[gem5-users] Re: ARM SVE ISA

[Nazmus Sakib via gem5-users]

Thank you. I will try to switch to starter_se.py.
I still had some questions regarding SVE.
1. When I compile with msve-vector-bit set to 512, I can see PTRUE instruction, 
which is replaced by whilelow when I compile without setting the vector bit 
value. Now on gem5, it seems whilelow and the corresponding incw instructions 
works fine, because when I keep sve_vl=1 in gem5, incw increments by 0x4 ( 128 
bits) and when I set sve_vl=4 the incw increments by 0x16 (512 bits). But what 
I am curious about, is whether there is anything wrong with the implementation 
of PTRUE instruction in gem5.
2. As shown in my first email, my data arrays are 64 bytes in size. An sve load 
instruction with sve_vl=4 will allow all 64 bytes to be loaded by one ld1w 
instruction (theoretically at least in an actual cpu ). I can see from the 
outputs generated by debug flag LSQUnit and CacheALL, that indeed all 64 bytes 
are accessed by one instruction. For example:
system.cpu.dcache: access for WriteReq [81010:8104f]
The address range here are for 64 byte (16 integer of 4 byte in my test code).
But, without support in the bus/interconnection connected with cpu to deal with 
64 bytes (or whatever is the vector length)  and additional code in gem5 to 
support multi-word read/write , shouldnt only one word (I am guessing that is 4 
byte in gem5 for arm) can be read from cache to cpu ? In that case, how are all 
64 bytes is requested and read from cache to cpu in gem5 with one instruction? 
Is there some underlying mechanism, like micro-ops or some architectural 
feature that is taking place transparently ? Or maybe a simple loop that is not 
part of the debug flag output? I tried to look in src/mem/cache/base.cc and 
cache.cc but could not get an answer.

From: Giacomo Travaglini 
Sent: 12 January 2024 03:56
To: Nazmus Sakib ; The gem5 Users mailing list 

Cc: Jason Lowe-Power 
Subject: Re: ARM SVE ISA

You don't often get email from giacomo.travagl...@arm.com. Learn why this is 
important
WARNING This email originated external to the NMSU email system. Do not click 
on links or open attachments unless you are sure the content is safe.

You are right, I created a PR to fix this:



https://github.com/gem5/gem5/pull/764



Kind Regards



Giacomo



From: Nazmus Sakib 
Date: Thursday, 11 January 2024 at 19:34
To: Giacomo Travaglini , The gem5 Users mailing 
list 
Cc: Jason Lowe-Power 
Subject: Re: ARM SVE ISA

Not compiling with -msve-vector-bits did the trick. It runs perfectly, whether 
I set the cpu[0].isa[0].sve_vl_se to 4 or keep it to 1.
Thank you for the suggestions !!
One last thing, the starter_se.py does not seem to have support for 
--cpu-type=ArmO3CPU (or am I missing something) ?



From: Giacomo Travaglini 
Sent: 11 January 2024 12:16
To: The gem5 Users mailing list 
Cc: Jason Lowe-Power ; Nazmus Sakib 
Subject: Re: ARM SVE ISA



You don't often get email from giacomo.travagl...@arm.com. Learn why this is 
important

WARNING This email originated external to the NMSU email system. Do not click 
on links or open attachments unless you are sure the content is safe.

Hi Nazmus,



I can see from what you posted you are compiling the testcase with 512b vector 
width. I believe you should amend the gem5 VL accordingly… Basically writing up 
in the gem5 config:



cpu.isa[0].sve_vl_se = 4



According to [1].

This should fix your problem. Another solution I believe would be to compile 
without specifying the VL. Then it should be VL agnostic code I presume.



Anyway, I also recommend you use configs/example/arm/starter_se.py as se.py is 
per se deprecated



Kind Regards



Giacomo



[1]: https://github.com/gem5/gem5/blob/stable/src/arch/arm/ArmISA.py#L179



From: Nazmus Sakib via gem5-users 
Date: Thursday, 11 January 2024 at 17:54
To: gem5-users@gem5.org 
Cc: Jason Lowe-Power , Nazmus Sakib 
Subject: [gem5-users] ARM SVE ISA

Hello.
I am trying to run a simple program with SVE instructions on gem5. However, the 
output with debug flag ExecALL suggests there is a issue with the decoder.
Here is the test code:

#define STREAM_ARRAY_SIZE 16
void main()

{

for (int j=0; j___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org

[gem5-users] Re: Spec2017 GCC benchmark crashes in SE mode

[muke101 via gem5-users]

Hi, thanks for the reply.

Assuming that the page isn't being allocated when it should be, what could I do 
with this information? I'm not familiar with this part of the Gem5 codebase.

Also, just to be clear, what do you mean by 'when the image download is done'?

Thanks.

Sent from Proton Mail mobile

 Original Message 
On 15 Jan 2024, 01:18, sun2k23 via gem5-users wrote:

> Hi,
>
> I have ever met several similar issues but i'm not running Spec2017. I think 
> that's because you use this address 0x66195c before allocating page 
> firstly. You can enable the debug-flag of MMU to check whether the page 
> related to this address is allocated when the image download is done.
>
> S2k
>
> At 2024-01-14 04:40:13, "muke101 via gem5-users"  wrote:
>
>> Hi, I'm trying to checkpoint spec2017 with NonCachingSimpleCPU according to 
>> simpoints I generated from native AArch64 binaries. On an unmodified Gem5, a 
>> page fault occurs in the simulation (pasted the error message at the bottom).
>>
>> I've read that GCC can run out of stack space when simulated, so I edited 
>> arch/arm/process.cc to have a max stack size of 16MB instead of the default 
>> 8MB, but this hasn't helped. Can someone confirm this is the right way to 
>> increase the max stack size? The total memory allowed to the simulation if 
>> 50GB (set if --mem-size on the command line).
>>
>> Another possibility is that it's due to me compiling the benchmark without 
>> '--no-strict-aliasing', which the spec documentation suggests to, but I 
>> imagine if this were the problem then the program wouldn't had been able to 
>> run natively, which it does.
>>
>> Has anyone run into this problem before and been able to solve it?
>>
>> Thanks.
>>
>> build/ARM/sim/simulate.cc:194: info: Entering event queue @ 188431954680500. 
>> Starting simulation...
>> build/ARM/sim/faults.cc:104: panic: panic condition !handled && 
>> !tc->getSystemPtr()->trapToGdb(SIGSEGV, tc->contextId()) occurred: Page 
>> table fault when accessing virtual address 0x66195c
>> Memory Usage: 52735052 KBytes
>> Program aborted at tick 191641021589000
>> --- BEGIN LIBC BACKTRACE ---
>> /sim_home/luke/PND-Loads/gem5/build/ARM/gem5.fast(+0x97d088)[0xca97c088]
>> /sim_home/luke/PND-Loads/gem5/build/ARM/gem5.fast(+0x9ef1bc)[0xca9ee1bc]
>> linux-vdso.so.1(__kernel_rt_sigreturn+0x0)[0x4000161c2688]
>> /lib/aarch64-linux-gnu/libc.so.6(raise+0xb0)[0x4000164c2598]
>> --- END LIBC BACKTRACE ---
>> Aborted (core dumped)
>>
>> Sent with [Proton Mail](https://proton.me/) secure email.___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org

[gem5-users] Re: Spec2017 GCC benchmark crashes in SE mode

[sun2k23 via gem5-users]

Hi,


I have ever met several similar issues but i'm not running Spec2017. I think 
that's because you use this address 0x66195c before allocating page 
firstly. You can enable the debug-flag of MMU to check whether the page related 
to this address is allocated when the image download is done.  


S2k 

At 2024-01-14 04:40:13, "muke101 via gem5-users"  wrote:

Hi, I'm trying to checkpoint spec2017 with NonCachingSimpleCPU according to 
simpoints I generated from native AArch64 binaries. On an unmodified Gem5, a 
page fault occurs in the simulation (pasted the error message at the bottom).


I've read that GCC can run out of stack space when simulated, so I edited 
arch/arm/process.cc to have a max stack size of 16MB instead of the default 
8MB, but this hasn't helped. Can someone confirm this is the right way to 
increase the max stack size? The total memory allowed to the simulation if 50GB 
(set if --mem-size on the command line).



Another possibility is that it's due to me compiling the benchmark without 
'--no-strict-aliasing', which the spec documentation suggests to, but I imagine 
if this were the problem then the program wouldn't had been able to run 
natively, which it does.



Has anyone run into this problem before and been able to solve it?


Thanks.


build/ARM/sim/simulate.cc:194: info: Entering event queue @ 188431954680500.  
Starting simulation...
build/ARM/sim/faults.cc:104: panic: panic condition !handled && 
!tc->getSystemPtr()->trapToGdb(SIGSEGV, tc->contextId()) occurred: Page table 
fault when accessing virtual address 0x66195c
Memory Usage: 52735052 KBytes
Program aborted at tick 191641021589000
--- BEGIN LIBC BACKTRACE ---
/sim_home/luke/PND-Loads/gem5/build/ARM/gem5.fast(+0x97d088)[0xca97c088]
/sim_home/luke/PND-Loads/gem5/build/ARM/gem5.fast(+0x9ef1bc)[0xca9ee1bc]
linux-vdso.so.1(__kernel_rt_sigreturn+0x0)[0x4000161c2688]
/lib/aarch64-linux-gnu/libc.so.6(raise+0xb0)[0x4000164c2598]
--- END LIBC BACKTRACE ---
Aborted (core dumped)




Sent with Proton Mail secure email.___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org