I'm afraid all progress has halted here yesterday and today. I have a house full of electricians rewiring the place, dicking with the power and making a horrible noise. Everything is upside down.
Edit: Attachment removed, it was broken, mult optimization was incorrect. V1.5 is now out.
Attached is Zog V1.4
This has undergone a lot of little tweaks so I hope nothing has gone bust. Only had a quick test with fibo in HUB and Ext RAM.
Changes:
Removed some redundant use of the nos variable and nos itself.
Removed decode_mask, now use self-modified jmp to select first/next IM.
Fixed ZPU_SWAP.
Fixed zpu_storeh and zu_loadh (No longer uses EMULATE)
Removed EMULATE handler as it is no longer required.
Thanks to Lonsesock who spotted errors/optimization opportunities in: zpu_addsp, zpu_swap, zpu_neq, math_F4.
There are now 58 LONGs left in COG when using Ext RAM from VMCog. So it's time to find some new features to put in there.
Jazzed, do note that read_word and write_word now need implementing for your SDRAM.
Edit: N.B fibo still gives wrong results for fibo(25) and fibo(26) when running from VMCog. Other programs may also fail or crash and burn under with VMCog. Any news on that Bill?
If you want a few more longs to play with, I'm pretty sure I can reduce your "init" section to about 1/2 size, and move all variables to 'res'. Is 'zpu_pasm_addr' no longer used...can it be removed from the par block?
EDIT: to change the vars to use res, they would have to come after the dispatch table...is that a problem?
I can also gain you 1 long before the 255-long boundary, by making the entry/zpu_breakpoint jump to init, then patching zpu_breakpoint back to a jump (wastes a long after the 255-long boundary, though, so I'm guessing it's not really worth it.)
Jonathan
BIG EDIT: Oops, I'm an idiot: adding code and moving the vars to res does _not_ give you more COG longs. Please ignore this post...sorry.
Sorry, I have not found it yet - I have been spending most of my time trying to fully test all the new boards so I can get them into production.
I honestly don't know why it is crashing, I've gone over the code a million times and can't find it.
It is almost certainly something dumb like re-using a variable and clobbering something.
EDIT: VMCOG now runs on CPU#1 of Morpheus with 64KB VM. After I finish testing IR on the rev2 PCB, I will add FlexMem support to VMCOG and try to find the fibo issue... I will have three different SPI implementations to work with!
N.B fibo still gives wrong results for fibo(25) and fibo(26) when running from VMCog. Other programs may also fail or crash and burn under with VMCog. Any news on that Bill?
This is wasteful of space, but by having 2 versions of loadsp, storesp, and addsp, you can save one instruction in 3 of the 6 routines:
zpu_addsp and address, #$0F wz
if_z mov data, tos 'Handle case where offset = 0, this DOES happen.
if_nz shl address, #2
if_nz add address, sp
if_nz call #read_long
add tos, data
jmp #done_and_inc_pc
zpu_addsp_08 and address, #$0F 'No chance for an offset of 0, as bit 3 is set
shl address, #2
add address, sp
call #read_long
add tos, data
jmp #done_and_inc_pc
zpu_loadsp and address, #$0F
or address, #$10 'bit 4 was 0...Trust me, you need this.
shl address, #2
add address, sp
call #push_tos
call #read_long
mov tos, data
jmp #done_and_inc_pc
zpu_loadsp_10 and address, #$0F 'bit 4 was 1...Trust me, you need this.
shl address, #2
add address, sp
call #push_tos
call #read_long
mov tos, data
jmp #done_and_inc_pc
zpu_storesp and address, #$0F
or address, #$10 'bit 4 was 0...Trust me, you need this.
shl address, #2
add address, sp
mov data, tos
call #write_long
call #pop
mov tos, data
jmp #done_and_inc_pc
zpu_storesp_10 and address, #$0F 'bit 4 was 1...Trust me, you need this.
shl address, #2
add address, sp
mov data, tos
call #write_long
call #pop
mov tos, data
jmp #done_and_inc_pc
Now I'm headed to the medicine cabinet for some aspirin.
WARNING, casual reading of the Zog interpeter code can cause migrains and seizures. Prolonged study leads to permanent mental disorder.
Thing it's impossible to understand what Zog is doing unless you have a good grasp of the ZPU instruction set that it is emulating. That's not hard in itself but essential.
But, to make it more dangerous the ZOG PASM code is not written in the straight forward obvious way that one might do as a first attempt at the emulation. No it is twisted with optimizations and if you have ever looked at the code that an optimizing compiler produces you will know how tortuous that can be.
We have to thank Bill Henning for the major optimization twists that permeate the whole thing. His suggestions minimize the amount of times the interpreter has to access RAM. This is done by keeping the value of the ZPUs top of stack in COG as much as possible. This is important when using slow external RAM.
It took me quite a while to a) Understand what Bill was suggesting, b) Actually pull it off.
To do that I had to do:
1) Write a ZPU interpreter in C running on my PC.
2) Check the C version ran actual ZPU code.
3) Write a ZPU interpreter in PASM for the Prop.
4) Check the results of 1) and 2) against each other.
5) Rewrite the C version using Bills optimizations.
6) Check I understood it and it was working.
7) Use the optimized C version as a model to create the optimized PASM version.
8) Check results again.
From time to time it was necessary to check the execution of 100 of thousands of instructions ZPU code by any of the above against actual execution traces produced by the actual VHDL implementation of ZPU as used on FPGAs. Some funny bugs were hiding very well.
Now on top of that Lonesock is adding his own twists:)
Yes, sadly res is not a black hole we can fill up with data.
It might me important to have the dispatch table at the end in the future. Just so that when Zog is just a binary blob started up by something else that something else knows where to find the dispatch table. As you know Zog is designed to be able to move the dispatch table around in HUB and delete the original PASM when running.
As for 2 versions of loadsp, storesp, and addsp, I like the idea. It is similar to what we discussed about having special versions of those ops with fixed offsets in them.
Let's keep that in mind and do some testing on it the various options at some point.
Bill,
...I cannot quickly test with it, as it depends on FSRW and loading files on an SD.
As I suggested here the other day one could hack debug_zog to pull the executable in from a "file" statement to HUB and modify load_bytecodes to use that instead of reading the SD card. But knowing you perhaps tacking on the hardware falls to hand more easily.
I have this worrying feeling that zpu_loadsp and zpu_storesp go wrong when the offset is zero. Similar to zpu_addsp.
Originally I coded zpu_addsp without the test for zero offset hoping the ZPU compiler never generated such code. Of course eventually I found a case where it did and it failed. I've always thought this might happen to zpu_loadsp and zpu_storesp as well.
Just now I'm too tired to see what happens with zpu_loadsp and zpu_storesp in that case.
Should we just settle for having a variant of zpu_addsp just for the zero offset case thus removing one instruction from all the other cases?
@Heater: Regarding the special case for 0, using that for addsp makes the most sense for optimization (better than my addsp_08). When you say special case of 0 for loadsp and storesp, is the 0 special before or after the xor $10? I.e. I'm guessing my special case would be zpu_loadsp_10 instead of zpu_loadsp_00. No big deal, just need to change my nomenclature for the optimized-for-high-bit-is-1 case. Either way, a special case for the 0 => tos offset makes sense to me.
I made a quick patch like that, but the compiled image was >32KB. I'll have to toss some stuff out, or plug in Mem+ into the new Morpheus, or patch fsrw for uSD on PropCade... all very feasible, after I finish the new boards.
As I suggested here the other day one could hack debug_zog to pull the executable in from a "file" statement to HUB and modify load_bytecodes to use that instead of reading the SD card. But knowing you perhaps tacking on the hardware falls to hand more easily.
zpu_addsp_0 add tos, tos 'Special case for offset = 0
jmp #done_and_inc_pc
zpu_addsp and address, #$0F
shl address, #2
add address, sp
call #read_long
add tos, data
jmp #done_and_inc_pc
zpu_loadsp_tos call #push_tos
jmp #done_and_inc_pc
zpu_loadsp_hi ' this will fall through if we're saving space
#ifdef SPEED_ADD_LOAD_STORE_SP
and address, #$0F 'bit 4 was 1...Trust me, you need this.
shl address, #2
add address, sp
call #push_tos
call #read_long
mov tos, data
jmp #done_and_inc_pc
#endif
zpu_loadsp and address, #$1F
xor address, #$10 'Trust me, you need this.
shl address, #2
add address, sp
call #push_tos
call #read_long
mov tos, data
jmp #done_and_inc_pc
zpu_storesp_tos call #pop
mov tos, data
jmp #done_and_inc_pc
zpu_storesp_hi ' this will fall through if we're saving space
#ifdef SPEED_ADD_LOAD_STORE_SP
and address, #$0F 'bit 4 was 1...Trust me, you need this.
shl address, #2
add address, sp
mov data, tos
call #write_long
call #pop
mov tos, data
jmp #done_and_inc_pc
#endif
zpu_storesp and address, #$1F
xor address, #$10 'Trust me, you need this.
shl address, #2
add address, sp
mov data, tos
call #write_long
call #pop
mov tos, data
jmp #done_and_inc_pc
The new zog feels faster than before Cudo's to heater and lonesock!
I've added SDRAM Cache to zog_v1_4 in the attachment. The default fibo test works fine. I'm having some trouble with the malloc memory test with this kernel, and will look at that more soon. Meanwhile fibo.bin tests results are posted.
@Heater,
A change for debug_zog.spin I am proposing and have included is USERDEFS. It is up to you to include of course, but if you choose to keep this method, it would mean less work for users who have different hardware and clock requirements. I think you will find other opportunities for build flexibility there as well.
If you build with USERDEFS defined, the compiler will look for userdefs.spin. Building without USERDEFS gives Heater's original hardware definitions. Before this will work, a user should copy userdefs_template.spin to their library directory as userdefs.spin and modify that file for their own clock and hardware pin definitions. Putting userdefs.spin in a library location is better than keeping it in the zog directory.
An example for specifying a library path in bstc is:
bstc -D USERDEFS -L /home/steve/spin -Orx -p0 debug_zog.spin
A userdefs.spin should never be included in a new .zip package; userdefs_template.spin should be there of course.
In the code portion I just posted, zpu_loadsp and zpu_storesp now have a special case for offset==0, which _may_ have been malfunctioning previously. I will download the toolchain (good excuse to do so...I've been just using fibo.bin) and play around with this as well, though you guys are much more experienced using zog. Do you recommend the stable or snapshot version?
Jonathan
EDIT: does it run on 1.3? I see a yes on 1.2, no on 1.4.
No problem; just growing pains. Someday we'll be able to run the gcc test suite and ZOG may have lots of bumps and bruises before he's ready - kind of like my grandson
Well, I am not having any luck getting the toolchain working on my PC. (It's cool to have a GCC compiler for the prop, but seems a bit tricky to get working on Windows.)
I mentioned version 1.3 on the off chance that the break happened there instead of in 1.4.
For some reason .bin files built under Cygwin are more than 2x bigger than the ones built on linux. I don't get it. So even if you could get zog compiling under windows the mall.c file would need to be hacked down big-time.
mall.c works if I revert math_F4 back to the v1.3 version.
Which is lucky because it was the first thing I reverted after studying diffs of our changes and deciding that is the only change I did not full agree with (because I don't understand it fully:))
If anyone can see what is wrong with mmul in v1.4 then I'll fix it else there will be a v1.5 release with the old mmul back in and Jazzed's SDRAM additions.
I just built mall under cycgwin. The binary is 20 bytes SMALLER than when building under Linux. Are you sure you have ZOG defined when compiling?
Guess I missed the ZOG define requirement. Where is it to be defined?
I was thinking about Makefiles a little today. Seems that there should be a common makefile in test that all the other test/*/Makefile files can include. Also, is it possible for the linker to be less verbose by default?
At some point I was having to running something under ZOG and Linux so I introduced ZOG to select iprintf or printf. That does not seem to have made it into any of the current Makefiles but it did make it into your mall.c
As for verbose just remove "-Wl,--verbose" from the LDFLAGS. Again that comes from an experiment in messing with linker scripts so it can go.
As for a common Makefile: I hate Makefiles. Try as I might I don't think I'm going to live long enough to understand their intricacies. Pretty much every large project I've worked on has had huge, complicated, recursive, inclusive whatever Makefiles all done in a different style. Preferably people like to throw in a whole load of shell script just to make sure it's illegible:)
Having said that if you can come up with a simplified make system I'll gladly adopt it.
mall.c works if I revert math_F4 back to the v1.3 version.
Which is lucky because it was the first thing I reverted after studying diffs of our changes and deciding that is the only change I did not full agree with (because I don't understand it fully:))
If anyone can see what is wrong with mmul in v1.4 then I'll fix it else there will be a v1.5 release with the old mmul back in and Jazzed's SDRAM additions.
I just built mall under cycgwin. The binary is 20 bytes SMALLER than when building under Linux. Are you sure you have ZOG defined when compiling?
My bad. I tried to massage my existing (and working) multiplication code into zog, but without a working toolchain I didn't know how to test it in situ. I will continue banging my head on the wall over here until I can figure it out. [8^)
I did try, on a win7 64-bit machine...maybe that screwed things up? I'm trying an install of cygwin now on this older XP machine, but with my download speeds here, it will be a while!
Do you happen to have a version of mall.c precompiled that I can test in Hub RAM?
@jazzed: OK, looked at the multiplication code some more, and it seems 'x' must not be modified, so I have 2 different code changes for you to try...just replacing the mmul long and the 3 prior to that.
If it's OK to modify 'y', then this would be a good version to use:
' make t2 the smaller of the 2 parameters
' NOTE: x must not be modified!
mov t2, x
max t2, y
min y, x
mmul shr t2,#1 wc,wz 'multiply
Otherwise, if that doesn't work, try this one:
' make t2 a copy of x
' NOTE: neither x nor y may be modified!
mov t2, x
mmul shr t2,#1 wc,wz 'multiply
Jonathan
EDIT: To be clear, the above it to patch the zog 1.4 code.
Comments
Not necessarily.
You could modify debug_zog a little.
Arrange that your ZPU binary is included from a "file" statement. As it is when compiling debug_zog with USE_HUB_MEMORY in effect.
Make yourself a new load_bytecode method that reads the bytes from that included binary and writes them to VMCog.
That is actually how I got started using VMCog with Zog. It's OK until your binaries are too big to fit in HUB space.
I'm afraid all progress has halted here yesterday and today. I have a house full of electricians rewiring the place, dicking with the power and making a horrible noise. Everything is upside down.
Attached is Zog V1.4
This has undergone a lot of little tweaks so I hope nothing has gone bust. Only had a quick test with fibo in HUB and Ext RAM.
Changes:
Removed some redundant use of the nos variable and nos itself.
Removed decode_mask, now use self-modified jmp to select first/next IM.
Fixed ZPU_SWAP.
Fixed zpu_storeh and zu_loadh (No longer uses EMULATE)
Removed EMULATE handler as it is no longer required.
Thanks to Lonsesock who spotted errors/optimization opportunities in: zpu_addsp, zpu_swap, zpu_neq, math_F4.
There are now 58 LONGs left in COG when using Ext RAM from VMCog. So it's time to find some new features to put in there.
Jazzed, do note that read_word and write_word now need implementing for your SDRAM.
Edit: N.B fibo still gives wrong results for fibo(25) and fibo(26) when running from VMCog. Other programs may also fail or crash and burn under with VMCog. Any news on that Bill?
EDIT: ignore from here down!
If you want a few more longs to play with, I'm pretty sure I can reduce your "init" section to about 1/2 size, and move all variables to 'res'. Is 'zpu_pasm_addr' no longer used...can it be removed from the par block?
EDIT: to change the vars to use res, they would have to come after the dispatch table...is that a problem?
I can also gain you 1 long before the 255-long boundary, by making the entry/zpu_breakpoint jump to init, then patching zpu_breakpoint back to a jump (wastes a long after the 255-long boundary, though, so I'm guessing it's not really worth it.)
Jonathan
BIG EDIT: Oops, I'm an idiot: adding code and moving the vars to res does _not_ give you more COG longs. Please ignore this post...sorry.
@Heater.
Unfortunately, I can't integrate changes right away. The rest of my day is shot. I'll get to it as soon as I can though.
Thanks
I honestly don't know why it is crashing, I've gone over the code a million times and can't find it.
It is almost certainly something dumb like re-using a variable and clobbering something.
EDIT: VMCOG now runs on CPU#1 of Morpheus with 64KB VM. After I finish testing IR on the rev2 PCB, I will add FlexMem support to VMCOG and try to find the fibo issue... I will have three different SPI implementations to work with!
zpu_addsp and address, #$0F wz if_z mov data, tos 'Handle case where offset = 0, this DOES happen. if_nz shl address, #2 if_nz add address, sp if_nz call #read_long add tos, data jmp #done_and_inc_pc zpu_addsp_08 and address, #$0F 'No chance for an offset of 0, as bit 3 is set shl address, #2 add address, sp call #read_long add tos, data jmp #done_and_inc_pc zpu_loadsp and address, #$0F or address, #$10 'bit 4 was 0...Trust me, you need this. shl address, #2 add address, sp call #push_tos call #read_long mov tos, data jmp #done_and_inc_pc zpu_loadsp_10 and address, #$0F 'bit 4 was 1...Trust me, you need this. shl address, #2 add address, sp call #push_tos call #read_long mov tos, data jmp #done_and_inc_pc zpu_storesp and address, #$0F or address, #$10 'bit 4 was 0...Trust me, you need this. shl address, #2 add address, sp mov data, tos call #write_long call #pop mov tos, data jmp #done_and_inc_pc zpu_storesp_10 and address, #$0F 'bit 4 was 1...Trust me, you need this. shl address, #2 add address, sp mov data, tos call #write_long call #pop mov tos, data jmp #done_and_inc_pcThe new dispatch table would look like thisdispatch_table {00} byte zpu_breakpoint {01} byte zpu_illegal {02} byte zpu_pushsp {03} byte zpu_illegal {04} byte zpu_poppc {05} byte zpu_add {06} byte zpu_and {07} byte zpu_or {08} byte zpu_load {09} byte zpu_not {0A} byte zpu_flip {0B} byte zpu_nop {0C} byte zpu_store {0D} byte zpu_popsp {0E} byte zpu_illegal {0F} byte zpu_illegal {10} byte zpu_addsp {11} byte zpu_addsp {12} byte zpu_addsp {13} byte zpu_addsp {14} byte zpu_addsp {15} byte zpu_addsp {16} byte zpu_addsp {17} byte zpu_addsp {18} byte zpu_addsp_08 {19} byte zpu_addsp_08 {1A} byte zpu_addsp_08 {1B} byte zpu_addsp_08 {1C} byte zpu_addsp_08 {1D} byte zpu_addsp_08 {1E} byte zpu_addsp_08 {1F} byte zpu_addsp_08 {20} byte not_implemented' zpu_emulate {21} byte not_implemented' zpu_emulate {22} byte zpu_loadh {23} byte zpu_storeh {24} byte zpu_lessthan {25} byte zpu_lessthanorequal {26} byte zpu_ulessthan {27} byte zpu_ulessthanorequal {28} byte zpu_swap {29} byte zpu_mult {2A} byte zpu_lshiftright {2B} byte zpu_ashiftleft {2C} byte zpu_ashiftright {2D} byte zpu_call {2E} byte zpu_eq {2F} byte zpu_neq {30} byte zpu_neg {31} byte zpu_sub {32} byte zpu_xor {33} byte zpu_loadb {34} byte zpu_storeb {35} byte zpu_div {36} byte zpu_mod {37} byte zpu_eqbranch {38} byte zpu_neqbranch {39} byte zpu_poppcrel {3A} byte zpu_config {3B} byte zpu_pushpc {3C} byte zpu_syscall {3D} byte zpu_pushspadd {3E} byte zpu_mult16x16 {3F} byte zpu_callpcrel {40} byte zpu_storesp {41} byte zpu_storesp {42} byte zpu_storesp {43} byte zpu_storesp {44} byte zpu_storesp {45} byte zpu_storesp {46} byte zpu_storesp {47} byte zpu_storesp {48} byte zpu_storesp {49} byte zpu_storesp {4A} byte zpu_storesp {4B} byte zpu_storesp {4C} byte zpu_storesp {4D} byte zpu_storesp {4E} byte zpu_storesp {4F} byte zpu_storesp {50} byte zpu_storesp_10 {51} byte zpu_storesp_10 {52} byte zpu_storesp_10 {53} byte zpu_storesp_10 {54} byte zpu_storesp_10 {55} byte zpu_storesp_10 {56} byte zpu_storesp_10 {57} byte zpu_storesp_10 {58} byte zpu_storesp_10 {59} byte zpu_storesp_10 {5A} byte zpu_storesp_10 {5B} byte zpu_storesp_10 {5C} byte zpu_storesp_10 {5D} byte zpu_storesp_10 {5E} byte zpu_storesp_10 {5F} byte zpu_storesp_10 {60} byte zpu_loadsp {61} byte zpu_loadsp {62} byte zpu_loadsp {63} byte zpu_loadsp {64} byte zpu_loadsp {65} byte zpu_loadsp {66} byte zpu_loadsp {67} byte zpu_loadsp {68} byte zpu_loadsp {69} byte zpu_loadsp {6A} byte zpu_loadsp {6B} byte zpu_loadsp {6C} byte zpu_loadsp {6D} byte zpu_loadsp {6E} byte zpu_loadsp {6F} byte zpu_loadsp {70} byte zpu_loadsp_10 {71} byte zpu_loadsp_10 {72} byte zpu_loadsp_10 {73} byte zpu_loadsp_10 {74} byte zpu_loadsp_10 {75} byte zpu_loadsp_10 {76} byte zpu_loadsp_10 {77} byte zpu_loadsp_10 {78} byte zpu_loadsp_10 {79} byte zpu_loadsp_10 {7A} byte zpu_loadsp_10 {7B} byte zpu_loadsp_10 {7C} byte zpu_loadsp_10 {7D} byte zpu_loadsp_10 {7E} byte zpu_loadsp_10 {7F} byte zpu_loadsp_10~1.8% improvement in fibo(26).Jonathan
Seriously, I can't believe how much you've accomplished. What do you do in your spare time?
WARNING, casual reading of the Zog interpeter code can cause migrains and seizures. Prolonged study leads to permanent mental disorder.
Thing it's impossible to understand what Zog is doing unless you have a good grasp of the ZPU instruction set that it is emulating. That's not hard in itself but essential.
But, to make it more dangerous the ZOG PASM code is not written in the straight forward obvious way that one might do as a first attempt at the emulation. No it is twisted with optimizations and if you have ever looked at the code that an optimizing compiler produces you will know how tortuous that can be.
We have to thank Bill Henning for the major optimization twists that permeate the whole thing. His suggestions minimize the amount of times the interpreter has to access RAM. This is done by keeping the value of the ZPUs top of stack in COG as much as possible. This is important when using slow external RAM.
It took me quite a while to a) Understand what Bill was suggesting, b) Actually pull it off.
To do that I had to do:
1) Write a ZPU interpreter in C running on my PC.
2) Check the C version ran actual ZPU code.
3) Write a ZPU interpreter in PASM for the Prop.
4) Check the results of 1) and 2) against each other.
5) Rewrite the C version using Bills optimizations.
6) Check I understood it and it was working.
7) Use the optimized C version as a model to create the optimized PASM version.
8) Check results again.
From time to time it was necessary to check the execution of 100 of thousands of instructions ZPU code by any of the above against actual execution traces produced by the actual VHDL implementation of ZPU as used on FPGAs. Some funny bugs were hiding very well.
Now on top of that Lonesock is adding his own twists:)
Therapy, medication, self help groups...
Yes, sadly res is not a black hole we can fill up with data.
It might me important to have the dispatch table at the end in the future. Just so that when Zog is just a binary blob started up by something else that something else knows where to find the dispatch table. As you know Zog is designed to be able to move the dispatch table around in HUB and delete the original PASM when running.
As for 2 versions of loadsp, storesp, and addsp, I like the idea. It is similar to what we discussed about having special versions of those ops with fixed offsets in them.
Let's keep that in mind and do some testing on it the various options at some point.
Bill,
As I suggested here the other day one could hack debug_zog to pull the executable in from a "file" statement to HUB and modify load_bytecodes to use that instead of reading the SD card. But knowing you perhaps tacking on the hardware falls to hand more easily.
I have this worrying feeling that zpu_loadsp and zpu_storesp go wrong when the offset is zero. Similar to zpu_addsp.
Originally I coded zpu_addsp without the test for zero offset hoping the ZPU compiler never generated such code. Of course eventually I found a case where it did and it failed. I've always thought this might happen to zpu_loadsp and zpu_storesp as well.
Just now I'm too tired to see what happens with zpu_loadsp and zpu_storesp in that case.
Should we just settle for having a variant of zpu_addsp just for the zero offset case thus removing one instruction from all the other cases?
Jonathan
You read my mind
I made a quick patch like that, but the compiled image was >32KB. I'll have to toss some stuff out, or plug in Mem+ into the new Morpheus, or patch fsrw for uSD on PropCade... all very feasible, after I finish the new boards.
zpu_addsp_0 add tos, tos 'Special case for offset = 0 jmp #done_and_inc_pc zpu_addsp and address, #$0F shl address, #2 add address, sp call #read_long add tos, data jmp #done_and_inc_pc zpu_loadsp_tos call #push_tos jmp #done_and_inc_pc zpu_loadsp_hi ' this will fall through if we're saving space #ifdef SPEED_ADD_LOAD_STORE_SP and address, #$0F 'bit 4 was 1...Trust me, you need this. shl address, #2 add address, sp call #push_tos call #read_long mov tos, data jmp #done_and_inc_pc #endif zpu_loadsp and address, #$1F xor address, #$10 'Trust me, you need this. shl address, #2 add address, sp call #push_tos call #read_long mov tos, data jmp #done_and_inc_pc zpu_storesp_tos call #pop mov tos, data jmp #done_and_inc_pc zpu_storesp_hi ' this will fall through if we're saving space #ifdef SPEED_ADD_LOAD_STORE_SP and address, #$0F 'bit 4 was 1...Trust me, you need this. shl address, #2 add address, sp mov data, tos call #write_long call #pop mov tos, data jmp #done_and_inc_pc #endif zpu_storesp and address, #$1F xor address, #$10 'Trust me, you need this. shl address, #2 add address, sp mov data, tos call #write_long call #pop mov tos, data jmp #done_and_inc_pcdispatch_table {00} byte zpu_breakpoint {01} byte zpu_illegal {02} byte zpu_pushsp {03} byte zpu_illegal {04} byte zpu_poppc {05} byte zpu_add {06} byte zpu_and {07} byte zpu_or {08} byte zpu_load {09} byte zpu_not {0A} byte zpu_flip {0B} byte zpu_nop {0C} byte zpu_store {0D} byte zpu_popsp {0E} byte zpu_illegal {0F} byte zpu_illegal {10} byte zpu_addsp_0 {11} byte zpu_addsp {12} byte zpu_addsp {13} byte zpu_addsp {14} byte zpu_addsp {15} byte zpu_addsp {16} byte zpu_addsp {17} byte zpu_addsp {18} byte zpu_addsp {19} byte zpu_addsp {1A} byte zpu_addsp {1B} byte zpu_addsp {1C} byte zpu_addsp {1D} byte zpu_addsp {1E} byte zpu_addsp {1F} byte zpu_addsp {20} byte not_implemented' zpu_emulate {21} byte not_implemented' zpu_emulate {22} byte zpu_loadh {23} byte zpu_storeh {24} byte zpu_lessthan {25} byte zpu_lessthanorequal {26} byte zpu_ulessthan {27} byte zpu_ulessthanorequal {28} byte zpu_swap {29} byte zpu_mult {2A} byte zpu_lshiftright {2B} byte zpu_ashiftleft {2C} byte zpu_ashiftright {2D} byte zpu_call {2E} byte zpu_eq {2F} byte zpu_neq {30} byte zpu_neg {31} byte zpu_sub {32} byte zpu_xor {33} byte zpu_loadb {34} byte zpu_storeb {35} byte zpu_div {36} byte zpu_mod {37} byte zpu_eqbranch {38} byte zpu_neqbranch {39} byte zpu_poppcrel {3A} byte zpu_config {3B} byte zpu_pushpc {3C} byte zpu_syscall {3D} byte zpu_pushspadd {3E} byte zpu_mult16x16 {3F} byte zpu_callpcrel {40} byte zpu_storesp {41} byte zpu_storesp {42} byte zpu_storesp {43} byte zpu_storesp {44} byte zpu_storesp {45} byte zpu_storesp {46} byte zpu_storesp {47} byte zpu_storesp {48} byte zpu_storesp {49} byte zpu_storesp {4A} byte zpu_storesp {4B} byte zpu_storesp {4C} byte zpu_storesp {4D} byte zpu_storesp {4E} byte zpu_storesp {4F} byte zpu_storesp {50} byte zpu_storesp_tos {51} byte zpu_storesp_hi {52} byte zpu_storesp_hi {53} byte zpu_storesp_hi {54} byte zpu_storesp_hi {55} byte zpu_storesp_hi {56} byte zpu_storesp_hi {57} byte zpu_storesp_hi {58} byte zpu_storesp_hi {59} byte zpu_storesp_hi {5A} byte zpu_storesp_hi {5B} byte zpu_storesp_hi {5C} byte zpu_storesp_hi {5D} byte zpu_storesp_hi {5E} byte zpu_storesp_hi {5F} byte zpu_storesp_hi {60} byte zpu_loadsp {61} byte zpu_loadsp {62} byte zpu_loadsp {63} byte zpu_loadsp {64} byte zpu_loadsp {65} byte zpu_loadsp {66} byte zpu_loadsp {67} byte zpu_loadsp {68} byte zpu_loadsp {69} byte zpu_loadsp {6A} byte zpu_loadsp {6B} byte zpu_loadsp {6C} byte zpu_loadsp {6D} byte zpu_loadsp {6E} byte zpu_loadsp {6F} byte zpu_loadsp {70} byte zpu_loadsp_tos {71} byte zpu_loadsp_hi {72} byte zpu_loadsp_hi {73} byte zpu_loadsp_hi {74} byte zpu_loadsp_hi {75} byte zpu_loadsp_hi {76} byte zpu_loadsp_hi {77} byte zpu_loadsp_hi {78} byte zpu_loadsp_hi {79} byte zpu_loadsp_hi {7A} byte zpu_loadsp_hi {7B} byte zpu_loadsp_hi {7C} byte zpu_loadsp_hi {7D} byte zpu_loadsp_hi {7E} byte zpu_loadsp_hi {7F} byte zpu_loadsp_hiJonathanThe new zog feels faster than before
I've added SDRAM Cache to zog_v1_4 in the attachment. The default fibo test works fine. I'm having some trouble with the malloc memory test with this kernel, and will look at that more soon. Meanwhile fibo.bin tests results are posted.
@Heater,
A change for debug_zog.spin I am proposing and have included is USERDEFS. It is up to you to include of course, but if you choose to keep this method, it would mean less work for users who have different hardware and clock requirements. I think you will find other opportunities for build flexibility there as well.
If you build with USERDEFS defined, the compiler will look for userdefs.spin. Building without USERDEFS gives Heater's original hardware definitions. Before this will work, a user should copy userdefs_template.spin to their library directory as userdefs.spin and modify that file for their own clock and hardware pin definitions. Putting userdefs.spin in a library location is better than keeping it in the zog directory.
An example for specifying a library path in bstc is:
bstc -D USERDEFS -L /home/steve/spin -Orx -p0 debug_zog.spin
A userdefs.spin should never be included in a new .zip package; userdefs_template.spin should be there of course.
Cheers,
--Steve
It works with my v1_2 code but not v1_4 code.
I've modified the mall.c program a little and can run it from HUB.
It fails the same way running from HUB as it does running from SDRAM.
The problem appears to be that dereferencing a pointer with array syntax does not work:
iprintf("testprand %x %x %08x\r\n",size,count,seed); iprintf("0x%x - 0x%x\r\n", ptr, &ptr[count-1]);I'm attaching updated mall.c code for testing. I'll try running this
with zog_v1_4 as it was originally posted, but I'm not very hopeful.
Update: I tried the same test with HUB zog_v1_4 and it also failed.
--Steve
If I can find a moment I'll revert to 1.3 and reapply the changes one by one till the fault shows up with mall.
[8^/
In the code portion I just posted, zpu_loadsp and zpu_storesp now have a special case for offset==0, which _may_ have been malfunctioning previously. I will download the toolchain (good excuse to do so...I've been just using fibo.bin) and play around with this as well, though you guys are much more experienced using zog. Do you recommend the stable or snapshot version?
Jonathan
EDIT: does it run on 1.3? I see a yes on 1.2, no on 1.4.
I never used v1_3.
I mentioned version 1.3 on the off chance that the break happened there instead of in 1.4.
Jonathan
Which is lucky because it was the first thing I reverted after studying diffs of our changes and deciding that is the only change I did not full agree with (because I don't understand it fully:))
If anyone can see what is wrong with mmul in v1.4 then I'll fix it else there will be a v1.5 release with the old mmul back in and Jazzed's SDRAM additions.
I just built mall under cycgwin. The binary is 20 bytes SMALLER than when building under Linux. Are you sure you have ZOG defined when compiling?
Guess I missed the ZOG define requirement. Where is it to be defined?
I was thinking about Makefiles a little today. Seems that there should be a common makefile in test that all the other test/*/Makefile files can include. Also, is it possible for the linker to be less verbose by default?
Thanks,
--Steve
in the Make file.
At some point I was having to running something under ZOG and Linux so I introduced ZOG to select iprintf or printf. That does not seem to have made it into any of the current Makefiles but it did make it into your mall.c
As for verbose just remove "-Wl,--verbose" from the LDFLAGS. Again that comes from an experiment in messing with linker scripts so it can go.
As for a common Makefile: I hate Makefiles. Try as I might I don't think I'm going to live long enough to understand their intricacies. Pretty much every large project I've worked on has had huge, complicated, recursive, inclusive whatever Makefiles all done in a different style. Preferably people like to throw in a whole load of shell script just to make sure it's illegible:)
Having said that if you can come up with a simplified make system I'll gladly adopt it.
My bad. I tried to massage my existing (and working) multiplication code into zog, but without a working toolchain I didn't know how to test it in situ. I will continue banging my head on the wall over here until I can figure it out. [8^)
Jonathan
I'll visit the makefiles after the zog 1.5 release.
@Lonesock, do you have Cygwin installed?
Do you happen to have a version of mall.c precompiled that I can test in Hub RAM?
Jonathan
If it's OK to modify 'y', then this would be a good version to use:
' make t2 the smaller of the 2 parameters ' NOTE: x must not be modified! mov t2, x max t2, y min y, x mmul shr t2,#1 wc,wz 'multiplyOtherwise, if that doesn't work, try this one:
' make t2 a copy of x ' NOTE: neither x nor y may be modified! mov t2, x mmul shr t2,#1 wc,wz 'multiplyJonathan
EDIT: To be clear, the above it to patch the zog 1.4 code.