On Mon, Apr 28, 2014 at 3:08 PM, Stefan Wallentowitz
<[email protected]> wrote:
>
> Dear all,
>
> finally, a big blob with some first multicore changes plus some massive
> changes in newlib for better usability. Summary:
>

Wow, this is way cool!
And massive bonus points for using bleeding edge "OpenRISC community
technology", like fusesoc/orpsoc-cores etc.
I will definitely set a side some time to play with this.

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.

>  * 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?

>   * cherry-pick Stefan's l.lwa/l.swa

No comment ;)

>   * 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.

>   * 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.

>   * 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.

Stefan
_______________________________________________
OpenRISC mailing list
[email protected]
http://lists.openrisc.net/listinfo/openrisc

Reply via email to