[rescue] sparc10 cpu - what to do.

[John Hudak]

"The deal-breaker is that compiler backends would have to be much more
complex,
and code would need to be recompiled for each new processor generation. If
it
were that simple, we'd all have ARM desktops now"

that's pretty much the deal with both RISC and VLIW machines.  Simplify the
ID and FU's and replicate & add FUs, and let the compiler sort out the hard
stuff to boost IPC, e.g. loop unrolling, branch reordering, branch target
preloads, etc. with help for some addnl hardware logic, eg.. branch
prediction, shadow registers, register coloring, etc.  One side effect of
this in the hw is that the bus structures on the silicon become more
complex, e.g. more drive capability required, which increases power
draw.  HW architect motto: Always seek to make the compiler writers life
'fun'...
J


On Wed, Dec 21, 2016 at 2:04 PM, Peter Corlett <abuse at cabal.org.uk> wrote:

> On Tue, Dec 20, 2016 at 11:46:31AM -0600, Mark Linimon wrote:
> > On Tue, Dec 20, 2016 at 03:04:31PM +0100, Peter Corlett wrote:
> [...]
> >> Modern Intel x86-64 chips, if you squint. They read in 120-bit wide
> >> "instructions", which consist of up to six x86 instructions which it
> will
> >> attempt to execute in parallel.
> > I've wondered what kind of performance boost we could get if we ran
> directly
> > at the microcode layer (the one that pretends it's this obsolete junk).
>
> There's probably not much in it. You lose a bit on the translation from x86
> code to micro-ops, but win from having a more compact representation and
> less
> I-cache pressure.
>
> The deal-breaker is that compiler backends would have to be much more
> complex,
> and code would need to be recompiled for each new processor generation. If
> it
> were that simple, we'd all have ARM desktops now.
> _______________________________________________
> rescue list - http://www.sunhelp.org/mailman/listinfo/rescue