Oxygen Basic
Programming => Problems & Solutions => Topic started by: chrisc on March 21, 2018, 12:40:05 PM
-
i was trying to compile a simple program but encounter a compilation error
ASM error
unidentified operation (xor) for this type (extended)
at line 22
the problem code is
$ filename "Testc.exe"
use rtl64
use corewin
'=======================================================
FUNCTION BigXOR(BYVAL value1 AS STRING, BYVAL value2 AS STRING) AS STRING
LOCAL valueans AS STRING
LOCAL loopit , tempnum AS LONG
Local insXor as LONG
tempnum = LEN(value1) - LEN(value2)
IF tempnum < 0 THEN
valueans = LEFT(value2, ABS(tempnum))
value2 = MID(value2, ABS(tempnum) + 1)
ELSEIF tempnum > 0 THEN
valueans = LEFT(value1, ABS(tempnum))
value1 = MID(value1, tempnum + 1)
END IF
FOR loopit = 1 TO LEN(value1)
insXor = VAL("&H" + MID(value1, loopit, 1)) XOR VAL("&H" + MID(value2, loopit, 1))
valueans = valueans + HEX(insXor)
NEXT loopit
FUNCTION = RIGHT(valueans, 8)
END FUNCTION
this is the error line
insXor = VAL("&H" + MID(value1, loopit, 1)) XOR VAL("&H" + MID(value2, loopit, 1))
how to rectify this error?
-
The problem is that val processes numbers on the FPU as potential floating point values.
It always pays to break complex expressions down into simpler components for readability. The compiler has to do it anyway.
' insXor = VAL("&H" + MID(value1, loopit, 1)) XOR VAL("&H" + MID(value2, loopit, 1))
int i1,i2
i1="&H" + MID(value1, loopit, 1)
i2="&H" + MID(value2, loopit, 1)
insXor=i1 xor i2
-
That was a good catch, Thanxx Charles
-
int i1,i2
i1="&H" + MID(value1, loopit, 1)
i2="&H" + MID(value2, loopit, 1)
@Charles
in your solution above, O2 seems to be able to defy some assignment rules
bcos in i1="&H" + MID(value1, loopit, 1)
the left hand side is an integer while the right hand side result in
a string?
Is this mix and match ok for O2 only for this situation whenever there is a prefix of "&H" and this
is then regarded as an integer ?
-
You can do this with any numeric variable and any string expression, and vice-versa.
This autoconverting feature is mostly used in print expressions with numbers and strings combined.
-
this is very flexible and adaptive, bravo Charles :)
-
You can do this with any numeric variable and any string expression, and vice-versa.
Can O2 provide this functionality?
a = 1
b = "2"
PRINT a + b, "\n"
PRINT a & b, "\n"
jrs@jrs-laptop:~/sb/examples/test$ scriba strnum.sb
3
12
jrs@jrs-laptop:~/sb/examples/test$
-
Bravo Charles, i luv it
int a ,b
a = 1
b = "2"
' this results in 3
PRINT a + b
' this results in 0
PRINT a & b
-
Oxygen's C-ish & is either bitwise AND or address (a.k.a. reference) operator partly synonymous to HLL @. Pretty much guess work for the parser to determine the true meaning of actual use cases as-is. Overloading it with yet another option and especially decode possible 1 & "2" bad programming practices would be just a bit too much, don't you think?
Oxygen is smart enough to correct kiddie 1 + "2" exercises but generally it is advisable to try and not lose one's face in the eyes of someone who might happen to be looking through one's codez later on.
Prefer to supply the compiler with all possible hints at your disposal as to what you would like it to do for you, rather than try and dump the load of human intellection on the shoulders of a machine.
For it is written: "It always pays to break complex expressions down into simpler components for readability. The compiler has to do it anyway." (Gospel of Charles, Reply #1)
-
I would love to see O2 be able to support variant style variables.
The SB example was a cheap shot. :-[
-
( ;) )
That'd make just one more possible front end for the O2 engine. :D
-
The autoconversion features are there to aid casual programming, not forgetting what the B in Basic stands for.
It should be as easy to use as a calculator. Remember the early days of home computers. Plug in the telly, switch on and start programming in Basic
-
The autoconversion features are there to aid casual programming, not forgetting what the B in Basic stands for.
It should be as easy to use as a calculator. Remember the early days of home computers. Plug in the telly, switch on and start programming in Basic
The BASIC language goal is to minimize the number of steps to accomplish any task.
-
The autoconversion features are there to aid casual programming, not forgetting what the B in Basic stands for.
That's justifiable in a PRINT statement only, which is where the B phase usually ends.
Otherwise, int i1="&H" + MID(value1, loopit, 1) may only appear in:
either- developer's own stress tests to verify the compiler is bullet proof against BSOD's running goofy code
or
Don't forget what A(ll-purpose) stands for in BASIC, either. My all-purposefulness implies being able to write industrial quality applications.
What you're seeing below is a pro-grade 3D model viewer displaying a model (courtesy of Patrice Terrier) that totals 2 million fully textured polygons, at a speed of 30 frames per second.
The viewer is written entirely in FBSL under a totally header-less and unprototyped environment.
Otherwise, the entire B-eginner level functionality a newcomer may ever need (PRINT, GDI graphics primitives, etc.) amounts to a 2K lines long #include file the FBSL Eclecta editor would plug in transparently whenever it sees #Option Implicit (a.k.a. don't require variable declaration) at the top of user code.
Do you think Dartmouth or BBC BASIC could ever do the same? We're living in the 21st century, Charles. :)
-
If a complex task only requires two parameters to run, should the BASIC programmer care beyond the intended results and the arguments presented?
-
I like the soft shadows :)
Yes, by all means, I would encourage industrial grade stainless-steel programming. Paradoxically, it usually involves breaking complex expressions down into simple ones. Then it is easier to identify repeating patterns in the code, and then compact them into functions or macros. It improves the readability of code, and ease of verification.
To enforce variable declaration, we have #autodim off
-
If a complex task only requires two parameters to run, should the BASIC programmer care beyond the intended results and the arguments presented?
I'd say- a complex task that only requires two parameters to run is a chimera; and
- the BASIC coder wouldn't, but the BASIC programmer, must.
I like the soft shadows :)
Veritable penumbra emulation is absolutely impossible outside GLSL, and still rather heavy on the GPU when implemented in a shader.
Yes, by all means, I would encourage industrial grade stainless-steel programming. Paradoxically, it usually involves breaking complex expressions down into simple ones. Then it is easier to identify repeating patterns in the code, and then compact them into functions or macros. It improves the readability of code, and ease of verification.
+1 in a static/JIT compiler, but it is a real speed killer in an interpreter where every run time temp var allocation, cast, or condition in the user code is a bottleneck.
To enforce variable declaration, we have #autodim off
+1 again. :)