IAR Bool datatype - Page 1
Forum section: electronics / general

author: hamdi.tn
author_rank: Frequent Contributor
timestamp: October 22, 2015, 01:10:34 pm
content: Hi, anyone have an idea how IAR workbench handle bool type,is it implanted to occupy 8bit on memory or just one.Thanks.

author: andersm
author_rank: Super Contributor
timestamp: October 22, 2015, 01:18:56 pm
content: What does the documentation say? It's very likely also target-specific.

author: hamdi.tn
author_rank: Frequent Contributor
timestamp: October 22, 2015, 01:27:21 pm
content: just find the doc , it's an 8bit.http://supp.iar.com/FilesPublic/UPDINFO/004916/arm/doc/EWARM_DevelopmentGuide.ENU.pdf

author: c4757p
author_rank: Super Contributor
timestamp: October 22, 2015, 01:56:38 pm
content: I would have bet money. bool is pretty much always implemented as a full byte - sure, it's not as space-efficient, but 1) it's usually faster to access, and 2) you can make a pointer to it. Any compiler that used single bits for bool would have to automatically upgrade to a full byte for any bool you take the address of.

author: Gall
author_rank: Frequent Contributor
timestamp: October 22, 2015, 03:06:50 pm
content: ISO C standard has no limitation on the sizes of such variables.charis specified as the smallest machine word that is able to contain the ASCII character set. That is, smallest machine word not smaller as 7 bits (8 bits on most modern machines).booldoes not exist in the language itself, it is a typedef for_Boolwhich shall be able to hold "0 or 1", does not matter, how. Most modern systems make bool 8-bit (and just equal to unsigned char).The optimizer may, however, rearrange your variables, as long as you don't obstruct them. In this case bol may take 1 bit or even 0 bits (completely optimized out).

author: hamdi.tn
author_rank: Frequent Contributor
timestamp: October 22, 2015, 04:54:50 pm
content: Quote from: Gall on October 22, 2015, 03:06:50 pmyap , so IAR by adding bool in "stdbool.h" is not doing more that what i can do myself withCode:typedef char bool;#define true 1#define flase 0it can be handy to get a more readable code, but nothing more i guess

author: richardman
author_rank: Frequent Contributor
timestamp: October 26, 2015, 10:55:39 am
content: C99 does specify a _Bool type, spelled that way so that it will be collide any existing code that may use "bool" or "Bool". The size is still up to the implementation - most likely at least a byte as bits are still notaddressableunits. A _Bool data holds either 0 or 1, but the type of a comparison expression is still an int, not a _Bool.

author: Kjelt
author_rank: Super Contributor
timestamp: October 26, 2015, 11:17:19 am
content: Quote from: hamdi.tn on October 22, 2015, 04:54:50 pmIf you define it like that you have a big issue for each value > 1 which can occur since a bool can be a char or even int.true should always be defined as !falsethat is the only way you can prevent any logical comparison errors in the future.

author: newbrain
author_rank: Super Contributor
timestamp: October 26, 2015, 11:56:10 am
content: Quote from: Kjelt on October 26, 2015, 11:17:19 amCould you give an example where this makes a real difference?To the best of my knowledge, !false == 1 so, unless there something I'm missing, the definitions are exactly the same.That said, comparing to true (in whatever way it's defined) is, generally speaking, not a wise thing to do and most certainly redundant.

author: hamdi.tn
author_rank: Frequent Contributor
timestamp: October 26, 2015, 12:45:34 pm
content: Quote from: newbrain on October 26, 2015, 11:56:10 amif false=0, !false=0xffbut i think what he meant is that if it's not 0 false then any value should be considered true ? am i right ?

author: c4757p
author_rank: Super Contributor
timestamp: October 26, 2015, 01:25:55 pm
content: Along these lines, there is an interesting difference between _Bool and int. C99 made it so youcancompare a _Bool withtruevalidly - just watch out for the gotcha:Code:#include <stdbool.h>int main (void){volatile bool x = 2;volatile char y = 2;volatile char a = (x == true);volatile char b = (y == true);return 0;}Code:volatile bool x = 2;c:81 e0ldir24, 0x01; 1e:89 83stdY+1, r24; 0x01When storing 2 into abool, it doesn't store 2! It stores 0x01, which is its internal representation oftrue.Code:volatile char y = 2;10:82 e0ldir24, 0x02; 212:8a 83stdY+2, r24; 0x02Storing 2 into acharstores 0x02, business as usual.Code:volatile char a = (x == true);14:89 81lddr24, Y+1; 0x0116:8b 83stdY+3, r24; 0x03Comparing x == true, because it stuffed a 1 in there to begin with, it can just retrieve the value.Code:volatile char b = (y == true);18:9a 81lddr25, Y+2; 0x021a:81 e0ldir24, 0x01; 11c:91 30cpir25, 0x01; 11e:09 f0breq.+2; 0x22 <__zero_reg__+0x21>20:80 e0ldir24, 0x00; 022:8c 83stdY+4, r24; 0x04Comparing y == true -trueis not itself a _Bool, so this is just equivalent to (y == 1)!So, two gotchas:- Comparison ofboolwithtrueis done by changing the way the data isstored, which meansnever ever everalias a bool as an int. If you forced it to store a 2 in there with something along the lines of*(int*)&x = 2;it would not compare that properly.- Comparison ofintwithtruedoesn't just magically work becausetrueis not a _Bool.Note that Ido not recommenddoing this. I don't particularly like that they changed the comparison semantics forbool. It works just fine if you do it right, but will confuse the shit out of somebody who misunderstands it, and certainly is not compatible with pre-C99 code that defined itself a bool type.C's implicit boolean semantics - justif(x)rather thanif(x == true)-just works.

author: Ian.M
author_rank: Super Contributor
timestamp: October 26, 2015, 02:58:47 pm
content: Any time you need a boolean result from a non-boolean expression simply double negate ( !!(x) ).

author: c4757p
author_rank: Super Contributor
timestamp: October 26, 2015, 03:04:21 pm
content: I've seen that, but I've literally never needed it. C treats numbers as boolean in all the right places anyway. Got a use case?

author: Ian.M
author_rank: Super Contributor
timestamp: October 26, 2015, 03:11:27 pm
content: Yep. If you are extracting bits from a number using bitmasks, when you assign the result to a 1 bit bitfield, if you don't double negate, it truncates so you get the LSB rather than the logical value.

author: c4757p
author_rank: Super Contributor
timestamp: October 26, 2015, 03:13:44 pm
content: Ah, bitfields are definitely a special case. I'd probably not double-negate, as I don't like doing things that require one to remember what !0 equals. I think I'd do something like(x ? 1 : 0), that's more explicit.In fact, any time I want a boolean to expand to aspecific valueI write something like that, even if the value is supposed to be obvious. I'll doint x = !yif I'm using int as a boolean and want it to be "false", but if I'm going to use itnumericallyas a zero, I write that. Explicit is better than implicit.

author: Kjelt
author_rank: Super Contributor
timestamp: October 26, 2015, 04:03:07 pm
content: Quote from: hamdi.tn on October 26, 2015, 12:45:34 pmYes the whole point is that there are compilers that put bools into for instance an unsigned char which per definition can have any 8 bit value.So if you make a logic decision, you have to make sure there are only two logical possibilities. This can be done by a typedef enum forcing the bool to be false or true but then make sure you cast each logical decision, and thus forcing the outcome in any of the two possibilities.There are numerous of other ways to do that but it all depends on the compiler in the end, if they are truly boolean logic in the end.If your compiler supports C99 <stdbool.h> it probably will be OK (always check and doublecheck), and values other than 0 will probably be stored as a true or 1.In our company we use platforms with many compilers from 6 vendors and many divers microcontrollers and we had a lot of problems with this bool issue.Modules that ran perfectly on one compiler had issues on another and one of the big mischiefs was the boolean operator (and programmers that did not comply 100% to the rules).So in the end to get rid of this issue we just defined our own bool_t so it is standardized within our entire platform.

author: newbrain
author_rank: Super Contributor
timestamp: October 26, 2015, 08:58:52 pm
content: Quote from: hamdi.tn on October 26, 2015, 12:45:34 pmNo, not in anything you can still call C, from the C99 standard (draft, admittedly):QuoteAnd it's been this way since K&R...c4757p: Excellent and detailed example. Still, you mention something I don't understand:Quote from: c4757pTo me the semantic is exactly the same as always: bool (actually, _Bool) undergoes the "usual arithmetic conversions", and being the lowest ranked unsigned type, is simply translated to 1 in all situations.The following two clauses apply:QuoteandQuoteBut this is nitpicking. In short, a thousand times this:Quote

author: c4757p
author_rank: Super Contributor
timestamp: October 26, 2015, 09:10:59 pm
content: Quote from: newbrain on October 26, 2015, 08:58:52 pmThey changed the semantics ofBooleans, not of the type itself. C programmers pre-C99 had been quite well trainednotto think of a Boolean as a one-bit value, and that's different now.

author: newbrain
author_rank: Super Contributor
timestamp: October 26, 2015, 09:20:14 pm
content: Quote from: c4757p on October 26, 2015, 09:10:59 pmCristal clear now, thanks! I was wondering if I was missing something subtler.

author: westfw
author_rank: Super Contributor
timestamp: October 27, 2015, 12:46:23 am
content: QuoteHmm. ARM bit-banding gives you addressable single bits...

author: andersm
author_rank: Super Contributor
timestamp: October 27, 2015, 06:26:27 am
content: Quote from: westfw on October 27, 2015, 12:46:23 amOnly for the first megabyte of RAM, and the bigger chips are already exceeding that limit. It's also an optional feature in the M0-M4, and not supported at all in the M7.

author: westfw
author_rank: Super Contributor
timestamp: October 27, 2015, 09:03:09 am
content: Yes, only on the ARMs that have bit-banding. And hopefully by the time you have more than 1MB of RAM, you stop worrying about the size of a Bool.It might be somewhat awkward to have "const Bool x" (in flash), and "Bool y" (in RAM) have different sizes (or perhaps not; you shouldn't be able to tell.)It still might be an "interesting" feature for a compiler vendor to implement...