Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!uxc!uxc.cso.uiuc.edu!mcdurb!aglew
From: aglew@mcdurb.Urbana.Gould.COM
Newsgroups: comp.arch
Subject: Re: Fujitsu SPARC Interlocks
Message-ID: <28200273@mcdurb>
Date: 10 Feb 89 17:14:00 GMT
References: <28200269@mcdurb>
Lines: 22
Nf-ID: #R:mcdurb:28200269:mcdurb:28200273:000:863
Nf-From: mcdurb.Urbana.Gould.COM!aglew    Feb 10 11:14:00 1989


Don't get me wrong - I think that SW interlocking is a perfectly valid
approach for compilers and architectures.

Commercially, however, it suffers the problem that two implementations
of the same instruction set might have different needs for interlocking.
So, either software handles the worst case interlocking for both
architectures, or you have hardware interlocking in one of them,
or you require recompilation or binary transaltion to move between the
implementations.
    Neither of recompilation or binary translation is commercially practical
at the moment, and I'd guess not for the next few years, so I'd like to
look at points in the spectrum lying between

    TOTALLY HARDWARE INTERLOCKED
    ...
    Some HW I'L, some SW I'L
    ...
    TOTALLY SOFTWARE INTERLOCKED

ON the mixed points you have options like Cydra's
memory latency register, etc.