At 10:38 AM -0700 9/24/01, Clifford Click wrote:
>
>Thus I claim the semantics come first; from these we can derive
>the allowed transformations.
Correct. The semantics should not enumerate the allowed
optimizations. Instead, they describe the allowed behaviors.
However, if you want to allow certain transformations or combinations
of transformations, you need to make sure that the semantics allow
the behavior that could be produced by those transformations.
>I.e., there are many possible results from program 1 but with these
>semantics, "r1=r2=r3=2" is not a possible result. Thus I can do
>any transform I like as long as the transformed program running on
>my hardware never produces this result. Choosing transforms here
>is tough because the semantics require me to look non-thread-local
>to determine correctness. In otherwords, these semantics suck.
No, I am trying to devise a semantics that is strictly weaker than
the "Can only look at thread-local data" semantics. So if you want to
do transformations that only depend upon thread-local data, you are
fine. You don't need to look at non-thread-local information.
However, I am trying to allow for the possibility of transformations
that look at non-thread-local information.
>I thought semantics was about the precise definitions - 100% - of what
>was legal or not. Isn't denotational semantics all about this?
Formal semantics allow you to specify with absolute precision what
the allowed behaviors are. They do not allow 100% certainty that in
the future no one will ever devise an architecture or desirable
transformation that violates the existing formal semantics.
Bill
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:35 EDT