Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ukma!xanth!mcnc!rti!xyzzy!tiktok!meissner
From: meissner@tiktok.dg.com (Michael Meissner)
Newsgroups: gnu.gcc
Subject: Re: question on parm passing in regs
Message-ID: <6366@xyzzy.UUCP>
Date: 23 May 89 15:02:25 GMT
References: <8905182218.AA12401@riunite.aca.mcc.com>
Sender: usenet@xyzzy.UUCP
Reply-To: meissner@tiktok.UUCP (Michael Meissner)
Distribution: gnu
Organization: Data General (Languages @ Research Triangle Park, NC.)
Lines: 36

In article <8905182218.AA12401@riunite.aca.mcc.com> rfg@MCC.COM (Ron Guilmette) writes:
| 
| I have just noticed that the tm-sparc.h file allows for
| function parameters to be passed via registers, but it
| does *not* allow parameters (no matter what their type)
| to be passed via the floating point registers.
| 
| This gives rise to two questions.
| 
| First, is the tm-sparc.h file just obeying existing
| conventions?
| 
| Second, regardless of whether or not the tm-sparc.h file
| reflects the existing (Sun mandated) conventions, doesn't
| this seem wasteful?  It seems that this would be especially
| wasteful whenever you had some function calls like:
| 
| 	calculate_something (x1+y1, x2+y2);
| 
| where the values of the parameters had to be calculated into
| the floating-point registers just before the call anyway.
| 
| It there some secret reason that I don't know about which
| makes it inadvisable to pass floating-point parameters in
| floating-point registers?

I would suspect that 1) tm-sparc.h is following Sun's convention, and
2) it would make varargs harder, because you couldn't traverse a
single linear list.  I had to deal with this for the 88k, because some
arguments are passed in registers, and some are passed in the shadow
stack locations, but it required adding builtins and new syntax to get
it work correctly.
--
Michael Meissner, Data General.
Uucp:		...!mcnc!rti!xyzzy!meissner		If compiles were much
Internet:	meissner@dg-rtp.DG.COM			faster, when would we
Old Internet:	meissner%dg-rtp.DG.COM@relay.cs.net	have time for netnews?