RISC-V double float alignment

[Hesham Almatary]

I agree with Joel we shouldn't take unaligned accesses.

A solution is to add an "unaligned support" configuration option to
each RISC-V BSP (similar to HTIF).
Then in the CPU_Control struct [1] we add a dummy uint32_t
align_padding variable.

[1] https://github.com/RTEMS/rtems/blob/master/cpukit/score/cpu/riscv/include/rtems/score/cpu.h#L109

On Sat, 2 Feb 2019 at 08:10, Jiri Gaisler <jiri at gaisler.se> wrote:
>
>
> On 2/1/19 5:37 PM, Hesham Almatary wrote:
> > On Fri, 1 Feb 2019 at 15:08, Jiri Gaisler <jiri at gaisler.se> wrote:
> >> Hello,
> >>
> >> As far as I understand, RISC-V does not require any particular alignment
> >> of data structures in memory. Nevertheless, the compiler automatically
> >> aligns data structures on their natural sizes, i.e. ints are aligned on
> >> 4-byte and doubles on 8-bytes boundaries. sis-riscv with support for
> >> doubles (extension D) checks that load and store double are properly
> >> aligned on 8-byte boundaries. This works fine for all compiler-generated
> >> code, (e.g. paranoia) but fails for spcontext01, where the context save
> >> function in riscv-exception-handler.S tries to save 64-bit floating
> >> point registers on a non-aligned stack address.
> >>
> >> Is this an oversight in the code, or does the hardware (and simulators)
> >> have to support unaligned accesses?
> >>
> > Spike can be built to support either aligned or unaligned accesses. This
> > includes floating points and integers. It's not in the spec that a RISC-V
> > implementation has to support it or not (it's up to the platform),
> > but if it doesn't, it should trigger an unaligned access trap and
> > should be handled.
> >
> > That said, I am not sure whether the intention of the RISC-V FPU
> > implementation in RTEMS is assuming everything will be aligned
> > (in which case some alignment checks should be added) or not.
> >
> > I had another a look at the RISC-V Context_Control struct. I assume this only
> > happens on rv32 with D extension?
>
> Yes, I have just added support for the D extension to sis and I am
> testing it against the test suite. It only happens when I compile with
> rv32imafd, and saving the FPU context. If I remove the alignment checks
> in sis, spcontext01 runs fine. My hardware however does not support
> unaligned accesses so I see the error there. The stack pointer is
> properly aligned on a 16-byte boundary when the error occurs, so it
> seems to be an issue with the layout of the FPU context. I will try to
> fix it by modifying the context layout ...
>
> Jiri.
>
>