From owner-freebsd-hackers Wed Dec 13 15:18:50 2000 From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 13 15:18:48 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from chopper.Poohsticks.ORG (chopper.poohsticks.org [63.227.60.73]) by hub.freebsd.org (Postfix) with ESMTP id 3A5D737B404 for ; Wed, 13 Dec 2000 15:18:48 -0800 (PST) Received: from chopper.Poohsticks.ORG (drew@localhost.poohsticks.org [127.0.0.1]) by chopper.Poohsticks.ORG (8.10.1/8.10.1) with ESMTP id eBDNImh29194 for ; Wed, 13 Dec 2000 16:18:48 -0700 Message-Id: <200012132318.eBDNImh29194@chopper.Poohsticks.ORG> To: freebsd-hackers@FreeBSD.ORG Subject: Re: syscall assembly In-reply-to: Your message of "Wed, 13 Dec 2000 18:02:44 EST." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <29190.976749527.1@chopper.Poohsticks.ORG> Date: Wed, 13 Dec 2000 16:18:47 -0700 From: Drew Eckhardt Sender: drew@chopper.Poohsticks.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message , intmktg@ CAM.ORG writes: >Perhaps, but no matter the degree of optimisation, the >16 byte of space is performed in two instructions. This >leads me to believe is it most likely a pipelining issue >for the following pushl instructions. As for subl'ing and >addl'ing 8 bytes instead of 4, as required by each pushl, >that can very well be an aligning issue which would seem >to make more sense for the x86. pushl puts the operand on the stack and then decrements %esp by an appropriate quantity. Nothing needs to be done to the stack before it. My best guess (if it isn't a bug) would be that it's there to keep the stack on a 32 byte (IIRC, this sounds like cache line size for the newer Intel chips) boundary when the program gets to open (4 for saved %ebp, 4 for the char * arg, 4 for the int arg, and 4 for the %eip call pushes requires 16 bytes more to preserve a 32 byte alignment) so that in a "normal" function without a lot of locals all of the locals are on the same cache line. Two instructions instead of 1 would help to facilitate alignment of the return address (I think 16 bytes is a good alignment for a jmp, and I can't see why a ret wouldn't the same), and a subl + addl combination would prevent interferance by a stupid peephole optimizer looking to combine addls with the same destination register. -- Home Page For those who do, no explanation is necessary. For those who don't, no explanation is possible. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message