<courmisch>
why oh why are scalar operands in widening adds not wide :(
<courmisch>
this keeps screwing up DCTs/DSTs handling of direct coefficients
Stat_headcrabed has quit [Quit: Stat_headcrabed]
davidlt has quit [Remote host closed the connection]
davidlt has joined #riscv
sajattack has joined #riscv
davidlt has quit [Ping timeout: 264 seconds]
leah2 has joined #riscv
rah has quit [Quit: leaving]
billchenchina has joined #riscv
billchenchina has quit [Client Quit]
davidlt has joined #riscv
tlwoerner has quit [Remote host closed the connection]
tlwoerner has joined #riscv
<courmisch>
lu_zero: I could maybe glu rPi heat exchangers if it helps, but I don't really have a cooling solution. Unlike LPi4, this board does not come with a fan
ntwk has quit [Quit: ntwk]
<lu_zero>
courmisch: at least a Gentoo user is fine with that, the bpi-r4 block+fan should be compatible
ntwk has joined #riscv
<lu_zero>
I hoped to have enough spare time to put together the hwmon bits so we have a saner way to get the reading from the sensor
nmeum has quit [Remote host closed the connection]
Andre_Z has joined #riscv
iooi has quit [Quit: iooi]
nmeum has joined #riscv
psydroid has quit [Ping timeout: 240 seconds]
frkazoid333 has joined #riscv
nmeum has quit [Read error: Connection reset by peer]
frkzoid has quit [Ping timeout: 260 seconds]
psydroid has joined #riscv
alexghiti has quit [Ping timeout: 246 seconds]
iooi has joined #riscv
iooi has quit [Read error: Connection reset by peer]
tlwoerner has quit [Ping timeout: 268 seconds]
tlwoerner has joined #riscv
iooi has joined #riscv
Stat_headcrabed has joined #riscv
nmeum has joined #riscv
mlw has joined #riscv
BootLayer has quit [Quit: Leaving]
psydroid has quit [Ping timeout: 252 seconds]
davidlt has quit [Ping timeout: 260 seconds]
mlw has quit [Ping timeout: 268 seconds]
mlw has joined #riscv
psydroid has joined #riscv
mlw has quit [Ping timeout: 268 seconds]
mlw has joined #riscv
mlw has quit [Ping timeout: 246 seconds]
<unlord>
courmisch: you need the scalar inputs to be wide in the widening ops?
JanC has quit [Read error: Connection reset by peer]
mlw has joined #riscv
<courmisch>
unlord: well yeah that would be extremely usegul
<sorear>
i can see both sides here
zjason` is now known as zjason
<sorear>
probably _most_ scalars are small, and some designs will have a penalty for widening the input when it isn't needed
<sorear>
sifive's being one of them according to the llvm scheduling model, sew+sew -> 2*sew is twice the speed of sew+2*sew -> 2*sew for most operations
JanC has joined #riscv
<sorear>
throw it in the "things to try to add if 64-bit opcode space V happens" pile
<courmisch>
I doubt I'd still be doing RVV by that point, unless it was my actual job
<courmisch>
sorear: I guess it makes sense for hardware then
davidlt has joined #riscv
<unlord>
courmisch: which transforms?
heat has joined #riscv
BootLayer has joined #riscv
n_crm_ has quit [Changing host]
n_crm_ has joined #riscv
Amanieu has quit [Ping timeout: 240 seconds]
confusion has joined #riscv
<confusion>
can someone tell me why the immediate `4` of `jal x0, 4` encodes to `0000 0000 0100 0000 0000` and not `0100 0000 0000 0000 0000`? im so confused
<confusion>
i dont understand how to decode this
<sorear>
what's that syntax supposed to be? wouldn't 4 be ....0100 in binary?
<confusion>
thats what i meant
<confusion>
do i have to like rotate to the left by 8 bits or?
<sorear>
have you read 2.3. Immediate Encoding Variants ?
davidlt has quit [Ping timeout: 264 seconds]
<confusion>
i have read the spec over and over. "...and by 1 bit to form J immediates" so for `jal x0, -4` you shift `1111 1111 1101 1111 1111` to the left by 1 bit and then you get 111111111101111111110 which is not -4
<sorear>
Where did you get 1111 1111 1101 1111 1111 from?
<sorear>
that paragraph is meaningless, nothing is ever shifted, refer to the diagrams
<sorear>
it shows you what bits are where for J-type immediates
<confusion>
why does it show multiple imms?
<confusion>
there is only one imm
<confusion>
if i understood the diagrams...
<confusion>
why are there 2 sign bits 20 and 11?
<sorear>
those aren't sign bits
<confusion>
in what ways do i have to put these two imms and sign bits together to get -4?
<confusion>
whatever those bits are you know
<sorear>
[20] is short for imm[20]
<sorear>
which is bit 20 of the immediate
<sorear>
imm[10:1] is bits 10 through 1 of the immediate
<confusion>
thats where i got that example from 1111 1111 1101 1111 1111
<sorear>
so you need to extract 4 parts of the immediate, imm[20] (1 bit), imm[10:1] (10 bits), imm[11] (1 bit), imm[19:12] (8 bits) and then concatenate those parts
alexghiti has joined #riscv
<confusion>
isnt the result of concatenating that the same as those 20 bits in full anyway?
<confusion>
1 + 10 + 1 + 8 = 20
<sorear>
no because you're concatenating them in a different order
<confusion>
in which order?
<sorear>
if you did 20 then 19:12 then 11 then 10:1 it would be the same as the 20 bits in full
<confusion>
the order you listed them is the same as the diagram
<confusion>
yes
<sorear>
but you're doing 20 then 10:1 then 11 then 19:12
<confusion>
but that is the same order as the diagram which is the same order as what the imm in the opcode will already be in no?
<sorear>
"imm" in the diagram is the actual immediate value, so `1111 1111 1111 1111 1111 1111 1111 1100` for -4
<confusion>
so in 1111 1111 1101 1111 1111 which is only the imm part of `jal x0, -4`, the first 1 is not [20]? the 10 bits after are not 111 1111 110?
<sorear>
you pull out `imm[20]` which is `1`, `imm[10:1]` which is `111 1111 110`, `imm[11]` which is `1`, `imm[19:12]` which is `1111 1111` and put them together in that order
davidlt has joined #riscv
<sorear>
yes the first 1 is imm[20], the next 10 bits are imm[10:1] and are 111 1111 110
<confusion>
I put them together in the order of 20, 10:1, 11, and then 19:12, right? so I get 1111 1111 1101 1111 1111, no?
<sorear>
yes? that's what's in the high 20 bits of the instruction according to the link you just posted
<confusion>
but that is not -4
<confusion>
I want to decode it to -4
<sorear>
if you're decoding you reverse the process
<confusion>
oh so the order is 20, 19:12, 11, 10:1 when decoding
<sorear>
the first bit is imm[20] (and implicitly imm[31:21] because of sign extension), so imm is `1111 1111 1111 ???? ???? ???? ???? ????`
<sorear>
the next ten bits are imm[10:1], so imm is `1111 1111 1111 ???? ???? ?111 1111 110?`
<sorear>
the next bit is imm[11], so imm is `1111 1111 1111 ???? ???? 1111 1111 110?`
<sorear>
the remaining bits are imm[19:12], so imm is `1111 1111 1111 1111 1111 1111 1111 1100`, with imm[0] always being 0 for the J-type
<confusion>
and then how do I take -4 from that?
<confusion>
the last 4 bits are -4
<confusion>
but taking the last 4 bits won't always work
<confusion>
ooh I do the two's complement conversion by inverting and adding 1 I guess
confusion has quit [Remote host closed the connection]