aerkiaga has quit [Remote host closed the connection]
rurtty has quit [Quit: Leaving]
Tenkawa has quit [Quit: Was I really ever here?]
juliadev has quit [Quit: Ping timeout (120 seconds)]
dramforever has joined #riscv
juliadev has joined #riscv
dramforever has quit [Ping timeout: 252 seconds]
juliadev has quit [Quit: Network issues]
handsome_feng has joined #riscv
vagrantc has quit [Quit: leaving]
pabs3 has quit [Remote host closed the connection]
pabs3 has joined #riscv
billchenchina has quit [Remote host closed the connection]
Leopold_ has quit [Ping timeout: 248 seconds]
BootLayer has joined #riscv
elastic_dog has quit [Killed (calcium.libera.chat (Nickname regained by services))]
elastic_dog has joined #riscv
pabs3 has quit [Remote host closed the connection]
pabs3 has joined #riscv
mahk has quit [Changing host]
mahk has joined #riscv
craigo has quit [Ping timeout: 246 seconds]
wingsorc has quit [Ping timeout: 252 seconds]
crossdev has joined #riscv
pecastro has joined #riscv
your-mom has joined #riscv
billchenchina has joined #riscv
bitterlollipop has joined #riscv
ldevulder has joined #riscv
bitterlollipop has quit [Quit: system sleep - ZZZzzz...]
billchenchina has quit [Ping timeout: 248 seconds]
abelvesa has quit [Ping timeout: 246 seconds]
abelvesa has joined #riscv
iooi has quit [Read error: Connection reset by peer]
iooi has joined #riscv
ldevulder_ has joined #riscv
iooi has quit [Read error: Connection reset by peer]
iooi has joined #riscv
ldevulder has quit [Ping timeout: 255 seconds]
billchenchina has joined #riscv
billchenchina- has joined #riscv
billchenchina has quit [Ping timeout: 246 seconds]
iooi has quit [Read error: Connection reset by peer]
iooi has joined #riscv
iooi has quit [Read error: Connection reset by peer]
iooi has joined #riscv
biosit has quit [Ping timeout: 246 seconds]
biosit has joined #riscv
junaid_ has joined #riscv
Stat_headcrabed has joined #riscv
Stat_headcrabed has quit [Quit: Stat_headcrabed]
rurtty has joined #riscv
your-mom has quit [Ping timeout: 255 seconds]
junaid_ has quit [Remote host closed the connection]
ldevulder_ is now known as ldevulder
Andre_Z has joined #riscv
billchenchina- has quit [Remote host closed the connection]
billchenchina- has joined #riscv
johnjaye has quit [Ping timeout: 246 seconds]
johnjaye has joined #riscv
elastic_dog has quit [Ping timeout: 252 seconds]
elastic_dog has joined #riscv
Andre_Z has quit [Ping timeout: 255 seconds]
Tenkawa has joined #riscv
bitterlollipop has joined #riscv
bauruine has joined #riscv
bitterlollipop has quit [Quit: system sleep - ZZZzzz...]
MaxGanzII has joined #riscv
juliadev has joined #riscv
jmdaemon has quit [Ping timeout: 246 seconds]
rneese has joined #riscv
dramforever has joined #riscv
rsalveti has joined #riscv
billchenchina- has quit [Ping timeout: 246 seconds]
troglodito has quit [Ping timeout: 264 seconds]
jobol has joined #riscv
drewj has quit [Quit: Client closed]
troglodito has joined #riscv
BootLayer has quit [Quit: Leaving]
pedja has joined #riscv
<Sofia>
Hello world. Can someone confirm the expected number of instructions to reverse the bits of a 32-bit number is 2 instructions or similar with the bitmanip extension? If I read correctly, rev8 would transform abcdefgh_ijklmnop to hgfedcba_ponmlkji, reversing the 8 bits per byte, but keeping the byte positions. Then an xperm.b to permute the bytes around too. If someone could the specific asm or
<Sofia>
C/intrinsics to compile this, and instruct how to run it in qemu with bitmanip, I'd appreciate it. https://godbolt.org/z/6381zTG8b
<Sofia>
Though I'd be happy with just a confirmation or a description of what it'd take instead if incorrect.
<Sofia>
could write the*
<Sofia>
Probably another instruction or two to load the permutation map into a register.
<Sofia>
Or a rev.b for the bits and rev8 for the bytes. So 2 instructions?
epony has quit [Read error: Connection reset by peer]
Stat_headcrabed has joined #riscv
aerkiaga has joined #riscv
<dramforever>
Sofia: I don't think rev.b exists in the frozen Zb* spec, so there's no way to work on individual bits with those
<dramforever>
On the other hand in the 0.93 bitmanip, just straight up rev is reversing everything, so 1 instruction
<dramforever>
rev8 is 'byte swap', which you can get LLVM to produce from u32::swap_bytes etc from Rust: https://godbolt.org/z/4vEx97vxG
<Sofia>
Hmm.. I see. Thanks
<Sofia>
dramforever: What do you think the cheapest full bit reversal would be then?
<bjdooks>
the vector crypto is still in progress, not sure whern the actual ratification will tkae place
<dramforever>
looks like they want it to be in 2023
<la_mettrie>
are cpuid and hartid different values in kernel because cpuid can refer also to non-riscv-compatible and hartid only to riscv compatible cores?
<Sofia>
dramforever: I'm pretty sure that vector implies scalar.
<dramforever>
okay, good to know, i haven't chceked
<dramforever>
*checked
<dramforever>
la_mettrie: I think Linux renumbers the CPUs to numbers starting at 0. hartid is whatever the hardware says it is
<dramforever>
For example on the Unmatched/Visionfive 2 hart 0 is a small one that can't run Linux, so hartid will be 1 through 4, and cpuid (or whatever the correct terminology for Linux) is 0 through 3
<bjdooks>
given the work we're doing getting qemu to support them
<Sofia>
Stat_headcrabed: Can you at least confirm the scalar extensions like Zbkb are implied by vector crypto?
* Sofia
doesn't see zbkb mentioned in the crypto vector spec
<Sofia>
> a companion document Volume I: Scalar & Entropy Source Instructions , describes cryptographic instruction proposals for smaller cores which do not implement the vector extension.
<Sofia>
That sounds like the scalar crypto code is intended for lower end cores, but doesn't say anything about Zbkb et al.
<Sofia>
Not all cryptography benefits from vectors, and the Zbkb et al are tiny....
<Sofia>
Especially at such levels as we're talking about vectors and vectored crypto.
<Sofia>
And they benefit so much other non-crypto code too
<muurkha>
interesting
<Stat_headcrabed>
Does existing bit manuplation instructions could be applied to vector register?
<courmisch>
no
<Stat_headcrabed>
Thx
<courmisch>
different operand types require different instructions on RV
<muurkha>
on pretty much every architecture really
Leopold has joined #riscv
<Sofia>
Is anyone in here working on these crypto specs? I'd really like to know at least the Zbkb will be included in say an RVA23 processor with vector crypto.
<Sofia>
Zkr and Zkt are at least.
wiagn has joined #riscv
<dramforever>
Maybe you can just get the RVA23 people to keep Zbkb around in RVA23
<dramforever>
Or probably, get the bitmanip people to ratify Moar Zb*
<courmisch>
muurkha: yes and no. RV actually uses different mnemonics for different operand types. Arm does not.
<courmisch>
though obviously the instruction encoding varies
<muurkha>
oh, sure
<muurkha>
MOV on amd64 is the worst offender there
<dramforever>
aaaaaaah mov
Stat_headcrabed has quit [Ping timeout: 246 seconds]
wiagn is now known as Stat_headcrabed
cwebber has quit [Ping timeout: 255 seconds]
cwebber has joined #riscv
<Sofia>
I care about both Zbkb (Zbb + pack, packh, packw, brev8, zip, unzip) and Zbkx (crossbeam permutations; xperm4, xperm8). Despite vectors.
<dramforever>
wait pack isn't in the ratified Zb stuff? I'm disappointed :(
<Sofia>
I care about these for more than just cryptography.
<Sofia>
There are plenty of data structures which share usefulness in these instructions alongside cryptography.
<dramforever>
Yeah these are very general and kinda weird that they took it out with Zk
<geertu>
muurkha: MOVE(A) on m68k? ;-)
<dramforever>
Wonder if it's just unintentionally taken out
* Sofia
tries for sleep o/
<somlo>
tried building the latest rocket from source (`make -C rocket-chip/vsim verilog`) and now I'm getting "/bin/bash: mill: command not found"
<somlo>
there's a bunch of stuff about updating to the "mill build system" in the git logs, but I haven't found anything on the practical implications on how one would actually *build* it in the new scheme of things
jacklsw has quit [Read error: Connection reset by peer]
<somlo>
the (recursive) rocket repo used to have everything it needed to build (given java) -- I suppose mill is an external dependency one would now have to have pre-installed (rather than it being included as a submodule)?
Leopold has quit [Remote host closed the connection]
Leopold has joined #riscv
elastic_dog has quit [Ping timeout: 248 seconds]
elastic_dog has joined #riscv
MaxGanzII has quit [Remote host closed the connection]
ldevulder has quit [Remote host closed the connection]
dramforever has quit [Ping timeout: 260 seconds]
vagrantc has joined #riscv
<muurkha>
geertu: hmm, maybe?
Stat_headcrabed has quit [Quit: Stat_headcrabed]
rneese has quit []
prabhakarlad has quit [Quit: Client closed]
aerkiaga has quit [Remote host closed the connection]
juliadev has quit [Ping timeout: 265 seconds]
craigo has joined #riscv
juliadev has joined #riscv
crossdev has quit [Ping timeout: 255 seconds]
peeps has joined #riscv
<drewfustini>
I'm getting a dtc warning that I can't seem to figure out. I think I am missing something obvious. Anyone have suggestion? <stdin>:22.57-26.27: Warning (interrupt_provider): /cpus/cpu@0/interrupt-controller: Missing #address-cells in interrupt provider https://www.irccloud.com/pastebin/t9plYHnb/
peeps[zen] has quit [Ping timeout: 268 seconds]
<drewfustini>
I looked at upstream ones like sifive/fu540-c000.dtsi and they don't seem to have address cells inside cpu0_intc either
peeps[zen] has joined #riscv
peeps has quit [Ping timeout: 246 seconds]
<drewfustini>
i see that the fu540 plic node has "#address-cells" but I can't see any examples of the cpu node interrupt-controller having
prabhakarlad has joined #riscv
torbjornsd has joined #riscv
aerkiaga has joined #riscv
MaxGanzII has joined #riscv
zjason has quit [Ping timeout: 246 seconds]
zjason has joined #riscv
jmdaemon has joined #riscv
crossdev has joined #riscv
torbjornsd has quit [Ping timeout: 248 seconds]
bitterlollipop has joined #riscv
junaid_ has joined #riscv
junaid_ has quit [Ping timeout: 252 seconds]
bitterlollipop has quit [Quit: system sleep - ZZZzzz...]
Andre_Z has quit [Ping timeout: 255 seconds]
Andre_Z has joined #riscv
BootLayer has quit [Quit: Leaving]
vagrantc has quit [Quit: leaving]
junaid_ has joined #riscv
prabhakarlad has quit [Quit: Client closed]
junaid__ has joined #riscv
zjason` has joined #riscv
zjason has quit [Ping timeout: 252 seconds]
junaid___ has joined #riscv
junaid__1 has joined #riscv
MaxGanzII has quit [Remote host closed the connection]
MaxGanzII has joined #riscv
junaid__2 has joined #riscv
johnjaye has quit [Ping timeout: 246 seconds]
johnjaye has joined #riscv
iooi has quit [Read error: Connection reset by peer]
iooi has joined #riscv
Tenkawa has quit [Quit: Was I really ever here?]
bitterlollipop has joined #riscv
bitterlollipop has quit [Client Quit]
torbjornsd has joined #riscv
junaid__3 has joined #riscv
jobol has quit [Quit: Leaving]
junaid__1 has quit [Remote host closed the connection]
junaid___ has quit [Remote host closed the connection]
junaid__2 has quit [Remote host closed the connection]
junaid_ has quit [Remote host closed the connection]
junaid__3 has quit [Remote host closed the connection]
junaid__ has quit [Remote host closed the connection]
lagash_ has quit [Ping timeout: 248 seconds]
prabhakarlad has joined #riscv
prabhakarlad has quit [Quit: Client closed]
crossdev has quit [Remote host closed the connection]
craigo has quit [Quit: Leaving]
<conchuod>
drewfustini: Did you get a satisfactory answer from Rob?
<drewfustini>
yeah, thanks
<drewfustini>
also, I think I was seeing different warnings from running dtc directly (outside of the kernel build)
lagash_ has joined #riscv
<conchuod>
Are we ever gonna see the thing you're working on upstream or nah?
bauruine has quit [Remote host closed the connection]
craigo has joined #riscv
<drewfustini>
I had my dts outside of the linux directory and I was just building directly with dtc to get my dtb. Now that I created proper directory inside arch/riscv/boot/dts/vendor/mysoc.dts I don't see any warning when I build the kernel. Though maybe the warnings are just hidden?
<drewfustini>
re: upstream... I hope eventually. The main activity is still bring-up so not in a state to send patches yet.
<drewfustini>
Though OpenSBI 1.2 and Linux 6.2 is the base so not too bad of shape
<drewfustini>
I guess it is not a problem. I don't see mainline complain about address-cells missing in the sifive or starfive cpu interrupt-controller nodes.
<bjdooks>
drewfustini: could you have a bad reference somewhere else in the dts which is making dts think you are doing an addr translation instead of irq translaton
wingsorc has joined #riscv
<drewfustini>
Thanks, that is possible
<drewfustini>
Now that I am building the dts for my new platform inside kernel tree, I don't see that warning. I suspect the schema information that dtc has is different when running in a random directory outside of the linux tree.
<drewfustini>
Anyways, when I have my new dts in the linux tree like the other riscv platforms, then there is no warning about address cells anymore
<drewfustini>
Unrelated to my platform, but I notice riscv does have some warnings about property names like:
<drewfustini>
arch/riscv/boot/dts/microchip/mpfs-polarberry.dts:73.2-15: Warning (property_name_chars_strict): /soc/mmc@20008000:mmc-ddr-1_8v: Character '_' not recommended in property name
<drewfustini>
I suppose not much can be done there as the mmc properties are named that
<conchuod>
Yah, nothing to be done there as they're common properties