Re: Computer architects leaving Intel...

On 9/18/2024 9:27 AM, MitchAlsup1 wrote:

On Wed, 18 Sep 2024 4:00:43 +0000, BGB wrote:
 

On 9/17/2024 6:04 PM, MitchAlsup1 wrote:

 

Still limited to 32-bit displacement from IP.
>
How would you perform the following call::
current IP = 0x0000000000001234
target  IP = 0x7FFFFFFF00001234
>
This is a single (2-word) instruction in my ISA, assuming GOT is
32-bit displaceable and 64-bit entries.
>

>
Granted, but in plain RISC-V, there is no real better option.
>
If one wants to generate 64-bit displacement, and doesn't want to load a
constant from memory:
   LUI X6, Disp20Hi       //20 bits
   ADDI X6, X6, Disp12Hi  //12 bits
   AUIPC X7, Disp20Lo
   ADD X7, Disp12Lo
   SLLI X6, X6, 32
   ADD X7, X7, X6

 How very much simpler is::
      MEM    Rd,[IP,Ri<<s,DISP64]
 1 instruction, 3 words, 1 decode cycle, no forwarding, shorter latency.

It is simpler, but N/E in RV64G...
This is the whole issue of the idea:
   Remain backwards compatible with RV64G / RV64GC (in a binary sense).
*and* try to allow extending it in a way such that performance can be less poor...
Though, the new encodings, and 'C', could not be used at the same time.
Most likely, it would be a per-binary option, with some wonk in the function prologs to deal with uncertain cases. Granted, less obvious how to approach this without adding extra overhead for ELF SO's, where pretty much every function may be potentially exported.
Even if GCC output targeting RV64GC is still going to produce the same sort of code as before (typically generating constants via memory loads).

>
Which is sort of the whole reason I am considering hacking around it
with an alternate encoding scheme.

 Just put in real constants.

>
New encoding scheme can in theory do:
   LEA X7, PC, Disp64
In a single 96-bit instruction.

 Where is the indexing register?

Generally the use of a displacement and index register are mutually exclusive (and, cases that can make use of Disp AND Index are much less common than Disp OR Index).
I may still consider defining an encoding for this, but not yet. It is in a similar boat as auto-increment. Both add resource cost with relatively little benefit in terms of overall performance. Auto-increment because if one has superscalar, the increment can usually be co-executed. And, full [Rb+Ri*Sc+Disp], because it is just too infrequent to really justify the extra cost of a 3-way adder even if limited mostly to the low-order bits...

>

------------

>
AUPIC is (and remains) a crutch (like LUI from MIPS)
a) it consumes an instruction (space and time)
b) it consumes a register unnecessarily
c) it consumes power that direct delivery of the constant would not

>
Yeah, pretty much.
   LUI + AUIPC + JAL, eat nearly 27 bits of encoding space.
>