home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!cs.utexas.edu!qt.cs.utexas.edu!yale.edu!ira.uka.de!sbusol.rz.uni-sb.de!coli.uni-sb.de!coli-gate.coli.uni-sb.de!spackman
- From: spackman@disco-sol.dfki.uni-sb.de (Stephen Spackman)
- Newsgroups: comp.arch
- Subject: Partial endian solution
- Date: 8 Jan 1993 21:52:35 GMT
- Organization: DFKI Saarbruecken GmbH, D-W 6600 Saarbruecken
- Lines: 29
- Message-ID: <SPACKMAN.93Jan8225718@disco-sol.dfki.uni-sb.de>
- References: <1iig7aINNtc@spim.mti.sgi.com> <1993Jan8.120225.8330@infodev.cam.ac.uk>
- <willmore.726511292@help.cc.iastate.edu> <16294@auspex-gw.auspex.com>
- Reply-To: stephen@acm.org
- NNTP-Posting-Host: disco-sol.dfki.uni-sb.de
- In-reply-to: wally@Auspex.COM's message of 8 Jan 93 20:02:07 GMT
-
- The argument for little endian is: term n of the polynomial representing
- a number is at offset n. That should save some effort now and then and
- makes more conceptual sense to those of us who think in these terms
- (rather than paper notations which, as discussion here shows, are
- totally arbitrary).
-
- The argument for big endian is: sort orders work out to be the same for
- integers and strings. (This is the place where the "order of writing"
- really matters - though it's really pure coincidence that they coincide).
-
- IMO, the sort order argument is weaker than it looks, because the
- topology of strings is rational and not integral - so it's sort of
- natural that they should be different.
-
- That last observation prompts me to suggest that bytesex inconsistency
- should be handled *not* by having byteswap operations, but rather by
- laying out structures and arrays (including strings) in a
- **negativegoing** direction on whatever you deem to be the "hostile"
- architecture (as you might guess from the above, I vote for bigend as
- "hostile"). Except in the case of machines that use inconsistent bit-
- and byte-sex (68000 case in point) this lets you use the *same* layout
- logic for *both* genders.
-
- You can even share structures between the two architectures if one of
- the sharers negates its addresses (whether in software or in hardware).
- ----------------------------------------------------------------------
- stephen p spackman +49 681 302 5288(o) 5282(sec) stephen@acm.org
- dfki / stuhlsatzenhausweg 3 / d-w-6600 saarbruecken 11 / germany
- ----------------------------------------------------------------------
-