Hi Holger,

I was just wondering how you got on with Venray and Atomthreads in the
end? Did the processor hit the road?

Best regards,
Kelvin.

On 2 November 2012 08:12, Holger Teutsch <holger.a.teut...@gmail.com> wrote:
> Kelvin,
>
>
> On Fri, Nov 2, 2012 at 12:51 AM, Kelvin Lawson <i...@atomthreads.com> wrote:
>>
>>
>>> The target processor is 64bit and unfortunately the entry_param is
>>> hardwired to 32bit. So it's not possible to pass a pointer in a clean way.
>>>
>>>
>>> Wouldn't it be better to define a port specific ENTRY_PARAM_TYPE like
>>> POINTER ?
>>
>>
>> Yes, this makes sense. I've added an issue on Github and will try to get
>> this into the next release.
>
> Great !
>>
>>
>> Does the full test suite pass? Are you interested in submitting your port
>> to the project? Don't feel like you have to of course, but new architectures
>> are always interesting so I thought I'd ask :-)
>
>
> Yes, the full test suite passes.
> The most complicated task in porting was to adjust the stack sizes of the
> test suite so the stack wasn't overrun *before* stack checking could detect
> it 8-) .
>
> Another idea came to my mind then:
> What about
>
> add a field "POINTER stack_limit" to the TCB. E.g. for an architecture with
> "stack grows downwards" that describes the bottom of the stack.
> the architecture dependent task switcher could do a rather *cheap* overrun
> check when switching stacks on *each* switch
> the port can put a magic word there or just compare pointers on its own
> discretion
> that is much less overhead (and of course a much less rigorous checking)
> than full stack checking but it's frequent
> these extra fields could be added by a preprocessor macro e.g.
> PORT_TCB_EXTRA_FIELDS. That would avoid permanent overhead for all ports.
>
>
> Right now the processor is for demonstrating Venray's IP and currently it's
> all simulated (cgen, gdb's sim, sid & friends). When the processor hits the
> road will submit the port for sure.
>
> Thank you for creating and sharing atomthreads.
>
> Regards
> Holger
>
>

Reply via email to