View mode: basic / threaded / horizontal-split · Log in · Help
July 13, 2006
ASM extensions
How difficult would it be to alter the inline assembler to accept paramter
arguments for new default syntaxes?  For instance, you could have something like
asm(intel) or asm(gas) or asm(arm) or asm(hal).  That way somebody could
progromatically decide the base style of the assembly syntax they were going to
use.  It doesn't seem to be internally inconsistent, as virtually all assembler
code should be written in 'version' tags anyway, as I see it.

Also, is there anything in the works for a somewhat simpler syntax for closures
(i.e. anything like passing Ruby code/Proc blocks)?
-Gabe
July 13, 2006
Re: ASM extensions
Gabe wrote:
> How difficult would it be to alter the inline assembler to accept paramter
> arguments for new default syntaxes?  For instance, you could have something like
> asm(intel) or asm(gas) or asm(arm) or asm(hal).  That way somebody could
> progromatically decide the base style of the assembly syntax they were going to
> use.  It doesn't seem to be internally inconsistent, as virtually all assembler
> code should be written in 'version' tags anyway, as I see it.

Very time consuming - you'd have to write whole new assemblers.

> Also, is there anything in the works for a somewhat simpler syntax for closures
> (i.e. anything like passing Ruby code/Proc blocks)?

Simplifying it further would require dynamic typing.
July 13, 2006
Re: ASM extensions
Walter Bright wrote:
> Gabe wrote:
> 
>> How difficult would it be to alter the inline assembler to accept 
>> paramter
>> arguments for new default syntaxes?  For instance, you could have 
>> something like
>> asm(intel) or asm(gas) or asm(arm) or asm(hal).  That way somebody could
>> progromatically decide the base style of the assembly syntax they were 
>> going to
>> use.  It doesn't seem to be internally inconsistent, as virtually all 
>> assembler
>> code should be written in 'version' tags anyway, as I see it.
> 
> 
> Very time consuming - you'd have to write whole new assemblers.
> 

You don't have to implement any of it, this could be a syntactic sugar.

for example,
asm(intel)
{
...
}

would be a shortcut for
version(intel)
{
asm
{
....
}
}
July 13, 2006
Re: ASM extensions
Hasan Aljudy wrote:
> 
> 
> Walter Bright wrote:
> 
>> Gabe wrote:
>>
>>> How difficult would it be to alter the inline assembler to accept 
>>> paramter
>>> arguments for new default syntaxes?  For instance, you could have 
>>> something like
>>> asm(intel) or asm(gas) or asm(arm) or asm(hal).  That way somebody could
>>> progromatically decide the base style of the assembly syntax they 
>>> were going to
>>> use.  It doesn't seem to be internally inconsistent, as virtually all 
>>> assembler
>>> code should be written in 'version' tags anyway, as I see it.
>>
>>
>>
>> Very time consuming - you'd have to write whole new assemblers.
>>
> 
> You don't have to implement any of it, this could be a syntactic sugar.
> 
> for example,
> asm(intel)
> {
> ....
> }
> 
> would be a shortcut for
> version(intel)
> {
> asm
> {
> .....
> }
> }

Maybe you're missing the fact that DMD has to understand Intel-style ASM 
syntax so that it may process it correctly for the real assembler...

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/MU/S d-pu s:+ a-->? C++++$ UL+++ P--- L+++ !E W-- N++ o? K? w--- O 
M--@ V? PS PE Y+ PGP- t+ 5 X+ !R tv-->!tv b- DI++(+) D++ G e++>e 
h>--->++ r+++ y+++
------END GEEK CODE BLOCK------

James Dunne
July 13, 2006
Re: ASM extensions
James Dunne wrote:
> Hasan Aljudy wrote:
[...]
>>
>> You don't have to implement any of it, this could be a syntactic sugar.
>>
>> for example,
>> asm(intel)
>> {
>> ....
>> }
>>
>> would be a shortcut for
>> version(intel)
>> {
>> asm
>> {
>> .....
>> }
>> }
> 
> 
> Maybe you're missing the fact that DMD has to understand Intel-style ASM 
> syntax so that it may process it correctly for the real assembler...
> 

DMD already has to be able to parse the ASM enough to find the end of 
the block. Consider:

version(intel)
{
asm
{
.....
}
}
version(arm)
{
asm
{
.....
}
}

Regardless of the compiler, to correctly find the end of the version, it 
needs to find the end of the asm. The suggested addition would only 
requirer DMD to be able to ignore contents of the "wrong" asm block, 
e.i. correctly find the closing "}" (as it already needs to).

That said I have not used asm in D so, this is all of no use to me.
July 14, 2006
Re: ASM extensions
BCS wrote:
> James Dunne wrote:
> 
>> Hasan Aljudy wrote:
> 
> [...]
> 
>>>
>>> You don't have to implement any of it, this could be a syntactic sugar.
>>>
>>> for example,
>>> asm(intel)
>>> {
>>> ....
>>> }
>>>
>>> would be a shortcut for
>>> version(intel)
>>> {
>>> asm
>>> {
>>> .....
>>> }
>>> }
>>
>>
>>
>> Maybe you're missing the fact that DMD has to understand Intel-style 
>> ASM syntax so that it may process it correctly for the real assembler...
>>
> 
> DMD already has to be able to parse the ASM enough to find the end of 
> the block. Consider:
> 
> version(intel)
> {
> asm
> {
> ......
> }
> }
> version(arm)
> {
> asm
> {
> ......
> }
> }
> 
> Regardless of the compiler, to correctly find the end of the version, it 
> needs to find the end of the asm. The suggested addition would only 
> requirer DMD to be able to ignore contents of the "wrong" asm block, 
> e.i. correctly find the closing "}" (as it already needs to).
> 
> That said I have not used asm in D so, this is all of no use to me.

version blocks need to be syntactially valid code.  They're not like the 
C preprocessor's #if..#endif blocks.

If one of these ASM syntaxes involves the use of curly braces, then 
finding the true end curly brace of the asm {} block itself might be 
difficult without understanding the ASM syntax itself.

-- 
Regards,
James Dunne
July 14, 2006
Re: ASM extensions
James Dunne wrote:
> BCS wrote:
> 
>> James Dunne wrote:
>>
>>> Hasan Aljudy wrote:
>>
>>
>> [...]
>>
>>>>
>>>> You don't have to implement any of it, this could be a syntactic sugar.
>>>>
>>>> for example,
>>>> asm(intel)
>>>> {
>>>> ....
>>>> }
>>>>
>>>> would be a shortcut for
>>>> version(intel)
>>>> {
>>>> asm
>>>> {
>>>> .....
>>>> }
>>>> }
>>>
>>>
>>>
>>>
>>> Maybe you're missing the fact that DMD has to understand Intel-style 
>>> ASM syntax so that it may process it correctly for the real assembler...
>>>
>>
>> DMD already has to be able to parse the ASM enough to find the end of 
>> the block. Consider:
>>
>> version(intel)
>> {
>> asm
>> {
>> ......
>> }
>> }
>> version(arm)
>> {
>> asm
>> {
>> ......
>> }
>> }
>>
>> Regardless of the compiler, to correctly find the end of the version, 
>> it needs to find the end of the asm. The suggested addition would only 
>> requirer DMD to be able to ignore contents of the "wrong" asm block, 
>> e.i. correctly find the closing "}" (as it already needs to).
>>
>> That said I have not used asm in D so, this is all of no use to me.
> 
> 
> version blocks need to be syntactially valid code.  They're not like the 
> C preprocessor's #if..#endif blocks.
> 
> If one of these ASM syntaxes involves the use of curly braces, then 
> finding the true end curly brace of the asm {} block itself might be 
> difficult without understanding the ASM syntax itself.

Actually it wouldn't, because the curly braces in _any_ syntax come in 
pairs. ;-)

But that fact alone doesn't help the real issue.
July 14, 2006
Re: ASM extensions
Georg Wrede wrote:
>> version blocks need to be syntactially valid code.  They're not like 
>> the C preprocessor's #if..#endif blocks.
>>
>> If one of these ASM syntaxes involves the use of curly braces, then 
>> finding the true end curly brace of the asm {} block itself might be 
>> difficult without understanding the ASM syntax itself.
> 
> Actually it wouldn't, because the curly braces in _any_ syntax come in 
> pairs. ;-)
> 
> But that fact alone doesn't help the real issue.

Their are some constraints on the asm syntax in order to support the D 
lexer and the version/debug statements.

But supporting the same CPU with multiple asm syntaxes just seems to be 
burdensome without much benefit.
July 18, 2006
Re: ASM extensions
Georg Wrede wrote:
> 
> 
> James Dunne wrote:
> 
>> BCS wrote:
>>
>>> James Dunne wrote:
>>>
>>>> Hasan Aljudy wrote:
>>>
>>>
>>>
>>> [...]
>>>
>>>>>
>>>>> You don't have to implement any of it, this could be a syntactic 
>>>>> sugar.
>>>>>
>>>>> for example,
>>>>> asm(intel)
>>>>> {
>>>>> ....
>>>>> }
>>>>>
>>>>> would be a shortcut for
>>>>> version(intel)
>>>>> {
>>>>> asm
>>>>> {
>>>>> .....
>>>>> }
>>>>> }
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Maybe you're missing the fact that DMD has to understand Intel-style 
>>>> ASM syntax so that it may process it correctly for the real 
>>>> assembler...
>>>>
>>>
>>> DMD already has to be able to parse the ASM enough to find the end of 
>>> the block. Consider:
>>>
>>> version(intel)
>>> {
>>> asm
>>> {
>>> ......
>>> }
>>> }
>>> version(arm)
>>> {
>>> asm
>>> {
>>> ......
>>> }
>>> }
>>>
>>> Regardless of the compiler, to correctly find the end of the version, 
>>> it needs to find the end of the asm. The suggested addition would 
>>> only requirer DMD to be able to ignore contents of the "wrong" asm 
>>> block, e.i. correctly find the closing "}" (as it already needs to).
>>>
>>> That said I have not used asm in D so, this is all of no use to me.
>>
>>
>>
>> version blocks need to be syntactially valid code.  They're not like 
>> the C preprocessor's #if..#endif blocks.
>>
>> If one of these ASM syntaxes involves the use of curly braces, then 
>> finding the true end curly brace of the asm {} block itself might be 
>> difficult without understanding the ASM syntax itself.
> 
> 
> Actually it wouldn't, because the curly braces in _any_ syntax come in 
> pairs. ;-)
> 
> But that fact alone doesn't help the real issue.

Not if the curlies are in comments that don't take a form that D is 
familiar with (such as those starting with -- or semicolon).  In 
comments, all bets are off.

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/MU/S d-pu s:+ a-->? C++++$ UL+++ P--- L+++ !E W-- N++ o? K? w--- O 
M--@ V? PS PE Y+ PGP- t+ 5 X+ !R tv-->!tv b- DI++(+) D++ G e++>e 
h>--->++ r+++ y+++
------END GEEK CODE BLOCK------

James Dunne
July 18, 2006
Re: ASM extensions
James Dunne wrote:
> Georg Wrede wrote:
>>
>>
>> James Dunne wrote:
>>
>>> BCS wrote:

[snip]

>>> If one of these ASM syntaxes involves the use of curly braces, then 
>>> finding the true end curly brace of the asm {} block itself might be 
>>> difficult without understanding the ASM syntax itself.
>>
>>
>> Actually it wouldn't, because the curly braces in _any_ syntax come in 
>> pairs. ;-)
>>
>> But that fact alone doesn't help the real issue.
> 
> Not if the curlies are in comments that don't take a form that D is 
> familiar with (such as those starting with -- or semicolon).  In 
> comments, all bets are off.
> 

http://www.digitalmars.com/d/statement.html#asm says the following:

     The format of the instructions is, of course, highly dependent on
     the native instruction set of the target CPU, and so is
     implementation defined. But, the format will follow the following
     conventions:

        * It must use the same tokens as the D language uses.
        * The comment form must match the D language comments.
        * Asm instructions are terminated by a ;, not by an end of
          line.

    These rules exist to ensure that D source code can be tokenized
    independently of syntactic or semantic analysis.

Note the second requirement: the asm syntax must use D comment syntax.
Curiously, it doesn't mention braces though. A small oversight maybe?
Top | Discussion index | About this forum | D home