Python's Performance

[Donn Cave]

In article <861x2t2m7s.fsf at bhuda.mired.org>, Mike Meyer <mwm at mired.org> 
wrote:

> Donn Cave <donn at u.washington.edu> writes:
> > I agree that there are many shades of grey here, but there's also a
> > real black that's sharply distinct and easy to find -- real native
> > code binaries are not interpreted.
> 
> Except when they are. Many machines are microcoded, which means your
> "real native code binary" is interpreted by a microcode program stored
> in the control store. Most machines don't have a writeable control
> store (WCS), so you generally can't change the interpreter, but that's
> not always true. In the simple case, a WCS lets the vendor fix
> "hardware" bugs by providing a new version of the microcode. In the
> extreme cases, you get OS's in which the control store is part of the
> process state, so different processes can have radically different
> formats for their "native code binaries".
> 
> Then there's the Nanodata QM-1, whose microcode was interpreted by
> "nanocode".

Fine -- given a Python Chip computer, Python programs are
native code.  It can use microcode, if that helps.

The VAX/11 microcode was just a software extension of the
CPU hardware, implementing some extra instructions, the way
I remember it.  I don't recall that it was of any more than
academic interest to anyone using the computer - though it
may have been software in a sense, it was on the hardware
side of the wall.  On the software side of the wall, if your
program can go over the wall by itself, then it's native.

   Donn Cave, donn at u.washington.edu