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
>> * GDC's default calling convention has now been switched back to that of the
>> default for the target platform.
>
> Hmm. You just invented a new ABI. "extern(D)" will mean different things to
> different compilers on the same platform. Only makes sense if you're sure to
> win the ABI war, and the other party to practically disappear.
I did not invent an ABI. extern(D) is only defined for the x86
platform - and it is no secret that only DMD adheres to it.
> This new ABI still isn't compatible with the default "C/C++" one, because of
> name mangling. (could it be made, at least partially, C++ compatible?)
> As you still cannot easily call D code from C, without the equivalent of
> "extern(D)", why not default to a more sane calling conventions, such as
> regparm on 32-bit x86?
The default calling convention is cdecl - this is directly ABI
compatible with C and C++ code with the exception to name mangling
requiring special treatment.
eg:
extern "C" int _Dmain(struct string args);
> GCC made a mistake years ago to not mangle the names when using a nonstd
> convention (eg by prepending '@' like some other compilers did) which
> resulted in this feature being unusable, other than for application-internal
> functions, as calling the wrong version will silently build and link, only to
> blow up at runtime; you also cannot place both versions in a library etc.
> Hence "fixing" this had to wait for a new architecture (x86_64) and whole
> program optimizations/LTO, which can figure out automatically when it's safe
> to switch to a more efficient convention.
>
What makes you think changing the calling convention will turn off
name mangling?
>> The D_InlineAsm family of version identifiers are now turned off by default
>> as we no longer pretend to follow DMD's calling convention. For those who
>> want to turn on D_InlineAsm(_X86/_x86_64) there is a -fd-inline-asm compiler
>> switch.
>
> Why is it a compiler option? Ie is it safe to turn it on (why optional then?)
> or will it result in wrong code being generated (why have the option then?).
> D_InlineAsm allowed things like the cpuid code to work, will every asm{} now
> need to be rewritten, or could a safe subset of the "D" asms be reused?
>
All Inline Asm code in Druntime and Phobos is written with the DMD
calling convention in mind, so ie: when one of the naked functions in
std.math pops the stack when returning a float, the caller won't clean
this in GDC generated code. Other than that, it works perfectly well
(tm).
>> * GDC will emit the GNU_InlineAsm version identifier to tell user code that
>> we support GNU Extended Inline Assembly.
>
> BTW, a identifier, which is set for *both* x86 and x86_64 would be good -
> because
> of how D's version() works and the fact that on those platforms the asm code
> will
> often be identical.
>
>> * All patches to GCC proper have now been removed, GDC can now build
>> applications without relying on changes to the backend, with the exception
>> of naked functions.
>>
>> * "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.
>> * D version 2 is now the default compiler to build.
>>
>>
>> I will get round to putting up a roadmap to GCC-4.8 sometime this week, and
>> I invite everyone interested in making this happen to get together and help
>> progress this. :)
>
> What's the plan wrt druntime and phobos? It would be good if both could stay
> completely out of gcc, just like libc. Would make contributions significantly
> easier (no copyright assignment...) and maybe even a common version could
> emerge.
>
> artur
I have no plans to remove libphobos or druntime from the compiler. I
will check licensing, but there should be no issues with including it.
--
Iain Buclaw
*(p < e ? p++ : p) = (c & 0x0f) + '0';
