[math-fun] intel and bad instruction sets history/philosophy
Re swap, there should be a <--> b built into language. It's a matter of syntax. Also it should be a hardware instruction too. Jorg Arndt by saying templates can fix this, is missing my point. My point is: syntax matters. SWAP(a,b) is simply poor syntax for such a common operation. Common stuff, should be short. Principle of the Huffman code. This well known principle was one that ADA, otherwise quite a good language, ignored tremendously. And that single decision alone by the ADA designers, goes a long way toward explaining why ADA achieved far less success than it should have. (And they can say all they want about how syntax does not matter, but their massive failure is just staring us all in the face.) Another huge error made by ADA was making garbage collection optional. As a result, few put it into their compilers. As a result, Joe Programmer could not use garbage collection unless his program was nonportable. As a result, the whole idea completely kamikazed. Re C deficiencies, another huge one is no array bounds checking. It should be provided as part of the language -- for example, A[n] would be bounds checked by default, but one could turn it off by, say A[[n]] or explicitly declaring A to be unchecked int A[77]; or some such. Or even a compiler overrule flag to turn off/on all boundschecking. A tremendous number of bugs have been caused by this one incredibly simple and easy to fix C language design error, plus this is probably the top reason underlying security flaws in everything today. And re add-with-carry, not allowing multiprecision arithmetic, as a result you cannot write good cryptography in C alone. You need assembler. Virtually everything Joe User does today, involves crypto. So it's insane. And yes, add-with-carry does require some thought to see how to put it into an HLL, but the best choice was NOT "completely surrendering."
The proper approach is (of course!) to write programs that write programs.
--The proper approach is to make the language have enough power that I do not have to in many common cases. I'm not opposed to your idea per se.
The designers of C didn't think of every possible use 30 years in the future. They should really be ashamed.
--I think you were being sarcastic, but I completely agree with this. The bottom line is: they designed something without the future in mind and now we are paying for it. Huge. Security flaws that would not be there if C had included array bound check, are costing literally billions. This would have far far overpaid for the whole C development effort. And if C had included various machine language stuff like in MMIX, then people would have used it, which means CPU designers would have put it in hardware. Instead since it was "not used" CPU designers were not going to supply it. Which meant it was silly to put in an HLL. Vicious circle.
And, by the way, there is a threshold in programming language criticism where "Write your own or cork it!" applies.
--ah. The trouble is, writing your own is (a) hard, and (b) virtually certain to be a wasted effort. Which is exactly the problem. Just look at all the wasted language ideas that are out there in languages essentially nobody uses. -- Warren D. Smith http://RangeVoting.org <-- add your endorsement (by clicking "endorse" as 1st step)
:) I still prefer my own "proper approach" - write everything at the lowest level possible, optimising everything whether strictly necessary or not. The higher level you code at the greater chance of missed bugs and security holes, Use C or a similar level language but only if you know that the CPU you're programming for is likely to get more highly optimised run-time code that way rather than hand-coded assembler. e.g. on Intel/AMD use C or similar but on ARM stick to assembler - IMO in terms of optimisation the C/C++/Objective C/Java compilers still don't cut it on ARM. Personally the only coding I'm really interested in now is shader fragments and for those interested who have a decent shader video card check http://www.shadertoy.com/ (use Chrome, Safari or IE not Firefox). I'm stil hoping for programmable CPUs i.e. such that the actual instruction set can be defined or even redefined at run-time. On 20 Apr 2014, at 15:25, Warren D Smith wrote:
Re swap, there should be a <--> b built into language.
It's a matter of syntax. Also it should be a hardware instruction too. Jorg Arndt by saying templates can fix this, is missing my point. My point is: syntax matters. SWAP(a,b) is simply poor syntax for such a common operation. Common stuff, should be short. Principle of the Huffman code.
This well known principle was one that ADA, otherwise quite a good language, ignored tremendously. And that single decision alone by the ADA designers, goes a long way toward explaining why ADA achieved far less success than it should have. (And they can say all they want about how syntax does not matter, but their massive failure is just staring us all in the face.)
Another huge error made by ADA was making garbage collection optional. As a result, few put it into their compilers. As a result, Joe Programmer could not use garbage collection unless his program was nonportable. As a result, the whole idea completely kamikazed.
Re C deficiencies, another huge one is no array bounds checking. It should be provided as part of the language -- for example, A[n] would be bounds checked by default, but one could turn it off by, say A[[n]] or explicitly declaring A to be unchecked int A[77]; or some such. Or even a compiler overrule flag to turn off/on all boundschecking.
A tremendous number of bugs have been caused by this one incredibly simple and easy to fix C language design error, plus this is probably the top reason underlying security flaws in everything today.
And re add-with-carry, not allowing multiprecision arithmetic, as a result you cannot write good cryptography in C alone. You need assembler. Virtually everything Joe User does today, involves crypto. So it's insane. And yes, add-with-carry does require some thought to see how to put it into an HLL, but the best choice was NOT "completely surrendering."
The proper approach is (of course!) to write programs that write programs.
--The proper approach is to make the language have enough power that I do not have to in many common cases. I'm not opposed to your idea per se.
The designers of C didn't think of every possible use 30 years in the future. They should really be ashamed.
--I think you were being sarcastic, but I completely agree with this. The bottom line is: they designed something without the future in mind and now we are paying for it. Huge. Security flaws that would not be there if C had included array bound check, are costing literally billions. This would have far far overpaid for the whole C development effort.
And if C had included various machine language stuff like in MMIX, then people would have used it, which means CPU designers would have put it in hardware. Instead since it was "not used" CPU designers were not going to supply it. Which meant it was silly to put in an HLL. Vicious circle.
And, by the way, there is a threshold in programming language criticism where "Write your own or cork it!" applies.
--ah. The trouble is, writing your own is (a) hard, and (b) virtually certain to be a wasted effort. Which is exactly the problem. Just look at all the wasted language ideas that are out there in languages essentially nobody uses.
-- Warren D. Smith http://RangeVoting.org <-- add your endorsement (by clicking "endorse" as 1st step)
_______________________________________________ math-fun mailing list math-fun@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/math-fun
The meaning and purpose of life is to give life purpose and meaning. The instigation of violence indicates a lack of spirituality.
* Warren D Smith <warren.wds@gmail.com> [Apr 20. 2014 19:29]:
Re swap, there should be a <--> b built into language.
An operator "<-->", _seriously_?
It's a matter of syntax. Also it should be a hardware instruction too. Jorg Arndt by saying templates can fix this, is missing my point. My point is: syntax matters. SWAP(a,b) is simply poor syntax for such a common operation. Common stuff, should be short. Principle of the Huffman code.
I can certainly live with swap(a,b). Note C is not a high level language.
[...]
Re C deficiencies, another huge one is no array bounds checking. It should be provided as part of the language -- for example, A[n] would be bounds checked by default, but one could turn it off by, say A[[n]] or explicitly declaring A to be unchecked int A[77]; or some such. Or even a compiler overrule flag to turn off/on all boundschecking.
You keep suggesting things that would make life hellishly complicated. Use valgrind. Be happy thereafter. (more below)
A tremendous number of bugs have been caused by this one incredibly simple and easy to fix C language design error, plus this is probably the top reason underlying security flaws in everything today.
Want Java? Performance eek bytes bottom. (again, more below)
And re add-with-carry, not allowing multiprecision arithmetic, as a result you cannot write good cryptography in C alone. You need assembler. Virtually everything Joe User does today, involves crypto. So it's insane. And yes, add-with-carry does require some thought to see how to put it into an HLL, but the best choice was NOT "completely surrendering."
How clear was that (importance of cryptography) at the time C was created? For very low level things you tend to need assembler in every language at some point. Hardly any language is as good as C at pushing that point away from you! I have used about 20 machine instructions in about 15 _tiny_ assembler fragments in the last 20 years.
The proper approach is (of course!) to write programs that write programs.
--The proper approach is to make the language have enough power that I do not have to in many common cases. I'm not opposed to your idea per se.
The designers of C didn't think of every possible use 30 years in the future. They should really be ashamed.
--I think you were being sarcastic, but I completely agree with this. The bottom line is: they designed something without the future in mind and now we are paying for it. Huge. Security flaws that would not be there if C had included array bound check, are costing literally billions. This would have far far overpaid for the whole C development effort.
It is (almost) trivial to create array with bounds checks. But wait! Just use what is already there: std::vector. V.at(i) <--= bounds check V.[i] <--= no bounds check And that is _precisely_ what you asked for.
And if C had included various machine language stuff like in MMIX, then people would have used it, which means CPU designers would have put it in hardware.
How can a language reasonably include "machine language stuff"??? A (the?) point of C was to get CPU _independent_!
Instead since it was "not used" CPU designers were not going to supply it. Which meant it was silly to put in an HLL. Vicious circle.
And, by the way, there is a threshold in programming language criticism where "Write your own or cork it!" applies.
--ah. The trouble is, writing your own is (a) hard, and (b) virtually certain to be a wasted effort. Which is exactly the problem. Just look at all the wasted language ideas that are out there in languages essentially nobody uses.
I know 8^) To me it sounds that would you read up on C++, you'd find most of your demands are solved for the overwhelming majority of use case.
[...]
Best, jj
On 20 Apr 2014, at 19:05, Joerg Arndt wrote:
* Warren D Smith <warren.wds@gmail.com> [Apr 20. 2014 19:29]:
Re swap, there should be a <--> b built into language.
An operator "<-->", _seriously_?
It's a matter of syntax. Also it should be a hardware instruction too. Jorg Arndt by saying templates can fix this, is missing my point. My point is: syntax matters. SWAP(a,b) is simply poor syntax for such a common operation. Common stuff, should be short. Principle of the Huffman code.
I can certainly live with swap(a,b). Note C is not a high level language.
?? Surely any language where the majority of instructions cover more than one machine code instruction is "high" level ;) Or to put it another way - any language that can potentially compile one instruction into *different* but equivalently performing machine code is "high" level ;)
* David Makin <makinmagic@tiscali.co.uk> [Apr 21. 2014 14:57]:
On 20 Apr 2014, at 19:05, Joerg Arndt wrote: [...]
I can certainly live with swap(a,b). Note C is not a high level language.
?? Surely any language where the majority of instructions cover more than one machine code instruction is "high" level ;) Or to put it another way - any language that can potentially compile one instruction into *different* but equivalently performing machine code is "high" level ;)
OK, to put into perspective: http://en.wikipedia.org/wiki/High-level_programming_language I'd rather consider, for example, Python, Ruby, and Languages of computer algebra systems as examples of "high level languages". C rather as "low level", as there is not a lot of space between C and machine code, indeed I can often predict the machine code for small programs (apart from the compiler's neat tricks such as unusual instructions for specific CPUs). C++: "mid level"? In it's raw form, maybe, but including the STL, certainly, as it can be used in a quite high-level-ish manner. No quality ranking implied, I use what is good for the problem at hand. Best regards, jj P.S.: The German Wiki page http://de.wikipedia.org/wiki/Höhere_Programmiersprache essentially says "it's high level if it is not assembler".
_______________________________________________ math-fun mailing list math-fun@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/math-fun
The definition of a 'high level language' seems to be subject to some amount of 'mission creep'; I would argue that the phrase 'high level' would indicate that the language at least abstracts away the details of the underlying hardware so that such languages are _portable_ to another ISA (instruction set architecture). Nowadays, I'd also throw in ideas like type safety, memory safety and garbage collection to make a language 'high level'. Note that Postscript (after Adobe finally put in a garbage collector) fits this definition. If you care _only_ about "control structures" like if-then-else, but not about the actual machine instructions, you might enjoy these papers about the "Comfy" language, which is illustrated for the 6502 (the original Apple II cpu), but has also been used as an 'assembler' for other architectures. *** Warren, you should check these out *** The Comfy language: http://home.pipeline.com/~hbaker1/sigplannotices/sigcol03.pdf Size: 62 KB (62,584 bytes) The Comfy 6502 compiler in Emacs Lisp: http://home.pipeline.com/~hbaker1/sigplannotices/sigcol04.pdf Size: 61 KB (61,617 bytes) At 09:55 AM 4/21/2014, Joerg Arndt wrote:
* David Makin <makinmagic@tiscali.co.uk> [Apr 21. 2014 14:57]:
On 20 Apr 2014, at 19:05, Joerg Arndt wrote: [...]
I can certainly live with swap(a,b). Note C is not a high level language.
?? Surely any language where the majority of instructions cover more than one machine code instruction is "high" level ;) Or to put it another way - any language that can potentially compile one instruction into *different* but equivalently performing machine code is "high" level ;)
OK, to put into perspective: http://en.wikipedia.org/wiki/High-level_programming_language
I'd rather consider, for example, Python, Ruby, and Languages of computer algebra systems as examples of "high level languages".
C rather as "low level", as there is not a lot of space between C and machine code, indeed I can often predict the machine code for small programs (apart from the compiler's neat tricks such as unusual instructions for specific CPUs).
C++: "mid level"? In it's raw form, maybe, but including the STL, certainly, as it can be used in a quite high-level-ish manner.
No quality ranking implied, I use what is good for the problem at hand.
Best regards, jj
P.S.: The German Wiki page http://de.wikipedia.org/wiki/Höhere_Programmiersprache essentially says "it's high level if it is not assembler".
participants (4)
-
David Makin -
Henry Baker -
Joerg Arndt -
Warren D Smith