On 2/5/2024 1:39 PM, Nazmus Sakib wrote:
I am trying to see how small I can set the cacheline size (gem5 ARM, test
binary is aarch64)
When I set it to 4 bytes, I get a page fault for address 0x400c00. By going through bunch of debugging (using print of
my own and debug flags), I think the problem is, when trying to generate address 0x400c00, it is only generating 0x400,
and since it is not the VMA list the fixfault() function cannot assign new page, nor can the page table lookip() access
the already assigned page.
I am guessing somehow the MSB of 0x400c00 are lost in address generation. So I was trying to look where this is
happening and why.
I know 4 byte cacheline is unrealistic, and also I am running 64 bit binary, but I want to find the exact reason for
this page fault (I might also be missing some basic understanding of Compter System theory).
Note: cacheline size=8 (byte) works fine !!
------------------------------------------------------------------------------------------------------------------------
*From:* Eliot Moss <m...@cs.umass.edu>
*Sent:* 05 February 2024 09:47
*To:* The gem5 Users mailing list <gem5-users@gem5.org>
*Cc:* Nazmus Sakib <nsak...@nmsu.edu>
*Subject:* Re: [gem5-users] Effective address and ISA
[You don't often get email from m...@cs.umass.edu. Learn why this is important at
https://aka.ms/LearnAboutSenderIdentification <https://aka.ms/LearnAboutSenderIdentification> ]
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.
On 2/5/2024 10:41 AM, Nazmus Sakib via gem5-users wrote:
Hello.
I was trying to find how the virtual (logical) addresses are calculated and
passed on to cpu.
In the load/store queee, after a request object is created, then the
corresponding instruction is assigned a effective
address from this request object, something like inst->effaddr=req->getVirt().I
found setVirt(), the set virtual address
function. But I cannot find who calls this setVirt() and where.
For example: ldr x0, [x1,#1024] // an ARM instruction
Here, the address would be x1+1024. So the content of x1 register plus
immediate 1024.
How and where would this address calculation take place ? Where can I see the
contents of x1 register is added with 1024
? and who would call the setVirt() function ?
As I understand, address calculation is ISA specific, and the dynamic/static
instruction classes works with ISA files to
get this done. I wanted to know how this works, the interface for connecting
ISA features to cpu pipeline.
src/arc/arm/insts/macromem.isa has definitions of micro-ops used for
memory instructions. In there you can find some of the effective
address calculation code being generated (look for eaCode and EA).
See also the instruction templates in src/arc/arm/isa/templates/mem.isa.
These isa files are processed by a custom macro processor to generate
the actual decoding, execution, etc., functions, which you can find
in the build hierarchy.
The whole construction is somewhat complex, but I hope I've answered
your question. Was it just a point of curiosity, or is there something
specific you're trying to do?
Eliot Moss
A guess would be that the code is not set up to expect an aligned 8 byte
quantity might break across cache lines. To make that work, the 8 byte
access would have to be broken into two 4 byte accesses, since each can
miss separately. It would likely take deeper changes to make that work,
though I would think it is possible with concomitant effort.
When you say it is generating 0x400, is that as the whole address? It
looks suspiciously like the page number (i.e., shift right by 12 bits).
But anyway, as I mentioned, a cache line size of 4 bytes has other
problems with it and that may somehow be leading to the behavior you see.
EM
_______________________________________________
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
