[PATCH 02/12] score: Add ticks per second to configuration

[Joel Sherrill]

On Mon, Apr 11, 2016 at 8:17 AM, Sebastian Huber <
sebastian.huber at embedded-brains.de> wrote:

>
> ----- Chris Johns <chrisj at rtems.org> schrieb:
> > On 8/04/2016 7:34 PM, Sebastian Huber wrote:
> > > On 08/04/16 11:22, Chris Johns wrote:
> > >>> I don't think its feasible to avoid <rtems/confdefs.h>. Its now the
> only
> > >>> way to create a configuration.
> > >>>
> > >>
> > >> Sorry, but I do not like confdefs getting these values in this way.
> > >> This is not a great long term solution. Easy to add very hard to
> remove.
> > >>
> > >> Maybe you need make some score level variables and compute the values
> > >> during configuration.
> > >
> > > In this case they are no longer read-only.
> >
> > Yes and holding RAM base computed values does use a couple of ints. Is
> > there another reason they need to be read only?
>
> On BSP with MMU you get an exception if you modify them.
>
> For cache efficiency its better to put read-only data in the same cache
> lines.
>
> If you put related values into one structure then you only have to load
> the structure base address once and can re-use the register containing the
> address in subsequent load/store operations.
>
> >
> > This change exposes implementation details unrelated to the
> > configuration table. I cannot see a way we can avoid this with out
> > having internal intermediate values. What is being proposed is an
> > optimization and one worth doing but it exposes an optimization detail
> > in an unfortunate way. If the implementation changes and these values
> > are no longer needed can we remove them? We have no control on who uses
> > them once we add them.
>
> I use RTEMS since 2008 and never created my own configuration table. From
> my point of view the user level API is
>
>
confdefs.h came about because when there were already 50-100 tests,
manually creating
and maintaining them was a real pain. Any change in the structures had to
be propagated
manually to all tests. Every test set every field and it was impossible to
know which fields
were really of interest to a test.

Eventually users started using confdefs.h and it moved from a test fixture
to a user aid.
That resulted in much more attention to the formulas for memory allocation
and the need
for it to cover more configuration parameters. Plus be relatively easy to
explain.

 Around 4.9 or 4.10, we began to assume the names of the
various data structures.

The past couple of classes I have taught, I have wondered if it is time to
delete the
"has own table" options. We wouldn't recommend it and wouldn't want to help
someone debug it.

#define CONFIGURE_MICROSECONDS_PER_TICK 123
>
> #include <rtems/confdefs.h>
>
> and
>
> #include <rtems.h>
>
> void f(void)
> {
>   uint32_t upt = rtems_configuration_get_microseconds_per_tick();
> }
>
> What RTEMS does with the configuration input an how it delivers the value
> via rtems_configuration_get_microseconds_per_tick() should be of no concern
> for the application developer.
>
>
That's a general statement which applies to every operation. But whether it
is a macro, value,
or method should be irrelevant to a user.


> >
> > >
> > > One way to test it would be to use
> > >
> > > #define CONFIGURE_MICROSECONDS_PER_TICK 1000000000
> > >
> > > and exploit the limited integer ranges. Doesn't work if we check this
> > > configuration error in <rtems/confdefs.h>.
> > >
> >
> > A concern for me is the separation of the definition and the management.
> > As a compromise maybe documenting the fields as generated would help and
> > then provide a macro in the configuration table header to set the user
> > visible value which then sets the generated values.
> >
> > I would prefer not to pollute the table.
> >
> > Chris
>
> We should not rely on <rtems/confdefs.h> to do the right things. So, a
> run-time check resulting in a fatal error is desirable. I will try to find
> a solution which is testable.  Otherwise, we can keep the things as is,
> since its only a micro optimization.
>
>
There is the option of error checking via macros in confdefs.h. That isn't
a bad line of defense either.
Stops things at compile time.

Ultimately we have to rely on something to do the right thing. What errors
are you two worried about
that couldn't happen now?

--joel


> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax     : +49 89 189 47 41-09
> E-Mail  : sebastian.huber at embedded-brains.de
> PGP     : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20160411/6b8dbf53/attachment-0002.html>