Recent changes to GDC.
Iain Buclaw
ibuclaw at ubuntu.com
Mon Jan 16 15:21:29 PST 2012
On 16 January 2012 23:08, Artur Skawina <art.08.09 at gmail.com> wrote:
> On 01/16/12 21:49, Iain Buclaw wrote:
>> On 16 January 2012 19:14, Artur Skawina <art.08.09 at gmail.com> wrote:
>>> On 01/16/12 17:43, Iain Buclaw wrote:
>>>> On 16 January 2012 14:41, Artur Skawina <art.08.09 at gmail.com> wrote:
>>>>> On 01/15/12 23:34, Iain Buclaw wrote:
>>>>>> * Merged in the work Walter has done for __vector type support. There are now newly available GCC builtins for vector operations via gcc.builtins module.
>>>>>
>>>>> Allowing !=128 bits wide types would be just a matter of removing the frontend
>>>>> restrictions, right? (i didn't look at the latest commits, maybe you already did
>>>>> that)
>>>>> As the vector ops often will need to be wrapped, lack of cross module function
>>>>> inlining is a problem.
>>>>>
>>>>
>>>> If you want cross-module inlining, compile all sources in one command.
>>>>
>>>> gdc file1.d file2.d -o myapp
>>>
>>> Does this work for '-c' too? For building libs, like eg phobos?
>>>
>>> Hmm, '-fonly" seems like it could work, together with '-c' -- I have never
>>> used that option, will have to try it later - but if it works, shouldn't it
>>> be on by default (for '-[cS]' invocations)?
>>>
>>
>> It won't. For inlining to work, the function body (that is available
>> at compile-time in DMDFE AST) needs to be converted into GCC trees for
>> the backend to inline. -fonly, whilst it processes the semantic
>> analysis on the other modules, does not generate any codegen for them.
>> For cross module inlining to properly work in the one-file-at-a-time
>> compilation method, there needs to be an intermediate routine that
>> says 'build this body now, but don't add the function to the global to
>> output list'.
>
> I guess treating the functions like C "extern inline"'s isn't possible?
>
>
Like gnu_inline? It will have to be implemented.
>>> BTW, is the GDC exception handling compatible with C++?
>>
>> It's practically rewrite of the C++ exception routine in D. But don't
>> quote me on it being directly compatible.
>
> Hmm, i was looking for more incompatibilities, but i guess expecting to
> directly throw/catch D exceptions from C++ (and v/v) is a bit too much. :)
>
>
Yes, that is. I can't find the file at the moment, but if you were to
compare the two (C++ exception handling and D exception handling) -
you can easily point two fingers between which functions correlate to
which.
>>>> What makes you think changing the calling convention will turn off
>>>> name mangling?
>>>
>>> My point is that modifying the ABI has a significant cost and can't easily
>>> be undone. I don't see much gain from switching from one nonstd convention
>>> to a different nonstd convention, which is /similar/ to the C one, but still
>>> not directly accessible from C.
>>> What does your change mean? Programs now use a worse calling convention (not
>>> even one arg gets passed in a register), object files and libraries generated
>>> by different D compilers are incompatible (by design, not just because of some
>>> implementation quirk), worse, mixing libs produced by different toolchains may
>>> seem to work, only to fail at runtime. Where's the gain?
>>>
>>
>> 1. My point is that modifying the ABI has a significant cost and
>> can't easily be undone. I don't see much gain from switching from one
>> nonstd convention to a different nonstd convention, which is /similar/
>> to the C one, but still not directly accessible from C.
>>
>> A calling convention that is used by the target platform is better
>> than a calling convention that is used by no one but yourself. Also,
>> I don't see how name mangling is part of the calling convention, but
>> maybe that's just me (I am aware that name mangling is part of various
>> Windows calling conventions, but not in *nix. :-)
>
> It isn't, but if you can't (easily) call the "D" code from C/C++
> it might as well be.
> If you need proper annotations at every language border crossing,
> what advantage does using the same calling convention give you?..
>
>
>> 2. What does your change mean? Programs now use a worse calling
>> convention (not even one arg gets passed in a register),
>>
>> *cough* for x86 *cough*
>>
>> I can't see how you can use this as an argument. Parameter passing
>> hasn't changed for x86, only the way certain values are returned. So
>> it is *still* as bad as it was *before* the change.
>
> So gdc didn't implement the official (dlang.org) convention, and i was
> fooled by LTO? :)
>
>
x86 does implicitly turn on regparm when compiling with -O for local
functions only.
>> 3. object files and libraries generated by different D compilers are
>> incompatible (by design, not just because of some implementation
>> quirk), worse, mixing libs produced by different toolchains may seem
>> to work, only to fail at runtime. Where's the gain?
>>
>> It has always been this way. I've never known people to frequently mix
>> compilers when building code.
>
> Shared libraries. Distributions, such as Ubuntu. Does every OS vendor
> have to provide different packages for different D "stacks"? Every D
> library will come in a DMD version, GDC version and a LDC version? Or
> will just one compiler be picked, because the alternative isn't really
> acceptable? Note the former also means packaging every application
> using *any* D shared library (and i guess this can include phobos) N
> times. Let's hope nobody else decides to make a D compiler. :)
>
>
>>>>>> * "naked" has now been implemented now as a function attribute of the x86 platform. It is applied to all naked functions, and implies noinline and noclone.
>>>>>
>>>>> I've never really understood the reason for "naked". Custom prologue and epilogue
>>>>> could be useful sometimes, but turning the compiler into an assembler?... You can
>>>>> already write "naked" asm functions in gcc - with asm()s outside of functions
>>>>> plus some as(1) section push/pop magic, iirc.
>>>>> Now you've removed the D builtin assembler, but decided to introduce "naked".
>>>>> Is it really necessary? There are no back-compat concerns...
>>>>> How does naked work will the various gcc features the modify prologue (profiling,
>>>>> stack usage checking, forced stack aligment etc)?
>>>>>
>>>>
>>>> I have not removed the D builtin assembler. I have just removed
>>>> D_InlineAsm version identifers. GDC's "naked" function support was
>>>> originally a (pretty bad) hack in GCC. It is now implemented cleanly
>>>> as a function attribute, and does not affect the code generation of
>>>> other frontends.
>>>
>>> I meant something like "practically removed the availability of D builtin
>>> assembler by removing the guarding version identifiers", sorry.
>>> But doesn't this mean that, right now, there are exactly zero users of this
>>> feature (gcc naked functions)?..
>
>> There is naked support for other architectures that have been accepted
>> in GCC (arm, avr, m68k, mcore, rx, spu) - yes I had to look them up.
>> :-)
>
> I meant "zero D users". :^)
>
> And was wondering if introducing something D-related that nobody was
> using made sense. I admit to *not* checking if some arch already had it. :)
>
> artur
naked functions are used by D programmers. Last example I can think of
off the top of my head I aided were two OS developers writing a kernel
in D.
--
Iain Buclaw
*(p < e ? p++ : p) = (c & 0x0f) + '0';
More information about the D.gnu
mailing list