Date: 18 Aug 2002 20:15:56 +0200 From: Joshua LeVasseur <jtl-freebsd@bothan.net> To: David Edelsohn <dje@watson.ibm.com> Cc: freebsd-ppc@FreeBSD.ORG Subject: Re: freebsd-ppc: gcc's SysV ABI and parameter passing Message-ID: <1029694558.9422.501.camel@i30pc32> In-Reply-To: <200208180001.UAA09144@makai.watson.ibm.com> References: <200208180001.UAA09144@makai.watson.ibm.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 2002-08-18 at 02:01, David Edelsohn wrote: > >>>>> Joshua LeVasseur writes: > > Joshua> I think that this aspect of the SysV calling convention is really bad. > Joshua> If a data-type is 32-bits (whether or not it is expressed as a structure > Joshua> in the high level language), it should be passed by register when passed > Joshua> by value. > > Yes, the 32-bit PowerPC SVR4 ABI is rather inefficient in some > areas. You can thank Sun for that part of the ABI. This is one reason > that the 64-bit PowerPC SVR4 ABI is not an extension of the 32-bit PowerPC > SVR4 ABI (I'm not saying the 64-bit ABI is perfect either, we made > compromises). > > However, the 32-bit SVR4 ABI is the official, standard ABI. > Making private modification is arrogant and creates unnecessary > differences with user applications and standard tools. Hopefully everyone > learned enough from the Unix wars to not go down that road. > > David I can understand the concern with incompatability. But we have two realms here: the kernel and user land. For user land, I abstain. I agree, it doesn't make sense to introduce little incompatabilities here and there. But I do feel that an operating system, such as FreeBSD, should carefully choose its ABI (rather than default). Other ABIs offer compelling features, such as Apple's lazy dynamic linking (which also frees r2 for general use). If compatibility with NetBSD and Linux binaries is paramount, then oh well. For the kernel, the SVR4 ABI can be inappropriate. Some of its problems: per-function stack size, the division of volatile vs. non-volatile registers, our little issue about parameter passing (which consumes precious stack space), the restriction of function return values to r3+r4 (rather than r3-r10), amongst other issues. A kernel need not maintain ABI compatibility with user land. Kernel-user communication takes place via well defined interfaces. And if third party modules are compiled for cooperation with the kernel proper, they are usually compiled and linked against the kernel via the kernel's own tool chain. So I think it appropriate to add a kernel-friendly ABI to gcc (or command line switches in the spirit of gcc's many other ABI-altering command line switches). Josh To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ppc" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1029694558.9422.501.camel>