Forums

I thought I knew it correctly. Either I do either the compiler is buggy :)

In my very first file, Meka.c, the main fonction call a bunch of other functions.
Half of them are inside the Meka.c file, and I had them all INLINEd before.
Removing the INLINE directives for these functions, and Meka freeze when first loading the Japanese BIOS ... go figure.

What is the exact behavior of INLINE before a function?
The functions are declared nor used outside of Meka.c of course.

Quote

> What is the exact behavior of INLINE before a function?
> The functions are declared nor used outside of Meka.c of course.

What compiler are you using?

Quote

> I thought I knew it correctly. Either I do either the compiler is buggy :)

Inline is a tricky bugger. The fact is that it is not in the ANSI C standard, so there is not a universal 'proper' behavior for it (it is in C++ tho), although many C compilers support it. MSVC is careful with it, offering several options for the way INLINE should behave.

IIRC, Meka uses Allegro, meaning it uses DJGPP. I've used 3 main C compilers: DJGPP, Watcom, and MSVC. I have been the, uh, least impressed with DJGPP. I might not be so bold as to call it a compiler 'bug' lest I have 80000 GNU fanatics send me death threats, but it is not behaving the way it should. There could be a compiler option effecting it or something, but basically, you're right, having something inline or not should never make a program crash. I know GCC has some optimizations that conflict with other advanced options from time to time, and I suspect something like this is going on.

I learned something similar the other day... Since emulators involve heavy repetetive procedural calling, esp for functions such as for reading and writing memory, I figured I'd use the simple trick of making my local variables static. Now, I knew, of course, that you have to be a bit careful with static variables, that they cannot be used in a function needing reentrant behavior, for instance. WrZ80 did not need such a thing, tho, so I did:

void WrZ80(word ofs, byte v)
{
word myofs = ofs & 0x3FFF;
...

And I just plopped a 'static' in front of the 'word myofs' definition, since it didn't need to be recursive... Heh, an hour and a half of intensive debugging later, I learned that this is not equivalent. ^_^ the static initialization is only only carried out at startup, of course. I had to change it to:

static word myofs;
myofs = ofs & 0x3FFF;

Ah well. One more thing I now know to avoid. ^_^

Anyhow, I suspect something like this is going on. The weird thing is that REMOVING the inlines is causing you problems, rather than adding them.. Even though it shouldn't make a difference, doing a complete rebuild sometimes helps... Otherwise, you might try the gcc man pages to see if it has any peculiar behaviors with INLINE. What I found with DJGPP is that it has a tendency of 'hiding' errors sometimes. [ie, you might port a DJGPP program to WATCOM and find it crashes a lot -- These are not watcom errors, but bugs in your program that DJGPP tends to cover, often with more lax memory protection, etc.] I suspect that something like this is going on, the procedures might actually have a bug in them, but when DJGPP modified the procedure for INLINEing it, it glossed over this. Dunno.

If you call it a compiler bug, then inevitably some GNU fanatic will show you some obfuscated manpage entry clearly detailing archaic behavior of GCC. It's more likely there are some compiler switches that effect this. But in general GCC is not very intuitive about these things. If you're not already, try compiling on the highest warning level.

- vecna

Quote

>> What is the exact behavior of INLINE before a function?
>> The functions are declared nor used outside of Meka.c of course.
> What compiler are you using?

DJGPP (GCC for DOS) as Vecna guessed :)

Quote

> > I thought I knew it correctly. Either I do either the compiler is buggy :)

All software is buggy. "Lubarsky's law of Cybernetic Entomology: There's always one more bug."

Quote

> Inline is a tricky bugger. The fact is that it is not in the ANSI C standard, so there is not a universal 'proper' behavior for it (it is in C++ tho), although many C compilers support it. MSVC is careful with it, offering several options for the way INLINE should behave.

Heh. And I was wondering why I used macros so much. At least their semantics are known. ^_^

Quote

> IIRC, Meka uses Allegro, meaning it uses DJGPP. I've used 3 main C compilers: DJGPP, Watcom, and MSVC. I have been the, uh, least impressed with DJGPP. I might not be so bold as to call it a compiler 'bug' lest I have 80000 GNU fanatics send me death threats, but it is not behaving the way it should. There could be a compiler option effecting it or something, but basically, you're right, having something inline or not should never make a program crash. I know GCC has some optimizations that conflict with other advanced options from time to time, and I suspect something like this is going on.

I am not so discrete when it comes to complaining about software. Any software. Especially development toolchains (why are they called "chains"? because they are binding and restrictive).

I've been the least impressed with MSVC, myself. Of course, developing for FreeBSD and Linux tends to do that to a person. On the other paw, so, apparently, does developing for Windows. ^_^

As to compiler bugs, GCC is the second buggiest C compiler I know (MSVC is the first, there is no third). I won't go in to the horror stories I've heard about their support of MIPS systems. Of course the main bug in gcc is the developers, who won't do the job right if they already have a "working" solution (did I mention that programs that use sockets are screwed on SGI systems because of this?). At least it doesn't CRASH THE COMPILER when it sees certain (valid) language constructs (MSVC does. Hell, MASM does (otherwise I might have a windows NES emulator by now)).

And as to conflicting options, -fno-frame-pointer is a useful option, but it is hell on debugers and time machines (exception libraries). Not that debuggers are very useful, but I'll tear gdb a new one later.

Quote

> I learned something similar the other day... Since emulators involve heavy repetetive procedural calling, esp for functions such as for reading and writing memory, I figured I'd use the simple trick of making my local variables static. Now, I knew, of course, that you have to be a bit careful with static variables, that they cannot be used in a function needing reentrant behavior, for instance. WrZ80 did not need such a thing, tho, so I did:

> void WrZ80(word ofs, byte v)
> {
> word myofs = ofs & 0x3FFF;
> ...

> And I just plopped a 'static' in front of the 'word myofs' definition, since it didn't need to be recursive... Heh, an hour and a half of intensive debugging later, I learned that this is not equivalent. ^_^ the static initialization is only only carried out at startup, of course. I had to change it to:

> static word myofs;
> myofs = ofs & 0x3FFF;

> Ah well. One more thing I now know to avoid. ^_^

"register word myofs;" Why have it in memory in the first place? Of course, GCC ignores the register keyword. The flipside is that it will register variables according to it's whims. And as far as I can tell, it ignores the volatile keyword as well. Ever try to use longjmp() without it bitching about possibly clobbering variables? The only way to shut it up is to take the address of the variable, even when you shouldn't have to. I don't care where it's documented, it shouldn't do that (at least for the volatile keyword).

Quote

> Anyhow, I suspect something like this is going on. The weird thing is that REMOVING the inlines is causing you problems, rather than adding them.. Even though it shouldn't make a difference, doing a complete rebuild sometimes helps... Otherwise, you might try the gcc man pages to see if it has any peculiar behaviors with INLINE. What I found with DJGPP is that it has a tendency of 'hiding' errors sometimes. [ie, you might port a DJGPP program to WATCOM and find it crashes a lot -- These are not watcom errors, but bugs in your program that DJGPP tends to cover, often with more lax memory protection, etc.] I suspect that something like this is going on, the procedures might actually have a bug in them, but when DJGPP modified the procedure for INLINEing it, it glossed over this. Dunno.

Heh. The number of null pointer dereferences I found when porting from DOS to Linux just isn't funny, some of them were the "how on earth did this run in the first place?" variety. I'd try removing one INLINE at a time, and seeing if it's a problem with just one routine. And if anything, I'd suspect that the problem would be with function parameter semantics (could be "pass by reference", not "pass by value", wouldn't put it past GCC).

Quote

> If you call it a compiler bug, then inevitably some GNU fanatic will show you some obfuscated manpage entry clearly detailing archaic behavior of GCC. It's more likely there are some compiler switches that effect this. But in general GCC is not very intuitive about these things. If you're not already, try compiling on the highest warning level.

Of course, the "obfuscated manpage entry" itself would be a bug. Seriously, I have yet to see any compiler behave in a sane and rational manner concerning documentation. Or inline ASM (though GCC is semi-reasonable about it). etc.

Oh, and the highest warning level is more trouble than it's worth. Just use "-Wall" (the most warnings you can get with just one command-line switch).

Quote

> - vecna

--Nyef

Quote

> I am not so discrete when it comes to complaining about software. Any software. Especially development toolchains (why are they called "chains"? because they are binding and restrictive).

Hehe, well, it's true that all software has bugs. I'm only descrete in general around GNU programs because I find that when I'm not, at least 85% of the linux users present take it as some sort of personal attack, that anyone dare suggest that something that's GNU *might* have a bug, or infact, be absolutely 100% counterintuitive. I guess I just know the wrong linux people. ^_~

Quote

> I've been the least impressed with MSVC, myself. Of course, developing for FreeBSD and Linux tends to do that to a person. On the other paw, so, apparently, does developing for Windows. ^_^

Ah, yes. Well, I had lots and lots of problems with Win98 and MSVC5, but since I've upgraded to Win2k and MSVC6 I haven't encountered any problems (yet). Win98 was so bjorked that it's often hard to tell if an application crash was even the application's fault. Hence, writing a Windows-native SMS emu, so I can play in Win2k. ^_^ I have the most fond memories of WATCOM I think, codegen was amazing at optimizing code (again, not to 'diss' GCC, but porting programs from GCC to WATCOM often lead to up to 20% speed gains). But, Watcom is a bit old by today's standards, has no IDE or debugger system to speak of, and I'm not really sure how good it's windows support is, so I find myself using MSVC these days for Windows programming.

Quote

> And as to conflicting options, -fno-frame-pointer is a useful option, but it is hell on debugers and time machines (exception libraries). Not that debuggers are very useful, but I'll tear gdb a new one later.

Well, yeah. gdb isn't useful. One of the reasons I'm a bit pleased with MSVC is it's the ONLY compiler I've used in the last 4 years (I've haven't tried Borland) with a debugger that's usable in the context that I need it, that being games and graphical programming. The MSVC debugger has actually saved me a LOT of time tracking down CHASMS bugs. Whatever else MSVC has wrong with it, the debugger works, and so I'm happy. ^_^

Quote

> "register word myofs;" Why have it in memory in the first place? Of course, GCC ignores the register keyword. The flipside is that it will register variables according to it's whims. And as far as I can tell, it ignores the volatile keyword as well.

Actually, that's why I didn't use 'register'. I don't know whether or not MSVC even uses it, though there may be an option for it. Actually, if it does automatically 'register'-ize variables, that's fine with me. I don't want to over-use register variables such that it would mess up the code generation in order to accomodate them - I don't know if that ever happens, but, for the time being, I'd rather be safe than sorry. So, static variables isn't as ideal as register, but better than on-the-stack.

Quote

> Heh. The number of null pointer dereferences I found when porting from DOS to Linux just isn't funny, some of them were the "how on earth did this run in the first place?" variety.

Heh, YES! Exactly. That's one of the reasons I have unfond memories of DJGPP. Couldn't get the debugger to work, couldn't get the profiler to work, optimization was not competetive with Watcom or MSVC, and it HIDES BUGS like crazy. Absolutely, lots of times I would be completely amazed that the program ever RAN in DJGPP when I finally tracked down a bug, things like NOT ALLOCATING A POINTER, but using it anyway. I'm MUCH happier with Watcom or MSVC where your program will crash as SOON as you do something goofy like that, rather than it just sort of amalgamating, sometimes-crashing, or having roaming memory corruption.

Quote

> Of course, the "obfuscated manpage entry" itself would be a bug. Seriously, I have yet to see any compiler behave in a sane and rational manner concerning documentation. Or inline ASM (though GCC is semi-reasonable about it). etc.

Yep. I didnt even bother to install the MSVC help stuff, it'd just take up space anyway.

- vecna

Quote

> Hehe, well, it's true that all software has bugs. I'm only descrete in general around GNU programs because I find that when I'm not, at least 85% of the linux users present take it as some sort of personal attack, that anyone dare suggest that something that's GNU *might* have a bug, or infact, be absolutely 100% counterintuitive. I guess I just know the wrong linux people. ^_~

Indeed. You want the people who have given up on Linux in disgust, switched to some form of BSD, and decided that even though it's an improvement, it's still not good enough (now, if I could just get FreeBSD 4.0 installed). ^_^

Quote

> Ah, yes. Well, I had lots and lots of problems with Win98 and MSVC5, but since I've upgraded to Win2k and MSVC6 I haven't encountered any problems (yet). Win98 was so bjorked that it's often hard to tell if an application crash was even the application's fault. Hence, writing a Windows-native SMS emu, so I can play in Win2k. ^_^ I have the most fond memories of WATCOM I think, codegen was amazing at optimizing code (again, not to 'diss' GCC, but porting programs from GCC to WATCOM often lead to up to 20% speed gains). But, Watcom is a bit old by today's standards, has no IDE or debugger system to speak of, and I'm not really sure how good it's windows support is, so I find myself using MSVC these days for Windows programming.

I don't need or want an IDE. I currently use emacs, and it does a lot of those IDE functions in a language-independant manner, and has a "psychoanalyse-pinhead" function. What more does one need? Hrm... with a half-decent DOS emulator, a custom linker, and some work on new libs, one could force watcom's compiler to work on Linux/FreeBSD. Now _there's_ a scary thought.

I suspect that if I were to do any windows programming, I'd use mingw32 or straight ASM. The former because it's a compiler I know how to abuse safely, and the latter because the pain of dealing with the excreble x86 architecture will dull the pain of dealing with the even more excreble win32 API.

Quote

> Well, yeah. gdb isn't useful. One of the reasons I'm a bit pleased with MSVC is it's the ONLY compiler I've used in the last 4 years (I've haven't tried Borland) with a debugger that's usable in the context that I need it, that being games and graphical programming. The MSVC debugger has actually saved me a LOT of time tracking down CHASMS bugs. Whatever else MSVC has wrong with it, the debugger works, and so I'm happy. ^_^

I have found a total of three uses for gdb. First, for finding out where a program crashed (note that if it crashes while working on a CPU core, it won't tell you anything). Second, it makes a handy hex calculator and base converter. Third, it is useful for triggering various bits of code I haven't written UI hookups for.

Quote

> > "register word myofs;" Why have it in memory in the first place? Of course, GCC ignores the register keyword. The flipside is that it will register variables according to it's whims. And as far as I can tell, it ignores the volatile keyword as well.

> Actually, that's why I didn't use 'register'. I don't know whether or not MSVC even uses it, though there may be an option for it. Actually, if it does automatically 'register'-ize variables, that's fine with me. I don't want to over-use register variables such that it would mess up the code generation in order to accomodate them - I don't know if that ever happens, but, for the time being, I'd rather be safe than sorry. So, static variables isn't as ideal as register, but better than on-the-stack.

The problem with static is that it precludes register. And since register is supposedly faster, I'd rather use it.

Quote

> > Heh. The number of null pointer dereferences I found when porting from DOS to Linux just isn't funny, some of them were the "how on earth did this run in the first place?" variety.

> Heh, YES! Exactly. That's one of the reasons I have unfond memories of DJGPP. Couldn't get the debugger to work, couldn't get the profiler to work, optimization was not competetive with Watcom or MSVC, and it HIDES BUGS like crazy. Absolutely, lots of times I would be completely amazed that the program ever RAN in DJGPP when I finally tracked down a bug, things like NOT ALLOCATING A POINTER, but using it anyway. I'm MUCH happier with Watcom or MSVC where your program will crash as SOON as you do something goofy like that, rather than it just sort of amalgamating, sometimes-crashing, or having roaming memory corruption.

This is actually more of a problem with DOS than with DJGPP. Of course, if DJGPP used something reasonable like 0x80000000 for null pointers, this wouldn't be a problem either. It would probably add slightly more complexity to the parser, though (determining if a compare to 0 is in a pointer context or not). Again, if you do your real work on Linux or FreeBSD and port it to DOS with DJGPP, most of these problems disappear.

Quote

> - vecna

--Nyef

First, let me say that I'm not a crazed Linux fan (I don't use linux or GCC), but I would like to point out two things:

1.) The problem Vecna encountered with static variables is actually documented C/C++ behavior. If an initializer is included in a variable declaration, it is only used when the variable name is bound to a storage location. In the case of local variables this happens every time the function is called (since the local variables are created in the stack frame). In the case of static variables this only happens once: when the program is loaded. Basically, the behavior Vecna saw was not a bug with the compiler, that behavior should exist on any C/C++ compiler.

2.) A compiler has the option to ignore the "register" keyword. This, too, is documented C/C++ behavior. A compiler that ignores "register" altogether is still operating within the C/C++ specification. As compilers become "smarter" about code optimization, I imagine that more and more will ignore "register" completely making the keyword all but obsolete.

Finally, I have a question: Can someone explain why the use of static variables is believed to be faster than using local variables?

Eric Quinn

Quote

> First, let me say that I'm not a crazed Linux fan (I don't use linux or GCC), but I would like to point out two things:

> 1.) The problem Vecna encountered with static variables is actually documented C/C++ behavior. If an initializer is included in a variable declaration, it is only used when the variable name is bound to a storage location. In the case of local variables this happens every time the function is called (since the local variables are created in the stack frame). In the case of static variables this only happens once: when the program is loaded. Basically, the behavior Vecna saw was not a bug with the compiler, that behavior should exist on any C/C++ compiler.

Indeed. This wasn't in question at all.

Quote

> 2.) A compiler has the option to ignore the "register" keyword. This, too, is documented C/C++ behavior. A compiler that ignores "register" altogether is still operating within the C/C++ specification. As compilers become "smarter" about code optimization, I imagine that more and more will ignore "register" completely making the keyword all but obsolete.

Exactly. If the compiler ignores the "register" keyword it is either good enough to register them itself, or is so bad that it dosn't optimize at all (gcc obviously follows the middle road of being a pessimizing compiler when used on pentium systems. I'm not kidding). The keyword is, in fact, all but obsolete now.

Quote

> Finally, I have a question: Can someone explain why the use of static variables is believed to be faster than using local variables?

Because the address is resolved at compile time to an absolute reference, instead of being resolved at runtime as an index into the stack. I suspect, however, that someone is forgetting about locality of reference and other cache effects. Not to mention that it will screw up any register optimizations the compiler wishes to perform. ^_^

C'mon people, "Policy, not Mechanism" (now, how many people know what I'm alluding to here?). Let the C compiler worry about how to do what you want, don't try to second-guess it without profiling (before and after), looking at the generated ASM code (before and after), checking if you are using the most efficient algorithms, and so on.

After all, the first rule of optimization is "Don't do it", and the second (for experts only) is "Don't do it yet". Trying to optimize without knowing exactly what's going on (especially when you are trying to get the compiler to do a better job) is a fool's game, and I no longer have any desire to play that game.

Quote

> Eric Quinn

--Nyef

Quote

> > [Cut garbage about "static" keyword and initialization]

> Indeed. This wasn't in question at all.

I apologize. The tone of Vecna's post suggested to me that there was some question about whether the compiler was behaving correctly.

Quote

> > Finally, I have a question: Can someone explain why the use of static variables is believed to be faster
> > than using local variables?

> Because the address is resolved at compile time to an absolute reference, instead of being resolved at
> runtime as an index into the stack. I suspect, however, that someone is forgetting about locality of reference
> and other cache effects. Not to mention that it will screw up any register optimizations the compiler wishes to
> perform. ^_^

These were my suspicions as well. I am not positive that static variables are always the best (fastest) solution. Thank you for your help. (For what it's worth, you and I seem to be on the same page regarding code optimization.)

Eric Quinn

Quote

> These were my suspicions as well. I am not positive that static variables are always the best (fastest) solution. Thank you for your help. (For what it's worth, you and I seem to be on the same page regarding code optimization.)

I'll do one better. I am positive that static variables are not always the best (fastest) solution. In fact, I am more likely to rewrite a routine in ASM (and these days there are two chances of that) than use a static variable (I still use globals for some things, but not for an execution speed benefit).

I actually have some code that uses a lot of static variables. It also uses "evil" as a verb in one of the comments. This was also before I discovered the benefits of libc and stdio.h (think fgets(3)).

Quote

> Eric Quinn

--Nyef

Quote

> I apologize. The tone of Vecna's post suggested to me that there was some question about whether the compiler was behaving correctly.

Nono, I was just using it as an example of times when you might think things are totally whacked, and find there's actually a reasonable, non-bug explaination for it. ^_^

Quote

> These were my suspicions as well. I am not positive that static variables are always the best (fastest) solution. Thank you for your help. (For what it's worth, you and I seem to be on the same page regarding code optimization.)

Just for the hell of it, I decided to do some tests. (In MSVC), I called a simple procedure with three local variables something like a billion times (I forget how many zeroes it was) and timed their execution, with normal, static, and register local variables.

Normal and register were identical timings (within variance), leading me to believe that MSVC probably ignores the register keyword and registers at will. As you suspected, static was slower.

Now I will promptly go take out the very static decls that caused me so much trouble to begin with. ;)

On the very small flipside, I just did the same test out of curiosity with a very large array declared locally, and then static. It was very marginally faster static. (the degree to which it was faster is just barely over the general level of variance you get from running these tests sequentially in windows anyhow, much smaller than the difference from the initial test).

As far as optimizations go, absolutely. Algorthmic optimization is of course whats needed. For instance, my Priority layer method is absolutely horrid right now. I need to optimize it, but not till I take care of more pressing things. ^_^

- vecna

Quote

> Just for the hell of it, I decided to do some tests. (In MSVC), I called a simple procedure with three local variables something like a billion times (I forget how many zeroes it was) and timed their execution, with normal, static, and register local variables.

> Normal and register were identical timings (within variance), leading me to believe that MSVC probably ignores the register keyword and registers at will. As you suspected, static was slower.

> Now I will promptly go take out the very static decls that caused me so much trouble to begin with. ;)

That is very interesting. Thanks for doing the experiment. Perhaps someday someone will create a tutorial on optimizations for emulators.

Any way, take comfort in the fact that your emulator will be slighty faster now that you've done the experiment. :-)

Good luck with your project.

Eric Quinn

Hello :)

I had the same problem with Calypso. The GUI code uses some functions inline, and if you compile it with inline and optimizations, it crash. Try to trap the line in wich exactly the compiler crash, by examinig the output code (the stack) at the crash output. Sorry, but i don't remeber how I solved the problem, but i solved It.

The error may be in a pointer: inlinig the function could use a space of memory totally different from not inlinig the function.

Experience tell me that the 99.9999999% of errors are programmer, not compiler, but it could be..... Post it on a DJGPP newsgroup.

Saludos,

Jose Manuel

Quote

> Just for the hell of it, I decided to do some tests. (In MSVC), I called a simple procedure with three local variables something like a billion times (I forget how many zeroes it was) and timed their execution, with normal, static, and register local variables.

One thing I noticed in my emulator is MSVC does a really good job of optimizing certain sizes of variables. (Mainly 32bit ones.) One place where I saw an huge speed-up by using static variables was in my draw loop where I had a ton of local variables.

My two cents!

- Mike

Quote

> One thing I noticed in my emulator is MSVC does a really good job of optimizing certain sizes of variables. (Mainly 32bit ones.) One place where I saw an huge speed-up by using static variables was in my draw loop where I had a ton of local variables.

Yeah.. well, it's a bit tricky. I suspect the main reason that normal local definitions were so much faster than static in my test was because MSVC probably made them all registers. If you have a ton of variables, then static may once again become faster than allocation of dynamic stack variables. But, you can't really make any generalizations about this, because it depends not only compiler to compiler, but circumstance to circumstance, and really you can only know by testing it out on a function-per-function basis, which can be real time consuming.

- vecna

Author	Message
Zoop Joined: 24 Jun 1999 Posts: 1732 Location: Paris, France	About the inline C directive Posted: Fri Mar 31, 2000 10:06 pm
	I thought I knew it correctly. Either I do either the compiler is buggy :) In my very first file, Meka.c, the main fonction call a bunch of other functions. Half of them are inside the Meka.c file, and I had them all INLINEd before. Removing the INLINE directives for these functions, and Meka freeze when first loading the Japanese BIOS ... go figure. What is the exact behavior of INLINE before a function? The functions are declared nor used outside of Meka.c of course.

Heliophobe Site Admin Joined: 25 Oct 1999 Posts: 2029 Location: Monterey, California	Posted: Fri Mar 31, 2000 11:21 pm
	Quote > What is the exact behavior of INLINE before a function? > The functions are declared nor used outside of Meka.c of course. What compiler are you using?

vecna Guest	Posted: Fri Mar 31, 2000 11:31 pm
vecna Guest	Quote > I thought I knew it correctly. Either I do either the compiler is buggy :) Inline is a tricky bugger. The fact is that it is not in the ANSI C standard, so there is not a universal 'proper' behavior for it (it is in C++ tho), although many C compilers support it. MSVC is careful with it, offering several options for the way INLINE should behave. IIRC, Meka uses Allegro, meaning it uses DJGPP. I've used 3 main C compilers: DJGPP, Watcom, and MSVC. I have been the, uh, least impressed with DJGPP. I might not be so bold as to call it a compiler 'bug' lest I have 80000 GNU fanatics send me death threats, but it is not behaving the way it should. There could be a compiler option effecting it or something, but basically, you're right, having something inline or not should never make a program crash. I know GCC has some optimizations that conflict with other advanced options from time to time, and I suspect something like this is going on. I learned something similar the other day... Since emulators involve heavy repetetive procedural calling, esp for functions such as for reading and writing memory, I figured I'd use the simple trick of making my local variables static. Now, I knew, of course, that you have to be a bit careful with static variables, that they cannot be used in a function needing reentrant behavior, for instance. WrZ80 did not need such a thing, tho, so I did: void WrZ80(word ofs, byte v) { word myofs = ofs & 0x3FFF; ... And I just plopped a 'static' in front of the 'word myofs' definition, since it didn't need to be recursive... Heh, an hour and a half of intensive debugging later, I learned that this is not equivalent. ^_^ the static initialization is only only carried out at startup, of course. I had to change it to: static word myofs; myofs = ofs & 0x3FFF; Ah well. One more thing I now know to avoid. ^_^ Anyhow, I suspect something like this is going on. The weird thing is that REMOVING the inlines is causing you problems, rather than adding them.. Even though it shouldn't make a difference, doing a complete rebuild sometimes helps... Otherwise, you might try the gcc man pages to see if it has any peculiar behaviors with INLINE. What I found with DJGPP is that it has a tendency of 'hiding' errors sometimes. [ie, you might port a DJGPP program to WATCOM and find it crashes a lot -- These are not watcom errors, but bugs in your program that DJGPP tends to cover, often with more lax memory protection, etc.] I suspect that something like this is going on, the procedures might actually have a bug in them, but when DJGPP modified the procedure for INLINEing it, it glossed over this. Dunno. If you call it a compiler bug, then inevitably some GNU fanatic will show you some obfuscated manpage entry clearly detailing archaic behavior of GCC. It's more likely there are some compiler switches that effect this. But in general GCC is not very intuitive about these things. If you're not already, try compiling on the highest warning level. - vecna

Zoop Joined: 24 Jun 1999 Posts: 1732 Location: Paris, France	Posted: Sat Apr 01, 2000 5:47 am
	Quote >> What is the exact behavior of INLINE before a function? >> The functions are declared nor used outside of Meka.c of course. > What compiler are you using? DJGPP (GCC for DOS) as Vecna guessed :)

Nyef Guest	Posted: Sat Apr 01, 2000 1:07 pm
Nyef Guest	Quote > > I thought I knew it correctly. Either I do either the compiler is buggy :) All software is buggy. "Lubarsky's law of Cybernetic Entomology: There's always one more bug." Quote > Inline is a tricky bugger. The fact is that it is not in the ANSI C standard, so there is not a universal 'proper' behavior for it (it is in C++ tho), although many C compilers support it. MSVC is careful with it, offering several options for the way INLINE should behave. Heh. And I was wondering why I used macros so much. At least their semantics are known. ^_^ Quote > IIRC, Meka uses Allegro, meaning it uses DJGPP. I've used 3 main C compilers: DJGPP, Watcom, and MSVC. I have been the, uh, least impressed with DJGPP. I might not be so bold as to call it a compiler 'bug' lest I have 80000 GNU fanatics send me death threats, but it is not behaving the way it should. There could be a compiler option effecting it or something, but basically, you're right, having something inline or not should never make a program crash. I know GCC has some optimizations that conflict with other advanced options from time to time, and I suspect something like this is going on. I am not so discrete when it comes to complaining about software. Any software. Especially development toolchains (why are they called "chains"? because they are binding and restrictive). I've been the least impressed with MSVC, myself. Of course, developing for FreeBSD and Linux tends to do that to a person. On the other paw, so, apparently, does developing for Windows. ^_^ As to compiler bugs, GCC is the second buggiest C compiler I know (MSVC is the first, there is no third). I won't go in to the horror stories I've heard about their support of MIPS systems. Of course the main bug in gcc is the developers, who won't do the job right if they already have a "working" solution (did I mention that programs that use sockets are screwed on SGI systems because of this?). At least it doesn't CRASH THE COMPILER when it sees certain (valid) language constructs (MSVC does. Hell, MASM does (otherwise I might have a windows NES emulator by now)). And as to conflicting options, -fno-frame-pointer is a useful option, but it is hell on debugers and time machines (exception libraries). Not that debuggers are very useful, but I'll tear gdb a new one later. Quote > I learned something similar the other day... Since emulators involve heavy repetetive procedural calling, esp for functions such as for reading and writing memory, I figured I'd use the simple trick of making my local variables static. Now, I knew, of course, that you have to be a bit careful with static variables, that they cannot be used in a function needing reentrant behavior, for instance. WrZ80 did not need such a thing, tho, so I did: > void WrZ80(word ofs, byte v) > { > word myofs = ofs & 0x3FFF; > ... > And I just plopped a 'static' in front of the 'word myofs' definition, since it didn't need to be recursive... Heh, an hour and a half of intensive debugging later, I learned that this is not equivalent. ^_^ the static initialization is only only carried out at startup, of course. I had to change it to: > static word myofs; > myofs = ofs & 0x3FFF; > Ah well. One more thing I now know to avoid. ^_^ "register word myofs;" Why have it in memory in the first place? Of course, GCC ignores the register keyword. The flipside is that it will register variables according to it's whims. And as far as I can tell, it ignores the volatile keyword as well. Ever try to use longjmp() without it bitching about possibly clobbering variables? The only way to shut it up is to take the address of the variable, even when you shouldn't have to. I don't care where it's documented, it shouldn't do that (at least for the volatile keyword). Quote > Anyhow, I suspect something like this is going on. The weird thing is that REMOVING the inlines is causing you problems, rather than adding them.. Even though it shouldn't make a difference, doing a complete rebuild sometimes helps... Otherwise, you might try the gcc man pages to see if it has any peculiar behaviors with INLINE. What I found with DJGPP is that it has a tendency of 'hiding' errors sometimes. [ie, you might port a DJGPP program to WATCOM and find it crashes a lot -- These are not watcom errors, but bugs in your program that DJGPP tends to cover, often with more lax memory protection, etc.] I suspect that something like this is going on, the procedures might actually have a bug in them, but when DJGPP modified the procedure for INLINEing it, it glossed over this. Dunno. Heh. The number of null pointer dereferences I found when porting from DOS to Linux just isn't funny, some of them were the "how on earth did this run in the first place?" variety. I'd try removing one INLINE at a time, and seeing if it's a problem with just one routine. And if anything, I'd suspect that the problem would be with function parameter semantics (could be "pass by reference", not "pass by value", wouldn't put it past GCC). Quote > If you call it a compiler bug, then inevitably some GNU fanatic will show you some obfuscated manpage entry clearly detailing archaic behavior of GCC. It's more likely there are some compiler switches that effect this. But in general GCC is not very intuitive about these things. If you're not already, try compiling on the highest warning level. Of course, the "obfuscated manpage entry" itself would be a bug. Seriously, I have yet to see any compiler behave in a sane and rational manner concerning documentation. Or inline ASM (though GCC is semi-reasonable about it). etc. Oh, and the highest warning level is more trouble than it's worth. Just use "-Wall" (the most warnings you can get with just one command-line switch). Quote > - vecna --Nyef

vecna Guest	Heheh.. Posted: Sat Apr 01, 2000 6:21 pm
vecna Guest	Quote > I am not so discrete when it comes to complaining about software. Any software. Especially development toolchains (why are they called "chains"? because they are binding and restrictive). Hehe, well, it's true that all software has bugs. I'm only descrete in general around GNU programs because I find that when I'm not, at least 85% of the linux users present take it as some sort of personal attack, that anyone dare suggest that something that's GNU might have a bug, or infact, be absolutely 100% counterintuitive. I guess I just know the wrong linux people. ^_~ Quote > I've been the least impressed with MSVC, myself. Of course, developing for FreeBSD and Linux tends to do that to a person. On the other paw, so, apparently, does developing for Windows. ^_^ Ah, yes. Well, I had lots and lots of problems with Win98 and MSVC5, but since I've upgraded to Win2k and MSVC6 I haven't encountered any problems (yet). Win98 was so bjorked that it's often hard to tell if an application crash was even the application's fault. Hence, writing a Windows-native SMS emu, so I can play in Win2k. ^_^ I have the most fond memories of WATCOM I think, codegen was amazing at optimizing code (again, not to 'diss' GCC, but porting programs from GCC to WATCOM often lead to up to 20% speed gains). But, Watcom is a bit old by today's standards, has no IDE or debugger system to speak of, and I'm not really sure how good it's windows support is, so I find myself using MSVC these days for Windows programming. Quote > And as to conflicting options, -fno-frame-pointer is a useful option, but it is hell on debugers and time machines (exception libraries). Not that debuggers are very useful, but I'll tear gdb a new one later. Well, yeah. gdb isn't useful. One of the reasons I'm a bit pleased with MSVC is it's the ONLY compiler I've used in the last 4 years (I've haven't tried Borland) with a debugger that's usable in the context that I need it, that being games and graphical programming. The MSVC debugger has actually saved me a LOT of time tracking down CHASMS bugs. Whatever else MSVC has wrong with it, the debugger works, and so I'm happy. ^_^ Quote > "register word myofs;" Why have it in memory in the first place? Of course, GCC ignores the register keyword. The flipside is that it will register variables according to it's whims. And as far as I can tell, it ignores the volatile keyword as well. Actually, that's why I didn't use 'register'. I don't know whether or not MSVC even uses it, though there may be an option for it. Actually, if it does automatically 'register'-ize variables, that's fine with me. I don't want to over-use register variables such that it would mess up the code generation in order to accomodate them - I don't know if that ever happens, but, for the time being, I'd rather be safe than sorry. So, static variables isn't as ideal as register, but better than on-the-stack. Quote > Heh. The number of null pointer dereferences I found when porting from DOS to Linux just isn't funny, some of them were the "how on earth did this run in the first place?" variety. Heh, YES! Exactly. That's one of the reasons I have unfond memories of DJGPP. Couldn't get the debugger to work, couldn't get the profiler to work, optimization was not competetive with Watcom or MSVC, and it HIDES BUGS like crazy. Absolutely, lots of times I would be completely amazed that the program ever RAN in DJGPP when I finally tracked down a bug, things like NOT ALLOCATING A POINTER, but using it anyway. I'm MUCH happier with Watcom or MSVC where your program will crash as SOON as you do something goofy like that, rather than it just sort of amalgamating, sometimes-crashing, or having roaming memory corruption. Quote > Of course, the "obfuscated manpage entry" itself would be a bug. Seriously, I have yet to see any compiler behave in a sane and rational manner concerning documentation. Or inline ASM (though GCC is semi-reasonable about it). etc. Yep. I didnt even bother to install the MSVC help stuff, it'd just take up space anyway. - vecna

Nyef Guest	Re: Heheh.. Posted: Sun Apr 02, 2000 12:17 am
Nyef Guest	Quote > Hehe, well, it's true that all software has bugs. I'm only descrete in general around GNU programs because I find that when I'm not, at least 85% of the linux users present take it as some sort of personal attack, that anyone dare suggest that something that's GNU might have a bug, or infact, be absolutely 100% counterintuitive. I guess I just know the wrong linux people. ^_~ Indeed. You want the people who have given up on Linux in disgust, switched to some form of BSD, and decided that even though it's an improvement, it's still not good enough (now, if I could just get FreeBSD 4.0 installed). ^_^ Quote > Ah, yes. Well, I had lots and lots of problems with Win98 and MSVC5, but since I've upgraded to Win2k and MSVC6 I haven't encountered any problems (yet). Win98 was so bjorked that it's often hard to tell if an application crash was even the application's fault. Hence, writing a Windows-native SMS emu, so I can play in Win2k. ^_^ I have the most fond memories of WATCOM I think, codegen was amazing at optimizing code (again, not to 'diss' GCC, but porting programs from GCC to WATCOM often lead to up to 20% speed gains). But, Watcom is a bit old by today's standards, has no IDE or debugger system to speak of, and I'm not really sure how good it's windows support is, so I find myself using MSVC these days for Windows programming. I don't need or want an IDE. I currently use emacs, and it does a lot of those IDE functions in a language-independant manner, and has a "psychoanalyse-pinhead" function. What more does one need? Hrm... with a half-decent DOS emulator, a custom linker, and some work on new libs, one could force watcom's compiler to work on Linux/FreeBSD. Now _there's_ a scary thought. I suspect that if I were to do any windows programming, I'd use mingw32 or straight ASM. The former because it's a compiler I know how to abuse safely, and the latter because the pain of dealing with the excreble x86 architecture will dull the pain of dealing with the even more excreble win32 API. Quote > Well, yeah. gdb isn't useful. One of the reasons I'm a bit pleased with MSVC is it's the ONLY compiler I've used in the last 4 years (I've haven't tried Borland) with a debugger that's usable in the context that I need it, that being games and graphical programming. The MSVC debugger has actually saved me a LOT of time tracking down CHASMS bugs. Whatever else MSVC has wrong with it, the debugger works, and so I'm happy. ^_^ I have found a total of three uses for gdb. First, for finding out where a program crashed (note that if it crashes while working on a CPU core, it won't tell you anything). Second, it makes a handy hex calculator and base converter. Third, it is useful for triggering various bits of code I haven't written UI hookups for. Quote > > "register word myofs;" Why have it in memory in the first place? Of course, GCC ignores the register keyword. The flipside is that it will register variables according to it's whims. And as far as I can tell, it ignores the volatile keyword as well. > Actually, that's why I didn't use 'register'. I don't know whether or not MSVC even uses it, though there may be an option for it. Actually, if it does automatically 'register'-ize variables, that's fine with me. I don't want to over-use register variables such that it would mess up the code generation in order to accomodate them - I don't know if that ever happens, but, for the time being, I'd rather be safe than sorry. So, static variables isn't as ideal as register, but better than on-the-stack. The problem with static is that it precludes register. And since register is supposedly faster, I'd rather use it. Quote > > Heh. The number of null pointer dereferences I found when porting from DOS to Linux just isn't funny, some of them were the "how on earth did this run in the first place?" variety. > Heh, YES! Exactly. That's one of the reasons I have unfond memories of DJGPP. Couldn't get the debugger to work, couldn't get the profiler to work, optimization was not competetive with Watcom or MSVC, and it HIDES BUGS like crazy. Absolutely, lots of times I would be completely amazed that the program ever RAN in DJGPP when I finally tracked down a bug, things like NOT ALLOCATING A POINTER, but using it anyway. I'm MUCH happier with Watcom or MSVC where your program will crash as SOON as you do something goofy like that, rather than it just sort of amalgamating, sometimes-crashing, or having roaming memory corruption. This is actually more of a problem with DOS than with DJGPP. Of course, if DJGPP used something reasonable like 0x80000000 for null pointers, this wouldn't be a problem either. It would probably add slightly more complexity to the parser, though (determining if a compare to 0 is in a pointer context or not). Again, if you do your real work on Linux or FreeBSD and port it to DOS with DJGPP, most of these problems disappear. Quote > - vecna --Nyef

Eric Guest	"Static" and "Register" Posted: Mon Apr 03, 2000 4:18 pm
Eric Guest	First, let me say that I'm not a crazed Linux fan (I don't use linux or GCC), but I would like to point out two things: 1.) The problem Vecna encountered with static variables is actually documented C/C++ behavior. If an initializer is included in a variable declaration, it is only used when the variable name is bound to a storage location. In the case of local variables this happens every time the function is called (since the local variables are created in the stack frame). In the case of static variables this only happens once: when the program is loaded. Basically, the behavior Vecna saw was not a bug with the compiler, that behavior should exist on any C/C++ compiler. 2.) A compiler has the option to ignore the "register" keyword. This, too, is documented C/C++ behavior. A compiler that ignores "register" altogether is still operating within the C/C++ specification. As compilers become "smarter" about code optimization, I imagine that more and more will ignore "register" completely making the keyword all but obsolete. Finally, I have a question: Can someone explain why the use of static variables is believed to be faster than using local variables? Eric Quinn

Nyef Guest	Re: "Static" and "Register" Posted: Mon Apr 03, 2000 5:21 pm
Nyef Guest	Quote > First, let me say that I'm not a crazed Linux fan (I don't use linux or GCC), but I would like to point out two things: > 1.) The problem Vecna encountered with static variables is actually documented C/C++ behavior. If an initializer is included in a variable declaration, it is only used when the variable name is bound to a storage location. In the case of local variables this happens every time the function is called (since the local variables are created in the stack frame). In the case of static variables this only happens once: when the program is loaded. Basically, the behavior Vecna saw was not a bug with the compiler, that behavior should exist on any C/C++ compiler. Indeed. This wasn't in question at all. Quote > 2.) A compiler has the option to ignore the "register" keyword. This, too, is documented C/C++ behavior. A compiler that ignores "register" altogether is still operating within the C/C++ specification. As compilers become "smarter" about code optimization, I imagine that more and more will ignore "register" completely making the keyword all but obsolete. Exactly. If the compiler ignores the "register" keyword it is either good enough to register them itself, or is so bad that it dosn't optimize at all (gcc obviously follows the middle road of being a pessimizing compiler when used on pentium systems. I'm not kidding). The keyword is, in fact, all but obsolete now. Quote > Finally, I have a question: Can someone explain why the use of static variables is believed to be faster than using local variables? Because the address is resolved at compile time to an absolute reference, instead of being resolved at runtime as an index into the stack. I suspect, however, that someone is forgetting about locality of reference and other cache effects. Not to mention that it will screw up any register optimizations the compiler wishes to perform. ^_^ C'mon people, "Policy, not Mechanism" (now, how many people know what I'm alluding to here?). Let the C compiler worry about how to do what you want, don't try to second-guess it without profiling (before and after), looking at the generated ASM code (before and after), checking if you are using the most efficient algorithms, and so on. After all, the first rule of optimization is "Don't do it", and the second (for experts only) is "Don't do it yet". Trying to optimize without knowing exactly what's going on (especially when you are trying to get the compiler to do a better job) is a fool's game, and I no longer have any desire to play that game. Quote > Eric Quinn --Nyef

Eric Guest	Re: "Static" and "Register" Posted: Mon Apr 03, 2000 6:42 pm
Eric Guest	Quote > > [Cut garbage about "static" keyword and initialization] > Indeed. This wasn't in question at all. I apologize. The tone of Vecna's post suggested to me that there was some question about whether the compiler was behaving correctly. Quote > > Finally, I have a question: Can someone explain why the use of static variables is believed to be faster > > than using local variables? > Because the address is resolved at compile time to an absolute reference, instead of being resolved at > runtime as an index into the stack. I suspect, however, that someone is forgetting about locality of reference > and other cache effects. Not to mention that it will screw up any register optimizations the compiler wishes to > perform. ^_^ These were my suspicions as well. I am not positive that static variables are always the best (fastest) solution. Thank you for your help. (For what it's worth, you and I seem to be on the same page regarding code optimization.) Eric Quinn

Nyef Guest	Re: "Static" and "Register" Posted: Mon Apr 03, 2000 6:56 pm
Nyef Guest	Quote > These were my suspicions as well. I am not positive that static variables are always the best (fastest) solution. Thank you for your help. (For what it's worth, you and I seem to be on the same page regarding code optimization.) I'll do one better. I am positive that static variables are not always the best (fastest) solution. In fact, I am more likely to rewrite a routine in ASM (and these days there are two chances of that) than use a static variable (I still use globals for some things, but not for an execution speed benefit). I actually have some code that uses a lot of static variables. It also uses "evil" as a verb in one of the comments. This was also before I discovered the benefits of libc and stdio.h (think fgets(3)). Quote > Eric Quinn --Nyef

vecna Guest	Re: "Static" and "Register" Posted: Tue Apr 04, 2000 12:46 am
vecna Guest	Quote > I apologize. The tone of Vecna's post suggested to me that there was some question about whether the compiler was behaving correctly. Nono, I was just using it as an example of times when you might think things are totally whacked, and find there's actually a reasonable, non-bug explaination for it. ^_^ Quote > These were my suspicions as well. I am not positive that static variables are always the best (fastest) solution. Thank you for your help. (For what it's worth, you and I seem to be on the same page regarding code optimization.) Just for the hell of it, I decided to do some tests. (In MSVC), I called a simple procedure with three local variables something like a billion times (I forget how many zeroes it was) and timed their execution, with normal, static, and register local variables. Normal and register were identical timings (within variance), leading me to believe that MSVC probably ignores the register keyword and registers at will. As you suspected, static was slower. Now I will promptly go take out the very static decls that caused me so much trouble to begin with. ;) On the very small flipside, I just did the same test out of curiosity with a very large array declared locally, and then static. It was very marginally faster static. (the degree to which it was faster is just barely over the general level of variance you get from running these tests sequentially in windows anyhow, much smaller than the difference from the initial test). As far as optimizations go, absolutely. Algorthmic optimization is of course whats needed. For instance, my Priority layer method is absolutely horrid right now. I need to optimize it, but not till I take care of more pressing things. ^_^ - vecna

Eric Guest	Re: "Static" and "Register" Posted: Tue Apr 04, 2000 1:27 am
Eric Guest	Quote > Just for the hell of it, I decided to do some tests. (In MSVC), I called a simple procedure with three local variables something like a billion times (I forget how many zeroes it was) and timed their execution, with normal, static, and register local variables. > Normal and register were identical timings (within variance), leading me to believe that MSVC probably ignores the register keyword and registers at will. As you suspected, static was slower. > Now I will promptly go take out the very static decls that caused me so much trouble to begin with. ;) That is very interesting. Thanks for doing the experiment. Perhaps someday someone will create a tutorial on optimizations for emulators. Any way, take comfort in the fact that your emulator will be slighty faster now that you've done the experiment. :-) Good luck with your project. Eric Quinn

Jose Manuel Delgado Mendi Guest	Posted: Tue Apr 04, 2000 9:09 pm
Jose Manuel Delgado Mendi Guest	Hello :) I had the same problem with Calypso. The GUI code uses some functions inline, and if you compile it with inline and optimizations, it crash. Try to trap the line in wich exactly the compiler crash, by examinig the output code (the stack) at the crash output. Sorry, but i don't remeber how I solved the problem, but i solved It. The error may be in a pointer: inlinig the function could use a space of memory totally different from not inlinig the function. Experience tell me that the 99.9999999% of errors are programmer, not compiler, but it could be..... Post it on a DJGPP newsgroup. Saludos, Jose Manuel

Michael Montague Guest	Re: "Static" and "Register" Posted: Wed Apr 05, 2000 8:43 pm
Michael Montague Guest	Quote > Just for the hell of it, I decided to do some tests. (In MSVC), I called a simple procedure with three local variables something like a billion times (I forget how many zeroes it was) and timed their execution, with normal, static, and register local variables. One thing I noticed in my emulator is MSVC does a really good job of optimizing certain sizes of variables. (Mainly 32bit ones.) One place where I saw an huge speed-up by using static variables was in my draw loop where I had a ton of local variables. My two cents! - Mike

vecna Guest	Re: "Static" and "Register" Posted: Wed Apr 05, 2000 9:11 pm
vecna Guest	Quote > One thing I noticed in my emulator is MSVC does a really good job of optimizing certain sizes of variables. (Mainly 32bit ones.) One place where I saw an huge speed-up by using static variables was in my draw loop where I had a ton of local variables. Yeah.. well, it's a bit tricky. I suspect the main reason that normal local definitions were so much faster than static in my test was because MSVC probably made them all registers. If you have a ton of variables, then static may once again become faster than allocation of dynamic stack variables. But, you can't really make any generalizations about this, because it depends not only compiler to compiler, but circumstance to circumstance, and really you can only know by testing it out on a function-per-function basis, which can be real time consuming. - vecna

Forums

View topic - About the inline C directive