Itanium Port Question - VMS

This is a discussion on Itanium Port Question - VMS ; 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 ...

+ Reply to Thread
Page 2 of 4 FirstFirst 1 2 3 4 LastLast
Results 21 to 40 of 62

Thread: Itanium Port Question

  1. Re: Itanium Port Question

    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.




  2. Re: Itanium Port Question

    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


  3. Re: Itanium Port Question

    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).


  4. Re: Itanium Port Question

    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.
    >




  5. Re: Itanium Port Question

    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.


  6. Re: Itanium Port Question

    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.


  7. Re: Itanium Port Question

    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

  8. Re: Itanium Port Question

    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

  9. What'd you do in the war Grand-dad? (was Re: Itanium Port Question)

    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




  10. Re: What'd you do in the war Grand-dad? (was Re: Itanium Port Question)

    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

  11. 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.

    --
    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!

  12. Re: Itanium Port Question

    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

  13. Re: Itanium Port Question

    "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.


  14. RE: Itanium Port Question



    > -----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.






  15. 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.

    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 -




  16. RE: Itanium Port Question



    > -----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 -

    >




  17. Re: Itanium Port Question

    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!

  18. Re: Itanium Port Question

    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


  19. Re: Itanium Port Question

    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!

  20. Re: Itanium Port Question

    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

+ Reply to Thread
Page 2 of 4 FirstFirst 1 2 3 4 LastLast