Boolean? Really?
User Name
Posts: 1,451
Edit: Matter is resolved. Nothing to see here. Please move along.
Could someone explain to me the need for a separate category of boolean instructions and variables? Any variable is either zero or not zero, and on that basis alone is perfectly serviceable for use in conditional branching.[\s]
Could someone explain to me the need for a separate category of boolean instructions and variables? Any variable is either zero or not zero, and on that basis alone is perfectly serviceable for use in conditional branching.[\s]
Comments
I think this is what you are asking...
Bean
Especially in high level languages like C.
I think you express the problem right there. In that scheme:
1 is TRUE
0 is FALSE
101 is TRUE
but wait a minute, NOT 101 is 010 which is not zero therefor it's TRUE. So we have NOT TRUE is TRUE!
All the above in binary and pseudo code. Depending on what language you are using and how it treats TRUE, FALSE, if, and whatever different NOT operators it has you get different results.
This is why high level languages have types, boolean, integer, float, whatever.
One of those scenarios is doing conditional math.
X := 50 & ( y <= 1)
( y <= 1) will evaluate to either 0, for false, or -1 for true. The AND operation, &, works with the value 50, resulting in either 0 or 50, due to all bits being set.
In systems where True is "1", a multiply is generally used, and the P1 has no multiply instruction. However, even when there is a multiply instruction, the -1 form of true is faster and smaller in most cases, due to how the bit operations work.
If your code is math heavy, you may find conditionals expressed in this way, rather than branches, generate more efficient and smaller code.
Should you plan to capture this in a variable, or use variables in tandem with booleans and compares, having a variable type helps to insure you are working with the values you think you are.
Many Processor systems use exactly that for Boolean,
- Memory is cheap, and coders are lazy.
However, in the world of Embedded control, Boolean can represent a single Flag, or Pin.
There a separate category of boolean instructions and variables can be very useful.
Even some ARM cores patch around this, by mapping single bits to memory locations on hardware.
Proper microcontrollers like the 8051, have special boolean opcodes and can JB/JNB/JBC/CPL 256 separate single bit memory locations.
When that variable is controlling the bits of an IO port you want to be a little more discerning.
I'm glad you mention this. I found this terribly misleading when I first read it in the Propeller Manual many moons ago. I wondered if, for example, I could only test entities that were either 0x0 or 0xFFFFFFFF. It seemed horribly inconvenient and bizarre. Of course a little experimentation revealed it not to be the case.
But until your post I didn't know why such a mention would even be made in the Propeller Manual. OTOH, I can't imagine writing the result of a boolean operation to a hardware port.
@everyone who responded: Thank you for your well-considered responses.
@Seairth: Why not now? Is there a moratorium on questions?
OTOH, if it was done 40 years ago and with a PDP-8, I retract everything I just said.
Port.Pin := (Heater < SetPoint);
That is directly writing the result of a boolean operation to a hardware port.
Huh? What if I want to clear pins 0 and 1 without affecting any others?
Toggle a bit from one state to the other?
Output seven-segment data to a port:
I could go on but I fear I've belabored the point already.
You might also be familiar with how ARM GPIO pins are written.
My code was not Spin, and uses no masking or shifting on the MCU it compiles to.
You were the one who claimed they could not imagine writing the result of a boolean operation to a hardware port.
You seem to be wanting to re-phrase that, now an example has been provided ?
"writing the result of a boolean operation to a hardware port."
I'll let others judge what that proves
A one bit port can output a high or low, 1 or 0, TRUE or FALSE. The later is a BOOLEAN expression.
Not so multiple bit wide ports of course.
The treatment/representation/syntax for these things varies from language to language. It's been know to trip me up on my journey from ALGOL, to CORAL, to PL/M, to C, to Spin, to JavaScript....
Perhaps you could flesh out your code example a bit (no pun intended). Your example wasn't exactly ready for prime time. And I refuse to fill in the blanks for you.
You asked why, and a few of us stepped up and provided cases that support the why.
The one I gave does have code speed and size advantages in SPIN.
In PASM, it is common to set a long to all ones and use that as the basis for a lot of stuff. Doing that can avoid some operations and when combined with conditional execution, provides a fairly direct mapping to what SPIN would do.
Of course anyone can debate the worth, and or need. One instruction can be Turing complete, but impractical.
Like anything, it's there to give you options. Not having it there doesn't make sense as the posts above speak to.
Yes, I guess you could write a one-bit boolean (or one of Chip's -1 booleans) to a one-bit port. Never had the situation arise. Never had a chip with a one-bit port. While I still can't imagine it, I have to point out for jmg's benefit that I've never claimed omniscience. The world is full of crazy/amazing things.
Use em, don't use em. When you may encounter trouble, or need options later, it's all still there, no worries.
I should use more smiley faces. Some how I've engendered animosity where none was intended.
My initial question was ill-conceived...that's why I struck it out a while back.
Not at all! If it had been someone else that had started this thread, I would have put it down as trolling (since this is a well-worn discussion amongst programmers). But since I don't think that's what this is, it makes me think that there was some unsaid incident that prompted you.
My apologies if my original reply seemed terse or adversarial. That wasn't my intent.
I have no idea what "wasn't exactly ready for prime time" or "fill in the blanks" mean, but I do sense a gulf here...
A bit is a low level concept, the smallest amount of information you can have, a single memory cell or I/O path. Values usually referred to as 1 and 0.
A "boolean" is a high level concept. A type with two values TRUE or FALSE.
A boolean can be represented by a single bit, 0 and 1. Or many bits 0 and -1, or 0 and something that is not zero.
A programming language may or may not support boolean types. Or single bit values. A single bit value may or may not be usable directly as a boolean value (Not in Ada for example)
XMOS xcore chips have one bit wide I/O ports. As physical hardware features and syntactically in their programming language XC.
Thank you for your graciousness. You're exactly right - there was a precipitating incident. It stemmed from the fact that SPIN is just a tool to support my PASM habit. And PASM is just a tool to make the world do my bidding. So I never know more SPIN than is necessary. But I know a lot of C because embedded programming was my livelihood for many years.
Anyway, as Heater suggests, differences between languages can be a source of frustration. Sometimes the differences in terminology are the problem. Sometimes the presentation of the information is the problem. Sometimes the symbols clash. Sometimes my memory fails me. Sometimes I'm too impatient.
Not running in programming circles (I'm an engineer), I didn't have any idea that this topic had already been beaten to death.
FWIW, one of the things I love about C is K & R's decision to use the terms "logical operator" and "bitwise operator" and to pair the two families of operators wherever possible (&, && for example). In fact I'm so used to C that its operators are less of a convention and more of a law of nature.
Another example in PASM that can shorten the code in a loop.
ror Data, #1 wc ' rotate and set carry if lsb is 1 muxc outa, mask ' output the carry bit state to the pinPlease share with us how you managed that without so much as a cognew or a start.
That's pretty ingenious. I'm earmarking that one. Of course you're still selecting output pins with the use of a mask - and that is a bitwise operation. I'm sure jmg's example does that as well. But I'm not setting up his strawmen for him.
Why would I need a cognew ? as my general posts above said, this is not Spin (nor a Prop) - it is an 8051 target.
Here is the source line
and this is the assembler created :
MOV A,Heater ; 03C2 E5 76 ADD A,#0ABh ; 03C4 24 AB CPL C ; 03C6 B3 MOV P2.3,C ; 03C7 92 A3Most will easily see the "writing the result of a boolean operation to a hardware port" here.
The muxc example further above, shows the (very similar) Prop1 version of Copy-carry-to-bit :