libera/#sicl - IRC Chatlog
Search
13:26:01
beach
Bike: Wouldn't it be the case that most functions at the AST level would appear as the CALLEE-AST of a CALL-AST? And those functions can't escape then.
13:28:52
beach
I thought they would be in the paper, but I did a quick scan and couldn't find anything.
13:42:46
beach
For the others, I guess it is harder at the ATS level to track what becomes of them, since there is not the flow aspect of HIR.
13:46:01
beach
Well, this is not something I am planning to implement right now anyway, so I'll just keep it in mind.
13:46:34
beach
It would be interesting to do some quick performance comparisons between code executed by the AST evaluator and code executed by the HIR evaluator.
13:50:41
beach
What I should do now is to think about code generation. It appears that Cluster needs to handle something that is a bit like object code, i.e., in which certain references are not fully resolved. I am obviously not going to do that in the form of symbol tables stored in a file.
13:52:15
beach
I first thought I could get away with using Cluster "labels", but those are at the granularity of an instruction, so the patching code would then need to know where the operands of an instruction are located, which becomes messy.
13:53:35
beach
So I will try to work out in in-memory data structure for representing "object code" and some protocols for managing such code.
13:56:01
beach
The data structure could be as simple as a code vector of (unsigned-byte 8) and a list of pairs (identity . offset).
13:57:57
beach
There may have to be some size information too at some point, but I am pretty sure that we do only full-word patches, at least initially.
14:03:54
beach
I guess the code will always be only partially resolved because of call sites that can change at run time.
14:04:38
beach
So there will be no separate "object code" representation from the "fully resolved" representation.
14:10:26
beach
We probably also need to represent both "references" and "definitions" just like other object code does. So the simple idea with pairs might become a tad more complex.
14:16:17
beach
I think there are only two kinds of things to patch: 1. The target address of an unconditional jump, and 2. A full-word immediate value to load into a register.
14:23:45
beach
So I guess I will allow IMMEDIATE-OPERAND to take a value that is something other than an integer, and such an operand will match a descriptor with a 64-bit immediate operand. And I will allow for the unsigned jump instruction to contain a label that is not in the stream of Cluster instructions.
14:28:44
beach
Alternatively (for the immediate operand), I will have a subclasses of IMMEDIATE-OPERAND that include the type (8, 16, 32, 64 bit) and create a 64-bit operand with a value of 0. Then I will maintain a pointer to that operand and have it tracked as part of the translation procedure.
14:38:05
beach
Oh, wait. We concluded that there is no unconditional jump with an immediate 64-bit address, didn't we?
14:49:51
beach
Maybe we concluded that we need to free up a scratch register and use a 64-bit immediate load and a jump via a register.
14:51:58
beach
I can't figure out what "Jump near, absolute indirect, RIP = 64-bit offset from register or memory" means.
15:13:02
beach
So there is a hint where you can do "jmp far qword [rel next]" and then "next: resq ..."
15:16:13
beach
I take it to be a "far" jump so it uses a segment register, but perhaps there is a way to use the same as the current one.
15:26:03
beach
Either the RIP-relative indirect jump or the far jump seem to work, but I am not sure how.
15:28:04
Bike
well, as far as i understand, the "near" jump is relative to RIP, but the offset can be at most 32 bits. simple and should be adequate for jumping around within a function.
15:28:29
Bike
the indirect jumps load the address from wherever you specify. i don't see why that couldn't be the bytes immediately following the instruction, i guess?
15:51:13
beach
OK, so it looks like FF/4 JMP r/m64 can work. It's an indirect jump. The address in memory where the target address is located is specified with a modrm byte, so that could be specified to be the full word following the instruction. But it is not clear to me what the full word should contain, i.e., whether it is an absolute address, or an offset from some PC.
15:53:15
beach
I have read the relevant sections in the Intel manuals an uncountable number of times, like for implementing Cluster. But if a week goes by, I forget everything and have to read and understand it again.
15:53:39
Bike
in x86-64 there's no segmentation, so it should just be an absolute address, yeah? it says "absolute" in the table, too
15:54:53
beach
But that's a different instruction. That's the far jump. What I was just referring to is a near jump.
16:04:45
beach
OK, I think I got it (with the near indirect jump). Use a RIP-relative addressing which is Mod=00 R/M = 101 and a 32-bit displacement. The displacement is such that it points to the 64-bit word immediately following the instruction.
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