Re: [m5-dev] Review Request: Ruby: Simplify SLICC and Entry/TBE handling.
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/630/#review1074
---
Ship it!
- Brad
On 2011-03-31 14:26:33, Lisa Hsu wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.m5sim.org/r/630/
> ---
>
> (Updated 2011-03-31 14:26:33)
>
>
> Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and
> Nathan Binkert.
>
>
> Summary
> ---
>
> Ruby: Simplify SLICC and Entry/TBE handling.
> Before this changeset, all local variables of type Entry and TBE were
> considered
> to be pointers, but an immediate use of said variables would not be
> automatically
> deferenced in SLICC-generated code. Instead, deferences occurred when such
> variables were passed to functions, and were automatically dereferenced in
> the bodies of the functions (e.g. the implicitly passed cache_entry).
>
> This is a more general way to do it, which leaves in place the
> assumption that parameters to functions and local variables of type
> AbstractCacheEntry
> and TBE are always pointers, but instead of dereferencing to access member
> variables
> on a contextual basis, the dereferencing automatically occurs on a type basis
> at the
> moment a member is being accessed. So, now, things you can do that you
> couldn't before
> include:
>
> Entry foo := getCacheEntry(address);
> cache_entry.DataBlk := foo.DataBlk;
>
> or
>
> cache_entry.DataBlk := getCacheEntry(address).DataBlk;
>
> or even
>
> cache_entry.DataBlk := static_cast(Entry, pointer,
> cache.lookup(address)).DataBlk;
>
>
> Diffs
> -
>
> src/mem/slicc/ast/ActionDeclAST.py d8587c913ccf
> src/mem/slicc/ast/FormalParamAST.py d8587c913ccf
> src/mem/slicc/ast/FuncCallExprAST.py d8587c913ccf
> src/mem/slicc/ast/IsValidPtrExprAST.py d8587c913ccf
> src/mem/slicc/ast/MemberExprAST.py d8587c913ccf
>
> Diff: http://reviews.m5sim.org/r/630/diff
>
>
> Testing
> ---
>
> So - just to add a note (this is not about testing). I had uploaded a patch,
> then realized that there was some dead code that I should also remove, so I
> uploaded a new patch. However, the head of my tree had changed, and that
> appears to have messed up my ability to update patches. So, two upshots:
>
> One, this newer patch gets rid of the some of the str.replace("*", "") code
> that was in place to auto-remove the *s from m_cache_entry and m_tbe, since
> now, those guys do not have *s by default.
>
> Two, don't change the head of your tree and have outstanding patches at the
> same time, if you think you want to update patches.
>
>
> Thanks,
>
> Lisa
>
>
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: Ruby: Simplify SLICC and Entry/TBE handling.
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/630/#review1066
---
Ship it!
Lisa, the changes look fine to me. Just make sure that all the existing
protocols compile properly.
- Nilay
On 2011-03-31 14:26:33, Lisa Hsu wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.m5sim.org/r/630/
> ---
>
> (Updated 2011-03-31 14:26:33)
>
>
> Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and
> Nathan Binkert.
>
>
> Summary
> ---
>
> Ruby: Simplify SLICC and Entry/TBE handling.
> Before this changeset, all local variables of type Entry and TBE were
> considered
> to be pointers, but an immediate use of said variables would not be
> automatically
> deferenced in SLICC-generated code. Instead, deferences occurred when such
> variables were passed to functions, and were automatically dereferenced in
> the bodies of the functions (e.g. the implicitly passed cache_entry).
>
> This is a more general way to do it, which leaves in place the
> assumption that parameters to functions and local variables of type
> AbstractCacheEntry
> and TBE are always pointers, but instead of dereferencing to access member
> variables
> on a contextual basis, the dereferencing automatically occurs on a type basis
> at the
> moment a member is being accessed. So, now, things you can do that you
> couldn't before
> include:
>
> Entry foo := getCacheEntry(address);
> cache_entry.DataBlk := foo.DataBlk;
>
> or
>
> cache_entry.DataBlk := getCacheEntry(address).DataBlk;
>
> or even
>
> cache_entry.DataBlk := static_cast(Entry, pointer,
> cache.lookup(address)).DataBlk;
>
>
> Diffs
> -
>
> src/mem/slicc/ast/ActionDeclAST.py d8587c913ccf
> src/mem/slicc/ast/FormalParamAST.py d8587c913ccf
> src/mem/slicc/ast/FuncCallExprAST.py d8587c913ccf
> src/mem/slicc/ast/IsValidPtrExprAST.py d8587c913ccf
> src/mem/slicc/ast/MemberExprAST.py d8587c913ccf
>
> Diff: http://reviews.m5sim.org/r/630/diff
>
>
> Testing
> ---
>
> So - just to add a note (this is not about testing). I had uploaded a patch,
> then realized that there was some dead code that I should also remove, so I
> uploaded a new patch. However, the head of my tree had changed, and that
> appears to have messed up my ability to update patches. So, two upshots:
>
> One, this newer patch gets rid of the some of the str.replace("*", "") code
> that was in place to auto-remove the *s from m_cache_entry and m_tbe, since
> now, those guys do not have *s by default.
>
> Two, don't change the head of your tree and have outstanding patches at the
> same time, if you think you want to update patches.
>
>
> Thanks,
>
> Lisa
>
>
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: Ruby: Simplify SLICC and Entry/TBE handling.
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/630/
---
(Updated 2011-03-31 14:26:33.755740)
Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan
Binkert.
Summary
---
Ruby: Simplify SLICC and Entry/TBE handling.
Before this changeset, all local variables of type Entry and TBE were considered
to be pointers, but an immediate use of said variables would not be
automatically
deferenced in SLICC-generated code. Instead, deferences occurred when such
variables were passed to functions, and were automatically dereferenced in
the bodies of the functions (e.g. the implicitly passed cache_entry).
This is a more general way to do it, which leaves in place the
assumption that parameters to functions and local variables of type
AbstractCacheEntry
and TBE are always pointers, but instead of dereferencing to access member
variables
on a contextual basis, the dereferencing automatically occurs on a type basis
at the
moment a member is being accessed. So, now, things you can do that you
couldn't before
include:
Entry foo := getCacheEntry(address);
cache_entry.DataBlk := foo.DataBlk;
or
cache_entry.DataBlk := getCacheEntry(address).DataBlk;
or even
cache_entry.DataBlk := static_cast(Entry, pointer,
cache.lookup(address)).DataBlk;
Diffs
-
src/mem/slicc/ast/ActionDeclAST.py d8587c913ccf
src/mem/slicc/ast/FormalParamAST.py d8587c913ccf
src/mem/slicc/ast/FuncCallExprAST.py d8587c913ccf
src/mem/slicc/ast/IsValidPtrExprAST.py d8587c913ccf
src/mem/slicc/ast/MemberExprAST.py d8587c913ccf
Diff: http://reviews.m5sim.org/r/630/diff
Testing (updated)
---
So - just to add a note (this is not about testing). I had uploaded a patch,
then realized that there was some dead code that I should also remove, so I
uploaded a new patch. However, the head of my tree had changed, and that
appears to have messed up my ability to update patches. So, two upshots:
One, this newer patch gets rid of the some of the str.replace("*", "") code
that was in place to auto-remove the *s from m_cache_entry and m_tbe, since
now, those guys do not have *s by default.
Two, don't change the head of your tree and have outstanding patches at the
same time, if you think you want to update patches.
Thanks,
Lisa
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] Review Request: Ruby: Simplify SLICC and Entry/TBE handling.
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/630/ --- Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- Ruby: Simplify SLICC and Entry/TBE handling. Before this changeset, all local variables of type Entry and TBE were considered to be pointers, but an immediate use of said variables would not be automatically deferenced in SLICC-generated code. Instead, deferences occurred when such variables were passed to functions, and were automatically dereferenced in the bodies of the functions (e.g. the implicitly passed cache_entry). This is a more general way to do it, which leaves in place the assumption that parameters to functions and local variables of type AbstractCacheEntry and TBE are always pointers, but instead of dereferencing to access member variables on a contextual basis, the dereferencing automatically occurs on a type basis at the moment a member is being accessed. So, now, things you can do that you couldn't before include: Entry foo := getCacheEntry(address); cache_entry.DataBlk := foo.DataBlk; or cache_entry.DataBlk := getCacheEntry(address).DataBlk; or even cache_entry.DataBlk := static_cast(Entry, pointer, cache.lookup(address)).DataBlk; Diffs - src/mem/slicc/ast/ActionDeclAST.py d8587c913ccf src/mem/slicc/ast/FormalParamAST.py d8587c913ccf src/mem/slicc/ast/FuncCallExprAST.py d8587c913ccf src/mem/slicc/ast/IsValidPtrExprAST.py d8587c913ccf src/mem/slicc/ast/MemberExprAST.py d8587c913ccf Diff: http://reviews.m5sim.org/r/630/diff Testing --- Thanks, Lisa ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: Ruby: Simplify SLICC and Entry/TBE handling.
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/628/ --- (Updated 2011-03-31 14:13:38.794443) Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- Ruby: Simplify SLICC and Entry/TBE handling. Before this changeset, all local variables of type Entry and TBE were considered to be pointers, but an immediate use of said variables would not be automatically deferenced in SLICC-generated code. Instead, deferences occurred when such variables were passed to functions, and were automatically dereferenced in the bodies of the functions (e.g. the implicitly passed cache_entry). This is a more general way to do it, which leaves in place the assumption that parameters to functions and local variables of type AbstractCacheEntry and TBE are always pointers, but instead of dereferencing to access member variables on a contextual basis, the dereferencing automatically occurs on a type basis at the moment a member is being accessed. So, now, things you can do that you couldn't before include: Entry foo := getCacheEntry(address); cache_entry.DataBlk := foo.DataBlk; or cache_entry.DataBlk := getCacheEntry(address).DataBlk; or even cache_entry.DataBlk := static_cast(Entry, pointer, cache.lookup(address)).DataBlk; Diffs (updated) - src/mem/slicc/ast/ActionDeclAST.py 7ee8e012c038 src/mem/slicc/ast/FormalParamAST.py 7ee8e012c038 src/mem/slicc/ast/FuncCallExprAST.py 7ee8e012c038 src/mem/slicc/ast/IsValidPtrExprAST.py 7ee8e012c038 src/mem/slicc/ast/MemberExprAST.py 7ee8e012c038 Diff: http://reviews.m5sim.org/r/628/diff Testing --- Thanks, Lisa ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] Review Request: Ruby: Simplify SLICC and Entry/TBE handling.
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/628/ --- Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- Ruby: Simplify SLICC and Entry/TBE handling. Before this changeset, all local variables of type Entry and TBE were considered to be pointers, but an immediate use of said variables would not be automatically deferenced in SLICC-generated code. Instead, deferences occurred when such variables were passed to functions, and were automatically dereferenced in the bodies of the functions (e.g. the implicitly passed cache_entry). This is a more general way to do it, which leaves in place the assumption that parameters to functions and local variables of type AbstractCacheEntry and TBE are always pointers, but instead of dereferencing to access member variables on a contextual basis, the dereferencing automatically occurs on a type basis at the moment a member is being accessed. So, now, things you can do that you couldn't before include: Entry foo := getCacheEntry(address); cache_entry.DataBlk := foo.DataBlk; or cache_entry.DataBlk := getCacheEntry(address).DataBlk; or even cache_entry.DataBlk := static_cast(Entry, pointer, cache.lookup(address)).DataBlk; Diffs - src/mem/slicc/ast/ActionDeclAST.py d8587c913ccf src/mem/slicc/ast/FormalParamAST.py d8587c913ccf src/mem/slicc/ast/MemberExprAST.py d8587c913ccf Diff: http://reviews.m5sim.org/r/628/diff Testing --- Thanks, Lisa ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
