<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
<title></title>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
<title></title>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
<title></title>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
<title></title>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
<title></title>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
<title></title>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
<title></title>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
<title></title>
About 10 years ago, I was using an algorithm which required more than<br>
15
digits of precision. I wrote some PDP-11 assembler code which<br>
could handle unsigned values up to 2^512 (just under 10^160) plus<br>
fractional numbers with 1024 bits that had a precision on the right hand<br>
side of the decimal point equal to the integer portion - 512 bits for
each.<br>
Actually, there were three levels of precision: 128 bits, 256 bits and
the<br>
maximum at 512 bits. The FORTRAN 77 integer symbols were LU...,<br>
MU... and NU... while the corresponding integer / fractional symbols<br>
were LX..., MX... and NX..., all allocated as CHARACTER *n variables.<br>
<br>
These subroutines are designed to be used under FORTRAN 77, so any<br>
PDP-11 operating system (such as RT-11 and RSX-11) can easily make<br>
use of them. While these routines include ADD, SUBTRACT and<br>
MULTIPLY, DIVISION is not available, although that is easily remedied<br>
via a FORTRAN 77 subroutine which arrives at the result via the standard<br>
approximation algorithm. Also available are ENCODE and DECODE<br>
routines to convert between internal binary and external decimal values.<br>
In addition, there are routines to convert back and forth between all
six<br>
sizes of variables and DOUBLE PRECISION floating point or REAL *8<br>
variables.<br>
<br>
Of late, I realized that a signed variable aspect is required, so I
have begun<br>
to consider what is needed. ALSO, because I so often run the PDP-11<br>
code under the Ersatz-11 emulator, I will consider supporting the use of<br>
six additional PDP-11 instructions (for each ONLY one combination of<br>
registers will be used as operands - Ersatz-11 supports a DLL):<br>
UMUL16 - unsigned multiple two 16 bit variables<br>
MUL32 - signed multiple two 32 bit variables<br>
UMUL32 - unsigned multiple two 32 bit variables<br>
UDIV16 - unsigned divide a 32 bit variable by a 16 bit variable<br>
DIV32 - signed divide a 64 bit variable by a 32 bit variable<br>
UDIV32 - unsigned divide a 64 bit variable by a 32 bit variable<br>
the UMUL16 and UMUL32 instructions being especially important to<br>
perform multi-precision MULTIPLY. I will also consider the possibility<br>
of a single PDP-11 instruction to perform multi-precision arithmetic of<br>
values contained in memory using that ability of the Ersatz-11 emulator<br>
to LOAD a user written DLL, namely to convert many of the PDP-11<br>
multi-precision assembler subroutines to a single PDP-11 instruction<br>
which would then be executed using x86 instructions at a much higher<br>
speed, sort of like a CIS for multi-precision variables. In that case,<br>
much larger sized variables could easily be supported due to the much<br>
higher speed of execution. In addition, the (approximately) 16KB<br>
of subroutine instruction / data memory within the emulated PDP-11<br>
could be substantially reduced.<br>
<br>
If there is sufficient interest and support, complete algorithms might
be<br>
implemented which could directly make use of the x86's huge GB<br>
memory to solve particular problems - sort of like a SLAR auxiliary<br>
processor CPU (which for example performed an FFT on a KB<br>
sized array in virtual memory) implemented in software rather than<br>
hardware.<br>
<br>
I hope that some interest is expressed. Commercial inquiries for a<br>
specific algorithm would obviously receive priority, but hobby users<br>
are expressly encouraged to express all of their needs as well.<br>
<br>
Jerome Fine<br>
</body>
</html>