Date sent: Thu, 28 Mar 2002 10:06:58 -0800 (PST)
From: "Fred Cisin (XenoSoft)" <cisin_at_xenosoft.com>
To: classiccmp_at_classiccmp.org
Subject: Re: UCSD P-System & "compile once, run anywhere"
Send reply to: classiccmp_at_classiccmp.org
> On Thu, 28 Mar 2002, Hans Franke wrote:
> > 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.
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 :)
> > 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.
> 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.
> > 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?
Hmm... Naaa !
I was thinking more along the lines of just another compiler.
Basic, Fortran, Cobol, Pascal and finaly Java :)
> 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/
Received on Thu Mar 28 2002 - 12:35:19 GMT