<cousteau>
jrtc27: I meant harts are "the threads as used in hyperthreading", not that hart literally means "hyperthreading thread"
<cousteau>
So... basically everything that comprises a state has a replica per hart, right? So pc, registers (x1-31, f0-31), CSR, and maybe even pipeline stages and other flip-flops in the design?
<jrtc27>
technically hyperthreading is Intel's branding for the technology otherwise known more generally as SMT
<jrtc27>
everything architectural
<cousteau>
oh I see
<jrtc27>
pipeline stages are not architectural
<jrtc27>
they are microarchitectural
<cousteau>
so "multithreading" might be more appropriate
<cousteau>
oh
<cousteau>
...I still don't know what's the difference between architecture and microarchitecture
<jrtc27>
interface vs implementation
<cousteau>
interface as in specification?
<jrtc27>
interface as in what the programmer sees
<cousteau>
as in, ISA vs how it's actually implemented?
<cousteau>
I see
<jrtc27>
implementation as in how the hardware designers made it do what the specification says it should
<jrtc27>
yes
<jrtc27>
registers are IAS
<jrtc27>
*ISA
<jrtc27>
pipelines, caches, etc are not
<cousteau>
good point
<cousteau>
registers are probably mapped to "registers" as in "vectors of flip-flops" in the implementation but I guess they don't have to
<jrtc27>
exactly
<jrtc27>
you could put them in hidden DRAM if you really wanted to
<jrtc27>
most processors already lie to you by saying there is "the" x1
<jrtc27>
in reality there's a bank of flip-flops and it keeps track of which one is the current x1
<cousteau>
...actually the register file is likely to be implemented as some distributed RAM, or at least the ISA hints to a dual-port (2R+1W) implementation
<cousteau>
jrtc27: oh really? how so?
<jrtc27>
look up register renaming
<cousteau>
like, there are 31 or 32 registers, and at some point it decides that register number [24] is going to be x1, whereas x2 is going to be [15]?
<cousteau>
so like "virtual memory but at a register level"?
<dh`>
yeah except more than 32
<cousteau>
yeah I was thinking that, why only 32, could be more
<cousteau>
I guess simple implementations don't do that, though. Like the Rocket core.
<cousteau>
The BOOM core probably does...
<dh`>
basically the idea is that you have more registers than the ISA actually exhibits
<dh`>
would recommend actually looking it up, though
<cousteau>
I see, makes sense
<cousteau>
I have the wikipedia article open
<cousteau>
(oh wow, IA-64 has 128 registers?? and here I was thinking that that sort of thing tended to have few registers)
JanC_ has joined #riscv
JanC is now known as Guest340
Guest340 has quit [Killed (lithium.libera.chat (Nickname regained by services))]
JanC_ is now known as JanC
<dh`>
also, "the current x1" is a bit misleading because which register is "x1" depends on where in the pipeline you're looking
<cousteau>
got it
<cousteau>
oh wow, this IA-64 arch (which so far I had only heard of, mostly in the context of "you can refer to x86 as IA-32, but be careful not to refer to x86-64/amd64 as IA-64 because that's something else") is big...
<cousteau>
it uses the "register window" thing I studied at university (I think)
<dh`>
e.g. if I start something slow like multiply x1 into x2, the view of that instruction remains constant as it floats through, but earlier instructions will be seeing a different x2 (with the value from before I started) and other things that run later might allocate a different x1 to write into without messing me up
<dh`>
oh yeah, itanium is/was notorious
<dh`>
surprised you could have not heard about it, but I guess that happens
<gurki>
imho ia64 was a really cool idea but our compilers werent even remotely up to the task
<gurki>
would be interesting to try a similar thing with 23 tools
<gurki>
(ignoring all the other problems :p)
<cousteau>
dh`: I mean... I did hear of itanium and "ia-64", I just had no idea WHAT it was :)
<cousteau>
it's like SPARC. I know it exists but I have no idea what it is... guess I could look into it
<cousteau>
(with OpenSPARC being one of the possible contenders / inspiration for RISC-V, I'm going to guess it's a RISC architecture)
<gurki>
you need to do less guessing and more reading *runs*
<cousteau>
I just came to the same conclusion, did the reading, and realized that my guess was right, so next time I'm going to skip the reading and trust my guesses :P
<gurki>
*g
<gurki>
*
<cousteau>
(most of the time my "guesses" are actually "I already knew this, but forgot I knew it"
<cousteau>
I think Plato referred to that as "anamnesis"
* cousteau
reads the article on anamnesis
<cousteau>
wow, SPARC uses register windows too
wigyori has quit [Ping timeout: 240 seconds]
<cousteau>
Wikipedia says register windows were "one of the most influential features of the Berkeley RISC design"... but now the RISC-V doesn't use them
wigyori has joined #riscv
scruffyfurn has quit [Server closed connection]
scruffyfurn has joined #riscv
danilogondolfo has quit [Remote host closed the connection]
clandmeter has quit [Quit: Alpine Linux, the security-oriented, lightweight Linux distribution]
ncopa has quit [Quit: Alpine Linux, the security-oriented, lightweight Linux distribution]
billchenchina has quit [Ping timeout: 268 seconds]
clandmeter has joined #riscv
ncopa has joined #riscv
cousteau has quit [Quit: ♫ I can't forget the day I shot that network down ♫]
Andre_Z has quit [Quit: Leaving.]
<muurkha>
cousteau: yeah, register windows turned out to be a mistake, and the SPARC was the most widespread arch that used them. https://stackoverflow.com/a/60920481 mentions that SPARC implementors already deplored this by the 01990s
<muurkha>
21:26 < jrtc27> most processors already lie to you by saying there is "the" x1
<muurkha>
I don't think this is correct; the vast majority CPUs are simple low-performance in-order designs without register renaming, speculation, etc.
<jrtc27>
most processors *that you will deal with* then
<jrtc27>
fine
<jrtc27>
clearly I'm not talking about some tiny Cortex M0
<muurkha>
I would agree with "all current high-performance processors", I just think that's a small minority of processors, maybe 5%
<drmpeg>
i960 also used register windows.
<muurkha>
drmpeg: oh neat, I didn't know that
<muurkha>
jrtc27: I've spent a lot of time dealing with tiny in-order Atom and Cortex-M and Cortex-R processors
<muurkha>
even in recent years
<jrtc27>
I'm willing to bet Atom cores have at least some form of register renaming
<muurkha>
oddly WP says the opposite about Bonnell
<muurkha>
"This enables relatively good performance with only two integer ALUs, and without any instruction reordering, speculative execution, or register renaming. The Bonnell microarchitecture therefore represents a partial revival of the principles used in earlier Intel designs such as P5 and the i486, with the sole purpose of enhancing the performance per watt ratio."
<muurkha>
but later "Atom" microarchitectures probably did
<muurkha>
I saw a lovely plot the other day in some lecture slides about the, uh, OR10N?
<muurkha>
it claims in-order single-issue execution is significantly more energy-efficient than any of the alternatives up to about 750MIPS
<muurkha>
and most of the rest of the slides are about some ungodly hacks they bolted onto OpenRISC to reduce the performance penalty of in-order single-issue execution to goose the speed of their cluster-on-a-chip
<muurkha>
that plot is from 13 years ago, so I don't know if it's still correct or ever really was
<muurkha>
but it does seem to be true that most processors slower than that are still in-order even today
<dh`>
the sparc t1/t2 (aka niagara) were based on that premise and it didn't really pan out
pecastro has quit [Ping timeout: 246 seconds]
<dh`>
although by that point, like with DEC and late alphas, it was probably too late commercially
pecastro has joined #riscv
Leopold has quit [Ping timeout: 255 seconds]
<muurkha>
which premise, the premise that for power efficiency you want lots of small simple cores rather than a big one full of speculation and reordering?