Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (herse.apache.org: domain of nbeyer@gmail.com designates
 66.249.92.174 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth;
        b=B1u1I0heWynoJXnHRNm/dWh6o+Ojtrr7fjExF5uKnVr68IZIoxzosJdORGSGNc6UAt3pekvViLcjNstGFBYrcYZtLCB+xb9w7ysdx0SJDaLMPPywgLOC/B0uExNRWwbH6MWg1AGntqjymG0Q9CMMLdGHQ572ulWSYlIIV6qYRdc=
Message-ID: <3b3f27c60704041525p24bf4f04v7f52f38351fd8c61@mail.gmail.com>
Date: Wed, 4 Apr 2007 17:25:33 -0500
From: "Nathan Beyer" <ndbeyer@apache.org>
Sender: nbeyer@gmail.com
To: dev@harmony.apache.org
Subject: Re: [general] What platforms do we support?
In-Reply-To: <200704050027.55508.gshimansky@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <3b3f27c60703302034r65b0cb21q9ceb0afca71be7a0@mail.gmail.com>
	 <bc79dd600704040023u184fb2fepb6a788c840cabf29@mail.gmail.com>
	 <51d555c70704041233oba2a9abubf7caaeea8e46b1f@mail.gmail.com>
	 <200704050027.55508.gshimansky@gmail.com>

On 4/4/07, Gregory Shimansky <gshimansky@gmail.com> wrote:
> On Wednesday 04 April 2007 23:33 Rana Dasgupta wrote:
> > On 4/4/07, Mikhail Fursov <mike.fursov@gmail.com> wrote:
> > > On 4/4/07, Alexey Petrenko <alexey.a.petrenko@gmail.com> wrote:
> > > > 2007/4/4, Gregory Shimansky <gshimansky@gmail.com>:
> > > > > > > I would like to see these modifications. I wonder what you've
> > > > > > > done in
> > > > >
> > > > > port/src/thread/linux/apr_thread_ext.c and vmcore/include/atomics.h.
> > > > > They contain mfence and sfence instructions in inline assembly which
> > > > > have to be changed to something else on P3.
> >
> > MemoryWriteBarrier() etc. should be no-ops on PIII. x86 is already
> > strongly ordered for writes ?
>
> What about MemoryReadWriteBarrier()? If you know, what kind of code should be
> used for this in P3?
>
> > > > Can we produce separate binary build for P3 if it is not easy to
> > > > replace mfence/sfence?
> > >
> > > Jitrino can use runtime detection of CPU features supported and emit
> > > appropriate code.
> > > Can we do the same with VM (check flag) to avoid multiple distributions?
> >
> > Jitrino generates code late, the VM doesn't. So I am not sure how this
> > would work unless we link all versions of the asm's and then decide
> > which ones to call at runtime, which has a cost. My suggestion would
> > be that if we want the x86-32 bits to be PIII compatible, we should
> > only use PIII instructions ( upto SSE ) in all the static 32 bit
> > binaries. The jit can choose to generate more advanced instruction
> > sequences at runtime based on cpuid if the paltform supports it.
>
> I am not sure what you mean by using only P3 compatible code in all statically
> linked binaries. In this case what should be used for MemoryWriteBarrier
> function so that it would work on P4 too?

Yes, I believe what we want to say is code to the lowest common
instruction set for static code in the VM, at least for each distinct
instruction set (x86 32-bit, IPF, etc). For the x86 32-bit, the
available instructions must be available in at least a P3.

-Nathan

>
> What about code patching upon initialization? The [m|s]fence instructions
> could be replaced with NOPs or other code for P3 by the initialization code.
> Of course this would prevent inlining of these functions so that all places
> where code has to be patched are known, but it should be faster than choosing
> the appropriate barrier function implementation at runtime. Also care should
> be taken for [lib]hythr library which uses apr_memory_rw_barrier function, it
> should be patched as well after [lib]hythr is loaded, possibly by the library
> initialization code since it is currently loaded before harmonyvm by the
> launcher as a hyport dependency.
>
> --
> Gregory
>