Airs - Ian Lance Taylor

According to the U.S. census, median household income in the U.S. has not changed much since 1998. The economy does continue to expand. What is happening is that the richer households are absorbing all the gains, leading to increased inequality. I’ve commented before on whether or not this matters.

I’ve now seen a couple of attempts to argue against this, on the basis that household sizes are shrinking. The argument is that when the household gets smaller, then even if the household has the same amount of money, there is more money per person.

Unfortunately, this argument is too simple. A household has fixed expenses which remain the same regardless of the number of people. One obvious fixed expense is the cost of the house itself. If the cost of housing as a proportion of household income has increased faster than the size of the household has decreased, then the argument does not hold.

It is also quite possible that the earnings-per-person of a single parent living alone has increased, while the earnings-per-person of a single parent living with children has decreased. That would maintain the same statistics, but would suggest that more children are living with fewer resources, which would seem to be undesirable.

More importantly, I think this type of argument is somewhat off-the-point. I think what matters to most people is stability of shelter, food, and health care. Stability of income is acceptable provided those prices are stable. Instability of income is rarely desirable. So the whole issue of tracking average household income seems much less interesting to me than tracking income stability for families in different economic strata.

What should a society seek to provide for its members? The most basic goals have to be the survival of members of the society and inducting new members into the society. Any society which can not achieve these goals will fail. (The most obvious way to induct new members is to have children, but there are successful micro-societies formed entirely from immigration, such as the Vatican.)

There are many choices beyond the basics. Some popular choices seem to be freedom; security; stability; opportunity; happiness; religious adherence; ethics; perpetuation of the power of the leader(s); support of a given ethnic group. Of course all societies have these goals and many others in different proportions, but different societies emphasize different ones. Is it possible to decide which ones are best?

In particular, is it possible to decide which ones are best if we know that different societies exist? A society which loses its members due to emigration or invasion would seem to be unsuccessful. The required security may conflict with other goals.

But if we speak too seriously about goals like survival of the society, and protection against other societies, then we are heading down the path of equating “good” with “survival,” which also pretty quickly leads us to determine that the societies which exist today are the best ones so far. Is this reasonable? Can we speak of an ideal society which existed once but no longer exists? Presumably an ideal society ought to be able to cope with natural disasters of at least intermediate scope—e.g., short of the sinking of Atlantis. Or what if the ideal society emphasizes freedom, and everybody chooses to leave?

But if survival is not the major goal, then what is? Since different societies have different ethical beliefs, how can we choose among them? If we think they are wrong, and they think we are wrong, then how can we decide? Determining the ideal society would seem to require first developing a universal ethics.

I was talking to my daughter about how anybody could put anything on the Internet. She was surprised by that, and indeed it is kind of incredible. There was nothing like that when I was young: a way for any random person to speak to any other random person. Of course, as I’ve said before, this is both good and bad. A good aspect is the increased ability to communicate, and a bad aspect is the increased ability to filter all your communication through like-minded people.

Anyhow, my daughter wanted to put something on the Internet, so she is hijacking today blog’s post (though I am doing the typing). This is a song she wrote all by herself. This is sung to the song of Twinkle, Twinkle, Little Star, though it is slightly shorter.

Twinkle, twinkle, little diamond
How I wonder what you’re made of
Up above the world so high
It’s a diamond near the sky
Mountains they grow very high
They can almost touch the sky

How does the gcc compiler get written? Who works on it and why? It seems to puzzle some people.

There are vast numbers of free software projects these days, far more than I try to keep track of. Among these, gcc is unusual in several respects.

• gcc is more than 20 years old as an active free software project.
• gcc has a large number of active contributors.
• gcc is not associated with any single company or organization.
• gcc has a relatively informal organizational structure.
• gcc has no single central maintainer.
• there is significant commercial interest in gcc.
• gcc has survived a significant shift in organizational approach: the egcs fork back in 1997, which eventually took over as the mainline of gcc development.

What people seem to find most confusing is that gcc has no central governing body. It is a collection of people who cooperate following loosely specified rules. Many of those people are volunteers who are interested in compilers. Many, perhaps a majority, work for companies which have a commercial interest in gcc.

No single party decides what to implement in gcc. Instead, different people work on projects for reasons of their own. As these projects near completion, they are loosely coordinated by the release managers (until recently, there was only one release manager) who decides in which order they should come into mainline. The release manager does not reject projects.

gcc has a steering committee, but the committee does not make technical decisions, and does not decide what code will be written. The main effect of the steering committee is to appoint maintainers for different parts of gcc. This is considerable power, but in practice the steering committee has not chosen to wield it. There have been essentially no controversies about choices of maintainers–the closest to a controversy has been discussions about which contri buting organizations may have too many maintainers.

How does the gcc community decide to work on something? Somebody puts forward a proposal and works on it. If it needs more than one person, he or she gathers interest and tries to convince people to help. There is no central directive to work on anything, although there is a list of suggested projects.

How does the gcc community reject a contribution? There are certain required guidelines: a copyright assignment for the code, various formatting and documentation requirements. The code obviously has to work, and it has to not make the compiler significantly slower or otherwise worse. Given those, pretty much the only way a contribution gets rejected is for somebody else to develop an alternative which makes the first contribution unnecessary.

How does the gcc community fix bugs? One way is that releases are not made until the number of open bugs is reduced to a certain level. This encourages anybody interested in the release to work on bugs. The other way is that some companies have a commercial interest in high quality releases; they direct their employees to fix bugs.

How did this haphazard project produce a widely used compiler, probably second only to Microsoft Visual C++? The compiler is not tied to any single organization, which means that it keeps going even when organizations fail. Because the compiler is widely used, many people benefit from improving it. Because it is free, many people are able to improve it.

gcc is a clear success story in the free software world. Of course it has problems, but I don’t think it has any structural problems which will prevent it from continuing on for many years in the future.

The volatile qualifier in C/C++ is widely misunderstood. Because it is described so vaguely in language standards, many people interpret it as a do-what-I-mean qualifier.

What the standard says is that accesses to volatile objects must be evaluated strictly according to the abstract machine defined by the language standard; this means that if the C/C++ code reads the volatile object twice, then the machine code must do so as wel. The standard says that volatile objects must be stable at sequence points; this means, approximately, that in between statements all reads and writes of volatile objects must have been completed–the value may not be cached in a register. The standard makes clear that it is possible that the values of volatile objects may change in some unknown way between accesses.

One relatively unimportant misunderstanding is due to the fact that the standard only talks about accesses to volatile objects. It does not talk about accesses via volatile qualified pointers. Some programmers believe that using a pointer-to-volatile should be handled as though it pointed to a volatile object. That is not guaranteed by the standard and is therefore not portable. However, this is relatively unimportant because gcc does in fact treat a pointer-to-volatile as though it pointed to a volatile object.

A way to think about volatile is to observe that it was invented to support memory mapped hardware. Some hardware is controlled by accesses to specific memory addresses. For example, a serial controller often handles input by setting a bit in one memory location and making the new byte available in another memory location. The kernel code must observe that the bit is set, read the byte, and set another bit to tell the serial controller that the byte has been read (I’m skipping the interrupt which is also involved). These accesses should use volatile to make sure that they happen in the exact order written in the program.

The standard also explicitly describes two other uses of volatile. One is for setjmp and is relatively uninteresting. The other is that a variable of type volatile sig_atomic_t may be set in a signal handler and read by code outside the signal handler. In fact, just about all that a portable signal handler may do is set such a variable.

For dealing with memory mapped hardware, volatile is exactly what you want. For most other types of code, including multi-threaded code, volatile does not help.

Using volatile does not mean that the variable is accessed atomically; no locks are used. Using volatile does not mean that other cores in a multi-core system will see the memory accesses; no cache flushes are used. While volatile writes are guaranteed to occur in the program order for the core which is executing them, there is no guarantee that any other core will see the writes in the same order. Using volatile does not imply any sort of memory barrier; the processor can and will rearrange volatile memory accesses (this will not happen for address ranges used for memory mapped hardware, but it will for ordinary memory).

Conversely, if you use the locking primitives which are part of any threading library, then you do not need to use volatile. The locking primitives will include the required memory barriers or cache flushes. They will include whatever special directives are needed to tell the compiler that memory must be stable.

There is one case where volatile may be used for multi-threaded programming with some reliability. You may use a single volatile sig_atomic_t variable to communicate between threads, much as you may use such a variable to communicate between a signal handler and the main program. You should not use more than one such variable to communicate between any pair of threads, as there is no guarantee that the different threads will see the accesses in the same order.

In summary, if you are using volatile for anything other than manipulating memory mapped hardware, or for very limited communication between threads, it is very likely that you are making a mistake. Think carefully about what volatile means and about what it does not mean.