Inherent code performance advantages of D over C?

[Manu]

On 13 December 2013 13:38, Manu <turkeyman at gmail.com> wrote:

> On 13 December 2013 06:08, H. S. Teoh <hsteoh at quickfur.ath.cx> wrote:
>
>> On Thu, Dec 12, 2013 at 08:57:42PM +0100, Max Samukha wrote:
>> > On Thursday, 12 December 2013 at 17:56:12 UTC, Walter Bright wrote:
>> >
>> > >11. inline assembler being a part of the language rather than an
>> > >extension that is in a markedly different format for every
>> > >compiler
>> >
>> > Ahem. If we admit that x86 is not the only ISA in exsistence, then
>> > what is (under)specified here http://dlang.org/iasm.html is a
>> > platform-specific extension.
>>
>> I've always wondered about that. What is D supposed to do with asm
>> blocks when compiling for a CPU that *isn't* x86?? What *should* a
>> conforming compiler do? Translate x86 asm into the target CPU's
>> instructions?  Abort compilation? None of those options sound
>> particularly appealing to me.
>>
>
> It occurs to me that a little sugar would be nice, rather than:
>
> version(x86)
> {
>   asm
>   {
>     ...
>   }
> }
> else version(ARM)
> {
>   asm
>   {
>     ...
>   }
> }
>
> Which appears basically everywhere an asm block does. 'asm' could
> optionally receive an architecture as argument, and lower to the version
> wrapper:
>
> asm(x86)
> {
>   ...
> }
> else asm(ARM)
> {
>   ...
> }
>
> (The 'else's in those examples seem unnecessary)
>

The 'else' is useful:

asm(x86)
{
  ...
}
else asm(ARM)
{
  ...
}
else
{
  static assert("Unsupported architecture!");

  // or a fallback implementation
}
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20131213/6f66b92a/attachment.html>