December 12, 2013
On 12/12/2013 10:46 AM, Adam D. Ruppe wrote:
> I agree with the rest of them, but D's default TLS has been a big pain to me.

You're right that TLS on XP with DLLs is a miserable problem. Fortunately, with TLS now standard at least in C++, this problem is going away.

And, of course, you can use __gshared instead.
December 12, 2013
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.
December 12, 2013
On 12/12/2013 11:57 AM, 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 know of at least 3 different C x86 inline assembler syntaxes. This is not convenient, to say the least.
December 12, 2013
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.


T

-- 
Let's not fight disease by killing the patient. -- Sean 'Shaleh' Perry
December 12, 2013
On Thursday, 12 December 2013 at 20:06:37 UTC, Walter Bright wrote:
> On 12/12/2013 11:57 AM, 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 know of at least 3 different C x86 inline assembler syntaxes. This is not convenient, to say the least.

I know that too. I appreciate that you attempted to standardize the asm for x86. But the question is what to do about other targets? What about ARM, MIL, LLVM IR or whatever low-level target a D compiler may compile too? Will those be standardized as part of the language?
December 12, 2013
Am 12.12.2013 21:08, schrieb H. S. Teoh:
> 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.
>
>
> T
>


I already argued a few times here that although inline assembly seems convenient, I do favour the use of external macro assemblers.

There will always be some ISAs that are more special than others. So I rather have clean higher level code that drops out to assembly, that having version() for each processor and lack thereof.

So far I have only used dmd, but as far as I know both gdc and ldc don't follow the same asm syntax anyway.

--
Paulo

December 12, 2013
On 12/12/2013 12:16 PM, Max Samukha wrote:
> But the question is what to do about other targets? What about ARM, MIL, LLVM IR
> or whatever low-level target a D compiler may compile too? Will those be
> standardized as part of the language?

I certainly think they ought to be.
December 12, 2013
On 12/12/2013 12:08 PM, H. S. Teoh wrote:
> I've always wondered about that. What is D supposed to do with asm
> blocks when compiling for a CPU that *isn't* x86??

Give an error. asm blocks should be protected with version statements for the CPU type. The asm format should be what the CPU manufacturer lists as the format in their CPU data sheets.

December 12, 2013
On Thursday, 12 December 2013 at 20:24:19 UTC, Walter Bright wrote:
> On 12/12/2013 12:16 PM, Max Samukha wrote:
>> But the question is what to do about other targets? What about ARM, MIL, LLVM IR
>> or whatever low-level target a D compiler may compile too? Will those be
>> standardized as part of the language?
>
> I certainly think they ought to be.

Don't you find it somewhat alarming that both alternative compilers follow neither the standard inline asm nor ABI? Maybe it would be wiser to call those standard extentions or whatever than claiming they are part of the language?
December 12, 2013
On 12/12/2013 12:33 PM, Max Samukha wrote:
> Don't you find it somewhat alarming that both alternative compilers follow
> neither the standard inline asm nor ABI?

I find it unfortunate. But it also can be difficult and time consuming to reimplement an assembler for those back ends, so I can understand why it isn't a priority.