ZOG: GCC C/C++ Project in Google Code (propeller-zpu-vm)

David Betz · 2011-02-16 23:14

I've been working with jazzed and Heater on a version of Heater's ZOG virtual machine. Originally this was a version for the Parallax C3 board but it has expanded to include support for jazzed's SDRAM board for the Propeller Platform and also Dr_Acula's Dracblade board. It would be relatively easy to expand it to support other external memory interfaces as well as small programs running directly from hub memory.

I've recently created a project for this in Google Code. This will allow us to continue developing it using the SVN version control system and will also make the code available to everyone.

For those who haven't been following ZOG development here is a summary of what ZOG provides in Heater's words:

Heater. wrote:

Zog enables running C and C++ programs compiled with GCC, the GNU Compiler Collection, on the Propeller multi-core micro-controller from Parallax Inc.

There is no Propeller architecture target for GCC. To overcome this Zog provides a virtual machine implementing the instruction set of a CPU architecture for which there is a GCC target, namely the Zylin CPU (ZPU) from Zylin Consulting. The ZPU architecture provides a 32-bit processor with a very minimal instruction set, each ZPU instruction is a single byte, it is therefore a perfect candidate for emulation on the Propeller as the entire bytecode interpreter can be implemented in PASM within a single COG. Hence the name ZOG, ZPU in a Cog. Further, as each instruction is a single byte the ZPU is a good match for Propeller systems having external RAM or ROM that is connected over an 8 bit data bus.

Zog can be used to run compiled C, C++ binaries on a bare Propeller where the binaries are located within the Propellers HUB RAM space. This limits the binary size to a little less than 32KBytes. Fortunately there are Propeller systems available that provide memory external to the Propeller chip and Zog can also make use of such memory expansion from which it can execute much larger binaries and deal with much larger data sets. Up to 32MBytes currently!

Features:

Can run programs with up to 1MB of code and 64K of data on the Parallax C3
Can run programs with up to 32MB of code/data on the Gadget Gangster SDRAM board
Can run programs with up to 512K of code/data on the Dracblade

Loader features:

Can load compiled ZOG programs through a serial connection directly to Propeller external memory
Can load compiled ZOG programs to an SD card attached to the Propeller board
Can write a bootloader to EEPROM to facilitate serial downloads
Can write a bootloader to EEPROM to boot ZOG programs from an SD card
Can write a bootloader to EEPROM to boot a ZOG program from SPI flash on the Parallax C3

You can find ZOG in Google Code here:

http://code.google.com/p/propeller-zpu-vm/

Anyone can download the sources but you need to create a free Google account to commit changes. The PC-based loader can be built under Linux or under Windows using Cygwin. Building the Spin code requires the use of Brad's Spin Tool (BST, BSTC). I also have a project that will allow zogload, the PC-based loader program, to be built under Microsoft Visual C++.

The version of GCC that generates code for the ZPU can be found here:

http://opensource.zylin.com/zpudownload.html

The PDF for the manual is attached to this message.

David Betz · 2011-02-17 04:29

I've attached a PDF file containing the ZOG manual to the top message of this thread.

jazzed · 2011-02-17 06:50

Thanks for committing your tree to google code.

David Betz · 2011-03-09 15:48

Suddenly I'm having trouble with the ZPU tools. I have a simple basic interpreter called xbasic that I'm trying to get running on the C3 and I'm starting to have trouble with sign extension of signed bytes. I have no idea why this is happening because this same code ran fine a while ago. Here is a simplified version of what I'm doing:

#include <stdint.h>

int8_t index;

uint8_t code[1] = { 0xff };
uint8_t *pc = code;

index = *(int8_t *)pc++;
printf("%d\n", index);

If I run this code the printf ends up printing 255 when I expect it to print -1. Any idea why this might be happening? It seems like the int8_t variable "index" should be sign extended into an integer before being passed to printf but this doesn't seem to be happening.

David Betz · 2011-03-09 17:38

Okay, I'm going to answer my own question. I guess the answer is pretty obvious. It turns out that the ZPU tool chain defines char as unsigned by default. That means that the definition of int8_t from stdint.h was wrong.

I had:

typedef char int8_t;

when I should have had:

typedef signed char int8_t;

I guess I neglected to mention in my original post that I created the version of stdint.h that I've been using since none came with the ZPU tool chain. I guess I got that definition wrong. This is the first compiler I've ever seen that defined char as unsigned but I guess it's allowed by the ANSI standard.

Anyway, fixing this bug makes my VM work correctly.

Heater. · 2011-03-10 02:21

David,

Oh yes, signed/unsigned char has bitten me in the past. Turns out this is not so much a compiler issue as a platform issue. After all we are using GCC everywhere and it can change from platform to platform. From the book An Introduction to GCC - for the GNU compilers gcc and g++

"Most systems, including x86 GNU/Linux and Microsoft Windows, use signed char, but those based on PowerPC and ARM processors typically use unsigned char."

David Betz · 2011-03-10 03:32

Heater. wrote: »

David,

Oh yes, signed/unsigned char has bitten me in the past. Turns out this is not so much a compiler issue as a platform issue. After all we are using GCC everywhere and it can change from platform to platform. From the book An Introduction to GCC - for the GNU compilers gcc and g++

"Most systems, including x86 GNU/Linux and Microsoft Windows, use signed char, but those based on PowerPC and ARM processors typically use unsigned char."

I guess I never noticed this on the PowerPC. I stayed away from using the "signed" keyword for a while because I don't think it was in K&R C. I guess in the future I should always use it for char typedefs that required signed behavior.

David Betz · 2011-03-15 09:37

I'm trying to move the stack to hub memory while leaving code and data in external flash/SRAM. I've modified the push_tos and pop instructions to reference only hub memory. The normal read/write code has already been made to handle references to hub or external memory. This results in code that mostly works but fails in strange ways. For instance, drivers loaded into other COGs don't seem to work anymore. My question is, does the ZPU C compiler do anything with SP besides just use the value supplied by the startup code as the stack pointer? Does it ever reload SP with some other value?

Heater. · 2011-03-15 10:41

I don't thing GCC is doing anything odd with the stack pointer. At least I have never seen it with all the test programs I traced through when hunting for ZOG bugs.
Of course it probably does more than PUSH and POP values. The SP must be loaded when making calls to clear space for local variables.
The stack is also accessed by loads and stores so I hope the push/pops are actually going to the same locations as other memory read/writes.

David Betz · 2011-03-15 10:43

I think everything is going to the right place because I am able to run a simple program that flashes an LED on the C3 successfully. In fact, code that calls iprintf to print to either the serial port or a TV completes without crashing but no output appears on either the serial port or the TV suggesting that the drivers either weren't loaded successfully or aren't working for some reason.

Chris Micro · 2011-03-15 12:33

Hello together,

I follow the ZOG-Posts since a longer period. There is one idea which drives me since the beginning: Wouldn't it be easy to convert the ZPU in a multi-thread ( or pseudo multi core virtual machine )? I mean the ZPU is a stack based architecture, so one has simply to implement multiple stack pointers and switch for every thread between this pointers.
The result would be, that you can run more than one ZPU program in one COG.

David Betz · 2011-03-15 12:45

Chris Micro wrote: »

Hello together,

I follow the ZOG-Posts since a longer period. There is one idea which drives me since the beginning: Wouldn't it be easy to convert the ZPU in a multi-thread ( or pseudo multi core virtual machine )? I mean the ZPU is a stack based architecture, so one has simply to implement multiple stack pointers and switch for every thread between this pointers.
The result would be, that you can run more than one ZPU program in one COG.

Yes, that could certainly be done and would be interesting. I have to admit though that I'm having enough trouble getting a single thread working! :-)

Chris Micro · 2011-03-15 12:54

David Betz wrote: »

Yes, that could certainly be done and would be interesting. I have to admit though that I'm having enough trouble getting a single thread working! :-)

I surmised that. Often it takes more time to get things running than suspected at the beginning.
In the documentation I saw that only TV output is supported. I have only VGA displays.

BTW: is there a ZPU simulator for PC which has the same interfaces like ZOG so one can run the same binaries on PC as on a propeller board?

David Betz · 2011-03-15 12:57

I can add a VGA driver pretty easily. Steve (jazzed) has already ported a VGA driver to C. I just have to merge it into my ZOG library. I'll try to get to that soon.

Chris Micro · 2011-03-15 12:59

Quite nice. Good luck,

chris

ZOG: GCC C/C++ Project in Google Code (propeller-zpu-vm)

Comments