4 ms·

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 mos

by 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.
      - dewster 10y ago
        Yes, but even with the most meticulously hand coded assembly, a canonical stack machine will starve the ALU ~1/3 of the time. Better to code however is the most efficient at the top level, implement the HW however is the most efficient at the bottom level, and automate the middle ground.
- frozenport 10y ago
  It is possible to design a Java specific CPU, see this guy's thesis[1]: [1] http://www.jopdesign.com/thesis/thesis.pdf http://www.jopdesign.com/thesis/thesis.pdf

by hacknat 10y ago

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.
    - dewster 10y ago
      Yes, but even with the most meticulously hand coded assembly, a canonical stack machine will starve the ALU ~1/3 of the time. Better to code however is the most efficient at the top level, implement the HW however is the most efficient at the bottom level, and automate the middle ground.
frozenport 10y ago
It is possible to design a Java specific CPU, see this guy's thesis[1]: [1] http://www.jopdesign.com/thesis/thesis.pdf http://www.jopdesign.com/thesis/thesis.pdf