<sorear>
what you've described only makes sense for the "r" constraint - 64-bit values can already be passed as "m" or "A" with obviously different behavior
<sorear>
I'm more inclined to use a new letter for zdinx/zacas/zilsd style register pairs (note that, as a special case, x0/x0 is allowed but x0/x1 is not)
seasharp has joined #riscv
esv has quit [Remote host closed the connection]
esv has joined #riscv
<cousteau_>
Hmm... in fact, isn't what I said how it works for x86_64 inline assembly? You just specify "r" (var) and then it becomes %e*x or %r*x depending on whether var is 32 or 64 bits. You don't specify any modifier or any letter other than "r", if I understood correctly
<sorear>
x86_64 architectural registers are 64 bits, if you want register pairs on x86_64 you need to go to 128 bits
<cousteau_>
But you could say that in RV32I there are 64-bit registers too, named x2, x4, x6, x8... And each of these registers is divided into two individually addressable 32-bit registers; for example, the 64-bit x6 register is divided into the 32-bit x6 register (which happens to have the same name) and x7. It's a stretch from a technical definition, but you could tell that small lie to the compiler to have it work.
damian101 has joined #riscv
<cousteau_>
In a similar way, if I understand correctly, x86_64 has %rax and %eax, but %eax is part of %rax so overwriting %eax modifies %rax and vice versa.
<cousteau_>
What I mean to say is, I believe that this would be supported in gcc inline asm.
Tenkawa has joined #riscv
<cousteau_>
Can confirm that asm ("add %0, %1" : "+r" (x) : "r" (y)) produces different assembly code depending on the type of x and y: "add %eax, %esi" if 32b, "add %rax, %rsi" if 64.
<cousteau_>
In short... Are we even sure that gcc doesn't already implement register pairs for RV?
Leopold has joined #riscv
<sorear>
You realize that neither of those is a register pair?
<cousteau_>
(*Can confirm that *in x86_64*, asm...)
<cousteau_>
sorear: no, but the behavior is similar
<cousteau_>
%eax is part of %rax
<cousteau_>
x6 is part of the 64-bit x6/x7 pair
<sorear>
it really isn't. "add %eax, %esi" is semi-intel syntax for the at&t "addl" instruction, "add %rax, %rsi" "addq", operating on the same architectural register 0
<cousteau_>
But gcc doesn't need to know that to work, right?
<sorear>
it needs to know for the purposes of register allocation that there are 15 "general registers" which it can allocate, and not try to put one value in "eax" and a different value in "rax"
<sorear>
I don't know how that's modeled exactly
<sorear>
you do need a subregister model if you want to put two different 8-bit values in "al" and "ah"
<cousteau_>
gcc just saw me write asm() and pass it a 32-bit variable, and said "OK, I need to use %eax", and then use a 64-bit variable and said "%rax it is". So that part seems to be OK; I seem not to need any special modifier to specify a 32 or 64 bit register.
<sorear>
is there a reason you're talking about riscv32 and x86_64? it'd be less confusing if you picked an XLEN and stuck with it
<cousteau_>
Yes, the reason is that I see a certain parallelism between RV32I register pairs and x86_64 %r* 64-bit registers.
<sorear>
x86_64 *has* register pairs though. if you pass an int128_t to asm, does it get put in %rdx:%rax ?
<cousteau_>
OK, I did not know that
<cousteau_>
Anyway. My question was, what would be necessary to implement support for dual registers in RISC-V in the GCC toolchain (for extensions that use those)?
<cousteau_>
The answer seems to be that it can be done without changes to the asm() "API"
<sorear>
Ideally, we'd be making decisions about the asm() API for human factors reasons, not "what's easiest to implement in gcc"
<sorear>
it needs to be compatible between gcc and clang, and the number of people writing or reading asm() blocks is far greater than the number of people making asm() itself work
<cousteau_>
(but further changes in the handling of registers would be necessary... this is, unless it has already been implemented!)
<cousteau_>
I see. My point would also be "how is this done in other ISAs? Let's make it similar. "
<sorear>
strong agree
<sorear>
the closest thing I've found on modern architectures is the aligned register pairs in SPARC
<sorear>
gcc has "U Even register" but I'm not sure if that's actually relevant
<sorear>
the LEON test code is using "r" for double-register values, maybe that's precedent enough
tlwoerner has quit [Remote host closed the connection]
tlwoerner has joined #riscv
<cousteau_>
I think asm() does not actually require any special modifier to explicitly say that a variable is associated with a 32-bit or a 64-bit "register". You just pass a 32-bit or 64-bit variable and it figures out how to handle it.
<cousteau_>
In the case of x86_64, this means it'll generate "%eax" or "%rax" (which are kind of the same registers, but the point is that gcc knew which name to use)
<cousteau_>
In the case of RISC-V, it could mean deciding whether to use a "double register" (assuming the instruction supports those) or a regular 32-bit register. They just happen to be named the same ("a0" may refer to the 32-bit a0 register, or to the 64-big a0/a1 pair, depending on the instruction)
Leopold has quit [Ping timeout: 260 seconds]
<cousteau_>
OK now I definitely need to go to sleep. Good night!
KREYREN has quit [Remote host closed the connection]
Armand has quit [Ping timeout: 246 seconds]
Armand has joined #riscv
Tenkawa has quit [Quit: Was I really ever here?]
jfsimon1981 has quit [Read error: Connection reset by peer]
damian101_ has joined #riscv
jfsimon1981 has joined #riscv
damian101 has quit [Ping timeout: 268 seconds]
Leopold has joined #riscv
<dh`>
sparc a modern architecture? :-)
somlo_ has joined #riscv
somlo has quit [Ping timeout: 252 seconds]
duckworld has quit [Ping timeout: 264 seconds]
<sorear>
my other lead was Blackfin, and between the two of those I think it's obvious who gets 'modern'
<sorear>
even if OSA2015 renamed ldd to ldtw for some reason
duckworld has joined #riscv
tlwoerner_ has joined #riscv
Bluefoxicy_ has joined #riscv
knielsen_ has joined #riscv
helium-3 has joined #riscv
tux3_ has joined #riscv
ssb_ has joined #riscv
Maylay_ has joined #riscv
tlwoerner has quit [*.net *.split]
knielsen has quit [*.net *.split]
dilfridge has quit [*.net *.split]
Maylay has quit [*.net *.split]
Bluefoxicy has quit [*.net *.split]
sajattack has quit [*.net *.split]
Pokey has quit [*.net *.split]
tux3 has quit [*.net *.split]
ssb has quit [*.net *.split]
kgz has quit [*.net *.split]
Bluefoxicy_ is now known as Bluefoxicy
Pokey has joined #riscv
sajattack has joined #riscv
esv has quit [Ping timeout: 260 seconds]
jacklsw has joined #riscv
patersonc_ has joined #riscv
The_Decryptor8 has joined #riscv
paulbarker_ has joined #riscv
shreyasminocha_ has joined #riscv
mmind00_ has joined #riscv
hl has joined #riscv
pavelow has joined #riscv
bjoto` has joined #riscv
benh_ has joined #riscv
roxell__ has joined #riscv
pavel_odintsov_ has joined #riscv
patersonc has quit [Ping timeout: 240 seconds]
patersonc_ is now known as patersonc
abelvesa_ has joined #riscv
rsalveti_ has joined #riscv
jleightcap_ has joined #riscv
gatecat_ has joined #riscv
mturquette_ has joined #riscv
sskras_ has joined #riscv
theruran_ has joined #riscv
lu_zero_ has joined #riscv
pld_ has joined #riscv
paulbarker has quit [Ping timeout: 240 seconds]
paulbarker_ is now known as paulbarker
ConorDooley has joined #riscv
geertu_ has joined #riscv
GordonH has joined #riscv
NishanthMenon_ has joined #riscv
edef_ has joined #riscv
nathanchance_ has joined #riscv
shachaf_ has joined #riscv
khilman_ has joined #riscv
sorear_ has joined #riscv
Kedleston_ has joined #riscv
h2t has joined #riscv
geist_ has joined #riscv
troglodi1o has joined #riscv
Pegazusuo-- has joined #riscv
Pegazusuo-- has left #riscv [#riscv]
tlwoerner_ has quit [Quit: Leaving]
Pokey has quit [*.net *.split]
DesRoin has quit [*.net *.split]
DoubleJ has quit [*.net *.split]
q66 has quit [*.net *.split]
Kedleston has quit [*.net *.split]
ZipCPU has quit [*.net *.split]
JTL has quit [*.net *.split]
vgtw has quit [*.net *.split]
edef has quit [*.net *.split]
puranjaymohan has quit [*.net *.split]
gordonDrogon has quit [*.net *.split]
khilman has quit [*.net *.split]
zups has quit [*.net *.split]
kaol has quit [*.net *.split]
wigyori has quit [*.net *.split]
tlwoerner has joined #riscv
Kedleston_ is now known as Kedleston
khilman_ is now known as khilman
Pokey has joined #riscv
abelvesa has quit [*.net *.split]
mmind00 has quit [*.net *.split]
pld has quit [*.net *.split]
gatecat has quit [*.net *.split]
pavelow_ has quit [*.net *.split]
seds has quit [*.net *.split]
sorear has quit [*.net *.split]
h2t_ has quit [*.net *.split]
hl_ has quit [*.net *.split]
pavel_odintsov has quit [*.net *.split]
rsalveti has quit [*.net *.split]
conchuod has quit [*.net *.split]
haritz has quit [*.net *.split]
jleightcap has quit [*.net *.split]
shreyasminocha has quit [*.net *.split]
roxell_ has quit [*.net *.split]
bjoto has quit [*.net *.split]
theruran has quit [*.net *.split]
unlord has quit [*.net *.split]
benh has quit [*.net *.split]
cow321 has quit [*.net *.split]
geertu has quit [*.net *.split]
The_Decryptor has quit [*.net *.split]
lu_zero has quit [*.net *.split]
troglodito has quit [*.net *.split]
shachaf has quit [*.net *.split]
nelnire has quit [*.net *.split]
nathanchance has quit [*.net *.split]
NishanthMenon has quit [*.net *.split]
geist has quit [*.net *.split]
mturquette has quit [*.net *.split]
gatecat_ is now known as gatecat
pavel_odintsov_ is now known as pavel_odintsov
The_Decryptor8 is now known as The_Decryptor
geist_ is now known as geist
nathanchance_ is now known as nathanchance
sorear_ is now known as sorear
ConorDooley is now known as conchuod
pld_ is now known as pld
NishanthMenon_ is now known as NishanthMenon
rsalveti_ is now known as rsalveti
sskras_ is now known as sskras
shreyasminocha_ is now known as shreyasminocha
jleightcap_ is now known as jleightcap
mturquette_ is now known as mturquette
felixonmars has quit [Excess Flood]
unlord has joined #riscv
BootLayer has joined #riscv
duckworld has quit [Ping timeout: 250 seconds]
DoubleJ has joined #riscv
vgtw has joined #riscv
JTL has joined #riscv
puranjaymohan has joined #riscv
q66 has joined #riscv
ZipCPU has joined #riscv
DesRoin has joined #riscv
zups has joined #riscv
kaol has joined #riscv
wigyori has joined #riscv
seds has joined #riscv
cow321 has joined #riscv
kaol has quit [Ping timeout: 260 seconds]
kaol_ has joined #riscv
q66 has quit [Ping timeout: 260 seconds]
wigyori_ has joined #riscv
zups has quit [Ping timeout: 260 seconds]
wigyori has quit [Ping timeout: 260 seconds]
zupss has joined #riscv
Pegazusao-`_ has joined #riscv
haritz has joined #riscv
nelnire has joined #riscv
<Pegazusao-`_>
RADIO SUPER NETS IS LIVE CALL IN NOW 1-877-293-1933
Pegazusao-`_ has left #riscv [FUCK THE SAND NIGGERS JOIN IRC.EFNET.ORG FOR THE RESISTANCE]
theruran_ is now known as theruran
<palmer>
there's some global message about some spam, looks like this one's gone already?
puranjaymohan_ has joined #riscv
duckworld has joined #riscv
puranjaymohan has quit [Ping timeout: 260 seconds]
puranjaymohan_ is now known as puranjaymohan
nshire has joined #riscv
nelmire has joined #riscv
nelnire has quit [Ping timeout: 240 seconds]
felixonmars has joined #riscv
q66 has joined #riscv
JTL has quit [Max SendQ exceeded]
vgtw has quit [Max SendQ exceeded]
vgtw has joined #riscv
JTL has joined #riscv
rsjw has quit [Quit: leaving]
mlw has joined #riscv
rsjw has joined #riscv
rsjw has quit [Client Quit]
Noisytoot has quit [Ping timeout: 256 seconds]
Noisytoot has joined #riscv
rsjw has joined #riscv
Stat_headcrabed has joined #riscv
rsjw has quit [Quit: leaving]
damian101_ has quit [Ping timeout: 256 seconds]
mlw has quit [Ping timeout: 240 seconds]
billchenchina has quit [Remote host closed the connection]
Leopold has quit [Remote host closed the connection]
Nixkernal has joined #riscv
<courmisch>
sorear: if SUB were an alias for RSUB, then the corresponding opcode under OP-IMM would be free for RSUBI. Of course, it's a decade late for that. I just wonder if there was a *reason*
<courmisch>
or just a case of not thinking about it during the design
coldfeet has joined #riscv
lu_zero_ is now known as lu_zero
shachaf_ is now known as shachaf
lu_zero has quit [Changing host]
lu_zero has joined #riscv
shachaf has quit [Changing host]
shachaf has joined #riscv
GenTooMan has quit [Ping timeout: 260 seconds]
jfsimon1981 has quit [Remote host closed the connection]
jfsimon1981 has joined #riscv
hightower2 has joined #riscv
jacklsw has quit [Ping timeout: 268 seconds]
<cousteau_>
courmisch: that's a good point... Or would be, if it weren't for the fact that ADD and SUB have the same opcode, and only differ by one bit within the imm12 field
<cousteau_>
I guess an RSUBI instruction could have been added. The 8 f3 functions in the opcode are already used, but they could've combined all the shift left/right instructions into one and free one f3 code, which could be used by RSUB[I]
cousteau has joined #riscv
<cousteau>
I wonder how common an operation it is to flip the sign of a register and add/subtract an offset. Maybe it was deemed unnecessary?
<cousteau>
y = 100 - x; and the like
<cousteau>
(...yeah, probably would make sense to have)
<cousteau>
I'm trying to see if adding this would've had an impact on resource usage, but I don't think it would. It would add one extra instruction to the list though.
<cousteau>
So I've been trying to read riscv.md (to figure out if it handles double-width words), and have realized that I can't
KREYREN has joined #riscv
<cousteau>
My pet theory is that handling of dwords (DImode words in RV32) is already implemented but nobody realized. I don't know how to test this theory though.
<cousteau>
...OK, first question: in RV32 default ABI, a function `int64_t f(int64_t x, int32_t y, int64_t z)` will store x in {a1,a0}, y in a2, and z in {a4,a3}, is that correct? Or is godbolt messing with me?
<cousteau>
This is, `z` is not aligned to an even register!
unlord has quit [Ping timeout: 252 seconds]
unlord has joined #riscv
EchelonX has quit [Quit: Leaving]
<cousteau>
"Scalars that are 2×XLEN bits wide are passed in a pair of argument registers, with the low-order XLEN bits in the lower-numbered register and the high-order XLEN bits in the higher-numbered register. If no argument registers are available, the scalar is passed on the stack by value. If exactly one register is available, the low-order XLEN bits are passed in the register and the high-order XLEN bits are passed on the stack." -- ok, this leaves very
<cousteau>
little room for ambiguity.
<cousteau>
That text doesn't say anything about aligning 2×XLEN words to even-numbered registers, and even considers the possibility of passing half such word on a register (a5 or a7) and the other half on the stack.
<sorear>
note that if the argument is passed on the stack, it's aligned, and if the argument is _anonymous_, it goes into an even register so that it becomes aligned when the va_arg save area is created
<cousteau>
So... that sounds an awful lot like the ABI doesn't do "register pairs", so I don't think I could expect asm() to do so when I pass a 2×XLEN variable.
<cousteau>
OK, noted :)
pecastro has joined #riscv
<sorear>
"put it in an even/odd register pair" is an entirely reasonable thing for int64_t "r" riscv32 to do. I can see nonstandard extensions possibly doing other things though
<sorear>
now that zacas and zdinx are both ratified and have identical behavior, maybe it makes sense to use "r" for it
<cousteau>
cool!
<cousteau>
But in principle it is not implemented yet, right?
<sorear>
I checked the P working drafts last night, it uses even/odd pairs but is silent about x0 behavior so it may or may not be compatible
<sorear>
the gcc machine descriptions are completely incomprehensible to me so I can't answer that
<cousteau>
I'm asking because I need to do that with an extension (XIF) and the solution I eventually figured out (or rather, this channel told me to do) is quite complex, so I want to make sure that's the real way to do it before I tell my coworkers "here, this is how to do it"
<cousteau>
P being RVP, right?
<sorear>
yes (the drafts on the mailing list are substantially more up to date than what's on github)
<cousteau>
sorear: oh wait, you can't read .md files? Ha ha, how silly you are. I can read them just fine. (sarcasm)
<sorear>
at least intercal has an manual that explains what all of the letters mean
<cousteau>
Ah cool, good to know, I recently got the P draft somewhere, probably github, so it was probably outdated then
<cousteau>
I was thinking, if asm() will align 2xXLEN words to even boundaries, maybe the calling convention should too. It's not much of a problem, but right now calling asm() with a wide function argument that happens to be unaligned will require copying that argument to an aligned area instead of using it directly
<cousteau>
I thought of an amendment to the ABI saying that "and if the argument is 2xXLEN, and it would start on an odd (unaligned) register, then you have to pad it as if the previous arg were also 2xXLEN"
<cousteau>
And possibly "and if a 1xXLEN argument comes afterwards, you cram it in that space you left behind", but that'll complicate things a lot, especially when va_args are involved
<cousteau>
So... maybe better to just leave them unaligned, or (if anything) align them using padding (how wasteful!)
<cousteau>
"In the base integer calling convention, variadic arguments are passed in the same manner as named arguments, with one exception. Variadic arguments with 2×XLEN-bit alignment and size at most 2×XLEN bits are passed in an aligned register pair" -- oooh nice! Disregard what I said before; this option seems promising.
<cousteau>
I hereby introduce the ILP32A* variants for ILP32* ABIs, which Aligns these arguments on regular function calls too
<cousteau>
(I was thinking if the ABI could be amended, but it can't becase of backward compatibility; so the only way is to create a new one)
<sorear>
we have too many ABIs already, there'll be close to zero support for adding another one just to save a couple of c.mv
<cousteau>
ok fair enough
<cousteau>
I had a better idea. When I create a function that will need aligned wide words, I'll order the parameters in a way that makes sense myself.
kaol_ is now known as kaol
coldfeet has quit [Remote host closed the connection]
Stat_headcrabed has joined #riscv
damian101 has joined #riscv
Tenkawa has joined #riscv
khem has joined #riscv
Stat_headcrabed has quit [Quit: Stat_headcrabed]
BootLayer has quit [Quit: Leaving]
felixonmars has quit [Remote host closed the connection]
felixonmars has joined #riscv
zjason`` has quit [Read error: Connection reset by peer]