System programming in D (Was: The God Language)

[Iain Buclaw]

On 9 January 2012 22:28, Artur Skawina <art.08.09 at gmail.com> wrote:
> On 01/09/12 20:05, Iain Buclaw wrote:
>> On 9 January 2012 18:15, Artur Skawina <art.08.09 at 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';