[Edited] For anyone like me stuck on his language: the phrase "move from" should be understood as a technical term loosely related to the English language meaning of the words. I think the post would be better if he explained this terminology; as it is you have to know an awful lot about the topic he is writing about to even parse what he is saying.
There is a pretty good stack overflow post that quuxplusone linked below. How they explain it:
Moving from lvalues
Sometimes, we want to move from lvalues. That is, sometimes we want the compiler to treat an lvalue as if it were an rvalue, so it can invoke the move constructor, even though it could be potentially unsafe. For this purpose, C++11 offers a standard library function template called std::move inside the header <utility>. This name is a bit unfortunate, because std::move simply casts an lvalue to an rvalue; it does not move anything by itself. It merely enables moving. Maybe it should have been named std::cast_to_rvalue or std::enable_move, but we are stuck with the name by now.
Now, if you don't know what "move semantics" is, then "lvalues can't be moved from" isn't terribly helpful, and if you do then it's tautological, so I'm not saying you're wrong to criticize. :) But in a C++ context, "move" does have a single specific meaning — the one he's using properly if opaquely-to-non-C++ers.
But here's the gist: sometimes you have an object you want to copy, but then abandon the original. Maybe it's to return an object from a function. Maybe it's to insert the object into a larger structure. In these cases, copying can be expensive and it would be nice if you could just "raid" the original object to steal bits of it and construct the "copy" out of the raided bits. C++11 enabled this with rvalue references, std::move, and rvalue reference constructors.
This added a lot of "what the hell is this" to C++ code and a lot of new mental-model stuff to track for programmers. I understand why it was all added, but I have deep misgivings about the added complexity.
I find that this can reduce overall complexity. It makes it possible to use objects that can not be copied (such as a file descriptor wrapper) and moving can in most cases not fail. Without move semantics you'd have to use smart pointers to get similar results but with extra overhead.
Presumably, if you already (mistakenly) believe that a prvalue is a temporary, then you probably have at least a vague idea of C++ move semantics. If you don't already believe that then you are probably not the audience for the article.
By what legal mechanism is it restricted that not any random company can make their own independent implementation of hardware that interoperates with x86 software?
AMD and Intel have a cross-licensing agreement for patents. Via also has one (two? I don't remember if Centaur and Cyrix's licenses were separate), Via's x86 division was basically disbanded in 2021.
There are independent implementations of x86 at least in software - QEMU can do full emulation at the cost of it being dog slow, which is about the only choice for running fully x86 virtual machines on ARM - no aid from Rosetta for anything.
The problem is the hardware magics you need to make x86 actually performant, there's a lot of patents surrounding that area.
>The problem is the hardware magics you need to make x86 actually performant, there's a lot of patents surrounding that area.
Those aren't even patented, they're straight up trade secrets. The relevant IPs concern the ISAs alone. Without doing anything too crazy you could implement x86 on your own silicon and make something that's slower than mainstream processors, but still usable for some things; certainly better than emulation in software, that's for sure.
Not quite. That's a board that contains both an FPGA and an ARM, what I meant was a board that just uses the FPGA for everything and an i386 or better core without any auxiliary processors. 100% clean hardware.
Not really sure what you mean by "no auxiliary processors". Even the on the original IBM PC the CPU was not directly in charge of all the devices. That's generally undesirable because it means any IO ties up the CPU. I think that's what they're using the ARM core for, though I've only just heard of this board minutes ago.
That's a bit different. The whole idea I have revolves around a clean computer without any kind of 3rd party hidden tricks. Of course, the original PC already had several auxiliary processors in places that are important, such as drives, keyboard etc. But let's take those for granted. Adding a soft-core FPGA based i486 to a much more powerful ARM system opens up a massive can of worms: that ARM could do just about anything to the poor 486 without it ever being the wiser.
Anyway, this project may be useful (I've been digging around in it some more since making the previous comment) because the FPGA itself is fairly common and the i486 bits and pieces could probably be recycled in something much simpler.
You've probably seen this already, but just in case... You might be interested in Bunny Huang's work on Betrusted and Precursor. He's building a soft-core FPGA based on RiscV instead of i486, but it's a fascinating project:
https://betrusted.io/ - which includes an open source RiscV design that runs on an fpga
Yes, I've seen it, in fact that's my major inspiration. I already have some software that I can run on an i486 so RiscV would come with substantial extra development cost.
>that ARM could do just about anything to the poor 486 without it ever being the wiser.
Any device with DMA has that same issue, though. You could plug in a hard drive that takes control of the CPU by writing new instructions when certain conditions are met. Even if it doesn't have DMA, it could fulfill a request with crafted data. You can't defend against an adversary in your own machine.
> You can't defend against an adversary in your own machine.
Not if you import large chunks of unknown hardware. But if you built the whole thing from scratch you could. And FPGA's with adversarial blocks in them (or a toolchain that would corrupt your own bitstream) are probably possible but I don't see these as realistic attacks against a one-off.
An i486 certainly doesn't have an integrated iommu, and none of the chipsets for 486s had them either (afaik), but that doesn't mean you can't add one if you're building up your system from scratch.
Or you could forego DMA completely if you wanted. Almost all DMA capable devices have some kind of non-DMA route to access the data. It may be slower and it would of course still enable an adversary with access to your hardware to replace the device you boot from with one that has compromised data on it. But at that level it is usually game over anyway. I was thinking of just using an SD card, and if you're really paranoid about this (which I am!) you could glue it into the slot or make it physically impossible to replace it without damage to the case.
There is no reason to assume it's an independent implementation, it very well could be a company partnered with Intel or AMD.
Hypothetically, Sony could ask AMD to support additional custom opcodes for a still-under-development PlayStation 6 processor, and it would be legally kosher.
Every time new extensions get added to x86 new patents and copyrights are issued to cover those extensions. If you want to make a CPU compatible with what a current compiler produces, you need most of those extensions.
Legally, could a CPU manufacturer implement the unencumbered ISA in hardware and have a separate corporate entity provide a low-level software compatibility trap for the missing instructions? The CPU could even have functional equivalent (but ISA-incompatible) instructions to make it almost as fast. Kind of like third-party microcode?
In theory yes, the problem is that even x86 emulation in hardware in order to run x86 code natively without recompiling can drag you into a legal mess which any western company will avoid.
NVIDIA got pinched for this over a decade ago.
I’m not entirely sure how Qualcomm and Apple didn’t.
But overall the more you try to make an x86 enabled alternative viable the more likely you’ll get served with papers and even if you’ll win it would take a decade and cost 100’s of millions to fight.
There are further versions of SSE (SSE4 is pretty much a hard requirement on Windows) and a follow-on series, AVX. AVX-512 is from 2016 and AVX10 is from 2023.
That makes me wonder if all those vector extensions pilling on top of each other were really that necessary, or if they are mostly a means of keep churning out patents to delay expiration.
Is it possible to just improve the original SSE extensions in a logical backward compatible way? Similar to what AMD did to x86, widening it to x86-64, dooming Intel efforts to push the incompatible Itanium architecture?
SSE3+ & AVX{,2,-512} & co improve on SSE in pretty much the same way that x86-64 improves on x86 - the old thing still works just fine, but the new one is wider, adds new (very useful!) instructions, doesn't copy over others, and (at least partly) uses different encodings.
And an important thing to remember is that there is and never as a single "x86" before x86-64; both Intel and AMD added new instructions as was seen useful in new generations. AVX & co just continue the pattern that's been going on for four decades.
No, the newer extensions are different opcodes. It's like extending an API, you can't change old function signatures, you have to add new ones. The new ones are legitimately useful, most video games and media production software use them a lot.
Predicting what you will want in a few years is tricky at best. Some things that seem like a great idea are not worth it in the real world and so you pay the price for flexibility nobody uses. Some use case you didn't think of comes along that could really be helped with some tweak you didn't anticipate. thus your flexible architecture is both too flexible and not enough at the same time.
the above is a constant problem in engineering projects more than about 6 months old.
RISC-V uses a length-agnostic approach, so that would've at least bypassed the need for width-expansion upgrades. But it's something you have to take into account from the very start...
And even that only helps with the length problem, and doesn't help with doing new operations.
For SIMD, baseline x86-64 (i.e. SSE + SSE2) didn't have dynamic shuffles & shifts & blend, float floor/ceil, integer conversions & min/max & 64-bit comparisons & 32-bit mul, just to name things useful for even very boring SIMD; then in AVX2 we also get gather/masked load/store, FMA, and in AVX-512 we get a bunch of neat mask stuff, integer narrowing & rotates, compress.
(much of those things RVV has in its base extension, but RISC-V already has a good number of extensions on top of base RVV for things like like float16/bfloat16, expanded bitwise stuff (Zvbb - rotates/popcount/lzcnt/widening shift), clmul, and a bunch of crypto things; and presumably in a decade there'll be a bunch more things that people will want in their CPUs that'll have no choice but to be new extensions)
If the scalable VLEN is the same as the ALU width, which should generally be the target, small vectors would still perform optimally.
Of course if you need less than a VLEN-sized vector you're wasting throughput, but that applies just as much when using 128-bit vectors on AVX-capable hardware, and even worse so on AVX-512-capable (which, while double-pumped or equivalent to some extent on most impls, still has 512-bit-exclusive throughput on most).
Some of SSE is required as part of the x86_64 ABI, and also new versions of Windows (infamously, now) add required CPU extensions so software will often base its requirements on that. And SSE4x is ubiquitous enough (99% of PCs) that some software/games will just require it and simply crash if it can't use those instructions.
Considering there are no meaningful patent-free x86 CPUs in the wild, why should they?
It's just the default optimization level for those distros. If patent-free x86 CPUs become relevant, compiling another set of binaries would be trivial. Until then it doesn't make any sense to kneecap the >99% of x86 deployments by deliberately refusing to use faster and more efficient instructions.
Wait, you can patent an operation? Is it not considered an API? I assumed the Java case would meant you couldn't. I would think it would be limited to the hardware implementation, or maybe some specifics of the alg.
They said that, but my understanding was that they were really trying to scare apple back on to x86-64. It didn't work, and it was pretty specious anyway.
I would suspect that the patents and other IP dont protect against a software implementation of x86-*. Similar to the way copyright doesnt protect against somebody else making a clean room implementation of an API.
No idea what happens around firmware implementations or an FPGA.
Usually patents and the risk of being sued out of existence despite having the right to implement clean-room clones.
Patents use sly language and legalese spagetti. If your implementation looks similar, you may lose the right to manufacture certain parts or the entire thing. The law is deliberately vague and you are at the whims of the judge.
You make it sound like there must be a real high-Level strategic reason behind this. More likely it’s just a low level face-saving exercise. Someone probably spent 10s of millions of Secret Service budget chasing some threatening text messages sent to government officials, and in the end what they have to show for it is taking down a $1 million spam operation. So they hype it as a cyber-espionage threat anyway to make themselves look good.
This post jumps into the center of some controversy in a very unclear place. Is there a short (preferably neutral) summary of what this is all about somewhere?
DHH created Rails, but he didn't write Rails - a large community did. This is an attempt to be factual. Linus created Linux, but he didn't write Linux. Etc.
Criticizing an *individual* for stopping to *donate* is pointless.
Supporting Canadian truckers was a straw? And that somehow broke the camels back because of misogyny in slides and booth ads (showing a pretty girl?).
Because of this they lost a 250,000 sponsorship from sideiq which then gave leverage to shopify to takeover the community because of a fear of this rv tool.
In the end their communities purity tests lost them everything.
If this was true wouldn't there be a market for a ruggedized version that has the toughness of a case, from the factory as shipped? Its a little silly for Apply to shave every possible half-millimeter from the design and then have 99% of people add back the thickness plus a lot of extra by adding a case. Why not have a factory-ruggedized version which isn't as thick as adding that case but is just as rugged?
Considering the price and re-sale value of iphones I would add a case even if they ruggedized it.
My current (Android) phone is from 2020 and I have bought three cases for it because the previous ones got wear and tear. The phone inside still looks brand new.
But yeah, the trend of ultra-thin phones is silly.
That open a new business for them to sell $60 cases that are worth $2 of materials and have a great panel to match people’s taste which is even more appealing to buy
Some overlap but not identical. There are 38 Mac patterns compared to 32 geos patterns. Of these I count 27 that coincide; 5 are unique to geos and 11 are unique to the Mac. I think certainly the direction of copying is geos copying from Mac.
> I think certainly the direction of copying is geos copying from Mac.
Given that the Mac shipped with those patterns in early 1984 and GEOS in 1986, it can’t be Mac copying GEOS.
That doesn’t mean it was GEOS copying Mac, though. Various horizontal and vertical stripes, block patterns and attempts to get a range of grays easily can be parallel evolution. 27 out of 32 seems a bit much, though.
Most languages that have made it big have been the primary language for a platform that made it big, and it is really the features of the platform more than those of the language that have driven that.
> Most languages that have made it big have been the primary language for a platform that made it big,
I think you're going to want to define "made it big" and then make yourself some lists as this to me sounds like it doesn't have much explanatory power.
Mathematician here, so educated layman on the physics but expert on infinity if you like.
Mathematically, "infinity" doesn't imply every possible option. But in terms of quantum physics, yes it kind of does include every possible option. There is a kind of joke classroom exercise in quantum physics class to calculate the probability that a piano would instantaneously rematerialize a meter away from its previously observed location. Its 10^-[ ridiculous number] but still thats not zero.
The size of physical reconfiguration of a person's brain to cause them to break out singing is a much smaller deviation so comparatively likely. So 10^-[somewhat less ridiculous nunber]
The bigger issue with all those non-zero probabilities is they're meaningless while you still experience actual time as a human...but become pretty damn significant when you experience no time after you die.
So tiny probabilities become essentially guarantees unless the heat death of the universe is so thorough as to erase the slight probability that the whole thing pops back into existence.
