Thread overview
Inline Assembler in GDC
Jan 01, 2005
David Friedman
Jan 03, 2005
Simon Buchan
Jan 04, 2005
David Friedman
December 26, 2004
Q: How much work would adding asm { } mean ?


In "theory" it should be able to translate D into
asm { } sections of the regular GCC, but I suppose
the syntax have to be massaged first, for the X86 ?

http://www.digitalmars.com/d/iasm.html


As for PPC syntax, the D language spec doesn't even
mention the CPU :-(, so I guess anything goes there ?
(suggestion: using something very similar to GCC/gas)

http://developer.apple.com/documentation/DeveloperTools/Reference/Assembler/


Compiling the C and asm functions separately works as a
workaround in the meantime, so it's not really urgent...

--anders

PS. Just as the X86 assembly assumes a Pentium,
    the PPC assembly can assume a G3 or above ?

January 01, 2005
Anders F Björklund wrote:
> Q: How much work would adding asm { } mean ?
> 
> 
> In "theory" it should be able to translate D into
> asm { } sections of the regular GCC, but I suppose
> the syntax have to be massaged first, for the X86 ?
> 
> http://www.digitalmars.com/d/iasm.html
> 

The easy part is translating opcode and register names.  Other tasks
are: parsing expressions, determining the operand size and addressing
mode, evaluating type/variable expressions, etc.  The DMD sources don't
include the code to do any of this.

A temporary shortcut would be to pass as much as the expression as
possible on to the assembler and let it determine what is valid.

> 
> As for PPC syntax, the D language spec doesn't even
> mention the CPU :-(, so I guess anything goes there ?
> (suggestion: using something very similar to GCC/gas)
> 
> http://developer.apple.com/documentation/DeveloperTools/Reference/Assembler/ 
> 

Or the CodeWarrior-style asm blocks that Apple added to GCC.  In fact, I
can probably use some of that code.

> 
> 
> Compiling the C and asm functions separately works as a
> workaround in the meantime, so it's not really urgent...
> 
> --anders
> 
> PS. Just as the X86 assembly assumes a Pentium,
>     the PPC assembly can assume a G3 or above ?
> 


Ideally, the whole range of RS/6000 and PowerPC CPUs should be supported.  I don't think there is that much difference between them, though.

David
January 01, 2005
David Friedman wrote:

> A temporary shortcut would be to pass as much as the expression as
> possible on to the assembler and let it determine what is valid.

Sounds like a good start! Usually one only adds a few snippets anyway...
Can it be fed into the usual GCC assembly processor, by any chance ?

> Or the CodeWarrior-style asm blocks that Apple added to GCC.  In fact, I
> can probably use some of that code.

asm { } blocks would be the preferred result, I think. One can always
switch to separate .s files, if larger assembly blocks are needed ?

>> PS. Just as the X86 assembly assumes a Pentium,
>>     the PPC assembly can assume a G3 or above ?
> 
> Ideally, the whole range of RS/6000 and PowerPC CPUs should be supported.  I don't think there is that much difference between them, though.

Just meant if it's a shortcut to ignore the POWER 601 opcodes and 603,
then by all means focus on the modern processors instead ? (AltiVec ?)

--anders
January 03, 2005
On Sun, 26 Dec 2004 11:57:56 +0100, Anders F Björklund <afb@algonet.se> wrote:

> Q: How much work would adding asm { } mean ?
>
>
> In "theory" it should be able to translate D into
> asm { } sections of the regular GCC, but I suppose
> the syntax have to be massaged first, for the X86 ?
>
> http://www.digitalmars.com/d/iasm.html
>
>
> As for PPC syntax, the D language spec doesn't even
> mention the CPU :-(, so I guess anything goes there ?
> (suggestion: using something very similar to GCC/gas)
>
> http://developer.apple.com/documentation/DeveloperTools/Reference/Assembler/
>
>
> Compiling the C and asm functions separately works as a
> workaround in the meantime, so it's not really urgent...
>
> --anders
>
> PS. Just as the X86 assembly assumes a Pentium,
>      the PPC assembly can assume a G3 or above ?
>
>

Just out of curiosity, would running the asm block contents
through an external assembler, then putting the output back
as an __emit__ block not be feasable? (OK, symbols, etc...)
January 04, 2005
Simon Buchan wrote:
> On Sun, 26 Dec 2004 11:57:56 +0100, Anders F Björklund <afb@algonet.se> wrote:
> 
>> Q: How much work would adding asm { } mean ?
>>
>>
>> In "theory" it should be able to translate D into
>> asm { } sections of the regular GCC, but I suppose
>> the syntax have to be massaged first, for the X86 ?
>>
>> http://www.digitalmars.com/d/iasm.html
>>
>>
>> As for PPC syntax, the D language spec doesn't even
>> mention the CPU :-(, so I guess anything goes there ?
>> (suggestion: using something very similar to GCC/gas)
>>
>> http://developer.apple.com/documentation/DeveloperTools/Reference/Assembler/ 
>>
>>
>>
>> Compiling the C and asm functions separately works as a
>> workaround in the meantime, so it's not really urgent...
>>
>> --anders
>>
>> PS. Just as the X86 assembly assumes a Pentium,
>>      the PPC assembly can assume a G3 or above ?
>>
>>
> 
> Just out of curiosity, would running the asm block contents
> through an external assembler, then putting the output back
> as an __emit__ block not be feasable? (OK, symbols, etc...)

GCC's output *is* and assembler file.  So, in some sense, it's just a matter of writting the inline asm code to the output.  The compiler still has to parse each assembler statement to find variables and replace them with stack offsets, mangled symbol names, etc.  Also, for X86, Intel syntax needs to be translated to GAS syntax.

David