This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: Scheduling x86 dispatch windows
On Fri, Jun 11, 2010 at 10:58 AM, Daniel Jacobowitz
<dan@codesourcery.com> wrote:
> On Thu, Jun 10, 2010 at 09:48:24PM -0500, Quentin Neill wrote:
[snip]
>> Does this qualify as a form of what you are suggesting? ?Because this
>> is exactly what is being proposed:
>>
>> .balign 8 ? ? ? ? ? ? ? ? ?# start window
>> ? ? insn op, op ? ? ? ? ?# 67 67 XX YY ZZ ?- padded with 2 prefixes to make 8
>> ? ? insn2 op, op ? ? ? ?# AA BB CC
>> .padalign 8 ? ? ? ? ? ? ?# window boundary
>> ? ? insn4 op
>> ? ? . . .
>
> No, this is quite different. ?These are directives that tell the
> assembler to make changes. ?I'm talking about assertions, not
> directives. ?Something like this:
>
> ?mov r0, r1 @ [length 2]
> ?add ip, lr, ip @ [length 4]
> ?mov r0, r1 @ [length 4] <-- assembler error 'insn has length 2'
>
> GCC can output length information, but it is never exact, and it is
> not in a form recognized by the assembler.
>
> On x86, I have no idea how this would work.
>
> --
> Daniel Jacobowitz
> CodeSourcery
>
I see.
Currently GCC doesn't compute the current encoding offset (doesn't
know mnemonic/opcode lengths), nor does it perform a relaxation pass
(to resolve forward displacement/branch offsets). Without these it
so cannot accurately formulate such assertions.
Our proposal is to let the assembler itself (knowing best the details
of the encoding stream, offsets, and the processor) aligns
instructions, with hints about the structure (block starts, ends,
instruction sets) using macros/assertions/tokens if needed.
Another option would be to expose some subset of the assembler
functionality as a plugin to GCC (similar to how gold is used) to
extract the instruction sizes. Any comments on that approach?
--
Quentin Neill