* arm fenv support - static inline of methods
@ 2020-05-13 14:11 Joel Sherrill
2020-05-13 18:17 ` Brian Inglis
0 siblings, 1 reply; 6+ messages in thread
From: Joel Sherrill @ 2020-05-13 14:11 UTC (permalink / raw)
To: Newlib, Eshan Dhawan
Hi
Eshan Dhawan is an RTEMS GSoC 2020 student working on adding more POSIX
methods to RTEMS and newlib if appropriate. He is currently looking at
adding more
fenv.h implementations.
The FreeBSD implementation of arm fenv.h has static inlines for all the
methods in sys/fenv.h. Is this OK? Or should they be turned into real
bodies in a C file?
--joel
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: arm fenv support - static inline of methods
2020-05-13 14:11 arm fenv support - static inline of methods Joel Sherrill
@ 2020-05-13 18:17 ` Brian Inglis
2020-05-13 18:22 ` Joel Sherrill
2020-05-13 21:03 ` Richard Damon
0 siblings, 2 replies; 6+ messages in thread
From: Brian Inglis @ 2020-05-13 18:17 UTC (permalink / raw)
To: newlib
On 2020-05-13 08:11, Joel Sherrill wrote:
> Eshan Dhawan is an RTEMS GSoC 2020 student working on adding more POSIX
> methods to RTEMS and newlib if appropriate. He is currently looking at
> adding more
> fenv.h implementations.
>
> The FreeBSD implementation of arm fenv.h has static inlines for all the
> methods in sys/fenv.h. Is this OK? Or should they be turned into real
> bodies in a C file?
Don't all functions need to be provided as linkable implementations for cases
where they are invoked using their address directly or indirectly, unless the
standards agree they don't need to be?
--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in IEC units and prefixes, physical quantities in SI.]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: arm fenv support - static inline of methods
2020-05-13 18:17 ` Brian Inglis
@ 2020-05-13 18:22 ` Joel Sherrill
2020-05-13 18:36 ` Brian Inglis
2020-05-13 21:03 ` Richard Damon
1 sibling, 1 reply; 6+ messages in thread
From: Joel Sherrill @ 2020-05-13 18:22 UTC (permalink / raw)
To: Newlib
On Wed, May 13, 2020 at 1:17 PM Brian Inglis <
Brian.Inglis@systematicsw.ab.ca> wrote:
> On 2020-05-13 08:11, Joel Sherrill wrote:
>
> > Eshan Dhawan is an RTEMS GSoC 2020 student working on adding more POSIX
> > methods to RTEMS and newlib if appropriate. He is currently looking at
> > adding more
> > fenv.h implementations.
> >
> > The FreeBSD implementation of arm fenv.h has static inlines for all the
> > methods in sys/fenv.h. Is this OK? Or should they be turned into real
> > bodies in a C file?
>
> Don't all functions need to be provided as linkable implementations for
> cases
> where they are invoked using their address directly or indirectly, unless
> the
> standards agree they don't need to be?
>
That's what I think also but that's not how FreeBSD has implemented it.
IMO the static inline implementations from them need to move to .c files.
--joel
>
> --
> Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
>
> This email may be disturbing to some readers as it contains
> too much technical detail. Reader discretion is advised.
> [Data in IEC units and prefixes, physical quantities in SI.]
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: arm fenv support - static inline of methods
2020-05-13 18:22 ` Joel Sherrill
@ 2020-05-13 18:36 ` Brian Inglis
2020-05-13 19:14 ` Joel Sherrill
0 siblings, 1 reply; 6+ messages in thread
From: Brian Inglis @ 2020-05-13 18:36 UTC (permalink / raw)
To: newlib
On 2020-05-13 12:22, Joel Sherrill wrote:
> On Wed, May 13, 2020 at 1:17 PM, Brian Inglis wrote:
>> On 2020-05-13 08:11, Joel Sherrill wrote:
>>> Eshan Dhawan is an RTEMS GSoC 2020 student working on adding more POSIX
>>> methods to RTEMS and newlib if appropriate. He is currently looking at
>>> adding more
>>> fenv.h implementations.
>>>
>>> The FreeBSD implementation of arm fenv.h has static inlines for all the
>>> methods in sys/fenv.h. Is this OK? Or should they be turned into real
>>> bodies in a C file?
>> Don't all functions need to be provided as linkable implementations for
>> cases where they are invoked using their address directly or indirectly,
>> unless the standards agree they don't need to be?
> That's what I think also but that's not how FreeBSD has implemented it.
> IMO the static inline implementations from them need to move to .c files.
I'm pretty sure I've seen somewhere in the sources, that the library has a
standard approach for doing this, as most libraries do for such common cases.
--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in IEC units and prefixes, physical quantities in SI.]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: arm fenv support - static inline of methods
2020-05-13 18:36 ` Brian Inglis
@ 2020-05-13 19:14 ` Joel Sherrill
0 siblings, 0 replies; 6+ messages in thread
From: Joel Sherrill @ 2020-05-13 19:14 UTC (permalink / raw)
To: Newlib
On Wed, May 13, 2020 at 1:36 PM Brian Inglis <
Brian.Inglis@systematicsw.ab.ca> wrote:
>
> On 2020-05-13 12:22, Joel Sherrill wrote:
> > On Wed, May 13, 2020 at 1:17 PM, Brian Inglis wrote:
> >> On 2020-05-13 08:11, Joel Sherrill wrote:
>
> >>> Eshan Dhawan is an RTEMS GSoC 2020 student working on adding more POSIX
> >>> methods to RTEMS and newlib if appropriate. He is currently looking at
> >>> adding more
> >>> fenv.h implementations.
> >>>
> >>> The FreeBSD implementation of arm fenv.h has static inlines for all the
> >>> methods in sys/fenv.h. Is this OK? Or should they be turned into real
> >>> bodies in a C file?
>
> >> Don't all functions need to be provided as linkable implementations for
> >> cases where they are invoked using their address directly or indirectly,
> >> unless the standards agree they don't need to be?
>
> > That's what I think also but that's not how FreeBSD has implemented it.
> > IMO the static inline implementations from them need to move to .c files.
>
> I'm pretty sure I've seen somewhere in the sources, that the library has a
> standard approach for doing this, as most libraries do for such common
> cases.
>
Thanks for saying that. It just occurred triggered me to realize that this
in the
header file:
#ifndef __fenv_static
#define __fenv_static static
#endif
All we need is an arm fenv.c which does this
#define __fenv_static
#include <fenv.h>
Then magically, we have methods (I think).
And empty files for every fenv source file named for a method since
all the methods are in one file.
Thank you. I think that's enough to let me help Eshan through this.
--joel
--
> Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
>
> This email may be disturbing to some readers as it contains
> too much technical detail. Reader discretion is advised.
> [Data in IEC units and prefixes, physical quantities in SI.]
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: arm fenv support - static inline of methods
2020-05-13 18:17 ` Brian Inglis
2020-05-13 18:22 ` Joel Sherrill
@ 2020-05-13 21:03 ` Richard Damon
1 sibling, 0 replies; 6+ messages in thread
From: Richard Damon @ 2020-05-13 21:03 UTC (permalink / raw)
To: newlib
On 5/13/20 2:17 PM, Brian Inglis wrote:
> On 2020-05-13 08:11, Joel Sherrill wrote:
>
>> Eshan Dhawan is an RTEMS GSoC 2020 student working on adding more POSIX
>> methods to RTEMS and newlib if appropriate. He is currently looking at
>> adding more
>> fenv.h implementations.
>>
>> The FreeBSD implementation of arm fenv.h has static inlines for all the
>> methods in sys/fenv.h. Is this OK? Or should they be turned into real
>> bodies in a C file?
> Don't all functions need to be provided as linkable implementations for cases
> where they are invoked using their address directly or indirectly, unless the
> standards agree they don't need to be?
>
But you CAN take the address of a static inline function, and then call
through that address. Taking the address will force the compiler to
generate an out of line copy to take the address of it. What this
doesn't allow is manually providing a prototype per the standard and
calling it, but I am not sure that is officially required to be
supported in the standard.
--
Richard Damon
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2020-05-13 21:03 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-05-13 14:11 arm fenv support - static inline of methods Joel Sherrill
2020-05-13 18:17 ` Brian Inglis
2020-05-13 18:22 ` Joel Sherrill
2020-05-13 18:36 ` Brian Inglis
2020-05-13 19:14 ` Joel Sherrill
2020-05-13 21:03 ` Richard Damon
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).