On Fri, Feb 1, 2019, 11:38 AM Hesham Almatary <hesham.almat...@cl.cam.ac.uk wrote:
> On Fri, 1 Feb 2019 at 15:08, Jiri Gaisler <j...@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@rtems.org > > http://lists.rtems.org/mailman/listinfo/devel > _______________________________________________ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel