----- Chris Johns <chr...@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.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
