floating point alignment issues with xilkernel

Hi!

I'm encountering a nasty bug when using the xilkernel with floating point.
I have an application that uses the FPU (connected via APU) to the
PPC440 (EDK 10.1 SP2). When I run the application standalone everything
works fine. However, when I use xilkernel and use my application as
starting thread execution stops after some time.

I debugged this behaviour and can see, that the CPU issues an alignment
exception all the time (remaining at the same instruction). The problem
occurs in different regions of the program, depending on the code
structure or whatever.
For instance in _vprintf_r there is an instruction(stfd = store floating
point double):

stfd f30, 1760(r1) with r1 = 0x0111ed1a

The resulting address is not aligned to an 8-byte boundary which causes
the exception. It seems that the stack for the thread is not aligned to
an 8-byte boundary. Looks like a xilkernel bug.

Has anyone ever seen the same behaviour? How can I solve this problem?

Thanks!
Matthias Alles

Hi again!

> stfd f30, 1760(r1) with r1 = 0x0111ed1a
> 
> The resulting address is not aligned to an 8-byte boundary which causes
> the exception. It seems that the stack for the thread is not aligned to
> an 8-byte boundary. Looks like a xilkernel bug.

OK, I was able to fix this issue by myself in the xilkernel. My guess
was right.
The stack for all threads is created in mem.c line 63 like this:

char thread_stack_mem[PTHREAD_STACK_MSIZE];

By replacing the line with

char thread_stack_mem[PTHREAD_STACK_MSIZE] __attribute__ ((aligned (8)));

the problems are gone. So the programmers of the xilkernel just never
thought of 64bit types that some applications might use.


Matthias

"Matthias Alles" <REMOVEallesCAPITALS@NOeit.SPAMuni-kl.de> wrote in message 
news:g6choh$qot$1@news.uni-kl.de...
> Hi again!
>
>> stfd f30, 1760(r1) with r1 = 0x0111ed1a
>>
>> The resulting address is not aligned to an 8-byte boundary which causes
>> the exception. It seems that the stack for the thread is not aligned to
>> an 8-byte boundary. Looks like a xilkernel bug.
>
> OK, I was able to fix this issue by myself in the xilkernel. My guess
> was right.
> The stack for all threads is created in mem.c line 63 like this:
>
> char thread_stack_mem[PTHREAD_STACK_MSIZE];
>
> By replacing the line with
>
> char thread_stack_mem[PTHREAD_STACK_MSIZE] __attribute__ ((aligned (8)));
>
> the problems are gone. So the programmers of the xilkernel just never
> thought of 64bit types that some applications might use.
>
>

The issue is a bit more basic -- Xilkernel does not support the APU FPU; It 
does not save/restore the floating point registers on context switches, does 
not distinguish between single precision/double precision and so on.

Unless you plan to use floating point in just a single thread, you will end 
up with a corrupted system.

Documentation is missing for this lack of support. We will get it added in.

Vasanth 

Thanks for the information. That's good to know! I didn't think about
that at all..

Are there any plans to include FPU support into xilkernel for a future
release?

Matthias



> The issue is a bit more basic -- Xilkernel does not support the APU FPU; It 
> does not save/restore the floating point registers on context switches, does 
> not distinguish between single precision/double precision and so on.
> 
> Unless you plan to use floating point in just a single thread, you will end 
> up with a corrupted system.
> 
> Documentation is missing for this lack of support. We will get it added in.
> 
> Vasanth 

"Matthias Alles" <REMOVEallesCAPITALS@NOeit.SPAMuni-kl.de> wrote in message 
news:g6rmt5$ef7$1@news.uni-kl.de...
> Thanks for the information. That's good to know! I didn't think about
> that at all..
>
> Are there any plans to include FPU support into xilkernel for a future
> release?

Yes we do plan to add the support. I don't have a hard date for it though :(