The Script Control Interface (SCI) protects the computer's software stack and operational integrity by only running scripts when necessary to conduct background processing, accept input, or produce output. The SCI is similar to a task manager or process manager.
The SCI is part of the BIOS.
The SCI constantly manages non-BIOS script states by starting, stopping, and resetting them as necessary to reduce lag and improve data integrity by only running software when it is needed.
All software on the Mark 1 is stopped by default. When the Mark 1 is first turned on, the bootloader starts a program through the SCI. The LSL script for that program is then reset and started so it can run. That script can then launch additional LSL scripts that act in different ways depending on how they are classified in the SCI architecture.
The SCI supports three types of executable LSL scripts: programs, services, and libraries.
Programs are handled using the program stack. When the bootloader launches the first program, that program may then launch another program. The new program is added to the program stack and the SCI stops the original program while it is in the background. This may be repeated to add more programs to the stack.
When a currently running program exits using BIOS_SCI_TERMINATE (either by itself or by some other software attempting to terminate the running program for whatever reason), the program "falls off" the stack and the SCI stops it. If the exited program does not have any background instances running, it is also reset to clear any memory. Then, the SCI restores and starts the program that launched the exited program.
Only one program can run at a time. To run additional scripts to support a program only while it is running, consider a library. To run a script in the background all the time, consider a service.
By default, programs can only run once on the SCI stack; a new instance cannot be started until the original instance "falls off" the stack.
Programs that need to run as children of themselves - for example, the SCOPE console - are multi-context aware. These programs can run in multiple instances and must monitor the contextual cache value sent with BIOS_SCI_STARTED to determine which instance is running at any point.
For more information, see BIOS_SCI_MULTI.
Services are handled using the service stack. Unlike programs, multiple services can run at once. Services always run in the background. The SCI does not stop them automatically. The only way to stop a service and remove it from the service stack is to terminate it using BIOS_SCI_TERMINATE.
Services are generally used to provide support (stateless or stateful) to one or more programs without having to be manually loaded like a library. For example, the SCOPE drivers, along with most other device drivers, run as services.
Libraries are handled on both the program and service stacks, depending on how they are executed.
Libraries are stateless - i.e., they should not make use of any global variables and should not store any information. Libraries should act as general-purpose support scripts that may be used to split out code that may be used by multiple programs or to offload temporary processing to another script without the overhead of a service.
Although libraries should generally be stateless as a best practice, the SCI can support a stateful library - but such libraries should not be called by more than one program or service, since they might otherwise get confused by being called by multiple other scripts. Unlike contextual cache data for programs, the SCI does not give libraries any way to determine which instance is running, since a library might be running for multiple different services and programs at the same time. Therefore, while this documentation assumes libraries are stateless, you may want to consider a stateful library instead of a service to reduce lag in certain circumstances if you are sure your library will not be called by more than one program instance or service.
When a library is started using BIOS_SCI_EXECUTE, it is automatically associated with the running program and loaded into the currently running program's instance on the program stack. It does not act like a separate program or an instance itself on the program stack.
A library may also be started by a service. In that case, the service must pass its script name with BIOS_SCI_EXECUTE. The SCI will associate the library with the service's instance on the service stack, which will act the same way except that the library will always be running as long as the service is running regardless of what program is currently running and regardless of whether the currently running program (or a background program) has also called the same library.
When the program or service that a library is associated with is stopped, the library is also stopped. If the program or service "falls off" the stack, the library also falls off.
Libraries can be associated with multiple programs and/or services. Whenever a program or service associated with a specific library is running, the SCI will also start the library. Therefore, a library may not actually stop when the SCI receives BIOS_SCI_TERMINATE to terminate it or one of its associated programs or services, since the library might be loaded onto another service or the running program.
| System Call | Description |
|---|---|
| BIOS_SCI_CACHE | Stores contextual cache data that will be recalled if the program is suspended and restored. |
| BIOS_SCI_DELETE | Deletes an LSL script. |
| BIOS_SCI_EXECUTE | Starts an LSL script. |
| BIOS_SCI_INTERRUPT_ALLOW | Allows a requested interrupt to run. |
| BIOS_SCI_INTERRUPT_REQUEST | Requests to interrupt the current program and run a new one. |
| BIOS_SCI_MULTI | Marks a program as multi-context aware and capable of running multiple instances. |
| BIOS_SCI_PANIC | Stops all running LSL scripts. |
| BIOS_SCI_TERMINATE | Stops an LSL script. |
| System Call | Description |
|---|---|
| BIOS_SCI_DELETED | Status response to BIOS_SCI_DELETE. |
| BIOS_SCI_EXECUTED | Status response to BIOS_SCI_EXECUTE. |
| BIOS_SCI_INTERRUPT_TIMEOUT | Status response to BIOS_SCI_INTERRUPT_REQUEST. |
| BIOS_SCI_INTERRUPTED | Signals to an LSL script that an interrupt has been requested. |
| BIOS_SCI_STARTED | Signals to an LSL script that it has been started or restored. |
| BIOS_SCI_TERMINATED | Status response to BIOS_SCI_TERMINATE. |