Change bold code snippets to inline code blocks

This commit is contained in:
James Gregory 2013-12-31 17:12:29 +11:00
commit 3c76d884ef
185 changed files with 1772 additions and 1772 deletions

View file

@ -71,9 +71,9 @@ The more things change, the more they remain the same....
#### POPF and the 286 {#Heading17}
We've one final 286-related item to discuss: the hardware malfunction of
**POPF** under certain circumstances on the 286.
`POPF` under certain circumstances on the 286.
The problem is this: Sometimes **POPF** permits interrupts to occur when
The problem is this: Sometimes `POPF` permits interrupts to occur when
interrupts are initially off and the setting popped into the Interrupt
flag from the stack keeps interrupts off. In other words, an interrupt
can happen even though the Interrupt flag is never set to 1. Now, I
@ -85,29 +85,29 @@ absolutely disabled, with no chance of an interrupt sneaking through.
For example, a critical portion of a disk BIOS might need to retrieve
data from the disk controller the instant it becomes available; even a
few hundred microseconds of delay could result in a sector's worth of
data misread. In this case, one misplaced interrupt during a **POPF**
data misread. In this case, one misplaced interrupt during a `POPF`
could result in a trashed hard disk if that interrupt occurs while the
disk BIOS is reading a sector of the File Allocation Table.
There is a workaround for the **POPF** bug. While the workaround is easy
to use, it's considerably slower than **POPF**, and costs a few bytes as
There is a workaround for the `POPF` bug. While the workaround is easy
to use, it's considerably slower than `POPF`, and costs a few bytes as
well, so you won't want to use it in code that can tolerate interrupts.
On the other hand, in code that truly cannot be interrupted, you should
view those extra cycles and bytes as cheap insurance against mysterious
and erratic program crashes.
One obvious reason to discuss the **POPF** workaround is that it's
One obvious reason to discuss the `POPF` workaround is that it's
useful. Another reason is that the workaround is an excellent example of
Zen-level assembly coding, in that there's a well-defined goal to be
achieved but no obvious way to do so. The goal is to reproduce the
functionality of the **POPF** instruction without using **POPF**, and
the place to start is by asking exactly what **POPF** does.
functionality of the `POPF` instruction without using `POPF`, and
the place to start is by asking exactly what `POPF` does.
All **POPF** does is pop the word on top of the stack into the FLAGS
register, as shown in Figure 11.4. How can we do that without **POPF**?
Of course, the 286's designers intended us to use **POPF** for this
All `POPF` does is pop the word on top of the stack into the FLAGS
register, as shown in Figure 11.4. How can we do that without `POPF`?
Of course, the 286's designers intended us to use `POPF` for this
purpose, and didn't intentionally provide any alternative approach, so
we'll have to devise an alternative approach of our own. To do that,
we'll have to search for instructions that contain some of the same
functionality as **POPF**, in the hope that one of those instructions
can be used in some way to replace **POPF**.
functionality as `POPF`, in the hope that one of those instructions
can be used in some way to replace `POPF`.