On Tue, Dec 04, 2012 at 01:26:04PM +0100, Olof Kindgren wrote: > 2012/12/4 Stefan Kristiansson <[email protected]>: > > On Tue, Dec 04, 2012 at 02:10:42PM +0200, Stefan Kristiansson wrote: > >> On Mon, Dec 03, 2012 at 03:17:26PM -0500, Peter Gavin wrote: > >> > 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. > >> > >> How is that any different than any other instruction that is using > >> registers as > >> source for their data? > >> I agree that there will be some overhead if actually implemented in > >> hardware, > >> but so would any other instruction outputting to a debug uart. > >> > >> Or am I completely missing your point here? > > > > Actually, reading your message again and giving this some more thought > > I kind of see what you mean, if you want to have the register output > > ready when you are doing the instruction decoding, you're kind of screwed > > since you don't have the register address in the l.nop instruction. > > > > Stefan > > _______________________________________________ > > Openrisc mailing list > > [email protected] > > http://lists.opencores.org/listinfo/openrisc > > Would it help to use 5 bits in the nop immediate for a register number? >
No, but using the reserved bit [20:16] would. Stefan _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
