long long long

long long long

[Tim Josling]

My COBOL compiler will need a 128 bit data type to support 31
digit decimal arithmetic which is required in the new cobol
standard. A couple of questions: is it technically feasible to
support this in GCC, similar to the way long long (64 bit) is
supported? Does it require that you have enough registers to hold
a whole value in storage?

In principle could a patch to support long long long be
acceptable?

There are alternatives but these involve seperately compiled
runtime support which does not optimize very well, or a lot of
work to create pseudo inline functions during the compile. Any
suggestions welcome. I have had a look at the Ada code and it is
not feasible to reuse that (eg it is written in Ada).

Tim Josling

Re: long long long

[Geoff Keating]

Tim Josling <tej@melbpc.org.au> writes:

> My COBOL compiler will need a 128 bit data type to support 31
> digit decimal arithmetic which is required in the new cobol
> standard. A couple of questions: is it technically feasible to
> support this in GCC, similar to the way long long (64 bit) is
> supported?

Yes; in fact, on some 64-bit ports there's partial support for it
already.

It would be a TImode value.

> Does it require that you have enough registers to hold
> a whole value in storage?

Yes.  That's a limitation of the way gcc 

> In principle could a patch to support long long long be
> acceptable?

Yes, but not if you call it 'long long long'.  Call it something like
__TImode__ in the C compiler (if you even allow it to be used from the
C compiler, although this is a good idea for test cases if nothing else).

-- 
- Geoffrey Keating <geoffk@cygnus.com>

Re: long long long

[Toon Moene]

Mike Stump wrote:

> > Date: Sat, 23 Sep 2000 10:12:17 +1100
> > From: Tim Josling <tej@melbpc.org.au>

> > My COBOL compiler will need a 128 bit data type to support 31 digit
> > decimal arithmetic which is required in the new cobol standard. A
> > couple of questions: is it technically feasible to support this in
> > GCC, similar to the way long long (64 bit) is supported?

> Unelss your machine has the actual instructions, or your code is
> exceedingly tiny to not blow out a cache, I do wonder if there would
> be much of a speed difference in using a traditional C library for
> such things.  If there isn't, why bother with builtin types?  Also, I
> thought most COBOL systems didn't bother with actual compilation, but
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> rather just targeted a cobol vm, and did it that way.  If you do it
> that way, the cost of using a more traditional approach would matter
> even less.

Ummmm, why do you think there's an EDITPC instruction on the VAX ?

[ Yes, I know, this has little to do with TImode support ]

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
GNU Fortran 95: http://g95.sourceforge.net/ (under construction)

Re: long long long

[Richard Kenner]

    Also, I thought most COBOL systems didn't bother with actual
    compilation, but rather just targeted a cobol vm, and did it that way.

This is news to me!  Certainly, the original COBOL compilers for the
IBM mainframes always generated machine code directly.  I know that
both major COBOL compilers for the x86 did as well.  Indeed, if I
remember correctly, one of them was the only compiler to ever generate
*all* x86 instructions from some code sequence.

Re: long long long

[Mike Stump]

> Date: Sat, 23 Sep 2000 10:12:17 +1100
> From: Tim Josling <tej@melbpc.org.au>

> My COBOL compiler will need a 128 bit data type to support 31 digit
> decimal arithmetic which is required in the new cobol standard. A
> couple of questions: is it technically feasible to support this in
> GCC, similar to the way long long (64 bit) is supported?

I'd think so.

> Does it require that you have enough registers to hold a whole value
> in storage?

It wants to work that way I suspect.

> In principle could a patch to support long long long be acceptable?

I'd think so.

> There are alternatives but these involve seperately compiled runtime
> support which does not optimize very well, or a lot of work to
> create pseudo inline functions during the compile. Any suggestions
> welcome.

Unelss your machine has the actual instructions, or your code is
exceedingly tiny to not blow out a cache, I do wonder if there would
be much of a speed difference in using a traditional C library for
such things.  If there isn't, why bother with builtin types?  Also, I
thought most COBOL systems didn't bother with actual compilation, but
rather just targeted a cobol vm, and did it that way.  If you do it
that way, the cost of using a more traditional approach would matter
even less.