Target memory may be mapped for program memory (which may be ROM), initialized RAM, and uninitialized RAM. You can define multiple sections of each type, specifying the optimal location and size for your target hardware. You may, for example, place frequently accessed variables in on-chip RAM for maximum speed, while leaving larger arrays in external, or even paged, RAM.

It is very easy to develop custom I/O drivers in SwiftX. XTL communication with the target lets you examine and even modify I/O registers directly, to test the device's functionality. Typically, drivers are quite small, and are made up of several related simple definitions (e.g., one to read and one to write), which can also be tested interactively. Several examples (e.g., serial I/O, clock) are provided with your SwiftX system. To see how easily you can control digital devices such as motors and switches, look at the Washing Machine example.

SwiftOS makes interrupt handling simple. The strategy is:

• Perform only the most time-critical actions at interrupt time.
• Notify the task responsible for the interrupting device that the interrupt has occurred.
• Defer complex logic to high-level routines executed by that task.

Notification may take the form of setting a flag, incrementing or decrementing a counter, or modifying the task's status so it will become active at the next opportunity in the multitasker cycle.

The basic, high level code form of an interrupt handler is:

LABEL <name> <code instructions>
<name> <dev#> INTERRUPT

where LABEL starts the definition of the routine, which is called name; the code instructions perform the necessary work of the routine; dev# is the device code or interrupt vector to which the routine will respond, and INTERRUPT is a special code-ending macro that assembles the appropriate return-from-interrupt instruction and attaches the address of name to the interrupt vector. When an interrupt occurs, it will be vectored directly to the code at name with no overhead imposed by SwiftOS.

SwiftX includes the complete, high level source code for your target kernel, so you can modify it in any way that suits your needs: add, delete, or change anything. You also have complete control over your ability to map memory. With SwiftX Pro, you can even modify the assembler (e.g., to add instructions that only appear in certain chip variants). By omitting unused functions, you can reduce the size of your program to fit in even very small target hardware. This can be done manually in SwiftX, or automatically using the "stripper" feature in SwiftX Pro.

During development, it is convenient to be able to test your embedded programs in RAM. SwiftX's flexible memory configuration makes it easy to, for example, map more RAM during development than you may have in the final product, or to substitute RAM chips for PROMs during development. On many targets, it is possible to run your kernel code in flash or EEPROM, and to test your embedded applications' code in RAM; as code is validated, it may be added to the code loaded with the kernel.

If you have limited program RAM, a good strategy might be to start with a simple SwiftX kernel in PROM. You can interactively test some application code in RAM and, as more of it becomes stable, add it to the kernel in PROM.

SwiftX writes its object files in whatever format is most appropriate for burning flash or PROMs on a particular platform, either HEX records, S-records, or binary files. Wherever possible, SwiftX includes its own download utility to simplify development procedures, however these standard format files may also be used by any PROM-burning utility.