RISC-V double float alignment

[Joel Sherrill]

On Fri, Feb 1, 2019, 11:38 AM Hesham Almatary <hesham.almatary at cl.cam.ac.uk
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.
>

Then we should ensure proper alignment since we NEVER want an unaligned
exception on any architecture if it is avoidable. No point in taking the
likely performance hit or exception.

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

The intention is to avoid unaligned exceptions so this has to be accounted
for.

>
> I had another a look at the RISC-V Context_Control struct. I assume this
> only
> happens on rv32 with D extension?
>
> > Jiri.
> >
> > _______________________________________________
> > devel mailing list
> > devel at rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20190201/a0a98290/attachment.html>