libera/#sicl - IRC Chatlog
Search
21:41:34
Bike
i think the way reconstruct works is screwing up source info for nil constants sometimes. which isn't a huge deal, but i'm noticing it now
21:42:28
Bike
there's probably no way to do it perfectly, but i wonder if i couldn't at least have reconstruct prioritize csts with actual source info... but it would still get a bit screwy
3:06:52
hayley
I think moon-child and I joked about JMP [RIP], and they found that the displacement would be zero, as RIP is set to the location of the next instruction.
3:12:42
hayley
That said, I can't seem to figure out how to get nasm to assemble such an instruction. But I recall Gnuxie and I had discussed RIP-relative addressing in Cluster.
3:15:28
moon-child
beach: I think it might be better to make it a flag than a first-class operand. The rules are finicky, and it's difficult to ensure correctness by construction either way, but I think it might work out better that way
3:17:25
beach
moon-child: OK, I need to look into it a bit. Like I said, whenever a week goes by, I totally forget everything.
3:19:08
hayley
An article has caught my attention about how engineering students don't understand directory structures, because they always use searching tools which don't show the directory structure. I won't link it because it's basically clickbait, but it's almost amusing how people seem to think it is a problem with the students, and not the software.
3:20:51
hayley
Er, I can't remember if RIP-relative effective addresses are constructed differently, but I recall some tables on the OSdev wiki on instruction encoding had some blatant exception to the usual rules.
3:23:36
hayley
Right, RIP is addressed differently to general purpose registers. And the addressing description starts at <https://wiki.osdev.org/X86-64_Instruction_Encoding#32.2F64-bit_addressing>
3:24:10
hayley
The exception to the rule I was thinking of involves using RSP and RBP in effective addresses.
3:27:04
Gnuxie
ACTION is going back to sleep, but just in case, Cluster should already follow that table "to the letter"
3:38:39
beach
I think I can get away with using labels. If I add a protocol function to the assembler that takes both a list of instructions and a list of labels, and that returns a code vector and a list of offsets corresponding to those labels, that should be enough. In fact, I can add it as an &OPTIONAL parameter and a second return value.
3:41:33
beach
Using labels will be slightly inconvenient for the MOV instruction that loads a 64-bit immediate into a register, because the label will reflect the offset of the instruction, and the offset of the immediate will be a bit further.
3:42:12
beach
But I think that kind of stuff could be an independent project to add features to Cluster.
3:54:01
beach
So all I need to do is hold on to relevant labels, and then consult the dictionary returned as a second value.