| To: | "Maciej W. Rozycki" <macro@ds2.pg.gda.pl> |
|---|---|
| Subject: | Re: sti() does not work. |
| From: | Ralf Baechle <ralf@oss.sgi.com> |
| Date: | Fri, 13 Jul 2001 13:35:18 +0200 |
| Cc: | Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>, linux-mips@oss.sgi.com |
| In-reply-to: | <Pine.GSO.3.96.1010705132623.11517D-100000@delta.ds2.pg.gda.pl>; from macro@ds2.pg.gda.pl on Thu, Jul 05, 2001 at 01:35:11PM +0200 |
| References: | <20010704152619.E3829@bacchus.dhis.org> <Pine.GSO.3.96.1010705132623.11517D-100000@delta.ds2.pg.gda.pl> |
| Sender: | owner-linux-mips@oss.sgi.com |
| User-agent: | Mutt/1.2.5i |
On Thu, Jul 05, 2001 at 01:35:11PM +0200, Maciej W. Rozycki wrote: > > > (why is noreorder used here?). > > > > Without the .set noreorder the assembler would be free to do arbitrary > > reordering of the object code generated. Gas doesn't do that but there > > are other assemblers that do flow analysis and may generate object code > > that doesn't look very much like the source they were fed with. > > Hmm, I would consider that a bug in such an assembler. The mtc0 and > possibly the mfc0 opcode should be treated as reordering barriers as they > may involve side effects an assembler might not be aware of. Assembler is the art of using sideeffects so things are fairly explicit. Optimizations are controlled using .set noreorder / reorder .set volatile / novolatile .set nomove / nomove .set nobopt / bopt Ralf |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: RFC: run-time defining serial ports, Ralf Baechle |
|---|---|
| Next by Date: | Re: OSS CVS Tree and 2.5.x, Ralf Baechle |
| Previous by Thread: | Re: sti() does not work., Maciej W. Rozycki |
| Next by Thread: | Re: sti() does not work., Maciej W. Rozycki |
| Indexes: | [Date] [Thread] [Top] [All Lists] |