Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Using Floating Point to Package Larger than Integer Data Fields

IP.com Disclosure Number: IPCOM000110303D
Original Publication Date: 1992-Nov-01
Included in the Prior Art Database: 2005-Mar-25
Document File: 3 page(s) / 136K

Publishing Venue

IBM

Related People

Brenner, LB: AUTHOR

Abstract

Floating-point numbers can provide an efficient alternative to multi-word implementations of integers that are larger than the computer word size.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 53% of the total text.

Using Floating Point to Package Larger than Integer Data Fields

       Floating-point numbers can provide an efficient
alternative to multi-word implementations of integers that are larger
than the computer word size.

      It is sometimes necessary to store more information in a single
program data variable than will fit in an integer.  While this is
most often accomplished by using several integers (or a structure),
POSIX standards require certain variables to specifically be
arithmetic (or primitive) data types, which allows such variables to
be compared and manipulated easily in the C language.

      By careful selection of the exponent field of a floating-point
variable's internal representation, one may, in effect, provide a
large integer.  (On the 370, this would yield an effective 56-bit
unsigned integral value from a double precision floating-point
field).  To protect this integer from floating-point normalization
effects (which might otherwise cause subfields of the large integer
to be shifted in memory and thus difficult to retrieve efficiently),
we also sacrifice the high-order bit of the floating-point fraction
field and force it always to be 1.  Since there are now no leading
zeroes in the fraction, floating-point operations will never require
normalization, and the remaining 55 bits may safely be treated as a
limited use large integral field.

      Such fields may not only be readily compared, but can also be
incremented and decremented (within reason...you don't want to try to
represent a negative number in this way).  However, since the
high-order fraction bit participates in floating-point arithmetic,
direct multiplication and division operations cannot be used.

      Following is the C language prototype of an implementation,
which explains precisely how many of the operations we required were
reduced to makedev, major, and minor portions of a composite encoded
device number.  The composite values can be directly compared, and
even incremented, while the internal major and minor fields remain
consistently aligned for efficient retrieval via non floating point
operations.  (Floating point operations are a possibility, as shown
as comments in the example on the next page.).
/*
 *   Floating-point doubleword device number layout:
 *
 *   +-----+------+       +------------
 *     4e8   major             minor
 *   +-----+------+       +------------
 * *  9 bits 23 bits    32 bits    <- implied hexadecimal point
 *
 *   This layout provides a 23-bit unsigned major number and
 *   a 31-bit signed minor number.  The first 9 bits will be
 *   cleared when the major number is extracted to form an
 *   ...