Re: Stealing a Great Idea from the 6600

On 4/26/2024 4:07 PM, MitchAlsup1 wrote:

BGB wrote:
 

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.

 After pulling out the calculator and thinking about the frames, My 66000 needs no more than 18 DW of negative addressing. This is just
over 0.2% as you indicate.
 

OK.
Not entirely sure I know what you mean be 'DW' here though...

 

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

 We looked at this in Mc88100 (scaling of the displacement). The drawback
was that the ISA and linker were slightly mismatched: The linker wanted
to use a single upper 16-bit LUI <if it were> over several LD/STs of
potentially different sizes, and scaling of the displacement failed in
those regards; so we dropped scaled displacements.
 

This is partly why I initially went with unscaled for PC-rel and GBR-rel cases, since these were being used for globals, and the linker/reloc stage would need to deal with more complexity for the relocs in this case.
For normal direct displacements, these will not typically be used for accessing globals or similar, or otherwise need relocs, so scaled made more sense here.
Some scaled cases (for GBR) were later re-added mostly as an optimization case.
And, when generating the binary all at once, it is possible to cluster the commonly used globals close together rather than have them scattered all across ".data" and ".bss" (so, most of the further reaches of these sections can be all the bulk arrays and similar).
If doing separate compilation, likely the compiler would need to use the generic case (or possibly involve the arcane magic known as "linker relaxation").

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

 Not even an issue when one has universal constants.
 

In this case:
   LEA.B (GBR, Disp33s), Rn
Needs 64 bits to encode, whereas:
   LEA.Q (GBR, Disp16u), Rn
Can be encoded in 32 bits (but only applicable if the array is within 512K of GBR).
This saves some space for loading the address of a global array.
Though, as-is, string literals still always need the longer form:
   LEA.B (PC, Disp33s), Rn
...
Similar also applies for function pointers.

 

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.