Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

MIPS 74K and execution hazards

14 views
Skip to first unread message

Gregory T. Andersen

unread,
Sep 22, 2010, 12:29:09 PM9/22/10
to
Has anyone done any work for MIPS 74K CPUs (mips32r2)? We have run into
an issue where it seems a lot of the low level code (mipsX_subr.S,
locore.S) does not have support for MIPS execution hazards. The big
offenders seem to be the TLB/CP0 instructions (tlbp, tlbw, mtc0, mfc0,
etc..).

Rather than use nop slots after instructions MIPS32 requires use of
ssnop (mips32r1) or ehb (mips32r2) instructions to guarantee clearing of
execution hazards in MIPS superscaler designs.

We have a heavy handed solution in place to get the kernel booting but
were curious if anyone had implemented a more elegant/tested solution?

Greg Andersen
Cradlepoint Technology


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-...@muc.de

Matt Thomas

unread,
Sep 22, 2010, 2:23:05 PM9/22/10
to

On Sep 22, 2010, at 9:29 AM, Gregory T. Andersen wrote:

> Has anyone done any work for MIPS 74K CPUs (mips32r2)? We have run into an issue where it seems a lot of the low level code (mipsX_subr.S, locore.S) does not have support for MIPS execution hazards. The big offenders seem to be the TLB/CP0 instructions (tlbp, tlbw, mtc0, mfc0, etc..).

I'd love to have to a mipsXXr2 to play with to actually make the r2 features work.

> Rather than use nop slots after instructions MIPS32 requires use of ssnop (mips32r1) or ehb (mips32r2) instructions to guarantee clearing of execution hazards in MIPS superscaler designs.

I find the COP0_SYNC stuff to be horrible. I've been planning on making adding mips32r2_subr.S and mips64r2_subr.S so I can use those features. But locore is more difficult since it's not CPU specific.

> We have a heavy handed solution in place to get the kernel booting but were curious if anyone had implemented a more elegant/tested solution?

If have a few ideas in mind but haven't done anything with it due to lack of anything to test on.

Gregory T. Andersen

unread,
Sep 22, 2010, 4:47:14 PM9/22/10
to
> I find the COP0_SYNC stuff to be horrible.
Horrible yes and in some cases on a 74K it is insufficient to define
COP0_SYNC as 'ehb' because there are hazards which don't have a
interceding COP0_SYNC instructions.

On 09/22/2010 12:23 PM, Matt Thomas wrote:
>
> On Sep 22, 2010, at 9:29 AM, Gregory T. Andersen wrote:
>

>> Has anyone done any work for MIPS 74K CPUs (mips32r2)? We have run into an issue where it seems a lot of the low level code (mipsX_subr.S, locore.S) does not have support for MIPS execution hazards. The big offenders seem to be the TLB/CP0 instructions (tlbp, tlbw, mtc0, mfc0, etc..).
>

> I'd love to have to a mipsXXr2 to play with to actually make the r2 features work.
>

>> Rather than use nop slots after instructions MIPS32 requires use of ssnop (mips32r1) or ehb (mips32r2) instructions to guarantee clearing of execution hazards in MIPS superscaler designs.
>

> I find the COP0_SYNC stuff to be horrible. I've been planning on making adding mips32r2_subr.S and mips64r2_subr.S so I can use those features. But locore is more difficult since it's not CPU specific.
>

>> We have a heavy handed solution in place to get the kernel booting but were curious if anyone had implemented a more elegant/tested solution?
>

> If have a few ideas in mind but haven't done anything with it due to lack of anything to test on.
>
>
>

--

0 new messages