SADE™ Debugging

By Joe Pillera, Ann Arbor, MI

Debugging In MPW With SADE™

Joe Pillera is a Scientific Staff Member at Bell Northern Research (BNR) in Ann Arbor, Michigan. Prior to this he was a Systems Analyst at the Ford Motor Company. He earned his B.S. in Computer Science from Eastern Michigan University, and is now a Master’s of Computer Science degree candidate at Wayne State University. His primary area of research is object oriented programming and software engineering.

Introduction

A good debugger is a programmer’s best friend. One of the serious drawbacks to MPW (Macintosh Programmer’s Workshop) software development has always been a lack of a source level debugger (no, I don’t consider MacsBug hexadecimal dumps debugging!). Until now. Introducing SADE™ - the Symbolic Application Debugging Environment. This is Apple’s new source level debugger for MPW 3.0 and beyond.

In this article I plan to cover the following:

• An overview of SADE.

• SADE in action - debugging a sample C program.

• A numerical integrator - pushing the SADE script language to the limit.

• Talking straight - the good, the bad and the ugly.

Note that even though this is not a ‘comparison’ article, I will occasionally mention THINK’s Lightspeed™ debuggers (because of their excellent performance), as a frame of reference in discussing SADE.

Figure 1. The SADE Menu System

What Is SADE, Anyway?

SADE is not an MPW tool, nor is it physically part of the MPW shell. It is simply a stand-alone application that communicates with your target program under Multifinder. As in THINK’s Lightspeed C, this debugger must be operated under Multifinder, to allow interprocess communication. Two or more megs of memory are strongly recommended; however, the manual does indicate you can squeeze by with one meg. The only special requirements to run SADE are:

1. You must be using Multifinder 6.1b7 or later.

2. The (Pascal or C) compiler must be instructed to generate ‘symbol’ files during program compiles.

One of the more interesting design decisions Apple made was to make SADE appear almost identical to the MPW Shell. This has both an advantage and a disadvantage: the advantage is that of instant familiarity to existing MPW programmers; the disadvantage is that this precludes the use of a user-friendly, animated interface (such as the debuggers used in THINK’s Lightspeed C and Lightspeed Pascal).

Please refer to Figure 1 for a closer look at SADE’s functionality.

Wade Through Your Code With SADE

The most fundamental operation in using a debugger is setting a breakpoint in the source code. Because SADE is so sophisticated, there are four ways to do this:

1. Enter the break command from the SADE command interpreter. The syntax (for debugging a C program) is:

 break <function name>.(<line number>)

2. Call the function SysError from within the C code itself. The syntax of this approach is:

 #include <Errors.h>
 . . .
 SysError(<integer from 129..32511>).

3. Press the SADEKey (Command-Option-<period>).

4. Open a source code file (as read-only from SADE), and use the mouse to select a line of code. Then execute ‘Break’ from the SourceCmds menu.

Method number 1 is fine if your functions are small, otherwise counting the individual lines of code could prove cumbersome.

Why does method number 2 work? When using version 6.1b7 and above of Multifinder, MC68000 exceptions are passed to SADE, if present; if SADE isn’t a concurrently executing task, then a system exception occurs.

Personally, I think method number 3 is somewhat satirical; trying to guess which machine instruction you are now (ahem, were) executing can cause brain damage.

Method number 4, of course, appears to be the most user-friendly of them all.

So in practice, it would seem that all methods except number three can be easily used to set break points in your own code. Refer to Figure 2 for an example of starting up SADE and setting breakpoints. For an illustration of SADE stopping at a breakpoint, please refer to Figure 3. The MPW C source listings will also provide more information on how to set breakpoints within your own code.

One interesting thing I noticed is that a SysError() breakpoint will stop after that line of code is executed, whereas setting a normal breakpoint will stop before that line of code.

SADE has complete facilities for keeping track of variable values. You can either perform a Show Value, which shows the contents of the variable of your choice, or you can use the Watch feature. This feature is analogous to THINK’s Lightspeed Pascal’s ‘Observe’ window: every time a variable’s value changes, it is updated in a display window for you. Please refer to Figure 4 for an example from the ‘Test’ program.

And of course, you have complete code stepping facilities: single step lines of code, and even control whether or not you step into procedure calls.

Program Your Bugs Away

All of the aforementioned features can be found in most other debuggers. However, the feature that sets SADE apart from any other debugger I’ve used is its internal programming facility (henceforth, I’ll refer to SADE programs as ‘scripts’, to differentiate these from your C & Pascal programs). You can actually write SADE procedures and functions to automate debugging tasks. And if that’s not enough, how about a slew of predefined procedures (even printf ) and reserved system variables? Furthermore, complete expression evaluation is possible, including pointer manipulation, bit-wise operations, and string manipulation.

The script facility of SADE is so extensive, it strongly resembles Pascal. Not only that, SADE procedures and functions are fully capable of recursion. Unlike Pascal, however, all variables are dynamically typed - based on their use in the program; this would appear to be the result of an interpretative implementation of this language.

To execute a SADE script, enter the script name (followed by any arguments) and press ‘enter’ from the numeric keypad. Thus, script invocation is identical to executing MPW tools. Before a SADE subroutine can be run, the file that contains it must first be loaded into memory; this is done as follows:

 execute ‘<Full HFS Path>:<File Name>’

As an example, I’ve developed a general purpose numerical integration script, which when given any arbitrary function f(x), will find the (approximate) integral bounded between two values ‘a’ and ‘b’. The foundation to my algorithm is the SADE eval function; this function takes a string representing an expression, and then proceeds to parse it in search of an answer. For example:

 define x = 5
 eval(‘x * 2’)

When executed at the SADE command line, this would return ‘10’ as the result.

The technique of integration I use is called Simpson’s Rule, which partitions an interval from ‘a’ to ‘b’ an even number of times (i.e. N=2M partitions). We then approximate the graph of f(x) by M segments of parabolas; the technique is shown below:

In my case, I partition each region between n and n+1 four times, giving delta x the value of 0.25; integration then simply becomes a matter of alternating the coefficients of the intermediate data values.

Unfortunately, it wasn’t that easy - because I wanted to be able to integrate any continuous function I could think of, not just the simple ones. As it turns out, simple mathematical functions (such as x**n) are not known to SADE, so I had to write my own.

How did I do this for polynomials? Using something called a Taylor Expansion, it is possible to calculate x**n (x to the nth power), where either ‘x’ or ‘n’ can be floating point values. Taylor Expansions are open-ended functions, so it is necessary to determine a stopping criteria that is both accurate and efficient. The Taylor Expansion for x**n is shown below:

For example: because both ‘x’ and ‘n’ can be floating point numbers, integrating the square root of ‘x’ is simply a matter of integrating x**(1/2) power.

Just one more problem - ln(x) is not known to SADE either, so here’s the approximation for it:

This approximation, of course, is only valid for x > 0. For an example of a simple polynomial integration, please refer to Figure 5.

However, before you throw away your favorite numerical analysis package, I should warn you that I found SADE to have problems maintaining floating point precision. Take a look at my exponent script: I noticed that using tricks such as intermediate variables for subexpressions made the difference between a correct answer and something way out in left field. SADE’s natural habitat seems to be integers, which would make a lot of sense seeing how it’s a debugging environment. Therefore, even though Simpson’s Rule will (theoretically) work on any continuous function, my SADE script will only work in cases when SADE handles floating point calculations correctly. We should remember, that SADE is a debugging environment, so I don't consider this to be a drawback.

If all these features still aren’t enough, SADE even provides high level calls to prompt the user with dialog boxes, add custom menus, and even generate music! In short, SADE has every power-tool a programmer could ever ask for in a debugger.

Straight Talk About SADE

SADE is by far the most sophisticated and user-extendable debugger I’ve ever used - but I do have one complaint: its user interface. This drawback is caused by SADE’s own complexity: at times it seems to offer you too many features. All of these features in turn dictate a user-interface that’s not as elegant as the Lightspeed debuggers. If SADE were made to be more user-friendly, even at the expense of some of its bells and whistles, Apple would have a world-class debugger in their hands.

The End...

MacsBug, MPW, Multifinder and SADE are trademarks of Apple Computer, Inc. Lightspeed is a registered trademark of Lightspeed, Inc.

The opinions expressed here are solely those of the author, and not of Bell Northern Research Inc., or its employees.

BIBLIOGRAPHY

Apple Computer, Inc. (1989) SADE: Symbolic Application Debugging Environment, Apple Programmer’s and Developer’s Association, Cupertino, California.

Beyer, William H., PhD. (1978) “Series Expansion,” p.387 in Standard Mathematical Tables - 25th Edition, CRC Press Inc., Boca Raton, Florida.

Shenk, Al, PhD. (1979) “Techniques of Integration,” pp. 424-425 in Calculus and Analytic Geometry - 2nd Edition, Scott, Foresman and Company, Glenview, Illinois.

Symantec, Inc. (1989) “Debugging Programs,” pp. 103-110 in THINK’s Lightspeed Pascal User’s Manual, The Symantec Corporation, Cupertino, California.

Symantec, Inc. (1989) “The Debugger,” pp. 129-145 in THINK’s Lightspeed C User’s Manual, The Symantec Corporation, Cupertino, California.

========== The Integrator Script ===========

# ----------------------------------------
# A simple but powerful use of the SADE™
# script langauge to perform numercial
# integration on almost any function.
# ----------------------------------------
# Copyright © Joe Pillera, 1989
# All Rights reserved
# ----------------------------------------

# ----------------------------------------
#            func integrate(a,b) 
# ----------------------------------------
# Integrate a global function ‘f(x)’ from 
# a to b.  
# ----------------------------------------
# INPUTS:
# a -> integer or floating point
# b -> integer or floating point
# ----------------------------------------
func integrate(lower,upper)
  define factor, result, index, x
  index := lower
  factor := 2
  result := 0
  while index <= upper
    x := index
    if (index = lower) or (index = upper) then
      result := result + eval(f)
   else
     result := result + (factor * eval(f))
   end
   index := index + 0.25
   if factor = 2 then
     factor := 4
   else
     factor := 2
    end
  end
  return (1.0/12.0) * result
end

# ----------------------------------------
# func ln(x)  -> Compute natural log of x
# ----------------------------------------
# INPUTS:
# x -> integer or floating point
# ----------------------------------------
func ln(x)
  define result, term, index, frac
  term   := (x - 1.0) / (x + 1.0)
  result := term + (0.3333 * power(term,3))
  index := 5
  while index <= 25 do
    frac := 1.0 / index
    result := result + 
              (frac * power(term,index))
    index := index + 2
  end
  return (2.0 * result)
end

# ----------------------------------------
# func exponent(a,x) -> Compute a ** x 
# ----------------------------------------
# INPUTS:
# a -> integer or floating point
# x -> integer or floating point
# ----------------------------------------
# NOTE: Use power(a,x) if ‘x’ is a integer,
#       because that routine is faster.
# ----------------------------------------
func exponent(a,x)
  define result,iteration,term
  define numerator,denominator
  term   := x * ln(a) 
  result := 1.0 + term
  for iteration := 2 to 15 do
    numerator   := power(term,iteration)
   denominator := fact(iteration)
    result := result + 
              (numerator / denominator)
  end
  return result
end 

# ----------------------------------------
# func power(x,n)  -> Compute x ** n
# ----------------------------------------
# INPUTS:
# x -> integer or floating point
# n -> integer
# ----------------------------------------
# NOTE: Use iteration for speed.
# ----------------------------------------
func power(x,n)
  define index, result
  if n = 0 then
    return 1
  elseif n = 1 then
    return x
  else
    result := x
    for index := 2 to n do
     result := result * x
  end
  return result
end

# ----------------------------------------
# func fact(n)  -> Compute n!
# ----------------------------------------
# INPUTS:
# n -> integer 
# ----------------------------------------
func fact(n)
  if n = 0 then
    return 1
  elseif n = 1 then
    return 1
  else
    return ( n * fact(n-1) )
  end
end

================== Main.C ==================

#include <Errors.h>

int  number;

main()
{    
  /* Set breakpoint #1 here (from SADE) */
  number = 1;
  
  /* Now pass control to func, and let */
  /* it alter the “number” variable.   */
  func();
 
  /* Hard code breakpoint #3 here */
  SysError(129); 
}

================== Func.C ==================

extern int number;

void func()
{
  /* Set breakpoint #2 here (from SADE) */
  number = 10;
}

================== Test.R ==================

#include “SysTypes.r”

resource ‘vers’ (1) {
    0x1,
    0x00,
    release,
    0x0,
    verUS,
    “”,
    “1.0 / MacTutor Magazine”
};

resource ‘vers’ (2) {
    0x1,
    0x00,
    release,
    0x0,
    verUS,
    “”,
    “For Use With MPW SADE™ Only!”
};

=============== Make File =================

Test ƒƒ Test.make test.r
 Rez test.r -append -o Test
func.c.o ƒ Test.make func.c
  C -sym on func.c
main.c.o ƒ Test.make main.c
  C -sym on main.c

SOURCES = test.r func.c main.c
OBJECTS = func.c.o main.c.o

Test ƒƒ Test.make {OBJECTS}
 Link -w -t APPL -c ‘????’ -sym on -mf 
 {OBJECTS} 
 “{CLibraries}”CRuntime.o 
 “{Libraries}”Interface.o 
 “{CLibraries}”StdCLib.o 
 “{CLibraries}”CSANELib.o 
 “{CLibraries}”Math.o 
 “{CLibraries}”CInterface.o 
 -o Test