On Sat, 18 Jul 2009, Gerhard Fiedler wrote:

> sergio masci wrote:
> 
> > *** YOU *** are saying "'knows' the intent of the line". *** I ***  
> > am saying"'knows' the intent of several seperate lines as one unit"
> 
> Ok. But so far you didn't explain how this is different for language
> elements that are implemented in the compiler versus language elements
> that are implemented in a library. The compiler can only "know" a priori
> what a single language element is doing (for both the built-in elements
> and the ones that are implemented in a standard library); the rest it
> has to figure out based on the program -- independently of where exactly
> the language elements are implemented.
> 
> 
> > I am saying something like:
> > 
> > 	j = x * 2 + y * 2;
> > 
> > 	temp = arr[j];
> > 
> > 	j = (x + y) * 2;
> > 
> > 	arr[j] = temp;
> > 
> > should also be reduced to nothing *** AND *** the compiler should warn
> > the user that this piece of code has no effect and so may be in
> > error. This is not possible if you understand only the intent of
> > single lines but can be fudged by the compiler by keeping track of
> > what is evaluated and where the result is placed. So although the
> > compiler might be able to reduce it to zero it doesn't understand
> > that this might be an error.
> 
> How is this dependent on where the involved operators are defined -- as
> long as the compilers "knows" what they are supposed to do?
> 
> > Things get much more difficult if we re-write the above as:
> > 
> > 	int func_get(int arr[], int x, int y)
> > 	{
> > 		int	j;
> > 
> > 		j = x * 2 + y * 2;
> > 
> > 		return arr[j];
> > 	}
> > 
> > 	void func_set(int arr[], int x, int y, int val)
> > 	{
> > 		k = (x + y) * 2;
> > 
> > 		arr[k] = val;
> > 	}
> > 
> > 	temp = func_get(arr, x, y);
> > 
> > 	func_set(arr, x, y, temp);
> > 
> > Ok the compiler *** MIGHT *** still be able to hack this if it is very
> > smart and all the source is available for the functions. BUT change
> > the type of the array from a straight forward int to a struct and
> > things get incredibly complicated (I mean they are really complicated
> > now with int but they will get MUCH worse with a struct :)
> 
> I don't doubt that it's incredibly complicated, but I don't see how the
> exact implementation of the various operators affects this optimization.
> This optimization is based on the compiler "knowing" that (x * 2 + y *
> 2) == ((x + y) * 2), no matter how exactly they are calculated. If this
> identity can be derived from what's defined in the standard about the
> involved operators, then this optimization can be made, no matter where
> the operators are implemented. If it's not defined in the standard (for
> example, for typical floating point variables, this identity is
> generally not given), such an optimization can't be made -- no matter
> where the operators are implemented.
> 
> 
> > Here having built-in type like STRING, LIST etc reduces the
> > complication because the lanuage and compiler control the way they
> > are used. It's like the difference between a menu interface and a
> > command line interface. With the menu interface you guide the users
> > interactions and there can be no unexpected commands issued that will
> > break things (kind of).
> 
> I still don't see this. You repeat that there is a difference, but don't
> really say where the difference is. The analogy with the menu doesn't
> seem to be very helpful; if I have a list defined with the operations
> insert, delete, replace, find, the "menu" is the same whether they are
> implemented in the compiler or in a standard library. 
> 
> It seems you forget that the library I'm talking about has an interface
> that's as strictly and precisely defined as the language itself, by the
> same language standard. Can you give an example where a programmer could
> give an "unexpected command" in the case the list is implemented in a
> standard library, versus the programmer not being able to give that
> "unexpected command" in the case it is implemented in the compiler?
> (Keep in mind that in both cases it is defined in the language standard
> what the programmer can do with the list -- and it's the exact same
> definition.)
> 
> 
> > But the same argument could be made for floating point. Many people
> > require different precission (wheather greater or less than that
> > provided by C) yet they either use what is available in a way that
> > suits them of they use a specialised library *** AS WELL *** as the
> > supported floating point. 
> > 
> > Often people will fit the solution to the tools available.
> 
> I didn't understand the point you're making here (WRT the discussion
> about built-in versus standard library). Yes, I think it's helpful for
> both strings and floating-point when a user can use custom libraries
> instead of the implementations built into the compiler. And I also think
> that this only makes real sense if the syntax is the same in both cases.
> And IMO this means that there can't be any syntax advantage for the
> implementations that are built into the compiler. 
> 
> 
> > in the above, how would I tell the compiler the relationship between 
> > string_alloc, string_assign, string_substr and string_release such that  
> > the compiler is able to:
> > 
> > (1) ... indicate an error if tmp_str is not initialised with string_alloc 
> > before string_assign is used on it (simply assigning a value to tmp_str is 
> > not what I mean, I mean actually using string_alloc to initialise it).
> > 
> > (2) ... indicate an error if tmp_str goes out of scope before it is 
> > cleaned up with string_release
> > 
> > (3) ... optimise the combined use of string_assign and string_substr
> > 
> > (4) ... recognise that tmp_str is undefined after the use of 
> > string_release
> > 
> > This is why you need to be able to add special attributes to the 
> > functions, to be able to tell the compiler about all this stuff.
> 
> If I understand you correctly, this wouldn't be defined as attribute of
> the function, but it would be defined in the language standard, /before/
> any implementation of a compiler or a standard library. Every library
> function I'm talking about is assumed to be defined in the same language
> standard where you define how your built-in list works.
> 
> 
> > in each of these cases C ensures that the actual paraemeters val_1,
> > val_2 and val_3 are floats before passing them to func_A. 
> 
> FWIW, I'm not a friend of this. I prefer explicit casts, and if I had a
> way to switch off all implicit casts in C or C++, I'd probably do it.
> (At least I'd start doing it to see how it works out.) But this is not
> related to our discussion about built-in vs library.
> 
> > [...] All of this is the calling protocol. 
> > 
> > So yes the the compiler "understands" a standard library function in
> > as much as it "understands" its parameter requirements. 
> 
> This is not what I mean. This is what the compiler "knows" about any
> function, standard or user-defined. It "knows" more (or could "know"
> more) about standard library functions -- as much as there is defined in
> the language standard.
> 
> 
> > The C++ compiler still doesn't understand the relationships between
> > functions. The programmer does and he arranges all the objects to get
> > sensible optimised results.
> 
> Whether it actual does or doesn't doesn't really matter here. What
> matters is whether this is /possible/ -- and whether there's a
> difference between implemented in the compiler or in a standard library.
> 
> One of your first points was the replacement of a delete followed by an
> insert with a replace, for a list. This is possible because the compiler
> "knows" what delete, insert and replace do to a list, and how the list
> is supposed to work. It needs a definition for this. If this definition
> is given in the language standard, I still fail to see how it matters
> whether the list is implemented in a standard library or in the compiler
> itself.
> 
> 
> >>> An intrinsic function is one that the compiler understands
> >>> intimately. Not just what parameters it takes and what result it
> >>> returns. 
> >> 
> >> Next step is to define what "understands intimately" means. Does a
> >> specification (like in a language standard) qualify?
> > 
> > No.
> 
> I guess we don't really need to define what intrinsic functions are (and
> consequently what "understands intimately" means for you), as it's not
> what seems to be important in the question what exactly is the
> difference in optimizing sequences of commands, depending on whether
> they are implemented in the compiler or in a standard library (always
> given that both implementations follow the same language standard). 
> 
> 
> >> Not sure whether the standard can tell you what kind of optimizations
> >> actual compilers implement. Much of this is probably a trade secret.
> >> Then I'm not convinced a casual look at this is enough to find out
> >> what /could/ be implemented. They don't talk about optimizations in
> >> the standard; they just say what has to be the result. 
> >> 
> >> Going back to one of your original arguments, the one that prompted
> >> my question about what the difference is between list operations
> >> that are implemented by the compiler and list operations that are
> >> implemented in a standard library: the substitution of a delete from
> >> a list followed by an insert into a list at the same location by a
> >> replace. 
> >> 
> >> If you want to implement such an optimization in your compiler,
> >> what's the difference between having these functions as part of the
> >> compiler, or having them defined as standard library functions in
> >> the standard that the compiler is based upon? In both cases, the
> >> compiler "knows" that this substitution is possible and the exact
> >> implementation of the three functions is not necessary to be known
> >> for this optimization to be possible.
> > 
> > Yes I understand what you mean here. But in the case of functions
> > this relies on the compiler actually recognising the function names
> > and executing some internal code to perform checks, issue warning (or
> > errors) and perform optimisations.
> 
> Yes.
> 
> > That internal compiler code needs to be activated somehow and it needs
> > to perform a very specific task (not something that would be there
> > anyway - somthing that is written specially for that one perpose).
> 
> Yes. Just as with your insert+delete==replace example. The compiler can
> do this, independently of where these functions are implemented.
> 
> Pretty much every C++ compiler does this, for example, for custom
> implementations of the operator new. This is a special operator, and no
> matter whether I use a built-in version or a standard library version
> that came with the compiler or my own custom version, there are a number
> of special checks that are related to this operator that are executed by
> the compiler, based on what the language standard says about operator
> new. 
> 
> This internal code is activated by the use of an operator new; this is a
> reserved word, just like all other tokens/identifiers in the language
> standard. 
> 
> > If you really wanted to you could say that the function names are
> > undefined to the compiler but then you need some way of telling the
> > compiler which functions are special (what their names are) and what
> > is special about them (under special circustances you can replace
> > func_A + func_B with func_C). 
> 
> No, I don't want to. The function names are defined in the language
> standard, just as the language elements are defined in the (same)
> language standard. For example, the C++ std::list::insert. In C++, this
> /is/ a special function, and it always has this name. There's nothing
> that prevents a C++ compiler from implementing some optimization that is
> based on what the standard says this function is doing. There's also
> nothing that would prevent a compiler writer from providing an
> implementation of this function that is built into the compiler itself.
> But it still couldn't do anything with this function that's contrary to
> the standard. (If there's something lacking in the standard to make its
> definitions more useful, it should be added to the standard -- not to a
> single implementation.)
> 
> > This is why you would need to be able to add special attributes to a
> > function, so that you can tell the compiler that these are special
> > functions that need to be handled in a special way (execute the
> > special internal code for them). (sorry about all the specials :-)
> 
> No. I'm talking /exclusively/ about /standard/ libraries, which contain
> implementations for functions that have their behavior defined in the
> language standard. Like the C++ std::list member functions, for example.
> Their names are known to the compiler implementers; no special
> attributes are needed to identify these functions.
> 
> > Other than having special attributes you really would need to make
> > these functions intrinsic (known and understood by the compiler) so
> > that it can execute its special internal code when it sees them in
> > the users source code.
> 
> No. If their interface is defined accordingly, the compiler can assume
> that insert followed by delete can be replaced by replace in a given
> situation. The functions must be defined in a way in the language
> standard that the compiler can assume this -- but this must be the case
> no matter whether the list is implemented in the compiler or in a
> standard library. This optimization can then be performed, independently
> of whether the functions are implemented by the compiler or in a
> standard library. (The compiler's optimization stage that deals with
> this type of high-level optimization doesn't even have to "know" this.)
> 

If I understand you correctly what you are saying is that if the compiler 
writer is already aware of the /standard/ library before he starts writing 
the compiler AND the /standard/ library definition is set in concrete just 
as the language definition is then the compiler writer is able to use 
intimate knowledge of the /standard/ library functions within the compiler 
without incorporating the code generation of the /standard/ library 
functions within the compiler but instead leaving this implemented 
external to the compiler proper (so that these functions can be written by 
someone else and code generated at compile time).

Please confirm this.

Friendly Regards
Sergio Masci
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist