<stikonas>there is still something wrong somewhere but it might be my fault... <stikonas>M1 finished sucessfully, then I appended elf header and hex2 produced binary but that binary dumped core... <oriansj>first sanity check, does that elf_header work with a hello world micro-program or exit 42 microprogram? <oriansj>(a simple M1 program that puts 42 in the required register and does the exit syscall) <oriansj>because there is always the possiblity RISC-V is doing the same sort of thing as PowerPC64le does with e_entry <oriansj>(also please share your elf-header so I can check for common mistakes <stikonas>no, I think it's something with . operation <stikonas>my manually encoded .hex2 file had 03 35 01 00 <oriansj>yeah you would have wanted .00000500 .00010000 30030000 <oriansj>as the .hex are reversed but pure hex are kept in order <stikonas>so that's just a matter of reordering M1 defines <xentrac>so exciting to see this happening :) <stikonas>hmm .00000500 .00010000 30030000 produces 0630 0001 that is strange <stikonas>oh, it has to be .00000500 .00010000 03300000 <oriansj>big endian to little endian note: 12345678 -> 78563412 <stikonas>although, it was convenient for manual encoding to have them in the same order... <stikonas>I think I'll add normal order to . registers in the comment <stikonas>then I can take opcode define and register define from the comment and add them up <stikonas>oh, actually I should be fine without comments too <stikonas>I also need to reverse dotted definitions in M1 def file <oriansj>if you also use --little-endian flag <oriansj>but in RISC-V's case I am not certain as this is new code that I haven't played too much with. <stikonas>oriansj: yeah, I think something is still wrong <stikonas>I suspect immediates have wrong endianness <stikonas>as instructions without immedites/labels seem fine <stikonas>oriansj: e.g. for %56 M1 outputs .00008003 when I think it should output .03800000 <stikonas>(so swap endian bytes and reverse order) <stikonas>well that 12345678 -> 78563412 transformation <stikonas>oriansj: also I think I spotted another bug <stikonas>probably related to why instructions with labels are wrong <oriansj>hex2 could read .hex in big-endian order then switch it to little-endian order. <stikonas>adding an extra arrays of .00000000 should do nothing <stikonas>so I think instruction counter is somehow incremented (during first pass?) <stikonas>anyway, like you said, this is a new code, so will take some time to catch the bugs <stikonas>I think for now I'll go back to encoding kaem-minimal.hex2... <oriansj>yeah DoByte increments by 1 each byte read. <stikonas>without those . blocks I think it was calculating correctly <stikonas>I briefly tested with my unfinished kaem-minimal.hex2 and it was reading data from .data area correctly, and branch jumps seemed to work too <oriansj>ok fix for .hex ip offset behavior fixed. <oriansj>M1 immediates might not be outputting in the order I expected for .hex in hex2 <oriansj>yeah I am going to have to make .hex behavior relative to --little-endian or --big-endian flag is used. <stikonas>hmm, binaries are much closer now, but there are some differences... <stikonas>but I'll go to sleep now, so will look at it tomorrow <stikonas>ok, so I think there is still an issue with immediates, those instructions differ <stikonas>although, at least with your change ".hex" and "hex" have the same order <stikonas>I literally just need to add M1 defines now, don't even have to reverse the order after that <oriansj>it is a small assembly addition for hex2 but it'll take a couple instructions (no jumps or loops needed) <oriansj>and tomorrow when we are both more clear, we will look at immediates in M1 and see where I screwed up ***rt is now known as robin
<stikonas>oriansj: so hex2.c seems to work reasonably well now, at least all labels and jumps are calculated correctly in my handwritten .hex2 file <stikonas>(it does not use all features though, no dots)