This is the mail archive of the
mailing list for the glibc project.
Re: PATCH: Fix ll/sc for mips
- From: "Maciej W. Rozycki" <macro at ds2 dot pg dot gda dot pl>
- To: Ralf Baechle <ralf at oss dot sgi dot com>
- Cc: "H . J . Lu" <hjl at lucon dot org>, Hiroyuki Machida <machida at sm dot sony dot co dot jp>, libc-alpha at sources dot redhat dot com, linux-mips at oss dot sgi dot com
- Date: Mon, 4 Feb 2002 15:54:11 +0100 (MET)
- Subject: Re: PATCH: Fix ll/sc for mips
- Organization: Technical University of Gdansk
- Reply-to: "Maciej W. Rozycki" <macro at ds2 dot pg dot gda dot pl>
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
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
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: firstname.lastname@example.org, PGP key available +