Way cool! Let's make this a thing! Multi-core OpenRISC is just what Debian for OpenRISC needs ;)
Regards, Christian On Tue, Apr 29, 2014 at 8:07 AM, Stefan Wallentowitz <[email protected]> wrote: > On 04/29/2014 08:02 AM, Stefan Kristiansson wrote: >> As for the mor1kx changes, I think some of them can be picked in to >> openrisc/mor1kx without much discussion, so I'd like to do that ASAP. >> I have added some small comments on the bullet points below. > Some of the stuff is still experimental, especially you should not pull > the snoop stuff until it also includes cache coherency I think (which I > am integrating). >>> * mor1kx changes (https://github.com/wallento/mor1kx/tree/multicore) >>> * adds SPR_COREID and SPR_NUMCORES >> This can go in as is, but we'll need to add this to the architecture >> specification. >> Do you think you could lay out the text for this so it can easily be >> copy-pasted into the arch spec? > Yes, there is a proposal in the Wiki: > http://opencores.org/or1k/Architecture_Specification on bottom. I think > describing the SPRs in the table is sufficient >>> * adds snoop port to abort atomic on write to same address >> No comment here neither, we can apply this as is, it just needs a >> better commit message. > Yes, I will extend this when I also have the cache coherency in there. >>> * adds trace port (mor1kx_monitor does not work for two cores), this >>> can then be used for synthesizable trace processing >> This is nice, I've been meaning to do something like this for a while. >> I'll take a closer look at it and apply it if I don't find any issues with >> it. > At the moment it only captures PC, insn and potential write back. In > OpTiMSoC we use it to extract l.nop K and R3 combinations for software > instrumentation/tracing plus program counter traces. I already kept the > naming that it is an execution trace. I think it is rather simple to add > other traceports like memory trace etc. >>> * adds ISR0 and ISR1 as "shadow register" alternative for calculations >>> in the prolog of exceptions >>> >> I'll leave this one out. >> *But*, I've given this some more thought since our last conversation about >> this. >> And, I think, if not properly implementing the "fast context switch" >> stuff (which is perhaps a bit overkill) among the options you gave I >> think adding "SPR scratch regs", like you are using the ISR0 and ISR1 >> here, is the best option. >> If we'd be going down that path, we'll need to properly document those >> in the architecture specification. >> I'd really like others to chip in on this discussion before moving >> forward with that though. > Yes, definitely. I just needed this and wanted to demonstrate the > advantage and easiness of this approach ;) We should keep the discussion > alive, as the multicore version will rely on this and or1k-src cannot be > cleanly merged until this is clarified. > > I made vast changes to the newlib and libgloss. Do you or anybody else > (Jeremy, Julius?) have feelings or comments about the reentrancy for > exceptions and separate stack thing? We for example build our lean > runtime system directly with this libc as I always loved the flexibility > in exception handling provided by or1k-support. But I think (independent > of the necessity of reentrancy for SMP multicore), that the flexibility > is further increased by using a different reentrancy structure for > exceptions (at least for printf). > > Bye, > Stefan > > > > _______________________________________________ > OpenRISC mailing list > [email protected] > http://lists.openrisc.net/listinfo/openrisc > _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
