Slashdot Mirror
Variable Instruction Computing: What Is Old Is New Again (hackaday.com)
szczys writes: Higher performance, lower power. One of the challenges with hitting both of those benchmarks is the need to adhere to established instruction sets like x86. One interesting development is the use of Variable Instruction Sets at the silicon level. The basic concept of translating established instructions to something more efficient for the specific architecture isn't new; this is what yielded the first low-power x86 processors at the beginning of the century. But those relied on the translation at the software level. A company called Soft Machine is paving the way for variable instructions in hardware. Think of it as an emulator for ARM, x86, and other architectures that is running on silicon for fast execution while sipping very little power.
Can they really get better performance per watt on general computing using a flexible substrate? Seems like whatever design they set up the flexible (FPGAish?) circuit to do, could be faster and lower power if it were put into a fixed silicon (or similar) implementation. Maybe if your workload devolves down to very simple needs for long periods of time, this might take advantage of that.
So instead of the current situation where we have intel/amd processors doing something under the hood, using microcode as the language that translate the x86 environment into whatever is actually on the silicon ... and you're going to add ARM to it, and maybe some other ones?
Thats cool and all, but its not really all that useful, and intel can pretty much already do that on any CPU it wants with a microcode update. ARM may not run as efficiently on the core that intel uses, but it can be done from a technical point of view.
Its not worth it. Thats why no one does it.
You'll effectively do nothing well.
Intel was an ARM licensee (probably still is), they know ARM as good as anyone outside of ARM itself ... and they made entirely new silicon to run it (well technically they bought it if I recall correctly) ... and it even had its own microcode ... But what they never did was share a single core between both ARM and x86 CPUs that could change modes with a microcode update. No reason they couldn't other than its not efficient.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
Yep - the B1700 did this in the 1970s. Been there, done that... (I was a CPU engineer on one of them.)
Have you compiled your kernel today??
nikto is the last word. as written, it's a jelly doughnut.
Transmeta with a hardware morphing layer?
Silence is a state of mime.
Translating instruction to micro-ops to run on a VLIW-ish backend? I think every high performance architecture does that now (arm and x86)
Share processing resources between cores? AMD tried to share the FP pipeline (flex FP?) between cores starting with their bulldozer architecture, but it looks like they are going to abandon that with their zen architecture after getting beat up about single thread perf...
I remember studying about variable length instruction sets when I was studying CS back in the '70s. Scared the hell out of me.
"Variable" or "variable length"? There's nothing particularly exotic about instruction sets where not all instructions are the same length, so presumably you meant the former.
As the 6502 only had a single stack, limited in size to 256 bytes, and hard coded to reside at memory address range 0x0100-0x01ff, I might tend to disagree with that assessment.
File under 'M' for 'Manic ranting'
Yep - the B1700 did this in the 1970s. Been there, done that... (I was a CPU engineer on one of them.)
But they didn't translate programs compiled to the various S-languages directly into microcode and execute the microcode. From this article about them, it sounds as if that's what they're doing:
so this looks more like Transmeta.
http://www.amazon.com/The-Soft-Machine-William-Burroughs/dp/0802133290
Or Soft Machine, the band.
translate programs compiled to the various S-languages directly into microcode and execute the microcode.
What could possibly go wrong, in today's connected era. LOL.
Seven puppies were harmed during the making of this post.
Went RISC uOps to Get Perf. Anyone who thinks a PENTIUM was looking for Low Power Is AN IGNORANT SLUT!
(Pentium Pro, but whatever.)
No, but Transmeta did something similar to what it appears Soft Machine are doing, and did so to reduce power consumption; I think that's what "The basic concept of translating established instructions to something more efficient for the specific architecture isn't new; this is what yielded the first low-power x86 processors at the beginning of the century." was referring to.
translate programs compiled to the various S-languages directly into microcode and execute the microcode.
What could possibly go wrong, in today's connected era. LOL.
That's pretty much what these guys do, although they've stopped calling what it gets translated to is "microcode" (in the current machines, it's Power Architecture code, possibly with a few extensions such as tag bits).
(They used to call the low-level OS and binary-to-binary translator code "vertical microcode", in the days before it was PowerPC/Power Architecture code, but that was for legal reasons; they didn't want to be forced to make the code available to clone makers. "Vertical microcode" ran out of main memory, and the binary-to-binary translator translated compiler output to the "vertical microcode" instruction set and ran it from main memory as well. The original "vertical microcode" instruction set was somewhat S/360-ish.)
Make a cpu with just a few instructions and do complex stuff by repeating simple things many times, fast....oh hang on...
I can only wonder... if the Crusoe and Efficeon patents are being licensed from Intellectual Ventures (who ended up owning them), or if we are going to see another East Texas lawsuit over this.
Well - variable length instructions, variable length data path too. The S-ops were Huffman encoded, i.e. the most often used were the shortest. The B1700 had a about a 3:1 code density advantage over the IBM 360 in Cobol if my memory serves me. Yes - likely Transmeta's JIT compiler is closer to what this is about. I also worked on the Cydra 5 which was a VLIW machine - it's Achilles heal was solved by the JIT trick.
Have you compiled your kernel today??
There is a reason the idea fizzled: If you have very special code, it may be able to compete speed-wise, otherwise it will be slower. As compilers optimize better these days, it will be even worse today. And the "low power" is a red herring: If you want that (at slow speed), compile to ARM code, not to x86.
My guess is somebody is looking for funding from clueless people.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Wow dude... that's like, super meta... I mean, it's basically transmeta...
Get it? Is this thing on?
Yes and Transmeta were not particularly successful in spite of the promise the technology showed.
Yep - the B1700 did this in the 1970s. Been there, done that... (I was a CPU engineer on one of them.)
So did the i432 a few year later.
Intel iAPX 432
The innovative features of the iAPX 432 were individually detrimental to good performance. Combined together, it ran slower than contemporary conventional microprocessor designs such as the Motorola 68010 and Intel 80286. One problem was that the two-chip implementation of the GDP limited it to the speed of the motherboard's electrical wiring. A larger issue was the capability architecture needed large associative caches to run efficiently, but the chips had no room left for that. The instruction set also used bit-aligned variable-length instructions (as opposed to the byte or word-aligned semi-fixed formats used in the majority of computer designs). Instruction decoding was much more complex than in other designs. In addition, the BIU was designed to support fault-tolerant systems, and in doing so up to 40% of the bus time was held up in wait states.
much of left-wing thought is a kind of playing with fire by people who don't even know that fire is hot - George Orwell
This sounds like Transmeta. Remember that, Slashdot old-timers? The company had trouble, and was eventually bought by private equity. I'm too lazy to find out if this is a re-emergence by the rights holders, or if they're going to get sued by the guys who bought Transmeta's IP. IIRC, It was an Israeli company that took it off the US exchange. After that I lost track of it.
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
Or maybe Netflix. It has the makings of a great Zombie movie - with Orson Welles as RMS, Vincent Price as Theo, Peter Cushing and Christopher Lee and Kernighan and Richie, Lon Chaney as SCO and Special appearance of Boris Karloff as Bill Gates.
I am willing to write the screen play (in K&R C) for a considerable fee. Someone else will have to do the CGI.
Sent from my ASR33 using ASCII
Yep - the B1700 did this in the 1970s. Been there, done that... (I was a CPU engineer on one of them.)
So from within the dark entrails of Burroughs you were one of the Hardy Boys helping bring to light the Soul of a New Machine? That's awesome, and I'm not Kiddering. What if... those BCD architectures were designed from scratch using today's tools and methods? Is there something the machine could do inherently better or faster, something that benefits from the use of errorless unbounded decimal arithmetic?
<blink>down the rabbit hole</blink>