IRC channel logs

<oriansj>good idea

<stikonas>ok, I think I understand what's wrong with my current code

<stikonas>char needs special casing

<stikonas>as it has size 1 (8 bytes)

<stikonas>but using mov_[rbx],al instead of mov_[rbx],rax seems to break something

<stikonas>hmm...

<stikonas>most likely the case of dirty stack

<stikonas>which seemed to workaround

<stikonas>but we need to be more careful with uninitialized stack with other smaller width types...

<stikonas>hmm, so perhaps I actually don't need to use those mov_[rbx],eax instead of mov_[rbx],rax for uint32_t...

<oriansj>sign extension matters

<stikonas>yes, and arithmetic operations such as overflow matter too

<stikonas>after all we want them go behave like 32-bit numbers

<stikonas>possibly overflow is automatic

<oriansj>unfortunately x86 has some weaknesses in correctness there

<stikonas>if we wipe higher bits...

<stikonas>needs some thought...

<stikonas>and I don't want to introduce performance hit for register sized operations...

<stikonas>maybe let me make a PR for struct indirection fix

<oriansj>there is a very good reason why struct types has: int is_signed

<stikonas>I think that's good to have in any case

<stikonas>yeah, I know, operations depend on signed vs unsigned

<oriansj>and so does load behavior (store is more interesting)

<stikonas>argh, and I'm hitting that ifdef error

<stikonas>M2-Planet is also unhappy about it

<stikonas>anyway, that's unrelated to current issue (only happens on M2libc update)

<oriansj>the minute I get back into operational state, I will be clearing out these issues

<stikonas>well, I'll see how much I can clear before that

<stikonas>so that there is less work for yu

<stikonas>for you

<stikonas>probably mostly M2libc stuff as that is where most UEFI work was happening

<oriansj>and existing M2* bugs that I need to address

<stikonas> https://github.com/oriansj/M2-Planet/pull/45

<stikonas>ok, and then I guess I need to pass current_target->is_signed to that store_into_register function as discussed above

<stikonas>and do signed/unsigned extension to full register

<oriansj>and probably add some logic for the 8byte case on 4byte architectures

<stikonas>uint64_t on x86?

<stikonas>hmm, that will probably be a bit more work...

<stikonas>especially operations other than store/load

<oriansj>or we just punt a warning

<stikonas>(multiplication, addition, etc...)

<oriansj>or throw an error

<stikonas>let's do warning for now

<stikonas>or an error

<oriansj>something easy to figure out the reason for like # Load operations for uint64_t are not supported on 32bit hosts at this time

<stikonas>right now we don't even plan to use uint64_t...

<stikonas>I was planning to add up to uint64_t

<stikonas>so (u)int8_t, (u)int16_t and (u)int32_t

<stikonas>or should I add 64 bit variant too?

<stikonas>as soon as we start using it, we'll hit that warning

<stikonas>at least use it outside arch specific M2libc bits

<oriansj>you can proably skip it for now

<Hagfish>stikonas[m]: thanks for the update! i wasn't expecting stage0-uefi to be ready imminently, i was just half imagining that there could be a "subsequent release" around Christmas

<Hagfish>good point about the mailing list, though. i'll try to make sure i'm following that. (i don't know how easy/spammy it would be to set up a bot which pings this channel when new posts reach the ML)

<oriansj>Hagfish: right now it would be pretty low traffic (like 4 emails on a busy day)

IRC channel logs

2022-11-29.log