IRC channel logs
2023-11-06.log
back to list of logs
<artemist>I'm working on getting mescc running for aarch64 target and my big problem is how to generate instructions with registers that are not nibble aligned. I could use an accumulator register or just output hex from as.scm <artemist>I'm not sure what people would prefer, neither seems great <artemist>It may also be possible to modify M1 to make it possible to e.g. or words together, but that sounds annoying <stikonas>artemist: we already have that in M1 for riscv <stikonas>and oriansj and I discussed it at some point that it would be nice to convert aarch64 to be word based <stikonas>now the problem is how to do it in backwards compatible way if you don't want to rework stage0-posix-aarch64 <stikonas>possibly need an option to specify which mode to use <stikonas>though right now that file is very risc-v'ish <stikonas>word based stuff is far easier to maintain <stikonas>you basically create a fairly short M1 define list (100 lines or so) <stikonas>and then you can construct any assembly expression ever... <stikonas>M1 needs some support to be able to output word based immediate constants <artemist>That wouls be convenient, I'll look at it <stikonas>artemist: have you seen how mescc deals with riscv64? <stikonas>because of the way or'ing is implemented, opcode is always the last <artemist>I saw this file though I assumed stuff was nibble aligned like it is in aarch32 <stikonas>it's immediates and instructions are not just misaligned <stikonas>but they are also mangled in complicated ways <artemist>This feels like something you come up with so your engineering undergrads can feel clever <stikonas>you can have bit 20, then bits 10 to 1 then bit 11, etc... <stikonas>it might be that somehow this makes instruction decoding in HW simpler <stikonas>e.g. registers are always in the same place... <stikonas>and you can often check sign of immediate earlier <artemist>Is there a reference for how the or works? I can't see it in the hex2 high level prototype <stikonas>basically for riscv we contstruct 32-bit words as <stikonas>so everything that starts with . gets merged into the next thing <artemist>Is stuff swapped again for endianness reasons? <stikonas>plus for riscv we also redefined % & $... <stikonas>hmm, I think it is swapped, but not again <artemist>Oh, sorry, I meant would .01000000 .00020000 .00000300 00000004 turn into 04030201 <stikonas>anyway, take a look at mescc_tools/hex2_word <stikonas>in risc-v those other thigns implement instruction mangling (those formats I showed you in that picture) <artemist>Thanks! I'll figure out how to port this <stikonas>in practive for risc-v it doesn't matter <stikonas>as none of the bits should ever be set in more than one operand <artemist>Mostly just if it's convenient to e.g. default to 64 bit then have a way to switch back to 32 bit, which could work in aarch64 <stikonas>aarch64 also has 32-bit words, doesn't it? <artemist>Yes, I was thinking of whether you use the 64-bit or 32-bit general purpose registers, as a lot of instructions support either <stikonas>e.g. LD, LW, LH and LB loads different sizes... <stikonas>but generally most opcodes have no concept of 64 vs 32-bit <stikonas>e.g. "addi, reg1, reg2, imm1" works on 64-bit registers in riscv64 but on 32-bit registers in riscv32 <artemist>in aarch64 "add x0, x1, x2" would be the full 64 bits but "add w0, w1, w2" would truncate the result to 32 bits <artemist>Same registers, it's just "ignore the top half" <stikonas>so there is addiw reg1, reg2, imm1 that works with 32-bit values <stikonas>but the result is sign extended and writen to 64-bit register <artemist>that difference might be pretty similar on aarch64, it's just a single bit at the top of the instruction that specifies <artemist>Yeah, assemblers being high level has been annoying <artemist>aarch64 assembly really doesn't like exposing the existance of pc-relative instructions <stikonas>there is lui for absolute loads and auipc for relative loads <stikonas>but low level stuff (e.g. hex0) is really pain to write for riscv <stikonas>well, actually only once you reach M0, it becomes nice <artemist>The instructions exist but the assembler really wants you do something like "ldr x0, label" <artemist>mov on aarch64 means so many different actual opcodes <stikonas>mv is actually the same opcode as addi just with zero immediate <muurkha>cedb: you will learn Forth eventually if this kind of thing interests you, probably <muurkha>janneke: congratulations on new stage0 release push! <muurkha>23:52 < artemist> This feels like something you come up with so your engineering undergrads can <muurkha>that was what I thought about the RISC-V instruction format at first too, but when I went to look at where immediate bits come from, I changed my mind; I think it's actually a significant advantage for tiny, low-gate-count RISC-V cores <muurkha>I think there's probably a significant class of designs where this gives you a significantly higher maximum clock speed <muurkha>wrt auipc/addiw or auipc/addi, there's a standard `la` pseudoinstruction that traditional RISC-V assemblers assemble to that instruction pair <artemist>Yeah, true. I guess if the sign bit is always in the same place it's fewer gates to sign extend <artemist>Low gate count is an interesting use case I don't think about a ton, especially since I keep seeing bigger and bigger rv64 socs for linux <muurkha>low gate count is where RISC-V is wildly successful <muurkha>Linux-capable RISC-V is so far kind of an enthusiast niche <muurkha>but in the microcontroller market RISC-V is kicking the shit out of Tensilica and in some cases even ARM <muurkha>also, MIPS. to the point that MIPS the company has totally just thrown in the towel and switched to RISC-V <muurkha>Xilinx announced yesterday that they're ditching MicroBlaze in the same way <muurkha>I think likely Loongson or someone will ship a really compelling Linux-capable RISC-V at some point, but so far they're all a bit anemic <artemist>MIPS seemed on their last legs because of ARM before riscv <jcowan>risc-v is very close to mips, but is opne source <jcowan>and the mips company (Wave) has discontinued mips and is using risc-v anyway <pabs3>and Loongson is moving on to LoongArch, their evolution of MIPS <pabs3>don't think I have seen them mention any RISC-V stuff <matrix_bridge><Andrius Štikonas> The author hasn't finished it though, somebody should test and merge it <matrix_bridge><Andrius Štikonas> I think it has 3 changes and mknod was untested 