Re: Stealing a Great Idea from the 6600

On 4/28/2024 2:24 PM, MitchAlsup1 wrote:

BGB wrote:
 

On 4/27/2024 8:45 PM, MitchAlsup1 wrote:

>
>

But, I think the main difference is that, normal PIC does calls like like:
   LD Rt, [GOT+Disp]
   BSR Rt

>
     CALX   [IP,,#GOT+#disp-.]
>
It is unlikely that %GOT can be represented with 16-bit offset from IP
so the 32-bit displacement form (,,) is used.
>

Wheres, FDPIC was typically more like (pseudo ASM):
   MOV SavedGOT, GOT
   LEA Rt, [GOT+Disp]
   MOV GOT, [Rt+8]
   MOV Rt, [Rt+0]
   BSR Rt
   MOV GOT, SavedGOT

>
Since GOT is not in a register but is an address constant this is also::
>
     CALX   [IP,,#GOT+#disp-.]
>

 

So... Would this also cause GOT to point to a new address on the callee side (that is dependent on the GOT on the caller side, and *not* on the PC address at the destination) ?...

 The module on the calling side has its GOT and the module on the called side
has its own GOT where offsets to/in GOT are determined by linker making the
module. There may be cases where multiple link edits on a final module have
some of the functions in this module accessed via GOT in this module and in
these cases one uses
     CALA   [IP,,#GOT+#disp-.]     // LDD ip changes to LDA ip
 

OK, but it seems I may be failing to understand something here...

In effect, the context dependent GOT daisy-chaining is a fundamental aspect of FDPIC that is different from conventional PIC.

 Yes, understood, and it happens.
 

But, in my case, noting that function calls tend to be more common than the functions themselves, and functions will know whether or not they need to access global variables or call other functions, ... it made more sense to move this logic into the callee.

>
>

No official RISC-V FDPIC ABI that I am aware of, though some proposals did seem vaguely similar in some areas to what I was doing with PBO.

>

Where, they were accessing globals like:
   LUI Xt, DispHi
   ADD Xt, Xt, DispLo
   ADD Xt, Xt, GP
   LD  Xd, Xt, 0

>

Granted, this is less efficient than, say:
   MOV.Q (GBR, Disp33s), Rd

>
     LDD   Rd,[IP,,#GOT+#disp-.]
>

 

As noted, BJX2 can handle this in a single 64-bit instruction, vs 4 instructions.

 

Though, people didn't really detail the call sequence or prolog/epilog sequences, so less sure how this would work.

>
>

Likely guess, something like:
   MV    Xs, GP
   LUI   Xt, DispHi
   ADD   Xt, Xt, DispLo
   ADD   Xt, Xt, GP
   LD    GP, Xt, 8
   LD    Xt, Xt, 0
   JALR  LR, Xt, 0
   MV    GP, Xs

>

Well, unless they have a better way to pull this off...

>
     CALX   [IP,,#GOT+#disp-.]
>

 

Well, can you explain the semantics of this one...

 

But, yeah, as far as I saw it, my "better solution" was to put this part into the callee.

>
>

Main tradeoff with my design is:
   From any GBR, one needs to be able to get to every other GBR;
   We need to have a way to know which table entry to reload (not statically known at compile time).

>
Resolved by linker or accessed through GOT in mine. Each dynamic
module gets its own GOT.
>

 

The important thing is not associating a GOT with an ELF module, but with an instance of said module.

 Yes.
 

So, say, one copy of an ELF image, can have N separate GOTs and data sections (each associated with a program instance).

 

In my PBO ABI, this was accomplished by using base relocs (but, this is N/A for ELF, where PE/COFF style base relocs are not a thing).

>
>

One other option might be to use a PC-relative load to load the index.
Say:
   AUIPC Xs, DispHi  //"__global_pbo_offset$" ?
   LD Xs, DispLo
   LD Xt, GP, 0   //get table of offsets
   ADD Xt, Xt, Xs
   LD  GP, Xt, 0

>

In this case, "__global_pbo_offset$" would be a magic constant variable that gets fixed up by the ELF loader.

>
     LDD   Rd,[IP,,#GOT+#disp-.]
>

 

Still going to need to explain the semantics here...

 IP+&GOT+disp-IP is a 64-bit pointer into GOT where the external linkage
pointer resides.

OK.
Not sure I follow here what exactly is going on...
As noted, if I did a similar thing to the RISC-V example, but with my own ISA (with the MOV.C extension):
     MOV.Q (PC, Disp33), R0
     MOV.Q (GBR, 0), R18
     MOV.C (R18, R0), GBR
Differing mostly in that it doesn't require base relocs.
The normal version in my case avoids the extra memory load, but uses a base reloc for the table index.
...
Though, the reloc format is at least semi-dense, eg, for a block of relocs:
   { DWORD rvaPage;   //address of page (4K)
     DWORD szRelocs;  //size of relocs in block
   }
With each reloc encoded as a 16-bit entry:
   (15:12): Reloc Type
   (11: 0): Address within Page (4K)
One downside is this format is less efficient for sparse relocs (current situation), where often there are only 1 or 2 relocs per page (typically the PBO index fixups and similar).
One situation could be to have a modified format that partially omits the block structuring, say:
   0ddd: Advance current page position by ddd pages (4K);
     0000: Effectively a NOP (as before)
   1ddd..Cddd: Apply the given reloc.
     These represent typical relocs, target dependent.
     HI16, LO16, DIR32, HI32ADJ, ...
     8ddd: Was assigned for PBO fixups;
     Addd: Fixup for a 64-bit address, also semi common.
   Dzzz/Ezzz: Extended Relocs
     These ones are configurable from a larger set of reloc types.
   Fzzz: Command-Escape
   ...
Where, say, rather than needing 1 block per 4K page, it is 1 block per PE section.
Though, base relocs are a relatively small part of the size of the binary.
To some extent, the PBO reloc is magic in that it works by pattern-matching the instruction that it finds at the given address. So, in effect, is only defined for a limited range of instructions.
Contrast with, say, the 1/2/3/4/A relocs, which expect raw 16/32/64 bit values. Though, a lot of these are not currently used for BJX2 (does not use 16-bit addressing nides, ...).
Here:
5/6/7/8/9/B/C, ended up used for BJX2 relocs in BJX2 mode.
   For other targets, they would have other meanings.
D/E/F were reserved as expanded/escape-case relocs, in case I need to add more. These would differ partly in that the reloc sub-type would be assigned as a sort of state-machine.