Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84 SMI; site sun.uucp Path: utzoo!watmath!clyde!burl!ulysses!gamma!epsilon!zeta!sabre!petrus!bellcore!decvax!decwrl!sun!guy From: guy@sun.uucp (Guy Harris) Newsgroups: net.lang.c Subject: Re: Uses of "short" ? Message-ID: <2801@sun.uucp> Date: Sun, 15-Sep-85 19:44:58 EDT Article-I.D.: sun.2801 Posted: Sun Sep 15 19:44:58 1985 Date-Received: Wed, 18-Sep-85 02:41:57 EDT References: <486@houxh.UUCP> <2761@sun.uucp> <697@cyb-eng.UUCP> <2789@sun.uucp> <710@cyb-eng.UUCP> Organization: Sun Microsystems, Inc. Lines: 52 > You are invited to write a 3Com Ethernet driver that works on a PC > (16-bit int) and on a Cyb machine (32-bit int) without referring to longs > or shorts. I.e., a 16-bit hardware register is a 16-bit hardware register, > despite your desire for abstraction. The object being described is a 16-bit hardware register. As such, technically, there's no abstract way to describe it in C except *maybe* a bitfield. What happens on an 18-bit machine? One hopes that 1) the register is an 18-bit register and 2) "short" is 18 bits on the machine (or that both are 36 bits). For that matter, what if the board has memory-mapped I/O on one machine, but not on another (i.e., you have to issue I/O instructions to read the device registers)? If you truly want a portable driver, you'll have to pick a level of abstraction *above* the device registers and have 99% of the code in the driver deal with that abstraction rather than the device registers. The Ethernet driver has to deal with a lot of objects that aren't part of the board - a 4.2 driver, for instance, has to talk to the various protocol modules above it. That code doesn't have to get up-close and personal with the machine to the degree that code that fiddles hardware registers does. Also, if you can find *any* statement where I say that the use of "short" and "long" violates proper use of abstractions, and should be avoided, I'd really like to see it. In fact, I believe quite the opposite. In some cases, "int" better fits the abstract object being described than "short" or "long" does, and in some cases "short" or "long" better fit it. "short" and "int" capture a requirement that -32767 to 32767 be the range of values of this (integral) object equally well. However, "short" specifies the amount of space required more stringently than "int" does, and "int" (sort of) specifies the required efficiency for instructions that manipulate the object better than "short" does. Choose the one that specifies the part you *do* care about (and in the case of a 16-bit device register, "short", while *not* perfectly specifying this, does so better than "int" does). If you want something that has a range of values of -2147483647 to 2147483647 (*not* -2147483648 - the Sperry 100 users will get a bit annoyed if you assume that all UNIX machines can represent -2147483648), you should use "long", even if you "know" that you'll be running on a machine with 32-bit (or wider) "int"s. > I nevertheless believe, for instance, that when Internet protocol specifies > that the header checksum is a 16-bit 2's-complement number, it is wise to > comply, if you want the packets to fly properly. So, if your language has a primitive integral data type that specifies that objects of the type are 16 bits and that arithmetic is done in 1's complement (not 2's complement - check the IP spec again), use it. There is no way in C to say "I want a 16-bit 1's complement number." (Note that the 4.2BSD VAX and Sun IP checksum routines both drop into assembler language at times.) Guy Harris