4 ms·
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
by 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 agoYeah, 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 agoYes, 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.