[gem5-dev] Change in gem5/gem5[develop]: arch-power: Use 64-bit registers and operands

2021-04-15 Thread Boris Shingarov (Gerrit) via gem5-dev 
Boris Shingarov has submitted this change. (  
https://gem5-review.googlesource.com/c/public/gem5/+/40881 )


Change subject: arch-power: Use 64-bit registers and operands
..

arch-power: Use 64-bit registers and operands

This increases the width of the general-purpose registers
and some of the special purpose registers to 64 bits in
accordance with recent versions of the Power ISA. This
allows the registers to be used for both 32-bit and 64-bit
execution modes.

It should be noted that in 32-bit mode, the use of upper
word is dependent on the instruction being executed and in
some cases, this may be undefined.

Change-Id: I2a5865a66e4ceab45e42a833d425abdd6bd6bf55
Signed-off-by: Sandipan Das 
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40881
Tested-by: kokoro 
Reviewed-by: Gabe Black 
Reviewed-by: Boris Shingarov 
Maintainer: Bobby R. Bruce 
---
M src/arch/power/isa/operands.isa
1 file changed, 10 insertions(+), 10 deletions(-)

Approvals:
  Boris Shingarov: Looks good to me, approved
  Gabe Black: Looks good to me, approved
  Bobby R. Bruce: Looks good to me, approved
  kokoro: Regressions pass



diff --git a/src/arch/power/isa/operands.isa  
b/src/arch/power/isa/operands.isa

index e77fde2..07415ba 100644
--- a/src/arch/power/isa/operands.isa
+++ b/src/arch/power/isa/operands.isa
@@ -41,10 +41,10 @@

 def operands {{
 # General Purpose Integer Reg Operands
-'Ra': ('IntReg', 'uw', 'RA', 'IsInteger', 1),
-'Rb': ('IntReg', 'uw', 'RB', 'IsInteger', 2),
-'Rs': ('IntReg', 'uw', 'RS', 'IsInteger', 3),
-'Rt': ('IntReg', 'uw', 'RT', 'IsInteger', 4),
+'Ra': ('IntReg', 'ud', 'RA', 'IsInteger', 1),
+'Rb': ('IntReg', 'ud', 'RB', 'IsInteger', 2),
+'Rs': ('IntReg', 'ud', 'RS', 'IsInteger', 3),
+'Rt': ('IntReg', 'ud', 'RT', 'IsInteger', 4),

 # General Purpose Floating Point Reg Operands
 'Fa': ('FloatReg', 'df', 'FRA', 'IsFloating', 1),
@@ -54,16 +54,16 @@
 'Ft': ('FloatReg', 'df', 'FRT', 'IsFloating', 5),

 # Memory Operand
-'Mem': ('Mem', 'uw', None, (None, 'IsLoad', 'IsStore'), 8),
+'Mem': ('Mem', 'ud', None, (None, 'IsLoad', 'IsStore'), 8),

 # Program counter and next
-'CIA': ('PCState', 'uw', 'pc', (None, None, 'IsControl'), 9),
-'NIA': ('PCState', 'uw', 'npc', (None, None, 'IsControl'), 9),
+'CIA': ('PCState', 'ud', 'pc', (None, None, 'IsControl'), 9),
+'NIA': ('PCState', 'ud', 'npc', (None, None, 'IsControl'), 9),

 # Control registers
 'CR': ('IntReg', 'uw', 'INTREG_CR', 'IsInteger', 9),
-'LR': ('IntReg', 'uw', 'INTREG_LR', 'IsInteger', 9),
-'CTR': ('IntReg', 'uw', 'INTREG_CTR', 'IsInteger', 9),
+'LR': ('IntReg', 'ud', 'INTREG_LR', 'IsInteger', 9),
+'CTR': ('IntReg', 'ud', 'INTREG_CTR', 'IsInteger', 9),
 'XER': ('IntReg', 'uw', 'INTREG_XER', 'IsInteger', 9),

 # Setting as IntReg so things are stored as an integer, not double
@@ -72,5 +72,5 @@
 # Registers for linked loads and stores
 'Rsv': ('IntReg', 'uw', 'INTREG_RSV', 'IsInteger', 9),
 'RsvLen': ('IntReg', 'uw', 'INTREG_RSV_LEN', 'IsInteger', 9),
-'RsvAddr': ('IntReg', 'uw', 'INTREG_RSV_ADDR', 'IsInteger', 9),
+'RsvAddr': ('IntReg', 'ud', 'INTREG_RSV_ADDR', 'IsInteger', 9),
 }};



3 is the latest approved patch-set.
No files were changed between the latest approved patch-set and the  
submitted one.

--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/40881
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: I2a5865a66e4ceab45e42a833d425abdd6bd6bf55
Gerrit-Change-Number: 40881
Gerrit-PatchSet: 5
Gerrit-Owner: Sandipan Das 
Gerrit-Reviewer: Bobby R. Bruce 
Gerrit-Reviewer: Boris Shingarov 
Gerrit-Reviewer: Gabe Black 
Gerrit-Reviewer: kokoro 
Gerrit-CC: lkcl 
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: tutorial docs

2021-04-15 Thread Gabe Black via gem5-dev 
If you (or the documentation) expect things to work in a particular way,
one thing I've seen in some technical books I've read is that the examples
they have in the text are actually runnable, and they have a process which
goes through and runs them to make sure they work. Alternatively (and more
simply), you could just write unit tests which do what's in the
documentation, and if something changes then either that will be updated or
kokoro will reject the change. If you want something to keep working, it's
wise to write a test for it.

Gabe

On Thu, Apr 15, 2021 at 1:58 PM mike upton via gem5-dev 
wrote:

>
> I have verified that the tutorial works in its original form on 20.0.0.3
> and in its new form on 20.1.0.5
>
> It segfaults on the current stable master: 21.0.0.0
>
>
>
> On Thu, Apr 15, 2021 at 8:18 AM Jason Lowe-Power 
> wrote:
>
>> Hi Mike,
>>
>> It's a bit embarrassing how out of date our documentation is.
>> Unfortunately, we have a really hard time finding the resources or
>> convincing developers to update the documentation as the code changes.
>>
>> The canonical documentation can be found here:
>> http://www.gem5.org/documentation/
>> and the Learning gem5 material here:
>> http://www.gem5.org/documentation/learning_gem5/introduction/
>>
>> There's definitely mistakes and things that have changed. We would
>> greatly appreciate contributions. The code is available here:
>> https://gem5.googlesource.com/public/gem5-website/+/refs/heads/stable/
>> and it's reviewed the same way as regular gem5 code.
>>
>> Let me know if you have any questions about contributing, etc.
>>
>> Cheers,
>> Jason
>>
>> On Thu, Apr 15, 2021 at 8:04 AM mike upton via gem5-dev <
>> gem5-dev@gem5.org> wrote:
>>
>>> Hi,
>>> do we (I) have edit permissions on the tutorial documentation?
>>>
>>> I tried to follow the first steps of the tutorial, and the instructions
>>> are out of date for the develop head. Some googling resulted in the
>>> solution, but for me it still does not execute correctly.
>>>
>>> It looks like there are Jira issues documenting the needed updates.
>>>
>>> I have some issue where the tutorial is segfaulting.
>>>
>>> Can someone else verify that the tutorial actually works?
>>> ___
>>> 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] Change in gem5/gem5[develop]: arch-power: Refactor CR field generation

2021-04-15 Thread Boris Shingarov (Gerrit) via gem5-dev 
Boris Shingarov has submitted this change. (  
https://gem5-review.googlesource.com/c/public/gem5/+/42943 )


Change subject: arch-power: Refactor CR field generation
..

arch-power: Refactor CR field generation

This splits the existing makeCRField utility into signed
and unsigned variants to help callers avoid confusion.
The CR bit union is also used to clean up the underlying
bit setting logic.

Change-Id: I2aa6ec0666d2bc5096eb6c775cc47f2a5a0621ee
Signed-off-by: Sandipan Das 
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/42943
Tested-by: kokoro 
Reviewed-by: Gabe Black 
Maintainer: Bobby R. Bruce 
---
M src/arch/power/insts/integer.hh
M src/arch/power/isa/decoder.isa
M src/arch/power/isa/formats/integer.isa
3 files changed, 21 insertions(+), 19 deletions(-)

Approvals:
  Gabe Black: Looks good to me, approved
  Bobby R. Bruce: Looks good to me, approved
  kokoro: Regressions pass



diff --git a/src/arch/power/insts/integer.hh  
b/src/arch/power/insts/integer.hh

index 1c9b1cc..1771fea 100644
--- a/src/arch/power/insts/integer.hh
+++ b/src/arch/power/insts/integer.hh
@@ -65,28 +65,30 @@

 /* Compute the CR (condition register) field using signed comparison */
 inline uint32_t
-makeCRField(int32_t a, int32_t b, uint32_t xerSO) const
+makeCRFieldSigned(int64_t a, int64_t b, bool so) const
 {
-uint32_t c = xerSO;
+Cr cr = 0;

-/* We've pre-shifted the immediate values here */
-if (a < b)  { c += 0x8; }
-else if (a > b) { c += 0x4; }
-else{ c += 0x2; }
-return c;
+if (a < b)  { cr.cr0.lt = 1; }
+else if (a > b) { cr.cr0.gt = 1; }
+else{ cr.cr0.eq = 1; }
+if (so) { cr.cr0.so = 1; }
+
+return cr.cr0;
 }

 /* Compute the CR (condition register) field using unsigned comparison  
*/

 inline uint32_t
-makeCRField(uint32_t a, uint32_t b, uint32_t xerSO) const
+makeCRFieldUnsigned(uint64_t a, uint64_t b, bool so) const
 {
-uint32_t c = xerSO;
+Cr cr = 0;

-/* We've pre-shifted the immediate values here */
-if (a < b)  { c += 0x8; }
-else if (a > b) { c += 0x4; }
-else{ c += 0x2; }
-return c;
+if (a < b)  { cr.cr0.lt = 1; }
+else if (a > b) { cr.cr0.gt = 1; }
+else{ cr.cr0.eq = 1; }
+if (so) { cr.cr0.so = 1; }
+
+return cr.cr0;
 }

 std::string generateDisassembly(
diff --git a/src/arch/power/isa/decoder.isa b/src/arch/power/isa/decoder.isa
index f32861b..7f22d8c 100644
--- a/src/arch/power/isa/decoder.isa
+++ b/src/arch/power/isa/decoder.isa
@@ -39,12 +39,12 @@
 format IntImmOp {
 10: cmpli({{
 Xer xer = XER;
-uint32_t cr = makeCRField(Ra, (uint32_t)uimm, xer.so);
+uint32_t cr = makeCRFieldUnsigned(Ra_uw, uimm, xer.so);
 CR = insertCRField(CR, BF, cr);
 }});
 11: cmpi({{
 Xer xer = XER;
-uint32_t cr = makeCRField(Ra_sw, (int32_t)imm, xer.so);
+uint32_t cr = makeCRFieldSigned(Ra_sw, imm, xer.so);
 CR = insertCRField(CR, BF, cr);
 }});
 }
@@ -250,12 +250,12 @@
 format IntOp {
 0: cmp({{
 Xer xer = XER;
-uint32_t cr = makeCRField(Ra_sw, Rb_sw, xer.so);
+uint32_t cr = makeCRFieldSigned(Ra_sw, Rb_sw, xer.so);
 CR = insertCRField(CR, BF, cr);
 }});
 32: cmpl({{
 Xer xer = XER;
-uint32_t cr = makeCRField(Ra, Rb, xer.so);
+uint32_t cr = makeCRFieldUnsigned(Ra_uw, Rb_uw, xer.so);
 CR = insertCRField(CR, BF, cr);
 }});
 144: mtcrf({{
diff --git a/src/arch/power/isa/formats/integer.isa  
b/src/arch/power/isa/formats/integer.isa

index 50badce..0ed0bf02 100644
--- a/src/arch/power/isa/formats/integer.isa
+++ b/src/arch/power/isa/formats/integer.isa
@@ -77,7 +77,7 @@

 computeCR0Code = '''
 Cr cr = CR;
-cr.cr0 = makeCRField((int32_t)%(result)s, (int32_t)0, xer.so);
+cr.cr0 = makeCRFieldSigned(%(result)s, 0, xer.so);
 CR = cr;
 '''




2 is the latest approved patch-set.
No files were changed between the latest approved patch-set and the  
submitted one.

--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/42943
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: I2aa6ec0666d2bc5096eb6c775cc47f2a5a0621ee
Gerrit-Change-Number: 42943
Gerrit-PatchSet: 5
Gerrit-Owner: Sandipan Das 
Gerrit-Reviewer: Bobby R. Bruce 
Gerrit-Reviewer: Boris Shingarov 
Gerrit-Reviewer: Gabe Black 
Gerrit-Reviewer: kokoro 
Gerrit-MessageType: merged

[gem5-dev] Change in gem5/gem5[develop]: systemc: Extend TlmBridges to 512 bits

2021-04-15 Thread Yu-hsin Wang (Gerrit) via gem5-dev 
Yu-hsin Wang has uploaded this change for review. (  
https://gem5-review.googlesource.com/c/public/gem5/+/44528 )



Change subject: systemc: Extend TlmBridges to 512 bits
..

systemc: Extend TlmBridges to 512 bits

Change-Id: I41763743974665e78ff05203d6ad2b8ac14ad625
---
M src/systemc/tlm_bridge/TlmBridge.py
M src/systemc/tlm_bridge/gem5_to_tlm.cc
M src/systemc/tlm_bridge/tlm_to_gem5.cc
3 files changed, 96 insertions(+), 0 deletions(-)



diff --git a/src/systemc/tlm_bridge/TlmBridge.py  
b/src/systemc/tlm_bridge/TlmBridge.py

index 0a2aaa7..9238535 100644
--- a/src/systemc/tlm_bridge/TlmBridge.py
+++ b/src/systemc/tlm_bridge/TlmBridge.py
@@ -68,6 +68,30 @@

 tlm = TlmInitiatorSocket(64, 'TLM initiator socket')

+class Gem5ToTlmBridge128(Gem5ToTlmBridgeBase):
+type = 'Gem5ToTlmBridge128'
+cxx_template_params = [ 'unsigned int BITWIDTH' ]
+cxx_class = 'sc_gem5::Gem5ToTlmBridge<128>'
+cxx_header = 'systemc/tlm_bridge/gem5_to_tlm.hh'
+
+tlm = TlmInitiatorSocket(128, 'TLM initiator socket')
+
+class Gem5ToTlmBridge256(Gem5ToTlmBridgeBase):
+type = 'Gem5ToTlmBridge256'
+cxx_template_params = [ 'unsigned int BITWIDTH' ]
+cxx_class = 'sc_gem5::Gem5ToTlmBridge<256>'
+cxx_header = 'systemc/tlm_bridge/gem5_to_tlm.hh'
+
+tlm = TlmInitiatorSocket(256, 'TLM initiator socket')
+
+class Gem5ToTlmBridge512(Gem5ToTlmBridgeBase):
+type = 'Gem5ToTlmBridge512'
+cxx_template_params = [ 'unsigned int BITWIDTH' ]
+cxx_class = 'sc_gem5::Gem5ToTlmBridge<512>'
+cxx_header = 'systemc/tlm_bridge/gem5_to_tlm.hh'
+
+tlm = TlmInitiatorSocket(512, 'TLM initiator socket')
+

 class TlmToGem5Bridge32(TlmToGem5BridgeBase):
 type = 'TlmToGem5Bridge32'
@@ -84,3 +108,27 @@
 cxx_header = 'systemc/tlm_bridge/tlm_to_gem5.hh'

 tlm = TlmTargetSocket(64, 'TLM target socket')
+
+class TlmToGem5Bridge128(TlmToGem5BridgeBase):
+type = 'TlmToGem5Bridge128'
+cxx_template_params = [ 'unsigned int BITWIDTH' ]
+cxx_class = 'sc_gem5::TlmToGem5Bridge<128>'
+cxx_header = 'systemc/tlm_bridge/tlm_to_gem5.hh'
+
+tlm = TlmTargetSocket(128, 'TLM target socket')
+
+class TlmToGem5Bridge256(TlmToGem5BridgeBase):
+type = 'TlmToGem5Bridge256'
+cxx_template_params = [ 'unsigned int BITWIDTH' ]
+cxx_class = 'sc_gem5::TlmToGem5Bridge<256>'
+cxx_header = 'systemc/tlm_bridge/tlm_to_gem5.hh'
+
+tlm = TlmTargetSocket(256, 'TLM target socket')
+
+class TlmToGem5Bridge512(TlmToGem5BridgeBase):
+type = 'TlmToGem5Bridge512'
+cxx_template_params = [ 'unsigned int BITWIDTH' ]
+cxx_class = 'sc_gem5::TlmToGem5Bridge<512>'
+cxx_header = 'systemc/tlm_bridge/tlm_to_gem5.hh'
+
+tlm = TlmTargetSocket(512, 'TLM target socket')
diff --git a/src/systemc/tlm_bridge/gem5_to_tlm.cc  
b/src/systemc/tlm_bridge/gem5_to_tlm.cc

index b80a083..4ac722a 100644
--- a/src/systemc/tlm_bridge/gem5_to_tlm.cc
+++ b/src/systemc/tlm_bridge/gem5_to_tlm.cc
@@ -62,6 +62,9 @@

 #include "params/Gem5ToTlmBridge32.hh"
 #include "params/Gem5ToTlmBridge64.hh"
+#include "params/Gem5ToTlmBridge128.hh"
+#include "params/Gem5ToTlmBridge256.hh"
+#include "params/Gem5ToTlmBridge512.hh"
 #include "sim/system.hh"
 #include "systemc/tlm_bridge/sc_ext.hh"
 #include "systemc/tlm_bridge/sc_mm.hh"
@@ -517,3 +520,24 @@
 return new sc_gem5::Gem5ToTlmBridge<64>(
 *this, sc_core::sc_module_name(name.c_str()));
 }
+
+sc_gem5::Gem5ToTlmBridge<128> *
+Gem5ToTlmBridge128Params::create() const
+{
+return new sc_gem5::Gem5ToTlmBridge<128>(
+*this, sc_core::sc_module_name(name.c_str()));
+}
+
+sc_gem5::Gem5ToTlmBridge<256> *
+Gem5ToTlmBridge256Params::create() const
+{
+return new sc_gem5::Gem5ToTlmBridge<256>(
+*this, sc_core::sc_module_name(name.c_str()));
+}
+
+sc_gem5::Gem5ToTlmBridge<512> *
+Gem5ToTlmBridge512Params::create() const
+{
+return new sc_gem5::Gem5ToTlmBridge<512>(
+*this, sc_core::sc_module_name(name.c_str()));
+}
diff --git a/src/systemc/tlm_bridge/tlm_to_gem5.cc  
b/src/systemc/tlm_bridge/tlm_to_gem5.cc

index 143eeac..36809d3 100644
--- a/src/systemc/tlm_bridge/tlm_to_gem5.cc
+++ b/src/systemc/tlm_bridge/tlm_to_gem5.cc
@@ -61,6 +61,9 @@

 #include "params/TlmToGem5Bridge32.hh"
 #include "params/TlmToGem5Bridge64.hh"
+#include "params/TlmToGem5Bridge128.hh"
+#include "params/TlmToGem5Bridge256.hh"
+#include "params/TlmToGem5Bridge512.hh"
 #include "sim/system.hh"
 #include "systemc/ext/core/sc_module_name.hh"
 #include "systemc/ext/core/sc_time.hh"
@@ -558,3 +561,24 @@
 return new sc_gem5::TlmToGem5Bridge<64>(
 *this, sc_core::sc_module_name(name.c_str()));
 }
+
+sc_gem5::TlmToGem5Bridge<128> *
+TlmToGem5Bridge128Params::create() const
+{
+return new sc_gem5::TlmToGem5Bridge<128>(
+*this, sc_core::sc_module_name(name.c_str()));
+}
+
+sc_gem5::TlmToGem5Bridge<256> *
+TlmToGem5Bridge256Params::create() const
+{
+return

[gem5-dev] Re: tutorial docs

2021-04-15 Thread mike upton via gem5-dev 
I have verified that the tutorial works in its original form on 20.0.0.3
and in its new form on 20.1.0.5

It segfaults on the current stable master: 21.0.0.0



On Thu, Apr 15, 2021 at 8:18 AM Jason Lowe-Power 
wrote:

> Hi Mike,
>
> It's a bit embarrassing how out of date our documentation is.
> Unfortunately, we have a really hard time finding the resources or
> convincing developers to update the documentation as the code changes.
>
> The canonical documentation can be found here:
> http://www.gem5.org/documentation/
> and the Learning gem5 material here:
> http://www.gem5.org/documentation/learning_gem5/introduction/
>
> There's definitely mistakes and things that have changed. We would greatly
> appreciate contributions. The code is available here:
> https://gem5.googlesource.com/public/gem5-website/+/refs/heads/stable/
> and it's reviewed the same way as regular gem5 code.
>
> Let me know if you have any questions about contributing, etc.
>
> Cheers,
> Jason
>
> On Thu, Apr 15, 2021 at 8:04 AM mike upton via gem5-dev 
> wrote:
>
>> Hi,
>> do we (I) have edit permissions on the tutorial documentation?
>>
>> I tried to follow the first steps of the tutorial, and the instructions
>> are out of date for the develop head. Some googling resulted in the
>> solution, but for me it still does not execute correctly.
>>
>> It looks like there are Jira issues documenting the needed updates.
>>
>> I have some issue where the tutorial is segfaulting.
>>
>> Can someone else verify that the tutorial actually works?
>> ___
>> 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] Change in gem5/gem5[develop]: gpu-compute: Topology and driver changes for dGPU

2021-04-15 Thread Alex Dutu (Gerrit) via gem5-dev 
Alex Dutu has submitted this change. (  
https://gem5-review.googlesource.com/c/public/gem5/+/42214 )


Change subject: gpu-compute: Topology and driver changes for dGPU
..

gpu-compute: Topology and driver changes for dGPU

New topology ripped from Fiji to support dGPU.  A dGPU flag is added to
the config which is propogated to the driver.  The emulated driver is
now able to properly deal with dGPU ioctls and mmaps.  For now, dGPU
physical memory is allocated from the host, but this is easy to change
once we get a GPU memory controller up and running.

Change-Id: I594418482b12ec8fb2e4018d8d0371d56f4f51c8
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/42214
Reviewed-by: Matt Sinclair 
Maintainer: Matt Sinclair 
Tested-by: kokoro 
---
M configs/example/apu_se.py
M configs/example/hsaTopology.py
M src/dev/hsa/hsa_driver.cc
M src/gpu-compute/GPU.py
M src/gpu-compute/gpu_compute_driver.cc
M src/gpu-compute/gpu_compute_driver.hh
6 files changed, 329 insertions(+), 27 deletions(-)

Approvals:
  Matt Sinclair: Looks good to me, approved; Looks good to me, approved
  kokoro: Regressions pass



diff --git a/configs/example/apu_se.py b/configs/example/apu_se.py
index feed8a7..baf9360 100644
--- a/configs/example/apu_se.py
+++ b/configs/example/apu_se.py
@@ -182,6 +182,13 @@
 parser.add_option("--reg-alloc-policy",type="string", default="simple",
   help="register allocation policy (simple/dynamic)")

+parser.add_option("--dgpu", action="store_true", default=False,
+  help="Configure the system as a dGPU instead of an APU. "
+  "The dGPU config has its own local memory pool and is  
not "

+  "coherent with the host through hardware.  Data is "
+  "transfered from host to device memory using runtime  
calls "

+  "that copy data over a PCIe-like IO bus.")
+
 Ruby.define_options(parser)

 #add TLB options to the parser
@@ -417,7 +424,7 @@
 hsapp_gpu_map_paddr = int(Addr(options.mem_size))

 # HSA kernel mode driver
-gpu_driver = GPUComputeDriver(filename="kfd")
+gpu_driver = GPUComputeDriver(filename = "kfd", isdGPU = options.dgpu)

 # Creating the GPU kernel launching components: that is the HSA
 # packet processor (HSAPP), GPU command processor (CP), and the
@@ -470,7 +477,15 @@
"/usr/lib/x86_64-linux-gnu"
]),
'HOME=%s' % os.getenv('HOME','/'),
-   "HSA_ENABLE_INTERRUPT=1"]
+   # Disable the VM fault handler signal creation for dGPUs also
+   # forces the use of DefaultSignals instead of driver-controlled
+   # InteruptSignals throughout the runtime.  DefaultSignals poll
+   # on memory in the runtime, while InteruptSignals call into the
+   # driver.
+   "HSA_ENABLE_INTERRUPT=1",
+   # We don't have an SDMA hardware model, so need to fallback to
+   # vector copy kernels for dGPU memcopies to/from host and  
device.

+   "HSA_ENABLE_SDMA=0"]

 process = Process(executable = executable, cmd = [options.cmd]
   + options.options.split(), drivers = [gpu_driver], env =  
env)

@@ -643,7 +658,12 @@

 root = Root(system=system, full_system=False)

-hsaTopology.createHsaTopology(options)
+# Create the /sys/devices filesystem for the simulator so that the HSA  
Runtime

+# knows what type of GPU hardware we are simulating
+if options.dgpu:
+hsaTopology.createFijiTopology(options)
+else:
+hsaTopology.createCarrizoTopology(options)

 m5.ticks.setGlobalFrequency('1THz')
 if options.abs_max_tick:
diff --git a/configs/example/hsaTopology.py b/configs/example/hsaTopology.py
index 707a83d..a5e0d44 100644
--- a/configs/example/hsaTopology.py
+++ b/configs/example/hsaTopology.py
@@ -49,7 +49,177 @@
 rmtree(path)
 makedirs(path)

-def createHsaTopology(options):
+# This fakes out a dGPU setup so the runtime correctly operations.  The  
spoofed

+# system has a single dGPU and a single socket CPU.  Note that more complex
+# topologies (multi-GPU, multi-socket CPUs) need to have a different setup
+# here or the runtime won't be able to issue Memcpies from one node to  
another.

+#
+# TODO: There is way too much hardcoded here.  It doesn't effect anything  
in
+# our current ROCm stack (1.6), but it is highly possible that it will in  
the

+# future.  We might need to scrub through this and extract the appropriate
+# fields from the simulator in the future.
+def createFijiTopology(options):
+topology_dir = joinpath(m5.options.outdir, \
+'fs/sys/devices/virtual/kfd/kfd/topology')
+remake_dir(topology_dir)
+
+amdgpu_dir = joinpath(m5.options.outdir, \
+'fs/sys/module/amdgpu/parameters')
+remake_dir(amdgpu_dir)
+
+# Fiji reported VM size in GB.  Used to reserve an allocation from CPU
+# to implement SVM (i.e. GPUVM64 pointers and X86 pointers agree)
+

[gem5-dev] Re: tutorial docs

2021-04-15 Thread Jason Lowe-Power via gem5-dev 
Hi Mike,

It's a bit embarrassing how out of date our documentation is.
Unfortunately, we have a really hard time finding the resources or
convincing developers to update the documentation as the code changes.

The canonical documentation can be found here:
http://www.gem5.org/documentation/
and the Learning gem5 material here:
http://www.gem5.org/documentation/learning_gem5/introduction/

There's definitely mistakes and things that have changed. We would greatly
appreciate contributions. The code is available here:
https://gem5.googlesource.com/public/gem5-website/+/refs/heads/stable/ and
it's reviewed the same way as regular gem5 code.

Let me know if you have any questions about contributing, etc.

Cheers,
Jason

On Thu, Apr 15, 2021 at 8:04 AM mike upton via gem5-dev 
wrote:

> Hi,
> do we (I) have edit permissions on the tutorial documentation?
>
> I tried to follow the first steps of the tutorial, and the instructions
> are out of date for the develop head. Some googling resulted in the
> solution, but for me it still does not execute correctly.
>
> It looks like there are Jira issues documenting the needed updates.
>
> I have some issue where the tutorial is segfaulting.
>
> Can someone else verify that the tutorial actually works?
> ___
> 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] tutorial docs

2021-04-15 Thread mike upton via gem5-dev 
Hi,
do we (I) have edit permissions on the tutorial documentation?

I tried to follow the first steps of the tutorial, and the instructions are
out of date for the develop head. Some googling resulted in the solution,
but for me it still does not execute correctly.

It looks like there are Jira issues documenting the needed updates.

I have some issue where the tutorial is segfaulting.

Can someone else verify that the tutorial actually works?
___
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] Jenkins build is back to normal : Compiler-Checks #59

2021-04-15 Thread jenkins-no-reply--- via gem5-dev 
See 

___
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]: fastmodel: Remove CortexA76 unpresented resource

2021-04-15 Thread Yu-hsin Wang (Gerrit) via gem5-dev 
Yu-hsin Wang has uploaded this change for review. (  
https://gem5-review.googlesource.com/c/public/gem5/+/44527 )



Change subject: fastmodel: Remove CortexA76 unpresented resource
..

fastmodel: Remove CortexA76 unpresented resource

Change-Id: I8fde5f90cca45df9430c5f4159fa6e8319ad12df
---
M src/arch/arm/fastmodel/CortexA76/thread_context.cc
1 file changed, 2 insertions(+), 2 deletions(-)



diff --git a/src/arch/arm/fastmodel/CortexA76/thread_context.cc  
b/src/arch/arm/fastmodel/CortexA76/thread_context.cc

index 44becd3..8b0b733 100644
--- a/src/arch/arm/fastmodel/CortexA76/thread_context.cc
+++ b/src/arch/arm/fastmodel/CortexA76/thread_context.cc
@@ -526,7 +526,7 @@
 { ArmISA::MISCREG_CNTV_CVAL, "CNTV_CVAL" },
 { ArmISA::MISCREG_CNTVOFF, "CNTVOFF" },
 { ArmISA::MISCREG_CNTHP_CVAL, "CNTHP_CVAL" },
-{ ArmISA::MISCREG_CPUMERRSR, "CPUMERRSR" },
+// ArmISA::MISCREG_CPUMERRSR?
 { ArmISA::MISCREG_L2MERRSR, "L2MERRSR" },

 // AArch64 registers (Op0=2)
@@ -810,7 +810,7 @@
 // ArmISA::MISCREG_L2ACTLR_EL1?
 { ArmISA::MISCREG_CPUACTLR_EL1, "CPUACTLR_EL1" },
 { ArmISA::MISCREG_CPUECTLR_EL1, "CPUECTLR_EL1" },
-{ ArmISA::MISCREG_CPUMERRSR_EL1, "CPUMERRSR_EL1" },
+// ArmISA::MISCREG_CPUMERRSR_EL1?
 { ArmISA::MISCREG_L2MERRSR_EL1, "L2MERRSR_EL1" },
 // ArmISA::MISCREG_CBAR_EL1?
 { ArmISA::MISCREG_CONTEXTIDR_EL2, "CONTEXTIDR_EL2" },

--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/44527
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: I8fde5f90cca45df9430c5f4159fa6e8319ad12df
Gerrit-Change-Number: 44527
Gerrit-PatchSet: 1
Gerrit-Owner: Yu-hsin Wang 
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

[gem5-dev] Re: gem5 namespace

2021-04-15 Thread Giacomo Travaglini via gem5-dev 
My vote goes to 1 and A as well

My sole argument is consistency; in general I'd rather start a namespace with a 
lowercase. So that when we have something
like a scope resolution we know we are dealing with a namespace and not a 
class. But that's off-topic.

Namespace names are anyway not covered by our coding style, so it's probably 
worth adding an entry.

https://www.gem5.org/documentation/general_docs/development/coding_style/

From a quick grep I can see most of our namespaces follow the PascalCase type, 
though there are some namespaces using snake_case convention.

Giacomo

> -Original Message-
> From: Gabe Black via gem5-dev 
> Sent: 15 April 2021 09:03
> To: gem5 Developer List 
> Cc: Gabe Black 
> Subject: [gem5-dev] Re: gem5 namespace
>
> My vote is for 1 and A.
>
> We have style rules for a reason, and that is because not following them
> causes technical problems like name collisions, and makes it less obvious
> when reading code what things are and what they're doing. It's a bit
> hypocritical to say that we should follow style rules and completely ignore
> the aesthetic rule when capitalizing GEM5_, but then say that the aesthetic
> rule should win when dealing with the namespace.
>
> This is further inconsistent with the Gem5Internal namespace, the Gem5
> class in SCons, the Gem5Op instruction format used for ARM, and the
> Gem5Imm constant used for ARM semihosting. It would also cause a collision
> with any variable called gem5, a completely legal and reasonable name to use,
> *especially* in code outside of gem5 which might be using it to refer to
> something related to gem5 which it is interacting with.
>
> There are no other instances where we let superficial aesthetic conventions
> like this overrule technical considerations. We don't add _tm to the end of
> trademarked names, we don't call AtomicSimpleCPU the atomic simple CPU
> since that's not a valid class name, and a hundred other examples of where
> prose takes a back seat because this is not prose, this is a conceptual 
> machine
> people happen to be able to read.
>
> Our website is the place for branding and identity and marketing, our code is
> not.
>
> Gabe
>
> On Wed, Apr 14, 2021 at 7:28 AM Jason Lowe-Power via gem5-dev  d...@gem5.org  > wrote:
>
>
> Thanks for putting this all together, Daniel!
>
> My opinion is the same as yours: option 2 and macro A.
>
> One other thing 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

[gem5-dev] Change in gem5/gem5[develop]: misc: Replace std::conditional with std::conditional_t

2021-04-15 Thread Giacomo Travaglini (Gerrit) via gem5-dev 
Giacomo Travaglini has submitted this change. (  
https://gem5-review.googlesource.com/c/public/gem5/+/44506 )


Change subject: misc: Replace std::conditional with std::conditional_t
..

misc: Replace std::conditional with std::conditional_t

Change-Id: I50d26d958d521c30b69d31426380b1e2e213a9e6
Signed-off-by: Giacomo Travaglini 
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/44506
Reviewed-by: Jason Lowe-Power 
Maintainer: Jason Lowe-Power 
Tested-by: kokoro 
---
M src/arch/amdgpu/vega/operand.hh
M src/arch/generic/vec_pred_reg.hh
M src/base/coroutine.hh
M src/base/refcnt.hh
4 files changed, 14 insertions(+), 14 deletions(-)

Approvals:
  Jason Lowe-Power: Looks good to me, approved; Looks good to me, approved
  kokoro: Regressions pass



diff --git a/src/arch/amdgpu/vega/operand.hh  
b/src/arch/amdgpu/vega/operand.hh

index 740fbb9..a4517ea 100644
--- a/src/arch/amdgpu/vega/operand.hh
+++ b/src/arch/amdgpu/vega/operand.hh
@@ -326,12 +326,12 @@
   scRegData.read();
   }

-  using VecRegCont = typename std::conditional-  VecRegContainerU64, typename  
std::conditional
+  using VecRegCont = typename std::conditional_t+  VecRegContainerU64, typename  
std::conditional_t
   == sizeof(VecElemU16), VecRegContainerU16,
-  typename std::conditional::type>::type>::type;
+  VecRegContainerU32>>>;

   /**
* whether this operand a scalar or not.
diff --git a/src/arch/generic/vec_pred_reg.hh  
b/src/arch/generic/vec_pred_reg.hh

index 46f6f2f..d156ba0 100644
--- a/src/arch/generic/vec_pred_reg.hh
+++ b/src/arch/generic/vec_pred_reg.hh
@@ -72,10 +72,10 @@

   public:
 /// Container type alias.
-using Container = typename std::conditional<
+using Container = typename std::conditional_t<
 Const,
 const VecPredRegContainer,
-VecPredRegContainer>::type;
+VecPredRegContainer>;

   protected:
 // Alias for this type
diff --git a/src/base/coroutine.hh b/src/base/coroutine.hh
index 68d2b1d..594c1e8 100644
--- a/src/base/coroutine.hh
+++ b/src/base/coroutine.hh
@@ -66,11 +66,11 @@
 // in case the channel should be void (Coroutine template parameters
 // are void. (See following ArgChannel, RetChannel typedef)
 struct Empty {};
-using ArgChannel = typename std::conditional<
-std::is_same::value, Empty, std::stack>::type;
+using ArgChannel = typename std::conditional_t<
+std::is_same::value, Empty, std::stack>;

-using RetChannel = typename std::conditional<
-std::is_same::value, Empty, std::stack>::type;
+using RetChannel = typename std::conditional_t<
+std::is_same::value, Empty, std::stack>;

   public:
 /**
diff --git a/src/base/refcnt.hh b/src/base/refcnt.hh
index 3106a6f..43a2a36 100644
--- a/src/base/refcnt.hh
+++ b/src/base/refcnt.hh
@@ -129,13 +129,13 @@
 /** Convenience aliases for const/non-const versions of T w/  
friendship. */

 /** @{ */
 static constexpr auto TisConst = std::is_const::value;
-using ConstT = typename std::conditional,
-RefCountingPtr::type>>::type;
+RefCountingPtr::type>>;
 friend ConstT;
-using NonConstT = typename std::conditional::type>,
-RefCountingPtr>::type;
+RefCountingPtr>;
 friend NonConstT;
 /** @} */
 /// The stored pointer.

--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/44506
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: I50d26d958d521c30b69d31426380b1e2e213a9e6
Gerrit-Change-Number: 44506
Gerrit-PatchSet: 2
Gerrit-Owner: Giacomo Travaglini 
Gerrit-Reviewer: Bobby R. Bruce 
Gerrit-Reviewer: Gabe Black 
Gerrit-Reviewer: Giacomo Travaglini 
Gerrit-Reviewer: Jason Lowe-Power 
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]: misc: Fix VecPredReg coding style

2021-04-15 Thread Giacomo Travaglini (Gerrit) via gem5-dev 
Giacomo Travaglini has submitted this change. (  
https://gem5-review.googlesource.com/c/public/gem5/+/44505 )


Change subject: misc: Fix VecPredReg coding style
..

misc: Fix VecPredReg coding style

* get_bits -> getBits
* set_bits -> setBits
* set_raw -> setRaw
* get_raw -> getRaw

Change-Id: I57c0217dc399b7e1c5b007ed862d7ed221d5ac0b
Signed-off-by: Giacomo Travaglini 
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/44505
Reviewed-by: Jason Lowe-Power 
Maintainer: Jason Lowe-Power 
Tested-by: kokoro 
---
M src/arch/arm/fastmodel/iris/thread_context.cc
M src/arch/arm/isa/insts/sve.isa
M src/arch/generic/vec_pred_reg.hh
3 files changed, 12 insertions(+), 12 deletions(-)

Approvals:
  Jason Lowe-Power: Looks good to me, approved; Looks good to me, approved
  kokoro: Regressions pass



diff --git a/src/arch/arm/fastmodel/iris/thread_context.cc  
b/src/arch/arm/fastmodel/iris/thread_context.cc

index 9567b11..b2173e1 100644
--- a/src/arch/arm/fastmodel/iris/thread_context.cc
+++ b/src/arch/arm/fastmodel/iris/thread_context.cc
@@ -693,13 +693,13 @@
 size_t num_bits = reg.NUM_BITS;
 uint8_t *bytes = (uint8_t *)result.data.data();
 while (num_bits > 8) {
-reg.set_bits(offset, 8, *bytes);
+reg.setBits(offset, 8, *bytes);
 offset += 8;
 num_bits -= 8;
 bytes++;
 }
 if (num_bits)
-reg.set_bits(offset, num_bits, *bytes);
+reg.setBits(offset, num_bits, *bytes);

 return reg;
 }
diff --git a/src/arch/arm/isa/insts/sve.isa b/src/arch/arm/isa/insts/sve.isa
index 03775ca..8a4e724 100644
--- a/src/arch/arm/isa/insts/sve.isa
+++ b/src/arch/arm/isa/insts/sve.isa
@@ -2623,7 +2623,7 @@
 code +='''
 const SElement& srcElem1 = auxPOp1[i];'''
 code += '''
-destPred.set_raw(i, 0);
+destPred.setRaw(i, 0);
 PDest_xd[i] = srcElem1;'''
 else:
 if unpackHalf == Unpack.High:
@@ -2836,8 +2836,8 @@
 ArmISA::VecPredRegContainer tmpPredC;
 auto auxPOp1 = tmpPredC.as();
 for (unsigned i = 0; i < eCount; ++i) {
-uint8_t v = POp1_x.get_raw(i);
-auxPOp1.set_raw(i, v);
+uint8_t v = POp1_x.getRaw(i);
+auxPOp1.setRaw(i, v);
 }
 PDest_x[0] = 0;'''
 else:
@@ -2854,7 +2854,7 @@
 AA64FpDest_x[i] = auxOp1[eCount - i - 1];'''
 else:
 code += '''
-destPred.set_raw(i, auxPOp1.get_raw(eCount - i - 1));'''
+destPred.setRaw(i, auxPOp1.getRaw(eCount - i - 1));'''
 code += '''
 }'''
 iop = ArmInstObjParams(name, 'Sve' + Name, 'SveUnaryUnpredOp',
diff --git a/src/arch/generic/vec_pred_reg.hh  
b/src/arch/generic/vec_pred_reg.hh

index b238357..46f6f2f 100644
--- a/src/arch/generic/vec_pred_reg.hh
+++ b/src/arch/generic/vec_pred_reg.hh
@@ -118,18 +118,18 @@
 /// Return an element of the predicate register as it appears
 /// in the raw (untyped) internal representation
 uint8_t
-get_raw(size_t idx) const
+getRaw(size_t idx) const
 {
-return container.get_bits(idx * (Packed ? 1 : sizeof(VecElem)),
+return container.getBits(idx * (Packed ? 1 : sizeof(VecElem)),
 (Packed ? 1 : sizeof(VecElem)));
 }

 /// Write a raw value in an element of the predicate register
 template
 std::enable_if_t
-set_raw(size_t idx, uint8_t val)
+setRaw(size_t idx, uint8_t val)
 {
-container.set_bits(idx * (Packed ? 1 : sizeof(VecElem)),
+container.setBits(idx * (Packed ? 1 : sizeof(VecElem)),
 (Packed ? 1 : sizeof(VecElem)), val);
 }

@@ -302,7 +302,7 @@
 /// Returns a subset of bits starting from a specific element in the
 /// container.
 uint8_t
-get_bits(size_t idx, uint8_t nbits) const
+getBits(size_t idx, uint8_t nbits) const
 {
 assert(nbits > 0 && nbits <= 8 && (idx + nbits - 1) < NumBits);
 uint8_t v = 0;
@@ -317,7 +317,7 @@
 /// Set a subset of bits starting from a specific element in the
 /// container.
 void
-set_bits(size_t idx, uint8_t nbits, uint8_t bval)
+setBits(size_t idx, uint8_t nbits, uint8_t bval)
 {
 assert(nbits > 0 && nbits <= 8 && (idx + nbits - 1) < NumBits);
 for (int i = 0; i < nbits; ++i, ++idx) {

--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/44505
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: I57c0217dc399b7e1c5b007ed862d7ed221d5ac0b
Gerrit-Change-Number: 44505
Gerrit-PatchSet: 2
Gerrit-Owner: Giacomo Travaglini 
Gerrit-Reviewer: Bobby R. Bruce 
Gerrit-Reviewer: Gabe Black 
Gerrit-Reviewer: Giacomo Travaglini 
Gerrit-Reviewer: Jason Lowe-Power 
Gerrit-Reviewer: Jason Lowe-Power

[gem5-dev] Re: gem5 namespace

2021-04-15 Thread Gabe Black via gem5-dev 
My vote is for 1 and A.

We have style rules for a reason, and that is because not following them
causes technical problems like name collisions, and makes it less obvious
when reading code what things are and what they're doing. It's a bit
hypocritical to say that we should follow style rules and completely ignore
the aesthetic rule when capitalizing GEM5_, but then say that the aesthetic
rule should win when dealing with the namespace.

This is further inconsistent with the Gem5Internal namespace, the Gem5
class in SCons, the Gem5Op instruction format used for ARM, and the Gem5Imm
constant used for ARM semihosting. It would also cause a collision with any
variable called gem5, a completely legal and reasonable name to use,
*especially* in code outside of gem5 which might be using it to refer to
something related to gem5 which it is interacting with.

There are no other instances where we let superficial aesthetic conventions
like this overrule technical considerations. We don't add _tm to the end of
trademarked names, we don't call AtomicSimpleCPU the atomic simple CPU
since that's not a valid class name, and a hundred other examples of where
prose takes a back seat because this is not prose, this is a conceptual
machine people happen to be able to read.

Our website is the place for branding and identity and marketing, our code
is not.

Gabe

On Wed, Apr 14, 2021 at 7:28 AM Jason Lowe-Power via gem5-dev <
gem5-dev@gem5.org> wrote:

> Thanks for putting this all together, Daniel!
>
> My opinion is the same as yours: option 2 and macro A.
>
> One other thing 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 <
> 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/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
>> 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/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**
>> 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
>> 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]: dev: Fix GCN3_X86 builds on aarch64 host

2021-04-15 Thread Giacomo Travaglini (Gerrit) via gem5-dev 
Giacomo Travaglini has submitted this change. (  
https://gem5-review.googlesource.com/c/public/gem5/+/44485 )


Change subject: dev: Fix GCN3_X86 builds on aarch64 host
..

dev: Fix GCN3_X86 builds on aarch64 host

Signed-off-by: Giacomo Travaglini 
Change-Id: Ic826f0cb46e07b9b5135eee1e518bc13f3d978a1
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/44485
Reviewed-by: Gabe Black 
Maintainer: Gabe Black 
Tested-by: kokoro 
---
M src/dev/hsa/hsa.h
1 file changed, 1 insertion(+), 1 deletion(-)

Approvals:
  Gabe Black: Looks good to me, approved; Looks good to me, approved
  kokoro: Regressions pass



diff --git a/src/dev/hsa/hsa.h b/src/dev/hsa/hsa.h
index 55a98b1..ef01de6 100644
--- a/src/dev/hsa/hsa.h
+++ b/src/dev/hsa/hsa.h
@@ -80,7 +80,7 @@
 // Try to detect CPU endianness
 #if !defined(LITTLEENDIAN_CPU) && !defined(BIGENDIAN_CPU)
 #if defined(__i386__) || defined(__x86_64__) || defined(_M_IX86) || \
-defined(_M_X64)
+defined(_M_X64) || defined(__aarch64__)
 #define LITTLEENDIAN_CPU
 #endif
 #endif

--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/44485
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: Ic826f0cb46e07b9b5135eee1e518bc13f3d978a1
Gerrit-Change-Number: 44485
Gerrit-PatchSet: 2
Gerrit-Owner: Giacomo Travaglini 
Gerrit-Reviewer: Gabe Black 
Gerrit-Reviewer: Giacomo Travaglini 
Gerrit-Reviewer: Matthew Poremba 
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]: cpu: Increased the upper bound of cpu issue width

2021-04-15 Thread Han-sheng Liu (Gerrit) via gem5-dev 
Han-sheng Liu has submitted this change. (  
https://gem5-review.googlesource.com/c/public/gem5/+/44225 )


Change subject: cpu: Increased the upper bound of cpu issue width
..

cpu: Increased the upper bound of cpu issue width

The upper bound was 8, but issue width increased to 12 since Cortex A77.
(https://en.wikichip.org/wiki/arm_holdings/microarchitectures/cortex-a77)
This CL increased the upper bound to 12.

Bug: 175759373
Test: gem5/main/config/example/se.py
Change-Id: I9d084b940628a2bcfa676d386d3d1a82ba9b03f2
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/44225
Reviewed-by: Gabe Black 
Maintainer: Gabe Black 
Tested-by: kokoro 
---
M src/cpu/o3/impl.hh
1 file changed, 1 insertion(+), 1 deletion(-)

Approvals:
  Gabe Black: Looks good to me, approved; Looks good to me, approved
  kokoro: Regressions pass



diff --git a/src/cpu/o3/impl.hh b/src/cpu/o3/impl.hh
index bc7e408..b709930 100644
--- a/src/cpu/o3/impl.hh
+++ b/src/cpu/o3/impl.hh
@@ -72,7 +72,7 @@

 enum
 {
-  MaxWidth = 8,
+  MaxWidth = 12,
   MaxThreads = 4
 };
 };

--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/44225
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: I9d084b940628a2bcfa676d386d3d1a82ba9b03f2
Gerrit-Change-Number: 44225
Gerrit-PatchSet: 4
Gerrit-Owner: Han-sheng Liu 
Gerrit-Reviewer: Gabe Black 
Gerrit-Reviewer: Giacomo Travaglini 
Gerrit-Reviewer: Han-sheng Liu 
Gerrit-Reviewer: Jason Lowe-Power 
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]: systemc: define atomic extension

2021-04-15 Thread Yu-hsin Wang (Gerrit) via gem5-dev 
Yu-hsin Wang has uploaded this change for review. (  
https://gem5-review.googlesource.com/c/public/gem5/+/44525 )



Change subject: systemc: define atomic extension
..

systemc: define atomic extension

Gem5 defines several types of memory access including normal read,
normal write, atomic operations. For now we only support normal read
and normal write converting from SystemC via TLM2. To support atomic
operations from SystemC, we add an atomic extension. A SystemC model can
fire a atomic request with the extension.

The extension mainly has two attributes. One is a AtomicOpFunctor which
is the implementation of the atomic operation. The other one is bool
which indicates the gem5 request flag should be ATOMIC_RETURN_OP or
ATOMIC_NO_RETURN_OP.

Change-Id: I817727dd4b2d357667f928063210c58a44c81afb
---
M src/systemc/tlm_bridge/sc_ext.cc
M src/systemc/tlm_bridge/sc_ext.hh
2 files changed, 71 insertions(+), 0 deletions(-)



diff --git a/src/systemc/tlm_bridge/sc_ext.cc  
b/src/systemc/tlm_bridge/sc_ext.cc

index 194ecbc..55e303b 100644
--- a/src/systemc/tlm_bridge/sc_ext.cc
+++ b/src/systemc/tlm_bridge/sc_ext.cc
@@ -77,4 +77,50 @@
 packet = cpyFrom.packet;
 }

+AtomicExtension::AtomicExtension(
+std::shared_ptr _amo_op, bool _need_return)
+  : amo_op(_amo_op), need_return(_need_return)
+{
+}
+
+tlm::tlm_extension_base *
+AtomicExtension::clone() const
+{
+return new AtomicExtension(*this);
+}
+
+void
+AtomicExtension::copy_from(const tlm::tlm_extension_base )
+{
+const AtomicExtension  = static_cast&>(ext);

+*this = cpyFrom;
+}
+
+AtomicExtension &
+AtomicExtension::getExtension(const tlm::tlm_generic_payload )
+{
+return AtomicExtension::getExtension();
+}
+
+AtomicExtension &
+AtomicExtension::getExtension(const tlm::tlm_generic_payload *payload)
+{
+AtomicExtension *result = nullptr;
+payload->get_extension(result);
+sc_assert(result);
+return *result;
+}
+
+bool
+AtomicExtension::needReturn() const
+{
+return need_return;
+}
+
+AtomicOpFunctor*
+AtomicExtension::getAtomicOpFunctor() const
+{
+return amo_op.get();
+}
+
 } // namespace Gem5SystemC
diff --git a/src/systemc/tlm_bridge/sc_ext.hh  
b/src/systemc/tlm_bridge/sc_ext.hh

index 56a19a77..aea14ae 100644
--- a/src/systemc/tlm_bridge/sc_ext.hh
+++ b/src/systemc/tlm_bridge/sc_ext.hh
@@ -34,6 +34,9 @@
 #ifndef __SYSTEMC_TLM_BRIDGE_SC_EXT_HH__
 #define __SYSTEMC_TLM_BRIDGE_SC_EXT_HH__

+#include 
+
+#include "base/amo.hh"
 #include "mem/packet.hh"
 #include "systemc/ext/tlm_core/2/generic_payload/gp.hh"

@@ -58,6 +61,28 @@
 PacketPtr packet;
 };

+class AtomicExtension: public tlm::tlm_extension
+{
+  public:
+AtomicExtension(
+std::shared_ptr _amo_op, bool _need_return);
+
+virtual tlm_extension_base *clone() const;
+virtual void copy_from(const tlm_extension_base );
+
+static AtomicExtension (
+const tlm::tlm_generic_payload *payload);
+static AtomicExtension (
+const tlm::tlm_generic_payload );
+
+bool needReturn() const;
+AtomicOpFunctor* getAtomicOpFunctor() const;
+
+  private:
+std::shared_ptr amo_op;
+bool need_return;
+};
+
 } // namespace Gem5SystemC

 #endif // __SYSTEMC_TLM_BRIDGE_SC_EXT_HH__

--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/44525
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: I817727dd4b2d357667f928063210c58a44c81afb
Gerrit-Change-Number: 44525
Gerrit-PatchSet: 1
Gerrit-Owner: Yu-hsin Wang 
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

[gem5-dev] Change in gem5/gem5[develop]: systemc: tlm bridge support atomic operations

2021-04-15 Thread Yu-hsin Wang (Gerrit) via gem5-dev 
Yu-hsin Wang has uploaded this change for review. (  
https://gem5-review.googlesource.com/c/public/gem5/+/44526 )



Change subject: systemc: tlm bridge support atomic operations
..

systemc: tlm bridge support atomic operations

Change-Id: I9b0ca447f8457348e96debf3e67b4eee5b4cf076
---
M src/systemc/tlm_bridge/gem5_to_tlm.cc
M src/systemc/tlm_bridge/tlm_to_gem5.cc
2 files changed, 41 insertions(+), 15 deletions(-)



diff --git a/src/systemc/tlm_bridge/gem5_to_tlm.cc  
b/src/systemc/tlm_bridge/gem5_to_tlm.cc

index b80a083..d92e4a0 100644
--- a/src/systemc/tlm_bridge/gem5_to_tlm.cc
+++ b/src/systemc/tlm_bridge/gem5_to_tlm.cc
@@ -133,6 +133,14 @@
 auto *extension = new Gem5SystemC::Gem5Extension(packet);
 trans->set_auto_extension(extension);

+if (packet->isAtomicOp()) {
+auto *atomic_ex = new Gem5SystemC::AtomicExtension(
+std::shared_ptr(
+packet->req->getAtomicOpFunctor()->clone()),
+packet->req->isAtomicReturn());
+trans->set_auto_extension(atomic_ex);
+}
+
 // Apply all conversion steps necessary in this specific setup.
 for (auto  : extraPacketToPayloadSteps) {
 step(packet, *trans);
diff --git a/src/systemc/tlm_bridge/tlm_to_gem5.cc  
b/src/systemc/tlm_bridge/tlm_to_gem5.cc

index 143eeac..72d4451 100644
--- a/src/systemc/tlm_bridge/tlm_to_gem5.cc
+++ b/src/systemc/tlm_bridge/tlm_to_gem5.cc
@@ -93,24 +93,42 @@
 payload2packet(RequestorID _id, tlm::tlm_generic_payload )
 {
 MemCmd cmd;
+std::shared_ptr req;

-switch (trans.get_command()) {
-case tlm::TLM_READ_COMMAND:
-cmd = MemCmd::ReadReq;
-break;
-case tlm::TLM_WRITE_COMMAND:
-cmd = MemCmd::WriteReq;
-break;
-case tlm::TLM_IGNORE_COMMAND:
-return nullptr;
-default:
-SC_REPORT_FATAL("TlmToGem5Bridge",
-"received transaction with unsupported  
command");

+Gem5SystemC::AtomicExtension *atomic_ex = nullptr;
+trans.get_extension(atomic_ex);
+if (atomic_ex) {
+cmd = MemCmd::SwapReq;
+Request::Flags flags = (atomic_ex->needReturn() ?
+Request::ATOMIC_RETURN_OP :
+Request::ATOMIC_NO_RETURN_OP);
+AtomicOpFunctorPtr amo_op = AtomicOpFunctorPtr(
+atomic_ex->getAtomicOpFunctor()->clone());
+// FIXME: correct the context_id and pc state.
+req = std::make_shared(
+trans.get_address(), trans.get_data_length(), flags, _id,
+0, 0, std::move(amo_op));
+req->setPaddr(trans.get_address());
+} else {
+switch (trans.get_command()) {
+case tlm::TLM_READ_COMMAND:
+cmd = MemCmd::ReadReq;
+break;
+case tlm::TLM_WRITE_COMMAND:
+cmd = MemCmd::WriteReq;
+break;
+case tlm::TLM_IGNORE_COMMAND:
+return nullptr;
+default:
+SC_REPORT_FATAL("TlmToGem5Bridge",
+"received transaction with unsupported "
+"command");
+}
+Request::Flags flags;
+req = std::make_shared(
+trans.get_address(), trans.get_data_length(), flags, _id);
 }

-Request::Flags flags;
-auto req = std::make_shared(
-trans.get_address(), trans.get_data_length(), flags, _id);

 /*
  * Allocate a new Packet. The packet will be deleted when it returns  
from


--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/44526
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: I9b0ca447f8457348e96debf3e67b4eee5b4cf076
Gerrit-Change-Number: 44526
Gerrit-PatchSet: 1
Gerrit-Owner: Yu-hsin Wang 
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