Re: x86-64 and calling conventions

"Vidar Hokstad" <vidar.hokstad@gmail.com> wrote in message
> On May 12, 12:44 am, "cr88192" <cr88...@hotmail.com> wrote:
>> Well, I have my own compiler, however, I don't as of yet target x86-64.
>>
>> one of the main reasons:
>> the calling conventions used in Linux and friends are, scary...
>>
>> Short Description:
>> arguments are passed in registers, meanwhile, others may be left on the
>> stack, and there is no particular relation between the registers and the
>> stack layout.
>
> Ouch. This is hideous. Since I didn't know what you were talking
> about, but is in the process of writing a compiler in Ruby (currently
> targeting 386, but I want to add x86_64 later) I did a search and came
> up with this: http://www.x86-64.org/documentation/abi-0.99.pdf
>
> I can see why you consider it scary. My compiler is taking a lot of
> ideas from Ruby, and that includes being able to take all arguments as
> an array, which is trivial on 32 bit x86, but a real pain here..


yeah.




> There are a number of callee saved registers, so you can do some forms
> of extension of the calling convention without losing the ability for
> your code to call out to C without interface stubs, but you'd lose the
> ability for C to call back in, of course (I made that sacrifice in my
> compiler for varargs, where I pass the count of varargs provided in a
> register, in which case you'll need a wrapper to safely call it from
> C, but if my code calls varargs C functions, the value of that
> register will just be ignored).
>


my compiler is for C...


the ability to make calls need to be bidirectional...




> Apart from that, I'd strongly suggest you stick with the calling
> convention, even though it's painful. To handle higher order argument
> lists you could always synthesize an anonymous conversion function if
> needed, to turn it into an array or iterate over the arguments.
>
> As for "hidden arguments", presumably they won't be hidden to the C
> code anyway, or the values would be lost when crossing the barrier, so
> there I'd consider just treating them as normal arguments with respect
> to the calling convention and just hiding them to the users of your
> language.


my language is C...


Actually, the hidden arguments are more within the compiler-generated
function body. it itself is wrapped by another automatically generated
wrapper (which has the same interface as the original function).


The added argument would basically be a context representing the
closures' environment...




> There's in practice nothing outright stopping you from defining your
> function signatures in a way which will force all the arguments onto
> the stack and still comply with this calling convention, either, as
> far as I can see, but it'd result in function signatures that would be
> extremely inconvenient to work with on the C side, and you'd still
> have a problem calling C code unless your compiler explicitly knows
> when it needs to resort to the C calling convention.


well, this wont work in my case.




> I'd bite the bullet...


will probably have to.

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