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.

Comments

Flexible, but better than fixed?

[JoeMerchant]

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.

Re:Flexible, but better than fixed?

[Aighearach]

The problem with your analysis is that the words "flexible" and "fixed" don't have technical meaning here. Those aren't differing physical characteristics to choose between, those are just human-level descriptions of how the programming will be organized.

An FPGA intentionally has a whole bunch of extra circuits supporting each logical unit, those are expected to take a lot of extra power because it is additional functionality. An FPGA doesn't use more power per physical transistor, it just has a whole bunch of transistors and other logic devices for each programmable unit. When you then implement the circuit as an ASIC, it uses less power because it uses less logic devices, not because there is some other qualitative difference.

Something like this, any extra logic devices would be specifically designed to manage the other logic devices for low power use. That is a very reasonable thing to try to do. If their implementation is successful and useful in the market is a whole different issue, of course.

Transmeta was successful from an engineering perspective; their products used less power than their competitors. Problem was, they were only a few months ahead, and required too many changes in devices. All other companies had to do was be richer, and more able to secure access to new fab technologies.

One big difference here is that this will potentially change thread management for programmers in a way that many people will like. It might very well be able to fragment the industry and corner a significant chunk of interest.

So, its like x86 already is?

[BitZtream]

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.

Re:So, its like x86 already is?

[KiloByte]

Too bad both Intel and AMD keep their microcode closed. There's so much fun we could do if they were documented and non-Tivoized.

Just the first use: shuffle opcode numbers, make your compiler emit those and recompile your software per-installation. Any exploits that use machine code are instantly thwarted.

And that's just a start...

So....

[wbr1]

Transmeta with a hardware morphing layer?

Re:WRONG!

[Guy Harris]

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.

Re:Yea I'll believe it when I see it...

[Guy Harris]

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.)

Re:Uh... no

[jeremyp]

You forget that the 6502 could do indirect addressing through any of the zero page locations giving you a potential 128 stack pointers for your stack machine. Also, the zero page had a special address mode so that loads, stores and increments/decrements could be done with two byte instructions instead of three byte instructions, reducing the fetch execute time by one cycle.

However, I think the main reason stack machines were often implemented on 6502 has more to do with its relative lack of registers. There's only one register on which you can do arithmetic which means that you have to constantly save data out of it when calculating complex expressions. The stack machine architecture makes this a fairly task.

Re: Old is new

[chaboud]

Wow dude... that's like, super meta... I mean, it's basically transmeta...

Get it? Is this thing on?

Transmeta?

[istartedi]

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.