On 16 January 2012 23:08, Artur Skawina <[email protected]> wrote: > On 01/16/12 21:49, Iain Buclaw wrote: >> On 16 January 2012 19:14, Artur Skawina <[email protected]> wrote: >>> On 01/16/12 17:43, Iain Buclaw wrote: >>>> On 16 January 2012 14:41, Artur Skawina <[email protected]> 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';
