sergio masci wrote:

>>> Yes I can see where you are comming from. So what would you say to a
>>> programmer who points at your generated code and laughing says "I
>>> could have done that in half the number of machine code
>>> instructions" using C. If your C "successor" is going to stand any
>>> chance of competeing with C, it's got to generate code that's at
>>> least on a par with it.
>> 
>> If it's competing on its turf, then yes. If I can say "I have
>> developed the application in 10% of the time it would have taken to
>> develop it in C", then it depends. That's probably the reason why C
>> (and assembly) is not that popular with bigger systems,
>> notwithstanding its popularity with smaller systems. 
> 
> Yes but the problem is: are you prepared to take the risk and try a
> new programming language just to discover its strengths and
> weaknesses, to see it really will save you a great deal of time in
> both development and maintinance? And if you are, is your boss? 

People (and their bosses :) do it all the time. C# came out of (almost)
nowhere a few years ago. Ruby is quite recent, too. Both are reasonably
popular now. I'm sure you can find other examples. 

> It's all well and good reading about a language or paradigm that will
> save you tons of money and time but having read all these over
> enthusiastic claims in the past and found them to be false (if not
> down right lies), you tend to treat new claims (that you "hear"
> about) with a good deal of sceptisism. 

Of course. This is what I've written about before: it's not so much
about the "computer science quality" of the language, but about a number
of other factors. I'm not sure what it is, but it's pretty obvious that
it's not the mere programming quality of a programming language that
makes it popular (or not).


>>>> It seems a certain part of the engineering population thinks that
>>>> ladder logic is an adequate way to describe their control
>>>> problems, yet ladder logic compilers are definitely unpopular with
>>>> the micro crowd. There seem to be groups that have different views
>>>> of what is the easiest way to describe a problem.
>>> 
>>> Yes but most people that like ladder logic are not expert programmers.
>> 
>> Most people, and even most programmers, are not expert programmers (by
>> definition... :)
> 
> Ok, ok, back to the 99% :-) 
> 
> Let me change that then to: most people that make a living as a
> professional programmer.

But still... they get work done. And apparently they (and their bosses
:) don't think that learning C (or whatever other programming language)
would help them getting it done more efficiently -- or they would hire
programmers.


> BTW I guess by XSBC you actually mean XCSB :-)

Yes. You can send this to your marketing department -- I never can
remember which way it is :)


>>> But most problems can be broken down into much smaller well defined
>>> processes such as search, sort, append, remove etc. which a
>>> language should be able to apply to basic data types such as lists,
>>> sets, heaps, arrays, strings etc. For any really complex not yet
>>> thought-of domains we have libraries. I am so fed up with the
>>> notion that we need libraries for everything, that the language
>>> needs to be so rediculasly simply as to not be able to understand
>>> types such as lists, strings, dynamic array etc. when these types
>>> are so common and well understood. 
>> 
>> I for one never understood this "war" between language and libraries. I
>> don't really care that much whether C++ has a decent array type built
>> into the language or whether there are the C-style arrays for backwards
>> compatibility and as a decent solution there is std::vector from the
>> standard library. The standard libraries are, at least with C and C++,
>> part of the language specification. 
>> 
>> Then there are those cases where I still code my own containers, because
>> for the one or other requirement, the standard containers don't fit my
>> bill. Probably no language built-in container can do it all; there too
>> many different sets of requirements with different solutions.
>> 
>> You probably have a point with strings (in C and C++), but there is the
>> dreaded backwards compatibility that sooner or later hits everything
>> that is used for long enough, and so C is pretty much stuck with the
>> half-assed string implementation it has. In C++ there is std::string,
>> which works for many cases well enough (and again I don't really care
>> that much that this is from a library).
> 
> Yes this point seems to elude most programmers.
> 
> [loop optimization ...]
> 
> Now if we introduce a function the above optimisations break
> e.g.
> 	for (j=0; j<10; j++)
> 	{	arr[j] = sin(j);
> 	}
> 
> This is because the compiler doesn't really know anything about the
> function. It can analyse the function and depending on how complex
> the function is it might be able to optimise the loop a little but in
> the case of a well optimised sine function optimisation becomes very
> limited.
> 
> If however the compiler "knows" about the sin function (because the 
> compiler writer has given it special attributes that the compiler can 
> use) it could optimise this loop by building a lookup table at compile 
> time as:
> static	xxx
> 	own_sin_tbl[] = {sin(0), sin(1), ...
> 
> 	for (j=0; j<10; j++)
> 	{	arr[j] = own_sin_tbl[j];
> 	}

Here you have a point, but I'd say that this code (as C code for a small
micro) is badly written. Really badly. arr[j] should be initialized with
compile-time constants, not at run-time. You can say that this is the
compiler's job, but the problem is, again, that there are so many
different ways to calculate sin(). The compiler doesn't know which one I
think is adequate for my purposes; do I need 2 digits precision, or 6,
or 12? The code size and/or execution time of the function varies
substantially with the required precision.


> The important point here is not to focus on the sine function itself
> but on the fact that a function is involved. Using functions (and
> this is primarilly what libraries use) hinders the compilers ability
> to analyse the intent of the programmer. Whereas having the compiler
> understand more of the source allows it to better analyse the intent.

Yes, I get that. But the compiler can't know a few things around my
requirements, and I may be better able to choose which function
implementation is more adequate.

Regarding the intent, a good definition of a library function (think the
C++ standard library) explains quite clearly the intent. It doesn't nail
down the implementation details of the functions, though. C doesn't do
it, but there's nothing in the above that would prevent a compiler to
actually call at compile time the library function to calculate that
array. It doesn't have to be built in for that; it just has to know
which library to use (at compile time). 


> Going a bit further, if I wrote a simple search function such as
> 
> struct MY_STRUCT
> 	{	int	id;
> 		int	mask1, mask2;
> 	};
> 
> int search(int x, int cnt, struct MY_STRUCT arr[])
> {
> 	int	j;
> 
> 	for (j=0; j<cnt; j++)
> 	{
> 		if (x == arr[j].id)
> 		{	return j;
> 		}
> 	}
> 
> 	return -1;
> }
> 
> then I could use this in C as:
> 
> static const struct MY_STRUCT predef_arr[] =
> 	{
> 		{ 5, 0xfe, 0x11},
> 		{ 7, 0xfc, 0x22},
> 		{11, 0xe1, 0x33},
> 	};
> 
> static const int predef_cnt = 3;
> 
> main()
> {
> ...
> 
> 	mask1 = 0xff;
> 	mask2 = 0x00;
> 
> 	res = search(7, predef_cnt, predef_arr);
> 
> 	if (res != -1)
> 	{
> 		mask1 = predef_arr[res].mask1;
> 		mask2 = predef_arr[res].mask2;
> 	}
> ...
> }
> 
> now if search were actually part of the language as in:
> 
> 	res = SEARCH ARRAY=predef_arr LENGTH=predef_cnt WITH KEY=id FOR 7;
> 
> then the compiler would be in the position to simply generate the 
> equivalent of:
> 
> main()
> {
> ...
> 
> 	mask1 = 0xfc;
> 	mask2 = 0x22;
> ...
> }

This doesn't require that SEARCH is part of the compiler; it merely
requires that the semantics of SEARCH are well-defined. It could just as
well be a library function with semantics that are specified so that the
compiler can know what to do. 

But again, like above with the sin() example, code like this should
actually be compile-time constants, not run-time calculations. The
program writer should clearly distinguish between values that are known
before the program runs and values that are dependent on run-time
events. The examples you showed are only relevant if the programmer
doesn't do this.


> Ok so from all this you might get the impression that what I'm talking
> about is purely optimisation related, it's not. It's about making it
> easier for the programmer to write correct code and the compiler to
> understand the code and so catch mistakes at compile time - good
> optimisation is actually a side effect.

I get this, but I think a library with clearly defined semantics goes a
long ways towards that. And a programmer who clearly distinguishes
between stuff that's known at compile time and stuff that can only be
known when the program runs also helps.


> Having built-in types such as LIST, STACK, STRING greatly enhance the 
> compilers ability to track correct usage and reduce source code size 
> making it easier for the programmer to see the wood for the trees.

Right, but again... The C++ standard library, for example, has quite
good implementations of standard containers, yet I find myself creating
my own containers or using different containers from other libraries,
for specific requirements that the standard containers don't satisfy. A
list or stack is a concept, with many different possible implementations
that satisfy different requirements. And I suspect that the smaller the
micro it runs on, the more limited the resources are, the more important
are the differences between different implementations. 

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