#AltDevBlogADay » Alex Darby

C/C++ Low Level Curriculum Part 12: Multiple Inheritance

Alex Darby — Wed, 22 May 2013 11:16:20 +0000

Hello, and welcome to the 12th part of the C / C++ low level curriculum. Really soon after part 11! (No, of course part 11 didn’t get too big and need to be split. Why would you ask?)

Last time we looked at the basics of how inheritance was implemented at the low level; and this time we’re going to examine how using multiple inheritance affects this picture (note: we’re leaving the keyword virtual til next time).

Before We Begin

I will assume that you have already read the previous posts in the series, but I will also put in-line links to any important terms or concepts that you might need to know about to make sense of what you’re reading. I’m helpful like that.

Another big assumption I’m going to make is that you’re already very familiar with the language features of C++ and comfortable using the language features we’re discussing. If I need to demonstrate anything out of the ordinary I’ll explain it – or at least link to an explanation.

In this series I discuss what happens with vanilla unoptimised win32 debug code generated by the VS 2010 compiler – whilst the specifics will differ on other platforms (and probably with other compilers) the general sweep of the code should be basically the same – because it’s assembly that has been generated by a C++ compiler – and so following the same examples given here with a source / disassembly debugger on your platform of choice should provide you with the same insights we get here.

With this in mind, in case you missed them, here are the backlinks to the previous posts in the series:

I won’t lie – it’s not light reading :)

I’ve just read post 11 and it all seemed pretty obvious…

Good! It should do!

In my experience, most good solutions to problems appear obvious when explained well ;)

Now we’ve got an understanding of how single inheritance behaves, let’s examine how multiple inheritance affects this picture…

Multiple Inheritance

Sample time!

Like last time I have lovingly zipped up a hand-crafted VS2010 solution / project / source code combo to go with this sample which contains the following code:

class CTestBaseOne
{
public:
    int _iA;
    int _iB;
 
    CTestBaseOne( int iA, int iB )
    : _iA( iA )
    , _iB( iB )
    {}
 
    int SumBase( void )
    {
        return _iA + _iB;
    }
};
 
class CTestBaseTwo
{
public:
    int _iC;
    int _iD;
 
    CTestBaseTwo( int iC, int iD )
    : _iC( iC )
    , _iD( iD )
    {}
 
    int SumBaseTwo( void )
    {
        return _iC + _iD;
    }
};
 
class CTestDerived
: public CTestBaseOne
, public CTestBaseTwo
{
public:
    int _iE;
    int _iF;
 
    CTestDerived( int iA, int iB, int iC, int iD )
    : CTestBaseOne ( iA, iB )
    , CTestBaseTwo ( iC, iD )
    , _iE ( iB )
    , _iF ( iD )
    {}
 
    int SumDerived( void )
    {
        return return SumBase() + SumBaseTwo() +_iE + _iF;
    }
};
 
int main( int argc, char* argv[] )
{
    CTestBaseOne    cTestBaseOne( argc, argc + 1 );
    CTestBaseTwo    cTestBaseTwo( argc, argc + 1 );
    CTestDerived    cTestDerived( argc, argc + 1, argc + 2, argc + 3 );
 
    return      cTestBaseOne.SumBase()  + cTestBaseTwo.SumBaseTwo() 
            +   cTestDerived.SumBase()  + cTestDerived.SumBaseTwo() + cTestDerived.SumDerived();
}

Once you’ve unzipped it, go ahead and build it.

Don’t forget to pay attention to the build output – it shows the memory layout which we’re going to talk about next.

Memory Layout

As you can see, we now have two base classes, and one class that derives from both of them.

When you build the project, you should see that the memory layout of these classes looks like this:

1>  class CTestBaseOne	size(8):
1>  	+---
1>   0	| _iA
1>   4	| _iB
1>  	+---
1>  
1>  class CTestBaseTwo	size(8):
1>  	+---
1>   0	| _iC
1>   4	| _iD
1>  	+---
1>   
1>  class CTestDerived	size(24):
1>  	+---
1>  	| +--- (base class CTestBaseOne)
1>   0	| | _iA
1>   4	| | _iB
1>  	| +---
1>  	| +--- (base class CTestBaseTwo)
1>   8	| | _iC
1>  12	| | _iD
1>  	| +---
1>  16	| _iE
1>  20	| _iF
1>  	+---

This is all as we might expect – given what we found out last time.

In particular note that:

the memory layout of both base classes is embedded into CTestDerived
CTestBaseOne and CTestBaseTwo appear in the memory layout in the same order they are declared in the base-specifier-list of CTestDerived.

n.b. the base-specifier-list is the part of the declaration of a class where the base classes are specified.

In the simple case of single inheritance we considered in the last post, we saw that the functions of a base class B could be called on instances of a derived class D because:

the memory layout of D contains a literal instance of B at an offset of 0 bytes within itself and…
…this means that the member data of an instance of B is at the same offset relative to the memory layout of an instance of D…
…and so the hard coded offsets used to access these members within functions belonging to B are also valid for instances of D

Looking at the memory layout for this multiply inherited class we can see that:

this relationship still holds for CTestBaseOne and CTestDerived - CTestBaseOne is an an offset of 0 bytes within the memory layout of CTestDerived
however, this same relationship is not true of CTestBaseTwo and CTestDerived

Given this situation, how do functions of CTestBaseTwo work with instances of CTestDerived?

As usual the best thing to do do is take a look…

Calling a function of CTestBaseTwo on CTestDerived

Put a breakpoint on the return statement from main(), run the code, and when it stops right click then choose ‘Go To Disassembly’.

Rather than paste the disassembly as text this time, I’ve inserted a screenshot of my debugger window – this allows more formatting and highlighting options.

N.B. in this screenshot I have “Show symbol names” checked under viewing options. Whilst this typically makes it easier to relate disassembly to C or C++ code, it does hide detail (i.e. the addresses of the symbols) .

Let’s pick this apart then, starting at the current line indicator where the breakpoint is and working down:

we can see that (following the x86 thiscall convention) before each function is called, the address of the corresponding object is stored into ecx using lea.
First it loads the address of cTestDerived into ecx and then calls CTestDerived::SumDerived()…
then it…
Oh, wait… it’s loading the address [ebp-20h] into ecx…
that symbol isn’t resolving in the disassembly window, so what witchcraft is this!?

I have helpfully highlighted the most salient areas of the screenshot with red boxes :)

If you look at the function calls made in the disassembly, and compare them to the calls in the C++ code, you will see that all of the high level function calls have an analogue at the assembly level except for cDerived.SumBaseTwo().

CTestBaseTwo::SumBaseTwo is getting called, but with [ebp-20h] as the this pointer in ecx, not [cTestDerived] (n.b. see the top red box in the screenshot).

So, the question is: how does the address [ebp-20h] related to the address of cTestDerived?

This would be a good time to reiterate that the watch window is your friend. We can use the watch window to Sherlock Holmes our way to an answer.

If you look in the watch window below the disassembly view (shown again below by itself for those of you who are vertical resolution challenged) you can see that I have used watch window expression evaluation to find out some information about these values:

This shows us that:

the address of cTestDerived is 0x0048fa84…
… and the address of cTestDerived cast to a pointer to CTestBaseOne has the same address, …
…but when the address of cTestDerived is cast to CTestBaseTwo we get 0x0048fa8c…
…which is the same value as [ebp-20h]…
…or an 8 byte offset from the address of cTestDerived…
…which is the offset of CTestBaseTwo within CTestDerived

Should this be surprising?

Here’s the memory layout of CTestDerived again:

1>  class CTestDerived	size(24):
1>  	+---
1>  	| +--- (base class CTestBaseOne)
1>   0	| | _iA
1>   4	| | _iB
1>  	| +---
1>  	| +--- (base class CTestBaseTwo)
1>   8	| | _iC
1>  12	| | _iD
1>  	| +---
1>  16	| _iE
1>  20	| _iF
1>  	+---

Since we know that:

(within non-static member functions) member variables are accessed via constant offsets from their this pointer

the memory for CTestBaseTwo starts at an offset of 8 bytes from the start of the memory layout of an instance of CTestDerived

it follows that CTestBaseTwo::SumBaseTwo() wouldn’t work if the compiler passed the address of an instance of CTestDerived because the constant offsets used to access the members of CTestBaseTwo would be off by 8 bytes.

Consequently, any time a CTestBaseTwo member function is called on an instance of CTestDerived the compiler must ensure that a compatible this pointer is generated to pass to the function - i.e. pointing at the start address of CTestBaseTwo within the instance of CTestDerived.

Frighteningly obvious once you know isn’t it?

I honestly don’t think it should be surprising though – given the way that we know data within user defined types is accessed at the assembly level (see part 10), it pretty much had to work like this.

…one more little thing

In the example above, cTestDerived is a Stack variable – so the compiler knows exactly where it is located in the current Stack Frame.

This means that the compiler can calculate the address of the instance of CTestBaseTwo within cTestDerived at compile time, and can therefore access it at no extra cost compared to any other Stack variable.

We should probably check whether this is this any different when we’re dealing with a pointer to a CTestDerived at an arbitrary point in memory, just to be thorough.

Luckily I have already thought of this :)

If you place a breakpoint on the return statement of CTestDerived::SumDerived you can check the disassembly yourself, but here are the relevant lines from my disassembly window:

   52:     int SumDerived( void )
    53:     {
001010A0  push        esi  
001010A1  mov         esi,ecx  
001010A3  push        edi  
    54:         return SumBase() + SumBaseTwo() +_iE + _iF;
001010A4  lea         ecx,[esi+8]  
001010A7  call        CTestBaseTwo::SumBaseTwo (101050h)

As you should be able to see by now, the code in this function is adding a constant offset of 8 bytes onto the this pointer it is passed to generate the this pointer it is passing to CTestBaseTwo::SumBaseTwo

If you’re having trouble seeing it, remember that the ‘thiscall‘ win32 member function calling convention uses ecx to pass the this pointer.

Most significantly, looking back to the last post, we can see that this is essentially the same way that member variables of user defined types are accessed when we had a pointer to an instance of a user defined type – in fact, at the level of the assembly code, there is really no difference between a member variable and a base class; this distinction is really only meaningful at the level of the C++ code.

We now also know that multiple inheritance can cause your code a small additional cost in pointer arithmetic when calling member functions of any of its base types that has a non-zero offset within its memory layout.

What was that earlier? about declaration order?

If you’re paying attention, you should have noticed that when we looked at the memory layout of CTestDerived I mentioned in passing that the ordering of CTestBaseOne and CTestBaseTwo within it matches the textual order they were listed in its base-specifier-list.

This is obviously significant, since it implies that if the textual order in which CTestBaseOne and CTestBaseTwo are listed changes, then the memory layout of CTestDerived will change to reflect this.

If you swap the order of CTestBaseOne and CTestBaseTwo around here’s the memory layout printed during the build process:

1>  class CTestDerived	size(24):
1>  	+---
1>  	| +--- (base class CTestBaseTwo)
1>   0	| | _iC
1>   4	| | _iD
1>  	| +---
1>  	| +--- (base class CTestBaseOne)
1>   8	| | _iA
1>  12	| | _iB
1>  	| +---
1>  16	| _iE
1>  20	| _iF
1>  	+---
1>

Given what we have discovered so far, we can see that this new memory layout means that CTestDerived can now be treated as an instance of CTestBaseTwo.

We can also see that with this new layout, the compiler would need to adjust CTestDerived pointers in order to call CTestOne functions.

I leave it as an exercise for you, o budding expert reader of x86 disassembly, to check this for yourself :)

Aside: construction and destruction with single inheritance

Something we entirely skipped past in last post was construction and destruction of inherited types.

This was intentional – construction and destruction behaviour is straightforward with single inheritance.

We all should know the expected high level behaviour for single inheritance (of arbitrary depth) - in summary:

each constructor calls the constructor of its base class before it does the work of its own function definition – i.e. classes are constructed in order ”from inside to out” or “least to most derived“.
destructors do the opposite, each destructor does its own work before calling the destructor of its base class – i.e. classes are destructed in order “from outside to in” or “most to least derived“.

The disassembly matches the high level behaviour in a very straightforward way and I leave it as an exercise for the reader to step through the disassembly of construction & destruction in some test code to see this in action.

Like the rest of the behaviour we’ve discovered so far, when you think about it, it’s actually pretty obvious that this sort of ‘stack-like’ construction / destruction behaviour is required in order to make inheritance work correctly.

Construction and destruction with multiple inheritance

It was pretty obvious that we were coming to this, right?

What happens with construction and destruction when multiple inheritance is involved is less simple.

For example, what order do the constructors of multiple base classes get called in? … and what order do their destructors get called in?

We also assume that – since the constructor and destructor are member functions – there must be some fiddling with this pointers during this process too.

Luckily, this is very easy to empirically determine: we can just add some text output into the constructors and destructors of the sample classes to print the name of the function and the value of their this pointer.

Here’s a link to a VS2010 project I prepared earlier to do just that, I’ve just added a little extra code to the original example code.

Below is the command line output produced when it is run:

You can see that:

constructors are called in the textual order they appear in the class declaration for CTestDerived - from least derived (i.e. CTestBaseOne) to most (CTestDerived).

destructors are called in the opposite order – this is to ensure that work done in the constructors is un-done in the opposite order.

this also shows that the this pointers are changed for the constructor and destructor of CTestBaseTwo just as they did when we were calling regular member functions

At this point you should feel free to swap around the order of CTestBaseOne and CTestBaseTwo in CTestDerived‘s base-specifier-list to check that construction and destruction follow the same rules as the ordering of base types in derived type’s memory layout (they do, I promise).

Summary

That’s it for this time and it was massive! I bet you’re glad I split this off from post 11 now :)

The astute amongst you will have noticed that we have not looked at any code using the keyword virtual. This is entirely deliberate, and that’s for next time.

So, let’s recap what we’ve discovered so far about inheritance…

First, what we learned about single inheritance in part 11:

1) We know that the memory layout of user defined types is fixed at compile time…

2) …and so code accessing a data member of a user defined type can use a constant offset relative to the start address of an instance of the type (see part 10).

3) In single inheritance, the memory layout of a derived type D literally extends that of its base type B.

4) This ensures that the inherited members of B are at the same constant offsets relative to the start address of an instance of D as they would be relative to the start address of an instance of B…

5) …which means that a pointer to an instance of type D can safely be treated as a pointer to an instance of type B…

6) …which in turn guarantees that member functions of type B can safely be called on instances of type D.

We’ve also discovered that if a derived class D class inherits from multiple base types A and B, then this multiple inheritance breaks the convenience of the single inheritance approach somewhat:

7) As with single inheritance, the memory layout of an instance of D contains the member data of both A and B, laid out exactly as it was in each base class.

8) Member functions of both type A and type B will use constant offsets relative to the their this pointers to access their data members.

9) Logically; only either A or B may have an offset of 0 bytes within the memory layout of an instance of D…

10) … consequently a pointer to an instance of type D can only be safely treated as a pointer to whichever of A or B has a 0 byte offset within its memory layout

11) Which base type has a 0-byte offset is determined by the textual ordering of the A and B types within the base-specifier-list of D‘s class declaration

12) …if A were at the 0 byte offset within D, the compiler would need to calculate a compatible ‘this’ pointer whenever a member function of B called on an instance of D (and vice versa)

13) …when an instance of D is created, the instances of A and B contained within its memory layout will be constructed by their own constructors before the constructor for D is called, and…

14) …the order in which A and B are constructed depends on their textual ordering within the base-specifier-list in D‘s class declaration (i.e. they will be constructed in memory offset order).

Disclaimer

The above numbered bullet points are facts we have discovered empirically by examining the behaviour of win32 x86 code created by the Visual Studio 2010 compiler.

Do not assume that code generated by other platforms / compilers will behave identically. It should behave very similarly, but you should check.

In general, for any POD type you should be able to save out its memory to file as binary and load it back into the memory of a different instance of the same type.

Obviously, this will hold true iff you don’t change target platform, compiler, compiler options, alignment specifications, or the declaration of the type.

Thanks

Thanks for peer review go out to Bruce Dawson and Amir Embrahimi; and for general #altdevblogaday admin assistance to Luke Dicken.

Appendix: What does the C++ standard have to say about all this?

I spent some time reading the C++11 ISO standard (or a near final revision of it at least), but even after consulting the source it is not 100% clear to me exactly what is and what isn’t guaranteed by the standard – see the below for more information.

Below is a collection of snippets of information I found in this near-final draft of the ISO C++ 11 standard document when I was looking up various bits for this post (you have to pay ANSI for the actual one!).

If you want more information on any of the points below, click the link above to download the .pdf and search for the indented text – that will get you to the page it was on. This document does not make for light reading!

1. Ordering of base classes in memory within a multiply inherited class.

As far as I can tell, this is not guaranteed by the standard – in fact the draft standard says this:

10.1 Multiple base classes [class.mi]
1 A class can be derived from any number of base classes. [Note: The use of more than one direct base class
is often called multiple inheritance. — end note ] [Example:
class A { /∗ ... ∗/ };
class B { /∗ ... ∗/ };
class C { /∗ ... ∗/ };
class D : public A, public B, public C { /∗ ... ∗/ };
— end example ]

2 [Note: The order of derivation is not signiﬁcant except as speciﬁed by the semantics of initialization by
constructor (12.6.2), cleanup (12.4), and storage layout (9.2, 11.1). — end note ]

which more or less says that it’s not guaranteed.

2. Ordering of data members within a class.

So, it appears that a C++ compiler is allowed to reorder data members of a class in memory vs. their textual declaration order if (and only if) their access control (i.e. public, private, protected) is different:

15 Nonstatic data members of a (non-union) class with the same access control (Clause 11) are allocated so that later members have higher addresses within a class object. The order of allocation of non-static data members with diﬀerent access control is unspeciﬁed (11). Implementation alignment requirements might cause two adjacent members not to be allocated immediately after each other;

I can’t imagine this would ever be a problem for you unless you’re writing a reflection library or similar.

3. Ordering of constructor calls when constructing types with base types

Thankfully, there does appear to be some sanity remaining in the universe; as I managed to find the part of the standard that specifies the order in which constructors are called for types that use inheritance:

In a non-delegating constructor, initialization proceeds in the following order:
— First, and only for the constructor of the most derived class (1.8), virtual base classes are initialized in the order they appear on a depth-ﬁrst left-to-right traversal of the directed acyclic graph of base classes, where “left-to-right” is the order of appearance of the base classes in the derived class base-speciﬁer-list.
— Then, direct base classes are initialized in declaration order as they appear in the base-speciﬁer-list (regardless of the order of the mem-initializers).
— Then, non-static data members are initialized in the order they were declared in the class deﬁnition (again regardless of the order of the mem-initializers).
— Finally, the compound-statement of the constructor body is executed.
[Note: The declaration order is mandated to ensure that base and member subobjects are destroyed in the
reverse order of initialization. — end note ]

TL;DR – (if you are not using virtual base classes) each constructor initialises its base classes in declaration order, then the class members in declaration order, then the constructor’s body is executed called.

C/C++ Low Level Curriculum Part 11: Inheritance

Alex Darby — Fri, 03 May 2013 21:06:20 +0000

Hello, and welcome to the 11th part of the C / C++ low level curriculum. About time? Definitely!

Last time we looked at the basics of User Defined Types: how structs, classes, and unions are laid out in memory; and (some of) the implications of memory alignment on this picture.

In part 11 we’re going to look at how inheritance affects this picture, in particular the implications for memory layout of derived types and also for their behaviour during construction and destruction (note: we’re leaving multiple inheritance and the keyword virtual out of this picture to start with).

Before We Begin

Another big assumption I’m going to make is that you’re already very familiar with the C++ language and comfortable using the language features we’re discussing, as well as the accepted usage limitations of those features etc. If I need to demonstrate anything out of the ordinary I’ll explain it – or at least link to an explanation.

With this in mind, in case you missed them, here are the backlinks to the previous posts in the series:

I won’t lie – it’s not light reading :)

Class vs. Struct: a Gentle Reminder

The C++ keywords struct and class define types that are identical in implementational detail and what you can do with them (the only difference being at the language level: the default access specifier if none is specified is private for class, and public for struct).

So, whilst I will be using the keyword class throughout this article please take it as read that anything we talk about here applies equally to types defined using the keyword struct.

What happens when we derive from another type?

So, what does happen when you derive a user defined type from another non built-in type?

Clearly the data members you specify in the declarations have to go somewhere, and so do all those specified in the type(s) you are deriving from.

At the level of C++ there is nothing other than the standard to tell you how this works – and nothing other than looking at what happens with the code generated by the compiler you are using will tell you for definite.

As in the last post, we will be relying heavily on the frankly awesome secret 007 compiler flag /d1reportSingleClassLayout in order to tell us exactly how the (Visual Studio 2010 win32 x86) compiler has decided to lay our example structures out in memory.

It’s about time to look at some example code, so, rather than have you go through the usual rigmarole of setting up your project I have kindly set one up for you.

The zip file in this link contains a VS2010 solution with a single project and .cpp file lovingly set up to run the code shown below, which is in 00_Inheritance.cpp

class CTestBase
{
public:
    int _iA;
    int _iB;
};
 
class CTestDerived
: public CTestBase
{
public:
    int _iC;
    int _iD;
};
 
int main(int argc, char* argv[])
{
    return 0;
}

When you compile this project you should get the following in your “Build” output window (the magic of /d1reportSingleClassLayout!) :

1> class CTestBase size(8):
1>   +---
1> 0 | _iA
1> 4 | _iB
1>   +---
1> 
1> class CTestDerived size(16):
1>    +---
1>    | +--- (base class CTestBase)
1>  0 | | _iA
1>  4 | | _iB
1>    | +---
1>  8 | _iC
1> 12 | _iD
1>    +---

Looking at this, it should be fairly obvious that the data members of CTestDerived have just been concatenated onto the end of the memory layout of CTestBase - and, more importantly, that the memory layout of CTestBase within CTestDerived is identical to that when it’s not a base class.

It’s that simple! (for certain definitions of ‘it’ and ‘simple’…)

Armed with this information from last post:

“A guarantee is given in both the C and C++ language specifications that memory address of each member will be higher than that of the one declared before it (see this post on Stack Overflow for more detail of the wording).”

it is obvious that – since CTestDerived inherits all of the members of CTestBase - its members must appear after those of CTestBase in memory.

I remember when I had this explained this to me - not long after having started my first job in the industry as a fresh faced graduate – I did the internal equivalent of a double-take, because the information I had just received was so bleedingly obvious that I couldn’t believe I’d ever not known it.

If it’s that easy, why post about it?

Good question!

The fact that the memory layout of a type is identical in all situations is required by the standard – and also by logic – let’s see why…

First, download and open the second zipped VS2010 project file - this contains the code below in 01_InheritanceWithFunctions.cpp:

class CTestBase
{
public:
    int _iA;
    int _iB;
 
    CTestBase( int iA, int iB )
    : _iA( iA )
    , _iB( iB )
    {}
 
    int SumBase( void )
    {
        return _iA + _iB;
    }
};
 
class CTestDerived
: public CTestBase
{
public:
    int _iC;
    int _iD;
 
    CTestDerived( int iA, int iB, int iC, int iD )
    : CTestBase ( iA, iB )
    , _iC ( iC )
    , _iD ( iD )
    {}
 
    int SumDerived( void )
    {
        return _iA + _iB + _iC + _iD;
    }
};
 
int main(int argc, char* argv[])
{
    CTestBase       cTestBase   ( argc, argc + 1 );
    CTestDerived    cTestDerived( argc, argc + 1, argc + 2, argc + 3 );
 
    return cTestBase.SumBase() + cTestDerived.SumBase() + cTestDerived.SumDerived();
}

Put a breakpoint on the return statement from main, and then compile and run the release build configuration.

The first thing to note is that the memory layouts printed to the output window during the build are unaffected by the addition of these functions.

This is what you would expect, as we know that non-virtual member function calls are resolved at compile time just like regular non-member and static member functions.

Since CTestDerived is derived from CTestBase, we know from our high level knowledge about C++ that we can call both of these functions on an instance of CTestDerived – what we’re looking at right now is how this is implemented.

When the breakpoint is hit, right click and choose “Go To Disassembly”.

I’ve pasted the part I’d like to discuss below…

(N.B. to get the same disassembly as this you should have the following Viewing Options checked in the disassembly window: ‘Show source code’, ‘Show line numbers’, ‘Show address’, and ‘Show symbol names’)

    44:     return cTestBase.SumBase() + cTestDerived.SumBase() + cTestDerived.SumDerived();
0129109A  lea         ecx,[cTestDerived]  
0129109D  call        CTestDerived::SumDerived (1291060h)  
012910A2  lea         ecx,[cTestDerived]  
012910A5  mov         esi,eax  
012910A7  call        CTestBase::SumBase (1291020h)  
012910AC  lea         ecx,[cTestBase]  
012910AF  add         esi,eax  
012910B1  call        CTestBase::SumBase (1291020h)  
012910B6  pop         edi  
012910B7  add         eax,esi

We’ve previously covered that the win32 calling convention for member functions (‘thiscall’) passes this to member functions in the ecx register.

Correspondingly, you’ll notice that the address of cTestBase and cTestDerived are being stored in ecx using lea (‘load effective address’) immediately before calling their member functions.

Specifically, note that the address of cTestDerived is passed un-tampered with in ecx when calling the base class function CTestBase::SumBase. Remember this for later (and for the next post!).

So, let’s look at the disassembly for CTestBase::SumBase and CTestDerived::SumDerived - I tend to single step the disassembly and step into them, but putting breakpoints in them is more reliable :)

CTestBase::SumBase

    14:     int SumBase( void )
    15:     {
    16:         return _iA + _iB;
01291020  mov         eax,dword ptr [ecx+4]  
01291023  add         eax,dword ptr [ecx]  
    17:     }
01291025  ret

CTestDerived::SumDerived

    33:     int SumDerived( void )
    34:     {
    35:         return _iA + _iB + _iC + _iD;
01291060  mov         eax,dword ptr [ecx+0Ch]  
01291063  add         eax,dword ptr [ecx+8]  
01291066  add         eax,dword ptr [ecx+4]  
01291069  add         eax,dword ptr [ecx]  
    36:     }
0129106B  ret

We can see that all offsets from ecx used in both functions correspond to the memory layouts we have in the build output for the type that the function belongs to.

Since _iA and _iB are at the same offset within both CTestBase and CTestDerived (i.e. 0 and 4 bytes respectively), CTestBase::SumBase can safely be called on instances of CTestDerived.

We already know that this is possible from our high level understanding of C++, but now we know the implementational detail that makes it possible.

Whilst the specifics of the disassembly will probably differ from platform to platform, the principles underlying its operation should not.

Summary

To summarise what we’ve established so far :

1) in member functions, member data of a class is accessed via specific offsets from the this pointer

2) these offsets are constants at compile time and are baked into the assembly code for the member functions

3) this means that the memory layout of the members of a given class must always be identical or the member functions won’t work

If we follow this logic through, we can see that:

4) the memory layout of a class B that inherits from another class A must contain class A‘s members in the same memory layout as class A

5) the memory layout of any given class A is identical regardless of whether it is an instance of A, or it is included in the memory of some type derived from A.

6) note: this behaviour is required by the standard, and (more significantly) by logic.

Finally, it follows that (because each member of a struct must have a higher address than those declared before it):

7) the extra memory required by derived class B will be concatenated onto the end of the memory layout of its base class A

That’s all for now – next time we’ll look at how multiple inheritance affects this picture.

I know it’s pretty short, but this just means the next one will get here more quickly :)

Epilogue – for those who wondered what I changed in the project settings

There’s quite few changes to the default VS2010 win32 console app project properties in the projects I’ve zipped up for this post.

The changes have to do with making the optimised release build configuration leave the code structure alone (i.e. not strip out or ‘fold’ functions to save exe size, prevent functions being inlined), and prevent extraneous ‘debug checking’ code being inserted (makes function calls slower, and code less easy to follow in disassembly)

turning off ‘Whole Program Optimisation’ (Configuration Properties->General)
turning off ‘Inline Function Expansion’ (Configuration Properties->C/C++ ->Optimisation)
turning off ‘Basic Runtime Checks’ (Configuration Properties->C/C++ ->Code Generation)
getting rid of pre-compiled headers to streamline the number of files (Configuration Properties->C/C++ ->Precompiled Headers)
turning off ‘Enable COMDAT folding’ (Configuration Properties->Linker-> Optimization)

Essentially, this makes the Release configuration assembly have the same structure as the Debug one WRT function calls.

Also, I use the argc parameter to main as input to the code, and return value computed from that so that the optimiser can’t assume constant input or output values.

If you use constant inputs, or don’t output a value computed from the inputs then it’s pretty hard to convince the optimiser not to optimse the entire .exe to ‘return 0;’… ;)

Shout out

Thanks (again) to Bruce – king (or at the very least duke) of advice and peer review.

C/C++ Low Level Curriculum Part 10: User Defined Types

Alex Darby — Sat, 05 Jan 2013 15:25:05 +0000

Hello again peoples of the interweb. It has been quite a while since the last one (probably even longer than the gap between part 8 and part 9) so I thought I ought to pull my finger out and get the next post in the C/C++ Low Level Curriculum done.

In the previous posts we’ve covered the structural aspects of the language: flow control, functions, and so forth; and so now we move on to looking in detail at user defined types in C/C++ (i.e. struct, class, and associated keywords) which I naively expected to comprise the bulk of this potentially never ending series when I started it. D’oh!

Before we start, dear reader, I’m going to assume that you’re the kind of person / recently self aware google web trawling AI entity who likes to understand your jargon terms and so I will be including appropriate links (probably mostly wikipedia or other ADBAD articles) where appropriate.

You may also want to read the previous posts in this series (though I don’t think this one will particularly rely on older posts) so, in case you missed them, here are the back-links for preceding articles in the series (warning: reading these might take a while…) :

Data Types and Enums

We covered fundamental and intrinsic types in the second post in the series, which also touched on the enum keyword. I deliberately didn’t cover the use of the keywords struct or class in this post, but we did cover some facts about the behaviour of values defined using the enum keyword (i.e. that it was up to the compiler to decide what intrinsic type to use to represent each enumerated type you declare, based on the range required by its values).

Helpfully, the C++11 standard made some sweeping changes to the behaviour of enums; amongst which was the ability to specify the the fundamental type used to represent the values of each enum. Tasty.

Mentioning this welcome change is the extent of our discussion of enum, so let’s get on with starting to look at struct, class, andunion.

Thankyou Visual Studio Devteam

If you have been really paying attention to the older posts, you might remember that I mentioned some undocumented (and unsupported!) command line options for Microsoft’s Visual Studio C++ compiler which can be used to print out the memory layout of data types defined using the struct, class, orunion keywords.

These secret compiler options are /d1reportAllClassLayout which reports the layout of all classes in the current project, and its more user friendly sibling /d1reportSingleClassLayoutxxx (where xxx is a string used to do a substring match against classes that you wish to have reported).

I will be leaning pretty heavily on this compiler for the next few posts, so we may as well cover how to use it. It definitely works in VS2010 and VS2012; it even works with the Express versions. Woo!

Here’s where you type in the command line option in the property pages (n.b. this is the ‘single’ version and matches any class or struct with the string ‘Test’ in its name):

Output from /d1reportSingleClassLayout

So far so froody.

Now, it’s about time we looked at a code snippet defining a simple POD struct (POD types being the simplest cases of aggregate data types) and the output produced by /d1reportSingleClassLayout when we build it…

#include "stdafx.h"
 
struct STest
{
    int iA;
    int iB;
};
 
int main(int argc, char* argv[])
{
    return 0;
}

When we compile this with the fancy secret compiler switch, as expected we find an extra bit of information in amongst the usual Visual Studio compiler’s output:

1> class STest size(8):
1>   +---
1> 0 | iA
1> 4 | iB
1>   +---

Hopefully this should appear pretty much self explanatory to you, but in case it doesn’t – rest assured we’re about to look at it in a little more detail.

The first line contains the name of the class and its size in bytes – STest is a struct, but it is reported as a class – don’t worry about this for now.

The struct‘s name contains the string ‘Test’ which is the substring we specified to match against in the compiler option in order to get class layout information.

The rest of the information details the member-by-member memory layout of the struct organised by the name of the data members – the number at the start of the line is the memory offset in bytes of that member relative to the start of the struct.

The first thing to note is that the member variables are laid out in memory in the order specified in the class declaration.

A guarantee is given in both the C and C++ language specifications that memory address of each member will be higher than that of the one declared before it (see this post on Stack Overflow for more detail of the wording).

In the case of STest the first member iA is at an offset of 0 bytes from the start of the struct; and the second member iB is at an offset of 4 bytes from the start of the struct.

Importantly (by doing a little maths with the offsets and the size of the struct) this also tells us that the size taken up by iA is 4 bytes, and the size taken up by iB is 4 bytes – since sizeof(int) == 4 this matches up with what we would expect.

Accessing the members of a struct in assembly

We all knew this was coming, right?

Woo! I know you all live for hexadecimal numbers and assembler mnemonics.

As always, the main thing I want you to take away from this is not so much the understanding of the specific assembly code itself (though clearly it has its benefits…), but more of a generalised appreciation for the combinations of assembly instructions that ‘smell like’ the compiler accessing the members of a struct or class.

Getting used to the assembly level ‘smells’ of the various high level constructs in compiler generated assembly code will enable you to find your bearings much more quickly in code you see in the disassembly window, and – most importantly (assuming that you are lucky enough to have a valid callstack – and, like a sensible person, you have symbols for your release build) – you should quickly develop the ability to work out which bit of the high level code corresponds to the assembly you’re currently looking at. Win.

Here’s a code snippet that accesses the data members of the struct we just defined:

#include "stdafx.h"
 
struct STest
{
    int iA;
    int iB;
};
 
int main(int argc, char* argv[])
{
    STest sOnStack;
    sOnStack.iA = 1;
    sOnStack.iB = 2;
 
    STest* psOnHeap = new STest;
    psOnHeap->iA = 3;
    psOnHeap->iB = 4;
    delete psOnHeap;
 
    return 0;
}

Before we look at the disassembly we should explain a little about the snippet.

Two instances of STest are created:

sOnStack on the Stack – i.e. automatically allocated by the compiler as a local variable
psOnHeap on the Heap – i.e. dynamically allocated.

The reasons for doing this will become clear once we’ve inspected the assembly.

Aside: technically the area of dynamic memory managed by new and delete in C++ is called the Free Store, but almost everyone calls it the Heap. I’m pretty sure this is because the dynamic memory in C managed by malloc and free has colloquially and historically been known as “the Heap”, and a lot of C++ implementations define new and delete using malloc and free (and most if not all used to).

So here’s the disassembly generated by the VS2010 debug compiler:

    14: STest sOnStack;
    15: sOnStack.iA = 1;
00A01269 mov dword ptr [ebp-8],1 
    16: sOnStack.iB = 2;
00A01270 mov dword ptr [ebp-4],2 
    17: 
    18: STest* psOnHeap = new STest;
00A01277 push 8 
00A01279 call 00A010F5 
00A0127E add esp,4 
00A01281 mov dword ptr [ebp-54h],eax 
00A01284 mov eax,dword ptr [ebp-54h] 
00A01287 mov dword ptr [ebp-0Ch],eax 
    19: psOnHeap->iA = 3;
00A0128A mov eax,dword ptr [ebp-0Ch] 
00A0128D mov dword ptr [eax],3 
    20: psOnHeap->iB = 4; 
00A01293 mov eax,dword ptr [ebp-0Ch] 
00A01296 mov dword ptr [eax+4],4

Looking at lines 3 and 6 (and remembering what we learned in post 2 about how variables in memory are accessed in assembly); we can see that both sOnStack.iA and sOnStack.iB are being directly accessed by their memory addresses as offsets from ebp ([ebp-8] and [ebp-4] respectively).

Looking at lines 15-16 and lines 18-19, we can see that psOnHeap.iA and psOnHeap.iB are being accessed differently.

Since this is different to what we have seen before, let’s break it down a little:

For each of these assignments, first the pointer psOnHeap (i.e. memory address of the instance of STest created at line 7) is loaded into eax (line 15 and line 18), and…
… then the member is accessed via the memory address stored in eax (line 16 and line 19 – via [eax] and [eax+4] respectively).

In particular, note that when STest::iB is accessed (at address [eax+4] - line 19) an 4 byte offset is added, which is exactly the offset that the output from /d1reportSingleClassLayout gave us.

Hopefully it should now be pretty obvious why the instances of STest are accessed differently like this – and by extension why I showed code accessing an instance on the Stack and on the Heap (via a pointer):

When an instance of a user defined type is on the Stack, the compiler is in charge of where the instance is stored (relative to the stack frame); and so it can access its members by their direct offsets within the stack frame.
When an instance is stored in a memory location that is not known at compile time (e.g. accessed via a pointer) the compiler can’t do this and has to access it via offsets from the instance’s base address (i.e. the memory address the instance starts at).

NOTE: this is debug disassembly code, please do not attempt to infer anything about the relative efficiency of Stack vs. Heap memory from this! As far as I am aware, on every machine I’ve ever used Stack and Heap are both stored in the same memory and accessed via the same physical systems so in terms of theoretical minimum access speeds Stack == Heap.

What about class?

The short answer to this question is that there is no difference whatsoever between classes and structs at the implementational level of C++.

The long answer is that, in the C++ language, struct is actually a special case of class with one specific difference – for classes any unsupplied access specifier (i.e. public, protected, or private anywhere in the type declaration) will default to private, but for structs it will default to public.

That’s it. The only difference. Honest.

Access specifiers are ultimately just language level syntactic sugar to allow us to control the way our classes are used; under the hood struct and class are implemented the same way – even with regards to stuff like inheritance and virtual functions.

If you do a search and replace of struct for class in the snippet and add a public: to the top of each class declaration (so it compiles) you will get the exact same output from the class layout information and the same disassembly.

Union

As well as class and struct, there is another keyword that can define a type – the keyword union.

It’s not a frequently seen or used language feature, and so it’s all the more worthwhile discussing here because it can be very useful and its low frequency of use means that a lot of people don’t really know what it’s for, let alone how it works.

Let’s look at this with another example code snippet. This has had two new types added to it:

#include "stdafx.h"
 
struct STest
{
    int iA;
    int iB;
};
 
struct STestTwo
{
    int iC;
    int iD;
    int iE;
};
 
union UTestUnion
{
    STest sTest;
    STestTwo sTestTwo;
};
 
int main(int argc, char* argv[])
{
    UTestUnion* psOnHeap = new UTestUnion;
 
    psOnHeap->sTest.iA    = 1;
    psOnHeap->sTestTwo.iC = 2;
 
    psOnHeap->sTest.iB    = 3; 
    psOnHeap->sTestTwo.iD = 4;
 
    psOnHeap->sTestTwo.iE = 5;
 
    delete psOnHeap;
 
    return 0;
}

Compiling this with /d1reportSingleClassLayout we get the following output for the layouts:

1> class STest	size(8):
1>  	+---
1>   0	| iA
1>   4	| iB
1>  	+---
1>  
1> class STestTwo	size(12):
1>  	+---
1>   0	| iC
1>   4	| iD
1>   8	| iE
1>  	+---
1>
1> class UTestUnion	size(12):
1>     +---
1>   0 | STest sTest
1>   0 | STestTwo sTestTwo
1>     +---

The first thing to note is that UTestUnion is the same size as STestTwo. This is exactly as one would expect.

The second thing to note is that both UTestUnion::sTest and UTestUnion::sTestTwo have an offset of 0 bytes within UTestUnion. Again, exactly as one would expect.

So, why is this the case?

The keyword union allows you specify multiple layouts for a chunk of memory. When we declare the union of STest and STestTwo within UTestUnion, we declare our intent to be able to treat the memory of type UTestUnion as either an instance of STest or an instance of STestTwo at our discretion.

This means that, within the type UTestUnion, an instance of STest and an instance of STestTwo exist overlaid on each other. Since the union can be treated as either type, this means that it must necessarily have the same size as the larger of the two types.

Let’s back this up by looking at the disassembly:

    29: psOnHeap->sTest.iA = 1;
0122127C mov eax,dword ptr [ebp-4] 
0122127F mov dword ptr [eax],1 
    30: psOnHeap->sTestTwo.iC = 2;
01221285 mov eax,dword ptr [ebp-4] 
01221288 mov dword ptr [eax],2 
    31: 
    32: psOnHeap->sTest.iB = 3; 
0122128E mov eax,dword ptr [ebp-4] 
01221291 mov dword ptr [eax+4],3 
    33: psOnHeap->sTestTwo.iD = 4;
01221298 mov eax,dword ptr [ebp-4] 
0122129B mov dword ptr [eax+4],4 
    34: 
    35: psOnHeap->sTestTwo.iE = 5;
012212A2 mov eax,dword ptr [ebp-4] 
012212A5 mov dword ptr [eax+8],5

There it is, clear as day :)

In case you’re not seeing it, here’s a quick breakdown:

we can see that psOnHeap is stored at [ebp-4].
(line 2) UTestUnion::sTest::iA and (line 5) UTestUnion::sTestTwo::iC are both being accessed directly via the value loaded into eax from [ebp-4] - i.e. at an offset of 0 bytes; the same as their offset within their respective types as shown in the class layout information.
(line 9) UTestUnion::sTest::iB and (line 12) UTestUnion::sTestTwo::iD are both being accessed via [eax+4] at an offset of 4 bytes from the value loaded into eax from [ebp-4]. Again, the same as their offsets within their respective types as shown in the class layout information.
(line 16) UTestUnion::sTestTwo::iE is accessed via [eax+8] – an offset of 8 bytes as specified in the class layout information.

A more ‘real world’ example of the use of union might be a data structure used in a vector maths library similar to the one below:

class CTestVec4
{
    union 
    {
        struct 
        {
            float x;
            float y;
            float z;
            float w;
        };
        struct  
        {
            float vec[ 4 ];
        };
    };
};

The above code declares a vector structure whose data can be accessed either via its components or like an array – e.g. CTestVec4::z occupies the same memory as CTestVec4::vec[ 2 ].

The code looks like it should be illegal but it isn’t – leaving all the names out is entirely deliberate, this defines an “anonymous union” which makes the syntax for accessing the union ‘less cumbersome’ (i.e. basically just less typing).

If you weren’t sure how union worked, or indeed what it was for, now you know :)

Surely we’re due a spanner in the works about now?

We most certainly are! Well spotted.

There is an incredibly important low level aspect of the way memory is laid out within classes and structs that I have deliberately skimmed over until now.

Consider the following snippet containing an innocent looking struct declaration:

#include "stdafx.h"
 
struct STestSpanner
{
    int     iOne;
    double  fdTwo;
    char    chThree;
    int     iFour;
};
 
int main(int argc, char* argv[])
{
    return 0;
}

When we compile this we get the following output from the class layout information:

1>  class STestSpanner    size(24):
1>  	+---
1>   0	| iOne
1>    	|  (size=4)
1>   8	| fdTwo
1>  16	| chThree
1>    	|  (size=3)
1>  20	| iFour
1>  	+---

What witchcraft is this!?!

We’ve added a char and a double to our struct - requiring a total of an extra 9 bytes (on win32 sizeof(char) == 1 and sizeof(double) == 8).

However, the total size of the struct has increased by 16 bytes – in addition to the 9 bytes we know we asked for, we have also added an additional 7 bytes of invisible ‘alignment member‘ fields.

What is going on? Padding – that’s what.

Padding!?!

As long as the layout of the data members of a type meet the ordering requirement of the language standard (as covered earlier) they do not have to be immediately adjacent in memory.

The compiler is free, encouraged even, to insert additional padding into your structs / classes at its discretion.

Why might the compiler wish to adjust the layout like this?

The short answer is: to optimise for speed of memory access for the intrinsic types stored in that structure.

The longer answer goes something like this…

On each platform, the various intrinsic types have different sizes and typically also different memory alignment requirements.

In the best case, accessing an intrinsic type with an alignment requirement from an incorrectly aligned memory address will cause the memory access time to be slower than usual (on x86 the cost is typically relatively small, but can be an order of magnitude slower on other platforms); and in the worst case can actually cause the CPU to crash (yes, really – on some platforms unaligned access makes the CPU freak out).

There are three separate factors at play in determining the size of STestSpanner:

The logical number of bytes required by its constituent types – this is the minimum possible size of the type.
The ordering of the constituent types within the class declaration.
The individual alignment requirements of those constituent types.

The compiler honours both the ordering of the constituent types and their individual alignment requirements, and this interaction determines the amount of padding bytes that get added.

Since they affect each other and are closely related, the distinction between alignment, packing, and padding often causes confusion:

Alignment is a constraint on the start address of instances of a type in memory
Packing is a constraint on the alignment of adjacent members within the memory of a struct or class
Padding is the bytes added within a class or struct to maintain its packing constraints

This Stack Overflow question has a good a discussion of the implications of unaligned access on x86 for those of you who are interested.

Sorry, why the padding?

As we have covered before, compiler writers are wily.

You must be able to declare an array of any type that you define, and so the memory layout of a struct or class you define must not only maintain the alignment constraints of its constituent intrinsic types within an instance, but also across an array of instances laid out contiguously in memory.

The simplest way to ensure this is to make the internal structure of the type adhere to the largest alignment constraint of its constituent types – and this means that the size and internal packing of any structure you declare will usually end up being determined by the largest alignment requirement of its constituent types.

In the case of our struct this would be double which has a default alignment of 8 bytes (at least under the Visual Studio x86 complier, it varies with other compilers), and consequently so does the structure STest – hence the 7 extra bytes of padding to take the struct from the 17 bytes ( 2 ints (8bytes) + 1 double (8 bytes) + 1 char (1 byte) ) of data we asked it to contain up to 24 bytes – i.e. the next size that maintains the alignment of double.

You should find that, no matter how you shuffle the members of STestSpanner around, you still end up with a 24 byte structure that includes 7 bytes of padding.

On the plus side, if we needed to add 3 extra char and an extra int into STestSpanner we would get that storage space for free as long as we put them in the correct positions in the type declaration :)

But what about all the wasted bytes?

The compiler knows what it is doing, and 99% of the time you should not worry about the wasted space.

Get a cup of tea and a biscuit and make peace with it – it’s not wasted space, it’s space invested in making your memory access more efficient.

However, you should worry about it a little – because it is entirely possible to cause the compiler to introduce padding into a type that is actually a total waste of memory.

Consider this struct:

struct STestSpannerTwo
{
    int     iOne;
    double  fdTwo;
    int     iThree;
};

which produces this class layout:

1>  class STestSpanner	size(24):
1>     +---
1>   0 | iOne
1>     |  (size=4)
1>   8 | fdTwo
1>  16 | iThree
1>     |  (size=4)
1>     +---

A quick look at the class layout above informs us that there is 4 bytes of padding between STestSpannerTwo::iOne and STestSpannerTwo::fdTwo; and another 4 bytes of padding after STestSpannerTwo::iThree.

The x86 intrinsic 64 bit float format used to represent double is 8 bytes long and clearly has default alignment of 8-bytes under Visual Studio’s compiler.

The constraints of our type declaration combined with the 8 byte alignment constraint for double have resulted in:

4 padding bytes after STestSpannerTwo::iOne and before STestSpannerTwo::fdTwo to maintain the alignment within the memory of a single instance of STestSpannerTwo…
…and 4 padding bytes after STestSpannerTwo::iThree to maintain the 8 byte alignment across instances of STestSpannerTwo that are contiguous in memory (i.e. an array of STestSpannerTwo).

However, we can also see that STestSpannerTwo::iThree is a 4 byte int and so it will fit into the first block of padding; eliminating the need for the 8 padding bytes.

Re-ordering the members by hand like this will save 8 bytes off the total size of the struct, and so we can see that – in this case – we can save 33% of the memory used by the struct basically for free – don’t take my word for it, try it!

whilst this isn’t something you should lose sleep over, you should now be able to see the benefit in always taking a second to consider the most appropriate place to insert a new data member into an existing type ;)

…but what if I really need those padding bytes?

Unsurprisingly, this being C/C++, it is entirely possible to ask the compiler to change its default alignment and packing behaviour.

This is usually accomplished by use of command line compiler options and/or compiler specific commands that are inserted inline in your code.

In Visual Studio, for example, there is the /Zp compiler option, and another 2 ways to affect the alignment of data structures and the packing of their members with compiler commands in the code itself __declspec( align( x ) ) and #pragma pack (x)). There may also be others I’ve never seen or used, but a quick search on t’interwebs didn’t find them.

For example, using #pragma pack to tell the compiler to pack STestSpanner to a 1 byte boundary like this:

#pragma pack(1) 
struct STestSpanner
{
    int     iOne;
    double  fdTwo;
    char    chThree;
    int     iFour;
};

Gives this class layout output:

1>  class STestSpanner	size(17):
1>  	+---
1>   0	| iOne
1>   4	| fdTwo
1>  12	| chThree
1>  13	| iFour
1>  	+---

Be warned!

Adjusting the packing of a type can (and probably will) break the alignment constraints of its constituent types – in the example above there are no ‘wasted’ bytes; but STestSpanner no longer honours the alignment requirements of its constituent types and so will presumably take significantly longer to access than it would do had we not fiddled about with it.

This means that when you ask the compiler to change the packing of a type you need to be very careful.

My advice is that – in general – you shouldn’t mess with alignment or padding unless you have a very good reason to; altering padding and alignment can get you into a whole world of pain, especially with bigger projects and when using code libraries – here’s a link to a post on the Visual C++ Team Blog that goes into it in some detail.

The decisions to change alignment or padding will typically come down to essentially platform specific trade offs based on data derived from run time profiling – balancing issues like data sizes vs. memory resource constraints, worst case access times of individual parts of the data, and issues relating to system cache sizes and alignments.

Summary

In summary here are the main points I’d like you to take away from this post:

The undocumented compiler options /d1reportSingleClassLayout and /d1reportAllClassLayout are awesome, and can help you to understand the memory use implications of code you write, as well as being very useful debugging tools
We now know that, when an instance of a structure is accessed via pointer, its members are accessed via an offset from the instance’s base address in the assembly, and …
… that, logically, we can use this in the disassembly view to work out which member is being accessed
The difference between struct and class. i.e. that there is no low level representational difference.
What the keyword union does and how it works
What padding and alignment are and some of their implications

Next time we will look at how (simple) inheritance affects this picture…

Epilogue: Debugger Trick 17a

Here’s an alternative way to find out the offset of a member within a user defined data type, a way that you can happily use in the debugger rather than having to compile the code.

This method works with the vast majority of debuggers I’ve used in the last 5 years or so on both PC and console; and it relies on the fact that the standard C style cast syntax works in watch windows (try it! It’s awesome).

One upshot of this is that you can use casting to calculate the byte offset of any member of any user defined type (this is also valid, and very useful, C/C++ code):

That code looks horrible, not to mention dangerous, but what it’s doing is actually very simple and totally safe.

We have seen that, when using a pointer to an instance of a type, the compiler accesses members of that user defined type by adding an offset to the memory address the instance is stored at (its ‘base address’).

Note that the values we’re seeing in the watch window are identical to those seen in the output from /d1reportSingleClassLayout.

Here’s how this works:

(STest*) 0 - tells the debugger to treat 0 as the value of a pointer to an instance STest. If you’re thinking “but 0 is NULL!” – remember that 0 is only ‘NULL’ by convention (in fact, on some consoles, 0 is a valid memory address and can be accessed…). In any case, this code isn’t accessing the memory – it’s just asking the compiler to treat 0 as the value of a pointer.
&(((STest*)0)->iB) - tells the debugger to calculate the address of STest::iB. Again, since this is just calculating an address and not attempting to access it it is fine.

This is possibly my favourite thing I have ever found out about debuggers, and has come in incredibly useful over the years :)

C/C++ Low Level Curriculum Part 9: Loops

Alex Darby — Tue, 04 Sep 2012 18:00:25 +0000

Welcome to the 9th post in this C/C++ low level curriculum series I’ve been doing. It’s been a long time since post 8 (way longer than I thought it was), a fact I can only apologise for. My 3 year old son stopped having a nap in the afternoon in late April and it’s totally ruined my productivity…

This post covers the 3 built-in looping control structures while, do-while, and for as well as the manual if-goto loop (old school!); as usual, we look in some detail at the assembly generated by the compiler looks like. Did I forget about the new range-based-for loop that was added in the C++11 standard? Nope. If you have access to a C++11 compliant compiler you’re more than welcome to look at that yourself – think of it as homework…

Here are the backlinks for preceding articles in the series (warning: it might take you a while, the first few are quite long):

A brief history of looping

It occurred to me that a sensible order to cover the looping constructs of the C/C++ language might be to address them in the order in which they were introduced into the language.

A couple of years back a friend showed me a brilliant website / article that covered the evolution of the C programming language. It was very interesting, and from what I can remember, contained information on the order in which the various features of the C compiler were added – including which looping construct came first. I tried to find it on t’ internet, but failed. Feel free to link me up in a comment if you happen to know where it is…

Since I couldn’t find the article /website in question I’ve decided to cover them in the order of the amount of work they do automatically for the programmer, which in my opinion is: if-goto, while, do-while, and finally for.

This seems to me to be a sensible order for 2 reasons; firstly because it’s likely to be the order in which they were introduced into programming languages, and secondly because the concepts encapsulated by these constructs sort of build on each other in that order.

if-goto

From our previous excursions into the land of assembly we are already familiar with the concept of jumping the execution address, and with the concept of ‘conditional jumping’ (i.e. conditionally changing the execution address). The most direct way to loop the execution of a piece of code several times (as opposed to the simplest to type) is to use the high level keywords that correspond to these assembly level concepts.

We are already familiar with the keyword if, but we’ve not really covered goto – possibly the most maligned of all the language features of C/C++, and almost certainly the most banned by corporate coding standards.

Personally I don’t think that goto is inherently more dangerous than (for example) operator overloading; but, the purpose of this article is not to discuss goto – if you’re interested here’s the Wikipedia page which contains a fair amount of detail (and links to) on the arguments for and against it.

The purpose of this article is not to discuss the merits of goto or, for that matter, operator overloading so let’s get on with it.

Here’s the first code snippet (see the previous article for how to set up a project that will just accept this code…)

#include "stdafx.h"
 
#define ARRAY_SIZE(array) (sizeof(array)/sizeof(array[0]))
 
int main(int argc, char* argv[])
{
    int k_aiData[] = { 1, 2, 3, 4, 5, 6, 7, 8 };
    int iSum       = 0;
    int iLoop      = 0;
 
LoopStart:
    if( iLoop < ARRAY_SIZE(k_aiData) )
    {
        iSum += k_aiData[ iLoop ];
        ++iLoop;
        goto LoopStart;
    }
 
    return 0;
}

You should be able to see that this code is simply looping over the values in the array k_aiData and summing them, other than the use of if and goto it’s essentially a standard loop to iterate an array.

The pre-processor macro ARRAY_SIZE that I’ve used here is a simple way to make dealing with statically allocated arrays less error prone. Essentially we could initialise the array k_aiData with any number of elements we wanted to and the rest of the code would still just work. There are simple ways to achieve this in a type safe manner using templates too, but I chose to use a macro here because a readable version of the code takes up less vertical space than the template.

If you are wondering why I am not incrementing iLoop inside the square brackets, this is so that the high level code that is doing the work of the loop is identical across all code snippets.

If you are also wondering why I am using the prefix as opposed to postfix version of operator++ then well done to you – award yourself 6.29 paying attention points. In this case it makes no difference to the assembly generated, but in these days of operator overloading it’s generally better to use the prefix version as a point of good practice – unless of course you require postfix behaviour (the first comment on the first answer to this question on Stack Overflow should prove illuminating if you don’t know what implications of the different behaviours are).

Since we’re using two keywords that have a very clear relationship to assembly level concepts, it’s reasonable to assume that the disassembly for this code will be pretty much as we wrote it at the high level. As we all know, we should never assume; so let’s check our assumptions.

Here is the debug x86 disassembly for the looping section:

    11: LoopStart:
    12:     if( iLoop < ARRAY_SIZE(k_aiData) )
00BB1299  cmp         dword ptr [ebp-2Ch],8  
00BB129D  jae         LoopStart+1Eh (0BB12B7h)  
    13:     {
    14:         iSum += k_aiData[ iLoop ];
00BB129F  mov         eax,dword ptr [ebp-2Ch]  
00BB12A2  mov         ecx,dword ptr [ebp-28h]  
00BB12A5  add         ecx,dword ptr [ebp+eax*4-24h]  
00BB12A9  mov         dword ptr [ebp-28h],ecx  
    15:         ++iLoop;
00BB12AC  mov         eax,dword ptr [ebp-2Ch]  
00BB12AF  add         eax,1  
00BB12B2  mov         dword ptr [ebp-2Ch],eax  
    16:         goto LoopStart;
00BB12B5  jmp         LoopStart (0BB1299h)  
    17:     }
    18: 
    19:     return 0;
00BB12B7  xor         eax,eax

As expected, the disassembly for this is very straightforward, and you should be familiar with almost all of it from previous posts.

As we saw in the first article on conditionals, the assembly code (lines 3 & 4) that maps to the if statement (line 2) tests the logical opposite of the high level code. This is because the high level if conceptually ‘steps into’ the curly brackets it controls if its test passes, whereas the assembly has to jump past the assembly code generated by the content of the if in order to not execute it (remember: curly brackets are a high level convenience for programmers!).

In this case, line 3 compares iLoop (at address [ebp-2Ch]) to 8 (the size of the array obtained from ARRAY_SIZE is a compile time constant), and (line 4) uses jae (jump if above or equal) to conditionally jump execution to LoopStart+1Eh (0BB12B7h) – which is the memory address immediately after the assembly generated by the content of the curly brackets controlled by the if statement.

The next block of assembly adds the iLoop-th element of k_aiData to iSum. By this point, we should all be familiar with the assembly for adding two integers, and the way in which the elements of k_aiData are accessed is the only real new assembly code idiom that we’re seeing in this disassembly.

The instruction that accesses the iLoop-th element from the array is doing a surprising amount of work for an assembly instruction; certainly this is the first time that we’ve seen any significant computation being performed within a single line of assembly code, and it’s all occurring in the square brackets in the place that usually contains the address of the value we wish to access.

So, let’s look at it in detail:

9	add ecx,dword ptr [ebp+eax*4-24h]

When line 9 is executed, the eax register holds the value of iLoop and [ebp-24h] is the address of the array k_aiData.

Since k_aiData is an array of int, the address of k_aiData[ 0 ] is [ebp-24h] and sizeof( int ) is 4 on the x86, it should be pretty obvious that the computation [ebp+eax*4-24h] on line 9 equates to the memory address of the iLoop-th element of k_aiData.

If you’re having trouble seeing it, here is the address computation seen in the disassembly rearranged step by step so that we can swap out the registers and memory addresses for the high level variables:

ebp+eax*4-24h

= ebp + ( eax*4 ) + (-24h)

= ebp + (-24h) + ( eax*4 )

= ( epb – 24h ) + (eax * 4 )

= &k_aiData[ 0 ] + ( iLoop * sizeof( int ) )

Now we’ve examined the new elements of the disassembly we’ve not seen before, the rest of this post should clip along fairly quickly :)

So, after the value stored in the iLoop-th element of k_aiData has been added to iSum, all that remains is to ++iLoop ( lines 12-14) and then jump back to the label at the start of the loop (line 16).

Clearly this will continue until iLoop >= 8, and so we can see that the assembly is isomorphic with the high level code.

Why add Looping Constructs?

Since looping behaviour can simply be achieved using the if-goto, this begs the question “Why did Dennis Ritchie (sadly no longer with us) bother with the rest of the looping constructs available in C?”

There are three main reasons that spring to my mind, the first is efficiency (of typing rather than execution), the second is robustness, and the third is clarity of intent.

Writing a loop using the if-goto idiom involves a fair amount of typing, and loops are very common in most code bases. No-one likes to type more than they have to – especially programmers. Since the programmers using the language were probably originally the programmers of the language it was more or less an inevitability that a more textually terse method of writing loops would come about.

Secondly, and more importantly, the code involved in any writing two given if-goto loops is very similar and doing it by hand would be more prone to error (as well as tedious) than using a code construct specifically made to handle looping which removes the need for the explicit goto and associated label.

Thirdly, and possibly even more importantly, an explicit looping construct makes the intent of the code far more clear, if and goto both have plenty of other uses as well as looping, and so any programmer coming along later to read code containing an if-goto loop would have to expend significant mental effort just to get to the point where they can see that the code is in fact a loop; which would clearly be very bad.

Taken together, these three reasons mean that you will almost certainly never write a loop using if-goto for any reason other than just for fun; and you certainly won’t need to write one. The only reason I am covering it is because I feel that it’s worth considering as a step in the evolution of looping constructs in languages.

while

So, we come to while. The while loop is basically an automatic if-goto, and we will see this when we look at the disassembly (which is essentially why I covered the if-goto in the first place).

Here’s the code snippet upgraded to use while

#include "stdafx.h"
 
#define ARRAY_SIZE(array) (sizeof(array)/sizeof(array[0]))
 
int main(int argc, char* argv[])
{
    int k_aiData[] = { 1, 2, 3, 4, 5, 6, 7, 8 };
    int iSum       = 0;
    int iLoop      = 0;
 
    while( iLoop < ARRAY_SIZE(k_aiData) )
    {
        iSum += k_aiData[ iLoop ];
        iLoop++;
    }
 
    return 0;
}

Clearly the high level code looks neater already, and (more importantly) the manual elements of putting the if and goto in the right places have been removed; so it’s a lot harder to do something wrong as a result of human error, and it’s instantly obvious that the code is looping over the content of the array k_aiData.

Much better – well done programming language designers of yesteryear!

Now let’s have a look at the (dis)assembly that it generates…

    11:     while( iLoop < ARRAY_SIZE(k_aiData) )
013E1299  cmp         dword ptr [ebp-2Ch],8  
013E129D  jae         main+77h (13E12B7h)  
    12:     {
    13:         iSum += k_aiData[ iLoop ];
013E129F  mov         eax,dword ptr [ebp-2Ch]  
013E12A2  mov         ecx,dword ptr [ebp-28h]  
013E12A5  add         ecx,dword ptr [ebp+eax*4-24h]  
013E12A9  mov         dword ptr [ebp-28h],ecx  
    14:         iLoop++;
013E12AC  mov         eax,dword ptr [ebp-2Ch]  
013E12AF  add         eax,1  
013E12B2  mov         dword ptr [ebp-2Ch],eax  
    15:     }
013E12B5  jmp         main+59h (13E1299h)  
    16: 
    17:     return 0;
013E12B7  xor         eax,eax

Almost entirely unsurprisingly, the assembly that has been generated from the while is essentially identical to that generated for the if-goto we just looked at – only the addresses that are being jumped to have changed.

This is the sort of thing that restores my faith in humanity; well, in compiler programmers specifically but they’re still human. I assume.

do-while

Let’s move swiftly on with the code snippet for the next type of loop, the do-while.

#include "stdafx.h"
 
#define ARRAY_SIZE(array) (sizeof(array)/sizeof(array[0]))
 
int main(int argc, char* argv[])
{
    int k_aiData[] = { 1, 2, 3, 4, 5, 6, 7, 8 };
    int iSum       = 0;
    int iLoop      = 0;
 
    do 
    {
        iSum += k_aiData[ iLoop ];
        ++iLoop;
    } 
    while( iLoop < ARRAY_SIZE(k_aiData) );
 
    return 0;
}

Essentially the same code, but now we’re testing the loop’s exit condition at the end of each loop rather than at the beginning.

All being sane in the universe, I think it would be reasonable to expect the assembly generated for this code to turn out very similar to the previous two loops – except that the testing code is likely to be after the body of the loop rather than before it….

    11:     do 
    12:     {
    13:         iSum += k_aiData[ iLoop ];
00CC1299  mov         eax,dword ptr [ebp-2Ch]  
00CC129C  mov         ecx,dword ptr [ebp-28h]  
00CC129F  add         ecx,dword ptr [ebp+eax*4-24h]  
00CC12A3  mov         dword ptr [ebp-28h],ecx  
    14:         ++iLoop;
00CC12A6  mov         eax,dword ptr [ebp-2Ch]  
00CC12A9  add         eax,1  
00CC12AC  mov         dword ptr [ebp-2Ch],eax  
    15:     } 
    16:     while( iLoop < ARRAY_SIZE(k_aiData) );
00CC12AF  cmp         dword ptr [ebp-2Ch],8  
00CC12B3  jb          main+59h (0CC1299h)  
    17: 
    18:     return 0;
00CC12B5  xor         eax,eax

As expected then, the code doing the work of the loop and incrementing iLoop is basically identical.

Also as expected, the conditional jump that keeps the loop going is a little different – it’s using the jump instruction jb (jump if below) so, unlike pretty much all the other assembly code we’ve looked at generated by high level conditionals, this is testing the same condition as the high level code – but why?

As discussed earlier, the high level language concept of ‘curly bracket scope’ doesn’t exist at the assembly level. Despite this, the compiler has to generate assembly code that is logically isomorphic with the high level code; so in order to satisfy the high level behavioural constraint of ‘stepping into’ the curly bracketed code if a pre-condition is met, the assembly skips over the code within the curly brackets if the condition isn’t met.

So, since the looping condition is a post-condition in a do-while loop (i.e. at the end of the ‘curly bracket scope’ it controls) the high level code and assembly code both need to jump back to the start of the loop if the looping condition is met, and so the test in the assembly code is the same as that at the high level.

for

So, we come to the for loop, the loop you probably use the most often.

The for loop was the looping construct that worked the hardest for you until the new C++11 ANSI standard introduced the ‘range-based’ for to the language this time last year (not counting the various template based solutions). Unfortunately (although it’s obviously supported in the recently released VC2012) support for the C++11 standard is patchy at best on most video game platforms so the for loop is still the default solution.

Let’s take a second to look at the ‘anatomy of a loop’. More or less any looping code it has 3 responsibilities in addition to the work it does per iteration of the loop:

a) declare and/or initialise loop state variables
b) test loop exit condition
c) update state variables for the next loop

These 3 responsibilities define the scope and manner of the iteration the loop is doing, and therefore can be seen as the ‘fingerprint’ of that iteration.

The for loop is a ‘language level refactoring’ that gathers these three responsibilities into one construct giving them textual adjacency, thus making the entire fingerprint visible in one place.

Whilst this is pretty obvious when you stop to examine it, the importance of explicitly stating this should not be underestimated.

Why? Let’s look at for compared to while, replacing the code with the corresponding a, b, or c from the list above.

for( a; b; c)
{
    //do work
}

as opposed to:

a;
while( b )
{
    //do work
    c;
}

So, the for loop takes up less vertical space than the while (in this instance at least) but what, if anything, are the other advantages:

variables declared by a in the for are scoped to the loop. Smaller scope == less entropy == less bugs.
c is obviously distinct from the work code of the loop in the for, but not so in the while (be honest; how many times have you accidentally done an infinite while because you forgot to increment at the end?)
the adjacency of a, b, and c in the for allows possible bugs with loop conditions to be spotted more easily

Whoever invented the for loop deserves a pat on the back, because for takes the improvements made by the while and do-while loops to the next level – by reducing human error and increasing the clarity of intent even further.

I looked him up and it turns out that the earliest equivalent to for I found by googling is the DO loop in FORTRAN which was invented in 1957 by a team led by the late John Backus at IBM. Since that’s about as close to an answer as I feel I need to get, I now invite you to join me in a posthumous air high-five to John to celebrate his team’s sterling work.

Let’s look at one now shall we? Here’s the code snippet:

#include "stdafx.h"
 
#define ARRAY_SIZE(array) (sizeof(array)/sizeof(array[0]))
 
int main(int argc, char* argv[])
{
    int k_aiData[] = { 1, 2, 3, 4, 5, 6, 7, 8 };
    int iSum       = 0;
 
    for( int iLoop = 0; iLoop < ARRAY_SIZE(k_aiData); ++iLoop )
    {
        iSum += k_aiData[ iLoop ];
    } 
 
    return 0;
}

…and here’s the disassembly (n.b. I un-ticked the ‘Show symbol names’ check box in the disassembly display options for this…)

    10:     for( int iLoop = 0; iLoop < ARRAY_SIZE(k_aiData); ++iLoop )
00DC1292  mov         dword ptr [ebp-2Ch],0  
00DC1299  jmp         00DC12A4  
00DC129B  mov         eax,dword ptr [ebp-2Ch]  
00DC129E  add         eax,1  
00DC12A1  mov         dword ptr [ebp-2Ch],eax  
00DC12A4  cmp         dword ptr [ebp-2Ch],8  
00DC12A8  jae         00DC12B9  
    11:     {
    12:         iSum += k_aiData[ iLoop ];
00DC12AA  mov         eax,dword ptr [ebp-2Ch]  
00DC12AD  mov         ecx,dword ptr [ebp-28h]  
00DC12B0  add         ecx,dword ptr [ebp+eax*4-24h]  
00DC12B4  mov         dword ptr [ebp-28h],ecx  
    13:     } 
00DC12B7  jmp         00DC129B  
    14: 
    15:     return 0;
00DC12B9  xor         eax,eax

Sooooo … this one looks a little different, right? It’s not very different though, just re-organised a little:

Line 2-3: is initialising iLoop (i.e. [ebp-2Ch]) to 0, and then jumping over lines 4-6
Lines 4-6: are incrementing iLoop
Lines 7-8: are comparing iLoop with 8 and exits the loop by jumping to line 19 if iLoop >= 8 (n.b. pre-condition check so opposite of high level)
Lines 11-14: indexing the array and accumulating the sum of element values (should look very familiar by now)
Line 16: loops back to line 4

So, the assembly in each of steps 1, 2, and 3 implements one of the semi-colon separated parts of the for loop’s ‘parameters; in fact, steps 1 to 3 correspond to a (initialise), c (increment), and b (test exit condition) respectively in our ‘anatomy of a loop’ list above.

Only steps 1 and 3 are executed on the first iteration of the loop, and only steps 2 and 3 on all other iterations.

Also note that steps 2 and 3 are in the opposite order in the assembly compared to the high level code – this is, again, down to the disparity between high level nicety and low level execution.

So, the assembly that is generated from a for loop is more or less as you might expect. We’ve covered all the (non-templated-non-C++11) looping constructs now, end of story – next article. Move along please.

Wait! I’m not quite finished!

Hold on! The reason the last post was about how to look at optimised assembly is mostly because I wanted to look at the optimised assembly generated by the C++ looping constructs in this post.

So, rather than re-compile all the snippets one by one let’s set up the project just like in post 8, and then download and paste in this code (massive ‘snippet’): CPPLLC_Part9MoreLoops.

This file contains a simple program that has 4 functions in addition to main – they are:

SumGoto – sums the elements of an array using an if-goto loop
SumWhile – sums the elements of an array using a while loop
SumDo – sums the elements of an array using a do-while loop, and
SumFor – sums the elements of an array using a for loop

All very straightforward really. The only unusual thing you might notice is that main looks like this:

int main( int argc, char* argv[] )
{
    // array and a nice const for the size
    const int k_iArraySize = 8;
    int       k_aiData[ k_iArraySize ] = { 0, 1, 2, 3, 4, 5, 6, 7 };
 
    int iSumGoto  = SumGoto ( k_aiData, atoi( argv[ 1 ] ) );
    int iSumWhile = SumWhile( k_aiData, atoi( argv[ 2 ] ) );
    int iSumDo    = SumDo   ( k_aiData, atoi( argv[ 3 ] ) );
    int iSumFor   = SumFor  ( k_aiData, atoi( argv[ 4 ] ) );
 
    std::cout << iSumGoto << iSumWhile << iSumDo << iSumFor;
    return 0;
}

So it’s using command line arguments as input, and printing to stdout for output. This is a relatively simple way to prevent the overzealous optimising compiler from removing all the code – we force it to keep it in there by doing input and output at runtime.

Before we compile and run it, you’ll also need to make a couple of changes in your project’s property pages – make sure you have the ‘Release’ build configuration selected…

The first is to pass some command line arguments to the code – apart from any other reasons, this is shockingly naive code and will crash if it doesn’t get the arguments it expects, so add the following (which will make it iterate k_aiData fully for each function):

We also need to turn off function inlining or the compiler will optimise away all the function calls making the disassembly much harder to follow:

Final pre-launch check: add a breakpoint to the C++ line in each loop that sums the loop’s elements (i.e. ‘iSum += xxxx’), and off we go!

Optimised Disassembly O’clock!

Build and run the code and you should end up with your debugger stopped on the breakpoint you have put in SumGoto.

Right click and choose ‘Go To Disassembly’, you should see something like the image below – but before we look at it in detail, a brief aside is needed:

The code in main that calls SumGoto looks like this:

00DB191A  push        eax  
00DB191B  lea         esi,[ebp-24h]  
00DB191E  call        SumGoto (0DB1880h)

eax (which contains k_iArraysize) is pushed onto the stack, but the address of k_aiData[ 0 ] (which is stored at [ebp-24h]) is stored into esi rather than being pushed onto the stack.

“Wait!” I hear you say “They just did who in a whatnow? I thought we covered calling conventions, and no-one said anything about using esi for parameter passing!“

Don’t worry about this for now, just accept that – for whatever reason – in this case the address of k_aiData[ 0 ] is being passed via the esi register (I investigate this in the article’s epilogue if you’re really interested).

So, here’s the disassembly for SumGoto:

make sure you have the same view options checked in the context menu, or your disassembly may look very different!

Interestingly this bears little visible relation to the debug disassembly we looked at for the if-goto earlier. So let’s pick it apart to see what it’s doing differently:

00DB1880 to 00DB1884 – function prologue of SumGoto.
00DB1885 – moving function parameter iDataCount (i.e. the number of loops) into the edi register.
00DB1888 to 00DB188E – initialising registers ecx, edx, ebx, and eax to 0 (n.b. anything XOR itself is 0).
ooDB1890 to 00DB1893 – compare edi (number of loops remaining) with 2; if less jump to 00DB18A7 (2nd instruction in step 9) otherwise continue.
ooDB1895 – another new assembly instruction; dec decreases its register operand by 1 – in this case edi (iDataCount).
00DB1896 to 00DB1899 – we know that the address of k_aiData[0] is in esi, so from the address calculation in the square brackets it is pretty obvious that these two lines are indexing into k_aiData and summing the odd and even elements into edx and ecx respectively.
00DB189D – is incrementing eax by two. eax clearly contains the count of elements that have been looped over so far – because…
00DB18A0 to ooDB18A2 – …are comparing eax to edi. If eax < edi execution jumps back to step 6.
00DB18A4 to 00DB18AB – this ties in with the decrement to edi made at step 5. Since the code is looping and summing 2 elements at a time, this code checks if iDataCount was odd or even. If odd it jumps to step 11, if even it jumps to step 12.
00DB18AD – leaves ecx unchanged. What is it for? It’s essentially a nop instruction (no operation), nop instructions are used in assembly code for various reasons such as memory maintaining alignment of certain instructions (the 1st answer to this question on Stack Overflow explains sufficiently for our requirements at this point). In any case, both possible code paths through step 9 will skip this instruction entirely.
00DB18B0 – if iDataCount was odd, this code moves the value of the array element that would have been missed by iterating 2 elements at a time into ebx.
00DB18B3 – this uses lea to add the sums of odd and even elements of k_aiData that have been accumulating in edx and ecx and store them in eax (remember, eax is used to return integer values from functions).
00DB18B6 – this is actually the start of the epilogue of SumGoto – restoring edi to the value it stored before SumGoto was called. There’s no particular reason for this to have been put in before the next instruction. Optimising compilers do this sort of thing relatively often, as long as the code it generates is correct it’s not worth worrying about too much.
00DB18B7 – this line adds the value from ebx (see step11) to the sum to be returned in eax.
00DB18B9 to 00DB18BB – function epilogue of SumGoto.

Ouch. That seems far more complex than the debug assembly code for the if-goto loop. You may have to read through it a few times before you satisfy yourself about how it works – I recommend stepping through it in the debugger looking at the registers in a watch window.

Somewhat surprisingly, SumWhile and SumFor look pretty much exactly like SumGoto, but SumDo is way smaller:

SumDo:
00DB1830  xor         eax,eax  
00DB1832  xor         ecx,ecx  
00DB1834  add         eax,dword ptr [esi+ecx*4]  
00DB1837  inc         ecx  
00DB1838  cmp         ecx,edx  
00DB183A  jl          SumDo+4 (0DB1834h)  
00DB183C  ret

This is incredibly simple to follow, and intuitively much more the sort of thing I would have intuitively expected to see for all of the looping constructs, but there is method to the compiler’s seeming madness…

Summing two elements per iteration of the loop like the assembly of SumGoto, SumWhile, and SumFor are doing is actually a form of loop unrolling. Although (in this code) the compiler doesn’t know how many iterations of the loop it will end up doing, it can still improve the overall ‘looping instructions to working instructions’ ratio of the loop by this pairwise unrolling. Over a large enough array it should be faster than code that is not unrolled in the same way.

By changing the compiler options (under C/C++ -> Optimisation) from ‘Maximize Speed (/02)’ to ‘Minimize Size (/01)’ you can generate assembly that looks a lot more as you would expect. Since /02 is the default for release build configurations under Visual Studio 2010 I thought I should explain this assembly, and I leave looking at the assembly generated by /01 as an exercise for you dear reader :)

Conclusions

So, there we have it. looping constructs, and a genuine taste of the differences between optimised and debug assembly – albeit in a massively simplified scenario compared to real code.

What should we take away from this? Well, I guess primarily the point of this was to demonstrate that whilst the optimising compiler is constrained to generate assembly code that is isomorphic with your high level code, you should never take it for granted that the code it generates will look how you expect it to.

This should, I think, about finish up the program control / structural aspects of C/C++ and leave us free to move on to look at the way other mechanics of the language work at the assembly level.

I feel that there might possibly be a post on the range based for and on recursion at some point, but we’ll see – feel free to leave a comment if you think there’s something glaring that I’ve left out and I’ll try to rectify that before moving on…

Finally, a hearty thank you to all the AltDevAuthors who chipped in with sage advice on this post – Tony, Paul, Ted, Bruce, Ignacio, and Rich.

Epilogue

Notes on [ebp+eax*4-XXh]

Whilst this addressing mode seems like magic, there are limitations on the computations that can be performed within the square brackets in this way – see this article on Wikipedia for a summary of the limits.

Regardless of this, it is commonly seen used in conjunction with another x86 assembly instruction called lea (load effective address) (as seen in the optimised SumGoto assembly) which will load the result of the address computation (rather than the value at that address) into a specific register.

When I’ve seen the mnemonic lea in the disassembly window it has most often been used for this purpose – though don’t assume that it is! Since we’re not (necessarily) assembly programmers, we don’t need to worry about this too much but I thought I’d mention it.

Notes on Using esi to pass parameters to functions

So, this is certainly not what we’d expect given the coverage of calling conventions we did earlier in the series.

I googled for at least 10 minutes (clearly not exhaustive, but usually long enough to find a trail to an answer) and couldn’t find any specific information pertaining to the use of esi to pass parameters in a documented calling convention; however I did find several other people who had observed this behaviour and were looking for answers about it.

So, in the spirit of discovery I decided to see what happened if I compiled the looping functions (SumGoto, SumWhile, SumDo, and SumFor) into a separate library and then linked to that library instead of having them compile inside the same logical compilation unit as main. As anticipated, this sorted out the parameter passing so that it conformed to the cdecl calling convention, no more kooky use of esi to pass the array.

What do we conclude from this then? Well, it seems that if the compiler knows that the code it’s generating isn’t going in a library (or you have Link Time Code Generation enabled) – and so code only has to conform to the ‘local’ calling conventions of the executable it’s generating – then the compiler takes liberties with the calling conventions in order to optimise function parameter passing – here’s a couple of links from Bruce on the matter: from MSDN (mentions it, but no specifics to speak of) and from StackOverflow.

Final take away point: if something makes no sense when you’re debugging, don’t assume anything – put on your Deerstalker and Sherlock Holmes your way to the bottom of it.

A final note on the genesis of loops

I’ve already mentioned that I didn’t find the page on the history of C that I was looking for, so I can’t say with any degree of certainty which order the various looping constructs were actually added to the language.

However, in my searching I did find this interesting little nugget of information on Stack Exchange about the history of looping – my personal gut feeling on this matter is that whoever first coined the use of Sigma in mathematical notation is probably the father (or mother) of programmatic looping, but whoever invented knitting is the true originator ;)

C/C++ Low Level Curriculum Part 8: looking at optimised assembly

Alex Darby — Mon, 07 May 2012 22:35:39 +0000

It’s that time again where I have managed to find a few spare hours to squoze out an article for the Low Level Curriculum. This is the 8th post in this series, which is not in any way significant except that I like the number 8. As well as being a power of two, it is also the maximum number of unarmed people who can simultaneously get close enough to attack you (according to a martial arts book I once read).

This post covers how to set up Visual Studio to allow you to easily look at the optimised assembly code generated for simple code snippets like the ones we deal with in this series. If you wonder why I feel this is worth a post of its own here’s the reason – optimising compilers are good, and given code with constants as input and no external output (like the snippets I give as examples in this series) the compiler will generally optimise the code away to nothing – which I find makes it pretty hard to look at. This should prove immensely useful, both to refer back to, and for your own experimentation.

Here are the backlinks for preceding articles in the series in case you want to refer back to any of them (warning: the first few are quite long):

Assumptions

Strictly speaking, dear reader, I am making tonnes of assumptions about you as I write this – that you read English, that you like to program etc. but we’ll be here all day if I try to list those so let’s stick to the ones that might be immediately inconvenient if they were incorrect.

I will be assuming that you have access to some sub-species of Visual Studio 2010 on a Windows PC, and that you are familiar with using it to do all the everyday basics like change build configurations, open files, edit, compile, run, and debug C/C++.

Creating a project

Open Visual Studio and from the menu choose “File -> New -> Project…”.

Once the new project wizard window opens (see below):

go to the tree view on the left of the window and select “Other Languages -> Visual C++”
in the main pane select “Win32 Console Application Visual C++”
give it a name in the Name edit box
browse for a location of your choosing on your PC
click OK to create the project

Once you have clicked OK just click “Finish” on the next stage of the wizard – in case you’re wondering, the options available when you click next don’t matter for our purposes (and un-checking the “Precompiled header” check box makes no difference, it still generates a console app that uses a precompiled header…).

Changing the Project Properties

The next step is to use the menu to select “Project -> Properties”, which will bring up the properties dialog for the project.

When the properties dialog appears (see image below):

select “All Configurations” from the Configuration drop list
select “Configuration Properties ->General” in the tree view at the left of the window
in the main pane change “Whole Program Optimisation” to “No Whole Program Optimisation”.

Next, in the tree view (see image below):

in the tree view, navigate to “C/C++ -> Code Generation”
in the main pane, change “Basic Runtime Checks” to “Default” (i.e. off)

Finally (see image below):

in the tree view, go to “C/C++ -> Output Files”
in the main pane change “Assembler Output” to “Assembly With Source Code /(FAs)”
once you’ve done that click “OK”

Now, when you compile the Visual Studio compiler will generate an .asm file as well as an .exe file. This file will contain the intermediate assembly code generated by the compiler, with the source code inserted into it inline as comments.

You could alternatively choose the “Assembly, Machine Code and Source (/FAcs)” option if you like – this will generate a .cod file that contains the machine code as well as the asm and source.

I prefer the regular .asm because it’s less visually noisy and the assembler mnemonics are all aligned on the same column, so that’s what I’ll assume you’re using if you’re following the article, but the .cod file is fine.

So, what did we do there?

Well, first we turned off link time code generation. Amongst other things, this will prevent the linker stripping the .asm generated for functions that are compiled but not called anywhere.

Secondly, we turned off the basic runtime checks (which are already off in Release). These checks make the function prologues and epilogues generated do significant amounts of (basically unneccessary) extra work causing a worst case 5x slowdown (see this post by Bruce Dawson on his personal blog for an in depth explanation).

Finally, we asked the compiler not to throw away the assembly code it generates for our program; this data is produced by the compilation process whenever you compile but is usually thrown away, we’re just asking Visual Studio to write it into an .asm file so we can take a look at it.

Since we made these changes for “All Configurations” this means we will have access to .asm files containing the assembly code generated by both the Debug and Release build configurations.

Let’s try it out

So in the spirit of discovery, let’s try it out (for the sake of familiarity) with a language feature we looked at last time – the conditional operator:

#include "stdafx.h"
 
int ConditionalTest( bool bFlag, int iOnTrue, int iOnFalse )
{
    return ( bFlag ? iOnTrue : iOnFalse );
}
 
int main(int argc, char* argv[])
{
    int a = 1, b = 2;
    bool bFlag = false;
    int c = ConditionalTest( bFlag, a, b );
    return 0;
}

The question you have in your head at this moment should be “why have we put the code into a function?”. Rest assured that this will become apparent soon enough.

Now we have to build the code and look in the .asm files generated to see what the compiler has been up to…

First build the Debug build configuration – this should already be selected in the solution configuration drop-down (at the top of your Visual Studio window unless you’ve moved it).

Next build the Release configuration.

Now we need to open the .asm files. Unless you have messed with project settings that I didn’t tell you to these will be in the following paths:

<path where you put the project>/Debug/<projectName>.asm

<path where you put the project>/Release/<projectName>.asm

.asm files

I’m not going to go into any significant detail about how .asm files are laid out here, if you want to find out more here’s a link to the Microsoft documentation for their assembler.

The main thing you should note is that we can find the C/C++ functions in the .asm file by looking for their names; and that – once we find them – the mixture of source code and assembly code looks basically the same as it does in the disassembly view of Visual Studio in the debugger.

main()

Let’s look at main() first. This is where I explain why the code snippet we wanted to look at was put in a function. I can tell you’re excited.

Here’s main() from the Debug .asm (I’ve reformatted it slightly to make it take up less vertical space):

_TEXT    SEGMENT
_c$ = -16                        ; size = 4
_bFlag$ = -9                        ; size = 1
_b$ = -8                        ; size = 4
_a$ = -4                        ; size = 4
_argc$ = 8                        ; size = 4
_argv$ = 12                        ; size = 4
_main    PROC                        ; COMDAT
; 9    : {
    push    ebp
    mov    ebp, esp
    sub    esp, 80                    ; 00000050H
    push    ebx
    push    esi
    push    edi
; 10   :     int a = 1, b = 2;
    mov    DWORD PTR _a$[ebp], 1
    mov    DWORD PTR _b$[ebp], 2
; 11   :     bool bFlag = false;
    mov    BYTE PTR _bFlag$[ebp], 0
; 12   :     int c = ConditionalTest( bFlag, a, b );
    mov    eax, DWORD PTR _b$[ebp]
    push    eax
    mov    ecx, DWORD PTR _a$[ebp]
    push    ecx
    movzx    edx, BYTE PTR _bFlag$[ebp]
    push    edx
    call    ?ConditionalTest@@YAH_NHH@Z        ; ConditionalTest
    add    esp, 12                    ; 0000000cH
    mov    DWORD PTR _c$[ebp], eax
; 13   :     return 0;
    xor    eax, eax
; 14   : }
    pop    edi
    pop    esi
    pop    ebx
    mov    esp, ebp
    pop    ebp
    ret    0
_main    ENDP
_TEXT    ENDS

As long as you’ve read the previous posts, this should mostly look pretty familiar.

It breaks down as follows:

lines 1-8: these lines define the offsets of the various Stack variables from [ebp] within main()’s Stack Frame
lines 10-15: function prologue of main()
lines 17-20: initialise the Stack variables
lines 22-30: push the parameters to ConditionalTest() into the Stack, call it, and assign its return value
line 32: sets up main()’s return value
lines 34-38: function epilogue of main()
line 39: return from main()

Nothing unexpected there really, the only new thing to take in is the declarations of the Stack variable offsets from [ebp].

I feel these tend to make the assembly code easier to follow than the code in the disassembly window in the Visual Studio debugger.

And, for comparison, here’s main() for the Release .asm:

_TEXT    SEGMENT
_argc$ = 8                        ; size = 4
_argv$ = 12                        ; size = 4
_main    PROC                        ; COMDAT
; 10   :     int a = 1, b = 2;
; 11   :     bool bFlag = false;
; 12   :     int c = ConditionalTest( bFlag, a, b );
; 13   :     return 0;
    xor    eax, eax
; 14   : }
    ret    0
_main    ENDP
_TEXT    ENDS

The astute amongst you will have noticed that the Release assembly code is significantly smaller than the Debug.

In fact, it’s clearly doing nothing at all other than returning 0. Good optimising! High five!

As I alluded to earlier, the optimising compiler is great at spotting code that evaluates to a compile time constant and will happily replace any code it can with the equivalent constant.

So that’s why we put the code snippet in a function

It should hopefully be relatively clear by this point why we might have put the code snippet into a function, and then asked the linker not to remove code for functions that aren’t called.

Even if it can optimise away calls to a function, the compiler can’t optimise away the function before link time because some code outside of the object file it exists in might call it. Incidentally, the same effect usually keeps variables defined at global scope from being optimised away before linkage.

I’m going to call this Schrödinger linkage (catchy, right?). If we want our simple code snippet to stay around after optimising we only need to make sure that it takes advantage of Schrödinger linkage to cheat the optimiser.

If the compiler can’t tell whether the function will be called, then it certainly can’t tell what the values of its parameters will be during one of these potential calls, or what its return value might be used for and so it can’t optimise away any code that relies on those inputs or contributes to the output either.

The upshot of this is that if we put our code snippet in a function, make sure that it uses the function parameters as inputs, and that its output is returned from the function then it should survive optimisation.

It’s really a testament to all the compiler programmers over the years that it takes so much effort to get at the optimised assembly code generated by a simple code snippet – compiler programmers we salute you!

ConditionalTest()

So, here’s the Debug .asm for ConditionalTest() (ignoring the prologue / epilogue):

; 5    :     return( bFlag ? iOnTrue : iOnFalse );
    movzx    eax, BYTE PTR _bFlag$[ebp]
    test    eax, eax
    je    SHORT $LN3@Conditiona
    mov    ecx, DWORD PTR _iOnTrue$[ebp]
    mov    DWORD PTR tv66[ebp], ecx
    jmp    SHORT $LN4@Conditiona
$LN3@Conditiona:
    mov    edx, DWORD PTR _iOnFalse$[ebp]
    mov    DWORD PTR tv66[ebp], edx
$LN4@Conditiona:
    mov    eax, DWORD PTR tv66[ebp]
; 6    : }

As you should be able to see, this is doing the basically same thing as the code we looked at in the Debug disassembly in the previous article:

branching based on the result of testing the value of bFlag (the mnemonic test does a bitwise logical AND)
both branches set a Stack variable at an offset of tv66 from [ebp]
and both branches then execute the last line which copies the content of that address into eax

Again, the assembly code is arguably easier to follow than the corresponding disassembly because the jmp mnemonic jumps to labels visibly defined in the code, whereas in the disassembly view in Visual Studio you generally have to cross reference the operand to jmp with the memory addresses in the disassembly view to see where it’s jumping to…

Let’s compare this with the Release assembler (again not showing the function prologue or epilogue):

; 5    :     return( bFlag ? iOnTrue : iOnFalse );
    cmp    BYTE PTR _bFlag$[ebp], 0
    mov    eax, DWORD PTR _iOnTrue$[ebp]
    jne    SHORT $LN4@Conditiona
    mov    eax, DWORD PTR _iOnFalse$[ebp]
$LN4@Conditiona:
; 6    : }

You will note that the work of this function is now done in 4 instructions as opposed to 9 in the Debug:

it compares the value of bFlag against 0
unconditionally moves the value of iOnTrue into eax
if the value of bFlag was not equal to 0 (i.e. it was true) it jumps past the next instruction…
…otherwise this moves the value of iOnFalse into eax

As I’ve stated before I’m not an assembly code programmer and I’m not an optimisation expert. Consequently, I’m not going to offer my opinion on the significance of the ordering of the instructions in this Release assembly code.

I am, however, prepared to go out on a limb and say it’s a pretty safe bet that the Release version with 4 instructions is going to execute significantly faster than the Debug version with 9.

So, why such a big difference between Debug and Release for something that when debugging at source level is a single-step?

Essentially this is because the unoptimised assembly code generated by the compiler must be amenable to single-step debugging at the source level:

it almost always does the exact logical equivalent of what the high level code asked it to do and, specifically, in the same order
it also has to frequently write values from CPU registers back into memory so that the debugger can show them updating

Summary

What’s the main point I’d like you to take away from this article? Optimising compilers are feisty!

You have to know how to stop them optimising away your isolated C/C++ code snippets if you want to easily be able to see the optimised assembly code they generate.

This article shows a simple boilerplate way to short-circuit the Visual Studio optimising compiler – mileage will vary on other platforms.

There are other strategies to stop the optimiser optimising away your code, but they basically all come down to utilising the Schrödinger linkage effect; in general:

use global variables, function parameters, or function call results as inputs to the code
use global variables, function return values, or function call parameters as outputs from the code
if you’re not using Visual Studio’s compiler you may also need to turn off inlining

A final extreme method I have been told about is to insert nop instructions via inline assembly around / within the code you want to isolate. Note that you should use this approach with caution, as it interferes directly with the optimiser and can easily affect the output to the point where it is no longer representative.

Epilogue

So, I hope you found this interesting – I certainly expect you will find it useful :)

The next article (as promised last time!) is about looping, which is another reason why it seemed like a good time to cover getting at optimised assembly code for simple C/C++ snippets.

I will be referring back to this in future articles in situations where looking at the optimised assembly code is particularly relevant.

If you’re wondering what you should look at first to see how Debug and Release code differ, and want to get practise at beating the optimiser, I’d suggest starting with something straight forward like adding a few numbers together.

Lastly, but by no means leastly, thanks to Rich, Ted, and Bruce for their input and proof reading; and Bruce for supplying me with the tip that made this post possible.

C/C++ Low Level Curriculum Part 7: More Conditionals

Alex Darby — Tue, 10 Apr 2012 15:46:57 +0000

Hello humans. Welcome to the 7th part of the C/C++ Low Level Curriculum series I’ve been writing. This post covers the conditional operator, and switch statements. As per usual I will be showing snippets of C++ code and throwing the corresponding x86 assembler at you (as produced by VS2010) to show you what your high level code is actually doing at the assembler level.

Disclaimer: in an ideal world I’d like to try to avoid assumed knowledge, but keeping up the level of detail in each post that this entails is, frankly, too much work. Consequently I will from now on point you at post 6 as a “how to” and then get on with it…

Here are the backlinks for preceding articles in the series (warning: it might take you a while, the first few are quite long):

http://altdevblogaday.com/2011/11/09/a-low-level-curriculum-for-c-and-c/
http://altdevblogaday.com/2011/11/24/c-c-low-level-curriculum-part-2-data-types/
http://altdevblogaday.com/2011/12/14/c-c-low-level-curriculum-part-3-the-stack/
http://altdevblogaday.com/2011/12/24/c-c-low-level-curriculum-part-4-more-stack/
http://altdevblogaday.com/2012/02/07/c-c-low-level-curriculum-part-5-even-more-stack/
http://altdevblogaday.com/2012/03/07/c-c-low-level-curriculum-part-6-conditionals/ [see near the top of this post for details on compiling & running the code snippets]

The conditional operator

I assume that everyone’s familiar with the conditional operator, also known as the “question mark”, or the ternary operator (“ternary” because it’s the only C/C++ operator that takes three operands).

If you’re not, here’s a link so you can catch up (I predict that you will be so stoked to find out about it that you will be over-using it within the week).

Personally I heartily approve of the conditional operator when used judiciously, but it’s not always great for source level debugging because it’s basically a single line if-else and can be hard to follow in the debugger (in fact I’ve heard of it being banned under the coding standards at more than one company, but there you are we can’t all be sane can we?).

Anyway, let’s have a quick look at it with some code:

#include "stdafx.h"
 
int main(int argc, char* argv[])
{
    // the line after this comment is logically equivalent to the following line of code:
    // int iLocal; if( argc > 2 ){ iLocal = 3; }else{ iLocal = 7; }
    int iLocal = (argc > 2) ? 3 : 7;
 
    return 0;
}

If you remember the the assembler that a basic if-else generated in the last article, then the assembler generated here will probably bust your mind gaskets…

Note:

I’ve deliberately left the function prologue and epilogue out of the asm below, and just left the assembler involved with the conditonal assignment
if your disassembly view doesn’t show the variable names, then you need to right click the window and check “Show Symbol Names”

     5:     int iLocal = (argc > 2) ? 3 : 7;
01311249  xor         eax,eax
0131124B  cmp         dword ptr [argc],2
0131124F  setle       al
01311252  lea         eax,[eax*4+3]
01311259  mov         dword ptr [iLocal],eax

Clearly this is not very much like the code for the simple if-else that we looked at previously.

This is because there is trickery afoot and the compiler has chosen to do sneaky branchless code to implement the logic specified by the C++ code.

So, let’s examine it line by line:

line 1 – uses the xor instruction to set eax to 0. Anything XORed with itself is 0.
line 2 – as in the previous if examples this uses cmp to test the condition, setting flags in a special purpose CPU register based on the result of the comparison.
line 3 – this is a new one! The instruction setless equal sets its operand to 1 if the 1st operand of the preceding cmp was less than or equal to the 2nd operand, and to 0 if it was greater. We’ve not seen the operand al before, it’s a legacy (386) register name which now maps to the lowest byte of the eax register (if you’re a sensible person and are stepping through this code in your debugger with the register window open, you will see that this instruction causes the eax register to be set to 1 – also note that this only works because eax has already been set to 0).
line 4 – uses the load effective address instruction do do some sneaky maths that relies on the value of eax set by setle in line 3.
line 5 – moves the value from eax into the memory address storing the value of iLocal

That’s all fine, but how does it work?

Firstly, note that at the assembler level the comparative instruction setle is (as in the previous post’s examples) testing the opposite condition to the conditonal specified in the C++ code.

This means that the eax register will be set to 0 in line 3 if argc is greater than 2, which in turn means that the eax*4+3 part of line 4 will evaluate to (0*4)+3 - i.e. 3.

Conversely, if argc is less than or equal to 2, the eax register will be set to 1 which in turn means that line 4 will evaluate to (1*4)+3 - i.e. 7.

So, as you can see, the assembler is doing the same branchless set of instructions regardless of the condition, but using the 0 or 1 result of the conditional instruction in the maths to cancel out or include one of the terms and give what I like to call a “mathematical if”. Clever.

Incidentally this sort of branchless-but-still-conditional code has been a bit / lot of a hot topic over the last few years, especially on consoles since their CPUs are particularly branch mis-prediction sensitive.

Judicious use of the “branchless condtional” idiom is a tool that can be used to combat branch (mis-)prediction related performance issues – for an example of this, see the use of the fsel PPU instruction in this ADBAD post by Tony Albrecht, and for brief a discussion of branch prediction issues (primarily PC related) see this article by Igor Ostrovsky (who works for Microsoft).

The conditional operator (part deux)

So, clearly our above super-simple-sample resulted in the compiler generating clever assembler because of the constant values in it; interesting certainly, but not necessarily representative of most “real world” assembler.

Let’s see what happens if we use variables with the conditional operator…

#include "stdafx.h"
 
int main(int argc, char* argv[])
{
    int iOperandTwo = 3;
    int iOperandThree = 7;
    int iLocal = (argc > 2) ? iOperandTwo : iOperandThree;
 
    return 0;
}

And, here’s the relevant disassembly:

     5:     int iOperandTwo = 3;
00CF1619  mov         dword ptr [iOperandTwo],3
     6:     int iOperandThree = 7;
00CF1620  mov         dword ptr [iOperandThree],7
     7:     int iLocal = (argc > 2) ? iOperandTwo : iOperandThree;
00CF1627  cmp         dword ptr [argc],2
00CF162B  jle         main+25h (0CF1635h)
00CF162D  mov         eax,dword ptr [iOperandTwo]
00CF1630  mov         dword ptr [ebp-50h],eax
00CF1633  jmp         main+2Bh (0CF163Bh)
00CF1635  mov         ecx,dword ptr [iOperandThree]
00CF1638  mov         dword ptr [ebp-50h],ecx
00CF163B  mov         edx,dword ptr [ebp-50h]
00CF163E  mov         dword ptr [iLocal],edx

Since the conditional operator is now assigning from variables we’d expect it to generate something that looks more like the sort of code we saw from the basic if-else we looked at last time, which it has.

We have the expected cmp followed by a conditional jump testing against the opposite of the conditional, then two blocks of assembler, the first of which (lines 7 to 9) unconditionally jumps over the second (lines 10 and 11) if it executes, so essentially it’s behaving more or less as expected; however there’s clearly some interesting stuff happening in there:

the two branches use different registers to store their intermediate values; the first uses eax, the second uses ecx
both branches store their result to the same memory address in the Stack (see this post if you don’t know or can’t remember about Stack Frames) – i.e. [ebp-50h]
the code that assigns the value to iLocal (lines 12 and 13) only exists once and is executed regardless of which branch was taken; it takes the value from[ebp-50h] and writes it into iLocal using uses a third register (edx)

The use of different registers for the different branches in step 1 looks like it might be significant but (according to several expert sources) this is apparently perfectly normal compiler behaviour and not anything to read into.

Steps 2 and 3 show that the that generated from the conditional operator (at least with VS2010) isn’t directly equivalent to the intuitively equivalent if-else statement:

// intuitively equivalent if-else of
// int iLocal = (argc > 2 ) ? iOperandTwo : iOperandThree;
int iLocal;
if( argc > 2 )
{
    iLocal = iOperandTwo;
}
else
{
    iLocal = iOperandThree;
}

Rather than choosing between one of two assignments like this if-else, the assembler generated for our use of the conditional operator does exactly what we told it to: choose one of two values (store it temorarily in the Stack) and assign iLocal from it.

A few final notes on the ? operator:

You can see that less lines of C++ code does not equate to less assembler
It can be nested, but don’t do it! It’s hideous and will also be very hard to follow when source-level debugging
Be very careful with operator precedence when using it. Use brackets to ensure it will resolve the way you intend.

Switch Statements

The final type of conditional statement we’ll be looking at is the switch statement. Like the conditional operator, the switch statement is an often abused and maligned construct that you wouldn’t want to live without.

To be fair to the switch statement it’s not the fault of the switch statement that it’s possible for maniacs to write brittle and insane code using them.

An aside about switch statements

Where I have consistently found really horrific examples of switch statements is when an originally stateless synchronous system has been forced to become asyncronous and state driven under time pressure. This specific situation seems always to somehow spawn the kind of monolithic, hard to follow, difficult to change, architecturally brittle switch statements that have given the switch statement a bad rep over the years.

Code that has had network functionality retrofitted to it is (in my experience) an extremely common place to find problem switch statements. It’s always better to fix a system properly if it starts to look systemically broken than it is to soldier on regardless, and if it looks like you need to introduce a set of states into a system to then (in my experience) it’s architecturally more sensible to use polymorphic behaviour (e.g. a state class with one or more virtual functions) than a switch statement.

Where were we?

Sorry, let’s get on and take a look at a switch statement…

#include "stdafx.h"
 
int main(int argc, char* argv[])
{
    int iLocal = 0;
 
    // n.b. no "break" in case 1 so we can
    // see what "fall through" looks like
    switch( argc )
    {
    case 1:
        iLocal = 6;
    case 3:
        iLocal = 7;
        break;
    case 5:
        iLocal = 8;
        break;
    default:
        iLocal = 9;
        break;
    }
 
    return 0;
}

And here’s the disassembly…

     9:     switch( argc )
00C61620  mov         eax,dword ptr [argc]
00C61623  mov         dword ptr [ebp-48h],eax
00C61626  cmp         dword ptr [ebp-48h],1
00C6162A  je          main+2Ah (0C6163Ah)
00C6162C  cmp         dword ptr [ebp-48h],3
00C61630  je          main+31h (0C61641h)
00C61632  cmp         dword ptr [ebp-48h],5
00C61636  je          main+3Ah (0C6164Ah)
00C61638  jmp         main+43h (0C61653h)
    10:     {
    11:     case 1:
    12:         iLocal = 6;
00C6163A  mov         dword ptr [iLocal],6
    13:     case 3:
    14:         iLocal = 7;
00C61641  mov         dword ptr [iLocal],7
    15:         break;
00C61648  jmp         main+4Ah (0C6165Ah)
    16:     case 5:
    17:         iLocal = 8;
00C6164A  mov         dword ptr [iLocal],8
    18:         break;
00C61651  jmp         main+4Ah (0C6165Ah)
    19:     default:
    20:         iLocal = 9;
00C61653  mov         dword ptr [iLocal],9
    21:         break;
    22:     }

This is more or less exactly what you’d expect:

line 1 stores argc into the Stack at [ebp-48h]
then block from line 2 to 9 implements the logic of the switch by a series of comparisons of this value against the constants specified in the case statements and associated conditional jumps to the assembler generated by the code in the corresponding case statement
if none of the conditional jumps are triggered, the logic causes an unconditional jump to the default: case.
in particular, note that:

wherever the break keyword is used this causes an unconditional jump past the end of the assembler generated by the switch

the “drop through” from case 1: into case 3: in the high level code happens at the assembler level as a by product of the organisation of the adjacent blocks of instructions generated for the switch by the compiler, and the lack of unconditional jump at the end of the assembler for case 1:

If you look at assembler from the sample if-else-if-else in the last article; you should be able to see that the assembler generated for this switch is (more or less) what would happen if we had written the switch as an if-else-if-else and then re-organised the assembler so all the logic was in one place at the top, and the assembler generated for each code block was left where it was.

So other than the fact that the switch statement is a very useful C/C++ language convenience for managing what would often otherwise be messy looking and error prone chains of if-else-if-else statements, based on this example it doesn’t appear to be doing anything which might offer a significant advantage at the assembler level – so why would I have claimed that the compiler might generate “pretty cool assembler” for a switch?

Before we assume we’ve seen it all, let’s try using a contiguous range of values for the constants in the cases of the switch. You know, just for fun – and for the sake of simplicity let’s start at 0.

#include "stdafx.h"
 
int main(int argc, char* argv[])
{
    int iLocal = 0;
 
    switch( argc )
    {
    case 0:
        iLocal = 4;
        break;
    case 1:
        iLocal = 5;
        break;
    case 2:
        iLocal = 6;
        break;
    case 3:
        iLocal = 7;
        break;
    }
 
    return 0;
}

And here’s the disassembly it generates…

Ok, so this time something more interesting is definitely going on – n.b. I’ve used a screenshot rather than just pasting the text because we need to look in a memory window to make sense of it.

So what exactly is it doing?

it moves argc into eax, then stores it into the Stack at [ebp-48h]
it then compares the value stored in the address [ebp-48h] with 3 (i.e. our maximum case constant)
if this value is greater than 3 then ja (jump above) on the next line will cause execution to jump to 8D1658h – the 1st instruction after the code generated by the case blocks, skipping the switch
if the value is less than or equal to 3 then the value is moved into ecx, and we then have an unconditional jump to … somewhere :-/

Ok, so that final unconditional jump has some syntax we’ve not yet seen for its address operand, and which clearly isn’t a constant:

1	jmp dword ptr (1B1664h)[ecx*4]

This says “jump to the location stored in the memory address at an offset of 4 times the value of ecx from the memory address 8D1664h“, so how is this implementing the logic of the C++ switch statement?

To answer this question we need to look in a memory window at the address 8D1664h (n.b. to open a memory window from the menu in VS2010 when debugging go Debug -> Windows -> Memory -> … and choose one of the memory windows. To set the address just copy and paste it from the disassembly into the “Address:” input box. You will also need to right click and choose “4-byte integer” and set the “Columns:” list box to 1 to have it look like the screenshot above).

So, if you cast your eyes up to the memory window on the left of the screenshot above, you will see that the top 4 rows are highlighted, these values start at address 8D1664h and are 4 byte integers (hence the ecx*4 in the operand) – which specifically in this case are pointers.

The instruction jmp dword ptr (8D1664h)[ecx*4] will jump to the value stored in the address:

8D1664h + 0 = 8D1664h if the value in ecx is 0
8D1664h + 4 = 8D1668h if the value of ecx is 1
8D1664h + 8 = 8D166Ch if the value of ecx is 2
8D1664h + Ch = 8D1670h if the value of ecx is 3

So, the four highlighted rows make up a jump table – since our case constant’s range is from 0 to 3 it is an array of 4 pointers – with each element of the array pointing to the execution address of the case block matching its array index.

You can verify this by checking the addresses of the first instruction generated for each case against the 4 values stored in the array.

Maybe it’s just me, but I think this is some pretty cool assembler. It’s certainly more elegant that the assembler generated by the first switch we looked at, but what – if anything – is the advantage of this over the assembler that was generated for the previous case statement?

In theory this jump table form reaches the code in constant time for all cases, whereas in the if-else-if-else form the time to reach the code corresponding to each case will be proportional to the number of previous cases in the switch statement.

You’re pretty unlikely to find that a switch statement is a performance bottleneck in your code (unless you’ve done something silly) but, all things being equal, the jump table appoach uses less instructions to get to the conditional which is normally A Good Thing and – in theory – should make it faster on average.

One final note on switch statements; I am reliably informed that in addition to the if-else-if-else alike linear search behaviour for resolving the correct case to execute, most modern compilers are also capable of generating a binary search for the cases of switch statements with appropriate ranges of case constant values.

Using a binary search rather than a linear search will improve average search time from linear to logarithmic (i.e. O(n) to O(log n)). However, in the average case a binary searched switch will still almost always take more instructions and branches to reach the correct case than a jump table switch.

It’s also possible that the compiler might choose to use one or more of these methods in a single switch, though this would probably require a large number of cases in the switch and ranges of case constants with very specific properties so it’s not likely you will come across these very often.

A couple of final things to note about switch statements:

the compiler should be able to generate a jump table regardless of the order in of the constants in your code (e.g. case 2: … case 1: … case 3: … should still work fine)
having a range of case constants that starts at 0 makes the conditional code around a jump table simpler, as it removes the lower bounds check
a jump table should get created as long as the overall range of constants is large enough and/or closely packed enough for the compiler to decide it’s worthwhile even if they’re not completely contiguous. Look at the disassembly if you want to check.

Summary

So, this concludes our look at conditionals, hopefully you’ve found it interesting and illuminating ;)

A final point to take away from our look at conditionals is that whilst the compiler could generate the same assembler for an if-else as for the conditional operator it doesn’t. Similarly, it could generate the same assembler from an if-else-if-else as for a switch statement but it doesn’t do that either.

In part, this shows the limits of the compiler but also shows the importance of using the appropriate conditional for purpose – the benefit is that which you use makes your intent clearer to human readers of your code.

We’ve now covered enough ground that you should be finding that you can apply the information I’ve given you to everyday programming problems such as debugging release code, or code you don’t have debugging information for.

The main things I’d like you to take away from our look at conditionals are all things that will help you when debugging without symbols:

anytime you see cmp followed by a jxx to a nearby address in the disassembly you’re probably looking at code generated by a conditional statement in the C/C++ code
if the address operand to the jump instruction is lower than the current instruction’s address (i.e. it’s jumping backwards) you’re most likely looking at a loop
assembler generated from conditionals generally tests the opposite of the test being done in the C / C++ code

By using these heuristics, looking at the values in the registers, the values in the Stack that have been written by the assembler, and by looking up your current address in the symbol file to tell you which function you’re in (if you’re not generating a symbol file for all your builds you should be – look in the documentation for your platform’s compiler toolchain to find out how) you should be able to make an educated guess at what variables in the C/C++ code are likely to be causing the current issue and this will usually tell you why it crashed, or give you a lead so you can Sherlock Holmes your way to the root of the problem – it’s certainly a lot quicker than the ubiquitous insertion of the many printf()…

Our next topic will be loops, which obviously also use conditional jumps (which is why we covered conditionals first…)

One final thing…

Thanks to Tony, Bruce, and Fabian for extra information, advice, and proof reading.

And, for those of you who like to go off and look for yourselves (hopefully most of you!), I’ve recently discovered this wiki book on x86 Assembler http://en.wikibooks.org/wiki/X86_Assembly. It has a large overlap with this series of articles and also covers programming in x86 assembler. Highly recommended – I’ve certainly found it pretty useful.

A final, final nugget of wisdom from Bruce Dawson:

Another problem I’ve seen with ?: is with people who have ‘cleverly’ created string classes that both have a const char* constructor and a const char* conversion operator. This has potential to be exquisitely dangerous and exquisitely inefficient, by allowing lots of hidden conversions. These come to their fruition with ?:. Imagine this:

return bFlag ? mStringObject : “Hello world”;

The question is, what is the type of this expression? Does mStringObject get converted to a const char*, or does “Hello world” get converted to a string object? I have no idea, and nobody should memorize the relevant rules. Such code is too fragile and dangerous.

Some people might assume that the type of the ?: will depend on the return type of the function but that is not true. They are independent. Thus, it is quite possible that “Hello world” will be converted to a string object and then (if the return type of the function is const char*) this (temporary!!!) string object will be converted back to a const char*. In addition to being inefficient this leads to undefined behavior, since we are returning a pointer to memory owned by an object that is destroyed as the function exits.

Using the ?: operator with mismatched types is evil evil evil. String classes with a const char* conversion operator are evil evil evil. Putting them together… priceless.

C / C++ Low Level Curriculum Part 6: Conditionals

Alex Darby — Wed, 07 Mar 2012 07:06:41 +0000

Hello interwebs! As the title suggests this is the 6th part of the C / C++ Low Level Curriculum series I’ve been doing. In this installment we’ll be starting to look at conditional statements, and what the code that you’re asking the compiler to generate when you use them looks like (at least before the optimiser gets to it…).

Just in case anyone is unclear about what they are, conditionals are the language features that allow us control over which parts of our code get executed. At face value, the subject of conditionals might seem a simple one, but it is precisely because it seems simple – and because so much else builds on top of it – that it is the first topic that I’ve chosen to look at in detail after function calls.

Though we won’t get around to all of them in this post, our look at conditionals will take us on a tour through a representative sample of x86 disassembly generated by if statements, the conditional operator (or “ternary operator”, or “question mark”), and switch statements; and whilst we look at all of these we’ll also be looking at disassembly generated by the (built in!) relational and logical operators that are used with them (i.e. ==, !=, <=, >=, >, <, !, &&, and ||).

Prologue

Firstly, I’d like to apologise to anyone who reads these posts regularly for the fact that my rate of posting has slowed down – I will hopefully speed up again to the regular 2 week posting cycle in the near future.

Secondly, here are the backlinks for anyone who wants to start from the beginning of the series (warning: it might take you a while, the first few are quite long):

Generally I will try to avoid too much assumed knowledge; but if something comes up that I’ve explained previously, or that I know another ADBAD author has covered already then I will just link to it; this implies that you, dear reader, should assume that I assume you will read anything I link to if you want to make complete sense of the article :)

Compiling and running code from this article

I assume that you are using Windows, are familiar with the VS2010 IDE, and comfortable writing, running, and debugging C++ programs.

As with the previous posts in this series, I’m using a win32 console application made by the “new project” wizard in VS2010 with the default options (VS2010 express edition is fine).

The only change I make from the default project setup is to turn off “Basic Runtime Checks” to make the generated assembler more legible (and significantly faster…) see this previous post for details on how to do this.

To run code from this article in a VS2010 project created this way, open the .cpp file that isn’t stdafx.cpp and replace everything in it with text copied and pasted from the code box.

The disassembly we look at is from the debug build configuration, which generates “vanilla” unoptimised win32 x86 code.

Instructions and Mnemonics: an aside

I’ve just realised that so far in this series I have typically been using the term instruction when referring to an assembler mnemonic.

I felt that I should point out that this isn’t 100% accurate, because whilst assembler mnemonics are normally thought of as having a 1:1 correspondence to binary CPU instructions, they are not actually instructions.

In fact, in x86 assembler, the menemonics often actually have a 1:x relationship with the corresponding opcodes, because multiple variants of each mnemonic exist that differ in the types and sizes of their operands.

This is not something you should worry yourself about too much, as it’s a fairly harmless Kenobiism, but I still felt I should point it out if I was going to carry on doing it ;)

Conditionals

The best place to start is, as someone or other famously once remarked, at the beginning; so let’s start with the most basic form of the if statement.

Before anyone mentions it, I know I could have omitted the curly braces around iLocal = 1; on line 9. If you’re the kind of person who’s so lazy that you like to leave out curly braces in these situations then that’s up to you; but I would just like to point out that there is probably a special place in one of the deeper and less pleasant circles of the Hell I don’t believe in that is reserved for your sort – just a couple of floors up from those who do the same thing with loops.

Also, I’ve left the #inlcude “stdafx.h” in the code box so that your line numbers match mine if you’re working through this yourself.

#include "stdafx.h"
 
int main(int argc, char* argv[])
{
    int iLocal = 0;
 
    if( argc < 0 )
    {
        iLocal = 1;
    }
 
    return 0;
}

Anyway, as usual if you’re looking at this in VS2010 then copy and paste the above code over whichever is your project’s main .cpp file, put a breakpoint on line 7, tell Visual Studio to compile and run, wait for the breakpoint to be hit, then right click in the source window and choose “Go To Disassembly”. You should now be seeing something like this:

n.b. right-click and check you have the same options checked as me...

As we already know the assembler above int iLocal = 0; is the function prologue (or preamble) and the assembler after the closing brace of main() is function epilogue.

The specific disassembler we’re interested in is between lines 7 and 13 of the source code that is shown inline with the disassembly, so here it is pasted into a code window (N.B. the addresses corresponding to the disassembly instructions will almost certainly differ on your screen if you’re running this yourself…)

     7:     if( argc < 0 )
010D20B0  cmp         dword ptr [argc],0
010D20B4  jge         main+1Dh (10D20BDh)
     8:     {
     9:         iLocal = 1;
010D20B6  mov         dword ptr [iLocal],1
    10:     }
    11:
    12:     return 0;
010D20BD  xor         eax,eax
    13: }

Straight away, there are a couple of new assembler mnemonics we’ve not come across so far in this series of posts. We’ll cover these as we come to them.

line 2 is comparing argc against 0. The instruction cmp doesn’t have an instant effect on code execution, it compares its first and second operand and stores the result of the comparison in an internal register of the CPU known as EFLAGS.

line 3 uses the mnemonic jge, which means jump greater equal. It will cause a jump to the address 0x010D20BD supplied as its operand if the outcome of the previous cmp instruction has set the content of the EFLAGS register to indicate that its first operand was greater than or equal to its second operand – i.e. if argc is greater than or equal to 0 then execution will jump past the instructions generated by the block of code controlled by the if.

Hold on a minute…

So, we’ve only covered the most basic form of an if statement and we’ve already encountered a major difference between what we might think we’re asking the compiler to do, and the code it’s generating.

The intuitive way to think about an if block in a high level language is that if the condition of the if is met, then execution will step into the curly braces delimted block of code it controls.

However, the assembler is clearly testing the logical opposite of what we’ve asked it to, and if that condition is met then it is skipping over the code block controlled by the if.

This is because, at the assembler level, instructions are executed in sequential order unless a jump instruction tells it to do otherwise – and so assembler has no equivalent to the high level concept of a curly brace delimited “code block”. The upshot of this is that the high level notion of “stepping into” a code block is implemented at the assembler level by “not skipping over” the code the block has generated.

Clearly these two behaviours are logically isomorphic (i.e. produce the same output given the same input), but the high level version is easier for the human mind to cope with intuitively, and the version generated by the compiler better suits the sequential-execution-unless-tampered-with behaviour of the underlying machine.

Just for the sake of clarity let’s re-write the C++ code in a form that matches what the assembler we just looked at does, using the C++ keyword goto:

#include "stdafx.h"
 
int main(int argc, char* argv[])
{
    int iLocal = 0;
 
    // corresponding original code in comments to the right...
    if( argc >= 0 ) goto GreaterEqualZero;   //if( argc < 0 )
                                             //{
    iLocal = 1;                              //    iLocal = 1;
                                             //}
    GreaterEqualZero:
 
    return 0;
}

NOTE: Ironically (though unsurprisingly) this C++ code generates different assembler to the original code. Please don’t worry about this.

if … else if … else

So let’s take a look at a more complicated if construct:

#include "stdafx.h"
 
int main(int argc, char* argv[])
{
    int iLocal = 0;
 
    if( argc == 0 )
    {
        iLocal = 13;
    }
    else if( argc != 42 )
    {
        iLocal = (6 * 9);
    }
    else
    {
        iLocal = 1066;
    }
 
    return 0;
}

This code generates the following assembler, which given what we saw in the previous example is more or less exactly what you’d expect:

     7:     if( argc == 0 )
002020B0  cmp         dword ptr [argc],0
002020B4  jne         main+1Fh (2020BFh)
     8:     {
     9:         iLocal = 13;
002020B6  mov         dword ptr [iLocal],0Dh
002020BD  jmp         main+35h (2020D5h)
    10:     }
    11:     else if( argc != 42 )
002020BF  cmp         dword ptr [argc],2Ah
002020C3  je          main+2Eh (2020CEh)
    12:     {
    13:         iLocal = (6 * 9);
002020C5  mov         dword ptr [iLocal],36h
    14:     }
    15:     else
002020CC  jmp         main+35h (2020D5h)
    16:     {
    17:         iLocal = 1066;
002020CE  mov         dword ptr [iLocal],42Ah
    18:     }
    19:
    20:     return 0;
002020D5  xor         eax,eax

The main things to note about this code are:

Each if and else if condition is implemented as a cmp followed by a jxx – there are two new ones in here: je (jump equal) and jne (jump not equal)
As in the first example, each if and else if condition is causing the compiler to generate the logically opposite test to the high level language, and skipping the assembler generated by the controlled block of code if it succeeds
The test for the first if jumps to the condition of the else if when its condition is not met. If there were more chained else if statements then this pattern would continue through them.
Each block of code has an unconditonal jmp at the end of it that takes the execution past the code block controlled by the else

That was all pretty straightforward for once. Joy.

Next, let’s take a look at the effects of the && and || operators:

#include "stdafx.h"
 
int main(int argc, char* argv[])
{
    int iLocal = 0;
 
    if( ( argc >= 7 ) && ( argc <= 13 ) )
    {
        iLocal = 1024;
    }
    else if( argc || ( !argc ) || ( argc == 69 ) ) // deliberately nonsensical test
    {
        iLocal = 666;
    }
 
    return 0;
}

This generates the following assembler, which is much more interesting than the first if … else if example:

     7:     if( ( argc >= 7 ) && ( argc <= 13 ) )
00F120B0  cmp         dword ptr [argc],7
00F120B4  jl          main+25h (0F120C5h)
00F120B6  cmp         dword ptr [argc],0Dh
00F120BA  jg          main+25h (0F120C5h)
     8:     {
     9:         iLocal = 1024;
00F120BC  mov         dword ptr [iLocal],400h
00F120C3  jmp         main+3Eh (0F120DEh)
    10:     }
    11:     else if( argc || ( !argc ) || ( argc == 69 ) )
00F120C5  cmp         dword ptr [argc],0
00F120C9  jne         main+37h (0F120D7h)
00F120CB  cmp         dword ptr [argc],0
00F120CF  je          main+37h (0F120D7h)
00F120D1  cmp         dword ptr [argc],45h
00F120D5  jne         main+3Eh (0F120DEh)
    12:     {
    13:         iLocal = 666;
00F120D7  mov         dword ptr [iLocal],29Ah
    14:     }
    15:
    16:     return 0;
00F120DE  xor         eax,eax
    17: }

Now, I don’t know about you but the first time I saw assembler generated by using && and || I was amazed by the sheer simplistic audacity of it – I think it’s because I’m not an assembler programmer, but I expected it to be a little more complicated and fiddly than this.

Looking in detail at the code generated for the if statement using && (lines 2 to 5), we can see that is using another two conditional jump instructions we’ve not yet seen: jl (jump less) and jg (jump greater) and as before is testing the logically opposite condition to that specified by the high level code.

More interestingly, in order to implement &&, the compiler simply concatenates the separate tests – if either of these tests fails they will cause execution to jump past the block of code controlled by the if statement. This means that the block of code controlled by the if will only be executed if both tests are passed, which clearly implements a logical AND.

If we now turn our attention to the code generated by the if statement using || (lines 12 to 17) we see a similar pattern of consecutive conditional tests, though clearly it must be different since it implements conditions joined by ||.

The first thing to notice is that the first two tests done by the assembler are logically the same as their high level equivalents. This bucks the trend we have seen so far, but why?

Well, the address passed as operands to the conditional jumps on lines 13 and 15 will move execution past the rest of the tests, to the start of the controlled code block. Unsurprisingly though, the last test of the || if statement (lines 16 & 17) follows the standard test-the-opposite-and-jump-past idiom we’ve come to expect from an if statement.

The jump-into-controlled-block behaviour of all but the last || conditional means that as soon as any one of the tests is passed the controlled code will be executed, which clearly implements a logical OR.

Aside: Lazy Evaluation

I’m sure that most – if not all – of you will have heard that C++ has “lazy evaluation” of && and ||. If you’ve never been 100% sure of what this means, you’ve just seen it in action in this block of assembler!

The && will fail if either of its operands fails; so if the first test fails it will never do the second (or third, or fourth …).

Similarly the || will succeed if either of its operands succeeds; so if the first test passes it will never do the second (or third, or forth …).

Since neither necessarily evaluates all of its operands this makes them technically “lazy”; which in this circumstance you can read as awesome, elegant, and efficient (for certain definitions of efficient).

Summary

The main points to take away from the assembler we’ve looked at in this post are that:

The conditional test that you see in the disassembly is likely to be the logical opposite of the test the high level code is asking for…
…and the conditional jump will typically be jumping over the assembler that is generated by the “code block” controlled by the conditional in the the high level code.
This is because there is no concept of a “code block” at the level of assembler.

More or less all control code boils down to various combinations of conditionals and jumps at the assembly level; and being familiar with the assembler mnemonics that are used to implement these C / C++ features, and the various ways that they are used will almost certainly prove invaluable when you find yourself in the unenviable situation of a crash deep within some library code that you don’t have symbols for (or that your debugger can’t find symbols for).

Incidentally if you find yourself lost in code that you should have symbols for but your machine refuses to find them, you might try this post by Bruce Dawson to see if it helps ;)

Next time we’ll continue looking at conditionals with the conditional operator (also known as the “ternary operator” or more commonly the question mark), and the the switch statement.

Also, thanks to Fabian and Bruce for giving this a once-over and offering sage advice on content.

Disclaimers

I am pretty sure that the code in this article doesn’t demonstrate all the relational operators; so I’m leaving it to you, dear reader, to try out the ones I left out to see what they do :)

I also avoided writing any conditions for the if statements that contained function calls, clearly this will make the assembler generated by the test code significantly more complex and assuming that you have read the previous posts on the assembler generated when calling functions too you should be able to make sense of this by yourself. I have to admit that I also partly avoided doing this so I could steer clear of operator overloading. That’s for later. Probably.

C / C++ Low Level Curriculum Part 5: Even More Stack

Alex Darby — Tue, 07 Feb 2012 07:06:59 +0000

Welcome to the 5th installment of the series I’m doing on a C/C++ Low-Level Curriculum. This is the 3rd post about the Stack, the fundamentals have been covered a couple of posts ago, and the previous post and this one are really just for extra information to round out the picture of ways the Stack is used in win32 x86 function calls – then we can move on to other low level aspects of the C/C++ languages.

The last two (win32 x86) function calling conventions we’re going to look at are thiscall which is used for calling non-static member functions of classes, and fastcall which emphasises register use over stack use for parameters. As with the previous posts about the Stack, the point of this isn’t so much the specific calling conventions that we’re examining, but rather to see the different ways that the Stack and registers are used to pass information around when functions are called.

Previously on #AltDevBlogADay…

If you missed the previous C/C++ Low Level Curriculum posts, here are some backlinks:

Generally I will try to avoid too much assumed knowledge, but this post does assume that you have read the posts linked above as 3 and 4 (or have a working knowledge of how the Stack works in vanilla x86 assembler, in which case why are you reading this!?).

Compiling and running code from this article

I assume that you are familiar with the VS2010 IDE, and comfortable writing, running, and debugging C++ programs.

As with the previous posts in this series, I’m using a win32 console application made by the “new project” wizard in VS2010 with the default options (express edition is fine).

To run code from this article in a VS2010 project created this way open the .cpp file that isn’t stdafx.cpp and replace everything below the line: #include “stdafx.h” with text copied and pasted from the code box.

The disassembly we look at is from the debug build configuration, which will generate “vanilla” unoptimised win32 x86 code.

The “thiscall” calling convention

As I’m sure you’re aware, in any non-static class member function it is possible to access a pointer to the instance of the class that the function was called on via the C++ keyword this.

The presence of the this pointer is often explained away by saying that it is an invisible “0th parameter to member functions”, which isn’t necessarily incorrect but is the same kind of truth that Obiwan Kenobi might have dealt in if he had been a computer science professor rather than a retired Jedi Knight; that is to say “true, from a certain point of view”.

The thiscall calling convention is more or less exactly the same as the stdcall calling convention we have already looked at in some detail in the last two posts (this->pPrevious->pPrevious, this->pPrevious). Though it is the default calling convention used by the VS2010 compiler for non-static member functions, it’s worth noting that there are situations where the compiler won’t use it (e.g. if your function uses the elipsis operator to take a varaible number of arguments).

As we have seen in the last two posts; the unoptimised win32 x86 stdcall calling convention passes its parameters on the Stack. The thiscall convention obviously must somehow pass the this pointer to member functions, but rather than storing an extra parameter on the Stack, it uses a register (ecx) to pass it to the called function.

The code below demonstrates this…

class CSumOf
{
public:
    int m_iSumOf;

    void SumOf( int iParamOne, int iParamTwo )
    {
        m_iSumOf = iParamOne + iParamTwo;
    }
};

int main( int argc, char** argv )
{
    int iValOne        = 1;
    int iValTwo        = 2;
    CSumOf cMySumOf;
    cMySumOf.SumOf( iValOne, iValTwo );
    return 0;
}

Paste this into VS2010, and put a breakpoint on the line

cMySumOf.SumOf( iValOne, iValTwo );

Run the debug build configuration; when the breakpoint is hit, right click and choose “Go To Disassembly”, and you should see something like this (n.b. the addresses in the leftmost column of the disassembly will almost certainly differ):

Make sure that the check boxes in your right-click context menu match those shown in this screenshot, or your disassembly will not match mine!

The block of assembler that we’re interested in for the purposes of illustrating how the thiscall convention works is shown below:

    14:     int iValOne        = 1;
00EE1259  mov         dword ptr [iValOne],1
    15:     int iValTwo        = 2;
00EE1260  mov         dword ptr [iValTwo],2
    16:     CSumOf cMySumOf;
    17:     cMySumOf.SumOf( iValOne, iValTwo );
00EE1267  mov         eax,dword ptr [iValTwo]
00EE126A  push        eax
00EE126B  mov         ecx,dword ptr [iValOne]
00EE126E  push        ecx
00EE126F  lea         ecx,[cMySumOf]
00EE1272  call        CSumOf::SumOf (0EE112Ch)

The assembler involved with calling CSumof::SumOf() starts at line 7 and goes to line 12.

Lines 7 to 10 are pushing the parameters to the function onto the stack in reverse order of declaration, exactly as with the stdcall convention we looked at in the previous article.

Line 11 is storing the address of cMySumOf in ecx using the instruction lea. If you right click and un-check “Show Symbol Names” you can see that lea is computing the address of cMySumOf given its offset from the ebx register.

Line 12 is obviously calling the function.

Stepping into the function call in the disassembly you should see the following: (not forgetting that we have to step through an additional jmp instruction before we get there because of VS2010 incremental linking – see approx. half way through this post for the details)

     6:     void SumOf( int iParamOne, int iParamTwo )
     7:     {
00EE1280  push        ebp
00EE1281  mov         ebp,esp
00EE1283  sub         esp,44h
00EE1286  push        ebx
00EE1287  push        esi
00EE1288  push        edi
00EE1289  mov         dword ptr [ebp-4],ecx
     8:         m_iSumOf = iParamOne + iParamTwo;
00EE128C  mov         eax,dword ptr [iParamOne]
00EE128F  add         eax,dword ptr [iParamTwo]
00EE1292  mov         ecx,dword ptr [this]
00EE1295  mov         dword ptr [ecx],eax
     9:     }

The calling code stored the address of the calling instance of the local variable cMySumOf in the ecx register before calling this function, and if we examine line 9 in code box above, you can see that – compared to the stdcall assembler – the function prologue has an extra step – it is moving the value in ecx into a memory address within the function’s stack frame (i.e. ebp-4). The upshot of this is that after line 9 [ebp-4] now stores the function’s this pointer.

The function then proceeds exactly as you might expect from the disassembly we’ve examined in previous articles up until line 13.

Line 13 moves the this pointer (previously stored in the function’s stack frame) into ecx, then line 14 stores the value of eax into the address specified by ecx (remember: in the VS2010 disassembly view, values in [square brackets] are memory accesses, taking the address to access from the value in the brackets). If you right click in the disassembly window and un-check “Show Symbol Names” you will see that the symbol this corresponds to ebp-4, which is where the value of ecx was stored at the end of the function prologue.

The astute amongst you will have noticed that the assembler is storing the this pointer from ecx into the Stack only to get it re-load it into ecx later without having used the register in the intervening time. This is exactly the kind of odd thing that un-optimised compiler generated assembler will do, try not to let it bother you :)

So the sum of the two parameters is stored using the this pointer, and then we hit the function epilogue and the function returns; end of story – or is it?

Nothing to see here. Move along.

This is not what you might expect because – based on what we’ve seen so far – that assembler that is setting CSumOf::m_iSumOf in the member function doesn’t obviously match the C++ code we wrote.

What we’re seeing looks like it might have been generated by the code

*((int*) this) = iParamOne + iParamTwo;

And in fact if you substitute that line it will generate exactly the same assembler – so how does that work?!?

// Here's what we wrote. Since m_iSumOf is a class member the language syntax allows use to
// "access it directly" (another Professor Kenobiism) in the member function
m_iSumOf = iParamOne + iParamTwo;

// in fact, what happens is that the compiler evaluates the code as if it was written like this
this->m_iSumOf = iParamOne + iParamTwo;

Ok, so there’s invisible pointer access in the C++ code, but that still doesn’t explain what we’re seeing – exactly how is

*((int*) this)

equivalent to

this->m_iSumOf

The answer has to do with memory layout of C++ classes (and structs), which is a topic for another entire article (probably several).

For now we’ll keep the explanation simple whilst trying not to channel our friend Professor Kenobi more than absolutely necessary…

First let’s take it as read that the member data for an instance of class must be stored somewhere in memory, and take a high level look at how the “pointing to” operator works with another code snippet:

this->m_iSumOf = 0;

This basically tells the compiler generate assembler that:

gets the value of this (a memory address)
looks up the offset of m_iSumOf relative to the start of the data making up an instance of CSumOf (which is known at compile time, so it’s constant at run time)
adds the offset to the address of this to get the memory address storing m_iSumOf and then sets the value at the resulting memory address to 0

The this pointer holds the address of the first byte of the data in an instance of CSumOf.

The first (and only) member variable in CSumOf is m_iSumOf, which puts it at an offset of 0 relative to the this pointer – and clearly even a debug build knows better than to add an offset of 0, so it accesses the memory at the address this.

So, again, we can see that even in seemingly innoccuous everyday C++ code there is hidden stuff going on – which is a big part of why I’m doing this series :)

Incidentally, I have recently been made aware of an unbelievably useful (and undocumented!) feature of the VS2010 compiler which prints the memory layout of classes to the build output during compilation: here’s the link I was sent, I hope you find it useful: http://thetweaker.wordpress.com/2010/11/07/d1reportallclasslayout-dumping-object-memory-layout/

fastcall (last one, I promise)

At last we come to the win32 x86 calling convention excitingly named fastcall, so named because in theory it makes function calls faster (than the more common stdcall or cdecl conventions).

So why is it faster than the other calling conventions that we’ve looked at? To answer this, we’ll need to examine the assembler generated by a function call that uses the fastcall convention.

To demonstrate this we’ll use the code below:

int __fastcall SumOf( int iParamOne, int iParamTwo, int iParamThree )
{
    int iLocal = iParamOne + iParamTwo + iParamThree;
    return iLocal;
}

int main( int argc, char** argv )
{
    int iValOne   = 1;
    int iValTwo   = 2;
    int iValThree = 4;
    int iResult   = SumOf( iValOne, iValTwo, iValThree );
    return 0;
}

This is basically the same as the code used in the previous post in the series to show how the stdcall calling convention stores multiple parameters on the stack, except the function SumOf has got an extra keyword between the return type and the name of the function.

The __fastcall keyword is a not-quite Microsoft specific C++ extension that changes the calling convention used to call the function it is applied to (http://en.wikipedia.org/wiki/X86_calling_conventions#fastcall).

If you follow the usual drill to make a runnable project from this snippet, put a breakpoint on line 12, then compile and run the debug configuration, wait for the breakpoint to get hit, and go to disassembly you should see something like this:

     8: int main( int argc, char** argv )
     9: {
010F1280  push        ebp
010F1281  mov         ebp,esp
010F1283  sub         esp,50h
010F1286  push        ebx
010F1287  push        esi
010F1288  push        edi
    10:     int iValOne   = 1;
010F1289  mov         dword ptr [iValOne],1
    11:     int iValTwo   = 2;
010F1290  mov         dword ptr [iValTwo],2
    12:     int iValThree = 4;
010F1297  mov         dword ptr [iValThree],4
    13:     int iResult   = SumOf( iValOne, iValTwo, iValThree );
010F129E  mov         eax,dword ptr [iValThree]
010F12A1  push        eax
010F12A2  mov         edx,dword ptr [iValTwo]
010F12A5  mov         ecx,dword ptr [iValOne]
010F12A8  call        SumOf (10F1136h)
010F12AD  mov         dword ptr [iResult],eax
    14:     return 0;
010F12B0  xor         eax,eax
    15: }

You should by this point be pretty familiar with function prologues, and the assembler that precedes a function call in the other conventions we’ve examined, so we’ll just look at the differences with __fastcall.

Looking at lines 16 to 20, we can see that of the three parameters passed to SumOf():

the 3rd (iValThree) is being pushed onto the stack,
the 2nd (iValTwo) is being moved into the edx register, and
the 1st (iValOne) is being moved into the ecx register

Stepping into the disassembly of SumOf() you should see something like this (N.B. I unchecked “Show Symbol Names” before grabbing this text from the disassembly view so the addresses were all visible):

     2: int __fastcall SumOf( int iParamOne, int iParamTwo, int iParamThree )
     3: {
010F1250  push        ebp
010F1251  mov         ebp,esp
010F1253  sub         esp,4Ch
010F1256  push        ebx
010F1257  push        esi
010F1258  push        edi
010F1259  mov         dword ptr [ebp-8],edx
010F125C  mov         dword ptr [ebp-4],ecx
     4:     int iLocal = iParamOne + iParamTwo + iParamThree;
010F125F  mov         eax,dword ptr [ebp-4]
010F1262  add         eax,dword ptr [ebp-8]
010F1265  add         eax,dword ptr [ebp+8]
010F1268  mov         dword ptr [ebp-0Ch],eax
     5:     return iLocal;
010F126B  mov         eax,dword ptr [ebp-0Ch]
     6: }

The assembly making up the function prologue is doing extra work compared to a stdcall function; taking the values of ecx and edx and storing them into the function’s Stack frame (lines 9 & 10).

Lines 12 to 14 then add the three values passed to it using eax – iParamOne (passed via ecx now in [ebp-4]), iParamTwo (passed via edx now in [ebp-8]), and iParamThree (passed via the Stack in [ebp+8]).

Line 15 sets iLocal from the sum calculated in eax, and then Line 16 moves the return value of the function into eax where the calling code will expect to find it (as previous established in this post).

That’s all well and good, but how is fastcall faster than the alternative calling conventions?

In theory, passing the arguments via registers should save two operations per parameter:

not writing the value into the Stack (i.e. memory access) before the function is called, and
not reading it from the Stack (i.e. memory access) when it is needed inside the function.

As a rule of thumb, performing less operations and avoiding those that involve accessing memory should result in faster code, but this is not always the case. I don’t want to get into discussing why this is, because on its own it is a subject for many posts and by someone more qualified than myself to explain (e.g. Bruce Dawson, Mike Acton, Tony Albrecht, Jaymin Kessler, or John McCutchan).

In all honesty I would be extremely surprised if the unoptimised code we’ve looked at runs any faster at all when using fastcall. As you can see by examining the disassembly above, the first of these potentially saved operations is being un-done by pushing the content of ecx and edx onto the Stack in the function prologue, and the second is being un-done by accessing the parameter values from the Stack in lines 12 & 13.

I assume that, like the other instances of unoptimised compiler generated assembler performing redundant operations we have come across, these unnecessary instructions would happily optimise away in a release build; however the sad fact is that it is pretty hard to test the disassembly of trivial programs like the one we’ve been looking at meaningfully in a release build configuration.

Why? because the optimising compiler is so good that any simple program (like this one) which uses compile time constants for input, and does no output will pretty much compile to “return 0;”

I leave it as an exercise for you, dear reader, to work out the smallest number of changes to this code that will result in disassembly that actually calls SumOf() :)

Summary

So, we have now seen how thiscall and fastcall differ from the other x86 calling conventions we’ve looked at, and we have seen yet again that even in simple code there is black magic going on behond the scenes of the language syntax.

Also, I want to point out that – whilst non x86 platforms will be do things slightly differently – this information is more generally useful than it may appear; the more different ways you’ve seen assembler doing similar tasks (like calling functions using the Stack), the more likely you are to be able to make sense of some new assembly language that you’ve never seen before (e.g. powerPC assembler) sure the mnemonics may be very different but you should be able to guess at a lot of them and the documentation is out there to allow you to put the rest of the picture together given time.

No doubt we will revisit the Stack from time to time as this (Potentially neverending! Help!) series of articles continues, but I’ve now covered it in as much detail as I feel is appropriate until we’ve covered some other aspects of the Low Level view of C/C++ (for example; we will definitely be coming back to the Stack when we examine structs & classes and their memory layout to discuss pass by value).

Next time we’ll be looking at the disassembly from common C / C++ language constructs like loops and control statements, which are very useful things to be familiar with know if you find yourself staring at bunch of disassembly as a result of a crash in code you don’t have symbols for..

In case you missed it whilst reading the main body of the post, here’s that link again concerning the undocumented VS2010 compiler feature that dumps memory layouts of classes to the build output: http://thetweaker.wordpress.com/2010/11/07/d1reportallclasslayout-dumping-object-memory-layout/

Also, thanks to Fabian and Bruce for their help reviewing this post.

C / C++ Low Level Curriculum Part 4: More Stack

Alex Darby — Sat, 24 Dec 2011 16:41:40 +0000

Welcome to the 4th part of my C/C++ Low Level Curriculum – more Stack!

The last post was a mammoth and took me ages so this post is going to be significantly shorter, and will consequently cover less ground. Specifically we’re going to look at how more than one parameter is passed in compiler generated unoptimised x86 assembler using the stdcall calling convention.

This post assumes that you have read the previous post on the Stack (or know how the Stack works in “vanilla” x86 assembler already).

If you missed the previous posts here are backlinks:

I’ve also dropped in a good link to some IBM resources on the PowerPC ABI which explain in detail (and at the assembler level) how the Stack is used on PowerPC based CPUs as it is actually more different from x86 than I remembered. You may find this particularly useful if you work on Current Gen consoles and want to understand how they use the Stack, call functions, and pass parameters.

More than one function parameter

As before, I’m using a win32 console application made by the “new project” wizard in VS2010 with the default options. The disassembly we’ll be looking at is from the debug build configuration, which generates vanilla unoptimised stdcall x86 code.

The only change I make is to turn off “Basic Runtime Checks” to make the generated assembler more legible (and significantly faster…) see the previous post for details on how to do this.

We’re going to update the very simple program used for the last article so that the function it calls requires 3 parameters.

int SumOf( int iParamOne, int iParamTwo, int iParamThree )
{
    int iLocal = iParamOne + iParamTwo + iParamThree;
    return iLocal;
}

int main( int argc, char** argv )
{
    int iValOne   = 1;
    int iValTwo   = 2;
    int iValThree = 4;
    int iResult   = SumOf( iValOne, iValTwo, iValThree );
    return 0;
}

and here’s the assembler it generates for main() (as before the addresses of the instructions will almost certainly differ for you):

     7: int main( int argc, char** argv )
     8: {
00401280  push        ebp
00401281  mov         ebp,esp
00401283  sub         esp,50h
00401286  push        ebx
00401287  push        esi
00401288  push        edi
     9:     int iValOne        = 1;
00401289  mov         dword ptr [ebp-4],1
    10:     int iValTwo        = 2;
00401290  mov         dword ptr [ebp-8],2
    11:     int iValThree    = 4;
00401297  mov         dword ptr [ebp-0Ch],4
    12:     int iResult        = SumOf( iValOne, iValTwo, iValThree );
0040129E  mov         eax,dword ptr [ebp-0Ch]
004012A1  push        eax
004012A2  mov         ecx,dword ptr [ebp-8]
004012A5  push        ecx
004012A6  mov         edx,dword ptr [ebp-4]
004012A9  push        edx
004012AA  call        00401127
004012AF  add         esp,0Ch
004012B2  mov         dword ptr [ebp-10h],eax
    13:     return 0;
004012B5  xor         eax,eax
    14: }
004012B7  pop         edi
004012B8  pop         esi
004012B9  pop         ebx
004012BA  mov         esp,ebp
004012BC  pop         ebp
004012BD  ret

Calling SumOf()

As we saw in the last article, we know we can safely ignore the function preamble and postamble (lines 3-8, and lines 28-33; also known as the prologue and epilogue respectively) which set up and tear down the function’s Stack Frame as we know they’re not involved in passing the parameters to SumOf().

A quick look at the disassembly initialising the local variables tells us that iValOne, iValTwo, and iValThree are stored at [ebp-4], [ebp-8], and [ebp-0Ch] respectively.

The disassembly relevant to the function call and the assignment of its return value is this part:

    12:     int iResult        = SumOf( iValOne, iValTwo, iValThree );
0040129E  mov         eax,dword ptr [ebp-0Ch]
004012A1  push        eax
004012A2  mov         ecx,dword ptr [ebp-8]
004012A5  push        ecx
004012A6  mov         edx,dword ptr [ebp-4]
004012A9  push        edx
004012AA  call        00401127
004012AF  add         esp,0Ch
004012B2  mov         dword ptr [ebp-10h],eax

As in the case with a single argument, copies of the function parameters’ values are pushed onto the Stack – but note that they are pushed on in the opposite order to the order in which the function’s parameter list expects them in the C++ code.

The final thing to note, is that following the call instruction on line 22 (i.e. immediately before the assembler for SumOf() is executed) the copy of iValOne that was pushed onto the stack in line 21 is at [esp+4] because call pushes the return address onto the Stack.

Just in case, here’s what the stack looks like immediately after line 22 is executed, but before any code in SumOf() is executed:

Stack after line 22, before any of SumOf() is executed

Accessing the parameters

Here’s the disassembly for SumOf():

     1: int SumOf( int iParamOne, int iParamTwo, int iParamThree )
     2: {
00401250  push        ebp
00401251  mov         ebp,esp
00401253  sub         esp,44h
00401256  push        ebx
00401257  push        esi
00401258  push        edi
     3:     int iLocal = iParamOne + iParamTwo + iParamThree;
00401259  mov         eax,dword ptr [ebp+8]
0040125C  add         eax,dword ptr [ebp+0Ch]
0040125F  add         eax,dword ptr [ebp+10h]
00401262  mov         dword ptr [ebp-4],eax
     4:     return iLocal;
00401265  mov         eax,dword ptr [ebp-4]
     5: }
00401268  pop         edi
00401269  pop         esi
0040126A  pop         ebx
0040126B  mov         esp,ebp
0040126D  pop         ebp
0040126E  ret

We can see that the function prologue code pushes ebp which moves esp on another 4 bytes, then moves esp to ebp – so after line 4 the copy of iValOne’s value is now at [ebp+8].

Here’s another Stack snapshot showing the state after the function prologue (i.e. after line 8):

state of the Stack after the prologue of SumOf()

Looking at lines 10-12 we can see that the assembler is accessing the function parameters as follows:

iParamOne (iValOne) from [ebp+8]
iParamTwo (iValTwo) from [ebp+0Ch]
iParamThree (iValThree) from [ebp+10h]

Which, unsurprisingly, is exactly where the values main() pushed onto the Stack before calling this function ended up after the function prologue.

Now we can see why the function parameters are pushed onto the stack in reverse order by main() – because functions called expect them to be stored in the Stack in parameter list order starting from [ebp+8] and incrementing in offset from ebp for each parameter.

As before the return value (iLocal, stored at [ebp-4]) is moved into eax before the function’s epilogue code in order to return it to main(), and since we know how the epilogue and return work from the last article we’re done with vanilla stdcall with multiple parameters. Joy.

Summary

We’ve looked in some detail at how the Stack is used to call functions in vanilla unoptimised compiler generated stdcall x86 assembler, this should leave you in a pretty good place to go mooching about in disassembly windows with a fair idea of which parts of the disassembly for each function is most likely to be relevant.

For extra information, and to show you how different the Stack use can be (whilst still being basically the same in principle), here’s a link to the 4th in a series of articles on the IBM Technical Library site dealing with PowerPC assembler, and in particular with the 64 bit PowerPC ABI:

http://www.ibm.com/developerworks/linux/library/l-powasm4/index.html

In all likelihood you’ll need to read the first three articles to make sense of the 4th, but the 4th one is where most of the juicy info is :)

Next Time

Next time, I’m going to look at the x86 thiscall calling convention used when C++ member functions (where the ‘this’ pointer is passed in ecx), and we’ll also have a look in overview at how the exciting sounding ‘fastcall’ x86 calling convention uses the Stack.

Oh, and Merry Christmas!

C / C++ Low Level Curriculum Part 3: The Stack

Alex Darby — Wed, 14 Dec 2011 23:10:21 +0000

Welcome to the 3rd part of the series I’m doing on a Low Level Curriculum for C/C++.

This one is about the Stack, which is arguably the most important component of the underlying “engine” of C/C++. If you only ever bother to learn about one aspect of the low level behaviour of C/C++, then my advice is to make that one thing be the Stack.

You probably won’t need to have read the first two parts of this series to follow this article, but I will assume that you have – and I definitely assume that you do not fear the disassemby window.

In case you want to go back and read them here are links to the first two articles:

http://altdevblogaday.com/2011/11/09/a-low-level-curriculum-for-c-and-c/
http://altdevblogaday.com/2011/11/24/c-c-low-level-curriculum-part-2-data-types/

Prologue

If you are a C++ programmer and you’re not 100% sure what the Stack is or how it works, then you are not alone.

The Bjible

Bjarne Stroustrup’s book “The C++ Programming Language (3rd edition)” – which is pretty much the standard text on C++ (at least until the update for the C++11 standard is published…) – does not discuss what the stack is or how it works; although it does refers to data or objects being “on the stack” as if the reader knows what this means.

The closest you get to concrete information about the Stack in the Bjible is the following paragraph in a section in Appendix C entitled “C.9 Memory Management”…

“Automatic memory, in which function arguments and local variables are allocated. Each entry into a function or a block gets its own copy. This kind of memory is automatically created and destroyed; hence the name automatic memory. Automatic memory is also said ‘‘to be on the stack.’’ If you absolutely must be explicit about this, C++ provides the redundant keyword auto .”

Don’t get me wrong, this is still a very very good book (and one I refer to fairly often), but the fact that the standard text on C++ all but ignores something as core to the internal operation of C++ as the Stack is telling indeed. In my experience, this is symptomatic of the disconnect between programming language and underlying implementation that exists in the academic mindset.

On my Computer Science degree the concept of the Stack was covered in a couple of slides during a compulsory 1st year module called “Computer Systems and Architecture”, but never specifically with relation to the programming languages we were learning – and this, dear reader, is why I feel compelled to write about it…

What is the Stack?

Unsurprisingly, the Stack is a stack data structure. For the sake of clarity I’m going to capitalise the Stack to discriminate it from just any old instance of a stack data structure.

In a single threaded program the Stack contains the vast majority of the data relating to the current execution state of the program and all non-global “automatic” memory under the control of the compiler – i.e. local variables, function parameters etc.

When you put a breakpoint in your code in your IDE of choice and use the Call Stack window to discover the stack of function calls that got you to your breakpoint, the data used to populate that window was almost certainly derived by the debugger from examining the state of the Stack.

The detailed specifics of the way the Stack functions varies from CPU to CPU, machine to machine, compiler to compiler, and even with the same compiler and different compiler options (more about that in the next post!).

Broadly speaking, each time a new function is called:

the current CPU execution state (i.e. the instantaneous values of CPU registers) is backed up into the Stack so it can be reinstated later,

some or all of the parameters expected by the function being called are put into the Stack (many implementations use registers for parameter passing when possible), and

the CPU jumps to a new location in memory to execute the code of the called function.

In the generalised case then, the Stack includes the following information:

all of the local variables and function parameters of the functions below the top of the call stack,

copies of the contents of all the CPU registers that were in use in each function below the top of the call stack when the call to the function above it was made,

the memory address of the next instruction to execute in each of the functions below the top of the call stack when the function above them returns (the “return address”).

The area of Stack that contains the local variables belonging to a function (and any other data it might happen to put there) is said to be that function’s Stack Frame. This is an important term, don’t forget it!

Clearly the operation of the Stack is massively important to the execution of your code, and hopefully it is now obvious why something as easily done as writing outside of the bounds of an array declared as a local inside a function can cause such an epic fail – the out of bounds write is very likely to overwrite a function’s return addess or some other value crucial to the correct running of the program once the current function returns.

How does the Stack work in practice?

To help answer these questions let’s consider a (very simple) C/C++ program:

int AddOneTo( int iParameter )
{
    int iLocal = iParameter + 1;
    return iLocal;
}
 
int main( int argc, char** argv )
{
    int iResult = 0;
    iResult = AddOneTo( iResult );
    return 0;
}

I will be stepping through this program as a win32 console application built using VS2010 in a debug configuration with more or less the default compiler and linker settings, and the screenshots in this article will reflect this.

I would definitely advise doing this yourself by hand after reading this article because it’s always much more instructional to muddle through something like this yourself than it is to just read it…

As I mentioned earlier, the detailed specifics of the operation of the Stack – especially with regards to passing parameters to functions – will depend on the compiler options you use. The differences are mostly down to a set of code generation standards that are called “calling conventions”, each convention has its own rules about how parameters are passed to functions and how values are returned. Some tend to be faster, some tend to be slower, but most are designed to meet specific requirements for passing data – such as C++ member function calls, or variable numbers of parameters (e.g. printf() ).

The default calling convention used by VS2010 with C-style functions (i.e. no ‘this’ pointer) is known as stdcall, and since we’re looking at a debug build the disassembly we’re looking at will be using entirely un-optimised stdcall. This calling convention puts everything on the Stack other than return values from functions which are returned via the eax register.

If you are runningthis code on non wintel hardware, then the operation and organisation of the Stack in the code generated by your compiler, and the way parameters are passed will almost certainly be subtly – or even markedly – different from what I’m showing you in my debugger here, but the fundamental mechanisms by which it works should be basically the same.

Setting up

To start with, make an empty win32 console project, create a new .cpp file in it (I’d call it main.cpp if I were you), and then paste the above code into it.

Next, open up the project settings and make sure you have the “run time checks” option set to “default”. This not only makes the debug code (a lot) faster, but also simplifies the assembler it generates substantially – especially in the case of our very simple program. The image below shows you what the options dialog should look like after you make the change.

important areas higlighted in red for good measure!

Put a breakpoint on line 7 (yes, I know this line is the definition of main()) and then compile and run a debug build. When the Breakpoint gets hit, right click the source window and choose “Go To Disassembly”.

You should now be seeing something like this (n.b. the addresess of the instructions down the left edge of the window will almost certainly be different in your disassembly window):

n.b. make sure you have the same display options checked in the right-click menu

DON’T PANIC

Clearly this is significantly more daunting than the disassembly we have looked at before so, before going any further, let’s cover a little background on the way that the Stack is managed in compiler generated 32bit x86 assembler (at least by the VS2010 C++ compiler with the default compiler and linker settings).

Before we begin…

The first piece of information that will start to make sense of this is that two key CPU registers are usually involved in the management of Stack Frames in 32bit x86 assembler:

esp – or the Stack Pointer register which always points to the “top” of the Stack, and

ebp – or the Base Pointer register which points to the start (or base) of the current Stack Frame.

Local variables are typically represented as offsets from the ebp register, in this case iResult is stored at the address [ebp-4].

If you want to see the local variable names rather than offsets from ebp you can right-click and check the “Show Symbol Names” option, but knowing that offsets from ebp are negative is useful.

Why are the offsets from ebp of local variables negative? This is because the x86 Stack grows downwards in memory – i.e. the “top” of the stack is stored in a lower memory address than the “bottom”. Consequently, the address stored in ebp is higher than the address in esp, and so local variables within the stack frame have negative offsets from ebp (and would have a positive offset from esp).

I’m pretty sure that every machine I’ve worked with has had a stack that grows down rather than up in address space, but as far as I know there’s no Universal Law of Computers that says that the Stack must do this – I’m sure there must be machines that have stacks which grow the opposite way.

Whilst this sounds counter-intuitive, having a stack that grows downward in memory address makes sense when considered in terms of the traditional overall memory layout of C / C++ programs, which we’ll cover in a later article in the series dealing with memory.

Push and Pop

As I’m sure you all already know, the two key operations of the abstract data structure known as a stack are to push something onto the top of it (covering the previous top), or to pop whatever is on the top off it (exposing the previous top).

Unsurprisingly the x86 instruction set has a push and a pop instruction, each of which take a register operand:

push decrements esp by the size of its operand and then stores that operand into the address pointed to byesp (i.e. on the top of the Stack).

This means that after a push instruction, the value at the address esp points to whatever was pushed onto the Stack.

pop copies the value from the address contained in esp into its operand and then increments esp by the size of its operand so that its operand is essentially removed from the Stack.

These behaviours are key to the way in which the Stack operates.

How the Stack looks before our code executes

As I’m sure most of you know there is code that runs before main(). This code is responsible for all sorts of system initialisation, and when it’s finished it calls main() passing the command line arguments as parameters.

Let’s look at the layout of the Stack at the point just before the first instruction in main() is executed – in the diagram below I have called the function that calls main() “pre-main()” – you will probably find that the name of the actual function in your program’s call stack is a scary looking combination of underscores and capitalised acronyms.

This diagram will make more sense when you come back to look at it after reading the rest of the article.

the state of the Stack before our code executes

The Function Preamble (or Function Prologue)

Before the disassembly even gets as far as assigning 0 to iResult we have a fair amount of assembler for what looks like nothing at the C/C++ level; so let’s make sense of it.

     7: int main( int argc, char** argv )
     8: {
01311280  push        ebp
01311281  mov         ebp,esp
01311283  sub         esp,44h
01311286  push        ebx
01311287  push        esi
01311288  push        edi

A block of assembler very similar to this will be at the start of every compiler generated function, and is usually referred to as the function’s “preamble” or “prologue”.

The purpose of this code is to create the stack frame for the function, and to store the content of any registers the function is going to use so that those values can be reinstated before the function returns:

[n.b. line numbers used in points below refer to the numbers in the code box above]

line 3: is storing the current value of ebp on the Stack using the instruction push.

line4: is moving the current value of esp to ebp. ebp now points straight to the old value of ebp that was just pushed onto the stack.

line 5: is subtracting 44h (68 in decimal) in place from the value esp. This has the effect of allocating 68bytes on the Stack after ebp.

line 6, 7, and 8: are storing the values contained in the ebx, esi, and edi registers respectively by pushing them onto the stack. This is because the assembler in main() makes use of these registers and needs to be able to restore them to their old states before it returns. Note that each push instruction will decrease the value of esp by 4 bytes.

N.B. If you’re following this in the debugger, then I would advise that you open a “Registers” window in your debugger to watch the values of the registers change as you single step through the disassembly. You would probably also do well to have memory windows open so you can point them at esp and ebp to watch the values change in memory (to get a memory window in VS2010 to track a register you will need to click the “Reevaluate Automatically” button to the right of the “Address:” edit box and then type the register’s name into the edit box).

At this point, the Stack looks like this:

state of the Stack after preamble of main()

A couple of things to note about these Stack snapshot diagrams:

The value T in the top left of these snapshots is used to identify old values of ebp stored in the Stack.

Different colours are used to show which function is responsible for putting the data onto the Stack (and therefore for taking it off…).

Different shades of the same colour represent different logical types of data put onto the stack by each function (i.e. base pointer, stack frame (locals), values of saved registers, and parameters /return addresses).

The function Postamble (or Epilogue)

Once the body of the function has finished executing, the Stack and registers need to be put back in the same state they were in before the function preamble so that the calling function can happily carry on excuting where it left off.

This is the job of the function postamble, or epilogue. The postamble simply does the logical opposite of the preamble – it pops whatever the preamble pushed, and reinstates the values that esp and ebp had before the preamble code executed.

In the code box below I’ve deleted the body of the function so that the preamble and postamble code are ajdacent. Looking at it like this it’s very clear that the postamble is doing the opposite of the preamble.

     7: int main( int argc, char** argv )
     8: {
01311280  push        ebp
01311281  mov         ebp,esp
01311283  sub         esp,44h
01311286  push        ebx
01311287  push        esi
01311288  push        edi
... code representing the body of main() removed ...
    12: }
013112A1  pop         edi
013112A2  pop         esi
013112A3  pop         ebx
013112A4  mov         esp,ebp
013112A6  pop         ebp
013112A7  ret

The only line in the preamble that doesn’t have a direct opposite in the postamble is line 5 (sub esp, 44h) – and that’s because assigning to esp from ebp in line 14 undoes lines 4 and 5.

Since all functions have a preamble and postamble, covering these two sections of the disassembly up front means we can essentially ignore the preamble and postamble from now on, and focus on the code that is different in each function.

And now: actual code we wrote!

Now we’ve covered the preamble and postamble we can concentrate on the body of main(), and how it calls the function AddOneTo().

This is the first bit of disassembly that directly correlates with the code that we can see at the C/C++ level.

     9:     int iResult = 0;
01311289  mov         dword ptr [ebp-4],0  
    10:     iResult = AddOneTo( iResult );
01311290  mov         eax,dword ptr [ebp-4]  
01311293  push        eax  
01311294  call        0131101E  
01311299  add         esp,4  
0131129C  mov         dword ptr [ebp-4],eax

So, as we should all be familiar with from getting over our fear of disassembly line 2 in the above code is setting iResult, which we can see is within our current stack frame at adress [ebp-4] in the Stack.

The rest of the instructions are setting up to call the function AddOneTo(), calling it, and assigning to iResult from its return value.

line 4: is moving the value of iResult into the eax register.

line 5: is pushing the value of iResult from eax onto the top of the stack (which also decrements esp). This is storing a copy of the value of iResult on the stack as the function parameter to AddOneTo().

line 6: is calling to address 0131101Eh. This instruction causes the function AddOneTo() to be called. It first pushes the address 01311299h onto the Stack (which is the memory address of the instruction at line 7), and then it jumps program execution to the instruction at 0131101Eh.

line 7: When the function called by line 6 returns, the function parameter pushed onto the Stack in line 5 must be removed so the Stack state is as it was before AddOneTo() was called. To achieve this we add 4 to esp – this has the same effect on esp as pop, but we don’t care about the value so it makes sense to adjust esp directly. I assume this is also more efficient, but I’ve never looked into it.

line 8: moves the value in eax into [ebp-4] where we know that iResult is stored. The standard “stdcall” convention for win32 x86 code specifies that eax is used to return values from functions so this line is assigning the return value of AddOneTo() to iResult.

Calling AddOneTo()

Let’s just review the instructions involved in calling AddOneTo() in detail:

     9:     int iResult = 0;
01311289  mov         dword ptr [ebp-4],0  
    10:     iResult = AddOneTo( iResult );
01311290  mov         eax,dword ptr [ebp-4]  
01311293  push        eax  
01311294  call        0131101E

A copy of iResult’s value is pushed onto the stack (via eax) as the parameter for AddOneTo().
push moves esp by 4 bytes (i.e. 32 bits) then stores its operand at that address, after the push instruction the value of iResult is stored in the address [esp].
call pushes the address of the next instruction to execute after the function returns (the return address – 01311299h) onto the Stack, and then jumps execution to the address 0131101Eh.
The copy of iResult’s value is now at [esp+4], and the return address is at [esp].

At this point, the Stack looks like this:

state of the Stack immediately after the call to AddOneTo() is made from main()

The code at the address 0131101Eh that has been called looks like this:

1 2	AddOneTo: 0131101E jmp 01311250

I have to confess this is confusing. This instruction simply makes the code execution jump again, this time to the disassembly that represents the actual function body of AddOneTo(), which is at 01311250h. Why call to an instruction that does another jump?

If you step through this yourself, you’ll notice that the disassembly around this function appears to be a collection of goto style labels. This is because they are. You’ll also notice that the instructions associated with each label are jumping elsewhere. Clearly we’re looking at some sort of “jump table”.

The reason for this? Since I used the default debug configuration build settings; the option “Enable Incremental Linking” is set to “Yes”.

Incremental linking makes linking faster (apparently), but clearly introduces a small overhead to all function calls. This is the sort of thing you might possibly want to consider turning off in the build options – but you’d want to profile it to to make an informed decision as to its impact either way before doing so.

The jmp instruction doesn’t disturb the Stack, so no harm done really (other than the likely instruction cache miss introduced by the incremental link’s jump table).

Getting at the parameter passed to AddOneTo()

So, at last, we come to the disassembly of the body of AddOneTo():

     1: int AddOneTo( int iParameter )
     2: {
01311250  push        ebp  
01311251  mov         ebp,esp  
01311253  sub         esp,44h  
01311256  push        ebx  
01311257  push        esi  
01311258  push        edi  
     3:     int iLocal = iParameter + 1;
01311259  mov         eax,dword ptr [ebp+8]  
0131125C  add         eax,1  
0131125F  mov         dword ptr [ebp-4],eax  
     4:     return iLocal;
01311262  mov         eax,dword ptr [ebp-4]  
     5: }
01311265  pop         edi  
01311266  pop         esi  
01311267  pop         ebx  
01311268  mov         esp,ebp  
0131126A  pop         ebp  
0131126B  ret

We’re already familar with the preamble (lines 3 to 8) and postamble (lines 16 to 20) which are identical to that of main().

Line 10 is much more interesting, as it gets the function parameter iParameter off the stack. Note the positive offset from ebp – this means that the address it is moving a value from into eax is outside this function’s stack frame.

As we established earlier, when we jumped to the address of this function, the address esp pointed to contained the return address, and a copy of the local variable iResult (i.e was stored at [esp+4].

The first instruction in the preamble is a push, which changes esp by a further 4 bytes; so immediately after line 3 the value of iResult – or iParameter as it is refered to in this function – is now at [esp+8].

The next instruction moves the value of esp into ebp, so the value of iReturn passed as a parameter to this function is now also at [ebp+8] – which is exactly where line 10 is accessing it from.

So now we know how arguments are passed to functions. Win!

Since this is the most data that this program ever puts on the Stack, we should take a look at a snapshot of the Stack so we can see exactly where everything is:

state of the Stack immediately after AddOneTo() preamble

Returning the result of AddOneTo()

Ignoring the function preamble, we are left with:

     3:     int iLocal = iParameter + 1;
01311259  mov         eax,dword ptr [ebp+8]  
0131125C  add         eax,1  
0131125F  mov         dword ptr [ebp-4],eax  
     4:     return iLocal;
01311262  mov         eax,dword ptr [ebp-4]  
     5: }
01311265  pop         edi  
01311266  pop         esi  
01311267  pop         ebx  
01311268  mov         esp,ebp  
0131126A  pop         ebp  
0131126B  ret

Line 2 moves the value of iParameter from the Stack into eax.

Lines 3 & 4 are adding one to the parameter value in eax and then moving the content of eax into the address at [ebp-4] which is the address of the local variable iLocal.

Line 6 sets up the function’s return value by moving the value of iLocal into eax – which is where the stdcall calling convention specifies that return values go. If you remember, the code in main that accesses the return value expects it in eax.

If you’re paying attention you should have noticed that lines 4 and 6 are essentially redundant, since the return value was already in eax after line 3.

You will see this sort of thing all the time when looking at completely unoptimised disassembly - but it’s not a bad thing after all, when not asked to optimise the compiler’s task is to do exactly what your code has asked it to.

So the final piece of the puzzle in all this is actually returning from one function to another.

We know that the postamble puts the Stack back into the same state it was in immediately before the function’s preamble executed, well we already know what that looks like – because we have a digram of it at T=2:

state of the Stack immediately after the call to AddOneTo() is made from main()

The final ret on line 13 in the code box above causes the return address currently stored on the top of Stack by the call instruction in main() to be popped (adding 4 to esp) and resumes execution at that address – i.e. at the instruction immediately after the call in main().

Phew. There you have it. See, it wasn’t that bad was it?

Summary

In this article I’ve taken you through the disassembly of a simple program with a single function call with one parameter and a return value to demonstrate how the stack works.

The sample disassembly we looked at used the x86 stdcall calling convention, and whilst specifics of the disassembly generated to manage the stack will vary between calling conventions, the way the Stack works on any other machine or with any other calling convention should be very similar in principle.

If, for totally random example, you’re working with a platform that uses some variant of the IBM power PC CPU just fire up one of the simple SDK demos and step through the disassembly in a debug build. Whilst the disassembler mnenmonics will be (very) different, just spend a little while with a hardware manual and you should find that it’s doing pretty much the same thing as this x86 code we’ve just looked at.

You’re likely to find some significant variation relative to the x86 assembler we looked since the platform you’re working with almost certianly uses a different function calling convention – for example your compiler might mostly pass arguments via registers and only use the Stack when a function requires a large number of parameters, or uses var args (e.g. printf() ).

Either way, a quick flick through the hardware manuals and / or a search or two through the hardware / compiler manufacturer’s forums and newsgroups should tell get you the details of the calling convention you’re dealing with and enable you to get your head around it.

On top of this, the understanding you now have of the Stack’s mechanisms and data layouts should enable you to properly appreciate why out of bounds array access with local arrays can be so dangerous, and precisely why you should think very carefully before passing pointers to local variables…

Next Time…

Believe it or not, we’re not finished with the Stack – we have plenty more to cover about it!

For example:

What happens when passing > 1 parameter?
More detail on how local variables use Stack memory.
How pass by value and return by value work.
How some of the different x86 function calling conventions work – particularly __fastcall which is more similar to the calling conventions typically used by the ABIs (Application Binary Interface) for console platforms.

Given how long this article has become (and the time it took to write…), I will probably split these into more than one post.

Epilogue…

Assuming that you’ve run this code yourself in VS2010 then, if you have some spare time and fancy a bit of a shock, you may want to run this code in a release build configuration with the same breakpoint and look at the disassembly window when the breakpoint is hit.

I found the optimised code generated pretty interesting.

You may also find it fun to see what changes you need to make to the code to force the optimised code to keep the function call and local variables. I certainly did.

Thanks

I’d like to thank Bruce, Tiffany, Jonathan, Fabian, and Darren for their feedback on this article. It is definitely much better for it.

C / C++ Low Level Curriculum part 2: Data Types

Alex Darby — Thu, 24 Nov 2011 12:00:30 +0000

Prologue

Hello and welcome to the 2nd part of the C / C++ low level curriculum series of posts that I’m currently doing.

Here’s a link to the first one if you missed it: http://altdevblogaday.com/2011/11/09/a-low-level-curriculum-for-c-and-c/

This post is going to be a little lighter than most of the other posts in the series, primarily because this post is vying for my spare time with my urge to save a blonde girl with pointy ears from the skinny androgynous Demon Lord of extended monologue in a virtual universe powered by three equilateral triangles.

Before we continue, I’d like to quickly bring to public note a book that has now been recommended to me many times as a result of the first post: http://www1.idc.ac.il/tecs

I can’t personally vouch for it, but I fully intend to buy it and grok its face off as soon as I get some spare time in my schedule. This book looks awesome, and if it is half as good as it looks to be then reading it should be an extremely worthwhile investment of your time…

Assumptions

The next thing on my agenda is to discuss assumptions.

Assumptions are dangerous. Even by writing this I am making many assumptions – that you have a computer, that you can read and understand The Queen’s English, and that on some level you care about understanding the low-level of C++ to name but a few.

Consequently, dear reader, I feel that it’s worth mentioning what I assume about you before I go any further.

The important thing, I guess, that I should mention is that I assume that you are already familiar with and comfortable using C and/or C++. If you’re not, then I’d advise you to go and get comfortable before you read any more of this :)

Data Types?

So, again, I find myself almost instantly qualifying the title of the post and explaining what I mean when I say data types.

What I am talking about is the “Fundamental” types of C++ and what you should know about how they relate to the machine level – even this seemingly straightforward aspect of C++ is not necessarily what you would expect; especially when dealing with multiple target platforms.

Whilst this isn’t the kind of information that will suddenly improve your code by an order of magnitude, it is (in my opinion) one of the key building blocks of understanding C / C++ at the low level; as it has tonnes of potential knock on effects in terms of speed of execution, memory layout of complex types etc.

Certainly, no-one ever sat me down and explained this to me, I just sort of absorbed it or looked it up over the years.

Fundamental and Intrinsic Types

The fundamental types of C/C++ are all the types that have a language keyword.

These are not to be confused with the intrinsic types which are the types that are natively handled by some given CPU (i.e. the data types that the machine instructions of that CPU operate on).

Whenever you use new hardware you should check how the compiler for your platform is representing your fundamental types. The best way to do this is (can you guess?) to look at the disassembly window.

These days all fundamental types of C++ can be represented by an intrinsic type on most platforms; but you definitely shouldn’t take this for granted, it has only really been the case since the current console hardware generation.

There are 3 categories of fundamental type: integer, floating, and void.

As we all know, the void type cannot be used to store values. It is used to specify “no type”.

For both integral and floating point types there is a progression of types that can hold larger values and/or have more numerical precision.

For integers this progression is (from least to most precision) char, short, int, long, long long; and for floats: float, double, long double.

Clearly, the numerical value limits that a given type must be able to store mandate a certain minimum data size for that type (i.e. number of bits needed to store the prescribed values when stored in binary).

Sizes of Fundamental types

As far as I have been able to discover, the C and C++ standards make no explicit guarantee about the specific size of any of the Fundamental types

There are, however, several key rules about the sizes of the various types which I have paraphrased below:

A char must be a minimum of 8 bits.
sizeof( char ) == 1.
If a pointer of type char* points at the very first address of a contiguous block of memory, then every single address in that block of memory must be traversable by simply incrementing that pointer.
The C standard specifies a value that each of the integer types must be able to represent (see page 33 in this .pdf of the C standard if you want the values - see the header of a standard conformant C++ implementation for details of the values used by your compiler).
The C++ standard says nothing about size, only that “There are five standard signed integer types : “signed char”, “short int”, “int”, “long int”, and “long long int”. In this list, each type provides at least as much storage as those preceding it in the list.” (see page 75 in this .pdf of the latest C++ standard I could find).
4 & 5 have similar rules in the C and C++ standard for the progression of floats.

Helpfully, MSDN has a useful summary of this information (though it’s partly MSVC specific, it’s a good starting point).

Despite all this leeway in the standard, the size of the fundamental types across PC and current gen console platforms is (to the best of my knowledge) relatively consistent.

The C++ standard also defines bool as an integral type. It has two values, true and false, which can be implicitly converted to and from the integer values 1 and 0 respectively; and is the return type of all the logical operators (==, !=, >, < etc.).

As far as I have been able to ascertain, the standard only specifies that bool must be able to represent a binary state. Consequently, the size of bool can vary dramatically according to compiler implementation, and even within code generated by the same compiler – I have seen it vary between 1 and 4 bytes on platforms I’ve used – I have always assumed that this was down to speed of execution vs. storage size tradeoffs.

This ‘size of bool’ issue resulted in the use of bool being banned from use in complex data structures at least one company that I have worked at. I should clarify that this was a ‘proactive’ banning based on the fact that it might cause trouble rather than one that resulted from trouble actually having been caused.

We should also mention enums at this point (thanks John!) – the standard gives the storage value of an enumerated type the liberty to vary in size depending on the range of values represented by each specific enum – even within the same codebase – so an enum with values < 255 (or <= 256 members with no values assigned) may well have sizeof() == 1, and one which has to represent 32 bit values would typically have sizeof() == 4.

This brings us onto pointers. Strictly speaking pointers are not defined as one of the fundamental types, but the value of a pointer clearly has a corresponding data size so we’re covering them here.

The first thing to note about pointers is that the numeric limits required for a pointer on any given platform are determined by the size of the addressable memory on that platform.

If you have 1 GB of memory that must be accessible in 1 byte increments, then a pointer needs to be able to hold values up to ((1024 * 1024 * 1024) – 1), which is (2^30 -1) or 30 bits. 4GB is the most that can be addressed with a 32 bit value – which is why win32 systems can’t make use of more than 4GB.

For example, when compiling for win32 with VS2010, pointers are 32 bit (i.e. sizeof() ==4), and when compiling for OSX with XCode (on the Macbook Pro I use at work for iOS development) pointers are 42 bit (sizeof() ==6).

One thing that is definitely worth noting is that all data pointers produced by a given compiler will be the same size (n.b. this is not true of function pointers). The type of a pointer is, after all, a language level abstraction – under the hood they are all just a memory address. This is also why they can all be happily converted to and from void* – void* being a ‘typeless pointer’ (n.b. function pointers cannot be converted to or from void*).

That said, knowing the type of the pointer is absolutely crucial to the low level of many of the higher level language mechanisms – as we shall see in later posts.

Addendum

So, following on from a couple of the comments, I need to cover function pointers as separate from data pointers.

I made an incorrect assertion that all pointers were the same size. This is only true of data pointers.

Function pointers can be of different sizes precisely because they are not necessarily just memory addresses – in the case of multiply inherited functions or virtual functions they are typically structures.

I recommend the blog that Bryan Robertson linked me to, as it gives a concrete example of why pointer to member functions often need to be more than a memory address: http://blogs.msdn.com/b/oldnewthing/archive/2004/02/09/70002.aspx

I also found these useful links relating to function pointers and void* (this whole site is pretty damn useful in fact):

http://www.parashift.com/c++-faq-lite/pointers-to-members.html#faq-33.10

http://www.parashift.com/c++-faq-lite/pointers-to-members.html#faq-33.11

Thanks to Bryan and Jalf for pushing me to find out more :)

Intrinsic Types used by Fundamental Types

As I mentioned up front, this varies between the various platforms – and even then there’s no guarantee that the compiler will do the “sensible” thing and use all the intrinsic types supported by the platform you’re using.

Here is a screenshot of a win32 console app I knocked up that prints the sizes of the Fundamental types as created by compiling for win32 under VS2010:

C++ Fundamental types (win32 compiled on Windows 7 with VS2010)

My home machine is a 64 bit intel thing of some description, about a year old.

Since the processor is 64 bit, I’d hope that all of these sizes correspond to intrinsic types (8 bytes being the size of a 64 bit CPU register), however since I’m compiling for win32 (which can only fit 4 bytes in a standard CPU register) I’m guessing that it won’t be using intrinsics for types > 32 bit.

adding 2 long long values and storing the result in a 3rd long long

In any event, I can’t be sure without looking at the disassembly.

<…pause to add some simple test code with long long and run it…>

Sure enough, these 8 byte long long values are being handled as 2 32bit values.

Ignoring the actual addition, you can clearly see this because the code initialising llTest and llTest2 is setting them in two separate steps for the upper and lower 32 bits of the 64 bit values.

So now I know, and it wasn’t even scary – really I should go and check the rest of them…

Fancy Intrinsics

Most modern CPUs have fancy intrinsics – e.g. 128 bit vector registers that can store and operate on four-32bit-floats-in-one-value sort of stuff.

In theory these sorts of extra intrinsics can provide big wins in certain situations – e.g. heavy duty chunks of vector maths, or non vector maths that can be parallelised into vectors.

The chances are that your compiler won’t ever use these without you asking it nicely. There are plenty of good reasons why this is the case (apparently), but you should find that support for these hardware specific intrinsics will be mentioned in your hardware / compiler manuals.

Summary

So, what would I like you to take away from this?

Firstly, that there is a difference between the data types of the C++ language and the hardware data types.

Secondly, don’t just trust that your compiler is doing what would intuitively seem sensible to you. Check its work.

Thirdly, it’s not rocket science! You can find out by just modifying one of the sample programs for your new hardware and then looking at the disassembly in the debugger.

Finally, thought I might insert a few points of note here:

Almost all CPUs have 8 bit bytes. Any CPU with more than 8 bits per byte was probably designed by a maniac / genius (n.b. I find that there is a particularly fine line between the two in Computer Science circles).
One thing you need to watch out for with numerical types is that in the C standard, int and short both have the same numerical limit (unsigned int and unsigned short both have 0xFFFF (i.e. 16 bits)). I’ve never had a problem with it, but an int could be represented as 16 bit.
If you want to know the size of any given type just use the sizeof() keyword. Your compiler knows these things.

Epilogue

If you are hungry for more information on this level (i.e. fundamental and intrinsic types) I recommend searching #AltDevBlogADay, because there are loads to choose from…

Here are a few of articles I found when doing a quick search (apologies to those whose articles I missed as a result of less than thorough searching!):

http://altdevblogaday.com/2011/08/21/practical-flt-point-tricks/

http://altdevblogaday.com/2011/08/06/demise-low-level-programmer/

http://altdevblogaday.com/2011/11/10/optimisation_lessons/

A Low Level Curriculum for C and C++

Alex Darby — Wed, 09 Nov 2011 04:00:23 +0000

Background

In my last post I wrote Why I became an Educator I was bemoaning the lack of focus on Low Level understanding that seems to have afflicted Computer Science degree courses of recent times (at least in the UK…).

As a result, I received a comment from someone called Travis Woodward that said:

There are plenty of students out there who are more than willing to dive into low level stuff, but its hard to know where to start or even what to learn (the old ‘you don’t know what you don’t know’ problem).

I’ve looked around for something approaching a low level curriculum, but they tend to just be lists of topics which aren’t actually that helpful without context and suggested resources to start you off. The best intro I’ve found so far is a course called CS107: Programming Paradigms from Stanford on iTunesU, which has a good section on how C and C++ look to a compiler.

So if any low level programmers want to put together a low level curriculum with suggested resources, then please do! :)

This is of course a commendable idea, and so I decided to get started on it…

Low Level Curriculum?

Before I go any further, I’d like to clarify what I mean by “Low Level Curriculum”.

During my time in the industry I’ve helped architect and build a multi-platform once-Next-Gen-now-current-gen engine and tool chain, I’ve written plenty of shaders, tracked down countless hideous bugs by looking at disassembly and memory windows, hunted down the odd submission blocking threaded race condition, and on several occasions had to hand-unpick the broken stacks of core dumps from PS3 / X360 test decks to find bugs that only occur “in the wild”; but that doesn’t make me a low level programmer – this is the kind of thing I’d expect anyone with my sort of experience to have done.

I’ve never sat for hours poring over GPad or Pix captures, I’ve never really had to worry about stuff like patching fragment shaders or batched physics calculations on SPUs, or how to get the most from my AltiVecs, and I’ve certainly never had to re-code large chunks of code in assembler taking advantage of caching or sneaky DMA modes to get a few extra FPS out of anything – this is what low level programmers do, platform specific hardware optimised code usually written to get the best performance out of a machine.

This curriculum is not about learning to be a low level programmer.

What it is about is gaining a solid understanding of the low level implementational underpinnings of C and C++ * – an understanding that I strongly feel should be the base line for any programmer working in games.

Over the course of however many posts this eventually takes up I’ll be covering:

Data types
Pointers, Arrays, and References
Functions and the Stack
The C++ object model (several posts)
Memory (again, several posts)
Caches

Assuming you read and understand all of the posts in this series – and that I manage to communicate the information effectively – you should end up in a place where for any given “foible” of the language you understand not only that it exists but also – and most crucially – why it exists.

For example, you may (or may not) know that virtual function calls don’t work in constructors, before the end of this series of posts you will understand why they can’t work in constructors.

Again just to be clear, I’m not necessarily talking about the same level of understanding of this as someone who writes compilers for their day job; but certainly a level of understanding that gives you a much better idea of what is likely to be going on at the level of the underlying engine that C++ sits on top of, and which consequently enables you to far better understand the implications of the code you write.

* N.B. to be 100% clear, C will be covered strictly as a subset of C++.

There is no source code available for the current location.

Aieeee! Spare me the hexadecimal!

I’m sure the vast majority of programmers who use Visual Studio freak out the first few times they see this dialog.

I know I did.

I learned to program primarily in a green (or orange if the green screens were taken) screen dumb terminal Unix mainframe environment. You know, like they have in old films like Alien. The second and third year students had priority use of the XWindows machines (and the few Silicon Graphics workstations were for 3rd year graphics projects only), so dumb terminals were where I learned my trade.

Even on the XWindows machines there was no programming IDE that I was aware of – I used EMACS and GNU make files, and the only debugger I had use of was command line GDB, which is not what you’d call user-friendly. I got by with std::cout.

When I graduated I went from this world of bakelite keyboards, screen burn, and command lines into the bright world of windows 95 development using Visual Studio 4 (slightly before Direct X and hardware accelerated graphics).

When I first saw this dialog box you can bet your life I freaked out – and why wouldn’t I?

Thanks to the language syntax and code architecture focussed high level teaching methods employed by my university I had no more idea of what went on behind the veil of the compiler than my brief forays into debugging with GDB had afforded me.

I’d just got a degree from a well-respected University where they had altogether avoided teaching me about assembler as part of the main syllabus, and I had assumed it was because they were worried it was too much for my puny mind to deal with.

Suffice to say, I got over the freaking out part – but I still saw this dialog as a “No Entry” sign for far longer than I’d like to admit.

I only really started to really get over it a few years later when I was working closely with someone who had got a job in games on the strength of their assembler programming.

I had a crash, and they just casually leant over and clicked the “Show Disassembly” button. Then, equally casually, showed me exactly why my code was crashing – explaining it in terms of how C++ maps to assembler – and told me how to fix it.

This blew my mindgaskets three times because:

this person was so casual about it
disassembly clearly wasn’t the black magic it appeared to be
given it was so simple I couldn’t believe I hadn’t been taught about the low level innards of C++ at University

Rending the Veil of Disassembly

I really didn’t realise how incredibly important this was until I had the pleasure of meeting a guy called Andy Yelland. If you already know Andy, then you will know exactly what I mean, but for those of you who have not met him I will explain.

Andy is one of those people who changes your perspective. He is more or less the polar opposite of the stereotypical ninja-level video game programmer: well dressed, professional, endlessly well-informed, friendly, funny, and socially adept.

However, the most amazing thing about Andy is the speed with which he can dissect a console core dump. He just sits there and calmly unpicks the stack, occasionally keeping a few notes about which register some value is in, or looking up the address of a function in a symbol file as he goes, and then in somewhere between 5 minutes and a few hours (depending on how tricky the issue is) he’ll turn around and tell you exactly what the problem was.

Not only that, but he’ll happily do this in a codebase he’s never even seen before – and even better, he’s totally happy to sit and explain it all to you as he does it.

After sitting with Andy for a few dissections I realised that whilst what he does seems like black magic, it is in fact anything but.

It’s about having an expert understanding of how C++ works at the assembly level, and bloody-mindedly applying that knowledge to reverse engineer the state of the system backwards from the current stack state (i.e. when the crash happened) to the point where the bad data was introduced.

Clearly this takes a lot of practice, and to get anywhere near as good as Andy at it will take anyone (who isn’t Rain Man) years of their life.

I’m not saying that I think everyone should be able to casually decipher disassembly representing code they didn’t write – I certainly can’t do that.

What I am saying is that I think all game programmers should be able to look at disassembly and be able to at least make an educated guess at what is going on, and by leveraging their understanding of how C++ is implemented at the low level – and given time, possibly with some hardware manuals – then they should be able to work it out.

The first rule of the Low Level Curriculum for C++: Don’t fear Disassembly

Ok, so assuming that you agree with me where do you start?

I think the best way to start making sense of it is to look at some simple code in the disassembly window, so let’s do that.

Make yourself a test project in a C++ programming IDE of your choice and write some simple code in your main() function.

For the sake of argument, let’s say you’re using my weapon of choice – Visual Studio 2010 on a Windows PC.

The Code I’m suggesting we look at is this:

int x = 1;
int y = 2;
int z = 0;
 
z = x + y;

Make sure you’re in the “debug” configuration, and put a breakpoint on the line

z = x + y;

then run the program.

When the breakpoint gets hit, right-click in the text editor and choose “Go To Disassembly” from the context menu.

DON’T PANIC!

NOTE: ensure that you have the same options checked in the right-click context menu!

You should now see something that looks something like the image above. Your text will almost certainly be scrolled differently, because I’ve messed about with the window sizes and text position for clarity.

The black text with line numbers is clearly the code we compiled, the grey text below each line of code shows the assembler that each line of code generated.

So what does it all mean?

The hexadecimal number at the start of each line of assembler is the memory address of that line of assembler – remember code is really just a stream of data that tells the CPU what to do, so logically it must be at an address in memory. Don’t worry about these too much, I just wanted to make the point that the instructions are in memory too.

mov and add are assembler mnemonics – each represents a CPU instruction, one per line with its arguments.

eax and ebp are two of the registers in the x86 CPU architecture. Registers are “working area” for CPUs: fragments of memory that are built into the CPU itself, and which the CPU can access instantaneously. Rather than having addresses like memory, registers are named in assembler because there are usually only a (relatively) small number of them.

The eax register is a “general purpose” register, but is primarily used for mathematical operations.

The ebp register is the “base pointer” register. In x86 assembler, local variables will typically be accessed via an offset from this register. We will cover the purpose of ebp in later posts.

As I alluded to in the previous sentence, ebp-8, ebp-14h, and ebp-20h are the memory addresses (as offsets from the ebp register) storing the values of the local variables x, y, and z respectively.

dword ptr [ ... ] means “the 32 bit value stored in the address in the square brackets” (this is definitely true for the Win32 assembler, it may be different for the Win64 one – I’ve not checked).

How does it work?

Now, we know that the assembler generated by the C++ code we’ve written will initialise the three variables x, y, and z; then add x to y and store the result in z.

Let’s look at each line of assembler in isolation (ignoring the address).

mov    dword ptr [ebp-8],1

This assembler instruction sets the value of the variable x by moving the value 1 into the memory at address ebp-8.

mov    dword ptr [ebp-14h],2

This assembler instruction sets the value of the variable y by moving the value 2 into the memory at address ebp-14h – n.b. the ‘h’ is necessary because 14 in decimal is a different value from 14 in hexadecimal – this wasn’t necessary when specifying the offset for the value of x because 8 is the same value in decimal and hexadecimal.

mov    dword ptr [ebp-20h],0

This instruction is, unsurprisingly, setting the value of the variable z.

Now we’re up to the interesting part, doing the arithmetic and assigning the result to z.

mov    eax, dword ptr [ebp-8]

This instruction moves the value of the memory at address ebp-8 (i.e. x) into the eax register…

add    eax, dword ptr [ebp-14h]

…this instruction adds the value of the memory at address ebp-14h (i.e. y) to the eax register…

mov    dword ptr [ebp-20h],eax

…and this instruction moves the value from eax into the memory at address ebp-20h (i.e. z).

So, as you can see, whilst the assembler looks very different, it is logically isomorphic with the C++ code that it was generated from (i.e. whilst its behaviour may be slightly different, it will give the same output for any given input).

Hold on, why did we look at that again?

Those of you with brains connected to your eyes will have noticed that the intro to disassembly I just gave was – to use a British colloquialism – “a bit noddy”.

In all honesty, that was the whole point of choosing such a simple example. the intention was to show how something as simple as adding two integers and storing the result in a third in C++ maps to assembler.

You can use this exact technique to look at the vast majority of the C++ language constructs and see what they actually generate, and the purpose of this was to show you that it’s simple enough to do.

Obviously this example showed only two of the x86 assembler mnemonics, of which there are many more.

If you want to make sense of assembler code that is using mnemonics you don’t know, it’s usually as simple as googling them. That’s all I’ve ever done, and there is so much information about x86 assembler floating about on the interweb that you should have little trouble deciphering it.

I found a super helpful webpage that covers the x86 registers in some detail: http://www.swansontec.com/sregisters.html

Here’s a link to a page to download a .pdf x86 “cheat sheet”: http://www.jegerlehner.ch/intel/

And the obvious wikipedia page: http://en.wikipedia.org/wiki/X86_instruction_listings

And a beefy link also linked from wikipedia: http://home.comcast.net/~fbui/intel.html

Summary

Whilst very few programmers will ever need to write assembler, all game programmers will – sooner or later – find it to their advantage to be able to read and make some sense of it. It’s amazing what you can figure out with only a partial knowledge of assembler and how it maps to C++ code.

The example code we looked at was, as I’ve already admitted, very simple.

The point of this first post wasn’t to give you answers, but to show that the disassembly window is only daunting if you let it be; and to encourage you to explore what your compiler is doing with the code you give it.

Don’t give up just because you don’t understand what you’re seeing yet; google it or post a specific question somewhere like http://stackoverflow.com/.

Epilogue

I guess there are a few other things that I’d like to draw your attention to a few other things that I think are there to take away from this tiny snippet of disassembly:

the C++ concept of a variable (or any other language’s concept of a variable for that matter) doesn’t exist at the assembler level. In assembler the values of x, y, and z are stored in specific memory addresses, and the CPU gets at them by explicit use of their respective memory addresses. The high level language concept of a variable, whilst easier to think about, is actually already an abstracted concept identifying a value in a memory address.
note that in order to do anything “interesting” (e.g. add a value to another) the CPU needs to have at least part of the data it is operating on in a register (I’m sure some that some CPUs must be able to operate directly on memory, but it’s certainly not the usual way of doing things).

Finally, I feel that this extremely simple example illustrates what I think is one of the most important facts about programming:

High level languages exist only to make life easy for humans, they’re not any kind of accurate reflection of how CPUs actually work – in fact even assembler is a human convenience compared to the actual binary opcodes that the mnemonics (e.g. mov, add etc.) represent.

My advice is don’t think about the actual opcodes too much, and definitely don’t worry about the electrons or the silicon :)

Why I became an Educator

Alex Darby — Tue, 25 Oct 2011 04:00:17 +0000

I’ve always felt that my education left me woefully under prepared for the realities of the workplace, let alone the realities of the workplace in the Video Game Industry.

I’ve learned almost all of what I consider to be the core knowledge required by game programmers out of necessity whilst doing my job; and each time I’ve made one of these fundamental discoveries, I’ve felt that there was no good reason why I couldn’t have been told about it during my education.

Kneel before the Sinclair ZX Spectrum+

I had no formal training in Computer Science before I studied for a degree in Computer Science, but – like most programmers of my generation – I learned to program in BASIC on one of the 1980′s many cheap personal computers – in my case a Sinclair ZX Spectrum+.

Eventually, I ended up studying Computer Science at University (Jt Hons Comp Sci / AI & Psychology).

When I went to University, C++ was still a new language and the template keyword wasn’t in the language standard. In fact, according to Wikipedia there wasn’t a langauge standard until 1998, which is 5 years after I started university.

As I assume most other people were back then, I was taught language syntax in lectures, and set a lot of coursework to force me to apply that syntax and allow my learning to be assessed.

Unfairly or fairly, I genuinely don’t feel that I learned anything significant about programming directly from the people who ostensibly educated me in it.

I may have learned how to program whilst solving the problems that the lecturers had set; but I was taught far, far more by one or two specific people around me (thanks Nigel and Matt) when I was solving them than by the lecturers who had read language syntax at me.

The Bjible

Even back then in 1993 – before what we now think of as the internet was really in existence – the langauge syntax of C++ could be easily learned from a book (e.g. “The C++ Programming Language” by Bjarne Stroustrup – also known as the “Bjible”), but the syntax of the language isn’t the code that executes – so why did no-one explain those parts of it to me?

Ironically, I managed to sail through university and get a job at Codemasters with the functional level of knowledge that I had been given by a year’s worth of C++ syntax lectures and coursework, but I was in for a massive shock when I actually started work.

Two of the guys I knew at Codies were doing a Sega Saturn port of the PSOne version of Micro Machines V3. They had reverse engineered the opcodes of the Saturn’s sound chip using a multimeter and an oscilloscope and, from what I recall, were using their findings to get extra texture memory by storing textures in sound RAM.

At that point in time I literally didn’t know what the stack was, and heap was just another word for a badly organised pile. What those two guys were doing was literally and figuratively completely beyond me.

Needless to say I learned fast, I had to. I was also lucky enough to be around programmers who had that level of knowledge and were more than happy to share it.

Over the years I have seen a consistent worsening of understanding of the low-level underpinnings of programming languages from graduates – which is, I suppose, to be expected given the ongoing trend toward teaching only Java on traditional Computer Science Degrees (at least in the UK).

However, more worryingly, I have also seen a constantly surprising lack of low-level knowledge and understanding demonstrated by theoretically experienced programmers.

One of my main motivations in becoming an educator is to try to address this issue; as most of the really horrible hard to track down bugs I’ve seen over the years have arisen from some subtle disconnect between what a programmer thinks they’re asking the compiler to do and what they’re actually asking it to do.

Without a thorough understanding of the underpinnings of C++ – i.e. how the engine of the C++ language is implemented – you can’t possibly properly understand the implications of the C++ code that you’re writing.

Even if you understand the way that C++ works internally then, sooner or later, you’re still going to have to worry about the implications of any given implementational choice for the way the code executes on the specific hardware architecture it will execute on.

It’s a lot to take in. Very few people get it right all of the time – and I’m not foolish enough to claim to be one of them – but that’s not a get-out-of-jail-free card…

If you’re only thinking about what you want the compiler to do, and not worrying about what you’re actually telling the compiler to do, then you’re much more likely to get it wrong.

Remember:

All code is bad, especially your own – and if it compiles first time and seems to work then it’s probably wrong.

Making your own type id is fun!

Alex Darby — Mon, 10 Oct 2011 22:18:52 +0000

To RTTI, or not to RTTI?

Someone once told me “If you need to use RTTI then your design is wrong.”

I find that when you meet someone who says stuff like this, the best thing to do is tell them that – having tried both approaches – you totally prefer inheritance to composition; and then sneak away under cover of the resulting self-righteousness mushroom cloud.

Pragmatic? Moi?!?

In game programming we often end up inhabiting an interesting middle ground between engineering best practice and the practicality of getting the job done so we can hit the milestone and keep the company afloat.

In addition to this issue, the Object Oriented goal of localising the logical behaviour of an object into a class that contains the data that it operates on is sometimes at odds with sensibility as well as the other goals of OOP.

For example; I’ve lost track of the number of seemingly well thought out state machine manager classes I’ve seen which, when put into use, produce a system of state classes whose logic about state transitions is so decentralised amongst the various states that it actively works against the maintainability of the code.

For me the issues surrounding use of RTTI are less about philosophy, and more about pragmatics.

There are plenty of situations where you can entirely work around a problem without using typeid or dynamic_cast; but there are also situations where the solution that doesn’t require them involves:

too many layers of abstraction to be readily digested at a later date by anyone who didn’t write the code in the first place, and / or
too much refactoring of existing code given the time and / or
is too risky given the current situation (e.g. in the final run-up to mastering)

In any of these situations I say: “Go for your life; but for the love of Bob please don’t use typeid or dynamic_cast<>.”

What’s wrong with typeid and dynamic_cast<>?

Well, there’s nothing actually wrong with them as such; they work as intended, and it’s not like they go around stamping on kittens or anything…

However, you need to leave RTTI turned on to use them; which uses extra memory for typeid (up to 40 bytes per class with virtual functions according to wikipedia, so not actually that bad), and dynamic_cast<> “can be pretty slow” and definitely isn’t constant time.

To be honest, I – and the other programmers who were founding members of FreeStyleGames – always felt the RTTI functionality was (is) just another little thing that people will tend to misuse if left to their own devices – so we always turned it off. I still do so now.

At the end of the day, using it has some small fixed and not so fixed penalties, and not using it doesn’t. That was enough to make up my mind for me.

Either way, I’m not writing this to argue coherently about whether you should or shouldn’t use the default C++ RTTI; that’s well trodden ground, people have their opinions and let’s just accept that I’ve decided to live on the side of the fence where we turn it off and use the extra memory for something more useful like storing user defined 1s and 0s.

So, what about this type id then?

So, assuming that you’re someone who’s sold on not using RTTI; and that you have a situation where you feel that your best-available-solution requires it (or something like it) then I hope what follows is useful – let’s get on with it shall we?

What do we want from our type id?

Firstly, our type id – let’s call it altTypeId – needs to resolve to a unique value for each type that we ask it to give us an altTypeId for.

Secondly, the value it gives for each type needs to be constant throughout the duration of each instance of the execution of our program.

Finally, I think it’s fair to say that it should to usable in a typeid alike fashion.

template and #define are your friends

Unsurprisingly, given that this problem requires a unique value per type we’re going to use a template.

Even more unsurprisingly, since the solution uses a template, we’re going to need a #define macro to wrap it so your code doesn’t become a hideous mess of angle brackets and scope operators.

Volia! Le code est ici!

Let’s start at the beginning, we need a type to hold altTypeId.

It’s pretty unlikely that any code base is going to have more than 0xFFFFFFFF types in total, and the number that might need to be resolved using a type id should be smaller than the total number. This makes an unsigned int (assuming it to be 32bit) a sensible choice.

1 2	// typedef for altTypeId as unsigned int typedef unsigned int altTypeId;

Ok, so the next part is we need some way to generate unique values for these altTypeIds. My solution to this is a class that contains a single static function which returns 0 the first time it’s called, and then 1 the next, then 2, and so on.

This is only a class because I want to make all of its functionality protected and hide the ability to generate altTypeIds away from anything not derived from it.

class CAltTypeIdGen_Base
{
public:
    enum{ ALTTYPEID_INVALID = 0xFFffFFff };
 
protected:
    // generates type Id values starting from 0
    // you would probably want to put this in a .cpp in case you want to use it in a library
    static altTypeId GenerateAltTypeId()
    {
        static altTypeId s_uNextClassID = 0;
        return s_uNextClassID++;
    }
 
    // only constructible from derived types
    CAltTypeIdGen_Base()
    {}
};

I’m assuming that you’re thinking “What?” at this point. The above class doesn’t make a lot of sense without the template that turns it into a one-number-per-type system. Here it is…

template< typename T >
class TAltTypeIdGen : public CAltTypeIdGen_Base
{
public:
    // this generates a typeID for each class that instantiates the template
    static altTypeId GetAltTypeId()
    {
        static altTypeId s_uClassId = GenerateAltTypeId();
        return s_uClassId;
    }
 
    private:
    // no instance of this class can be created.
    TAltTypeIdGen()
    {}
};

Now we have a way of generating a unique altTypeId for each type in the code base – this template type cannot be constructed, and the internal static data of its only accessible function can only be initialised once. Joy.

To finish it off I’ve added a macro that makes it less visually traumatic to use, and a template function that extracts the altTypeId from an instance of a type which is pretty helpful too.

// define to make CAltTypeIdGen_Base::ALTTYPEID_INVALID less visually traumatic
#define ALTTYPEID_INVALID CAltTypeIdGen_Base::ALTTYPEID_INVALID 
 
// macro for getting hold of a type's altTypeId
#define GetAltTypeIdOf( TYPENAME ) ( TAltTypeIdGen< TYPENAME >::GetAltTypeId() ) 
 
// resolves to the correct form of TAltTypeIdGen< T >::GetAltTypeId()
template< typename T >
altTypeId GetAltTypeIdOfInstance( T instance )
{
    return TAltTypeIdGen< T >::GetAltTypeId();
}

That was easy, right? Now we can use the altTypeId to make decisions based on the type of variables e.g.:

int iDemo = 0;
if( GetAltTypeIdOf( int ) == GetAltTypeIdOfInstance( iDemo ) )
{
    // do stuff
}

But… that’s not really useful for anything… is it?

Busted! Ok, so the astute amongst you will have noticed that so far altTypeId is not really mega useful…

So, the first thing to note about what I’ve shown here is that it isn’t a straight replacement for typeid, and it definitely isn’t a straight replacement for dynamic_cast<>. It does however definitely let you solve the majority of problems whose alternate solutions might involve these two C++ language features.

The main limitation of altTypeId is that – without a little extra stitching into your code – can’t be used to do any reasoning about the actual types of objects pointed to by a pointer of a base type.

This is for two reasons:

templates can only operate on what you instantiate them with at compile time – so a pointer to a type will give you a different altTypeId than an instance of the type would, and

a pointer to a base class will always yield the altTypeId of a pointer to a base class – there’s no polymorphic cleverness in altTypeId

To be honest I’m pretty sure that some template black magic could fix the first issue, but I’ve never bothered to because there are lots of reasons type id should maintain the differentiation between the type of an instance and the type of a pointer to that instance. Apart from anything else type and type* are actually different types…

The second issue is definitely fixable – you could either:

have a (pure) virtual function in the base type that returns an altTypeId and implement it in all deriving classes to return their actual altTypeId, or

have a base class that has an altTypeId as a member which is set by an argument to its constructor when derived classes are constructed. This way is more tedious to write, as you have to chain the constructors down the hierarchy if there is > 1 level of derivation from the base class. However it has no virtual function overhead for getting at the altTypeId.

I’ve used both of these approaches myself, and they’re both fine – though the second one takes more explaining to get people to do it correctly.

Summary

The code is here if you want to just download it: http://codepad.org/uqoOP7WW.

Hopefully this was of some interest and not so bleedingly obvious that you, dear reader, were wondering why I bothered to post it.

I’ve had occasion to use this code maybe 4 or 5 times over the years since I originally wrote it and each time I dig it out I usually make a couple of tweaks so this is relatively mature code (I know it’s tiny, but it’s changed quite a lot from the original implementation!).

I’m 99.9% sure that with some extra template magic it could be made into something a lot cleverer – in fact I know it can because I built a reflection system off it, but I can’t give you the source to that since it belongs to Activision.

Incidentally, if you’re interested in templates I highly recommend the book “Modern C++ Design” by Andrei Alexandrescu, the reflection code I wrote drew heavily on this book. Ironically it’s 10 years old now and will probably still blow your mind gaskets unless you’re the kind of person who programs entirely in templates and contributes to boost. Some of the stuff in there is pure genius, and yet it’s almost entirely unused in games where its use would make things good ™ (e.g. policy based design).

Final thought; solutions 1 & 2 in the previous section would also work with an enum containing a value for all derived types of the base class instead of a fancy templatey solution, but if you do it that way you will make Bjarne Stroustrup cry.

Epilogue, or The Benefit of Peer Criticism

Following on from comments made on this by Unai Lander, Michael Nicolella, and Nicolas Silva I have added this epilogue.

Unai suggested a more elegant solution, Michael pointed out a couple of possible issues with run time efficiency of the solution I posted originally, and Nicolas spotted what I was getting at with the phrase “template black magic” – specifically if you want const int, volatile int, and int to return the same altTypeId you will need to use a technique called “qualifier stripping” which uses partial template specialisation and is covered in detail in the Andrescu book “Modern C++ Design”, page 44 [2.10.4 Stripping Qualifiers].

Unai’s solution removes the need to have the base type for the template Id generator type. Like many really elegant solutions it seems bleedingly obivous when you see it :)

typedef unsigned int altTypeId;
 
template< typename T >
class TAltTypeIdGenerator
{
private:
    // no instance of this class can be created.
    TAltTypeIdGenerator()
    {}
 
public:
    // this generates a typeID for each class that instantiates the template
    static altTypeId GetAltTypeId()
    {
        // I wasn't sure if the char would take up > 1 byte because of alignment.
        // With VS2010 on win32 they take up exactly 1 byte each (and in the pastebin too...)
        static char chAddressOfThisIsTheTypeId;
        return reinterpret_cast< altTypeId >( &chAddressOfThisIsTheTypeId );
    }
};

Michael pointed out that using a function local static introduces the overhead of conditional branching into the function, which is bad for obvious reasons.

So, I did a little empirical experimentation (in VS2010) to see what the assembler did for various cases of function local statics and here’s what I found:

int functionNotInit( void )     // no branches
{
    static int iNotInit;
    return iNotInit;
}
 
int functionNotInitInc( void ) // no branches
{
    static int iNotInit;
    return iNotInit++;
}
 
int functionInitZero( void ) // no branches
{
    static int iInit = 0;
    return iInit;
}
 
int functionInitZeroInc( void )    // no branches
{
    static int iInit = 0;
    return iInit++;
}
 
int functionInitFunction( void ) // conditional branch to call SetValue on first time through
{
    static int iInitFromFunc = SetValue();
    return iInitFromFunc;
}

So, the upshot is that (as an uninitialised function local static appears to have no branch overhead associated with it) I have revised the code to use Unai’s method and whacked the new version into a paste bin for your pleasure here:

http://codepad.org/RXZfzCpo

Thanks to Unai, Michael, and Nicolas :)

How I discovered my favourite templated list class

Alex Darby — Sun, 25 Sep 2011 00:42:23 +0000

Templated list class?!?

Really? This isn’t 1996 dude. We have the STL and the fancy new ISO approved C++11 standard. We don’t need your stupid list class.

That’s fine. Sorry. How stupid of me – please feel free to ignore the rest of this blog.

I can only apologise for having wasted your time.

My favourite templated list class

If you’re still reading, well done – you have passed the test.

You receive the +1 Spectacles of Second-Hand Perspective, and the +2 Underpants of Questionable Enlightenment.

Please continue reading.

Prelude

As other ADBAD posts about data structures have already said, there’s no such thing as a one-size-fits-all data structure.

Obviously you should definitely avoid spending time writing new data structures unless you genuinely need to, and not optimise until you find a bottleneck; but sometimes there are cases where you don’t actually need to, but if you don’t then you will maybe sleep a little less soundly at night wondering what that generic class you used is up to when you’re not looking at it.

The templated list class I’m eventually going to give you the code for definitely doesn’t fit all, and I guess the absolute need for it is questionable, but it’s still my favourite templated list class.

Why, dear reader? That’s what I’m about to tell you.

The Backstory

It was the last console hardware transition. Our middleware provider had been bought by a large publisher and had essentially gone out of business. New consoles were appearing daily. The company decided to do a couple of work-for-hire type projects whilst we planned how to hit the next-gen.

We looked at the other middleware available at the time. We decided that we didn’t want to use Unreal and that most other extant providers were no more likely to be around forever than our previous one. After much deliberation it was decided that a small group of us should roll our own in-house engine.

What we were doing

Going from mature bleeding edge middleware to a self built engine is a big shock to the system

Our initial platforms were PS3 / X360, but we made a conscious choice to leave the door open for Wii because even the early indications were that it might end up having the biggest install base. This meant that the multi-platform architecture had to be very flexible and modular to leave room for the various platforms to be different but for our libs to work the same.

Several of the guys involved were old hands at engine code and we knew what we were doing, but even working as fast as we could, we knew that the most we’d be able to get done in any sensible timescale was the basics; and that any features we added above that would need to be directly applicable to the target game in order to make it worth our while.

What was on our mind

A lot of our core concerns in writing this engine were to mitigate against problems we’d experienced on our previous projects.

There was big picture stuff – like making sure the tool chain enabled assets to be added without needing code to be written so that the art and design teams could work effectively and iterate content without code issues slowing them up.

There was also nitty gritty stuff – for example, our previous game had had no end of problems with OOM caused by heap fragmentation. It was no-one’s fault directly – more a symptom of the fact that team sizes were growing, games were getting more complex, and tools hadn’t quite caught up – everyone was doing their own thing to get the game done, and because the game was fine until it had been running for some time none of the programmers had noticed it.

Must… Allocate… Memory… Fragmenting.

At the time we were relying on a slightly tweaked version of the basic the memory manager that our middleware provider had given us. It didn’t have the ability to do any sort of checks for fragmentation.

Heap fragmentation sucks, especially if you don’t know it’s happening. We only really found out that it was happening between alpha and beta – when QA started hammering it.

A couple of us spent a very long time tidying it all up. It was a mess. So much code existed that was blithely doing temporary allocations in amongst long term ones. Some stuff was just ill considered decisions made at 2am when under time pressure, but it turned out that a lot of it was to do with either:

Unexpected interactions between the asset management and graphics subsystems of the middleware when used in the way that our game was using them.
Insanely naive / inappropriate use of STL and other library code in the front end tin the code that wrote the persistent data that the gameplay relied on for settings etc. This was the killer.

It was a fairly big job to sort out, and involved several large architectural changes to the loading system of the game, plus tearing out all the STL use in our game side code.

Just to be clear, the problem wasn’t directly caused by STL but the way in which it was being used; it was quicker to tear it out than fix it – imagine a situation where someone had used STL whenever possible as opposed to where it made sense to, like having a std::vector< std::tuple< int, float > > instead of an array of a struct with an int and a float in it. And not pre-allocating the size of the vector even when it was fixed.

I’m honestly not trying to start an STL fight. This code was so insane that it managed to read the data out of a 15kb XML file and take up 750kb in memory. That was nothing to do with STL itself, but the way it had been (ab)used really didn’t help.

The upshot of all this? Our Technical Director ended up as an anti-STL extremist, and he and several others (myself included) ended up borderline paranoic about memory fragmentation.

What we did about it

When we started writing out new in-house engine, the first thing that was done to address these issues was that the technical director banned STL and we wrote our own templated container classes. Sure there were other things that could have been done, but that’s what was done.

Another thing was the creation of a memory management subsystem that had all sorts of nice features including fragmentation detection, multiple heaps for different sizes and types of allocs etc. etc.

We also set out one of our prime directives to do whatever we could to prevent fragmentation at the architectural level to make it harder for people to accidentally cause fragmentation.

So, about this template list class you mentioned…

I’ve not forgotten. Honestly.

The asset management system was on my schedule. Sure it’s pretty dry stuff, not everyone’s cup of tea, and definitely not a glory area like implementing a deferred bipolar thrumble edging render pass or whatever; but someone had to do it.

I’ll be honest, I like this sort of stuff. You get to stroke your chin and consider the “best way to do it ™”, and also have a good chance of getting the rare treat of writing code once and never having to change it again – other than the odd bug fix for a real life edge case you missed in your test runs.

With a prime directive of “prevent memory fragmentation”, I found it became very interesting. I stroked my chin and contemplatively nommed the arm of my glasses many times, discussed it over many cups of tea with other programmers, and eventually I came up with a plan that would work.

It did work, and it’s possibly the only bit of code I’ve ever written that I’ve been 100% happy with.

Simple, elegant, and competely bulletproof. Anti-fragmentation asset handling. The future.

There were a couple of teeny weeny little caveats on usage – much of the underlying architectural fragmentation resistance came from the fact it was sort of stack like; so it always unloaded assets in the opposite order to loading – but it was a small price to pay for being awesome and fragmentation proof.

That’s another story though. The important thing is that my main architectural concern was preventing memory fragmentation, and the best way that I know of to entirely reduce the risk of fragmenting memory is not to allocate or deallocate anything.

So, in an ideal world, this asset manager needed to store the managed assets in a data structure that didn’t have a fixed size, and which also didn’t allocate or deallocate memory.

Just one more tangent.

After I had been made paranoid about memory fragmentation and unintended allocations, I started to worry about the STL container classes.

Once I found out that you can mostly handle that sort of thing with an appropriate STL allocator I got over it (it still bothers me that so few programmers I’ve known seem to worry about this stuff, but that’s largely out of my control).

However, I eventually came up against a use-case with generic containers that still bothered me, and it was essentially a property of the way a generic containers have to work in order to be generic – so AFAIK there’s no work around other than a different approach.

Consider a common situation where you’ve got a known number of pre-allocated objects and you’re using a dead list and an active list to manage which are being used and which are not.

What happens when you take something out of one list and put it into another?

The link element used to store the object in the list doesn’t move with the object, but it still has to go somewhere.

I reasoned that what’s actually going on in any given templated list implementation is likely to be somewhere between the following two cases:

Worst case: a list element is newed every time I insert something into a list, and deleted every time I take it out. This is potentially one free store alloc + constructor and one destructor + free store dealloc per object moved between lists.

Best case: list elements are pre-allocated for each list so elements are used when an object is inserted and recycled when they’re removed. This still has an overhead for internal list element management, and also has to pre-allocate the maximum number of elements in both lists which is wasteful.

I honestly doubt there are many situations where this has become a bottleneck, but I just couldn’t bring myself to feel happy about the list element not moving with the object as it moves from one list to the other – it just seems wasteful and sloppy.

The way to work around this is bleedingly obvious, and is how most – if not all – heaps keep track of the memory they manage. You just put the list element into the object you’re going to store in the list.

This, as it happens, is also where the allocationless data structure comes in.

Ladies and Gentlemen…

It is my profound pleasure to present to you my favourite template list class.

(Note: 12/10/2011 – I found a bug in the code and have put the fixed code into the pastebin…)

In fact, it’s in a pastebin: http://codepad.org/hK6xO2bO

Codepad is ace. It runs the code too, and so you can see the output as well as the nicely highlighted code. Yay!

Broadly speaking, the code works like this:

There is a class for the templated list called CNoAllocList which does all the donkey work.
Intances of CNoAllocList can’t be created directly, and it’s wrapped by a template called TNoAllocList which is how you create one.
There is a base class called CNoAllocListable from which you derive the type you want to store.
You create an instance of TNoAllocList<> with your type as the template parameter…
…and then you can do all the normal sort of list operations on it with instances of your CNoAlloListable derived type.

A few little things to bear in mind:

This probably isn’t code you would want to drop straight into an existing code base – it’s intended to be more illustrative than instantly usable.
I couldn’t post the original code as:
1. I don’t have it, and
2. (more importantly) it belongs to Activision.
The template isn’t even vaguely STL container compliant, but it’s not supposed to be.
I’ve left writing an iterator as an exercise for you, but it is useable as is.
I’ve put lots of comments in the code which – whether you love or hate that – should explain it nicely.
I also like hungarian notation, and tend to go a bit mad with access specifiers so, for that I apologise.

So, why is it my favourite?

I’m sure the amount of fuzzy contentedness I get from this approach to lists is not normal, but I love it.

There are two reasons why:

1) It doesn’t allocate.

2) It only has one case for inserting links and one case for deleting links. This is possibly my overall favourite thing. The same approach to storing the head & tail that gives this property could be used in any list class.

Oh wait there’s three reasons:

3) The links move about between lists with the objects.

It’s not really important in the “generic list” case, but if you’re using a free list and an active list this saves all of the overhead of managing the list elements that the lists are built of.

Sorry, four reasons (“hold on, I’ll come in again…”):

4) The only real tradeoff for this awesomeness is that you can’t put a given object in more than one list simultaneously.

This might be fixable, but I’d be surprised if it didn’t need a significantly different implementation.

Parting thoughts

As I mentioned at the start, TNoAllocList is not a one size fits all data structure.

I think it’s probably most suited to the use case that inspired me to write it in the first place – managing of free / active lists of objects.

I hope this wasn’t a waste of your time, and ideally I hope it was useful – or at least interesting.

The final thing to remember is, just because your list can’t fragment memory it doesn’t mean you won’t.