Re: RFC: project directions...

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.


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.


--
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]

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