calyx icon indicating copy to clipboard operation
calyx copied to clipboard

Represent undefined signals in the interpreter

Open sampsyo opened this issue 4 years ago • 3 comments
trafficstars

Currently, when a signal in a Calyx program doesn't have a meaningful value during interpretation, we currently just say that it has the value zero. For example, when a group is currently "disabled" (i.e., not running), all the stuff it assigns to gets a zero value.

But it actually seems a little odd to be using zero for all these port values—because it looks the same as if someone was explicitly/intentionally writing a zero to it! We should think carefully about how we want to represent "disabled" signals and probably change the interpreter environment to support "undefined" values for these cases. This will also involve figuring out how to represent undefinedness in the output serialization format from the interpreter.

sampsyo avatar Jun 14 '21 14:06 sampsyo

Did #582 fix this issue? @sampsyo @EclecticGriffin?

rachitnigam avatar Aug 27 '21 12:08 rachitnigam

No, #582 is the short-term "solution" where we use zeroes. This broader issue is about introducing an actual undefined state so we can throw errors when reading from undriven signals.

sampsyo avatar Aug 27 '21 15:08 sampsyo

Depends on your view philosophically. #582 solved situations in which undefined values came up by using a zero instead, which fixed issues with assignments remaining "active" when they weren't running anymore.

The reason this is still open however was because the interpreter doesn't actually "represent" undefined values and the thought was that it might be useful to model undefined values explicitly so that the interpreter could give a warning under circumstances where they were being used in places where it seems unwise. For example, the current feeling seems to be that zeroing interface signals when they're not explicitly defined seems to be expected behavior and therefor not undefined but it's not entirely clear that the behavior is expected under all circumstances. It might be reasonable to use zero for an input when the signal is not being driven by anything, but that could just as easily be an error. It's also not obvious for instance what to do with guards which are checking non-driven signals and whether they should work as normal.

Anyway, that was a very long way of saying "kinda, maybe". Curious to hear your thoughts

EclecticGriffin avatar Aug 27 '21 15:08 EclecticGriffin

Closing this as stale for the moment, worth revisiting later on in the redesign efforts

EclecticGriffin avatar May 01 '23 16:05 EclecticGriffin