harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nathan Beyer" <ndbe...@apache.org>
Subject Re: [general] What platforms do we support?
Date Wed, 04 Apr 2007 22:25:33 GMT
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
>

Mime
View raw message