So often, I've seen dispatch tables like this:
#define prvJmpSize 4
#define NUMBER_OF_FUNCTIONS 7
#define TABLE_OFFSET 2 * (NUMBER_OF_FUNCTIONS + 1)
#define MSL_DISPATCH_SLOT(i) (TABLE_OFFSET + ( (i) * prvJmpSize))
@TableStart:
DC.W @LibName
DC.W MSL_DISPATCH_SLOT(0) // MSLOpen()
DC.W MSL_DISPATCH_SLOT(1) // MSLClose()
DC.W MSL_DISPATCH_SLOT(2) // MSLSleep()
DC.W MSL_DISPATCH_SLOT(3) // MSLWake()
DC.W MSL_DISPATCH_SLOT(4) // MSLGetVersion
DC.W MSL_DISPATCH_SLOT(5) // MSLAdd
DC.W MSL_DISPATCH_SLOT(6) // MSLSubtract
JMP MSLOpen // 0
JMP MSLClose // 1
JMP MSLSleep // 2
JMP MSLWake // 3
JMP MSLGetVersion // 4
JMP MSLAdd // 5
JMP MSLSubtract // 6
I seem to recall reading that this is a workaround to "a compiler bug." Any
idea in which compiler, or if this rumor is even true?
I'm also a bit curious what goes on here. If I were to take an educated
guess, I'd say that the dispatch trap will find this dispatch table, and
then look for function 'n' (say MSLSleep() happens, so n = 3). The it does
this.
1) Go to the n+1 word. For some reason, we put an offset here.
2) Assume that this is the offset to the actual function 'n' ( MSLSleep() )
from the start of the dispatch table, so JMP to TableStart + this offset.
3) Surprise! It's another JMP, but this second JMP will put you where you
want to go this time, which is straight to MSLSleep()
Am I too far off base here? It sure sounds good. :)
Thanks, have a great weekend. I sure will, I turn 24 tomorrow!
-Jeff Ishaq
The Windward Group
