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

[pausch@saaf.se (Paul Schlyter)]

In article <20030619155811.09031.00001456@mb-m18.aol.com>,
Michael J. Mahon <mjmahon@aol.com> wrote:
> Paul Schlyter wrote:
> 
>> In article <Xns939FA7E65252wildstar128hotmailco@216.168.3.44>,
>> wildstar  <wildstar128@hotmail.com> wrote:
>> 
>>> Excuse me, one has to first write/compile a JAVA compiler. It still 
>>> requires interpretation during execution. Did you forget about the byte-
>>> code interpretation. That is like converting tokens in token BASIC.
>> 
>> 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.
> 
> Or look at the machine code of a RISC machine, which directly
> controls the hardware.
 
Really?  I knew that each instruction for a given RISC CPU always has
the same length, but I wasn't aware that these instructions were so
very long (hundreds of bits, or more).  Yep, that's the kind of
instruction lengths you need if you want a specific bit in the
instruction to directly control a specific gate in the hardware --
that's what microcode does.
 
> The elimination of microcode was one of the primary tenets of
> RISC design.  (At HP, we added small bits of ordinary machine code
> as interrupt routines to handle things like TLB misses, and we called
> it "millicode" to emphasize that it was normal code performing a
> role typically done by microcode in a CISC machine.  (BTW, this
> code resided in normal memory, not ROM.)
 
Microcode can of course be replaced by hardware, however the RISC CPU
still does an amount of interpretation of the machine code before
deciding what to actually do.  If the RISC machine code was some kind
of microcode moved out to regular memory, then it would become very
bloated, where most bits in the machine code didn't matter but still
had to be there to occupy that specific bit position.
 
-- 
----------------------------------------------------------------
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/