Prop2 Interactive debugger
ozpropdev
Posts: 2,792
in Propeller 2
Hi P2 Testers
This may be useful to you folks wanting to play/test the P2.
It's a interactive debugger that allows you to single step through test code and
view flag status, stack contents, cog/lut and hub contents and IO pin states.
It utilizes the debug interrupt and I have found it a essential tool.
The Debugger interface requires a serial terminal @ 1Mbaud.
Included in the code is a sample test program that tests the new nibble instructions.
All FPGA builds will run the demo.
If you want to discover how some of the P2 instructions work this will give you a clear insight.
Have fun!
This may be useful to you folks wanting to play/test the P2.
It's a interactive debugger that allows you to single step through test code and
view flag status, stack contents, cog/lut and hub contents and IO pin states.
It utilizes the debug interrupt and I have found it a essential tool.
The Debugger interface requires a serial terminal @ 1Mbaud.
Included in the code is a sample test program that tests the new nibble instructions.
All FPGA builds will run the demo.
If you want to discover how some of the P2 instructions work this will give you a clear insight.
Have fun!
Comments
What happened to your great tool to generate dedicated P1V verilog code, is it still available for download?
Down-under must be a great and creative place to live in, got some space to spare??
The P1V stuff disappeared when the forum was updated.
I still use the Verilog generator and have updated it a bit since it was last posted.
I will try and tidy it up a bit on the weekend and post an update.
BTW What FPGA boards are you playing with?
P.S Sorry no space available, all available space filled with FPGA's and P2 related stuff.
The reason for asking is that I might want to implement a P1V booting from internal memory, and I remember your P1V tool having a way of modifying the ROM.
My vision of your country is one where you can get fined if you don't carry 5 spare fuel cannisters when going to visit your mother in law in the neighbouring town
I think you watch too much TV, it's not like that at all. As if we would go visit the mother-in-law. The difference between outlaws and inlaws is that outlaws are wanted.
I took some old tires I found to the dump and they said I was lucky the Highway Patrol didn't notice, because you can get fined $10,000 for carrying ten tires without a special permit. Nine tires is no problem, though. It's so much safer.
That reminds me of something I heard the other day: "It's so crowded that nobody goes there, anymore."
But, hey, I gave up wondering about the sanity of the law when we started to have to pay a levy to the copyright MAFIA when buying blank CD's or hard drives. Or listening to the radio in a taxi cab.
Or was it before that...?
I do recall a little issue back in the 1980's when a package with a few 360K floppy discs in it, destined for the company I worked for, was held up by customs.
As an import the customs had to impose some kind of duty on it. The question was, should they value it at the couple of pennies the floppy disks were worth. Or, should they value it at the 10,000 dollars per seat of the licence cost for the software on the disks?
The world had little idea of what software was at the time.
Perhaps that has not changed much.
Pretty hard to enforce silly laws like that now that "big data" like that can fit on tiny micro SD cards. Also says something about the intelligence of people that come up with those laws.
I have never heard of such a law.
But wait -- this is the debugger thread. How did we end up here? What I really wanted to write in this thread is that I'm very impressed with ozpropdev's work. Great idea, great project.
I needed a way of expanding some pixel data from 8 bits to 32 bits.
Here's a neat combinations of P2's instructions that do the job nicely.
and here's the test results from the debugger
Note that the debuuger displays the MERGEW instruction by it's real name not it's alias.
You are turning each bit into 4 identical bits. I had to look at that for a while.
I think you could do this, too:
mov pixels,#$C5
movbyts pixels,#%00_00_00_00
mergeb pixels
That's better again Chip!
It now looks ahead to show which instructions will be cancelled/skipped.
It all seems to work Ok, although I have noticed a slight difference in regards to the instruction following the SKIPF block compared to SKIP and EXECF. I'll keep digging....
Looks nice.
I thought the ..F ones were the HOPS and the SKIP was the one that did what it says ?
(which seems the opposite of your tags <skipped> <cancel> ?)
On other MCUs with SKIP instructions, they treat the SKIP as a NOP.
This semantic issue is why I prefer HOP over SKIP, for the variant (fast) version of SKIP.
Words like HOP make it clearer there was a short jump, clear over the opcodes.
SKIPF advances the PC to actually skip past them and won't work with REP well or HUBEXEC.
I am with @ozpropdev
cancel = cancel the instruction, transforms it in NOP, still take clocks because NOPs are executed
skip = jump over (advance PC), thus non needed clocks because the instructions are not executed at all
The problem with such re-define of skip, as actually a jump-over, is that others before this have used SKIP to mean the opposite (aka treat as NOP).
The nett result will be general confusion in the user base.
Here is one example, of existing MCU terminology usage for SKIP. Note the reach, and cycle times == NOPs.
http://www.atmel.com/webdoc/avrassembler/avrassembler.wb_CPSE.html
Like the opcode, no confusion.
I think cancel is OK because that is what chip is referring too, canceling instruction, but still taking the time because it is a nop now
Great work @ozpropdev, I wish I understand half of the stuff you know already about the P2.
Enjoy!
Mike
Are you still seeing anything weird?
The only thing that's a bit weird is the SKIP instruction seems to include the instruction after the expected 4 instructions in my example.
SKIPF works as expected with 4 instructions in group.
Is it a pipeline "cancel" thing?
FYI Be aware my debugger is using the "debug interrupt" to single step.
Or are you saying that the DRVH was cancelled?