Pythoniac: Thoughts on a hardware Python processor

[David LeBlanc]

> -----Original Message-----
> From: Gustavo Cordova [mailto:gcordova at hebmex.com]
> Sent: Thursday, June 27, 2002 12:54
> To: David LeBlanc
> Cc: Python List
> Subject: RE: Pythoniac: Thoughts on a hardware Python processor
>
>
> >
> > Ahh! Haven't you heard? Forth came in Fifth and the Forth
> > chip is dead. In fact I don't think anyone is still offering
> > a stack based computer (only HP did AFAIK, the HP 3000).
> >
> > Dave LeBlanc
> > Seattle, WA USA
> >
>
> Which is truly a shame; it's more because of commercial
> and market pressures, and nothing to do with true
> throughput or technical merit.

Actually, it's hard to make zero address machines effeciently in hardware
(on chip). At least a (substantial) part of the problem is having to keep
pushing and popping parts of the hardware stack into memory. That might be
less of a problem these days given VVLSI, but back then 4k of 16 bit stack
would have been a big deal - and yet not enough for multi-tasking. Would
have been great for embedding though. I agree that theoretically, a stack
machine is a thing of grace and beauty. To be honest though, the IBM System
34 tagged architecture is one I would have preferred to have survived. IMO,
_that_ could have made Python really really go fast! Personally, i'd settle
for a good 3-address CISC machine (which Intel X86 is not), but IIRC, those
never went far back when there was still a good deal of experimentation in
the MPU world.

> Let's see if Python can be ported to Forth, like it was
> to Java. If it can, *then* python'll run at hardware speed,
> don't you think?

I don't know about your Python, but my Python definately runs just as fast
as the hardware can make it go ;-). It's going to run a whole lot faster
when the AMD "Hammer" 64 bit hummer hits the bricks at a price that mere
mortals can afford. Seriously though, there are some aspects of Python that
don't lend themselves to efficient implementation in hardware.

> Anyhow, as I said, it's a shame that Forth has been lambasted
> so much that it's not really possible to find much info
> and code on the net. It's actually a quite nice tool.

I don't think Forth got lambasted so as to cause it to be hard to find info
on - I think it, like many many other computer and natural languages, had
it's day and has left the stage. Too bad Lisp hasn't followed it ;-)

> :-/
>
> -gus

Whoever asked if the Intel/AMD FP stack counted: nah - it's not the primary
mode of the CPU like it was on the HP 3000 and the Forth chip. BTW, speaking
of the Forth chip, I think Forth, Inc. is still offering the IP for that if
anyone wants to burn a few hunderd k$ on new silicon.

While I think that creating a Python chip is a great and wonderful idea, I
doubt it will or should happen:

* The CPU vendors are ahead of the power curve and I don't see an Open
Source group doing as well, let alone better. I figure a volunteer effort
would take on the order of $1,000,000,000 in time/services to get a 1-2 GHZ
chip. Intel spent about 4x that for the Itanic...err Itanium ;) and they had
the capital, IP and bodies already on hand. (Coming soon: "Itanic 2 - The
Resurrection!" (really, Itanium 2 is coming).)

* Important IP for modern CPU performance is under patent. Plus, the guys
who have the knowledge are probably paid extreme sums and kept in obscure
out of the way places, not to mention being contractually obligated up the
ying-yang to not disclose, compete or otherwise ply their trade for other
then their designated keepers for a long term of years.

* Efficient explotation of current and proposed CPU architectures is
predicated upon software tools that do a good bit of (proprietary)
optimization and organization during code generation before the CPU ever
sees the bits.

* Burning Python into silicon will tend to fossilize the language. Is Guido
done enough with it for that yet? Guido and the gang can whip out a patch
for the PVM in a matter of hours. How long would that take for a silicon
change and what would it cost?

For all these reasons and more, I think a good compiler with a retargetable
backend is a better expenditure of time/effort and would yield a result far
faster then a silicon development effort.

Dave LeBlanc
Seattle, WA USA