Re: RFC: project directions...

<jgd@cix.compulink.co.uk> wrote
> cr88192@hotmail.com (BGB / cr88192) wrote:
>
>> however, as a cost:
>> since it would be the non-native calling convention, there would be
>> imperfect interfacing with the natively compiled code, in particular
>> WRT function pointers and 'va_list' and similar. although automatic
>> stub-generation is likely to glue the calling conventions together
>> fairly well, the glue is likely to be imperfect in various cases.
>
> Do you plan to provide libraries of your own for all of the APIs that
> Linux on x86-64 offers? I suspect not, but without that, the usefulness
> of your language will be rather limited. I think you need to provide a
> real, honest, 100% compatible implementation of the standard calling
> convention, both for calling external libraries, and for functions to be
> passed to them as callbacks. You really should ensure that linker
> symbols for your own calling convention can't be confused with ones from
> the usual compilers, not even by ingenious idiots.


actually, it will be a compiler for C, not a custom language...


however, it will be (mostly) compiled at runtime.




the idea will be to (mostly) use native APIs, but to make use of lots of
"auto-glue" machinery to try to stick them together (I already do this on
Linux, but for a different calling convention more directly related to
cdecl...).


the issue though is that there are a lot of edge cases, which could make
automatic gluing problematic in some cases, and it is possible at least
partial API wrapping will be needed to get around some of this, which is
less than ideal.




it doesn't help that I have discovered that, in the DLL case (the main case
where this is likely to be useful), neither DLL's not SO's contain enough
information (by themselves) to generate the glue, and I am left paranoid
that producing DLL's may require a "post compilation" step, which would
essentially mine additional information in order to produce a new DLL with a
good deal of metadata added (type data, full import/export declarations,
...).


at this rate, I almost may as well not use DLL's anymore.




note, this is not so much of an issue with the "XCall" name mangling, which
is what is used normally for gluing. in this case, the name mangling/ABI
stores a fairly large amount of additional information (both embedded into
symbol names, and also sideband), which allows code to more-or-less figure
out how to marshall data between one ABI and another (note that my ABI tends
to store a lot of information which is usually left out in the IA-64 ABI and
friends...).


it is likely I will take this further, adding in many cases full annotative
metadata (vaguely similar to debug info, but structured differently and used
differently). it also differs from the sorts of data usually embedded into
DLL's in MS formats, namely in that I will not depend on DLL-specific
mechanisms (although, sadly, in some cases this would lead to redundant
information).


I am left almost thinking I would be better off deriving a custom format,
itself based on a "purer" form of COFF, but alas, this would mean only using
my own tools, and having to use a custom loader on Windows as well, which is
again, lame...




> I'd expect that using your own calling convention, while it may offer
> up-front savings in effort, will become a millstone with time. It's
> probably going to be best to bite the bullet now, and save the effort of
> switching at a later date.
>


the problem is that this would not allow compiling code in a form which
would work on both Win64 and Linux x86-64, meaning that everything would
need to be compiled fresh for each platform.




I may as well almost go to the extreme of full-on bytecode while I am at it,
so that I could use the same code for x86 and x86-64.


I had partly designed such a format already (partly, it is a hybrid of EFI
ByteCode and x86/x86-64 machine code...).


or such...




> --
> John Dallman jgd@cix.co.uk
> "C++ - the FORTRAN of the early 21st century."
> [How much performance difference does a calling convention make, anyway?
> I'd think that if you had a lot of tiny procedures, you'd be better off
> inlining them like C++ does so they can participate in the calling
> procedure's optimizations. -John]
>


agreed, but I don't really think this is what is at issue here...

Return to the comp.compilers page.
Search the comp.compilers archives again.