<oriansj>well the smaller the delta between stage0-posix and stage0-uefi cc_* the easier it would be to detect mistakes <stikonas>oriansj: delta is quite huge but mostly trivial things <stikonas>I think i had to change over a thousand lines <stikonas>mostly stuff like "mov register, label" -> lea register, [rip+label] or "mov register, [label]" -> mov register, [rip+label]. But also slightly more complicated changes in types struct <stikonas>ok, debug function crashes in the middle... <oriansj>that means the bit before it is called passed a something it didn't expect (possibly a null value or an address outside of memory it can read) <stikonas>ok, that was just another missed "mov register, label" in debug function <stikonas>so another bug that I didn't spot before because code was commented out <oriansj>I'm honestly more surprised you didn't actively use it for testing while implementing the functions <oriansj>as I have always leaned heavily on it when doing cc_* work <stikonas>and just went over it adjusting absolute addressing <stikonas>oriansj: it was probably very useful for you cause you had to write all those compilation functions, etc <oriansj>fair. the debug function was designed to be called from where ever you are and enable you to figure out what is going on if you don't have a debugger to use <oriansj>as the first cc_* written was for knight and the debug was very primitive <stikonas>well, now it might be useful for me, since I can't easily figure it out using gdb <stikonas>unless I go step by step over the whole thing <oriansj>yeah, that is an exercise in frustration <stikonas>hmm, still not sure what is broken, but it must be something where I made types structs relatively addressed ***nckx is now known as nckhexen
<stikonas>fix_types did not iterate over indirect types... <ilmu[m]><oriansj> "one: it tends to lead to non-..." <- only if you get stuck debating the premise, if you can move on from picking a coordinate frame then you get a technical discussion. <oriansj>ilmu[m]: well let us assume the premise is valid, what technical problems remain to reaching the final goal state? <ilmu[m]>if the goal state is "truth" then I want to tell you that the icelandic word for truth is "sannleikur" which is a composition of the words for "proving" and "game" so when I say "fix a premise" I am saying "pick some axioms" and then the "technical discussion" can also be called "mathematics" <ilmu[m]>final goal state would be to know everything that is true given the axioms <ilmu[m]>barring that; you'd want to know what you can know given the axioms <stikonas[m]>ilmu: Knowing everything that is true given axioms is simply not possible <stikonas[m]>It's simply a theorem that there are always statements that can be neither proved nor disproved given the axioms <ilmu[m]><stikonas[m]> "ilmu: Knowing everything that is..." <- that's literally what datalog does (given it's restricted semantics) <ilmu[m]><muurkha> "are you from Iceland?" <- yep <ilmu[m]>the theorem you mention stikonas is exactly a result of people testing the limits of what holds given the axioms ***Noisytoot_ is now known as Noisytoot
<oriansj>ilmu[m]: the idea isn't for software to replace human thinking but to amplify what can be achieved. <ilmu[m]>yeah and also to help the human prioritize how to allocate attention <oriansj>and aid in encouraging human cooperation. <ilmu[m]>the issue is that right now you don't get control over the program that "helps you prioritize" <oriansj>ilmu[m]: well people have to be able to allocate their attention and resources on the wrong things <ilmu[m]>because who knows what is the "wrong" thing <ilmu[m]>"who is fit to assess?" is the fundamental reoccuring question <ilmu[m]>we can provide tooling to assist humans in trying to answer it <oriansj>ilmu[m]: hence why "who does decides" matters. <oriansj>as long as those who are doing the work get to decide what gets done, then the tools will empower and not enslave the users. <ilmu[m]>oriansj: "coupling responsibility and authority" is how I put it somewhere, but yeah I agree. <oriansj>ilmu[m]: good. Now what are the technical problems that need solving? <oriansj>ilmu[m]: have you ever read the Cory Doctorow book Walkaway? <stikonas>ok, found another bug in my position independent cc_amd64 <stikonas>now there are no more crashes, though there is some corruption in output (but it seems to be limitted to comments) <oriansj>I believe the logic is that there are 10x more bugs for every bug we see. <stikonas>all if labels in the comments are broken <stikonas>(though this shouldn't affect the binary code) <stikonas>so that would suggest something missing in process_if: <oriansj>the pointer being passed to the string generating the labels is wrong <stikonas>so I think I now have a working position independent cc_amd64 GAS prototype (for posix) <oriansj>stikonas: we would be adding it to stage0 itself <stikonas>anyway, my next step is to replace POSIX syscalls with UEFI functions <oriansj>oh, sorry I ment your stage0-uefi work would become a submodule of stage0 when you feel it was ready <oriansj>can definitely go into stage0-posix-amd64 <stikonas>it definitely shouldn't replace existing cc_amd64.S <stikonas>because that is what corresponds to cc_amd64.M1 <stikonas>maybe I should also migrate M2libc defines to those more readable ones... <stikonas>well, I should probably finish cc_amd64.efi and then can do defines... <stikonas>there is one extra function to fixup type structures but other than that it follows existing cc_amd64 <oriansj>stikonas: interesting solution in fix_types <stikonas>and most isolated from othat parts of code <stikonas>initially I thought to do it relative to prim_types <stikonas>but it's simpler to do it relative to each individual type <oriansj>although if we moved the strings after the structs, you could simplify things as they would just be an array <stikonas>not sure if I understand your idea yet... <stikonas>is each type an element of array, or each .quad an element? <oriansj>stikonas: if you look at the bottom of every type you see something like type_function_name: .asciz "FUNCTION" <oriansj>that is the string for the type's name <oriansj>but it can be moved because it is pointed to by the .quad type_function_name - type_function <stikonas>but we still need to iterate over 4 sets of quads <stikonas>ok, but then it's easier to predict in advance <stikonas>so we don't need to bother with that INDIRECT vs NEXT? <oriansj>and if we are willing to change the order of the elements in the struct itself, then we just have 16 sets of pointer, int <oriansj>but that would take a good deal more work as it would impact all of the -> bits in the above code <stikonas>oriansj: hmm, it might be easier to iterate but it's trickier to do the last type <stikonas>well, for now I've implemented the first suggestion <stikonas>as that is a fairly cheap fix that does not affect much <stikonas>still fixup_type is already much simpler <oriansj>stikonas: fair; that is probably enough simplification anyway. <stikonas>hmm, first attempt of porting cc_amd64.S to UEFI (which took maybe 5 minutes) manages to completely crash UEFI and cause a reboot... <oriansj>UEFI seems to be less stable than DOS and I must say that is a serious achievement