In relation to this thread, I would like to point out a documentation error in the FB^3 Reference Manual, where an extravagant and incorrect assertion is made: "Mixed-mode compilations. If your program is being compiled for the PPC CPU, you can still include lines of 68k assembly language in your program if you precede them with the BEGINASSEM _cpu68k statement. When your program runs (on a PPC), then your 68k assembly statements will be executed by the PPC's "68k emulator" software." This is wrong. You _cannot_ use 68K assembly instructions in a program compiled for PPC. That is to say, FB^3 lets you put them in, but they are certain to crash. Consider the following short program, which runs OK in 68K but gives a "PowerPC illegal instruction" error in PPC (when you type G <return> to leave MacsBug): LOCAL FN Test CALL DEBUGGER BEGINASSEM cpu68K moveq #-1,d0 ; assembles as $70FF ENDASSEM END FN FN Test DO UNTIL FN BUTTON The PPC disassembly shows why: TEST ; LOCAL FN Test +00000 b 'FCOD 03E9 1B8C FB^3.PPC'+1F9DC +00004 mflr r0 ; Save.. +00008 stw r0,0x0008(SP) ; ..link reg +0000C stmw r13,-0x0060(SP) ; Save non-volatile regs +00010 stwu SP,-0x00A4(SP) ; Set up.. +00014 addi r13,SP,0x0020 ; ..stack frame +00018 bl 'FCOD 03E91B8C FB^3.PPC'+1FC54 ; CALL DEBUGGER +0001C lwz RTOC,0x0014(SP) +00020 andi. r31,r7,0x4800 ; $70FF 4800 +00024 dc.l 0x02A18041 ; Meaningless.. +00028 dc.l 0x00143821 ; illegal garble.. +0002C dc.l 0x00A48001 ; from here on.. See that $70FF? It's the 68K 2-byte opcode, assembled right into the compiler's output stream of PPC opcodes. This particular 68K opcode happens to be a legal PPC opcode (andi.) so the PPC processor can execute it. Of course, what it does (andi.) bears no resemblance to the 68K assembly programmer's original intention (moveq) . Moreover, the insertion of 2 bytes into the stream causes all subsequent PPC code to be illegal rubbish. This whole "feature" seems to me to be misconceived. Technically it would be possible for Staz'n'Andy to fix up the crash bug, by providing a Universal Procedure Pointer (effectively a MixedMode wrapper) for the 68K code, so that it would be emulated correctly. But there seems remarkably little point in doing so. Without screeds of additional code, the 68K section would have no access to FB variables, thus rendering it largely useless. I think that this "feature" should be removed from the documentation. Furthermore, the compiler should flag BEGINASSEM cpu68K as an error when compiling for PPC. A better mechanism to invoke 68K code from PPC already exists: a separate code module, invoked via UNIVERSALFN. Robert Purves