All the Zog interpreter variables have been overlaid against the init code thus saving 20-30 LONGs in Cog. There are now 42 LONGs free when built for using external memory.
Put back the fibo test source code that went missing in 1.2.
If this voting thing works as well as I would hope, which depends on us I guess, it would be great to be able to do a search for all the highest rated threads.
Then all those "classic" threads like Bill Henning's introduction of LMM or BradC's and Mica Dowty's USB threads or many others would be easy to get to. It would be a great way for people new to the Prop to find all kinds of interesting things you can do with a Propeller before you even know what you are looking for.
I was just now wondering why the fibo source had dropped off the Zog tree and was busy putting it back. The attached source generates the same binary.
Thanks for that.
I expect a long day of debugging today. I started using the hello.c program last night for debugging. It gets right up to launching main and stops. I have tools to figure out what's happening with the PASM, but some of the zpu instructions are a mystery to me right now Too bad I have to learn them to make more progress.
The following trace shows the instruction address fetch for executing hello.bin - the last column "D" result has the address.
Hello world
The meaning of life = 42
Hi
Zog say hello
0000000e
argc = 00000001
Address of argv[0] = 00003dbc
_hardware = 00000000
_cpu_config = 00000002
ZPU_ID = 0000000e
_use_syscall = 00000000
Please type 4 characters...
1234You typed...
1234
The following should be deadbeef
deadbeef
The following should be 00000009
00000009
The following should be 0001da31
FIBO using SdramCache is slower than VMCOG and Triblade,
but it crashes the same. At least the FIBO results are correct.
Is ZOG is running out of stack?
"Two wrongs don't make a right, but three rights make a left."
-Cosmo, Fairly Odd Parents
I'm not sure I have ever written a program that exits gracefully, in general they are not supposed to stop
The C run time supplied with zpu-gcc has the break point in it. Which seems quite reasonable to me in the absence of HALT. I guess as we don't have a break point debugger we can just treat it as "end of prog" and print something polite.
We have to tweak Zog to allow up to 32MB RAM. Currently addresses over 64K are mapped into HUB space.
I wasn't trying being critical of the way the program terminates. BREAKPOINT quickly took on the meaning "oops" and I didn't realize it had another context
I'll migrate to zog_v1_3 vintage at some point. I could try a file that "would likely remove" the 64KB restriction if you have one. The right thing to do is of course get hardware to you for development and as I've mentioned that's in process.
Meanwhile, I'm experimenting with different cache line sizes to check performance impact and may settle on something other than 32bytes. I should try xxtea and other programs as well.
To use up to 32MB RAM change the definition of vhub_end in zog.spin as so:
vhub_end long $01FFFFFF ' 32M - 1
That will allow access up to 32 MB of ext RAM whilst buggering up access to HUB RAM from C. But as we are not currently doing any of that who cares for now?
At least when I make that change here fibo still runs OK.
Speaking of "oops", we'll soon have uCLinux running on the Prop:)
I forgot to mention and perhaps you have spotted it already but it is necessary to change the constant zpu_memory_size in debug_zog.spin to use 32MB external RAM. This ends up getting used to set the initial value of the ZPU stack pointer.
I have used malloc from external memory, in one version of test_libzog where it put the FDX C++ object on the heap. malloc should work, after all iprintf uses it.
The only memory accesses in ZOG that get mapped to HUB RAM or I/O ports are read_long and write_long. They both check if the address is 64K and up and then branch off to do I/O or HUB access if so.
Look for:
read_long cmp address, word_mask wc 'FIXME this only allows 64K RAM
if_nc jmp #in_long
and similar for write_long.
That cmp will need to be changed to test against 32M instead of 64K
Sorry, forgot about that.
Then you might want to revisit those tests against vhub_end that get us into HUB RAM or just remove them.
We now have mostly functional 32MB Propeller programs
Changing those two word_mask comparisons to vhub_end did it - thanks. I assume something else depends on the resulting C state as just removing the check causes run-time failure.
Here's what I'm getting on the malloc business. No idea why 4MB+ fails. How big is an sbrk block? My malloc pointer is a char* and was getting null pointers without a cast before ... I'm getting lazy .
Malloc big buffer size: 256
Free big buffer.
...
Malloc big buffer size: 2097152
Free big buffer.
Malloc big buffer size: 4194304
Oops, malloc failed.
Malloc big buffer size: 8388608
Oops, malloc failed.
Malloc big buffer size: 16777216
Oops, malloc failed.
It makes sense, if that check is remove then you no longer get memory mapped I/O ports mapped in and iprintf etc stops working.
If you put _use_syscall = 1; at the beginning of main() then the C run time will use SYSCALL instead of memory mapped I/O ports which would no longer be needed.
"How big is an sbrk block?" - No idea I'm afraid.
Not sure why the lack of a cast would get you a NULL pointer. A compiler warning/error yes but...
I downloaded the Cygwin version of GCC ZPU toolchain and the 'include' directory seems to be empty. Where do I get the header files to go with the ZPU toolchain?
I have never tried the Cygwin version so I'm not sure I can be much help, I'll try and find time to set up a Windows box (We don't have any around here normally) and have a play.
Which "include" directory do you mean? And at what point is it missing?
I can see 21 include directories under my "toolchain"
Can you try a command like:
$ find -name include
and post the result?
I suspect the directory may be there but there is some include path not set up correctly.
I downloaded the Cygwin version of GCC ZPU toolchain and the 'include' directory seems to be empty. Where do I get the header files to go with the ZPU toolchain?
Hi David.
Yesterday I Installed Cygwin (with gcc-core developer tools), zpugcccygwin.tar.bz2, and zog on my netbook for a demo. I was able to build programs no problem. I suspect that any extra include files necessary are part of the gcc-core developer package, so you might want to install that.
I've attached a test_libzog.binary that you will need for 80MHz operation (change the name to test_libzog.bin after download). Heaters library is by default 104MHz. Other frequencies require another build - seems there should be a solution easier to customize.
Thanks for the 80mhz library. I have my program compiling and linking succcessfully. I'm wondering what library functions are available on the Propeller? Is there a header file that lists the low-level library functions like serial I/O, etc? I'd like to stay away from using stdio.h as much as possible so I want to use low level stuff to make it more likely that my program will actually fit in the 32k hub memory.
I'm also not entirely clear on how to go from a test.bin file to something that can be loaded and run on the Propeller. Is there an example of how to do this somewhere?
I don't understand it all either run_zog.spin is a bit of a mystery to me though it uses test_libzog.bin. In retrospect I'm not sure how test_libzog.bin is used exactly, but it is an output from the lib/Makefile.
I've been using debug_zog.spin as the top spin object. I build with "bstc -Ox debug_zog" for example. So for non XMM builds in debug_zog.spin I keep #define USE_HUB_MEMORY uncommented and change the file to load as defined for zpu_image which by default is fibo.bin. The image to load is built from one of the test subdirectories.
Maybe just try the debug_zog.spin route until heater can explain the rest.
Is it possible to load run_zog.spin into the Propeller Tool directly or must you use bstc? My guess is that something like bstc is necessary since the Propeller Tool doesn't understand the compile time conditionals that are in the zog spin code. Is that correct?
I guess what I'm really trying to understand is what runtime support is available to programs compiled to run under the ZOG VM? Can the programs use stdio with fopen/fclose/etc? What low-level I/O functions are available. It would be nice to have a simple list of the functions that are available in the runtime.
Fibo(20) now takes 3247ms with the 32MB SDRAM and 16KB cache. That's the best I can get without wandering into the replacement policy jungle. The cache line size is 128 bytes. I was able to squeeze in the 16K cache by recycling the driver space. The size of debug_zog.binary is now about 27K.
I experimented with a 4-way associative cache and got something working, but the performance was worse than straight direct mapped cache.
Is it possible to load run_zog.spin into the Propeller Tool directly or must you use bstc? My guess is that something like bstc is necessary since the Propeller Tool doesn't understand the compile time conditionals that are in the zog spin code. Is that correct?
The short answer is no.
The long answer is a very, very, very painful yes.
I guess what I'm really trying to understand is what runtime support is available to programs compiled to run under the ZOG VM? Can the programs use stdio with fopen/fclose/etc? What low-level I/O functions are available. It would be nice to have a simple list of the functions that are available in the runtime.
The short answer is no.
The long answer is a very, very, very painful yes.
That's what I thought. I've downloaded bstc and bstl and will use those for my ZOG work.
Are there any examples of relatively large programs ported to ZOG? I've only seen small demo programs so far. Any idea how big a program might fit into HUBmemory? The platform I'm coding for won't have a big attached SRAM.
I just downloaded Cygwin into Windows XP running in VirtualBox. Takes for ever if you install everything:) Compiling with install/bin/zpu-elf-gcc -phi hello.c just worked out of the box. You have yours working as well now so let's move on.
I'm wondering what library functions are available on the Propeller?
and
Can the programs use stdio with fopen/fclose/etc? What low-level I/O functions are available. It would be nice to have a simple list of the functions that are available in the runtime.
Good question, and one that I have not got to the bottom of yet.
Firstly IO.
Out of the box the ZPU tool chain, is set up to support some simple configurations of the ZPU processor core on an FPGA. It's only I/O is a console port which is memory mapped and a timer register. If you really want to get into this you would have to download the tool chain sources and have a look in the C run time support source.
Zog implements the console port by way of checking ZPU LOAD and STORE instructions. If the address is outside of the ZPU memory range then the access is passed along to the debug_zog COG to handle. Look for zog_mbox in the code. Currently debug_zog sees I/O commands for the console port address and uses FullDuplexSerial to do the work.
In this way things like printf work and we can get "Hello World" running.
There is an alternative I/O mechanism that uses the ZPU SYSCALL instruction. If you put "_use_syscall = 1;" in your program then then standard input and output are redirected to use SYSCALL. This mechanism seesm to be implemented in ZPU for use with the Java simulator. Zog passes all SYSCALLs out to debug_zog in much the same way as I/O operations.
The only syscalls implemented in debug_zog are SYS_read and SYS_write and they only work on the stdio file handles at the moment. Again, enough to get "Hello world" working. Perhaps the syscall mechanism will be expanded to use the SD card file system at some point.
So, given the fact that C programs under Zog have no file system yet most of the standard C library is there. Have a look in your install/zpu-elf/include/ directory to see what we have. I cannot guarantee how much of it is actually implemented though. For that we would have to look at the C libraries "newlib" and "libgloss" source.
If you want to get into floating point there is libm chock full of sin, cos, tan, etc. But warning, the resulting binaries will be huge and slow. I'm working on adding a floating point "coprocessor" cog which will improve that situation dramatically.
I'd like to stay away from using stdio.h as much as possible so I want to use low level stuff to make it more likely that my program will actually fit in the 32k hub memory.
Good plan, things like printf are rather huge (There is a smaller iprintf though and there is a print function that is small and works directly on the ZPU UART port). Have a look in hello.c for examples. You can slways read/write bytes directly to that UART prort address from your C code and build up your own mini I/O library. Taking things further one could add further IO ports to debug_zog and use them for whatever other device drivers you want.
I'm also not entirely clear on how to go from a test.bin file to something that can be loaded and run on the Propeller. Is there an example of how to do this somewhere?
debug_zog.spin is the top level object that starts up Zog and provides I/O for ZOG, in there you will see that the ZPU binary is included into the Spin using a "file" statement when running ZPU code from HUB memory. Of course one could hack that around to load the binary from an SD card file instead as is done when exeuting from external memory.
Are there any examples of relatively large programs ported to ZOG? I've only seen small demo programs so far. Any idea how big a program might fit into HUBmemory?
Not yet. At the moment in time I'm still amazed the thing works at all:) A minimal C program currently comes out at 3K bytes or so. I'm going to look into shrinking that. There is at least 1K of vector table that gets included with the run time that we don't use and should be removed.
I've been running programs with debug_zog that sit in 26K Bytes of HUB memory leaving 252 LONGs free. Just tweak the
"zpu_memory_size" constant.
General:
debug_zog as it's name suggests has grown as a tool to debug the interpreter, the external RAM, and C programs it runs. As a result it ends up providing the console I/O and even SD card support which is usefull for actual applications. It serves as an example of ZOG usage. It can of course be chopped down or extended as required for any particular application.
run_zog is something of an experiment at the moment. The aims here are:
1) Get Zog and C code running with minimal memory foot print for the Spin startup code and hence maximum HUB memory for C.
2) Optionally enable Zog to takeover the entire Propeller with no Spin code left at run time at all.
As such it has no I/O, it's just a loader. That means that any I/O, a serial port for example, has to be created in C. Enter libzog.
libzog is even more experimental and has the following ideas in mind:
1) Create C versions of things like FullDuplexSerial. That is use the PASM parts of existing objects, possibly adapted a little, and replace the Spin interfaces with C interfaces. This has been shown to be quite workable and FullDuplexSerial and VMCog have C wrappers.
2) libzog is an experiment in working with C++ under Zog. Which turns out is a good fit for makeing the equivalent of Spin objects.
3) libzog will grow to support Arduino programs.
4) Zog itself should be have a C++ wrapper so that it can be used from C++ programs. That is staring multiple interpreter instances as you do in Spin.
test_libzog is just a little test harness for the objects in libzog and is first program we have that runs with out any Spin code left in the Prop.
I think for any real application Zog will need access to Prop features like waitxx, DIRA, INA, OUT, CNT, LOCKS etc etc. I want to put as much of that as possible into the interpreter COG. Space is getting tight.
If you have a pressing need for anything let us know and I'll move it up the priority list.
Comments
fibo(24) = 046368 (19072ms)
fibo(25) = 075025 (30859ms)
fibo(26) = 121393 (08971ms)
Yep, the count rolls over.
I was just now wondering why the fibo source had dropped off the Zog tree and was busy putting it back. The attached source generates the same binary.
Did you notice this thread now has a 5 star rating? I wonder how that happened?:)
No functional changes.
All the Zog interpreter variables have been overlaid against the init code thus saving 20-30 LONGs in Cog. There are now 42 LONGs free when built for using external memory.
Put back the fibo test source code that went missing in 1.2.
I notice this thread now has two 5 star votes:)
If this voting thing works as well as I would hope, which depends on us I guess, it would be great to be able to do a search for all the highest rated threads.
Then all those "classic" threads like Bill Henning's introduction of LMM or BradC's and Mica Dowty's USB threads or many others would be easy to get to. It would be a great way for people new to the Prop to find all kinds of interesting things you can do with a Propeller before you even know what you are looking for.
I expect a long day of debugging today. I started using the hello.c program last night for debugging. It gets right up to launching main and stops. I have tools to figure out what's happening with the PASM, but some of the zpu instructions are a mystery to me right now
The following trace shows the instruction address fetch for executing hello.bin - the last column "D" result has the address.
I'll be getting more GadgetGangster hardware today. I'll put that and an SDRAM board in the mail to you soon.
--Steve
I'm a bit busy to concentrate on that post just now.
Have you tried setting #define SINGLE_STEP ?
With that and the hello.lst file in hand you can follow execution all the way to main fairly easily and see every op code it picks up.
That's about all I had to use.
I guess I would have noticed that eventually.
But FIBO fails. :mad: ... more work to do.
FIBO using SdramCache is slower than VMCOG and Triblade,
but it crashes the same. At least the FIBO results are correct.
Is ZOG is running out of stack?
"Two wrongs don't make a right, but three rights make a left."
-Cosmo, Fairly Odd Parents
That's no crash. It only goes up to fibo(26). When main exits in eventually halts with a breakpoint instruction.
Now is this the old VMCOG and 20 pages? What about other page settings?
Wow. Ok. Would be nice to have a graceful exit
That's using SDRAM without VMCOG, a 16K cache, and 32 byte cache line.
I'm not sure I have ever written a program that exits gracefully, in general they are not supposed to stop
The C run time supplied with zpu-gcc has the break point in it. Which seems quite reasonable to me in the absence of HALT. I guess as we don't have a break point debugger we can just treat it as "end of prog" and print something polite.
We have to tweak Zog to allow up to 32MB RAM. Currently addresses over 64K are mapped into HUB space.
I'll migrate to zog_v1_3 vintage at some point. I could try a file that "would likely remove" the 64KB restriction if you have one. The right thing to do is of course get hardware to you for development and as I've mentioned that's in process.
Meanwhile, I'm experimenting with different cache line sizes to check performance impact and may settle on something other than 32bytes. I should try xxtea and other programs as well.
Cheers.
--Steve
To use up to 32MB RAM change the definition of vhub_end in zog.spin as so:
That will allow access up to 32 MB of ext RAM whilst buggering up access to HUB RAM from C. But as we are not currently doing any of that who cares for now?
At least when I make that change here fibo still runs OK.
Speaking of "oops", we'll soon have uCLinux running on the Prop:)
Changing vhub_end seems to work. Thanks.
"But that's impossible."
I'm glad you said so. Now I know it's as good as done:)
I forgot to mention and perhaps you have spotted it already but it is necessary to change the constant zpu_memory_size in debug_zog.spin to use 32MB external RAM. This ends up getting used to set the initial value of the ZPU stack pointer.
zpu_memory_size = (1 << 16) 'This works
zpu_memory_size = (1 << 17) 'This fails
--Steve
I have used malloc from external memory, in one version of test_libzog where it put the FDX C++ object on the heap. malloc should work, after all iprintf uses it.
The only memory accesses in ZOG that get mapped to HUB RAM or I/O ports are read_long and write_long. They both check if the address is 64K and up and then branch off to do I/O or HUB access if so.
Look for:
read_long cmp address, word_mask wc 'FIXME this only allows 64K RAM if_nc jmp #in_longand similar for write_long.
That cmp will need to be changed to test against 32M instead of 64K
Sorry, forgot about that.
Then you might want to revisit those tests against vhub_end that get us into HUB RAM or just remove them.
Changing those two word_mask comparisons to vhub_end did it - thanks. I assume something else depends on the resulting C state as just removing the check causes run-time failure.
Here's what I'm getting on the malloc business. No idea why 4MB+ fails. How big is an sbrk block? My malloc pointer is a char* and was getting null pointers without a cast before ... I'm getting lazy
void malloctest(int size) { char* mp; printf("Malloc big buffer size: %d\r\n",size); mp = (char*)malloc(size); if(mp != 0) { printf("Free big buffer.\r\n"); free(mp); } else { printf("Oops, malloc failed.\r\n"); } } // called with: for(n = 8; n < 25; n++) malloctest(1<<n);I'll add some buffer test mashup code tomorrow and see what happens.
The latest uClinux distribution is > 300MB. It took over half an hour to get the package and archive manager is *still* opening it.
Guess I should post the debug_zog and zog spin files. I'll wait on posting the SDRAM drivers until later.
Cheers.
--Steve
It makes sense, if that check is remove then you no longer get memory mapped I/O ports mapped in and iprintf etc stops working.
If you put _use_syscall = 1; at the beginning of main() then the C run time will use SYSCALL instead of memory mapped I/O ports which would no longer be needed.
"How big is an sbrk block?" - No idea I'm afraid.
Not sure why the lack of a cast would get you a NULL pointer. A compiler warning/error yes but...
Thanks,
David Betz
I have never tried the Cygwin version so I'm not sure I can be much help, I'll try and find time to set up a Windows box (We don't have any around here normally) and have a play.
Which "include" directory do you mean? And at what point is it missing?
I can see 21 include directories under my "toolchain"
Can you try a command like:
$ find -name include
and post the result?
I suspect the directory may be there but there is some include path not set up correctly.
Here is what I have:
Yesterday I Installed Cygwin (with gcc-core developer tools), zpugcccygwin.tar.bz2, and zog on my netbook for a demo. I was able to build programs no problem. I suspect that any extra include files necessary are part of the gcc-core developer package, so you might want to install that.
I've attached a test_libzog.binary that you will need for 80MHz operation (change the name to test_libzog.bin after download). Heaters library is by default 104MHz. Other frequencies require another build - seems there should be a solution easier to customize.
--Steve
I'm also not entirely clear on how to go from a test.bin file to something that can be loaded and run on the Propeller. Is there an example of how to do this somewhere?
Thanks,
David
I've been using debug_zog.spin as the top spin object. I build with "bstc -Ox debug_zog" for example. So for non XMM builds in debug_zog.spin I keep #define USE_HUB_MEMORY uncommented and change the file to load as defined for zpu_image which by default is fibo.bin. The image to load is built from one of the test subdirectories.
Maybe just try the debug_zog.spin route until heater can explain the rest.
--Steve
I guess what I'm really trying to understand is what runtime support is available to programs compiled to run under the ZOG VM? Can the programs use stdio with fopen/fclose/etc? What low-level I/O functions are available. It would be nice to have a simple list of the functions that are available in the runtime.
I experimented with a 4-way associative cache and got something working, but the performance was worse than straight direct mapped cache.
I'll focus on malloc and other testing now .....
@David, Heater must be on holiday.
The short answer is no.
The long answer is a very, very, very painful yes.
It would best for Heater to answer these.
--Steve
That's what I thought. I've downloaded bstc and bstl and will use those for my ZOG work.
Are there any examples of relatively large programs ported to ZOG? I've only seen small demo programs so far. Any idea how big a program might fit into HUBmemory? The platform I'm coding for won't have a big attached SRAM.
I just downloaded Cygwin into Windows XP running in VirtualBox. Takes for ever if you install everything:) Compiling with install/bin/zpu-elf-gcc -phi hello.c just worked out of the box. You have yours working as well now so let's move on.
and
Good question, and one that I have not got to the bottom of yet.
Firstly IO.
Out of the box the ZPU tool chain, is set up to support some simple configurations of the ZPU processor core on an FPGA. It's only I/O is a console port which is memory mapped and a timer register. If you really want to get into this you would have to download the tool chain sources and have a look in the C run time support source.
Zog implements the console port by way of checking ZPU LOAD and STORE instructions. If the address is outside of the ZPU memory range then the access is passed along to the debug_zog COG to handle. Look for zog_mbox in the code. Currently debug_zog sees I/O commands for the console port address and uses FullDuplexSerial to do the work.
In this way things like printf work and we can get "Hello World" running.
There is an alternative I/O mechanism that uses the ZPU SYSCALL instruction. If you put "_use_syscall = 1;" in your program then then standard input and output are redirected to use SYSCALL. This mechanism seesm to be implemented in ZPU for use with the Java simulator. Zog passes all SYSCALLs out to debug_zog in much the same way as I/O operations.
The only syscalls implemented in debug_zog are SYS_read and SYS_write and they only work on the stdio file handles at the moment. Again, enough to get "Hello world" working. Perhaps the syscall mechanism will be expanded to use the SD card file system at some point.
So, given the fact that C programs under Zog have no file system yet most of the standard C library is there. Have a look in your install/zpu-elf/include/ directory to see what we have. I cannot guarantee how much of it is actually implemented though. For that we would have to look at the C libraries "newlib" and "libgloss" source.
If you want to get into floating point there is libm chock full of sin, cos, tan, etc. But warning, the resulting binaries will be huge and slow. I'm working on adding a floating point "coprocessor" cog which will improve that situation dramatically.
Good plan, things like printf are rather huge (There is a smaller iprintf though and there is a print function that is small and works directly on the ZPU UART port). Have a look in hello.c for examples. You can slways read/write bytes directly to that UART prort address from your C code and build up your own mini I/O library. Taking things further one could add further IO ports to debug_zog and use them for whatever other device drivers you want.
debug_zog.spin is the top level object that starts up Zog and provides I/O for ZOG, in there you will see that the ZPU binary is included into the Spin using a "file" statement when running ZPU code from HUB memory. Of course one could hack that around to load the binary from an SD card file instead as is done when exeuting from external memory.
Not yet. At the moment in time I'm still amazed the thing works at all:) A minimal C program currently comes out at 3K bytes or so. I'm going to look into shrinking that. There is at least 1K of vector table that gets included with the run time that we don't use and should be removed.
I've been running programs with debug_zog that sit in 26K Bytes of HUB memory leaving 252 LONGs free. Just tweak the
"zpu_memory_size" constant.
General:
debug_zog as it's name suggests has grown as a tool to debug the interpreter, the external RAM, and C programs it runs. As a result it ends up providing the console I/O and even SD card support which is usefull for actual applications. It serves as an example of ZOG usage. It can of course be chopped down or extended as required for any particular application.
run_zog is something of an experiment at the moment. The aims here are:
1) Get Zog and C code running with minimal memory foot print for the Spin startup code and hence maximum HUB memory for C.
2) Optionally enable Zog to takeover the entire Propeller with no Spin code left at run time at all.
As such it has no I/O, it's just a loader. That means that any I/O, a serial port for example, has to be created in C. Enter libzog.
libzog is even more experimental and has the following ideas in mind:
1) Create C versions of things like FullDuplexSerial. That is use the PASM parts of existing objects, possibly adapted a little, and replace the Spin interfaces with C interfaces. This has been shown to be quite workable and FullDuplexSerial and VMCog have C wrappers.
2) libzog is an experiment in working with C++ under Zog. Which turns out is a good fit for makeing the equivalent of Spin objects.
3) libzog will grow to support Arduino programs.
4) Zog itself should be have a C++ wrapper so that it can be used from C++ programs. That is staring multiple interpreter instances as you do in Spin.
test_libzog is just a little test harness for the objects in libzog and is first program we have that runs with out any Spin code left in the Prop.
I think for any real application Zog will need access to Prop features like waitxx, DIRA, INA, OUT, CNT, LOCKS etc etc. I want to put as much of that as possible into the interpreter COG. Space is getting tight.
If you have a pressing need for anything let us know and I'll move it up the priority list.