On 18 October 2012 15:22, Don Clugston <[email protected]> wrote: > On 18/10/12 11:39, Iain Buclaw wrote: >> >> On 18 October 2012 09:27, bearophile <[email protected]> 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';
