IRC channel logs
2023-07-04.log
back to list of logs
<oriansj>muurkha: mov eax, [memory address] is a simple example <muurkha>I just did and it zeroes the upper 32 bits <muurkha>here's the runnable example so *you* can reproduce that behavior with gas and gdb: <muurkha>main: mov $0xdeadbeeffee1dead, %rax; mov var, %eax; ret <muurkha>you may have to compile with -no-pie <oriansj>you can change the al to ax and the behavior is the same <muurkha>oriansj: that's not an example of affecting only the lower 32 bits of a 64-bit register; it's an example of only affecting the lower 8 or 16 bits of a 64-bit register <muurkha>it's true that the 8- and 16-bit instructions do indeed leave the rest of the register untouched (the whole 64-bit register, not just the lower 32 bits, which I didn't know) <muurkha>but I was asking specifically about 32-bit operations <oriansj>well this is interesting: rasm2 -a x86 -b 64 'mov eax, [0x1234]' vs rasm2 -a x86 -b 32 'mov eax, [0x1234]' looks like the encoding was repurposed <muurkha>yeah, there's a bunch of instructions that changed encoding, which was also true with the 80286→80386 transition <oriansj>I remember seeting that behavior when I was working on M2-Planet; but you are correct as far as I can tell. <muurkha>I think it's a lot more common to want to zero or sign-extend the high part of a 32-bit register (since there isn't any way to use it independently the way there is for AH, BH, CH, DH, SIH, DIH, BPH, and maybe SPH?) <muurkha>so it's kind of unfortunate that Intel's decision with the 80386 was to leave it unchanged <muurkha>it's additionally pretty unfortunate and confusing that amd64 made an inconsistent choice on that count, even if it's more often the useful choice <janneke>efraim: ekaitz even backported the riscv support to our bootstrappable-tcc <janneke>but what the status of any of those tcc's is, no idea ;) <stikonas[m]>janneke: by the way boitstrapoed mes-tcc seems to have at least preprocessor functional <stikonas[m]>(And mes-tcc is somewhat confusingly named, one might think that this is mes built with tcc compiler) <janneke>stikonas[m]: yes, we may want to change those names <janneke>(i believe those names preceded the mes-gcc mes-m2 -mes-mescc era) <stikonas[m]>I was passing -DHAVE_LONG_LONG=1 even to the first build compiled with mescc <oriansj>muurkha: well yes, if you are not doing ugly bit operations but at that point you would want a proper pack and unpack instruction <muurkha>stikonas: I should have had an idea since we previously talked about inline assembler limitations in RISC-V TCC, but I forgot <ekaitz>muurkha: i'm trying to add some RISC-V assembler instructions to tcc <ekaitz>because i need to obtain the symbol addresses and TCC's code is horrible so it's really hard to know where they come from