[gem5-users] Re: Implicit Register Dependencies in x86

2021-07-23 Thread Gabe Black via gem5-users
Yes, I haven't looked at the code itself, but that explanation seems very
plausible. The way the ISA parser works is basically if something is on the
left hand side of an =, then it's assumed to be a destination, and
otherwise it's a source. It bases its decision *purely* on text, with no
understand of liveness, where values came from, or even more subtle things
like being set by a function when passed by reference.

One trick you can use, and which you'll find in other places in the ISA
descriptions (particularly ARM I think), is to assign the result of a
computation to a temporary like "result" which doesn't mean anything to the
parser. Then you can use that variable to compute flags, etc, without the
parser thinking you're reading the original version of that register.
Separately, you can assign result to the destination register, which the
also successfully tell the parser how to treat that operand.

uint64_t result = Src1 * Src2;
computeFlags(result);
Dest = result;

I have some grand plans for how to make the parser and ISA generation in
general more sophisticated in several different ways, at which point these
sorts of tricks will hopefully be unnecessary. In the meantime though, this
may help solve your problem. If it works, please send out a review so we
can fix this for other folks too.

Gabe

On Fri, Jul 23, 2021 at 12:20 PM Mohit Gambhir via gem5-users <
gem5-users@gem5.org> wrote:

> Hi Gabe,
>
> I think your code has not yet made into stable/master branch. I see that
> in develop branch INTREG_IMPLICIT is no longer there and is replaced by
> INTREG_PRODHI and INTREG_PRODLO
>
> However, I see that even in develop branch there are two classes that are
> generated - Mul1s and Mul1sFlags. In Mul1s INTREG_PRODLO and INTREG_PRODHI
> are not added as source and are only added as destination. But in
> Mul1sFlags class they are added both as source and destination.
>
> class Mul1s : public X86ISA::RegOpT X86ISA::FoldedSrc2Op>
> {
>   ...
> setSrcRegIdx(_numSrcRegs++, RegId(IntRegClass, src1));
> setSrcRegIdx(_numSrcRegs++, RegId(IntRegClass, src2));
> setDestRegIdx(_numDestRegs++, RegId(IntRegClass,
> X86ISA::INTREG_PRODLOW));
> _numIntDestRegs++;
> setDestRegIdx(_numDestRegs++, RegId(IntRegClass,
> X86ISA::INTREG_PRODHI));
> _numIntDestRegs++;
> ...
> }
>
> class Mul1sFlags : public X86ISA::RegOpT X86ISA::FoldedSrc2Op>
> {
> .
> setSrcRegIdx(_numSrcRegs++, RegId(IntRegClass, src1));
> setSrcRegIdx(_numSrcRegs++, RegId(IntRegClass, src2));
> setSrcRegIdx(_numSrcRegs++, RegId(IntRegClass,
> X86ISA::INTREG_PRODLOW));
> setDestRegIdx(_numDestRegs++, RegId(IntRegClass,
> X86ISA::INTREG_PRODLOW));
> _numIntDestRegs++;
> setSrcRegIdx(_numSrcRegs++, RegId(IntRegClass,
> X86ISA::INTREG_PRODHI));
> setDestRegIdx(_numDestRegs++, RegId(IntRegClass,
> X86ISA::INTREG_PRODHI));
>
> }
>
> Any idea why that would be? Does it have anything to do with how Mul1s is
> defined in src/arch/x86/isa/microops/regop.isa. I see that flags_code in
> that definition does read ProdHi and ProdLow but it is being produced by
> the same instruction. Does isa_parser naively treat it as source because it
> is RHS in flags code? My understanding of isa_parser is very primitive so
> any help there will be appreciated.
>
> Thanks!
> ___
> gem5-users mailing list -- gem5-users@gem5.org
> To unsubscribe send an email to gem5-users-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: Implicit Register Dependencies in x86

2021-07-23 Thread Mohit Gambhir via gem5-users
Hi Gabe, 

I think your code has not yet made into stable/master branch. I see that in 
develop branch INTREG_IMPLICIT is no longer there and is replaced by 
INTREG_PRODHI and INTREG_PRODLO

However, I see that even in develop branch there are two classes that are 
generated - Mul1s and Mul1sFlags. In Mul1s INTREG_PRODLO and INTREG_PRODHI are 
not added as source and are only added as destination. But in Mul1sFlags class 
they are added both as source and destination. 

class Mul1s : public X86ISA::RegOpT
{
  ...
setSrcRegIdx(_numSrcRegs++, RegId(IntRegClass, src1));
setSrcRegIdx(_numSrcRegs++, RegId(IntRegClass, src2));
setDestRegIdx(_numDestRegs++, RegId(IntRegClass, 
X86ISA::INTREG_PRODLOW));
_numIntDestRegs++;
setDestRegIdx(_numDestRegs++, RegId(IntRegClass, 
X86ISA::INTREG_PRODHI));
_numIntDestRegs++;
...
}

class Mul1sFlags : public X86ISA::RegOpT
{
.
setSrcRegIdx(_numSrcRegs++, RegId(IntRegClass, src1));
setSrcRegIdx(_numSrcRegs++, RegId(IntRegClass, src2));
setSrcRegIdx(_numSrcRegs++, RegId(IntRegClass, X86ISA::INTREG_PRODLOW));
setDestRegIdx(_numDestRegs++, RegId(IntRegClass, 
X86ISA::INTREG_PRODLOW));
_numIntDestRegs++;
setSrcRegIdx(_numSrcRegs++, RegId(IntRegClass, X86ISA::INTREG_PRODHI));
setDestRegIdx(_numDestRegs++, RegId(IntRegClass, 
X86ISA::INTREG_PRODHI));

}

Any idea why that would be? Does it have anything to do with how Mul1s is 
defined in src/arch/x86/isa/microops/regop.isa. I see that flags_code in that 
definition does read ProdHi and ProdLow but it is being produced by the same 
instruction. Does isa_parser naively treat it as source because it is RHS in 
flags code? My understanding of isa_parser is very primitive so any help there 
will be appreciated. 

Thanks!
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s


[gem5-users] Re: 4-core ARM with fs.py and fs_bigLITTLE.py

2021-07-23 Thread Majid Jalili via gem5-users
Hey,
Thanks! Yes, the configuration is the same. Now, with the compiled
bootloader it boots up with 4 cores.


On Thu, Jul 22, 2021 at 10:05 AM Giacomo Travaglini <
giacomo.travagl...@arm.com> wrote:

> Hi Majid,
>
> Out of curiosity, are you sure the configuration is the same? Could you
> try to rebuild the bootloader in system/arm/bootloader/arm64 and make sure
> the config script is pointing to it?
> (Either with M5_PATH or by using the --bootloader option)
>
> Please let me know if this works
>
> Kind Regards
>
> Giacomo
>
> > -Original Message-
> > From: Majid Jalili via gem5-users 
> > Sent: 21 July 2021 05:44
> > To: gem5 users mailing list 
> > Cc: Majid Jalili 
> > Subject: [gem5-users] 4-core ARM with fs.py and fs_bigLITTLE.py
> >
> > Hi,
> >
> > I am using the following commands for the fs.py and fs_bigLITTLE.py:
> >
> > ./build/ARM/gem5.opt ./configs/example/fs.py --caches --mem-size=64GB -
> > -kernel /home/cc/disks/binaries/vmlinux.arm64 --disk
> > /home/cc/disks/disks/ubuntu-18.04-arm64-docker_big.img -n 4 --machine-
> > type VExpress_GEM5_V1
> >
> >
> >
> > ./build/ARM/gem5.opt ./configs/example/arm/fs_bigLITTLE.py --caches --
> > mem kernel /home/cc/disks/binaries/vmlinux.arm64 --disk
> > /home/cc/disks/disks/ubuntu-18.04-a
> > ig.img --machine-type VExpress_GEM5_V1 --big-cpus 4 --little-cpus 0
> >
> >
> > When I run the lscpu command, I would see 1 CPU for fs.py and 4 CPUs for
> > the  fs_bigLITTLE.py.
> > I was trying to figure out why the first script can bring only one CPU
> up, and
> > the other all 4 CPUs, but has no success.
> > I made sure all four CPUs are created in the config files.
> >
> > Thanks!
> > Majid
> 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-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Memory mapped I/O

2021-07-23 Thread hissa alshamsi via gem5-users
Hello everyone,


I am trying to write data to a memory mapped queue in gem5. I have created a 
queue as a SimObject which is connected by PIO port. I am working on SE mode 
and want to enqueue data to the queue from the user-mode program.


The device registers has been mapped to the program address space using 'map()' 
method. Does anyone have a clue on how to use a memory mapped device in SE mode 
from a user program?


Any help is appreciated,

Thank you.

Hessa.

___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s