KON & BAL'S PUZZLE PAGE

A Branch Too Far

Chris YERGA

See if you can solve this programming puzzle, presented in the form of a dialog between Konstantin Othmer and guest puzzler Chris Yerga. The dialog gives clues to help you. Keep guessing until you're done; your score is the number to the left of the clue that gave you the correct answer. Even if you never run into the particular problems being solved here, you'll learn some valuable debugging techniques that will help you solve your own programming conundrums. And please, make KON & BAL's day by submitting a puzzle of your own to AppleLink DEVELOP.

Chris I have a piece of code that runs fine on my Quadra, but when I run it on a plain old 68000 it crashes.

KON A 68000? So you're still trying to get GX to run on that Mac Portable in Cary's office, huh? How does it crash?

Chris With an address error.

KON What's hard about that? Your code is doing a 2- or 4-byte access to an odd address, which is OK on a 68040 but not on a 68000. It's a trivial problem.

Chris That's what I thought, but the address it's accessing appears to be uninitialized data. The code is simply allocating a block and then storing a pointer in the block, but the store never seems to occur, because afterward the block has random data in it. And of course the block itself is long-aligned, because it came from the Memory Manager, so there's no problem there.

KON Maybe on your Quadra, but on a Mac Plus the Memory Manager allocates blocks that are word-aligned.

Chris Thanks for the history lesson, chief, but this isn't a Mac Plus and the Memory Manager on this machine is much different -- much simpler, actually. It just so happens that our Memory Manager always long-aligns blocks.

KON Since when are you writing new Memory Managers? I thought you wrote graphics code.

Chris Yes. But the cornerstone of any decent graphics system is its Memory Manager -- I wouldn't expect a "QuickDraw classic" guy like you to understand.

KON I understand memory management just fine, Jackson. Show me where you're setting up this data.

100 Chris This is the interesting section:

NewDMAQueueEntry
...
+0030 0020C5D6  MOVE.L  D3,D0
+0036 0020C5DC  _NewPtr
+0038 0020C5DE  MOVE.L  A0,-$0008(A6)
+003C 0020C5E2  MOVE.L  -$000C(A6),-(A7)
+0040 0020C5E6  MOVEA.W -$000E(A6),A1
+0044 0020C5EA  MOVE.L  A1,-(A7)
+0046 0020C5EC  JSR     *+$53A4 ; 00211990
+004A 0020C5F0  MOVE.L  D0,-$000C(A6)
+004E 0020C5F4  MOVE.L  A2,(A0,D0.L)

It makes the _NewPtr call, makes some other function call, and then stores the pointer in A2 into our newly allocated buffer.

KON What's the other function call doing?

95 Chris I'm not sure, actually. The C source doesn't indicate that a function call should be happening:

buffer = NewPtr(totalSize);
count = count * size;
*(long *) (buffer + count) = (long) handlerProc;

The only thing I see happening in the source code is a multiply. You don't need a function call for that.

KON Could this be some wacky C++ operator overloading nonsense? C++ is very good at generating extra function calls. I think we'd better bring a SmartFriend in on this one.

Chris Don't bring out the big guns just yet. The code is written completely in plain old C: no C++ and no CFront.

KON It's got to be code you've written, because it's a PC-relative JSR. Since it's not an A5- relative JSR, it's not going through the jump table, so it couldn't have been linked in from a library or something external to your program. It looks like a call to a static function.

Chris Actually, all the JSR instructions in this code are PC-relative. I wrote a tool that transforms all JSRs that go through the jump table to PC-relative JSRs. You may want to sit down for this next part -- it's a little tricky.

KON That's why it ended up in the Puzzle Page. Let's hear it.

90 Chris All the code is being built into a ROM; however, our development system of choice only allows us to build our code as a Mac application. So I created a custom tool that postprocesses the application and turns it into something that will run out of ROM. Basically we use the CODE 0 jump table to link everything together.

KON I see. You know where the code will reside in ROM, so you fake out the jump table to make it look as if all the segments are loaded. Since nothing will ever move or unload, your ROM jump table entries never need to change. Pretty tricky.

Chris But not tricky enough. The scheme you describe will work, but it has two problems. First, our ROM can be mapped into different addresses, so the code must be completely relocatable. A Mac jump table contains JMP instructions with fixed long addresses (for example, JMP $4083143A), which are not relocatable. Second, as a cycle counter like you should know, the jump table is superfluous here, because no code will ever move or unload while it's running. You're doing a JSR to the JMP in the jump table -- the extra JMP is unnecessary and wastes cycles.

KON I didn't know you GX guys counted cycles. How do you get away with removing the extra JMP?

85 Chris Our tool scans all the object code for all instructions that reference the jump table. They are JSR xx(A5) (function call), PEA xx(A5) (pass a function pointer on the stack), and LEA xx(A5),Ax (get a function pointer in a local variable). When it finds one of these instructions, it looks up the function in the jump table and changes the instruction to a PC-relative version that simply references the address of the target function directly. Everything is PC-relative, so it relocates correctly, and there are no extra instructions.

KON But the PC-relative addressing mode has only a 16-bit offset, so you can only reference functions within 32K of the PC. Is your ROM that small?

80 Chris Are you kidding? The pictures for the About box are bigger than that. When we need to reference a function that's beyond 32K, we create a "jump island" that's still PC- relative but allows us a greater reach.

0020122A:   JSR     $00201FA8       ;go to jump island
0020122E:   MOVE.W  D0,(A3)
...
00201FA8:   LEA     *+0,A0          ;get pc
00201FAC:   ADDA.L  #$00014B02,A0   ;add long offset
00201FB2:   JMP (A0)                ;jump to destination

KON That looks suspicious to me. You're messing with A0 in your jump island.

75 Chris But that should be OK because the whole thing is written in C, which never passes a parameter in A0 and never expects A0 to be preserved.

KON I can't find a specific problem, but I'm still a little suspicious of all this OS code you're writing. You said that this code runs fine on your Quadra. Does the Quadra version undergo the jump table transformation process?

Chris No. The Quadra version is run just like a Mac application out of RAM.

KON Tell me all the differences between the two environments.

70 Chris The 68000 version of the software is different in two ways. First, it's generated with the exact same compiler, but without 68020 code generation enabled. Then, I run it through my BuildROM tool, which transforms all the jump table references to PC- relative references. The 68000 target hardware is a diskless system; the only way to get code into it is through ROM cartridges, so we can't try to run a version of the software that hasn't undergone the BuildROM step.

KON So the bug may have nothing to do with the differences between the 68040 and 68000 processors -- it may be the BuildROM process. Let's sum up what we know: First we saw a piece of code that allocates a block of memory and stores a value into that block, but the store never seems to happen. Near that code is an unexplained JSR which we believe is a function call. Finally, we know that a critical difference in the environment is that you alter the code path of function calls. It's really starting to smell like your BuildROM tool.

Chris The evidence is all circumstantial, counselor. The only questionable part of the BuildROM process we've seen is my usage of A0 in the jump islands, but I can't see a case where a C function call takes a parameter in A0 or assumes A0 is preserved.

KON We should trace through the NewDMAQueueEntry routine and see what that mysterious function call is doing.

65 Chris I put in a breakpoint. But when I run the program again, I drop into the debugger with a debug message complaining that some kind of parameter is out of range.

KON You mean the bug isn't reproducible?

Chris After many tries, this is the first time it's failed this way.

KON Hmm. What parameter is out of range?

Chris The debug message doesn't say, exactly. The value it's complaining about is in D2. The value is $00004E56.

KON That's a funny-looking number. It looks like an opcode to me. dh 4E56 tells me it's a LINK A6,#xx instruction. Where did the value in D2 come from?

60 Chris From a MOVE.W (A0),D2 instruction. The code seems to think A0 points to some data.

KON But it looks as if it points to code instead. Where is A0?

Chris It points to the start of a routine called VBLHandler.

KON VBLHandler sure sounds like an interrupt service routine to me, which would explain the various failure modes. Is the routine written in C? C routines don't bother to preserve A0, so your interrupt routine is trashing a register!

55 Chris There's some inline assembly code to save all the registers. Take a look:

 void VBLHandler(void)
{
asm {
    MOVEM.L     A0-A6/D0-D7, -(SP)
};

FlushQueue();
HandleVBLTasks();

asm {
    MOVEM.L     (SP)+, A0-A6/D0-D7
};
}

KON It seems quite suspicious to me that A0 points to the beginning of this routine. Sounds like your jump islands are at work. Look at the interrupt vector for your VBL handler.

50 Chris On this particular machine the VBL is handled as a level-6 interrupt. The level-6 vector is at $0078. It points to a jump island entry like the one above.

KON And the first thing it does is trash A0 before your inline assembly gets a chance to save it! Maybe you should stick to drawing bitmaps and leave the OS work to someone else.

45 Chris The problem is that the code that installed the interrupt handler is more than 32K away from the handler itself. So when it did an LEA xx(A5),Ax to get the address of the interrupt handler, the ROM builder tool needed to stick a jump island in there. Nasty. But I still need a way to do PC-relative jump islands.

KON Use the stack, son. Try this:

PEA     * ;push the pc
ADD.L   #xxxxxx,(sp) ;add a long offset
RTS     ;jump to the destination

Chris All this and you can draw bitmaps too! I'll fix the ROM builder tool to do this. But somehow I doubt that a VBL interrupt was hitting us at the same spot in my NewDMAQueueEntry routine every time. There must be another problem there.

KON We still have the breakpoint there; before we recompile and fix the bug, let's run it again and see if we can get the original failure mode to happen again.

40 Chris This time we hit the breakpoint. We trace over the NewPtr and see that it returns a valid pointer in A0. We step into the JSR at $20C5EC and it takes us to one of my jump islands.

KON Which alters A0, and then jumps to the function being called. What is the function doing?

35 Chris It's a very short routine; it just takes some parameters off the stack and does a few multiplies. It returns the result in D0 just like any normal C function would.

KON But is it using the trashed A0 for anything?

Chris No. In fact, it's not using any address registers at all. It only uses data registers for the multiplies. I repeat: no C function would ever take a parameter in A0.

KON So we return to the NewDMAQueueEntry routine, with a return value in D0. We save D0 in a local variable on the stack frame, and then hit the instruction at $20C5F4, which stores a value in the buffer pointed to by A0.

30 Chris But A0 still has the result of the jump island calculation in it. The code didn't set up A0 to point to anything!

KON Look at the listing of NewDMAQueueEntry again. The code gets the result of the NewPtr call in A0, makes the function call, and then assumes that A0 still has the valid pointer in it. But meanwhile, some wannabe OS programmer has gotten in there and hosed A0 on us!

20 Chris That function call seems to be doing the multiply. It must be some runtime math library that the compiler uses.

KON I'll bet one of your variables is a long word. With 68020 code generation turned on, the compiler was able to generate a long multiply instruction, but the 68000 doesn't have a long multiply instruction, so it calls the math library.

10 Chris I see. Since the math library was written by the same people who wrote the compiler, their code generator knows that A0 won't get trashed, so it doesn't bother to save and restore it around the call to the long multiply routine. Pretty sneaky.

KON But nice. You want the person writing your code generator to be the ultimate cycle counter. Since the Mac Segment Loader implementation doesn't trash A0, it's a worthwhile optimization for them to make.

Chris Except in this case, the code that performs a multiply is more than 32K away from where the math library resides in the ROM, so it hits a jump island and loses the value of A0.

KON Even a lowly register like A0 is sacred sometimes.

Chris So it appears.

KON Nasty.

Chris Yeah.

SCORING

• 80-100 Please fax your resumé to Catapult Entertainment, Inc., (408)366-2471.
• 60-75 We also have junior positions available.
• 40-55 Don't worry; just let CopyBits do the tricky stuff.
• 10-35 I see you've done your share of long multiplies. *

Chris YERGA During his four years working on QuickDraw GX, Chris learned a lot about graphics systems and large projects. He's currently employed by Catapult Entertainment, where he learned that a Sega is kinda like a Macintosh, a SNES is kinda like an Apple II GS, and carbon dioxide can be explosive. *

Thanks to Josh Horwich,

KON (Konstantin Othmer), and BAL (Bruce Leak) for reviewing this column. *