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
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
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
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
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
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
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
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.
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(
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
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
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
12 matches
Mail list logo
