[<<][staapl][>>][..]
Fri Aug 15 16:22:27 BST 2008

Architectures: where to draw the line?

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.




[Reply][About]
[<<][staapl][>>][..]