*start*
00322 00024 US 
Date: 1 Oct. 1980 2:18 am PDT (Wednesday)
From: Stewart.PA
Subject: Real mail
To: "@[Ivy]<Cedarlib>Real>Users.dl"
cc: Stewart

I have stored the accumulation of mail about Mesa 6 floating point as
[Ivy]<Cedarlib>Real>Real01.mail.  Historians may be interested. This is a Laurel
mail file.
	-Larry

*start*
00720 00024 US 
Date: 1 Oct. 1980 1:18 am PDT (Wednesday)
From: Stewart
Subject: Reals for Cedar
To: Morris
cc: Stewart

Everything needed for Real numbers to work is in [Ivy]<Cedarlib>Real>.  The
documentation is Doc>MesaFloat60.press on that directory.

The major defs files are Real and RealFns, implementations are RealImpl (A
config) and RealFnsImpl.

I guess I don't care too much about putting a release version for Cedar in some
subdirectory of Cedar, provided that I don't have to do the work!  (Brownie can
do it.)  However, we are short on disk space these days and why have multiple
copies around?  If things inside cedar should be in subdirectories, why not
change cedarlib into Cedar>lib?

	Larry

*start*
00342 00024 US 
Date: 1 Oct. 1980 11:27 am PDT (Wednesday)
From: Stewart
Subject: STARTing Reals
To: Morris
cc: Stewart

(As in the Documentation)

You can either call Real.InitReals[], or START Real.RealControl, or just load
RealImpl on the command line.  InitReals is idempotent, but RealControl isn't
(Should I fix that?)
	-Larry

*start*
00357 00024 US 
Date: 2 Oct. 1980 12:08 am PDT (Thursday)
From: Morris
Subject: Reals package
To: Stewart
cc: Teitelman

I am using Warren's config as a guide in building the 6.0m version of Cedar and
have the following confusions:

He uses a module called Reals.  Should that be RealImpl now?

What about the D0 micro-code?  Who purveys that now?

*start*
01029 00024 US 
Date: 2 Oct. 1980 12:16 am PDT (Thursday)
From: MBrown
Subject: IEEE floating point IO
To: LStewart

I made an inquiry a few months ago when the format for the text representation
of floating point numbers (and the problem of "stable" conversions) was being
debated.  I just got this response...

------------------------------------------------------------
Mail-from: Arpanet host SUMEX-AIM rcvd at 25-SEP-80 1051-PDT
Date: 25 Sep 1980 1053-PDT
From: Grosse at SUMEX-AIM
Subject: IEEE floating point IO
To:   mbrown at PARC-MAXC
cc:   grosse, dlb at SU-AI


Mark

By now you are presumably finished with your floating point project,
but just in case you are still interested:  Jerome Coonen wrote a
paper on "Binary<->decimal conversion in KCS arithmetic" published
as document P754/80-4.15 of the IEEE floating point standards
committee.  Such documents are available from David Hough, Box 561,
Cupertino CA 95015.

Best wishes
Eric
-------
------------------------------------------------------------

*start*
00458 00024 US 
Date: 14 Oct. 1980 11:51 am PDT (Tuesday)
From: Stewart.PA
Subject: New RealImpl
To: "@[Ivy]<Cedarlib>Real>Users.dl"
cc: Stewart

There is a new RealImpl.bcd and a new RealImpl.symbols out on
[Ivy]<Cedarlib>Real>.  There are no recompilations.  The only idfference is that
this RealImpl.bcd includes (and EXPORTS) RealFns.  Thought it would be more
convenient.

You might have to twiddle your .configs to avoid duplications.
	-Larry

*start*
01002 00024 US 
Date: 27 Oct. 1980 8:32 am PST (Monday)
From: Satterthwaite
Subject: Code for Floating Point Operations
To: LStewart
cc: Warnock, Wyatt, Geschke, Sweet, Satterthwaite

While looking for something else in the code generators of the Mesa compiler, I
noticed that ALL floating-point operations appear to be compiled "minimal stack"
for ALL machines, i.e., when such an operation is invoked, only its operands are
on the register stack.  This strategy is guaranteed to dump and reload
intermediate results during evalution of an expression such as a*x+b*y (but I
believe the compiler does understand commutativity of floating +, * now).

It is my vague impression that this strategy is no longer necessary, at least for
some machine/microcode/hardware combinations.  Could one of you let me know
what the relevant (Mesa 6) combinations are, and just what is assumed in each
case about the code generated by compiling /f (i.e., the MISC operations for
floating point).  Thanks.

Ed

*start*
01091 00024 US 
Date: 27 Oct. 1980 9:17 am PST (Monday)
From: Stewart
Subject: Re: Code for Floating Point Operations
In-reply-to: Satterthwaite's message of 27 Oct. 1980 8:32 am PST (Monday)
To: Satterthwaite
cc: Stewart, Warnock, Wyatt, Geschke, Sweet,"@[Ivy]<Cedarlib>Real>Support.dl"

Here's the current state of the world:

Dorados, Dolphins (CSL flavor anyway), Alto II 3K, and Alto II 2K w/Mesa >=41
all support MISC floating point operations.

None of these machines even bother to fill in SD, so /-f will not work.

None of the machines have any stack requirements for the main
operations +, *, -, /, compare, float, or any of the Fixes or Rounds.  The Alto
does require minimal stack for the FSticky instruction, which only used by the
Mesa part of the floating point code.

If the microcode ever decides to trap or give up, it restores the stack to its state at
the beginning of the instruction, puts the MISC alpha byte into OTPReg, and
traps through SD[137B].  (This is in fact a general mechanism for trapping on
MISC instructions, if anyone wants to use it.) 

	Larry
*start*
00699 00024 US 
Date: 27 Oct. 1980 9:21 am PST (Monday)
From: Stewart
Subject: Floating Point Modes
To: "@[Ivy]<Cedarlib>Real>Support.dl"
cc: Stewart

Looks like I screwed up when I rearranged the format of floating point modes for
eventual use with the class of instructions that get their modes off the stack.  I
meant for the default modes to have all 0's in the left byte so that an LIB could
be used, but it looks like I forgot to fix up the field specifications in the
MACHINE DEPENDENT record.  This makes no particular difference, but it is
something to remember to do on the next recompilation of RealOps.  Is it true that
I can recompile RealOps without bothering anyone? 

	Larry
*start*
00496 00024 US 
Date: 27 OCT 1980 1304-PST
From: STEWART
Subject: IeeeTest.mesa
To:   Taft, Boyce
cc:   Stewart

If you have a copy of this file hidden away somewhere, please save it for me.
The master copy on [Ivy]<Cedarlib>Real> is truncated at length 2660.

I have a retreive request in for an archived copy from Mesa 6.0u, but I
don't know yet whether or not it will be intact.

Probably this represents a Formatter screw-up that I didn't notice, but
I'm not sure...

	-Larry
-------
*start*
00565 00024 US 
Date: 27 Oct. 1980 1:15 pm PST (Monday)
From: Stewart.PA
Subject: New RealImpl, RealConvertImpl
To: "@[Ivy]<Cedarlib>Real>Users.dl", Stewart

[Ivy]<Cedarlib>Real>RealImpl.bcd and RealImpl.symbols are now updated to Mesa
6.0f, as are the other implementation files.

The main defs file, Real, was not recompiled, but the secondary defs files, Ieee,
and RealOps, were.

If anyone out there has a copy of the file IeeeTest.mesa, please let me know it's
whereabouts.  All my copies seem to have gotten smashed somewhere along the
line.
	-Larry

*start*
00601 00024 US 
Date: 30 OCT 1980 1538-PST
From: STEWART
Subject: Pilot and Floating point
To:   Levin, Fiala, Taft
cc:   Stewart

As far as I know, the only thing that needs doing is making sure that
the MISC opcodes are handled reasonably.  Ed Fiala and I talked 
briefly.  Here is what we would like:

All unimplemented MISC opcodes store the alpha byte in OTPReg and
call KFC 137B with the stack unchanged.

Not too remarkably, this is just what happens now in the Alto world.
Any problems?  What needs doing?  (I think Fiala is going to talk
to Frandeen sooner or later.)
	-Larry
-------
*start*
00610 00024 US 
Date: 30 Oct. 1980 5:51 pm PST (Thursday)
From: Taft
Subject: Re: Pilot and Floating point
In-reply-to: STEWART's message of 30 OCT 1980 1538-PST
To: STEWART
cc: Levin, Fiala, Taft

I'm happy to do it that way if you want.  But do you really want all undefined
opcodes to pour through SD[137], as opposed to just unimplemented floating point
opcodes?  How is the use of SD[137] going to be resolved between competing trap
handlers for various unimplemented opcodes?

A more general solution might be for all undefined MISC opcodes to trap through
SD[k+alpha], for some constant k.
	Ed

*start*
00614 00024 US 
Date: 31 Oct. 1980 8:48 am PST (Friday)
From: Levin
Subject: Re: Pilot and Floating point
In-reply-to: STEWART's message of 30 OCT 1980 1538-PST
In-reply-to: Taft's message of 30 Oct. 1980 5:51 pm PST
To: STEWART
cc: Levin, Fiala, Taft

I'm inclined to agree with Ed; SD[137] should be just for the floating point
opcodes.  Furthermore, OTPReg is an undefined concept in the Pilot world, since
trap handlers get their parameters in a more reasonable way.  I also think we
should try not to be too profligate in the use of SD slots -- they are not an
indefinitely extendable resource.

Roy

*start*
01190 00024 US 
Date: 31 Oct. 1980 9:54 am PST (Friday)
From: Stewart
Subject: Re: Pilot and Floating point
To: Taft
cc: Stewart, Levin, Fiala

I may have screwed up my message (doubtless).  Ed Fiala and I think that MISC
should trap tgrough 137B and everything else should trap through 5
(sUnimplemented) or whatever happens now.  It is obviously necessary to be
able to tell which instruction was executed, and for MISC, to get the alpha byte
value.

I don't think that each misc should trap through a different place, as that would
lead to proliferation of the STATE_ and other ControlDefs stuff that is used to
decode the stack.  Currently there is a CASE statement underneath SD[137B] that
dispatches on the alpha byte after saving away the stack.

What is used instead of OTPReg in Pilot?  I guess there is no particular reason to
have compatible implementations for Alto and Pilot.  All the FP stuff needs is
the Alpha byte.

Incidently.  SD[130B] through [136B], which are listed as FP (/-f switch in
Compiler) are no longer used.  Should we return them to the pool?  I stuff
UnboundLink in there at the moment.  I also never got official permission to use
137B...
	-Larry

*start*
01362 00024 US 
Date: 31 OCT 1980 1429-PST
From: FIALA
Subject: Unimp. Mesa opcodes
To:   Taft, Levin, Stewart
cc:   Fiala

My concern is that we establish now a uniform procedure for dealing with
opcodes that are presently unimplemented so that during periods of transition
(i.e., when some versions of microcode implement an opcode, others not)
it will be possible to produce programs that contain the new opcode but
trap to a procedure instead of the microcode isn't there.

I am not sure how Mesa presently handles this.  Apparently, everything not
implemented traps through SD[5], but Larry Stewart used SD[137] for his
floating point opcodes.

With respect to efficiency, it seems that most of the changes in the opcode
set are in the MISC opcodes, so that the method used to trap unimplemented
MISC opcodes should be an efficient one.  This suggests a separate trap
for the MISC opcodes or a table with one entry for each of the 256 values of
the Alpha byte, as Taft suggested.

Whatever method is used in the microcode, the conventions employed by the
Mesa system should be such that one module can seize the trap for one
unimplemented opcode, while another module seizes the trap for some other one.
Given this constraint, the dispatch table suggested by Taft seems like
a good choice, even though it wastes 256 or 512 words of storage.
-------
*start*
00938 00024 US 
Date: 3 Nov. 1980 9:04 am PST (Monday)
From: Levin
Subject: Re: Unimp. Mesa opcodes
In-reply-to: FIALA's message of 31 OCT 1980 1429-PST
To: FIALA
cc: Taft, Levin, Stewart

The Mesa PrincOps (version 3.0c) specifies that all unimplemented opcodes,
including undefined MISC alpha values, trap through SD[5].  Although this trap
is specified to supply no information about the bytecode that caused it, we can
compatibly extend it pass the bytecode that failed (and alpha value).  The trap
handler can then dispatch as it pleases.

This removes the dispatch table and logic from the realm of the microcode,
which seems proper to me.  I don't buy the efficiency argument, since
presumably the trap is being taken at all because the microcode needed to
implement the desired function efficiently has not yet been written.  Under
these circumstances, the cost of an additional software dispatch seems acceptable.

Roy 

*start*
00520 00024 US 
Date: 3 Nov. 1980 9:12 am PST (Monday)
From: Levin
Subject: Re: Unimp. Mesa opcodes
In-reply-to: FIALA's message of 31 OCT 1980 1429-PST
To: FIALA
cc: Taft, Levin, Stewart

Another small observation:  in the Mesa PrincOps, traps appear to occur between
instructions.  Therefore, at the time an OpcodeTrap (SD[5]) occurs, the PC is
pointing to the initial byte of the instruction.  Given this, the trap handler
doesn't really need a parameter at all in order to dispatch to a software routine.  

*start*
01502 00024 US 
Date: 3 Nov. 1980 3:37 pm PST (Monday)
From: Stewart
Subject: Pilot FP opcodes
To: Levin,Fiala,Taft
cc: Stewart

Per our discussion today (Levin/Taft/Me).  In Pilot, all unimplemented opcodes
trap to SD[5] without disturbing the machine state and without updating the PC. 
Unimplemented opcodes, in particular, do not currently have any 'parameter'
(Pilot does not use OTPReg, but stores the parameter in the local frame of the
instruction that traps -- but this is irrelevant, since unimplemented doesn't need
a parameter.).  This mechanism includes the fp opcodes that may run for awhile
and then give up.  (probably this means that a floating point instruction that
gives up near the end of execution (after picking up the alpha byte etc.) will
have to back up the pc so that it points at the MISC instruction again.

The code underneath SD[5] will look at the code stream by hand and figure out
what instruction was being executed.  Some software dispatch mechanism will be
provided to call the right pice of code for a particular instruction or group of
instructions (e.g. FP as a class probably).

In the case of an unimplemented instruction being emulated, the Mesa software
will be responsible for bumping the PC for return to the instruction following
the one that trapped.

The Alto world will stay the way it is - FP via SD[137B] and alpha in OTPReg.
We didn't talk about future MISC instructions in the Alto world.  Maybe no-one
will want to implement any.

	-Larry
*start*
00714 00024 US 
Date: 5 Nov. 1980 12:24 pm PST (Wednesday)
From: Stevens
Subject: Floating Point Distribution List
To: Stewart
cc: Tremain, Stevens

Larry,

Please add my name to your Floating Point "Real" dl.  I work with Bob Tremain
and we intend to make extensive use of this capability starting immediately or as
soon as possible.

Where can we obtain a document describing how to bind the appropriate files
into a Mesa program?  I'm sure there's nothing to it but copying someones
example is easier than trial and error.  I dont see any direct reference in the
messages Bob has received in the last two months.

Also, how does one convert a text string to a REAL representation and visa
versa.

	Jim

*start*
00700 00024 US 
Date: 5 Nov. 1980 2:59 pm PST (Wednesday)
From: Stewart.PA
Subject: Re: Floating Point
In-reply-to: wu.ES's message of 5 Nov. 1980 11:43 am PST (Wednesday)
To: wu.ES
cc: LSTEWART

The Mesa 5 floating point stuff may be found on [maxc].  The documentation is
in <Altodocs>Float.press (or possibly MesaFloat.press).  Depending on whether
you have an Alto I or an Alto II you may want the Mesa version of the package
<Alto>Mesa-Float.dm, or the microcoded version <Alto>UCode-Float.dm.

Sources are in <AltoSource>FloatSources.dm.

Some of this stuff may be in the <Alto> directory down in ES

	-Larry

Let me know if you need anything else.  The Mesa 6 stuff is all different.

*start*
01013 00024 US 
Date: 5 Nov. 1980 3:09 pm PST (Wednesday)
From: Stewart
Subject: Re: Floating Point Distribution List
In-reply-to: Stevens's message of 5 Nov. 1980 12:24 pm PST (Wednesday)
To: Stevens
cc: Stewart, Tremain

You are on the list now.  For an example config, you might want to look at
[Ivy]<Stewart>std>Standard.config  (You might also want to look at
[Ivy]<Stewart>Std>MiscIO.mesa).  The relevant parts are to IMPORT StringDefs
(for RealImpl), and to EXPORT Real (If you need it outside the config).  If your
program does not explicitly call Real.InitReals[] then you may wish to have
RealImpl listed as one of your CONTROL modules.

For string conversion, Real.StringToReal does the job.  The other direction is
Real.AppendReal, see page 4 of [Ivy]<Cedarlib>Real>Doc>MesaFloat60.press.  (I am
advertising the WriteFormatted package for output also.  It's REAL conversion
stuff works although the field width specifications don't.  -- see
[Ivy]<Cedarlib>WF>WriteFormatted.press ).

	-Larry

*start*
00531 00024 US 
Date: 6 Nov. 1980 10:53 am PST (Thursday)
From: Karlton
Subject: Re: FP
In-reply-to: Your message of 4 Nov. 1980 2:40 pm PST (Tuesday)
To: Stewart

Larry,

If you EXPORT RealControl out of RealImpl.config, then I could start the module
as one of the control modules in my config.

One small nit:  at the top of page 3 of your "Mesa 6 Floating Point Package" of
September 29, in the fine point, you say "... the configuration Reals by ..." when
I think you mean "... the configuration RealImpl by ...".

PK

*start*
00596 00024 US 
Date: 6 Nov. 1980 11:38 am PST (Thursday)
From: Stewart
Subject: Re: FP
In-reply-to: Your message of 6 Nov. 1980 10:53 am PST (Thursday)
To: Karlton
cc: Stewart

Yesterday I modified MesaFloat60.press for just that reason.  I think I have now
found all instances of "Reals".

RealControl: PROGRAM is already declared in the defs file Real, which is
exported by RealImpl, so there shouldn't be any problem.  Anyway, if RealImpl
is nested in another config, the outer config can just say CONTROL xxx,
RealImpl, xxx and start it that way.  Or have I misunderstood?

	-Larry

*start*
00485 00024 US 
Date: 6 Nov. 1980 12:13 pm PST (Thursday)
From: Karlton
Subject: Re: FP
In-reply-to: Your message of 6 Nov. 1980 11:38 am PST (Thursday)
To: Stewart

It was my intention to put in "CONTROL RealControl, MyModule" in my config,
but unfortunately, RealControl, is not EXPORTed by RealImpl.  The list following
the CONTROL must contain only modules, not other configs.  The key phrase
is "control module".  It is not legal to put a config on the CONTROL list.

PK

*start*
00883 00024 US 
Date: 8 Nov. 1980 6:14 pm PST (Saturday)
From: Stewart.PA
Subject: New RealImpl
To: "@[Ivy]<Cedarlib>Real>Users.dl", Stewart

There is a new RealImpl.bcd and RealImpl.symbols on [Ivy]<Cedarlib>Real>

No defs file recompilations.

There are two changes:  RealFns.AlmostZero now works, and RealImpl EXPORTS
the module RealControl.

The latter change permits you to arrange for the real stuff to be started in an
outer config, like so:

Foo: CONFIGURATION
IMPORTS StringDefs  -- Used by RealImpl
CONTROL RealControl, FooImpl =
BEGIN
RealImpl;
FooImpl;
END.

When this configuration is started, first RealControl in RealImpl will be
STARTed, then FooImpl will be STARTed.  Since RealImpl is STARTed first,
FooImpl can use FP operations at will (including initialization of REALs in the
global frame of FooImpl).  (This change per suggestion by Karlton)

	-Larry

*start*
00364 00024 US 
Date: 10 Nov. 1980 10:10 am PST (Monday)
From: McKeeman
Subject: Re: New RealImpl
In-reply-to: Stewart's message of 8 Nov. 1980 6:14 pm PST (Saturday)
To: Stewart

Larry,  Tom Pittman of the IEEE standards group would be very interested in
anything you can send him about your packages.  I'll take care of the delivery
if you like.


Bill

*start*
00913 00024 US 
Date: 11 Nov. 1980 2:20 pm PST (Tuesday)
From: Stevens
Subject: Floating Point sample program
To: Stewart
cc: Tremain, Stevens

Larry,

I have a very simple mesa program which uses mesa floating point software.  A
few moments ago you helped me to run it for the first time.  This may make a
good programming example after it is cleaned up a little more.  The relevant files
are [Ivy]<Stevens>Calculate.mesa,bcd.

When you run the program it asks for a 'multiplier' and 'multiplicand' using
ReadReal for input, then prints back the 'product' using WriteReal.  I do not yet
know why the input is not echoed to the display.

If you look at the source I'm sure you'll see some simplifications to the first few
statements that would make this an even better sample program.  I look forward
to learning from your comments.

Thanks for your help.  I'm off to write some Real applications.

	Jim

*start*
00502 00024 US 
Date: 17 Nov. 1980 3:39 pm PST (Monday)
From: Stewart.PA
Subject: FP bug
To: "@[Ivy]<Cedarlib>Real>Users.dl"
cc: Stewart

Gene McDaniel and I have found a bug in the floating point stuff that will get
you to the debugger if an interrupt arrives in a small interval during the
handling of a floating point trap from microcode to mesa  (This does not happen
very often anyway).  I will be fixing it on Wednesday and will announce a new
wversion of RealImpl at that time.
	-Larry

*start*
00290 00024 US 
Date: 18 Nov. 1980 1:43 am PST (Tuesday)
From: Stewart
Subject: New FP
To: McDaniel,Stone
cc: Stewart

[Ivy]<Cedarlib>Real>RealImpl.bcd  is new.  It should fix the problem with Griffin
and the spy.  If so (would you check?) I will announce it to the world.
	-Larry