[gem5-dev] Re: Ruby Prefetcher Segfaulting

[Daniel Carvalho via gem5-dev]

 Hello Timothy,
I believe this patch is fixing that: 
https://gem5-review.googlesource.com/c/public/gem5/+/29974
Regards,Daniel

Em sexta-feira, 5 de junho de 2020 11:42:44 GMT+2, Timothy Hayes via 
gem5-dev  escreveu:  
 
 I’ve just rebased onto v20.0.0.1 and am finding that the RubyPrefetcher is not 
working with MESI_Three_Level correctly anymore.

There is a segmentation fault when RubyPrefetcher.cc executes 
m_controller->enqueuePrefetch

I can’t quite work out why this is happening. Oddly, enqueuePrefetch is a 
virtual public function defined in AbstractController.hh. Its implementation is 
in the autogenerated L0Cache_Controller.[cc|hh], however, here it is private 
and doesn’t use the virtual/override keyword. I thought this might be the 
issue, but I see in v19 it is exactly the same and it works fine there.

warn: CheckedInt already exists in allParams. This may be caused by the Python 
2.7 compatibility layer.
warn: Enum already exists in allParams. This may be caused by the Python 2.7 
compatibility layer.
warn: ScopedEnum already exists in allParams. This may be caused by the Python 
2.7 compatibility layer.
gem5 Simulator System.  http://gem5.org
gem5 is copyrighted software; use the --copyright option for details.

gem5 version 20.0.0.1
gem5 compiled Jun  4 2020 19:18:07
gem5 started Jun  5 2020 10:26:41
gem5 executing on tsx-rdrd, pid 13187
command line: ./gem5/build/ARM_MESI_Three_Level/gem5.opt 
./gem5/configs/example/fs.py --ruby --num-cpus=1 --mem-type=SimpleMemory 
--mem-size=4GB --cpu-type=TimingSimpleCPU --kernel=vmlinux.vexpress_gem5_v1_64 
--machine-type=VExpress_GEM5_V1 --disk-image=disk.img --script=script.sh 
--enable-prefetch

warn: You are trying to use Ruby on ARM, which is not working properly yet.
Global frequency set at 1 ticks per second
info: kernel located at: dist/binaries/vmlinux.vexpress_gem5_v1_64
warn: Highest ARM exception-level set to AArch32 but the workload is for 
AArch64. Assuming you wanted these to match.
system.vncserver: Listening for connections on port 5900
system.terminal: Listening for connections on port 3456
system.realview.uart1.device: Listening for connections on port 3457
system.realview.uart2.device: Listening for connections on port 3458
system.realview.uart3.device: Listening for connections on port 3459
0: system.remote_gdb: listening for remote gdb on port 7000
info: Using bootloader at address 0x10
info: Using kernel entry physical address at 0x8008
info: Loading DTB file: m5out/system.dtb at address 0x8800
 REAL SIMULATION 
warn: Existing EnergyCtrl, but no enabled DVFSHandler found.
info: Entering event queue @ 0.  Starting simulation...
warn: Replacement policy updates recently became the responsibility of SLICC 
state machines. Make sure to setMRU() near callbacks in .sm files!
warn: SCReg: Access to unknown device dcc0:site0:pos0:fn7:dev0
warn: Cache maintenance operations are not supported in Ruby.
gem5 has encountered a segmentation fault!

--- BEGIN LIBC BACKTRACE ---
./gem5/build/ARM_MESI_Three_Level/gem5.opt(_Z15print_backtracev+0x2c)[0x56110817369c]
./gem5/build/ARM_MESI_Three_Level/gem5.opt(+0xbdf76f)[0x56110818276f]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x12890)[0x7f516f641890]
./gem5/build/ARM_MESI_Three_Level/gem5.opt(_ZN14RubyPrefetcher16initializeStreamEmijRK15RubyRequestType+0x1a1)[0x561109336151]
./gem5/build/ARM_MESI_Three_Level/gem5.opt(_ZN14RubyPrefetcher11observeMissEmRK15RubyRequestType+0x5a7)[0x561109337627]
./gem5/build/ARM_MESI_Three_Level/gem5.opt(_ZN18L0Cache_Controller14po_observeMissERP11L0Cache_TBERP13L0Cache_Entrym+0x104)[0x561108652fa4]
./gem5/build/ARM_MESI_Three_Level/gem5.opt(_ZN18L0Cache_Controller18doTransitionWorkerE13L0Cache_Event13L0Cache_StateRS1_RP11L0Cache_TBERP13L0Cache_Entrym+0xc64)[0x56110865d2b4]
./gem5/build/ARM_MESI_Three_Level/gem5.opt(_ZN18L0Cache_Controller12doTransitionE13L0Cache_EventP13L0Cache_EntryP11L0Cache_TBEm+0x3d1)[0x56110865db01]
./gem5/build/ARM_MESI_Three_Level/gem5.opt(_ZN18L0Cache_Controller6wakeupEv+0x15d1)[0x561108660b51]
./gem5/build/ARM_MESI_Three_Level/gem5.opt(_ZN10EventQueue10serviceOneEv+0xa5)[0x561108179335]
./gem5/build/ARM_MESI_Three_Level/gem5.opt(_Z9doSimLoopP10EventQueue+0x108)[0x5611081939a8]
./gem5/build/ARM_MESI_Three_Level/gem5.opt(_Z8simulatem+0xa5a)[0x5611081946fa]
./gem5/build/ARM_MESI_Three_Level/gem5.opt(+0x2237390)[0x5611097da390]
./gem5/build/ARM_MESI_Three_Level/gem5.opt(+0xc45d40)[0x5611081e8d40]
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
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: [Suggestion] Replace gem5-users mailing-list with Discourse

[Daniel Carvalho via gem5-dev]

First of all, I don't know how Discourse works, but from what I saw on the 
online demo it looked like a forum. Therefore, our main use case would be as a 
place to ask/deposit questions.
I believe that having a mailing list pushing mails down our throats compels 
people to answer: "Oh, I know the answer for that one". I don't imagine people 
going out of their ways to go to a website/forum and search for questions they 
can answer. I have been actively checking StackOverflow's gem5 questions for 
the past year or so, and I can tell you there is close to null community 
engagement - it is basically Ciro - on the answering department.
That being said, the mailing list is indeed harder to work with, and 
StackOverflow is not a forum, so we could have a try at a forum-like approach 
and see how things go.

Regards,Daniel
   Em quarta-feira, 10 de junho de 2020 00:41:20 GMT+2, Jason Lowe-Power via 
gem5-dev  escreveu:  
 
 +1 for Discourse :).

Just to give a bit more context: I'm also trying to find a good forum for
community engagement during my online Learning gem5 class this summer. I
would like to find a platform that could be used generally for my class
this summer, future iterations of the class, and general gem5 questions, as
I believe there will be significant overlap between these groups.

Other potential options that IMO have more cons than pros when compared to
Discourse:
- Slack/Teams/etc.
- gitter.im
- stackoverflow

That said, we're open to suggestions :). Our goal is to create the most
welcoming and inclusive environment possible. We'll go where our users are!

Cheers,
Jason

On Tue, Jun 9, 2020 at 2:45 PM Bobby Bruce via gem5-dev 
wrote:

> Dear all,
>
> In an effort to better support the gem5 community, there has been a
> suggestion that we drop the gem5-users mailing list and replace it with
> Discourse, https://www.discourse.org/about, a web-based discussion
> platform. I'm writing this email to propose this to the community and ask
> for feedback on the matter.
>
> We have noticed that using mailing lists as our primary communication
> platform is problematic. Sending an email to a list can be daunting
> experience, requiring an etiquette many are not accustom to. I'm sure I'm
> not the only one who feels like they are unduly bothering a large number of
> people when posting to a list (like I'm doing right now :) ). This is, of
> course, an unfortunate hurdle for many to get over when they encounter
> problems using gem5, particularly those new to the project. I've come to
> believe mailing lists are simply not a very good technology for fostering
> community engagement and helping those who are running into difficulties.
> Mailing lists are also difficult to search, and lack proper formatting
> mechanisms to neatly display attributes such as code and output logs.
>
> Looking around at alternative technologies available, Discourse appears to
> be a suitable replacement. For those unaware, Discourse is (essentially) a
> revamp of messaging forums. It is an increasingly popular platform for
> users and developers in open source projects to communicate with one
> another (see LLVM's discourse as an example: https://llvm.discourse.group
> ).
> All-in-all, I think it's a well-designed product and contains all the
> features we'd expect and need to get our work done. I can see no immediate
> downsides to using it, though feedback from the community on the matter
> would be greatly appreciated, particularly from those who have used
> Discourse before. Dissenting opinions on the whole idea of moving away from
> the gem5-user's mailing list are also welcome.
>
> So, let me know what you think! :)
>
> Please note, regardless as to any decision made, we will continue the use
> of the gem5-dev mailing list for technical discussions for the foreseeable
> future.
>
> Kind regards,
> Bobby
> --
> Dr. Bobby R. Bruce
> Room 2235,
> Kemper Hall, UC Davis
> Davis,
> CA, 95616
>
> web: https://www.bobbybruce.net
> ___
> 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 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: Change in gem5/gem5[develop]: mem-cache: Create Compressor namespace

[Daniel Carvalho via gem5-dev]

 Was about to send an e-mail with a heads up, but I guess I was too late.
As reported here 
(https://gem5.atlassian.net/jira/software/c/projects/GEM5/issues/GEM5-753), it 
is not an issue caused by this patch itself. SCons does not trigger 
recompilation when a change modifies the cxx_class; therefore, 
params/BaseCache.hh is not recompiled and generates the error. To solve this, 
one must manually delete this file and force a recompilation.
Regards,Daniel

Em terça-feira, 25 de agosto de 2020 21:20:56 GMT+2, mike upton via 
gem5-dev  escreveu:  
 
 This checkin breaks the build.
you can check at:http://jenkins.gem5.org:8080/job/gem5_develop/136/ 
 

On Tue, Aug 25, 2020 at 8:13 AM Daniel Carvalho (Gerrit) via gem5-dev 
 wrote:


Daniel Carvalho submitted this change.

View Change
Approvals: Nikos Nikoleris: Looks good to me, approved; Looks good to me, 
approved kokoro: Regressions passmem-cache: Create Compressor namespace

Creation of the Compressor namespace. It encapsulates all the cache
compressors, and other classes used by them.

The following classes have been renamed:
BaseCacheCompressor -> Base
PerfectCompressor - Perfect
RepeatedQwordsCompressor -> RepeatedQwords
ZeroCompressor -> Zero

BaseDictionaryCompressor and DictionaryCompressor were not renamed
because the there is a high probability that users may want to
create a Dictionary class that encompasses the dictionary contained
by these compressors.

To apply this patch one must force recompilation (e.g., by deleting
it) of build//params/BaseCache.hh (and any other files that
were previously using these compressors).

Change-Id: I78cb3b6fb8e3e50a52a04268e0e08dd664d81230
Signed-off-by: Daniel R. Carvalho 
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/33294
Reviewed-by: Nikos Nikoleris 
Maintainer: Nikos Nikoleris 
Tested-by: kokoro 
---
M src/mem/cache/base.hh
M src/mem/cache/compressors/Compressors.py
M src/mem/cache/compressors/base.cc
M src/mem/cache/compressors/base.hh
M src/mem/cache/compressors/base_delta.cc
M src/mem/cache/compressors/base_delta.hh
M src/mem/cache/compressors/base_delta_impl.hh
M src/mem/cache/compressors/base_dictionary_compressor.cc
M src/mem/cache/compressors/cpack.cc
M src/mem/cache/compressors/cpack.hh
M src/mem/cache/compressors/dictionary_compressor.hh
M src/mem/cache/compressors/dictionary_compressor_impl.hh
M src/mem/cache/compressors/fpcd.cc
M src/mem/cache/compressors/fpcd.hh
M src/mem/cache/compressors/multi.cc
M src/mem/cache/compressors/multi.hh
M src/mem/cache/compressors/perfect.cc
M src/mem/cache/compressors/perfect.hh
M src/mem/cache/compressors/repeated_qwords.cc
M src/mem/cache/compressors/repeated_qwords.hh
M src/mem/cache/compressors/zero.cc
M src/mem/cache/compressors/zero.hh
22 files changed, 231 insertions(+), 165 deletions(-)

diff --git a/src/mem/cache/base.hh b/src/mem/cache/base.hh
index 3efc7c7..d30de3f 100644
--- a/src/mem/cache/base.hh
+++ b/src/mem/cache/base.hh
@@ -320,7 +320,7 @@
 BaseTags *tags;
 
 /** Compression method being used. */
-BaseCacheCompressor* compressor;
+Compressor::Base* compressor;
 
 /** Prefetcher */
 Prefetcher::Base *prefetcher;
diff --git a/src/mem/cache/compressors/Compressors.py 
b/src/mem/cache/compressors/Compressors.py
index eb1952a..46050f6 100644
--- a/src/mem/cache/compressors/Compressors.py
+++ b/src/mem/cache/compressors/Compressors.py
@@ -1,4 +1,4 @@
-# Copyright (c) 2018 Inria
+# Copyright (c) 2018-2020 Inria
 # All rights reserved.
 #
 # Redistribution and use in source and binary forms, with or without
@@ -31,6 +31,7 @@
 class BaseCacheCompressor(SimObject):
 type = 'BaseCacheCompressor'
 abstract = True
+cxx_class = 'Compressor::Base'
 cxx_header = "mem/cache/compressors/base.hh"
 
 block_size = Param.Int(Parent.cache_line_size, "Block size in bytes")
@@ -41,6 +42,7 @@
 class BaseDictionaryCompressor(BaseCacheCompressor):
 type = 'BaseDictionaryCompressor'
 abstract = True
+cxx_class = 'Compressor::BaseDictionaryCompressor'
 cxx_header = "mem/cache/compressors/dictionary_compressor.hh"
 
 dictionary_size = Param.Int(Parent.cache_line_size,
@@ -48,49 +50,49 @@
 
 class Base64Delta8(BaseDictionaryCompressor):
 type = 'Base64Delta8'
-cxx_class = 'Base64Delta8'
+cxx_class = 'Compressor::Base64Delta8'
 cxx_header = "mem/cache/compressors/base_delta.hh"
 
 class Base64Delta16(BaseDictionaryCompressor):
 type = 'Base64Delta16'
-cxx_class = 'Base64Delta16'
+cxx_class = 'Compressor::Base64Delta16'
 cxx_header = "mem/cache/compressors/base_delta.hh"
 
 class Base64Delta32(BaseDictionaryCompressor):
 type = 'Base64Delta32'
-cxx_class = 'Base64Delta32'
+cxx_class = 'Compressor::Base64Delta32'
 cxx_header = "mem/cache/compressors/base_delta.hh"
 
 class Base32Delta8(BaseDictionaryCompressor):
 type = 'Base32Delta8'
-cxx_class = 'Base32Delta8'
+cxx_class = 'Compressor::Base32Delta8'
 cxx_header = "mem/cache/com

[gem5-dev] Namespace creation on develop branch

[Daniel Carvalho via gem5-dev]

Hello,

This message only concerns those who use the *develop* branch.


We have recently merged another patch creating a namespace 
(https://gem5-review.googlesource.com/c/public/gem5/+/33294). Due to a small 
issue with the SCons configuration, it does not trigger automatic recompilation 
of the params file of the BaseCache class, so recompilation must be forced 
manually; otherwise, the old name without the namespace will be used, and a 
compilation error will pop up.

More details can be found in this thread: 
https://www.mail-archive.com/gem5-dev@gem5.org/msg35502.html .


If more patches creating namespaces are merged in the future, similar 
situations may happen; nonetheless, the solution is analogous.


Regards,
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: For gem5 20.1: Remove "master" and replace with new "stable" default branch (?)

[Daniel Carvalho via gem5-dev]

 +1
Seems like an excellent rename choice!
Em sábado, 29 de agosto de 2020 02:58:57 GMT+2, Jason Lowe-Power via 
gem5-dev  escreveu:  
 
 +1
Thanks for getting the ball rolling on this, Bobby!

On Fri, Aug 28, 2020 at 5:26 PM Bobby Bruce via gem5-dev  
wrote:

Dear all,
Back when we moved from the master branch being under constant development to a 
dual "master-as-stable" and "develop" branch setup, there was talk of renaming 
the master branch. Though, at this time, it seemed unconventional so avoided 
doing so. In the past few months there has been greater momentum in the 
direction of allowing git repositories to call their default branch whatever 
they wish. For example, Github is reworking things in this regard 
(https://github.com/github/renaming/) and defaulting new repos to have "main" 
as the default branch.
Our GoogleSource/Gerrit setup allows us to set HEAD to point towards whatever 
branch we wish. We therefore think v20.1 would be a good time to rename 
"master" to "stable". This afternoon I created a "stable" branch, identical to 
"master", here: https://gem5.googlesource.com/public/gem5/+/refs/heads/stable. 
The next step would be to redirect HEAD to this branch, then delete the master 
branch. Coinciding this with the release of v20.1 (in roughly 2 weeks time) 
seems like an ideal timing.

I'm writing this email to ask if the community agrees with this, and if there 
is anything I'm not taking into account. I believe this should be a fairly 
seamless transition, and will give our two branches more descriptive names  --- 
stable and develop.

Kind regards,Bobby
--
Dr. Bobby R. Bruce
Room 2235,
Kemper Hall, UC Davis
Davis,
CA, 95616
web: https://www.bobbybruce.net
___
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 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] gem5 namespace

[Daniel Carvalho via gem5-dev]

Hello, devs,


We currently have a recurring issue, which is the lack of a gem5 namespace.This 
generates collision with other libraries and user code.


A Jira ticket has been created to point out the issue last year:
https://gem5.atlassian.net/jira/software/c/projects/GEM5/issues/GEM5-730

And this topic has been brought up a few times:

https://www.mail-archive.com/gem5-dev@gem5.org/msg37770.html
https://gem5-review.googlesource.com/c/public/gem5/+/40878
https://www.mail-archive.com/gem5-dev@gem5.org/msg36453.html

Finally, there were already patches that were consequences of lack of a gem5
namespace:

https://gem5-review.googlesource.com/c/public/gem5/+/32175
https://gem5-review.googlesource.com/c/public/gem5/+/40878

A similar issue exists for macros, and an existing proposal to solve it 
alreadyexists, which is to add a "GEM5_" prefix. It follows the coding style, 
whichdictates that "preprocessor symbols (constants and macros) should be 
allcaps with underscores":

https://gem5.atlassian.net/jira/software/c/projects/GEM5/issues/GEM5-912

It does not seem to be controversial to add this namespace; however, there is
still one blocker to greenlight its creation: what will be its name. There are
no explicit rules regarding namespace naming; however, they are typically
declared starting with an uppercase letter followed by lowercase letters. So,
theoretically, gem5's namespace should be "Gem5". This, however, conflicts
with gem5's identity: "“gem5” should always have a lowercase “g”"
(see http://www.gem5.org/getting_started/).


We should decide as a community what is the best approach to take, so I'll
list the options and will request you to cast your votes. If you would like
to add remarks to the discussion, feel free to do so.


NAMESPACE:

1 - namespace Gem5 {}

2 - namespace gem5 {}


MACROS:

A - GEM5_MACRO_NAME
B - gem5_MACRO_NAME

Personally, I think that identity precedes coding style, so *option 2* shouldbe 
taken. Yet, in a slightly inconsistent manner, I would vote for macro*option 
A*. My argument being that it would be more convenient to type itwith all caps, 
and that it would be implied from the identity that it refers toinstances of 
the identity containing lowercase letters, which is not the caseof "GEM5_".
Best,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

[Daniel Carvalho via gem5-dev]

we need to do is to standardize and document when
> and where you need to use the gem5 namespace. For instance, do we need
> to update *all* headers to be in the gem5 namespace? If not, when is an
> object in the gem5 namespace and when it is not? What about `using
> namespace gem5`? Can/must all .cc files include this?
>
> Since this is a relatively big change to the coding standards which
> could cause significant frustration to our users, we should be sure to
> document and standardize *before* we make any code changes.
>
> Cheers,
> Jason
>
>
> On Wed, Apr 14, 2021 at 6:48 AM Daniel Carvalho via gem5-dev
> mailto:gem5-dev@gem5.org> > wrote:
>
>
> Hello, devs,
>
>
>
> We currently have a recurring issue, which is the lack of a
> gem5 namespace.
> This generates collision with other libraries and user code.
>
>
>
> A Jira ticket has been created to point out the issue last year:
>
>
> https://gem5.atlassian.net/jira/software/c/projects/GEM5/issues/G
> EM5-730
>
>
> And this topic has been brought up a few times:
>
>
> https://www.mail-archive.com/gem5-
> d...@gem5.org/msg37770.html
>
> https://gem5-
> review.googlesource.com/c/public/gem5/+/40878
>
> https://www.mail-archive.com/gem5-
> d...@gem5.org/msg36453.html
>
>
> Finally, there were already patches that were consequences
> of lack of a gem5
> namespace:
>
>
> https://gem5-
> review.googlesource.com/c/public/gem5/+/32175
>
> https://gem5-
> review.googlesource.com/c/public/gem5/+/40878
>
>
> A similar issue exists for macros, and an existing proposal to
> solve it already
> exists, which is to add a "GEM5_" prefix. It follows the coding
> style, which
> dictates that "preprocessor symbols (constants and macros)
> should be all
> caps with underscores":
>
>
>
> https://gem5.atlassian.net/jira/software/c/projects/GEM5/issues/G
> EM5-912
>
>
> It does not seem to be controversial to add this namespace;
> however, there is
> still one blocker to greenlight its creation: what will be its
> name. There are
> no explicit rules regarding namespace naming; however, they
> are typically
> declared starting with an uppercase letter followed by
> lowercase letters. So,
> theoretically, gem5's namespace should be "Gem5". This,
> however, conflicts
> with gem5's identity: "“gem5” should always have a
> lowercase “g”"
> (see http://www.gem5.org/getting_started/).
>
>
>
> We should decide as a community what is the best approach
> to take, so I'll
> list the options and will request you to cast your votes. If you
> would like
> to add remarks to the discussion, feel free to do so.
>
>
>
> NAMESPACE:
>
>
> 1 - namespace Gem5 {}
>
>
> 2 - namespace gem5 {}
>
>
>
> MACROS:
>
>
> A - GEM5_MACRO_NAME
>
>
> B - gem5_MACRO_NAME
>
>
> Personally, I think that identity precedes coding style, so
> *option 2* should
> be taken. Yet, in a slightly inconsistent manner, I would vote
> for macro
> *option A*. My argument being that it would be more
> convenient to type it
> with all caps, and that it would be implied from the identity
> that it refers to
> instances of the identity containing lowercase letters, which
> is not the case
> of "GEM5_".
>
> Best,
> Daniel
>
>
> ___
> gem5-dev mailing list -- gem5-dev@gem5.org <mailto:gem5-
> d...@gem5.org>
> To unsubscribe send an email to gem5-dev-le...@gem5.org
> <mailto:gem5-dev-le...@gem5.org>
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
> ___
> gem5-dev mailing list -- gem5-dev@gem5.org <mailto:gem5-
> d...@gem5.org>
> To unsubscribe send an email to gem5-dev-le...@gem5.org
> <mailto:gem5-dev-le...@gem5.org>
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

___
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

[Daniel Carvalho via gem5-dev]

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  
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 
 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 harder to read/understand. In this sense, 
the uppercase version generates better code.

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 and within our SystemC bridge (more on that later) - however, 
since we already have some exceptions, it wouldn't be the end of the world 
having it start with a capital letter.


In the end, I personally do not care about which approach is taken, but the 
decision taken must be taken as a community. Therefore, it would be nice if we 
could have participation from other contributors to make the final decision 
less susceptible to changes/complaints in the future.


Regarding when to use it:IMHO (and not thoroughly thought out), all .cc and .hh 
and objects within src/ should be subject to the namespace. Objects declared 
there are declared and maintained by gem5. Because of that there would probably 
be very few instances of namespace resolution within src/, so we should keep 
avoiding "using namespace" and being verbose about it. Finally, we also 
probably want to encourage users to define their objects inside the gem5 
namespace to make it less unlikely that they will give up on uploading their 
contributions due to the different styles, and the laziness to adapt code. This 
means that disturbance in user code would be minimal: they would simply add 
"namespace (G|g)em5 {" in the beginning and "} // namespace (G|g)em5" at the 
end, instead of multiple "(G)|gem5::" instances.


Regards,
Daniel
For the record, if the namespaces you found using snake_case start with sc_, 
those are for systemc and are mandated by that standard. The one exception, 
sc_gem5, is one I made up which is closely associated with the other systemc 
namespaces and is named similarly to them for consistency.
Gabe
On Thu, Apr 15, 2021 at 1:51 AM Giacomo Travaglini  
wrote:

My vote goes to 1 and

[gem5-dev] Re: gem5 namespace

[Daniel Carvalho via gem5-dev]

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

[Daniel Carvalho via gem5-dev]

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

[Daniel Carvalho via gem5-dev]

 Glad to see that we are reaching a consensus! Then we will create the "gem5" 
namespace, rename (most) macros to use a "GEM5_" prefix, and will rename all 
namespaces to snake case.


I agree that we should do the renaming on a case-by-case basis. I've created a 
new Jira Epic to cover converting all namespaces to snake case: 
https://gem5.atlassian.net/jira/software/c/projects/GEM5/issues/GEM5-974 .

Regarding deprecating namespaces, aliases cannot be assigned attributes (thus 
they cannot be marked as deprecated), but I believe this will do the trick: 

    #define GEM5_DEPRECATE_NAMESPACE(old_namespace, new_namespace) \    
namespace [[gnu::deprecated("Please use the new namespace: '" \
    #new_namespace "'")]] old_namespace { \
    using namespace new_namespace; \
        }


Example:

    // Suppose we want to rename a namespace from Test to test
    namespace test {    int var;
    }    // This can be added to the base file (i.e., the one we know everybody 
will include)
    GEM5_DEPRECATE_NAMESPACE(Test, test)
    ...
    // In code, somewhere:    test::var = 2; // Does not show deprecation 
warning
    Test::var = 2; // Shows deprecation warning

Cheers,
Daniel
Em quarta-feira, 5 de maio de 2021 23:28:31 BRT, Gabe Black via gem5-dev 
 escreveu:  
 
 Yeah, we don't have a ton of namespaces already, but having two copies of all 
of them for a while might be messy. I also don't think you can really mark a 
namespace as deprecated without even more macro trickery.
Using snake case for the namespaces would be a change to acclimate to and I'm 
not *excited* to make a big change like that, especially to something I'm so 
used to, but importantly it would maintain consistency which is arguably more 
important. It would bring us in line with namespaces like "std" too, which, 
given how common it is, wouldn't be the worst thing.
We would have to be careful that short, simple namespace names like "loader" 
don't conflict with existing local variable names. Given the potential for 
problems there and that we only have a handful of namespaces currently, it 
might make sense to convert each namespace one by one, which might make it 
easier to deal with fallout.
Gabe
On Wed, May 5, 2021 at 6:45 AM Giacomo Travaglini via gem5-dev 
 wrote:

Hi all,

I agree with Daniel's analysis and solution, as enforcing snake_case for 
namespaces would probably make everyone happy.
We could in theory adopt namespace aliases for backward compatibility, to 
transition smoothly from one "convention" (PascalCase for namespaces is not 
mentioned in our coding style) to the other, but I think it will complicate 
things even further.

Kind Regards

Giacomo

> -Original Message-
> From: Jason Lowe-Power via gem5-dev 
> Sent: 03 May 2021 21:27
> To: gem5 Developer List 
> Cc: Jason Lowe-Power 
> Subject: [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  d...@gem5.org <mailto: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 sta

[gem5-dev] Re: Build failed in Jenkins: nightly #307

[Daniel Carvalho via gem5-dev]

 Hi, Bobby,
Previous to that patch, enabled() (now tracing()) checked if the flag was 
globally enabled and if it had been individually enabled, and the tracing check 
was done elsewhere (DTRACE(flag) did that). Now tracing() is checking both 
conditions AND if tracing is on, which is likely a much more desirable design. 
As such, the tests must be updated to reflect this API change (e.g., replace 
ASSERT_TRUE(x.tracing()) with ASSERT_TRUE(!TRACING_ON || x.tracing()), or 
simply disable these tests altogether with a NDEBUG check).
Regards,Daniel
Em terça-feira, 11 de maio de 2021 16:48:35 BRT, Bobby Bruce 
 escreveu:  
 
 Hey Daniel and Gabe,
I'm looking into this test failure (reproducible with `scons 
build/NULL/unittests.fast`). I'm a little confused about how these tests ever 
passed. This patchet introduces the error (or at least, if this patch is 
reverted, the tests pass): 
https://gem5-review.googlesource.com/c/public/gem5/+/45008, but this doesn't 
appear to be doing anything bad. If compiling to `.fast` `tracing()` should 
return false (as far as I understand things), but the tests appear to assume 
this should return true, mostly so this branch is traversed: 
https://gem5.googlesource.com/public/gem5/+/refs/heads/develop/src/base/debug.cc#177.
 As things currently stand `TRACING_ON` is false and `_tracing` is true with 
`.fast`.

Does anyone have any insight? I feel like I might be overlooking something 
here. I realize things have been moved around in debug.hh recently but nothing 
seems particularly incorrect.

Kind regards,Bobby

--Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616
web: https://www.bobbybruce.net


On Mon, May 10, 2021 at 11:43 PM jenkins-no-reply--- via gem5-dev 
 wrote:

See 

Changes:

[gabe.black] base: Add macros to mark things as deprecated.

[gabe.black] base: Mark the unused DPRINTF_UNCONDITIONAL macro as deprecated.

[gabe.black] base,arch,dev,mem: Always compile DPRINTFs, even if they're 
disabled.

[gabe.black] base: Collapse the DTRACE macro in DPRINTF.

[gabe.black] base: Simplify the definition of DTRACE.

[Giacomo Travaglini] arch-arm: Fix SMM* instructions

[gabe.black] base,python: Simplify how we check if a debug flag is enabled.

[gabe.black] base: Move TRACING_ON check into Flag::tracing().

[gabe.black] misc: Collapse all uses of DTRACE(x) to Debug::x.

[gabe.black] base,arch-sparc: Overhaul the small fenv wrapper in base.

[gabe.black] arch-arm: Use src/base/fenv.hh instead of raw fenv.h.

[gabe.black] cpu: Delete an unnecessary return in RegId::flatIndex.

[gabe.black] arch,cpu: Get rid of is*Reg() methods in RegId.

[gabe.black] cpu: Get rid of the unused NumRegClasses constant.

[gabe.black] cpu: Get rid of the redundant PhysRegIndex type.

[gabe.black] scons,misc: Remove the ability to disable some trivial features.

[gabe.black] scons: Pull builder definitions out of SConstruct.

[gabe.black] scons: Simplify finding the python lib with ParseConfig.

[gabe.black] scons: Update comments in SConstruct.

[gabe.black] python: Collapse away the now unused readCommandWithReturn 
function.

[gabe.black] python,scons: Move readCommand and compareVersions into site_scons.

[gabe.black] arch-x86: Clean up x86 integer indexes.

[gabe.black] arch-x86: Create some infrastructure for x86 microop operands.

[gabe.black] arch: Set %(op_idx)s properly when predicated operands are present.

[gabe.black] arch-x86: Build source picking into the operands.


--
[...truncated 506.72 KB...]
[==] Running 8 tests from 1 test suite.
[--] Global test environment set-up.
[--] 8 tests from Coroutine
[ RUN      ] Coroutine.Unstarted
[       OK ] Coroutine.Unstarted (0 ms)
[ RUN      ] Coroutine.Unfinished
[       OK ] Coroutine.Unfinished (0 ms)
[ RUN      ] Coroutine.Passing
[       OK ] Coroutine.Passing (1 ms)
[ RUN      ] Coroutine.Returning
[       OK ] Coroutine.Returning (0 ms)
[ RUN      ] Coroutine.Fibonacci
[       OK ] Coroutine.Fibonacci (0 ms)
[ RUN      ] Coroutine.Cooperative
[       OK ] Coroutine.Cooperative (0 ms)
[ RUN      ] Coroutine.Nested
[       OK ] Coroutine.Nested (0 ms)
[ RUN      ] Coroutine.TwoCallers
[       OK ] Coroutine.TwoCallers (0 ms)
[--] 8 tests from Coroutine (1 ms total)

[--] Global test environment tear-down
[==] 8 tests from 1 test suite ran. (1 ms total)
[  PASSED  ] 8 tests.
Running main() from build/googletest/googletest/src/gtest_main.cc
[==] Running 16 tests from 1 test suite.
[--] Global test environment set-up.
[--] 16 tests from FlagsTest
[ RUN      ] FlagsTest.ConstructorZero
[       OK ] FlagsTest.ConstructorZero (0 ms)
[ RUN      ] FlagsTest.ConstructorSingle
[       OK ] FlagsTest.ConstructorSingle (0 ms)
[ RUN      ] FlagsTest.ConstructorMulti
[       OK ] FlagsTest.ConstructorMulti (0 ms)
[ RUN      ] FlagsTest.TypeAssign

[gem5-dev] Re: Build failed in Jenkins: compiler-checks #72

[Daniel Carvalho via gem5-dev]

 +1 to raising the minimum GCC version to 7 (not sure about 7.3; 2018 may be 
too recent) and enabling C++17.
Em quinta-feira, 13 de maio de 2021 19:58:49 BRT, Gabe Black via gem5-dev 
 escreveu:  
 
 I have no objection to moving the compiler versions up. I don't really know 
what benchmark we use to decide when that's ok to do. If we do move up, it 
would be nice to move to a version which would let us use c++17.
For gcc, the oldest version with any support is 5, there seems to be pretty 
solid support by version 7, pretty much complete compiler support by 8, pretty 
much complete library support by 9, and it's the default version by 11. If we 
remove support for 5 and 6, I think that might bring us into position to use 
c++17 with 7, and I think if we move to 8 it's pretty safe.
Version 5.2 was released on July 16, 2015Version 7.3 was released on January 
25, 2018Version 8.1 was released on May 2, 2018Version 11.1 was released very 
recently on  April 27, 2021.
For clang, it seems to be a little more straightforward, and we'd just need 
version 5. This was released on 7 September 2017.
So, with no other data points, I'd vote for updating to gcc version 7.3 (or 
just 7+), and clang 5, and then enabling c++17.

https://en.cppreference.com/w/cpp/compiler_support/17
https://www.gnu.org/software/gcc/projects/cxx-status.html#cxx17
https://clang.llvm.org/cxx_status.html
https://en.wikipedia.org/wiki/Clang#Status_history
https://gcc.gnu.org/releases.html

On Thu, May 13, 2021 at 1:43 PM Bobby Bruce via gem5-dev  
wrote:

These two patchset should fix most of this: 
https://gem5-review.googlesource.coThism/c/public/gem5/+/45479, 
https://gem5-review.googlesource.com/c/public/gem5/+/45481
Unfortunately, we currently can't compile with GCC 5 as deprecation of enum 
values were only introduced in GCC 6. So this change is problematic: 
https://gem5.googlesource.com/public/gem5/+/6d7c3afcd44843fb93578d63ad1f5401906d17ad/src/sim/aux_vector.hh#100,
 and will continue to break the compilation tests.
Perhaps this is worthy of discussion: how long do we want to continue 
supporting GCC 5? What's our policy here? The GCC 5 and 6 release series are no 
longer supported, but I wouldn't go as far to say these are old compilers 
completely unused in the wider world.

--Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616
web: https://www.bobbybruce.net


On Tue, May 11, 2021 at 11:45 PM jenkins-no-reply--- via gem5-dev 
 wrote:

See 


Changes:

[shingarov] arch-power: Fix precedence of register operands

[shingarov] arch-power: Add fields for DS form instructions

[m] arch-x86: Implement ACPI root tables

[m] arch-x86: Add ACPI support for MADT

[m] configs: Use MADT in x86 full system simulation

[shingarov] arch-power: Refactor load-store instructions

[gabe.black] arch,cpu: Rename arch/registers.hh to arch/vecregs.hh.

[gabe.black] tests: Delete the nmtest "UnitTest".

[gabe.black] tests: Remove the stattest "UnitTest".

[gabe.black] misc: Delete the unittest/genini.py script.

[gabe.black] scons,tests: Delete support for the UnitTest scons class/function.

[gabe.black] arch-x86: Fix x86 build.

[gabe.black] arch-x86: Let individual reg uops specialize their arguments.

[gabe.black] arch-x86: Factor out duplication in the new RegOp base classes.

[gabe.black] arch-x86: Generalize the RegOp operands.

[gabe.black] arch-x86: Use the new op bases for memory microops.

[gabe.black] arch-x86: Remove static code from debug.isa and fix style.

[gabe.black] arch-x86: Use the *Op classes with FP microops.

[gabe.black] arch-x86: Use the newly flexible RegOpT to implement the limm uop.

[gabe.black] arch-x86: Correct style and use uop args in specop.isa.

[gabe.black] arch-x86: Fix style and use uop args in seqop.isa.

[gabe.black] arch-x86: Style fixes and use uop args in the media ops.

[gabe.black] arch-x86: Use regIdx() instead of creating an InstRegIndex 
directly.

[gabe.black] arch-x86: Eliminate the DependenceTags in registers.hh.

[gabe.black] arch-x86: Create a separate type for floating point reg idxs.

[gabe.black] arch-x86: Specialize the remaining operand types for uops.

[gabe.black] arch: Delete a few unused vector register types/constants.

[gabe.black] arch-x86: Make pick, signedPick and merge take indexes directly.

[gabe.black] arch-x86: Use the new multiplication helpers in the mul uops.

[gabe.black] arch-x86: Move the step division helper out of the ISA desc.

[gabe.black] arch-x86: Get rid of the now unused print(Src|Dest)Reg methods.

[gabe.black] base: Add macros to mark things as deprecated.

[gabe.black] base: Mark the unused DPRINTF_UNCONDITIONAL macro as deprecated.

[gabe.black] base,arch,dev,mem: Always compile DPRINTFs, even if they're 
disabled.

[gabe.black] base: Collapse the DTRACE macro in DPRINTF.

[gabe.black] base: Simplify the definition of DTRACE.

[Giacomo Travaglini] arch-arm: Fix SMM* instr

[gem5-dev] Re: RFC: run python Black on gem5 python code

[Daniel Carvalho via gem5-dev]

are foundation, which makes it seem "official".
> Though the real reason is that it's the first one I looked at and the only 
> one I
> investigated.

I actually thought pycodestyle was the "official" linter (I am not sure if the 
"official" word makes completely sense though)

I was asking this because for example in pycodestyle (and prob other linters as 
well) there are error codes 
https://pycodestyle.pycqa.org/en/latest/intro.html#error-codes you could use 
include or exclude lists of errors (to ignore specific types of warnings).

Kind regards

Giacomo

>
>
>
> Kind regards
>
> Giacomo
>
> > -Original Message-
> > From: Gabe Black via gem5-dev  <mailto:gem5-dev@gem5.org> >
> > Sent: 04 March 2021 03:59
> > To: gem5 Developer List mailto:gem5-
> d...@gem5.org> >
> > Cc: Gabe Black  <mailto:gabe.bl...@gmail.com> >
> > Subject: [gem5-dev] Re: RFC: run python Black on gem5 python code
> >
> > I'm a little worried about the no exceptions part of that, since we
> might have
> > some weird restrictions that we have to do weird things to work
> around, but I
> > can't really think of an example of that off hand. I'd want to look at it
> to see
> > how much wiggle room there is in the style, since I think ironclad
> rules which
> > make no accommodation for occasional common sense are maybe
> more
> > trouble than they're worth. I'm not opposed to having at least some
> stated
> > standard for python though, and the "official" one seems like a
> pretty
> > reasonable choice. I guess it's fine with me, up until it causes me
> some sort of
> > problem :-)
>
>
>
> I actually think it's a feature not a bug. With an "uncompromising Python code
> formatter" there can be no arguments in code review about the style.
>
>
> >
> > Maybe the right thing to do would be to give it a shot but not make
> it
> > compulsory until we have a feeling for how much trouble it is.
> >
> >
> > Gabe
> >
> > On Wed, Mar 3, 2021 at 11:24 AM Bobby Bruce via gem5-dev  > d...@gem5.org <mailto:d...@gem5.org>  <mailto:gem5-
> d...@gem5.org <mailto:gem5-dev@gem5.org> > > wrote:
> >
> >
> > Sounds like a good idea to me.
> > ---
> >
> > Dr. Bobby R. Bruce
> > Room 2235,
> > Kemper Hall, UC Davis
> > Davis,
> > CA, 95616
> >
> >
> > web: https://www.bobbybruce.net
> >
> >
> >
> > On Wed, Mar 3, 2021 at 10:11 AM Daniel Carvalho via gem5-dev
> > mailto:gem5-dev@gem5.org>
> <mailto:gem5-dev@gem5.org <mailto:gem5-dev@gem5.org> > > wrote:
> >
> >
> > +1
> >
> >
> > Em quarta-feira, 3 de março de 2021 14:35:57 BRT, Jason
> > Lowe-Power via gem5-dev mailto:gem5-
> d...@gem5.org>  <mailto:gem5- <mailto:gem5->
> > d...@gem5.org <mailto:d...@gem5.org> > > escreveu:
> >
> >
> > Hi all,
> >
> > Right now, we don't have an official style guide for python.
> > Our style guide
> >
> (http://www.gem5.org/documentation/general_docs/development/coding_st
> > yle/) is very C++ focused.
> >
> > I would like to propose adopting a relatively strict PEP 8 style
> > guide: https://www.python.org/dev/peps/pep-0008. This is the
> "official" style
> > guide for python (as much as there is anything official). I say
> "relatively strict"
> > to mean that we will limit our exceptions *as much as possible*.
> >
> > To implement this, Andreas S. recently pointed me to the
> > "Black" package (https://pypi.org/project/black/) which automatically
> fixes
> > code style. I just tried it out with gem5art (patch coming soon) and
> found that
> > it works really well. The only downside is that it's not configurable at
> all.
> > Adding special cases would be almost impossible.
> >
> > Concrete and specific proposal:
> > - Adopt PEP 8 as our official style guide
> > - Use black to reformat all python code in src/
> > - Use black to reformat code in configs/
> > - Use black to reformat other python code
> >
> > - Use black as part of our commit hook to make sure all future
> > python is formatted to PEP 8
> >
> > Let me know what you think!
> >
> > Cheers,
> > Jason
> >
> > ___
> > gem5-dev mailing list -- gem5-dev@gem5.org <mailto:gem5-
> d...@gem5.org>  <mailto:gem5- <mailt

[gem5-dev] Re: gem5 namespace

[Daniel Carvalho via gem5-dev]

Dear all,

We have already renamed most of the existing namespaces to snake case. Before 
moving on to the last ones, which may generate more conflicts, I have 
encapsulated most of gem5 in a gem5 namespace. This will ensure that these last 
- and possibly most likely to generate conflicts - renames generate less 
issues. The respective chain can be found in 
https://gem5-review.googlesource.com/c/public/gem5/+/46323/4 .

The approach taken to implement the gem5 namespace was not ideal, since it is a 
huge dump on the whole project instead of a per-dir approach; however, it was a 
trade-off between number of rebasing conflicts that I would have to deal with, 
and the time I had available for this project. To make it at least a bit 
reviewable, I have split it into sub-patches with common approaches. These 
patches will be squashed as soon as they are approved.

Finally, every time I do a git push, many conflicts pop up. This requires a lot 
of effort to support, and processing power to recompile everything and make 
sure everything still works (I don't currently have the latter). Also, the next 
version is on the corner, and it would be great to deliver the gem5 namespace 
with it. Therefore, I would like to get these changes in ASAP. When problems 
show up - and they will - they can be more easily fixed, since this change is 
trivial - one will most likely just need to add a "namespace gem5 {" to a 
specific file that is compiled in a specific simulation configuration.
tl;dr: Could you review the namespace patches so that we can try to get them in 
for the next version?

Regards,Daniel
   Em sexta-feira, 7 de maio de 2021 02:30:13 BRT, Gabe Black via gem5-dev 
 escreveu:  
 
 Be warned though, that there are some pitfalls with this namespace deprecation 
approach. The namespaces here are not actually equivalent, and so the old 
deprecated namespace can have things added to it that won't show up in the new 
one. This is probably not that big a deal in practice, and should be pretty 
useful letting people know what's going on, but it's still important to be 
aware of limitations.
Gabe
On Thu, May 6, 2021 at 7:36 AM Jason Lowe-Power via gem5-dev 
 wrote:

Thanks for putting this all together, Daniel!
IMO, we should do our best with providing deprecation notices, but not bend 
over backwards. For things that are easy to add deprecations to (e.g., function 
names / class names) we should do it, and for things that have a big impact on 
our users we should provide the warnings. However, if it's very difficult to 
provide the notice *and* if it's for something that is unlikely to affect 
users, then the deprecation warnings are less important.
Example: if we change `panic` to `gem5_panic` (or `GEM5_PANIC`?) we definitely 
need a deprecation warning. This will significantly impact users. If, on the 
other hand, we change a macro that is used in exactly one place, it's probably 
less important

Thanks for coming up with a way to do namespaces! This will be useful.

Cheers,Jason

On Thu, May 6, 2021 at 7:06 AM Daniel Carvalho via gem5-dev  
wrote:

 Glad to see that we are reaching a consensus! Then we will create the "gem5" 
namespace, rename (most) macros to use a "GEM5_" prefix, and will rename all 
namespaces to snake case.


I agree that we should do the renaming on a case-by-case basis. I've created a 
new Jira Epic to cover converting all namespaces to snake case: 
https://gem5.atlassian.net/jira/software/c/projects/GEM5/issues/GEM5-974 .

Regarding deprecating namespaces, aliases cannot be assigned attributes (thus 
they cannot be marked as deprecated), but I believe this will do the trick: 

    #define GEM5_DEPRECATE_NAMESPACE(old_namespace, new_namespace) \    
namespace [[gnu::deprecated("Please use the new namespace: '" \
    #new_namespace "'")]] old_namespace { \
    using namespace new_namespace; \
        }


Example:

    // Suppose we want to rename a namespace from Test to test
    namespace test {    int var;
    }    // This can be added to the base file (i.e., the one we know everybody 
will include)
    GEM5_DEPRECATE_NAMESPACE(Test, test)
    ...
    // In code, somewhere:    test::var = 2; // Does not show deprecation 
warning
    Test::var = 2; // Shows deprecation warning

Cheers,
Daniel
Em quarta-feira, 5 de maio de 2021 23:28:31 BRT, Gabe Black via gem5-dev 
 escreveu:  
 
 Yeah, we don't have a ton of namespaces already, but having two copies of all 
of them for a while might be messy. I also don't think you can really mark a 
namespace as deprecated without even more macro trickery.
Using snake case for the namespaces would be a change to acclimate to and I'm 
not *excited* to make a big change like that, especially to something I'm so 
used to, but importantly it would maintain consistency which is arguably more 
important. It would bri

[gem5-dev] Re: deprecating warn_once

[Daniel Carvalho via gem5-dev]

 Hello,
I like the idea of GEM5_ONCE, but as it would become part of the API users 
could definitely use in unforeseen ways (e.g., debugging). I am not saying this 
is a bad thing, but it is something to consider.
Regards,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: IWYU tool and include checking from scons

[Daniel Carvalho via gem5-dev]

I am in favor of running a tool like IWYU to fix the codebase (although I have 
never used it), but I am not sure if adding this to the build system is a good 
idea: our current contribution frequency (~1k commits/year?) likely does not 
generate enough extra/missing includes to require the overhead added to every 
build. There is also the issue of adding another dependency VS making it 
optional and creating an inconvenience for others: users that do not use the 
tool will generate compilation warnings/errors for users that do.

IMO, unless the overhead is unnoticeable, it would be enough to run IWYU once a 
semester/year to try to find and fix any the period's mistakes. If doing this 
periodic approach, we should probably add an util script that installs IWYU, 
builds/fixes the includes, and uninstalls IWYU, in order to automate the 
process.
Best,Daniel
   Em terça-feira, 12 de janeiro de 2021 22:41:58 BRT, Gabe Black via gem5-dev 
 escreveu:  
 
 Hi folks. Daniel has submitted a big change which fixes up a bunch of missing 
includes in files which were coincidentally getting the definitions they needed 
indirectly from some other file. Way down the line in c++20 I think the 
"modules" mechanism would be a great tool avoiding these sorts of problems from 
the get go, but in the meantime it would be helpful if we had a way to scan for 
these sorts of issues, instead of finding them when they cause problems. These 
sorts of overly broad, leaky includes also likely slow down builds by making 
the compiler process more text than it really needs to, and also introduces 
more dependencies at the scons level than are necessary.
I'm not really familiar with it, but after a little bit of Googling I found a 
tool called iwyu (include what you use) which looks at includes and finds 
places where includes are missing (transitive includes), and also includes 
which are not being used. It looks like the way this tool is intended to be 
used is to substitute it for the compiler, and then run it through, for 
instance, make.
Rather than use it that way, I'm thinking we might be able to set up additional 
scons rules which would build iwyu error reports based on Source declarations 
in scons, alongside the normal build outputs. There may be false positives in 
there somewhere, particularly from code we don't control, and so we'd likely 
want to add in ways to flag exceptions.
If this sort of scons integration works out, it would be nice to make a pass of 
this tool part of the presubmit checks, assuming it doesn't add tons of time to 
the build.
What do folks think? I don't necessarily have a lot of time to work on this 
myself, although I might give it a shot if I find some time. It could also be 
something for someone wanting to cut their teeth on scons to help with, and I 
could help give pointers and help with the high level design if someone wanted 
to try it. If you do want to give it a try, at the very least keep me in the 
loop so we don't have to redo things in a major way when it comes time to check 
something in.
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  ___
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-join debug flags headers

[Daniel Carvalho via gem5-dev]

Hello all,
I've uploaded a commit that re-joins the debug header files into a single one: 
https://gem5-review.googlesource.com/c/public/gem5/+/39255. This means that 
instead of having to include a different header for each and every debug flag 
used in a file, only one is needed. For example, in src/arch/arm/kvm/arm_cpu.cc
| 
    #include "debug/Kvm.hh" |


|     #include "debug/KvmContext.hh" |

    #include "debug/KvmInt.hh"
would be replaced by
    #include "debug/flags.hh"
Finally, since most of the code using these flags will use DPRINTF or a similar 
macro, this include could be added to base/trace.hh, so that most of the times 
it would be included transitively.

The advantage of this change is that debugging becomes easier/faster: this file 
would behave as a library of supported flags and very few header files would 
suffice for all debugging needs. The disadvantage is that every time a commit 
introduces or removes a debug flag debug/flags.hh will be recompiled, which 
will cause an almost complete build. Luckily, debug flags are not frequently 
modified.

Performance-wise both approaches are similar.
What are your opinions in this matter?
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: Build failed in Jenkins: Nightly #208

[Daniel Carvalho via gem5-dev]

 Fix here: https://gem5-review.googlesource.com/c/public/gem5/+/40555Em 
quarta-feira, 3 de fevereiro de 2021 17:18:14 BRT, jenkins-no-reply--- via 
gem5-dev  escreveu:  
 
 See 

Changes:

[gabe.black] ext: Update pybind11 to version 2.6.2.

[shunhsingou] systemc: remove boost header dependency

[Giacomo Travaglini] ext: testlib loading tests from multiple directories

[Bobby R. Bruce] util,python: Fix Pre-commit hooks to ignore non-source files

[Bobby R. Bruce] util,python: Add check to ensure files are utf-8 in pre-commit

[odanrc] scons: Separate debug flags from debug-format flags

[odanrc] sim: Move cur tick to its own files

[odanrc] base,tests: Add a basic fake class to handle curTick

[odanrc] base: Move Stats::Info functions to its own source file

[odanrc] base,tests: Create unit tests for Stats::Stor

[gabe.black] arch: Templatize the BasicDecodeCache.


--
[...truncated 532.91 KB...]
[--] 4 tests from TypesTest
[ RUN      ] TypesTest.FloatToBits32
[      OK ] TypesTest.FloatToBits32 (0 ms)
[ RUN      ] TypesTest.floatToBits64
[      OK ] TypesTest.floatToBits64 (0 ms)
[ RUN      ] TypesTest.floatsToBitsDoubleInput
[      OK ] TypesTest.floatsToBitsDoubleInput (0 ms)
[ RUN      ] TypesTest.floatsToBitsFloatInput
[      OK ] TypesTest.floatsToBitsFloatInput (0 ms)
[--] 4 tests from TypesTest (0 ms total)

[--] Global test environment tear-down
[==] 19 tests from 3 test suites ran. (6 ms total)
[  PASSED  ] 19 tests.
build/NULL/sim/byteswap.test.debug 
--gtest_output=xml:build/NULL/unittests.debug/sim/byteswap.test.xml
Running main() from build/googletest/googletest/src/gtest_main.cc
[==] Running 2 tests from 1 test suite.
[--] Global test environment set-up.
[--] 2 tests from UncontendedMutex
[ RUN      ] UncontendedMutex.Lock
build/NULL/base/debug.test.debug 
--gtest_output=xml:build/NULL/unittests.debug/base/debug.test.xml
Running main() from build/googletest/googletest/src/gtest_main.cc
[==] Running 12 tests from 4 test suites.
[--] Global test environment set-up.
[--] 1 test from DebugFlagDeathTest
[ RUN      ] DebugFlagDeathTest.UniqueNames
[      OK ] DebugFlagDeathTest.UniqueNames (1 ms)
[--] 1 test from DebugFlagDeathTest (1 ms total)

[--] 8 tests from DebugFlagTest
[ RUN      ] DebugFlagTest.NameDesc
[      OK ] DebugFlagTest.NameDesc (0 ms)
[ RUN      ] DebugFlagTest.IsFormat
[      OK ] DebugFlagTest.IsFormat (0 ms)
[ RUN      ] DebugFlagTest.ConversionOperator
[      OK ] DebugFlagTest.ConversionOperator (0 ms)
[ RUN      ] DebugFlagTest.FindFlag
[      OK ] DebugFlagTest.FindFlag (0 ms)
[ RUN      ] DebugFlagTest.ChangeFlag
[      OK ] DebugFlagTest.ChangeFlag (0 ms)
[ RUN      ] DebugFlagTest.SetClearDebugFlag
[      OK ] DebugFlagTest.SetClearDebugFlag (0 ms)
[ RUN      ] DebugFlagTest.NoDumpDebugFlags
[      OK ] DebugFlagTest.NoDumpDebugFlags (0 ms)
[ RUN      ] DebugFlagTest.DumpDebugFlags
[      OK ] DebugFlagTest.DumpDebugFlags (0 ms)
[--] 8 tests from DebugFlagTest (0 ms total)

[--] 1 test from DebugSimpleFlagTest
[ RUN      ] DebugSimpleFlagTest.Enabled
[      OK ] DebugSimpleFlagTest.Enabled (0 ms)
[--] 1 test from DebugSimpleFlagTest (0 ms total)

[--] 2 tests from DebugCompoundFlagTest
[ RUN      ] DebugCompoundFlagTest.Enabled
[      OK ] DebugCompoundFlagTest.Enabled (0 ms)
[ RUN      ] DebugCompoundFlagTest.EnabledKids
[      OK ] DebugCompoundFlagTest.EnabledKids (0 ms)
[--] 2 tests from DebugCompoundFlagTest (0 ms total)

[--] Global test environment tear-down
Running main() from build/googletest/googletest/src/gtest_main.cc
[==] Running 8 tests from 1 test suite.
[--] Global test environment set-up.
[==] 12 tests from 4 test suites ran. (1 ms total)
[  PASSED  ] 12 tests.
[--] 8 tests from ByteswapTest
[ RUN      ] ByteswapTest.swap_byte64
[      OK ] ByteswapTest.swap_byte64 (0 ms)
[ RUN      ] ByteswapTest.swap_byte32
[      OK ] ByteswapTest.swap_byte32 (0 ms)
[ RUN      ] ByteswapTest.swap_byte16
[      OK ] ByteswapTest.swap_byte16 (0 ms)
[ RUN      ] ByteswapTest.swap_byte
[      OK ] ByteswapTest.swap_byte (0 ms)
[ RUN      ] ByteswapTest.htog
[      OK ] ByteswapTest.htog (0 ms)
[ RUN      ] ByteswapTest.gtoh
[      OK ] ByteswapTest.gtoh (0 ms)
[ RUN      ] ByteswapTest.betole
[      OK ] ByteswapTest.betole (0 ms)
[ RUN      ] ByteswapTest.letobe
[      OK ] ByteswapTest.letobe (0 ms)
[--] 8 tests from ByteswapTest (21 ms total)

[--] Global test environment tear-down
[==] 8 tests from 1 test suite ran. (23 ms total)
[  PASSED  ] 8 tests.
[      OK ] UncontendedMutex.Lock (213 ms)
[ RUN      ] UncontendedMutex.HeavyContention
build/NULL/sim/guest_abi.test.debug 
--gtest_output=xml:build/NULL/unittests.debug/sim/guest_abi.test.xml
build/NULL/s

[gem5-dev] Re: Build failed in Jenkins: Nightly #211

[Daniel Carvalho via gem5-dev]

 Fix here: https://gem5-review.googlesource.com/c/public/gem5/+/40835
Bonus fix (not run by any CI): 
https://gem5-review.googlesource.com/c/public/gem5/+/40836/1Em sábado, 6 de 
fevereiro de 2021 21:19:30 BRT, jenkins-no-reply--- via gem5-dev 
 escreveu:  
 
 See 

Changes:

[odanrc] base: Fix storage params safe_cast

[odanrc] base: Initialize storage params on constructor

[gabe.black] arch,sim: Add a UintPtr type to the ABI types for GuestABI.

[gabe.black] sim: Add a void * analogue to VPtr.

[shingarov] arch-power: Restore consistency with other platforms

[gabe.black] tests,base: Delete the SymbolTable::load method and symtest test.


--
[...truncated 304.76 KB...]
[ RUN      ] CyclesTest.ShiftRight
[      OK ] CyclesTest.ShiftRight (0 ms)
[ RUN      ] CyclesTest.ShiftLeft
[      OK ] CyclesTest.ShiftLeft (0 ms)
[ RUN      ] CyclesTest.OutStream
[      OK ] CyclesTest.OutStream (0 ms)
[--] 10 tests from CyclesTest (5 ms total)

[--] 5 tests from MicroPCTest
[ RUN      ] MicroPCTest.CheckMicroPCRomBit
[      OK ] MicroPCTest.CheckMicroPCRomBit (0 ms)
[ RUN      ] MicroPCTest.RomMicroPCTest
[      OK ] MicroPCTest.RomMicroPCTest (0 ms)
[ RUN      ] MicroPCTest.NormalMicroPCTest
[      OK ] MicroPCTest.NormalMicroPCTest (0 ms)
[ RUN      ] MicroPCTest.IsRomMicroPCTest
[      OK ] MicroPCTest.IsRomMicroPCTest (0 ms)
[ RUN      ] MicroPCTest.IsNotRomMicroPCTest
[      OK ] MicroPCTest.IsNotRomMicroPCTest (0 ms)
[--] 5 tests from MicroPCTest (2 ms total)

[--] 4 tests from TypesTest
[ RUN      ] TypesTest.FloatToBits32
[      OK ] TypesTest.FloatToBits32 (0 ms)
[ RUN      ] TypesTest.floatToBits64
[      OK ] TypesTest.floatToBits64 (0 ms)
[ RUN      ] TypesTest.floatsToBitsDoubleInput
[      OK ] TypesTest.floatsToBitsDoubleInput (0 ms)
[ RUN      ] TypesTest.floatsToBitsFloatInput
[      OK ] TypesTest.floatsToBitsFloatInput (0 ms)
[--] 4 tests from TypesTest (2 ms total)

[--] Global test environment tear-down
[==] 19 tests from 3 test suites ran. (34 ms total)
[  PASSED  ] 19 tests.
build/NULL/sim/byteswap.test.fast 
--gtest_output=xml:build/NULL/unittests.fast/sim/byteswap.test.xml
Running main() from build/googletest/googletest/src/gtest_main.cc
[==] Running 8 tests from 1 test suite.
[--] Global test environment set-up.
[--] 8 tests from ByteswapTest
[ RUN      ] ByteswapTest.swap_byte64
[      OK ] ByteswapTest.swap_byte64 (0 ms)
[ RUN      ] ByteswapTest.swap_byte32
[      OK ] ByteswapTest.swap_byte32 (0 ms)
[ RUN      ] ByteswapTest.swap_byte16
[      OK ] ByteswapTest.swap_byte16 (0 ms)
[ RUN      ] ByteswapTest.swap_byte
[      OK ] ByteswapTest.swap_byte (0 ms)
[ RUN      ] ByteswapTest.htog
[      OK ] ByteswapTest.htog (0 ms)
[ RUN      ] ByteswapTest.gtoh
[      OK ] ByteswapTest.gtoh (0 ms)
[ RUN      ] ByteswapTest.betole
[      OK ] ByteswapTest.betole (0 ms)
[ RUN      ] ByteswapTest.letobe
[      OK ] ByteswapTest.letobe (0 ms)
[--] 8 tests from ByteswapTest (1 ms total)

[--] Global test environment tear-down
[      OK ] UncontendedMutex.Lock (212 ms)
[ RUN      ] UncontendedMutex.HeavyContention
 [    LINK]  -> NULL/sim/guest_abi.test.fast.unstripped
[==] 8 tests from 1 test suite ran. (1 ms total)
[  PASSED  ] 8 tests.
 [    CXX] NULL/sim/proxy_ptr.test.cc -> .fo
[      OK ] UncontendedMutex.HeavyContention (441 ms)
[--] 2 tests from UncontendedMutex (653 ms total)

[--] Global test environment tear-down
[==] 2 tests from 1 test suite ran. (653 ms total)
[  PASSED  ] 2 tests.
 [    LINK]  -> NULL/base/stats/storage.test.fast.unstripped
 [  STRIP] NULL/sim/guest_abi.test.fast.unstripped -> .fast
build/NULL/sim/guest_abi.test.fast 
--gtest_output=xml:build/NULL/unittests.fast/sim/guest_abi.test.xml
Running main() from build/googletest/googletest/src/gtest_main.cc
[==] Running 7 tests from 1 test suite.
[--] Global test environment set-up.
[--] 7 tests from GuestABI
[ RUN      ] GuestABI.ABI_1D_args
[      OK ] GuestABI.ABI_1D_args (0 ms)
[ RUN      ] GuestABI.ABI_Prepare
[      OK ] GuestABI.ABI_Prepare (0 ms)
[ RUN      ] GuestABI.ABI_2D_args
[      OK ] GuestABI.ABI_2D_args (0 ms)
[ RUN      ] GuestABI.ABI_TC_init
[      OK ] GuestABI.ABI_TC_init (0 ms)
[ RUN      ] GuestABI.ABI_returns
[      OK ] GuestABI.ABI_returns (0 ms)
[ RUN      ] GuestABI.dumpSimcall
[      OK ] GuestABI.dumpSimcall (0 ms)
[ RUN      ] GuestABI.isVarArgs
[      OK ] GuestABI.isVarArgs (0 ms)
[--] 7 tests from GuestABI (0 ms total)

[--] Global test environment tear-down
[==] 7 tests from 1 test suite ran. (0 ms total)
[  PASSED  ] 7 tests.
 [  STRIP] NULL/base/stats/storage.test.fast.unstripped -> .fast
build/NULL/base/stats/storage.test.fast 
--gtest_output=xml:build/NULL/unittests.fast/base/stats/storage.test.xml
Run

[gem5-dev] Re: RFC: run python Black on gem5 python code

[Daniel Carvalho via gem5-dev]

 +1

Em quarta-feira, 3 de março de 2021 14:35:57 BRT, Jason Lowe-Power via 
gem5-dev  escreveu:  
 
 Hi all,
Right now, we don't have an official style guide for python. Our style guide 
(http://www.gem5.org/documentation/general_docs/development/coding_style/) is 
very C++ focused.
I would like to propose adopting a relatively strict PEP 8 style guide: 
https://www.python.org/dev/peps/pep-0008. This is the "official" style guide 
for python (as much as there is anything official). I say "relatively strict" 
to mean that we will limit our exceptions *as much as possible*.
To implement this, Andreas S. recently pointed me to the "Black" package 
(https://pypi.org/project/black/) which automatically fixes code style. I just 
tried it out with gem5art (patch coming soon) and found that it works really 
well. The only downside is that it's not configurable at all. Adding special 
cases would be almost impossible.
Concrete and specific proposal:- Adopt PEP 8 as our official style guide- Use 
black to reformat all python code in src/- Use black to reformat code in 
configs/- Use black to reformat other python code
- Use black as part of our commit hook to make sure all future python is 
formatted to PEP 8
Let me know what you think!
Cheers,Jason
___
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