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
10
54-01.md
10
54-01.md
|
|
@ -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,
|
||||
|
|
|
|||
Loading…
Reference in a new issue