Bits rotations

[Iain Buclaw]

On 18 October 2012 15:22, Don Clugston <dac at nospam.com> wrote:
> 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.
>

Normal assembler... naked assembler has its own set of problems
(requires patching in a "naked" style attribute which the x86 GCC
maintainers rejected outrightly).


-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';