<stikonas[m]>well, risc-v manual is maybe 130 pages long but you mostly need a couple of pages <bauen1>stikonas[m]: for doing a (probably correct) implementation of rv32i you only need <35 pages, probably less than <30 <bauen1>stikonas[m]: you probably need that much to even have a list of all opcodes for i386 and all the possible encodings used ... <stikonas>bauen1: well, I mostly used table of opcodes <stikonas>but yes, x86 has significantly more opcodes <oriansj>bauen1: well we only use 84 x86 encodings (not counting immediates) for M2-Planet, M2libc, mescc-tools, mescc-tools-extra and Mes.c <oriansj>so even though x86 migh have considerably more opcodes than RISC-V; I highly doubt one needs most of them to actually bootstrap everything. <oriansj>plasma41: I greatly look forward to seeing your results. <plasma41>oriansj: What is the oldest x86 family processor that the hex0_monitor is supposed to support? <oriansj>plasma41: ideally? or what would be good enough? <stikonas>LOAD_EFFECTIVE_ADDRESS_rdi looks like amd64 <oriansj>so the question becomes how did it get there <stikonas>./M2libc/riscv32/libc-full.M1 and defs file seem clean <stikonas>oriansj: it's including M2libc/amd64/linux/unistd.c <plasma41>oriansj: As in what is the oldest processor that has supports all the machine opcodes we want to limit ourselves to? Currently there are a few opcodes in the commented hex that weren't introduced until the 80186. I've modified the assembly in a few places so that the generated machine code will be limited to what is available on the 8086. <stikonas>plasma41: I think it's mostly because more opcodes aren't really necessary for bootstrap <stikonas>even in riscv ISA I have not used all opcodes <oriansj>plasma41: well EAX and that group only were added with i386 but the hex0_monitor should be able to run on an 8088 <stikonas>oriansj: strange in -E mode I don't see any amd64 stuff <plasma41>oriansj: Basically was it a design goal for the hex0_monitor that it be able to run on an 8086? If so, a few 80186 opcodes snuck in. <stikonas>oriansj: and in fact manual invocation of M2-Mesoplanet builds it successfully <oriansj>plasma41: actually the original design goal for the hex0_monitor was just: could I do something that could self-host in 510bytes and run on operating systems and bare metal. So one could say my goals have grown more ambitious with our collectiv sucess. <stikonas>oh, actually my chmod error on riscv32 happens later than in orisnsj's paste <stikonas>M1 runs fine for me, it's hex2 that crashes <stikonas>yet running "../riscv32/bin/hex2 --file ../M2libc/riscv32/ELF-riscv32-debug.hex2 --file /tmp/M1-macro-000019 --output ../riscv32/bin/chmod --architecture riscv32 --base-address 0x600000 --little-endian" works just fine <oriansj>stikonas: can you share the /tmp/M1-macro-000019 please <oriansj>and tonight I'm gonna fuzz hex2 with --architecture riscv32 to see if I can find anything else that might cause a segfault <stikonas>I've just checked, the file in riscv32/bin/chmod seems functional <oriansj>(all other architectures have either wait or wait4) <stikonas>ok, something to look at tomorrow... Unless you find the bug while I sleep <oriansj>stikonas: well I found a bug in the behavior of --architecture, so I'll be fixing that tonight <stikonas>well, it's nicer to have --architecture in M2-Planet rather than env variable <oriansj>and I'll be fuzzing hex2 just in case <stikonas>I can't reproduce it in any of the manual runs <stikonas>actually, I can try to run just 1 command in kaem and see <stikonas>and also running M2-Planet in kaem worked... <oriansj>now the order of --architecture --debug-mode --max-string and -I no longer matter; they will be processed first before the setup of environments and thus will always be respected <plasma41>EBFE, the shortest self-hosting x86 machine code program! :-P <oriansj>plasma41: well that isn't self-hosting, so much as self-calling. as one needs to read input and write output to be considered a hosting language. and self-hosting just simply requires just enough functionality to enable it to make the act of a human developer using that language to be able to implement the functionality of that language in terms of that language. <oriansj>hence why support for comments of some kind (be it line and/or block) seem to be some sort of universal requirement for actual self-hosting languages. <ekaitz>janneke: gcc-4.6.4 is kicking my ass at the moment, do you have any recipe for old versions of GCC that I can use as a reference? Looks like the one that comes with guix (4.7) uses newer environment variables that were not available in 4.6. <stikonas>ekaitz: are you having trouble building it? <ekaitz>that explains part of the problem <ekaitz>most of the thing is related with search paths <ekaitz>I had to patch a couple of configuration files but this is supposed to just compile by its own <stikonas>hmm, I haven't tried 4.6 but both 4.0.4 and 4.7.4 were at least not sensitive to installation prefix <ekaitz>now the problem I have is it doesn't find /lib/cpp <ekaitz>what I don't understand is why is it searching for it there <ekaitz>this step was supposed to be the easy one... lol <stikonas>well, it tooks me some time to build it in live-bootstrap too <ekaitz>is there any script for building 4.0.4? <ekaitz>it's not very different to what I'm doing <stikonas>just need to point build to those new dependencies (gmp, mpc, etc...) <ekaitz>but you are compiling folder by folder <ekaitz>I tried to compile the whole thing <stikonas>we were forced into compiling folder by folder by pre-generated files <stikonas>there is no way to build top-level Makefile.am <stikonas>it's machine generated, it's not a source file <ekaitz>yeah that's what I'm having issues with <ekaitz>it has some hardcoded paths that are kicking my ass <stikonas>everybody who had a look at it quickly gave up <ekaitz>I'll try your way then, I was more stubborn and tried to patch it a little :D <stikonas>that top-level thing is kind of optional... <stikonas>subdir configure files seem to work well enough <ekaitz>i tried to execute it but it was complaining about some things... i'll give it another try <stikonas>you could always build live-bootstrap chroot :D for compiling gcc <stikonas>although, that wouldn't help you once you build natively on risc-v <ekaitz>i just need this building normally to be able to backport it <ekaitz>but even compiling it is shooting myself in the foot <ekaitz>i'll try your method later but it looks reasonable... will see... <janneke>ekaitz: aren't you building gcc-4.6 using guix? <ekaitz>janneke: yes but i'm having problems with it <ekaitz>janneke: do you build 4.0 with guix too? do you have any guix package definition for it? <janneke>this is an old branch, very much wip <janneke>maybe you can use some trick from the package description ***ChanServ sets mode: -o janneke
<plasma41>oriansj: Yes, I did use the wrong term; you are right. I was just being silly. Though it is rather amusing that all it takes to write a program that creates an infinite loop and eats up all your CPU cycles is just sixteen bits. <oriansj>plasma41: if you are referring to :(){ :|:& };: setting /etc/security/limits.conf to have soft nproc 100 and hard nproc 300 and fork bombs don't work anymore <oriansj>but if you mean rm -rf / well fortunately that is fixed and you need --no-preserve-root these days <oriansj>but dd if=/dev/zero of=/dev/sda will continue to work <plasma41>oriansj: Yes, "rm -rf /" plus the final carriage return. While requiring '--no-preserve-root' is better than not doing so, I think the way the Solaris folks solved the problem is more elegant. <stikonas>plasma41: why is it surprising to have infinite loop in so few bits? <stikonas>isn't it just putting jump instruction to current address <oriansj>you can have a segfault in just 24bits <Hagfish>that makes me think of a question like "what is the smallest dangerous number?" (obviously open for debate) <Hagfish>i guess arguably zero is dangerous as a divisor <oriansj>Hagfish: 0xFE shutdowns the entire computer <oriansj>or 0x9D and 0xDD on the Motorola 6800; which causes the system to halt and catch fire <plasma41>oriansj: I rewatched the original sandsifter conference talk just this week actually. It's a classic. <oriansj>plasma41: well it certainly proves the point from NASA that no IC with more than 16 pins ever actually matches the spec exactly. <plasma41>oriansj: I hadn't heard that quote, but I like it!