<stikonas>hmm, something is more messed up with hex2 (C version) on riscv :( ***KM4MBG is now known as Jack-KM4MBG
<stikonas>"Target label Failult_file is not valid" <stikonas>that looks like some memory corruption.... <fossy>oh hell YES this is soooo much nicer with an actual modern linux kernel :DDDD <stikonas>and hopefully that smaller kernel can be used before linux too... <fossy>after i fixed up the kernel config the serial works properly <fossy>yeah i plan to look at that reasonably soon <fossy>just need to finish checksums then this massive as hell PR is done <stikonas>well, right now I was busy with riscv work... <stikonas>maybe I'll have kaem-minimal done by the end of this week <fossy>i haven't tried doing hex* coding yet, i don't imagine it is tooo fun <stikonas>a bit easier once I followed oriansj suggestion to go via .S -> .M1 -> .hex2 -> hex0 route <stikonas>.S ->.M1 is just slightly different assembly syntax <stikonas>.M1 -> .hex2 (which I'm doing now) is now pasting the defines for each word and adding them up <stikonas>well, first I had to write assembly version too... That also took some time ***Jack-KM4MBG is now known as jackhill
<fossy>right, i guess that would help <fossy>.hex2 -> .hex0 is probably going to be hardest, heaps of calculations to do i imagine? ***rt is now known as robin
<oriansj>stikonas: last night I finished RISC-V support in M1 (my internet went down until just now) I've uploaded it. Plesae test to see if it behaves like you expect or if I have to do something to fix it. <stikonas>oriansj: I need to send another two changes to hex2 first <oriansj>and I merged your mescc-tools pull request <stikonas>need to add 0 to scratch array to terminate string and there off by one instruction error in ! calculation <oriansj>I'm guessing you missed the clearing of scratch <oriansj>easy mistake to make (I've done it more times than I like to admit) <oriansj>stikonas: entirely possible as this was entirely thrown together as a best guess. <xentrac>oriansj: that's wonderful! congratulations! <oriansj>one thing that might be checked is if the jump offsets are correct or need a +/- 4 to handle with the .hex behavior <stikonas>oriansj it's an easy thing to miss there. By the time we use addi woth ! we are one instruction later after auipc <oriansj>Hagfish: in regards to the ocean language; C family languages are really easy to create and the biggest problem is avoiding the temptation to add more on top. <xentrac>what kind of attractive nuisances do people cram in there? <Hagfish>oriansj: yeah, the HN comments suggested that the project looked like it was going to fall victim to that <Hagfish>i can't remember exactly what the picked up on, but the discussion started talking about some feature from golang, i think <xentrac>if you want to know "what would the people who designed C do differently if they were going to do it over again?" then Golang is probably a pretty reliable answer <stikonas>oriansj: hmm, I'm getting Given symbol . to express immediate value 0 with M1 <stikonas>I think coming from DEFINE RS2_T6 .01F00000 <oriansj>stikonas: thank you for the fixes, they have been merged. <stikonas>with these fixes hex2 seems to be working so far for me... <stikonas>I've encoded maybe half of the kaem-minimal into hex2... <oriansj>i'm looking into your M1 problem now <oriansj>stikonas: well there is only one place where that could occur and I'm looking there now <stikonas>well, it's in that express_word function <stikonas>I just offered my M1 file in case I misunderstood how we should write immediates in .M1 file <stikonas>also it seems to me that U-encoding would only work with positive numbers... <stikonas>(although, I need to think more carefully about that) <oriansj>actually it was in eval_immediates that I forgot to do a basic sanity check <oriansj>I even indented it knowing to put it in but yet still missed it