Thread: Re: [PORTS] Patch for m68k architecture (fwd)

> 
> Hi Bruce!
> 
> > I have already asked for you to try a change to template/linux_m68k
> > by changing the optimization -O2 to -O and see if you still need the
> > postgres.h fmgr_ptr change you did.  I assume you are using egcs, right?
> 
> Can't remember that you asked me... But anyway, it wouldn't help. It's
> defined in the SysV/m68k ABI that %d0 is used for scalar return values
> and %a0 for pointer values. Both gcc and egcs do it like this, and
> it's also independent from optimization level. (And, BTW, I didn't use
> egcs.)
> 
> This behaviour is one of the most prominent porting problems to m68k.
> ANSI C says results are undefined if you call a function via pointer
> and the pointer is declared to return another type than the function
> actually returns. So m68k compilers conform to the standard here.
> However, most programmers never expect such problems... also because
> on most architectures it works without probs, because all values are
> returned in the same register.

Yes, we admit that we break the standard with fmgr_ptr, because we
return a variety of values depending on what function they call.  It
appears the egcs optimization on the powerpc or alpha cause a problem
when optimization is -O2, but not -O.  We may see more platforms with
problems as optimizers get smarter.

--  Bruce Momjian                        |  http://www.op.net/~candle maillist@candle.pha.pa.us            |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 

Bruce Momjian <maillist@candle.pha.pa.us> writes:
>> ANSI C says results are undefined if you call a function via pointer
>> and the pointer is declared to return another type than the function
>> actually returns. So m68k compilers conform to the standard here.

> Yes, we admit that we break the standard with fmgr_ptr, because we
> return a variety of values depending on what function they call.  It
> appears the egcs optimization on the powerpc or alpha cause a problem
> when optimization is -O2, but not -O.  We may see more platforms with
> problems as optimizers get smarter.

Seeing as how we also know that the function-call interface ought to be
redesigned to handle NULLs better, maybe we should just bite the bullet
and fix all of these problems at once by adopting a new standard
interface for everything that can be called via fmgr.  It'd uglify the
code, no doubt, but I think we are starting to see an accumulation of
problems that justify doing something.

Here is a straw-man proposal:
       Datum function (bool  *resultnull,                       Datum *args,                       bool  *argnull,
                int    nargs)
 

args[i] is the i'th parameter, or undefined (perhaps always 0?)
when argnull[i] is true.  The function is responsible for setting
*resultnull, and returns a Datum value if *resultnull is false.
Most standard functions could ignore nargs since they'd know what it
should be, but we ought to pass it for flexibility.

A useful addition to this scheme would be for fmgr to preset *resultnull
to the OR of the input argnull[] array just before calling the function.
In the typical case where the function is "strict" (ie, result is NULL
if any input is NULL), this would save the function from having to look
at argnull[] at all; it'd just check *resultnull and immediately return
if true.

As an example, int4 addition goes from

int32
int4pl(int32 arg1, int32 arg2)
{   return arg1 + arg2;
}

to

Datum
int4pl (bool *resultnull, Datum *args, bool *argnull, int nargs)
{   if (*resultnull)       return (Datum) 0;        /* value doesn't really matter ... */   /* we can ignore argnull
andnargs */
 
   return Int32GetDatum(DatumGetInt32(args[0]) + DatumGetInt32(args[1]));
}

This is, of course, much uglier than the existing code, but we might be
able to improve matters with some well-chosen macros for the boilerplate
parts.  What we actually end up writing might look something like

Datum
int4pl (PG_FUNCTION_ARGS)
{   PG_STRICT_FUNCTION(            /* encapsulates null check */       PG_ARG0_INT32;       PG_ARG1_INT32;
PG_RESULT_INT32( arg0 + arg1 );   );
}

where the macros expand to things like "int32 arg0 = DatumGetInt32(args[0])"
and "return Int32GetDatum( x )".  It'd be worth a little thought to
try to set up a group of macros like that, I think.
        regards, tom lane

Hi Bruce!

> Yes, we admit that we break the standard with fmgr_ptr, because we
> return a variety of values depending on what function they call.

Yep... the correct thing would be to cast all such return values to a
common type (e.g. long) and cast them back in the caller.

> It appears the egcs optimization on the powerpc or alpha cause a
> problem when optimization is -O2, but not -O.

Can be like this on those archs. On m68k, however, the registers for
function return values are the same independent of optimization level.

> We may see more platforms with problems as optimizers get smarter.

Yep...

Roman

> Seeing as how we also know that the function-call interface ought to
> be redesigned to handle NULLs better, maybe we should just bite the
> bullet and fix all of these problems at once by adopting a new
> standard interface for everything that can be called via fmgr.
[...]

This all looks fine. At least it would solve the current function
return value problem on m68k.

Roman