Re: PRECOMPILATION

Re: PRECOMPILATION

[Tom Moran]

>AFAIK aonix is the only compiler which swaps fields in a record
I think Rational Apex also optimizes record layout unless you overide
with a rep clause.

Re: PRECOMPILATION

[Tom Moran]

>Are there precompilation instructions in Ada95,
>like in C (#ifdef,...etc) ? In other words, how can
>I set compilation conditions ?
  Most compilers are smart enough to delete code in a situation like:
  Sometimes : constant Boolean := False;
....
  if Sometimes then
    stuff;
  end if;
ie, if the optimizer knows "stuff" can never be executed, it will
simply drop it and the if-test.  
   Having worked on well known shrinkwrap software coded with the C
preprocessor, I would STRONGLY recommend against going that route.
Yes, it's just a tool, and judiciously used can be useful.  So's a
hydrogen bomb.

Re: PRECOMPILATION

[Tucker Taft]

Pascal MALAISE wrote:

> ...
> (1) AFAIK aonix is the only compiler which swaps fields in a record

Can you be more specific here?  Is this ObjectAda 7.0, or
earlier versions?  Under what circumstances does it "swap" fields?

> --
> Pascal MALAISE
> (priv) mailto:malaise@magic.fr
> (prof) mailto:malaise@fr.airsysatm.thomson-csf.com

Thanks.
-Tuck

-- 
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA

Re: PRECOMPILATION

[Tucker Taft]

=:-) Vincent wrote:
> 
> Are there precompilation instructions in Ada95,
> like in C (#ifdef,...etc) ? In other words, how can
> I set compilation conditions ?

Some Ada compilers have built in support for a preprocessor.
Some companies use the C preprocessor itself as a pre-pass
over the source.

However, we have had good experience with making the
unit of variation be the whole source file.  Typically
you can define a small number of primitive types and constants
which can isolate out the environment-specificity from all
other source files.  Then you only need to select which
version of this one source file you will use to switch from
one environment to another.  Our experience is that this approach
is dramatically more maintainable that spreading #ifdef's or
equivalent out all over the code.

> Thanks.
> 
> Vincent

-- 
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA

Re: PRECOMPILATION

[Tom Moran]

>and which is very usefull when you interface several languanges, several
>compilers
>on several architectures.
>Then, the ada definitions of the types are universal but the
>representation clauses
>are enclosed in precompilation options which can be set according to the
>architecture (32/64 bits) or the compiler
  Could you give an example?  If the data is to be passed between
architectures I would think there is a single "public" form, which
would always be the same and thus could always be described by the
same representation clause (even if for some compilers that rep clause
happened to merely confirm what that particular compiler does anyway).

PRECOMPILATION

[=:-) Vincent]

Are there precompilation instructions in Ada95,
like in C (#ifdef,...etc) ? In other words, how can
I set compilation conditions ?

Thanks.

Vincent

Re: PRECOMPILATION

[Larry Kilgallen]

In article <918556681.260459@dedale.pandemonium.fr>, "=:-) Vincent" <vb@bruker.fr> writes:
> Are there precompilation instructions in Ada95,
> like in C (#ifdef,...etc) ? In other words, how can
> I set compilation conditions ?

Conditional compilation is explicitly omitted from Ada to avoid
a host of problems (not the least of which is readability issues).

For situations where you would use the C preprocessor to set varying
bounds, a small package declaring the current values is appropriate.
At compile-time you can substitute a different rendition of that
package which has different limits.

One strange case often handled by the C preprocessor is the definition
of named constants.  If this is your interest, take a look at Ada
enumerated types.

The piece of Ada which most closely matches C "macros" would be
Ada "generics".  At a rough level, you can first think of them
as "macros with type checking".  There are certainly (unsafe)
thinks you can do with C macros that are not possible with Ada
generics, but then again C macros are a crude shadow of the
macro capabilities of a language like Bliss.

Larry Kilgallen

Re: PRECOMPILATION

[Marin David Condic]

=:-) Vincent wrote:
> 
> Are there precompilation instructions in Ada95,
> like in C (#ifdef,...etc) ? In other words, how can
> I set compilation conditions ?
> 
Ada doesn't generally like conditional compilation. However, the GNAT
compiler (and maybe others - I don't know if it has been adopted widely)
provides the "pragma Debug" and the "pragma Assert" which provide some
level of conditional compilation. Over usage can lead to difficult to
read code and make things harder to debug, so use this judiciously.

MDC
-- 
Marin David Condic
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
Ph: 561.796.8997         Fx: 561.796.4669
***To reply, remove "bogon" from the domain name.***

"Government is not reason. It is not eloquence. It is a force. 
Like fire, a dangerous servant and a fearful master."

    --  George Washington

Re: PRECOMPILATION

[Pascal MALAISE]

Larry Kilgallen wrote:

...
> set varying bounds
...
> definition of named constants.
...
> C "macros"
...

Agreed, Ada provides elegant solutions for that. 
But Vincent message seems to be about #ifdef, for which Ada has no
equivallent,
and which is very usefull when you interface several languanges, several
compilers
on several architectures.
Then, the ada definitions of the types are universal but the
representation clauses
are enclosed in precompilation options which can be set according to the
architecture (32/64 bits) or the compiler (aonix has a very specific
approach to record implementation (1) ):

#if defined (Linux)
for T use record ...
#elif defined (aonix)
...

The solution we use is to manage (archive) the sources as .common with
the
precompilation statements, preprocess them with 
cpp -D<operating system> -D<ada_compiler> [-traditional (2)]
to build the correct ada source.

Any better solution?

(1) AFAIK aonix is the only compiler which swaps fields in a record
(2) gnu cpp does not like unmatching quotes without this flag


-- 
Pascal MALAISE
(priv) mailto:malaise@magic.fr
(prof) mailto:malaise@fr.airsysatm.thomson-csf.com

Re: PRECOMPILATION

[Tom Moran]

>Is it legal Ada to write
>Sometimes : constant Boolean := False;
>if Sometimes then
>  -- representation clause
>else
>  -- another representation caluse of the same type
  No, since "if Sometimes then" can't appear in a declaration part.
You might be able to
if Sometimes then
  declare
     ..... do all the 32 bit declarations and usage thereof
  end;
else
  declare
     ... do the 64 bit version
   end;
end if;
if that doesn't generate other problems.  Tucker Taft's solution of
putting the variable stuff into different variants of a low level
package is what I've done in the past, though.

Re: PRECOMPILATION

[Tom Moran]

>As an example, just consider that a file size, of type "long" in C, can
>be
>implemented on 32 or 64 bits, depending on the operating system.
  And when it's passed from a 64 bit system to a 32 bit system what
happens to the extra 32 bits?  Or do you mean that sometimes the Ada
code talks to some C code that expects 32 bits, and other times the
same Ada must talk to a differently compiled version of the same C
code, but one that expects 64 bits?  In which case, why not
standardize on the Ada 32 bits (using a rep clause) and do the usual
preprocessor stuff for making a C program "portable"?

Re: PRECOMPILATION

[robert_dewar]

In article <36c0b371.307347@news.pacbell.net>,
  tmoran@bix.com (Tom Moran) wrote:
> >AFAIK aonix is the only compiler which swaps fields in a
> record. I think Rational Apex also optimizes record
> layout unless you overide with a rep clause.

Our view from the GNAT world is that such rearrangement
of fields causes much more trouble than it is worth, and
we quite definitely do NOT do such rearrangement!

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: PRECOMPILATION

[Corey Ashford]

Tom Moran wrote:
> 
> >AFAIK aonix is the only compiler which swaps fields in a record
> I think Rational Apex also optimizes record layout unless you overide
> with a rep clause.

Yes, or if you supply a "pragma convention(C, ...)" to the record type.

This latter method is a bit easier since record rep specs can be troublesome
to maintain.

- Corey

Re: PRECOMPILATION

[dennison]

In article <36c0b371.307347@news.pacbell.net>,
  tmoran@bix.com (Tom Moran) wrote:
> >AFAIK aonix is the only compiler which swaps fields in a record
> I think Rational Apex also optimizes record layout unless you overide
> with a rep clause.

I'm pretty sure I saw an Alsys SMART compiler doing it too.

T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: PRECOMPILATION

[Fraser Wilson]

I nearly cried when stt@averstar.com said:

>However, we have had good experience with making the
>unit of variation be the whole source file.  Typically
>you can define a small number of primitive types and constants
>which can isolate out the environment-specificity from all
>other source files.  Then you only need to select which
>version of this one source file you will use to switch from
>one environment to another.  Our experience is that this approach
>is dramatically more maintainable that spreading #ifdef's or
>equivalent out all over the code.

Indeed.  For various reasons, I maintain a small compiler that emits
assembler for either a 32 bit virtual processor that executes editor
extension commands, or an 8 bit 6502 (which means that I can finally
use Ada on my Commodore 64 -- actually, a C64 emulator, but close
enough).  To switch between targets, I put all the system dependent
stuff in subdirectories of the main source tree, and use compile
time flags to tell gnatmake to select the appropriate one.  Voila!
It's safe, and it's hard to create obscure bugs this way.

This works unbelievably better that mucking around with a preprocessor.
I remember those days when I used a bunch of #error directives to try
to find out why a particular file, the subject of a #include, wasn't
being read, and the culprit was usually some sort of #define coupled
with #ifdef stuff.  Pure evil.  Mind you, we were using Visual C++,
so we were kind of doomed from the start I think.

On a side note, who wants to target GNAT to MMIX?  There's some
interesting features on the chip that are impossible (or very dodgy)
to access from C, whereas Ada compilers can target them with ease.

cheers,
Fraser.
--
Fraser Wilson   |  700 East Middlefield Rd  |  Phone:  650 943 5270
Sr R&D Engineer |  Mountain View, CA 94043  |  Fax:    650 934 1227
Synopsys Inc    |  USA                      |  Email:  fraser@synopsys.com
           Ada, Linux, PowerPC: The Golden Triangle

Re: PRECOMPILATION

[Pascal MALAISE]

Tom Moran wrote:
>   Could you give an example?  If the data is to be passed between
> architectures I would think there is a single "public" form, which
> would always be the same and thus could always be described by the
> same representation clause (even if for some compilers that rep clause
> happened to merely confirm what that particular compiler does anyway).
The data has to be passed, within one architecture, from Ada to C and
vice versa,
through files, tcp/ip "messages", calls to libraries.
The code (Ada and C) has to run on several architectures, it provides,
by instance,
interface to UNIX calls.
As an example, just consider that a file size, of type "long" in C, can
be
implemented on 32 or 64 bits, depending on the operating system.

Clear?
-- 
Pascal MALAISE
(priv) mailto:malaise@magic.fr
(prof) mailto:malaise@fr.airsysatm.thomson-csf.com

Re: PRECOMPILATION

[Pascal MALAISE]

Tom Moran wrote:
> 
> >Are there precompilation instructions in Ada95,
> >like in C (#ifdef,...etc) ? In other words, how can
> >I set compilation conditions ?
>   Most compilers are smart enough to delete code in a situation like:
>   Sometimes : constant Boolean := False;
> ....
>   if Sometimes then
>     stuff;
>   end if;
> ie, if the optimizer knows "stuff" can never be executed, it will
> simply drop it and the if-test.
>    Having worked on well known shrinkwrap software coded with the C
> preprocessor, I would STRONGLY recommend against going that route.
> Yes, it's just a tool, and judiciously used can be useful.  So's a
> hydrogen bomb.

Is it legal Ada to write
Sometimes : constant Boolean := False;
if Sometimes then
  -- representation clause
else
  -- another representation caluse of the same type
end if;

I think the error will be detected far before the optimizer is involved.

-- 
Pascal MALAISE
(priv) mailto:malaise@magic.fr
(prof) mailto:malaise@fr.airsysatm.thomson-csf.com

Re: PRECOMPILATION

[Pascal MALAISE]

Tom Moran wrote:
> 
> >As an example, just consider that a file size, of type "long" in C, can
> >be
> >implemented on 32 or 64 bits, depending on the operating system.
>   And when it's passed from a 64 bit system to a 32 bit system what
> happens to the extra 32 bits?
This is absolutely out of question.

> Or do you mean that sometimes the Ada
> code talks to some C code that expects 32 bits, and other times the
> same Ada must talk to a differently compiled version of the same C
> code, but one that expects 64 bits?
Not realy. It is just a matter of the same source ported on several
operating systems. At this stage, we don't need these different portings
to interact.
We want each of them to run, each of them on a different OS.
But each of them is Ada and C and use the OS, and some OS/architecture
implement
long on 64 bits and some others implement long on 32 bits.
but the C library calls use the "long" type anyway:
int fseek( FILE *stream, long offset, int whence);
We need to provide "portable" ada interface for such call, so, in the
exported
ada interface, we define the ada MY_LONG_INTEGER type on 64 or 32 bits,
just
according to what the /usr/include/sys/type.h does.

> In which case, why not
> standardize on the Ada 32 bits (using a rep clause) and do the usual
> preprocessor stuff for making a C program "portable"?
On one architecture, the same constraint on a file size applies to a
pure C program
as to an Ada application.


-- 
Pascal MALAISE
(priv) mailto:malaise@magic.fr
(prof) mailto:malaise@fr.airsysatm.thomson-csf.com

Re: PRECOMPILATION

[robert_dewar]

In article <36C335C9.7932690@magic.fr>,
  Pascal MALAISE <malaise@magic.fr> wrote:
> We need to provide "portable" ada interface for such
> call, so, in the exported
> ada interface, we define the ada MY_LONG_INTEGER type on
> 64 or 32 bits, just
> according to what the /usr/include/sys/type.h does.

This seems a completely bizarre approach, why not simply
use interfaces.c.long, as clearly intended by the language
design?

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: PRECOMPILATION

[Pascal MALAISE]

robert_dewar@my-dejanews.com wrote:

> This seems a completely bizarre approach, why not simply
> use interfaces.c.long, as clearly intended by the language
> design?
In Ada83?
-- 
Pascal MALAISE
(priv) mailto:malaise@magic.fr
(prof) mailto:malaise@fr.airsysatm.thomson-csf.com

Re: PRECOMPILATION

[Samuel Mize]

Tucker Taft <stt@averstar.com> wrote:
> =:-) Vincent wrote:
>> 
>> Are there precompilation instructions in Ada95,
>> like in C (#ifdef,...etc) ? In other words, how can
>> I set compilation conditions ?
...
> However, we have had good experience with making the
> unit of variation be the whole source file.

Of course, this may affect your design. You'll have to provide
some higher-level package that interacts with the system, instead
of just embedding code to do low-level system things throughout
your program.

This is disquieting to someone with a C-style design mindset, but
is expected by an Ada-style mindset.  I'm not denigrating EITHER
mindset.  I do point out that C people write large, involved,
nested #ifdef structures instead without a second thought because
that's "normal" to them.  The Ada approach seems like "a lot of
bother" -- they see the "extra" work in Ada, but don't observe
how much it reduces the coding burden in other areas.

If you prefer, you can maintain the platform-specific packages in
a "pre-Ada" form, with conditional compilation commands, and use
a preprocessor to generate your platform-specific versions.  IIRC,
Rational has a fairly nice implementation of this.

A couple of points that may help people with C-style preprocessor
experience:

C-experienced people probably expect platform-specific issues to be
shot through the whole program, like cancer.  For instance, if a
system call's parameter can be 64-bit or 32-bit depending on the
platform, you may have #ifdefs around every call to it, and every
declaration of a variable to use as a parameter for it.

So they fear the spectre of having to maintain parallel files for
a huge number of units, and getting their logic out of synch.

This is greatly reduced by using Ada's strong typing and separate
compilation capabilities.  Once you've set up a fairly small
platform interface, all the rest of the source code is invariant.
But it takes a bit of experience to really believe that.

Also, a C-experienced developer feels he can look at just one
file and make sure that each element has an alternative defined
for each platform.

It seems so simple in theory...

Of course, if there are dependencies between elements, you wind up
with nested #ifdefs, and elements which exist in some configurations
but not in others.  You wind up with nightmares where, for instance,
a function should have been declared to return long_int on platform
X, but X didn't get into the #ifdef, so the compiler assumes it
returns an integer, and everything links and runs.  Badly.

Again, Ada largely takes care of this concern.  If you missed an
element that you need in one of your platform-specific files, the
program won't compile.  It's actually easier to maintain most
cross-platform dependencies in Ada, once you adapt your design to
the Ada mindset.

Best,
Sam Mize

-- 
Samuel Mize -- smize@imagin.net (home email) -- Team Ada
Fight Spam: see http://www.cauce.org/ \\\ Smert Spamonam

Re: PRECOMPILATION

[robert_dewar]

In article <7ahor8$otv@news1.newsguy.com>,
  Samuel Mize <smize@imagin.net> wrote:

<<nice post on preprocessing>>

Nice post Sam! I think this captures the issues nicely.
Note that there certainly is nothing illegal or immoral
about using a preprocessor in Ada if it is the right way
to go. GNAT provides gnatprep, and some people find it
very useful, but usually the structuring of target
dependent programs in Ada is best done without this tool.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: PRECOMPILATION

[Rakesh Malhotra]

Samuel Mize wrote:
> 
> Tucker Taft <stt@averstar.com> wrote:
> You'll have to provide
> some higher-level package that interacts with the system, instead
> of just embedding code to do low-level system things throughout
> your program....
>
> C-experienced people probably expect platform-specific issues to be
> shot through the whole program, like cancer.  ...
>... [snipped]
> So they fear the spectre of having to maintain parallel files for
> a huge number of units, and getting their logic out of synch.
> ... [snipped]
> This is greatly reduced by using Ada's strong typing and separate
> compilation capabilities.  Once you've set up a fairly small
> platform interface, all the rest of the source code is invariant.
> But it takes a bit of experience to really believe that.
> ... [snipped]
> Again, Ada largely takes care of this concern.  If you missed an
> element that you need in one of your platform-specific files, the
> program won't compile.  It's actually easier to maintain most
> cross-platform dependencies in Ada, once you adapt your design to
> the Ada mindset.
> 
Thanks for the enlightening explanation above.  I have not done any
cross-platform coding in C or Ada but have often wondered how one would
do the equivalent of the C preprocessor stuff in Ada.

I have ported bought-in 3rd party libraries written in C to my platform
(e.g. a TCP/IP library for an embedded platform).  You are correct in
saying that the cross-platform stuff (e.g. size of a variable) is shot
through the whole program and it makes reading the code quite
difficult.  In the libraries I bought it was quite a nightmare till,
after staring at the code for a couple of weeks, I started to understand
all the dependencies.

Would it be possible to give an Ada example of how you would do what you
have suggested in your message above  ? i.e. what kind of things does
one put into the platform specific packages, does one not land up with
having to maintain many such packages versus just 1 file in the C case
etc ?    Some code that highlights your explanation will help.

Thanks
Rakesh

Re: PRECOMPILATION

[Samuel Mize]

Rakesh Malhotra <rakesh.malhotra@pop.safetran.com> wrote:
> Samuel Mize wrote:
[about preprocessors forcing you to address portability issues
 throughout your code]

> Would it be possible to give an Ada example of how you would do what you
> have suggested in your message above  ? i.e. what kind of things does
> one put into the platform specific packages, does one not land up with
> having to maintain many such packages versus just 1 file in the C case
> etc ?    Some code that highlights your explanation will help.

I don't have an example handy.  I assume there would be some useful
tutorial or example material at www.adahome.com or the ACM SigAda
web site.

Here's a sketch.

Suppose you want to use a system call to get the current time.
As I recall, there are at least three different "standard" Unix
OS calls to do this, each of which uses a different data structure.
A given Unix box will provide at least one of these.  And I assume
Windows does something different.

An Ada programmer would decide what representation of time is best
in this program, and write a package that makes the system call,
extracts time to the desired representation, and returns it.  Thus,
the entire program is insulated from the differences between systems,
except inside one package.

(That package being Ada.Calendar, in this example.)

Now, a sterotypical C programmer believes that preprocessor directives
are much more efficient than procedure calls.  So he would use #ifdefs
to select the right call and data structure.  If he is really worried
about performance, he'll put the #ifdefs in-line in the code.  If he
is a little less worried about performance, he'll put the #ifdefs into
a macro that makes the right call and puts the current time into a
global data structure.

The Ada programmer will trust the compiler to optimize the code,
instead of trying to do so by hand.  This is aided by pragma Inline,
which tells the compiler it may treat a procedure definition as if it
were a preprocessor macro, if convenient.

I hope this is enough to give you an idea.  Look for tutorials and
books on portability, and on design encapsulation.  The book "Ada
Quality and Style" has a section on portability, you may find that
useful.  AQ&S is available electronically for free, you can find it
via adahome, one specific URL is:

  http://wuarchive.wustl.edu/languages/ada/ajpo/docs/style-guide/
    95style/html/cover.html

Best,
Sam Mize

-- 
Samuel Mize -- smize@imagin.net (home email) -- Team Ada
Fight Spam: see http://www.cauce.org/ \\\ Smert Spamonam

Re: PRECOMPILATION

[Robert A Duff]

Samuel Mize <smize@imagin.net> writes:

> C-experienced people probably expect platform-specific issues to be
> shot through the whole program, like cancer.  For instance, if a
> system call's parameter can be 64-bit or 32-bit depending on the
> platform, you may have #ifdefs around every call to it, and every
> declaration of a variable to use as a parameter for it.

Yeah, I've seen lots of code like that.  But it seems like a bad way to
do things, no matter *what* language you're using.

- Bob
-- 
Change robert to bob to get my real email address.  Sorry.