LETTERS

Consider his example of CopyUppercase. A C programmer might write the body as that in Example 1. I would expect any compiler to construct the intermediate form in Figure 1. I would then expect an optimizing compiler to identify common subexpressions and perform dataflow analysis resulting in that in Figure 2. During memory allocation I would expect an optimizing compiler to recognize that the idioms in Figure 3 can be implemented using string instructions if the DS,SI and EI,DI registers are associated with the appropriate subexpressions. Without such recognition, string instructions will never be generated. Recognition of these idioms leads to the allocation for subexpressions to machine locations as in Example 2, which leads to the code shown in Example 3. Since these ideas are at least 10 - 15 years old, any optimizing compiler should incorporate them. Michael Abrash made a mistake in regarding the Microsoft and/or Borland compilers to be optimizing compilers. By the way, I am The OPG Co., a firm that performs research into compiler writing tools.

George H. Roberts

Broken Arrow, Oklahoma

Example 1

  do {
    x = *a++;
    x += (('a' <=x) && (x<='z'))?  ('A'-'a'): 0;
    *b++ = x;
  } while (x);

Example 2

  subexpression name  register name  register contents
  @a, offset          DS, SI         address for source byte
  @b, offset          EI, DI         address for destination byte
  x, x+0, x+32        AL             source/destination byte value

Example 3

       ...       optimized prologue
       les       si, [bp+a_pointer]
       les       di, [bp+b_pointer]
  Convert_and_Copy_Loop:
       lodsb
       cmp       al, 'a'
       jb        Save_Upper
       cmp       al, 'z'
       ja        Save_Upper
       add       al, 'A'-'a'
  Save_Upper:
       stosb
       and       al, al
       jnz       Convert_and_Copy_Loop
       ...       optimized epilogue

Michael responds: And so once again we come to the difference between "what is" and "what should be." Mr. Roberts' letter reminds me of the debate between the RISC and CISC people; the RISC people keep saying that RISC has the potential to be two,four, even ten times faster than CISC, and the CISC people keep sighed and pointing out that today's CISC software, running on today's CISC computers, is just about as fast per dollar cost -- and there's a heck of a lot more of it available. In the high-level versus assembly language arena, it's much the same. I remember a lively debate three or four years ago about the relatively low quality of code generated from C source, with the C proponents insisting that the critics were mistaking poor compiler implementations for a poorly optimizable language. "Just wait untit real optimizing C compilers arrive!" they protested.

Well, here we are, years later, and 95 percent of the world uses two compilers that Mr. Roberts claims aren't optimizing compilers at all. I note that Mr. Roberts doesn't actually name a compiler that generates the code he lists; even if there is such a compiler, I suggest that since almost no one is using that compiler, whatever it is, it's a moot point. Mr. Roberts may be entirely correct in that a good optimizing compiler will generate the code he lists; I suggest that today, given currently used PC tools, that's pretty much irrelevant. There's another point to be addressed here. After claiming that I "propagate the myth that code produced by compilers cannot match code produced by good assembler [sic] language programmers," Mr. Roberts follows with the non-sequitur that the compilers I used aren't worthy of being called optimizing compilers, as if the latter is evidence for the former. Even if Turbo C and Microsoft C aren't optimizing compilers, that doesn't mean that "worthy" compilers can generate code as good as assembly language programmers can. Consider Mr. Roberts's own example: His hypothetical "optimized" code is indeed much better than the code Microsoft C produced -- but it's a good 50 percent slower than the hand-optimized code in my article! Anyone who believes that a compiler can match top-notch assembly language for small, well-defined tasks is kidding themselves. (There just isn't enough information bandwidth from the programmer to the compiler in a high-level language for this not to be true.) Assembly language isn't appropriate for most tasks, but when you need maximum performance, it is the only choice.

Errata

Please note the following changes to the source code listing on page 86 in last month's "Building a Hypertext System" by Rick Gessner (DDJ, June 1990).

	44:
	45:
	
	112: If Line [j] <>Null then
	113:      Inc(i) else Inc(j,2);
	114:    Inc. (j);
	115:  end;
	116: Determine_Actual_Line_Pos:=J;
	117: end; (Determine actual line pos)
	
	140: IfOrd(Line[LinePos])>127 then
	141: Begin

On page 167 of the same issue, change the line of source code accompanying "LZW Revisited" by Shawn Regan from:

  if ( num_bits == MAX_BITS > max_code ) {

  if ( num_bits == MAX_BITS ) {

DDJ apologizes for the confusion.

LETTERS

Alive and Apparently Well in Louisville

A Plus for Patents

Here We Go Again

Example 1

Example 2

Example 3

Errata