.. index:: miscellanious


.. " here $8381 , execute " pushes the current RAM pointer onto the stack, compiles two opcodes into RAM — HALT and RET on the
    STM8S in this example and runs  them. From the  command line running on the microcontroller.


.. jcwren says: January 28, 2017 at 6:28 am
    I've always been a Forth proponent, but haven't gotten to do as many projects as I'd have liked in it.
    15 or 16 years ago I built up a Z80 SBC board to test the idea of using a Compact Flash card as storage for a CP/M   machine,
    using only a Z8420 (PIO) to drive it (http://tinymicros.com/wiki/Z80_SBC). I used Forth for the boot monitor as it was easy
    to modify the code interactively while debugging instead of burn and churn with an EPROM programmer.
    I've used Forth on a couple of PIC18 projects, a port of CH Tings Forth on a 8031 for a handheld device to enter fuel
    purchases for tracking MPG, and a few other minor things. I also wrote a Forth interpreter in C for a piece of test
    equipment, to allow testers to string words together to run a series of tests (it also supported strings as a data type
    to make life easier for anyone who had to write their own test words).
    Forth used to be one of the first languages brought up on a new architecture. With only 15 or 16 words needing to be
    written in assembly, it was extremely easy to port to any machine that already had an assembler, and only slightly
    more difficult if it didn't.
    Most people who haven't used Forth will parrot the statement that Forth is a write-only language. And without proper
    documentation, that's a fairly accurate statement, especially when you start making use of immediate words in definitions
    and deferred words (one of the more powerful parts of Forth). And if you're old-school Forth and still use screens
    instead of files for source, it's even more true. Of course, without much effort you can write write-only code in most any language.



Miscellanious
=============