From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Christley To: Richard Henderson Cc: egcs@cygnus.com Subject: Re: GCC/ObjC enhancements, comments requested Date: Sun, 08 Feb 1998 10:21:00 -0000 Message-id: References: <19980207224541.37240@dot.cygnus.com> X-SW-Source: 1998-02/msg00296.html On Sat, 7 Feb 1998, Richard Henderson wrote: > On Sat, Feb 07, 1998 at 08:17:34PM -0800, Scott Christley wrote: > > * allocation information for loading the stack and register with argument > > and return values. > > I guess I don't understand why you don't just pass everything by > reference if you don't know their types. Seems _much_ cleaner > than trying to get things loaded into random registers. You at > least know how many arguments you are passing, don't you? Seems > like that plus references makes the problem non-existant. We do know the types, the issue is that we don't know the types until runtime, so we must be able to perform the same logic at runtime that GCC at compile time. > > This function is given a type string and pointers to two buffers where it > > will store its output. The function will traverse through the type string > > and for each argument store a 0 (zero), if the argument is passed in a > > register, or a 1 (one), if the argument is passed on the stack, into > > buffer; if the argument is passed on the stack then the stack size will be > > stored into sizes. > > Won't work. Its type may change which register it is passed in, > and furthermore, structure-type arguments may be passed in fragments: > parts in disjoint registers and parts on the stack. > > I can't think of any way you could get any coherent description of > where a particular non-scalar object might go. How can this be? GCC somehow must decide how to pass this information; it is obviously doing it when you compile. The issue is that we need access to this logic at runtime. I'm afraid I haven't explained the task clearly enough. Scott