Menu
▾
▴
Re: [sdcc-devel] mcs51 port, reentrency
|
From: Richard V. <ric...@ne...> - 2015-01-27 16:21:31
|
<html><body><span style="font-family:Verdana; color:#000; font-size:10pt;"><div>Hi,</div><div><br></div><div>I would like to chime in as an "8051 professional with a different opinion," on a<br></div><div>friendly note, just so that people know that there are some other professional </div><div>opinions out there.</div><div><br></div><div>Whenever an embedded system's architecture and design would benefit from an </div><div>RTOS style task/thread model, then one might choose one of the tiny 8051 rtos's </div><div>from various vendors. One can find eight or ten of them on the web in assyb and c, </div><div>your mileage will vary.</div><div><br></div><div>Whenever an embedded system's architecture does not call for an rtos, then one</div><div>might choose to run a state machine or polling loop on the bare metal.</div><div><br></div><div>Keil and IAR subjectively have "more better" 8051 support than does SDCC, but </div><div>that's to be expected and that's why this friendly and enlightening discussion is </div><div>occuring, wouldn't you agree.<br></div><div><br></div><div>I recently switched from Keil to SDCC when I "discovered" the Contiki-OS and wanted</div><div>to build some sensor nodes of my own. That is one of the reasons that I started </div><div>looking at SDCC internals to find out how the compiler works.<br></div><div><br></div><div>Regarding re-entrant and recursion; I might have a helpful comment. In the past I </div><div>found re-entrant code useful for embedded systems, but I avoided recursion on </div><div>systems that did not have virtual memory. If needed, I would use a recursive function </div><div>on an embedded system that was based on linux, but not on a "traditional" embedded </div><div>system. </div><div><br></div><div>Thank you all for the lively and enlightening discussion.<br></div><div><br></div><div>Cheers, Richard.<br></div><div><br></div> <blockquote id="replyBlockquote" webmail="1" style="border-left: 2px solid blue; margin-left: 8px; padding-left: 8px; font-size:10pt; color:black; font-family:verdana;"> <div id="wmQuoteWrapper"> -------- Original Message --------<br> Subject: Re: [sdcc-devel] mcs51 port, reentrency<br> From: "Maarten Brock" <<a href="mailto:sou...@ds...">sou...@ds...</a>><br> Date: Tue, January 27, 2015 6:54 am<br> To: "Development chatter about sdcc" <<a href="mailto:sdc...@li...">sdc...@li...</a>><br> <br> > Maarten,<br> ><br> > No offense, but I think that your personal opinion of wether an RTOS is<br> > suitable for a 8051 should not influence such a technical decision. The<br> > stack/overlay impact on generated code is very important.<br> <br> It is my professional opinion and it is based on the stack, code and speed<br> impact an RTOS requires. I know of no 8051 professional with a different<br> opinion.<br> <br> > For such small platforms, having the choice to allocate locals on stack or<br> > on overlays seems interesting. The same goes for the PIC platform, which<br> > emits absolutely horrendous code where 75% of the operations are moves<br> > between pseudo registers, stack positions, and real registers. On this<br> > platform, an overlay allocator would be best (as is used in MCC18, which<br> > generates 'usable' code).<br> ><br> > That's why my suggestion is to give users the choice of allocating either<br> > on the stack or in overlays. The best would be a keyword or __attribute__<br> > to have control at function level.<br> <br> The current situation is that SDCC gives the users that choice. The<br> keyword is __reentrant. Philipp is arguing it should be removed because it<br> is not C standard compliant.<br> <br> > I agree with you that recursion is not the most useful feature that needs<br> > reentrancy; but there is no need to have *all* the functions reentrant.<br> > Moreover, overlayed ISR would benefit from a better latency without a<br> > stack frame to setup/remove.<br> ><br> > Sébastien Lorquet<br> <br> You cannot easily overlay anything in an ISR, because the interrupt can<br> happen at any time.<br> <br> Maarten<br> <br> ------------------------------------------------------------------------------<br> Dive into the World of Parallel Programming. The Go Parallel Website,<br> sponsored by Intel and developed in partnership with Slashdot Media, is your<br> hub for all things parallel software development, from weekly thought<br> leadership blogs to news, videos, case studies, tutorials and more. Take a<br> look and join the conversation now. <a href="http://goparallel.sourceforge.net">http://goparallel.sourceforge.net</a>/<br> _______________________________________________<br> sdcc-devel mailing list<br> <a href="mailto:sdc...@li...">sdc...@li...</a><br> <a href="https://lists.sourceforge.net/lists/listinfo/sdcc-devel">https://lists.sourceforge.net/lists/listinfo/sdcc-devel</a><br> </div> </blockquote></span></body></html> |