Rupert Swarbrick

(1) "sort of works", in that there are scripts that you can run by hand. But the user interface is awful (lots of required arguments). We should either teach the...

You're right that this isn't currently wired out to the top-level. I think this is mostly because we haven't needed to do so yet. Do you have an application where...

@tgorochowik: Please correct me if I've mangled something here! :-)

I don't think that turning Ibex into a 5-stage pipeline is a very good idea: that would be a completely different processor and Ibex probably isn't the right starting point...

Yeah, indeed. But isn't the splitting done in terms of the number of these top-level statements already? I *think* that the proposed changes don't make that any worse (or better,...

The only problem with this "first run / later run" distinction is that it would be really nice if this flow worked well: ``` git checkout branch1 make git checkout...

Oh, I see. Could we do something like this Python-ish pseudocode? ```python3 window = MyStmtWindow() cur_size = 0 for stmt in stmts: cur_size += stmt.size() window.take_stmt(stmt) hash_mod = int(100 *...

For the symbol table question: that's a good point. A rather lame approach that I can think of uses more hashes(!). Suppose there are (say) 900 fields needed of a...

> Changing the order of signals depending on model can be around 20% performance. Yikes! Hmm, maybe the hashing scheme isn't such a good idea...

I guess the other thing that we could do would be to mirror the chunking we're describing for the statements. So we'd have (say) blocks of 32 variables that we...