libera/#sicl - IRC Chatlog
Search
2:04:11
hayley
A few questions about code organisation of sorts: Which package should register locations be defined in? What package should helper functions for creating instructions (such as LOAD-FROM-STACK-INSTRUCTION) be in? Is there a nicer way to write out address offsets for loading and storing slots of objects?
2:05:26
hayley
I am thinking the first two should be moved to SICL-IR or a x86-64 specific package. SBCL has constants defined somewhere for object tags and slot offsets for the third.
2:11:17
hayley
(With respects to the first, they were first in MIR-to-LIR but now that package depends on SICL-REGISTER-ALLOCATION, creating a circular dependency. And it doesn't sound like it should be in any conversion pass anyway. Hence why it would be a better fit for another IR definitions package.)
3:06:31
beach
Registers are specific to an architecture, so I think MIR-to-LIR is probably the best package for those.
3:07:25
hayley
Functions that create specific instructions, such as loading from and storing to a stack slot.
3:08:48
hayley
Though I'd have to do something with the systems, as currently we would have a circular dependency between register allocation and MIR to LIR.
3:10:38
beach
Since the register-allocation system is also specific to an architecture, you could define the registers there.
3:11:13
beach
Or, you could eliminate the register-allocation package and put everything in MIR-to-LIR. I don't think it matters much.
3:11:43
hayley
The solution I had in mind was to create another system with register location definitions and helper functions, in order to break the dependency cycle and to have somewhere more natural for such definitions.
3:14:50
hayley
And then other information on the use of registers (such as the calling convention for example) would be removed from either system, so that it would be less of a hassle to make it portable with other target instruction sets.
4:00:27
hayley
Still, is there a package with definitions of tag bits and other "magic" numbers like the number of bytes in a word? I can remember how many bytes are in a word, but I need to read the specification to remember tag bits.
4:03:16
hayley
The latter is somewhat harder when an offset for a specific slot is added to the (negative) tag value, ending up in something like a MEMREF instruction with an offset of 3 bytes which takes a while to understand. But I could still just have to remember the tags.
5:28:59
hayley
Is the argument count kept unboxed in a function call? I'm not sure why it would be boxed, but the specification states "Store the argument count in R9 as a fixnum."
5:30:13
hayley
(Though we have instructions like FIXNUM-ADD which operate on unboxed data, so it could be that "fixnum" means a machine integer there too.)
7:34:27
heisig
hayley: I see two sane options for MIR-to-LIR. Either you define one package per architecture, or you make everything generic and have each function dispatch on the architecture.
7:36:19
hayley
I think most of MIR-to-LIR is portable in the sense that we could just change a few variables, and perhaps the instructions generated for spilling and unspilling, and we'd be done with it. So my plan is "Maybe even both".
7:36:53
hayley
I haven't merged for a while, so https://github.com/no-defun-allowed/SICL/tree/master/Code/Compiler/MIR-to-LIR would be up to date with my plans.
7:39:36
hayley
From memory, there are only a few actually x86-64 specific things that aren't in the Registers/ directory now. Still, there is no protocol for introducing a new architecture to MIR-to-LIR.
7:43:01
heisig
How does instruction selection interact with MIR-to-LIR? (Because there is this circular dependency between register allocation and instruction selection.)
7:43:03
beach
I would welcome a cleanup of all that stuff. I was too busy getting something going at all to figure out how to structure the code for different architectures.
7:45:54
hayley
Currently we don't do anything influenced by instruction selection. Are you referring to how, say, the high 8 general purpose registers on x86-64 require an extension byte and the low 8 do not, or how some instruction sets have some useful instructions that others do not?
7:49:45
heisig
No, am referring to something like a complex addressing instruction that can eliminate the need for a register, but only if the other argument resides in a register.
7:52:24
hayley
Right. So far we treat everything as a machine which can only load or store to an address in a register with a constant offset, and I believe this is sort of introduced in MIR. Though I imagine MIR-to-LIR could make more complex addressing modes from simpler MIR, as part of pre-processing.
7:53:49
beach
scymtym has an idea about instruction selection, based on "tiling". I forget the paper he picked that idea from.
7:54:02
hayley
Which reminds me, we would want to drop the two-address conversion business on a better instruction set. But the pre-processing is another thing to parametrize, yes.
7:57:31
heisig
Another issue is the encoding of constants. Some constants can be encoded directly into the operand, some can be reconstructed cheaply with one or two instructions, and some have to be loaded from memory.