Bits rotations

[Don Clugston]

On 18/10/12 11:39, Iain Buclaw wrote:
> On 18 October 2012 09:27, bearophile <bearophileHUGS at lycos.com> wrote:
>> Iain Buclaw:
>>
>>
>>> In the gdc-4.6 package you have there, it's only naked asm that can't be
>>> inlined.
>>
>>
>> Good.
>>
>>
>>
>>> However it is worth noting that DIASM is no longer in mainline gdc.
>>
>>
>> What's DIASM? Is it the D syntax for asm code? If this is right, then gdc
>> developers have done a mistake, reducing D code interoperability, creating
>> an incompatibility where there wasn't (and reducing my desire to use gdc or
>> to switch to it, because I have hundreds of lines of inlined asm in my D
>> code), this means doing the opposite of what generally compiler writers are
>> supposed to do (maybe this topic was discussed already, in past).
>>
>> Bye,
>> bearophile
>
>
> This topic has been discussed in the past.  And the current status is
> that GCC mainline has poisoned the frontend to use certain headers
> that the IASM implementation in GDC depended on.
>
> Example:
>
> int zz(int p1)
> {
>    asm {
>      naked;
>      mov EAX, p1[EBP];
>    }
> }
>
>
> To calculate p1[EBP], one would have to know where p1 will land on the
> frame pointer to replace it with the relavant offset value.  This
> would mean from the front-end we would have to invoke the back-end to
> generate and tell us the stack frame layout of zz, which is not
> possible because:

FYI: That code doesn't work in DMD either.
DMD assumes a frame pointer is created in naked ASM, which is totally 
wrong. Code like that should not compile. The compiler does not know 
what the correct offsets are and should not attempt to try.

> a) Invoking this before the optimisation passes may produce a
> different result to what that actual result is after the optimisation
> passes.
> b) All functions are sitting in poisoned (for the front-end) headers.
>
> There is an opportunity to defer parsing IASM until the GIMPLE
> (middle-end) stage, however am still unable to retrieve the required
> information to produce the correct codegen.

Are you just talking about naked asm? Conceptually naked asm should act 
as if it was created in an assembler in a seperate obj file, and 
accessed via extern(C).
If you have problems with non-naked asm, that would make more sense to me.