Code size

Ken Strauss

Some of the new SX/B2.0 features such as STR generate inline code. A few uses of STR will considerably bloat ones code. Is there any way to avoid this behavior other than moving calls to a subroutine? Why doesn't the compiler do this for me?

Bean

Ken,
Yes you put them into a subroutine.
The SX/B compiler is a single pass in-line compiler. It simply translates commands line by line.
This makes the assembler output easy to understand. SX/B was designed to "teach" assembly by examining the SX/B output.

Bean.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
There is a fine line between arrogance and confidence. Make sure you don't cross it...

·

JonnyMac

Terry: Could we change STR and HEXSTR so that they expect the address of the array instead of the name -- this would let us wrap them into a generic subroutine

' Use: DEC_STR @array, value
' -- pass pointer to array and value

SUB DEC_STR
  STR __PARAM1, __WPARAM23 
  ENDSUB

I can presently get this to work because of what STR expects as the first parameter; or am I missing something?

Bean

Jon,
If the first parameter is NOT an array, then it is assumed to be the address of the array.
So you can still but it in a subroutine, but you have to store the parameters because the code for STR overwrites __PARAM1 and __PARAM2 with the "value".
I could change the code generated so that it doesn't do that...

Bean.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
There is a fine line between arrogance and confidence. Make sure you don't cross it...

·

JonnyMac

Doggonnit -- I actually looked inside the code for STR and should have seen that __PARAM1 was getting overwritten; this works:

' Use: DEC_STR @array, value
' -- pass pointer to array and value

SUB DEC_STR
  aPntr        VAR    __PARAM4

  aPntr = __PARAM1

  STR aPntr, __WPARAM23 
  ENDSUB

Thanks, Terry.