[gem5-dev] Change in gem5/gem5[develop]: util: Fix checkpoint-tester.py checkpoint parameter
Hoa Nguyen has submitted this change. (
https://gem5-review.googlesource.com/c/public/gem5/+/9 )
Change subject: util: Fix checkpoint-tester.py checkpoint parameter
..
util: Fix checkpoint-tester.py checkpoint parameter
checkpoint-tester script tests gem5's checkpoints by
using gem5 to produce a series of checkpoints, each with
a specified interval. After that, for all K > 1,
each of K-th produced checkpoint is used by gem5 to produce
the {K+1}-th checkpoint. The newly produced checkpoint will
be compared against the {K+1}-th checkpoint that was
previously produced.
Previously, in the tester script, the inputs to
`--take-checkpoints X,Y` was `(interval, interval)`.
The intention was to restore the N-th checkpoint and to run
the simulation for `interval` ticks.
According to the current configs/common/Options.py file,
`--take-checkpoints X,Y` means `X` is the starting tick of
the simulation, while `Y` is the number of ticks to be simulated
after tick `X`.
Therefore, `X` should be the starting tick of the N-th checkpont,
and this change addresses this problem.
Change-Id: I1fd7c91c9454f42a4fb98aa878fb5e4ac7d238f3
Signed-off-by: Hoa Nguyen
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/9
Reviewed-by: Jason Lowe-Power
Reviewed-by: Daniel Carvalho
Maintainer: Jason Lowe-Power
Tested-by: kokoro
---
M util/checkpoint-tester.py
1 file changed, 8 insertions(+), 7 deletions(-)
Approvals:
Jason Lowe-Power: Looks good to me, approved; Looks good to me, approved
Daniel Carvalho: Looks good to me, approved
kokoro: Regressions pass
diff --git a/util/checkpoint-tester.py b/util/checkpoint-tester.py
index 2600644..5817469 100755
--- a/util/checkpoint-tester.py
+++ b/util/checkpoint-tester.py
@@ -55,12 +55,12 @@
#
# Examples:
#
-# util/checkpoint-tester.py -i 40 -- build//m5.opt \
-# configs/example/se.py -c
tests/test-progs/hello/bin//tru64/hello \
+# util/checkpoint-tester.py -i 40 -- build//gem5.opt \
+# configs/example/se.py -c
tests/test-progs/hello/bin//linux/hello \
# --output=progout --errout=progerr
#
-# util/checkpoint-tester.py -i 2000 -- build//m5.opt \
-# configs/example/fs.py --script tests/halt.sh
+# util/checkpoint-tester.py -i 2000 -- build//gem5.opt \
+# configs/example/fs.py --script configs/boot/halt.sh
#
@@ -94,12 +94,12 @@
args = args.cmdline[1:]
-initial_args = ['--take-checkpoints', '%d,%d' % (interval, interval)]
+checkpoint_args = ['--take-checkpoints', '%d,%d' % (interval, interval)]
cptdir = os.path.join(top_dir, 'm5out')
print('===> Running initial simulation.')
-subprocess.call([m5_binary] + ['-red', cptdir] + args + initial_args)
+subprocess.call([m5_binary] + ['-red', cptdir] + args + checkpoint_args)
dirs = os.listdir(cptdir)
expr = re.compile('cpt\.([0-9]*)')
@@ -117,8 +117,9 @@
# less than tha number of checkpoints.
for i in range(1, len(cpts)):
print('===> Running test %d of %d.' % (i, len(cpts)-1))
+checkpoint_args = ['--take-checkpoints', '%d,%d' % (cpts[i], interval)]
mydir = os.path.join(top_dir, 'test.%d' % i)
-subprocess.call([m5_binary] + ['-red', mydir] + args + initial_args +
+subprocess.call([m5_binary] + ['-red', mydir] + args + checkpoint_args
+
['--max-checkpoints' , '1', '--checkpoint-dir', cptdir,
'--checkpoint-restore', str(i)])
cpt_name = 'cpt.%d' % cpts[i]
--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/9
To unsubscribe, or for help writing mail filters, visit
https://gem5-review.googlesource.com/settings
Gerrit-Project: public/gem5
Gerrit-Branch: develop
Gerrit-Change-Id: I1fd7c91c9454f42a4fb98aa878fb5e4ac7d238f3
Gerrit-Change-Number: 9
Gerrit-PatchSet: 4
Gerrit-Owner: Hoa Nguyen
Gerrit-Reviewer: Daniel Carvalho
Gerrit-Reviewer: Gabe Black
Gerrit-Reviewer: Hoa Nguyen
Gerrit-Reviewer: Jason Lowe-Power
Gerrit-Reviewer: kokoro
Gerrit-MessageType: merged
___
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
[gem5-dev] Change in gem5/gem5[develop]: arch-sparc: Fix the SPARC build.
Gabe Black has submitted this change. ( https://gem5-review.googlesource.com/c/public/gem5/+/45065 ) Change subject: arch-sparc: Fix the SPARC build. .. arch-sparc: Fix the SPARC build. Change-Id: I233d32f67fc4e5e9f88c3bc95f9f8614543b2885 Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/45065 Reviewed-by: Boris Shingarov Maintainer: Gabe Black Tested-by: kokoro --- M src/arch/sparc/pseudo_inst_abi.hh 1 file changed, 2 insertions(+), 1 deletion(-) Approvals: Boris Shingarov: Looks good to me, approved Gabe Black: Looks good to me, approved kokoro: Regressions pass diff --git a/src/arch/sparc/pseudo_inst_abi.hh b/src/arch/sparc/pseudo_inst_abi.hh index 446043a..95bc460 100644 --- a/src/arch/sparc/pseudo_inst_abi.hh +++ b/src/arch/sparc/pseudo_inst_abi.hh @@ -28,7 +28,8 @@ #ifndef __ARCH_SPARC_PSEUDO_INST_ABI_HH__ #define __ARCH_SPARC_PSEUDO_INST_ABI_HH__ -#include "arch/sparc/registers.hh" +#include "arch/sparc/regs/int.hh" +#include "cpu/thread_context.hh" #include "sim/guest_abi.hh" struct SparcPseudoInstABI -- To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/45065 To unsubscribe, or for help writing mail filters, visit https://gem5-review.googlesource.com/settings Gerrit-Project: public/gem5 Gerrit-Branch: develop Gerrit-Change-Id: I233d32f67fc4e5e9f88c3bc95f9f8614543b2885 Gerrit-Change-Number: 45065 Gerrit-PatchSet: 2 Gerrit-Owner: Gabe Black Gerrit-Reviewer: Bobby R. Bruce Gerrit-Reviewer: Boris Shingarov Gerrit-Reviewer: Gabe Black Gerrit-Reviewer: Giacomo Travaglini Gerrit-Reviewer: kokoro Gerrit-MessageType: merged ___ 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
[gem5-dev] Re: gem5 namespace
Hey Daniel, Sorry, I didn't mean to add to the confusion :). I may have gotten my case names confused! Also, I really appreciate the thoughtfulness and effort you're putting into this conversation! I believe I agree with your email below. I think that most people don't care that much (which is why we haven't heard from many). From my experience, our users only care when they get merge conflicts :D. That said, I'm not sure if "straightforward" is a way most of our users ever feel about merge conflicts. IMO, stability and ease of update should be high priority. If we are going to be changing names, etc. in a way that means external users of gem5 will have compiler errors, we should probably provide backwards compatibility and warnings. Most of our users are not software engineers and do not have as much experience with git, compilers, etc. as we do. Cheers, Jason On Mon, May 3, 2021 at 12:40 PM Daniel Carvalho via gem5-dev < gem5-dev@gem5.org> wrote: > I'm confused, Jason. I thought you were in favor of adopting snake case as > a "general convention" (i.e., "the google way"), so by adopting snake case > we would be adopting the "general convention", not forging our own path. > However, if by "general convention" you mean "the convention vastly adopted > by gem5", I don't have the exact numbers, but I'd guess it is 70% pascal, > 30% snake case - i.e., IMHO, not a "general convention", just a preference. > Adding "gem5" or "Gem5" would only extend this mess, not add an exception. > > Regarding changing the name of the variable, indeed, it is not a necessary > step. > > Again, as stated before, I don't care which solution is taken. The > important thing is to come to a decision that appeases most community > members; however, it is hard to reach a consensus when we seem to have > strong opinions on both sides, yet we only have 5 votes. That is why I have > suggested officially adopting snake case namespaces: it would solve the > "gem5 VS Gem5" problem, it is feasible to do it without having exceptions > (at least as of now), Giacomo expressed preference towards lowercase > namespaces, Jason suggested affinity with the google approach (snake case) > and "gem5", Bobby prefers "gem5", and Gabe and I like consistency/patterns. > The (huge) downside to this solution is that it would affect users, but 1) > we'd already be affecting users anyway with the new namespace, and 2) > solving the merge conflicts would be straightforward if the patches were > created with that in mind. > > Regards, > Daniel > Em segunda-feira, 3 de maio de 2021 15:44:46 BRT, Jason Lowe-Power < > ja...@lowepower.com> escreveu: > > > Just a few quick replies below. Overall, I think we're being too focused > on "standards" and not on enough on ease of use. It's not a problem if > there are exceptions to guidance, if there's good reasons for the > exceptions. > > > On Mon, May 3, 2021 at 11:36 AM Daniel Carvalho via gem5-dev < > gem5-dev@gem5.org> wrote: > > As mentioned by Gabe in the Jira issue, some of the namespaces using snake > declared in the codebase case are defined as parts of a standard, and thus > cannot be modified. Realistically, this means that if we wanted to follow a > namespace naming convention, it'd be snake case: despite having way more > occurrences of pascal case namespaces, they are all "ours"; this means > that, although inconvenient, it would be doable to standardize all of them. > > > If we just say "all namespaces should be PascalCase. gem5, the name of > this project, is an exception" would be OK with me. > > > Would you be willing to adopt to enforce a snake case namespace naming > convention? From the previous replies to this thread, it seems that this > solution would appease most - if not all - participants. > > > I really don't think this is too important. I would definitely prefer to > follow the *general* conventions rather than forging our own path. > > > > For this change to take place, we need to (not necessarily sorted): > 1) Rename the python variables named "gem5" in > src/systemc/tlm_bridge/TlmBridge.py (or remove them - I don't remember > finding where they are used); > > > Why does this need to be done? These are class names, not namespaces. > > > > 2) Add a section to our coding style mandating snake case for namespaces; > > 3) Change all existing namespaces to snake case; > > 4) Create a verifier to enforce this convention. > > 5) Rename/Move elements starting with gem5X/m5X as gem5::X > > > Finally, regarding macro names, we could improve the corresponding Jira > issue by listing all current macros so that we can start applying the > change and raise objections to particular instances. > > Cheers, > Daniel > > ___ > 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 > > ___ > gem5-dev mailing list --
[gem5-dev] Re: gem5 namespace
I'm confused, Jason. I thought you were in favor of adopting snake case as a "general convention" (i.e., "the google way"), so by adopting snake case we would be adopting the "general convention", not forging our own path. However, if by "general convention" you mean "the convention vastly adopted by gem5", I don't have the exact numbers, but I'd guess it is 70% pascal, 30% snake case - i.e., IMHO, not a "general convention", just a preference. Adding "gem5" or "Gem5" would only extend this mess, not add an exception. Regarding changing the name of the variable, indeed, it is not a necessary step. Again, as stated before, I don't care which solution is taken. The important thing is to come to a decision that appeases most community members; however, it is hard to reach a consensus when we seem to have strong opinions on both sides, yet we only have 5 votes. That is why I have suggested officially adopting snake case namespaces: it would solve the "gem5 VS Gem5" problem, it is feasible to do it without having exceptions (at least as of now), Giacomo expressed preference towards lowercase namespaces, Jason suggested affinity with the google approach (snake case) and "gem5", Bobby prefers "gem5", and Gabe and I like consistency/patterns. The (huge) downside to this solution is that it would affect users, but 1) we'd already be affecting users anyway with the new namespace, and 2) solving the merge conflicts would be straightforward if the patches were created with that in mind. Regards,Daniel Em segunda-feira, 3 de maio de 2021 15:44:46 BRT, Jason Lowe-Power escreveu: Just a few quick replies below. Overall, I think we're being too focused on "standards" and not on enough on ease of use. It's not a problem if there are exceptions to guidance, if there's good reasons for the exceptions. On Mon, May 3, 2021 at 11:36 AM Daniel Carvalho via gem5-dev wrote: As mentioned by Gabe in the Jira issue, some of the namespaces using snake declared in the codebase case are defined as parts of a standard, and thus cannot be modified. Realistically, this means that if we wanted to follow a namespace naming convention, it'd be snake case: despite having way more occurrences of pascal case namespaces, they are all "ours"; this means that, although inconvenient, it would be doable to standardize all of them. If we just say "all namespaces should be PascalCase. gem5, the name of this project, is an exception" would be OK with me. Would you be willing to adopt to enforce a snake case namespace naming convention? From the previous replies to this thread, it seems that this solution would appease most - if not all - participants. I really don't think this is too important. I would definitely prefer to follow the *general* conventions rather than forging our own path. For this change to take place, we need to (not necessarily sorted):1) Rename the python variables named "gem5" in src/systemc/tlm_bridge/TlmBridge.py (or remove them - I don't remember finding where they are used); Why does this need to be done? These are class names, not namespaces. 2) Add a section to our coding style mandating snake case for namespaces; 3) Change all existing namespaces to snake case; 4) Create a verifier to enforce this convention. 5) Rename/Move elements starting with gem5X/m5X as gem5::X Finally, regarding macro names, we could improve the corresponding Jira issue by listing all current macros so that we can start applying the change and raise objections to particular instances. Cheers,Daniel ___ 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 ___ 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
[gem5-dev] Re: gem5 namespace
Just a few quick replies below. Overall, I think we're being too focused on "standards" and not on enough on ease of use. It's not a problem if there are exceptions to guidance, if there's good reasons for the exceptions. On Mon, May 3, 2021 at 11:36 AM Daniel Carvalho via gem5-dev < gem5-dev@gem5.org> wrote: > As mentioned by Gabe in the Jira issue, some of the namespaces using snake > declared in the codebase case are defined as parts of a standard, and thus > cannot be modified. Realistically, this means that if we wanted to follow a > namespace naming convention, it'd be snake case: despite having way more > occurrences of pascal case namespaces, they are all "ours"; this means > that, although inconvenient, it would be doable to standardize all of them. > If we just say "all namespaces should be PascalCase. gem5, the name of this project, is an exception" would be OK with me. > Would you be willing to adopt to enforce a snake case namespace naming > convention? From the previous replies to this thread, it seems that this > solution would appease most - if not all - participants. > I really don't think this is too important. I would definitely prefer to follow the *general* conventions rather than forging our own path. > > For this change to take place, we need to (not necessarily sorted): > 1) Rename the python variables named "gem5" in > src/systemc/tlm_bridge/TlmBridge.py (or remove them - I don't remember > finding where they are used); > Why does this need to be done? These are class names, not namespaces. > 2) Add a section to our coding style mandating snake case for namespaces; > 3) Change all existing namespaces to snake case; > 4) Create a verifier to enforce this convention. > 5) Rename/Move elements starting with gem5X/m5X as gem5::X > > Finally, regarding macro names, we could improve the corresponding Jira > issue by listing all current macros so that we can start applying the > change and raise objections to particular instances. > > Cheers, > Daniel > ___ > 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 ___ 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
[gem5-dev] Re: gem5 namespace
As mentioned by Gabe in the Jira issue, some of the namespaces using snake declared in the codebase case are defined as parts of a standard, and thus cannot be modified. Realistically, this means that if we wanted to follow a namespace naming convention, it'd be snake case: despite having way more occurrences of pascal case namespaces, they are all "ours"; this means that, although inconvenient, it would be doable to standardize all of them. Would you be willing to adopt to enforce a snake case namespace naming convention? From the previous replies to this thread, it seems that this solution would appease most - if not all - participants. For this change to take place, we need to (not necessarily sorted):1) Rename the python variables named "gem5" in src/systemc/tlm_bridge/TlmBridge.py (or remove them - I don't remember finding where they are used);2) Add a section to our coding style mandating snake case for namespaces;3) Change all existing namespaces to snake case;4) Create a verifier to enforce this convention.5) Rename/Move elements starting with gem5X/m5X as gem5::X Finally, regarding macro names, we could improve the corresponding Jira issue by listing all current macros so that we can start applying the change and raise objections to particular instances. Cheers,Daniel ___ 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
[gem5-dev] Re: gem5 namespace
Hi all,
For the most part, we try to follow the Google C++ conventions. I don't
think these existed when gem5/m5 was started, but we follow them pretty
closely. For namespace names, see
https://google.github.io/styleguide/cppguide.html#Namespace_Names.
I quite strongly would like to see the namespace for gem5 be *all lower
case*. I'm looking at this purely from the point of view of a *new user*,
not a developer (which is what we should do! there are *way* more gem5
users than developers). If we make everyone always use Gem5:: in
their code, we will *never* be able to convince people to use the "gem5"
branding in papers, documentation, blog posts, etc. I believe that if we
make the *external* gem5 namespace a capital "G" we will be fundamentally
changing the gem5 branding.
We can have a conversation about changing the gem5 brand if we really want
to, but that isn't this conversation.
I am *strongly* against creating a namespace with a capital "G". This goes
against our branding, goes against common namespace naming practices (in
both the STL and Google's style), and it will confuse our users.
Jason
On Sun, May 2, 2021 at 4:23 PM Gabe Black via gem5-dev
wrote:
> Hi Daniel, just about the panic, fatal, etc, macros, that's a pretty
> sticky issue since those are so prevalent and are *nearly*
> functions, except annoyingly it's very hard to capture line/file
> information without using a macro. The way they are isn't ideal since they
> are macros with simple names, but changing them would be really painful and
> come with its own drawbacks. This is why I tried finding a way to make them
> not macros, and I *almost* was able to. I don't have a solution right now,
> but just wanted to point out that this is a bit trickier than, say,
> changing M5_UNUSED to GEM5_UNUSED.
>
> Gabe
>
> On Sun, May 2, 2021 at 2:46 PM Daniel Carvalho via gem5-dev <
> gem5-dev@gem5.org> wrote:
>
>> Hello, devs,
>>
>>
>> It's been over 2 weeks since the first mail, so I think it is safe to
>> assume nobody else will vote. We have reached 3 votes in favor of "gem5",
>> and 2 in favor of "Gem5". However, after going through the codebase and
>> thinking thoroughly, I have decided to change my vote to "Gem5". The vast
>> majority of namespaces in the codebase follow the PascalCase style, so it
>> be one more thing breaking consistency; classes, enums and others would
>> have to be renamed to enforce the lowercase rule, which would case even
>> more conflicts; and some functions and sections of the code would become
>> confusing due to the expected case of structures. Data for argumentation
>> have been uploaded to the respective Jira issue.
>>
>>
>> As changing my opinion means that the decision tips to the other
>> possibility, it would be fair to extend voting a couple more days to give
>> time for people to object, in case they were counting on the general census
>> matching theirs. The deadline to vote is on **Wednesday, April 5th**. After
>> that, the patches pending on this decision can resume.
>>
>>
>> Finally, just to make sure we are on the same page, because I forgot to
>> consider the function-like macros (fatal, panic, etc). the update for
>> macros would rename them as GEM5_MACRO_NAME, instead of keeping
>> GEM5_macro_name. That is, fatal -> GEM5_FATAL and so on.
>>
>>
>> Regards,
>>
>> Daniel
>>
>> I still favor namespace gem5 - it'd be the "external external" API, i.e.
>> we probably wouldn't be using it within src/ that much, and it would be
>> used by other simulators...
>>
>>
>> This is why I'm strongly in favor of lowercase gem5. When external
>> projects link to gem5 (which is *going* to happen), I think it's much
>> better to use the normative gem5 spelling. It would be very confusing for
>> people to use Gem5 in the code but gem5 in documentation/papers.
>>
>> ```
>> class MyExternalObj: public gem5::SimObject
>> {
>> };
>> ```
>>
>> Jason
>>
>>
>>
>> On Mon, Apr 19, 2021 at 6:40 AM Bobby Bruce via gem5-dev <
>> gem5-dev@gem5.org> wrote:
>>
>> Nothing gets software devs as engaged as when discussing naming
>> conventions :).
>>
>> I vote for "gem5" (lowercase) namespace, with all caps MACROS, but my
>> sole reason for this is I've grown to flinch whenever I see "Gem5", which I
>> admit isn't the best argument.
>>
>> I echo Daniel's comment that I care more about having a rule and moving
>> past this than what that rule should be.
>>
>> --
>> Dr. Bobby R. Bruce
>> Room 2235,
>> Kemper Hall, UC Davis
>> Davis,
>> CA, 95616
>>
>> web: https://www.bobbybruce.net
>>
>>
>> On Sun, Apr 18, 2021 at 3:44 PM Daniel Carvalho via gem5-dev <
>> gem5-dev@gem5.org> wrote:
>>
>> Overall, there are way more uses of "gem5" than "Gem5" in the codebase,
>> and most of the instances that break the identity rule could be easily
>> fixed; however, there are cases that generate inconvenience: classes
>> starting with lowercase, and situations where gem5 is in the middle of the
>> var name (like "haveGem5Extension") make the code
[gem5-dev] Change in gem5/gem5[develop]: arch-power: Refactor branch instructions
Boris Shingarov has submitted this change. (
https://gem5-review.googlesource.com/c/public/gem5/+/40886 )
Change subject: arch-power: Refactor branch instructions
..
arch-power: Refactor branch instructions
This changes the base classes for branch instructions and
switches to two high-level classes for unconditional and
conditional branches. The conditional branches are further
classified based on whether they use an immediate field or
a register for determining the target address.
Decoding has also been consolidated using formats that can
generate code after determining if an instruction branches
to an absolute address or a PC-relative address, or if it
implicitly sets the return address by looking at the AA and
LK bits.
Change-Id: I5fa7db7b6693586b4ea3c71e5cad8a60753de29c
Signed-off-by: Sandipan Das
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40886
Reviewed-by: Boris Shingarov
Maintainer: Gabe Black
Tested-by: kokoro
---
M src/arch/power/insts/branch.cc
M src/arch/power/insts/branch.hh
M src/arch/power/isa/decoder.isa
M src/arch/power/isa/formats/branch.isa
M src/arch/power/isa/formats/util.isa
M src/arch/power/types.hh
6 files changed, 224 insertions(+), 330 deletions(-)
Approvals:
Boris Shingarov: Looks good to me, approved
Gabe Black: Looks good to me, approved
kokoro: Regressions pass
diff --git a/src/arch/power/insts/branch.cc b/src/arch/power/insts/branch.cc
index 84834f1..1077f33 100644
--- a/src/arch/power/insts/branch.cc
+++ b/src/arch/power/insts/branch.cc
@@ -49,21 +49,30 @@
return *cachedDisassembly;
}
+
PowerISA::PCState
-BranchPCRel::branchTarget(const PowerISA::PCState ) const
+BranchOp::branchTarget(const PowerISA::PCState ) const
{
-return (uint32_t)(pc.pc() + disp);
+if (aa)
+return li;
+else
+return pc.pc() + li;
}
+
std::string
-BranchPCRel::generateDisassembly(
+BranchOp::generateDisassembly(
Addr pc, const Loader::SymbolTable *symtab) const
{
std::stringstream ss;
+Addr target;
ccprintf(ss, "%-10s ", mnemonic);
-Addr target = pc + disp;
+if (aa)
+target = li;
+else
+target = pc + li;
Loader::SymbolTable::const_iterator it;
if (symtab && (it = symtab->find(target)) != symtab->end())
@@ -74,46 +83,34 @@
return ss.str();
}
+
PowerISA::PCState
-BranchNonPCRel::branchTarget(const PowerISA::PCState ) const
+BranchDispCondOp::branchTarget(const PowerISA::PCState ) const
{
-return targetAddr;
+if (aa) {
+return bd;
+} else {
+return pc.pc() + bd;
+}
}
+
std::string
-BranchNonPCRel::generateDisassembly(
+BranchDispCondOp::generateDisassembly(
Addr pc, const Loader::SymbolTable *symtab) const
{
std::stringstream ss;
+Addr target;
ccprintf(ss, "%-10s ", mnemonic);
-Loader::SymbolTable::const_iterator it;
-if (symtab && (it = symtab->find(targetAddr)) != symtab->end())
-ss << it->name;
+// Print BI and BO fields
+ss << bi << ", " << bo << ", ";
+
+if (aa)
+target = bd;
else
-ccprintf(ss, "%#x", targetAddr);
-
-return ss.str();
-}
-
-PowerISA::PCState
-BranchPCRelCond::branchTarget(const PowerISA::PCState ) const
-{
-return (uint32_t)(pc.pc() + disp);
-}
-
-std::string
-BranchPCRelCond::generateDisassembly(
-Addr pc, const Loader::SymbolTable *symtab) const
-{
-std::stringstream ss;
-
-ccprintf(ss, "%-10s ", mnemonic);
-
-ss << bo << ", " << bi << ", ";
-
-Addr target = pc + disp;
+target = pc + bd;
Loader::SymbolTable::const_iterator it;
if (symtab && (it = symtab->find(target)) != symtab->end())
@@ -124,47 +121,25 @@
return ss.str();
}
+
PowerISA::PCState
-BranchNonPCRelCond::branchTarget(const PowerISA::PCState ) const
+BranchRegCondOp::branchTarget(ThreadContext *tc) const
{
-return targetAddr;
+Addr addr = tc->readIntReg(srcRegIdx(_numSrcRegs - 1).index());
+return addr & -4ULL;
}
+
std::string
-BranchNonPCRelCond::generateDisassembly(
+BranchRegCondOp::generateDisassembly(
Addr pc, const Loader::SymbolTable *symtab) const
{
std::stringstream ss;
ccprintf(ss, "%-10s ", mnemonic);
-ss << bo << ", " << bi << ", ";
-
-Loader::SymbolTable::const_iterator it;
-if (symtab && (it = symtab->find(targetAddr)) != symtab->end())
-ss << it->name;
-else
-ccprintf(ss, "%#x", targetAddr);
-
-return ss.str();
-}
-
-PowerISA::PCState
-BranchRegCond::branchTarget(ThreadContext *tc) const
-{
-uint32_t regVal = tc->readIntReg(srcRegIdx(_numSrcRegs - 1).index());
-return regVal & 0xfffc;
-}
-
-std::string
-BranchRegCond::generateDisassembly(
-Addr pc, const Loader::SymbolTable *symtab) const
-{
-std::stringstream ss;
-
-ccprintf(ss, "%-10s ", mnemonic);
-
-ss << bo << ", " << bi << ", ";
+// Print the BI and BO
[gem5-dev] Change in gem5/gem5[develop]: arch-sparc: Fix the SPARC build.
Gabe Black has uploaded this change for review. ( https://gem5-review.googlesource.com/c/public/gem5/+/45065 ) Change subject: arch-sparc: Fix the SPARC build. .. arch-sparc: Fix the SPARC build. Change-Id: I233d32f67fc4e5e9f88c3bc95f9f8614543b2885 --- M src/arch/sparc/pseudo_inst_abi.hh 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/arch/sparc/pseudo_inst_abi.hh b/src/arch/sparc/pseudo_inst_abi.hh index 446043a..95bc460 100644 --- a/src/arch/sparc/pseudo_inst_abi.hh +++ b/src/arch/sparc/pseudo_inst_abi.hh @@ -28,7 +28,8 @@ #ifndef __ARCH_SPARC_PSEUDO_INST_ABI_HH__ #define __ARCH_SPARC_PSEUDO_INST_ABI_HH__ -#include "arch/sparc/registers.hh" +#include "arch/sparc/regs/int.hh" +#include "cpu/thread_context.hh" #include "sim/guest_abi.hh" struct SparcPseudoInstABI -- To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/45065 To unsubscribe, or for help writing mail filters, visit https://gem5-review.googlesource.com/settings Gerrit-Project: public/gem5 Gerrit-Branch: develop Gerrit-Change-Id: I233d32f67fc4e5e9f88c3bc95f9f8614543b2885 Gerrit-Change-Number: 45065 Gerrit-PatchSet: 1 Gerrit-Owner: Gabe Black Gerrit-MessageType: newchange ___ 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
