Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #38331 > unrolled thread

Can Java compute 9^(9^9) ?

Started bybursejan@gmail.com
First post2018-06-01 10:20 -0700
Last post2018-06-14 13:37 -0700
Articles 6 on this page of 26 — 7 participants

Back to article view | Back to comp.lang.java.programmer

Contents

  Can Java compute 9^(9^9) ? bursejan@gmail.com - 2018-06-01 10:20 -0700
    Re: Can Java compute 9^(9^9) ? Eric Sosman <esosman@comcast-dot-net.invalid> - 2018-06-01 13:36 -0400
      Re: Can Java compute 9^(9^9) ? j4n bur53 <janburse@fastmail.fm> - 2018-06-01 20:20 +0200
        Re: Can Java compute 9^(9^9) ? bursejan@gmail.com - 2018-06-05 07:17 -0700
          Re: Can Java compute 9^(9^9) ? bursejan@gmail.com - 2018-06-05 07:29 -0700
            Re: Can Java compute 9^(9^9) ? bursejan@gmail.com - 2018-06-05 07:48 -0700
            Re: Can Java compute 9^(9^9) ? Eric Sosman <esosman@comcast-dot-net.invalid> - 2018-06-05 10:57 -0400
              Re: Can Java compute 9^(9^9) ? bursejan@gmail.com - 2018-06-05 09:32 -0700
                Re: Can Java compute 9^(9^9) ? Eric Sosman <esosman@comcast-dot-net.invalid> - 2018-06-05 13:58 -0400
                  Re: Can Java compute 9^(9^9) ? bursejan@gmail.com - 2018-06-05 11:10 -0700
                    Re: Can Java compute 9^(9^9) ? bursejan@gmail.com - 2018-06-05 11:21 -0700
                      Re: Can Java compute 9^(9^9) ? Andreas Leitgeb <avl@logic.at> - 2018-06-06 08:50 +0000
                        Re: Can Java compute 9^(9^9) ? bursejan@gmail.com - 2018-06-06 01:58 -0700
                          Re: Can Java compute 9^(9^9) ? bursejan@gmail.com - 2018-06-06 02:01 -0700
                            Re: Can Java compute 9^(9^9) ? bursejan@gmail.com - 2018-06-06 10:34 -0700
    Re: Can Java compute 9^(9^9) ? j4n bur53 <janburse@fastmail.fm> - 2018-06-09 21:06 +0200
      Re: Can Java compute 9^(9^9) ? v_borchert@despammed.com (Volker Borchert) - 2018-06-09 23:29 +0000
        Re: Can Java compute 9^(9^9) ? Martin Gregorie <martin@mydomain.invalid> - 2018-06-10 09:13 +0000
          Re: Can Java compute 9^(9^9) ? bursejan@gmail.com - 2018-06-10 02:31 -0700
            Re: Can Java compute 9^(9^9) ? Arne Vajhøj <arne@vajhoej.dk> - 2018-06-10 18:28 -0400
              Re: Can Java compute 9^(9^9) ? bursejan@gmail.com - 2018-06-10 15:48 -0700
                Re: Can Java compute 9^(9^9) ? bursejan@gmail.com - 2018-06-10 15:52 -0700
                  Re: Can Java compute 9^(9^9) ? bursejan@gmail.com - 2018-06-10 15:58 -0700
                Re: Can Java compute 9^(9^9) ? Arne Vajhøj <arne@vajhoej.dk> - 2018-06-10 21:17 -0400
                  Re: Can Java compute 9^(9^9) ? bursejan@gmail.com - 2018-06-11 13:20 -0700
                    Re: Can Java compute 9^(9^9) ? bursejan@gmail.com - 2018-06-14 13:37 -0700

Page 2 of 2 — ← Prev page 1 [2]

#38356

Frombursejan@gmail.com
Date2018-06-10 15:48 -0700
Message-ID<578c1151-0e93-4316-8b82-32652421e022@googlegroups.com>
In reply to#38355
For VAX it was possibly option 2), at least
wikipedia says:

    Architectures with instruction sets 
    implemented by complex microprograms 
    included the IBM System/360 and Digital 
    Equipment Corporation VAX. 
    https://en.wikipedia.org/wiki/Microcode

And the instructions were so called decimal
string instructions, I guess:

Decimal =	Decimal instruction group

		ADDP4	ADDP6	ASHP	CMPP3	CMPP4
		CVTLP	CVTPL	CVTPS	CVTPT	CVTSP
		CVTTP	DIVP	MOVP	MULP	SUBP4
		SUBP6

Because there is always a length parameter,
I guess option 1) does not really exist. At
least if the aim is decimal strings.

Am Montag, 11. Juni 2018 00:29:14 UTC+2 schrieb Arne Vajhøj:
> On 6/10/2018 5:31 AM, bursejan@gmail.com wrote:
> > Am Sonntag, 10. Juni 2018 11:13:19 UTC+2 schrieb Martin Gregorie:
> >> On Sat, 09 Jun 2018 23:29:53 +0000, Volker Borchert wrote:
> >>> j4n bur53 wrote:
> >>>> Interestingly IBM, also for their new POWER9,
> >>>> still provides BCD coding support.
> >>>
> >>> Is it part of ANSI COBOL?
> >>>
> >> Its been a long time since I wrote any COBOL, and I've never done so on
> >> IBM kit [only ICL 1900 (24bit word, 6bit char), ICL 2900 (byte-oriented),
> >> DEC VAX, Tandem and NCR UNIX (Intel chips)] and AFAIK none of these
> >> machines supported BCD arithmetic at the hardware level.
> >>
> >> COBOL specifies a number of numeric representations which include COMP
> >> (fixed length numeric strings), DISPLAY (formatted character strings)
> >> COMP SYNC (native binary representations) and a few others (COMP-n)
> >> including floating point. I think you'll find that the internal
> >> representation of COMP variables is undefined by the standard as long as
> >> manipulating it works to the CODSASYL rules. I've looked at COBOL crash
> >> dumps on most of these systems and don't recall any of them using some
> >> form of non-native numeric storage, i.e. if you could read the assembler,
> >> the data division of the COBOL dump was understandable.
> > 
> > Intel 8080 had hardware support for BCD arithmetic
> > https://en.wikipedia.org/wiki/Half-carry_flag
> > 
> > While packed BCD does not make optimal use
> > of storage (about one-sixth of the memory used
> > is wasted), conversion to ASCII, EBCDIC, or
> > the various encodings of Unicode is still
> > trivial, as no arithmetic operations are
> > required. The extra storage requirements
> > are usually offset by the need for the
> > accuracy and compatibility with calculator
> > or hand calculation that fixed-point decimal
> > arithmetic provides. Denser packings of BCD
> > exist which avoid the storage penalty and
> > also need no arithmetic operations for
> > common conversions.
> > 
> > Packed BCD is supported in the COBOL programming
> > language as the "COMPUTATIONAL-3" (an IBM
> > extension adopted by many other compiler
> > vendors) or "PACKED-DECIMAL" (part of the
> > 1985 COBOL standard) data type. It is
> > supported in PL/I as "FIXED DECIMAL". Besides
> > the IBM System/360 and later compatible
> > mainframes, packed BCD is implemented
> > in the native instruction set of the
> > original VAX processors from Digital
> > Equipment Corporation and some models
> > of the SDS Sigma series mainframes, and
> > is the native format for the Burroughs
> > Corporation Medium Systems line of
> > mainframes (descended from the 1950s
> > Electrodata 200 series).
> 
> Note that there is a difference between supporting
> BCD format in memory and having the CPU support it.
> 
> Systems supporting BCD format in memory can process
> them in 3 different ways:
> 1) BCD instructions in the ISA implemented in actual
>     silicium
> 2) BCD instructions in the ISA implemented in
>     micro-code
> 3) non-BCD instructions
> 
> All will support COBOL COMP-3 fine.
> 
> #1 will be fastest, so if COBOL COMP-3 is a huge
> part of the actual workload for a given computer
> architecture then it makes sense.
> 
> Arne

[toc] | [prev] | [next] | [standalone]

#38357

Frombursejan@gmail.com
Date2018-06-10 15:52 -0700
Message-ID<cca5b121-58dc-4551-a370-81577fb24a26@googlegroups.com>
In reply to#38356
Here is a list which VAX had decimal fp, and which not,
in micro code and not in macro code:

VAX Processor Charts		Rev 7 15-Sep-2000
http://simh.trailing-edge.com/docs/vax_proc.txt

y	=	implemented in hardware/microcode
n	=	emulated in macrocode

It lists the processor model, and then yoi have to lookup
the VAX model.

Am Montag, 11. Juni 2018 00:48:31 UTC+2 schrieb burs...@gmail.com:
> For VAX it was possibly option 2), at least
> wikipedia says:
> 
>     Architectures with instruction sets 
>     implemented by complex microprograms 
>     included the IBM System/360 and Digital 
>     Equipment Corporation VAX. 
>     https://en.wikipedia.org/wiki/Microcode
> 
> And the instructions were so called decimal
> string instructions, I guess:
> 
> Decimal =	Decimal instruction group
> 
> 		ADDP4	ADDP6	ASHP	CMPP3	CMPP4
> 		CVTLP	CVTPL	CVTPS	CVTPT	CVTSP
> 		CVTTP	DIVP	MOVP	MULP	SUBP4
> 		SUBP6
> 
> Because there is always a length parameter,
> I guess option 1) does not really exist. At
> least if the aim is decimal strings.
> 
> Am Montag, 11. Juni 2018 00:29:14 UTC+2 schrieb Arne Vajhøj:
> > On 6/10/2018 5:31 AM, bursejan@gmail.com wrote:
> > > Am Sonntag, 10. Juni 2018 11:13:19 UTC+2 schrieb Martin Gregorie:
> > >> On Sat, 09 Jun 2018 23:29:53 +0000, Volker Borchert wrote:
> > >>> j4n bur53 wrote:
> > >>>> Interestingly IBM, also for their new POWER9,
> > >>>> still provides BCD coding support.
> > >>>
> > >>> Is it part of ANSI COBOL?
> > >>>
> > >> Its been a long time since I wrote any COBOL, and I've never done so on
> > >> IBM kit [only ICL 1900 (24bit word, 6bit char), ICL 2900 (byte-oriented),
> > >> DEC VAX, Tandem and NCR UNIX (Intel chips)] and AFAIK none of these
> > >> machines supported BCD arithmetic at the hardware level.
> > >>
> > >> COBOL specifies a number of numeric representations which include COMP
> > >> (fixed length numeric strings), DISPLAY (formatted character strings)
> > >> COMP SYNC (native binary representations) and a few others (COMP-n)
> > >> including floating point. I think you'll find that the internal
> > >> representation of COMP variables is undefined by the standard as long as
> > >> manipulating it works to the CODSASYL rules. I've looked at COBOL crash
> > >> dumps on most of these systems and don't recall any of them using some
> > >> form of non-native numeric storage, i.e. if you could read the assembler,
> > >> the data division of the COBOL dump was understandable.
> > > 
> > > Intel 8080 had hardware support for BCD arithmetic
> > > https://en.wikipedia.org/wiki/Half-carry_flag
> > > 
> > > While packed BCD does not make optimal use
> > > of storage (about one-sixth of the memory used
> > > is wasted), conversion to ASCII, EBCDIC, or
> > > the various encodings of Unicode is still
> > > trivial, as no arithmetic operations are
> > > required. The extra storage requirements
> > > are usually offset by the need for the
> > > accuracy and compatibility with calculator
> > > or hand calculation that fixed-point decimal
> > > arithmetic provides. Denser packings of BCD
> > > exist which avoid the storage penalty and
> > > also need no arithmetic operations for
> > > common conversions.
> > > 
> > > Packed BCD is supported in the COBOL programming
> > > language as the "COMPUTATIONAL-3" (an IBM
> > > extension adopted by many other compiler
> > > vendors) or "PACKED-DECIMAL" (part of the
> > > 1985 COBOL standard) data type. It is
> > > supported in PL/I as "FIXED DECIMAL". Besides
> > > the IBM System/360 and later compatible
> > > mainframes, packed BCD is implemented
> > > in the native instruction set of the
> > > original VAX processors from Digital
> > > Equipment Corporation and some models
> > > of the SDS Sigma series mainframes, and
> > > is the native format for the Burroughs
> > > Corporation Medium Systems line of
> > > mainframes (descended from the 1950s
> > > Electrodata 200 series).
> > 
> > Note that there is a difference between supporting
> > BCD format in memory and having the CPU support it.
> > 
> > Systems supporting BCD format in memory can process
> > them in 3 different ways:
> > 1) BCD instructions in the ISA implemented in actual
> >     silicium
> > 2) BCD instructions in the ISA implemented in
> >     micro-code
> > 3) non-BCD instructions
> > 
> > All will support COBOL COMP-3 fine.
> > 
> > #1 will be fastest, so if COBOL COMP-3 is a huge
> > part of the actual workload for a given computer
> > architecture then it makes sense.
> > 
> > Arne

[toc] | [prev] | [next] | [standalone]

#38358

Frombursejan@gmail.com
Date2018-06-10 15:58 -0700
Message-ID<da03eaad-548d-4c89-8fff-80396124157f@googlegroups.com>
In reply to#38357
So I guess it has been settled that VAX had something
for decimals. What I dont know whether PDP had something
for decimals.

Here is a nice story about DEC: Ken Olsen 1957 - 1989
https://www.youtube.com/watch?v=VEf2Xf7Urn8

Am Montag, 11. Juni 2018 00:52:33 UTC+2 schrieb burs...@gmail.com:
> Here is a list which VAX had decimal fp, and which not,
> in micro code and not in macro code:
> 
> VAX Processor Charts		Rev 7 15-Sep-2000
> http://simh.trailing-edge.com/docs/vax_proc.txt
> 
> y	=	implemented in hardware/microcode
> n	=	emulated in macrocode
> 
> It lists the processor model, and then yoi have to lookup
> the VAX model.
> 
> Am Montag, 11. Juni 2018 00:48:31 UTC+2 schrieb burs...@gmail.com:
> > For VAX it was possibly option 2), at least
> > wikipedia says:
> > 
> >     Architectures with instruction sets 
> >     implemented by complex microprograms 
> >     included the IBM System/360 and Digital 
> >     Equipment Corporation VAX. 
> >     https://en.wikipedia.org/wiki/Microcode
> > 
> > And the instructions were so called decimal
> > string instructions, I guess:
> > 
> > Decimal =	Decimal instruction group
> > 
> > 		ADDP4	ADDP6	ASHP	CMPP3	CMPP4
> > 		CVTLP	CVTPL	CVTPS	CVTPT	CVTSP
> > 		CVTTP	DIVP	MOVP	MULP	SUBP4
> > 		SUBP6
> > 
> > Because there is always a length parameter,
> > I guess option 1) does not really exist. At
> > least if the aim is decimal strings.
> > 
> > Am Montag, 11. Juni 2018 00:29:14 UTC+2 schrieb Arne Vajhøj:
> > > On 6/10/2018 5:31 AM, bursejan@gmail.com wrote:
> > > > Am Sonntag, 10. Juni 2018 11:13:19 UTC+2 schrieb Martin Gregorie:
> > > >> On Sat, 09 Jun 2018 23:29:53 +0000, Volker Borchert wrote:
> > > >>> j4n bur53 wrote:
> > > >>>> Interestingly IBM, also for their new POWER9,
> > > >>>> still provides BCD coding support.
> > > >>>
> > > >>> Is it part of ANSI COBOL?
> > > >>>
> > > >> Its been a long time since I wrote any COBOL, and I've never done so on
> > > >> IBM kit [only ICL 1900 (24bit word, 6bit char), ICL 2900 (byte-oriented),
> > > >> DEC VAX, Tandem and NCR UNIX (Intel chips)] and AFAIK none of these
> > > >> machines supported BCD arithmetic at the hardware level.
> > > >>
> > > >> COBOL specifies a number of numeric representations which include COMP
> > > >> (fixed length numeric strings), DISPLAY (formatted character strings)
> > > >> COMP SYNC (native binary representations) and a few others (COMP-n)
> > > >> including floating point. I think you'll find that the internal
> > > >> representation of COMP variables is undefined by the standard as long as
> > > >> manipulating it works to the CODSASYL rules. I've looked at COBOL crash
> > > >> dumps on most of these systems and don't recall any of them using some
> > > >> form of non-native numeric storage, i.e. if you could read the assembler,
> > > >> the data division of the COBOL dump was understandable.
> > > > 
> > > > Intel 8080 had hardware support for BCD arithmetic
> > > > https://en.wikipedia.org/wiki/Half-carry_flag
> > > > 
> > > > While packed BCD does not make optimal use
> > > > of storage (about one-sixth of the memory used
> > > > is wasted), conversion to ASCII, EBCDIC, or
> > > > the various encodings of Unicode is still
> > > > trivial, as no arithmetic operations are
> > > > required. The extra storage requirements
> > > > are usually offset by the need for the
> > > > accuracy and compatibility with calculator
> > > > or hand calculation that fixed-point decimal
> > > > arithmetic provides. Denser packings of BCD
> > > > exist which avoid the storage penalty and
> > > > also need no arithmetic operations for
> > > > common conversions.
> > > > 
> > > > Packed BCD is supported in the COBOL programming
> > > > language as the "COMPUTATIONAL-3" (an IBM
> > > > extension adopted by many other compiler
> > > > vendors) or "PACKED-DECIMAL" (part of the
> > > > 1985 COBOL standard) data type. It is
> > > > supported in PL/I as "FIXED DECIMAL". Besides
> > > > the IBM System/360 and later compatible
> > > > mainframes, packed BCD is implemented
> > > > in the native instruction set of the
> > > > original VAX processors from Digital
> > > > Equipment Corporation and some models
> > > > of the SDS Sigma series mainframes, and
> > > > is the native format for the Burroughs
> > > > Corporation Medium Systems line of
> > > > mainframes (descended from the 1950s
> > > > Electrodata 200 series).
> > > 
> > > Note that there is a difference between supporting
> > > BCD format in memory and having the CPU support it.
> > > 
> > > Systems supporting BCD format in memory can process
> > > them in 3 different ways:
> > > 1) BCD instructions in the ISA implemented in actual
> > >     silicium
> > > 2) BCD instructions in the ISA implemented in
> > >     micro-code
> > > 3) non-BCD instructions
> > > 
> > > All will support COBOL COMP-3 fine.
> > > 
> > > #1 will be fastest, so if COBOL COMP-3 is a huge
> > > part of the actual workload for a given computer
> > > architecture then it makes sense.
> > > 
> > > Arne

[toc] | [prev] | [next] | [standalone]

#38359

FromArne Vajhøj <arne@vajhoej.dk>
Date2018-06-10 21:17 -0400
Message-ID<pfkiih$1glu$1@gioia.aioe.org>
In reply to#38356
On 6/10/2018 6:48 PM, bursejan@gmail.com wrote:
> Am Montag, 11. Juni 2018 00:29:14 UTC+2 schrieb Arne Vajhøj:
>> On 6/10/2018 5:31 AM, bursejan@gmail.com wrote:
>>> Am Sonntag, 10. Juni 2018 11:13:19 UTC+2 schrieb Martin Gregorie:
>>>> On Sat, 09 Jun 2018 23:29:53 +0000, Volker Borchert wrote:
>>>>> j4n bur53 wrote:
>>>>>> Interestingly IBM, also for their new POWER9,
>>>>>> still provides BCD coding support.
>>>>>
>>>>> Is it part of ANSI COBOL?

>>> Packed BCD is supported in the COBOL programming
>>> language as the "COMPUTATIONAL-3" (an IBM
>>> extension adopted by many other compiler
>>> vendors) or "PACKED-DECIMAL" (part of the
>>> 1985 COBOL standard) data type. It is
>>> supported in PL/I as "FIXED DECIMAL". Besides
>>> the IBM System/360 and later compatible
>>> mainframes, packed BCD is implemented
>>> in the native instruction set of the
>>> original VAX processors from Digital
>>> Equipment Corporation and some models
>>> of the SDS Sigma series mainframes, and
>>> is the native format for the Burroughs
>>> Corporation Medium Systems line of
>>> mainframes (descended from the 1950s
>>> Electrodata 200 series).
>>
>> Note that there is a difference between supporting
>> BCD format in memory and having the CPU support it.
>>
>> Systems supporting BCD format in memory can process
>> them in 3 different ways:
>> 1) BCD instructions in the ISA implemented in actual
>>      silicium
>> 2) BCD instructions in the ISA implemented in
>>      micro-code
>> 3) non-BCD instructions
>>
>> All will support COBOL COMP-3 fine.
>>
>> #1 will be fastest, so if COBOL COMP-3 is a huge
>> part of the actual workload for a given computer
>> architecture then it makes sense.
 >
> For VAX it was possibly option 2), at least
> wikipedia says:
> 
>      Architectures with instruction sets
>      implemented by complex microprograms
>      included the IBM System/360 and Digital
>      Equipment Corporation VAX.
>      https://en.wikipedia.org/wiki/Microcode
> 
> And the instructions were so called decimal
> string instructions, I guess:
> 
> Decimal =	Decimal instruction group
> 
> 		ADDP4	ADDP6	ASHP	CMPP3	CMPP4
> 		CVTLP	CVTPL	CVTPS	CVTPT	CVTSP
> 		CVTTP	DIVP	MOVP	MULP	SUBP4
> 		SUBP6
> 
> Because there is always a length parameter,
> I guess option 1) does not really exist. At
> least if the aim is decimal strings.

Yes - VAX xxxP is BCD.

Length is necessary as there is a need to support different
lengths.

I would think even a pure silicium solution would need
that.

Arne

[toc] | [prev] | [next] | [standalone]

#38360

Frombursejan@gmail.com
Date2018-06-11 13:20 -0700
Message-ID<089e177b-ca23-4f6d-8369-6b86330ca206@googlegroups.com>
In reply to#38359
OCaml seems to now simply hook on GMP.

https://github.com/ocaml/Zarith

Maybe Java should also hook on GMP?

Just joking...

Am Montag, 11. Juni 2018 03:17:16 UTC+2 schrieb Arne Vajhøj:
> On 6/10/2018 6:48 PM, bursejan@gmail.com wrote:
> > Am Montag, 11. Juni 2018 00:29:14 UTC+2 schrieb Arne Vajhøj:
> >> On 6/10/2018 5:31 AM, bursejan@gmail.com wrote:
> >>> Am Sonntag, 10. Juni 2018 11:13:19 UTC+2 schrieb Martin Gregorie:
> >>>> On Sat, 09 Jun 2018 23:29:53 +0000, Volker Borchert wrote:
> >>>>> j4n bur53 wrote:
> >>>>>> Interestingly IBM, also for their new POWER9,
> >>>>>> still provides BCD coding support.
> >>>>>
> >>>>> Is it part of ANSI COBOL?
> 
> >>> Packed BCD is supported in the COBOL programming
> >>> language as the "COMPUTATIONAL-3" (an IBM
> >>> extension adopted by many other compiler
> >>> vendors) or "PACKED-DECIMAL" (part of the
> >>> 1985 COBOL standard) data type. It is
> >>> supported in PL/I as "FIXED DECIMAL". Besides
> >>> the IBM System/360 and later compatible
> >>> mainframes, packed BCD is implemented
> >>> in the native instruction set of the
> >>> original VAX processors from Digital
> >>> Equipment Corporation and some models
> >>> of the SDS Sigma series mainframes, and
> >>> is the native format for the Burroughs
> >>> Corporation Medium Systems line of
> >>> mainframes (descended from the 1950s
> >>> Electrodata 200 series).
> >>
> >> Note that there is a difference between supporting
> >> BCD format in memory and having the CPU support it.
> >>
> >> Systems supporting BCD format in memory can process
> >> them in 3 different ways:
> >> 1) BCD instructions in the ISA implemented in actual
> >>      silicium
> >> 2) BCD instructions in the ISA implemented in
> >>      micro-code
> >> 3) non-BCD instructions
> >>
> >> All will support COBOL COMP-3 fine.
> >>
> >> #1 will be fastest, so if COBOL COMP-3 is a huge
> >> part of the actual workload for a given computer
> >> architecture then it makes sense.
>  >
> > For VAX it was possibly option 2), at least
> > wikipedia says:
> > 
> >      Architectures with instruction sets
> >      implemented by complex microprograms
> >      included the IBM System/360 and Digital
> >      Equipment Corporation VAX.
> >      https://en.wikipedia.org/wiki/Microcode
> > 
> > And the instructions were so called decimal
> > string instructions, I guess:
> > 
> > Decimal =	Decimal instruction group
> > 
> > 		ADDP4	ADDP6	ASHP	CMPP3	CMPP4
> > 		CVTLP	CVTPL	CVTPS	CVTPT	CVTSP
> > 		CVTTP	DIVP	MOVP	MULP	SUBP4
> > 		SUBP6
> > 
> > Because there is always a length parameter,
> > I guess option 1) does not really exist. At
> > least if the aim is decimal strings.
> 
> Yes - VAX xxxP is BCD.
> 
> Length is necessary as there is a need to support different
> lengths.
> 
> I would think even a pure silicium solution would need
> that.
> 
> Arne

[toc] | [prev] | [next] | [standalone]

#38380

Frombursejan@gmail.com
Date2018-06-14 13:37 -0700
Message-ID<6296a912-0b6d-451e-a540-108297e25bae@googlegroups.com>
In reply to#38360
Checked latest Spire/Scala. 
https://github.com/non/spire

No FFT multiplication found, right?
But otherwise looks fun.

Am Montag, 11. Juni 2018 22:20:46 UTC+2 schrieb burs...@gmail.com:
> OCaml seems to now simply hook on GMP.
> 
> https://github.com/ocaml/Zarith
> 
> Maybe Java should also hook on GMP?
> 
> Just joking...
> 
> Am Montag, 11. Juni 2018 03:17:16 UTC+2 schrieb Arne Vajhøj:
> > On 6/10/2018 6:48 PM, bursejan@gmail.com wrote:
> > > Am Montag, 11. Juni 2018 00:29:14 UTC+2 schrieb Arne Vajhøj:
> > >> On 6/10/2018 5:31 AM, bursejan@gmail.com wrote:
> > >>> Am Sonntag, 10. Juni 2018 11:13:19 UTC+2 schrieb Martin Gregorie:
> > >>>> On Sat, 09 Jun 2018 23:29:53 +0000, Volker Borchert wrote:
> > >>>>> j4n bur53 wrote:
> > >>>>>> Interestingly IBM, also for their new POWER9,
> > >>>>>> still provides BCD coding support.
> > >>>>>
> > >>>>> Is it part of ANSI COBOL?
> > 
> > >>> Packed BCD is supported in the COBOL programming
> > >>> language as the "COMPUTATIONAL-3" (an IBM
> > >>> extension adopted by many other compiler
> > >>> vendors) or "PACKED-DECIMAL" (part of the
> > >>> 1985 COBOL standard) data type. It is
> > >>> supported in PL/I as "FIXED DECIMAL". Besides
> > >>> the IBM System/360 and later compatible
> > >>> mainframes, packed BCD is implemented
> > >>> in the native instruction set of the
> > >>> original VAX processors from Digital
> > >>> Equipment Corporation and some models
> > >>> of the SDS Sigma series mainframes, and
> > >>> is the native format for the Burroughs
> > >>> Corporation Medium Systems line of
> > >>> mainframes (descended from the 1950s
> > >>> Electrodata 200 series).
> > >>
> > >> Note that there is a difference between supporting
> > >> BCD format in memory and having the CPU support it.
> > >>
> > >> Systems supporting BCD format in memory can process
> > >> them in 3 different ways:
> > >> 1) BCD instructions in the ISA implemented in actual
> > >>      silicium
> > >> 2) BCD instructions in the ISA implemented in
> > >>      micro-code
> > >> 3) non-BCD instructions
> > >>
> > >> All will support COBOL COMP-3 fine.
> > >>
> > >> #1 will be fastest, so if COBOL COMP-3 is a huge
> > >> part of the actual workload for a given computer
> > >> architecture then it makes sense.
> >  >
> > > For VAX it was possibly option 2), at least
> > > wikipedia says:
> > > 
> > >      Architectures with instruction sets
> > >      implemented by complex microprograms
> > >      included the IBM System/360 and Digital
> > >      Equipment Corporation VAX.
> > >      https://en.wikipedia.org/wiki/Microcode
> > > 
> > > And the instructions were so called decimal
> > > string instructions, I guess:
> > > 
> > > Decimal =	Decimal instruction group
> > > 
> > > 		ADDP4	ADDP6	ASHP	CMPP3	CMPP4
> > > 		CVTLP	CVTPL	CVTPS	CVTPT	CVTSP
> > > 		CVTTP	DIVP	MOVP	MULP	SUBP4
> > > 		SUBP6
> > > 
> > > Because there is always a length parameter,
> > > I guess option 1) does not really exist. At
> > > least if the aim is decimal strings.
> > 
> > Yes - VAX xxxP is BCD.
> > 
> > Length is necessary as there is a need to support different
> > lengths.
> > 
> > I would think even a pure silicium solution would need
> > that.
> > 
> > Arne

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.java.programmer

csiph-web