Regarding branch delay instructions in R4000

Regarding branch delay instructions in R4000

[karthikeyan natarajan]

Hi All,

    If this is not a right forum to ask this Question,

please redirect me to the appropriate one...
    Since R4000 is using the 8 stage pipeline, three
instructions are already entered into the pipeline
when the branch instruction is executed. Out of these
three instructions, the first instruction will be 
executed for sure.

My question is:
    What happens to the other two instruction that are
in the delay slots? are they nullified?
    Could anyone please shed some light on this.

Thanks much,
-karthi

=====
The expert at anything was once a beginner

________________________________________________________________________
Yahoo! Messenger - Communicate instantly..."Ping" 
your friends today! Download Messenger Now 
http://uk.messenger.yahoo.com/download/index.html

Re: Regarding branch delay instructions in R4000

[Michael Uhler]

The MIPS architecture specifies a single delay slot after a branch
or jump.  The fact that the R4000 implementation (and pretty much
any of the ones following) had a pipeline in which more instructions
had already entered the pipe before the branch is resolved is not
relevant to the architecture specification.  In the case you
mention, a single instruction is executed after the branch, as
architecturally required, and any subsequent instructions in the
pipe are killed.

/gmu

On Thu, 2003-12-18 at 22:01, karthikeyan natarajan wrote:
> Hi All,
> 
>     If this is not a right forum to ask this Question,
> 
> please redirect me to the appropriate one...
>     Since R4000 is using the 8 stage pipeline, three
> instructions are already entered into the pipeline
> when the branch instruction is executed. Out of these
> three instructions, the first instruction will be 
> executed for sure.
> 
> My question is:
>     What happens to the other two instruction that are
> in the delay slots? are they nullified?
>     Could anyone please shed some light on this.
> 
> Thanks much,
> -karthi
> 
> =====
> The expert at anything was once a beginner
> 
> ________________________________________________________________________
> Yahoo! Messenger - Communicate instantly..."Ping" 
> your friends today! Download Messenger Now 
> http://uk.messenger.yahoo.com/download/index.html
> 
-- 
Michael Uhler, Chief Technology Officer
MIPS Technologies, Inc.  Email: uhler@mips.com  Pager: uhler_p@mips.com
1225 Charleston Road     Voice:  (650)567-5025  FAX:   (650)567-5225
Mountain View, CA 94043  Mobile: (650)868-6870  Admin: (650)567-5085

Re: Regarding branch delay instructions in R4000

[karthikeyan natarajan]

Hi gmu,

    Have got a one more doubt...
MIPS stands for Microprocessor without Interlocked
Pipeline Stages.
    But, in the "R4400_Uman_book_Ed2.pdf" doc, it is
mentioned that the CPU general registers are 
interlocked. I am bit confused after reading this doc.
    Would be great if you clarify this doubt too...

Thanks much,
-karthi

> The MIPS architecture specifies a single delay slot
> after a branch
> or jump.  The fact that the R4000 implementation
> (and pretty much
> any of the ones following) had a pipeline in which
> more instructions
> had already entered the pipe before the branch is
> resolved is not
> relevant to the architecture specification.  In the
> case you
> mention, a single instruction is executed after the
> branch, as
> architecturally required, and any subsequent
> instructions in the
> pipe are killed.
> 
> /gmu
> 
> On Thu, 2003-12-18 at 22:01, karthikeyan natarajan
> wrote:
> > Hi All,
> > 
> >     If this is not a right forum to ask this
> Question,
> > 
> > please redirect me to the appropriate one...
> >     Since R4000 is using the 8 stage pipeline,
> three
> > instructions are already entered into the pipeline
> > when the branch instruction is executed. Out of
> these
> > three instructions, the first instruction will be 
> > executed for sure.
> > 
> > My question is:
> >     What happens to the other two instruction that
> are
> > in the delay slots? are they nullified?
> >     Could anyone please shed some light on this.
> > 
> > Thanks much,
> > -karthi
> > 
> > =====
> > The expert at anything was once a beginner
> > 
> >
>
________________________________________________________________________
> > Yahoo! Messenger - Communicate instantly..."Ping" 
> > your friends today! Download Messenger Now 
> > http://uk.messenger.yahoo.com/download/index.html
> > 
> -- 
> Michael Uhler, Chief Technology Officer
> MIPS Technologies, Inc.  Email: uhler@mips.com 
> Pager: uhler_p@mips.com
> 1225 Charleston Road     Voice:  (650)567-5025  FAX:
>   (650)567-5225
> Mountain View, CA 94043  Mobile: (650)868-6870 
> Admin: (650)567-5085
> 
>  

=====
The expert at anything was once a beginner

________________________________________________________________________
Yahoo! Messenger - Communicate instantly..."Ping" 
your friends today! Download Messenger Now 
http://uk.messenger.yahoo.com/download/index.html

Re: Regarding branch delay instructions in R4000

[Kevin D. Kissell]

Yes, MIPS stood for Microprocessor without Interlocked Pipeline Stages
when it was first used as a name for a graduate student project at Stanford
University in publications from 1982.  But that in itself was a play on words,
as the most common metric of computer perfomance at the time was 
"Millions of Instructions Per Second", or MIPS.  The Stanford architcture 
was revamped and commercialized as the "MIPS I" architecture, implemented 
in the R2000 and R3000 CPUs, which likewise had no interlocks on cache load 
delays. As silicon geometries became finer and gates got cheaper, the relative cost
of providing the interlocks decreased, while the need to run the same MIPS 
binaries on multiple, very different implementations of the architecture increased.
So from the R4000 onwards, MIPS CPUs have had interlocks.  But by that time
the name "MIPS" was a well-known trademark, and it made no sense to change it.

----- Original Message ----- 
From: "karthikeyan natarajan" <karthik_96cse@yahoo.com>
To: "Michael Uhler" <uhler@mips.com>
Cc: <linux-mips@linux-mips.org>
Sent: Saturday, December 20, 2003 10:53
Subject: Re: Regarding branch delay instructions in R4000


> Hi gmu,
> 
>     Have got a one more doubt...
> MIPS stands for Microprocessor without Interlocked
> Pipeline Stages.
>     But, in the "R4400_Uman_book_Ed2.pdf" doc, it is
> mentioned that the CPU general registers are 
> interlocked. I am bit confused after reading this doc.
>     Would be great if you clarify this doubt too...
> 
> Thanks much,
> -karthi
> 
> > The MIPS architecture specifies a single delay slot
> > after a branch
> > or jump.  The fact that the R4000 implementation
> > (and pretty much
> > any of the ones following) had a pipeline in which
> > more instructions
> > had already entered the pipe before the branch is
> > resolved is not
> > relevant to the architecture specification.  In the
> > case you
> > mention, a single instruction is executed after the
> > branch, as
> > architecturally required, and any subsequent
> > instructions in the
> > pipe are killed.
> > 
> > /gmu
> > 
> > On Thu, 2003-12-18 at 22:01, karthikeyan natarajan
> > wrote:
> > > Hi All,
> > > 
> > >     If this is not a right forum to ask this
> > Question,
> > > 
> > > please redirect me to the appropriate one...
> > >     Since R4000 is using the 8 stage pipeline,
> > three
> > > instructions are already entered into the pipeline
> > > when the branch instruction is executed. Out of
> > these
> > > three instructions, the first instruction will be 
> > > executed for sure.
> > > 
> > > My question is:
> > >     What happens to the other two instruction that
> > are
> > > in the delay slots? are they nullified?
> > >     Could anyone please shed some light on this.
> > > 
> > > Thanks much,
> > > -karthi
> > > 
> > > =====
> > > The expert at anything was once a beginner
> > > 
> > >
> >
> ________________________________________________________________________
> > > Yahoo! Messenger - Communicate instantly..."Ping" 
> > > your friends today! Download Messenger Now 
> > > http://uk.messenger.yahoo.com/download/index.html
> > > 
> > -- 
> > Michael Uhler, Chief Technology Officer
> > MIPS Technologies, Inc.  Email: uhler@mips.com 
> > Pager: uhler_p@mips.com
> > 1225 Charleston Road     Voice:  (650)567-5025  FAX:
> >   (650)567-5225
> > Mountain View, CA 94043  Mobile: (650)868-6870 
> > Admin: (650)567-5085
> > 
> >  
> 
> =====
> The expert at anything was once a beginner
> 
> ________________________________________________________________________
> Yahoo! Messenger - Communicate instantly..."Ping" 
> your friends today! Download Messenger Now 
> http://uk.messenger.yahoo.com/download/index.html
> 
> 

Re: Regarding branch delay instructions in R4000

[Kevin D. Kissell]

Yes, MIPS stood for Microprocessor without Interlocked Pipeline Stages
when it was first used as a name for a graduate student project at Stanford
University in publications from 1982.  But that in itself was a play on words,
as the most common metric of computer perfomance at the time was 
"Millions of Instructions Per Second", or MIPS.  The Stanford architcture 
was revamped and commercialized as the "MIPS I" architecture, implemented 
in the R2000 and R3000 CPUs, which likewise had no interlocks on cache load 
delays. As silicon geometries became finer and gates got cheaper, the relative cost
of providing the interlocks decreased, while the need to run the same MIPS 
binaries on multiple, very different implementations of the architecture increased.
So from the R4000 onwards, MIPS CPUs have had interlocks.  But by that time
the name "MIPS" was a well-known trademark, and it made no sense to change it.

----- Original Message ----- 
From: "karthikeyan natarajan" <karthik_96cse@yahoo.com>
To: "Michael Uhler" <uhler@mips.com>
Cc: <linux-mips@linux-mips.org>
Sent: Saturday, December 20, 2003 10:53
Subject: Re: Regarding branch delay instructions in R4000


> Hi gmu,
> 
>     Have got a one more doubt...
> MIPS stands for Microprocessor without Interlocked
> Pipeline Stages.
>     But, in the "R4400_Uman_book_Ed2.pdf" doc, it is
> mentioned that the CPU general registers are 
> interlocked. I am bit confused after reading this doc.
>     Would be great if you clarify this doubt too...
> 
> Thanks much,
> -karthi
> 
> > The MIPS architecture specifies a single delay slot
> > after a branch
> > or jump.  The fact that the R4000 implementation
> > (and pretty much
> > any of the ones following) had a pipeline in which
> > more instructions
> > had already entered the pipe before the branch is
> > resolved is not
> > relevant to the architecture specification.  In the
> > case you
> > mention, a single instruction is executed after the
> > branch, as
> > architecturally required, and any subsequent
> > instructions in the
> > pipe are killed.
> > 
> > /gmu
> > 
> > On Thu, 2003-12-18 at 22:01, karthikeyan natarajan
> > wrote:
> > > Hi All,
> > > 
> > >     If this is not a right forum to ask this
> > Question,
> > > 
> > > please redirect me to the appropriate one...
> > >     Since R4000 is using the 8 stage pipeline,
> > three
> > > instructions are already entered into the pipeline
> > > when the branch instruction is executed. Out of
> > these
> > > three instructions, the first instruction will be 
> > > executed for sure.
> > > 
> > > My question is:
> > >     What happens to the other two instruction that
> > are
> > > in the delay slots? are they nullified?
> > >     Could anyone please shed some light on this.
> > > 
> > > Thanks much,
> > > -karthi
> > > 
> > > =====
> > > The expert at anything was once a beginner
> > > 
> > >
> >
> ________________________________________________________________________
> > > Yahoo! Messenger - Communicate instantly..."Ping" 
> > > your friends today! Download Messenger Now 
> > > http://uk.messenger.yahoo.com/download/index.html
> > > 
> > -- 
> > Michael Uhler, Chief Technology Officer
> > MIPS Technologies, Inc.  Email: uhler@mips.com 
> > Pager: uhler_p@mips.com
> > 1225 Charleston Road     Voice:  (650)567-5025  FAX:
> >   (650)567-5225
> > Mountain View, CA 94043  Mobile: (650)868-6870 
> > Admin: (650)567-5085
> > 
> >  
> 
> =====
> The expert at anything was once a beginner
> 
> ________________________________________________________________________
> Yahoo! Messenger - Communicate instantly..."Ping" 
> your friends today! Download Messenger Now 
> http://uk.messenger.yahoo.com/download/index.html
> 
> 

Re: Regarding branch delay instructions in R4000

[Maciej W. Rozycki]

On Sat, 20 Dec 2003, Kevin D. Kissell wrote:

> Yes, MIPS stood for Microprocessor without Interlocked Pipeline Stages
> when it was first used as a name for a graduate student project at Stanford
> University in publications from 1982.  But that in itself was a play on words,
> as the most common metric of computer perfomance at the time was 
> "Millions of Instructions Per Second", or MIPS.  The Stanford architcture 
> was revamped and commercialized as the "MIPS I" architecture, implemented 
> in the R2000 and R3000 CPUs, which likewise had no interlocks on cache load 
> delays. As silicon geometries became finer and gates got cheaper, the relative cost
> of providing the interlocks decreased, while the need to run the same MIPS 
> binaries on multiple, very different implementations of the architecture increased.
> So from the R4000 onwards, MIPS CPUs have had interlocks.  But by that time
> the name "MIPS" was a well-known trademark, and it made no sense to change it.

 Well, as I like to nitpick, actually the original MIPS I R2000 and R3000
processors did have a single interlock already -- the one used for reading
the HI and LO registers. ;-)

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Regarding the LL & SC instructions

[karthikeyan natarajan]

Hi All,

    Seems that LL & SC instrutions operate on a 'word'
data.
    Can we use the same instructions to do a atomic
increment on a 'byte' data. If not, are there any
specific instructions to operate on a byte data?
(Like, LLD & SCD for doubleword data) or else, any 
method to achieve this using the LL & SC instr?

Thanks much,
-karthi


=====
The expert at anything was once a beginner

________________________________________________________________________
Yahoo! Messenger - Communicate instantly..."Ping" 
your friends today! Download Messenger Now 
http://uk.messenger.yahoo.com/download/index.html

Re: Regarding the LL & SC instructions

[Kevin D. Kissell]

You can modify any, all, or none of the bytes in a word loaded/stored
with LL/SC.  What you *can't* do is independently  LL/SC individual 
bytes within the same memory word, but operationally, this is of little
consequence.  If you want to atomically modify a byte, you LL the word
containing the byte, modify the byte in question, and SC the word.
If the SC succeeds, all is as you wish.  If the SC fails, you need to
retry the whole sequence.

----- Original Message ----- 
From: "karthikeyan natarajan" <karthik_96cse@yahoo.com>
To: <linux-mips@linux-mips.org>
Sent: Sunday, January 04, 2004 10:09
Subject: Regarding the LL & SC instructions


> Hi All,
> 
>     Seems that LL & SC instrutions operate on a 'word'
> data.
>     Can we use the same instructions to do a atomic
> increment on a 'byte' data. If not, are there any
> specific instructions to operate on a byte data?
> (Like, LLD & SCD for doubleword data) or else, any 
> method to achieve this using the LL & SC instr?
> 
> Thanks much,
> -karthi
> 
> 
> =====
> The expert at anything was once a beginner
> 
> ________________________________________________________________________
> Yahoo! Messenger - Communicate instantly..."Ping" 
> your friends today! Download Messenger Now 
> http://uk.messenger.yahoo.com/download/index.html
> 
> 

Re: Regarding the LL & SC instructions

[Kevin D. Kissell]

You can modify any, all, or none of the bytes in a word loaded/stored
with LL/SC.  What you *can't* do is independently  LL/SC individual 
bytes within the same memory word, but operationally, this is of little
consequence.  If you want to atomically modify a byte, you LL the word
containing the byte, modify the byte in question, and SC the word.
If the SC succeeds, all is as you wish.  If the SC fails, you need to
retry the whole sequence.

----- Original Message ----- 
From: "karthikeyan natarajan" <karthik_96cse@yahoo.com>
To: <linux-mips@linux-mips.org>
Sent: Sunday, January 04, 2004 10:09
Subject: Regarding the LL & SC instructions


> Hi All,
> 
>     Seems that LL & SC instrutions operate on a 'word'
> data.
>     Can we use the same instructions to do a atomic
> increment on a 'byte' data. If not, are there any
> specific instructions to operate on a byte data?
> (Like, LLD & SCD for doubleword data) or else, any 
> method to achieve this using the LL & SC instr?
> 
> Thanks much,
> -karthi
> 
> 
> =====
> The expert at anything was once a beginner
> 
> ________________________________________________________________________
> Yahoo! Messenger - Communicate instantly..."Ping" 
> your friends today! Download Messenger Now 
> http://uk.messenger.yahoo.com/download/index.html
> 
>