Hi Kelvin, the project I worked on was for demonstration of Venray's IP in a simulator environment. Their idea is to implement the processor directly in memory. Currently they are working together with a memory manufacturer to bring it to silicon.
Atomthreads worked great. It was easy to port. I have built a (very!) reduced MPI implementation on top of Atomthreads and TOMI's network primitves to run the graph500 benchmark<http://www.graph500.org/specifications>in a multiprocessor environment. This exploited the full range of Atomthreads' functionality. The only thing I missed was a "condition variable". I build something like that with mutexes / semaphores at the application level but an Atomthreads primitive would be more efficient. Best regards Holger On Wed, Oct 2, 2013 at 1:12 AM, Kelvin Lawson <i...@atomthreads.com> wrote: > 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 > > > > >
