Re: Cost of handling misaligned access

On Tue, 18 Feb 2025 1:00:18 +0000, BGB wrote:

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

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

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.
>
Though, not sure how this mixes with 16/32 ISAs, given if one allows
misaligned 32-bit instructions, and a misaligned 32-bit instruction to
cross a cache-line boundary, one still has to deal with essentially the
same issues.

Strategy for low end processors::
a) detect misalignment in AGEN
b) when misaligned, AGEN takes 2 cycles for the two addresses
c) when misaligned, DC is accessed twice
d) When misaligned, LD align is performed twice to merge data

Another related thing I can note is internal store-forwarding within the
L1 D$ to avoid RAW and WAW penalties for multiple accesses to the same
cache line.

IMHO:: Low end processors should not be doing ST->LD forwarding.
---------------------

>
Say, it less convoluted to do, say:
   MOV.X  R24, (SP, 0)
   MOV.X  R26, (SP, 16)
   MOV.X  R28, (SP, 32)
   MOV.X  R30, (SP, 48)

These still look like LDs to me.
-----------------

Then again, I have heard that apparently there are libraries that rely
on the global-rounding-mode behavior, but I have also heard of such
libraries having issues or non-determinism when mixed with other
libraries which try to set a custom rounding mode when these modes
disagree.
>
>
I prefer my strategy instead:
   FADD/FSUB/FMUL:
     Hard-wired Round-Nearest / RNE.
     Does not modify FPU flags.

It takes Round Nearest Odd to perform Kahan-Babashuka Summation.
That is:: comply with IEEE 754-2019

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

Oh what fun, another RISC-V encoding mistake...