I started implementing the CPU version symbols: https://gist.github.com/4701086

It doesn't mirror the C++ macro structure as we usually don't have to overwrite the macro definitions for specific architectures. So the generic definitions are in the top level OS files which are used for every architecture. It's still possible to add architecture and OS specific versions, see e.g. Android or GDC_MinGW64.


As a next step I'd like to remove target-ver-syms.sh, but there's one problem: What to do about the TARGET_OSX,... preprocessor definitions? Should I change all of those to runtime variables? Also: Should extra code be added to the TARGET_OS_D_BUILTINS macros or could we just use findCondition to check if version(OSX) is set and then use that result?

On 3 February 2013 09:54, Johannes Pfau <nospam@example.com> wrote:

> I started implementing the CPU version symbols: https://gist.github.com/4701086
>
>
Nice. :-)




> It doesn't mirror the C++ macro structure as we usually don't have to overwrite the macro definitions for specific architectures. So the generic definitions are in the top level OS files which are used for every architecture. It's still possible to add architecture and OS specific versions, see e.g. Android or GDC_MinGW64.
>
>
>
Typically in the we've used GNU_xxx for identifiers specific to our compiler.  I would hint that the same convention should be used here too.



> As a next step I'd like to remove target-ver-syms.sh, but there's one problem: What to do about the TARGET_OSX,... preprocessor definitions? Should I change all of those to runtime variables? Also: Should extra code be added to the TARGET_OS_D_BUILTINS macros or could we just use findCondition to check if version(OSX) is set and then use that result?
>

A better way would be to remove all TARGET_ macros from the D frontend ( example: http://bit.ly/WSzRlk ) and pushing them into the backend away from the code that GDC/LDC shares with DMD.


Regards,
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';