On Mon, Dec 3, 2012 at 6:03 AM, Julius Baxter <[email protected]>wrote:
> I have added this functionality to the pronto-espersso pipeline in the > mor1kx by making the l.j 0 instruction (0x00000000) shut down the > fetch stage and only restart to service tick timer or PIC interrupts. > (I intend to add a checker, too, to test if we ever see a "l.j 0" insn > and the PIC or TT units aren't set up then clearly something is wrong, > and warn.) This isn't the best solution, but I think it's perfectly > reasonable to add implementation-dependent behavior like that to > achieve the sort of thing you're suggesting here. > How do you handle the instruction in the delay slot in that case? If it causes an exception or has some other side effect? But yes, my proposed l.halt instruction would essentially behave as if it puts the CPU into an infinite loop. > > But probably what you want is something with defined behavior in terms > of power-saving modes, like what clocks can be turned off or reduced > in frequency, what the longest "wake" latency is, etc. > No, I actually think those things should be implementation dependent. I think only the software visible behavior should be specified. The implementer should be able to decide whether the clock is gated or turned off altogether, and how long it takes to wake back up etc. > I quite like the l.nop trickery, and if anything I'd like for us to > use more of them! :) UARTs are too slow to simulate in Icarus, and for > small point tests of functionality, 99% of your simulation cycles will > be spent printing out the finish message. > > That's a fair point. What I have in mind is that whenever data needs to be output by the testsuite, it calls a function or macro that expands to either l.nops or writes to the UART, or perhaps something implementation specific. This would allow the implementer to choose the mechanism by which the data is output. > We could perhaps introduced the concept of a "debug UART" which is > l.nop printchars in sim and an actual UART in physical > implementations. That would be pretty cool. But I'd say stick with the > l.nop trickery even for that debug output on physical targets, so that > the binary remains the same. > > I think at the very least the l.nop argument space needs to be cleaned up. There are some entries that are no longer used and so on. Another problem is that l.nop REPORT requires that register 3 be read by the pipeline. That's not possible without heavily altering the pipeline design--the register addresses accessed by any given instruction need to be available immediately without any decoding overhead. So if we introduce a debug UART we need to rethink the instructions used to output to it. I would suggest adding a separate instruction just for that purpose. -Pete
_______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
