<xentrac>I mean you need relative offset computation for auipc, which is necessary if you want to load a function pointer address in position-independent code (or the address of a constant) <xentrac>and doing it with auipc is normally a lot less hassle than doing it in a non-position-independent way <oriansj>xentrac: so you want hex2 to support U format as well? <stikonas>yeah, I used auipc when I tried writing hex1_x86 <xentrac>well, I think hex2 should support whatever stikonas thinks it should support, since he's the one hacking on it <oriansj>so SB, UJ and U in hex2 but R, I and S in M1? <xentrac>I was just pointing out that relative address computation is useful for auipc as well as branches <oriansj>well hex2 is dealing with relative addressing mostly (only &label tends to be used for absolute addresses) <stikonas>I didn't really do any hacking on hex2... <stikonas>well, I can be done in both, I is not mangled <oriansj>stikonas: I can hack it together for you. Just wanted to be clear in what you needed. <oriansj>and I am going to use . to just xor in blocks made by M1 <stikonas>hmm, actually in hex1_x86 I only used auipc with 0 <oriansj>So .000000CD . 00BF0000 A0000000 => A0BF00CD written out <stikonas>will be easier that doing it in 6 different blocks <oriansj>well it might result in 6 different .hex statements in the hex2 input but it will be simpler to implement <stikonas>yes, xor should be cheaper than shifting bits <oriansj>but that will only occur with M1 generated output and not in any human written cases <stikonas>might be even easier to write later hex files... <oriansj>stikonas: if they wanted but it would effectively just mean read the next 4 bytes and xor them with this hold register that will be xor'd with the next 4 hex bytes recieved before output. <stikonas>as it will be just a simple replace of strings from when converting .M1-> hex2 <oriansj>yeah the DEFINEs for everything but the instructions become .hex and the instructions just become a full word with zeros where things are to be filled in by hex2 via .hex <oriansj>So Register 1 will have 3 different defines depending on if it goes in rs1, rs2 or rd <oriansj>an R-Type instruction would have just a DEFINE and 3 Register DEFINEs used <oriansj>which would be a single hex block and 3 .hex blocks before it <oriansj>so R1_0 R2_1 R3_2 ADD for ADD R1, R2, R3 <stikonas>yeah, that will be much easier than .S->.hex0 conversion I did... <oriansj>with the R1_0, R1_1 and R1_2 having different defines as those register locations are 3 different spots in the word <oriansj>(Just an idea you can steal, improve or ignore) <stikonas>hmm, there might also be an issue with those pseudoinstructions (in particular ones that have auipc in them) <stikonas>basically immediate is split between two instructions <oriansj>stikonas: well that would be in M1 right? <stikonas>well, I guess M1 should be fine for that <stikonas>in any case we don't need big jumps/loads before M1 <oriansj>and we can have M1 know to chop off the top or bottom depending on what instruction format it is <oriansj>It'll disable range checking for those formats and make some bugs harder to find but I can squeeze it in <oriansj>with luck I could have prototypes up by Monday and hopefully someone more familiar with RISC-V instruction encoding could tell me where I am a moron. <oriansj>Then RISC-V stage-posix development should become easier for you stikonas. <stikonas>well, it's not like I'm familiar with RISC-V instructions encoding, having done just once but it sounds plausible <oriansj>well getting M1 code to work is much easier than hex0 and once you go to convert to hex0/hex1/hex2 it becomes a line by line exercise with the checksum being identical every step of the way. <oriansj>as M1+blood-elf => fully debuggable binary with labels for functions and globals and gdb doesn't have to act like it is a stripped binary. <oriansj>b _start will work if you do :_start in your M1 code <oriansj>just need to remember to use the debug hex2 ELF-headers <oriansj>which we probably need to include in mescc-tools along with non-debug elf headers for RISC-V <oriansj>as ironically the person who did RISC-V work previously didn't think mescc-tools users needed to be able to create RISC-V posix binaries. <stikonas>yeah, should be easier with blood elf, although in the end layout asm in gdb does let you debug some things <stikonas>that's what I was thinking about when I said "basically immediate is split between two instructions" <stikonas>it's mention in riscv isa in the section about pseudoinstructions (loading address of symbol) <stikonas>I've only read a few pages of that documentation and already stumbled on this <stikonas>I'm not yet familiar with M1 well enough to answer that myself <stikonas>I guess the only logical place to handle it is the place that splits pseudo instruction into two... <oriansj>For example the pseudo instruction: li x10, 0xDEADBEEF would need to be written ~0xDEADBEEF x10_0 LUI @0xDEADBEEF x10_0 x10_1 ADDI <oriansj>as the immediate would be needed in both WORDs <oriansj>does anyone know a good distro for RISC-V development? <oriansj>So even if just in a qemu vm, that I can do some sanity checking <vagrantc>only have experience with debian on RISC-V <oriansj>vagrantc: I just need sshd, gdb, binutils and any text editor and any shell <stikonas>oriansj: I just installed qemu and that's it <stikonas>(and compiled riscv toolchain with crossdev) <oriansj>vagrantc: I'm guessing install images in a place I don't know to look at <oriansj>unless it is part of the multi-arch cd <vagrantc>and then you can dump that into a rootfs for your virtual machine <vagrantc>it's not a release architecture on debian yet, so i'm not sure there's an installer yet <vagrantc>yeah, it's useable ... occasionally some issues still <oriansj>vagrantc: my needs are extremely minimal. just enough to hex bang a couple minimal instruction tests out for risc-v <oriansj>well looks like using rasm2 to guess at RISC-V instruction encoding is not going to be very productive. ***ChanServ sets mode: +o oriansj
<fossy>this is annoying... reuse seems to not be properly respecting gitignore <stikonas>fossy: yes, I tried rustc 1.39 bootstrap some time ago. But it only worked on amd64 for me, not on arm64...