IRC channel logs
2025-03-19.log
back to list of logs
<oriansj>gtker: I said for byte architectures @ for signed 16bit and $ for unsigned 16bit <oriansj>for RISC-V (and other word architectures) there is only $ for 16bit values <oriansj>also a big warning about data alignment in RISC-V; there are some stupid rules involving unaligned (relative to the word) data and RISC-V doesn't work with unaligned instructions. So you may wish to leverage < (to pad things out to the word) after a data block <oriansj>stikonas: one minor point about RISC-V performance. unaligned load could take hundreds of times longer than aligned loads <oriansj>so altering M2libc to do word aligned memory allocations might give RISC-V a big speedup <oriansj>as for the known_issues.org file; we can delete it if you wish. I just had it there to warn people of how M2-Planet isn't a normal C compiler (which honestly is surprising how that got missed given the name) <matrix_bridge><gtker> Stikonas: My bad, it's probably the kast indentation change where I forgot <matrix_bridge><gtker> Oriansj: What counts as bytr archs? Everything other than RISCV? <ekaitz>janneke: sorry for the noisy emails yesterday, i don't know what I did :S <matrix_bridge><Andrius Štikonas> Though some of them would benefit from rework into word like arch <matrix_bridge><Andrius Štikonas> Note how on riscv we construct instruction from individual Opcodes registers, etc... <matrix_bridge><Andrius Štikonas> Well x86 we don't have fixes width instructions <matrix_bridge><gtker> Is that even possible for x86? Doesn't the register value change between instructions? <matrix_bridge><Andrius Štikonas> Well, maybe it is possible in octal rather than hex <matrix_bridge><Andrius Štikonas> But yes, we need to think of something for 16 bits... <matrix_bridge><Andrius Štikonas> Perhaps keeping @ $ for 16 bits and using new one for riscv <matrix_bridge><Andrius Štikonas> Oh I see oriansj already added $ for riscv <matrix_bridge><gtker> stikonas, oriansj: So @ for signed, $ for unsigned and $ for all RISCV? <matrix_bridge><Andrius Štikonas> gtker looking at M1 isn't the only difference between @ and $ is range check? <matrix_bridge><Andrius Štikonas> I think bitwise it will be the same representation <matrix_bridge><Andrius Štikonas> We can distinguish between @ and $ for other arches <matrix_bridge><Andrius Štikonas> (I'm now on my phone, so I wouldn't be.too helpful <matrix_bridge><gtker> Yeah, I see it. Alright. I've got a PR that's going up anyway so I'll add the 2 byte values as well <matrix_bridge><gtker> stikonas, oriansj: Does hex2 not support '$' for RISCV? I'm getting "Target label 13 is not valid" when trying to initialize a value with 13 <matrix_bridge><Andrius Štikonas> gtker: hex2 uses $ for encoding J instruction offsets <matrix_bridge><Andrius Štikonas> But sounds like some immediate meant for M1 made its way to hex2 somehow... <matrix_bridge><Andrius Štikonas> I.e. I would expect $13 to be gone after M1 step <matrix_bridge><Andrius Štikonas> hex2 would be fine with label :13 and $13 jmp <matrix_bridge><gtker> It seems like M1 doesn't handle it correctly for RISCV <matrix_bridge><Andrius Štikonas> Oh we can't do 2 bytes in that function yet <matrix_bridge><Andrius Štikonas> gtker: did M2-Planet tokenizer already support ++ ? <matrix_bridge><Andrius Štikonas> I guess I added that during the last attempt to support ++ <matrix_bridge><Andrius Štikonas> but I got confused by various special cases and eventually reverted it <matrix_bridge><gtker> Yeah, I'm also not sure I'm covering 100% of cases, but it's enough for tcc_1_7 at least <matrix_bridge><Andrius Štikonas> *++ though is fairly common usecase, isn't it? <matrix_bridge><Andrius Štikonas> it might be similar issue as pointer arithmetic with + and - which was also tricky... <matrix_bridge><gtker> If necessary it's probably relatively easy to add later