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-").
8:52:03
beach
I see. That's very strange. I don't see how anything at that high level could influence the low levels. Even the HIR level has got to be correct, or else the HIR evaluator would fail. Unless, of course, it is never executed on the result.
8:56:46
beach
One thing you could do then, is to add some output to the HIR evaluator to see whether it ever evaluates something like that. And if it does, then it is a HIR-to-MIR problem.
11:55:20
Gnuxie[m]
hi beach, I'm wanting to make a start on the disassembler today, do you want me to go over my plan?
12:00:28
beach
I am expecting a visit in an hour and sometimes they come early (not likely though), so if I disappear suddenly, then that's it.
12:10:58
Gnuxie[m]
so basically, first I'm going to intern all the instructions in the database by their first opcode byte to support the disassembler
12:11:50
beach
And you know that some instructions have multiple opcode, because some register number may be added to the opcode, yes?
12:18:16
Gnuxie[m]
from the disassembler there will be another table that is used to dispatch on the first opcode byte and decide what to do with the prefixes that are collected, this table is just essentially going to be used because we only intern them by mnemonic otherwise and it's not useful
12:21:39
beach
OK. After that, you should be able to determine whether there is the reg/rm byte or whatever it's called, and that one has a fixed format.
12:22:44
beach
You should also consider whether you want to create a "table interpreter", or generate code from those tables, like in the form of TAGBODYs.
12:23:31
beach
The latter will be faster, but we don't really need performance from the disassembler.
12:25:13
beach
I totally agree. I just don't know which one is easier to maintain; a table interpreter or a table compiler.
12:30:49
beach
Oh, and consider whether you want to use a vector of 256 elements or a hash table for the opcode table.
12:33:35
Gnuxie[m]
I've gone with the vector for now, but I don't plan on making it an issue to change later on
12:37:58
Gnuxie[m]
the process seems really long, I had a paired programming interview thing on Friday that seemed to go really well but they've not contacted me since then
12:39:01
beach
Sounds good. Yes, it can take longer than that. Did they say what method they were going to use to contact you?