As far as explicitly vs. implicitly using the stack segment, I wasn't able
to find a very conclusive answer while looking through the manuals. This
would be something to check by running a little test program on an actual
computer, although I suspect implicit vs. explicit does matter.
One
Yeah, it's a major problem that we say that we support macOS and others
when we allow commits that break builds on these other OSes.
If we are going to say that we have support for OSes other than Linux, we
need to at least verify gem5 builds on these OSes, preferably before
accepting a commit.
I'm leaning towards deleting the AddrSizeFlagBit. Gabe, can you shed some
light on the purpose of this flag? It's only ever used for masking
addresses in the TLB:
http://grok.gem5.org/xref/gem5/src/arch/x86/tlb.cc#318
http://grok.gem5.org/xref/gem5/src/arch/x86/tlb.cc#330
From what I can
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3791/#review9319
---
Ship it!
Ship It!
- Tony Gutierrez
On Jan. 25, 2017, 3:28 a.m.,
Hi all,
A large-sized project for some crafty person out there: A
binary-translation CPU for fast-forwarding, much like the KVMCpu, but more
portable. It could, for example, be built on top of the Tiny Code
Generator (TCG), as it is BSD licensed.
Quite a big task, but also a very big
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3773/#review9318
---
Ship it!
Ship It!
- Brad Beckmann
On Jan. 25, 2017, 6:49 a.m., Joel
Thanks, Gabe! That's all really helpful. I appreciate you taking the time
to respond.
One concern I have is that the portion of the manual Jason quoted says the
rule holds "For instructions that
*implicitly* access the stack segment (SS)" (emphasis mine)... would you
say then that instructions
Here are some ideas we at AMD have for the sprint.
1) Adding checkpointing support to the GPU model
2) Fixing the structure and design of the GPU coalescer
3) Adding x86 inst tests
4) Properly supporting atomics
5) Add support for event-based scheduling in the GPU model, and FUPool-style
Another small project:
Unify PS/2 handling: PS2 is implemented by both the i8042 and PL050
models, but almost no code is shared.
//Andreas
On 23/01/17 15:57, Andreas Sandberg wrote:
Hi Everyone,
Thanks for organising this! See below for some of my ideas.
Small projects:
* Clean up
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3791/#review9317
---
Ship it!
Ship It!
- Jason Lowe-Power
On Jan. 25, 2017, 11:28 a.m.,
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3791/
---
Review request for Default.
Repository: gem5
Description
---
There are
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3781/#review9316
---
Ship it!
Ship It!
- Andreas Sandberg
On Jan. 24, 2017, 4:33 p.m.,
> On Jan. 24, 2017, 9:43 a.m., Andreas Sandberg wrote:
> > Did you remove all files from the reference output directory? In that case,
> > you'll need to add a an empty placeholder file called EMPTY in the
> > reference directories. Some VCS systems (git being one of them) don't track
> >
Forgive me if I'm repeating a bit of what you said, Steve, but I looked a
little more and there's more to fix.
Also, if you look at x86/isa/microops/ldstop.isa, you'll find the python
classes which receive the parameters of the load and store microops and
translate them into C++ instantiations of
Hi. I think you guys are generally interpreting this code correctly, but
I'll throw in my two cents. If you look at the pseudo code here:
http://www.felixcloutier.com/x86/CALL.html
then it appears that the size of the return address you push onto the stack
should be based on the operand size,
15 matches
Mail list logo
