Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/12/84; site desint.UUCP
Path: utzoo!watmath!clyde!cbosgd!cbdkc1!desoto!packard!hoxna!houxm!vax135!cornell!uw-beaver!tektronix!hplabs!sdcrdcf!trwrb!desint!geoff
From: geoff@desint.UUCP (Geoff Kuenning)
Newsgroups: net.micro.68k,net.micro.16k
Subject: Re: Re: PDP11s vs the micros
Message-ID: <124@desint.UUCP>
Date: Sat, 24-Aug-85 16:23:02 EDT
Article-I.D.: desint.124
Posted: Sat Aug 24 16:23:02 1985
Date-Received: Tue, 27-Aug-85 06:14:16 EDT
References: <2422@sun.uucp> <5883@utzoo.UUCP> <5890@utzoo.UUCP>
Reply-To: geoff@desint.UUCP (Geoff Kuenning)
Organization: SAH Consulting, Manhattan Beach, CA
Lines: 55
Xref: watmath net.micro.68k:1082 net.micro.16k:375

In article <5890@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes:

>The following two Dave Trissel quotes are from the same message:
>
>> The stack save equates to about the same overhead as executing 12
>> instructions.
>
>In other words, all you need is 12 contiguous non-memory-referencing
>instructions and the 68020's stack puke will actually break even!  This
>is stretching it a bit, since on the pdp11 typically every third or fourth
>instruction did some sort of memory reference; I doubt that the 68000 family
>does much better.  Speaking of the 68000 *family*, note that a 68010 gets
>the full performance hit every time since it doesn't pipeline much.

Do I detect just a tiny rabid note here?  Henry, I think Dave's point was
not that you only have to do 12 non-memory-referencing instructions to
break even.  Rather, his point was that you only have to eliminate 12
instructions (of any "average" type) from the total code stream executed
in response to a bus error to break even.  Or, alternatively, that you would
get the same performance hit from adding 12 instructions to that stream,
which can easily be the result of a single bug fix in trap.c.  There is
little point in getting excited about a few microseconds in bus-error
processing unless (a) you are getting LOTS of bus errors per second, and
(b) those microseconds add a SIGNIFICANT percentage to the bus-error
processing time.  (a) is generally true in virtual-machine OS's;  (b)
is not true in any operating system I've ever heard of.

In any case, Henry, why bring up the red herring of the 68010?  This was
a discussion of the 020 until now.  Or are you just in a flaming-at-Motorola
mood?

>On the other hand, I'm glad to hear that Motorola did have the sense to
>put a floating-point-used flag in the FPU, so at least you don't have to
>shovel 300 bytes of state around unnecessarily.

Hmm, maybe you *are* in a mood.  In article <5883@utzoo.UUCP> you complain
that some friends are all upset about the 300 bytes of state.  Now we
find out that said friends maybe didn't even know about the f.p.-used
flag?

>An interesting possibility would be to have the hardware support *both* an
>FPU-used flag *and* a trap-on-first-FPU-use bit.  It would not seem too
>difficult to set up some code in the kernel that switches between the
>two strategies as a function of the number of FPU context switches that
>have occurred lately.

Henry's got a point here, Dave.  Even if you didn't want to do it dynamically,
the OS designer would still have the option of picking trap-on-first-use,
which is still advantageous if you are certain that most of the time there
will only be one f.p. user.  Any chance of getting this idea into the
next rev?
-- 

	Geoff Kuenning
	...!ihnp4!trwrb!desint!geoff