In an idle moment I just started coding the ZPU emulator in PASM working from the ZyLin Java simulator code and my C version of same. So far I have 44 of the 47 ops in place and have only used 255 longs !
What's missing? Basically the support infrastructure:
Dispatch table in HUB.
A fetch and dispatch loop.
The essential push and pop functions for this stack based machine.
BYTE, WORD and LONG ZPU memory access functions.
Some arithmetic functions.
All of the above won't take 240 longs so it looks as if everything is going to fit in a single COG !!
Sorry Bill this is going so easily there may never be a Spin version of the ZPU. Hope we can test VMCog from this PASM version soon.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Maybe there will even be room for moving the dispatch table into the cog...
Please see VMCOG.spin for the Spin access functions, by writing pasm equivalents, you will be interfaced [noparse]:)[/noparse]
I hope to have VMCOG running in a couple of days...
heater said...
In an idle moment I just started coding the ZPU emulator in PASM working from the ZyLin Java simulator code and my C version of same. So far I have 44 of the 47 ops in place and have only used 255 longs !
What's missing? Basically the support infrastructure:
Dispatch table in HUB.
A fetch and dispatch loop.
The essential push and pop functions for this stack based machine.
BYTE, WORD and LONG ZPU memory access functions.
Some arithmetic functions.
All of the above won't take 240 longs so it looks as if everything is going to fit in a single COG !!
Sorry Bill this is going so easily there may never be a Spin version of the ZPU. Hope we can test VMCog from this PASM version soon.
Attached is version 0.1 of the ZPU virtual machine for the Prop.
First off I have to say this does NOT work yet.
Basically it has all the ZPU opcodes in place and runs around executing NOPs in the ZPU memory space in HUB.
The ZPU memory area is loaded from a binary image file, nops.bin (full of NOPs), with a "file" statement.
A simple user interface is provided by a serial link back to the terminal in BST or whatever.
So far the entire VM uses 365 LONGS in COG. A typical ZPM opcode takes 35 PASM instructions to execute.
I have not done any testing on this yet, apart from NOP, so for sure it does not work. Just thought someone out there might be interested to see how it looks and having a backup on the forum is convenient[noparse]:)[/noparse]
I haven't paid any attention to optimization so if anyone has any sneaky speed up tricks now is the time to say.
Bad news is that the smallest Hello World program I have managed to compile with the ZPU version of GCC is about 12K bytes! I have to get down to working without having to drag in a lot of C library stuff.
I had a change of heart about the name for this project. It's been renamed "ZOG" for Z in a Cog.
The Cogz name was just not working for me but ZOG is stuck in my head. RossH seemed to settle on ZOG as well.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
one optimization I almost always use is that I keep the top of the stack in a cog register - then all the operations like 'neg' and 'rev' become MUCH faster, so do add, etc.
Oh... you might want to google Zog and look at the Wikipedia entry - I don't think its a good name.
heater said...
Attached is version 0.1 of the ZPU virtual machine for the Prop.
First off I have to say this does NOT work yet.
Basically it has all the ZPU opcodes in place and runs around executing NOPs in the ZPU memory space in HUB.
The ZPU memory area is loaded from a binary image file, nops.bin (full of NOPs), with a "file" statement.
A simple user interface is provided by a serial link back to the terminal in BST or whatever.
So far the entire VM uses 365 LONGS in COG. A typical ZPM opcode takes 35 PASM instructions to execute.
I have not done any testing on this yet, apart from NOP, so for sure it does not work. Just thought someone out there might be interested to see how it looks and having a backup on the forum is convenient[noparse]:)[/noparse]
I haven't paid any attention to optimization so if anyone has any sneaky speed up tricks now is the time to say.
Bad news is that the smallest Hello World program I have managed to compile with the ZPU version of GCC is about 12K bytes! I have to get down to working without having to drag in a lot of C library stuff.
I had a change of heart about the name for this project. It's been renamed "ZOG" for Z in a Cog.
The Cogz name was just not working for me but ZOG is stuck in my head. RossH seemed to settle on ZOG as well.
Zog - To frolic amongst friends upon turf or the earth in hopes of mentally, physically and emotionally crushing one's enemies in ritual sporting; these games are usually followed by friendly banter accompanied by games centered around consuming beer
"I can't wait to Zog on Sunday!"
"I love Zog"
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
We should not let conspiracy umm fans dictate words anyway [noparse]:)[/noparse]
heater said...
Zog - King of Albania.
Zog - To frolic amongst friends upon turf or the earth in hopes of mentally, physically and emotionally crushing one's enemies in ritual sporting; these games are usually followed by friendly banter accompanied by games centered around consuming beer
Not to mention the famous Professor Philo Zog inventor of the giant robot called Electro, which he controls by remote-control electra waves. en.wikipedia.org/wiki/Elektro_(comics)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Bill: "...keep the top of the stack in a cog register..."
Sounds good but I can't see how to make it work.
If I understand correctly the idea is that every time a PUSH is done the pushed value, which is now top of stack, is cached locally. Then the next instruction starting with POP only has to adjust the stack pointer and use the cached top of stack value. No actual read from the stack is required. A second POP would have to do the read as normal. This sounds great, it removes a lot of redundant reads.
BUT what to do in the face of instructions that can basically write anywhere in memory which may or may not write to the stack top thus making the cached stack top value out of date? Or instructions that end with a POP?
For example STOREH which does:
address = pop();
value = pop();
WriteWord(addr, val);
Looks like it requires a "dirty" bit. Any instruction that ends with a PUSH, caches the pushed value and sets the dirty bit to "clean", the cached value is valid.
Any other instruction sets the dirty bit to "dirty", the cached value may be old.
Any instruction that starts with a POP checks the dirty bit and skips reading the stack if "clean"
Any second POP within an instruction should always do the stack read as normal.
Think that covers it.
All this dirty bit setting/checking takes time and space but compared to the long winded reads from external RAM must be quite a gain.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
But then we could keep an internal stack of the last two items pushed and all the ops that basically do:
x = pop()
y = pop()
z = some_operation(x, y)
push(z)
would hardly ever have to go to external memory for their operands. That's about 50% of the ops.
Maintaining the internal stack and it's state of cleanliness might be an optimization to far...
We are going to give Catalina a run for it's money after all [noparse]:)[/noparse]
Bill: Do you have a test version of your VM that has no external memory? Say just serving up 16K of HUB RAM.
When I have tested Zog a bit I'd like to move it's memory space to another COG and access it via your mailbox interface.
Just for testing.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
SP LONG 0
TOS LONG 0
NOS LONG 0
pushpc:
sub sp,#4
wrlong TOS,sp
mov TOS,pc
pushpc_ret: ret
poppc:
mov pc,TOS
add sp,#4
rdlong TOS,SP
poppc_ret: ret
rev:
rev TOS
jmp #next
neg:
neg TOS
jmp #next
popadd:
add sp,#4
rdlong NOS,sp
add TOS,nos
jmp #next
sub:
add sp,#4
rdlong NOS,sp
sub NOS,TOS
mov TOS,NOS
jmp #next
storeh:
' TOS holds the value when we get here, as it is the Top Of Stack
add sp,#4
rdlong NOS,SP ' we pop the address
wrword NOS, TOS ' write it
add sp,#4
rdlong TOS,sp ' and get new TOS off the stack
jmp #next
fetch_long: ' ie replace TOS with long pointed to by TOS
rdlong TOS, TOS
jmp #next
I think the above gives you the idea [noparse]:)[/noparse]
See the 'sub' case, where TOS & NOS have to be flipped as subtraction is not commutative
See a quick&dirty STOREH implementation
See neg, rev
Does not need a 'Dirty' bit, just careful use of TOS, NOS and SP - note NOS is just a special temporary, and is NOT always the number below TOS - just a place holder for it, in case we need to access it.
Another optimization:
set SP to zog_base+zog_sp, only pushsp needs the "zog_sp" - there you can give it that by subtracting zog_base; VAST majority of accesses then sped up by removing an add
same for PC - set it to zog_base+zog_pc, only subtract out base before pushing it, and add on pops - again, vast majority of accesses want to deal with (zog_base + zog_pc), thus good optimization
I use these technique in several unpublished byte code interpreters I've built over the years, HUGE speedup [noparse]:)[/noparse]
heater said...
Bill: "...keep the top of the stack in a cog register..."
Sounds good but I can't see how to make it work.
If I understand correctly the idea is that every time a PUSH is done the pushed value, which is now top of stack, is cached locally. Then the next instruction starting with POP only has to adjust the stack pointer and use the cached top of stack value. No actual read from the stack is required. A second POP would have to do the read as normal. This sounds great, it removes a lot of redundant reads.
BUT what to do in the face of instructions that can basically write anywhere in memory which may or may not write to the stack top thus making the cached stack top value out of date? Or instructions that end with a POP?
For example STOREH which does:
address = pop();
value = pop();
WriteWord(addr, val);
Looks like it requires a "dirty" bit. Any instruction that ends with a PUSH, caches the pushed value and sets the dirty bit to "clean", the cached value is valid.
Any other instruction sets the dirty bit to "dirty", the cached value may be old.
Any instruction that starts with a POP checks the dirty bit and skips reading the stack if "clean"
Any second POP within an instruction should always do the stack read as normal.
Think that covers it.
All this dirty bit setting/checking takes time and space but compared to the long winded reads from external RAM must be quite a gain.
See all the sample code in my previous reply ... I've been using this technique for quite a while, and it gives a huge speedup.
The latest VMCOG can easily serve up 16K of hub:
vm.start(@mailbox,$7C00,64) ' See VMDebug.spin, this will make virtual addresses $0000-$3FFF available for use right now.
The $7C00 is so VMCOG can run under SphinxOS.
Currently vm.rdvbyte(addr) and vm.wrvbyte(addr,val) messages work fine (see VMCOG.spin for implementation of those spin methods, shows you how to poke values into the mailbox and get results from it.
I hope to get rdvword/rdvlong/wrvword/wrvlong running today.
You will find commands 1,3,6 and 9 very useful for debugging.
1 - shows you the TLB, including dirty bit, physical address, and access count
3 - read a byte from specified virtual address
6 - write a byte to specified virtual address
9 - shows you a hex dump of a virtual page (as long as it is in the working set)
Later I may change to a command line monitor style debugger instead of menu's.
heater said...
But then we could keep an internal stack of the last two items pushed and all the ops that basically do:
x = pop()
y = pop()
z = some_operation(x, y)
push(z)
would hardly ever have to go to external memory for their operands. That's about 50% of the ops.
Maintaining the internal stack and it's state of cleanliness might be an optimization to far...
We are going to give Catalina a run for it's money after all [noparse]:)[/noparse]
Bill: Do you have a test version of your VM that has no external memory? Say just serving up 16K of HUB RAM.
When I have tested Zog a bit I'd like to move it's memory space to another COG and access it via your mailbox interface.
Just for testing.
FYI, I just uploaded VMCOG v0.25 - this version adds aligned word and long reads from the working set
I am working on aligned word and long writes right now, and once those work as well, I will add support for non-aligned word/long reads/writes
non-aligned is a pain because it may cross page boundaries.
heater said...
OK Bill, that's starting to make sense. I'm not going to get into any such optimizations until Zog is tested and happily running some GCC output.
Nothing like a challenge to bring out the best in a design. Apple used to run two design teams and the best design won out (not sure it they still do that).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
But with Bill's suggested optimizations and the VM cache Zog might not be totally embarrassed. Especially in some odd contrived cases like running code directly from an attached SPI FLASH with data and stack in HUB.
Actually, that sounds like a damn useful use-case. How great it would be if Spin could execute from the program FLASH leaving all the RAM for working data.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
The madness grows: How about C++ for the Propeller?
Just for Humanoido's list.
For the Propeller ZPU emulator this:
class aclass
{
public:
aclass()
{
a = 42;
}
int get()
{
return (a);
}
void set(int val)
{
a = val;
}
private:
int a;
};
int main (int argc, char* argv[noparse][[/noparse] ])
{
aclass* aobj = new aclass();
aclass* bobj = new aclass();
bobj->set(aobj->get());
*aobj = *bobj;
return (aobj->get());
}
Produces this:
.file "hello.cpp"
.text
.globl main
.type main, @function
main:
im -2
pushspadd
popsp
im 4
storesp 4
impcrel (_Znwm)
callpcrel
im _memreg+0
load
storesp 12
im 42
nop
im _memreg+0
load
store
.L3:
im 4
storesp 4
impcrel (_Znwm)
callpcrel
im 42
nop
im _memreg+0
load
store
.L6:
loadsp 8
load
loadsp 0
im _memreg+0
load
store
loadsp 0
loadsp 16
store
.L1:
im _memreg+0
store
im 4
pushspadd
popsp
poppc
.size main, .-main
.ident "GCC: (GNU) 3.4.2"
Do you think it require external memory? Not a problem if it does, but would be nice to do reasonable stuff without it.
I finally made a Fedora uSD card so I can use the toolchain on my laptop. If you have a pointer to linux binaries, that would save a ton of work.
How would one download the program to the Propeller (without resident CPM, or other OS) ?
BTW, one offshoot of my 32 bit addressable Spin interpreter investigations/development would be running spin from any media including uSD as you suggested above. Having a compiler option to put stack and variables in HUB ram would make that possible ... preliminary discussion has started in this area. Not trying to hijack the thread of course.
Make a directory for your zpu tool chain and change to it, I called mine zpu:
$ mkdir zpu
$ cd zpu
Put the down loaded package there and unpack it:
$ tar -xvjf zpugcclinux.tar.bz2
That will have created an "install" directory full of ZPU goodies.
Now you should be able to run GCC for ZPU.
$ ./bin/zpu-elf-gcc bla bla bla ...
See post above for options I use in compiling.
Zog will run fine without external memory. For sure the first versions will only use HUB RAM.
How useful that turns out to be remains to be seen. Catalina and ICC may be better/faster there although ZPU should have smaller binaries.
For now the ZPU binaries are downloaded within the Spin program. They are just included into a DAT section in a "file" statement. No other OS or software required.
I have yet to think about how this will work in future. Especially when we have external memory. Don't tempt me with getting CP/M to do it[noparse]:)[/noparse]
Zog could of course be fixed in the Propeller boot ROM as normal and include a simple secondary boot loader to get the ZPU binary down. But we should also think about integration with other objects in Spin like Catalina does. Early days yet. Or think about booting ZPU code from SD etc.
Spin from external RAM or FLASH would be great. Same with Zog. Similarly I have yet to figure out how to separate the code and data sections from a ZPU compilation.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
By the way the pre-compiled GCC for ZPU does not include C++ you will have to compile GCC from the sources to get that.
I can give instructions if anyone wants.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
FORTRAN only comes into the picture here because the version of GCC (3.4.2) that has been targeted at the ZPU architecture is already able to compile it. Looks like it has java in there as well but I have not managed to get it to compile anything yet.
As far as I can tell COBOL for GCC is not "done" yet. The version of GCC that the ZPU developers have used does not support COBOL and I doubt if they will ever bring there GCC version up to any newer version that may have COBOL.
Oh well.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Well, actually Bill, when I rebuilt the GCC for ZPU without configuring which languages it should support (Then it should default to "all") I was hoping to find Ada in there. Sadly not.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
heater said...
Well, actually Bill, when I rebuilt the GCC for ZPU without configuring which languages it should support (Then it should default to "all") I was hoping to find Ada in there. Sadly not.
Comments
What's missing? Basically the support infrastructure:
Dispatch table in HUB.
A fetch and dispatch loop.
The essential push and pop functions for this stack based machine.
BYTE, WORD and LONG ZPU memory access functions.
Some arithmetic functions.
All of the above won't take 240 longs so it looks as if everything is going to fit in a single COG !!
Sorry Bill this is going so easily there may never be a Spin version of the ZPU. Hope we can test VMCog from this PASM version soon.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Maybe there will even be room for moving the dispatch table into the cog...
Please see VMCOG.spin for the Spin access functions, by writing pasm equivalents, you will be interfaced [noparse]:)[/noparse]
I hope to have VMCOG running in a couple of days...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
First off I have to say this does NOT work yet.
Basically it has all the ZPU opcodes in place and runs around executing NOPs in the ZPU memory space in HUB.
The ZPU memory area is loaded from a binary image file, nops.bin (full of NOPs), with a "file" statement.
A simple user interface is provided by a serial link back to the terminal in BST or whatever.
So far the entire VM uses 365 LONGS in COG. A typical ZPM opcode takes 35 PASM instructions to execute.
I have not done any testing on this yet, apart from NOP, so for sure it does not work. Just thought someone out there might be interested to see how it looks and having a backup on the forum is convenient[noparse]:)[/noparse]
I haven't paid any attention to optimization so if anyone has any sneaky speed up tricks now is the time to say.
Bad news is that the smallest Hello World program I have managed to compile with the ZPU version of GCC is about 12K bytes! I have to get down to working without having to drag in a lot of C library stuff.
I had a change of heart about the name for this project. It's been renamed "ZOG" for Z in a Cog.
The Cogz name was just not working for me but ZOG is stuck in my head. RossH seemed to settle on ZOG as well.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
one optimization I almost always use is that I keep the top of the stack in a cog register - then all the operations like 'neg' and 'rev' become MUCH faster, so do add, etc.
Oh... you might want to google Zog and look at the Wikipedia entry - I don't think its a good name.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Post Edited (Bill Henning) : 2/9/2010 10:17:20 PM GMT
Zog - To frolic amongst friends upon turf or the earth in hopes of mentally, physically and emotionally crushing one's enemies in ritual sporting; these games are usually followed by friendly banter accompanied by games centered around consuming beer
"I can't wait to Zog on Sunday!"
"I love Zog"
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
We should not let conspiracy umm fans dictate words anyway [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
ZOG will be very, very, unhappy if you decide to change the name.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Sounds good but I can't see how to make it work.
If I understand correctly the idea is that every time a PUSH is done the pushed value, which is now top of stack, is cached locally. Then the next instruction starting with POP only has to adjust the stack pointer and use the cached top of stack value. No actual read from the stack is required. A second POP would have to do the read as normal. This sounds great, it removes a lot of redundant reads.
BUT what to do in the face of instructions that can basically write anywhere in memory which may or may not write to the stack top thus making the cached stack top value out of date? Or instructions that end with a POP?
For example STOREH which does:
address = pop();
value = pop();
WriteWord(addr, val);
Looks like it requires a "dirty" bit. Any instruction that ends with a PUSH, caches the pushed value and sets the dirty bit to "clean", the cached value is valid.
Any other instruction sets the dirty bit to "dirty", the cached value may be old.
Any instruction that starts with a POP checks the dirty bit and skips reading the stack if "clean"
Any second POP within an instruction should always do the stack read as normal.
Think that covers it.
All this dirty bit setting/checking takes time and space but compared to the long winded reads from external RAM must be quite a gain.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Post Edited (heater) : 2/10/2010 8:56:03 AM GMT
x = pop()
y = pop()
z = some_operation(x, y)
push(z)
would hardly ever have to go to external memory for their operands. That's about 50% of the ops.
Maintaining the internal stack and it's state of cleanliness might be an optimization to far...
We are going to give Catalina a run for it's money after all [noparse]:)[/noparse]
Bill: Do you have a test version of your VM that has no external memory? Say just serving up 16K of HUB RAM.
When I have tested Zog a bit I'd like to move it's memory space to another COG and access it via your mailbox interface.
Just for testing.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Post Edited (heater) : 2/10/2010 9:38:52 AM GMT
SP LONG 0 TOS LONG 0 NOS LONG 0 pushpc: sub sp,#4 wrlong TOS,sp mov TOS,pc pushpc_ret: ret poppc: mov pc,TOS add sp,#4 rdlong TOS,SP poppc_ret: ret rev: rev TOS jmp #next neg: neg TOS jmp #next popadd: add sp,#4 rdlong NOS,sp add TOS,nos jmp #next sub: add sp,#4 rdlong NOS,sp sub NOS,TOS mov TOS,NOS jmp #next storeh: ' TOS holds the value when we get here, as it is the Top Of Stack add sp,#4 rdlong NOS,SP ' we pop the address wrword NOS, TOS ' write it add sp,#4 rdlong TOS,sp ' and get new TOS off the stack jmp #next fetch_long: ' ie replace TOS with long pointed to by TOS rdlong TOS, TOS jmp #nextI think the above gives you the idea [noparse]:)[/noparse]
See the 'sub' case, where TOS & NOS have to be flipped as subtraction is not commutative
See a quick&dirty STOREH implementation
See neg, rev
Does not need a 'Dirty' bit, just careful use of TOS, NOS and SP - note NOS is just a special temporary, and is NOT always the number below TOS - just a place holder for it, in case we need to access it.
Another optimization:
set SP to zog_base+zog_sp, only pushsp needs the "zog_sp" - there you can give it that by subtracting zog_base; VAST majority of accesses then sped up by removing an add
same for PC - set it to zog_base+zog_pc, only subtract out base before pushing it, and add on pops - again, vast majority of accesses want to deal with (zog_base + zog_pc), thus good optimization
I use these technique in several unpublished byte code interpreters I've built over the years, HUGE speedup [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Post Edited (Bill Henning) : 2/10/2010 3:22:48 PM GMT
See all the sample code in my previous reply ... I've been using this technique for quite a while, and it gives a huge speedup.
The latest VMCOG can easily serve up 16K of hub:
vm.start(@mailbox,$7C00,64) ' See VMDebug.spin, this will make virtual addresses $0000-$3FFF available for use right now.
The $7C00 is so VMCOG can run under SphinxOS.
Currently vm.rdvbyte(addr) and vm.wrvbyte(addr,val) messages work fine (see VMCOG.spin for implementation of those spin methods, shows you how to poke values into the mailbox and get results from it.
I hope to get rdvword/rdvlong/wrvword/wrvlong running today.
You will find commands 1,3,6 and 9 very useful for debugging.
1 - shows you the TLB, including dirty bit, physical address, and access count
3 - read a byte from specified virtual address
6 - write a byte to specified virtual address
9 - shows you a hex dump of a virtual page (as long as it is in the working set)
Later I may change to a command line monitor style debugger instead of menu's.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Post Edited (Bill Henning) : 2/10/2010 3:23:42 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
FYI, I just uploaded VMCOG v0.25 - this version adds aligned word and long reads from the working set
I am working on aligned word and long writes right now, and once those work as well, I will add support for non-aligned word/long reads/writes
non-aligned is a pain because it may cross page boundaries.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
But with Bill's suggested optimizations and the VM cache Zog might not be totally embarrassed. Especially in some odd contrived cases like running code directly from an attached SPI FLASH with data and stack in HUB.
Actually, that sounds like a damn useful use-case. How great it would be if Spin could execute from the program FLASH leaving all the RAM for working data.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Just for Humanoido's list.
For the Propeller ZPU emulator this:
class aclass { public: aclass() { a = 42; } int get() { return (a); } void set(int val) { a = val; } private: int a; }; int main (int argc, char* argv[noparse][[/noparse] ]) { aclass* aobj = new aclass(); aclass* bobj = new aclass(); bobj->set(aobj->get()); *aobj = *bobj; return (aobj->get()); }Produces this:
.file "hello.cpp" .text .globl main .type main, @function main: im -2 pushspadd popsp im 4 storesp 4 impcrel (_Znwm) callpcrel im _memreg+0 load storesp 12 im 42 nop im _memreg+0 load store .L3: im 4 storesp 4 impcrel (_Znwm) callpcrel im 42 nop im _memreg+0 load store .L6: loadsp 8 load loadsp 0 im _memreg+0 load store loadsp 0 loadsp 16 store .L1: im _memreg+0 store im 4 pushspadd popsp poppc .size main, .-main .ident "GCC: (GNU) 3.4.2"After doing this:
We will have Catalina and ICC totally on the mat when we get to being able to run that[noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Do you think it require external memory? Not a problem if it does, but would be nice to do reasonable stuff without it.
I finally made a Fedora uSD card so I can use the toolchain on my laptop. If you have a pointer to linux binaries, that would save a ton of work.
How would one download the program to the Propeller (without resident CPM, or other OS) ?
BTW, one offshoot of my 32 bit addressable Spin interpreter investigations/development would be running spin from any media including uSD as you suggested above. Having a compiler option to put stack and variables in HUB ram would make that possible ... preliminary discussion has started in this area. Not trying to hijack the thread of course.
Post Edited (jazzed) : 2/11/2010 5:31:00 PM GMT
You can download the binary release of GCC for ZPU from this page:
opensource.zylin.com/zpudownload.html
Make a directory for your zpu tool chain and change to it, I called mine zpu:
$ mkdir zpu
$ cd zpu
Put the down loaded package there and unpack it:
$ tar -xvjf zpugcclinux.tar.bz2
That will have created an "install" directory full of ZPU goodies.
Now you should be able to run GCC for ZPU.
$ ./bin/zpu-elf-gcc bla bla bla ...
See post above for options I use in compiling.
Zog will run fine without external memory. For sure the first versions will only use HUB RAM.
How useful that turns out to be remains to be seen. Catalina and ICC may be better/faster there although ZPU should have smaller binaries.
For now the ZPU binaries are downloaded within the Spin program. They are just included into a DAT section in a "file" statement. No other OS or software required.
I have yet to think about how this will work in future. Especially when we have external memory. Don't tempt me with getting CP/M to do it[noparse]:)[/noparse]
Zog could of course be fixed in the Propeller boot ROM as normal and include a simple secondary boot loader to get the ZPU binary down. But we should also think about integration with other objects in Spin like Catalina does. Early days yet. Or think about booting ZPU code from SD etc.
Spin from external RAM or FLASH would be great. Same with Zog. Similarly I have yet to figure out how to separate the code and data sections from a ZPU compilation.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I can give instructions if anyone wants.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
C++ polluting our beautiful Propeller???? Noooooooooo!
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Zog is now at the stage where it can, on the Propeller, limp around a simple C while(1); loop compiled with GCC.
As a bit of a retro computing fan I had to try and get GCC to compile some FORTRAN for Zog which it can then run on the Propeller. Results:
This FORTRAN program:
PROGRAM HELLOW * The PRINT statement is like WRITE, * but prints to the standard output unit PRINT*, '(A)', 'Hello, world' STOP ENDBecomes this Zog assembler for the Prop.
.file "test.for" .data .balign 4; .type __g77_cilist_0.0, @object .size __g77_cilist_0.0, 20 __g77_cilist_0.0: .long 0 .long 6 .long 0 .long 0 .long 0 .section .rodata .balign 4; .LC0: .ascii "(A)" .balign 4; .LC3: .ascii "Hello, world" .balign 4; .LC4: .section .rodata.cst4,"aM",@progbits,4 .balign 4; .LC1: .long 1 .balign 4; .LC2: .long 9 .text .globl MAIN__ .type MAIN__, @function MAIN__: im -3 pushspadd popsp im __g77_cilist_0.0 storesp 4 impcrel (s_wsle) callpcrel im 3 storesp 16 im .LC0 storesp 12 im .LC1 storesp 8 im .LC2 storesp 4 impcrel (do_lio) callpcrel im 12 storesp 16 im .LC3 storesp 12 im .LC1 storesp 8 im .LC2 storesp 4 impcrel (do_lio) callpcrel impcrel (e_wsle) callpcrel im 0 storesp 8 im .LC4 storesp 4 impcrel (s_stop) callpcrel .size MAIN__, .-MAIN__ .ident "GCC: (GNU) 3.4.2"It does not quite link into a complete executable program yet but we are nearly able to run FORTRAN on the Propeller!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
If you have FORTRAN compiling, why not go for COBOL [noparse];)[/noparse]
http://cobolforgcc.sourceforge.net/
Sounds like Zog is making progress. Keep up the great work!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Game(s) Mythic Flight
Utilities Font Editors (AIGeneric, Potato_Text, etc.)
What's next - ADA?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
As far as I can tell COBOL for GCC is not "done" yet. The version of GCC that the ZPU developers have used does not support COBOL and I doubt if they will ever bring there GCC version up to any newer version that may have COBOL.
Oh well.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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