GDC review process.

[Don Clugston]

On 20/06/12 00:55, Manu wrote:
> On 20 June 2012 01:07, Walter Bright <newshound2 at digitalmars.com
> <mailto:newshound2 at digitalmars.com>> wrote:
>
>     On 6/19/2012 1:58 PM, Manu wrote:
>
>         I find a thorough suite of architecture intrinsics are usually
>         the fastest and
>         cleanest way to the best possible code, although 'naked' may be
>         handy in this
>         circumstance too...
>
>
>     Do a grep for "naked" across the druntime library sources. For
>     example, its use in druntime/src/rt/alloca.d, where it is very much
>     needed, as alloca() is one of those "magic" functions.
>
>
> I never argued against naked... I agree it's mandatory.
>
>
>     Do a grep for "asm" across the druntime library sources. Can you
>     justify all of that with some other scheme?
>
>
> I think almost all the blocks I just browsed through could be easily
> written with nothing more than the register alias feature I suggested,
> and perhaps a couple of opcode intrinsics.
> And as a bonus, they would also be readable. I can imagine cases where
> the optimiser would have more freedom too.
>
>
>         Thinking more about the implications of removing the inline asm,
>         what would
>         REALLY roxors, would be a keyword to insist a variable is
>         represented by a
>         register, and by extension, to associate it with a specific
>         register:
>
>
>     This was a failure in C.
>
>
> Really? This is the missing link between mandatory asm blocks, and being
> able to do it in high level code with intrinsics.
> The 'register' keyword was similarly fail as 'inline'.. __forceinline
> was not fail, it is actually mandatory. I'd argue that __forceregister
> would be similarly useful in C aswell, but the real power would come
> from being able to specify the particular register to alias.
>
>         This would almost entirely eliminate the usefulness of an inline
>         assembler.
>         Better yet, this could use the 'new' attribute syntax, which
>         most agree will
>         support arguments:
>         @register(rsp) int x;
>
>
>     Some C compilers did have such pseudo-register abilities. It was a
>     failure in practice.
>
>
> Really? I've never seen that. What about it was fail?
>
>     I really don't understand preferring all these rather convoluted
>     enhancements to avoid something simple and straightforward like the
>     inline assembler. The use of IA in the D runtime library, for
>     example, has been quite successful.
>
>
> I agree, IA is useful and has been successful, but it has drawbacks too.
>    * IA ruins optimisation around the IA block
>    * IA doesn't inline well. intrinsics allow much greater opportunity
> for efficient integration into the calling context
>    * most IA functions are small, and prime candidates for inlining (see
> points 1 and 2)

You and I seem to be from different planets. I have almost never written 
as asm function which was suitable for inlining.

Take a look at std.internal.math.biguintX86.d

I do not know how to write that code without inline asm.