httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <dgau...@arctic.org>
Subject Re: [PATCH] PR#344: 64-bit cleanups
Date Sun, 20 Apr 1997 02:10:58 GMT
On Sat, 19 Apr 1997, Rodent of Unusual Size wrote:
>     BTW, Dean, there are other 64-bit implementations than Alpha.  Is
>     Alpha/OSF the only one that has the sizeof(int) issue?  If not, I
>     dunno about the special-casing in the revised patch..

Oh I know this, however for some reason the folks here are against
autoconf-style configuration (flame bait).  Unfortunately it's not easy
to test for all the 64-bit architectures with the preprocessor alone.

[skip the rest if you get bored when I mumble about compilers]

The most portable way to clean this up without some preknowledge of the
architecture is to pass around a pointer to the integer rather than the
integer itself.  However that has a speed penalty (palloc the integer)
that I'm not really interested in suffering.

A somewhat less portable (breaks on some non-ANSI compilers) but usually
better performance solution is to use:

    typedef union {
	int i;
	void *v;
    } ptr_or_int;

And then pass around ptr_or_int values assuming that there is some
implicit method for your routines to know which to use.  Then at
least some sane-ABIs allow the compiler to pass things around cheaply.
The x86 ABI for example would push a ptr_or_int parameter direct onto
the callee's argument stack (because it fits into a register).  But the
ultrasparc ABI requires that the caller allocate some stack space for
the parameter, and pass a pointer to the stack space instead.  For example:

    void blue (ptr_or_int x);

Under x86 it would be implemented pretty much the same way that:

    void blue_good (int x);

would be.  But on ultrasparc it is implemented this way:

    void blue_bad (ptr_or_int *copy_of_x);

and the caller allocates some temp storage for x for the duration of
the call.

Even if the ABI passes ptr_to_int cheap as parameters doesn't mean it'll let
them come back cheap as return values.  For example, in the x86 ABI
the function foo:

    ptr_or_int red( int param );

is implemented as:

    void red( ptr_or_int *__return_value, int param );

behind the scenes.

And finally we could just have two of every routine that deals with this
void * vs. int crap, one for void * and one for int.  So we would have
register_cleanup_ptr, and register_cleanup_int.  Bleh.

So ... I give up, I don't see a clean way to do this without some
preknowledge or sacrificing performance.

Dean

P.S. Yeah I do worry about the few cycles...


Mime
View raw message