IRC channel logs
2022-08-20.log
back to list of logs
<oriansj>but I can't imagine many people preferring LOAD32U R0::31:0 <- 0x100[0] over LOAD32U R0::31:0 <- [0x100] <oriansj>although there are probably good arguments for R0::31:0 <- R0::31:0 SUB32U R1::31:0 instead of SUB32U R0::31:0 <- R0::31:0 R1::31:0 <oriansj>although 4op and 5op instructions would look very ugly <oriansj>but instructions with implicit behavior would instantly be explicit; such as div ebx => R4::31:0 R0::31:0 <- R4::31:0 R0::31:0 DIVIDE R2::31:0 <oriansj>it probably is wrong or something is named wrong <stikonas>yeah, so I was working on hex2.c prototype for UEFI and it's outputing negative values there <stikonas>this is for my investigation why things are getting stuck <stikonas>and given that hex2.c seems to work, I think that the bug is in hex2 assembly version <stikonas>and some of that hex2.c work might later help M2libc port to UEFI anyway... <stikonas>argh, I think I actually have bug in both kaem-optional AND in hex2 <stikonas>so I shouldn't try to find a loop in hex2... <oriansj>well bare metal programming is always a humbling experience. <stikonas>well, at UEFI level it's not that different than POSIX programming <stikonas>in terms of services that we use, UEFI is basically a proper OS <oriansj>well a half proper OS with some perhaps badly thought out ideas <stikonas>opening files for reading and writing takes so much boilerplate code... <stikonas>and i doubt that it simplifies internal UEFI implementation <stikonas>it's getting stuck in File_Print function when subprocess_error message is passed <stikonas>but e.g. if I change it to suffix message (just newline) it works <stikonas>hmm, strage, now I can't reproduce it with .S file <stikonas>so maybe the bug is actually not in .S file but in lower levels... <stikonas>but luckily no changes in size, so no hex0 reencoding was needed <fossy>when aggi comes back, gcc is def needed for python. you can successfully create modern versions of python3 without python3 installed from tarball only (it won't be properly bootstrapped tho) - you may have to disable some thigns iirc, but <unmatched-paren>pabs3: pretty sure they're keeping the C++-based compiler though, right? <pabs3>the comments say they aren't <pabs3>I believe the goal is to replace the C++ with a C bootstrap that is initially auto generated from the zig code by zig but manually cleaned up and maintained to match" <unmatched-paren>> We still want the bootstrapping process to be simple though. So here's another proposal. We get a self-hosted compiler going right now. It's the official zig compiler. However the C++ implementation must be able to build the official zig compiler. As long as that remains true, bootstrapping is 1 step process. <pabs3>although I'm not sure that comment is correct <pabs3>I'd guess kelly's response is likely more true than the comment I mention <Andrew>I think Kelley is the maintainer of Zig <unmatched-paren>though tbh i don't see how removing stage0 temporarily will help them "iterate faster, solve bugs, finish the language, and approach 1.0" <oriansj>pabs3: well assuming someone gets the zig c++ build into guix and keeps a working bootstrap chain we should be good. I have zero faith that people are going to actually maintain human written c/c++ code for building of zig <unmatched-paren>oriansj: Well, Hare is maintaining the C harec forever, so I don't see why they can't do the same for Zig <pabs3>sounded like their plan was to auto-convert the zig code to C code and then manually maintain the C code, potentially repeating the auto-conversion every so often <unmatched-paren>> Delete the stage1 c++ code and check that generated .c code into the zig source repository to make it easy to build zig. This does not count as bootstrapping because the generated .c code is not source code. It's more like committing a multi-target binary into source control. <unmatched-paren>I still have no idea what they expect to gain from this, but oh well. <stikonas[m]>fossy: how are things on your side going. Had any luck with python? <oriansj>nothing is more Permanent than a Temporary solution <stikonas>hmm, can't see anything particularly bad in hex2.S but I've debugged and it starts failing in allocate_pool with EFI_OUT_OF_RESOURCES <stikonas>I think hex2.c prototype is way more efficient with memory <stikonas>though it's a bit strange cause I always tried to call free_pool <stikonas>reducing memory allocation from 16 MiB to 1MiB helps a bit but eventualy still starts failing <oriansj>stikonas: well hex2 only needs to store a pointer (->NEXT), the label (:label) and an address (32bits) per label. So assuming 20char names that would be 32bytes per label and assuming 1K labels, you would only end up using 32KB of RAM for hex2 <oriansj>and we are talking about a machine with 4GB RAM, How the F*&K is 16MB of allocation a problem? is UEFI so dumb we need to ensure dealloction as well prior to exit? <stikonas[m]>Though I should probably also close rootdir and protocol handles but that's unrelated <stikonas[m]>Well, in the worst case, I'll steal string_length function from M0 <stikonas[m]>oriansj: possibly I should use allocate page instead of allocate pool <oriansj>or you could just do a single malloc of 16MB and that'll work <oriansj>then even if you use 64KB per entry you'll be good for 1K entries <oriansj>"when a structure is allocated, it is useful to clear the buffer to a known state with zeros." stikonas: could be UEFI be dumb enough to use free'd memory and assume that we zero'd it first before returning it for UEFI? <oriansj>stikonas: well memory allocation is just a data structure, which if not properly zero'd could easily be interpreted as data and throw an exception which the catching function might interpret as running out of memory <stikonas>anyway, I've tried allocate_pages and it didn't help, though failure mode is a bit different: after I run hex2 multiple times, it gets stuck rather than exit with non-zero code <stikonas>still, it's probably easier to limit memory consumption with string_length than to have 2 different memory allocation functions <stikonas>that I don't understand why exactly we run out of resources <oriansj>and we are including: SystemTable->BootServices->SetWatchdogTimer(0, 0, 0, NULL); right? <stikonas>and trying to build catm.hex2 -> catm.efi <stikonas>perhaps the good data point would be to try to allocate more memory in C prototype and see if we git the same issue <oriansj>in allocate_pool you seem to do sub rsp, 24 but no matching add, so the stack would be off after <oriansj>sorry missed the add rsp, 24 (I must be blind) <stikonas>and just adding calloc(16 MiB, 1) to hex2.c (and not using) that memory and not even freeing works <stikonas>or I introduced some other bug in assembly