28 Mar
2002
28 Mar
'02
4:35 a.m.
Date sent: Thu, 28 Mar 2002 10:06:58 -0800 (PST)
From: "Fred Cisin (XenoSoft)" <cisin(a)xenosoft.com>
To: classiccmp(a)classiccmp.org
Subject: Re: UCSD P-System & "compile once, run anywhere"
Send reply to: classiccmp(a)classiccmp.org
Some of the P-Code engines were VERY well written. V
some compilers, ...
The PC-DOS Fortran compiler 1.0 (written by MICROS~1, sold by IBM) when
running a sieve of Erastothanes (a common benchmark in those days) was
SLOWER than the MICROS~1 ROM BASIC interpreter!
Bob Wallace (PC-Write), who wrote the MICROS~1 Pascal compiler, advised to
NEVER EVER use the supplied run-time library.
The standard Apple machine was at least in the beginnig as worse
as it could get.
Hmm... Naaa !
I was thinking more along the lines of just another compiler.
Basic, Fortran, Cobol, Pascal and finaly Java :)
On Thu, 28 Mar 2002, Hans Franke wrote:
And that's what what I refer to if I speek of platform independant
(in the same sense as Java claims it). Never ment to be optimal.
We all know there's only one real high level language :)
Now, here we are talking about two things:
#1 is is the platform independant coding of an application, which
is accomplished by using the same structure across all platforms.
They did a good
job. > Because of #2 you rarely could use a disk from
one system on another
> . . .
> (In fact I even remember the same situation for MS-DOS - at least
The number of formats could have easily been limited
to one for each type
of hardware.
I had a brief discussion of that with Gary Kildall.
Me: What is the standard format for 5.25" double density?
Gary: 8" single density.
He held to his convictions of NOT diluting the standard by having a
secondary (5.25") standard format.
Interesting statement ...
> > The basic concept behind it was the
distribution of software NOT as a
> > binary, but as a platform independent "P-code" that was run on a
> > "P-code" interpreter.
> Well, the P code IS the binary format of the programms. Just as
> the so called Bytecode is the binary format for Java.
Most people think of "binary" as meaning the
NATIVE executable form of a
program.
By having the input to the P-system interpreter in a non human readable
form, it added the additional benefit of making it more difficult to make
any changes without going back through the compiler process.
Well, the P-System wasn't just a Pascal interpreter where each statement
was converted into a token and then interpreted, but rather a real system
of compilers for a (somewhat weired) CPU, which later on was emulated on
the host system (or not, if the host was a Micro Engine). in fact a concet
not uncommon in the mainframe world. The /370 ISA was just an abstract CPU
model for the programmer - even the OS people. The real CPU did change from
model to model and from manufacturer to manufacttuerer. Rarely that the code
was native, sometimes even draged over two or three levels of microcode. I've
always viewed the P-Code machine quite similar back than (Sorry, /370 was and
is my world). The interpreter was just the microprogramm, specific to the
actual hardware to supply the ISA for all programming. There have been good
and bad implementations ... to be honest, some bad implementations in the /370
world have been bad by design - the customer bought a machine good for xyz kOp/s
and if they bought the 'upgrade' packet, all they got was a new microcode disk
whare some coding was 'better' (read less nops).
The UCSD system could have been the real unifying OS - if they hadn't shoot
themself all the time - you named altready much of the incompatibility madness.
It combined all of the convenience of software
development of a compiler
with the speed of execution of an interpreter.
Well, the speed difference
wasn't that big between the
result of 'real' Compilers (fortran for example) and
the UCSD-P version of Fortran. As so often it depended
on your kind of application. BTW: Total
different thing - has anybody erver tried to do a Java to
UCSD P-Code compiler ? Could be some fun :)
Or a P-code interpreter written in
java?
Or java virtual machine written in P-Code? Two more fun parts of the UCSD P-System:
It would not/could not save a file in non-contiguous space. Thus you
could have hundreds of K of free space, but not necessarily enough
contiguous to save a file. Periodically you had to run their
"CRUNCH" program to defragment. Hope that nothing goes wrong DURING that
process!
Oh ja, several seconds of nail biteing ....
Gruss
H.
--
VCF Europa 3.0 am 27./28. April 2002 in Muenchen
http://www.vcfe.org/