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

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)?

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

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

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.

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

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.

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.

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.

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?