RISC-V double float alignment
joel at rtems.org
Fri Feb 1 19:53:30 UTC 2019
On Fri, Feb 1, 2019, 11:38 AM Hesham Almatary <hesham.almatary at cl.cam.ac.uk
> 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
> I had another a look at the RISC-V Context_Control struct. I assume this
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the devel