Path: utzoo!attcan!uunet!steinmetz!davidsen From: davidsen@steinmetz.ge.com (William E. Davidsen Jr) Newsgroups: comp.lang.c Subject: Re: Absolute size of 'short' Keywords: unsigned wrap-around Message-ID: <11941@steinmetz.ge.com> Date: 22 Aug 88 17:57:51 GMT References: <214@ISIDAPS5.UUCP> <9641@dartvax.Dartmouth.EDU> <62505@sun.uucp> <11794@steinmetz.ge.com> <2970@tekcrl.CRL.TEK.COM> Reply-To: davidsen@crdos1.UUCP (bill davidsen) Organization: General Electric CRD, Schenectady, NY Lines: 62 In article <2970@tekcrl.CRL.TEK.COM> danw@tekchips.CRL.TEK.COM (Daniel E. Wilson;1432;58-790;;) writes: | > I proposed something like this to X3J11 in the first year or so (I was | > only there two years). What I suggested was size in bytes, allowing: | > int foo*4 | > -or- | > int*4 foo; | > The feeling was that it was (a) not really needed and (b) too much like | > fortran. I like your idea better, but the few cases where you want exact | > size rather than minimum size probably don't justify inclusion. | | I thought this was C not FORTRAN 77. The reason why the size of an | int is not tightly defined is so that the compiler will use the | best size for the computer. Usually so the program will wind up being | faster. I think I should have quoted a bit of the previous posting. The intent was to give the compiler all the information so it could choose the best representation. Currently to get a four byte (or more) integer I say long. dpANS says that this will be at least 32 bits. If I need four bytes and short is 2, int is 4, and long is 8, I could say int*4 and get the best data type which would hold the data. There was no intension of forcing high overhead on any implemention, just giving the compiler more information, like the register declaration. Consider some programs which need at least 48 bit integers. Currently that information has to be carried in the documentation, so you know it runs on a Cray, CDC, mini-super, etc. If I could say int*6 the compiler on a smaller machine now has the option of generating an error "not on this machine, you don't", or generating code which gives me the precision I need, and hopefully a warning that it is being done in software. I hate to say it, but 'noalias' didn't offent me a bit. It was a way to let compilers generate better code, and I didn't have to learn or use it if I chose not to. I believe in telling the compiler as much as I can, because guesses are usually not optimal. | > I would really like to see a "packed struct," also. | | It would seem that a well written compiler would already choose the | best alignments of members in a structure. Also remember that some | types of hardware can't address a word on a byte boundry (PDP-11) and | so this option would end up not being implemented. A good 80x86 compiler | would probably not pad a structure because the hardware doesn't care how | an int is aligned. The problem here is that you and I may disagree about "best alignment". If I need best speed then the compiler probably does that. If I need to get the absolute smallest packing of data, then I can use the 'packed struct' concept. Good compilers for the 80x86 do pack structures, because it makes things run faster. The 80286 takes one (or two) additional clocks to fetch unaligned, as does the 80386 if not aligned mod four. I believe the same is true on the 68k series, but my hardware manual isn't handy. It's a tradeoff between space and speed. The Microsoft C compilers allow the user to comtrol the packing. -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs | seismo}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me