<stikonas>hmm, interesting cc_amd64 problems when running directly in qemu without first going into bios menu or uefi shell seem to be stack related <stikonas>though I don't yet understand how exactly <muurkha>oriansj: I agree; it's kind of based on the PDP-8 or the DG NOVA, but the NOVA *did* have 4 registers <stikonas>hmm, it's definitely UEFI shell that initializes something... BIOS menu only works after you exit from uefi shell but not before... <Christoph[m]>If there was, say, editor support for dealing with relative jumps, would you consider the result as written not by humans and thus not acceptable for bootstrap? <Christoph[m]>Or are there so few files that would be benefiting such an effort that it's not worth it? <AwesomeAdam54321>Christoph[m]: I would consider editor support for relative jumps to be acceptable for bootstrapping, if the relative jumps in the editor's source code were calculated by hand <stikonas[m]>Relative jumps are painful to cal calculate but we don't have that many of them <stikonas[m]>And if they are automatically calculated then it's a bit of cheating <Christoph[m]>hex0 code has to be written for each supported architecture? <oriansj>Christoph[m]: well the hardest part of getting started with hex0, usually if you have to figure out all the stupid details which are never documented or are often documented incorrectly. <oriansj>for example ARM incorrectly documents the order of the bits. it isn't [condition code] [operation] [register][register][shift][register], it is actually [shift][register][register][part opcode][register][condition code][part opcode] <oriansj>PowerPC does ELF headers e_entry entirely differently from everyone else <oriansj>RISC-V required a whole song and dance just to get to a minimal working state <oriansj>muurkha: I think their 15bit immediate is probably to blame for the technical choices made in the design. <oriansj>if they went with 32bit instructions, 16bit immediate and 16 registers and added just a handful more circuits to the main design (barrel shifter, call and return); then the assembly programming becomes so much cleaner and you can avoid having to do A = A ^ D; D = A ^D; A = A ^ D; (XOR swaps make me feel like a dirty little programming whore) <stikonas[m]>Christoph: And UEFI versions of hex0 required oriansj to figure out PE32 header <stikonas[m]>And PE32 header is huge, bigger than whole hex0 on POSIX <Christoph[m]>Wow! I expected at least RISC-V to be properly documented! <Christoph[m]>And hex1? Is hex1 architecture independent? Or does that later start with C? <stikonas[m]>hex0 code is architecture dependent (needs to be ported to each ISA/platform) but algorithm is the same <stikonas[m]>So riscv version of hex0 can build hex0_x86.hex0 into 32-bit Elf executable hex0 <stikonas[m]>Then later once we have M2-planet we build C versions (hex2 and M1) to replace early hex2 and M0 <stikonas[m]>The reason is that different arches do quite different things with labels and immediate constants <stikonas[m]>E.g. on x86 call function 5 bytes later is E8 05000000 <stikonas[m]>Whereas on RISC that number is encoded very non trivially <stikonas[m]>First you have bit 20 then 10, 9 8, ..., 1, 11, 19, 18, ..., 12 <stikonas[m]>Actually the other way, this diagram is right to left... <stikonas[m]>So writing hex0 code is much harder on risc-v compared to x86/amd64 <stikonas[m]>On x86 you just take a number, convert to hex and swap byte order to little endian <aggi>this hex0 language, is this equivalent to directly feeding opcodes into the CPU? <stikonas[m]>aggi: basically yes, plus two things: comments and conversion of a pair of ASCII hex numbers to bytes <stikonas[m]>2. kaem-optional-sees: trivial shell that can run other commands, this might be optional if you have a way of running hex0 but is often useful in scripting automations <stikonas[m]>One can just start with hex1 but then your minimal seed would be bigger ***jackhill is now known as KM4MBG
***KM4MBG is now known as jackhill
