5 ms·

Thanks for the blog pointer, an interesting read. As the blog author points out, local variables are a huge issue on a stack machine because they lead to stack

• progman 10y ago
  > local variables are a huge issue on a stack machine Forth routines are usually short so they don't need local variables. > ANY stack manipulation must be seen as fundamentally inefficient Why? I remember developing Forth code on a 6502 machine, and the code was just ten times slower than native assembler. That's not bad for a byte code interpreter. And the byte code is extremely compact which makes Forth very suitable for tiny systems.
  • dewster 10y ago
    > Forth routines are usually short so they don't need local variables. Variables have to go somewhere. In a zero operand machine they go on the stack. Good luck finding them amidst all the confusing rolling, picking, duping, etc. > Why? Because the ALU is just laying there doing nothing while the stack is having it's spine manipulated (see above).
    • astrobe_ 10y ago
      > Variables have to go somewhere. Good luck finding them amidst all the confusing rolling, picking, duping, etc. Of course you don't want to use roll or pick. That's tutorial-level knowledge that you shouldn't use them. What you do when you see that coming is that you offload something to a global variable. The "something" is often the central topic of some part of the program, like a file handle for instance. So it makes sense to put it in a variable because it's needed in many places.
      • progman 10y ago
        > Of course you don't want to use roll or pick. That's tutorial-level knowledge that you shouldn't use them. I think the opposite is true. Basic, Assembler and Forth were my first languages. Forth was the one that was the most powerful, and it showed me best on bare metal how a computer works.
    • progman 10y ago
      > Variables have to go somewhere. As I already mentioned, in Forth you barely need variables. Everything happens on the stack. The rest is global. Forth requires a radical shift in thinking about programming. You should read Leo Brodie's book "Thinking Forth". http://thinking-forth.sourceforge.net/ http://thinking-forth.sourceforge.net/ > Good luck finding them amidst all the confusing rolling, picking, duping, etc. Good Forth code style uses comments all the time. For instance: ( swap the two top values ) : myswap ( x y -- y x) <= x y is input, y x is output swap ( y x ) ; If you keep every Forth routine small then you can really have fun in Forth without local variables. By the way, I would never use Forth for big software. Forth is particularly powerful in tiny systems where every byte matters.
• nickpsecurity 10y ago
  "ANY stack manipulation must be seen as fundamentally inefficient, and they make Forth a naturally obfuscated write-only language IMO." This is one issue I have with them. Real machines have local, fast storage you address directly with stores or functions operating on them. They have a remote storage, RAM, that you might work on directly with a CISC or move to local storage with many RISC's. In any case, the fundamental mechanisms are functions operating on individual data or function pointers. Best to map a high-level abstraction or low-level language directly to that. Whereas, a stack that flows this way, heap that flows that way... all this stuff isn't anything like how a computer fundamentally works. Except the stack-oriented architectures of course. :) An alternative assembler might have variables, expressions, and function calls. Maybe differentiate between pointers and non pointers. Compile can handle (or help handle) mapping of that to non-stack machines. Looks a lot closer to Modula-2 or Oberon in the process once you consider ability to read, protect, and optimize the source code. Even though Wirth prefers stack machines for them. Another showed you could directly compile a subset to hardware: http://vbn.aau.dk/ws/files/58355126/main.pdf http://vbn.aau.dk/ws/files/58355126/main.pdf