Re: problems with "reordered code" using GNU, PPC, vxWorks

Michael Meissner <mrmnews@the-meissners.org>
30 Mar 2003 00:39:33 -0500

          From comp.compilers

Related articles
problems with "reordered code" using GNU, PPC, vxWorks schulze_wolfgang@t-online.de (2003-03-24)
Re: problems with "reordered code" using GNU, PPC, vxWorks mcintosh@mc-pc.research.telcordia.com (2003-03-30)
Re: problems with "reordered code" using GNU, PPC, vxWorks anton@mips.complang.tuwien.ac.at (2003-03-30)
Re: problems with "reordered code" using GNU, PPC, vxWorks mrmnews@the-meissners.org (Michael Meissner) (2003-03-30)
| List of all articles for this month |
From: Michael Meissner <mrmnews@the-meissners.org>
Newsgroups: comp.compilers
Date: 30 Mar 2003 00:39:33 -0500
Organization: Compilers Central
References: 03-03-151
Keywords: optimize
Posted-Date: 30 Mar 2003 00:39:33 EST

schulze_wolfgang@t-online.de (Wolfgang Schulze) writes:
> I´m using a PPC under vxworks, Ansi C, GNU. After compilation my code
> is reordered for optimisation. I want to have my code optimized by the
> compiler, but in some source code I need to have the exact instruction
> order as I write in my source code. ...
> [Isn't that what volatile declarations are supposed to do? -John]


In general, John is right you really should be using volatile on all
variables that need to be ordered. Otherwise, the compiler is fully
entitled to rearrange things.


On asm statements, you should use asm volatile instead of asm where
the asm statement cannot be moved out of a loop, and you should
indicate "memory" in the list of clobbered registers as per the
documentation. A usual problem that many people have is in using
multiple asm statements, one per instruction, when you should put all
of the interelated asm's together in one block, so that the compiler
won't move things between the asm statements. You obviously need to
have the right inputs and outputs so the compiler can do the
dependency checking (and not use the form of asm that has no
inputs/outputs).


There are options for not rescheduling instructions, but those are a
crutch, and in general you should try to not use them.


The final method of course is to write the critical parts in
assembler, and call it from the code.
--
Michael Meissner
email: mrmnews@the-meissners.org
http://www.the-meissners.org


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.