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 >
