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

[Sebastian Huber]

----- 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

#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.

> 
> >
> > 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.

-- 
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.