cwebber has quit [Read error: Connection reset by peer]
<sorear>
bluefox: flipping funct3[0] always inverts the result of the comparison, EQ becomes NE, LTU becomes GEU, etc
cwebber has joined #riscv
hendursaga has joined #riscv
greaser|q has quit [Changing host]
greaser|q has joined #riscv
greaser|q is now known as GreaseMonkey
vagrantc has joined #riscv
<solrize>
are there any good benchmarks for GMP or something similar on riscv?
<GreaseMonkey>
BGE: x=0 means a subtraction overflows/carries, x=1 means this does not happen
<GreaseMonkey>
BEQ: x=0 means a subtraction returns zero, x=1 means it doesn't
<GreaseMonkey>
if you're looking for your consistency, there it is as far as i can tel
<GreaseMonkey>
l
<sorear>
pro tip: BGEU is the same as BGE if you invert bit 31/63 of both inputs
<GreaseMonkey>
neat
<GreaseMonkey>
having written emulators for various CPUs i've always found overflow to be the annoying thing to work out
davidlt has quit [Ping timeout: 268 seconds]
<xentrac>
RISC-V sure is nice on that count
<GreaseMonkey>
RISC-V is nice as long as you don't have to deal with the C extension
<jrtc27>
C isn't that awkward
<jrtc27>
it's not much additional fetch complexity
<jrtc27>
and decode is just a bunch of decompression combinatorial logic
<jrtc27>
the encodings aren't as clean but who cares
<xentrac>
emulator authors
<xentrac>
probably
<GreaseMonkey>
the encodings are what's nasty about it
<GreaseMonkey>
it's the sort where you'd opt for a 256 KB lookup table to convert all the C ops to their uncompressed equivalents
<xentrac>
too bad current CPUs don't have a few FPGA slices you can set up with the decompression combinational logic
<GreaseMonkey>
even though you'd have 64 KB wasted unless you really want to save it for extra computational cost
<sorear>
use MIPS if you care about being able to extract opcodes and immediates with one shift
<bluefox>
sorear, interesting. What's confusing me is funct3[0] = 0 when the two terms are equal
<bluefox>
except, funct3[0] = 1 when checking if the two terms are equal if also checking if the one is greater than the other
<bluefox>
so 0 seems to mean "only equal or greater than and not equal" and 1 seems to mean "not equal or greater than and equal" depending on the other values of funct3
<sorear>
the funct3[2] = 1 cases aren’t zero tests at all, they’re carry tests
<bluefox>
ah
<bluefox>
so there's a hardware implementation where the circuit to check this is simpler this way than the other
<bluefox>
The decoder for RVI/M/A is ridiculously simple and everything is totally uniform, although I'm still trying to pick apart how I'm to interpret the relationship between LUI/AUIPC/JAL/JALR and their instructions
<jrtc27>
what's JALR doing there?
<jrtc27>
it's not a U/J-type
<bluefox>
first 4 functions in the table
<bluefox>
*mnemonics whatever instructions
<bluefox>
I have stuff like load store LD/ST: XXXXXXX XXXXX XXXXX uhw XXXXX 0s00f11 u=upper h=half w=word hw=64-bit (hw=00=byte, hw=10=2x byte, hw=10=4x byte, hw=11=8x byte)
<jrtc27>
everywhere else that's a 3 bit log2(size)
<jrtc27>
but ld has to handle both signed and unsigned so one of the bits is stolen
<bluefox>
unsigned yeah
<xentrac>
:(
<jrtc27>
stores, atomics, floating-point loads and floating-point stores all just have a 3-bit width
<bluefox>
my point is the decoder is like…just pick a couple bits out, and make a decision on what kind of insn I'm looking at, and send it forward, let the pipeline ignore the bits that don't apply to the type of instruction I'm decoding
<jrtc27>
sure
<bluefox>
but I'm thinking of the BGE/BGEU as an OR between a greater/equal check
<bluefox>
so I expected funct3[0] to be the same as BEQ for those, but it's not. I must be thinking about how to do this the wrong way.
<jrtc27>
BGE is just BNLT
<bluefox>
ah.
<jrtc27>
EQ, LT and LTU are your primitives
<jrtc27>
and funct3[0] is XOR'ed with the result
<jrtc27>
(/ conditionally inverted, whichever way you like to think of it)
<bluefox>
Okay. My brain was starting to go down the rabbit hole of adding/subtracting everything that goes in the ALU and doing a carry test or whatnot to figure out all these relationships
<bluefox>
OH
<bluefox>
That makes sense. If I subtract one thing from the other, I get a carry bit if one's less. That's what sorear means.
<bluefox>
I guess the only way to do an equality check is to subtract rs2 from rs1 and then OR together every bit of output
<xentrac>
sometimes xor has a shorter path length than subtraction, but in a synchronous design that probably doesn't matter unless you have a useful way to split subtraction across multiple pipeline stages
<xentrac>
since you need subtraction anyway
<bluefox>
...that still gets me XORing with ~funct3[0] (the result is is 0, OR all the bits together gives 0, funct3[0] is 0). I don't know how I'm intended to test equality then?
<bluefox>
xentrac: yeah, I figure my decoder can flag the subtract operation if I detect I'm decoding a branch, simplest way
<xentrac>
sounds legit
<bluefox>
ALU will do the subtraction because there's nothing else to do with the adder at that time, and then use the result to figure out the equalities
<bluefox>
subtraction is weird. I simply XOR every incoming bit of one addend with the SUB bit, and set the carry-in to the SUB bit as well
<bluefox>
anyway, that helps things make sense.
<xentrac>
heh, nice. I'd never tried implementing an adder-subtractor but that makes a lot of sense
<bluefox>
Yeah, my first pass trying to shove this stuff in my head at dangerous rate of learning (I have burned out multiple times doing that, you CAN injure yourself that way), I implemented a speculative hans-carlson adder just for fun.
<bluefox>
the FPGA's fabric adder is faster than mine probably
<xentrac>
(although if you're doing this in actual gates rather than LUTs, keep in mind that XOR itself has a longer propagation delay than fundamental operations)
<bluefox>
true. Isn't everything basically just NAND gates?
<xentrac>
neat, han-carlson adders sound like a promising new avenue for timing side-channel attacks
<bluefox>
eh. not so useful.
<bluefox>
It's a really fast parallel prefix adder, but also you can USUALLY skip the last stage
<bluefox>
the error detection for this is substantially faster than the last stage
<xentrac>
you can do everything with just nand gates, but for example it's easier to build a cmos nor gate directly than to build one out of nands
<xentrac>
and iirc there are even things like aoi and half-adders that are faster than the nand-based equivalent
<bluefox>
so like something like one in 10^-6 adds ends up coming out wrong, and the rest complete faster than usual
<bluefox>
the error check signal becomes a stall, and you wait the next cycle for the propagation to finish and switch over to that output instead
<xentrac>
and old chips used to use pass transistor logic a fair bit because the bits passing through the pass transistor channel don't have to wait for the gate capacitance to charge or discharge
<bluefox>
which is nice, but probably more for specialized circuitry, because as I understand it's unlikely your adder is your critical path
<bluefox>
AOI?
<xentrac>
and-or-invert
<bluefox>
ah
<xentrac>
and also a couple of pass transistors is usually a lot smaller than a mux or aoi made of nands, and if you're doing dynamic logic tricks you can use even a single pass transistor usefully
<bluefox>
neat.
<xentrac>
uncommon data-dependent stalls in your adder sound like a brilliant, shingin new avenue for timing side-channel attacks
<xentrac>
*shining
<xentrac>
it's pretty common for adders to be your critical path actually
<bluefox>
Maybe. It depends on how well you can control the data and how much it matters if you can.
<bluefox>
like, in voting theory, we look for ways to manipulate elections
<bluefox>
somebody wrote a research paper on manipulating single transferable vote by tactical voting
<bluefox>
Their conclusions were that you need an enormous amount of information to do so, i.e. you need to know almost all the ballots actually cast in full by all the voters
<bluefox>
and even if you did, finding a voting pattern that successfully manipulates the outcome is NP-complete
<xentrac>
you might not have to control the data; if being able to observe a single stall leaks 20 bits of secret data, that may be enough to bring a brute-force keyspace search within range
<bluefox>
You might be able to get information out of an adder's occasional speculative stall, but if you can't create the conditions or know the information necessary to interpret it, it's not useful for information leaking
<xentrac>
that's the same kind of optimistic reasoning we used to use 30 years ago to explain why buffer overflows weren't really a security concern
<bluefox>
branch prediction and cache timing attacks work so well because by their very nature they cause timing issues constantly, and so it's trivial to manipulate those issues
<bluefox>
30 years ago people were saying 8 character passwords were enough because windows broke a password into 7 and 7
<bluefox>
there are 53 different symbols LM hash stores. You could MEMORIZE the rainbow table for that.
<xentrac>
8 character passwords are still enough if you're not using a broken hash ;)
<bluefox>
your 8 character password was a 7 character password. How nobody saw this is beyond me
<bluefox>
same with buffer overflows tbh.
<xentrac>
there was a manager at microsoft in the late 1990s who posted to bugtraq that you shouldn't expose windows machines to a hostile network
<bluefox>
Like, you know a buffer can be overflowed. First question is what can you do with it? You know there's stuff on the stack to control program flow. You know you can guess the stack location pretty reliably if you know the OS. You know you can spam an instruction that does nothing, then a small piece of code, so you can definitely get code executing
<xentrac>
anyway, the buffer overflow optimism was wrong in retrospect, and "You might be able to get information out of an adder's occasional speculative stall, but if you can't create the conditions or know the information necessary to interpret it, it's not useful for information leaking" is the same kind of optimism
<bluefox>
at first glance it looks complicated, but so does everything. What information do you have, and how can you leverage that? If you don't know, write it down and wait; you'll find more information later.
<xentrac>
well *now* we know all that stuff
<bluefox>
I mean in a more fundamental way
<bluefox>
you saw the leaked NSA exploits?
<bluefox>
they all relied on useless and trivial information leaks
<xentrac>
no, I haven't looked at them at all, actually
<bluefox>
the problem is once you have 6 different things leaking different types of useless information, it turns out you have…a complete set of USEFUL information
<bluefox>
"X is useful if I have Y" means find a way to get your hands on Y
<bluefox>
anyway
<xentrac>
in 01991 most people hadn't thought of the possibility of pointing the stack frame's return address into the stack itself, and even if you pointed out that this was possible and in fact not far from a thing that GCC did routinely, they would be (a) astounded that GCC would do such a thing and (b) incredulous that you could get such a thing to work at all since you'd have to know the exact stack layout
<bluefox>
there are more interesting things in the world
<xentrac>
I don't remember if Morris's 01988 buffer-overflowing worm even used nop sleds
<bluefox>
oh man, wasn't that his second one?
<bluefox>
I thought the first one was just that fingerd worked by sending it a command and it returned the output
<xentrac>
I think the fingerd channel used a gets() buffer overflow; it was sendmail that let you pipe email to a shell command
<xentrac>
(if debug mode was on)
<xentrac>
oh, but it turns out the thing Morris was overwriting with the buffer overflow was actually a shell command, not the return address, so you were right that you could send fingerd a command
<sorear>
EQ is just the (carry propagate AND NOT carry generate) output from a subtract
<xentrac>
but that wasn't the normal way to use fingerd :)
<bluefox>
I'm still slightly confused about out-of-order superscalar architecture
<bluefox>
specifically that on RV it looks like if I have an instruction pending on a read from a register that's waiting to be written by an earlier instruction, that instruction stalls until the write completes, but I can run another instruction
zjason has quit [Read error: Connection reset by peer]
<sorear>
imagine turning code back into single static assignment form
<bluefox>
and if I have an instruction trying to write over a pending write, I know that all instructions between the prior write and mine which depend on a write to that register are waiting on that value
zjason has joined #riscv
<bluefox>
I can easily just rename registers each time they're written, and free them up (and store the index into a fifo of some sort) as instructions retire
<bluefox>
and bam: superscalar out-of-order execution.
<bluefox>
…it can't be that easy.
<bluefox>
but I'm out of conditions that can occur that I haven't addressed
<jrtc27>
yes, that is the basic idea behind OoO
<jrtc27>
or even some higher-end in-order cores
<bluefox>
yeah. It's probably much more complicated when you start speculating
<jrtc27>
you have to be careful about implicit dependencies like CSRs
<jrtc27>
and memory
<sorear>
it’s not that any part of it is difficult, there are just a lot of cases and possible interactions to get right
<bluefox>
the RVIM instructions in user mode don't look like they depend implicitly on CSRs?
<jrtc27>
JAL and JALR depend on misa.C
<bluefox>
fair enough
<bluefox>
there's always the cheap way
<jrtc27>
instruction fetch is of course dependent on satp and pmp*
<jrtc27>
and loads/stores similarly
<sorear>
and XLEN/BE if you make any of that writeable
<bluefox>
the conditions in which these things change sound relatively rare or non-deterministic
<jrtc27>
those kinds of things can generally be full pipeline flushes
<jrtc27>
ie you don't express the dependency
<jrtc27>
you just treat the CSR write in the same way as an exception
<sorear>
generally it’s designed so you can make all CSR writes (other than fflags) full barriers and not lose too much
<bluefox>
yeah
<bluefox>
that's what I was thinking: the OS can't change the CSRs without a context switch, and if it can it can't change them in any way it can actually precisely plan
<sorear>
this does add a few dozen cycles to syscalls but few care these days
<bluefox>
so the easy solution is to not try to squeeze out a 0.001% performance gain and just barrier around those instructions when they occur?
<sorear>
yes
<bluefox>
Probably a win all around then
<bluefox>
because the extra logic would likely slow down your clock rate or create longer pipelines and cost more in exceptions anyway
<dh`>
extending renaming to certain CSRs is probably not that hard
<jrtc27>
fflags likely wants renaming
<jrtc27>
most other things, meh, who cares
<jrtc27>
though for most you could just implement the barrier as stalling the next instructions in rename
<dh`>
for ones that actually control stuff it's hard, but things like sscratch and sepc
<jrtc27>
rather than actually flushing
<sorear>
you don’t need to rename fflags because it’s commutative
<bluefox>
mmh.
<bluefox>
I read something where people set up 16 separate soft CPUs on an FPGA, and used an external FPU that was connected to all of them
<bluefox>
they saw a 2% performance drop
<jrtc27>
yeah fflags you can actually just do in commit
<bluefox>
I don't imagine floating point math is all that common either, but it probably comes in tight loops
<jrtc27>
so long as you handle the explicit csr read properly
<dh`>
how common it is depends on your workload
<bluefox>
so less the occasional hickup in the instruction stream as "if you make this slow, you will have the occasional SLOOOOOOOOOOOOOOOOOOW"
<jrtc27>
depends what score you want on SPECfp :)
<xentrac>
floating-point math varies between "the entire reason I have a computer" to "not even implemented"
<bluefox>
dh` in some video games, there are almost 100% integer instructions, and the occasional decimal computation for things like character acceleration, gravity, or sub-pixel position tracking
<xentrac>
and it's common for people who care a lot about floating-point math to unroll their loops fwiw
<xentrac>
sure, if you mean like Space Invaders
<bluefox>
I imagine in sound processing and mixing and such with e.g. VST plugins there's a lot of floating point going on
<bluefox>
in fact, I know there are fixed-point math libraries for various lossy decoders
<xentrac>
but things like Counterstrike are almost entirely floating-point
<bluefox>
specifically because they're usually floating-point math and it doesn't run on things that have no FPU
<xentrac>
DSP pretty commonly uses fixed point, yeah. although once you start doing FFTs you start to really want floating point
<xentrac>
this division between 99%-integer applications and 99%-floating-point applications goes back to the 01940s; Zuse's early machines were entirely floating-point, for example
<xentrac>
in the 01950s and early 01960s it was "business" vs. "scientific": "business" computers were for processing characters and decimal accounting math and had byte-addressable memory, while "scientific" computers were designed for floating-point and just about only included integer math because it's useful for array indexing, and their memories were typically word-addressable
<xentrac>
the IBM 360 was an effort to unify these two kinds of computers, thus the name (360°)
<bluefox>
(Oddly enough, I hear Sega created the Sonic series because their sales pitch amounted to having faster screen scrolling for high-paced and exciting games)
dilfridge is now known as zoombie
<xentrac>
fixed-point math libraries for lossy decoders are largely intended for things like MP3 players without floating-point hardware
zoombie is now known as dionysos
<bluefox>
IBoxM 360
dionysos is now known as ENOTIME
<xentrac>
today the "business" and "scientific" division has sort of resurfaced: CPUs are "business", though they have floating-point hardware, and GPUs are "scientific"
ENOTIME is now known as iznogoud
iznogoud is now known as helium-3
<bluefox>
Interesting.
helium-3 is now known as dionysos
<xentrac>
they're not called that, of course
<bluefox>
I met someone once who had Intel get an engineer on a plane, fly out to his house, and deliver a CPU by hand, for free
<bluefox>
they got there in like 4 hours.
<bluefox>
He was doing engineering calculations for designing public transit rail systems, particularly all the physics for how the wheels interact with the track and what shape everything needs to be so it can make curves without crashing and turning into a mangled wreckage
<bluefox>
Called them, told them his CPU had FDIV bug, they brought him a new one.
<xentrac>
heh
<xentrac>
nowadays there are dozens of such bugs every year
<xentrac>
things have changed a lot since then
Andre_H has quit [Ping timeout: 265 seconds]
vagrantc has quit [*.net *.split]
cwebber has quit [*.net *.split]
nvmd has quit [*.net *.split]
TMM_ has quit [*.net *.split]
hendursaga has quit [*.net *.split]
crabbedhaloablut has quit [*.net *.split]
dionysos has quit [*.net *.split]
rektide_ has quit [*.net *.split]
mhorne has quit [*.net *.split]
alexfanqi has quit [*.net *.split]
radu242 has quit [*.net *.split]
abelvesa has quit [*.net *.split]
FL4SHK has quit [*.net *.split]
somlo has quit [*.net *.split]
ahs3 has quit [*.net *.split]
sm2n has quit [*.net *.split]
mecrisp has quit [*.net *.split]
zjason has quit [*.net *.split]
scruffyfurn has quit [*.net *.split]
joev has quit [*.net *.split]
aquijoule__ has quit [*.net *.split]
jotweh has quit [*.net *.split]
cmuellner has quit [*.net *.split]
dmang has quit [*.net *.split]
cronos has quit [*.net *.split]
mrkajetanp has quit [*.net *.split]
Amanieu has quit [*.net *.split]
toshywoshy has quit [*.net *.split]
elastic_dog has quit [*.net *.split]
Raito_Bezarius has quit [*.net *.split]
seds has quit [*.net *.split]
adamse has quit [*.net *.split]
drewfustini has quit [*.net *.split]
aurel32 has quit [*.net *.split]
danielinux_ has quit [*.net *.split]
bewees has quit [*.net *.split]
oaken-source has quit [*.net *.split]
indy has quit [*.net *.split]
peepsalot has quit [*.net *.split]
Gravis has quit [*.net *.split]
devcpu has quit [*.net *.split]
jedix has quit [*.net *.split]
avoidr has quit [*.net *.split]
balrog has quit [*.net *.split]
aburgess has quit [*.net *.split]
Bigcheese has quit [*.net *.split]
Forty-Bot has quit [*.net *.split]
solrize has quit [*.net *.split]
leah2 has quit [*.net *.split]
jljusten has quit [*.net *.split]
jrjsmrtn has quit [*.net *.split]
merry has quit [*.net *.split]
Esmil has quit [*.net *.split]
FluffyMask has quit [*.net *.split]
mahmutov has quit [*.net *.split]
gordonDrogon has quit [*.net *.split]
adjtm_ has quit [*.net *.split]
Sos has quit [*.net *.split]
pabs3 has quit [*.net *.split]
enthusi has quit [*.net *.split]
rvalles has quit [*.net *.split]
awordnot has quit [*.net *.split]
aredridel has quit [*.net *.split]
mifr has quit [*.net *.split]
zumbi has quit [*.net *.split]
wolfshappen has quit [*.net *.split]
kaji has quit [*.net *.split]
moto-timo has quit [*.net *.split]
wgrant has quit [*.net *.split]
gruetzkopf has quit [*.net *.split]
stefanct has quit [*.net *.split]
koolazer has quit [*.net *.split]
edef has quit [*.net *.split]
Finde has quit [*.net *.split]
psydroid has quit [*.net *.split]
bgamari has quit [*.net *.split]
xentrac has quit [*.net *.split]
ssb has quit [*.net *.split]
sauce has quit [*.net *.split]
jemarch has quit [*.net *.split]
jn has quit [*.net *.split]
koorogi has quit [*.net *.split]
haritz has quit [*.net *.split]
pjw has quit [*.net *.split]
kgz has quit [*.net *.split]
agraf has quit [*.net *.split]
dlan has quit [*.net *.split]
s0ph0s has quit [*.net *.split]
clandmeter has quit [*.net *.split]
adomas has quit [*.net *.split]
hl has quit [*.net *.split]
sirn has quit [*.net *.split]
rsalveti has quit [*.net *.split]
sjs has quit [*.net *.split]
khem has quit [*.net *.split]
ahs3[m] has quit [*.net *.split]
CarlosEDP has quit [*.net *.split]
demostanis[m] has quit [*.net *.split]
Slide-O-Mix has quit [*.net *.split]
mthall has quit [*.net *.split]
wigyori_ has quit [*.net *.split]
khilman has quit [*.net *.split]
mobius has quit [*.net *.split]
sorear has quit [*.net *.split]
panzeroceania has quit [*.net *.split]
connojd has quit [*.net *.split]
Werner has quit [*.net *.split]
tux3 has quit [*.net *.split]
zapb has quit [*.net *.split]
jtdowney has quit [*.net *.split]
tucanae47 has quit [*.net *.split]
jimbzy has quit [*.net *.split]
fabs has quit [*.net *.split]
pavelow has quit [*.net *.split]
meowray has quit [*.net *.split]
pokes has quit [*.net *.split]
crest has quit [*.net *.split]
tgamblin has quit [*.net *.split]
ats has quit [*.net *.split]
x0ul has quit [*.net *.split]
jcm has quit [*.net *.split]
shoragan has quit [*.net *.split]
jimwilson_ has quit [*.net *.split]
rah has quit [*.net *.split]
palmer has quit [*.net *.split]
mwbrown has quit [*.net *.split]
mrus has quit [*.net *.split]
geist2 has quit [*.net *.split]
klysm has quit [*.net *.split]
rjek has quit [*.net *.split]
cs_0x6373 has quit [*.net *.split]
bluefox has quit [*.net *.split]
snild has quit [*.net *.split]
Maylay has quit [*.net *.split]
dobson has quit [*.net *.split]
djdelorie has quit [*.net *.split]
guerby has quit [*.net *.split]
Thalheim has quit [*.net *.split]
jc has quit [*.net *.split]
arnd has quit [*.net *.split]
elms has quit [*.net *.split]
SanchayanMaity has quit [*.net *.split]
mithro has quit [*.net *.split]
olofj has quit [*.net *.split]
xypron has quit [*.net *.split]
reda has quit [*.net *.split]
q66 has quit [*.net *.split]
yongxiang has quit [*.net *.split]
NishanthMenon has quit [*.net *.split]
jrtc27 has quit [*.net *.split]
ln5 has quit [*.net *.split]
JSharp has quit [Ping timeout: 250 seconds]
zumbi has joined #riscv
aredridel has joined #riscv
wolfshappen has joined #riscv
mifr has joined #riscv
awordnot has joined #riscv
pabs3 has joined #riscv
rvalles has joined #riscv
enthusi has joined #riscv
Sos has joined #riscv
adjtm_ has joined #riscv
gordonDrogon has joined #riscv
FluffyMask has joined #riscv
mahmutov has joined #riscv
Esmil has joined #riscv
crabbedhaloablut has joined #riscv
mecrisp has joined #riscv
hendursaga has joined #riscv
sm2n has joined #riscv
cronos has joined #riscv
dionysos has joined #riscv
rjek has joined #riscv
shoragan has joined #riscv
scruffyfurn has joined #riscv
jrjsmrtn has joined #riscv
cs_0x6373 has joined #riscv
leah2 has joined #riscv
stefanct has joined #riscv
wgrant has joined #riscv
klysm has joined #riscv
kaji has joined #riscv
zjason has joined #riscv
jimwilson_ has joined #riscv
palmer has joined #riscv
mrus has joined #riscv
merry has joined #riscv
geist2 has joined #riscv
solrize has joined #riscv
jljusten has joined #riscv
ahs3 has joined #riscv
somlo has joined #riscv
dmang has joined #riscv
cmuellner has joined #riscv
FL4SHK has joined #riscv
abelvesa has joined #riscv
radu242 has joined #riscv
jotweh has joined #riscv
alexfanqi has joined #riscv
aquijoule__ has joined #riscv
mhorne has joined #riscv
rektide_ has joined #riscv
joev has joined #riscv
NishanthMenon has joined #riscv
xypron has joined #riscv
ln5 has joined #riscv
gruetzkopf has joined #riscv
yongxiang has joined #riscv
reda has joined #riscv
moto-timo has joined #riscv
elms has joined #riscv
arnd has joined #riscv
SanchayanMaity has joined #riscv
jc has joined #riscv
Thalheim has joined #riscv
guerby has joined #riscv
dobson has joined #riscv
djdelorie has joined #riscv
Maylay has joined #riscv
snild has joined #riscv
bluefox has joined #riscv
rah has joined #riscv
mwbrown has joined #riscv
mithro has joined #riscv
olofj has joined #riscv
jrtc27 has joined #riscv
q66 has joined #riscv
jn has joined #riscv
haritz has joined #riscv
koorogi has joined #riscv
pjw has joined #riscv
agraf has joined #riscv
clandmeter has joined #riscv
rsalveti has joined #riscv
adomas has joined #riscv
kgz has joined #riscv
s0ph0s has joined #riscv
dlan has joined #riscv
sirn has joined #riscv
sjs has joined #riscv
hl has joined #riscv
mrkajetanp has joined #riscv
elastic_dog has joined #riscv
toshywoshy has joined #riscv
Amanieu has joined #riscv
adamse has joined #riscv
Raito_Bezarius has joined #riscv
drewfustini has joined #riscv
aurel32 has joined #riscv
danielinux_ has joined #riscv
bewees has joined #riscv
oaken-source has joined #riscv
indy has joined #riscv
Gravis has joined #riscv
avoidr has joined #riscv
jedix has joined #riscv
peepsalot has joined #riscv
aburgess has joined #riscv
devcpu has joined #riscv
Bigcheese has joined #riscv
Forty-Bot has joined #riscv
balrog has joined #riscv
jemarch has joined #riscv
bgamari has joined #riscv
xentrac has joined #riscv
ssb has joined #riscv
sauce has joined #riscv
kaji has quit [Ping timeout: 244 seconds]
fabs has joined #riscv
tgamblin has joined #riscv
pavelow has joined #riscv
ats has joined #riscv
meowray has joined #riscv
pokes has joined #riscv
x0ul has joined #riscv
crest has joined #riscv
jcm has joined #riscv
zapb has joined #riscv
khem has joined #riscv
khilman has joined #riscv
wigyori_ has joined #riscv
demostanis[m] has joined #riscv
ahs3[m] has joined #riscv
CarlosEDP has joined #riscv
mthall has joined #riscv
sorear has joined #riscv
mobius has joined #riscv
tucanae47 has joined #riscv
Werner has joined #riscv
panzeroceania has joined #riscv
connojd has joined #riscv
Slide-O-Mix has joined #riscv
jimbzy has joined #riscv
jtdowney has joined #riscv
tux3 has joined #riscv
balrog has quit [Max SendQ exceeded]
elastic_dog has quit [Max SendQ exceeded]
koolazer has joined #riscv
edef has joined #riscv
Finde has joined #riscv
koolazer has quit [Max SendQ exceeded]
seds has joined #riscv
cwebber has joined #riscv
JSharp has joined #riscv
nvmd has joined #riscv
TMM_ has joined #riscv
vagrantc has joined #riscv
koolazer has joined #riscv
khem has quit [Ping timeout: 272 seconds]
llamp[m] has quit [Ping timeout: 250 seconds]
ahs3[m] has quit [Ping timeout: 272 seconds]
CarlosEDP has quit [Ping timeout: 272 seconds]
demostanis[m] has quit [Ping timeout: 272 seconds]