Re: Cost of handling misaligned access

On 2/17/2025 11:07 PM, Robert Finch wrote:

On 2025-02-17 8:00 p.m., BGB wrote:

On 2/14/2025 3:52 PM, MitchAlsup1 wrote:

On Fri, 14 Feb 2025 21:14:11 +0000, BGB wrote:
>

On 2/13/2025 1:09 PM, Marcus wrote:

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

>
The problem arises when the programmer *deliberately* does unaligned
loads and stores in order to improve performance. Or rather, if the
programmer knows that the hardware supports unaligned loads and stores,
he/she can use that to write faster code in some special cases.
>

>
Pretty much.
>
>
This is partly why I am in favor of potentially adding explicit keywords
for some of these cases, or to reiterate:
   __aligned:
     Inform compiler that a pointer is aligned.
     May use a faster version if appropriate.
       If a faster aligned-only variant exists of an instruction.
       On an otherwise unaligned-safe target.
   __unaligned: Inform compiler that an access is unaligned.
     May use a runtime call or similar if necessary,
       on an aligned-only target.
     May do nothing on an unaligned-safe target.
   None: Do whatever is the default.
     Presumably, assume aligned by default,
       unless target is known unaligned-safe.

>
It would take LESS total man-power world-wide and over-time to
simply make HW perform misaligned accesses.

>
>

 

I think the usual issue is that on low-end hardware, it is seen as "better" to skip out on misaligned access in order to save some cost in the L1 cache.
>

I always include support for unaligned accesses even with a ‘low-end’ CPU. I think it is not that expensive and sure makes some things a lot easier when handled in hardware. For Q+ it just runs two bus cycles if the data spans a cache line and pastes results together as needed.
 

I had went aligned-only with some 32-bit cores in the past.
Whole CPU core fit into less LUTs than I currently spend on just the L1 D$...
Granted, some of these used a very minimal L1 cache design:
   Only holds a single cache line.
The smallest cores I had managed had used a simplified SH-based design:
   Fixed-length 16 bit instructions, with 16 registers;
   Only (Reg) and (Reg, R0) addressing;
   Aligned only;
   No shift or multiply;
   ...
Where, say:
   SH-4 -> BJX1-32 (Added features)
   SH-4 -> B32V (Stripped down)
   BJX1-32 -> BJX1-64A (64-bit, Modal Encoding)
   B32V -> B64V (64-bit, Encoding Space Reorganizations)
   B64V ~> BJX1-64C (No longer Modal)
Where, BJX1-64C was the end of this project (before I effectively did a soft-reboot).
Then transition phase:
   B64V -> BtSR1 (Dropped to 32-bit, More Encoding Changes)
     Significant reorganization.
     Was trying to get optimize for code density closer to MSP430.
   BtSR1 -> BJX2 (Back to 64-bit, re-adding features from BJX1-64C)
     A few features added for BtSR1 were dropped again in BJX2.
The original form of BJX2 was still a primarily 16-bit ISA encoding, but at this point pretty much mutated beyond recognition (and relatively few instructions were still in the same places that they were in SH-4).
For example (original 16-bit space):
   0zzz:
     SH-4: Ld/St (Rm,R0); also 0R and 1R spaces, etc.
     BJX2: Ld/St Only (Rm) and (Rm,R0)
   1zzz:
     SH-4: Store (Rn, Disp4)
     BJX2: 2R ALU ops
   2zzz:
     SH-4: Store (@Rn, @-Rn), ALU ops
     BJX2: Branch Ops (Disp8), etc
   3zzz:
     SH-4: ALU ops
     BJX2: 0R and 1R ops
   4zzz:
     SH-4: 1R ops
     BJX2: Ld/St (SP, Disp4); MOV-CR, LEA
   5zzz:
     SH-4: Load (Rm, Disp4)
     BJX2: Load (Unsigned), ALU ops
   6zzz:
     SH-4: Load (@Rm+ and @Rm), ALU
     BJX2: FPU ops, CMP-Imm4
   7zzz:
     SH-4: ADD Imm8, Rn
     BJX2: (XGPR 32-bit Escape Block)
   8zzz:
     SH-4: Branch (Disp8)
     BJX2: Ld/St (Rm, Disp3)
   9zzz:
     SH-4: Load (PC-Rel)
     BJX2: (XGPR 32-bit Escape Block)
   Azzz:
     SH-4: BRA Disp12
     BJX2: MOV Imm12u, R0
   Bzzz:
     SH-4: BSR Disp12
     BJX2: MOV Imm12n, R0
   Czzz:
     SH-4: Some Imm8 ops
     BJX2: ADD Imm8, Rn
   Dzzz:
     SH-4: Load (PC-Rel)
     BJX2: MOV Imm8, Rn
   Ezzz:
     SH-4: MOV Imm8, Rn
     BJX2: (32-bit Escape, Predicated Ops)
   Fzzz:
     SH-4: FPU Ops
     BJX2: (32-bit Escape, Unconditional Ops)
For the 16-bit ops, SH-4 had more addressing modes than BJX2:
   SH-4: @Reg, @Rm+, @-Rn, @(Reg,R0), @(Reg,Disp4) @(PC,Disp8)
   BJX2: (Rm), (Rm,R0), (Rm,Disp3), (SP,Disp4)
Although it may seem like it, I didn't just completely start over on the layout, but rather it was sort of an "ant-hill reorganization".
Say, for example:
   1zzz and 5zzz were merged into 8zzz, reducing Disp by 1 bit
   2zzz and 3zzz was partly folded into 0zzz and 1zzz
   8zzz's contents were moved to 2zzz
   4zzz and part of 0zzz were merged into 3zzz
   ...
A few CR's are still in the same places and SR still has a similar layout I guess, ...
Early on, there was the idea that the 32-bit ops were prefix-modified versions of the 16-bit ops, but early on this symmetry broke and the 16 and 32-bit encoding spaces became independent of each other.
Though, the 32-bit F0 space still has some amount of similarity to the 16-bit space.
Later on I did some testing and performance comparisons, and realized that using 32-bit encodings primarily (or exclusively) gave significantly better performance than relying primarily or exclusively on 16-bit ops. And at this point the ISA transitioned from a primarily 16-bit ISA (with 32-bit extension ops) to a primarily 32-bit ISA with a 16-bit encoding space. This transition didn't directly effect encodings, but did effect how the ISA developed from then going forward (more so, there was no longer an idea that the 16-bit ISA would need to be able to exist standalone; but now the 32-bit ISA did need to be able to exist standalone).
But, now newer forms of BJX2 (XG2 and XG3) have become almost unrecognizable from early BJX2 (as an ISA still primarily built around 16-bit encodings).
Except that XG2's instruction layout still carries vestiges of its origins as a prefix encoding. But, XG3 even makes this part disappear (by reorganizing the bits to more closely resemble RISC-V's layout).
Well, and there is:
   ZnmX -> ZXnm
But:
   F0nm_ZeoX

I prefer my strategy instead:
   FADD/FSUB/FMUL:
     Hard-wired Round-Nearest / RNE.
     Does not modify FPU flags.
   FADDG/FSUBG/FMULG:
     Dynamic Rounding;
     May modify FPU flags.
>
Can note that RISC-V burns 3 bits for FPU instructions always encoding a rounding mode (whereas in my ISA, encoding a rounding mode other than RNE or DYN requiring a 64-bit encoding).
>
>

Q+ encodes rounding mode the same way as RISCV as there are lots of bit available in the instruction. Burning bits on the rounding mode seems reasonable to me when bits are available.
 

Initially:
   3 bits of entropy were eaten by the 16-bit space;
   2 more bits were eaten by predication and WEX.
So, the initial ISA design for 32-bit ops had 5 less bits than in RISC-V land.
XG2 reclaimed the 16-bit space, but used the bits to expand all the register fields to 6 bits.
Not many bits left to justify burning on a rounding mode.
   And, my Imm/Disp fields were generally 3 bits less than RV.

 Modified the PRED modifier in Q+ to take a predicate bit from one of three registers used to supply bits. Previously an array of two-bit mask values encoded in the instruction indicated to 1) ignore the predicate bit 2) execute if predicate true or 3) execute if predicate false.
Since there were three reg specs available in the PRED modifier, it seemed to make more sense to specify three regs instead of one. So now it works 1) as before 2) execute if bit in Ra is set, 3) execute if bit in Rb is set, 3) execute if bit in Rc is set.
The same register may be specified for Ra, Rb, and Rc. Since there is sign inversion available, the original operation may be mimicked by specifying Ra, ~Ra.
 

In BJX2, all 32-bit instructions encode predication in 2 bits in each instruction.
In XG3, the space that would have otherwise encoded WEX was instead left to RISC-V (to create a conglomerate ISA).
But, there is also the possibility to use XG3 by itself without any RISC-V parts in the mix.