In my last post I talk about writing my new language fil in uForth via 3 stage metacompilation.
I want to note here that there is an alternate approach I am considering: Tethering.
I don't need to metacompile fil in order to get it running on a small MCU. If I retain the C code that does interpreting/compiling (bootstrap.exe) and write a new stripped down VM that doesn't understand interpreting/compiling (fil.exe), I only have to port the stripped down VM to the MCU. I would do all of my development/compiling on the PC (with bootstrap.exe -- renamed pc-fil.exe). The resulting byte code image (from compilation) would be moved to the MCU and run by the ported fil.exe.
This approach is a subset of what uForth already does. However, uForth also allows for the C based interpreter/compiler to run on the MCU. This is a bit weighty, but essentially gives me the ability to interactively develop directly on the MCU (interacting through a serial interface).
A better approach is tethering, and fil will prefer this approach even if I do re-implement the interpreter/compiler in uForth. In tethering, you do your development on the PC (using fil.exe/bootstrap.exe) and craft a MCU VM that listens on a serial port for special "commands". These commands can be as simple as "store byte-code" and "execute byte-code". You maintain a mirror of the dictionary between the PC and MCU. All the MCU VM needs to do (from an interaction perspective) is write PC compiled byte-code to its dictionary and to be able to execute it. No interpreter is needed.
This is the brilliant method used by various Forths including MyForth, and Riscy Pygness.
If I run into too many walls doing my 3 stages, I may take a break and just go tethered. I do have MCU CFT projects I want to get done!
hi,
ReplyDeleteI've develpped the msp430 Launchpad tinyForth under
win32Forth originally from Tom Zimmer. The style is quite different from the traditional ones. Such as:
t: tinyForth initialize
begin get.command ecute.command
again
This is universal to all cpus and it is very simple.
By the tehnique of tethered Forth we don't have to leave the interpreter/compiler in the target, that way relieving the burden of the target cpu to the minimum to less than 2k of flash to run the tinyForth. We can find the complete source code in:
http://tech.groups.yahoo.com/group/armForth/files\msp430
have fun with tinyForth.
**** C-style as well. ****
t: test.adc
ADC10CTL0=ADC10SHT_2+ADC10ON+ADC10IE;
ADC10CTL1=INCH_1;
ADC10AE0|=0x02;
P1DIR|=0x01;
ahd'
begin' P1OUT&=~0x01;
then'
begin'
ADC10CTL0|=ENC+ADC10SC;
__bis_SR_register(CPUOFF+GIE);
(ADC10MEM:0x1FF);
until'c=1
P1OUT|=0x01;
until'c=0 ret
**** macro-instruction-style ****
t: 4drop {nip}
t: 3drop {nip}
t: 2drop {nip}
t: drop {drop}
t: noop ret
t: ?dup if'T<>0 t: dup {dup}
then' ret
Just to show a little, we can see more in the file.
Thanks, I'll check it out.
ReplyDelete