This manual page only applies to interp builds for POSIX-compatible systems, including embedded Linux. The environment-specific features are limited to the command line interface, and include capabilities that make it easier to use an interpretive language as one part of a larger entity such as scripts and programs. These features make it possible to load function definitions from multiple files, pass one-line command strings, and run in a batch mode (non-interactive.)
This API allows you to add, delete, and list macro definitions, and initiate macro expansion on an input buffer.
This API is the I/O portability layer between interp and the hardware, or host operating system (if there is one.)
This API allows you to instantiate a complete interpreter, including the outer interpreter with pre-defined macros, directives (handles commands beginning with "#" in column one), in-line comments (starting with "__"), and the macro processor, and initiate an interactive (or file-based) session.
This API implements wrappers for the memory management routines used by interp. These functions and macros localize any future changes to memory management. This is a very important strategy because c libraries for embedded targets often have reduced functionality and may or may not have the level of memory management required by interp.
This API allows you to instantiate a byte-code interpreter, reset its state after an error, and execute zero-terminated sequences of tokens.
This API provides functions that are the glue between interp and the I/O portability layer. They provide interp with a stack-oriented I/O capability suitable for printing numbers in various formats and number bases, and processing strings containing output formatting directives and argument type information.
This API provides the port I/O portability layer between interp and the hardware, or host operating system (if there is one.) Port I/O is communication between software and a device with a buffer that appears as one memory location (of a fixed size, such as a byte or a 32-bit word.) Writing data to this device is done by transfering each unit of data to the port memory location. Reading data from this device is done by transferring data from the port memory location into the next receiving buffer location.
These functions are the abstraction layer between interp and the IIF records. Typically IIF records are collected together into a file. Think of an IIF file as a portable binary container for your interp programs. They can be programmed to flash memory for execution in an embedded environment. They are perfect any time you wish to distribute an interp-based solution to a non-technical audience. By convention, the suffix for IIF files is "iif". Each record has three parts: 1) The 1-byte, unsigned Record Type, followed by 2) the 4-byte unsigned Length Field (the number of bytes that follow the Length Field), and 3) the remainder of the record (if the Length Field value is greater-than zero), whose contents vary according to the Record Type.
The functions and macros of this API implement a simple stack interface consisting of a list head (containing three pointers) and a one-dimensional array. A stack push increments the stack pointer and stores the item. A stack pop reads the item then decrements the stack pointer.