* Re: long long long
@ 2000-09-22 18:14 Richard Kenner
0 siblings, 0 replies; 5+ messages in thread
From: Richard Kenner @ 2000-09-22 18:14 UTC (permalink / raw)
To: mrs; +Cc: gcc
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: long long long
@ 2000-09-22 17:51 Mike Stump
2000-09-23 11:33 ` Toon Moene
0 siblings, 1 reply; 5+ messages in thread
From: Mike Stump @ 2000-09-22 17:51 UTC (permalink / raw)
To: gcc, tej
> 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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: long long long
2000-09-22 17:51 Mike Stump
@ 2000-09-23 11:33 ` Toon Moene
0 siblings, 0 replies; 5+ messages in thread
From: Toon Moene @ 2000-09-23 11:33 UTC (permalink / raw)
To: Mike Stump; +Cc: gcc, tej
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)
^ permalink raw reply [flat|nested] 5+ messages in thread
* long long long
@ 2000-09-22 17:14 Tim Josling
2000-09-24 23:04 ` Geoff Keating
0 siblings, 1 reply; 5+ messages in thread
From: Tim Josling @ 2000-09-22 17:14 UTC (permalink / raw)
To: gcc
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: long long long
2000-09-22 17:14 Tim Josling
@ 2000-09-24 23:04 ` Geoff Keating
0 siblings, 0 replies; 5+ messages in thread
From: Geoff Keating @ 2000-09-24 23:04 UTC (permalink / raw)
To: Tim Josling; +Cc: gcc
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>
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2000-09-24 23:04 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-09-22 18:14 long long long Richard Kenner
-- strict thread matches above, loose matches on Subject: below --
2000-09-22 17:51 Mike Stump
2000-09-23 11:33 ` Toon Moene
2000-09-22 17:14 Tim Josling
2000-09-24 23:04 ` Geoff Keating
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).