[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",
"alarm",...)
implements do_it as it does not together with head, outdata etc.
functionality.
- 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
DISPATCHER<PROBELIST>).
- 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
variant.
- 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
command_dispatcher["tran"].
then stashes v(nodes) in the PROBELIST dispatcher of the store command plugin at
"tran".
<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)
afterwards:
load s_ac.so
ac 1 10 * 2
runs ac using the wrong probes.
thanks
felix