From jayk123 at hotmail.com Wed Dec 22 23:55:22 2021 From: jayk123 at hotmail.com (Jay K) Date: Wed, 22 Dec 2021 22:55:22 +0000 Subject: [M3devel] significant cm3 bootstrap/wiki/docs progress In-Reply-To: References: Message-ID: Eric you have some very good work on the "getting started" and "bootstrap", and piecing together all my parts and adding more. cmake covers for example, what I wanted to do with autoconf. (I haven't been able to get cmake to run on OSF/1, it requires C++14). Thank you. I can confirm, at least about a year ago, the Mac stuff works on M1/ARM64. Some nits. Current Windows includes curl and tar, and that tar supports some compression e.g. gzip, and not wget. Point is, err toward curl and tar, and not 7z please, maybe. I agree wget is easier to use though, and this gives you portability to Unix. I doubt you need "J" on tar. It should be automatic, in "tar xf". Perhaps automatic J is a GNU-ism? Does MacOS really need brew/gnu-tar? Tars are generally the same, unless paths are long, and even then maybe modern tars have converged. (I have run into a need to use GNU tar on older systems on other projects, indeed). > so our distribution includes a C++ bootstrap compiler Wording is a bit off, perhaps, but no matter. - Jay Message ID: -------------- next part -------------- An HTML attachment was scrubbed... URL: From vvm at tut.by Thu Dec 23 07:21:14 2021 From: vvm at tut.by (vvm at tut.by) Date: Thu, 23 Dec 2021 09:21:14 +0300 Subject: [M3devel] significant cm3 bootstrap/wiki/docs progress In-Reply-To: References: Message-ID: <65121640240137@mail.yandex.by> An HTML attachment was scrubbed... URL: From coder5506 at pobox.com Thu Dec 23 16:50:20 2021 From: coder5506 at pobox.com (Eric Sessoms) Date: Thu, 23 Dec 2021 10:50:20 -0500 Subject: [M3devel] significant cm3 bootstrap/wiki/docs progress In-Reply-To: References: Message-ID: <95addb8d-4246-4768-a6fd-1707bda5818f@www.fastmail.com> Thanks for the kind words. I know there's much yet to be done, but I felt like this was a solid step forward. On Wed, Dec 22, 2021, at 5:55 PM, Jay K wrote: > (I haven't been able to get cmake to run on OSF/1, it requires C++14). Yes, I was afraid cmake would fail on some or all platforms I'm not able to test on. I picked it over autotools partly because I know it better, but also because it has much better Windows support. If there's an older version of cmake (pre C++14) that works on OSF/1, I can try to adapt the cmake files to support it. (And in fairness, even though the older platforms are better supported by autotools, I would never expect them to work without platform-specific testing and tuning.) I meant to put out a call on the mailing list earlier, but better late than never: If anybody is is willing to provide me shell access to any non-mainstream platforms that CM3 should support, I will do my very best to make sure the new cmake bootstrap works there. The one platform I may be able to address myself is Solaris. I haven't personally used Solaris since... 96? but if someone could point be to the best / most-appropriate Vagrant box I can work with that. (See https://app.vagrantup.com/boxes/search?provider=virtualbox&q=solaris&sort=downloads&utf8=%E2%9C%93 ) > I can confirm, at least about a year ago, the Mac stuff works on M1/ARM64. Great! > Some nits. Always welcome. > Current Windows includes curl and tar, and that tar supports some > compression e.g. gzip, and not wget. > Point is, err toward curl and tar, and not 7z please, maybe. > I agree wget is easier to use though, and this gives you portability to > Unix. I'm happy with curl, I had no idea it was included in Windows. The Windows tar did not seem to work very well (aside from the issues Victor mentioned), but I can revisit it. My memory is not certain--too many platforms for me to always keep them straight--but it's possible that I ran into compatibility issues with assembling tars on Linux and not being able to untar them on Windows. 7z worked across platforms. > I doubt you need "J" on tar. It should be automatic, in "tar xf". > Perhaps automatic J is a GNU-ism? Yup, GNU. > Does MacOS really need brew/gnu-tar? Two issues there. Homebrew: not a huge fan (prefer MacPorts, personally) but I ran into problems installing the X11 dependencies with MacPorts. So I figured if brew was required for the X11 builds there was no point in confusing the issue by invoking multiple different package managers. The gnu-tar came upon me late in the game, when I discovered that my Linux tarballs wouldn't work on the Mac. So anyway, the central theme here seems to be that tarballs generated on Linux don't work very well on either Windows or BSD, so the fix is probably to assemble the distributions natively on the various platforms. That is entirely doable! >> so our distribution includes a C++ bootstrap compiler > Wording is a bit off, perhaps, but no matter. I struggled with that. :). My English was failing me, I suppose. From jayk123 at hotmail.com Fri Dec 24 11:41:49 2021 From: jayk123 at hotmail.com (Jay K) Date: Fri, 24 Dec 2021 10:41:49 +0000 Subject: [M3devel] significant cm3 bootstrap/wiki/docs progress In-Reply-To: <95addb8d-4246-4768-a6fd-1707bda5818f@www.fastmail.com> References: <95addb8d-4246-4768-a6fd-1707bda5818f@www.fastmail.com> Message-ID: Sorry this a bit disjointed: Curl on Windows is recent. I don't know from when. The new additions always kinda surprise me. I agree it is difficult to remember the platforms, the versions, the switches, the behaviors. So "converging" and just saying "GNU tar always" greatly simplifies and is a small or zero inconvenience. People can ignore it, and it might work, or do it and it might have been unnecessary, etc. This explains much of cm3 and it is reasonable. I don't know if you have seen the whole cminstall thing. That I have never liked, but solves simplar problems for similar reasons. Easier to do a so-so portable solution with less dependency, than to adopt the varying more complete solutions on every system, esp. 20+ years ago when GNU was less dominant. But cminstall I think did too little and too poorly, to be worthwhile. A common characteristic of many systems. You know, the stuff about "finding" x11, odbc, etc. these can?should be handled by autoconf or cmake or pkg-config. When quake was written, cmake didn't exist, and autoconf was less widespread, and this stuff works on Windows. And it is fast. And temptingly easy to maintain. On one hand it detracts from the core of Modula-3, but it does add some value. Go and Rust do derive much of their value from their build systems, as "minor" as that might seem. I am very tempted to include C code for unzip in some sort of uncompressed/unpackaged form, like one C file, to get over this, but that seems wrong too. Do realize that cm3 bootstrap itself is available as one .cpp file...however...I don't know. Maybe that was a bad idea. It is unwieldy when it has errors and it does fail to compile on some systems just due to being large, whereas the multiple medium-sized files work. Every solution has tradeoffs. Years ago the OpenBSD position included that gzip is fast and low memory on all systems and they insisted on using it, vs. higher compression ratios. That rules out "J", 7zip, etc. I am sympathetic to this simple view, that leads to not just a sort of performance portability, but prerequisite portability. But again, maybe really not a big deal. People should start gradually trying your new directions and we can see if anyone complains. But there is no perfect answer here, understood. No strong opinion can be correct. Any fact can be refuted through time, or nearly confirmed by smaller more recent samples. In your copious time on this project you may want to "restore" building of .msis. That is another kinda dent in this battle. And heck you could consider using it to "install"/compress source. I realize it is all contentious, provision of binaries vs. source vs. both. One might argue that Windows users are fine with binaries, but this is a gross generalization that mostly confuses axes. It isn't a complete confusion, in that apart from philosophical or bootstrapability grounds, binaries work "better" on Windows due to higher release to release compatibility. You probably noticed I was producing .debs, but not very good ones. Homebrew: I have been resigned to this for years due to past professional concerns. I don't know how it compares to MacPorts, etc. but seemingly the main problem with all of these, is they aren't builtin. > tarballs generated on Linux don't work very well on either Windows or BSD Ugh. "We" may want to pursue that. I admit I had not noticed. Maybe there are flags. Maybe it is the long path thing. (Years ago I needed GNU tar to extract gcc on Irix for example.) "We" may want to consider .zip universally. I realize people would cringe at that too, and it seems unnecessary now that Windows has tar. I realize "we" is whoever does the work, if anyone. I am mostly talk these days. > Wording is a bit off, perhaps Almost nobody understands any of this. Of the few that understand it, some really dislike it, so don't care how it is worded. Some really like it, so don't care much about the wording. (And some dislike it without understanding. :) ) Personally of course I am totally in favor of this. It is a clear leader imho in how to write compilers, though not far and away best. Compiling to LLVM IR is a good choice too, and we could even distribute portable textual LLVM IR. Also I believe the structure you now have is a major advance in terms of acceptability into either RedHat or Debian, but maybe not both. They have certain "build from source" requirements, of which I think you now satisfy. One of them allows derived files, as long as there is like that feedback loop and deleting of the derived files. Honestly I don't know how else anything can work. You know, gcc is not magic, does not spring out of thin air, and must work "similarly" (well, somewhat differently, the derived files must be executables, not text). https://wiki.debian.org/UpstreamGuide#Bootstrapping.2FCrossbuilding_Language_Compilers.2FInterpreters does not seem to cover this though, alas. While I am airing all of my desires, the garbage collection in cm3 I think needs work. I believe it maintains one span of all allocated memory, or a span divided by 64k page size. It suffers under particularly random allocation patters in the underlying mmap and should be rewritten "like" a page table, a multi level sparse array, perhaps with variably sized "pages", but probably not. i.e. and then remove the use of sbrk from Linux. Back on the m3build thing. My vision is something like: Introduce new "targets", like "auto" or "autotools" or "autounix64le" or "cmake" or "cmakewindows" or "cmakeunix64le" in which cm3's "builder" job largely becomes to generate automake/libtool or cmake input and then run them. For the backend and linking work. This would include incrementality, perhaps via "move if change", so while there would be some slight "latency" e.g. when adding/removing source files, the incremental build performance would be pretty ok. I prototyped this, like with minimal automake input. There is the problem of where to put output. We have this user model, you know, of current directory + target. Instead of cd out of source dir and use current directory. Another step in all of this is the ability to tie together directories. No more cd'ing around required. Just build from the root. I realize this is controversial for many reasons. There is the question as to what packages are really part of one overall system, vs. independent, and the world is not in one tree (Linux kernel, Glibc, gcc, X11, cm3, etc.) People esp. here don't like automake or cmake, we have our own good system, but this is subjective and has cost. I'd rather adapt to and depend on more portability layers than maintain more of them. Being better, is being different, is expensive. I think your cmake work subsumes a lot of this, but you "only" did it for bootstrap. Also btw we should be able to produce one C++ form for 32bit and 64bit. I was working on it but didn't finish. It is not as easy as I thought. My initial vision was to use uint64 almost everywhere, but then cast before dereference. This doesn't work because, passing of parameters to extern (C) functions. And don't treat extern differently. So the next experiment was uint64 local variables everywhere..and treat all or all pointer parameters as uplevel, so they get captured to uint64 locals. Something like that. And still mind any INTEGER in structs involved in C interop. And cast to pointer for function calls. On Windows you could almost just put __ptr64 on all pointers and be done, alas. And then any endian specific code could be factored into C, or make endian be dynamically detected. I.e. in the floating point stuff. Oh and exception handling should depend on C++, instead of the thread locals and setjmp/longjmp. :) But before that, jmpbuf should be a type backends can optionally know about, and then optionally remove the alloca... :) And then the system can be considered very much done from my point of view. :) > I can confirm, at least about a year ago, the Mac stuff works on M1/ARM64. It required small tweaks. We maybe should complete this matrix: ARM32_{NT,LINUX} (half done? I realize "arm32" is ambiguous..) RISCV{32,64}_LINUX (half done? all done?) ARM64_{LINUX,NT,DARWIN) (partly done) ARM64EC_NT (maybe..pointless really) But it is likely all trivial at this point. The C++ backend has proven its success. > The one platform I may be able to address myself is Solaris. It runs ok in VirtualBox and/or Hyper-V and/or Parallels. I had it one of those this year, easily enough. I fixed minor problems. Actually, maybe that is not what I used..for the SunCC fixes. opencsw is the way.. > but I felt like this was a solid step forward Definitely. > If there's an older version of cmake (pre C++14) that works on OSF/1, I can try to adapt the cmake files to support it Hm for some reason I didn't think about this but only tried current cmake. Yeah let's maybe try that. > much better Windows support. Definite cmake advantage agreed. > If anybody is is willing to provide me shell access to any non-mainstream platforms > that CM3 should support, I will do my very best to make sure the new cmake bootstrap works there. I can probably get you OSF/1 but I hesitate to..just sending this mail...your time is better spent in the direction you are already going. Seriously, at some point, say no. Requests will only get more ridiculous until you do. :) Which reminds me..DragonflyBSD is missing. Heck, OS/2 and djgpp are missing. AIX, Irix, HP-UX, VMS. I expect autotools or cmake based work will just work on HP-UX and AIX though. Write a backend that generates (unsafe) Go, and use its garbage collector. Ditto (unsafe) C#. Or integrate the custom Go backends. :) - Jay ________________________________ From: Eric Sessoms Sent: Thursday, December 23, 2021 3:50 PM To: Jay K ; m3devel Subject: Re: significant cm3 bootstrap/wiki/docs progress Thanks for the kind words. I know there's much yet to be done, but I felt like this was a solid step forward. On Wed, Dec 22, 2021, at 5:55 PM, Jay K wrote: > (I haven't been able to get cmake to run on OSF/1, it requires C++14). Yes, I was afraid cmake would fail on some or all platforms I'm not able to test on. I picked it over autotools partly because I know it better, but also because it has much better Windows support. If there's an older version of cmake (pre C++14) that works on OSF/1, I can try to adapt the cmake files to support it. (And in fairness, even though the older platforms are better supported by autotools, I would never expect them to work without platform-specific testing and tuning.) I meant to put out a call on the mailing list earlier, but better late than never: If anybody is is willing to provide me shell access to any non-mainstream platforms that CM3 should support, I will do my very best to make sure the new cmake bootstrap works there. The one platform I may be able to address myself is Solaris. I haven't personally used Solaris since... 96? but if someone could point be to the best / most-appropriate Vagrant box I can work with that. (See https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapp.vagrantup.com%2Fboxes%2Fsearch%3Fprovider%3Dvirtualbox%26q%3Dsolaris%26sort%3Ddownloads%26utf8%3D%25E2%259C%2593&data=04%7C01%7C%7C6969ef8b698d45e97ccb08d9c62c62a1%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637758716199559510%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=sayC0VJOZtBEtfmsNtEQFagv30%2Bpi%2BsZowUEQOpbTNA%3D&reserved=0 ) > I can confirm, at least about a year ago, the Mac stuff works on M1/ARM64. Great! > Some nits. Always welcome. > Current Windows includes curl and tar, and that tar supports some > compression e.g. gzip, and not wget. > Point is, err toward curl and tar, and not 7z please, maybe. > I agree wget is easier to use though, and this gives you portability to > Unix. I'm happy with curl, I had no idea it was included in Windows. The Windows tar did not seem to work very well (aside from the issues Victor mentioned), but I can revisit it. My memory is not certain--too many platforms for me to always keep them straight--but it's possible that I ran into compatibility issues with assembling tars on Linux and not being able to untar them on Windows. 7z worked across platforms. > I doubt you need "J" on tar. It should be automatic, in "tar xf". > Perhaps automatic J is a GNU-ism? Yup, GNU. > Does MacOS really need brew/gnu-tar? Two issues there. Homebrew: not a huge fan (prefer MacPorts, personally) but I ran into problems installing the X11 dependencies with MacPorts. So I figured if brew was required for the X11 builds there was no point in confusing the issue by invoking multiple different package managers. The gnu-tar came upon me late in the game, when I discovered that my Linux tarballs wouldn't work on the Mac. So anyway, the central theme here seems to be that tarballs generated on Linux don't work very well on either Windows or BSD, so the fix is probably to assemble the distributions natively on the various platforms. That is entirely doable! >> so our distribution includes a C++ bootstrap compiler > Wording is a bit off, perhaps, but no matter. I struggled with that. :). My English was failing me, I suppose. -------------- next part -------------- An HTML attachment was scrubbed... URL: From coder5506 at pobox.com Fri Dec 24 17:17:43 2021 From: coder5506 at pobox.com (Eric Sessoms) Date: Fri, 24 Dec 2021 11:17:43 -0500 Subject: [M3devel] significant cm3 bootstrap/wiki/docs progress In-Reply-To: References: <95addb8d-4246-4768-a6fd-1707bda5818f@www.fastmail.com> Message-ID: <086ae65e-d0c5-4684-93c2-842c19300409@www.fastmail.com> On Fri, Dec 24, 2021, at 5:41 AM, Jay K wrote: > I can probably get you OSF/1 but I hesitate to..just sending this > mail...your time is better > spent in the direction you are already going. Seriously, at some point, > say no. > Requests will only get more ridiculous until you do. :) That's a fair point. Everybody has their own priorities. My priority is using cm3 at work, which means I needed first and foremost a stable and reliable compiler (CI/CD) and support for the platforms I use (i.e., fixing macOS), and both of those together led to working on builds and installs. I recognize a certain responsibility goes along with that. Nobody wants yet another build system, so if I'm going to do it, I need to do it right and not just make the situation worse. So yeah, that means making sure it works for as many platforms as I reasonably can. Now that the initial hurdles are over I do want to spend more time using cm3 and less time working on cm3, but I don't plan to leave a job half-done. > I don't know if you have seen the whole cminstall thing. Well, it assumes an existing Modula-3 compiler or a binary distribution, so it wasn't really suitable. > You know, the stuff about "finding" x11, odbc, etc. > these can?should be handled by autoconf or cmake or pkg-config. It can and should. I spent some time writing autoconf-style functionality in quake (finding a few quake bugs along the way) before discovering how fundamentally limited the m3build stuff is. It is possible to greatly improve the current m3makefiles, but I think the effort is better spent to just obsolete them. > When quake was written, cmake didn't exist, and autoconf Yeah, these things all make sense in context. I'm sure it was the right move at the time. And it is easy to use, but is is limiting. Autoconf and cmake can be just as easy for end users or new contributors... once it's setup. > Do realize that cm3 bootstrap itself is available > as one .cpp file...however...I don't know. Maybe > that was a bad idea. It is unwieldy when it has errors I thought the single-file approach was great. I know you said some systems couldn't handle it, but I never had any problems. What finally decided me in favor of multiple files was the need to include mklib.exe for windows. So now I need to build two EXEs, both statically linked, sharing 90% of the same code. Individual files make for a smaller distribution. > Years ago the OpenBSD position included that gzip is > fast and low memory on all systems and they insisted on using it, > vs. higher compression ratios. Fair. But where the newer algorithms really suffer is in the compressing, less so the decompressing. I just did a quick test: our 40MB xz decompressed in 2.5s and the equivalent 70MB gz decompressed in 1.5s. I feel like you'll lose that second downloading the extra 30MB. > In your copious time on this project you may want to "restore" > building of .msis. That is another kinda dent in this battle. Agree. MSIs, DEBs, etc., all need to come back. But first will be Gentoo ebuilds b/c that's what I personally use. :) > vs. both. One might argue that Windows users are fine with binaries, > but this is a gross generalization that mostly confuses axes. I did consider that, but you can't realistically use cm3 on Windows without a supporting compiler, so it's a hurdle the user will need to overcome at some point. MSIs are convenient, but not a top priority. > though not far and away best. Compiling to LLVM IR is a good choice too, > and we could even distribute portable textual LLVM IR. LLVM is also mostly talk these days. And I'm not picking on our LLVM backend. They support *way* fewer targets that we do https://clang.llvm.org/docs/UsersManual.html#target-specific-features-and-limitations and their supported host platforms (for distributing IR) are even more limited https://llvm.org/docs/GettingStarted.html#requirements In practical terms, LLVM is just a convenient way to compile to either x86 or Arm, with optimizations that may or may not be worth their cost in added compile time. It's got some advantages, but I can't see using it for bootstrap. > While I am airing all of my desires, the garbage collection in cm3 I > think needs work. That's something I've been wanting to work on since Day 1! Before I got sidetracked with the whole build and install thing. I know the GC has flaws, but it's not Boehm. That's a huge win in my book, since just about everything else not backed by a trillion-dollar corporation uses Boehm. Boehm is great, but GC is all about tradeoffs, and the tradeoffs it makes are not appropriate for the types of applications I write. I can't wait to get all this janitorial work out of the way so I can concentrate on the GC. > I think your cmake work subsumes a lot of this, but you "only" > did it for bootstrap. I did. I could compile the entire system to C and distribute that, but (a) it would be even bigger and (b) it's still a source distribution, so there's no clear advantage. I can't really take cmake or autotools further until I can get away from quake and its limitations. Adding for anyone who didn't see the other thread: I don't plan to get rid of quake--I'm sure it will be around forever--I'm just going to add a way to *not* use it. > Also btw we should be able to produce one C++ form for 32bit and 64bit. > I was working on it but didn't finish. (snip) Thanks for these notes, they will be very useful. From jayk123 at hotmail.com Sun Dec 26 04:55:29 2021 From: jayk123 at hotmail.com (Jay K) Date: Sun, 26 Dec 2021 03:55:29 +0000 Subject: [M3devel] significant cm3 bootstrap/wiki/docs progress In-Reply-To: <086ae65e-d0c5-4684-93c2-842c19300409@www.fastmail.com> References: <95addb8d-4246-4768-a6fd-1707bda5818f@www.fastmail.com> <086ae65e-d0c5-4684-93c2-842c19300409@www.fastmail.com> Message-ID: [partial answers, I need to go] > I thought the single-file approach was great. mklib isn't a good reason to give this up, actually. - mklib can be a lib linked into cm3 - mklib can probably go away almost entirely: cm3 can write .def files, and run usual link /lib mklib is part of an attempt to remove all C++ tools, not worthwhile imho. But yes I understand your point, and it is certainly ok. It should parallelize better or more easily (via make instead of the compiler) > I recognize a certain responsibility goes along with that. > MSIs, DEBs, etc., all need to come back. Just realize these .debs were particularly low quality. There was "all" and "min". That overlapped. That were built on one system (easily fixed now with automation). They were built in a custom and minimal way, i.e. w/o deb tools, w/o dependencies, w/o versionining. Probably nobody used them, and they do not come close to Debian packaging standards. I do think .msi has a little value, but as you point out, you need a C++ compiler/linker anyway. Maybe don't bother. The easier portable C++-based bootstrap is a major advance. > Gentoo Wow I have tried but failed to become a Gentoo user, and am torn on the value thereof. > I could compile the entire system to C and distribute that There is that, but it isn't what I meant. I meant you are using cmake to tie together directories already. This is functionality that should be there post-bootstrap also. cm3 has a directory walking, and packages, but doesn't have provision for building multiple packages. I think it might be quite easy but haven't gotten around to it, for many years. One problem with making the entire distribution as C++ is you might into "AMD64_LINUX" not being right for all 64bit little endian Unix. Might. What "you" "need" to do is build that for varius targets and compare, and work out the differences. I did that already but maybe only for "boot1". Or rather, don't do it. :) Other ideas include m3build remembering the "ifs", and generating both sides, and having ifdef in the C++. So Unix and Windows C++ is the same file. Very futuristic. Not well described here. - Jay ________________________________ From: Eric Sessoms Sent: Friday, December 24, 2021 4:17 PM To: Jay K ; m3devel Subject: Re: significant cm3 bootstrap/wiki/docs progress On Fri, Dec 24, 2021, at 5:41 AM, Jay K wrote: > I can probably get you OSF/1 but I hesitate to..just sending this > mail...your time is better > spent in the direction you are already going. Seriously, at some point, > say no. > Requests will only get more ridiculous until you do. :) That's a fair point. Everybody has their own priorities. My priority is using cm3 at work, which means I needed first and foremost a stable and reliable compiler (CI/CD) and support for the platforms I use (i.e., fixing macOS), and both of those together led to working on builds and installs. I recognize a certain responsibility goes along with that. Nobody wants yet another build system, so if I'm going to do it, I need to do it right and not just make the situation worse. So yeah, that means making sure it works for as many platforms as I reasonably can. Now that the initial hurdles are over I do want to spend more time using cm3 and less time working on cm3, but I don't plan to leave a job half-done. > I don't know if you have seen the whole cminstall thing. Well, it assumes an existing Modula-3 compiler or a binary distribution, so it wasn't really suitable. > You know, the stuff about "finding" x11, odbc, etc. > these can?should be handled by autoconf or cmake or pkg-config. It can and should. I spent some time writing autoconf-style functionality in quake (finding a few quake bugs along the way) before discovering how fundamentally limited the m3build stuff is. It is possible to greatly improve the current m3makefiles, but I think the effort is better spent to just obsolete them. > When quake was written, cmake didn't exist, and autoconf Yeah, these things all make sense in context. I'm sure it was the right move at the time. And it is easy to use, but is is limiting. Autoconf and cmake can be just as easy for end users or new contributors... once it's setup. > Do realize that cm3 bootstrap itself is available > as one .cpp file...however...I don't know. Maybe > that was a bad idea. It is unwieldy when it has errors I thought the single-file approach was great. I know you said some systems couldn't handle it, but I never had any problems. What finally decided me in favor of multiple files was the need to include mklib.exe for windows. So now I need to build two EXEs, both statically linked, sharing 90% of the same code. Individual files make for a smaller distribution. > Years ago the OpenBSD position included that gzip is > fast and low memory on all systems and they insisted on using it, > vs. higher compression ratios. Fair. But where the newer algorithms really suffer is in the compressing, less so the decompressing. I just did a quick test: our 40MB xz decompressed in 2.5s and the equivalent 70MB gz decompressed in 1.5s. I feel like you'll lose that second downloading the extra 30MB. > In your copious time on this project you may want to "restore" > building of .msis. That is another kinda dent in this battle. Agree. MSIs, DEBs, etc., all need to come back. But first will be Gentoo ebuilds b/c that's what I personally use. :) > vs. both. One might argue that Windows users are fine with binaries, > but this is a gross generalization that mostly confuses axes. I did consider that, but you can't realistically use cm3 on Windows without a supporting compiler, so it's a hurdle the user will need to overcome at some point. MSIs are convenient, but not a top priority. > though not far and away best. Compiling to LLVM IR is a good choice too, > and we could even distribute portable textual LLVM IR. LLVM is also mostly talk these days. And I'm not picking on our LLVM backend. They support *way* fewer targets that we do https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fclang.llvm.org%2Fdocs%2FUsersManual.html%23target-specific-features-and-limitations&data=04%7C01%7C%7C30e31939b7504a45564508d9c6f8f9ba%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637759594915801165%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=TryfUpd2HcG4osZRO4lJ7t2ZQ9ndbGKBXHvmJ%2BtlbbU%3D&reserved=0 and their supported host platforms (for distributing IR) are even more limited https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fllvm.org%2Fdocs%2FGettingStarted.html%23requirements&data=04%7C01%7C%7C30e31939b7504a45564508d9c6f8f9ba%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637759594915801165%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Ows%2FIFNywOkmR%2Bagzilo0%2Fr2BYnkXAuuTbTNViuAu2U%3D&reserved=0 In practical terms, LLVM is just a convenient way to compile to either x86 or Arm, with optimizations that may or may not be worth their cost in added compile time. It's got some advantages, but I can't see using it for bootstrap. > While I am airing all of my desires, the garbage collection in cm3 I > think needs work. That's something I've been wanting to work on since Day 1! Before I got sidetracked with the whole build and install thing. I know the GC has flaws, but it's not Boehm. That's a huge win in my book, since just about everything else not backed by a trillion-dollar corporation uses Boehm. Boehm is great, but GC is all about tradeoffs, and the tradeoffs it makes are not appropriate for the types of applications I write. I can't wait to get all this janitorial work out of the way so I can concentrate on the GC. > I think your cmake work subsumes a lot of this, but you "only" > did it for bootstrap. I did. I could compile the entire system to C and distribute that, but (a) it would be even bigger and (b) it's still a source distribution, so there's no clear advantage. I can't really take cmake or autotools further until I can get away from quake and its limitations. Adding for anyone who didn't see the other thread: I don't plan to get rid of quake--I'm sure it will be around forever--I'm just going to add a way to *not* use it. > Also btw we should be able to produce one C++ form for 32bit and 64bit. > I was working on it but didn't finish. (snip) Thanks for these notes, they will be very useful. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Wed Dec 29 18:56:51 2021 From: jayk123 at hotmail.com (Jay K) Date: Wed, 29 Dec 2021 17:56:51 +0000 Subject: [M3devel] IA64_HPUX target names? Message-ID: Hi. I have an HP-UX/IA64 machine. This system is "funny" in that it supports 32bit and 64bit pointer sizes. I guess 32bit pointer/long are really good for compatibility with older source code. Esp. 10+ years ago. (more recently, support for 32bit is being dropped). Modula-3 does not need this, but for hypothetical linking to old C/C++ code and completeness. So we need some target names: - do nothing, wierd unpopular system - IA64_HPUX with 64bit integer/pointer, and no 32bit system - IA6464_HPUX, IA6432_HPUX - IA64_HPUX, IA32_HPUX (IA32 can mean x86, but there is no HP-UX/x86) But I have never seen IA32 mean Itanium. - IA64_HPUX implied 64bit, IA64_HPUX32 This is my favorite by a small margin. - IA64_HPUX64, IA64_HPUX32? - ITANIUM64_HPUX ITANIUM32_HPUX I don't think there is any precedent. In that, usually the numbers "32" and "64" in an architecture imply the pointer size, and IA64 is a popular name for this. Also this is Itanium2. Itanium1 was an even older and lower volume system. IA64 is particularly unusual in having "two stacks". Registers are spilled "behind the scenes" to a stack that starts at the same base as the "normal" stack, but grows up. That is my understanding. I'd really like to get away from a conservative GC, but this is what we have "for now". I realize HP-UX and IA64 are both kinda useless. I don't have git yet so this'll be a short while still. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri Dec 31 02:44:18 2021 From: jayk123 at hotmail.com (Jay K) Date: Fri, 31 Dec 2021 01:44:18 +0000 Subject: [M3devel] IA64_HPUX target names? In-Reply-To: References: Message-ID: I've been mulling this over a bit. Kinda a waste, granted. There's no great answer. And it doesn't matter much. There are so many other approaches, but we are kinda stuck for now. We could build to current directory (preferably that user creates outside of source) or a generically named "out". We could call Itanium IPF or such as it is sometimes. The problem is I don't want things like IA6432 or IA6464. I don't love the symmetry of IA64_HPUX and IA64_HPUX32 I don't love having "32" and "64" in the same name. I don't love IA64_HPUX64 either. I don't even really love ALPHA_LINUX being unambiguously 64bit but there being 32bit and 64bit ALPHA_VMS. So, I cannot resolve all dilemas. I am leaning toward: When there is "any" amibiguity, put in 32 or 64. If 64 occurs in processor name, put 32 or 64 at end. "Any" ambiguity includes unreleased NT/alpha64. Leading to: ALPHA32_NT ALPHA64_NT ALPHA32_VMS ALPHA64_VMS IA64_HPUX32 (yuck) IA64_HPUX64 (yuck) ALPHA_LINUX ? IPF32_HPUX and IA32_HPUX are tempting I admit. - Jay ________________________________ From: Jay K Sent: Wednesday, December 29, 2021 5:56 PM To: m3devel Subject: IA64_HPUX target names? Hi. I have an HP-UX/IA64 machine. This system is "funny" in that it supports 32bit and 64bit pointer sizes. I guess 32bit pointer/long are really good for compatibility with older source code. Esp. 10+ years ago. (more recently, support for 32bit is being dropped). Modula-3 does not need this, but for hypothetical linking to old C/C++ code and completeness. So we need some target names: - do nothing, wierd unpopular system - IA64_HPUX with 64bit integer/pointer, and no 32bit system - IA6464_HPUX, IA6432_HPUX - IA64_HPUX, IA32_HPUX (IA32 can mean x86, but there is no HP-UX/x86) But I have never seen IA32 mean Itanium. - IA64_HPUX implied 64bit, IA64_HPUX32 This is my favorite by a small margin. - IA64_HPUX64, IA64_HPUX32? - ITANIUM64_HPUX ITANIUM32_HPUX I don't think there is any precedent. In that, usually the numbers "32" and "64" in an architecture imply the pointer size, and IA64 is a popular name for this. Also this is Itanium2. Itanium1 was an even older and lower volume system. IA64 is particularly unusual in having "two stacks". Registers are spilled "behind the scenes" to a stack that starts at the same base as the "normal" stack, but grows up. That is my understanding. I'd really like to get away from a conservative GC, but this is what we have "for now". I realize HP-UX and IA64 are both kinda useless. I don't have git yet so this'll be a short while still. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney.bates at gmx.com Fri Dec 31 18:38:26 2021 From: rodney.bates at gmx.com (Rodney Bates) Date: Fri, 31 Dec 2021 11:38:26 -0600 Subject: [M3devel] IA64_HPUX target names? In-Reply-To: References: Message-ID: On 12/30/21 7:44 PM, Jay K wrote: > I've been mulling this over a bit. Kinda a waste, granted. > > There's no great answer. > > And it doesn't matter much. I don't consider making good names of anything to be unimportant. I've spent too many hours in maintenance work trying to figure out things with names that are ambiguous, uninformative, or worst, downright misleading. > > There are so many other approaches, but we are kinda stuck for now. > We could build to current directory (preferably that user creates outside of source) or a generically named "out". > > We could call Itanium IPF or such as it is sometimes. > > The problem is I don't want things like IA6432 or IA6464. > > I don't love the symmetry of IA64_HPUX and IA64_HPUX32 > > I don't love having "32" and "64" in the same name. > > I don't love IA64_HPUX64 either. > > I don't even really love ALPHA_LINUX being unambiguously 64bit > but there being 32bit and 64bit ALPHA_VMS. > > So, I cannot resolve all dilemas. > > I am leaning toward: > > When there is "any" amibiguity, put in 32 or 64. > If 64 occurs in processor name, put 32 or 64 at end. > "Any" ambiguity includes unreleased NT/alpha64. > > Leading to: > ?ALPHA32_NT > ?ALPHA64_NT > ?ALPHA32_VMS > ?ALPHA64_VMS > ?IA64_HPUX32 (yuck) > ?IA64_HPUX64 ?(yuck) > ?ALPHA_LINUX > ?? > > ?IPF32_HPUX > ?and IA32_HPUX > ?are tempting I admit. > ?- Jay > > > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ > *From:* Jay K > *Sent:* Wednesday, December 29, 2021 5:56 PM > *To:* m3devel > *Subject:* IA64_HPUX target names? > Hi. I have an HP-UX/IA64 machine. > This system is "funny" in that it supports 32bit and 64bit pointer sizes. > I guess 32bit pointer/long are really good for compatibility with older source code. > ?Esp. 10+ years ago. (more recently, support for 32bit is being dropped). > Modula-3 does not need this, but for hypothetical linking to old C/C++ code and completeness. > > So we need some target names: > ?- do nothing, wierd unpopular system > ?- IA64_HPUX with 64bit integer/pointer, and no 32bit system > ?- IA6464_HPUX, IA6432_HPUX > ?- IA64_HPUX, IA32_HPUX (IA32 can mean x86, but there is no HP-UX/x86) > But I have never seen IA32 mean Itanium. > ?- IA64_HPUX implied 64bit, IA64_HPUX32 > ? ? This is my favorite by a small margin. > ?- IA64_HPUX64, IA64_HPUX32? > ?- ITANIUM64_HPUX ITANIUM32_HPUX > > I don't think there is any precedent. > In that, usually the numbers "32" and "64" in an architecture imply the pointer size, and IA64 is a popular name for this. > > Also this is Itanium2. Itanium1 was an even older and lower volume system. > > IA64 is particularly unusual in having "two stacks". > Registers are spilled "behind the scenes" to a stack that starts at the same base as the "normal" stack, but grows up. > That is my understanding. > > I'd really like to get away from a conservative GC, but this is what we have "for now". > > I realize HP-UX and IA64 are both kinda useless. > > I don't have git yet so this'll be a short while still. > > ?- Jay > > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://m3lists.elegosoft.com/mailman/listinfo/m3devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney.bates at gmx.com Fri Dec 31 18:41:09 2021 From: rodney.bates at gmx.com (Rodney Bates) Date: Fri, 31 Dec 2021 11:41:09 -0600 Subject: [M3devel] IA64_HPUX target names? In-Reply-To: References: Message-ID: <9fa0797f-ff44-2279-3c72-988ced9e7576@gmx.com> On 12/31/21 11:38 AM, I wrote: > > > On 12/30/21 7:44 PM, Jay K wrote: >> I've been mulling this over a bit. Kinda a waste, granted. >> >> There's no great answer. >> >> And it doesn't matter much. > > I don't consider making good names of anything to be unimportant. > I've spent too many hours in maintenance work trying to figure > out things with names that are ambiguous, uninformative, > or worst, downright misleading. OTOH, there is the matter of name changes introducing bitrot to existing code, scripts, user procedures, etc. >> >> There are so many other approaches, but we are kinda stuck for now. >> We could build to current directory (preferably that user creates outside of source) or a generically named "out". >> >> We could call Itanium IPF or such as it is sometimes. >> >> The problem is I don't want things like IA6432 or IA6464. >> >> I don't love the symmetry of IA64_HPUX and IA64_HPUX32 >> >> I don't love having "32" and "64" in the same name. >> >> I don't love IA64_HPUX64 either. >> >> I don't even really love ALPHA_LINUX being unambiguously 64bit >> but there being 32bit and 64bit ALPHA_VMS. >> >> So, I cannot resolve all dilemas. >> >> I am leaning toward: >> >> When there is "any" amibiguity, put in 32 or 64. >> If 64 occurs in processor name, put 32 or 64 at end. >> "Any" ambiguity includes unreleased NT/alpha64. >> >> Leading to: >> ?ALPHA32_NT >> ?ALPHA64_NT >> ?ALPHA32_VMS >> ?ALPHA64_VMS >> ?IA64_HPUX32 (yuck) >> ?IA64_HPUX64 ?(yuck) >> ?ALPHA_LINUX >> ?? >> >> ?IPF32_HPUX >> ?and IA32_HPUX >> ?are tempting I admit. >> ?- Jay >> >> >> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ >> *From:* Jay K >> *Sent:* Wednesday, December 29, 2021 5:56 PM >> *To:* m3devel >> *Subject:* IA64_HPUX target names? >> Hi. I have an HP-UX/IA64 machine. >> This system is "funny" in that it supports 32bit and 64bit pointer sizes. >> I guess 32bit pointer/long are really good for compatibility with older source code. >> ?Esp. 10+ years ago. (more recently, support for 32bit is being dropped). >> Modula-3 does not need this, but for hypothetical linking to old C/C++ code and completeness. >> >> So we need some target names: >> ?- do nothing, wierd unpopular system >> ?- IA64_HPUX with 64bit integer/pointer, and no 32bit system >> ?- IA6464_HPUX, IA6432_HPUX >> ?- IA64_HPUX, IA32_HPUX (IA32 can mean x86, but there is no HP-UX/x86) >> But I have never seen IA32 mean Itanium. >> ?- IA64_HPUX implied 64bit, IA64_HPUX32 >> ? ? This is my favorite by a small margin. >> ?- IA64_HPUX64, IA64_HPUX32? >> ?- ITANIUM64_HPUX ITANIUM32_HPUX >> >> I don't think there is any precedent. >> In that, usually the numbers "32" and "64" in an architecture imply the pointer size, and IA64 is a popular name for this. >> >> Also this is Itanium2. Itanium1 was an even older and lower volume system. >> >> IA64 is particularly unusual in having "two stacks". >> Registers are spilled "behind the scenes" to a stack that starts at the same base as the "normal" stack, but grows up. >> That is my understanding. >> >> I'd really like to get away from a conservative GC, but this is what we have "for now". >> >> I realize HP-UX and IA64 are both kinda useless. >> >> I don't have git yet so this'll be a short while still. >> >> ?- Jay >> >> _______________________________________________ >> M3devel mailing list >> M3devel at elegosoft.com >> https://m3lists.elegosoft.com/mailman/listinfo/m3devel > > > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://m3lists.elegosoft.com/mailman/listinfo/m3devel -------------- next part -------------- An HTML attachment was scrubbed... URL: