On Sun, 9 Oct 2016, Wouter van Ooijen wrote:

> Op 09-Oct-16 om 7:50 PM schreef smplx:
>> The piclist seems very quite regarding PIC topics lately so I thought I'=
d
>> try to add something interesting.
>>
>> Before we get bogged down into which is better assembler or high level
>> language consider how you would feel about a compiler that generates cod=
e
>> that is optimised beyond your wildest dreams.
>>
>> Imagin that you don't need to resort to sneaky tricks or hand crafted
>> assembler embedded in your high level code. That you don't need to
>> labouriously generate complicated tables in excel or matlab and then
>> painstakingly shoehorn them into you high level code. Imagin that you ca=
n
>> execute thousands of lines of complex code and have the result available
>> in the time it takes to execute a single machine cycle. And better still=
,
>> imagin you can do all this without having to learn some new complicated
>> language.
>>
>> Basically it comes down to this: the compiler executes as much user code
>> as possible during the compilation process and works out the bare minimu=
m
>> that needs to be executed in the target.
>
> Are you aware that this is a feature of C++? It was available for a long
> time in a rather convoluted form as meta-programming (templates and
> SFINAE), extended to plain functions in a limited form in C++ 11
> (single-return-statement functions only), which was generalized in C++ 14=
..
>
> I don't fully get what you proposed, but in C++ you can use
>
> constexpr auto x =3D y( ... );
>
> which requires that y(...) is evaluated at compile time. Y can be a
> function, or an object constructor that creates a complex object.
>
> Wouter "Objects? No Thanks!" van Ooijen

Hi Wouter,

No, I was not aware of this. I haven't been keeping up with C++ as I feel=20
it is getting over complicated.

What I propose is that the user (the programmer) does ***NOT*** write code=
=20
in a special way so that the compiler can do something special with it but=
=20
***INSTEAD*** writes normal code ***AND*** the compiler does the something=
=20
special on ***ALL*** of it.

Some of it will be dependent on the runtime environment and the compiler=20
will generate executable machine code for this which must be run on the
target. Some of it though will not be dependent on the runtime environment=
=20
so the compiler will execute it directly and if possible produce greatly=20
condensed logic, lookup tables, simple inline constants or simply=20
eliminate code altogether.

As a simple example consider a C program that uses a structure called=20
WIDGET that has a member called 'length' and an array of these structures=20
called POOL is built by repeatedly calling a function (called INIT_WIDGET)=
=20
to initalise each element of this array.

something like this:

 	struct	WIDGET
 		{ ...
 		  int	length;
 		  ...
 		}

 	WIDGET POOL[10];

 	for (int j=3D0; j<10; j++)
 	{
 		POOL[j] =3D INIT_WIDGET(...)
 	}

Now if the function is always returning the same value for the member=20
'length' and 'length' is never updated anywhere else it is possible to=20
replace all references to that member with a simple constant.

so if we wrote:

 	POOL[n].length

we could replace it with the simple constant

even if we used pointers to WIDGET as in:

 	WIDGET *ptr;

 	ptr->length

Now because I am saying that the user must not be forced to write special=20
code to achive this then the compiler must be able to understand the=20
intent of the function ***AND*** the simplest way to do that is to=20
run the function INIT_FIFO while analysing the inputs and outputs.

Basically it is the same as replacing a variable with a constant once=20
analysis reveals that the variable never changes.

Converting every occurance of 'X[j].m' with a simple constant would be a=20
huge optimisation.

Perhaps if I put this in another way:

 	for (int x=3D0; x<10; x++)
 	{
 		output(sin(x));
 	}

could easily be converted to:

 	for (int x=3D0; x<10; x++)
 	{
 		sin_tbl[x] =3D sin(x);
 	}

 	for (int x=3D0; x<10; x++)
 	{
 		output(sin_tbl[x]);
 	}

but the creation and use of the table being done as an optimisation by the=
=20
compiler because it knows about the builtin 'sin()' function. Now instead=20
of limiting this optimisation to builtin functions like 'sin()' make it=20
work with user written functions.


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