Re: ifdef replacement for GNAT

Re: ifdef replacement for GNAT

[John T Vegezzi 312C M 237110]

For those interested, gnatprep is a preprocessing utility included in
the GNAT distribution which will support #ifdef type conditional
compilations.  gnatprep produces an output file which forms the input to
the compiler.  It is not as transparent as the C preprocessor - See the
man page for details.

-- 
John T Vegezzi 
(314) 233-3589 
j_vegezz@tolstoy.mdc.com

Re: ifdef replacement for GNAT

[Robert Dewar]

John said

<<For those interested, gnatprep is a preprocessing utility included in
the GNAT distribution which will support #ifdef type conditional
compilations.  gnatprep produces an output file which forms the input to
the compiler.  It is not as transparent as the C preprocessor - See the
man page for details.
>>

I have no idea what "not as transparent as the C preprocessor" means, but
note that gnatprep, unlike the C preprocessor, understands Ada tokens and
will pass through arbitrary Ada text without difficulties, unlike the
C preprocessor which will choke on some constructs (such as attributes)
because they do not look like C tokens.

Re: ifdef replacement for GNAT

[Robert Dewar]

Dirk asks

<<How is an Ada project (GNAT) being kept portable among various Unices
and say, Win32? Assume there is something special to be done in all
environments. Without using a nonstandard tool like gnatprep that is.
>>

The Steelman requirements prohibited the inclusion of preprocessing in
the Ada language, which may surprise you. What may surprise you more is
that I and many others think this is a *good thing*.

We provide gnatprep for our users, but we do NOT use it ourselves in
the GNAT system.

The proper approach for achieving target dependence is to follow two steps

  (a) encapsulte the target dependence down to the minimum level

  (b) Provide separate target dependent units for these remaining functions

This has worked well in the GNAT project. We do use some conditional
compilation in the small parts of the runtime written in C (probably 
conditions are overused here ...)

Indeed, the use of conditional compilation has many disadvantages:

1. It tends to run amok. People throw in #ifdef's without a moment's thought
   about how to make the code more common, and avoid the need for target
   dependent conditionalization.

2. Since deleted code is not syntax or semantic checked, you don't even know
   that your code will compile correctly for different combinations of checks.

By avoiding the inclusion of preprocessing facilities in the language, you
discourage their use. This discouragement is definitely a good thing.

Yes, people used to C find this surprising, but I have worked on several
large Ada systems that managed just fine in dealing with target dependencies
without resorting to conditional compilation.

Going back to GNAT, the front end is almost entirely target independent.

The backend is much more target independent than you might suppose. The
great majority of target dependence is encapsulated in the configuration
file, there is one such file for each target.

The runtime is mostly target dependent, with the exception of five files
that provide the low level tasking interface. These files have multiple
versions for different targets.

Re: ifdef replacement for GNAT

[Dirk Zoller]

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

> John said
> 
> <<For those interested, gnatprep is a preprocessing utility included in
> the GNAT distribution which will support #ifdef type conditional
> compilations.  gnatprep produces an output file which forms the input to
> the compiler.

The designers of Ada have thought of so many things. Very
impressive. Of the procedural languages I know it is the one where I
can express the most in terms of the plain standard language.

With the exception of nonstandard stuff imposed on me by the
environment I'm programming for. These preprocessor conditionals are
missing. Or am I missing something?

How is an Ada project (GNAT) being kept portable among various Unices
and say, Win32? Assume there is something special to be done in all
environments. Without using a nonstandard tool like gnatprep that is.

-- 
Dirk Zoller <Dirk.Zoller_@_rhein-main_._netsurf_._de>
Remove '_' from the e-mail adress.

Re: ifdef replacement for GNAT

[nabbasi]

In article <dewar.892261504@merv>, dewar@merv.cs.nyu.edu says...

>The proper approach for achieving target dependence is to follow two steps
>
>  (a) encapsulte the target dependence down to the minimum level
>
>  (b) Provide separate target dependent units for these remaining functions
>

Prof. Dewar, let me try to see what you mean by point (a) above by 
an example (I am also one of those who learn better by examples, for no
other reason other than to be clear on what things mean):

Lets assume we have UNIX and VMS (for the purpose of this example). 

Lets assume one wants to create a child process. on UNIX one calls fork(), 
on VMS one calls vfork(). There are nowadays 3 main methods of how to
do this.

first solution
=============

cc -DUNIX program.c
 
program.c
+--------------------------------------+
| #if defined(VMS)                     |
|     status = vfork()                 |
| #else                                |
| #if defined(UNIX)                    |
|      status= fork()                  |
| #else                                |
| #error "unsupported platform"        |
| #endif /* UNIX */                    |
| #endif /* VMS */                     |
+--------------------------------------+

Now, I do not like the above myself, for the same reason you say, it also makes
the code hard to read and maintain.

second solution
================
The other approach is to do this:

cc -DUNIX program.c

program.c
+-----------------------------+
|#include "program.h"         |
|  status=  GENERIC_fork();   |
+-----------------------------+

program.h
+---------------------------------+
| #if defined(VMS)                |
| #define GENERIC_fork vfork      |
| #else                           |
| #if defined(UNIX)               |
| #define GENERIC_fork fork       |
| #else                           |
| #error "unsupported system"     |
| #endif                          |
| #endif                          |
+---------------------------------+

This above is a little better since the main source code is not cluttered, and
the ifdef stuff is kept in one header file, but it  also suffer from some of
the same problems. It also has an additional problem which is against 
the "what you see is what you get". i.e. one looks at the source code in
program.c, they do not know actually what the call will turn up to be 
without looking around in some other header files to find out.

(another variation on the above is to use a compiler directive (as in
-Dfork=vfork) to make replacement of all "fork" tokens to become "vfork".
This assumes that the original files used the fork call. This also is a bad
solution, as it is confusing and is not what you see is what you get when
looking at the code. but can be useful to eliminate the need to edit many
files manually or add ifdef everywhere where the call is made.

third solution
==============

have one file (package in Ada terms) that contains all the specific
platform functions that are not command to other platforms. so in the
above example we can have

    program.c                   VMS.c                    UNIX.c
+---------------------------+  +-------------------+   +---------------------+
|                           |  |#include "unistd.h"|   |#include "unistd.h"  |
| #include "program.h"      |  |int GENERIC_fork() |   | int GENERIC_fork()  |
| status = GENERIC_fork()   |  | {                 |   |{                    |
|                           |  |   return vfork(); |   |   return fork();    |
+---------------------------+  | }                 |   |}                    |
                               +-------------------+   +---------------------+

program.h
+--------------------------+
| int GENERIC_fork();      |
+--------------------------+

Now, this is better.


When on UNIX, the makefiles will link the common source code against
the UNIX specific files, and when on VMS the makefiles will be directed
to link against the VMS specific platform dependent file(s) as in:

on VMS:
cc -c VMS.c
cc program.c VMS.o

on UNIX:
cc -c UNIX.c
cc program.c UNIX.o

This solution I like the most of the three. first, the common source code
is free of ifdef stuff. and so easier to read and maintain. it also easy
to find where all the platform specific stuff is located. the platform
specific file(s) should also be named to reflect the platform, but this
is minor point.

The only problem with the third solution is that one needs to design
the program from the start with this in mind. i.e. any operation  which
could possibly be different on different platforms must be not called
directly from the "common" body of the program, but instead wrap it and
make the platform specific calls from the platform specific module(s).

many time, people do not do this (how many of us who code in c/c++ wraps
a fork() call for example? or an open() or etc..etc.., but later on,
when one wants to port the program to a different platform, and then find
out that that call is not exactly the same as on the first platform, the 
easy and the quickest way will be to resort to solution 1 above, 
in particular when the program needs to be done by Monday morning :)

I think the hardest thing is to foresee in advanced what the platform
specific calls will be. or what the platform specific components will be.

for example reading a directory file I do not think is available on windows
as is done on UNIX. and so this have to be wrapped (or abstracted).

I assume what you meant by point (a) is something along the lines of
the third solution above. right?

I am not sure about your point (b) above, since it seems to be folded into
(a), at least in the way I thought about (a). 

thanks,
Nasser

Re: ifdef replacement for GNAT

[Larry Kilgallen]

In article <dewar.892261504@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) writes:

> The proper approach for achieving target dependence is to follow two steps
> 
>   (a) encapsulte the target dependence down to the minimum level
> 
>   (b) Provide separate target dependent units for these remaining functions

So is the build variance then done by maintaining multiple control files for
your "Make" utility, or do you have a tool to generate those on the fly?
(I realize one might be able to learn this by studying GNAT source, but
I am looking for an easy answer.  I promise it is not homework from a
class :-).

Larry Kilgallen

Re: ifdef replacement for GNAT

[Larry Kilgallen]

In article <6gn4q1$ee6@drn.newsguy.com>, nabbasi@earthlink.net writes:

> I think the hardest thing is to foresee in advanced what the platform
> specific calls will be. or what the platform specific components will be.
> 
> for example reading a directory file I do not think is available on windows
> as is done on UNIX. and so this have to be wrapped (or abstracted).

This does not seem so hard to me if you start with multiple operating
systems not particularly related to each other (i.e., not all Unix, not
all Windows, etc.).  After you have found the operations which differ
among Solaris X86 (always pick the smaller subset), MicroVMS (yes, it
had Ada), Windows 3.1, OS/2 and MVS, you have minimized your future work
in discovering new areas which are uncomon.

The worst thing is to start with one operating system and presume that
all others are like it.  Windows programmers and Unix programmers seem
to be most prone to this pattern; the rest of us know from the start that
we are in a minority :-).

Larry Kilgallen

Re: ifdef replacement for GNAT

[Geert Bosch]

Dirk Zoller <duz> wrote:
 ``How is an Ada project (GNAT) being kept portable among various Unices
   and say, Win32? Assume there is something special to be done in all
   environments. Without using a nonstandard tool like gnatprep that is.''

Very easy: put system dependent stuff in a package with a well defined
interface (spec) and use different bodies for different systems.
You'd like to make this system dependent part as small as possible,
but this is a good design principle anyway. 

When you want to add a new system you just write a new implementation
for the spec for system dependent stuff and that's it. No more hunting
#ifdefs in dozens of files and breaking other code in the process...

Regards,
   Geert

Re: ifdef replacement for GNAT

[raw]

In article <dewar.892261504@merv>,
  dewar@merv.cs.nyu.edu (Robert Dewar) wrote:
> The Steelman requirements prohibited the inclusion of preprocessing in
> the Ada language, which may surprise you. What may surprise you more is
> that I and many others think this is a *good thing*.

The second statement did not surprise me; the first one did.  I looked at
Steelman at http://www.adahome.com/History/Steelman/steelman.htm
but I'm still not sure where it prohibits preprocessing.

It lists reliability and maintainability among the goals, which would imply
this but is not very specific.  It talks about conditional compilation; in
6C, it says "Only the selected branch shall be compiled when the
discriminating condition is a translation time expression." (regarding
the conditional control structure), so it would seem that Ada doesn't
need #ifdef because it has if.

I'd guess you meant the statement from 13G that "Translators shall do
full syntax and type checking" which would rule out text preprocessing
(given the various requirements on syntax and types); is this correct?

--
MJSR

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/   Now offering spam-free web-based newsreading

Re: ifdef replacement for GNAT

[Haug Buerger]

Geert Bosch <geert@gonzo.sun3.iaf.nl> wrote:
...
>Very easy: put system dependent stuff in a package with a well defined
>interface (spec) and use different bodies for different systems.
>You'd like to make this system dependent part as small as possible,
>but this is a good design principle anyway.

Can i use gnatmake with this approach? If yes how?

Haug

--

For email use haug@zesi.ruhr.de !

Re: ifdef replacement for GNAT

[Richard Kenner]

In article <6gn4q1$ee6@drn.newsguy.com> nabbasi@earthlink.net writes:
>Prof. Dewar, let me try to see what you mean by point (a) above by 
>an example (I am also one of those who learn better by examples, for no
>other reason other than to be clear on what things mean):
>
>Lets assume we have UNIX and VMS (for the purpose of this example). 
>
>Lets assume one wants to create a child process. on UNIX one calls fork(), 
>on VMS one calls vfork(). There are nowadays 3 main methods of how to
>do this.

Let me give my "take" on this, which is that you can't give a
meaningful answer based on only *one* difference.  If everything is
portable except for one thing, it's hard to make a strong case about
which way to handle that single non-portable thing.

But there isn't just one thing; there are many.  And there are also
many more than two systems.  So the whole point is to establish a
methodology for handling the non-portable things and you can't 
illustrate that well with one thing and two systems.

One way you do it is by abstracting them.  You make a list of each of
the areas of non-portability and find an interface that works for all
systems for each of them.  Then you can have one module that handles
all the non-portablilities.

Another is to try to find commonalities and conditionalizations that
aren't necessarily system dependent.  So suppose you find something
that can be done one of two ways (e.g., big or little endian).  Rather
than conditionalizing each place with "systems A, B, C, D, and E are
this way".  Say "big endian is this way and little endian is this
way".  Then have a configuration file for each system saying which of
the attributes is true for it.

Very roughly speaking, the first approach is typically the way GNAT
and GCC handles *host* dependencies and the latter is the way it
handles *target* dependencies.

Re: ifdef replacement for GNAT

[Michael F Brenner]

Robert > The proper approach for achieving target dependence is 
       > to follow two steps
       >   (a) encapsulate the target dependence down to the minimum level
       >   (b) Provide separate target dependent units for these 
       >       remaining functions

       > ... multiple implementations for different targets ...

These are good steps. However, there still needs to be a need for
conditional compilation for three reasons. 

First, multiple implentations (function bodies or package bodies, say) 
for different targets IS conditional compilation.

Second, this kind of conditional compilation is not supported
within the language, even though it is required for multiple
targets. There is no question of whether conditional compilation
is needed or used. The question is whether the conditional
compilation that we have to do is standard across compilers
and tools. Currently the required conditional compilation is
not standardized, and each compiler does it its own way. This is
a serious language issue that is easily and cheaply fixed.

Third, there is a limit to step (a), encapsulation. The language permits
an efficient IF FALSE or IF MACHINE=DOS or IF INTERRUPT_LEVELS=15 to 
be optimized away at runtime, but only in the executable portion of the
code. In the declarations the following types of target dependent
code cannot be handled within the language, but must resort to
non-standard ways of managing the visible parts, not just the
implementations: 
    A. Different pragmas or pragma arguments
    B. Different representation specifications (bit lengths & starts)
    C. Different types (signed versus unsigned)
    D. Different implementations of points (integer versus record)
    E. Different interrupt locations for interrupt handlers 
    F. Different ways of addressing virtual memory
    G. Different ways of addressing absolute memory
    H. Different data structures for accomplishing software interrupts
    I. Different memory-mapped locations for hardware devices
    J. Different ways of handling integers larger than integer'last 
    K. Number of levels of pointers required to interface to C vs. Java
    L. Different elements in records for interface to different
       operating systems 

Other things like URL formats, bit ordering, filenames, 
end-of-line-string, end-of-file-string, maximum filename,
temporary directory location, directory separator character,
byte ordering, numerical and string constants, bit patterns
for interrupts, etc., can be done with a configuration package.  

Looking over the code here written that requires conditional 
compilation, the following suggestion comes to mind for Ada 2005X:

Add into the Ada language a package streaming_IO, which has nothing
to do with stream_IO, but instead has the following characteristics.

On INPUT Ada will set up reliable streams of bytes from the following 
sources: directories, virtual memory, absolute memory, serial ports,
parallel ports, SCSI ports, key-down presses, key-up presses, mouse-down
presses, mouse-up presses, mouse movements (sampled at a selectable
rate), screen touches, keypad key-down presses, keypad key-up presses, 
analog audio input, MIDI, Ethernet packets, standard input, disk files,
URLs on the Net, sense lights, tablet control stick, joystick, and 
so forth for all input ports on the computer. 

On OUTPUT Ada will set up reliable streams of bytes to the following
sinks: directories, virtual memory, absolute memory, serial ports,
parallel ports, SCSI ports, sense lights, screen text, screen pixels,
speaker, sound boards, MIDI, Ethernet, standard output, disk files,
URLs on the Net, lighting up a character of a given size in a given
font at a given screen location, etc., for all output ports on the computer.

These should be done in such a manner that the user can add
additional device streaming_IO streams.

The lack of this kind of reliable streaming is what caused the
problems with windowing systems today: over-reliance on mouse
movement and mouse icon selection, inversion of the main program
so that the Windowing System call the program when it detects
an input rather than the program taking from whatever stream it
desires, and the difficulty of programming windowing systems
because (in order to become the main program) the windowing system
must restrict the application from doing most of the things it
wants to do.

There is a strong relationship between these two problems: 
the lack of conditional code in Ada and the need for device streaming.
They are related because almost all of the conditional code is
the result of programming reliable device drivers for 
device streams. The need for conditional compilation of any
kind is reduced significantly when the user has direct access
to the byte streams coming in from files, ports, directories,
URLs, and keyboard interrupts, and can light up pixels on the screen in a 
portable manner. 

If Ada standardizes a realtime speed way of directly getting to 
the hardware, there would probably be no reason for desiring
any conditional compilation (outside of the built-in generic
instantiation for switching types and their representations),
CASE statements and IF statements.

The Unix, DOS, Windows 3.1, Windows 9x, Windows NT, Posix, Mac HFS,
Solaris, VMS, etc., systems are close enough to permit these streams
to be implemented in a standard manner with realtime response. VMS
files would NOT go through the record manager, but would be channel
programmed so they are given to the user as a stream of bytes, of 
course. And those operating systems with defects (for example, 
do not support key down-strokes) would simply never have any inputs
on those streams. Defective hardware (for example, missing 
parallel port or those that use and ISP instead of being hot
on the Net) would have an exception: raise missing_hardware.

There are approximately 10,000 things that Ada has to do to 
support applications, divided into various device streams and 
various data structures. It should be our goal to have all these
10,000 things implemented as external packages by 2005, so that
at that time, the revision of the language can concentrate on
fixing the small number of efficiency bugs in the language design,
eliminating the last of the rational reasons for avoiding the use
of Ada.

Re: ifdef replacement for GNAT

[Larry Kilgallen]

In article <6gt6ij$q6o@top.mitre.org>, mfb@mbunix.mitre.org (Michael F Brenner) writes:

> These are good steps. However, there still needs to be a need for
> conditional compilation for three reasons. 

Regardless of the presence of reasons for supporting inline conditional
compilation, I believe the current state of affairs is the correct one,
due to the overwhelming strong reason for _not_ supporting it -- namely
that it will get abused.  Take a look at any multi-platform C program.

Larry Kilgallen

Re: ifdef replacement for GNAT

[Aaro Koskinen]

haug@localhost.ruhr.de (Haug Buerger) writes:
> Geert Bosch <geert@gonzo.sun3.iaf.nl> wrote:
> >Very easy: put system dependent stuff in a package with a well defined
> >interface (spec) and use different bodies for different systems.
> >You'd like to make this system dependent part as small as possible,
> >but this is a good design principle anyway.
> 
> Can i use gnatmake with this approach? If yes how?

Yes, for each target create a directory which contains the target
dependent bodies. When compiling, call gnatmake with parameter -Idir,
where the dir is the directory of the target to which you are
compiling.
-- 
Aaro Koskinen, aaro@iki.fi, http://www.iki.fi/aaro

Re: ifdef replacement for GNAT

[Jean-Pierre Rosen]

Robert Dewar a �crit dans le message ...
>Dirk asks
>
><<How is an Ada project (GNAT) being kept portable among various Unices
>and say, Win32? Assume there is something special to be done in all
>environments. Without using a nonstandard tool like gnatprep that is.
>>>
>
>The Steelman requirements prohibited the inclusion of preprocessing in
>the Ada language, which may surprise you. What may surprise you more is
>that I and many others think this is a *good thing*.
>
>We provide gnatprep for our users, but we do NOT use it ourselves in
>the GNAT system.
>
>The proper approach for achieving target dependence is to follow two steps
>
>  (a) encapsulte the target dependence down to the minimum level
>
>  (b) Provide separate target dependent units for these remaining functions
>

Note that library packages renaming can be handy in managing this approach.
You define for example:

package My_Interface_Unix is...
package My_Interface_Win32 is...

and then:
with My_Interface_Win32;
package My_Interface renames My_Interface_Win32;

and use My_Interface all over the place.

If you change operating system, you only need to change the renaming in only
one place. Not more work than changing a #define.
--
----------------------------------------------------------------------------
                  J-P. Rosen (Rosen.Adalog@wanadoo.fr)
      Visit Adalog's web site at http://perso.wanadoo.fr/adalog

Ada Programming Environment [was ifdef replacement for GNAT]

[Nick Roberts]

Aha, but Larry, you miss Michael's point: the Ada standard does not
prescribe the way in which different 'versions' of code (e.g. package
bodies) are selected for compilation into a version of a program. So
supplier A provides one method, supplier B provides another, and so on. This
is the sort of anarchy which Ada was intended to prevent.

Of course, this issue goes beyond just conditional compilation, to the
(fairly well discussed) issue of the Ada programming/development environment
(APSE or whatever).

(Along with others) I would suggest that one of the broad issues Ada 200X
should address is the issue of the programming environment. Whilst,
doubtless, much would be impossible to standardise, I feel that much could
be; and it would surely be a great boon to Ada programmers everywhere to
have even a partially standardised environment to work in.

I realise there are things like COE out there, but they all have problems
(as regards wider implementation). And, with respect, they are not written
by the talented people who created Ada (83 & 95), nor are they subject to
the same rigorous review process.

Michael's discursion on the subject of I/O (a classic Brennerism (MFB is
_unique_)) is (to me) fascinating. Mentioning no names, there are some
real-time operating systems which use a central 'software bus' in a way very
similar to what Michael describes. And the idea works provably well, too. A
lesson there, I feel sure.

For those of you who are not studied in Turing (shame on you!:-), it is
perhaps interesting to note that every program is just a means of
translating an input stream into an output stream. Some programs can even do
it backwards ;->

--
Nick Roberts, Croydon, UK
Nick.Roberts@dial.pipex.com

Larry Kilgallen wrote in message <1998Apr13.124600.1@eisner>...
|In article <6gt6ij$q6o@top.mitre.org>, mfb@mbunix.mitre.org (Michael F
Brenner) writes:
|
|> These are good steps. However, there still needs to be a need for
|> conditional compilation for three reasons.
|
|Regardless of the presence of reasons for supporting inline conditional
|compilation, I believe the current state of affairs is the correct one,
|due to the overwhelming strong reason for _not_ supporting it -- namely
|that it will get abused.  Take a look at any multi-platform C program.