Here's an interesting article that argues that using C to write low-level fast code that operates close to the bare metal is no longer a straightforward task, and is becoming increasingly virtualized..
...In light of such issues, it is difficult to argue that a programmer can be expected to understand exactly how a C program will map to an underlying architecture.
Yes, quite so. As a longtime pedant and onetime assembler programmer, I could never really see that it was correct to call C "a low-level language" and was skeptical of the terminology./Rant on:
Similarly, I was extremely skeptical of what looked like orchestrated obfuscation and fake news narrative around the so-called "Meltdown" and "Spectre" "threats"
("The sky is falling down!"). They are not "threats" per se
, but apparently built-in potential security weaknesses that were intelligently and knowingly hard-coded into the CPU firmware in the early days by Intel engineers, to optimise throughput rates. They were probably justifiable as a perfectly valid workaround
at the time - i.e., a justifiable trade-off to maximise efficiency. However, following the Snowdengate revelations, it became apparent that any such potential security weaknesses were likely to be exploited at some point - that's what made them "threats" - e.g., including (say) back-doors deliberately coded into Cisco router firmware, maybe (?) as a provision for anticipating the need for remote maintenance/support, etc.
Post-Snowdengate, there's been a sort of FUD-induced insecurity and an almost total cessation of trust (and add to that the Bitcoin scams) - so we'll all be wanting encrypted/blockchained everything and Tandem Non-Stop hardware and operating systems (or similar) at this rate. Then all our social chats can be "secure" and even the most banal data - "Hey! Cool pix of your cat/dog/twerk!"
will be "secured" (except to the NSA, of course). We'll probably get it too, but only at a cost. Some people are going to make a lot of $money
out of all that FUD. /Rant off.
The other day, I was trying out a proggie called Domain Name Speed Benchmark
>. I thought it seemed to be a very fast and rather nifty and small-sized proggie. Then I saw a bullet-point in the features list that said:
Hand-coded in 100% pure assembly language for highest precision and smallest size: 166 KBytes.
That explained it.