chris@mimsy.UUCP (Chris Torek) (12/31/88)
>In article <15209@mimsy.UUCP>, regarding string comparisons on big-endian machines one ALU-width-word at a time, I claimed that >>This [can be done] for ordering comparisons (< <= > >=) only when the >>strings being compared are known to be sufficiently long, or are padded >>with 0s (or something that compares < `normal' characters) to the >>machine's word length. In article <6605@killer.DALLAS.TX.US> chasm@killer.DALLAS.TX.US (Charles Marslett) writes: >Come now, are you saying that if I have two strings differing in >the first character, the order they sort into can in any way be >affected by later characters. The only case where the trailing >trash can have an effect is if the two strings compare equal. True enough. But it hardly seems safe to allow equal strings s1 and s2 to compare as `s1 > s2' at one moment, then `s1 < s2' at the next. If it is possible to characterise the `trailing junk' as fixed, and the case where s1 and s2 should be equal but are counted otherwise is unimportant, you can again make use of the faster comparison. The latter is a characteristic of the algorithm, of course; but the former is a characteristic of an implementation, and I, for one, am leery of counting on implementations. >On the other hand, if an easy way to identify the \0 byte is not >available, faster compares does not help C code (usually). Other >languages are almost all helped with this characteristic, though. >(Is this because C was invented and developed in little-endian machines?) It does give pause to wonder. . . . Actually, I suspect this reflects much more a byte-orientation than an endian-orientation. Generating decent machine code from C source is usually not difficult on big- endian machines, but it is often hard on word-oriented machines (e.g., Cray), whether big- or little-endian. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
hunt@spar.SPAR.SLB.COM (Neil Hunt) (01/06/89)
Nobody has mentioned the argument used by some of the early
8 bit micro developers, who favoured little endian architectures.
This was because the low order offset for a long relative jump
is read first, and can be added to the PC in parallel with
the fetch of the high order offset. The other order would be
more difficult because of the possible carry which might be
generated in the low order addition which needs to be incor-
porated in the high order addition.
Neil/.
hunt@spar.slb.com
...{amdahl|decwrl|hplabs}!spar!hunt