Re: NetBSD on SH-4A

Valeriy E. Ushakov wrote:
> On Mon, Jun 15, 2009 at 15:18:01 -0700, David S. Alessio wrote:
>
>   
>> I'd like to see the SH-4A fully supported.  Any suggestions on the best 
>> path to get there?
>>
>> The approach that first comes to my mind is:
>> 1)   Add kernel support for the FPU to the SH-4 arch
>>    Has anyone examined this?  If so, any thoughts/suggestions on the 
>> "right way" to do it?
>>    I'd like to see a lazy FPU context switch.
>>     
>
> Look at how other arches do it and do the same for SH-4 FPU.  FPU
> autodetection would be nice, but compile-time kernel option could do
> for now.  Shouldn't be hard, but I never got around to it as real life
> keep interfering.  If you could work on it and contribute the code
> back, that would be very helpful 
>   
How would autodetection be helpful for SH-4 and SH-4A?  I don't think 
we'll see many [any] SH-4A-DSP chips; and all SH-4/4A have an FPU.


> (we don't have much NetBSD/sh3
> developers).
>
>   
Well, you've got one more now ;)
>> 2)  Recompile the SH-4 world with FPU support
>>    (gcc default integer division should not use the FPU)
>>     
>
> Not sure it's possible without hacking gcc as with -m4 it generates
> calls to __sdivsi3_i4 and expects its result in FPUL.
>   
gcc has an SH-specific option  "-mdiv=STRATEGY" where STRATEGY is a menu 
of division options.  I believe gcc-4.3.3 by default uses "-mdiv=call" 
which implements the inv.minlat strategy (integer division instructions).

Which begs the questions:  When will NetBSD/ports support gcc-4.3.3?  Is 
there anything standing in the way of updating to 4.3.3 as the default 
gcc version?

> Why is this particular requirement?
>   
A few reasons:
    o    any integer division in kernel code should use DIV0, DIV1 
instructions (not the FPU).
    o   Using the FPU for integer division results in a slight win at a 
micro-benchmark level, but results in a net loss at the macro-benchmark 
level.  If we assume several applications running, every thread 
performing at least one integer division per time slot, then every 
thread will dirty the FPU and trigger an FPU context save.  This is 
expensive.  Doubly expensive if we use lazy FPU context save -- we'd get 
hit with an FPU exception on just about every context switch
    o   most apps/threads don't use float/double vars and would not need 
the FPU

-david

begin:vcard
fn:David S. Alessio
n:Alessio;David S.
org:Systemic Realtime Design, LLC.
adr:;;201 San Antonio Circle, Suite 145;Mountain View;CA;94040;USA
email;internet:[email protected]
title:CTO
tel;work:+1-650-559-8222
tel;fax:+1-650-204-6968
tel;cell:+1-650-248-8867
x-mozilla-html:TRUE
url:www.SysRealTime.com
version:2.1
end:vcard