Re: Stealing a Great Idea from the 6600

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

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

George Neuner wrote:
>

On Sun, 21 Apr 2024 00:43:21 +0000, mitchalsup@aol.com (MitchAlsup1)
wrote:

>

Address arithmetic is ADD only and does not care about signs or
overflow. There is no concept of a negative base register or a
negative index register (or, for that matter, a negative displace-
ment), overflow, underflow, carry, ...

>

Stack frame pointers often point to the middle of the frame and need
to access data using both positive and negative displacements.

>
Yes, one accesses callee saved registers with positive displacements
and local variables with negative accesses. One simply needs to know
where the former stops and the later begins. ENTER and EXIT know this
by the register count and by the stack allocation size.
>

Some GC schemes use negative displacements to access object headers.

>
Those are negative displacements not negative bases or indexes.

 I was reacting to your message (quoted fully above) which,
paraphrased, says "address arithmetic is add only and there is no
concept of a negative displacement".
 In one sense you are correct: the result of the calculation has to be
considered as unsigned in the range 0..max_memory ... ie. there is no
concept of negative *address*.
 However, the components being added to form the address, I believe are
a different matter.
 I agree that negative base is meaningless.
 However, negative index and negative displacement both do have
meaning. The inclusion of specialized index registers is debatable
[I'm in the GPR camp], but I do believe that index and displacement
*values* both always should be considered as signed.
 

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