[gem5-users] Re: Magic instructions with GCN3 Model/hipcc return 0
If you're using regular magic instruction based calls to the m5 ops, then that should work fine since you don't have to set up any virtual/physical mappings for that to work. That also means you can just call the non _addr version, so no problems there either. The store method will be called by the generic GuestABI code when the return type matches the partial specialization, which in this case is any type T. I think I see the problem, actually. There are two versions of the pseudoInst function, one which returns the result to the caller, and one which doesn't. The one that returns it assumes that you don't want to store it also, although you can tell it to do both. The one that does not return it makes the opposite assumption. The code in the decoder passes the return value back to the caller, so that will not automatically store the result. What it should do is either not call the version that passes back the result (preferred), or keep calling the current one but tell it to store the result for it anyway. I'm not sure why I didn't do that to start with, unless it was because one change passed each other in time while they sat in review. It could have also just been a mistake? Gabe On Mon, Nov 9, 2020 at 6:37 PM Daniel Gerzhoy wrote: > Hmm, I've been using magic instructions in SE mode for years now. Jason > can you maybe shed some light on this? Have I been getting lucky or is > there something we are missing? > > I'm using TimingSimpleCPU or DerivO3CPU (this is the GPU model, so we're > more limited). > > To be clear, the pseudo-instructions are being called, no problems. I can > see them executing with the PseudoInst debug flag. > It's just that the return values don't show up unless I explicitly set Rax > two_byte_opcodes.isa which is how it used to work. > (And It is working properly and consistently with Rax set explicitly) > > Where is the "store" in pseudo_inst_abi.hh supposed to be called from? We > could maybe add a check for SE mode and explicitly call it at the end of > pseudoInstWork() or something? > > Cheers, > > Dan > > > On Mon, Nov 9, 2020 at 9:20 PM Gabe Black wrote: > >> Using the m5 library in SE mode is somewhat uncharted waters. You'd need >> the access to /dev/mem to be captured and to map memory in the simulation >> and not on the host, or Very Bad Things might happen to your host computer. >> If the functions are defined in the header but you can't use them, you >> should make sure you're actually getting the right header and not some >> other, older version. The code which implements the ABI for address based >> m5 ops in x86 is in src/arch/x86/tlb.cc in finalizePhysical, where it sets >> the "local accessor" for the request, aka a callback which handles an >> access which conceptually does not go out into the memory system and is >> instead handled inside the CPU. The default, instruction based mechanism >> will *not* work on a KVM based CPU (if that's what you're using), and so no >> pseudo inst code of any kind will be invoked. If you're actually triggering >> the address based mechanism but you're not using a virtual address which >> maps to the correct physical address (the physical address is what's >> special), then no pseudo inst code will be triggered then either. Basically >> if you don't do the right dance to get gem5's attention, then it won't know >> you're trying to do a pseudo instruction and will do something else >> instead. Unfortunately exactly what gets through from whatever the CPU >> model is to get gem5's attention varies (necessarily) based on how the CPU >> is implemented, which is why there are all these different calling >> mechanisms, and some attempt to organize them more systematically in the >> utility. >> >> Gabe >> >> On Mon, Nov 9, 2020 at 4:40 PM Daniel Gerzhoy >> wrote: >> >>> Hi Gabe, >>> >>> I can see where the register should be stored (line 59 in >>> pseudo_inst_abi.hh) but I put a print there and it never gets called for >>> the calls that I am making at least. >>> >>> When i try to use m5_exit_addr and other functions with that suffix I >>> get a "error: 'm5_exit_addr' was not declared in this scope" >>> Which makes sense because m5ops.h doesn't declare the functions, I can >>> see they are built by macro though. >>> >>> I've also tried to run map_m5_mem() but I get the "Can't open /dev/mem" >>> error message. >>> >>> Could you point me to, or could you quickly throw together an example >>> 'hello-world' type program and build process for SE mode? >>> >>> Thanks, >>> >>> Dan >>> >>> >>> >>> >>> On Mon, Nov 9, 2020 at 6:48 PM Matt Sinclair via gem5-users < >>> gem5-users@gem5.org> wrote: >>> Hi Gabe, I don't have the broken build in front of me, and it's possible it is because I'm running on an Ubuntu 16 machine, but I had to add c+11 per the error message I got when debugging this. If c++14 works though, great. Thanks for the updated info -- I built the tutorial out of the old one, so
[gem5-users] Re: Magic instructions with GCN3 Model/hipcc return 0
Hmm, I've been using magic instructions in SE mode for years now. Jason can you maybe shed some light on this? Have I been getting lucky or is there something we are missing? I'm using TimingSimpleCPU or DerivO3CPU (this is the GPU model, so we're more limited). To be clear, the pseudo-instructions are being called, no problems. I can see them executing with the PseudoInst debug flag. It's just that the return values don't show up unless I explicitly set Rax two_byte_opcodes.isa which is how it used to work. (And It is working properly and consistently with Rax set explicitly) Where is the "store" in pseudo_inst_abi.hh supposed to be called from? We could maybe add a check for SE mode and explicitly call it at the end of pseudoInstWork() or something? Cheers, Dan On Mon, Nov 9, 2020 at 9:20 PM Gabe Black wrote: > Using the m5 library in SE mode is somewhat uncharted waters. You'd need > the access to /dev/mem to be captured and to map memory in the simulation > and not on the host, or Very Bad Things might happen to your host computer. > If the functions are defined in the header but you can't use them, you > should make sure you're actually getting the right header and not some > other, older version. The code which implements the ABI for address based > m5 ops in x86 is in src/arch/x86/tlb.cc in finalizePhysical, where it sets > the "local accessor" for the request, aka a callback which handles an > access which conceptually does not go out into the memory system and is > instead handled inside the CPU. The default, instruction based mechanism > will *not* work on a KVM based CPU (if that's what you're using), and so no > pseudo inst code of any kind will be invoked. If you're actually triggering > the address based mechanism but you're not using a virtual address which > maps to the correct physical address (the physical address is what's > special), then no pseudo inst code will be triggered then either. Basically > if you don't do the right dance to get gem5's attention, then it won't know > you're trying to do a pseudo instruction and will do something else > instead. Unfortunately exactly what gets through from whatever the CPU > model is to get gem5's attention varies (necessarily) based on how the CPU > is implemented, which is why there are all these different calling > mechanisms, and some attempt to organize them more systematically in the > utility. > > Gabe > > On Mon, Nov 9, 2020 at 4:40 PM Daniel Gerzhoy > wrote: > >> Hi Gabe, >> >> I can see where the register should be stored (line 59 in >> pseudo_inst_abi.hh) but I put a print there and it never gets called for >> the calls that I am making at least. >> >> When i try to use m5_exit_addr and other functions with that suffix I get >> a "error: 'm5_exit_addr' was not declared in this scope" >> Which makes sense because m5ops.h doesn't declare the functions, I can >> see they are built by macro though. >> >> I've also tried to run map_m5_mem() but I get the "Can't open /dev/mem" >> error message. >> >> Could you point me to, or could you quickly throw together an example >> 'hello-world' type program and build process for SE mode? >> >> Thanks, >> >> Dan >> >> >> >> >> On Mon, Nov 9, 2020 at 6:48 PM Matt Sinclair via gem5-users < >> gem5-users@gem5.org> wrote: >> >>> Hi Gabe, >>> >>> I don't have the broken build in front of me, and it's possible it is >>> because I'm running on an Ubuntu 16 machine, but I had to add c+11 per the >>> error message I got when debugging this. If c++14 works though, great. >>> >>> Thanks for the updated info -- I built the tutorial out of the old one, >>> so next time I'll make sure to update it accordingly. >>> >>> Thanks, >>> Matt >>> >>> On Mon, Nov 9, 2020 at 5:44 PM Gabe Black via gem5-users < >>> gem5-users@gem5.org> wrote: >>> BTW, I do think I need to explicitly set the c++ version in the scons file, like in Matt's original email above. I'd probably set it to c++14 though, to be consistent with gem5 proper. I think that will likely fix a build issue Bobby had with an older (7.x I think) version of gcc, where the default version is probably different from the compiler I'm using (10.x I think). Gabe On Mon, Nov 9, 2020 at 1:50 PM Gabe Black wrote: > Hi folks. If you're using the magic address based version of the gem5 > ops, then you should call, for instance, m5_exit_addr and not just > m5_exit. > The "normal" functions are now always the magic instructions which > essentially only gem5 CPU models know how to execute. All call mechanisms > are built into the library at once now so you can use the same binary on > the KVM CPU, native gem5 CPUs, etc. > > You also should not change the scons files when you build. The old > Makefile based setup required tinkering with things to get the build you > wanted, but that is no longer necessary. If you need to, that's a bug and > we should look into
[gem5-users] Re: Magic instructions with GCN3 Model/hipcc return 0
Using the m5 library in SE mode is somewhat uncharted waters. You'd need the access to /dev/mem to be captured and to map memory in the simulation and not on the host, or Very Bad Things might happen to your host computer. If the functions are defined in the header but you can't use them, you should make sure you're actually getting the right header and not some other, older version. The code which implements the ABI for address based m5 ops in x86 is in src/arch/x86/tlb.cc in finalizePhysical, where it sets the "local accessor" for the request, aka a callback which handles an access which conceptually does not go out into the memory system and is instead handled inside the CPU. The default, instruction based mechanism will *not* work on a KVM based CPU (if that's what you're using), and so no pseudo inst code of any kind will be invoked. If you're actually triggering the address based mechanism but you're not using a virtual address which maps to the correct physical address (the physical address is what's special), then no pseudo inst code will be triggered then either. Basically if you don't do the right dance to get gem5's attention, then it won't know you're trying to do a pseudo instruction and will do something else instead. Unfortunately exactly what gets through from whatever the CPU model is to get gem5's attention varies (necessarily) based on how the CPU is implemented, which is why there are all these different calling mechanisms, and some attempt to organize them more systematically in the utility. Gabe On Mon, Nov 9, 2020 at 4:40 PM Daniel Gerzhoy wrote: > Hi Gabe, > > I can see where the register should be stored (line 59 in > pseudo_inst_abi.hh) but I put a print there and it never gets called for > the calls that I am making at least. > > When i try to use m5_exit_addr and other functions with that suffix I get > a "error: 'm5_exit_addr' was not declared in this scope" > Which makes sense because m5ops.h doesn't declare the functions, I can see > they are built by macro though. > > I've also tried to run map_m5_mem() but I get the "Can't open /dev/mem" > error message. > > Could you point me to, or could you quickly throw together an example > 'hello-world' type program and build process for SE mode? > > Thanks, > > Dan > > > > > On Mon, Nov 9, 2020 at 6:48 PM Matt Sinclair via gem5-users < > gem5-users@gem5.org> wrote: > >> Hi Gabe, >> >> I don't have the broken build in front of me, and it's possible it is >> because I'm running on an Ubuntu 16 machine, but I had to add c+11 per the >> error message I got when debugging this. If c++14 works though, great. >> >> Thanks for the updated info -- I built the tutorial out of the old one, >> so next time I'll make sure to update it accordingly. >> >> Thanks, >> Matt >> >> On Mon, Nov 9, 2020 at 5:44 PM Gabe Black via gem5-users < >> gem5-users@gem5.org> wrote: >> >>> BTW, I do think I need to explicitly set the c++ version in the scons >>> file, like in Matt's original email above. I'd probably set it to c++14 >>> though, to be consistent with gem5 proper. I think that will likely fix a >>> build issue Bobby had with an older (7.x I think) version of gcc, where the >>> default version is probably different from the compiler I'm using (10.x I >>> think). >>> >>> Gabe >>> >>> On Mon, Nov 9, 2020 at 1:50 PM Gabe Black wrote: >>> Hi folks. If you're using the magic address based version of the gem5 ops, then you should call, for instance, m5_exit_addr and not just m5_exit. The "normal" functions are now always the magic instructions which essentially only gem5 CPU models know how to execute. All call mechanisms are built into the library at once now so you can use the same binary on the KVM CPU, native gem5 CPUs, etc. You also should not change the scons files when you build. The old Makefile based setup required tinkering with things to get the build you wanted, but that is no longer necessary. If you need to, that's a bug and we should look into it. The lines you're commenting out just set the default magic address, and that's only there for legacy reasons. You can set the address to use from the command line if you're using the m5 utility, or by setting the m5op_addr variable if using the library. You still have to run map_m5_mem to make the magic physical address visible to userspace for the library to work, or otherwise set up a virtual to physical mapping if you were, for instance, running in the kernel which somebody was doing recently. If you try to use a call mechanism that isn't supported by your CPU model, then the behavior will be unpredictable. For x86 on the KVM CPU for example, the special gem5 instructions will do whatever they look like they should do on real hardware. That may be a nop, it may be to generate an undefined instruction exception, etc. If it's a nop, it will just leave whatever is in RAX
[gem5-users] Re: Magic instructions with GCN3 Model/hipcc return 0
Hi Gabe,
I can see where the register should be stored (line 59 in
pseudo_inst_abi.hh) but I put a print there and it never gets called for
the calls that I am making at least.
When i try to use m5_exit_addr and other functions with that suffix I get a
"error: 'm5_exit_addr' was not declared in this scope"
Which makes sense because m5ops.h doesn't declare the functions, I can see
they are built by macro though.
I've also tried to run map_m5_mem() but I get the "Can't open /dev/mem"
error message.
Could you point me to, or could you quickly throw together an example
'hello-world' type program and build process for SE mode?
Thanks,
Dan
On Mon, Nov 9, 2020 at 6:48 PM Matt Sinclair via gem5-users <
gem5-users@gem5.org> wrote:
> Hi Gabe,
>
> I don't have the broken build in front of me, and it's possible it is
> because I'm running on an Ubuntu 16 machine, but I had to add c+11 per the
> error message I got when debugging this. If c++14 works though, great.
>
> Thanks for the updated info -- I built the tutorial out of the old one, so
> next time I'll make sure to update it accordingly.
>
> Thanks,
> Matt
>
> On Mon, Nov 9, 2020 at 5:44 PM Gabe Black via gem5-users <
> gem5-users@gem5.org> wrote:
>
>> BTW, I do think I need to explicitly set the c++ version in the scons
>> file, like in Matt's original email above. I'd probably set it to c++14
>> though, to be consistent with gem5 proper. I think that will likely fix a
>> build issue Bobby had with an older (7.x I think) version of gcc, where the
>> default version is probably different from the compiler I'm using (10.x I
>> think).
>>
>> Gabe
>>
>> On Mon, Nov 9, 2020 at 1:50 PM Gabe Black wrote:
>>
>>> Hi folks. If you're using the magic address based version of the gem5
>>> ops, then you should call, for instance, m5_exit_addr and not just m5_exit.
>>> The "normal" functions are now always the magic instructions which
>>> essentially only gem5 CPU models know how to execute. All call mechanisms
>>> are built into the library at once now so you can use the same binary on
>>> the KVM CPU, native gem5 CPUs, etc.
>>>
>>> You also should not change the scons files when you build. The old
>>> Makefile based setup required tinkering with things to get the build you
>>> wanted, but that is no longer necessary. If you need to, that's a bug and
>>> we should look into it. The lines you're commenting out just set the
>>> default magic address, and that's only there for legacy reasons. You can
>>> set the address to use from the command line if you're using the m5
>>> utility, or by setting the m5op_addr variable if using the library. You
>>> still have to run map_m5_mem to make the magic physical address visible to
>>> userspace for the library to work, or otherwise set up a virtual to
>>> physical mapping if you were, for instance, running in the kernel which
>>> somebody was doing recently.
>>>
>>> If you try to use a call mechanism that isn't supported by your CPU
>>> model, then the behavior will be unpredictable. For x86 on the KVM CPU for
>>> example, the special gem5 instructions will do whatever they look like they
>>> should do on real hardware. That may be a nop, it may be to generate an
>>> undefined instruction exception, etc. If it's a nop, it will just leave
>>> whatever is in RAX in RAX.
>>>
>>> Also, argument values and return values are now handled by a layer which
>>> knows and applies the actual ABI rules for a given ISA and for the specific
>>> types of the arguments and return value. There should be no reason to
>>> change the code which is calling the pseudo instruction to explicitly set
>>> RAX, especially if you're using the address based calling mechanism which
>>> doesn't go through that path at all.
>>>
>>> Gabe
>>>
>>> On Mon, Nov 9, 2020 at 1:06 PM Matt Sinclair via gem5-users <
>>> gem5-users@gem5.org> wrote:
>>>
Hi Dan,
My comment was just a general comment on the m5ops -- I thought you
were using the "old" format for building m5ops and that might have been the
problem. Sounds like it wasn't.
I think pushing a fix to develop and tagging Gabe and Jason as
reviewers is probably the right strategy.
Thanks,
Matt
On Mon, Nov 9, 2020 at 2:33 PM Daniel Gerzhoy
wrote:
> I found the issue and fixed it.
>
> The return value wasn't being put into the Rax register in
> src/arch/x86/isa/decoder/two_byte_opcodes.isa
>
> 0x4: BasicOperate::gem5Op({{
> uint64_t ret;
> bool recognized =
> PseudoInst::pseudoInst(
> xc->tcBase(), IMMEDIATE, ret);
> if (!recognized)
> fault = std::make_shared();
> Rax = ret;
>
> //<< }}, IsNonSpeculative);
>
> This code was simplified with the new abi stuff and the Rax = ret;
> must have
[gem5-users] Re: Magic instructions with GCN3 Model/hipcc return 0
Hi Gabe,
I don't have the broken build in front of me, and it's possible it is
because I'm running on an Ubuntu 16 machine, but I had to add c+11 per the
error message I got when debugging this. If c++14 works though, great.
Thanks for the updated info -- I built the tutorial out of the old one, so
next time I'll make sure to update it accordingly.
Thanks,
Matt
On Mon, Nov 9, 2020 at 5:44 PM Gabe Black via gem5-users <
gem5-users@gem5.org> wrote:
> BTW, I do think I need to explicitly set the c++ version in the scons
> file, like in Matt's original email above. I'd probably set it to c++14
> though, to be consistent with gem5 proper. I think that will likely fix a
> build issue Bobby had with an older (7.x I think) version of gcc, where the
> default version is probably different from the compiler I'm using (10.x I
> think).
>
> Gabe
>
> On Mon, Nov 9, 2020 at 1:50 PM Gabe Black wrote:
>
>> Hi folks. If you're using the magic address based version of the gem5
>> ops, then you should call, for instance, m5_exit_addr and not just m5_exit.
>> The "normal" functions are now always the magic instructions which
>> essentially only gem5 CPU models know how to execute. All call mechanisms
>> are built into the library at once now so you can use the same binary on
>> the KVM CPU, native gem5 CPUs, etc.
>>
>> You also should not change the scons files when you build. The old
>> Makefile based setup required tinkering with things to get the build you
>> wanted, but that is no longer necessary. If you need to, that's a bug and
>> we should look into it. The lines you're commenting out just set the
>> default magic address, and that's only there for legacy reasons. You can
>> set the address to use from the command line if you're using the m5
>> utility, or by setting the m5op_addr variable if using the library. You
>> still have to run map_m5_mem to make the magic physical address visible to
>> userspace for the library to work, or otherwise set up a virtual to
>> physical mapping if you were, for instance, running in the kernel which
>> somebody was doing recently.
>>
>> If you try to use a call mechanism that isn't supported by your CPU
>> model, then the behavior will be unpredictable. For x86 on the KVM CPU for
>> example, the special gem5 instructions will do whatever they look like they
>> should do on real hardware. That may be a nop, it may be to generate an
>> undefined instruction exception, etc. If it's a nop, it will just leave
>> whatever is in RAX in RAX.
>>
>> Also, argument values and return values are now handled by a layer which
>> knows and applies the actual ABI rules for a given ISA and for the specific
>> types of the arguments and return value. There should be no reason to
>> change the code which is calling the pseudo instruction to explicitly set
>> RAX, especially if you're using the address based calling mechanism which
>> doesn't go through that path at all.
>>
>> Gabe
>>
>> On Mon, Nov 9, 2020 at 1:06 PM Matt Sinclair via gem5-users <
>> gem5-users@gem5.org> wrote:
>>
>>> Hi Dan,
>>>
>>> My comment was just a general comment on the m5ops -- I thought you were
>>> using the "old" format for building m5ops and that might have been the
>>> problem. Sounds like it wasn't.
>>>
>>> I think pushing a fix to develop and tagging Gabe and Jason as reviewers
>>> is probably the right strategy.
>>>
>>> Thanks,
>>> Matt
>>>
>>> On Mon, Nov 9, 2020 at 2:33 PM Daniel Gerzhoy
>>> wrote:
>>>
I found the issue and fixed it.
The return value wasn't being put into the Rax register in
src/arch/x86/isa/decoder/two_byte_opcodes.isa
0x4: BasicOperate::gem5Op({{
uint64_t ret;
bool recognized =
PseudoInst::pseudoInst(
xc->tcBase(), IMMEDIATE, ret);
if (!recognized)
fault = std::make_shared();
Rax = ret;
//<<>>> }}, IsNonSpeculative);
This code was simplified with the new abi stuff and the Rax = ret;
must have been lost in the shuffle.
I could push the fix to develop, or should I just make an issue on Jira?
Best,
Dan
On Mon, Nov 9, 2020 at 2:50 PM Daniel Gerzhoy
wrote:
> Let me further say that I know that the magic instructions are being
> called. I am just getting bogus return values.
>
> On Mon, Nov 9, 2020 at 2:18 PM Daniel Gerzhoy <
> daniel.gerz...@gmail.com> wrote:
>
>> Hi Matt,
>>
>> Thanks for this, it's very helpful. However after following the
>> instructions (I had to extrapolate a little because of the directory
>> structure changes you mentioned) I get the same result: Nill returns from
>> the magic instructions.
>> Actually It isn't nill, but a constant no matter what. If I compile
>> my program with -O0 its nill, if with -O2
[gem5-users] Re: Magic instructions with GCN3 Model/hipcc return 0
BTW, I do think I need to explicitly set the c++ version in the scons file,
like in Matt's original email above. I'd probably set it to c++14 though,
to be consistent with gem5 proper. I think that will likely fix a build
issue Bobby had with an older (7.x I think) version of gcc, where the
default version is probably different from the compiler I'm using (10.x I
think).
Gabe
On Mon, Nov 9, 2020 at 1:50 PM Gabe Black wrote:
> Hi folks. If you're using the magic address based version of the gem5 ops,
> then you should call, for instance, m5_exit_addr and not just m5_exit. The
> "normal" functions are now always the magic instructions which essentially
> only gem5 CPU models know how to execute. All call mechanisms are built
> into the library at once now so you can use the same binary on the KVM CPU,
> native gem5 CPUs, etc.
>
> You also should not change the scons files when you build. The old
> Makefile based setup required tinkering with things to get the build you
> wanted, but that is no longer necessary. If you need to, that's a bug and
> we should look into it. The lines you're commenting out just set the
> default magic address, and that's only there for legacy reasons. You can
> set the address to use from the command line if you're using the m5
> utility, or by setting the m5op_addr variable if using the library. You
> still have to run map_m5_mem to make the magic physical address visible to
> userspace for the library to work, or otherwise set up a virtual to
> physical mapping if you were, for instance, running in the kernel which
> somebody was doing recently.
>
> If you try to use a call mechanism that isn't supported by your CPU model,
> then the behavior will be unpredictable. For x86 on the KVM CPU for
> example, the special gem5 instructions will do whatever they look like they
> should do on real hardware. That may be a nop, it may be to generate an
> undefined instruction exception, etc. If it's a nop, it will just leave
> whatever is in RAX in RAX.
>
> Also, argument values and return values are now handled by a layer which
> knows and applies the actual ABI rules for a given ISA and for the specific
> types of the arguments and return value. There should be no reason to
> change the code which is calling the pseudo instruction to explicitly set
> RAX, especially if you're using the address based calling mechanism which
> doesn't go through that path at all.
>
> Gabe
>
> On Mon, Nov 9, 2020 at 1:06 PM Matt Sinclair via gem5-users <
> gem5-users@gem5.org> wrote:
>
>> Hi Dan,
>>
>> My comment was just a general comment on the m5ops -- I thought you were
>> using the "old" format for building m5ops and that might have been the
>> problem. Sounds like it wasn't.
>>
>> I think pushing a fix to develop and tagging Gabe and Jason as reviewers
>> is probably the right strategy.
>>
>> Thanks,
>> Matt
>>
>> On Mon, Nov 9, 2020 at 2:33 PM Daniel Gerzhoy
>> wrote:
>>
>>> I found the issue and fixed it.
>>>
>>> The return value wasn't being put into the Rax register in
>>> src/arch/x86/isa/decoder/two_byte_opcodes.isa
>>>
>>> 0x4: BasicOperate::gem5Op({{
>>> uint64_t ret;
>>> bool recognized =
>>> PseudoInst::pseudoInst(
>>> xc->tcBase(), IMMEDIATE, ret);
>>> if (!recognized)
>>> fault = std::make_shared();
>>> Rax = ret;
>>>
>>> //<<>> }}, IsNonSpeculative);
>>>
>>> This code was simplified with the new abi stuff and the Rax = ret;
>>> must have been lost in the shuffle.
>>>
>>> I could push the fix to develop, or should I just make an issue on Jira?
>>>
>>> Best,
>>>
>>> Dan
>>>
>>> On Mon, Nov 9, 2020 at 2:50 PM Daniel Gerzhoy
>>> wrote:
>>>
Let me further say that I know that the magic instructions are being
called. I am just getting bogus return values.
On Mon, Nov 9, 2020 at 2:18 PM Daniel Gerzhoy
wrote:
> Hi Matt,
>
> Thanks for this, it's very helpful. However after following the
> instructions (I had to extrapolate a little because of the directory
> structure changes you mentioned) I get the same result: Nill returns from
> the magic instructions.
> Actually It isn't nill, but a constant no matter what. If I compile my
> program with -O0 its nill, if with -O2 its: 4198192, which is suspicious.
>
> To clarify, are these updated instructions specifically meant to fix
> this issue I am running into? Or just general instructions to build m5op.o
>
> Here are the specific changes I made according to the link you
> provided, the supplemental instructions, and extrapolating based on the
> directory structure change.
>
> 1. In SConsopts I commented both:
>
> --- a/util/m5/src/abi/x86/SConsopts
> +++ b/util/m5/src/abi/x86/SConsopts
> @@ -27,8 +27,8 @@ Import('*')
>
> env['ABI'] = 'x86'
>
[gem5-users] Re: Magic instructions with GCN3 Model/hipcc return 0
Hi folks. If you're using the magic address based version of the gem5 ops,
then you should call, for instance, m5_exit_addr and not just m5_exit. The
"normal" functions are now always the magic instructions which essentially
only gem5 CPU models know how to execute. All call mechanisms are built
into the library at once now so you can use the same binary on the KVM CPU,
native gem5 CPUs, etc.
You also should not change the scons files when you build. The old Makefile
based setup required tinkering with things to get the build you wanted, but
that is no longer necessary. If you need to, that's a bug and we should
look into it. The lines you're commenting out just set the default magic
address, and that's only there for legacy reasons. You can set the address
to use from the command line if you're using the m5 utility, or by setting
the m5op_addr variable if using the library. You still have to run
map_m5_mem to make the magic physical address visible to userspace for the
library to work, or otherwise set up a virtual to physical mapping if you
were, for instance, running in the kernel which somebody was doing recently.
If you try to use a call mechanism that isn't supported by your CPU model,
then the behavior will be unpredictable. For x86 on the KVM CPU for
example, the special gem5 instructions will do whatever they look like they
should do on real hardware. That may be a nop, it may be to generate an
undefined instruction exception, etc. If it's a nop, it will just leave
whatever is in RAX in RAX.
Also, argument values and return values are now handled by a layer which
knows and applies the actual ABI rules for a given ISA and for the specific
types of the arguments and return value. There should be no reason to
change the code which is calling the pseudo instruction to explicitly set
RAX, especially if you're using the address based calling mechanism which
doesn't go through that path at all.
Gabe
On Mon, Nov 9, 2020 at 1:06 PM Matt Sinclair via gem5-users <
gem5-users@gem5.org> wrote:
> Hi Dan,
>
> My comment was just a general comment on the m5ops -- I thought you were
> using the "old" format for building m5ops and that might have been the
> problem. Sounds like it wasn't.
>
> I think pushing a fix to develop and tagging Gabe and Jason as reviewers
> is probably the right strategy.
>
> Thanks,
> Matt
>
> On Mon, Nov 9, 2020 at 2:33 PM Daniel Gerzhoy
> wrote:
>
>> I found the issue and fixed it.
>>
>> The return value wasn't being put into the Rax register in
>> src/arch/x86/isa/decoder/two_byte_opcodes.isa
>>
>> 0x4: BasicOperate::gem5Op({{
>> uint64_t ret;
>> bool recognized =
>> PseudoInst::pseudoInst(
>> xc->tcBase(), IMMEDIATE, ret);
>> if (!recognized)
>> fault = std::make_shared();
>> Rax = ret;
>>
>> //<<> }}, IsNonSpeculative);
>>
>> This code was simplified with the new abi stuff and the Rax = ret; must
>> have been lost in the shuffle.
>>
>> I could push the fix to develop, or should I just make an issue on Jira?
>>
>> Best,
>>
>> Dan
>>
>> On Mon, Nov 9, 2020 at 2:50 PM Daniel Gerzhoy
>> wrote:
>>
>>> Let me further say that I know that the magic instructions are being
>>> called. I am just getting bogus return values.
>>>
>>> On Mon, Nov 9, 2020 at 2:18 PM Daniel Gerzhoy
>>> wrote:
>>>
Hi Matt,
Thanks for this, it's very helpful. However after following the
instructions (I had to extrapolate a little because of the directory
structure changes you mentioned) I get the same result: Nill returns from
the magic instructions.
Actually It isn't nill, but a constant no matter what. If I compile my
program with -O0 its nill, if with -O2 its: 4198192, which is suspicious.
To clarify, are these updated instructions specifically meant to fix
this issue I am running into? Or just general instructions to build m5op.o
Here are the specific changes I made according to the link you
provided, the supplemental instructions, and extrapolating based on the
directory structure change.
1. In SConsopts I commented both:
--- a/util/m5/src/abi/x86/SConsopts
+++ b/util/m5/src/abi/x86/SConsopts
@@ -27,8 +27,8 @@ Import('*')
env['ABI'] = 'x86'
get_abi_opt('CROSS_COMPILE', '')
-env.Append(CXXFLAGS='-DM5OP_ADDR=0x')
-env.Append(CCFLAGS='-DM5OP_ADDR=0x')
+#env.Append(CXXFLAGS='-DM5OP_ADDR=0x')
+#env.Append(CCFLAGS='-DM5OP_ADDR=0x')
env['CALL_TYPE']['inst'].impl('m5op.S', 'verify_inst.cc')
env['CALL_TYPE']['addr'].impl('m5op_addr.S', default=True)
2. In SConstruct I added:
--- a/util/m5/SConstruct
+++ b/util/m5/SConstruct
@@ -44,7 +44,9 @@ def abspath(d):
# Universal settings.
main.Append(CXXFLAGS=[
[gem5-users] Re: Magic instructions with GCN3 Model/hipcc return 0
Hi Dan,
My comment was just a general comment on the m5ops -- I thought you were
using the "old" format for building m5ops and that might have been the
problem. Sounds like it wasn't.
I think pushing a fix to develop and tagging Gabe and Jason as reviewers is
probably the right strategy.
Thanks,
Matt
On Mon, Nov 9, 2020 at 2:33 PM Daniel Gerzhoy
wrote:
> I found the issue and fixed it.
>
> The return value wasn't being put into the Rax register in
> src/arch/x86/isa/decoder/two_byte_opcodes.isa
>
> 0x4: BasicOperate::gem5Op({{
> uint64_t ret;
> bool recognized = PseudoInst::pseudoInst(
> xc->tcBase(), IMMEDIATE, ret);
> if (!recognized)
> fault = std::make_shared();
> Rax = ret;
>
> //<< }}, IsNonSpeculative);
>
> This code was simplified with the new abi stuff and the Rax = ret; must
> have been lost in the shuffle.
>
> I could push the fix to develop, or should I just make an issue on Jira?
>
> Best,
>
> Dan
>
> On Mon, Nov 9, 2020 at 2:50 PM Daniel Gerzhoy
> wrote:
>
>> Let me further say that I know that the magic instructions are being
>> called. I am just getting bogus return values.
>>
>> On Mon, Nov 9, 2020 at 2:18 PM Daniel Gerzhoy
>> wrote:
>>
>>> Hi Matt,
>>>
>>> Thanks for this, it's very helpful. However after following the
>>> instructions (I had to extrapolate a little because of the directory
>>> structure changes you mentioned) I get the same result: Nill returns from
>>> the magic instructions.
>>> Actually It isn't nill, but a constant no matter what. If I compile my
>>> program with -O0 its nill, if with -O2 its: 4198192, which is suspicious.
>>>
>>> To clarify, are these updated instructions specifically meant to fix
>>> this issue I am running into? Or just general instructions to build m5op.o
>>>
>>> Here are the specific changes I made according to the link you provided,
>>> the supplemental instructions, and extrapolating based on the directory
>>> structure change.
>>>
>>> 1. In SConsopts I commented both:
>>>
>>> --- a/util/m5/src/abi/x86/SConsopts
>>> +++ b/util/m5/src/abi/x86/SConsopts
>>> @@ -27,8 +27,8 @@ Import('*')
>>>
>>> env['ABI'] = 'x86'
>>> get_abi_opt('CROSS_COMPILE', '')
>>> -env.Append(CXXFLAGS='-DM5OP_ADDR=0x')
>>> -env.Append(CCFLAGS='-DM5OP_ADDR=0x')
>>> +#env.Append(CXXFLAGS='-DM5OP_ADDR=0x')
>>> +#env.Append(CCFLAGS='-DM5OP_ADDR=0x')
>>>
>>> env['CALL_TYPE']['inst'].impl('m5op.S', 'verify_inst.cc')
>>> env['CALL_TYPE']['addr'].impl('m5op_addr.S', default=True)
>>>
>>> 2. In SConstruct I added:
>>>
>>> --- a/util/m5/SConstruct
>>> +++ b/util/m5/SConstruct
>>> @@ -44,7 +44,9 @@ def abspath(d):
>>>
>>> # Universal settings.
>>> main.Append(CXXFLAGS=[ '-O2' ])
>>> +main.Append(CXXFLAGS=[ '-std=c++11' ])
>>> main.Append(CCFLAGS=[ '-O2' ])
>>> main.Append(CPPPATH=[ common_include ])
>>>
>>> The compilation process compiles m5op.S with gcc though, so c++11
>>> doesn't have any effect on it. Not sure if that matters.
>>>
>>> 3. Finally I linked both m5_mmap.o and m5op.o as per the instructions
>>> but I am a little wary of m5_mmap
>>>
>>> What does m5_mmap actually do if I don't have M5OP_ADDR defined. It
>>> looks like nothing? Do I need to link it?
>>>
>>> *Is there something inside the program I need to do before calling magic
>>> instructions that has to do with m5_mmap?*
>>>
>>> Thanks for your help,
>>>
>>> Dan
>>>
>>> On Mon, Nov 9, 2020 at 12:12 PM Matt Sinclair
>>> wrote:
>>>
Hi Dan,
In recent weeks, Gabe (if I recall correctly) updated how the m5ops are
created. I had created a homework assignment for my course about it:
https://pages.cs.wisc.edu/~sinclair/courses/cs752/fall2020/handouts/hw3.html
(see #2), but this is now already out of date as the location of some files
changed. The updated instructions are:
1. Update $GEM5_ROOT/util/m5/SConstruct, add a new line between the
current lines 46 and 47:
main.Append(CXXFLAGS=[ '-O2' ])
*+main.Append(CXXFLAGS=[ '-std=c++11' ])*
main.Append(CCFLAGS=[ '-O2' ])
2. Now run the same command you ran in step 2 of the above link:
scons build/x86/out/m5
3. This will create the same two .o files in step 2 of the above link,
in the same places (although the location of m5op.o may have changed
to include/gem5 util/m5/build/x86/abi/x86/ according to some of the
students in my course).
Matt
On Mon, Nov 9, 2020 at 9:25 AM Daniel Gerzhoy via gem5-users <
gem5-users@gem5.org> wrote:
> Hey all,
>
> I've recently updated to using the dev branch for my GCN3 simulations.
> I've noticed that I am now getting return values of 0 for every magic
> instruction (m5_rpns for instance).
>
> Is there a special way I need to be compiling/linking
[gem5-users] Re: Magic instructions with GCN3 Model/hipcc return 0
I found the issue and fixed it.
The return value wasn't being put into the Rax register in
src/arch/x86/isa/decoder/two_byte_opcodes.isa
0x4: BasicOperate::gem5Op({{
uint64_t ret;
bool recognized = PseudoInst::pseudoInst(
xc->tcBase(), IMMEDIATE, ret);
if (!recognized)
fault = std::make_shared();
Rax = ret;
//<<
wrote:
> Let me further say that I know that the magic instructions are being
> called. I am just getting bogus return values.
>
> On Mon, Nov 9, 2020 at 2:18 PM Daniel Gerzhoy
> wrote:
>
>> Hi Matt,
>>
>> Thanks for this, it's very helpful. However after following the
>> instructions (I had to extrapolate a little because of the directory
>> structure changes you mentioned) I get the same result: Nill returns from
>> the magic instructions.
>> Actually It isn't nill, but a constant no matter what. If I compile my
>> program with -O0 its nill, if with -O2 its: 4198192, which is suspicious.
>>
>> To clarify, are these updated instructions specifically meant to fix
>> this issue I am running into? Or just general instructions to build m5op.o
>>
>> Here are the specific changes I made according to the link you provided,
>> the supplemental instructions, and extrapolating based on the directory
>> structure change.
>>
>> 1. In SConsopts I commented both:
>>
>> --- a/util/m5/src/abi/x86/SConsopts
>> +++ b/util/m5/src/abi/x86/SConsopts
>> @@ -27,8 +27,8 @@ Import('*')
>>
>> env['ABI'] = 'x86'
>> get_abi_opt('CROSS_COMPILE', '')
>> -env.Append(CXXFLAGS='-DM5OP_ADDR=0x')
>> -env.Append(CCFLAGS='-DM5OP_ADDR=0x')
>> +#env.Append(CXXFLAGS='-DM5OP_ADDR=0x')
>> +#env.Append(CCFLAGS='-DM5OP_ADDR=0x')
>>
>> env['CALL_TYPE']['inst'].impl('m5op.S', 'verify_inst.cc')
>> env['CALL_TYPE']['addr'].impl('m5op_addr.S', default=True)
>>
>> 2. In SConstruct I added:
>>
>> --- a/util/m5/SConstruct
>> +++ b/util/m5/SConstruct
>> @@ -44,7 +44,9 @@ def abspath(d):
>>
>> # Universal settings.
>> main.Append(CXXFLAGS=[ '-O2' ])
>> +main.Append(CXXFLAGS=[ '-std=c++11' ])
>> main.Append(CCFLAGS=[ '-O2' ])
>> main.Append(CPPPATH=[ common_include ])
>>
>> The compilation process compiles m5op.S with gcc though, so c++11 doesn't
>> have any effect on it. Not sure if that matters.
>>
>> 3. Finally I linked both m5_mmap.o and m5op.o as per the instructions but
>> I am a little wary of m5_mmap
>>
>> What does m5_mmap actually do if I don't have M5OP_ADDR defined. It looks
>> like nothing? Do I need to link it?
>>
>> *Is there something inside the program I need to do before calling magic
>> instructions that has to do with m5_mmap?*
>>
>> Thanks for your help,
>>
>> Dan
>>
>> On Mon, Nov 9, 2020 at 12:12 PM Matt Sinclair
>> wrote:
>>
>>> Hi Dan,
>>>
>>> In recent weeks, Gabe (if I recall correctly) updated how the m5ops are
>>> created. I had created a homework assignment for my course about it:
>>> https://pages.cs.wisc.edu/~sinclair/courses/cs752/fall2020/handouts/hw3.html
>>> (see #2), but this is now already out of date as the location of some files
>>> changed. The updated instructions are:
>>>
>>> 1. Update $GEM5_ROOT/util/m5/SConstruct, add a new line between the
>>> current lines 46 and 47:
>>>
>>> main.Append(CXXFLAGS=[ '-O2' ])
>>> *+main.Append(CXXFLAGS=[ '-std=c++11' ])*
>>>
>>> main.Append(CCFLAGS=[ '-O2' ])
>>>
>>> 2. Now run the same command you ran in step 2 of the above link:
>>>
>>> scons build/x86/out/m5
>>>
>>> 3. This will create the same two .o files in step 2 of the above link,
>>> in the same places (although the location of m5op.o may have changed to
>>> include/gem5 util/m5/build/x86/abi/x86/ according to some of the
>>> students in my course).
>>> Matt
>>>
>>> On Mon, Nov 9, 2020 at 9:25 AM Daniel Gerzhoy via gem5-users <
>>> gem5-users@gem5.org> wrote:
>>>
Hey all,
I've recently updated to using the dev branch for my GCN3 simulations.
I've noticed that I am now getting return values of 0 for every magic
instruction (m5_rpns for instance).
Is there a special way I need to be compiling/linking m5ops.S to get
the return values to show up correctly? Or might this be a bug?
Thanks,
Dan
___
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: Magic instructions with GCN3 Model/hipcc return 0
Let me further say that I know that the magic instructions are being
called. I am just getting bogus return values.
On Mon, Nov 9, 2020 at 2:18 PM Daniel Gerzhoy
wrote:
> Hi Matt,
>
> Thanks for this, it's very helpful. However after following the
> instructions (I had to extrapolate a little because of the directory
> structure changes you mentioned) I get the same result: Nill returns from
> the magic instructions.
> Actually It isn't nill, but a constant no matter what. If I compile my
> program with -O0 its nill, if with -O2 its: 4198192, which is suspicious.
>
> To clarify, are these updated instructions specifically meant to fix
> this issue I am running into? Or just general instructions to build m5op.o
>
> Here are the specific changes I made according to the link you provided,
> the supplemental instructions, and extrapolating based on the directory
> structure change.
>
> 1. In SConsopts I commented both:
>
> --- a/util/m5/src/abi/x86/SConsopts
> +++ b/util/m5/src/abi/x86/SConsopts
> @@ -27,8 +27,8 @@ Import('*')
>
> env['ABI'] = 'x86'
> get_abi_opt('CROSS_COMPILE', '')
> -env.Append(CXXFLAGS='-DM5OP_ADDR=0x')
> -env.Append(CCFLAGS='-DM5OP_ADDR=0x')
> +#env.Append(CXXFLAGS='-DM5OP_ADDR=0x')
> +#env.Append(CCFLAGS='-DM5OP_ADDR=0x')
>
> env['CALL_TYPE']['inst'].impl('m5op.S', 'verify_inst.cc')
> env['CALL_TYPE']['addr'].impl('m5op_addr.S', default=True)
>
> 2. In SConstruct I added:
>
> --- a/util/m5/SConstruct
> +++ b/util/m5/SConstruct
> @@ -44,7 +44,9 @@ def abspath(d):
>
> # Universal settings.
> main.Append(CXXFLAGS=[ '-O2' ])
> +main.Append(CXXFLAGS=[ '-std=c++11' ])
> main.Append(CCFLAGS=[ '-O2' ])
> main.Append(CPPPATH=[ common_include ])
>
> The compilation process compiles m5op.S with gcc though, so c++11 doesn't
> have any effect on it. Not sure if that matters.
>
> 3. Finally I linked both m5_mmap.o and m5op.o as per the instructions but
> I am a little wary of m5_mmap
>
> What does m5_mmap actually do if I don't have M5OP_ADDR defined. It looks
> like nothing? Do I need to link it?
>
> *Is there something inside the program I need to do before calling magic
> instructions that has to do with m5_mmap?*
>
> Thanks for your help,
>
> Dan
>
> On Mon, Nov 9, 2020 at 12:12 PM Matt Sinclair
> wrote:
>
>> Hi Dan,
>>
>> In recent weeks, Gabe (if I recall correctly) updated how the m5ops are
>> created. I had created a homework assignment for my course about it:
>> https://pages.cs.wisc.edu/~sinclair/courses/cs752/fall2020/handouts/hw3.html
>> (see #2), but this is now already out of date as the location of some files
>> changed. The updated instructions are:
>>
>> 1. Update $GEM5_ROOT/util/m5/SConstruct, add a new line between the
>> current lines 46 and 47:
>>
>> main.Append(CXXFLAGS=[ '-O2' ])
>> *+main.Append(CXXFLAGS=[ '-std=c++11' ])*
>>
>> main.Append(CCFLAGS=[ '-O2' ])
>>
>> 2. Now run the same command you ran in step 2 of the above link:
>>
>> scons build/x86/out/m5
>>
>> 3. This will create the same two .o files in step 2 of the above link,
>> in the same places (although the location of m5op.o may have changed to
>> include/gem5 util/m5/build/x86/abi/x86/ according to some of the
>> students in my course).
>> Matt
>>
>> On Mon, Nov 9, 2020 at 9:25 AM Daniel Gerzhoy via gem5-users <
>> gem5-users@gem5.org> wrote:
>>
>>> Hey all,
>>>
>>> I've recently updated to using the dev branch for my GCN3 simulations.
>>> I've noticed that I am now getting return values of 0 for every magic
>>> instruction (m5_rpns for instance).
>>>
>>> Is there a special way I need to be compiling/linking m5ops.S to get the
>>> return values to show up correctly? Or might this be a bug?
>>>
>>> Thanks,
>>>
>>> Dan
>>> ___
>>> 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: Magic instructions with GCN3 Model/hipcc return 0
Hi Matt,
Thanks for this, it's very helpful. However after following the
instructions (I had to extrapolate a little because of the directory
structure changes you mentioned) I get the same result: Nill returns from
the magic instructions.
Actually It isn't nill, but a constant no matter what. If I compile my
program with -O0 its nill, if with -O2 its: 4198192, which is suspicious.
To clarify, are these updated instructions specifically meant to fix
this issue I am running into? Or just general instructions to build m5op.o
Here are the specific changes I made according to the link you provided,
the supplemental instructions, and extrapolating based on the directory
structure change.
1. In SConsopts I commented both:
--- a/util/m5/src/abi/x86/SConsopts
+++ b/util/m5/src/abi/x86/SConsopts
@@ -27,8 +27,8 @@ Import('*')
env['ABI'] = 'x86'
get_abi_opt('CROSS_COMPILE', '')
-env.Append(CXXFLAGS='-DM5OP_ADDR=0x')
-env.Append(CCFLAGS='-DM5OP_ADDR=0x')
+#env.Append(CXXFLAGS='-DM5OP_ADDR=0x')
+#env.Append(CCFLAGS='-DM5OP_ADDR=0x')
env['CALL_TYPE']['inst'].impl('m5op.S', 'verify_inst.cc')
env['CALL_TYPE']['addr'].impl('m5op_addr.S', default=True)
2. In SConstruct I added:
--- a/util/m5/SConstruct
+++ b/util/m5/SConstruct
@@ -44,7 +44,9 @@ def abspath(d):
# Universal settings.
main.Append(CXXFLAGS=[ '-O2' ])
+main.Append(CXXFLAGS=[ '-std=c++11' ])
main.Append(CCFLAGS=[ '-O2' ])
main.Append(CPPPATH=[ common_include ])
The compilation process compiles m5op.S with gcc though, so c++11 doesn't
have any effect on it. Not sure if that matters.
3. Finally I linked both m5_mmap.o and m5op.o as per the instructions but I
am a little wary of m5_mmap
What does m5_mmap actually do if I don't have M5OP_ADDR defined. It looks
like nothing? Do I need to link it?
*Is there something inside the program I need to do before calling magic
instructions that has to do with m5_mmap?*
Thanks for your help,
Dan
On Mon, Nov 9, 2020 at 12:12 PM Matt Sinclair
wrote:
> Hi Dan,
>
> In recent weeks, Gabe (if I recall correctly) updated how the m5ops are
> created. I had created a homework assignment for my course about it:
> https://pages.cs.wisc.edu/~sinclair/courses/cs752/fall2020/handouts/hw3.html
> (see #2), but this is now already out of date as the location of some files
> changed. The updated instructions are:
>
> 1. Update $GEM5_ROOT/util/m5/SConstruct, add a new line between the
> current lines 46 and 47:
>
> main.Append(CXXFLAGS=[ '-O2' ])
> *+main.Append(CXXFLAGS=[ '-std=c++11' ])*
>
> main.Append(CCFLAGS=[ '-O2' ])
>
> 2. Now run the same command you ran in step 2 of the above link:
>
> scons build/x86/out/m5
>
> 3. This will create the same two .o files in step 2 of the above link, in
> the same places (although the location of m5op.o may have changed to
> include/gem5 util/m5/build/x86/abi/x86/ according to some of the students
> in my course).
> Matt
>
> On Mon, Nov 9, 2020 at 9:25 AM Daniel Gerzhoy via gem5-users <
> gem5-users@gem5.org> wrote:
>
>> Hey all,
>>
>> I've recently updated to using the dev branch for my GCN3 simulations.
>> I've noticed that I am now getting return values of 0 for every magic
>> instruction (m5_rpns for instance).
>>
>> Is there a special way I need to be compiling/linking m5ops.S to get the
>> return values to show up correctly? Or might this be a bug?
>>
>> Thanks,
>>
>> Dan
>> ___
>> 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: Magic instructions with GCN3 Model/hipcc return 0
Hi Dan, In recent weeks, Gabe (if I recall correctly) updated how the m5ops are created. I had created a homework assignment for my course about it: https://pages.cs.wisc.edu/~sinclair/courses/cs752/fall2020/handouts/hw3.html (see #2), but this is now already out of date as the location of some files changed. The updated instructions are: 1. Update $GEM5_ROOT/util/m5/SConstruct, add a new line between the current lines 46 and 47: main.Append(CXXFLAGS=[ '-O2' ]) *+main.Append(CXXFLAGS=[ '-std=c++11' ])* main.Append(CCFLAGS=[ '-O2' ]) 2. Now run the same command you ran in step 2 of the above link: scons build/x86/out/m5 3. This will create the same two .o files in step 2 of the above link, in the same places (although the location of m5op.o may have changed to include/gem5 util/m5/build/x86/abi/x86/ according to some of the students in my course). Matt On Mon, Nov 9, 2020 at 9:25 AM Daniel Gerzhoy via gem5-users < gem5-users@gem5.org> wrote: > Hey all, > > I've recently updated to using the dev branch for my GCN3 simulations. > I've noticed that I am now getting return values of 0 for every magic > instruction (m5_rpns for instance). > > Is there a special way I need to be compiling/linking m5ops.S to get the > return values to show up correctly? Or might this be a bug? > > Thanks, > > Dan > ___ > 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
