Just some thoughts. Understanding the model is the key.
It might be worth reconsidering how unconnected pins are handled. Letting something read or write to dummy can cause nasty bugs. That's particularly true for writing to dummy. Checking for a null pointer is pretty fast with today's machines -- even with the ARM and other little processors. I wrote a similar system back in the early 70's (the processor was an Intel 8080). The model didn't differentiate between signals and parameters. Everything was implemented as a (logical) value in a named register. The last writer of the value won. There were four thread priorities that ran asynchronously. That could lead to some "interesting" bugs. Regards, Ken On Thu, Jul 21, 2016 at 6:04 PM, John Kasunich <[email protected]> wrote: > dammit, hit the wrong key and sent in the middle of editing > my thoughts on this are still muddled, but I added a couple > of things... > > On Thu, Jul 21, 2016, at 05:57 PM, John Kasunich wrote: > > I started to write a "quick" reply, but the deeper I look > > the more complex it gets - and I have to be somewhere. > > I'm going to post this partial reply now and hope to get > > back to it later... > > > > On Thu, Jul 21, 2016, at 11:00 AM, Jeff Epler wrote: > > > > snippage > > > > > > Note that HAL threads are not started, so the function that updates PO > has > > > never had a chance to run and drive PO's value. > > > > This is a key point. > > > > The "default" values mentioned in that commit message > > were never intended to be defaults. The struct member > > name is "dummy", not "default". > > I only now realized that .comp files can specify a STARTVALUE. > That probably explains how "dummy" has been (mis-)interpreted > as a default... > > > > > HAL pins are nothing more than C pointers. Once connected, > > they point to the value, which is part of the signal struct. > > Since HAL was intended to be simple, clean, and fast, I didn't > > want to force every pin reference to do NULL pointer checks > > to handle unconnected pins. So an unconnected pin still needs > > to point somewhere. The "dummy" field is that somewhere. > > HAL pin pointers must never be NULL. > > > > When HAL component code reads a pin, it reads from the > > pointer. If the pin is connected to a signal, the component > > reads the signal value. If the pin is unconnected, it reads > > the dummy value. > > > > When a HAL component code writes a pin, it writes to the > > pointer. If the pin is connected to a signal, the write goes > > to the signal value. If the pin is unconnected, the write > > goes to the dummy value. > > > > The component code neither knows nor cares if the pin is > > connected. > > > > Sorry if the above is already common knowledge, but knowing > > the implementation makes the behavior easy to understand: > > > > "sets" ALWAYS modifies the value of the signal. If the signal > > has no writers, the "sets" value will persist. If there is a > > writer the value will be over-written by that writer sooner > > or later. > > > > "setp" modifies the target of the pin pointer. If the pin is > > connected, it modifies the value of the signal, just like a > > "sets". If the pin is unconnected, it modifies the dummy > > value. > > > > > Here's the thought experiment I've been using for myself, and > mentioned on IRC: > > > > > > # (newsig rather than creating via net command, to show that a > signal > > > # can also have an explicit initial value) > > > newsig S signed > > > sets S 1 > > > # Note: assume pin PI is direction IN and power-on value 2 > > > net S <= PI > > > # Note: assume pin PO is direction OUT and power-on value 3 > > > net S <= PO > > > # Note: assume pin PJ is direction IN and power-on value 4 > > > net S <= PJ > > > > > > show sig S > > > > > > > > We need to think about input and output pins separately (bidir pins > > too, but they are a mix of both and come later) > > > > For all types of pins, I like to think of components as if they were some > > kind of hardware. Many people have experience with hardware components, > > and the "principle of least astonishment" applies. HAL components should > > behave like regular hardware would, when possible. > > > > For INPUT pins: think about the inputs of say a stereo amplifier. > > Typically the input impedance is very high - the input doesn't drive > > anything, it is driven by other things. However, there is usually a > > weak pull-down to ground so an unconnected input doesn't go > > floating off. > > > > For an unconnected input, ideally the value would be STARTVALUE. > > > > This is where I ran out of time. The problem: > > Sometimes you want an unconnected input to behave like the stereo > with a pull-down to ground - unlink it and it goes back to STARTVALUE. > Other times you want an unconnected input to have memory - unlink > it and the pin retains its current value (what the commit does on unlink). > Certainly if you "setp" an unconnected input you want it to retain that > setp value - that is how we tune PID loops for example. > > > > > > > > -- > John Kasunich > [email protected] > > > ------------------------------------------------------------------------------ > What NetFlow Analyzer can do for you? Monitors network bandwidth and > traffic > patterns at an interface-level. Reveals which users, apps, and protocols > are > consuming the most bandwidth. Provides multi-vendor support for NetFlow, > J-Flow, sFlow and other flows. Make informed decisions using capacity > planning > reports.http://sdm.link/zohodev2dev > _______________________________________________ > Emc-developers mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-developers > -- Kenneth Lerman 55 Main Street Newtown, CT 06470 ------------------------------------------------------------------------------ _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
