tim@amdcad.AMD.COM (Tim Olson) (07/31/87)
In article <279@diab.UUCP> pf@.UUCP (Per Fogelstrom) writes: +----- | Be serious! Do you really belive in Dhrystone? Okay i do admitt that we don't | have anything better for the moment, but soon i hope. +----- I hope so, too. Dhrystone has been "twisted" by the translation from Ada to C (too much emphasis on string handling) and by the use of globally-optimizing compilers (code elimination) so much that it now should only be used as a *very* rough ballpark figure (unfortunately, people tend to like single figures-of-merit). There are on-going attempts to define new benchmarks; let's hope that some of these problems are being addressed. +----- | 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. 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. We were able to identify a single, simple instruction which increased the performance of C string handling. Others have also used this same technique in software to also obtain performance increases. -- Tim Olson Advanced Micro Devices (tim@amdcad.amd.com)
pec@necntc.NEC.COM (Paul Cohen) (08/04/87)
In article <1699@comp.arch> tim@.amdcad.AMD.COM (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. With respect to the V70 I feel that I must add a point of clarification. It is true that the movc and cmpc instructions require a string length to be specified (they also require you to specify whether to use eight or sixteen bit characters), but these are not the only character string operations that the V70 supports. There are also: CMPCF (compare character string with filler) CMPCS (compare character string with stopper) MOVCF (move character string with filler) MOVCS (move character string with stopper) SCHC (search for character) SKPC (search for not a character) each of which has eight and sixteen bit versions. Of these instructions, CMPCS and MOVCS support C language strings and in fact strings terminated by any character you want to specify. In addition, SCHC can be used as a string-length operation by C. The V70's character string move instructions also allow you to specify whether to move the string in a forward or backward direction, a critical issue when source and destination overlap. The V70 also has a complement of bit-string operations; specifically there are: MOVBS NOTBS ANDBS ANDNBS ORBS ORNBS XORBS XORNBS SCH0BS SCH1BS (search for ...) each of which can be specified to work in a forward or reverse direction. In performing string operations, whether bit, byte or half-word, the V70 reads and writes memory 32-bits at a time. Can anyone comment on this with respect to the other 32-bit micros?