www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Assembly Integration into Compiler

reply eris <jvburnes gmail.com> writes:
I believe I read in TDPL that D2 compilers actually assemble asm statement
code directly.  This would seem to break modularity and require every compiler
to re-implement every possible assembler.  Not exactly good news for a systems
programming language.

I hope I read that incorrectly because it seems to be a design mistake.
Jul 07 2011
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/7/2011 10:45 AM, eris wrote:

 I believe I read in TDPL that D2 compilers actually assemble asm statement
 code directly.


Yes, that is correct.


 This would seem to break modularity and require every compiler
 to re-implement every possible assembler.


Not really. Assemblers aren't hard to write.


 Not exactly good news for a systems programming language.


Having an integrated assembler is great for a systems programming language.
It's 
not that awkward kludge used in gcc.


 I hope I read that incorrectly because it seems to be a design mistake.


Take a look at the druntime sources. It makes good and appropriate use of the 
inline assembler.
Jul 07 2011
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 07 Jul 2011 14:01:10 -0400, Walter Bright  
<newshound2 digitalmars.com> wrote:


 On 7/7/2011 10:45 AM, eris wrote:

 This would seem to break modularity and require every compiler
 to re-implement every possible assembler.


 Not really. Assemblers aren't hard to write.


To clarify, D's inline assembler has it's own syntax, and works across  
OSes.  Essentially, D doesn't support other assemblers, it simply  
implements an assembler inside D.  Plus it integrates symbols with normal  
D code, making assembly *much* easier to write.

Read the documentation here: http://www.digitalmars.com/d/2.0/iasm.html

-Steve
Jul 07 2011
parent reply eris <jvburnes gmail.com> writes:
I'm sure it's a good assembler, I'm just thinking that if you wanted to
cross-develop for ARM or some other CPU you would have to write the assembler
for
it rather than leverage an existing ARM assembler.

Perhaps its easy enough to snag the critical assembler components from an
existing
assembler, but it still means that D sources must carry all of the existing
target
assemblers.

Modularity...just saying.   But I realize that this also allows for very tight
control over the compiled/assembled code.

Maybe this is no big deal when you consider that cross-development requires a
custom build chain anyway.

Other than that, I love D/D2.  (Though trying to get LDC2/qtd to work right now
is
driving me a little nuts.  :-)
Jul 07 2011
next sibling parent Daniel Gibson <metalcaedes gmail.com> writes:
Am 07.07.2011 20:58, schrieb eris:

 I'm sure it's a good assembler, I'm just thinking that if you wanted to
 cross-develop for ARM or some other CPU you would have to write the assembler
for
 it rather than leverage an existing ARM assembler.
 
 Perhaps its easy enough to snag the critical assembler components from an
existing
 assembler, but it still means that D sources must carry all of the existing
target
 assemblers.
 
 Modularity...just saying.   But I realize that this also allows for very tight
 control over the compiled/assembled code.
 
 Maybe this is no big deal when you consider that cross-development requires a
 custom build chain anyway.
 
 Other than that, I love D/D2.  (Though trying to get LDC2/qtd to work right
now is
 driving me a little nuts.  :-)
 


It's all much better than having to use different assembler syntax on
different compilers (even when they're generating code for the same CPU).
Jul 07 2011
prev sibling next sibling parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Thu, 07 Jul 2011 21:58:12 +0300, eris <jvburnes gmail.com> wrote:


 I'm sure it's a good assembler, I'm just thinking that if you wanted to
 cross-develop for ARM or some other CPU you would have to write the  
 assembler for
 it rather than leverage an existing ARM assembler.


An assembler can be written in under a few hundred lines. There's no  
practical need for code re-use.

-- 
Best regards,
  Vladimir                            mailto:vladimir thecybershadow.net
Jul 07 2011
prev sibling next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
The inline assembler is *the* killer feature for me in
Digital Mars products. It's so much easier to use than the
competition's alternatives.
Jul 07 2011
parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
There's nothing stopping you from using an external assembler? You can
hook up NASM and D code pretty easily.
Jul 07 2011
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/7/2011 12:14 PM, Andrej Mitrovic wrote:

 There's nothing stopping you from using an external assembler? You can
 hook up NASM and D code pretty easily.


I abandoned using third party assemblers years ago because:

1. Poor (i.e. zero) integration with the compiler.

2. You have to rewrite your data structure & manifest constant declarations in 
the assembler, and of course these always get out of sync with the ones in your 
C/D source.

3. Having the compiler set up the call/return sequences and parameter
addressing 
is so darned convenient.

4. The compiler will keep track of register usage for you.

5. There are lots of 3rd party assemblers, all different. Even the same 
assembler will have multiple versions. The chances of the asm source you ship 
assembling on all of them, and avoiding all the various bugs in them, is zero. 
It was a major tech support issue.

6. It really hurts my brain to have gas swap the operands.

7. gas (gnu assembler) doesn't follow the Intel syntax so you have to do a 
mental translation from the Intel datasheets to the gas source. gas doesn't
even 
use the same instruction names. Bah.

8. External assemblers don't do name mangling. You've got to do it all
manually. 
This is a horror.

9. Symbolic debug formats differ.

10. Having to manage a separate source file for just two instructions was
highly 
annoying.


Getting the assembler integrated into the compiler made me much more productive 
and my life much easier. It was a giant win, no doubt about it.
Jul 07 2011
next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
I wasn't referring to you Walter, but to users who want to use their
own assembler. :)
Jul 07 2011
prev sibling next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
Walter Bright wrote:

 On 7/7/2011 12:14 PM, Andrej Mitrovic wrote:

 There's nothing stopping you from using an external assembler? You can
 hook up NASM and D code pretty easily.


 ...
 6. It really hurts my brain to have gas swap the operands.

 7. gas (gnu assembler) doesn't follow the Intel syntax so you have to do a
 mental translation from the Intel datasheets to the gas source. gas doesn't
even
 use the same instruction names. Bah.
 [snip]


asm(".intel_syntax noprefix\n"); + Compiler Switch iirc.
This fixes syntax, but all the other parts of gas remain kludgy.

I fully agree with all the other points. Having a neat inline assembler can be
extremely handy.

Cheers,
-Timon
Jul 07 2011
prev sibling parent eris <jvburnes gmail.com> writes:
Walter said...

I abandoned third-party assemblers years ago because...

1.

...

10.

All very good points.   I stand corrected and yield the debate to the vastly
more
experienced party.

:-)
Jul 07 2011
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 7/7/2011 11:58 AM, eris wrote:

 I'm sure it's a good assembler, I'm just thinking that if you wanted to
 cross-develop for ARM or some other CPU you would have to write the assembler
for
 it rather than leverage an existing ARM assembler.


Yes, you would.
Jul 07 2011