gcl-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gcl-devel] Re: (object (*)()) vs (long (*)())


From: Camm Maguire
Subject: Re: [Gcl-devel] Re: (object (*)()) vs (long (*)())
Date: 01 Aug 2002 15:08:00 -0400

Greetings, and thanks for your *very helpful* reply!

OK, now it is clear to me what is going on.  I calling all functions
through a variable declared to return a pointer, and some functions
are returning a long.

I can fix the instances in the existing code fairly easily, but the
issue is that the lisp compiler produces C code using these
interchangeable declarations.  At some point, I need to either have
all compiled functions return the same union and use the existing
function link helper functions (in funlink.c, et.al.), or to duplicate
these functions to handle function variables returning long and modify
the compiler to use these in the correct instances instead.  As
always, the implementation is much easier than the conception of the
proper solution.  Comments most welcome.

As a very ugly temporary hack, I suppose I can define a macro specific
to m68k which casts the function variable to long (*), and not use
-fomit-frame-pointer, to be able to retrieve correct results from
functions returning both long and pointer in actuality.  Hate to do
it, but its definitely the quickest way to restore the m68k build.

Alternatively, I could leave everything the way it is if I could
insert assembly copying the long destination register to the pointer
destination register at each function close, but this does not sound
likely. 

Take care,

Richard Zidlicky <address@hidden> writes:

> On Wed, Jul 31, 2002 at 02:51:25PM +0200, Andreas Schwab wrote:
> 
> > |> Function return values must be declared (and used) properly on m68k, 
> > |> pointer values are returned in reg a0, ints d0. I would be surprised
> > |> if m68k was the only arch that gets broken by this..
> > 
> > Actually, this should not be a problem, because functions returning a
> > pointer put the return value in both registers, to support broken
> > programs.
> 
> it is still possible to run into trouble by scrweing it up the other
> way round: write a function that returns int and call it with a cast 
> to a pointer-returning function. 
> The compiler must expect the return value in a0 but int-returning 
> functions don't do that.
> Broken beyond imagination but I have seen software doing this.
> 
> > |> expecting 'long' result from pointer-returning functions would work
> > |> as long as you don't use -fomit-frame-pointer but is a horrible hack.
> > 
> > I don't think that -fomit-frame-pointer has any influence on this, but if
> > it does, then only by chance.
> 
> it has, the code to generate the extra a0->d0 move is in 
> FUNCTION_EXTRA_EPILOGUE which gets omitted with -fomit-frame-pointer
> 
> Richard
> 
> _______________________________________________
> Gcl-devel mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/gcl-devel
> 
> 

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah



reply via email to

[Prev in Thread] Current Thread [Next in Thread]