«previous next»

SwiftX™ Features (continued)

Stepping Debugger

SwiftX's single-stepping debugger allows you to step through source compiled from a file. A simple example of its use is the sample program Sstest.f, reproduced below:

[DEBUG         \ Starts compiling steppable code
: 2X ( n -- n*2)   DUP + ;
: 3X ( n -- n*3)   DUP 2X + ;
: 4X ( n -- n*4)   DUP 2X SWAP 2X + ;
: 5X ( n -- n*5)   DUP 2X SWAP 3X + ;
DEBUG]         \ Stops compiling steppable code

Assuming this source code has been compiled from the file Sstest.f, you may type 4 DEBUG 5X to cause a debug window to appear ("4" is the argument for 5X).

While this debug window is active, you may control it using the buttons at the bottom, which work as follows:

• Step    Executes the next word, with no nesting.
• Nest    Executes the next word, nesting if it is a call.
• Go ;    Executes to the end of the current definition without stopping.
• Run    Stops debugging and continues running at (near) full speed.

The current stack is displayed at the bottom of the debug window.

Code Stripper

This SwiftX Pro feature strips unused code from your kernel and application, leaving a compact object. It does this by repeating a BUILD, keeping a record of all definitions not called, and then excluding them from the next INCLUDE. This takes several passes, since omitting a definition may remove the only uses of lower-level definitions, which may be omitted on the next pass.

When two successive passes produce an object whose size doesn't change, it's finished.

DEBUG can detect whether a BUILD (stripped or otherwise) has been done since SwiftX was loaded. If so, it uses its image (saving the time required to re-build it).

Since the code stripper will remove anything not called in the current loads, you should avoid stripping the kernel until late in your development cycle, because your application will likely use kernel words that might otherwise be stripped.

The assumption is that you will follow a development path like this:

1. Write new code, loaded by DEBUG.F after the SET-DOWNLOAD and before DOWNLOAD-ALL, and test it on top of a full (unstripped) BUILD.
2. As code becomes satisfactorily tested, move its INCLUDEs into the file App.f (see below) where it's loaded with the kernel (usually only once per session).
3. When your application is fully developed and tested, and all moved into App.f, strip that package and use DEBUG> (which now loads nothing) to test the stripped package.
4. When that works satisfactorily, replace DEBUG-LOOP in the word GO in App.f with your application startup word (see below).

If you need to make a change in the kernel image being used by DEBUG, you must BUILD it and install it.

Provision for Application Loading

The source file App.f is provided in the target-specific directory for each SwiftX. It contains the definition GO, which is invoked at the appropriate point in the power-up sequence. This file is loaded near the end of Kernel.f, and is intended to load your application source. INCLUDE your application files before the definition GO, and replace the word DEBUG-LOOP (which runs the target XTL for debugging) with your word which performs application initialization and startup.

«previous next»