Re: Stealing a Great Idea from the 6600

On 4/26/2024 8:25 AM, MitchAlsup1 wrote:

BGB wrote:
 

On 4/25/2024 4:01 PM, George Neuner wrote:

On Tue, 23 Apr 2024 17:58:41 +0000, mitchalsup@aol.com (MitchAlsup1)
wrote:
>

 

Agreed in the sense that negative displacements exist.

 

However, can note that positive displacements tend to be significantly more common than negative ones. Whether or not it makes sense to have a negative displacement, depending mostly on the probability of greater than half of the missed displacements being negative.

 

 From what I can tell, this seems to be:
   ~ 10 bits, scaled.
   ~ 13 bits, unscaled.

 

So, say, an ISA like RISC-V might have had a slightly hit rate with unsigned displacements than with signed displacements, but if one added 1 or 2 bits, signed would have still been a clear winner (or, with 1 or 2 fewer bits, unsigned a clear winner).

 

I ended up going with signed displacements for XG2, but it was pretty close to break-even in this case (when expanding from the 9-bit unsigned displacements in Baseline).

 

Granted, all signed or all-unsigned might be better from an ISA design consistency POV.

 

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.
 

I was seeing stats more like 99.8% positive, 0.2% negative.
There was enough of a bias that, below 10 bits, if one takes all the remaining cases, zero extending would always win, until reaching 10 bits, when the number of missed reaches 50% negative (along with positive displacements larger than 512).
So, one can make a choice: -512..511, or 0..1023, ...
In XG2, I ended up with -512..511, for pros or cons (for some programs, this choice is optimal, for others it is not).
Where, when scaled for QWORD, this is +/- 4K.
If one had a 16-bit displacement, it would be a choice between +/- 32K, or (scaled) +/- 256K, or 0..512K, ...
For the special purpose "LEA.Q (GBR, Disp16), Rn" instruction, I ended up going unsigned, where for a lot of the programs I am dealing with, this is big enough to cover ".data" and part of ".bss", generally used for arrays which need the larger displacements (the compiler lays things out so that most of the commonly used variables are closer to the start of ".data", so can use smaller displacements).
Does implicitly require that all non-trivial global arrays have at least 64-bit alignment.
Note that seemingly both BGBCC and GCC have variations on this optimization, though in GCC's case it requires special command-line options ("-fdata-sections", etc).

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
 

In my case, all of these are [SP+Disp], granted, there is no frame pointer and stack frames are fixed-size in BGBCC.
This is typically with a frame layout like:
   Argument/Spill space
   -- Frame Top
   Register Save
   (Stack Canary)
   Local arrays/structs
   Local variables
   Argument/Spill Space
   -- Frame Bottom
Contrast with traditional x86 layout, which puts saved registers and local variables near the frame-pointer, which points near the top of the stack frame.
Though, in a majority of functions, the MOV.L and MOV.Q functions have a big enough displacement to cover the whole frame (excludes functions which have a lot of local arrays or similar, though overly large local arrays are auto-folded to using heap allocation, but at present this logic is based on the size of individual arrays rather than on the total combined size of the stack frame).
Adding a frame pointer (with negative displacements) wouldn't make a big difference in XG2 Mode, but would be more of an issue for (pure) Baseline, where options are either to load the displacement into a register, or use a jumbo prefix.

But, admittedly, main reason I went with unscaled for GBR-rel and PC-rel Load/Store, was because using scaled displacements here would have required more relocation types (nevermind if the hit rate for unscaled 9-bit displacements is "pretty weak").

 

Though, did end up later adding specialized Scaled GBR-Rel Load/Store ops (to improve code density), so it might have been better in retrospect had I instead just went the "keep it scaled and add more reloc types to compensate" option.

 

....

 

YMMV.