Pythoniac: Thoughts on a hardware Python processor

[Christopher Saunter]

Dear All,
	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