dthierbach

Ok, so what do you do if you run out of scratchpad?

I’d assumed that the answer is “the magical spiller”. And yes, I’d still really like to see a talk about the spiller. It’s not so hard to imagine how it should work, but I guess the devil is in the details. From what we’ve seen so far, it seems to be complex enough.

If there are no operations with side effects in the “in-flight” portion of the loop after it finishes, you don’t need an epilogue, as you said in the talk. If there are, I guess you’d unroll it once for each “block” with side-effect ops in it, and then do a usual epilogue, probably within another inner/leave. Or am I missing something?

Looking forward to the rest of the talks and the wiki. A description of the instruction set on the wiki would be nice.

How does the retire operation handle the order of the results? In a steady state, the arguments on the belt should always be in the same order. But the retire operation only knows about the number of expected results, not which FUs should actually produce results in which order. So what if it has to fill in a None somewhere in between? How does it do that?

(If I explained the question badly, maybe I can try to come up with some sample code).

If I understand it correctly, this conversion of literals is baked into Go itself and not extensible.

But it’s interesting that newer languages seem to converge on the “no implicit conversion between numeric types, but conversion of literals” point of view.

Just FYI, Haskell has a nice solution for extensible literals without suffixes: All numeric literals are [implicitely applied](http://www.haskell.org/onlinereport/basic.html#numeric-literals) to an overloaded function fromInteger, which will be optimized away by the compiler when a concrete numeric type is known. So implementing all the saturated/signalling/etc. numeric types in Haskell together with overloaded arithmetic operations (the typeclasses already exist) would be really easy.

Of course, lazy evaluation is not everyone’s cup of tea. Sometimes I wish there was a C variant with a Haskell-style type system.

If you want to think about it, the general solution is to cause any data sources in the pipeline after the predicate to produce Nones. […] We’re also not sure we have found all the cases yet.

This looks really hard to get right in every case, and I probably wouldn’t trust the compiler to get it always right.

Why not introduce an artificial dependency in every store (a sort of phantom argument, maybe just add 0 directly before the store) and let the compiler taint these extra dependencies after the loop has completed instead of trying to taint a source? KISS. One can taint a source because normally you know when it’s a bad value. Similarly, one should dually taint the destination if it becomes invalid.

Ah, I see. I thought it was slot order (for those slots that produce results, so not like in an array), not latency order. Maybe I missed that in the earlier talks. So I assume it’s by slot order for ops with the same latency? Is the latency order guaranteed to be the same across different mills, or does it not matter because this scheduling is done during the “specialization” phase anyway?

That would have been another ten slides

To be honest, I fast forwarded through the first 3/4 or so of the talk. (Amazingly enough, your voice is so deep it’s still quite easy to understand at 2x speed, at 4x it gets a bit difficult :-)) I know you probably try to cater to an audience of varying background, but a few quick asides don’t hurt. Those people interested can usually figure them out without slides.