[gem5-users] The learning gem5 code can't be compiled.

[조해윤]

Hi all,

The recent commit for learning gem5 occurs a compile error.

The cause is #include base/misc.hh, because misc.hh is renamed to
logging.hh recently.
___
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users

Re: [gem5-users] Possible Bug with X86 Decoder

[Gabe Black]

Could you please give this patch a try?

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

On Mon, Dec 4, 2017 at 5:50 PM, Matt Sinclair 
wrote:

> Hi everyone,
>
> Recently I've been dealing with an unmapped address bug that I’ve traced
> back to an issue with the X86 decoder.  Specifically, the issue I’m having
> is that one of the three micro-ops for this loop instruction:
>
>
>
> 1964176: loop   0xffee
>
>
>
> is having its PC truncated from 64 bits to 32 bits.  The PC of the
> original loop instruction is 0x727ae050, and I see that the rdip and
> subi (the first two micro-ops) do not affect this.  However, the wripi
> truncates the resultant PC to 32 bits, which causes the unmapped address
> failure.  With the X86 flag on, I see that the pick() function picks size 4
> (i.e., dataSize == 4) for this micro-op, when it should be choosing size 8
> (if I force the pick() function to always choose the 64-bit return value,
> then the application makes progress beyond the failure point).  I have
> included more details of the trace I’ve been looking at below for reference.
>
>
>
> However, so far I haven’t been able to find any useful information about
> why the dataSize field is being set to 4 for this micro-op/instruction.
> Gabe, I was wondering if you could provide any pointers about where the
> right place(s) to look at for this?
>
>
>
> Sincerely,
> Matt Sinclair
>
>
>
> ---
>
>
>
> (I used the following flags: ExecAll,Decode,X86,Fetch,
> IntRegs,MiscRegs,CCRegs)
>
>
>
> 60042127104: system.cpu0.[tid:0]: Setting int reg 16 (16) to
> 0.
>
> 60042127104: system.cpu0: Decode: Decoded rdip
> instruction:
>
> {
>
>
> leg = 0,
>
>
> rex = 0,
>
>
> vex/xop = 0,
>
>
> op = {
>
>
> type = one byte,
>
>
> op = 0xe2,
>
>
> },
>
>
> modRM = 0,
>
>
> sib = 0,
>
>
> immediate = 0xffee,
>
>
> displacement = 0
>
>
> dispSize = 0,
>
>
> mode = 0,
>
>
> submode = 0}
>
>
>
>
>
> 60042127104: global: The data size is 4
>
>
> 60042127104: system.cpu0.[tid:0]: Setting int reg 17 (17) to
> *0x727ae052*. *// Matt: rdip sets resultant PC correctly
> in t1d*
>
> 60042127104: system.cpu0 A0 T0 : 
> @_ZN12_GLOBAL__N_1L16ARMAttributeTagsE+140737131964176
> : loop   0xffee
>
> 60042127104: system.cpu0 A0 T0 : 
> @_ZN12_GLOBAL__N_1L16ARMAttributeTagsE+140737131964176.0
> :   LOOP_I : rdip   t1d, %ctrl154,  : IntAlu :  D=*0x727ae052  *
> flags=(IsInteger|IsMicroop|IsDelayedCommit|IsFirstMicroop)
>
> 60042127104: system.cpu0.[tid:0]: Setting int reg 16 (16) to
> 0.
>
> 60042127104: system.cpu0: Decode: Decoded subi
> instruction:
>
> {
>
>
> leg = 0,
>
>
> rex = 0,
>
>
> vex/xop = 0,
>
>
> op = {
>
>
> type = one byte,
>
>
> op = 0xe2,
>
>
> },
>
>
> modRM = 0,
>
>
> sib = 0,
>
>
> immediate = 0xffee,
>
>
> displacement = 0
>
>
> dispSize = 0,
>
>
> mode = 0,
>
>
> submode = 0}
>
>
>
>
>
> 60042127104: system.cpu0.[tid:0]: Reading int reg 1 (1) as
> 0x22.
>
> 60042127104: global: Picking with size 8
>
>
> 60042127104: global: flagMask = 0x20
>
>
> 60042127104: system.cpu0.[tid:0]: Setting int reg 1 (1) to
> 0x21.
>
> 60042127104: system.cpu0.[tid:0]: Setting CC reg 4 (4) to
> 0.
>
> 60042127104: system.cpu0 A0 T0 : 
> @_ZN12_GLOBAL__N_1L16ARMAttributeTagsE+140737131964176.1
> :   LOOP_I : subi   rcx, rcx, 0x1 : IntAlu :  D=0x
> flags=(IsInteger|IsCC|IsMicroop|IsDelayedCommit)
>
> 60042127104: system.cpu0.[tid:0]: Setting int reg 16 (16) to
> 0.
>
> 60042127104: system.cpu0: Decode: Decoded wripi
> instruction:
>
> {
>
>
> leg = 0,
>
>
> rex = 0,
>
>
> vex/xop = 0,
>
>
> op = {
>
>
> type = one byte,
>
>
> op = 0xe2,
>
>
> },
>
>
> modRM = 0,
>
>
> sib = 0,
>
>
> immediate = 0xffee,
>
>
> displacement = 0
>
>
> dispSize = 0,
>
>
> mode = 0,
>
>
> submode = 0}
>
>
>
>
>
> *60042127104: system.cpu0.[tid:0]: Reading int reg 17 (17) as
> 0x727ae052.   // Matt: PC (in t1d) still correct at this point*
>
> 60042127104: system.cpu0.[tid:0]: Reading CC reg 0 (0) as
> 0x44.
>
> 60042127104: system.cpu0.[tid:0]: Reading CC reg 1 (1) as
> 0.
>
> 60042127104: system.cpu0.[tid:0]: Reading CC reg 2 (2) as 0.
>
>
> 60042127104: system.cpu0.[tid:0]: Reading CC reg 3 (3) as
> 0.
>
> 60042127104: system.cpu0.[tid:0]: Reading CC reg 4 (4) as
> 0.
>
> *60042127104: global: Picking with size
> 4 // Matt: this
> should be size 8*
>
> 60042127104: system.cpu0 A0 T0 : 
> @_ZN12_GLOBAL__N_1L16ARMAttributeTagsE+140737131964176.2
> :   LOOP_I : wripi   , t1d, 0xee : IntAlu :   flags=(IsInteger|IsCC|
> IsControl|IsCondControl|IsMicroop|IsLastMicroop)
>
> 60042127104: system.cpu0: Fetch: PC:*0xf27ae040
> // Matt: resultant PC is truncated*
>
> Fault 

[gem5-users] Possible Bug with X86 Decoder

[Matt Sinclair]

Hi everyone,

Recently I've been dealing with an unmapped address bug that I’ve traced
back to an issue with the X86 decoder.  Specifically, the issue I’m having
is that one of the three micro-ops for this loop instruction:



1964176: loop   0xffee



is having its PC truncated from 64 bits to 32 bits.  The PC of the original
loop instruction is 0x727ae050, and I see that the rdip and subi (the
first two micro-ops) do not affect this.  However, the wripi truncates the
resultant PC to 32 bits, which causes the unmapped address failure.  With
the X86 flag on, I see that the pick() function picks size 4 (i.e.,
dataSize == 4) for this micro-op, when it should be choosing size 8 (if I
force the pick() function to always choose the 64-bit return value, then
the application makes progress beyond the failure point).  I have included
more details of the trace I’ve been looking at below for reference.



However, so far I haven’t been able to find any useful information about
why the dataSize field is being set to 4 for this micro-op/instruction.
Gabe, I was wondering if you could provide any pointers about where the
right place(s) to look at for this?



Sincerely,
Matt Sinclair



---



(I used the following flags:
ExecAll,Decode,X86,Fetch,IntRegs,MiscRegs,CCRegs)



60042127104: system.cpu0.[tid:0]: Setting int reg 16 (16) to
0.

60042127104: system.cpu0: Decode: Decoded rdip
instruction:

{


leg = 0,


rex =
0,

vex/xop =
0,

op = {


type = one
byte,

op =
0xe2,

},


modRM =
0,

sib =
0,

immediate =
0xffee,

displacement =
0

dispSize =
0,

mode =
0,

submode =
0}



60042127104: global: The data size is
4

60042127104: system.cpu0.[tid:0]: Setting int reg 17 (17) to
*0x727ae052*. *// Matt: rdip sets resultant PC correctly in
t1d*

60042127104: system.cpu0 A0 T0 :
@_ZN12_GLOBAL__N_1L16ARMAttributeTagsE+140737131964176: loop
0xffee

60042127104: system.cpu0 A0 T0 :
@_ZN12_GLOBAL__N_1L16ARMAttributeTagsE+140737131964176.0  :   LOOP_I :
rdip   t1d, %ctrl154,  : IntAlu :  D=*0x727ae052  *
flags=(IsInteger|IsMicroop|IsDelayedCommit|IsFirstMicroop)

60042127104: system.cpu0.[tid:0]: Setting int reg 16 (16) to
0.

60042127104: system.cpu0: Decode: Decoded subi
instruction:

{


leg = 0,


rex =
0,

vex/xop =
0,

op = {


type = one
byte,

op =
0xe2,

},


modRM =
0,

sib =
0,

immediate =
0xffee,

displacement =
0

dispSize =
0,

mode =
0,

submode = 0}




60042127104: system.cpu0.[tid:0]: Reading int reg 1 (1) as
0x22.

60042127104: global: Picking with size
8

60042127104: global: flagMask =
0x20

60042127104: system.cpu0.[tid:0]: Setting int reg 1 (1) to
0x21.

60042127104: system.cpu0.[tid:0]: Setting CC reg 4 (4) to
0.

60042127104: system.cpu0 A0 T0 :
@_ZN12_GLOBAL__N_1L16ARMAttributeTagsE+140737131964176.1  :   LOOP_I :
subi   rcx, rcx, 0x1 : IntAlu :  D=0x
flags=(IsInteger|IsCC|IsMicroop|IsDelayedCommit)

60042127104: system.cpu0.[tid:0]: Setting int reg 16 (16) to
0.

60042127104: system.cpu0: Decode: Decoded wripi
instruction:

{


leg =
0,

rex =
0,

vex/xop =
0,

op =
{

type = one
byte,

op =
0xe2,

},


modRM =
0,

sib =
0,

immediate =
0xffee,

displacement =
0

dispSize =
0,

mode = 0,


submode =
0}



*60042127104: system.cpu0.[tid:0]: Reading int reg 17 (17) as
0x727ae052.   // Matt: PC (in t1d) still correct at this point*

60042127104: system.cpu0.[tid:0]: Reading CC reg 0 (0) as
0x44.

60042127104: system.cpu0.[tid:0]: Reading CC reg 1 (1) as
0.

60042127104: system.cpu0.[tid:0]: Reading CC reg 2 (2) as 0.


60042127104: system.cpu0.[tid:0]: Reading CC reg 3 (3) as
0.

60042127104: system.cpu0.[tid:0]: Reading CC reg 4 (4) as
0.

*60042127104: global: Picking with size
4 // Matt: this
should be size 8*

60042127104: system.cpu0 A0 T0 :
@_ZN12_GLOBAL__N_1L16ARMAttributeTagsE+140737131964176.2  :   LOOP_I :
wripi   , t1d, 0xee : IntAlu :
flags=(IsInteger|IsCC|IsControl|IsCondControl|IsMicroop|IsLastMicroop)

60042127104: system.cpu0: Fetch: PC:*0xf27ae040
// Matt: resultant PC is truncated*

Fault description: #PF(0x15) at
0xf27ae040

PC: 0xf27ae040, Instr:   LOOP_I : wripi   , t1d,
0xee

panic: Tried to execute unmapped address 0xf27ae040.
___
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users

[gem5-users] How to access cache (in timing mode) in a pseudo instruction

[倪某]

Hello everyone,
I am now adding some pseudo instructions to the X86 ISA, and need to access
the cache. Since in timing mode, there is a latency when accessing the
cache, how can i get the result of the access in the instruction.
In my understanding, the pseudo instruction works just like a system call,
we cannot wait in the hander for the response.
The cache operation does not return the result immediately, then how can i
get the results?

Thanks very much.
--
Regards,
Fan Ni
___
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users

[gem5-users] omg! amazing new stuff

[Sheldon Stanton]

Hello, 

Take  a look at these cool things that I've just found on the web, they can  be 
just amazing! Check them out 
http://www.wififamilyblog.com/wp-content/uploads/dfgx.php?UE9nZW01LXVzZXJzQGdlbTUub3Jn

Good wishes, Sheldon Stanton


-

In no event will we be liable for any loss or damage including without 
limitation, indirect or consequential loss or damage, or any loss or damage 
whatsoever arising from loss of data or profits arising out of, or in 
connection with, the use of this website. Through this website you are able to 
link to other websites which are not under the control of US. We have no 
control over the nature, content and availability of those sites. The inclusion 
of any links does not necessarily imply a recommendation or endorse the views 
expressed within them.

___
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users

Re: [gem5-users] Instructions Access from Instruction Scratch Pad (I-SPM)

[Qureshi Yasir Mahmood]

Hi Everyone,

As the CPU is ARMv8, is anyone aware of any architectural constraints as to why 
the instructions are not being executed from Instruction-SPM ? Secondly in 
BaseCPU.py, there are _uncached_master_port. Can I connect the SPM to the 
_uncached_master_port, or is it for interrupts only ?

Regards
Yasir

From: gem5-users [mailto:gem5-users-boun...@gem5.org] On Behalf Of Qureshi 
Yasir Mahmood
Sent: 01 December 2017 16:45
To: gem5 users mailing list 
Subject: [gem5-users] Instructions Access from Instruction Scratch Pad (I-SPM)

Hello All,

I have recently been working on adding both data and instruction scratch Pad 
(SPM) in GEM5 FS simulation. I was able to add both of them alongside with 
having L1-I and L1-D cache. The memory system now looks as in figure at 
https://imgur.com/a/wUtUX

Since I am using FS mode, I can access the D-SPM and I-SPM using 
open("/dev/mem") and mmap(). I-SPM is connected to both the instruction as well 
as data port, so that we can write the program to it through data port and 
execute and read through instruction port.
To test this, I compiled a helloworld program as a library which does not print 
anything, but just returns an integer value. We access this library through 
dlopen and the function in the library through dlsym. Then through function 
pointer we copied the function to the I-SPM. Finally we jumped to the function 
in I-SPM through a function pointer call. After this the program gets stuck and 
does not proceed.

In the stats file I can see the write accesses (to copy the function to) the 
SPM issued by cpu.data, but I don't see any read cpu.inst access to I-SPM. Can 
someone suggest why the CPU does not read the I-SPM when I jump to the function 
in it ?

NOTE: When using mmap() I do enable PROT_EXEC to mark I-SPM as executable 
memory region.

Regards
Yasir


___
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users