Stack overflows have bugged me enough over the years. They are a special case of memory corruption which is even more insidious when its some stray pointer access done by some code that apparently works OK but causes other functions to fail at random some time later.
Bills stack guard will prove the point one way or the other which is a "good thing".
I'm surprised, I have never seen a micro-processor in which the stack grow upwards. No idea about minis and mainframes though.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Cluso99 said...
Bill, where do you find the time? Congratulations, these are great advances, but no time for me to test :-(
Thanks [noparse]:)[/noparse]
Mikronauts IS my day job, and I work a ridiculous number of hours per week; fortunately I have a very understanding wife!
heater said...
OK, if the stack grows UP (is there anything normal about the Prop?) from the end of the Spin data into the Stack/Free Space area (Blue bar in the F8 output window) then Zog should have about 6K of stack with a 24 page VM. Which sounds ample. Used to be enough for 25 page of working set.
Now I move my VM last page up to $7E00. The last page of HUB memory.
With 23 pages fibo runs through to completion.
With 24 pages it fails on fibo(26)
But I just made room for that extra page by moving everything up one page.
I still don't buy the stack overflow explanation.
I don't think the stack is the only problem, however it is the only thing I have been able to think of so far as to why all the memory tests pass, and ZOG code (with some working set configurations) fails.
I suspect there may still be some multi-legged creatures lurking in VMCOG that need squishing.
heater said...
There is no time to go shopping whilst dhrystone performs 5000 loops any more[noparse]:)[/noparse]
I've been bitten by the stack overwriting other memory in the past too. It's a pain in the posterior.
GuardDog launches a separate cog that does nothing but monitor a firewall of configurable size. When corruption is detected, it blinks an LED (can be changed to generating a tone).
I actually got it debugged, with a test program last night; I just have to clean it up a bit before uploading it. I will integrate it with the ZOG test shell today.
FYI, GuardDog was VERY easy to write, and it is trivial to integrate with any Spin program - purely because of how the Propeller works, and because GuardDog can use an independent cog to do the checking.
BradC said...
heater said...
I still don't buy the stack overflow explanation.
Stack overflows can be quite insidious, particularly if something writes to the same memory location the stack has overflowed into. When the next method returns, it ends up popping random garbage off the stack and going off into never never land. Generally stack overflows are pretty repeatable though, so they're not *that* hard to pin down.
I thought a growing stack pointer was pretty normal. Every time you push something on the stack you simply increment the pointer. I do recall a processor I once used worked the other direction, but I can't recall which one it was now.
I like Bills idea of just poisoning a guard area between the stack and the remainder of ram. Just check it regularly and if it has changed your stack has been bigger than you thought it might.
Debugging this will be nasty, especially if GuardDog does not find corruption!
If I can't find the problem soon, I have an idea of how to build a debug version of VMCOG that guards against memory corruption - but it will be much slower...
- when a page is read in, generate a checksum, and store it in a table in the hub.
- when a write is performed to the page, check before writing to see if the checksum is correct, then do the write and update the checksum
If the above does not do it...
- check the checksum before every read as well.
if either read or write test fails a checksum test, force a ZOG breakpoint, dump TLB
heater said...
Stack overflows have bugged me enough over the years. They are a special case of memory corruption which is even more insidious when its some stray pointer access done by some code that apparently works OK but causes other functions to fail at random some time later.
Bills stack guard will prove the point one way or the other which is a "good thing".
I'm surprised, I have never seen a micro-processor in which the stack grow upwards. No idea about minis and mainframes though.
Instead of giving vmcog a starting high address and number of pages that grow down, why not pass vmcog the address of the start of a array variable and size of the array (VAR or DAT, not sure which is better)? Then when you compile the hub memory used by vmcog will be counted and show in the object info popup window.
John Abshier said...
Instead of giving vmcog a starting high address and number of pages that grow down, why not pass vmcog ...
I wonder about this too. As it is I have to start the cog and then look at the pointer to see where I can put other data. It's a little awkward. I could calculate this, but what if the table sizes change at some point? Maybe the next major revision that supports read-only segments could support growing up from a base address?
The reason it grows down is to easily adjust to different sized "host" Spin programs, and different working set sizes.
No need to change the start address, just change the number of pages!
The reason it is not mapped over an array is two fold:
1) to optimize VMCOG, the pages MUST be page aligned in the hub. This allows storing only the upper address bits for each page, and avoids adding a "base offset"
2) VMCOG is designed to be Spin independent. I can foresee ZOG (and other) eeprom images that only have enough Spin byte codes to start the boot VM.
Frankly, I find the "start of last available page" (normally $7E00, but can be $7C00 under SphinxOS) and "number of pages in working set" easy to use.
Note, the current TLB design allows for 512 pages in the working set on PropII which is NOT an accident.
Please find attached a test archive with GuardDog and 10 pages that breakpoints right at the start - heater, could you try to see if you can find the reason?
I have to spend the rest of the weekend working on a demo for UPEW, and while I may try one or two more tweaks, I won't have a lot of time to spend on VMCOG until after UPEW.
Firstly, after 24 hours away from Zog I return to find he now runs all the way through the fibos with 35 pages just fine. In fact I moved the working set to $7E00 and 36 pages works as well.
So it looks like there is no problem with VMCOG and I have been wasting your time. I suspect now there is something iffy about my power supply.
Secondly, we have a new problem with Zog and VMCog. The Dhrystone test runs through to completion but now not all the results that it prints at the end are correct. Look at Int_Comp, Enum_Comp and Ptr_Comp below.
Thing is these results ARE correct when running from HUB.
Anyway I have posted this version to the first page of the Zog thread. There are Dhrystone some timings shown for different numbers of pages.
Oh, Bill, that fibo you have won't work. There has been a change or two in the Zog emulation to make it work better with VMCog since that version.
Dhrystone Benchmark, Version 2.1 (Language: C)
Program compiled without 'register' attribute
Execution starts, 5000 runs through Dhrystone
Execution ends
Final values of the variables used in the benchmark:
Int_Glob: 5
should be: 5
Bool_Glob: 1
should be: 1
Ch_1_Glob: A
should be: A
Ch_2_Glob: B
should be: B
Arr_1_Glob[noparse][[/noparse]8]: 7
should be: 7
Arr_2_Glob[noparse][[/noparse]8][noparse][[/noparse]7]: 5010
should be: Number_Of_Runs + 10
Ptr_Glob->
Ptr_Comp: 11
should be: (implementation-dependent)
Discr: 0
should be: 0
Enum_Comp: 2
should be: 2
Int_Comp: 17
should be: 17
Str_Comp: DHRYSTONE PROGRAM, SOME STRING
should be: DHRYSTONE PROGRAM, SOME STRING
Next_Ptr_Glob->
Ptr_Comp: 16
should be: (implementation-dependent), same as above
Discr: 0
should be: 0
Enum_Comp: 2
should be: 1
Int_Comp: 17
should be: 18
Str_Comp: DHRYSTONE PROGRAM, SOME STRING
should be: DHRYSTONE PROGRAM, SOME STRING
Int_1_Loc: 5
should be: 5
Int_2_Loc: 13
should be: 13
Int_3_Loc: 7
should be: 7
Enum_Loc: 1
should be: 1
Str_1_Loc: DHRYSTONE PROGRAM, 1'ST STRING
should be: DHRYSTONE PROGRAM, 1'ST STRING
Str_2_Loc: DHRYSTONE PROGRAM, 2'ND STRING
should be: DHRYSTONE PROGRAM, 2'ND STRING
User time: 0
Measured time too small to obtain meaningful results
Please increase number of runs
Microseconds for one run through Dhrystone: 0
Dhrystones per Second: 0
VAX MIPS rating * 1000 = 0
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Prompted by crypto discussions going on here I compiled xxtea for Zog.
This is the biggest Zog program so far as it uses the full size printf and so comes it at nearly 48KB.
When running it repeatedly encrypts and decrypts a string and prints before and after results like so:
All work and no play makes Jack a dull boy.
f850a5c5 8c68fc59 2e000f9a 70c8061a 368a25a1 33ef7ff5 d621f8c5 a731e86a 3d1c3268 13b41a88 8a40fec9
206c6c41 6b726f77 646e6120 206f6e20 79616c70 6b616d20 4a207365 206b6361 75642061 62206c6c 202e796f
All work and no play makes Jack a dull boy.
f850a5c5 8c68fc59 2e000f9a 70c8061a 368a25a1 33ef7ff5 d621f8c5 a731e86a 3d1c3268 13b41a88 8a40fec9
206c6c41 6b726f77 646e6120 206f6e20 79616c70 6b616d20 4a207365 206b6361 75642061 62206c6c 202e796f
All work and no play makes Jack a dull boy.
f850a5c5 8c68fc59 2e000f9a 70c8061a 368a25a1 33ef7ff5 d621f8c5 a731e86a 3d1c3268 13b41a88 8a40fec9
206c6c41 6b726f77 646e6120 206f6e20 79616c70 6b616d20 4a207365 206b6361 75642061 62206c6c 202e796f
All work and no play makes Jack a dull boy.
This is freaky to watch as it's constantly changing speed. From a couple of lines per second to 10s of seconds per line with a period of about a minute.
With only 8 pages in the working set VMCog is working very hard to juggle all this code.
This goes on for 10 minutes or so until it locks up.
Edit: Every run of this results in a lock up at the same position in the 189th iteration.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Ill try and find a moment to pop that in to Zog. I have to get Zog working again with ext memory anyway.
Things are moving slowly here. I smashed my spectacles and am not able to get hold of my old backup specs. I get a terrible headache squinting at my monitor for more than an hour. New specs. are arriving on Wednesday.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I think the 64KB version of VMCOG is pretty stable now - so unless I get reports of some bugs that I can replicate, I am thinking of declaring it v1.0, and moving onto working on the large VM version.
The "large" version will need to use one byte of hub memory for every potential virtual page - so if you want a 2MB VM (because you are running with hardware that adds that much backing store), VMCOG2 will use 4KB of hub memory to hold the "page present" table.
Bill, I've just managed to find a free day to get my latest Zog working with external RAM again.
As a last step I fitted it out with your latest VMCOG (Jul31 v0.976) I had to update it's TriBlade code to my my latest version that was posted here on 18th June.
Sadly the result is that my basic test prog which checks out basic console I/O and ends with a run of fibo() still does not get through the fibo(). With the older VMCog it does at least finish but with a wrong result.
How should we proceed? I could just post the latest ZOG for you to tryout with SPI RAM or so. I need to tidy up the files a bit first.
Bill, I've just managed to find a free day to get my latest Zog working with external RAM again.
As a last step I fitted it out with your latest VMCOG (Jul31 v0.976) I had to update it's TriBlade code to my my latest version that was posted here on 18th June.
Sadly the result is that my basic test prog which checks out basic console I/O and ends with a run of fibo() still does not get through the fibo(). With the older VMCog it does at least finish but with a wrong result.
How should we proceed? I could just post the latest ZOG for you to tryout with SPI RAM or so. I need to tidy up the files a bit first.
Zog V1.1 is posted now with operation from external RAM via VMCog working again.
As delivered it runs the fibo test from TriBlade ext RAM using 20 pages of working set and VMCOG version 0.975. This runs correctly. Other configurations are not so happy:
VMCog Version Pages Result
------------- ----- ------
0.975 20 PASS
0.975 10 FAIL, wrong result for fibo(25) and fibo(26)
0.976 20 FAIL, crash out to break point/illegal op
0.976 10 FAIL, crashes out to reboot!
Bill, I had to refit your 0.976 with my latest TriBlade code as that had been lost somewhere. Both VMCog versions are included in todays Zog package.
Zog V1.1 is posted now with operation from external RAM via VMCog working again.
As delivered it runs the fibo test from TriBlade ext RAM using 20 pages of working set and VMCOG version 0.975. This runs correctly. Other configurations are not so happy:
VMCog Version Pages Result
------------- ----- ------
0.975 20 PASS
0.975 10 FAIL, wrong result for fibo(25) and fibo(26)
0.976 20 FAIL, crash out to break point/illegal op
0.976 10 FAIL, crashes out to reboot!
Bill, I had to refit your 0.976 with my latest TriBlade code as that had been lost somewhere. Both VMCog versions are included in todays Zog package.
I've just tried a modified heater3 test which loops for ever. It has not failed anywhere yet. Like so:
Testing $00010000 bytes
Up count fill...
Up count check...
Down count fill...
Down count check...
Random fill...
Random check...
Zero fill...
Checking 00 writing FF...
Checking FF writing AA...
Checking AA writing 55...
Checking 55 writing 00...
OK
I've just tried a modified heater3 test which loops for ever. It has not failed anywhere yet. Like so:
Testing $00010000 bytes
Up count fill...
Up count check...
Down count fill...
Down count check...
Random fill...
Random check...
Zero fill...
Checking 00 writing FF...
Checking FF writing AA...
Checking AA writing 55...
Checking 55 writing 00...
OK
1) Zog runs FIBO from HUB RAM OK.
2) Zog runs FIBO OK from Ext RAM on TriBlade in at least one configuration.
3) Zog fails to run FIBO from Ext RAM on TriBlade in many other configurations.
4) The heater3 test has not been seen to fail yet.
Now, the fact that Zog runs from HUB is irrelevant as the actual code used (for memory access) is different. So ignore 1)
2) Seems to imply Zog does not have a problem.
3) and 4) imply that the heater3 test is not thorough enough:) Or at least not simulating what Zog does with FIBO.
What would help is if someone were running Zog and FIBO on a different Ext memory hardware. Then we could determine if the Problem is with VMCog logic, or VMCog TriBlade interface code, or something weird with my particular hardware.
I have a problem running heter3 test for long periods as every time our refrigerator goes on/off it crashes out the USB serial connection, resetting the Prop and crashing BST.
Just now they are rewiring the house so perhaps that electrical glitch will be gone soon.
Bill: "I've read, and re-read, the code *many* times,"
Often that is the problem. You end up reading what you "know" is there rather than what is actually there. Is there some way we can probe what is going on? Dump some useful variables or such as it runs. Might be slow but who cares.
I'll try the fibo code (is it in the latest zip in the ZPU thread?) with various sizes on PropCade/SPI.
I am in the middle of finishing qualifying the rev2 Morpheus and Mem+ PCB's, as part of that process I will make a VMCOG driver for the two SPI RAM's I can install on CPU#1 of Morpheus - and run FIBO there as well.
I am tempted to add memory traces (ie log every read/write) however unless we find a case where it fails for a very small fibo (ie 3 or 4) it will take forever to run.
I agree about re-reading a code; I may easily be missing something due to that.
1) Zog runs FIBO from HUB RAM OK.
2) Zog runs FIBO OK from Ext RAM on TriBlade in at least one configuration.
3) Zog fails to run FIBO from Ext RAM on TriBlade in many other configurations.
4) The heater3 test has not been seen to fail yet.
Now, the fact that Zog runs from HUB is irrelevant as the actual code used (for memory access) is different. So ignore 1)
2) Seems to imply Zog does not have a problem.
3) and 4) imply that the heater3 test is not thorough enough:) Or at least not simulating what Zog does with FIBO.
What would help is if someone were running Zog and FIBO on a different Ext memory hardware. Then we could determine if the Problem is with VMCog logic, or VMCog TriBlade interface code, or something weird with my particular hardware.
I have a problem running heter3 test for long periods as every time our refrigerator goes on/off it crashes out the USB serial connection, resetting the Prop and crashing BST.
Just now they are rewiring the house so perhaps that electrical glitch will be gone soon.
Bill: "I've read, and re-read, the code *many* times,"
Often that is the problem. You end up reading what you "know" is there rather than what is actually there. Is there some way we can probe what is going on? Dump some useful variables or such as it runs. Might be slow but who cares.
Comments
Bills stack guard will prove the point one way or the other which is a "good thing".
I'm surprised, I have never seen a micro-processor in which the stack grow upwards. No idea about minis and mainframes though.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Thanks [noparse]:)[/noparse]
Mikronauts IS my day job, and I work a ridiculous number of hours per week; fortunately I have a very understanding wife!
I don't think the stack is the only problem, however it is the only thing I have been able to think of so far as to why all the memory tests pass, and ZOG code (with some working set configurations) fails.
I suspect there may still be some multi-legged creatures lurking in VMCOG that need squishing.
Sounds GREAT!
What is the hub-only time?
Very strange...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
Post Edited (Bill Henning) : 6/19/2010 2:56:20 PM GMT
GuardDog launches a separate cog that does nothing but monitor a firewall of configurable size. When corruption is detected, it blinks an LED (can be changed to generating a tone).
I actually got it debugged, with a test program last night; I just have to clean it up a bit before uploading it. I will integrate it with the ZOG test shell today.
FYI, GuardDog was VERY easy to write, and it is trivial to integrate with any Spin program - purely because of how the Propeller works, and because GuardDog can use an independent cog to do the checking.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
Debugging this will be nasty, especially if GuardDog does not find corruption!
If I can't find the problem soon, I have an idea of how to build a debug version of VMCOG that guards against memory corruption - but it will be much slower...
- when a page is read in, generate a checksum, and store it in a table in the hub.
- when a write is performed to the page, check before writing to see if the checksum is correct, then do the write and update the checksum
If the above does not do it...
- check the checksum before every read as well.
if either read or write test fails a checksum test, force a ZOG breakpoint, dump TLB
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
John abshier
Thanks,
--Steve
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
No need to change the start address, just change the number of pages!
The reason it is not mapped over an array is two fold:
1) to optimize VMCOG, the pages MUST be page aligned in the hub. This allows storing only the upper address bits for each page, and avoids adding a "base offset"
2) VMCOG is designed to be Spin independent. I can foresee ZOG (and other) eeprom images that only have enough Spin byte codes to start the boot VM.
Frankly, I find the "start of last available page" (normally $7E00, but can be $7C00 under SphinxOS) and "number of pages in working set" easy to use.
Note, the current TLB design allows for 512 pages in the working set on PropII
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
Please find attached a test archive with GuardDog and 10 pages that breakpoints right at the start - heater, could you try to see if you can find the reason?
I have to spend the rest of the weekend working on a demo for UPEW, and while I may try one or two more tweaks, I won't have a lot of time to spend on VMCOG until after UPEW.
Darn it!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
Firstly, after 24 hours away from Zog I return to find he now runs all the way through the fibos with 35 pages just fine. In fact I moved the working set to $7E00 and 36 pages works as well.
So it looks like there is no problem with VMCOG and I have been wasting your time. I suspect now there is something iffy about my power supply.
Secondly, we have a new problem with Zog and VMCog. The Dhrystone test runs through to completion but now not all the results that it prints at the end are correct. Look at Int_Comp, Enum_Comp and Ptr_Comp below.
Thing is these results ARE correct when running from HUB.
Anyway I have posted this version to the first page of the Zog thread. There are Dhrystone some timings shown for different numbers of pages.
Oh, Bill, that fibo you have won't work. There has been a change or two in the Zog emulation to make it work better with VMCog since that version.
Dhrystone Benchmark, Version 2.1 (Language: C) Program compiled without 'register' attribute Execution starts, 5000 runs through Dhrystone Execution ends Final values of the variables used in the benchmark: Int_Glob: 5 should be: 5 Bool_Glob: 1 should be: 1 Ch_1_Glob: A should be: A Ch_2_Glob: B should be: B Arr_1_Glob[noparse][[/noparse]8]: 7 should be: 7 Arr_2_Glob[noparse][[/noparse]8][noparse][[/noparse]7]: 5010 should be: Number_Of_Runs + 10 Ptr_Glob-> Ptr_Comp: 11 should be: (implementation-dependent) Discr: 0 should be: 0 Enum_Comp: 2 should be: 2 Int_Comp: 17 should be: 17 Str_Comp: DHRYSTONE PROGRAM, SOME STRING should be: DHRYSTONE PROGRAM, SOME STRING Next_Ptr_Glob-> Ptr_Comp: 16 should be: (implementation-dependent), same as above Discr: 0 should be: 0 Enum_Comp: 2 should be: 1 Int_Comp: 17 should be: 18 Str_Comp: DHRYSTONE PROGRAM, SOME STRING should be: DHRYSTONE PROGRAM, SOME STRING Int_1_Loc: 5 should be: 5 Int_2_Loc: 13 should be: 13 Int_3_Loc: 7 should be: 7 Enum_Loc: 1 should be: 1 Str_1_Loc: DHRYSTONE PROGRAM, 1'ST STRING should be: DHRYSTONE PROGRAM, 1'ST STRING Str_2_Loc: DHRYSTONE PROGRAM, 2'ND STRING should be: DHRYSTONE PROGRAM, 2'ND STRING User time: 0 Measured time too small to obtain meaningful results Please increase number of runs Microseconds for one run through Dhrystone: 0 Dhrystones per Second: 0 VAX MIPS rating * 1000 = 0▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
Prompted by crypto discussions going on here I compiled xxtea for Zog.
This is the biggest Zog program so far as it uses the full size printf and so comes it at nearly 48KB.
When running it repeatedly encrypts and decrypts a string and prints before and after results like so:
This is freaky to watch as it's constantly changing speed. From a couple of lines per second to 10s of seconds per line with a period of about a minute.
With only 8 pages in the working set VMCog is working very hard to juggle all this code.
This goes on for 10 minutes or so until it locks up.
Edit: Every run of this results in a lock up at the same position in the 189th iteration.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Post Edited (heater) : 6/24/2010 10:43:25 AM GMT
Interesting test!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
's' - read SPI RAM status register contents to VMDEBUG
and supporting read_status(n) API call with supporting PASM code to VMDEBUG.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
Things are moving slowly here. I smashed my spectacles and am not able to get hold of my old backup specs. I get a terrible headache squinting at my monitor for more than an hour. New specs. are arriving on Wednesday.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
The "large" version will need to use one byte of hub memory for every potential virtual page - so if you want a 2MB VM (because you are running with hardware that adds that much backing store), VMCOG2 will use 4KB of hub memory to hold the "page present" table.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
As a last step I fitted it out with your latest VMCOG (Jul31 v0.976) I had to update it's TriBlade code to my my latest version that was posted here on 18th June.
Sadly the result is that my basic test prog which checks out basic console I/O and ends with a run of fibo() still does not get through the fibo(). With the older VMCog it does at least finish but with a wrong result.
How should we proceed? I could just post the latest ZOG for you to tryout with SPI RAM or so. I need to tidy up the files a bit first.
Thanks,
--Steve
I start to do more debugging is how. I could not get anything done on the weekend - it was too hot in my lab.
Please send me the latest fibo, so I can see if it finishes with SPI ram's.
This week I am planning to add support for two SPI ram's on CPU1 of Morpheus, and FlexMem
As delivered it runs the fibo test from TriBlade ext RAM using 20 pages of working set and VMCOG version 0.975. This runs correctly. Other configurations are not so happy:
Bill, I had to refit your 0.976 with my latest TriBlade code as that had been lost somewhere. Both VMCog versions are included in todays Zog package.
I am really puzzled as to *WHY* it would work with 20, and not with 10... very weird.
I've just tried a modified heater3 test which loops for ever. It has not failed anywhere yet. Like so:
Testing $00010000 bytes
Up count fill...
Up count check...
Down count fill...
Down count check...
Random fill...
Random check...
Zero fill...
Checking 00 writing FF...
Checking FF writing AA...
Checking AA writing 55...
Checking 55 writing 00...
OK
Works for vmcog versions 0.975 and 0.976.
Curiouser and curiouser...
I've read, and re-read, the code *many* times, and I can't spot any multi-legged creatures... (ofcourse this does NOT mean they are not there).
1) Zog runs FIBO from HUB RAM OK.
2) Zog runs FIBO OK from Ext RAM on TriBlade in at least one configuration.
3) Zog fails to run FIBO from Ext RAM on TriBlade in many other configurations.
4) The heater3 test has not been seen to fail yet.
Now, the fact that Zog runs from HUB is irrelevant as the actual code used (for memory access) is different. So ignore 1)
2) Seems to imply Zog does not have a problem.
3) and 4) imply that the heater3 test is not thorough enough:) Or at least not simulating what Zog does with FIBO.
What would help is if someone were running Zog and FIBO on a different Ext memory hardware. Then we could determine if the Problem is with VMCog logic, or VMCog TriBlade interface code, or something weird with my particular hardware.
I have a problem running heter3 test for long periods as every time our refrigerator goes on/off it crashes out the USB serial connection, resetting the Prop and crashing BST.
Just now they are rewiring the house so perhaps that electrical glitch will be gone soon.
Bill: "I've read, and re-read, the code *many* times,"
Often that is the problem. You end up reading what you "know" is there rather than what is actually there. Is there some way we can probe what is going on? Dump some useful variables or such as it runs. Might be slow but who cares.
I am in the middle of finishing qualifying the rev2 Morpheus and Mem+ PCB's, as part of that process I will make a VMCOG driver for the two SPI RAM's I can install on CPU#1 of Morpheus - and run FIBO there as well.
I am tempted to add memory traces (ie log every read/write) however unless we find a case where it fails for a very small fibo (ie 3 or 4) it will take forever to run.
I agree about re-reading a code; I may easily be missing something due to that.