Re: [PATCH] [RSB] use updated newlib revision for or1k

[Hesham Almatary]

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

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

[Chris Johns]

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 0/5] Tool Updates

[Joel Sherrill]

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

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

[Joel Sherrill]

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 02/12] score: Add ticks per second to configuration

[Sebastian Huber]

- 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