RISC-V ASM unaligned read/writes: alternative assembly

[SparkiDev]

Description

Not all RISC-V chips allow unaligned reads and writes with basic assembly instructions like lw/sw.
Add alternative assembly that is turned on with:
WOLFSSL_RISCV_ASM_NO_UNALIGNED.

Fixes #10525

Testing

./configure --disable-shared LDFLAGS=--static --host=riscv64 CC=riscv64-linux-gnu-gcc --enable-riscv-asm CFLAGS=-DWOLFSSL_RISCV_ASM_NO_UNALIGNED

[SparkiDev]

Jenkins: retest this please

[EAlexJ]

I would like to push back on this implementation a bit.

Currently, all instructions that could be unaligned get emulated.

I think it makes sense to check if the pointers are actually unaligned and only then use the more costly emulation.
I suggest something like this (with the check guarded behind WOLFSSL_RISCV_ASM_NO_UNALIGNED):

Sha512Transform(wc_Sha512* sha512, const byte* data,
    word32 blocks)
{
if((uintptr_t) data % 8) // modulo 8 as the routine uses UNALIGNED_[LS]D
    <emulate using the UNALIGNED_* macro>
else
    <normal execution>
}

There should only be a negligible impact on performance in case the data is aligned. This also only introduces a small size overhead, the check should be a few instructions at most.

[EAlexJ]

On a separate issue: In my opinion readability would be increased if you just used the UNALIGNED_* Macro unconditionally and only check once in the actual definition of the macro if WOLFSSL_RISCV_ASM_NO_UNALIGNED is defined and then emit the emulation.
This is then similar to how REV8 and others are handled. It would then also make sense to name the macro differently.

EDIT: This is probably obsolete in case the suggestion above gets adopted

[SparkiDev]

I've modified the macros to check the alignment and choose the sequence to use.
Let me know if that is better.

Thanks,
Sean

[EAlexJ]

I see the following pattern several times:

addi    t, p, o          
andi    t, t, <alignment mask>           
bnez    t, <label>
----
t: scratch register
p: register holding the base address
o: offset

This checks the alignment of p+o, but since o is always a valid offset (is it not?) it is sufficient to check p only.
One instruction can then be saved by doing:

andi    t, p, <alignment mask>           
bnez    t, <label>

[EAlexJ]

One issue I see is that there is a lot of double checking for alignments:
The bulk variants call the underlying N times, but since the check for the alignment is done in the underlying only, it also gets checked N times.

In case the data is actually aligned there should only be one check.

I'd argue that most of the time the data is (or at the very least should be) aligned, so I'd try to keep the overhead for this case as small as possible.

If the data is unaligned, performance will take a hit even on hardware that supports misaligned loads and stores, e.g. when accesses cross cache-line boundaries.

[SparkiDev]

Made it that it will do many at once after the check to reduce the overhead.
Will test for largest alignment first and use the smallest number of instructions.