4 ms·

Oh I just meant that the CPU might have a 64 bit interface and address space, but be 32 bit or less internally. Mostly the microcode would provide the emulation

Oh I just meant that the CPU might have a 64 bit interface and address space, but be 32 bit or less internally. Mostly the microcode would provide the emulation, but maybe a few instructions like 64 bit multiply would have dedicated hardware. If that turns out to be the bulk of the hardware needed in the first place, then maybe my idea wouldn't work. Maybe a hybrid design, half the transistors for a 5% performance loss or something. Ya I agree, ISA is kind of an antiquated concept. Intel chips basically emulate x86 instructions in microcode today, as a glaring example.

SV_BubbleTime 5y ago
Or… just use 64bit through out? I’m not following what you are trying to save by adding a mixed system and emulation. I can’t imagine dropping 64bit to pump cores up.
- zackmorris 5y ago
  Sorry, I'm coming at this from a pretty low level. Things like ALUs sometimes use lookup tables to do things like N bit multiply, instead of carrying bits serially like in a 1 bit handheld calculator. But there are fundamental limits to that where maybe there just isn't transistor budget to multiply more than 8 or 16 bits or something. Or there are propagation delay issues where the circuit just can't get any faster, so instructions must be pipelined to approach something like 1 instruction per cycle. So it really depends on the architecture. Sometimes it makes sense to have "native" 64 bit math, and sometimes it makes sense to compose a 64 bit operation from many 8/16/32 bit operations. In this case, I would opt for using as few transistors as possible per-core in order to fit more cores on the chip. Then expose a 64 bit architecture, but implement that as 8/16/32 bit software loops in the microcode. So maybe a multiply might take 2 or 4 or 8 cycles or something instead of 1. In practice superscalar architecture, pipelining, caching, even hyper-threading, can hide much of that because processors today usually run dozens or even hundreds of times faster than main memory. So I highly doubt that chips today actually implement every single 64 bit instruction in hardware. Granted, my knowledge around this is over 20 years old, but it comes from studying stuff like MIPS processors, so is about as fundamental as it gets. And single-threaded performance has only roughly tripled since the 90s. My guess is that they use more lookup tables now since transistors are basically free. At the cost of never going back and checking how effectively they're using their transistor budget for actual computation, which results in the CPUs we have today that run many thousands of times slower than they could. We see this in how GPUs absolutely dwarf the performance of CPUs.
rbanffy 5y ago
I have the impression reorder buffers took a huge amount of space, specially in irregularly sized ISAs like x86. Simplifying the ISA could free up a lot of space for 64-bit multiply units.

SV_BubbleTime 5y ago

Or… just use 64bit through out? I’m not following what you are trying to save by adding a mixed system and emulation. I can’t imagine dropping 64bit to pump cores up.

zackmorris 5y ago
Sorry, I'm coming at this from a pretty low level. Things like ALUs sometimes use lookup tables to do things like N bit multiply, instead of carrying bits serially like in a 1 bit handheld calculator. But there are fundamental limits to that where maybe there just isn't transistor budget to multiply more than 8 or 16 bits or something. Or there are propagation delay issues where the circuit just can't get any faster, so instructions must be pipelined to approach something like 1 instruction per cycle. So it really depends on the architecture. Sometimes it makes sense to have "native" 64 bit math, and sometimes it makes sense to compose a 64 bit operation from many 8/16/32 bit operations. In this case, I would opt for using as few transistors as possible per-core in order to fit more cores on the chip. Then expose a 64 bit architecture, but implement that as 8/16/32 bit software loops in the microcode. So maybe a multiply might take 2 or 4 or 8 cycles or something instead of 1. In practice superscalar architecture, pipelining, caching, even hyper-threading, can hide much of that because processors today usually run dozens or even hundreds of times faster than main memory. So I highly doubt that chips today actually implement every single 64 bit instruction in hardware. Granted, my knowledge around this is over 20 years old, but it comes from studying stuff like MIPS processors, so is about as fundamental as it gets. And single-threaded performance has only roughly tripled since the 90s. My guess is that they use more lookup tables now since transistors are basically free. At the cost of never going back and checking how effectively they're using their transistor budget for actual computation, which results in the CPUs we have today that run many thousands of times slower than they could. We see this in how GPUs absolutely dwarf the performance of CPUs.

rbanffy 5y ago

I have the impression reorder buffers took a huge amount of space, specially in irregularly sized ISAs like x86. Simplifying the ISA could free up a lot of space for 64-bit multiply units.