Nilay,

I guess since I wrote this patch initially I'll fight for it... I wouldn't
call this fixing the compiler. We're just adding another builtin function,
no new "compiler" features.

Although I can't remember exactly why this was needed for the protocol I
was working on at AMD 3 years ago, there are many cases where references
need to be converted into pointers in SLICC. Since SLICC is really just a
source-to-source compiler that outputs C++, being able to explicitly
extract the pointer of a variable is a useful function.

The way I see it is: this isn't hurting anything. It's 16 lines of code. It
affects nothing outside of the feature it adds. And it provides a useful
function. Why not include it in gem5?

Jason


On Wed, May 13, 2015 at 9:15 AM Nilay Vaish <[email protected]> wrote:

> On Tue, 12 May 2015, Brad Beckmann wrote:
>
> >
> >
> >> On May 12, 2015, 4:05 a.m., Nilay Vaish wrote:
> >>> I need an example why this is required.  What behavior is not
> achievable right now?
> >
> > Here is the initial patch description from a certain intern back in 2012:
> >
> > "Adds a function to slicc to return the pointer of an object or
> reference.
> > This is needed in a few cases where you are not using a CacheMemory as
> the main store in
> > your controller. The other stores (PerfectCacheMemory and
> DirectoryMemory) return a reference
> > as their lookup functions which must be cast to a pointer to work with
> getCacheEntry"
> >
> > Would it be sufficient if I just updated the desciption with this second
> paragraph?
> >
>
>
> If my code is broken, I do not go and fix the compiler.  So fix
> DirectoryMemory and PerfectCacheMemory instead.
>
> I generally try to follow two principles suggested by William Wulf for ISA
> design:
>
> a. If something is done in one way in one place, it ought to be
> done the same way everywhere.
>
> b. There should be precisely one way to do something, or all ways should
> be possible.
>
> I suggest that we follow these in software design as well.
>
> Lastly, I strongly suggest that we avoid, as much as possible, adding new
> keywords to SLICC.
>
> --
> Nilay
> _______________________________________________
> gem5-dev mailing list
> [email protected]
> http://m5sim.org/mailman/listinfo/gem5-dev
>
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev

Reply via email to