IRC channel logs
2025-02-15.log
back to list of logs
<matrix_bridge><Andrius Štikonas> gtker: I've now merged pointer arithmetic fix for riscv32 and riscv64 (and also x86/amd64 was working before) <matrix_bridge><Andrius Štikonas> and I wouldn't be surprised if arm7a and knight also need some fixes... <stikonas>ok, M2-Planet for aarch64 is now fixed too... <stikonas>hmm, arm and knight might be fine from what I can see without testing <stikonas>oriansj: I know why unxz crashes on RISC-V... <oriansj>stikonas: hmmm, M1 and hex2 should both throw an error if !number or !label exceeds the limits of the prefix size type <oriansj>oh most architectures use express_number and risc-v uses express_word which doesn't bounds check <oriansj>which is probably the root cause for most of the RISC-V bugs in M2-Planet <stikonas>we could have founds this crash (and possibly other crashes ) much earlier <stikonas>yeah, though we don't have that many of them <stikonas>and it's getting late today, so I won't look further <oriansj>and I guess I need to look up the RISC-V integer ranges for the different encoding types <oriansj>(this may break a great many RISC-V programs in the the short term) <stikonas>that's the main limitation that is worth checking <oriansj>I was going to use bound_values(displacement, number_of_bytes, -129, 256); sort of thing <stikonas>so I instructions (! token) is from -2048 to 2047 <oriansj>that is fine, I was planning to redo powerpc using word instead of byte <stikonas>anyway, I'll be going to sleep now. Did quite a bit this evening. Plus gtker is also doing even more work recently <oriansj>hmm U-format seems to drop the bottom 12bits of the immediate <stikonas>I think that's because you are supposed to load high bits with U instruction <oriansj>we may have to change that to not conflict with bounds checking <oriansj>yeah and probably why we skipped bounds checking previously <matrix_bridge><Andrius Štikonas> But otherwise all codegen code in M2-planet and cc_* would be much longer <oriansj>yeah but M1 doesn't touch the labels <oriansj>we also could be slightly less optimal and leverage the same trick we used with armv7l and aarch64 and knight <oriansj>and will fix the 31bit arithmetic bugs in RISC-V as well <matrix_bridge><Andrius Štikonas> We have similar bug everywhere where we load constants... <matrix_bridge><Andrius Štikonas> New riscv pointer arithmetic also breaks with 12 bit sized types <matrix_bridge><Andrius Štikonas> Though that is probably less of a problem in practice <oriansj>hmmm, we don't have J format support <oriansj>so we may need a single hard-coded instruction for the jump-over; also RISC-V doesn't support efficient PC relative loading. So we might need to save the link register in a register, do a jump and link, use the link register to do the relative load, then restore the old link register value. <matrix_bridge><Andrius Štikonas> I think I used @ as a workaround for short numeric jumps <oriansj>we have UJ format with $ (which might just be the old name for J) <oriansj>well, we would be trying to encode approximately jal 4 <oriansj>I'd rather slow and correct over fast and buggy <oriansj>we can also do something more complex where we look at the immediate and if it fits in 12 bits we just do a direct load of the immediate and otherwise do the slower route <oriansj>looks like erc eventually runs out of RAM and crashes <oriansj>irc client that runs in emacs that I use to talk here <stikonas>anyway, I don't think there was much said here while you were away <stikonas>I've merged a couple of PRs from gtker... <stikonas>perhaps one of them is causing the remaining unxz crash <stikonas>and those two assemblies are really similar <stikonas>(but rv32 has smaller pointers, so probably still fit in the bound) <oriansj>or the sign extension behavior of riscv64 is causing the problem <oriansj>as 32bit wouldn't hit any sign extension behaviors on 4byte values