Re: Disabling local optimizations with GCC

Re: Disabling local optimizations with GCC

[The Chazman]

> Here's my problem:
> I'm using a cross-compiler under Windows 98/NT for an m68k-coff target
> (MC68306). I have certain symbols mapped to specific hardware addresses
> so that I can interact with the hardware (as I assume most would do it).
> In some cases I assign different values to the same address in
> succession, or intermixed with the assignment of values to other
> addresses. It is important for all assignments to occur because each one
> causes the hardware to perform a particular action, and all actions need
> to occur in the order I've placed them in the C-language functions. The
> problem is that with any GCC optimization level  (-O, -O1, -O2, or -O3),
> it "optimizes" out all but the last assignment to a given location. This
> causes my program not to work. Everything seems to be fine if I disable
> all optimizations, but some parts of my program are time-critical and I
> may need some of the optimizations for the program to work right.
>
> Here is some example code:
> _____________________________________________________________
> /* duart's base i/o address */
> #define IoPortAddr   ((BYTE*)0xa0001)

Stop right there.  Change this to:

#define IoPortAddr  ((volatile BYTE*)0xa0001)

It's imperative that you define all hardware registers volatile.
This tells the compiler that these variables/addresses either:
  1) produce side-effects when written, thus back-to-back writes
     must be preserved, or
  2) may change values due to external causes, thus reads must
     not be cached in CPU registers for future use, or
  3) both.

Try that and see how it goes.


-------------------------------------------
Carl Miller               Firmware Engineer
chaz@gordian.com              Gordian, Inc.
(714) 850-0205       http://www.gordian.com
personal: chaz@devastator.extern.ucsd.edu

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

Re: Disabling local optimizations with GCC

[John Mills]

Art -

On Wed, 28 Jun 2000, Art Berggreen wrote:
 
> Have you tried declaring your hardware variables as "volatile"?  This
> tends to stop the compiler from many of these optimizations.
> (i.e. try #define IoPortAddr   (volatile (BYTE*)0xa0001))

Thanks for the suggestion. At present, I'm using two types of
construction:

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
[...]
#define	EVB_BASE	0xFFFF0000      /* Register-block base address */

/* SCI0 Registers */

/* Serial mode ch 0 */
#define SCI0_SMR   (*(volatile unsigned char *)(EVB_BASE + 0x81a0))
/* Bit rate ch 0 */
#define SCI0_BRR   (*(volatile unsigned char *)(EVB_BASE + 0x81a1))
[...]

then I read or write from appropriately typed or cast variables
{
unsigned char tempch;
...
  tempch = SCI0_SMR | <modes_to_add>;
  SCI0_SMR = tempch;
...
}
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

and in other sources:

[...]
#define readb(addr) (*(volatile unsigned char *) (addr))
#define writeb(b,addr) ((*(volatile unsigned char *) (addr)) = (b)

#define SCI0_SMR    (EVB_BASE + 0x81a0)

used as in:

{
...
unsigned char tempch;

  tempch = readb(SCI0_SMR);
  writeb((tempch | <modes_to_add>), SCI0_SMR);

...
}
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

The second approach is handy in that registers may be grouped as unions
and manipulated jointly or severally without duplicated variant names nor
in-line type-casts (or rather the type casting looks like functions, which
I find handy and readable - YMMV).

I haven't found any construction which seems to work or fail consistently,
but my 'C' coding skills are (to put it gently) 'limited'. I'll try the
formation you suggest and see how it works.

I am also concerned by the inconsistent results I seem to get from code
constructions which (_a_priori_) look acceptable to me.
  
Regards -

   John Mills
   Sr. Software Engineer
   TGA Technologies, Inc.
   100 Pinnacle Way, Suite 140
   Norcross, GA 30071-3633
   e-mail: jmills@tga.com
   Phone: 770-441-2100 ext.124 (voice)
          770-449-7740 (FAX)



------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

Re: Disabling local optimizations with GCC

[Art Berggreen]

Christopher Bahns wrote:
> 
> Hello,
> 
> Anyone know how to take advantage of most of GCC's optimizations without
> it performing certain local optimizations? I read through the -O and -f
> options in the gcc manual and did not see anything specifically just for
> local optimizations. There is the "-fgcse" (global common
> subexpressions) but I guess this would not apply to commonizing
> subexpressions locally within a function... don't really know. I did not
> see any "-flcse" or similar option.
> 
> Here's my problem:
> I'm using a cross-compiler under Windows 98/NT for an m68k-coff target
> (MC68306). I have certain symbols mapped to specific hardware addresses
> so that I can interact with the hardware (as I assume most would do it).
> In some cases I assign different values to the same address in
> succession, or intermixed with the assignment of values to other
> addresses. It is important for all assignments to occur because each one
> causes the hardware to perform a particular action, and all actions need
> to occur in the order I've placed them in the C-language functions. The
> problem is that with any GCC optimization level  (-O, -O1, -O2, or -O3),
> it "optimizes" out all but the last assignment to a given location. This
> causes my program not to work. Everything seems to be fine if I disable
> all optimizations, but some parts of my program are time-critical and I
> may need some of the optimizations for the program to work right.
> 
> Of course, I can choose to disable all optimizations except the ones
> that I specify explicitly with "-f" options, but I'd prefer to have as
> many enabled as possible without breaking my program.
> 
> Here is some example code:
> _____________________________________________________________
> /* duart's base i/o address */
> #define IoPortAddr   ((BYTE*)0xa0001)
> 
> void InitDuart681(void)
> {
>    /* disable transmitter and receiver */
>    IoPortAddr[DUCRA] = ((0x0 << 4) | (0x2 << 2) | 0x2);
>    IoPortAddr[DUCRB] = ((0x0 << 4) | (0x2 << 2) | 0x2);
> 
>    /* reset UartA transmitter and receiver */
>    IoPortAddr[DUCRA] = (0x2 << 4);
>    IoPortAddr[DUCRA] = (0x3 << 4);
> 
>    /* make sure we're not in break */
>    IoPortAddr[DUCRA] = (0x7 << 4);
>    IoPortAddr[DUCRA] = (0x5 << 4);
> 
>    /* reset error status */
>    IoPortAddr[DUCRA] = (0x4 << 4);
> 
>    /* set for no N81, normal operation */
>    IoPortAddr[DUCRA] = (0x1 << 4);
>    IoPortAddr[DUMRA] = 0x13;
>    IoPortAddr[DUMRA] = 0x7;
> 
>    /* set port speed-- 9600 bps */
>    IoPortAddr[DUCRA] = (0x1 << 4);
>    IoPortAddr[DUACR] = (DUacr |= 0x80);
>    IoPortAddr[DUCSRA] = 0xbb;
> 
>    /* init counter- counter mode, external clock source */
>    IoPortAddr[DUACR] = (DUacr |= 0x30);
> }
> _____________________________________________________________
> 
> This is not the complete function, but you can see that it writes values
> to the same location more than once, without ever accessing values from
> that location. This tells the compiler that all assignments except the
> last one (to a given location) are meaningless and can be discarded. I
> have verified this by examining the assembler listing generated by GCC.
> 
> Any suggestions? I've gotta think someone else has run into this before.
> 
> Thanks for any help!
> Chris

Have you tried declaring your hardware variables as "volatile"?  This
tends to stop the compiler from many of these optimizations.
(i.e. try #define IoPortAddr   (volatile (BYTE*)0xa0001))

Art

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

Disabling local optimizations with GCC

[Christopher Bahns]

Hello,

Anyone know how to take advantage of most of GCC's optimizations without
it performing certain local optimizations? I read through the -O and -f
options in the gcc manual and did not see anything specifically just for
local optimizations. There is the "-fgcse" (global common
subexpressions) but I guess this would not apply to commonizing
subexpressions locally within a function... don't really know. I did not
see any "-flcse" or similar option.

Here's my problem:
I'm using a cross-compiler under Windows 98/NT for an m68k-coff target
(MC68306). I have certain symbols mapped to specific hardware addresses
so that I can interact with the hardware (as I assume most would do it).
In some cases I assign different values to the same address in
succession, or intermixed with the assignment of values to other
addresses. It is important for all assignments to occur because each one
causes the hardware to perform a particular action, and all actions need
to occur in the order I've placed them in the C-language functions. The
problem is that with any GCC optimization level  (-O, -O1, -O2, or -O3),
it "optimizes" out all but the last assignment to a given location. This
causes my program not to work. Everything seems to be fine if I disable
all optimizations, but some parts of my program are time-critical and I
may need some of the optimizations for the program to work right.

Of course, I can choose to disable all optimizations except the ones
that I specify explicitly with "-f" options, but I'd prefer to have as
many enabled as possible without breaking my program.

Here is some example code:
_____________________________________________________________
/* duart's base i/o address */
#define IoPortAddr   ((BYTE*)0xa0001)

void InitDuart681(void)
{
   /* disable transmitter and receiver */
   IoPortAddr[DUCRA] = ((0x0 << 4) | (0x2 << 2) | 0x2);
   IoPortAddr[DUCRB] = ((0x0 << 4) | (0x2 << 2) | 0x2);

   /* reset UartA transmitter and receiver */
   IoPortAddr[DUCRA] = (0x2 << 4);
   IoPortAddr[DUCRA] = (0x3 << 4);

   /* make sure we're not in break */
   IoPortAddr[DUCRA] = (0x7 << 4);
   IoPortAddr[DUCRA] = (0x5 << 4);

   /* reset error status */
   IoPortAddr[DUCRA] = (0x4 << 4);

   /* set for no N81, normal operation */
   IoPortAddr[DUCRA] = (0x1 << 4);
   IoPortAddr[DUMRA] = 0x13;
   IoPortAddr[DUMRA] = 0x7;

   /* set port speed-- 9600 bps */
   IoPortAddr[DUCRA] = (0x1 << 4);
   IoPortAddr[DUACR] = (DUacr |= 0x80);
   IoPortAddr[DUCSRA] = 0xbb;

   /* init counter- counter mode, external clock source */
   IoPortAddr[DUACR] = (DUacr |= 0x30);
}
_____________________________________________________________

This is not the complete function, but you can see that it writes values
to the same location more than once, without ever accessing values from
that location. This tells the compiler that all assignments except the
last one (to a given location) are meaningless and can be discarded. I
have verified this by examining the assembler listing generated by GCC.

Any suggestions? I've gotta think someone else has run into this before.

Thanks for any help!
Chris