IRC channel logs

2021-08-02.log

back to list of logs

<stikonas>ok, now I need to deal with immediates in kaem-minimal.M1...
<stikonas>converted most other instructions into M1 format except for immediates and labels (la instructions)
<stikonas>I guess at least with current unmodified M1 that's as good as I can get
<stikonas>well, maybe I can convert unmangled immediates
<stikonas>oriansj: https://github.com/oriansj/mescc-tools/blob/master/hex2_word.c#L62 did you mean J-type there instead of UJ?
<stikonas>and I guess SB means B-type
<stikonas>ok, so those convoluted ones...
<oriansj>stikonas: the document I have lists the 6 instruction formats: R,I,S,SB,U and UJ
<oriansj>So I am guessing they just simplified the name SB to just B and UJ to just J
<oriansj>with SB being used by beq and bge and UJ being used by jal
<stikonas>oh probably, I guess that's older documetn
<oriansj>although it looks like they changed JAL to U format in version 2.0 and dropped the J instruction format
<stikonas>an what are we doing with S format?
<stikonas>it's similar to B but with less mangling
<stikonas>JAL is still j-type here where I'm looking
<stikonas>oh, but it says • The JAL instruction has now moved to the U-Type register, and the J instruction has been dropped being
<oriansj>Well S is for sw and sb, so the offset should be an immediate expanded by M1 and not something in hex2
<stikonas>but some other page says The jump and link (JAL) instruction uses the J-type format, where the J-immediate encodes
<stikonas>did they go back and forwards on JAL...
<oriansj>probably
<stikonas>also SD for 64 bits...
<stikonas>I used SD quite a bit actually
<stikonas>cause that's used for pushing to stack
<stikonas>hmm, are we going to need some prefix character in M1 for S-type?
<oriansj>we only need prefixes in M1 for instruction formats which we plan on supporting an immediate that will probably change a bit
<stikonas>hmm, but then what do I do with those prefixes that don't change, i.e. I type is just the number itself bits [11:0]
<stikonas>e.g. I have RD_A1 RS1_SP 8 LD
<stikonas>which M1 is not happy with
<stikonas>hmm, I should familiarize myself with M1 more... Haven't studdied it enough yet :(
*stikonas goes to read source and manuals
<stikonas>oh, I guess I just generate 32 bit integer with %
<stikonas>although I also need . in front
<stikonas>I guess something like RD_A1 RS1_SP DOT %8 LD then
<stikonas>maybe DOT is not the best name though
<stikonas>although I can't think of anything better
<oriansj>well when M1 is ready, it will probably be something like: RD_A1 RS1_SP @8 LD
<oriansj>I can't seem to find the RISC-V SD instruction format. did you mean SB instruction format?
<stikonas>oriansj: I mean SD command with that S-type instruction
<stikonas>I was looking at https://github.com/riscv/riscv-isa-manual/releases/download/Ratified-IMAFDQC/riscv-spec-20191213.pdf
<stikonas>it's those SB SH SW and SD commnads to store data
<oriansj>ok, I was planning on supporting S-type and I-Type and U-Type in M1
<stikonas>yeah, it makes sense...
<oriansj>and I am using https://inst.eecs.berkeley.edu/~cs61c/fa17/lec/07/L07%20Instruction%20Formats%20(6up).pdf
<oriansj>SB, U and UJ seemed the only reasonable instruction formats to support at the hex2 level based on the instructions included in that set.
<oriansj>as R-type doesn't need immediates or offsets
<stikonas>yes, that's the simplest one
<stikonas>all those arithmetic operations with 2 source registers...
<stikonas>hmm, there might be another ugly thing, those la instructions
<stikonas>we probably need to deal with them in hex1 stage
<stikonas>since hex1 calculates offsets to labels
<stikonas>but it's often used in conjunction with AUIPC to have access to more than 12 bits of offsets
<stikonas>maybe at least for hex1 we should restrict jumps to 12 bits (or is that 11 but same idea)
<stikonas>that might mean moving data into the ".text" section
<stikonas>that's a bit ugly...
<stikonas>argh...
<stikonas>well, we'll see when/if we need it
<stikonas>shift amounts might need some further thought too, for now I'll replace shift by 11 with RS2_A1 (11-th register) which should have the same effect
<oriansj>well I can add I-Format to Hex2 to support jalr instructions better via !label
<oriansj>which is usually done in conjunction with AUIPC
<stikonas>it's also used in la pseudoinstruction...
<stikonas>not just jalr
<oriansj>stikonas: short hand instruction formats that need to be offsets need to be supported in hex2. instruction formats that need to be integers (1, -3, etc_ need to be supported in M1
<stikonas>ok, I think I'm almost done with kaem-minimal.M1, will finish tomorrow (only la instructions are left)
<stikonas>and then hex0 encoding...
<oriansj>and prototype I-Format support for hex2 has been added using the !label method
<oriansj>M1 still needs more work but I'll have it done this week.
***attila_lendvai_ is now known as attila_lendvai
***edef is now known as edf0
***qdef is now known as edef
<plasma41>How to bootstrap Kubernetes: Step 1: Abandon all hope https://github.com/kubernetes/kubernetes/issues/76395
<stikonas>yeah, some distributions of kubernetes are even worse...
<stikonas>I think RedHat's version (OpenShift/OKD) are even more entangled
<drakonis>abandon all hope ye who enter here
<ericonr>does it matter if all of that is Go?
<ericonr>the compiler just brings it in...
<stikonas>well, for kubernetes it probably doesn't matter too much, but that openshift stuff even installing it involves bootstrapping from existing cluster
<stikonas>hmm, something strange is going on with hex2 risc-v shift registers... Should fire up gdb to investigate...
<stikonas>oriansj: how am I supposed to use hex2 shift registers on riscv? I'm getting an error from GetTarget which is called here https://github.com/oriansj/mescc-tools/blob/master/hex2_word.c#L341
<stikonas>I'm probably using incorrect syntax in .hex2 file
<stikonas>so I'm trying to encode RD_A1 RS1_SP !8 LD which is an I instruction (hence !)