Go compiler moving from C to Go

[Iain Buclaw]

On Dec 23, 2013 12:00 AM, "bearophile" <bearophileHUGS at lycos.com> wrote:
>
> Iain Buclaw:
>
>
>> That same support is never going to happen.  Not because of
>> disagreement, but because our backends are designed to work most
>> naturally in conflicting ways.
>
>
> I think this means that working to make DMD better is a good idea,
because every compiler has different strengths, like Walter says.
>
>

For inline assembly, making dmd work better how?

The problem with inline assembly is much more fundamental. DMD emits object
code, so it makes sense to have a full blown assembler built into it.  In
contrast, GDC emits assembly, and AT&T syntax at that, so having anything
other than GCC-style inline assembly support is just plain awkward.

>> and that core.simd.__simd thingy.
>
>
> What are the problems with that thing?
>

Not possible without some sort of translation map, which would be target
specific, so not suitable for GDC, and language specific so not suitable
for GCC either.

Also, falls under category of x86-centric below.

>
>> x86-specific and x86-centric are implied on all DMD's features mentioned
above.
>
>
> While the work to support other CPUs (and GPUs) is important, even at
Phobos/language level, x86 is still an important CPU, so the work to make
its support good is not wasted time :-)
>

Indeed, but just keep that support out of the language spec, as it only
serves to hurt progress, and leads to extreme conflicts in design (I don't
tend to show it, but I do take extreme pity that DMD has three interfaces
to va_arg - X86, X86_64, and Win64).

Regards
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20131223/5b680db1/attachment.html>