[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <473A26A2.7090007@zytor.com>
Date: Tue, 13 Nov 2007 14:35:14 -0800
From: "H. Peter Anvin" <hpa@...or.com>
To: Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>
CC: akpm@...ux-foundation.org, linux-kernel@...r.kernel.org,
Andi Kleen <ak@....de>, Chuck Ebbert <cebbert@...hat.com>,
Christoph Hellwig <hch@...radead.org>,
Jeremy Fitzhardinge <jeremy@...p.org>
Subject: Re: [patch 5/8] Immediate Values - x86 Optimization (update)
Mathieu Desnoyers wrote:
>
> Andi seemed to trust gas stability and you answered:
>
> "The comment was referring to x86-64, but I incorrectly remembered that
> applying to "movq $imm,%reg" as opposed to loading from an absolute
> address. gas actually has a special opcode (movabs) for the 64-bit
> version of the latter variant, which is only available with %rax and its
> subregisters.
>
> Nevermind, in other words. It's still true, though, that the immediate
> will always be the last thing in the instruction -- that's a fixture of
> the instruction format."
>
> So, in the end, is there a way to make x86_64 use a fixed-size opcode
> for the 1, 2, 4 and 8 bytes load immediates or we will have to force the
> use of a specific register ?
>
> (and we can't take a pointer from the end of the instruction, because we
> need to align the immediate value correctly)
>
For a 64-bit load, you'll always have a REX prefix. For 8-, 16- and
32-bit load, the length of the instruction will depend on the register
chosen, unless you constrain to either all legacy or all upper
registers, or you force gas to generate a prefix, but I don't think
there is a way to do that that will work with assemblers all the way
back to 2.12, which is at least what we officially support (I have no
idea if assemblers that far back actually *work*, mind you.)
-hpa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists