[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



> Chris, please have in mind that operating system
> have to be portable between different or1k implementations.
> So, rather than concentrating on or1200 details, we should
> define or1k architecture in more detail instead.
> 
> Marko

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. 

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

Note that it may run without modifications, although it may
be significantly less efficient. It may also run into timing
difficulties which were not present earlier and which I didn't
think about because I never expected it. 

I don't want to be difficult, but I think it is unrealistic
to ask a programmer to ignore these concerns when writing
code. User level applications can generally ignore the details.
Low level code may not have this luxury. 

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?

God knows as a programmer, I sure as hell want a known, structured
platform under my feet at all times. I'd rather write to 17 well
defined, solid architectures, than a single "fluid" one.

Chris
chris@asics.ws


_______________________________________________________
www.asics.ws - Solutions for your ASIC needs