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

@ -36,10 +36,10 @@ I should have known better than to try to sneak this one by you. The
most common feedback I've gotten on X-Sharp is that I should make it
support the 8088 and 286. Well, I can take a hint as well as the next
guy. Listing 54.1 is an improved version of FIXED.ASM, containing dual
386/8088 versions of **CosSin(), XformVec()**, and **ConcatXforms()**,
as well as **FixedMul()** and **FixedDiv()**.
386/8088 versions of `CosSin(), XformVec()`, and `ConcatXforms()`,
as well as `FixedMul()` and `FixedDiv()`.
Given the new version of FIXED.ASM, with **USE386** set to 0, X-Sharp
Given the new version of FIXED.ASM, with `USE386` set to 0, X-Sharp
will now run on any processor. That's not to say that it will run fast
on any processor, or at least not as fast as it used to. The switch to
8088 instructions makes X-Sharp's fixed-point calculations about 2.5
@ -56,7 +56,7 @@ simple matter of adding together four partial products. A 32-bit divide
is not so simple, however. In fact, in Listing 54.1 I've chosen not to
implement a full 32x32 divide, but rather only a 32x16 divide. The
reason is simple: performance. A 32x16 divide can be implemented on an
8088 with two **DIV** instructions, but a 32x32 divide takes a great
8088 with two `DIV` instructions, but a 32x32 divide takes a great
deal more work, so far as I can see. (If anyone has a fast 32x32 divide,
or has a faster way to handle signed multiplies and divides than the
approach taken by Listing 54.1, please drop me a line care of the
@ -70,7 +70,7 @@ degradation; therefore, given the already slow performance of the 8088
and 286, I've opted for performance over precision.
At any rate, please keep in mind that the non-386 version of
**FixedDiv()** is *not* a general-purpose 32x32 fixed-point division
`FixedDiv()` is *not* a general-purpose 32x32 fixed-point division
routine. In fact, it will generate a divide-by-zero error if passed a
fixed-point divisor between -1 and 1. As I've explained, the non-386
version of **Fixed-Div()** is designed to do just what X-Sharp needs,