Macros within IF commands

hippy

Technical Support
Staff member
Due to the way the pre-processor and syntax checking works within PICAXE Editor 6 there are some tricks which may not be immediately obvious but with a bit of lateral thinking can be put to good use.

For example, having macro style function calls in IF commands, for example -

Code:
If Matched( char, "abc" ) Then
  SerTxd( "Character ", char, " is one of 'a', 'b', or 'c'" )
End If
An example of this is below which can be run in the PE6 simulator or on a real PICAXE. It prints the letters "a" through "z" putting square brackets around those which are in the matching list, vowels in this case -

Code:
Symbol char  = b0
Symbol match = b1
{
#Define Matched(n,chars) b0=0 Then                _
                         End If                   _
                         match = $FF              _
                         LookDown n,(chars),match _
                         If match < $FF
}
Do
  For char = "a" To "z"
    If Matched(char,"aeiou") Then
      SerTxd( "[", char, "]" )
    Else
      SerTxd( char )
    End If
  Next
  SerTxd( CR, LF )
  Pause 1000
Loop
Note it's actually a #DEFINE rather than a #MACRO and each line except the last ends with a line continuation "_".

The first two lines complete an IF-ENDIF and is just wasted code ( and wasted memory ), then comes the processing, and at the end the start of an IF command except the THEN which is in the main program.

This does, as noted waste memory, but that can be acceptable when making the main body of program code more readable and aesthetically pleasing. In PE6 one can click on the [-] box next to the "{" and hide the complexity of what's going on under the hood.
 
Last edited:

hippy

Technical Support
Staff member
You can waste one less byte per invocation writing :
if b0=b0 Then
It would be interesting to know where you are seeing that, using which software and which PICAXE. I suspect it is an anomaly because the token for a numeric zero should be smaller than for a variable.
 

BESQUEUT

Senior Member
It would be interesting to know where you are seeing that, using which software and which PICAXE. I suspect it is an anomaly because the token for a numeric zero should be smaller than for a variable.
With 28X2 :
23043
23044
Same for all X2 parts...
Surprising, but...
 

hippy

Technical Support
Staff member
Thanks. I think it is an anomaly. If you add a STOP command at the end after the LOOP, with "b0=0" that's 65 bytes, with "b0=b0" it's 66 bytes.

I recall it comes down to the way the compiler counts bytes used that it can be an off by one depending on how the code aligns in memory.
 

hippy

Technical Support
Staff member
Token sizes vary, depending on what the token represents or what its value is.

Generally there needs to be X-bits to represent N different things, so if one had 8 commands one might have 3-bit command tokens -
Code:
000 LET
001 HIGH
010 LOW
011 IF
100 GOTO
101 GOSUB
110 RETURN
111 END
But one can instead encode tokens so more commonly used commands use two and less frequently used have five -
Code:
00     LET
01     HIGH
10     LOW
11 000 IF
11 001 GOTO
11 010 GOSUB
11 011 RETURN
11 100 END
Or there could be, more optimally in this case, two, four or five -
Code:
00      LET
01      HIGH
10      LOW
11 00   IF
11 01   GOTO
11 10   GOSUB
11 11 0 RETURN
11 11 1 END
There is no fixed 'how it will be' though the more fixed things are the less firmware is required to decode what something means.
 
Top