On Sun, 5 Jul 2009, Gerhard Fiedler wrote:

> sergio masci wrote:
> 
> > You forgot the "conformance" aspect. Ada is a registered trademark of
> > the US DoD. 
> 
> Yup, didn't think of that. Definitely a killer.
> 
> 
> > 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?

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.

> 
> >> 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.

> 
> There is a place for languages that can be used by domain experts
> efficiently, so that they don't need expert programmers to solve their
> problems. What we do when we solve a problem with a microcontroller and
> C (or assembly, or Pascal, or even XSBC :) is often a "hack", in the
> absence of a better solution; the real solution would be something that
> allows the domain expert to do it herself.
> 

I agree which is why I developed the meta CASE tool IPAD-Pro with which 
the domain expert together with an expert programmer put together a system 
whereby the domain expert can draw a diagram of his/her requirements 
in a way that is natural to their domain. The tool then generates code 
according to the diagram. It even lets code be simulated on the diagram so 
that the diagram, code and requirements can be debugged.

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

> 
> > 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.

Think of it like this: when you have a sequence of language keywords the 
compiler is able to analyse the sequence in order to try to look for the
"meaning" of the sequence rather than just the statements that the 
sequence is made of.

e.g.
this is a loop

	for (j=0; j<10; j++)
	{	arr[j] = 0;
	}

here the compiler can optimise the loop in all kinds of ways.
* It knows that j is not modified within the loop
* it knows that the loop is to be repeated 10 times
* it knows that each item in the array is referenced simply relative to j
* it knows that each item of the array is set to a value that is not 
  dependent on the order in which the array is processed
* it can also scan ahead of the loop to see if subsequent statements are
  dependent on the value of j once the loop exits

The compiler can actually change this loop to the more optimal form

	for (j=9; j!=0; j--)
	{	arr[j] = 0;
	}

which in itself could be used to generate a much more optimised executable 
depending on the target CPU (think of Z80 or x86 with native load and 
repeat). BTW this is one type of optimisation that XCSB does.


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];
	}

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.

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;
...
}

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.

In the above example LENGTH was given as predef_cnt but this could have 
easily been omitted since the compiler can see the length of the array. 
Thus eliminating the need for predef_cnt (and maintaining it if predef_arr 
actually changes). If the array were of integers SEARCH wouldn't even have 
needed a WITH KEY component :-)

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.

> 
> > I think if you look at a high level language like Java or even the
> > executable produced by something like a C++ compiler, you will find
> > that the native machine code being executed is not the problem - the
> > problem is all the dynamic memory management that is going on.
> > Objects being created and destroyed just so that trivial operations
> > can be performed without impacting on other objects.
> 
> You're probably right. Heap management and garbage collection, pointer
> and reference mechanics, support for polymorphism and virtual functions
> -- all in microcode, directly executed, wouldn't that be nice? But by
> judging from the

???
 
> 
> > Personally I think if you really want to optimise a processor to
> > execute high level code more efficiently then it needs an evaluation
> > stack (kind of like FORTH) [...]
> 
> FORTH again... shouldn't it have had more success? :)

As Olin points out, large complex programs are very difficult to write and 
maintain in FORTH. But I wasn't actually advocating FORTH itself just the 
evaluation stack.

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