freakazoid333 has quit [Read error: Connection reset by peer]
jwillikers has quit [Remote host closed the connection]
davidlt has joined #riscv
jamtorus has quit [Quit: jamtorus]
davidlt has quit [Ping timeout: 246 seconds]
jellydonut has joined #riscv
riff-IRC has quit [Remote host closed the connection]
riff-IRC has joined #riscv
davidlt has joined #riscv
gioyik has quit [Quit: WeeChat 3.1]
smaeul_ has joined #riscv
smaeul has quit [Read error: Connection reset by peer]
Bigcheese has quit [Ping timeout: 268 seconds]
Bigcheese has joined #riscv
crabbedhaloablut has quit [Ping timeout: 244 seconds]
crabbedhaloablut has joined #riscv
gktrk has joined #riscv
gktrk has quit [Client Quit]
gktrk has joined #riscv
gktrk has quit [Client Quit]
gktrk has joined #riscv
rhett has joined #riscv
rhett has quit [Excess Flood]
hendursa1 has joined #riscv
hendursaga has quit [Ping timeout: 244 seconds]
winterflaw has joined #riscv
jeancf_ has joined #riscv
winterflaw has quit [Remote host closed the connection]
pecastro has joined #riscv
pecastro_ has joined #riscv
somlo has quit [Read error: Connection reset by peer]
somlo has joined #riscv
jamtorus has joined #riscv
jellydonut has quit [Read error: Connection reset by peer]
winterflaw has joined #riscv
winterflaw has quit [Quit: Leaving]
valentin has joined #riscv
cousteau has joined #riscv
<cousteau>
Hi
<cousteau>
Out of curiosity, about how many different instructions (including different parameter combinations) are there in RV64G
<cousteau>
?
<cousteau>
I know it's less than 2^30 (probably much less), but I have no idea how much less. I.e., how "dense" is the instruction space
<cousteau>
Or in RV32G?
<cousteau>
Quick googling says that RV32G has 122 instructions (≈2^7), but going from that to the absolute total can be tricky...
<cousteau>
Come to think of it, IIRC there are 2 instructions that take a 20-bit immediate, so that's at least >2^21 instructions (but it kinda feels like cheating)
winterflaw has joined #riscv
<cousteau>
And a few other opcodes such as OP-IMM are also at nearly 100% usage
jeancf_ has quit [Ping timeout: 240 seconds]
peepsalot has quit [Ping timeout: 252 seconds]
<cousteau>
Wait no, the 20-bit immediates also include a 5-bit register number, so 2^25
<enthusi>
you mean valid 4byte arrays rather than 'instructions' ?
<cousteau>
Yeah basically
<cousteau>
After seeing the list in chapter 19 (of what I just realized is a very old revision of the standard, stupid Google...) I got about 2^27.70 for RV32I
<cousteau>
All this is because I wanted to make an idea of the "complexity" of the instruction set
jamtorus has quit [Quit: jamtorus]
<cousteau>
Including all the F/D crazy instructions it grows to 2^28.12 approx
jellydonut has joined #riscv
<cousteau>
So yeah, about 300 million instructions. Not bad. I wonder how many ARM has, considering it reserves 4 bits for conditional execution.
<rjek>
I think they've reused all the NV space too
<rjek>
Aarch64 doesn't have the condition field on every instruction anymore too
<cousteau>
Oh, well, seems they're growing out of it
<cousteau>
I've always wondered how an "average" RISC-V compares to a similarly-sized ARM
<rjek>
it made speculative and out of order execution too tricky
<rjek>
A joy to program by hand, but who does that anymore? :D
<cousteau>
Yeah, iirc the whole point of those execution conditions was to compensate for the lack of fancy pipeline features
<cousteau>
Branch prediction, I guess ooo execution too...
<rjek>
IIRC, it was that the instruction set was designed by a programmer, not a hardware engineer :)
<cousteau>
RISC-V seems to be designed by... both?
<rjek>
heh
<rjek>
ARM's conditional execution *does* make for very tight code that can avoid pipeline flushes though
<cousteau>
Since it has all these potentially beneficial hardware tricks, like the "bit salad" in some instruction types, but it also optimized the instruction set to "modern programming languages and features" (such as "nobody uses ALU flags anymore")
<rjek>
the free barrel shifter was wonderful
<cousteau>
Anyway, I've always wanted to see how these two compare. I suspect that RISC-V might be able to reach higher clock frequencies, for example
<cousteau>
rjek: do you mean the fact that "bit shifting" is just routing wires when it comes to digital design?
<rjek>
yep
<cousteau>
Yeah that's a nice thing
<rjek>
the instruction decoder programs the barrel shifter, and it's directly in the data path
<cousteau>
It's not 100% free though, but iirc the instruction decoder for the immediate word would need what, a 4-input mux at most?
<winterflaw>
Shame. Be amazing for large-scale simulation games.
<xentrac>
wouldn't make a difference
<winterflaw>
you could use long double rather than double, for the co-ordinate system
<xentrac>
if you want wide vector operations you can use the V extension
<winterflaw>
how wide are we talking?
<xentrac>
arbitrarily wide
<winterflaw>
no free lunches
<winterflaw>
what happens to performance?
<winterflaw>
once you exceed register width you must take a big hit?
<xentrac>
it remains constant on a given processor, but increases linearly on processors with wider vector units
<winterflaw>
although I'm getting close to being out of my depth now :-)
<sorear>
128-bit riscv is specifically oriented toward *pointers*, for systems with more than 8 EiB of (virtual) memory
<xentrac>
yeah. and I don't think that makes sense
<sorear>
you don't need it for 128-bit doubles and it's only marginally useful for 128-bit integers
<winterflaw>
actually the next problem is compiler support
<winterflaw>
but anyways
<winterflaw>
not useful at the current time
<xentrac>
computer word size has varied from 6 bits to 64 bits since IBM delivered Stretch, which was probably the first 64-bit computer, in 01961
<xentrac>
the CDC 6600 shipped in 01964 with a 60-bit word length
<winterflaw>
full 64-bit? or only for registers and not busses?
<sorear>
most modern application cores have >64 bit buses, that's not what people generally mean
<xentrac>
pretty sure Stretch used 64-bit buses too
<xentrac>
it didn't have a 64-bit address space though
<winterflaw>
I was thinking of earlier stuff like the 68000
<xentrac>
the 68000 didn't have just 16-bit buses, it had a 16-bit ALU too
<xentrac>
there have been lots and lots of computers with 1-bit ALUs
<xentrac>
anyway the mainstream move to 64-bit words in 02004 came about because of memory address space limitations
<sorear>
360 has always had family members with different internal bus and ALU widths
<winterflaw>
huh
<winterflaw>
there was a 68012
<winterflaw>
I never knew
<sorear>
but the pointer-holding registers were 32 bits, and more than half of that was used, until z/arch came out this millenium
<xentrac>
I think until S/370 only 24 bits were significant, much like the 68000
<sorear>
i don't think that's a very interesting feature (see "more than half" above)
<xentrac>
it was common in the 01960s and 01970s for a machine word to hold two memory addresses
<xentrac>
right, but I mean the choice of 32-bit architectural registers for the 360 (rather than 24) wasn't motivated by memory address space limitations the way the move to amd64 was
<sorear>
i doubt 24-bit was ever on the table given how oriented it is toward powers of 2
<sorear>
and 16-bit could have been ruled out for address space reasons
<xentrac>
a lot of IBM's previous machines had non-power-of-2 word sizes
<sorear>
yes, which is why the 360's focus on 8/16/32/64 bit operations is so notable
<xentrac>
and the CDC 6600, which was the machine to beat, also did
<xentrac>
anyway, 2⁶⁴ bytes is 2²⁴ tebibytes or 2¹⁴ pebibytes. and Moore's Law is dead, so planar silicon memory density is not going to keep doubling every 18 months
Thalheim has quit [Remote host closed the connection]
<xentrac>
so even if SASOSes catch on, which they probably won't, more-than-64-bit addressing seems likely not to be useful until we find a different way to make computers
Tranmi has quit [Quit: Leaving]
choozy has joined #riscv
freakazoid333 has quit [Read error: Connection reset by peer]
freakazoid333 has joined #riscv
<sorear>
2^63 bytes of NAND is about a tonne, the prohibitive factor here is only mfg cost
<xentrac>
Oh, absolutely!
<xentrac>
Although if you're doing a computation over 2⁶³ bytes of data, at present you would probably want to split the computation into multiple cores (so it doesn't take 2⁶³ ns, a few centuries), at which point sharding the data itself among the cores starts to become very attractive too, and then unless you're using a SASOS you're still going to be fine with 64-bit addressing
<sorear>
obviously it's NUMA but there are pros and cons to uniform naming of data regardless of topology
<sorear>
and the gap between communication costs in current computers and communication costs in current lab equipment is conspicuously high, compared to computation or data storage
<xentrac>
hm? lab equipment?
<winterflaw>
I've found NUMA to be a headache, generally. I understand why it's there, and I'm fine with it, but it's extra stuff to deal with. Also if I remember correctly there's no NUMA aware shared memory allocator in Linux.
<xentrac>
I guess my thought is that once you have multiple worker processes on multiple nodes sending messages back and forth, the things they put in those messages probably can refer to data at a larger granularity than a byte except in very rare cases
davidlt has quit [Ping timeout: 258 seconds]
Andre_H has quit [Ping timeout: 252 seconds]
winterflaw has quit [Remote host closed the connection]
winterflaw has joined #riscv
mhorne has quit [Ping timeout: 240 seconds]
mahmutov has joined #riscv
jimwilson has quit [Read error: Connection reset by peer]
jimwilson has joined #riscv
freakazoid333 has quit [Read error: Connection reset by peer]