Announcing Zog v0.2. Attached to the first post of this thread.
With version 0.2 of Zog he can run a C program compiled with GCC for the ZPU architecture for the first time.
Yes! We have GCC C, C++ and FORTRAN for the Propeller now.
v0.2 does not have any IO. The supplied test program just runs around a loop in main() incrementing a variable.
Still to do that it has made it's way through the start up code and C runtime stuff.
The C code is executed from HUB with 16K being allocated to Zog.
Instructions for building programs with GCC for the ZPU are in the README.TXT
If you run this with the BST terminal or such you can single step through the code by pressing SPACE. Eventually it will come to a loop at PC = 056C. The numbers below the register dump are the stack. In there you may be able to make out the incrementing variable as you step through.
Next up is some I/O so as to get printf() working and then adding Bill Hennings Virtual Memory system.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
heater said...
Announcing Zog v0.2. Attached to the first post of this thread.
With version 0.2 of Zog he can run a C program compiled with GCC for the ZPU architecture for the first time.
Yes! We have GCC C, C++ and FORTRAN for the Propeller now. ....
Good progress and excellent news for all us GNU lovers [noparse]:)[/noparse]
Having used GNU on multi-billion dollar projects for over 20 years, I find it hard to change my ways. I must admit though the Propeller has shown me light ... In some cases the light in the tunnel was freedom, in others it was a train.
I found and fixed a problem with LOADSP and STORESP ops. These instructions have a 5 bit field used to give an offset into the stack. Turns out the ZPU inverts bit 4 of that offset prior to use. God knows why!
RossH: "Proves how persistent you are, and also how remarkable the Propeller is"
Some call it "persistent" others call it "obsessive compulsive" [noparse]:)[/noparse]
The remarkable thing here is that the Prop is doing in 371 instructions what the ZPU simulator I'm looking at does in about 2000 lines of Java !
If anyone is up to cross compiling uClinux for ZPU I'd love to see it. Then we think about a port.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Speed? What speed? I was hoping no one would ask. I don't like to talk about it.
Looking at a typical ZPU instruction, say ADD, we have:
execute loop - 10 LONGS
readbyte - 5 LONGS
Add op handler - 5 LONGS
pop - 6 LONGS
pop - 6 LONGS
push - 7 LONGS
TOTAL 39 LONGS
So one fortieth of 20 MIPS = 500,000 ZIPS. Quite sad really.
Perhaps we are doing a tad better as things like ADD do more work that the majority of the executed instructions.
Pretty much one third of all instructions output by the compiler are IM. Loading a small immediate value. This is only 24 PASM instructions.
I'll try and do some real measurements on this.
At some point I will adopt Bill's suggestions for optimizing away a lot of POPs by keeping the Top Of Stack around which will save a bit.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Jeff Atwood said...
So when, exactly, is International Backup Awareness Day? Today. Yesterday. This week. This month. This year.
It's a trick question. Every day is International Backup Awareness Day. And the sooner I figure that out, the better off I'll be.
I lost some of my interim versions of ZiCog recently. I backup to DVD regularly and did one final backup before I deleted some of the files. Just to be sure, I read a few files off the DVD as I always do. The day after I deleted them I was looking for one of the older files. You guessed it!! Damn DVD software was ignoring files after a long filename in one of the folders, so everything seemed OK except what I wanted !! But guess what - I had uploaded it to the forum, so I got it back
BTW: I have hundreds of incremental backups. That is the way I always work. Many incremental backups often in 1 day. You may notice my _rr076 filename extensions, but here I have a..z added.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
BTW: I have hundreds of incremental backups. That is the way I always work. Many incremental backups often in 1 day. You may notice my _rr076 filename extensions, but here I have a..z added.
I used to work like that until I discovered source control software. Now pretty much every change is documented as a separate patch in source control. I can roll back any changes piecemeal and it makes regression testing a piece of cake. Plus, it's dead easy to mirror the source control server directory using rsync for off-site backups. The added benefit is I can work across multiple machines and I know my source is *always* in sync.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
Well, we are in the same ball park as an original IBM PC with its 4.77MHz Intel 8088 ans about 0.33 MIPS.
So Zog is within the realms of usability. Oh and did I say these are 32 bit ops [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
heater said...
Well, we are in the same ball park as an original IBM PC with its 4.77MHz Intel 8088 ans about 0.33 MIPS.
Oooh ooh ooh can you port digger with its original "Popcorn" soundtrack ???
I have very fond memories of my first XT with its 5.25 drives and the ST-506. Unlike the useful Apple ][noparse][[/noparse] it was supposed to replace though, Digger was about the only thing it was good at.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
You must be the first person I've ever heard of having "fond memories" of the IBM PC. I thought it was universally hated or at least considered really dull and unimaginative.
At least with Zog you don't have to worry about memory segments.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I am guessing they invert it so it can easily access function parameters on the stack by using a negative offset, and local variables by using a positive offset.
heater said...
Zog v0.3 Released. See first post.
I found and fixed a problem with LOADSP and STORESP ops. These instructions have a 5 bit field used to give an offset into the stack. Turns out the ZPU inverts bit 4 of that offset prior to use. God knows why!
RossH: "Proves how persistent you are, and also how remarkable the Propeller is"
Some call it "persistent" others call it "obsessive compulsive" [noparse]:)[/noparse]
The remarkable thing here is that the Prop is doing in 371 instructions what the ZPU simulator I'm looking at does in about 2000 lines of Java !
If anyone is up to cross compiling uClinux for ZPU I'd love to see it. Then we think about a port.
In this example, my optimization of push/pop would save one push and one pop, dropping the count to 26 longs.
Using the other optimization I suggested (adding stack_offset to SP when loading it instead of every push/pop) would save two more longs, and using the same optimization for PC should save two more... dropping it to 22 longs total!
heater said...
Speed? What speed? I was hoping no one would ask. I don't like to talk about it.
Looking at a typical ZPU instruction, say ADD, we have:
execute loop - 10 LONGS
readbyte - 5 LONGS
Add op handler - 5 LONGS
pop - 6 LONGS
pop - 6 LONGS
push - 7 LONGS
TOTAL 39 LONGS
So one fortieth of 20 MIPS = 500,000 ZIPS. Quite sad really.
Perhaps we are doing a tad better as things like ADD do more work that the majority of the executed instructions.
Pretty much one third of all instructions output by the compiler are IM. Loading a small immediate value. This is only 24 PASM instructions.
I'll try and do some real measurements on this.
At some point I will adopt Bill's suggestions for optimizing away a lot of POPs by keeping the Top Of Stack around which will save a bit.
Actually the 5 bit offset field in LOADSP and STORESP is an unsigned offset up the stack. It confused me like hell that all LOADSP in the test compilation are 0x7X i.e. with bit 4 set. They are all small offsets.
Big external FLASH for code would be great. I have yet to figure out how to get the compiler to locate code, constants, data, stack in such away that we can do that and keep data/stack in HUB. Should be a case of tweaking the linker scripts but the ZPU devs suspect it is harder than that for some reason.
I have to get my head around the optimizations, we can't Have RossH snickering at us forever[noparse]:)[/noparse]
But not before Zog gets some I/O so that printf("Works\n");
And not before the Virtual Memory interface is added.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
>>But not before Zog gets some I/O so that printf("Works\n");
Since a certain time I have a dream that I can migrate all my software to any new microcontroller plattform. Therefore I ran the propeller-emulator on a 8 Bit Atmega32.
The structure of ZOG seems much easier to implement than the propeller core. So this seems to be the architecture I have to use for my project.
To be able to use the ZOG emulator on every new mikrocontroller system, there should be dedicated address in the ZOG memory space which have on every system the same meanings.
For instance:
0xF000 ( write ) : output to the serial port of the mikrocontroller
0xF000 ( read ) : get the last character from the serial port
0xF004 ( write ) : 32 bit value, write to port pins ( on each architecture the port pins have to be mapped to that address )
....
heater said...
Actually the 5 bit offset field in LOADSP and STORESP is an unsigned offset up the stack. It confused me like hell that all LOADSP in the test compilation are 0x7X i.e. with bit 4 set. They are all small offsets.
Ah! I sit corrected [noparse]:)[/noparse]
heater said...
Big external FLASH for code would be great. I have yet to figure out how to get the compiler to locate code, constants, data, stack in such away that we can do that and keep data/stack in HUB. Should be a case of tweaking the linker scripts but the ZPU devs suspect it is harder than that for some reason.
Me too. Hmm.. there should be a way to tell gcc and the linker to have separate cseg/dseg/sseg
If Zog can eventually handle that, there is no reason GCC could not crawl on it! (note I did not say "run" on purpose)
heater said...
I have to get my head around the optimizations, we can't Have RossH snickering at us forever[noparse]:)[/noparse]
But not before Zog gets some I/O so that printf("Works\n");
And not before the Virtual Memory interface is added.
If all else fails, after it functions totally correctly, I can try to find some time to tweak it a bit.
Getting putchar() and getchar() working will allow a lot of programs to run, and allow benchmarking etc
VMCOG has slowed down a bit, but I have made some more progress. I will upload a new version this weekend.
I have also decided to later make a VLMM kernel... care to guess what that would be for? <grin>
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
With version 0.2 of Zog he can run a C program compiled with GCC for the ZPU architecture for the first time.
Yes! We have GCC C, C++ and FORTRAN for the Propeller now.
v0.2 does not have any IO. The supplied test program just runs around a loop in main() incrementing a variable.
Still to do that it has made it's way through the start up code and C runtime stuff.
The C code is executed from HUB with 16K being allocated to Zog.
Instructions for building programs with GCC for the ZPU are in the README.TXT
If you run this with the BST terminal or such you can single step through the code by pressing SPACE. Eventually it will come to a loop at PC = 056C. The numbers below the register dump are the stack. In there you may be able to make out the incrementing variable as you step through.
Next up is some I/O so as to get printf() working and then adding Bill Hennings Virtual Memory system.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Amazing work. Proves how persistent you are, and also how remarkable the Propeller is.
Ross.
P.S. When can I load Linux?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
You make it sound so ... well ... bestial!
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
I found and fixed a problem with LOADSP and STORESP ops. These instructions have a 5 bit field used to give an offset into the stack. Turns out the ZPU inverts bit 4 of that offset prior to use. God knows why!
RossH: "Proves how persistent you are, and also how remarkable the Propeller is"
Some call it "persistent" others call it "obsessive compulsive" [noparse]:)[/noparse]
The remarkable thing here is that the Prop is doing in 371 instructions what the ZPU simulator I'm looking at does in about 2000 lines of Java !
If anyone is up to cross compiling uClinux for ZPU I'd love to see it. Then we think about a port.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I'm always amazed at how much you can cram into a few dozen PASM instructions. The SPIN interpreter is quite a good example also.
How's the speed? How many ZIPS? (and should that "ZPU Instructions Per Second", or "ZOG Instructions per second"?).
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Looking at a typical ZPU instruction, say ADD, we have:
execute loop - 10 LONGS
readbyte - 5 LONGS
Add op handler - 5 LONGS
pop - 6 LONGS
pop - 6 LONGS
push - 7 LONGS
TOTAL 39 LONGS
So one fortieth of 20 MIPS = 500,000 ZIPS. Quite sad really.
Perhaps we are doing a tad better as things like ADD do more work that the majority of the executed instructions.
Pretty much one third of all instructions output by the compiler are IM. Loading a small immediate value. This is only 24 PASM instructions.
I'll try and do some real measurements on this.
At some point I will adopt Bill's suggestions for optimizing away a lot of POPs by keeping the Top Of Stack around which will save a bit.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Glad you posted the code on the forum so you have a backup in case you leave the code on the bus LOL.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
I'm borrowing my backup strategy from Linus Torvalds:
Bet he never had that trouble with buses.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
At this rate maybe Brad and parallax will be $1,000 poorer by the end of the year after all... (but richer for the experience?
Adopting the upload-as-backup strategy sounds like a great way to celebrate International Backup Awareness Day - http://www.codinghorror.com/blog/2009/12/international-backup-awareness-day.html
or, to cut a long blog short:
BTW: I have hundreds of incremental backups. That is the way I always work. Many incremental backups often in 1 day. You may notice my _rr076 filename extensions, but here I have a..z added.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Maybe you should calculate ZOG speed in ZIMmers instead (just tell peope it stands for "Zog Instructions per Minute").
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Post Edited (RossH) : 2/19/2010 8:53:55 AM GMT
I used to work like that until I discovered source control software. Now pretty much every change is documented as a separate patch in source control. I can roll back any changes piecemeal and it makes regression testing a piece of cake. Plus, it's dead easy to mirror the source control server directory using rsync for off-site backups. The added benefit is I can work across multiple machines and I know my source is *always* in sync.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
Don't forget that Zog is a 1000 foot tall space alien that likes to sleep frozen in an iceberg.
www.marvunapp.com/Appendix3/zogjim.htm
@Rossh: I would not dream to coopt the name of the hallowed rock band "The Zimmers"
www.youtube.com/watch?v=zqfFrCUrEbY
This is my generation, baby.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
On my 104MHz Propeller Zog has been timed at 35,378,485 ZIMs (ZPU Instructions per Minute).
Or about 590 KIPs (Kilo Instructions Per second)
My measurement technique slows the execution a tad so lets call it 600KIPs.
Compares favourably with the ZiCog Z80 emulator. But, hey, these are 32 bits ops [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Wow - 35 MegaZIMs! ZOG smiles on you from his home in the ice!
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
So Zog is within the realms of usability. Oh and did I say these are 32 bit ops [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Oooh ooh ooh can you port digger with its original "Popcorn" soundtrack ???
I have very fond memories of my first XT with its 5.25 drives and the ST-506. Unlike the useful Apple ][noparse][[/noparse] it was supposed to replace though, Digger was about the only thing it was good at.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
At least with Zog you don't have to worry about memory segments.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I am guessing they invert it so it can easily access function parameters on the stack by using a negative offset, and local variables by using a positive offset.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com 5.0" VGA LCD in stock!
Morpheus dual Prop SBC w/ 512KB kit $119.95, Mem+2MB memory/IO kit $89.95, both kits $189.95 SerPlug $9.95
Propteus and Proteus for Propeller prototyping 6.250MHz custom Crystals run Propellers at 100MHz
Las - Large model assembler Largos - upcoming nano operating system
Using the other optimization I suggested (adding stack_offset to SP when loading it instead of every push/pop) would save two more longs, and using the same optimization for PC should save two more... dropping it to 22 longs total!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com 5.0" VGA LCD in stock!
Morpheus dual Prop SBC w/ 512KB kit $119.95, Mem+2MB memory/IO kit $89.95, both kits $189.95 SerPlug $9.95
Propteus and Proteus for Propeller prototyping 6.250MHz custom Crystals run Propellers at 100MHz
Las - Large model assembler Largos - upcoming nano operating system
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com 5.0" VGA LCD in stock!
Morpheus dual Prop SBC w/ 512KB kit $119.95, Mem+2MB memory/IO kit $89.95, both kits $189.95 SerPlug $9.95
Propteus and Proteus for Propeller prototyping 6.250MHz custom Crystals run Propellers at 100MHz
Las - Large model assembler Largos - upcoming nano operating system
Actually the 5 bit offset field in LOADSP and STORESP is an unsigned offset up the stack. It confused me like hell that all LOADSP in the test compilation are 0x7X i.e. with bit 4 set. They are all small offsets.
Here is what the ZPU developer,
I have to get my head around the optimizations, we can't Have RossH snickering at us forever[noparse]:)[/noparse]
But not before Zog gets some I/O so that printf("Works\n");
And not before the Virtual Memory interface is added.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Since a certain time I have a dream that I can migrate all my software to any new microcontroller plattform. Therefore I ran the propeller-emulator on a 8 Bit Atmega32.
The structure of ZOG seems much easier to implement than the propeller core. So this seems to be the architecture I have to use for my project.
To be able to use the ZOG emulator on every new mikrocontroller system, there should be dedicated address in the ZOG memory space which have on every system the same meanings.
For instance:
0xF000 ( write ) : output to the serial port of the mikrocontroller
0xF000 ( read ) : get the last character from the serial port
0xF004 ( write ) : 32 bit value, write to port pins ( on each architecture the port pins have to be mapped to that address )
....
Well it looks probably a little bit like DOS.
What do you think?
Ah! I sit corrected [noparse]:)[/noparse]
Me too. Hmm.. there should be a way to tell gcc and the linker to have separate cseg/dseg/sseg
If Zog can eventually handle that, there is no reason GCC could not crawl on it! (note I did not say "run" on purpose)
If all else fails, after it functions totally correctly, I can try to find some time to tweak it a bit.
Getting putchar() and getchar() working will allow a lot of programs to run, and allow benchmarking etc
VMCOG has slowed down a bit, but I have made some more progress. I will upload a new version this weekend.
I have also decided to later make a VLMM kernel... care to guess what that would be for? <grin>
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com 5.0" VGA LCD in stock!
Morpheus dual Prop SBC w/ 512KB kit $119.95, Mem+2MB memory/IO kit $89.95, both kits $189.95 SerPlug $9.95
Propteus and Proteus for Propeller prototyping 6.250MHz custom Crystals run Propellers at 100MHz
Las - Large model assembler Largos - upcoming nano operating system
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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