www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - ASM extensions

reply Gabe <Gabe_member pathlink.com> writes:
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
Jul 12 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
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.
Jul 12 2006
parent reply Hasan Aljudy <hasan.aljudy gmail.com> writes:
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
{
....
}
}
Jul 13 2006
parent reply James Dunne <james.jdunne gmail.com> writes:
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
Jul 13 2006
parent reply BCS <BCS pathlink.com> writes:
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.
Jul 13 2006
parent reply James Dunne <james.jdunne gmail.com> writes:
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
Jul 13 2006
parent reply Georg Wrede <georg.wrede nospam.org> writes:
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.
Jul 13 2006
next sibling parent Walter Bright <newshound digitalmars.com> writes:
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.
Jul 14 2006
prev sibling parent reply James Dunne <james.jdunne gmail.com> writes:
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
Jul 18 2006
parent Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
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?
Jul 18 2006