GDC review process.

[Manu]

On 20 June 2012 01:07, Walter Bright <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)
  * IA is difficult for the majority of programmers to follow/understand
  * even to experienced programmers, poorly commented asm takes a lot of
time to mentally parse

It's a shame that there are IA constructs that can't be expressed any other
way. I don't think it would take much to address that.


For example, consider this bit from druntime/src/rt/lifetime.d:
>

> ------------------------------**------------------------------**-------
>    auto isshared = ti.classinfo is TypeInfo_Shared.classinfo;
>    auto bic = !isshared ? __getBlkInfo((*p).ptr) : null;
>    auto info = bic ? *bic : gc_query((*p).ptr);
>    auto size = ti.next.tsize();
>    version (D_InlineAsm_X86)
>    {
>        size_t reqsize = void;
>
>        asm
>        {
>            mov EAX, newcapacity;
>            mul EAX, size;
>            mov reqsize, EAX;
>            jc  Loverflow;
>        }
>    }
>    else
>    {
>        size_t reqsize = size * newcapacity;
>
>        if (newcapacity > 0 && reqsize / newcapacity != size)
>            goto Loverflow;
>    }
>
>    // step 2, get the actual "allocated" size.  If the allocated size does
> not
>    // match what we expect, then we will need to reallocate anyways.
>
>    // TODO: this probably isn't correct for shared arrays
>    size_t curallocsize = void;
>    size_t curcapacity = void;
>    size_t offset = void;
>    size_t arraypad = void;
> ------------------------------**----------------
>

This one seems trivial, you just need one intrinsic:

  size_t reqsize = size * newcapacity;
  __jc(&Loverflow);

Although it depends on a '&codeLabel' mechanism to get the label address
(GCC supports this in C, I'd love to see this in D too).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20120620/53456897/attachment-0001.html>