I'm getting dizzy! DRC cancelled. But LMM for all the opcodes almost done?!
Well the half completed LMM code is now running on all my propeller boards (8080 ops) so am looking forward to all the rest.
Now I have several kilobytes of unused hub ram, what could it be used for? A bit will be needed for the new instructions, but maybe there is enough left over for a simple cache system? I'm still thinking about moving code blocks of 128 bytes into hub ram. Just looking at source code of various Z80 programs you might end up caching a bit of CP/M from high ram plus the local bit of the program. And the cache bits can use recycled hub ram from cogs as I know that works. This is just a dream though - I'll wait till all the Z80 opcodes are done first.
pullmoll, has that board arrived yet? Or did they send it by pigeon post?
Damn #1) I was looking forward, to when my work panic is eased up, to spending some quality time studying your DRC technique. There is less incentive to do so if the project is cancelled.
Damn #2) Looks like ZiCog has a serious competitor now [noparse]:)[/noparse]
The first of those is a shame but there's a lot of other projects to be getting on with. Last year I spent some time building a Z80 for the Prop that spread code over 4 COGs. Not for parallel processing, only one COG operated a time, but just to be able to have lots of PASM space. I had to cancel that attempt. It did not have the speed, the overheads of selecting the COGs, writing out PC and FLAGS to HUB etc was to much. Besides I decided using four 32 bit CPU's to do this is nuts.
The second "damn" is serious. I'll be very interested to see how this pans out in the speed stakes.
There are two competing techniques here:
1) ZiCog - Has a bunch of "micro-ops" in COG for speed. Z80 instructions are built up by defining sequences of micro-ops to be executed. Those sequences being coded in fields in the dispatch tables. This carries the overhead of pulling the micro op addresses out of the dispatch table entries.
2) PiCog (Pullmoll Zilog Z80 ina COG?) - Do everything in LMM but put common code in subroutines in COG for speed. Carries the over head of LMM.
A long time ago I started down the LMM road with the old PropAltair emulator. It to was cancelled. I could not get the speed out of it. That may well have been the result of my bolting LMM onto an existing 8080 emulator in a hackish fashion rather than starting with a clean slate and building it in an orderly manner.
Looks like Pullmoll may have a winner here. ZiCog may get cancelled[noparse]:([/noparse]
So be it, there may be a lesson to learn here for the Motorola 6809 emulator. MoCog started to use a lot of overlays and be very tight on COG space. Turning that over to LMM may be just the ticket.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
If an address in the dispatch table entry for a Z80 instruction was less than 512 the dispatch loop jumped to that code in COG directly.
If the address was >= 512 it set the LMM program counter to the address and jumped to the LMM execution loop.
In this way ops could be moved from COG to HUB or vice versa very easily.
If you can keep the regs in COG you gave a speed gain AND all the MOV reg, reg instructions can be done in a very small fast routine. Z80 code has a lot of those MOVs so this is a killer optimization.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Dr_Acula said...
I'm getting dizzy! DRC cancelled. But LMM for all the opcodes almost done?!
Well the half completed LMM code is now running on all my propeller boards (8080 ops) so am looking forward to all the rest.
Now I have several kilobytes of unused hub ram, what could it be used for? A bit will be needed for the new instructions, but maybe there is enough left over for a simple cache system? I'm still thinking about moving code blocks of 128 bytes into hub ram. Just looking at source code of various Z80 programs you might end up caching a bit of CP/M from high ram plus the local bit of the program. And the cache bits can use recycled hub ram from cogs as I know that works. This is just a dream though - I'll wait till all the Z80 opcodes are done first.
pullmoll, has that board arrived yet? Or did they send it by pigeon post?
Guess who rang my doorbell a few minutes ago
It doesn't want to be programmed by bst.linux through serial, though.
Yes, almost done. Copy + paste at its best.
I don't know how much bigger yaz80 is compared to zicog. It will most probably be larger, because it has the undocumented opcodes also. Let's see how this all works out.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Hehehe... we think alike! I've used that trick in a couple of vmm's!
as I recall, I used:
andn vpc,#$1ff nr wz
if_z jmp vpc ' cog micro-op
next ... lmm kernel unrolled 4 times goes here
heater said...
One little trick I used in PropAltair.
If an address in the dispatch table entry for a Z80 instruction was less than 512 the dispatch loop jumped to that code in COG directly.
If the address was >= 512 it set the LMM program counter to the address and jumped to the LMM execution loop.
In this way ops could be moved from COG to HUB or vice versa very easily.
If you can keep the regs in COG you gave a speed gain AND all the MOV reg, reg instructions can be done in a very small fast routine. Z80 code has a lot of those MOVs so this is a killer optimization.
Comments
Well the half completed LMM code is now running on all my propeller boards (8080 ops) so am looking forward to all the rest.
Now I have several kilobytes of unused hub ram, what could it be used for? A bit will be needed for the new instructions, but maybe there is enough left over for a simple cache system? I'm still thinking about moving code blocks of 128 bytes into hub ram. Just looking at source code of various Z80 programs you might end up caching a bit of CP/M from high ram plus the local bit of the program. And the cache bits can use recycled hub ram from cogs as I know that works. This is just a dream though - I'll wait till all the Z80 opcodes are done first.
pullmoll, has that board arrived yet? Or did they send it by pigeon post?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Yes. It was a rather simple copy + paste orgy. I hope I didn't make too many mistakes, but it's looking good.
No, nothing yet :-(
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Damn #1) I was looking forward, to when my work panic is eased up, to spending some quality time studying your DRC technique. There is less incentive to do so if the project is cancelled.
Damn #2) Looks like ZiCog has a serious competitor now [noparse]:)[/noparse]
The first of those is a shame but there's a lot of other projects to be getting on with. Last year I spent some time building a Z80 for the Prop that spread code over 4 COGs. Not for parallel processing, only one COG operated a time, but just to be able to have lots of PASM space. I had to cancel that attempt. It did not have the speed, the overheads of selecting the COGs, writing out PC and FLAGS to HUB etc was to much. Besides I decided using four 32 bit CPU's to do this is nuts.
The second "damn" is serious. I'll be very interested to see how this pans out in the speed stakes.
There are two competing techniques here:
1) ZiCog - Has a bunch of "micro-ops" in COG for speed. Z80 instructions are built up by defining sequences of micro-ops to be executed. Those sequences being coded in fields in the dispatch tables. This carries the overhead of pulling the micro op addresses out of the dispatch table entries.
2) PiCog (Pullmoll Zilog Z80 ina COG?) - Do everything in LMM but put common code in subroutines in COG for speed. Carries the over head of LMM.
A long time ago I started down the LMM road with the old PropAltair emulator. It to was cancelled. I could not get the speed out of it. That may well have been the result of my bolting LMM onto an existing 8080 emulator in a hackish fashion rather than starting with a clean slate and building it in an orderly manner.
Looks like Pullmoll may have a winner here. ZiCog may get cancelled[noparse]:([/noparse]
So be it, there may be a lesson to learn here for the Motorola 6809 emulator. MoCog started to use a lot of overlays and be very tight on COG space. Turning that over to LMM may be just the ticket.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
If an address in the dispatch table entry for a Z80 instruction was less than 512 the dispatch loop jumped to that code in COG directly.
If the address was >= 512 it set the LMM program counter to the address and jumped to the LMM execution loop.
In this way ops could be moved from COG to HUB or vice versa very easily.
If you can keep the regs in COG you gave a speed gain AND all the MOV reg, reg instructions can be done in a very small fast routine. Z80 code has a lot of those MOVs so this is a killer optimization.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Guess who rang my doorbell a few minutes ago
It doesn't want to be programmed by bst.linux through serial, though.
Yes, almost done. Copy + paste at its best.
I don't know how much bigger yaz80 is compared to zicog. It will most probably be larger, because it has the undocumented opcodes also. Let's see how this all works out.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Post Edited (pullmoll) : 3/19/2010 9:57:12 AM GMT
as I recall, I used:
andn vpc,#$1ff nr wz if_z jmp vpc ' cog micro-op next ... lmm kernel unrolled 4 times goes here▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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