Re: [PATCH 02/12] score: Add ticks per second to configuration
- Chris Johns 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 . 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
and
#include
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 10
> >
> > and exploit the limited integer ranges. Doesn't work if we check this
> > configuration error in .
> >
>
> 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 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
Re: [PATCH 02/12] score: Add ticks per second to configuration
On Mon, Apr 11, 2016 at 8:17 AM, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:
>
> - Chris Johns 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 . 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
>
> and
>
> #include
>
> 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 10
> > >
> > > and exploit the limited integer ranges. Doesn't work if we check this
> > > configuration error in .
> > >
> >
> > 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 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@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 0/5] Tool Updates
I have pushed this. Thanks,. On Sun, Apr 10, 2016 at 6:20 PM, Chris Johns wrote: > On 11/04/2016 05:01, Joel Sherrill wrote: > >> This patch series updates newlib to 2.4.0 for all targets. For most, >> this was done by changing the default. >> > > Looks good. Please push. > > Thanks > Chris > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Tool Updates
Hi I pushed a patch set that bumped the gcc and newlib version. The main point of the newlib update to 2.4.0 was to pick up the feature flag rework. This may result in new warnings in user code that was strictly non-conformant (or trips a bug in the feature flag rework). Please report issues. Also, I recently posted some POSIX pthread additions and am about to push the first of those. If your toolset is not using at least the newlib from the end of February, you will have to update. The new methods were added to pthread.h on 19 February. Thanks. --joel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 02/12] score: Add ticks per second to configuration
On 11/04/2016 23:37, Joel Sherrill wrote: Ultimately we have to rely on something to do the right thing. The design issue is a struct and code in the score is dependent on something in a header in another file in another part of RTEMS, ie confdefs.h to actually work as expected. It is easy to see the relationship now but in time will that happen. We need to either bring the functionality closer together or check the values are valid or something else or all of the above. The optimisation is a good one and worth doing, we just need a way to handle the implementation issues. What errors are you two worried about that couldn't happen now? The values are different and so different pieces of code have different timeouts. This would be very hard to see on a live system. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] [RSB] use updated newlib revision for or1k
That's Ok, so please merge your patch and discard this one. On Mon, Apr 11, 2016 at 10:40 AM Joel Sherrill wrote: > > On Apr 10, 2016 7:11 PM, "Hesham Almatary" > wrote: > > > > This is the patch. It would conflict with Joel's [PATCH 3/5] > 4.12/rtems-or1k.bset: Update newlib to 2.4.0, so we can choose either > according to the current RSB convention (releases or git revisions). > > The ports need to get to newlib 2.4.0. If I don't merge my patch, can you > bump the newlib version in yours? > > I am holding a few pthread patches that need the updated newlib. > > > On Wed, Mar 30, 2016 at 4:48 PM Stefan Wallentowitz < > ste...@wallentowitz.de> wrote: > >> > >> -BEGIN PGP SIGNED MESSAGE- > >> Hash: SHA1 > >> > >> On 30.03.2016 07:29, Sebastian Huber wrote: > >> > > >> > > >> > On 30/03/16 07:26, Stefan Wallentowitz wrote: > >> >> there is also a GCC-6 snapshot available: > >> >> https://github.com/openrisc/newlib/releases/tag/gcc6-preview > >> >> > >> >> This was the GCC version used in the other architectures last > >> >> week, so maybe it makes sense to bump to this GCC version, too. > >> > > >> > Are there any plans to integrate the or1k stuff into the FSF GCC? > >> > > >> > >> Hi Sebastian, > >> > >> this is unfortunately not possible due to one missing FSF copyright > >> assignment of the original author. We have repeatedly tried to > >> convince him or find a proper workaround, but do not have a solution. > >> But we are keeping up with upstream GCC pretty fast currently. > >> > >> If you accidentally know somehow who would be interested to rewrite > >> the GCC port from scratch.. > >> > >> Cheers, > >> Stefan > >> -BEGIN PGP SIGNATURE- > >> Version: GnuPG v2 > >> > >> iEYEARECAAYFAlb7aKkACgkQuMYtsrn2U9wbjgCffW0gkH6MDa2T/SnwGGFkXLWe > >> s9oAnAyqPfD8jNiXSdDsfOZW3QIn2anE > >> =BBl7 > >> -END PGP SIGNATURE- > >> ___ > >> devel mailing list > >> devel@rtems.org > >> http://lists.rtems.org/mailman/listinfo/devel > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH] posix: Rename killinfo()
Apparently killinfo() is not defined by POSIX, glibc or FreeBSD. Rename
killinfo() to _POSIX_signals_Send() to cleary mark it as an internal
function.
---
cpukit/posix/include/rtems/posix/psignalimpl.h | 2 +-
cpukit/posix/src/kill.c| 2 +-
cpukit/posix/src/kill_r.c | 2 +-
cpukit/posix/src/killinfo.c| 2 +-
cpukit/posix/src/sigqueue.c| 2 +-
5 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/cpukit/posix/include/rtems/posix/psignalimpl.h
b/cpukit/posix/include/rtems/posix/psignalimpl.h
index 7c1424c..8399a7b 100644
--- a/cpukit/posix/include/rtems/posix/psignalimpl.h
+++ b/cpukit/posix/include/rtems/posix/psignalimpl.h
@@ -107,7 +107,7 @@ bool _POSIX_signals_Clear_signals(
booldo_signals_acquire_release
);
-int killinfo(
+int _POSIX_signals_Send(
pid_t pid,
int sig,
const union sigval *value
diff --git a/cpukit/posix/src/kill.c b/cpukit/posix/src/kill.c
index 6e28f00..ee2c1b0 100644
--- a/cpukit/posix/src/kill.c
+++ b/cpukit/posix/src/kill.c
@@ -30,6 +30,6 @@ int kill(
int sig
)
{
- return killinfo( pid, sig, NULL );
+ return _POSIX_signals_Send( pid, sig, NULL );
}
diff --git a/cpukit/posix/src/kill_r.c b/cpukit/posix/src/kill_r.c
index a25961e..97dcd43 100644
--- a/cpukit/posix/src/kill_r.c
+++ b/cpukit/posix/src/kill_r.c
@@ -37,6 +37,6 @@ int _kill_r(
intsig
)
{
- return killinfo( pid, sig, NULL );
+ return _POSIX_signals_Send( pid, sig, NULL );
}
#endif
diff --git a/cpukit/posix/src/killinfo.c b/cpukit/posix/src/killinfo.c
index 7a70539..3df670c 100644
--- a/cpukit/posix/src/killinfo.c
+++ b/cpukit/posix/src/killinfo.c
@@ -54,7 +54,7 @@
#define _POSIX_signals_Is_interested( _api, _mask ) \
( (_api)->signals_unblocked & (_mask) )
-int killinfo(
+int _POSIX_signals_Send(
pid_t pid,
int sig,
const union sigval *value
diff --git a/cpukit/posix/src/sigqueue.c b/cpukit/posix/src/sigqueue.c
index 380ada6..56292bf 100644
--- a/cpukit/posix/src/sigqueue.c
+++ b/cpukit/posix/src/sigqueue.c
@@ -31,5 +31,5 @@ int sigqueue(
const union sigval value
)
{
- return killinfo( pid, signo, &value );
+ return _POSIX_signals_Send( pid, signo, &value );
}
--
1.8.4.5
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
