karl@haddock.ima.isc.com (Karl Heuer) (06/05/90)
In article <20.266429f6@spanky.mgi.com> Cepek@MGI.COM writes: >Among our "company-common" .H files, the compiler/target-machine dependent >one includes the following pseudo-types: >#define bool int8 /* smallest entity for TRUE or FALSE */ >#define boolean int /* fast/simple entity for TRUE or FALSE */ > >This allows the programmer to choose between space and speed. Defining both `bool' and `boolean', with different meanings, is probably a mistake. The very existence of a typedef named `int8' is questionable. (Yes, I know the reason.) And it's probably not worthwhile to have the `small' type, since if you have enough of them that the factor of (probably) 4 is significant, you might as well also go for the factor of (probably) 8 that you get by using packed bit vectors. (The time cost isn't as bad as one often hears, since you don't normally have to go around packing and unpacking the things--the common operations on booleans are test, set, and clear, none of which is hard. The only real pain is that you can't use normal C syntax; you have to go through macros.) Karl W. Z. Heuer (karl@ima.ima.isc.com or harvard!ima!karl), The Walking Lint Followups to comp.lang.c.
kaleb@mars.jpl.nasa.gov (Kaleb Keithley) (06/05/90)
In article <20.266429f6@spanky.mgi.com> Cepek@MGI.COM writes: >Among our "company-common" .H files, the compiler/target-machine dependent >one includes the following pseudo-types: >#define bool int8 /* smallest entity for TRUE or FALSE */ >#define boolean int /* fast/simple entity for TRUE or FALSE */ > >This allows the programmer to choose between space and speed. All the compilers I've seen for 80x86 (excepting 80[34]86) always allocate at least one word in the stack frame for variables, even if only one byte is needed. I surmised that it was to keep the stack pointer aligned to an even address, which allows for a small speed improvement on the 8086/80186/80286 (but no speed improvement on 8088/80188.) Static variables were allocated less discriminitely, but were suitably aligned as required. Not having worked with 680x0, so I can't comment reliably on that architecture, and I haven't delved into the code generated by the compiler on our SPARCS, but in both cases, I'd hazard a guess that a similar consideration might come into play. So, IMHO, I'd guess that letting the programmer choose between space and speed would be halfty-fifty at best. Half a chance at getting it right, 50% chance of getting it wrong. My rule of thumb has always been: "Make it work first, then make it fast." kaleb@thyme.jpl.nasa.gov Jet Propeller Labs Kaleb Keithley
cepek@spanky.mgi.com (06/06/90)
In article <16784@haddock.ima.isc.com>, karl@haddock.ima.isc.com (Karl Heuer) writes: > In article <20.266429f6@spanky.mgi.com> Cepek@MGI.COM writes: >> Among our "company-common" .H files, the compiler/target-machine dependent >> one includes the following pseudo-types: >> #define bool int8 /* smallest entity for TRUE or FALSE */ >> #define boolean int /* fast/simple entity for TRUE or FALSE */ >> >> This allows the programmer to choose between space and speed. > > Defining both `bool' and `boolean', with different meanings, is probably a > mistake. The very existence of a typedef named `int8' is questionable. (Yes, > I know the reason.) I will (have) start(ed) a separate thread for this topic. > And it's probably not worthwhile to have the `small' > type, since if you have enough of them that the factor of (probably) 4 is > significant, you might as well also go for the factor of (probably) 8 that you > get by using packed bit vectors. (The time cost isn't as bad as one often > hears, since you don't normally have to go around packing and unpacking the > things--the common operations on booleans are test, set, and clear, none of > which is hard. The only real pain is that you can't use normal C syntax; you > have to go through macros.) OK, so to summarize the ups and downs of both ways of implementing "bool": _int_8_bool_ _bitfield_bool_ normal C syntax versus using "painful" macros quicker versus "not too bad" time cost less dense versus more dense (twice) The most significant item for me, a programmer using this, is item #1. The last thing I want to have to cope with is an awkward syntax for doing something simple. Also, switching from using a "bool" to using a "boolean" (or vice versa), is very easy (if rare). Item 2 is nice, but not significant (for us). Item 3 is also not very important in our situation; we appreciate the extra density beyond "boolean", but maximal density isn't important. - - - - - - - - - - - - - - - - - - - - I'm not trying to start a war here. I've only been using C for 4 years (programming for 12). I'm all for learning new methods and discussing alternative approaches; in fact I enjoy it. +------------------------------------------------------------------------+ | Michael Cepek "Engage." | | Programmer/Analyst | | Internet: Cepek@MGI.COM | | Management Graphics, Inc. Voice: +1 612/851-6112 | | 1401 East 79th Street Operator: +1 612/854-1220 | | Minneapolis, MN 55425 USA Fax: +1 612/854-6913 | +------------------------------------------------------------------------+
karl@haddock.ima.isc.com (Karl Heuer) (06/11/90)
In article <24.266bdce0@spanky.mgi.com> cepek@spanky.mgi.com writes: >OK, so to summarize the ups and downs of both ways of implementing "bool": > _int_8_bool_ _bitfield_bool_ > normal C syntax versus using "painful" macros > quicker versus "not too bad" time cost > less dense versus more dense (twice) No, it's 8 times more dense (32 per word instead of 4, in the model I was using). And this table ignores the third option of using `int'. My argument is that either you have a large array of booleans so that the inconvenience of the macros is outweighed by the space savings, or else you don't, in which case there's also probably no advantage to using `char' rather than `int'. Karl W. Z. Heuer (karl@ima.ima.isc.com or harvard!ima!karl), The Walking Lint