On 25/04/12 17:05, Paulo Pinto wrote:
On Wednesday, 25 April 2012 at 14:32:13 UTC, Alex Rønne Petersen wrote:
On 25-04-2012 15:06, Kagamin wrote:
On Tuesday, 24 April 2012 at 10:29:52 UTC, Alex Rønne Petersen wrote:
The point is just that: Right now I can write assembly that will work
on GDC, LDC, and DMD on non-Windows. It will not work for DMD on
Windows. Something has to change here.

If it doesn't work on Windows, it should be versioned out. What we have:
http://dlang.org/version.html#PredefinedVersions - versions for LDC,
GDC, DMD and Windows - all what you want.

Yes, I added them. :)

You're missing the point. D is providing (or trying to provide) a
standard inline assembler, but calling conventions are not
standardized enough for it to be useful across compilers. If you're
writing inline assembly because you *have* to, you don't just "version
it out", you have to write different logic for different compilers,
which is a maintenance nightmare.

This is exactly what C++ gets blamed for, yet most people fail to
realize that the situation is common to all languages that generate
native code.

No, it's totally the fault of C++. C++ failed to specify it, so everyone did something different. Then you get this very unfortunate mindset where everyone is so used to it, they don't find it unacceptable any more.

The only reason it works out for C, is that the C ABI is actually the OS
ABI, as such all C compilers tend to have a common ABI.

Not true. The ABI for Win32 is __stdcall, not C. Pascal and Fortran calling conventions were always well standardized, too.

It would be nice if I could use D libraries without having to worry
which compiler was used to generate them.

Yes. This is mandatory.

It'd be fantastic if we had a calling convention that depended ONLY on the CPU, not on the OS. But I don't know if it is feasible. The Windows64 calling convention is standardized, and it's different to the Linux64 one.

I don't know if it's even possible to use a different calling convention on Win64, there are interactions with system exception handling.

Reply via email to