IRC channel logs

2021-08-12.log

back to list of logs

<oriansj>vancz: as stikonas pointed out, we do have man pages (just perhaps not to the depth desired) and I am more than happy to expand it to address any specific questions you might have. Provided you are willing to help me clarify to a level which your question is satisfied
<stikonas>oriansj: U-type instructions might also need more work
<stikonas>I think the issue is that once we place 32-bit value there, it is sign-extended to 64 bits
<stikonas>so if I try to place 0xfffff000 then REGISTER ~0xfffff000 LUI does not work
<stikonas>I can load it using 3 instructions and shifts though...
<stikonas>perhaps this can't be solved at M1 level...
<stikonas>and has to be implemented in C compiler
<oriansj>stikonas: well U-type instructions only provide the top half of a 32bit value as (value & 0xfff) < 0x800 wouldn't be true
<oriansj>how would say binutils encode that?
<stikonas>oriansj: they do the following
<stikonas>RD_T2 ~0x100000 LUI
<stikonas>RD_T2 RS1_T2 !-1 ADDIW
<stikonas>RD_T2 RS1_T2 RS2_X12 SLLI
<stikonas>so create the same number in lower bits and then bitshift it
<stikonas>RS2_X12 is shift by 12
<stikonas>so basically load 0x100 with lui; addiw, reg, reg, -1 and slli reg ,reg, 12
<stikonas>on way or another, we'll have to encode these large values, those limits are in source code of hex2 now
<stikonas>in assembly version of hex1/2 I can do this shifting trick
<stikonas>but I guess at least M2-Planet (not sure about cc_*) will have to deal with it
<stikonas>although, I guess we would have to deal with it in any case if we want to support 64-bit numbers
<stikonas>hmm, shouldn't we have encountered similar problem on ARM...
<oriansj>stikonas: well in AMD64 and AArch64, we simply loaded a sign extended 32bit number as M2-Planet operates under the 31bit memory space.
<oriansj>So if one needs a 64bit number that can't be expressed in 32bits, then it isn't going to work in M2-Planet.
<stikonas[m]>Oh i see
<stikonas[m]>So I guess same with RISC-V...
<stikonas[m]>Having some issues debugging hex1.M1 :(. But will continue tomorrow...
<stikonas[m]>Gas version works, m1 version doesn't quite work but I can't spot any difference
<oriansj>stikonas: objdump -d and meld might make it easier to spot the differences.
<stikonas[m]>I tried to even load both into gdb...
<stikonas[m]>Couldn't see anything significantly different in .text
<stikonas[m]>(Only address of buffer area...)
<stikonas[m]>Unless I missed something
<stikonas[m]>Well, I should try to create a smaller reproducer
<oriansj>starting with something that works and slowly add to it (while keeping it working) really helps reduce the number of problem areas
<oriansj>You can also add tracing with stderr and a simple incrementing variable.
<vancz>Thanks for clarifying - I was partly asking on behalf of someone else but this is good to know in case I ever start poking around with this stuff :)