[M3devel] m3front scanner div wierdness?

[Jay K]

My first computer, at home, had 80k, and it was oddly high end, most people had 48k or 64k.
 (in either case, the address space was 16 bit and ROM and periphal memory was in there,
so various bank switching employed to gain access; later similar with the 128k RAM machines...)


I won't just change one place and break all the others, but maybe we should try to split it everywhere as you suggest (and recombine
as you suggest).


I know that 32bits is overkill for a line number.
I also know 16 bits isn't overkill -- but more than 16 are used here so ok.
There is/was a warning in the Visual C++ compiler about truncating line numbers
or terminating debug information after 64k lines. Midl output would trigger it.

I still don't follow completely.
It seems there is an aliasing situation, where lines very far apart can be deemed the same.

I'll look closer though, as e.g. 20 bits would seem enough for a line number and 20 bits for a file number.
Or maybe the answer is 32 bits in general, and the 64bit machines can move the pair together...
In general you have to balance:
 1 System still compilable on 32bit. 
 2 vs. 64bit system can do more 

For the first case, you want to limit integers to 32bits and for the second you do not.

Also convenience and perf suggest *not* having to sprinkle div/mod all around,
though granted, div/mod by a constant is emininently optimizable, at least 32 bit operations...

 > FileNoAndLineNo

Lately this is called "location" and things even have starts and ends, so the error messages can output
a line and then point out the parts of the line. I'm not sure if this is obviously good and nice or overkill
but clang is there and I think gcc went there. Yes the data is larger.

Maybe shorter FileAndLine?
I realize it is ambiguous, they could both be strings, or line could be a file offset (a useful quantity!)

 - Jay


----------------------------------------
> Date: Wed, 29 Jun 2016 11:09:34 -0500
> From: rodney_bates at lcwb.coop
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] m3front scanner div wierdness?
>
>
>
> On 06/28/2016 10:54 PM, Jay K wrote:
>> Does anyone understand this stuff in m3front/Scanner.m3:
>>
>> Here vs. LocalHere?
>> SameFile?
>>
>>
>> I understand only this nuance:
>> offset MOD MaxLines
>>
>> MaxLines = 100000;
>>
>>
>> is to crudely handle that when asserts fail,
>> they pack the line number in with the assertion failure code,
>> potentially loosing bits.
>>
>>
>> I don't think this is a good design, they should just be separate INTEGERS,
>> but this is besides the point.
>>
>
> This is just pure speculation, but I am very confident of it. These
> offsets have a very high occurrence count. There is code all over m3front
> that copies Scanner.offset into various data structures. So the small space
> saving of one INTEGER instead of two would be multiplied by a big number.
> I remember working in Modula-3 on a company-paid computer with 16 Meg of ram.
> Today, I have 8 Gig in the one I bought, and could easily afford more, if I
> thought I needed it.
>
> Two integers would be cleaner, but this design is not too bad *if* you know
> the MOD/DIV invariant. It is commented at Scanner.m3:54, but only for one
> field. As pure documentation, there really should be a distinct type name
> (say FileNoAndLineNo?) for all values that use this representation, even
> though it just equates to INTEGER. There are a lot of variables lying around
> all over the front end that use this invariant, but are just declared as
> INTEGER. That's maintainer-hostile.
>
>
>>
>> What doesn't makes sense to me is the machinations around file name.
>>
>>
>> Here:
>> file := files [offset DIV MaxLines];
>>
>> vs. LocalHere:
>> file := local_files [fnum];
>>
>>
>> LocalHere makes sense. Here does not.
>>
>>
>> PROCEDURE SameFile (a, b: INTEGER): BOOLEAN =
>> BEGIN
>> RETURN (a DIV MaxLines) = (b DIV MaxLines);
>> END SameFile;
>>
>>
>>
>> Shouldn't this just be a = b?
>>
>
> As coded, this will return TRUE if a and b are different line numbers within
> the same file. The name "SameFile" at least suggests that is what is intended.
> A good example of a place where it would have been clearer if a & b were
> declared as the type name I proposed above.
>
>>
>> Well, anyway, this SameFile function isn't called.
>>
>> Here and LocalHere are used.
>>
>>
>> I'm looking here because I want to add a temporary measure
>> such that the file names are leaf-only.
>>
>>
>> In particular, because generic modules have target names in their paths
>> and I want to temporarly remove target names from output, so I can prove
>> that a few targets are identical.
>>
>>
>> I guess, really, I propose the interface to assertion failures be expanded to take the line number separate from the failure code.
>> This has to percolate quite a bit through the system -- the backends and the runtime.
>>
>>
>> And then this Here vs. LocalHere difference should fall away.
>> But still, what is it trying to do?
>>
>>
>> Thank you,
>> - Jay
>>
>>
>>
>> _______________________________________________
>> M3devel mailing list
>> M3devel at elegosoft.com
>> https://m3lists.elegosoft.com/mailman/listinfo/m3devel
>>
>
> --
> Rodney Bates
> rodney.m.bates at acm.org
> _______________________________________________
> M3devel mailing list
> M3devel at elegosoft.com
> https://m3lists.elegosoft.com/mailman/listinfo/m3devel