<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix"><br>
If in hard-float gcc is free to use fpu registers as general
pupose, if soft-float then no fp registers are used. Many
functions in newlib etc (particularly the printf family) use fp
registers, or even initialize local fp vars and so have a floating
point "presence". If you really need soft-float (eg no fpu) then
you have to build the entire toolchain; cross-compiler, newlib and
rtems all with soft-float. Essentially, its tricky to have a mix
of floating point and integer only tasks on the ppc, so its easies
to make all tasks FP or everything soft-float.<br>
<br>
Greg<br>
<br>
<br>
<br>
On 12/12/2013 10:44 AM, Kate Feng wrote:<br>
</div>
<blockquote
cite="mid:CACrq_VmyjaBL8tKtj-c=4mb5x5-htrRE5u9FyVT7xDjHsLBi_A@mail.gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<div dir="ltr">
<div>
<div>
<div>
<div>
<div>Hi Joel,<br>
<br>
</div>
I understood what you tried to point out about the
surprise from the<br>
</div>
compiler. The ISR is supposed to be written as short as
possible<br>
</div>
to the point that only a few hardware registers are needed
to be<br>
programmed. All the non-essential stuff (e.g. a = b; where
a, b are<br>
struct timespec) can be done via the rtems_event_send(),
which is<br>
implemented outside the ISR. Look at the BSP code in
GT64260eth_isr() of<br>
network/if_100MHz/GT64260eth.c and i82544EI_isr() of<br>
network/if_1GHz/if_wm.c. Did you see that any surprise
could be<br>
</div>
</div>
<div>triggered by the modern compiler ? If it does, then
either the code<br>
should be rewritten or there is a bug in the compiler.<br>
</div>
<div>BTW, which version of gcc compiler do you mean ?<br>
<br>
</div>
<div>Cheers,<br>
</div>
<div>Kate Feng<br>
</div>
</div>
<br>
</blockquote>
<br>
</body>
</html>