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
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
