Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!elroy.jpl.nasa.gov!jato!mars!kaleb
From: kaleb@mars.jpl.nasa.gov (Kaleb Keithley)
Newsgroups: comp.lang.c
Subject: Re: boolean
Message-ID: <3939@jato.Jpl.Nasa.Gov>
Date: 5 Jun 90 15:58:49 GMT
References: <12986@smoke.BRL.MIL> <5907@buengc.BU.EDU> <4232@castle.ed.ac.uk> <13003@smoke.BRL.MIL> <20.266429f6@spanky.mgi.com> <16784@haddock.ima.isc.com>
Sender: news@jato.Jpl.Nasa.Gov
Reply-To: kaleb@mars.UUCP (Kaleb Keithley)
Organization: Jet Propulsion Laboratory, Pasadena, CA.
Lines: 27

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