*start*
00352 00024 US
Date: 9 June 1980 4:03 pm PDT (Monday)
From: Horning
Subject: Re: Floating Point
In-reply-to: LSTEWART's message of 9 JUN 1980 1534-PDT
To: LSTEWART
cc: Cedar-Lang↑, Warnock, Wyatt
Larry,
How big an audience do you want? Dealer would be a good place to expose the
whole lab. Cedar-Lang generally has about 5 of us.
Jim H.
*start*
01036 00024 US
Date: 9 JUN 1980 2034-PDT
From: LSTEWART
Subject: Re: Floating Point
To: Horning
cc: Warnock, Wyatt, LSTEWART
In response to your message sent 9 June 1980 4:03 pm PDT (Monday)
I don't know; this stuff has a lot of angles to it:
Language: syntax for lexically scoped rounding modes etc.
Proper style for exceptions, interaction with
NARROW & RangeError.
Architecture: FP instruction set, encoding thereof, per-process
data structures, double precision
Hard/firmware: D0 microcode space problems, D0 hardware interactions
Alto implementation, Dorado implementation (?)
Other issues: Side effects of arithmetic, fixed point overflow
detection, results of RESUME, Mesa stack size,
debugger stuff
The current focus of confusion is a) settling on an interface
and b) what needs to be done to compilers/instruction set to
allow more forward progress.
Probably much of this stuff is of wide (i hesitate to say) interest
but the immediate problems are more-or-less language related.
-Larry
-------
*start*
00533 00024 US
Date: 17 JUN 1980 0954-PDT
From: LSTEWART
Subject: MN-Float
To: M-Newell
cc: LStewart
See [Maxc]<LStewart>MN-Float.dm
This version of float stuff uses the BCPL-Float version of RealDefs but has
microcode operations. It requires some IMPORTS, just like the old microcode
version.
I also recompiled FloatFns with the f/c switch so it will run fast.
The files RealExtra.mesa and MN-Float.config had to change, so I have
put them in the dump file for safe-keeping.
I have not tested it. -larry
-------
*start*
01556 00024 US
Date: 19 June 1980 9:00 am EDT (Thursday)
From: DMurray.WBST
Subject: 3K Floating Point MC
To: LStewart.PA
cc: DMurray, CParker
Larry, have you or anyone thought of or resolved some seemingly ugly problems
in dealing with Mesa, the 3K CRAMs, and user microcode -- in your case the
Floating Point.
For cases involving emulator tasks and only RAM0, it is relatively easy to
combine your stuff with the Mesa overflow and go.
Consider the Express project, however, which is extending the Orbit task MC
(same for Trident or other non-emulator tasks). Because SWMODE does not work
properly between banks for non-emulator tasks (p58. hardware manual), we fill
RAM0 with the Orbit and Trident code. Floating point code necessary for spline
conversion, etc. will have to go to RAM2.
The question is how to return to Mesa in RAM1 from RAM2? Looking at the
Levin-Johnsson "...Harmonious Cooperation....User Microcode" of 4/1/80, suggests
using the typical SWMODE;
;romnextA;
sequence. My documentation shows romnextA is address 401 which is impossible
to reach if you are SWMODE-ing from RAM2.
What to do? First, does all this seem correct and inline with your
understanding? Does Mesa define another return address that we should be
using from RAM2? Finally as an "uglier" solution, I guess we could do a double
return from your code in RAM2. That is, SWMODE into RAM0 to a special
place of ours that immediately SWMODE's into RAM1 to the standard Mesa
return place.
Your advice appreciated -- Dan
*start*
00567 00024 US
Date: 23 JUN 1980 0903-PDT
From: LSTEWART
Subject: REAL printer
To: Malasky
cc: Wyatt, LStewart
Bruce,
[Ivy]<LStewart>Float>D60Real.dm has everything I think.
The one module needed is DRA.mesa. It needs Real.bcd and Ieee.bcd
to compile. I changed it to export DebugRealDefs for no particular
reason, but changing back to use DOutput is easy.
I would like to know how to add printers for other types,
perhaps replacing the standard ones or adding new ones. CSL
mesa (Cedar) has a new type ATOM which needs a printer.
-Larry
-------
*start*
00407 00024 US
Date: 25 JUN 1980 1138-PDT
From: LSTEWART
Subject: Mesa FP instructions, proposal
To: Cedar Language Features Design Committee:
cc: Wick, Warnock, Wyatt, LStewart
See [Ivy]<LStewart>Float>MesaFP2.bravo and .press
The note calls for a default instruction set, which does operations
using reasonable modes, and an extra set, which take their modes
off the stack.
-Larry
-------
*start*
00491 00024 US
Date: 27 JUN 1980 1159-PDT
From: LSTEWART
Subject: Real printout in Mesa6 debugger
To: Wyatt, Teitelman, Stone, Warnock
cc: LStewart, Malasky
[Maxc]<LStewart>DRA.bcd works. It prints out records funny for
an odd reason that will be fixed someday. Briefly, the
routine always prints xxx = yyy, even when it should print
xxx: yyy.
You still cannot use the interpreter to set REALs.
Many thanks to Bruce for his telephone answering and advice.
-Larrry
-------
*start*
00657 00024 US
Date: 2 JUL 1980 1253-PDT
From: LSTEWART
Subject: Alto-Mesa emulator
To: Satterthwaite, Levin
cc: LStewart
I have some questions about Mesa 6 stuff.
Are the floating point misc opcodes generated with the stack empty?
(i.e. are the operands the only things there?)
Are there any alignment constraints about turning a MISC into a
KFCB?
Is the alpha byte of MISC saved in a register somewhere on entry
to the RAM? Or do I have to save it away from T myself?
(In the case that a FP instruction looks like it will trap, I
want to push alpha on the stack and call my exisitng
Mesa stuff to handle the operation.
-larry
-------
*start*
00836 00024 US
Date: 8 JUL 1980 1844-PDT
From: LSTEWART
Subject: FP misc alpha bytes
To: Wick
cc: Levin, Taft, Warnock, LStewart
I am currently using these alpha bytes. As the defs file Real.mesa
has to know about them, please let me know if these are OK, or if
not, which ones are.
-- Floating Point known by the compiler
aFADD: CARDINAL = 20B;
aFSUB: CARDINAL = 21B;
aFMUL: CARDINAL = 22B;
aFDIV: CARDINAL = 23B;
aFCOMP: CARDINAL = 24B;
aFIX: CARDINAL = 25B;
aFLOAT: CARDINAL = 26B;
-- Added by me, known by Real.mesa
aFIXI: CARDINAL = 27B;
aFIXC: CARDINAL = 30B;
aFSTICKY: CARDINAL = 31B;
aFREM: CARDINAL = 32B;
aROUND: CARDINAL = 33B;
aROUNDI: CARDINAL = 34B;
aROUNDC: CARDINAL = 35B;
-Larry
PS These are implementing the 'easy' operations, fixed modes, specified in
[Ivy]<LStewart>Float>MesaFP2.press
-------
*start*
00544 00024 US
Date: 9 July 1980 1:24 am PDT (Wednesday)
From: LStewart
Subject: Mesa 6 Floating Point
To: CSL↑,M-Newell,GBrown,Satterthwaite,Wick,ABell,Malasky,Stone,Boyce
cc: LStewart
There is beginning to be Mesa 6 floating point stuff on [Ivy]<CedarLib>Real>.
Currently it only works on AltoII 3K or ROM 41 machines, but soon...
Do any of you want to be on
[Ivy]<CedarLib>Real>Users.dl or (hope) Support.dl ?
Some documentation should be available soon.
-Larry
P.S. What is the right place to advertise Users.dl lists anyway?
*start*
00873 00024 US
Date: 9 July 1980 1:34 am PDT (Wednesday)
From: LStewart
Subject: Mesa 6 FP
To: Stone,Warnock,Wyatt,GBrown
cc: Boyce, LStewart
If any of you want to try using this stuff, please go ahead.
Everything is on [Ivy]<CedarLib>Real>
The Defs are Real.mesa, FloatFns.mesa, and their .bcd's
The implementation is AltoII>Reals.bcd and AltoII>Reals.symbols
This new microcode runs about 4 microseconds per op slower than the old stuff
due to additional decoding and rounding code. Funny cases (infinities,
denormalized, etc.) trap to Mesa and run about 500 times slower (about 4
milliseconds rather than 70 microseconds for FAdd). Of course they hardly ever
happen and will probably raise a SIGNAL anyway, so who cares.
Inexact-Result is implemented, although it's trap is disabled. You can tell by
calling Real.GetStickyBits (if interested).
-Larry
*start*
00622 00024 US
Date: 13 July 1980 10:31 pm PDT (Sunday)
From: LStewart
Subject: REAL printout for WriteFormatted
To: "@[Ivy]<CedarLib>WriteFormatted>Users.dl"
For users of Mesa 6 floating point, there is a WF compatible module for printing
them in [Ivy]<CedarLib>WriteFormatted>Mesa6>.
Definitions: WFReal.bcd (and .mesa)
Code: WFRealImpl.bcd (and .mesa)
The only procedure to worry about is InitWFReals. STARTing WFRealImpl will
work also (and must happen after WFImpl is running!)
This module defines %f and %e and supplies the procedures. Documentation
has been added to WriteFormatted.press.
-Larry
*start*
00958 00024 US
Date: 13 July 1980 10:42 pm PDT (Sunday)
From: LStewart
Subject: REAL Misc instructions and SD indices
To: Wick, Rovner
cc: Warnock, LStewart
I am releasing the Real package for alpha testing via CedarLib. As it stands, the
package implements floating point operations with fixed modes and exceptions,
per [Ivy]<CedarLib>Real>Doc>MesaFP3.bravo, .press. Misc alpha bytes 20B
through 36B are currently used. They are declared in a private copy of
MiscAlpha:
[Ivy]<CedarLib>Real>FPMiscAlpha.mesa
As the compilation of Real.mesa, the major interface, depends on this file (as
does the microcode!), I would like to nail it down before too long.
When microcode traps to the Mesa implementation of the floating point
operations, it does so through SD 137B. This value is known only in the
implementing module and in the microcode, so it could change if need be.
Are these alpha bytes and this SD index reasonable values?
-Larry
*start*
00751 00024 US
Date: 13 July 1980 10:54 pm PDT (Sunday)
From: LStewart
Subject: Mesa 6.0u floating point
To: "@[Ivy]<CedarLib>Real>Users.dl"
cc: LStewart
The Mesa 6 Real package is now available.
Everything lives on [Ivy]<CedarLib>Real>. The documentation is
[Ivy]<CedarLib>Real>Doc>MesaFloat60.press.
This package will run on the Dorados, and on Alto IIs with either 3K rams or
Mesa 41 ROMs. It should work on CSL D0s shortly.
The Alto II implementation has microcode for the common cases; add takes about
50 or 60 microseconds. The Dorado, trapping to Mesa, runs at about one quarter
that speed.
As is usual for CedarLib, messages about this stuff should go to
[Ivy]<CedarLib>Real>Users.dl or Support.dl, as appropriate.
-Larry
*start*
00287 00024 US
Date: 16 July 1980 9:12 am PDT (Wednesday)
From: LStewart
Subject: D0 FP microcode
To: Fiala
cc: Boyce, LStewart
AMesa.mb!25 seems to work fine with my floating point tester. Should I tell
[Ivy]<CedarLib>Real>Users.dl about it? How do they get/load it?
-Ly
*start*
00206 00024 US
Date: 16 JUL 1980 1452-PDT
From: FIALA
Subject: D0 FP microcode
To: LStewart
cc: Boyce
You can tell your users about it. Sources are on [Ivy]<D0Source>AMesaSources.Dm.
-------
*start*
00880 00024 US
Date: 17 July 1980 11:38 pm PDT (Thursday)
From: LStewart.PA
Subject: Re: REAL
In-reply-to: Your message of 17 July 1980 3:21 pm PDT (Thursday)
To: Pany.ES
cc: LStewart
Yes. There is a Mesa 6.0u REALs package. It runs with microcode on 3K Alto
II's or Alto II's with Mesa 41 ROMs. It runs (slowly) on D0's with AMesa.mb!25
or above microcode (CSL stuff), and pretty well on Dorados. We are working on
D0 and Dorado microcode.
Everything you need is on [Ivy]<CedarLib>Real>.
I especially refer you to [Ivy]<CedarLib>Real>Doc>MesaFloat60.press
I will add you to [Ivy]<CedarLib>Real>Users.dl, the Laurel distribution list for
this stuff. Please send requests, comments, bug reports, etc. to Users.dl or to
[Ivy]<CedarLib>Real>Support.dl as appropriate.
This package is not very well advertised, so feel free to tell your friends about
it.
-Larry
*start*
00472 00024 US
Date: 18 July 1980 12:49 am PDT (Friday)
From: LStewart.PA
Subject: CSL D0 Mesa 6 Float
To: "@[Ivy]<CedarLib>Real>Users.dl"
Ed Fiala has added the instruction decoding for Mesa 6 floating point to the
microcode for CSL D0's. If you load your D0 with [Ivy]<D0>AMesa.mb!25 (or
newer), then the Mesa 6 float stuff will all work.
It will work very slowly (~ 2 milliseconds/op) until more microcode is written
(Jim Boyce is working on it).
-Larry
*start*
00761 00024 US
Date: 18 July 1980 4:38 pm PDT (Friday)
From: krasner.PA
Subject: Floating Pt microcode
To: smalltalkusers↑, marshall.wbst, lstewart
cc: krasner
Sidney Marshall, of WRC, has just completed integrating Larry Stewart's floating
point microcode with Smalltalk-76 (benchmarked at 20x faster). The system
requires a 3K CRAM XM Alto. As a by-product, he has also made it easier for
future microcode hackers to use extra RAM for their primitives.
[erie]<marshall>microsmall.boot is a file that has the floating microcode included
(requires! 3K RAM). We hope to include in the next release enough stuff so that
it would take only a changes.st file to turn your small.boot into a microfloating
small.boot. For more deatils, see me.
glenn
*start*
00657 00024 US
Date: 20 July 1980 12:16 am PDT (Sunday)
From: LStewart.PA
Subject: Re: Pls add to [Ivy]<CedarLib>Real>Users.dl
In-reply-to: Hamilton.ES's message of 18 July 1980 10:45 am PDT (Friday)
To: Hamilton.ES
cc: LStewart, Hayes
Ok, you are added to the list. You might care to look at
[Ivy]<CedarLib>Real>Doc>MesaFloat60.press.
I am no longer working on the real stuff (except bug fixing, if any bugs are
reported.). It all seems to work. Jim Boyce of CSL is working on CSL D0
microcode and Taft is working on Dorado microcode.
Is MesaUsers the right list for Mesa 6? I announced the existance of this stuff to
CSL and SSL.
-Larry
*start*
00379 00024 US
Date: 20 July 1980 12:26 am PDT (Sunday)
From: LStewart.PA
Subject: Smalltalk FP
To: marshall.wbst
cc: Krasner.PA, LStewart.PA
DId you use the Mesa 5 package or the Mesa 6 package? The Mesa 6 stuff is
now working and uses the IEEE standard. The microcode does not differ very
much. See [Ivy]<CedarLib>Real>, especially Doc>MesaFloat60.press
-Larry
*start*
04403 00024 US
Date: 20 July 1980 1:56 am PDT (Sunday)
From: LStewart.PA
Subject: Re: The behavior of REALs for +-*/
In-reply-to: McKeeman's message of 19 July 1980 9:08 am PDT (Saturday)
To: McKeeman
cc: LStewart, Cedar-Lang↑, Lampson, Warnock, "@[Ivy]<CedarLib>Real>Users.dl"
Larry, Can you help me fill in the table below for the Primer? Are there
missing entries?
I have answered for the modes round-to-nearest (unbiased), projective-infinity,
and warning-normalization (the default modes supported by the compiler and the
Real.bcd interface).
The following statements are true for REAL x, y, ..., (LONG) INTEGER i, j.
NaN==Not-a-Number
The Not-a-Number logic returns the lexicographically smaller operand if both
operands are NaN. If only one operand is NaN, it is returned)
statement under condition
-----------------------------------------------------------------------
x+0 = x always (when x=-0, the result is +0)
x+infinity = infinity except when x is NaN or infinity
(infinity+/-infinity -> invalid-operation in projective mode)
x+y = y+x always
x+(y+z) = (x+y)+z excepting NaN etc. this breaks
down when y and z are <<< x so that x+y=x (y is < 2↑-24*x)
however, y+z may be large enough to affect x
(x>0 & y>0) => x+y > x not if y<<<x so that x+y = x
(x>0 & y>0) => x+y >= x always
(in projective-infinity mode, infinity cannot be compared with
anything, ideally, the tests = and # should be ok, but the compiler doesn't
support them)
--x = x always
x-x = 0 except NaN and infinity
(x+y)-y = x if |x|<|y|, bits of precision will
be lost through rounding; also not true when x+y overflows
(x>0 & y>0) => x-y < x except when y<<<x
(x>0 & y>0) => x-y <= x always
x*0 = 0 x#infinity & x#NaN
x*infinity = infinity x#0 & x#NaN
x*plusInfinity = plusInfinity sign of infinity not distinguished
0*infinity invalid operation
x*1 = x always
x*(-1) = -x except NaN and infinity
x*x > 0 when x#0 except NaN or infinity
(x*x=0 when x*x < 2↑-149, the smallest representable number)
x*x >= 0 except NaN and infinity, which
can't be compared anyway
x*y = y*x always
x*(y*z) = (x*y)*z except when denormalization reduces
the precision of intermediate results or when the intermediate result overflows
(i*x)+x = (i+1)*x not always, Float[i]=Float[i+1]
if i>2↑24. Elsewhere rounding may affect the low bit or so.
0/x = 0 x#0 & x normalized & x#NaN
(dividing by a de-normalized number is invalid operation)
x/infinity = 0 x#infinity & x#NaN
infinity/x = infinity x#infinity & x#0
1/(1/x) = x only when no rounding takes place
x/1 = x always
x/x = 1 x#0 & x#infinity & x#NaN
(x*y)/y = x y#0 & y#infinity & y not
denormalized, see discusion of (x*y)*z, rounding
(x/y)*y = x y#0 & y#infinity & not
denormalized and rounding
(x←i; j←x;) i = j unless x has more than 24
significant bits (certain values >2↑24 are representable)
(i←x; y←i;) x = y unless NaN, infinity,
rangeError or rounding
Other issues
Compare: Floating compare returns -1, 0, or +1 for < =, and >. The compiler
then generates an appropriate jump instruction. This fails when the operands
are "different but unordered", as happens on comparing NaNs or projective
infinities.
Associativity and invertability: Generally these will work in the absense of the
inexact-result flag.
-Larry
*start*
00876 00024 US
Date: 21 July 1980 3:25 pm EDT (Monday)
From: Marshall.WBST
Subject: Re: Smalltalk FP
In-reply-to: LStewart.PA's message of 20 July 1980 12:26 am PDT (Sunday)
To: LStewart.PA
cc: marshall, Krasner.PA
I used the microcoded version of the old Float package. It uses 3 words, one for
exponent and sign and 2 for mantissa. This is to be compatable with the Smalltalk
format. There would be no problem with changing the format but I didn't. I will
take a look at the mesa floating-point and see if it is applicable.
The current floating-point version of smalltalk is an experiment to test adding
microcoded routines to smalltalk. Consequently, more attention was focused on
the microcode interface than the floating-point routines. Users should be
cautioned that the system is experimental and that possibly incompatable changes
might be made.
--Sidney
*start*
00505 00024 US
Date: 24 July 1980 9:39 am PDT (Thursday)
From: LStewart
Subject: Re: +/- infinity
In-reply-to: Your message of 21 July 1980 9:19 am PDT (Monday)
To: McKeeman
cc: LStewart
The bit patterns for plus and minus infinity exist regardless of whether infinity
mode is affine (2 of 'em) or projective (1 infinity). The mode makes a difference
when a compare is done or when an arithmetic operation needs to know a sign as
a result (as in 10/infinity, if it plus or minus zero?).
-ly
*start*
00802 00024 US
Date: 25 July 1980 2:20 pm PDT (Friday)
From: Crowther
Subject: Floating Stuff
To: LStewart
cc: Crowther
Larry,
I stole a bcpl to mesa floating point conversion routine from Warnock, and it
worked just fine except that all the numbers were too big by a factor of four. SO
I divided the numbers by four. (Fortunately, all I need to work with right now
are relatively small positive integers (screen coordinates)).
Do you know what is going on? Is this perhaps an old format? Do you have a
better routine? Could I get my factor of four more efficiently by decrementing
the exponent? (I suspect not, without some sort of test for overflow.)
As far as I can tell, there is NO change of the exponent from one form of the
Real to the other. Only the mantissa changes.
Will,
*start*
02542 00024 US
Date: 25 July 1980 5:17 pm PDT (Friday)
From: LStewart.PA
Subject: On conversion of old floating numbers
To: "@[Ivy]<CedarLib>Real>Users.dl"
cc: Crowther, LStewart
Here is a note about the differences among the BCPL floating point number
format, the Mesa 5 float format as implemented by <AltoSource>FloatSources.dm
and the Mesa 6 float format (IEEE).
All formats have a sign bit, 8 exponent bits, and 23 mantissa bits.
Bcpl reals have the sign bit in the word with the lower memory address.
Both Mesa formats have the sign bit in the word with the higher address.
Mesa 6 Reals encode the sign of the number only in the sign bit (1 => negative)
This is a sign-magnitude representation.
Bcpl and Mesa 5 use a two's complement encoding in order to implement compare
as a LONG INTEGER compare.
Bcpl reals have an explicit leading one bit in the mantissa, thus it is possible to
represent unnormalized numbers.
Both Mesa formats have a hidden bit, thus there is no representation for
unnormalized numbers (exception for de-normalized Mesa 6 reals).
The Mesa 6 real exponent is encoded as excess-127
Bcpl and Mesa 5 are excess-128
The interpretation of the mantissa of a Mesa 6 real is as a number between 1 and
2.
The interpretation of the mantissa of Bcpl or Mesa 5 reals is as a number
between 1/2 and 1.
Mesa 6 Reals have distinguished exponent values, exponent 377B is reserved for
infinity and Not-a-Numbers. exponent 0B is reserved for true zero and
denormalized numbers.
There is at least one, and probably several format conversion routines floating
around. Probably we should have a single package with a nice interface and so
on. While the conversion of the format per se is fairly strightforward, there is
no sense in multiple implementations, and the behavior of the conversion
routines on encountering non-representable numbers should be well defined.
If those of you out there will send me your existing routines, I will undertake to
put them under one roof and maintain them. I think the important routines are
BcplRealToIeeeReal: PROC [LONG UNSPECIFIED] RETURNS [REAL];
IeeeRealToBcplReal: PROC [REAL] RETURNS [LONG UNSPECIFIED];
Mesa5RealToIeeeReal: PROC [LONG UNSPECIFIED] RETURNS [REAL];
NonRepresentableNumber: SIGNAL;
NonRepresentableNumber would be raised when a value will not 'fit',
RESUMEing will cause something reasonable to be returned.
Should there be an InexactConversion SIGNAL? This might happen a lot on
IeeeRealToBcplReal and seldom in the other direction.
-Larry
*start*
00586 00024 US
Date: 13 Aug. 1980 8:44 am PDT (Wednesday)
From: LStewart.PA
Subject: New Reals.bcd
To: "@[Ivy]<Cedarlib>Real>Users.dl"
cc: LStewart
There is a new Reals.bcd and Reals.symbols on [Ivy]<Cedarlib>Real>. There were
no defs file changes. It seems that the Mesa code behind FixI would never
return negative values... This might have affected programs running on
machines without microcode support.
-Larry
P.S. Default value returned on RESUME from RealException[fixOverflow] is now
uniformly (across FixI, FixC, FixLI) the low order bits of the absolute value.
*start*
00409 00024 US
Date: 15 Aug. 1980 11:33 am PDT (Friday)
From: Taft.PA
Subject: Mesa microcode release
To: DoradoUsers↑
A new version of the Dorado Mesa microcode is released. The principal change
is that the Mesa 6 floating point operations (IEEE standard) are now
implemented in microcode. Also a few bugs are fixed, such as the color display
bug that caused unreliable operation on Dorado #4.
*start*
00541 00024 US
Date: 19 Aug. 1980 8:17 pm PDT (Tuesday)
From: Boyce
Subject: Floating Point Rounding Error
To: Taft, LStewart
cc: Ramshaw, Boyce
Here are two 24 bit numbers whose product has the (un?)desired property.
1100 0011 0001 0000 1101 0000
1100 0011 0001 0000 1010 1000
The full 48 bit product is
1001 0101 1010 0010 0111 1111 1000 0000 0000 1000 1000 0000
The 40 bit product ignoring the low8 by low8 bit term is
1001 0101 1010 0010 0111 1111 0111 1111 1000 0000
The low8 by 8 product is
1000 1000 1000 0000
jim
---
*start*
01222 00024 US
Date: 20 Aug. 1980 9:48 am PDT (Wednesday)
From: Ramshaw
Subject: Re: Floating Point Rounding Error
In-reply-to: Boyce's message of 19 Aug. 1980 8:17 pm PDT (Tuesday)
To: Boyce
cc: Taft, LStewart, Ramshaw
If you don't want to play with as many bits to check things out,
try multiplying the two 9-bit numbers whose octal representations
are 707 and 727 (two famous airplanes!). [7*7=61 in octal, by the way.]
The correct 18-bit multiplication is
.727
.707
------
. 6341
..... 6341
---------------
.... .642441
Thus, the correct 9-bit result is .643; note that it is normalized.
Alternatively, suppose we compute the product treating the left two octal
digits as the high order part, and the right one as the low order part.
The high-high contribution is then
.626000,
the two low-high contributions are
.006100 and .006260,
and the low-low contribution is
.000061 .
If we add all but the low-low term, we get
.642360,
which wants to round down to .642; and just noting that the low-low
product is non-zero and OR-ing in a one-bit doesn't change anything,
since there is already a one-bit in that position.
Lyle
*start*
00364 00024 US
Date: 20 Aug. 1980 12:00 pm PDT (Wednesday)
From: Taft
Subject: Re: Floating Point Rounding Error
In-reply-to: Boyce's message of 19 Aug. 1980 8:17 pm PDT (Tuesday)
To: Boyce
cc: LStewart, Ramshaw
Ok, I'm convinced. I will change the Dorado microcode to do the full
48-bit multiply. Thanks for working out the (un?)desired example.
Ed
*start*
01469 00024 US
Date: 20 Aug. 1980 6:01 pm PDT (Wednesday)
From: LStewart.PA
Subject: Buggy Microcode (Alto)
To: "@[Ivy]<Cedarlib>Real>Users.dl"
cc: LStewart
There are unknown bugs in the Alto Mesa6.0u floating point microcode
([Ivy]<Cedarlib>Real>Float6.br). CedarGraphics performs in generally unreliable
ways. If this worries you, you can retrieve [Ivy]<Cedarlib>Real>Float6ni.br and
name it Float6.br on your disk. This version calls the Mesa code all the time and
is thus very slow, but it works better.
Another odd problem has come to light: the floating point instructions expect the
stack to be empty when executed (except for their own operands). The compiler
knows this and does all the temporary stuff required to make it happen.
Unfortunately, Fix, FixI, and FixC are INLINE MACHINE CODE, and the
compiler does NOT enforce the stack restrictions. This means that an expression
like x ← 123+Fix[y]; may not produce working code. The result will be a
StackError sometime later. I am fairly sure you will eventually find out!
This fix for this is to add Pushes and Pops to the Alto microcode (might as well,
since it is broken anyway), and to fix up the Mesa trap handler a bit.
Float6ni.br does not fix this problem, and it may surface on the Dolphin and
Dorado as well; so until further notice (fairly soon) be leery of expressions
involving Fix, FixI, or FixC as components. (An expression as the argument of
Fix is fine).
-Larry
*start*
02354 00024 US
Date: 23 Aug. 1980 8:31 pm PDT (Saturday)
From: LStewart
Subject: New FP trap standards
To: "@[Ivy]<Cedarlib>Real>Support.dl"
cc: Sweet, Satterthwaite, Wick, Levin, Fiala, LStewart
I have just finished changing the Alto FP microcode to do pushes and pops
rather than requiring FP operands to be at the bottom of the stack. This was
intended to fix the problem of expressions involving Fix not compiling right.
(The compiler doesn't enforce minimal stack restrictions for MACHINE CODE
procedures.) Since all three machines now push and pop, we can remove the
stack restrictions from all FP operations. This presents a few problems with
trapping to Mesa: First, the Mesa trap procedure has to know where on the stack
to find the original operands, and second, the compiler will have to understand
that FP operations may trap, and need a stack word to pass the opcode of the
faulted operation to the trap handler.
The solution to the second problem turns out to be fairly easy. The microcode
can pass the opcode in the emulator register OTPreg ("other trap parameter"),
which is accessible from Mesa by TrapOps.ReadOTP. (Via Levin)
Fine point: a similar problem with generating a KFC from
Ram0 on the Alto has been solved (Levin again). Currently
the Alto FP microcode fetches the SD control link itself, puts
it on the stack and jumps to SFC because there was apparently
no way to get to KFCr in Ram1. It turns out that a convenient
place in the bounds check code is accessible...
On finding the operands, I want to take the position that the FP microcode must
restore the stack pointer to the state it was in before the instruction started. On
the Alto, I do this by saving stkp (expensive, sigh). On the D0, there is
hardware to save stkp (into SStkp) on instruction dispatch. It can be restored in
the trap microcode fairly easily. Willie-Sue tells me there is a similar facility on
the Dorado. Does this cause problems for anyone?
So:
1. Fix the microcode everywhere to use OTPreg to save the MISC alpha byte
2. Fix the microcode everywhere to restore the stack pointer on a trap
3. Fix the Mesa trap code accordingly.
4. Remove stack restrictions from all FP operations.
5. It will be pleasant if future versions of the Alto Mesa emulator make it
possible to get to KFC from Ram 0
-Larry
*start*
01066 00024 US
Date: 23 Aug. 1980 8:41 pm PDT (Saturday)
From: LStewart
Subject: FP random tester
To: "@[Ivy]<Cedarlib>Real>Support.dl"
cc: LStewart
I have written a program which generates random operands and calls both the
microcode and Mesa versions of the FP operations (Real.xxx and RealOps.xxx).
The program prints things when the results differ. It uses
[Ivy]<CedarLib>Random>RandomCard to generate the operands. The program
prints a '. every 100 sets of operands.
The program does not test FixI and FixC.
The program is [Ivy]<Cedarlib>Real>IeeeRandomTest.mesa and .bcd
The command line for a Dorado is:
WFImpl Reals RandomCardImpl IeeeRandomTest
The command line for an Alto is:
RunMesa Float6.br/m0 Mesa.image WFImpl Reals ↑
RandomCardImpl IeeeRandomTest
Both the Alto and Dorado produce things differing in the low bit. Mostly I don't
know which is wrong (microcode or Mesa). (Although the Mesa Divide is
definitely wrong).
Multiply and Divide are the most frequent offenders, but there is an occasional
Add or Subtract.
-Larry
*start*
01012 00024 US
Date: 24 Aug. 1980 2:51 pm PDT (Sunday)
From: Taft
Subject: Re: New FP trap standards
In-reply-to: LStewart's message of 23 Aug. 1980 8:31 pm PDT (Saturday)
To: LStewart
cc: "@[Ivy]<Cedarlib>Real>Support.dl", Sweet, Satterthwaite, Wick, Levin, Fiala
I have the following comments on your proposal:
1. It's my understanding that OTPReg is due to be eliminated when
implementations are converted to the "true" PrincOps, whenever that happens. I
believe that the PrincOps specifies that trap parameters are to be pushed onto the
stack. In light of this, perhaps using OTPReg is inappropriate.
2. On the Dorado, the SStkP feature is useless in conjunction with the multiple
entry point feature. However, saving StkP at the beginning of each floating
point instruction costs only one microinstruction, so it's no big deal.
3. Your proposed scheme is incompatible with the present one, so the microcode
and software changes will have to be coordinated. How do you want to do this?
Ed
*start*
00493 00024 US
Date: 24 Aug. 1980 2:54 pm PDT (Sunday)
From: Taft
Subject: Re: FP random tester
In-reply-to: LStewart's message of 23 Aug. 1980 8:41 pm PDT (Saturday)
To: LStewart
I was pretty careful about sticky bits, rounding, etc., in the Dorado
implementation. I will be interested to see the exact operands that give
inconsistent results.
(I have not yet fixed the inaccuracy caused by failing to compute the low-order
product during a multiply, but I will do so soon.)
Ed
*start*
00502 00024 US
Date: 25 Aug. 1980 7:49 am PDT (Monday)
From: Levin
Subject: Re: New FP trap standards
In-reply-to: LStewart's message of 23 Aug. 1980 8:31 pm PDT (Saturday)
To: LStewart
cc: Sweet, Satterthwaite, Wick, Levin, Fiala, Taft
If there ever is another version of the Alto/Mesa emulator, I'll see to it that KFCr
is accessible.
John: expect a "wish" AR.
Ed (Taft): The OTPReg problem should ultimately be fixed by using the true
PrincOps trap mechanism (parameter in L+3).
Roy
*start*
00407 00024 US
Date: 26 Aug. 1980 11:17 am PDT (Tuesday)
From: LStewart.PA
Subject: New FP release
To: "@[Ivy]<Cedarlib>Real>Users.dl"
cc: LStewart
This is to warn you that there will soon be a new release of the floating point
stuff together with new Dorado microcode. There are no defs file changes, but
everyone will need the new Reals.bcd.
This should happen in the next day or so.
-Larry
*start*
00511 00024 US
Date: 26 Aug. 1980 4:22 pm PDT (Tuesday)
From: Taft.PA
Subject: Dorado Mesa microcode
To: DoradoUsers↑, "@[Ivy]<Cedarlib>Real>Users.dl"
A new version of the Dorado Mesa microcode is released. It fixes a bug that
caused occasional disk failures when running Mesa 6. It also incorporates
revised floating point microcode that is incompatible with the previous version.
Programs that use floating point must be re-bound with the just-released version
of [Ivy]<CedarLib>Real>Reals.bcd.
*start*
00514 00024 US
Date: 26 Aug. 1980 4:53 pm PDT (Tuesday)
From: LStewart.PA
Subject: New release of Mesa 6 FP
To: "@[Ivy]<Cedarlib>Real>Users.dl"
cc: LStewart
[Ivy]<Cedarlib>Real>Reals.bcd and Reals.symbols are new. These files work with
the new Dorado microcode.
For Alto FP users [Ivy]<Cedarlib>Real>Float6.br is new. It fixes the problems
noted last week with uncertain operation of CedarGraphics.
Expressions with Fix as a component should now work also.
There were no defs file changes.
-Larry
*start*
00979 00024 US
Date: 26 Aug. 1980 5:00 pm PDT (Tuesday)
From: LStewart.PA
Subject: Floating point number conversion
To: "@[Ivy]<Cedarlib>Real>Users.dl"
cc: LStewart
[Ivy]<Cedarlib>Real>RealConvert.mesa and .bcd together with
RealConvertImpl.mesa and .bcd are a package providing conversion of floating
point numbers among various formats.
RealConvert: DEFINITIONS = BEGIN
-- Ieee Floating point format is the Mesa 6 standard. These
-- procedures convert from previous formats (BCPL and Mesa 5)
-- to the new format and also convert new format numbers
-- back to bcpl format. (Press files use the bcpl format).
CVError: ERROR; -- Signalled on impossible conversion in IeeeToBcpl
Mesa5ToIeee: PROCEDURE [a: LONG UNSPECIFIED] RETURNS [b: REAL];
BcplToIeee: PROCEDURE [a: LONG UNSPECIFIED] RETURNS [b: REAL];
IeeeToBcpl: PROCEDURE [a: REAL] RETURNS [b: LONG UNSPECIFIED];
END.
-Larry
P.S. The word swapping for BcplLongNumber is built into the above routines.
*start*
00789 00024 US
Date: 27 AUG 1980 2344-PDT
From: LSTEWART
Subject: FP Zero
To: Sweet
cc: LStewart
If you happen to see the AR I sent this afternoon... This is more info.
For some reason (I can't remember why), the IEEE FP standard has
both plus and minus zero. Minus zero is encoded as sign bit plus
all zeros (FIRST[LONG INTEGER]) and arises as a result of multiplying
or dividing plus zero by a negative number.
The code I found for IF x=0 was LLDB, OR, NOP, JNEZ. Unfortunately
Maureen Stone managed to get a minus zero. . . This was the
compiler on [Ivy]<alphamesa>temp>.
-Larry
BTW: As of yesterday, the fp microcode has no stack restrictions
on any machines. We moved the trap parameter to OTPreg in the
case that the microcode needs mesa assistance.
-------
*start*
00421 00024 US
Date: 29 Aug. 1980 11:00 am PDT (Friday)
From: LStewart.PA
Subject: Round in FP package
To: "@[Ivy]<Cedarlib>Real>Users.dl"
cc: LStewart
RoundLI, RoundI, and RoundC are not currently implemented in microcode.
They always trap to the Mesa FP routines. This is on the theory that they are
not used very often.
If you are a heavy or potentially heavy user of RoundX, please let me know.
-Larry
*start*
00386 00024 US
Date: 28 AUG 1980 1937-PDT
From: LSTEWART
Subject: RoundC
To: Wyatt
cc: Taft, LStewart
In fact, RoundC is not implemented on either the Dorado or Alto (It
always traps). Your program may run faster if you use FixC instead.
Do you want to use Round a lot? I guess we can move towards implementing
it in microcode -- it shouldn't be hard.
-Larry
-------
*start*
00401 00024 US
Date: 29 Aug. 1980 1:26 pm PDT (Friday)
From: Wyatt
Subject: Re: Round in FP package
In-reply-to: LStewart's message of 29 Aug. 1980 11:00 am PDT (Friday)
To: LStewart
cc: Wyatt
Yes, I'd like to see RoundX implemented in microcode. CedarGraphics needs to
round to the nearest pixel for both scan conversion and text display. The
rounding should be consistent and fast.
Doug
*start*
01158 00024 US
Date: 2 Sept. 1980 9:24 am PDT (Tuesday)
From: LStewart.PA
Subject: Status report on FP
To: "@[Ivy]<Cedarlib>Real>Users.dl", LStewart
There are no new versions announced here, but it is probably time for some
news items and reminders.
Known bugs.
Code like "x: REAL; IF x=0 THEN . . ." may break. The 6.0u compiler
optimizes compares against (constant) zero, which does not take into account the
existance of -0. -0 arises as a consequence of multiplying or dividing +0 by a
negative number. This will undoubtably be fixed, but you can avoid it by
comparing against a variable whose value is either + or - 0. (+0 and -0 are
equal but have different bit patterns.)
The Alto FP microcode (Float6.br) does not always get the low order bit
right on multiply or divide. It messes up about 1 in 200 randomly chosen sets of
operands. I am not in a hurry to fix this, but if you think it is urgent, let me
know.
Annoyances
RoundI, RoundC, and RoundLI are not implemented in Microcode.
They are slow. (This is on the list too.)
Field width specifications for WFReal (part of the writeformatted
package) don't work.
-Larry
*start*
00563 00024 US
Date: 8 Sept. 1980 6:26 pm EDT (Monday)
From: DMurray.WBST
Subject: 3K Floating Point MC
To: LStewart.PA
Larry, I was cleaning up my mail and ran across our discussion of putting your
Floating Point MC (and XMesa overflow) in RAM2 since we have RAM0 full of
Orbit and Trident code.
Yup, it all works. We use the Mesa command line to load the RAM's to avoid
mucking with RunMesa.run -- ugly, but it works. Along the way, we added a
return to the mesa code in RAM1, so as to avoid the double return jump --
RAM2 to RAM0 to RAM1.
Dan
*start*
00376 00024 US
Date: 8 SEP 1980 1619-PDT
From: STEWART
Subject: Re: 3K Floating Point MC
To: DMurray.WBST
cc: STEWART, CParker.WBST
In response to your message sent 8 Sept. 1980 6:26 pm EDT (Monday)
Could you point me at the 3K stuff? I'd like to do the same
thing for the Audio software we have here so the Audio microcode
can live in Ram0.
-Larry
-------
*start*
00356 00024 US
Date: 11 Sept. 1980 8:06 am PDT (Thursday)
From: Johnsson
Subject: Alto Floating Point microcode
To: LStewart
cc: Johnsson
I want to get the final integration of the Alto microcode for Mesa 6 together
soon. Is there any chance that you will have floating point microcode you
would like to include in the standard XMesa overflow?
*start*
01936 00024 US
Date: 11 Sept. 1980 11:44 am PDT (Thursday)
From: Stewart
Subject: Alto FP microcode
To: Johnsson
cc: Stewart
Here is the situation...
I have a small amount of microcode which stuffs the MISC alpha byte into
OTPreg and branches to KFC 137. This permits all the FP code to be in Mesa
and is very small. I think that should certainly be in the standard release.
I also have a large (nearly full) overflow containing code to do the operations
(except for funny cases, which trap as above). There are some problems with it
though: Multiply and divide get the low bit wrong about 1/2 % of the time and
the Round instructions are not implemented. I can fix the latter fairly easily.
I did cobble up my own RunMesa the other day that has a full RamImage for
Ram0 with the FP stuff included. All that stuff is on [Ivy]<Cedarlib>Real> as
RunMesa.run and Run.bcpl and XMesaOverflow.br, but is not announced
anywhere.
The FP ram image includes HBLT for Griffin and ImeXfer, which may not be
useful anymore.
If most people won't mind the additional 7 or 8 disk pages for RunMesa, I'd say
'yes', put in the FP as standard. I can fix the Round instructions sooner rather
than later to avoid future changes. I am inclined not to fix multiply and divide
in the short term. If disk space is a problem (Front.run too I guess), then I
would suggest putting in the small amount of code for trapping and separately
distributing a larger RunMesa with FP included. I have found that "Runmesa
xxx.br/m0 mesa...." significantly interferes with my making command files that
work everywhere so I will want to use a RunMesa which includes FP.
Are you aware of the work at WRC on moving the overflow to Ram2 of 3K
Altos? They moved the FP up there too, leaving Ram0 free for Orbit/Trident
etc. I will probably want to do that someday too, to allow running the Audio
task microcode along with the floating point.
-Larry
*start*
00380 00024 US
Date: 11 SEP 1980 1517-PDT
From: STEWART
Subject: FP scanner
To: Satterthwaite
cc: Stewart
I guess the scanner still blows up if a real literal has more than 8 digits
or so. This ought to be fixed. How about passing the entire string
xx.yye+/-zz to Real.StringToReal or some such? I would work on a smallerized
implementation etc.
-Larry
-------
*start*
00858 00024 US
Date: 12 Sept. 1980 8:54 am EDT (Friday)
From: DMurray.WBST
Subject: Re: 3K Floating Point MC
In-reply-to: STEWART.PA's message of 8 SEP 1980 1619-PDT
To: STEWART.PA
Larry, all the stuff we use in in [erie]<CParker>ExpressMC.dm both *.br's and
*.mu's. It may take a bit of re-organization to unscramble the Express Orbit stuff
from the Mesa, Mesa overflow+Reals, but this is more a matter of looking at file
contents than anything else.
I'm not sure I told you, but we were unable to convince Roy Levin to have
RunMesa.run load RAM2 with the Mesa overflow stuff. Consequently, when we
run, we must force RunMesa.run to do this explicitly. Our OS command lines
look something like the following:
RunMesa.run OrbitTridentMC/M0 MesaMC/M1 MesaOverFlow&RealsMC/M2
ImageFileName/i....
Bit ugly, but it works... Good luck -- Dan
*start*
00273 00024 US
Date: 15 Sept. 1980 1:11 pm PDT (Monday)
From: Stewart
Subject: New testers
To: "@[Ivy]<Cedarlib>Real>Support.dl"
cc: Stewart
There are new versions of IeeeTest and IeeeRandomTest on Cedarlib>Real that
support RoundLI, RoundI, and RoundC.
-Larry
*start*
00349 00024 US
Date: 16 Sept. 1980 3:50 pm PDT (Tuesday)
From: Stewart.PA
Subject: RealFns, new version
To: "@[Ivy]<Cedarlib>Real>Users.dl"
cc: Stewart
There is a new RealFnsImpl.bcd out on [Ivy]<Cedarlib>Real>. The old one had a
version of Exp that didn't work at all (noticed by Stone, Warnock, et al.).
No Defs file changes.
-Larry
*start*
00815 00024 US
Date: 16 Sept. 1980 4:06 pm PDT (Tuesday)
From: Stewart.PA
Subject: New Floating Point Stuff
To: "@[Ivy]<Cedarlib>Real>Users.dl"
cc: Stewart
There are new versions of Reals.bcd, Reals.symbols, and the testing programs
on [Ivy]<Cedarlib>Real> These have some bugs fixed (like one noticed by Jim
Boyce that turned up once in 700,000 randomly chosen Adds.).i
There are no defs file changes.
There is a new Float6.br also. This one implements Multiply and Divide
correctly and has Real.RoundLI, RoundI, and RoundC in microcode.
There is a RunMesa.run on [Ivy]<CedarLib>Real> that permits you to avoid the
"RunMesa Float6.br/m0 Mesa.image xxx" on Alto IIs because it has Float6.br
inside itself. This RunMesa is NOT supported by SDSupport - it is an
underground project of mine.
-Larry
*start*
00286 00024 US
Date: 19 SEP 1980 1305-PDT
From: STEWART
Subject: Float microcode
To: Johnsson
cc: Stewart
Everything is on [Ivy]<Stewart>mu>. Float6.mu has a line including
Checksum.mu and it assembles ok and runs FP ok. I didn't test
the Checksum part.
-Larry
-------
*start*
00332 00024 US
Date: 21 Sept. 1980 5:23 pm PDT (Sunday)
From: Taft.PA
Subject: Dorado floating point microcode
To: @[Ivy]<CedarLib>Real>Users.dl
cc: Taft
The Dorado Mesa microcode now implements the Round, RoundI, and RoundC
opcodes; formerly these trapped to software. This should improve performance in
CedarGraphics.
*start*
00659 00024 US
Date: 23 Sept. 1980 8:58 am PDT (Tuesday)
From: Johnsson
Subject: New RunMesa
To: Murray (Checksum), Stewart (FP), Stone (Griffin)
cc: Johnsson
I have stored a new RunMesa (version35.8) on [Igor]<Johnsson>Temp>. This one
includes microcode for Pup checksums, IEEE floating point and HBlt for Altos
with multi-bank control store. I would appreciate your trying this RunMesa
with particular attention to verifying that your particular microcode is operating
correctly. Running on as many different types of machines and memory
configurations will also be helpful. Please report any findings by the end of the
day.
Thanks,
Richard
*start*
00502 00024 US
Date: 23 Sept. 1980 10:32 am PDT (Tuesday)
From: Stone
Subject: Re: New RunMesa
In-reply-to: Johnsson's message of 23 Sept. 1980 8:58 am PDT (Tuesday)
To: Johnsson
cc: Murray (Checksum), Stewart (FP), Stone (Griffin)
I'll try to get an HBlt tester up in the next day or so, and test the new RunMesa.
Griffin doesn't run with Mesa 6 floating point yet, as I was waiting for the next
release of the alpha compiler before converting.
Thanks for the update information.
Maureen
*start*
00825 00024 US
Date: 23 Sept. 1980 1:16 pm PDT (Tuesday)
From: Wyatt
Subject: Floating point test
To: Stewart
cc: Wyatt
I interrupted the floating point test you were running on my Alto (at 13:10). It
had found the following:
Alto/Mesa 6.0u of 6-Aug-80 14:57
23-Sep-80 9:34
>Reals -- 150564B
>wfimpl -- 172014B
>randomcardimpl -- 170620B
>ieeerandomtest -- 147434B
............................................................................................................................................................
Add
a = -4.500213e+15 bin: - e 51 m: 1.7771655400
b = -1.706506e+13 bin: - e 43 m: 1.7412424200
xu = -4.535419e+15 bin: - e 52 m: 1.0034741200
xm = -4.517277e+15 bin: - e 52 m: 1.0014341200
..........................................................................................
*start*
00904 00024 US
Date: 29 Sept. 1980 1:25 am PDT (Monday)
From: Stewart.PA
Subject: 6.0m Real package
To: @[Ivy]<Cedarlib>Real>Users.dl
cc: Stewart
[Ivy]<Cedarlib>Real> has been updated to Mesa 6.0m. There are a number of
important changes.
The name of the implementation has changed from Reals.bcd to RealImpl.bcd.
The symbols are now RealImpl.symbols.
The standard RunMesa.run now supports Alto FP microcode, so you no longer
need to manually load microcode. Also, D0/Dolphin FP microcode is available
(thanks to Jim Boyce). Get it from wherever D0 microcode comes from.
AlmostZero and AlmostEqual are new procedures in RealFns that allow you to
detect near-equality in a scale-independent way.
Some of the more obscure procedures in RealOps have been de-implemented. If
you needed one of them, let me know!
The Mesa 6.0u stuff is archived (On TAPE!) if you really need it.
-Larry
*start*
00249 00024 US
Date: 29 Sept. 1980 1:26 am PDT (Monday)
From: Stewart
Subject: 6.0m Real package
To: @[Ivy]<Cedarlib>Real>Support.dl
cc: Stewart
FloatTimeTest now supports RoundLI, RoundI, and RoundC, if you have been
curious...
-Larry
*start*
00299 00024 US
Date: 29 Sept. 1980 1:30 am PDT (Monday)
From: Stewart
Subject: rounding
To: Petit
cc: Stewart
I think I have fixed the rounding of denormalized numbers (well - I changed it
anyway!). This is all for Mesa 6.0m.
Why aren't you on [Ivy]<Cedarlib>Real>Users.dl ?
-Larry
*start*
00226 00024 US
Date: 29 Sept. 1980 1:34 am PDT (Monday)
From: Stewart.PA
Subject: Real documentation
To: @[Ivy]<Cedarlib>Real>Users.dl
cc: Stewart
[Ivy]<Cedarlib>Real>Doc>MesaFloat60.press has been updated.
-Larry
*start*
00351 00024 US
Date: 29 Sept. 1980 9:56 am PDT (Monday)
From: Taft
Subject: Re: 6.0m Real package
In-reply-to: Stewart's message of 29 Sept. 1980 1:26 am PDT (Monday)
To: Stewart
1. Your modified FloatTimeTest apparently never made it back out to Ivy.
2. Why is fix to long integer called Fix but round to long integer called
RoundLI?
Ed
*start*
00538 00024 US
Date: 29 Sept. 1980 1:20 pm PDT (Monday)
From: Stewart
Subject: Floattimetest
To: Taft
cc: Stewart
Right you are! The changes seem to have been lost. I have put a new
FloatTimeTest out there. RoundX on the DOrado seem to be about 2 microseconds
after taking off for loop overhead. They are 700 nS or so slower than FixX.
Fix vs. RoundLI is for historical reasons. There is an SD entry called Fix. The
FixI, FixC and RoundX were added later. This is not a very good reason. Just a
wart I guess!
-Larry