public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Scott Christley <scottc@net-community.com>
To: Richard Henderson <rth@cygnus.com>
Cc: egcs@cygnus.com
Subject: Re: GCC/ObjC enhancements, comments requested
Date: Sun, 08 Feb 1998 10:21:00 -0000	[thread overview]
Message-ID: <Pine.LNX.3.95.980208122344.32402A-100000@duncan.net-community.com> (raw)
In-Reply-To: <19980207224541.37240@dot.cygnus.com>

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



  reply	other threads:[~1998-02-08 10:21 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1998-02-07 18:11 Scott Christley
1998-02-07 22:43 ` Richard Henderson
1998-02-08 10:21   ` Scott Christley [this message]
1998-02-10  3:34     ` Richard Henderson
1998-02-10 14:45   ` Anthony Green
1998-02-08 10:27 ` Ovidiu Predescu
1998-02-08 13:12   ` Marcus G. Daniels
1998-02-08 22:32     ` Ovidiu Predescu
1998-02-09  7:43       ` Bruno Haible
1998-02-09 15:33         ` Ovidiu Predescu
     [not found]           ` <199802092146.WAA04183@halles.ilog.fr>
1998-02-10 10:58             ` Ovidiu Predescu
1998-02-10 14:45               ` Joern Rennecke
1998-02-09 11:31       ` Marcus G. Daniels
1998-02-10  3:34       ` Richard Henderson
1998-02-10 10:58         ` Ovidiu Predescu
1998-02-09 14:46     ` Anthony Green

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.3.95.980208122344.32402A-100000@duncan.net-community.com \
    --to=scottc@net-community.com \
    --cc=egcs@cygnus.com \
    --cc=rth@cygnus.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).