In the before times the close eyes were by directors and funding committees at the institutes like NIH and NSF. Now those roles are played by political appointees and funds controlled at the whim of the office of the President and their fundamentally anti-science agenda.
"It just radiates jank" ... that line resonates with me, but is sonehow a bit attractive. Like this is how things might be done in some alternative grittier universe. Like this is how Kaylee would make data formats execute on the Firefly. Its steampunk programming.
Thanks. I watched a few snippets of the video but I hate video. It did look like it would have been an interesting blog post but no way I am sitting thru that.
Google maps is doing the same thing to local business success that social media algorithms are doing to political success. The algorithm controls what you perceive as the consensus of others. It is a dangerous world to have such power so highly concentrated.
Perhaps such things should be controlled democratically instead of by a single person or a small group of people whose companies are organized as dictatorships.
It is controlled democratically. The people have democratically ceded their knowledge gathering to large companies. Because people are above all else lazy
"Decide" is a heavily weighted word here. From what did they decide? Was the field from which they were deciding, perhaps monopolized, or ologipopalized? Was there information skewed by the entities hoping to be chosen? Do said entities have stunning amounts of capital and power that let them prevent competition?
First off, let me see ALL the restaurants in my city, not just the 10 recommended ones.
Second, stop moving the map when I search for things. Why does google maps on both mobile and desktop, change your search area. I put the map in one place because I want to search there.
Third, stop scrubbing bad reviews. When every restaurant is 5 stars, theres no point
> The latest work has again been made possible by funding from Time Team, for a new programme they will be making next year.
This is funded by a TV show whose primary concern is ratings earned by how exciting is the entertainment value. I think that explains the low-content but very breathless press-release article now: they want to hype it up for the show to get viewers. This smells like show-biz hype rather than scientific excitement.
[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.
reply