Re: [openrisc] Address pipeline during exception...

["Marko Mlinar" <Marko.Mlinar@campus.fri.uni-lj.si>]

> I completely agree with this statement. I feel the Or1k
> architecture as I've come to understand it is not well
> enough defined. The pipeline structure, command latencies,
> and exception procedures/order should be specified as part
> of Or1k, and not left up to the hardware designer. I want
> to know when I hit an instruction if the cache miss or
> the breakpoint exception will happen first. I want to know
> the latency involved with various things. Having things
> happen randomly (from my perspective) makes my life more
> difficult, and I don't like that in a processor. As a
> telecom and video game engineer, in fact, I abhor it. I
> cherish consistency. 
I completely agree with you or1k architecture should be
well defined, so that there aren't any inconsistencies.

> gcc needs to know about latencies and cycle timings in
> order to generate efficient code. So do I as a software
> designer who wishes to port an OS. I don't consider the
> instruction pipeline as a low level hardware detail. It
> is an integral part of my thought process when producing
> a design. 
I see you enjoy doing hand optimizations ;)
 
> I think placing the pipeline and latencies inside of the
> Or1k spec will resolve most of my concerns. Without this,
> I will argue that each processor is an entity unto itself,
> and even though part of the same family, it may require a
> different OS and tools port. A processor is made up of alot
> more than an instruction set and registers. If the latencies
> or pipelines change, then the architecture has changed as well.
> I will need to modify gcc to tell it that it now must schedule
> 4 instructions between filling a register and operating on it
> (for example) and I must modify my hand written assembly code
> to account for the change.
> 
> Can one of you guys please explain to me why I'm encountering
> such strong resistance from you on this point? Doesn't it make
> sense to enforce as much consistency as possible to make sure
> things are portable? Since this is an open source implementation,
> don't you want to be sure things work...always. ?
I think figured out what you are missing.

Or1k architecture will have a lot of different applications, DSP
processors, superscalars, lowpower, high performance.
This is true, because or1k RTL is completly configurable.

Try to look from this point: or1k is not a processor definition,
but definition of a processor from SW point of view. It is
interface between HW and SW guys. SW see what they get,
HW see what they should implement. Implementation is up to
them. This way you get SW:HW independence.
When you are doing OS port, you should cover all implementations.
I think things are defined in a way that you don't loose much,
when writing portable code.
It is up to implementation to use or1k code in a way that application
needs.

You can write code as there were no pipelines - but you should
decrease dependencies as much as possible - because you have
in mind pipelined and superscalar versions. I don't think this is
so hard to achieve.
Anyway for our applications it is much better that code is portable
than the fact that the user must write its own OS and other utils
if he wants to use or1k... this way nobody will do the effort.

I would suggest the following: If you find any inconsistencies,
or you wish to define some things further, we have to do this
in or1k spec, but in a way, that would support all possible
implementations.

In some implementations, that highly or fully depend on highly specific
code, bits in configuration registers should be used. But these kind of
applications are really rare. Also - as can be noticed from or1k doc
these regs can also be used to define amount of HW resources. SW
should depend only on those - SW should be written in a way that
optimally or nearly optimaly supports all possible configurations, that
you can achieve with given configuration registers. 

This architecture was designed mostly by SW guys, and we designed
towards the goal, that no implementation looses anything, and that
architecture is orthogonal.

Marko