Constant and variable

tryphon · Post by **tryphon** » Fri Jan 02, 2015 11:38 pm

This question sounds stupid, but up to now (coding for PCs), I never wondered if an object must be stored in ROM or RAM. Everything was RAM

So must I take for granted that, if I declare something 'const', it will be created in ROM by the compiler. Or is there anything else ?

djcouchycouch · Post by **djcouchycouch** » Sat Jan 03, 2015 2:04 am

Generally yes. If you're declaring an array and want to have it in rom, the const has to be specified like this:

u16 const myArray[] = {whatever};

tryphon · Post by **tryphon** » Sat Jan 03, 2015 9:42 am

Thanks

sega16 · Post by **sega16** » Tue Jan 06, 2015 1:32 am

Also if you are using the array in only one file make sure to make it static. Same with functions. This is especially important for functions and applies regardless of platform you should always when appropriate declare make proper use of const and use it whenever what you are dealing with is const and when used in one file always declare as static. Don't think that better hardware should allow you to forget good coding practices. Making the function static allows the compiler to do additional optimizations based upon use of the function such as constant propagation. For example lets say you have a function

Code: Select all

static inline void writePixel(unsigned x,unsigned y,unsigned w,unsigned val){
	vram[x+y*w]=val;
}

You always call the function with the same w value. w happens to be 256 always. If the compiler knew that w was always 256 it could replace the multiplication with a bit shift and inline it maybe even without declaring it as such if the decided that inlining has no negative tradeoffs. Despite enabling link time optimizations I have still got better code declaring functions as static when appropriate. I even checked the generated machine code.
Also while I am at it another tip make when appropriate make use of the restrict keyword and attributes such as pure for example lets say you wrote a square root function. Declare it pure, a square root function should be a pure function anyway.

Chilly Willy · Post by **Chilly Willy** » Tue Jan 06, 2015 4:51 am

Things like restrict might be why certain tests of new versions of gcc seem slower than old ones. Old gcc probably made lots of assumptions for speed that have since been deemed bugs that require things like restrict to enable. Using new versions of gcc requires more knowledge of attributes and how they affect optimizations to get similar results, but should result in more stable code.

tryphon · Post by **tryphon** » Tue Jan 06, 2015 8:16 am

Thanks for the tips.

Last time I coded in C, it didn't have attributes

Chilly Willy · Post by **Chilly Willy** » Tue Jan 06, 2015 8:23 pm

tryphon wrote:Thanks for the tips.

Last time I coded in C, it didn't have attributes

When I started, all there was was K&R. Standards didn't come along until later.

I remember when I finally got SAS/C - it came with this monster book on C as implemented by SAS. That was kinda the standard for a long time as SAS became popular on a lot of platforms.

tryphon · Post by **tryphon** » Tue Jan 06, 2015 8:35 pm

You win

sega16 · Post by **sega16** » Wed Jan 07, 2015 12:38 am

tryphon wrote:Thanks for the tips.

Always glad to help.

tryphon wrote: Last time I coded in C, it didn't have attributes

That is because this is a gcc extension see https://gcc.gnu.org/onlinedocs/gcc/Func ... butes.html.

Chilly Willy · Post by **Chilly Willy** » Wed Jan 07, 2015 6:56 pm

tryphon wrote:You win

All right! What's my prize?

You could have come back with a story about there not being C compilers, thus forcing you to compile the code in your head.

tryphon · Post by **tryphon** » Wed Jan 07, 2015 10:19 pm

I actually did this with 6809 asm (not C), at the time I owned a MO6 (only French can know what it is).

Branchment instructions to compute in hex was such a fun

I was 13 then...
Time flies...

Chilly Willy · Post by **Chilly Willy** » Thu Jan 08, 2015 12:09 am

tryphon wrote:I actually did this with 6809 asm (not C), at the time I owned a MO6 (only French can know what it is).

Branchment instructions to compute in hex was such a fun

I was 13 then...
Time flies...

I was so fluent in 6502 (had an Atari 8-bitter back then), I could read the code from the hex dump, and change it via a hex-editor. I was nearly as good with 68000 assembly code - I can read the hex dump pretty good, but it's a bit of a stretch to convert from assembly back to hex in my head... other than some of the more common codes, like jumps and branches and the like.

I know quite a few programmers on that level. It was easier to reach on 8-bit systems. Forget about it on new systems. Most don't bother even learning assembly these days. It's slowly passing away.