freenode/#sicl - IRC Chatlog
Search
14:47:23
beach
http://metamodular.com/SICL/sicl-specification.pdf is what I am working on. Specifically, please look at pages 92 and 93 (PDF pages 102 and 103) for the different cases I came up with for register allocation of one single type of instruction, and only item 8 is handled so far.
14:48:45
beach
And please tell me whether you think I am on the right track or whether this is completely wrong.
14:58:37
beach
And this is just the beginning. No callee-saves registers yet. And no ... what was the name again... re-something for recomputing rather than spilling.
15:00:59
beach
Also, since register allocation is going to be totally important, I am willing to make the technique a bit more complex so as to improve the result.
15:02:44
beach
It is probably possible to factor the description (and the associated code), but I would rather start with a more complete case analysis.
21:16:16
Bike
https://github.com/s-expressionists/Concrete-Syntax-Tree/compare/parse-macro-cst?expand=1 tried rewriting cst:parse-macro to actually input and output CSTs. it ended up... kind of ugly
21:26:03
Gnuxie[m]
beach, I noticed you told someone in #lisp to consider rewriting a crypto library in CL and while I think for their purposes they probably would not be susceptible to timing attacks, I would like to know how you would handle this
21:37:21
Gnuxie[m]
(Idk anything about crypto but surely a solution is making sure that for a given key and input each time you run it you should get a different execution time, rather than trying to make all keys have the same execution time always, although i guess that's more complete)
21:50:02
Bike
putting in a random time would be kind of weird. and if the attacker can also see how hard the computer is working, random sleep calls won't help
23:48:06
no-defun-allowed
Shinmera: Instead of it either blowing the stack or going incredibly slowly, would it be a good idea for the hash table to signal an error if it has resized however many times, but still can't get a key into the table?
23:52:45
Bike
i feel like there ought to be some way to speed up cst:reconstruct, but since practically any macro is going to insert code that's not in the original form, it seems like we have to run an exhaustive search regardless
0:05:57
Bike
this might be an interesting case for meters. i can put in meters and see which particular macros slow things down
0:18:32
Bike
i guess if circular CSTs were marked as such, they could just be searched without consing up a hash table and stuff.
0:23:33
no-defun-allowed
What was that instruction traversing thing which would benefit from fast hash table misses again?
0:24:21
Bike
map-instructions-arbitrary-order, but as i said, in cleavir now that's no longer an issue.
0:26:05
no-defun-allowed
It would only have to check if instructions with multiple predecessors were already mapped, so the table would be used very infrequently. But if it's not an issue, then no problem.
0:30:29
no-defun-allowed
Oh, another CHT thing: should we use the same test function for keys and values? In my case, EQ works fine for testing values when doing conditional updates, as I share structure for everything.
0:32:36
no-defun-allowed
e.g there's a TRY-REMHASH which removes an entry iff the value is some expected value. It's kind of like CASing an entry.
0:35:28
Bike
well, i don't see any reason the keys and values should necessarily use the same test function
0:35:55
Bike
for example, say you have a hash table from function names to functions. then the names have a test function of EQUAL for setf names, but the values can be compared with EQ fine.
0:36:08
no-defun-allowed
I have one table mappings strings to lists of source information objects, so the keys — yeah, same thing.
0:42:29
Bike
the other day i decided a "real" lisp CAS should have a comparator argument, but i can't think of much reason to do fancy stuff except compare integers via EQL instead of EQ