Hi folks, specifically ARM folks. I'm trying to figure out what's going on
with this in the minor CPU:

#if THE_ISA == X86_ISA || THE_ISA == ARM_ISA
                    /* In SE mode, it's possible to branch to a microop when
                     *  replaying faults such as page faults (or simply
                     *  intra-microcode branches in X86).  Unfortunately,
                     *  as Minor has micro-op decomposition in a separate
                     *  pipeline stage from instruction decomposition, the
                     *  following advancePC (which may follow a branch with
                     *  microPC() != 0) *must* see a fresh macroop.  This
                     *  kludge should be improved with an addition to
PCState
                     *  but I offer it in this form for the moment
                     *
                     * X86 can branch within microops so we need to deal
with
                     * the case that, after a branch, the first un-advanced
PC
                     * may be pointing to a microop other than 0.  Once
                     * advanced, however, the microop number *must* be 0 */
                    fetch_info.pc.upc(0);
                    fetch_info.pc.nupc(1);
#endif


This seems very strange, but removing it does in fact make the minor CPU
stop working for at least the ARM BubbleSort regression test.

Can anyone explain what's going on here? This code sprang into existence
with this #if in it, so there's no history, reviews, etc, that give any
clue why this self professed kludge is necessary. It was checked in with
this change:

commit 0e8a90f06bd3db00f700891a33458353478cce76
Author: Andrew Bardsley <andrew.bards...@arm.com>
Date:   Wed Jul 23 16:09:04 2014 -0500

    cpu: `Minor' in-order CPU model

There's some fairly hefty documentation now on the website which I'll look
through which I imagine might help, but I think there's a disconnect
between this code and how the PCState class is supposed to be used...

Gabe
_______________________________________________
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

Reply via email to