Michael S (already5chosen.delete@this.yahoo.com) on July 26, 2020 10:00 am wrote:
> Heikki Kultala (heikki.kult.ala.delete@this.gmail.com) on July 26, 2020 7:49 am wrote:
> > Brett (ggtgp.delete@this.yahoo.com) on July 25, 2020 2:16 pm wrote:
> > > dmcq (dmcq.delete@this.fano.co.uk) on July 25, 2020 7:58 am wrote:
> > > > ⚛ (0xe2.0x9a.0x9b.delete@this.gmail.com) on July 24, 2020 4:24 pm wrote:
> > > > > Chester (lamchester.delete@this.gmail.com) on July 24, 2020 3:59 pm wrote:
> > > > > > ⚛ (0xe2.0x9a.0x9b.delete@this.gmail.com) on July 24, 2020 12:56 pm wrote:
> > > > > > > Linus Torvalds (torvalds.delete@this.linux-foundation.org) on July 12, 2020 11:35 am wrote:
> > > > > > > > Because this forum is about architecture design and implementation, isn't it? So I think
> > > > > > > > it's very fair to put down that gauntlet: AVX512 vs SVE2. "Gong plays" - FIGHT!
> > > > > > > >
> > > > > > > > Linus
> > > > > > >
> > > > > > > The number and size of registers in all current CPUs are heavily influenced by the fact
> > > > > > > that those CPU architectures started in years when transistors were a scarce resource.
> > > > > > >
> > > > > > > Today, with the number of transistors in a single chip being counted
> > > > > > > in billions, the following CPU architecture is possible:
> > > > > > >
> > > > > > > - No integer register and no floating-point registers
> > > > > > >
> > > > > > > - 64K (65536 bytes) of local memory per core
> > > > > > >
> > > > > > > - No explicit SIMD instructions: All SIMD instructions are just macro instructions,
> > > > > > > i.e. just special sequences/tuples of normal instructions
> > > > > > >
> > > > > > > So, instead of the following x86 instructions:
> > > > > > >
> > > > > > > MULSD xmm1,xmm2/m64
> > > > > > > MULPD xmm1, xmm2/m128
> > > > > > > VMULPD ymm1, ymm2, ymm3/m256
> > > > > > > VMULPD zmm1, zmm2, zmm3/m512
> > > > > > >
> > > > > > > you can have a CPU with almost-infinite scalability, fully backward compatible and
> > > > > > > fully forward compatible, based on just recognizing tuples of scalar instructions:
> > > > > > >
> > > > > > > 0064: MULD x1, x2/m64
> > > > > > > 0128: MULD x1, x2/m64; MULD x1+8, x2/m64+8
> > > > > > > 0256: MULD x1, x2/m64; 2*MULD ...; MULD x1+24, x2/m64+24
> > > > > > > 0512: MULD x1, x2/m64; 6*MULD ...; MULD x1+56, x2/m64+56
> > > > > > > 1024: MULD x1, x2/m64; 14*MULD ...; MULD x1+120, x2/m64+120
> > > > > > >
> > > > > > > where 'xN' means an operand N located in local per-core memory starting from the
> > > > > > > byte-offset (in some cases: from the bit-offset) specified in the instruction.
> > > > > >
> > > > > > You want every instruction to reference memory? Even today, we're looking at dual/triple ported L1D caches
> > > > > > with 3-5 cycle load-to-use latencies. Compare that with a 9-ported or whatever register file....
> > > > > >
> > > > > > Yup, decades on and the top part of the memory hierarchy still matters. You want to keep
> > > > > > stuff in regs as much as possible. Also, just look at a die photo and see how much area
> > > > > > registers take compared to the L1D, and how little capacity the register files have.
> > > > >
> > > > > AVX-512 is 32*512 = 16384 bits = 2 KiB. OK, 64K is 32 times more
> > > > > than 2K, but still, how is 64K fundamentally different from 2K?
> > > > >
> > > > > If the 64K memory per core CPU is targeting (is optimized
> > > > > for) workloads with 32-bit or 64-bit pointer size then
> > > > > the design has to divide the 64K into 4- or 8-byte units,
> > > > > so in fact the per-core memory would as such (alone)
> > > > > be theoretically capable of handling 64K/4=16K or 64K/8=8K
> > > > > non-overlapping aligned concurrent accesses per clock.
> > > > > From the 16K or 8K theoretical, only a small number is selected by instructions each clock cycle.
> > > > >
> > > > > Using the 64-byte cacheline of current L1D/L2/L3 caches in the 64K per-core memory would be a huge mistake.
> > > > >
> > > > > If you have problems imagining this running at 5 GHz, then please imagine it running at
> > > > > about 2 GHz. So assume a GPU-like frequency rather than a CPU-like operating frequency.
> > > > >
> > > > > -atom
> > > >
> > > > One would have to avoid store type access or the checking would be horrible. And one would
> > > > be led back to small register files to deal with loops properly. I think I far far prefer
> > > > Ivan Godard's Mill with no registers at all than this huge mess of store/registers.
> > >
> > > The belt is a register file, the register names just happen to loop.
> > > Most of the rest of the architecture is the same as any other CPU, like L1 cache, MMU, etc.
> > > Learn more before posting.
> >
> > No, it's not.
> >
> > The belt consist of registers at the FU outputs. There is no single "belt register file".
> >
> > Learn more before posting.
> >
>
> Since Ivan didn't publish RTL and has no intention to ever publish RTL, there is nothing to learn.
> Brett's interpretation is as good as yours.

Heikki is correct.
There is a single virtual belt that points at the registers in all the functional units.
But that is a confusing thing to tell people, most won’t understand.
A software guy like me does not really need to know these details.

It’s best to look at it from the one ALU Mill case with the H&P book open to the pipelining chapter to understand what is going on. The five instruction loop case fits in the bypass registers. Mill has lots of ALU’s so lots of these registers.

Getting rid of the conventional register file enables Mill to go super wide and cuts the die space needed considerably. Downside is that Mill is in-order which will hurt perhaps not as much as one thinks with good prefetch.
Mill also has cheap function calls and a few other advantages.
Mill is a better design that can do more work with fewer transistors.

RISC is second best, but second best always seems to win.
After the patents expire plus half a decade I expect the industry to start switching to Mill.

Prediction:
Apple will be first due to the big bucks in compiler support needed.
Microsoft will copy Apple, because that’s what Microsoft does. ;)
Google will also copy Apple, same reason. ;)