Crazy ABI Layout Rules

A couple of years ago, EDG was invited to participate in the development of an ABI (Application Binary Interface) for C++ on the Itanium architecture. The weekly development meetings ocurred in the Bay Area (SGI facilities), and since I lived close to there at the time, I represented EDG.

For the C language, the ABI consists of data layout rules, calling conventions, object file format specs, and a few other relatively simple choices. For C++, however, things are harder: layout of base classes, virtual function dispatch (and the data structures associated therewith), exception handling, name mangling, and RTTI offer a much larger variety of options to disagree on. The “holy C++ ABI grail,” then, is to be able to seemlessly blend libraries from different vendors in a single application.

I hear you say “But what about templates?” Good reflex, but forget about those for now. Instead, let me rant about a more basic topic: Laying out subobjects in memory.

Consider the following piece of code:

struct D: B1, B2 {

  int i;

};

An object of type D contains three direct subobjects: a field i and two base subobjects (of types B1 and B2 respectively). Most of the time, each of these subobjects take up some bytes of memory within the sizeof(D) bytes occupied by D. One exception is that if a base class type is “empty” it may be optimized not to take up any space at all. Still, an optimized empty base class (OEBC) must have its own address.

Until now, I always assumed that direct subobjects cannot overlap. Specifically, in the example above, I would expect the base subobject of type B1 to take up the first zero or more bytes of a D object, then the subobject of type B2 would follow with perhaps an alignment gap between the two bases, and finally the integer field would take up four bytes or so. The ordering of these three parts may be different for different ABIs, and it may even depend on the kind of base classes (e.g., if B2 has virtual functions and B1 does not, it is not uncommon for ABIs to place the subobject of type B2 first).

In the IA-64 ABI however, the nonoverlap principle need not hold. Indeed, if the base class types are defined as follows:

struct B1 {};

struct B2: B1 {};

then the base subobject of type B2 ends up inside the field of type int.

That, in my opinion, is crazy.

Off To The Printer...

C++ Templates is now officially complete. The proofed manuscript was sent to the printer earlier this week. It took incredibly long to get this one out of the door. Well over four years, in fact. If it weren't for Nico's help, I'd still be trying to get it finished.

Fortunately, the reviews have been stellar so far. One well-known C++ guru even sent us a personal note saying that he is dropping his own plans for a book on that topic because ours meets all his needs.

Overhaul

The web site is being further updated. A core change is that Movable Type is used to update the news pages. Other than that, the tables will now have a “sculpted&rdquo look. It's lighter on the eyes, but heavier on the pipes. The main page already reflects the new design, but most other pages still need updating.

Deciding on a browser...

Lately I've been rethinking my browser choice. Until last month, OmniWeb was easily my preferred browser.

Recently I ran into problems while trying various CSS-intensive pages (including the Movable Type administration pages). I already was keeping a Microsoft browser on my laptop for the occasional banking site that didn't deal with OmniWeb very nicely. Fortunately, I rarely bank on-line. On the other hand, I anticipate I might use Movable Type more often in the future. So I first downloaded Netscape 7... but it really did not do it for me. I am not too excited about Mozilla either. Chimera, on the other hand, looks promising (although visually it still does not match OmniWeb). It renders HTML GUI elements using Aqua and it has tabbed browsing.