Funny C Rules (And Low-Level Languages in general)

[revelator]

just jerking his chains a bit but indeed its an int.

something to look out for if typecasting also since it does not change the underlaying type so results might not be what one would expect.
Hmm one thing that has allways baffled me is byte types or unsigned char, do they also fall back to int or is there more to them ?.
range from experience is 0 - 255 and theres actually a rather nasty bug in the vanilla doom3 font code that assumes a negative byte value,
which every static analyzing tool i have tried on it screams to me that byte values cannot be negative. funny enough most compilers let it pass anyway heh.

[Baker]

Just discovered that CodeBlocks has Swap Headers which switches between source and header. i.e. swap between, as an example, "common.c" and "common.h".

I like that feature in XCode which is default Ctrl + Alt + UP.

[mankrip]

[Baker]

[Baker]

What is the best way to print a date and time to file
--- and read it back.

--- Without spaces in it?

[mankrip]

[Baker]

[revelator]

another one to take note of is the pre incremeting and post incrementing used in counters and loops.

this one can be a bit tricky example

int i = 0; ConsoleWrite(++i); = 1 or 1+i
int i = 0 ConsoleWrite(i++); = 0 or 0+i

in a for loop its allways 0 if for (i = 0; i < something; i++ or ++i) unless you do things a bit different
so as one can see this can easily fool an unexperienced programmer into beliving that the loop counter starts at 1 and not 0

[mankrip]

I don't think it's that easy to fool, because programmers usually know that the increment portion of the loop is only executed after its contents.

However, for (i = 0; i < --something; i++) could fool, due to the comparison being executed before the contents.

[revelator]

One should think but i actually seen devs who made that mistake more times than you think hehe.
Theres a fine example of it in the vanilla doom3 sources just try to run clang on it as a static code analyzer and get the popcorn .
Honest mistake though since the dev seems to have just copy pastaed the code piece in question but forgot to check the return .

[mankrip]

[Spike]

Memory references should be expected to be slower than (fairly fast) register operations. a bitshift will take only one clock, while memory references can easily take many many more.
Memory access is FAR from free - especially if it means that other locals can no longer be stored in a register either.
The memory accesses also mean that the compiler probably doesn't know whether the value actually changes, so any loop unrolling optimisations go out of the window too.
Also, your code violates C's strict aliasing rules.

[mankrip]

[toneddu2000]

[Spike]

well, modern cpus have tricks that allow the cpu to do all sorts of things asynchronously, which allows certain things to take less than a clock if its simple enough for the instruction decoding to rearrange things. memory references are far from simple, so try to prevent the compiler from spilling locals to stack
cpus have limited associativity, which means that if you start reading/writing some new location, the cpu will forget somewhere else and re-accessing somewhere that was forgotten will incur a stall as it repopulates from a higher level cache. if that means that it needs to re-read from system ram, then expect a large stall. If you have two CPUs/GPUs trying to write the same memory region then you'll find that they will constantly purge the other's cache of that region (the alternative is worse...).

regarding structs/unions, I wouldn't worry about the offset. if its on the stack then esp+(offset) is identical to esp+(offset+2). globals don't need the esp part, of course. either way you no longer need a separate register to hold the pointer's value, so more registers for your actual maths.

remember that the x86 only has 8 registers (amd64 raises that to 16). and many of them are reserved for specific purposes. So if you need to hold many variables at a time, you'll end up spilling all your variables to stack, and now each reference to those variables will need load+store operations too. constants can often be embedded in the instructions themselves, which helps reduce cache misses etc.

c99's __restrict keyword might be useful to you, as it allows greater freedom by letting the compiler know that writes will not change other memory addresses. this isn't normally an issue for locals if nothing needed an address to them, but your code decided to take an address to it, and now it might need to read the pointer and THEN dereference it as two separate operations. and only then can it read from it.

Or something.

If this stuff is important to you, you should really try and figure out how to use cachegrind - http://valgrind.org/docs/manual/cg-manual.html
For raw clock costs, you should use something like gprof (which requires compiler instrumentation). Expect different results on different cpus (especially but not just with different instruction sets), or even with each run (interrupts etc will flush caches, which will affect reported costs).