IRC channel logs

2021-07-26.log

back to list of logs

<oriansj>as immediates like @5
<stikonas>so R, I, S and U?
<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)
<oriansj>in M1
<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
<oriansj>ok
<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.
<xentrac>i stand corrected!
<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>oh that would work
<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>humans can also use . can't they?
<stikonas>e.g. when writing hex1 code
<stikonas>i.e. hex2 implementation
<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
<stikonas>hmm
<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
<stikonas>that's probably not too bad
<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?
<oriansj>So ~5 LUI and $5 slli
<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.
<xentrac>yay :)
<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>so b foo will actually work
<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
<oriansj>looks likes there are even more fun surprises inside for us: http://inst.eecs.berkeley.edu/~cs61c/resources/su18_lec/Lecture7.pdf
<oriansj>check out page 54
<stikonas>oriansj: yes, I'm aware of that
<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>can this be handled at M1 level?
<stikonas>I'm not yet familiar with M1 well enough to answer that myself
<oriansj>stikonas: absolutely
<stikonas>I guess the only logical place to handle it is the place that splits pseudo instruction into two...
<stikonas>ok, that's good
<oriansj>but it'll look a little weird.
<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
<oriansj>can it install in qemu and do that
<xentrac>yes
<stikonas>oriansj: I just installed qemu and that's it
<stikonas>(on gentoo)
<stikonas>(and compiled riscv toolchain with crossdev)
<vagrantc>oriansj: yeah, should work for that
<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>oriansj: https://wiki.debian.org/RISC-V#Creating_a_riscv64_chroot
<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
<oriansj>looks good even to make a vm
<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.
<Hagfish> https://i.redd.it/wr308dmuydd71.png "Wait, it's all abstraction?"
***ChanServ sets mode: +o oriansj
<fossy>this is annoying... reuse seems to not be properly respecting gitignore
<fossy> https://github.com/thepowersgang/mrustc can do rustc 1.39.. that should make the bootstrap path quite a bit faster
<civodul>nice
<civodul>in other news, i updated mescc-tools and m2-planet in Guix: https://issues.guix.gnu.org/49515#4
<stikonas>fossy: yes, I tried rustc 1.39 bootstrap some time ago. But it only worked on amd64 for me, not on arm64...