| From: | Sam Jordan |
| Date: | 11 Dec 99 at 20:47:00 |
| Subject: | Re: [warpup] Re: GetMsgPPC arguement. |
Am 11-Dez-99 schrieb Joseph Fenton:
Hi
>You can do all your 68K handling in a seperate task created
>with exec for the 68K side; make the task assembly language
>and you'll be sure vbcc will keep it 68K. :^} It also allows
>you to make the 68K part as fast as possible and control exactly
>what it does. Handling messages and the like is very easy in
>assembly language; it's not the same level of programming
>as say a 3-D perspective correct texture rendering engine...
>anyone can handle that much assembly. Have the 68K task wait on
>messages and Io and anything else, then preprocess the data
>to a form that is easier for you to use on the PPC side, then
>flush that region of the cache and signal the PPC task. The
>PPC task can then simply check the signal staying completely
>on the PPC side eliminating the switch; when it sees the signal,
I'm not sure whether the effort of using an asynchronous architecture
is it really worth. Sure, it should work this way, but IMHO it's
a lot easier to use the synchron approach. One context switch is
usually irrelevant and a cross message also doesn't have zero cost
(although it's faster).
Here a function for event handling, written in 68k assembly for
easiest integration into my StormC project:
_handleMsg
move.l d2,-(sp)
move.l _SysBase,a6
move.l a1,d2
jsr _LVOGetMsg(a6)
tst.l d0
beq.b .err
move.l d0,a0
move.l d2,a1
move.l im_Class(a0),(a1)
move im_Code(a0),d0
ext.l d0
move.l d0,(a2)
move im_MouseX(a0),d0
ext.l d0
move.l d0,(a3)
move im_MouseY(a0),d0
ext.l d0
move.l d0,(a4)
move.l a0,a1
jsr _LVOReplyMsg(a6)
moveq #-1,d0
bra.b .end
.err
moveq #0,d0
.end
move.l (sp)+,d2
rts
On the PPC side there is something like that:
while (1) {
extern void handleMsg(void);
struct PPCArgs CallArgs;
CallArgs.PP_Code = (void *)handleMsg;
CallArgs.PP_Offset = 0;
CallArgs.PP_Flags = 0;
CallArgs.PP_Stack = 0;
CallArgs.PP_StackSize = 0;
CallArgs.PP_Regs[8] = (unsigned long)myWin->UserPort;
CallArgs.PP_Regs[9] = (ULONG)&class;
CallArgs.PP_Regs[10] = (ULONG)&code;
CallArgs.PP_Regs[11] = (ULONG)&dmx;
CallArgs.PP_Regs[12] = (ULONG)&dmy;
Run68K(&CallArgs);
if (!CallArgs.PP_Regs[0]) {
break;
}
switch(class) {
case IDCMP_RAWKEY: {
Usually there shouldn't be that many events per frame, that the
amount of context switches get large. In cases, where this is
a problem, the 68k function can collect all messages at once
and store it into an array.
>it invalidates the cache for the data area and then fetches
>data from the data area. A cache invalidation is virtually
>instantaneous as all it is doing is marking cache entries
>as not valid... no push-backs or the like are needed.
In theory that's surely right. But what I can say is, that people
should always try to avoid dealing with caches completely.
I personally would prefer having one or two more context switches
rather than have to add cache tricks to my program. Theory is one
thing, practice another. I consider cache tricks as potentially
dangerous concerning reliability and stability of applications.
bye