On Thursday, 12 December 2013 at 20:46:26 UTC, Walter Bright wrote:
> 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.

You know that it is not likely to ever be a priority. That's what will happen: lots of code will be written, using the peculiarities of each implementation. And then nobody will want to change the status quo becase "it will break lots of code".

On Thursday, 12 December 2013 at 09:01:17 UTC, Paulo Pinto wrote:
> On Thursday, 12 December 2013 at 02:12:00 UTC, ed wrote:
>> On Wednesday, 11 December 2013 at 03:33:47 UTC, Walter Bright wrote:
>> [snip]
>>
>>>>> The issue is convenience of writing C code in D vs C.
>>>>
>>>> So you're trying to say that it's easier to write C code in D, rather
>>>> than in C?
>>>>
>>>> I thought this thread was about the inherent advantages of D over C.
>>>
>>> I was referring specifically to Dicebot's post as ancestor:
>>>
>> [snip]
>>
>> I am finding C is much easier and more pleasant to write with DMD.
>>
>> At work we're forced, under duress, to write C. I just got a new project with a loose deadline so I thought I'd do a crazy experiment to make it interesting...
>> (NOTE: I say "under duress" but I secretly like C/C++, especially C++11/14.)
>>
>> I'm writing my C code with DMD. When tested and tweaked I do a final compile with C compiler (test once more) then commit for our QA to pick up.  Occasionally I'll compile with the C compiler to ensure I haven't leaked any D into the code and to minimise the #include fixups at the end.
>>
>> Currently this is about 20 C-(D) files with approx. 12,000-15,000 LOC. I doubt this workflow would scale much further, although it doesn't look like becoming an issue yet.
>>
>> My experiment is a success IMO. My C code is much cleaner, safer and more maintainable because of it. Yes, I know I could write C like this without DMD ... but I'm lazy and fall back into bad C habits :-)
>>
>> I now advocate that students should be taught C programming with the DMD compiler :D
>>
>>
>> Cheers,
>> Ed
>
> Currently I always advocate that C and C++ development should
> always be done with warnings as errors enabled, coupled with
> static analyzers at very least during CI builds, breaking them if
> anything is found.
>
> Nice story though, thanks for sharing.
>
> --
> Paulo

I agree 100% and do so with my real D code also.

While it was a fun experiment I really don't believe think this workflow could ever replace good static analysis tools.

Cheers,
Ed

On 13 December 2013 06:08, H. S. Teoh <hsteoh@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)

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

> On 13 December 2013 06:08, H. S. Teoh <hsteoh@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
}

Am 12.12.2013 21:16, schrieb Max Samukha:
> 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?

like freepascal got support for x86 and ARM inline asm (and others) for years?

"Manu" <turkeyman@gmail.com> wrote in message news:mailman.513.1386905921.3242.digitalmars-d@puremagic.com...
>
> 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)
>

meh

version(x86) asm
{
}
else version(ARM) asm
{
}
else
...

On 13 December 2013 15:39, Daniel Murphy <yebblies@nospamgmail.com> wrote:

> "Manu" <turkeyman@gmail.com> wrote in message news:mailman.513.1386905921.3242.digitalmars-d@puremagic.com...
> >
> > 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)
> >
>
> meh
>
> version(x86) asm
> {
> }
> else version(ARM) asm
> {
> }
> else
> ...
>

Haha, okay. Good point.
I never think of version statements like that for some reason.
Mental throwback to #define perhaps, which requires it's own line >_<

On 12.12.2013 19:46, Adam D. Ruppe wrote:
> On Thursday, 12 December 2013 at 17:56:12 UTC, Walter Bright wrote:
>> 5. thread local storage
>
> I think this is a negative. D's TLS has caused me more problems than it
> has fixed: for example, if you write an in-process COM server in Windows
> XP, it will crash the host application if you hit almost any druntime
> call. Why? Because the TLS stuff isn't set up properly when the dll is
> loaded.
>
> Windows Vista managed to fix this, but there's a lot of people who use
> XP, and this is a big problem.

Implicite TLS in XP-DLLs has a workaround in druntime for a few years now (emulating it for the system). IIRC Denis has even found a solution how to unload these DLLs later.

It's great to have thread local data easily available, but I'm not completely sold on thread-local by default, too. One disadvantage is that both memory and initialization code affect any thread, even if it does not use TLS at all. This doesn't scale for large programs.

Usually you should not create a lot of global variables, and if I do, I mostly want them shared. But coming from C++ I often tend to forget to add the modifier. I remember a few years ago, almost every occurrence of TLS in phobos was converted to shared or immutable...

Am Thu, 12 Dec 2013 12:46:26 -0800
schrieb Walter Bright <newshound2@digitalmars.com>:

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

It's not just that. I found that some discussion and work is necessary about these issues, if D is ever going to have a standard inline assembly language:

* GCC would have to support naked functions on x86/amd64 or DMD
  drop the keyword.
* DMD would have to adapt extended inline assembly expressions
  or the GDC/LDC "downgrade" to basic inline assembly.

A "downgrade" needs good arguments though. Not only did D evolve over C, but the same is true for inline assembly. From http://wiki.dlang.org/LDC_inline_assembly_expressions:

  Being an expression, extended inline expressions are able to
  return values!

  Additionally issues regarding inlining of function containing
  inline asm are mostly not relevant for extended inline assembly
  expressions. Effectively, extended inline assembly expression
  can be used to efficiently implement new intrinsics in the
  compiler.

-- 
Marco

On Friday, 13 December 2013 at 13:57:09 UTC, Marco Leise wrote:
> Am Thu, 12 Dec 2013 12:46:26 -0800
> schrieb Walter Bright <newshound2@digitalmars.com>:
>
>> 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.
>
> It's not just that. I found that some discussion and work is
> necessary about these issues, if D is ever going to have a
> standard inline assembly language:
>
> * GCC would have to support naked functions on x86/amd64 or DMD
>   drop the keyword.
> * DMD would have to adapt extended inline assembly expressions
>   or the GDC/LDC "downgrade" to basic inline assembly.
>
> A "downgrade" needs good arguments though. Not only did D
> evolve over C, but the same is true for inline assembly. From
> http://wiki.dlang.org/LDC_inline_assembly_expressions:
>
>   Being an expression, extended inline expressions are able to
>   return values!
>
>   Additionally issues regarding inlining of function containing
>   inline asm are mostly not relevant for extended inline assembly
>   expressions. Effectively, extended inline assembly expression
>   can be used to efficiently implement new intrinsics in the
>   compiler.


Maybe the best way to fix this issue is to follow what other
language standards do (C++, Ada) and only define that inline
assembly is possible and how the entry point, e.g. asm () looks
like.

The real inline assembly syntax is then left implementation
specific.


--
Paulo