harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rana Dasgupta" <rdasg...@gmail.com>
Subject Re: [drlvm][jit][ia-32]register-based fast calling convention
Date Fri, 17 Nov 2006 01:32:34 GMT
Hi Alex,
    This is good, thanks. Please see below...

On 11/15/06, Alex Astapchuk <alex.astapchuk@gmail.com > wrote:
> >Hi all,
> >Among other things listed on the JIT Dev tasks, there is a need for
> >calling convention (CC) fix-up for IA-32 [1].
> >Current problems are:
> >1. The calling convention(s) used are stack-based - this adds a memory
> >access overhead on calls.
> >2. The convention currently used for managed code neither allow to pass
> >float-point values on XMM registers, nor it provides callee-saved XMM
> >registers.
> >3. FPU stack is used to return float/double values
>So, I'm going to implement register-based calling convention for IA-32.
> >The current proposal is:
> >    - make it possible to switch between existing and new conventions
> >       for investigation and tuning purposes

  So does this mean one specific convention, fastcall, for C helpers and a
second custom DRLVM convention for managed code?

>    - implement 2 calling conventions:
> >       1. well known standard fastcall (fisrt 2 params on ECX+EDX, the
> >       rest is on stack)

> >       2. DRLVM-specific convention: which involves ECX, EDX (and may
> >       be EAX) for integer/parameters passing and also use XMMs for
> >       float-point parameters and produce callee-save XMMs.

Passing a bounded number of fp args using XMM sounds like a good idea, but
why callee-saves XMM's? My recollection is that the Intel Software
Development Manual recommends caller saved SSE and SSE2 registers for
performance. Primarily because there are all kinds of optimized move
instructions to and from XMM registers like MOVAPS, MOVUPS, MOVAPD, MOVDQA
etc.  for packed/unpacked, single/double precision fp types. The callee does
not know the datatype in a register. The caller can save only what it wants
to preserve, using the best move. My recollection is that the unaligned move
penalties are high.

I  did not fully understand your comment about the resolve_interface()
helper. In the custom convention(2), is the proposal for all XMM registers
to be saved by the callee, even if there are no fp operands in the method?


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message