[futurebasic] Re: [FB] Convert 68K assem to PPC assem

Message: < previous - next > : Reply : Subscribe : Cleanse
Home   : September 1999 : Group Archive : Group : All Groups

From: Robert Purves <robert.purves@...>
Date: Sun, 19 Sep 1999 10:40:11 +1200
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