Re: Cost of handling misaligned access

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