GDC review process.

[deadalnix]

Le 20/06/2012 14:51, Manu a écrit :
> On 20 June 2012 14:44, Don Clugston <dac at nospam.com
> <mailto:dac at nospam.com>> wrote:
>
>     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>
>
>         <mailto: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.
>
>
> These functions of yours are 100% asm, that's not really what I would
> usually call 'inline asm'. That's really just 'asm' :)

You are being picky here.

Yes, this is 100% asm. But still, 100% asm is inline asm. It is asm 
within D code.