 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
http://www.theregister.co.uk/2010/07/23/ibm_z196_mainframe_processor/
(Big-ass mainframe CPUs)
I didn't know people were still putting decimal math circuits into CPUs.
--
Darren New, San Diego CA, USA (PST)
C# - a language whose greatest drawback
is that its best implementation comes
from a company that doesn't hate Microsoft.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 27/07/2010 8:29 AM, Darren New wrote:
> http://www.theregister.co.uk/2010/07/23/ibm_z196_mainframe_processor/
>
> (Big-ass mainframe CPUs)
>
> I didn't know people were still putting decimal math circuits into CPUs.
>
Used to program the ancestors of this in assembler. S370 and S390
instruction sets. The 'packed decimal' format was really perfect for
banks and similar. Hardware memory to memory add, subtract, multiply
large precision numerics with exact precision. 'ZAP' (Zero and Add
Packed) was one of the most common instructions in almost any assembler
program. And the main numeric data type in IBM COBOL translated to
these underlying instructions.
There is a fair chance that your money is still held and processed in
this format today.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Paul Fuller <pgf### [at] optusnet comau> wrote:
> The 'packed decimal' format was really perfect for banks and similar.
I really can't understand why. The user doesn't need to know how
integers are represented internally, so why would he care?
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Paul Fuller <pgf### [at] optusnetcomau> wrote:
>> The 'packed decimal' format was really perfect for banks and similar.
>
> I really can't understand why. The user doesn't need to know how
> integers are represented internally, so why would he care?
You know that 1/10 can't be exactly represented in binary, but can be
represented exactly in decimal, right?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> You know that 1/10 can't be exactly represented in binary, but can be
> represented exactly in decimal, right?
Why not just store the total pence/cents in an int?
Anyway, I thought banks worked internally to fractions of a pence/cent and
only rounded for statements etc?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible <voi### [at] devnull> wrote:
> Warp wrote:
> > Paul Fuller <pgf### [at] optusnetcomau> wrote:
> >> The 'packed decimal' format was really perfect for banks and similar.
> >
> > I really can't understand why. The user doesn't need to know how
> > integers are represented internally, so why would he care?
> You know that 1/10 can't be exactly represented in binary, but can be
> represented exactly in decimal, right?
And 1/3 cannot be represented exactly in *any* base being currently
used in any computer system. So what?
Besides, 1/10 isn't an integer, so what would BCD integer registers
help that? Any solution you devise will also work with plain binary
registers as well.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>>>> The 'packed decimal' format was really perfect for banks and similar.
>>> I really can't understand why. The user doesn't need to know how
>>> integers are represented internally, so why would he care?
>
>> You know that 1/10 can't be exactly represented in binary, but can be
>> represented exactly in decimal, right?
>
> And 1/3 cannot be represented exactly in *any* base being currently
> used in any computer system. So what?
Financial transactions don't involve units of 1/3. They *do* frequently
involve 1/10, however. (And 1/100, and smaller.)
> Besides, 1/10 isn't an integer, so what would BCD integer registers
> help that? Any solution you devise will also work with plain binary
> registers as well.
Oh, well, if it's only *integer* arithmetic then yeah, I have no idea
what the advantage would be.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
scott wrote:
> Why not just store the total pence/cents in an int?
Because when you're talking about thousands of dollars as the smallest
increment, that wastes space. Because when you add dollars to pennies to
fractional pennies, you need to do the scaling anyway. Because when you
print out the number, you wind up doing a whole bunch of divide-by-10's
anyway, and lots and lots of financial processing involves printing out numbers.
And usually (at least in modern standards) these numbers go up to something
like 38 digits. So why would an "int" be better than packed decimal in terms
of processing speed?
Anyway, yes, that's basically what this is doing, except with appropriate
scaling. Your question is like asking "why not just store the floating
point number without the exponent?"
The oldest mainframe I worked on has a "scientific" unit (the floating point
coprocessor) and the "business" unit (the decimal math coprocessor). The
business unit had things like scatter/gather memory moves, packed decimal,
and the equivalent of BASIC's "print using" (which I think COBOL called an
Edit field).
> Anyway, I thought banks worked internally to fractions of a pence/cent
> and only rounded for statements etc?
Depends what you're doing. Interest is probably in fractions of a cent.
Statements are to the penny. Taxes are to the dollar. Etc.
--
Darren New, San Diego CA, USA (PST)
C# - a language whose greatest drawback
is that its best implementation comes
from a company that doesn't hate Microsoft.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Besides, 1/10 isn't an integer, so what would BCD integer registers
> help that?
It's a scaled integer. Part of the decimal math mechanism includes aligning
the decimal points.
> Any solution you devise will also work with plain binary
> registers as well.
Yes, and so would floating point, if you made the registers big enough.
And, like floating point, it would be quite the PITA to translate scaled
integer numbers into something you could print efficiently, compared to
using BCD.
COBOL has "display" types (packed BCD) and "computation" types (two's
complement integers), depending on what you want to do with them.
Why would plain integers be *better* than packed BCD for this sort of
application? You're going to need specialized instructions if you want to
run fast in either situation.
--
Darren New, San Diego CA, USA (PST)
C# - a language whose greatest drawback
is that its best implementation comes
from a company that doesn't hate Microsoft.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Because when you're talking about thousands of dollars as the smallest
> increment, that wastes space.
Oh I see, so it's like a base-10 float?
> And usually (at least in modern standards) these numbers go up to
> something like 38 digits. So why would an "int" be better than packed
> decimal in terms of processing speed?
It would avoid the need for custom hardware, but obviously it works out
faster per $ to get the non-standard CPUs if that's what they actually use.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
scott wrote:
>> Because when you're talking about thousands of dollars as the smallest
>> increment, that wastes space.
>
> Oh I see, so it's like a base-10 float?
Not exactly. It's packed BCD. Two decimal digits per byte. The exponent is
declared at the source code level but isn't stored in memory. It's more like
"take that number that has two decimal places and add it to this number here
that has four decimal places."
>> And usually (at least in modern standards) these numbers go up to
>> something like 38 digits. So why would an "int" be better than packed
>> decimal in terms of processing speed?
>
> It would avoid the need for custom hardware, but obviously it works out
> faster per $ to get the non-standard CPUs if that's what they actually use.
They're really only non-standard compared to x86. Most of the mainframe CPUs
have had decimal math for years. When you're talking about 38-digit binary
numbers with assorted number of digits after the decimal points, trying to
do all that in pure machine-register-size integer operations is slow. You
don't want slow.
Or, to phrase it another way... You need to print 30 million phone bills
with itemized phone calls today. How much time are you going to spend
dividing by ten in order to be able to print the cost of each call, vs the
storage space you waste by storing the call times and costs as BCD instead
of binary?
--
Darren New, San Diego CA, USA (PST)
C# - a language whose greatest drawback
is that its best implementation comes
from a company that doesn't hate Microsoft.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> They're really only non-standard compared to x86. Most of the mainframe
> CPUs have had decimal math for years.
Oh, as did the 6502 in its own way, for that matter. As does the 8086.
--
Darren New, San Diego CA, USA (PST)
C# - a language whose greatest drawback
is that its best implementation comes
from a company that doesn't hate Microsoft.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> And, like floating point, it would be quite the PITA to translate scaled
> integer numbers into something you could print efficiently, compared to
> using BCD.
This CPU broke the 5 GHz barrier. I don't think printing efficiency is
an issue.
> Why would plain integers be *better* than packed BCD for this sort of
> application?
2's complement binary registers require simpler circuitry to be operated
with, compared to BCD registers, hence making the CPU design simpler (and
hence less expensive).
The value range of BCD registers is smaller than that of 2's complement
binary registers.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> 2's complement binary registers require simpler circuitry to be operated
> with, compared to BCD registers, hence making the CPU design simpler (and
> hence less expensive).
Until it's time to scale the decimal place.
Add a 30-digit number with two decimal places to a 30-digit number with 4
decimal places in binary.
Now do the same in BCD.
But, surely, Intel's mainframe CPU division doesn't know anything about
efficiency of instructions and data.
--
Darren New, San Diego CA, USA (PST)
C# - a language whose greatest drawback
is that its best implementation comes
from a company that doesn't hate Microsoft.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> They're really only non-standard compared to x86. Most of the
>> mainframe CPUs have had decimal math for years.
>
> Oh, as did the 6502 in its own way, for that matter. As does the 8086.
The B status flag puts the 6502 into BCD mode. God only knows what that
actually means in practice; I never tried it.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> Warp wrote:
> > 2's complement binary registers require simpler circuitry to be operated
> > with, compared to BCD registers, hence making the CPU design simpler (and
> > hence less expensive).
>
> Until it's time to scale the decimal place.
>
> Add a 30-digit number with two decimal places to a 30-digit number with 4
> decimal places in binary.
>
> Now do the same in BCD.
>
> But, surely, Intel's mainframe CPU division doesn't know anything about
> efficiency of instructions and data.
>
> --
> Darren New, San Diego CA, USA (PST)
> C# - a language whose greatest drawback
> is that its best implementation comes
> from a company that doesn't hate Microsoft.
Another reason for retaining hardware decimal instructions would be for backward
compatibility. The company I work for has thousands of cobol programs that use
decimal instructions. It would be impossible to upgrade to the new processor
without that feature. IBM has to insure the upgrade path for it's customers is
as painless as possible.
Isaac.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 7/27/2010 8:01 AM, Darren New wrote:
> scott wrote:
>> Why not just store the total pence/cents in an int?
>
> Because when you're talking about thousands of dollars as the smallest
> increment, that wastes space. Because when you add dollars to pennies to
> fractional pennies, you need to do the scaling anyway. Because when you
> print out the number, you wind up doing a whole bunch of divide-by-10's
> anyway, and lots and lots of financial processing involves printing out
> numbers.
>
The real reason is, to some extent, that, at one time, they "did" only
store the rounded values, then someone figured out how to "add up" those
extra missing bits, and dump them into their own bank account, so now
financial software, unless the coder is a complete idiot, **never**
throws away enough of the data to allow someone to make millions, via
that trick, from rounding errors. ;)
--
void main () {
If Schrödingers_cat is alive or version > 98 {
if version = "Vista" {
call slow_by_half();
call DRM_everything();
}
call functional_code();
}
else
call crash_windows();
}
<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models,
3D Content, and 3D Software at DAZ3D!</A>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
scott a écrit :
>> Because when you're talking about thousands of dollars as the smallest
>> increment, that wastes space.
>
> Oh I see, so it's like a base-10 float?
>
>> And usually (at least in modern standards) these numbers go up to
>> something like 38 digits. So why would an "int" be better than packed
>> decimal in terms of processing speed?
>
> It would avoid the need for custom hardware, but obviously it works out
> faster per $ to get the non-standard CPUs if that's what they actually use.
>
>
What do you mean non-standard? Every single bank, every single
insurance company, every single government tax agency/ministry/dept.,
most airline, universities, and large companies with more than a 1000
employees worldwide has one or more IBM mainframes.
I'd call that "standard"!
Tin foil hat dept: And they all have a phone line to call back home in
case of problems. The more paranoid think Big Blue can also use those
phone lines for its own nefarious purposes.
--
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/* flabreque */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/* @ */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/* gmail.com */}camera{orthographic location<6,1.25,-6>look_at a }
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> What do you mean non-standard? Every single bank, every single insurance
> company, every single government tax agency/ministry/dept., most airline,
> universities, and large companies with more than a 1000 employees
> worldwide has one or more IBM mainframes.
And they also have 1000 or more x86 machines each :-) That's what I meant,
that way more x86/x64 CPUs are manufactured, so obviously they are cheaper.
I just wondered if you worked it out on a performance per $ metric (eg how
many $ equipment do you need to print 30 million bills in 24 hours), would
using the IBM mainframe be cheaper than using a room full of x86 machines?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
scott a écrit :
>> What do you mean non-standard? Every single bank, every single
>> insurance company, every single government tax agency/ministry/dept.,
>> most airline, universities, and large companies with more than a 1000
>> employees worldwide has one or more IBM mainframes.
>
> And they also have 1000 or more x86 machines each :-)
That's a recent development. Most banks, up to 10 years ago, had 3278
terminals hooked up to 3174 cluster controllers in their branches, not
PCs. The loan officer probably had a portable (which she used to access
the host-based financial applications anyway, plus a little Excel and
Word here and there), but that's it.
> That's what I
> meant, that way more x86/x64 CPUs are manufactured, so obviously they
> are cheaper. I just wondered if you worked it out on a performance per $
> metric (eg how many $ equipment do you need to print 30 million bills in
> 24 hours), would using the IBM mainframe be cheaper than using a room
> full of x86 machines?
>
>
Mainframes do way more than overnight batch jobs. A typical mainframe
environment will allow for 99.999% uptime. Handle millions of
transactions per day with response times below 5 secs. A similar
environment made out of x86 or x64 hardware, with the required
redundancy, clustering and load-balancers required to achieve five-9s
uptime (That's less than 25 secs of downtime PER MONTH!) as well has
handle the number of transactions at the same speed will probably be as
expensive, if not more.
That's the main reason banks and airlines (the two industries I'm
familiar with) don't change their systems.
Anyway, by "standard" I didn't mean "Most. Popular. Ever.", I meant that
for its intended use it IS still the de facto standard.
--
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/* flabreque */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/* @ */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/* gmail.com */}camera{orthographic location<6,1.25,-6>look_at a }
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Mainframes do way more than overnight batch jobs. A typical mainframe
> environment will allow for 99.999% uptime. Handle millions of
> transactions per day with response times below 5 secs. A similar
> environment made out of x86 or x64 hardware, with the required redundancy,
> clustering and load-balancers required to achieve five-9s uptime (That's
> less than 25 secs of downtime PER MONTH!) as well has handle the number of
> transactions at the same speed will probably be as expensive, if not more.
Oh ok, that's all I wondered. I guess they have different requirements than
eg Google that decided to take the lots-of-cheap-x86s path.
> That's the main reason banks and airlines (the two industries I'm familiar
> with) don't change their systems.
Yeh, and if there was some advantage to x86 sytems, it would probably have
to be quite a large gap to make it worthwhile changing over (which surely
won't be cheap).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
scott wrote:
>> What do you mean non-standard? Every single bank, every single
>> insurance company, every single government tax agency/ministry/dept.,
>> most airline, universities, and large companies with more than a 1000
>> employees worldwide has one or more IBM mainframes.
>
> And they also have 1000 or more x86 machines each :-)
Almost all of which do nothing except run a web browser open to the back end
site running on the mainframe.
--
Darren New, San Diego CA, USA (PST)
C# - a language whose greatest drawback
is that its best implementation comes
from a company that doesn't hate Microsoft.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
scott wrote:
> Oh ok, that's all I wondered. I guess they have different requirements
> than eg Google that decided to take the lots-of-cheap-x86s path.
Yes. They have ACID. They're actually charging money, and allocating
resources like airplane seats, in ways that you actually need to coordinate
different requests. Google doesn't, but google also serves an audience in a
way that physically putting the machines closer to the audience helps business.
--
Darren New, San Diego CA, USA (PST)
C# - a language whose greatest drawback
is that its best implementation comes
from a company that doesn't hate Microsoft.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
