On 1/8/2015 9:01 AM, Eric Botcazou wrote: >> I've worked on a gcc target that was porting an architecture without >> hardware interlock support. Basically, you need to emit nop operations >> to avoid possible hw conflicts. At the moment, this was done by >> patching the gcc scheduler to do so, Another issue to keep is to check >> for hardware conflicts across basic-block boundaries. And not the >> last, is to prohibit/avoid any instruction stream modification after >> scheduler (e.g., peephole optimizations etc.). > That's an overly complex approach, this usually can be done in a simpler way > with a machine-specific pass that runs at the end of the RTL pipeline. > Isn't this similar to needing to fill a delay slot after a branch instruction? My recollection is that some SPARC and MIPS have to deal with that.
-- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.com On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985
