GNAT Codesize

GNAT Codesize

[Haug Buerger]

I have a little Ada program to convert mail and news to display
propperly on an PC with OS/2, nothing but some character
conversions. The main programm is 146 lines long, the
corresponding object file is from 63849 to 113000 bytes big
depending on the optimizeations (-O0..-O3). The object contains
about 2kbyte of text information. That's about 400 bytes per
line, best case.

Assuming that all the runtime check code is in the runtime
libraries, what is gnat doing? It seems to me that gnat produces
very inefficiente code.

The whole program is never smaller than 400kbyte. Is it possible
to use a dynamic link library for the runtime library? Is there
any chance to reduce the code size?

Haug

Re: GNAT Codesize

[James E. Hopper]

In article <31c8fdd4.5a455349@zesi.ruhr.de> Haug Buerger,
haug@zesi.ruhr.de writes:
>I have a little Ada program to convert mail and news to display
>propperly on an PC with OS/2, nothing but some character
>conversions. The main programm is 146 lines long, the
>corresponding object file is from 63849 to 113000 bytes big
>depending on the optimizeations (-O0..-O3). The object contains
>about 2kbyte of text information. That's about 400 bytes per
>line, best case.
>

we have found that if you pull in text_io things get large in a hurry,
as gcc linker does not prune unused code. however if you can get by with
gnat_io things are MUCH smaller.

jim

Re: GNAT Codesize

[Doug Smith]

In article <31c8fdd4.5a455349@zesi.ruhr.de>, haug@zesi.ruhr.de (Haug
Buerger) wrote:

> I have a little Ada program to convert mail and news to display
> propperly on an PC with OS/2, nothing but some character
> conversions. The main programm is 146 lines long, the
> corresponding object file is from 63849 to 113000 bytes big
> depending on the optimizeations (-O0..-O3). The object contains
> about 2kbyte of text information. That's about 400 bytes per
> line, best case.
> 
> Assuming that all the runtime check code is in the runtime
> libraries, what is gnat doing? It seems to me that gnat produces
> very inefficiente code.
> 
> The whole program is never smaller than 400kbyte. Is it possible
> to use a dynamic link library for the runtime library? Is there
> any chance to reduce the code size?
> 
> Haug

I use the Unix "strip" utility which reduces the code size
from 20-40%. If there is a similar utility on OS/2, you could
try it.

Doug.

Re: GNAT Codesize

[Ralph Paul]

Hi,

there was a thread about code size reduction for GNAT OS/2
about 2-3 months back. Maybe you can check on dejanews ?

Any way check out : http://www.pitt.edu/~tojst1/adaos2

This page contains some tips about reducing your code size


See ya,

Ralph Paul

	paul@aem.umn.edu
or	ralph@ifr.luftfahrt.uni-stuttgart.de

-- 
Ralph Paul


	paul@aem.umn.edu
or	ralph@ifr.luftahrt.uni-stuttgart.de

Re: GNAT Codesize

[Robert Dewar]

Haug said

"Assuming that all the runtime check code is in the runtime
libraries, what is gnat doing? It seems to me that gnat produces
very inefficiente code.

The whole program is never smaller than 400kbyte. Is it possible
to use a dynamic link library for the runtime library? Is there
any chance to reduce the code size?"

You actually have no idea how big your program is, so your guess that
this is gnat inefficiency is incorrect. Undoubtedly you are building
with debugging information present, at least in the runtime library
routines. The debugging informatoin is typically MUCH larger than the
actual code. So strip the objects or executables (depending on your
system) if you want to make the executables smaller (but you won't
be able to debug the resulting program).

These day when 400K of disk space costs 4 cents, most people prefer
to keep the debugging information around which is why this is the
default behavior in the normal setup. 

Note that if you do strip the objects of the library, you must be careful
to preserve the original time stamps.

On some systems it is possible to use a dynamic link library, and the
standard distributions for Linux and SGI do this.
We will probably introduce this in additional distributions as time
goes by.

Re: GNAT Codesize

[John McCabe]

dewar@cs.nyu.edu (Robert Dewar) wrote:

<..snip..>

>You actually have no idea how big your program is, so your guess that
>this is gnat inefficiency is incorrect. Undoubtedly you are building
>with debugging information present, at least in the runtime library
>routines. The debugging informatoin is typically MUCH larger than the
>actual code. So strip the objects or executables (depending on your
>system) if you want to make the executables smaller (but you won't
>be able to debug the resulting program).

By debugging information here are you referring to e.g. symbol tables
and that kind of thing? If so, is it not possible to keep this
information in a separate file akin to what embedded cross-development
systems tend to use? Obviously this would involve a lot of work and
I'm not suggesting that GNAT should be changed to behave like this,
I'm just curious as I too noticed that the GNAT executable for a
[small] program I wrote was more than 2x the size of an [functionally]
identical program compiled with Meridian's DOS Ada compiler.


Best Regards
John McCabe <john@assen.demon.co.uk>

Re: GNAT Codesize

[John Howard]

-- Filename: mini.adb
procedure mini is
begin
  null;
end mini;

>gnatmake mini

The DJGPP version (GNAT v3.05) produces:
MINI     ADB        46   6-22-96  4:38p
MINI     ALI       117   6-22-96  4:39p
MINI     O         400   6-22-96  4:39p
MINI     EXE     47104   6-22-96  4:40p

The OS/2 version (GNAT v3.05) produces:
 6-22-96   4:38p        46           0  MINI.ADB
 6-22-96   4:42p       117           0  mini.ali
 6-22-96   4:42p       130           0  mini.o
 6-22-96   4:42p     56298           0  mini.exe

There is an article in July 1996 Embedded Systems Programming which refers
to people using the codesize of "Hello, world" to help gauge the quality
of a compiler.  Most of us want our programs to be as small as possible. 
By todays standards most of us recognize that a 250 KB "Hello, world" 
program is too bloated.  Heck, all it must do is print one line of text.

Some observations about "Hello, world" in the P.J. Plauger article:
Unix C produces a few hundred bytes.  Using printf bloats the codesize to
around 10 KB.  Typical C++ produces around 250 KB.  Optimized C++ produces 
around 50 KB.

Below are my Turbo Pascal and two GNAT v3.05 results.

program HelloWorld;
begin
  writeln('Hello, world');
end.

>tpc hello.pas

The Borland Turbo Pascal v7.0 produces:
HELLO    EXE      2192   6-24-96  7:33p

There are two keys to producing smaller executables.  One is to strip the 
executable of debug information.  The other key is to use a smart linker.

TP7 uses a smart linker and defaults to producing a stripped executable. 
Ideally we want GNAT to use a smart linker that only pulls in data that is
actually referenced.  ( There should also be some pragmas to tell the
compiler and linker to create a DLL instead of an Executable.  TP7 can 
produce a 16-bit DLL that works under either DOS protected mode interface 
or Windows or OS/2. )

-- Filename: hello.adb
with Text_IO;
procedure hello is
begin
  Text_IO.Put_Line("Hello, world");
end hello;

>gnatmake hello

The DJGPP version (GNAT v3.05) produces:
HELLO    ADB        91   6-24-96  8:21p
HELLO    ALI       749   6-24-96  8:39p
HELLO    O         519   6-24-96  8:39p
HELLO    EXE     83456   6-24-96  8:40p

The OS/2 version (GNAT v3.05) produces:
HELLO    ADB        91   6-24-96  8:21p
HELLO    ALI       749   6-24-96  8:22p
HELLO    O         237   6-24-96  8:22p
HELLO    EXE    263355   6-24-96  8:22p

The OS/2 GNAT unstripped executable codesize is like typical C++ 
bloatware.  It would be an embarassment to distribute bloatware when
demonstrating an example of Ada 95 advantages.  Bloatware is a stigma that
reinforces the idea of inefficient code produced by poor compilers and/or
inept programmers.

------------------------------------------------------------------------
-- John Howard <jhoward@sky.net>               -- Team OS/2  Team Ada --

Re: GNAT Codesize

[Robert Dewar]

using the codesize of hello world as a measure of something or other
is not unreasonable, but be careful not to assume that you can measure
code size by looking at the size of the executable, since the two
are unrelated, in particular the executable contains both the code
and the debugging information -- the latter can be quite voluminous,
and indeed from one point of view, it is a measure of quality to 
generate MORE debugging information rather than less, assuming that
the information is properly generated and useful.

Re: GNAT Codesize

[David J. Fiander]

According to John Howard <jhoward@sky.net>:
>
>Below are my Turbo Pascal and two GNAT v3.05 results.
>
>program HelloWorld;
>begin
>  writeln('Hello, world');
>end.
>
>>tpc hello.pas
>
>The Borland Turbo Pascal v7.0 produces:
>HELLO    EXE      2192   6-24-96  7:33p
>
>The DJGPP version (GNAT v3.05) produces:
>HELLO    ADB        91   6-24-96  8:21p
>HELLO    ALI       749   6-24-96  8:39p
>HELLO    O         519   6-24-96  8:39p
>HELLO    EXE     83456   6-24-96  8:40p
>
>The OS/2 version (GNAT v3.05) produces:
>HELLO    ADB        91   6-24-96  8:21p
>HELLO    ALI       749   6-24-96  8:22p
>HELLO    O         237   6-24-96  8:22p
>HELLO    EXE    263355   6-24-96  8:22p

Checking the size on disk is pretty pointless if the file
contains debugging symbol tables because no O/S (not even DOS)
will load the debugging information into memory.  More
interesting is the output of the "size" command, which displays
the size of the text, data, and bss regions (or their DOS
equivalents).


	with Ada.Text_IO;
	use Ada;

	procedure Main is
	begin
	   Text_IO.Put_Line("Hello, world");
	end Main;

GNAT 3.05 on Solaris produces:

	worf=(); size thello
	36756t + 708d + 1724d + 4500b = 43688 (aaa8)

while the file size is

	worf=(); ls -l thello
	-rwxr-xr-x   1 davidf   r+d       116904 Jun 21 10:23 thello

So, half the disk file is debugging info.  Of course, using
Gnat_IO:

	with Gnat.IO;

	procedure Main is
	begin
		Gnat.IO.Put_Line("Hello, world");
	end Main;

gives me a size of

	worf=(); size ghello
	2888t + 250d + 408d + 2616b = 6162 (1812)

Mostly because Gnat.IO doesn't suck in all the exception, finalization,
streams, and unused text code that Ada.Text_IO does.

- David

Re: GNAT Codesize

[Robert Dewar]

John McCabe said

"By debugging information here are you referring to e.g. symbol tables
and that kind of thing? If so, is it not possible to keep this
information in a separate file akin to what embedded cross-development
systems tend to use? Obviously this would involve a lot of work and
I'm not suggesting that GNAT should be changed to behave like this,
I'm just curious as I too noticed that the GNAT executable for a
[small] program I wrote was more than 2x the size of an [functionally]
identical program compiled with Meridian's DOS Ada compiler."


Yes, exactly, symbol table type information. Yes you could keep it in
a separate file, but 

(a) it would not save any disk space to have two files instead of one
(b) you don't load the symbol information, so it would not save load time
(c) it would violate system standards, which are to keep debugging 
	information in the objects and executables. The GNAT approach
	is deliberately system standard compatible to allow use of
	standard debuggers.

Presumbaly Meridian kept debugging information in some non-standard
proprietary format (as did and do many other Ada compilers).

Re: GNAT Codesize

[John McCabe]

dewar@cs.nyu.edu (Robert Dewar) wrote:

>John McCabe said

<..snip..>

>Yes, exactly, symbol table type information. Yes you could keep it in
>a separate file, but 

>(a) it would not save any disk space to have two files instead of one

Good point, however there would be the advantage that when you wanted
to ditch it, you just have to delete the symbol file without touching
the executable.

>(b) you don't load the symbol information, so it would not save load time

But don't you still have to decide which bits to load and not to load?
If you didn't have to make that decision, there presumably would be
some [probably unnoticeable] reduction in the load time.

>(c) it would violate system standards, which are to keep debugging 
>	information in the objects and executables. The GNAT approach
>	is deliberately system standard compatible to allow use of
>	standard debuggers.

Yes, that appears reasonable. Obviously this tends not to be so
important in the cross-compilation systems I mentioned as they must
provide their own proprietary debuggers and processor simulators.

>Presumbaly Meridian kept debugging information in some non-standard
>proprietary format (as did and do many other Ada compilers).

Looking back at what I was doing, I think the Meridian default is not
to produce debugging information.


Best Regards
John McCabe <john@assen.demon.co.uk>

Re: GNAT Codesize

[Fergus Henderson]

john@assen.demon.co.uk (John McCabe) writes:

>dewar@cs.nyu.edu (Robert Dewar) wrote:
>
>>Yes, exactly, symbol table type information. Yes you could keep it in
>>a separate file, but 
>
>>(a) it would not save any disk space to have two files instead of one
>
>Good point, however there would be the advantage that when you wanted
>to ditch it, you just have to delete the symbol file without touching
>the executable.

Why would that be an advantage?  What's wrong with just using the
`strip' command?

>>(b) you don't load the symbol information, so it would not save load time
>
>But don't you still have to decide which bits to load and not to load?
>If you didn't have to make that decision, there presumably would be
>some [probably unnoticeable] reduction in the load time.

I don't think so.  All decent modern systems do demand-loading, so they
don't load the entire executable at once anyway.  They just load each
page as it is needed.  In any case, as you note, any overhead here
would be insignificant.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: GNAT Codesize

[John McCabe]

fjh@mundook.cs.mu.OZ.AU (Fergus Henderson) wrote:

>>Good point, however there would be the advantage that when you wanted
>>to ditch it, you just have to delete the symbol file without touching
>>the executable.

>Why would that be an advantage?  What's wrong with just using the
>`strip' command?

Because you're modifying the file that contains the executable code
and you're risking the possibility of a bug in the 'strip' command
that may remove something it shouldn't. This may be something that
happens to be not fully tested on a large system.

It's probably highly unlikely I know, but stranger things have
happened.

Best Regards
John McCabe <john@assen.demon.co.uk>

Re: GNAT Codesize

[Robert Dewar]

John McCabe says

"Because you're modifying the file that contains the executable code
and you're risking the possibility of a bug in the 'strip' command
that may remove something it shouldn't. This may be something that
happens to be not fully tested on a large system."

Now that's really FUD at work. Strip is a trivial command, you might as
well worry about ls corrupting the file, or worrying that deleting the
separate symbol table file might clobber the executable file (stranger
things have happened). Of course strip has been tested on large systems!

If you start using this argument, you can prove that ANY possible aproach
might be dangerous!

Re: GNAT Codesize

[John McCabe]

dewar@cs.nyu.edu (Robert Dewar) wrote:


>John McCabe says

>"Because you're modifying the file that contains the executable code
>and you're risking the possibility of a bug in the 'strip' command
>that may remove something it shouldn't. This may be something that
>happens to be not fully tested on a large system."

>Now that's really FUD at work. Strip is a trivial command, you might as
>well worry about ls corrupting the file, or worrying that deleting the
>separate symbol table file might clobber the executable file (stranger
>things have happened). Of course strip has been tested on large systems!

>If you start using this argument, you can prove that ANY possible aproach
>might be dangerous!

You've removed the quoted line:

"It's probably highly unlikely I know, but stranger things have
happened."

from your reply.


Best Regards
John McCabe <john@assen.demon.co.uk>

Re: GNAT Codesize

[JP Thornley]

In article: <dewar.836197454@schonberg>  dewar@cs.nyu.edu (Robert Dewar) 
writes:

  (in relation to using 'trivial' tools on files)

> If you start using this argument, you can prove that ANY possible aproach
> might be dangerous!
> 

Well, we have had experience of the VMS 'copy' command fouling up some 
Ada code.

(The config controller used copy *.*;* instead of copy *.* without doing 
a purge first.)

-- 
------------------------------------------------------------------------
| JP Thornley    EMail jpt@diphi.demon.co.uk                           |
------------------------------------------------------------------------

Re: GNAT Codesize

[Robert Dewar]

John McCabe said (speaking of symbol information in executables)

  "Good point, however there would be the advantage that when you wanted
   to ditch it, you just have to delete the symbol file without touching
   the executable."

Seems irrelevant, it is perfectly easy to strip the executable. There may
be some systems in which you cannot strip an executable, but the best
thing would be to fix this obvious lack of functionality.

  ">(b) you don't load the symbol information, so it would not save load time
   But don't you still have to decide which bits to load and not to load?
   If you didn't have to make that decision, there presumably would be
   some [probably unnoticeable] reduction in the load time.

Well I suppose you have to store and read one extra word of information
in the file, which might take a few extra microseconds. However, from
a performance point of view it is much better to keep all the information
in one file than two, since you save directory search time, as someone
else already pointed out.

  ">(c) it would violate system standards, which are to keep debugging
   >       information in the objects and executables. The GNAT approach
   >       is deliberately system standard compatible to allow use of
   >       standard debuggers.
   Yes, that appears reasonable. Obviously this tends not to be so
   important in the cross-compilation systems I mentioned as they must
   provide their own proprietary debuggers and processor simulators.

Actually in my experience this is exactly wrong. It is for cross-development
that it is most critical to generate debugging information in standard
system format. For example, many of the hardware emulators provide builtin
debugging capability based on generation of symbol information in object
files and executables in the standard format. Such systems will typically
have utilities to strip/remove/process this information in a form that is
suitable for the emulator use, but it is critical that it be generated in
standard format. In fact thinking about cross-systems is one of the strong
arguments in favor of the GNAT approach of using standard debugging info.

Re: GNAT Codesize

[John McCabe]

dewar@cs.nyu.edu (Robert Dewar) wrote:

>John McCabe said (speaking of symbol information in executables)

<..snip..>

>  ">(c) it would violate system standards, which are to keep debugging
>   >       information in the objects and executables. The GNAT approach
>   >       is deliberately system standard compatible to allow use of
>   >       standard debuggers.
>   Yes, that appears reasonable. Obviously this tends not to be so
>   important in the cross-compilation systems I mentioned as they must
>   provide their own proprietary debuggers and processor simulators.

>Actually in my experience this is exactly wrong. It is for cross-development
>that it is most critical to generate debugging information in standard
>system format. For example, many of the hardware emulators provide builtin
>debugging capability based on generation of symbol information in object
>files and executables in the standard format. Such systems will typically
>have utilities to strip/remove/process this information in a form that is
>suitable for the emulator use, but it is critical that it be generated in
>standard format. In fact thinking about cross-systems is one of the strong
>arguments in favor of the GNAT approach of using standard debugging info.

Not in my experience. My current compiler uses a proprietary format
and even when using an Tek emulator with a Tek 8086 Pascal
cross-compiler on a VAX we had to use a separate utility to format the
output for use in the emuulator.


Best Regards
John McCabe <john@assen.demon.co.uk>

Re: GNAT Codesize

[Robert Dewar]

John McCabe said

"Not in my experience. My current compiler uses a proprietary format
and even when using an Tek emulator with a Tek 8086 Pascal
cross-compiler on a VAX we had to use a separate utility to format the
output for use in the emuulator."

The fact that one particular system is not organized enough to have a well
defined ABI and compilers and tools that conform to this ABI is hardly
significant. The fact is that many systems *do* have such conventions,
and they are followed!

Re: GNAT Codesize

[Fergus Henderson]

dewar@cs.nyu.edu (Robert Dewar) writes:

>John McCabe said
>
>"By debugging information here are you referring to e.g. symbol tables
>and that kind of thing? If so, is it not possible to keep this
>information in a separate file akin to what embedded cross-development
>systems tend to use?"
>
>Yes, exactly, symbol table type information. Yes you could keep it in
>a separate file, but 
>
>(a) it would not save any disk space to have two files instead of one
>(b) you don't load the symbol information, so it would not save load time
>(c) it would violate system standards, which are to keep debugging 
>	information in the objects and executables. The GNAT approach
>	is deliberately system standard compatible to allow use of
>	standard debuggers.

Also	(d) the increased number of files would slow down directory
	    lookups, which can be an important factor in compilation time
	    for large projects (with typical file systems, searching a
	    directory with N files is O(N))
and	(e) it would be irritating; simple commands like `cp foo foo.old'
	    or `rm foo' would not be sufficient, and more complicated
	    commands would have to be used instead.

On the other hand, it might well be a good idea to make the `-s' (strip)
option the default if `-g' (debug) was not specified on the command
line during the linking step.  That's what I did for the Mercury
compiler, and we haven't got any complaints about it.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: GNAT Codesize

[Michael Feldman]

In article <4r1806$aci@mulga.cs.mu.OZ.AU>,
Fergus Henderson <fjh@mundook.cs.mu.OZ.AU> wrote:

>On the other hand, it might well be a good idea to make the `-s' (strip)
>option the default if `-g' (debug) was not specified on the command
>line during the linking step.  That's what I did for the Mercury
>compiler, and we haven't got any complaints about it.

Actually, GNAT/DOS does this. If no -g was specified, it strips the
executable.

Mike Feldman

Re: GNAT Codesize

[John McCabe]

mfeldman@seas.gwu.edu (Michael Feldman) wrote:

>In article <4r1806$aci@mulga.cs.mu.OZ.AU>,
>Fergus Henderson <fjh@mundook.cs.mu.OZ.AU> wrote:

>>On the other hand, it might well be a good idea to make the `-s' (strip)
>>option the default if `-g' (debug) was not specified on the command
>>line during the linking step.  That's what I did for the Mercury
>>compiler, and we haven't got any complaints about it.

>Actually, GNAT/DOS does this. If no -g was specified, it strips the
>executable.

That's interesting as it was on DOS that I (and some others)
originally noticed the huge increase in size over the Meridian
compiler (see a previous posting for details).

Best Regards
John McCabe <john@assen.demon.co.uk>

Re: GNAT Codesize

[John McCabe]

fjh@mundook.cs.mu.OZ.AU (Fergus Henderson) wrote:

<..snip..>

>and	(e) it would be irritating; simple commands like `cp foo foo.old'
>	    or `rm foo' would not be sufficient, and more complicated
>	    commands would have to be used instead.

On the other hand, when you've finished debugging and want to provide
an official release, you only have to copy a single file rather than
having to strip it of debugging information first.

It works both ways really, I think the only real advantage either
method has is the one Robert Dewar mentioned about being compatible
with system standards (although I'd be grateful if he'd enlighten us
on exactly what he means by that phrase).

Best Regards
John McCabe <john@assen.demon.co.uk>

Re: GNAT Codesize

[Robert Dewar]

John McCabe
said

"On the other hand, when you've finished debugging and want to provide
an official release, you only have to copy a single file rather than
having to strip it of debugging information first.

It works both ways really, I think the only real advantage either
method has is the one Robert Dewar mentioned about being compatible
with system standards (although I'd be grateful if he'd enlighten us
on exactly what he means by that phrase)."

First, John, you are making some big deal about stripping, it is a trivial
process, and it is no harder to strip a file than to copy it, either at
the user level of at the implementation level. And you are ignoring the
real advantages of efficiency that we have discussed of having a single file.

As to system standards, typically the ABI specifies the format of debugging
information stored in object files and executables. By following this format,
you will be compatible with all tools that use this format.

For example, gprof, the profiling program, is driven by debugging 
information in standard system format. If your compiler generates debugging
information in this format, then gprof will work without modification.
This is indeed true for GNAT, and many of our users are using gprof.
\x1adp

Re: GNAT Codesize

[John McCabe]

dewar@cs.nyu.edu (Robert Dewar) wrote:

<..snip..>

>First, John, you are making some big deal about stripping, it is a trivial
>process, and it is no harder to strip a file than to copy it, either at
>the user level of at the implementation level.

It does appear that way doesn't it? Let's forget about strip from now
on - besides, someone mentioned the default behaviour of GNAT on DOS
was _not_ to leave debugging information in the executable which takes
me back to me originally mentioning that the GNAT executable was 2 to
3 times the size of the Meridian one for identical functionality.

>And you are ignoring the
>real advantages of efficiency that we have discussed of having a single file.

If you say so - the only efficency advantage I've seen shown is that
it reduces the directory lookup time. This is trivial.

>As to system standards, typically the ABI specifies the format of debugging
>information stored in object files and executables. By following this format,
>you will be compatible with all tools that use this format.

>For example, gprof, the profiling program, is driven by debugging 
>information in standard system format. If your compiler generates debugging
>information in this format, then gprof will work without modification.
>This is indeed true for GNAT, and many of our users are using gprof.
>\x1adp

Surely gprof though will depend on the program being operational in
the host system? How does this fit in with cross-compilation systems.
I need third party profiling tools for the compiler I use to
cross-compile MIL-STD-1750A code on a Sun SPARCstation. Are you saying
that if my compiler generated a MIL-STD-1750A program in the required
Sun Solaris ABI format, that I could use the gprof program to profile
it?

I don't think so.

Best Regards
John McCabe <john@assen.demon.co.uk>

Re: GNAT Codesize

[Robert Dewar]

John McCabe said

"If you say so - the only efficency advantage I've seen shown is that
it reduces the directory lookup time. This is trivial."

Not at all, directory lookup time can be quite appreciable if you have
very large directories. On some systems, we have found this to be a
significant source of slowing down of compilations.

Re: GNAT Codesize

[Michael Feldman]

In article <836687839.21932.0@assen.demon.co.uk>,
John McCabe <john@assen.demon.co.uk> wrote:

>It does appear that way doesn't it? Let's forget about strip from now
>on - besides, someone mentioned the default behaviour of GNAT on DOS
>was _not_ to leave debugging information in the executable which takes
>me back to me originally mentioning that the GNAT executable was 2 to
>3 times the size of the Meridian one for identical functionality.

Anyone interested in the mechanics of that DOS default is invited
to look in the bin directory where the GNAT binaries are. You will
discover there coff2exe.bat, a simple DOS batch file implementing
the behavior. You can even change it if you wish.:-)

Mike Feldman

Re: GNAT Codesize

[Gavin Smyth]

There have been a number of people noting that GNAT DOS executables are
quite large. Someone has done some work in shrinking DJGPP executables
by effectively compressing the files, and building an uncompressor
into the startup code. You can find Laszlo Molnar's DJP utility with
the rest of the DJGPP stuff (eg, Simtel somewhere under /vendors/djgpp/v2
I think, or at DJGPP's home, http://www.delorie.com/djgpp/). You can
run this tool on the executable produced by GNAT or you can do as I did,
and automatically invoke it as part of the build process - the final 
stage
of a GNAT build under DOS is to call COFF2EXE.BAT. I replaced the 
supplied
one with one that calls DJP on the last line - see below:

   My COFF2EXE.BAT

          @echo off
          copy %1 %1.cof>nul:
          strip %1
          stubify %1
          del %1
          rename %1.cof %1
          djp %1.exe

It does seem to make a worthwhile saving in disc space, at the expense
of a little startup time, and some extra build time, and I haven't
had any problems with it so far.

Gavin

Question about the need for requeue as described in Rationale

[James A. Squire]

In the Ada95 Rationale, II.9 "Protected Types", it says the following:

"Our final example introduces the ability to requeue a call on another
entry. It sometimes happens that a service needs to be provided in two
parts and that the calling task has to be suspended after the first part
until conditions are such that the second part can be done. Two entry
calls are then necessary but attempts to program this in Ada 83 usually
run into difficulties; race conditions can arise in the interval between
the calls and there is often unnecessary visibility of the internal
protocol."

It goes on to cite an example which does not represent work that needs
to be provided in two parts, and concludes with this disclaimer:

"The above example has been used for illustration only. The astute
reader will have observed that the condition is not strictly needed
inside Signal; without it the caller will simply always requeue and then
immediately be processed if there are no waiting tasks. But the
condition clarifies the description. Indeed, the very astute reader
might care to note that we can actually program this example in Ada 95
without using requeue at all. A more realistic classic example is the
disk scheduler where a caller is requeued if the head is currently over
the wrong track."

I am trying to understand what problem Requeue is trying to solve and
the above does not help me.  I can see from the example given how it
would be difficult to do the same thing in Ada83, but as I was trying to
describe the Ada83 problem that raised the need for this, I found I
couldn't come up with any good way of describing the problem.

"race conditions can arise in the interval between the calls" - like
what, for example?  A race condition, AFAIK, is where two tasks are both
updating the same data object but act as if they are oblivious to it.
I'm having trouble seeing how that applies in the context in which this
quote was used.

"Indeed, the very astute reader might care to note that we can actually
program this example in Ada 95 without using requeue at all." - Great!
So why was it used if it wasn't needed?  For that matter, how can I do
it in Ada 95 without requeue?

"A more realistic classic example is the disk scheduler where a caller
is requeued if the head is currently over the wrong track." - Gee, then
why didn't they?  I have a feeling I would understand the dilemma a lot
better if they had.

Can anybody help me understand what race conditions can't be avoided in
Ada83 that pertain the situation where a service needs to be provided in
two parts?  (Frankly, if they had said "deadlock" instead, I might have
understood that a bit more)

Thank you.
--
James Squire
MDA Avionics Tools & Processes
ja_squire@csehp3.mdc.com
Opinions expressed here are my own and NOT my company's
"one of these days I'm going to better myself by going to Knight school"
"You'll be a web knight instead of a web page!"

Re: Question about the need for requeue as described in Rationale

[Bo I. Sanden]

James A. Squire (m193884@CSEHP3.MDC.COM) wrote:
: I am trying to understand what problem Requeue is trying to solve and
: the above does not help me.  I can see from the example given how it
: would be difficult to do the same thing in Ada83, but as I was trying to
: describe the Ada83 problem that raised the need for this, I found I
: couldn't come up with any good way of describing the problem.

In my understanding, requeue is "needed" in Ada 95 primarily as part of
the effort to replace by protected units what was sometimes called 
guardian tasks in Ada 83. Guardian tasks execute only while being
called by other task, and made a typical Ada 83 program contain more 
tasks than the inherent concurrency of the problem would suggest. 
(Guardian tasks where there to restrict concurrency by enforcing 
synchronization of other tasks.)

The following example appears in full in the March 96 issue of the Ada
User Journal: There are a number of tasks each responsible for the 
heating of a home. The monitor shown below enforces rationing. For reasons
known only to the originators of this example, only 4 out of 5 homes
(say) can be heated at the same time. But a home can be without 
heating forcibly for no more than 10 minutes. After having waited for
heat that long, a home task calls the Insist entry. A call to Insist 
causes a switch to be set that in turn will cause one of the other 
homes to turn off its heat. After setting the switch, the call to 
Insist is requeue until another home has shut down its heating in 
an orderly fashion and called Release.

In Ada 83, Monitor is a guardian task and the wait is implemented by
a statement accept Release nested within the body of accept Insist.
This is not allowed in a protected unit, and instead requeue is used.

protected body Monitor is
    .......
   
    entry Wait (H: Hnum) when Active < Home_Num - 1 is
    begin
        Active := Active + 1;
    end Wait;

    entry Insist (H: Hnum) when Wait'count = 0 is
    begin
        if Active < Home_Num - 1 then
            ......
        else
            Auto_Status(...) := Off;      -- Set switch
            requeue Wait;                 -- Wait for shut-down
        end if;
    end Insist;

    procedure Release (I: Hnum) is
    begin
        Active := Active - 1;
    end Release;
end Monitor;

---------------------------------------------------------------------
Dr. Bo Sanden					Author of:
Mail Stop 4A4				Software Systems Construction
George Mason University			    with examples in Ada
Fairfax, VA 22030-4444, USA		     Prentice-Hall 1994

        Tutorials on concurrent/real-time software design
                      at WAdaS and TRI-Ada
             http://www.isse.gmu.edu/faculty/bsanden
---------------------------------------------------------------------

Re: Question about the need for requeue as described in Rationale

[progers]

In <4rjimv$glk@portal.gmu.edu>, bsanden@site.gmu.edu (Bo I. Sanden) writes:
>James A. Squire (m193884@CSEHP3.MDC.COM) wrote:
>: I am trying to understand what problem Requeue is trying to solve and
>: the above does not help me.  I can see from the example given how it
>: would be difficult to do the same thing in Ada83, but as I was trying to
>: describe the Ada83 problem that raised the need for this, I found I
>: couldn't come up with any good way of describing the problem.
>
>In my understanding, requeue is "needed" in Ada 95 primarily as part of
>the effort to replace by protected units what was sometimes called 
>guardian tasks in Ada 83. Guardian tasks execute only while being
>called by other task, and made a typical Ada 83 program contain more 
>tasks than the inherent concurrency of the problem would suggest. 
>(Guardian tasks where there to restrict concurrency by enforcing 
>synchronization of other tasks.)

Requeue is needed to deal with the difficulties associated with
"avoidance synchronization", which is the model used in Ada.
The most illustrative example IMHO is the lack
of expressive power of guard conditions in select statements:
the conditions may not refer to the formal parameters of the
accept statements they control.  Thus you sometimes have to 
to do two rendezvous instead of one, and this leads to a
number of other difficulties: the race conditions and potential
for abort mentioned elsewhere.  

See 

	A Problem With Ada and Resource Allocation, Ada
	Letters, vol. 3, no. 4 from 1984,

or better yet, to hear how requeue works,

	Burns & Wellings' Concurrency In Ada, 
	Cambridge University Press, 1995

pat
---------------
Patrick Rogers
progers@acm.org

Re: Question about the need for requeue as described in Rationale

[Robert A Duff]

In article <31DAD51F.40F1@csehp3.mdc.com>,
James A. Squire <m193884@CSEHP3.MDC.COM> wrote:
>In the Ada95 Rationale, II.9 "Protected Types", it says the following:
>
>"Our final example introduces the ability to requeue a call on another
>entry. It sometimes happens that a service needs to be provided in two
>parts and that the calling task has to be suspended after the first part
>until conditions are such that the second part can be done. Two entry
>calls are then necessary but attempts to program this in Ada 83 usually
>run into difficulties; race conditions can arise in the interval between
>the calls and there is often unnecessary visibility of the internal
>protocol."
>
>It goes on to cite an example which does not represent work that needs
>to be provided in two parts, and concludes with this disclaimer:
>
>"The above example has been used for illustration only. The astute
>reader will have observed that the condition is not strictly needed
>inside Signal; without it the caller will simply always requeue and then
>immediately be processed if there are no waiting tasks. But the
>condition clarifies the description. Indeed, the very astute reader
>might care to note that we can actually program this example in Ada 95
>without using requeue at all. A more realistic classic example is the
>disk scheduler where a caller is requeued if the head is currently over
>the wrong track."
>
>I am trying to understand what problem Requeue is trying to solve and
>the above does not help me.

Right -- it's not intended to help you in that way.  This part of the
"Rationale" isn't really rationale at all -- it's a tutorial, and is
trying to explain how requeue works (as opposed to why it's in the
language).

You should instead look at section 9.2 and 9.2.1 in Part 2.  I believe
it answers your questions.  One thing you might want to do is to rewrite
the disk controller example of 9.2.1 without using requeue, but making
sure it's abort-safe and ATC-safe, and the server accepts additional
callers while waiting for interrupts (i.e. while one or more requests
are in the process of being serviced), and there are no race conditions,
etc.

>...  I can see from the example given how it
>would be difficult to do the same thing in Ada83, but as I was trying to
>describe the Ada83 problem that raised the need for this, I found I
>couldn't come up with any good way of describing the problem.
>
>"race conditions can arise in the interval between the calls" - like
>what, for example?  A race condition, AFAIK, is where two tasks are both
>updating the same data object but act as if they are oblivious to it.

A race condition is really any timing-related bug.  Suppose you had a
task that had two entries Do_Part_1 and Do_Part_2, which are really two
parts of the same thing.  It might be considered a race condition if one
task does:

    T.Do_Part_1(...);
    T.Do_Part_2(...);

And another task can sneak in and do something in between the above.
Assuming that causes some damage, of course.

>I'm having trouble seeing how that applies in the context in which this
>quote was used.
>
>"Indeed, the very astute reader might care to note that we can actually
>program this example in Ada 95 without using requeue at all." - Great!
>So why was it used if it wasn't needed?  For that matter, how can I do
>it in Ada 95 without requeue?

The solution is quite tricky, and is shown in 9.2.

>"A more realistic classic example is the disk scheduler where a caller
>is requeued if the head is currently over the wrong track." - Gee, then
>why didn't they?  I have a feeling I would understand the dilemma a lot
>better if they had.

They did.

>Can anybody help me understand what race conditions can't be avoided in
>Ada83 that pertain the situation where a service needs to be provided in
>two parts?  (Frankly, if they had said "deadlock" instead, I might have
>understood that a bit more)
>
>Thank you.

Hope this helps.

- Bob

Re: Question about the need for requeue as described in Rationale

[Samuel Tardieu]

>>>>> "James" == James A Squire <m193884@CSEHP3.MDC.COM> writes:

James> "Indeed, the very astute reader might care to note that we can
James> actually program this example in Ada 95 without using requeue
James> at all." - Great! So why was it used if it wasn't needed?  For
James> that matter, how can I do it in Ada 95 without requeue?

You could try something like this: (untested)

   protected Event is
      entry Wait;
      procedure Signal;
   private
      Occurred : Boolean := False;
   end Event;

   protected body Event is
     
      entry Wait when Occurred is
      begin
         Occurred := Wait'Count > 0;
      end Wait;

      procedure Signal is
      begin
         Occurred := Wait'Count > 0;
      end Signal;

   end Event;      

  Sam
-- 
"La cervelle des petits enfants, ca doit avoir comme un petit gout de noisette"
                                                       Charles Baudelaire

Re: Question about the need for requeue as described in Rationale

[Robert Dewar]

James Squire said

""Indeed, the very astute reader might care to note that we can
actually program this example in Ada 95 without using requeue
at all." - Great! So why was it used if it wasn't needed?  For
that matter, how can I do it in Ada 95 without requeue?"

That strikes me as a bit odd. You often use features in programming
languages that are not "needed", to improve the efficiency, readability,
implementability, or simplicity of your code. After all it is obvious 
that the assignment statement in Ada is redundant in that any code you
write using assignments could be written in an applicative style without
assignments, but that's no reason to avoid assignments.

A complex feature like requeue is never essential from a functionality
point of view (though it might be critical on a given implementation
from a performance point of view). Clearly anything in Ada 95 that can
be written with requeue can be written without, but possibly at the
expense of clarity and efficiency.

This is one of those situations where the notions of complexity and
simplicity get quite confused. Adding a feature like requeue to a
language makes he language more complex, but may well make programs
using the feature more simple.

During the Ada 95 design process, everyone was in favor of simplicity,
and opposed to complexity, but we often found that this agreement was
pretty meaningless, given these often entirely contradictory ideas
of what simplicity might mean. A designer trying to simplify programming
in Ada by providing useful new features does *not* find the impelementors
agreeing that they are simplifying things :-)

Re: Question about the need for requeue as described in Rationale

[James A. Squire]

progers@ACM.ORG wrote:

> Requeue is needed to deal with the difficulties associated with
> "avoidance synchronization", which is the model used in Ada.
> The most illustrative example IMHO is the lack
> of expressive power of guard conditions in select statements:
> the conditions may not refer to the formal parameters of the
> accept statements they control.  Thus you sometimes have to
> to do two rendezvous instead of one, and this leads to a
> number of other difficulties: the race conditions and potential
> for abort mentioned elsewhere.

How is this different from barrier conditions on protected entries and
procedures?

> See
>
>         A Problem With Ada and Resource Allocation, Ada
>         Letters, vol. 3, no. 4 from 1984,
>
> or better yet, to hear how requeue works,
>
>         Burns & Wellings' Concurrency In Ada,
>         Cambridge University Press, 1995

I don't have access to either of these references.  Could you be a
little more lucid?  The thrust of what you are saying went right by me.
--
James Squire
MDA Avionics Tools & Processes
ja_squire@csehp3.mdc.com
Opinions expressed here are my own and NOT my company's
"one of these days I'm going to better myself by going to Knight school"
"You'll be a web knight instead of a web page!"

Re: Question about the need for requeue as described in Rationale

[progers]

In <31E16C28.3BE2@csehp3.mdc.com>, "James A. Squire" <m193884@CSEHP3.MDC.COM> writes:
>progers@ACM.ORG wrote:
>
>> Requeue is needed to deal with the difficulties associated with
>> "avoidance synchronization", which is the model used in Ada.
>> The most illustrative example IMHO is the lack
>> of expressive power of guard conditions in select statements:
>> the conditions may not refer to the formal parameters of the
>> accept statements they control.  Thus you sometimes have to
>> to do two rendezvous instead of one, and this leads to a
>> number of other difficulties: the race conditions and potential
>> for abort mentioned elsewhere.
>
>How is this different from barrier conditions on protected entries and
>procedures?

The same issue applies to protected entry barriers (protected
procedures don't have barriers).


>> See
>>
>>         A Problem With Ada and Resource Allocation, Ada
>>         Letters, vol. 3, no. 4 from 1984,
>>
>> or better yet, to hear how requeue works,
>>
>>         Burns & Wellings' Concurrency In Ada,
>>         Cambridge University Press, 1995
>
>I don't have access to either of these references.  Could you be a
>little more lucid?  The thrust of what you are saying went right by me.

Well, I think I was lucid when I wrote that :) but maybe I could have been
less succinct!  In any case, I strongly suggest you get access to the
Burns' and Wellings book, since you seem interested in the subject.

>--
>James Squire
>MDA Avionics Tools & Processes
>ja_squire@csehp3.mdc.com
>Opinions expressed here are my own and NOT my company's
>"one of these days I'm going to better myself by going to Knight school"
>"You'll be a web knight instead of a web page!"



pat
---------------
Patrick Rogers
progers@acm.org

Re: Question about the need for requeue as described in Rationale

[Robert A Duff]

In article <31E16C28.3BE2@csehp3.mdc.com>,
James A. Squire <m193884@CSEHP3.MDC.COM> wrote:
>How is this different from barrier conditions on protected entries and
>procedures?

It's not different.  The guards of an accept statement cannot reference
parameters of the entry call.  The barrier of an entry body cannot
reference the parameters of the entry call.

This illustrates the need for requeue.  (Well, not *need*; exactly, I
guess it illustrates the *usefulness* of requeue.)

Suppose you want to write a protected entry that accepts the caller
based on some condition, and that condition is based on the parameters
of the call, and also on the current state of the protected object.
Well, Ada doesn't support that, directly, so requeue gives you a way out
-- you can accept the call unconditionally, and then write some code
that checks all the relevant stuff, and either requeues-for-later, or
else does-it-now.

- Bob

Re: Question about the need for requeue as described in Rationale

[progers]

In <DuAyGJ.ACx@world.std.com>, bobduff@world.std.com (Robert A Duff) writes:
>In article <31E16C28.3BE2@csehp3.mdc.com>,
>James A. Squire <m193884@CSEHP3.MDC.COM> wrote:
>>How is this different from barrier conditions on protected entries and
>>procedures?
>
>It's not different.  The guards of an accept statement cannot reference
>parameters of the entry call.  The barrier of an entry body cannot
>reference the parameters of the entry call.
>
>This illustrates the need for requeue.  (Well, not *need*; exactly, I
>guess it illustrates the *usefulness* of requeue.)
>
>Suppose you want to write a protected entry that accepts the caller
>based on some condition, and that condition is based on the parameters
>of the call, and also on the current state of the protected object.
>Well, Ada doesn't support that, directly, so requeue gives you a way out
>-- you can accept the call unconditionally, and then write some code
>that checks all the relevant stuff, and either requeues-for-later, or
>else does-it-now.

That is an understatement, IMHO.  When one looks at the code required to
be safe from aborts and and cancellations -- which requires agent tasks --
requeue looks more like a necessity. True, that is overstatement, since 
it can be done without it, but realistically, no.


pat
---------------
Patrick Rogers
progers@acm.org

Re: Question about the need for requeue as described in Rationale

[James A. Squire]

Bo I. Sanden wrote:
>
> James A. Squire (m193884@CSEHP3.MDC.COM) wrote:
> : I am trying to understand what problem Requeue is trying to solve and
> : the above does not help me.  I can see from the example given how it
> : would be difficult to do the same thing in Ada83, but as I was trying to
> : describe the Ada83 problem that raised the need for this, I found I
> : couldn't come up with any good way of describing the problem.
>
> In my understanding, requeue is "needed" in Ada 95 primarily as part of
> the effort to replace by protected units what was sometimes called
> guardian tasks in Ada 83. Guardian tasks execute only while being
> called by other task, and made a typical Ada 83 program contain more
> tasks than the inherent concurrency of the problem would suggest.
> (Guardian tasks where there to restrict concurrency by enforcing
> synchronization of other tasks.)

I know.  The problem with this Ada83 solution is that it is "voluntary".
There is no enforcement unless tasks voluntarily submit to it.  That is
why I like the Ada95 solution so much.

> In Ada 83, Monitor is a guardian task and the wait is implemented by
> a statement accept Release nested within the body of accept Insist.

You're joking!  This is actually allowed in Ada?  I thought for sure it
was forbidden.  In fact, I thought that was one of the reasons why the
requeue statement was needed.  Now I'm really confused.

If you can have an accept within an accept, then why was the requeue
statement desirable?
--
James Squire
MDA Avionics Tools & Processes
ja_squire@csehp3.mdc.com
Opinions expressed here are my own and NOT my company's
"one of these days I'm going to better myself by going to Knight school"
"You'll be a web knight instead of a web page!"

Re: Question about the need for requeue as described in Rationale

[Robert A Duff]

In article <31E16AE7.2F7A@csehp3.mdc.com>,
James A. Squire <m193884@CSEHP3.MDC.COM> wrote:
>You're joking!  This is actually allowed in Ada?  I thought for sure it
>was forbidden.  In fact, I thought that was one of the reasons why the
>requeue statement was needed.  Now I'm really confused.

It is (and always was) allowed to have nested accept statements.
That is, both Ada 83 and Ada 95.  So long as it's not for the same
entry, or entries of the same family.

>If you can have an accept within an accept, then why was the requeue
>statement desirable?

Maybe I'm missing the point, but: If the server task is accepting within
an accept, then the server task is not available to other tasks that
want service.  On the other hand, if the server task creates tasks on
the fly, then that's a lot of complexity and (in most implementations)
inefficiency.  Or, more importantly, unpredictable efficiency (in
real-time apps).  Requeue is certainly not NEEDED in a formal sense, but
it sure does simplify and (in most implementations) make things faster.

I hope you saw my previous note about how requeue can be used for
preference control, and it's in the Rationale.  One way to think about
it is: suppose I wanted to refer to local data (of a protected object)
in a barrier (of a procedure of that object).  Well, that's illegal.
The workaround is to use requeue.

- Bob

Re: Question about the need for requeue as described in Rationale

[Bo I. Sanden]

James A. Squire (m193884@CSEHP3.MDC.COM) wrote:

: > In Ada 83, Monitor is a guardian task and the wait is implemented by
: > a statement accept Release nested within the body of accept Insist.

: You're joking!  This is actually allowed in Ada?  I thought for sure it
: was forbidden.  In fact, I thought that was one of the reasons why the
: requeue statement was needed.  Now I'm really confused.

: If you can have an accept within an accept, then why was the requeue
: statement desirable?
: --
As I see it, the advantage is that you can do away with the guardian 
task and accomplish what you want with a protected unit. You end up 
with one less thread and, arguably, a simpler program. The requeue
is primarily useful in protected units, in my experience.


---------------------------------------------------------------------
Dr. Bo Sanden					Author of:
Mail Stop 4A4				Software Systems Construction
George Mason University			    with examples in Ada
Fairfax, VA 22030-4444, USA		     Prentice-Hall 1994

        Tutorials on concurrent/real-time software design
                      at WAdaS and TRI-Ada
             http://www.isse.gmu.edu/faculty/bsanden
---------------------------------------------------------------------

Re: Question about the need for requeue as described in Rationale

[James A. Squire]

Robert Dewar wrote:
>
> James Squire said
>
> ""Indeed, the very astute reader might care to note that we can
> actually program this example in Ada 95 without using requeue
> at all." - Great! So why was it used if it wasn't needed?  For
> that matter, how can I do it in Ada 95 without requeue?"
>
> That strikes me as a bit odd. You often use features in programming
> languages that are not "needed", to improve the efficiency, readability,
> implementability, or simplicity of your code. After all it is obvious
> that the assignment statement in Ada is redundant in that any code you
> write using assignments could be written in an applicative style without
> assignments, but that's no reason to avoid assignments.

This is getting to be such a common occurrence that I wonder if I'm to
blame for being obscure.

My question was:  Why was this example used to illustrate in this
portion of the Rationale to illustrate why the requeue statement was
invented, if the example could also be done without using the requeue?
That struck me as a poor use of an example.

Someone else has since pointed out that a later section is the Rationale
was intended to serve that purpose and that this section (up front) was
simply meant to illustrate HOW it can be used.  I would nevertheless
argue that the text in this section (on Protected Types) does bring up a
limitation with tasking in Ada83 and then introduces the requeue
statement.  It seems quite logical to expect that the example would
clarify the need for the statement by showing something that could not
be done without it.  The example here didn't do that.

> A complex feature like requeue is never essential from a functionality
> point of view (though it might be critical on a given implementation
> from a performance point of view). Clearly anything in Ada 95 that can
> be written with requeue can be written without, but possibly at the
> expense of clarity and efficiency.

Then the Rationale should have made that clear.  I would have
understood.
--
James Squire
MDA Avionics Tools & Processes
ja_squire@csehp3.mdc.com
Opinions expressed here are my own and NOT my company's
"one of these days I'm going to better myself by going to Knight school"
"You'll be a web knight instead of a web page!"

Re: Question about the need for requeue as described in Rationale

[Jon S Anthony]

In article <31E16978.2E90@csehp3.mdc.com> "James A. Squire" <m193884@CSEHP3.MDC.COM> writes:

> My question was:  Why was this example used to illustrate in this
> portion of the Rationale to illustrate why the requeue statement was
> invented, if the example could also be done without using the requeue?
> That struck me as a poor use of an example.

In the particular case in question, I don't think it was there to
illustrate the why, only the what and how.


> Someone else has since pointed out that a later section is the Rationale
> was intended to serve that purpose and that this section (up front) was
> simply meant to illustrate HOW it can be used.  I would nevertheless

Right.

> argue that the text in this section (on Protected Types) does bring up a
> limitation with tasking in Ada83 and then introduces the requeue
> statement.  It seems quite logical to expect that the example would
> clarify the need for the statement by showing something that could not
> be done without it.  The example here didn't do that.

I suppose.  Shrug.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com

Re: Question about the need for requeue as described in Rationale

[James A. Squire]

Robert A Duff wrote:

> Right -- it's not intended to help you in that way.  This part of the
> "Rationale" isn't really rationale at all -- it's a tutorial, and is
> trying to explain how requeue works (as opposed to why it's in the
> language).

Well, that was what was confusing because it started talking about
limitations in Ada83.  I wasn't expecting a throw-away example to
immediately follow that.
--
James Squire
MDA Avionics Tools & Processes
ja_squire@csehp3.mdc.com
Opinions expressed here are my own and NOT my company's
"one of these days I'm going to better myself by going to Knight school"
"You'll be a web knight instead of a web page!"