![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Paul Fuller <pgf### [at] optusnet com au> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Warp wrote:
> Paul Fuller <pgf### [at] optusnet com au> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Invisible <voi### [at] dev null> wrote:
> Warp wrote:
> > Paul Fuller <pgf### [at] optusnet com au> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
>>>> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |