IRC channel logs

<stikonas>oriansj: so riscv32 is still broken...

<stikonas>I'll have to look a bit more at it

<stikonas>but it's probably exit status detection that goes badly

<oriansj>stikonas: I don't think WORDSIZE = 64 is correct for riscv32

<oriansj>and I added more debug state to cc_spawn.c

<oriansj>it'll definitely screw up the blood-elf output

<stikonas[m]>Oh good spot. It's copy paste error but it confused me and I was looking at bugs elsewhere

<stikonas>oriansj: right I think the remaining problems that I have on riscv32 and aarch64 are that qemu issue where we use too much heap memory

<stikonas>when I ran it natively on aarch64 it worked

<stikonas>still, not working on qemu is kind of a blocker

<stikonas>because we need to be able to test it on multiple platforms

<oriansj>good point. I'll try to start trimming down memory usage

<oriansj>starting with envp (which is super wasteful)

<stikonas>well, right now I can't even push because I don't have riscv32 checksums...

<stikonas>and I don't think we have anybody with riscv32 hardware

<oriansj>right now envp is allocating 128KB per environment variable

<oriansj>so this will really cut the memory size

<oriansj>anyone remember what the max envp line size is?

<stikonas>do we have to know it in advance? I.e. something like scratch is not possible?

<stikonas>oriansj: I think limit is here https://man7.org/linux/man-pages/man2/execve.2.html

<stikonas>so 128 KiB

<stikonas>but that's total size of argv and envp

<stikonas>not per environmental variable

<stikonas>still, we don't have to support such large limit

<oriansj>say limit ourselves to 4KB envp lines

<oriansj>well that certainly speeds things up

<oriansj>stikonas: checkout the latest, it is much speedier

<oriansj>and much smaller of a memory footprint

<oriansj>stikonas: and if that isn't enough memory saved, let me know and I'll start hunting for more places to save RAM

<plasma41>oriansj: Hi, I just wanted to let you know that I'm working on hand-assembling the x86 assembly version of the stage0_monitor in order to verify the commented hex. It's very tedious work as you well know, but I've been enjoying it in spite of frequent head-scratching and manual-consulting.

<plasma41>I've hand-assembled about a third of it so far. Calculating offsets for call and jmp instructions is a pain. :-P

<oriansj>plasma41: one thing that might make the lookup easier is Oscar Toledo G's books include a section listing all of the opcodes in hex for quick reference.

<oriansj>and a stupid trick for making the call and jmp instructions easier is everywhere you would put a :label do a #:label (address) comment

<stikonas>plasma41: and another useful trick is to go via M1->hex2->hex0 steps rather than directly encoding into hex0

<oriansj>and I suggest doing the first version in C or plain assembly to work out logic issues first

<stikonas>oriansj: indeed, new M2-Mesoplanet is so much faster now.

<stikonas>although, I still need to fix some riscv32 issue (aarch64 now works correctly)

<stikonas>but I still see some crash with riscv32, but only when building the very last executable (chmod)

<Hagfish>huh, weird that it should get that far, and fail on something so seemingly simple. it's really encouraging that aarch64 works, though, so maybe this is an example of ports being useful for uncovering subtle bugs

<Hagfish>anyway, great work!

<plasma41>oriansj: I've printed out both the assembly language prototype and the commented machine code of the stage0_monitor. I also printed out the relevant pages from a PDF of the 1979 Intel 8086 User's Manual I found online. With the manual and the assembly language printouts and a pen, I've been hand assembling the code and then comparing my work to the commented machine code.

<bauen1>plasma41: that's dedication

<plasma41>I've made a few minor changes along the way and so must account for changed byte counts in some of the call and jump intructions. I'll submit my changes once I've finished the hand-assembling. It shouldn't take me more than about a day or two at this point.

<plasma41>Honestly the hardest part was learning what was meant by "MOD reg R/M" in the documentation. So few "learn assembly language" books ever even touch on how assembly language mnemonics get translated into machine language. Most of them assume that no one would be crazy enough to actually _want_ to do that by hand. Which, to be fair, is true of most people. :-P

<bauen1>plasma41: yes, hand assembling x86 is interesting ... i had to help / teach students with that as part of my job, it's incredibly confusing, learning vhdl is a piece of cake by comparison ...

<Hagfish>it sounds like there needs to be a user's manual for the user's manual :)

<plasma41>Hagfish: The hard part is discovering which 62 pages out of the 760 page manual are the relevant ones. (It's pages 2-30 to 2-72 and 4-18 to 4-36 btw)

<plasma41>Pages B-191 and B192 also provide a nice quick reference card printable on a single sheet of paper that offers a nice at-a-glance summary of the instruction encodings from chapter 4.

<Hagfish>nice. maybe those little insights can be placed in a README, if your work has one

<plasma41>Hagfish: I'll be sure to suggest it when I submit my proposed modifications.

IRC channel logs

2022-01-25.log