<stikonas>luckily the fix was easy and didn't change number of instructions, so could be easily backported to hex1 <stikonas>this slow me down a bit with cc_riscv64 coding though... But now some simple expressions are starting to work... <stikonas>relational expressions (a<b) are somewhat awkward to implement for risc-v in M1 assembly. Fortunately, S and B encodings are identical for small numbers. so something like this works RS1_A0 RS2_A1 @8 BLT in order to branch 8 bytes forward <oriansj>also why would relational expressions be awkward? isn't there compare instructions which put the compare result in a register for use? <xentrac>well, there's a subtract instruction, yeah <xentrac>but the compare instructions are actually conditional branch instructions <xentrac>like stikonas[m]'s example of blt a0, a1, .+8 <oriansj>jump if register is negative/positive or zero instructions? <xentrac>there's a zero register, so you can use beq and bge with the zero register as one operand <oriansj>doesn't really help for longer jumps <xentrac>that gives you "jump if register is zero", and "jump if register is nonnegative" <xentrac>yeah, for longer jumps you can jump over an unconditional jump <oriansj>So RISC-V just will have to have a register load, 2 unconditional jumps and a compare with a fixed jump. <xentrac>I-type JAL gives you a 2-mebibyte jump range, which is probably enough to get to something like GCC <xentrac>JALR is I-type and can jump anywhere, at the cost of first loading the jump destination into a register, or most of it anyway <xentrac>yeah, that's definitely a workable solution. just, as stikonas[m] said, somewhat awkward <oriansj>32bit jump range is kinda the standard for M2-Planet. The smallest right now is 24bit (ARMv7l) <xentrac>which is 2 mebibytes instead of 1 because it's counted in 16-bit parcels <xentrac>if you want portability, it's somewhat simpler to program in a format where you have a BLT operation that then breaks down into two instructions (a compare and a conditional branch) on amd64 and arm, than to have separate compare and conditional branch operations in the source, where the compare operation stores its results in a register, and then the conditional branch operation compiles into all <xentrac>amusingly, amd64 implementations go to the trouble of recognizing the instruction pair and re-merging it into a RISC-V-like compare-and-branch "macro-op" <oriansj>well well variable length instruction encoding is a much better match for compare and branch than fixed length instruction encoding. <xentrac>in the context of the C extension, LUI seems kinda goofy <xentrac>why not just have a 6-byte instruction format with a 32-bit immediate? but they didn't <xentrac>AUIPC is a little more immediate, and AUIPC+JALR gives you a 32-bit jump range <oriansj>well instructions are supposed by be 16bit packet based if I remember correctly. So no clue on what their decision making progress but they probably write it in their book I didn't buy. <xentrac>right, they're divided into 16-bit parcels <xentrac>the book I think you're thinking of is free (of charge) in Spanish and some other languages, but not in English <xentrac>but so far I haven't found any material in it that isn't in the RISC-V spec, just prettier colors and more enthusiastic cheerleading, which the RISC-V spec is blessedly free of, unlike Intel manuals ***ChanServ sets mode: +o oriansj
***ChanServ sets mode: +o janneke
***tungsten.libera.chat sets mode: +o ChanServ
***ChanServ sets mode: +o oriansj
<oriansj>xentrac: well praising the good parts of one's own work is natural. It is the admitting of one's own mistakes and flaws that is most healthy in technical matters and so rarely done. <stikonas>oriansj: I think longer jumps can still be implemented via pseudoinstructions, so we are not limited to 20 bits... <stikonas>riscv specs pdf defines call pseudoinstruction which is auipc + jalr <stikonas>should be possible to call far-away functions with it <stikonas>once you reach TCC, that's up to TCC to deal with all that stuff <stikonas>and function calls in cc_* and I guess M2-Planet are implemented by calling it via register <oriansj>stikonas: well there are two types of function calls in M2-Planet; passed function pointers and static function calls. The first has to be passed in a register (otherwise we would have to support polymorphic code) and the second is the one that RISC-V will probably might need some considerations. <oriansj>as most architectures it is just call %label or ~label call <oriansj>but stikonas; you probably know RISC-V much better than me on what would probably be the closest mapping which would work. <stikonas[m]>We can still load address of label into register if we want long jump... <oriansj>so load R5 &label jalr R5 will probably work (with RISC-V specific needed tweaks of course) <oriansj>but to be honest, I have not kept up on MesCC's RISC-V progress and if it resulted in greater requirements. <oriansj>well lack of RISC-V support in mescc-tools probably was the biggest issue. Hopefully know that you have helped solve those issues stikonas, they might be able to make progress now. <stikonas[m]>Yeah, I can see some code generation commits in mescc but looks more like gas syntax <stikonas[m]>Well, we indeed didn't have anything in mescc-tools until recently <oriansj>well we had the --flags setup for RISC-V and a #define matching the ELF numbers but not actually anything to help in making real RISC-V binaries ***dongcarl1 is now known as dongcarl
<xentrac>oriansj: the RISC-V spec only mentions a couple of mistakes and flaws, but I suppose it's new enough that if they thought some decision was bad they would have just changed it <oriansj>or put it under a depreciation version.