pf@diab.UUCP (Per Fogelstrom) (08/01/87)
In article <17780@amdcad.AMD.COM> tim@amdcad.UUCP (Tim Olson) writes: +------ |In article <279@diab.UUCP> pf@.UUCP (Per Fogelstrom) writes: |+----- || What this benchmark really tests is the compilers ability to remove code that || does'nt really do anything. And of course the cpu's ability to handle strings. || Just check the Am29000. The designers put in an instruction just to speed up || this benchmark.... Now what, have we reaced a new point, where cpu's are || designed for the bencmarks instead of vice versa, as it was before ???? |+----- |No, we didn't put in the cpbyte instruction to "speed up Dhrystone" -- |it was added because many internal programs that we ran showed that such |an instruction could be used to speed up C string handling (size |unknown, string terminated by a \0) in general. +------ Sorry ! Didn't wanted to pick on you. Yes! The Am29000 is good at strings. But can one make use of such a instruction (cpbyte) in compiler code generation?? Of course it is possible to use it in assembly written librarys. But to often i have seen programs that do not make use of the 'C' library string routines, mayby because they are inefficient. +------- |Many processors have specialized instructions for strings -- Intel's 80x86 |family (movs, cmps), AT&T's 32100 (strlen, strcmp), National's 32x32 |family (movs, cmps), NEC's V70 (movc, cmpc), Fairchild's Clipper (movc, |cmpc macros). However, most of these don't address "C-type" strings; |they require a character count as a parameter. +------- Wrong! At least in the NS32x32 case. They do address "C-type" strings, and many other string constructs as well, not only \0 terminated strings. The character count parameter can be ignored if it is set to a 'huge' value (e.g 2**32-1). I myslf is using string instructions in C-librarys and it is possible to detect the "while( *p1++ = *p2++)" in a 'C' program. (We here at Diab can in our C-compiler). -- Per Fogelstrom, Diab Data AB SNAIL: Box 2029, S-183 02 Taby, Sweden ANALOG: +46 8-7680660 UUCP: seismo!mcvax!enea!diab!pf
aeusesef@csun.UUCP (Sean Eric Fagan) (08/06/87)
In article <280@diab.UUCP> pf@.UUCP (Per Fogelstrom) writes: >In article <17780@amdcad.AMD.COM> tim@amdcad.UUCP (Tim Olson) writes: >+------ >|Many processors have specialized instructions for strings -- Intel's 80x86 >|family (movs, cmps), AT&T's 32100 (strlen, strcmp), National's 32x32 >|family (movs, cmps), NEC's V70 (movc, cmpc), Fairchild's Clipper (movc, >|cmpc macros). However, most of these don't address "C-type" strings; >|they require a character count as a parameter. >+------- > >Wrong! At least in the NS32x32 case. They do address "C-type" strings >-- >Per Fogelstrom, Diab Data AB >SNAIL: Box 2029, S-183 02 Taby, Sweden >ANALOG: +46 8-7680660 >UUCP: seismo!mcvax!enea!diab!pf Hold on! The WE32100 chip *DOES* use C type strings. The instructions, incidentally, are STREND and STRCPY. STREND uses %r0, and increments it until it comes to a '\0', while STRCPY copies %r0 to %r1 until it comes to a '\0'. Unnecessary and useless fact designed to eat up line space so that the news poster won't complain: the 3B[5 at least] Unix that comes with it (SysVr2.0) uses the STRCPY instruction for the strcpy() function, but it does not use the STREND instruction for the strlen() routine. And, the assembler requires that these instructions be in UPPER CASE. Very strange machine. ----- Sean Eric Fagan Office of Computing/Communications Resources (213) 852 5742 Suite 2600 1GTLSEF@CALSTATE.BITNET 5670 Wilshire Boulevard Los Angeles, CA 90036 {litvax, rdlvax, psivax, hplabs, ihnp4}!csun!{aeusesef,titan!eectrsef} -------------------------------------------------------------------------------- My employers do not endorse my | "When in danger, in doubt, opinions, and, at least in my | run in Circles, scream, and shout." preference of Unix, heartily | -Dora Long, Richard Ames disagree. | (Robert A. Heinlein)
molly@killer.UUCP (Molly Fredericks) (08/14/87)
In article <712@csun.UUCP>, aeusesef@csun.UUCP (Sean Eric Fagan) writes: > In article <280@diab.UUCP> pf@.UUCP (Per Fogelstrom) writes: > >In article <17780@amdcad.AMD.COM> tim@amdcad.UUCP (Tim Olson) writes: > >+------ > >|Many processors have specialized instructions for strings -- Intel's 80x86 > >|family (movs, cmps), AT&T's 32100 (strlen, strcmp), National's 32x32 > >|family (movs, cmps), NEC's V70 (movc, cmpc), Fairchild's Clipper (movc, > >|cmpc macros). However, most of these don't address "C-type" strings; > >|they require a character count as a parameter. > >+------- > > > >Wrong! At least in the NS32x32 case. They do address "C-type" strings > > Hold on! The WE32100 chip *DOES* use C type strings. The instructions, > incidentally, are STREND and STRCPY. STREND uses %r0, and increments it > until it comes to a '\0', while STRCPY copies %r0 to %r1 until it comes to a > '\0'. Unnecessary and useless fact designed to eat up line space so that > the news poster won't complain: the 3B[5 at least] Unix that comes > with it (SysVr2.0) uses the STRCPY instruction for the strcpy() function, > but it does not use the STREND instruction for the strlen() routine. > And, the assembler requires that these instructions be in UPPER CASE. > Very strange machine. I'm sure this is no major revalation, but I seem to recall that Vaxen have a rather nice collection of string instructions. With the rumors (reality ???) that DEC is now selling the chips for uVaxen to OEMs, I think it is time to throw that number into the hat. I gave assembly up for C years ago (just after college ...) but I do recall instructions that could be used for strlen, strcpy, strncpy, strcmp, and strncmp. The instructions I'm thinking about are MOVC5, MOVC3, SPAN (SCAN?) - anyhow, I don't have my Levi and Eckhouse book (yick) close at hand, so I make no promises about what those guys, especially the baby Vax's, do or don't have. The way I remember them working was something like: MOVQ SRC_DESCRIPTOR, R0 MOVQ DST_DESCRIPTOR, R2 MOVB END_CHARACTER, R4 MOVC5 R0,R1,R2,R3,R4 and more or less poof! Instant strcpy (with error checking no less!) Of course, you have to finish with moving the lenght of the source string, or the length of the destination strings, whichever was smaller, into the length of the destination string in the descriptor. One bummer about those guys, I remember that MOVC5 was real bad about trashing R0 .. R5 or so. I think even MOVC3 ate plenty of your registers, which was a real bastard to deal with. Maybe I should go looking through the boxes for that book ...