[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnucap-devel] output plugins, iteration

From: Felix Salfelder
Subject: Re: [Gnucap-devel] output plugins, iteration
Date: Tue, 10 Mar 2015 15:45:12 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

On Mon, Mar 02, 2015 at 03:53:01AM +0100, Felix Salfelder wrote:
> (still no clue about s_fo.)

Hi Al

i have been thinking about this a bit. it's larger than i hoped it would
be. i'd like to collect some thougts on my current path before pushing
another variant. good ideas are welcome.

output plugin implementation details

- simulation output is organized as table with dimensions #probes x #outdata\
  calls. a probe related plugin may do anything with it.
- class PROBE_CMD, base for PROBE related commands (such as "print", 
  implements do_it as it does not together with head, outdata etc. 
- CMD::_type a string identifier for CMD, the identifier is set during command
  invocation, similar to dev_type
- probe related command stores a PROBELIST for each sim type (using a
- OUTPUT_PROBES maintains a list with pointers to all probe related commands.
- PROBELIST. now storing PROBE* (previously PROBE).
  PROBEs are polymorphic. a simulation command may carry its own tailored probe
- SIM::head, SIM::outdata calls OUTPUT_PROBES::head, OUTPUT_PROBES::outdata,
  forwarding to all probe related commands, together with CMD::_type.
- the simulation command has access to corresponding PROBES (using an
  OUTPUT_PROBES::iterator). this seems required for s_fo.
- _sim->_mode remains intact (for now?). special treatment for
  particular commands. (e.g. s_fo currently prints mag, db and phase, as
  well as relative stuff)
- a PROBE instance has a type. either real or complex. the output plugin
  decides what to do.

use case, example

<printcmd> <ident> <probelist>
e.g. "store tran v(nodes)". picks probe prototype from 
then stashes v(nodes) in the PROBELIST dispatcher of the store command plugin at
<simcmd> <args>
e.g. ".tran 0 1 1". runs tran, calls SIM::head, SIM::outdata as usual, passing
data and CMD::_type (="tran") to the probe related commands. the "store" plugin
then processes the probelist registered at "tran".

problems: many. for example:

- PROBE polymorphism feels a bit ugly. yet i don't know how to avoid it.
- a probe related command cannot see probes stashed by another probe related
  command (good or bad?)
- print ac v(nodes)
  (stashes base/default/generic probes)
  ac 1 10 * 2
  runs ac using the wrong probes.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]