OBJFILES := $(subst .cpp,.o,$(CXXFILES))
LIBFILE := libalee/libalee.a
+STANDALONE := forth/core.fth
+
all: alee
msp430: CXX := msp430-elf-g++
msp430: LDFLAGS += -L/usr/msp430-elf/usr/include -Tmsp430/msp430g2553.ld -Wl,-gc-sections
msp430: clean-lib msp430/alee-msp430
+msp430-prep: STANDALONE += forth/msp430.fth
+msp430-prep: core.fth.h
+
small: CXXFLAGS += -Os -fno-asynchronous-unwind-tables -fno-threadsafe-statics -fno-stack-protector
small: alee
xxd -i $< > $@
sed -i "s/unsigned /static const &/" $@
-alee.dat: alee forth/core.fth
- echo "3 sys" | ./alee forth/core.fth
+alee.dat: alee $(STANDALONE)
+ echo "3 sys" | ./alee $(STANDALONE)
clean: clean-lib
rm -f alee alee-standalone msp430/alee-msp430
# Alee Forth
-Alee is a concise Forth implementation written in modern C++ that aims for portability, minimal program size, and execution efficiency.
+Alee Forth is a concise Forth implementation written in modern C++ that aims for portability, minimal program size, and execution efficiency.
## Cross-platform compatibility
-Alee relies on the C++17 standard. Alee *does not* rely on operating-system-specific functions, making portability easy.
+Alee Forth relies on the C++20 standard. It *does not* rely on any operating system. As a result, portability extends down to microcontroller targets with < 1 kB of memory. See the `msp430` folder for an example of such a port.
-The goal of portability extends down to microcontroller targets with kilobytes of memory. See the `msp430` target for an example of a port.
-
-System-specific functionality is obtained through a `sys` Forth word. This word calls a user-supplied C++ function that implements the necessary (or any additional) functionality.
+System-specific functionality is obtained through a `sys` Forth word. This word calls a user-supplied C++ function that implements whatever functionality is needed.
## Forth compatibility
-Alee implements a large majority of the "core" and "core extension" [word sets](https://forth-standard.org/standard/core). Implementation is tracked in `compat.txt`, with missing words listed below. Fundamental words are built into Alee (written in C++); the rest of the implementation is in `core.fth` and `core-ext.fth`.
-
-Running Alee without `core.fth` or `core-ext.fth` passed as arguments will leave you with a minimal word set. The `standalone` target will package the `core.fth` dictionary into the program.
+Alee implements a large majority of the "core" and "core extension" [word-sets](https://forth-standard.org/standard/core). Implementation is tracked in `compat.txt` with missing words listed below. Fundamental words are hard-coded into Alee while the rest of the implementation is found in `forth/core.fth` and `forth/core-ext.fth`. Running Alee without these implementation files will leave you with a very minimal word-set. These files may be compiled into the Alee binary by building the `standalone` target.
**Missing** core features:
* Pictured numeric output conversion (e.g. `<# #>`)
.R HOLDS PAD PARSE PARSE-NAME REFILL RESTORE-INPUT S\" SAVE-INPUT SOURCE-ID U.R U> UNUSED WITHIN [COMPILE]
```
-Alee aims for compliance with common Forth standards like Forth 2012 and ANS Forth. Compliance is tested using a [Forth 2012 test suite](https://github.com/gerryjackson/forth2012-test-suite). Supported test files are in the `test` directory, with tests for unimplemented words commented out.
+Alee aims for compliance with common Forth standards like Forth 2012 and ANS Forth. Compliance is tested using a [Forth 2012 test suite](https://github.com/gerryjackson/forth2012-test-suite). Supported test files are in the `test` directory with tests for unimplemented words commented out.
## Building
-Alee requires `make` and a C++17-compatible compiler. Simply running `make` will produce the `libalee.a` library and a REPL binary named `alee`. Note that this binary has no built-in libraries; these can be passed in by calling `./alee core.fth core-ext.fth`.
+Alee requires `make` and a compiler that supports C++20. Simply running `make` will produce the `libalee.a` library and a REPL binary named `alee`. You will likely want to pass in the core implementation files by calling `./alee forth/core.fth forth/core-ext.fth`.
-There are other build targets:
+Other available build targets:
* `small`: Optimize for minimal binary size.
* `fast`: Optimize for maximum performance on the host system.
* `standalone`: Builds the core dictionary (`core.fth`) into the binary.
-* `msp430`: Builds a binary for the [MSP430G2553](https://www.ti.com/product/MSP430G2553) microcontroller. The `standalone` target must be built first for the core dictionary.
+* `msp430-prep` and `msp430`: Builds a binary for the [MSP430G2553](https://www.ti.com/product/MSP430G2553) microcontroller. See the `msp430` folder for more information.
-If building for a new platform, see `Makefile`, `types.hpp`, and `state.hpp` for available configuration options.
+If building for a new platform, review these files: `Makefile`, `libalee/types.hpp`, and `libalee/state.hpp`.
--- /dev/null
+# msp430 implementation
+
+This is the MSP430 port of Alee Forth. It produces a binary that enters a REPL made available on the UART peripheral at 115200 baud. The specific target is MSP430G2553.
+
+## Building
+
+1. `make clean` (just in case)
+2. `make msp430-prep`: Builds `alee` for the host computer and uses it to create an `alee.dat` blob containing bytecode for `forth/core.fth` and `forth/msp430.fth`.
+3. `make msp430`: Produces `alee-msp430`, a standalone binary for the MSP430 with built-in core and msp430 word-sets.
+
+The final binary is < 11 kB and provides 150 bytes for user dictionary in RAM (assuming 512 bytes of total RAM).
+
+## msp430.fth
+
+The msp430 word-set makes programming for the MSP430 easier:
+
+* All register names are defined (P1OUT, ADC10MEM, etc.).
+* `r!` and `r@` to write and read device memory (i.e. registers).
+* `rset`, `rclr`, `rtgl` work like `r!` but set, clear, or toggle the given value/mask instead.
+