On 01 May 2006 20:55, DJ Delorie wrote:
> At this point, I would like some feedback about the API and how to
> cleanly (namespace-wise) add it to libgcc.a.
Um, I know it's a bit bikeshedcolour, and sorry about that, but wouldn't a
target-dependent builtin be a better fit to this kind of problem? A
subroutine call just to fetch/modify a cpu register seems a bit heavy. Maybe
at -Os, given that this is an embedded target, but even so.
Otherwise this sort of thing should live in the main C lib, the way
fpu_control.h and feset/getround/etc. do, shouldn't it?
> #define FR 0x00200000
> #define SZ 0x00100000
> #define PR 0x00080000
> #define DN 0x00040000
> #define RN 0x00000003
> #define RN_N 0
> #define RN_Z 1
A name like 'SZ' is highly likely to collide with a lot of applications if
its in the same namespace, isn't it?
> extern int __fpscr_values[2];
> void
> change_fpscr(int off, int on)
> {
> int b = get_fpscr();
> off = ~off;
> off |= 0x00180000;
> on &= ~ 0x00180000;
:) Shouldn't that be (SZ | PR) since you went to the effort of defining
them anyway?
> b &= off;
> b |= on;
> put_fpscr(b);
See, this is all nice simple stuff that would optimise beautifully if it was
emitted as inline rtl.
> __fpscr_values[0] &= off;
> __fpscr_values[0] |= on;
> __fpscr_values[1] &= off;
> __fpscr_values[1] |= on;
Ok, I'll bite. Why are there two of them?!
cheers,
DaveK
--
Can't think of a witty .sigline today....
