3 ms·
You want assembly with some sugar. Read up on Forth languages. It's pretty much exactly what you're after.
by mystified5016 2y ago
You want assembly with some sugar.
Read up on Forth languages. It's pretty much exactly what you're after.
- mananaysiempre 2y agoForth 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).