<gbrlwck>stikonas: `make test-riscv32` fails (i don't think RV32 binaries run on RV64). how/what exactly would you like me to test on HW? <stikonas>gbrlwck: well, if binaries don't run on rv64 then nothing you can do on your hardware... <stikonas>e.g. I can run armv7l binaries on aarch64 box (and obviously x86 on amd64) <stikonas>yeah, maybe some info from that wiki is useful <stikonas>although, it's also not super up-to-date <gbrlwck>i get a "cannot execute binary file: Exec format error" <gbrlwck>i don't think RV32/RV64 was designed to be compatible; the others are bc they were designed to be backwards-compatible <stikonas>I guess RV tries to be as minimal as possible... <stikonas>even though instructions for RV32 and RV64 are almost identical <stikonas>anyway, we can wait until sombody has some RV32 hw... <stikonas>I actually do have but it's not suitable to run Linux... <stikonas>stage0-posix is not designed to run on soldering iron <gbrlwck>well, it's not backwards if they are designed at the same time ;) <gbrlwck>i have some smaller RV32 HW too, but it's too small for a full-fledged linux kernel <gbrlwck>ok, so i know where to order my next soldering iron from <gbrlwck>i'm generally not sure whether i'd seen any RV32 board big enough to run linux <stikonas>maybe there isn't... There aren't even that many RV64 boards <gbrlwck>so... anybody have a FPGA laying around? <gbrlwck>i think this is the most viable option to test on "real" hw ATM <gbrlwck>i'll ask around... i know some people doing hw design and working a lot with risc-v and FPGA's.. if there's already a linux kernel running it should not be much work to test ***Server sets mode: +cnt
***molybdenum.libera.chat sets mode: +oo oriansj ChanServ
***ChanServ sets mode: +o oriansj
<gbrlwck>'re saving a register to a local variable (?).. but why the negation? is the (* n 4) part for alignment? <gbrlwck>i figure (function-locals) is to allocate space on the stack for local variables. why is this necessary? just decreasing the stack pointer (without writing stuff at the intermediate positions) seems of no use <muurkha>to me that looks like it's multiplying the index by 4 because each variable occupies 4 bytes, then subtracting it from 0 to get a negative offset? a difficulty with reading Scheme is that the lack of types makes it hard to figure out what something is supposed to be taking as an argument and what it's supposed to be returning <gbrlwck>muurkha: yeah, i guess something like that... i'll write janneke an email. <gbrlwck>regarding the types thing, i'm pretty sure we're operating on numbers in this context ;) <gbrlwck>aaaah, so #x80 means 1000 0000 in binary and distinguishes negative from positive numbers, right? <muurkha>yes, but I suspect that in this case it's an operand encoding thing, trying to distinguish operands that can be encoded in one byte <muurkha>and sure, everything computers do is "operating on numbers" in the sense that you can interpret any bit pattern as a number <muurkha>the point of types is to be more specific so you can tell when you're doing something wrong <muurkha>or so you can read someone else's code *stikonas is redoing openjdk bootstrap on Gentoo, seems like it was broken by GCC10, so need to apply some fixes... <oriansj>gbrlwck: well to understand the x86 stack, you need to first understand it grows backwards towards zero instead of up to max_address. <oriansj>So every push decrements the stack pointer by the number of bytes pushed. <oriansj>second you can address relative to the stack pointer (ESP) or the base pointer (EBP) rather efficiently <oriansj>base pointer stays the same regardless of pushes and pops; stack pointer changes with every push and pop <oriansj>so every address prior to the base or the stack pointer is a positive value and everything after must be negative <oriansj>now there are 2 ways to deal with local variables in a C function: be lazy and just do a push when you see a new local variable (this is what M2-Planet does and why int i = 0; can't be inside a loop) or you process the function, recording all of the locals needed and set them up on the stack (this is what MesCC does)