From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,245c84afd1e393ce X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news4.google.com!news.glorb.com!wn12feed!worldnet.att.net!bgtnsc05-news.ops.worldnet.att.net.POSTED!53ab2750!not-for-mail From: Dave Thompson Newsgroups: comp.lang.ada Subject: Re: What about big integers in Ada 2005? Message-ID: References: <1581461.uQ1jN63t33@linux1.krischik.com> <5mo0f.529$B14.97@newssvr11.news.prodigy.com> <1x4pe4pv41qsn$.m5c5jawjqcpq.dlg@40tude.net> X-Newsreader: Forte Agent 1.93/32.576 English (American) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 10 Oct 2005 05:36:02 GMT NNTP-Posting-Host: 12.75.193.108 X-Complaints-To: abuse@worldnet.att.net X-Trace: bgtnsc05-news.ops.worldnet.att.net 1128922562 12.75.193.108 (Mon, 10 Oct 2005 05:36:02 GMT) NNTP-Posting-Date: Mon, 10 Oct 2005 05:36:02 GMT Organization: AT&T Worldnet Xref: g2news1.google.com comp.lang.ada:5531 Date: 2005-10-10T05:36:02+00:00 List-Id: On Tue, 04 Oct 2005 18:56:20 GMT, wrote: > BCD was originally a six bit (where 7 was a parity bit) representation. With > the advent of the byte on the IBM System 360, BCD became Extended Binary > Coded Decimal Interchange Code (EBCDIC). > The 6-bit character code was BCDIC -- Binary Coded Decimal Interchange Code. With the advent of _8-bit_ bytes on S/360 it became EBCDIC. BCD was/is any representation that uses 4-bits for each decimal digit, hence the name. That can be an outright 4-bit processor like the original 4004; 4-bits in a 6-bit (BCDIC) or 8-bit (EBCDIC) or 7-bit (ASCII) character; or 2 4-bit nibbles packed in an 8-bit byte. > In COBOL for the 360, we had several Picture clauses available. > > 05 Item-1 PICTURE XXX . which would be represented by > EBCDIC > 05 Number PICTURE S99999. which would also be EBCDIC > 05 Hnumber PICTURE S99999 Usage Comp-3. which would be packed > > decimal. > > COMP-3 represented the numeric PICTURE by using a half-byte (nibble) for each 9 > in the picture and a nibble for the sign. In the example shown, Hnumber would > occupy > only three bytes where Number would occupy five bytes. In both cases, the > high-order > nibble is used for the sign. > Not that last; the S/360 decimal instructions (AP, SP, etc.) put the sign in the low-order nibble, namely the low half of the highest addressed byte, which is the low-valued one on big-endian S/360. For DISPLAY numeric the sign is in the high nibble aka 'zone' of _one_ byte, IIRC the low-order (high-address) one by default but you can specify SIGN [IS] LEADING | TRAILING . > There are actually some additional formats available including USAGE > COMPUTATIONAL > which is the same as representing a value in pure binary within the size of a > word. > Pure binary, but IIRC fullword or halfword depending on digits. And [DISPLAY] numeric with SIGN ... [IS] SEPARATE a full byte for each digit _plus_ one for sign. (And numeric edited even more, but that's no longer just a number representation anyway.) > I could write for a couple of hours on this topic, but I think this gets the > gist of the issue. > > The central problem is that business data processing people use all of these > formats > at one time or another. > - David.Thompson1 at worldnet.att.net