freenode/#clasp - IRC Chatlog
Search
14:06:00
scymtym
drmeister: your builder should not assume a particular order for MAKE-NODE calls. RELATE calls for a given LEFT node however occur in order
14:07:45
drmeister
scymtym: C1CCC1 (three-member ring) needs the two '1's to be handled differently. The first one would set a 'ring tag' and the second one will test the ring tag.
14:08:32
drmeister
Is that beyond the scope of the parser and/or the builder and should be left to the thing that runs the final code?
14:18:23
drmeister
Or I can keep track of these ring tags while parsing and then fix them up with a second pass after parsing is complete. Maybe I'll do that.
14:18:58
drmeister
esrap gives me the character position of everything - I just need to record that.
14:19:41
scymtym
drmeister: you could track that information in the parent node (if any, i don't remember) of the AST subtree
14:20:48
scymtym
when the first C1 is added, you could set a flag in the parent (or in a hash-table in the builder) to indicate that tag "1" has already occurred in the current subtree
14:29:30
scymtym
if you have some kind of pattern compilation phase after parsing, handling ring tags there sounds fine
15:10:45
scymtym
yeah, in my experience, doing too much during parsing will often cause problems later
15:12:17
drmeister
We need to recognize things like C1CCC1 where the first '1' means set-ring-tag and the subsequent ones mean 'test-ring-tag'
15:12:55
drmeister
And [$(C1CCC1),$(C1CCCC1)] must be from left to right set-ring-tag, test-ring-tag, set-ring-tag, test-ring-tag
15:13:47
drmeister
So yeah - we have to walk the tree and figure out which '1' comes first and modify that node to be a setter and not a tester.
15:14:38
drmeister
I used nonstandard syntax in our old parser C1CC[C;?1] but that is going to be eliminated.
15:15:00
drmeister
Besides this we need the colon operator to associate tags with atoms for later recovery.
15:15:52
drmeister
Those :1, :2, :3 are tests that always return true but have a side effect that associates the current atom with the tag in a separate hash table.
16:43:00
Bike
or failing that, i guess i can just load babel normally, then manually parallel-compile whichever file the problem is, if you tell me which
16:46:36
Bike
i tried to disassemble a generic function, and it printed something normally but then printed the same instruction thousands of times until i aborted
16:49:41
drmeister
Is the instruction that it printed screwed up - does it have zero length? I think I have to put something in to check for that.
16:50:45
Bike
drmeister: i can use compile-file-parallel, i'm asking which file to compile in babel to reproduce the issue.
16:51:24
drmeister
Oh - I used the (setf (fdefinition 'compile-file) ...) . and then I (load "~/quicklisp/setup.lisp") and then I (ql:quickload "babel")
16:52:56
drmeister
I'm wonder if it's an infinite loop because it's printing the same instruction or if it's a screw up in the length of the function and it is disassembling what it thinks is a very, very, very long function.
16:53:31
drmeister
Can you dump a few lines - say where it goes from looking ok to where it goes crazy?
16:56:43
drmeister
The llvm disassembler is screwing up when dumping the 'sarl' instruction (what is that?) It thinks it's zero length and so it goes into an infinite loop because I don't test for that - I will fix that.
16:57:19
drmeister
The first hex value is the IP. The <#424+1898> I think is the instruction # counting from the start and the instruction offset from the start of the function.
16:57:41
drmeister
Notice how the <#424+1898> the first number increments by one and the second is stuck.
16:58:44
drmeister
Yeah - I don't recognize it - but the last instruction set I memorized was Z80 and that was 30 years ago.
17:01:18
drmeister
It might be an illegal instruction after the tail end of the function and the function end is not exactly the end of the function (I define the end of the function as the start of the next symbol - a bit dangerous -but on macOS I don't have a choice). The disassembler is confused or something.
17:01:59
Bike
i just restarted and set up the discriminating function again and i get a similar bad result, except with `cld` instead of `sarl %cl, %edx`
17:04:34
drmeister
I just put in a sanity check - if it hits a zero length instruction it stops disassembling.
17:04:37
Bike
also, doing some basic timing on bclasp versus bespoke, and i'm not seeing a difference for fast method calls, which is kind of surprising
17:04:48
drmeister
I pushed the change - it's untested but small enough that I'm confident it will compile.
17:07:16
Bike
for the discriminating function timing, it might just be that the method function is most of the time, rather than discrimination. dunno