Forgive the stream of consciousness; I am not even close to what one would consider a thorough writer or really used to writing blogs in general, so this is mostly just a brain dump.

So this is quite a large learning project that will take some time and there is much to research and experiment, but there are three main parts that I'm working on in order (but still hacking around and building the bare framework with the others parts as I go...) :

-A Compiler that takes standard Python 2.7 code and compiles it to a format that the Apodora can use. Python has a very object oriented interpretation model. However, the Apodora doesn't actually follow the standard CPython implementation. This isn't as bad as it seems because the only impact a modified VM has is that C extensions simply won't be compatible anymore. No problem because on the Apodora, they aren't needed and is totally incompatible anyway. Now the inner machinations of the CPU are an enigma to the casual programmer. But it's still just executing pure Python code, just in a different, streamlined way.

-A Simulator that operates as close as possible to the actual hardware implementation. It essentially shuffles the stack, block, and list data around in the same way as the hardware. This way different memory management algorithms can be test. It will be used to test the output of the Compiler and help verify design and feasibility of the CPU's execution model. Maybe an basic IDE like in the future.

-The actual Apodora hardware will be a small FPGA (hopefully an MOSIC ASIC conversion or something if there's enough interest, but I like the idea of a hackable FPGA for use as a miniature FPGA board). The basic hardware will be a 48 (or maybe more) pin DIP, breadboard-able PCB with an 8 MB Pseudo SRAM (for the prototype, eventually SDRAM support for at least useful 32-bit support), configuration circuit, power, uSB, etc.

Here is an awesome breakdown of CPython black magic:

This is just a rough outline of a project that will take quite a while. I'm still building the core execution model, as it it not the same as the standard CPython interpreter at all... I will be documenting the core as it develops. So here's the rough, ephemeral brain dump of the central execution model:

The Apodora microcontroller is an FPGA CPU coupled to an SRAM and is basically a stack machine. It has 2 32-bit stacks; a working stack and a block stack. The working stack is stored in the faster M4K memory blocks inside the FPGA. The block stack is made of ApoBlock objects stored in SRAM. This block contains the code, return value, flags, references to globals & local variable names and values for a block. The blocks include functions, for & while loops, try blocks, etc. When a block is executed, they are pushed onto a block M4K stack. From there, they are executed and if a block calls/runs a function/loop, the new block is pushed on the block M4K stack and run. Rinse, repeat. Then for a return/break, the block access the lower one, dumps the return value and pops itself from the stack.

So that's the basic idea. The major hurdle is going to be a lot of memory management, pipelineing and optimization like how the blocks are loaded to the M4K blocks during each call. It'd be smart to do a parallel (M4K is dual-port) look ahead in the top block's code while it's executing and cache blocks it may jump to. However, that may be pushed to the side for now..