Re: Stealing a Great Idea from the 6600

BGB wrote:

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

 

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...

While I am sure I don't understand what 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            // What data does this access ?
     MOV.Q (GBR, 0), R18
     MOV.C (R18, R0), GBR

It appears to me that you are placing an array of GOT pointers at the first entry of any particular GOT ?!?
Whereas My 66000 uses IP relative access to the GOT the linker (or LD.so) setup avoiding the indirection. Then My 66000 does not have or need a pointer to GOT since it can
synthesize such a pointer at link time and then just use a IP relative
plus DISP32 to access said GOT.
So, say we have some external variables::
     extern uint64_t fred, wilma, barney, betty;
AND we postulate that the linker found all 4 externs in the same module
so that it can access them all via 1 pointer. The linker assigns an
index into GOT and setups a relocation to that memory segment and when
LD.so runs, it stores a proper pointer in that index of GOT, call this
index fred_index.
And we access one of these::
     if( fred at_work )
The compiler will obtain the pointer to the area fred is positioned via:
     LDD    Rfp,[IP,,#GOT+fred_index<<3]        // *
and from here one can access barney, betty and wilma using the pointer to fred and standard offsetting.
     LDD    Rfred,[Rfp,#0]     // fred
     LDD    Rbarn,[Rfp,#16]    // barney
     LDD    Rbett,[Rfp,#24]    // betty
     LDD    Rwilm,[Rfp,#8]     // wilma
These offsets are known at link time and possibly not at compile time.
(*) if the LDD through GOT takes a page fault, we have a procedure setup
so LD.so can run figure out which entry is missing, look up where it is
(possibly load and resolve it) and insert the required data into GOT.
When control returns to LDD, the entry is now present, and we now have access to fred, wilma, barney and betty.

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.

....

{{ // this looks like stuff that should be accessible to LD.so

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.

but not the program itself}}