Scheduling x86 dispatch windows
Fri Jun 11 19:17:00 GMT 2010
On Fri, Jun 11, 2010 at 12:09 PM, Quentin Neill
> On Fri, Jun 11, 2010 at 10:58 AM, Daniel Jacobowitz
> <email@example.com> wrote:
>> On Thu, Jun 10, 2010 at 09:48:24PM -0500, Quentin Neill wrote:
>>> 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
> 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.
More information about the Binutils