<OriansJ`>xentrac: actually it would be easier if I didn't try to minimize the number of opcodes used <xentrac>really? I always have the problem that my immediates bloat from 4 bytes to 8 bytes, although I admit I don't know enough about amd64 to know if that's just because I'm not using it properly <OriansJ`>I am starting to believe the quality of an instruction set is relative to the number of assemblers written in assembly for it. MIPS -> 1, 6502 -> 4 (possibly more) 680x0 -> 2, x86 -> 5 (possibly more), arm -> 0 and powerpc -> 0 <OriansJ`>xentrac: well depending on the immediate, you could load 32bits and sign extend or zero extend <OriansJ`>or load it as an 8bit immediate if it'll fit <xentrac>it's mostly 64-bit immediate offsets for base-offset and base-index-offset addressing modes <xentrac>rather than actual immediate operands <OriansJ`>plus with 16 registers, you cam skip load/stores and drop the immdiates needed there <xentrac>but you could still compute the effective address explicitly, as you say <xentrac>yeah, although those other 8 registers aren't free in the instruction encoding either <OriansJ`>also 16bit immediate offsets cache better performance-wise <OriansJ`>and I just accidentially deleted 30minutes of work. thank god for (setq backup-directory-alist `(("." . "~/.saves"))) <OriansJ`>Soon kaem-minimal.hex0 will be done for AMD64 and then I'll get to work on kaem-minimal.M1 for armv7l <OriansJ`>I should probably update the bootstrap-seeds to leverage the new kaem-minimal.hex0 for AMD64 ***clever_ is now known as clever
<OriansJ`>ugh arm requires such ugly code to map to M0 <OriansJ`>in a sane architecture, you'd do load R2 &label or load R2 %label and be done but no... that would be too simple <OriansJ`>instead of PUSH R2, we get !4 R2 NOSHIFT POSTINC R13 ALWAYS MEMORY ; because arm doesn't actually have push or pop instructions but rather uses those words to mean load/store many with post action increment or decrements. <OriansJ`>oh and the documentation slows the bytes of the instruction in little endian order; aka ass f**king backwards <OriansJ`>and the reason for the instructions having to be word aligned is because isntead of just reading the first byte and knowing the size of the instruction, the decode logic has to read 4bytes and guess if the 2nd or 4th byte is the one that is executed next. <OriansJ`>oh and done bx to an address not 4 byte aligned. Because you are instantly in thumb2 mode and now no opcode means the same thing anymore and f**k mean if I accidentially do bxj instead of bx when working in hex. Because then now only Java ByteCode are valid instructions and you can't leave that mode without exiting to kernel (or getting kernel permissions and directly turn off the Java Bytecode mode) ***ChanServ sets mode: +o rekado_
***rekado_ is now known as rekado