libera/#sicl - IRC Chatlog
Search
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.
13:17:14
beach
For the package system, I made two ASDF system definitions, one for the intrinsic system and one for the extrinsic system. Each one has a specific file defining a package. Each package definition has a very similar list of uninterned symbols used in the :EXPORT option of DEFPACKAGE, and the extrinsic system shadows many of the same symbols. I would like to define that list of symbols once. But where (in which file and in which
13:18:16
beach
I am thinking of making a -BASE ASDF system that defines a package to use only for the ASDF systems and of putting a special variable in the -BASE system that contains the list of common uninterned symbols.
13:34:30
Bike
i read your make method lambda paper again since metamodular is back up. it's true that it solves the compiler time behavior problem, but it doesn't deal with the other problems costanza complains about, like the tight coupling between generic functions and method classes, or the call-method stuff i talk about.
13:36:01
beach
I need to read your thing again with respect to call-method. And I need to refresh my memory about the right coupling you are referring to.
13:39:00
beach
The compiler records the name of that class and generates the appropriate call to make-instance for the subsequent DEFMETHOD forms.
13:41:00
beach
That was an "interesting" referee dialogue by the way. I was totally surprised that Costanza took it as a personal attack rather than as joint progress.
13:41:55
beach
I personally welcome any papers by others criticizing claims in mine. I mean, what do I care? Mine has already been published.
13:42:55
beach
Well, it ended well, since he discovered that one of the "examples" in their paper was totally wrong. It was code from the AMOP book, but the wrong code.
13:43:54
beach
And he of course agreed to accept the paper. The required modifications made it better, I think, and I too discovered their mistake and could mention it.
13:46:19
beach
Speaking of which, a recent article in CACM discusses peer reviews for CS conferences, and the process used by ELS seems much more sound than what is the norm.
13:47:53
beach
The norm, to my surprise, seems to be that people apply as candidates for reviewers and the program chair doesn't know who these people are. They are trusted to declare conflicts, but there is a trend of "collusion" where authors and reviewers know one another without declaring it.
13:49:17
beach
For ELS, the members of the program committee are suggested and selected by the program chair, so these people are known, and it is common knowledge if there are conflicts involved.
13:53:26
Bike
i guess your solution does address the coupling, since costanza's basic complaint is that, given a compiler that doesn't know the method class, the behavior of make-method-lambda is entirely dependent on the generic function class
13:53:50
Bike
but even with this fix you'd still have to go kind of out of your way to define methods for the same generic function with different classes
13:55:45
Bike
being able to use defmethod for that would require some additional extension i haven't thought much about either, though. like leeting a defmethod specify a method class.
14:05:57
beach
I am not sure my solution solves every problem, but I was convinced that it solved all the problems indicated in their paper.
14:06:34
beach
So at some point, I'll re-read your post and try to understand it in the context of my paper.
14:10:53
Bike
i mean, it happens in even standard code. you can have a generic function with accessor methods and non-accessor methods.
14:13:25
Bike
it's not more complicated than the current situation. it's just not particularly easier
14:15:13
Bike
a little bit. it's supposed to make the method invocation protocol dependent almost only on the method. but i don't talk about defmethod extensions or anything.