Article View: comp.arch
Article #11670Re: Endianess resolved, by one who knows.
From: Martin Golding
Date: Sat, 18 May 1991 01:34
Date: Sat, 18 May 1991 01:34
56 lines
3116 bytes
3116 bytes
In <16077@ganymede.inmos.co.uk> davidb@brac.inmos.co.uk (David Boreham) writes:
>In article <m0jd17b-0003uJC@rht32.pcs.com> hgw@RHT32.PCS.COM (h.-g. willers) writes:
>>We are considering to build a VME-based computer board using a
>>little endian processor. Is there any reason to swap bytes
>>and shorts going from and to the (big endian) VME, or are things just more
>>easy when we do not swap anything?
>Interesting question !
>Since the endian-swap depends upon the data (you would do it for
>byte data but not for 32-bit integers), the swap needs to be
>configurable. Also for VME there are about 12 potentially useful
>different swap variations---caused by the mixture of 8,16 and 32-bit
>datapaths to SLAVEs interworking with a 32-bit RISC.
>Probably overkill---but there's a Texas chip which does all this
>for about $50.
Having built a system with one processor each perverse and normal byte
sex on a single bus (which was supposed to have perverse byte sex, but
some of the device controllers were normal), I can assure you that I know
precisely what to do under these circumstances.
Join a new company :-) no, that's not right:
1) Store data correctly for the processor. There is a company that
went broke trying to store data the wrong way, and have auto-swapping
hardware (the product was based on a 32x32, so one could surmise
other causes.)
2) Identify the places where byte sex _must_ be changed. This should
be limited to device drivers, and any space shared with other processors.
(We made a rule about shared memory that ALL shared data was to be byte
normal, and the perverted processor had the responsibility to 'fix' things
since it was ALL HIS FAULT.
It's probably not cost effective to provide special hardware for swapping.
If you do choose to do so, I'd suggest a general purpose swapper
(write to <arbitrary address>, read swapped from <arbitrary address>)
since you don't want data fiddled with most of the time, and when you
do, it's usually in some odd address space.
It's not an extremely difficult job, until you try to use the kernel
debugger (or equivalent) to look at the i/o space, and try to remember
whether 00400 is really 1 in that register...
Above all, relax, don't worry, have a home brew :-)
(Notice that although I have used the correct terminology, I have not
ascribed any particulat endianess to those terms.)
Martin Golding | sync, sync, sync, sank ... sunk:
Dod #0236 | He who steals my code steals trash.
A poor old decrepit Pick programmer. Sympathize at:
{mcspdx,pdxgate}!adpplz!martin or martin@adpplz.uucp
Technical Details
Message-ID:
<748@adpplz.UUCP>Path:
arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!think.com!mintaka!ogicse!cvedc!mcspdx!adpplz!martinReferences:
<m0jd17b-0003uJC@rht32.pcs.com> <16077@ganymede.inmos.co.uk>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!think.com!mintaka!ogicse!cvedc!mcspdx!adpplz!martin From: martin@adpplz.UUCP (Martin Golding) Newsgroups: comp.arch Subject: Re: Endianess resolved, by one who knows. Message-ID: <748@adpplz.UUCP> Date: 18 May 91 01:34:19 GMT References: <m0jd17b-0003uJC@rht32.pcs.com> <16077@ganymede.inmos.co.uk> Organization: ADP Dealer Services R&D, Portland, OR Lines: 56