freenode/#sicl - IRC Chatlog
Search
2:49:45
no-defun-allowed
Hm, a STANDARD-OBJECT-CLASS-OF-INSTRUCTION has appeared in the MIR, and I assume it shouldn't because it would be replaced with a memory load.
3:10:25
no-defun-allowed
The next problem I have is that some lexical variable does not have an attribution, but is an input to an instruction. It is a NOOK-WRITE-INSTRUCTION somewhere in ROW-MAJOR-AREF, so I suppose I am getting somewhere still.
3:15:05
no-defun-allowed
Is there a convention for when to use MEMREF1 and an address addition or MEMREF2? I would guess the latter could only be implemented in one instruction when the offset is constant, on most RISC machines.
3:16:37
beach
I used to have only MEMREF1, but the MIR code because much bigger, and so did the code to generate it.
3:17:11
beach
The idea was to ultimately use "tiling", as suggested by scymtym, but that idea shall have to wait until later.
4:04:49
beach
no-defun-allowed: It looks like you are making great progress, even though you are pretty quiet about it.
4:33:44
no-defun-allowed
The method in question only contains a call to CLEAVIR-PRIMOP:AREF, so I will see if I can find if it appears in the HIR or MIR. Casual inspection of AST-to-HIR suggests that the HIR should be fine still.
4:35:12
beach
I'll let you look a bit yourself. My main mission this morning is to go buy food, so I'll be distracted for a while.
4:45:08
no-defun-allowed
It happens when processing a BOX-INSTRUCTION with element-type DOUBLE-FLOAT, more specifically. And I can see that there is an OBJECT-LOCATION which is an input to that NOOK-WRITE-INSTRUCTION, but never an output.
4:46:25
no-defun-allowed
There is a call to MAKE-INSTANCE which outputs to the output of the original BOX-INSTRUCTION, and I think the NOOK-WRITE-INSTRUCTION should use that location as well.
5:05:09
no-defun-allowed
But come to think of it, there should not be NOOK-{WRITE,READ}-INSTRUCTIONs in MIR if I am not mistaken.
5:08:15
no-defun-allowed
Could I call PROCESS-INSTRUCTION on an intermediate NOOK-WRITE-INSTRUCTION as part of processing BOX-INSTRUCTION?
5:11:08
no-defun-allowed
When boxing a DOUBLE-FLOAT, we generate a call for something like (make-instance 'double-float), producing an object, then write the value into a nook of the object.
6:12:44
no-defun-allowed
Calling PROCESS-INSTRUCTION as I described resulted in MIR which makes a DOUBLE-FLOAT object, but never initializes it. I extracted the body of the method specialized on NOOK-WRITE-INSTRUCTION to a function, and calling that works correctly.
6:45:45
no-defun-allowed
I have apparently now found another location which was never defined during the satiation of E5.
6:50:02
no-defun-allowed
As I understand it, you just continue adding NATURAL JOINs with every table that is relevant.
7:14:56
jdz
This looks like a very relevant paper here: https://dl.acm.org/doi/pdf/10.1145/3140587.3062344 (linked from https://github.com/preames/public-notes/blob/master/unintended-instructions.rst, which I think is also relevant here).
7:20:29
shka_
i can now parse my language just fine https://gist.github.com/sirherrbatka/8b6af20278aa3e8e0c80ee4ebcbd5f58
7:42:07
heisig
I purposely avoid any further contact with ASDF, because doing so increases the risk that I'll have to maintain it someday.
7:44:33
heisig
I see a clear way for a backwards compatible upgrade to ASDF that improves upon such things. But that is precisely the reason why I don't want to get involved.
8:09:06
no-defun-allowed
I found that the problematic function is probably being produced by WRAP-METHOD-COMBINATION-FORM as part of satiation, as the location has a name which only it would generate (a gensym starting with "ARGUMENTS-").