bug-gnucobol
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Incorrect internal representation of P-scaled COMP-3 variables.


From: Ron Norman
Subject: Re: Incorrect internal representation of P-scaled COMP-3 variables.
Date: Fri, 29 Nov 2019 14:44:03 -0800

Keep in mind that all 01 data fields must be aligned on an address boundary that will handle any requirement of any possible sub-fields.
So aligning to 8 or 16 byte boundaries is correct.

On Fri, Nov 29, 2019 at 1:27 PM Robert Dubner <address@hidden> wrote:
Problem: Possible incorrect internal representation of P-scaled
COMP-3/PACKED-DECIMAL variables.

Irrelevant tentative inference:  Such variables aren't used much out in
the
real world.

Test program rtest.cbl:

        IDENTIFICATION DIVISION.
        PROGRAM-ID. RTEST.
        DATA DIVISION.
        WORKING-STORAGE SECTION.
        01 VAR1 PICTURE  P999     USAGE COMP-3 VALUE 0.0123 .
        01 VAR2 PICTURE  PP999    USAGE COMP-3 VALUE 0.00123 .
        01 VAR3 PICTURE  PPP999   USAGE COMP-3 VALUE 0.000123 .
        01 VAR4 PICTURE  PPPP999  USAGE COMP-3 VALUE 0.0000123 .
        01 VAR5 PICTURE  PPPPP999 USAGE COMP-3 VALUE 0.00000123 .
        PROCEDURE DIVISION.
        DISPLAY 'P999     ' VAR1
        DISPLAY 'PP999    ' VAR2
        DISPLAY 'PPP999   ' VAR3
        DISPLAY 'PPPP999  ' VAR4
        DISPLAY 'PPPPP999 ' VAR5
        DISPLAY 'Done'
        STOP RUN.

Compiled with: 3.1-dev.0

Command line: cobc -g -x rtest.cbl

Representation of VAR1 through VAR5 in rtest.c.l.h

    /* Data storage */
    static int  b_2;    /* RETURN-CODE */
    static cob_u8_t b_8[2] __attribute__((aligned));    /* VAR1 */
    static cob_u8_t b_9[2] __attribute__((aligned));    /* VAR2 */
    static cob_u8_t b_10[2] __attribute__((aligned));   /* VAR3 */
    static cob_u8_t b_11[2] __attribute__((aligned));   /* VAR4 */
    static cob_u8_t b_12[2] __attribute__((aligned));   /* VAR5 */

    /* End of local data storage */

Note specifically how each variable b_8 through b_12 has two bytes
allocated.

Output:

P999     .0103
PP999    .00103
PPP999   .000123
PPPP999  .0000123
PPPPP999 .00000123
Done

I then started a gdb session.  I found the line with the text "initialized
= 1",
which happened to be at line 200, and set a breakpoint there. After
reaching
that point, I dumped out the contents of b_8 through b_12:

Breakpoint 1, RTEST_ (entry=0) at rtest.c:200
200       initialized = 1;
(gdb) x/8xb b_8
0x555555756130 <b_8.4414>:    0x00  0x1f  0x30  0x00  0x00  0x00  0x00
0x00
(gdb) x/8xb b_9
0x555555756120 <b_9.4415>:    0x00  0x1f  0x30  0x00  0x00  0x00  0x00
0x00
(gdb) x/8xb b_10
0x555555756110 <b_10.4416>:   0x00  0x0f  0x12  0x30  0x00  0x00  0x00
0x00
(gdb) x/8xb b_11
0x555555756100 <b_11.4417>:   0x00  0x0f  0x12  0x30  0x00  0x00  0x00
0x00
(gdb) x/8xb b_12
0x5555557560f0 <b_12.4418>:   0x00  0x0f  0x00  0x12  0x30  0x00  0x00
0x00
(gdb)

Note that each of those variables, declared as char[2] in the C code, is
occupying more than two bytes.  The run-time is "saved" by the .align 16
in the assembler code; those variables are allocated on 16-byte
boundaries, so
they aren't overflowing into anything else.

So, there you have it.  My belief is that the data storage for each of
those
five variables should be identical:  Two bytes: 0x12 0x3f. 









--
Cheers
Ron Norman

reply via email to

[Prev in Thread] Current Thread [Next in Thread]