***Noisytoot_ is now known as Noisytoot
<fossy>configure: error: libgmp not found or uses a different ABI (including static vs shared). <oriansj>fossy: as they say: bootstrapping is the discovery of all programming sins. Including unreliable kludges <oriansj>pabs3: 1200 transistors!!! that is enough for a 12bit CPU (the PDP-8s only needed 519 gates total) <oriansj>once it gets to the 16bit level, we will be able to leverage it to bootstrap all the way to up cc_* (32bit is needed for M2-Planet and above) <oriansj>stikonas: no tools require 16bit. just only some tools fit within 64KB of RAM for both program and all working data <stikonas>catm actually reserved 1MiB but that can be reduced... <oriansj>absolutely (it can be reduced down to 1byte and still work; if only much slower) <stikonas>and it's only on POSIX that it needs that... <stikonas>on paper tape catm is almost optional... <oriansj>stikonas: actually catm on bare metal would be needed on media forms that can not be manually combined. with a hit enter after inserting next media sort of thing <stikonas>oh yes, if you use something like floppies <oriansj>or magnetic tape or USBs or MicroSD cards, etc <stikonas>btw, I spotted that bootstrap-seeds has an outdated amd64 hex0-seed... <stikonas>and later (hopefully today) I should also have hex1 for risc-v <stikonas>only need to encode branching jumps now (other ones are now done) <oriansj>stikonas: well we knew that was likely because of the encoding complexity of RISC-V but it is nice to see that you managed to find a small subset for RISC-V to make the step a bit more auditable. <stikonas>at least no more of this complicated label encoding <stikonas>well, we'll still need to do other things (including encoding actual immediates) until we reach M1... <oriansj>stikonas: atleast encoding immediates by hand is much less difficult. <oriansj>Also the platform specific version of M1 is M0 which will support immediate encoding <oriansj>hopefully this work has helped clear out any encoding bugs in hex2 that might cause us issues for RISC-V <stikonas>and yes, I think encoding bugs should be cleared now <stikonas>but in any case if there is anything left, should be a minor bug <stikonas>but I did build those development files with C versions of hex2 and M1 <oriansj>stikonas: good. hopefully after you finish M0, we will have found and cleared out all M1 RISC-V bugs as well. <stikonas>that will take some time... I'll be less available for half a month <oriansj>understandably. a half-month delay is no problem. Take care of your personal life first, the bootstrapping work can always wait. (If anyone has a problem with that, they are free to do all the work required themselves.) <oriansj>stikonas: well in terms of manual offset calculations absolutely. In terms of effort: nope <oriansj>everytime we make something easier, we use that additional power to build yet a bigger effort saver. <oriansj>but also more difficult because it becomes large enough to lose track of all the pieces. <oriansj>I like to think of it as a gently escalating slope. Requiring greater and greater skill in assembly programming. <oriansj>hex0 one can do without any experience in assembly programming but by M0 you absolutely have to have the basics down solid. <oriansj>cc_* requires the skills associated with large assembly program development and after which point you can consider yourself a skilled assembly programmer. <stikonas>hmm, I guess so. Although things are made easier but lots of existing examples. It's quite a bit easier to retrace the steps once somebody did it for the first time <stikonas>well, the simplest program is probably kaem-micro now :D <stikonas>speaking of which, I should do catm for riscv64. Should be fairly quick <oriansj>(you can literally just copy any of the hex2 and/or M1 programs already written and plug them in as a valid test) <stikonas>yeah, I was thinking about them too. In any case it's simple <stikonas>just need to replace a couple of hardcoded constants with labels <oriansj>I believe so. give me a minute to check my notes to see who <stikonas>ok, I found a commit from May by janneke <stikonas>anyway, elf headers would be required for M1 in any case <oriansj>it does match the info I have saying a laanwj is doing RISC-V work for MES <oriansj>actually elf headers are written in hex2 not M1 and are needed for M0 <oriansj>that is why the %label1>label2 support is needed in hex2 <stikonas>it's probably a good idea to use headers by then, but I guess that's not stricly a requirement. <stikonas>M0 is written in hex2, so can still prepend it <oriansj>it is required for: ph_filesz, ph_memsz, e_phoff and e_shoff <oriansj>you just have been manually calculating them up until this point <stikonas>well, yes, but that is one time job since header is static <stikonas>it becomes more important once you have debug builds etc... <oriansj>ph_filesz and ph_memsz are just the size of the file <stikonas>oh, I think for riscv we don't calculate those.. <stikonas>I didn't update those for any of my hex0 files <stikonas>they still seemed to work but I guess better to fix <oriansj>stikonas: if the values are wrong a little bit it is ok. BUT if the values are too low and your program will not be entirely loaded into memory <stikonas>once you merge it, I'll update submodule in stage0-posix and do fixes there too <stikonas>because for hex1 it was already 3 times smaller than program size <oriansj>e_phoff is either 0x34 or 0x40 for 32- and 64-bit ELF executables, respectively. and e_shoff are where to lookup the section headers (blood-elf output) in early stages will just be zero <stikonas>and there is an unnecessary TODO in e_entry, I think it can be removed...