[Freeciv-Dev] Re: (PR#7279) Macro optimizations

["Arnstein Lindgard" <a-l@xxxxxxx>]

<URL: http://rt.freeciv.org/Ticket/Display.html?id=7279 >

On Tue, 20 Jan 2004 17:44:09 -0800 rwetmore@xxxxxxxxxxxx wrote:

> Use of alloca() to create temporary stack space is a potential
> compatibility issue, but can be removed by making preallocation
> of local storage in env a requirement or part of the definition
> macro rather than option.
> [...]
> #define macfn(env, arg1, arg2)              \
> ( (env || (env = alloca(sizeof(MACENV)))),  \
>    env->arg1 = (arg1),                       \
>    env->arg2 = (arg2),                       \
>    //  ... functional code goes here         \
>    //  ... e.g.  return (arg1 + arg2) ** 2;  \
>    env->temp = env->arg1 + env->arg2,        \
>    env->temp *= env->temp                    \
> )

Assuming we need local variables:

My linux man pages says alloca() is non POSIX and it's use is
discouraged. Some existing Freeciv code (which looks imported)
substitutes alloca() with malloc() if you don't have a requirement,
and that introduces overhead for one function call in your macro.

I suppose we could write:

typedef struct macenv {
   int  arg1;
   int  arg2;
   int  temp;
} MACENV_T;

#define MACENV(env)     MACENV_T *env

#define macfn(ENV, ARG1, ARG2)                  \
(  (ENV)->arg1 = (ARG1),                        \
   (ENV)->arg2 = (ARG2),                        \
   (ENV)->temp = (ENV)->arg1 + (ENV)->arg2,     \
   (ENV)->temp *= (ENV)->temp                   \
)

void userfn()
{
   MACENV(my_env);
   int val = macfn(my_env, 1, 2);
}

Either way, I understand we'd have to add a "MACENV(my_env);" line to
every function that uses the macro, to ensure the optimization we
may not neccessarily get with inlining. And we have to add the "my_env"
argument to all the macro functions?

bool normalize_map_pos(int *x, int *y)    would become
normalize_map_pos(ENV, X, Y)

So would further macro definitions be required to avoid this becoming
a white elephant?

What about type checking?

On Tue, 20 Jan 2004 20:18:15 -0800 Jason Short wrote:
> map_pos_to_index, as written, needs temp variables.  If written in macro 
> form (without any change to the interface) these temp variables must be 
> made global.  This doesn't work since multiple calls to this function 
> can be made within one sequence.  For instance
>
>    hmap(x, y) = hmap(x1, y1) + foo(); /* hmap calls map_pos_to_index */
>
> is not valid C if map_pos_to_index isn't coded properly.

That's just the situation I ran into with undefined behaviour, so
I begin to see the use for inlining, at least with map_pos_to_index().

I'm sorry if you've had this discussion before. I'm pretty sure you
have, from what I recall when the search engine worked.


Arnstein