From Newsgroup: comp.lang.ada

On 2024-09-12 12:04, J-P. Rosen wrote:

[...]

Well, tasks are not only for speeding up code. They can be a very useful design tool (active objects, independant activities). I think the Ada
model is clean and simple, I would hate to see it disappear.

I agree.

I'm less certain about the value of priorities, [...]

Priorities are just optimization on how to manage cores when there are
not enough of them.

In some contexts it could be optimization -- for example, to increase throughput in a soft real-time system -- but in hard real-time systems priorities (or deadlines) are needed for correctness, not just for optimizatiion.

I know that people use priorities to guarantee mutual exclusion, and
other properties. All these algorithms were designed at the time of
mono-CPU machines, but they fail on multi-cores.

In SW for multi-core systems it can be beneficial to collect tasks that frequently interact with each other or with the same single-user
resources in the same core, and then the mono-core mutual-exclusion
algorithms like priority ceiling inheritance can be used for that group
of tasks, while using other algorithms for mutual exclusion between
tasks running in different cores.

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.ada

If Ada did not have tasks with priorities, most of the Ada applications
I have worked on in my life would have had to avoid Ada tasking and
retreat to using some other real-time kernel, with ad-hoc mapping of the >kernels's threads to Ada procedures.

Counter intuitively it is possible that this is holding Ada back. A lot of
Ada code cannot run without some fairly complex runtime support due to
tasks, protected objects, finalization etc.. Runtimes have to be developed
for each chip instead of each cpu. Atleast I assume that that is why these
features are not available to e.g. the light cortex-m33 or cortex-m4 or
cortex-m0+ runtimes. This requires rewriting code which isn't required with
equivalent C code such as containers and ip stacks etc.. Even support for
the Ada interrupt package is missing but it looks like porting that support
to chips is less work and research.

If you need advanced multi core support then using an OS seems like a more
suitable situation to be in to me.
--
Regards, Kc
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.ada

On 2024-09-12 15:36, Kevin Chadwick wrote:

If Ada did not have tasks with priorities, most of the Ada
applications I have worked on in my life would have had to avoid Ada
tasking and retreat to using some other real-time kernel, with ad-hoc
mapping of the kernels's threads to Ada procedures.

Counter intuitively it is possible that this is holding Ada back. A lot of Ada code cannot run without some fairly complex runtime support due to
tasks, protected objects, finalization etc.. Runtimes have to be developed for each chip instead of each cpu.

True, however an Ada RTS can implement many of the tasking features with moderate effort on top of non-Ada real-time kernels such as FreeRTOS,
VxWorks, etc., as AdaCore have done for some kernels. At least for the Ravenscar and Jorvik profiles. AIUI, the processor-specific stuff is
then mainly in the kernel, not in the RTS.

If you need advanced multi core support then using an OS seems like a more suitable situation to be in to me.

Using a large OS like Linux would not be acceptable for many embedded
systems. Fortunately the smaller real-time kernels are adding multi-core support too.

The great advantage of using the standard Ada tasking feature, special
syntax and all, is that your embedded Ada program can then be executed
on a PC or other non-embedded computer, for testing or other purposes,
tasking and all. It can also be analysed by static-analysis tools such
as AdaControl for race conditions and other tasking-sensitive issues.

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.ada

On Wed, 11 Sep 2024 23:39:27 -0500, Randy Brukardt wrote:

"Lawrence D'Oliveiro" <ldo@nz.invalid> wrote in message news:vbdk2t$hj0r$6@dont-email.me...

On Thu, 5 Sep 2024 19:03:22 -0500, Randy Brukardt wrote:

...

(10) Variable-returning functions are introduced.

Is this like updater functions in POP-11, or "setf" in Lisp?

No, it is a function that returns a variable, meaning you can assign
into the function result.

I think an updater function would be more generally useful. Because some things you want to update might not (depending on the implementation) live independently in an explicit variable. And it seems good not to constrain implementations unnecessarily.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.ada

On Thu, 12 Sep 2024, Kevin Chadwick wrote:
"Counter intuitively it is possible that this is holding Ada back. A lot of
Ada code cannot run without some fairly complex runtime support due to
tasks, protected objects, finalization etc.. Runtimes have to be developed
for each chip instead of each cpu."


A book by Burns and Wellings unsensibly boasts that the demanding runtime demands of Ada are an advantage because if you be with them then you be
with them, whereas as Kevin Chadwick points out - they are not easy to
make.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.ada


"Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message news:lkg1vvF1tp6U1@mid.individual.net...
...

Priorities are just optimization on how to manage cores when there are
not enough of them.

In some contexts it could be optimization -- for example, to increase throughput in a soft real-time system -- but in hard real-time systems priorities (or deadlines) are needed for correctness, not just for optimizatiion.

This I don't buy: priorities never help for correctness. At least not
without extensive static analysis, but if you can do that, you almost certainly can do the correctness without depending upon priorities.

I view priorities as similar to floating point accuracy: most people use
them and get the results they want, but the reason for that is that they got lucky, and not because of anything intrinsic. Unless you do a lot of
detailed analysis, you don't know if priorities really are helping or not
(and similarly, whether your results actually are meaningful in the case of floating point).

Anyway, I don't see any such changes coming to Ada, but rather to some separate follow-on language (which necessarily needs to be simpler), and
thus some things that are sometimes useful would get dropped.

(Different message)
...

Ok, I understand. In that case, what "parallel" adds to the current
tasking feature is an easy way to create a largish and perhaps dynamically defined number of concurrent threads from a "parallel" loop, where the threads are automatically created when the loop is started and
automatically "joined" and destroyed when the loop completes.

I think the parallel block is more useful for general tasking. The advantage of using parallel structures is that they look very similar to sequential structures, and one lets the system do the scheduling (rather than trying to figure out an organization manually).

One of the advantages of the model I'm thinking about is that it separates concerns such as parallel execution, mutual exclusion, inheritance, organization (privacy, type grouping), and so on into separate (mostly) non-overlapping constructs. Ada started this process by having tagged types
a separate construct from packages; you need both to get traditional OOP,
but you can also construct many structures that are quite hard in
traditional "one construct" OOP. I think that ought to be done for all constructs, and thus the special task and protected constructs ought to go.
We already know that protected types cause problems with privacy of implementation and with inheritance. Tasks have similar issues (admittedly less encountered), so splitting them into a set of constructs would fit the model.

In any case, this is still a thought experiment at this time, whether
anything ever comes of it is unknown.

Randy.




Randy.


--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.ada

"Lawrence D'Oliveiro" <ldo@nz.invalid> wrote in message news:vbvpmt$esm6$7@dont-email.me...

On Wed, 11 Sep 2024 23:39:27 -0500, Randy Brukardt wrote:

"Lawrence D'Oliveiro" <ldo@nz.invalid> wrote in message
news:vbdk2t$hj0r$6@dont-email.me...

On Thu, 5 Sep 2024 19:03:22 -0500, Randy Brukardt wrote:

...

(10) Variable-returning functions are introduced.

Is this like updater functions in POP-11, or "setf" in Lisp?

No, it is a function that returns a variable, meaning you can assign
into the function result.

I think an updater function would be more generally useful. Because some things you want to update might not (depending on the implementation) live independently in an explicit variable. And it seems good not to constrain implementations unnecessarily.

Unfortunately, "updater" functions don't work with the Ada model of components, because you can't tell what to do when a component appears or disappears in an assignment. (That's why Ada doesn't allow overloading
":=".) And composition is very important to Ada -- stand-alone objects are pretty rare outside of those for scalar types. I don't think something that only worked with stand-alone objects would be very useful (can't use those with ODTs, for instance)..

Randy.


--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.ada

On 2024-09-14 08:13, Randy Brukardt wrote:

I think the parallel block is more useful for general tasking. The advantage of using parallel structures is that they look very similar to sequential structures, and one lets the system do the scheduling (rather than trying to figure out an organization manually).

Tasking is not about scheduling. It is about program logic expressed in
a sequential form. It is about software decomposition. Parallel
constructs simply do not do that.

One of the advantages of the model I'm thinking about is that it separates concerns such as parallel execution, mutual exclusion, inheritance, organization (privacy, type grouping), and so on into separate (mostly) non-overlapping constructs.

To me it is exactly *one* construct: inheritance. You should be able to inherit from an abstract protected interface at any point of type
hierarchy in order to add mutual exclusion:

type Protected_Integer is new Integer and Protected;

Ada started this process by having tagged types
a separate construct from packages;

I see modules and types as unrelated things.

you need both to get traditional OOP,

but you can also construct many structures that are quite hard in
traditional "one construct" OOP. I think that ought to be done for all constructs, and thus the special task and protected constructs ought to go.

Constructs yes, they must go. It must be all inheritance. The concepts
must stay.

We already know that protected types cause problems with privacy of implementation and with inheritance. Tasks have similar issues (admittedly less encountered), so splitting them into a set of constructs would fit the model.

The problems are of syntactic nature, IMO.

There is an issue with an incomplete inheritance model. You need not
just complete overriding but also more fine mechanisms like extension in
order to deal with entry point implementations. The same problem is with constructors and destructors, BTW. What should really go is
Ada.Finalization mess replaced by a sane user construction hooks model
for all types, class-wide ones included.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.ada

On Sat, 14 Sep 2024 01:18:25 -0500, Randy Brukardt wrote:

Unfortunately, "updater" functions don't work with the Ada model of components, because you can't tell what to do when a component appears
or disappears in an assignment.

But it’s just syntactic sugar, nothing more. Instead of

a := obj.get_prop()
obj.set_prop(a)

(both of which have valid Ada equivalents), you can unify them into

a:= obj.prop
obj.prop := a

What difference does writing it differently make?
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.ada

On Sat, 14 Sep 2024 01:13:28 -0500, Randy Brukardt wrote:

... priorities never help for correctness.

Concurrent programming was never about correctness, it was about efficiency/performance (throughput, latency, whatever is appropriate). And priorities are just another part of this.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.ada

On 2024-09-14 9:13, Randy Brukardt wrote:

"Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message news:lkg1vvF1tp6U1@mid.individual.net...
...

Priorities are just optimization on how to manage cores when there are
not enough of them.

In some contexts it could be optimization -- for example, to increase
throughput in a soft real-time system -- but in hard real-time systems
priorities (or deadlines) are needed for correctness, not just for
optimizatiion.

This I don't buy: priorities never help for correctness. At least not
without extensive static analysis, but if you can do that, you almost certainly can do the correctness without depending upon priorities.

You misunderstood me; perhaps I was too brief.

I said "hard real-time systems", which means that the program is correct
only if it meets its deadlines, for which priorities or deadline-based scheduling are necessary if there are fewer cores than
concurrent/parallel activities, and the application has a wide range of deadlines and activity execution times.

(To be honest, there is the alternative of using a single thread that is manually sliced into small bits, interleaving all the activities
increment by increment, according to a static, cyclic schedule, but that
is IMO a horribly cumbersome and unmaintainable design, though
unfortunately still required in some contexts.)

I believe we agree that priorities should be used for other things, such
as controlling access to shared data, only if there is a well-defined
and safe mechanism for it, such as protected objects with priority
ceilings and priority inheritance on a single core.

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.ada

I am sensible to the complexity vs use balance, and I would easily cope
with the negative consequence of most of the simplifications you propose
(at least those I understand!) but obviously it's hard to be fully aware
of the consequence.

Le 06/09/2024 à 02:03, Randy Brukardt a écrit :

(3) A number of syntax options are eliminated. Matching identifiers are required at the end of subprograms and packages. Initializers are always required (<> can be used if default initialization is needed). Keyword "variable" is needed to declare variables (we do not want the worst option
to be the easiest to write, as it is in Ada).

Why are you considering variables worst than constants?

I don't want the the "worst" option to be the easiest to write, but
neither do I want to put one more keyword in the most common case.

Note that :
1. I have no statistics, but it seems to me that there is more variables
than constants in my code.
2. I say "Useless" from my coder point of view, I dont know if it
simplify the work for compiler or tools implementers.

Lionel
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.ada

Le 06/09/2024 à 02:03, Randy Brukardt a écrit :

(10) Variable-returning functions are introduced. They're pretty similar the semantics of anonymous access returns (or the aliased function returns suggested by Tucker). This means that a variable can easily be treated as a function (and indeed, a variable declaration is just syntactic sugar for
such a function).

I suppose that to allows the compiler to discriminate this non sense code

Square (2) := 3;

from the legitimate

List.Index (3) := Item;

you will have to introduce some specific syntax, like Tucker's "aliased function".

I see the huge benefit from a user point of view, but I'm not aware of compiler internals : doesn't the introduction of a second function type increase complexity?



--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.ada

"Lioneldraghi" <lionel.draghi@free.fr> wrote in message news:vk4uee$3lfp0$1@dont-email.me...
...

Le 06/09/2024 � 02:03, Randy Brukardt a �crit :

(3) A number of syntax options are eliminated. Matching identifiers are
required at the end of subprograms and packages. Initializers are always
required (<> can be used if default initialization is needed). Keyword
"variable" is needed to declare variables (we do not want the worst
option
to be the easiest to write, as it is in Ada).

Why are you considering variables worst than constants?

I don't want the the "worst" option to be the easiest to write, but
neither do I want to put one more keyword in the most common case.

A lot of "variables" in code actually are only written once. In Ada, those
are better modeled as constants. A constant tells the reader that the value doesn't change during the life of the object, which is easier for analysis (both human and machine).

Secondly, I am assuming that automation is helping to write a lot of code. "One more keyword" is irrelevant in terms of creating code, the only
question is whether it hurts readability. I prefer to have most things
written explicitly (but not to the point of noise, of course). That seems especially true if the code is being written by a program and mostly you are trying to figure out why it doesn't work!

Note that :
1. I have no statistics, but it seems to me that there is more variables than constants in my code.

But how many of them *have* to be variables vs. the number that just are because it is easier? I know I have a number of the latter.

2. I say "Useless" from my coder point of view, I dont know if it simplify the work for compiler or tools implementers.

Constants do help the compiler generate better code, although a lot of the benefits can be gained also by working harder. (That's what C compilers do, after all.)

Randy.


--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.ada

"Lioneldraghi" <lionel.draghi@free.fr> wrote in message news:vk53gs$3lfp0$2@dont-email.me...

Le 06/09/2024 � 02:03, Randy Brukardt a �crit :

(10) Variable-returning functions are introduced. They're pretty similar
the
semantics of anonymous access returns (or the aliased function returns
suggested by Tucker). This means that a variable can easily be treated as >> a
function (and indeed, a variable declaration is just syntactic sugar for
such a function).

I suppose that to allows the compiler to discriminate this non sense code

Square (2) := 3;

from the legitimate

List.Index (3) := Item;

you will have to introduce some specific syntax, like Tucker's "aliased function".

I see the huge benefit from a user point of view, but I'm not aware of compiler internals : doesn't the introduction of a second function type increase complexity?

Yes, but Ada already has a bunch of different mechanisms for dealing with objects/functions/exceptions/packages/types. My intent is to collapse those all into one (somewhat more complex) mechanism. The basic idea is that everything resolves a single way, meaning that everything can be overloaded, and there no longer is a semantic difference between:
A : constant T := ...;
and
function A return T is (...);

Whether that really helps remains to be seen, of course. But the goal is to reduce the number of disjoint mechanisms both in the language description
and in the implementation. The hope is then to be able to introduce
additional capabilities on top of a simpler and stronger foundation.

Randy.


--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.ada

On 2024-12-21 09:14, Randy Brukardt wrote:

"One more keyword" is irrelevant in terms of creating code, the only
question is whether it hurts readability.

More keywords = fewer words that can be used as identifiers

so more keywords makes writing code a little bit harder than fewer keywords.

But how many of them *have* to be variables vs. the number that just are because it is easier? I know I have a number of the latter.

I put a lot of effort into making sure that all constants are so declared, because I have the rule that (with certain exceptions) no non-local variables may be referenced from subprograms, but constants may be referenced from anywhere. However, I sometimes have constants that cannot be initialized with a
single expression, resulting in

C : T; -- Constant after initialization

Once C has been initialized, I treat it as a constant. Would your approach allow
the compiler to know that C is really a constant?
--
Jeff Carter
“Anyone who cannot cope with mathematics
is not fully human.”
The Notebooks of Lazarus Long
214
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.ada

On 21.12.24 09:14, Randy Brukardt wrote:

Note that :
1. I have no statistics, but it seems to me that there is more variables
than constants in my code.

But how many of them *have* to be variables vs. the number that just are because it is easier? I know I have a number of the latter.

2. I say "Useless" from my coder point of view, I dont know if it simplify >> the work for compiler or tools implementers.

Constants do help the compiler generate better code, although a lot of the benefits can be gained also by working harder. (That's what C compilers do, after all.)

What are some compilers offering today? That is, can they find declarations
of variables that could be constants, if so instructed?
I am seeing some warnings about non-initialized variables for a meaningless mock-up, but not much else. Ada, C++, Java.
(Maybe there are options that I have missed. Or an analysis of a whole
program yields more.)

function testc (b : Boolean) return Integer is
package P is
x : Integer;
end;
begin
if b then
P.x := 42;
end if;
return P.x;
end testc;

int testc(bool b) {
struct {
int x;
} P;
if (b) {
P.x = 42;
}
return P.x;
}

class testc {
class P {
int x;
}
P P;
int $(boolean b) {
if (b) {
P.x = 42;
}
return P.x;
}
}

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.ada

On 21/12/2024 17:19, G.B. wrote:

On 21.12.24 09:14, Randy Brukardt wrote:

Note that :
1. I have no statistics, but it seems to me that there is more variables >>> than constants in my code.

But how many of them *have* to be variables vs. the number that just are
because it is easier? I know I have a number of the latter.

2. I say "Useless" from my coder point of view, I dont know if it
simplify
the work for compiler or tools implementers.

Constants do help the compiler generate better code, although a lot of
the
benefits can be gained also by working harder. (That's what C
compilers do,
after all.)

What are some compilers offering today? That is, can they find declarations of variables that could be constants, if so instructed?
I am seeing some warnings about non-initialized variables for a meaningless mock-up, but not much else.  Ada, C++, Java.
(Maybe there are options that I have missed. Or an analysis of a whole program yields more.)

function testc (b : Boolean) return Integer is
   package P is
     x : Integer;
   end;
begin
  if b then
     P.x := 42;
  end if;
  return P.x;
end testc;

int testc(bool b) {
   struct {
     int x;
   } P;
   if (b) {
     P.x = 42;
   }
   return P.x;
}

class testc {
  class P {
    int x;
  }
  P P;
  int $(boolean b) {
    if (b) {
       P.x = 42;
    }
    return P.x;
  }
}

My understanding is that many compliers will optimise these, and if
trivial numbers will 'optimise' out the variable. Confusing in the debugger!
--
Chris
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.ada

"Randy Brukardt" <randy@rrsoftware.com> writes:
[...]

A lot of "variables" in code actually are only written once. In Ada, those are better modeled as constants. A constant tells the reader that the value doesn't change during the life of the object, which is easier for analysis (both human and machine).

[...]

Agreed. But my understanding is that compilers typically do this kind
of analysis anyway, at least when optimization is enabled. For example,
if I write:

N : Integer := 42;

and later refer to the value of N, if the compiler is able to prove to
itself that N is never modified after its initialization, it can replace
a reference to N with the constant 42 (and possibly fold it into other
constant expressions).

Using "constant" for something that isn't going to be modified is good practice, but I'd say it's for the benefit of the human reader.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.ada

Le samedi 21 décembre 2024 à 13:26 -0800, Keith Thompson a écrit :

Using "constant" for something that isn't going to be modified is
good
practice, but I'd say it's for the benefit of the human reader.

Exactly the point of Randy. And as Jean-Pierre would say "a program is
written once and read many times" (or something like that).
So having "constant" is a very important point when reading the code
for maintenance. Actually a developer don't care about the compiler,
what is important is the "visible" semantic to the human reader.
--
  Pascal Obry /  Magny Les Hameaux (78)
  The best way to travel is by means of imagination
  http://photos.obry.net
  gpg --keyserver keys.gnupg.net --recv-key F949BD3B
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.ada

"G.B." <bauhaus@notmyhomepage.invalid> writes:

I am seeing some warnings about non-initialized variables for a meaningless mock-up, but not much else.

See -gnatwk, which is included in -gnatwa. Been around for a long time now.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.ada

On 22.12.24 13:15, Simon Wright wrote:

"G.B." <bauhaus@notmyhomepage.invalid> writes:

I am seeing some warnings about non-initialized variables for a meaningless >> mock-up, but not much else.

See -gnatwk, which is included in -gnatwa. Been around for a long time now.

No effect of either here (gcc-14.1.0). I see a CONSTRAINT_ERROR at run time when using the uninitialized return value, for indexing an array.


--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.ada

"G.B." <bauhaus@notmyhomepage.invalid> writes:

On 22.12.24 13:15, Simon Wright wrote:

"G.B." <bauhaus@notmyhomepage.invalid> writes:

I am seeing some warnings about non-initialized variables for a meaningless >>> mock-up, but not much else.

See -gnatwk, which is included in -gnatwa. Been around for a long
time now.

No effect of either here (gcc-14.1.0). I see a CONSTRAINT_ERROR at run time when using the uninitialized return value, for indexing an array.

I _meant_ to be commenting on

What are some compilers offering today? That is, can they find
declarations of variables that could be constants, if so instructed?

Sorry about that.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.ada

"Jeffrey R.Carter" <spam.jrcarter.not@spam.acm.org.not> wrote in message news:vk631h$3vfb4$1@dont-email.me...
...

I put a lot of effort into making sure that all constants are so declared, because I have the rule that (with certain exceptions) no non-local variables may be referenced from subprograms, but constants may be referenced from anywhere.

Precisely. The idea is to encourage use of constants by eliminating the unnatural advantage to writing uninitialized variables. If everything is equally easy/hard to write, then one is more likely to make the best choice for the program.

However, I sometimes have constants that cannot be initialized with a
single expression, resulting in

C : T; -- Constant after initialization

Once C has been initialized, I treat it as a constant. Would your approach allow the compiler to know that C is really a constant?

Not with the approach I was envisioning. Of course, Ada 2022 and beyond already make it possible to initialize a lot more objects (especially with
the introduction of container aggregates), so hopefully it will be less necessary to write things like your example.

Randy.

--
Jeff Carter
"Anyone who cannot cope with mathematics
is not fully human."
The Notebooks of Lazarus Long
214

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.ada

"G.B." <bauhaus@notmyhomepage.invalid> wrote in message news:vk6tag$4tm1$1@dont-email.me...

On 21.12.24 09:14, Randy Brukardt wrote:

...

Constants do help the compiler generate better code, although a lot of
the
benefits can be gained also by working harder. (That's what C compilers
do,
after all.)

What are some compilers offering today? That is, can they find
declarations
of variables that could be constants, if so instructed?

I was thinking from a code generation perspective, as opposed to static analysis. These are really the same process, but in one case the output is only for a computer, and in the other, the output is for a human. The needs
of those outputs are quite different. I think a lot of compilers do optimizations of constants by discovery, but few compilers do much beyond rudimentary static analysis. I expect that to change, but I may be an
optimist on that...

Randy.


--- Synchronet 3.20a-Linux NewsLink 1.114