This function is slighly too complex for inlining with two if
statements. The caller already needs a stack frame due to the potential
call to _Thread_Do_dispatch(). In _Thread_Dispatch_enable() the call to
_Thread_Do_dispatch() can be optimized to a tail call.
A text size comparision
(text si
On 10/08/2018 15:41, Sebastian Huber wrote:
> On 10/08/18 07:38, Chris Johns wrote:
>> On 10/08/2018 15:03, Sebastian Huber wrote:
>>> we want a ticket for each milestone in which it is resolved. What is now the
>>> meaning of the version field?
>>>
>> A ticket may be assigned to a branch but not a
On 10/08/18 07:38, Chris Johns wrote:
On 10/08/2018 15:03, Sebastian Huber wrote:
we want a ticket for each milestone in which it is resolved. What is now the
meaning of the version field?
A ticket may be assigned to a branch but not a milestone. Milestones lets us
select which tickets we fix
On 10/08/2018 15:03, Sebastian Huber wrote:
>
> we want a ticket for each milestone in which it is resolved. What is now the
> meaning of the version field?
>
A ticket may be assigned to a branch but not a milestone. Milestones lets us
select which tickets we fix on branch. Once all tickets on a
This bug had probably no effect since the interrupt enable is idempotent
on all CPU ports.
Close #3496.
---
cpukit/include/rtems/score/threaddispatch.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/cpukit/include/rtems/score/threaddispatch.h
b/cpukit/include/rtems/score/t
Hello,
we want a ticket for each milestone in which it is resolved. What is now
the meaning of the version field?
--
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.hu...@e
On 10/08/18 01:44, Chris Johns wrote:
On 07/08/2018 15:33, Chris Johns wrote:
I will ping Amar tomorrow. I do not touch the Trac install.
Amar has installed the clone tool (Thank you). There is now a Clone button on
the tickets besides the Reply and Delete buttons.
Thanks, this makes it easi
On 07/08/2018 15:33, Chris Johns wrote:
>
> I will ping Amar tomorrow. I do not touch the Trac install.
>
Amar has installed the clone tool (Thank you). There is now a Clone button on
the tickets besides the Reply and Delete buttons.
Chris
___
devel m
On Thu, Aug 9, 2018 at 1:13 PM, Amaan Cheval wrote:
> Haha, my tc_frequency was set all wrong, causing the date to be wonky.
>
> The dispatching issue turned out to be a (potential) QEMU bug where
> "decq" wouldn't set the ZF in EFLAGS even if it resulted in a 0 value,
> causing the "jne" to alwa
On Thu, Aug 9, 2018, 11:50 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:
> - Am 6. Aug 2018 um 21:14 schrieb joel j...@rtems.org:
> [...]
> > We looked at a lot of generated assembly. Sometimes we would see
> > large methods being inlined multiple times. This would increase t
Thought this was interesting. At least this info is now in the RTEMS
archives.
-- Forwarded message -
From: Jim Wilson
Date: Thu, Aug 9, 2018, 1:26 PM
Subject: Re: gcov questions
To: daro...@o2.pl , g...@gcc.gnu.org
On 08/09/2018 02:38 AM, daro...@o2.pl wrote:
> Hello, I want
Haha, my tc_frequency was set all wrong, causing the date to be wonky.
The dispatching issue turned out to be a (potential) QEMU bug where
"decq" wouldn't set the ZF in EFLAGS even if it resulted in a 0 value,
causing the "jne" to always be taken.
Anyway, here's where we're at now:
Start @ 0x102
- Am 6. Aug 2018 um 21:14 schrieb joel j...@rtems.org:
[...]
> We looked at a lot of generated assembly. Sometimes we would see
> large methods being inlined multiple times. This would increase the overall
> size of an RTEMS application. But size is not the only impact of inlining.
> If an inli
On Thu, Aug 9, 2018 at 7:43 AM, Amaan Cheval wrote:
> Addition to status: it doesn't seem like the RTEMS Interrupt's call to
> _Thread_Dispatch functions either - ticker.exe has outputs like the
> following (yeah, the counter is running too quickly right now):
>
> *** BEGIN OF TEST CLOCK TICK ***
Addition to status: it doesn't seem like the RTEMS Interrupt's call to
_Thread_Dispatch functions either - ticker.exe has outputs like the
following (yeah, the counter is running too quickly right now):
*** BEGIN OF TEST CLOCK TICK ***
*** TEST VERSION: 5.0.0.2f10634899719c2857e2c8dd5088fb93a425fc
Hi everyone!
Good news! The APIC timer _does_ work now (after implementing 1GiB
pages)! I see Clock_isr_ticks increasing steadily, though I don't have
tc_get_timecount implemented yet - I've yet to figure out the
specifics of the clock driver (how
rtems_configuration_get_microseconds_per_tick infl
16 matches
Mail list logo
