IRC channel logs

<oriansj>well as the stage-posix steps are done for RISC-V, we will prove and get everything working

<stikonas>yeah, I should have kaem-minimal.hex0 in the near future...

<stikonas>for hex1 we probably need to implement all label calculations ~!@$ but I guess combining with . is not necessary...

<oriansj>stikonas: well the . is needed for the M1 output

<oriansj>so hex2 will need to support it along with % and &

<oriansj>but @ and $ might be the minimal subset for hex1

<stikonas>by the way, am I correct in assuming that signed bit (11-th) is not yet dealt with in auipc/lui combos?

<oriansj>if you are referring to U format, it is dealt with

<stikonas>oh ok...

<oriansj>with the: (value & 0xfffff000) + 0x1000

<stikonas>hmm, something seemed odd to me when I tried negative value...

<oriansj>you mean -3 when used in U format?

<oriansj>yeah it threw me too

<stikonas>if value = -1 then hex((value & 0xfffff000) + 0x1000) is 0x100000000

<stikonas>shouldn't it have a lot of f's?

<stikonas>oh, ok U itself is fine

<oriansj>stikonas: -1 == 0xFFFFFFFF

<oriansj>so FFFFFFFF & FFFFF000 == FFFFF000

<oriansj>and FFFFF000 + 1000 = 00000000

<stikonas>yeah, ignore that, U seems fine

<stikonas>cause those are just upper bits...

<oriansj>and that is what the documentation says to do.

<oriansj>as 00000000 - 1000 is FFFFF000

<oriansj>which is what RISC-V will do with the sign bit

<oriansj>and If I am wrong, it is trivial to fix

<oriansj>just delete the IF statement and leave value & 0xfffff000

<oriansj>but the DEADBEEF example they provided seems to support the behavior implemented.

<stikonas>no, I think it's correct too now

<fossy>hmm, how weird

<fossy>gnulib-tool does not seem to work properly for coreutils under new linux kernel or something

<oriansj>fossy: sounds like a bug report to me

<stikonas>there is an option of trying different gnulib-tool...

<stikonas>maybe newer coreutils would work

<fossy>well actually its "old" linux kernel but not that old (4.9)

<fossy>wtf, it appears that gnulib-tool is straight up ignoring some of its arguments :O

<xentrac>for compatibility with third-party software?

<fossy>?

<xentrac>that's the usual reason GNU software has arguments it ignores. pretty unlikely explanation for libtool ;)

<fossy>oh, lol

<siraben>Why doesn't this have a function return true when matching with the empty string?

<siraben> https://github.com/oriansj/kaem/blob/fab0724347141af9595a475034d4e689270660ea/functions/match.c#L23

<siraben>s/this have/this/

<siraben>oops I mean

<siraben>Why does it return false when matching with the empty string?

<siraben>here is my rewrite

*siraben < https://libera.ems.host/_matrix/media/r0/download/libera.chat/611401b865a271d1082a4f2098210198750d2054/message.txt >

<siraben>which I also formally verified that it returns true if one of the strings is a prefix of another

<siraben>ah never mind

<siraben> https://github.com/oriansj/kaem/blob/fab0724347141af9595a475034d4e689270660ea/kaem.c#L77

<siraben>my function would always return true

<oriansj>siraben: well that is an old kaem as kaem is currently part of mescc-tools and currently uses M2libc's match function: https://github.com/oriansj/M2libc/blob/main/bootstrappable.c#L36

<stikonas[m]>maybe archive the repository?

<oriansj>probably a good idea

<siraben>Ah I had no idea it was old. Thanks

<siraben>What's the intended behavior of the function?

<oriansj>to return false if the strings don't exactly match.

<oriansj>So mull matches null but doesn't match an empty string

IRC channel logs

2021-08-06.log