***examors_ is now known as examors
<rickmasters>Hello, I'm back with another update on boot2now and the builder-hex0 bootstrap kernel work. <rickmasters>As a reminder, I reported on August 9th that I has was stuck for weeks building mes-tcc <rickmasters>but I had finally found a clue as to what was wrong. <rickmasters>Well, I fixed the issue and managed to build mes-tcc a few days ago. <rickmasters>I am debugging "mes-tcc -ar cr /usr/lib/mes/libc.a unified-libc.o" <rickmasters>which is currently failing with an "Unsupported Elf Class" error. <rickmasters>To elaborate, mes-tcc is in the tcc-0.9.26 package and is an early form of tcc built using mes. <rickmasters>This tcc-0.9.26 package also uses the libc sources from mes. <rickmasters>mes-tcc is the first compiler which progressively, over five passes, builds itself up to the final tcc-0.9.26 binary. <rickmasters>If I can get mes-tcc to work well, or perhaps get to the final tcc-0.9.26 binary, then that is <rickmasters>probably a good place to pause and explore building a kernel written in C and assembly. <rickmasters>The reason to pause is that I don't see an advantage of working towards later bootstrap <rickmasters>tools such as tcc-0.9.27, or tcc-0.9.27 with musl, for building the next kernel. <rickmasters>I also have a lot of technical debt built up that I need to work through. <rickmasters>I'll report any significant progress but I may be gone for a while again. <stikonas>rickmasters: but maybe it makes sense to use higher level language? <stikonas>even if it's something similar to builder-hex0, but if you write it in M1 or C it might be easier for you <rickmasters>stikonas: well that's what I have been working towards but it was not clear whether to use M1, M2, mescc, or tcc <rickmasters>stikonas: looking back, the kernel programming wasn't the problem - it was debugging very difficult bugs with little information and very long run times <stikonas>yeah, long run times make it hard to debug <rickmasters>for example, mes corrupted memory when it got a file handle number that was too high <stikonas>for stage0-uefi I have some bugs with little information but at least short run times <rickmasters>and i'm running on qemu without kvm, so mes would take over 24 hours to run, so debugging memory corruption in a slow interpreted program was just hard <rickmasters>I should spend time moving to bare metal, but i was willing to wait because I've got other things to do and I'm lazy <rickmasters>BTW, regarding M1, I have to admit, I was turned off by the primitive mnemonics and lack of documentation. <rickmasters>With tcc you get what looks like a standard-ish decent assembler <rickmasters>.... or maybe I'm looking at the mes assembly - the tcc.s file uses assembly syntax I am familiar with <stikonas>rickmasters: the difference is just what defines you are using... <stikonas>I think mes just has defines called like mov____eax,ebx rather than COPY_EBX_to_EAX <rickmasters>Yeah, I've looked at the defines and see something like DEFINE LOAD_INTEGER 8B00 but I have no idea what that actually does <stikonas>I think I found M0 mnemonics alright but I didn't do much assembly before <stikonas>so perhaps it's a case of being used to it <rickmasters>but without docs "LOAD_INTEGER" doesn't have enough information, as opposed to mov eax, [eax] <stikonas>yes, perhaps we need better comments there <stikonas>rickmasters: it's somewhat different for M0 on risc-v <stikonas>it's slightly closer to normal syntax, yet still a bit different <stikonas>e.g. "addi a7, 217" becomes "RD_A7 !214 ADDI" <stikonas>(typo in the number, should be the same) <stikonas>but risc-v style fixed word syntax needs much bigger hex2 <rickmasters>I guess its not that hard to plug 8B00 into some disassembly tool and backfill the documentation but I decided to just avoid further investment in M1 if possible <rickmasters>my suspicion is that there was a goal to somewhat unify the assembly syntax across architectures by using an abstraction like LOAD_INTEGER <rickmasters>but that probably fell apart quickly because the register set can't really be abstracted away <rickmasters>anyway, I have to step away but I'm sure oriansj will chime in on these topics soon enough <Hagfish>what a legend, i'm glad he's still making progress, and it sounds like some more exciting milestones aren't too far away <Hagfish>i'm glad you were able to compare notes with him, stikonas, and your work sounds equally important and impressive <oriansj>well most of the M1 DEFINEs are a direct product of M2-Planet's needs and were named related to what the Instruction was doing in the generated M1 output. Hence why the DEFINEs in cc_x86.s are quite different from those in M2libc. <oriansj>The idea was anyone could create any DEFINEs to suit their needs rather than requiring anyone to use a standard set of DEFINEs that are hardcoded. <stikonas>oriansj: that's true, but I guess rickmasters is saying, we could have used names that are closer to e.g. nasm syntax