instruction order

[wit-3]

Hi all,


I see some codes having reverse order in head.S assembly:

        l.addi  r6,r0,0
        l.addi  r5,r0,IC_SIZE
1:
        l.mtspr r0,r6,SPR_ICBIR
        l.sfne  r6,r5
        l.bf    1b
        l.addi  r6,r6,IC_LINE

        /* Enable IC */
        l.mfspr r6,r0,SPR_SR
        l.ori   r6,r6,SPR_SR_ICE
        l.mtspr r0,r6,SPR_SR
        l.nop
        l.nop
        l.nop
        l.nop

If the code runs sequentially, there would be an dead loop at:
1:
        l.mtspr r0,r6,SPR_ICBIR
        l.sfne  r6,r5
        l.bf    1b
        l.addi  r6,r6,IC_LINE

So I guess "l.addi  r6,r6,IC_LINE" will be executed before "l.bf 1b". (I
also see jumping instructions followed with a l.nop, so looks like all
instructions immediately follows a jumping instruction would executed
before the jumping instruction).
The manual says all branching and jumping instructions will be put into
delay slot. I guess this is how delay slot works. But guess is just
guess. Could anyone explain how delay slot works to me and tell me why
those instructions are in reversed order?


Best Regards,
--Zhanhua


_______________________________________________
http://www.opencores.org/mailman/listinfo/openrisc

[Fabrizio Fazzino]

Zhanhua Kuang wrote:
>
> The manual says all branching and jumping instructions will be put into
> delay slot. I guess this is how delay slot works. But guess is just
> guess. Could anyone explain how delay slot works to me and tell me why
> those instructions are in reversed order?

http://en.wikipedia.org/wiki/Branch_delay_slot

_______________________________________________
http://www.opencores.org/mailman/listinfo/openrisc

[Jeremy Bennett-4]

On Tue, 2009-02-24 at 19:32 +0800, Zhanhua Kuang wrote:

> Hi all,
>
>
> I see some codes having reverse order in head.S assembly:
>
>         l.addi  r6,r0,0
>         l.addi  r5,r0,IC_SIZE
> 1:
> l.mtspr r0,r6,SPR_ICBIR
>         l.sfne  r6,r5
> l.bf    1b
>         l.addi  r6,r6,IC_LINE
>
>         /* Enable IC */
>         l.mfspr r6,r0,SPR_SR
>         l.ori   r6,r6,SPR_SR_ICE
>         l.mtspr r0,r6,SPR_SR
>         l.nop
>         l.nop
>         l.nop
>         l.nop
>
> If the code runs sequentially, there would be an dead loop at:
> 1:
> l.mtspr r0,r6,SPR_ICBIR
>         l.sfne  r6,r5
> l.bf    1b
>         l.addi  r6,r6,IC_LINE
>
> So I guess "l.addi  r6,r6,IC_LINE" will be executed before "l.bf 1b". (I
> also see jumping instructions followed with a l.nop, so looks like all
> instructions immediately follows a jumping instruction would executed
> before the jumping instruction).
> The manual says all branching and jumping instructions will be put into
> delay slot. I guess this is how delay slot works. But guess is just
> guess. Could anyone explain how delay slot works to me and tell me why
> those instructions are in reversed order?

Hi Zhanhua,

You are correct. OpenRISC implements delayed branching. The branch is
taken one cycle after it is specified. So the instruction immediately
after the branch instruction will be executed before there is a change
of program counter.

The reason is that branch targets are computed fairly late in the
instruction evaluation. By delaying the branch, you can have a much
tighter pipeline.

The first architecture I am aware of with this feature was the original
RISC-1 in 1982. It became common in subsequent RISC architectures as
pipelines got longer. More recently pipelines have become much shorter,
and there has been a move away from delayed branches.

Compilers can generally make good use of the delay slot. I recall some
data from RISC-1 that reckoned only about 8% of the slots had to use a
NOP, and that with further optimization they thought they could get that
down to 3%.

The original RISC papers from 1980 and 1982 (Patterson and Ditzel,
Patterson and Sequin) are well worth reading for more insight into this.

HTH,


Jeremy

--
Tel:      [phone]
Cell:     [phone]
SkypeID: jeremybennett
Email:   jeremy.bennett@...
Web:     www.embecosm.com


_______________________________________________
http://www.opencores.org/mailman/listinfo/openrisc

[wit-3]

Fabrizio Fazzino wrote:
> Zhanhua Kuang wrote:
>>
>> The manual says all branching and jumping instructions will be put into
>> delay slot. I guess this is how delay slot works. But guess is just
>> guess. Could anyone explain how delay slot works to me and tell me why
>> those instructions are in reversed order?
>
> http://en.wikipedia.org/wiki/Branch_delay_slot
>
Thanks Fabrizio, this is really helpful.
> _______________________________________________
> http://www.opencores.org/mailman/listinfo/openrisc
>

_______________________________________________
http://www.opencores.org/mailman/listinfo/openrisc

[wit-3]

Hi Jeremy,

It's nice you to share some background knowledge.
So is this has been taken care by the current or32 tool train?


Jeremy Bennett wrote:

> On Tue, 2009-02-24 at 19:32 +0800, Zhanhua Kuang wrote:
>  
>> Hi all,
>>
>>
>> I see some codes having reverse order in head.S assembly:
>>
>>         l.addi  r6,r0,0
>>         l.addi  r5,r0,IC_SIZE
>> 1:
>> l.mtspr r0,r6,SPR_ICBIR
>>         l.sfne  r6,r5
>> l.bf    1b
>>         l.addi  r6,r6,IC_LINE
>>
>>         /* Enable IC */
>>         l.mfspr r6,r0,SPR_SR
>>         l.ori   r6,r6,SPR_SR_ICE
>>         l.mtspr r0,r6,SPR_SR
>>         l.nop
>>         l.nop
>>         l.nop
>>         l.nop
>>
>> If the code runs sequentially, there would be an dead loop at:
>> 1:
>> l.mtspr r0,r6,SPR_ICBIR
>>         l.sfne  r6,r5
>> l.bf    1b
>>         l.addi  r6,r6,IC_LINE
>>
>> So I guess "l.addi  r6,r6,IC_LINE" will be executed before "l.bf 1b". (I
>> also see jumping instructions followed with a l.nop, so looks like all
>> instructions immediately follows a jumping instruction would executed
>> before the jumping instruction).
>> The manual says all branching and jumping instructions will be put into
>> delay slot. I guess this is how delay slot works. But guess is just
>> guess. Could anyone explain how delay slot works to me and tell me why
>> those instructions are in reversed order?
>>    
>
> Hi Zhanhua,
>
> You are correct. OpenRISC implements delayed branching. The branch is
> taken one cycle after it is specified. So the instruction immediately
> after the branch instruction will be executed before there is a change
> of program counter.
>
> The reason is that branch targets are computed fairly late in the
> instruction evaluation. By delaying the branch, you can have a much
> tighter pipeline.
>
> The first architecture I am aware of with this feature was the original
> RISC-1 in 1982. It became common in subsequent RISC architectures as
> pipelines got longer. More recently pipelines have become much shorter,
> and there has been a move away from delayed branches.
>
> Compilers can generally make good use of the delay slot. I recall some
> data from RISC-1 that reckoned only about 8% of the slots had to use a
> NOP, and that with further optimization they thought they could get that
> down to 3%.
>
> The original RISC papers from 1980 and 1982 (Patterson and Ditzel,
> Patterson and Sequin) are well worth reading for more insight into this.
>
> HTH,
>
>
> Jeremy
>
>  

_______________________________________________
http://www.opencores.org/mailman/listinfo/openrisc

[Jeremy Bennett-4]

On Wed, 2009-02-25 at 22:47 +0800, Zhanhua wrote:
> Hi Jeremy,
>
> It's nice you to share some background knowledge.
> So is this has been taken care by the current or32 tool train?

Hi Zhanhua,

Yes - all taken care of.


Jeremy

--
Tel:      [phone]
Cell:     [phone]
SkypeID: jeremybennett
Email:   jeremy.bennett@...
Web:     www.embecosm.com


_______________________________________________
http://www.opencores.org/mailman/listinfo/openrisc

[rich_daddio]

Hi Zhanhua,
For the most part this is taken care of in the current toolchain, but
could be optimized I am sure.

At a bare minimum this must be "taken care of" with nops since bad
things can happen otherwise as you can imagine.

BR,

Rich d

----- Original Message -----
From: Zhanhua<is01kzh@g...>
To:
Date: Wed Feb 25 15:47:47 CET 2009
Subject: [openrisc] instruction order

> Hi Jeremy,
>
> It's nice you to share some background knowledge.
> So is this has been taken care by the current or32 tool train?
> Jeremy Bennett wrote:
> > On Tue, 2009-02-24 at 19:32 +0800, Zhanhua Kuang wrote:
> >
> >> Hi all,
> >>
> >>
> >> I see some codes having reverse order in head.S assembly:
> >>
> >> l.addi r6,r0,0
> >> l.addi r5,r0,IC_SIZE
> >> 1:
> >> l.mtspr r0,r6,SPR_ICBIR
> >> l.sfne r6,r5
> >> l.bf 1b
> >> l.addi r6,r6,IC_LINE
> >>
> >> /* Enable IC */
> >> l.mfspr r6,r0,SPR_SR
> >> l.ori r6,r6,SPR_SR_ICE
> >> l.mtspr r0,r6,SPR_SR
> >> l.nop
> >> l.nop
> >> l.nop
> >> l.nop
> >>
> >> If the code runs sequentially, there would be an dead loop
> at:
> >> 1:
> >> l.mtspr r0,r6,SPR_ICBIR
> >> l.sfne r6,r5
> >> l.bf 1b
> >> l.addi r6,r6,IC_LINE
> >>
> >> So I guess "l.addi r6,r6,IC_LINE" will be
> executed before "l.bf 1b". (I
> >> also see jumping instructions followed with a l.nop, so
> looks like all
> >> instructions immediately follows a jumping instruction
> would executed
> >> before the jumping instruction).
> >> The manual says all branching and jumping instructions
> will be put into
> >> delay slot. I guess this is how delay slot works. But
> guess is just
> >> guess. Could anyone explain how delay slot works to me and
> tell me why
> >> those instructions are in reversed order?
> >>
> >
> > Hi Zhanhua,
> >
> > You are correct. OpenRISC implements delayed branching. The
> branch is
> > taken one cycle after it is specified. So the instruction
> immediately
> > after the branch instruction will be executed before there is
> a change
> > of program counter.
> >
> > The reason is that branch targets are computed fairly late in
> the
> > instruction evaluation. By delaying the branch, you can have a
> much
> > tighter pipeline.
> >
> > The first architecture I am aware of with this feature was the
> original
> > RISC-1 in 1982. It became common in subsequent RISC
> architectures as
> > pipelines got longer. More recently pipelines have become much
> shorter,
> > and there has been a move away from delayed branches.
> >
> > Compilers can generally make good use of the delay slot. I
> recall some
> > data from RISC-1 that reckoned only about 8% of the slots had
> to use a
> > NOP, and that with further optimization they thought they
> could get that
> > down to 3%.
> >
> > The original RISC papers from 1980 and 1982 (Patterson and
> Ditzel,
> > Patterson and Sequin) are well worth reading for more insight
> into this.
> >
> > HTH,
> >
> >
> > Jeremy
> >
> >
>
>

_______________________________________________
http://www.opencores.org/mailman/listinfo/openrisc

[wit-3]

Thanks every one.


On Wed, 2009-02-25 at 19:53 +0100, rich_daddio@... wrote:

> Hi Zhanhua,
> For the most part this is taken care of in the current toolchain, but
> could be optimized I am sure.
>
> At a bare minimum this must be "taken care of" with nops since bad
> things can happen otherwise as you can imagine.
>
> BR,
>
> Rich d
>
> ----- Original Message -----
> From: Zhanhua<is01kzh@g...>
> To:
> Date: Wed Feb 25 15:47:47 CET 2009
> Subject: [openrisc] instruction order
>
> > Hi Jeremy,
> >
> > It's nice you to share some background knowledge.
> > So is this has been taken care by the current or32 tool train?
> > Jeremy Bennett wrote:
> > > On Tue, 2009-02-24 at 19:32 +0800, Zhanhua Kuang wrote:
> > >
> > >> Hi all,
> > >>
> > >>
> > >> I see some codes having reverse order in head.S assembly:
> > >>
> > >> l.addi r6,r0,0
> > >> l.addi r5,r0,IC_SIZE
> > >> 1:
> > >> l.mtspr r0,r6,SPR_ICBIR
> > >> l.sfne r6,r5
> > >> l.bf 1b
> > >> l.addi r6,r6,IC_LINE
> > >>
> > >> /* Enable IC */
> > >> l.mfspr r6,r0,SPR_SR
> > >> l.ori r6,r6,SPR_SR_ICE
> > >> l.mtspr r0,r6,SPR_SR
> > >> l.nop
> > >> l.nop
> > >> l.nop
> > >> l.nop
> > >>
> > >> If the code runs sequentially, there would be an dead loop
> > at:
> > >> 1:
> > >> l.mtspr r0,r6,SPR_ICBIR
> > >> l.sfne r6,r5
> > >> l.bf 1b
> > >> l.addi r6,r6,IC_LINE
> > >>
> > >> So I guess "l.addi r6,r6,IC_LINE" will be
> > executed before "l.bf 1b". (I
> > >> also see jumping instructions followed with a l.nop, so
> > looks like all
> > >> instructions immediately follows a jumping instruction
> > would executed
> > >> before the jumping instruction).
> > >> The manual says all branching and jumping instructions
> > will be put into
> > >> delay slot. I guess this is how delay slot works. But
> > guess is just
> > >> guess. Could anyone explain how delay slot works to me and
> > tell me why
> > >> those instructions are in reversed order?
> > >>
> > >
> > > Hi Zhanhua,
> > >
> > > You are correct. OpenRISC implements delayed branching. The
> > branch is
> > > taken one cycle after it is specified. So the instruction
> > immediately
> > > after the branch instruction will be executed before there is
> > a change
> > > of program counter.
> > >
> > > The reason is that branch targets are computed fairly late in
> > the
> > > instruction evaluation. By delaying the branch, you can have a
> > much
> > > tighter pipeline.
> > >
> > > The first architecture I am aware of with this feature was the
> > original
> > > RISC-1 in 1982. It became common in subsequent RISC
> > architectures as
> > > pipelines got longer. More recently pipelines have become much
> > shorter,
> > > and there has been a move away from delayed branches.
> > >
> > > Compilers can generally make good use of the delay slot. I
> > recall some
> > > data from RISC-1 that reckoned only about 8% of the slots had
> > to use a
> > > NOP, and that with further optimization they thought they
> > could get that
> > > down to 3%.
> > >
> > > The original RISC papers from 1980 and 1982 (Patterson and
> > Ditzel,
> > > Patterson and Sequin) are well worth reading for more insight
> > into this.
> > >
> > > HTH,
> > >
> > >
> > > Jeremy
> > >
> > >
> >
> >
> _______________________________________________
> http://www.opencores.org/mailman/listinfo/openrisc

_______________________________________________
http://www.opencores.org/mailman/listinfo/openrisc