On 9 January 2012 22:28, Artur Skawina <art.08...@gmail.com> wrote: > On 01/09/12 20:05, Iain Buclaw wrote: >> On 9 January 2012 18:15, Artur Skawina <art.08...@gmail.com> wrote: >>> >>> [1] I guess omitting the frame pointer manipulation for (at least) just >>> nonthrowing leaf functions that don't use any stack slots wouldn't be easy? >>> (the vector extensions will probably make this even more important...) >> >> I think the tweaks I've made for extern(D) - frame pointer turned on >> unless naked - trumps all other checks for whether it is ok to omit >> frame pointer. For extern(C) at least for x86, the frame pointer is >> omitted by default as is the default for that particular backend. > > Didn't realize extern(C) would influence this, other than changing name > mangling and calling convention - will have to try it. I'm afraid it > could cause symbol collisions with the "real" C code (for wrappers). [1] > > The cases i'm worried about are things like virtual methods - imagine eg > a gui toolkit where every widget has certain properties (x,width,hidden etc) > which are implemented using getters, which in many cases should be just > "mov IMM, eax; ret" or "mov OFF(eax), eax; ret" -- this is what the C > compiler will emit; setting up the frame pointer just adds overhead and > inlining cannot help here. > SIMD code can have similar properties - only access data passed via > pointers, never calling other functions nor spilling. > >> Will need to fix the inline asm in phobos and druntime to be C calling >> convention friendly, then can drop all relevant attempts at matching >> the DMD calling convention. > > Do I understand correctly that you want to ignore the "official" D abi, > and go with an incompatible one, as a long term goal? That has downsides, > but as i think the "D ABI" will end up being changed and gdc is currently > not compatible anyway - maybe it's a reasonable option. > But gdc's D abi won't be fully compatible with the C one, right? Then, > avoiding some of C's mistakes would be a good idea (name mangling, > default to regparm etc) >
The mere mention that D required it's own ABI didn't go down too well, and to be honest, for the quirks I am currently addressing, I think there's another calling convention in GCC that may suit the bill... Naked function support for x86 has a chance of getting in without too much hassle. -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
