## Forum Replies Created

Viewing 6 posts - 1 through 6 (of 6 total)
• Author
Posts
• dthierbach
Participant
Post count: 6

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.

• dthierbach
Participant
Post count: 6

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).

• dthierbach
Participant
Post count: 6

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.

• dthierbach
Participant
Post count: 6

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.

• dthierbach
Participant
Post count: 6

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.

• dthierbach
Participant
Post count: 6