Re: IBM System z9
- From: "Quadibloc" <jsavard@xxxxxxxxx>
- Date: 24 Mar 2007 02:58:58 -0700
Andrew Reilly wrote:
What I (still) don't get, though, is why this has happened backwards. Why
add hardware features to (presumably) speed up operations for which there
is no obvious performance demand?
If one is going to add new instructions to a machine at *all*, enough
hardware has to be added to at least make the instructions passably
useful. *Particularly* when the machine is a mainframe, whose power is
rented, not sold.
Why introduce a new arithmetic model at
the hardware level before there is any standardised way to even refer to
it from the common higher level languages?
Doubtless IBM will provide new statements or other facilities to the
z9 COBOL compilers to make use of this new type, so it will be
accessible.
There's been a lot of talk about helping out the users of spreadsheets,
but that's not going to happen automatically, just because the processors
grow a new arithmetic model: someone has to re-write the spreadsheets. Is
that all lined-up? If it was really important, why hasn't someone scooped
the pool with a spread*** that used decimal arithmetic already? Was the
software decimal arithmetic even a performance issue? Which spread***?
Does the z9 even have a spread***? My phone runs a spread*** and
doesn't even have a binary floating point unit, so what's another layer of
libraries...
Microsoft has apparently said it finds the 128-bit decimal floating-
point format in this proposed standard applicable enough that it plans
to use it with its new versions of Excel once it starts being
available in hardware - if I understand another post in this thread
correctly.
Microsoft and Intel together would presumably welcome any excuse to
get people running out and buying new computers.
As to the *other* part of that question, Mike Cowlishaw's site notes
that an HP calculator implemented the preceding IEEE 854 decimal
arithmetic standard. Other examples of software DFP arithmetic are
also listed there, so there isn't a *complete* and utter absence of
DFP implementations.
Of course, some examples - like the floating-point of John von
Neumann's JOSS interpreter - _do_ seem to show that humanizing
arithmetic by going decimal was tried, weighed, and found wanting.
So why try again?
IBM is a big, large company that sells computers. Long, long ago it
made computers that used decimal arithmetic internally because that's
what customers in the business and commercial field wanted. Even the
8080 and 6502 had a limited degree of support for decimal arithmetic,
because it occasionally made sense to take numbers in text form from
storage, do a very limited amount of computation, and return the
results to storage. So decimal fixed-point has been around for a
while.
Floating-point exists to relieve programmers of the responsibility of
keeping track of where the radix point should go in calculations.
Decimal floating point, therefore, offers to extend this convenience -
particularly important since most languages *do* lack an easy way to
specify applying scaling to fixed-point quantities, just assuming that
they are integers - to programmers using decimal arithmetic.
Side question: who's lined up to write all of the data and protocol
converters, to interoperate with all of the
systems/programs/libraries/existing files that currently use binary
floating point?
Most things that use binary floating point will continue to do so, and
won't need to interoperate with decimal floating point. Both types of
floating-point will be able to convert their input and output from
text form, and that would be all the interoperation needed in most
cases.
Why "if you build it, they will come", this time, rather than the accepted
"I can make this important app 20% faster/cheaper/better by adding this
particular new instruction"?
Here, it's partly "I can open up *new* applications for computers, and
sell more of them, with these new instructions"; but the other half is
that instead of the emphasis being on _performance_ per se, it's on
making existing applications *easier to use* by making them more user-
friendly and intuitive.
Nothing wrong with that - given that we're dealing with a changed
computer marketplace. Yes, this kind of instruction would be a very
*low* priority for, say, the successor to the SX-8, but it has uses to
other people.
John Savard
.
- References:
- IBM System z9
- From: Natarajan Krishnaswami
- Re: IBM System z9
- From: Quadibloc
- Re: IBM System z9
- From: Del Cecchi
- Re: IBM System z9
- From: John L
- Re: IBM System z9
- From: Stephen Fuld
- Re: IBM System z9
- From: Quadibloc
- Re: IBM System z9
- From: Quadibloc
- Re: IBM System z9
- From: Nick Maclaren
- Re: IBM System z9
- From: Quadibloc
- Re: IBM System z9
- From: Nick Maclaren
- Re: IBM System z9
- From: Nick Maclaren
- Re: IBM System z9
- From: Mike Cowlishaw
- Re: IBM System z9
- From: Nick Maclaren
- Re: IBM System z9
- From: Mike Cowlishaw
- Re: IBM System z9
- From: Andrew Reilly
- IBM System z9
- Prev by Date: Re: IBM System z9
- Next by Date: Re: IBM System z9
- Previous by thread: Re: IBM System z9
- Next by thread: Re: IBM System z9
- Index(es):
Loading