Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: pass (herse.apache.org: domain of pavel.ozhdikhin@gmail.com
 designates 64.233.166.178 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
        b=WdnfR89JT3ZnhYMplWjgZ15+7bky3Gic6m7ekCqyusn7ZFlXrEKDwPnH8JcLGfI9JdKq+vrtDdc39307z1jXfY5X06R4rm7NKOFoXkqUKvU59sNSgweOqLAtkDtPXqB/8imjRGZ7qTvuPyIQpE7AjUH4d7e11RC1/QfciAWpBWo=
Message-ID: <469bff730611160039l757781ud7993ac5f59a4def@mail.gmail.com>
Date: Thu, 16 Nov 2006 14:39:00 +0600
From: "Pavel Ozhdikhin" <pavel.ozhdikhin@gmail.com>
To: harmony-dev@incubator.apache.org,
	"Slava Shakin" <vyacheslav.p.shakin@gmail.com>
Subject: Re: [drlvm][jit][ia-32]register-based fast calling convention
In-Reply-To: <ejh71j$s29$1@sea.gmane.org>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_55960_4773420.1163666340283"
References: <ejf6do$fv2$1@sea.gmane.org> <ejh71j$s29$1@sea.gmane.org>

------=_Part_55960_4773420.1163666340283
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Good proposal, Alex! Do you know if other VM use register-based fast calling
convention and what gain we can get from it? Can we see that
using micro-benchmarks?

Thanks,
Pavel


On 11/16/06, Slava Shakin <vyacheslav.p.shakin@gmail.com> wrote:
>
> Alex,
>
> It's great you're going to do that. I like the proposal.
>
> >     - make it possible to switch between existing and new conventions
> > for investigation and tuning purposes
>
> I think such configurability is a very important feature as we lose
> nothing
> but acquire both more opportunities for tuning and some performance win
> even
> with the current optimization set. IMO it is important to expose as many
> options for tuning as possible because even if the proposal doesn't
> immediately bring considerable boost we might well expect more from
> synergy
> with future optimizations and non-default options of existing ones.
>
> --
> Thanks,
> Slava Shakin.
>
>
> "Alex Astapchuk" <alex.astapchuk@gmail.com> wrote in message
> news:ejf6do$fv2$1@sea.gmane.org...
> > 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
> >
> >
> > Both 2) and 3) affect register allocation for float point values in a
> > bad manner.
> > Fixing even the 1) looks promising for hot vm helpers like monitor
> > enter/exit and resolve_interface_vtable.
> >
> > 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
> >     - 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.
> >
> > The #1 may be used to call internal C-based helpers. It may also be used
> > to call VM helpers where XMM callee save regs may add unnecessary
> > overhead on the helper itself. The example I can think of is
> > resolve_interface helper - preserving XMMs there looks overkill.
> >
> > #2 will help to speed-up managed code both call-intensive and (I hope)
> > FP-intesive - together with register allocator tuning.
> >
> >
> > Any comments are welcome.
> >
> >
> > [1]
> >
> http://wiki.apache.org/harmony/JIT_Development_Tasks#head-bffdfbc80108641ca9a8bc29ea871c67fb3b82b9
> >
> >
> > --
> > Thanks,
> >   Alex
> >
> >
>
>
>
>

------=_Part_55960_4773420.1163666340283--