On 01/16/12 21:49, Iain Buclaw wrote: > On 16 January 2012 19:14, Artur Skawina <art.08...@gmail.com> wrote: >> On 01/16/12 17:43, Iain Buclaw wrote: >>> On 16 January 2012 14:41, Artur Skawina <art.08...@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? >> 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. :) >>> 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? :) > 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
