Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!yale!cmcl2!adm!smoke!gwyn
From: gwyn@smoke.brl.mil (Doug Gwyn)
Newsgroups: comp.lang.c
Subject: Re: What breaks?
Message-ID: <14918@smoke.brl.mil>
Date: 21 Jan 91 21:27:29 GMT
References: <1991Jan21.025706.7152@zoo.toronto.edu> <1991Jan21.113942.24379@watmath.waterloo.edu> <1991Jan21.130932.2982@odin.diku.dk>
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Lines: 18

In article <1991Jan21.130932.2982@odin.diku.dk> thorinn@diku.dk (Lars Henrik Mathiesen) writes:
>The TCP _protocol_ defines certain fields as exactly 32 bits in a
>specific order on the wire. For any machine the network interface will
>define a mapping between bits-on-the-wire and bits-in-machine-words;
>in a 36-bit-word machine this mapping cannot be as simple as in a
>byte-addressable machine.

It should involve roughly the same amount of effort.  For example, define
the system's internal representation of packet data as an array of words
with the data contained in the low-order 32 bits of each word (also define
whether big- or little-endian).  At some point the network hardware
interface is going to have to be spoon-fed the 32 bits in some form that
it can cope with; it is easy enough to take care of the unpacking at that
point.

I've had a fair amount of experience in dealing with communication between
36-bit and 8-bit addressable architectures (DEC mainframes vs. minis);
these issues have been solved long ago, and it wasn't very difficult.