msa@clinet.FI (Markku Savela) (04/27/88)
In article <587@vsi.UUCP> friedl@vsi.UUCP (Stephen J. Friedl) writes: > >Let's put this goto business in perspective: > > /* > * strcpy() - written by John Doe > */ > strcpy(dst, src) > char dst[], src[]; > { > int i; > > for (i = 0; dst[i] = src[i]; i++) > ; > } > > Who objects to this? I don't! I'm actually using similar loops in my C-programs that are written for MS-DOS machines. Just try compiling the above code and a variation using pointers with LARGE MEMORY MODEL! Compare the results (in ASM). Believe or not, the variant using indexes is much more compact than the one using pointers (and saying "register i" improves it even more...) The question is of course: is there really any penalty in using indexed versions with other architectures (like motorola)? -- markku savela, msa@clinet.fi
limes@sun.uucp (Greg Limes) (04/30/88)
In article <629@clinet.FI> msa@clinet.UUCP (Markku Savela) writes: > The question is of course: is there really any penalty in >using indexed versions with other architectures (like motorola)? Yes, the motorola archetecture does take a hit here. With the pointer version, the data transfer is done using "movb a0@+,a1@+"; with the index version, "movb a0@(0,d1:l),a1@(0,d1:l)" and "addql #1,d1". Calculation of transfer times gets hairy, but a quick test shows that the pointer version is about 25% faster. -- Greg Limes [limes@sun.com] frames to /dev/fb
craig@srs.UUCP (Craig Schmackpfeffer) (05/02/88)
In article <629@clinet.FI> msa@clinet.UUCP (Markku Savela) writes: >In article <587@vsi.UUCP> friedl@vsi.UUCP (Stephen J. Friedl) writes: >> >>Let's put this goto business in perspective: >> >> /* >> * strcpy() - written by John Doe >> */ >> strcpy(dst, src) >> char dst[], src[]; >> { >> int i; >> >> for (i = 0; dst[i] = src[i]; i++) >> ; >> } >> >> Who objects to this? > > I don't! I'm actually using similar loops in my C-programs >that are written for MS-DOS machines. Just try compiling the above >code and a variation using pointers with LARGE MEMORY MODEL! > > Compare the results (in ASM). Believe or not, the variant >using indexes is much more compact than the one using pointers (and >saying "register i" improves it even more...) > > The question is of course: is there really any penalty in >using indexed versions with other architectures (like motorola)? > >-- >markku savela, msa@clinet.fi The problem occurs when you are trying to index anything bigger than a single character. The index must be scaled by the size of the elements in the array. If you use pointers, an add instruction can be used to increment to the next element. However if you use an index on a compiler that doesn't optimize, it will have to generate code to multiply the index each time through the loop. Craig -- Craig Schmackpfeffer @ S.R. Systems {allegra,rutgers,ames}!rochester!srs!craig
walter@garth.UUCP (Walter Bays) (05/03/88)
In article <629@clinet.FI> msa@clinet.UUCP (Markku Savela) writes: >In article <587@vsi.UUCP> friedl@vsi.UUCP (Stephen J. Friedl) writes: >> strcpy(dst, src) >> char dst[], src[]; >> { >> int i; >> >> for (i = 0; dst[i] = src[i]; i++) >> ; >> } > Compare the results (in ASM). Believe or not, the variant >using indexes is much more compact than the one using pointers (and >saying "register i" improves it even more...) > > The question is of course: is there really any penalty in >using indexed versions with other architectures (like motorola)? I think that with a good compiler, for any architecture, you're better off writing in a simple and straightforward manner. The Clipper compiler will compile the example above using pointers just as if you had written it with pointers. The difference is, if the pointers are programmer declared, they have to be kept around, while if they are compiler generated, the registers are available for reuse. And of course if you use the library version (written with specific knowledge of the architecture) it will be faster still. -- ------------------------------------------------------------------------------ Any similarities between my opinions and those of the person who signs my paychecks is purely coincidental. E-Mail route: ...!pyramid!garth!walter USPS: Intergraph APD, 2400 Geng Road, Palo Alto, California 94303 Phone: (415) 852-2384 ------------------------------------------------------------------------------
bright@Data-IO.COM (Walter Bright) (05/05/88)
In article <624@garth.UUCP< walter@garth.UUCP (Walter Bays) writes: <In article <629@clinet.FI< msa@clinet.UUCP (Markku Savela) writes: <<In article <587@vsi.UUCP< friedl@vsi.UUCP (Stephen J. Friedl) writes: <<< strcpy(char *dst, char *src) <<< { int i; <<< for (i = 0; dst[i] = src[i]; i++) ; <<< } << The question is of course: is there really any penalty in <<using indexed versions with other architectures (like motorola)? <I think that with a good compiler, for any architecture, you're better off <writing in a simple and straightforward manner. The Clipper compiler will <compile the example above using pointers just as if you had written it <with pointers. The difference is, if the pointers are programmer declared, <they have to be kept around, while if they are compiler generated, the <registers are available for reuse. With many optimizers, live range analysis is done. What this is is determining the sections of code where a variable is used (is 'live'). Therefore, two variables with live ranges that do not overlap can share the same register. The Datalight and Zortech optimizers do this (I know because I wrote them!). I agree with the point that code should be written in a straightforward manner and let the optimizer 'tune' it for a particular architecture. Compilers in general are getting good enough to rely on this.
miker@wjvax.UUCP (Michael Ryan) (05/06/88)
In article <629@clinet.FI>, msa@clinet.FI (Markku Savela) writes: > In article <587@vsi.UUCP> friedl@vsi.UUCP (Stephen J. Friedl) writes: > >Let's put this goto business in perspective: [ ... ] > > for (i = 0; dst[i] = src[i]; i++) > > ; [ .. ] > I don't! I'm actually using similar loops in my C-programs > that are written for MS-DOS machines. Just try compiling the above [ ..] > Compare the results (in ASM). Believe or not, the variant > using indexes is much more compact than the one using pointers (and > saying "register i" improves it even more...) ok , far char type/size objects this works swell. but chars are not an interesting pointer case! if , for instance, you have a struct of , say , 60 bytes or so, like this: struct foo { char name [ 32 ]; long value; int asst[ 5 ]; }/**/ struct foo dave[ 200 ]; accessing dave with indexes becomes harrowing if your compiler is not smart I currently use , much to my chagrin, Msoft 5.0. an index like dave[3] becomes mov ax, 02EH ; or there about.. imul 3 ; .... excuse the mistakes, this is just an ex. to do anything interesting , meaning multiple struct access, becomes an exercise in integer multiplication. no, the Msoft 5.0 optimizer does nothing to change multiple array index accesses into pointer accesses. why ? I do not know. a million excuses to any compiler that does index/pointer optimization. our VAX cc doesn't while our Integrated Solutions cc does. can anyone name an MS-DOS product that does ? if one does not know the intelligence of one's compiler I recommend avoiding indexes, unless one has a great deal of time and don't we all. -- ==== *michael j ryan *{..!pyramid,..!decwrl!qubix}!wjvax!miker *Watkins-Johnson Co., San Jose CA : (408) 435 1400 x3079 * above views are not necessarily those of Watkins-Johnson Co.
bright@Data-IO.COM (Walter Bright) (05/07/88)
In article <1272@wjvax.UUCP> miker@wjvax.UUCP (Michael Ryan) writes:
<if , for instance, you have a struct of , say , 60 bytes or so, like this:
< struct foo { char name [32]; long value; int asst[ 5 ]; } dave[200];
<accessing dave with indexes becomes harrowing if your compiler is not smart
<I currently use , much to my chagrin, Msoft 5.0. an index like dave[3]
<becomes
<
< mov ax, 02EH ; or there about..
< imul 3 ;
<no, the Msoft 5.0 optimizer does nothing to change multiple array index
<accesses into pointer accesses. why ? I do not know.
<can anyone name an MS-DOS product that does ?
Datalight's optimizer does. I know because I wrote it.
"We keep you alive to serve this net. Post well,... and live."joseph@chromo.ucsc.edu (Joseph Reger) (05/08/88)
I do not see any ads any more about that wonderfully optimizing C compiler from Datalight. What happened? Does anybody have it? Impressions? __ Joseph
msa@clinet.FI (Markku Savela) (05/09/88)
In article <834@srs.UUCP> srs!craig@cs.rochester.edu (Craig Schmackpfeffer) writes: > >The problem occurs when you are trying to index anything bigger than a >single character. [...] Yes, I quite right! I merely wanted to point out, that one shouldn't make statemens like " *s++ = *p++ is ALWAYS better than s[i] = p[i]; ++i" and gave ONE counter example (Intel machine + large memory model). I think it's very good practice occasionally check the assembler code your high level language compiler procudes. I do generally this kind of thing after a program works. And sometimes I change my coding as a result (if I feel the relevant spot of code is critical). Markku Savela, msa@clinet.fi