Itanium Port Question - VMS

This is a discussion on Itanium Port Question - VMS ; On Wed, 29 Aug 2007 07:19:41 -0700, John Reagan wrote: > 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 ...

+ Reply to Thread
Page 3 of 4 FirstFirst 1 2 3 4 LastLast
Results 41 to 60 of 62

Thread: Itanium Port Question

  1. Re: Itanium Port Question

    On Wed, 29 Aug 2007 07:19:41 -0700, John Reagan wrote:

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

    The same is true for PL/I. Of course, you probably don't want to change
    existing
    code that does record I/O


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

  2. Re: Itanium Port Question

    Paul Raulerson wrote:

    > same, which gives me reason to pause. I wonder if someone would post the
    > generated code from an Itanium system please?
    >


    Here it is with the CALL statement recommended by Hein to prevent the
    optimizer from evaporating the MOVEs.

    The 'st1' for the MOVE on line 12 is at offset 00E0. For the MOVE on
    line 13, you'll find a sequence scattered in the code that is:

    00A03A200180 0082 tbit.z pr6, pr7 = r34, 0
    0108022008C0 0090 mov r35 = r34
    00AC02348047 00A0 (pr7) st1 [r35] = r36, 1
    00A5BA420907 00B1 (pr7) shr.u r36 = r36, 8
    00AC42348080 00C0 st2 [r35] = r36, 2

    00A57A440900 00C1 shr.u r36 = r36, 16 ;;
    008C42348006 00D0 (pr6) st2 [r35] = r36

    008C02348007 00D1 (pr7) st1 [r35] = r36

    Apparently, the compiler knew it COULD be unaligned, but for some reason
    it didn't realize it ALWAYS was unaligned. I think it should. I'll put
    that on our code-quality list.

    Anyway, the tbit tests the bottom bit the address to pick of
    byte-aligned data. If byte aligned, we'll do a st1,st2,st1 sequence.
    If not byte aligned, we'll do the st2,st2 seqeunce.

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

    .psect $CODE$, CON, LCL, SHR,
    EXE, NOWRT, NOVEC, NOSHORT
    .proc TEST3
    .align 32
    .global TEST3
    .personality DCOB$SIGNAL_HANDLER
    .handlerdata 8
    TEST3:
    // 000002
    { .mii
    002C00B1AA40 0000 alloc r41 = rspfs, 0, 11, 2, 0
    0119F8CE0300 0001 adds sp = -16, sp
    // r12 = -16, r12
    010800100A80 0002 mov r42 = gp ;;
    // r42 = r1
    }
    { .mib
    010800C30080 0010 adds r2 = 24, sp
    // r2 = 24, r12
    000188000A00 0011 mov r40 = rp
    // r40 = br0
    004000000000 0012 nop.b 0 ;;
    }
    { .mii
    008CC0200000 0020 st8 [r2] = r0
    012000100200 0021 add r8 = @ltoffx($LOCAL$), gp
    // r8 = @ltoffx($LOCAL$), r1
    012000100800 0022 add r32 = @ltoffx($LOCAL$), gp
    // r32 = @ltoffx($LOCAL$), r1
    }
    { .mmi
    012000100AC0 0030 add out0 =
    @ltoff(@fptr(TEST3)), // r43 = @ltoff(@fptr(TEST3)), r1
    gp ;;
    0080C0800200 0031 ld8.mov r8 = [r8], $LOCAL$
    012000002640 0032 mov ai = 1
    // r25 = 1
    }
    { .mmi
    0080C2000800 0040 ld8.mov r32 = [r32], $LOCAL$ ;;
    0080C2B00AC0 0041 ld8 out0 = TEST3
    // r43 = [r43]
    000008000000 0042 nop.i 0 ;;
    }
    { .mii
    010800860200 0050 adds r8 = 48, r8
    010802040800 0051 adds r32 = 32, r32
    000008000000 0052 nop.i 0 ;;
    }
    { .mmb
    008CC0800000 0060 st8 $LOCAL$ = r0
    // [r8] = r0
    008C82000000 0061 st4 [r32] = r0
    00A000001000 0062 br.call.sptk.many rp = DCOB$CALLED
    ;; // br0 = DCOB$CALLED
    }
    { .mii
    0119FA0C2880 0070 adds r34 = -31, r32
    // 000013
    0119F0058840 0071 adds r33 = -212, r0
    010802A00040 0072 mov gp = r42
    // r1 = r42 // 000002
    }
    { .mmi
    0120000B4980 0080 mov r38 = 90 ;;
    // 000012
    010802100900 0081 mov r36 = r33
    // 000013
    00A03A200180 0082 tbit.z pr6, pr7 = r34, 0
    }
    { .mii
    0108022008C0 0090 mov r35 = r34
    012000100940 0091 add r37 = @ltoffx($LOCAL$), gp
    ;; // r37 = @ltoffx($LOCAL$), r1 // 000002
    0119FA0C00C0 0092 adds r3 = -32, r32
    // 000014
    }
    { .mii
    00AC02348047 00A0 (pr7) st1 [r35] = r36, 1
    // 000013
    0119FA0C09C0 00A1 adds r39 = -32, r32
    // 000012
    012000004640 00A2 mov ai = 2 ;;
    // r25 = 2 // 000014
    }
    { .mii
    0080C2500940 00B0 ld8.mov r37 = [r37], $LOCAL$
    // 000002
    00A5BA420907 00B1 (pr7) shr.u r36 = r36, 8
    // 000013
    010800300AC0 00B2 mov out0 = r3 ;;
    // r43 = r3 // 000014
    }
    { .mii
    00AC42348080 00C0 st2 [r35] = r36, 2
    // 000013
    00A57A440900 00C1 shr.u r36 = r36, 16 ;;
    010802570940 00C2 adds r37 = 56, r37 ;;
    // 000002
    }
    { .mmi
    008C42348006 00D0 (pr6) st2 [r35] = r36
    // 000013
    008C02348007 00D1 (pr7) st1 [r35] = r36
    0119FA0C0800 00D2 adds r32 = -32, r32 ;;
    // 000012
    }
    { .mmi
    00AC0204C040 00E0 st1 [r32] = r38, 1
    008CC2510000 00E1 st8 $LOCAL$ = r8
    // [r37] = r8 // 000002
    000008000000 00E2 nop.i 0 ;;
    }
    { .mfb
    010802000B00 00F0 mov out1 = r32
    // r44 = r32 // 000014
    000008000000 00F1 nop.f 0
    00A000001000 00F2 br.call.sptk.many rp = TEST ;;
    // br0 = TEST
    }
    { .mii
    012000000640 0100 mov ai = 0
    // r25 = 0 // 000015
    010802A00040 0101 mov gp = r42
    // r1 = r42 // 000014
    000008000000 0102 nop.i 0 ;;
    }

    { .mfb
    000008000000 0110 nop.m 0
    000008000000 0111 nop.f 0
    00A000001000 0112 br.call.sptk.many rp = DCOB$STOP
    ;; // br0 = DCOB$STOP // 000015
    }
    { .mfi
    010802A00040 0120 mov gp = r42
    // r1 = r42
    000008000000 0121 nop.f 0
    000008000000 0122 nop.i 0 ;;
    }
    .endp TEST3

  3. Re: Itanium Port Question

    In article ,
    John Reagan writes:
    > 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,
    As the guy responsible for the Pascal compiler and because playing with
    Pascal compilers is how I spend my freetime :-) how about answering a
    quick question for me.

    How does the PACKED effect all of this alignment stuff? Does the
    Pascal compiler take care of alignment? And, does using PACKED have
    any adverse effect on all this?

    bill


    --
    Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
    bill@cs.scranton.edu | and a sheep voting on what's for dinner.
    University of Scranton |
    Scranton, Pennsylvania | #include

  4. Re: Itanium Port Question

    On 08/29/07 09:41, Tom Linden wrote:
    > On Wed, 29 Aug 2007 07:19:41 -0700, John Reagan wrote:
    >
    >> 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.
    >>

    > The same is true for PL/I. Of course, you probably don't want to change
    > existing
    > code that does record I/O


    Hmmm. So it does a single "structure copy" instead of knowing that
    the fields are (not-byte)-aligned and thus moving the fields
    individually into a temp buffer before doing record IO.

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

  5. Re: Itanium Port Question

    On Wed, 29 Aug 2007 09:17:22 -0700, Ron Johnson
    wrote:

    > On 08/29/07 09:41, Tom Linden wrote:
    >> On Wed, 29 Aug 2007 07:19:41 -0700, John Reagan
    >> wrote:
    >>
    >>> 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.
    >>>

    >> The same is true for PL/I. Of course, you probably don't want to change
    >> existing
    >> code that does record I/O

    >
    > Hmmm. So it does a single "structure copy" instead of knowing that
    > the fields are (not-byte)-aligned and thus moving the fields
    > individually into a temp buffer before doing record IO.
    >

    Maybe I am not understanding you, but if the shape is the same in memory as
    external storage why would you need a temporary?


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

  6. Re: Itanium Port Question

    Bill Gunshannon wrote:

    > John,
    > As the guy responsible for the Pascal compiler and because playing with
    > Pascal compilers is how I spend my freetime :-) how about answering a
    > quick question for me.
    >
    > How does the PACKED effect all of this alignment stuff? Does the
    > Pascal compiler take care of alignment? And, does using PACKED have
    > any adverse effect on all this?
    >
    > bill
    >
    >


    PACKED tells Pascal to squish types even tighter. So BOOLEANs are
    1-bit, subranges, enumerated types, sets, etc. take exactly the number
    of bits needed.

    [We can have the tangent thread of exactly how many bits are need to
    represent 1..1 for instance - it would related back to the undefined
    state discussion we had last week or so. Hint: 0. However the compiler
    actually would allocate 1 bit since we didn't want to really confuse
    things - plus nobody writes 1..1 anyway].

    So something like:

    type
    pr = packed record
    f1 : boolean;
    f2 : 0..65535;
    end;

    f1 is one bit big and starts at the beginning of the record. f2 is
    16-bits big and is 1-bit from the beginning (allocated immediately after
    f1). In PACKED records, fields 32-bits or smaller are shoved right next
    to the prior field (integers, reals, other arrays/records). Larger than
    32-bits are bumped to the next byte-boundary.

    Like the previous replies, since the compiler knows that fields are very
    unaligned (and in some cases not even on byte-boundaries anymore), it
    will require lots of instructions to fetch,increment,store the word
    subrange field for instance. However, no alignment faults should occur.

    Pascal's /SHOW=STRUCTURE_LAYOUT and /USAGE=PERFORMANCE can show lots of
    stuff. Also, see Appendix A.2, "Storage Allocation" in the Pascal RM.

    $ pascal/list/show=(struct)/usage=perform x

    f1 : boolean;
    ...........^
    %PASCAL-I-COMNOTSIZ, Component is not optimally sized
    at line number 4 in file HIYALL$:[REAGAN]X.PAS;8

    f2 : 0..65535;
    ...........^
    %PASCAL-I-COMNOTALNSIZ, Component is not optimally aligned and sized
    at line number 5 in file HIYALL$:[REAGAN]X.PAS;8
    %PASCAL-S-ENDDIAGS, PASCAL completed with 2 diagnostics




    Structure Layout Listing
    29-AUG-2007 13:45:06 HP Pascal Alpha V6.0-115 Page 2

    29-AUG-2007 13:42:03 HIYALL$:[REAGAN]X.PAS;8


    Comments Offset Size
    ----------- --------------- ---------------
    3 Bytes PR {In PROGRAM FOO} =
    PACKED RECORD
    Size 0 Bytes 1 Bit F1 : BOOLEAN
    Align; Size 1 Bit 2 Bytes F2 : 0..65535
    END



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

  7. Re: Itanium Port Question

    In article ,
    John Reagan writes:
    > Bill Gunshannon wrote:
    >
    >> John,
    >> As the guy responsible for the Pascal compiler and because playing with
    >> Pascal compilers is how I spend my freetime :-) how about answering a
    >> quick question for me.
    >>
    >> How does the PACKED effect all of this alignment stuff? Does the
    >> Pascal compiler take care of alignment? And, does using PACKED have
    >> any adverse effect on all this?
    >>

    >
    > PACKED tells Pascal to squish types even tighter. So BOOLEANs are
    > 1-bit, subranges, enumerated types, sets, etc. take exactly the number
    > of bits needed.
    >

    <....>


    Thank you very much. Any day I learn something new is a good day.

    bill

    --
    Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
    bill@cs.scranton.edu | and a sheep voting on what's for dinner.
    University of Scranton |
    Scranton, Pennsylvania | #include

  8. Re: Itanium Port Question

    On 08/29/07 12:21, Tom Linden wrote:
    > On Wed, 29 Aug 2007 09:17:22 -0700, Ron Johnson
    > wrote:
    >
    >> On 08/29/07 09:41, Tom Linden wrote:
    >>> On Wed, 29 Aug 2007 07:19:41 -0700, John Reagan
    >>> wrote:
    >>>
    >>>> 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.
    >>>>
    >>> The same is true for PL/I. Of course, you probably don't want to change
    >>> existing
    >>> code that does record I/O

    >>
    >> Hmmm. So it does a single "structure copy" instead of knowing that
    >> the fields are (not-byte)-aligned and thus moving the fields
    >> individually into a temp buffer before doing record IO.
    >>

    > Maybe I am not understanding you, but if the shape is the same in memory as
    > external storage why would you need a temporary?


    If the compiler pads/aligns the members of the structure.

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

  9. Re: Itanium Port Question

    On Aug 29, 10:08 am, Ron Johnson wrote:
    > On 08/29/07 07:12, Hein RMS van den Heuvel wrote:
    >> Run-Length Encoding. Replaces a repeated character (25 spaces, for

    > example, with a repeat-count and the target character).


    Ah, yes. That's what RMS does, and the only thing RMS does, for what
    it calls adta_record_compression. It divides records into chunks. Each
    chunk has a 16 bit length. The last byte is a repeat count for the
    last character.
    So there is a 3 byte overhead, and the max repeat is 255 chars.
    The scan algortime just looks for 16 bits (aligned?) matching the next
    16 and on match looks backward a few bytes and of course forward.
    So it might fail to trigger on some series of 6 equal bytes. Just as
    well?

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


    Agreed.

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


    Ayup!

    Hein.


  10. Re: Itanium Port Question

    On 08/29/07 14:18, Hein RMS van den Heuvel wrote:
    > On Aug 29, 10:08 am, Ron Johnson wrote:
    >> On 08/29/07 07:12, Hein RMS van den Heuvel wrote:
    >>> Run-Length Encoding. Replaces a repeated character (25 spaces, for

    >> example, with a repeat-count and the target character).

    >
    > Ah, yes. That's what RMS does, and the only thing RMS does, for what
    > it calls adta_record_compression. It divides records into chunks. Each
    > chunk has a 16 bit length. The last byte is a repeat count for the
    > last character.
    > So there is a 3 byte overhead, and the max repeat is 255 chars.
    > The scan algortime just looks for 16 bits (aligned?) matching the next
    > 16 and on match looks backward a few bytes and of course forward.
    > So it might fail to trigger on some series of 6 equal bytes. Just as
    > well?
    >>
    >> 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.

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

    >
    > Ayup!


    If RMS and Rdb don't use the exact same code, I'll be stunned.

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

  11. Re: Itanium Port Question

    Ron Johnson wrote:

    > If RMS and Rdb don't use the exact same code, I'll be stunned.
    >


    The same code for *what* ?
    Rdb does a hell of a lot more then RMS...

    Jan-Erik.

  12. Re: Itanium Port Question

    On 08/29/07 15:07, Jan-Erik Söderholm wrote:
    > Ron Johnson wrote:
    >
    >> If RMS and Rdb don't use the exact same code, I'll be stunned.
    >>

    >
    > The same code for *what* ?


    RLE-compressing duplicate data in fields.

    > Rdb does a hell of a lot more then RMS...


    You're confusing me with Paul Raulerson.

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

  13. Re: Itanium Port Question

    On Wed, 29 Aug 2007 11:46:37 -0700, Ron Johnson
    wrote:

    > On 08/29/07 12:21, Tom Linden wrote:
    >> On Wed, 29 Aug 2007 09:17:22 -0700, Ron Johnson
    >> wrote:
    >>
    >>> On 08/29/07 09:41, Tom Linden wrote:
    >>>> On Wed, 29 Aug 2007 07:19:41 -0700, John Reagan
    >>>> wrote:
    >>>>
    >>>>> 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.
    >>>>>
    >>>> The same is true for PL/I. Of course, you probably don't want to
    >>>> change
    >>>> existing
    >>>> code that does record I/O
    >>>
    >>> Hmmm. So it does a single "structure copy" instead of knowing that
    >>> the fields are (not-byte)-aligned and thus moving the fields
    >>> individually into a temp buffer before doing record IO.
    >>>

    >> Maybe I am not understanding you, but if the shape is the same in
    >> memory as
    >> external storage why would you need a temporary?

    >
    > If the compiler pads/aligns the members of the structure.
    >


    You get to choose
    PLI

    /ALIGN[=option]

    /NOALIGN (D)

    Controls alignment of data within structures and aligned bit
    strings. If you specify /ALIGN on a VAX system, data is aligned on
    the natural byte boundary of the specified data type. If you
    specify /NOALIGN, the default, data is aligned on the next
    available byte boundary.

    (OpenVMS AXP only)

    /[NO]ALIGN[=(PACKED|NATURAL)]

    If you specify /ALIGN=NATURAL, data is aligned on the natural byte
    boundary of the specified data type. If you specify /ALIGN=PACKED,
    data is aligned on the next available byte boundary. On OpenVMS
    AXP, /ALIGN=PACKED forces data to be aligned on the next available
    byte boundary. Data structures will be aligned in the same manner
    as on a OpenVMS VAX System. Requesting /DATA=VAX will cause
    /ALIGN=PACKED to be selected. Specifying /ALIGN with no option is
    equivalent to specifying /ALIGN=NATURAL.



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

  14. Re: Itanium Port Question

    On Aug 29, 4:53 pm, Ron Johnson wrote:
    > > Rdb does a hell of a lot more then RMS...

    >
    > You're confusing me with Paul Raulerson.


    ROTFLOLAP (Rolling on the floor laughing out loud and peeing).

    That was funny.

    :-)


  15. RE: Itanium Port Question



    > -----Original Message-----
    > From: Ron Johnson [mailto:ron.l.johnson@cox.net]
    > Sent: Wednesday, August 29, 2007 3:54 PM
    > To: Info-VAX@Mvb.Saic.Com
    > Subject: Re: Itanium Port Question
    >
    > On 08/29/07 15:07, Jan-Erik Söderholm wrote:
    > > Ron Johnson wrote:
    > >
    > >> If RMS and Rdb don't use the exact same code, I'll be stunned.
    > >>

    > >
    > > The same code for *what* ?

    >
    > RLE-compressing duplicate data in fields.
    >
    > > Rdb does a hell of a lot more then RMS...

    >
    > You're confusing me with Paul Raulerson.
    >


    Not me Ron - your on your own. -Paul
    > --
    > 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!



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

    P. Sture wrote:

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


    Yes Derek C., from Eire And Helen F. from Scotland. Both colleagues at
    the same job but not concurrently.


    --
    Cheers - Dave

  17. Re: Itanium Port Question

    John Reagan wrote:
    > 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.
    >


    I would like to point out that all this stuff about alignment faults has
    *absolutely nothing* to do with the OP's question.

    Randy, if you're still reading... I'll throw in my 2 cents worth a little
    later in the thread if no one else has said anything.

    (Not to disparage John Reagan or anyone else, but this is a classic
    example of thread drift :-)


    --
    John Santos
    Evans Griffiths & Hart, Inc.
    781-861-0670 ext 539

  18. Re: Itanium Port Question

    Ron Johnson wrote:
    > On 08/29/07 15:07, Jan-Erik Söderholm wrote:
    >> Ron Johnson wrote:
    >>
    >>> If RMS and Rdb don't use the exact same code, I'll be stunned.
    >>>

    >> The same code for *what* ?

    >
    > RLE-compressing duplicate data in fields.


    Rdb RLE-compression only compresses "space" characters.
    Like empty white-space at the end of an address field
    or something similar.

    I read the description of RMS RLE-compression here earlier
    that it does RLE-compression on any character (byte).

    Jan-Erik.

  19. Re: Itanium Port Question

    On 08/30/07 01:50, Jan-Erik Söderholm wrote:
    > Ron Johnson wrote:
    >> On 08/29/07 15:07, Jan-Erik Söderholm wrote:
    >>> Ron Johnson wrote:
    >>>
    >>>> If RMS and Rdb don't use the exact same code, I'll be stunned.
    >>>>
    >>> The same code for *what* ?

    >>
    >> RLE-compressing duplicate data in fields.

    >
    > Rdb RLE-compression only compresses "space" characters.
    > Like empty white-space at the end of an address field
    > or something similar.
    >
    > I read the description of RMS RLE-compression here earlier
    > that it does RLE-compression on any character (byte).


    Well, it *has* been a while since I went to an Rdb Internals class.
    But I'd have sworn that it encoded any repeating characters.

    Maybe I'm confusing it with sorted index prefix compression, though.

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

    John Santos wrote:
    > John Reagan wrote:
    >
    >> 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.
    >>

    >
    > I would like to point out that all this stuff about alignment faults has
    > *absolutely nothing* to do with the OP's question.
    >
    > Randy, if you're still reading... I'll throw in my 2 cents worth a little
    > later in the thread if no one else has said anything.
    >
    > (Not to disparage John Reagan or anyone else, but this is a classic
    > example of thread drift :-)
    >
    >


    c.o.v. is classic example! I won't try to classify it further! ;-)


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