Go compiler moving from C to Go

[Iain Buclaw]

On 21 December 2013 06:26, Paulo Pinto <pjmlp at progtools.org> wrote:
> On 20.12.2013 22:05, Jacob Carlborg wrote:
>>
>> On 2013-12-20 08:03, Paulo Pinto wrote:
>>
>>> Even though I rather use D than Go, every time I read that, I am tempted
>>> to prove people wrong. If I had the time for it, that is.
>>>
>>> Go offers the same mechanisms for systems programming as Oberon does. If
>>> ETHZ was able to create Native Oberon, AOS and EthOS with Oberon, why
>>> cannot one do an OS with Go?
>>
>>
>> When developing an OS, for somethings these languages are not enough,
>> including C, Go and D. You need to use assembly. D has the advantage of
>> supporting inline assembly.
>>

While useful the ability to write inline assembler functions, DMD
can't inline these around the place. So you get all the benefits of
being able to shortcut the fastest route to do X, but with the
slowdown of 25% because there's a big elephant in the room.


>
> Until all D compilers provide the same support for inline assembly, it is
> better we don't use that as language feature.
>

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.  The same can be said for other (very)
low-level details, such as va_list type and va_arg functions,
low-level x86 intrinsics (inp, outp, y2lx...), and that
core.simd.__simd thingy.

x86-specific and x86-centric are implied on all DMD's features mentioned above.

Iain.