Xref: utzoo comp.arch:7728 comp.misc:4577 comp.lang.misc:2427 comp.protocols.misc:429 Path: utzoo!attcan!uunet!lll-winken!lll-lcc!ames!haven!vrdxhq!bms-at!stuart From: stuart@bms-at.UUCP (Stuart Gathman) Newsgroups: comp.arch,comp.misc,comp.lang.misc,comp.protocols.misc Subject: Re: "big endian" and "little endian" - first usage for computer Message-ID: <145@bms-at.UUCP> Date: 3 Jan 89 21:46:30 GMT References: <2766@cbnews.ATT.COM> <10147@well.UUCP> <13045@cup.portal.com> Organization: Business Management Systems, Inc., Fairfax, VA Lines: 21 In article <13045@cup.portal.com>, bcase@cup.portal.com (Brian bcase Case) writes: > Big endian has the significant advantage that, when properly aligned, > character strings can be compared using the full width of the machine's > ALU. For 32-bit machines, this means that two four-character (sub)strings > can be compared at one time. This is because the lowest address always > points to the *first* character in the string. Little endian requires > character-at-a-time processing or hardware gymnastics. I do the same thing on little endian. It all depends on how you store the characters. Read the "HOLY WAR" article for a detailed explanation. The problem is, there are no consistent little-endian machines, the big-endian infiltrators have sabotaged every last one (that I know of). The major (dis)advantages are: BIGend (numeric) compares / divides are faster LITTLEend adds / multiplies are faster -- Stuart D. Gathman <..!{vrdxhq|daitc}!bms-at!stuart>