Re: Ada standard and maximum line lengths

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

"Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message 
news:an1fdkFjimtU1@mid.individual.net...
> On 13-02-01 01:54 , Randy Brukardt wrote:
>> "Robert A Duff" <bobduff@shell01.TheWorld.com> 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.