The Impact of the 8-Bit Bus Cycle-Eater

One obvious effect of the 8-bit bus cycle-eater is that word-sized accesses to memory operands on the 8088 take 4 cycles longer than byte-sized accesses. That’s why the instruction timings in Appendix A indicate that for code running on an 8088 an additional 4 cycles are required for every word-sized access to a memory operand. For instance:

mov ax,word ptr [MemVar]

takes 4 cycles longer to read the word at address MemVar than:

mov al,byte ptr [MemVar]

takes to read the byte at address MemVar. (Actually, the difference between the two isn’t very likely to be exactly 4 cycles, for reasons that will become clear when we discuss the prefetch queue and dynamic RAM refresh cycle-eaters later in this chapter.)

What’s more, in some cases one instruction can perform multiple word-sized accesses, incurring that 4-cycle penalty on each access. For example, adding a value to a word-sized memory variable requires 2 word-sized accesses — one to read the destination operand from memory prior to adding to it, and one to write the result of the addition back to the destination operand — and thus incurs not one but two 4-cycle penalties. As a result:

add word ptr [MemVar],ax

takes about 8 cycles longer to execute than:

add byte ptr [MemVar],al

String instructions can suffer from the 8-bit bus cycle-eater to a greater extent than other instructions. Believe it or not, a single rep movsw instruction can lose as much as:

524,280 cycles = 131,070 word-sized memory accesses x 4 cycles

to the 8-bit bus cycle-eater! In other words, one 8088 instruction (admittedly, an instruction that does a great deal) can take over one-tenth of a second longer on an 8088 than on an 8086, simply because of the 8-bit bus. One-tenth of a second! That’s a phenomenally long time in computer terms; in one-tenth of a second, the 8088 can perform more than 50,000 additions and subtractions.

The upshot of all this is simply that the 8088 can transfer word-sized data to and from memory at only half the speed of the 8086, which inevitably causes performance problems when coupled with an Execution Unit that can process word-sized data every bit as fast as an 8086. These problems show up with any code that uses word-sized memory operands. More ominously, as we will see shortly, the 8-bit bus cycle-eater can cause performance problems with other sorts of code as well.

What to Do About the 8-Bit Bus Cycle-Eater?

The obvious implication of the 8-bit bus cycle-eater is that byte-sized memory variables should be used whenever possible. After all, the 8088 performs byte-sized memory accesses just as quickly as the 8086. For instance, Listing 4-1, which uses a byte-sized memory variable as a loop counter, runs in 10.03 us per loop. That’s 20% faster than the 12.05 us per loop execution time of Listing 4-2, which uses a word-sized counter. Why the difference in execution times? Simply because each word-sized dec performs 4 byte-sized memory accesses (2 to read the word-sized operand and 2 to write the result back to memory), while each byte-sized dec performs only 2 byte-sized memory accesses in all.

I’d like to make a brief aside concerning code optimization in the listings in this book. Throughout this book I’ve modeled the sample code after working code so that the timing results are applicable to real-world programming. In Listings 4-1 and 4-2, for instance, I could have shown a still greater advantage for byte-sized operands simply by performing 1000 dec instructions in a row, with no branching at all. However, dec instructions don’t exist in a vacuum, so in the listings I used code that both decremented the counter and tested the result. The difference is that between decrementing a memory location (simply an instruction) and using a loop counter (a functional instruction sequence). If you come across code in The Zen of Assembly Language that seems less than optimal, my desire to provide code that’s relevant to real programming problems may be the reason. On the other hand, optimal code is an elusive thing indeed; by no means should you assume that the code in this book is ideal! Examine it, question it, and improve upon it, for an inquisitive, skeptical mind is an important part of the Zen of assembler.

Back to the 8-bit bus cycle-eater. As I’ve said, you should strive to use byte-sized memory variables whenever possible. That does not mean that you should use 2 byte-sized memory accesses to manipulate a word-sized memory variable in preference to 1 word-sized memory access, as, for instance, with:

mov dl,byte ptr [MemVar]
mov dh,byte ptr [MemVar+1]

versus:

mov dx,word ptr [MemVar]

Recall that every access to a memory byte takes at least 4 cycles; that limitation is built right into the 8088. The 8088 is also built so that the second byte-sized memory access to a 16-bit memory variable takes just those 4 cycles and no more. There’s no way you can manipulate the second byte of a word-sized memory variable faster with a second separate byte-sized instruction in less than 4 cycles. As a matter of fact, you’re bound to access that second byte much more slowly with a separate instruction, thanks to the overhead of instruction fetching and execution, address calculation, and the like.

For example, consider Listing 4-3, which performs 1000 word-sized reads from memory. This code runs in 3.77 us per word read. That’s 45% faster than the 5.49 us per word read of Listing 4-4, which reads the same 1000 words as Listing 4-3 but does so with 2000 byte-sized reads. Both listings perform exactly the same number of memory accesses — 2000 accesses, each byte-sized, as all 8088 memory accesses must be. (Remember that the Bus Interface Unit must perform two byte-sized memory accesses in order to handle a word-sized memory operand.) However, Listing 4-3 is considerably faster because it expends only 4 additional cycles to read the second byte of each word, while Listing 4-4 performs a second lodsb, requiring 13 cycles, to read the second byte of each word.

In short, if you must perform a 16-bit memory access, let the 8088 break the access into two byte-sized accesses for you. The 8088 is more efficient at that task than your code can possibly be.

Chapter 9 has further examples of ways in which you can take advantage of the 8088’s relative speed at handling the second byte of a word-sized memory operand to improve your code. However, that advantage only exists relative to the time taken to access 2 byte-sized memory operands; you’re still better off using single byte-sized memory accesses rather than word-sized accesses whenever possible. Word-sized variables should be stored in registers to the greatest feasible extent, since registers are inside the 8088, where 16-bit operations are just as fast as 8-bit operations because the 8-bit cycle-eater can’t get at them. In fact, it’s a good idea to keep as many variables of all sorts in registers as you can. Instructions with register-only operands execute very rapidly, partially because they avoid both the time-consuming memory accesses and the lengthy address calculations associated with memory operands.

There is yet another reason why register operands are preferable to memory operands, and it’s an unexpected effect of the 8-bit bus cycle-eater. Instructions with only register operands tend to be shorter (in terms of bytes) than instructions with memory operands, and when it comes to performance, shorter is usually better. In order to explain why that is true and how it relates to the 8-bit bus cycle-eater, I must diverge for a moment.

For the last few pages, you may well have been thinking that the 8-bit bus cycle-eater, while a nuisance, doesn’t seem particularly subtle or difficult to quantify. After all, Appendix A tells us exactly how many cycles each instruction loses to the 8-bit bus cycle-eater, doesn’t it?

Yes and no. It’s true that in general we know approximately how much longer a given instruction will take to execute with a word-sized memory operand than with a byte-sized operand, although the dynamic RAM refresh and wait state cycle-eaters can raise the cost of the 8-bit bus cycle-eater considerably, as we’ll see later in this chapter. However, all word-sized memory accesses lose 4 cycles to the 8-bit bus cycle-eater, and there’s one sort of word-sized memory access we haven’t discussed yet: instruction fetching. The ugliest manifestation of the 8-bit bus cycle-eater is in fact the prefetch queue cycle-eater.

Official Execution Times are Only Part of the Story

The sequence of 5 shr instructions in the last example is 10 bytes long. That means that it can never execute in less than 24 cycles even if the 4-byte prefetch queue is full when it starts, since 6 instruction bytes would still remain to be fetched, at 4 cycles per fetch. If the prefetch queue is empty at the start, the sequence could take 40 cycles. In short, thanks to instruction fetching the code won’t run at its documented speed, and could take up to 4 times as long as it is supposed to.

Why does Intel document Execution Unit execution time rather than overall instruction execution time, which includes both instruction fetch time and Execution Unit execution time? As described in Chapter 3, instruction fetching isn’t performed as part of instruction execution by the Execution Unit, but instead is carried on in parallel by the Bus Interface Unit whenever the external data bus isn’t in use or whenever the EU runs out of instruction bytes to execute. Sometimes the BIU is able to use spare bus cycles to prefetch instruction bytes before the EU needs them, so instruction fetching takes no time at all, practically speaking. At other times the EU executes instructions faster than the BIU can fetch them and instruction fetching becomes a significant part of overall execution time. As a result, the effective fetch time for a given instruction varies greatly depending on the code mix preceding that instruction. Similarly, the state in which a given instruction leaves the prefetch queue affects the overall execution time of the following instructions.

In other words, while the execution time for a given instruction is constant, the fetch time for that instruction depends on the context in which the instruction is executing -the amount of prefetching the preceding instructions allowed -and can vary from a full 4 cycles per instruction byte to no time at all. As we’ll see later, other cycle-eaters, such as DRAM refresh and display memory wait states, can cause prefetching variations even during different executions of the same code sequence. Given that, it’s meaningless to talk about the prefetch time of a given instruction except in the context of a specific code sequence.

So now you know why the official instruction execution times are often wrong, and why Intel can’t provide better specifications. You also know now why it is that you must time your code if you want to know how fast it really is.

There is No Such Beast as a True Instruction Execution Time

The effect of the code preceding an instruction on the execution time of that instruction makes the Zen timer trickier to use than you might expect, and complicates the interpretation of the results reported by the Zen timer. For one thing, the Zen timer is best used to time code sequences that are more than a few instructions long; below 10 us or so, prefetch queue effects and the limited resolution of the clock driving the timer can cause problems.

Some slight prefetch queue-induced inaccuracy usually exists even when the Zen timer is used to time longer code sequences, since the calls to the Zen timer usually alter the code’s prefetch queue from its normal state. (As we’ll see in Chapter 12, branches — jumps, calls, returns and the like — empty the prefetch queue.) Ideally, the Zen timer is used to measure the performance of an entire subroutine, so the prefetch queue effects of the branches at the start and end of the subroutine are similar to the effects of the calls to the Zen timer when you’re measuring the subroutine’s performance.

Another way in which the prefetch queue cycle-eater complicates the use of the Zen timer involves the practice of timing the performance of a few instructions over and over. I’ll often repeat one or two instructions 100 or 1000 times in a row in listings in this book in order to get timing intervals that are long enough to provide reliable measurements. However, as we just learned, the actual performance of any 8088 instruction depends on the code mix preceding any given use of that instruction, which in turns affects the state of the prefetch queue when the instruction starts executing. Alas, the execution time of an instruction preceded by dozens of identical instructions reflects just one of many possible prefetch states (and not a very likely state at that), and some of the other prefetch states may well produce distinctly different results.

For example, consider the code in Listings 4-5 and 4-6. Listing 4-5 shows our familiar shr case. Here, because the prefetch queue is always empty, execution time should work out to about 4 cycles per byte, or 8 cycles per shr, as shown in Figure 4.3. (Figure 4.3 illustrates the relationship between instruction fetching and execution in a simplified way, and is not intended to show the exact timings of 8088 operations.) That’s quite a contrast to the official 2-cycle execution time of shr. In fact, the Zen timer reports that Listing 4-5 executes in 1.81 us per byte, or slightly more than 4 cycles per byte. (The extra time is the result of the dynamic RAM refresh cycle-eater, which we’ll discuss shortly.) Going strictly by Listing 4-5, we would conclude that the “true” execution time of shr is 8.64 cycles.

Now let’s examine Listing 4-6. Here each shr follows a mul instruction. Since mul instructions take so long to execute that the prefetch queue is always full when they finish, each shr should be ready and waiting in the prefetch queue when the preceding mul ends. As a result, we’d expect that each shr would execute in 2 cycles; together with the 118 cycle execution time of multiplying 0 times 0, the total execution time should come to 120 cycles per shr/mul pair, as shown in Figure 4.4. And, by God, when we run Listing 4-6 we get an execution time of 25.14 us per shr/mul pair, or exactly 120 cycles! According to these results, the “true” execution time of shr would seem to be 2 cycles, quite a change from the conclusion we drew from Listing 4-5.

The key point is this: we’ve seen one code sequence in which shr took 8-plus cycles to execute, and another in which it took only 2 cycles. Are we talking about two different forms of shr here? Of course not — the difference is purely a reflection of the differing states in which the preceding code left the prefetch queue. In Listing 4-5, each shr after the first few follows a slew of other shr instructions which have sucked the prefetch queue dry, so overall performance reflects instruction fetch time. By contrast, each shr in Listing 4-6 follows a mul instruction which leaves the prefetch queue full, so overall performance reflects Execution Unit execution time.

Clearly, either instruction fetch time or Execution Unit execution time — or even a mix of the two, if an instruction is partially prefetched — can determine code performance. Some people operate under a rule of thumb by which they assume that the execution time of each instruction is 4 cycles times the number of bytes in the instruction. While that’s often true for register-only code, it frequently doesn’t hold for code that accesses memory. For one thing, the rule should be 4 cycles times the number of memory accesses, not instruction bytes, since all accesses take 4 cycles. For another, memory-accessing instructions often have slower Execution Unit execution times than the 4 cycles per memory access rule would dictate, because the 8088 isn’t very fast at calculating memory addresses, as we’ll see in Chapter 7. Also, the 4 cycles per instruction byte rule isn’t true for register-only instructions that are already in the prefetch queue when the preceding instruction ends.

The truth is that it never hurts performance to reduce either the cycle count or the byte count of a given bit of code, but there’s no guarantee that one or the other will improve performance either. For example, consider Listing 4-7, which consists of a series of 4-cycle, 2-byte mov al,0 instructions, and which executes at the rate of 1.81 us per instruction. Now consider Listing 4-8, which replaces the 4-cycle mov al,0 with the 3-cycle (but still 2-byte) sub al,al. Despite its 1-cycle-per-instruction advantage, Listing 4-8 runs at exactly the same speed as Listing 4-7. The reason: both instructions are 2 bytes long, and in both cases it is the 8-cycle instruction fetch time, not the 3-or 4-cycle Execution Unit execution time, that limits performance.

As you can see, it’s easy to be drawn into thinking you’re saving cycles when you’re not. You can only improve the performance of a specific bit of code by reducing the factor - either instruction fetch time or execution time, or sometimes a mix of the two — that’s limiting the performance of that code.

In case you missed it in all the excitement, the variability of prefetching means that our method of testing performance by executing 1000 instructions in a row by no means produces “true” instruction execution times, any more than the official execution times in Appendix A are “true” times. The fact of the matter is that a given instruction takes at least as long to execute as the time given for it in Appendix A, but may take as much as 4 cycles per byte longer, depending on the state of the prefetch queue when the preceding instruction ends. The only true execution time for an instruction is a time measured in a certain context, and that time is meaningful only in that context.

Look at it this way. We’ve firmly established that there’s no number you can attach to a given instruction that’s always that instruction’s true execution time. In fact, as we’ll see in the rest of this chapter and in the next, there are other cycle-eaters that can work with the prefetch queue cycle-eater to cause the execution time of an instruction to vary to an even greater extent than we’ve seen so far. That’s okay, though, because the execution time of a single instruction is not what we’re really after.

What we really want is to know how long useful working code takes to run, not how long a single instruction takes, and the Zen timer gives us the tool we need to gather that information. Granted, it would be easier if we could just add up neatly documented instruction execution times — but that’s not going to happen. Without actually measuring the performance of a given code sequence, you simply don’t know how fast it is. For crying out loud, even the people who designed the 8088 at Intel couldn’t tell you exactly how quickly a given 8088 code sequence executes on the PC just by looking at it! Get used to the idea that execution times are only meaningful in context, learn the rules of thumb in this book, and use the Zen timer to measure your code.

Approximating Overall Execution Times

Don’t think that because overall instruction execution time is determined by both instruction fetch time and Execution Unit execution time, the two times should be added together when estimating performance. For example, practically speaking, each shr in Listing 4-5 does not take 8 cycles of instruction fetch time plus 2 cycles of Execution Unit execution time to execute. Figure 4.3 shows that while a given shr is executing, the fetch of the next shris starting, and since the two operations are overlapped for 2 cycles, there’s no sense in charging the time to both instructions. You could think of the extra instruction fetch time for shr in Listing 4-5 as being 6 cycles, which yields an overall execution time of 8 cycles when added to the 2 cycles of Execution Unit execution time.

Alternatively, you could think of each shr in Listing 4-5 as taking 8 cycles to fetch, and then executing in effectively 0 cycles while the next shr is being fetched. Whichever perspective you prefer is fine. The important point is that the time during which the execution of one instruction and the fetching of the next instruction overlap should only be counted toward the overall execution time of one of the instructions. For all intents and purposes, one of the two instructions runs at no performance cost whatsoever while the overlap exists.

As a working definition, we’ll consider the execution time of a given instruction in a particular context to start when the first byte of the instruction is sent to the Execution Unit and end when the first byte of the next instruction is sent to the EU. We’ll discuss this further in Chapter 5.

What to Do About the Prefetch Queue Cycle-Eater?

Reducing the impact of the prefetch queue cycle-eater is one of the overriding principles of high-performance assembler code. How can you do this? One effective technique is to minimize access to memory operands, since such accesses compete with instruction fetching for precious memory accesses. You can also greatly reduce instruction fetch time simply by your choice of instructions: keep your instructions short. Less time is required to fetch instructions that are 1 or 2 bytes long than instructions that are 5 or 6 bytes long. Reduced instruction fetching lowers minimum execution time (minimum execution time is 4 cycles times the number of instruction bytes) and often leads to faster overall execution.

While short instructions minimize overall prefetch time, they ironically actually often suffer relatively more from the prefetch queue bottleneck than do long instructions. Short instructions generally have such fast execution times that they drain the prefetch queue despite their small size. For example, consider the shr of Listing 4-5, which runs at only 25% of its Execution Unit execution time even though it’s only 2 bytes long, thanks to the prefetch queue bottleneck. Short instructions are nonetheless generally faster than long instructions, thanks to the combination of fewer instruction bytes and faster Execution Unit execution times, and should be used as much as possible — just don’t expect them to run at their documented speeds.

More than anything, the above rules mean using the registers as heavily as possible, both because register-only instructions are short and because they don’t perform memory accesses to read or write operands. (Using the registers is a topic we’ll return to repeatedly in The Zen of Assembly Language.) However, using the registers is a rule of thumb, not a commandment. In some circumstances, it may actually be faster to access memory. (The look-up table technique, which we’ll encounter in Chapter 7, is one such case.) What’s more, the performance of the prefetch queue (and hence the performance of each instruction) differs from one code sequence to the next, and can even differ during different executions of the same code sequence.

All in all, writing good assembler code is as much an art as a science. As a result, you should follow the rules of thumb described in The Zen of Assembly Language — and then time your code to see how fast it really is. You should experiment freely, but always remember that actual, measured performance is the bottom line.

The prefetch queue cycle-eater looms over the performance of all 8088 code. We’ll encounter it again and again in this book, and in every case it will make our code slower than it would otherwise be. An understanding of the prefetch queue cycle-eater provides deep insight into what makes some 8088 code much faster than other, seemingly similar 8088 code, and is a key to good assembler programming. You’ll never conquer this cycle-eater, but with experience and the Zen timer you can surely gain the advantage.

Holding Up the 8088

Over the last two chapters I’ve taken you further and further into the depths of the PC, telling you again and again that you must understand the computer at the lowest possible level in order to write good code. At this point, you may well wonder, “Have we gotten low enough?”

Not quite yet. The 8-bit bus and prefetch queue cycle-eaters are low-level indeed, but we’ve one level yet to go. Dynamic RAM refresh and wait states — our next topics — together form the lowest level at which the hardware of the PC affects code performance. Below this level, the PC is of interest only to hardware engineers.

Before we begin our discussion of dynamic RAM refresh, let’s step back for a moment to take an overall look at this lowest level of cycle-eaters. In truth, the distinctions between wait states and dynamic RAM refresh don’t much matter to a programmer. What is important is that you understand this: under certain circumstances devices on the PC bus can stop the 8088 for 1 or more cycles, making your code run more slowly than it seemingly should.

Unlike all the cycle-eaters we’ve encountered so far, wait states and dynamic RAM refresh are strictly external to the 8088, as shown in Figure 4.1. Adapters on the PC’s bus, such as video and memory cards, can insert wait states on any 8088 bus access, the idea being that they won’t be able to complete the access properly unless the access is stretched out. Likewise, the channel of the DMA controller dedicated to dynamic RAM refresh can request control of the bus at any time, although the 8088 must relinquish the bus before the DMA controller can take over. This means that your code can’t directly control wait states or dynamic RAM refresh. However, code can sometimes be designed to minimize the effects of these cycle-eaters, and even when the cycle-eaters slow your code without there being a thing in the world you can do about it, you’re still better off understanding that you’re losing performance and knowing why your code doesn’t run as fast as it’s supposed to than you were programming in ignorance.

Let’s start with DRAM refresh, which affects the performance of every program that runs on the PC.

How Dram Refresh Works in the Pc

Timer 1 of the 8253 timer chip is programmed at power-up to generate a signal once every 72 cycles, or once every 15.08 us. That signal goes to channel 0 of the 8237 DMA controller, which requests the bus from the 8088 upon receiving the signal. (DMA stands for direct memory access, the ability of a device other than the 8088 to control the bus and access memory directly, without any help from the 8088.) As soon as the 8088 is between memory accesses, it gives control of the bus to the 8237, which in conjunction with special circuitry on the PC’s motherboard then performs a single 4-cycle read access to 1 of 256 possible addresses, advancing to the next address on each successive access. (The read access is only for the purpose of refreshing the DRAM; the data read isn’t used.)

The 256 addresses accessed by the refresh DMA accesses are arranged so that taken together they properly refresh all the memory in the PC. By accessing one of the 256 addresses every 15.08 us, all of the PC’s DRAM is refreshed in:

3.86 ms = 256 x 15.08 us

just about the desired 4 ms time I mentioned earlier. (Only the first 640 Kb of memory is refreshed; video adapters and other adapters above 640 Kb containing memory that requires refreshing must provide their own DRAM refresh.)

Don’t sweat the details here. The important point is this: for at least 4 out of every 72 cycles, the PC’s bus is given over to DRAM refresh and is not available to the 8088, as shown in Figure 4.5. That means that as much as 5.56% of the PC’s already inadequate bus capacity is lost. However, DRAM refresh doesn’t necessarily stop the 8088 for 4 cycles. The Execution Unit of the 8088 can keep processing while DRAM refresh is occurring, unless the EU needs to access memory. Consequently, DRAM refresh can slow code performance anywhere from 0% to 5.56% (and actually a bit more, as we’ll see shortly), depending on the extent to which DRAM refresh occupies cycles during which the 8088 would otherwise be accessing memory.

The Impact of Dram Refresh

Let’s look at examples from opposite ends of the spectrum in terms of the impact of DRAM refresh on code performance. First, consider the series of mul instructions in Listing 4-9. Since a 16-bit mul executes in between 118 and 133 cycles and is only 2 bytes long, there should be plenty of time for the prefetch queue to fill after each instruction, even after DRAM refresh has taken its slice of memory access time. Consequently, the prefetch queue should be able to keep the Execution Unit well-supplied with instruction bytes at all times. Since Listing 4-9 uses no memory operands, the Execution Unit should never have to wait for data from memory, and DRAM refresh should have no impact on performance. (Remember that the Execution Unit can operate normally during DRAM refreshes so long as it doesn’t need to request a memory access from the Bus Interface Unit.)

Running Listing 4-9, we find that each mul executes in 24.72 us, or exactly 118 cycles. Since that’s the shortest time in which mul can execute, we can see that no performance is lost to DRAM refresh. Listing 4-9 clearly illustrates that DRAM refresh only affects code performance when a DRAM refresh forces the Execution Unit of the 8088 to wait for a memory access.

Now let’s look at the series of shr instructions shown in Listing 4-10. Since shr executes in 2 cycles but is 2 bytes long, the prefetch queue should be empty while Listing 4-10 executes, with the 8088 prefetching instruction bytes non-stop. As a result, the time per instruction of Listing 4-10 should precisely reflect the time required to fetch the instruction bytes.

Since 4 cycles are required to read each instruction byte, we’d expect each shr to execute in 8 cycles, or 1.676 us, if there were no DRAM refresh. In fact, each shr in Listing 4-10 executes in 1.81 us, indicating that DRAM refresh is taking 7.4% of the program’s execution time. That’s nearly 2% more than our worst-case estimate of the loss to DRAM refresh overhead! In fact, the result indicates that DRAM refresh is stealing not 4 but 5.33 cycles out of every 72 cycles. How can this be?

The answer is that a given DRAM refresh can actually hold up CPU memory accesses for as many as 6 cycles, depending on the timing of the DRAM refresh’s DMA request relative to the 8088’s internal instruction execution state. When the code in Listing 4-10 runs, each DRAM refresh holds up the CPU for either 5 or 6 cycles, depending on where the 8088 is in executing the current shr instruction when the refresh request occurs. Now we see that things can get even worse than we thought: DRAM refresh can steal as much as 8.33% of available memory access time — 6 out of every 72 cycles — from the 8088.

Which of the two cases we’ve examined reflects reality? While either can happen, the latter case — significant performance reduction, ranging as high as 8.33% — is far more likely to occur. This is especially true for high-performance assembler code, which uses fast instructions that tend to cause non-stop instruction fetching.

What to Do About the Dram Refresh Cycle-Eater?

Hmmm. When we discovered the prefetch queue cycle-eater, we learned to use short instructions. When we discovered the 8-bit bus cycle-eater, we learned to use byte-sized memory operands whenever possible, and to keep word-sized variables in registers. What can we do to work around the DRAM refresh cycle-eater?

Nothing.

As I’ve said before, DRAM refresh is an act of God. DRAM refresh is a fundamental, unchanging part of the PC’s operation, and there’s nothing you or I can do about it. If refresh were any less frequent, the reliability of the PC would be compromised, so tinkering with either timer 1 or DMA channel 0 to reduce DRAM refresh overhead is out. Nor is there any way to structure code to minimize the impact of DRAM refresh. Sure, some instructions are affected less by DRAM refresh than others, but how many multiplies and divides in a row can you really use? I suppose that code could conceivably be structured to leave a free memory access every 72 cycles, so DRAM refresh wouldn’t have any effect. In the old days when code size was measured in bytes, not K bytes, and processors were less powerful — and complex — programmers did in fact use similar tricks to eke every last bit of performance from their code. When programming the PC, however, the prefetch queue cycle-eater would make such careful code synchronization a difficult task indeed, and any modest performance improvement that did result could never justify the increase in programming complexity and the limits on creative programming that such an approach would entail. There’s no way around it: useful code accesses memory frequently and at irregular intervals, and over the long haul DRAM refresh always exacts its price.

If you’re still harboring thoughts of reducing the overhead of DRAM refresh, consider this. Instructions that tend not to suffer very much from DRAM refresh are those that have a high ratio of execution time to instruction fetch time, and those aren’t the fastest instructions of the PC. It certainly wouldn’t make sense to use slower instructions just to reduce DRAM refresh overhead, for it’s total execution time — DRAM refresh, instruction fetching, and all — that matters.

The important thing to understand about DRAM refresh is that it generally slows your code down, and that the extent of that performance reduction can vary considerably and unpredictably, depending on how the DRAM refreshes interact with your code’s pattern of memory accesses. When you use the Zen timer and get a fractional cycle count for the execution time of an instruction, that’s often DRAM refresh at work. (The display adapter cycle-eater is another possible culprit.) Whenever you get two timing results that differ less or more than they seemingly should, that’s usually DRAM refresh too. Thanks to DRAM refresh, variations of up to 8.33% in PC code performance are par for the course.

The Display Adapter Cycle-Eater

Display adapters must serve two masters, and that creates a fundamental performance problem. Master #1 is the circuitry that drives the display screen. This circuitry must constantly read display memory in order to obtain the information used to draw the characters or dots displayed on the screen. Since the screen must be redrawn between 50 and 70 times per second, and since each redraw of the screen can require as many as 36,000 reads of display memory (more in Super-VGA modes), master #1 is a demanding master indeed. No matter how demanding master #1 gets, though, its needs must always be met — otherwise the quality of the picture on the screen would suffer.

Master #2 is the 8088, which reads from and writes to display memory in order to manipulate the bytes that the video circuitry reads to form the picture on the screen. Master #2 is less important than master #1, since the 8088 affects display quality only indirectly. In other words, if the video circuitry has to wait for display memory accesses, the picture will develop holes, snow, and the like, but if the 8088 has to wait for display memory accesses, the program will just run a bit slower — no big deal.

It matters a great deal which master is more important, for while both the 8088 and the video circuitry must gain access to display memory, only one of the two masters can read or write display memory at any one time. Potential conflicts are resolved by flat-out guaranteeing the video circuitry however many accesses to display memory it needs, with the 8088 waiting for whatever display memory accesses are left over.

It turns out that the 8088 has to do a lot of waiting, for three reasons. First, the video circuitry can take as much as about 90% of the available display memory access time, as shown in Figure 4.7, leaving as little as about 10% of all display memory accesses for the 8088. (These percentages vary considerably among the many EGA and VGA clones.)

Second, because dots (or pixels, short for “picture elements”) must be drawn on the screen at a constant speed, display adapters can provide memory accesses only at fixed intervals. As a result, time can be lost while the 8088 synchronizes with the start of the next display adapter memory access, even if the video circuitry isn’t accessing display memory at that time, as shown in Figure 4.8.

Finally, the time it takes a display adapter to complete a memory access is related to the speed of the clock which generates pixels on the screen rather than to the memory access speed of the 8088. Consequently, the time taken for display memory to complete an 8088 read or write access is often longer than the time taken for system memory to complete an access, even if the 8088 lucks into hitting a free display memory access just as it becomes available, again as shown in Figure 4.8. Any or all of the three factors I’ve described can result in wait states, slowing the 8088 and creating the display adapter cycle-eater.

If some of this is Greek to you, don’t worry. The important point is that display memory is not very fast compared to normal system memory. How slow is it? Incredibly slow. Remember how slow the PCjr was? In case you’ve forgotten, I’ll refresh your memory: the PCjr was at best only half as fast as the PC. The PCjr had an 8088 running at 4.77 MHz, just like the PC — why do you suppose it was so much slower? I’ll tell you why: all the memory in the PCjrwas display memory.

Enough said.

All the memory in the PC is not display memory, however, and unless you’re thickheaded enough to put code in display memory, the PC isn’t going to run as slowly as a PCjr. (Putting code or other non-video data in unused areas of display memory sounds like a neat idea — until you consider the effect on instruction prefetching of cutting the 8088’s already-poor memory access performance in half. Running your code from display memory is sort of like running on the hypothetical 8084 — an 8086 with a 4-bit bus. Not recommended!) Given that your code and data reside in normal system memory below the 640 K mark, how great an impact does the display adapter cycle-eater have on performance?

The answer varies considerably depending on what display adapter and what display mode we’re talking about. The display adapter cycle-eater is worst with the Enhanced Graphics Adapter (EGA) and the Video Graphics Array (VGA). While the Color/Graphics Adapter (CGA), Monochrome Display Adapter (MDA), and Hercules Graphics Card (HGC) all suffer from the display adapter cycle-eater as well, they suffer to a lesser degree. Since the EGA and particularly the VGA represent the standard for PC graphics now and for the foreseeable future, and since those are the hardest graphics adapter to wring performance from, we’ll restrict our discussion to the EGA and VGA for the remainder of this chapter.

The Impact of the Display Adapter Cycle-Eater

Even on the EGA and VGA, the effect of the display adapter cycle-eater depends on the display mode selected. In text mode, the display adapter cycle-eater is rarely a major factor. It’s not that the cycle-eater isn’t present; however, a mere 4000 bytes control the entire text mode display, and even with the display adapter cycle-eater it just doesn’t take that long to manipulate 4000 bytes. Even if the display adapter cycle-eater were to cause the 8088 to take as much as 5 us per display memory access — more than ten times normal — it would still take only:

40 ms = 4000 x 2 x 5 us

to read and write every byte of display memory. That’s a lot of time as measured in 8088 cycles, but it’s less than the blink of an eye in human time, and video performance only matters in human time. After all, the whole point of drawing graphics is to convey visual information, and if that information can be presented faster than the eye can see, that is by definition fast enough.

That’s not to say that the display adapter cycle-eater can’t matter in text mode. In Chapter 2 I recounted the story of a debate among letter-writers to a magazine about exactly how quickly characters could be written to display memory without causing snow. The writers carefully added up Intel’s instruction cycle times to see how many writes to display memory they could squeeze into a single horizontal retrace interval. (On a CGA, it’s only during the short horizontal retrace interval and the longer vertical retrace interval that display memory can be accessed in 80-column text mode without causing snow.) Of course, now we know that their cardinal sin was to ignore the prefetch queue; even if there were no wait states, their calculations would have been overly optimistic. There are display memory wait states as well, however, so the calculations were not just optimistic but wildly optimistic.

Text mode situations such as the above notwithstanding, where the display adapter cycle-eater really kicks in is in graphics mode, and most especially in the high-resolution graphics modes of the EGA and VGA. The problem here is not that there are necessarily more wait states per access in high-resolution graphics modes (that varies from adapter to adapter and mode to mode). Rather, the problem is simply that are many more bytes of display memory per screen in these modes than in lower-resolution graphics modes and in text modes, so many more display memory accesses — each incurring its share of display memory wait states — are required in order to draw an image of a given size. When accessing the many thousands of bytes used in the high-resolution graphics modes, the cumulative effects of display memory wait states can seriously impact code performance, even as measured in human time.

For example, if we assume the same 5 us per display memory access for the EGA’s high-res graphics mode that we assumed for text mode, it would take:

260 ms = 26,000 x 2 x 5 us

to scroll the screen once in the EGA’s hi-res graphics mode, mode 10h. That’s more than one-quarter of a second — noticeable by human standards, an eternity by computer standards.

That sounds pretty serious, but we did make an unfounded assumption about memory access speed. Let’s get some hard numbers. Listing 4-11 accesses display memory at the 8088’s maximum speed, by way of a rep movsw with display memory as both source and destination. The code in Listing 4-11 executes in 3.18 us per access to display memory — not as long as we had assumed, but a long time nonetheless.

For comparison, let’s see how long the same code takes when accessing normal system RAM instead of display memory. The code in Listing 4-12, which performs a rep movsw from the code segment to the code segment, executes in 1.39 us per display memory access. That means that on average 1.79 us (more than 8 cycles!) are lost to the display adapter cycle-eater on each access. In other words, the display adapter cycle-eater can more than double the execution time of 8088 code!

Bear in mind that we’re talking about a worst case here; the impact of the display adapter cycle-eater is proportional to the percent of time a given code sequence spends accessing display memory. A line-drawing subroutine, which executes perhaps a dozen instructions for each display memory access, generally loses less performance to the display adapter cycle-eater than does a block-copy or scrolling subroutine that uses rep movs instructions. Scaled and three-dimensional graphics, which spend a great deal of time performing calculations (often using very slow floating-point arithmetic), tend to suffer still less.

In addition, code that accesses display memory infrequently tends to suffer only about half of the maximum display memory wait states, because on average such code will access display memory halfway between one available display memory access slot and the next. As a result, code that accesses display memory less intensively than the code in Listing 4-11 will on average lose 4 or 5 rather than 8-plus cycles to the display adapter cycle-eater on each memory access.

Nonetheless, the display adapter cycle-eater always takes its toll on graphics code. Interestingly, that toll becomes relatively much higher on ATs and 80386 machines, because while those computers can execute many more instructions per microsecond than can the PC, it takes just as long to access display memory on those computers as on the PC. Remember, the limited speed of access to a graphics adapter is an inherent characteristic of the adapter, so the fastest computer around can’t access display memory one iota faster than the adapter will allow. We’ll discuss this further in Chapter 15.

What to Do About the Display Adapter Cycle-Eater?

What can we do about the display adapter cycle-eater? Well, we can minimize display memory accesses whenever possible. In particular, we can try to avoid read/modify/write display memory operations of the sort used to mask individual pixels and clip images. Why? Because read/modify/write operations require two display memory accesses (one read and one write) each time display memory is manipulated. Instead, we should try to use writes of the sort that set all the pixels in a given byte of display memory at once, since such writes don’t require accompanying read accesses. The key here is that only half as many display memory accesses are required to write a byte to display memory as are required to read a byte from display memory, mask part of it off and alter the rest, and write the byte back to display memory. Half as many display memory accesses means half as many display memory wait states.

Along the same line, the display adapter cycle-eater makes the popular exclusive-or animation technique, which requires paired reads and writes of display memory, less-than-ideal for the PC. Exclusive-or animation should be avoided in favor of simply writing images to display memory whenever possible, as we’ll see in Chapter 11.

Another principle for display adapter programming is to perform multiple accesses to display memory very rapidly, in order to make use of as many of the scarce accesses to display memory as possible. This is especially important when many large images need to be drawn quickly, since only by using virtually every available display memory access can many bytes be written to display memory in a short period of time. Repeated string instructions are ideal for making maximum use of display memory accesses; of course, repeated string instructions can only be used on whole bytes, so this is another point in favor of modifying display memory a byte at a time.

These concepts certainly need examples and clarification, along with some working code; that’s coming up in Volume II of The Zen of Assembly Language. Why not now? Well, in Volume II we’ll be able to devote a whole chapter to display adapter programming, and by that point we’ll have the benefit of an understanding of the flexible mind, which is certainly a plus for this complex topic.

For now, all you really need to know about the display adapter cycle-eater is that you can lose more than 8 cycles of execution time on each access to display memory. For intensive access to display memory, the loss really can be as high as 8-plus cycles, while for average graphics code the loss is closer to 4 cycles; in either case, the impact on performance is significant. There is only one way to discover just how significant the impact of the display adapter cycle-eater is for any particular graphics code, and that is of course to measure the performance of that code.

If you’re interested in the detailed operation of the display adapter cycle-eater, I suggest you read my article, “The Display Adapter Bottleneck,” in the January, 1987 issue of PC Tech Journal.

Cycle-Eaters by the Battalion

Taken individually the cycle-eaters are formidable, as we saw in the last chapter. Cycle-eaters don’t line up neatly and occur one at a time, though. They’re like the proverbial 900-pound gorilla — they occur whenever they want. Frequently one cycle-eater will occur during the course of another cycle-eater, with compound (and complex) effects.

For example, it’s perfectly legal to put code in display memory and execute that code. However, as the instruction bytes of that code are fetched they’ll be subjected to the display adapter cycle-eater, meaning that each instruction byte could easily take twice as long as usual to fetch. Naturally, this will worsen the already serious effects of the prefetch queue cycle-eater. (Remember that the prefetch queue cycle-eater is simply the inability of the 8088 to fetch instruction bytes quickly enough.) In this case, the display adapter and prefetch queue cycle-eaters together could make overall execution times five to ten times longer than the times listed in Appendix A!

As another example, the DRAM refresh and 8-bit bus cycle-eaters can work together to increase the variability of code performance. When DRAM refresh occurs during an instruction that accesses a word-sized memory operand, the instruction’s memory accesses are held up until the DRAM refresh is completed. However, the exact amount by which the instruction’s accesses are delayed (and which access is delayed, as well) depends on exactly where in the course of execution the instruction was when the DRAM refresh came along. If the DRAM refresh happens just as the 8088 was about to begin a bus access, the 8088 can be held up for a long time. If, however, the DRAM refresh happens while the 8088 is performing internal operations, such as address calculations or instruction decoding, the impact on performance will be less.

The point is not, Lord knows, that you should understand how every cycle-eater affects every other cycle-eater and how together and separately they affect each instruction in your code. Quite the opposite, in fact. I certainly don’t understand all the interactions between cycle-eaters and code performance, and frankly I don’t ever expect (or want) to. Rather, what I’m telling you (again) is that a complete understanding of the performance of a given code sequence is so complex and varies so greatly with context that there’s no point worrying about it. As a result, high-performance assembler code comes from programming by intuition and experience and then measuring performance, not from looking up execution times and following rigid rules. In a way that’s all to the good: experienced, intuitive assembler programmers are worth a great deal, because no compiler can rival a good assembler programmer’s ability to deal with cycle-eaters and the complexity of code execution on the 8088.

One fallout of the near-infinite variability of code performance is that the exact performance of a given instruction is for all intents and purposes undefined. There are so many factors affecting performance, and those factors can vary so easily with time and context, that there’s just no use to trying to tag a given instruction with a single execution time. In other words…

Cycles in the Life of a Pc

Next, we’re going to examine every detail of instruction execution on the PC over a period of 170 cycles. One reason for doing this is to convince any of you who may still harbor the notion that there must be some way to come up with hard-and-fast execution times that you’re on a fool’s quest. Another reason is to illustrate many of the concepts we’ve developed over the last two chapters.

A third reason is simple curiosity. We’ll spend most of this book measuring instruction execution times and inferring how cycle-eaters and instruction execution are interacting. Why not take a look at the real thing? It won’t answer any fundamental questions, but it will give us a feel for what’s going on under the programming interface.

The Test Set-Up

The code we’ll observe is shown in Listing 5-1. This code is an endless loop in which the value stored in the variable i is copied to the variable j over and over by way of AH. The DS: override prefixes on the variables, while not required, make it clear that both variables are accessed by way of DS.

The detailed performance of the code in Listing 5-1 was monitored with the logic analyzer capability of the OmniLab multipurpose electronic test instrument manufactured by Orion Instruments. (Not coincidentally, I was part of the team that developed the OmniLab software.) OmniLab’s probes were hooked up to a PC’s 8088 and bus, Listing 5-1 was started, and a snapshot of code execution was captured and studied.

By the way, OmniLab, a high-performance but relatively low-priced instrument, costs (circa 1989) about $9,000. Money is one reason why you probably won’t want to analyze code performance in great detail yourself!

The following lines of the 8088 were monitored with OmniLab: the 16 lines that carry addresses, 8 of which also carry data, the READY line (used to hold the 8088 up during DRAM refresh), and the QS1 and QS0 lines (which signal transfers of instruction bytes from the prefetch queue to the Execution Unit). The /MEMR and /MEMW lines on the PC bus were monitored in order to observe memory accesses. The 8088 itself provides additional information about bus cycle timing and type, but the lines described above will show us program execution in plenty of detail for our purposes.

Odds are that you, the reader, are not a hardware engineer. After all, this is a book about software, however far it may seem to stray at times. Consequently, I’m not going to show the execution of Listing 5-1 in the form of the timing diagrams of which hardware engineers are so fond. Timing diagrams are fine for observing the state of a single line, but are hard to follow at an overall level, which is precisely what we want to see. Instead, I’ve condensed the information I collected with OmniLab into an event time-line, shown in Figure 5.1.

The Results

Figure 5.1 shows 170 consecutive 8088 cycles. To the left of the cycle time-line Figure 5.1 shows the timing of instruction byte transfers from the prefetch queue to the Execution Unit. This information was provided by the QS1 and QS0 pins of the 8088. To the right of the cycle time-line Figure 5.1 shows the timing of bus read and write accesses. The timing of these accesses was provided by the /MEMR and /MEMW lines of the PC bus, and the data and addresses were provided by the address/data lines of the 8088. One note for the technically oriented: since bus accesses take 4 cycles from start to finish, I considered the read and write accesses to complete on the last cycle during which /MEMR or /MEMW was active.

Take a minute to look Figure 5.1 over, before we begin our discussion. Bear in mind that Figure 5.1 is actually a simplified, condensed version of the information that actually appeared on the 8088’s pins. In other words, if you choose to analyze cycle-by-cycle performance yourself, the data will be considerably harder to interpret than Figure 5.1!

Code Execution Isn’t All That Exciting

The first thing that surely strikes you about Figure 5.1 is that it’s awfully tedious, even by assembler standards. During the entire course of the figure only seven instructions are executed — not much to show for all the events listed. The monotony of picking apart code execution is one reason why such a detailed level of understanding of code performance isn’t desirable.

The 8088 Really Does Coprocess

The next notable aspect of Figure 5.1 is that you can truly see the two parts of the 8088 — the Execution Unit and the Bus Interface Unit — coprocessing. The left side of the time-line shows the times at which the EU receives instruction bytes to execute, indicating the commencement and continuation of instruction execution. The right side of the time-line shows the times at which the BIU reads or writes bytes from or to memory, indicating instruction fetches and accesses to memory operands.

The two sides of the time-line overlap considerably. For example, at cycle 10 the EU receives the opcode byte of mov ds:[j],ah from the prefetch queue at the same time that the BIU prefetches the mod-reg-rm byte for the same instruction. (We’ll discuss mod-reg-rm bytes in detail in Chapter 7.) Clearly, the two parts of the 8088 are processing independently during cycle 10.

The EU and BIU aren’t always able the process independently, however. The EU spends a considerable amount of time waiting for the BIU to provide the next instruction byte, thanks to the prefetch queue cycle-eater. This is apparent during cycles 129 through 135, where the EU must wait 6 cycles for the mod-reg-rm byte of mov ah,ds:[i] to arrive. Back at cycle 84, the EU only had to wait 1 cycle for the same byte to arrive. Why the difference?

The difference is the result of the DRAM refresh that occurred at cycle 118, preempting the bus and delaying prefetching so that the mod-reg-rm byte of mov ah,ds:[i] wasn’t available until cycle 135. What’s particularly interesting is that this variation occurs even though the sequence of instructions is exactly the same at cycle 83 as at cycle 129. In this case, it’s the DRAM refresh cycle-eater that causes identical instructions in identical code sequences to execute at different speeds. Another time, it might be the display adapter cycle-eater that causes the variation, or the prefetch queue cycle-eater, or a combination of the three. This is an important lesson in the true nature of code execution: the same instruction sequence may execute at different speeds at different times.

When Does an Instruction Execute?

One somewhat startling aspect of Figure 5.1 is that it makes it clear that there is no such thing as the time interval during which a given instruction — and only that instruction — executes. There is the time at which a given byte of an instruction is prefetched, there is a time at which a given byte of an instruction is sent to the EU, and there is a time at which each memory operand byte of an instruction is accessed. None of those times really marks the start or end of an instruction, though, and the instruction fetches and memory accesses of one instruction usually overlap those of other instructions.

Figure 5.2 illustrates the full range of action of each of the instructions in Figure 5.1. (In Figure 5.2, and in Figure 5.3 as well, the two sides of the time-line are equivalent; there is no specific meaning to text on, say, the left side as there is in Figure 5.1. I simply alternate sides in order to keep one instruction from running into the next.)

For example, at cycle 143 the last instruction byte of mov ah,ds:[i] is sent to the EU. At cycle 144 the opcode of the next instruction, mov ds:[j],ah, is prefetched. Not until cycle 150 is the operand of mov ah,ds:[i] read, and not until cycle 154 is the opcode byte of mov ds:[j],ah sent to the EU. Which instruction is executing between cycles 143 and 154?

It’s easiest to consider execution to start when the opcode byte of an instruction is sent to the EU and end when the opcode byte of the next instruction is sent to the EU, as shown in Figure 5.3.

Under this approach, the current instruction is charged with any instruction fetch time for the opcode byte of the next instruction that isn’t overlapped with EU execution of the current instruction. This is consistent with our conclusion in Chapter 4 that execution time is, practically speaking, EU execution time plus any instruction fetch time that’s not overlapped with the EU execution time of another instruction. Therefore, mov ah,ds:[i] executes during cycles 129 through 153.r

In truth, though, the first hint of mov ah,ds:[i] occurs at cycle 122, when the opcode byte is fetched. In fact, since read accesses to memory take 4 cycles, the 8088 must have begun fetching the opcode byte earlier still. Figure 5.2 assumes that the 8088 starts bus accesses 2 cycles before the cycle during which /MEMR or /MEMW becomes inactive. That assumption may be off by a cycle, but none of our conclusions would be altered if that were the case. Consequently, the instruction mov ah,ds:[i] occupies the attention of at least some part of the 8088 from around cycle 120 up through cycle 153, or 34 cycles, as shown in Figure 5.2.

Figure 5.3 shows that mov ah,ds:[i] doesn’t take 34 cycles to execute, however. The instruction fetching that occurs during cycles 120 through 128 is overlapped with the execution of the preceding instruction, so those cycles aren’t counted against the execution time of mov ah,ds:[i]. The instruction does take 25 cycles to execute, though, illustrating the power of the cycle-eaters: according to Appendix A, mov ah,ds:[i] should execute in 14 cycles, so just two of the cycle-eaters, the prefetch queue and DRAM refresh, have nearly doubled the actual execution time of the instruction in this context.

Variability

This brings us to an excellent illustration of the variability of performance, even for the same instruction in the same code sequence executing at different times. As we just discovered, the mov ah,ds:[i] instruction that starts at cycle 129 takes 25 cycles to execute. However, the same instruction starting at cycle 33 takes 27 cycle to execute. Starting at cycle 83, mov ah,ds:[i] takes just 21 cycles to execute. That’s three significantly different times for the same instruction executing in the same instruction sequence!

How can this be? In this case it’s the DRAM refresh cycle-eater that’s stirring things up by periodically holding up 8088 bus accesses for 4 cycles or more. This alters the 8088’s prefetching and memory access sequence, with a resultant change in execution time. As we discussed earlier, the DRAM refresh read at cycle 118 takes up valuable bus access time, keeping the 8088 from fetching the mod-reg-rm byte of mov ah,ds:[i] ahead of time and thereby pushing the succeeding bus accesses a few cycles later in time.

The DRAM refresh and display adapter cycle-eaters can cause almost any code sequence to vary in much the same way over time. That’s why the Zen timer reports fractional times. It is also the single most important reason why a micro-analysis of code performance of the sort done in Figure 5.1 is not only expensive and time-consuming but also pointless. If a given instruction following the same sequence of instructions can vary in performance by 20%, 50%, 100% or even more from one execution to the next, what sort of performance number can you give that instruction other than as part of the overall instruction sequence? What point is there in trying to understand the instruction’s exact performance during any one of those executions?

The answer, briefly stated, is: no point at all.

You Never Know Unless You Measure (In Context!)

I hope I’ve convinced you that the actual performance of 8088 code is best viewed as the interaction of many highly variable forces, the net result of which is measurable but hardly predictable. But just in case I haven’t, consider this…

Figure 5.1 illustrates the execution of one of the simplest imaginable code sequences. The exact pattern of code execution repeats after 144 cycles, so even with DRAM refresh we have an execution pattern that repeats after only 6 instructions. That’s not likely to be the case with real code, which rarely features the endless alternation of two instructions. In real code the code mix changes endlessly, so DRAM refresh and the prefetch queue cycle-eater normally result in a far greater variety of execution sequences than in Figure 5.1.

Also, only two of the four cycle-eaters are active in Figure 5.1. Since Listing 5-1 uses no word-sized operands, the 8-bit bus cycle-eater has no effect other than slowing instruction prefetching. Likewise, Listing 5-1 doesn’t access display memory, so the display adapter cycle-eater doesn’t affect performance. Imagine if we threw those cycle-eaters into Figure 5.1 as well!

Worse still, in the real world interrupts occur often and asynchronously, flushing the prefetch queue and often changing the fetching, execution, and memory operand access patterns of whatever code happens to be running. Most notable among these interrupts is the timer interrupt, which occurs every 54.9 ms. Because the timer interrupt may occur after any instruction and doesn’t always take the same amount of time, it can cause execution to settle into new patterns. For example, after I captured the sequence shown in Figure 5.1 I took another snapshot of the execution of Listing 5-1. The second snapshot did not match the first. The timer interrupt had kicked execution into a different pattern, in which the same instructions were executed, with the same results — but not at exactly the same speeds.

Other interrupts, such as those from keyboards, mice, and serial ports, can similarly alter program performance. Of course, interrupts and cycle-eaters don’t change the effects of code — add ax,1 always adds 1 to AX, and so on — but they can drastically change the performance of a given instruction in a given context. That’s why we focus on the overall performance of code sequences in context, as measured with the Zen timer, rather than on the execution times of individual instructions.

The Longer the Better

Now is a good time to point out that the longer the instruction sequence you measure, the less variability you’ll normally get from one execution to the next. Over time, the perturbations caused by the DRAM refresh cycle-eater tend to average out, since DRAM refresh occurs on a regular basis. Similarly, a lengthy code sequence that accesses display memory multiple times will tend to suffer a fairly consistent loss of performance to the display adapter cycle-eater. By contrast, a short code sequence that accesses display memory just once may vary greatly in performance from one run to the next, depending on how many wait states occur on the one access during a given run.

In short, you should time either long code sequences or repeated executions of shorter code sequences. While there’s no strict definition of “long” in this context, the effects of the DRAM refresh and display adapter cycle-eaters should largely even out in sequences longer than about 100 us. While you can certainly use the Zen timer to measure shorter intervals, you should take multiple readings in such cases to make sure that the variations the cycle-eaters can cause from one run to the next aren’t skewing your readings.

Odds and Ends

There are a few more interesting observations to be made about Figure 5.1. For one thing, we can clearly see that while bus accesses are sometimes farther apart than 4 cycles, they are never any closer together. This confirms our earlier observation that bus cycles take a minimum of 4 cycles.

On the other hand, instruction bytes can be transferred from the prefetch queue to the Execution Unit at a rate of 1 byte per cycle when the EU needs them that quickly. This reinforces the notion that the EU can use up instruction bytes faster than the BIU can fetch them. In fact, we can see the EU waiting for an instruction byte fetch from cycle 130 to cycle 135, as discussed earlier. It’s worth noting that after the instruction byte transfer to the EU at cycle 135, the next two instruction byte transfers occur at cycles 139 and 143, each occurring 4 cycles after the previous transfer. That mimics the 4 cycles separating the fetches of those instruction bytes, and that’s no coincidence. During these cycles the EU does nothing but wait for the BIU to fetch instruction bytes — the most graphic demonstration yet of the prefetch queue cycle-eater.

The prefetch queue cycle-eater can be observed in another way in Figure 5.1. A careful reading of Figure 5.1 will make it apparent that the prefetch queue never contains more than 2 bytes at any time. In other words, the prefetch queue not only never fills, it never gets more than 2 bytes ahead of the Execution Unit. Moreover, we can see at cycles 33 and 34 that the EU can empty those 2 bytes from the prefetch queue in just 2 cycles. There’s no doubt but what the BIU often fights a losing battle in trying to keep the EU supplied with instruction bytes.

The AX register

The AX register is the l6-bit accumulator. The lower byte of AX can be accessed as the AL register, which is the 8-bit accumulator; the upper byte of AX can be accessed as the AH register, which is not an accumulator of any sort. The accumulator is always both one of the source operands and the destination for multiply and divide instructions. The accumulator must also be the source for out instructions and the destination for in instructions, and is the source or destination register for the string instructions lods, stos, and scas, as we’ll see in Chapter 10. There are special instructions for sign-extending the accumulator to larger data types; cbw for converting a signed byte in AL to a signed word in AX, and cwd for converting a signed word in AX to a signed doubleword in DX:AX. Finally, there are a number of accumulator-specific instructions that are particularly efficient; we’ll discuss those instructions in Chapters 8 and 9.

There are several instructions that use part or all of the AX register in odd ways. In Chapter 7 we’ll discuss xlat, the only instruction that can use AL for memory addressing. In Chapter 8 we’ll discuss lahf and sahf, which transfer the lower byte of the flags register to and from AH. In Chapter 8 we’ll also discuss a special form of xchg that requires that AX be one operand. Finally, the decimal- and ASCII-adjust instructions — aaa, aad, aam, aas, daa, and das — alter AL or AX in specific ways to compensate for the effects of ASCII or BCD arithmetic. These instructions are so different from the other members of the 8088 instruction set that we’ll defer further discussion of them until Chapter 9.

The BX register

The BX register is the only register among the dual 8/16-bit registers that can be used for memory addressing (with the sole exception of AL in the case of xlat). The lower byte of BX is accessible as BL and the upper byte is accessible as BH; neither BH nor BL alone can be used for memory addressing.

Like the other general-purpose registers, BX (or BH or BL) may serve as an operand to any instruction that uses mod-reg-rm addressing. In addition, BX (but not BH or BL) can be used as a base register for memory addressing. That is, the contents of BX can be used to generate the address of a memory operand, as discussed in the next chapter, by any instruction that uses mod-reg-rm addressing, and by xlat as well.

The CX register

The CX register is designed for specialized counting purposes. The lower byte of CX is accessible as CL and the upper byte as CH; CL can be used for certain specialized 8-bit counting purposes, but CH cannot. CX is used as a counter by the loop, loopz, loopnz, and jcxz instructions, which we’ll look at in Chapter 14, and is also used as a counter by the string instructions when they’re used with the rep prefix, as we’ll see in Chapter 10, CL can be used to specify a rotation or shift count for any of the rotate or shift instructions, such asror, shl, and rcl, as described in Chapter 9.

The DX register

The DX register is the least specialized of the general-purpose registers; the only unique functions of DX are serving as the upper word of the destination on l6-bit by l6-bit multiplies, serving as the upper word of the source and the destination for the remainder on 32-bit by l6-bit divides, addressing I/O ports when used with in and out, and serving as the upper word of the destination for cbw. The lower byte of DX is accessible as DL, and the upper byte is accessible as DH.

The SI register

The SI register specializes as the source memory-addressing register for the string instructions lods and mob and as the destination memory-addressing register for the string instruction cmps, as we’ll see in Chapter 10.

Like the other general-purpose registers, SI may serve as an operand to any instruction that uses mod-reg-rm addressing. In addition, SI can be used as an index register for memory addressing by any instruction that uses mod-reg-rm addressing, as we’ll see in the next chapter, and, of course, by the above-mentioned string instructions as well.

The DI register

The DI register Specializes as the destination memory-addressing register for the string instructions stos and movs, and as the source memory-addressing register for the string instructions scas and cmps, as we’ll see in Chapter 10.

Like the other general-purpose registers, DI may serve as an operand to any instruction that uses mod-reg-rm addressing. In addition, DI can be used as an index register for memory addressing by any instruction that uses mod-reg-rm addressing, as we’ll see in the next chapter, and by the above-mentioned string instructions as well.

The BP register

The BP register specializes as the stack frame-addressing register. Like the other general-purpose registers, BP may serve as an operand to any instruction that uses mod-reg-rm addressing. Like BX, BP can also be used as a base register for memory addressing by any instruction that uses mod-reg-rm addressing, as discussed in the next chapter. However, while BX normally addresses the data segment, BP normally addresses the stack segment. This makes BP ideal for addressing parameters and temporary variables stored in stack frames, a topic to which we’ll return in the next chapter.

The SP register

The SP register is technically a general-purpose register, but in actual practice it almost always serves as the highly specialized stack pointer, and is rarely used as a general-purpose register. SP points to the offset of the top of the stack in the stack segment, and is automatically incremented and decremented as the stack is accessed via push, pop, call, ret, int, and iret instructions.

Like the other general-purpose registers, SP may serve as an operand to any instruction that uses mod-reg-rm addressing. In general, SP is modified through the above-mentioned stack-oriented instructions, but SP also may be subtracted from, added to, or loaded directly in order to allocate or deallocate a temporary storage block on the stack or switch to a new stack.

One note: never push SP directly, as in

push    sp

The reason is that the 80286 doesn’t handle the pushing of SP in quite the same way as the 8088 does; the 80286 pushes SP before decrementing it by 2, whereas the 8088 pushes SP after decrementing it. As a result, code that uses push sp may not work in the same way on all computers. In normal code you’ll rarely need to push SP, but if you do, you can simply pass the value through another register, as in

mov     ax,sp
push    ax

The above sequence will work exactly the same way on any 8086-family processor…

The CS register

The CS register points to the code segment, the 64-Kb block within which IP points to the offset of the next instruction byte to be executed. The CS:IP pair cannot ever point to the wrong place for even one instruction; if it did, an incorrect instruction byte would be fetched and executed next. Consequently, both CS and IP must be set whenever CS is changed, and the setting of both registers must be accomplished by a single instruction. Although CS can be pushed, copied to memory, or copied to a general-purpose register, it can’t be loaded directly from any of those sources. The only instructions that can load CS are the far versions of jmp, call and ret as well as int and iret, what all those instructions have in common is that they load both CS and IP at the same time. Both int and the far version of call push both CS and IP on the stack so that iret or ret can return to the instruction following the int or call.

In addition, segment override prefixes can be used to select CS as the segment accessed by many memory operands that normally access DS.

The DS register

The DS register points to the data segment, the segment within which most memory operands reside by default. (Note, however, that many memory-addressing instructions can access any of the four segments with the help of a segment override prefix.)

DS can be copied to or loaded from a memory operand, the stack, or a general-purpose register. It can also be loaded, along with any general- purpose register, from a doubleword operand with the lds instruction.

The ES register

The ES register points to the extra segment, the segment within which certain string instruction operands must reside. In addition, segment override prefixes can be used to select ES as the segment accessed by many memory operands that normally access DS.

ES can be copied to or loaded from a memory operand, the stack, or a general-purpose register. ES can also be loaded, along with any general-purpose register, from a doubleword operand with the les instruction.

The SS register

The SS register points to the stack segment, the segment within which SP points to the top of the stack. The instruction push stores its operand in the stack segment, and pop retrieves its operand from the stack segment. In addition, call, ret, int, and iret all access the stack Memory accesses performed with BP as a base register also default to accessing the stack segment. Finally, segment override prefixes can be used to select SS as the segment accessed by many memory operands that normally access DS.

Although SS can be loaded directly, like DS and ES, you must always remember that SS and SP operate as a pair and together must point to a valid stack whenever stack operations might occur. As discussed above, interrupts can occur at any time, so when you load SS, interrupts must be off until both SS and SP have been loaded to point to the new stack. Intel thoughtfully provided a feature designed to take care of such problems. Whenever you load a segment register via mov or pop, interrupts are automatically disabled until the following instruction has finished. For example, in the following code

mov   ss,dx
mov   sp,ax

interrupts are disabled from the start of the first mov until the end of the second. After the second mov, interrupts are again enabled or disabled as they were before the first mov, depending on the state of the interrupt flag.

Unfortunately, there was a bug in early 8088 chips that caused the automatic interrupt disabling described above to malfunction. Consequently, it’s safest to explicitly disable interrupts when loading SS:SP, as follows:

cli
mov   ss,dx
mov   sp,ax
sti

The Carry flag (CF)

The carry flag (CF for short) is set to 1 by additions that result in sums too large to fit in the destination and by subtractions that result in differences less than 0, and is set to 0 by arithmetic and logical operations that produce results small enough to fit in the destination when viewed as unsigned integers. (The logical operations and, or, and xor always set CF to 0, since they always produce results that fit in the destination.) Also, when a shift or rotate instruction shifts a bit out of an operand’s most significant bit (msb) or least significant bit (lsb), that bit is transferred to CF. As a special case, both the carry and overflow flags are set to 1 by multiplication, except when the result is small enough to fit in the lower half of the destination (considered as a signed number for imul and as an unsigned number for mul).

The primary purpose of CF is to support addition, subtraction, rotation, and shifting of multi-byte or multi-word operands. In these applications, CF conveys the msb or lsb of one 8- or 16-bit operation to the next operation, as for example in the 32-bit right shift

shr   dx,1  ;shift upper 16 bits
rcr   ax,1  ;shift lower 16 bits, including the bit
            ; shifted down from the upper 16 bits

Note that this makes CF the only flag that can participate directly in arithmetic operations.

CF can also be tested with the jc (which can be thought of as standing for “jump carry”) and the jnc (“jump no carry”) conditional jump instructions. The instruction jc is also known as both jb (“jump below”) and jnae (“jump not above or equal”). All three instructions assemble to the same machine code. Likewise, jnc is also known as both jae (“jump above or equal”) and jnb (“jump not below”). The carry and zero flags together can be tested with ja and jbe. ja is also known as jnbe (“jump not below or equal”), and jbe is also known as jna (“jump not above”). These conditional jumps are often used to determine unsigned greater than/less than/equal relationships between operands.

Alone among the six status flags , CF can be set, reset, and toggled directly with the clc (“clear carry”), stc (“set carry”), and cmc (“complement carry”) instructions. This can be useful for returning a status from a subroutine, or for modifying the action of ade, sbb, rei, or any other instruction that includes CF in its calculations.

Note that CF is not affected by inc or dec, although it is affected by add and sub. (We’ll see one use for this trait of inc and dec in Chapter 9.) Also, be aware that since neg is logically equivalent to subtracting an operand from 0, CF is always set by neg, except when the operand is 0. (Zero minus anything other than zero always causes borrow).

The Parity flag (PF)

The parity flag (PF for short) is set to 1 whenever the least significant byte of the result of an arithmetic or logical operation contains an even number of bits that are set to 1, and it is set to 0 whenever the least significant byte contains an odd number of bits that are 1.

PF can be tested only with the jp (“jump parity”) and jnp (“jump no parity”) conditional jump instructions. The instruction jp is also known as jpe (“jump parity even”), and jnp is also known as jpo (“jump parity odd”). Generally, PF is useful for generating and testing parity bits for data storage and transmission. Apart from that, I know of no good uses for PF, although such uses may well exist.

The Auxiliary Carry flag (AF)

The auxiliary carry flag (AF for short) is set to 1 if arithmetic or logical operation results in carry out of bit 3 of the destination and is set to 0 otherwise. Alone among the six status flags, AF cannot be tested by any conditional jump instruction. In fact, the only instructions that pay any attention at all to AF are aaa, aas, daa, and das, which use AF to help sort out the results of ASCII or BCD arithmetic. Apart from ASCII and BCD arithmetic, which we’ll discuss in Chapter 9, I’ve never found a use for AF.

The Zero flag (ZF)

The zero flag (ZF for short) is set to 1 if an arithmetic or logical operation produces a 0 result or to 0 otherwise. ZF is generally used to test for equality of two operands or for zero results via the jz (“jump zero”) and jnz (“jump not zero”) conditional jumps, also known as je (“jump equal”) and jne (“jump not equal”), respectively. As discussed above, ZF and CF can be tested together with a variety of conditional jumps. The zero, sign, and overflow flags together can be tested with jg (“jump greater”), also known as jnle (“jump not less or equal”) and with jle, also known as jng (“jump not greater”). These conditional jumps are often used to determine signed greater than/less than/equal relationships between operands.

The Sign flag (SF)

The sign flag (SF for short) is set to the state of the most significant bit of the result of an arithmetic or logical operation. For signed arithmetic, the most Significant bit is the sign of the operand, so an SF setting of 1 indicates a negative result.

SF is generally used to test for negative results via the js (“jump sign”) and jns (“jump no sign”) conditional jumps. As discussed above, the sign zero, and overflow flags together can be tested with jg and jle. The sign and overflow flags together can be tested with jl (“jump less”) and jge (“jump greater or equal”). The instruction jl is also known as jnge (“jump not greater or equal”) and jge is also known as jnl (“jump not less”).

The Overflow flag (OF)

The overflow flag (OF for short) is set to 1 if the carry into the most significant bit of the result of an operation and the carry out of that bit don’t match. Overflow indicates that the result, interpreted as a signed result, is too large to fit in the destination and is therefore not a valid signed result of the operation. (It may still be a valid unsigned result, however; CF is used to detect too large and too small unsigned results.) In short, OF is set to 1 if the result has overflowed (grown too large for) the destination in terms of signed arithmetic. I know of no use for OF other than in signed arithmetic. The logical operations and, or, and xor always set OF to 0.

OF can be tested in any of several ways. The jo (“jump overflow”) and jno (“jump no overflow”) instructions branch or don’t branch depending on the state of OF. As described above, the jl, jnl, jle, jnle, jg, jng, jge, and jnge instructions branch or don’t branch depending on the states of OF, SF, and sometimes ZF. Finally, the int instruction executes an int 4 if and only if OF is set.

The Interrupt flag (IF)

The interrupt flag (IF for short) enables and disables maskable hardware interrupts. When IF is 1, all hardware interrupts are recognized by the 8088. When IF is 0, maskable interrupts (that is, those interrupts signaled on the INTR pin) are not recognized until such time as IF is set to 1. (Nonmaskable interrupts — interrupts signaled on the NMI pin — are recognized by the 8088 regardless of the setting of IF, as are software interrupts, which are invoked with the int instruction.) IF is set to 1 (enabling interrupts) with sti and is set to 0 (disabling interrupts) with cli. IF is also automatically set to 0 when a hardware interrupt occurs or an int instruction is executed. In addition, as described in the discussion of the SS register above, interrupts are automatically disabled until the end of the following instruction whenever a segment register is loaded.

The PC is an interrupt-based computer, so interrupts should in general be disabled as infrequently and for as short a time as possible. System resources such as the keyboard and time-of-day clock are interrupt based and won’t function properly if interrupts are off for too long. You really only need to disable interrupts in code that could malfunction if it is interrupted, such as code that services time-sensitive hardware or code that uses multiple prefix bytes per instruction. (The latter, as discussed in Chapter 10, should be avoided whenever possible.)

Leave interrupts enabled at all other times.

The Direction flag (DF)

The direction flag (DF for short) controls the direction in which the pointer registers used by the string instructions (SI and DI) count. When DF is 1 (as set with std), string instruction pointer registers decrement after each memory access; when DF is 0 (as set with cld), string instruction pointer registers increment. We’ll discuss the direction flag in detail when we cover the string instructions in Chapter 10.

The Trap flag (TF)

The trap flag (TF for short) instructs the 8088 to execute a software interrupt 1 after the next instruction. This is specifically intended to allow debugging software to single-step through code; it has no other known use.

Square Brackets Mean Memory Addressing

The use of square brackets is optional when a memory location is being addressed by name. That is, the two following instructions assemble to exactly the same code:

mov   dx,MemVar
mov   dx,[MemVar]

However, addressing memory without square brackets is an extension of the “memory and registers are logically equivalent” mindset. I strongly recommend that you use square brackets on all memory references in order to keep the distinction between memory and registers clear in your mind. This practice also helps distinguish between immediate and memory operands.

Segment:Offset Pairs Aren’t Unique

In answer to question number two, “What’s to prevent more than one segment:offset pair from pointing to the same 20-bit address?” the answer is: nothing. There’s no rule that says two segment:offset pairs can’t point to the same address, and in fact many segment:offset pairs do evaluate to any given address — 4096 segment:offset pairs for every address, to be precise. For example, the following segment:offset pairs all point to the 20-bit address 00410: 0000:0410, 0001:0400, 0002:03F0, 0003:03E0, and so on up to 0041:0000.

You may have noticed that we’ve only accounted for 42h segment:offset pairs, not 4096 of them, and that leads in neatly to the answer to our third and final question. When the sum of a segment shifted left 4 bits and an offset exceeds 20 bits, it wraps back around to address 00000. Basically, any bits that carry out of bit 19 (into what would be bit 20 if the 8088 had 21 addressing bits) are thrown away. The segment:offset pair FFFF:0010 points to the address 00000 as follows:

   FFFF0
+   0010
--------
  100000
  ^
  carry

with the 1 that carries out of bit 19 discarded to leave 00000.

Now we can see what the other 4,000-odd segment:offset pairs that point to address 00410 are. FFFF:0420 points to 00410, as do FFFE:0430, F042:FFF0, and a host of segment:offset pairs in between. I doubt you’ll want to take advantage of that knowledge (in fact, there is a user-selectable trick that can be played on the 80286 and 80386 to disable wrapping at FFFFF, so you shouldn’t count on wrapping if you can help it), but if you do ever happen to address past the end of memory, that’s how it works on the 8088.

Good News and Bad News

Now that we know how segments and offsets work, what are the implications for assembler programs? The obvious implication is that we can address 1 Mb of memory, and that’s good news, since we can use memory in myriad ways to improve performance. For example, we’ll see how look-up tables can turn extra memory into improved performance later in this chapter. Likewise, in Chapter 13 we’ll see how in-line code lets you trade off bytes for performance. Much of top-notch assembler programming involves balancing memory requirements against performance, so the more memory we have available, the merrier.

The bad news is this: while there’s a lot of memory, it’s only available in 64 Kb chunks. The four segment registers can only point to four 64 Kb segments at any one time, as shown in Figure 7.2.

If you want to access a memory location that’s not in any of the four currently pointed-to segments, there is no way to do that with a single instruction. You must first load a segment register to point to a segment containing the desired memory location, a process which takes a minimum of 1 and often 2 instructions. Only then can you access the desired memory location.

Worse, there are problems dealing with blocks of memory larger than 64 Kb, because there’s no easy way to perform calculations involving full 20-bit addresses, and because 64 Kb is the largest block of memory that can be addressed by way of a single segment register without reloading the segment register. It’s easy enough to access a block up to 64 Kb in size; point a register to the start of the block, and then point wherever you wish. For example, the following bit of code would calculate the 16-bit sum of all the bytes in a 64 Kb array:

    mov   bx,seg TestArray
    mov   ds,bx               ;point to segment:offset of start of
    mov   bx,offset TestArray ;array to sum
    sub   cx,cx               ;count 64 K bytes
    mov   ax,cx               ;set initial sum to 0
    mov   dh,ah               ;set DH to 0 for summing later
SumLoop:
    mov   dl,[bx]             ;get the next array element
    add   ax,dx               ;add the array element to the sum
    inc   bx                  ;point to the next array element
    loop  SumLoop

Easy enough, eh? Ah, but it all falls apart when a block of memory is larger than 64 Kb, or when a block crosses a segment boundary. The problem is that in either of those cases the segment must change as well as the offset, for there’s simply no way for an offset to reach more than 64 K bytes away from any given segment register setting. If a register containing an offset reaches the end of a segment (reaches the value 0FFFFh), then it simply wraps back to zero when it’s incremented. Likewise, the instruction sequence:

mov   si,0ffffh
mov   al,[si+1]

merely manages to load AL with the contents of offset 0. Basically, whenever an offset exceeds 16 bits in size, the excess bits are ignored, just as the excess bits are ignored when a segment:offset pair adds up to an address past the 1 Mb overall limit on 8088 memory.

So we need to work with the whole segment:offset pair in order to handle blocks larger than 64 Kb. Is that such a problem? Unfortunately, the answer is yes. The 8088 has no particular aptitude for calculations involving more than 16 bits, and is very bad at handling segments. There’s no way to increment a segment:offset pair as a unit, and in fact there’s no way to modify a segment register other than copying it to a general-purpose register, modifying that register, and copying the result back to the segment register. All in all, it’s as difficult to work with blocks of memory larger than 64 Kb as it is easy to work with blocks no larger than 64 Kb.

For example, here’s typical code to calculate the 16-bit sum of a 128 Kb array, of the sort that a high-level language might generate (actually, the following code is a good deal better than most high-level languages would generate, but what the heck, let’s give them the benefit of the doubt!):

    mov   bx,seg TestArray
    mov   ds,bx               ;point to segment:offset of start of
    mov   bx,offset TestArray ;array to sum
    sub   cx,cx               ;count 128 K bytes with SI:CX
    mov   si,2
    mov   ax,cx               ;set initial sum to 0
    mov   dh,ah               ;set DH to 0 for summing later
SumLoop:
    mov   dl,[bx]             ;get the next array element
    add   ax,dx               ;add the array element to the sum
    inc   bx                  ;point to the next array element
    and   bx,0fh              ;time to advance the segment?
    jnz   SumLoopEnd          ;not yet
    mov   di,ds               ;advance the segment by 1; since BX has
    inc   di                  ;just gone from 15 to 0, we've advanced
    mov   ds,di               ;1 byte in all
SumLoopEnd:
    loop  SumLoop             ;count down 32-bit counter
    dec   si
    jnz   SumLoop

More Good News

While the above is undeniably a mess, things are not quite so grim as they might seem. In fact, the news is quite good when it comes to handling multiple segments in assembler. For one thing, assembler is much better than other languages at handling segments efficiently. Only in assembler do you have complete control over all your segments; that means that you can switch the segments as needed in order to make sure that they are pointing to the data you’re currently interested in. What’s more, in assembler you can structure your code and data so that it falls naturally into 64 Kb blocks, allowing most of your accesses at any one time to fall within the currently loaded segments.

In high-level languages you almost always suffer both considerable performance loss and significant increase in code size when you start using multiple code or data segments, but in assembler it’s possible to maintain near-peak performance even with many segments. In fact, segment-handling is one area in which assembler truly distinguishes itself, and we’ll see examples of assembler’s fine touch with segments in this chapter, Chapter 14, and Volume II of The Zen of Assembly Language.

There’s one more reason that handling multiple code or data segments isn’t much of a problem in assembler, and that’s that the assembler programmer knows exactly what his code needs to do and can optimize accordingly. For example, suppose that we know that the array TestArray in the last example is guaranteed to start at offset 0 in the initial data segment. Given that extra knowledge, we can put together the following version of the above code to sum a 128 Kb array:

    mov   bx,seg TestArray
    mov   ds,bx    ;point to segment:offset of start of
    sub   bx,bx    ;array to sum, which we know starts
                   ; at offset 0
    mov   cx,2     ;count two 64 Kb blocks
    sub   ax,ax    ;set initial sum to 0
    mov   dh,ah    ;set DH to 0 for summing later
SumLoop:
    mov   dl,[bx]  ;get the next array element
    add   ax,dx    ;add the array element to the sum
    inc   bx       ;point to the next array element
    jnz   SumLoop  ;until we wrap at the end of a 64 Kb block
    mov   si,ds
    add   si,1000h ;advance the segment by 64 K bytes
    mov   ds,si
    loop  SumLoop  ;count off this 64 Kb block

Compare the code within the inner loop above to that in the inner loop of the previous version of this example — the difference is striking. This inner loop is every bit as tight as that of the code for handling blocks 64 Kb-and-less in size; in fact, it’s slightly tighter, as jnz is faster than loop. Consequently, there shouldn’t be much difference in performance between the last example and the 64 Kb and less version. Nonetheless, a basic rule of the Zen of assembler is that we should check our assumptions, so let’s toss the three approaches to summing arrays into the Zen timer and see what comes out.

Listing 7-1 measures the time required to calculate the 16-bit sum of a 64 Kb block without worrying about segments. This code runs in 619 ms, or 9.4 us per byte summed. (Note that Listings 7-1 through 7-3 must be timed with the long-period Zen timer — via LZTIME.BAT — since they take more than 54 ms to run.)

Listing 7-2 measures the time required to calculate the 16-bit sum of a 128 Kb block. As is always the case with a memory block larger than 64 Kb, segments must be dealt with, and that shows in the performance of Listing 7-2: 2044 ms, or 15.6 us per byte summed. In other words, Listing 7-1, which doesn’t concern itself with segments, sums bytes 66% faster than Listing 7-2.

Finally, Listing 7-3 implements 128 Kb-block-handling code that takes advantage of the knowledge that the block of memory being summed starts at offset 0 in the initial data segment. We’ve speculated that Listing 7-3 should perform on a par with Listing 7-3, since their inner loops are similar… and the Zen timer bears that out, reporting that Listing 7-3 runs in 1239 ms — 9.5 us per byte summed.

Assumptions confirmed.

Notes on Optimization

There are several points to be made about Listings 7-1 through 7-3. First, these listings graphically illustrate that you should focus your optimization efforts on inner loops. Listing 7-3 is considerably bigger and more complex than Listing 7-1, but by moving the complexity and extra bytes out of the inner loop, we’ve managed to keep performance high in Listing 7-3.

Now, you may well object that in the process of improving the performance of Listing 7-3, we’ve altered the code so that it will only work under certain circumstances, and that’s my second point. Truly general-purpose code runs slowly, no matter whether it’s written in assembler, C, BASIC, or COBOL. Your advantage as a programmer — and your great advantage as an assembler programmer — is that you know exactly what your code needs to do…so why write code that wastes cycles and bytes doing extra work? I stipulated that the start offset was at 0 in the initial data segment, and Listing 7-3 is a response to that stipulation. If the conditions to be met had been different, then we would have come up with a different solution.

Do you see what I’m driving at? I hope so, for it’s central to the Zen of assembler. A key to good assembler code is to write lean code. Your code should do everything you need done — and nothing more.

I’ll finish up by pointing out that Listings 7-1 through 7-3 are excellent examples of both the hazards of using memory blocks larger than 64 Kb and of the virtues of using assembler when you must deal with large blocks. It’s rare that you’ll be able to handle larger-than-64 Kb blocks as efficiently as blocks that fit within a single segment; Listing 7-3 does take advantage of a very convenient special case. However, it’s equally rare that you won’t be able to handle large blocks much more efficiently in assembler than you ever could in a high-level language.

A Final Word on Segment:Offset Addressing

Let’s review what we’ve learned about segment:offset addressing and assembler. The architecture of the 8088 limits us to addressing at most four segments — 64 Kb blocks of memory — at any time, with each segment pointed to by a different segment register. Accessing data in a segment that is not currently pointed to by any segment register is a time-consuming, awkward process, as is handling data that spans multiple blocks. Fortunately, assembler is adept at handling segments, and gives us considerable freedom to structure our programs so that we’re usually working within the currently loaded segments at any one time.

On balance, segment:offset addressing is one of the less attractive features of the 8088. For us, however, it’s actually an advantage, since it allows assembler, with its superb control over the 8088, to far outstrip high-level languages. We won’t deal with segments a great deal in the remainder of this volume, since we’ll be focusing on detailed optimizations, but the topic will come up from time to time. In Volume II, we’ll tackle the subject of segment management in a big way.

The remainder of this chapter will deal only with data addressing — that is, the addressing of instruction operands. Code addressing — in the forms of instruction fetching and branching — is a very real part of PC performance (heck, instruction fetching is perhaps the single most important performance factor of all!), but it’s also very different from the sort of memory addressing we’ll be discussing. We learned as much as we’ll ever need to know (and possibly more) about instruction fetching back in Chapters 4 and 5, so we won’t pursue that aspect of code addressing any further. However, Chapters 12 through 14 discuss code addressing as it relates to branching in considerable detail.

What Can You Do With Segment Registers? Not Much

Segment registers are by no means as flexible as general-purpose registers. What can’t you do with segment registers that you can do with general-purpose registers? Let me answer that question by way of a story.

There’s a peculiar sort of “find the mistake” puzzle that’s standard fare in children’s magazines. Such puzzles typically consist of a drawing with a few intentional mistakes (a farmer milking a donkey, for example — a risky proposition at best), captioned, “What’s wrong with this picture?” Invariably, the answer is printed upside down at the bottom of the page.

I dimly recall from my childhood a takeoff that MAD magazine did on those puzzles. MAD showed a picture in which everything — and I do mean everything — was wrong. Just as with the real McCoy, this picture was accompanied by the caption, “What’s wrong with this picture?”, and by the answer at the bottom of the page.

In MAD, the answer was: “Better yet, what’s right with this picture?”

Segment registers are sort of like MAD’s puzzles. What can’t you do with segment registers? Better yet, what can you do with segment registers? Well, you can use them to address memory — and that’s about it.

Any segment register can be copied to a general-purpose register or memory location. Any segment register other than CS can be loaded from a general-purpose register or memory location. Any segment register can be pushed onto the stack, and any segment register but CS can be popped from the stack.

And that’s all.

Segment registers can’t be used for arithmetic. They can’t be operands to logical instructions, and they can’t take part in comparisons. One segment register can’t even be copied directly to another segment register. Basically, segment registers can’t do a blessed thing except get loaded and get copied to a register or memory.

Now, there are reasons why segments are so hard to work with. For one thing, it’s not all that important that segment registers be manipulated quickly. Segment registers aren’t changed as often as general-purpose registers — at least, they shouldn’t be, if you’re interested in decent performance. Segment registers rarely need to be manipulated arithmetically or logically, and when the need does arise, they can always be copied to general-purpose registers and manipulated there. Nonetheless, greater flexibility in handling segment registers would be nice; however, a major expansion of the 8088’s instruction set — requiring additional circuitry inside the 8088 — would have been required in order to allow us to handle segment registers like general-purpose registers, and it seems likely that the 8088’s designers had other, higher-priority uses for their limited chip space.

There’s another reason why segments can only be loaded and copied, nothing else, and it has to do with the protected mode of the 80286 and 80386 processors. Protected mode, which we’ll return to at a bit more length in Chapter 15, is a second mode of the 80286 and 80386 that’s not compatible with either MS-DOS or the 8088, but which makes much more memory available for program use than the familiar 1 Mb of MS-DOS/8088-compatible real mode.

In protected mode, the segment registers don’t contain memory addresses; instead, they contain segment selectors, which the 80286 and 80386 use to look up the actual segment information — location and attributes such as writability — in a table. Not only would it make no sense to perform arithmetic and the like on segment selectors, since selectors don’t correspond directly to memory addresses, but because the segment registers are central to the memory protection scheme of the 80286 and 80386, they simply cannot be loaded arbitrarily — the 80286 and 80386 literally don’t allow that to happen by instantly causing a trap whenever an invalid selector is loaded.

What’s more, it can take quite a while to load a segment register in protected mode. In real mode, moves to and from segment registers are just as fast as transfers involving general-purpose registers, but that’s not the case in protected mode. For example, mov es,ax takes 2 cycles in real mode and 17 cycles in protected mode.

Given all of the above, all you’d generally want to do in protected mode is load the segment registers with known-good segment selectors provided to you by the operating system. That doesn’t affect real mode, which is all we care about, but since real mode and protected mode share most instructions, the segment-register philosophy of protected mode (which Intel no doubt had as a long-range goal even before they designed the 8088) carries over to real mode.

And now you know why the 8088 offers so little in the way of segment-register manipulation capability.

Using Segment Registers for Temporary Storage

That brings us to another interesting point: the use of segment registers for temporary storage. The 8088 has just 7 available general-purpose registers (remember, we can’t use SP for anything but the stack most of the time), and sometimes it would be awfully handy to have somewhere to store a 16-bit value for a little while. Can we use the segment registers for that purpose?

Some people would answer that “No,” because code that uses segments for temporary storage can’t easily be ported to protected mode. I don’t buy that, for reasons I’ll explain when we get to les. My answer is “Yes… when they’re available.” Two of the segment registers are never available, one is occasionally available, and one may or may not be readily available, depending on your code.

Some segments are always in use. CS is always busy pointing to the segment of the next instruction to be executed; if you were to load CS with an arbitrary value for even 1 instruction, your program would surely crash. Clearly, it’s not a good idea to use CS for temporary storage. (Actually, this isn’t even a potential problem, as Intel has thoughtfully not implemented the instructions — mov and pop — that might load CS directly; MASM will simply generate an error if you try to assemble pop cs or mov cs,[mem16]. CS can only be loaded by far branches: far calls, far returns, far jumps, and interrupts.)

SS isn’t in use during every cycle as CS is, but unless interrupts are off, SS might be used on any cycle. Even if interrupts are off, non-maskable interrupts can occur, and of course your code will often use the stack directly. The risks are too great, the rewards too few. Don’t use SS for temporary storage.

DS can be used for temporary storage whenever it’s free. However, DS is usually used to point to the default data segment. It’s rare that you’ll have a tight loop in which memory isn’t accessed (it’s not worth bothering with such optimizations outside the tightest, most time-critical code), and memory is usually most efficiently accessed via DS. There certainly are loops in which DS is free — loops which use scas to scan the segment pointed to by ES, for example — but such cases are few and far between. Far more common is the case in which DS is saved and then pointed to another segment, as follows:

    push  ds                   ;preserve normal DS setting
    mov   bx,seg TestArray
    mov   ds,bx                ;point DS:BX to array in which
    mov   bx,offset TestArray  ;to flip all bits
    mov   cx,TEST_ARRAY_LENGTH ;# of bytes to flip
FlipLoop:
    not   byte ptr [bx]        ;flip all bits in current byte
    inc   bx                   ;point to next byte
    loop  FlipLoop
    pop   ds                   ;restore normal DS setting

This approach allows instructions within the loop to access memory without the segment override prefix required when ES is used. (More on segment override prefixes shortly.)

In short, feel free to use DS for temporary storage if it’s free, but don’t expect that to come up too often.

Which brings us to the use of ES for temporary storage. ES is by far the best segment register to use for temporary storage; not being dedicated to any full-time function, it’s usually free for any sort of use at all, including temporary storage.

Let’s look at an example of code that uses ES for temporary storage to good effect. This sample code sums selected points in a two-dimensional word-sized array. Let’s start by tallying up the registers this code will use. (A bit backwards, true, but we’re focusing on the use of ES for temporary storage at the moment, and this is the best way to go about it.)

In the sample code, the list of subscripts of points to be added in the major dimension will be stored at DI, and the list of subscripts in the minor dimension will stored at BX. CX will contain the number of points to be summed, and BP will contain the final sum. AX and DX will be used for multiplying, and, as usual, SP will be used to point to the stack. Finally, when the code begins, SI will contain the offset of the start of the array.

Let’s see… that covers all eight general-purpose registers. Unfortunately, we need yet another storage location, this one to serve as a working pointer into the array. There are many possible solutions to this problem, including using the xchg instruction (which we’ll cover in the next chapter), storing values in memory (slow), pushing and popping SI (also slow), or disabling interrupts and using SP (can unduly delay interrupts and carries some risk). Instead, here’s a solution that uses ES for temporary storage; it’s not necessarily the best solution, but it does nicely illustrate the use of ES for temporary storage:

;
; Sums selected points in a two-dimensional array.
;
; Input:
;     BX = list of minor dimension coordinates to sum
;     CX = number of points to sum
;     DS:SI = start address of array
;     DI = list of major dimension coordinates to sum
;
; Output:
;     BP = sum of selected points
;
; Registers altered: AX, BX, CX, DX, SI, DI, BP, ES
;
    mov   es,si ;set aside the array start offset
    sub   bp,bp ;initialize sum to 0
TwoDimArraySumLoop:
    mov   ax,ARRAY_WIDTH ;convert the next major dimension
    mul   word ptr [di]  ;coordinate to an offset in the array
                         ; (wipes out DX)
    add   ax,[bx]        ;add in the minor dimension coordinate
    shl   ax,1           ;make it a word-sized lookup
    mov   si,es          ;point to the start of the array
    add   si,ax          ;point to the desired data point
    add   bp,[si]        ;add it to the total
    inc   di             ;point to the next major dimension coordinate
    inc   di
    inc   bx             ;point to the next minor dimension coordinate
    inc   bx
    loop  TwoDimArraySumLoop

If you find yourself running out of registers in a tight loop and you’re not using the segment pointed to by ES, by all means reload one of your registers from ES if that will help.

Setting and Copying Segment Registers

As I’ve said, loading segment registers is one area in which assembler has a tremendous advantage over high-level languages. High-level languages tend to use DS to point to a default data segment all the time, loading ES every single time any other segment is accessed. In assembler, we can either load a new segment into DS as needed, or we can load ES and leave it loaded for as long as we need to access a given segment.

We’ll see examples of efficient segment use throughout The Zen of Assembly Language, especially when we discuss strings, so I’m not going to go into more detail here. What I am going to do is discuss the process of loading segment registers, because it is by no means obvious what the most efficient segment-loading mechanism is.

For starters, let’s divide segment loading into two categories: setting and copying. Segment setting refers to loading a segment register to point to a certain segment, while segment copying refers to loading a segment register with the contents of another segment register. I’m making this distinction because the instruction sequences used for the two sorts of segment loading differ considerably.

Let’s tackle segment copying first. Segment copying is useful when you want two segment registers to point to the same segment. For example, you’ll want ES to point to the same segment as DS if you’re using rep movs to copy data within the segment pointed to by DS, because DS and ES are the default source and destination segments, respectively, for movs. There are two good ways to load ES to point to the same segment as DS, given that we can’t copy one segment register directly to another segment register:

push  ds
pop   es

and:

mov   ax,ds
mov   es,ax

(Any general-purpose register would serve as well as AX.)

Each of the above approaches has its virtues. The push/pop approach is extremely compact, at just 2 bytes, and affects no other registers. Unfortunately, it takes a less-than-snappy 27 cycles to run. By contrast, the mov/mov approach officially takes just 4 cycles to run; 16 cycles (4 bytes at 4 cycles to fetch each byte) is a more realistic figure, but either way, mov/mov is clearly faster than push/pop. On the other hand, mov/mov takes twice as many bytes as push/pop, and destroys the contents of a general-purpose register as well.

There’s no clear winner here. Use the mov/mov approach to copy segment registers when you’re interested in speed and can spare a general-purpose register, and use the push/pop approach when bytes and/or registers are at a premium. I’ll use both approaches in this book, generally using push/pop in non-time-critical code and mov/mov when speed really counts. Why waste the bytes when the cycles don’t matter?

That brings us to an important point about assembler programming. There is rarely such a beast as the “best code” in assembler; instead, there’s code that’s good in a given context. In any situation, the choice between fast code, small code, understandable code, portable code, maintainable code, structured code, and whatever other sort of code you can dream up is purely up to you. If you make the right decisions, your code will beat high-level language code hands down, because you know more about your code and can think far more flexibly than any high-level language possibly can.

Now let’s look at ways to set segment registers. Segment registers can’t be loaded directly with a segment value, but they can be loaded either through a general-purpose register or from memory. The two approaches aren’t always interchangeable: one requires that the segment name be available as an immediate operand, while the other requires that a memory variable be set to the desired segment value. Nonetheless, you can generally set things up so that either approach can be used, if you really want to — so which is best?

Well, loading a segment register through a general-purpose register, as in:

mov   ax,DATA
mov   es,ax

officially takes 6 cycles. Since the two instructions together are 5 bytes long, however, this approach could take as much a 20 cycles if the prefetch queue is empty. By contrast, loading from memory, as in:

mov   es,[DataSeg]

officially takes only 18 cycles, is only 4 bytes long, and doesn’t destroy a general-purpose register. (Note that the last approach assumes that the memory variable DataSeg has previously been set to point to the desired segment.) Loading from memory sounds better, doesn’t it?

It isn’t.

Remember, it’s not just the number of instruction byte fetches that affects performance — it’s the number of memory accesses of all sorts. When a segment register is loaded from memory, 2 memory accesses are performed to read the segment value; together with the 4 instruction bytes, that means that 6 memory accesses in all are performed when a segment register is loaded from memory. What that means is that loading a segment register from memory takes anywhere from 18 to 24 (6 memory accesses at 4 cycles per access) cycles, which stacks up poorly against the 6 to 20 cycles required to load a segment register through a general-purpose register.

In short, it’s clearly fastest to load segment registers through general-purpose registers.

That’s not to say that there aren’t times when you’ll want to load a segment register directly from memory. If you’re really tight on space, you can save a byte every time you load a segment by using the 4-byte load from memory rather than the 5-byte load through a general-purpose register. (This is only worthwhile if there are multiple segment load instructions, since the memory variable containing the segment address takes 2 bytes.) Also, if the segment you want to work with varies as your program runs (for example, if your code can access either display memory or a display buffer in system RAM), then loading the segment register from memory is the way to go. The following code is clearly the best way to load ES to point to a display buffer that may be at any of several segments:

mov   es,[DisplayBufferSegment]

Here, DisplayBufferSegment is set externally to point to the segment in which all screen drawing should be performed at any given time.

Finally, segments are often passed as stack frame parameters from high-level languages to assembler subroutines — to point to far data buffers and the like — and in those cases segments can best be loaded directly from stack frames into segment registers. (We’ll discuss stack frames later in this chapter.) It’s easy to forget that segments can be loaded directly from any addressable memory location, as we’ll see in Chapter 16; all too many people load segments from stack frames like this:

mov   ax,[bp+BufferSegment]
mov   es,ax

when the following is shorter, faster, and doesn’t use any general-purpose registers:

mov   es,[bp+BufferSegment]

As it happens, though, lone segment values are rarely passed as stack frame parameters. Instead, segment:offset pairs that provide a full 20-bit pointer to a specific data element are usually passed. These can be loaded as follows:

mov   es,[bp+BufferSegment]
mov   di,[bp+BufferOffset]

However, the designers of the 8088 anticipated the need for loading 20-bit pointers, and gave us two most useful instructions for just that purpose: lds and les.

Loading 20-Bit Pointers With lds and les

lds loads both DS and any one general-purpose register from a doubleword of memory, and les similarly loads both ES and a general-purpose register, as shown in Figure 7.3.

While both instructions are useful, les is by far the more commonly used of the two. Since most programs leave DS pointing to the default data segment whenever possible, it’s rare that we’d want to load DS as part of a segment:offset pointer. True, it does happen, but generally only when we want to point to a block of far memory temporarily for faster processing in a tight loop.

ES, on the other hand, is the segment of choice when a segment:offset pointer is needed, since it’s not generally reserved for any other purpose. Consequently, les is usually used to load segment:offset pointers.

lds and les actually don’t come in for all that much use in pure assembler programs. The reason for that is that efficient assembler programs tend to be organized so that segments rarely need to be changed, and so such programs tend to work with 16-bit pointers most of the time. After all, while lds and les are efficient considering all they do, they’re still slow, with official execution times of at least 29 cycles. If you need to load segment:offset pointers, use lds and les, but try to load just offsets whenever you can.

One place where there’s no way to avoid loading segments is in assembler code that’s called from a high-level language, especially when the large data model (the model that supports more than 64 Kb of data) is used. When a high-level language passes a far pointer as a parameter to an assembler subroutine, the full 20-bit pointer must be loaded from memory before it can be used, and there lds and les work beautifully.

Suppose that we have a C statement that calls the assembler subroutine AddTwoFarInts as follows:

int Sum;
int far *FarPtr1, far *FarPtr2;
      :
Sum = AddTwoFarInts(FarPtr1, FarPtr2);

AddTwoFarInts could be written without les as follows:

Parms struc
    dw      ?              ;pushed BP
    dw      ?              ;return address
Ptr1Offset  dw ?
Ptr1Segment dw ?
Ptr2Offset  dw ?
Ptr2Segment dw ?
Parms ends
;
AddTwoFarInts proc near
    push  bp               ;save caller's BP
    mov   bp,sp            ;point to stack frame
    mov   es,[Ptr1Segment] ;load segment part of Ptr1
    mov   bx,[Ptr1Offset]  ;load offset part of Ptr1
    mov   ax,es:[bx]       ;get first int to add
    mov   es,[Ptr2Segment] ;load segment part of Ptr2
    mov   bx,[Ptr2Offset]  ;load offset part of Ptr2
    add   ax,es:[bx]       ;add the two ints together
    pop   bp               ;restore caller's BP
    ret
AddTwoFarInts endp

The subroutine is considerably more efficient when les is used, however:

Parms struc
    dw      ?        ;pushed BP
    dw      ?        ;return address
Ptr1   dd ?
Ptr2   dd ?
Parms ends
;
AddTwoFarInts proc near
    push  bp         ;save caller's BP
    mov   bp,sp      ;point to stack frame
    les   bx,[Ptr1]  ;load both segment and offset of Ptr1
    mov   ax,es:[bx] ;get first int to add
    les   bx,[Ptr2]  ;load both segment and offset of Ptr2
    add   ax,es:[bx] ;add the two ints together
    pop   bp         ;restore caller's BP
    ret
AddTwoFarInts endp

(We’ll talk about struc, stack frames, and segment overrides — such as es: — later in this chapter.)

High-level languages use les all the time to point to data that’s not in the default data segment, and that hurts performance significantly. Most high-level languages aren’t very smart about using les, either. For example, high-level languages tend to load a full 20-bit pointer into ES:BX every time through a loop, even though ES never gets changed from the last pass through the loop. That’s one reason why high-level languages don’t perform very well with more than 64 Kb of data.

You can usually easily avoid les-related performance problems in assembler. Consider Listing 7-4, which adds one far array to another far array in the same way that most high-level languages would, storing both far pointers in memory variables and loading each pointer with les every time it’s used. (Actually, Listing 7-4 is better than your average high-level language subroutine because it uses loop, while most high-level languages use less efficient instruction sequences to handle looping.) Listing 7-4 runs in 43.42 ms, or 43 us per array element addition.

Now look at Listing 7-5, which does exactly the same thing that Listing 7-4 does… except that it loads the far pointers outside the loop and keeps them in the registers for the duration of the loop, using the segment-loading techniques that we learned earlier in this chapter. How much difference does it make to keep the far pointers in registers at all times? Listing 7-5 runs in 19.69 ms — more than twice as fast asListing 7-4.

Now you know why I keep saying that assembler can handle segments much better than high-level languages can. Listing 7-5 isn’t the ultimate in that regard, however; we can carry that concept a step further still, as shown in Listing 7-6.

Listing 7-6 brings the full power of assembler to bear on the task of adding two arrays. Listing 7-6sets up the segments so that they never once need to be loaded within the loop. What’s more, Listing 7-6 arranges the registers so that the powerful lodsb string instruction can be used in place of a mov and an inc. (We’ll discuss the string instructions in Chapter 10. For now, just take my word that the string instructions are good stuff.) In short, Listing 7-6 organizes segment and register usage so that as much work as possible is moved out of the loop, and so that the most efficient instructions can be used.

The results are stunning.

Listing 7-6 runs in just 13.79 ms, more than three times as fast as Listing 7-4, even though Listing 7-4 uses the efficient loop and les instructions. This example is a powerful reminder of two important aspects of the Zen of assembler. First, you must strive to play to the strengths of the 8088 (such as the string instructions) while sidestepping its weaknesses (such as the segments and slow memory access speed). Second, you must always concentrate on moving cycles out of loops. The lds and les instructions outside the loop in Listing 7-6 effectively run 1000 times faster than the les instructions inside the loop in Listing 7-4, since the latter are executed 1000 times but the former are executed only once.

Loading Doublewords with les

While les isn’t often used to load segment:offset pointers in pure assembler programs, it has another less obvious use: loading doubleword values into the general-purpose registers.

Normally, a doubleword value is loaded into two general-purpose registers with two instructions. Here’s the standard way to load DX:AX from the doubleword memory variable DVar:

mov   ax,word ptr [DVar]
mov   dx,word ptr [DVar+2]

There’s nothing wrong with this approach, but it does take between 4 and 8 bytes and between 34 and 48 cycles. We can cut the time nearly in half, and can usually reduce the size as well, by using les in a most unusual way:

les   ax,[DVar]
mov   dx,es

The only disadvantage of using les to load doubleword values is that it wipes out the contents of ES; if that isn’t a problem, there’s simply no reason to load doubleword values any other way.

Once again, there are those people who will tell you that it’s a bad idea to load ES with anything but specific segment values, because such code won’t work if you port it to run in protected mode on the 80286 and 80836. While that’s a consideration, it’s not an overwhelming one. For one thing, most code will never be ported to protected mode. For another, protected mode programming, which we’ll touch on in Chapter 15, differs from normal 8088 assembler programming in a number of ways; using les to load doubleword values is unlikely to be the most difficult part of porting code to protected mode, especially if you have to rewrite the code to run under a new operating system. Still, if protected mode concerns you, use a macro such as:

LOAD_32_BITS  macro Address
ifdef PROTECTED_MODE
    mov   ax,word ptr [Address]
    mov   dx,word ptr [Address+2]
else
    les   ax,dword ptr [Address]
    mov   dx,ax
endif
    endm
    :
    LOAD_32_BITS  DwordVar

to load 32-bit values.

The les approach to loading doubleword values is not only fast but has a unique virtue: it’s indivisible. In other words, there’s no way an interrupt can occur after the lower word of a doubleword is read but before the upper word is read. For example, suppose we want to read the timer count the BIOS maintains at 0000:046C. We could read the count like this:

sub   ax,ax
mov   es,ax
mov   ax,es:[46ch]
mov   dx,es:[46eh]

There’s a problem with this code, though. Every 54.9 ms, the timer generates an interrupt which starts the BIOS timer tick handler. The BIOS handler then increments the timer count. If an interrupt occurs right after mov ax,es:[46ch] in the above code — before mov dx,es:[46eh] can execute — we would read half of the value before it’s advanced, and half of the value after it’s advanced. If this happened as an hour or a day turned over, we could conceivably read a count that’s seriously wrong, with potentially disastrous implications for any program that relies on precise time synchronization. Over time, such a misread of the timer is bound to happen if we use the above code.

We could solve the problem by disabling interrupts while we read the count:

sub   ax,ax
mov   es,ax
cli
mov   ax,es:[46ch]
mov   dx,es:[46eh]
sti

but there’s a better solution. There’s no way les can be interrupted as it reads a doubleword value, so we’ll just load our doubleword thusly:

sub   ax,ax
mov   es,ax
les   ax,es:[46ch]
mov   dx,es

This last bit of code is shorter, faster, and uninterruptible — in short, it’s perfect for our needs. In fact, we could have put les to good use reading the BIOS timer count in the long-period Zen timer, way back in Listing 2-5. Why didn’t I use it there? The truth is that I didn’t know about using les to load doublewords when I wrote the timer (which just goes to show that there’s always more to learn about the 8088). When I did learn about loading doublewords with les, it didn’t make any sense to tinker with code that worked perfectly well just to save a few bytes and cycles, particularly because the timer count load isn’t time-critical.

Remember, it’s only worth optimizing for speed when the cycles you save make a significant difference… which usually means inside tight loops.

Segment:Offset and Byte Ordering in Memory

Our discussion of les brings up the topic of how multi-byte values are stored in memory on the 8088. That’s an interesting topic indeed; on occasion we’ll need to load just the segment part of a 20-bit pointer from memory, or we’ll want to modify only the upper byte of a word variable. The answer to our question is simple but by no means obvious: multi-byte values are always stored with the least-significant byte at the lowest address.

For example, when you execute mov ax,[WordVar], AL is loaded from address WordVar, and AH is loaded from address WordVar+1, as shown in Figure 7.4. Put another way, this:

mov   ax,[WordVar]

is logically equivalent to this:

mov   al,byte ptr [WordVar]
mov   ah,byte ptr [WordVar+1]

although the single-instruction version is much faster and smaller. All word-sized values (including address displacements, which we’ll get to shortly) follow this least-significant-byte-first memory ordering.

Similarly, segment:offset pointers are stored with the least-significant byte of the offset at the lowest memory address, the most-significant byte of the offset next, the least-significant byte of the segment after that, and the most-significant byte of the segment at the highest memory address, as shown in Figure 7.5. This:

les   dx,dword ptr [FarPtr]

is logically equivalent to this:

mov   dx,word ptr [FarPtr]
mov   es,word ptr [FarPtr+2]

which is in turn logically equivalent to this:

mov   dl,byte ptr [FarPtr]
mov   dh,byte ptr [FarPtr+1]
mov   al,byte ptr [FarPtr+2]
mov   ah,byte ptr [FarPtr+3]
mov   es,ax

This organization applies to all segment:offset values stored in memory, including return addresses placed on the stack by far calls, far pointers used by far indirect calls, and interrupt vectors.

There’s nothing sacred about having the least-significant byte at the lowest address; it’s just the approach Intel chose. Other processors store values with most-significant byte at the lowest address, and there’s a sometimes heated debate about which memory organization is better. That debate is of no particular interest to us; we’ll be using an Intel chip, so we’ll always be using Intel’s least-significant-byte-first organization.

So, to load just the segment part of the 20-bit pointer FarPtr, we’d use:

mov   es,word ptr [FarPtr+2]

and to increment only the upper byte of the word variable WordPtr, we’d use:

inc   byte ptr [WordVar+1]

Remember that the least-significant byte of any value (the byte that’s closest to bit 0 when the value is loaded into a register) is always stored at the lowest memory address, and that offsets are stored at lower memory addresses than segments, and you’ll be set.

Loading SS

I’d like to take a moment to remind you that SP must be loaded whenever SS is loaded, and that interrupts should be disabled for the duration of the load, as we discussed in the last chapter. It would have been handy if Intel had given us an lss instruction, but they didn’t. Instead, we’ll load SS and SP with code along the lines of:

cli
mov   ss,[NewSS]
mov   sp,[NewSP]
sti

Extracting Segment Values With the seg Directive

Next, we’re going to look very quickly at a MASM operator and a MASM directive. As I’ve said, this is not a book about MASM, but these directives are closely related to the efficient use of segments.

The seg operator returns the segment within which the following symbol (label or variable name) resides. In the following code, seg WordVar returns the segment Data, which is then loaded into ES and used to assume ES to that segment:

Data  segment
WordVar   dw  0
Data  ends
Code  segment
      assume  cs:Code,es:Nothing
            :
      mov   ax,seg   WordVar
      mov   es,ax
      assume  es:seg WordVar
:
Code ends

You may well ask why it’s worth bothering with seg, when we could simply have used the segment name Data instead. The answer is that you may not know or may not have direct access to the segment name for variables that are declared in other modules. For example, suppose that WordVar were external in our last example:

      extrn WordVar:word
Code  segment
      assume  cs:Code, es:Nothing
      :
      mov   ax,seg WordVar
      mov   es,ax
      assume  es:seg WordVar
      :
Code ends

This code still returns the segment of WordVar properly, even though we don’t necessarily have any idea at all as to what the name of that segment might be.

In short, seg makes it easier to work with multiple segments in multi-module programs.

Joining Segments

Selected assembler modules can share the same code and/or data segments even when multiple code and data segments are used. In other words, in assembler you can choose to share segments between modules or not as you choose, by contrast with high-level languages, which generally force you to choose between all or no modules sharing segments. (This is not always the case, however, as we’ll see in Chapter 14.)

The mechanism for joining or separating segments is the segment directive. If each of two modules has a segment of the same name, and if those segments are created as public segments (via the public option to the segment directive), then those segments will be joined into a single, shared segment. If the segments are code segments, you can use near calls (faster and smaller than far calls) between the modules. If the segments are data segments, then there’s no need for one module to load segment registers in order to access data in the other module.

All in all, shared segments allow multiple-module programs to produce code that’s as efficient as single-module code, with the segment registers changed as infrequently as possible. In the same program in which multiple modules share a given segment, however, other modules — or even other parts of the same modules — may share segments of different names, or may have segments that are private (unique to that module). As a result, assembler programs can strike an effective balance between performance and available memory: efficient offset-only addressing most of the time, along with access to as many segments and as much memory as the PC can handle on an as-needed basis.

There are many ways to join segments, including grouping them and declaring them common, and there are many options to the segment directive. We need to get on with our discussion of memory addressing, so we won’t cover MASM’s segment-related directives further, but I strongly suggest that you carefully read the discussion of those directives in your assembler’s manual. In fact, you should make it a point to read your assembler’s manual cover to cover — it may not be the most exciting reading around, but I guarantee that there are tricks and tips in there that you’ll find nowhere else.

While we won’t discuss MASM’s segment-related directives again, we will explore the topic of effective segment use again in Chapter 10 (as it relates to the string instructions), Chapter 14 (as it relates to branching), and in Volume II of The Zen of Assembly Language.

Segment Override Prefixes

As we saw in Chapter 6, all memory accesses default to accessing memory relative to one of the four segment registers. Instructions come from CS, stack accesses and memory accesses that use BP as a pointer occur within SS, string instruction accesses via DI are in ES, and everything else is normally in DS. In some — but by no means all — cases, segments other than the default segments can be accessed by way of segment override prefixes, special bytes that can precede — prefix — instructions in order to cause those instructions to use any one of the four segment registers.

Let’s start by listing the types of memory accesses segment override prefixes can’t affect. Instructions are always fetched from CS; there’s no way to alter that. The stack pointer is always used as a pointer into SS, no matter what. ES is always the segment to which string instruction accesses via DI go, regardless of segment override prefixes. Basically, it’s accesses to explicitly named memory operands and string instruction accesses via SI that are affected by segment override prefixes. (The segment accessed by the unusual xlat instruction, which we’ll encounter later in this chapter, can also be overridden.)

The default segment for a memory operand is overridden by placing the prefix CS:, DS:, ES:, or SS: on that memory operand. For example:

sub   bx,bx
mov   ax,es:[bx]

loads AX with the word at offset 0 in ES, as opposed to:

sub   bx,bx
mov   ax,[bx]

which loads AX with the word at offset 0 in DS.

Segment override prefixes are handy in a number of situations. They’re good for accessing data out of CS when you’re not sure where DS is pointing, or when DS is temporarily pointing to some segment that doesn’t contain the data you want. (CS is the one segment upon whose setting you can absolutely rely at any given time, since you know that if a given instruction is being executed, CS must be pointing to the segment containing that instruction. Consequently, CS is a good place to put jump tables and temporary variables in multi-segment programs, and is a particularly handy segment in which to stash data in interrupt handlers, which start up with only CS among the four segment registers set to a known value.)

In many programs, especially those involving high-level languages, DS and SS normally point to the same segment, since it’s convenient to have both stack frame variables and static/global variables in the same segment. When that’s the case, ss: prefixes can be used to point to data in the default data segment when DS is otherwise occupied. Even when SS doesn’t point to the default data segment, segment override prefixes still let you address data on the stack using pointer registers other than BP.

Segment override prefixes are particularly handy when you need to access data in two to four segments at once. Suppose, for example, that we need to add two far word-sized arrays together and store the resulting array in the default data segment. Assuming that SS and DS both point to the default data segment, segment override prefixes let us keep all our pointers and counters in the registers as we add the arrays, as follows:

    push  ds              ;save normal DS
    les   di,[FarPtr2]    ;point ES:DI to one source array
    mov   bx,[DestPtr]    ;point SS:BX to the destination array
    mov   cx,[AddLength]  ;array length
    lds   si,[FarPtr1]    ;point DS:SI to the other source array
    cld                   ;make LODSW count up
Add3Loop:
    lodsw                 ;get the next entry from one array
    add   ax,es:[di]      ;add it to the other array
    mov   ss:[bx],ax      ;save the sum in a third array
    inc   di              ;point to the next entries
    inc   di
    inc   bx
    inc   bx
    loop  Add3Loop
    pop   ds              ;restore normal DS

Had we needed to, we could also have stored data in CS by using cs:.

Handy as segment override prefixes are, you shouldn’t use them too heavily if you can help it. They’re fine for one-shot instructions such as branching through a jump table in CS or retrieving a byte from the BIOS data area by way of ES, but they’re to be avoided whenever possible inside tight loops. The reason: segment override prefixes officially take 2 cycles to execute and, since they’re 1 byte long, they can actually take up to 4 cycles to fetch and execute — and 4 cycles is a significant amount of time inside a tight loop.

Whenever you can, organize your segments outside loops so that segment override prefixes aren’t needed inside loops. For example, consider Listing 7-7, which uses a segment override prefix while stripping the high bit of every byte in an array in the segment addressed via ES. Listing 7-7 runs in 2.95 ms.

Now consider Listing 7-8, which does the same thing as Listing 7-7, save that DS is set to match ES outside the loop. Since DS is the default segment for the memory accesses we perform inside the loop, there’s no longer any need for a segment override prefix… and that one change improves performance by nearly 14%, reducing total execution time to 2.59 ms.

The lesson is clear: don’t use segment override prefixes in tight loops unless you have no choice.

assume and Segment Override Prefixes

Segment override prefixes can find their way into your code even if you don’t put them there, courtesy of the assembler and the assume directive. assume tells MASM what segments are currently addressable via the segment registers. Whenever MASM doesn’t think the default segment register for a given instruction can reach the desired segment but another segment register can, MASM sticks in a segment override prefix without telling you it’s doing so. As a result, your code can get bigger and slower without you knowing about it.

Take a look at this code:

Code  segment
      assume      cs:code
Start proc  far
    jmp     Skip
ByteVar     db    0
Skip:
    push    cs
    pop     ds    ;set DS to point to the segment Code
    inc     [ByteVar]
            :
Code  ends

You know and I know that DS can be used to address ByteVar in the above code, since the first thing the code does is set DS equal to CS, thereby loading DS to point to the segment Code. Unfortunately, the assembler does not know that — the assume directive told it only that CS points to Code, and assume is all the assembler has to go by. Given this correct but not complete information, the assembler concludes that ByteVar must be addressed via CS and inserts a cs: segment override prefix, so the inc instruction assembles as if inc cs:[ByteVar] had been used.

The result is a wasted byte and several wasted cycles. Worse yet, you have no idea that the segment override prefix has been inserted unless you either generate and examine a listing file or view the assembled code as it runs in a debugger. The assembler is just trying to help by taking some of the burden of segment selection away from you, but the outcome is all too often code that’s invisibly bloated with segment override prefixes.

The solution is simple. Keep the assembler’s segment assumptions correct at all times by religiously using the assume directive every time you load a segment. The above example would have assembled correctly — without a segment override prefix — if only we had inserted the line:

assume  ds:Code

before we had attempted to access ByteVar.

Loading Offsets

Offsets are loaded with the offset operator. offset is analogous to the seg operator we encountered earlier; the difference, of course, is that offset extracts the offset of a label or variable name rather than the segment. For example:

mov   bx,offset WordVar

loads BX with the offset of the variable WordVar. If some segment register already points to the segment containing WordVar, then BX can be used to address memory, as for example in:

mov   bx,seg WordVar
mov   es,bx
mov   bx,offset WordVar
mov   ax,es:[bx]

We’ll discuss the many ways in which offsets can be used to address memory next.

Before we get to using offsets to address memory, there are a couple of points I’d like to make. The first point is that the lea instruction can also be used to load offsets into registers; however, an understanding of lea requires an understanding of the 8088’s addressing modes, so we’ll defer the discussion of lea until later in this chapter.

The second point is a shortcoming of MASM that you must be aware of when you use offset on variables that reside in segment groups. If you are using the group directive to make segment groups, you must always specify the group name as well as the variable name when you use the offset operator. For example, if the segment _DATA is in the group DGROUP, and WordVar is in _DATA, you must load the offset of WordVar as follows:

mov   di,offset DGROUP:WordVar

If you don’t specify the group name, as in:

mov   di,offset WordVar

the offset of WordVar relative to _DATA rather than DGROUP is loaded; given the way segment groups are organized (with all segments in the group addressed in a single combined segment), an offset relative to _DATA may not work at all.

I realize that the above discussion won’t make much sense if you haven’t encountered the group directive (lucky you!). I’ve never found segment groups to be necessary in pure assembler code, but they are often needed when sharing segments between high-level language code and assembler. If you do find yourself using segment groups, all you need to remember is this: when loading the offset of a variable that resides within a segment group with the offset operator, always specify the group name along with the variable name.

What’s mod-reg-rm Addressing Good For?

The first thing to ask is, “What is mod-reg-rm addressing good for?”What mod-reg-rm addressing does best is address memory in a very flexible way. No other addressing mode approaches mod-reg-rm addressing for sheer number of ways in which memory offsets can be generated.

Look at Figure 7.6, and try to figure out how many source/destination combinations are possible with mod-reg-rm addressing. The answer is simple, since there are 8 bits in a mod-reg-rm byte; 256 possible source/destination combinations are supported. Any general-purpose register can be one operand, and any general-purpose register or memory location can be the other operand.

If we look at memory addressing alone, we see that there are 24 distinct ways to generate a memory offset. (8 of the 32 possible selections that can be made with bits 7-6 and 3-0 of the mod-reg-rm byte select general-purpose registers.) Some of those 24 selections differ only in whether 1 or 2 displacement bytes are present, leaving us with the following 16 completely distinct memory addressing modes:

[disp16]    [bp+disp]
[bx]        [bx+disp]
[si]        [si+disp]
[di]        [di+disp]
[bp+si]     [bp+si+disp]
[bp+di]     [bp+di+disp]
[bx+si]     [bx+si+disp]
[bx+di]     [bx+di+disp]

For two-operand instructions, each of those memory addressing modes can serve as either source or destination, with either a constant value or one of the 8 general-purpose registers as the other operand.

Basically, mod-reg-rm addressing lets you select a memory offset in any of 16 ways (or a general-purpose register, if you prefer), and say, “Use this as an operand.” The other operand can’t involve memory, but it can be any general-purpose register or (usually) a constant value. (There’s no inherent support in mod-reg-rm addressing for constant operands. Special, separate opcodes must used to specify constant operands for instructions that support such operands, and a few mod-reg-rm instructions, such as mul, don’t accept constant operands at all.)

mod-reg-rm addressing is flexible indeed.

Displacements and Sign-Extension

I’ve said that displacements can be either 1 or 2 bytes in size. The obvious question is: what determines which size is used? That’s an important question, since displacement bytes directly affect program size, which in turn indirectly affects performance via the prefetch queue cycle-eater.

Except in the case of direct addressing, which we’ll discuss shortly, displacements in the range -128 to +127 are stored as one byte, then automatically sign-extended by the 8088 to a word when the instructions containing them are executed. (Expressed in unsigned hexadecimal, -128 to +127 covers two ranges: 0 to 7Fh and 0FF80h to 0FFFFh.) Sign-extension involves copying bit 7 of the byte to bits 15-8, so a byte value of 80h sign-extends to 0FF80h, and a byte value of 7Fh sign-extends to 0007Fh. Basically, sign-extension converts signed byte values to signed word values; since the maximum range of a signed byte is -128 to +127, that’s the maximum range of a 1-byte displacement as well.

The implication of this should be obvious: you should try to use displacements in the range -128 to +127 whenever possible, in order to reduce program size and improve performance. One caution, however: displacements must be either numbers or symbols equated to numbers in order for the assembler to be able to assemble them as single bytes. (Numbers and symbols work equally well. In:

SAMPLE_DISPLACEMENT   equ   1
    :
    mov   ax,[bx+SAMPLE_DISPLACEMENT]
    mov   ax,[bx+9]

both mov instructions assemble with 1-byte displacements.)

Displacements must be constant values in order to be stored in sign-extended bytes because when a named memory variable is used, the assembler has no way of knowing where in the segment the variable will end up. Other parts of the segment may appear in other parts of the module or may be linked in from other modules, and the linker may also align the segment to various memory boundaries; any of these can have the effect of moving a given variable in the segment to an offset that doesn’t fit in a sign-extended byte. As a result, the following mov instruction assembles with a 2-byte displacement, even though it appears to be at offset 0 in its segment:

Data  segment
MemVar  db  10 dup (?)
Data  ends
      :
      mov   al,[MemVar+bx]

Naming the mod-reg-rm Addressing Modes

The 16 distinct memory addressing modes supported by the mod-reg-rm byte are often given a slew of confusing names, such as “implied addressing,” “based relative addressing,” and “direct indexed addressing.” Generally, there’s little need to name addressing modes; you’ll find you use them much more than you talk about them. However, we will need to refer to the modes later in this book, so let me explain my preferred addressing mode naming scheme.

I find it simplest to give a name to each of the three possible components of a memory offset — base for BX or BP, index for SI or DI, displacement for a 1-or 2-byte fixed value — and then just refer to an addressing mode with all the components of that mode. That way, mov [bx],al uses base addressing, add ax,[si+1] uses index+displacement addressing, and mov dl,[bp+di+1000h] uses base+index+displacement addressing. The names may be long at times, but they’re never ambiguous or hard to remember.

Direct Addressing

There is one exception to the above naming scheme, and that’s direct addressing. Direct addressing is used when a memory address is referenced with just a 16-bit displacement, as in mov bx,[WordVar] or mov es:[410h],al. You might expect direct addressing to be called displacement addressing, but it’s not, for three reasons. First, the address used in direct addressing is not, properly speaking, a displacement, since it isn’t relative to any register. Second, direct addressing is a time-honored term that came into use long before the 8088 was around, so experienced programmers are more likely to speak of “direct addressing” than “displacement addressing.”

Third, direct addressing is a bit of an anomaly in mod-reg-rm addressing. It’s pretty obvious why we’d want to have direct addressing available; surely you’d rather do this:

mov   dx,[WordVar]

than this:

mov   bx,offset WordVar
mov   dx,[bx]

It’s just plain handy to be able to access a memory location directly by name.

Now look at Figure 7.6 again. Direct addressing really doesn’t belong in that figure at all, does it? The mod-reg-rm encoding for direct addressing should by all rights be taken by base addressing using only BP. However, there is no addressing mode that can use only BP — if you assemble the instruction mov [bp],al, you’ll find that it actually assembles as mov [bp+0],al, with a 1-byte displacement.

In other words, the designers of the 8088 rightly considered direct addressing important enough to build it into mod-reg-rm addressing in place of a little-used addressing mode. (BP is designed to point to stack frames, as we’ll see shortly, and there’s rarely any use for BP-only base addressing in stack frames.)

Along the same lines, note that direct addressing always uses a 16-bit displacement. Direct addressing does not use an 8-bit sign-extended displacement even if the address is in the range -128 to +127.

Miscellaneous Information About Memory Addressing

Be aware that all mod-reg-rm addressing defaults to accessing the segment pointed to by DS — except when BP is used as part of the mod-reg-rm address. Any mod-reg-rm addressing involving BP accesses the segment pointed to by SS by default. (If DS and SS point to the same segment, as they often do, you can use BP-based addressing modes to point to normal data if necessary, and you can use the other mod-reg-rm addressing modes to point to data on the stack.) However, mod-reg-rm addressing can always be forced to use any segment register with a segment override prefix.

There are a few other addressing terms that I should mention now. Indirect addressing is commonly used to refer to any sort of memory addressing that uses a register (BX, BP, SI, or DI, or any of the valid combinations) to point to memory. We’ll also use indirect to refer to branches that branch to destinations specified by memory operands, as in jmp word ptr [SubroutinePointer]. We’ll discuss indirect branching in detail in Chapter 14.

Immediate addressing is a non-mod-reg-rm form of addressing in which the operand is a constant value that’s built right into the instruction. We’ll cover immediate addressing when we’re done with mod-reg-rm addressing.

Finally, I’d like to make it clear that a displacement is nothing more than a fixed (constant) value that’s added into the memory offset calculated by a mod-reg-rm byte. It’s called a displacement because it specifies the number of bytes by which the addressed offset should be displaced from the offset specified by the registers used to point to memory. In mov si,[bx+1], the displacement is 1; the address from which SI is loaded is displaced 1 byte from the memory location pointed to by BX. In mov ax,[si+WordVar], the displacement is the offset of WordVar. We won’t know exactly what that offset is unless we look at the code with a debugger, but it’s a constant value nonetheless.

Don’t get caught up worrying about the exact meaning of the term displacement, or indeed of any of the memory addressing terms. In a way, the terms are silly; mov ax,[bx] is base addressing and mov ax,[si] is index addressing, but both load AX from the address pointed to by a register, both are 2 bytes long, and both take 13 cycles to execute. The difference between the two is purely semantic from a programmer’s perspective.

Notwithstanding, we needed to establish a common terminology for the mod-reg-rm memory addressing modes, and we’ve done so. Now that we understand how mod-reg-rm addressing works and how wonderfully flexible it is, let’s look at its dark side.

mod-reg-rm Addressing: The Dark Side

Gee, if mod-reg-rm addressing is so flexible, why don’t we use it for all memory accesses? For that matter, why does the 8088 even have any other addressing modes?

One reason is that mod-reg-rm addressing doesn’t work with all instructions. For example, the string instructions can’t use mod-reg-rm addressing, and neither can xlat, which we’ll encounter later in this chapter. Nonetheless, most instructions, including mov, add, adc, sub, sbb, cmp, and, or, xor, neg, not, mul, div, and more, do support mod-reg-rm addressing, so it would seem that there must be some other reason for the existence of other addressing modes.

And indeed there is another reason for the existence of other addressing modes. In fact, there are two reasons: speed and size. mod-reg-rm addressing is more flexible than other addressing modes — and it also produces the largest, slowest code around.

It’s easy to understand why mod-reg-rm addressing produces larger code than other memory addressing modes. The bits needed to encode mod-reg-rm addressing’s many possible source, destination, and addressing mode combinations increase the size of mod-reg-rm instructions, and displacement bytes can make mod-reg-rm instructions larger still. It stands to reason that the string instruction lods, which always loads AL from the memory location pointed to by DS:SI, should have fewer instruction bytes than the mod-reg-rm instruction mov al,[si], which selects AL from 8 possible destination registers, and which selects the memory location pointed to by SI from among 32 possible source operands.

It’s less obvious why mod-reg-rm addressing is slower than other memory addressing modes. One major reason falls out from the larger size of mod-reg-rm instructions; we’ve already established that instructions with more instruction bytes tend to run more slowly, simply because it takes time to fetch those extra instruction bytes. That’s not the whole story, however. It takes the 8088 a variable but considerable amount of time — 5 to 12 cycles — to calculate memory addresses from mod-reg-rm bytes. Those lengthy calculations, known as effective address (EA) calculations, are our next topic.

Before we proceed to EA calculations, I’d like to point out that slow and bulky as mod-reg-rm addressing is, it’s still the workhorse memory addressing mode of the 8088. It’s also the addressing mode used by many register-only instructions, such as add dx,bx and mov al,dl, with the mod-reg-rm byte selecting register rather than memory operands. My goodness, some instructions don’t even have a non-mod-reg-rm addressing mode. Without a doubt, you’ll be using mod-reg-rm addressing often in your code, so we’ll take the time to learn how to use it well.

Nonetheless, the less-flexible addressing modes are generally shorter and faster than mod-reg-rm addressing. As we’ll see throughout The Zen of Assembly Language, one key to high-performance code is avoiding mod-reg-rm addressing as much as possible.

Why Memory Accesses Are Slow

As I’ve already said, mod-reg-rm memory accesses are slow partly because instructions that use mod-reg-rm addressing tend to have many instruction bytes. The mod-reg-rm byte itself adds 1 byte beyond the opcode byte, and a displacement, if used, will add 1 or 2 more bytes. Remember, 4 cycles are required to fetch each and every one of those instruction bytes.

Taken a step farther, that line of thinking reveals why all instructions that access memory are slow: memory is slow. It takes 4 cycles per byte to access memory in any way. That means that an instruction like mov bx,[WordVar], which is 4 bytes long and reads a word-sized memory variable, must perform 6 memory accesses in all; at 4 cycles a pop, that adds up to a minimum execution time of 24 cycles. Even a 2-byte memory-accessing instruction spends a minimum of 12 cycles just accessing memory. By contrast, most register-only operations are 1 to 2 bytes in length and have Execution Unit execution times of 2 to 4 cycles, so the maximum execution times for register-only instructions tend to be 4 to 8 cycles.

I’ve said it before, and I’ll say it again: avoid accessing memory whenever you can. Memory is just plain slow.

In actual use, many memory-accessing instructions turn out to be even slower than memory access times alone would explain. For example, the fastest possible mod-reg-rm memory-accessing instruction, mov reg8,[bx] (BP, SI, or DI would do as well as BX), has an Execution Unit execution time of 13 cycles, although only 3 memory accesses (requiring 12 cycles) are performed. Similarly, string instructions, xlat, push, and pop take more cycles than can be accounted for solely by memory accesses.

The full explanation for the poor performance of the 8088’s memory-accessing instructions lies in the microcode of the 8088 (the built-in bit patterns that sequence the 8088 through the execution of each instruction), which is undeniably slower than it might be. (Check out the execution times of the 8088’s instructions on the 80286 and 80386, and you’ll see that it’s possible to execute the 8088’s instructions in many fewer cycles than the 8088 requires.) That’s not something we can change; about all we can do is choose the fastest available instruction for each task, and we’ll spend much of The Zen of Assembly Language doing just that.

There is one aspect of memory addressing that we can change, however, and that’s EA addressing time — the amount of time it takes the 8088 to calculate memory addresses.

Some mod-reg-rm Memory Accesses Are Slower Than Others

A given instruction that uses mod-reg-rm addressing doesn’t always execute in the same number of cycles. The Execution Unit execution time of mod-reg-rm instructions comes in two parts: a fixed Execution Unit execution time and an effective address (EA) execution time that varies depending on the mod-reg-rm addressing mode used. The two times added together determine the overall execution time of each mod-reg-rm instruction.

Each mod-reg-rm instruction has its own fixed Execution Unit execution time, which remains the same for all addressing modes. For example, the fixed execution time of add bl,[mem] is 9 cycles, as shown in Appendix A; this value is constant, no matter what mod-reg-rm addressing mode is used.

The EA calculation time, on the other hand, depends not in the least on which instruction is being executed. EA calculation time is determined solely by the mod-reg-rm addressing mode used, and nothing else, as shown in Figure 7.10. As you can see from Figure 7.10, the time it takes the 8088 to calculate an effective address can vary greatly, ranging from a mere 5 cycles if a single register is used to point to memory all the way up to 11 or 12 cycles if the sum of two registers and a displacement is used to point to memory. (Segment override prefixes require an additional 2 cycles each, as we saw earlier.) When I discuss the performance of an instruction that uses mod-reg-rm addressing, I’ll often say that it takes at least a certain number of cycles to execute. What “at least” means is that the instruction will take that many cycles if the fastest mod-reg-rm addressing mode — base-or index-only — is used, and longer if some other mod-reg-rm addressing mode is selected.

Only mod-reg-rm memory operands require EA calculations. There is no EA calculation time for register operands, or for memory operands accessed with non-mod-reg-rm addressing modes.

In short, EA calculation time means that the choice of mod-reg-rm addressing mode directly affects performance. Let’s look more closely at the performance implications of EA calculations.

Performance Implications of Effective Address Calculations

There are a number of interesting points to be made about EA calculation time. For starters, it should be clear that EA calculation time is a big reason why instructions that use mod-reg-rm addressing are slow. The minimum EA calculation time of 5 cycles, on top of 8 or more cycles of fixed execution time, is no bargain; the maximum EA calculation time of 12 cycles is a grim prospect indeed.

For example, add bl,[si] takes 13 cycles to execute (8 cycles of fixed execution time and 5 cycles of EA calculation time), which is certainly not terrific by comparison with the 3-cycle execution time of add bl,dl. (Instruction fetching alters the picture somewhat, as we’ll see shortly.) At the other end of the EA calculation spectrum, add bl,[bx+di+100h] takes 20 cycles to execute, which is horrendous no matter what you compare it to.

The lesson seems clear: use faster mod-reg-rm addressing modes whenever you can. While that’s true, it’s not necessarily obvious which mod-reg-rm addressing modes are faster. Base-only addressing or index-only addressing are the mod-reg-rm addressing modes of choice, because they add only 5 cycles of EA calculation time and 1 byte, the mod-reg-rm byte. For instance, mov dl,[bp] is just 2 bytes long and takes a fairly reasonable 13 cycles to execute.

Direct addressing, which has an EA calculation time of 6 cycles, is only slightly slower than base or index addressing so far as official execution time goes. However, direct addressing requires 2 additional instruction bytes (the 16-bit displacement) beyond the mod-reg-rm byte, so it’s actually a good deal slower than base or index addressing. mov dl,[ByteVar] officially takes 14 cycles to execute, but given that the instruction is 4 bytes long and performs a memory access, 20 cycles is a more accurate execution time.

Base+index addressing (mov al,[bp+di] and the like) takes 1 to 2 cycles more for EA calculation time than does direct addressing, but is nonetheless superior to direct addressing in most cases. The key: base+index addressing requires only the 1 mod-reg-rm byte. Base+index addressing instructions are 2 bytes shorter than equivalent direct addressing instructions, and that translates into a considerable instruction-fetching/performance advantage.

The rule is: use displacement-free mod-reg-rm* addressing modes whenever you can. Instructions that use displacements are always 1 to 2 bytes longer than those that use displacement-free mod-reg-rm* addressing modes, and that means that there’s generally a prefetching penalty for the use of displacements. There’s also a substantial EA calculation time penalty for base+displacement, index+displacement, or base+index+displacement addressing. If you must use displacements, use 1-byte displacements as much as possible; we’ll see an example of this when we get to stack frames later in this chapter.

Now, bear in mind that the choice of mod-reg-rm addressing mode really only matters inside loops, or in time-critical code. If you’re going to load DX from memory just once in a long subroutine, it really doesn’t much matter if you take a few extra cycles to load it with direct addressing rather than base or index addressing. It certainly isn’t worth loading, say, BX to point to memory, as in:

mov   bx,offset MemVar
mov   dx,[bx]

just to use base or index addressing once — the mov instruction used to load BX takes 4 cycles and 3 bytes, more than negating any advantage base addressing has over direct addressing.

Inside loops, however, it’s well worth using the most efficient addressing mode available. Listing 7-9, which adds up the elements of a byte-sized array using base+index+displacement addressing every time through the loop, runs in 1.17 ms. Listing 7-10, which changes the addressing mode to base+index by adding the displacement into the base outside the loop, runs in 1.01 ms, nearly 16% faster than Listing 7-9. Finally, Listing 7-11, which performs all the addressing calculations outside the loop and uses plain old base-only addressing, runs in just 0.95 ms, 6% faster still. (The string instruction lods is even faster than mov al,[bx], as we’ll see in Chapter 10. Always think of your non-mod-reg-rm alternatives.) Clearly, the choice of addressing mode matters considerably inside tight loops.

We’ve learned two basic rules, then: 1) use displacement-free mod-reg-rm addressing modes whenever you can, and 2) calculate memory addresses outside loops and use base-only or index-only addressing whenever possible. The lea instruction, which we’ll get to shortly, is most useful for calculating memory addresses outside loops.

mod-reg-rm Addressing: Slow, but Not Quite as Slow as You Think

There’s no doubt about it: mod-reg-rm addressing is slow. Still, relative to register operands, mod-reg-rm operands might not be quite so slow as you think, for a very strange reason — the prefetch queue. mod-reg-rm addressing executes so slowly that it allows time for quite a few instruction bytes to be prefetched, and that means that instructions that use mod-reg-rm addressing often run at pretty much their official speed.

Consider this. mov al,bl is a 2-byte, 2-cycle instruction. String a few such instructions together and the prefetch queue empties, making the actual execution time 8 cycles — the time it takes to fetch the instruction bytes.

By contrast, mov al,[bx] is a 2-byte, 13-cycle instruction. Counting both the memory access needed to read the operand pointed to by BX and the two instruction fetches, only 3 memory accesses are incurred by this instruction. Since 3 memory accesses take only 12 cycles, the 13-cycle official execution time of mov al,[bx] is a fair reflection of the instruction’s true performance.

That doesn’t mean that mov al,[bx] is faster than mov al,bl, or that memory-accessing instructions are faster than register-only instructions — they’re not. mov al,bl is a minimum of about 50% faster than mov al,[bx] under any circumstances. What it does mean is that memory-accessing instructions tend to suffer less from the prefetch queue cycle-eater than do register-only instructions, because the considerably longer execution times of memory-accessing instructions often allow a good deal of prefetching per instruction byte executed. As a result, the performance difference between the two is often not quite so great as official execution times would indicate.

In short, memory-accessing instructions, especially those that use mod-reg-rm addressing, generally have a better balance between overall memory access time and execution time than register-only instructions, and consequently run closer to their rated speeds. That’s a mixed blessing, since it’s a side effect of the slow speed of memory-accessing instructions, but it does make memory access — which is, after all, a necessary evil — somewhat less unappealing than it might seem.

Let me emphasize that the basic reason that instructions that use mod-reg-rm memory accesses suffer less from the prefetch queue cycle-eater than do equivalent register-only instructions is that both sorts of instructions have mod-reg-rm bytes. True, register-only mod-reg-rm instructions don’t have EA calculation times, but they do have at least 2 bytes, making them as long as the shortest mod-reg-rm memory-accessing instructions. (A number of non-mod-reg-rm instructions are just 1 byte long; we’ll meet them over the next few chapters.) Since register-only instructions are much faster than memory-accessing instructions, it’s just common sense that if they’re the same length in bytes then they can be hit much harder by the prefetch queue cycle-eater.

Still and all, register-only mod-reg-rm instructions are never longer than memory-accessing mod-reg-rm instructions, and are shorter than memory-accessing instructions that use displacements. What’s more, since memory-accessing instructions must by definition access memory at least once apart from fetching instruction bytes, register-only mod-reg-rm instructions must be at least 50% faster than their memory-accessing equivalents — 100% when word-sized operands are used. To sum up, register-only instructions are always much faster and often smaller than equivalent mod-reg-rm memory-accessing instructions. (Register-only instructions are faster than, although not necessarily shorter than or even as short as, non-mod-reg-rm instructions — even the string instructions — as well.)

Avoid memory. Use the registers as much as you possibly can.

The Importance of Addressing Well

When you do use mod-reg-rm addressing, do so efficiently. As we’ve discussed, that means using base-or index-only addressing whenever possible, and avoiding displacements when you can, especially inside loops. If you’re only going to access a memory location once and you don’t have a pointer to that location already loaded into BX, BP, SI, or DI, just use direct addressing; base-and index-only addressing aren’t so much faster than direct addressing that it pays to load a pointer. As we’ve seen, however, don’t use direct addressing inside a loop if you can load a pointer register outside the loop and then use base-or index-only addressing inside the loop.

It’s often surprising how much more efficient than direct addressing base-and index-only addressing are. Consider this simple bit of code:

mov   dl,[ByteVar]
and   dl,0fh
mov   [ByteVar],dl

You wouldn’t think that code could be improved upon by adding an instruction, but we can cut the code’s size from 10 to 9 bytes by using base-only addressing:

mov   bx,offset ByteVar
mov   dl,[bx]
and   dl,0fh
mov   [bx],dl

The cycle count is 2 higher for the latter version, but a 2-byte advantage in instruction fetching could well overcome that.

The point is not that base-only addressing is always the best solution. In fact, the latter example could be made much more efficient simply by anding 0Fh directly with memory, as in:

and   [ByteVar],0fh

(Always bear in mind that memory can serve as the destination operand as well as the source operand. When only one modification is involved, it’s always faster to modify a memory location directly, as in the last example, than it is to load a register, modify the register, and store the register back to memory. However, the scales tip when two or more modifications to a memory operand are involved, as we’ll see in Chapter 8.) The special accumulator-specific direct-addressing instructions that we’ll discuss in the next chapter make direct addressing more desirable in certain circumstances as well.

The point is that for repeated accesses to the same memory location, you should arrange your code so that the most efficient possible instruction — base-only, a string instruction, whatever fills the bill — can be used. In the last example, base-only addressing was superior to direct addressing when just two accesses to the same byte were involved. Multiply the number of accesses by ten, or a hundred, or a thousand, as is often the case in a tight loop, and you’ll get a feel for the importance of selecting the correct memory addressing mode in your time-critical code.

The 8088 is Faster at Memory Address Calculations Than You Are

You may recall that we found earlier that when you must access a word-sized memory operand, it is better to let the 8088 access the second byte than to do it with a separate instruction; the 8088 is simply faster at accessing two adjacent bytes than any two instructions can be. Much the same is true of mod-reg-rm addressing; the 8088 is faster at performing memory address calculations than you are. If you must add registers and/or constant values to address memory, the 8088 can do it faster during EA calculations than you can with separate instructions.

Suppose that we have to initialize a doubleword of memory pointed to by BX to zero. We could do that with:

mov   word ptr [bx],0
inc   bx
inc   bx
mov   word ptr [bx],0

However, it’s better to let the 8088 do the addressing calculations, as follows:

mov   word ptr [bx],0
mov   word ptr [bx+2],0

True, the latter version involves a 1-byte displacement, but that displacement is smaller than the 2 bytes required to advance BX in the first version. Since the incremental cost of base+displacement addressing over base-only addressing is 4 cycles, exactly the same number of cycles as two inc instructions, the code that uses base+displacement addressing is clearly superior.

Similarly, you’re invariably better off letting EA calculations add one register to another than you are using add. For example, consider two approaches to scanning an array pointed to by BX+SI for the byte in AL:

    mov   dx,bx     ;set aside the base address
ScanLoop:
    mov   bx,dx     ;get back the base address
    add   bx,si     ;add in the index
    cmp   [bx],al   ;is this a match?
    jz    ScanFound ;yes, we're done
    inc   si        ;advance the index to the next byte
    jmp   ScanLoop  ;scan the next byte
ScanFound:

and:

ScanLoop:
    cmp   [bx+si],al  ;is this a match?
    jz    ScanFound   ;yes, we're done
    inc   si          ;advance the index to the next byte
    jmp   ScanLoop    ;scan the next byte
ScanFound:

It should be pretty clear that the approach that lets the 8088 add the two memory components together is far superior.

While the point is perhaps a little exaggerated — I seriously doubt anyone would use the first approach — it is nonetheless valid. The 8088 can add BX to SI in just 2 extra cycles as part of an EA calculation, and at the cost of no extra bytes at all. What’s more, EA calculations leave all registers unchanged. By contrast, at least one register must be changed to hold the final memory address when you perform memory calculations yourself. That’s what makes the first version above so inefficient; we have to reload BX from DX every time through the loop because it’s altered by the memory-address calculation.

I hope you noticed that neither example above is particularly efficient. We’d be better off simply adding the two memory components outside the loop and using base-or index-only addressing inside the loop. (We’d be even better off using string instructions, but we’ll save that for another chapter.) To wit:

    add   si,bx     ;add together the memory address components
                    ;outside the loop
ScanLoop:
    cmp   [si],al   ;is this a match?
    jz    ScanFound ;yes, we're done
    inc   si        ;point to the next byte
    jmp   ScanLoop  ;scan the next byte
ScanFound:

Although EA calculations can add faster than separate instructions can, it’s faster still not to add at all. Whenever you can, perform your calculations outside loops.

Which brings us to lea.

Calculating Effective Addresses With lea

lea is something of an odd bird, as the only mod-reg-rm memory-addressing instruction that doesn’t access memory. lea calculates the offset of the memory operand… and then loads that offset into one of the 8 general-purpose registers, without accessing memory at all. Basically, lea is nothing more than a means by which to load the result of an EA calculation into a register.

For example, lea bx,[MemVar] loads the offset of MemVar into BX. Now, we wouldn’t generally want to use lea to load simple offsets, since mov can do that more efficiently; mov bx,offset MemVar is 1 byte shorter and 4 cycles faster than lea bx,[MemVar]. (Since lea involves EA calculation, it’s not particularly fast; however, it’s faster than any mod-reg-rm memory-accessing instruction, taking only 2 cycles plus the EA calculation time.)

lea shines when you need to load a register with a complex memory address, preferably without disturbing any of the registers that make up the memory address. Suppose that we want to push the address of an array element that’s indexed by BP+SI. We could use:

mov   ax,offset TestArray
add   ax,bp
add   ax,si
push  ax

which is 8 bytes long. On the other hand, we could simply use:

lea   ax,[TestArray+bp+si]
push  ax

which is only 5 bytes long. One of the primary uses of lea is loading offsets of variables in stack frames, because such variables are addressed with base+displacement addressing.

Refer back to the example we examined in the last section. Suppose that we wanted to scan memory without disturbing either BX or SI. In that case, we could use DI, with an assist from lea:

    lea   di,[bx+si]  ;add together the memory address components
                      ; outside the loop
ScanLoop:
    cmp   [di],al     ;is this a match?
    jz    ScanFound   ;yes, we're done
    inc   di          ;point to the next byte
    jmp   ScanLoop    ;scan the next byte
ScanFound:

lea is particularly handy in this case because it can add two registers — BX and SI — and place the result in a third register — DI. That enables us to replace the two instructions:

mov   di,bx
add   di,si

with a single lea.

lea should make it clear that offsets are just 16-bit numbers. Adding offsets stored in BX and SI together with lea is no different from adding any two 16-bit numbers together with add, because offsets are just 16-bit numbers. 0 is a valid offset; if we execute:

sub   bx,bx     ;load BX with 0
mov   al,[bx]   ;load AL with the byte at offset 0 in DS

we’ll read the byte at offset 0 in the segment pointed to by DS. It’s important that you understand that offsets are just numbers, and that you can manipulate offsets every bit as flexibly as any other values.

The flip side is that you could, if you wished, add two registers and/or a constant value together with lea and place the result in a third register. Of course, the registers would have to be BX or BP and SI or DI, but since offsets and numbers are one and the same, there’s no reason that lea couldn’t be used for arithmetic under the right circumstances. For example, here’s one way to add two memory variables and 52 together and store the result in DX:

mov   bx,[MemVar1]
mov   si,[MemVar2]
lea   dx,[bx+si+52]

That’s not to say this is a good way to perform this particular task; the following is faster and uses fewer registers:

mov   dx,[MemVar1]
add   dx,[MemVar2]
add   dx,52

Nonetheless, the first approach does serve to illustrate the flexibility of leaand the equivalence of offsets and numbers.

Offset Wrapping at the Ends of Segments

Before we take our leave of mod-reg-rm addressing, I’d like to repeat a point made earlier that may have slipped past unnoticed. That point is that offsets wrap at the ends of segments. Offsets are 16-bit entities, so they’re limited to the range 0 to 64 K-1. However, it is possible to use two or three mod-reg-rm address components that together add up to a number that’s larger than 64 K. For example, the sum of the memory addressing components in the following code is 18000h:

mov   bx,4000h
mov   di,8000h
mov   ax,[bx+di+0c000h]

What happens in such a case? We found earlier that segments are limited to 64 Kb in length; is this a clever way to enlarge the effective size of a segment?

Alas, no. If the sum of two offset components won’t fit in 16 bits, bits 16 and above of the sum are simply ignored. In other words, mod-reg-rm address calculations are always performed modulo 64 K (that is, modulo 10000h), as shown in Figure 7.11. As a result, the last example will access not the word at offset 18000h but the word at offset 8000h. Likewise, the following will access the byte at offset 0:

mov   bx,0ffffh
mov   dl,[bx+1]

The same rule holds for all memory-accessing instructions, mod-reg-rm or otherwise: offsets are 16-bit values; any additional bits that result from address calculations are ignored. Put another way, memory addresses that reach past the end of a segment’s 64 K limit wrap back to the start of the segment. This allows the use of negative displacements, and is the reason a displacement can always reach anywhere in a segment, including addresses lower than those in the base and/or index registers, as in mov ax,[bx-1].

Special Forms of Common Instructions

The 8088 offers special shorter, faster forms of several commonly used mod-reg-rm instructions, including mov, inc, and xchg. These special forms are both shorter and less flexible than the mod-reg-rm forms. For example, the special form of inc is just 1 byte long and requires only 2 cycles to execute, but can only work with 16-bit registers. By contrast, the mod-reg-rm form of inc is at least 2 bytes long and takes at least 3 cycles to execute, but can work with 8-or 16-bit registers or memory locations.

You don’t have to specify that a special form of an instruction is to be used; the assembler automatically selects the shortest possible form of each instruction it assembles. That doesn’t mean that you don’t need to be familiar with the special forms, however. To the contrary, you need to be well aware of the sorts of instructions that have special forms, as well as the circumstances under which those special forms will be assembled. Armed with that knowledge, you can arrange your code so that the special forms will be assembled as often as possible.

We’ll get a solid feel for the various special forms of mod-reg-rm instructions as we discuss them individually in Chapters 8 and 9.

The String Instructions

The string instructions are without question the most powerful instructions of the 8088. String instructions can initialize, copy, scan, and compare arrays of data at speeds far beyond those of mortal mod-reg-rm instructions, and lend themselves well to almost any sort of repetitive processing. In fact, string instructions are so important that they get two full chapters of The Zen of Assembly Language — Chapters 10 and 11 — to themselves. We’ll defer further discussion of these extremely important instructions until then.

Immediate Addressing

Immediate addressing is a form of memory addressing in which the constant value of one operand is built right into the instruction. You should think of immediate operands as being addressed by IP, since they directly follow opcode bytes or mod-reg-rm bytes, as shown in Figure 7.12.

Instructions that use immediate addressing are clearly faster than instructions that use mod-reg-rm addressing. In fact, according to official execution times, immediate addressing would seem to be much faster than mod-reg-rm addressing. For example, add ax,1 is a 4-cycle instruction, while add ax,[bx] is an 18-cycle instruction. What’s more, add reg,immed is just 1 cycle slower than add reg,reg, so immediate addressing seems to be nearly as fast as register addressing.

The official cycle counts are misleading, however. While immediate addressing is certainly faster than mod-reg-rm addressing, it is by no means as fast as register-only addressing, and the reason is a familiar one: the prefetch queue cycle-eater. You see, immediate operands are instruction bytes; when we use an immediate operand, we increase the size of that instruction, and that increases the number of cycles needed to fetch the instruction’s bytes.

Looked at another way, immediate operands need to be fetched from the memory location pointed to by IP, so immediate addressing could be considered a memory addressing mode. Granted, immediate addressing is an efficient memory addressing mode, with no EA calculation time or the like — but memory accesses are nonetheless required, at the inescapable 4 cycles per byte.

The upshot is simply that register operands are superior to immediate operands in loops and time-critical code, although immediate operands are still much better than mod-reg-rm memory operands. Back in Listing 7-11, we set DL to 0 outside the loop so that we could use register-register adc inside the loop. That approach allowed the code to run in 0.95 ms. Listing 7-12 is similar to Listing 7-11, but is modified to use an immediate operand of 0 rather than a register operand containing 0. Even though the immediate operand is only byte-sized, Listing 7-12 slows down to 1.02 ms. In other words, the need to fetch just 1 immediate operand byte every time through the loop slowed the entire loop by about 7%. What’s more, the performance loss would have been approximately twice as great if we had used a word-sized immediate operand.

On the other hand, immediate operands are certainly preferable to memory operands. Listing 7-13, which adds the constant value 0 from memory, runs in 1.26 ms. (I should hope you’ll never use code as obviously inefficient as Listing 7-13; I’m just presenting it for illustrative purposes.)

To sum up: when speed matters, use register operands rather than immediate operands if you can. If registers are at a premium, however, immediate operands are reasonably fast, and are certainly better than memory operands. If bytes rather than cycles are at a premium, immediate operands are excellent, for it takes fewer bytes to use an immediate operand than it does to load a register with a constant value and then use that register. For example:

LoopTop:
    or    byte ptr [bx],80h
    loop  LoopTop

is 1 byte shorter than:

    mov   al,80h
LoopTop:
    or    [bx],al
    loop  LoopTop

However, the latter, register-only version is faster, because it moves 2 bytes out of the loop.

There are many circumstances in which we can substitute register-only instructions for instructions that use immediate operands without adding any extra instructions. The commonest of these cases involve testing for zero. There’s almost never a need to compare a register to zero; instead, we can simply and or or the register with itself and check the resulting flags. We’ll discuss ways to handle zero in the next two chapters, and we’ll see similar cases in which immediate operands can be eliminated throughout The Zen of Assembly Language.

By the way, you should be aware that you can use an immediate operand even when the other operand is a memory variable rather than a register. For example, add [MemVar],16 is a valid instruction, as is mov [MemVar],52. As I mentioned earlier, we’re better off performing single operations directly to memory than we are loading from memory into a register, operating on the register, and storing the result back to memory. However, we’re generally better off working with a register when multiple operations are involved.

Ideally, we’d load a memory value into a register, perform multiple operations on it there, store the result back to memory… and then have some additional use for the value left in the register, thereby getting double use out of our memory accesses. For example, suppose that we want to perform the equivalent of the C statement:

i = ++j + k;

We could do this as follows:

inc   [j]
mov   ax,[j]
add   ax,[k]
mov   [i],ax

However, we can eliminate a memory access by incrementing j in a register:

mov   ax,[j]
inc   ax
mov   [j],ax
add   ax,[k]
mov   [i],ax

While the latter version is one instruction longer than the original version, it’s actually faster and shorter. One reason for this is that we get double use out of loading j into AX; we increment j in AX and store the result to memory, then immediately use the incremented value left in AX as part of the calculation being performed.

The other reason the second example above is superior to the original version is that it used two of the special, more efficient instruction forms: the accumulator-specific direct-addressed form of mov and the 16-bit register-only form of inc. We’ll study these instructions in detail in Chapters 8 and 9.

Sign-Extension of Immediate Operands

I’ve already noted that immediate operands tend to make for compact code. One key to this property is that like displacements in mod-reg-rm addressing, word-sized immediate operands can be stored as a byte and then extended to a word by replicating bit 7 as bits 15-8; that is, word-sized immediate operands can be sign-extended. Almost all instructions that support immediate operands allow word-sized operands in the range -128 to +127 to be stored as single bytes. That means that while and dx,1000h is a 4-byte instruction (1 opcode byte, 1 mod-reg-rm byte, and a 2-byte immediate operand), and dx,0fffeh is just 3 bytes long; since the signed value of the immediate operand 0FFFEh is -2, 0FFFEh is stored as a single immediate operand byte.

Not all values of the form 000nnh and 0FFnnh (where nn is any two hex digits) can be stored as a single byte and sign-extended. 0007Fh can be stored as a single byte; 00080h cannot. 0FF80h can be stored as a single byte; 0FF7Fh cannot. Watch out for cases where you’re using a word-sized immediate operand that can’t be stored as a byte, when a byte-sized immediate operand would serve as well.

For example, suppose we want to set the lower 8 bits of DX to 0. {.nasm}and dx,0ff00h is a 4-byte instruction that accomplishes the desired result. and dl,000h produces the same result in just 3 bytes. (Of course, sub dl,dl does the same thing in just 2 bytes — there are many ways to skin a cat in assembler.) Recognizing when a word-sized immediate operand can be handled as a byte-sized operand is still more important when using accumulator-specific immediate-operand instructions, which we’ll explore in the next chapter.

mov Doesn’t Sign-Extend Immediate Operands

Along the same lines, or bh,0ffh does the same thing as or bx,0ff00h and is shorter, while mov bh,0ffh is also equivalent and is shorter still… and that brings us to the one instruction which cannot sign-extend immediate operands: mov. Word-sized operands to mov are always stored as words, no matter what size they may be. However, there’s a compensating factor, and that’s that there’s a special, non-mod-reg-rm form of mov reg,immed that’s 1 byte shorter than the mod-reg-rm form.

Let me put it this way. and dx,1000h is a 4-byte instruction, with 1 opcode byte, 1 mod-reg-rm byte, and a 2-byte immediate operand. mov dx,1000h, on the other hand, is only 3 bytes long. There’s a special form of the mov instruction, used only when a register is loaded with an immediate value, that requires just the 1 opcode byte in addition to the immediate value.

There’s also the standard mod-reg-rm form of mov, which is 4 bytes long for word-sized immediate operands. This form does exactly the same thing as the special form, but is a different instruction, with a different opcode and a mod-reg-rm byte. The 8088 offers a number of duplicate instructions, as we’ll see in the next chapter. Don’t worry about selecting the right form of mov, however; the assembler does that for you automatically.

In short, you’re no worse off — and often better off — moving immediate values into registers than you are using immediate operands with instructions such as add and xor. It takes just 2 or 3 bytes, for byte-or word-sized registers, respectively, to load a register with an immediate operand. mov al,2 is actually the same size as mov al,bl (both are 2 bytes), although the official execution time of the register-only mov is 2 cycles shorter.

On balance, immediate operands used with mov reg,immed perform at nearly the speed of register operands, especially when the register is byte-sized; consequently, there’s less need to avoid immediate operands with mov than with other instructions. Nonetheless, register-only instructions are never slower, so you won’t go wrong using register rather than immediate operands.

Don’t mov Immediate Operands to Memory if You Can Help It

One final note, and then we’re done with immediate addressing. There is no special form of mov for moving an immediate operand to a memory operand; the special form is limited to register operands only. What’s more, mov [mem16],immed16 has no sign-extension capability. This double whammy means that storing immediate values to memory is the single least desirable way to use immediate operands. Over the next few chapters, we’ll explore several ways to set memory operands to given values. The one thing that the various approaches have in common is that they all improve performance by avoiding immediate operands to mov.

Don’t move immediate values to memory unless you have no choice.

Stack Addressing

While SP can’t be used to point to memory by mod-reg-rm instructions, it is nonetheless a memory-addressing register. After all, SP is used to address the top of the stack. Surely you know how the stack works, so I’ll simply note that SP points to the data item most recently pushed onto the top of the stack that has not yet been popped off the stack. Consequently, stack data can only be accessed in Last In, First Out (LIFO) order via SP (that is, the order in which data is popped off the stack is the reverse of the order in which it was pushed on). However, other addressing modes — in particular mod-reg-rm BP-based addressing — can be used to access stack data in non-LIFO order, as we’ll see when we discuss stack frames.

What’s so great about the stack? Simply put, the stack is terrific for temporary storage. Each named memory variable, as in:

MemVar  dw 0

takes up 1 or more bytes of memory for the duration of the program. That’s not the case with stack data, however; when data is popped from the stack, the space it occupied is freed up for other use. In other words, stack memory is a reusable resource. This makes the stack an excellent place to store temporary data, especially when large data elements such as buffers and structures are involved.

Space allocated on the stack is also unique for each invocation of a given subroutine, which is useful for any subroutine that needs to be capable of being called directly or indirectly from itself. Stack-based storage is how C implements automatic (dynamic) variables, which are unique for each invocation of a given subroutine. In fact, stack-based storage is the heart of the parameter-passing mechanism used by most C implementations, as well as the mechanism used for automatic variables, as we’ll see shortly.

Don’t underestimate the flexibility of the stack. I’ve heard of programs that actually compile code right into a buffer on the stack, then execute that code in place, on the stack. While that’s a strange concept, stack memory is memory like any other, and instruction bytes are data; obviously, those programs needed a temporary place in which to compile code, run it, and discard it, and the stack fits those requirements nicely.

Similarly, suppose that we need to pass a pointer to a variable from an assembler program to a C subroutine… but there’s no variable to point to in the assembler code, because we keep the variable in a register. Suppose also that the C subroutine actually modifies the pointed-to variable, so we need to retrieve the altered value after the call. The stack is admirably suited to the job; at the beginning of the following code, the variable of interest is in DX, and that’s just where the modified result is at the end of the code:

;
; Calls: int CSubroutine(int *Count, char *BufferPointer).
;
mov   dx,MAX_COUNT          ;store the maximum # of bytes to handle
                            ; in the count variable
push  dx                    ;store the count variable on the stack
                            ; for the duration of the call
mov   dx,sp                 ;put a pointer to the just-pushed temporary
                            ; count variable in DX
mov   ax,offset TestBuffer
push  ax                    ;pass the buffer pointer parameter
push  dx                    ;pass the count pointer parameter
call  CSubroutine           ;do the count
add   sp,4                  ;clear the parameter bytes from the stack
pop   dx                    ;get the actual count back into DX

The important point in the above code is that we created a temporary memory variable on the stack as we needed it; then, when the call was over, we simply popped the variable back into DX, and its space on the stack was freed up for other use. The code is compact, and not a single byte of memory storage had to be reserved permanently.

Compact code without the need for permanent memory space is the hallmark of stack-based code. It’s often possible to write amazingly complex code without using mod-reg-rm addressing or named variables simply by pushing and popping registers. The code tends to be compact because push reg16 and pop reg16 are each only 1 byte long. push reg16 and pop reg16 are so compact because they don’t need to support the complex memory-addressing options of mod-reg-rm addressing; there are only 8 possible register operands, and each instruction can only address one location, by way of the stack pointer, at any one time. (push mem16 and pop mem16 are mod-reg-rm instructions, and so they’re 2-4 bytes long; push reg16 and pop reg16, and push segreg and pop segreg as well, are special, shorter forms of push and pop.)

For once, though, shorter isn’t necessarily better. You see, push and pop are memory-accessing instructions, and although they don’t require EA calculation time, they’re still slow -like all instructions that access memory. push and pop are fast considering that they are word-sized memory-accessing instructions -push takes 15 cycles, pop takes just 12 — and they make for good prefetching, since only 3 memory accesses (including instruction fetches) are performed during an official execution time of 12 to 15 cycles. Nonetheless, they’re clearly slower than register-only instructions. This is basically the same case we studied when we looked into copying segments; it’s faster but takes more bytes and requires a free register to preserve a register by copying it to another register:

mov   dx,ax
:
mov   ax,dx

than it is to preserve it by pushing and popping it:

push  ax
:
pop   ax

What does all this mean to you? Simply this: use a free register for temporary storage if speed is of the essence, and push and pop if code size is your primary concern, if speed is not an issue, or if no registers happen to be free. In any case, it’s faster and far more compact to store register values temporarily by pushing and popping them than it is to store them to memory with mod-reg-rm instructions. So use push and pop… but remember that they come with substantial performance overhead relative to register-only instructions.

An Example of Avoiding push and pop

Let’s quickly look at an example of improving performance by using register-only instructions rather than push and pop. When copying images into display memory, it’s common to use code like:

;
; Copies an image into display memory.
;
; Input:
;     BX = width of image in bytes
;     DX = height of image in lines
;     BP = number of bytes from the start of one line to the
;          start of the next
;     DS:SI = pointer to image to draw
;     ES:DI = display memory address at which to draw image
;     Direction flag must be cleared on entry
;
; Output:
;     none
;
DrawLoop:
    push  di        ;remember where the line starts
    mov   cx,bx     ;# of bytes per line
    rep   movsb     ;copy the next line
    pop   di        ;get back the line start offset
    add   di,bp     ;point to the next line in display memory
    dec   dx        ;repeat if there are any more lines
    jnz   DrawLoop

That’s fine, but 1 push and 1 pop are performed per line, which seems a shame… all the more so given that we can eliminate those pushes and pops altogether, as follows:

;
; Copies an image into display memory.
;
; Input:
;     BX = width of image in bytes
;     DX = height of image in lines
;     BP = number of bytes from the start of one line to the
;          start of the next
;     DS:SI = pointer to image to draw
;     ES:DI = display memory address at which to draw image
;     Direction flag must be cleared on entry
;
; Output:
;     none
;
    sub   bp,bx     ;# of bytes from the end of 1 line of the
                    ; image in display memory to the start of
                    ; the next line of the image
DrawLoop:
    mov   cx,bx     ;# of bytes per line
    rep   movsb     ;copy the next line
    add   di,bp     ;point to the next line in display memory
    dec   dx        ;repeat if there are any more lines
    jnz   DrawLoop

Do you see what we’ve done? By converting an obvious solution (advancing 1 full line at a time) to a less-obvious but fully equivalent solution (advancing only the remaining portion of the line), we’ve saved about 27 cycles per loop… at no cost. Given inputs like the width of the screen and instructions like push and pop, we tend to use them; it’s just human nature to frame solutions in familiar terms. By rethinking the problem just a little, however, we can often find a simpler, better solution.

Saving 27 cycles not by knowing more instructions but by not using two powerful instructions is an excellent example indeed of the Zen of assembler.

Miscellaneous Notes About Stack Addressing

Before we proceed to stack frames, I’d like to take a moment to review a few important points about stack addressing.

SP always points to the next item to be popped from the stack. When you push a value onto the stack, SP is first decremented by 2, and then the value is stored at the location pointed to by SP. When you pop a value off of the stack, the value is read from the location pointed to by SP, and then SP is incremented by 2. It’s useful to know this whenever you need to point to data stored on the stack, as we did when we created and pointed to a temporary variable on the stack a few sections back, and as we will need to do when we work with stack frames.

push and pop can work with mod-reg-rm-addressed memory variables as easily as with registers, albeit more slowly and with more instruction bytes. push [WordVar] is perfectly legitimate, as is pop word ptr [bx+si+100h]. Bear in mind, however, that only 16-bit values can be pushed and popped; push bl won’t work, and neither will pop byte ptr [bx].

Finally, please remember that once you’ve popped a value from the stack, it’s gone from memory. It’s tempting to look at the way the stack pointer works and think that the data is still in memory at the address just below the new stack pointer, but that’s simply not the case, as shown in Figure 7.13. Sure, sometimes the data is still there — but whenever an interrupt occurs, it uses the top of the stack, wiping out the values that were most recently popped. Interrupts can happen at any time, so unless you’re willing to disable interrupts, accessing popped stack memory is a sure way to get intermittent bugs.

Even if interrupts are disabled, it’s really not a good idea to access popped stack data. Why bother, when stack frames give you the same sort of access to stack data, but in a straightforward, risk-free way? Not coincidentally, stack frames are our next topic, but first let me emphasize: once you’ve popped data off the stack, it’s gone from memory. Vanished. Kaput. Extinct. For all intents and purposes, that data is nonexistent.

Don’t access popped stack memory. Period.

Stack Frames

Stack frames are transient data structures, usually local to specific subroutines, that are stored on the stack. Two sorts of data are normally stored in stack frames: parameters that are passed from the calling routine by being pushed on the stack, and variables that are local to the subroutine using the stack frame.

Why use stack frames? Well, as we discussed earlier, the stack is an excellent place to store temporary data, a category into which both passed parameters and local storage fall. push and pop aren’t good for accessing stack frames, which often contain many variables and which aren’t generally accessed in LIFO order; however, there are several mod-reg-rm addressing modes that are perfect for accessing stack frames — the mod-reg-rm addressing modes involving BP. (We can’t use SP for two reasons: it can’t serve as a memory pointer with mod-reg-rm addressing modes, and it changes constantly during code execution, making offsets from SP hard to calculate.)

If you’ll recall, BP-based addressing modes are the only mod-reg-rm addressing modes that don’t access DS by default. BP-based addressing modes access SS by default, and now we can see why — in order to access stack frames. Typically, BP is set to equal the stack pointer at the start of a subroutine, and is then used to point to data in the stack frame for the remainder of the subroutine, as in:

push  bp          ;save caller's BP
mov   bp,sp       ;point to stack frame
mov   ax,[bp+4]   ;retrieve a parameter
:
pop   bp          ;restore caller's BP
ret

If temporary local storage is needed, SP is moved to allocate the necessary room:

push  bp          ;save caller's BP
mov   bp,sp       ;point to stack frame
sub   sp,10       ;allocate 10 bytes of local storage
mov   ax,[bp+4]   ;retrieve a parameter
mov   [bp-2],ax   ;save it in local storage
:
mov   sp,bp       ;dump the temporary storage
pop   bp          ;restore caller's BP
ret

I’m not going to spend a great deal of time on stack frames, for one simple reason: they’re not all that terrific in assembler code. Stack frames are ideal for high-level languages, because they allow regular parameter-passing schemes and support dynamically allocated local variables. For assembler code, however, stack frames are quite limiting, in that they require a single consistent parameter-passing convention and the presence of code to create and destroy stack frames at the beginning and end of each subroutine. In particular, the ability of assembler code to pass pointers and variables in registers (which is much more efficient than pushing them on the stack) is constrained by standard stack frames conventions. In addition, the BP register, which is dedicated to pointing to stack frames, normally cannot be used for other purposes when stack frames are used; the loss of one of a mere seven generally-available 16-bit registers is not insignificant.

High-level language stack frame conventions also generally mandate the preservation of several registers — always BP, usually DS, and often SI and DI as well — and that requires time-consuming pushes and pops. Finally, while stack frame addressing is compact (owing to the heavy use of bp+disp addressing with 1-byte displacements), it is rather inefficient, even as memory-accessing instructions go; mov ax,[bp+disp8] is only 3 bytes long, but takes 21 cycles to execute.

In short, stack frames are powerful and useful — but they don’t make for the best possible 8088 code. The best compiled code, yes, but not the best assembler code.

What’s more, compilers handle stack frames very efficiently. If you’re going to work within the constraints of stack frames, you may have a difficult time out-coding compilers, which rarely miss a trick in terms of generating efficient stack frame code. Handling stack frames well is not so simple as it might seem; you have to be sure not to insert unneeded stack-frame-related code, such as code to load BP when there is no stack frame, and you need to be sure that you always preserve the proper registers when they’re altered, but not otherwise. It’s not hard, but it’s tedious, and it’s easy to make mistakes that either waste bytes or lead to bugs as a result of registers that should be preserved but aren’t.

When you work with stack frames, you’re trying to out-compile a compiler while playing by its rules, and that’s hard to do. In pure assembler code, I generally recommend against the use of stack frames, although there are surely exceptions to this rule. Personally, I often use C for the sort of code that requires stack frames, building only the subroutines that do the time-critical work in pure assembler. Why not let a compiler do the dirty work, while you focus your efforts on the code that really makes a difference?

When Stack Frames Are Useful

That’s not to say that stack frames aren’t useful in assembler. Stack frames are not only useful but mandatory when assembler subroutines are called from high-level language code, since the stack frame approach is the sole parameter-passing mechanism for most high-level language implementations.

Assembler subroutines for use with high-level languages are most useful; together, assembler subroutines and high-level languages provide relatively good performance and fast development time. The best code is written in assembler, but the best code within a reasonable time frame is often written in a high-level language/assembler hybrid. Then, too, high-level languages are generally better than assembler for managing the complexities of very large applications.

In short, stack frames are generally useful in assembler when assembler is interfaced to a high-level language. High-level language interfacing and stack frame organization varies from one language to another, however, so I’m not going to cover stack frames in detail, although I will offer a few tips about using stack frames in the next section. Before I do that, I’d like to point out an excellent way to mix assembler with high-level language code: in-line assembler. Many compilers offer the option of embedding assembler code directly in high-level language code; in many cases, high-level language and assembler variables and parameters can even be shared. For example, here’s a Turbo C subroutine to set the video mode:

void SetVideoMode(unsigned char ModeNumber) {
    asm   mov   ah,0
    asm   mov   al,byte ptr [ModeNumber]
    asm   int   10h
}

What makes in-line assembler so terrific is that it lets the compiler handle all the messy details of stack frames while freeing you to use assembler. In the above example, we didn’t have to worry about defining and accessing the stack frame; Turbo C handled all that for us, saving and setting up BP and substituting the appropriate BP+disp value for ModeNumber. In-line assembler is harder to use for large tasks than is pure assembler, but in most cases where the power of assembler is needed in a high-level language, in-line assembler is a very good compromise.

One warning: many compilers turn off some or all code optimization in subroutines that contain in-line assembler. For that reason, it’s often a good idea not to mix high-level language and in-line assembler statements when performance matters. Write your time-critical code either entirely in in-line assembler or entirely in pure assembler; don’t let the compiler insert code of uncertain quality when every cycle counts.

Still and all, when you need to create the fastest or tightest code, try to avoid stack frames except when you must interface your assembler code to a high-level language. When you must use stack frames, bear in mind that assembler is infinitely flexible; there are more ways to handle stack frames than are dreamt of in high-level languages. In Chapter 16 we’ll see an unusual but remarkably effective way to handle stack frames in a Pascal-callable assembler subroutine.

Tips on Stack Frames

Before we go on to xlat, I’m going to skim over a few items that you may find useful should you need to use stack frames in assembler code.

MASM provides the struc directive for defining data structures. Such data structures can be used to access stack frames, as in:

Parms   struc
    dw  ?             ;pushed BP
    dw  ?             ;return address
X   dw  ?             ;X coordinate parameter
Y   dw  ?             ;Y coordinate parameter
Parms end
        :
DrawXY  proc  near
    push  bp          ;save caller's stack frame pointer
    mov   bp,sp       ;point to stack frame
    mov   cx,[bp+X]   ;get X coordinate
    mov   dx,[bp+Y]   ;get Y coordinate
          :
    pop   bp
    ret
DrawXY    endp

MASM structures have a serious drawback when used with stack frames, however: they don’t allow for negative displacements from BP, which are generally used to access local variables stored on the stack. While it is possible to access local storage by accessing all variables in the stack frames at positive offsets from BP, as in:

Parms   struc
Temp    dw  ?           ;temporary storage
OldBP   dw  ?           ;pushed BP
        dw  ?           ;return address
X       dw  ?           ;X coordinate parameter
Y       dw  ?           ;Y coordinate parameter
Parms   end
            :
DrawXY  proc  near
    push  bp            ;save caller's stack frame pointer
    sub   sp,OldBP      ;make room for temp storage
    mov   bp,sp         ;point to stack frame
    mov   cx,[bp+X]     ;get X coordinate
    mov   dx,[bp+Y]     ;get Y coordinate
    mov   [bp+Temp],dx  ;set aside Y coordinate
          :
    add   sp,OldBP      ;dump temp storage space
    pop   bp
    ret
DrawXY  endp

this approach has two disadvantages. First, it prevents us from dumping temporary storage with mov sp,bp, requiring instead that we use the less efficient add sp,OldBP. Second, and more important, it makes it more likely that parameters will be accessed with a 2-byte displacement.

Why? Remember that a 1-byte displacement can address memory in the range -128 to +127 bytes away from BP. If our entire stack frame is addressed at positive offsets from BP, then we’ve lost the use of a full one-half of the addresses that we can access with 1-byte displacements.

Now, we can use negative stack frame offsets in assembler; it’s just a bit more trouble than we’d like. There are many possible solutions, ranging from a variety of ways to use equated symbols for stack frame variables, as in:

Temp  equ   -2  ;temporary storage
X     equ   4   ;X coordinate parameter
Y     equ   6   ;Y coordinate parameter

and:

Temp  equ   -2  ;temporary storage`
X     equ   4   ;X coordinate parameter`
Y     equ   X+2 ;Y coordinate parameter`

up to ways to get the assembler to adjust structure offsets for us. See my “On Graphics” column in the July 1987 issue of Programmer’s Journal (issue 5.4) for an elegant solution, provided by John Navas. (Incidentally, TASM provides special directives — arg and local — that handle many of the complications of stack frame addressing and allow negative offsets.)

While we’re discussing stack frame displacements, allow me to emphasize that you should strive to use 1-byte displacements into stack frames as much as possible. If you have so many parameters or local variables that 2-byte displacements must be used, make an effort to put the least frequently used variables at those larger displacements. Alternatively, you may want to put large data elements such as arrays and structures in the stack frame areas that are addressed with 2-byte displacements, since such data elements are often accessed by way of pointer registers such as BX and SI, rather than directly via bp+disp addressing. Finally, you should avoid forward references to structures; if you refer to elements of a structure before the structure itself is defined in the code, you’ll always get 2-byte displacements, as we’ll see in Chapter 14.

Whenever you’re uncertain whether 1-or 2-byte displacements are being used, simply generate a listing file, or look at your code with a debugger.

By the way, it’s worth examining the size of your stack frame displacements even in high-level languages. If you can figure out the order in which your compiler organizes data in a stack frame, you can often speed up and shrink your code simply by reorganizing your local variable declarations so that arrays and structures are at 2-byte offsets, allowing most variables to be addressed with 1-byte offsets.

Stack Frames Are Often in DS

While it’s not always the case, often enough the stack segment pointed to by SS and the default data segment pointed to by DS are one and the same. This is true in most high-level language memory models, and is standard for COM programs.

If DS and SS are the same, the implication is clear: all mod-reg-rm addressing modes can be used to point to stack frames. That’s a real advantage if you need to scan stack frame arrays and the like, because SI or DI can be loaded with the array start address and used to address the array without the need for segment override prefixes. Similarly, BX could be set to point to a stack frame structure, which could then be accessed by way of bx+disp addressing without a segment override. In short, be sure to take advantage of the extra stack frame addressing power that you have at your disposal when SS equals DS.

Use BP as a Normal Register if You Must

When stack frame addressing is in use, BP is normally dedicated to addressing the current stack frame. That doesn’t mean you can’t use BP as a normal register in a tight loop, though, and use it as a normal register you should; registers are too scarce to let even one go to waste when performance matters. Just push BP, use it however you wish in the loop, then pop it when you’re done, as in:

    push  bp            ;preserve stack frame pointer
    mov   bp,LOOP_COUNT ;get # of times to repeat loop
LoopTop:
          :
    dec   bp            ;count off loops
    loop  LoopTop
    pop   bp            ;restore stack frame pointer

Of course, the stack frame can’t be accessed while BP is otherwise occupied, but you don’t want to be accessing memory inside a tight loop anyway if you can help it.

Using BP as a normal register in a tight loop can make the difference between a register-only loop and one that accesses memory operands, and that can translate into quite a performance improvement. Also, don’t forget that BP can be used in mod-reg-rm addressing even when stack frames aren’t involved, so BP can come in handy as a memory-addressing register when BX, SI, and DI are otherwise engaged. In that usage, however, bear in mind that there is no BP-only memory addressing mode; either a 1-or 2-byte displacement or an index register (SI or DI) or both is always involved.

The Many Ways of Specifying mod-reg-rm Addressing

There are, it seems, more ways of specifying an operand addressed with mod-reg-rm addressing than you can shake a stick at. For example, [bp+MemVar+si], MemVar[bp+si], MemVar[si][bp], and [bp][MemVar+si] are all equivalent. Now stack frame addressing introduces us to a new form, involving the dot operator: [bp.MemVar+si]. Or [bp.MemVar.si]. What’s the story with all these mod-reg-rm forms?

It’s actually fairly simple. The dot operator does the same thing as the plus operator: it adds two memory addressing components together. Any memory-addressing component enclosed in brackets is also added into the memory address. The order of the operands doesn’t matter, since everything resolves to a mod-reg-rm byte in the end; mov al,[bx+si] assembles to exactly the same instruction as mov al,[si+bx]. All the constant values and symbols (variable names and equated values) in an address are added together into a single displacement, and that’s used with whatever memory addressing registers are present (from among BX, BP, SI, and DI) to form a mod-reg-rm address. (Of course, only valid combinations — the combinations listed in Figure 7.6 — will assemble.) Lastly, if memory addressing registers are present, they must be inside square brackets, but that’s optional for constant values and symbols.

There are a few other rules about constructing memory addressing operands, but I avoid those complications by making it a practice to use a single simple mod-reg-rm memory address notation. As I said at the start of this chapter, I prefer to put square brackets around all memory operands, and I also prefer to use only the plus operator. There are three reasons for this: it’s not complicated, it reminds me that I’m programming in assembler, not in a high-level language where complications such as array element size are automatically taken care of, and it reminds me that I’m accessing a memory operand rather than a register operand, thereby losing performance and gaining bytes.

You can use whatever mod-reg-rm addressing notation you wish. I do suggest, however, that you choose a single notation and stick with it. Why confuse yourself?

xlat

At long last, we come to the final addressing mode of the 8088. This addressing mode is unique to the xlat instruction, an odd and rather limited instruction that can nonetheless outperform every other 8088 instruction under the proper circumstances.

The operation of xlat is simple: AL is loaded from the offset addressed by the sum of BX and AL, as shown in Figure 7. 14. DS is the default data segment, but a segment override prefix may be used.

As you can see, xlat bears no resemblance to any of the other addressing modes. It’s certainly limited, and it always wipes out one of the two registers it uses to address memory (AL). In fact, the first thought that leaps to mind is: why would we ever want to use xlat?

If xlat were slow and large, the answer would be never. However, xlat is just 1 byte long, and, at 10 cycles, is as fast at accessing a memory operand as any 8088 instruction. As a result, xlat is excellent for a small but often time-critical category of tasks.

xlat excels when byte values must be translated from one representation to another. The most common example occurs when one character set must be translated to another, as for example when the ASCII character set used by the PC is translated to the EBCDIC character set used by IBM mainframes. In such a case xlat can form the heart of an extremely efficient loop, along the lines of the following:

;
; Converts the contents of an ASCII buffer to an EBCDIC buffer.
; Stops when a zero byte is encountered, but copies the zero byte.
;
; Input:
;     DS:SI = pointer to ASCII buffer.
;
; Output: none
;
; Registers altered: AL, BX, SI, DI, ES
;
    mov   di,ds
    mov   es,di
    mov   di,si       ;point ES:DI to the ASCII buffer as well
    mov   bx,offset ASCIIToEBCDICTable
                      ;point to the table containing the EBCDIC
                      ; equivalents of ASCII codes
    cld
ASCIIToEBCDICLoop:
    lodsb             ;get the next ASCII character
    xlat              ;convert it to EBCDIC
    stosb             ;put the result back in the buffer
    and   al,al       ;zero byte is the last byte
    jnz   ASCIIToEBCDICLoop

Besides being small and fast, xlat has an advantage in that byte-sized look-up values don’t need to be converted to words before they can be used to address memory. (Remember, mod-reg-rm addressing modes allow only word-sized registers to be used to address memory.) If we were to implement the look-up in the last example with mod-reg-rm instructions, the code would become a good deal less efficient no matter how efficiently we set up for mod-reg-rm addressing:

    sub   bh,bh       ;for use in converting a byte in BL
                      ;to a word in BX
    mov   si,offset ASCIIToEBCDICTable
                      ;point to the table containing the EBCDIC
                      ;equivalents of ASCII codes
ASCIIToEBCDICLoop:
    lodsb             ;get the next ASCII character
    mov   bl,al       ;get the character into BX, where
                      ;we can use it to address memory
    mov   al,[si+bx]  ;convert it to EBCDIC
    stosb             ;put the result back in the buffer
    and   al,al       ;zero byte is the last byte
    jnz   ASCIIToEBCDICLoop

In short, xlat is clearly superior when a byte-sized look-up is performed, so long as it’s possible to put both the look-up value and the result in AL. Shortly, we’ll see how xlat can be used to good effect in a case where it certainly isn’t the obvious choice.

Memory is Cheap: You Could Look It Up

xlat, simply put, is a table look-up instruction. A table look-up occurs whenever you use an index value to look up a result in an array, or table, of data. A rough analogy might be using the number on a ballplayer’s uniform to look up his name in a program.

Look-up tables are a superb way to improve performance. The basic premise of look-up tables is that it’s faster to precalculate results, either by letting the assembler do the work or by calculating the results yourself and inserting them in the source code, than it is to have the 8088 calculate them at run time. The key factor is this: the 8088 is relatively fast at looking up data in tables and slow at performing almost any kind of calculation. Given that, why not perform your calculations before run time, when speed doesn’t matter, and let the 8088 do what it does best at run time?

Now, look-up tables do have a significant disadvantage — they require extra memory. This is a trade-off we’ll see again and again in The Zen of Assembly Language: cycles for bytes. If you’re willing to expend more memory, you can almost always improve the performance of your code. One trick to generating top-notch code is knowing when that trade-off is worth making.

Let’s look at an example that illustrates the power of look-up tables. In the process, we’ll see an unusual but effective use of xlat; we’ll also see that there are many ways to approach any programming task, and we’ll get a first-hand look at the cycles-for-bytes tradeoff that arises so often in assembler programming.

Five Ways to Double Bits

The example we’re about to study is based on the article “Optimizing for Speed,” by Michael Hoyt, which appeared in Programmer’s Journal in March, 1986 (issue 4.2). This is the article I referred to back in Chapter 2 as an example of a programmer operating without full knowledge about code performance on the PC. By no means am I denigrating Mr. Hoyt; his article simply happens to be an excellent starting point for examining both look-up tables and the hazards of the prefetch queue cycle-eater.

The goal of Mr. Hoyt’s article was to expand a byte to a word by doubling each bit, for the purpose of converting display memory pixels to printer pixels in order to perform a screen dump. So, for example, the value 01h (00000001b) would become 0003h (0000000000000011b), the value 02h (00000010b) would become 000Ch (0000000000001100b), and the value 5Ah (01011010b) would become 33CCh (0011001111001100b). Now, in general this isn’t a particularly worthy pursuit, given that the speed of the printer is likely to be the limiting factor; however, speed could matter if the screen dump code is used by a background print spooler. At any rate, bit-doubling is an ideal application for look-up tables, so we’re going to spend some time studying it.

Mr. Hoyt started his article with code that doubled each bit by testing that bit and branching accordingly to set the appropriate doubled bit values. He then optimized the code by eliminating branches entirely, instead using fast shift and rotate instructions, in a manner similar to that used by Listing 7-14.

Eliminating branches isn’t a bad idea in general, since, as we’ll see in Chapter 12, branching is very slow. However, as we’ve already seen in Chapter 4, instruction fetching is also very slow… and the code in Listing 7-14 requires a lot of instruction fetching. 70 instruction bytes must be fetched for each byte that’s doubled, meaning that this code can’t possibly run in less than about 280 (70 times 4) cycles per byte doubled, even though its official Execution Unit execution time is scarcely 70 cycles.

The Zen timer confirms our calculations, reporting that Listing 7-14 runs in 6.34 ms, or about 300 cycles per byte doubled. (The excess cycles are the result of DRAM refresh.) As a result of this intensive instruction fetching, Mr. Hoyt’s optimized shift-and-rotate code actually ran slower than his original test-and-jump code, as discussed in my article “More Optimizing for Speed,” Programmer’s Journal, July, 1986 (issue 4.4).

So far, all we’ve done is confirm that the prefetch queue cycle-eater can cause code to run much more slowly than the official execution times would indicate. This is of course not news to us; in fact, I haven’t even bothered to show the test-and-jump code and contrast it with the shift-and-rotate code, since that would just restate what we already know. What’s interesting is not that Mr. Hoyt’s optimization didn’t make his code faster, but rather that a look-up table approach can make the code much faster. So let’s plunge headlong into look-up tables, and see what we can do with this code.

Table Look-Ups to the Rescue

Bit-doubling is beautifully suited to an approach based on look-up tables. There are only 256 possible input values, all byte-sized, and only 256 possible output values, all word-sized. Better yet, each input value maps to one and only one output value, and all the input values are consecutive, covering the range 0 to 255, inclusive.

Given those parameters, it should be clear that we can create a table of 256 words, one corresponding to each possible byte to be bit-doubled. We can then use each byte to be doubled as a look-up index into that table, retrieving the appropriate bit-doubled word with just a few instructions. Granted, 512 bytes would be needed to store the table, but the 50 or so instruction bytes we would save would partially compensate for the size of the table. Besides, surely the performance improvement from eliminating all those shifts, rotates, and especially instruction fetches would justify the extra bytes… wouldn’t it?

It would indeed. Listing 7-15, which uses the table look-up approach I’ve just described, runs in just 1.32 ms — more than four times as fast as Listing 7-14! When performance matters, trading less than 500 bytes for a more than four-fold speed increase is quite a deal. Listing 7-15 is so fast that it’s faster than Listing 7-14 would be even if there were no prefetch queue cycle-eater; in other words, the official execution time of Listing 7-15 is faster than that of Listing 7-14. Factor in instruction fetch time, though, and you have a fine example of the massive performance improvement that look-up tables can offer.

The key to Listing 7-15, of course, is that I precalculated all the doubled bit masks when I wrote the program. As a result, the code doesn’t have to perform any calculation more complex than looking up a precalculated bit mask at run time. In a little while, we’ll see how MASM can often perform look-up table calculations at assembly time, relieving us of the drudgery of precalculating results.

There Are Many Ways to Approach Any Task

Never assume that there’s only one way, or even one “best” way, to approach any programming task. There are always many ways to solve any given programming problem in assembler, and different solutions may well be superior in different situations.

Suppose, for example, that we’re writing bit-doubling code in a situation where size is more important than speed, perhaps because we’re writing a memory-resident program, or perhaps because the code will be used in a very large program that’s squeezed for space. We’d like to improve our speed, if we can — but not at the expense of a single byte. In this case, Listing 7-14 is preferable to Listing 7-15 — but is Listing 7-14 the best we can do?

Not by a long shot.

What we’d like to do is somehow shrink Listing 7-15 a good deal. Well, Listing 7-15 is so large because it has a 512-byte table that’s used to look up the bit-doubled words that can be selected by the 256 values that can be stored in a byte. We can shrink the table a great deal simply by converting it to a 16-byte table that’s used to look up the bit-doubled bytes that can be selected by the 16 values that can be stored in a nibble (4 bits), and performing two look-ups into that table, one for each half of the byte being doubled.

Listing 7-16 shows this double table look-up solution in action. This listing requires only 23 bytes of code for each byte doubled, and even if you add the 16-byte size of the table in, the total size of 39 bytes is still considerably smaller than the 70 bytes needed to bit-double each byte in Listing 7-14. What’s more, the table only needs to appear once in any program, so practically speaking Listing 7-16 is much more compact than Listing 7-14.

Listing 7-16 also is more than twice as fast as Listing 7-14, clocking in at 2.52 ms. Of course, Listing 7-16 is nearly twice as slow as Listing 7-15 — but then, it’s much more compact.

There’s that choice again: cycles or bytes.

In truth, there are both cycles and bytes yet to be saved in Listing 7-16. If we apply our knowledge of mod-reg-rm addressing to Listing 7-16, we’ll realize that it’s a waste to use base+displacement addressing with the same displacement twice in a row; we can save a byte and a few cycles by loading SI with the displacement and using base+index addressing instead. Listing 7-17, which incorporates this optimization, runs in 2.44 ms, a bit faster than Listing 7-16.

There’s yet another optimization to be made, and this one brings us full circle, back to the start of our discussion of look-up tables. Think about it: Listing 7-17 basically does nothing more than use two nibble values as look-up indices into a table of byte values. Sound familiar? It should — that’s an awful lot like a description of xlat. (xlat can handle byte look-up values, but this task is just a subset of that.)

Listing 7-18 shows an xlat-based version of our bit-doubling code. This code runs in just 1.94 ms, still about 50% slower than the single look-up approach, but a good deal faster than anything else we’ve seen. Better yet, this approach takes just 16 instruction bytes per bit-doubled byte (32 if you count the table) — which makes this by far the shortest approach we’ve seen. Comparing Listing 7-18 to Listing 7-14 reveals that we’ve improved the code to an astonishing degree: Listing 7-18 runs more than three times as fast as Listing 7-14, and yet it requires less than one-fourth as many instruction bytes per bit-doubled byte.

There are many lessons here. First, xlat is extremely efficient at performing the limited category of tasks it can manage; when you need to use a byte index into a byte-sized look-up table, xlat is often your best bet. Second, the official execution times aren’t a particularly good guide to writing high-performance code. (Of course, you already knew that!) Third, there is no such thing as the best code, because the fastest code is rarely the smallest code, and vice-versa.

Finally, there are an awful lot of solutions to any given programming problem on the 8088. Don’t fall into the trap of thinking that the obvious solution is the best one. In fact, we’ll see yet another solution to the bit-doubling problem in Chapter 9; this solution, based on the sar instruction, isn’t like any of the solutions we’ve seen so far.

We’ll see look-up tables again in Chapter 14, in the form of jump tables.

Video Programming and I/O

I’d like to make one final point about I/O addressing. This section won’t mean much to you if you haven’t worked with video programming, and I’m not going to explain it further now; we’ll return to the topic when we discuss video programming in Volume II. For those of you who are involved with video programming, however, here goes.

Word-sized out instructions — out dx,ax — unquestionably provide the fastest way to set the indexed video registers of the CGA, EGA, and VGA. Just put the index of the video register you’re setting in AL and the value you’re setting the register to in AH, and out dx,ax sets both the index and the register in a single instruction. Using byte-sized out instructions, we’d have to do all this to achieve the same results:

out   dx,al
inc   dx
xchg  ah,al
out   dx,al
dec   dx
xchg  ah,al

(Sometimes you can leave off the final dec and xchg, but the word-sized approach is still much more efficient.)

However, there’s a potential pitfall to the use of word-sized out instructions to set indexed video registers. The 8088 can’t actually perform word-sized I/O accesses, since the bus is only 8 bits wide. Consequently, the 8088 breaks 16-bit I/O accesses into two 8-bit accesses, one sending AL to the addressed port, and a second one sending AH to the addressed port plus one. (If you think about it, you’ll realize that this is exactly how the 8088 handles word-sized memory accesses too.)

All well and good. Unfortunately, on computers built around the 8086, 80286, and the like, the processors do not automatically break up word-sized I/O accesses, since they’re fully capable of outputting 16 bits at once. Consequently, when word-sized accesses are made to 8-bit adapters like the EGA by code running on such computers, it’s the bus, not the processor, that breaks up those accesses. Generally, that works perfectly well — but on certain PC — compatible computers, the bus outputs the byte in AH to the addressed port plus one first, and then sends the byte in AL to the addressed port. The correct values go to the correct ports, but here sequence is critical; out dx,ax to an indexed video register relies on the index in AL being output before the data in AH, and that simply doesn’t happen. As a result, the data goes to the wrong video register, and the video programming works incorrectly — sometimes disastrously so.

You may protest that any computer that gets the sequencing of word-sized out instructions wrong isn’t truly a PC-compatible, and I suppose that’s so. Nonetheless, if a computer runs everything except your code that uses word-sized out instructions, you’re going to have a tough time selling that explanation. Consequently, I recommend using byte-sized out instructions to indexed video registers whenever you can’t be sure of the particular PC-compatible models on which your code will run.

Avoid Memory!

We’ve come to the end of our discussion of memory addressing. Memory addressing on the 8088 is no trivial matter, is it? Now that we’ve familiarized ourselves with the registers and memory addressing capabilities of the 8088, we’ll start exploring the instruction set, a journey that will occupy most of the rest of this volume.

Before we leave the realm of memory addressing, let me repeat: avoid memory. Use the registers to the hilt; register-only instructions are shorter and faster. If you must access memory, try not to use mod-reg-rm addressing; the special memory-accessing instructions, such as the string instructions and xlat, are generally shorter and faster. When you do use mod-reg-rm addressing, try not to use displacements, especially 2-byte displacements.

Last but not least, choose your spots. Don’t waste time optimizing non-critical code; focus on loops and other chunks of code in which every cycle counts. Assembler programming is not some sort of game where the object is to save cycles and bytes blindly. Rather, the goal is a dual one: to produce whole programs that perform well and to produce those programs as quickly as possible. The key to doing that is knowing how to optimize code, and then doing so in time-critical code — and only in time-critical code.

More Than a Passing Resemblance

In general, the 8088’s instruction set reflects the influence of the 8080 fairly strongly. While the 8088’s instruction set is a considerable superset of the 8080’s, there are few 8080 instructions that can’t be emulated by one (or at most two) 8088 instructions, and there are several 8088 instructions that most likely would not exist were it not for the 8080 legacy. Also, although it’s only speculation, it certainly seems possible that the segmented memory architecture of the 8088 is at least partially the result of needing to reconcile the 1 Mb address space of the 8088 with the 8-and 16-bit nature of the registers the 8088 inherited from the 8080. (Segmentation does allow some types of code to be more compact than it would be if the 8088 had an unsegmented address space, so let’s not blame segmentation entirely on the 8080.)

The 8088 is without question a more powerful processor than the 8080, with far more flexible addressing modes and register usage, but it is nonetheless merely a 16-bit extension of the 8080 in many ways, rather than a processor designed from scratch. We can only speculate as to what the capabilities of an 8088 built without regard for the 8080 might have been — but a glance at the 68000’s 16 Mb linear address space and large 32-bit register set gives us a glimpse of that future that never was.

At any rate, the 8088 was designed with the 8080 in mind, and the orientation of the 8088’s instruction set toward porting 8080 programs seems to have served its purpose. Many 8080 programs, including WordStar and VisiCalc, were ported to the 8088, and those ported programs helped generate the critical mass of software that catapulted the 8088 to a position of dominance in the microcomputer world. How much of the early success of the 8088 was due to ported 8080 software and how much resulted from the letters “IBM” on the nameplate of the PC is arguable, but ported 8080 software certainly sold well for some time.

Today the need for 8080 source-level compatibility is long gone, but that 8080-oriented instruction set is with us still, and seems likely to survive well into the 21st century in the silicon of the 80386 and its successors. (Amazingly, every processor shown in Figure 3-5 provides full 8088 compatibility, and it’s a safe bet that future generations will be compatible as well. In fact, although it hasn’t happened as of this writing, it appears that some non-Intel manufacturers may build 8088-compatible subprocessors into their chips!)

The 8080 flavor of the 8088’s instruction set is both a curse and a blessing. It’s a curse because it limits the performance of average 8088 code, and a blessing because it provides great opportunity for assembler code to shine. In particular, the 8080-specific instructions occupy valuable space in the 8088 opcode set — arguably causing native 8088 code (as opposed to ported 8080 code) to be larger and slower than it would otherwise be — and that is, by-and-large, one of the less appealing aspects of the 8088. For the assembler programmer, however, the 8080-specific instructions can be an asset. Since those instructions are faster and more compact than their general-purpose counterparts, they can often be used to create significantly better code. Next, we’ll examine the 8080-specific instructions in detail.

Accumulator-Specific Direct-Addressing Instructions

The 8088 lets you address memory operands in a great many different ways — 16 ways, to be precise, as we saw in Chapter 7. This flexibility is one of the strengths of the 8088, and is one way in which the 8088 far exceeds the 8080. There’s a price for that flexibility, though, and that’s the mod-reg-rm byte, which we encountered in Chapter 7. To briefly recap, the mod-reg-rm byte is a second instruction byte, immediately following the opcode byte of most instructions that access memory, which specifies which of 32 possible addressing modes are to be used to select the source and/or destination for the instruction. (8 of the addressing modes are used to select the 8 general-purpose registers as operands, and 8 addressing modes differ only in the size of the displacement field, hence the discrepancy between the 32 addressing modes and the 16 ways to address memory operands.) Together, the mod-reg-rm byte and the 16-bit displacement required for direct addressing mean that any instruction that uses mod-reg-rm direct addressing must be at least 4 bytes long, as shown in Figure 8.2.

Direct addressing is used whenever you simply want to refer to a memory location by name, with no pointing or indexing. For example, a counter named Count could be incremented with direct addressing as follows:

inc   [Count]

Direct addressing is intuitive and convenient, and is one of the most heavily used addressing modes of the 8088.

Since direct addressing is one of the very few addressing modes of the 8080, and since the 8088’s designers needed to make sure that ported 8080 code ran reasonably well on the 8088, there are 8088 instructions that do nothing more than load and store the accumulator from and to memory via direct addressing. These instructions are only 3 bytes long, as shown in Figure 8.3; better yet, they execute in just 10 cycles, rather than the 14 (memory read) or 15 (memory write) cycles required by mod-reg-rm memory accesses that use direct addressing. (Those cycle counts are for byte-sized accesses; add 4 cycles to both forms of mov for word-sized accesses.)

Looks Aren’t Everything

One odd aspect of the accumulator-specific direct-addressing instructions is that in assembler form they don’t look any different from the more general form of the mov instruction; the difference between the two versions only becomes apparent in machine-language. So, for example, while:

mov   al,[Count]

and:

mov   dl,[Count]

look like they refer to the same instruction, the machine code assembled from the two differs greatly, as shown in Figure 8.4; the first instruction is a byte shorter and 4 cycles faster than the second.

Odder still, there are actually two legitimate machine-language forms of the assembler code for each of the accumulator-specific direct-addressing instructions (and, indeed, for all the accumulator-specific instructions discussed in this chapter), as shown in Figure 8.5. Any 8088 assembler worth its salt automatically assembles the shorter form, of course, so the longer, general-purpose versions of the accumulator-specific instructions aren’t used. Still, the mere existence of two forms of the accumulator-specific instructions points up the special-case nature of these instructions and the general irregularity of the 8088’s instruction set.

How Fast Are They?

How much difference does the use of the accumulator-specific direct-addressing instructions make? Generally, less difference than the official timings in Appendix A would indicate, but a significant difference

nonetheless — and you save a byte every time you use an accumulator-specific direct-addressing instruction, as well.

Suppose you want to copy the value of one byte-sized memory variable to another byte-sized memory variable. A common way to perform this simple task is to read the value of the first variable into a register, then write the value from the register to the other variable. Listing 8-1 shows a code fragment that performs such a byte copy 1000 times by way of the AH register. Since the accumulator is neither source nor destination in Listing 8-1, the 4-byte mod-reg-rm direct-addressing form of mov is assembled for each instruction; consequently, 8 bytes of code are assembled in order to copy each byte via AH, as shown in Figure 8.6. (Remember that AH is not considered the accumulator. For 8-bit operations, AL is the accumulator, and for 16-bit operations, AX is the accumulator, but AH by itself is just another general-purpose register.)

Plugged into the Zen timer test program, Listing 8-1 yields an average time per byte copied of 10.06 us, or about 48 cycles per byte copied. That’s considerably longer than the 29 cycles per byte copied you’d expect from adding up the official cycle times given in Appendix A; the difference is the result of the prefetch queue and dynamic RAM refresh cycle-eaters. We can’t cover all the aspects of code performance at once, so for the moment let’s just discuss the implications of the times reported by the Zen timer. Remember, no matter how much theory of code performance you’ve mastered, there’s still only one reliable way to know how fast PC code really is — measure it!

Listing 8-2 performs the same 1000 byte copies as Listing 8-1, but does so by way of the 8-bit accumulator, AL. In Listing 8-2, 6 bytes of code are assembled in order to copy each byte by way of AL, as shown in Figure 8.7. Each mov instruction in Listing 8-2 is a byte shorter than the corresponding instruction in Listing 8-1, thanks to the 3-byte size of the accumulator-specific direct-addressing mov instructions. The Zen timer reports that copying by way of the accumulator reduces average time per byte copied to 7.55 microseconds, which works out to about 36 cycles per byte — a 33% improvement in performance over Listing 8-1.

Enough said.

When Should You Use Them?

The implications of accumulator-specific direct addressing are obvious: whenever you need to read or write a direct-addressed memory operand, do so via the accumulator if at all possible. You can take this a step further by running unorthodox applications of accumulator-specific direct addressing through the Zen timer to see whether they’re worth using. For example, one common use of direct addressing is checking whether a flag or count is zero, with an instruction sequence like:

cmp   [NumberOfShips],0   ;5 bytes/20 cycles
jz    NoMoreShips         ;2 bytes/16 or 4 cycles

In this example, NumberOfShips is accessed with mod-reg-rm direct addressing. We’d like to use accumulator-specific direct addressing, but because this is a cmp instruction rather than a mov instruction, it would seem that accumulator-specific direct addressing can’t help us.

Even here, however, accumulator-specific direct addressing can help speed things up a bit. Since we’re only interested in whether NumberOfShips is zero or not, we can load it into the accumulator and then and the accumulator with itself to set the zero flag appropriately, as in:

mov   ax,[NumberOfShips]    ;3 bytes/14 cycles
and   ax,ax                 ;2 bytes/3 cycles
jz    NoMoreShips           ;2 bytes/16 or 4 cycles

While the accumulator-specific version is longer in terms of instructions, what really matters is that both code sequences are 7 bytes long, and that the cycle time for the accumulator-specific code is 3 cycles less according to the timings in Appendix A.

Of course, we only trust what we measure for ourselves, so we’ll run the code in Listings 8-3 and 8-4 through the Zen timer. The Zen timer reports that the accumulator-specific means of testing a memory location and setting the appropriate zero/non-zero status executes in 6.34 us per test, more than 6% faster than the 6.76 us time per test of the standard test-for-zero code. While 6% isn’t a vast improvement, it is an improvement, and that boost in performance comes at no cost in code size. In addition, the accumulator-specific form leaves the variable’s value available in the accumulator after the test is completed, allowing for faster code yet if you need to manipulate or test that value further. The flip side is that the accumulator-specific direct-addressing approach requires that the test value be loaded into the accumulator, so if you’ve got something stored in the accumulator that you don’t want to lose, by all means use the mod-reg-rm cmp instruction.

Don’t get hung up on using nifty tricks for their own sake. The object is simply to select the best instructions for the task at hand, and it matters not in the least whether those instructions happen to be dazzlingly clever or perfectly straightforward.

Don’t expect that unorthodox uses of accumulator-specific direct addressing will always pay off, but try them out anyway; they might speed up your code, and even if they don’t, your experiments might well lead to something else worth knowing. For instance, based on the official execution times in Appendix A it appears that:

mov   ax,1                ;3 bytes/4 cycles
mov   [InitialValue],ax   ;3 bytes/14 cycles

should be faster than:

mov   [InitialValue],1    ;6 bytes/20 cycles

running Listings 8-5 and 8-6 through the Zen timer, however, we find that both versions take exactly 7.54 us per initialization. The execution time in both cases is determined by the number of memory accesses rather than by Execution Unit execution time, and both versions perform 8 memory accesses per initialization (6 instruction byte fetches and 1 word-sized memory operand access).

While that particular trick didn’t work out, it does suggest another possibility. Suppose that we want to initialize the variable InitialValue to the specific value of zero; now we can modify Listing 8-5 to:

sub   ax,ax               ;2 bytes/3 cycles`
mov   [InitialValue],ax   ;3 bytes/14 cycles`

which is both 1 byte shorter and 3 cycles faster than the mod-reg-rm instruction:

mov   word ptr [InitialValue],0   ;6 bytes/20 cycles

Code that’s shorter in both bytes and cycles (remember, we’re talking about official cycles, as listed in Appendix A) almost always provides superior performance, and Listing 8-7 does indeed clock the accumulator-specific initialize-to-zero approach at 6.76 us per initialization, more than 11% faster than Listing 8-6.

Actively pursue the possibilities in your assembler code. You never know where they might lead.

Accumulator-Specific Immediate-Operand Instructions

The 8088 also offers special accumulator-specific versions of a number of arithmetic and logical instructions — adc, add, and, cmp, or, sub, sbb, and xor — when these instructions are used with one register operand and one immediate operand. (Remember that an immediate operand is a constant operand that is built right into an instruction.) The mod-reg-rm immediate-addressing versions of the above instructions, when used with a register as the destination operand, are 3 bytes long for byte comparisons and 4 bytes long for word comparisons, as shown in Figure 8.8. The accumulator-specific immediate-addressing versions, on the other hand, are 2 bytes long for byte comparisons and 3 bytes long for word comparisons, as shown in Figure 8.9. Although the official cycle counts listed in Appendix A for all immediate-addressing forms of these instructions — accumulator-specific or otherwise — are all 4 when used with a register as the destination, shorter is generally faster, thanks to the prefetch queue cycle-eater.

Let’s see how much faster the accumulator-specific immediate-addressing form of cmp is than the mod-reg-rm version. (The results will hold true for all 8 accumulator-specific immediate-addressing instructions, since they all have the same sizes and execution times.) The Zen timer reports that each accumulator-specific cmp in Listing 8-8 takes 1.81 us, making it 50% faster than the mod-reg-rm version in Listing 8-9, which clocks in at 2.71 us per comparison. It is not in the least coincidental that the ratio of the execution times, 3:2, is the same as the ratio of instruction lengths in bytes; the performance difference is entirely due to the difference in instruction lengths.

There are two caveats regarding accumulator-specific immediate-addressing instructions. First, unlike the accumulator-specific form of the direct-addressing mov instruction, the accumulator-specific immediate-addressing instructions can’t work with memory operands. For instance, add al,[Temp] assembles to a mod-reg-rm instruction, not to an accumulator-specific instruction.

Second, there’s no advantage to using the accumulator-specific immediate-addressing instructions when they’re used with word-sized immediate operands in the range -128 to +127 (inclusive), although there’s no disadvantage, either. This is true because the word-sized mod-reg-rm equivalents of the accumulator-specific instructions can store immediate values in this range as bytes and then sign-extend them to words at execution time, while the accumulator-specific immediate-addressing instructions cannot, as shown in Figure 8.10. Consequently, both forms of these instructions are 3 bytes long when used with immediate operands in the range -128 to +127.

An important note: some 8088 references indicate that while immediate operands to arithmetic instructions can be sign-extended, immediate operands to logical instructions — xor, and, and or — cannot. Not true! Immediate operands to logical instructions can be sign-extended, and MASM does so automatically whenever possible.

Remember, if you’re not sure exactly what instructions the assembler is generating from your source code, you can always look at the instructions directly with a disassembler. Alternatively, you can look at the assembled hex bytes at the left side of the assembly listing.

An Accumulator-Specific Example

Let’s look at a real-world example of saving bytes and cycles with accumulator-specific instructions. We’re going to force the adapter-select bits — bits 5 and 4 of the BIOS equipment flag variable at 0000:0410 — to the setting for an 80-column color adapter. This requires first forcing the adapter-select bits to 0, then setting bit 5 to 1 and bit 4 to 0.

The simplest approach to setting the equipment flag to 80-column color text mode is shown in Listing 8-10; this code uses one mod-reg-rm and instruction and one mod-reg-rm or instruction to set the equipment flag in 18.86 us. By contrast, Listing 8-11 uses four accumulator-specific instructions to set the equipment flag. Even though Listing 8-11 uses two more instructions than Listing 8-10, it is 12.5% faster, taking only 16.76 us to set the equipment flag.

Other Accumulator-Specific Instructions

There are two more instructions that have accumulator-specific versions: test and xchg. Although these instructions have no direct equivalents in the 8080 instruction set, we’ll cover them now while we’re on the topic of accumulator-specific instructions. (While the 8080 does offer some exchange instructions, the 8088’s accumulator-specific form of xchg doesn’t correspond directly to any of those 8080 instructions.)

The Accumulator-Specific Version Of test

test sets the flags as if an and had taken place, but does not modify the destination. As with and, there’s an accumulator-specific immediate-addressing version of test that’s a byte shorter than the mod-reg-rm immediate version. (Unlike and, the accumulator-specific version of test is also a cycle faster than the mod-reg-rm version.) So, for example:

test    al,1

is a byte shorter and a cycle faster than:

test    dh,1

The Ax-Specific Version of xchg

In its general form, xchg swaps the values of two registers, or of a register and a memory location. The mod-reg-rm register-register interchange form of xchg is 2 bytes long and executes in 4 cycles. There is, however, a special form of xchg specifically for interchanging AX (not AL) with any of the 8 general-purpose registers. This AX-specific form is just 1 byte long and executes in a mere 3 cycles. So, for example:

xchg    ax,bx

is 1 byte and 1 cycle shorter than:

xchg    al,bl

as shown in Figure 8.11. In fact:

xchg    ax,bx

is 1 byte shorter (albeit 1 cycle slower) than:

mov     ax,bx

so the AX-specific form of xchg can be an attractive alternative to mov when you don’t require that the copied value remain in the source register after the copy.

When else might the AX-specific version of xchg be useful? Suppose that we’ve got a loop in which we need to add together elements from two arrays, subtract from that sum a value from a third array, and store the result in a fourth array. Suppose further that we can’t use BP, perhaps because it’s dedicated to maintaining a stack frame. What’s more, the pointers to the arrays are passed in, so we can’t just use one pointer register as an array subscript by way of displacement+base addressing. Now we’ve got a bit of a problem: there are only three registers other than BP capable of addressing memory, but we need pointers to four arrays. We could, of course, load two or more of the pointers from memory each time through the loop, but that would slow processing considerably. We could also store two of the pointers in other registers and copy them into, say, BX as we need them, but that would require us to use three registers to maintain two pointers, and, as it happens, we don’t have a register to spare.

The solution is to keep one pointer in BX and one in AX, and swap them as needed via the AX-specific form of xchg. (As usual, the assembler automatically uses the most efficient possible form of xchg; you don’t have to worry about explicitly selecting it.) Listing 8-12 show an implementation that uses the AX-specific form of xchg to handle our four-array case without accessing memory or using BP.

Listing 8-12 is intentionally constructed to allow us to use the AX-specific form of xchg. It’s natural to choose AL, not DL, as the register used for adding and moving data, but if we had done that, then the xchg would have become xchg dx,bx, which is the 2-byte mod-reg-rm version. Listing 8-13 shows this less-efficient version of Listing 8-12. Thanks solely to the AX-specific form of xchg, Listing 8-12 executes in 21.12 us per array element, 7% faster than the 22.63 us per array element of Listing 8-13. (By the way, we could revamp Listing 8-13 to run considerably faster by using the lodsb and stosb string instructions, but for the moment we’re focusing on the AX-specific form of xchg. Nonetheless, there’s a lesson here: be careful not to become fixated on a particular trick to the point where you miss other and possibly better approaches.)

The important point is that in 8088 assembler it often matters which registers and/or which forms of various instructions you select. Two seemingly similar code sequences, such as Listings 8-12 and 8-13, can actually have quite different performance characteristics.

Yet another aspect of the Zen of assembler.

lahf and sahf: An Example

Let’s look at lahf and sahf in action. Suppose we have a loop in which a value stored in AL is added to each element of a byte array, with the loop ending only when the result of any addition exceeds 7Fh, causing the Sign flag to be set. Unfortunately, the array pointer must be incremented after the addition, wiping out the Sign flag that we need to test at the bottom of the loop, so we need some way to preserve the Sign flag during execution of the instruction that increments the array pointer.

Listing 8-14 solves this problem by using pushf and popf to preserve the Sign flag. The Zen timer reports that with this approach it takes 16.45 ms to process 1000 array elements, or 16.45 us per element. Astoundingly, Listing 8-15, which is exactly the same as Listing 8-14 save that it uses lahf and sahf instead of pushf and popf, takes only 11.31 ms, or 11.31 us per array element — a performance improvement of 45%! (That’s a 45% improvement in the whole loop; the performance advantage of just lahf and sahf versus pushf and popf in this loop is far greater, in the neighborhood of 200%.)

Onward Through the Instruction Set

Given the extent to which the 8080 influenced the decidedly unusual architecture and instruction set of the 8088, it is interesting (although admittedly pointless) to wonder what might have been had the 8080 been less successful, allowing Intel to make a clean break with the past when the 8088 was designed. Still, the 8088 is what it is — so it’s on to the rest of the instruction set for us.

Making Zero

For starters, there is almost never any reason to assign the immediate value zero to a register. Why assign zero to a register when sub reg,reg or xor reg,reg always zeros the register in fewer cycles (and also in fewer bytes for 16-bit registers)? The only time you should assign the value zero to a register rather than clearing the register with sub or xor is when you need to preserve the flags, since mov doesn’t affect the flags but sub and xor do.

Initializing Constants From the Registers

As we discussed in the last chapter, it pays to clear a direct-addressed memory variable by zeroing AL or AX and storing that register to the memory variable. If you’re setting two or more direct-addressed variables to any specific value (and here we’re talking about any value, not just zero), it’s worth storing that value in the accumulator and then storing the accumulator to the memory variables. (When initializing large blocks of memory, rep stos works better still, as we’ll see in Chapter 10.) The basic principle is this: avoid extra immediate-operand bytes by storing frequently-used constants in registers and using the registers as operands.

Listing 9-1 provides an example of initializing multiple memory variables to the same value. This listing, which stores 0FFFFh in AX and then stores AX to three memory variables, executes in 17.60 us per three-word initialization. That’s more than 28% faster than the 22.63 us per initialization of Listing 9-2, which stores the immediate value 0FFFFh to each of the three words. Listing 9-1 is that much faster than Listing 9-2 even though Listing 9-1 is one instruction longer per initialization. The difference? Each of the three mov instructions in Listing 9-2 is 3 bytes longer than the corresponding mov in Listing 9-1: two bytes are taken up by the immediate value 0FFFFh, and one extra byte is required because the accumulator-specific direct-addressing form of mov isn’t used. That’s a total of 9 extra bytes for the three mov instructions of Listing 9-2, more than offsetting the 3 bytes required by the extra instruction mov ax,0ffffh of Listing 9-1. (Remember, the 8088 doesn’t sign-extend immediate operands to mov.) As always, those extra bytes take 4 cycles each to fetch. Shorter is better.

If you’re initializing more than one register to zero, you can save 1 cycle per additional register by initializing just one of the registers, then copying it to the other registers, as follows:

sub   si,si   ;point to offset 0 in DS
mov   di,si   ;point to offset 0 in ES
mov   dx,si   ;initialize counter to 0

While mov reg,reg is 2 bytes long, the same as sub reg,reg, according to the official specs mov is the faster of the two by 1 cycle. Whether this translates into any performance advantage depends on the code mix — if the prefetch queue is empty, code fetching time will dominate and mov will have no advantage — but it can’t hurt and might help.

Similarly, if you’re initializing multiple 8-bit registers to the same non-zero value, you can save up to 2 cycles per additional register by initializing one of the registers and copying it to the other(s). While mov reg,immed8 is 2 cycles slower than mov reg,reg, both instructions are the same size.

Finally, if you’re initializing multiple 16-bit registers to the same non-zero value, it always pays to initialize one register and copy it to the other(s). The reason: mov reg,immed16, at 3 bytes in length, is a byte longer (and 2 cycles slower) than mov reg,reg.

Initializing Two Bytes With a Single mov

While we’re on the topic of initializing registers and variables, let’s take a quick look at initializing paired bytes. Suppose we want to initialize AH to 16h and AL to 1. The obvious solution is to set each register to the desired value:

mov   ah,16h
mov   al,1

However, a better solution is to set the pair of registers with a single mov:

mov   ax,1601h

The paired-register initialization is a byte shorter and 4 cycles faster… and does exactly the same thing as the separate initializations!

A trick that makes it easier to initialize paired 8-bit registers is to shift the value for the upper register by 8 bits. For example, the last initialization could be performed as:

mov   ax,(16h shl 8) + 1

This method has two benefits. First, it’s easy to distinguish between the values for the upper and lower registers; 16 and 1 are easy to pick out in the above example. Second, it’s much simpler to handle non-hexadecimal values by shifting and adding. You must admit that:

mov   dx,(201 shl 8) + 'A'

is easier to write and understand than:

mov   dx,0c941h   ;DH=201, DL='A'

You need not limit paired-byte initializations to registers. Adjacent byte-sized memory variables can be initialized with a single word access as well. If you do use paired-byte initializations of memory variables, though, be sure to place prominent comments around the memory variables; otherwise, you or someone else might accidentally separate the pair at a later date, ruining the initialization.

More Fun With Zero

What else can we do with zero? Well, we can test the zero/non-zero status of a register with either and reg,reg or or reg,reg. Both of these instructions set the Zero flag just as cmp reg,0 would… and they execute faster and are anywhere from 0 to 2 bytes shorter than cmp. (Both and reg,reg and or reg,reg are guaranteed to be at least 1 byte shorter than cmp reg,0 except when reg is AL, in which case all three instructions are the same length.) Listing 9-3, which uses and dx,dx to test for the zero status of DX, clocks in at 3.62 us per test. That’s 25% faster than the 4.53 us per test of Listing 9-4, which uses cmp dx,0.

As described in the last chapter, it is (surprisingly) faster to load the accumulator from a direct-addressed memory variable and and or or the accumulator with itself in order to test whether that memory variable is zero than it is to simply compare the memory variable with an immediate operand. For instance:

mov   al,[ByteFlag]
and   al,al
jnz   FlagNotZero

is equivalent to and faster than:

cmp   [ByteFlag],0
jnz   FlagNotZero

Finally, there are some cases in which tests that are really not zero/non-zero tests can be converted to tests for zero. For example, consider a test to check whether or not DX is 0FFFFh. We could use cmp dx,0ffffh, which is three bytes long and takes 4 cycles to execute. On the other hand, if we don’t need to preserve DX (that is, if we’re performing a one-time-only test) we could simply use inc dx, which is only one byte long and takes just 2 cycles to execute, and then test for a zero/non-zero status. So, if we don’t mind altering DX in the course of the test:

cmp   dx,0ffffh
jnz   NotFFFF

and:

inc   dx
jnz   NotFFFF

are functionally the same… save that the latter version is much smaller and faster.

A similar case of turning a test into a zero/non-zero test occurs when testing a value for membership in a short sequence of consecutive numbers — the equivalent of a C switch construct with just a few cases consisting of consecutive values. (Longer and/or non-consecutive sequences should be handled with look-up tables.) For example, suppose that you want to perform one action if CX is 4, another if CX is 3, a third action if CX is 2, and yet another if CX is 1. Listing 9-5, which uses four cmp instructions to test for the four cases of interest, runs in 17.01 us per switch handled. That’s a good 4.94 us slower per switch than the 12.07 us of Listing 9-6, so Listing 9-5 runs at less than 75% of the speed of Listing 9-6. Listing 9-6 gets its speed boost by using the 1-byte dec cx instruction rather than the 3-byte cmp cx,immed8 instruction to test for each of the four cases, thereby turning all the tests into zero/non-zero tests.

Unorthodox, yes — but very effective. The moral is clear: even when the 8088 has an instruction that’s clearly intended to perform a given task (such as cmp for comparing), don’t assume that instruction is the best way to perform that task under all conditions.

Using 16-Bit inc and dec Instructions for 8-Bit Operations

If you’re clever, you can sometimes use the 16-bit form of inc or dec even when you only want to affect an 8-bit register. Consider Listing 9-11, which uses AL to count from 0 to 8. Since AL will never pass 0FFh and turn over (the only circumstance in which inc ax modifies AH), it’s perfectly safe to use inc ax rather than inc al. In this case, both instructions always produce the same result; however, inc ax produces that result considerably more rapidly than inc al. If you do use such a technique, however, remember that the flags are set on the basis of the whole operand. For example, dec ax will set the Zero flag only when both AH and AL — not AL alone — go to zero. This seems obvious, but if you’re thinking of AL as the working register, as in Listing 9-11, it’s easy to forget that dec ax sets the flags to reflect the status of AX, not AL.

To carry the quest for inc and dec efficiency to the limit, suppose we’re constructing code which contains nested countdown loops. Suppose further that all registers but CX are in use, so all we’ve got available for counters are CH and CL. Normally, we would expect to use two 8-bit dec instructions here. However, we know that the counter for the inner loop is 0 after the loop is completed, so we’ve got an opportunity to perform a 16-bit dec for the outer loop if we play our cards right.

Listing 9-12 shows how this trick works. CH is the counter for the inner loop, and we are indeed stuck with an 8-bit dec for this loop. However, by the time we get around to using CL as a counter, CH is guaranteed to be 0, so we can use a 16-bit dec cx for the outer loop. Granted, it would be preferable to place the 16-bit dec in the time-critical inner loop, and if that loop were long enough, we might well do that by pushing CX for the duration of the inner loop; nonetheless, a 16-bit dec is preferable in any loop, and in Listing 9-12 we get the benefits of a 16-bit dec at no cost other than a bit of careful register usage.

By the way, you’ve likely noticed that Listing 9-12 fairly begs for a loop instruction at the bottom of the outer loop. That’s certainly the most efficient code in this case; I’ve broken the loop into a dec and a jnz only for illustrative purposes.

How inc and add (and dec and sub) Differ - and Why

inc and dec are not exactly the same as add 1 and sub 1. Unlike addition and subtraction, inc and dec don’t affect the Carry flag. This can often be a nuisance, but there is a good use for this quirk of inc and dec, and that’s in adding or subtracting multi-word memory values.

Multi-word memory values are values longer than 16 bits that are stored in memory. On the 8088 such values can only be added together by a series of 16-and/or 8-bit additions. The first addition — of the least-significant words — must be performed with add, or with adc with the Carry flag set to 0. Subsequent additions of successively more-significant words must be performed with adc, so that the carry-out can be passed from one addition to the next via the Carry flag. The same is true of sub, sbb, and borrow for subtraction of multi-word memory variables.

Some way is needed to address each of the words in a multi-word memory value in turn, so that each part of the value may be used as an operand. Consequently, multi-word memory values are often pointed to by registers (BP or BX and/or SI or DI), which can be advanced to point to successively more-significant portions of the values as addition or subtraction proceeds. If, however, there were no way to advance a memory-addressing register without modifying the Carry flag, then adc and sbb would only work properly if we preserved the Carry flag around the inc instructions, with pushf and popf or lahf and sahf.

inc and dec don’t affect the Carry flag, however, and that greatly simplifies the process of adding multi-word memory variables. The code in Listing 9-13, which adds together two 64bit memory variables — one pointed to by SI and the other pointed to by DI — only works because the inc instructions that advance the pointers don’t affect the Carry flag values that join the additions of the various parts of the variables. (It’s equally important that loop doesn’t affect any flags, as we’ll see in Chapter 14.)

Shifting and Rotating Memory

One feature of the 8088 that for some reason is often overlooked is the ability to shift or rotate a memory variable. True, the 8088 doesn’t shift or rotate memory variables very rapidly, but the capability is there should you need it. If you should find the need to perform a multi-bit shift or rotate on a memory variable, for goodness sakes use a CL shift! Every 1-bit memory shift/rotate takes a minimum of 20 cycles. By contrast, a shift-by-CL memory shift/rotate takes a minimum of 25 cycles, but only 4 additional cycles per bit shifted. It doesn’t take a genius to see that for, say, a 4-bit rotate, the 41 cycles taken by the CL shift would beat the stuffing out of the 80 cycles taken by the four 1-bit shifts.

Rotates

You should be well aware that there are two sorts of rotates. One category, made up of rol and ror, consists of rotates that simply rotate the bits in the operand, as shown in Figure 9.2.

These instructions are useful for adjusting masks, swapping nibbles, and the like. For example:

mov   cl,4
ror   al,cl

swaps the high and low nibbles of AL. Note that these instructions don’t rotate through the Carry flag. However, they do copy the bit wrapped around to the other end of the operand to the Carry flag as well.

The other rotate category, made up of rcl and rcr, consists of rotates that rotate the operand through the Carry flag, as shown in Figure 9.3. These instructions are useful for multi-word shifts and rotates.

For example:

shr   dx,1
rcr   cx,1
rcr   bx,1
rcr   ax,1

shifts the 64-bit value in DX:CX:BX:AX right one bit.

The rotate instructions affect fewer flags than you might think, befitting their role as bit-manipulation rather than arithmetic instructions. None of the rotate instructions affect the Sign, Zero, Auxiliary Carry, or Parity flags. On 1-bit left rotates the Overflow flag is set to the exclusive-or of the value of the resulting Carry flag and the most-significant bit of the result. On 1-bit right rotates the Overflow flag is set to the exclusive-or of the two most-significant bits of the result. (These Overflow flag settings indicate whether the rotate has changed the sign of the operand.) On rotates by CL the setting of the Overflow flag is undefined.

Shifts

Similarly, there are two sorts of shift instructions. One category, made up of shl (also known as sal) and shr, consists of shifts that shift out to the Carry flag, shifting a 0 into the vacated bit of the operand, as shown in Figure 9.4.

These instructions are used for moving masks and bits about and for performing fast unsigned division and multiplication by powers of 2. For example:

shl   ax,1

multiplies AX, viewed as an unsigned value, by 2.

The other shift category contains only sar. sar performs the same shift right as does shr, save that the most significant bit of the operand is preserved rather than zeroed after the shift, as shown in Figure 9.5.

This preserves the sign of the operand, and is useful for performing fast signed division by powers of 2. For example:

sar   ax,1

divides AX, viewed as a signed value, by 2.

The shift instructions affect the arithmetic-oriented flags that the rotate instructions leave alone, which makes sense since the shift instructions can perform certain types of multiplication and division. Unlike the rotate instructions, the shift instructions modify the Sign, Zero, and Parity flags in the expected ways. The setting of the Auxiliary Carry flag is undefined. The setting of the Overflow flag by the shift instructions is identical to the Overflow settings of the rotate instructions. On 1-bit left shifts the Overflow flag is set to the exclusive-or of the resulting Carry flag and the most-significant bit of the result. On 1-bit right shifts the Overflow flag is set to the exclusive-or of the two most-significant bits of the result.

Basically, any given shift will set the Overflow flag to 1 if the sign of the result differs from the sign of the original operand, thereby signalling that the shift has not produced a valid signed multiplication or division result. sar always sets the Overflow flag to 0, since sar can never change the sign of an operand. shr always sets the Overflow flag to the high-order bit of the original value, since the sign of the result is always positive. On shifts by CL the setting of the Overflow flag is undefined.

Signed Division With sar

One tip if you do use sar to divide signed values: for negative dividends, sar rounds to the integer result of the next largest absolute value. This can be confusing, since for positive values sar rounds to the integer result of the next smallest absolute value, just as shr does. That is:

mov   ax,1
sar   ax,1

returns 1/2=0, while:

mov   ax,-1
sar   ax,1

doesn’t return -1/2=0, but rather -1/2=-1. Similarly, sar insists that -5/4=-2, not -1. This is actually a tendency to round to the next integer value less than the actual result in all cases, which is exactly what shr also does. While that may be consistent, it’s nonetheless generally a nuisance, since we tend to expect that, say, -1/2*-1 should equal 1/2*1, but with sar we actually get 1 for the former and 0 for the latter.

The solution? For a signed division by n of a negative number with sar, simply add n-1 to the dividend before shifting. This compensates exactly for the rounding sar performs. For example:

    mov   ax,-1   ;sample dividend
    and   ax,ax   ;is the dividend negative?
    jns   DoDiv   ;it's positive, so we're ready to divide
    add   ax,2-1  ;it's negative, so we need to compensate.
                  ; This is division by 2, so we'll
                  ; add n-1 = 2-1
DoDiv:
    sar   ax,1    ;signed divide by 2

returns 0, just what we’d expect from -1/2.

That’s a quick look at what the shift and rotate instructions were designed to do. Now let’s bring a little Zen of assembler to bear in cooking up a use for sar that you can be fairly sure was never planned by the architects of the 8088.

Bit-Doubling Made Easy

Think back to the bit-doubling example of Chapter 7, where we found that a bit-doubling routine based on register-register instructions didn’t run nearly as fast as it should have, thanks to the prefetch queue. We boosted the performance of the routine by performing a table look-up, and that’s the best solution that I know of. There is, however, yet another bit-doubling technique (conceived by my friend Dan Illowsky) that’s faster than the original shift-based approach. Interestingly enough, this new technique uses sar.

Let’s consider sar as a bit-manipulation instruction rather than as a signed arithmetic instruction. What does sar really do? Well, it shifts all the bits of the operand 1 bit to the right, and it shifts bit 0 of the operand into the Carry flag. The most significant bit of the operand is left unchanged — and it is also shifted 1 bit to the right.

In other words, the most significant bit is doubled!

Once we’ve made the conceptual leap from sar as arithmetic instruction to sar as “bit-twiddler,” we’ve got an excellent tool for bit-doubling. The code in Listing 7-14 placed the byte containing the bits to be doubled in two registers (BL and BH) and then doubled the bits with 4 instructions:

shr   bl,1
rcr   ax,1
shr   bh,1
rcr   ax,1

By contrast, the sar approach, illustrated in Listing 9-23, requires only one source register and doubles the bits with just 3 instructions:

shr   bl,1
rcr   ax,1
sar   ax,1

The sar approach requires only 75% as many code bytes as the approach in Listing 7-14. Since instruction fetching dominates the execution time of Listing 7-14, the shorter sar-based code should be considerably faster, and indeed it is. Listing 9-23 doubles bits in 47.07 us per byte doubled, more than 34% faster than the 63.36 us of Listing 7-14. (Note that the ratio of the execution times is almost exactly 3-to-4…which is the ratio of the code sizes of the two approaches. Keep your code short!)

Mind you, the sar approach of Listing 9-23 is still much slower than the look-up approach of Listing 7-15. What’s more, the code in Listing 9-23 is both slower and larger than the xlat-based nibble look-up approach shown in Listing 7-18, so sar really isn’t a preferred technique for doubling bits. The point to our discussion of bit-doubling with sar is actually this: all sorts of interesting possibilities open up once you start to view instructions in terms of what they do, rather than what they were designed to do.

daa, das, and Packed BCD Arithmetic

daa (“decimal adjust AL after addition”) and das (“decimal adjust AL after subtraction”) adjust AL to the correct value after addition of two packed BCD (binary coded decimal) operands. Packed BCD is a number-storage format whereby a digit between 0 and 9 is stored in each nibble, so the hex value 1000h interpreted in BCD is 1000 decimal, not 4096 decimal. (Unpacked BCD is similar to packed BCD, save that only one digit rather than two is stored in each byte.)

Naturally, the addition of two BCD values with the add instruction doesn’t produce the right result. The contents of AL after add al,bl is performed with 09h (9 decimal in BCD) in AL and 01h (1 decimal in BCD) in BL is 0Ah, which isn’t even a BCD digit. What daa does is take the binary result of the addition of a packed BCD byte (two digits) in AL and adjust it to the correct sum. If, in the last example, daa had been performed after add al,bl, AL would have contained 10h, which is 10 in packed BCD — the correct answer.

das performs a similar adjustment after subtraction of packed BCD numbers. The mechanics of daa and das are a bit complex, and I won’t go into them here, since I know of no use for the instructions save to adjust packed BCD results. Yes, I do remember that I told you to look at instructions for what they can do, not what they were designed to do. As far as I know, though, the two are one and the same for daa and das. I’ll tell you what: look up the detailed operation of these instructions, find an unintended use for them, and let me know what it is. I’ll be delighted to hear! One possible hint: these instructions are among the very few that pay attention to the Auxiliary Carry flag.

I’m not going to spend any more time on daa and das, because they’re just not used that often. BCD arithmetic is used primarily for working with on values to an exact number of decimal digits. (By contrast, normal binary arithmetic stores values to an exact number of binary digits, which can cause rounding problems with decimal calculations.) Consequently, BCD arithmetic is useful for accounting purposes, but not much else. Moreover, BCD arithmetic is decidedly slow. If you’re one of the few who need BCD arithmetic, the BCD-oriented instructions are there, and BCD arithmetic is well-discussed in the literature — it’s been around for decades, and many IBM mainframes use it — so go to it. For the rest of you, don’t worry that you’re missing out on powerful and mysterious instructions — the BCD instructions are deservedly obscure.

aam, aad, and Unpacked BCD Arithmetic

aam and aad are BCD instructions of a slightly different flavor and a bit more utility. aam (“ASCII adjust AX after multiply”) adjusts the result in AL of the multiplication of two single-digit unpacked BCD values to a valid two-digit unpacked BCD value in AX. This is accomplished by dividing AL by 10 and storing the quotient in AH and the remainder in AL. (By contrast, div stores the quotient in AL and the remainder in AH.)

aad (“ASCII adjust AL before division”) converts a two-digit unpacked BCD value in AX into the binary equivalent in AX. This is performed by multiplying AH by 10, adding it to AL, and zeroing AH. The binary result of aad can then be divided by a single-digit BCD value to generate a single-digit BCD result.

By the way, “ASCII adjust” really means unpacked BCD for these instructions, since ASCII digits with the upper nibble zeroed are unpacked BCD digits. aaa and aas, which we’ll discuss shortly, explicitly convert ASCII digits into unpacked BCD, but aam and aad require that you use and to zero the upper nibble of ASCII digits before performing multiplication and division.

aam can be used to implement multiplication of arbitrarily long unpacked BCD operands one digit at a time. That is, with aam you can multiply decimal numbers just the way we do it with a pencil and paper, multiplying one digit of each product together at a time and carrying the results along. Presumably, aad can be used similarly in the division of two BCD operands, although I’ve never found an example of the use of aad.

At any rate, the two instructions do have some small use apart from unpacked BCD arithmetic. They can save a bit of code space if you need to perform exactly the specified division by 10 of aam or multiplication by 10 and addition of aad, although you must be sure that the result can fit in a single byte. In particular, aam has an advantage over div in that a div by an 8-bit divisor requires a 16-bit dividend in AX, while aam uses only an 8-bit dividend in AL. aam has another advantage in that unlike div, it doesn’t require a register to store the divisor.

For example, Listing 9-24 shows code that converts a byte value to a three-digit ASCII string by way of aam. Listing 9-25, by contrast, converts a byte value to an ASCII string by using explicit division by 10 via div. Listing 9-24 is only 28 bytes long per byte converted, 2 bytes shorter than Listing 9-25. Listing 9-24 also executes in 54.97 us per conversion, 2.65 us faster than the 57.62 us of Listing 9-25. Normally, an improvement of 2.65 us would have us jumping up and down, but the lengthy execution times of both conversion routines mean that the speed advantage of Listing 9-24 is only about 5%. That’s certainly an improvement — but painfully slow nonetheless.

aam and aad would be more interesting if they provided significantly faster ways than div and mul to divide and multiply by 10. Unfortunately, that’s not the case, as the above results illustrate. aad and aam must use the 8088’s general-purpose multiplication and division capabilities, for they are just about as slow as mul and div. aad is the speedster of the two at 60 cycles per execution, while aam executes in 83 cycles.

Notes on mul and div

I’d like to take a moment to note some occasionally annoying characteristics of mul and div. mul (and imul, but I’ll refer only to mul from now on for brevity) has a tendency to surprise you by wiping out a register that you’d intuitively think it wouldn’t, because the product is stored in twice as many bits as either factor. For example, mul bl stores the result in AX, not AL, and mul cx stores the result in DX:AX, not AX. While this sounds simple enough, it’s easy to forget in the heat of coding.

Similarly, it’s easy to forget that div requires that the dividend be twice as large as the divisor and quotient. (The following discussion applies to idiv as well; again, I’ll refer only to div for brevity.) In order to divide one 16-bit value by another, it’s essential that the 16-bit dividend be extended to a 32-bit value, as in:

mov   bx,[Divisor]
mov   ax,[Dividend]
sub   dx,dx         ;extend Dividend to an unsigned 32-bit value
div   bx

(cwd can be used for sign-extension to a 32-bit value.) What’s particularly tricky about 32-bit-by-16-bit division is that it leaves the remainder in DX. That means that if you perform multiple 16-bit-by-16-bit divisions in a loop, you must zero DX every time through the loop. For example, the following code to convert a binary number to five ASCII digits wouldn’t work properly, because the dividend wouldn’t be properly extended to 32 bits after the first division, which would leave the remainder in DL:

    mov   ax,[Count]            ;value to convert to ASCII
    sub   dx,dx                 ;extend Count to an unsigned 32-bit value
    mov   bx,10                 ;divide by 10 to convert to decimal
    mov   si,offset CountEnd-1  ;ASCII count goes here
    mov   cx,5                  ;we want 5 ASCII digits
DivLoop:
    div   bx                    ;divide by 10
    add   dl,'0'                ;convert this digit to ASCII
    mov   [si],dl               ;store the ASCII digit
    dec   si                    ;point to the next most significant digit
    loop  DivLoop

On the other hand, the following code would work perfectly well, because it extends the dividend to 32 bits every time through the loop:

    mov   ax,[Count]            ;value to convert to ASCII
    mov   bx,10                 ;extend Count to an unsigned 32-bit value
    mov   si,offset CountEnd-1  ;ASCII count goes here
    mov   cx,5                  ;we want 5 ASCII digits
DivLoop:
    sub   dx,dx                 ;extend the dividend to an unsigned 32-bit value
    div   bx                    ;divide by 10
    add   dl,'0'                ;convert this digit to ASCII
    mov   [si],dl               ;store the ASCII digit
    dec   si                    ;point to the next most significant digit
    loop  DivLoop

All of the above goes for 8-bit-by-8-bit division as well, except that in that case it’s the 8-bit dividend in AL that you must extend to a word in AX before each division.

There’s another tricky point to div: div can crash a program by generating a divide-by-zero interrupt (interrupt 0) under certain circumstances. Obviously, this can happen if you divide by zero, but that’s not the only way div can generate a divide-by-zero interrupt. If a division is attempted for which the quotient doesn’t fit into the destination register (AX for 32-bit-by-16-bit divides, AL for 16-bit-by-8-bit divides), a divide-by-zero interrupt occurs. So, for example:

mov   ax,0ffffh
mov   dl,1
div   dl

results in a divide-by-zero interrupt.

Often, you know exactly what the dividend and divisor will be for a particular division, or at least what range they’ll be in, and in those cases you don’t have to worry about div causing a divide-by-zero interrupt. If you’re not sure that the dividend and divisor are safe, however, you must guard against potential problems. One way to do this is by intercepting interrupt 0 and handling divide-by-zero interrupts. The alternative is to check the dividend and divisor before each division to make sure both that the divisor is non-zero and that the dividend isn’t so much larger than the divisor that the result won’t fit in 8 or 16 bits, whichever size the division happens to be.

This division-by-zero business is undeniably a nuisance to have to deal with — but it’s absolutely necessary if you’re going to perform division without knowing that the inputs can safely be used.

aaa, aas, and Decimal ASCII Arithmetic

Finally, we come to aaa and aas, which support addition and subtraction of decimal ASCII digits. Actually, aaa and aas support addition and subtraction of any two unpacked BCD digits, or indeed of any two bytes at all the lower nibbles of which contain digits in the range 0-9.

aaa (“ASCII adjust after addition”) adjusts AL to the correct decimal (unpacked BCD) result of the addition of two nibbles. Consider this: if you add two digits in the range 0-9, one of three things can happen. The result can be in the range 0-9, in which case no adjustment is needed and no decimal carry has occurred. Alternatively, the result can be in the range 0Ah-0Fh, in which case the result can be corrected by adding 6 to the result, taking the result modulo 16 (decimal), and setting carry-out. Finally, the result can be in the range 10h-12h, in which case the result can be corrected in exactly the same way as for results in the range 0Ah-0Fh.

aaa handles all three cases with a single 1-byte instruction. aaa assumes that an add or adc instruction has just executed, with the Auxiliary Carry flag set appropriately. If the Auxiliary Carry flag is set (indicating a result in the range 10h-12h) or if the lower nibble of AL is in the range 0Ah-0Fh, then 6 is added to AL, the Auxiliary Carry and Carry flags are set to 1, and AH is incremented. Finally, the upper nibble of AL is set to 0 in all cases.

What does all this mean? Obviously, it means that it’s easy to add together unpacked BCD numbers. More important, though, is that aaa makes it fast (4 cycles per aaa) and easy to add together ASCII representations of decimal numbers. That’s genuinely useful because it takes a slew of cycles to convert a binary number to an ASCII representation; after all, a division by 10 is required for each digit to be converted. ASCII numbers are necessary for all sorts of data displays for which speed is important, ranging from game scores to instrumentation readouts. aaa makes possible the attractive alternative of keeping the numbers in displayable ASCII forms at all times, thereby avoiding the need for any sort of conversion at all.

Listing 9-26 shows the use of aaa in adding the value 1 - stored as the ASCII decimal string “00001” — to an ASCII decimal count. Granted, it takes much longer to perform the ASCII decimal increment shown in Listing 9-26 than it does to execute an inc instruction — more than 100 times as long, in fact, at 93.00 us per ASCII decimal increment versus a maximum of 0.809 us per inc. However, Listing 9-26 maintains the count in instantly-displayable ASCII form, and for frequently-displayed but rarely-changed numbers, a ready-to-display format can more than compensate for lengthier calculations.

If you do use aaa, remember that you have not one but two ways to use the carry-out that indicates that a decimal digit has counted from 9 back around to 0. The Carry flag is set on carry-out; that’s what we use as the carry-out status in Listing 9-26. In addition, though, AH is incremented by aaa whenever decimal carry-out occurs. It’s certainly possible to get some extra mileage by putting the next-most-significant digit in AH before performing aaa so that the carry-out is automatically carried. It’s also conceivable that you could use aaa specifically to increment AH depending on either the value in AL or on the setting of the Auxiliary Carry flag, although I’ve never seen such an application. Since the Auxiliary Carry flag isn’t testable by any conditional jump (or indeed by any instructions other than daa, das, aaa, and aas), aaa is perhaps the best hope for getting extra utility from that obscure flag.

aas (“ASCII adjust after subtraction”) is well and truly the mirror image of aaa. aas is designed to be used after a sub or sbb, subtracting 6 from the result, decrementing AH, and setting the Carry flag if the result in AL is not in the range 0-9, and zeroing the high nibble of AL in any case. You’ll find that wherever aaa is useful, so too will be aas.

On to the String Instructions

We’ve cut a wide swath through the 8088’s instruction set in this chapter, but we have yet to touch on one important set of instructions — the string instructions. These instructions, which are perhaps the most important instructions the 8088 has to offer when it comes to high-performance programming, are coming up next. Stay tuned.

Reading Memory: lods

lodsb (“load string byte”) reads the byte addressed by DS:SI (the source operand) into AL and then either increments or decrements SI, depending on the setting of the direction flag, as shown in Figure 10.1.

lodsw (“load string word”) reads the word addressed by DS:SI into AX and then adds or subtracts 2 to or from SI, again depending on the state of the direction flag. In either case, the use of DS as the segment can be overridden, as we’ll see later.

We’ll discuss the direction flag in detail later on. For now, let’s just refer to string instructions as “advancing” their pointers, with the understanding that advancing means either adding or subtracting 1 or 2, depending on the direction flag and the data size.

lods is particularly useful for reading the elements of an array or string sequentially, since SI is automatically advanced each time lods is executed.

lods is considerably more limited than, say, mov reg8,[mem8]. For instance, lodsb requires that AL be the destination and that SI point to the source operand, while the mov instruction allows any of the 8 general-purpose registers to be the destination and allows the use of any of the 16 addressing modes to address the source.

On the other hand, lodsb is shorter and a good deal faster than mov. mov reg8,[mem8] is between 2 and 4 bytes in length, while lodsb is exactly 1 byte long. lodsb also advances SI, an action which requires a second instruction (albeit a fast one), inc si, when mov is used.

Let’s compare lodsb and mov in action. Listing 10-1, which loads AL and advances SI 1000 times with mov and inc, executes in 3.77 ms. Listing 10-2, which uses lodsb to both load and advance in a single instruction, is 33% faster at 2.83 ms. When two code sequences perform the same task and one of them is 33% faster and one-third the length, there can’t be much doubt about which is better.

lodsb is even superior to mov when the time required to advance SI is ignored. Suppose, for example, that you were to load SI with a pointer into a look-up table. Would you be better off using lods or mov to perform the look-up, given that it doesn’t matter in this case whether SI advances or not?

Use lods. Listing 10-3, which is Listing 10-1 modified to remove the inc instructions, executes in 3.11 ms. Listing 10-2, which uses lodsb, is one-half the length of Listing 10-3 and 10% faster, even though Listing 10-3 uses the shortest and fastest memory-accessing form of the mov instruction and doesn’t advance SI.

Of course, if you specifically didn’t want SI to advance, you’d be better off with mov, since there’s no way to stop lods from advancing SI. (In fact, all the string instructions always advance their pointer registers, whether you want them to or not.)

I’m not going to contrast the other string instructions with their non-string equivalents in the next few sections; we’ll get plenty of that later in the chapter. The rule we just established applies to the other string instructions as well, though: it’s often better to use a string instruction than mov even when you don’t need all the power of the string instruction. While it can be a nuisance to set up the registers for the string instructions, it’s still usually worth using the string instructions whenever you can do so without going through too many contortions. In general, the string instructions simply make for shorter, faster code than their mov-based equivalents.

Never assume, though: string instructions aren’t superior in all cases. Always time your code!

Writing Memory: stos

stosb (“store string byte”) writes the value in AL to the byte addressed by ES:DI (the destination operand) and then either increments or decrements DI, depending on the setting of the direction flag. stosw (“store string word”) writes the value in AX to the word addressed by ES:DI and then adds or subtracts 2 to or from DI, again depending on the direction flag, as shown in Figure 10.2. The use of ES as the destination segment cannot be overridden.

stos is the preferred way to initialize arrays, strings, and other blocks of memory, especially when used with the rep prefix, which we’ll discuss shortly. stos also works well with lods for tasks that require performing some sort of translation while copying arrays or strings, such as conversion of a text string to uppercase. In this use, lods loads an array element into AL, the element is translated in AL, and stos stores the element to the new array. Put a loop around all that and you’ve got a compact, fast translation routine. We’ll discuss this further in the next chapter.

Moving Memory: movs

movsb (“move string byte”) copies the value stored at the byte addressed by DS:SI (the source operand) to the byte addressed by ES:DI (the destination operand) and then either increments or decrements SI and DI, depending on the setting of the direction flag, as shown in Figure 10.3.

movsw (“move string word”) copies the value stored at the word addressed by DS:SI to the word addressed by ES:DI and then adds or subtracts 2 to or from SI or DI, again depending on the direction flag. The use of DS as the source segment can be overridden, but the use of ES as the destination segment cannot.

Note that the accumulator is not affected by movs; the data is copied directly from memory to memory, not by way of AL or AX.

movs is by far the 8088’s best instruction for copying arrays, strings, and other blocks of data from one memory location to another.

Scanning Memory: scas

scasb (“scan string byte”) compares AL to the byte addressed by ES:DI (the source operand) and then either increments or decrements DI, depending on the setting of the direction flag, as shown in Figure 10.4.

scasw (“scan string word”) compares the value in AX to the word addressed by ES:DI and then adds or subtracts 2 to or from DI, again depending on the direction flag. The use of ES as the source segment cannot be overridden.

scas performs its comparison exactly as cmp does, by performing a trial subtraction of the memory location addressed by ES:DI from the accumulator without actually changing either the accumulator or the memory location. All the arithmetic flags — Overflow, Sign, Zero, Auxiliary Carry, Parity, and Carry — are affected by scas. That’s easy to forget when you use repz scas or repnz scas, which can only terminate according to the status of the Zero flag. (We’ll cover all the repeated string instruction below.)

scas is the preferred instruction for searching strings and arrays for specific values, and is especially good for looking up values in tables. Many programmers get so used to using repz scas and repnz scas that they forget that non-repeated scas instructions are more flexible than their repeated counterparts and can often be used when the repeated versions of scas can’t. For example, suppose that we wanted to search a word-sized array for the first element greater than 10,000. Listing 10-4 shows code for doing this with non-string instructions. The code in Listing 10-4 runs in 10.07 ms.

Note that in Listing 10-4 the value 10,000 is placed in a register outside the loop in order to make the cmp instruction inside the loop faster and 2 bytes shorter. Also note that the code is arranged so that DI can be incremented before each comparison inside the loop, allowing us to get by with just one jump instruction. The alternative would be:

SearchLoop:
    cmp   ax,[di]
    jb    SearchDone
    inc   di
    inc   di
    jmp   SearchLoop
SearchDone:

While this works perfectly well, it has not only the 4 instructions of the loop in Listing 10-4 but also an additional jump instruction, and so it’s bound to be slower.

Listing 10-5 is functionally equivalent to Listing 10-4, but uses scasw rather than cmp and inc. That slight difference allows Listing 10-5 to run in 8.25 ms, 22% faster than Listing 10-4. While scasw works beautifully in this application, rep scasw would not have worked at all, since rep scasw can only handle equality/non-equality comparisons, not greater-than or less-than. If we had been thinking in terms of rep scasw, we might well have missed the superior scasw implementation. The moral: although repeated string instructions are the most powerful instructions of the 8088, don’t forget that non-repeated string instructions are nearly as powerful and generally more flexible.

As another example, Listing 10-6 shows a lodsw-based version of Listing 10-4. While this straightforward approach is faster than Listing 10-4 (it executes in 9.07 ms), it is clearly inferior to the scasw-based implementation of Listing 10-5. When you set out to tackle a programming problem, always think of the string instructions first… and think of all the string instructions. The obvious solution is not necessarily the best.

Notes on Loading Segments for String Instructions

You may have noticed that in Listing 10-5 I chose to use DI to load ES with the target segment. This is a useful practice to follow when setting up pointers in ES:DI for string instructions; since you know you’re going to load DI with the target offset next, you can be sure that you won’t accidentally wipe out any important data in that register. It’s more common to use AX to load segment registers, since AX is the most general-purpose of registers, but why use AX — which might contain something useful — when DI is guaranteed to be free?

Similarly, I make a practice of using SI to load DS for string instructions, loading the offset into SI immediately after setting DS.

Along the same lines, I load the segment into DI in Listing 10-5 with the seg operator. You may prefer to load the name of the segment instead (for example, mov di,DataSeg). That’s okay too, but consider this: you can’t go wrong with the seg operator when you’re loading a segment in order to access a specific named variable. Even if you change the name of the segment containing the array in Listing 10-5, the code will still assemble properly. The same cannot be said for loading DI with the name of the segment. The choice is yours, but personally I prefer to make my code as immune as possible to errors induced by later changes.

It may have occurred to you that in Listing 10-5 it would be faster to load DI with the target segment from DS rather than with a constant. That is:

mov   di,ds
mov   es,di

is shorter and faster than:

mov   di,seg WordArray
mov   es,di

True enough, and you should use the first approach whenever you can. I’ve chosen to use the latter approach in the listings in this chapter in order to make the operation of the string instructions clear, and to illustrate the most general case. After all, in many cases the destination segment for a string instruction won’t be DS.

Comparing Memory: cmps

cmpsb (“compare string byte”) compares the byte addressed by DS:SI (the destination operand) to the byte addressed by ES:DI (the source operand) and then either increments or decrements SI and DI, depending on the setting of the direction flag. cmpsw (“compare string word”) compares the value stored at the word addressed by DS:SI to the word addressed by ES:DI and then adds or subtracts 2 to or from SI and DI, again depending on the direction flag, as shown in Figure 10.5.

The use of DS as the destination segment can be overridden, but the use of ES as the source segment cannot.

cmps performs its comparison as cmp does, by performing a trial subtraction of the memory location addressed by ES:DI from the memory location addressed by DS:SI without actually changing either location. As with scas, all six arithmetic flags are affected by cmps. The key difference between scas and cmps is that scas compares the accumulator to memory, while cmps compares two memory locations directly. The accumulator is not affected by cmps in any way; data is compared directly from one memory operand to the other, not by way of AL or AX. cmps is in a class by itself for comparing arrays, strings, and other blocks of memory data.

Data Size, Advancing Pointers, and the Direction Flag

Each string instruction advances its associated pointer register (or registers) by one memory location each time it executes. lods advances SI, stos and scas advance DI, and movs and cmps advance both SI and DI. As we’ve seen, that’s a very handy bonus of using the string instructions — not only do they access memory rapidly, they also advance pointers in that same short time. String instructions advance their pointer registers just once per execution. However, any string instruction prefixed with rep can execute — and consequently advance its pointer or pointers — thousands of times.

All that seems straightforward enough. There are complications, though: both the definition of “one memory location” and the direction in which the pointer or pointers advance can vary.

String instructions can operate on either byte-or word-sized data. We’ve already seen one way to choose data size: by putting the suffix “b” or “w” on the end of a string instruction’s mnemonic. For example, lodsb loads a byte, and cmpsw compares two words. Later in the chapter we’ll see another way to specify data size, along with ways to specify segment overrides for string instructions that access memory via SI.

When working with byte-sized data, string instructions advance their pointers by 1 byte per memory access, and when working with word-sized data, they advance their pointers by one word per memory access. So “one memory location” means whichever of 1 byte or 1 word is the data size of the instruction. That makes perfect sense given that the idea of using string instructions is to advance sequentially through the elements of a byte-or word-sized array.

Ah, but what exactly does “advance” mean? Do the pointer registers used by string instructions move to the next location higher in memory or to the next location lower in memory?

Both, actually. Or, rather, either one, depending on the setting of the Direction flag in the FLAGS register. If the Direction flag is set, string instructions move their pointers down in memory, subtracting either 1 or 2 — whichever is the data size — from the pointer registers. If the Direction flag is reset, string instructions move their pointers up in memory by adding either 1 or 2.

The Direction flag can be explicitly set with the std (“set Direction flag”) instruction and reset with the cld (“clear Direction flag”) instruction. Other instructions that load the FLAGS register, such as popf and iret, can alter the Direction flag as well. Be aware, however, that sahf does not affect the Direction flag, since it loads only the lower byte of the FLAGS register from AH. A glance at Figure 6-2 shows that the Direction flag resides in the upper byte of the FLAGS register.

The Direction flag doesn’t seem like a big deal, but in fact it can be responsible for some particularly nasty bugs. The problem with the Direction flag is that it allows a given string instruction to produce two completely different results under what look to be the same circumstances — the same register settings, memory contents, and so on. In other words, the Direction flag makes string instructions modal, and the instruction that controls that mode at any given time — the cld or std that selected the string direction — may have occurred long ago, in a subroutine far, far away. A string instruction that runs perfectly most of the time can mysteriously crash the system every so often because a different Direction flag state was selected by seemingly unrelated code that ran thousands of cycles earlier.

What’s the solution? Well, usually you’ll want your string instructions to move their pointers up in memory, since that’s the way arrays and strings are stored. (It’s also the way people tend to think about memory, with storage running from low to high addresses.) There are good uses for counting down, such as copying overlapping source and destination blocks and searching for the last element in an array, but those are not the primary applications for string instructions. Given that, it makes sense to leave the Direction flag cleared at all times except when you explicitly need to move pointers down rather than up in memory. That way you can always count on your string instructions to move their pointers up unless you specify otherwise.

Unfortunately, that solution can only be used when you’ve written all the code in a program yourself, and done so in pure assembler. Since you have no control over the code generated by compilers or the code in third-party libraries, you can’t rely on such code to leave the Direction flag cleared. I know of one language in which library functions do indeed leave the Direction flag set occasionally, and I’ve no doubt that there are others. What to do here?

The solution is obvious, though a bit painful: whenever you can’t be sure of the state of the Direction flag, you absolutely must put it in a known state before using any of the string instructions. This causes your code to be sprinkled with cld and std instructions, and that makes your programs a bit bigger and slower. Fortunately, though, cld and std are 1-byte, 2-cycle instructions, so they have a minimal impact on size and performance. As with so much else about the 8088, it would have been nice if Intel had chosen to build direction into the opcode bytes of the string instruction, as they did with data size. Alas, Intel chose not to do so -so be sure the Direction flag is in the proper state each and every time you use a string instruction.

That doesn’t mean you have to put a cld or std before every string instruction. Just be sure you know the state of the Direction flag when each string instruction is executed. For example, in Listing 10 - 5 cld is performed just once, outside the loop. Since nothing inside the loop changes the Direction flag, there’s no need to set the flag again.

An important tip: always put the Direction flag in a known state in interrupt — handling code. Interrupts can occur at any time, while any code is executing -including BIOS and DOS code, over which you have no control. Consequently, the Direction flag may be in any state when an interrupt handler is invoked, even if your program always keeps the Direction flag cleared.

The rep Prefix

Taken by themselves, the string instructions are superior instructions: they’re shorter and faster than the average memory-accessing instruction, and advance pointer registers too. It’s in conjunction with the rep prefix that string instructions really shine, though.

As you may recall from Chapter 7, a prefix is an instruction byte that modifies the operation of the following instruction. For example, segment override prefixes can cause many instructions to access memory in segments other than their default segments.

rep is a prefix that modifies the operation of the string instructions (and only the string instructions). rep is exactly 1 byte long, so it effectively doubles the 1-byte length of the string instruction it prefixes. Put another way, movsb is a 1-byte instruction, while rep movsb is effectively a 2-byte instruction, although it actually consists of a 1-byte prefix and a 1-byte instruction. What rep does to justify the expenditure of an extra byte is simple enough: it instructs the following string instruction to execute the number of times specified by CX.