SANE Normalized
Volume Number: | | 6
|
Issue Number: | | 1
|
Column Tag: | | XCMD Corner
|
SANE Normalized
By Donald Koscheka, Ernst & Young, MacTutor Contributing Editor
Note: Source code files accompanying article are located on MacTech CD-ROM or source code disks.
Ten years makes a big difference. When I started engineering school in 1973, I wanted to learn everything I could about the nascent microcomputer technology. For several years after graduation, however, I had trouble securing meaningful employment as a microcomputer engineer. With the exception of Silicon Valley and an instrumental little hotspot in Texas, there wasnt much calling for people who knew about microcomputers. Employers were intrigued by my background, but they regarded the microcomputer as not much more than an interesting toy. They argued that micros didnt have enough memory to do real work, they couldnt do real number crunching, and so on.
I found myself apologizing for these shortcomings. Realizing that I would probably have to beef up my computer experience, I enrolled in graduate school in 1980 at the University of Illinois. At the time, the school used yet another derivative of the IBM 370. You can imagine my reaction when I discovered that this behemoth was running an operating system called CMS (Conversational Mode System or some such). The entire goal of this operating system was to transform this monolithic hunk of iron in hundreds of virtual personal computers. The same people that were pooh-poohing my microcomputer training were spending vast amounts of effort trying to make their mainframes look like personal computers!
Ten years later, I think its safe to say that the personal computer cum micro has come of age. Aside from the obvious advances in user interface design, tremendous progress has been made in the personal computer technology.
Nowhere is this more evident than in the floating point support that ships at no extra cost with each and every Macintosh: the Standard Apple Numerics Environment (SANE). Numerics on the Macintosh are as good as or better than numerics on many mainframes. The implications of this quiet little revolution are profound, you can trust your Macintosh to do real number crunching accurately and reliably!
SANE guarantees well-behaved results and you dont have to be an expert in floating point arithmetic to use the Macintosh numerics package. If you do need to get into the details, SANE is beautifully documented in the Apple Numerics Manual, Second Addition by Addison Wesley. This is one of the best technical publications I have ever read; it is a paragon of simplicity and clarity.
I recently implemented a business graphics package as a set of XCMDs that accepts numbers from Hypercard and plots them into a windoid. I wanted to scale the picture so that it exactly fits within the dimensions of the windoid. I also didnt want to limit the input data to the domain of integers; a floating point implementation was indicated.
When using SANE, the old adage that knowledge is power is a statement of fact (if ones definition of power is the number of floating point operations per second). To exploit SANE, you should understand how floating point numbers work in the binary world.
HyperTalks callback mechnanism supports conversions between strings and extendeds (80 bit floating point numbers). While this is a good starting place, it only begins to untap the magic of SANE.
Floating point numbers come in a variety of flavors. You must consider factors such as range, precision, speed and space before settling on a format for your program. Simple applications might make do with the 32-bit single precision type, float. Most applications will be adequately served with the 64-bit double precision floating point type (double in C or Pascal). Understanding the internals of SANE can help you make a more informed decision.
For example, knowing that all SANE internal operations are performed on the extended type allows you to make an important design decision: if speed is important, you might want to consider doing all of your arithmetic with 80-bit extended numbers so that you can spare your code the overhead of automatic type conversions. If you know a priori that your product will have co-processor support, then the 96-bit extended type may better suit your needs.
For bean counters, theres even a computational type that allows you to manipulate very large signed integers (64 bits).
The extended data type is the essential SANE type but it is implementation dependent. You should store your numbers in some other language specific format. If you intend to massage the data heavily, you might consider declaring your variables as extendeds so that no intermediate conversions will be made yielding speed for the potential loss of portability. This assumes that you have some worthwhile machine that you want to port to in the first place.
As I studied these floating point formats, I discovered some interesting properties of floating point representations in the binary world. I debug in TMON, so I need to be able to disassemble floating point numbers with the same ease that I disassemble integers. I needed to learn how to read floating point numbers from hex dumps. This is an illuminating exercise so I hope you wont mind if I share it with you.
A decimal number can be broken down into the product of three numbers (if you ever learned how to use a slide rule, youll appreciate the value of this representation):
-100110 = -1 * 1.001 * 103
Lets call 1.001 the significand and 3 the exponent (the power of 10 that the significand is raised to). Any decimal number can be represented as the product of a sign, a significand and an exponent. It turns out that this is not just a property of decimal numbers. Binary numbers can be represented in the same fashion:
1.001 * 23
is equal to 9 base ten. Demonstrating this provides us with some insights into floating point numbers.
SANE stores numbers in either normalized or denormalized forms. Normalization maximizes precision for a given number of bits (can you prove this to yourself?) Unfortunately, very small numbers cannot be represented in this normalized format; how small the number has to be depends on the number of bits used to represent the number. Unless your idea of a fun afternoon is exploring the Mandelbrot set, you probably wont need to concern yourself with the difference between normalized and denormalized numbers; suffice it to say that denormalized numbers are very small and characteristically hover around the origin.
SANE uses the format in figure 1 to store 80-bit normalized extended numbers.
Figure 1. Format of extended numbers in SANE.
The most significant bit is the sign bit, just as in signed integers. The next fifteen bits represent the exponent using the formula:
2(e-16383)
This representation allows for numbers whose orders of magnitude range from 2-16385 to 2+16385. The next field in the number (the i-bit) is set if this is a normalized number, cleared otherwise. The f field represents the fractional portion of the significand. If the i-bit is set, then the significand is assembled as 1.f otherwise, the significand is assembled as 0.f. The exponent determines the range of the numbers while the significand determines the resolution of the numbers.
The complete representation for the extended type becomes the product of its components (for normalized numbers):
(-1)s * 2(e-16383) * 1.f
To test this format, I wrote the following C program:
/* 1 */
main(){
extended x;
x = 9;
}
to determine the extended representation of 9 decimal. On debugging this number, I noticed that the integer 9 is first converted to a SANE extended which pops out as:
$4002 9000 0000 0000 0000
To see if this is truly the extended representation of the number, lets dissect it. The most significant bit is turned off so we know this is a positive number. The next 15 bits represent the exponent, in this case $4002 (hex) which is equal to 16386 decimal. Putting the sign and exponent together reveals the order of magnitude of the number:
(-1)0 * 2(16386-16383) = 1 * 23 = 8
The rest of the number is the significand. The i-bit is set so this is a normalized number:
1.0012
The significand is a binary fraction (the word decimal doesnt quite seem to fit here).
When you see the decimal numbers 0.1, 0.01, 0.001 , you interpret them as 1/10, 1/100 and 1/1000 respectively. The binary numbers 0.12, 0.012 and 0.0012 have identical representations: 1/10, 1/100 and 1/1000 respectively, albeit in a different number system. To determine the value of a binary fraction, you need to know the decimal equivalent of these numbers. Thats simple: (1/10)2 is equivalent to (1/2)10. In the same fashion (1/100)2 = 1/4 and (1/1000)2 = 1/8. By now you should have inferred that these binary fractions are the negative powers of 2.
Armed with this knowledge, we can now determine that 1.0012 is equal to 1 + 1/8 or (1.125)10. We can now finish converting our extended number:
1 * 23 * 1.125 = 8 * 1.125 = 9
If the significand raised to its exponent yields an integer (no fractional part) you can very quickly determine that value of the number:
(-1)0 * 23 * 1.001 = 1 * 8 * 1.0012 = 910
In other words, just slide the significand to the right by the number of decimal places in the exponent. This is a simple trick that any student of the metric system understands but tends to be forgotten when we change to a non-decimal number system.
Try some of these problems on your own. You might want to consider exercises like finding the largest positive and negative numbers that a given format can represent. Equally interesting, is finding smallest number that can be represented in this format. What does 0 look like (watch this, its a trick question)?
Listing 1 contains a grab bag of SANE glue routines which Ive provided as illustrations of how to interface with SANE. You may never need to use these conversions but knowing how this mechanism works will surely help you to debug code that references SANE.
SANE operations get dispatched via the trap _FP68K which most likely stands for Floating Point, 68000 (SANE has been implemented on ALL Apple platforms since the mid-80s).
The conversions typically take an input parameter, an output parameter and an opword. The opwords are mnemonic, FX2D stands for extended to double and FL2X stands for long to extended. The conversion utilities in SANE give you a lot of control over how you want to represent your data and how you want to present it to the user. If youre serious about these conversions, you might want to write a general purpose converter that can convert between any two formats.
If you want to explore SANE further, get a copy of the Apple Numerics Manual. The next time you run into one of those old hacks who believe that, it aint a real computer unless its water cooled, dont get upset. They need all that power to compensate for the fact that some of those monoliths cant even add as well as the Macintosh!
/* 2 */
void ExtToDouble( ext, dbl )
extended *ext;
double *dbl;
/******************************
* given the extended IEEE number
* passed in, return its double
* representation
*
******************************/
{
asm{
move.l 8(A6),-(sp); address of the extended
move.l 12(A6),-(sp) ; address of the double
move.w #FX2D,-(sp); push the appropriate opword
_FP68K
}
}
void DoubleToExt( dbl, ext )
double *dbl;
extended *ext;
/******************************
* given the double number
* passed in, return its extended
* representation
*
******************************/
{
asm{
move.l 8(A6),-(sp); address of the double
move.l 12(A6),-(sp) ; address of the extended
move.w #FD2X,-(sp); push the appropriate opword
_FP68K
}
}
void LongToExt( lg, ext )
long *lg;
extended *ext;
/******************************
* given the long number
* passed in, return its extended
* representation
*
******************************/
{
asm{
move.l 8(A6),-(sp); address of the long
move.l 12(A6),-(sp) ; address of the extended
move.w #FL2X,-(sp); push the appropriate opword
_FP68K
}
}
void ExtToLong( ext, theint )
extended *ext;
long *theint;
/******************************
* given the extended IEEE number
* passed in, return its long word
* representation
*
******************************/
{
asm{
move.l 8(A6),-(sp); pointer to the extended
move.l 12(A6),-(sp) ; address of the long
move.w #FX2L,-(sp); push the appropriate opword
_FP68K
}
}
void DoubleToLong( dbl, theint )
double *dbl;
long *theint;
/******************************
* A simple conversion utility that might be useful
* for debugging at the TMON and MACSBUG level.
******************************/
{
extended temp;
DoubleToExt( dbl, &temp);
ExtToLong( &temp, theint );
}
void ExtendedToStr( ext, theStr )
extended *ext;
char *theStr;
/*******************************
* convert an extended to a string
*
* First convert the number to
* a decimal record and then convert
* the decimal record to a string.
*
* The Hypercard callback ExtToStr does
* this for you. Ive added it here for those
* cases where you cant make a callback
*
* The conversions uses the decimal record
* structure thats documented in Apple Numerics
* manual.
*******************************/
{
decformdecrec;
decimaldecnum;
/*** convert the extended to a decimal ***/
decrec.style = FIXEDDECIMAL;
decrec.digits= 0;
num2str( &decrec, *ext, theStr );
}
LISTING 1. Some Interesting SANE conversion utilities