Date: Sat, 24 Feb 2001 20:14:50 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: n@nectar.com (Jacques A. Vidrine) Cc: tlambert@primenet.com (Terry Lambert), brad.knowles@skynet.be (Brad Knowles), keichii@peorth.iteration.net (Michael C . Wu), jcm@FreeBSD-uk.eu.org (j mckitrick), freebsd-chat@FreeBSD.ORG Subject: Re: bad programming practice? Message-ID: <200102242014.NAA23639@usr05.primenet.com> In-Reply-To: <20010224090425.A30456@spawn.nectar.com> from "Jacques A. Vidrine" at Feb 24, 2001 09:04:25 AM
next in thread | previous in thread | raw e-mail | index | archive | help
> > (personally, I still think there should be sized types, > > Do you mean as in <stdint.h>, or something else? I mean that: sizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(long) has always been a handicap for the C language, and continues to be a handicap to this day. When you get an architecture where this is 8,16,32,32, everything is OK. When you get one where it's 8,16,16,32, it's also OK (barely). When you get one where it's 8,16,32,64, or (particularly) 8,16,64,64, or 8,32,64,64, then there's hell to pay when mapping device registers. The language needs sized types, since it's intended to be capable of mapping hardware, directly. Packing is another problem, if you want to use a structure to aggregate disparate fields into a consecutive region (as much hardware does with, for example, control registers or I/O space). Bitfields have always been more of an abomination than bit manipulation in objects of "at least this big" types, but the "at least this big" typing has led to a lot of glue, like that used with FD_SET. For things you don't care about, there need to be "at least" sizes; this lets the machine pick a "preferred" size for both registers and bus transfers. Does anyone remember the 68k? The size of "int" varied between 16 bit (the maximum single cycle fetch size) and 32 (the register size). Which was correct depended on whether "most efficient" meant "capable of being fetched in the least number of cycles" or "biggest object upon which a single operation can operate". The former was more efficient for I/O, the latter for sustained bit and other operations. X3J11 really copped out when it decided to try to be uncontroversial, at the same time letting compiler companies dictate that there would be no linker changes required. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200102242014.NAA23639>