On 6/22/07, Paul G. Allen <[EMAIL PROTECTED]> wrote:
On Thu, 2007-06-21 at 09:10 -0700, Tracy R Reed wrote:
> So for the past year or two I have been reading up on functional
> programming. I still haven't written anything useful with it but I hope
> that will change soon. Here is an exchange I had with Chris Seberino on
> IRC last night which I thought some of you might enjoy.
>
> <tessier> |seb|_: Have you looked at Stackless python? I just suddenly
> realized it's potential.
>
This reminds me of the Ti 99 series of CPUs. They were stackless and had
a memory-to-memory architecture. They only had three hardware registers
- program counter, status register, and workspace pointer. With these
chips, a context switch was up to 4 times faster than on the x86 running
at the same clock speed. A complete context switch could be performed
with a single instruction, and the limiting factor on the number of
contexts was the amount of memory available.
There was no stack or heap to keep track of and operations involving
data in memory were faster than on other systems. It's a shame the CPU
never took off like Intel processors did.
PGA
Stacks are _not_ the problem. Swapping a lot of state between
on chip and off chip memory is the problem.
The fastest task switching processors that I have ever
encountered were the RTX 2000 16 bit embedded processors
from Hariis, which were a direct descendent of Chuck Moore's
orignial Forth chip the Novix 4016. These machines had pointers
to stacks and would do interupts in one or two clock cycles.
Comparing them with an x86 architecture is like comparing
a racing motorcycle with an 18 wheel truck.
For more read Phil Koopman's excellent book "Stack Computers"
http://www.ece.cmu.edu/~koopman/stack_computers/contents.html
For issues with state cahnging see
http://www.ece.cmu.edu/~koopman/stack_computers/sec3_2.html#324
http://www.ece.cmu.edu/~koopman/stack_computers/sec6_5.html
From which I quote,
"CISC machines may have instructions which take a very long time to
execute, degrading interrupt response latency performance. Stack
machines, like RISC machines, can have a very quick interrupt response
latency. This is because most stack machine instructions are only a
single cycle long, so at worst only a few clock cycles elapse before
an interrupt request is acknowledged and the interrupt is processed."
"Once the interrupt is processed, however, the difference between RISC
and stack machines becomes apparent. RISC machines must go through a
tricky pipeline saving procedure upon recognizing an interrupt, as
well as a pipeline restoring procedure when returning from the
interrupt, in order to avoid losing information about partially
processed instructions. Stack machines, on the other hand, have no
instruction execution pipeline, so only the address of the next
instruction to be executed needs to be saved. This means that stack
machines can treat an interrupt as a hardware generated procedure
call. Of course, since procedure calls are very fast, interrupt
processing time is very low."
IMHO it is a real pity that these architectures have not gotten
an commerical traction.
BobLQ
PS. I think recursion is at least as "natural" as iteration.
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
