freenode/#sicl - IRC Chatlog
Search
7:53:04
beach
I think I'll just introduce raw data and register locations into HIR and we'll see what happens.
7:56:35
heisig
beach: What do you mean by 'raw data' and why is that necessary to introduce argument parsing on HIR? (Sorry if I missed that explanation in the logs)
7:58:41
beach
I can wait and introduce it when all HIR transformations are done and I translate to MIR.
8:00:12
beach
But hoisting is a HIR transformation, so then it is too late to introduce the min MIR.
8:04:21
heisig
If I understand correctly, these are only needed to reference a function's arguments.
8:08:24
heisig
But all these things could also be achieved with the current HIR instructions. The only thing that is not possible as of now is to determine the number of arguments, and to access the Nth argument.
8:10:51
heisig
One idea would be to introduce a special object - let's call it 'argument-pack' - and two instructions ARGUMENT-PACK-LENGTH and ARGUMENT-PACK-REF.
8:11:57
heisig
Or, one could rely on the fact that the stack is an implicit argument, and just provide the instructions ARGUMENT-LENGTH and ARGUMENT-REF.
8:12:00
beach
I need to move the arguments from their locations at function entry, to stack locations with lower addresses in order to make room for lexical locations.
8:13:24
heisig
For that, one could add a third instruction FINALIZE-ARGUMENT-PARSING that frees the arguments on the stack.
8:19:55
heisig
In terms of aesthetics, I'd prefer an abstraction like argument-packs to having raw stack manipulation in HIR.
8:21:34
heisig
Of course, I can only make such remarks because I know you would detect bad advice and ignore it :)
8:24:20
beach
I agree that it would be preferable to find some abstract solution. I just haven't come up with one yet.
11:28:41
beach
With only two specific instructions, COMPUTE-ARGUMENT-COUNT-INSTRUCTION and ARGUMENT-INSTRUCTION.
11:29:28
beach
The second one takes a fixnum input (constant or lexical) and has the argument with that number as its output.
11:30:17
beach
I also need an instruction for checking that there is an even number of remaining arguments, so I will introduce FIXNUM-ODDP-INSTRUCTION and FIXNUM-EVENP-INSTRUCTION to HIR.
11:30:48
beach
And I think I'll add the specific ones to HIR as well, in case some implementation would like to use them.
11:31:59
beach
This solution won't express moving the arguments, but that can be done in MIR, because there are no function calls required to do that.
11:35:31
heisig
I'm glad to hear that. It would have been really awkward to have HIR code manage the placement of entities on the stack.
11:36:58
heisig
Now we only need to make sure that the argument parsing code does not clobber the arguments or their count.
11:37:07
beach
Also, aside from the exact error message to be generated for foo few arguments, for too many arguments, and for an invalid keyword argument, the code is standard, so other implementations can use it.
11:40:55
Bike
well, that would be good anyway. that's a hir to mir kind of transformation, i would think
11:42:03
beach
Let's see, integer division between two fixnums is always two fixnums (quotient and rmainder)?
11:45:58
beach
Let me consult the Common Lisp HyperSpec and convince myself that they all, when given two fixnums, result in two fixnums.
11:53:15
Bike
what? i mean, yeah, fixnum divide seems good to me. maybe just have the rounding as a flag in it instead of having four instructions.
11:55:57
no-defun-allowed
Constant Variable CALL-ARGUMENTS-LIMIT: http://www.lispworks.com/documentation/HyperSpec/Body/v_call_a.htm
11:57:52
beach
I think we can proclaim that Cleavir can only handle implementations where it is a fixnum.
12:07:57
beach
The other good thing about this argument parsing technique is that I can do the transformation before I do my HIR-to-CL, and the latter will be simplified too.
12:09:06
beach
Though I should probably pass arguments as vectors rather than lists in HIR-to-CL to benefit the most.
12:42:04
beach
I think the best solution to this problem is to impose some restrictions that have to be tested for. Like imposing that the divisor must be positive.
13:02:21
Bike
by the way, having a distinct class for SSA locations isn't a bad idea, but with how ast-to-hir is organized we can't determine whether a temporary is SSA if it's ever in a context (so, most temporaries). during ast-to-hir, i mean, it's easy to determine afterwards
13:07:08
Bike
that could be changed by introducing a few more temporaries, though, and with the receive instruction stuff
13:09:10
Bike
well, it would mean to get full SSA form we'd have to worry only about actual lexical variables, so that's kind of neat.
13:11:36
Bike
Well, I mean, we only have non-single-assignment temporaries where basic blocks merge. and that's only from block and if, pretty nearly.
13:14:31
Bike
(except for lexical variables, because the source could setq them wherever, of course)
15:10:55
beach
metamodular.com/SICL/checking-every-keyword.pdf is how I imagine the code for checking the validity of each keyword given, should that be necessary.
15:13:37
beach
This is just code for checking the validity. I still have to generate code for determining whether that is actually needed.
15:14:03
beach
But it's just a loop as well, checking for :allow-other-keys, and comparing the following one to NIL.
15:15:35
beach
I am focused on getting things working (with as little effort as possible) before the end of the year.
15:15:59
Bike
yeah, no, sure, i was just mistakenly thinking you weren't accounting for it at all, which would be actually wrong
15:18:01
beach
I will draw similar figures for parsing a single keyword argument, for determining the value of :allow-other-keys as above, for assigning to optional parameters, and for assigning to required parameters.
15:18:29
beach
But it's tedious, so I first do it on paper, and then I clean it up before doing it properly.