sleigh: having trouble exporting an address

[fenugrec]

For context, I'm working on the 8048 implementation : https://github.com/NationalSecurityAgency/ghidra/blob/master/Ghidra/Processors/8048/data/languages/8048.slaspec

Specifically this part :

PData: @A is A {
  local addr:2 = inst_next; addr[0,8] = A; export *[CODE]:1 addr;
}
AddrInd: PData is PData {
  local addr:2 = inst_next; addr[0,8] = PData; export *[CODE]:1 addr;
}
.....
:JMPP AddrInd   is ophi=11 & oplo=3 & AddrInd {
  goto AddrInd;
}

Where JMPP seems to be doing two indirections : one in PData and then one again in AddrInd ?

MCS-48 docs say :

JMPP
The contents of the program memory location pointed to by the accumulator
are substituted for the 'page' portion of the program counter (PC bits 0-7).

(worded differently in another doc : )
The contents of the Program Memory location addressed by the Accumulator
is used as the new page offset of the Program Counter.

(PC 0 – 7) <- ((A))

Current implementation doesn't work ( Low-level Error: Could not find op at target address: (unique,0x00003280) )

       CODE:0168 b3              JMPP       @A
                                                      $U2d00:2 = COPY 0x169:2
                                                      $U2d80:2 = INT_AND $U2d00:2, 0xff00:2
                                                      $U2e00:2 = INT_ZEXT A
                                                      $U2d00:2 = INT_OR $U2d80:2, $U2e00:2
                                                      $U3100:2 = COPY 0x169:2
                                                      $U3180:2 = INT_AND $U3100:2, 0xff00:2
                                                      $U2e80:1 = LOAD CODE($U2d00:2)
                                                      $U3200:2 = INT_ZEXT $U2e80:1
                                                      $U3100:2 = INT_OR $U3180:2, $U3200:2
                                                      $U3280:1 = LOAD CODE($U3100:2)
                                                      BRANCH $U3280:1

I see two LOAD_CODE() operations where I think there should only be one ? i.e. we should only doing one LOAD_CODE at (inst_start & 0xFF00 | A) .

My broken sleigh would currently looks like this, after many different (but also broken) attempts :

AddrInd: @A is A {
  local tgt:2 = inst_start;
  tgt[0,8] = A;
  local tmp:1 = *[CODE]:1 tgt;
  tgt[0,8] = tmp;
  export *[CODE]:2 tgt;
}
:JMPP AddrInd   is ophi=11 & oplo=3 & AddrInd {
  goto AddrInd;
}

I tried different export lines, removing the *[CODE] part, etc... Read many sections of the Sleigh but I don't understand all of it, I'm clearly missing something.

[fenugrec]

The MCS-48 emulator in MAME (which is known to implement JMPP correctly) does a simple m_pc &= 0xf00; m_pc |= program_r(m_pc | m_a);

[fenugrec]

Aaaaaaaaaaah

:JMPP @^A is ophi=11 & oplo=3 & A {
  local holder:2 = inst_start;
  holder[0,8] = A;
  local tgt:2 = inst_start;
  tgt[0,8] = *[CODE]:1 holder;
  goto [tgt];
}

Disasm:

       CODE:0168 b3              JMPP       @A
                                                      $U4880:2 = COPY 0x168:2
                                                      $U4900:2 = INT_AND $U4880:2, 0xff00:2
                                                      $U4980:2 = INT_ZEXT A
                                                      $U4880:2 = INT_OR $U4900:2, $U4980:2
                                                      $U4a00:2 = COPY 0x168:2
                                                      $U4b00:2 = INT_AND $U4a00:2, 0xff00:2
                                                      $U4a80:1 = LOAD CODE($U4880:2)
                                                      $U4b80:2 = INT_ZEXT $U4a80:1
                                                      $U4a00:2 = INT_OR $U4b00:2, $U4b80:2
                                                      BRANCHIND $U4a00:2

And... decompiled is a bit disappointing, but at least it's not giving the "low-level error" anymore:

void FUN_CODE_015e(void)
{
  char in_R0;
  
                    /* WARNING: Could not recover jumptable at 0x0168. Too many branches */
                    /* WARNING: Treating indirect jump as call */
  (*(code *)((ushort)*(byte *)((ushort)(in_R0 + 0x49) | 0x100) | 0x100))();

This took way longer than it should.
Would still appreciate comments on whether there's a smarter way to write it ? Or some way that would help the decompiler figure out the jumptable.

[GhidorahRex]

:JMPP @^A is ophi=11 & oplo=3 & A {
  local holder:2 = inst_start;
  holder[0,8] = A;
  local tgt:2 = inst_start;
  tgt[0,8] = *[CODE]:1 holder;
  goto [tgt];
}

Without looking too deeply into it, I would assume the fix would be:

PData: @A is A {
  local addr:2 = inst_next; addr[0,8] = A; export *[CODE]:1 addr;
}
AddrInd: PData is PData {
  local addr:2 = inst_next; addr[0,8] = PData; export addr;
}
:JMPP AddrInd   is ophi=11 & oplo=3 & AddrInd {
  goto [AddrInd];
}

Is there a specific reason you switched from inst_next to inst_start ?

[fenugrec]

Thanks for looking at this. Your fix seems to match mine functionally, but I like your version better. "all" it took was
1- tweak the export in AddrInd so it doesn't do the unnecessary de-reference
2- goto needs [ ] around its argument now

Is there a specific reason you switched from inst_next to inst_start ?

It was a wrong interpretation of a warning in the MCS-48 docs:

Any jump instruction beginning in location 2047 or 4095 is invalid. A CALL cannot begin in locations 2046-2047 or 4094-4095.

but I later found

If a conditional jump or JMPP begins in location 255 of a page, it must reference a destination on the following page.

so inst_next was correct.

Not sure how to mark this discussion as Done or Answered, but I think it is.

Thanks again !

[fenugrec]

Going beyond this (and a bit off-topic) : is it possible to define a data type, of size 1 byte, that is a "pointer inside current page" ? (i.e. the lower 8 bits of PC). It would help for this kind of jump table.