This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Scheduling x86 dispatch windows


On Fri, Jun 11, 2010 at 12:09 PM, Quentin Neill
<quentin.neill.gnu@gmail.com> wrote:
> 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?
>

I would suggest generating object code directly, totally bypassing
assembler. Many compilers do it. But it is a HUGE effort.


-- 
H.J.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]