Re: x86-64 and calling conventions

James Harris <james.harris.1@googlemail.com>
Wed, 14 May 2008 03:38:42 -0700 (PDT)

          From comp.compilers

Related articles
[2 earlier articles]
Re: x86-64 and calling conventions james.harris.1@googlemail.com (James Harris) (2008-05-12)
Re: x86-64 and calling conventions vidar.hokstad@gmail.com (Vidar Hokstad) (2008-05-12)
Re: x86-64 and calling conventions daveparker@flamingthunder.com (Dave Parker) (2008-05-12)
Re: x86-64 and calling conventions cr88192@hotmail.com (cr88192) (2008-05-13)
Re: x86-64 and calling conventions cr88192@hotmail.com (cr88192) (2008-05-13)
Re: x86-64 and calling conventions gah@ugcs.caltech.edu (glen herrmannsfeldt) (2008-05-13)
Re: x86-64 and calling conventions james.harris.1@googlemail.com (James Harris) (2008-05-14)
Re: x86-64 and calling conventions vidar.hokstad@gmail.com (Vidar Hokstad) (2008-05-14)
Re: x86-64 and calling conventions james.harris.1@googlemail.com (James Harris) (2008-05-14)
Re: x86-64 and calling conventions cr88192@hotmail.com (cr88192) (2008-05-15)
Re: x86-64 and calling conventions cr88192@hotmail.com (cr88192) (2008-05-15)
Re: x86-64 and calling conventions bc@freeuk.com (Bart) (2008-05-14)
Re: x86-64 and calling conventions cr88192@hotmail.com (cr88192) (2008-05-15)
[2 later articles]
| List of all articles for this month |

From: James Harris <james.harris.1@googlemail.com>
Newsgroups: comp.compilers
Date: Wed, 14 May 2008 03:38:42 -0700 (PDT)
Organization: Compilers Central
References: 08-05-031 08-05-038
Keywords: architecture, design
Posted-Date: 14 May 2008 12:04:55 EDT

On 12 May, 12:12, James Harris <james.harri...@googlemail.com> wrote:
> I'm working on a language where the call conventions are to be filled-
> in after compilation. Each function is to compile to also use virtual
> registers rather than real ones. Then only when one function calls
> another do we set up the registers for both functions, the calling
> conventions to pass data between them, and decide which regs to either
> spill or save. ...


> [How do you plan to handle function pointers? -John]


You mean how to call routines which are dynamically chosen? I'm not
sure I'll have function pointers as such but maybe first class
functions having the same issue. If the caller does not know which
function it will call at the time of compilation perhaps the caller
could fall back to saving all in-use registers and using a generic
method to pass parameters


1. on the stack,
2. in registers,
3. in a block of memory.


Of course, any function which could potentially be called dynamically
would need to use the matching mechanism to retrieve its parameter
values. Things get more interesting if a function could be called
either statically or dynamically. In that case it may need to support
more than one method of parameter passing. Options here? 1. Header and
footer glue code - possibly the more complex of the two glue code
sequences calls the simpler or both types of glue code call the
function proper, 2. Duplicate functions - especially if the function
is short its code could be duplicated between suitable headers and
footers.


Does that sound like it would work? Maybe you meant something entirely
different!


By the way, the idea of duplicating code is intended to be quite
widespread in order to achieve speed. Two cases where that may apply:


First, when the number of iterations is small some iterable constructs
may be implementable more efficiently than in a loop. As an example,
the IBM 360 instruction set includes an insert characters under mask
instruction which can load bytes into a register. It may be the
fastest (and shortest) way to pick up unaligned bytes from memory
where the number of bytes is three or fewer. For higher numbers a loop
may be more appropriate.


Second, where parameters have default values execution may be faster
to execute if there is a copy of the code which uses the defaults.
After all, constants provide ways to optimise that are not possible
when variables are used. There would also need to be a piece of code
emitted for the more general case.


--
James
[Are you considering cache behavior? If you duplicate a lot of code,
it becomes less likely that it'll fit in the cache. -John]



Post a followup to this message

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