linux-mips
[Top] [All Lists]

Re: PATCH: Fix ll/sc for mips

To: Ralf Baechle <ralf@oss.sgi.com>
Subject: Re: PATCH: Fix ll/sc for mips
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Date: Mon, 4 Feb 2002 15:54:11 +0100 (MET)
Cc: "H . J . Lu" <hjl@lucon.org>, Hiroyuki Machida <machida@sm.sony.co.jp>, libc-alpha@sources.redhat.com, linux-mips@oss.sgi.com
In-reply-to: <20020204080145.C13799@dea.linux-mips.net>
Organization: Technical University of Gdansk
Reply-to: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Sender: owner-linux-mips@oss.sgi.com
On Mon, 4 Feb 2002, Ralf Baechle wrote:

> > It will make the code more readable. We don't have to guess what
> > the assembler will do. 
> 
> Generally speaking a MIPS assembler is free to do arbitrary reordering.
> In the past there have been non-GNU assembler that were doing more massive
> reordering than gcc does ...  Using .set noreorder means you dump the
> assembler's intelligence and take full responsibility for dealing with
> all interlocks (or the lack thereof) and other performance issues
> yourself.

 That's why I'm still uneasy about the patch or, specifically, its
_test_and_set hunk.  It's best to avoid pretending we have the knowledge
beyond what an assembler has, as it's often not the case -- consider all
the options an assembler can accept for code variations.

 Using "noreorder" is really justified if you need to generate an exact
opcode stream for some reason (perhaps for a trampoline with a fixed
format) or you know you have the knowledege beyond what an assembler has,
e.g. you know an instruction can (or must) really be placed in a delay
slot even though a dependency analysis performed by an assembler shows
otherwise. 

 Also beware of implicit macros which may expand into multiple
instructions -- their semantics when placed in a delay slot may differ
from what one may expect! 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +


<Prev in Thread] Current Thread [Next in Thread>