*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]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]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]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]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]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]Real>. Currently it only works on AltoII 3K or ROM 41 machines, but soon... Do any of you want to be on [Ivy]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]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]WriteFormatted>Users.dl" For users of Mesa 6 floating point, there is a WF compatible module for printing them in [Ivy]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]Real>Doc>MesaFP3.bravo, .press. Misc alpha bytes 20B through 36B are currently used. They are declared in a private copy of MiscAlpha: [Ivy]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]Real>Users.dl" cc: LStewart The Mesa 6 Real package is now available. Everything lives on [Ivy]Real>. The documentation is [Ivy]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]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]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]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]Real>. I especially refer you to [Ivy]Real>Doc>MesaFloat60.press I will add you to [Ivy]Real>Users.dl, the Laurel distribution list for this stuff. Please send requests, comments, bug reports, etc. to Users.dl or to [Ivy]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]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]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]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]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]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]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]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<<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<<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]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 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]Real>Users.dl" cc: LStewart There is a new Reals.bcd and Reals.symbols on [Ivy]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]Real>Users.dl" cc: LStewart There are unknown bugs in the Alto Mesa6.0u floating point microcode ([Ivy]Real>Float6.br). CedarGraphics performs in generally unreliable ways. If this worries you, you can retrieve [Ivy]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]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]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]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]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]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]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]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]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]Real>Users.dl" cc: LStewart [Ivy]Real>Reals.bcd and Reals.symbols are new. These files work with the new Dorado microcode. For Alto FP users [Ivy]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]Real>Users.dl" cc: LStewart [Ivy]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]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]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]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]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]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]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]Real>Users.dl" cc: Stewart There is a new RealFnsImpl.bcd out on [Ivy]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]Real>Users.dl" cc: Stewart There are new versions of Reals.bcd, Reals.symbols, and the testing programs on [Ivy]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]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]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]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]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]Real>Users.dl cc: Stewart [Ivy]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]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]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]Real>Users.dl cc: Stewart [Ivy]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