Compile time executed functions

Compile time executed functions

[Mats Karlssohn]

After following the thread on C style preprocessing, an old wish of
mine popped up in my brain (or whatever is inside the scull :).

Sometimes, especially when doing embedded programming, I feel a great
need to execute a function to get literal initialization a constant.
That is I'd like to have the compiler to execute a function for me (at
compiletime!) and use the return of that function to initialize the
constant.

Example (pleas, this is just an example, it hasn't been compiled):

type Byte is mod 2**8;
type Word is mod 2**16;
type CRC_Lookup_Table is array(0..255) of Byte;

constant CRC_Polynom := 4711; -- replace with a 'correct' polunom

function Generate_CRC_Table(Polynom : in Word) return CRC_Lookup_Table
is
begin
   -- Implementation
end Generate_CRC_Table;

package Package_Using_CRC is
   constant CRC_Lookup_Table := Generate_CRC_Table(CRC16_Polynom);

   -- 
end Package_Using_CRC;


- The constant is really a constant an should therefore be placed in
ROM.
- Therefore the function Generate_CRC_Table isn't needed in the output
  at all and since it may be quite large and/or time consuming it would
  be nice to do the job once, at compile time.


The way I'm currently doing this is by building a small external program
that generates an appropriate code fragment, that gets pasted into the
right place. This gives both maintenance and configuration management
headaches.

I must admit that I havn't researched enough to say that I can't get the
same effect using generice and/or other techniques in Ada.

Now, first I wonder have somebody out there solved this issue in a way
that complies with the first to points above ?

I realize that a lot of limitations must be put on the
Generate_CRC_Table function, but, have something along these lines been
considered by the language designers.

I have hoped to get the time to either build a small preprocessor to do
this kind of execution/substitution trick, or to add the same trick into
GNAT using some pragma(Compiler_Executed, func). Sorry to say, I don't
see that ammount of time in the near future.


Finally, as usual, I beg you to bear with my english.

-- 
Mats Karlssohn, developer                         mailto:mats@mida.se  
Mida Systemutveckling AB                          http://www.mida.se
Box 64, S-732 22 ARBOGA, SWEDEN
Phone: +46-(0)589-89808   Fax: +46-(0)589-89809

Re: Compile time executed functions

[Ken Garlington]

I think the key statement is "The constant is really a constant and should
therefore be placed in ROM."

AFAIK, you can create an _Ada_ constant from a function. Whether it's placed
in ROM is a concept outside the scope of the language, and is a function of
compiler optimizations. For example, my company spent a lot of time and
money in order to get the result of an Unchecked_Conversion between a
System.Address and a compatible access type placed into ROM for a particular
Ada 83 compiler/linker. Before we paid for this, the result would be placed
in RAM. Both implementations were legal with respect to the language
definition.

A more general solution, as you noted, is to write an Ada program that
writes an easier-to-optimize Ada program (or, in some cases, assembly
instructions). We have several of those for commonly-used capabilities in
our domain.

"Mats Karlssohn" <mats@mida.se> wrote in message
news:3AC03CCE.70E3C2D5@mida.se...
: After following the thread on C style preprocessing, an old wish of
: mine popped up in my brain (or whatever is inside the scull :).
:
: Sometimes, especially when doing embedded programming, I feel a great
: need to execute a function to get literal initialization a constant.
: That is I'd like to have the compiler to execute a function for me (at
: compiletime!) and use the return of that function to initialize the
: constant.
:
: Example (pleas, this is just an example, it hasn't been compiled):
:
: type Byte is mod 2**8;
: type Word is mod 2**16;
: type CRC_Lookup_Table is array(0..255) of Byte;
:
: constant CRC_Polynom := 4711; -- replace with a 'correct' polunom
:
: function Generate_CRC_Table(Polynom : in Word) return CRC_Lookup_Table
: is
: begin
:    -- Implementation
: end Generate_CRC_Table;
:
: package Package_Using_CRC is
:    constant CRC_Lookup_Table := Generate_CRC_Table(CRC16_Polynom);
:
:    --
: end Package_Using_CRC;
:
:
: - The constant is really a constant an should therefore be placed in
: ROM.
: - Therefore the function Generate_CRC_Table isn't needed in the output
:   at all and since it may be quite large and/or time consuming it would
:   be nice to do the job once, at compile time.
:
:
: The way I'm currently doing this is by building a small external program
: that generates an appropriate code fragment, that gets pasted into the
: right place. This gives both maintenance and configuration management
: headaches.
:
: I must admit that I havn't researched enough to say that I can't get the
: same effect using generice and/or other techniques in Ada.
:
: Now, first I wonder have somebody out there solved this issue in a way
: that complies with the first to points above ?
:
: I realize that a lot of limitations must be put on the
: Generate_CRC_Table function, but, have something along these lines been
: considered by the language designers.
:
: I have hoped to get the time to either build a small preprocessor to do
: this kind of execution/substitution trick, or to add the same trick into
: GNAT using some pragma(Compiler_Executed, func). Sorry to say, I don't
: see that ammount of time in the near future.
:
:
: Finally, as usual, I beg you to bear with my english.
:
: --
: Mats Karlssohn, developer                         mailto:mats@mida.se
: Mida Systemutveckling AB                          http://www.mida.se
: Box 64, S-732 22 ARBOGA, SWEDEN
: Phone: +46-(0)589-89808   Fax: +46-(0)589-89809

Re: Compile time executed functions

[Mats Karlssohn]

Ken Garlington wrote:
> 
> I think the key statement is "The constant is really a constant and should
> therefore be placed in ROM."

Well actually, I intended that to be one of the keystatements.
The simple cases (like "Foo : constant Integer := 4;") seems to work
for me already (using GNAT and adapted linker script).

> AFAIK, you can create an _Ada_ constant from a function. Whether it's placed
> in ROM is a concept outside the scope of the language, and is a function of
> compiler optimizations.

Agreed, the placement of the constant is not a Ada language issue.

> A more general solution, as you noted, is to write an Ada program that
> writes an easier-to-optimize Ada program (or, in some cases, assembly
> instructions). We have several of those for commonly-used capabilities in
> our domain.

And I currently does not feel that good about that solution. Most of
the practical issuses,like different project members using old, or
even worse own versions of the table generator (wich is not included
in configuration management) can (add WILL) be solved by some more
project regulations.

The other issue is that I feel that within Ada's expressive powers
it would be useful to have _some_ of the possibilities that is
availible when using C++ templates and/or C preprocessor macros.
(Please, no flames on the two 'bad words' above!)

-- 
Mats Karlssohn, developer                         mailto:mats@mida.se  
Mida Systemutveckling AB                          http://www.mida.se
Box 64, S-732 22 ARBOGA, SWEDEN
Phone: +46-(0)589-89808   Fax: +46-(0)589-89809

Re: Compile time executed functions

[Phaedrus]

"Mats Karlssohn" <mats@mida.se> wrote in message
news:3AC18DD1.EF25CE42@mida.se...
> The other issue is that I feel that within Ada's expressive powers
> it would be useful to have _some_ of the possibilities that is
> availible when using C++ templates and/or C preprocessor macros.
> (Please, no flames on the two 'bad words' above!)

I hope that this doesn't come off as a flame, but Ada always had
something like C++ templates, they are called generics.  As for
preprocessor macros, well, that subject has been pretty adequately
covered in the "Implementing C/C++ style #include" thread.

Phaedrus

Re: Compile time executed functions

[Mats Karlssohn]

Phaedrus wrote:
> 
> "Mats Karlssohn" <mats@mida.se> wrote in message
> news:3AC18DD1.EF25CE42@mida.se...
> > The other issue is that I feel that within Ada's expressive powers
> > it would be useful to have _some_ of the possibilities that is
> > availible when using C++ templates and/or C preprocessor macros.
> > (Please, no flames on the two 'bad words' above!)
> 
> I hope that this doesn't come off as a flame, but Ada always had
> something like C++ templates, they are called generics.  As for
> preprocessor macros, well, that subject has been pretty adequately
> covered in the "Implementing C/C++ style #include" thread.

It doesn't, and of course I know of generics, I use them just about
every day,. However, Ada generics is not as expressiv as C++ templates
with regard to what you can get the compiler to execute for you at
compile time. In many ways this is a blessing, that's why I'm thinking
of executing almost arbitrary functions at compiletime. I think that
implementing this (probably by adding a pragma) should be doable, and
very useful.

-- 
Mats Karlssohn, developer                         mailto:mats@mida.se  
Mida Systemutveckling AB                          http://www.mida.se
Box 64, S-732 22 ARBOGA, SWEDEN
Phone: +46-(0)589-89808   Fax: +46-(0)589-89809

Re: Compile time executed functions

[Ken Garlington]

"Mats Karlssohn" <mats@mida.se> wrote in message
news:3AC18DD1.EF25CE42@mida.se...

: The other issue is that I feel that within Ada's expressive powers
: it would be useful to have _some_ of the possibilities that is
: availible when using C++ templates and/or C preprocessor macros.
: (Please, no flames on the two 'bad words' above!)

Is this a different subject than resolving complex functions as simple ROM
constants? I'm having trouble seeing how a complex function written as a
macro consistently ends up as a constant...

Re: Compile time executed functions

[Mats Karlssohn]

Ken Garlington wrote:
%<
> : The other issue is that I feel that within Ada's expressive powers
> : it would be useful to have _some_ of the possibilities that is
> : availible when using C++ templates and/or C preprocessor macros.
> : (Please, no flames on the two 'bad words' above!)
> 
> Is this a different subject than resolving complex functions as simple ROM
> constants? I'm having trouble seeing how a complex function written as a
> macro consistently ends up as a constant...

I'll try to explain a little more. But first, forget about the RAM/ROM
issue, it was a mistake to include that in the original post.

Say I want to create a table of data. The data is constant and must not
change during the programs lifetime. Further more, the data is quite
time consuming to calculate.

In C++ (bad word again :) I can (with some effort) write a template that
does all the calculations in the compiler at compile time.

In Ada, my experience is that I end up with something like:

package BlaBlah is

   -- declarations needed

   MyLookupData : constant LookupTable := GenerateTable(parameter);

end BlahBlah;

GenerateTable will be called at package elaboration time, and therefore
consume time on the target. Moreover, the GenerateTable code is not used
by anything else but is included into the loadmodule anyway.

Now IF I haf a pragma that tagged GenerateTable as a 'compiler
executed function' it would allow the compiler to compile a native
version of Generatetable, execute it and use the result as a literal
when compiling package BlahBlah. Furthermore the compiler would know
that GenerateTable isn't needed on the target and thus eliminate it's
code.

As I noted in the original post, this can be (and is today) solved by
manually putting GenerateTable into its own program and the pasting the
output into the source of package BlahBlah. This has caused management
problems and I expect it to continue to do so.


Am I plain stupid since I worry about when what's included in my
output and when time is consumed ? 

-- 
Mats Karlssohn, developer                         mailto:mats@mida.se  
Mida Systemutveckling AB                          http://www.mida.se
Box 64, S-732 22 ARBOGA, SWEDEN
Phone: +46-(0)589-89808   Fax: +46-(0)589-89809

Re: Compile time executed functions

[Ken Garlington]

"Mats Karlssohn" <mats@mida.se> wrote in message
news:3AC2EB17.33AAEC0A@mida.se...
: Ken Garlington wrote:
: %<
: > : The other issue is that I feel that within Ada's expressive powers
: > : it would be useful to have _some_ of the possibilities that is
: > : availible when using C++ templates and/or C preprocessor macros.
: > : (Please, no flames on the two 'bad words' above!)
: >
: > Is this a different subject than resolving complex functions as simple
ROM
: > constants? I'm having trouble seeing how a complex function written as a
: > macro consistently ends up as a constant...
:
: I'll try to explain a little more. But first, forget about the RAM/ROM
: issue, it was a mistake to include that in the original post.
:
: Say I want to create a table of data. The data is constant and must not
: change during the programs lifetime. Further more, the data is quite
: time consuming to calculate.
:
: In C++ (bad word again :) I can (with some effort) write a template that
: does all the calculations in the compiler at compile time.

Could you post an example of such a template, and what in the C++ standard
you rely upon to guarantee compile-time calculations? Also, does
"compile-time" include "link-time", or are you not allowed to have anything
in the table that uses addresses?

[snip]

: As I noted in the original post, this can be (and is today) solved by
: manually putting GenerateTable into its own program and the pasting the
: output into the source of package BlahBlah. This has caused management
: problems and I expect it to continue to do so.

It's the part about "pasting the output" that seems odd. Why not have it
generate a stand-alone Ada *package* (e.g, BlahBlah)? We do this now in a
number of cases. In fact, you can have an automated build script that
generates the code, updates the CM system with it, then does the things you
usually expect in such a script (extract source from CM system, compile,
link...)

: Am I plain stupid since I worry about when what's included in my
: output and when time is consumed ?

Not at all. However, the source generation option can be just as reliable
(more so, since it's less dependent on compiler-specific optimizations) that
whjat you are wanting, IMHO. Even better, you can readily reuse the concept
if you move between languages (just have the source generation tool use a
template file to control the form of the output).

Re: Compile time executed functions

[Ted Dennison]

In article <lEHw6.434$2g1.81555482@newssvr16.news.prodigy.com>, Ken Garlington
says...
>
>
>"Mats Karlssohn" <mats@mida.se> wrote in message
>: As I noted in the original post, this can be (and is today) solved by
>: manually putting GenerateTable into its own program and the pasting the
>: output into the source of package BlahBlah. This has caused management
>: problems and I expect it to continue to do so.
>
>It's the part about "pasting the output" that seems odd. Why not have it
>generate a stand-alone Ada *package* (e.g, BlahBlah)? We do this now in a

We also do that now to generate external interface packages automaticly from ICD
databases.

For that matter, with a little investigation into your platform's object file
formats, you could just have your program directly create an object file with
the data in it, and "pragma Import" it and link it with your Ada code. On an
embedded system you could also just write the data out into a binary file, have
it burned into a set place in ROM, and use "for use at" to map an Ada structure
there.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: Compile time executed functions

[Mats Karlssohn]

Ted Dennison wrote:
%<
> For that matter, with a little investigation into your platform's object file
> formats, you could just have your program directly create an object file with
> the data in it, and "pragma Import" it and link it with your Ada code. On an
> embedded system you could also just write the data out into a binary file, have
> it burned into a set place in ROM, and use "for use at" to map an Ada structure
> there.

Well actually this is what I decided to do during the weekend.
Since i have GNU libbfd.so creating an object file should be
pretty easy and GNU objcopy can be a friend when the need to
for more platforms arise.

-- 
Mats Karlssohn, developer                         mailto:mats@mida.se  
Mida Systemutveckling AB                          http://www.mida.se
Box 64, S-732 22 ARBOGA, SWEDEN
Phone: +46-(0)589-89808   Fax: +46-(0)589-89809

Re: Compile time executed functions

[Ted Dennison]

In article <3ACAD2B2.4252FD7B@mida.se>, Mats Karlssohn says...
>
>Ted Dennison wrote:
>%<
>> For that matter, with a little investigation into your platform's object file
>> formats, you could just have your program directly create an object file with
>> the data in it, and "pragma Import" it and link it with your Ada code. On an
>Well actually this is what I decided to do during the weekend.
>Since i have GNU libbfd.so creating an object file should be
>pretty easy and GNU objcopy can be a friend when the need to

:-)

It always warms my heart to see someone writing a compiler in Ada (even if they
don't always realize that's what they are doing).

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: Compile time executed functions

[Mats Karlssohn]

Ted Dennison wrote:
> 
> In article <3ACAD2B2.4252FD7B@mida.se>, Mats Karlssohn says...
> >
> >Ted Dennison wrote:
> >%<
> >> For that matter, with a little investigation into your platform's object file
> >> formats, you could just have your program directly create an object file with
> >> the data in it, and "pragma Import" it and link it with your Ada code. On an
> >Well actually this is what I decided to do during the weekend.
> >Since i have GNU libbfd.so creating an object file should be
> >pretty easy and GNU objcopy can be a friend when the need to
> 
> :-)
> 
> It always warms my heart to see someone writing a compiler in Ada (even if they
> don't always realize that's what they are doing).

well I've been down that road a few times, one of the more entertaining
ones were the compiler that translated a map database in som ugly
textformat into Megatek displaylists, binary files that were later
loaded onto the graphics hardware. It was entertaining since debugging
was just about impossible, since most of the time the graphics system
(a Sigma 70) would just hang when you fed it incorrect data, forcing
a partitial (or sometimes a full) reset/reboot of the system (Sun
4/300).

-- 
Mats Karlssohn, developer                         mailto:mats@mida.se  
Mida Systemutveckling AB                          http://www.mida.se
Box 64, S-732 22 ARBOGA, SWEDEN
Phone: +46-(0)589-89808   Fax: +46-(0)589-89809

Re: Compile time executed functions

[Simon Wright]

"Ken Garlington" <Ken.Garlington@computer.org> writes:

> It's the part about "pasting the output" that seems odd. Why not
> have it generate a stand-alone Ada *package* (e.g, BlahBlah)? We do
> this now in a number of cases. In fact, you can have an automated
> build script that generates the code, updates the CM system with it,
> then does the things you usually expect in such a script (extract
> source from CM system, compile, link...)

The part that worries me about that is the 'updates the CM system with
it'. I can see that there _are_ arguments, it's just that I've also
seen projects keep the generated code in the CM system *and then
modify it by hand*.

Re: Compile time executed functions

[Ken Garlington]

"Simon Wright" <simon@pushface.org> wrote in message
news:x7vofuknypt.fsf@smaug.pushface.org...
: "Ken Garlington" <Ken.Garlington@computer.org> writes:
:
: > It's the part about "pasting the output" that seems odd. Why not
: > have it generate a stand-alone Ada *package* (e.g, BlahBlah)? We do
: > this now in a number of cases. In fact, you can have an automated
: > build script that generates the code, updates the CM system with it,
: > then does the things you usually expect in such a script (extract
: > source from CM system, compile, link...)
:
: The part that worries me about that is the 'updates the CM system with
: it'. I can see that there _are_ arguments, it's just that I've also
: seen projects keep the generated code in the CM system *and then
: modify it by hand*.

Note the part about automatically extracting the source from the CM system.
Usually, we set this up so that it would overwrite any "hand-edited"
versions in the same directory.

Re: Compile time executed functions

[Mats Karlssohn]

Simon Wright wrote:
> 
> "Ken Garlington" <Ken.Garlington@computer.org> writes:
> 
> > It's the part about "pasting the output" that seems odd. Why not
> > have it generate a stand-alone Ada *package* (e.g, BlahBlah)? We do
> > this now in a number of cases. In fact, you can have an automated
> > build script that generates the code, updates the CM system with it,
> > then does the things you usually expect in such a script (extract
> > source from CM system, compile, link...)
> 
> The part that worries me about that is the 'updates the CM system with
> it'. I can see that there _are_ arguments, it's just that I've also
> seen projects keep the generated code in the CM system *and then
> modify it by hand*.

Yep, that's the way it's done here (at least for this particular
project).

-- 
Mats Karlssohn, developer                         mailto:mats@mida.se  
Mida Systemutveckling AB                          http://www.mida.se
Box 64, S-732 22 ARBOGA, SWEDEN
Phone: +46-(0)589-89808   Fax: +46-(0)589-89809

Re: Compile time executed functions

[Jean-Marc Bourguet]

Ken Garlington wrote:

> Could you post an example of such a template, and what in the C++ standard
> you rely upon to guarantee compile-time calculations? 

First feature, things like
   enum { foo = x+y*z; }
are valid as long as x, y and z value are known at compile time and have
to be evaluated at compile time.

Second feature it is possible to provide "specialization" for template,
that is provide a different implementation when some template parameter
have some constant value.

The first ensure that evaluation is made at compile time.  The second
that it is possible to make some test.  Looping is available with
recursion so finally you have a computationnally complete language at
compile time.  It is painfull to write and even more painfull to use but
some like abusing the language...

An example, how to compute factorial

#include <iostream>

template <int F>
struct factorial {
   enum { RET = factorial<F-1>::RET*F };
};

template <>
struct factorial<1> {
   enum { RET = 1 };
};

int main() {
   std::cout << factorial<10>::RET << std::endl;
}

> Also, does
> "compile-time" include "link-time", or are you not allowed to have anything
> in the table that uses addresses?

As some C++ compilers do template instanciation at "link-time", I think
the answer is yes.

-- Jean-Marc

Re: Compile time executed functions

[Ken Garlington]

"Jean-Marc Bourguet" <jbourguet@free.fr> wrote in message
news:3AC46252.B7E54EA6@free.fr...
: Ken Garlington wrote:
:
: > Could you post an example of such a template, and what in the C++
standard
: > you rely upon to guarantee compile-time calculations?
:
: First feature, things like
:    enum { foo = x+y*z; }
: are valid as long as x, y and z value are known at compile time and have
: to be evaluated at compile time.

Isn't this usually resolvable as a constant by most Ada compilers? At least
the ones I know will usually do so.

More to the point, does the C++ standard _require_ that foo not generate any
assembly instructions to be executed at run-time? If so, what does it say?

: Second feature it is possible to provide "specialization" for template,
: that is provide a different implementation when some template parameter
: have some constant value.
:
: The first ensure that evaluation is made at compile time.  The second
: that it is possible to make some test.  Looping is available with
: recursion so finally you have a computationnally complete language at
: compile time.  It is painfull to write and even more painfull to use but
: some like abusing the language...
:
: An example, how to compute factorial
:
: #include <iostream>
:
: template <int F>
: struct factorial {
:    enum { RET = factorial<F-1>::RET*F };
: };
:
: template <>
: struct factorial<1> {
:    enum { RET = 1 };
: };
:
: int main() {
:    std::cout << factorial<10>::RET << std::endl;
: }

Are you claiming that this resolves to a single constant value prior to
execution? I don't see how...


: > Also, does
: > "compile-time" include "link-time", or are you not allowed to have
anything
: > in the table that uses addresses?
:
: As some C++ compilers do template instanciation at "link-time", I think
: the answer is yes.

I don't think we're talking about the same thing here...

: -- Jean-Marc

Re: Compile time executed functions

[Jean-Marc Bourguet]

Ken Garlington wrote:
> 
> "Jean-Marc Bourguet" <jbourguet@free.fr> wrote in message
> news:3AC46252.B7E54EA6@free.fr...
> : Ken Garlington wrote:
> :
> : > Could you post an example of such a template, and what in the C++
> standard
> : > you rely upon to guarantee compile-time calculations?
> :
> : First feature, things like
> :    enum { foo = x+y*z; }
> : are valid as long as x, y and z value are known at compile time and have
> : to be evaluated at compile time.
> 
> Isn't this usually resolvable as a constant by most Ada compilers? At least
> the ones I know will usually do so.

It is quite difficult to come with the equivalent in Ada.  One is
   foo : constant = x+y*z;
is indeed resolvable by most Ada compiler.

> More to the point, does the C++ standard _require_ that foo not generate any
> assembly instructions to be executed at run-time? If so, what does it say?

I've not checked what the standard says precisely.  The enum values are
a compile time constant.  They may be used in context like case label
which are to be fixed at compile time.  This

enum { a = 2, b = 3, c = 4, d = 7 };
enum { foo = a+b*c };
enum { bar = a*d };

void f() {
  int foobar;
  switch(foobar) {
    case foo:
      break;
    case bar:
      break;
  }
}

is required to produce a diagnostic as foo and bar have the same value.

> : Second feature it is possible to provide "specialization" for template,
> : that is provide a different implementation when some template parameter
> : have some constant value.
> :
> : The first ensure that evaluation is made at compile time.  The second
> : that it is possible to make some test.  Looping is available with
> : recursion so finally you have a computationnally complete language at
> : compile time.  It is painfull to write and even more painfull to use but
> : some like abusing the language...
> :
> : An example, how to compute factorial
> :
> : #include <iostream>
> :
> : template <int F>
> : struct factorial {
> :    enum { RET = factorial<F-1>::RET*F };
> : };
> :
> : template <>
> : struct factorial<1> {
> :    enum { RET = 1 };
> : };
> :
> : int main() {
> :    std::cout << factorial<10>::RET << std::endl;
> : }
> 
> Are you claiming that this resolves to a single constant value prior to
> execution? 

Yes.  factorial<10>::RET is a single constant value.

> I don't see how...

factorial<10>::RET is defined to be factorial<9>::RET*10
...
factorial<2>::RET is defined to be factorial<1>::RET*2
factorial<1>::RET is defined to be 1 by the specialization (template<>
...)

using template as compile time language is very functionnal.

> : > Also, does
> : > "compile-time" include "link-time", or are you not allowed to have
> anything
> : > in the table that uses addresses?
> :
> : As some C++ compilers do template instanciation at "link-time", I think
> : the answer is yes.
> 
> I don't think we're talking about the same thing here...

I don't think your are allowed to do pointer arithmetic in this
context.  Does that answer better your question?

-- Jean-Marc
BTW, template in C++ is so complex and this kind of thing push the limit
so much that you have to code taking into account the compiler bugs and
limitation.  So such code is very difficult to port.

Re: Compile time executed functions

[Stephen Leake]

Jean-Marc Bourguet <jbourguet@free.fr> writes:

> > : First feature, things like
> > :    enum { foo = x+y*z; }
> > : are valid as long as x, y and z value are known at compile time and have
> > : to be evaluated at compile time.
> > 
> > Isn't this usually resolvable as a constant by most Ada compilers? At least
> > the ones I know will usually do so.
> 
> It is quite difficult to come with the equivalent in Ada.  One is
>    foo : constant = x+y*z;
> is indeed resolvable by most Ada compiler.

Actually, since C and C++ define an enum to be just a named int, this
is the _exact_ equivalent in Ada.

Perhaps you meant to say that 

package A_Package is

   X : constant := 2;
   Y : constant := 3;
   Z : constant := 4;

   type Bar is (Foo);
   for Bar use (Foo => x + y * z);

end A_Package;

is not legal Ada. However, GNAT 3.14a disagrees with you.

-- 
-- Stephe

Re: Compile time executed functions

[Jean-Marc Bourguet]

Stephen Leake wrote:
> 
> Jean-Marc Bourguet <jbourguet@free.fr> writes:
> 
> > > : First feature, things like
> > > :    enum { foo = x+y*z; }
> > > : are valid as long as x, y and z value are known at compile time and have
> > > : to be evaluated at compile time.
> > >
> > > Isn't this usually resolvable as a constant by most Ada compilers? At least
> > > the ones I know will usually do so.
> >
> > It is quite difficult to come with the equivalent in Ada.  One is
> >    foo : constant = x+y*z;
> > is indeed resolvable by most Ada compiler.
> 
> Actually, since C and C++ define an enum to be just a named int,

I don't know for C but for C++ an enum cary more type information that
you seem to think.  There is an implicit conversion from enum to int but
not from int to an enum nor between enum.  The following does not
compile.

enum E1 {a = 1, b = 2, c = 4};
enum E2 {d, e};

void f(E1 x);

void g() {
  f(d);
}

because a E2 is passed where an E1 is expected.

> this
> is the _exact_ equivalent in Ada.

I don't agree.

> Perhaps you meant to say that
[use of representation clause] 
> is not legal Ada. However, GNAT 3.14a disagrees with you.

No.  Using representation clause to try to emulate C++ enum value is
doomed.  The enum values are far more visible to the program.  I think
the more complete way to represent a C++ enum in Ada is use an integer
type or an modular type with the correct range and give typed constant. 
Obviously the best way depend on the usage and may not be the more
complete way...

- Jean-Marc

Re: Compile time executed functions

[Ken Garlington]

"Jean-Marc Bourguet" <jbourguet@free.fr> wrote in message
news:3AC4B7F9.7C73455A@free.fr...
: Ken Garlington wrote:
: >
: > "Jean-Marc Bourguet" <jbourguet@free.fr> wrote in message
: > news:3AC46252.B7E54EA6@free.fr...
: > : Ken Garlington wrote:
: > :
: > : > Could you post an example of such a template, and what in the C++
: > standard
: > : > you rely upon to guarantee compile-time calculations?
: > :
: > : First feature, things like
: > :    enum { foo = x+y*z; }
: > : are valid as long as x, y and z value are known at compile time and
have
: > : to be evaluated at compile time.
: >
: > Isn't this usually resolvable as a constant by most Ada compilers? At
least
: > the ones I know will usually do so.
:
: It is quite difficult to come with the equivalent in Ada.  One is
:    foo : constant = x+y*z;
: is indeed resolvable by most Ada compiler.
:
: > More to the point, does the C++ standard _require_ that foo not generate
any
: > assembly instructions to be executed at run-time? If so, what does it
say?
:
: I've not checked what the standard says precisely.  The enum values are
: a compile time constant.  They may be used in context like case label
: which are to be fixed at compile time.  This
:
: enum { a = 2, b = 3, c = 4, d = 7 };
: enum { foo = a+b*c };
: enum { bar = a*d };
:
: void f() {
:   int foobar;
:   switch(foobar) {
:     case foo:
:       break;
:     case bar:
:       break;
:   }
: }
:
: is required to produce a diagnostic as foo and bar have the same value.

Same with Ada, as far as I know.

These examples are all in terms of "the value has to be calculated as a
scalar before it is used." This is *not* the same as saying "no code is
generated at run-time".

Re: Compile time executed functions

[Jean-Marc Bourguet]

Ken Garlington wrote:
> 
> "Jean-Marc Bourguet" <jbourguet@free.fr> wrote in message
> news:3AC4B7F9.7C73455A@free.fr...
> : Ken Garlington wrote:
> : >
> : > "Jean-Marc Bourguet" <jbourguet@free.fr> wrote in message
> : > news:3AC46252.B7E54EA6@free.fr...
> : > : Ken Garlington wrote:
> : > :
> : > : > Could you post an example of such a template, and what in the C++
> : > standard
> : > : > you rely upon to guarantee compile-time calculations?
> : > :
> : > : First feature, things like
> : > :    enum { foo = x+y*z; }
> : > : are valid as long as x, y and z value are known at compile time and
> have
> : > : to be evaluated at compile time.
> : >
> : > Isn't this usually resolvable as a constant by most Ada compilers? At
> least
> : > the ones I know will usually do so.
> :
> : It is quite difficult to come with the equivalent in Ada.  One is
> :    foo : constant = x+y*z;
> : is indeed resolvable by most Ada compiler.
> :
> : > More to the point, does the C++ standard _require_ that foo not generate
> any
> : > assembly instructions to be executed at run-time? If so, what does it
> say?
> :
> : I've not checked what the standard says precisely.  The enum values are
> : a compile time constant.  They may be used in context like case label
> : which are to be fixed at compile time.  This
> :
> : enum { a = 2, b = 3, c = 4, d = 7 };
> : enum { foo = a+b*c };
> : enum { bar = a*d };
> :
> : void f() {
> :   int foobar;
> :   switch(foobar) {
> :     case foo:
> :       break;
> :     case bar:
> :       break;
> :   }
> : }
> :
> : is required to produce a diagnostic as foo and bar have the same value.
> 
> Same with Ada, as far as I know.

I'm totally unable to come with an equivalent in Ada.  There is no
anonymous enum types, here you have three, the equivalent of the case
labels are constrained to be of the same types, here the value on which
one switch is of one type and the two labels of two different types,...

> These examples are all in terms of "the value has to be calculated as a
> scalar before it is used." This is *not* the same as saying "no code is
> generated at run-time".

I think there are NO requirement about generated code excepted the
observable behavior for conforming program.  Everybody would be
surprised that the generated code for the factorial template I gave
produced something other than what is generated for

int main() {
   std::cout << 3628800 << std::endl;
}

-- Jean-Marc

Re: Compile time executed functions

[Ken Garlington]

"Jean-Marc Bourguet" <jbourguet@free.fr> wrote in message
news:3AC6ED5F.9F2F51A5@free.fr...

: I think there are NO requirement about generated code excepted the
: observable behavior for conforming program.  Everybody would be
: surprised that the generated code for the factorial template I gave
: produced something other than what is generated for
:
: int main() {
:    std::cout << 3628800 << std::endl;
: }

Well, I think you've answered your question, then. You're not talking about
comparing the C++ language with Ada; you're talking about comparing behavior
you were able to produce in one compiler (I assume; have you actually
examined the generated the object code for your example and compiler?) with
other compilers. So, if you want a particular optimization with an Ada
compiler, then you need to look at the object code generated by that
compiler, and tweak it as needed (and possibly work with the vendor to get
what you want).

Re: Compile time executed functions

[Jean-Marc Bourguet]

Ken Garlington wrote:
> 
> "Jean-Marc Bourguet" <jbourguet@free.fr> wrote in message
> news:3AC6ED5F.9F2F51A5@free.fr...
> 
> : I think there are NO requirement about generated code excepted the
> : observable behavior for conforming program.  Everybody would be
> : surprised that the generated code for the factorial template I gave
> : produced something other than what is generated for
> :
> : int main() {
> :    std::cout << 3628800 << std::endl;
> : }
> 
> Well, I think you've answered your question, then.
> You're not talking about comparing the C++ language with Ada;

My question? Me comparing C++ and Ada?  I think you are confusing me
with somebody else. I came into this thread when you asked for an
example of using template in C++ for computing things at compile time to
give you one.  Then you asked for a formal guarantee that it was
computed at compile time.  The level at which the C++ standard describe
semantic make it impossible to have such guarantee.  Do you have a
formal guarantee that an Ada compiler does not generate a function to
calculate the 10! when you use the litteral 3628800?  I don't think so
and there is no such guarantee for C++. What the C++ standard does is
constraint the expression to be a constant integer expression and allows
the defined named and such expressions to be used in place like case
labels, array sizes and template parameters where no C++ programmer
would expect the expression be evaluated at run-time, where no sane C++
compiler would evaluate the expression at run-time. 

> So, if you want a particular optimization with an Ada
> compiler, then you need to look at the object code generated by that
> compiler, and tweak it as needed (and possibly work with the vendor to get
> what you want).

I think the success of "template meta programming" (as this abuse of the
template system is called by some) is the fact that there is no need to
count on compiler optimization to get the effect, and you may also do
some other things like computing type.  So running this 

#include <iostream>

template <int F>
struct factorial {
   enum { RET = factorial<F-1>::RET*F };
};

template <>
struct factorial<1> {
   enum { RET = 1 };
};

template <int F>
struct ken {
  typedef int T;
};

template <>
struct ken<3628800> {
  typedef double T;
};

int main() {
  ken<factorial<10>::RET >::T x10 = 0.5;
  ken<factorial<11>::RET >::T x11 = 0.5;
  std::cout << "x10=" << x10
	    << "\nx11=" << x11 << std::endl;
}

produces

x10=0.5
x11=0

because x10 is a double while x11 is an int.  But I agree, that is still
not a formal guarantee that the compiler does not compute the type of
x10 and x11 at run time :-)

Some seems to think that the biggest difference between Ada generic and
C++ template is the fact that the templates are instanciated
automatically or that they are constrained by use.  My point of view is
that these differences are syntaxic differences and do not modify
significantly the expressing power.  I think that the ability to
specialize template is a point where the C++ templates are more
powerfull than the Ada generics.

Yours,

-- Jean-Marc

Re: Compile time executed functions

[Robert A Duff]

Jean-Marc Bourguet <jbourguet@free.fr> writes:

> My question? Me comparing C++ and Ada?  I think you are confusing me
> with somebody else. I came into this thread when you asked for an
> example of using template in C++ for computing things at compile time to
> give you one.  Then you asked for a formal guarantee that it was
> computed at compile time.  The level at which the C++ standard describe
> semantic make it impossible to have such guarantee.  Do you have a
> formal guarantee that an Ada compiler does not generate a function to
> calculate the 10! when you use the litteral 3628800?  I don't think so
> and there is no such guarantee for C++. What the C++ standard does is
> constraint the expression to be a constant integer expression and allows
> the defined named and such expressions to be used in place like case
> labels, array sizes and template parameters where no C++ programmer
> would expect the expression be evaluated at run-time, where no sane C++
> compiler would evaluate the expression at run-time. 

Right.  In fact, a C++ compiler would have to go to some extra trouble
to evaluate these sorts of things at run time, so it's safe to say that
it doesn't.

> Some seems to think that the biggest difference between Ada generic and
> C++ template is the fact that the templates are instanciated
> automatically or that they are constrained by use.  My point of view is
> that these differences are syntaxic differences and do not modify
> significantly the expressing power.  I think that the ability to
> specialize template is a point where the C++ templates are more
> powerfull than the Ada generics.

Also, Ada generics can't be recursive.

- Bob

Re: Compile time executed functions

[Jean-Marc Bourguet]

Robert A Duff wrote:
> 
> Jean-Marc Bourguet <jbourguet@free.fr> writes:
[...]
> > I think that the ability to
> > specialize template is a point where the C++ templates are more
> > powerfull than the Ada generics.
> 
> Also, Ada generics can't be recursive.

How would you stop the recursion without an equivalent to
specialisation?  And with a equivalent to specialisation it 
would be natural to allow recusion.

-- Jean-Marc

Re: Compile time executed functions

[Pat Rogers]

"Robert A Duff" <bobduff@world.std.com> wrote in message
news:wcc4rw7ealq.fsf@world.std.com...
<snip>
> Also, Ada generics can't be recursive.

Lest people not familiar with Ada misinterpret Bob's statement -- if I may
be so bold as to put words in his mouth -- he doesn't mean that a generic
subprogram cannot be a recursive subprogram once instantiated.  He means
that the generic itself cannot be recursive, as in:

generic
procedure P;

procedure P is

  procedure PP is new P; -- this is not legal; the name P is that of an
instance

begin
  ...
end P;


(Sorry if that is not what you meant.)

---
Patrick Rogers                       Consulting and Training in:
http://www.classwide.com        Real-Time/OO Languages
progers@classwide.com          Hard Deadline Schedulability Analysis
(281)648-3165                          Software Fault Tolerance

Re: Compile time executed functions

[Ken Garlington]

"Jean-Marc Bourguet" <jbourguet@free.fr> wrote in message
news:3AC84628.D8B70C7C@free.fr...
: Ken Garlington wrote:
: >
: > "Jean-Marc Bourguet" <jbourguet@free.fr> wrote in message
: > news:3AC6ED5F.9F2F51A5@free.fr...
: >
: > : I think there are NO requirement about generated code excepted the
: > : observable behavior for conforming program.  Everybody would be
: > : surprised that the generated code for the factorial template I gave
: > : produced something other than what is generated for
: > :
: > : int main() {
: > :    std::cout << 3628800 << std::endl;
: > : }
: >
: > Well, I think you've answered your question, then.
: > You're not talking about comparing the C++ language with Ada;
:
: My question?

Sorry, "the" question.

: Me comparing C++ and Ada?  I think you are confusing me
: with somebody else. I came into this thread when you asked for an
: example of using template in C++ for computing things at compile time to
: give you one.

More specifically, I asked "Could you post an example of such a template,
and what in the C++ standard you rely upon to guarantee compile-time
calculations?"

: Then you asked for a formal guarantee that it was
: computed at compile time.

Note that this was part of my *initial* question to which you first
responded, and is important given the *original* question: "I'd like to have
the compiler to execute a function for me (at compile time!) and use the
return of that function to initialize the constant." Also relevant was the
later statement "Ada generics is not as expressiv [sic] as C++ templates
with regard to what you can get the compiler to execute for you at compile
time." As you've indicated, there apparently is no guarantee that a C++
template will be "executed at compile time." It simply tends to be the
behavior available from certain compilers. Similarly, there are some Ada
compilers that can optimize functions down to a constants, depending upon
the compiler and the nature of the function. If the customer base believes
that a particular optimization is important, the vendor will probably
support it (or go out of business). Therefore, if you want more
optimizations, you probably aren't talking about something that is part of
the language.

: The level at which the C++ standard describe
: semantic make it impossible to have such guarantee.  Do you have a
: formal guarantee that an Ada compiler does not generate a function to
: calculate the 10! when you use the litteral 3628800?

Which is exactly the point - there doesn't seem to be a true "compile time"
function with respect to either language, only optimization techniques that
are applied to various degree in *instances* of the language. Note that it
could be possible for a language to define required optimizations -- Erlang,
for example, appears to do so with tail recursion -- but asking for Ada to
provide the "same guarantees" as C++ in this area is vacuously true, AFAIK.

: I don't think so
: and there is no such guarantee for C++. What the C++ standard does is
: constraint the expression to be a constant integer expression and allows
: the defined named and such expressions to be used in place like case
: labels, array sizes and template parameters where no C++ programmer
: would expect the expression be evaluated at run-time, where no sane C++
: compiler would evaluate the expression at run-time.

This sounds suspiciously like a "guarantee". Do most "sane" C++ programmers
expect things that aren't there? ;)

I assume what you mean is that most C++ compilers tend to share certain
standard optimizations, and that as a result it would surprise a C++
programmer if they weren't done (assuming they would notice). Of course, the
problem with this is that there's no formal list of what "everyone" expects,
and so I imagine "surprises" do occur from time to time. If your program was
depending upon not being surprised, this would be a Bad Thing -- thus, it's
always a good idea IMHO not to depend upon such "sanity".

: > So, if you want a particular optimization with an Ada
: > compiler, then you need to look at the object code generated by that
: > compiler, and tweak it as needed (and possibly work with the vendor to
get
: > what you want).
:
: I think the success of "template meta programming" (as this abuse of the
: template system is called by some) is the fact that there is no need to
: count on compiler optimization to get the effect,

This is a particularly puzzling statement. Why do you believe you are not
counting on a compiler optimization for the case you presented?

: and you may also do
: some other things like computing type.  So running this
:
: #include <iostream>
:
: template <int F>
: struct factorial {
:    enum { RET = factorial<F-1>::RET*F };
: };
:
: template <>
: struct factorial<1> {
:    enum { RET = 1 };
: };
:
: template <int F>
: struct ken {
:   typedef int T;
: };
:
: template <>
: struct ken<3628800> {
:   typedef double T;
: };
:
: int main() {
:   ken<factorial<10>::RET >::T x10 = 0.5;
:   ken<factorial<11>::RET >::T x11 = 0.5;
:   std::cout << "x10=" << x10
:     << "\nx11=" << x11 << std::endl;
: }
:
: produces
:
: x10=0.5
: x11=0
:
: because x10 is a double while x11 is an int.  But I agree, that is still
: not a formal guarantee that the compiler does not compute the type of
: x10 and x11 at run time :-)

I'm not sure what it means to "compute a type." I assume you're talking
about type conversions? Most Ada compilers also can optimize type
conversions under the right conditions, e.g. trivially:

X : constant Integer := Integer(0.5);

will usually not generate any code to do the conversion. Again, however,
this is a compiler-specific optimization, not a requirement of the language.

: Some seems to think that the biggest difference between Ada generic and
: C++ template is the fact that the templates are instanciated
: automatically or that they are constrained by use.  My point of view is
: that these differences are syntaxic differences and do not modify
: significantly the expressing power.  I think that the ability to
: specialize template is a point where the C++ templates are more
: powerfull than the Ada generics.
:
: Yours,
:
: -- Jean-Marc

Re: Compile time executed functions

[Robert A Duff]

"Ken Garlington" <Ken.Garlington@computer.org> writes:

> Which is exactly the point - there doesn't seem to be a true "compile time"
> function with respect to either language, only optimization techniques that
> are applied to various degree in *instances* of the language.

Well, I wouldn't call the C++ template case an "optimization".  To me,
and optimization is when the compiler goes to extra trouble in the hopes
of generating more efficient code.  "Extra trouble" = more trouble than
the simplest compilation technique anybody can imagine.  If a compiler
evaluates an Ada function at compile time, that's clearly an
optimization.  But a C++ compiler would have to go to extra trouble
*not* to evaluate templates at compile time -- so I don't call it an
optimization to evaluate them at compile time.  In fact, I'll bet that
100% of all C++ compilers that now exist, or that ever exist, are
capable of evaluating the example (the factorial template someone
posted) at compile time.

>... Note that it
> could be possible for a language to define required optimizations -- Erlang,
> for example, appears to do so with tail recursion -- but asking for Ada to
> provide the "same guarantees" as C++ in this area is vacuously true, AFAIK.

Formally speaking, that's true.

>...If your program was
> depending upon not being surprised, this would be a Bad Thing -- thus, it's
> always a good idea IMHO not to depend upon such "sanity".

It's unavoidable.  All programs depend on various "sanity" aspects of
compilers -- aspects that are not formally defined in the language
definition.

- Bob

Re: Compile time executed functions

[Ken Garlington]

"Robert A Duff" <bobduff@world.std.com> wrote in message
news:wcczodzctdl.fsf@world.std.com...

: It's unavoidable.  All programs depend on various "sanity" aspects of
: compilers -- aspects that are not formally defined in the language
: definition.

"Sanity" with respect to optimizations?

Re: Compile time executed functions

[Robert A Duff]

"Ken Garlington" <Ken.Garlington@computer.org> writes:

> "Robert A Duff" <bobduff@world.std.com> wrote in message
> news:wcczodzctdl.fsf@world.std.com...
> 
> : It's unavoidable.  All programs depend on various "sanity" aspects of
> : compilers -- aspects that are not formally defined in the language
> : definition.
> 
> "Sanity" with respect to optimizations?

Sure.  The RM does not say how long it takes to, say, do an assignment
on an integer variable.  But if it took three weeks, any program doing
integer assignment would be useless.  We have to trust the compiler to
be sane enough to generate reasonable code for that assignment, even
though the RM doesn't *require* it.

- Bob

Re: Compile time executed functions

[Jean-Marc Bourguet]

Ken Garlington wrote:
> 
> "Jean-Marc Bourguet" <jbourguet@free.fr> wrote in message
> news:3AC84628.D8B70C7C@free.fr...
[...]
> : I think the success of "template meta programming" (as this abuse of the
> : template system is called by some) is the fact that there is no need to
> : count on compiler optimization to get the effect,
> 
> This is a particularly puzzling statement. Why do you believe you are not
> counting on a compiler optimization for the case you presented?

You keep calling evaluating these expressions an optimization.  I think
nobody familiar with C++ will.  There is no formal guarantee but the
trouble would be to make a compiler not compute these at compile time
and still respect the other aspect of the standard.
 
> : and you may also do
> : some other things like computing type.  So running this
> :
> : #include <iostream>
> :
> : template <int F>
> : struct factorial {
> :    enum { RET = factorial<F-1>::RET*F };
> : };
> :
> : template <>
> : struct factorial<1> {
> :    enum { RET = 1 };
> : };
> :
> : template <int F>
> : struct ken {
> :   typedef int T;
> : };
> :
> : template <>
> : struct ken<3628800> {
> :   typedef double T;
> : };
> :
> : int main() {
> :   ken<factorial<10>::RET >::T x10 = 0.5;
> :   ken<factorial<11>::RET >::T x11 = 0.5;
> :   std::cout << "x10=" << x10
> :     << "\nx11=" << x11 << std::endl;
> : }
> :
> : produces
> :
> : x10=0.5
> : x11=0
> :
> : because x10 is a double while x11 is an int.  But I agree, that is still
> : not a formal guarantee that the compiler does not compute the type of
> : x10 and x11 at run time :-)
> 
> I'm not sure what it means to "compute a type." 

The type of x10 is double because factorial<10>::RET evaluates to
3628800 and the type of x11 is int because factorial<11>::RET evaluates
to something different than 3628800.  The above program is exactly the
same as

#include <iostream>

int main() {
  double x10 = 0.5;
  int    x11 = 0.5;
  std::cout << "x10=" << x10
            << "\nx11=" << x11 << std::endl; 
}

-- Jean-Marc

Re: Compile time executed functions

[Mats Karlssohn]

Jean-Marc Bourguet wrote:
> 
> Ken Garlington wrote:
> 
> > Could you post an example of such a template, and what in the C++ standard
> > you rely upon to guarantee compile-time calculations?
> 
[Example deleted]
> > Also, does
> > "compile-time" include "link-time", or are you not allowed to have anything
> > in the table that uses addresses?


I missed to comment on this one, yes you are allowed to use addresses
or addess dependent stuff in the table. For this discussion the linking
is included in 'compile time' (sloppy language, I'm sorry).


And thank you Jean-Marc! You provided the example that I didn't
manage to provide!

-- 
Mats Karlssohn, developer                         mailto:mats@mida.se  
Mida Systemutveckling AB                          http://www.mida.se
Box 64, S-732 22 ARBOGA, SWEDEN
Phone: +46-(0)589-89808   Fax: +46-(0)589-89809

Re: Compile time executed functions

[Mats Karlssohn]

Ken Garlington wrote:
%<
> : Say I want to create a table of data. The data is constant and must not
> : change during the programs lifetime. Further more, the data is quite
> : time consuming to calculate.
> :
> : In C++ (bad word again :) I can (with some effort) write a template that
> : does all the calculations in the compiler at compile time.
> 
> Could you post an example of such a template, and what in the C++ standard
> you rely upon to guarantee compile-time calculations? Also, does
> "compile-time" include "link-time", or are you not allowed to have anything
> in the table that uses addresses?

Well.. no. I must admit (quite embarresed) that I can't, I spent a few
hours during the weekend trying to put together an example, but I
couldn't
get it to work. However (and more importantly) I've seen such a thing
done, I just havn't acces to that sourcecode anymore, so I really can't
examine it. Bugger, it might be that I'm plain wrong and have fallen for
some 'good talk for the project management' (I'm NOT the manager,
but...)



> It's the part about "pasting the output" that seems odd. Why not have it
> generate a stand-alone Ada *package* (e.g, BlahBlah)? We do this now in a
> number of cases. In fact, you can have an automated build script that
> generates the code, updates the CM system with it, then does the things you
> usually expect in such a script (extract source from CM system, compile,
> link...)

Yes, I could, but:
1. I'm too lazy to do it.
2. There's quite a lot of other code/data in the package.

But this actually gives me an idea, my data table could be separate,
right ? That would render the output from the tool so small that I
actually could generate the whole source file, so that no handediting
is needed. I'll need to investigate this.

> : Am I plain stupid since I worry about when what's included in my
> : output and when time is consumed ?
> 
> Not at all. However, the source generation option can be just as reliable
> (more so, since it's less dependent on compiler-specific optimizations) that
> whjat you are wanting, IMHO. Even better, you can readily reuse the concept
> if you move between languages (just have the source generation tool use a
> template file to control the form of the output).

OK

I thought that i had decided to let the tool produce an (ELF) object
file
and just pragma Import(..) a symbol from that. Now I'll investigate and
reconsider.

-- 
Mats Karlssohn, developer                         mailto:mats@mida.se  
Mida Systemutveckling AB                          http://www.mida.se
Box 64, S-732 22 ARBOGA, SWEDEN
Phone: +46-(0)589-89808   Fax: +46-(0)589-89809

Re: Compile time executed functions

[Ken Garlington]

"Mats Karlssohn" <mats@mida.se> wrote in message
news:3ACAD197.FB2C3303@mida.se...

: But this actually gives me an idea, my data table could be separate,
: right ? That would render the output from the tool so small that I
: actually could generate the whole source file, so that no handediting
: is needed. I'll need to investigate this.

This is exactly how we do it - when we have this situation, we try to put
the auto-generated info (and *only( the auto-generated info) in a separate
package. This allows us to do updates with minimal impact to the rest of the
system. We do this in Ada83; you might want to look at some of the packaging
options (e.g. child packages) to make it even more convienient.

Re: Compile time executed functions

[Mats Karlssohn]

Ken Garlington wrote:
> 
> "Mats Karlssohn" <mats@mida.se> wrote in message
> news:3ACAD197.FB2C3303@mida.se...
> 
> : But this actually gives me an idea, my data table could be separate,
> : right ? That would render the output from the tool so small that I
> : actually could generate the whole source file, so that no handediting
> : is needed. I'll need to investigate this.
> 
> This is exactly how we do it - when we have this situation, we try to put
> the auto-generated info (and *only( the auto-generated info) in a separate
> package. This allows us to do updates with minimal impact to the rest of the
> system. We do this in Ada83; you might want to look at some of the packaging
> options (e.g. child packages) to make it even more convienient.

I'll do that, I guess it's the way to go with today's Ada. I'll also
investigate the option of generate object code, since I belive it may
save som compilation time and more important, it saves some CM hassle
caused by bad management policy.

TNX

-- 
Mats Karlssohn, developer                         mailto:mats@mida.se  
Mida Systemutveckling AB                          http://www.mida.se
Box 64, S-732 22 ARBOGA, SWEDEN
Phone: +46-(0)589-89808   Fax: +46-(0)589-89809

Re: Compile time executed functions

[Tucker Taft]

Mats Karlssohn wrote:
> ...
> > This is exactly how we do it - when we have this situation, we try to put
> > the auto-generated info (and *only( the auto-generated info) in a separate
> > package. This allows us to do updates with minimal impact to the rest of the
> > system. We do this in Ada83; you might want to look at some of the packaging
> > options (e.g. child packages) to make it even more convienient.
> 
> I'll do that, I guess it's the way to go with today's Ada. I'll also
> investigate the option of generate object code, since I belive it may
> save som compilation time and more important, it saves some CM hassle
> caused by bad management policy.

One nice option with "today's Ada" is to put the table(s)
in a package body, and then return a "general" access
value pointing to it via a function, which eliminates
any compile-time dependence on the contents of the tables.

> 
> TNX
> 
> --
> Mats Karlssohn, developer                         mailto:mats@mida.se
> Mida Systemutveckling AB                          http://www.mida.se
> Box 64, S-732 22 ARBOGA, SWEDEN
> Phone: +46-(0)589-89808   Fax: +46-(0)589-89809

-- 
-Tucker Taft   stt@avercom.net   http://www.averstar.com/~stt/
Chief Technology Officer, AverCom Corporation (A Titan Company) 
Burlington, MA  USA (AverCom was formerly the Commercial Division of AverStar:
http://www.averstar.com/services/ebusiness_applications.html)

Re: Compile time executed functions

[Ted Dennison]

In article <3AC03CCE.70E3C2D5@mida.se>, Mats Karlssohn says...
>That is I'd like to have the compiler to execute a function for me (at
>compiletime!) and use the return of that function to initialize the
>constant.
>
>Example (pleas, this is just an example, it hasn't been compiled):
..
>- The constant is really a constant an should therefore be placed in
>ROM.
>- Therefore the function Generate_CRC_Table isn't needed in the output
>  at all and since it may be quite large and/or time consuming it would
>  be nice to do the job once, at compile time.
..
>I must admit that I havn't researched enough to say that I can't get the
>same effect using generice and/or other techniques in Ada.

You can't. As near as I can tell, you are doing what you need to do in order to
get the result you desire.

>I have hoped to get the time to either build a small preprocessor to do
>this kind of execution/substitution trick, or to add the same trick into
>GNAT using some pragma(Compiler_Executed, func). Sorry to say, I don't
>see that ammount of time in the near future.

If you are talking about being able to run pretty much *any* code at compile
time, no that can't be done with just a "trick". I don't know of any language in
existance (but I suppose there probably is one somewhere) that will let you do
that. It might be doable for a self-hosted system, but for a cross-compiled
system (which I suspect is your situation, otherwise you wouldn't be worrying
about making the result ROMable) I don't think it would be possible at all. The
cross compiler would also have to include a full-fledged native compiler!

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: Compile time executed functions

[Mark Biggar]

Ted Dennison wrote:
> 
> In article <3AC03CCE.70E3C2D5@mida.se>, Mats Karlssohn says...
> >That is I'd like to have the compiler to execute a function for me (at
> >compiletime!) and use the return of that function to initialize the
> >constant.
> >I have hoped to get the time to either build a small preprocessor to do
> >this kind of execution/substitution trick, or to add the same trick into
> >GNAT using some pragma(Compiler_Executed, func). Sorry to say, I don't
> >see that ammount of time in the near future.
> 
> If you are talking about being able to run pretty much *any* code at compile
> time, no that can't be done with just a "trick". I don't know of any language in
> existance (but I suppose there probably is one somewhere) that will let you do
> that.
> It might be doable for a self-hosted system, but for a cross-compiled
> system (which I suspect is your situation, otherwise you wouldn't be worrying
> about making the result ROMable) I don't think it would be possible at all. The
> cross compiler would also have to include a full-fledged native compiler!

Actually almost any compiled langauge "supports" this using a "trick".
You can always write separate standalone programs that generate
source code to be compiled.  It's trivial to set up your make file 
or equivalent to support this.  The generated program doesn't even
have to be the same lanaguage if you don't have a self-hosted backend
for Ada.  Even using a scripting langauge like Perl or Python would do.

So, his best bet is to write a small program that generates the Ada 
source code for the constant table in it's own package.  Not only
does this solve his problem, but is much easier to debug problems
with the table as the result is human readable and verifiable.

--
Mark Biggar
mark.a.biggar@home.com

Re: Compile time executed functions

[Florian Weimer]

Ted Dennison<dennison@telepath.com> writes:

> If you are talking about being able to run pretty much *any* code at
> compile time, no that can't be done with just a "trick". I don't
> know of any language in existance (but I suppose there probably is
> one somewhere) that will let you do that.

FORTH and Common Lisp (at least implementations which support
compilation) can do this.

Re: Compile time executed functions

[Florian Weimer]

Ted Dennison<dennison@telepath.com> writes:

> If you are talking about being able to run pretty much *any* code at
> compile time, no that can't be done with just a "trick". I don't
> know of any language in existance (but I suppose there probably is
> one somewhere) that will let you do that.

FORTH, Common Lisp (if there's any compilation at all) and Java (in
some sense) can do this.

Re: Compile time executed functions

[Ted Dennison]

In article <87ae67qdrv.fsf@deneb.enyo.de>, Florian Weimer says...
>
>Ted Dennison<dennison@telepath.com> writes:
>
>> If you are talking about being able to run pretty much *any* code at
>> compile time, no that can't be done with just a "trick". I don't
>> know of any language in existance (but I suppose there probably is
>> one somewhere) that will let you do that.
>
>FORTH, Common Lisp (if there's any compilation at all) and Java (in
>some sense) can do this.

FORTH I don't know. However, I have used Common Lisp, and I never came across
that capability before. How do you do it? What mechanisim tells the Lisp
compiler to run the code in a complicated function at compile time rather than
run time?

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: Compile time executed functions

[Florian Weimer]

Ted Dennison<dennison@telepath.com> writes:

> >FORTH, Common Lisp (if there's any compilation at all) and Java (in
> >some sense) can do this.
> 
> FORTH I don't know.

FORTH is a bit unfair anyway because it's not clear if typical
implementations are compilers or interpreters.

> However, I have used Common Lisp, and I never came across that
> capability before. How do you do it? 

You build the function (or a lambda expression) using the usual
methods, and then call COMPILE on it.  Simple, isn't it? ;-)

> What mechanisim tells the Lisp compiler to run the code in a
> complicated function at compile time rather than run time?

Since functions are first-class objects, no such mechanisms are
required.

Re: Compile time executed functions

[Ted Dennison]

In article <87lmprow3a.fsf@deneb.enyo.de>, Florian Weimer says...
>
>Ted Dennison<dennison@telepath.com> writes:
>
>> However, I have used Common Lisp, and I never came across that
>> capability before. How do you do it? 
>
>You build the function (or a lambda expression) using the usual
>methods, and then call COMPILE on it.  Simple, isn't it? ;-)
>

Admittedly, there are probably tons of nifty Lisp tricks I've never learned. But
that just generates code for the function, right? It doesn't actually execute
the code, find the resulting return value, then place that value in a data
object *during compile time*. To do that, you'd have to use
define-compiler-macro. Again, I'm no Lisp expert, but I don't see why
define-compiler-macro would have been placed in the language, if its effect
could be achieved without it. (Although it seems to me that even
define-compiler-macro for a complicated function would just expand to the code
required to compute the value, not to the value itself).

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: Compile time executed functions

[Florian Weimer]

Ted Dennison<dennison@telepath.com> writes:

> >You build the function (or a lambda expression) using the usual
> >methods, and then call COMPILE on it.  Simple, isn't it? ;-)

> But that just generates code for the function, right?

Yes, but this way, values can be computed prior to run time which
appear to be constants (even during compile time) but are in fact not.

> It doesn't actually execute the code, find the resulting return
> value, then place that value in a data object *during compile time*.

I think the concepts 'compile time' and 'run time' are a bit blurry
with Common Lisp (a CL enthusiast would protest, of course), simply
because we're used to the fact that 'run time' follows 'compile time',
and not the other way round.  With CL (and FORTH as well, and most
Java implementations), this is no longer true.

> To do that, you'd have to use define-compiler-macro.

Or some eval-when construct, I think.

Re: Compile time executed functions

[Georg Bauhaus]

Florian Weimer (fw@deneb.enyo.de) wrote:

: because we're used to the fact that 'run time' follows 'compile time',
: and not the other way round.  With CL (and FORTH as well, and most
: Java implementations), this is no longer true.

And don't forget SNOBOL4 :-)

Re: Compile time executed functions

[Florian Weimer]

sb463ba@l1-hrz.uni-duisburg.de (Georg Bauhaus) writes:

> Florian Weimer (fw@deneb.enyo.de) wrote:
> 
> : because we're used to the fact that 'run time' follows 'compile time',
> : and not the other way round.  With CL (and FORTH as well, and most
> : Java implementations), this is no longer true.
> 
> And don't forget SNOBOL4 :-)

Hmm, I've installed a SNOBOL4 compiler on my machine a few months ago
but didn't find time to look at the programming language.  I'm
surprised that you can invoke the compiler during runtime.  Do you
have an example?  Which language construct is used for that?

Re: Compile time executed functions

[Ted Dennison]

In article <874rweoo2p.fsf@deneb.enyo.de>, Florian Weimer says...
>
>Ted Dennison<dennison@telepath.com> writes:
>
>> >You build the function (or a lambda expression) using the usual
>> >methods, and then call COMPILE on it.  Simple, isn't it? ;-)
>
>> But that just generates code for the function, right?
>
>Yes, but this way, values can be computed prior to run time which
>appear to be constants (even during compile time) but are in fact not.

Ahhh. But that's not what he was talking about. He wants to be able to supply
some arbitrary function (like say an integrator or a matrix math routine or a
search routine) which the compiler will then run during the compile phase, find
the value of the result (eg: 3.57) and then place that value in a constant which
he can have the compiler stick in the ROM section of the generated code. In
order to stick a value in the ROM section, it clearly cannot be computed at
runtime. It has to be calulated by the compiler at compile time and built into a
ROM section in the reulting executable.

After thinking about this some more, I'll go so far as to say that I don't think
there are *any* languages that supply this capability. If there are, there
certianly aren't many. The reason is as follows:

Let us assume there is a compiler X that allows any aribitrary routine to be
supplied which it will run during the compile phase, find the result, and store
that result value in a constant. There are two possible approaches that X can
take to support this capability. 

Approach 1 is that compiler X makes no attempt to verify that the supplied
routine is valid. In this case, it would be possible for the user to supply a
non-halting routine to the compiler (eg: an estimating integration routine that
has a bug where it never converges). Thus a compiler that takes approach 1 can
under some circumstances go into an infinte loop during compilation due to a bug
in user code, and it must be the user's responsiblily to prevent this, and to
detect the condition when it occurs (vs. a routine that just takes a long time)
and kill the compiler somehow. This must be accepted as normal operation of
compiler X(1).

Approach 2 is that compiler X does not accept non-halting routines. However,
this means compiler X(2) is magic, since the halting problem has been proven to
be unsolvable in the general case. Whatever you do, don't tick off the developer
of X(2)! :-)

I'd claim that most developers will not accept the responsibility of an X(1)
compiler, and X(2) is impossible. The only possible way out is to somehow put
restrictions on the routines that may be supplied to the compiler so that all
possilbe non-halting routines are disallowed. That pretty much means nothing
with a loop (except possibly a for loop) or a goto, or another subroutine call
(recursion is another type of loop, but this may be softened by building and
checking some kind of call tree at compile time instead). These restrictions
would allow some simple subroutines, but nothing complicated like a
pointer-based list search or an estimating integrator, which is the kind of
stuff the original poster wanted to use.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: Compile time executed functions

[David C. Hoos, Sr.]

Just to set the record straight -- the original poster's example was a CRC
lookup table -- not something that would involve the halting problem.

I had the same problem years ago when writing JOVIAL for the
AC-130 gunship.  We had to do a number of diagnostic tasks in the
idle task -- one of which was to do a CRC check on the text and constant
data areas of memory, to make sure they hadn't changed.

My solution to the table generation problem was to write a standalone
program that generated the table and wrote it to a file in JOVIAL
source code format, to be included in the source to be compiled.


"Ted Dennison" <dennison@telepath.com> wrote in message
news:Minw6.344$bY4.291@www.newsranger.com...
> In article <874rweoo2p.fsf@deneb.enyo.de>, Florian Weimer says...
> >
> >Ted Dennison<dennison@telepath.com> writes:
> >
> >> >You build the function (or a lambda expression) using the usual
> >> >methods, and then call COMPILE on it.  Simple, isn't it? ;-)
> >
> >> But that just generates code for the function, right?
> >
> >Yes, but this way, values can be computed prior to run time which
> >appear to be constants (even during compile time) but are in fact not.
>
> Ahhh. But that's not what he was talking about. He wants to be able to
supply
> some arbitrary function (like say an integrator or a matrix math routine
or a
> search routine) which the compiler will then run during the compile phase,
find
> the value of the result (eg: 3.57) and then place that value in a constant
which
> he can have the compiler stick in the ROM section of the generated code.
In
> order to stick a value in the ROM section, it clearly cannot be computed
at
> runtime. It has to be calulated by the compiler at compile time and built
into a
> ROM section in the reulting executable.
>
> After thinking about this some more, I'll go so far as to say that I don't
think
> there are *any* languages that supply this capability. If there are, there
> certianly aren't many. The reason is as follows:
>
> Let us assume there is a compiler X that allows any aribitrary routine to
be
> supplied which it will run during the compile phase, find the result, and
store
> that result value in a constant. There are two possible approaches that X
can
> take to support this capability.
>
> Approach 1 is that compiler X makes no attempt to verify that the supplied
> routine is valid. In this case, it would be possible for the user to
supply a
> non-halting routine to the compiler (eg: an estimating integration routine
that
> has a bug where it never converges). Thus a compiler that takes approach 1
can
> under some circumstances go into an infinte loop during compilation due to
a bug
> in user code, and it must be the user's responsiblily to prevent this, and
to
> detect the condition when it occurs (vs. a routine that just takes a long
time)
> and kill the compiler somehow. This must be accepted as normal operation
of
> compiler X(1).
>
> Approach 2 is that compiler X does not accept non-halting routines.
However,
> this means compiler X(2) is magic, since the halting problem has been
proven to
> be unsolvable in the general case. Whatever you do, don't tick off the
developer
> of X(2)! :-)
>
> I'd claim that most developers will not accept the responsibility of an
X(1)
> compiler, and X(2) is impossible. The only possible way out is to somehow
put
> restrictions on the routines that may be supplied to the compiler so that
all
> possilbe non-halting routines are disallowed. That pretty much means
nothing
> with a loop (except possibly a for loop) or a goto, or another subroutine
call
> (recursion is another type of loop, but this may be softened by building
and
> checking some kind of call tree at compile time instead). These
restrictions
> would allow some simple subroutines, but nothing complicated like a
> pointer-based list search or an estimating integrator, which is the kind
of
> stuff the original poster wanted to use.
>
> ---
> T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
>           home email - mailto:dennison@telepath.com

Re: Compile time executed functions

[Robert A Duff]

Ted Dennison<dennison@telepath.com> writes:

> After thinking about this some more, I'll go so far as to say that I don't think
> there are *any* languages that supply this capability.

That's not correct.  The Bliss language has a macro facility that can
use the full power of the language at compile time.  Lisp macros also
allow the full power of Lisp at compile time.

As you point out, this means that you can have infinite loops at compile
time.  In practise, that's not a big deal: you deal with infinite
compile-time loops the same way as run-time ones.  If you think the
thing is taking too long, you type control-C and investigate.  Or if
you're doing a batch build, you set time-outs.  Or you could have the
compiler count the number of iterations of each loop, and stop after
"too many".  (After all, a very long loop is just as bad as an infinite
one.)

In fact, I would argue that compile-time infinite loops are less
damaging than run-time infinite loops, because a compile-time infinite
loop is guaranteed to be found by the programmer, whereas a run-time
loop might sneak through testing and escape to the customer.

Come to think of it, can't you write infinite loops using the C macro
preprocessor?  Eg, a file that #include's itself?  Or a macro that
expands to something containing a call to itself?

>... The only possible way out is to somehow put
> restrictions on the routines that may be supplied to the compiler so that all
> possilbe non-halting routines are disallowed. That pretty much means nothing
> with a loop (except possibly a for loop) or a goto, or another subroutine call
> (recursion is another type of loop, but this may be softened by building and
> checking some kind of call tree at compile time instead).

It's still sort of research-y, but it is possible to do much better than
that.  Various techniques exist for proving that more general loops
terminate.  Perhaps someday it will be common practise to prove
termination for 99% of the loops we actually write (and mark the residue
as "can't prove" or "intentionally infinite").

But this is orthogonal to the issue of compile time vs run time.  If you
had a fancy program prover, you would use it for both.

- Bob

Re: Compile time executed functions

[Brian Rogoff]

On Wed, 28 Mar 2001, Robert A Duff wrote:
> Ted Dennison<dennison@telepath.com> writes:
> 
> > After thinking about this some more, I'll go so far as to say that I don't think
> > there are *any* languages that supply this capability.
> 
> That's not correct.  The Bliss language has a macro facility that can
> use the full power of the language at compile time.  Lisp macros also
> allow the full power of Lisp at compile time.
> 
> As you point out, this means that you can have infinite loops at compile
> time.  In practise, that's not a big deal: you deal with infinite
> compile-time loops the same way as run-time ones.  If you think the
> thing is taking too long, you type control-C and investigate.  Or if
> you're doing a batch build, you set time-outs.  Or you could have the
> compiler count the number of iterations of each loop, and stop after
> "too many".  (After all, a very long loop is just as bad as an infinite
> one.)

That's just what C++ does with template instantiation, where the iteration
limit is set to 17 I think. Before that, you could express arbitrary
computations in the template language and do all sorts of interesting
things at compile time. This aspect of the language was unintentional I
think, but C++ programmers have been able to make good use of it. 

While I'm not generally fond of C++, this is actually one of those things
about the language I find very interesting. I'd like to see these ideas
explored in a future language that shed some of C++'s other baggage. 

Oh yeah, Mercury has a user defined iteration limit for resolving
instances of polymorphic recursion, since they opted to try to infer the 
types of polymorphically recursive functions and that problem is
undecidable. 

-- Brian

Re: Compile time executed functions

[Mats Karlssohn]

Robert A Duff wrote:
> 
> Ted Dennison<dennison@telepath.com> writes:
> 
> > After thinking about this some more, I'll go so far as to say that I don't think
> > there are *any* languages that supply this capability.
> 
> That's not correct.  The Bliss language has a macro facility that can
> use the full power of the language at compile time.  Lisp macros also
> allow the full power of Lisp at compile time.

Ahh, yet another reason to investigate Bliss (I've intended to
do so for a while for historical reasons). In Lisp I fell that most
of the time it's quite hard to se the difference between the
interpreter and the compiler, but let's not start on that...

[Cut away some points about the nonterminating functions
 that we already processed in other posts]

> Come to think of it, can't you write infinite loops using the C macro
> preprocessor?  Eg, a file that #include's itself?  Or a macro that
> expands to something containing a call to itself?

Yes, most C preprocessors limits the depth of the include stack
to smething reasonabel like 16. Btw. recursive #include is the only
way to do loops in the C preprocessor.


-- 
Mats Karlssohn, developer                         mailto:mats@mida.se  
Mida Systemutveckling AB                          http://www.mida.se
Box 64, S-732 22 ARBOGA, SWEDEN
Phone: +46-(0)589-89808   Fax: +46-(0)589-89809

Re: Compile time executed functions

[Mats Karlssohn]

Ted Dennison wrote:
%<
> Let us assume there is a compiler X that allows any aribitrary routine to be
> supplied which it will run during the compile phase, find the result, and store
> that result value in a constant. There are two possible approaches that X can
> take to support this capability.
> 
> Approach 1 is that compiler X makes no attempt to verify that the supplied
> routine is valid. In this case, it would be possible for the user to supply a
> non-halting routine to the compiler (eg: an estimating integration routine that
> has a bug where it never converges). Thus a compiler that takes approach 1 can
> under some circumstances go into an infinte loop during compilation due to a bug
> in user code, and it must be the user's responsiblily to prevent this, and to
> detect the condition when it occurs (vs. a routine that just takes a long time)
> and kill the compiler somehow. This must be accepted as normal operation of
> compiler X(1).

Yes, of course, but to me that's not a big deal. Further more it can be
handled by for example limiting the execution time of the supplied
function (better probably to limit its ability to loop though).

> Approach 2 is that compiler X does not accept non-halting routines. However,
> this means compiler X(2) is magic, since the halting problem has been proven to
> be unsolvable in the general case. Whatever you do, don't tick off the developer
> of X(2)! :-)

Yes, I know. At least some of the logic courses I've taken is
still accessable :)

> I'd claim that most developers will not accept the responsibility of an X(1)
> compiler, and X(2) is impossible. The only possible way out is to somehow put
> restrictions on the routines that may be supplied to the compiler so that all
> possilbe non-halting routines are disallowed. That pretty much means nothing
> with a loop (except possibly a for loop) or a goto, or another subroutine call
> (recursion is another type of loop, but this may be softened by building and
> checking some kind of call tree at compile time instead). These restrictions
> would allow some simple subroutines, but nothing complicated like a
> pointer-based list search or an estimating integrator, which is the kind of
> stuff the original poster wanted to use.

As another poster noted and I state above, the non halting function
problem
may not be that severe, during development you just hit Control-C and
investigate. In prduction batch build the compiler should be on a time
limit
anyway.


I still feel that the benefits of haveing macro-like like capabilities
that can use more or less the full power of Ada would be wery useful.

-- 
Mats Karlssohn, developer                         mailto:mats@mida.se  
Mida Systemutveckling AB                          http://www.mida.se
Box 64, S-732 22 ARBOGA, SWEDEN
Phone: +46-(0)589-89808   Fax: +46-(0)589-89809

Re: Compile time executed functions

[Ted Dennison]

In article <3AC2EE4D.56D61A58@mida.se>, Mats Karlssohn says...
>
>function (better probably to limit its ability to loop though).

Of the 3 approaches I mentioned, I think this one (allowing it, but limiting it
so that infinte loops cannot be written) would probably be the most promising.
It would be a fair bit of work though. It'd be interesting to see some graduate
student do a thesis or disseration on this subject. It should be fairly possible
to build someting of this sort off of Gnat.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: Compile time executed functions

[Mark Biggar]

Ted Dennison wrote:
> 
> In article <3AC2EE4D.56D61A58@mida.se>, Mats Karlssohn says...
> >
> >function (better probably to limit its ability to loop though).
> 
> Of the 3 approaches I mentioned, I think this one (allowing it, but limiting it
> so that infinte loops cannot be written) would probably be the most promising.
> It would be a fair bit of work though. It'd be interesting to see some graduate
> student do a thesis or disseration on this subject. It should be fairly possible
> to build someting of this sort off of Gnat.

It's been done many times.  For example go read "Godel, Esher and
Bach" by Hofsteder, the section on the *LOOP languages.  Obviously you
must outlaw abritrary "goto" statements, recursive procedures and
while loops, but if (case) statements and Ada like "for" loops are fine.
The trick it that you can only have looping construsts that allow
the computation of a strict bound on the number of iterations, 
before the loop is entered.

--
Mark Biggar
mark.biggar@trustedsyslabs.cpm

Re: Compile time executed functions

[Florian Weimer]

Mark Biggar <mark.a.biggar@home.com> writes:

> It's been done many times.  For example go read "Godel, Esher and
> Bach" by Hofsteder,

I think the third name is spelled 'Batch', to make the list more
consistent. ;-)

Re: Compile time executed functions

[Florian Weimer]

Mark Biggar <mark.a.biggar@home.com> writes:

> It's been done many times.  For example go read "Godel, Esher and
> Bach" by Hofsteder,

I think the third name is spelled 'Batch', at least the list is more
consistent then. ;-)

Re: Compile time executed functions

[Ken Garlington]

"Florian Weimer" <fw@deneb.enyo.de> wrote in message
news:87hf0cs7ci.fsf@deneb.enyo.de...
: Mark Biggar <mark.a.biggar@home.com> writes:
:
: > It's been done many times.  For example go read "Godel, Esher and
: > Bach" by Hofsteder,
:
: I think the third name is spelled 'Batch', at least the list is more
: consistent then. ;-)

Well, I have to ask - what's the joke here?

(For the sake of completeness, I think it's "Godel, Esher, Bach: The Eternal
Golden Braid", which uses the letters BEG to good effect ;)

Re: Compile time executed functions

[Brian Rogoff]

On Fri, 30 Mar 2001, Ken Garlington wrote:

> 
> "Florian Weimer" <fw@deneb.enyo.de> wrote in message
> news:87hf0cs7ci.fsf@deneb.enyo.de...
> : Mark Biggar <mark.a.biggar@home.com> writes:
> :
> : > It's been done many times.  For example go read "Godel, Esher and
> : > Bach" by Hofsteder,
> :
> : I think the third name is spelled 'Batch', at least the list is more
> : consistent then. ;-)
> 
> Well, I have to ask - what's the joke here?

Check the spelling. The only name that Mark spelled correctly was
Bach's. Of course, if Mark is using an ASCII only editor then I think
it's a bit unfair to criticize Godel since we don't have an umlaut; I've 
seen it spelled "Goedel" in umlaut free texts. And the Nederlands
challenged American might also spell it "Esher" since that's how we
pronounce that name, I'll have to check but if Escher is pronounced the
way it's spelled (I thought most Dutch words were) then the "ch" is like
the ch in Bach. 

-- Brian

Re: Compile time executed functions [OT]

[Karel Thönissen]

Brian Rogoff schreef:

> it's a bit unfair to criticize Godel since we don't have an umlaut; I've
> seen it spelled "Goedel" in umlaut free texts. And the Nederlands

Using the e for the umlaut is correct. Originally, the umlaut was a
small e on its side.
Said the Dutchman with an umlaut in his name (-8

> challenged American might also spell it "Esher" since that's how we
> pronounce that name, I'll have to check but if Escher is pronounced the
> way it's spelled (I thought most Dutch words were) then the "ch" is like
> the ch in Bach.

In Dutch, the name Escher is pronounced as /esher/. The correspondence
of spelling and pronounciation is a lot better than in English, but not
quite as good as in Italian, French or German. However, in this case we
deal with a name that was originally German, therefore /esher/.

You are right on how the /sch/ is pronounced in general. This sound is
so difficult for foreigners that it can be used as a password in times
of war. Say Scheveningen.

What is it that many English speaking people have with the spelling
and/or pronounciation of the names of Dutch artists? Why is the name of
Piet Mondriaan always spelled incorrectly? Or Vincent van Gogh's name
which is unrecognisably pronounced and alphabetized under /v/ instead of
/g/ ?

-- 

Groeten, Karel Th�nissen

Hello Technologies develops high-integrity software for complex systems

Scheveningen (Re: Compile time executed functions [OT])

[Ray Blaak]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 647 bytes --]

Karel Th�nissen <thoenissen@hello.nl> writes:
> You are right on how the /sch/ is pronounced in general. This sound is
> so difficult for foreigners that it can be used as a password in times
> of war. Say Scheveningen.

"Scheveningen".

The last time I went to Holland I drove my cousins up the wall practicing this
one so much. But I finally got it.

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
blaak@infomatch.com                            The Rhythm has my soul.

More {OT] (Was Re: Compile time executed functions [OT])

[Brian Rogoff]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=X-UNKNOWN, Size: 2727 bytes --]

On Fri, 30 Mar 2001, Karel [iso-8859-1] Thönissen wrote:
> Brian Rogoff schreef:
> 
> > it's a bit unfair to criticize Godel since we don't have an umlaut; I've
> > seen it spelled "Goedel" in umlaut free texts. And the Nederlands
> 
> Using the e for the umlaut is correct. Originally, the umlaut was a
> small e on its side.
> Said the Dutchman with an umlaut in his name (-8

So, my only questions would be about the "th" (I assume it's a regular t 
sound) and whether the "en" is a schwa, since lot's of Dutch speakers 
do that with a trailing en.  

> > challenged American might also spell it "Esher" since that's how we
> > pronounce that name, I'll have to check but if Escher is pronounced the
> > way it's spelled (I thought most Dutch words were) then the "ch" is like
> > the ch in Bach.
> 
> In Dutch, the name Escher is pronounced as /esher/. The correspondence
> of spelling and pronounciation is a lot better than in English, but not
> quite as good as in Italian, French or German. However, in this case we
> deal with a name that was originally German, therefore /esher/.
> 
> You are right on how the /sch/ is pronounced in general. This sound is
> so difficult for foreigners that it can be used as a password in times
> of war. Say Scheveningen.

When I visited I passed that test :-). The Hebraically challenged Dutchman 
can also note that a word which is so difficult for foreigners to pronounce 
that it is used as a password in times of war is a shibboleth, and is also 
a perfectly good English word. Now if Dutchmen had written the Bible after 
WWII the word would be scheveningen but then we'd pronounce it sheveningen 
and lose the whole point ;-).

> What is it that many English speaking people have with the spelling
> and/or pronounciation of the names of Dutch artists? 

Because we're ignorant, and many Dutch people are unfortunately ashamed of
their native language (unlike Flemish Belgians :) so they don't usually 
make an effort to educate foreigners. I really enjoy trying to learn at 
least a little of the language when I visit other countries, but it's hard 
in the Netherlands since practically everyone speaks English well.  

> Why is the name of Piet Mondriaan always spelled incorrectly?

You have to admit that the standard dictionary spelling in the Netherlands
changes quite frequently. If only the Ada standard would be updated as much!

> Or Vincent van Gogh's name > which is unrecognisably pronounced and
> alphabetized under /v/ instead of /g/ ?

We do that with all such names van, von, de, di, del...

"I'm an American honey, our names don't mean shit." 
Butch (character in 'Pulp Fiction')

-- Brian

Re: More {OT] (Was Re: Compile time executed functions [OT])

[Karel Thönissen]

Brian Rogoff schreef:

> > Said the Dutchman with an umlaut in his name (-8
>
> So, my only questions would be about the "th" (I assume it's a regular t
> sound) and whether the "en" is a schwa, since lot's of Dutch speakers
> do that with a trailing en.

Correct on both accounts.
 
> >Say Scheveningen.

I noticed that Ray Blaak had a beautiful pronounciation in his posting
(-8

> When I visited I passed that test :-). The Hebraically challenged Dutchman
> can also note that a word which is so difficult for foreigners to pronounce
> that it is used as a password in times of war is a shibboleth, and is also
> a perfectly good English word. Now if Dutchmen had written the Bible after
> WWII the word would be scheveningen but then we'd pronounce it sheveningen
> and lose the whole point ;-).

Thanx for pointing this out.
 
> > What is it that many English speaking people have with the spelling
> > and/or pronounciation of the names of Dutch artists?
> 
> Because we're ignorant, and many Dutch people are unfortunately ashamed of
> their native language (unlike Flemish Belgians :) so they don't usually
> make an effort to educate foreigners. I really enjoy trying to learn at
> least a little of the language when I visit other countries, but it's hard
> in the Netherlands since practically everyone speaks English well.

I am afraid there is a lot of merit in this paragraph )-8
 
> > Why is the name of Piet Mondriaan always spelled incorrectly?
> 
> You have to admit that the standard dictionary spelling in the Netherlands
> changes quite frequently.

That is true, but not for names.

> If only the Ada standard would be updated as much!

No, no, please not. That would turn Ada into another C or C++  (-8

-- 

Groeten, Karel Th�nissen

Hello Technologies develops high-integrity software for complex systems

Re: Compile time executed functions

[Brian Hanson]

So who is this Esher guy perhaps its
Godel, Escher, Bach: The Eternal Golden Braid.

Brian Hanson
brian.hanson@nospam.usfamily.net

"Ken Garlington" <Ken.Garlington@computer.org> wrote in message
news:YfTw6.461$3V5.99097668@newssvr16.news.prodigy.com...
>
> "Florian Weimer" <fw@deneb.enyo.de> wrote in message
> news:87hf0cs7ci.fsf@deneb.enyo.de...
> : Mark Biggar <mark.a.biggar@home.com> writes:
> :
> : > It's been done many times.  For example go read "Godel, Esher and
> : > Bach" by Hofsteder,
> :
> : I think the third name is spelled 'Batch', at least the list is more
> : consistent then. ;-)
>
> Well, I have to ask - what's the joke here?
>
> (For the sake of completeness, I think it's "Godel, Esher, Bach: The
Eternal
> Golden Braid", which uses the letters BEG to good effect ;)
>
>

Re: Compile time executed functions

[Robert A Duff]

Mark Biggar <mark.a.biggar@home.com> writes:

> It's been done many times.  For example go read "Godel, Esher and
> Bach" by Hofsteder, the section on the *LOOP languages.  Obviously you
> must outlaw abritrary "goto" statements, recursive procedures and
> while loops, but if (case) statements and Ada like "for" loops are fine.
> The trick it that you can only have looping construsts that allow
> the computation of a strict bound on the number of iterations, 
> before the loop is entered.

But if you give me a language like that, and what I really want is a
while loop, I'll end up writing something like:

    for I in 1..10**100 loop -- or maybe just 2**31-1 ;-)
        exit when ...;
        ...
    end loop;

It's easy to prove that the above loop is not infinite, but if I make a
mistake in the exit condition, I'll end up with a very long loop, which
is just as bad in practise.

So I think it's better just to allow while loops, and live with the fact
that they might be infinite.  Unless you have a fancy proof engine that
can prove termination of while loops most of the time.

- Bob

Re: Compile time executed functions

[Ted Dennison]

In article <wcck85886j6.fsf@world.std.com>, Robert A Duff says...
>
>But if you give me a language like that, and what I really want is a
>while loop, I'll end up writing something like:
>
>    for I in 1..10**100 loop -- or maybe just 2**31-1 ;-)
>        exit when ...;
>        ...
>    end loop;
>
>It's easy to prove that the above loop is not infinite, but if I make a
>mistake in the exit condition, I'll end up with a very long loop, which
>is just as bad in practise.

True. I'd think most developers would rather make some attempt to put a
reasonable limit on the for loop (eg: the maximum possible nodes in a list, or
something), rather than an arbitrary one. But I often deal code that "most
developers" would be loathe to write, so I know you have to deal with that case.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: Compile time executed functions

[Robert A Duff]

Ted Dennison<dennison@telepath.com> writes:

> True. I'd think most developers would rather make some attempt to put
> a reasonable limit on the for loop (eg: the maximum possible nodes in
> a list, or something), rather than an arbitrary one. 

But the max length of a list is something like "the size of the address
space".  Anything less is a bug.

- Bob

Re: Compile time executed functions

[Ted Dennison]

In article <wccy9tnkm9j.fsf@world.std.com>, Robert A Duff says...
>
>Ted Dennison<dennison@telepath.com> writes:
>
>> True. I'd think most developers would rather make some attempt to put
>> a reasonable limit on the for loop (eg: the maximum possible nodes in
>> a list, or something), rather than an arbitrary one. 
>
>But the max length of a list is something like "the size of the address
>space".  Anything less is a bug.

Not nessecarily. It depends on the data being listed. For instance, if the list
is a list of players on a soccer team, 30 would probably be more than enough (at
least for the teams with which I'm acquainted, pro teams may need a bit more,
but certianly no more than 100 or so). 

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: Compile time executed functions

[Ray Blaak]

Robert A Duff <bobduff@world.std.com> writes:
> So I think it's better just to allow while loops, and live with the fact
> that they might be infinite.  Unless you have a fancy proof engine that
> can prove termination of while loops most of the time.

"While" loops are also more correct in describing intentional unbounded
execution: the exit condition depends on the exit condition, and nothing else.

It is another problem to show that the exit condition will eventually occur.

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
blaak@infomatch.com                            The Rhythm has my soul.

Re: Compile time executed functions

[Florian Weimer]

Ted Dennison<dennison@telepath.com> writes:

> >Yes, but this way, values can be computed prior to run time which
> >appear to be constants (even during compile time) but are in fact not.
> 
> Ahhh. But that's not what he was talking about. He wants to be able
> to supply some arbitrary function (like say an integrator or a
> matrix math routine or a search routine) which the compiler will
> then run during the compile phase, find the value of the result (eg:
> 3.57) and then place that value in a constant which he can have the
> compiler stick in the ROM section of the generated code. In order to
> stick a value in the ROM section, it clearly cannot be computed at
> runtime.

Why not?  You can do this certainly with FORTH: you run the system in
'compile mode', and just before starting the actual execution, you
dump the entire environment.  From the dump, a ROM image can be built;
and there's no need to copy constants from ROM to RAM during
initialization.  (I think this works with some Lisp dialects as well,
Emacs is probably an example.)

> I'd claim that most developers will not accept the responsibility of
> an X(1) compiler,

Why not?  There are already some programming languages where you have
to some discipline not to write constructs which exhaust compile-time
ressources (C++ comes to my mind, and the problem with C++ is nottime
spent compiling, but the amount of core memory used).

Re: Compile time executed functions

[Mats Karlssohn]

Ted Dennison wrote:
%<
> >I have hoped to get the time to either build a small preprocessor to do
> >this kind of execution/substitution trick, or to add the same trick into
> >GNAT using some pragma(Compiler_Executed, func). Sorry to say, I don't
> >see that ammount of time in the near future.
> 
> If you are talking about being able to run pretty much *any* code at compile
> time, no that can't be done with just a "trick". I don't know of any language in
> existance (but I suppose there probably is one somewhere) that will let you do
> that. It might be doable for a self-hosted system, but for a cross-compiled
> system (which I suspect is your situation, otherwise you wouldn't be worrying
> about making the result ROMable) I don't think it would be possible at all. The
> cross compiler would also have to include a full-fledged native compiler!

This IS what I'm dreaming of. Of course a lot of restrictions on what
code is allowed to execute (sideeffects etc). Ofcourse you'll need a
native compiler to compile the initialization function (and all code
that it uses).

The analysis of the code, regarding weather it can be allowed is
probably so complex that it's best done from within the compiler,
and not in some kind of preprocessor.
I still hope to get some time to experiment with gnat (after all I
have to have the native compiler to build the crosscompiler anyway).

-- 
Mats Karlssohn, developer                         mailto:mats@mida.se  
Mida Systemutveckling AB                          http://www.mida.se
Box 64, S-732 22 ARBOGA, SWEDEN
Phone: +46-(0)589-89808   Fax: +46-(0)589-89809

Re: Compile time executed functions

[Jon S Anthony]

Ted Dennison wrote:

> In article <3AC03CCE.70E3C2D5@mida.se>, Mats Karlssohn says...
> >That is I'd like to have the compiler to execute a function for me (at
> >compiletime!) and use the return of that function to initialize the
> >constant.

This sort of thing can be extremely useful - even if all you are doing
is computing a "usual" value like you suggest (far more interesting
stuff can be done as noted below...)


> >I have hoped to get the time to either build a small preprocessor to do

If you are in some sort of "tight" ("small" memory, i.e., < 8 meg or so)
real time situation, you are going to have to resort to tricks/hacks
like the one you use.  If not, you should consider looking into Common
Lisp for which this is a trivial example of a much broader capability
- full compile time use of the language to compute anything, in
particular code.


> If you are talking about being able to run pretty much *any* code at
> compile time, no that can't be done with just a "trick". I don't
> know of any language in existance (but I suppose there probably is
> one somewhere) that will let you do that.

Common Lisp is probably the best example, i.e., not a research toy or
hack, but a highly optimized, fully capable and industrial strength
language for serious applications.  Compilation is typically extremely
fast and resulting code typically in the 1.2 of C range.


> It might be doable for a self-hosted system, but for a
> cross-compiled system (which I suspect is your situation, otherwise
> you wouldn't be worrying about making the result ROMable) I don't
> think it would be possible at all. The cross compiler would also
> have to include a full-fledged native compiler!

Actually no.  All you would need would be a compiler for the target
and an emulator or interpreter for the host.


/Jon

-- 
Jon Anthony
Synquiry Technologies, Ltd. Belmont, MA 02478, 617.484.3383
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: Compile time executed functions

[Robert A Duff]

Mats Karlssohn <mats@mida.se> writes:

> Sometimes, especially when doing embedded programming, I feel a great
> need to execute a function to get literal initialization a constant.
> That is I'd like to have the compiler to execute a function for me (at
> compiletime!) and use the return of that function to initialize the
> constant.

If you inline the function, you are likely to get what you want,
depending on how good the compiler's support for inlining is.

> I realize that a lot of limitations must be put on the
> Generate_CRC_Table function, but, have something along these lines been
> considered by the language designers.

I don't think it's really a language design issue.  The language doesn't
talk about how clever the compiler is about doing things at compile
time, nor about what goes in ROM vs RAM.

- Bob

Re: Compile time executed functions

[Ted Dennison]

In article <wcc1yrje0nr.fsf@world.std.com>, Robert A Duff says...
>
>Mats Karlssohn <mats@mida.se> writes:
>
>> Sometimes, especially when doing embedded programming, I feel a great
>> need to execute a function to get literal initialization a constant.
>> That is I'd like to have the compiler to execute a function for me (at
>> compiletime!) and use the return of that function to initialize the
>> constant.
>
>If you inline the function, you are likely to get what you want,
>depending on how good the compiler's support for inlining is.

He also wanted the result of the function to be put into the ROM area when the
executable is created by the compiler. Inlining wouldn't do that, would it? It
just prevents the little extra subprogram call overhead (saving and restoring
the register context, etc) when the function is called at runtime.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: Compile time executed functions

[Robert A Duff]

Ted Dennison<dennison@telepath.com> writes:

> In article <wcc1yrje0nr.fsf@world.std.com>, Robert A Duff says...
> >
> >Mats Karlssohn <mats@mida.se> writes:
> >
> >> Sometimes, especially when doing embedded programming, I feel a great
> >> need to execute a function to get literal initialization a constant.
> >> That is I'd like to have the compiler to execute a function for me (at
> >> compiletime!) and use the return of that function to initialize the
> >> constant.
> >
> >If you inline the function, you are likely to get what you want,
> >depending on how good the compiler's support for inlining is.
> 
> He also wanted the result of the function to be put into the ROM area when the
> executable is created by the compiler. Inlining wouldn't do that,
> would it?

Why not?  If the value of the constant is known to the compiler, then it
can go in ROM (presuming the compiler and linker and whatnot support ROM
at all).

>... It
> just prevents the little extra subprogram call overhead (saving and restoring
> the register context, etc) when the function is called at runtime.

Inlining does that, but it also allows the compiler to optimize through
the inlined code.  Eg:

    function Factorial(X: Natural) return Positive is
        pragma Inline(Factorial);
    begin
        if X = 0 then
            return 1;
        else
            return Factorial(X-1) * X;
        end if;
    end Factorial;

    Y: constant Integer := Factorial(7);

I have seen compilers that will generate the same code for the above
that is generated for:

    Y: constant Integer := 5040;

My point is that inlining is not just for removing the call overhead.
It is also for letting the compiler reason about the code as if it
were written in line at the call site.

- Bob

Re: Compile time executed functions

[Ken Garlington]

"Ted Dennison" <dennison@telepath.com> wrote in message
news:132w6.3493$fy.5811@www.newsranger.com...
: In article <wcc1yrje0nr.fsf@world.std.com>, Robert A Duff says...
: >
: >Mats Karlssohn <mats@mida.se> writes:
: >
: >> Sometimes, especially when doing embedded programming, I feel a great
: >> need to execute a function to get literal initialization a constant.
: >> That is I'd like to have the compiler to execute a function for me (at
: >> compiletime!) and use the return of that function to initialize the
: >> constant.
: >
: >If you inline the function, you are likely to get what you want,
: >depending on how good the compiler's support for inlining is.
:
: He also wanted the result of the function to be put into the ROM area when
the
: executable is created by the compiler. Inlining wouldn't do that, would
it? It
: just prevents the little extra subprogram call overhead (saving and
restoring
: the register context, etc) when the function is called at runtime.

It might - my experience is that inlining is more likely to result in
evaluation to a ROMable constant with a good compiler. However, there's a
lot of other factors involved.

Re: Compile time executed functions

[Mark Lundquist]

Ted Dennison <dennison@telepath.com> wrote in message
news:132w6.3493$fy.5811@www.newsranger.com...
>
> He also wanted the result of the function to be put into the ROM area when
the
> executable is created by the compiler. Inlining wouldn't do that, would
it? It
> just prevents the little extra subprogram call overhead (saving and
restoring
> the register context, etc) when the function is called at runtime.

You're right that inlining *alone* doesn't acheive the desired effect.  But
inlining may allow optimizations to accomplish it.  It depends on the order
of inlining relative to the various optimizations that the compiler
performs.

Mark Lundquist
Rational Software

Re: Compile time executed functions

[Mats Karlssohn]

Robert A Duff wrote:
> 
> Mats Karlssohn <mats@mida.se> writes:
> 
> > Sometimes, especially when doing embedded programming, I feel a great
> > need to execute a function to get literal initialization a constant.
> > That is I'd like to have the compiler to execute a function for me (at
> > compiletime!) and use the return of that function to initialize the
> > constant.
> 
> If you inline the function, you are likely to get what you want,
> depending on how good the compiler's support for inlining is.

OK, for the project at hand I don't have a choise for the compiler,
but I'll put inlining support on my compiler checklist for future
projects.

> > I realize that a lot of limitations must be put on the
> > Generate_CRC_Table function, but, have something along these lines been
> > considered by the language designers.
> 
> I don't think it's really a language design issue.  The language doesn't
> talk about how clever the compiler is about doing things at compile
> time, nor about what goes in ROM vs RAM.

I agree on the location issue (RAM vs. ROM), but the control over how
and when the code is executed is already a language issue I think.
We already have generics in the language wich controls how code should
be generated. We also have pragma Inline and representation pragmas
that controls the layout of code and data. So why couldn't we also
have pragma(s) to _hint_ to the compiler that this piece of code is
only used for initializing constants and is therefore NOT needed in
the runtime image if the compiler executes it. And, yes, I realize
that the analysis of the code may be to expensive and/or the
tradeoffs that have to be made may cause all this to be unusable.

-- 
Mats Karlssohn, developer                         mailto:mats@mida.se  
Mida Systemutveckling AB                          http://www.mida.se
Box 64, S-732 22 ARBOGA, SWEDEN
Phone: +46-(0)589-89808   Fax: +46-(0)589-89809

Re: Compile time executed functions

[Robert A Duff]

Mats Karlssohn <mats@mida.se> writes:

> I agree on the location issue (RAM vs. ROM), but the control over how
> and when the code is executed is already a language issue I think.
> We already have generics in the language wich controls how code should
> be generated. 

I don't think so.  Some compilers generate a separate piece of code for
each instance, some compilers generate a single shared piece of code for
all instances (which requires passing in all kinds of stuff at run time,
which in the first technique would be compile-time known), and some
compilers do some combination of the two.  In any case, the RM has
nothing to say about it.

>...We also have pragma Inline and representation pragmas
> that controls the layout of code and data.

Pragma Inline doesn't *require* anything (it's just a hint).
Representation pragmas and clauses specify data layout, but not code
layout.

>... So why couldn't we also
> have pragma(s) to _hint_ to the compiler that this piece of code is
> only used for initializing constants and is therefore NOT needed in
> the runtime image if the compiler executes it.

Oh, hint?  Like pragma Inline?  Well, maybe.  But why shouldn't the
compiler just do the optimization?  I mean, if I write "2 + 2", I want
the compiler to generate "4" in the machine code.  Likewise, if I have a
function call, and the function returns "2 + 2", and the function is
inlined, I want the compiler to do the same.  I don't think any hint is
needed here.  And anyway, the compiler can always ignore hints.

A hint pragma like pragma Inline makes sense, because inlining is not
always a good idea, so the programmer can tell the compiler when
inlining is worthwhile.  But pragma Inline doesn't make inlining any
easier for the compiler to do, and most compilers have various
restrictions on which pragmas Inline they actually obey.

Some compilers are capable of guessing when inlining is a good idea,
even *without* pragma Inline.  If the guesses are good, then that's
better than using the pragma.

>... And, yes, I realize
> that the analysis of the code may be to expensive and/or the
> tradeoffs that have to be made may cause all this to be unusable.

Compilers already do some of what you want (if you inline).  And adding
hint pragmas won't make them do better.  An open checkbook, on the other
hand, might cause a compiler writer to do certain table lookups (or
whatever it is you wanted) at compile time.  ;-)

So I still say it's an implementation issue, not a language issue.
On the other hand, I suppose it's a language issue in the sense that
some languages make this sort of optimization easier.  But no language
definition can *require* these kinds of optimizations in its Reference
Manual.

- Bob

Re: Compile time executed functions

[Mats Karlssohn]

Robert A Duff wrote:
> 
> Mats Karlssohn <mats@mida.se> writes:
> 
> > I agree on the location issue (RAM vs. ROM), but the control over how
> > and when the code is executed is already a language issue I think.
> > We already have generics in the language wich controls how code should
> > be generated.
> 
> I don't think so.  Some compilers generate a separate piece of code for
%<

OK, understood, let's not waste time on that issue.

> >...We also have pragma Inline and representation pragmas
> > that controls the layout of code and data.
> 
> Pragma Inline doesn't *require* anything (it's just a hint).
> Representation pragmas and clauses specify data layout, but not code
> layout.

Maybe you could see my proposed pragma as a representation pragma
for code then ?
 
> >... So why couldn't we also
> > have pragma(s) to _hint_ to the compiler that this piece of code is
> > only used for initializing constants and is therefore NOT needed in
> > the runtime image if the compiler executes it.
> 
> Oh, hint?  Like pragma Inline?  Well, maybe.  But why shouldn't the
> compiler just do the optimization?  I mean, if I write "2 + 2", I want
> the compiler to generate "4" in the machine code.  Likewise, if I have a
> function call, and the function returns "2 + 2", and the function is
> inlined, I want the compiler to do the same.  I don't think any hint is
> needed here.  And anyway, the compiler can always ignore hints.

This leads me to another thing that I've sometimes have found annoy�ng:
Why isn't it required by the language that there should be a n option
to force the compiler to tell you wich pragma;s it cant obey ?
I just hate auditing machine code just to check that the compiler
hasn't generated silly code. Although I must admit that this stuff has
only occured a few times during the past 7 years.
 
%<
> Some compilers are capable of guessing when inlining is a good idea,
> even *without* pragma Inline.  If the guesses are good, then that's
> better than using the pragma.

Hmmm, actually, no. I want to be able to control what goes where
and how, in wich form it goes there. But I want to know the
compilers opinion on my chioses to. Perhaps I should state it like:
When I have said someting to the compiler, like a representation
pragma or pragma Inline, the compiler shall damn well do as I tell
it, it may Warn or cause an error, but when it produces output it
shall be of the form I've asked. As for stuff I havn't said enything
about it should just do what it can.

%<
> Compilers already do some of what you want (if you inline).  And adding
> hint pragmas won't make them do better.  An open checkbook, on the other
> hand, might cause a compiler writer to do certain table lookups (or
> whatever it is you wanted) at compile time.  ;-)

Obviously my experience with different compilers is not great
enough, I havn't come across one. Would you care to name one ?


-- 
Mats Karlssohn, developer                         mailto:mats@mida.se  
Mida Systemutveckling AB                          http://www.mida.se
Box 64, S-732 22 ARBOGA, SWEDEN
Phone: +46-(0)589-89808   Fax: +46-(0)589-89809

Re: Compile time executed functions

[Robert A Duff]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1861 bytes --]

Mats Karlssohn <mats@mida.se> writes:

> Maybe you could see my proposed pragma as a representation pragma
> for code then ?

OK, but only as a hint.  Rep pragmas or clauses for data can be tested,
because you can Unchecked_Convert the data, and see if it's represented
the way you asked.  But how do you test a rep pragma for code?  For
example, how can you write an Ada program that behaves differently
depending on whether pragma Inline was obeyed?  No fair looking at the
generated code.

> This leads me to another thing that I've sometimes have found annoy�ng:
> Why isn't it required by the language that there should be a n option
> to force the compiler to tell you wich pragma;s it cant obey ?
> I just hate auditing machine code just to check that the compiler
> hasn't generated silly code. Although I must admit that this stuff has
> only occured a few times during the past 7 years.

But how would you know if *that* option were obeyed?  Suppose the
compiler says "yes, I inlined your function", how do you know if it's
lying?  You still have to inspect the generated code.

In practise, though, compilers do give this kind of information.
Eg, the documentation will normally tell you "we obey pragma Inline in
the following circumstances...".

> > Compilers already do some of what you want (if you inline).  And adding
> > hint pragmas won't make them do better.  An open checkbook, on the other
> > hand, might cause a compiler writer to do certain table lookups (or
> > whatever it is you wanted) at compile time.  ;-)
> 
> Obviously my experience with different compilers is not great
> enough, I havn't come across one. Would you care to name one ?

I think *all* Ada compilers can evaluate *some* things at compile time
besides static expressions.  I'll grant you that the particular table
lookups you have in mind might not be.

- Bob

Re: Compile time executed functions

[Mats Karlssohn]

Robert A Duff wrote:
> 
> Mats Karlssohn <mats@mida.se> writes:
> 
> > Maybe you could see my proposed pragma as a representation pragma
> > for code then ?
> 
> OK, but only as a hint.  Rep pragmas or clauses for data can be tested,
> because you can Unchecked_Convert the data, and see if it's represented
> the way you asked.  But how do you test a rep pragma for code?  For
> example, how can you write an Ada program that behaves differently
> depending on whether pragma Inline was obeyed?  No fair looking at the
> generated code.

How to check it... there should't be more than initialize data left
at the place the function was called and since the function is not
(at least in my case) called from anywhee else the body shoule _not_
be included in the output. When writing the previous sentence I
really felt thah my english isn't what it needs to be to discuss
really complicated matters, so maybe I didn't understand your point ? 

As for the test for inlined code... hmmm, I guess it'd be kind of
hard.

> > This leads me to another thing that I've sometimes have found annoy�ng:
> > Why isn't it required by the language that there should be a n option
> > to force the compiler to tell you wich pragma;s it cant obey ?
> > I just hate auditing machine code just to check that the compiler
> > hasn't generated silly code. Although I must admit that this stuff has
> > only occured a few times during the past 7 years.
> 
> But how would you know if *that* option were obeyed?  Suppose the
> compiler says "yes, I inlined your function", how do you know if it's
> lying?  You still have to inspect the generated code.

Well, until proven otherwise I trust the compiler vendor (a trust
that have proven false quite often), so if such an option was
availible I'd trust it (on my own projects, clients may have other
ideas) until I suspect that it lies, then som investigation is
needed.

> In practise, though, compilers do give this kind of information.
> Eg, the documentation will normally tell you "we obey pragma Inline in
> the following circumstances...".

Yes, aside from it beeing inconvenient to have to look for such
things in the documentation, I have found that the documentation
is often buried in some archive somwhere or just missing :(


-- 
Mats Karlssohn, developer                         mailto:mats@mida.se  
Mida Systemutveckling AB                          http://www.mida.se
Box 64, S-732 22 ARBOGA, SWEDEN
Phone: +46-(0)589-89808   Fax: +46-(0)589-89809

Re: Compile time executed functions

[Robert A Duff]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3038 bytes --]

Mats Karlssohn <mats@mida.se> writes:

> Robert A Duff wrote:
> > 
> > Mats Karlssohn <mats@mida.se> writes:
> > 
> > > Maybe you could see my proposed pragma as a representation pragma
> > > for code then ?
> > 
> > OK, but only as a hint.  Rep pragmas or clauses for data can be tested,
> > because you can Unchecked_Convert the data, and see if it's represented
> > the way you asked.  But how do you test a rep pragma for code?  For
> > example, how can you write an Ada program that behaves differently
> > depending on whether pragma Inline was obeyed?  No fair looking at the
> > generated code.
> 
> How to check it... there should't be more than initialize data left
> at the place the function was called and since the function is not
> (at least in my case) called from anywhee else the body shoule _not_
> be included in the output. When writing the previous sentence I
> really felt thah my english isn't what it needs to be to discuss
> really complicated matters, so maybe I didn't understand your point ? 

You seem to be saying "look at the generated code" to see if the
compiler obeyed your pragma.  But that's not meaningful in a formal
language-definition sense.

> As for the test for inlined code... hmmm, I guess it'd be kind of
> hard.

Right, and the same is true for any other pragma that (pretends to)
require something about the generated code.

> > > This leads me to another thing that I've sometimes have found annoy�ng:
> > > Why isn't it required by the language that there should be a n option
> > > to force the compiler to tell you wich pragma;s it cant obey ?
> > > I just hate auditing machine code just to check that the compiler
> > > hasn't generated silly code. Although I must admit that this stuff has
> > > only occured a few times during the past 7 years.
> > 
> > But how would you know if *that* option were obeyed?  Suppose the
> > compiler says "yes, I inlined your function", how do you know if it's
> > lying?  You still have to inspect the generated code.
> 
> Well, until proven otherwise I trust the compiler vendor (a trust
> that have proven false quite often), so if such an option was
> availible I'd trust it (on my own projects, clients may have other
> ideas) until I suspect that it lies, then som investigation is
> needed.

It would be useful to have a compiler option that warns you whenever you
asked for inlining (or other code-generation-specific pragmas) and it
didn't obey.  I'm just saying it's not really appropriate as a
requirement in the RM, because as a requirement, it's meaningless -- it
can't be formally tested.  So ask your compiler vendor for such a
feature.

> > In practise, though, compilers do give this kind of information.
> > Eg, the documentation will normally tell you "we obey pragma Inline in
> > the following circumstances...".
> 
> Yes, aside from it beeing inconvenient to have to look for such
> things in the documentation, I have found that the documentation
> is often buried in some archive somwhere or just missing :(

:-(

- Bob

Re: Compile time executed functions

[Ken Garlington]

"Mats Karlssohn" <mats@mida.se> wrote in message
news:3AC192D0.B1E48088@mida.se...

: I agree on the location issue (RAM vs. ROM), but the control over how
: and when the code is executed is already a language issue I think.
: We already have generics in the language wich controls how code should
: be generated. We also have pragma Inline and representation pragmas
: that controls the layout of code and data. So why couldn't we also
: have pragma(s) to _hint_ to the compiler that this piece of code is
: only used for initializing constants and is therefore NOT needed in
: the runtime image if the compiler executes it. And, yes, I realize
: that the analysis of the code may be to expensive and/or the
: tradeoffs that have to be made may cause all this to be unusable.

Actually, my company paid for such a pragma in the Tartan (now DDC-I)
VAX/1750 cross-compiler. See the documentation for a description of pragma
ROMable. (This turns out to be a nightmare to specify precisely, as you
might expect, and I don't see an obvious path to making this a
widely-adopted capability.)

Re: Compile time executed functions

[Mats Karlssohn]

Mats Karlssohn wrote:
%<
> - The constant is really a constant an should therefore be placed in
> ROM.

I'm really sure that I shouldn't have mentioned the RAM/ROM issue...

Surry guys and gals!

-- 
Mats Karlssohn, developer                         mailto:mats@mida.se  
Mida Systemutveckling AB                          http://www.mida.se
Box 64, S-732 22 ARBOGA, SWEDEN
Phone: +46-(0)589-89808   Fax: +46-(0)589-89809

Re: Compile time executed functions

[Georg Bauhaus]

Mats Karlssohn (mats@mida.se) wrote:

: That is I'd like to have the compiler to execute a function for me (at
: compiletime!) and use the return of that function to initialize the
: constant.

If I'v understood this correctly, then a hint given
by Tucker Taft some time ago was, that this could be
done using ASIS. (Would need _some_ work I guess... :-)