Author Topic: IAR Bool datatype  (Read 15061 times)

0 Members and 1 Guest are viewing this topic.

Offline hamdi.tnTopic starter

  • Frequent Contributor
  • **
  • Posts: 623
  • Country: tn
IAR Bool datatype
« on: October 22, 2015, 01:10:34 pm »
Hi, anyone have an idea how IAR workbench handle bool type,
is it implanted to occupy 8bit on memory or just one.
Thanks.
 

Offline andersm

  • Super Contributor
  • ***
  • Posts: 1198
  • Country: fi
Re: IAR Bool datatype
« Reply #1 on: October 22, 2015, 01:18:56 pm »
What does the documentation say? It's very likely also target-specific.

Offline hamdi.tnTopic starter

  • Frequent Contributor
  • **
  • Posts: 623
  • Country: tn
Re: IAR Bool datatype
« Reply #2 on: October 22, 2015, 01:27:21 pm »
 

Offline c4757p

  • Super Contributor
  • ***
  • Posts: 7799
  • Country: us
  • adieu
Re: IAR Bool datatype
« Reply #3 on: October 22, 2015, 01:56:38 pm »
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.
No longer active here - try the IRC channel if you just can't be without me :)
 

Offline Gall

  • Frequent Contributor
  • **
  • Posts: 310
  • Country: ru
Re: IAR Bool datatype
« Reply #4 on: October 22, 2015, 03:06:50 pm »
ISO C standard has no limitation on the sizes of such variables. char is 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). bool does not exist in the language itself, it is a typedef for _Bool which 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).
The difficult we do today; the impossible takes a little longer.
 

Offline hamdi.tnTopic starter

  • Frequent Contributor
  • **
  • Posts: 623
  • Country: tn
Re: IAR Bool datatype
« Reply #5 on: October 22, 2015, 04:54:50 pm »
ISO C standard has no limitation on the sizes of such variables.

yap , so IAR by adding bool in "stdbool.h" is not doing more that what i can do myself with

Code: [Select]
typedef char bool;
#define true 1
#define flase 0

it can be handy to get a more readable code, but nothing more i guess
 

Offline richardman

  • Frequent Contributor
  • **
  • Posts: 427
  • Country: us
Re: IAR Bool datatype
« Reply #6 on: October 26, 2015, 10:55:39 am »
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 not addressable units. A _Bool data holds either 0 or 1, but the type of a comparison expression is still an int, not a _Bool.
// richard http://imagecraft.com/
JumpStart C++ for Cortex (compiler/IDE/debugger): the fastest easiest way to get productive on Cortex-M.
Smart.IO: phone App for embedded systems with no app or wireless coding
 

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 6459
  • Country: nl
Re: IAR Bool datatype
« Reply #7 on: October 26, 2015, 11:17:19 am »
Code: [Select]
typedef char bool;
#define true 1
#define false 0
 
If 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 !false
that is the only way you can prevent any logical comparison errors in the future.


 

Offline newbrain

  • Super Contributor
  • ***
  • Posts: 1714
  • Country: se
Re: IAR Bool datatype
« Reply #8 on: October 26, 2015, 11:56:10 am »
true should always be defined as !false
that is the only way you can prevent any logical comparison errors in the future.

Could 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.
Nandemo wa shiranai wa yo, shitteru koto dake.
 

Offline hamdi.tnTopic starter

  • Frequent Contributor
  • **
  • Posts: 623
  • Country: tn
Re: IAR Bool datatype
« Reply #9 on: October 26, 2015, 12:45:34 pm »
true should always be defined as !false
that is the only way you can prevent any logical comparison errors in the future.

Could 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.

if false=0, !false=0xff
but i think what he meant is that if it's not 0 false then any value should be considered true ? am i right ?
« Last Edit: October 26, 2015, 12:48:32 pm by hamdi.tn »
 

Offline c4757p

  • Super Contributor
  • ***
  • Posts: 7799
  • Country: us
  • adieu
Re: IAR Bool datatype
« Reply #10 on: October 26, 2015, 01:25:55 pm »
Along these lines, there is an interesting difference between _Bool and int. C99 made it so you can compare a _Bool with true validly - just watch out for the gotcha:

Code: [Select]
#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: [Select]
    volatile bool x = 2;
   c: 81 e0        ldi r24, 0x01 ; 1
   e: 89 83        std Y+1, r24 ; 0x01

When storing 2 into a bool, it doesn't store 2! It stores 0x01, which is its internal representation of true.

Code: [Select]
    volatile char y = 2;
  10: 82 e0        ldi r24, 0x02 ; 2
  12: 8a 83        std Y+2, r24 ; 0x02

Storing 2 into a char stores 0x02, business as usual.

Code: [Select]
    volatile char a = (x == true);
  14: 89 81        ldd r24, Y+1 ; 0x01
  16: 8b 83        std Y+3, r24 ; 0x03

Comparing x == true, because it stuffed a 1 in there to begin with, it can just retrieve the value.

Code: [Select]
    volatile char b = (y == true);
  18: 9a 81        ldd r25, Y+2 ; 0x02
  1a: 81 e0        ldi r24, 0x01 ; 1
  1c: 91 30        cpi r25, 0x01 ; 1
  1e: 09 f0        breq .+2      ; 0x22 <__zero_reg__+0x21>
  20: 80 e0        ldi r24, 0x00 ; 0
  22: 8c 83        std Y+4, r24 ; 0x04

Comparing y == true - true is not itself a _Bool, so this is just equivalent to (y == 1)!

So, two gotchas:

- Comparison of bool with true is done by changing the way the data is stored, which means never ever ever alias 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 of int with true doesn't just magically work because true is not a _Bool.

Note that I do not recommend doing this. I don't particularly like that they changed the comparison semantics for bool. 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 - just if(x) rather than if(x == true) - just works.
« Last Edit: October 26, 2015, 02:33:10 pm by c4757p »
No longer active here - try the IRC channel if you just can't be without me :)
 

Offline Ian.M

  • Super Contributor
  • ***
  • Posts: 12807
Re: IAR Bool datatype
« Reply #11 on: October 26, 2015, 02:58:47 pm »
Any time you need a boolean result from a non-boolean expression simply double negate ( !!(x) ).
 

Offline c4757p

  • Super Contributor
  • ***
  • Posts: 7799
  • Country: us
  • adieu
Re: IAR Bool datatype
« Reply #12 on: October 26, 2015, 03:04:21 pm »
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?
No longer active here - try the IRC channel if you just can't be without me :)
 

Offline Ian.M

  • Super Contributor
  • ***
  • Posts: 12807
Re: IAR Bool datatype
« Reply #13 on: October 26, 2015, 03:11:27 pm »
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. 
 

Offline c4757p

  • Super Contributor
  • ***
  • Posts: 7799
  • Country: us
  • adieu
Re: IAR Bool datatype
« Reply #14 on: October 26, 2015, 03:13:44 pm »
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 a specific value I write something like that, even if the value is supposed to be obvious. I'll do int x = !y if I'm using int as a boolean and want it to be "false", but if I'm going to use it numerically as a zero, I write that. Explicit is better than implicit.
« Last Edit: October 26, 2015, 03:18:47 pm by c4757p »
No longer active here - try the IRC channel if you just can't be without me :)
 

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 6459
  • Country: nl
Re: IAR Bool datatype
« Reply #15 on: October 26, 2015, 04:03:07 pm »
but i think what he meant is that if it's not 0 false then any value should be considered true ? am i right ?
Yes 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.
 

Offline newbrain

  • Super Contributor
  • ***
  • Posts: 1714
  • Country: se
Re: IAR Bool datatype
« Reply #16 on: October 26, 2015, 08:58:52 pm »
if false=0, !false=0xff

No, not in anything you can still call C, from the C99 standard (draft, admittedly):
Quote
The result of the logical negation operator ! is 0 if the value of its operand compares unequal to 0, 1 if the value of its operand compares equal to 0. The result has type int.
The expression !E  is equivalent to (0==E)
And it's been this way since K&R...

c4757p: Excellent and detailed example. Still, you mention something I don't understand:
Quote from: c4757p
I don't particularly like that they changed the comparison semantics for bool.

To 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:
Quote
Otherwise, if both operands have signed integer types or both have unsigned integer types, the operand with the type of lesser integer conversion rank is converted to the type of the operand with greater rank.
and
Quote
Otherwise, if the type of the operand with signed integer type can represent all of the values of the type of the operand with unsigned integer type, then the operand with unsigned integer type is converted to the type of the operand with signed integer type.

But this is nitpicking. In short, a thousand times this:
Quote
C's implicit boolean semantics - just if(x) rather than if(x == true) - just works.
Nandemo wa shiranai wa yo, shitteru koto dake.
 

Offline c4757p

  • Super Contributor
  • ***
  • Posts: 7799
  • Country: us
  • adieu
Re: IAR Bool datatype
« Reply #17 on: October 26, 2015, 09:10:59 pm »
c4757p: Excellent and detailed example. Still, you mention something I don't understand:
Quote from: c4757p
I don't particularly like that they changed the comparison semantics for bool.

To 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.

They changed the semantics of Booleans, not of the type itself. C programmers pre-C99 had been quite well trained not to think of a Boolean as a one-bit value, and that's different now.
No longer active here - try the IRC channel if you just can't be without me :)
 

Offline newbrain

  • Super Contributor
  • ***
  • Posts: 1714
  • Country: se
Re: IAR Bool datatype
« Reply #18 on: October 26, 2015, 09:20:14 pm »
They changed the semantics of Booleans, not of the type itself. C programmers pre-C99 had been quite well trained not to think of a Boolean as a one-bit value, and that's different now.

Cristal clear now, thanks! I was wondering if I was missing something subtler.
Nandemo wa shiranai wa yo, shitteru koto dake.
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4196
  • Country: us
Re: IAR Bool datatype
« Reply #19 on: October 27, 2015, 12:46:23 am »
Quote
The size [of Bool] is still up to the implementation - most likely at least a byte as bits are still not addressable units.
Hmm.  ARM bit-banding gives you addressable single bits...
 

Offline andersm

  • Super Contributor
  • ***
  • Posts: 1198
  • Country: fi
Re: IAR Bool datatype
« Reply #20 on: October 27, 2015, 06:26:27 am »
ARM bit-banding gives you addressable single bits...
Only 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.

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4196
  • Country: us
Re: IAR Bool datatype
« Reply #21 on: October 27, 2015, 09:03:09 am »
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...
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf