CPU tailored to OS?

[Voyager]

@si_blakely

Sun invested considerable time and money about 10 years ago into Java CPUs, that could execute JVM bytecode on silicon. The problem is that the rate of performance increase in general purpose CPUs was faster than the development cycle for specific purpose CPUs, and so by the time the Java CPUs were ready, it was faster and cheaper to use general purpose CPUs.

This is often still the case (apart from some specific spaces, like DSPs and GPUs).

Si

I wouldn’t exactly call it considerable time and money - it was never a major design thrust. BTW, at one point these CPUs were open source - you could freely download them from the Sun site, after agreeing to pay Sun royalties if you ever made money off of them.

[Voyager]

@iamnotbatman

See, that’s interesting. I wonder about the possibility of something similar on a much larger scale. It sounds like one of the main stumbling blocks is how quickly OS’s need to be patched or otherwise are changing (like linux). Perhaps in the far off future the technology of processor design and production will be such that we will have the tools to quickly translate a high-level instruction set into a producible cpu design in an automated fashion. Sort of like a compiler, but on the hardware side rather than the software side.

Like maybe here for example (to just mention the one that comes to mind.) Mentioned in post 9, btw.
This goes considerably beyond normal everyday synthesis.

[Voyager]

@t-bonham@scc.net

There are some influences this way.

The early Cray supercomputers had one CPU instruction added just because a specific customer (NSA) wanted it. [Popcount – count the population of bits that were on in a word.] Apparently that was quite important in some of the cryptographic work they did. This was contrary to Seymour Cray’s RISC design*, but they were his biggest customer.

A few years back, there was an idea of making more effective supercomputers (not necessarily faster) by making the hardware re-programmable on the fly. By re-programming microcode to make the CPU instructions more tuned to the needs of the specific problem program, and possibly by rearranging the interconnections between the CPUs. So a problem program might spend some time re-programming the hardware to run that program more effectively, before it actually starts executing the program. Something like re-burning the PROM chip holding the BIOS in a PC system. I haven’t heard if this was actually done, or how well it worked out.

• The old joke was that RISC actually stood for Really Invented by Seymour Cray. He’d been designing that way since the CDC 6600, about 1963 – long before anybody gave a name to RISC.

More than a few years back. As I said, this idea has been around since at least the late 1970s, and I vaguely remember Dave Kuck talking about it in the early 1970s in the architecture class I took from him.

I think we need to distinguish RISC as a design philosophy from RISC forced upon designers by expensive hardware. My old LGP-21 had about 16 instructions, but I wouldn’t really call it a RISC machine. I taught Cyber assembly language after I taught PDP-11 assembly language, and wrote a simulator for it, and I didn’t think it very reduced, though at this time the RISC concept only existed within IBM.

[Voyager]

@Derleth

Both VHDL and Verilog meet this description. The development process from taking a Verilog program, for example, from source code to silicon is a lot more complex than doing the same for software, but it gets done all the time.

Starting at RTL, or even one step above RTL, is hardly the same as starting with an instruction set description. If I dumped the RTL for a modern processor on you, I think you’d have a hell of time figuring out the instruction set from it.

[Derleth]

@Voyager

Starting at RTL, or even one step above RTL, is hardly the same as starting with an instruction set description. If I dumped the RTL for a modern processor on you, I think you’d have a hell of time figuring out the instruction set from it.

Ah. Right. Well, I suppose I missed the part about ‘high-level instruction set’ going to silicon, as opposed to something lower-level like RTL.

And there’s something to what you say about RISC-by-design versus simple-by-necessity: Compare a given MIPS design to the 4004, or the PDP-8. Simplicity of implementation isn’t the only criterion for being RISC.

[Voyager]

@Derleth

Ah. Right. Well, I suppose I missed the part about ‘high-level instruction set’ going to silicon, as opposed to something lower-level like RTL.

And there’s something to what you say about RISC-by-design versus simple-by-necessity: Compare a given MIPS design to the 4004, or the PDP-8. Simplicity of implementation isn’t the only criterion for being RISC.

Not that the 6600 wasn’t a sweet machine. I taught myself a lot of architecture from Thornton’s book on it, and my a senior year class project I implemented it in DEC PDP-15 asynchronous hardware modules. Lucky for me that back then you could never try to simulate the thing! I got an A, which meant that my design was correct.

[unclelem]

@si_blakely

Sun invested considerable time and money about 10 years ago into Java CPUs, that could execute JVM bytecode on silicon. The problem is that the rate of performance increase in general purpose CPUs was faster than the development cycle for specific purpose CPUs, and so by the time the Java CPUs were ready, it was faster and cheaper to use general purpose CPUs.

This is often still the case (apart from some specific spaces, like DSPs and GPUs).

Si

A GPU might be might be faster, or cheaper, but those aren’t the only factors.

Quite a few million people carry around cellphones with ARM processors that support “jazelle” - essentially a mode in which the core (CPU) executes java byte code natively. The purpose is not so much to improve performance as to reduce the power required to execute the code. On a cell phone or portable device, low power usage is king.

This is still only a language-specific CPU design (and even then it is only an operating “mode” which is part of a general purpose processor), not an OS-specific one.