This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: long long long
- To: gcc at gcc dot gnu dot org, tej at melbpc dot org dot au
- Subject: Re: long long long
- From: Mike Stump <mrs at windriver dot com>
- Date: Fri, 22 Sep 2000 17:50:54 -0700 (PDT)
> 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.