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] 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?

-- 
                                                          - 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