On Aug 26, 10:54 pm, "Richard B. Gilbert"
wrote:
> Tom Linden wrote:
> > On Sun, 26 Aug 2007 17:50:13 -0700, Richard B. Gilbert
> > wrote:
>
> >> Alignment faults are basically caused by how you arrange and declare
> >> your structures. This was a problem long before there was a VAX or
> >> VMS. We worried about it in IBM/360 Fortran IV. If you failed to
> >> put your REAL*8 variables first in your COMMON blocks, you could get
> >> alignment faults. Fixing them up slowed execution and the machines
> >> of yesteryear were slow to begin with. Doing anything to make them
> >> slower was anathema!!
>
> > IIRC, PL/I on 360 didn't have that problem, afterall it was a byte
> > addressable
> > machine, as is the VAX.
>
> I can't swear to it that ALL IBM/360 were sensitive to alignment but the
> Model 91 certainly was! The model 91 was the super computer of the day.
> AIRC NASA ordered 17 of them from IBM and several Universities,
> including Princeton jumped on the bandwagon and wanted one too.
> Princeton had the model 91 when I started working there ca. January 1970.
>
> Just because a machine is byte adressable does not mean that there is no
> advantage to aligning your accesses. You can access any byte in memory
> but the machine may retrieve a byte, word, longword, or quadword in
> order to get that byte and it may like some number of the low order bits
> of the address to be zero. To retrieve a quadword that was not quadword
> aligned could require two memory accesses instead of one. ISTR that, at
> least in the IBM 360, the size of a memory access varied with the model.
> The model 91 grabbed a quadword at a time from core (real magnetic
> cores. . . Oh the nostalgia!) and loaded the piece(s) you wanted where
> you wanted them. Accesses that were quadword aligned were fastest. The
> model 91 had a sixteen-way interleave and I believe it retrieved sixteen
> bytes at a time.

Richard,

Alignment did matter on all models of the System/360, unless there
were special provisions to the contrary (reference, "Systems/360
Principles of Operation").

The alignment restrictions were eased with the advent of the System/
370.

Alignment faults can generally be detected by the compiler's code
generator and dealt with appropriately. This is even true for
MACRO-32, which is a compiler on all architectures other than the
original VAX. The problem is not unaligned data per se, but data whose
alignment is misrepresented to the compiler. The simplest cases of
this occur with data passed to subroutines as parameters. Probably the
more common case is data that is contained within structures that are
themselves within other structures. Somewhere along the chain, some
piece of code violates the alignment presumption.

There are two alternatives: provide hardware support for the mis-
alignment consequences, or take a fault and use software to sort it
out.

The increased overhead on Alpha and Itanium generally results from the
inherent overhead of taking the fault and winding down processing. The
more an architecture pre-fetches and pipelines, the higher the penalty
for faulting and other interrupts. Note that the penalty on a non-
pipelined, non-optimized machine is zero for faults, but it is also a
far slower machine in all other aspects.

Please remember that the problem is not how many alignment errors
there are in the code, the problem is how often they are executed.
Many of the cases of performance sapping alignment faults have not, I
strongly suspect, been systematic coding errors, but unrealized errors
that happened to be embedded in a frequently used code path.

- Bob Gezelter, http://www.rlgsc.com

On Aug 26, 8:45 pm, "Paul Raulerson" wrote:
> Are you saying the compile does not pad that out correctly? That should not
> be a problem in COBOL so far as I know.

By default, the HP COBOL compiler does not insert padding into a data
structure in order to align all the elementary data items. You can
read the HP COBOL User's Manual for all the gory details of how the /
ALIGNMENT qualifier and/or compiler directives are used to modify this
behavior.

Having done a number of migrations to OpenVMS from other platforms,
and ported applications from VAX to Alpha, I can tell you that the
default is really appropriate. Particularly in those cases where data
structures are written directly to an RMS file where disk space was at
a premium (old thinking since disk is relatively inexpensive now, but
I've been at this for a long time).

Hi Frank,

> There comes a point where the compiler writers need
> to stop being the data police for users that don't do their own
> performance analysis.

/OPTIMIZE must really do your head in hey?

Cheers Richard Maher


"FrankS" wrote in message
news:1188174360.239654.298340@o80g2000hse.googlegr oups.com...
> On Aug 26, 8:04 pm, "Richard Maher"
> wrote:
> > Forgot to mention that COBOL, like all other compilers, has the
/alignment
> > qualifiers if you're happy for it to pad 3 bytes between data_item_1 and
> > data_item_3.
>
> >From a porting perspective, though, I would expect the default
> qualifiers (no alignment) would be used, particularly if data
> structures are being used to read/write from files that already
> exist. That is, if files already exist with records that were not
> padded then the /ALIGNMENT qualifier wouldn't come into play. (Yes,
> yes, I know you can use compiler directives to selectively align
> structures. That's getting way off stream from the question of
> whether or not alignment faults are more likely to occur in Macro .vs.
> COBOL.)
>
> I'm aware that the compiler will generate instructions to manipulate
> bytes within an aligned quadword, but I didn't think it would generate
> instructions to manipulate all data items so that alignment faults are
> always avoided. There comes a point where the compiler writers need
> to stop being the data police for users that don't do their own
> performance analysis.
>

In article , Evert van Dijken writes:
> Depends on you programming language, Only macro needs to be rewritten.

Most macro does not need to be rewritten. Especially if its Macro-32
that already been ported from VAX to Alpha, the Itanium Macro-32
compiler should be able to handle it.

In article , "Tom Linden" writes:
> On Sun, 26 Aug 2007 17:50:13 -0700, Richard B. Gilbert
> wrote:
>
>> Alignment faults are basically caused by how you arrange and declare
>> your structures. This was a problem long before there was a VAX or
>> VMS. We worried about it in IBM/360 Fortran IV. If you failed to put
>> your REAL*8 variables first in your COMMON blocks, you could get
>> alignment faults. Fixing them up slowed execution and the machines of
>> yesteryear were slow to begin with. Doing anything to make them slower
>> was anathema!!
>>
> IIRC, PL/I on 360 didn't have that problem, afterall it was a byte
> addressable
> machine, as is the VAX.

FORTRAN-H Extended Enhanced for the 360 and 370 would point out
alignment problems, but generate the code anyhow.

Let's see if I can answer all the questions I spotted in this thread.

1) If the compiler knows that a particular data item is unaligned, (ie,
3 bytes from the beginning of the structure), we will generate
instructions to access the data in pieces and reassemble it in
registers. We won't "give up". If you see the compiler generating
aligned code for known-to-be-unaligned data, it is a compiler bug.
Period. Tell us.

2) Speaking of compiler bugs, COBOL prior to V2.9 had several bugs where
it generated aligned code for known-to-be-unaligned data items. V2.9
fixes all of them.

3) COBOL does not align/pad data items by default due to various
language issues. Look at /ALIGN and /ALIGN=PADDED for ways to get COBOL
to align items. Note that this will not (or at least should not) change
the amount of alignment faults. Poorly aligned data items are accessed
with multiple instructions that should not fault. Properly aligned data
items are accessed with single instructions that should not fault.

--
John Reagan
OpenVMS Pascal/Macro-32/COBOL Project Leader
Hewlett-Packard Company

In article <1188172138.417708.74290@50g2000hsm.googlegroups.co m>,
FrankS wrote:

> On Aug 26, 5:32 pm, Ron Johnson wrote:
> > Wouldn't alignment faults be more of a problem in Macro than in,
> > say, COBOL?
>
> This is a COBOL alignment fault ...
>
> 01 TOP-LEVEL.
> 03 DATA-ITEM-1 PIC X(1).
> 03 DATA-ITEM-2 PIC S9(9) COMP.
>
> Data-Item-2 is not on a natural boundary. This likely happens in lots
> and lots of places in many COBOL programs. I'm sure there's a ton of
> similar problems in programs I and many others have written over the
> years.

Maybe there are a lot of instances of this out there, but I was taught
to word align integers back in VAX COBOL days. Having said that, I was
lucky enough to start with a "clean slate", as opposed to porting
existing COBOL from other platforms.

IIRC VAX COBOL had compiler options for alignment too.

Question:-

Are there large alignment penalties on Itanium for COMP-3 data types
(packed decimal for non-COBOL readers)?

--
Paul Sture

Sue's OpenVMS bookmarks:
http://eisner.encompasserve.org/~stu...bookmarks.html

Hi Paul,

> Maybe there are a lot of instances of this out there, but I was taught
> to word align integers back in VAX COBOL days.

Oh really? Disk space was cheap back then was it?

"Yes, me and Gungadin used to fill our disks with padding bytes; don't fire
till you see the whites of their eyes; esprit de cour and all that."

Cheers Richard Maher

"P. Sture" wrote in message
newsaul.sture.nospam-211A9E.02440928082007@mac.sture.ch...
> In article <1188172138.417708.74290@50g2000hsm.googlegroups.co m>,
> FrankS wrote:
>
> > On Aug 26, 5:32 pm, Ron Johnson wrote:
> > > Wouldn't alignment faults be more of a problem in Macro than in,
> > > say, COBOL?
> >
> > This is a COBOL alignment fault ...
> >
> > 01 TOP-LEVEL.
> > 03 DATA-ITEM-1 PIC X(1).
> > 03 DATA-ITEM-2 PIC S9(9) COMP.
> >
> > Data-Item-2 is not on a natural boundary. This likely happens in lots
> > and lots of places in many COBOL programs. I'm sure there's a ton of
> > similar problems in programs I and many others have written over the
> > years.
>
> Maybe there are a lot of instances of this out there, but I was taught
> to word align integers back in VAX COBOL days. Having said that, I was
> lucky enough to start with a "clean slate", as opposed to porting
> existing COBOL from other platforms.
>
> IIRC VAX COBOL had compiler options for alignment too.
>
> Question:-
>
> Are there large alignment penalties on Itanium for COMP-3 data types
> (packed decimal for non-COBOL readers)?
>
> --
> Paul Sture
>
> Sue's OpenVMS bookmarks:
> http://eisner.encompasserve.org/~stu...bookmarks.html

In article ,
"Richard Maher" wrote:

> Hi Paul,
>
> > Maybe there are a lot of instances of this out there, but I was taught
> > to word align integers back in VAX COBOL days.
>
> Oh really? Disk space was cheap back then was it?
>

Eh? What are you wittering on about Dickie?

Consider a primary key of 17 bytes. Belongs at the beginning of an RMS
record in my book. Find another variable that's only one byte long and
it belongs next.

Then you define yer integers. I did say word aligned, not longword or
quadword aligned.

> "Yes, me and Gungadin used to fill our disks with padding bytes; don't fire
> till you see the whites of their eyes; esprit de cour and all that."

Righty-ho, I'll tell Carruthers and Farqhuart. They'll hold the
blighters off.

PS. Has anyone here actually come across anyone actually named
Carruthers or Farqhuart? I certainly haven't.

PPS. In he early 1980s I inadvertently contributed to the Y2K problem,
simply because I didn't believe an application would last so long.

If you wish to compare an amortization of the disk costs of doing
otherwise for 15+ years versus the one-off exercise that was Y2K, please
feel free to do so.

:-)

--
Paul Sture

Sue's OpenVMS bookmarks:
http://eisner.encompasserve.org/~stu...bookmarks.html

On 08/26/07 18:48, FrankS wrote:
> On Aug 26, 5:32 pm, Ron Johnson wrote:
>> Wouldn't alignment faults be more of a problem in Macro than in,
>> say, COBOL?
>
> This is a COBOL alignment fault ...
>
> 01 TOP-LEVEL.
> 03 DATA-ITEM-1 PIC X(1).
> 03 DATA-ITEM-2 PIC S9(9) COMP.
>
> Data-Item-2 is not on a natural boundary. This likely happens in lots
> and lots of places in many COBOL programs. I'm sure there's a ton of
> similar problems in programs I and many others have written over the
> years.

You'd think that something as complex as a COBOL compiler would
already align TOP-LEVEL.

--
Ron Johnson, Jr.
Jefferson LA USA

Give a man a fish, and he eats for a day.
Hit him with a fish, and he goes away for good!

On Tue, 28 Aug 2007 17:40:14 -0700, Ron Johnson
wrote:

> On 08/26/07 18:48, FrankS wrote:
>> On Aug 26, 5:32 pm, Ron Johnson wrote:
>>> Wouldn't alignment faults be more of a problem in Macro than in,
>>> say, COBOL?
>>
>> This is a COBOL alignment fault ...
>>
>> 01 TOP-LEVEL.
>> 03 DATA-ITEM-1 PIC X(1).
>> 03 DATA-ITEM-2 PIC S9(9) COMP.
>>
>> Data-Item-2 is not on a natural boundary. This likely happens in lots
>> and lots of places in many COBOL programs. I'm sure there's a ton of
>> similar problems in programs I and many others have written over the
>> years.
>
> You'd think that something as complex as a COBOL compiler would
> already align TOP-LEVEL.
>
Alignment is a relatively recent restriction, at least in the severity of
the
performance penalties. Cobol and PL/I both had the ability to move data
directly from disc
or tape to Cobol Records and PL/I Structures. These were typically
densely packed, meaning
members were not naturally aligned. Because Alpha and Itanium didn't
provide for unaligned
access which didn't significantly deteriate performance, the design was
deficient. This
is essentially failure to provide backward compatibility and is incredibly
stupid and a
dismal failure on the part of VMS management. But then you have
VAX->Alpha->Itanium.
Your unaligned Cobol and PL/I code runs just fine on ALL IBM machines.


--
PL/I for OpenVMS
www.kednos.com

"Ron Johnson" wrote in message
news:Of3Bi.69048$GO6.41099@newsfe21.lga...
> On 08/26/07 18:48, FrankS wrote:
>> On Aug 26, 5:32 pm, Ron Johnson wrote:
>>> Wouldn't alignment faults be more of a problem in Macro than in,
>>> say, COBOL?
>>
>> This is a COBOL alignment fault ...
>>
>> 01 TOP-LEVEL.
>> 03 DATA-ITEM-1 PIC X(1).
>> 03 DATA-ITEM-2 PIC S9(9) COMP.
>>
>> Data-Item-2 is not on a natural boundary. This likely happens in lots
>> and lots of places in many COBOL programs. I'm sure there's a ton of
>> similar problems in programs I and many others have written over the
>> years.
>
> You'd think that something as complex as a COBOL compiler would
> already align TOP-LEVEL.

I'm not a compiler writer but, I don't think that example would create an
alignment *fault* because the COBOL compiler would avoid it. The compiler
would know that DATA-ITEM-2 isn't aligned so it would generate extra
instructions to load a quadword and bit shift any time it referenced
DATA-ITEM-2. That's a few extra instructions which usually isn't a big
deal. You get an alignment fault when the compiler doesn't know the
alignment at compile time so it generates instructions which assume aligned
data then, if it turns out that the data isn't aligned, you get an alignment
fault which gets trapped and handled at the cost of hundreds of
instructions.

So, I would say that Macro programs would tend to generate more alignment
faults because there's usually more pointer arithmetic in macro programs
than there is in COBOL programs.

> -----Original Message-----
> From: Ron Johnson [mailto:ron.l.johnson@cox.net]
> Sent: Tuesday, August 28, 2007 7:40 PM
> To: Info-VAX@Mvb.Saic.Com
> Subject: Re: Itanium Port Question
>
> On 08/26/07 18:48, FrankS wrote:
> > On Aug 26, 5:32 pm, Ron Johnson wrote:
> >> Wouldn't alignment faults be more of a problem in Macro than in,
> >> say, COBOL?
> >
> > This is a COBOL alignment fault ...
> >
> > 01 TOP-LEVEL.
> > 03 DATA-ITEM-1 PIC X(1).
> > 03 DATA-ITEM-2 PIC S9(9) COMP.
> >
> > Data-Item-2 is not on a natural boundary. This likely happens in
> lots
> > and lots of places in many COBOL programs. I'm sure there's a ton of
> > similar problems in programs I and many others have written over the
> > years.
>
> You'd think that something as complex as a COBOL compiler would
> already align TOP-LEVEL.
>

It did, really. Here's part of the generated code on an Alpha, which I am
refraining from explaining because perhaps someone more familiar with Alpha
will explain. (Please? Oddly enough, the generated CODE is exactly the
same, which gives me reason to pause. I wonder if someone would post the
generated code from an Itanium system please?

Anyways- the complete listings are included below the two snippets below,
for completeness.
-Paul


This is generated from:
1 IDENTIFICATION DIVISION.
2 PROGRAM-ID. TEST3.
3
4 ENVIRONMENT DIVISION.
5
6 DATA DIVISION.
7 WORKING-STORAGE SECTION.
8 01 TOP-LEVEL.
9 03 DATA-ITEM-1 PIC X(1).
10 03 DATA-ITEM-2 PIC S9(9) COMP.
11
12 PROCEDURE DIVISION.
13 START-PROGRAM.
14 MOVE 'Z' TO DATA-ITEM-1
15 MOVE -212 TO DATA-ITEM-2
16 STOP RUN
...
[snip]
...

00000001 0078 .LONG X^1 ; .LONG 1
00000001 007C .LONG X^1 ; .LONG 1
00000000 0080 .LONG X^0 ; .LONG 0
00000004 0088 .ADDRESS TOP-LEVEL+4
00000001 0090 .LONG X^1 ; .LONG 1
00000004 0094 .LONG X^4 ; .LONG 4


This is generated from:
1 IDENTIFICATION DIVISION.
2 PROGRAM-ID. TEST2.
3
4 ENVIRONMENT DIVISION.
5
6 DATA DIVISION.
7 WORKING-STORAGE SECTION.
8 01 TOP-LEVEL.
9 03 DATA-ITEM-2 PIC S9(9) COMP.
10 03 DATA-ITEM-1 PIC X(1).
11
12 PROCEDURE DIVISION.
13 START-PROGRAM.
14 MOVE 'Z' TO DATA-ITEM-1
15 MOVE -212 TO DATA-ITEM-2
16 STOP RUN
...
[snip]
...


00000004 007C .LONG X^4 ; .LONG 4
20 0080 .ASCII \ \

00000004 0088 .ADDRESS TOP-LEVEL+4
00000001 0090 .LONG X^1 ; .LONG 1
00000001 0094 .LONG X^1 ; .LONG 1


========== Cut here- complete listings included below ================

TEST2 Source Listing 28-AUG-2007
20:51:10 Compaq COBOL V2.8-1286 Page 1
0 28-AUG-2007
20:50:41 DKB100:[PAUL.SRC.COBOL]TEST2.COB;4

1 IDENTIFICATION DIVISION.
2 PROGRAM-ID. TEST2.
3
4 ENVIRONMENT DIVISION.
5
6 DATA DIVISION.
7 WORKING-STORAGE SECTION.
8 01 TOP-LEVEL.
9 03 DATA-ITEM-2 PIC S9(9) COMP.
10 03 DATA-ITEM-1 PIC X(1).
11
12 PROCEDURE DIVISION.
13 START-PROGRAM.
14 MOVE 'Z' TO DATA-ITEM-1
15 MOVE -212 TO DATA-ITEM-2
16 STOP RUN
17 .


TEST2 Source Listing 28-AUG-2007
20:51:10 Compaq COBOL V2.8-1286 Page 2
0 Program Section Summary 28-AUG-2007
20:50:41 DKB100:[PAUL.SRC.COBOL]TEST2.COB;4



PROGRAM SECTION INDEX

Index Name Bytes Alignment Attributes
----- ------------------------------- ---------- ---------
-------------------------------------------------------------
1 $CODE$ 92 OCTA 4 PIC
CON REL LCL SHR EXE NORD NOWRT NOVEC
2 $LOCAL$ 152 OCTA 4 NOPIC
CON REL LCL NOSHR NOEXE RD WRT NOVEC
3 $LINK$ 96 OCTA 4 NOPIC
CON REL LCL NOSHR NOEXE RD NOWRT NOVEC
7 COB$NAMES_____2 48 OCTA 4 PIC
CON REL LCL NOSHR NOEXE RD WRT NOVEC



DIAGNOSTICS SUMMARY

Informationals 1 (suppressed)
----------------------
Total 1


TEST2 Machine Code Listing 28-AUG-2007
20:51:10 Compaq COBOL V2.8-1286 Page 3
0 Source Listing 28-AUG-2007
20:50:41 DKB100:[PAUL.SRC.COBOL]TEST2.COB;4

.PSECT $CODE$, OCTA, PIC, CON, REL, LCL,
SHR,-
EXE, NORD, NOWRT
0000 TEST2::
A41B0030 0000 LDQ R0, 48(R27)
23DEFFD0 0004 LDA SP, -48(SP)
A61B0038 0008 LDQ R16, 56(R27)
47E03419 000C MOV 1, R25
B75E0010 0010 STQ R26, 16(SP)
B77E0000 0014 STQ R27, (SP)
A75B0050 0018 LDQ R26, 80(R27)
B7FE0008 001C STQ R31, 8(SP)
B45E0018 0020 STQ R2, 24(SP)
B7BE0020 0024 STQ FP, 32(SP)
63FF0000 0028 TRAPB
47FE041D 002C MOV SP, FP
47FB0402 0030 MOV R27, R2
B7E0FFC8 0034 STQ R31, -56(R0)
A7620058 0038 LDQ R27, 88(R2)
B3E00000 003C STL R31, (R0)
6B5A4000 0040 JSR R26, DCOB$CALLED
; R26, R26
A4220030 0044 LDQ R1, 48(R2)
A7420040 0048 LDQ R26, 64(R2)
; 000016
47FF0419 004C CLR R25
A7620048 0050 LDQ R27, 72(R2)
B401FFD0 0054 STQ R0, -48(R1)
; 000002
6B5A4000 0058 JSR R26, DCOB$STOP
; R26, R26 ; 000016

Routine Size: 92 bytes, Routine Base: $CODE$ + 0000


.PSECT $LOCAL$, OCTA, NOPIC, CON, REL,
LCL,-
NOSHR, NOEXE, RD, WRT
TOP-LEVEL:
00000000 0000 .LONG X^0 ; .LONG 0
20 0004 .ASCII \ \

$$1:
54534554 0020 .ASCII \TEST2\
32 0024

RETURN-CODE:
00000001 0028 .LONG X^1 ; .LONG 1
$$2:
00000000 0030 .ADDRESS $$3
00000000 0038 .QUAD X^0 ; .QUAD 0
00000000 003C
00000003 0040 .LONG X^3 ; .LONG 3
00000000 0044 .LONG X^0 ; .LONG 0
00000001 0048 .LONG X^1 ; .LONG 1
$$3:
00000001 0050 .LONG X^1 ; .LONG 1
00000000 0058 .ADDRESS RETURN-CODE
00000001 0060 .LONG X^1 ; .LONG 1
00000004 0064 .LONG X^4 ; .LONG 4
00000000 0068 .LONG X^0 ; .LONG 0
00000000 0070 .ADDRESS TOP-LEVEL
00000001 0078 .LONG X^1 ; .LONG 1


TEST2 Machine Code Listing 28-AUG-2007
20:51:10 Compaq COBOL V2.8-1286 Page 4
0 TEST2 28-AUG-2007
20:50:41 DKB100:[PAUL.SRC.COBOL]TEST2.COB;4

00000004 007C .LONG X^4 ; .LONG 4
20 0080 .ASCII \ \

00000004 0088 .ADDRESS TOP-LEVEL+4
00000001 0090 .LONG X^1 ; .LONG 1
00000001 0094 .LONG X^1 ; .LONG 1

.PSECT $LINK$, OCTA, NOPIC, CON, REL, LCL,-
NOSHR, NOEXE, RD, NOWRT

0000 ; Stack-Frame invocation descriptor
Entry point: TEST2
Entry Length: 48
Static Handler: DCOB$SIGNAL_HANDLER
Registers used: R0-R2, R16, R25-R26,
R28-FP
Registers saved: R2, FP
Fixed Stack Size: 48
00000000 ; Handler data for DCOB$SIGNAL_HANDLER
00000000
00000000
00000000

00000048 0030 .ADDRESS $LOCAL$+72
00000000 0038 .ADDRESS TEST2
0040 .LINKAGE DCOB$STOP
0050 .LINKAGE DCOB$CALLED

.PSECT COB$NAMES_____2, OCTA, PIC, CON,
REL,-
LCL, NOSHR, NOEXE, RD, WRT
$$4:
00000000 0000 .ADDRESS $$1
00000000 0008 .ADDRESS TEST2
00000000 0010 .QUAD X^0 ; .QUAD 0
00000000 0014
00000000 0018 .ADDRESS $$2
00000005 0020 .LONG X^5 ; .LONG 5
00000000 0024 .LONG X^0 ; .LONG 0
00000000 0028 .LONG X^0 ; .LONG 0
00000000 002C .LONG X^0 ; .LONG 0


Source Listing 28-AUG-2007
20:51:10 Compaq COBOL V2.8-1286 Page 5
Compilation Summary 28-AUG-2007
20:50:41 DKB100:[PAUL.SRC.COBOL]TEST2.COB;4



COMMAND QUALIFIERS

COBOL

/NOALIGNMENT
/GRANULARITY = QUAD
/NOANALYSIS_DATA
/NOINCLUDE
/NOANSI_FORMAT /LIST

/ARCHITECTURE = GENERIC
/MACHINE_CODE
/ARITHMETIC = NATIVE /NOMAP

/NOAUDIT
/MATH_INTERMEDIATE = FLOAT
/CHECK = (NOPERFORM, NOBOUNDS, NODECIMAL, NODUPLICATE_KEYS)
/NATIONALITY = US
/NOCONDITIONALS /OBJECT

/NOCONVERT = LEADING_BLANKS
/OPTIMIZE = (LEVEL=4,TUNE=GENERIC)
/NOCOPY_LIST
/RESERVED_WORDS = (XOPEN, NOFOREIGN_EXTENSIONS, NO200X)
/NOCROSS_REFERENCE
/NOSEPARATE_COMPILATION
/DEBUG = (NOSYMBOLS, TRACEBACK)
/NOSEQUENCE_CHECK
/NODEPENDENCY_DATA
/STANDARD = (NOXOPEN, NOSYNTAX, NOV3, 85, NOMIA)
/NODIAGNOSTICS /NOTIE

/NODISPLAY_FORMATTED
/NOTRUNCATE
/NOFIPS /VFC

/NOFLAGGER
/WARNINGS = (NOINFORMATION, OTHER)
/FLOAT = D_FLOAT



COMPILATION STATISTICS

CPU time: 0.15 seconds
Elapsed time: 0.28 seconds
Pagefaults: 681
I/O Count: 29
Source lines: 17

6800 lines per CPU minute.

----
----
---
TEST3 Source Listing 28-AUG-2007
20:51:23 Compaq COBOL V2.8-1286 Page 1
0 28-AUG-2007
20:50:25 DKB100:[PAUL.SRC.COBOL]TEST3.COB;4

1 IDENTIFICATION DIVISION.
2 PROGRAM-ID. TEST3.
3
4 ENVIRONMENT DIVISION.
5
6 DATA DIVISION.
7 WORKING-STORAGE SECTION.
8 01 TOP-LEVEL.
9 03 DATA-ITEM-1 PIC X(1).
10 03 DATA-ITEM-2 PIC S9(9) COMP.
11
12 PROCEDURE DIVISION.
13 START-PROGRAM.
14 MOVE 'Z' TO DATA-ITEM-1
15 MOVE -212 TO DATA-ITEM-2
16 STOP RUN
17 .


TEST3 Source Listing 28-AUG-2007
20:51:23 Compaq COBOL V2.8-1286 Page 2
0 Program Section Summary 28-AUG-2007
20:50:25 DKB100:[PAUL.SRC.COBOL]TEST3.COB;4



PROGRAM SECTION INDEX

Index Name Bytes Alignment Attributes
----- ------------------------------- ---------- ---------
-------------------------------------------------------------
1 $CODE$ 92 OCTA 4 PIC
CON REL LCL SHR EXE NORD NOWRT NOVEC
2 $LOCAL$ 152 OCTA 4 NOPIC
CON REL LCL NOSHR NOEXE RD WRT NOVEC
3 $LINK$ 96 OCTA 4 NOPIC
CON REL LCL NOSHR NOEXE RD NOWRT NOVEC
7 COB$NAMES_____2 48 OCTA 4 PIC
CON REL LCL NOSHR NOEXE RD WRT NOVEC



DIAGNOSTICS SUMMARY

Informationals 1 (suppressed)
----------------------
Total 1


TEST3 Machine Code Listing 28-AUG-2007
20:51:23 Compaq COBOL V2.8-1286 Page 3
0 Source Listing 28-AUG-2007
20:50:25 DKB100:[PAUL.SRC.COBOL]TEST3.COB;4

.PSECT $CODE$, OCTA, PIC, CON, REL, LCL,
SHR,-
EXE, NORD, NOWRT
0000 TEST3::
A41B0030 0000 LDQ R0, 48(R27)
23DEFFD0 0004 LDA SP, -48(SP)
A61B0038 0008 LDQ R16, 56(R27)
47E03419 000C MOV 1, R25
B75E0010 0010 STQ R26, 16(SP)
B77E0000 0014 STQ R27, (SP)
A75B0050 0018 LDQ R26, 80(R27)
B7FE0008 001C STQ R31, 8(SP)
B45E0018 0020 STQ R2, 24(SP)
B7BE0020 0024 STQ FP, 32(SP)
63FF0000 0028 TRAPB
47FE041D 002C MOV SP, FP
47FB0402 0030 MOV R27, R2
B7E0FFC8 0034 STQ R31, -56(R0)
A7620058 0038 LDQ R27, 88(R2)
B3E00000 003C STL R31, (R0)
6B5A4000 0040 JSR R26, DCOB$CALLED
; R26, R26
A4220030 0044 LDQ R1, 48(R2)
A7420040 0048 LDQ R26, 64(R2)
; 000016
47FF0419 004C CLR R25
A7620048 0050 LDQ R27, 72(R2)
B401FFD0 0054 STQ R0, -48(R1)
; 000002
6B5A4000 0058 JSR R26, DCOB$STOP
; R26, R26 ; 000016

Routine Size: 92 bytes, Routine Base: $CODE$ + 0000


.PSECT $LOCAL$, OCTA, NOPIC, CON, REL,
LCL,-
NOSHR, NOEXE, RD, WRT
TOP-LEVEL:
20 0000 .ASCII \ \

00000000 0004 .LONG X^0 ; .LONG 0
$$1:
54534554 0020 .ASCII \TEST3\
33 0024

RETURN-CODE:
00000001 0028 .LONG X^1 ; .LONG 1
$$2:
00000000 0030 .ADDRESS $$3
00000000 0038 .QUAD X^0 ; .QUAD 0
00000000 003C
00000003 0040 .LONG X^3 ; .LONG 3
00000000 0044 .LONG X^0 ; .LONG 0
00000001 0048 .LONG X^1 ; .LONG 1
$$3:
00000001 0050 .LONG X^1 ; .LONG 1
00000000 0058 .ADDRESS RETURN-CODE
00000001 0060 .LONG X^1 ; .LONG 1
00000004 0064 .LONG X^4 ; .LONG 4
20 0068 .ASCII \ \

00000000 0070 .ADDRESS TOP-LEVEL


TEST3 Machine Code Listing 28-AUG-2007
20:51:23 Compaq COBOL V2.8-1286 Page 4
0 TEST3 28-AUG-2007
20:50:25 DKB100:[PAUL.SRC.COBOL]TEST3.COB;4

00000001 0078 .LONG X^1 ; .LONG 1
00000001 007C .LONG X^1 ; .LONG 1
00000000 0080 .LONG X^0 ; .LONG 0
00000004 0088 .ADDRESS TOP-LEVEL+4
00000001 0090 .LONG X^1 ; .LONG 1
00000004 0094 .LONG X^4 ; .LONG 4

.PSECT $LINK$, OCTA, NOPIC, CON, REL, LCL,-
NOSHR, NOEXE, RD, NOWRT

0000 ; Stack-Frame invocation descriptor
Entry point: TEST3
Entry Length: 48
Static Handler: DCOB$SIGNAL_HANDLER
Registers used: R0-R2, R16, R25-R26,
R28-FP
Registers saved: R2, FP
Fixed Stack Size: 48
00000000 ; Handler data for DCOB$SIGNAL_HANDLER
00000000
00000000
00000000

00000048 0030 .ADDRESS $LOCAL$+72
00000000 0038 .ADDRESS TEST3
0040 .LINKAGE DCOB$STOP
0050 .LINKAGE DCOB$CALLED

.PSECT COB$NAMES_____2, OCTA, PIC, CON,
REL,-
LCL, NOSHR, NOEXE, RD, WRT
$$4:
00000000 0000 .ADDRESS $$1
00000000 0008 .ADDRESS TEST3
00000000 0010 .QUAD X^0 ; .QUAD 0
00000000 0014
00000000 0018 .ADDRESS $$2
00000005 0020 .LONG X^5 ; .LONG 5
00000000 0024 .LONG X^0 ; .LONG 0
00000000 0028 .LONG X^0 ; .LONG 0
00000000 002C .LONG X^0 ; .LONG 0


Source Listing 28-AUG-2007
20:51:23 Compaq COBOL V2.8-1286 Page 5
Compilation Summary 28-AUG-2007
20:50:25 DKB100:[PAUL.SRC.COBOL]TEST3.COB;4



COMMAND QUALIFIERS

COBOL

/ALIGNMENT
/GRANULARITY = QUAD
/NOANALYSIS_DATA
/NOINCLUDE
/NOANSI_FORMAT /LIST

/ARCHITECTURE = GENERIC
/MACHINE_CODE
/ARITHMETIC = NATIVE /NOMAP

/NOAUDIT
/MATH_INTERMEDIATE = FLOAT
/CHECK = (NOPERFORM, NOBOUNDS, NODECIMAL, NODUPLICATE_KEYS)
/NATIONALITY = US
/NOCONDITIONALS /OBJECT

/NOCONVERT = LEADING_BLANKS
/OPTIMIZE = (LEVEL=4,TUNE=GENERIC)
/NOCOPY_LIST
/RESERVED_WORDS = (XOPEN, NOFOREIGN_EXTENSIONS, NO200X)
/NOCROSS_REFERENCE
/NOSEPARATE_COMPILATION
/DEBUG = (NOSYMBOLS, TRACEBACK)
/NOSEQUENCE_CHECK
/NODEPENDENCY_DATA
/STANDARD = (NOXOPEN, NOSYNTAX, NOV3, 85, NOMIA)
/NODIAGNOSTICS /NOTIE

/NODISPLAY_FORMATTED
/NOTRUNCATE
/NOFIPS /VFC

/NOFLAGGER
/WARNINGS = (NOINFORMATION, OTHER)
/FLOAT = D_FLOAT



COMPILATION STATISTICS

CPU time: 0.19 seconds
Elapsed time: 0.30 seconds
Pagefaults: 664
I/O Count: 30
Source lines: 17

5368 lines per CPU minute.

On Aug 28, 10:04 pm, "Paul Raulerson" wrote:
> > -----Original Message-----
> > From: Ron Johnson [mailto:ron.l.john...@cox.net]
:
> It did, really. Here's part of the generated code on an Alpha, which I am
> refraining from explaining because perhaps someone more familiar with Alpha
> will explain. (Please? Oddly enough, the generated CODE is exactly the
> same, which gives me reason to pause.

It should. Use the pause to study the code.
There is NO code generated for line 14,15.
It's optimized away.
All you have is program prologue + epilogue.

Toss in a line like:

16 call "test" using DATA-ITEM-1, DATA-ITEM-2

Now you'll see... line 15 exploding into 10 instructions
to do the unalignment protection.

:
LDQ_U R18, -4(R3) ; 000015
LDQ_U R17, -7(R3)
MOV -212, R1
LDA R16, -7(R3)
INSLH R1, R16, R20
INSLL R1, R16, R19
LDQ R23, 48(R2) ; 000002
LDQ R26, 96(R2) ; 000016
LDQ R27, 104(R2)
MOV 2, R25
MSKLH R18, R16, R18 ; 000015
MSKLL R17, R16, R17
LDA R16, -8(R3) ; 000016
BIS R18, R20, R18 ; 000015
BIS R17, R19, R17
STQ_U R18, -4(R3)
STQ_U R17, -7(R3)

Flip the two fields around to natually align them, or tell the
compiler to go ahead and alignt and you''l get 2 instuctions:
:
MOV -212, R1 ; 000015
:
STL R1, -8(R3) ; 000015
:

So you will NOT get a run time aligment faults in either case.

Personally I would appreciate an informational at compile that that
this is dumb coding, but that's not available.


ps 1... There is rally no strong reason to make a primary key be the
first field in the record, if that creates any trouble at all. RMS
will store the primary key as the first bytes for quicker comparesm
and re-assemble if the records is select later anyway.
ps 2... Rounding records (for indexed files) to be a 'nice' 512 bytes
or some such make NO sense at all, as RMS has odd sized headers, and
it likely to compress the data.

Cheers,
Hein.







I wonder if someone would post the
> generated code from an Itanium system please?
>
> Anyways- the complete listings are included below the two snippets below,
> for completeness.
> -Paul
>
> This is generated from:
> 1 IDENTIFICATION DIVISION.
> 2 PROGRAM-ID. TEST3.
> 3
> 4 ENVIRONMENT DIVISION.
> 5
> 6 DATA DIVISION.
> 7 WORKING-STORAGE SECTION.
> 8 01 TOP-LEVEL.
> 9 03 DATA-ITEM-1 PIC X(1).
> 10 03 DATA-ITEM-2 PIC S9(9) COMP.
> 11
> 12 PROCEDURE DIVISION.
> 13 START-PROGRAM.
> 14 MOVE 'Z' TO DATA-ITEM-1
> 15 MOVE -212 TO DATA-ITEM-2
> 16 STOP RUN
> ..
> [snip]
> ..
>
> 00000001 0078 .LONG X^1 ; .LONG 1
> 00000001 007C .LONG X^1 ; .LONG 1
> 00000000 0080 .LONG X^0 ; .LONG 0
> 00000004 0088 .ADDRESS TOP-LEVEL+4
> 00000001 0090 .LONG X^1 ; .LONG 1
> 00000004 0094 .LONG X^4 ; .LONG 4
>
> This is generated from:
> 1 IDENTIFICATION DIVISION.
> 2 PROGRAM-ID. TEST2.
> 3
> 4 ENVIRONMENT DIVISION.
> 5
> 6 DATA DIVISION.
> 7 WORKING-STORAGE SECTION.
> 8 01 TOP-LEVEL.
> 9 03 DATA-ITEM-2 PIC S9(9) COMP.
> 10 03 DATA-ITEM-1 PIC X(1).
> 11
> 12 PROCEDURE DIVISION.
> 13 START-PROGRAM.
> 14 MOVE 'Z' TO DATA-ITEM-1
> 15 MOVE -212 TO DATA-ITEM-2
> 16 STOP RUN
> ..
> [snip]
> ..
>
> 00000004 007C .LONG X^4 ; .LONG 4
> 20 0080 .ASCII \ \
>
> 00000004 0088 .ADDRESS TOP-LEVEL+4
> 00000001 0090 .LONG X^1 ; .LONG 1
> 00000001 0094 .LONG X^1 ; .LONG 1
>
> ========== Cut here- complete listings included below================
>
> TEST2 Source Listing 28-AUG-2007
> 20:51:10 Compaq COBOL V2.8-1286 Page 1
> 0 28-AUG-2007
> 20:50:41 DKB100:[PAUL.SRC.COBOL]TEST2.COB;4
>
> 1 IDENTIFICATION DIVISION.
> 2 PROGRAM-ID. TEST2.
> 3
> 4 ENVIRONMENT DIVISION.
> 5
> 6 DATA DIVISION.
> 7 WORKING-STORAGE SECTION.
> 8 01 TOP-LEVEL.
> 9 03 DATA-ITEM-2 PIC S9(9) COMP.
> 10 03 DATA-ITEM-1 PIC X(1).
> 11
> 12 PROCEDURE DIVISION.
> 13 START-PROGRAM.
> 14 MOVE 'Z' TO DATA-ITEM-1
> 15 MOVE -212 TO DATA-ITEM-2
> 16 STOP RUN
> 17 .
>
> TEST2 Source Listing 28-AUG-2007
> 20:51:10 Compaq COBOL V2.8-1286 Page 2
> 0 Program Section Summary 28-AUG-2007
> 20:50:41 DKB100:[PAUL.SRC.COBOL]TEST2.COB;4
>
> PROGRAM SECTION INDEX
>
> Index Name Bytes Alignment Attributes
> ----- ------------------------------- ---------- ---------
> -------------------------------------------------------------
> 1 $CODE$ 92 OCTA 4 PIC
> CON REL LCL SHR EXE NORD NOWRT NOVEC
> 2 $LOCAL$ 152 OCTA 4 NOPIC
> CON REL LCL NOSHR NOEXE RD WRT NOVEC
> 3 $LINK$ 96 OCTA 4 NOPIC
> CON REL LCL NOSHR NOEXE RD NOWRT NOVEC
> 7 COB$NAMES_____2 48 OCTA 4 PIC
> CON REL LCL NOSHR NOEXE RD WRT NOVEC
>
> DIAGNOSTICS SUMMARY
>
> Informationals 1 (suppressed)
> ----------------------
> Total 1
>
> TEST2 Machine Code Listing 28-AUG-2007
> 20:51:10 Compaq COBOL V2.8-1286 Page 3
> 0 Source Listing 28-AUG-2007
> 20:50:41 DKB100:[PAUL.SRC.COBOL]TEST2.COB;4
>
> .PSECT $CODE$, OCTA, PIC, CON, REL, LCL,
> SHR,-
> EXE, NORD, NOWRT
> 0000 TEST2::
> A41B0030 0000 LDQ R0, 48(R27)
> 23DEFFD0 0004 LDA SP, -48(SP)
> A61B0038 0008 LDQ R16, 56(R27)
> 47E03419 000C MOV 1, R25
> B75E0010 0010 STQ R26, 16(SP)
> B77E0000 0014 STQ R27, (SP)
> A75B0050 0018 LDQ R26, 80(R27)
> B7FE0008 001C STQ R31, 8(SP)
> B45E0018 0020 STQ R2, 24(SP)
> B7BE0020 0024 STQ FP, 32(SP)
> 63FF0000 0028 TRAPB
> 47FE041D 002C MOV SP, FP
> 47FB0402 0030 MOV R27, R2
> B7E0FFC8 0034 STQ R31, -56(R0)
> A7620058 0038 LDQ R27, 88(R2)
> B3E00000 003C STL R31, (R0)
> 6B5A4000 0040 JSR R26, DCOB$CALLED
> ; R26, R26
> A4220030 0044 LDQ R1, 48(R2)
> A7420040 0048 LDQ R26, 64(R2)
> ; 000016
> 47FF0419 004C CLR R25
> A7620048 0050 LDQ R27, 72(R2)
> B401FFD0 0054 STQ R0, -48(R1)
> ; 000002
> 6B5A4000 0058 JSR R26, DCOB$STOP
> ; R26, R26 ; 000016
>
> Routine Size: 92 bytes, Routine Base: $CODE$ + 0000
>
> .PSECT $LOCAL$, OCTA, NOPIC, CON, REL,
> LCL,-
> NOSHR, NOEXE, RD, WRT
> TOP-LEVEL:
> 00000000 0000 .LONG X^0 ; .LONG 0
> 20 0004 .ASCII \ \
>
> $$1:
> 54534554 0020 .ASCII \TEST2\
> 32 0024
>
> RETURN-CODE:
> 00000001 0028 .LONG X^1 ; .LONG 1
> $$2:
> 00000000 0030 .ADDRESS $$3
> 00000000 0038 .QUAD X^0 ; .QUAD 0
> 00000000 003C
> 00000003 0040 .LONG X^3 ; .LONG 3
> 00000000 0044 .LONG X^0 ; .LONG 0
> 00000001 0048 .LONG X^1 ; .LONG 1
> $$3:
> 00000001 0050 .LONG X^1 ; .LONG 1
> 00000000 0058 .ADDRESS RETURN-CODE
> 00000001 0060 .LONG X^1 ; .LONG 1
> 00000004 0064 .LONG X^4 ; .LONG 4
> 00000000 0068 .LONG X^0 ; .LONG 0
> 00000000 0070 .ADDRESS TOP-LEVEL
> 00000001 0078 .LONG X^1 ; .LONG 1
>
> TEST2 Machine Code Listing 28-AUG-2007
> 20:51:10 Compaq COBOL V2.8-1286 Page 4
> 0 TEST2 28-AUG-2007
> 20:50:41 DKB100:[PAUL.SRC.COBOL]TEST2.COB;4
>
> 00000004 007C .LONG X^4 ; .LONG 4
> 20 0080 .ASCII \ \
>
> 00000004 0088 .ADDRESS TOP-LEVEL+4
> 00000001 0090 .LONG X^1 ; .LONG 1
> 00000001 0094 .LONG X^1 ; .LONG 1
>
> .PSECT $LINK$, OCTA, NOPIC, CON, REL, LCL,-
> NOSHR, NOEXE, RD, NOWRT
>
> 0000 ; Stack-Frame invocation descriptor
> Entry point: TEST2
> Entry Length: 48
> Static Handler: DCOB$SIGNAL_HANDLER
> Registers used: R0-R2, R16, R25-R26,
> R28-FP
> Registers saved: R2, FP
> Fixed Stack Size: 48
> 00000000 ; Handler data for DCOB$SIGNAL_HANDLER
> 00000000
> 00000000
> 00000000
>
> 00000048 0030 .ADDRESS $LOCAL$+72
> 00000000 0038 .ADDRESS TEST2
> 0040 .LINKAGE DCOB$STOP
> 0050 .LINKAGE DCOB$CALLED
>
> .PSECT COB$NAMES_____2, OCTA, PIC, CON,
> REL,-
> LCL, NOSHR, NOEXE, RD, WRT
> $$4:
> 00000000 0000 .ADDRESS $$1
> 00000000 0008 .ADDRESS TEST2
> 00000000 0010 .QUAD X^0 ; .QUAD 0
> 00000000 0014
> 00000000 0018 .ADDRESS $$2
> 00000005 0020 .LONG X^5 ; .LONG 5
> 00000000 0024 .LONG X^0 ; .LONG 0
> 00000000 0028 .LONG X^0 ; .LONG 0
> 00000000 002C .LONG X^0 ; .LONG 0
>
> Source Listing 28-AUG-2007
> 20:51:10 Compaq COBOL V2.8-1286 Page 5
> Compilation Summary 28-AUG-2007
> 20:50:41 DKB100:[PAUL.SRC.COBOL]TEST2.COB;4
>
> COMMAND QUALIFIERS
>
> COBOL
>
> /NOALIGNMENT
> /GRANULARITY = QUAD
> /NOANALYSIS_DATA
> /NOINCLUDE
> /NOANSI_FORMAT /LIST
>
> /ARCHITECTURE = GENERIC
> /MACHINE_CODE
> /ARITHMETIC = NATIVE /NOMAP
>
> /NOAUDIT
> /MATH_INTERMEDIATE = FLOAT
> /CHECK = (NOPERFORM, NOBOUNDS, NODECIMAL, NODUPLICATE_KEYS)
> /NATIONALITY = US
> /NOCONDITIONALS /OBJECT
>
> /NOCONVERT = LEADING_BLANKS
> /OPTIMIZE = (LEVEL=4,TUNE=GENERIC)
> /NOCOPY_LIST
> /RESERVED_WORDS = (XOPEN, NOFOREIGN_EXTENSIONS, NO200X)
> /NOCROSS_REFERENCE
> /NOSEPARATE_COMPILATION
> /DEBUG = (NOSYMBOLS, TRACEBACK)
> /NOSEQUENCE_CHECK
> /NODEPENDENCY_DATA
> /STANDARD = (NOXOPEN, NOSYNTAX, NOV3, 85, NOMIA)
> /NODIAGNOSTICS /NOTIE
>
> /NODISPLAY_FORMATTED
> /NOTRUNCATE
> ...
>
> read more »- Hide quoted text -
>
> - Show quoted text -

> -----Original Message-----
> From: Hein RMS van den Heuvel [mailto:heinvandenheuvel@gmail.com]
> Sent: Tuesday, August 28, 2007 10:40 PM
> To: Info-VAX@Mvb.Saic.Com
> Subject: Re: Itanium Port Question
>
> On Aug 28, 10:04 pm, "Paul Raulerson" wrote:
> > > -----Original Message-----
> > > From: Ron Johnson [mailto:ron.l.john...@cox.net]
> :
> > It did, really. Here's part of the generated code on an Alpha, which
> I am
> > refraining from explaining because perhaps someone more familiar with
> Alpha
> > will explain. (Please? Oddly enough, the generated CODE is
> exactly the
> > same, which gives me reason to pause.
>
> It should. Use the pause to study the code.
> There is NO code generated for line 14,15.
> It's optimized away.
> All you have is program prologue + epilogue.
>

Yeah, I rather thought that is what it did; I wasn't sure though, which is
why I asked. Thanks for explaining that much more clearly.

It did show the alignment generation of the data items, which is what I
quoted up top.


> Toss in a line like:
>
> 16 call "test" using DATA-ITEM-1, DATA-ITEM-2
>
> Now you'll see... line 15 exploding into 10 instructions
> to do the unalignment protection.
>
> :
> LDQ_U R18, -4(R3) ; 000015
> LDQ_U R17, -7(R3)
> MOV -212, R1
> LDA R16, -7(R3)
> INSLH R1, R16, R20
> INSLL R1, R16, R19
> LDQ R23, 48(R2) ; 000002
> LDQ R26, 96(R2) ; 000016
> LDQ R27, 104(R2)
> MOV 2, R25
> MSKLH R18, R16, R18 ; 000015
> MSKLL R17, R16, R17
> LDA R16, -8(R3) ; 000016
> BIS R18, R20, R18 ; 000015
> BIS R17, R19, R17
> STQ_U R18, -4(R3)
> STQ_U R17, -7(R3)
>
> Flip the two fields around to natually align them, or tell the
> compiler to go ahead and alignt and you''l get 2 instuctions:
> :
> MOV -212, R1 ; 000015
> :
> STL R1, -8(R3) ; 000015
> :
>
> So you will NOT get a run time aligment faults in either case.
>
> Personally I would appreciate an informational at compile that that
> this is dumb coding, but that's not available.
>

Ah, that is much like what I expected to see. Much better example.

>
> ps 1... There is rally no strong reason to make a primary key be the
> first field in the record, if that creates any trouble at all. RMS
> will store the primary key as the first bytes for quicker comparesm
> and re-assemble if the records is select later anyway.

Ugh- I usually find it good practice to put the keys at the first of
the record, but then again, I deal a lot with variable length records.

I expect RMS knows what it is doing, but I don't like the idea of it
rearranging data for me.

> ps 2... Rounding records (for indexed files) to be a 'nice' 512 bytes
> or some such make NO sense at all, as RMS has odd sized headers, and
> it likely to compress the data.

Interesting; doesn't it tend to cause a bit of a performance hit, especially
in high transaction environments though?

-Paul

>
> Cheers,
> Hein.
>
>
>
>
>
>
>
> I wonder if someone would post the
> > generated code from an Itanium system please?
> >
> > Anyways- the complete listings are included below the two snippets
> below,
> > for completeness.
> > -Paul
> >
> > This is generated from:
> > 1 IDENTIFICATION DIVISION.
> > 2 PROGRAM-ID. TEST3.
> > 3
> > 4 ENVIRONMENT DIVISION.
> > 5
> > 6 DATA DIVISION.
> > 7 WORKING-STORAGE SECTION.
> > 8 01 TOP-LEVEL.
> > 9 03 DATA-ITEM-1 PIC X(1).
> > 10 03 DATA-ITEM-2 PIC S9(9) COMP.
> > 11
> > 12 PROCEDURE DIVISION.
> > 13 START-PROGRAM.
> > 14 MOVE 'Z' TO DATA-ITEM-1
> > 15 MOVE -212 TO DATA-ITEM-2
> > 16 STOP RUN
> > ..
> > [snip]
> > ..
> >
> > 00000001 0078 .LONG X^1 ; .LONG 1
> > 00000001 007C .LONG X^1 ; .LONG 1
> > 00000000 0080 .LONG X^0 ; .LONG 0
> > 00000004 0088 .ADDRESS TOP-LEVEL+4
> > 00000001 0090 .LONG X^1 ; .LONG 1
> > 00000004 0094 .LONG X^4 ; .LONG 4
> >
> > This is generated from:
> > 1 IDENTIFICATION DIVISION.
> > 2 PROGRAM-ID. TEST2.
> > 3
> > 4 ENVIRONMENT DIVISION.
> > 5
> > 6 DATA DIVISION.
> > 7 WORKING-STORAGE SECTION.
> > 8 01 TOP-LEVEL.
> > 9 03 DATA-ITEM-2 PIC S9(9) COMP.
> > 10 03 DATA-ITEM-1 PIC X(1).
> > 11
> > 12 PROCEDURE DIVISION.
> > 13 START-PROGRAM.
> > 14 MOVE 'Z' TO DATA-ITEM-1
> > 15 MOVE -212 TO DATA-ITEM-2
> > 16 STOP RUN
> > ..
> > [snip]
> > ..
> >
> > 00000004 007C .LONG X^4 ; .LONG 4
> > 20 0080 .ASCII \ \
> >
> > 00000004 0088 .ADDRESS TOP-LEVEL+4
> > 00000001 0090 .LONG X^1 ; .LONG 1
> > 00000001 0094 .LONG X^1 ; .LONG 1
> >
> > ========== Cut here- complete listings included below
> ================
> >
> > TEST2 Source Listing 28-
> AUG-2007
> > 20:51:10 Compaq COBOL V2.8-1286 Page 1
> > 0 28-
> AUG-2007
> > 20:50:41 DKB100:[PAUL.SRC.COBOL]TEST2.COB;4
> >
> > 1 IDENTIFICATION DIVISION.
> > 2 PROGRAM-ID. TEST2.
> > 3
> > 4 ENVIRONMENT DIVISION.
> > 5
> > 6 DATA DIVISION.
> > 7 WORKING-STORAGE SECTION.
> > 8 01 TOP-LEVEL.
> > 9 03 DATA-ITEM-2 PIC S9(9) COMP.
> > 10 03 DATA-ITEM-1 PIC X(1).
> > 11
> > 12 PROCEDURE DIVISION.
> > 13 START-PROGRAM.
> > 14 MOVE 'Z' TO DATA-ITEM-1
> > 15 MOVE -212 TO DATA-ITEM-2
> > 16 STOP RUN
> > 17 .
> >
> > TEST2 Source Listing 28-
> AUG-2007
> > 20:51:10 Compaq COBOL V2.8-1286 Page 2
> > 0 Program Section Summary 28-
> AUG-2007
> > 20:50:41 DKB100:[PAUL.SRC.COBOL]TEST2.COB;4
> >
> > PROGRAM SECTION INDEX
> >
> > Index Name Bytes Alignment
> Attributes
> > ----- ------------------------------- ---------- ---------
> > -------------------------------------------------------------
> > 1 $CODE$ 92 OCTA 4
> PIC
> > CON REL LCL SHR EXE NORD NOWRT NOVEC
> > 2 $LOCAL$ 152 OCTA 4
> NOPIC
> > CON REL LCL NOSHR NOEXE RD WRT NOVEC
> > 3 $LINK$ 96 OCTA 4
> NOPIC
> > CON REL LCL NOSHR NOEXE RD NOWRT NOVEC
> > 7 COB$NAMES_____2 48 OCTA 4
> PIC
> > CON REL LCL NOSHR NOEXE RD WRT NOVEC
> >
> > DIAGNOSTICS SUMMARY
> >
> > Informationals 1 (suppressed)
> > ----------------------
> > Total 1
> >
> > TEST2 Machine Code Listing 28-
> AUG-2007
> > 20:51:10 Compaq COBOL V2.8-1286 Page 3
> > 0 Source Listing 28-
> AUG-2007
> > 20:50:41 DKB100:[PAUL.SRC.COBOL]TEST2.COB;4
> >
> > .PSECT $CODE$, OCTA, PIC, CON, REL,
> LCL,
> > SHR,-
> > EXE, NORD, NOWRT
> > 0000 TEST2::
> > A41B0030 0000 LDQ R0, 48(R27)
> > 23DEFFD0 0004 LDA SP, -48(SP)
> > A61B0038 0008 LDQ R16, 56(R27)
> > 47E03419 000C MOV 1, R25
> > B75E0010 0010 STQ R26, 16(SP)
> > B77E0000 0014 STQ R27, (SP)
> > A75B0050 0018 LDQ R26, 80(R27)
> > B7FE0008 001C STQ R31, 8(SP)
> > B45E0018 0020 STQ R2, 24(SP)
> > B7BE0020 0024 STQ FP, 32(SP)
> > 63FF0000 0028 TRAPB
> > 47FE041D 002C MOV SP, FP
> > 47FB0402 0030 MOV R27, R2
> > B7E0FFC8 0034 STQ R31, -56(R0)
> > A7620058 0038 LDQ R27, 88(R2)
> > B3E00000 003C STL R31, (R0)
> > 6B5A4000 0040 JSR R26, DCOB$CALLED
> > ; R26, R26
> > A4220030 0044 LDQ R1, 48(R2)
> > A7420040 0048 LDQ R26, 64(R2)
> > ; 000016
> > 47FF0419 004C CLR R25
> > A7620048 0050 LDQ R27, 72(R2)
> > B401FFD0 0054 STQ R0, -48(R1)
> > ; 000002
> > 6B5A4000 0058 JSR R26, DCOB$STOP
> > ; R26, R26 ; 000016
> >
> > Routine Size: 92 bytes, Routine Base: $CODE$ + 0000
> >
> > .PSECT $LOCAL$, OCTA, NOPIC, CON,
> REL,
> > LCL,-
> > NOSHR, NOEXE, RD, WRT
> > TOP-LEVEL:
> > 00000000 0000 .LONG X^0 ; .LONG 0
> > 20 0004 .ASCII \ \
> >
> > $$1:
> > 54534554 0020 .ASCII \TEST2\
> > 32 0024
> >
> > RETURN-CODE:
> > 00000001 0028 .LONG X^1 ; .LONG 1
> > $$2:
> > 00000000 0030 .ADDRESS $$3
> > 00000000 0038 .QUAD X^0 ; .QUAD 0
> > 00000000 003C
> > 00000003 0040 .LONG X^3 ; .LONG 3
> > 00000000 0044 .LONG X^0 ; .LONG 0
> > 00000001 0048 .LONG X^1 ; .LONG 1
> > $$3:
> > 00000001 0050 .LONG X^1 ; .LONG 1
> > 00000000 0058 .ADDRESS RETURN-CODE
> > 00000001 0060 .LONG X^1 ; .LONG 1
> > 00000004 0064 .LONG X^4 ; .LONG 4
> > 00000000 0068 .LONG X^0 ; .LONG 0
> > 00000000 0070 .ADDRESS TOP-LEVEL
> > 00000001 0078 .LONG X^1 ; .LONG 1
> >
> > TEST2 Machine Code Listing 28-
> AUG-2007
> > 20:51:10 Compaq COBOL V2.8-1286 Page 4
> > 0 TEST2 28-
> AUG-2007
> > 20:50:41 DKB100:[PAUL.SRC.COBOL]TEST2.COB;4
> >
> > 00000004 007C .LONG X^4 ; .LONG 4
> > 20 0080 .ASCII \ \
> >
> > 00000004 0088 .ADDRESS TOP-LEVEL+4
> > 00000001 0090 .LONG X^1 ; .LONG 1
> > 00000001 0094 .LONG X^1 ; .LONG 1
> >
> > .PSECT $LINK$, OCTA, NOPIC, CON,
> REL, LCL,-
> > NOSHR, NOEXE, RD, NOWRT
> >
> > 0000 ; Stack-Frame invocation descriptor
> > Entry point: TEST2
> > Entry Length: 48
> > Static Handler:
> DCOB$SIGNAL_HANDLER
> > Registers used: R0-R2, R16,
> R25-R26,
> > R28-FP
> > Registers saved: R2, FP
> > Fixed Stack Size: 48
> > 00000000 ; Handler data for
> DCOB$SIGNAL_HANDLER
> > 00000000
> > 00000000
> > 00000000
> >
> > 00000048 0030 .ADDRESS $LOCAL$+72
> > 00000000 0038 .ADDRESS TEST2
> > 0040 .LINKAGE DCOB$STOP
> > 0050 .LINKAGE DCOB$CALLED
> >
> > .PSECT COB$NAMES_____2, OCTA, PIC,
> CON,
> > REL,-
> > LCL, NOSHR, NOEXE, RD, WRT
> > $$4:
> > 00000000 0000 .ADDRESS $$1
> > 00000000 0008 .ADDRESS TEST2
> > 00000000 0010 .QUAD X^0 ; .QUAD 0
> > 00000000 0014
> > 00000000 0018 .ADDRESS $$2
> > 00000005 0020 .LONG X^5 ; .LONG 5
> > 00000000 0024 .LONG X^0 ; .LONG 0
> > 00000000 0028 .LONG X^0 ; .LONG 0
> > 00000000 002C .LONG X^0 ; .LONG 0
> >
> > Source Listing 28-
> AUG-2007
> > 20:51:10 Compaq COBOL V2.8-1286 Page 5
> > Compilation Summary 28-
> AUG-2007
> > 20:50:41 DKB100:[PAUL.SRC.COBOL]TEST2.COB;4
> >
> > COMMAND QUALIFIERS
> >
> > COBOL
> >
> > /NOALIGNMENT
> > /GRANULARITY = QUAD
> > /NOANALYSIS_DATA
> > /NOINCLUDE
> > /NOANSI_FORMAT
> /LIST
> >
> > /ARCHITECTURE = GENERIC
> > /MACHINE_CODE
> > /ARITHMETIC = NATIVE
> /NOMAP
> >
> > /NOAUDIT
> > /MATH_INTERMEDIATE = FLOAT
> > /CHECK = (NOPERFORM, NOBOUNDS, NODECIMAL, NODUPLICATE_KEYS)
> > /NATIONALITY = US
> > /NOCONDITIONALS
> /OBJECT
> >
> > /NOCONVERT = LEADING_BLANKS
> > /OPTIMIZE = (LEVEL=4,TUNE=GENERIC)
> > /NOCOPY_LIST
> > /RESERVED_WORDS = (XOPEN, NOFOREIGN_EXTENSIONS, NO200X)
> > /NOCROSS_REFERENCE
> > /NOSEPARATE_COMPILATION
> > /DEBUG = (NOSYMBOLS, TRACEBACK)
> > /NOSEQUENCE_CHECK
> > /NODEPENDENCY_DATA
> > /STANDARD = (NOXOPEN, NOSYNTAX, NOV3, 85, NOMIA)
> > /NODIAGNOSTICS
> /NOTIE
> >
> > /NODISPLAY_FORMATTED
> > /NOTRUNCATE
> > ...
> >
> > read more ;- Hide quoted text -
> >
> > - Show quoted text -
>

On 08/28/07 22:58, Paul Raulerson wrote:
>
>> -----Original Message-----
>> From: Hein RMS van den Heuvel [mailto:heinvandenheuvel@gmail.com]
>> Sent: Tuesday, August 28, 2007 10:40 PM
>> To: Info-VAX@Mvb.Saic.Com
>> Subject: Re: Itanium Port Question
[snip]
>
>> ps 1... There is rally no strong reason to make a primary key be the
>> first field in the record, if that creates any trouble at all. RMS
>> will store the primary key as the first bytes for quicker comparesm
>> and re-assemble if the records is select later anyway.
>
> Ugh- I usually find it good practice to put the keys at the first of
> the record, but then again, I deal a lot with variable length records.
>
> I expect RMS knows what it is doing, but I don't like the idea of it
> rearranging data for me.
>
>> ps 2... Rounding records (for indexed files) to be a 'nice' 512 bytes
>> or some such make NO sense at all, as RMS has odd sized headers, and
>> it likely to compress the data.
>
> Interesting; doesn't it tend to cause a bit of a performance hit, especially
> in high transaction environments though?

It would if the record lengths grow and change a lot. But simple
(RLE) compression can also help by making your IO more effective.

--
Ron Johnson, Jr.
Jefferson LA USA

Give a man a fish, and he eats for a day.
Hit him with a fish, and he goes away for good!

On Aug 29, 4:47 am, Ron Johnson wrote:
> On 08/28/07 22:58, Paul Raulerson wrote:
> >> From: Hein RMS van den Heuvel

> >> ps 1... There is rally no strong reason to make a primary key be the
> >> first field in the record, if that creates any trouble at all.
:
> > Ugh- I usually find it good practice to put the keys at the first of
> > the record, but then again, I deal a lot with variable length records.

It is a fine and good practice to have the primary key be the first
field, if you have no reason for it to be elsewhere. But if there is
even the slightest reason to have it elsewhere, then just let it be
elsewhere.

That reason could precisely be the natural alignment of things: Don't
let the 9-byte 'Social Security Number' if not already replaced by an
hash for percieved secutiry reason spoil the potential aligment of
fields which migh benefit from that in teh record buffers in the
program.
Or maybe you finally realized that the SSN is a lousy / stupid primary
key and want to relegate it to be an alernate and make the customer
number or lastname/firstname the new primary. No reason to write/
script a converter to flip the fields in the record, just redefine the
keys in the FDL and the Cobol FD sections and convert and rebuild code
base.


>
> > I expect RMS knows what it is doing, but I don't like the idea of it
> > rearranging data for me.

By physicaly storing the primary key up front, rms does not have to
decompress, or at the very least carefully count the rest of the data
to find that primary key. And it will be 'near' the records header
which are looked at just earlier, thus the memory caches/transfer
arrangments might make it slightly quicker bytes to access than bytes
further down in the buffer, possibly on a next page(lette).


> >> ps 2... Rounding records (for indexed files) to be a 'nice' 512 bytes
> >> or some such make NO sense at all, as RMS has odd sized headers, and
> >> it likely to compress the data.
>
> > Interesting; doesn't it tend to cause a bit of a performance hit, especially in high transaction environments though?

What might be a performance hit? The compressing or the non-rounding?
I found RMS compression to ALWAYS be a net CPU AGAIN.
The reason for that is that records are more often (10x) just glanced
at versus being actualy decompressed and moved to a user buffer:
- scanning the bucket for the right target key
- moving records in the bucket to make room for a new or grown record,
or expunge the space which was occupied by a now deleted, or shortened
record

Aligning the end to a 'round number' can not possibly help ever.
It will just create more data to lug around.
The IOs are performed in BUCKETS of multiple 512-byte blocks.
Each bucket had 15 bytes overhead (14 header, 1 tail).
Each record typcially has 9 bytes overhead (flag, length, 6-byte RRV)
So how is a record having an end-user length of 128 or 512 or 1024
going to help RMS? Make 'm as short as possible, but no shorter!
Of course you may want to align the program buffers to receive those
records at nice round numbers, but that's an other story alltogether.

> It would if the record lengths grow and change a lot. But simple
> (RLE) compression can also help by making your IO more effective.

Huh? That fails to compute. Is this in response to (non)rounding?
Please explain.

simple RLE = ??? Record LEngth?
Sorry, but I have no clue what that might mean in RMS context.

My best guess is that it is about actual length versus maximum length.
If variable length records are used then RMS only ever stores the
actual data. It does not pre-reserve the full size and aligning either
would only serve to hurt both as per above.

If actual records lengths grow and change a lot, then you may want to
pre-allocate to the max size, and you may want to disable record-data-
compression or polute the unused space with non-compressing 'not in
use' data contents.

Hope this helps some,
Hein van den Heuvel (at gmail dot com)
HvdH Performance Consulting

On 08/29/07 07:12, Hein RMS van den Heuvel wrote:
[snip]
>
>> It would if the record lengths grow and change a lot. But simple
>> (RLE) compression can also help by making your IO more effective.
>
> Huh? That fails to compute. Is this in response to (non)rounding?
> Please explain.
>
> simple RLE = ??? Record LEngth?
> Sorry, but I have no clue what that might mean in RMS context.

Run-Length Encoding. Replaces a repeated character (25 spaces, for
example, with a repeat-count and the target character).

It means that you transfer less data from host to disk, store less
data on disk, read less data from disk and transfer less from disk
to host. Uses a *slight* amount of CPU to expand the record.

Can be a *BIG* win in insert-once/no-update situations, but a BIG
LOSER when you update a blank field with non-repeating data.

--
Ron Johnson, Jr.
Jefferson LA USA

Give a man a fish, and he eats for a day.
Hit him with a fish, and he goes away for good!

Ron Johnson wrote:
> On 08/26/07 18:48, FrankS wrote:
>
>>On Aug 26, 5:32 pm, Ron Johnson wrote:
>>
>>>Wouldn't alignment faults be more of a problem in Macro than in,
>>>say, COBOL?
>>
>>This is a COBOL alignment fault ...
>>
>>01 TOP-LEVEL.
>> 03 DATA-ITEM-1 PIC X(1).
>> 03 DATA-ITEM-2 PIC S9(9) COMP.
>>
>>Data-Item-2 is not on a natural boundary. This likely happens in lots
>>and lots of places in many COBOL programs. I'm sure there's a ton of
>>similar problems in programs I and many others have written over the
>>years.
>
>
> You'd think that something as complex as a COBOL compiler would
> already align TOP-LEVEL.
>

The COBOL compiler aligns 01 and 77 level items on quadword boundaries
by default. It is only the alignment/padding of other level items that
defaults to VAX byte alignment. You can ask for more alignment and
padding with the /ALIGNMENT qualifier.

--
John Reagan
OpenVMS Pascal/Macro-32/COBOL Project Leader
Hewlett-Packard Company