Am Fri, 13 Dec 2013 09:34:17 -0800
schrieb "H. S. Teoh" <hsteoh@quickfur.ath.cx>:

> On Fri, Dec 13, 2013 at 03:30:21PM +0100, Paulo Pinto wrote: [...]
> > 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.
> 
> But isn't this what Walter was arguing against? He wanted to standardize inline assembly syntax for x86 because leaving it up to implementation resulted in the current mess of Intel syntax vs. GNU syntax (which can be extremely confusing if you're not well-versed in both syntaxes, since the order of operands are swapped and there are some subtle notational differences).
> 
> 
> T

I for one am in favor of not having to write an ASM function 6 times for x86/amd64 * dmd/ldc/gdc. Before that happens I write a mixin generator that translates takes a string of ASM instructions and converts it to all three syntaxes at once.

-- 
Marco

On 12/13/2013 9:01 AM, Manu wrote:
> We really do need __forceinline. Walter did agreed on one occasion. He said
> something like "I've been thinking on it, and I think you might be right", which
> is almost a mental commitment... so there's hope! :P
> Sadly it was in a hotel parking lot, and not committed to the eternal historic
> record (ie, the forum).

Yes, I remember, and you did convince me!

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.

LDC in fact implements DMD-style inline assembly (occasionally there are bugs, though, as it's a complete reimplementation).

I don't think it would be unreasonable to work towards a common D ABI on the various Posix x86_64 systems, but given that DMD comes with its own bespoke exception handling implementation which doesn't really make sense to implement in GDC/LDC (as libunwind is the platform standard on Linux/… anyway), there is not really much motivation to start work on aligning the other parts of the ABI either.

David

13-Dec-2013 22:29, Walter Bright пишет:
> On 12/13/2013 9:01 AM, Manu wrote:
>> We really do need __forceinline. Walter did agreed on one occasion. He
>> said
>> something like "I've been thinking on it, and I think you might be
>> right", which
>> is almost a mental commitment... so there's hope! :P
>> Sadly it was in a hotel parking lot, and not committed to the eternal
>> historic
>> record (ie, the forum).
>
> Yes, I remember, and you did convince me!

Yay!

-- 
Dmitry Olshansky

On Friday, 13 December 2013 at 19:07:47 UTC, David Nadlinger wrote:
> 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.
>
> LDC in fact implements DMD-style inline assembly (occasionally there are bugs, though, as it's a complete reimplementation).
>
> I don't think it would be unreasonable to work towards a common D ABI on the various Posix x86_64 systems, but given that DMD comes with its own bespoke exception handling implementation which doesn't really make sense to implement in GDC/LDC (as libunwind is the platform standard on Linux/… anyway), there is not really much motivation to start work on aligning the other parts of the ABI either.
>
> David

I'm reinventing it right now for SDC, so it indeed make sense.

On 12/13/2013 6:52 AM, Dicebot wrote:
>> 1. compile speed
>
> Only partially true. Large projects need separate compilation and D does not
> behave that good in such scenario. Still better than C, but not good enough to
> make a difference.

Doesn't behave that good how?


>> 2. dependable sizes of basic types
> Not a real issue as your platform SDK always includes some kind of "stdint.h"

I've been around C code long enough to know it is a real issue. (Few programmers ever use stdint.h, and usually use it incorrectly when they do. Furthermore, those types aren't used by the C standard library, and are only very rarely used by 3rd party C libs. You cannot get away from this problem. It's made even worse because C will silently truncate integers to fit.)

>> 3. unicode
>
> Number one my list of advantages. Does not apply to plenty of projects though.

It applies more than you might think. Most D apps will be inherently unicode correct. Very, very few C programs are unless the programmer went to some effort to make it so. And, take a look at all those miserable UNICODE macros in windows.h.


>> 4. wchar_t that is actually usable
>
> Same as (3)

Almost nobody uses wchar_t in C code because it is unusable. Windows uses it for the "W" api functions, but surrogate pairs are broken in just about every C program, because C has no idea what a surrogate pair is. Furthermore, you're just fscked if you try to port wchar_t code from Windows to Linux, you're looking at line-by-line rewrite of all of that code.


>> 5. thread local storage
> It is lot of pain and source of problems, not advantage. Extra work to hack the
> druntime to get stuff working on barebone.

Making druntime work properly is not a problem for user programming. Most C programs care naught for global shared data, that is, until they try to multithread it. Then it's disasterville.


>> 6. no global errno being set by the math library functions
> This has made me smile :) It shows how different applications we have in mind
> speaking about "C domain".

Do you mean people don't do math in C apps?

>> 7. proper IEEE 754 floating point
> Potentially useful but largely mitigated by platform-specific development.

I suspect you haven't written serious FP apps. I have, and C's erratic and crappy support for FP is a serious problem. It's so bad that D's math libraries have gradually transitioned towards having our own implementation rather than rely on C's standard library.


>> 8. no preprocessor madness
> Would have called this a feature if one could actually use something instead out
> of the box. But there is no way to control symbol visibility right now so
> templates / CTFE are often out of the toolset. And what to do without those?

I have no idea what your issue is here.


>> 9. modules
> Other than (1) it is also more a problem than help in current implementation -
> you need to care also about emitted ModuleInfo.

Why do you need to care about it?


>> 11. inline assembler being a part of the language rather than an extension
>> that is in a markedly different format for every compiler
> Not an issue. You almost always stick to specific compiler in barebone world
> (one adapted for your platform).

I've had to port C code from one platform to another and had to do complete rewrites of the inline asm, even though they were for the exact same CPU. This is not convenient.


>> 12. forward referencing (no need to declare everything twice)
> Not an issue. C programmers are not tired from typing.

C programs tend to be written "bottom up" to avoid forward references. This is not convenient.


>> 14. no ridonculous struct tag name space with all those silly
>>
>>     typedef struct S { ... } S;
>>
>> declarations.
>
> Nice but just a syntax sugar yet again.

The tag name space is not convenient.


>> 15. no need for precompiled headers
> Same as (9)

Do you seriously believe C precompiled headers are convenient? Have you ever used them?


>> 16. struct alignment as a language feature rather than an ugly extension kludge
> Same as (11)

Have you ever tried to port C code that uses alignment?


>> 17. no #include guard kludges
> OH MY GOD EXTRA <10 LINE OVERHEAD PER HEADER

Not convenient. It also tends to be sensitive to typos that won't be detected by the compiler, and the usual non-hygienic macro problem. I see those typos now and then in C code I run across.


>> 19. no need for global variables when qsorting
> Doesn't matter

Have you ever used qsort much? It is hardly convenient - you have to write a bunch of boilerplate to use it using global variables, and none of that will work if you've got multiple threads.


>> 20. no global locale madness
> (no idea what this means)

strtod's behavior (for example) is dependent on the current locale. The fact that you didn't know this is indicative of its problems. This is not the only locale-dependent behavior. C has a number of issues with global state.


>> And if you use D features even modestly, such as auto, purity, out variables,
>> @safe, const, etc., you can get a large improvement in clarity in function APIs.
> `auto` has no real value in C world

Going back to the integer type size issue and C's propensity to silently truncate integers makes it a very real issue.

---

Yes, you can work around all these issues, but they aren't convenient, which is what this thread is about. But much worse are the increased propensity for silent bugs identified here.

On 14 December 2013 04:29, Walter Bright <newshound2@digitalmars.com> wrote:

> On 12/13/2013 9:01 AM, Manu wrote:
>
>> We really do need __forceinline. Walter did agreed on one occasion. He
>> said
>> something like "I've been thinking on it, and I think you might be
>> right", which
>> is almost a mental commitment... so there's hope! :P
>> Sadly it was in a hotel parking lot, and not committed to the eternal
>> historic
>> record (ie, the forum).
>>
>
> Yes, I remember, and you did convince me!
>

*gasp*, it's on record!!
This is a good day! :P

On 12/13/13 11:07 AM, David Nadlinger wrote:
> 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.
>
> LDC in fact implements DMD-style inline assembly (occasionally there are bugs, though, as it's a
> complete reimplementation).
>
> I don't think it would be unreasonable to work towards a common D ABI on the various Posix x86_64
> systems, but given that DMD comes with its own bespoke exception handling implementation which
> doesn't really make sense to implement in GDC/LDC (as libunwind is the platform standard on Linux/…
> anyway), there is not really much motivation to start work on aligning the other parts of the ABI
> either.
>
> David

I think it's very important to work towards a common D ABI.  Even further, I believe it's important for druntime and phobos to be binary compatible between the compilers.  That dmd uses a different eh scheme is more a factor of Walter not understanding the standard linux c++ eh mechanism well enough to implement it and instead took the path of least resistance and wrote his own.  This is very correctable, just needs someone to do it.

On 12/13/2013 11:07 AM, David Nadlinger wrote:
> LDC in fact implements DMD-style inline assembly (occasionally there are bugs,
> though, as it's a complete reimplementation).

Thank you! That's awesome!

> I don't think it would be unreasonable to work towards a common D ABI on the
> various Posix x86_64 systems, but given that DMD comes with its own bespoke
> exception handling implementation which doesn't really make sense to implement
> in GDC/LDC (as libunwind is the platform standard on Linux/… anyway), there is
> not really much motivation to start work on aligning the other parts of the ABI
> either.

I agree that an ABI would be good to work towards. Brad's right about why dmd's EH is different.

On 12/13/2013 12:06 PM, deadalnix wrote:
> I'm reinventing it right now for SDC, so it indeed make sense.

Reinventing EH or inline asm?