Thursday, October 28, 2010
7_Things_Every_Software_Architect_Should_Know
About Flexible Array Members(FAM)
My latest column in LFY is about Flexible Array Members (FAM) - see http://www.lfymag.com/currentissue.asp?id=13 (the article is not available online yet.
For those who dont know that FAM is: FAM is about the C99 feature where the last member of a struct can be an incomplete one. We can allocate memory dynamically for that structure with additional storage for that struct to treat the last element as a flexible lenght array. We remember the size of the allocated array in a member of the struct itself.
So far so good. An LFY reader - Basavaraj Dengi - asked me this intersting question: "when we can use a pointer and keep the things simple,
why use flexible array member?" An interesting question, indeed!
It appears that using FAM member and a pointer are equivalent. For example
struct varlength1 {
int len;
int *data;
};
struct varlength2 {
int len;
int data[];
};
Just think about it - what are the differences here? varlength1 has a *data, and we can allocate the struct statically. Then we need to allocate data with some dynamically allocated memory. What about the struct that is allocate dynamically? We logically do two allocations: one for the struct itself and another for the pointer member inside.
However with varlenght2, we can allocate it statically like this:
struct varlength2 {
int len;
int data[];
} varray { 3, { 1, 2, 3 } };
(This is a GCC feature and I am not sure if its C99), so it is very convenient. Coming to dynamic allocation of varlenght2, we do one dynamic allocation and allocate extra space for the data so that the end of the structure is treated as part of the array. How about doing free of the data? The compiler will obviously give an error, and so we need to do a free once: and that is for the struct.
As we can see, FAM is a convenience feature. Assume that we're writing a program for reading a file which is written according to a simple fileformat (bitmap format comes to my mind, but since I dont remember that format off-my-head, I am not sure if its a very good example for explaining the use of FAM). Now, we read the file header, which is typically a fixed lenght header. The header gives info on the rest of the file, which let us assume, is a simple list of integers. Now, for implementing it, FAM comes handy: as we read the header, we can allocate the struct for that file format once and use that FAM as if we allocated it statically. Freeing that struct is also easy. With a pointer member it is a little more work, but I dont deny it, it will also work.
Get me right: I am not saying using FAM is good and recommended. What I am saying is that FAM is a convenience feature and sometimes we find it as a handy feature to use. Yes, I can hear some of you still murmuring with disapproving my explanation. I see their point: C programmers can live without FAM, just like the K&R C days. But as I said, its just a "convenience" feature. If you want, take it and use it, or you can live with the plain old pointers, and keep going: you make the choice!
cost volatile
It reads as follows: the timer is a const pointer to a long volatile variable. In plain English, it means that the timer is a variable that I will not change; it points to a value that can be changed without the knowledge of the compiler!
So in above case..cost is for "timer " but volatile is for "*timer" (value pointed by timer)...so both r not for same variable
but i cam to know that we can set vloatile and cost for same varibale...i think that also true but i don;t know exact example
Demystifying the ‘Volatile’ Keyword in C
One of my favourite interview questions for novice programmers is: “What is the use of the ‘volatile’ keyword?” For experienced programmers, I ask: “Can we qualify a variable as both ‘const’ and ‘volatile’—if so, what is its meaning?” I bet most of you don’t know the answer, right?
The keyword ‘volatile’ is to do with compiler optimisation. Consider the following code:
long *timer = 0x0000ABCD;
// assume that at location 0x0000ABCD the current time is available
long curr_time = *timer;
// initialize curr_time to value from ‘timer’
// wait in while for 1 sec (i.e. 1000 millisec)
while( (curr_time - *timer) < 1000 )
{
curr_time = *timer; // update current time
}
print_time(curr_time);
// this function prints the current time from the
// passed long variable
Usually, hardware has a timer that can be accessed from a memory location. Here, assume that it’s 0×0000ABCD and is accessed using a long * variable ‘timer’ (in the UNIX tradition, time can be represented as a long variable and increments are done in milliseconds). The loop is meant to wait one second (or 1,000 milliseconds) by repeatedly updating curr_time with the new value from the timer. After a one second delay, the program prints the new time. Looks fine, right?
However, from the compiler point of view, what the loop does is stupid—it repeatedly assigns curr_time with *timer, which is equivalent to doing it once outside the loop. Also, the variable ‘timer’ is de-referenced repeatedly in the loop—when it is enough to do it once. So, to make the code more efficient (i.e., to optimise it), it may modify loop code as follows:
curr_time = *timer; // update current time
long temp_time = *timer;
while( (curr_time - temp_timer) < 1000 )
{ /* do nothing here */
}
As you can see, the result of this transformation is disastrous: the loop will never terminate because neither is curr_time updated nor is the timer de-referenced repeatedly to get new (updated time) values.
What we need is a way to tell the compiler not to ‘play around’ with such variables by declaring them volatile, as in:
volatile long * timer = 0x0000ABCD;
volatile curr_time = *timer;
Now, the compiler will not do any optimisation on these variables. This, essentially, is the meaning of the ‘volatile’ keyword: It declares the variables as ‘asynchronous’ variables, i.e., variables that are ‘not-modified-sequentially’. Implicitly, all variables that are not declared volatile are ‘synchronous variables’.
How about qualifying a variable as both const and volatile? As we know, when we declare a variable as const, we mean it’s a ‘read-only’ variable—once we initialise it, we will not change it again, and will only read its value. Here is a modified version of the example:
long * const timer = 0x0000ABCD;
// rest of the code as it was before..
We will never change the address of a timer, so we can put it as a const variable. Now, remember what we did to declare the timer as volatile:
volatile long * timer = 0x0000ABCD;
We can now combine const and volatile together:
volatile long * const timer = 0x0000ABCD;
It reads as follows: the timer is a const pointer to a long volatile variable. In plain English, it means that the timer is a variable that I will not change; it points to a value that can be changed without the knowledge of the compiler!
Monday, October 25, 2010
BSS
.bss
In computer programming, the name .bss or bss is used by many compilers and linkers for a part of the data segment containing statically-allocated variables represented solely by zero-valued bits initially (i.e., when execution begins). It is often referred to as the "bss section" or "bss segment".
In C, statically-allocated variables without an explicit initializer are initialized to zero (for arithmetic types) or a null pointer (for pointer types). Implementations of C typically represent zero values and null pointer values using a bit pattern consisting solely of zero-valued bits (though this is not required by the C standard). Hence, the bss section typically includes all uninitialized variables declared at the file level (i.e., outside of any function) as well as uninitialized local variables declared with the static keyword. An implementation may also assign statically-allocated variables initialized with a value consisting solely of zero-valued bits to the bss section.
Typically, the program loader initializes the memory allocated for the bss section when it loads the program. Operating systems may use a technique called zero-fill-on-demand to efficiently implement the bss segment (McKusick & Karels 1986). In embedded software, the bss segment is mapped into memory that is initialized to zero by the C run-time system before main() is entered.
Some application binary interfaces also support an sbss segment for "small data". Typically, these data items can be accessed by leaner code using instructions that can only access a certain range of addresses.
Historically, BSS (from Block Started by Symbol) was a pseudo-operation in UA-SAP (United Aircraft Symbolic Assembly Program), theassembler developed in the mid-1950s for the IBM 704 by Roy Nutt, Walter Ramshaw, and others at United Aircraft Corporation[citation needed]. The BSS keyword was later incorporated into FAP (FORTRAN Assembly Program), IBM's standard assembler for its 709 and 7090/94 computers. It defined a label (i.e. symbol) and reserved a block of uninitialized space for a given number of words (Timar 1996).