SCASM 2.88

expressions and functions


Back to: main index


When I started the SCASM project it never came to my mind that it could become necessary to do calculations and so there is no delimiter character to separate parameters. For this reason SCASM needs some help. This is why you have to use squared brackets "[ ]" in every arithmetic expression.

Expressions are always evaluated from the left to the right regardless of the common mathematical rules. The only way to change this is to use nested brackets. Expressions can also contain macro parameter numbers like this:

[[90 - %3] / 45 ]
In expressions the following operators are allowed:
==  equal (comparison)
!=  not equal
less than
<=  less or equal
greater than
>=  greater or equal
OR (bitwise)
exclusive OR
AND (bitwise)
<<  shift left
>>  shift right
It is also possible to "cast" the number format.
Some examples:   
0xAB23  hex format, with "0x" prefix
0b101010101  binary format, with "0b" prefix
0d12345  decimal format, with "0d" prefix
0b1010101  binary format

To avoid problems with the current number format recognision routine please use only upper case charaters for hex numbers and use only lower case characters in the "number cast" sequences:
"0x..." & "0b..." & "0d...".

The expression evaluator is called for every numeric parameter input. If the evaluator is called without the "[" at the beginning of the expression, it stops at the first space charater. Therefore I strongly recommend to use the brackets and separate the elements of the expression by spaces. This will also increase the readability of the source code.

Since SCASM is a one_pass assembler :Label's in arithmetic expressions cannot be used, if these :Label's are defined in a later source text line. This is because the :Label is still undefined when the expression is evaluated.
All calculations are done at compile time, NOT at runtime.

Functions (vers. 2.02 and later)

To improve the parameter calculations there are now some functions available. Please remember, all calculations are done at compile time. Function names are case sensitive.
int[ <expression> ]
This function converts the result of <expression> into an integer number by truncating the fractional part.
round[ <expression> ]
This function converts <expression> into an integer number by doing a normal round up/down.
sqrt[ <expression> ]
This calculates the square root of <expression>. The result is still a floating point value. If needed you can use:
  round[ sqrt[ 100 / 2 ] ]
abs[ <expression> ]
This function makes sure that the result of <expression> is always a positive number.
sin[ <expression> ]
cos[ <expression> ]
tan[ <expression> ]
asin[ <expression> ]
acos[ <expression> ]
atan[ <expression> ]
atan2[ <expression> ]
This is the atan2( y / x ) function. Format corrected in SCASM 2.07
adrpat[ :Label ]
This address patch funktion is a workaround for the address calculation problem in Dwx() commands in the case the label is defined in a later line of the source code. This function simply adds the current address to the internal patch table and returns a 0 value which will be patched later. (v.2.04)
ipt[ index flag ]
version 2.07

index  the wanted point's index number
flag  selects the coordinate element (x, y, or z) of that point.

This function imports point coordinates from an existing SCASM internal point list. For example, you have defined an point list somewhere in an Area(). SCASM holds an internal copy of this list for the polygon vector automatic function. This function gives you access to this list, so you can copy coordinates to instructions which do not accept point numbers.
If you want to draw a dotted line with 7 dots from, lets say, point number 5 to 6 of your list, you can write:
DotLine( ipt[5 x] ipt[5 z] ipt[5 y]
         ipt[6 x] ipt[6 z] ipt[6 y]   7 )
geopt[ Lat Lon Alt ]
version 2.52
This funktion is a very tricky one. It expects point coordinates in a geographic Lat/Lon/Alt format and converts them into the usual x-z-y format using the last referencepoint data. The result is written back into SCASM's input buffer.
Using this dirty trick you can use the Lat/Lon/Alt format with nearly every command which expects x-z-y data. The altitude is expected in meters.
This function fails if there is not enough space for the replacement text at the beginning of the current input line. If this happens simply insert some space characters.
DotLine( geopt[ 60:00:59 w2:0:59 0 ]
         geopt[ 60:00:60 w2:0:59 0 ]  30 )
TOP © Manfred Moldenhauer