This very much depends on the Hardware that Forth is running on but the concept is very old. Interpreters of all types are used to encode higher level function

This very much depends on the Hardware that Forth is running on but the concept is very old. Interpreters of all types are used to encode higher level functions than the hardware supports as a single bytes or integers. Then you write your program using the byte/integer code as instructions and it takes less space for a given program. Byte code threaded programs are small but less speedy. (Open-Firmware is byte coded Forth) Traditional Forth systems encode this virtual machine as lists of addresses. These lists are "interpreted" by a piece of code that is 2 to 3 instructions on modern computers, so it's pretty fast. (slightly bigger on an 8 bit CPU) This address based VM code "can" be smaller on a 16bit machine but might not be on a 32bit machine until you raise the programming level to very high level functions. This depends on the CPU. On RISC-V it's probably still true based on what I see of the instruction set. (not tested) The typical Forth development cycle involves extending the language in the direction that one needs, writing higher level functions, combining them into even higher level functions such that at the end of the coding process you are using very few of these application specific functions to write the program. Thus a space saving because each function uses only one byte or integer in your program to reference it.