Re: RISC-V double float alignment

[Chris Johns]

On 5/2/19 10:56 am, Joel Sherrill wrote:
> On Mon, Feb 4, 2019 at 5:07 PM Chris Johns  > wrote:
> 
> On 2/2/19 6:53 am, Joel Sherrill wrote:
> > 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. 
> 
> Is this documented anywhere?
> 
> Unless it is in the porting guide, I doubt it. Alignment issues for critical
> structures and the stack is a porting issue.

OK.

> I was just thinking of the m68k where it allowed unaligned accesses but there
> was often a hidden performance penalty. 

Yes I was hit by this architecture. I seem to remember something changed and
alignment on the stack changed.

> It is an important issue because a performance hit such as unaligned 
> accesses
> silently happening is difficult to see and it tends to be accounted for 
> as RTEMS
> not performing or hardware not performing. Is this something we could 
> test for
> and check?
> 
> I don't know if it could be a static assertion but it could be a debug check.
> It could certainly be checked with a normal test which peeked under the hood.

I was thinking of something in the testsuite that, as you say, looks under the 
hood.

> I personally have never stopped and checked a BSP for correct alignment 
> in all
> cases or the critical cases before using and when something exposes it I 
> have
> been surprised.
> 
> Me too. We all assume that alignment was thought through by the person who 
> did the port. Similar to finding caching disabled on a BSP.
> 
> I suppose if we identify the critical structures that a test could check them 
> all.
> But we should be careful about this. What is minimum needed and what is
> for performance? 4 or 8 byte alignments would avoid faults/unaligned accesses.
> 16 or 32 byte would be performance helps on many architectures for larger
> structures.

I do not know.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RISC-V double float alignment

[Joel Sherrill]

On Mon, Feb 4, 2019 at 5:07 PM Chris Johns  wrote:

> On 2/2/19 6:53 am, Joel Sherrill wrote:
> > 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.
>
> Is this documented anywhere?
>

Unless it is in the porting guide, I doubt it. Alignment issues for
critical structures
and the stack is a porting issue.

I was just thinking of the m68k where it allowed unaligned accesses but
there
was often a hidden performance penalty.

>
> It is an important issue because a performance hit such as unaligned
> accesses
> silently happening is difficult to see and it tends to be accounted for as
> RTEMS
> not performing or hardware not performing. Is this something we could test
> for
> and check?
>

I don't know if it could be a static assertion but it could be a debug
check.
It could certainly be checked with a normal test which peeked under the
hood.

>
> I personally have never stopped and checked a BSP for correct alignment in
> all
> cases or the critical cases before using and when something exposes it I
> have
> been surprised.
>

Me too. We all assume that alignment was thought through by the person who
did the port. Similar to finding caching disabled on a BSP.

I suppose if we identify the critical structures that a test could check
them all.
But we should be careful about this. What is minimum needed and what is
for performance? 4 or 8 byte alignments would avoid faults/unaligned
accesses.
16 or 32 byte would be performance helps on many architectures for larger
structures.

--joel


>
> Chris
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RISC-V double float alignment

[Chris Johns]

On 2/2/19 6:53 am, Joel Sherrill wrote:
> 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. 

Is this documented anywhere?

It is an important issue because a performance hit such as unaligned accesses
silently happening is difficult to see and it tends to be accounted for as RTEMS
not performing or hardware not performing. Is this something we could test for
and check?

I personally have never stopped and checked a BSP for correct alignment in all
cases or the critical cases before using and when something exposes it I have
been surprised.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RISC-V double float alignment

[Jiri Gaisler]

On 2/2/19 11:07 AM, Sebastian Huber wrote:
> Hello,
>
> yes, we should avoid misaligned access in RTEMS. Does this commit fix your 
> problem?
>
> https://git.rtems.org/rtems/commit/?id=9399473cb83985fd222e299e4581a232f5d35028

Yes, this is exactly the patch I was about to post myself! Thanks..!

To clarify for others: the unaligned problem was in context validate,
not context save/restore.


___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RISC-V double float alignment

[Sebastian Huber]

Hello,

yes, we should avoid misaligned access in RTEMS. Does this commit fix your 
problem?

https://git.rtems.org/rtems/commit/?id=9399473cb83985fd222e299e4581a232f5d35028
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: 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  wrote:
>
>
> On 2/1/19 5:37 PM, Hesham Almatary wrote:
> > On Fri, 1 Feb 2019 at 15:08, Jiri Gaisler  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

Re: RISC-V double float alignment

[Jiri Gaisler]

On 2/1/19 5:37 PM, Hesham Almatary wrote:
> On Fri, 1 Feb 2019 at 15:08, Jiri Gaisler  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

Re: RISC-V double float alignment

[Joel Sherrill]

On Fri, Feb 1, 2019, 11:38 AM Hesham Almatary  On Fri, 1 Feb 2019 at 15:08, Jiri Gaisler  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

Re: RISC-V double float alignment

[Hesham Almatary]

On Fri, 1 Feb 2019 at 15:08, Jiri Gaisler  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?

> 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

Re: RISC-V double float alignment

[emanuel stiebler]

On 2019-02-01 10:08, Jiri Gaisler wrote:
> Hello,
> 
> As far as I understand, RISC-V does not require any particular alignment
> of data structures in memory. [ ... ]

RISC-V explicitly states somewhere in the manuals, (?) that it supports
unaligned access to memory, but it could be emulated in software, and
accesses should/will be fastest on aligned addresses 

Actually, writing it I found it on wiki & the manual
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RISC-V double float alignment

[Jiri Gaisler]

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?

Jiri.

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel