Crashing IDLE

[David LeBlanc]

Ah! you mean "SLEEP" or "HIBERNATE"! :-). I believe in those cases the
microcode loop stalls on either the "sense" step (SLEEP) or some power level
signal (HIBERNATE). In both cases, as you mention, power requirements drop a
lot (less then 1 milliamp) or to virtually nothing (2-3 microamps).

WRT to Python in microcode, an early implementation of Smalltalk was
microcoded into the Xerox Dorado 16 bit mini-computer back in the late 70's.
I think Python has many of the same issues to deal with. In that
implementation, some functionality actually went from microcode back to
macro code and then back into microcode - i.e. some primatives where
detected by micrcode and dispatched to macro coded routines. This was mostly
out of microcode space constraints and CPU sophistication (or lack thereof),
and I doubt either of those would face a more recent/modern implementation.

David LeBlanc
Seattle, WA USA

> -----Original Message-----
> From: python-list-admin at python.org
> [mailto:python-list-admin at python.org]On Behalf Of Peter Hansen
> Sent: Friday, May 31, 2002 18:39
> To: python-list at python.org
> Subject: Re: Crashing IDLE
>
>
> 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
> --
> http://mail.python.org/mailman/listinfo/python-list