Bool ... lol

That is because today''s 32 processors are optimized to do 32bit operations. So if you try and use a bool, which is 8bits, then it must be converted to a 32bit before it can be used.

bool is neccessary for correct functionality.

hehe yeh you should use it, as it makes things more readable. And since generally your not doing math operations on a bool, only if statements, you get next to no slow down for that, I''ll refrain from the long explanation about moving of values aruond in memory etc .

Depends on how / why you are using it, theres surely no correct solution.

(But if the bool is a status for an object, I try to group them all together, and have a single status word, with each bit acting as a single bool flag).

I dunno, I tend to use BOOL all the type now, which is just

typedef int BOOL
 

Because all the windows functions use it.

Bagpuss doing that does save space but it makes it more complex, i.e. you have to remember which bit is what, and it''s also a lot slower. I tend to only use that method when saving to files, but hehe I''m not trying to say don''t use it or anything.

RamboBones, what method of storing and querying boolean values would you suggest taking into consideration eight to thirty-two bit conversions, memory management, etc.? I''d enjoy that long explanation regarding moving values around in memory, if you don''t mind.

________________________________________________
RapscallionGL development continues...
"Optimal decisions, once made, do not need to be changed." - Robert Sedgewick, Algorithms in C

hehe, okay you want the explanation. Note: As stated in my post this explanation is ONLY about how doing 'if' statements on bools brings very little slow down even when compared to 32 bits.

Okay, the reason is quite simple. When doing an 'if' statement the binary code goes something like this, note my binary is scratchy so don't expect anything big

move value(s) to some register, unless it's already there
perform a cmp statement on the two values
to a conditional jump statement

Moving an 8bit value into a register is of course no problem, since some of the register's are 8bits. Since, in this example, or your testing for is true or false you can compare the two 8bit values togehther, you don't need to compare 8bit with 32bit and therefore waste alot of time (see below for reason).

Incase anybody's wondering performing math operations on 8bit values can be slow because generally you have to move the 8bit value into a 32bit register/memory address, unless maybe your doing a math operation on two 8bit values. I say this because I believe you can't do a math operation with one value being 8bit and one value being 32bit or 16bit etc. The slowness comes in when moving the 8bit to a different sized memory address becuase you have to padd with zeros, I'd presume that you'd clear the 32bit area to zero first then move the 8bit value in to the lower part of the 32bit area but hehe like I said my assembler scratchy, but the point is you have to padd with zero's.

Okay I typed that up pretty fast so it's bound to be full of mistakes, or other problems.

If what I've said is total bullshit could someone please tell me. Although I know that the underlying principle behind what I've said should be pretty much okay.

EDIT: Okay so I went and did the other explanation as well, I didn't intend to, but I got carried away.

EDIT2: If you need futher explanation on something then please let me know

EDIT3: Added some more to the explanation

[edited by - RamboBones on July 21, 2003 7:58:32 PM]

[edited by - RamboBones on July 21, 2003 8:07:32 PM]

[edited by - RamboBones on July 21, 2003 8:12:06 PM]

struct padding should help.

Err structs..... what do they have to do with this :S

quite a few bools are part of structs of classes i would think.

edit: OR classes, not of

[edited by - billybob on July 21, 2003 8:42:13 PM]

Yes ! yes its good answers, I make tests,

if(boooool) is faster with an integer but
if(boooool == true) is faster or equal (compare with if(boool == un) ) with the VC++'s booleen,

(equal on a pentium logically, its difficult to say it with my little tests)

then we must specify !

Other good ideas?

Chuck

!o)

[edited by - Chuck3d on July 21, 2003 8:53:18 PM]

quote:

---

Original post by billybob
quite a few bools are part of structs of classes i would think.

edit: OR classes, not of

[edited by - billybob on July 21, 2003 8:42:13 PM]

---

Yes they are but that has no meaning because we''re talking about using the value itself, it could be contained in my arse and it still wouldn''t make a difference, although that could be kind of hard.

Acessing ANY value in a class or struct automatically may bring overhead, so we can ignore that.

you know, it''s not like you''re doing number-crunching on bools... the overhead is in almost all cases insignificant to nonexistent.


bool func() <--- returns 32 bits on a 32 bit system anyway.

bool c = func() <--- copies the first 8 bits from the stack into c.

so instead of copying 32 bits, it copies 8 within the same timeframe. Oooooh, cry me a river.

quote:

---

Original post by RamboBones

quote:

---

Original post by billybob
quite a few bools are part of structs of classes i would think.

edit: OR classes, not of

[edited by - billybob on July 21, 2003 8:42:13 PM]

---

Yes they are but that has no meaning because we''re talking about using the value itself, it could be contained in my arse and it still wouldn''t make a difference, although that could be kind of hard.

Acessing ANY value in a class or struct automatically may bring overhead, so we can ignore that.

---

yes but the whole point of padding is to alleviate wierd addressing by non-32 bit types. anyways, i agree with mith, speed of bools is irrelivant

quote:

---

Original post by RamboBones
hehe, okay you want the explanation. Note: As stated in my post this explanation is ONLY about how doing ''if'' statements on bools brings very little slow down even when compared to 32 bits.

Okay, the reason is quite simple. When doing an ''if'' statement the binary code goes something like this, note my binary is scratchy so don''t expect anything big

move value(s) to some register, unless it''s already there
perform a cmp statement on the two values
to a conditional jump statement

Moving an 8bit value into a register is of course no problem, since some of the register''s are 8bits. Since, in this example, or your testing for is true or false you can compare the two 8bit values togehther, you don''t need to compare 8bit with 32bit and therefore waste alot of time (see below for reason).

Incase anybody''s wondering performing math operations on 8bit values can be slow because generally you have to move the 8bit value into a 32bit register/memory address, unless maybe your doing a math operation on two 8bit values. I say this because I believe you can''t do a math operation with one value being 8bit and one value being 32bit or 16bit etc. The slowness comes in when moving the 8bit to a different sized memory address becuase you have to padd with zeros, I''d presume that you''d clear the 32bit area to zero first then move the 8bit value in to the lower part of the 32bit area but hehe like I said my assembler scratchy, but the point is you have to padd with zero''s.

Okay I typed that up pretty fast so it''s bound to be full of mistakes, or other problems.

If what I''ve said is total bullshit could someone please tell me. Although I know that the underlying principle behind what I''ve said should be pretty much okay.

---

8-bit registers? Not it today''s 32-bit processors. Atleast I KNOW they''re not in most of them. I''m not totally familar with intel''s, but I''ll bet there''s no 8-bit register in an intel 32-bit processor.

Your math example is a bit off as well. Here''s an example

unsigned long ul32 = 1234567;
unsigned char uc8  = 123;

uc8 = ul32+uc8;
// same as

asm
{
lb  $1, 0(sp)
lw  $2, 4(sp)
add $3, $2, $1
sb  $3, 0(sp)
}

ul32= ul32+uc8;
// same as

asm
{
lb  $1, 0(sp)
lw  $2, 4(sp)
add $3, $2, $1
sw  $3, 4(sp)
}

see the difference? lw (load words) vs lb (load bytes) and sw (store word) vs sb (store byte)
same # of instructions. If you''re casting and other stuff there can be a bit difference (ie shifting and whatnot).

There''s actually alot more to it. Don''t know why I expounded on this topic, I just did.
And, FYI, I always use a 32bit value for a boolean.

There are 8bit registerers on today''s CPU''s. I know cause I''ve used them .

As has been mentioned your not going to do number crunching on bools, as someone stated, and when you are using them for other things the speed difference is barely notable.

Guess that finishes this thread off

Not in Intel/AMD/etc CPU's (haven't played with others). What you're thinking of are AL,AH,BL,BH,etc... They aren't actual registers but aliases into the 32-bit registers.

AL = Accumulator Low = bits 0-7 of the accumulator (EAX)
AH = Accumulator High = bits 8-15 of the accumulator
AX = bits 0-15 of the accumulator (so both AL and AH)

Similarly for EBX,ECX,EDX.

Also, I don't think you get a slowdown moving an 8-bit value in memory to/from a 32-bit register when the memory address isn't 32-bit aligned (I could be wrong on this one) since it will always be fully contained within any 32-bit aligned address .


[edited by - joanusdmentia on July 22, 2003 8:26:05 AM]

quote:

---

Original post by Mithrandir
you know, it''s not like you''re doing number-crunching on bools... the overhead is in almost all cases insignificant to nonexistent.

---

Indeed. They use 1/4 of the memory of a 32-bit value. So it''s a question of priorities...



Superpig
- saving pigs from untimely fates, and when he''s not doing that, runs The Binary Refinery.
Enginuity1 | Enginuity2 | Enginuity3