All Databases MacTech Vol 07-1991

Mar 91 Letters

Volume Number: 7

Issue Number: 3

Column Tag: Letters

THINK C and Benchmarks

By Kirk Chase, Editor

Objective-C® Oversight

Sarah C. Bell

The Stepstone Corporation

75 Glen Road

Sandy Hook, CT 06482

I object to Mr. C. Keith Ray’s article, “NeXT for Mac Programmers”,

(MacTutor, Dec. ’90). This article dealt with the Objective-C® programming

environment marketed by the Stepstone Corporation. At the end of his article, he listed

all the trademarks that were included in the article. He failed to mention that

Objective-C is a trademark of the Stepstone Corp.

Since the column was centered around our product, we would appreciate it if you

made mention of this fact in the next issue of MacTutor.

[Consider it done - ed]

Taming The THINK C Debugger

Rex Reinhart

Irvine, CA

Here’s a simple workaround to setting and keeping breakpoints in THINK C.

Define the following macro:

/* 1 */
#define HALT asm{_Debugger}

Then simply put HALT in your code wherever you want a breakpoint (anywhere

but in the middle of an expression). Then run the program under the THINK C debugger.

When execution of your code reaches the HALT, your program will stop, the debugger

will become active, and your source code will appear with the current line pointer at

the HALT. From there you may step at your leisure.

For low level debugging, try it with MACSBUG. Compile your program and run it

on its own.

Another useful variation is

/* 2 */
#define CONDHALT(Condition) if(Condition) asm {_Debugger};

The Mac has a current debugger pointer which a debugger may set to point to

itself. I don’t know if this pointer is in a global, or directly in the trap dispatch table.

_Debugger is a little known (not in IM I-V) trap A9FF which transfers execution to

wherever this pointer points to. The THINK C debugger sets this pointer correctly. I

haven’t tried this with other debuggers, but if the set this pointer it should work.

Good Luck.

Benchmark Challenge Revisited

John W. Baxter

Port Ludow, WA

This is a response to the letter “Benchmark Challenge” published in the

September 1990 issue.

A significant problem exists with the benchmark source code (both C and Pascal)

as printed in the September issue: the local variable b controls the flow of the

program, and the letter states that it ranges from 1 to 20. However, b is neither

initialized to anything, nor adjusted during the loop. Therefore, the value of b will be

whatever is left over in the stack frame locations or register the compiler uses for

storing b. That could, for example, mean that the value of b in the Pascal case happens

to be 1 (causing execution of only one comparison per loop) while the C case it might

be 100,572, causing many comparisons per loop. To fix this problem, I would suggest

initializing b to 1 at the beginning of each of the test functions (procedures), and in

each conditional just advance it to the next value. So the Pascal TestCase procedure

would look something like:

begin

b := 1;

case b of

1: begin

b:=2;

end;

Another pitfall to watch out for in designing benchmark code is code optimization

performed by the compiler. Looking at the code as presented in the magazine, we find

that in fact regardless of the of b, the code to be executed by the conditional structure is

the same (nothing). In both C and Pascal, the compiler has the “right” in such a case

to optimize the conditional structure totally out of existence in the final object code

(there are no called function or procedure side effects to worry about). As it happens,

fixing the undefined state of the variable b as above will prevent such optimization in

this benchmark. And, I doubt that either compiler used actually goes that far in its

optimization process.

Yet another potential problem is the fact that the Pascal version using a 2-byte

b, while the C version happens to be using a 4-byte b. In this case, the time difference

introduced by this difference should be vanishingly small (on the 68xxx family). The

same benchmarks moved to the Apple IIgs, and continuing to suffer the problem (they

wouldn’t as printed because the available C compilers on the IIgs use a 2-byte int),

would favor the Pascal significantly, since the 2-byte arithmetic is much faster than is

4-byte arithmetic on the 65816 (which is why int is 2 bytes in those C compilers).

To go a step further, C would allow the use of an unsigned 2-byte b, while Pascal does

not. For best C performance on the 65816 chip, everything which CAN be unsigned

SHOULD be. That leads to the question: “Does a fair benchmark comparing 2 languages

and their implementations use the same data type each, or use the most efficient

available data type?”

Unfortunately, the answer to that is “Yes.” It depends upon what one wishes to

compare. When ignored, this issue invalidates carelessly-written benchmark articles,

including the original Byte magazine Sieve benchmark, which made UCSD Pascal look

much worse than it needed to. For the Apple II version, about a 40% speed improvement

was produced in the Byte Sieve simply by (a) turning off range checking, and (b)

defining the variables with the big array last, so that the other variables could be

reached by more efficient p-code. A benchmark needs to make clear whether it is

comparing the best source found for a given language/implementation/ platform, or a

direct translation.