Home » Archived » DSDP - Real-Time Software Components (RTSC) » notes from the technical followup today
| notes from the technical followup today [message #202] |
Mon, 19 May 2008 21:05  |
Eclipse User |
|
|
|
I tried to summarize the questions and answers from today's call below.
I'm sure I didn't capture everything, so please feel free to post
additional questions/comments.
1. It seems difficult to write tools that extend XDC because the
extensions need to understand JavaScript, right?
Not really. Virtually all of the scripting in RTSC run in the context
of a "model", a model like a web browser DOM. The model is a
declaratively specified (using the RTSC IDL) and only "configuration
parameters" can be updated by a user supplied script. Once the script
completes, a serialized form of the model (often an XML file) is
produced that allows other tools to analyze the model. In addition, it
is possible to re-run the scripts to re-produce the in-memory
representation of the model that tools can examine.
2. How do you capture existing code bases without re-writing all of your
code?
There are several well supported approaches to converting an existing
code based to RTSC components:
1. create a RTSC module whose implementation calls the existing
code base. This enables you to preserve the existing code base
and preserve compatibility with existing customers at the expense
of a function call overhead for those that use the new RTSC
interface.
2. create a meta-only module in this case rather than creating
runtime callable methods, you simply define a RTSC module to
enable the use of configuration by your clients. In this case,
there is no extra overhead and, by leveraging the RTSC
configuration infrastructure, it will simplify the integration of
your existing content with other RTSC components.
3. re-write selected elements of your code base as RTSC modules and
create thin static inline functions that preserve your existing
API's. This preserves compatibility but shifts the overhead
burden to those that chose to remain on the "old" interfaces.
Approach 2 was used in TI's Codec Engine product where the RTSC
packaging aspect and configuration was important to enable users to
extend the Codec Engine with new codecs (delivered in packages), but no
new runtime code was required.
Approach 3 was used in TI's DSP/BIOS product where we wanted to fully
leverage RTSC modules but also provide backward compatibility for
existing customers. We opted to burdon legacy API users because the
extra overhead was small enough that improvements in the underlying
_new_ implementation more than offset this overhead.
3. How do you handle variant data structures without an #ifdef?
Although the RTSC IDL does not allow target specific specifications (one
specification is used for _all_ targets and platforms), it is sometimes
necessary to define some structures based on the target. For example,
you may have a code base that supports both-fixed point and floating
point DSPs. You want to support floating point on the devices that has
HW support for floating point and don't want any overhead associated
with this support on devices that don't support floating point.
RTSC provides several ways to handle this:
1. encoded types each type declared in the IDL can be declared as an
"encoded" type. In this case the actual runtime representation
of the type is declared in a hand-crafter C header file and may
contain target-specific definitions and #ifdefs.
2. Each module can supply a template of C source which is expanded
as part of configuration and becomes part of the application.
When the template is expanded it can conditionally include
4. What function bindings are supported? The Koala model supports
inline, static function calls, and dynamic loadable modules.
The current XDCtools only support inline and static calls. Dynamic
loading of modules has been requested and is being planned for. At this
time we don't have a firm schedule but I'd expect it sometime next year.
5. Are data structures supported by the IDL?
Yes. The IDL allows one to define structures (using a syntax virtually
identical to C), declare structured data objects including arrays,
initialize these structures in the "meta-domain" (where assignments are
type-checked), and generate pre-initialized C structures that can be
accessed by the application at runtime.
6. It would be nice if there were either a more declarative way to
specify a configuration rather then trying to understand/review complex
scripts. Are there any plans for an interactive configuration tool?
The configuration tool produces, as part of it regular output, an XML
file that describes the modules and their configurations _after_ the
user's configuration scrip has run. So, it's possible to review the
result of a configuration script without having to understand the script
itself.
We have a first implementation of a GUI configuration tool that will be
released in the second half of this year. This tool allows the user to
interactively construct a configuration and browse modules for
configuration parameters.
Module producers will have an (initially limited) ability to control the
presentation of the modules configuration parameters. Over time, we
expect that additional "annotations" in the RTSC IDL will enable the
module producer to tightly control the interaction with the user.
7. How are versions handled?
Every package has a "compatibility key" that consists of 4 (or more
numbers):
1. Major number - if this number changes, clients of the package
must re-write their code,
2. Source number - if this number changes, clients must re-compile
their code but no sources need to be changes
3. Radius number, if this number changes existing clients need not
change; the package is binary backward compatible
4. Patch number - if this number changes, the package is both
binary backward _and_ forward compatible with the previous
releases.
The XDC tools capture the compatibility keys of all packages referenced
by a package when it is built. When packages are combined in a
configuration, the XDCtools verify that the packages used to build are
compatible with the packages being assembled.
8. Can you add semantics to interfaces?
In some situations the existing XDC tools provides the interface definer
the ability to perform semantic checks. In particular, during the
configuration process, every package has a chance to reflect on the
configuration model and verify to "correctness and consistency" of the
model. For example, the package that supplies an interface can verify
that only one module in the system implements the interface, that a
particular configuration parameter (defined by the interface), is within
allowable data ranges, etc.
A more general approach which we've prototyped is an implementation of
Design-by-Contract. Within the RTSC IDL specifications, interfaces can
declare executable pre and post conditions for every method. This
approach opens up a variety of powerful tools: from automated testing
tools to real-time monitoring of deployed systems. While it is unlikely
to be a capability that will be added this year, with sufficient
community interest, this is something that can be considered in the next
major update of the RTSC IDL.
|
|
|
| Re: notes from the technical followup today [message #210 is a reply to message #202] |
Wed, 28 May 2008 22:29  |
| Eclipse User |
|
|
|
Originally posted by: eclipse-newsgroups.scharf.gr
Thanks Dave and Bob, this was a very informative phone call!
Great notes! Maybe worth putting into the wiki...
Michael
> I tried to summarize the questions and answers from today's call below.
> I'm sure I didn't capture everything, so please feel free to post
> additional questions/comments.
>
> 1. It seems difficult to write tools that extend XDC because the
> extensions need to understand JavaScript, right?
>
> Not really. Virtually all of the scripting in RTSC run in the context
> of a "model", a model like a web browser DOM. The model is a
> declaratively specified (using the RTSC IDL) and only "configuration
> parameters" can be updated by a user supplied script. Once the script
> completes, a serialized form of the model (often an XML file) is
> produced that allows other tools to analyze the model. In addition, it
> is possible to re-run the scripts to re-produce the in-memory
> representation of the model that tools can examine.
>
> 2. How do you capture existing code bases without re-writing all of your
> code?
>
> There are several well supported approaches to converting an existing
> code based to RTSC components:
> 1. create a RTSC module whose implementation calls the existing
> code base. This enables you to preserve the existing code base
> and preserve compatibility with existing customers at the expense
> of a function call overhead for those that use the new RTSC
> interface.
> 2. create a meta-only module in this case rather than creating
> runtime callable methods, you simply define a RTSC module to
> enable the use of configuration by your clients. In this case,
> there is no extra overhead and, by leveraging the RTSC
> configuration infrastructure, it will simplify the integration of
> your existing content with other RTSC components.
> 3. re-write selected elements of your code base as RTSC modules and
> create thin static inline functions that preserve your existing
> API's. This preserves compatibility but shifts the overhead
> burden to those that chose to remain on the "old" interfaces.
>
> Approach 2 was used in TI's Codec Engine product where the RTSC
> packaging aspect and configuration was important to enable users to
> extend the Codec Engine with new codecs (delivered in packages), but no
> new runtime code was required.
>
> Approach 3 was used in TI's DSP/BIOS product where we wanted to fully
> leverage RTSC modules but also provide backward compatibility for
> existing customers. We opted to burdon legacy API users because the
> extra overhead was small enough that improvements in the underlying
> _new_ implementation more than offset this overhead.
>
> 3. How do you handle variant data structures without an #ifdef?
>
> Although the RTSC IDL does not allow target specific specifications (one
> specification is used for _all_ targets and platforms), it is sometimes
> necessary to define some structures based on the target. For example,
> you may have a code base that supports both-fixed point and floating
> point DSPs. You want to support floating point on the devices that has
> HW support for floating point and don't want any overhead associated
> with this support on devices that don't support floating point.
>
> RTSC provides several ways to handle this:
> 1. encoded types each type declared in the IDL can be declared as an
> "encoded" type. In this case the actual runtime representation
> of the type is declared in a hand-crafter C header file and may
> contain target-specific definitions and #ifdefs.
> 2. Each module can supply a template of C source which is expanded
> as part of configuration and becomes part of the application.
> When the template is expanded it can conditionally include
>
> 4. What function bindings are supported? The Koala model supports
> inline, static function calls, and dynamic loadable modules.
>
> The current XDCtools only support inline and static calls. Dynamic
> loading of modules has been requested and is being planned for. At this
> time we don't have a firm schedule but I'd expect it sometime next year.
>
> 5. Are data structures supported by the IDL?
>
> Yes. The IDL allows one to define structures (using a syntax virtually
> identical to C), declare structured data objects including arrays,
> initialize these structures in the "meta-domain" (where assignments are
> type-checked), and generate pre-initialized C structures that can be
> accessed by the application at runtime.
>
> 6. It would be nice if there were either a more declarative way to
> specify a configuration rather then trying to understand/review complex
> scripts. Are there any plans for an interactive configuration tool?
>
> The configuration tool produces, as part of it regular output, an XML
> file that describes the modules and their configurations _after_ the
> user's configuration scrip has run. So, it's possible to review the
> result of a configuration script without having to understand the script
> itself.
>
> We have a first implementation of a GUI configuration tool that will be
> released in the second half of this year. This tool allows the user to
> interactively construct a configuration and browse modules for
> configuration parameters.
>
> Module producers will have an (initially limited) ability to control the
> presentation of the modules configuration parameters. Over time, we
> expect that additional "annotations" in the RTSC IDL will enable the
> module producer to tightly control the interaction with the user.
>
> 7. How are versions handled?
> Every package has a "compatibility key" that consists of 4 (or more
> numbers):
> 1. Major number - if this number changes, clients of the package
> must re-write their code,
> 2. Source number - if this number changes, clients must re-compile
> their code but no sources need to be changes
> 3. Radius number, if this number changes existing clients need not
> change; the package is binary backward compatible
> 4. Patch number - if this number changes, the package is both
> binary backward _and_ forward compatible with the previous
> releases.
> The XDC tools capture the compatibility keys of all packages referenced
> by a package when it is built. When packages are combined in a
> configuration, the XDCtools verify that the packages used to build are
> compatible with the packages being assembled.
>
> 8. Can you add semantics to interfaces?
>
> In some situations the existing XDC tools provides the interface definer
> the ability to perform semantic checks. In particular, during the
> configuration process, every package has a chance to reflect on the
> configuration model and verify to "correctness and consistency" of the
> model. For example, the package that supplies an interface can verify
> that only one module in the system implements the interface, that a
> particular configuration parameter (defined by the interface), is within
> allowable data ranges, etc.
>
> A more general approach which we've prototyped is an implementation of
> Design-by-Contract. Within the RTSC IDL specifications, interfaces can
> declare executable pre and post conditions for every method. This
> approach opens up a variety of powerful tools: from automated testing
> tools to real-time monitoring of deployed systems. While it is unlikely
> to be a capability that will be added this year, with sufficient
> community interest, this is something that can be considered in the next
> major update of the RTSC IDL.
>
>
--
Michael Scharf
Wind River Systems GmbH
http://www.WindRiver.com
http://MichaelScharf.blogspot.com/
|
|
|
Goto Forum:
Current Time: Tue Nov 04 10:09:27 EST 2025
Powered by FUDForum. Page generated in 0.03327 seconds |
Home