dsPIC has a gcc toolchain: http://iridia.ulb.ac.be/~e-puck/wiki/tiki-index.php?page=Cross+compiling+for+dsPic http://iridia.ulb.ac.be/~e-puck/share/cross-compiler/packages/pic30-binutils_2.01-1_i386.deb http://iridia.ulb.ac.be/~e-puck/share/cross-compiler/packages/pic30-gcc_2.01-1_i386.deb http://iridia.ulb.ac.be/~e-puck/share/cross-compiler/packages/pic30-support_2.01-1_all.deb It's a bit silly to try to compete with that. If Staapl should support dsPIC, it needs to do so on top of C. It might make sense to try to write some dsp-ish language that compiles to assembler, but it doesn't look like there is much to gain in writing an assembler + forth compiler in the same style as for PIC18. Once it's a multi-register RISC chip, C is really the way to go. Same for 32-bit ARM/MIPS. Also, when there's a C compiler available, not being able to integrate with it is commercial suicide. For the small controllers, you're going to be the only tool in the chain. Not so for the bigger ones... there are going to be libraries and C developers. So, where should Staapl live? - For 8-bit controllers < PIC18 Staapl = Forth based macro assembler. Implements native code generator. - For 16/32-bit controllers that have a decent C compiler: Staapl provides Forth based scripting language + DSP-ish array processing languages. Built on top of C. - For 32-bit systems based on PPC/Intel: Staapl's PLT Scheme based meta system. The unifying idea is concatenative languages: the bare metal macro Forths for the low end, a linear typed Forth for the mid end and the functional Scat/Scheme for the high end.