<stikonas>oh, I think I finally figured out how to fix cc_amd64.efi... <stikonas>after I increased it from 16 MiB to 64 MiB and allcoated 8 MiB to user stack, it seems to work well <stikonas>and I suspect I'll have to increase it for M0 too... <stikonas>oriansj: hmm, I should probably rename PE32_text PE32_end into ELF_text and ELF_end. Or alternatively we can use more general names... <stikonas>otherwise we make it complicated to use cc_amd64.efi to build M2-Planet for posix <stikonas>and also more unnecessary complications in M2-Planet <stikonas>anyway, I can now build POSIX version of M2-Planet in stage0-uefi <stikonas>zeroed out some more fields in PE header and also renamed PE32_end to ELF_end in the commented label <oriansj>muurkha: make it 18bits and it'll be in good family <muurkha>one of the nice things about Harvard architectures is that it's trivial to use a weird instruction size <oriansj>Christoph[m]: yeah hex0 was designed to be universal (for systems which used a multiple of 4bits for their instructions) and allow easy cross-platform verification of the root seeds; hex1 and M0 can be cross verified with hex2 and M1 <oriansj>aggi: pretty close to toggling individual bytes into memory and then executing it. <oriansj>stikonas: well we could change ELF_* to be something more universal; I just don't know what it would be <oriansj>muurkha: I don't think any single instruction size is a good idea; especially when multiple different sizes don't seem to cost too much complexity if done carefully. <oriansj>even RISC-V supports 16bit instructions <oriansj>(Using up an insane percentage of their opcode space doing it too) <muurkha>yeah, I think RVC may actually be the densest instruction set GCC supports <muurkha>I don't think so, but I admit I don't have a cross-SH4 GCC handy to test with <oriansj>all instructions are 16bit originally with 16 registers; so it is hard to find a non-synthetic benchmark where RISC-V is Denser <muurkha>the SH4 only has 16 registers, while RISC-V has 32, so there are a lot of routines that can run in the register set in RISC-V which have to spill to RAM on the SH4 <oriansj>muurkha: a C Compiler written in assembly didn't even spill on x86 with 8 registers; why would 16 registers be an issue <muurkha>on x86 you use memory operands all the time <muurkha>the hardware handles this efficiently by having lots more registers that aren't architecturally exposed <Guest98>hey did you see that bootstrappable.org Let's Encrypt cert didn't get updated? <Guest98>> Not After Mon, 10 Oct 2022 12:02:42 GMT <muurkha>on RISC architectures you can't do that; you have to use separate instructions to load operands into an architecturally exposed register and store results from an architecturally exposed register <Guest98>np! wanted to make sure someone could that info early on <Guest98>also, looks like a fascinating convo here, unfortunately a bit over my head! <muurkha>oh, we were just chattering about code density <muurkha>like, what kind of instruction set design allows your programs to be smaller <muurkha>from looking at simple examples I feel like stack machines generally beat traditional RISC (register-to-register) and CISC (register-to-memory or memory-to-memory) designs <muurkha>they need about twice as many instructions, but those instructions are less than half as big <muurkha>and generally two-register instructions (like amd64 or RVC) are denser than three-register instructions (like uncompressed RISC-V) <muurkha>I mean, on uncompressed RISC-V you can say add a3, a4, s2 if you want to preserve the values in a4 and s2 <muurkha>on amd64 to do that you need two instructions, like you have to say mov %rsi, %rdi; add %rcx, %rsi, because the add instruction overwrites the old value in %rsi so you have to save it first if you want to use it again <muurkha>but the advantage of the two-operand approach is that all the instructions like that are 3-6 bits shorter <muurkha>which turns out to matter more most of the time <oriansj>well 2-7 bits shorter (There are 4 register 3-op instruction sets and 128 register sets as well) <oriansj>and 90% of the time, 2OPs is what you want <muurkha>I didn't know there were 4-register 3-operand instruction sets! <muurkha>even with 2 operands, about 80% of results are only used once, which is why accumulator-only and stack instruction sets work <muurkha>but every once in a while you need an additional stack operation or two <oriansj>The NAND2TETRIS CPU technically is 3 operands as you can do *A = D + A (but having only 2 actual registers so not exactly ideal) <muurkha>by "3 operands" I mean where the instruction contains three operand fields <muurkha>normally source 1, source 2, and destination <oriansj>indeed and hence why I don't really count architectures with less than 4 registers ***robin_ is now known as robin
<stikonas[m]>So I think bootstrappable.org was not setup with autorenewal <civodul>stikonas[m]: there is auto-renewable, but "certbot renew" is choking for reasons i don't understand <ilmu[m]><muurkha> "above all we should thank Guest9..." <- all hail Guest98 <stikonas[m]>civodul: good to know. Feel free to share error messages in case somebody here might be able to help