On 20/12/16 23:37, Chris Johns wrote:
On 21/12/2016 08:20, Gedare Bloom wrote:
I haven't fully understood the distinction. I get that C11 are
individually (and collectively) smaller. I don't entirely get what is
their time-space tradeoff or when they are less desirable.
There are a few advan
On 21/12/2016 08:20, Gedare Bloom wrote:
I haven't fully understood the distinction. I get that C11 are
individually (and collectively) smaller. I don't entirely get what is
their time-space tradeoff or when they are less desirable.
There are a few advantages to self-contained resources like mu
On Fri, Dec 16, 2016 at 11:26 AM, Sebastian Huber
wrote:
>
>
> On 15/12/16 23:34, Chris Johns wrote:
>>
>> On 15/12/2016 18:02, Sebastian Huber wrote:
>>>
>>> On 14/12/16 22:15, Chris Johns wrote:
On 15/12/2016 00:39, Sebastian Huber wrote:
>
> [...]
Would the "tiny" footprint
On 19/12/16 22:31, Chris Johns wrote:
On 19/12/2016 17:32, Sebastian Huber wrote:
On 16/12/16 21:50, Chris Johns wrote:
If the same storage model and performance can be gained with POSIX why
not look at moving in this direction.
We should change the POSIX synchronization objects
* mutexes,
On 19/12/2016 17:32, Sebastian Huber wrote:
On 16/12/16 21:50, Chris Johns wrote:
If the same storage model and performance can be gained with POSIX why
not look at moving in this direction.
We should change the POSIX synchronization objects
* mutexes,
* rwlocks,
* barriers,
* condition varia
On 16/12/16 21:50, Chris Johns wrote:
On 17/12/16 3:26 am, Sebastian Huber wrote:
On 15/12/16 23:34, Chris Johns wrote:
On 15/12/2016 18:02, Sebastian Huber wrote:
On 14/12/16 22:15, Chris Johns wrote:
On 15/12/2016 00:39, Sebastian Huber wrote:
[...]
Would the "tiny" footprint be smalle
On 17/12/16 3:26 am, Sebastian Huber wrote:
>
>
> On 15/12/16 23:34, Chris Johns wrote:
>> On 15/12/2016 18:02, Sebastian Huber wrote:
>>> On 14/12/16 22:15, Chris Johns wrote:
On 15/12/2016 00:39, Sebastian Huber wrote:
> [...]
Would the "tiny" footprint be smaller if all internal serv
On 15/12/16 23:34, Chris Johns wrote:
On 15/12/2016 18:02, Sebastian Huber wrote:
On 14/12/16 22:15, Chris Johns wrote:
On 15/12/2016 00:39, Sebastian Huber wrote:
[...]
Would the "tiny" footprint be smaller if all internal services
including compiler thread support are made C11? Could this
On 15/12/2016 18:02, Sebastian Huber wrote:
On 14/12/16 22:15, Chris Johns wrote:
On 15/12/2016 00:39, Sebastian Huber wrote:
Use C11 mutexes instead of Classic semaphores as a performance
optimization and to simplify the application configuration.
The use of C11 mutexes has not been agreed t
On 14/12/16 22:15, Chris Johns wrote:
On 15/12/2016 00:39, Sebastian Huber wrote:
Use C11 mutexes instead of Classic semaphores as a performance
optimization and to simplify the application configuration.
The use of C11 mutexes has not been agreed too and we need to discuss
this in more detai
On 14/12/16 22:43, Peter Dufault wrote:
Can someone help clarify the issue?
Is this a “required compiler to build RTEMS” question? That is, are
the compilers currently required to build the RTEMS Sebastian modified
guaranteed to support C11 mutexes, and is it desirable to be more
conservativ
Can someone help clarify the issue?
Is this a “required compiler to build RTEMS” question? That is, are the
compilers currently required to build the RTEMS Sebastian modified guaranteed
to support C11 mutexes, and is it desirable to be more conservative about what
compiler is needed?
If C11 m
On 15/12/2016 00:39, Sebastian Huber wrote:
Use C11 mutexes instead of Classic semaphores as a performance
optimization and to simplify the application configuration.
The use of C11 mutexes has not been agreed too and we need to discuss
this in more detail before we allow use within RTEMS. I w
Use C11 mutexes instead of Classic semaphores as a performance
optimization and to simplify the application configuration.
A performance of Classic semaphores vs. C11 mutexes was measured on the
arm/atsam BSP. A NXP SC16IS752 was connected via SPI. The RTEMS
application used one task to read from
14 matches
Mail list logo
