jazzed mcu Simulator
Rsadeika
Posts: 3,837
This program is a jazzed creation, which you have to compile using Qt5, in order too see how it works. Not being a PASM programmer, I find this program interesting and I have a few questions.
When I first start the program up, it shows the Simulator, COG tabs across the top, the middle is for program code, and across the bottom you have all of the pin number boxes. Now, according to instructions, when you hit 'Run' it starts the simulator by replacing the middle of the screen with some spots that spiral down, not sure what that is supposed too signify. And all of the pin boxes, at the bottom, start to turn green and then back too its normal state, on and off.
Once you hit stop, the middle of the screen goes back too its default, and now the columns on the left side have code residing there. The first column on the left has location numbers from $000 - $1ef, $1ef = 495, so I guess, the first column is COG ram locations. The next column of interest is labeled 'Instruction' , this is where it becomes interesting.
Since it has been stated some many times that when you boot the Propeller, COG 0 gets loaded with the Spin interpreter, so the code that is now residing in the Simulator, is the Spin interpreter or something else? If it is the Spin interpreter, at what location is the end of the interpreter, and where does the regular program begin? Hopefully other people will add questions as to what this program is all about.
Ray
When I first start the program up, it shows the Simulator, COG tabs across the top, the middle is for program code, and across the bottom you have all of the pin number boxes. Now, according to instructions, when you hit 'Run' it starts the simulator by replacing the middle of the screen with some spots that spiral down, not sure what that is supposed too signify. And all of the pin boxes, at the bottom, start to turn green and then back too its normal state, on and off.
Once you hit stop, the middle of the screen goes back too its default, and now the columns on the left side have code residing there. The first column on the left has location numbers from $000 - $1ef, $1ef = 495, so I guess, the first column is COG ram locations. The next column of interest is labeled 'Instruction' , this is where it becomes interesting.
Since it has been stated some many times that when you boot the Propeller, COG 0 gets loaded with the Spin interpreter, so the code that is now residing in the Simulator, is the Spin interpreter or something else? If it is the Spin interpreter, at what location is the end of the interpreter, and where does the regular program begin? Hopefully other people will add questions as to what this program is all about.
Ray
Comments
COG 0 always begins with the spin interpreter. So what you are seeing is the code in ROM location $F004. Right now the ROM code is not shown in the HUB RAM tab.
The spin program gets loaded one bytecode at a time by the rdbyte instruction at interpreter COG address $009.
There is no source listing for openspin at the moment, but there is for bstc if you have that. You can keep track of which spin bytecode is being executed if your program is compiled with bstc -ls.
The black screen with spots spiraling down is reserved for future VGA, TV, or Serial output.
Since this is called a simulator, I was thinking, can the PASM toggle P16 program, that is in the Propeller Manual be used as a demo for your program? I am guessing that with your simulator program one should be able to plug in the toggle code and then by running the simulator you should be able to see the pin 16 box at the bottom of the screen toggling on/off, is that a correct assumption for how your simulator program will be used?
Ray
I found out what you can do with it.....you can play with it for a good couple hours and then realize you've shot half your work day!!
Try this PASM code:
Cut and paste it into a new file in PropellerIDE, save it, compile it to get a binary and then load it into the mcusimulator. "Run" until P16 starts to blink, then you can stop and step and debug and watch teh PASM code run in COG#0.
It's a great PASM learning tool. Nothing like having a visual Propeller!!
{Note to Steve: The program above did not run in the simulator when it just had the "xor outa,Pin" instruction. When I wrapped it with the MOV instructions, it worked fine. I haven't gone further to see if it has to do with OUTA in a Dfield or just some timing quirk. }
This will really be cool when it has the P2 instruction set......(did I say that out loud???)
Way to GO, Steve (and Dave Hein) - I can see this being very useful and lots of fun!!
What is possible today:
Run any simple Spin, C, or other language programs that blink LED boxes.
So, yes today build a spin program that toggles P16 with PropellerIDE, load the .binary in the simulator, and run it.
There are some limits at the moment. For some reason I can't run more complicated programs that use FullDuplexSerial for example. This is a work in progress.
The vision:
Run any Propeller (P8x32a or P16x512) program written in any language.
The user's mouse, keyboard, and display should allow Propeller control and show output on the Run display.
Add an option to PropellerIDE to run programs in the simulator.
Provide different MCU modes eventually. That is ....
P8x32a SPIN in addition to the current PASM debug mode. Simulate the new P16x512 chip in a similar way.
Add other MCU options like AVR, dsPIC, PIC32, STM32, etc....
https://code.google.com/p/mcusimulator/
There have been updates this morning.
When the Simulator flashes pin 15, it does not look visually like there is a one second delay, so it looks like it is flashing much quicker than what I would see with a real life LED. Not sure if this optical illusion for me.
Looking at the code in the Simulator I was really surprised that all 496 bytes of COG ram, plus ~130 bytes of HUB ram are being used for the blinker.spin program. Now I get a good sense of how precious that COG RAM really is, and it does not take a very large program to use it up. I am scratching my head trying to figure out how you do a balancing act to utilize the COG and HUB RAM, in the most efficient manner.
I think the Simulator needs a way to print out the code in its neat column format. It would be nice to have the lines of code on paper so you could, using a pencil, connect up the jmp points, bracket up the SUBs, and do other visual things with the lines of code. Just a few thoughts of mine...
Now all we need is a program where you could check the little pin 15 box, and give some qualifications like 'on one second', 'off one second' and have the Simulator print out the lines of code to accomplish the request. But then if you could do that, then why would you need ASM programmers.:-)
Ray
When writing Spin programs, the COG RAM is all spoken for by the Spin interpreter and its data structures. Regardless of the size of your Spin program, the 496 Longs of COG RAM will always be used. Your Spin program (byte code and data) lives in HUB RAM. You don't need to balance between the two because you can only use HUB RAM.
When you start writing in PASM or creating .cog C code, then you realize how quickly 496 longs can disappear.
Any of the languages that have byte code VMs or run an interpreter of some sort have highly optimized kernels that use the COG RAM. For the most part, the user's program is pushed out to HUB RAM....where at some point, you realize how precious that 32K of HUB RAM is!
I see the simulator as a great tool for people learning PASM as well as testing kernels and such,
Again, excellent stuff, Steve!
In my pervious post code listing, when I use the 'step' method to work through the code, I notice that it jumps around within the COG code, but never really gets, or at least shows, that the HUB code is being accessed. So, I guess looking at the COG code, and identifying the Spin interpreter code from your actual Spin program code would be the next step.
Another observation: looking at the COG code, it sure looks like spaghetti code to me, no visible or identifiable structure what so ever. When you step through the program it becomes very apparent, at least to me, that the program is jumping all over the place, and not necessarily to a SUB and then doing a return. I guess more studying of the code is necessary.
Yes, this is a very useful and beneficial program, good work jazzed.
Ray
In your program, (I don;t have "Tools" so I don't know exactly what it is but each Spin statement in "Pub High" get translated into a series of byte codes when you compile your program, these are loaded into HUB RAM. The interpreter's job is to step through these byte codes and execute them. The interpreter is essentially a virtual machine that has an instruction set made up of the byte codes. Each byte code will cause 10's, 100's of actual Propeller instructions to be executed.
HUBRAM is the "program memory" for the Spin virtual machine - it can only execute byte codes from HUB RAM; just like COGRAM is the "program memory" for a COG, it can only execute Propeller instructions from COG RAM.
Somewhere in there among the looping, you'll see it reading HUB RAM - this is it fetching byte codes. There are posts detailing how the byte code is layed out in HUB RAM and even what the byte codes are. I don't have any references handy.
Looking at assembled and loaded code and making sense of it is an art. It's certainly not easy when someone takes all you variable names and nice labels away - all those numbers just start to look alike!! That's one reason this is such a neat tool. It at least gives you a nice structure to start with. Having a fixed length instruction is also a big help. Some times you are faced with multiple and variable byte length instructions (8/16 bit micros mostly) - if you start decoding instructions at the wrong byte, you quickly get lost if not careful.
Yes, play and study time is necessary and in the case of Spin (or LMM or CMM, or XMM), you actually have to pieces of code to understand and trace; the kernel code implementing the virtual machine and then the byte code or whatever instructions the VM uses to implement the language you are using.
[/quote]
Yes, this is a very useful and beneficial program, good work jazzed.
Ray[/QUOTE]
Ray
What do you expect it to do when loaded to real hardware?
Does it generate any Spin byte codes in HUB RAM? (probably but not much - maybe some sort of "HALT")
I think it probably does just what is supposed to - runs the PUB (which contains nothing) and quits. I'm guessing it didn't "CRASH".
Try:
PUB main
repeat
I don't think it gets optimized in any way, so that should at least get you a "repeat" byte code out in HUB RAM, which you can watch the Spin interpreter fetch and execute constantly.
Ray
When I load it and run it, it does nothing (as expected).
If I hit stop and then go to debug, I see COG0 running through what I presume to be the Spin interpreter happily executing something. I don't read Spin byte code by sight but I presume that is what it is doing and the byte codes sitting in HUB RAM are valid.
I get no windows.
I'm running on a Mac, OSX 10.9 and with a simulator that I built both release and debug versions. I thought I was running the standalone executable I created but I just checked and I am running it from QT. The only output I'm seeing in the QT is HUBRAM address out of range messages every so often.
I can try the standalone program to see what it does.
EDIT: OK, it goes "BOOM" when run as a standalone program. When it's an alpha or a beta and Steve wants input and bug reports, I'll worry about what it doesn't do. Now, I'm just having fun with what it does do!!
Ray
There are some issues I've been looking at that are causing some of the things you've seen.
As I said before, it runs "simple" SPIN and C programs fine. You crossed the "simple" threshold when you added an object.
Ray
Tried my normal millisecond wait function, "pause" and got a longer pause (about 3 seconds)...
dgately
Sorry for the trouble. I just got home so I couldn't run any of the examples.
Still working on that other problem ... I pretty sure they are related ;-)
The simulator now runs the examples you all posted here. The repository has been updated.
I won't be looking at the program again for about a week. Any testing would be appreciated though.
The Run mode should allow you to blink the LED check boxes in real time. Debug mode goes as fast as it can based on Delay as mentioned before.
I've added a Trace window feature. It records results in Debug mode. You can search for items in the Trace window using CTRL+F (search forward) CTRL+R (search reverse) and F3 (search last word in last direction). Also, if you press CTRL+S in the Trace window it will display Spin bytecode accesses. This will allow following programs with the BSTC list feature.
To generate a BSTC list file use:
bstc -L library -ls test.spin
or
bstc -L library -l test.spin
Compile to .binary with:
bstc -L library -b test.spin
Yes, I plan to change the command toolbar again probably by making separate tool bars for different categories.
Let me know if you have any problems.
Ray
Can you take a video with CamStudio ?
I am still using the Qt Creator run command to start up the Simulator program. I use the 'hg clone ...' method to get the latest source, not sure if that is making a difference. I am doing all this in a real machine installation of Windows 7.
Ray
The erratic blinking you see may be an optical illusion because the blink rate in your program is 75ms ... not everyone can perceive that rate reliably. One theory is that no one can perceive a rate under 50ms reliably for example - old TVs took advantage of this
Oh, it occurs to me that not having a repeat at the end of your program may be causing problems. The interpreter executes all over the place after the cog starts. Having the repeat makes it behave much better (see Spin Trace w/Repeat below).
Can you copy paste your Debug Trace window here with the example you gave?
Two runs would be useful:
Spin Trace:
1. Load the binary
2. Click Trace to see the window
3. Press CTRL+S once in the trace window for Spin trace.
4. Click Debug to start the program.
Full Trace (assuming Trace is open from above):
1. Load the binary
2. Press CTRL+S to turn off Spin trace.
3. Click Debug to start the program
Now the 1 second pasm blinker is misbehaving for me. All of this stuff worked perfectly yesterday.
$ hg pull
$ hg update
I also changed the Trace window CTRL+S command so it always sets Spin Trace. Now CTRL+P sets PASM Trace. Hope those key combinations don't cause trouble.
The trace feature is nifty!!
EDIT: I forget shortcut keys anyway, so either any combinations give me trouble or no combinations give me trouble!
I pushed a fix for a bug where the special registers got clobbered on COGINIT. Now GCC CMM toggle should work.
Also, GCC CMM filtering has been added in Trace with CTRL+G. Some day I'll make those selections buttons.
What have I learned today? It looks like COG 0 RAM gets loaded up, all 496 bytes(what do you do with the other 16 bytes that are available) worth, with the same code, using different programs, even though there is a cognew in the PASM Toggle example. The actual program and data gets loaded into HUB RAM and run from there, even the PASM example. These are general observations, I know there is some other stuff that gets loaded into HUB too.
So, from the looks of it, with the tools that are at hand, there is no way too actually have some code lines that have been written with either PropellerIDE or the Propeller Tool be run strictly in COG RAM. I had the impression that somehow PASM program code got run in COG RAM, but so far I do not see any evidence of that. What I see is, using the blinker examples, the PASM Toggle example shows a smaller code size in HUB RAM, compared too the Spin blinker example.
I still have not done any C coded programs, blinker style, maybe I will try a blinker program done in C and see how much HUB RAM gets used.
Ray
Great.
Yes, SPIN and other languages generally create a PASM interpreter (as Chip calls it) and fetch code from HUB RAM to act on in the interpreter. The other 16 bytes are the special registers.
Well, no that is not true. The interpreters run strictly in COG RAM. The only way to run a program is by loading something in a COG first.
PropellerGCC has always supported running code directly from COG RAM - see Eric's pong and vga programs in the PropellerGCC demos for examples.
Most of the C code in a blinker only program will be the part that runs in the COG. Same is true of SPIN except the Spin interpreter lives in the Propeller ROM.