IRC channel logs
2021-07-31.log
back to list of logs
<oriansj>if you have a clean way to support a little endian ASCII char stream in hex2, let me know and then the hex input might match the RISC-V docs (ARMv7l would probably benefit from that as well) <xentrac>yeah, I'm not doing very well at... doing things lately <oriansj>xentrac: I get it. everyone here has only a limited amount of effort they can invest in the work. some only discussion and others running code. <oriansj>hopefully you are making progress recovering from burnout xentrac (I know I'm at stage 3 of the 13 stages of burnout but working on it) <oriansj>although I find it odd that big word endian, little byte endian and big bit endian was the combo that seems to have won the architecture war. <xentrac>you keep saying that about bit endianness, and I keep explaining to you that you're wrong ;) <xentrac>not sure what you mean about big word endianness <oriansj>word endianess the first instructions start at low addresses and increment up vs first instructions start at high addresses and decrement down. <xentrac>are the first instructions supposed to be analogous to more significant words or to less significant words, and in either case, why? <stikonas>well, half of the work is writing low level prototypes... <oriansj>xentrac: remember the table of hex nybbles to byte endianess I did a while back? <stikonas>so even if hex0 encoding was trivial, it would only speed up .hex0 writing by a bit <stikonas>although, that makes writing hex1.hex0 harder... <oriansj>the first instruction are analogous to more significant words because they determine instruction flow more than later instructions. <xentrac>interesting. but you know when you actually do multi-precision arithmetic, the first instructions in your multi-precision arithmetic code have to handle the least-significant limbs of the multi-precision number, right? <xentrac>so bit-serial processors (which really do have a bit endianness) were invariably designed to process the LSB first. which is probably why the Datapoint 2200 and its successor amd64 are little-endian too <stikonas>oriansj: do you remember the reason for envp in kaem-optional-seed? <stikonas>I guess that allows to propagate things like PATH but I wonder if we really want that... <stikonas>hmm, live-bootstrap actually uses "sudo env -i PATH=/bin chroot ...", so maybe it is needed <oriansj>stikonas: mes.c can't survive a NULL envp <oriansj>everything prior to that behaves nicely with a null envp but mes.c explodes <stikonas>hmm, doesn't full kaem.c set various env variables... <stikonas>although, the fact that we had PATH=/bin in live-bootstrap means something consumed it <oriansj>in theory we could add one at the kaem.c stage but right now it supports setting up an envp <stikonas>well, I was thinking if I write something like kaem-micro that hardcodes some of the early commands, do I need envp there <oriansj>stikonas: well if we have kaem.c set up one before we run mes.c then it wouldn't be needed. <stikonas>well, I can try to keep it out of riscv's kaem and we'll see <stikonas>so that might be enough to get going until kaem.c <oriansj>worst case we learn something useful. <fossy>stikonas[m] oriansj: i pushed a bugfix a few weeks ago surrounding environment variables <fossy>stikonas[m]: it is very acceptable to ignore envp for mini kaem <fossy>i think that would actually be even preferred as it would reduce the hex0 <fossy>nice looks like this kernel will compile properly now, got over all the asm problems <stikonas>oriansj: just to make sure I'm not mistaken, I need to do little endian conversion when doing M1 DEFINES, don't I? <stikonas>i.e. DEFINE RD_A1 80050000 (A1 is 11th register, 0XB << 7 = 0x580) where RD is destination register <stikonas>if we do it this way, at least hex2 won't need to do endianness conversion <oriansj>stikonas: if you do . hex it will push the hex on left to right and pop off the values right to left <oriansj>so the order needs to be .12 34 56 78 if you want the output to be 78 56 34 12 when it is combined with 00 00 00 00 <stikonas>so I don't need to swap it in defines... <oriansj>well the output order is defined by the byte write order (little-endian in the RISC-V case) <stikonas>well, that's fine, I just need to make sure I use correct order in M1 defines <oriansj>stikonas: very easy to sanity check with hex2 as it supports .hex <stikonas>well, . will work, but I guess M1 does not yet support . (I can create .hex2 file manually though) <stikonas>at the moment I was only creating defines at the beginning of the file... <stikonas>but I think it will be much easier to encode into hex this way rather than directly <stikonas>once I have .M1, it's mostly just manually adding . hexes and reversing order <oriansj>well right now M1 will do the correct thing for DEFINEs <oriansj>what needs to be done is word support for immediates like @-3 <oriansj>so DEFINE foo .0011223344 will produce the exactly desired result <stikonas>anyway, before that I need to create DEFINE table... <stikonas>which will be useful both for encoding manually and later for M0 <stikonas>hmm, there is also a bit of a mess with shift amounts, they are in place of second source register... <stikonas>we might need to add more later... These are just RV32I (minus FENCE) and RV64I <stikonas>I guess at some point we'll want multiplication too