Date: Tue, 19 Nov 1996 15:30:34 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: travis@EvTech.com (Travis Hassloch x231) Cc: sommerfeld@orchard.medford.ma.us, tech-kern@NetBSD.ORG, hackers@FreeBSD.org Subject: Re: Kernel calls - args in registers Message-ID: <199611192230.PAA09730@phaeton.artisoft.com> In-Reply-To: <199611192106.PAA02602@tahiti.evtech.com> from "Travis Hassloch x231" at Nov 19, 96 03:06:53 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > of course, if you're going to pass syscall arguments in registers (and > > do the syscall.c-equivalent in hand-massaged assembler) you might find > > that you'll get a bigger *system* performance gain (at least on "CISC" > > systems like the i386 and m68k) by using a more RISC-like calling > > convention with the first few arguments in registers.. > > I've been looking at this a bit lately, and noticed that, as you > point out, gcc doesn't use registers on the x86 by default (IMHO it should > have, at least if you can configure that for free Unixes -- it's not like we > had a historical baggage commercial compiler to be call-level compatible > with). What about processor emulation environments? For instance, running my NetScape binaries on an Alpha using a processor emulator that converts traps to native kernel calls? I think that in this situation, calling in registers would complicate (and in some cases, because of alignment, make nearly impossible) such cross-processor ABI emulation. I find it extremely unlikely that NetScape will be porting to BSD or Linux on a PowerMAC (for example) any time soon, and this ABI/processor hybridization is about the only way you will be able to use commercial apps on that platform. FWIW: I agree on intra-kernel calling; I'd go so far as to suggest using callee-pop conventions, in fact. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199611192230.PAA09730>