Am 17.03.2014 um 00:34 schrieb John Kasunich <[email protected]>: > >> the basic issue I see is: if you _could_ connect two IO pins without an >> intervening signal, you would get undefined behavior because it is >> unspecified which of the two 'O's gets precedence > > Actually, it is defined - whoever wrote last wins.
that is trivially true on memory write ordering, but it does not specify the writing order a possible library function would decide to implement, and that is what we are discussing here - what is relevant is a value resolution precedence between pins and signals, and that would determine what such a function would have to do >> now you cant do that, you have to go through a signal, which gets precedence >> over the pin value, meaning the signal destroys the pin default value, which >> is counterproductive in the 'pin as parameter' use case > > The destruction of the default value is because > we don't copy "dummy" to the signal, and that > can be fixed as I suggested a couple messages > ago. I would tend to adopt your proposal over mine because it is simpler and suggests no code change. Downside: you cant track 'who did it', see below. Let's just think through possible side effects a bit first. I dont see any offhand though. >> one option would be to add a pin attribute (valid for HAL_IO pins only) say >> HAL_DRIVING_VALUE which determines value resolution during linking - >> basically it says this pin's value has priority over others linked to it: > > How is this attribute added? Who sets it? Is it > done in the component source code? If so, > you are assuming that the component author > understands every use case for the component, > and can choose the proper value. sure. Pin creation time, an attribute passed, hal library function, an additional bit mask to the direction argument maybe. One would explicitly modify the pin creation where the new semantics is desirable. > Or is it done in the HAL file somehow? If so, can you create pins in HAL files? no. So why should that be an issue? > Netting destroys default can be fixed by copying > from dummy to signal on first link. > > If the user is netting two things, each of which has a > compiled in default value, he gets to pick which one > wins by the order of the pins in the net command. > > I just don't see how the HAL_DRIVING_VALUE > attribute helps things. What it does over your proposal is: it defines a precedence order independent of linking order. That means you can ex-post inspect who set any initial value. If you are serious about introspection then you should be able to see the difference. With your proposal, one had to look at the .hal file because the order is dependent on statements in there. It's questionable if that is worth the effort, boils down to a value judgement. Not sure it is. But lets sit the decision for a day or two. (I hope you notice I am more concerned about backwards compatibility of semantics than you are) - Michael ------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
