June 95 - KON & BAL'S PUZZLE PAGE
KON & BAL'S PUZZLE PAGE
A Branch Too Far
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
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
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
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:
+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
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
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
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
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
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
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
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:
MOVEM.L A0-A6/D0-D7, -(SP)
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
KON Which alters A0, and then jumps to the function being called. What is the function
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
KON Even a lowly register like A0 is sacred sometimes.
Chris So it appears.
- 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. *