On 24-04-2012 11:41, Gor Gyolchanyan wrote:
There are lots of times, when a specialized custom calling convention
is necessary.
For instance, I need a dynamic typing subsystem, to create abstract
state machines, which can be effortlessly adapted to run-time
heterogeneous data.
I already made a function, that takes arbitrary arguments and tightly
packs them in a single chunk of memory, making a run-time defined
structures.
A new calling convention would normalize the ABI of all functions,
making them all take a single pointer to such a structure. This will
allow to safely discard the static type info of the functions,
allowing them to be stored in and called from statically homogeneous
containers (like the ones inside an abstract state machine).
Currently, in order to do that, you'd need to define a function in a
very weird way and use tons of mixins to inject naked function
assembly to do this without the overhead of going through the current
static-only type system and calling conventions.
A simple option of allowing to define custom calling convention would
already lead to library solutions, that make D equally effective
static and dynamic typed language simultaneously (which would be
beautifully integrated with each other).
On Tue, Apr 24, 2012 at 1:10 PM, Iain Buclaw<[email protected]> wrote:
On 24 April 2012 10:08, Iain Buclaw<[email protected]> wrote:
On 24 April 2012 09:42, Alex Rønne Petersen<[email protected]> wrote:
Writing portable code is hard enough as it is. Why do we have to have some
random, D-specialized calling convention (only on Win32 and only in DMD)?
The result of the current state of things is that extern(D) is essentially
useless - it has completely different meanings across compilers. You cannot
rely on it at all. If memory serves me right, both LDC and GDC just alias it
to extern(C), but DMD insists on using this magical D calling convention on
Win32.
extern(System) would be a more accurate description of what GDC does,
as it uses the default calling convention for the target/platform you
are running on, which may not neccessarily be extern(C).
s/ running on / compiling for /
--
Iain Buclaw
*(p< e ? p++ : p) = (c& 0x0f) + '0';
I'm not sure what that has to do with the state of extern(D), but yes, I
agree that custom calling conventions could be useful in some
specialized cases.
--
- Alex
