On Fri, Jul 22, 2016 at 3:06 AM, Chris Johns wrote:
> On 22/07/2016 17:05, Sebastian Huber wrote:
>>>
>>>
>>> _CPU_Context_Get_PC() ?
>>>
>>> I would like this to be localised to the CPU implementation and
>>> something that is figured out when a new port is done.
>>
>>
>> Yes, I think a _CPU_Cont
On 22/07/2016 17:05, Sebastian Huber wrote:
_CPU_Context_Get_PC() ?
I would like this to be localised to the CPU implementation and
something that is figured out when a new port is done.
Yes, I think a _CPU_Context_Get_PC() would be the right way to do this.
Excellent. Thanks for the feedb
On 22/07/16 08:52, Chris Johns wrote:
On 22/07/2016 16:44, Sebastian Huber wrote:
The stack pointer is part of the context. If you retrieve the PC from
here it should work for all threads.
All threads on the i386 arch or all threads on all archs?
I would like to make this simpler for all a
On 22/07/2016 16:44, Sebastian Huber wrote:
The stack pointer is part of the context. If you retrieve the PC from
here it should work for all threads.
All threads on the i386 arch or all threads on all archs?
I would like to make this simpler for all archs. I do not mind if we
require somethi
On 22/07/16 08:43, Sebastian Huber wrote:
On 22/07/16 08:34, Chris Johns wrote:
On 22/07/2016 16:10, Sebastian Huber wrote:
On i386 the PC is stored on the stack frame:
#define _CPU_Context_Initialize( _the_context, _stack_base, _size, \
_isr, _entry_poi
On 22/07/16 08:34, Chris Johns wrote:
On 22/07/2016 16:10, Sebastian Huber wrote:
On i386 the PC is stored on the stack frame:
#define _CPU_Context_Initialize( _the_context, _stack_base, _size, \
_isr, _entry_point, _is_fp,
_tls_area ) \
do { \
uint
On 22/07/2016 16:10, Sebastian Huber wrote:
On i386 the PC is stored on the stack frame:
#define _CPU_Context_Initialize( _the_context, _stack_base, _size, \
_isr, _entry_point, _is_fp,
_tls_area ) \
do { \
uint32_t _stack; \
\
(void) _is_f
On 22/07/16 08:03, Sebastian Huber wrote:
On 22/07/16 07:51, Chris Johns wrote:
On 22/07/2016 15:39, Sebastian Huber wrote:
On 22/07/16 07:30, Chris Johns wrote:
On 22/07/2016 15:26, Sebastian Huber wrote:
Could we please use the _CPU_* prefix only for stuff defined by
the CPU
port inter
On 22/07/16 07:51, Chris Johns wrote:
On 22/07/2016 15:39, Sebastian Huber wrote:
On 22/07/16 07:30, Chris Johns wrote:
On 22/07/2016 15:26, Sebastian Huber wrote:
Could we please use the _CPU_* prefix only for stuff defined by the
CPU
port interface and use something like _I386_* for thing
On 22/07/2016 15:39, Sebastian Huber wrote:
On 22/07/16 07:30, Chris Johns wrote:
On 22/07/2016 15:26, Sebastian Huber wrote:
Could we please use the _CPU_* prefix only for stuff defined by the CPU
port interface and use something like _I386_* for things that are
specific to a particular archit
On 22/07/16 07:30, Chris Johns wrote:
On 22/07/2016 15:26, Sebastian Huber wrote:
Could we please use the _CPU_* prefix only for stuff defined by the CPU
port interface and use something like _I386_* for things that are
specific to a particular architecture.
I would like this to be added to th
On 22/07/2016 15:26, Sebastian Huber wrote:
Could we please use the _CPU_* prefix only for stuff defined by the CPU
port interface and use something like _I386_* for things that are
specific to a particular architecture.
I would like this to be added to the formal _CPU_* port interface.
Withou
Could we please use the _CPU_* prefix only for stuff defined by the CPU
port interface and use something like _I386_* for things that are
specific to a particular architecture.
On 22/07/16 03:17, Chris Johns wrote:
Add an external symbol as a marker to the restore point in the
context switch.
Add an external symbol as a marker to the restore point in the
context switch. If you set the IP to this location for a blocked
thread and you use the saved register values in the TCB you can
view the thread's context.
---
cpukit/score/cpu/i386/cpu_asm.S | 2 ++
1 file changed, 2 insertions(+)
di
14 matches
Mail list logo
