New P2 Silicon Observations - Page 21 — Parallax Forums

# New P2 Silicon Observations

• Posts: 10,451
edited 2018-11-18 05:33
Cluso99 wrote: »
Can anyone pick what is wrong with this?

Just by looking at the hex dump (ctrl-M) of Pasm, it is putting a relative address into the LOC. It works if you use the back-slash to force an absolute address.

LOC would always want an absolute address I'd think. Maybe that should be changed in Pasm.

• Posts: 10,451
edited 2018-11-18 05:57
RDLONG can't do relative so this works:
                setq2   #16-1
rdlong  lut_start,#@palette


EDIT: And, because ORGH is declaring it as hubram, you don't even need the @
                setq2   #16-1
rdlong  lut_start,#palette

• Posts: 10,451
Here's something amusing:
con
lut_start = 0

dat
org  0
loc     ptra,#\palette
setq2   #16-1
rdlong  lut_start,ptra

jmp     #$orgf$1f0
orgh  $400 '==================================================================== '24 bit color format = rr_gg_bb_00 '==================================================================== palette long 0 'black long$0000aa00       'blue
long    $00aa0000 'green long$00aaaa00       'cyan
long    $aa000000 'red long$aa00aa00       'magenta
long    $aa550000 'brown long$aaaaaa00       'gray
long    $55555500 'dark gray long$5555ff00       'bright blue
long    $55ff5500 'bright green long$55ffff00       'bright cyan
long    $ff555500 'bright red long$ff55ff00       'bright magenta
long    $ffff5500 'yellow long$ffffff00       'white
'====================================================================

• Posts: 10,451
Cluso99 wrote: »
Can anyone pick what is wrong with this?

The orgh $400 works but just a plain orgh does not. The palette is <$400.
I can change the $400 ->$404, $600, etc and it works fine, but if I make it$300 it fails.

Hmm, experimenting with ORGH $100, even as relative addressing, there is something wrong with what Pasm is generating by the looks of the hex dump: 00000- FC 03 D0 FE 29 1E 64 FD 00 01 04 FB FC FF 9F FD '....).d.........' 00010- 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 '................' 00020- 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 '................' 00030- 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 '................' 00040- 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 '................' 00050- 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 '................' 00060- 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 '................' 00070- 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 '................' 00080- 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 '................' 00090- 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 '................' 000A0- 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 '................' 000B0- 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 '................' 000C0- 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 '................' 000D0- 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 '................' 000E0- 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 '................' 000F0- 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 '................' 00100- 00 00 00 00 00 AA 00 00 00 00 AA 00 00 AA AA 00 '................' 00110- 00 00 00 AA 00 AA 00 AA 00 00 55 AA 00 AA AA AA '..........U.....' 00120- 00 55 55 55 00 FF 55 55 00 55 FF 55 00 FF FF 55 '.UUU..UU.U.U...U' 00130- 00 55 55 FF 00 FF 55 FF 00 55 FF FF 00 FF FF FF '.UU...U..U......'  First machine code is$fed003fc. I read that as relative address $3fc.$0fc would be more like it.

• Posts: 17,481
If palette is <$400 then #@palette and #palette give incorrect results... #\palette is the only one to always give the correct result. DAT orgh 0 org 0 entry loc ptra,#@palette ' wrong!!! relative loc ptra,#palette ' wrong!!! loc ptra,#\palette ' correct use of absolute hub address :) here jmp #here DAT orgh '==================================================================== '24 bit color format = rr_gg_bb_00 '==================================================================== palette long 0 'black long$0000aa00       'blue
long    $00aa0000 'green long$00aaaa00       'cyan
long    $aa000000 'red long$aa00aa00       'magenta
long    $aa550000 'brown long$aaaaaa00       'gray
long    $55555500 'dark gray long$5555ff00       'bright blue
long    $55ff5500 'bright green long$55ffff00       'bright cyan
long    $ff555500 'bright red long$ff55ff00       'bright magenta
long    $ffff5500 'yellow long$ffffff00       'white
'====================================================================

• Posts: 10,451
edited 2018-11-18 08:00
I think you've stumbled upon at least one bug in Pasm as well.
• Posts: 2,745
That's the way it's always been with Pnut.
Pnut interprets addresses below $400 as COG/LUT addresses. • Posts: 10,451 edited 2018-11-18 10:11 Brian, It's not that either. Cluso's original source of LOC ptra,#@palette produced$3c. At the time I assumed it was relative addressing but it's not correct for that. There's an extraneous leading "3", assuming relative hub addressing.

Have a read of that dump above. The first code is a LOC instruction as per Cluso's example. I'm using ORGH $100 instead of$400.

The resulting address appears to be $3fc, which is way too high and, again, has an extraneous leading "3" for relative hub addressing. If it was assembling as absolute cog addressing then the address should have been$40. If relative cog addressing then it should have been $3f. If absolute hub addressing then it should have been$100. If relative hub addressing then it should have been $fc. • Posts: 10,451 Err, I probably should be saying Pnut rather than Pasm. • Posts: 2,745 I think this is why pnut has trouble. Consider the following code. DAT org barney jmp #fred nop fred jmp #barney  Pnut generates the following output. 00000- 04 00 90 FD 00 00 00 00 F4 FF 9F FD 27 96 80 FF '............'...'  Notice the relative offsets need to be shifted right 2 places to be cog/lut offsets. • Posts: 17,481 It is worse than this. Definitely a pnut problem! DAT org 0 .... loc pa,#@gfx '\ launch graphics demo coginit #16,pa '/ .... '==================================================================== orgh$400              ' REQUIRED TO BE >=$400 org 0 gfx jmp #demo 'launch hubexec code  This requires not only #@gfx to be used, but gfx code must be >=$400

I had problems with the ROM code. We solved it at the time although I was not convinced of the solution. It was probably that the ROM code resides in $FC000... so thankfully it worked. • Posts: 10,451 Oh, okay, so the machine coding for branching is effectively hub addressing all the time. Cool. Doesn't fix my example of$3fc though. It should have been $fc. Here's the source: con lut_start = 0 dat org 0 loc ptra,#palette setq2 #16-1 rdlong lut_start,ptra jmp #$

orgh  $100 '==================================================================== '24 bit color format = rr_gg_bb_00 '==================================================================== palette long 0 'black long$0000aa00       'blue
long    $00aa0000 'green long$00aaaa00       'cyan
long    $aa000000 'red long$aa00aa00       'magenta
long    $aa550000 'brown long$aaaaaa00       'gray
long    $55555500 'dark gray long$5555ff00       'bright blue
long    $55ff5500 'bright green long$55ffff00       'bright cyan
long    $ff555500 'bright red long$ff55ff00       'bright magenta
long    $ffff5500 'yellow long$ffffff00       'white
'====================================================================

• Posts: 17,481
For reference, here is test code that I used to verify the results.
Note that I am using the ROM monitor and serial code to display the results, and then I call the monitor so that I can examine cog/lut/hub memory.

pnut will compile it as a spin file or you can rename it spin2.
• Posts: 2,745
This has been brought up several times over the last couple of years.
Need to find some of the old posts on this.
IIRC Chip said this was a bit of a headache.

• Posts: 10,451
edited 2018-11-18 11:05
ozpropdev wrote: »
IIRC Chip said this was a bit of a headache.

Okay, no problem. Sounds like it'll be sorted out when Pnut is replaced.

• Posts: 17,481
I just spent a whole day on this problem. Because it is inconsistent, changing from #\xxx to #@xxx fixed one problem and caused another.

What concerns me more though, is it could cause a problem in the ROM and that could be a disaster
• Posts: 10,066
p2asm assembles the same too;

DAT
00000                              orgh    0
00000 000                          org     0
00000 000          entry
00000 000 fed0003c                 loc     ptra,#@palette                  ' wrong!!! relative
00004 001 fed00038                 loc     ptra,#palette                   ' wrong!!!
00008 002 fec00010                 loc     ptra,#\palette                  ' correct use of absolute hub address :)
0000c 003 fd9ffffc here            jmp     #here

DAT
00010                              orgh
'====================================================================
'24 bit color format = rr_gg_bb_00
'====================================================================
00010     00000000 palette         long    0               'black
00014     0000aa00                 long    $0000aa00 'blue 00018 00aa0000 long$00aa0000       'green
0001c     00aaaa00                 long    $00aaaa00 'cyan 00020 aa000000 long$aa000000       'red
00024     aa00aa00                 long    $aa00aa00 'magenta 00028 aa550000 long$aa550000       'brown
0002c     aaaaaa00                 long    $aaaaaa00 'gray 00030 55555500 long$55555500       'dark gray
00034     5555ff00                 long    $5555ff00 'bright blue 00038 55ff5500 long$55ff5500       'bright green
0003c     55ffff00                 long    $55ffff00 'bright cyan 00040 ff555500 long$ff555500       'bright red
00044     ff55ff00                 long    $ff55ff00 'bright magenta 00048 ffff5500 long$ffff5500       'yellow
0004c     ffffff00                 long    $ffffff00 'white '====================================================================  • Posts: 10,451 Cluso, Stop using LOC. It doesn't seem to be a benefit for what you are doing. MOV lmm_x, ##gfx ' will always give an absolute address and takes same code space as LOC + MOV. • Posts: 10,451 I don't think LOC has any real use for a PC-relative mode at all. Changing the assemblers to only encoding absolute addresses will probably solve Chip's headache. • Posts: 10,451 Oh, wow, Brian, you've used LOC a lot in that logic analyser program. • Posts: 17,481 edited 2018-11-18 12:54 Chip uses loc everywhere. It's in the VGA programs that I think Chip wrote originally. That's what I am working on, but every time I moved something it broke BTW loc is a single instruction, not 2 as in mov xx,##xxx. Just realised what you meant. No, that LOC + MOV was just so I could see what LOC was doing. It's regularly loading up PTRA/PTRB. • Posts: 10,451 edited 2018-11-18 14:19 Turns out the using @ in hubexec will also mess it up when the label's address is >=$400. It seems to me that
loc     ptra, #\label

is the safe bet.

I'm guessing non-LOC instructions are the ones that have problems with backslash.

• Posts: 10,451
edited 2018-11-18 14:59
I've just done a blanket search&replace on Brian's LA program and aside from the LOC's preceding the three COGINIT's every LOC that was using an @ now uses a \

Seems to run fine. I've actually plugged in a VGA monitor now, didn't think about it before, and can get INFO and RUN buttons to trigger the display.

• Posts: 14,595
hmm ... Is anyone else thinking this P2ASM syntax-chaff needs some (re)work, if it confuses even seasoned programmers ?
• Posts: 10,160
No.
• Posts: 10,160
I will be frank. A lot of the proposed solutions are really ugly. What we have here is only confusing because we haven't visited the discussion for a while, nor was it presented or documented cleanly at the time. We should do those things first before doing anything else.
• Posts: 17,481
No. The use is inconsistent so it’s a pnut bug.
When I last fell foul of it we were trying to get the rom to onsemi.
We just need a consistent way to override its use.
• Posts: 10,160
Yes, we've got a bug there. Sorting that out is a very different thing from what jmg has proposed many, many times.

• Posts: 10,451
edited 2018-11-18 23:38
Okay, the reason why #\ doesn't always work is because it generates a label's address with respect to an issued ORG rather than always a hubram address of the loaded code. An ORGH brings it right. This will be as intended.

So, #@ is meant to be the be-all for forcing an address to a label as first loaded to hubram. Sadly, #@ when used on a LOC instruction will inappropriately generate a PC-relative address if pnut perceives the label to be in the same addressing domain as the executing code.

What's interesting is this mechanism is fine for encoding branch instructions directly. It's only a problem for LOC. Basically, LOC has no purpose supporting relative addressing.

• Posts: 4,758
I think this has come up before. For a label "foo" that's in hub, "#@foo" and "#foo" mean exactly the same thing: "@x" means "the hub value of x", so if x is already a hub address then there's no difference.

"#\foo" is the syntax to use if you want to force an absolute (not relative) address
"#\@foo" is the syntax to use if you want to force an absolute hub address, even if "foo" is defined in COG

It's confusing because we're used to thinking of "@foo" as "the address of foo", which implies an absolute address. But "@foo" just means "use the hub value for label foo" and implies nothing about whether absolute or relative addressing will be used.

PNut, p2asm, and fastspin all agree on this, AFAICT.