Is There a Forth implementation for Teensy 3.X

Status
Not open for further replies.
I do not know of anyone using Forth.

Do people really still use Forth? I mean, for real projects... the kind that merit photos & video of the project itself, independent of what language it used?
 
Paul,
I have always liked working with Forth (as a professional programmer at Sun, Rolm, JPL, etc. and as a hobbyist) and yes I do an occasional "real" project with it. Recently I did a FM digital receiver with LCD display and IR remote control with Forth on an Arduino Uno and I even implemented a filesystem based on FAT16 for a data collection project I did.

I think Forth on the Teensy3.1 would be great because:
* Performance with a 96MHz clock would be very good
* All development tools would be hosted on the Teensy3.1 itself so no more edit, compile, download, debug cycles using the Arduino or other IDE

To many Forth is a dying or dead language. For others it is an alternative way of programming that has its own charm.
 
Enclosed, from my dusty archives, is a Forth interpreter. Written partly in AVR Assembly, mostly in Forth itself.
Someone with time and motivation could convert the AVR assembly to C (fast enough on Teensy 3), then bootstrap the interpreter.
 

Attachments

  • amforth-3.1.zip
    512.4 KB · Views: 228
I believe this would require much more effort than simply the asm code, which is at least 7364 lines in 261 ".asm" files in the "core" directory.

For example, here's some of the forth code in the lib directory:

From lib/twi.frt:

Code:
\ enable twi
: +twi ( prescaler bitrate  -- )
    TWBR c!
    03 and TWSR c!
;

\ some random initialization. Works fine with 8 MHz
: twi.default
    7f 3 +twi ;

\ turn off twi
: -twi ( -- )
    0 TWCR c!
;
\ wait for twi finish
: twi.wait ( -- )
    begin
        TWCR c@ 80 and
    until
;

\ send start condition
: twi.start ( -- )
    [ 1 7 lshift
      1 5 lshift or
      1 2 lshift or ] literal
    TWCR c!
    twi.wait
;

From bitnames.frt:

Code:
\ A named port pin puts a bitmask on stack, wherin the set bit indicates which
\ bit of the port register corresponds to the pin.
\ And then puts the address of its port on stack too.

\ Use it this way:
\ PORTD 7 portpin: PD.7  ( define portD pin #7)
\ PD.7 high              ( turn portD pin #7 on, i.e. set it high-level)
\ PD.7 low               ( turn portD pin #7 off, i.e. set it low-level)
\ PD.7 <ms> pulse        ( turn portD pin #7 for <ms> high and low)
\ the following words are for "real" IO pins only
\ PD.7 pin_output        ( set DDRD so that portD pin #7 is output)
\ PD.7 pin_input         ( set DDRD so that portD pin #7 is input)
\ PD.7 pin_high?         ( true if pinD pin #7 is high)
\ PD.7 pin_low?          ( true if pinD pin #7 is low)
\
\ multi bit operation
\ PORTD F portpin PD.F   ( define the lower nibble of port d )
\ PD.F pin@              ( get the lower nibble bits )
\ 5 PD.F pin!            ( put the lower nibble bits, do not change the others )

hex

\ At compiletime:
\ Store combination of portaddress and bit number in a cell and give it a name.
\ At runtime:
\ Get pinmask and portaddress on stack.
: portpin: create ( C: "ccc" portadr n -- ) ( R: -- pinmask portadr )
    1 swap lshift
    8 lshift or ,               \ packed value
  does> i@                      \ get packed value
    dup 8 rshift swap ff and    \
;

With AVR hardware specific code implemented throughout the forth language sections, and the whole system built on top of thousands of lines of very AVR specific assembly code, I'd say amforth is among the least portable projects I've ever seen.

Together with the very low demand for Forth, I'd say the odds of amforth ever being ported to Teensy 3.1 are virtually zero.
 
Yep, unlikely anyone would want to tackle this or any Forth these days.
I didn't look for who was the original author, but I think it was noted as done in 2008.
 
I know there are still some die hard Forth enthusiasts out there. Sometimes I wonder if counting them all would yield a 2, 3 or 4 digit number?

But my overall impression is Forth really was a language of the 1980s. The glory days for Forth faded away a very long time ago...
 
At some point I will be porting an old Micro-LISP, and I have been thinking of a FORTH 89 implementation too.
I am currently working on some other projects at present though.
 
As to oldies... I did a lot of R&D work with Prolog. Non-procedural language. Very interesting to work with.
 
FORTH ----> Prolog...

From a language (complete with multitasking, etc.) meant for the smallest footprint, to a language meant for solving big AI problems (backtracking!), that's a wonderful stretch.

Threaded interpreters (FORTH being the canonical example) were known for being *extremely* efficient with system resources, though they required careful thought in development in my experience. In the days of Apple II and other limited-resource systems, FORTH was a real treat for those willing to geek out on the strictly stack-based nature of the language group.
 
http://sourceforge.net/projects/mecrisp/files/

http://mecrisp.sourceforge.net/

Mecrisp-Stellaris
Now it is time to finally announce the first stable release of Mecrisp-Stellaris !

Mecrisp-Stellaris is the younger sister of Mecrisp and runs on ARM Cortex M chips. This is a big family of microcontrollers with a common processor architecture and very different peripheral capabilities. The first stable release runs on three core flavours: M0, M3 and M4.

Out of the box, you get support for TI Stellaris Launchpad with LM4F120H5QR (M4), TI Tiva Connected Launchpad with TM4C1294NCPDT (M4), STM32F4 Discovery with STM32F407VGT6 (M4), STM32VL Discovery with STM32F100RB (M3) and Freescale Freedom FRDM-KL25Z with KL25Z128VLK4 (M0).
 
There is an email address on the sourceforge project page, might not hurt to ask. He already supports multiple vendors including the Freescale KL25Z

Open Firmware has also been ported to ARM and has a USB stack and networking implimented in forth. Think SUN boot prom .
http://www.openfirmware.info/Open_Firmware

Would like to see Mitch Bradley jump on the IoT bandwagon...
 
Status
Not open for further replies.
Back
Top