7 ms·

The J1 Forth CPU (2010)

64 points by panic 10y ago

nickpsecurity 10y ago
A tiny, open CPU is good. Running Forth is not so good. People should also look at this one: http://www.jopdesign.com http://www.jopdesign.com Their Java processor outperforms most of the others with small amount of space. It's open. Doesn't necessarily have to run Java as Oberon or something could probably be ported. The papers section is full of good stuff.
- Volt 10y ago
  >Running Forth is not so good. Why not?
  - 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.
dewster 10y ago
Or try my Hive soft processor core: http://opencores.org/project,hive http://opencores.org/project,hive I need to update the paper and code, the core is at v9.03 and the simulator can now parse assembly code as input. IMO canonical stack processors aren't a good substitute for register-based processors. Hive is a stack / register hybrid that makes the 2 operand architecture more efficient. And I don't know why barrel processors aren't taking over the world - they make too much sense I suppose.
- david-given 10y ago
  About a year ago we had this thread: https://news.ycombinator.com/item?id=9920760 https://news.ycombinator.com/item?id=9920760 It's a thesis describing a C compiler for stack machines. (The link in the article is dead now. See https://www-users.cs.york.ac.uk/chrisb/main-pages/publications/ShannonThesis2006.pdf.1 https://www-users.cs.york.ac.uk/chrisb/main-pages/publicatio...) It achieves comparable code density with gcc's x86 (albeit for a fictional architecture). The really interesting bit is Appendix E, which proposes an architecture for a fast stack machine. It uses a fairly traditional 16-bit instruction encoding, except instead of registers each 4-bit operand slot contains an encoded stack manipulation --- a rot or a pick. This should give even better code density while still being easy to implement. Unfortunately I've never tracked down a copy of his compiler...
  - throwaway000002 10y ago
    Thanks david for providing that reference. I missed the discussion the first time. Perhaps you, or someone here, would know: has anyone asked and tried to analytically answer what primitive operations an ALU ought to have? I mean, everything could be coded as a look-up-table, but given code "on average", what should be available in hardware. It's a strange question that requires you pose it properly to even begin to answer it. For example, in the kind of stuff I do, popcnt and other "set-like" bit operations, i.e. most-significant set bit, are important enough that I just wish they were built in. Mine you, I'm doing high-performance data processing, so perhaps it's not part of the scope of "average" code, but I disagree.
hacknat 10y ago
Not to be "that guy", but can someone explain to me what about this architecture is Forth specific? I would have thought that as a stack based language that most architectures would align pretty closely with its primitive commands/functions (i.e. Push-Pop-Jmp)
- dewster 10y ago
  People who design stack processors like to say they're Forth or Java machines. IMO it's more buzz-word than anything else. I think we know now that tailoring a processor to a particular language isn't particularly efficient (though the opposite i.e. assembly is).
  - pjmlp 10y ago
    Current processors are tailored to C line of languages as they kind of follow up on the PDP-11 architecture. And yet, given the way C exploits have plagued the industry, Intel, ARM, CHERI are actually adding tagged instructions that allow C compilers to generate code that validates array and pointer accesses at hardware level. Just like the language specific processors that you state as not being efficient.
    - dewster 10y ago
      It's hard for me to see that CPUs historically and substantially pander specifically to C. IMO adding hardware crap to fix software crap should be strenuously resisted. Early on there were efforts to build custom Lisp machines, etc. which were abandoned when CPUs became good enough and general purpose enough. Using a stack processor as a stack language target seems natural until you see all the inefficient stack gymnastics that go on at the lowest level.
      - pjmlp 10y ago
        Yeah, but unfortunately that software crap is going to stay with us for a long time. Even I that usually bash C here, do use it when customers or a specific project requires it. I just try to follow all best practices to make it as safe as I can, ignoring third party code. However I can convinced that Lisp Machines, Xerox PARC and Burroughs micro-architectures, Rational Ada Machines, i432, could have been much better. Many times technology solutions fail not because they aren't good, rather the people aren't willing to invest the time they require to become good enough. For example JavaScript JITs, if it wasn't for the research money that Google and other vendors are willing to invest, no one would believe they would achieve the execution speed they have nowadays. I also remember when Z80 coders could easily outperform C, Pascal, Basic and Modula compilers for 8 bit micros.
Animats 10y ago
Forth machines have been around since Moore designed one in the mid-1980s.[1] He used to have a development system where the only input was three buttons, used in a chorded fashion, and the CPU was generating NTSC video in software. Now that's minimalism. In the first hardware implementation, integer divide had been botched, and gave wrong answers for odd-numbered divisors. There was an argument in the data sheet that most divisors are even, and a subroutine for correct divides when needed. [1] http://www.cpushack.com/2013/02/21/charles-moore-forth-stack-processors/ http://www.cpushack.com/2013/02/21/charles-moore-forth-stack...
algorithm314 10y ago
in action in ice40 fpga using icestorm http://www.excamera.com/sphinx/article-j1a-swapforth.html http://www.excamera.com/sphinx/article-j1a-swapforth.html
AstroJetson 10y ago
I have one of these on my Gameduino board. Since my early computing experience was on Burroughs stack machines I've always liked stack machines and Forth. I had Forth on my early 8080 systems. It didn't take long to collect a decent collection of words that made programming go pretty fast. The J1 was an interesting processor to work with. The speed was very impressive. They produced a pretty nice dev environment to process the code with the Arduino.

64 points by panic 10y ago

A tiny, open CPU is good. Running Forth is not so good. People should also look at this one: http://www.jopdesign.com http://www.jopdesign.com Their Java processor outperforms most of the others with small amount of space. It's open. Doesn't necessarily have to run Java as Oberon or something could probably be ported. The papers section is full of good stuff.

Volt 10y ago
>Running Forth is not so good. Why not?
- 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.

dewster 10y ago

Or try my Hive soft processor core: http://opencores.org/project,hive http://opencores.org/project,hive I need to update the paper and code, the core is at v9.03 and the simulator can now parse assembly code as input. IMO canonical stack processors aren't a good substitute for register-based processors. Hive is a stack / register hybrid that makes the 2 operand architecture more efficient. And I don't know why barrel processors aren't taking over the world - they make too much sense I suppose.

david-given 10y ago
About a year ago we had this thread: https://news.ycombinator.com/item?id=9920760 https://news.ycombinator.com/item?id=9920760 It's a thesis describing a C compiler for stack machines. (The link in the article is dead now. See https://www-users.cs.york.ac.uk/chrisb/main-pages/publications/ShannonThesis2006.pdf.1 https://www-users.cs.york.ac.uk/chrisb/main-pages/publicatio...) It achieves comparable code density with gcc's x86 (albeit for a fictional architecture). The really interesting bit is Appendix E, which proposes an architecture for a fast stack machine. It uses a fairly traditional 16-bit instruction encoding, except instead of registers each 4-bit operand slot contains an encoded stack manipulation --- a rot or a pick. This should give even better code density while still being easy to implement. Unfortunately I've never tracked down a copy of his compiler...
- throwaway000002 10y ago
  Thanks david for providing that reference. I missed the discussion the first time. Perhaps you, or someone here, would know: has anyone asked and tried to analytically answer what primitive operations an ALU ought to have? I mean, everything could be coded as a look-up-table, but given code "on average", what should be available in hardware. It's a strange question that requires you pose it properly to even begin to answer it. For example, in the kind of stuff I do, popcnt and other "set-like" bit operations, i.e. most-significant set bit, are important enough that I just wish they were built in. Mine you, I'm doing high-performance data processing, so perhaps it's not part of the scope of "average" code, but I disagree.

hacknat 10y ago

Not to be "that guy", but can someone explain to me what about this architecture is Forth specific? I would have thought that as a stack based language that most architectures would align pretty closely with its primitive commands/functions (i.e. Push-Pop-Jmp)

dewster 10y ago
People who design stack processors like to say they're Forth or Java machines. IMO it's more buzz-word than anything else. I think we know now that tailoring a processor to a particular language isn't particularly efficient (though the opposite i.e. assembly is).
- pjmlp 10y ago
  Current processors are tailored to C line of languages as they kind of follow up on the PDP-11 architecture. And yet, given the way C exploits have plagued the industry, Intel, ARM, CHERI are actually adding tagged instructions that allow C compilers to generate code that validates array and pointer accesses at hardware level. Just like the language specific processors that you state as not being efficient.
  - dewster 10y ago
    It's hard for me to see that CPUs historically and substantially pander specifically to C. IMO adding hardware crap to fix software crap should be strenuously resisted. Early on there were efforts to build custom Lisp machines, etc. which were abandoned when CPUs became good enough and general purpose enough. Using a stack processor as a stack language target seems natural until you see all the inefficient stack gymnastics that go on at the lowest level.
    - pjmlp 10y ago
      Yeah, but unfortunately that software crap is going to stay with us for a long time. Even I that usually bash C here, do use it when customers or a specific project requires it. I just try to follow all best practices to make it as safe as I can, ignoring third party code. However I can convinced that Lisp Machines, Xerox PARC and Burroughs micro-architectures, Rational Ada Machines, i432, could have been much better. Many times technology solutions fail not because they aren't good, rather the people aren't willing to invest the time they require to become good enough. For example JavaScript JITs, if it wasn't for the research money that Google and other vendors are willing to invest, no one would believe they would achieve the execution speed they have nowadays. I also remember when Z80 coders could easily outperform C, Pascal, Basic and Modula compilers for 8 bit micros.

Animats 10y ago

Forth machines have been around since Moore designed one in the mid-1980s.[1] He used to have a development system where the only input was three buttons, used in a chorded fashion, and the CPU was generating NTSC video in software. Now that's minimalism. In the first hardware implementation, integer divide had been botched, and gave wrong answers for odd-numbered divisors. There was an argument in the data sheet that most divisors are even, and a subroutine for correct divides when needed. [1] http://www.cpushack.com/2013/02/21/charles-moore-forth-stack-processors/ http://www.cpushack.com/2013/02/21/charles-moore-forth-stack...

algorithm314 10y ago

in action in ice40 fpga using icestorm http://www.excamera.com/sphinx/article-j1a-swapforth.html http://www.excamera.com/sphinx/article-j1a-swapforth.html

AstroJetson 10y ago

I have one of these on my Gameduino board. Since my early computing experience was on Burroughs stack machines I've always liked stack machines and Forth. I had Forth on my early 8080 systems. It didn't take long to collect a decent collection of words that made programming go pretty fast. The J1 was an interesting processor to work with. The speed was very impressive. They produced a pretty nice dev environment to process the code with the Arduino.