Chris:
Not sure if this helps, but I have a debugger that traces both spin and asm. It takes zero footprint (4 longs), so you would have to move that bit as your emulation is probably not going to reproduce that part properly (the shaddow ram underneath the registers $F0-FF).
It may help you to compare your code to real code on a prop.
See the tools link in my signature.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Cluso said...
Not sure if this helps, but I have a debugger that traces both spin and asm.
Hi Cluso99, thanks for your hint. I will try to use it.
BradC said...
A completely unrelated point, but you are not decoding the lock instructions
Hmm, well, I didn't implement the "lock" instructions yet, because they were not necessary for the basic functions of spin.
>The non-deterministic nature of the fault indicates a bug that is not a logic error, but something more sinister.
That hint is very helpful to me, because on my system the program behaves always the same.
I didn't preinitialize the hub memory with zeros, probably this may make the difference to your system. Now I made a version preinitializing the hub memory to zero ( see attachment ). Probably you could give me a second try.
I now implemented the command 's' in the debugger. It shows the spin registers ( x,y,a,t1,t2 ... ) and interprets some opcodes of spin. Probably this could be very useful for debugging.
Post Edited (Chris Micro) : 7/8/2009 2:47:43 PM GMT
Uhh, it is more work than I thought.
I corrected some errors in the assembly conditions, now the if/else in spin works.
But ... the repeat is still not working.
I would be very glad if someone could try the emulator and give me a feedback
Chris Micro said...
Uhh, it is more work than I thought.
I corrected some errors in the assembly conditions, now the if/else in spin works.
But ... the repeat is still not working.
I would be very glad if someone could try the emulator and give me a feedback
I'll try and do this today for you if I get the chance. Stepping through the interpreter and correlating the code positions to the original spin source/listfile is somewhat of a headache.
Just a suggestion though, rather than using the spin interpreter to debug the emulator (if you think about it, if the emulation was 100% then the spin interpreter would run perfectly) would we be better knocking up a series of PASM test cases that are easier to step through to improve the accuracy of the cog emulation first?
And check the result including the C and Z flags according to the WZ and WC modifiers. SPIN interpreter is using flags and conditional execution very much.
I would (or will) do it like that (when my emulator is done):
1. check that movd/movi works
2. check that·mov works with the 4 conditions IF_C_AND_Z, IF_NC_AND_Z, IF_C_AND_NZ and IF_NC_AND_NZ
1. and 2. are needed for the test framework
3. Then you can write a test framework for each instruction ··· Well ... the test framework depends on how you implemented the emulator. My emulator for example has some basic stuff. The conditions are checked before running the instruction code. So, I only have to check the conditions once and know that they will work with each instruction. Same with the·WR, WZ and WC - same method to set the flags is called after execution of each instruction (the instructions themselve only·use an internal set of the flags). So the WR, WZ, WC and I flags will also work for each instruction if I prooved that it worked for one.
· In the new Propeller Manual there are nice tables that show which operands lead to wich result including the flags. You only have to run each instruction with all those operands and you directly can compare the result with the Propeller Manual. To check that the flags are correct the IF_... can be used, which simply moves a defined value to a register according to the flags.
I'm a BIG fan of Doxygen ... even used it in spin a couple of times. It's available for Linux, Windows, and Mac. At minimum use file, param, and returns tags and describe each "public" function. If you use headers (as library API as well as forward declarations, etc...) it's good to put the markup the .h. Otherwise markup in the .c is fine.
BTW: Cluso99's debugger along with mpark's homespun and verbose listings can help you track those spin errors. It's kind of a pain to have to manually resolve the instructions with the source, but the assembly listing output for every spin statement is priceless.
You have to add extensions to the Doxyfile FILE_PATTERNS parameter. Also, I believe each file must have a @file <filename> tag in the doxygen markup comment.
Chris, If you use my debugger and you trace where the spin instruction fails, you can turn on the trace to trace the pasm instructions being executed and see which pasm instruction is wrong. Each pasm instruction shows the results of the flags and memory before and after the instruction. Hope this helps.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
MagIO2 said...
Didn''t you forget the
regs->pc++;
for the REV instruction?
Hi MagIO2,
congratulation, you are the firs who found one error.
I corrected the rev-function before thanks to ALE who helped me. But in my correction i deleted accidentally the regs->pc++. There was an misunderstanding on my side before because because rev reverts 32-n bits instead of n bits.
Cluso99 said...
If you use my debugger and you trace where the spin instruction fails, ...
Thats probably a good idea. At the moment I try to write some test cases.
the prop emulator is my first real open source project. So, as the project advances, there are some people who want to use the code. Now the question about the license arouses.
I got the following message:
Somebody said...
Do you mind if I use your code in a non-commercial, but not open-source app?
I've been contemplating adding a Prop ... to my ... code...
Your simulator seems like a good fit. I think it'd save me a lot of work.
But, I don't want to give out my .... code...
What do you think how to deal with that question? Is there anybody out there who has experience programming open source?
I normally make my code GPLv2 because I do not want businesses from profiting from my work when they do not compensate me. But of course anyone can just use any code and bundle it without saying anything. That is a really bad practice. LGPL 2 is also a nice alternative.
Chris you really have to a ask yourself what you want because we can only tell you what we want.
Do you want people to be able to see your code, use it, modify it? Should they be able distribute it in source or binary, modified or not, with attribution in place or not? Do you mind if they sell it for profit or or otherwise? On it's own or in combination with other work. Etc etc etc.
You might want to look over the GPL and LGPL licences and the BSD, MIT licenses for starters. If you want to drive yourself nuts take a look at all the licenses approved by the Open Source Initiative.www.opensource.org/licenses/alphabetical
You can always craft your own license, but I get the feeling we have enough licenses in the world already. May be just as well to pick one that fits your desires and save your users a little confusion.
Nothing stops you releasing your code under more than one license or using an existing license with some of your own exceptions specified.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Hi Chris
I just downloaded and compiled your simulator. I can't see how you have handed the pipelining in the hub fetch, execute and write back. It's probably there, I may have missed it. I remember I was intrigued to see how it was handled in Ale's code. Anyway, good job. I am sure you will get some help from Jazzed, but he is going to have to get his finger out if he's going to get his latest toys ready for Christmas. [noparse]:)[/noparse]
Ron
BTW I will do some testing see what we come up with.
I told Chris about my almost cycle accurate method. The point is: as his simulator was designed to be run by other processors than a PC, a pipeline and cycle exactness where not necessary. Especially becausee he wanted real time to mean the same time for the host as the simulated processor. I can see some advantages here. I was wondering how fast a COG simulator could be implemented using the XMOS chip. Especially because you have real 8 threads and no simulated ones... I'll have to give it a shot.
Exact cycle timing is probably not necessary. But I'm sure there are programs out there that will fail if some pipe lining is not implemented. At least the simulation must read the next instructions op code before writing out the results of the current one. Otherwise some self-modifying code may well fail. I don't know if Chris has done that yet.
Simulating a COG on XMOS, that's cheeky!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I think that the problem is more on propeller-side. If you develop code and first test it in the simulator, then you will find out that the code might not run on the propeller. As we all know about the self modifying code problem we tend to put an instruction between modifying code and execution of the modified code. The case where you rely on the fact that the code has not been modified yet is rare - isn't it?
So, most software written and tested on the prop will run in such a simulator.
"problem" or just "feature". Given the requirements for consistent instruction cycle times and pipe-ling for speed I guess this issue is inevitable.
Now I'm sure you are right in saying that most code tested on the Prop will also run on the simulator. However I maintain that:
1) If the simulator gives different results for an instruction sequence is just wrong. It may be rare in actual use but it's just leaving a little bomb there for someone in the future which will cause a lot of wasted time and head scratching.
2) If the code is already tested and working on the Prop there probably is no need for the simulator.
3) Working in reverse if the code is being debugged on the simulator it is necessary that it is executed accurately other wise those mysterious failures on a real Prop will be unnecessarily hard to find.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I fully agree with you for the "use the simulator as development tool" usecase. But I think that Chris' usecase is different. He want's to simulate the propeller with other microcontrollers. And there the pipeline is simply a speed issue. Knowing that code written for the prop runs on the simulator is sufficient for that usecase.
My usecase is the development tool usecase as well and that's why I currently write my own simulator which implements the pipeline. Hopefully I can finish the implementation of the instructions this weekend. And I hope Chris left some forum participants that are willing to test 'yet another prop simulator' - YAPS .. nice name. ;o)
Perhaps I don't understand the speed issue or the complexity of getting this pipeline working. But isn't it the case that simply fetching the next instruction prior to writing the current result is sufficient? That would not make the simulator much slower, if at all.
I like this idea of Prop simulator in C for running on other micros.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
More often than not Prop applications drive devices in Real Time. Without correct timing the simulator is very limited. I recently used the Gear logic prop to get my External memory driver up and running. I don't think that speed is all that important in a development tool, I think its better to get useful information from it. Users will contribute various interfaces. I found Gear Plugin scripts difficult to use.
There are not many multi-core micros out there that can emulate the propeller. One core micros can use interrupt context switching to do some of it, but emulating 8 cogs is unlikely. Heater is right about needing the pipeline (or a simulated one) if the simulator is used for Propeller development without needing Propeller hardware.
chCog.c looks so familiar [noparse]:)[/noparse] I did something very similar in Verilog except that I saved pc increment and destination writing for the end of the switch statement and used flags to determine if those options should be done.
On the licensing front, GPL is a pain for "independent users" since it requires feeding back changes ... if bug fixes are done they would be helpful though [noparse]:)[/noparse]. Just use the MIT license which only requires giving due credit to the original authors (although it does not specify how that is done).
Comments
Not sure if this helps, but I have a debugger that traces both spin and asm. It takes zero footprint (4 longs), so you would have to move that bit as your emulation is probably not going to reproduce that part properly (the shaddow ram underneath the registers $F0-FF).
It may help you to compare your code to real code on a prop.
See the tools link in my signature.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Hi Cluso99, thanks for your hint. I will try to use it.
Hmm, well, I didn't implement the "lock" instructions yet, because they were not necessary for the basic functions of spin.
>The non-deterministic nature of the fault indicates a bug that is not a logic error, but something more sinister.
That hint is very helpful to me, because on my system the program behaves always the same.
I didn't preinitialize the hub memory with zeros, probably this may make the difference to your system. Now I made a version preinitializing the hub memory to zero ( see attachment ). Probably you could give me a second try.
I now implemented the command 's' in the debugger. It shows the spin registers ( x,y,a,t1,t2 ... ) and interprets some opcodes of spin. Probably this could be very useful for debugging.
Post Edited (Chris Micro) : 7/8/2009 2:47:43 PM GMT
I corrected some errors in the assembly conditions, now the if/else in spin works.
But ... the repeat is still not working.
I would be very glad if someone could try the emulator and give me a feedback
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
I'll try and do this today for you if I get the chance. Stepping through the interpreter and correlating the code positions to the original spin source/listfile is somewhat of a headache.
Just a suggestion though, rather than using the spin interpreter to debug the emulator (if you think about it, if the emulation was 100% then the spin interpreter would run perfectly) would we be better knocking up a series of PASM test cases that are easier to step through to improve the accuracy of the cog emulation first?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Release the hounds!
Test all conditions
Test shift instructions
Test bitwise instructions
and so on...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit the home of pPropQL: propeller.wikispaces.com/pPropQL
pPropQL020: propeller.wikispaces.com/pPropQL
OMU for the pPropQL/020 propeller.wikispaces.com/OMU
I would (or will) do it like that (when my emulator is done):
1. check that movd/movi works
2. check that·mov works with the 4 conditions IF_C_AND_Z, IF_NC_AND_Z, IF_C_AND_NZ and IF_NC_AND_NZ
1. and 2. are needed for the test framework
3. Then you can write a test framework for each instruction
··· Well ... the test framework depends on how you implemented the emulator. My emulator for example has some basic stuff. The conditions are checked before running the instruction code. So, I only have to check the conditions once and know that they will work with each instruction. Same with the·WR, WZ and WC - same method to set the flags is called after execution of each instruction (the instructions themselve only·use an internal set of the flags). So the WR, WZ, WC and I flags will also work for each instruction if I prooved that it worked for one.
· In the new Propeller Manual there are nice tables that show which operands lead to wich result including the flags. You only have to run each instruction with all those operands and you directly can compare the result with the Propeller Manual. To check that the flags are correct the IF_... can be used, which simply moves a defined value to a register according to the flags.
·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit the home of pPropQL: propeller.wikispaces.com/pPropQL
pPropQL020: propeller.wikispaces.com/pPropQL
OMU for the pPropQL/020 propeller.wikispaces.com/OMU
It is a liitle bit a mather of documentation. First I wanted to document it a little bit more before I post it.
What do you think of about using Doxygen for Documentation?
http://www.stack.nl/~dimitri/doxygen/
I used it in earlier projects and it's quite good.
I find that adopting a system like that encourages one to actually do documentation[noparse]:)[/noparse] DoxyGen is pretty cool anyway.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
BTW: Cluso99's debugger along with mpark's homespun and verbose listings can help you track those spin errors. It's kind of a pain to have to manually resolve the instructions with the source, but the assembly listing output for every spin statement is priceless.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
Post Edited (jazzed) : 7/9/2009 2:32:48 PM GMT
The source code is now online here
I have some problems with doxygen. It seems only to take the *.h files for documention.
jazzed: can you give me some hints or examples how I can improve the documentation for doxygen?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
Didn''t you forget the
regs->pc++;
for the REV instruction?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
congratulation, you are the firs who found one error.
I corrected the rev-function before thanks to ALE who helped me. But in my correction i deleted accidentally the regs->pc++. There was an misunderstanding on my side before because because rev reverts 32-n bits instead of n bits.
Thats probably a good idea. At the moment I try to write some test cases.
the prop emulator is my first real open source project. So, as the project advances, there are some people who want to use the code. Now the question about the license arouses.
I got the following message:
What do you think how to deal with that question? Is there anybody out there who has experience programming open source?
I normally make my code GPLv2 because I do not want businesses from profiting from my work when they do not compensate me. But of course anyone can just use any code and bundle it without saying anything. That is a really bad practice. LGPL 2 is also a nice alternative.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit the home of pPropQL: propeller.wikispaces.com/pPropQL
pPropQL020: propeller.wikispaces.com/pPropQL
OMU for the pPropQL/020 propeller.wikispaces.com/OMU
Do you want people to be able to see your code, use it, modify it? Should they be able distribute it in source or binary, modified or not, with attribution in place or not? Do you mind if they sell it for profit or or otherwise? On it's own or in combination with other work. Etc etc etc.
You might want to look over the GPL and LGPL licences and the BSD, MIT licenses for starters. If you want to drive yourself nuts take a look at all the licenses approved by the Open Source Initiative.www.opensource.org/licenses/alphabetical
You can always craft your own license, but I get the feeling we have enough licenses in the world already. May be just as well to pick one that fits your desires and save your users a little confusion.
Nothing stops you releasing your code under more than one license or using an existing license with some of your own exceptions specified.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I just downloaded and compiled your simulator. I can't see how you have handed the pipelining in the hub fetch, execute and write back. It's probably there, I may have missed it. I remember I was intrigued to see how it was handled in Ale's code. Anyway, good job. I am sure you will get some help from Jazzed, but he is going to have to get his finger out if he's going to get his latest toys ready for Christmas. [noparse]:)[/noparse]
Ron
BTW I will do some testing see what we come up with.
No pipeline. In one of the first posts he mentioned that each instruction needs one clock.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit the home of pPropQL: propeller.wikispaces.com/pPropQL
pPropQL020: propeller.wikispaces.com/pPropQL
OMU for the pPropQL/020 propeller.wikispaces.com/OMU
Simulating a COG on XMOS, that's cheeky!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
So, most software written and tested on the prop will run in such a simulator.
Now I'm sure you are right in saying that most code tested on the Prop will also run on the simulator. However I maintain that:
1) If the simulator gives different results for an instruction sequence is just wrong. It may be rare in actual use but it's just leaving a little bomb there for someone in the future which will cause a lot of wasted time and head scratching.
2) If the code is already tested and working on the Prop there probably is no need for the simulator.
3) Working in reverse if the code is being debugged on the simulator it is necessary that it is executed accurately other wise those mysterious failures on a real Prop will be unnecessarily hard to find.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
My usecase is the development tool usecase as well and that's why I currently write my own simulator which implements the pipeline. Hopefully I can finish the implementation of the instructions this weekend. And I hope Chris left some forum participants that are willing to test 'yet another prop simulator' - YAPS .. nice name. ;o)
I like this idea of Prop simulator in C for running on other micros.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
More often than not Prop applications drive devices in Real Time. Without correct timing the simulator is very limited. I recently used the Gear logic prop to get my External memory driver up and running. I don't think that speed is all that important in a development tool, I think its better to get useful information from it. Users will contribute various interfaces. I found Gear Plugin scripts difficult to use.
Ron
There are not many multi-core micros out there that can emulate the propeller. One core micros can use interrupt context switching to do some of it, but emulating 8 cogs is unlikely. Heater is right about needing the pipeline (or a simulated one) if the simulator is used for Propeller development without needing Propeller hardware.
chCog.c looks so familiar [noparse]:)[/noparse] I did something very similar in Verilog except that I saved pc increment and destination writing for the end of the switch statement and used flags to determine if those options should be done.
On the licensing front, GPL is a pain for "independent users" since it requires feeding back changes ... if bug fixes are done they would be helpful though [noparse]:)[/noparse]. Just use the MIT license which only requires giving due credit to the original authors (although it does not specify how that is done).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
Ale made it look too simple. I would find the code, and post it buts its 1am and its zzzzz time
Ron