[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Incorrect internal representation of P-scaled COMP-3 variables.
From: |
Robert Dubner |
Subject: |
Incorrect internal representation of P-scaled COMP-3 variables. |
Date: |
Fri, 29 Nov 2019 14:50:58 -0600 (CST) |
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.
- Incorrect internal representation of P-scaled COMP-3 variables.,
Robert Dubner <=