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: Richard Zidlicky
Subject: Re: [Gcl-devel] Re: (object (*)()) vs (long (*)())
Date: Fri, 2 Aug 2002 13:01:35 +0200
User-agent: Mutt/1.2.5i

On Thu, Aug 01, 2002 at 03:08:00PM -0400, Camm Maguire wrote:
> 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.

imo the proper thing for lisp-like systems is to return some opaque 
long or union type for all functions. The caller mostly has to check
the return type of the result which involves some bit-fiddling so
a long is pretty convenient.
Only in places where the compiler is good enough to infere *all* type 
information you could use native 'c' types, but those are the cases 
that can be easilly inlined and the compiler has enough information 
to use correct functin declaration I would assume.

I haven't looked into the gcl sources yet, but scm/hobbit is an example 
how to get such things pretty portable, the bit-fiddling it uses looks 
pretty wild but appears really stable and portbale.

Alternatively you could define your own name-mangling/signature
control a'la c++ and have lots of fun with it :)

> 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. 

it seems that before doing that kind of effort it would be much easier
to fix the compiler to generate consistent code?

Richard




reply via email to

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