GDC review process.

[Don Clugston]

On 20/06/12 13:04, Manu wrote:
> On 20 June 2012 13:51, Don Clugston <dac at nospam.com
> <mailto:dac at nospam.com>> wrote:
>
>     On 19/06/12 20:19, Iain Buclaw wrote:
>
>         Hi,
>
>         Had round one of the code review process, so I'm going to post
>         the main
>         issues here that most affect D users / the platforms they want
>         to run on
>         / the compiler version they want to use.
>
>
>
>         1) D Inline Asm and naked function support is raising far too
>         many alarm
>         bells. So would just be easier to remove it and avoid all the other
>         comments on why we need middle-end and backend headers in gdc.
>
>
>     You seem to be conflating a couple of unrelated issues here.
>     One is the calling convention. The other is inline asm.
>
>     Comments in the thread about "asm is mostly used for short things
>     which get inlined" leave me completely baffled, as it is completely
>     wrong.
>
>     There are two uses for asm, and they are very different:
>     (1) Functionality. This happens when there are gaps in the language,
>     and you get an abstraction inversion. You can address these with
>     intrinsics.
>     (2) Speed. High-speed, all-asm functions. These _always_ include a loop.
>
>
>     You seem to be focusing on (1), but case (2) is completely different.
>
>     Case (2) cannot be replaced with intrinsics. For example, you can't
>     write asm code using MSVC intrinsics (because the compiler rewrites
>     your code).
>     Currently, D is the best way to write (2). It is much, much better
>     than an external assembler.
>
>
> Case 1 has no alternative to inline asm. I've thrown out some crazy
> ideas to think about (but nobody seems to like them). I still think it
> could be addressed though.
>
> Case 2; I'm not convinced. These such long functions are the type I'm
> generally interested in aswell, and have the most experience with. But
> in my experience, they're almost always best written with intrinsics.
> If they're small enough to be inlined, then you can't afford not to use
> intrinsics. If they are truly big functions, then you begin to sacrifice
> readability and maintain-ability, and certainly limit the number of
> programmers that can maintain the code.

I don't agree with that. In the situations I'm used to, using intrinsics 
would not make it easier to read, and would definitely not make it 
easier to maintain. I find it inconceivable that somebody could 
understand the processor well enough to maintain the code, and yet not 
understand asm.

> I rarely fail to produce identical code with intrinsics to that which I
> would write with hand written asm. The flags are always the biggest
> challenge, as discussed prior in this thread. I think that could be
> addressed with better intrinsics.

Again, look at std.internal.math.BiguintX86. There are many cases there 
where you can swap two instructions, and the code will still produce the 
correct result, but it will be 30% slower.

I think that the SIMD case gives you a misleading impression, because on 
x86 they are very easy to schedule (they nearly all take the same number 
of cycles, etc). So it's not hard for the compiler to do a good job of it.