[M3devel] M3CG_Rd.m3

Antony Hosking hosking at cs.purdue.edu
Thu Sep 6 23:07:25 CEST 2012


Why not simply write it out as an extra field of the command in the text.
That way you don’t need to hack the check on Int.Convert.

So, wherever there is VName(u, v) M3CG_Wr would also have Txt(.name).
SImilarly, when M3CG_Rd has Scan_var it would follow that with Scan_text.
It just seems more principled to have both sides grok the same format instead of relying on CvtInt silently ignoring some non-integer suffix.

On Sep 6, 2012, at 3:46 PM, Jay <jay.krell at cornell.edu> wrote:

> Does there really exist other code that parses this stuff? Anything is possible but one needs to make judgement calls & confident guesses.
> 
> 
> I would imagine everyone should read them with M3CG_Rd. And that everyone would really use the binary form usually, that the verbose text is really for humans.
> 
> 
> Heck, I assume that we even have a persistent format only to workaround the gcc backend license. 
> 
> 
> My use is temporary convenience but a bit of a while & very convenient. Anyway, I could add a runtime flag to trigger this change if necessary.
> 
> 
> All the backends (gcc, x86, C) do their own tracing as well..almost the same as this ouput, some redundancy there, but it helps to have it output while the backend is running & not just using a tool on the side -- you can see right away where it got too before failing an assertion or such.
> 
> 
> 
>  - Jay (briefly/pocket-sized-computer-aka-phone)
> 
> On Sep 6, 2012, at 6:24 AM, Antony Hosking <hosking at cs.purdue.edu> wrote:
> 
>> Yes, that is a HACK.
>> How do you know that your change to include the name doesn’t break other parts of the tool chain.
>> Yes, I know that numbers are less readable, but the binding between name and numbers is explicit in the code.
>> I’ve never found it to be too difficult to manage with.
>> I think in this instance it would be better to revert to the numbers.  Short-term convenience for potential sacrifice of robustness represents a step backward.
>> 
>> On Sep 6, 2012, at 4:29 AM, Jay K <jay.krell at cornell.edu> wrote:
>> 
>>> http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3middle/src/M3CG_Rd.m3.diff?r1=1.14;r2=1.15;f=u
>>> 
>>> 
>>> Tony, now I'm reviewing your changes (CVS sure doesn't make this easy!)
>>> Apparent problem here.
>>> Granted, I could have left a comment in the code as to what was going on.
>>> (not that the vast bulk of m3-sys is well commented!)
>>> 
>>> 
>>> 
>>> Revision 1.15: download - view: text, markup, annotated - select for diffs
>>> Tue Sep 4 16:52:46 2012 (41 hours, 23 minutes ago) by hosking
>>> Branches: MAIN
>>> CVS tags: HEAD
>>> Diff to: previous 1.14: preferred, unified
>>> Changes since revision 1.14: +2 -2 lines
>>> Best to retain error checking on return values from Convert.ToInt.
>>> 
>>> 
>>> See here:
>>> 
>>> Revision 1.14: download - view: text, markup, annotated - select for diffs
>>> Wed Aug 22 16:15:40 2012 (2 weeks ago) by jkrell
>>> Branches: MAIN
>>> Diff to: previous 1.13: preferred, unified
>>> Changes since revision 1.13: +2 -2 lines
>>> when printing variables and procedures:
>>> e.g:
>>> 	begin_procedure	 p.32
>>> 	store		 v.33 0 Addr Addr
>>> 
>>> instead:
>>> 	begin_procedure	 p.32.Makefile__NoteSourceFile
>>> 	store		 v.33.file 0 Addr Addr
>>> 
>>> i.e. much more readable
>>> granted, less compact, not "normalized" (redundant data)
>>> 
>>> I verified that m3cgcat still roundtrips.
>>>   Not that I ever tried that before, but that is what
>>>   the design implied the ability to do. Not that
>>>   it is likely important these days/years/decades.
>>> 
>>> The delimiting "." is chosen to stop integer parsing
>>> It is presumed names don't contain spaces, or whatever,
>>> that M3CG_Rd is ok with this extra output from M3CG_Wr.
>>> I only tried with one file.
>>> 
>>> Note that I hacked M3CG_Rd__CvtInt to not complain about the extra text.
>>> It might be better to have it verify it some, like that it is dot
>>> followed by star or a valid pair of "__" delimited identifiers.
>> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120906/e94a664f/attachment-0002.html>


More information about the M3devel mailing list