PBASIC Syntax: How Come Department
Phil Pilgrim (PhiPi)
Posts: 23,514
I know the following is not allowed:
But why not? The expression on the righthand side makes as much sense here as it does in an IF or ELSEIF. Plus, it's just downright useful sometimes, being much less awkward than:
'Just wondering...
-Phil
Comparator VAR Bit Value VAR Byte Comparator = Value > 128
But why not? The expression on the righthand side makes as much sense here as it does in an IF or ELSEIF. Plus, it's just downright useful sometimes, being much less awkward than:
Comparator VAR Bit Value VAR Byte IF (Value > 128) THEN Comparator = 1 ELSE Comparator = 0 ENDIF
'Just wondering...
-Phil
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- Stephen
-Phil
comparator = value/(128+1)· MAX 1
Jeff T.
Just
comparator = value/129
value is a byte so the MAX 1 is not necessary.
Or,
threshold = 128
comparator = value MIN threshold - threshold MAX 1 ' zero for values up to 128
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
Jeff T
Comparator = Value > 128
is more of a C syntax
the
IF (Value > 128) THEN
Comparator = 1
ELSE
Comparator = 0
ENDIF
is more of a BASIC syntax
I know there's a few companies out there try to combine the two in the last 5 - 10 years, but they have been different for 30+ years for many reasons. I've done quite a bit in both these and assembler and straight machine, after you go back a forth a couple of times it becomes second nature just like learning any language the more you use it the better you get. Some people do take a little more time to get better at different languages.
no biggie.
-Phil
Dim comparator As Boolean
Dim value As Byte
' value = 89 ' returns False
value = 130 ' returns True
comparator = value > 128
MsgBox comparator
comparator=x - 128 >>15
substitute 128 with a variable:
comparator=x - y >>15
Since the stamp appears to do all internal math at 16 bits this should work with any size variable.
What the stamp really needs is a CARRY BIT!! The carry bit would simplify math ops greatly and all processors provide it.·It could be·a global variable. We could use it for multi-word math and turning bit shifts into bit-rolls.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Have Fun
TR
Post Edited (TechnoRobbo) : 9/2/2007 2:32:00 PM GMT
TR's is nice, and using the sign bit will work so long as x and y are considered as twos complement, and the comparison is valid on the number line even if both numbers are negative, e.g., -20 < -15. As written it would give a 1=true output for x<128 or x<y. And
comparator=x - 128 >>15
substitute 128 with a variable:
comparator=x - y >>15
I agree, it would be great to have a carry bit available in an auxiliary variable. But that is not going to happen, nor the other direct comparison syntax, I bet $2!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
1. Comparisons in assignments.
2. Enhanced control over variable aliasing (including arrays).
3. Generalization of bracketed [noparse][[/noparse]I/O lists] to work with auxilliary RAM and other I/O issues.
One aside regarding comparison operators is their combined use with AND, OR, and XOR. These three Booleans are the only operators that break the strict left-to-right execution order of PBASIC expressions. What's interesting is that, like &, |, and ^, they operate bitwise and differ only in their precedence. Although it would be useful if they always returned 0/-1 or 0/1, this is likely a limitation of the pcode interpreter. Moreover, to change it would break some current PBASIC programs.
As to signed comparisons, an interesting syntax could employ operators like these: $> $>= $< $<=. But I'm not sure they can translated to meaningful pcode. (I once wrote a BASIC interpreter for the Z8 where signed comparisons were the norm, and unsigned comparisons were indicated by prepending a plus sign (e.g. +>) to the normal operators.)
In the same vein, a trinary operator like Forth's */ would be handy for ratiometric scaling. This operator performs division on a 32-bit internal product:
a */ b c = (a16 * b16)32 / c16
before the high-order 16 bits disappear. Although PBASIC's own */ and ** operators reveal the existence of an internal 32-bit product, these operators may have their own pcode tokens and not be decomposable to accommodate other uses.
-Phil
Post Edited (Phil Pilgrim (PhiPi)) : 9/2/2007 4:09:10 PM GMT
just remembering the code I have written over the years.
I haven't used the comparison type assignment syntax in basic (not often enough to remember any way), I do remember using it in C, with almost every assignment and I don't use the if then else block in C: