<Sofia>
My understanding is the reason RV64I includes the 32-bit operations is basically because a lot of C code operates over 32-bit numbers when working over larger numbers would just involve changing types and occasionally a little logic. At which point the reason to use 32-bit arithmetic is mostly a question of _maybe_ going faster, if the core implements 32-bit operations cheaper than 64-bit.
<HdkR>
Sofia: Should be noted that X2 and A510 also didn't have 32-bit support.
<unlord>
HdkR: I'm out of ideas for tonight
<Sofia>
And _maybe_ using less energy as less data needs to be passed around and processed. But if we care about power per bits used, there are encoding schemes which run-length encode the zeros and shortcut irrelevant gates to use less power when working with many prefixed zeros or numbers with either few zeros or few ones.
<HdkR>
Sofia: Should also be noted that the frontend size improvements mostly come from removing all the cruft that AArch32/Thumb/Thumb2 had, rather than operating at 32-bit sizes
* Sofia
nods
<Sofia>
In RV64I cores, I guess the costs of 32-bit arithmetic is mostly negligible in practice? Just a bit to mask away the higher bits and typically just reuse the same adder hardware anyway?
<Sofia>
Maybe fuse a couple 32-bit additions into a single 64-bit addition with a gate cutting the carries/communication between them.
<Sofia>
Therefore higher throughput. But only if the rest of the system can handle it.
<Sofia>
At which point a simple implementation doesn't care and a more advanced implementation is going to spend more area for better optimizations anyway.
pecastro has joined #riscv
<LordDoskias>
ATM what is the most affordable option to get a SBC with an riscv chip?
<Sofia>
What kind of chip are you after? There are many tiny ones. Or are you after something comparable to a raspberry pi?
<Sofia>
What extensions do you care about? I want a SBC with RV64GCBVK plus a bunch of Z* extensions.
<Sofia>
I don't know any which meet what I want yet.
<LordDoskias>
something where you can do meaningful work for enablement :d
<LordDoskias>
i'm a kernel developer so that's what i'll be mostly interested in
<LordDoskias>
thinking about it - when writing user software or the usual IOT stuff the underlying architecture doesn't matter so much so long as you can twiddle bits and make gpios turn on/off ;)
<Sofia>
qemu et al simulators should be a good start at least with no budget or hardware search. :)
<LordDoskias>
sure, i was wondering the fidelity they provide
<LordDoskias>
but i guess the initial linux port was done using qemu
raym has quit [Remote host closed the connection]
raym has joined #riscv
\subline has joined #riscv
raym has quit [Ping timeout: 268 seconds]
<smaeul>
LordDoskias: the most affordable Linux-class SBCs are D1 boards (20-30 USD), and D1 has plenty of kernel enablement left to do
<LordDoskias>
isn't this a NULL op in the sense that the value of sstatus is not changed? given that its value is first read into t0 and then t0 is written to sstatus?
BootLayer has quit [Quit: Leaving]
<yyp>
this construct swaps values in t0 and sstatus
<LordDoskias>
is this due to some magical register renaming ?
<yyp>
probably
<LordDoskias>
if rs/rd are equal isn't this supposed to first overwrite content of rd
<yyp>
check out section 9.1 of the unprivileged specification, it explains how this instruction works in detal
Andre_H has joined #riscv
<LordDoskias>
it's somewhat explained in a cheek in tongue way:
<LordDoskias>
CSRRW reads the old value of the CSR, zero-extends the value to XLEN bits, then writes it to integer register rd. The initial value in rs1 is written to the CSR.
<LordDoskias>
"The initial value in rs1...'
<LordDoskias>
that implies indeed that the initial value is retained is rd=rs1
<yyp>
Roughly this explanation to me looks like 'oldcsr = read(csr); rd = oldcsr; write(csr, rs1)'
<LordDoskias>
what if rs1 == rd ?
Andre_H has quit [Quit: Leaving.]
<yyp>
then it also saves "initial value in rs1"
<LordDoskias>
yes, though this is not explicitly mentioned
<yyp>
¯\_(ツ)_/¯
<yyp>
I've successfully used csrrw with rs1=rd in task switching code of my kernel and it works as expected, swapping csrs and registers
<LordDoskias>
sure, i'm not disputing this
<LordDoskias>
it's the same in the linux kernel, however this semantic is not clearly reflected in the docs
<ikskuh>
heya o/
<ikskuh>
i found some document describing the register usage and calling convention for risc-v, but i couldn't find a description what the registers x3/gp and x4/tp are used. can someone point me into the right direction here?
<LordDoskias>
basically it's a matter of ABI convention
<unlord>
smaeul: thanks for that link
<ikskuh>
LordDoskias: thanks! this sounds like i can safely forbid my compiler to use x4, compile as single threaded and use it for OS information
<LordDoskias>
well if you are linking against glibc then probably no
<ikskuh>
nah, i'm compiling for "riscv32-freestanding-none" with cpu "riscv32icm"
<ikskuh>
and i can set a llvm feature to prevent usage of register x4
BootLayer has joined #riscv
aerkiaga has quit [Ping timeout: 255 seconds]
aerkiaga has joined #riscv
RAMIII has joined #riscv
motherfsck has quit [Ping timeout: 246 seconds]
pabs3 has quit [Ping timeout: 268 seconds]
pabs3 has joined #riscv
motherfsck has joined #riscv
jacklsw has joined #riscv
Andre_H has joined #riscv
EchelonX has joined #riscv
Andre_H has quit [Quit: Leaving.]
motherfsck has quit [Ping timeout: 240 seconds]
motherfsck has joined #riscv
Andre_H has joined #riscv
mthall has quit [Ping timeout: 264 seconds]
mthall has joined #riscv
mthall has quit [Ping timeout: 240 seconds]
mthall has joined #riscv
mthall has quit [Ping timeout: 246 seconds]
mthall has joined #riscv
aerkiaga has quit [Remote host closed the connection]
zjason` is now known as zjason
theruran has joined #riscv
aburgess_ has quit [Ping timeout: 246 seconds]
<conchuod>
smaeul: what do I need for a minimal /bootable/ system?
Andre_H has quit [Quit: Leaving.]
<conchuod>
Just the dt, or is pinctrl required?
<HdkR>
unlord: nice!
vagrantc has joined #riscv
jacklsw has quit [Read error: Connection reset by peer]
<jrtc27>
Sofia: the article is poor, by 32-bit they mean AArch32 (both A32 and T32), not AArch64's add w0, w1, w2 etc support as that would violate the AArch64 spec
<jrtc27>
similarly an RV64I core that doesn't include addiw would not be a legal implementation
<jrtc27>
LordDoskias: it *is* explicitly mentioned, that's why it says "initial value of rs1", not "value of rs1"
<mmind00>
conchuod: from my tests today, I think mainline needs still something more than pinctrl to boot ... likely the RTC-part ... after adding the pinctrl and an ARCH_SUNXI Kconfig (for the clock-driver to acknowledge us), I still got a hang
<conchuod>
mmind00: I need to try to boot next-20220630 on something that isnt a sifive fu540 or mpfs
<conchuod>
d1 is the only other hw I have
<mmind00>
conchuod: so with -next you will get some early console output and then it will stop :-)
<conchuod>
On mpfs I get to [ 0.093895] smp: Bringing up secondary CPUs ...
<conchuod>
I bisected the commit that causes that on mpfs, but I suspect that the fu540 will fail in the exact same way
Andre_H has quit [Quit: Leaving.]
<conchuod>
(and if I dont have keep_bootcon, I get no output on a tty)
<mmind00>
conchuod: other option merge your next-branch into smaeul's tree ... the changes in there compared to mainline are only sunxi-specific
<mmind00>
conchuod: when running mainline on my d1, I also need a earlycon=uart8250,mmio32,0x2500000 ... due to the missing pinctrl (and more stuff)
<conchuod>
btw, if anyone with an SMP mainline board that isn't a polarfire soc, I'd be grateful if you test booted next-20220630
<conchuod>
s/if anyone/if theres anyone
<conchuod>
Or I could just am all the patches haha
<conchuod>
gah, conflicts between that and -next
<conchuod>
am it is..
<conchuod>
mmind00: ye I have the d1 set up in my "farm" already :)
* mmind00
just fixed the conflicts ;-)
<conchuod>
aight man, gotta make me look lazy dontcha..
<mmind00>
conchuod: sorry, wasn't the goal ;-) ... the conflicts just looks "simpler"
<conchuod>
Oh, I am lazy though...
<conchuod>
I hate trying to resolve conflicts in code I've not seen before
tsraoien has joined #riscv
<conchuod>
ohh, the patches have the conflicts too haha
<mmind00>
hehe, I guess it's always weighing between what's more work ... on my d1-nezha the merged kernel got past the cpu bringup (but of course there's only one core anyway) ... and I get breakage way later when networking (for nfsroot) comes up
<conchuod>
I suspected it'd be fine cos no SMP, but thanks!
<mmind00>
conchuod: what's the commit you bisected your breakage to?
<mmind00>
conchuod: and now I also thought about checking for CONFIG_SMP ... now with it being on, it still boots though ... and I get "smp: Brought up 1 node, 1 CPU" ... and the D1 continues on after that
<conchuod>
Aye, but even with CONFIG_SMP, it may require /actually being/ SMP to trigger
<mmind00>
yeah probably
<courmisch>
Esmil: V5 kernel fails to build recently. make[4]: *** No rule to make target 'firmware/brcm/brcmfmac43430-sdio.beagle,beaglev-starlight-jh7100-r0.txt', needed by 'drivers/base/firmware_loader/builtin/brcm/brcmfmac43430-sdio.beagle,beaglev-starlight-jh7100-r0.txt.gen.o'. Stop.
<courmisch>
Esmil: if I use earlier version of the last commit, it builds fine
<conchuod>
mmind00: ye looks like a null pointer is being dereferenced in smp cpu bringup code
<mmind00>
conchuod: oh "nice", at least that is a great starting point :-)
<conchuod>
Well, that unfortunately was not the starting point
<conchuod>
I dont get a splat or anything so had to find it :/
tsraoien has quit [Quit: WeeChat 3.5]
tsraoien has joined #riscv
<meowray>
jrtc27: ping on lld relaxation :)
aburgess has joined #riscv
jmdaemon has joined #riscv
EchelonX has quit [Quit: Leaving]
tsraoien has quit [Ping timeout: 268 seconds]
BootLayer has quit [Quit: Leaving]
zjason` has quit [Read error: Connection reset by peer]
zjason` has joined #riscv
tsraoien has joined #riscv
solrize has quit [Ping timeout: 255 seconds]
KombuchaKip has quit [Quit: Leaving.]
KombuchaKip has joined #riscv
<Esmil>
courmisch: do make ARCH=riscv visionfive_defconfig, or update your CONFIG_EXTRA_FIRMWARE