cross-compiling for resource-constrained targets

[biosbob]

interesting project....

my use-case targets resource-constrained embedded MCUs with ~32K of memory, which today are programmed in "bare-metal" C code....

were i to "constrain" my use of typescript to require a very minimal runtime, could i in theory use tsc with any target supported by LLVM???

[ASDAlexander77]

in short answer: in theory - yes, In practice I didn't try many different "targets". The only targets which I tried were "x86, x64, Wasm32, Wasm64" and I am sure "arm64" will work. any 32-bit platforms required extra testing.

[ASDAlexander77]

An update, since a lot has changed since the short answer above.

32-bit targets work now. The compiler takes pointer width and data layout from -mtriple, and the whole test suite runs at i686 (about 1400 tests). Android armeabi-v7a (-mtriple=armv7a-linux-androideabi29) is a supported target too, alongside arm64-v8a, x86_64 and wasm32. A bare-metal triple such as thumbv7em-none-eabi has not been tried yet, so treat it as "should work in principle, untested".

You don't need a garbage collector. Pick the memory model with -mm=:

• -mm=none: memory is never freed. Fine if you allocate once at startup and never again, which is common on MCUs.
• -mm=own: single ownership checked at compile time, like Rust's borrow checker. Memory is freed deterministically, with no collector and no reference counts. It's still in development, and code whose ownership can't be proven is a compile error.
• -mm=rc: reference counting, with no collector.

The runtime you'd have to supply is small. The wasm32-unknown-unknown build is the best guide to what a freestanding target needs. With -mm=none the program only imports a handful of C functions from the host: malloc/realloc/free, memset, strlen/strcpy/strcat/strcmp, puts, atoi/atof, sprintf_s, and a few math functions (sqrt, pow, floor, fabs, fmod). See the loader in the README's Compiling as WASM section. On an MCU, newlib-nano or picolibc (or a few lines of your own) can provide these. Build with --emit=obj and link the object with your startup code and linker script, as you would for C.

Things to keep in mind at ~32K:

• number is a 64-bit float. On a core without a double-precision FPU, use int/i32/u8… types for your arithmetic, or it pulls in soft-float.
• Avoid try/catch/throw: exceptions need an unwinder, which is too much for a part this small.
• Strings, closures and dynamic arrays allocate from the heap, so a C-like subset (classes, typed arrays, plain functions) keeps the heap small and predictable.
• Calling C is easy. declare function binds to C functions and globals, so you can call your vendor HAL or CMSIS directly.

If you try it on a real board (Cortex-M or RISC-V), please open an issue with the triple and whatever breaks. A bare-metal target is the next thing worth testing.