Pythoniac: Thoughts on a hardware Python processor
Christopher Saunter
I have seen the occasional post about creating a specific hardware 'Python
Processor', that could then be built and used in programmable logic or the
like (Valves, relays, core memory - Pythoniac ;-) - in other words, create
a processor that executes Python bytecode directly. There would be
various different reasons for doing this (the 'neat' factor etc...)
Replies to these questions have been a bit scant, so I though I would
chuck something in.
Due to Lazy Typing Syndrome I've used a couple of abbreviations:
PVM - Python Virtual Machine / Python Interpreter
PBC - Python Byte Code
This has been done for Java, for example
http://www.xilinx.com/prs_rls/0134lavacore.htm
and I have seen a partially complete open source core out there somewhere,
but I can't find it right now.
I have recently been looking at doing this for Python, and it seems like a
rather odd task. From playing with the 'dis' module and reading some
docs, it seems that Python Interpreter (PVM), which would be translated
into a processor, has these properties:
o Operates on sequential bytecode with branching / jump
instructions.
o Entirely stack based (no concept of registers / memory)
So far, so good - a processor could be built to do these functions of the
interpreter. However, we go on....
o Rather than operating on 8/16/xxx bit words, as most hardware
processors do, the PVM processes objects (via pointers on the stack),
which are treated in a 'black box' fashion - i.e. they have add, subtract,
compare etc. methods that are called by the PVM, and that return a result.
These methods of objects may not actually be coded for in Python, but in
the machine language (x86, alpha etc, derived from C etc.) of the
underlying processor.
Here, the PVM is very different from a 'typical' hardware processor, as
the later has a strictly limited number of data types, which it is able to
manipulate, whereas Python has many, built out of the basic types, and
although some may be coded in Python, they themselves are built on top of
C code (or Fortran etc.) that are all translated to native (x86 etc)
bytecode outside of Python. The upshot of this is that the PVM is
unaware, in the majority of cases, of what actually needs to be done to
manipulate objects, it just makes calls to non Python code.
So, how to go about dealing with this in a Python processor?
a) Create a stack based Python bytecode processor to replace the PVM, and
have this interact with another processor (x86 etc.) which stores the
objects and executes their methods. Ick.
b) Create a stack based bytecode processor that interfaces to custom
hardware processors for each Python object. Ick.
Neither of these are particularly nice (or for b, workable) solutions.
The one I prefer is the following:
c) Create a processor that understands Python bytecode, using a stack for
the object pointers. However, the processor would execute a sort of
superset of PBC, call it P+. This would be fully compatible with Python,
but would include several built in types (32bit integers, 8bit integers
for strings etc,) and would have access to a memory space. The basic
Python types(1) would then be implemented using P+, and stored in the
memory available to P+.
c Should present a processor that executes Python bytecode, manipulating
the Python stack. Then, when a method of an object is called, the
appropriate piece of P+ is called, executed by the same processor, and it
modifies the data structures of the objects, and the Python stack as
necessary, before returning seamlessly to the PBC execution.
Python extensions would then be directly executable on this processor, if
coded in Python. If they are coded in C or some other language, a C->P+
compiler would be needed...
The level of abstraction caused by having to chase down function and
object pointers will be higher than for the execution of code on a more
conventional hardware processor, but this is also the case for executing
PBC with an interpreter.
One advanced idea (not really thought about it yet!) is to store the
Python stack in main memory, but to store the top x (e.g. 32) items of the
stack in a register file to allow bytecode parallelism. I gather that
IA-64 may do something sort of similar.
---
So, Pythoniac: a hardware (well, FPGA(2)...) processor that directly
executes Python bytecode. What do people think about the idea? Is it
really feasible? I have doubts it would be particularly quick (in the
same way I have my doubts about anti-gravity generators... ;-), but it
should be fun!
I would like to try and implement this, initially in a simulation
environment, then in a real FPGA, with hooks back to a PC allowing the
loading, execution, single step execution and monitoring etc of PBC.
Ideally I would like to reach a state where an interactive interpreter
runs over a serial port...
So, anyone else interested in this? Comments, suggestions, gaping holes
in my understanding of things as outlined above etc are welcome!
Regards,
Chris Saunter
(1) Now we have increasing type<->object integration, should we refer to
numbers, strings, lists etc as types or objects?
(2) FPGA - Field Programmable Gate Array - a chip that consists of a
'logic fabric' than can be configured to produce arbitrary circuit
designs. If this sounds new to you, try www.fpgacpu.org
Steve Holden
news:afc52t$2pj$1...@sirius.dur.ac.uk...
> Dear All,
>
> I have seen the occasional post about creating a specific hardware 'Python
> Processor', that could then be built and used in programmable logic or the
> like (Valves, relays, core memory - Pythoniac ;-) - in other words, create
> a processor that executes Python bytecode directly. There would be
> various different reasons for doing this (the 'neat' factor etc...)
>
>
> So, Pythoniac: a hardware (well, FPGA(2)...) processor that directly
> executes Python bytecode. What do people think about the idea? Is it
> really feasible? I have doubts it would be particularly quick (in the
> same way I have my doubts about anti-gravity generators... ;-), but it
> should be fun!
>
the bytecode when moving from one major version to another. If you are
prepared to overlook their tendency to do that I would think this would be a
great project. Once you got the hardware core working the major problem
would be C/C++ to P+ compiler.
regards
-----------------------------------------------------------------------
Steve Holden http://www.holdenweb.com/
Python Web Programming http://pydish.holdenweb.com/pwp/
-----------------------------------------------------------------------
Thomas Heller
> >
> > I have seen the occasional post about creating a specific hardware 'Python
> > Processor', that could then be built and used in programmable logic or the
> > like (Valves, relays, core memory - Pythoniac ;-) - in other words, create
> > a processor that executes Python bytecode directly. There would be
> > various different reasons for doing this (the 'neat' factor etc...)
> >
> [... Pythoniacity ...]
> >
> > So, Pythoniac: a hardware (well, FPGA(2)...) processor that directly
> > executes Python bytecode. What do people think about the idea? Is it
> > really feasible? I have doubts it would be particularly quick (in the
> > same way I have my doubts about anti-gravity generators... ;-), but it
> > should be fun!
> >
> You will, of course, have to stop the development team from tinkering with
> the bytecode when moving from one major version to another.
it in Python, and translate this to VHDL. Pass this through synthesis, and
you get a byte-stream which the host CPU (if there is one) uses to initialize
the FPGA (FPGA's are reprogrammable).
So, basically, a reconfigurable Python Processor hardware in a file
on the host system should be possible.
Thomas
David LeBlanc
> From: python-l...@python.org
> [mailto:python-l...@python.org]On Behalf Of Christopher Saunter
> Sent: Wednesday, June 26, 2002 3:30
> To: pytho...@python.org
> Subject: Pythoniac: Thoughts on a hardware Python processor
>
>
> Dear All,
>
> I have seen the occasional post about creating a specific hardware 'Python
> Processor', that could then be built and used in programmable logic or the
> like (Valves, relays, core memory - Pythoniac ;-) - in other words, create
> a processor that executes Python bytecode directly. There would be
> various different reasons for doing this (the 'neat' factor etc...)
<snip>
> I would like to try and implement this, initially in a simulation
> environment, then in a real FPGA, with hooks back to a PC allowing the
> loading, execution, single step execution and monitoring etc of PBC.
> Ideally I would like to reach a state where an interactive interpreter
> runs over a serial port...
>
> So, anyone else interested in this? Comments, suggestions, gaping holes
> in my understanding of things as outlined above etc are welcome!
>
> Regards,
> Chris Saunter
Have you considered the need for:
* Bus control
* Interrupts
* Memory Management
(without even considering pipelining or other performance enhancing
techniques)
Xilinix makes available a basic FPGA/FPLA design tool for free - an entry
level of their full-on product. They are also known to support projects with
full copies of their tool and their (not-inexpensive) chips for free.
Presumably they do this if they think there might be commercial potential.
Here's a starting place: http://www.etek.chalmers.se/~e8cal1/jamcpu.html
Introductory survey piece: http://www.eetimes.com/story/OEG20010201S0050
Motherlode of information: http://www.opencores.org/ Includes info on open
design tools, most for Linux.
64 bit super-pipelined CPU dev project: http://www.f-cpu.org/
HTH,
Dave LeBlanc
Seattle, WA USA
P.S. Personally, I think a kick-ass true compiler with a retargetable
backend would be a better thing to persue.
Paul Rubin
for hardware execution. Take a look at the work done on Lisp machines
in the 70's and 80's instead.
Oren Tirosh
> Dear All,
>
> I have seen the occasional post about creating a specific hardware 'Python
> Processor', that could then be built and used in programmable logic or the
> like (Valves, relays, core memory - Pythoniac ;-) - in other words, create
> a processor that executes Python bytecode directly. There would be
> various different reasons for doing this (the 'neat' factor etc...)
One of the most effective optimizations for such a machine would be to
support compact objects. The machine word would be somewhat larger than the
actual address space. Let's say 40 bits. If the 4 high bits are 0 this is a
reference to an object allocated somewhere in memory. If the high bits are
not zero it means that the actual object is stored inside the register. You
have 15 types that can bypass allocation, deallocation, reference counting,
etc. The most important compact type is int, of course. Python floats are
64 bits so if you want them to be compact objects, too, the machine word
would need to be 64+ bits.
Another important hardware feature is accelerated associative lookup.
Oren
Christopher Saunter
Thanks for the replies, both email and usenet! Well, my plans
have changed a bit, and rather than replying to each post individually, I
have grouped the whole lot together below (hope that’s okay...)
Addressing the various points / ideas:
Python->VHDL (Thomas Heller)
----------------------------
This is an interesting idea, although rather at tangents to what I would
like to do. JHDL (www.jhdl.org) does something similar, allowing FPGA
etc. designs to be described in Java. I haven’t played with it yet mind.
I suspect implementing something like this in Python would be a minefield,
as this is a case where strong, static typing is really quite desirable!
Of course one could always use Jython... Guggy.....
Bytecode compatibility (Paul Rubin)
-----------------------------------
Initially I was thinking of using the same assembly as python (different
bytecode enumeration to make instruction decode more pleasant) but after
more looking into Pythons guts and various comments, I see that this is a
daft approach, as PBC is just to high level.
So Pythoniac would be some sort of processor with an inbuilt hardware
understanding of objects (stacks, registers etc. contain pointers to
objects, dedicated hardware would handle the lookup of the address of the
relevant function for the current opcode etc.), with a lower level
bytecode (P-) than Python, but one that Python compiles to in a ‘natural’
way.
‘Compact Objects’ (Oren Tirosh)
-------------------------------
I like this suggestion, it is something I had been thinking about in a
slightly different context, but not thought through.
Extend the idea to registers and stack objects, so that although
register/stack/etc. would normally store pointers to objects, the core
data types would be stored directly, and flagged as
int32/float32/aaa/bbb/object pointer. This seems a neat way of
integrating the necessary basic datatypes into an OO framework. I think
it would also make parallel execution of bytecode less of a headache.
Performance Issues
------------------
Pipelining and Instruction/Data caches
I have given these some though, and initially I would just like to see a
working processor, not a fast one. Pipelining sure will be interesting
with such a processor. I suspect once some general diagrams are created
for the proc, it will be easier to get a grip on how to do this.
Perhaps the processor would benefit from a separate cache for function
lookups for objects e.g. if ‘matrix’ objects are in regular use, the
function pointers for their ‘add’, ‘subtract’ etc. operations would be
cached. However, these are all considerations for later on... - Oren’s
‘accelerated associative lookup’?
Non Pythonic processor bits: (David LeBlanc)
----------------------------
[Bus Control, Interrupts, Memory Management]
Bus Control
- - - - -
This should be simple. Well, maybe not simple, but it’ll be an integral
part of the processor design.
David - thanks for the FPGA links. Some interesting links. I already own
a development board with a Xilinx SpartanIIE, so this is what I shall aim
to implement Pythoniac in, using the free Xilinx software. If this is
doable, anyone should be able to run / edit the processor for free...
Memory Management & Interrupts
- - - - - - - - - - - - - -
Initially I am aiming for a low speed (1MHz) processor, to allow real time
links / immersion with support software on a PC, so there will be no
caches. Also, initially there would be no multithreading, and as far as I
can tell, no need for interrupts. That’s not saying they wouldn’t be
added in the distant future...
The lack of threading removes some of the need for an MMU (memory
management unit)
If there was one memory space this would need to be split for different
purposes - stack, program, data etc. However, initially I plan to use the
multiple embedded memories in Xilinx devices to give separate memories for
each purpose (this limits it to small program / stack sizes, but I’ll be
happy when I have a processor that can max them out!)
On the other hand, hardware assisted reference counting / garbage
collection etc. might prove interesting.
Lisp Processors (Paul Rubin)
----------------------------
Thanks. Lots of useful looking Google hits to follow up there.
Bytecode Tinkering / C to P+ compiler (Steve Holden)
----------------------------------------------------
It looks like using python bytecode directly would be rather daft, so a
lower level bytecode would be used. Hopefully it would be relatively
trivial to convert different versions of Python code to the underlying
bytecode... As for a C,C++ to P+ compiler (I wonder if it should actually
be called P-) I’ll leave that as an exercise to someone else ;-)
Python compiler with retargetable back end (David LeBlanc)
------------------------------------------
I suspect that this is the way to go for faster Python, something I would
like to be able to use. I stress that ‘Pythoniac’ is not about speed, so
much as a ‘neat’ factor - I have been using programmable logic for a
couple of years now, and would like to attempt a processor core. I
thought one a bit different would be interesting... Having said that,
Pythoniac will need a compiler... Psyco is showing the way here, and it
looks good to me!
The current plan:
------------------
A RISC style processor that executes a more minimal bytecode than that of
cPython, but to which cPython bytecode translates in a ‘natural’ way. The
processor would have hardware understanding of objects, so in general it
would store pointers to objects (compact objects not withstanding) and
would have hardware lookup to retrieve the function pointers for standard
operations on objects (+, -, compare etc etc.) based on the current
objects and opcode.
Things to look at:
o Caching function tables
o Hardware assisted reference counting / garbage collection
(nice / maybe not so nice)
o Efficiently implemented compact objects
o The bytecode (p-)
o A Python -> p- compiler
My current plan of action is for a very simple, RISC style CPU that just
understands integers, and works with 16 a bit address space and 16 bit
data. Implement a Python->p- compiler that translates a single python
function that uses just integer objects into p- and produce a processor
capable of executing the p- code. The goals would be:
a) Something that works
b) Something that works in a way that reflects the nature of the PVM, and
that has a simple Python->p- translation stage.
I think this could be quite a large undertaking, but interesting...
Regards, and thanks again to all who replied!
Chris Saunter
William Park
> Dear All,
>
> I have seen the occasional post about creating a specific hardware 'Python
> Processor', that could then be built and used in programmable logic or the
> like (Valves, relays, core memory - Pythoniac ;-) - in other words, create
> a processor that executes Python bytecode directly. There would be
> various different reasons for doing this (the 'neat' factor etc...)
The only route that has any chance of success is
Python -> Forth -> stack engine
which leverage works that has already gone into Forth area. But, my days
of hand assembling 68000 or programming HP calculators are long gone... :-)
--
William Park, Open Geometry Consulting, <openge...@yahoo.ca>
8-CPU Cluster, Hosting, NAS, Linux, LaTeX, python, vim, mutt, tin
Gustavo Cordova
> Christopher Saunter <Christoph...@durham.ac.uk> wrote:
> > Dear All,
> >
> > I have seen the occasional post about creating a specific
> > hardware 'Python Processor', that could then be built and
> > used in programmable logic or the like (Valves, relays,
> > core memory - Pythoniac ;-) - in other words, create
> > a processor that executes Python bytecode directly. There would be
> > various different reasons for doing this (the 'neat' factor etc...)
>
> The only route that has any chance of success is
> Python -> Forth -> stack engine
> which leverage works that has already gone into Forth area.
> But, my days of hand assembling 68000 or programming HP calculators
> are long gone... :-)
>
Ahh! Thanks for posting this; I was thinking of the same thing,
about Chuck Moore's forth chips and all that, but I didn't want
to post anything because I've already posted some Forth comments
and received no replies.
:-)
-gus
> --
> William Park, Open Geometry Consulting, <openge...@yahoo.ca>
> 8-CPU Cluster, Hosting, NAS, Linux, LaTeX, python, vim, mutt, tin
> --
> http://mail.python.org/mailman/listinfo/python-list
>
David LeBlanc
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).
Gustavo Cordova
> Which is truly a shame; it's more because of commercial
> and market pressures, and nothing to do with true
> throughput or technical merit.
>
Argh!!
Please forgive me!!
This last paragraph sounds vaguely "Tim Rue"-ish,
and for that I grovel forgiveness.
-gus
pd: *grovel* *grovel*
Roman Suzi
>> The only route that has any chance of success is
>> Python -> Forth -> stack engine
---------------
-------
---
Fython by analogy of Jython ;-)
>> which leverage works that has already gone into Forth area.
>> But, my days of hand assembling 68000 or programming HP calculators
>> are long gone... :-)
Sincerely yours, Roman Suzi
--
r...@onego.ru =\= My AI powered by Linux RedHat 7.2
Gustavo Cordova
> 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.
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?
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.
:-/
-gus
Jeff Epler
> 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).
Intel and AMD still offer a chip with a register stack in the
floating-point unit. Does that count?
Jeff
David LeBlanc
> From: Gustavo Cordova [mailto:gcor...@hebmex.com]
> Sent: Thursday, June 27, 2002 12:54
> To: David LeBlanc
> Cc: Python List
> Subject: RE: Pythoniac: Thoughts on a hardware Python processor
>
>
> >
> > chip is dead. In fact I don't think anyone is still offering
> > a stack based computer (only HP did AFAIK, the HP 3000).
> >
> > 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.
Gustavo Cordova
> 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.
>
If I recall correctly, Chuck Moore's still churning out
forth processors, with on-chip fast memory and hardware
stacks, really really cool stuff. I think there's more info
in the ColorForth site, or at least it points you in the
right direction.
> While I think that creating a Python chip is a great and
> wonderful idea, I doubt it will or should happen:
>
> [... snip ...]
>
> 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
>
That's what I meant!! This compiler you talk about should generate
Forth instead of the normal byte code. Hmmm... I think it's doable,
but I've yet to learn more forth.
Do you know any good resources? Online books? Good archives?
Anything?
:-)
-gus
Richard Jones
> > 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.
>
> If I recall correctly, Chuck Moore's still churning out
> forth processors, with on-chip fast memory and hardware
> stacks, really really cool stuff. I think there's more info
> in the ColorForth site, or at least it points you in the
> right direction.
Ooh... from there I found:
http://www-2.cs.cmu.edu/~koopman/stack_computers/index.html
"The ENTIRE BOOK is available to read on-line or to download for
off-line reading!"
Oh dear, there goes my spare time (again) :)
Richard
David LeBlanc
> From: Gustavo Cordova [mailto:gcor...@hebmex.com]
> Sent: Thursday, June 27, 2002 15:45
> To: David LeBlanc; Python List
> Subject: RE: Pythoniac: Thoughts on a hardware Python processor
>
>
> >
> > 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.
> >
>
> If I recall correctly, Chuck Moore's still churning out
> forth processors, with on-chip fast memory and hardware
> stacks, really really cool stuff. I think there's more info
> in the ColorForth site, or at least it points you in the
> right direction.
Not when I looked 4 months ago, and not just now when I looked at
http://www.colorforth.com/:
"25x Multicomputer Chip
Spectacular chip! 25 microcomputers, each with 512 words of 18-bit memory.
Each capable of 2400 Mips, sustained. Awaiting funding. " Site last updated
7/2001.
> > While I think that creating a Python chip is a great and
> > wonderful idea, I doubt it will or should happen:
> >
> > [... snip ...]
> >
> > 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
> >
>
> That's what I meant!! This compiler you talk about should generate
> Forth instead of the normal byte code. Hmmm... I think it's doable,
> but I've yet to learn more forth.
>
> Do you know any good resources? Online books? Good archives?
> Anything?
>
> :-)
>
> -gus
You would do better to worry about the front end before you worry about the
backend, but if you insist, then http://www.forth.org/fig.html is the place
to start. http://www.forth.com is less useful.
David LeBlanc
Ah yes, thanks for reminding me. The Self project claimed to have gotten
Self to run in the mid 90's percentile of "C speed", largely by making as
many primatives as possible actual machine ops of the host processor - not
too good for portability. OTOH, Self has many of the complexities of Python,
and if this is true, this is blazing speed. For anyone that's interested,
there is still a Self website (and by darned, a new release this year!) at
http://research.sun.com/self/index.html and there are some good papers there
on their compiler techniques.
http://research.sun.com/self/release/optionalFiles.html offers the sources
to the Self VM (in C++ and "Sparc-asm")
Of course, some of the Self guys went on to another project at Sun: Java.
I've read somewhere that Java HotSpot JIT compiler tech came out of the Self
work (oops, there it is on one of the Self pages).
Actually, Java and this idea of hosting Python on Forth brings up an
interesting question: If Sun can't make a VM that will run everywhere, why
would a Forth based Python implementation do any better?
Greg Ewing
> * 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?
Leave it as an FPGA implementation and you can whip
out changes just as fast. (Well, faster than changing
silicon, anyway...)
--
Greg Ewing, Computer Science Dept,
University of Canterbury,
Christchurch, New Zealand
http://www.cosc.canterbury.ac.nz/~greg
Paul Foley
> On Wed, Jun 26, 2002 at 10:29:52AM +0000, Christopher Saunter wrote:
>> Dear All,
>>
>> I have seen the occasional post about creating a specific hardware 'Python
>> Processor', that could then be built and used in programmable logic or the
>> like (Valves, relays, core memory - Pythoniac ;-) - in other words, create
>> a processor that executes Python bytecode directly. There would be
>> various different reasons for doing this (the 'neat' factor etc...)
> One of the most effective optimizations for such a machine would be to
> support compact objects. The machine word would be somewhat larger than the
> actual address space. Let's say 40 bits. If the 4 high bits are 0 this is a
> reference to an object allocated somewhere in memory. If the high bits are
> not zero it means that the actual object is stored inside the register. You
It's usual to use the low bits for this purpose, rather than the high
bits. You can use at least 2 low bits for free, on ordinary 32 bit
hardware, if pointers are aligned to 32 bit boundaries anyway.
--
Majority, n.:
That quality that distinguishes a crime from a law.
(setq reply-to
(concatenate 'string "Paul Foley " "<mycroft" '(#\@) "actrix.gen.nz>"))
Oren Tirosh
> Compact Objects (Oren Tirosh)
> -------------------------------
> I like this suggestion, it is something I had been thinking about in a
> slightly different context, but not thought through.
Actually, I got the idea from an old Byte article about an interesting
processor called Rekursiv designed by the Glasgow-based audio company Linn.
This processor had hardware support for persistent objects and garbage
collection.
http://www.brouhaha.com/~eric/retrocomputing/rekursiv/rekursiv.txt
http://www.set-i.com/bruno/computing/sigarch.html
Oren
Gonçalo Rodrigues
>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
>
Completely OT but there is that J. Joyce line in Ulysses that goes like
Lazarus, come forth! And he came fifth and lost the job.
best,
Gonçalo Rodrigues
Steve Holden
news:mailman.1025206656...@python.org...
[...]
>
> 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).
>
Well, there was the English Electric KDF9, circa 1960. Even though it did
have instructions to load and store stack elements from/to memory, all
operations were performed on the hardware stack.
nothing-new-under-the-HP-ly y'rs - steve
Johannes Nix
> Ooh... from there I found:
>
> http://www-2.cs.cmu.edu/~koopman/stack_computers/index.html
>
In the early 80ties, the UCSD Pascal system was based on a virtual
stack machine, the P-Machine, resulting in a highly portable operating
system which was itself written in Pascal. I remember that in some
German computer magazine, a hardware implementation, the P-engine was
discussed.
I wonder if it would make sense to modify a Modula-3 compiler so that
the output runs on a hardware stack machine, and then implement
Python in Modula-3. Modula-3 is an interesting compiled,
strongly-typed language which has some important things in common with
Python. Because of the modularity and safety characteristics of the
language, this would be a very nice thing, I guess. For example, as
there exists automatic garbage collection, no reference counting would
be necessary.
Johannes
Armin Steinhoff
> Dear All,
>
> I have seen the occasional post about creating a specific hardware 'Python
> Processor', that could then be built and used in programmable logic or the
> like (Valves, relays, core memory - Pythoniac ;-) - in other words, create
> a processor that executes Python bytecode directly.
What about an implementation of the byte code processing in micro code for a
Transmeta processor?
Is it possible ??
Armin just-a-wild-idee :)