Prop2 Interactive debugger

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.
mov pixels,#$c5 rolword pixels,pixels,#0 'copy words mergew pixels 'merge words rolword pixels,pixels,#0 'copy words mergew pixels 'merge words
and here's the test results from the debugger
/=========================================\ | Propeller 2 Interactive Debugger | | Version 1.8 - Ozpropdev 6th March 2017 | \=========================================/ -----------------------------------------------------------------------------------------(P2 Debugger) 00004: F60414C5 MOV $00A,#$0C5 (? for help) >SWL+ -----------------------------------------------------------------------------------------(P2 Debugger) COG | $0000A: "Pixels" $00000000 %00000000_00000000_00000000_00000000 #0 00004: F60414C5 MOV $00A,#$0C5 (? for help) >* -----------------------------------------------------------------------------------------(P2 Debugger) COG | $0000A: "Pixels" $000000C5 %00000000_00000000_00000000_11000101 #197 00005: F940140A ROLWORD $00A,$00A,#0 (? for help) >* -----------------------------------------------------------------------------------------(P2 Debugger) COG | $0000A: "Pixels" $00C500C5 %00000000_11000101_00000000_11000101 #12910789 00006: F9FC1403 SFUNC $00A,#$003 (? for help) >* -----------------------------------------------------------------------------------------(P2 Debugger) COG | $0000A: "Pixels" $0000F033 %00000000_00000000_11110000_00110011 #61491 00007: F940140A ROLWORD $00A,$00A,#0 (? for help) >* -----------------------------------------------------------------------------------------(P2 Debugger) COG | $0000A: "Pixels" $F033F033 %11110000_00110011_11110000_00110011 #4029935667 #-265031629 00008: F9FC1403 SFUNC $00A,#$003 (? for help) >* -----------------------------------------------------------------------------------------(P2 Debugger) COG | $0000A: "Pixels" $FF000F0F %11111111_00000000_00001111_00001111 #4278193935 #-16773361 00009: FD9FFFFC JMP #$FFFFC (? for help) >
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!
-----------------------------------------------------------------------------------------(P2 Debugger) COG | $00008: "Pixels" $000000C5 %00000000_00000000_00000000_11000101 #197 00005: F9F41000 MOVBYTS $008,#$000 (? for help) >* -----------------------------------------------------------------------------------------(P2 Debugger) COG | $00008: "Pixels" $C5C5C5C5 %11000101_11000101_11000101_11000101 #3318072773 #-976894523 00006: F9FC1001 SFUNC $008,#$001 (? for help) >* -----------------------------------------------------------------------------------------(P2 Debugger) COG | $00008: "Pixels" $FF000F0F %11111111_00000000_00001111_00001111 #4278193935 #-16773361 00007: FD9FFFFC JMP #$FFFFC (? for help) >$
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....
/==========================================\ | Propeller 2 Interactive Debugger - V17 | | Version 2.2 - Ozpropdev 29th March 2017 | \==========================================/ -----------------------------------------------------------------------------------------(P2 Debugger) 00004: F547F6FF OR DIRB,#$0FF (? for help) >* -----------------------------------------------------------------------------------------(P2 Debugger) 00005: FD641C31 SKIP #$00E 00006: FD644049 OUTH #$020 00007: FD644249 <cancel> OUTH #$021 00008: FD644449 <cancel> OUTH #$022 00009: FD644649 <cancel> OUTH #$023 0000A: FD645E59 DRVH #$02F (? for help) >* -----------------------------------------------------------------------------------------(P2 Debugger) 0000B: FD641432 SKIPF #$00A 0000C: FD645049 OUTH #$028 0000D: FD645249 <skipped> OUTH #$029 0000E: FD645449 OUTH #$02A 0000F: FD645649 <skipped> OUTH #$02B (? for help) >* -----------------------------------------------------------------------------------------(P2 Debugger) 00010: FD645C59 DRVH #$02E (? for help) >* -----------------------------------------------------------------------------------------(P2 Debugger) 00011: FCDC0A02 REP #$005,#$002 00012: FD641C31 SKIP #$00E 00013: FD645049 OUTH #$028 00014: FD645249 <cancel> OUTH #$029 00015: FD645449 <cancel> OUTH #$02A 00016: FD645649 <cancel> OUTH #$02B 00017: FD645A59 DRVH #$02D (? for help) >* -----------------------------------------------------------------------------------------(P2 Debugger) 00018: FD64342A PUSH #$01A (? for help) >* -----------------------------------------------------------------------------------------(P2 Debugger) 00019: FD603833 EXECF $01C 0001D: FD644A49 <skipped> OUTH #$025 0001E: FD644C49 <skipped> OUTH #$026 0001F: FD644E49 OUTH #$027 (? for help) >* -----------------------------------------------------------------------------------------(P2 Debugger) 00020: 05440000 _RET_ OR $000,#$000 (? for help) >* -----------------------------------------------------------------------------------------(P2 Debugger) 0001A: FD645859 DRVH #$02C (? for help) >
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?
-----------------------------------------------------------------------------------------(P2 Debugger) 00005: FD641C31 SKIP #$00E 00006: FD644049 OUTH #$020 00007: FD644249 <cancel> OUTH #$021 00008: FD644449 <cancel> OUTH #$022 00009: FD644649 <cancel> OUTH #$023 0000A: FD645E59 DRVH #$02F ' <<<< not expected to execute with skip group above (? for help) >* -----------------------------------------------------------------------------------------(P2 Debugger) 0000B: FD641432 SKIPF #$00A 0000C: FD645049 OUTH #$028 0000D: FD645249 <skipped> OUTH #$029 0000E: FD645449 OUTH #$02A 0000F: FD645649 <skipped> OUTH #$02B (? for help) >* -----------------------------------------------------------------------------------------(P2 Debugger) 00010: FD645C59 DRVH #$02E '<<<< Ok. The SKIP instruction above should have done the sme. (? for help) >*
FYI Be aware my debugger is using the "debug interrupt" to single step.
Or are you saying that the DRVH was cancelled?