201–210 of 387 posts
Earlier quoted context omitted.
M............................................C M..............................................Java Look. C is much closer to how the machine (M) works.
Give that Java is written in C++ which is in turn an extended version of C, I'm not sure that chart is entirely to scale.
I think you're talking about the JVM. Anyway, some processors have native support:
My favorite take on the severity of the UB problem, https://blog.regehr.org/archives/1520 : > Tools like [Valgrind] are exceptionally useful and they have helped us progress from a world where almost every nontrivial C and C++ program executed a continuous stream of UB to a world where quite a few important programs seem to be largely UB-free in their most common configurations and use cases...Be knowledgeable about…
> Be knowledgeable about what’s actually in the C and C++ standards ... turns out to be an extremely tall order; the 2017-11-17 working draft of the C++ standard is 1,448 pages in PDF format. At some point, I wonder when programmers who are required to care about correctness throw up their hands and say "This language isn't reasonably human-sized for a user to know they're using it correctly." At which point the imme…
To be fair, that contains both language documentation and library documentation. The language specification portion itself is only ~400 pages, which is smaller than the Java Language Specification and JS's specification (both about 700-800 pages, although JS does include its [meager] standard library in there).
My favorite take on the severity of the UB problem, https://blog.regehr.org/archives/1520 : > Tools like [Valgrind] are exceptionally useful and they have helped us progress from a world where almost every nontrivial C and C++ program executed a continuous stream of UB to a world where quite a few important programs seem to be largely UB-free in their most common configurations and use cases...Be knowledgeable about…
What is profoundly pissing me off are bunch of hipsters on the internet that are using xyz language and are constantly trying to compare everything to C. We are faster, we are better, we are more portable, we have JIT, we have reflection... and so on. Who cares what your tool for solving the problem is. Use Java, use JS, use python, go, rust... whatever suits for the task. Why do you want to compare yourself to C. Ju…
Have a gnarly problem in a Python program that Haskell would be perfect for? Too bad. You'll spend more time figuring out how to transform the data and get the Python code to call into Haskell than you'll save by using the right tool. And in the process, the overhead, complexity, and bugs introduced in this process turn the right tool into the wrong tool.
And that's the reason why C is so important. It actually does work with pretty much any language, because it has a defined ABI, simple data types, minimal runtime, can work on any data formats unmodified, no GC. Very few languages have this superpower.
C++ mostly has that superpower, but some features don't entirely work with unmodified structures (RTTI and virtual functions both require adding magical fields to the class structure). Rust seems to have this superpower (does dynamic dispatch a different way than C++, so can always work on unmodified structures).
The JVM is an interesting case and the ecosystem of languages built on it do work better together because they have the exact same runtime (GC, etc.).
To summarize: we'd all like to use the right tool for the job. But we can't, except for the languages that go out of their way to make this effective, and that list of languages is very short.
Earlier quoted context omitted.
I don't have the patience to go fix Wikipedia, but microcode is a patching system (it's what "processor microcode updates" means). Most of the time, that's adjusting chicken bits and other flags. Instructions can be implemented in microcode, but they are really, really slow so it's typically done for security reasons or to emulate some new features that don't require fast performance. Micro-ops are part of the micro-…
I don't think wikipedia is broken, so plz don't fix. The definition of microcode matches my understanding. I've never heard it used as a patching system per se, ever.
People have this common misconception that the programmable micro-code is what your CPU is actually executing, and x86 somehow translates into instructions for it, and this was really just because of a conflation of the terms "micro-code" and "micro-op".
Admittedly, Intel isn't the best at this term either. They have several places in the Architecture Manuals where they refer to the "micro-code synthesizer" when they mean "micro-op synthesizer"; this really has nothing to do with the micro-code ROM.
Earlier quoted context omitted.
I don't have the patience to go fix Wikipedia, but microcode is a patching system (it's what "processor microcode updates" means). Most of the time, that's adjusting chicken bits and other flags. Instructions can be implemented in microcode, but they are really, really slow so it's typically done for security reasons or to emulate some new features that don't require fast performance. Micro-ops are part of the micro-…
Microcode on x86? Don't forget to also greet our friends such as RDTSCP, CPUID, RDMSR, POPCNT (on some models) etc. Also remember to check ENTER, BOUND, etc. out in the museum vitrine. But yeah, microcoded instructions are relatively rarely executed.
My favorite take on the severity of the UB problem, https://blog.regehr.org/archives/1520 : > Tools like [Valgrind] are exceptionally useful and they have helped us progress from a world where almost every nontrivial C and C++ program executed a continuous stream of UB to a world where quite a few important programs seem to be largely UB-free in their most common configurations and use cases...Be knowledgeable about…
> Be knowledgeable about what’s actually in the C and C++ standards ... turns out to be an extremely tall order; the 2017-11-17 working draft of the C++ standard is 1,448 pages in PDF format. At some point, I wonder when programmers who are required to care about correctness throw up their hands and say "This language isn't reasonably human-sized for a user to know they're using it correctly." At which point the imme…
I manage a c++ team btw. Our app has to be fast.
Earlier quoted context omitted.
> all that are complaining about it in whatever way possible or compare to it, will probably never be involved in a task where C excels, so why bother? I don't think that's a fair assumption. You may be underestimating the number of developers who have a need for a systems programming language.
Sure, I do. I am just hooking linux kernel calls, I will never take JS for this. Pure C. Valgrind? I have a header with #define MALLOC/FREE/REALLOC/... which returns larger buffer with guards at beginning and the end while after 25 years of C I hardly do anything more problematic that this. But seriously, would you give JS developer making kernel module? Ruby? PHP? No. So I wont compare with them and I would expect t…
> I am just hooking linux kernel calls, I will never take JS for this. Pure C.
Why not? Hooking native code in other languages is already fairly common: http://www.cycript.org
> Valgrind? I have a header with #define MALLOC/FREE/REALLOC/... which returns larger buffer with guards at beginning and the end while after 25 years of C I hardly do anything more problematic that this.
Valgrind does significantly more checks than your solution.
> System language? Make it.
"Systems language" is a very ill-defined term, often used to gatekeep people.
> If it is just a newage nonsense wasting resources for the sake of deallocating and taking care about buffer boundaries as it is so hard to take care and track your memory I will skip it.
Keeping track of your memory is hard. If you say "no, it's easy for me", I'd like to see a non-trivial sample of your code that doesn't have memory safety issues.
One of the blog posts I keep meaning to write is in the vein of "Why C is not portable assembly." Ironically, most of my points about C failures aren't related to UB at all, but rather the fact that C's internal model doesn't comport well to important details about machines: * There's no distinction between registers and memory in C. A function parameter that is "register volatile _Atomic int" is completely legal and…