* AND VARIABLE LENGTH NAMES\r
* Try again with literal subroutine substitution mode, one step at a time.\r
*\r
+* If I require a 68020 or better, I could use BSR.L for all calls to characteristic code.\r
+* But without BSR.L, the synthetic load offset followed by JSR PC-relative \r
+* is more than I want to do for constants and such.\r
+*\r
+* Using an address register as a base for the kernel (per BIF-6809's use of DP)\r
+* does not completely solve this,\r
+* since even that has only 16-bit constant offset in plain 68000.\r
+* New defining definitions would be required to exist within the reach of the 16-bit offset,\r
+* unless the synthetic long version of the base-offset JSR is also recognized by the kernel.\r
+*\r
+* Either way, three steps are wanted:\r
+* The first is to get the subroutine call version working within the 16-bit offset range.\r
+* The second is to add enough of the assembler to the kernel to compile new defining definitions. \r
+* The third is to flatten all definitions, stripping out the inner interpreter when done.\r
+*\r
+* If I am brave enough, I could simply flatten everything up front,\r
+* requiring me to add the basic parts of the assembler before I can actual compile anything at all. \r
+*\r
+* BUT!\r
+*\r
+* That would require me to plan far enough ahead to,\r
+* among other things, clear all variable objects out of the symbol table.\r
+* And that requires defining a global variable space separate from the dictionary.\r
+*\r
+* But that's not really what should be done,\r
+* because all global variables should be managed -- \r
+* meaning that they should be managed by the code for the modules that define them,\r
+* meaning that there are no real global variables.\r
+*\r
+* Meaning that I have to plan ahead and lay out the structures\r
+* and define the interface mechanisms of modules.\r
+*\r
+* Which is a huge jump past fig-Forth. \r
+* Which kind of means leaving fig-Forth behind,\r
+* and picking BIF back up, and cleaning BIF up and adapting it for the 68000,\r
+* and then laying out the intermodule call mechanisms.\r
+*\r
+* Backing off of that idea, I could go back and use the synthetic far call \r
+* to call all the characteristic code, even though it's inefficient.\r
+*\r
+* But I've really never liked the idea of variables physically adjacent to code.\r
+* Constants, sure. Variables, no.\r
+*\r
+* Maybe I should back up a step and flatten the definitions of the native return version,\r
+* see where that leads.\r
+*\r
* Adapted by Joel Matthew Rees \r
* from fig-FORTH for 6800 (via buggy fig-FORTH for 6809) by Dave Lion, et. al.\r
\r
*ZERO MOVE.L #DOCON-(ZERO+2),A0 ; 6 bytes, overwrite offset in long word following opcode\r
* JSR ZERO+2(PC,A0.L) ; 4 bytes. DOCON, as it currently is written, expects either this or BSR.\r
* DC.L 00000000 ; Making these uniform will make things easier for the debugging.\r
+*NOVAR MOVE.L #DOVAR-(ZERO+2),A0 ; 6 bytes, overwrite offset in long word following opcode\r
+* JSR NOVAR+2(PC,A0.L) ; 4 bytes. DOCON, as it currently is written, expects either this or BSR.\r
+* DC.L INITIALV ; Making these uniform will make things easier for the debugging.\r
+*SZERO MOVE.L #DOUSER-(ZERO+2),A0 ; 6 bytes, overwrite offset in long word following opcode\r
+* JSR SZERO+2(PC,A0.L) ; 4 bytes. DOCON, as it currently is written, expects either this or BSR.\r
+* DC.L XSPZER ; Making these uniform will make things easier for the debugging.\r
+*FORTH MOVE.L #DODOES-(ZERO+2),A0 ; 6 bytes, overwrite offset in long word following opcode\r
+* JSR FORTH+2(PC,A0.L) ; 4 bytes. DOCON, as it currently is written, expects either this or BSR.\r
+* DC.L DOVOC,VOCFLG,TASK-5-NATWID ; Making these uniform will make things easier for the debugging.\r
*\r
* Or do I copy the characteristic code right into the parameter field, leaving the CONSTANT (et. al.) \r
* sitting after the code, like this for CONSTANTs:\r
*NOVAR LEA NOVARV(PC),A0 ; 4 bytes, relative (*+8), the code can just be copied in.\r
* MOVE.L A0,-(PSP) ; 2 bytes, again, the code can just be copied in.\r
* RTS ; 2 bytes, actual variable is after the RTS, still easy to find.\r
-*NOVARV DC.L 00000000 ; However, the debugger needs to be aware of this code.\r
+*NOVARV DC.L INITIALV ; However, the debugger needs to be aware of this code.\r
* ; For USER variables (allowing large, greater than 32K, USER variable tables),\r
*SZERO MOVE.L SZEROC(PC),D0 ; 4 bytes, relative (*+10), the code can just be copied in.\r
* LEA (UP,D0.L),A0 ; 2 bytes, again, the code can just be copied in\r
* MOVE.L A0,-(PSP) ; 2 bytes, again, the code can just be copied in.\r
* RTS ; 2 bytes, actual offset is after the RTS, still easy to find.\r
-*SZEROC DC.L $00000018 ; Again, the debugger must be aware of this code.\r
+*SZEROC DC.L XSPZER ; Again, the debugger must be aware of this code.\r
+*\r
+*Have to define DODOES to figure out what goes here.\r
*\r
* Or, do I go ahead and optimize DOCON and DOUSER?\r
*ZERO MOVE.L #00000000,-(PSP) ; 6 bytes, CONSTANT compiler needs to know the instruction format.\r
* MOVE.L A0,-(PSP) ; 2 bytes, can be copied as is.\r
* RTS ; 2 bytes, 12 total, including offset. And debugger needs to be more intelligent.\r
*\r
+*Have to define DODOES to figure out what goes here.\r
+*\r
* Leave the name SMUDGEd.\r
EVEN\r
DC.B 0\r
OSDN Git Service
