3 ms·
Forth is kind of weak dealing with value types of unknown size. For example, suppose you're writing a cross-compiler, and an address on the target machine might
by mananaysiempre 2y ago
Forth is kind of weak dealing with value types of unknown size. For example, suppose you're writing a cross-compiler, and an address on the target machine might take one or two cells on the host machine depending on the host bitness. Now suppose you need to accept a (host-machine) cell and a target-machine address (e.g. an opcode and an immediate) and manipulate them a bit. Trivial in C, definitely possible in Forth, but supremely annoying and the elegance kind of falls apart.
- sylware 2y agoendian support is like the memory barrier and atomic support, should be inline function/keyword.
- mystified5016 2y agoAssembly isn't portable? Wow! You must be some type of genius! I'll start calling newspapers
- mananaysiempre 2y agoAssembly language isn’t, but assemblers usually are. If you want a (cross-)assembler for 32-bit x86, you can build GNU as or Nasm on any reasonable platform with a C implementation, because, ultimately, bytes are bytes, and you can write void emitd(struct buf *buf, int opcode, uint_least32_t address); or however it looks inside your assembler without caring what sizeof(int) is (assuming CHAR_BIT is 8). By comparison, in Forth that will be emitd ( buf op adr -- ) ( 32-bit host ) emitd ( buf op ahi alo -- ) ( 16-bit host ) depending on the bitness of where your assembler runs, even if the machine it assembles for is exactly the same in both cases. You cannot hide the platform difference behind a typedef for uint_least32_t or whatnot, unless you’re willing to drastically reshape the entirety of Forth from inside (which it does allow).