Re: Stealing a Great Idea from the 6600

BGB wrote:

On 4/26/2024 1:59 PM, EricP wrote:

MitchAlsup1 wrote:

BGB wrote:
>

If one had 16-bit displacements, then unscaled displacements would make sense; otherwise scaled displacements seem like a win (misaligned displacements being much less common than aligned displacements).

>
What we need is ~16-bit displacements where 82½%-91¼% are positive.
>
How does one use a frame pointer without negative displacements ??
>
[FP+disp] accesses callee save registers
[FP-disp] accesses local stack variables and descriptors
>
[SP+disp] accesses argument and result values

 A sign extended 16-bit offsets would cover almost all such access needs
so I really don't see the need for funny business.
 But if you really want a skewed range offset it could use something like
excess-256 encoding which zero extends the immediate then subtract 256
(or whatever) from it, to give offsets in the range -256..+65535-256.
So an immediate value of 0 equals an offset of -256.
 

Yeah, my thinking was that by the time one has 16 bits for Load/Store displacements, they could almost just go +/- 32K and call it done.

But, much smaller than this, there is an advantage to scaling the displacements.

In other news, got around to getting the RISC-V code to build in PIE mode for Doom (by using "riscv64-unknown-linux-gnu-*").

Can note that RV64 code density takes a hit in this case:
   RV64: 299K (.text)
   XG2 : 284K (.text)

Is this indicative that your ISA and RISC-V are within spitting distance of each other in terms of the number of instructions in .text ?? or not ??

So, apparently using this version of GCC and using "-fPIE" works in my favor regarding code density...

I guess a question is what FDPIC would do if GCC supported it, since this would be the closest direct analog to my own ABI.

What is FDPIC ?? Federal Deposit Processor Insurance   Corporation ??
                 Final   Dopey   Position  Independent Code ??

I guess some people are dragging their feet on FDPIC, as there is some debate as to whether or not NOMMU makes sense for RISC-V, along with its associated performance impact if used.

In my case, if I wanted to go over to simple base-relocatable images, this would technically eliminate the need for GBR reloading.

Checks:
Simple base-relocatable case actually currently generates bigger binaries, I suspect because in this case it is less space-efficient to use PC-rel vs GBR-rel.

Went and added a "pbostatic" option, which sidesteps saving and restoring GBR (making the simplifying assumption that functions will never be called from outside the current binary).

This saves roughly 4K (Doom's ".text" shrinks to 280K).

Would you be willing to compile DOOM with Brian's LLVM compiler and
show the results ??

....