The simple test.bin file included just prints "0000000C" which is not much but is the correct result for it's unsigned modulus operation the failure of which is the cause of a great deal of head scratching and these changes.
The single step register dump has been changed to print a trace that is easily diff'able with that of ZPU in C and the real ZPU VHDL run under GHDL.
Over many thousands of instructions executions they match perfectly so far.
Time for more advanced C tests, VMCOG and external memory.
I'm almost tempted to call this version 1.0.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Bill: "family-napped", How much do they want for us to get you back again. We could chip in together[noparse]:)[/noparse]
ZOG v0.12 is attached to the first post. This one now works!!!
That is after much futzing around comparing trace outputs with the real ZPU in VHDL they do the same for many 10s of thousands of cycles[noparse]:)[/noparse]
Zog now runs through the old dhrystone benchmark correctly through to the end. dhrystone is currently the default test.bin that it runs and the dhrystone code is included in the test directory.
I don't have the timer working yet so no DMIPS figure is available. 5000 runs through dhrystone takes about 10 seconds. Anyone familiar with dhrystone have a feel for what that compares with?
There is some scope for further optimization, inlining read/write_word, inlining mul/dev/mod code etc. Handling I/O outside of the memory space fetch and so on.
Changes in v0.12 were:
The ZPU_EMULATE op now works. If it's ever needed.
Fixed MOD and DIV instructions.
Inlined read/write_byte
read/write_word are EMULATED for now as their endiannes is not right yet.
ZPU memory is 20K bytes (Until we put SD and VM COG back in)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
LOL... I am afraid the family considers me to be a very valuable asset... right now I am helping my father in law deal with realtors, and finalizing selling a condo I own.
I've almost finished the tests I needed to do on PropCade before sending in for the revised prototype; and I've started building another batch of boards for a client.
Dhrystone: I like! We can compare performance of ZOG from hub, ZOG from VMCOG etc [noparse]:)[/noparse]
VMCOG is very close to being usable by ZOG; it now pages in the working-set number of pages on startup. I may even have enough longs free to enable a 192KB VMCOG (six SPI ram's) on PropCade (if I use 1KB pages).
Sadly I have no timer setup to get a result out of Dhrystone. I'm just glad it runs at all. It was giving me a real headache. Not sure it will even report less than one MIP. Currently Zog is executing about 640K instructions per second. Seems to be about one third the speed of Spin on simple loops full of multiplies and divides.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
heater said...
Sadly I have no timer setup to get a result out of Dhrystone. I'm just glad it runs at all. It was giving me a real headache. Not sure it will even report less than one MIP. Currently Zog is executing about 640K instructions per second. Seems to be about one third the speed of Spin on simple loops full of multiplies and divides.
BUT I have just recompiled my little "loop full of muls and divs" test with optimizations wound up to -O3 and what do you know? The execution time has dropped from 18 seconds to about 6. That would make it about the same speed as Spin perhaps even a tad quicker!
Now GCC is a bit sneaky and if you are not careful it will optimize away any code whose result is not used. Initially it cheerfully removed all the muls and divs and produced an execution time of 2 seconds. If it was a bit smarter it would have removed the loop altogether.
To get round this I now return a result from main() and can see in the list file that muls and divs are indeed still there.
Here is the mul div code in C:
int main()
{
int a, b, c, d;
print ("Start\n");
for (int i=0; i < 100000; i++)
{
a = a * b;
if (d == 0)
d++;
c = c / d;
a++;
b++;
c++;
d++;
}
print ("End\n");
return (a+b+c+d);
}
and here it is in Spin:
PRI muldiv | i, a, b, c, d
UART.str(string("Start"))
crlf
repeat i from 0 to 99999
a := a * b
if d == 0
d++
c := c / d
a++
b++
c++
d++
UART.str(string("End"))
crlf
With a bit of tweaking Zog could be faster than Spin[noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
By the way. If I'm counting correctly Zog takes 61 bytes for that main() and Spin takes 74 for the muldiv. I think we are doing very well[noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
K2: Thank you. I always need a little encouragement.
I woke up this morning with some wild ideas.
1) I want to replace the Spin interpreter with Zog.
It has the speed and small code size to do the same job except in C. I'd like to be able to get Zog started in a COG and then stop and free up the original Spin COG. Most of the stuff in that original Spin COG is start-up and debug which we don't need. Then there is the I/O via UART which a bare bones program running Spin does not have anyway. All of the HUB RAM should be turned over to Zog usage.
2) To do the same job as Spin, Zog would need a way to more directly access Prop features, pins, timers, locks etc.
Importantly it needs a way to be able to start (and stop) COGs with blobs of PASM.
3) There should be a way to start new instances of the ZOG interpreter in further COGs as Spin can start new instances of Spin.
They would share the same dispatch table which would be relocated to a fixed address somewhere in high HUB memory (Zog stack would be placed below that.)
4) I'd like to replace the object nature of Spin with real C++ objects.
I know we can compile C++ for Zog I just haven't checked how well it runs yet.
5) To make all of this fly would require recoding Spin objects, UART, tv, vga, etc etc ect in C for Zog.
Basically what I'm looking at is a completely C (C++) based Propeller!
In fact I might be so bold as to say that Parallax should stop doing what ever it is they have planned for their "not" C language implementation for the Prop and proceed to do the above[noparse]:)[/noparse]
In fact I would now suggest putting a ZPU interpreter into the Prop II ROM with an option to have it started at boot up instead of Spin!
See how crazy I am when I'm half asleep. When I have flushed the dreams out of my head with a few cups of coffee I might start to realize how infeasible this is.
On the other hand...Bill seems to want to be heading this way with Largos, about which I know almost nothing so far.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I like the idea of running a ZOG Prop, however I'd do things a bit differently than you are suggesting in your early morning email.
- Use a 64KB eeprom and/or a uSD card
With this approach, the first 32KB holds the ZOG kernel, system libraries, and a kernel/file system buffer area - which is extremely similar to the Largos memory map.
Here is the initial memory map:
$0000-$01FF - reserved, will talk about later, Largos uses it, and it holds important system vectors etc
$0200-$09FF - initial ZOG image, padded out to full 2KB
$0A00-$0AFF - syscall and syslib vectors, points to one of 128 functions, later can grow to 256 functions or even 512
$0B00-$0FFF - syslib, written in ZOG - things like i2c read code, cognew, stdio, SPI read/write code,
$1000-$7FFF - user application space / VMCOG working set when using VM
The initial 32KB of the eeprom holds the above 4KB image (later could be 8KB with full Largos) - the rest of the 32KB holds useful cog drivers, and loadable libraries.
The upper 32KB holds the user application, which saves much memory by using drivers in the first 32KB, and by using the standard system services.
This way, the ZOG user code can do something like:
cog = icognew(i2caddress,&par);
which loads a driver cog into the 2K cog buffer, then launches it.
cog = icognew(zogaddress,&par);
launches a new ZOG interpreter, pointing at code to execute, and
cog = icognew(fasterspin,&par);
could use Cluso's tweaked faster Spin interpreter, or a version modified for VMCOG (thanks for the correction guys!)
The 'i' prefix to cognew means use the version that loads the image from eeprom via i2c into the shared cog buffer.
Adding the rest of prop features would be easy - just add them to syslib, and use the syscall escape hatch to implement them. IMHO, there is no need to implement waitvid, as ZOG would not be fast enough to write video drivers in.
******* PLEASE DO NOT USE C++ *********
C++ makes much heavier use of the stack, and indirection tables - not to mention all the hidden new / delete's!
Not only would this chew up memory much faster (a big concern with a hub-only "small" model ZOG), but it would significantly reduce execution speed.
Stick to ANSII C, and instead of objects, have nice libraries - that is the plan for Largos.
Recoding the objects would not be too bad, as only the spin code would need modifying; the underlying PASM code would be used as-is.
There is no need to replace the spin interpreter in the ROM, doing it like I suggest above is easy enough [noparse]:)[/noparse]
I'd rather Parallax spent the roughly 50k they would need to make a new rom on getting P1.5 out... besides, doing it this way allows changing the ZOG interpreter to be even more efficient (or customized) over time.
oh - and placing the low-level readblock/writeblock code for fsrw into the system library is a big win... if a C version of FAT is compiled, it can be run under VMCOG, with unused file system code not taking up space in the hub until needed...
Same with TCP/IP - only code being used would be in the working set.
Wow Bill, a lot to think about there. I was only dreaming, especially the part about the ZPU in ROM (Mind you the more I think about it the more I like the idea for Prop II. A new interpreter for C, not necessarily for ZPU, or a souped up version of the Spin interpreter that will handle both. After all the dispatch table can go in the ROM as well to make some room.)
Anyway the general dream still holds, minimize the amount of Spin required to get into the C environment hopefully bootstrapping into C and discarding the Spin altogether. Isn't that what you are up to with Largos?
Re: C++, I understand your concerns about the overheads of C++ and the need for a memory allocator to deal with all the new/deletes, or the huge stack, or the vtables.
But actually none of that is necessary. C++ is just C with more rope to hang yourself with[noparse]:)[/noparse]
If you don't use new/delete you don't need a heap manager.
If you don't declare objects on the stack you don't need a huge stack.
If you don't use inheritance and polymorphism etc then you don't have vtables.
So which part of the C++ rope might we actually use? What's the point you might ask?
Well, it occurs to me that you can use objects in C++ in much the same limited way as objects in Spin. They are static, they have no inheritance etc. In fact pretty much all they do is allow for multiple instances of the same object to have their own data whilst sharing the same code. As a bonus they provide data hiding, private methods and the possibility to have many functions/variables in you code that have the same name. Objects provide name spaces.
This can be done in C++ with no overheads over C.
Consider this, if you want two UART objects what can you do?.
1) Cut and paste the code, have two copies, change the names used in one to avoid name clashes.
2) Use one copy of the code and have two copies of the data structures required. The UART code now needs a pointer parameter to each method so that each call will access the correct UART.
3) Put the UART code in a C++ class and instantiate two UART objects. This basically does what you do manually in C but C++ does the pointer messing for you.
solution 3) is the same size code as doing it in C and is easier to read as a bonus.
A concrete example: Here are C function calls to turn a LEDs on/off with an object selector pointer parameter together with the ASM it generates:
on(&led1);
5b4: 99 im 25
5b5: bc im 60
5b6: 51 storesp 4
5b7: ff im -1
5b8: ab im 43
5b9: 3f callpcrel
off(&led2);
5ba: 99 im 25
5bb: c0 im -64
5bc: 51 storesp 4
5bd: ff im -1
5be: bc im 60
5bf: 3f callpcrel
Here the equivalent C++ method calls to objects of a Led class:
led1.on();
56c: 99 im 25
56d: bc im 60
56e: 51 storesp 4
56f: 80 im 0
570: c8 im -56
571: 3f callpcrel
led2.off();
572: 99 im 25
573: c0 im -64
574: 51 storesp 4
575: ac im 44
576: 3f callpcrel
Well, what do we know? The C++ version is smaller!!
(Not sure why there is that extra IM 0 in there though)
The fully built binary is exactly the same size in straight C or using a class. See attachment.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Jazzed, what do you mean?
The working version of Zog is in the first post of this thread. Sorry if I did not make that clear.
The working version of Cluso's Spin interpreter is just where he says it is,
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
heater said...
Jazzed, what do you mean?
The working version of Zog is in the first post of this thread. Sorry if I did not make that clear.
The working version of Cluso's Spin interpreter is just where he says it is,
Zog seems to work in some of my tests. However, I've never seen a working version of the cluso interpreter.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
May the road rise to meet you; may the sun shine on your back.
May you create something useful, even if it's just a hack.
I have been playing and I'm very interested in these results since I'm a GNU fan.
I just haven't had time recently. I'll have more time in June. I'm "swamped" right now.
I've been waiting for cluso's fix he keeps referring to in other threads. Until that happens, it's broken.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
May the road rise to meet you; may the sun shine on your back.
May you create something useful, even if it's just a hack.
jazzed: Sorry, noone seemed interested so I haven't bothered to find the bug that I introduced near the end of my search for the ultimate. IIRC there were versions that worked posted on the thread. I have a few other things to do then I will debug or revert to a working version.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
ZOG_SMALL is a compact version of ZOG that has it's dispatch table in COG.
To make this possible a lot of op codes have been implemented using the ZPU's EMULATE instruction rather than being done in PASM.
The result is of course much slower than ZOG but there is still 160 LONGs left in the COG. So with some profiling we can find out which ZPU ops it is useful to put back into PASM.
What's the point? Well, just an experiment and I'd like to have a Spin interpreter style binary blob that can be thrown at a COG without having to worry where the dispatch table is. Plus it save HUB space.
As this is just an experiment at the moment I attach it here for comment rather than the first post.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Hmm... Gcc generates pretty damn good quality code for C++ !
Better than I expected.
As you may have noticed in my VMCOG thread, v0.92 now works... I have a 64KB VM running on PropCade!
All you really need is two 23K256 chips, and a minor change to BSTART to change how you select between the two chips - and you can start running 64KB ZOG programs!
That would help test VMCOG immensely...
heater said...
Wow Bill, a lot to think about there. I was only dreaming, especially the part about the ZPU in ROM (Mind you the more I think about it the more I like the idea for Prop II. A new interpreter for C, not necessarily for ZPU, or a souped up version of the Spin interpreter that will handle both. After all the dispatch table can go in the ROM as well to make some room.)
At this simple level you need at least a pointer to distinguish between objects of the same class. In C you do it manually with a pointer. In C++ the pointer gets hidden from you. The mechanism is the same. As you see in the asm output. Admittedly I have not looked at any other C++ compilers output to see what they get up to.
I'm sure when you get into inheritance and vtables things look a lot uglier[noparse]:)[/noparse]
OK, I'll try and get some 23K256 from Farnell here in Finland. They can bolt onto my TriBlade blade #3. Until then I'll try and find time to integrate VMCog using only HUB RAM.
Would I be wasting my time if I ordered 8 or 16? How many will VMCog handle ultimately?. I can't put in an order for just 2.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Last time I looked at such equivalent code, the C++ code was about 3x the size. That was what - five years ago?
VMCOG will handle:
1) up to 8 23K256's in single-channel mode (with 2KB pages)
2) up to 12 23K256's in four-bit wide mode (with 4KB pages)
You could easily modify BSTART/BREAD/BWRITE to use the parallel ram on TriBlade...
Also there is no reason one could not run two VMCOG's, with different mailboxes and pins on the same Prop... for two ZOG's.
heater said...
Bill, why are you surprised about GCC and C++?
At this simple level you need at least a pointer to distinguish between objects of the same class. In C you do it manually with a pointer. In C++ the pointer gets hidden from you. The mechanism is the same. As you see in the asm output. Admittedly I have not looked at any other C++ compilers output to see what they get up to.
I'm sure when you get into inheritance and vtables things look a lot uglier[noparse]:)[/noparse]
OK, I'll try and get some 23K256 from Farnell here in Finland. They can bolt onto my TriBlade blade #3. Until then I'll try and find time to integrate VMCog using only HUB RAM.
Would I be wasting my time if I ordered 8 or 16? How many will VMCog handle ultimately?. I can't put in an order for just 2.
I'm not going to dwell on the C++ thing. Life is complicated enough already.
I'll see what I can do with BSTART/BREAD/BWRITE on the TriBlade.
Two Zogs. I was thinking in terms of one Zog running from HUB RAM as a general replacement for Spin. It would provide the infrastructure for the second Zog running from ext RAM instead of Spin.
Now we could have three Zogs, two in ext RAM[noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I tried to make Bxxxx easy to write; it only takes two pieces of data - start of virtual page, and start of hub page (both 512 byte aligned)
Hmm... two props with parallel ram, one with serial... you could get ~8 ZOG's on a TriBlade!
heater said...
I'm not going to dwell on the C++ thing. Life is complicated enough already.
I'll see what I can do with BSTART/BREAD/BWRITE on the TriBlade.
Two Zogs. I was thinking in terms of one Zog running from HUB RAM as a general replacement for Spin. It would provide the infrastructure for the second Zog running from ext RAM instead of Spin.
Now we could have three Zogs, two in ext RAM[noparse]:)[/noparse]
Zog is now working with external RAM on the TriBlade (Blade #2) via Bill Hennings VMCog.
This means that Zog will now work with any external RAM system that VMCog supports.
Currently the external memory size is limited to 64K by the VMCog capabilities.
As built here it only uses 4 "resident" memory pages and is very slow running the RC4 crypto test. Changing to 16 pages brings the speed of this little test up a lot. (Factor 10).
So change "vm.start(@mailbox, $7000, 4)" to "vm.start(@mailbox, $7000, 16)".
Just now the ZPU image to be executed is pulled in from a "file" statement so be carefull with using too many pages as we need the HUB space. I'll have a go at getting binary images loaded from SD then mpre pages can be used and things will speed up for bigger programs.
Attached to first post.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Comments
Fixed endianness issue and ADDSP as per ZPU in C.
The simple test.bin file included just prints "0000000C" which is not much but is the correct result for it's unsigned modulus operation the failure of which is the cause of a great deal of head scratching and these changes.
The single step register dump has been changed to print a trace that is easily diff'able with that of ZPU in C and the real ZPU VHDL run under GHDL.
Over many thousands of instructions executions they match perfectly so far.
Time for more advanced C tests, VMCOG and external memory.
I'm almost tempted to call this version 1.0.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I should be more active on the forum later this week.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
ZOG v0.12 is attached to the first post. This one now works!!!
That is after much futzing around comparing trace outputs with the real ZPU in VHDL they do the same for many 10s of thousands of cycles[noparse]:)[/noparse]
Zog now runs through the old dhrystone benchmark correctly through to the end. dhrystone is currently the default test.bin that it runs and the dhrystone code is included in the test directory.
I don't have the timer working yet so no DMIPS figure is available. 5000 runs through dhrystone takes about 10 seconds. Anyone familiar with dhrystone have a feel for what that compares with?
There is some scope for further optimization, inlining read/write_word, inlining mul/dev/mod code etc. Handling I/O outside of the memory space fetch and so on.
Changes in v0.12 were:
The ZPU_EMULATE op now works. If it's ever needed.
Fixed MOD and DIV instructions.
Inlined read/write_byte
read/write_word are EMULATED for now as their endiannes is not right yet.
ZPU memory is 20K bytes (Until we put SD and VM COG back in)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
LOL... I am afraid the family considers me to be a very valuable asset... right now I am helping my father in law deal with realtors, and finalizing selling a condo I own.
I've almost finished the tests I needed to do on PropCade before sending in for the revised prototype; and I've started building another batch of boards for a client.
Dhrystone: I like! We can compare performance of ZOG from hub, ZOG from VMCOG etc [noparse]:)[/noparse]
VMCOG is very close to being usable by ZOG; it now pages in the working-set number of pages on startup. I may even have enough longs free to enable a 192KB VMCOG (six SPI ram's) on PropCade (if I use 1KB pages).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Or are mul/div implemented with zog byte codes?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
BUT I have just recompiled my little "loop full of muls and divs" test with optimizations wound up to -O3 and what do you know? The execution time has dropped from 18 seconds to about 6. That would make it about the same speed as Spin perhaps even a tad quicker!
Now GCC is a bit sneaky and if you are not careful it will optimize away any code whose result is not used. Initially it cheerfully removed all the muls and divs and produced an execution time of 2 seconds. If it was a bit smarter it would have removed the loop altogether.
To get round this I now return a result from main() and can see in the list file that muls and divs are indeed still there.
Here is the mul div code in C:
int main() { int a, b, c, d; print ("Start\n"); for (int i=0; i < 100000; i++) { a = a * b; if (d == 0) d++; c = c / d; a++; b++; c++; d++; } print ("End\n"); return (a+b+c+d); }and here it is in Spin:
PRI muldiv | i, a, b, c, d UART.str(string("Start")) crlf repeat i from 0 to 99999 a := a * b if d == 0 d++ c := c / d a++ b++ c++ d++ UART.str(string("End")) crlfWith a bit of tweaking Zog could be faster than Spin[noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
The early bird gets the worm but the second mouse gets the cheese.
I woke up this morning with some wild ideas.
1) I want to replace the Spin interpreter with Zog.
It has the speed and small code size to do the same job except in C. I'd like to be able to get Zog started in a COG and then stop and free up the original Spin COG. Most of the stuff in that original Spin COG is start-up and debug which we don't need. Then there is the I/O via UART which a bare bones program running Spin does not have anyway. All of the HUB RAM should be turned over to Zog usage.
2) To do the same job as Spin, Zog would need a way to more directly access Prop features, pins, timers, locks etc.
Importantly it needs a way to be able to start (and stop) COGs with blobs of PASM.
3) There should be a way to start new instances of the ZOG interpreter in further COGs as Spin can start new instances of Spin.
They would share the same dispatch table which would be relocated to a fixed address somewhere in high HUB memory (Zog stack would be placed below that.)
4) I'd like to replace the object nature of Spin with real C++ objects.
I know we can compile C++ for Zog I just haven't checked how well it runs yet.
5) To make all of this fly would require recoding Spin objects, UART, tv, vga, etc etc ect in C for Zog.
Basically what I'm looking at is a completely C (C++) based Propeller!
In fact I might be so bold as to say that Parallax should stop doing what ever it is they have planned for their "not" C language implementation for the Prop and proceed to do the above[noparse]:)[/noparse]
In fact I would now suggest putting a ZPU interpreter into the Prop II ROM with an option to have it started at boot up instead of Spin!
See how crazy I am when I'm half asleep. When I have flushed the dreams out of my head with a few cups of coffee I might start to realize how infeasible this is.
On the other hand...Bill seems to want to be heading this way with Largos, about which I know almost nothing so far.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Post Edited (heater) : 5/14/2010 7:53:47 AM GMT
nice results with -O3 !
the smaller code is also nice to see.
re/ wild ideas:
I like the idea of running a ZOG Prop, however I'd do things a bit differently than you are suggesting in your early morning email.
- Use a 64KB eeprom and/or a uSD card
With this approach, the first 32KB holds the ZOG kernel, system libraries, and a kernel/file system buffer area - which is extremely similar to the Largos memory map.
Here is the initial memory map:
$0000-$01FF - reserved, will talk about later, Largos uses it, and it holds important system vectors etc
$0200-$09FF - initial ZOG image, padded out to full 2KB
$0A00-$0AFF - syscall and syslib vectors, points to one of 128 functions, later can grow to 256 functions or even 512
$0B00-$0FFF - syslib, written in ZOG - things like i2c read code, cognew, stdio, SPI read/write code,
$1000-$7FFF - user application space / VMCOG working set when using VM
The initial 32KB of the eeprom holds the above 4KB image (later could be 8KB with full Largos) - the rest of the 32KB holds useful cog drivers, and loadable libraries.
The upper 32KB holds the user application, which saves much memory by using drivers in the first 32KB, and by using the standard system services.
This way, the ZOG user code can do something like:
cog = icognew(i2caddress,&par);
which loads a driver cog into the 2K cog buffer, then launches it.
cog = icognew(zogaddress,&par);
launches a new ZOG interpreter, pointing at code to execute, and
cog = icognew(fasterspin,&par);
could use Cluso's tweaked faster Spin interpreter, or a version modified for VMCOG (thanks for the correction guys!)
The 'i' prefix to cognew means use the version that loads the image from eeprom via i2c into the shared cog buffer.
Adding the rest of prop features would be easy - just add them to syslib, and use the syscall escape hatch to implement them. IMHO, there is no need to implement waitvid, as ZOG would not be fast enough to write video drivers in.
******* PLEASE DO NOT USE C++ *********
C++ makes much heavier use of the stack, and indirection tables - not to mention all the hidden new / delete's!
Not only would this chew up memory much faster (a big concern with a hub-only "small" model ZOG), but it would significantly reduce execution speed.
Stick to ANSII C, and instead of objects, have nice libraries - that is the plan for Largos.
Recoding the objects would not be too bad, as only the spin code would need modifying; the underlying PASM code would be used as-is.
There is no need to replace the spin interpreter in the ROM, doing it like I suggest above is easy enough [noparse]:)[/noparse]
I'd rather Parallax spent the roughly 50k they would need to make a new rom on getting P1.5 out... besides, doing it this way allows changing the ZOG interpreter to be even more efficient (or customized) over time.
oh - and placing the low-level readblock/writeblock code for fsrw into the system library is a big win... if a C version of FAT is compiled, it can be run under VMCOG, with unused file system code not taking up space in the hub until needed...
Same with TCP/IP - only code being used would be in the working set.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
Post Edited (Bill Henning) : 5/13/2010 3:31:23 PM GMT
Great work! I have also been watching the thread and think you have made great progress!
@Bill,
I remember Cluso99 working on a faster Spin interpreter. Maybe Brad/RossH worked on others as well?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit the Propeller Powered SIG·fourm kindly hosted at Savage Circuits
Game(s) Mythic Flight
Utilities Font Editors (AIGeneric, Potato_Text, etc.)
I just wanted to correct that. It was not I, but Cluso99 that did the faster Spin Interpreter. I'm not that hard core I'm afraid.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"Are you suggesting coconuts migrate?"
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
Anyway the general dream still holds, minimize the amount of Spin required to get into the C environment hopefully bootstrapping into C and discarding the Spin altogether. Isn't that what you are up to with Largos?
Re: C++, I understand your concerns about the overheads of C++ and the need for a memory allocator to deal with all the new/deletes, or the huge stack, or the vtables.
But actually none of that is necessary. C++ is just C with more rope to hang yourself with[noparse]:)[/noparse]
If you don't use new/delete you don't need a heap manager.
If you don't declare objects on the stack you don't need a huge stack.
If you don't use inheritance and polymorphism etc then you don't have vtables.
So which part of the C++ rope might we actually use? What's the point you might ask?
Well, it occurs to me that you can use objects in C++ in much the same limited way as objects in Spin. They are static, they have no inheritance etc. In fact pretty much all they do is allow for multiple instances of the same object to have their own data whilst sharing the same code. As a bonus they provide data hiding, private methods and the possibility to have many functions/variables in you code that have the same name. Objects provide name spaces.
This can be done in C++ with no overheads over C.
Consider this, if you want two UART objects what can you do?.
1) Cut and paste the code, have two copies, change the names used in one to avoid name clashes.
2) Use one copy of the code and have two copies of the data structures required. The UART code now needs a pointer parameter to each method so that each call will access the correct UART.
3) Put the UART code in a C++ class and instantiate two UART objects. This basically does what you do manually in C but C++ does the pointer messing for you.
solution 3) is the same size code as doing it in C and is easier to read as a bonus.
A concrete example: Here are C function calls to turn a LEDs on/off with an object selector pointer parameter together with the ASM it generates:
on(&led1); 5b4: 99 im 25 5b5: bc im 60 5b6: 51 storesp 4 5b7: ff im -1 5b8: ab im 43 5b9: 3f callpcrel off(&led2); 5ba: 99 im 25 5bb: c0 im -64 5bc: 51 storesp 4 5bd: ff im -1 5be: bc im 60 5bf: 3f callpcrelHere the equivalent C++ method calls to objects of a Led class:
led1.on(); 56c: 99 im 25 56d: bc im 60 56e: 51 storesp 4 56f: 80 im 0 570: c8 im -56 571: 3f callpcrel led2.off(); 572: 99 im 25 573: c0 im -64 574: 51 storesp 4 575: ac im 44 576: 3f callpcrelWell, what do we know? The C++ version is smaller!!
(Not sure why there is that extra IM 0 in there though)
The fully built binary is exactly the same size in straight C or using a class. See attachment.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Post Edited (heater) : 5/14/2010 6:08:06 PM GMT
This fixes an endian issue with the write syscall.
The default test binary is now some RC4 crypto.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Yes, I did the faster spin interpreter (see the tools link in my signature)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
May the road rise to meet you; may the sun shine on your back.
May you create something useful, even if it's just a hack.
The working version of Zog is in the first post of this thread. Sorry if I did not make that clear.
The working version of Cluso's Spin interpreter is just where he says it is,
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
May the road rise to meet you; may the sun shine on your back.
May you create something useful, even if it's just a hack.
If you are playing along please tell me where Zog falls down.
As for the Cluso interpreter I guess we have to bug Cluso some more.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I just haven't had time recently. I'll have more time in June. I'm "swamped" right now.
I've been waiting for cluso's fix he keeps referring to in other threads. Until that happens, it's broken.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
May the road rise to meet you; may the sun shine on your back.
May you create something useful, even if it's just a hack.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
ZOG_SMALL is a compact version of ZOG that has it's dispatch table in COG.
To make this possible a lot of op codes have been implemented using the ZPU's EMULATE instruction rather than being done in PASM.
The result is of course much slower than ZOG but there is still 160 LONGs left in the COG. So with some profiling we can find out which ZPU ops it is useful to put back into PASM.
What's the point? Well, just an experiment and I'd like to have a Spin interpreter style binary blob that can be thrown at a COG without having to worry where the dispatch table is. Plus it save HUB space.
As this is just an experiment at the moment I attach it here for comment rather than the first post.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Better than I expected.
As you may have noticed in my VMCOG thread, v0.92 now works... I have a 64KB VM running on PropCade!
All you really need is two 23K256 chips, and a minor change to BSTART to change how you select between the two chips - and you can start running 64KB ZOG programs!
That would help test VMCOG immensely...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
At this simple level you need at least a pointer to distinguish between objects of the same class. In C you do it manually with a pointer. In C++ the pointer gets hidden from you. The mechanism is the same. As you see in the asm output. Admittedly I have not looked at any other C++ compilers output to see what they get up to.
I'm sure when you get into inheritance and vtables things look a lot uglier[noparse]:)[/noparse]
OK, I'll try and get some 23K256 from Farnell here in Finland. They can bolt onto my TriBlade blade #3. Until then I'll try and find time to integrate VMCog using only HUB RAM.
Would I be wasting my time if I ordered 8 or 16? How many will VMCog handle ultimately?. I can't put in an order for just 2.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
VMCOG will handle:
1) up to 8 23K256's in single-channel mode (with 2KB pages)
2) up to 12 23K256's in four-bit wide mode (with 4KB pages)
You could easily modify BSTART/BREAD/BWRITE to use the parallel ram on TriBlade...
Also there is no reason one could not run two VMCOG's, with different mailboxes and pins on the same Prop... for two ZOG's.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
I'll see what I can do with BSTART/BREAD/BWRITE on the TriBlade.
Two Zogs. I was thinking in terms of one Zog running from HUB RAM as a general replacement for Spin. It would provide the infrastructure for the second Zog running from ext RAM instead of Spin.
Now we could have three Zogs, two in ext RAM[noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Hmm... two props with parallel ram, one with serial... you could get ~8 ZOG's on a TriBlade!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
This means that Zog will now work with any external RAM system that VMCog supports.
Currently the external memory size is limited to 64K by the VMCog capabilities.
As built here it only uses 4 "resident" memory pages and is very slow running the RC4 crypto test. Changing to 16 pages brings the speed of this little test up a lot. (Factor 10).
So change "vm.start(@mailbox, $7000, 4)" to "vm.start(@mailbox, $7000, 16)".
Just now the ZPU image to be executed is pulled in from a "file" statement so be carefull with using too many pages as we need the HUB space. I'll have a go at getting binary images loaded from SD then mpre pages can be used and things will speed up for bigger programs.
Attached to first post.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.