yup, the PowerPC has autoincremented index opcodes, but the ICE doesn't like this too much, for *a lot* of reasons, and, worse still, people can do a mess with the GreenHills C compiler.Why are you using C at all in those critical projects?
QuoteThere were some architectures where ++/-- were supported by specific inc/dec instructions.Umm. By the addressing modes available on nearly ALL instructions, on some CPUs.Notably the PDP/11, which supported pre-decrement and post-increment of a memory index register on nearly all of the instructions (and which had some influence on the design of C!).
And everything that copied or claimed to copy the PDP/11 instruction set; surviving is MSP430. ARM has this too, I guess (some versions of ARM, anyway.) (But not X86, MIPS, or RISC-V? (results of a quick check; I may not be up to date!))
QuoteThere were some architectures where ++/-- were supported by specific inc/dec instructions.Umm. By the addressing modes available on nearly ALL instructions, on some CPUs.Notably the PDP/11, which supported pre-decrement and post-increment of a memory index register on nearly all of the instructions (and which had some influence on the design of C!).
And everything that copied or claimed to copy the PDP/11 instruction set; surviving is MSP430. ARM has this too, I guess (some versions of ARM, anyway.) (But not X86, MIPS, or RISC-V? (results of a quick check; I may not be up to date!))
I think this turned out to be relatively cheap, hardware-wise. You needed something similar for the PC anyway, and for stack instructions if you have them...
QuoteThere were some architectures where ++/-- were supported by specific inc/dec instructions.Umm. By the addressing modes available on nearly ALL instructions, on some CPUs.Notably the PDP/11, which supported pre-decrement and post-increment of a memory index register on nearly all of the instructions (and which had some influence on the design of C!).
And everything that copied or claimed to copy the PDP/11 instruction set; surviving is MSP430. ARM has this too, I guess (some versions of ARM, anyway.) (But not X86, MIPS, or RISC-V? (results of a quick check; I may not be up to date!))
Yup. And has everyone forgotten about the 68k already?
I think many have just forgotten what it meant to code for < 1MIPS CISC CPUs with basic tools. We now take for granted what GCC produces for instance (and most modern compilers), but even with -O0, GCC produces code (for most targets) that is light-years more efficient than the compilers of the early days...
No Rust though?
in today's world we want everyone to pass the test without putting any work in.Yup. Our automatic and autonomous tests aim for this. But also consider that a part of our "test-cases" is recycled and used to help guys and robots in production to test what they build.
No Rust though?
It depends on LLVM, which has some problem with Catalyst at the moment
competent programmers should understand basic operators and precedence without needs packets of aspirin and a special senior classification [...] a tutor at a local technical college. They stopped teaching C because students were having too much difficulty with the language
But out of curiousity, what language would you use instead?
competent programmers should understand basic operators and precedence without needs packets of aspirin
It reminds me of a discussion I have with a tutor at a local technical college. They stopped teaching C because students were having too much difficulty with the language. They now teach using python and basic.
One of his KPI's is the number of students passing. We teach our children by lowering the standards until they too pass the test rather than having the hard conversation, therefore everyone is a winner and we have to put fences in to keep all but a select few out.
Professor Eric Laithwaite at Imperial College used to set exams where one question was easy and sufficient get you a pass mark, one was more challenging and couuld get you a good degree, and one could not be answered adequately in the time available. He expected his undergraduate engineers to be able to determine which questions to avoid. If they couldn't, they wouldn't make good engineers anyway.
Professor Eric Laithwaite at Imperial College used to set exams where one question was easy and sufficient get you a pass mark, one was more challenging and couuld get you a good degree, and one could not be answered adequately in the time available. He expected his undergraduate engineers to be able to determine which questions to avoid. If they couldn't, they wouldn't make good engineers anyway.I'd have failed immediately; I've always been a sucker for interesting hard questions. Probably a reason I'm more into science/research than engineering.
Professor Eric Laithwaite at Imperial College used to set exams where one question was easy and sufficient get you a pass mark, one was more challenging and couuld get you a good degree, and one could not be answered adequately in the time available. He expected his undergraduate engineers to be able to determine which questions to avoid. If they couldn't, they wouldn't make good engineers anyway.I'd have failed immediately; I've always been a sucker for interesting hard questions. Probably a reason I'm more into science/research than engineering.
Yes.
But in an exam you are up to your neck in alligators, and if you can't remember that your objective is to drain the swamp then you don't deserve to be an engineer
Professor Eric Laithwaite at Imperial College used to set exams where one question was easy and sufficient get you a pass mark, one was more challenging and couuld get you a good degree, and one could not be answered adequately in the time available. He expected his undergraduate engineers to be able to determine which questions to avoid. If they couldn't, they wouldn't make good engineers anyway.I'd have failed immediately; I've always been a sucker for interesting hard questions. Probably a reason I'm more into science/research than engineering.Yes.
But in an exam you are up to your neck in alligators, and if you can't remember that your objective is to drain the swamp then you don't deserve to be an engineer
The ability to both keep one's goals in mind when it's most needed, and to assess, even roughly, how much time a given task will take you, isanessentialpart of engineeringindeed.
Professor Eric Laithwaite at Imperial College used to set exams where one question was easy and sufficient get you a pass mark, one was more challenging and couuld get you a good degree, and one could not be answered adequately in the time available. He expected his undergraduate engineers to be able to determine which questions to avoid. If they couldn't, they wouldn't make good engineers anyway.I'd have failed immediately; I've always been a sucker for interesting hard questions. Probably a reason I'm more into science/research than engineering.Yes.
But in an exam you are up to your neck in alligators, and if you can't remember that your objective is to drain the swamp then you don't deserve to be an engineerFully agreed!
Fortunately, in real life -- as opposed to exams -- it is easier to find out the objective. In exams, the lecturer may have any number of different objectives, and it is not always easy to tell which.
The ability to both keep one's goals in mind when it's most needed, and to assess, even roughly, how much time a given task will take you, isanessentialpart of engineeringindeed.I definitely agree. (Overstrikes mine, because it really is essential nowadays in just about every task. Even research.)
I have an unfortunate tendency to underestimate the effort needed for my own part (a personality flaw), and must remember to compensate by a factor of two or so. It does not affect comparison of tasks, though. Outside work, in idle chat or discussions like in this forum, I often forget to compensate.
Like I said, am a researcher/problem solver, not an engineer.
It does not affect comparison of tasks, though.
Relatively comparing tasks is not helpful, though, when you need to make a decision which one to tackle, unless of course you have a hard rule of always picking the one which will take the least time (or the most).
You may have a choice to make between two options, one you know for sure is harder than the other, but you could still think it's manageable (and of course a lot more interesting)...
I find it much more difficult to define "success" in normal life!
Many people estimate how long it will take to do a task assuming they will be productive for 100% of that time. In reality many people are the only directly productive for 30-40% of the time. Hence a multiplication factor of 2.5-3.3 is appropriate. Or just convert to the next higher unit
One ability I'd like to have, is to tell the compiler to accomplish unrelated things in whichever order is best.
I really liked the Fortran 95 FORALL loop (where the iteration order is undefined), but they're deprecating that in future Fortran standards.
One ability I'd like to have, is to tell the compiler to accomplish unrelated things in whichever order is best.You'd probably need to be more specific though. At high optimization levels, good C compilers already re-order operations when they can safely do so. You probably had something more advanced in mind, would you care to give an example?
I really liked the Fortran 95 FORALL loop (where the iteration order is undefined), but they're deprecating that in future Fortran standards.I've seen that kind of loop in ParaSail (the language I created a thread for - didn't get much traction), I think. Of course it's just a curiousity more than anything else at the moment.
For the little I've explored with OpenMP, I think you can definitely do that with it.
One ability I'd like to have, is to tell the compiler to accomplish unrelated things in whichever order is best.
One ability I'd like to have, is to tell the compiler to accomplish unrelated things in whichever order is best.Compile-time optimization can only go so far in determining 'best'
A secondary use case is to interleave unrelated operations because their order and side effects is irrelevant