The MSP430 is a 16-bit microcontroller from Texas Instruments. The Amforth implementation is based on code from Camelforth by Brad Rodriguez. This code is heavily modified and completely merged with the AVR code from the initial Amforth code base.

This merge affects all higher order word like the interpreter itself. Most low-level stuff remained unchanged however. E.g. the inner interpreter is completely unchanged thus almost all assembly words work as before. To make room in the 8KB sized code segment, many words were removed. Some of them reappear as loadable forth source however. Some other like ,jmp are gone, since they make no real sense within amforth.

CPU Register Mapping

Standard Use

Forth Register MSP430 Register
W: Working Register R6
IP: Instruction Pointer R5
RSP: Return Stack Pointer SP (HW Stack)
PSP: Parameter Stack Pointer R4
UP: User Pointer R14
TOS: Top Of Stack R7
X: temporary register R10
Loop Index R8
Loop Limit R9
Y: temporary register R11
Q: temporary register R12

The remaining registers are used by the CPU itself (R0-R3).

Extended Forth VM Register Mapping

Forth Register MSP430 Register(s)
A: Index and Scratch Register R15
B: Index and Scratch Register R13

Core System

Threading Model

AmForth implements the classic indirect threaded variant of forth. The registers and their mappings are shown in table CPU Register Mapping.

Inner Interpreter

For the indirect threading model an inner interpreter is needed. On the MSP 430 it almost the same as on the AVR8 platform. There are two major differences.

  • the NEXT routine is compiled into each word, there is no central NEXT code.
  • It does not support interrupts.

Memory Allocation

The ANS 94 standard defines three major data regions: name space, code space and data space. The MSP430 system architecture uses three memory types too: Flash, RAM and Info Flash. These three memory types share a common address space. The Info Flash is copied to a pre-defined RAM region, that can be written back using SAVE. This write back is not performed automatically. That is a major difference to the EEPROM based configuration area in the AVR8.

User Area

The User Area is a special RAM storage area. It contains the USER variables and the User deferred definitions. Access is based upon the value of the user pointer UP. It can be changed with the word UP! and read with UP@ . The UP itself is stored in a register pair.

The size of the user area is determined by the size the system itself uses plus a configurable number at compile time. For self defined tasks this user supplied number can be changed for task local variables.

The first USER area is located at the first data address (usually RAMSTART).

Address offset (bytes) Purpose
0 Multitasker Status
2 Multitasker Follower
4 RP0
6 SP0
8 SP (used by multitasker)
10 HANDLER (exception handling)
12 BASE (number conversion)
14 EMIT (deferred)
16 EMIT? (deferred)
18 KEY (deferred)
20 KEY? (deferred)
22 SOURCE (deferred)
24 >IN
26 REFILL (deferred)

The User Area is used to provide task local information. Without an active multitasker it contains the starting values for the stackpointers, the deferred words for terminal IO, the BASE variable and the exception handler.

The multitasker uses the first 2 cells to store the status and the link to the next entry in the task list. In that situation the user area is/can be seen as the task control block.

Dictionary Management

The dictionary has all words and code. It is located in the flash region. The memory is managed with the dp dictionary pointer. It is a configuration RAM variable.

\ ( n -- )
: , dp !i dp 1 +! ;

Wordlists too use the configuration RAM. The wordlist identifier is the address of a RAM cell, that contains the link to the first word in the list.

: wordlist ( -- wid )
    infodp @ 0 over !
    dup cell+ infodp !e ;

The header command starts a new dictionary entry. It creates the same layout as the AVR8 but differs in the way, the header is built.

: header ( addr len wid -- NT )
  @ ,      \ link field
  $ff c,   \ flag field
  ihere >r \ Name Token NT
  s,       \ copy the string from RAM to flash
  r>       \

All higher level structures are identical.



Flash contains the dictionary. The actual placement depends on the device type but usually the amforth core system is at the higher addresses. User specific words start at flash start.

Reqriting flash pages is only possible if enough RAM ressources are available to buffer a whole page. Since a page is usually 512 bytes in size, the smaller device types like the G2553 cannot rewrite flash cells.

Info Flash

A 128 bytes segment called INFO D is used for configuration data. This block is copied to RAM at startup. Any changes to the data are applied to this RAM copy. Only an explicit command SAVE writes the configuration settings back to the info flash.


RAM is used for the info flash copy, data like the USER area, buffers such as the terminal input buffer and the acutal user data. Technically it would be possible to place the dictionary here too since nothing in the MSP430 architecture prevents this.


Some devices use FRAM instead of flash memory. While not strictly necessary, they too require the save command to make all changes to the dictionary permanent. This memory supports the create command.