9 ms·

>Running Forth is not so good. Why not?

by Volt 10y ago

nickpsecurity 10y ago
It's an untyped, stack language. A strongly-typed language gives you more readability, safety/security and optimization abilities. Dynamic, but still safe, typing plus hygenic macros can be used to make that even higher-level and more productive. Plus, there's tons of tooling, talent, and libraries for a few, good ones. Forth is behind the curve in almost every respect. Forth is the way it is mainly because Chuck Moore wants it that way. It's his preference. Tiny cores, typeless, hand-optimized to near metal, primitive VLSI tooling, 18-bit CPU's... nothing justified by scientific or engineering argument. All surpassed by other work in cost-benefit analysis. Nice write-up here by one person that delved deep into it to see good and bad of it: http://yosefk.com/blog/my-history-with-forth-stack-machines.html http://yosefk.com/blog/my-history-with-forth-stack-machines....
- avmich 10y ago
  An assembler is usually C-typed and non-stack. If you want extra features, you're welcome to write a translator for higher level language - you just have an opportunity to use Forth as your target, not typical assembler. At the same time you can have top performance with a concatenative, dense language. It doesn't mean Forth is most convenient to write for any kind of problems, or that translator can easier optimize for Forth target... yet this at least is an opportunity to have a nicer language on the bare-bones level. Do you think it's a good enough thing?
  - nickpsecurity 10y ago
    "If you want extra features, you're welcome to write a translator for higher level language - you just have an opportunity to use Forth as your target, not typical assembler. " One paper in my collection does that for IIRC Haskell to Forth by implementing a G-machine interpreter or compiler for a Forth CPU. It certainly can be done. Question is whether it's ideal vs a non-Forth CPU. "At the same time you can have top performance with a concatenative, dense language." I can do that with a Leon3 SPARC GPL'd with LISP or Forth extensions. It will be faster. Likewise, one can modify a simple, microcoded CPU to run Forth, Oberon, LISP, or whatever. Difference is that we're not tied to Forth's style in the process. "yet this at least is an opportunity to have a nicer language on the bare-bones level. Do you think it's a good enough thing?" If you have nothing else. Otherwise, no. I think, as I commented to avshalom, we can modify a flexible, simple RISC to have basic checks built-in. With microcode, you can raise abstraction to primitives of your choosing from expressions to stacks to heaps to pointer manipulation. Whatever you want.These can be composed of primitive instructions with checks enabled or disabled. You can then code in those with safe, highly-optimized primitives underneath making it fly in performance. Further, as Intel does, you can always change underlying architecture to speed-up your model as you're leveraging microcode or ISA level. Last point, as my conversation with Alan Kay shows, is that modifying hardware to support OOP and late binding allows you productivity and code reduction of Smalltalk-style languages with still efficient, safe execution.
    - avmich 10y ago
      This a little bit seems like just moving the question on another level - from software to hardware. How much it would cost to you in terms of hardware - and maybe speed? - to have extensions which will have those nice features, especially if they are flexible, i.e. switchable? Would you need less gates than a Forth system?
      - nickpsecurity 10y ago
        "Would you need less gates than a Forth system?" That's not a fair question given Forth doesn't do crap compared to alternatives I'm pushing. More like "Does it use a reasonable number of gates for a commercial processor? For a MCU, do any schemes use a tiny number of gates to provide some protections vs existing MCU's?" Answer to these are yes. As several people want links, here's a list of approaches ranging from safety to security, full to partial, MPU to MCU. Two of the best for full safety are Hardbound and Watchdog, both from same group: https://www.cis.upenn.edu/acg/papers/asplos08_hardbound.pdf https://www.cis.upenn.edu/acg/papers/asplos08_hardbound.pdf https://www.cs.rutgers.edu/~santosh.nagarakatte/papers/isca12_watchdog.pdf https://www.cs.rutgers.edu/~santosh.nagarakatte/papers/isca1... One provides full spatial safety with other providing full memory safety with both having C compatibility. There are significant extra chip resources. Not a problem in a microprocessor, though, given the frivilous stuff takes up more space than this. The performance overhead is usually single-digit (under 5%) with it maxing out on 20% on Hardbound and 25% on Watchdog. For Watchdog, that's trading occasional 25% hit or buying a bit of extra CPU to get fully-compatible and safe C software. Great trade. HW experts could probably optimize it even further. CHERI processor: https://www.cl.cam.ac.uk/~swm11/research/papers/isca2014.pdf https://www.cl.cam.ac.uk/~swm11/research/papers/isca2014.pdf CHERI processor adds capability-security to mix on MIPS processor. FreeBSD already ported. Uses 32% extra logic elements with 8% clock speed reduction and overhead similar to above designs. Recent papers added more protection, reduced some overheads, and so on. Strange enough, I used this one because the others have too much data to sift through quickly. Sandia Secure Processor (SSP): http://faculty.ist.unomaha.edu/winter/ShiftLab/Monarch_web/LM_Documentation/2004/SLIDES-the_ssp_an_example_of_high-assurance_system_engineering.pdf http://faculty.ist.unomaha.edu/winter/ShiftLab/Monarch_web/L... For microcontrollers, Forth is a bad idea because it's typeless and dynamic. It's best to have strong typing plus static behavior so our current tooling can know exactly how it will behave. That naturally leads to things like Java. The system at jopdesign.com is just over 2,000 slices in FPGA. Idk if it has built-in safety checks or uses compiler's. However, this high-assurance CPU manages first-pass for 40,000 gates with full checks and verification. Plus can leverage Java tooling for automated unit tests, static analysis, dynamic analysis, design by contract... you name it. They even have a tool for converting regular Java to their tool. Examples of ultra, lightweight schemes for MCU's: http://www.icri-sc.org/fileadmin/user_upload/Group_TRUST/PubsPDF/trustlite.pdf http://www.icri-sc.org/fileadmin/user_upload/Group_TRUST/Pub... Trustlite does isolation, attestation, and exception handling. It uses about 300 extra registers and 440 extra LUTS on a FPGA plus around 200 each per protected module. Tiny. https://www.cs.utah.edu/~regehr/papers/plos06a.pdf https://www.cs.utah.edu/~regehr/papers/plos06a.pdf Works on 8-bit with TinyOS demonstration. Software method. Something like this could be hardware supported. http://www.ece.umd.edu/~barua/simpson-CASES-2005.pdf http://www.ece.umd.edu/~barua/simpson-CASES-2005.pdf One for microcontrollers that averages 0.72% speed overhead (approx 10% max) and code size of 3.6%. Could be aided with HW. http://read.seas.harvard.edu/~kohler/pubs/kumar07system.pdf http://read.seas.harvard.edu/~kohler/pubs/kumar07system.pdf Another proven out on an ATmega with single-digit runtime effects and only a few thousands slices in MCU that's over 20,000 at start. Note: You don't see much on 8-bit or 16-bit HW on my list as they're so constrained that a MPU or stack-overflow check is about all you can do. It's why I recommend against them most of the time. The likes of Infineon and Gemalto are stretching their capabilities far, though, in smartcard IC's with onboard crypto, MPU's, built-in checks, and usually a verified, safe OS or platform like MULTOS or JavaCard. One really just needs to use best tools and care they can on such platforms, though. 32-bit in 20,000-30,000 gate range is the lower bound so far on believable tech for assisted safety or security. I mean, you can use 8- or 16-bit with similar tech but your overall datapath and gates will be similar to 32-bit ones. Just get different tradeoffs in speed, code-size, addressing, and so on.
- Avshalom 10y ago
  I'm certainly a fan of languages built for robustness and safety but this a CPU for (essentially) pedagogy purposes. A b5000-esque cpu would be much less straight forward (actually I don't even know how many of the b5000's features were in the cpu vs being in some other support chip)
  - nickpsecurity 10y ago
    "but this a CPU for (essentially) pedagogy purposes" No doubt. Many people might try to build on it for other reasons. Hence, my warning. "A b5000-esque cpu would be much less straight forward" Try crash-safe.org's main presentation on SAFE architecture. Narrow your focus to that one section on atomic groups. Mentally combine that with Burrough's most primitive checks. I'm talking code vs data check, pointer bounds check, pointer write-check to prevent modification, optionally stack overflow, and so on. Each one is a few lines of C code if you draw it out. I don't design HW but I've read enough of these to know there's close to zero performance and gate overhead in such simple checks. They typically run in parallel with CPU pipeline where it goes ahead with execution but doesn't actually write results unless gets a "1" (check succeeds) from parallel checkers. Simple, simple. Academics with almost no team or budget typically start with highly-configurable, Leon3 CPU. They add the tags or checks into a few components. Synthesize for FPGA. Done. Then, compiler and/or OS modifications to make use of it. I've seen it done for RTEMS and Linux with small teams and mods. Cambridge's CHERI, with larger team, did whole capability-architecture that's C compatible and runs FreeBSD port. Changes that big have quite the performance implications, though, which is why I focus on primitive checks for interim or hobbyist use. ;)
    - pjmlp 10y ago
      Looking forward to the day that all x86 code is MPX enabled. :)
      - nickpsecurity 10y ago
        It's a nice start and improvement. I'd like to see more peer review on stuff like Hardbound and Code-pointer Integrity. I think stuff like Softbound or Code-pointer integrity could be merged with MPX to reduce its cost. Or just amplify its capability. Would be worthwhile research for some undergrads seeing as MPX is deployed already.
- dewster 10y ago
  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 thrash. ANY stack manipulation must be seen as fundamentally inefficient, and they make Forth a naturally obfuscated write-only language IMO. I understand complexity push-back, particularly in the processor / SW worlds where so much of it seems actually harmful, but the cult they've formed around Chuck Moore is kinda weird and it makes it hard for noobs to get a balanced picture of computing.
  - 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.
- astrobe_ 10y ago
  > nothing justified by scientific or engineering argument. All surpassed by other work in cost-benefit analysis. One wonders why a company like GreenArray is trying to sell his designs. Must be a band of lunatics. A PhD paper from 2007 is certainly more serious than a company spending millions to get Moore's ideas on wafers.
  - nickpsecurity 10y ago
    Because some business executive or venture capitalist thinks they might get rich off it. Like the other 90+% of businesses they invest in that fail. Obviously... Meanwhile, the products he hopes to displace are still selling well without the built-in drawbacks of his.

>Running Forth is not so good. Why not?

by Volt 10y ago

>Running Forth is not so good. Why not?

It's an untyped, stack language. A strongly-typed language gives you more readability, safety/security and optimization abilities. Dynamic, but still safe, typing plus hygenic macros can be used to make that even higher-level and more productive. Plus, there's tons of tooling, talent, and libraries for a few, good ones. Forth is behind the curve in almost every respect. Forth is the way it is mainly because Chuck Moore wants it that way. It's his preference. Tiny cores, typeless, hand-optimized to near metal, primitive VLSI tooling, 18-bit CPU's... nothing justified by scientific or engineering argument. All surpassed by other work in cost-benefit analysis. Nice write-up here by one person that delved deep into it to see good and bad of it: http://yosefk.com/blog/my-history-with-forth-stack-machines.html http://yosefk.com/blog/my-history-with-forth-stack-machines....

avmich 10y ago
An assembler is usually C-typed and non-stack. If you want extra features, you're welcome to write a translator for higher level language - you just have an opportunity to use Forth as your target, not typical assembler. At the same time you can have top performance with a concatenative, dense language. It doesn't mean Forth is most convenient to write for any kind of problems, or that translator can easier optimize for Forth target... yet this at least is an opportunity to have a nicer language on the bare-bones level. Do you think it's a good enough thing?
- nickpsecurity 10y ago
  "If you want extra features, you're welcome to write a translator for higher level language - you just have an opportunity to use Forth as your target, not typical assembler. " One paper in my collection does that for IIRC Haskell to Forth by implementing a G-machine interpreter or compiler for a Forth CPU. It certainly can be done. Question is whether it's ideal vs a non-Forth CPU. "At the same time you can have top performance with a concatenative, dense language." I can do that with a Leon3 SPARC GPL'd with LISP or Forth extensions. It will be faster. Likewise, one can modify a simple, microcoded CPU to run Forth, Oberon, LISP, or whatever. Difference is that we're not tied to Forth's style in the process. "yet this at least is an opportunity to have a nicer language on the bare-bones level. Do you think it's a good enough thing?" If you have nothing else. Otherwise, no. I think, as I commented to avshalom, we can modify a flexible, simple RISC to have basic checks built-in. With microcode, you can raise abstraction to primitives of your choosing from expressions to stacks to heaps to pointer manipulation. Whatever you want.These can be composed of primitive instructions with checks enabled or disabled. You can then code in those with safe, highly-optimized primitives underneath making it fly in performance. Further, as Intel does, you can always change underlying architecture to speed-up your model as you're leveraging microcode or ISA level. Last point, as my conversation with Alan Kay shows, is that modifying hardware to support OOP and late binding allows you productivity and code reduction of Smalltalk-style languages with still efficient, safe execution.
  - avmich 10y ago
    This a little bit seems like just moving the question on another level - from software to hardware. How much it would cost to you in terms of hardware - and maybe speed? - to have extensions which will have those nice features, especially if they are flexible, i.e. switchable? Would you need less gates than a Forth system?
    - nickpsecurity 10y ago
      "Would you need less gates than a Forth system?" That's not a fair question given Forth doesn't do crap compared to alternatives I'm pushing. More like "Does it use a reasonable number of gates for a commercial processor? For a MCU, do any schemes use a tiny number of gates to provide some protections vs existing MCU's?" Answer to these are yes. As several people want links, here's a list of approaches ranging from safety to security, full to partial, MPU to MCU. Two of the best for full safety are Hardbound and Watchdog, both from same group: https://www.cis.upenn.edu/acg/papers/asplos08_hardbound.pdf https://www.cis.upenn.edu/acg/papers/asplos08_hardbound.pdf https://www.cs.rutgers.edu/~santosh.nagarakatte/papers/isca12_watchdog.pdf https://www.cs.rutgers.edu/~santosh.nagarakatte/papers/isca1... One provides full spatial safety with other providing full memory safety with both having C compatibility. There are significant extra chip resources. Not a problem in a microprocessor, though, given the frivilous stuff takes up more space than this. The performance overhead is usually single-digit (under 5%) with it maxing out on 20% on Hardbound and 25% on Watchdog. For Watchdog, that's trading occasional 25% hit or buying a bit of extra CPU to get fully-compatible and safe C software. Great trade. HW experts could probably optimize it even further. CHERI processor: https://www.cl.cam.ac.uk/~swm11/research/papers/isca2014.pdf https://www.cl.cam.ac.uk/~swm11/research/papers/isca2014.pdf CHERI processor adds capability-security to mix on MIPS processor. FreeBSD already ported. Uses 32% extra logic elements with 8% clock speed reduction and overhead similar to above designs. Recent papers added more protection, reduced some overheads, and so on. Strange enough, I used this one because the others have too much data to sift through quickly. Sandia Secure Processor (SSP): http://faculty.ist.unomaha.edu/winter/ShiftLab/Monarch_web/LM_Documentation/2004/SLIDES-the_ssp_an_example_of_high-assurance_system_engineering.pdf http://faculty.ist.unomaha.edu/winter/ShiftLab/Monarch_web/L... For microcontrollers, Forth is a bad idea because it's typeless and dynamic. It's best to have strong typing plus static behavior so our current tooling can know exactly how it will behave. That naturally leads to things like Java. The system at jopdesign.com is just over 2,000 slices in FPGA. Idk if it has built-in safety checks or uses compiler's. However, this high-assurance CPU manages first-pass for 40,000 gates with full checks and verification. Plus can leverage Java tooling for automated unit tests, static analysis, dynamic analysis, design by contract... you name it. They even have a tool for converting regular Java to their tool. Examples of ultra, lightweight schemes for MCU's: http://www.icri-sc.org/fileadmin/user_upload/Group_TRUST/PubsPDF/trustlite.pdf http://www.icri-sc.org/fileadmin/user_upload/Group_TRUST/Pub... Trustlite does isolation, attestation, and exception handling. It uses about 300 extra registers and 440 extra LUTS on a FPGA plus around 200 each per protected module. Tiny. https://www.cs.utah.edu/~regehr/papers/plos06a.pdf https://www.cs.utah.edu/~regehr/papers/plos06a.pdf Works on 8-bit with TinyOS demonstration. Software method. Something like this could be hardware supported. http://www.ece.umd.edu/~barua/simpson-CASES-2005.pdf http://www.ece.umd.edu/~barua/simpson-CASES-2005.pdf One for microcontrollers that averages 0.72% speed overhead (approx 10% max) and code size of 3.6%. Could be aided with HW. http://read.seas.harvard.edu/~kohler/pubs/kumar07system.pdf http://read.seas.harvard.edu/~kohler/pubs/kumar07system.pdf Another proven out on an ATmega with single-digit runtime effects and only a few thousands slices in MCU that's over 20,000 at start. Note: You don't see much on 8-bit or 16-bit HW on my list as they're so constrained that a MPU or stack-overflow check is about all you can do. It's why I recommend against them most of the time. The likes of Infineon and Gemalto are stretching their capabilities far, though, in smartcard IC's with onboard crypto, MPU's, built-in checks, and usually a verified, safe OS or platform like MULTOS or JavaCard. One really just needs to use best tools and care they can on such platforms, though. 32-bit in 20,000-30,000 gate range is the lower bound so far on believable tech for assisted safety or security. I mean, you can use 8- or 16-bit with similar tech but your overall datapath and gates will be similar to 32-bit ones. Just get different tradeoffs in speed, code-size, addressing, and so on.
Avshalom 10y ago
I'm certainly a fan of languages built for robustness and safety but this a CPU for (essentially) pedagogy purposes. A b5000-esque cpu would be much less straight forward (actually I don't even know how many of the b5000's features were in the cpu vs being in some other support chip)
- nickpsecurity 10y ago
  "but this a CPU for (essentially) pedagogy purposes" No doubt. Many people might try to build on it for other reasons. Hence, my warning. "A b5000-esque cpu would be much less straight forward" Try crash-safe.org's main presentation on SAFE architecture. Narrow your focus to that one section on atomic groups. Mentally combine that with Burrough's most primitive checks. I'm talking code vs data check, pointer bounds check, pointer write-check to prevent modification, optionally stack overflow, and so on. Each one is a few lines of C code if you draw it out. I don't design HW but I've read enough of these to know there's close to zero performance and gate overhead in such simple checks. They typically run in parallel with CPU pipeline where it goes ahead with execution but doesn't actually write results unless gets a "1" (check succeeds) from parallel checkers. Simple, simple. Academics with almost no team or budget typically start with highly-configurable, Leon3 CPU. They add the tags or checks into a few components. Synthesize for FPGA. Done. Then, compiler and/or OS modifications to make use of it. I've seen it done for RTEMS and Linux with small teams and mods. Cambridge's CHERI, with larger team, did whole capability-architecture that's C compatible and runs FreeBSD port. Changes that big have quite the performance implications, though, which is why I focus on primitive checks for interim or hobbyist use. ;)
  - pjmlp 10y ago
    Looking forward to the day that all x86 code is MPX enabled. :)
    - nickpsecurity 10y ago
      It's a nice start and improvement. I'd like to see more peer review on stuff like Hardbound and Code-pointer Integrity. I think stuff like Softbound or Code-pointer integrity could be merged with MPX to reduce its cost. Or just amplify its capability. Would be worthwhile research for some undergrads seeing as MPX is deployed already.
dewster 10y ago
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 thrash. ANY stack manipulation must be seen as fundamentally inefficient, and they make Forth a naturally obfuscated write-only language IMO. I understand complexity push-back, particularly in the processor / SW worlds where so much of it seems actually harmful, but the cult they've formed around Chuck Moore is kinda weird and it makes it hard for noobs to get a balanced picture of computing.
- 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.
astrobe_ 10y ago
> nothing justified by scientific or engineering argument. All surpassed by other work in cost-benefit analysis. One wonders why a company like GreenArray is trying to sell his designs. Must be a band of lunatics. A PhD paper from 2007 is certainly more serious than a company spending millions to get Moore's ideas on wafers.
- nickpsecurity 10y ago
  Because some business executive or venture capitalist thinks they might get rich off it. Like the other 90+% of businesses they invest in that fail. Obviously... Meanwhile, the products he hopes to displace are still selling well without the built-in drawbacks of his.