From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,6458d1ee91b224ec X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit X-Received: by 10.180.106.73 with SMTP id gs9mr2380754wib.2.1361849547575; Mon, 25 Feb 2013 19:32:27 -0800 (PST) MIME-Version: 1.0 Path: g1ni33273wig.0!nntp.google.com!feeder1.cambriumusenet.nl!82.197.223.108.MISMATCH!feeder2.cambriumusenet.nl!feed.tweaknews.nl!85.12.40.138.MISMATCH!xlned.com!feeder5.xlned.com!npeer.de.kpn-eurorings.net!npeer-ng0.de.kpn-eurorings.net!border2.nntp.ams2.giganews.com!border4.nntp.ams.giganews.com!border2.nntp.ams.giganews.com!nntp.giganews.com!news.teledata-fn.de!weretis.net!feeder4.news.weretis.net!nuzba.szn.dk!news.jacob-sparre.dk!munin.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Version control and multiple implementation variants (Was: chopping Ada source that have preprocessor symbols in them) Date: Tue, 19 Feb 2013 15:07:11 -0600 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <5111a9d5$0$6567$9b4e6d93@newsspool3.arcor-online.net><85txpnm1vp.fsf@stephe-leake.org><5114fb61$0$6561$9b4e6d93@newsspool4.arcor-online.net><85ehgqkxnf.fsf@stephe-leake.org><51168e7e$0$6566$9b4e6d93@newsspool3.arcor-online.net><85r4khdfm3.fsf@stephe-leake.org><511e17c3$0$9520$9b4e6d93@newsspool1.arcor-online.net><511E64AB.8030805@obry.net> <871ucffhtu.fsf@adaheads.sparre-andersen.dk> <87liakk4aa.fsf_-_@adaheads.sparre-andersen.dk> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: munin.nbi.dk 1361308034 24474 69.95.181.76 (19 Feb 2013 21:07:14 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Tue, 19 Feb 2013 21:07:14 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Date: 2013-02-19T15:07:11-06:00 List-Id: "Jacob Sparre Andersen" 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.