IRC channel logs

2021-08-05.log

back to list of logs

<stikonas>ok, I'll check now
<stikonas>it seems better...
<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
<oriansj>)
<stikonas>no, I think it's something with . operation
<stikonas>so M1 produced
<stikonas>.00000500 .00010000 00003003
<stikonas>when assembled with hex2, hexdump shows
<stikonas>0500 0331
<stikonas>but I think we need 3503 0001
<stikonas>my manually encoded .hex2 file had 03 35 01 00
<stikonas>(I took elf header from https://github.com/stikonas/stage0-posix/blob/kaem-minimal_riscv/riscv64/Development/hex1_x86.hex0)
<oriansj>yeah you would have wanted .00000500 .00010000 30030000
<oriansj>as the .hex are reversed but pure hex are kept in order
<stikonas>oh ok
<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
<stikonas>this works
<oriansj>big endian to little endian note: 12345678 -> 78563412
<stikonas>yeah, I figured it out...
<stikonas>although, it was convenient for manual encoding to have them in the same order...
<oriansj>completely fair
<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
<oriansj>sounds like a good plan
<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
<oriansj>I have an idea that might solve it.
<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.
<oriansj>then it would look right in M1
<stikonas>adding an extra arrays of .00000000 should do nothing
<stikonas>but it changes value of @label
<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.
<oriansj>stikonas: could you look at this patch https://paste.debian.net/1206611/ to see if it fixes behavior when you use --little-endian on M1 and hex2
<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>so convenient for hand-encoding
<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)
<stikonas>yeah, so not too bad
<stikonas>I think let's push this
<oriansj>done
<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)
<oriansj>stikonas: nice.