Re: Low-level vs. High-level programming (was My First Computer)

[pausch@saaf.se (Paul Schlyter)]

In article <Xns939F7A7487987wildstar128hotmailco@216.168.3.44>,
wildstar  <wildstar128@hotmail.com> wrote:
> pausch@saaf.se (Paul Schlyter) wrote in
> news:bcsosv$otu$1@merope.saaf.se: 
> 
>> Note quite: Java bytecode is much closer to machine language than
>> BASIC tokens.
>>  
>> Actually, even native machine code is interpreted -- by the hardware
>> CPU.  If you want to look at some REAL machine code, then you'll have
>> to look at the microcode om ROM's within many CPU's.
> 
> Like Zork. Anytime you use representational code to represent a function
> great but byte-code really is a fancier token structure that is more
> flexible then early tokens.
 
The same can be said about any kind of machine language, for real
as well as virtual CPU's....
 
> Giving you an apparently close to ML
> structure but using virtual Opcodes. A token basically represents a
> command or routine with a special number. One can actually compile by
> simple taking the token and converting them into the ML routine calls. I
> really hope they given some sophistication to it. Hey, the token
> structure in BASIC was written 25+ years ago. 
> 
> The advent of Zork given some VM nature. Take a look at ZMachine
> someday. 
 
I already did ... some 20 years ago.  It was fun!  The ZMachine was
more portable than the JVM, in the sense that ZMachine interpreters
were implemented for a larger number of systems than the JVM.  This
happened in the early 1980's, when there was no standardization
whatsowever among microcomputers -- each used their own OS, their own
disk format, etc etc etc.  On my good ol' Apple II+ I ran two
versions of the ZMachine: one for native Apple II hardware, written
for the 6502 (it was neither Apple DOS, nor Apple ProDOS or Apple
Pascal; the ZMachine for the Apple II served as a kind of OS as
well), and the other fpr CP/M, under Apple II CP/M (here CP/M was
actually booted before you started Zork).
 
I believe the ZMachine was also the very first implementation of
virtual memory for 8-bit micros: you noticed that when you visited a
room for the first tome, something was read off the disk.  When you
returned there, nothing was read off the disk because the code for
that room was still in the cache.  But if you went far away, visiting
many other rooms, and then returned much later, something was read
off the disk again.  This virtual memory implementation was of course
considerably simplified by the fact that everything in the disk cache
was read-only (Z-code for the game) so the disk cache handler never
had to worry about disk pages getting "dirty" and needing to be
written back to disk.... :-).  The game state itself, which was a
much smaller data area, wasn't handled by the virtual memory - it
remained in RAM during the entire game, being read in at game start
and written out whenever you did a "Save" or when you quit the game
(unless you decided to discard your current game position then).
 
-- 
----------------------------------------------------------------
Paul Schlyter,  Grev Turegatan 40,  SE-114 38 Stockholm,  SWEDEN
e-mail:  pausch at stockholm dot bostream dot se
WWW:     http://www.stjarnhimlen.se/
         http://home.tiscali.se/pausch/