3 ms·

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 opp

by 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.

by avmich 10y ago

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.