Change bold code snippets to inline code blocks
This commit is contained in:
parent
f658bfbb40
commit
3c76d884ef
185 changed files with 1772 additions and 1772 deletions
26
11-07.md
26
11-07.md
|
|
@ -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`.
|
||||
Loading…
Reference in a new issue