C is now a major impediment to improvement just like the 80x86 ISA.
I'm not clear what you mean by that. Can you give examples?
Many other people have done that far better than I could. I liked C in the early 80s, but by the time the mid 90s had arrived it was clear that C and C++ were problems rather than answers.
People have loved writing "C is bad" articles" since C first appeared, but most don't really hold water.
"90% of everything is crap" - but the 10% is worth understanding.
I well remember the endless (over a year) debate about whether it should be possible/impossible to "cast away constness". There are good reasons for both, but they are obviously mutually incompatible.
Tinkering with constness is more about the use of ROM than the CPU architecture.
Absolutely not. Constness is about correct operation in the presence of large programs and/or optimisation. ROMs are a side issue.
Without constness, many optimisations aren't possible because the compiler cannot determine the absence of aliasing. Even then, having the wrong compilation flags introduces all sorts of intermittent bugs.
With constness, how can a debugger operate?
There's the C++ FQA, of course.
C++ doesn't count. Its so complex and quirky, it certainly does tie people's hands.
No argument there. If C++ is is the answer, you asked the wrong question.
Amusingly, until recently it wasn't even possible to write an OS in C. I know it is ridiculous, but as late a 2004 Hans Boehm had to point that out to many people in "Threads Cannot be Implemented as a Library" http://www.hpl.hp.com/techreports/2004/HPL-2004-209.html
I think Hans Boehm is also someone who wrote an excellent article about how poorly understood the memory models of various x86 cores was (even by their own developers), and how this shot holes in most threading systems. I don't see how this makes running C code an impediment to progress.
Strawman question!
Until
very recently, C didn't even have a memory model. How successful its current memory model will be remains to be seen. It is a
very difficult area; even Java had to modify the memory model in the light of experience.
There have been only two interestingly innovative architectures recently: the Mill and xCORE.
The Mill is an interesting CPU architecture. The interesting thing about xCORE is the way the CPUs cooperate, rather than anything about the architecture of the CPUs.
A key point is multiprocessor/multiprocessing operation - but many processors have that. It is easy to make very parallel processors, but difficult to program them to make use of the parallelism.
The unique point is the tight integration of hardware capabilities with software capabilities such that together they are better than the sum.
Sure, but you could do that with x86 or ARM cores. There is nothing particular about the xCORE cores that makes them special. I've encountered many people trying to tie their favourite ISA to an interesting scheme, that had almost nothing to do with the ISA.
Correct. There was even an XMOS processor that included an ARM core!
Nonetheless, the
combination of i/o ports, comms fabric, multiprocessor cores, language and IDE tools is unparalleled (ho ho ho). It is the
unified vision plus
implementation of the vision that is unique.
I also hope it is not the last word - we need as much help as we can get with highly parallel systems. There are encouraging signs: other modern languages are incorporating some of the CSP and xC concepts more or less directly. Such languages are learning from the past, not being constrained by it.