Message-ID: <000d01c55ed6$16afcf00$2800000a@pc365dualp2>
From: <cutaway@bellsouth.net>
To: <linux-kernel@vger.kernel.org>
Subject: Avoid getting GAS bloat on i386 assembly -- explicit zero displacements are evil
Date: Sun, 22 May 2005 09:56:26 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2158
Lines: 49

The i386 flavor of GNU assembler appears to take specified displacements
quite literally even when they are unwanted/unneeded.

ex. movl %esi,0(%ebx)

This instruction can reasonably be encoded as a tidy 2 byte instruction
since the zero displacement is superfluous(except in a couple of special
cases). HOWEVER - this is NOT what GAS is doing. If there is a zero there,
then it builds you the puffy 3 byte form, with the worthless byte of zero
displacement, no matter what. This is quite unhandy ;->

This particular "superfluous zero" coding style DOES however appear rather
frequently in code people write for a variety of reasons. It CAN be
generated by macros behind your back. An example of this can be found in the
387 emulator code (which I've been working on slimming down and speeding up)
in:

.../kernel/arch/i386/math-emu/fpu_asm.h

#define SIGL_OFFSET 0

...blah, blah, blah...

#define SIGL(x) SIGL_OFFSET##(x)

The preprocessor dutifully pastes that zero onto what can be just a
base/index register and wham, GAS stick it to you and puffs up the generated
code ;->

I just spent an hour or so pouring through the very latest GAS source and
located the area where "the crime"<VBG> is being committed and it appears
this unwanted behavior is still in there. There appear to be a couple of
ways to hack it to behave properly - in the operand parsing where a zero
displacement could simply be thrown away, but this may complicate handling
of the funky absolute displacement modes. The actual code emitter looks
hackable near the top too where this zero displacement could be detected and
one of the operand type fields diddled accordingly. There is existing logic
to handle the special case of the BP/EBP situation where there must be a
displacement byte present, so I doubt hacking in this condition would screw
that case up.

Bottom line - check your macros and code.  GAS may be giving you gas ;->


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/