Re:

Christian writes:
>
> Well, I'm not sure there was such a performance hit. There's never been
> any such thing, officially speaking, as an SPL NM compiler. Now guess

What about SPLash!? :)

<plug>
http://www.allegro.com/products/#SPLASH
<plug>


> how they compiled TurboImage in NM and never rewrote it? Your best
> guess.

They used the un-released PSPL compiler.

For the HP 300 (Amigo), and the Classic HP 3000, HP developed SPL2 ...
a language to replace SPL.

But ... SPL2 never did replace SPL (although a few things were written
for Classic MPE in SPL2, like VPLUS and the second COBOL compiler, IIRC).
And, SPL2 was never released to the users.
(Actually, this was the start of a long, and bad, tradition within HP
of failing to realize that if *they* needed a tool, the *users* probably
needed the same tool ... that's why the CM version of Modcal was never
released.)

When MPE XL (on PA-RISC) was being designed/developed, the compiler
language lab (CLL) said that a native mode SPL wouldn't be possible.
For the most part, people seemed resigned to this (well, except for the
eventual SPLash! Consortium, which saw it as an opportunity :)

The SPLash! Consortium was formed in 1986 ...
to provide useful tools to MPE XL users.
Our first two projects were the "Beyond RISC!" book and
the SPLash! compiler.

We explained to HP how we planned to implement a native mode SPL.
HP management was supportive of our idea, and kindly provided us machine
access at the TAC (migration center).  We had had to convince CLL that an
NM SPL was possible before we got the machine access ... HP probably wanted
to avoid wasting their resources if the project didn't look feasible.

Later, possibly given new hope by our success with SPLash!,
CLL apparently decided to port SPL2 to native mode for PA-RISC.

My vague memory is that the SPL2 port was motivated by the desire to port
the COBOL compiler to native mode (while changing its code emitter
to emit PA-RISC code, of course).

Originally, the SPL version of IMAGE was going to be replaced by a new DBMS,
HPIMAGE, written (IIRC) in Modcal.  When that didn't succeed, and the
performance of the CM IMAGE (still in SPL) was a concern, the IMAGE lab
and CLL apparently cooperated and produced:

   - PSPL ... based on the NM SPL2 compiler, but with a syntax much closer
   to SPL/V (lacking ASSEMBLE and TOS, and with a slightly enhanced
   MOVE statement, and with some 64-bit pointer support).
   BTW, PSPL stands for "Portable SPL".

   - A successful port of IMAGE to NM by changing the SPL source into
   PSPL source.  (Probably less than 10% of the code changed, but that's
   just a guess.)

(I have not seen any evidence to imply that PSPL was used for anything
else within HP, other than for IMAGE.)


> behind, there was any technical superiority of C vs. Pascal/Modcal. But

Having produced a lot of code in both languages, I'd choose Modcal
for almost any project ... based on the languages alone.  However,
reality intrudes, because you can't just consider the language in isolation.
Portability is a major problem with Modcal (it's actually less portable
than SPLash!, surprisingly, because it is limited essentially to PA-RISC
platforms, whereas SPLash! now seems to be limited to platforms of
either PA-RISC or 32-bit C compilers).  Also, even on HP-UX, Modcal
doesn't seem to be supported as well as C by all of the available
debugger tools.

Why would I choose Modcal, standalone?  Because you have the power of C
when you need it (via reasoned use of type coercion), but the safety of
Pascal most of the time.  (Nested procedures provide a nice bonus :)

In short: it's easier, and more common, to write bad code in C than in Modcal
(although one can certainly write bad code in Modcal, as in any language :)

Stan
--
Stan Sieler
[log in to unmask]
www.allegro.com/sieler/wanted/index.html

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *