Op 10-Oct-16 om 12:22 AM schreef smplx:
>
> 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 co=
de
>>> 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 c=
an
>>> execute thousands of lines of complex code and have the result availabl=
e
>>> in the time it takes to execute a single machine cycle. And better stil=
l,
>>> 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 cod=
e
>>> as possible during the compilation process and works out the bare minim=
um
>>> 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++ 1=
4.
>>
>> 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
> it is getting over complicated.
>
> What I propose is that the user (the programmer) does ***NOT*** write cod=
e
> in a special way so that the compiler can do something special with it bu=
t
> ***INSTEAD*** writes normal code ***AND*** the compiler does the somethin=
g
> special on ***ALL*** of it.
>
> Some of it will be dependent on the runtime environment and the compiler
> 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 environmen=
t
> so the compiler will execute it directly and if possible produce greatly
> condensed logic, lookup tables, simple inline constants or simply
> eliminate code altogether.
>
> As a simple example consider a C program that uses a structure called
> WIDGET that has a member called 'length' and an array of these structures
> called POOL is built by repeatedly calling a function (called INIT_WIDGET=
)
> 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
> 'length' and 'length' is never updated anywhere else it is possible to
> 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
> code to achive this then the compiler must be able to understand the
> intent of the function ***AND*** the simplest way to do that is to
> run the function INIT_FIFO while analysing the inputs and outputs.
>
> Basically it is the same as replacing a variable with a constant once
> analysis reveals that the variable never changes.
>
> Converting every occurance of 'X[j].m' with a simple constant would be a
> 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 th=
e
> compiler because it knows about the builtin 'sin()' function. Now instead
> of limiting this optimisation to builtin functions like 'sin()' make it
> work with user written functions.
>
>
> Regards
> Sergio Masci

In your idea, as a user, can I be *sure* that a certain (complicated)=20
part is run by the compiler at compilation?

In C++ 0x14 you can

- declare any function as constexper, which means that the compiler must=20
check that it can evaluate that function at compile time (provided that=20
it knows the arguments at compile time). Such a function is still usable=20
at run time too.

- declare any const value as constexpr, which means that the compiler=20
must evaluate it at compile time.

There isn't much special about a constexpr function that isn't obvious=20
(like: it can't access globals, can't do memory allocation, etc.).

Wouter

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