On Thu, Feb 7, 2013, at 02:37 PM, Michael Haberler wrote: > > Am 07.02.2013 um 20:11 schrieb Kenneth Lerman: > > > On 2/7/2013 12:39 PM, Michael Haberler wrote:
> > On 7 February 2013 16:39, Kenneth Lerman <[email protected]> wrote: > > Having parameters that are strings would let us create a general > > calculation component. That would be a component with signal pins and > > calculation pins. The calculation pins would have strings that looked > > like: "((pin3 * pin 4) + pin5)/(6 + pin7)". The component could have a > > interpreter that would permit generic calculations. > > > > I've build this type of thing before (in 1974 with an Intel 8080 > > processor), for both arithmetic and logical (boolean) operations (two > > different components). The original versions used a pretty simple > > interpreter. If I were to do this today, I might build a JIT compiler to > > byte code with a simple interpreter. > > > > Having this type of component would eliminate a bunch of other component > > types and all of the "wiring" among them. > > let me make sure I understand what you two are talking about here: > > > Is this about adding a string flavor variant to these operations? > > http://www.linuxcnc.org/docs/devel/html/man/man3/hal_param_new.3hal.html As a loosely related aside... When HAL was first conceived, pins and parameters seemed very different to me. Pins were the connections between components, and parameters were the adjustments and indicators "internal" to a component. PID is a good example. If you think about 1960-1980 era hardware based analog servo systems, a PID block might be a board or assembly with terminals for input and output, and a few potentiometers to adjust the gains. The terminals are pins, and the pots are parameters. Then someone (I wish I could remember who) pointed out that the distinction between pins and parameters might be artifical and limiting. Suppose you have the PID component, with pins for input and output, and parameters for the tuning values. Now, someone clever comes along and invents an auto- tune component. That component would like to be able to tweak the tuning gains of the PID loop that it is tuning. If they are parameters, it can't do that. If they are pins, then they can be wired to the outputs of the auto-tune component, and it works. After that time, we started blurring the distinction between pins and parameters. (For example, setp doesn't care, it will set either one.) We also started making most new components with a minimum of parameters - we just made everything a pin. The thought at that point was that the pin/parameter distinction was a case of the component designer enforcing a policy on the component user by making the pin/parameter decision ahead of time. The HAL refactor that never happened was probably going to eliminate parameters completely - just make everything a pin. Ken's example is one where there is a distinction between pins and parameters. A HAL pin (or signal connecting pins) that is of type string just makes my head hurt, mostly because it doesn't fit the "electronic components" metaphor for HAL. A string parameter hurts less (but only a little bit). Regardless, it is exciting to see these discussions taking place! Regards, John Kasunich ------------------------------------------------------------------------------ Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
