lkml.org 
[lkml]   [1997]   [Oct]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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.


\
 
 \ /
  Last update: 2005-03-22 13:40    [W:0.169 / U:0.084 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site