CALM CALL instruction

CALL was implemented on a request from one of the early adopters of CALM, purely for performance reasons. However, they way it is implemented, it also allows to do some small tricks that are not possible through a normal ASSEMBLE route.

When a macro is called through a standard assembly, the arguments are always symbolic values - pieces of text cut from the original assembled line. But when giving values to CALL variables, you can pass any kind of value, not necessarily symbolic. This allows for a further performance gain, when you pass a numeric/polynomial value directly, but may also cause some subtle effects in cases where the type of value matters:

Code:

calminstruction demo value*
        local a, b
        match a+b, value
        jyes two
        emit 1, value
        exit
      two:
        emit 1, a
        emit 1, b
        exit
end calminstruction

calminstruction test0 expr
        local cmd
        arrange cmd, =demo expr
        assemble cmd
end calminstruction

calminstruction test1 expr
        compute value, expr
        call demo, value
end calminstruction

test0 2+3
test1 2+3 ; fails, because MATCH cannot be applied to numeric value

The fact that CALL makes it possible for an argument to come with a non-symbolic value is the reason why in the experimental branch I added a __TEXT operator that allows CHECK command to determine whether a variable has a symbolic value.

And CALL command is also going to fail when the target instruction is not CALM itself.

In short: the use of CALL is optional, when you need your macros to work faster, and then it should be used carefully.

fabbel wrote:

. or even different from simply

Code:

calminstruction another_calm_inx
   calm_inx
end calminstruction

This is very much different, as this calls a macro defined as "calminstruction?.calm_inx", and it does it at the time of definition (when "another_calm_inx" is compiled). The CALL is done at run-time (just like ASSEMBLE).

This helped me remember another difference: with CALL the reference to target instruction is resolved at definition time. At the run-time ASSEMBLE may see and execute an instruction with the same name from a different namespace, depending on context, but compiled CALL command always refers to the same symbol, fixed at the time of definition/compilation.