Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (athena.apache.org: domain of gshimansky@gmail.com
 designates 72.14.220.153 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=from:to:subject:date:user-agent:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender;
        b=aVCFO+jxjOX7Cc7AT8ukuz6OmIN2wGhV8s8TUo+TexsdpBc48p2wszotXKBn2Y/9YQhKQPn1X2SwAWeC2dZDulXRQfWXjap71URZx2JVoqK3uqugrqXbVGE+9n0nrSuPtkf1IELA3st32K9ssmvAwZfQ/Pv2Sh7svQTc7AiSTok=
From: Gregory Shimansky <gshimansky@apache.org>
To: dev@harmony.apache.org
Subject: Re: [general] harmony launch failed on AMD Geode LX
Date: Sat, 2 Feb 2008 22:45:43 +0300
User-Agent: KMail/1.9.7
References: <47962808.3000400@gmail.com>
 <200802012319.43611.gshimansky@apache.org> <0vqir17k8ck.fsf@gmail.com>
In-Reply-To: <0vqir17k8ck.fsf@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-5"
Content-Transfer-Encoding: 8bit
Content-Disposition: inline
Message-Id: <200802022245.44114.gshimansky@apache.org>
Sender: Gregory Shimansky <gshimansky@gmail.com>

On 2 February 2008 Egor Pasko wrote:
> On the 0x3DD day of Apache Harmony Gregory Shimansky wrote:
> > On 1 ������� 2008 Egor Pasko wrote:
> > > On the 0x3DD day of Apache Harmony Mark Hindess wrote:
> > > > > > in place of sfence in vm/vmcore/src/thread/linux/atomics.cpp.
> > > > >
> > > > > Yes I think this should help on processors with no SSE (not to
> > > > > mention SSE2) support.
> > > >
> > > > It does.  HelloWorld runs okay with -Xint.  (Now I just need to find
> > > > a way to run the tests on a machine which boots to a small ramdisk
> > > > from compact flash and doesn't currently support network file
> > > > systems.)
> > > >
> > > > Without -Xint, predictably, it fails with not-immediately-helpful
> > > > core which reports:
> > > >
> > > > (gdb) bt
> > > > #0  0xa649d24d in ?? ()
> > > > (gdb) x/1i $eip
> > > > 0xa649d24d:     (bad)
> > > >
> > > > It might be worth adding an option to the federation build compile
> > > > for a more limited processor so that people can do some testing
> > > > w/-Xint - on OLPC, Geode and VIA based machines?
> > >
> > > I tried to say that a build option would be nearly as hard to
> > > implement as a runtime option, which is more preferrable.
> >
> > In class library I saw an interesting approach with code patching in
> > assembly. It has a special segment with the same name (on windows all
> > segments of the same name are merged across assembly sources) with labels
> > for each LOCKed instruction. In case the system is determined to be
> > uniprocessor, it patches all of the LOCK prefixes with NOP (see
> > thrhelp.asm, thrspinlock.asm and lock386.c files).
>
> cool! but who needs uniprocessors? :)

I just wanted to describe the approach with patching the code on startup. It 
doesn't have to be SMP/noSMP choice. It may be SSE/noSSE choice.

> They say some windows drivers on uniprocessor systems just stop thread
> preemption by flipping a special flag with no lock prefix [1]. That is
> because windows does not support CPU hotplug :)
>
> > In theory it could be possible to gather all of the locations of mfence,
> > sfence, etc instructions in the code and patch them according to
> > architecture at the initialization point. But in practice creating such a
> > table is easy only for assembly.
>
> I see the biggest problem in making a complete list of all potential
> fence places. After that deciding case by case is much easier.

Yes this is the problem with high level languages.

-- 
Gregory