Re: Version control and multiple implementation variants (Was: chopping Ada source that have preprocessor symbols in them)

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

"Jacob Sparre Andersen" <sparre@nbi.dk> wrote in message 
news:87liakk4aa.fsf_-_@adaheads.sparre-andersen.dk...
> Randy Brukardt wrote:
...
>> But the real situation is that you have different but related versions
>> for different targets. For instance, the host descriptor packages
>> contain a large bunch of constants, some of which vary by target. What
>> you don't want to do is have completely separate copies of these
>> packages, because it makes changing one of the packages to add or
>> delete something difficult -- now you have to change a bunch of other
>> packages as well.
>
> Wouldn't this be doable with nested packages with separate bodies for
> the target specific parts?

Not really, because Ada requires some things to be static (the size in bits 
for type Integer, for example), and thus they have to be defined as 
constants in a package specification.

Some such things (that don't have to be static) can be described as 
functions and thus put into a body, but when you do that you're making your 
program slower and more complex (especially as memory management is 
concerned; arrays with compile-time bounds are directly allocated while 
other arrays have to be allocated using some dynamic mechanism). Obviously, 
this matters for a compiler.

 >> Moreover, those bodies that are different for a shared body rarely are
>> 100% custom for each target. Typically, the algorithms are similar in
>> each target (and certainly the declarations are), and these shared
>> parts really ought to be shared (so that if a modification needs to be
>> made in one to fix a bug, it will get fixed in all versions).
>
> Yes.  I think this is an example where it would make sense to use nested
> packages with separate bodies for the target specific parts.  (But I
> have never written an Ada compiler, so I may be wrong.)

My level of sharing is much more fine-grained than yours. I'm thinking about 
any individual line of text that's shared, like the declarations of the 
various subprograms. For instance, in something like:

    function Register_Possible (Start, Stop : Int_Code_Index; Item : 
Int_Code_Index) return Boolean is
         -- Returns True if Item can be placed into a target hardware 
register over the
         -- entire range of code represented by Start .. Stop.
         Max_Registers : constant := 6; -- Intel x86.
    begin
         for I in Start .. Stop loop
               -- Figure the likely number of registers used by this code, 
return false if it ever reaches Max_Registers.
              case Code(I).Op_Code is
                   when RAISE_OP | TKCREATE | ... =>
                          -- These kill (use) all registers, so the answer 
is no.
                          return False;
                   ... -- Other intermediate code instructions.
              end case;
        end loop;
        return True; -- If we get here, we can put this item into a 
register.
    end Register_Possible;

In this code, the only code that's actually target-specific is the constant 
Max_Registers and the code represented by the ... The part about 
instructions that kill all registers is not target specific (obviously). (It 
should be noted that we use case statements for this sort of code as much as 
possible, without others clauses, because they let the Ada compiler complain 
if we forget to add a new instruction to the intermediate form, something 
that isn't common but does happen.)

Because so much of these algorithms is not target-specific, and the use of 
case statements is so important for correctness, I want to be able to manage 
these files as related (so that changes to the common parts get made 
automatically) and the unshared parts get managed separately.

(Side-note: Ada 2012's static predicates will allow a bit of additional 
abstraction here, as we will be able to define a subtype to represent all 
register-killing instructions and the like. That will at least eliminate one 
common thing that has to be maintained in all of these versions. But of 
course most of the code is in the limb, not the list of choices.)

...
> PS: When will you start accepting pre-orders for a Linux version of
>    Janus/Ada?

I'm happy to take people's money at any time. However, no one should be 
expecting delivery any time soon. ;-)

                                                     Randy.