Messages in this thread | | | Date | Thu, 16 Oct 1997 10:23:01 -0600 (MDT) | From | teunis <> | Subject | Re: ntohl and others |
| |
On Thu, 16 Oct 1997, Magnus Ahltorp wrote:
> > > (1) As macros, they *are* inline, just not functions. > > With a function, type checking and type conversion is performed upon entry. > Of course you can perform type conversion in a macro, but type checking?
Massive latency on a function call. But I work in VR (endianness can vary from graphic-mode to graphic-mode... and can vary bit-endianness as well as byte-endianness...) I discovered there that macros were the most efficient way to go - just write multiple translation functions if you need them.
These macros are needed in the networking layer where they'd hurt network speed if they became a function.
GCC isn't all that good at converting functions to inline code....
> > (2) Your desired usage would require a non-inlined instance of the > > "inline" function to point to. > > Yes, but only then. All instances not requiring a address to htonl will > be inlined.
Doesn't work that way. You either always have the address or you don't.
> > (3) Why on earth do you want the address of ntohl? It's not like > > you need to change endianness at runtime... > > No, but maybe the choice of converting or not converting. Imagine a > function making a data structure for host or network use. When asked for > a host order data structure, a parameter can be passed to the function > that does that conversion (nothing), and when a network order structure > is wanted, htonl can be passed.
So write a wrapper!
> This is just an example I just made up, but why should the kernel's > include files tell people what to code?
They don't - but they tell how and what to code if you want code merged with the kernel! (otherwise - go pester the glibc-people about this.)
Apparently user-programs should _NEVER_ go near kernel source or includes.
> > This code is a toy example of using a function pointer, yet tells us > > nothing about *why* you want to do so...and I really think you don't. > > What context are you working in, and what other function(s) might you > > point to besides htonl? > > This is not a thing I'm working on, I just found out the inconsistency > between little endian and big endian implementations of ntohl and the > other functions.
What inconsistancy? And ever worked with a processor that can change endian-ness on-the-fly? (PowerPC, MIPS) I haven't - but graphic systems do this.
> Imagine a programmer working on an Intel or Alpha platform. He codes the > function I suggested above, and everything works, since ntohl is a > function. Then, someone tries to compile his code on a Sparc. This > doesn't work very well, since ntohl is a macro.
then don't do that then. Or write a wrapper that'll work in both situations.
> > See (4) above. Note that the function ought not to be declared static > > if there's any possibility of multiple places forcing the compiler to > > make an out-of-line copy of the htonl function...(prototype in the > > header, actual definition in one place only) > > If the function is not declared static, it will be exported, and since > many .c files will certainly include this .h file, multiple definitions > will give error messages at link time.
"extern inline " <function>. Solves that handily. Gives you an address too. But it has the overhead of a function call.
> Well, why bother, when you can make ugly solutions and get away with it?
That's my point :)
(if this call - or any other really-lowlevel call in the networking layer - became a function the cost would be ... high. Instead of 100K packets/second you might drop the bandwidth down to 25-50K packets/second. Or even worse it might drop <10K packets/sec) CPU caching isn't fond of function calls.
(one of my rendering calls went from 100K calls/second to 10K calls/second because one of the internals was converted to a function...)
Mind you, I didn't notice a speed drop when I converted it into an inline function... which is more-or-less the same as a macro. unless I tried to get the address of the "inline". You can't IIRC.
G'day, eh? :) - Teunis
An end to this please? There's no need. Just go with how things are in this case - Linux isn't the only platform to use macros here.
| |