3 ms·

>most implementations in C switch between several nearly-identical code blocks depending on how steep the line is ...which the code in this blog post avoids by

>most implementations in C switch between several nearly-identical code blocks depending on how steep the line is ...which the code in this blog post avoids by defining words that compare dx with dy and return pointers to the "short" and "long" coordinate? You could do the same in C or most other languages. The problem is that in other languages, a Sufficiently Advanced Optimizer™ could at least in theory analyze the source code, and then emit those nearly-identical code blocks, whereas Forth is more like a platform-independent macroassembler: there is no zero-cost abstraction, every word you write in the source code will result in some predetermined machine instructions being executed (and usually with extra interpreter overhead). Actual assembly code seems less confining, since at least you have a few different registers and addressing modes to play with, rather than just a stack. I still kind of like the idea of Forth, but pretty much agree with this article: http://yosefk.com/blog/my-history-with-forth-stack-machines.html http://yosefk.com/blog/my-history-with-forth-stack-machines....

akira2501 3y ago
> every word you write in the source code will result in some predetermined machine instructions being executed Not strictly.. I wrote a partially optimizing Forth compiler that could combine compiled words when building new words that used them from the interpreter, analyze the generated assembly for unnecessary stack movement of arguments, and eliminate the stack movement and if necessary emit MOV instructions to fixup the output results into the correct input registers. This was not terribly difficult. The harder part was susequently decoding the concatenated x86 instruction streams to do this type of analysis, but once the PUSH and POP trains were spotted, they were super easy to just eliminate. With careful coding of the assembly words, you could guarantee that common expressions never needed any MOV fixups and could just pass results that were sitting directly in the registers.

akira2501 3y ago

> every word you write in the source code will result in some predetermined machine instructions being executed Not strictly.. I wrote a partially optimizing Forth compiler that could combine compiled words when building new words that used them from the interpreter, analyze the generated assembly for unnecessary stack movement of arguments, and eliminate the stack movement and if necessary emit MOV instructions to fixup the output results into the correct input registers. This was not terribly difficult. The harder part was susequently decoding the concatenated x86 instruction streams to do this type of analysis, but once the PUSH and POP trains were spotted, they were super easy to just eliminate. With careful coding of the assembly words, you could guarantee that common expressions never needed any MOV fixups and could just pass results that were sitting directly in the registers.