On 25/01/17 17:24, Joel Sherrill wrote:
I had another thought that we need to be sure that the
reason for adjusting the starting FP context pointer
to not be the base address of the FP context area
should be clear.
For architectures where you are just linearly saving the FPU
registers, it is just a normal structure.
For architectures like the m68k where the FPU state is saved
as a stack which grows down, the adjustment should have
a comment to explain it. Even if it is done inline in the
context initialization.
Thanks for the review. I added a comment for m68k:
/*
* The floating-point context is saved/restored via FSAVE/FRESTORE
which
* use a growing down stack. Initialize the stack and adjust the
FP area
* pointer accordingly.
*/
#define _CPU_Context_Initialize_fp( _fp_area ) \
{ \
uint32_t *_fp_context = _Addresses_Add_offset( \
*(_fp_area), CPU_CONTEXT_FP_SIZE - 4); \
*(--(_fp_context)) = 0; \
*(_fp_area) = (void *)(_fp_context); \
}
It is the only architecture supported by RTEMS that uses this model.
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
