harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregory Shimansky <gshiman...@gmail.com>
Subject Re: [general] What platforms do we support?
Date Wed, 04 Apr 2007 20:27:55 GMT
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?

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.


View raw message