minipci1321

> so they do not allow the efficient use of modern CPUs otherwise than by using inline assembly or compiler intrinsics.

When one provides the full effect of the operation in the source code, a properly ported compiler backend should be able to spot the pattern and emit the instructions with matching non-C semantics. (Typically, saturated operations are a very low hanging fruit.)

That doesn't always work because the optimization passes targeting local optimum break these patterns while "optimizing" them, so they arrive to the instruction emitter unrecognizable. And these passes, living in the generic "good-for-all" area of the compiler core, cannot be made aware of what a particular target does or doesn't support. So ironically, such instructions appear more when the optimizations are disabled.

Intrinsics emit internal representation forms that optimization passes don't dare to touch.

> C is an abstraction of the machine, so thin it's nearly transparent.

-Werror might help with that

Thought it was about electric fence the malloc debug library, and was surprised to see so many comments. Turns out it is not mentioned at all in the comments, so correcting that :)

These days they do that using a vape, cover the PCB with a thick layer of vapor and see where it raises the fast after power-up. Youtube has videos.

Check out: https://www.history.com/news/chernobyl-nuclear-disaster-7-pe...

Look up the section for Anatoly Dyatlov

Ooooh, that hit the nerve )).

The author, rather unfortunately, focuses primarily on the predation from the "generalized colleague", and that wasn't welcomed by many commenters, possibly because people in big-tech tend to be young and do need help, so have to ask for it.

But the way I see it, the predation is institutionalized in big companies.

-- The Intellectual Property department blocking the entire R&D of the entire product division for the whole day, to give a presentation on how to file a patent. Knowing full well that only a dozen of these people will every do, at best.

-- IT dept locking down everything, because, you know, there are risks and we don't want to take it. Doesn't matter if it slows down everyone else everywhere.

-- "Security" disabling access to slightest technical information, because, you know, someone could steal it. Just ask and you'll have access. (How does one asks for something one doesn't know exists?)

-- Purchasing that shortlists only some contracting shops and not accepting any others. Doesn't matter if the shortlisted one don't "carry" the competence (e.g., try EMC specialists).

All these people consider that as their achievements and are not shy about it when yearly appraisal comes. We all work as one team aren't we? And then comes the day of layoffs. One reason of it being that the R&D hasn't been performant enough. Guess what, we aren't so much of one team anymore.

> Maybe I've read to much French literature which set some expectations.

See also: <https://en.wikipedia.org/wiki/Paris_syndrome>

Do you have siblings? How have they turned out?

> And even if you write inefficient code, CPUs are so fast that you won't notice it.

I think you are arguing for the right cause but with wrong arguments. In C language, not understanding in details what exactly the code does, can be just as disastrous as in Verilog. Internet examples abound.

"Potop" is also missing it seems? Didn't find "Katyn" either.

> Yeah they compile to the same machine code operations though.

Not always. Switch your example to AARCH64 and check out the BFI instruction.

> ... malloc() returns a pointer to sequentially-addressable bytes ...

malloc () doesn't return even that. It returns 'void *' which isn't of much use without a further upcast. The required upcast, and the rest that follows, is the coder's own idea of what happens.

> It's also hard to know anything other than C++, because of how taxing the language is; there's little energy left in you to learn something else.

When I think that in my industry, good mastership of C++ is, what, 30% of what it takes... Throw in real-time design principles and a few different kernels, several CPU architectures, unavoidable Linux and a one or two build systems (Yocto anyone?). And only then comes the real problem domain, communications protocol stacks or image-processing algos, or what have you.

I spent time typing in a setup with very dim ambient light (think of a photo room with dim red light). I still cannot touch-type, but after some time I discovered I can type in QWERTY on any keyboard layout.

> Changing return type from "void" into some "result" is a mechanical change.

.. but then checking the returned val for error in every call sites is very far from mechanical change. (Attribute about unused return result can help here, with obvious drawbacks.)

> 10. has anyone yet found a legitimate use for throwing an `int`?

I use that a lot in constexpr computations -- to stop the compilation, I usually do 'throw __LINE__'.

-- Using a more complex type is not warranted -- there is no catching end in constexpr.

-- And in case the same routine ends up called non-constexpr, it will be easy to identify the place that called 'throw' -- line numbers are unique without additional effort. Just don't put two throws on the same line.

Let's go see some figures!

"Empirical Study of Power Consumption of x86-64 Instruction Decoder"

https://www.usenix.org/system/files/conference/cooldc16/cool...

From the conclusion:

"The result demonstrates that the decoders consume between 3% and 10% of the total processor package power in our benchmarks. The power consumed by the decoders is small compared with other components such as the L2 cache, which consumed 22% of package power in benchmark #1. We conclude that switching to a different instruction set would save only a small amount of power since the instruction decoder cannot be eliminated completely in modern processors."

Somehow I doubt this wide-sweeping affirmation, are you sure? Atom is really big family by now, starting from Silvermont it vent full out of order with all bells and whistles, I find it hard to believe OO backend is anywhere near the size of x86 insn decoder.

> Mixing unsigned and signed is seriously broken in C, and hence better to stick with signed.

Mmmm .. maybe in this specific case (didn't look). But if you meant this as general advice, then one should keep in mind that unsigned overflows are specified but signed overflow is UB (barring maybe the very latest version of C standard); because of that, unsigned division in many cases is trivially optimised to less complex ops, etc.

There are many advantages in using unsigned.

You are of course entitled to your personal opinion, and sharing it is OK, but this:

> ... the low work ethic .. (I exaggerate, slightly).

is a very wide-sweeping generalization which insults many of us.

Why is it that, every time someone complains about "low work ethics", the underlying context is always "my employees don't want to spend mad hours working on my idea for the compensation I think should be fair for them"?

Work ethics goes both ways BTW, and your "glory to firing someone with less than six months notice" doesn't sit square with me. "firing" is terminating for serious misconduct, notice is not due. I assume you meant laying off for economical reasons. So you want exemplary work ethics from the employees, and then quickly get rid of them when you think you don't need them anymore, did I get that right?

> After years of optimization, I have a better quality of life than our CEO. I'd be insane to give it up.

Maybe you did run in to it but haven't mentioned, or maybe 5 years is not enough to see it -- have you noticed that a big part of the "remote culture" that few know how to build, is proper recognition of remote workers in the mixed- or dominantly-office- teams?

Those CEOs are perfectly aware that your life quality is higher than theirs on a much lower income, they know full well you are not going away anytime soon...

Many (most by now?) consumer cable networks use SIP (check out PacketCable 2.0) and still don't/wouldn't interoperate. There is much more to voice calling than just SIP, big part of that is attaining guaranteed acceptable quality.

IBM s/370 (possibly even s/360) too had memory page tagging -- see instructions ISK / ISKE.

Oh, don't get me wrong, I am far from blaming employer on that. Or anyone for that matter (not Canadian, Europe, our govt does what they can ... you cannot break bones to national business culture in one-election-term timeframe).

It is just that it feels hopeless either way: companies who strip it down bare to what the employed work really is -- a wolf-pack hunting together -- don't feel that great, and the opposite, pretending that we all are in the middle of a nice cozy great-place-to-work -- gets down on nerves after some point too.

The only solution, switch jobs regularly by all means. Play the national lottery.

Over here, yes, it has gotten worse since 2001 -- asian shops press much harder now, cheap remote labor really easily available ... competition vent through the roof. Longer hours, guilt feels stronger, sloppier work, inter-team communication destroyed (all-email in some language foreign to everyone), and -- still more lost deals.

This is for everyone, workers and management.

True, people maybe feel more entitled. But I think we also are getting introduced to a phenomenon new since 2001 -- having a solid "living wage" (which Trubune says noting else replaces), but burning out repeatedly, hating the job but being unable to quit, as providing for family takes more now than it used to in 2001, too.

Replied to your personal address.

I only quickly checked and found this:

https://rusneb.ru/catalog/000224_000128_0000488231_19751015_...

-- click on "Skachat' PDF" (second from the top on the left). Unfortunately it is in Russian, not sure whether English translation exists.

This patent seems only for (X,Y) coordinate capture, but the same authors later worked on 3D setups as well.

EDIT: let me know if you need help with translation

Great accomplishment, but people were building 3D ultrasonic scanners back in 80-ies, for much less than $100:

[didn't read your article, your claim has put me off, sorry]

-- use an electric spark gap as the wideband acoustic source

-- use 3 simple electret mikes on 3 axes. Mikes don't need to be high quality (spark intensity can always be raised as necessary), so they were hand-assembled using metallised mylar film (used nowadays to pack some food, or ESD-sensitive electronics components).

The rest was data processing.

> Another perk: in communism you did NOT pay any from of income tax as ordinary worker

Income tax was of course collected: https://aif.ru/money/mymoney/kakoy_podohodnyy_nalog_byl_v_ss...

of which workers might have been not fully aware (as it was deduced before wiring/handing-out the cash).

But there was also such a thing as "childlessness" tax on income, and concerned workers were well aware of it.

I feel and sympathize your nostalgia of the past, but it doesn't seem proper to extrapolate your personal experience to the "millions" of other USSR inhabitants. Western republics of the USSR were the proverbial land of milk and honey, out of reach for the vast majority of them.

Maintaining projects in assembler requires much less heroics than developing them. Significant part of Soviet computer program, shortly before (Minsk 32), and after they switched to cloning IBM mainframes (ES EVM), was maintained in assembler only, once they lost access to the original PL/S source code of the OS and other system products. These were teams of many people and the activity lasted long enough time to fit your criterium. They certainly outlived the originators by several dozen years.

Maintenance involved fixing bugs (including in the OS kernel), localizing software to a different language (sounds inoffensive ... when you have source code. Much more nasty when translated sentence doesn't fit into its allocated place in the binary). And adapting to hardware difference, such as less RAM, less capable peripherals and slower CPUs.

EDIT: Minsk 32 was bespoke development but the language still was close enough to hardware to be qualified as assembly by today's standards.