On Fri, Jun 11, 2010 at 12:09 PM, Quentin Neill <quentin.neill....@gmail.com> wrote: > On Fri, Jun 11, 2010 at 10:58 AM, Daniel Jacobowitz > <d...@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.
