sorear changed the topic of #riscv to: RISC-V instruction set architecture | https://riscv.org | Logs: https://libera.irclog.whitequark.org/riscv
jjido has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
pecastro has quit [Ping timeout: 240 seconds]
<jrtc27> in what sense?
<jrtc27> I work on this
<jrtc27> it is very remarkable for the industry that this exists
<jrtc27> though I'm not sure what their source is, the official launch event is later this week
<jrtc27> kind of a crap article too
<jrtc27> "ARM has developed a prototype architecture based on the Cortex-A core" is wrong
<jrtc27> Cortex-A is an implementation of the architecture, the architecture is Armv8-A etc
<jrtc27> and the implementation isn't directly based on a Cortex-A core, either, it's based on the Neoverse N1, which itself is ultimately based on the Cortex A76
EchelonX has quit [Quit: Leaving]
kaph has quit [Ping timeout: 240 seconds]
<solrize> jrtc27, is it like old style x86 segmentation registers?
<jrtc27> no
<jrtc27> there are some similarities at a very high level
<jrtc27> but it's quite a different way of doing things
<jrtc27> segments are in a table and you reference them by number
<jrtc27> capabilities have no such indirection, the capability is the thing in the register and contains all the information
<jrtc27> and there is a tag bit to prove integrity/validity so they are impossible to forge
<jrtc27> whereas segments you can just load whatever you like into the GDT or whatever
<solrize> ah ok
<jrtc27> in our world, every single pointer in your C code, and every single pointer in the runtime (program counter, return addresses, GOT entries, ...) is a capability with a tag proving its validity, fine-grained bounds and permissions
<solrize> that's kind of hard for C because of the way pointer casting happens everywhere... would be nice for ada. iapx432 had something like that iirc. maybe this arm thing is better
<jrtc27> I mean, we have all of FreeBSD, nginx, WebKit, PostgreSQL and a minimal KDE all working
<jrtc27> most code requires few if any changes
<jrtc27> not sure what your concern with casting is?
<solrize> does that use the feature to its full, um, capability?
<jrtc27> yes
<solrize> there is a data structure associated with each pointer? so when you load a pointer you have to fill in a bunch of slots?
<jrtc27> the pointer is the data structure
<jrtc27> it's a compressed 128-bit (plus 1-bit tag) value
<solrize> i guess there are C implementations with fat pointers
<solrize> hmm ok
<solrize> 64 bit addresses fit in that?
<jrtc27> yes
<jrtc27> (we also have a version for 32-bit processors where the capability is a 64-bit value)
<solrize> how is forgery prevented?
<jrtc27> clobbering values in memory atomically clears the tag
<jrtc27> so the only way to write a valid capability to memory is by having a valid capability in a register and writing it
<jrtc27> then it's just a matter of designing the architecture so no instruction lets you create a capability with access rights you don't already have
<solrize> 129 bits?
<jrtc27> ie the set bounds instruction checks the requested bounds are a subset of the input etc
<solrize> or 127+1
<jrtc27> 129
<solrize> hmm
<jrtc27> the 129th bit is in non-addressable memory
<solrize> interesting
<jrtc27> similar to how sparc adi/arm mte/etc store their notion of tag bits on the side
<solrize> so the memory controller has to be made for that
<jrtc27> yes
<jrtc27> though, you can use commodity dram
<jrtc27> if you shove a shim in front that reserves 1/129th of the memory for itself
<solrize> yeah
<solrize> wonder if risc-v will get something similar
<jrtc27> (or slightly more in reality, so you can have a multi-level scheme that exploits the non-uniform distribution of pointers in memory0
<jrtc27> our research is based on riscv
<jrtc27> so we have a cheri-risc-v
<jrtc27> all open source
<solrize> ah ok
<solrize> i've heard of that but didn't connect the two
<jrtc27> but we've also been collaborating with arm and that led to this government-funded industrial research program
<jrtc27> and they have rather more mature microarchitectures than you can do in research
<jrtc27> plus the experience to do a full SoC and board
<solrize> and then arm runs this press release making it sounds revolutionary and unique to them
<jrtc27> I can guarantee that's not their press release
<solrize> ah ok
<jrtc27> that's just some rando's announcement
<jrtc27> my *guess* is they picked up a colleague's linkedin post from a few days ago
<jrtc27> where they posted a photo of a box containing a morello board delivered outside their front door
<jrtc27> but they don't cite their source so who knows
<solrize> there is a hn thread about it that is a little bit breathless
<jrtc27> yeah, I took a guess that's where you got that link from and found the post
<solrize> well, 2 comments, one of them breathless. https://news.ycombinator.com/item?id=29951145
<jrtc27> the other might look familiar :)
<solrize> aha ;)
<solrize> yeah there was only the first comment when i looked a while ago
<jrtc27> wouldn't be surprised if we have more downstream that we failed to upstream
<jrtc27> but also we hit really stupid stuff like https://github.com/libuv/libuv/commit/2fbfa0358b3bb920ddd1c2747d4887b35b9ac161 that's not interesting it's just "seriously?"
<solrize> jrtc27, you might mention cheri on hacker news?
jacklsw has joined #riscv
<jrtc27> the article does mention CHERI
<jrtc27> albeit in a sentence with broken grammar
AEtherC0r3 has quit [Quit: No Ping reply in 180 seconds.]
AEtherC0r3 has joined #riscv
j0hnny has joined #riscv
vagrantc has quit [Quit: leaving]
winterflaw has joined #riscv
Sos has quit [Quit: Leaving]
riff-IRC has quit [Remote host closed the connection]
riff-IRC has joined #riscv
kaph has joined #riscv
BOKALDO has joined #riscv
<dh`> ssb: compat does not require that paths through glibc be machine-dependent; that's purely poor engineering
KombuchaKip has quit [Quit: Leaving.]
<ssb> dh`, I don't get it how -- system calls are different. In linux riscv64 there are waitid and wait4, in riscv32 there is only waitid
<ssb> on my riscv32 system make called waitpid(), glibc translated it to waitid(), which hit a bug in qemu at line 8729: https://git.qemu.org/?p=qemu.git;a=blob;f=linux-user/syscall.c#l8729
<jrtc27> yes, poor engineering
<jrtc27> because the linux kernel has machine-dependent system calls
<jrtc27> other OSes have machine-independent system calls
<jrtc27> just look at clone for the complete mess that is linux's system call interface
<ssb> no question about that, but how is that poor _engineering_, but not poor design choice (== backwards binary compatibility)
<jrtc27> design choices are a part of engineering
<ssb> So Linus decided to maintain backwards compatibility and glibc authors did poor engineering to implement it instead of breaking it each release ?
<ssb> I still don't get it what would be non-poor engineering/design choice in this situation
mahmutov has joined #riscv
kaph_ has joined #riscv
kaph has quit [Ping timeout: 256 seconds]
KombuchaKip has joined #riscv
epony has joined #riscv
KombuchaKip has quit [Quit: Leaving.]
KombuchaKip has joined #riscv
huseyinkozan has joined #riscv
<dh`> ssb: the way this works outside the linux bubble is
<dh`> originally, waitpid() is its own system call
<dh`> at some point the kernel adds support for waitid(), which doesn't affect compatibility in any way
<dh`> at some point (possibly the same point), the waitpid entry point in libc gets changed to call the waitid() system call
<dh`> this also doesn't affect compatibility in any way because the results are the same
<dh`> which machine you're running on is 100% irrelevant
jjido has joined #riscv
<dh`> the only thing where the machine might matter is that on a machine added since the transition in libc, there's no need to implement the waitpid system call directly
<dh`> outside the linux bubble that translates to building riscv kernels without the compat code for versions from say ten years ago
<dh`> problem #1 is that in linux lots of stuff that shouldn't be is machine-dependent
<dh`> problem #2 is that technical coordination between the kernel and libc has historically been "challenging"
Andre_H has joined #riscv
<la_mettrie> examples of machine-dependent stuff that shouldn't be?
<dh`> well, for example, on linux system call numbers are different on each port
<ssb> also stuff like RLIMIT_* constants
<dh`> basically anything/everything in the syscall ABI is up for grabs and might be different from one machine to the next regardless of whether there's any substantive reason
<ssb> dh`, above that there also problem #0 backwards binary compatibility requirement makes solutions to problem #1 impossible
<dh`> sort of
<dh`> not for this example
<dh`> you can't renumber e.g. the arm system calls to match the x86 ones
<dh`> but you also don't need binary compat for arm binaries on x86 (unless you're qemu-user, but that's a very specific translation headache)
<dh`> so ok, on riscv the kernel only provides waitid() and not waitpid() or wait4() or whatnot else
<dh`> but presumably it provides waitid() on all platforms, so why is waitpid() being handled differently on a platform-by-platform basis?
<dh`> it boils down to "glibc has issues" and hence my remarks a couple days ago
<dh`> this is not something that appeared one night; it's the result of years and years of dysfunction
TMM_ has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM_ has joined #riscv
jjido has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
EchelonX has joined #riscv
kaph_ has quit [Quit: Leaving]
kaph has joined #riscv
pecastro has joined #riscv
jjido has joined #riscv
kaph has quit [Ping timeout: 250 seconds]
pecastro has quit [Read error: Connection reset by peer]
pecastro has joined #riscv
kaph has joined #riscv
quantum_ has joined #riscv
EchelonX has quit [Ping timeout: 256 seconds]
jjido has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
geranim0 has joined #riscv
NeoCron has joined #riscv
mahmutov has quit [Ping timeout: 240 seconds]
Narrat has joined #riscv
alMalsamo has quit [Remote host closed the connection]
alMalsamo has joined #riscv
mahmutov has joined #riscv
jjido has joined #riscv
freakazoid333 has quit [Ping timeout: 240 seconds]
freakazoid333 has joined #riscv
Andre_H has quit [Quit: Leaving.]
freakazoid333 has quit [Quit: Leaving]
Narrat has quit [Quit: They say a little knowledge is a dangerous thing, but it's not one half so bad as a lot of ignorance.]
aerkiaga has joined #riscv
aerkiaga has quit [Remote host closed the connection]
jacklsw has quit [Read error: Connection reset by peer]
freakazoid333 has joined #riscv
aerkiaga has joined #riscv
compscipunk has quit [Quit: WeeChat 2.8]
cousteau has joined #riscv
aerkiaga has quit [Remote host closed the connection]
peeps[zen] has quit [Read error: Connection reset by peer]
peeps[zen] has joined #riscv
huseyinkozan has quit [Quit: Konversation terminated!]
cousteau has quit [Quit: ♫ I can't forget the day I shot that network down ♫]
kaph has quit [Read error: Connection reset by peer]
kaph has joined #riscv
RAMIII has joined #riscv
RAMIII has quit [Quit: WeeChat 2.8]
BOKALDO has quit [Quit: Leaving]
gaude has joined #riscv
pecastro has quit [Read error: Connection reset by peer]
pecastro has joined #riscv
mahmutov has quit [Ping timeout: 240 seconds]
<gordonDrogon> some more weird gcc things with -O3 in my emulator, but can't quite get to the bottom of it - I think it's in-lining some code in an odd way but probably correct for a real cpu. if I put the code in a separate file to stop it inlining then it works perfectly.
<gordonDrogon> however not too worried for now - it seems good enough to run some C code including switch() and an ackermann function.
cousteau has joined #riscv
Ivii has joined #riscv
jjido has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
kaph has quit [Read error: Connection reset by peer]
compscipunk has joined #riscv
compscipunk has quit [Client Quit]
compscipunk has joined #riscv
compscipunk has quit [Client Quit]
compscipunk has joined #riscv
kaph has joined #riscv
kaph has quit [Remote host closed the connection]
jjido has joined #riscv
jjido has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
jimwilson has quit [Quit: Leaving]
gaude has quit [Quit: Client closed]
quantum_ has quit [Quit: Leaving]
EchelonX has joined #riscv