Re: "Mini" tags to reduce the number of op codes

BGB-Alt wrote:

On 4/11/2024 1:46 PM, MitchAlsup1 wrote:

BGB wrote:
>

>
Win-win under constraints of Load-Store Arch. Otherwise, it depends.

 Never seen a LD-OP architecture where the inbound memory can be in the Rs1 position of the instruction.
 

>

 

FWIW:
The LDSH / SHORI mechanism does provide a way to get 64-bit constants, and needs less encoding space than the LUI route.

 

   MOV Imm16. Rn
   SHORI Imm16, Rn
   SHORI Imm16, Rn
   SHORI Imm16, Rn

 

Granted, if each is a 1-cycle instruction, this still takes 4 clock cycles.

 As compared to::
      CALK   Rd,Rs1,#imm64
 Which takes 3 words (12 bytes) and executes in CALK cycles, the loading
of the constant is free !! (0 cycles) !! {{The above example uses at least
5 cycles to use the loaded/built constant.}}
 

The main reason one might want SHORI is that it can fit into a fixed-length 32-bit encoding.

While 32-bit encoding is RISC mantra, it has NOT been shown to be best
just simplest. Then, once you start widening the microarchitecture, it
is better to fetch wider than decode-issue so that you suffer least from boundary conditions. Once you start fetching wide OR have wide
decode-issue, you have ALL the infrastructure to do variable length
instructions. Thus, complaining that VLE is hard has already been
eradicated.

                              Also technically could be retrofitted onto RISC-V without any significant change, unlike some other options (as noted, I don't argue for adding Jumbo prefixes to RV under the basis that there is no real viable way to add them to RV, *).

The issue is that once you do VLE RISC-Vs ISA is no longer helping you
get the job done, especially when you have to execute 40% more instructions

Sadly, the closest option to viable for RV would be to add the SHORI instruction and optionally pattern match it in the fetch/decode.

Or, say:
   LUI Xn, Imm20
   ADD Xn, Xn, Imm12
   SHORI Xn, Imm16
   SHORI Xn, Imm16

Then, combine LUI+ADD into a 32-bit load in the decoder (though probably only if the Imm12 is positive), and 2x SHORI into a combined "Xn=(Xn<<32)|Imm32" operation.

This could potentially get it down to 2 clock cycles.

Universal constants gets this down to 0 cycles......

*: To add a jumbo prefix, one needs an encoding that:
   Uses up a really big chunk of encoding space;
   Is otherwise illegal and unused.
RISC-V doesn't have anything here.

Which is WHY you should not jump ship from SH to RV, but jump to an
ISA without these problems.

Ironically, in XG2 mode, I still have 28x 24-bit chunks of encoding space that aren't yet used for anything, but aren't usable as normal encoding space mostly because if I put instructions in there (with the existing encoding schemes), I couldn't use all the registers (and they would not have predication or similar either). Annoyingly, the only types of encodings that would fit in there at present are 2RI Imm16 ops or similar (or maybe 3R 128-bit SIMD ops, where these ops only use encodings for R0..R31 anyways, interpreting the LSB of the register field as encoding R32..R63).

Just another reason not to stay with what you have developed.
In comparison, I reserve 6-major OpCodes so that a control transfer into
data is highly likely to get Undefined OpCode exceptions rather than a
try to execute what is in that data. Then, as it is, I still have 21-slots
in the major OpCode group free (27 if you count the permanently reserved).
Much of this comes from side effects of Universal Constants.

An encoding that can MOV a 64-bit constant in 96-bits (12 bytes) and 1-cycle, is preferable....

 A consuming instruction where you don't even use a register is better
still !!

Can be done, but thus far 33-bit immediate values. Luckily, Imm33s seems to addresses around 99% of uses (for normal ALU ops and similar).

What do you do when accessing data that the linker knows is more than 4GB away from IP ?? or known to be outside of 0-4GB ?? externs, GOT, PLT, ...

Had considered allowing an Imm57s case for SIMD immediates (4x S.E5.F8 or 2x S.E8.F19), which would have indirectly allowed the Imm57s case. By themselves though, the difference doesn't seem enough to justify the cost.

While I admit that <basically> anything bigger than 50-bits will be fine
as displacements, they are not fine for constants and especially FP
constants and many bit twiddling constants.

Don't have enough bits in the encoding scheme to pull off a 3RI Imm64 in 12 bytes (and allowing a 16-byte encoding would have too steep of a cost increase to be worthwhile).

And yet I did.

So, alas...

Yes, alas..........