gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

Coding > volatile error while it is not in the program

#3351 - Lionheart - Sun Feb 23, 2003 11:34 am

when I want to compile my program using Devkitadvs' GCC I always get the same error:
Koelogotest.c:12: parse error before "volatile"
I know that that means that I used a wrong code or something before "volatile" in line 12, but the problem is that I don't have the word volatile in my whole program!

here is the code of my whole program:
Code:

#include"gba.h"
char f =0;

#include "screenmode.h"
#include "KOElogo.h"
#include "timers.h"
#include "screenmodes.h"
#include "clrhome.h"
#include "Flogo.h"

u16* FrontBuffer = (u16*)0x6000000;
u16* BackBuffer = (u16*)0x600A000;
u16* videoBuffer;

u16* paletteMem = (u16*)0x5000000;

void PlotPixel(int x,int y, unsigned short int c) {FrontBuffer[(y) *120 + (x)] = (c);}

#define RGB(r,g,b) (r+(g<<5)+(b<<10))

int main(void)
{
   SetMode(MODE_4 | BG2_ENABLE);   

   int x, y, z;
   z=0;
   for(x = 0; x < 256; x++)
      paletteMem[x] = KOElogoPalette[x];
   for(y = 0; y < 160; y++)
   {
      for(x = 0; x < 120; x++)

      {
         PlotPixel(x,y,KOElogoData[y*120+x]);

      }
   }
   for (z = 0; z < 20000; z++ )
      {}
 
   z=0;
   for(x = 0; x < 256; x++)
      paletteMem[x] = clrhomePalette[x];
   for(y = 0; y < 160; y++)
   {
      for(x = 0; x < 120; x++)

      {
         PlotPixel(x,y,clrhomeData[y*120+x]);

      }
   }
   
   z=0;
   for(x = 0; x < 256; x++)
      paletteMem[x] = FlogoPalette[x];
   for(y = 0; y < 160; y++)
   {
      for(x = 0; x < 120; x++)

      {
         PlotPixel(x,y,FlogoData[y*120+x]);

      }
   }
   for (z = 0; z < 20000; z++)
      {}
}


sorry for the length but line 12 is the line with:
u16* BackBuffer = (u16*)0x600A000;

thanks
_________________
"You PLAY games? Pathetic!"

#3356 - col - Sun Feb 23, 2003 2:43 pm

have you checked the *.h files that you are including, if one of them is faulty, it could be tripping the compiler into giving you a seemingly false line number?

cheers

Col.

#3357 - Lionheart - Sun Feb 23, 2003 2:51 pm

yes, I have checked them and there seems to be no problem, because they work with other progams as well. HELP!
Maybe someone can try to make the .bin file when he copies the code and makes 3 pictures with the names given in the code? If it works then something must be wrong with my compiler.
_________________
"You PLAY games? Pathetic!"

#3375 - CoolMan - Sun Feb 23, 2003 7:27 pm

GCC can get confused about what causes a parse error, but it does not get confused about the line number that it hit when it detected the error. (GCC explicitely details what file the error is in if the error is nested.)

However, the preprocessor is what replaces typedefs like 'u8' with 'unsigned char' (which is what the compiler recognizes). If one of your typedefs (for u16, or whatever) defines it a volatile, then thats why GCC is using that as it's error referance point.

As for the actual cause of the error, the only thing i see that might freak out the compiler is...
Code:

for (z = 0; z < 20000; z++) {}

I don't think that should parse at all, but if it does, it might go into an infinite loop in your first case...
Code:

for (z = 0; z < 20000; z++ )
      {}

   z=0;

Might just translate to...
Code:

for (z = 0; z < 20000; z++ ) /* {} was ignored... */ z=0;


I would suggest replacing "for (z = 0; z < 20000; z++ ) {}" with "for (z = 0; z < 20000; z++ ) { ; }"...

Other then that, I don't see your error with just a quick glance.

I might try running it through my compiler later, but I gotta end this post and go eat lunch now. :)

Hope it works out.
_________________
Moron! You don't herd chickens with a shotgun!

--CoolMan

#3959 - Paul Shirley - Thu Mar 13, 2003 7:53 pm

removed

Last edited by Paul Shirley on Sun Mar 28, 2004 9:53 pm; edited 1 time in total

#3968 - tepples - Thu Mar 13, 2003 11:41 pm

Paul Shirley wrote:
Its a problem because you cannot see what the compiler is trying to compile

Doesn't GCC have a way to store the preprocessor output?

Quote:
If your headers defined it this way an error would have been thrown that made more sense
Code:
static u16*const  FrontBuffer      =(u16*)0x6000000;
static u16*const  BackBuffer       =(u16*)0x600A000;

In my experience, collisions with names of macros are rare if your header files always name macros in all caps. For instance, the corresponding macros from my header file:
Code:
#define VRAM (u16 *)0x06000000
#define VRAM_BACKBUF (u16 *)0x0600a000

By using names designed not to collide, I don't have any problems.

Quote:
The moral is: #define is evil, wherever possible replace its use.

But can you always trust a compiler to expand an inline function inline and to reduce functions of constant values to constant values themselves? For example, I have the following in my GBA header:
Code:
#define RGB(r, g, b) (((r) << 0) | ((g) << 5) | ((b) << 10))

The inline function equivalent:
Code:
static inline int RGB(int r, int g, int b)
{
  return (((r) << 0) | ((g) << 5) | ((b) << 10));
}

Are C++ compilers guaranteed to expand a pure function inline and reduce it to a constant value when the function is called with constant arguments? Or will I take a performance hit from repeated function calls?

Quote:
You may need to compile as C++ to get maximum benefit but there are plenty of reasons to do that anyway.

Like a larger binary footprint (especially important for multiboot programs)?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#3971 - Paul Shirley - Fri Mar 14, 2003 1:17 am

removed

Last edited by Paul Shirley on Sun Mar 28, 2004 9:54 pm; edited 1 time in total

#3973 - tepples - Fri Mar 14, 2003 5:15 am

Paul Shirley wrote:
(And you're missing a set of brackets in those #defines if you want maximum error checking;)

Actually, that wasn't cut and paste. I just checked my real header files, and they do have the parentheses in the proper places.

Quote:
'Inappropriate use is evil' is probably a better way to put it.

For each developer's definition of "inappropriate".

Quote:
Making things that look like variables or functions is rarely appropriate.

Except when the overhead from renaming your .c files to .cpp and changing clever preprocessor tricks into enum constants and static inline functions is enough to put your binary over the 4 MB mark or your game loop over the 280896 cycle mark because g++ has some optimization deficiencies.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.