IRC channel logs
2021-07-23.log
back to list of logs
<oriansj>stikonas: thank you for the fixes. Merged <oriansj>but yes hex0, hex1, hex2 and M0 are the 3 most tedious programs in the entire bootstrap. but yeah hex1 is the most annoying because of all the relative offsets and jumps. <xentrac>stikonas: what do you think of risc-v? <oriansj>well yeah 737 (of which 70bytes are just strings) vs 689bytes (just 8bytes of nulls at the end). So I guess hex1 just slightly is harder than kaem-minimal <stikonas>xentrac: so after looking a bit more at risc-v it seems that I'll have to do quite a bit more work... Some opcodes (jumps in particular) have a fairly complicated encodings (possibly to make hardware implementations simpler) <stikonas>so what I have now would work on *.hex1 code written for e.g. x86 or x86_64 but risc-v .hex1 would need some extentions to deal with it (and hence need to write some more "functions") <stikonas>e.g. jumps encode addess into bit 20, bits 10 to 1, bit 11, bits 19 to 12 <stikonas>and there are a couple of other different schemes for some other opcodes (e.g. branching ones) <Hagfish>that seems like pretty solid research <stikonas>Hagfish: that's just reading risc-v specs... <stikonas>you can't write *.hex0 code without that (or even later ones e.g. .hex2) <ekaitz>stikonas: Yeah the encoding is wild sometimes <ekaitz>are you going to make the hex1 step? <ekaitz>i have some experience on risc-v (i made the hex0) so I can help <stikonas>ekaitz: I'm almost there with hex1-x86.hex0 for risc-v <stikonas>ekaitz: if you want, you can review my low-level prototype <stikonas>it does not yet handle risc-v encoding but deals just fine with x86.hex1 files <stikonas>it will be easier to push it somewhere than just pastebin <ekaitz>is x86 encoding simpler than risc-v or are we using a subset of x86 there? <ekaitz>afaik x86 can get complicated too <stikonas>well, I mean immediates are in one location <ekaitz>thanks! I'll take a look to it right now <ekaitz>lol you added me in the license header :D <stikonas>actually I started from hex0 code and modified it <stikonas>ekaitz: would be worth looking at that .table stuff (at the very end), I was not completely sure what to do there <ekaitz>ok i'll take a look right now, but I'll take a deeper look tomorrow <ekaitz>did you decide how to assemble this? <stikonas>first pass is almost done (non branching/jumping) instructoins <stikonas>I printed out opcode table from risc-v manual... <ekaitz>let me give you a small extra file <ekaitz>with that you can assemble things better <stikonas>I mean I can obtain the same things from gnu as... <ekaitz>alright I pushed the baseassembler file <ekaitz>the pyscv/baseassembler.py file is able to assemble instructions and give you the hex0 value <ekaitz>something like that more or less <ekaitz>that's going to save you a lot of time <ekaitz>it's nothing you can't do by hand, but it's easier <stikonas>and I could do quite a bit of copy-paste <stikonas>since there are a lot of identical instructions... <ekaitz>when you assemble branches it gets messy <ekaitz>because you have to split bit values and convert and all that <stikonas>well, that's what I still have to teach to hex1 <ekaitz>that code is an unfinished assembler I'm writting and I decided to reuse part of it for this :) <ekaitz>and saved me from chances of making it wrong... <stikonas>at least when writing hex2, this won't be a problem, hex1 will already know how to do these calculations <ekaitz>hex1 is going to be critical here <ekaitz>i'm not very focused today but feel free to ping me with this, because I want to get a little bit more involved on the process <stikonas>yeah, I'll think over the weekend how to handle immediates <stikonas>ekaitz: by the way, do we need that stdout stuff in hex0? <stikonas>getting rid of it would reduce bootstrap binary a bit <stikonas>I don't mind in in later hex1 and hex2 though <xentrac>stikonas: yeah, the RISC-V encodings are definitely a PITA. x86 encoding is a lot simpler for software <xentrac>there's only like 6 instruction formats in RISC-V (without the C extension) though <ekaitz>stikonas: I just copied what it was done in others i think, feel free to remove what is not needed <xentrac>in hardware switching around the order of bits is easy (it's just routing wires) while having the bit field locations be conditional is hard (you have to add more layers of muxes, which slows down the whole computer) <xentrac>in software it's exactly the opposite <stikonas>well, hardware is harder in general than software <stikonas>so there is some sense in making hardware implementation easier <ekaitz>routing is not for free, changing the order of some cables has HUGE impact in the silicon layout <xentrac>but when you're talking about moving work between the compiler and the hardware, you'll tend to get better performance if the compiler does it <xentrac>ekaitz: yeah, but not so much on the propagation delay <xentrac>that is, if you can choose between doing something like moving the sign bit to a weird location at the time you compile an instruction, or at the time you execute it, you should probably do it when you compile it <xentrac>because typically you run instructions more than once after you compile them, often trillions of times <xentrac>that rule can mislead you (Itanic sank, in part, because of hoping that compilers would be better at instruction scheduling than OoO hardware, which turned out to be wrong) but it's pretty often valid