[Top][All Lists]
[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