llvm dev - Jan 2010 - [LLVMdev] llc generated machine assembly code for NASM

On 01/28/2010 11:41 AM, Anton Korobeynikov wrote:
>
> The required efforts equal to ones required to write new assembler.
> "Too weak to be usable" means "it's not possible to
represent many
> important constructs with masm/nasm/fasm".
Wow.  It's perhaps too much of a distraction, but I'm curious about the 
details of this.  It's probably because it's first mission is to be a 
compiler back-end, but the common wisdom is that gas is bare-bones and 
masm is featureful.  Clearly that doesn't hold for what LLVM needs, and 
you imply it's true for the whole family of assemblers that use Intel 
syntax.  Very surprising to those of us (well, me anyway) with minimal 
time writing actual assembly.

Is any of this documented somewhere I can just go off and read, or is it 
just lore in the LLVM community?

Dustin

> Wow.  It's perhaps too much of a distraction, but I'm curious about
the
> details of this.  It's probably because it's first mission is to be
a
> compiler back-end, but the common wisdom is that gas is bare-bones and
> masm is featureful.
Think about one thing: vcpp emits object file directly, not via masm.
The generated listings (via /Fa option) cannot be assembled, in
general.
> Is any of this documented somewhere I can just go off and read, or is it
> just lore in the LLVM community?
At some time (say, LLVM 1.7-1.8 dates) it was a hope, that intel
asmprinter will be as usable as gnu as. Unfortunately, it turned out
that this is not possible.
Pick any non-trivial C++ app and try to convert the output to masm /
nasm and you'll get an idea (linkonce / weak stuff is an example, but
not the last problem).

-- 
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University

On Jan 28, 2010, at 11:51 AM, Dustin Laurence wrote:
> On 01/28/2010 11:41 AM, Anton Korobeynikov wrote:
>>
>> The required efforts equal to ones required to write new assembler.
>> "Too weak to be usable" means "it's not possible to
represent many
>> important constructs with masm/nasm/fasm".
>
> Wow.  It's perhaps too much of a distraction, but I'm curious about
> the
> details of this.  It's probably because it's first mission is to be
a
> compiler back-end, but the common wisdom is that gas is bare-bones and
> masm is featureful.  Clearly that doesn't hold for what LLVM needs,  
> and
> you imply it's true for the whole family of assemblers that use Intel
> syntax.  Very surprising to those of us (well, me anyway) with minimal
> time writing actual assembly.
The long term plans are to finish the integrated assembler.  We  
currently have active work to finish the assembler for Macho X86 32/64  
targets.  I suspect that ELF will follow shortly after that, though I  
don't know who exactly will do the work.  Adding PECOFF support should  
not be that hard, and would obviate the dependence on a third-party  
assembler.

MASM is not a production quality assembler IMO, which is why Microsoft  
doesn't use it with VC++.  I don't know whether nasm or fasm are, but  
I think it's more productive to work on the integrated assembler  
(again, once the macho support is complete and reliable) than to add  
nasm/fasm support.

-Chris

I have one thing not clear to me. If the llvm diect generate object
code. Then how about the llvm assembler processing  llvm code with
inline assembly? Indeed, it's seems now llvm is direct using gas
syntax in the assembly code. And because it's generate .S files, so it
can be manipulated by binutils. But there is one day, no binutils any
further, how to deal with these inline assembly. Generally, there is
two major inline assembly at all, one is vc++ style, and one is gcc
style. Then llvm mc will support which one or both or it's own inline
assembly?


2010/1/29, Chris Lattner <clattner at apple.com>:
>
> On Jan 28, 2010, at 11:51 AM, Dustin Laurence wrote:
>
>> On 01/28/2010 11:41 AM, Anton Korobeynikov wrote:
>>>
>>> The required efforts equal to ones required to write new assembler.
>>> "Too weak to be usable" means "it's not possible
to represent many
>>> important constructs with masm/nasm/fasm".
>>
>> Wow.  It's perhaps too much of a distraction, but I'm curious
about
>> the
>> details of this.  It's probably because it's first mission is
to be a
>> compiler back-end, but the common wisdom is that gas is bare-bones and
>> masm is featureful.  Clearly that doesn't hold for what LLVM needs,
>> and
>> you imply it's true for the whole family of assemblers that use
Intel
>> syntax.  Very surprising to those of us (well, me anyway) with minimal
>> time writing actual assembly.
>
> The long term plans are to finish the integrated assembler.  We
> currently have active work to finish the assembler for Macho X86 32/64
> targets.  I suspect that ELF will follow shortly after that, though I
> don't know who exactly will do the work.  Adding PECOFF support should
> not be that hard, and would obviate the dependence on a third-party
> assembler.
>
> MASM is not a production quality assembler IMO, which is why Microsoft
> doesn't use it with VC++.  I don't know whether nasm or fasm are,
but
> I think it's more productive to work on the integrated assembler
> (again, once the macho support is complete and reliable) than to add
> nasm/fasm support.
>
> -Chris
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-- 
从我的移动设备发送

         此致
礼
罗勇刚
Yours
    sincerely,
Yonggang Luo