MIPS Rating of 3B2/400??

[Stephen J. Friedl]

In article <3109 at cbnewsc.ATT.COM>, roynh at cbnewsc.ATT.COM (roy.n.harkness) writes:
> How much does the MAU effect the performance of the above machines?

The MAU is of limited use in many cases.  The best code is
generated by the CPLU4.2 compiler in -Kmau mode.  In this mode,
the compiler generates direct coprocessor calls, and it really
does run very, very fast.  However, it requires that the MAU be
present, so if you are compiling code that is to run all around
you really can't use it.  The -Kfpe mode generates code that
checks for a MAU and uses it or not accordingly.

The bummer is that this involves a function call for almost every
operation (probably all but loads and stores) and this is pretty
slow.  Note that in the absense of a MAU the function call
overhead is *much* less than the miserably slow FP interpreter
found in the older compilers.

In addition, many application packages are not compiled to use
even the conditional MAU code.  For instance, it was only
recently that Informix included this code, and it's my belief
that RM/Cobol still has the old FP interpreters.

Note that the FP interpreter is really an amazing piece of code.
It works in concert with the compiler to use the holes in the
opcode map of the WE32100 processor for each floating point
"instruction".  When one of these opcodes is used, the CPU takes
a trap, and this is routed to the user process because the FP
startup routines use the S3BIOP undocumented fast illegal opcode
handler (see <sys/sys3b.h> for a little info on this).

Given the address of the faulting instruction, the handler checks
to see if it is in fact a floating point instruction.  If so, it
enters an interpreter for the rest of the instruction, including
what seems to be all the addressing modes.  It is my feeling
after doing lots of testing that it is the instruction decode (if
you will) that takes most of the time, not the fp emulation.

It is also my feeling that this was a lot of energy targeted in
the wrong direction.  At the very least, supporting all those
addressing modes really cuts into the efficiency of the package,
and I really doubt that the compiler really can use them.

**** personal opinion: I do not have much experience with this
kind of thing, but I can see a lot of benefit by having the FP
interpreter located in the kernel.  The fptrap.o routine (located
in libc.a) is a little larger than 5kb of code, and this could
all be saved if it was not located in every program.  In addition
-- and more importantly -- it strikes me that by organizing it
this way, they could have built it such that inserting a MAU
would (say) cause a different "interpreter" to be loaded at boot
time.  Now old code can use the MAU.

They didn't do this for what I must imagine to be good reasons,
and we are stuck with what we have.  Oh well.

     Steve

Disclaimer: I very specifically do not speak for V-Systems, they
don't even know what I am talking about, and they get nervous
when I post.

-- 
Stephen J. Friedl / V-Systems, Inc.  /  Santa Ana, CA  / +1 714 545 6442 
3B2-kind-of-guy   / {attmail uunet}!vsi!{bang!}friedl  /  friedl at vsi.com

"But officer, I *was* carpooling; I had the Lord with me!" - me