limitations on optimizers for conditional compilation

limitations on optimizers for conditional compilation

[Emery]

Armin points out that it is perfectly legal to do conditional
compilation of statements based on some (constant) boolean value.
This is something I'd expect a good compiler to do, and a technique
that I have used (sending prayers to the God of Compilers that my
compiler was "good").   

Where this approach fails, though, is in non-statements such as type
declarations.  It would be nice to have support for this:
	type foo_bar is 
	  record
	    x : integer;
#ifdef VAX
	    y : float_64;
#elsif IBM_PC_WITH_8087
	    y : IEEE_float;
#endif
	end record;

I suspect that the very clever person could use variant records for
this example, but I also suspect that it wouldn't take much to come up
with type definitions where a variant record approach wouldn't work.

Using these ("constant type") variant records would probably make the
program harder to read, because it wouldn't be clear to the maintainer
if this was a variant record object (or subtype) based on some 'real
variant) or based on some conditional compilation feature.  Objects
are often widely separated from their declaration, compared to
(optimizable) conditional compilation statements.
				dave 
				emery@aries.mitre.org

Re: "limitations" of conditional compilation

[William Thomas Wolfe, 2847]

From emery@MBUNIX.MITRE.ORG (Emery):
> Armin points out that it is perfectly legal to do conditional
> compilation of statements based on some (constant) boolean value. [...]
> Where this approach fails, though, is in non-statements such as type
> declarations.  It would be nice to have support for this:
> 	type foo_bar is record
>           x : integer;
> #ifdef VAX
> 	    y : float_64;
> #elsif IBM_PC_WITH_8087    [...]
> 
> Using these ("constant type") variant records would probably make the
> program harder to read, because it wouldn't be clear to the maintainer
> if this was a variant record object (or subtype) based on some 'real
> variant) or based on some conditional compilation feature.  

   Amazingly enough, the standard SYSTEM package provides precisely
   the constant that we need to do this... it's SYSTEM.SYSTEM_NAME.

   Now are you REALLY contending that any competent maintainer is 
   going to fail to understand the following?

     type foo_bar (MACHINE : SYSTEM.NAME := SYSTEM.SYSTEM_NAME) is record
        X : Integer;
        case MACHINE is
           when VAX => Y : Float_64; 
           when IBM_PC_WITH_8087 => Y : IEEE_Float;
        end case;
     end record;

   The floating-point type definitions are taken from your example,
   despite the fact that they do not conform to the standard protocol
   for the naming of any additional compiler-supplied floating-point 
   subtypes (Short_Float, Long_Float, Long_Long_Float, etc.).  

   
   Bill Wolfe, wtwolfe@hubcap.clemson.edu
 

Re: "limitations" of conditional compilation

[Sun Visualization Products]

In article <7398@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes:
>From emery@MBUNIX.MITRE.ORG (Emery):
>>  It would be nice to have support for this:
>> 	type foo_bar is record
>>           x : integer;
>> #ifdef VAX
>> 	    y : float_64;
>> #elsif IBM_PC_WITH_8087    [...]
>   Amazingly enough, the standard SYSTEM package provides precisely
>     type foo_bar (MACHINE : SYSTEM.NAME := SYSTEM.SYSTEM_NAME) is record
>        X : Integer;
>        case MACHINE is
>           when VAX => Y : Float_64; 
>           when IBM_PC_WITH_8087 => Y : IEEE_Float;
>        end case;
>     end record;

I no longer work in an Ada shop, so I don't have a compiler or my
old copy of the interpretations to help double-check
my reading of the LRM, but according to 3.7 (3)
"The identifiers of all components of a record type must be distinct."
I interpret this to mean that the above record is illegal.

However, even if my interpretation is incorrect, I still feel that
some form of conditional compilation above and beyond "IF FALSE" is
advantageous.  At my last job, we were implementing and maintaining
an Ada compiler (written in Ada) targeted to several machines.  As
much as possible, target dependencies were localized to packages and
tables.  However, there were still occasions when a target dependent
section was best handled in a file of primarily target independent
code.   These cases did not always neatly fit into the IF TARGET=X
code scenario.  We used a preprocessor to handle these cases.  However,
if such a preprocessor were standard to Ada, then the source could
have fit better into the 'normal' Ada development environment.

Re: Re: "limitations" of conditional compilation

[Andy DeFaria]

>> Furthermore, there are many reasons besides host machine name for
>> doing separate compilation.  One that comes immediately to mind occurs
>> when a specific feature is present or absent from the version of the
>> operating system generated for a given machine.  I've seen this rather
>> frequently in Unix.
>
>   Appropriately handled in the package which provides the binding to
>   the operating system involved.  OS bindings must also be standardized,
>   and this is taking place; e.g., the IEEE 1003.5 Ada binding to Posix.
>    

I'm developing such a binding as we speak.  One problem that I have, and
haven't been able to workaround, is that of different representation clauses.
This OS binding is designed to be portable to multiple architectures.  The
data alignment of the different machines are different so I need to:

         Machine 1                                Machine 2
----------------------------------   ----------------------------------------
for RECORD_1 use                     for RECORD_1 use
   record                               record
      FIELD_1 at 0 range 0 .. 15;          FIELD_1 at 0 range 0 .. 15;
      FIELD_2 at 2 range 0 .. 15;          FIELD_2 at 4 range 0 .. 15;
      ...                                  ...
   end record;                          end record;

As you can see Machine 2 need to be aligned at the 4 byte boundary.  Since the
interface code I am going to is C (Unix system calls) I'm stuck the these
record layouts and alignments.  I have thought using some sort of constant to
determine where the next alignment would be but it would make the coding of
the for clause exceeding difficult.  

Re: Re: "limitations" of conditional compilation

[William Thomas Wolfe, 2847]

From article <920015@hpcladb.HP.COM>, by defaria@hpcladb.HP.COM (Andy DeFaria):
> I'm developing such a binding as we speak.  One problem that I have, and
> haven't been able to workaround, is that of different representation clauses.
> This OS binding is designed to be portable to multiple architectures.  The
> data alignment of the different machines are different so I need to:
> 
%          Machine 1                                Machine 2
% ----------------------------------   ----------------------------------------
% for RECORD_1 use                     for RECORD_1 use
%    record                               record
%       FIELD_1 at 0 range 0 .. 15;          FIELD_1 at 0 range 0 .. 15;
%       FIELD_2 at 2 range 0 .. 15;          FIELD_2 at 4 range 0 .. 15;
%       ...                                  ...
%    end record;                          end record;
> 
> As you can see Machine 2 need to be aligned at the 4 byte boundary.  Since the
> interface code I am going to is C (Unix system calls) I'm stuck the these
> record layouts and alignments.  I have thought using some sort of constant to
> determine where the next alignment would be but it would make the coding of
> the for clause exceeding difficult.  

   Hmmm... how about:

      ALIGNMENT_LENGTH : constant := 2;   -- or 4, or whatever...

      for RECORD_1 use
         record
            FIELD_1 at 0 * ALIGNMENT_LENGTH range 0..15;
            FIELD_2 at 1 * ALIGNMENT_LENGTH range 0..15;
            ...
         end record;

   The general form of the "at" expression seems to qualify as a
   static_simple_expression (by 4.9.7 & 4.4.2, plus a similar 
   example is given in 13.4.9), and the coding of the for clause 
   would seem to be relatively straightforward.


   Bill Wolfe, wtwolfe@hubcap.clemson.edu
 

Re: Re: "limitations" of conditional compilation

[Andy DeFaria]

>   Hmmm... how about:
>
>      ALIGNMENT_LENGTH : constant := 2;   -- or 4, or whatever...
>
>      for RECORD_1 use
>         record
>            FIELD_1 at 0 * ALIGNMENT_LENGTH range 0..15;
>            FIELD_2 at 1 * ALIGNMENT_LENGTH range 0..15;
>            ...
>         end record;
>
>   The general form of the "at" expression seems to qualify as a
>   static_simple_expression (by 4.9.7 & 4.4.2, plus a similar 
>   example is given in 13.4.9), and the coding of the for clause 
>   would seem to be relatively straightforward.

It's the old "who came first? the chicken or the egg" syndrone.  How do you
define ALIGNMENT_LENGTH?  Its 2 on some machines and 4 on others.  

Re: limitations on optimizers for conditional compilation

[Robert Munck]

In article <8912110202.AA11909@mbunix.mitre.org> emery@MBUNIX.MITRE.ORG (Emery) writes:
>... (discusses conditional compiliation of executable code)...   
>
>Where this approach fails, though, is in non-statements such as type
>declarations.  It would be nice to have support for this:
>	  record
>#ifdef VAX
>	    y : float_64;
>#elsif IBM_PC_WITH_8087
>	    y : IEEE_float;
>#endif
>
>... but I also suspect that it wouldn't take much to come up
>with type definitions where a variant record approach wouldn't work.

I'm not so sure about this anymore.  I have a feeling that "type
definitions where a variant record approach wouldn't work" may well be
the equivalent of "programs where structured coding doesn't work."

We oldtimers are all used to playing fast and loose with the source text
with preprocessor statements, including such horrors as "manufacturing"
keywords from conditionals and compile-time variables.  Maybe, just
maybe, that isn't such a good idea, and the good software engineering
practice would be to stick to the language definition, variant records
and all.

I have only one data-point, a small OS with a fair number of "sysgen"
variables and choices.  I found it fairly easy and "satisfactory to my
esthetic sense" to do everything entirely within the language.