__builtin_apply/sparc.md problem on SPARC-Solaris ?

__builtin_apply/sparc.md problem on SPARC-Solaris ?

[Helge Hess]

Hi,

I had problems using the objc_msg_sendv() function from the Objective-C
runtime. Since the function relies on __builtin_apply() I wonder whether
something is wrong with this in egcs-SPARC and whether such a problem is
known.

I found a patch for gcc 2.8.0 (works on egcs-1.0.3 as well) on

  ftp://alpha.gnu.org/gnu/gnustep/contrib/gcc-2.8.0-sparc.diff

which solved the problem for me (actually I applied the patch by hand,
since the CVS egcs sparc.md file is much different from the egcs-1.0.3
one).
If it matters, I'm using an UltraSPARC machine with Solaris 2.6.

------diff of what I changed in gcc/config/sparc/sparc.md------
7305c7305,7307
<                              GEN_INT (INTVAL (operands[3]) & 0xfff),
---
> /*HH patch inspired by ftp://alpha.gnu.org/gnu/gnustep/contrib/gcc-2.8.0-sparc.diff
>                              GEN_INT (INTVAL (operands[3]) & 0xfff),*/
>                                operands[3],
7337c7339,7341
<                          GEN_INT (INTVAL (operands[3]) & 0xfff),
---
> /*HH patch inspired by ftp://alpha.gnu.org/gnu/gnustep/contrib/gcc-2.8.0-sparc.diff
>                          GEN_INT (INTVAL (operands[3]) & 0xfff),*/
>                            operands[3],
------snap------

There is some operation applied on the 'operands[3]' which is removed by
the patch.

Since I do not understand the modification at all, I wonder whether this
patch is a hack or whether it's a correct fix, in which case I wonder
why it isn't in the egcs repository.

BTW: Where are these .md files used ? They look like a lisp-C mixture ?!

It would be kind if anyone with knowledge about egcs-SPARC could say
something to this issue
  Helge
-- 
MDlink online service center
http://www.mdlink.de/

Re: __builtin_apply/sparc.md problem on SPARC-Solaris ?

[Richard Henderson]

On Tue, Oct 20, 1998 at 12:50:42PM +0200, Helge Hess wrote:
> I had problems using the objc_msg_sendv() function from the Objective-C
> runtime. Since the function relies on __builtin_apply() I wonder whether
> something is wrong with this in egcs-SPARC and whether such a problem is
> known.

Very well known.  __builtin_apply will not work on any machine
that doesn't simply push arguments on the stack.

The extention is an abomination and should be removed.


r~

Re: __builtin_apply/sparc.md problem on SPARC-Solaris ?

[Richard Henderson]

On Tue, Oct 20, 1998 at 12:50:42PM +0200, Helge Hess wrote:
> I had problems using the objc_msg_sendv() function from the Objective-C
> runtime. Since the function relies on __builtin_apply() I wonder whether
> something is wrong with this in egcs-SPARC and whether such a problem is
> known.

I should have mentioned that the proper way to do something 
like what objc is trying to do with __builtin_apply is to 
use a library like libffi.

  ftp://ftp.cygnus.com/pub/home/green/libffi-1.20.tar.gz


r~

Re: __builtin_apply/sparc.md problem on SPARC-Solaris ?

[Richard Henderson]

On Thu, Oct 22, 1998 at 08:52:59AM -0700, Ovidiu Predescu wrote:
> Conceptually the idea seems to be good, I never understood
> why you're saying it's not good.

Because __builtin_apply does not receive type info for the function
arguments or return value.  So on any machine in which that makes a
difference as to which register is used -- which is quite a few --
it cannot possibly work.

> I would also like to replace it with something else but I don't know
> of a dynamic function invocation library that could be released together
> with EGCS, so that we don't introduce unnecessary dependencies for the
> Objective-C runtime library.

In which case I guess the bits you need will have to be reimplemented
for libobjc.


r~

Re: __builtin_apply/sparc.md problem on SPARC-Solaris ?

[Richard Henderson]

On Thu, Oct 22, 1998 at 09:22:38AM -0700, Ovidiu Predescu wrote:
> Could you please list one case in which type information is needed?

Some m68k return pointers in a0, integers in d0, fp in fp0.

Alpha, MIPS, PPC and many others take fp arguments in fp regs,
others in int regs.

Sparc64 splits structures <= 32 bytes into fundamental types
and promotes them by type into integer and fp regs.  Structures
larger than 32 bytes are passed by reference.



r~

Re: __builtin_apply/sparc.md problem on SPARC-Solaris ?

[Ovidiu Predescu]

On Wed, 21 Oct 1998 23:18:05 -0700, Richard Henderson <rth@cygnus.com> wrote:

> On Tue, Oct 20, 1998 at 12:50:42PM +0200, Helge Hess wrote:
> > I had problems using the objc_msg_sendv() function from the Objective-C
> > runtime. Since the function relies on __builtin_apply() I wonder whether
> > something is wrong with this in egcs-SPARC and whether such a problem is
> > known.
> 
> Very well known.  __builtin_apply will not work on any machine
> that doesn't simply push arguments on the stack.

It does actually work on RISC machines and it used to work on Sparc/Solaris.
All the registers are saved and restored in and from a buffer by the
__builtin_apply/restore functions, so it should work even if the arguments are
passed on registers. Conceptually the idea seems to be good, I never understood
why you're saying it's not good.

> The extention is an abomination and should be removed.

I would also like to replace it with something else but I don't know of a
dynamic function invocation library that could be released together with EGCS,
so that we don't introduce unnecessary dependencies for the Objective-C runtime
library.

Ovidiu

Re: __builtin_apply/sparc.md problem on SPARC-Solaris ?

[Ovidiu Predescu]

On Thu, 22 Oct 1998 09:15:46 -0700, Richard Henderson <rth@cygnus.com> wrote:

> On Thu, Oct 22, 1998 at 08:52:59AM -0700, Ovidiu Predescu wrote:
> > Conceptually the idea seems to be good, I never understood
> > why you're saying it's not good.
> 
> Because __builtin_apply does not receive type info for the function
> arguments or return value.  So on any machine in which that makes a
> difference as to which register is used -- which is quite a few --
> it cannot possibly work.

Could you please list one case in which type information is needed?

> > I would also like to replace it with something else but I don't know
> > of a dynamic function invocation library that could be released together
> > with EGCS, so that we don't introduce unnecessary dependencies for the
> > Objective-C runtime library.
> 
> In which case I guess the bits you need will have to be reimplemented
> for libobjc.

I can do this if I understand why the current mechanism is broken.

Thanks,
Ovidiu

Re: __builtin_apply/sparc.md problem on SPARC-Solaris ?

[Ovidiu Predescu]

On Thu, 22 Oct 1998 15:55:34 -0700, Richard Henderson <rth@cygnus.com> wrote:

> On Thu, Oct 22, 1998 at 09:22:38AM -0700, Ovidiu Predescu wrote:
> > Could you please list one case in which type information is needed?
> 
> Some m68k return pointers in a0, integers in d0, fp in fp0.
> 
> Alpha, MIPS, PPC and many others take fp arguments in fp regs,
> others in int regs.
> 
> Sparc64 splits structures <= 32 bytes into fundamental types
> and promotes them by type into integer and fp regs.  Structures
> larger than 32 bytes are passed by reference.

We had the same discussion a while ago and explained you how the Objective-C
runtime uses the __builtin_apply function. It doesn't use the mechanism to
dynamically create method invocations but to forward the message to another
object on possibly another method that takes the _exact_ same arguments.

For doing this thing the __builtin_apply mechanism should be sufficient as it
copies all the registers involved in a function call and restores their values
at the end. The caller sees the function invocation as a normal function call
and takes the return value from the expected place no matter is on stack or in
some register.

For building dynamic function invocations I agree with you that we need to have
additional type information. libffi is a very good example of how to do the
things.

Ovidiu