*start*
00291 00024 US
Date: 19 Nov. 1980 2:30 pm PST (Wednesday)
From: Stewart.PA
Subject: Real Example
To: "@[Ivy]<Cedarlib>Real>Users.dl"
cc: Stewart
[Ivy]<Cedarlib>Real> RealExampleImpl.mesa and RealExample.config are an
example of a simple program which uses floating point.
-Larry
*start*
01153 00024 US
Date: 5 Dec. 1980 5:02 pm PST (Friday)
From: Stewart.PA
Subject: Pilot floating point status
To: Levin, Fiala
cc: Morris, Boyce, Wyatt, Taft, Stewart
Here is the current situation.
The released Dolphin Pilot microcode does not support the traps required to make
floating point work by trapping; nor does it include Jim Boyce's fast floating
point microcode. Ed Fiala is going to poke the Pilot people and see about fixing
the first part (making MISC opcodes trap correctly). Jim's microcode will need
some modifications to handle the Pilot trapping strategy (should be simple). We
can get along with just the trapping for a while (slowly).
Roy Levin is working on the mesa stuff that will intercept traps for all
unimplemented instructions, including floating point.
I will modifiy the mesa part of the floating point package to mesh smoothly with
the new trap handler. (I will need some help in getting the compilation done
and testing under Pilot...)
There may be desirable changes to the interface Real for Cedar/Pilot: the
RealException SIGNAL returns a POINTER to an exception record. Is this ok?
REF? or what?
*start*
00800 00024 US
Date: 8 Dec. 1980 3:14 pm PST (Monday)
From: Stewart.PA
Subject: Trap Handler comments
To: Levin
cc: Stewart
SpecialTraps looks fine.
Comment:
There is no provision for a client of the (monolithic) released Cedar to override
(say) the floating point handler with one of his own, then replace the original.
Perhaps either there could be an enumeration procedure or
RegisterOpcodeHandler could return whatever was there before.
Either method would allow me to slip in my own handler for some instruction,
then later on restore the original, without knowing what it was in advance.
(The new handler could just watch the traps going by and count them, before
passing control to the original trap handler; this might be of interest to future
statistics gatherers.)
Larry
*start*
01457 00024 US
Date: 12 Dec. 1980 10:02 pm PST (Friday)
From: Stewart.PA
Subject: Pilot Floating Point
To: CedarImplementors↑
[Ivy]<Cedarlib>Real>Pilot> contains the usual stuff.
Defs files: Real.bcd RealFns.bcd Ieee.bcd RealOps.bcd
Impl: RealImpl.bcd RealImpl.symbols
In order to avoid hanging on the trap handler and pilot microcode, I have
changed Real to use procedure calls rather than microcode (INLINEs). This
means that you must compile your programs with the compiler switch -f. This
switch causes the compiler to use SD-style procedure calls for the FP operations.
This will all be fixed whenever the microcode and trap hander are ready. At
that time, you will have to recompile floating point stuff with a new defs file.
For now, floating point will be very slow, both because of the procedure calls
and because there is as yet no microcode.
Notes:
Files with no source on [Ivy]<Cedarlib>Real>Pilot> have their source on
[Ivy]<Cedarlib>Real> (no change from Alto world)
The only test program I have tried is an equivalent of IeeeRandomTest. It is
IeeeRT.bcd (from IeeeRT.config and PIeeeRandomTestImpl.*). It works under
Tajo, rather than Cascade (IMPORTS Process, String, Time, TTY).
CAVEAT
I have noticed that the compiler switches set up with the options sheet in
CascadeExec go away under some circumstances that I don't understand. You are
advised to check. If you don't use -f, your code will break horribly.
*start*
00616 00024 US
Date: 28 Jan. 1981 10:13 pm PST (Wednesday)
From: Teitelman.PA
Subject: reals
To: baskett
Reply-To: Teitelman
cc: stewart
I use AppendReal (to do my outputting of reals to my own stream). I have
hokeyed it up to add a .0 in the case that there is no decimal point in the
resulting characters. I do this by searching through the string for a decimal
point. (a) it would be more efficient if I could do this simply by testing the
fractional part of the real to see if it was zero. How do I do this? (b) if and when
you fix appendreal, please let me know so I can take this kluge out.
warren
*start*
00586 00024 US
Date: 29 Jan. 1981 9:52 am PST (Thursday)
From: Stewart.PA
Subject: Reals
To: Teitelman
Reply-To: Stewart
cc: Baskett,Stewart
(Try again, fixing the bug.)
FracPart: [r: REAL] RETURNS [rr: REAL] = {
InternalFracPart: [rrr: REAL] RETURNS [REAL] = {
RETURN [rrr-Real.Fix[rrr]];
};
rr ← InternalFracPart[x ! Real.RealException => {
IF flags[fixOverflow] THEN { y ← 0; CONTINUE; }
ELSE REJECT;
}];
};
REAL-Fix[REAL] is the key part, the rest is to handle overflow. The second
level of procedure is to cover up a bug in Mesa SIGNALs.
*start*
00505 00024 US
Date: 29 Jan. 1981 8:55 am PST (Thursday)
From: Baskett.PA
Subject: Re: reals
In-reply-to: Your message of 28 Jan. 1981 10:13 pm PST (Wednesday)
To: Teitelman
cc: Stewart,Baskett
I worked on, with Larry's help, the real part of the write formatted and cedar
write formatted package so that it would do better in putting out 5.0, etc. I'm not
sure what this has to do with appendreal. If appendreal derives from the same
code then I can add my partial fixes to it also.
Forest
*start*
00939 00024 US
Date: 31 Jan. 1981 6:23 pm PST (Saturday)
From: Stewart.PA
Subject: New RealImpl, TrappingNaN
To: "@[Ivy]<Cedarlib>Real>Users.dl"
Reply-To: "@[Ivy]<Cedarlib>Real>Support.dl"
I found a low-frequency bug in the Mesa implementation of REALs,
multiplications or divisions with a result smaller in magnitude than 2↑(-278) or
so caused an uncaught ERROR. A fixed version of
[Ivy]<Cedarlib>Real>RealImpl.bcd, .symbols is out there now.
-Larry
There is also a dreadfuil sloppiness in Real.mesa, which probably won't be fixed
for the Mesa 6 world, but will be for Cedar/Pilot:
Real.TrappingNaN is supposed to be a value that you can use to initialize
storage. If picked up as an operand of a floating point operation (other than
assignment), it should raise Real.RealException[invalidOperation]. Unortunately,
it doesn't. A working version would be
NotANumber: REAL = LOOPHOLE[17740000002B]; -- unREAL number
*start*
00521 00024 US
Date: 20 Feb. 1981 3:56 pm PST (Friday)
From: Stewart.PA
Subject: New WFRealImpl
To: "@[Ivy]<Cedarlib>WF>Users.dl","@[Ivy]<Cedarlib>Real>Users.dl"
Reply-To: Stewart
cc: Baskett, Stewart
I have incorporated the changes Forrest made in CWFRealImpl back into
WFRealImpl, so both should behave the same and with luck, more correctly than
before. WFRealImpl is on [Ivy]<Cedarlib>WF>WFRealImpl.bcd and .mesa.
WFReal.bcd did not change.
Forrest will be putting CWFRealImpl on Cedarlib soon.
-Larry
*start*
01722 00024 US
Date: 11 March 1981 8:53 am PST (Wednesday)
From: Ayers.PA
Subject: Floating Point in 8000 Series?
To: Evans, Newlin
Reply-To: Ayers
cc: Irby, Nikora.ES (fyi)
cc: Karlton, Wick, Stewart, Johnsson, Sandman, Lipkie.ES (fyi)
cc: Ayers
I have investigated the supports for REAL arithmetic to see if it might be
appropriate for use within the 8044 printer software. [The alternative is 32-bit
arithmetic, which is partly implemented in software.]
An ieee-style floating point package which runs on Alto-style d0lphins is
available on ivy<cedarlib>. This package runs either with or without the
presence of several "misc" microcode implementations. A Rubicon version is
apparently not available.
Timings: I computed the expression Ax + By + C for precalculated A & B & C
[they were 0.5, 2.0, and -0.3333333] and for x ← y ← [0..999]. There are thus 1000
calculations of the expression per test.
REALs with microcode assist: 0.2 seconds per thousand
"Rational" representation (fractions: long integer/long cardinal): 1.8 seconds
REALs without microcode assist: 30.1 seconds per thousand
The "rational" arithmetic timing would be considerably worse if post-scaling was
required (observe that the numerators and denominators in the test case are all
small). A little playing with larger values suggests that post-scaling might
quadruple the average running time.
Conclusion: for 8044 printing software, running on a Dandelion without
microcode assist, REAL arithmetic is too slow to be utilized. (Consider that there
is an Ax + By + C, tho perhaps with A or B zero, about twice per text line. At
an incremental cost of 20 milliseconds per, that is about two seconds per page.)
Bob
*start*
01274 00024 US
Date: 11 March 1981 9:36 am PST (Wednesday)
From: Stewart.PA
Subject: REAL arithmetic
To: Ayers
cc: Stewart, Warnock, Lampson
REALs work in Mokolumne and I expect to make them work in Rubicon with
little to no difficulty, whenever Rubicon appears over here.
It is a little unfair to judge the potential performance of REALs by the
performance of RealImpl.bcd. That particular package is NOT designed to run
fast. It could be greatly sped up by application of modest effort. The intended
application of RealImpl was to handle the cases not supported by microcode
(traps, denormalized numbers, FixI[-32768], etc.).
In comparing rationals (exponent word plus LONG INTEGER) to REALs,
depending on whether you do post-normalization or not, the difference in speed
will be primarily due to packing and unpacking the 32 bit REAL representation.
As far as post normalization goes, I believe it is the case that the number of
normalization shifts required is roughly exponentially distributed with mean 1,
so it is not a big deal anyway.
It may be that a reasonable compromise is REAL arithmetic with an unpacked
representation and a fairly tight implementation (which RealImpl is not).
-Larry
PS RealImpl does Divide in a loop, one bit at a time...
*start*
01157 00024 US
Date: 11 March 1981 12:55 pm EST (Wednesday)
From: Lampson.PA
Subject: Re: Real msg from Ayers
In-reply-to: Stewart's message of 11 March 1981 9:37 am PST (Wednesday)
To: Ayers
cc: Warnock, Stewart, Lampson, Wick
Wait! The current intention is that you won't need to do either real or rational
arithmetic for transforming a coordinate from the user's CS to the device CS --
32-bit fixed point will be more than sufficient, i.e., 32-bit integers with a fixed
scaling. This means that add and subtract are identical to integer add and
subtract, and multiply is identical to integer multiply except for a scaling of the
result. For the 8044 putting the binary point in the middle of the 32 bits should
be fine. The multiply can be done with 4 16x16->32 multiplies and 3 32 bit
adds. Furthermore, if the client coordinates are integers (probably the case to be
favored by the encoding) there are 2 16x16 multiplies and 1 add. Either reals or
rationals will be needed ONLY for concatenating transformation matrices, or for
doing arithmetic explicitly specified by the arithmetic operations. Presumably
these are rare operations.
*start*
01008 00024 US
Date: 11 March 1981 10:14 am PST (Wednesday)
From: Ayers.PA
Subject: Re: "Wait!" and Real msg from Ayers
In-reply-to: Lampson's message of 11 March 1981 12:55 pm EST (Wednesday)
To: Lampson
cc: Ayers, Warnock, Stewart, Wick
The message from Stewart mentioned a "Rational" as a 32-bit thingie with a
power-of-two scale factor. But I did not.
I am doing 32-bit integer arithmetic and plan to continue.
I investigated REALs for two reasons:
Concatenating transformations, which is rare in the normal case but
may be un-rare in a heavy graphics environment. (Graphics guys are
considering CallConcat for displaying arrowheads by scaling and rotating
the ideal unit arrowhead.)
Because I was asked about REALs for the possible use of Star's
workstation graphics code.
I agree with all of Butler's point about the required precision. There are a few
uglies that one might mention, chiefly concerned with mischevious user
behavior, but they are in the noise.
Bob
*start*
01187 00024 US
Date: 10 March 1981 11:40 am PST (Tuesday)
From: Stewart.PA
Subject: Re: REAL via SOFTware
To: Ayers
cc: Stewart
They still exist... I dropped explicit support of the Procedure call versions
because they require a separate DEFs file and people were always confused about
what versions they had or needed. These days, my position is that Alto I's don't
exist and any newer machines should handle the REAL Misc opcodes -- at least
by trapping to software.
The present situation is that while the Alto II, Dolphin, and Dorado all have
REAL microcode, that code only speeds up the easy cases. At any time, the
microcode can trap to software. Rather than try to untangle partially completed
operations, the Mesa code starts over from the original operands, thus RealImpl is
actually a complete implementation.
If we have a processor around that is unable to handle MISC even far enough to
trap immediately, it would be no problem to build a version of Real.mesa that has
procedures instead of INLINEs and then use /-f to compile. (I did this for the
first Pilot REALs, but deleted it later.) In fact, RealOps.mesa is pretty close to
what is needed.
-Larry
*start*
01173 00024 US
Date: 30 March 1981 5:15 pm PST (Monday)
From: Smeltzer.ES
Subject: Mesa 6 Floating Point Package
To: Stewart.PA
cc: Smeltzer
Please add me to [Ivy]<CedarLib>Real>Users.dl as suggested in the Memo to Mesa
Floating Point Users dated Nov 4, 1980.
I may be a very short-lived user unless I can get past a hurdle which has
bugged me for a day. To Wit: I brought in all the requisite .bcd's and
RealExample.config and RealExampleImpl.Mesa from <CedarLib>Real>. The latter
compiled OK, but the .config required a change of StringDefs to String and the
addition of FrameDefs for it to bind without errors. Running RealExample results
in a freezing of the screen requiring a boot to recover. By debugging, it was
determined that this happens after the last statement in RealControl but before
getting to the first message in RealExampleImpl. I have a 64K Alto II for which
the board with the Mesa ROM's has just been changed to one with Mesa 6.0
ROM's.
Its highly probable that it is a simple procedural goof on my part. Any
suggestions would be greatly appreciated.
Jack Smeltzer, PSD, working on simulation of the 9700 and its enhancements.
*start*
01010 00024 US
Date: 30 March 1981 8:55 pm PST (Monday)
From: Stewart.PA
Subject: Re: Mesa 6 Floating Point Package
In-reply-to: Your message of 30 March 1981 5:15 pm PST (Monday)
To: Smeltzer.ES
cc: Stewart
I have added you to [Ivy]<CedarLib>Real>Users.dl.
I will look into RealExample I think. The difficulties you cite with String and
FrameDefs are my fault. RealImpl has changed since RealExample was last tried
I'm afraid.
The hanging of your Alto II sounds like trouble with the microcode, since you
needed to boot to recover. The first thing to check is to try "Runmesa/v<cr>"
which will print the version number of your microcode. If it doesn't say "41"
somewhere in the string (the alternative is 39 I think), then you have the wrong
ROMS.
Also, be sure that you got the stuff from [Ivy]<Cedarlib>Real> but NOT from
[Ivy]<Cedarlib>Real>Pilot> or Real>Rubicon> as those are pilot versions, which
work very differently.
More later when I look at RealImpl -- probably tomorrow.
-Larry
*start*
00802 00024 US
Date: 23 April 1981 3:21 pm PST (Thursday)
From: Jarvis
Subject: Floating Point IO
To: LStewart
cc: Jarvis
May I suggest that you either change the character that ReadReal and
AppendReal use to indicate the power of 10 or make it an optional argument? I
use all of your floating point software as part of the Calculator tool, but must use
my own version of IeeeIOB. The Calculator uses "↑" instead of "E" because "E"
is a perfectly good hex digit. For example, 1E1 is ambiguous; it can either be a
fixed or floating point number. I realize that this is not a big deal, but it grates.
I also have Cordic algorithm implementations for RealFns. These are much faster
when there is not microcode support for floating point and probably about the
same with microcode assist.
*start*
00561 00024 US
Date: 23 APR 1981 1606-PST
From: STEWART
Subject: Re: Floating Point IO
To: Jarvis
cc: STEWART
In response to your message sent 23 April 1981 3:21 pm PST (Thursday)
I am a bit reluctant to add an argument to appendreal.
You may find RealToPair more to your liking.
(Also, scanning the returned string for 'e and replacing it by
'↑ seems reasonable!.)
I'd like to look at your realFns sometime.
Also, I will be working on the ouput routines sometime soon,
since they don't work very well. Will keep you informed.
-Larry
-------
*start*
00307 00024 US
Date: 24 April 1981 10:08 am PST (Friday)
From: Jarvis
Subject: Re: Floating Point IO
In-reply-to: Your message of 23 APR 1981 1606-PST
To: STEWART
cc: Jarvis
Take a look at the following files on [Iris]<Jarvis>: Cordic.mesa CordicImpl.mesa
CordicFns.mesa and CordicConstants.mesa
*start*
01184 00024 US
Date: 21-May-81 11:16:37 PDT (Thursday)
From: Karlton.PA
Subject: Re: Floating Point
In-reply-to: STEWART's message of 20 MAY 1981 1831-PDT
To: Stewart
cc: Taft, Fiala, Murray, Guarino, Neely, Frandeen, Sandman, Johnsson, Karlton
Hal Murray forwarded your message to me that said that floating point works fine on Dolphins and Dorados. I asked around a little over here and got very confused. Some people said that the CSL microcode was different than the released Rubicon microcode and others weren't sure.
I was also told that, as of the latest update, the Dandelion microcode has been fixed so that the Misc alphabyte from 20B to 37B trap through SD[137B] with the opcode as the trap parameter. (I don't know what that means, but it may be useful to you.)
What I really want is a package I can load in my PreCascade world (on any of Dandelion, Dolphin or Dorado) and be able to do floating point arithmetic. What switch do I give the compiler to make sure it invokes the floating point operations the correct way?
PK
p.s. I was just told that the Rubicon Dolphin microcode gets an unimplemented instruction trap for Misc alpha-bytes in [20B..37B].
*start*
02685 00024 US
Date: 21 May 1981 2:56 pm PDT (Thursday)
From: Stewart.PA
Subject: Re: Floating Point
In-reply-to: Karlton's message of 21-May-81 11:16:37 PDT (Thursday)
To: Karlton
cc: Stewart, Taft, Fiala, Murray, Guarino, Neely, Frandeen, Sandman, Johnsson
Here is the Pilot FP situation as I understand it:
Mokolumne is dead.
Procedure Call FP is dead. zESC (MISC) 20B-37B are the only way to get at
floating point operations. SD[130B]-SD[136B] will not be used.
The Compiler default FP switch is /f, which generates zESC. The only version
of Real.bcd includes MACHINE CODE for Real.Fix, etc. which generate zESC.
Rubicon floating point:
[Ivy]<Cedarlib>Real>Rubicon>RealImpl.bcd with defs files Real, Ieee and
RealFns works fine on Dorados and CSL Dolphins.
SDD Dolphins run some other microcode, and FP does not work at all.
FP does not work on Dandelions at all.
How can this situation be changed so that SDD Dolphins and Dandelions will
work?
Change microcode or change the FP software.
1) Changing the microcode seems more reasonable to me. The FP world is set up
so that microcode can handle as little or as much of the work as there is
control-store room for, leaving the difficult cases or remaining opcodes to trap to
software (RealImpl.bcd). The way that CSL Dolphins and Dorados handle (Cedar)
traps is described in Roy Levin's memo
[Ivy]<CSL-Notebook>Entries>81CSLN-0004.press
and in Ed Taft's implementation
[Ivy]<Cedarlib>Trap>*.
(For the FP implementation, see
[Ivy]<Cedarlib>Real>Rubicon>PilotRealControl.mesa.)
If SDD Dolphins and Dandelions follow these trap conventions, then the existing
FP stuff will all work.
Fine Points: The CSL FP Dolphin microcode is ~440B words, but could be made
smaller by de-implementing some of the opcodes, so that they always trap to
software.
The Dandelion apparently traps ESC 20B-37B through SD[137B] with the
alpha byte as trap parameter, this is the (old) Mesa 6 FP trap mechanism as
implemented by Altos, and D-machines emulating Altos.
A minimal amount of space would be used by having all of ESC 20B-37B
trapping as per Levin's memo and none of the FP instructions handled by
microcode.
2) Modify the software. It is always possible to produce machine dependent
versions of RealImpl.bcd (or a bigger version that looks to see what kind of
machine it is), that will handle whatever trap conventions are being used.
I suppose it is even possible to use SD[130]-SD[137] together with the /-f
compiler switch, (if it still works...), but that would require a different version of
the Defs file because the defs file (Real) had some MACHINE CODE inlines in it
that would have to change.
-Larry
*start*
00849 00024 US
Date: 11 May 1981 12:35 pm PDT (Monday)
From: Stewart.PA
Subject: Re: Real Mesa
In-reply-to: Your message of 11 May 1981 12:19 pm PDT (Monday)
To: SMiller.ES
cc: Stewart
Yes. Everything is wonderful.
Read [Ivy]<Cedarlib>Real>Doc>MesaFloat60.press
Trig functions are inside RealFns.bcd, which is implemented, along with the
REALs themselves, by RealImpl.bcd. It is all Mesa 6.
The way to check your proms is to run Runmesa/v. If you get version 41, you
are OK. If you get version 39 (XMesa5), you lose. The REAL microcode goes in
the Ram, but the ROMs you have must be correct in order to transfer control
over there.
The debugger will print out REALs, but you cannot type one in: x ← 5.6
doesn't work.
John Warnock (Warnock.PA) has rotation software as part of CedarGraphics, you
might give him a shout.
-Larry
*start*
00891 00024 US
Date: 22 MAY 1981 1214-PDT
From: FIALA
Subject: Re: Floating Point
To: Karlton, Stewart
cc: FIALA
In response to the message sent 21-May-81 11:16:37 PDT (Thursday) from Karlton.PA
Floating point microcode exists for Dolphins running Cedar, a variant of
Rubicon Pilot. It would be a trivial matter to make this microcode available
to ordinary Rubicon Pilot, but there is insufficient microstore available for
using it in combination with all the things currently supported.
It might be desirable to either replace or overlay some of the existing Pilot
io drivers on Dolphins, so that space would become available for floating point
and other additions. At the moment, good candidates for overlay/replacement
are as follows:
1) Overlay the 10 mb and 3 mb ethernet drivers;
2) Overlay the RS232 and MIOC drivers;
3) Overlay the IFDC and RDC drivers;
-------
*start*
00671 00024 US
Date: 22 May 1981 1:02 pm PDT (Friday)
From: Neely.PA
Subject: Re: Floating Point
In-reply-to: FIALA's message of 21-May-81 11:16:37 PDT (Thursday)
To: FIALA
cc: Karlton, Stewart, Johnsson, Sandman, Frandeen, Neely
Ed,
I assume that "3) Overlay the IFDC and RDC drivers" means swapping the IFDC
and RDC microcode. This is not feasible because the floppy is not an alternate
system disk. It's for user file I/O on a system that is using an RDC as a system
disk. In addition to performance considerations, if the RDC ucode was overlaid by
the floppy ucode, there would be no way to get the RDC ucode back in.
Did you mean something else?
ev.
*start*
02006 00024 US
Date: 22 May 1981 1:17 pm PDT (Friday)
From: Neely.PA
Subject: Overlaying communications microcode
To: Danielson
cc: Karlton, Stewart, Fiala, Johnsson, Sandman, Frandeen, Neely
Bill,
The forwarded message below sets the context for these questions.
Currently -
1. When does communications microcode get put into microstore?
2. Is there selective loading based on subsets of communications hardware?
3. If there is no communiation hardware on a system, does the microcode
still get loaded?
4. Do many D0s have communication hardware?
5. What about TOR D0s?
Possibilities -
6. Are there fairly straight forward things that could be done to allow other
uses of the D0 control store currently allocated to communications.
ev.
---------------------------
Date: 22-May-81 12:17:50 PDT (Friday)
From: Karlton.PA
Subject: FYI: re: microcode for Dolphins
To: Johnsson, Sandman, Frandeen, Neely
I though you would be interested in this.
------------------------------
Date: 22 MAY 1981 1214-PDT
From: FIALA
Subject: Re: Floating Point
To: Karlton, Stewart
cc: FIALA
In response to the message sent 21-May-81 11:16:37 PDT (Thursday) from
Karlton.PA
Floating point microcode exists for Dolphins running Cedar, a variant of
Rubicon Pilot. It would be a trivial matter to make this microcode available
to ordinary Rubicon Pilot, but there is insufficient microstore available for
using it in combination with all the things currently supported.
It might be desirable to either replace or overlay some of the existing Pilot
io drivers on Dolphins, so that space would become available for floating point
and other additions. At the moment, good candidates for overlay/replacement
are as follows:
1) Overlay the 10 mb and 3 mb ethernet drivers;
2) Overlay the RS232 and MIOC drivers;
3) Overlay the IFDC and RDC drivers;
------
----------------------------------------------------------------
------------------------------------------------------------
*start*
00849 00024 US
Date: 22 MAY 1981 1348-PDT
From: STEWART
Subject: Re: Overlaying communications microcode
To: Neely, Danielson
cc: Karlton, Fiala, Johnsson, Sandman, Frandeen, STEWART
In response to the message sent 22 May 1981 1:17 pm PDT (Friday) from Neely.PA
Remember in all this that the minimum required microcode to handle
floating point is very small. All it need do is trap according
to the Cedar trap convention ([ivy]<cedarlib>trap>81csln-0004.press).
The software part of the FP package will then all work. If additional
control store is available, all that will happen is that FP will run faster.
-Larry
(It seems like all this talk of swapping microcode is making too much
out of the initial problem of making FP work in PreCascade.
Presumably not too many operations are done, so why worry about the speed?)
-------
*start*
01924 00024 US
Date: 22 May 1981 2:14 pm PDT (Friday)
From: Danielson.PA
Subject: Re: Overlaying communications microcode
In-reply-to: Neely's message of 22 May 1981 1:17 pm PDT (Friday)
To: Neely
cc: Danielson, Karlton, Stewart, Fiala, Johnsson, Sandman, Frandeen, Schwartz
Here are the answer to your questions: (My comment refer to RS232C microcode
rather any of the Ethernet stuff)
[1]. When does communications microcode get put into microstore?] Most of the
RS232C microcode is loaded when the client creates the RS232C.Channel although
there is a stub that is loaded at boot time.
[2. Is there selective loading based on subsets of communications hardware?]
Yes, by the Channel code. If no RS232C hardware exists, the channel Create call
won't get far enough to load the RS232C microcode variant before it realizes no
RS232C hardware exists and tells the client.
[3. If there is no communiation hardware on a system, does the microcode
still get loaded?]. Only the stub gets loaded. See 1. and 2. answers.
[4. Do many D0s have communication hardware?]. There were around 15-25
MIOC boards built, I think.
[5. What about TOR D0s?]. Tor has its own RS232C hardware, etc. It is part
of the SCB board and works in a similar manner to the Dandelion IOP... that is, it
has an 8080 processor on the board which does most of the low level RS232 work.
[6. Are there fairly straight forward things that could be done to allow other
uses of the D0 control store currently allocated to communications.] Yes, there
are. One could probably change the microcode/head so the stub was not
needed. Then the microcode page for the RS232C could be used for other
things. However, it is important to make sure that this new microcode
is indeed used only for optional things. We have been screwed before where
RS232C overlay space was used for optional things, which later became
mandatory.
BRD
*start*
00615 00024 US
Date: 29 May 1981 5:36 pm PDT (Friday)
From: Stewart.PA
Subject: AltoI REALs
To: Dobkin,Brotz
cc: Stewart
See [Ivy]<Cedarlib>Real>AltoI>AltoIReal.press
Basically, the defs files are the same as the microcode world, but there is a
different RealImpl.bcd.
The interface RealOps is the one that works (procedure calls).
This version actually works anywhere, it just isn't as capable as the microcode
version of RealImpl. I was going to use SegmentDefs.GetMemoryConfig, but that
would require importing SegmentDefs and I didn't want to force people to change
their outer configs.
-Larry
*start*
00779 00024 US
Date: 1 June 1981 6:14 pm PDT (Monday)
From: Fiala.PA
Subject: Dolphin Floating Point
To: Stewart.PA,Warnock.PA
cc: Fiala
I have prepared a new version of the Alto-compatible Dolphin microcode which
is on [Ivy]<D0>Test>InitialAlto.Eb. I would appreciate if you could test it for me
and report any problems (also report lack of problems if you test it). Its main
virtue is that it is about 60% faster than the last released version.
The microcode has already been tested on Larry Stewart's IEEERandomTest for
awhile without any problems, so the bugs, if any, are likely to be in dealing
with zeroes and limit values of various types.
The same floating point microcode will be installed in the Cedar microcode when
it is certified on the Alto system.
*start*
00681 00024 US
Date: 24 June 1981 5:57 pm PDT (Wednesday)
From: Barth.PA
Subject: Floating Point Performance
To: Stewart
cc: Barth
Do you know what sort of performance the floating point microcode on the
Dolphin and the Dorado deliver in the form of n secs per floating point add,
multiply or divide? Is there anyone that you know of that is interested in
and/or is actually doing something about improving that performance? Rumor
has it that the floating point board that was underway for Dolphins has been
dropped because the net increase in throughput would be so small. Could you
tell me anything about that?
I'd appreciate whatever info you can give me.
Rick