1 INFO-VAX	Sun, 08 Apr 2001	Volume 2001 : Issue 197       Contents:2 Re: Flipping from big-endian to little endian in C2 Re: Flipping from big-endian to little endian in C2 RE: Flipping from big-endian to little endian in C2 RE: Flipping from big-endian to little endian in C2 RE: Flipping from big-endian to little endian in C2 RE: Flipping from big-endian to little endian in C2 RE: Flipping from big-endian to little endian in C2 RE: Flipping from big-endian to little endian in C2 RE: Flipping from big-endian to little endian in C2 RE: Flipping from big-endian to little endian in C( Re: London, England Technical Update Day3 Re: Q: Converting a VAX 6000-420 to a VAX 6000-620? 3 Re: Q: Converting a VAX 6000-420 to a VAX 6000-620? 3 Re: Q: Converting a VAX 6000-420 to a VAX 6000-620? 3 Re: Q: Converting a VAX 6000-420 to a VAX 6000-620?  Re: sys$io_performw  Re: sys$io_performw  Re: sys$io_performw   Re: THE EMC Chronicles - revised Re: VMS-Related: Affordable  Re: VMS-Related: Affordable   F ----------------------------------------------------------------------   Date: 8 Apr 2001 00:14 PDT) From: rankin@eql.caltech.edu (Pat Rankin) ; Subject: Re: Flipping from big-endian to little endian in C . Message-ID: <8APR200100143264@eql.caltech.edu>  - In article <3ACFD3F2.6F5428A6@videotron.ca>,\ 2  JF Mezei <jfmezei.spamnot@videotron.ca> writes... > Pat Rankin wrote: & >>   for (i = 0; i < 2*4800; i += 2) { >>     outbuf[i+1] = inbuf[i]; >>     outbuf[i] = inbuf[i+1]; >>   } >>G >> (You might be tempted to use i++ or ++i in that loop.  Don't do it.)  >  > why not ?   =      Because you'll end up with undefined behavior, and if it = happens to behave the way you want, you'll falsely think that : any other compiler which handles it differently is broken.= The FAQ posting in comp.lang.c covers this fairly well in the  section on expressions.   @ > Also, is there something magic in the above that preserves the< > value of the second byte so it can be moved to the first ?  >      No magic is needed if the output buffer you're writing to< is different from the input buffer you're reading from.  You: snipped off that part of my post from the bit quoted here.> Updating the data in place is probably going to be slower than using two buffers.   > I was thinking of :  >  > ptr1 = inbuff ;  > ptr2 = ptr1 + 1 ;  > ptr3 = ptr1 + 9600 ; >  > while (ptr1 < ptr3)  >    { x = *ptr2 ; >      *ptr2 = *ptr1 ; >      *ptr1 = x;  >      ptr2 = ptr2 + 2 ; >	ptr1 = ptr1 + 2 ;  >    } > E > The compiler would surely put "x" in a register and you only have 2 G > additions to perform. In your example, would the compiler see the two + > "[i+1]" and do that operation only once ?   @      CC/List/Machine_Code will show exactly what the compiler isA going to do.  The loop in my version ends up being 5 instructions : (This is trimmed a bit to remove some extraneous columns.)  #   for (i = 0; i < 2*4800; i += 2) { 2                           0002          clrl    r08                           0004          movl    8(ap),r28                           0008          movl    4(ap),r1)                           000C  noname.3:      outbuf[i+1] = inbuf[i]; B                           000C          movb    (r1)[r0],1(r2)[r0]     outbuf[i] = inbuf[i+1]; B                           0012          movb    1(r1)[r0],(r2)[r0]   } 5                           0018          addl2   #2,r0 8                           001B          cmpl    r0,#96008                           0022          blss    noname.3  @ Note that both of the i+1's have been subsumed by the addressing= mode used.  Your loop ends up with an extra movb and an extra > addl2, but its three move intructions use a simpler addressing> mode so it wouldn't necessarily run slower.  You'll need to do) some benchmark testing to determine that.   2                 Pat Rankin, rankin@eql.caltech.edu   ------------------------------  % Date: Sun, 08 Apr 2001 05:45:45 -0400 - From: JF Mezei <jfmezei.spamnot@videotron.ca> ; Subject: Re: Flipping from big-endian to little endian in C , Message-ID: <3AD03348.F42B3DEE@videotron.ca>   Pat Rankin wrote: ( > >>   for (i = 0; i < 2*4800; i += 2) {  > >>     outbuf[i+1] = inbuf[i];  > >>     outbuf[i] = inbuf[i+1];@ >      No magic is needed if the output buffer you're writing to9 > is different from the input buffer you're reading from.   I Mea culpa. You're right. Thanks. Will give that a try. I have to generate N about 200 vectors out of 100 megs of data on a microvax 3100-30 so getting the1 program right may save a few hours of processing.    ------------------------------  % Date: Sun, 08 Apr 2001 08:08:02 -0700 ! From: Tom Linden <tom@kednos.com> ; Subject: RE: Flipping from big-endian to little endian in C 9 Message-ID: <CIEJLCMNHNNDLLOOGNJICEJICFAA.tom@kednos.com>   L Sorry about that post, it is obviously wrong.  I think my brain took the day off yesterday.     > -----Original Message-----* > From: Tom Linden [mailto:tom@KEDNOS.COM]( > Sent: Saturday, April 07, 2001 7:59 PM > To: Info-VAX@Mvb.Saic.Com = > Subject: RE: Flipping from big-endian to little endian in C  >  > ; > That won't work.  You need to reverse the entire 16 bits.  >  > > -----Original Message-----4 > > From: Pat Rankin [mailto:rankin@eql.caltech.edu]* > > Sent: Saturday, April 07, 2001 7:34 PM > > To: Info-VAX@Mvb.Saic.Com ? > > Subject: Re: Flipping from big-endian to little endian in C  > >  > > 1 > > In article <3ACED07F.4CA8A637@videotron.ca>,\ 6 > >  JF Mezei <jfmezei.spamnot@videotron.ca> writes...H > > > I have to read a rather large amount of binary data (2 byte signed> > > > integers) in C. The data is stored as big-endian shorts. > > > L > > > If I have a entire row of 4800 big-endian signed shorts in consecutiveL > > > memory, what would be the most efficient to flip all of them to litte-) > > > endian ? (VAX architecture, DEC-C).  > > F > >      I would copy them into a separate array rather than swap themE > > in place.  Use pointers to unsigned char (rather than short) with  > > ' > >   for (i = 0; i < 2*4800; i += 2) {  > >     outbuf[i+1] = inbuf[i];  > >     outbuf[i] = inbuf[i+1];  > >   }  > > H > > (You might be tempted to use i++ or ++i in that loop.  Don't do it.) > > F > >      For Alpha the answer might be different; cache considerationsG > > are more likely to apply and shifting and masking four 16-bit units $ > > at a time could perhaps pay off. > > 6 > > > And while I am at it, a question on descriptors: > > > - > > > I used to declare descriptors such as : : > > > $DESCRIPTOR(my_time_desc,"dd-mmm-yyyy hh:mm:ss.mm"); > > > K > > > and in the program, my_time_desc.dsc$a_pointer was filled with actual L > > > data. However, since DEC-C, the default ahs been to made the string inL > > > $DESCRIPTOR in non-writable memory, causing access violations when you > > > try to write it. > > F > >      Such behavior is sanctioned by the C standard, and it usuallyA > > is a good thing.  The compiler has a qualifier to get the old ( > > behavior back if you really need it. > > - > > > I have since change my programs to have  > > >	char my_time_char[25];. > > >	$DESCRIPTOP(my_time_desc,my_time_char) ; > > > Is there a better way ?  > > 1 > >      Let the compiler do the length counting.  > > B > >        static char my_time_char[] = "dd-mmm-yyyy hh:mm:ss.mm";3 > >        $DESCRIPTOR(my_time_desc, my_time_char);  > > 6 > >                 Pat Rankin, rankin@eql.caltech.edu   ------------------------------  % Date: Sun, 08 Apr 2001 08:08:02 -0700 ! From: Tom Linden <tom@kednos.com> ; Subject: RE: Flipping from big-endian to little endian in C 9 Message-ID: <CIEJLCMNHNNDLLOOGNJICEJICFAA.tom@kednos.com>   L Sorry about that post, it is obviously wrong.  I think my brain took the day off yesterday.     > -----Original Message-----* > From: Tom Linden [mailto:tom@KEDNOS.COM]( > Sent: Saturday, April 07, 2001 7:59 PM > To: Info-VAX@Mvb.Saic.Com = > Subject: RE: Flipping from big-endian to little endian in C  >  > ; > That won't work.  You need to reverse the entire 16 bits.  >  > > -----Original Message-----4 > > From: Pat Rankin [mailto:rankin@eql.caltech.edu]* > > Sent: Saturday, April 07, 2001 7:34 PM > > To: Info-VAX@Mvb.Saic.Com ? > > Subject: Re: Flipping from big-endian to little endian in C  > >  > > 1 > > In article <3ACED07F.4CA8A637@videotron.ca>,\ 6 > >  JF Mezei <jfmezei.spamnot@videotron.ca> writes...H > > > I have to read a rather large amount of binary data (2 byte signed> > > > integers) in C. The data is stored as big-endian shorts. > > > L > > > If I have a entire row of 4800 big-endian signed shorts in consecutiveL > > > memory, what would be the most efficient to flip all of them to litte-) > > > endian ? (VAX architecture, DEC-C).  > > F > >      I would copy them into a separate array rather than swap themE > > in place.  Use pointers to unsigned char (rather than short) with  > > ' > >   for (i = 0; i < 2*4800; i += 2) {  > >     outbuf[i+1] = inbuf[i];  > >     outbuf[i] = inbuf[i+1];  > >   }  > > H > > (You might be tempted to use i++ or ++i in that loop.  Don't do it.) > > F > >      For Alpha the answer might be different; cache considerationsG > > are more likely to apply and shifting and masking four 16-bit units $ > > at a time could perhaps pay off. > > 6 > > > And while I am at it, a question on descriptors: > > > - > > > I used to declare descriptors such as : : > > > $DESCRIPTOR(my_time_desc,"dd-mmm-yyyy hh:mm:ss.mm"); > > > K > > > and in the program, my_time_desc.dsc$a_pointer was filled with actual L > > > data. However, since DEC-C, the default ahs been to made the string inL > > > $DESCRIPTOR in non-writable memory, causing access violations when you > > > try to write it. > > F > >      Such behavior is sanctioned by the C standard, and it usuallyA > > is a good thing.  The compiler has a qualifier to get the old ( > > behavior back if you really need it. > > - > > > I have since change my programs to have  > > >	char my_time_char[25];. > > >	$DESCRIPTOP(my_time_desc,my_time_char) ; > > > Is there a better way ?  > > 1 > >      Let the compiler do the length counting.  > > B > >        static char my_time_char[] = "dd-mmm-yyyy hh:mm:ss.mm";3 > >        $DESCRIPTOR(my_time_desc, my_time_char);  > > 6 > >                 Pat Rankin, rankin@eql.caltech.edu   ------------------------------  % Date: Sun, 08 Apr 2001 08:08:02 -0700 ! From: Tom Linden <tom@kednos.com> ; Subject: RE: Flipping from big-endian to little endian in C 9 Message-ID: <CIEJLCMNHNNDLLOOGNJICEJICFAA.tom@kednos.com>   L Sorry about that post, it is obviously wrong.  I think my brain took the day off yesterday.     > -----Original Message-----* > From: Tom Linden [mailto:tom@KEDNOS.COM]( > Sent: Saturday, April 07, 2001 7:59 PM > To: Info-VAX@Mvb.Saic.Com = > Subject: RE: Flipping from big-endian to little endian in C  >  > ; > That won't work.  You need to reverse the entire 16 bits.  >  > > -----Original Message-----4 > > From: Pat Rankin [mailto:rankin@eql.caltech.edu]* > > Sent: Saturday, April 07, 2001 7:34 PM > > To: Info-VAX@Mvb.Saic.Com ? > > Subject: Re: Flipping from big-endian to little endian in C  > >  > > 1 > > In article <3ACED07F.4CA8A637@videotron.ca>,\ 6 > >  JF Mezei <jfmezei.spamnot@videotron.ca> writes...H > > > I have to read a rather large amount of binary data (2 byte signed> > > > integers) in C. The data is stored as big-endian shorts. > > > L > > > If I have a entire row of 4800 big-endian signed shorts in consecutiveL > > > memory, what would be the most efficient to flip all of them to litte-) > > > endian ? (VAX architecture, DEC-C).  > > F > >      I would copy them into a separate array rather than swap themE > > in place.  Use pointers to unsigned char (rather than short) with  > > ' > >   for (i = 0; i < 2*4800; i += 2) {  > >     outbuf[i+1] = inbuf[i];  > >     outbuf[i] = inbuf[i+1];  > >   }  > > H > > (You might be tempted to use i++ or ++i in that loop.  Don't do it.) > > F > >      For Alpha the answer might be different; cache considerationsG > > are more likely to apply and shifting and masking four 16-bit units $ > > at a time could perhaps pay off. > > 6 > > > And while I am at it, a question on descriptors: > > > - > > > I used to declare descriptors such as : : > > > $DESCRIPTOR(my_time_desc,"dd-mmm-yyyy hh:mm:ss.mm"); > > > K > > > and in the program, my_time_desc.dsc$a_pointer was filled with actual L > > > data. However, since DEC-C, the default ahs been to made the string inL > > > $DESCRIPTOR in non-writable memory, causing access violations when you > > > try to write it. > > F > >      Such behavior is sanctioned by the C standard, and it usuallyA > > is a good thing.  The compiler has a qualifier to get the old ( > > behavior back if you really need it. > > - > > > I have since change my programs to have  > > >	char my_time_char[25];. > > >	$DESCRIPTOP(my_time_desc,my_time_char) ; > > > Is there a better way ?  > > 1 > >      Let the compiler do the length counting.  > > B > >        static char my_time_char[] = "dd-mmm-yyyy hh:mm:ss.mm";3 > >        $DESCRIPTOR(my_time_desc, my_time_char);  > > 6 > >                 Pat Rankin, rankin@eql.caltech.edu   ------------------------------  % Date: Sun, 08 Apr 2001 08:08:02 -0700 ! From: Tom Linden <tom@kednos.com> ; Subject: RE: Flipping from big-endian to little endian in C 9 Message-ID: <CIEJLCMNHNNDLLOOGNJICEJICFAA.tom@kednos.com>   L Sorry about that post, it is obviously wrong.  I think my brain took the day off yesterday.     > -----Original Message-----* > From: Tom Linden [mailto:tom@KEDNOS.COM]( > Sent: Saturday, April 07, 2001 7:59 PM > To: Info-VAX@Mvb.Saic.Com = > Subject: RE: Flipping from big-endian to little endian in C  >  > ; > That won't work.  You need to reverse the entire 16 bits.  >  > > -----Original Message-----4 > > From: Pat Rankin [mailto:rankin@eql.caltech.edu]* > > Sent: Saturday, April 07, 2001 7:34 PM > > To: Info-VAX@Mvb.Saic.Com ? > > Subject: Re: Flipping from big-endian to little endian in C  > >  > > 1 > > In article <3ACED07F.4CA8A637@videotron.ca>,\ 6 > >  JF Mezei <jfmezei.spamnot@videotron.ca> writes...H > > > I have to read a rather large amount of binary data (2 byte signed> > > > integers) in C. The data is stored as big-endian shorts. > > > L > > > If I have a entire row of 4800 big-endian signed shorts in consecutiveL > > > memory, what would be the most efficient to flip all of them to litte-) > > > endian ? (VAX architecture, DEC-C).  > > F > >      I would copy them into a separate array rather than swap themE > > in place.  Use pointers to unsigned char (rather than short) with  > > ' > >   for (i = 0; i < 2*4800; i += 2) {  > >     outbuf[i+1] = inbuf[i];  > >     outbuf[i] = inbuf[i+1];  > >   }  > > H > > (You might be tempted to use i++ or ++i in that loop.  Don't do it.) > > F > >      For Alpha the answer might be different; cache considerationsG > > are more likely to apply and shifting and masking four 16-bit units $ > > at a time could perhaps pay off. > > 6 > > > And while I am at it, a question on descriptors: > > > - > > > I used to declare descriptors such as : : > > > $DESCRIPTOR(my_time_desc,"dd-mmm-yyyy hh:mm:ss.mm"); > > > K > > > and in the program, my_time_desc.dsc$a_pointer was filled with actual L > > > data. However, since DEC-C, the default ahs been to made the string inL > > > $DESCRIPTOR in non-writable memory, causing access violations when you > > > try to write it. > > F > >      Such behavior is sanctioned by the C standard, and it usuallyA > > is a good thing.  The compiler has a qualifier to get the old ( > > behavior back if you really need it. > > - > > > I have since change my programs to have  > > >	char my_time_char[25];. > > >	$DESCRIPTOP(my_time_desc,my_time_char) ; > > > Is there a better way ?  > > 1 > >      Let the compiler do the length counting.  > > B > >        static char my_time_char[] = "dd-mmm-yyyy hh:mm:ss.mm";3 > >        $DESCRIPTOR(my_time_desc, my_time_char);  > > 6 > >                 Pat Rankin, rankin@eql.caltech.edu   ------------------------------  % Date: Sun, 08 Apr 2001 08:08:02 -0700 ! From: Tom Linden <tom@kednos.com> ; Subject: RE: Flipping from big-endian to little endian in C 9 Message-ID: <CIEJLCMNHNNDLLOOGNJICEJICFAA.tom@kednos.com>   L Sorry about that post, it is obviously wrong.  I think my brain took the day off yesterday.     > -----Original Message-----* > From: Tom Linden [mailto:tom@KEDNOS.COM]( > Sent: Saturday, April 07, 2001 7:59 PM > To: Info-VAX@Mvb.Saic.Comn= > Subject: RE: Flipping from big-endian to little endian in Ct >e >a; > That won't work.  You need to reverse the entire 16 bits.E >l > > -----Original Message-----4 > > From: Pat Rankin [mailto:rankin@eql.caltech.edu]* > > Sent: Saturday, April 07, 2001 7:34 PM > > To: Info-VAX@Mvb.Saic.Com ? > > Subject: Re: Flipping from big-endian to little endian in C  > >  > >61 > > In article <3ACED07F.4CA8A637@videotron.ca>,\06 > >  JF Mezei <jfmezei.spamnot@videotron.ca> writes...H > > > I have to read a rather large amount of binary data (2 byte signed> > > > integers) in C. The data is stored as big-endian shorts. > > >lL > > > If I have a entire row of 4800 big-endian signed shorts in consecutiveL > > > memory, what would be the most efficient to flip all of them to litte-) > > > endian ? (VAX architecture, DEC-C).e > >uF > >      I would copy them into a separate array rather than swap themE > > in place.  Use pointers to unsigned char (rather than short) withF > >6' > >   for (i = 0; i < 2*4800; i += 2) {z > >     outbuf[i+1] = inbuf[i];. > >     outbuf[i] = inbuf[i+1];( > >   }< > >0H > > (You might be tempted to use i++ or ++i in that loop.  Don't do it.) > >>F > >      For Alpha the answer might be different; cache considerationsG > > are more likely to apply and shifting and masking four 16-bit units $ > > at a time could perhaps pay off. > > 6 > > > And while I am at it, a question on descriptors: > > >i- > > > I used to declare descriptors such as :o: > > > $DESCRIPTOR(my_time_desc,"dd-mmm-yyyy hh:mm:ss.mm"); > > >pK > > > and in the program, my_time_desc.dsc$a_pointer was filled with actualeL > > > data. However, since DEC-C, the default ahs been to made the string inL > > > $DESCRIPTOR in non-writable memory, causing access violations when you > > > try to write it. > > F > >      Such behavior is sanctioned by the C standard, and it usuallyA > > is a good thing.  The compiler has a qualifier to get the old ( > > behavior back if you really need it. > >=- > > > I have since change my programs to have  > > >	char my_time_char[25];. > > >	$DESCRIPTOP(my_time_desc,my_time_char) ; > > > Is there a better way ?p > > 1 > >      Let the compiler do the length counting.  > >lB > >        static char my_time_char[] = "dd-mmm-yyyy hh:mm:ss.mm";3 > >        $DESCRIPTOR(my_time_desc, my_time_char);e > > 6 > >                 Pat Rankin, rankin@eql.caltech.edu   ------------------------------  % Date: Sun, 08 Apr 2001 08:08:02 -0700.! From: Tom Linden <tom@kednos.com>i; Subject: RE: Flipping from big-endian to little endian in Cr9 Message-ID: <CIEJLCMNHNNDLLOOGNJICEJICFAA.tom@kednos.com>   L Sorry about that post, it is obviously wrong.  I think my brain took the day off yesterday.     > -----Original Message-----* > From: Tom Linden [mailto:tom@KEDNOS.COM]( > Sent: Saturday, April 07, 2001 7:59 PM > To: Info-VAX@Mvb.Saic.Com = > Subject: RE: Flipping from big-endian to little endian in C  >u >f; > That won't work.  You need to reverse the entire 16 bits.o >  > > -----Original Message-----4 > > From: Pat Rankin [mailto:rankin@eql.caltech.edu]* > > Sent: Saturday, April 07, 2001 7:34 PM > > To: Info-VAX@Mvb.Saic.Com ? > > Subject: Re: Flipping from big-endian to little endian in C' > >e > > 1 > > In article <3ACED07F.4CA8A637@videotron.ca>,\n6 > >  JF Mezei <jfmezei.spamnot@videotron.ca> writes...H > > > I have to read a rather large amount of binary data (2 byte signed> > > > integers) in C. The data is stored as big-endian shorts. > > >nL > > > If I have a entire row of 4800 big-endian signed shorts in consecutiveL > > > memory, what would be the most efficient to flip all of them to litte-) > > > endian ? (VAX architecture, DEC-C).: > >pF > >      I would copy them into a separate array rather than swap themE > > in place.  Use pointers to unsigned char (rather than short) withi > >)' > >   for (i = 0; i < 2*4800; i += 2) {> > >     outbuf[i+1] = inbuf[i];  > >     outbuf[i] = inbuf[i+1];u > >   }y > > H > > (You might be tempted to use i++ or ++i in that loop.  Don't do it.) > >uF > >      For Alpha the answer might be different; cache considerationsG > > are more likely to apply and shifting and masking four 16-bit unitst$ > > at a time could perhaps pay off. > >r6 > > > And while I am at it, a question on descriptors: > > >p- > > > I used to declare descriptors such as :e: > > > $DESCRIPTOR(my_time_desc,"dd-mmm-yyyy hh:mm:ss.mm"); > > >iK > > > and in the program, my_time_desc.dsc$a_pointer was filled with actualuL > > > data. However, since DEC-C, the default ahs been to made the string inL > > > $DESCRIPTOR in non-writable memory, causing access violations when you > > > try to write it. > > F > >      Such behavior is sanctioned by the C standard, and it usuallyA > > is a good thing.  The compiler has a qualifier to get the old ( > > behavior back if you really need it. > > - > > > I have since change my programs to havek > > >	char my_time_char[25];. > > >	$DESCRIPTOP(my_time_desc,my_time_char) ; > > > Is there a better way ?  > > 1 > >      Let the compiler do the length counting.i > > B > >        static char my_time_char[] = "dd-mmm-yyyy hh:mm:ss.mm";3 > >        $DESCRIPTOR(my_time_desc, my_time_char);. > > 6 > >                 Pat Rankin, rankin@eql.caltech.edu   ------------------------------  % Date: Sun, 08 Apr 2001 08:08:02 -0700.! From: Tom Linden <tom@kednos.com>r; Subject: RE: Flipping from big-endian to little endian in Co9 Message-ID: <CIEJLCMNHNNDLLOOGNJICEJICFAA.tom@kednos.com>   L Sorry about that post, it is obviously wrong.  I think my brain took the day off yesterday.     > -----Original Message-----* > From: Tom Linden [mailto:tom@KEDNOS.COM]( > Sent: Saturday, April 07, 2001 7:59 PM > To: Info-VAX@Mvb.Saic.Com = > Subject: RE: Flipping from big-endian to little endian in C[ >] > ; > That won't work.  You need to reverse the entire 16 bits.n >a > > -----Original Message-----4 > > From: Pat Rankin [mailto:rankin@eql.caltech.edu]* > > Sent: Saturday, April 07, 2001 7:34 PM > > To: Info-VAX@Mvb.Saic.Com1? > > Subject: Re: Flipping from big-endian to little endian in Cn > >l > >m1 > > In article <3ACED07F.4CA8A637@videotron.ca>,\ 6 > >  JF Mezei <jfmezei.spamnot@videotron.ca> writes...H > > > I have to read a rather large amount of binary data (2 byte signed> > > > integers) in C. The data is stored as big-endian shorts. > > >eL > > > If I have a entire row of 4800 big-endian signed shorts in consecutiveL > > > memory, what would be the most efficient to flip all of them to litte-) > > > endian ? (VAX architecture, DEC-C).c > >dF > >      I would copy them into a separate array rather than swap themE > > in place.  Use pointers to unsigned char (rather than short) with. > > ' > >   for (i = 0; i < 2*4800; i += 2) {o > >     outbuf[i+1] = inbuf[i];5 > >     outbuf[i] = inbuf[i+1];c > >   }c > >;H > > (You might be tempted to use i++ or ++i in that loop.  Don't do it.) > > F > >      For Alpha the answer might be different; cache considerationsG > > are more likely to apply and shifting and masking four 16-bit units $ > > at a time could perhaps pay off. > >c6 > > > And while I am at it, a question on descriptors: > > >p- > > > I used to declare descriptors such as :e: > > > $DESCRIPTOR(my_time_desc,"dd-mmm-yyyy hh:mm:ss.mm"); > > >iK > > > and in the program, my_time_desc.dsc$a_pointer was filled with actualuL > > > data. However, since DEC-C, the default ahs been to made the string inL > > > $DESCRIPTOR in non-writable memory, causing access violations when you > > > try to write it. > > F > >      Such behavior is sanctioned by the C standard, and it usuallyA > > is a good thing.  The compiler has a qualifier to get the old ( > > behavior back if you really need it. > > - > > > I have since change my programs to havek > > >	char my_time_char[25];. > > >	$DESCRIPTOP(my_time_desc,my_time_char) ; > > > Is there a better way ?  > > 1 > >      Let the compiler do the length counting.i > > B > >        static char my_time_char[] = "dd-mmm-yyyy hh:mm:ss.mm";3 > >        $DESCRIPTOR(my_time_desc, my_time_char);. > > 6 > >                 Pat Rankin, rankin@eql.caltech.edu   ------------------------------  % Date: Sun, 08 Apr 2001 08:08:02 -0700.! From: Tom Linden <tom@kednos.com>r; Subject: RE: Flipping from big-endian to little endian in Co9 Message-ID: <CIEJLCMNHNNDLLOOGNJICEJICFAA.tom@kednos.com>   L Sorry about that post, it is obviously wrong.  I think my brain took the day off yesterday.     > -----Original Message-----* > From: Tom Linden [mailto:tom@KEDNOS.COM]( > Sent: Saturday, April 07, 2001 7:59 PM > To: Info-VAX@Mvb.Saic.Com = > Subject: RE: Flipping from big-endian to little endian in C[ >] > ; > That won't work.  You need to reverse the entire 16 bits.n >a > > -----Original Message-----4 > > From: Pat Rankin [mailto:rankin@eql.caltech.edu]* > > Sent: Saturday, April 07, 2001 7:34 PM > > To: Info-VAX@Mvb.Saic.Com1? > > Subject: Re: Flipping from big-endian to little endian in Cn > >l > >m1 > > In article <3ACED07F.4CA8A637@videotron.ca>,\ 6 > >  JF Mezei <jfmezei.spamnot@videotron.ca> writes...H > > > I have to read a rather large amount of binary data (2 byte signed> > > > integers) in C. The data is stored as big-endian shorts. > > >eL > > > If I have a entire row of 4800 big-endian signed shorts in consecutiveL > > > memory, what would be the most efficient to flip all of them to litte-) > > > endian ? (VAX architecture, DEC-C).c > >dF > >      I would copy them into a separate array rather than swap themE > > in place.  Use pointers to unsigned char (rather than short) with. > > ' > >   for (i = 0; i < 2*4800; i += 2) {o > >     outbuf[i+1] = inbuf[i];5 > >     outbuf[i] = inbuf[i+1];c > >   }c > >;H > > (You might be tempted to use i++ or ++i in that loop.  Don't do it.) > > F > >      For Alpha the answer might be different; cache considerationsG > > are more likely to apply and shifting and masking four 16-bit units $ > > at a time could perhaps pay off. > >c6 > > > And while I am at it, a question on descriptors: > > >p- > > > I used to declare descriptors such as :e: > > > $DESCRIPTOR(my_time_desc,"dd-mmm-yyyy hh:mm:ss.mm"); > > >iK > > > and in the program, my_time_desc.dsc$a_pointer was filled with actualuL > > > data. However, since DEC-C, the default ahs been to made the string inL > > > $DESCRIPTOR in non-writable memory, causing access violations when you > > > try to write it. > > F > >      Such behavior is sanctioned by the C standard, and it usuallyA > > is a good thing.  The compiler has a qualifier to get the old ( > > behavior back if you really need it. > > - > > > I have since change my programs to havek > > >	char my_time_char[25];. > > >	$DESCRIPTOP(my_time_desc,my_time_char) ; > > > Is there a better way ?  > > 1 > >      Let the compiler do the length counting.i > > B > >        static char my_time_char[] = "dd-mmm-yyyy hh:mm:ss.mm";3 > >        $DESCRIPTOR(my_time_desc, my_time_char);. > > 6 > >                 Pat Rankin, rankin@eql.caltech.edu   ------------------------------  $ Date: Sun, 8 Apr 2001 14:53:09 +0200" From: "Hans Vlems" <hvlems@iae.nl>1 Subject: Re: London, England Technical Update Daye( Message-ID: <9apjic$jvo$1@news.IAEhv.nl>   Sue,  J will this material be presented at the Decus Europe evenet too, early May?  
 Hans Vlems  ; Sue Skonetski <susan.skonetski@compaq.com> wrote in message , news:PPoz6.648$fB6.17182@news.cpqcorp.net... > Dear Newsgroup,  >  > As promised. >0J > Here is the URL for the OpenVMS Technical Update days in London England. > 4 > http://www.wordsbureau.co.uk/vms-technical-update/ >o/ > It works from Netscape and Internet explorer.  >  > Warm Regards,t >a > Suei >  >d >e   ------------------------------   Date: 8 Apr 2001 07:05:40 -0500 9 From: kaplow_r@eisner.encompasserve.org.mars (Bob Kaplow) < Subject: Re: Q: Converting a VAX 6000-420 to a VAX 6000-620?3 Message-ID: <dlP$shHWxqI8@eisner.encompasserve.org>   X In article <3ACF8A70.EB74DC5C@mediaone.net>, Bob Willard <bobwbsgs@mediaone.net> writes: > Brian Chase wrote: >> dK >> I've got a VAX 6000-420 and some CPUs coming from a VAX 6000-6xx system.eF >> Is it possible to replace the VAX 6000-4xx series CPUs with the VAXM >> 6000-6xx CPUs?  If it is possible, is it just as simple as pulling out the J >> old CPUs and swapping in faster ones, or does something more need to be >> done? >>  
 >> -brian. > G > More.  The VAX 62x0/63x0/64x0 used write-thru caches, while the later H > 65x0/66x0 used write-back caches.  If your 64x0 has original memories,D > they will need to be replaced with later ones that had support for > write-back caches. > F > Also, maybe, if you have some early XMI I/O adapters, they may causeE > problems.  Most of the I/O adapters were cured early enough that ifmE > they shipped with a 64x0 they would also work with write-back CPUs.k > D > There may also be some configuration constraints -- number of 6500D > or 6600 CPUs comes to mind -- based on the older power supplies in > the 64x0.m > F > Sorry I can't be more specific about the I/O and P.S. stuff, but the# > memories are the primary concern.t  H Wasn't there a backplane change somewhere along the 6000 family upgrade?   ------------------------------  $ Date: Sun, 8 Apr 2001 14:50:37 +0200" From: "Hans Vlems" <hvlems@iae.nl>< Subject: Re: Q: Converting a VAX 6000-420 to a VAX 6000-620?( Message-ID: <9apjdo$jla$1@news.IAEhv.nl>  F You are correct: there was a backplane change. The 6400 series came inG two modeltypes. IIRC the ones that had the new backplane no langer came.7 with a TK70. They no longer worked with MS62-xx memory.   
 Hans Vlems  D Bob Kaplow <kaplow_r@eisner.encompasserve.org.mars> wrote in message- news:dlP$shHWxqI8@eisner.encompasserve.org...F: > In article <3ACF8A70.EB74DC5C@mediaone.net>, Bob Willard <bobwbsgs@mediaone.net> writes:a > > Brian Chase wrote: > >>E > >> I've got a VAX 6000-420 and some CPUs coming from a VAX 6000-6xxr system.-H > >> Is it possible to replace the VAX 6000-4xx series CPUs with the VAXK > >> 6000-6xx CPUs?  If it is possible, is it just as simple as pulling out  theaL > >> old CPUs and swapping in faster ones, or does something more need to be
 > >> done? > >> > >> -brian. > >aI > > More.  The VAX 62x0/63x0/64x0 used write-thru caches, while the lateraJ > > 65x0/66x0 used write-back caches.  If your 64x0 has original memories,F > > they will need to be replaced with later ones that had support for > > write-back caches. > >pH > > Also, maybe, if you have some early XMI I/O adapters, they may causeG > > problems.  Most of the I/O adapters were cured early enough that iflG > > they shipped with a 64x0 they would also work with write-back CPUs.l > >hF > > There may also be some configuration constraints -- number of 6500F > > or 6600 CPUs comes to mind -- based on the older power supplies in
 > > the 64x0.e > >dH > > Sorry I can't be more specific about the I/O and P.S. stuff, but the% > > memories are the primary concern.  > J > Wasn't there a backplane change somewhere along the 6000 family upgrade?   ------------------------------  " Date: Sun, 8 Apr 2001 16:42:03 GMT% From: bdc@world.std.com (Brian Chase) < Subject: Re: Q: Converting a VAX 6000-420 to a VAX 6000-620?& Message-ID: <GBHFq3.44w@world.std.com>  M In article <GBFwvA.Gxs@world.std.com>, Brian Chase <bdc@world.std.com> wrote:   L > I've got a VAX 6000-420 and some CPUs coming from a VAX 6000-6xx system.  E > Is it possible to replace the VAX 6000-4xx series CPUs with the VAX L > 6000-6xx CPUs?  If it is possible, is it just as simple as pulling out theI > old CPUs and swapping in faster ones, or does something more need to beT > done?e  J Okay... well, I've gotten some feedback so far, but it's all still sort ofA fuzzy.  Here's some more information...  I've got a VAX 6000-420,0I apparently an older style one.  It uses MS62-xx type memory.  I have somerI VAX 6000-600 series CPUs on the way, as well as some newer RAM that worksC with those CPUs.  I I've been told, that I may need to modify the backplane (Is this a simpleeH replacement of the cardcage, do I need different power supplies?).  I'veH also been told that there existed an XMI module which could plugged intoI the old XMI backplane to allow the the VAX 6000-600 CPUs to work in it.  nB More details on either or both of these options would be very much appreciated.  L Really, I just need a list of all the parts I need to take a 420 to a 620.  , I have the CPUs, I have the RAM.  What else?   -brian.  -- nF --- Brian Chase | bdc@world.std.com | http://world.std.com/~bdc/ -----D YOU PEOPLE OUGHTA HAVE MORE RESPECT FOR YOUR INSANE ELDERS!!!  -- K.   ------------------------------  % Date: Sun, 08 Apr 2001 18:52:10 +0100a+ From: "antonio.carlini" <arcarlini@iee.org>t< Subject: Re: Q: Converting a VAX 6000-420 to a VAX 6000-620?' Message-ID: <3AD0A54A.E856603A@iee.org>v   Brian Chase wrote: > O > In article <GBFwvA.Gxs@world.std.com>, Brian Chase <bdc@world.std.com> wrote:eL > Okay... well, I've gotten some feedback so far, but it's all still sort ofC > fuzzy.  Here's some more information...  I've got a VAX 6000-420,aK > apparently an older style one.  It uses MS62-xx type memory.  I have someFK > VAX 6000-600 series CPUs on the way, as well as some newer RAM that works[ > with those CPUs. > K > I've been told, that I may need to modify the backplane (Is this a simplenJ > replacement of the cardcage, do I need different power supplies?).  I'veJ > also been told that there existed an XMI module which could plugged intoI > the old XMI backplane to allow the the VAX 6000-600 CPUs to work in it. D > More details on either or both of these options would be very much > appreciated. > L > Really, I just need a list of all the parts I need to take a 420 to a 620.. > I have the CPUs, I have the RAM.  What else?  / The VAX 6000-500 and VAX 6000-600 shipped with o1 what (IIRC) was referred to as the XMI-2 platforme. whereas the previous VAX 6000 shipped with the XMI-1 platform.e  + XMI-2 added a few bits and bobs over XMI-1. ( From a hardware point of view you got an& extra supply voltage (+3.3V, perhaps a  few others too); from a software( point of view you could support machines  with > 512MB of physical memory.  % VAX 6000-600 supported up to 3.5GB ofo& memory (again, IIRC); the VAX 6000-500$ could have supported more than 512MB% but I don't think that ever happened.   + Older systems' platforms could be convertedo( in the field from XMI-1 to XMI-2. I have( the manual that describes this somewhere+ but it essentially means removing the XMI-1c' card cage and one PSU and swapping in ak+ new backplane and PSU. This is not the path- you wish to take (I assume).  & The simpler upgrade is to use a T2019. This is an XMI module that you* install in slot 2 (it make slot 1 unusable% too because of its size). This moduleJ" supplies +3.3V on the relevant XMI' lines. You need a connector at the backI* too to feed the new power down the correct lines.  ) There are some limitations with the T2019n& method. You are limited to four of the& newer processors rather than eight and! you cannot have a battery backup.i  . There are some options which will specifically* bot function in an environment where +3.3V/ is supplied (because the +3.3V appears on linesg. that were previously ground). The KA62A, KA62B+ and KA64A processors, MS62A memory and the 0 DWMBA XMI-BI adapter.o  ! If you have a true XMI-2 platformF$ (or a fully upgraded XMI-1 platform)$ I think that the system protects you% from damaging such components if they ! are present (by not powering up).n  " If you use the T2019, I don't know  whether you get that protection.  % So I think the short answer is: T2019h' and that widget you plug in at the back ( (sorry, no part number ... I can hit the# IPBs if you think you might have iti but are not sure).   Antonio    -- t   ---------------a- Antonio Carlini             arcarlini@iee.orgt   ------------------------------  % Date: Sun, 08 Apr 2001 14:44:23 +0200t= From: Arne =?iso-8859-1?Q?Vajh=F8j?= <arne.vajhoej@gtech.com>r Subject: Re: sys$io_performw) Message-ID: <3AD05D27.B6C07DAC@gtech.com>>   "Doug W." wrote:O > If you can drop the w, there is an example of sys$io_perform in sys$examples.bM > Last time I looked it gave a compiler error, but its easy to fix and fairlyp > clear.  Its a C program.   Thanks.    Arne   ------------------------------    Date: 08 Apr 2001 23:07:57 +0800, From: Paul Repacholi <prep@prep.synonet.com> Subject: Re: sys$io_performw- Message-ID: <87zodrv38y.fsf@prep.synonet.com>   , Arne Vajhj <arne.vajhoej@gtech.com> writes:   > "Doug W." wrote:  C > > If you can drop the w, there is an example of sys$io_perform intC > > sys$examples.  Last time I looked it gave a compiler error, buts7 > > its easy to fix and fairly clear.  Its a C program.   F HAs anyone measured the performance diffs between QIO, OI_PERFORM, and? paging? I assume the paging has inherited any speedups as well.n   -- h< Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda.y@                                              West Australia 6076. Raw, Cooked or Well-done, it's all half baked.   ------------------------------   Date: 08 Apr 2001 17:22:10 GMT' From: dashw459@aol.comeatspam (Doug W.)l Subject: Re: sys$io_performw: Message-ID: <20010408132210.20363.00005729@ng-mq1.aol.com>   Paul Repacholi wrote:m     << sF HAs anyone measured the performance diffs between QIO, OI_PERFORM, andB paging? I assume the paging has inherited any speedups as well. >>  N Without a clear definition of the specific I/O behavior one is concerned with,8 its hard to say anything definite about I/O performance.  K As for I/O perform & QIO.  Expect I/O perform to become more efficient withoL many small I/Os.  I didn't see any big difference on 127 block I/Os.  QIO isN definitely easy to use.  The object like orientation of I/O perform may appealM to C++ programers.  Under 7.2-1 with all patches expect troube with MAXBOBMEMd0 (easy to get around) and I believe fixed in 7.3.   ------------------------------  " Date: Sun, 8 Apr 2001 17:33:57 GMT( From: Terry Kennedy <terry@gate.tmk.com>) Subject: Re: THE EMC Chronicles - revised ' Message-ID: <GBHI4L.15z@spcuna.spc.edu>M  , Sean O'Banion <seanobanion@home.com> writes:Q > EMC might be able to figure out who I work for, but the mangers they originallytQ > "smoozed" no longer work here (the EMC purchase is one of the reasons), and the N > new managers are not even in this state, so they have no one to complain to.L > But Lyndon is just starting: I hope we all get the chance to hear how that > deployment goes.  H   I would never buy anything from EMC after the way we were treated manyK years ago. We got a very aggressive quote from EMC for 4 4MB VAX 780 memory J boards in 1986 or 1987, and FAXed them a PO the same say, as the sales repG said was necessary. We were told they would ship by the end of the day.   L   After a couple days, I called back and the rep said he couldn't understandN what the problem was, would look into it, etc. Things went downhill from thereJ and about a month later I was able to talk to a senior manager who told meL that the sales rep was terminated for providing "overly aggressive discount- ing".n  I   I then explained that this memory was to satisfy a Federal grant at my  L [then] employer, and that we needed it and the Feds thought we'd ordered it.K I also stated that I felt a quote and a PO (which was not rejected within a J month) constituted a binding agreement. He didn't agree. I then offered toJ take trade-in boards that they had in stock, product with cosmetic damage,I etc. - whatever they needed to do to provide me 4 4MB boards at the pricenJ they had quoted. He refused, and I took it all the way up EMC's managementJ chain, where it was refused (with varying degrees of pleasantness) all the way.  G   A couple months later, I went to a DECUS Symposium, and at the nearbyeI DEXPO, I told this tale of woe to every memory manufacturer I could find,_I until Dataram offered to meet the EMC quote (without even knowing what iteI was!) with new Dataram product. So we bought it from them, and remained aiA loyal Dataram customer across many 780's, 8650's, and MicroVAXen.s  H   Since then, I've observed at least one *major* EMC storage "situation"I which involved EMC senior management and engineers at the customer's site-I 24x7 for at least a week, along with a stream of replacement parts, soft-sG ware updates, etc. The customer is apparently still using EMC hardware,sJ and I don't know if they're completely satisfied or less satisfied. But it6 was apparently a really big disaster when it happened.  4         Terry Kennedy             http://www.tmk.com5         terry@tmk.com             Jersey City, NJ USAd   ------------------------------  % Date: Sun, 08 Apr 2001 10:33:45 +0100i  From: Paul Sture <paul@sture.ch>$ Subject: Re: VMS-Related: Affordable+ Message-ID: <VA.00000349.b35dda40@sture.ch>a  9 In article <9anjur$cbg$1@pyrite.mv.net>, Bill Todd wrote:o) > From: "Bill Todd" <billtodd@foo.mv.com>y > Newsgroups: comp.os.vms & > Subject: Re: VMS-Related: Affordable& > Date: Sat, 7 Apr 2001 13:49:19 -0400 >  > > > Malcolm Dunnett <nothome@spammers.are.scum> wrote in message( > news:2c$iMWUXdhKV@malvm1.mala.bc.ca... >  > .... > 7 > > It was a bit of culture shock to move from a PDP-11yK > > RSTS system with its constrained program address space ( generally 56kbsL > > for your program and 8kb reserved for system address space ) and limitedG > > physical memory ( the PDP 11/40 maxed out at 128KB ). It often tooklF > > longer in those days to design a TKB overlay structure to get yourG > > program to fit into memory than it took to write the original code.  > N > But what fun it was!  And of course if you wrote the code with overlaying inM > mind (which might be hard to go back to nowadays but was second-nature backf4 > then) it wasn't all *that* bad - at least usually. >pM Yes, it _was_ fun. I distinctly remember designing programs with overlays in eK mind. Initialization, closedown and fatal error routines were always prime y candidates for example.   M And I recall the point when we had a substantial hardware upgrade, with lots  J more memory. Simply reworking the overlays of critical programs brought a ! significant performance increase.(  M > IIRC VMS early-on still supported overlays as an alternative (or perhaps anmK > adjunct) to paging.  I always assumed it was because some people realizedCL > that, at least in a memory-constrained environment, giving the applicationG > programer more control over the effective 'paging' activity could, at J > noticable additional cost in development effort, result in significantly > better performance.  > N IIRC that was right. Why let the OS decide when to drop stuff out of RAM when / you already knew that you had finished with it?v   ___ 
 Paul Sture Switzerland    ------------------------------  % Date: Sun, 08 Apr 2001 10:33:46 +0100   From: Paul Sture <paul@sture.ch>$ Subject: Re: VMS-Related: Affordable+ Message-ID: <VA.0000034a.b35ddc71@sture.ch>y  C In article <D$4mFL9g$AGw@malvm1.mala.bc.ca>, Malcolm Dunnett wrote: 3 > From: nothome@spammers.are.scum (Malcolm Dunnett)e > Newsgroups: comp.os.vms-& > Subject: Re: VMS-Related: Affordable! > Date: 7 Apr 2001 14:41:01 -0700v > * > In article <9anjur$cbg$1@pyrite.mv.net>,/ >     "Bill Todd" <billtodd@foo.mv.com> writes:I > > P > > But what fun it was!  And of course if you wrote the code with overlaying inO > > mind (which might be hard to go back to nowadays but was second-nature backg6 > > then) it wasn't all *that* bad - at least usually. > > J >    Well I suppose it wasn't "rocket science", but you could spend a fairL > bit of time mapping which routine had dependencies on which other routinesJ > and comparing sizes of routines to map them into appropriate branches of > the overlay tree.  > Q Ah yes. On RT11 if you got the dependencies wrong, it came up with the wonderful m "Trap to 4".  N >    The worst part was getting code that wasn't designed to fit into a PDP-11P > (Fortran simulation programs originally written for mainframes comes to mind),C > and trying to design an overlay structure that would make it fit.n >eL Ugh! Programs designed as one extremely long module. Stuff originating from , COBOL on mainframes also suffered from this.  O > > IIRC VMS early-on still supported overlays as an alternative (or perhaps an M > > adjunct) to paging.  I always assumed it was because some people realizedwN > > that, at least in a memory-constrained environment, giving the applicationI > > programer more control over the effective 'paging' activity could, at L > > noticable additional cost in development effort, result in significantly > > better performance.e > > M >     VMS supported TKB for PDP-11 images ( remember, the 11/780 had a PDP-11bL > "compatibility mode" built in ). I don't recall anything like overlays for; > native images, but it might have been in there somewhere.s >p   ___ 
 Paul Sture Switzerlandr   ------------------------------   End of INFO-VAX 2001.197 ************************