<stikonas>well, my porting of cc_amd64 from posix to uefi is also over a week now and it's not even writing from scratch <stikonas>it's probably going to be around 18 KiB binary <stikonas>it's fairly straightforward transformation to convert from .S gas sytnax to M1 but you need to go over all 5500 lines... <aggi>which hardware and language did Knuth implement the compiler for? <oriansj>aggi: Burroughs 205 Datatron and Algol 58 Compiler <muurkha>stikonas: heh, that reminds me of the famous quote about measuring software project progress, but in this case it's actually a legitimate measure <stikonas>I first went over labels and data stuff and that fairly quickly got me 5 KiB <stikonas>so almost 30% of cc_* is just pure data (mostly strings) <oriansj>and 9 handwritten instances of a struct for the Datatypes supported. <oriansj>although reading knuth's interview I can't help but thinking M1 might actually be the fastest Assembler out there. (mostly because it does so little) <muurkha>seems unlikely, there's a lot of assemblers out there and a whole continuum between assemblers and linkers <muurkha>and M1 is way on the not-just-a-linker side of that continuum <oriansj>muurkha: completely fair. Hex0, Hex1 and Hex2 kind of straddles that line kind of aggressively. <stikonas[m]>Well, assembly versions of hex, M0 are slowed down by inefficient 1 byte reads <stikonas[m]>So one could write C version of M0 that might be tiny bit faster <oriansj>well the C version of hex0 is about as fast one can go; as it just does a single read and a single write and it never looks at a byte more than once <oriansj>unless one went full vectorization logic ***ChanServ sets mode: +o janneke
<stikonas>oriansj: either I have messed something up or our UEFI header does not work for cc_amd64... <stikonas>cc_amd64.efi just refuses to run (command load error) <stikonas>possibly something messed up with either VirtualSize or SizeOfRawData <stikonas>where as I can see GAS binary has them different <aggi>don't mean to interrupt, nonetheless, thinking hard <aggi>would you recommend moving to Oasis Linux? <aggi>because, it is alot of work, and will leave me with a system: vendor-locked against x86(64), either an undesireable kernel (5.16 currently) or an old kernel (2.4, rollback intended for tccboot) <aggi>and i got the gcc47/c-only toolchain profile archived here, which is stable and too is blocked indefinitely <aggi>all i could achieve with Oasis Linux is bringing the system-profile closer to compliance with minimum acceptance criteria