Re: My 66000 and High word facility

On 8/17/2024 3:40 PM, Brett wrote:

Thomas Koenig <tkoenig@netcologne.de> wrote:

Brett <ggtgp@yahoo.com> schrieb:

MitchAlsup1 <mitchalsup@aol.com> wrote:

>

Anytime one removes more "MOVs and saves and restore" instructions
than the called subroutine contains within the prologue and epilogue
bounds, the subroutine should be inlined.

>
In principle, yes.
>
You can either use C++ headers, which result in huge compilation
times, or you can use LTO.  LTO, if done right, is a huge time-eater
(I was looking for an English translation of "Zeitgrab", literarlly
"time grave" or "time tomb", this was the best I could come up with).
>
[...]
>

When HW is doing the saves, it does them in a known order and
can mark the registers "in use" or "busy" instantaneously and
clear that status as data arrives. When SW is doing the same,
SW ahs to wait for the instruction to arrive and then do them
one-to-small numbers at a time. HW is not so constrained.

>
Ok, so the hardware is smart enough.
But has anyone told the software guys?

>
Software guys generally work with high-level languages where this is
irrelevant, except for...
>

Of course convincing programmers to RTFM is futile. ;(

>
...people writing operating systems or drivers, and they better
read the docs for the architecture they are working on.
>

So we are back to finding any downsides for 64 registers in My 66000.

>
Encoding space.  Not sure if you have Mitch's document,

 Section 4.1 Instruction Template, Figure 25, page 33-179
 

but having
one more bit per register would reduce the 16-bit data in the
offset to 14 (no way you can expand that by a factor of four),

 14 is plenty, you can actually do 12 and pack those instructions in with
shifts which have a pair of 6 bit fields, width and offset. This would
expand some constants but you make it back in shorter code with less MOVs
and more performance.
 

FWIW, Ld/St Disp and Imm fields in BJX2 are:
   Baseline: 9-bit, Zero (Common) or One (Rare) Extended
   XG2:
     Disp9u -> Disp10s
     Imm9u -> Imm10u | Imm10s (*1)
     Imm9n -> Imm10n
*1: Most ops extend Imm9u to Imm10u, except AND and RSUB, which are Imm10s. At the time, it was because I realized I needed one-extended AND more often than I needed 10-bit AND, and there were no more Imm9 spots available at this point. RSUB just came along for the ride.
If a Jumbo-Imm (FE) prefix is used, Immed and Disp fields increase to 33-bits sign-extended.
Ironically, despite being smaller that RV imm fields, there doesn't seem to be a large difference in statistical hit-rate, and Jumbo prefixes give an advantage (a 64-bit Jumbo op being better than a 3-op LUI+ADD+OP sequence).
One minor downside is that there is not currently support for unaligned displacements, which while rare isn't strictly zero.
Though mostly unused, as typically encoded as:
   FFw0-Uvii-F0nm-0eiZ  Ld/St (Rm, Disp17s), Rn
Which encodes multiple addressing sub-modes:
   (Rm, Disp17s)        //Scaled as usual
   (Rm, Disp17s*1)      //Not yet implemented (*1)
   (Rm, Ro, Disp11u)    //Optional Extension
   (Rm, Ro*Sc, Disp9u)  //Optional Extension
     If supported: AGU adds an unscaled displacement.
     Else: Trying to use these is UB.
       At present, behaves as if Disp is always 0.
*1: I was left trying to think up a new encoding, then I noticed I had already defined this case, it is just not implemented (as a Disp5u op with V.w==1)...
And, the U field encodes:
   0=MOV, 1=XCHG, 2=ADD, 3=SUB (M-R), 4=SUB (R-M), 5=AND, 6=OR, 7=XOR
   8..F repeat, but NoCache/Volatile
     Previously: Store but Imm5, but dropped as unimplemented/unused,
     and I realized I needed Volatile more than I needed Imm5 store.
Though, not quite 1:1 with the RV64 'A' ops, as they behave more like x86 operations. Same underlying mechanism is used in both cases though.
Just the RV 'A' case performs an OpStore but with destination register as not ZZR (Zero Register).
Though, EXCH/XCHG is special, and will behave like in the 'A' extension (allowing a value in memory to be swapped with the value in the register).

would require eight instead of one major opcodes for the three-
register instructions,

 Mitch gloats about how many major opcodes he has free, in his 7 bit opcode
he has the greater part of a bit free, so we are a good part of the way
there.
 Conceptually some of the modifier bits move into the opcode space, not as
clean but you have to squeeze those bits hard. One can come up with a few
patterns that are not hard to decode, and spread across several instruction
types.
 

and the four-register instructions like FMA...

 Trying to wave a red flag in front of Mitch. ;)
 This is a pain point.
I would sacrifice most or all of XCOM6 the predicate instructions.
 Does it fit or does one look at extended opcodes for FMA.
 

FWIW: I have 4 register FMAC instructions... But:
   Only a basic 3R form can be encoded in 32-bits.
So:
     F0nm-5eoB
   FMAC Rm, Ro, Rn  //32-bit, Rn=Rn+Rm*Ro
And:
     FFw0-0vpp F0nm-5eoB
   FMAC Rm, Ro, Rp, Rn  //64-bit, Rn=Rm*Ro+Rp
   FMAS Rm, Ro, Rp, Rn  //64-bit, Rn=Rm*Ro-Rp
   FMRS Rm, Ro, Rp, Rn  //64-bit, Rn=Rp-Rm*Ro
   FMRA Rm, Ro, Rp, Rn  //64-bit, Rn=-(Rm*Ro+Rp)
Where the 'v' field encodes the sub-op (0..3).
   Possible: Consider 4..7 as PMAC.H and PMAC.F (SIMD).
     Went and now added this as part of the NNX extension.
     Though, general SIMD MAC would be fairly slow ATM (*1).
Currently not Immed forms of FMAC as this would require coming up with a new encoding scheme for them.
Most likely something like:
     FEii-iiii FFw0-0vii F0nm-5eoB
   FMAC Rm, Imm32, Ro, Rn  //64-bit, Rn=Rm*Imm+Ro
   FMAS Rm, Imm32, Ro, Rn  //64-bit, Rn=Rm*Imm-Ro
   FMRS Rm, Imm32, Ro, Rn  //64-bit, Rn=Ro-Rm*Imm
   FMRA Rm, Imm32, Ro, Rn  //64-bit, Rn=-(Rm*Imm+Ro)
With the Immed as Binary64 truncated to 32 bits.
Anything more than this would require a 128-bit encoding, but at present supporting 128-bit instruction fetch/decode isn't likely to be worth the added cost (though, could may save needing a 4th decoder by doing it in a way that would be "a bit hackish").
*1: Only real way to make SIMD MAC.H work quickly enough to be pipelined would be to do it at horrible precision.
Otherwise, routing it through the main FPU is going to make these ops take roughly 16 clock cycles (but, ironically, would be "Single Rounded" for sake of being internally performed at Double Precision...).

This would not matter if we were still living in a 36-bit world,
but the days of the IBM 704, the PDP-10 or the UNIVAC 1100 have
passed, except for emulation.
>