<stikonas>ok, I think it just happened to work because kernel zeros r10 on start and it was never used... <oriansj>sure, we could use the migration to the relocatable version of cc_amd64.M1 as a way of updating M2libc's DEFINEs <oriansj>it is a breaking change for M2-Planet but it'll probably be worth it long term. <oriansj>unfortunately Mes.c would have to be upgraded too <oriansj>assuming janneke is onboard iwth the change <oriansj>muurkha: playing with doing assembly for the NAND2TETRIS CPU, having 4 registers would have saved so much bit juggling <stikonas[m]>Anyway, I'll start with m2libc, the m2-planet and we can do mes after that <stikonas[m]>oriansj, so mes will be unaffected but that's because we don't have any glue for amd64, it's x86 only <stikonas>I'm now adjusting M2-Planet. Main binary itself is done but going over the tests (whose build scripts got broken due to earlier M2libc changes) <stikonas>oriansj: I have some trouble with knight tests\ <stikonas>M2libc/fcntl.c I get M2libc/fcntl.c:35: error: #error arch not supported <stikonas>otherwise it's M2libc/stdlib.c:128:open is not a defined symbol <stikonas>well, maybe I'll do it since I'm testing it already <oriansj>stikonas: I guess the lack of AMD64 support in mescc saves us that sync problem. <stikonas>I wonder if knight-native will also need similar adjustment <oriansj>well M2-Mesoplanet can't run natively <fossy>stikonas: oh, i figured out the issue.. i forgot to say linux-headers should only extract certain folders from the tarball. i'll push a fix tomorrow, i just need to confirm it works <stikonas>anyway, all amd64 M2-Planet tests pass... <stikonas>oriansj: and amd64 binaries built by M2-Planet are now position independent <stikonas>ok, knight-native also needs similar fix... <stikonas>oriansj: what should I do with knight-native? <stikonas>the problems is that my fix needs init_macro_env ... <stikonas>hmm, at least if I add those lines, test seems to build/pass on amd64 (actual running is skipped) <stikonas>it probably wouldn't make a difference on knight (I guess it's dummy) <stikonas>but at least it will superficially allow tests to pass <oriansj>well env doesn't exist on bare metal; so a dummy function that perhaps set up a dummy environment is an option if we need to ensure an env exists. <stikonas>well, we'll come back to knight-native if/when we need it <stikonas>for now I'm just updating M2-Planet to work with your M2libc changes... <stikonas>hmm, now checksums at the end don't match... <stikonas>though that is probably due to m2libc changes <stikonas>I guess I'll just run Generate-test-answers <stikonas>I still need to adapt cc_amd64.M1 to output new defines, but I can push there myself ***ay is now known as Andrew
<stikonas>oriansj: I've now pushed stage0-posix-amd64 changes <stikonas>so once M2-Planet PR is merged, I can update stage0-posix and we will be done with new defines <stikonas>(at least at higher levels, one can still replace them in the comments and prototypes of hex0,..., M0) <stikonas>hmm, looks like UEFI command lines might be limitted to 128 chars... <stikonas>or maybe more likely some bug in kaem-minimal causing that <stikonas>kaem-optional.c prototype works fine too, so looks like bug in assembly <oriansj>stikonas: M2-Planet reviewed and Merged <stikonas>thanks. I'll pull in new submodules in stage0-posix then <stikonas>oriansj: any idea what might be causing kaem bug in stage0-uefi... <stikonas>I've been staring at kaem-optional.S but can't see anything so far <stikonas>though if I can't quickly spot it, we can just limit ourselves to short command lines <stikonas>it's not that far till C version of kaem... <oriansj>well let me think about it for a minute <stikonas>hmm, some limitted debugging that I can do in UEFI shows that rsi register that holds the length of the string has correct value <stikonas>yet even File_Print stuff that prints command is already truncated to 127 bytes... <stikonas>oh, rax is actually 0x20a when we reach read_command_done <stikonas>so of course it triggered cmp al, 0xa check <stikonas>this is quite strange, somehow we end up with multi-byte value after read_byte <stikonas>oh it might be that address where character is stored was not empty <stikonas>(which I actually do in all other programs) <stikonas>hmm, but it changes file size, so I would have to reencode everything <stikonas>let me see if I can push any other register <Christoph[m]><stikonas> "hmm, but it changes file size..." <- May I ask, why? I have no clue about assembler, and I don't know what 'reencode' means here or why it is necessary. But it seems extra strange to me that one needs to know the file size in advance. Or ... do you use something like GOTO <relative jump size>? <stikonas>Christoph[m]: cause push rsi is 1 byte of machine code <stikonas>but "push 0" is two bytes 6A is push and 00 <stikonas>and assembler basically jumps to relative locations from the current plcae <stikonas>Christoph[m]: so e.g. if you want to jump to some label b, you need to tell, jump 25 bytes forward <stikonas>Christoph[m]: I'll soon have a diff up, so you could see <Christoph[m]>And there are no labels to jump to? Or editor support for that? <stikonas>so somewhat limitted amount of labels you can have <stikonas>but good enough to build hex2 which supports arbitrary length labels (and a bit more stuff too) <stikonas>Christoph[m]: though you also need to know file size too <stikonas>(though I've also sneaked in another change here <stikonas>apparently we don't need to explicitely have zeroes (for variables) at the end of program <stikonas>and we can just tweak a couple of parameters in the header <stikonas>Christoph[m]: so speaking of those bootstrap programs, hex2 support the labels. Then we have M0 which allows using DEFINES, e.g. "DEFINE push 6A" and also knows how to encode numbers, e.g on x86 %123 -> 23010000. So basically let's you program in primitive assembly. <stikonas>and after that we have cc_* compilers which supports a subset of C <stikonas>hmm, there might be another bug in kaem-optional... though I'm now super sure yet <stikonas>amd64\artifact\cc_amd64.efi amd64\artifact\M2-0.c amd64\artifact\M2-0.M1 fails when when kaem was launched by UEFI directly but succeeds when I run BOOTX64 in UEFI shell (BOOTX64.efi is kaem-optional.efi) <stikonas>hmm, that is more likely to be cc_amd64.efi bug rather than kaem bug...