Go compiler moving from C to Go

[Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang at gmail.com>]

On Sunday, 22 December 2013 at 08:11:05 UTC, Russel Winder wrote:
> Historically, and anecdotally, I found that as soon as the 
> assembly
> language was a function, it was better as a separate entity,

Well, you can usually get what you want by first writing the code 
in C, then generate asm and optimize that by hand. So, being able 
to generate useful asm listings is more important than inlining, 
I think. In that respect I agree. I would much rather have the 
ability to generate tight and readable/auto-commented ASM than 
having inlining.

> that inline
> assembler only worked for accessing a processor instruction 
> that the
> code generator could not generate. So I think you are making 
> this same
> point, cf. SIMD instructions at the bleeding edge.

Well, yes, but if you are doing projects where you know the 
hardware and the hardware is specialized and limited (e.g. tiny 
amounts of RAM/ROM, no division/multiply, System on a Chip etc) 
it becomes a little bit more attractive to be able to do asm here 
and there: get the most out of flag-registers (like carry, 
overflow etc), run without an OS and write tight IRQ handlers. 
Like art-installations, small robots, embedded things? Granted, 
this is not something D is suitable for atm, but I hope it will 
move in that direction, eventually. I think it could become a hit.

Regarding bleeding edge: AFAIK, inlined asm is necessary if you 
want to benefit effectively from transactional memory in Haswell 
processors today, although it would be much much more convenient 
with language support. It is hard to get right, because there are 
cache-line restrictions (objects have a minimum/maximum size, so 
you have to group attributes that are to be protected into the 
same region). I think inline asm might be useful in a heavily 
optimized single-purpose server for that reason. But to 
conveniently benefit from that the compiler have to generate ASM 
that the CPU-vendor's assembler can parse and without 
restrictions on instructions unknown to the compiler (so you 
don't have to resort to injecting opcodes rather than mnemonics). 
If inline asm implies a built in assembler then I am not at all 
sure if it is all that useful.