× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: Re: writeable constant
  • From: "Larry Loen" <lwloen@xxxxxxxxxx>
  • Date: Mon, 11 Jun 2001 09:26:27 -0500
  • Importance: Normal


>Why does ILE distinguish between read-only constants and writeable
>constants?  What's the difference between a writeable constant and a
static
>variable with initial value?

I couldn't tell you precisely myself.  But, there's a couple of distinct
possibilities that could already be exploited or exploited in the future.
It is certainly useful to have a notion of read only constants:

1.  Read only variables -- when this is known -- can be optimized based on
that assumption.  That is, the code generation might be slightly different.
To take an example from C, it may be possible to change:

myfunct(const *int)   to   myfunct(int)   and an actual call from myfunct(
&i)  to  myfunct(i)   whenever myfunct is in-lined, for instance.  This is
not just a nicety -- it could change the generated code over and above what
in-lining gives.

2.  It could improve performance to ensure read only variables are linked
in a manner which ensures they share the same cache line.  It eventually
costs something, after all, to "push" a cache line out of L1 storage, out
of L2 storage and back to main storage.  But, get enough read only stuff
together and at least one less cache line is changed.

There are probably other possibilities as well, but the system can
certainly exploit knowledge that a given region of storage is not supposed
to change.  It might even be able to enforce it in various ways.

3.  It does seem that a 'writeable constant' is a bit of a misnomer, but
C/C++ casting rules do admit to the possibility.  Usually, it's a bad
programming practice and, I would think, ordinarily a bug.  Without doubt,
casting of this sort is not very portable (see "optimization" above) but
there are probably shipped programs out there that depend on run-time
alteration of constants.   Perhaps the most interesting question is how a
compiler decides to declare the constants writable.  The only legitimate
case I could think of, off-hand, would be to have a constant that is
initialized only at the first time a class is used.  Java certainly has
this notion built-in fairly formally and you can have the same notion in
C++.  Here, you might not know the value until the program runs for the
first time in its activation group ("load" in conventional architectures),
but it might well be constant thereafter.  A "writable constant" might be a
way to permit a compiler (which is able to have some understanding of this
practice) to implement this.  Also, depending on how strictly arbitrary
pointer "aliasing" is being enforced (an optimization flag in many C/C++
compilers and possibly other languages as well), a compiler might feel
compelled to declare all constants writeable for worst-case assumptions
about language requirements.

Again, I don't know how much of this is done by anyone, but
architecturally, I could see how ILE would want to allow for all of this. .
.



Larry W. Loen  -   Senior Java and iSeries Performance Analyst
                          Dept HP4, Rochester MN

Speaking on his own

+---
| This is the MI Programmers Mailing List!
| To submit a new message, send your mail to MI400@midrange.com.
| To subscribe to this list send email to MI400-SUB@midrange.com.
| To unsubscribe from this list send email to MI400-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: dr2@cssas400.com
+---

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.