<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'><div>Aside: </div><div><br></div><div> > LINIXLIBC </div><div><br></div><div>Any chance people will move from:</div><div> LINUXLIBC6 </div><div> NT386 </div><div> FreeBSD4 </div><div> SOLgnu </div><div> SOLsun </div><div> </div><div>to:</div><div> </div><div> I386_LINUX </div><div> I386_NT </div><div> I386_FREEBSD </div><div> SPARC32_SOLARIS (which internally lets you chose C compiler) </div><div><br></div><div>?</div><div><br></div><div> They have all been present and working for years. </div><div><br></div><div> These other names are a warty legacy. </div><div><br></div><div> The name LINUXLIBC6 has 20+ years of outdated legacy encoded in it. </div><div> 1) The assumption that Linux is x86 only. </div><div> 2) The fact that libc5 back in kernel 1.x days, pre-pthreads or at least pre-NPTL, was incompatible with libc6. </div><div>There is more motivation imho for pthreads vs. userthreads targets, and C vs. gcc-based vs. LLVM-based targets. </div><div>(LLVM-based should be link compatible with one of them though?) </div><div><br></div><div><br></div><div>I wouldn't mind lowercase or omitting the underscore or using a dash though -- possibly short forms recognized by "config.guess".</div><div><br></div><div> - Jay<br><br><br></div><div>> Date: Fri, 3 Jun 2016 20:23:37 -0400<br>> From: hendrik@topoi.pooq.com<br>> To: m3devel@elegosoft.com<br>> Subject: Re: [M3devel] replace build system??<br>> <br>> On Fri, Jun 03, 2016 at 09:44:12AM -0500, Rodney M. Bates wrote:<br>> > BTW, 'though the current build system is considerably sophisticated,<br>> > it does have some bugs, which we should fix. I have the exact setup &<br>> > symptom for one of them written down somewhere. I think it's when adding<br>> > a procedure signature to an interface when a procedure body for it was<br>> > already present in a compiled exporting module, things don't get recompiled<br>> > right.<br>> > <br>> > Also, I occasionally get recompile failures that I don't think are valid,<br>> > and when I clean the package and recompile that, all is well. I haven't<br>> > ever tracked down how to reproduce this or noted its exact symptom.<br>> <br>> I get them too, and I too have not managed to reproduce this. I have <br>> the impression that sonetimes something that should have been <br>> recompiled isn't, but I don't really know. Deleting the LINIXLIBC <br>> directory usually makes everything work.<br>> <br>> -- hendrik<br>> <br>> > <br>> > We also don't keep track of compile options that affect generated code,<br>> > so as to recompile when only the options change. E.g., optimization level,<br>> > debug info presence and format. I did do this for the size of WIDECHAR,<br>> > since mismatches here would be disastrous.<br>> > <br>> > On 06/03/2016 02:22 AM, Jay K wrote:<br>> > >I understand the C model very well, but I'm not certain of all<br>> > >the ramifications for Modula-3.<br>> > ><br>> > ><br>> > >I understand C++ has limited checking via name mangling.<br>> > ><br>> > ><br>> > >And that other systems carry names/signatures forward to runtime<br>> > >and check them there. Even dynamically linked C++. And Modula-3.<br>> > ><br>> > ><br>> > >However function names aren't everything -- i.e. they don't include<br>> > >structural hashes of types. It is name-based, not structure-based.<br>> > ><br>> > ><br>> > >The most common mistake in the loose C systems is not doing things<br>> > >wrong per se, but accidentally mixing old and new versions,<br>> > >and the result is undefined/crash.<br>> > ><br>> > ><br>> > >We have the same problem with our "extern" mechanism -- how many times<br>> > >I debugged stat corrupting stack until I put in the extra layer.<br>> > ><br>> > ><br>> > >C++ systems are getting better and check for "ODR violations" at link time.<br>> > >But checking at link time kinda contradicts my question.<br>> > >Goal being to fit into "generic" build systems but C++ only starts<br>> > >winning when the linker knows about it -- when the system is C++ specific.<br>> > >If C++ requires C++ linker/driver, we shouldn't feel too bad<br>> > >requiring a Modula-3 linker/driver.<br>> > ><br>> > ><br>> > > > Typical front end compilation actual work is similar to<br>> > > > or less than executable program startup/shutdown overhead.<br>> > ><br>> > ><br>> > > Ideally this is not the case. Ideally process startup is just referencing<br>> > > pages already in file system cache. Demand paging, unified file system cache<br>> > > and memory manager and all that (all systems NT, Linux, etc. are the same<br>> > > these days). But I realize in reality there is alway some amount of other CPU<br>> > > to burn at each process start. The ideal is not quite reached.<br>> > ><br>> > > > m3cc is a separate executable..has to start up for every .[im]3 file. B<br>> > ><br>> > > I wonder if we can fix this btw.<br>> > > If we can start it just once per library.<br>> > > Process create really is fast on typical Posix systems, so people maybe<br>> > > don't notice.<br>> > ><br>> > > There are a few methods:<br>> > > - alway keep the m3cg ir files<br>> > > - if any out of date, read them all into one large IR and write out one large assembly file<br>> > > - I want do that anyway, to achieve a rich/poor man's LTCG/LTO.<br>> > > poor: No need to worry about linker/driver support.<br>> > > rich: We can afford the memory these days. Though at some point it wouldn't scale.<br>> > > - I want do similar for C backend, as it seems noticable either the compiler startup<br>> > > or the few #includes I sometimes use (though C++ modules promise some relief..)<br>> > ><br>> > ><br>> > > Or, really, more simply, just accept a bunch of .mc/ms file pairs and process them<br>> > > separately as usual, but within one m3cg invocation.<br>> > ><br>> > ><br>> > > > Does/can it retain its incrementality?<br>> > ><br>> > > I think the best but not great we could do is make would decide pessmisically<br>> > > to run the compiler, but the compiler could figure out that the old/existing<br>> > > output is still correct. The world to decide up-to-date is significant but<br>> > > perhaps somewhat less than the work to just do all the work.<br>> > ><br>> > > > see no benefit and almost certainly losses, in putting these in different executables.<br>> > ><br>> > > Less code to maintain. Easier to redistribute.<br>> > > I like the model of distribution of C source.<br>> > > wget source && tar xf && configure && make && make install<br>> > ><br>> > > I want something like that.<br>> > > I am uncertain of "redistribution" and "active development" must/should be different.<br>> > > i.e. We do have something like this, and the two ways of working cooexist.<br>> > ><br>> > ><br>> > > - Jay<br>> > ><br>> > ><br>> > ><br>> > ><br>> > ><br>> > >----------------------------------------<br>> > >>Date: Wed, 1 Jun 2016 17:08:34 -0500<br>> > >>From: rodney_bates@lcwb.coop<br>> > >>To: m3devel@elegosoft.com<br>> > >>Subject: Re: [M3devel] replace build system??<br>> > >><br>> > >><br>> > >><br>> > >>On 06/01/2016 04:30 AM, Jay K wrote:<br>> > >>>We need to understand if and how well Modula-3 fits in the traditional and widespread C build infrastructure.<br>> > >><br>> > >>It doesn't, not very well. A deep principle, if you can call it that, of C is that<br>> > >>each compilation has no knowledge of any other compilation. Likewise, when linking<br>> > >>them together, it's all just binary stuff, addresses, constants, etc. To get a<br>> > >>semblance of type-safe compilation, all coders have to correctly follow some variant<br>> > >>of a header file/#include idiom and create a matching makefile that correctly reflects<br>> > >>the actual interdependencies. There is no checking that these are done correctly, and<br>> > >>from direct experience, I can say they are routinely done wrong.<br>> > >><br>> > >>All the modular languages have direct linguistic support for type-safe separate<br>> > >>compilation. Implementing this correctly while using the C compilation model lies<br>> > >>somewhere between very kludgy and impossible.<br>> > >><br>> > >>><br>> > >>>Does/can it retain its build speed if you invoke cm3 per .i3 and per .m3 file?<br>> > >><br>> > >>It couldn't possibly. Typical front end compilation actual work is similar to<br>> > >>or less than executable program startup/shutdown overhead. This effect<br>> > >>might be partially lost in the fact that m3cc is a separate executable and it<br>> > >>has to start up for every .[im]3 file. But it would still about double the<br>> > >>number of program executions and startup overheads.<br>> > >><br>> > >>>Does/can it retain its incrementality?<br>> > >><br>> > >>I don't think this is possible all. No matter what is in the makefile, Make<br>> > >>only understands dependencies among whole source files and must rebuild if<br>> > >>a depended-on file has been touched, even no changes to content. Our current<br>> > >>build system works on declaration granularity. (I presume this is what you<br>> > >>mean by incrementality." I am not aware of any language-independent build<br>> > >>infrastructure that keeps track of dependencies on other that source file<br>> > >>granularity.<br>> > >><br>> > >>><br>> > >>>Or do we really need to be more of the "driver" and do a lot of stuff at the lib/link level?<br>> > >>><br>> > >><br>> > >>In a sense, we already have this. Cm3 contains a sophisticated driver, a compiler<br>> > >>frontend, and language-specific link-time functions in one executable. I see no<br>> > >>benefit and almost certainly losses, in putting these in different executables.<br>> > >><br>> > >>>- Jay<br>> > >>><br>> > >>><br>> > >>><br>> > >>><br>> > >>>----------------------------------------<br>> > >>>>From: jay.krell@cornell.edu<br>> > >>>>To: mika@async.caltech.edu; estellnb@elstel.org; m3devel@elegosoft.com; dabenavidesd@yahoo.es<br>> > >>>>Date: Tue, 31 May 2016 17:18:46 +0000<br>> > >>>>Subject: Re: [M3devel] replace build system??<br>> > >>>><br>> > >>>>We should probably learn how to get the number of processors and optionally system load and make this more automatic.<br>> > >>>>Posix should standardize more of this. :(<br>> > >>>><br>> > >>>>- Jay<br>> > >>>><br>> > >>>><br>> > >>>><br>> > >>>><br>> > >>>><br>> > >>>><br>> > >>>>----------------------------------------<br>> > >>>>>To: estellnb@elstel.org; jay.krell@cornell.edu; m3devel@elegosoft.com<br>> > >>>>>To: dabenavidesd@yahoo.es<br>> > >>>>>Date: Tue, 31 May 2016 10:16:05 -0700<br>> > >>>>>From: mika@async.caltech.edu<br>> > >>>>>Subject: Re: [M3devel] replace build system??<br>> > >>>>><br>> > >>>>>I mentioned this before a few times on this mailing list.... CM3 is already fairly<br>> > >>>>>parallel if you turn on the right options. Every back-end invocation can be done<br>> > >>>>>in parallel.<br>> > >>>>><br>> > >>>>>Set M3_PARALLEL_BACK in the config to 10 or 20 and watch it go...<br>> > >>>>><br>> > >>>>>"Daniel Alejandro Benavides D." writes:<br>> > >>>>>...<br>> > >>>>>>A make-based build solution would have other advantages as well like=20<br>> > >>>>>>f.i. parallel build by make --jobs=3D4. That way CM3 could build up to=20<br>> > >>>>>>four times faster.<br>> > >>>>>...<br>> > >>>>>_______________________________________________<br>> > >>>>>M3devel mailing list<br>> > >>>>>M3devel@elegosoft.com<br>> > >>>>>https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel<br>> > >>>><br>> > >>>>_______________________________________________<br>> > >>>>M3devel mailing list<br>> > >>>>M3devel@elegosoft.com<br>> > >>>>https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel<br>> > >>><br>> > >>>_______________________________________________<br>> > >>>M3devel mailing list<br>> > >>>M3devel@elegosoft.com<br>> > >>>https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel<br>> > >>><br>> > >><br>> > >>--<br>> > >>Rodney Bates<br>> > >>rodney.m.bates@acm.org<br>> > >>_______________________________________________<br>> > >>M3devel mailing list<br>> > >>M3devel@elegosoft.com<br>> > >>https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel<br>> > > <br>> > >_______________________________________________<br>> > >M3devel mailing list<br>> > >M3devel@elegosoft.com<br>> > >https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel<br>> > ><br>> > <br>> > -- <br>> > Rodney Bates<br>> > rodney.m.bates@acm.org<br>> > _______________________________________________<br>> > M3devel mailing list<br>> > M3devel@elegosoft.com<br>> > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel<br>> _______________________________________________<br>> M3devel mailing list<br>> M3devel@elegosoft.com<br>> https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel<br></div> </div></body>
</html>