M68k/ColdFire: FPU context initialization

[Brett Swimley]

Sounds great.  Will this be dropped into CVS?

I would probably pick up your integration in lieu of my own just to keep 
things consistent.

Brett

Thomas Doerfler (nt) wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi Brett,
>
> thank you for the offer. But now we almost have a/the solution for the
> FP context save/restore, so actually we would like to integrate our
> solution.
>
> We just want to make sure that we initialize things properly, that's why
> I started this thread.
>
> wkr,
> Thomas.
>
>
> Brett Swimley schrieb:
>   
>> It is a bit different.
>>
>> I have a patch that saves and restores the FP context for the MCFv4e
>> that I keep meaning to submit (based on the -mcfv4e compiler option
>> found in the newer gcc compilers).  I will try to put that together. 
>>
>> I will look at the FPU control register initialization.  I don't know if
>> I did that.
>>
>> On this topic, would it be possible to add the mcfv4e variant to the
>> list of m68k targets (t-rtems) and include this in the pre-built RPMs? 
>> I added this variant to my version of the compiler, but I don't know if
>> I got all the soft-float stuff correct.
>>
>> Brett
>>
>> Joel Sherrill wrote:
>>
>>     
>>> Thomas Doerfler wrote:
>>>  
>>>
>>>       
>>>> Hi,
>>>>
>>>> we are currently adding FPU support for a ColdFire v4e CPU derivate.
>>>> After reading, re-reading (and reading again) the relevant files in
>>>> cpukit/score/cpu/m68k in the current M68K (with hardware FPU, e.g.
>>>> MC68040) CPU Context management, I have not found, where/how the FPU
>>>> context is initialized for a newly created thread.
>>>>
>>>> Can somebody please guide me:
>>>>
>>>> - Is the FPU context in an arbitrary state when a new thread is started?
>>>>  
>>>>    
>>>>
>>>>         
>>> If the thread is not an FP task, you would prefer to disable the FPU.
>>> If it is FP enabled, then all that you have to initialize is usually
>>> the control registers.
>>>  
>>>
>>>       
>>>> - Or: Where is the code which defines the initial state of the FPU in a
>>>> new thred?
>>>>  
>>>>    
>>>>
>>>>         
>>> score/cpu/m68k/rtems/score/cpu.h and score/cpu/m68k/cpu_asm.S
>>>
>>> Is the Coldfire FPU similar to the 68881 or is it more RISC like?
>>> Do you have the same type of fsave/restore instructions?
>>>  
>>>
>>>       
>>>> Any hint appreciated,
>>>>
>>>> Thomas Dörfler.
>>>>
>>>>
>>>>
>>>>  
>>>>    
>>>>
>>>>         
>>> _______________________________________________
>>> rtems-users mailing list
>>> rtems-users at rtems.com
>>> http://rtems.rtems.org/mailman/listinfo/rtems-users
>>>  
>>>
>>>       
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> rtems-users mailing list
>> rtems-users at rtems.com
>> http://rtems.rtems.org/mailman/listinfo/rtems-users
>>     
>
>
> - --
> - --------------------------------------------
> IMD Ingenieurbuero fuer Microcomputertechnik
> Thomas Doerfler           Herbststrasse 8
> D-82178 Puchheim          Germany
> email:    Thomas.Doerfler at imd-systems.de
> PGP public key available at:
>      http://www.imd-systems.de/pgpkey_en.html
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.5 (MingW32)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>
> iD8DBQFHL3akwHyg4bDtfjQRAqJJAJ4+SUFJPSrG3GAVHtIdlE1zWH/bCQCgmF8V
> zQqm+lVO0MRjMxHfZfZSAvY=
> =n06s
> -----END PGP SIGNATURE-----
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20071105/4044a144/attachment-0001.html>