A common problem beginning programmers have with assembly language is understanding calling conventions and register preservation rules, because those are not rules imposed by the architecture, but are rather created by convention.<\/p>\n
Imagine that you are an instructor at a university. In the United States, classrooms are typically not dedicated to a single class or a single instructor, but rather, classes and instructors are assigned to rooms on a case-by-case basis, and it is common for instructors to have to teach classes in multiple rooms.<\/p>\n
The convention at the school might be that the instructor is free to use the chalkboard however they like, and they are allowed to erase any content left on the chalkboard when they arrive for the start of class, with no responsibility to return the chalkboard to its original state when the class ends.<\/p>\n
On the other hand, the convention is that the desks and chairs in the classroom must be returned to their original places at the end of class. The instructor is permitted to move the desks and chairs during class, but they have to put them back in the original locations when the class is over.<\/p>\n
The chalkboard is like the registers we call “scratch” or “volatile”: You are welcome to use them all you want, and you are not under any obligation to restore them to their original values when you are done.<\/p>\n
The desks and chairs are like the registers we call “preserved” or “non-volatile”: You are welcome to use them all you want, but you are required to put them “back where you found them” when you are done. This is typically done by saving their initial state somewhere when you start (for desks and chairs, maybe by marking their locations with tape on the floor; for registers, by saving their values to memory) and restoring them at before you finish (moving the desks and chairs back to the markers; for registers, reloading the values from memory).<\/p>\n
There might be some fixtures in the classroom that may not be moved at all. You cannot unscrew the light bulbs or disable the fire alarm. These are “immutable” registers, which you aren’t allowed to modify, not even temporarily.<\/p>\n
Now, maybe your class is a lab class that has been given a dedicated room for an entire week, so you don’t have to reset the room after each session and can instead just resume from where the previous session left off. But you don’t have class on Wednesday, so for Wednesday, another class uses the room. What can you expect?<\/p>\n
Well, the conventions say that the chalkboard is available for use. So don’t leave anything important on the chalkboard at the end of the Tuesday class, because it will be gone when you come back on Thursday.<\/p>\n
On the other hand, the conventions also say that the desks should be returned to their original locations, so the desk clumps you created for your lab class will still be there. The desks may very well be moved around by the Wednesday class, but they will return them to the original positions before they are done.<\/p>\n
Now, the school may have other conventions regarding the classroom. For example, maybe in addition to the convention that says that you have to restore the desks to their original locations, they also say that if you do move any desks, you have to take a photo of the classroom to show the original desk positions, and you have to post the photo on the bulletin board next to the door (and take it away when your class is over). The school requires this because your class might be cancelled after the Thursday session, so you won’t be around on Friday to reset the desks. The facilities staff needs to use that photo you took in order to restore the desks to their original positions for the class that had the room before you.<\/p>\n
When people write code in assembly language, they often forget about the conventions about taking photos of things before you move them because those photos (unwind codes<\/a>) are not explicitly in the code itself, but are instead stored in another part of the executable, to be consulted only in the (hopefully rare) case that the system needs to reason over<\/a> the stacks of active threads. This primarily happens during exception handling.\u00b9 But since the unwind codes are not immediately visible, people usually forget that they need them.<\/p>\n Related reading<\/b>: Zero-cost exceptions aren’t actually zero cost<\/a>.<\/p>\n