Re: Stealing a Great Idea from the 6600

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

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.