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: 103376,8143b93889fe9472 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit X-Received: by 10.180.98.102 with SMTP id eh6mr78055wib.7.1359760443763; Fri, 01 Feb 2013 15:14:03 -0800 (PST) MIME-Version: 1.0 Path: bp2ni11020wib.1!nntp.google.com!proxad.net!feeder1-2.proxad.net!feeder.erje.net!eu.feeder.erje.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: Ada standard and maximum line lengths Date: Fri, 1 Feb 2013 17:13:48 -0600 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <8dfcf819-e1d0-4578-a795-a4bf724b5014@googlegroups.com> <5107b329$0$6556$9b4e6d93@newsspool4.arcor-online.net> <5107eaed$0$6566$9b4e6d93@newsspool4.arcor-online.net> <51080c38$0$6561$9b4e6d93@newsspool4.arcor-online.net> <51085776$0$6637$9b4e6d93@newsspool2.arcor-online.net> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: munin.nbi.dk 1359760437 14094 69.95.181.76 (1 Feb 2013 23:13:57 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Fri, 1 Feb 2013 23:13:57 +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-01T17:13:48-06:00 List-Id: "Niklas Holsti" wrote in message news:an1fdkFjimtU1@mid.individual.net... > On 13-02-01 01:54 , Randy Brukardt wrote: >> "Robert A Duff" wrote in message >> news:wccwquucd1x.fsf@shell01.TheWorld.com... ... >>> There are various ways to store line/column numbers compactly without >>> limiting line lengths. >> >> Really? Do tell! I know of no such technique that still would be usable >> (meaning does not involve indirection, which would add complication and >> fragmentation issues, and can be used at any time without calculation, >> because you don't know ahead of time when and where you'll need to >> generate >> error messages, debugging information, and traces). > > I'm not sure that I understand your conditions on what is "usable", but > the LEB128 encoding (little-endian base 128) used in DWARF works pretty > well for storing unbounded but usually small integers without wasting a > lot of space. An integer is encoded as a sequence of octets, with one > end-marker bit and 7 significand bits in each octet. Numbers from 0 to > 127 take one octet, number from 128 to 2**14 - 1 take two octets, and so > on. Thanks, sort of. That would work in the stream of tokens representation, but it wouldn't work in the symbol table, debugging information, intermediate code, and the like. As I noted, we use strong typing by having a Line_Number and Line_Position type, and it's preferable to use those types everywhere. A variable-length format would work fine in a stream, but it wouldn't work in the various records (you'd have to allocate space for the largest representation, and then why have all of the complication?) Also note that the symbol table records are written in and out (that's how we implement "with"), so increasing the size would have an impact on the compilation speed. I could see reasons for giving more bits to these things (in particular, a representation using 22-bits for the line number and 10-bits for the position would add only a little bit more space but effectively remove the limits), but I don't see any way to truely eliminate the limits. (Making the line number 32-bits and position 16-bits would increase the I/O requirements of the compiler by around 5%; that would probably only be noticable in large compilations or via a stopwatch but it surely is not "free".) In any case, there is a disincentive to make any changes so long as the ACATS insists on having a line length and identifier length being the same and thus relatively short. And it would be hard to justify rewriting those ACATS tests (they're among the least important tests, but not so much that they have so little value that removing them outright could be considered). Dan Eilers had the best suggestion, which was to convert the tests to tests that 200 character identifiers are properly supported (all compilers have to support those), but that would also be the most work. Such work would be better spent on tests for Ada 2005 and Ada 2012 features, I think. Randy.