Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!rutgers!princeton!udel!burdvax!sdcrdcf!ism780c!darryl
From: darryl@ism780c.UUCP (Darryl Richman)
Newsgroups: comp.arch
Subject: Re: The 360 was a design landmark (long)
Message-ID: <7171@ism780c.UUCP>
Date: Wed, 26-Aug-87 14:14:29 EDT
Article-I.D.: ism780c.7171
Posted: Wed Aug 26 14:14:29 1987
Date-Received: Sat, 29-Aug-87 03:31:30 EDT
References: <855@tjalk.cs.vu.nl> <2683@hoptoad.uucp> <916@haddock.ISC.COM> <1193@k.gp.cs.cmu.edu> <570@l.cc.purdue.edu>
Reply-To: darryl@ism780c.UUCP (Darryl Richman)
Organization: Interactive Systems Corp., Santa Monica CA
Lines: 19

In article <570@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes:
>A big flaw in the 360-style architecture, which is present in all of its
>successors of which I am aware, is that there is no communication between
>the integer and floating registers.  I know of no other machines on which
>it is as difficult and time consuming to convert between integer and
>floating point.

Look at the 80*86 machines and their 80*87 coprocessors.  In most Unix
implementations, the coprocessor's rounding mode is by default set to
round to nearest.  When you want an integer from an fp, you must save the
current mode, set to truncate, store the integer into memory, and reset
the rounding modes.  You must then load the cpu register with the integer.
Branch on fp condition is similarly hampered, although there is an
instruction that will directly load the ax register from the coprocessor's
status word.

But this stuff is only a problem if you're doing serious scientific stuff.
I was under the impression that most 370s did mundane payroll/bookkeeping
stuff.  For those tasks, bcd string performance would seem to be paramount.