why still use C?

[CBFalconer]

Re: Decimal Floating Point (was Re: why still use C?)

glen herrmannsfeldt wrote:[color=blue]
> CBFalconer wrote:[color=green]
> > glen herrmannsfeldt wrote:[/color]
>
> (snip of base 1000 representation of decimal floating point)
>[color=green][color=darkred]
> >>The normalization is done in uncompressed (BCD) form, and then
> >>they are converted to the base 1000 form for storage.[/color][/color]
>[color=green]
> > If you have ever designed a floating point package you will
> > realize that normalization takes up the majority of the time. It
> > needs to be simple, not a major base conversion.[/color]
>[color=green]
> > Any reasonable form of decimal FP will be based on some flavor of
> > bcd, possibly 8421, or excess 3, or 2*421, or even bi-quinary.[/color]
>
> I haven't actually checked, but rumors are that it only takes a
> few gates to convert between the base 1000 representation, and
> BCD. It can be done while loading into registers, or even
> as part of the ALU, itself.[/color]

If you show me (in detail) I will believe you. Not before.

--
Chuck F (cbfalconer@yah oo.com) (cbfalconer@wor ldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home .att.net> USE worldnet address!
--
comp.lang.c.mod erated - moderation address: clcm@plethora.n et

[Mike Cowlishaw]

Re: Decimal Floating Point (was Re: why still use C?)

> OK, so still between 49.8 and 53.1 equivalent bits for the mantissa,[color=blue]
> 11.3 bits for the exponent, and 1 for the sign, so 62.1 worst case
> and 65.4 best case, for 63.75 average case, or 99.6% efficient.
>
> This reminds me of all the work the authors of the original Fortran
> compiler did to generate as efficient object code as possible.
> They needed to convince people that Fortran could be used in place
> of assembly code, without a significant loss of efficiency.
>
> Personally, I would have been happy with ordinary BCD arithmetic,
> in floating point form. It seems to have worked well for calculator
> users for many years now.[/color]

There are a few constraints, though. For example, the ISO
COBOL 2002 standard specifies that intermediate calculations
be done using 32 decimal digits of precision. 32 digits of BCD
into a 128-bit register leaves very little room for a sign and
exponent.

Mike Cowlishaw
--
comp.lang.c.mod erated - moderation address: clcm@plethora.n et

[Mike Cowlishaw]

Re: Decimal Floating Point (was Re: why still use C?)

> (snip of base 1000 representation of decimal floating point)[color=blue]
>[color=green][color=darkred]
>>> The normalization is done in uncompressed (BCD) form, and then
>>> they are converted to the base 1000 form for storage.[/color][/color]
>[color=green]
>> If you have ever designed a floating point package you will
>> realize that normalization takes up the majority of the time. It
>> needs to be simple, not a major base conversion.[/color]
>[color=green]
>> Any reasonable form of decimal FP will be based on some flavor of
>> bcd, possibly 8421, or excess 3, or 2*421, or even bi-quinary.[/color]
>
> I haven't actually checked, but rumors are that it only takes a
> few gates to convert between the base 1000 representation, and
> BCD. It can be done while loading into registers, or even
> as part of the ALU, itself.[/color]

Correct. For details, see a summary at:

http://www2.hursley.ibm.com/decimal/DPDecimal.html

Mike Cowlishaw
--
comp.lang.c.mod erated - moderation address: clcm@plethora.n et

[Douglas A. Gwyn]

Re: why still use C?

"Kalle Olavi Niemitalo" <kon@iki.fi> wrote in message
news:87d6ahc03y .fsf@Astalo.kon .iki.fi...[color=blue]
> Type checks like this would be easier if the comma operator were
> allowed in constant expressions.[/color]

Yes; that's an aggravating restriction.
The main argument for it seems to be to diagnose
int a[20,30];
but with VLAs that has to be allowed anyway in many contexts,
so it seems pointless to keep the restriction.

[Douglas A. Gwyn]

Re: sizeof UB?, was Re: why still use C?

"Arthur J. O'Dwyer" <ajo@nospam.and rew.cmu.edu> wrote...[color=blue]
> and I'm curious as to what various compilers make of 'sizeof(1/0)',
> and whether it's valid C or not. [I think the answer should be
> sizeof(int), but I'm not sure it doesn't invoke UB.][/color]

There is no undefined behavior, because the / operator is not
executed (the argument of sizeof is not evaluated).

[Paul Eggert]

Re: why still use C?

At Mon, 22 Dec 2003 11:00:34 -0600, "Douglas A. Gwyn" <DAGwyn@null.ne t> writes:
[color=blue]
> "Kalle Olavi Niemitalo" <kon@iki.fi> wrote in message
> news:87d6ahc03y .fsf@Astalo.kon .iki.fi...[color=green]
>> Type checks like this would be easier if the comma operator were
>> allowed in constant expressions.[/color]
>
> Yes; that's an aggravating restriction.
> The main argument for it seems to be to diagnose
> int a[20,30];[/color]

A diagnostic for that declaration is required regardless of whether
commas are allowed in constant expressions. This is because a
direct-declarator (which is used to declare array types and their
bounds) must contain an assignment-expression, and
assignment-expressions must not contain a comma at the top level.
Seethe syntax in C99 section 6.7.5.

I think it's a good idea to have a diagnostic for that declaration, as
it's an understandably common error for C neophytes. But this issue
is independent of whether the comma operator should be allowed in
constant expressions.

[Christian Bau]

Re: Decimal Floating Point (was Re: why still use C?)

In article <clcm-20031221-0005@plethora.n et>,
CBFalconer <cbfalconer@yah oo.com> wrote:
[color=blue]
> glen herrmannsfeldt wrote:[color=green]
> > CBFalconer wrote:[color=darkred]
> > > glen herrmannsfeldt wrote:[/color]
> >
> > (snip of base 1000 representation of decimal floating point)
> >[color=darkred]
> > >>The normalization is done in uncompressed (BCD) form, and then
> > >>they are converted to the base 1000 form for storage.[/color]
> >[color=darkred]
> > > If you have ever designed a floating point package you will
> > > realize that normalization takes up the majority of the time. It
> > > needs to be simple, not a major base conversion.[/color]
> >[color=darkred]
> > > Any reasonable form of decimal FP will be based on some flavor of
> > > bcd, possibly 8421, or excess 3, or 2*421, or even bi-quinary.[/color]
> >
> > I haven't actually checked, but rumors are that it only takes a
> > few gates to convert between the base 1000 representation, and
> > BCD. It can be done while loading into registers, or even
> > as part of the ALU, itself.[/color]
>
> If you show me (in detail) I will believe you. Not before.[/color]

The format is described at

http://www2.hursley.ibm.com/decimal/DPDecimal.html

It definitely looks simple enough to be done with a few logic gates.
--
comp.lang.c.mod erated - moderation address: clcm@plethora.n et

[Mike Cowlishaw]

Re: Decimal Floating Point (was Re: why still use C?)

CBFalconer wrote:[color=blue][color=green]
>> I haven't actually checked, but rumors are that it only takes a
>> few gates to convert between the base 1000 representation, and
>> BCD. It can be done while loading into registers, or even
>> as part of the ALU, itself.[/color]
>
> If you show me (in detail) I will believe you. Not before.[/color]

See: http://www2.hursley.ibm.com/decimal/DPDecimal.html

There are only two gate delays needed for the conversion (or three if
inverted signals are not available).

Mike Cowlishaw.
--
comp.lang.c.mod erated - moderation address: clcm@plethora.n et

[CBFalconer]

Re: Decimal Floating Point (was Re: why still use C?)

Mike Cowlishaw wrote:[color=blue]
>[color=green]
> > (snip of base 1000 representation of decimal floating point)
> >[color=darkred]
> >>> The normalization is done in uncompressed (BCD) form, and then
> >>> they are converted to the base 1000 form for storage.[/color]
> >[color=darkred]
> >> If you have ever designed a floating point package you will
> >> realize that normalization takes up the majority of the time. It
> >> needs to be simple, not a major base conversion.[/color]
> >[color=darkred]
> >> Any reasonable form of decimal FP will be based on some flavor of
> >> bcd, possibly 8421, or excess 3, or 2*421, or even bi-quinary.[/color]
> >
> > I haven't actually checked, but rumors are that it only takes a
> > few gates to convert between the base 1000 representation, and
> > BCD. It can be done while loading into registers, or even
> > as part of the ALU, itself.[/color]
>
> Correct. For details, see a summary at:
>
> http://www2.hursley.ibm.com/decimal/DPDecimal.html[/color]

Thanks for the references. I am convinced as to the packing and
convertability, but offhand I don't think it solves the
normalization problem. It will still be necessary to normalize to
base 1000, or to convert to BCD and normalize to base 10, with the
effective loss of 4 to 10 bits of precision as compared to binary.

i.e. the minimum normalized value in Chen-Ho encoding and 30 bits
is 1,000,000 while the minimum in binary is 2**29, or about
500,000,000. This is ameliorated by the need for less bits to
describe the exponent to cover the same magnitudes. We haven't
even considered the efficiency improvement of assumed leading 1
bits in binary.

--
Chuck F (cbfalconer@yah oo.com) (cbfalconer@wor ldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home .att.net> USE worldnet address!
--
comp.lang.c.mod erated - moderation address: clcm@plethora.n et

[glen herrmannsfeldt]

Re: Decimal Floating Point (was Re: why still use C?)

Mike Cowlishaw wrote:

(snip)
[color=blue]
> There are a few constraints, though. For example, the ISO
> COBOL 2002 standard specifies that intermediate calculations
> be done using 32 decimal digits of precision. 32 digits of BCD
> into a 128-bit register leaves very little room for a sign and
> exponent.[/color]

I still have never written a COBOL program, but is that fixed point or
floating point?

-- glen
--
comp.lang.c.mod erated - moderation address: clcm@plethora.n et

[glen herrmannsfeldt]

Re: Decimal Floating Point (was Re: why still use C?)

CBFalconer wrote:
(snip)
[color=blue]
> Thanks for the references. I am convinced as to the packing and
> convertability, but offhand I don't think it solves the
> normalization problem. It will still be necessary to normalize to
> base 1000, or to convert to BCD and normalize to base 10, with the
> effective loss of 4 to 10 bits of precision as compared to binary.[/color]

One possibility is to store them in the registers in BCD.

Another is to convert to BCD, perform arithmetic operations, and
convert back to the packed form. This might be needed if the
same registers were used, and it was necessary not to enlarge
them. Though the Intel 80 bit registers should be big enough.
[color=blue]
> i.e. the minimum normalized value in Chen-Ho encoding and 30 bits
> is 1,000,000 while the minimum in binary is 2**29, or about
> 500,000,000. This is ameliorated by the need for less bits to
> describe the exponent to cover the same magnitudes. We haven't
> even considered the efficiency improvement of assumed leading 1
> bits in binary.[/color]

The calculation I did some days ago included the hidden bit.

Or at least I meant it to. IEEE double is 53 bits, including the
hidden 1.

-- glen
--
comp.lang.c.mod erated - moderation address: clcm@plethora.n et

[Mike Cowlishaw]

Re: Decimal Floating Point (was Re: why still use C?)

>> There are a few constraints, though. For example, the ISO[color=blue][color=green]
>> COBOL 2002 standard specifies that intermediate calculations
>> be done using 32 decimal digits of precision. 32 digits of BCD
>> into a 128-bit register leaves very little room for a sign and
>> exponent.[/color]
>
> I still have never written a COBOL program, but is that fixed point or
> floating point?[/color]

'Standard' COBOL arithmetic. Calculate as well as possible and then
assign to a fixed-point variable. Best ask COBOL folk what that is :-).

Mike
--
comp.lang.c.mod erated - moderation address: clcm@plethora.n et

[Mike Cowlishaw]

Re: Decimal Floating Point (was Re: why still use C?)

>>> (snip of base 1000 representation of decimal floating point)[color=blue][color=green][color=darkred]
>>>
>>>>> The normalization is done in uncompressed (BCD) form, and then
>>>>> they are converted to the base 1000 form for storage.
>>>
>>>> If you have ever designed a floating point package you will
>>>> realize that normalization takes up the majority of the time. It
>>>> needs to be simple, not a major base conversion.
>>>
>>>> Any reasonable form of decimal FP will be based on some flavor of
>>>> bcd, possibly 8421, or excess 3, or 2*421, or even bi-quinary.
>>>
>>> I haven't actually checked, but rumors are that it only takes a
>>> few gates to convert between the base 1000 representation, and
>>> BCD. It can be done while loading into registers, or even
>>> as part of the ALU, itself.[/color]
>>
>> Correct. For details, see a summary at:
>>
>> http://www2.hursley.ibm.com/decimal/DPDecimal.html[/color]
>
> Thanks for the references. I am convinced as to the packing and
> convertability, but offhand I don't think it solves the
> normalization problem. It will still be necessary to normalize to
> base 1000, or to convert to BCD and normalize to base 10, with the
> effective loss of 4 to 10 bits of precision as compared to binary.[/color]

Please explain the 'normalization problem' ... I have tried to
cover that in my FAQ but onviiously am lacking something.
[color=blue]
> i.e. the minimum normalized value in Chen-Ho encoding and 30 bits
> is 1,000,000 while the minimum in binary is 2**29, or about
> 500,000,000. This is ameliorated by the need for less bits to
> describe the exponent to cover the same magnitudes. We haven't
> even considered the efficiency improvement of assumed leading 1
> bits in binary.[/color]

[I think your calculations are a bit off?]

Mike Cowlishaw
--
comp.lang.c.mod erated - moderation address: clcm@plethora.n et

[Christian Bau]

Re: Decimal Floating Point (was Re: why still use C?)

In article <clcm-20031223-0008@plethora.n et>,
"Mike Cowlishaw" <mfcowli@attglo bal.net> wrote:
[color=blue][color=green][color=darkred]
> >> There are a few constraints, though. For example, the ISO
> >> COBOL 2002 standard specifies that intermediate calculations
> >> be done using 32 decimal digits of precision. 32 digits of BCD
> >> into a 128-bit register leaves very little room for a sign and
> >> exponent.[/color]
> >
> > I still have never written a COBOL program, but is that fixed point or
> > floating point?[/color]
>
> 'Standard' COBOL arithmetic. Calculate as well as possible and then
> assign to a fixed-point variable. Best ask COBOL folk what that is :-).[/color]

As you say COBOL requires 32 decimal digits of precision. Would that be
_exactly_ 32 digits of precision or _at least_ 32 digits of precision? I
think producing _exactly_ 32 digits if what you have available is 34
digits could be difficult.
--
comp.lang.c.mod erated - moderation address: clcm@plethora.n et

[Jerry Feldman]

Re: Decimal Floating Point (was Re: why still use C?)

On 23 Dec 2003 22:15:31 GMT
"Mike Cowlishaw" <mfcowli@attglo bal.net> wrote:
[color=blue][color=green][color=darkred]
> >> There are a few constraints, though. For example, the ISO
> >> COBOL 2002 standard specifies that intermediate calculations
> >> be done using 32 decimal digits of precision. 32 digits of BCD
> >> into a 128-bit register leaves very little room for a sign and
> >> exponent.[/color]
> >
> > I still have never written a COBOL program, but is that fixed point
> > or floating point?[/color]
>
> 'Standard' COBOL arithmetic. Calculate as well as possible and then
> assign to a fixed-point variable. Best ask COBOL folk what that is
> :-).[/color]
COBOL on some mainframes use true BCD arithmetic where each digit is
stored in a nybble with the sign usually taking up a nybble (I worked on
a mainframe where BCD numbers were nybble addresssable and the sign
could be either on the msb or lsb or absent. IBM mainframes, the sign is
in the low order nybble or the LSB. A number could have nearly any
precision and any number of decimal points since is was stored in
consecutive bytes. The hardware suppored this.
--
Jerry Feldman <gaf-nospam-at-blu.org>
Boston Linux and Unix user group
http://www.blu.org PGP key id:C5061EA9
PGP Key fingerprint:053 C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9
--
comp.lang.c.mod erated - moderation address: clcm@plethora.n et