[DC] Add merge operation

[mortbopet]

Looks like we're going to have to introduce a possibility for non-determinism in DC to make it generally applicable.

dc.merge will non-deterministically select one of the incoming tokens and emit an output (dc.value<i1>) stating which token was selected.

[lucas-rami]

LGTM!

[teqdruid]

Great! I was thinking: is there a reason that this operation shouldn't give priority to one of the two images no matter what?

[mortbopet]

@teqdruid hmm... giving it a bit of thought, I'm not finding any situation where a prioritized merge wouldn't lead to a situation that couldn't, probabilistically speaking, be reached with a non-deterministic merge. And nevertheless, the hardware implementation would have to give priority. I like it. I personally cannot stand non-deterministic semantics, so that solves that whole ordeal... just make it deterministic with priority!

[teqdruid]

If you say so...

I don't know exactly how you define "determinism" in this context. I had just assumed that you defined it as having the same result with different pipeline depths (aka timing in the literature) -- kinda like a KPN is deterministic. By that definition, I don't think what we need would be deterministic. "On a given cycle, consume a token from the priority input if there's one available there", which is the mechanism by which a KPN guarantees determinism. But I'm faaaaaar from knowledgeable in the field of theoretical control networks.

If, however, you define determinism as "same outputs under the same pipeline depths" (i.e. timing) then that's a different matter and we could absolutely build something which is deterministic.

Overloaded terms are very painful... Especially when they're technical terms.

[mortbopet]

I'm not even thinking about pipelines or anything hardware related at this point - strictly KPN. My definition of a deterministic operation would be "Under any possible input combination (/state), the output of the operation is deterministic".