Hi Rome,

You wrote :

> Thanks to Christian and Ray for replying to this...

You're welcome ...

> Excellent points raised (yes, I read the entire reply).
> 
> During my HPLAB days, the language of choice was MODCAL, which was
> essentially pascal with various extensions such as default parameter
> values, and other goodies that pascal lacked.

Oh, I did not realize you were an HPLabs former staff member. Then I
should not have gone so much into detail.

> I really liked it very
> much: very easy to code, and, the entire library was developed using
> MODCAL. 

From my own former days as an MPE dumpreader with lots of source code
reading, I can say how much I like PASCAL/MODCAL. So easy to read, yes
...

> SPL seemed to be better at stack operations (somewhat faster),

Agreed, but there were not nearly as many stack ops in MPE/XL as there
were with MPE V/E and its ancestry. MPE/XL was much more
register-oriented, and MODCAL extensions were wonderful at handling
register ops.

> but MODCAL provided so much more, that a small performance penalty was
> no problem. 

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
how they compiled TurboImage in NM and never rewrote it? Your best
guess. Now if we compare NM performance, we have to consider that stack
ops were not that common, register ops very, very common, and
MODCAL/PASCAL probably the best choice to handle register ops, with C
most likely a close second. If you are familiar with NM MPE/XL compiled
code (and my best guess now is that you are), you've probably seen
gazillions of register ops, and not many stack ops. However I agree
that, as far as CM and MPE V/E are concerned, SPL was wonderful to
handle stack ops.

> Unfortunately, the C folks won the battle, and, prior to my
> leaving, most of the code was being developed with C.

They mostly won the battle of portability. I'm not sure that, 10 years
behind, there was any technical superiority of C vs. Pascal/Modcal. But
let's treat that as a business case, for a minute. Imagine you're a lab
manager and you have to churn out code for two platforms, one running
MPE and one running Unix. Then you say you are trying to evolve your
proprietary platform (MPE) into the world of open systems. If you want
to add open systems features like, say, INETD, telnet, Sendmail, et al,
you re-use the code you have already written for your "other" platform,
thus at the same time cutting cost and speeding availability. In other
words, you've squared the circle with minimal to non-existent technical
impact, other than training a few engineers on C, which you would have
had to do anyway sooner or later.

In other words, the technical C people did not win any battle. The bean
counters did.

> I'm an avid fan of Pascal, and, having FreePascal definitely is a
> blessing (www.freepascal.org).  I sure would like to get a good
modula-2
> (open-source) that runs on Win32.  So far, not too impressed with
these
> compilers.
> 
> By the way, a simple HelloWorld program (4 liner) in pascal creates an
> .exe file that is about 21,614 bytes.  The same program (again 4
lines)
> iin HLA is 6,144 bytes.
> 
> I'm studying HLA rather heavily these days.  It's the only assembler
> that makes a lot of sense.  For all interested, please take a look.
I'm
> sure you would be pleasantly surprised.  It's not your average
assembler
> that takes lots of development time.  It was written by Randal Hyde
(the
> guru of assembly language), which he still uses in teaching his
> assembler course at the university.

I've minimal experience with assembly languages. I've done some
assembly-level programming about 15-20 years ago, in my SPL fluency
times. I've done some Borland assembler (sorry, can't even remember the
exact product name .... perhaps TurboAssembler will ring a bell ...),
but that was also in a former lifetime. So I won't comment about the
current state of the art.

> Going back to MPE...
> 
> There is really too much effort to create MPE as a total package.  My
> intention was to create "some" part of it that we all can use (CI
would
> be a good start).  And, one does not have to write the entire CI as a
> start.  The code could be published as each command was added.  By
> definition, this means that some of the intrinsics would be written to
> be called by the CI commands.

Yes, but the relevance of re-developing, or emulating, MPE is in running
current apps on some "other" platform. If you only have a limited
feature set, you won't be able to run your apps, and you cut yourself
off of the corporate market. Other than a hobbyist's playground, I see
little relevance in such a partial MPE-like implementation.

> So, version 1.0 might have just a few commands, 1.1 will add a couple
> more, and so on.  At some point, we would have a "shell" that could be
> used on say, Win32 (rather than dealing with all the .bat files).

When the subject was raised at the time OpenMPE was started, Linux was
the host platform of choice, because a) it is free, 2) it is widely
available and 3) it seems to be relatively easy to program on it. Please
note that, as I have a tremendously minimal Linux experience, I can't go
much into detail here.

> I think this would be a good start.  The worst one could do is give
all
> the MPE folks a shell that they can take with them.
> 
> Granted, this would not be a "real" MPE, but it would be a start.

As much as I understand the a) good starting point and b) hobbyist's
point of view, I still fail to grasp the business relevance of a partial
MPE.

Christian

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