On 2/1/19 5:37 PM, Hesham Almatary 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. > > 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. _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
