Crashing IDLE

[Peter Hansen]

David LeBlanc wrote:
> 
> Peter Hansen wrote:
> > Instructions like HALT simply put the CPU into a state where
> > *all* it does is sit and check for interrupts, and sometimes
> > bump timer registers along.  It is in suspended animation,
> > not reading or writing memory or incrementing the program
> > counter.
> 
> "HALT" is often implemented as a "jump to self" in the chip's microcode.
> This is a simple way of taking it through the microcode
> sense/dispatch/process loop that is the basis of all macro ("regular")
> instructions.

I think you're right.  Probably STOP is what I meant, which 
would be one step closer towards completely frozen than HALT.
I may have the names wrong (and relatively few micros support
something like STOP) but the idea is that there is an 
instruction that does not even execute that loop in microcode,
so that the main clock can be stopped and power consumption
lowered.  This sort of thing is no doubt uncommon in generic
CPUs used in PCs, but in embedded micros, and probably laptop
CPUs, it's very important.

> I really meant assembler as an analogy - Python's VM (interpreter if you
> prefer) is quite analgous to a CPU with C as the microcode for the
> underlying "simple" CPU. Too bad none of the user microcodable chips ever
> made it into production/broadspread use. It would be interesting to create a
> truly microcoded Python chip. Perhaps one of those 200,000 gate FPLA's....
> hmmmmmmm.

I'm not expert, but the little time I've spent looking into
the heart of the Python interpreter tells me it would be *much*
more difficult to do that than with, say, the Java engine.  Java
has much lower level bytecode than does Python, and it's much
less dynamic.  It would be very cool to see though.  And a blend
of microcoded and non-microcoded routines could be effective.

-Peter