SDPL – Nested (Child) Programs

Contents

Overview

SDPL provides facilities to execute code, store values, and retrieve data within other SDPL programs.

This is not the same as running another program simultaneously, and communicating between them with rx/tx sockets and global shared memory.

The usual case would be to set some input variables for a specific subroutine from a program, run that subroutine, and gather its results.

Child Programs

Programs that are referenced with the @ symbol are automatically compiled in as a ‘Child’ program, which exists in a non-running state until it is called.  There is no need to declare the import of the program.

Unlike similar languages that use a library call or include the file’s contents, in SDPL the ‘Child’ program is completely compiled and placed in a sandbox like container where its variables, stack, and memory are completely isolated from the parent program.  It can be thought of as a sandboxed program.  Your ‘Parent’ program, however, can read/write arbitrary memory in the child before or after the child program is run.

Once called by the main program using a GOTO or CALL operation, the ‘Child’ program runs until it returns/exits, at which point the main program resumes.

Once a program is referenced, it becomes a dependency, and if it becomes invalid, so does our main program.  Circular dependencies are illegal (if a child has a parent which is also its child)

Use

Pointers or variables within other programs are designated with the @ symbol, and a format of either @PROGRAM:VALUE or, or programs located outside the current package directory, @PACKAGE:PROGRAM:VALUE

The syntax is slightly awkward as there are quite a few symbols.

# set variable X in another program:
SET %@OTHER_PROGRAM:X

# print the value of X from that other program:
PRINT /HEX $@OTHER_PROGRAM:X

# call subroutine SUB from that program:
CALL *@OTHER_PROGRAM:SUB

Care is required if the child program is written in a way to expect certain data to be initialized, as that may not be done by the subroutine itself.  Moving initialization to its own subroutine, which can be called from the main program, may be the best approach to solving this.

Tricks

If for some reason you need to know that you are running inside a parental sandbox, you can use the CHILD function, which sets the true/false bit in the status register based on whether we have been compiled as the child of another program.

CHILD
IF TRUE PRINT "WE ARE IN A SANDBOX"
IF FALSE PRINT "WE ARE THE ROOT PROGRAM"