[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference rusure::math

Title:Mathematics at DEC
Moderator:RUSURE::EDP
Created:Mon Feb 03 1986
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:2083
Total number of notes:14613

28.0. "Integer Multiprecision Package" by AURORA::HALLYB () Sat Feb 04 1984 23:42

Announcing the availability of a multiprecision arithmetic package
for the VAX family of processors.

There is now available a package called IXP (Integer eXtended Precision)
that supports integer arithmetic to an arbitrary degree of precision,
limited only by available storage and VAX architecture constraints.

The IXP package consists of one object module (IXP.OBJ) which contains all
the code necessary to implement the supported operations.  Also provided
is a documentation package (IXP.DOC).  There is also an IXP.PLI that can
be %INCLUDEd with PL/I sources, which defines the entry points for PL/I.
These files are available on AURORA:: (note the deliberate lack of device
or directory), are available for INTERNAL USE ONLY for the present, while
we decide what to do with them.  Distributing the code outside of DEC is
likely to cause legal problems for DEC, distributor, and recipient, so
please refrain therefrom. 


	SOME FEATURES OF THIS PACKAGE

Implements a variety of arithmetic operations, in addition to the basic four.

PIC, fully reentrant code...can even be called at interrupt level, without
any process context.  All local storage is on the stack, address operations
all use unsigned arithmetic (I think).

Follows VAX architecture closely, routine names and arguments look much like
VAX machine language operations.

IXP is registered as VMS Facility 259.  However, the IXP code makes NO calls
to any VMS-specific routines.  Thus it could run on UNIX(tm) just as well.


	PROBLEM AREAS:

There is no architecture specified for XNs.  At the moment, I do not (cannot)
check CLASS or TYPE fields of arguments.

Returned status is always an SS$_ status.  I don't know if I should continue
using these or have my own message file or section.  The "right" thing to do
is still to be decided.

On overflow (answer too big to fit in allocated space) I set the V-bit in
the call frame PSL, and also return SS$_INTOVF.  Setting the V-bit will
cause an overflow trap if enabled, which may or may not be the right thing
to do for the high-level-language user.

Constructive comments on the problem areas above are invited.


	INCOMPLETES:

No convert from floating to XN.  None planned.  Is this a serious problem?

Negative exponentiations <i.e., A^(-B) (mod N)> are unsupported. 
Sometimes the answer is undefined, sometimes it is computable.
Is there a good general solution to this problem?
T.RTitleUserPersonal
Name
DateLines