sorear changed the topic of #riscv to: RISC-V instruction set architecture | https://riscv.org | Logs: https://libera.irclog.whitequark.org/riscv
jn has quit [Ping timeout: 268 seconds]
joev has quit [Ping timeout: 245 seconds]
joev has joined #riscv
joev has quit [Ping timeout: 272 seconds]
joev has joined #riscv
jn has joined #riscv
jacklsw has joined #riscv
jacklsw has quit [Changing host]
jacklsw has joined #riscv
aerkiaga has quit [Remote host closed the connection]
Heston has joined #riscv
seninha has quit [Quit: Leaving]
Heston has quit [Read error: Connection reset by peer]
Heston has joined #riscv
sobkas has quit [Quit: sobkas]
jacklsw has quit [Quit: Back to the real world]
jacklsw has joined #riscv
lumberjack123 has quit [Remote host closed the connection]
alMalsamo has joined #riscv
alMalsamo is now known as lumberjack123
vagrantc has quit [Quit: leaving]
mahmutov has quit [Ping timeout: 246 seconds]
raym has quit [Quit: kernel update, rebooting...]
raym has joined #riscv
<muurkha> hi there
<muurkha> gordonDrogon: congratulations on your liberation from the ARM yoke ;)
<muurkha> gordonDrogon: I agree that bounds-checking is the kind of thing that you'd think hardware would be faster at, because it can be done concurrently with the rest of the instruction. but modern hardware is surprisingly good at that kind of thing
<muurkha> congratulations on getting your RISC-V CPU running! which design are you using?
<muurkha> oh, PicoRv32
<muurkha> gordonDrogon: you probably know half a dozen people who have PS/2 keyboards who live within 100km of you
<muurkha> (and don't want them)
<muurkha> dh`: no worries
<jrtc27> modern hardware is good at that kind of thing because it speculates past your bounds checks
<jrtc27> if you want the bounds checks to not suffer from spectre-like things then you're in for a rougher time without hardware support
<jrtc27> it's also quite hard to have the bounds be atomic with the pointer without hardware support
<jrtc27> see: the mess that was MPX
<muurkha> jrtc27: hmm, that's a good and dismaying point
<muurkha> what is/was MPX?
<muurkha> I assume you don't mean multiplex files in antediluvian Unix
<jrtc27> mpx added bounds registers to x86
<jrtc27> software would load bounds information into them and use instructions to check bounds
<jrtc27> but it was racy, because no atomics
<jrtc27> false-positives and false-negatives
<jrtc27> and you only had four bounds registers
<jrtc27> so the churn was insane, constantly swapping bounds in and out
<muurkha> how many capability registers does CHERI have?
<muurkha> I thought it was 4
<muurkha> incidentally I just found that the authors of this book on transactional memory from 02010 (first edition 02006) put it on the web: https://courses.cs.vt.edu/~cs5204/fall10-kafura-BB/Papers/TransactionalMemory/TM-Book-V2.pdf.pdf
<jrtc27> depends on your architecture
<jrtc27> "as many as you have integer registers"
<muurkha> sounds like I have a lot of reading to do
<jrtc27> (since we just extend the integer registers)
<jrtc27> slightly more complicated for x86 because people like to use segment registers for things and we don't want to lose them
<jrtc27> so we add capability registers that replace fs/gs
<jrtc27> in our sketch
<jrtc27> ("things" specifically being TLS)
<muurkha> makes sense, cs/ds/es/ss were originally intended as capability registers, they just got nerfed before tapeout
<jrtc27> well, they're not quite registers, they're indices into a table of segment descriptors
<muurkha> in the iAPX86 they were just base registers
<muurkha> as you surely know; I'm just clarifying the referent
<muurkha> undoubtedly a table of segment descriptors was intended but could not be realized until much later
<jrtc27> yeah descriptors came in the 286, before then it was just a base
<muurkha> right. and notoriously in the iAPX432
seninha has joined #riscv
seninha has quit [Remote host closed the connection]
Heston has quit [Read error: Connection reset by peer]
Heston has joined #riscv
Sofia has quit [Ping timeout: 240 seconds]
Sofia has joined #riscv
riff-IRC has quit [Remote host closed the connection]
riff-IRC has joined #riscv
<dh`> it's not at all clear what was intended
<dh`> other than compat with code for the 8080
lumberjack123 has quit [Remote host closed the connection]
lumberjack123 has joined #riscv
BOKALDO has joined #riscv
<gordonDrogon> muurkha, I have a back-burner project that might need 30-50 units, so 30-50 usb keyboards, etc. and lifes getting too short to chase own more and more stuff becoming obsolete )-:
pecastro has joined #riscv
jjido has joined #riscv
Heston has quit [Remote host closed the connection]
winterflaw has joined #riscv
freakazoid12345 has joined #riscv
freakazoid343 has quit [Ping timeout: 256 seconds]
Heston has joined #riscv
jjido has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
jjido has joined #riscv
radu242 has quit [Ping timeout: 260 seconds]
freakazoid343 has joined #riscv
freakazoid12345 has quit [Ping timeout: 272 seconds]
jjido has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
jmdaemon has quit [Ping timeout: 256 seconds]
EchelonX has quit [Quit: Leaving]
tafa has quit [Quit: ZNC - https://znc.in]
tafa has joined #riscv
<la_mettrie> visionfive's fedora images use initramfs while debian images seem not. so initramfs is not necessary there? but it's still somehow beneficial? i'd like to understand this scheme.
<gordonDrogon> it's a long story.
<gordonDrogon> if you can be bothered to compile a kernel tailired to your hardware then you don't need an initramfs at all - it's used to let a 'bare' kernel load up modules that can then access hardware - like the disk drive it's booting off and so on.
<gordonDrogon> I used to build fully static kernels for servers - they booted fast and had just the right hardware drivers and no more. It's a dying art these days, I fear .....
<gordonDrogon> I've no idea about debian on RISC-V though, but my Debian/Devuan systems on x86 all have an initramfs - see /boot/initrd.img-* ...
freakazoid343 has quit [Ping timeout: 260 seconds]
<la_mettrie> yes, i know this bigger picture. i was wondering more about this VisionFive's case (which can be related to wider SoC and/or riscv considerations)
jacklsw has quit [Quit: Back to the real world]
freakazoid333 has joined #riscv
<courmisch> I have Debian on VisionFive using initrd as normal
<courmisch> it's just a question of how the kernel is setup
<courmisch> really it boils down to the fact that you can't yet use the board with an upstream kernel, so you have to have a custom image.
<courmisch> if you have a custom image anyway, might as well skip initrd
<la_mettrie> you've made that initrd by yourself? i wonder if that's complicated
Andre_H has joined #riscv
kaph_ has quit [Read error: Connection reset by peer]
Andre_H has quit [Client Quit]
<courmisch> no, I use update-initramfs from stock Debian
kaph has joined #riscv
seninha has joined #riscv
radu242 has joined #riscv
aerkiaga has joined #riscv
seninha has quit [Quit: Leaving]
seninha has joined #riscv
joev has quit [Ping timeout: 260 seconds]
joev has joined #riscv
mthall has quit [Ping timeout: 246 seconds]
mthall has joined #riscv
freakazoid333 has quit [Remote host closed the connection]
freakazoid333 has joined #riscv
rvalles has quit [Quit: rvalles]
rvalles has joined #riscv
seninha has quit [Remote host closed the connection]
freakazoid333 has quit [Read error: Connection reset by peer]
freakazoid333 has joined #riscv
joev has quit [Ping timeout: 260 seconds]
joev has joined #riscv
seninha has joined #riscv
seninha has quit [Quit: Leaving]
seninha has joined #riscv
foton has quit [Quit: %Bye, bye, ...%]
foton has joined #riscv
jacklsw has joined #riscv
seninha has quit [Ping timeout: 260 seconds]
EchelonX has joined #riscv
<muurkha> gordonDrogon: yeah, 30-50 PS/2 keyboards might be significant effort at this point
vagrantc has joined #riscv
adjtm has quit [Quit: Leaving]
mahmutov has joined #riscv
<muurkha> dh`: so I've been reading the Harris/Larus/Rajwar book on transactional memory
<muurkha> at some point they do come out and say that "eager versioning" (direct rather than deferred update) requires pessimistic synchronization, which is what I was saying the other night
<muurkha> they also go into quite a bit of detail on different problems that can happen with mixing transactional and nontransactional access and with transactions doing impossible things because they saw incoherent views of the transactional store
<muurkha> like {{ x = 10; y = 10; }} || {{ my a = x; my b = y; if (a != b) for (;;); }}
<muurkha> where {{ }} is a transaction and || is concurrent execution
<muurkha> with the property they call "opacity" the second transaction never gets into an infinite loop, but in other cases it might
<muurkha> so my plan is to provide opacity (by giving transactions a view of the world as of, by default, the time they started) and use lazy versioning and optimistic update
<muurkha> I think I have a solution for the upgrade-read-only-to-read-write problem. when a transaction opens an object read-write, instead of copying the object's current state into the transaction's "redo-log" (the term they use for its buffered updates) we will make a copy of the object's unmodified state and relink the global state history to use the new copy instead of the old copy
<muurkha> that way the object doesn't move from the perspective of the transaction that wants to write to it, so if it has old raw pointers they remain valid
<muurkha> if there are any *other* transactions that had the object open read-only, well, they're apparently lower priority (or another transaction wouldn't be running) and they'll get canceled anyway if the current transaction commits
<muurkha> so we can just cancel them immediately due to detection of the tentative conflict, which is a thing I was saying was potentially bad the other night, so that we don't have to worry about the validity of their pointers
<muurkha> I think we still get to claim that the system is "lock-free" because only a higher-priority transaction can block the progress of a lower-priority transaction, in just the way it would have done anyway if it committed
<muurkha> but you could potentially have a high-priority transaction that occurs often and always crashes, say due to a bug, which consistently blocks lower-priority work in a way that it wouldn't if it had executed successfully. but in exactly the way it would have if it contained, for example, an infinite loop
<muurkha> where we maybe get into trouble is if two transactions can repeatedly preempt each other, say because you're doing round-robin scheduling at a given priority level and preempting transactions when their scheduling quantum runs out, the way time-sharing OSes normally do
jjido has joined #riscv
freakazoid343 has joined #riscv
Sofia has quit [Ping timeout: 240 seconds]
ivii has joined #riscv
freakazoid333 has quit [Ping timeout: 260 seconds]
Sofia has joined #riscv
jmdaemon has joined #riscv
jacklsw has quit [Read error: Connection reset by peer]
prabhakarlad has joined #riscv
Sofia has quit [Ping timeout: 240 seconds]
___nick___ has joined #riscv
Sofia has joined #riscv
jjido has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
freakazoid343 has quit [Remote host closed the connection]
freakazoid343 has joined #riscv
<Esmil> la_mettrie: where did you order your visionfive board from?
<Esmil> courmisch: ^
<la_mettrie> shop.allnetchina.cn
<Esmil> la_mettrie: thanks
<palmer> oh, maybe let's just hop over here?
<palmer> do you guys know if this is the old chip, the one from the BeagleV, or the new one?
<Esmil> palmer: it's a new run of the same jh7100 as the beaglev
<palmer> and it has the same coherency-related bugs?
<Esmil> yes
<palmer> OK, then I guess I'm not that excited ;)
<palmer> I was hoping for the new chip, so I could see the new bugs ;)
___nick___ has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
<courmisch> Esmil: sponsored by StarFive
<Esmil> courmisch: cool
___nick___ has joined #riscv
___nick___ has quit [Client Quit]
___nick___ has joined #riscv
jmdaemon has quit [Quit: ZNC 1.8.2 - https://znc.in]
jmdaemon has joined #riscv
<courmisch> Esmil: well not much to do so far. Lack of V means not much actually RV stuff in my field - multimedia.
<courmisch> audio is also pretty much unusable at the moment
<courmisch> KMS multiplane is buggy
<courmisch> and I've not managed to start the video DSP kernel module
<Esmil> yeah, i'd think there was lot's to improve in the multimedia area
<courmisch> there's a lot of missing hardware enablement for JH7100. There's not much at the ISA level.
<Esmil> maybe ask starfive which peripherals will be similar on the jh7110
<Esmil> right
<courmisch> I reckon JH7110 would have RVV, so there'd be a massive amount of work porting multimedia algos
<courmisch> but I don't suppose I'll get a second device
<courmisch> I need to check if the KMS multiplane problems are hardware limitations or just driver oversights
<courmisch> otherwise I would need HDMI Audio and HDMI CEC but I very much doubt that I myself can take care of the kernel side of those things
<Esmil> ah I see. yeah i was thinking on the kernel side there is lot's of multimedia drivers to improve
<courmisch> I'm not afraid of kernel programming per se. I still have my name in the MAINTAINERS file by some strange history. But I'm not a hardware person and I don't even have a serial port setup...
Andre_H has joined #riscv
adjtm has joined #riscv
seninha has joined #riscv
jmdaemon has quit [Read error: Connection reset by peer]
jmdaemon has joined #riscv
nvmd has joined #riscv
seninha has quit [Quit: Leaving]
<gordonDrogon> hey ho. Day 1 of playing with fpga with a device capable of hosting 2MB of RAM, a RISC-V core (or 2), HDMI & LCD video and I have a larson scanner. I'll call that progress for today :)
* [exa] can't believe the thing is called "larson scanner"
sobkas has joined #riscv
<muurkha> gordonDrogon: congratulations!
<gordonDrogon> [exa], seems to be the popular name for cylon/kitt .. Glen Larson productions thing...
<muurkha> yeah, Windell and Lenore named it that in 02007: https://www.evilmadscientist.com/2007/time-to-make-a-cylon/
<gordonDrogon> hm. I'm sure I knew it by that name before then - possibly even the 80's when I made a bbc micro do it ..
<gordonDrogon> or maybe we just called it a cylon scanner then. who knows.
<gordonDrogon> and I'm sure my verilog is somewhat crude - not sure learning verilog by looking at other example is the best way todo it, but it seems to work.
<muurkha> it's surely an indispensable part of it
<muurkha> there are some pitfalls: https://danluu.com/why-hardware-development-is-hard/
prabhakarlad has quit [Quit: Client closed]
BOKALDO has quit [Quit: Leaving]
<muurkha> (so I hear! you're one Larson Scanner ahead of me in actually writing things in Verilog)
<gordonDrogon> 6 LEDs on this board.
<gordonDrogon> I'l lread that after supper.thanks.
<muurkha> nice!
<muurkha> are the LEDs on when the bit is 0 because they're strung between the FPGA output and Vcc? do the FPGA pin drivers really have more sinking capacity than sourcing?
<gordonDrogon> supper delayed. yes, they seem inverted - not 100% sure why.
<muurkha> I saw a single-transistor bipolar LED driver last night that draws no current, which is a thing I didn't know was possible
<muurkha> but it does *sink* what would otherwise be the transistor's base current into your I/O pin when the pin is *low*
jmdaemon has quit [Ping timeout: 240 seconds]
jmdaemon has joined #riscv
<gordonDrogon> I wish they'd published the schematics for the board.
<gordonDrogon> and dealing with gowin is ugly. need to login to their site every time I want to download a pdf from them. it's almost as i they don't actually want people to use their stuff.
<muurkha> ugh
<muurkha> probably there are chinese forum sites where you could get all the PDFs without logging in to *GoWin*'s site
<gordonDrogon> I'm sure if you're a real commercial customer then you can bulk download easily.
<gordonDrogon> or I could take my growser out of privacy mode and get it to remember their cookies, login, etc. ...
<gordonDrogon> but onwards and upwards. I got the picoRV core loaded and working - now to take it to bits and see how it all plumbs together. all that ram, hdmi, etc.
___nick___ has quit [Ping timeout: 245 seconds]
radu242 has quit [Ping timeout: 246 seconds]
freakazoid343 has quit [Read error: Connection reset by peer]
freakazoid343 has joined #riscv
motherfsck has joined #riscv
winterflaw has quit [Remote host closed the connection]
pecastro has quit [Ping timeout: 260 seconds]
ntwk has quit [Quit: ntwk]
pecastro has joined #riscv
epony has quit [Quit: QUIT]
freakazoid12345 has joined #riscv
freakazoid343 has quit [Ping timeout: 240 seconds]
freakazoid12345 has quit [Quit: Leaving]
mahmutov_ has joined #riscv
mahmutov has quit [Ping timeout: 272 seconds]
nvmd has quit [Quit: WeeChat 3.5]
radu242 has joined #riscv
seninha has joined #riscv
Andre_H has quit [Quit: Leaving.]
sobkas has quit [Quit: sobkas]
EchelonX has quit [Quit: Leaving]
pecastro has quit [Ping timeout: 272 seconds]
freakazoid333 has joined #riscv
freakazoid343 has joined #riscv