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

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.

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
{
....
}
}

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

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.

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

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.

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.

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

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?