From jay.krell at cornell.edu Sat May 2 11:16:49 2015 From: jay.krell at cornell.edu (Jay K) Date: Sat, 2 May 2015 09:16:49 +0000 Subject: [M3devel] the need for cooperative suspend Message-ID: We really need to move away from preemptive suspend. 1) It is a large fraction of the target-dependent code in m3core. 2) It doesn't really work in "wow64", the x86-on-amd64 Windows system. The SuspendThread + GetThreadContext does not actually reliably give you current and coherent context. I'm not sure about x86-on-ia64. The context can be old. The context can be mid-update. Which might be ok, depending on what the updates are. LIke if Eip and Esp are being updated, we don't care about Eip anyway. You can find out if either is the case, and let the thread run longer, but being in a long running syscall I believe is reported as possibly invalid even though it is valid. NT/native is ok. We should just use cooperative suspend and not worry about it. Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Sat May 2 17:57:13 2015 From: mika at async.caltech.edu (mika at async.caltech.edu) Date: Sat, 02 May 2015 08:57:13 -0700 Subject: [M3devel] the need for cooperative suspend In-Reply-To: References: Message-ID: <20150502155713.29DCC1A2062@async.async.caltech.edu> Jay, Can you explain precisely what you mean by "suspend"? A thread is suspended by ... a timer expiration? Another thread at higher priority needing resources? I'm thinking about a tight loop "for(;;) ;"... how do you stop a thread from running that (it could have been coded in assembly...)? Jay K writes: >--_6bc62225-3263-437a-a88c-4b1ff9473d58_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > >We really need to move away from preemptive suspend. > >1) It is a large fraction of the target-dependent code in m3core. >=20 > >2) It doesn't really work in "wow64"=2C the x86-on-amd64 Windows system. >The SuspendThread + GetThreadContext does not actually reliably give you >current and coherent context. >I'm not sure about x86-on-ia64. >=20 > > The context can be old. > The context can be mid-update. Which might be ok=2C depending on what the = >updates are. > LIke if Eip and Esp are being updated=2C we don't care about Eip anyway. >=20 > >You can find out if either is the case=2C and let the thread run longer=2C >but being in a long running syscall I believe is reported as possibly >invalid even though it is valid. >=20 >=20 >NT/native is ok. >=20 > >We should just use cooperative suspend and not worry about it. >=20 >=20 >Thanks=2C > - Jay > > >=20 > = > >--_6bc62225-3263-437a-a88c-4b1ff9473d58_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > >
We really need to move away from= > preemptive suspend.

1) It is a large fraction of the target-depende= >nt code in m3core.
 =3B

2) It doesn't really work in "wow64"= >=2C the x86-on-amd64 Windows system.
The SuspendThread + GetThreadContex= >t does not actually reliably give you
current and coherent context.
I= >'m not sure about x86-on-ia64.
 =3B

 =3BThe context can b= >e old.
 =3BThe context can be mid-update. Which might be ok=2C depen= >ding on what the updates are.
 =3BLIke if Eip and Esp are being upda= >ted=2C we don't care about Eip anyway.
 =3B

You can find out = >if either is the case=2C and let the thread run longer=2C
but being in a= > long running syscall I believe is reported as possibly
invalid even tho= >ugh it is valid.
 =3B
 =3B
NT/native is ok.
 =3B>
We should just use cooperative suspend and not worry about it.
&nbs= >p=3B
 =3B
Thanks=2C
 =3B- Jay


 =3B
= >
>= > >--_6bc62225-3263-437a-a88c-4b1ff9473d58_-- From jay.krell at cornell.edu Sat May 2 21:13:31 2015 From: jay.krell at cornell.edu (Jay) Date: Sat, 2 May 2015 12:13:31 -0700 Subject: [M3devel] the need for cooperative suspend In-Reply-To: <20150502155713.29DCC1A2062@async.async.caltech.edu> References: <20150502155713.29DCC1A2062@async.async.caltech.edu> Message-ID: In the preemptive case, you call SuspendThread and a hardware interrupt is sent to the processor. Cooperative suspend does not have this power. There ends up being, I guess, an analog between non-polling code and the "fixed" wow64 method that is also easily starved w/o more sophistication. Thinking more about this...maybe preemptive is viable with a little more work. In particular we can record when we leave "managed" code and leave a reliable stack pointer for ourselves. We can then safely preempt "native" code, getting context from our own data structures instead of the operating system. Native code though could allocate traced data though, without registering with the runtime somehow. - Jay On May 2, 2015, at 8:57 AM, wrote: > Jay, > > Can you explain precisely what you mean by "suspend"? > > A thread is suspended by ... a timer expiration? Another thread at higher priority needing resources? > > I'm thinking about a tight loop "for(;;) ;"... how do you stop a thread from running that (it could have > been coded in assembly...)? > > Jay K writes: >> --_6bc62225-3263-437a-a88c-4b1ff9473d58_ >> Content-Type: text/plain; charset="iso-8859-1" >> Content-Transfer-Encoding: quoted-printable >> >> We really need to move away from preemptive suspend. >> >> 1) It is a large fraction of the target-dependent code in m3core. >> =20 >> >> 2) It doesn't really work in "wow64"=2C the x86-on-amd64 Windows system. >> The SuspendThread + GetThreadContext does not actually reliably give you >> current and coherent context. >> I'm not sure about x86-on-ia64. >> =20 >> >> The context can be old. >> The context can be mid-update. Which might be ok=2C depending on what the = >> updates are. >> LIke if Eip and Esp are being updated=2C we don't care about Eip anyway. >> =20 >> >> You can find out if either is the case=2C and let the thread run longer=2C >> but being in a long running syscall I believe is reported as possibly >> invalid even though it is valid. >> =20 >> =20 >> NT/native is ok. >> =20 >> >> We should just use cooperative suspend and not worry about it. >> =20 >> =20 >> Thanks=2C >> - Jay >> >> >> =20 >> = >> >> --_6bc62225-3263-437a-a88c-4b1ff9473d58_ >> Content-Type: text/html; charset="iso-8859-1" >> Content-Transfer-Encoding: quoted-printable >> >> >> >> >>
We really need to move away from= >> preemptive suspend.

1) It is a large fraction of the target-depende= >> nt code in m3core.
 =3B

2) It doesn't really work in "wow64"= >> =2C the x86-on-amd64 Windows system.
The SuspendThread + GetThreadContex= >> t does not actually reliably give you
current and coherent context.
I= >> 'm not sure about x86-on-ia64.
 =3B

 =3BThe context can b= >> e old.
 =3BThe context can be mid-update. Which might be ok=2C depen= >> ding on what the updates are.
 =3BLIke if Eip and Esp are being upda= >> ted=2C we don't care about Eip anyway.
 =3B

You can find out = >> if either is the case=2C and let the thread run longer=2C
but being in a= >> long running syscall I believe is reported as possibly
invalid even tho= >> ugh it is valid.
 =3B
 =3B
NT/native is ok.
 =3B>>
We should just use cooperative suspend and not worry about it.
&nbs= >> p=3B
 =3B
Thanks=2C
 =3B- Jay


 =3B
= >>
>> = >> >> --_6bc62225-3263-437a-a88c-4b1ff9473d58_-- From rodney_bates at lcwb.coop Fri May 15 21:50:28 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Fri, 15 May 2015 14:50:28 -0500 Subject: [M3devel] Not getting github notifications Message-ID: <55564E04.1080401@lcwb.coop> After a lot of poking around in github.com/modula3, it is apparent that there has been some activity that I hadn't heard about. I have, for some time, had my account set up so that (I thought) I would get generated emails for pushes to the repository. But apparently, it only works when _I_ push, which, of course, is not big news to me. I also tried adding m3commit at elegosoft.com to the list of email addresses to be sent to, but that one doesn't come through at all. Any advice? -- Rodney Bates rodney.m.bates at acm.org From wagner at elegosoft.com Sun May 17 01:18:24 2015 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 17 May 2015 01:18:24 +0200 Subject: [M3devel] Bootstrapping cm3 on OS X 10.9.5 Message-ID: <20150517011824.75f096c832d5da56e4810bbf@elegosoft.com> After several years I've just tried to setup a current cm3 on my computer again. I've cloned the repository from github/modula3/cm3, installed the latest binary archive for Darwin I could find -- which is that of the 5.8.6 release several years ago -- and tried to compile some sources. This always fails with lots of these errors: m3cc (aka cm3cg) failed compiling: PklFpMap.mc new source -> compiling FpIntTbl.m3 m3cgc1: fatal error: *** illegal type: 0x17, at m3cg_lineno 4 compilation terminated. regardless if I use the 5.8.6 backend or build a new cm3cg from sources (which actually succeeds). Any suggestions how to continue? Are newer bootstrap archives available somewhere? Any hints are appreciated. Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From rodney_bates at lcwb.coop Sun May 17 16:48:00 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sun, 17 May 2015 09:48:00 -0500 Subject: [M3devel] Bootstrapping cm3 on OS X 10.9.5 In-Reply-To: <20150517011824.75f096c832d5da56e4810bbf@elegosoft.com> References: <20150517011824.75f096c832d5da56e4810bbf@elegosoft.com> Message-ID: <5558AA20.1090208@lcwb.coop> This is a familiar error to me, but I can't remember the details right off hand. I would have said it was an old m3cc, but you have built the latest one, so that theory goes down the drain. I'll see what I can reconstruct. On 05/16/2015 06:18 PM, Olaf Wagner wrote: > After several years I've just tried to setup a current cm3 on my computer > again. I've cloned the repository from github/modula3/cm3, installed > the latest binary archive for Darwin I could find -- which is that of > the 5.8.6 release several years ago -- and tried to compile some sources. > > This always fails with lots of these errors: > > m3cc (aka cm3cg) failed compiling: PklFpMap.mc > new source -> compiling FpIntTbl.m3 > m3cgc1: fatal error: *** illegal type: 0x17, at m3cg_lineno 4 > compilation terminated. > > regardless if I use the 5.8.6 backend or build a new cm3cg from > sources (which actually succeeds). > > Any suggestions how to continue? > Are newer bootstrap archives available somewhere? > Any hints are appreciated. > > Olaf > -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Mon May 18 18:34:58 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Mon, 18 May 2015 11:34:58 -0500 Subject: [M3devel] Bootstrapping cm3 on OS X 10.9.5 In-Reply-To: <5558AA20.1090208@lcwb.coop> References: <20150517011824.75f096c832d5da56e4810bbf@elegosoft.com> <5558AA20.1090208@lcwb.coop> Message-ID: <555A14B2.7090900@lcwb.coop> Well, I have not been able to reproduce this on AMD64_LINUX, nor see by looking at code what it might be. ISTR that it is some kind of front-end/back-end mismatch. But the CGType codes that m3cc in trying to read have not changed in either the front-end nor the back-end since the release. 0x17 is well out of range. m3cc must be lost and trying to interpret something else as a type. On 05/17/2015 09:48 AM, Rodney M. Bates wrote: > This is a familiar error to me, but I can't remember the details right off hand. > I would have said it was an old m3cc, but you have built the latest one, > so that theory goes down the drain. I'll see what I can reconstruct. > > On 05/16/2015 06:18 PM, Olaf Wagner wrote: >> After several years I've just tried to setup a current cm3 on my computer >> again. I've cloned the repository from github/modula3/cm3, installed >> the latest binary archive for Darwin I could find -- which is that of >> the 5.8.6 release several years ago -- and tried to compile some sources. >> >> This always fails with lots of these errors: >> >> m3cc (aka cm3cg) failed compiling: PklFpMap.mc >> new source -> compiling FpIntTbl.m3 >> m3cgc1: fatal error: *** illegal type: 0x17, at m3cg_lineno 4 >> compilation terminated. >> >> regardless if I use the 5.8.6 backend or build a new cm3cg from >> sources (which actually succeeds). >> >> Any suggestions how to continue? >> Are newer bootstrap archives available somewhere? >> Any hints are appreciated. >> >> Olaf >> > -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Mon May 18 18:55:10 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Mon, 18 May 2015 11:55:10 -0500 Subject: [M3devel] Bootstrapping cm3 on OS X 10.9.5 In-Reply-To: <555A14B2.7090900@lcwb.coop> References: <20150517011824.75f096c832d5da56e4810bbf@elegosoft.com> <5558AA20.1090208@lcwb.coop> <555A14B2.7090900@lcwb.coop> Message-ID: <555A196E.2020106@lcwb.coop> Olaf, I think you must have a wrong version of cm3cg. I paper-traced through the first few IR opcodes of PklFpMap.mc (as generated by my cm3 executable, fairly recently built from the git repository) and encountered several changes to the binary opcodes, one of which I made. Using a release 5.8 version of cm3cg, I got a similar (though not identical) error: rodney at allegheny:~/proj/m3/git/cm3/m3-libs/libm3/AMD64_LINUX$ /usr/local/cm3-release/bin/cm3cg -quiet -fno-reorder-blocks -funwind-tables -fPIC -m64 -gstabs+ PklFpMap.mc -o PklFpMap.ms cm3cg: fatal error: *** illegal type: 0x20, at m3cg_lineno 2 compilation terminated. The type 0x20 and and m3cg_lineno 2 values agree with what I expect from the source code I have for the release branch, CVS repository. That suggests you have a third version of cm3cg. (Or maybe not the right version of cm3 front-end?) This is on AMD64_LINUX. On 05/18/2015 11:34 AM, Rodney M. Bates wrote: > Well, I have not been able to reproduce this on AMD64_LINUX, nor see by looking > at code what it might be. ISTR that it is some kind of front-end/back-end > mismatch. But the CGType codes that m3cc in trying to read have not changed > in either the front-end nor the back-end since the release. 0x17 is well > out of range. m3cc must be lost and trying to interpret something else as > a type. > > On 05/17/2015 09:48 AM, Rodney M. Bates wrote: >> This is a familiar error to me, but I can't remember the details right off hand. >> I would have said it was an old m3cc, but you have built the latest one, >> so that theory goes down the drain. I'll see what I can reconstruct. >> >> On 05/16/2015 06:18 PM, Olaf Wagner wrote: >>> After several years I've just tried to setup a current cm3 on my computer >>> again. I've cloned the repository from github/modula3/cm3, installed >>> the latest binary archive for Darwin I could find -- which is that of >>> the 5.8.6 release several years ago -- and tried to compile some sources. >>> >>> This always fails with lots of these errors: >>> >>> m3cc (aka cm3cg) failed compiling: PklFpMap.mc >>> new source -> compiling FpIntTbl.m3 >>> m3cgc1: fatal error: *** illegal type: 0x17, at m3cg_lineno 4 >>> compilation terminated. >>> >>> regardless if I use the 5.8.6 backend or build a new cm3cg from >>> sources (which actually succeeds). >>> >>> Any suggestions how to continue? >>> Are newer bootstrap archives available somewhere? >>> Any hints are appreciated. >>> >>> Olaf >>> >> > -- Rodney Bates rodney.m.bates at acm.org From wagner at elegosoft.com Mon May 18 23:47:14 2015 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 18 May 2015 23:47:14 +0200 Subject: [M3devel] Bootstrapping cm3 on OS X 10.9.5 In-Reply-To: <555A196E.2020106@lcwb.coop> References: <20150517011824.75f096c832d5da56e4810bbf@elegosoft.com> <5558AA20.1090208@lcwb.coop> <555A14B2.7090900@lcwb.coop> <555A196E.2020106@lcwb.coop> Message-ID: <20150518234714.dd1c111374ba3614cd74a63e@elegosoft.com> On Mon, 18 May 2015 11:55:10 -0500 "Rodney M. Bates" wrote: > Olaf, I think you must have a wrong version of cm3cg. I paper-traced through the first > few IR opcodes of PklFpMap.mc (as generated by my cm3 executable, fairly recently built > from the git repository) and encountered several changes to the binary opcodes, > one of which I made. Using a release 5.8 version of cm3cg, I got a similar (though > not identical) error: > > rodney at allegheny:~/proj/m3/git/cm3/m3-libs/libm3/AMD64_LINUX$ /usr/local/cm3-release/bin/cm3cg -quiet -fno-reorder-blocks -funwind-tables -fPIC -m64 -gstabs+ PklFpMap.mc -o PklFpMap.ms > cm3cg: fatal error: *** illegal type: 0x20, at m3cg_lineno 2 > compilation terminated. > > The type 0x20 and and m3cg_lineno 2 values agree with what I expect from the source code > I have for the release branch, CVS repository. That suggests you have a third version > of cm3cg. (Or maybe not the right version of cm3 front-end?) > > This is on AMD64_LINUX. OK, I'll try to check that again. Thank you very much for the help. It may take some time but I'll let you know what I find out. Weekend is over... Olaf > On 05/18/2015 11:34 AM, Rodney M. Bates wrote: > > Well, I have not been able to reproduce this on AMD64_LINUX, nor see by looking > > at code what it might be. ISTR that it is some kind of front-end/back-end > > mismatch. But the CGType codes that m3cc in trying to read have not changed > > in either the front-end nor the back-end since the release. 0x17 is well > > out of range. m3cc must be lost and trying to interpret something else as > > a type. > > > > On 05/17/2015 09:48 AM, Rodney M. Bates wrote: > >> This is a familiar error to me, but I can't remember the details right off hand. > >> I would have said it was an old m3cc, but you have built the latest one, > >> so that theory goes down the drain. I'll see what I can reconstruct. > >> > >> On 05/16/2015 06:18 PM, Olaf Wagner wrote: > >>> After several years I've just tried to setup a current cm3 on my computer > >>> again. I've cloned the repository from github/modula3/cm3, installed > >>> the latest binary archive for Darwin I could find -- which is that of > >>> the 5.8.6 release several years ago -- and tried to compile some sources. > >>> > >>> This always fails with lots of these errors: > >>> > >>> m3cc (aka cm3cg) failed compiling: PklFpMap.mc > >>> new source -> compiling FpIntTbl.m3 > >>> m3cgc1: fatal error: *** illegal type: 0x17, at m3cg_lineno 4 > >>> compilation terminated. > >>> > >>> regardless if I use the 5.8.6 backend or build a new cm3cg from > >>> sources (which actually succeeds). > >>> > >>> Any suggestions how to continue? > >>> Are newer bootstrap archives available somewhere? > >>> Any hints are appreciated. > >>> > >>> Olaf > >>> > >> > > > > -- > Rodney Bates > rodney.m.bates at acm.org -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Tue May 19 01:33:49 2015 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 19 May 2015 01:33:49 +0200 Subject: [M3devel] Bootstrapping cm3 on OS X 10.9.5 In-Reply-To: <20150518234714.dd1c111374ba3614cd74a63e@elegosoft.com> References: <20150517011824.75f096c832d5da56e4810bbf@elegosoft.com> <5558AA20.1090208@lcwb.coop> <555A14B2.7090900@lcwb.coop> <555A196E.2020106@lcwb.coop> <20150518234714.dd1c111374ba3614cd74a63e@elegosoft.com> Message-ID: <20150519013349.0ba8729443cabb394424d3cd@elegosoft.com> On Mon, 18 May 2015 23:47:14 +0200 Olaf Wagner wrote: > On Mon, 18 May 2015 11:55:10 -0500 > "Rodney M. Bates" wrote: > > > Olaf, I think you must have a wrong version of cm3cg. I paper-traced through the first > > few IR opcodes of PklFpMap.mc (as generated by my cm3 executable, fairly recently built > > from the git repository) and encountered several changes to the binary opcodes, > > one of which I made. Using a release 5.8 version of cm3cg, I got a similar (though > > not identical) error: > > > > rodney at allegheny:~/proj/m3/git/cm3/m3-libs/libm3/AMD64_LINUX$ /usr/local/cm3-release/bin/cm3cg -quiet -fno-reorder-blocks -funwind-tables -fPIC -m64 -gstabs+ PklFpMap.mc -o PklFpMap.ms > > cm3cg: fatal error: *** illegal type: 0x20, at m3cg_lineno 2 > > compilation terminated. > > > > The type 0x20 and and m3cg_lineno 2 values agree with what I expect from the source code > > I have for the release branch, CVS repository. That suggests you have a third version > > of cm3cg. (Or maybe not the right version of cm3 front-end?) > > > > This is on AMD64_LINUX. > > OK, I'll try to check that again. Thank you very much for the help. > It may take some time but I'll let you know what I find out. Weekend > is over... Couldn't let this rest though... It seems I made a really stupid mistake by installing an I386_DARWIN archive, as I have a 64 bit processor. AMD64_DARWIN should work much better, and I've even found one from March 2011. After replacing the configuration files with those from the current code base and adapting some basic system tool definitions like gcc and libtool I have now successfully compiled m3core. This looks good so far. It would have taken me much longer without your hint. But now I need some sleep, Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From rodney_bates at lcwb.coop Tue May 19 21:32:40 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Tue, 19 May 2015 14:32:40 -0500 Subject: [M3devel] New llvm backend Message-ID: <555B8FD8.2000109@lcwb.coop> I just noticed Peter's llvm backend in the github repository. I'm glad to see it. We need this. I had started some work on this too, much of it complementary. I have a version of cm3 that integrates an llvm backend, either as a separate executable, or with (some of) llvm linked in. I will work on getting that set up for Peter's main program. I also have done quite a bit of work on expanded bindings to more llvm stuff, especially for building debug info, plus a few other things that were missing from llvm's core interface. I had started a cm3-IR to llvm-IR converter, but got bogged down in making Modula-3's recursive definitions fit llvm's. The latter was not general enough for Modula-3, at least not in a direct way. I did a lot on an algorithm to wrap a minimal set of pointers, each in an artificial llvm struct, which is the only thing the llvm IR allows forward declarations for. Just when I had a pretty good draft coded, some of the llvm folks announced that the typed pointers in their IR were really unnecessary anyway, and reworked their head to have pointers with no referent type. Since that is most of what I had coded, I think it best to abandon that and adopt Peter's. I do think it would be good to have a branch for the llvm backend work. From what I have seen so far, git branches look to be pretty easy to use. -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Tue May 19 22:17:30 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Tue, 19 May 2015 15:17:30 -0500 Subject: [M3devel] Rerunning m3cggen Message-ID: <555B9A5A.2090106@lcwb.coop> What does it take to get m3cggen to be rerun? scripts/do-pkg.sh buildship m3cc doesn't appear to do it, nor does cm3 in m3-sys/m3cc. Does it need to be done manually? -- Rodney Bates rodney.m.bates at acm.org From wagner at elegosoft.com Tue May 19 23:56:09 2015 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 19 May 2015 23:56:09 +0200 Subject: [M3devel] Bootstrapping cm3 on OS X 10.9.5 In-Reply-To: <20150519013349.0ba8729443cabb394424d3cd@elegosoft.com> References: <20150517011824.75f096c832d5da56e4810bbf@elegosoft.com> <5558AA20.1090208@lcwb.coop> <555A14B2.7090900@lcwb.coop> <555A196E.2020106@lcwb.coop> <20150518234714.dd1c111374ba3614cd74a63e@elegosoft.com> <20150519013349.0ba8729443cabb394424d3cd@elegosoft.com> Message-ID: <20150519235609.41e93f178398d113bdecb79d@elegosoft.com> On Tue, 19 May 2015 01:33:49 +0200 Olaf Wagner wrote: > After replacing the configuration files with those from the current code > base and adapting some basic system tool definitions like gcc and libtool > I have now successfully compiled m3core. This looks good so far. I almost succeeded in building a new cm3 from sources now, but I'm stuck at something again I don't understand. Symbol ___eprintf is referenced from m3core, but there is no static definition for it in any library I can find. -> linking cm3 generate _m3main.new compare _m3main.new _m3main.c rm _m3main.new /usr/bin/gcc -o cm3 _m3main.o cm3unix.o Version.io M3Backend.io M3Backend.mo UtilsPosix.mo Arg.io Arg.mo Builder.io Builder.mo Dirs.io Dirs.mo M3Build.io M3Build.mo M3Loc.io M3Loc.mo M3Options.io M3Options.mo M3Unit.io M3Unit.mo Makefile.io Makefile.mo Msg.io Msg.mo Utils.io Utils.mo WebFile.io WebFile.mo Main.mo /usr/local/cm3/pkg/m3back/AMD64_DARWIN/libm3back.a /usr/local/cm3/pkg/m3objfile/AMD64_DARWIN/libm3objfile.a /usr/local/cm3/pkg/m3quake/AMD64_DARWIN/libm3quake.a /usr/local/cm3/pkg/m3front/AMD64_DARWIN/libm3front.a /usr/local/cm3/pkg/m3linker/AMD64_DARWIN/libm3link.a /usr/local/cm3/pkg/m3middle/AMD64_DARWIN/libm3middle.a /usr/local/cm3/pkg/sysutils/AMD64_DARWIN/libsysutils.a /usr/local/cm3/pkg/libm3/AMD64_DARWIN/libm3.a /usr/local/cm3/pkg/m3core/AMD64_DARWIN/libm3core.a -multiply_defined suppress -bind_at_load -shared-libgcc -dead_strip -headerpad_max_install_names Undefined symbols for architecture x86_64: "___eprintf", referenced from: _ThreadPThread__ProcessStopped in libm3core.a(ThreadApple.o) _InstallOneHandler in libm3core.a(RTSignalC.o) ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) ---- elegos-MacBook-Pro:cm3 wagner$ for f in $(find /usr/lib /usr/local/lib /opt/local/lib /usr/local/cm3/lib -name *.a); do nm $f 2>/dev/null | grep ___eprintf && echo "found in $f"; done U ___eprintf U ___eprintf found in /usr/local/cm3/lib/libm3core.a ---- elegos-MacBook-Pro:cm3 wagner$ for f in $(find /usr/lib /usr/local/lib /opt/local/lib /usr/local/cm3/lib -name *.dylib); do nm $f 2>/dev/null | grep ___eprintf && echo "found in $f"; done U ___eprintf 000141c0 t ___eprintf found in /usr/lib/lib6200Lib.dylib U ___eprintf 00019bf0 t ___eprintf found in /usr/lib/lib7225lib.dylib 00016c60 t ___eprintf U ___eprintf found in /usr/lib/lib8200Alib.dylib 00017d30 t ___eprintf U ___eprintf found in /usr/lib/lib8220lib.dylib U ___eprintf 00009a10 t ___eprintf found in /usr/lib/libAgent.dylib U ___eprintf 00018f00 t ___eprintf found in /usr/lib/libIceraDownloadLib.dylib U ___eprintf 000081bb t ___eprintf found in /usr/lib/libTinyXml.dylib 0000000000001850 t ___eprintf found in /usr/local/cm3/lib/libm3core.5.2.dylib 0000000000001850 t ___eprintf found in /usr/local/cm3/lib/libm3core.5.dylib 0000000000001850 t ___eprintf found in /usr/local/cm3/lib/libm3core.dylib ---- Does anybody know what it the standard solution for this? The symbol is even defined in the dynamic version of m3core itself. Is static linking not supported anymore? Or should I just link against one of the above dynamically? The m3makefile for cm3 still contains build_standalone () %-- we don't want to depend on the shared libraries... Any hint will be appreciated. Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Wed May 20 00:21:41 2015 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 20 May 2015 00:21:41 +0200 Subject: [M3devel] Rerunning m3cggen In-Reply-To: <555B9A5A.2090106@lcwb.coop> References: <555B9A5A.2090106@lcwb.coop> Message-ID: <20150520002141.1291106319a5d76adad4415e@elegosoft.com> On Tue, 19 May 2015 15:17:30 -0500 "Rodney M. Bates" wrote: > What does it take to get m3cggen to be rerun? scripts/do-pkg.sh buildship m3cc doesn't > appear to do it, nor does cm3 in m3-sys/m3cc. Does it need to be done manually? As long as I remember, I never automated anything that runs m3cggen. So I assume the answer should be yes. Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Wed May 20 21:01:09 2015 From: jay.krell at cornell.edu (Jay K) Date: Wed, 20 May 2015 19:01:09 +0000 Subject: [M3devel] Rerunning m3cggen In-Reply-To: <20150520002141.1291106319a5d76adad4415e@elegosoft.com> References: <555B9A5A.2090106@lcwb.coop>, <20150520002141.1291106319a5d76adad4415e@elegosoft.com> Message-ID: I think I automated it. But historically, in those other paths, it wasn't automated.Not a problem with the C backend. :) - Jay > Date: Wed, 20 May 2015 00:21:41 +0200 > From: wagner at elegosoft.com > To: rodney.m.bates at acm.org > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Rerunning m3cggen > > On Tue, 19 May 2015 15:17:30 -0500 > "Rodney M. Bates" wrote: > > > What does it take to get m3cggen to be rerun? scripts/do-pkg.sh buildship m3cc doesn't > > appear to do it, nor does cm3 in m3-sys/m3cc. Does it need to be done manually? > > As long as I remember, I never automated anything that runs m3cggen. > So I assume the answer should be yes. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed May 20 21:11:22 2015 From: jay.krell at cornell.edu (Jay K) Date: Wed, 20 May 2015 19:11:22 +0000 Subject: [M3devel] Bootstrapping cm3 on OS X 10.9.5 In-Reply-To: <20150519235609.41e93f178398d113bdecb79d@elegosoft.com> References: <20150517011824.75f096c832d5da56e4810bbf@elegosoft.com>, <5558AA20.1090208@lcwb.coop> <555A14B2.7090900@lcwb.coop>, <555A196E.2020106@lcwb.coop>, <20150518234714.dd1c111374ba3614cd74a63e@elegosoft.com>, <20150519013349.0ba8729443cabb394424d3cd@elegosoft.com>, <20150519235609.41e93f178398d113bdecb79d@elegosoft.com> Message-ID: Hi Olaf, This is surely some printf/sprint wrapper from stdio.h.Did you copy files across from some other machine or this is all one-machine?Try the C backend? I -lSystem? #include int main(){char buffer[10];printf("");sprint(buffer, "");return 0;} gcc -E 1.c gcc -S 1.c gcc 1.c gcc -v 1.c libtool a.out ? Hopefully I'll find more time here.. - Jay > Date: Tue, 19 May 2015 23:56:09 +0200 > From: wagner at elegosoft.com > To: rodney.m.bates at acm.org; m3devel at elegosoft.com > Subject: Re: [M3devel] Bootstrapping cm3 on OS X 10.9.5 > > On Tue, 19 May 2015 01:33:49 +0200 > Olaf Wagner wrote: > > > After replacing the configuration files with those from the current code > > base and adapting some basic system tool definitions like gcc and libtool > > I have now successfully compiled m3core. This looks good so far. > > I almost succeeded in building a new cm3 from sources now, but I'm > stuck at something again I don't understand. Symbol ___eprintf is > referenced from m3core, but there is no static definition for it in > any library I can find. > > -> linking cm3 > generate _m3main.new > compare _m3main.new _m3main.c > rm _m3main.new > /usr/bin/gcc -o cm3 _m3main.o cm3unix.o Version.io M3Backend.io M3Backend.mo UtilsPosix.mo Arg.io Arg.mo Builder.io Builder.mo Dirs.io Dirs.mo M3Build.io M3Build.mo M3Loc.io M3Loc.mo M3Options.io M3Options.mo M3Unit.io M3Unit.mo Makefile.io Makefile.mo Msg.io Msg.mo Utils.io Utils.mo WebFile.io WebFile.mo Main.mo /usr/local/cm3/pkg/m3back/AMD64_DARWIN/libm3back.a /usr/local/cm3/pkg/m3objfile/AMD64_DARWIN/libm3objfile.a /usr/local/cm3/pkg/m3quake/AMD64_DARWIN/libm3quake.a /usr/local/cm3/pkg/m3front/AMD64_DARWIN/libm3front.a /usr/local/cm3/pkg/m3linker/AMD64_DARWIN/libm3link.a /usr/local/cm3/pkg/m3middle/AMD64_DARWIN/libm3middle.a /usr/local/cm3/pkg/sysutils/AMD64_DARWIN/libsysutils.a /usr/local/cm3/pkg/libm3/AMD64_DARWIN/libm3.a /usr/local/cm3/pkg/m3core/AMD64_DARWIN/libm3core.a -multiply_defined suppress -bind_at_load -shared-libgcc -dead_strip -headerpad_max_install_names > Undefined symbols for architecture x86_64: > "___eprintf", referenced from: > _ThreadPThread__ProcessStopped in libm3core.a(ThreadApple.o) > _InstallOneHandler in libm3core.a(RTSignalC.o) > ld: symbol(s) not found for architecture x86_64 > clang: error: linker command failed with exit code 1 (use -v to see invocation) > > ---- > > elegos-MacBook-Pro:cm3 wagner$ for f in $(find /usr/lib /usr/local/lib /opt/local/lib /usr/local/cm3/lib -name *.a); do nm $f 2>/dev/null | grep ___eprintf && echo "found in $f"; done > U ___eprintf > U ___eprintf > found in /usr/local/cm3/lib/libm3core.a > > ---- > > elegos-MacBook-Pro:cm3 wagner$ for f in $(find /usr/lib /usr/local/lib /opt/local/lib /usr/local/cm3/lib -name *.dylib); do nm $f 2>/dev/null | grep ___eprintf && echo "found in $f"; done > U ___eprintf > 000141c0 t ___eprintf > found in /usr/lib/lib6200Lib.dylib > U ___eprintf > 00019bf0 t ___eprintf > found in /usr/lib/lib7225lib.dylib > 00016c60 t ___eprintf > U ___eprintf > found in /usr/lib/lib8200Alib.dylib > 00017d30 t ___eprintf > U ___eprintf > found in /usr/lib/lib8220lib.dylib > U ___eprintf > 00009a10 t ___eprintf > found in /usr/lib/libAgent.dylib > U ___eprintf > 00018f00 t ___eprintf > found in /usr/lib/libIceraDownloadLib.dylib > U ___eprintf > 000081bb t ___eprintf > found in /usr/lib/libTinyXml.dylib > 0000000000001850 t ___eprintf > found in /usr/local/cm3/lib/libm3core.5.2.dylib > 0000000000001850 t ___eprintf > found in /usr/local/cm3/lib/libm3core.5.dylib > 0000000000001850 t ___eprintf > found in /usr/local/cm3/lib/libm3core.dylib > > ---- > > Does anybody know what it the standard solution for this? > The symbol is even defined in the dynamic version of m3core itself. > Is static linking not supported anymore? Or should I just link > against one of the above dynamically? > The m3makefile for cm3 still contains > > build_standalone () %-- we don't want to depend on the shared libraries... > > > Any hint will be appreciated. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Wed May 20 22:12:50 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Wed, 20 May 2015 15:12:50 -0500 Subject: [M3devel] Rerunning m3cggen In-Reply-To: References: <555B9A5A.2090106@lcwb.coop>, <20150520002141.1291106319a5d76adad4415e@elegosoft.com> Message-ID: <555CEAC2.8050202@lcwb.coop> So what command(s) now take care of it? I wasn't getting it to happen, until I did it manually. On 05/20/2015 02:01 PM, Jay K wrote: > I think I automated it. But historically, in those other paths, it wasn't automated. > Not a problem with the C backend. :) > > - Jay > > > > > Date: Wed, 20 May 2015 00:21:41 +0200 > > From: wagner at elegosoft.com > > To: rodney.m.bates at acm.org > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] Rerunning m3cggen > > > > On Tue, 19 May 2015 15:17:30 -0500 > > "Rodney M. Bates" wrote: > > > > > What does it take to get m3cggen to be rerun? scripts/do-pkg.sh buildship m3cc doesn't > > > appear to do it, nor does cm3 in m3-sys/m3cc. Does it need to be done manually? > > > > As long as I remember, I never automated anything that runs m3cggen. > > So I assume the answer should be yes. > > > > Olaf > > -- > > Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > > Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -- Rodney Bates rodney.m.bates at acm.org From wagner at elegosoft.com Thu May 21 01:51:15 2015 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 21 May 2015 01:51:15 +0200 Subject: [M3devel] Bootstrapping cm3 on OS X 10.9.5 In-Reply-To: References: <20150517011824.75f096c832d5da56e4810bbf@elegosoft.com> <5558AA20.1090208@lcwb.coop> <555A14B2.7090900@lcwb.coop> <555A196E.2020106@lcwb.coop> <20150518234714.dd1c111374ba3614cd74a63e@elegosoft.com> <20150519013349.0ba8729443cabb394424d3cd@elegosoft.com> <20150519235609.41e93f178398d113bdecb79d@elegosoft.com> Message-ID: <20150521015115.1c558406fe4358c833242628@elegosoft.com> On Wed, 20 May 2015 19:11:22 +0000 Jay K wrote: > Hi Olaf, > This is surely some printf/sprint wrapper from stdio.h.Did you copy files across from some other machine or this is all one-machine?Try the C backend? I > -lSystem? > > #include int main(){char buffer[10];printf("");sprint(buffer, "");return 0;} > gcc -E 1.c gcc -S 1.c gcc 1.c gcc -v 1.c libtool a.out ? > Hopefully I'll find more time here.. Of course the binary distribution came from another machine and was several years old and had a different setup than my current computer. However, I think I had enough of an idea what was going on finally, and with much tweaking and manual intervention I was able to do a complete bootstrap. I've compiled all the packages now, and the demo programs I tried worked as expected (fisheye, Solitaire). Trying the C backend would have been my next attempt ;-) If anybody is interested in a copy of the installed system I can try to upload that somewhere in the next week. I'm not sure if there is currently a repository for packages or installation archives different from the old one on the M3 (elego) web site, which contains only packages several years old. Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Thu May 21 10:05:31 2015 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 21 May 2015 10:05:31 +0200 Subject: [M3devel] Repo access, was: Re: Bootstrapping cm3 on OS X 10.9.5 In-Reply-To: References: <20150517011824.75f096c832d5da56e4810bbf@elegosoft.com> <5558AA20.1090208@lcwb.coop> <555A14B2.7090900@lcwb.coop> <555A196E.2020106@lcwb.coop> <20150518234714.dd1c111374ba3614cd74a63e@elegosoft.com> <20150519013349.0ba8729443cabb394424d3cd@elegosoft.com> <20150519235609.41e93f178398d113bdecb79d@elegosoft.com> <20150521015115.1c558406fe4358c833242628@elegosoft.com> Message-ID: <20150521100531.8ca0c02c2553e513e480e6dc@elegosoft.com> On Wed, 20 May 2015 20:58:13 -0400 Antony Hosking wrote: > That's great! > I suppose bootstrap binaries should go on guthub? Can I get commit permissions again? I think I read somewhere that you managed that now. elegos-MacBook-Pro:cm3 wagner$ git push X11 forwarding request failed on channel 0 ERROR: Permission to modula3/cm3.git denied to olaf-wagner. fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. I'd just like to increase the compiler version number and make some minor updates to scripts. You can find me among the watchers of cm3. Olaf > Sent from my iPhone > > > On May 20, 2015, at 7:51 PM, Olaf Wagner wrote: > > > > On Wed, 20 May 2015 19:11:22 +0000 > > Jay K wrote: > > > >> Hi Olaf, > >> This is surely some printf/sprint wrapper from stdio.h.Did you copy files across from some other machine or this is all one-machine?Try the C backend? I > >> -lSystem? > >> > >> #include int main(){char buffer[10];printf("");sprint(buffer, "");return 0;} > >> gcc -E 1.c gcc -S 1.c gcc 1.c gcc -v 1.c libtool a.out ? > >> Hopefully I'll find more time here.. > > > > Of course the binary distribution came from another machine and was > > several years old and had a different setup than my current computer. > > > > However, I think I had enough of an idea what was going on finally, > > and with much tweaking and manual intervention I was able to do a > > complete bootstrap. I've compiled all the packages now, and > > the demo programs I tried worked as expected (fisheye, Solitaire). > > > > Trying the C backend would have been my next attempt ;-) > > > > If anybody is interested in a copy of the installed system I can try > > to upload that somewhere in the next week. I'm not sure if there is > > currently a repository for packages or installation archives different > > from the old one on the M3 (elego) web site, which contains only > > packages several years old. > > > > Olaf > > -- > > Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > > Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From estellnb at elstel.org Thu May 21 12:07:53 2015 From: estellnb at elstel.org (Elmar Stellnberger) Date: Thu, 21 May 2015 12:07:53 +0200 Subject: [M3devel] Bootstrapping cm3 on OS X 10.9.5 In-Reply-To: <20150521015115.1c558406fe4358c833242628@elegosoft.com> References: <20150517011824.75f096c832d5da56e4810bbf@elegosoft.com> <5558AA20.1090208@lcwb.coop> <555A14B2.7090900@lcwb.coop> <555A196E.2020106@lcwb.coop> <20150518234714.dd1c111374ba3614cd74a63e@elegosoft.com> <20150519013349.0ba8729443cabb394424d3cd@elegosoft.com> <20150519235609.41e93f178398d113bdecb79d@elegosoft.com> <20150521015115.1c558406fe4358c833242628@elegosoft.com> Message-ID: <40F30E19-16FB-4993-9712-3B67B9A624B4@elstel.org> Dear Olaf, I have Mac OS 10.7.5 here and would like to give your new binaries a try. Do the binaries include a version of Qt or will I have to install qt4/5 in addition to your binaries? It should not be a problem for me if Qt is only available to C/C++ externals. Elmar Am 21.05.2015 um 01:51 schrieb Olaf Wagner: > On Wed, 20 May 2015 19:11:22 +0000 > Jay K wrote: > >> Hi Olaf, >> This is surely some printf/sprint wrapper from stdio.h.Did you copy files across from some other machine or this is all one-machine?Try the C backend? I >> -lSystem? >> >> #include int main(){char buffer[10];printf("");sprint(buffer, "");return 0;} >> gcc -E 1.c gcc -S 1.c gcc 1.c gcc -v 1.c libtool a.out ? >> Hopefully I'll find more time here.. > > Of course the binary distribution came from another machine and was > several years old and had a different setup than my current computer. > > However, I think I had enough of an idea what was going on finally, > and with much tweaking and manual intervention I was able to do a > complete bootstrap. I've compiled all the packages now, and > the demo programs I tried worked as expected (fisheye, Solitaire). > > Trying the C backend would have been my next attempt ;-) > > If anybody is interested in a copy of the installed system I can try > to upload that somewhere in the next week. I'm not sure if there is > currently a repository for packages or installation archives different > from the old one on the M3 (elego) web site, which contains only > packages several years old. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From wagner at elegosoft.com Thu May 21 17:50:16 2015 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 21 May 2015 17:50:16 +0200 Subject: [M3devel] Qt bindings, was: Re: Bootstrapping cm3 on OS X 10.9.5 In-Reply-To: <40F30E19-16FB-4993-9712-3B67B9A624B4@elstel.org> References: <20150517011824.75f096c832d5da56e4810bbf@elegosoft.com> <5558AA20.1090208@lcwb.coop> <555A14B2.7090900@lcwb.coop> <555A196E.2020106@lcwb.coop> <20150518234714.dd1c111374ba3614cd74a63e@elegosoft.com> <20150519013349.0ba8729443cabb394424d3cd@elegosoft.com> <20150519235609.41e93f178398d113bdecb79d@elegosoft.com> <20150521015115.1c558406fe4358c833242628@elegosoft.com> <40F30E19-16FB-4993-9712-3B67B9A624B4@elstel.org> Message-ID: <20150521175016.a551cb784f3bed67aa833835@elegosoft.com> On Thu, 21 May 2015 12:07:53 +0200 Elmar Stellnberger wrote: > Dear Olaf, > > I have Mac OS 10.7.5 here and would like to give your new binaries a try. > Do the binaries include a version of Qt or will I have to install qt4/5 in addition to your binaries? > It should not be a problem for me if Qt is only available to C/C++ externals. I just gave that a try. QtEventLoopRaw.m3 cannot be found: === package m3-ui/qt/m3qtcore === +++ cm3 -build -override $RARGS -DROOT='/Users/wagner/work/cm3' +++ --- building in AMD64_DARWIN --- unable to read ../src/m3overrides, options "-override" and "-x" ignored. compiling ../src/dynamicqobject.cxx compiling ../src/QtNamespace_wrap.cxx compiling ../src/QtDynamic_wrap.cxx ../src/QtDynamic_wrap.cxx:164:3: warning: delete called on 'AbstractDynamicSlot' that is abstract but has non-virtual destructor [-Wdelete-non-virtual-dtor] delete arg1; ^ 1 warning generated. compiling ../src/QtCoreApplication_wrap.cxx compiling ../src/QtByteArray_wrap.cxx compiling ../src/QtString_wrap.cxx compiling ../src/QtList_wrap.cxx compiling ../src/QtStringList_wrap.cxx compiling ../src/QtEventLoop_wrap.cxx compiling ../src/QtEvent_wrap.cxx ../src/QtEvent_wrap.cxx:376:23: warning: 'QDynamicPropertyChangeEvent_propertyName' has C-linkage specified, but returns user-defined type 'QByteArray' which is incompatible with C [-Wreturn-type-c-linkage] SWIGEXPORT QByteArray QDynamicPropertyChangeEvent_propertyName(QDynamicPropertyChangeEvent const * self) { ^ 1 warning generated. compiling ../src/QtObject_wrap.cxx compiling ../src/QtPoint_wrap.cxx ../src/QtPoint_wrap.cxx:472:21: warning: 'QPointF_rx' has C-linkage specified, but returns user-defined type 'double &' which is incompatible with C [-Wreturn-type-c-linkage] SWIGEXPORT double & QPointF_rx(QPointF * self) { ^ ../src/QtPoint_wrap.cxx:484:21: warning: 'QPointF_ry' has C-linkage specified, but returns user-defined type 'double &' which is incompatible with C [-Wreturn-type-c-linkage] SWIGEXPORT double & QPointF_ry(QPointF * self) { ^ 2 warnings generated. compiling ../src/QtLine_wrap.cxx compiling ../src/QtSize_wrap.cxx ../src/QtSize_wrap.cxx:584:21: warning: 'QSizeF_rwidth' has C-linkage specified, but returns user-defined type 'double &' which is incompatible with C [-Wreturn-type-c-linkage] SWIGEXPORT double & QSizeF_rwidth(QSizeF * self) { ^ ../src/QtSize_wrap.cxx:596:21: warning: 'QSizeF_rheight' has C-linkage specified, but returns user-defined type 'double &' which is incompatible with C [-Wreturn-type-c-linkage] SWIGEXPORT double & QSizeF_rheight(QSizeF * self) { ^ 2 warnings generated. compiling ../src/QtRect_wrap.cxx compiling ../src/QtDateTime_wrap.cxx compiling ../src/QtMargins_wrap.cxx compiling ../src/QtAbstractItemModel_wrap.cxx ../src/QtAbstractItemModel_wrap.cxx:266:26: warning: 'QModelIndex_flags' has C-linkage specified, but returns user-defined type 'Qt::ItemFlags' (aka 'QFlags') which is incompatible with C [-Wreturn-type-c-linkage] SWIGEXPORT Qt::ItemFlags QModelIndex_flags(QModelIndex const * self) { ^ ../src/QtAbstractItemModel_wrap.cxx:416:26: warning: 'QPersistentModelIndex_flags' has C-linkage specified, but returns user-defined type 'Qt::ItemFlags' (aka 'QFlags') which is incompatible with C [-Wreturn-type-c-linkage] SWIGEXPORT Qt::ItemFlags QPersistentModelIndex_flags(QPersistentModelIndex const * self) { ^ ../src/QtAbstractItemModel_wrap.cxx:652:28: warning: 'QAbstractItemModel_supportedDropActions' has C-linkage specified, but returns user-defined type 'Qt::DropActions' (aka 'QFlags') which is incompatible with C [-Wreturn-type-c-linkage] SWIGEXPORT Qt::DropActions QAbstractItemModel_supportedDropActions(QAbstractItemModel * self) { ^ ../src/QtAbstractItemModel_wrap.cxx:662:28: warning: 'QAbstractItemModel_supportedDragActions' has C-linkage specified, but returns user-defined type 'Qt::DropActions' (aka 'QFlags') which is incompatible with C [-Wreturn-type-c-linkage] SWIGEXPORT Qt::DropActions QAbstractItemModel_supportedDragActions(QAbstractItemModel * self) { ^ ../src/QtAbstractItemModel_wrap.cxx:962:26: warning: 'QAbstractItemModel_flags' has C-linkage specified, but returns user-defined type 'Qt::ItemFlags' (aka 'QFlags') which is incompatible with C [-Wreturn-type-c-linkage] SWIGEXPORT Qt::ItemFlags QAbstractItemModel_flags(QAbstractItemModel * self, QModelIndex const & index) { ^ 5 warnings generated. unable to open file for reading: ../src/QtEventLoopRaw.m3: errno=2 open failed on: ../src/QtEventLoopRaw.m3 Fatal Error: failed compiling: *** execution of cm3 -build -override $RARGS -DROOT='/Users/wagner/work/cm3' failed *** elegos-MacBook-Pro:cm3 wagner$ find m3-ui -name '*EventLoop*' -print m3-ui/qt/m3qtcore/AMD64_DARWIN/QtEventLoop.io m3-ui/qt/m3qtcore/AMD64_DARWIN/QtEventLoop_wrap.o m3-ui/qt/m3qtcore/AMD64_DARWIN/QtEventLoopRaw.io m3-ui/qt/m3qtcore/src/QtEventLoop.i3 m3-ui/qt/m3qtcore/src/QtEventLoop.m3 m3-ui/qt/m3qtcore/src/QtEventLoop_wrap.cxx m3-ui/qt/m3qtcore/src/QtEventLoop_wrap.o m3-ui/qt/m3qtcore/src/QtEventLoopRaw.i3 m3-ui/qt/m3qtcore/src/swig/QtEventLoop.i The warnings seem to indicate that there may be more problems. I installed qt 4.8.6 via brew: elegos-MacBook-Pro:cm3 wagner$ brew install qt ==> Downloading https://downloads.sf.net/project/machomebrew/Bottles/qt-4.8.6.mavericks.bottle.6.tar.gz ######################################################################## 100.0% ==> Pouring qt-4.8.6.mavericks.bottle.6.tar.gz ==> Caveats We agreed to the Qt opensource license for you. If this is unacceptable you should uninstall. .app bundles were installed. Run `brew linkapps` to symlink these to /Applications. ==> Summary /usr/local/Cellar/qt/4.8.6: 2790 files, 122M Any advice what I did wrong? Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From rodney_bates at lcwb.coop Thu May 21 18:57:07 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 21 May 2015 11:57:07 -0500 Subject: [M3devel] LLVM version and patches thereto Message-ID: <555E0E63.6070506@lcwb.coop> Peter, what version of llvm are you using? Also, can you tell us what the patches you have made to it are? Have you sent these to the llvm developers to incorporate? I can guess one is to tolerate DW_LANG_Modula3. -- Rodney Bates rodney.m.bates at acm.org From hendrik at topoi.pooq.com Thu May 21 18:56:00 2015 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Thu, 21 May 2015 12:56:00 -0400 Subject: [M3devel] Bootstrapping cm3 on OS X 10.9.5 In-Reply-To: <40F30E19-16FB-4993-9712-3B67B9A624B4@elstel.org> References: <20150517011824.75f096c832d5da56e4810bbf@elegosoft.com> <5558AA20.1090208@lcwb.coop> <555A14B2.7090900@lcwb.coop> <555A196E.2020106@lcwb.coop> <20150518234714.dd1c111374ba3614cd74a63e@elegosoft.com> <20150519013349.0ba8729443cabb394424d3cd@elegosoft.com> <20150519235609.41e93f178398d113bdecb79d@elegosoft.com> <20150521015115.1c558406fe4358c833242628@elegosoft.com> <40F30E19-16FB-4993-9712-3B67B9A624B4@elstel.org> Message-ID: <20150521165600.GA13058@topoi.pooq.com> On Thu, May 21, 2015 at 12:07:53PM +0200, Elmar Stellnberger wrote: > Dear Olaf, > > I have Mac OS 10.7.5 here and would like to give your new binaries a try. > Do the binaries include a version of Qt or will I have to install qt4/5 in addition to your binaries? > It should not be a problem for me if Qt is only available to C/C++ externals. Live and learn! I didn't know there *was* a Qt binding for Modula 3. I could sure use it. What interfaces and modules provide it? -- hendrik From rodney_bates at lcwb.coop Thu May 21 19:24:12 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 21 May 2015 12:24:12 -0500 Subject: [M3devel] How to integrate llvm into cm3 Message-ID: <555E14BC.2040805@lcwb.coop> I previously made significant changes to cm3 and related, to drive an llvm backend and have them in a branch. I added 4 new backend modes. IntLlvmObj and IntLlvmAsm are "internal", meaning a complete llvm-derived back end is linked in with cm3, similar to the x86 internal backend, found in m3back. Obj/Asm is whether it produces object modules or assembly code. (I did not set out to use these, just put them in for completeness.) ExtLlvmObj and ExtLlvmAsm are for "external". In these, a separate executable llvm backend is used (llc) that reads llvm bitcode, generated by cm3. The code to produce the llvm-IR is in a package m3llvmgen. It links in some amount of llvm infrastructure to build llvm IR in-memory trees, then write them to llvm bitcode. Peter's cm3-IR to llvm-IR conversion is a separately compiled executable, which differs from both the above organizations. It relys on cm3's existing ability to write cm3-IR to a file in binary form. It reads this (either binary or text form, with a small code change) and produces llvm bitcode files. So, do we have any preference about how to do this. Code changes to either read cm3-IR from a binary file, a text file, or get it directly inside the cm3 executable are nearly trivial. Just substitute a different subtype of M3CG.T. to supply the cm3-IR operator stream. Cm3 changes would be a bit bigger to drive the separate executable pass. There are pros and cons. Integrating Peter's cm3-to-llvm conversion into the cm3 executable would be faster compiling--one fewer time per interface or module for the OS to create a process and run an executable. But it would also entail linking in this code, along with some of llvm's infrastructure, into cm3, making its executable bigger, with code that might not be executed at all, when a different backend is used. We already have the x86 integrated backend and the C backend linked in to cm3, whether used or not. Anybody have thoughts on this? I suppose it could be set up to be fairly easily changed either way too. -- Rodney Bates rodney.m.bates at acm.org From estellnb at elstel.org Thu May 21 20:13:18 2015 From: estellnb at elstel.org (Elmar Stellnberger) Date: Thu, 21 May 2015 20:13:18 +0200 Subject: [M3devel] How to integrate llvm into cm3 In-Reply-To: <555E14BC.2040805@lcwb.coop> References: <555E14BC.2040805@lcwb.coop> Message-ID: <555E203E.4040203@elstel.org> Am 21.05.15 um 19:24 schrieb Rodney M. Bates: > > There are pros and cons. Integrating Peter's cm3-to-llvm conversion into > the cm3 executable would be faster compiling--one fewer time per > interface > or module for the OS to create a process and run an executable. But it > would also entail linking in this code, along with some of llvm's > infrastructure, > into cm3, making its executable bigger, with code that might not be > executed > at all, when a different backend is used. We already have the x86 > integrated > backend and the C backend linked in to cm3, whether used or not. > > Anybody have thoughts on this? I suppose it could be set up to be fairly > easily changed either way too. > Why not put each backend into a shared library and load it dynamically? Are there still problems with shared libraries for some build targets? On the other hand having cm3-IR handy and being able to translate cm3-IR by an executable like m3cc into any desired target has proven to be very handy for debugging as well as chocking the Modula-3 compiler on a new platform. My personal preference would be to only have one default target statically compiled in namely that on for cm3-IR and load all other targets by a shared libarary dynamically. If that should fail for some reason one can still use m3cc or one of its counterparts to accomplish the translation process. Elmar From peter.mckinna at gmail.com Fri May 22 00:09:28 2015 From: peter.mckinna at gmail.com (Peter McKinna) Date: Fri, 22 May 2015 08:09:28 +1000 Subject: [M3devel] LLVM version and patches thereto In-Reply-To: <555E0E63.6070506@lcwb.coop> References: <555E0E63.6070506@lcwb.coop> Message-ID: Hi Rodney, Good to see this stuff moving forward. I had no idea how to integrate it with the front end. I'm using llvm 3.5 . I downloaded 3.6 and built it but then could not get some dibuilder bindings I had added to compile, some sort of problem with the wrap function which I have yet to sort out. I think they made a change to the way metadata is treated. Anyway I have attached the 2 sets of bindings I have been using. I have to commit a few bug fixes and my initial attempt at debug support. Speaking of debugging, I was following what I think clang uses which is the dibuilder class . So far its very primitive and could probably be split into its own module. I managed to get simple scalars, enumerations, arrays and records to be debugged with stock gdb and none of the name mangling I usually get. But globals, objects and sets dont work. I think this needs an expert and mybe a chat with the llvm people, they seem pretty helpful. Anyway it runs the maze program, I compiled the collector the other day, 15,000 lines of llvm ir. The code quality looks pretty good from a brief inspection of the assembly thats compiled at O3 although O2 doesnt make much difference. I read in tips for programmers somewhere that pascal like languages with lots of runtime checks should be running some extra passes for better optimisation. We could look at that in the future. Regards Peter On Fri, May 22, 2015 at 2:57 AM, Rodney M. Bates wrote: > Peter, what version of llvm are you using? Also, can you tell us what the > patches > you have made to it are? Have you sent these to the llvm developers to > incorporate? > I can guess one is to tolerate DW_LANG_Modula3. > > > -- > Rodney Bates > rodney.m.bates at acm.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: M3Extras.h Type: text/x-chdr Size: 838 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DIBuilderBindings.h Type: text/x-chdr Size: 6034 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: M3Extras.cpp Type: text/x-c++src Size: 2354 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DIBuilderBindings.cpp Type: text/x-c++src Size: 11648 bytes Desc: not available URL: From jay.krell at cornell.edu Fri May 22 02:57:07 2015 From: jay.krell at cornell.edu (Jay K) Date: Fri, 22 May 2015 00:57:07 +0000 Subject: [M3devel] How to integrate llvm into cm3 In-Reply-To: <555E203E.4040203@elstel.org> References: <555E14BC.2040805@lcwb.coop>,<555E203E.4040203@elstel.org> Message-ID: Imho "all" options should be implemented, for purposes of convenient debugging/development of the backends. "external" is good for developing backends. You can "snapshot" the state of things slightly into the pipeline and then just iterate on later parts. At the cost of having all the serialization code. "integrated" is usually preferable for performance, for users. E.g. NTx86 backend has been sitting in there for decades unused by half the users. Having extra backends sitting in there unused is ok. Ideally, agreed, they'd be .dll/.sos if we can construct it that way, but ok either way imho. Ideally also cm3 would dynamically link to libm3/m3core, but it doesn't. Everything is demand paged so there is cost to distribute over the network and copy around, but at runtime, the pages just sit mostly cold on disk. One difficulty though is the need to have and build the LLVM code. For that reason, delayload-dynamically-linked might be preferable. It depends on how small/easy-to-build LLVM is. I guess LLVM provides more choices than before. In order of efficiency and inverse order of debuggability: 1 We could construct LLVM IR in memory and run LLVM in-proc and write .o. 2 We could write out LLVM bytes and run an executable. 3 We could write out LLVM text and run an executable. > My personal preference would be to only have one default target statically compiled in It has never worked that away. Granted, we didn't really have backends before, just writing mainly IR. And I don't think LLVM works that way, does it? I like one compiler to have all targets and just select with a command line switch. I don't like how hard it is to acquire various cross-toolschains. Granted, we cheat and are incomplete -- you still need the next piece of the pipeline, be it LLVM or m3cc (which has one target), or a C compiler or assembler or linker or "libc.a". binutils at least has this "all" notion reasonably well working now I believe. There are tradeoffs though. If only one backend has a bug, and they are all statically linked together, you have to update them all.And the largely wasted bloat. Ultimately really, I'd like the C backend to output portable C and then just one C backend, one distribution .tar.gz for all targets.There is work to do there..not easy..and no progress lately.Things like INTEGER preserving flexibility in the output, and using sizeof(INTEGER) in expressions instead of using 4 or 8 and folding... - Jay > Date: Thu, 21 May 2015 20:13:18 +0200 > From: estellnb at elstel.org > To: rodney.m.bates at acm.org; m3devel at elegosoft.com > Subject: Re: [M3devel] How to integrate llvm into cm3 > > Am 21.05.15 um 19:24 schrieb Rodney M. Bates: > > > > There are pros and cons. Integrating Peter's cm3-to-llvm conversion into > > the cm3 executable would be faster compiling--one fewer time per > > interface > > or module for the OS to create a process and run an executable. But it > > would also entail linking in this code, along with some of llvm's > > infrastructure, > > into cm3, making its executable bigger, with code that might not be > > executed > > at all, when a different backend is used. We already have the x86 > > integrated > > backend and the C backend linked in to cm3, whether used or not. > > > > Anybody have thoughts on this? I suppose it could be set up to be fairly > > easily changed either way too. > > > > Why not put each backend into a shared library and load it dynamically? > Are there still problems with shared libraries for some build targets? > On the other hand having cm3-IR handy and being able to translate > cm3-IR by an executable like m3cc into any desired target has proven > to be very handy for debugging as well as chocking the Modula-3 > compiler on a new platform. > My personal preference would be to only have one default target > statically compiled in namely that on for cm3-IR and load all other > targets by a shared libarary dynamically. If that should fail for some > reason one can still use m3cc or one of its counterparts to > accomplish the translation process. > > Elmar > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.mckinna at gmail.com Fri May 22 05:01:25 2015 From: peter.mckinna at gmail.com (Peter McKinna) Date: Fri, 22 May 2015 13:01:25 +1000 Subject: [M3devel] How to integrate llvm into cm3 In-Reply-To: References: <555E14BC.2040805@lcwb.coop> <555E203E.4040203@elstel.org> Message-ID: I followed the m3cc design mainly because I didnt want to include the llvm libs in the link for cm3. It is a c++ lib set and requires the c++ linker which if you have ever built llvm or clang leaves you wondering about that linker. I was watching it link an llvm lib once and it took over 19 seconds. In fact watching the llvm build is like watching grass grow, it takes over 2 hours on my humble laptop (core i3). They estimate about 40 minutes on a "fast" machine. I digress. If llvm or other library is statically linked into cm3 and its not part of the standard toolchain then we would have to ship the those libs woudnt we? We dont have the package mechanism like debian and others which will drag in dependant libraries. At the moment we ship the sources and say build this with what youve got installed. Peter On Fri, May 22, 2015 at 10:57 AM, Jay K wrote: > Imho "all" options should be implemented, for purposes of convenient > debugging/development of the backends. > > > "external" is good for developing backends. You can "snapshot" the state > of things > slightly into the pipeline and then just iterate on later parts. > > > At the cost of having all the serialization code. > > > "integrated" is usually preferable for performance, for users. > > > E.g. NTx86 backend has been sitting in there for decades unused by half > the users. > > > Having extra backends sitting in there unused is ok. > Ideally, agreed, they'd be .dll/.sos if we can construct it that way, but > ok either way imho. > Ideally also cm3 would dynamically link to libm3/m3core, but it doesn't. > > > Everything is demand paged so there is cost to distribute over the network > and copy around, but at runtime, the pages just sit mostly cold on disk. > > > One difficulty though is the need to have and build the LLVM code. > For that reason, delayload-dynamically-linked might be preferable. > It depends on how small/easy-to-build LLVM is. > > > I guess LLVM provides more choices than before. > In order of efficiency and inverse order of debuggability: > 1 We could construct LLVM IR in memory and run LLVM in-proc and write > .o. > 2 We could write out LLVM bytes and run an executable. > 3 We could write out LLVM text and run an executable. > > > > My personal preference would be to only have one default target > statically compiled in > > It has never worked that away. Granted, we didn't really have backends > before, just writing mainly IR. > And I don't think LLVM works that way, does it? > > I like one compiler to have all targets and just select with a command > line switch. > > I don't like how hard it is to acquire various cross-toolschains. > Granted, we cheat and are incomplete -- you still need the next piece of > the pipeline, > be it LLVM or m3cc (which has one target), or a C compiler or assembler > or linker or "libc.a". > > > binutils at least has this "all" notion reasonably well working now I > believe. > > > > There are tradeoffs though. If only one backend has a bug, and they are > all statically linked together, you have to update them all. > And the largely wasted bloat. > > > Ultimately really, I'd like the C backend to output portable C and then > just one C backend, one distribution .tar.gz for all targets. > There is work to do there..not easy..and no progress lately. > Things like INTEGER preserving flexibility in the output, and using > sizeof(INTEGER) in expressions instead of using 4 or 8 and folding... > > > > - Jay > > > > > > Date: Thu, 21 May 2015 20:13:18 +0200 > > From: estellnb at elstel.org > > To: rodney.m.bates at acm.org; m3devel at elegosoft.com > > Subject: Re: [M3devel] How to integrate llvm into cm3 > > > > > Am 21.05.15 um 19:24 schrieb Rodney M. Bates: > > > > > > There are pros and cons. Integrating Peter's cm3-to-llvm conversion > into > > > the cm3 executable would be faster compiling--one fewer time per > > > interface > > > or module for the OS to create a process and run an executable. But it > > > would also entail linking in this code, along with some of llvm's > > > infrastructure, > > > into cm3, making its executable bigger, with code that might not be > > > executed > > > at all, when a different backend is used. We already have the x86 > > > integrated > > > backend and the C backend linked in to cm3, whether used or not. > > > > > > Anybody have thoughts on this? I suppose it could be set up to be > fairly > > > easily changed either way too. > > > > > > > Why not put each backend into a shared library and load it dynamically? > > Are there still problems with shared libraries for some build targets? > > On the other hand having cm3-IR handy and being able to translate > > cm3-IR by an executable like m3cc into any desired target has proven > > to be very handy for debugging as well as chocking the Modula-3 > > compiler on a new platform. > > My personal preference would be to only have one default target > > statically compiled in namely that on for cm3-IR and load all other > > targets by a shared libarary dynamically. If that should fail for some > > reason one can still use m3cc or one of its counterparts to > > accomplish the translation process. > > > > Elmar > > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmuysers at hotmail.com Fri May 22 10:48:36 2015 From: dmuysers at hotmail.com (dirk muysers) Date: Fri, 22 May 2015 10:48:36 +0200 Subject: [M3devel] How to integrate llvm into cm3 In-Reply-To: References: <555E14BC.2040805@lcwb.coop>, <555E203E.4040203@elstel.org> Message-ID: Personally I have a strong dislike towards LLVM. 1. You first have to compile the whole tool chain. 2. It is a monstrous blob of code, mainly on Windows. 3. Contrary to a widespread belief, It is definitely NOT platform independent. 4. It changes at every release. 5. Having built your objects, you still have to run them through a platform assembler-linker. If I still had the energy of my younger years I would try to pack the platform dependent part of the libraries into a dynamic load library together with a JIT translator (e.g. libjit) for the portable application code and have a single byte-code producing compiler backend. From: Jay K Sent: Friday, May 22, 2015 2:57 AM To: Elmar Stellnberger ; rodney.m.bates at acm.org ; m3devel Subject: Re: [M3devel] How to integrate llvm into cm3 Imho "all" options should be implemented, for purposes of convenient debugging/development of the backends. "external" is good for developing backends. You can "snapshot" the state of things slightly into the pipeline and then just iterate on later parts. At the cost of having all the serialization code. "integrated" is usually preferable for performance, for users. E.g. NTx86 backend has been sitting in there for decades unused by half the users. Having extra backends sitting in there unused is ok. Ideally, agreed, they'd be .dll/.sos if we can construct it that way, but ok either way imho. Ideally also cm3 would dynamically link to libm3/m3core, but it doesn't. Everything is demand paged so there is cost to distribute over the network and copy around, but at runtime, the pages just sit mostly cold on disk. One difficulty though is the need to have and build the LLVM code. For that reason, delayload-dynamically-linked might be preferable. It depends on how small/easy-to-build LLVM is. I guess LLVM provides more choices than before. In order of efficiency and inverse order of debuggability: 1 We could construct LLVM IR in memory and run LLVM in-proc and write .o. 2 We could write out LLVM bytes and run an executable. 3 We could write out LLVM text and run an executable. > My personal preference would be to only have one default target statically compiled in It has never worked that away. Granted, we didn't really have backends before, just writing mainly IR. And I don't think LLVM works that way, does it? I like one compiler to have all targets and just select with a command line switch. I don't like how hard it is to acquire various cross-toolschains. Granted, we cheat and are incomplete -- you still need the next piece of the pipeline, be it LLVM or m3cc (which has one target), or a C compiler or assembler or linker or "libc.a". binutils at least has this "all" notion reasonably well working now I believe. There are tradeoffs though. If only one backend has a bug, and they are all statically linked together, you have to update them all. And the largely wasted bloat. Ultimately really, I'd like the C backend to output portable C and then just one C backend, one distribution .tar.gz for all targets. There is work to do there..not easy..and no progress lately. Things like INTEGER preserving flexibility in the output, and using sizeof(INTEGER) in expressions instead of using 4 or 8 and folding... - Jay > Date: Thu, 21 May 2015 20:13:18 +0200 > From: estellnb at elstel.org > To: rodney.m.bates at acm.org; m3devel at elegosoft.com > Subject: Re: [M3devel] How to integrate llvm into cm3 > > Am 21.05.15 um 19:24 schrieb Rodney M. Bates: > > > > There are pros and cons. Integrating Peter's cm3-to-llvm conversion into > > the cm3 executable would be faster compiling--one fewer time per > > interface > > or module for the OS to create a process and run an executable. But it > > would also entail linking in this code, along with some of llvm's > > infrastructure, > > into cm3, making its executable bigger, with code that might not be > > executed > > at all, when a different backend is used. We already have the x86 > > integrated > > backend and the C backend linked in to cm3, whether used or not. > > > > Anybody have thoughts on this? I suppose it could be set up to be fairly > > easily changed either way too. > > > > Why not put each backend into a shared library and load it dynamically? > Are there still problems with shared libraries for some build targets? > On the other hand having cm3-IR handy and being able to translate > cm3-IR by an executable like m3cc into any desired target has proven > to be very handy for debugging as well as chocking the Modula-3 > compiler on a new platform. > My personal preference would be to only have one default target > statically compiled in namely that on for cm3-IR and load all other > targets by a shared libarary dynamically. If that should fail for some > reason one can still use m3cc or one of its counterparts to > accomplish the translation process. > > Elmar > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From estellnb at elstel.org Fri May 22 11:50:38 2015 From: estellnb at elstel.org (Elmar Stellnberger) Date: Fri, 22 May 2015 11:50:38 +0200 Subject: [M3devel] How to integrate llvm into cm3 In-Reply-To: References: <555E14BC.2040805@lcwb.coop>, <555E203E.4040203@elstel.org> Message-ID: <780C53B1-C9EA-479C-86EA-82D4670879DC@elstel.org> Am 22.05.2015 um 10:48 schrieb dirk muysers: > Personally I have a strong dislike towards LLVM. > 1. You first have to compile the whole tool chain. > 2. It is a monstrous blob of code, mainly on Windows. > 3. Contrary to a widespread belief, It is definitely NOT platform independent. > 4. It changes at every release. > 5. Having built your objects, you still have to run them through a platform assembler-linker. Is it really that bad? What about the said platform dependencies you have discovered? I believe llvm could be beneficial in deed when it comes to debugging and/or analyzing Modula-3 programs, as there are tools like SAFECode and to my knowledge we never had a fully featured m3gdb. Besides this I would hardly like to believe that llvm is still that volatile when it comes to changes. I know it had some issues in its first days but I can hardly believe that qt5 on MacOS would rely on clang/llvm if that were not a ready to use technology nowadays. I would hope the main changes to llvm had already been done when Apple started to adopt llvm for its own needs. Concerning the code size of llvm that should not be a problem as long as it remains a separate module compiling into an own executable or a shared library loaded in addition to other backends at runtime. > > If I still had the energy of my younger years I would try to pack the platform > dependent part of the libraries into a dynamic load library together with a JIT > translator (e.g. libjit) for the portable application code and have a single byte-code > producing compiler backend. > > From: Jay K > Sent: Friday, May 22, 2015 2:57 AM > To: Elmar Stellnberger ; rodney.m.bates at acm.org ; m3devel > Subject: Re: [M3devel] How to integrate llvm into cm3 > > Imho "all" options should be implemented, for purposes of convenient debugging/development of the backends. > > > "external" is good for developing backends. You can "snapshot" the state of things > slightly into the pipeline and then just iterate on later parts. > > > At the cost of having all the serialization code. > > > "integrated" is usually preferable for performance, for users. > > > E.g. NTx86 backend has been sitting in there for decades unused by half the users. > > > Having extra backends sitting in there unused is ok. > Ideally, agreed, they'd be .dll/.sos if we can construct it that way, but ok either way imho. > Ideally also cm3 would dynamically link to libm3/m3core, but it doesn't. > > > Everything is demand paged so there is cost to distribute over the network > and copy around, but at runtime, the pages just sit mostly cold on disk. > > > One difficulty though is the need to have and build the LLVM code. > For that reason, delayload-dynamically-linked might be preferable. > It depends on how small/easy-to-build LLVM is. > > > I guess LLVM provides more choices than before. > In order of efficiency and inverse order of debuggability: > 1 We could construct LLVM IR in memory and run LLVM in-proc and write .o. > 2 We could write out LLVM bytes and run an executable. > 3 We could write out LLVM text and run an executable. > > > > My personal preference would be to only have one default target statically compiled in > > It has never worked that away. Granted, we didn't really have backends before, just writing mainly IR. > And I don't think LLVM works that way, does it? > > I like one compiler to have all targets and just select with a command line switch. > > I don't like how hard it is to acquire various cross-toolschains. > Granted, we cheat and are incomplete -- you still need the next piece of the pipeline, > be it LLVM or m3cc (which has one target), or a C compiler or assembler or linker or "libc.a". > > > binutils at least has this "all" notion reasonably well working now I believe. > > > > There are tradeoffs though. If only one backend has a bug, and they are all statically linked together, you have to update them all. > And the largely wasted bloat. > > > Ultimately really, I'd like the C backend to output portable C and then just one C backend, one distribution .tar.gz for all targets. > There is work to do there..not easy..and no progress lately. > Things like INTEGER preserving flexibility in the output, and using sizeof(INTEGER) in expressions instead of using 4 or 8 and folding... > > > > - Jay > > > > > > Date: Thu, 21 May 2015 20:13:18 +0200 > > From: estellnb at elstel.org > > To: rodney.m.bates at acm.org; m3devel at elegosoft.com > > Subject: Re: [M3devel] How to integrate llvm into cm3 > > > > Am 21.05.15 um 19:24 schrieb Rodney M. Bates: > > > > > > There are pros and cons. Integrating Peter's cm3-to-llvm conversion into > > > the cm3 executable would be faster compiling--one fewer time per > > > interface > > > or module for the OS to create a process and run an executable. But it > > > would also entail linking in this code, along with some of llvm's > > > infrastructure, > > > into cm3, making its executable bigger, with code that might not be > > > executed > > > at all, when a different backend is used. We already have the x86 > > > integrated > > > backend and the C backend linked in to cm3, whether used or not. > > > > > > Anybody have thoughts on this? I suppose it could be set up to be fairly > > > easily changed either way too. > > > > > > > Why not put each backend into a shared library and load it dynamically? > > Are there still problems with shared libraries for some build targets? > > On the other hand having cm3-IR handy and being able to translate > > cm3-IR by an executable like m3cc into any desired target has proven > > to be very handy for debugging as well as chocking the Modula-3 > > compiler on a new platform. > > My personal preference would be to only have one default target > > statically compiled in namely that on for cm3-IR and load all other > > targets by a shared libarary dynamically. If that should fail for some > > reason one can still use m3cc or one of its counterparts to > > accomplish the translation process. > > > > Elmar > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmuysers at hotmail.com Fri May 22 12:16:21 2015 From: dmuysers at hotmail.com (dirk muysers) Date: Fri, 22 May 2015 12:16:21 +0200 Subject: [M3devel] How to integrate llvm into cm3 In-Reply-To: <0A1CDD8C-EEB5-40E2-A38B-28E8EEA8C37E@elstel.org> References: <555E14BC.2040805@lcwb.coop>, <555E203E.4040203@elstel.org> <0A1CDD8C-EEB5-40E2-A38B-28E8EEA8C37E@elstel.org> Message-ID: >> What about the said platform dependencies you have discovered? Not me (I never seriously considered using it), but many people on the llvm forums pointed to the fact. One example among many: Does your C code ever use the 'long' type? If so, the LLVM IR will be different depending on whether it's targeting linux-32 or linux-64. Do you ever use size_t? Same problem. Do you ever use a union containing both pointers and integers? See above. In principle, it's possible to write platform-independent IR, or even C code that compiles to platform-independent IR. In practice, especially if you include any system headers, it's remarkably hard. (Jeffrey Yasskin jyasskin at google.com) And then, besides the IR proper, there is that steadily increasing legion of intrinsics. Unless you translate C-like code and build upon the existing technical LLVM heritage, je vous souhaite bien du plaisir as the French say... From: Elmar Stellnberger Sent: Friday, May 22, 2015 11:49 AM To: dirk muysers Subject: Re: [M3devel] How to integrate llvm into cm3 Am 22.05.2015 um 10:48 schrieb dirk muysers: Personally I have a strong dislike towards LLVM. 1. You first have to compile the whole tool chain. 2. It is a monstrous blob of code, mainly on Windows. 3. Contrary to a widespread belief, It is definitely NOT platform independent. 4. It changes at every release. 5. Having built your objects, you still have to run them through a platform assembler-linker. Is it really that bad? What about the said platform dependencies you have discovered? I believe llvm could be beneficial in deed when it comes to debugging and/or analyzing Modula-3 programs, as there are tools like SAFECode and to my knowledge we never had a fully featured m3gdb. Besides this I would hardly like to believe that llvm is still that volatile when it comes to changes. I know it had some issues in its first days but I can hardly believe that qt5 on MacOS would rely on clang/llvm if that were not a ready to use technology nowadays. I would hope the main changes to llvm had already been done when Apple started to adopt llvm for its own needs. Concerning the code size of llvm that should not be a problem as long as it remains a separate module compiling into an own executable or a shared library loaded in addition to other backends at runtime. If I still had the energy of my younger years I would try to pack the platform dependent part of the libraries into a dynamic load library together with a JIT translator (e.g. libjit) for the portable application code and have a single byte-code producing compiler backend. From: Jay K Sent: Friday, May 22, 2015 2:57 AM To: Elmar Stellnberger ; rodney.m.bates at acm.org ; m3devel Subject: Re: [M3devel] How to integrate llvm into cm3 Imho "all" options should be implemented, for purposes of convenient debugging/development of the backends. "external" is good for developing backends. You can "snapshot" the state of things slightly into the pipeline and then just iterate on later parts. At the cost of having all the serialization code. "integrated" is usually preferable for performance, for users. E.g. NTx86 backend has been sitting in there for decades unused by half the users. Having extra backends sitting in there unused is ok. Ideally, agreed, they'd be .dll/.sos if we can construct it that way, but ok either way imho. Ideally also cm3 would dynamically link to libm3/m3core, but it doesn't. Everything is demand paged so there is cost to distribute over the network and copy around, but at runtime, the pages just sit mostly cold on disk. One difficulty though is the need to have and build the LLVM code. For that reason, delayload-dynamically-linked might be preferable. It depends on how small/easy-to-build LLVM is. I guess LLVM provides more choices than before. In order of efficiency and inverse order of debuggability: 1 We could construct LLVM IR in memory and run LLVM in-proc and write .o. 2 We could write out LLVM bytes and run an executable. 3 We could write out LLVM text and run an executable. > My personal preference would be to only have one default target statically compiled in It has never worked that away. Granted, we didn't really have backends before, just writing mainly IR. And I don't think LLVM works that way, does it? I like one compiler to have all targets and just select with a command line switch. I don't like how hard it is to acquire various cross-toolschains. Granted, we cheat and are incomplete -- you still need the next piece of the pipeline, be it LLVM or m3cc (which has one target), or a C compiler or assembler or linker or "libc.a". binutils at least has this "all" notion reasonably well working now I believe. There are tradeoffs though. If only one backend has a bug, and they are all statically linked together, you have to update them all. And the largely wasted bloat. Ultimately really, I'd like the C backend to output portable C and then just one C backend, one distribution .tar.gz for all targets. There is work to do there..not easy..and no progress lately. Things like INTEGER preserving flexibility in the output, and using sizeof(INTEGER) in expressions instead of using 4 or 8 and folding... - Jay > Date: Thu, 21 May 2015 20:13:18 +0200 > From: estellnb at elstel.org > To: rodney.m.bates at acm.org; m3devel at elegosoft.com > Subject: Re: [M3devel] How to integrate llvm into cm3 > > Am 21.05.15 um 19:24 schrieb Rodney M. Bates: > > > > There are pros and cons. Integrating Peter's cm3-to-llvm conversion into > > the cm3 executable would be faster compiling--one fewer time per > > interface > > or module for the OS to create a process and run an executable. But it > > would also entail linking in this code, along with some of llvm's > > infrastructure, > > into cm3, making its executable bigger, with code that might not be > > executed > > at all, when a different backend is used. We already have the x86 > > integrated > > backend and the C backend linked in to cm3, whether used or not. > > > > Anybody have thoughts on this? I suppose it could be set up to be fairly > > easily changed either way too. > > > > Why not put each backend into a shared library and load it dynamically? > Are there still problems with shared libraries for some build targets? > On the other hand having cm3-IR handy and being able to translate > cm3-IR by an executable like m3cc into any desired target has proven > to be very handy for debugging as well as chocking the Modula-3 > compiler on a new platform. > My personal preference would be to only have one default target > statically compiled in namely that on for cm3-IR and load all other > targets by a shared libarary dynamically. If that should fail for some > reason one can still use m3cc or one of its counterparts to > accomplish the translation process. > > Elmar > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From estellnb at elstel.org Fri May 22 12:53:14 2015 From: estellnb at elstel.org (Elmar Stellnberger) Date: Fri, 22 May 2015 12:53:14 +0200 Subject: [M3devel] How to integrate llvm into cm3 In-Reply-To: References: <555E14BC.2040805@lcwb.coop>, <555E203E.4040203@elstel.org> <0A1CDD8C-EEB5-40E2-A38B-28E8EEA8C37E@elstel.org> Message-ID: <8A3AB2ED-C11E-4787-A7F8-C8F12157EAA5@elstel.org> Am 22.05.2015 um 12:16 schrieb dirk muysers: > >> What about the said platform dependencies you have discovered? > > Not me (I never seriously considered using it), but many people on the llvm > forums pointed to the fact. One example among > many: > > Does your C code ever use the 'long' type? If so, the LLVM IR will be > different depending on whether it's targeting linux-32 or linux-64. Do > you ever use size_t? Same problem. Do you ever use a union containing > both pointers and integers? See above. In principle, it's possible to > write platform-independent IR, or even C code that compiles to > platform-independent IR. In practice, especially if you include any > system headers, it's remarkably hard. > (Jeffrey Yasskin jyasskin at google.com) Concerning me I am a very conscientious programmer when it comes to make a difference between long, long long and int. I only use long if my code requires a data item to be exactly as large as a pointer (in special cases also when it comes to tap the power of 64bit machines, f.i. that might be either 32/64bit as a base type for arbitrary length integers; however not without taking special provisions that will tackle the difference in data size. ). Usually aligning the pointers for the next structure at the beginning would also solve such an issue when it comes to reuse existing code where data sizes may not be changed from long either to int or long long without special consideration. Those who use glib f.i. additionally have a g[u]int32/64 which they can use instead of int / long long though that should at last never make a difference for Intel x86 based systems. So when it comes to use int or long long I mostly rely on them being either 32 or 64bit. I know that most programmers do not care and just always use long which I consider to be a particularly bad practice. Even in the Linux kernel they have declared "typedef long time_t" instead of "typedef long long time_t" which will create an Y2K mess all over in 2038 for all 32bit machines still in use then. A somehow bad decision which needs to be changed sooner or later even without llvm. Now let us think of Modula-3. I believe we had a long type for cm3 the last time I have seen it. However an equivalent to long long which does also exist on 32bit platforms would be an absolute requirement to not break things for llvm! Many Thanks for notifying us about this issue, Dirk. As far as I can see a Modula-3 programmer will need a good core for portable programming anyway as we did not even uphold a guarantee for WIDECHAR to be either 16 or 32bit. > > And then, besides the IR proper, there is that steadily increasing > legion of intrinsics. > > Unless you translate C-like code and build upon the existing technical > LLVM heritage, je vous souhaite bien du plaisir as the French say... > > From: Elmar Stellnberger > Sent: Friday, May 22, 2015 11:49 AM > To: dirk muysers > Subject: Re: [M3devel] How to integrate llvm into cm3 > > > Am 22.05.2015 um 10:48 schrieb dirk muysers: > >> Personally I have a strong dislike towards LLVM. >> 1. You first have to compile the whole tool chain. >> 2. It is a monstrous blob of code, mainly on Windows. >> 3. Contrary to a widespread belief, It is definitely NOT platform independent. >> 4. It changes at every release. >> 5. Having built your objects, you still have to run them through a platform assembler-linker. >> > > Is it really that bad? What about the said platform dependencies you have discovered? > I believe llvm could be beneficial in deed when it comes to debugging and/or analyzing Modula-3 programs, > as there are tools like SAFECode and to my knowledge we never had a fully featured m3gdb. > Besides this I would hardly like to believe that llvm is still that volatile when it comes to changes. > I know it had some issues in its first days but I can hardly believe that qt5 on MacOS would rely on clang/llvm > if that were not a ready to use technology nowadays. I would hope the main changes to llvm had already > been done when Apple started to adopt llvm for its own needs. > Concerning the code size of llvm that should not be a problem as long as it remains a separate module > compiling into an own executable or a shared library loaded in addition to other backends at runtime. > > >> If I still had the energy of my younger years I would try to pack the platform >> dependent part of the libraries into a dynamic load library together with a JIT >> translator (e.g. libjit) for the portable application code and have a single byte-code >> producing compiler backend. >> >> From: Jay K >> Sent: Friday, May 22, 2015 2:57 AM >> To: Elmar Stellnberger ; rodney.m.bates at acm.org ; m3devel >> Subject: Re: [M3devel] How to integrate llvm into cm3 >> >> Imho "all" options should be implemented, for purposes of convenient debugging/development of the backends. >> >> >> "external" is good for developing backends. You can "snapshot" the state of things >> slightly into the pipeline and then just iterate on later parts. >> >> >> At the cost of having all the serialization code. >> >> >> "integrated" is usually preferable for performance, for users. >> >> >> E.g. NTx86 backend has been sitting in there for decades unused by half the users. >> >> >> Having extra backends sitting in there unused is ok. >> Ideally, agreed, they'd be .dll/.sos if we can construct it that way, but ok either way imho. >> Ideally also cm3 would dynamically link to libm3/m3core, but it doesn't. >> >> >> Everything is demand paged so there is cost to distribute over the network >> and copy around, but at runtime, the pages just sit mostly cold on disk. >> >> >> One difficulty though is the need to have and build the LLVM code. >> For that reason, delayload-dynamically-linked might be preferable. >> It depends on how small/easy-to-build LLVM is. >> >> >> I guess LLVM provides more choices than before. >> In order of efficiency and inverse order of debuggability: >> 1 We could construct LLVM IR in memory and run LLVM in-proc and write .o. >> 2 We could write out LLVM bytes and run an executable. >> 3 We could write out LLVM text and run an executable. >> >> >> > My personal preference would be to only have one default target statically compiled in >> >> It has never worked that away. Granted, we didn't really have backends before, just writing mainly IR. >> And I don't think LLVM works that way, does it? >> >> I like one compiler to have all targets and just select with a command line switch. >> >> I don't like how hard it is to acquire various cross-toolschains. >> Granted, we cheat and are incomplete -- you still need the next piece of the pipeline, >> be it LLVM or m3cc (which has one target), or a C compiler or assembler or linker or "libc.a". >> >> >> binutils at least has this "all" notion reasonably well working now I believe. >> >> >> >> There are tradeoffs though. If only one backend has a bug, and they are all statically linked together, you have to update them all. >> And the largely wasted bloat. >> >> >> Ultimately really, I'd like the C backend to output portable C and then just one C backend, one distribution .tar.gz for all targets. >> There is work to do there..not easy..and no progress lately. >> Things like INTEGER preserving flexibility in the output, and using sizeof(INTEGER) in expressions instead of using 4 or 8 and folding... >> >> >> >> - Jay >> >> >> >> >> > Date: Thu, 21 May 2015 20:13:18 +0200 >> > From: estellnb at elstel.org >> > To: rodney.m.bates at acm.org; m3devel at elegosoft.com >> > Subject: Re: [M3devel] How to integrate llvm into cm3 >> > >> > Am 21.05.15 um 19:24 schrieb Rodney M. Bates: >> > > >> > > There are pros and cons. Integrating Peter's cm3-to-llvm conversion into >> > > the cm3 executable would be faster compiling--one fewer time per >> > > interface >> > > or module for the OS to create a process and run an executable. But it >> > > would also entail linking in this code, along with some of llvm's >> > > infrastructure, >> > > into cm3, making its executable bigger, with code that might not be >> > > executed >> > > at all, when a different backend is used. We already have the x86 >> > > integrated >> > > backend and the C backend linked in to cm3, whether used or not. >> > > >> > > Anybody have thoughts on this? I suppose it could be set up to be fairly >> > > easily changed either way too. >> > > >> > >> > Why not put each backend into a shared library and load it dynamically? >> > Are there still problems with shared libraries for some build targets? >> > On the other hand having cm3-IR handy and being able to translate >> > cm3-IR by an executable like m3cc into any desired target has proven >> > to be very handy for debugging as well as chocking the Modula-3 >> > compiler on a new platform. >> > My personal preference would be to only have one default target >> > statically compiled in namely that on for cm3-IR and load all other >> > targets by a shared libarary dynamically. If that should fail for some >> > reason one can still use m3cc or one of its counterparts to >> > accomplish the translation process. >> > >> > Elmar >> > >> > >> > >> > >> > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From estellnb at elstel.org Fri May 22 12:58:56 2015 From: estellnb at elstel.org (Elmar Stellnberger) Date: Fri, 22 May 2015 12:58:56 +0200 Subject: [M3devel] How to integrate llvm into cm3 In-Reply-To: References: <555E14BC.2040805@lcwb.coop>, <555E203E.4040203@elstel.org> <0A1CDD8C-EEB5-40E2-A38B-28E8EEA8C37E@elstel.org> Message-ID: <7E7A129A-7EAB-4424-98BD-D2D1900CF0AB@elstel.org> > (Jeffrey Yasskin jyasskin at google.com) > > And then, besides the IR proper, there is that steadily increasing > legion of intrinsics. Dirk, what can you tell us about intrinsics? Do they have a sufficient abstraction level for LLVM or do they really expose hidden language dependencies? -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Fri May 22 13:06:00 2015 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri, 22 May 2015 13:06:00 +0200 (CEST) Subject: [M3devel] How to integrate llvm into cm3 In-Reply-To: References: <555E14BC.2040805@lcwb.coop>, <555E203E.4040203@elstel.org> <0A1CDD8C-EEB5-40E2-A38B-28E8EEA8C37E@elstel.org> Message-ID: On Fri, 22 May 2015, dirk muysers wrote: > >> What about the said platform dependencies you have discovered? > Not me (I never seriously considered using it), but many people on the > llvm forums pointed to the fact. One example among many: Why should the LLVM IR be platform independent? Like object files, the ll bitcode files are platform dependent. Of course, there must be a way to address processor specific instructions. Intrinsics are used for that purpose. If you want processor specific optimizations, then LL cannot be platform independent. From estellnb at elstel.org Fri May 22 14:26:28 2015 From: estellnb at elstel.org (Elmar Stellnberger) Date: Fri, 22 May 2015 14:26:28 +0200 Subject: [M3devel] How to integrate llvm into cm3 In-Reply-To: References: <555E14BC.2040805@lcwb.coop>, <555E203E.4040203@elstel.org> <0A1CDD8C-EEB5-40E2-A38B-28E8EEA8C37E@elstel.org> Message-ID: <94C9A717-B0EA-4257-A728-C926FC8A4FEB@elstel.org> Am 22.05.2015 um 13:06 schrieb Henning Thielemann: > > > On Fri, 22 May 2015, dirk muysers wrote: > >> >> What about the said platform dependencies you have discovered? > >> Not me (I never seriously considered using it), but many people on the llvm forums pointed to the fact. One example among many: > > Why should the LLVM IR be platform independent? Like object files, the ll bitcode files are platform dependent. Of course, there must be a way to address processor specific instructions. Intrinsics are used for that purpose. If you want processor specific optimizations, then LL cannot be platform independent. > You are right; not an issue of llvm though someone who is used to Java or C#/.net bytecode would not expect such a 'feature'. Am 22.05.2015 um 12:53 schrieb Elmar Stellnberger: > Now let us think of Modula-3. I believe we had a long type for cm3 the last > time I have seen it. However an equivalent to long long which does also > exist on 32bit platforms would be an absolute requirement to not break > things for llvm! Many Thanks for notifying us about this issue, Dirk. > > As far as I can see a Modula-3 programmer will need a good core for > portable programming anyway as we did not even uphold a guarantee for > WIDECHAR to be either 16 or 32bit. > > Nonetheless we actually need to demand the necessary precautions from Modula-3 for platform independent programming. Having a type (1) which is at least 64bit long (why not also 128bit) for numeric purposes (at best also available on 32bit platforms) (2) a type which is exactly as long as a pointer (f.i. for subtracting two pointers) (3) the regular INTEGER defined to be at most 32bit in order to avoid an overkill in memory consumption and computing power Anyone here who can tell me about the current state of LONGINT support for cm3? As far as I can remember we had a LONGINT but only on 64bit machines. For portable programming we will at least need types for (2) and (3). (1) would be an additional plus. So writing code which will execute seamlessly either in a 32bit or 64bit environment as I have frequently tested it and done in the last eight years should at least become possible with Modula-3. It needs to be doable when using gcc as well as llvm though the 'advantages' are more obvious when it comes to arch-all llvm bytecode. From rodney_bates at lcwb.coop Fri May 22 18:15:06 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Fri, 22 May 2015 11:15:06 -0500 Subject: [M3devel] How to integrate llvm into cm3 In-Reply-To: References: <555E14BC.2040805@lcwb.coop>, <555E203E.4040203@elstel.org> Message-ID: <555F560A.4010506@lcwb.coop> On 05/21/2015 07:57 PM, Jay K wrote: > Imho "all" options should be implemented, for purposes of convenient debugging/development of the backends. > Yes, I like that idea. We should be able to do it without a huge coding burden. > > "external" is good for developing backends. You can "snapshot" the state of things > slightly into the pipeline and then just iterate on later parts. > Yes. > > At the cost of having all the serialization code. > Yes, although it is already there now, for cm3-IR. It exists in llvm for llvm-IR, but has to be linked in. > > "integrated" is usually preferable for performance, for users. > Yes > > E.g. NTx86 backend has been sitting in there for decades unused by half the users. > > > Having extra backends sitting in there unused is ok. > Ideally, agreed, they'd be .dll/.sos if we can construct it that way, but ok either way imho. Thank you. > Ideally also cm3 would dynamically link to libm3/m3core, but it doesn't. > > > Everything is demand paged so there is cost to distribute over the network > and copy around, but at runtime, the pages just sit mostly cold on disk. > Hadn't thought of that. It pretty well addresses my concerns about how much to link in. We can just be extravagant and let the paging take care of it. > > One difficulty though is the need to have and build the LLVM code. > For that reason, delayload-dynamically-linked might be preferable. > It depends on how small/easy-to-build LLVM is. > All of llvm is huge and takes a long time to build. Both Peter and I are currently following the approach of linking in only a subset of llvm, containing code to build its internal trees and serialize them. I haven't checked actual sizes of compiled code, but in library count, it's perhaps 1/4 or so. Of course, you still need the rest for the separate executable that optimizes/codegens. > > I guess LLVM provides more choices than before. > In order of efficiency and inverse order of debuggability: > 1 We could construct LLVM IR in memory and run LLVM in-proc and write .o. > 2 We could write out LLVM bytes and run an executable. > 3 We could write out LLVM text and run an executable. > > One consideration is that there is a *lot* of command-line processing, etc. in driving llvm opt/codegen. llc, a separate executable which comes as part of llvm already provides this. Doing 1 above would require duplicating this, or maybe ripping out the C++ code and somehow repackaging it. We would still have to pass all these options through cm3. The way I have Builder working now, what of this stuff that is handled, comes from Quake code, etc. bypasses cm3 and gets passed in to llc. > > My personal preference would be to only have one default target statically compiled in > > It has never worked that away. Granted, we didn't really have backends before, just writing mainly IR. > And I don't think LLVM works that way, does it? > > I like one compiler to have all targets and just select with a command line switch. > > I don't like how hard it is to acquire various cross-toolschains. > Granted, we cheat and are incomplete -- you still need the next piece of the pipeline, > be it LLVM or m3cc (which has one target), or a C compiler or assembler or linker or "libc.a". > > > binutils at least has this "all" notion reasonably well working now I believe. > > > > There are tradeoffs though. If only one backend has a bug, and they are all statically linked together, you have to update them all. > And the largely wasted bloat. > > > Ultimately really, I'd like the C backend to output portable C and then just one C backend, one distribution .tar.gz for all targets. > There is work to do there..not easy..and no progress lately. > Things like INTEGER preserving flexibility in the output, and using sizeof(INTEGER) in expressions instead of using 4 or 8 and folding... > > > > - Jay > > > > > > Date: Thu, 21 May 2015 20:13:18 +0200 > > From: estellnb at elstel.org > > To: rodney.m.bates at acm.org; m3devel at elegosoft.com > > Subject: Re: [M3devel] How to integrate llvm into cm3 > > > > Am 21.05.15 um 19:24 schrieb Rodney M. Bates: > > > > > > There are pros and cons. Integrating Peter's cm3-to-llvm conversion into > > > the cm3 executable would be faster compiling--one fewer time per > > > interface > > > or module for the OS to create a process and run an executable. But it > > > would also entail linking in this code, along with some of llvm's > > > infrastructure, > > > into cm3, making its executable bigger, with code that might not be > > > executed > > > at all, when a different backend is used. We already have the x86 > > > integrated > > > backend and the C backend linked in to cm3, whether used or not. > > > > > > Anybody have thoughts on this? I suppose it could be set up to be fairly > > > easily changed either way too. > > > > > > > Why not put each backend into a shared library and load it dynamically? > > Are there still problems with shared libraries for some build targets? > > On the other hand having cm3-IR handy and being able to translate > > cm3-IR by an executable like m3cc into any desired target has proven > > to be very handy for debugging as well as chocking the Modula-3 > > compiler on a new platform. > > My personal preference would be to only have one default target > > statically compiled in namely that on for cm3-IR and load all other > > targets by a shared libarary dynamically. If that should fail for some > > reason one can still use m3cc or one of its counterparts to > > accomplish the translation process. > > > > Elmar > > > > > > > > > > > > -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Fri May 22 18:59:15 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Fri, 22 May 2015 11:59:15 -0500 Subject: [M3devel] LLVM version and patches thereto In-Reply-To: References: <555E0E63.6070506@lcwb.coop> Message-ID: <555F6063.2000204@lcwb.coop> On 05/21/2015 05:09 PM, Peter McKinna wrote: > Hi Rodney, > > Good to see this stuff moving forward. I had no idea how to integrate it with the front end. I'm using llvm 3.5 . I downloaded 3.6 and built it but then could not get some dibuilder bindings I had added to compile, some sort of problem with the wrap function which I have yet to sort out. I think they made a change to the way metadata is treated. Anyway I have attached the 2 sets of bindings I have been using. I have to commit a few bug fixes and my initial attempt at debug support. I have been using llvm 3.4.2, which was the current release when I first started thinking about this. I want to avoid overlapping heavy development, while simultaneously constantly reworking what's already done to new versions. However, I am well past due to update to as late a version as reasonable. They have made a couple of changes that I know will be relevant. (I've been monitoring their mailing list--very high traffic.) One is the metadata class is no longer a subclass of Value, with various implications to the IR. Another is that there is only one pointer type. It no longer gives its referent type. We (Peter and I) have duplicated on DIBuilder bindings. Yours is tidier looking, but mine is pretty much complete. I will undertake merging them and adapting to latest llvm. I had some real nightmares getting wrap and unwrap unravelled, and will probably have to do some of that again. IMO, this is, by far, the most extreme specific example I have ever seen for why user-defined overloading is disastrous idea. There are a bazillion overloads of wrap and unwrap, whose declarations are scattered all over the universe. Figuring out which one you got, or, in case none was found, where the one you wanted is horrible. It's further complicated by the fact that there are various user-defined implicit conversions that the compiler can insert with no syntactic clue in the call you are trying to decrypt. These are just as spread out, maybe more. And have you ever tried to construct a transitive #include closure in something as big as llvm? > Speaking of debugging, I was following what I think clang uses which is the dibuilder class . So far its very primitive and could probably be split into its own module. I managed to get simple scalars, enumerations, arrays and records to be debugged with stock gdb and none of the name mangling I usually get. But globals, objects and sets dont work. I think this needs an expert and mybe a chat with the llvm people, they seem pretty helpful. > Anyway it runs the maze program, I compiled the collector the other day, 15,000 lines of llvm ir. The code quality looks pretty good from a brief inspection of the assembly thats compiled at O3 although O2 doesnt make much difference. I read in tips for programmers somewhere that pascal like languages with lots of runtime checks should be running some extra passes for better optimisation. We could look at that in the future. > > Regards Peter > > On Fri, May 22, 2015 at 2:57 AM, Rodney M. Bates > wrote: > > Peter, what version of llvm are you using? Also, can you tell us what the patches > you have made to it are? Have you sent these to the llvm developers to incorporate? > I can guess one is to tolerate DW_LANG_Modula3. > > > -- > Rodney Bates > rodney.m.bates at acm.org > > -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Fri May 22 19:20:17 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Fri, 22 May 2015 12:20:17 -0500 Subject: [M3devel] How to integrate llvm into cm3 In-Reply-To: References: <555E14BC.2040805@lcwb.coop>, <555E203E.4040203@elstel.org> Message-ID: <555F6551.3000300@lcwb.coop> On 05/22/2015 03:48 AM, dirk muysers wrote: > Personally I have a strong dislike towards LLVM. > 1. You first have to compile the whole tool chain. > 2. It is a monstrous blob of code, mainly on Windows. > 3. Contrary to a widespread belief, It is definitely NOT platform independent. > 4. It changes at every release. > 5. Having built your objects, you still have to run them through a platform assembler-linker. Having grubbed around in it a bit, I can't say I'm exactly ecstatic about llvm. However, its developers have at least adopted the intention of providing clear documentation. While the documentation has trapped/misled me in some areas, this is dramatically better than gcc, where, as I understand, there is intentional avoidance of documenting internal formats and data structures, as a way to make it difficult to work on for any but programmers who are both very skilled and have a lot of time to spend on it. Further, it appears gcc changes about as fast as llvm. > If I still had the energy of my younger years I would try to pack the platform > dependent part of the libraries into a dynamic load library together with a JIT > translator (e.g. libjit) for the portable application code and have a single byte-code > producing compiler backend. I don't think things like this are at all unrealistic, if we get a basic llvm backend developed. > *From:* Jay K > *Sent:* Friday, May 22, 2015 2:57 AM > *To:* Elmar Stellnberger ; rodney.m.bates at acm.org ; m3devel > *Subject:* Re: [M3devel] How to integrate llvm into cm3 > Imho "all" options should be implemented, for purposes of convenient debugging/development of the backends. > > "external" is good for developing backends. You can "snapshot" the state of things > slightly into the pipeline and then just iterate on later parts. > > At the cost of having all the serialization code. > > "integrated" is usually preferable for performance, for users. > > E.g. NTx86 backend has been sitting in there for decades unused by half the users. > > Having extra backends sitting in there unused is ok. > Ideally, agreed, they'd be .dll/.sos if we can construct it that way, but ok either way imho. > Ideally also cm3 would dynamically link to libm3/m3core, but it doesn't. > > Everything is demand paged so there is cost to distribute over the network > and copy around, but at runtime, the pages just sit mostly cold on disk. > > One difficulty though is the need to have and build the LLVM code. > For that reason, delayload-dynamically-linked might be preferable. > It depends on how small/easy-to-build LLVM is. > > I guess LLVM provides more choices than before. > In order of efficiency and inverse order of debuggability: > 1 We could construct LLVM IR in memory and run LLVM in-proc and write .o. > 2 We could write out LLVM bytes and run an executable. > 3 We could write out LLVM text and run an executable. > > > My personal preference would be to only have one default target statically compiled in > It has never worked that away. Granted, we didn't really have backends before, just writing mainly IR. > And I don't think LLVM works that way, does it? > I like one compiler to have all targets and just select with a command line switch. > I don't like how hard it is to acquire various cross-toolschains. > Granted, we cheat and are incomplete -- you still need the next piece of the pipeline, > be it LLVM or m3cc (which has one target), or a C compiler or assembler or linker or "libc.a". > > binutils at least has this "all" notion reasonably well working now I believe. > There are tradeoffs though. If only one backend has a bug, and they are all statically linked together, you have to update them all. > And the largely wasted bloat. > Ultimately really, I'd like the C backend to output portable C and then just one C backend, one distribution .tar.gz for all targets. > There is work to do there..not easy..and no progress lately. > Things like INTEGER preserving flexibility in the output, and using sizeof(INTEGER) in expressions instead of using 4 or 8 and folding... > > - Jay > > > > > > Date: Thu, 21 May 2015 20:13:18 +0200 > > From: estellnb at elstel.org > > To: rodney.m.bates at acm.org; m3devel at elegosoft.com > > Subject: Re: [M3devel] How to integrate llvm into cm3 > > > > Am 21.05.15 um 19:24 schrieb Rodney M. Bates: > > > > > > There are pros and cons. Integrating Peter's cm3-to-llvm conversion into > > > the cm3 executable would be faster compiling--one fewer time per > > > interface > > > or module for the OS to create a process and run an executable. But it > > > would also entail linking in this code, along with some of llvm's > > > infrastructure, > > > into cm3, making its executable bigger, with code that might not be > > > executed > > > at all, when a different backend is used. We already have the x86 > > > integrated > > > backend and the C backend linked in to cm3, whether used or not. > > > > > > Anybody have thoughts on this? I suppose it could be set up to be fairly > > > easily changed either way too. > > > > > > > Why not put each backend into a shared library and load it dynamically? > > Are there still problems with shared libraries for some build targets? > > On the other hand having cm3-IR handy and being able to translate > > cm3-IR by an executable like m3cc into any desired target has proven > > to be very handy for debugging as well as chocking the Modula-3 > > compiler on a new platform. > > My personal preference would be to only have one default target > > statically compiled in namely that on for cm3-IR and load all other > > targets by a shared libarary dynamically. If that should fail for some > > reason one can still use m3cc or one of its counterparts to > > accomplish the translation process. > > > > Elmar > > > > > > > > > > > > -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Fri May 22 19:55:27 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Fri, 22 May 2015 12:55:27 -0500 Subject: [M3devel] How to integrate llvm into cm3 In-Reply-To: <8A3AB2ED-C11E-4787-A7F8-C8F12157EAA5@elstel.org> References: <555E14BC.2040805@lcwb.coop>, <555E203E.4040203@elstel.org> <0A1CDD8C-EEB5-40E2-A38B-28E8EEA8C37E@elstel.org> <8A3AB2ED-C11E-4787-A7F8-C8F12157EAA5@elstel.org> Message-ID: <555F6D8F.4070109@lcwb.coop> This is a worthwhile discussion, but it has very little to do with using llvm as a back end. In the llvm-IR, sizes of integers, pointers, etc. are constant numbers. The frontend, whether Clang, CM3, or any other, makes the decisions about mapping language types like long, INTEGER, pointers, etc. to a size, target-dependently or otherwise, according to the language's rules. LLvm does not make these decisions. Its target dependencies are mostly in the line of different code generators for different instruction sets. On 05/22/2015 05:53 AM, Elmar Stellnberger wrote: > > Am 22.05.2015 um 12:16 schrieb dirk muysers: > >> >> What about the said platform dependencies you have discovered? >> Not me (I never seriously considered using it), but many people on the llvm >> forums pointed to the fact. One example among >> many: >> >> Does your C code ever use the 'long' type? If so, the LLVM IR will be >> different depending on whether it's targeting linux-32 or linux-64. Do >> you ever use size_t? Same problem. Do you ever use a union containing >> both pointers and integers? See above. In principle, it's possible to >> write platform-independent IR, or even C code that compiles to >> platform-independent IR. In practice, especially if you include any >> system headers, it's remarkably hard. >> (Jeffrey Yasskin jyasskin at google.com) > > Concerning me I am a very conscientious programmer when it comes to > make a difference between long, long long and int. I only use long if my > code requires a data item to be exactly as large as a pointer (in special > cases also when it comes to tap the power of 64bit machines, f.i. that > might be either 32/64bit as a base type for arbitrary length integers; > however not without taking special provisions that will tackle the > difference in data size. ). Usually aligning the pointers for the next > structure at the beginning would also solve such an issue when it comes > to reuse existing code where data sizes may not be changed from long > either to int or long long without special consideration. Those who use > glib f.i. additionally have a g[u]int32/64 which they can use instead of int > / long long though that should at last never make a difference for Intel x86 > based systems. So when it comes to use int or long long I mostly rely > on them being either 32 or 64bit. > I know that most programmers do not care and just always use long which > I consider to be a particularly bad practice. Even in the Linux kernel they > have declared "typedef long time_t" instead of "typedef long long time_t" > which will create an Y2K mess all over in 2038 for all 32bit machines still > in use then. A somehow bad decision which needs to be changed sooner > or later even without llvm. > > Now let us think of Modula-3. I believe we had a long type for cm3 the last > time I have seen it. However an equivalent to long long which does also > exist on 32bit platforms would be an absolute requirement to not break > things for llvm! Many Thanks for notifying us about this issue, Dirk. > Whether types like integer have a language-specified or target-dependent range is a tough language design question. I have tended to favor a fixed, language-specified range, but there are pros and cons. I do think all the time about end-of-range cases and native word size dependencies. It takes a great deal of care, and I know of no way to design a language that doesn't, to some extent, trade one set of problems for another. Signed/unsigned creates similar language dilemmas. > As far as I can see a Modula-3 programmer will need a good core for > portable programming anyway as we did not even uphold a guarantee for > WIDECHAR to be either 16 or 32bit. > The evolving nature of first UCS and then Unicode standards has left many language designers knocked off balance. Critical Mass first introduced WIDECHAR as 16-bit when that was what everybody thought was enough. Then things changed, and it wasn't anymore. Right now, it's a configuration parameter (must be the same for the entire link closure) in Modula-3. I personally favor making it full Unicode by default, in the next release, as this is where the world is now. This is hopefully a simpler problem than INTEGER, etc., because, as of now, the Unicode committee has emphatically assured us that the range will *never* increase. We can hope. > > > > >> And then, besides the IR proper, there is that steadily increasing >> legion of intrinsics. >> Unless you translate C-like code and build upon the existing technical >> LLVM heritage, /je vous souhaite bien du plaisir/ as the French say... >> ** >> *From:* Elmar Stellnberger >> *Sent:* Friday, May 22, 2015 11:49 AM >> *To:* dirk muysers >> *Subject:* Re: [M3devel] How to integrate llvm into cm3 >> Am 22.05.2015 um 10:48 schrieb dirk muysers: >> >>> Personally I have a strong dislike towards LLVM. >>> 1. You first have to compile the whole tool chain. >>> 2. It is a monstrous blob of code, mainly on Windows. >>> 3. Contrary to a widespread belief, It is definitely NOT platform independent. >>> 4. It changes at every release. >>> 5. Having built your objects, you still have to run them through a platform assembler-linker. >> Is it really that bad? What about the said platform dependencies you have discovered? >> I believe llvm could be beneficial in deed when it comes to debugging and/or analyzing Modula-3 programs, >> as there are tools like SAFECode and to my knowledge we never had a fully featured m3gdb. >> Besides this I would hardly like to believe that llvm is still that volatile when it comes to changes. >> I know it had some issues in its first days but I can hardly believe that qt5 on MacOS would rely on clang/llvm >> if that were not a ready to use technology nowadays. I would hope the main changes to llvm had already >> been done when Apple started to adopt llvm for its own needs. >> Concerning the code size of llvm that should not be a problem as long as it remains a separate module >> compiling into an own executable or a shared library loaded in addition to other backends at runtime. >> >>> If I still had the energy of my younger years I would try to pack the platform >>> dependent part of the libraries into a dynamic load library together with a JIT >>> translator (e.g. libjit) for the portable application code and have a single byte-code >>> producing compiler backend. >>> *From:*Jay K >>> *Sent:*Friday, May 22, 2015 2:57 AM >>> *To:*Elmar Stellnberger ;rodney.m.bates at acm.org ;m3devel >>> *Subject:*Re: [M3devel] How to integrate llvm into cm3 >>> Imho "all" options should be implemented, for purposes of convenient debugging/development of the backends. >>> >>> "external" is good for developing backends. You can "snapshot" the state of things >>> slightly into the pipeline and then just iterate on later parts. >>> >>> At the cost of having all the serialization code. >>> >>> "integrated" is usually preferable for performance, for users. >>> >>> E.g. NTx86 backend has been sitting in there for decades unused by half the users. >>> >>> Having extra backends sitting in there unused is ok. >>> Ideally, agreed, they'd be .dll/.sos if we can construct it that way, but ok either way imho. >>> Ideally also cm3 would dynamically link to libm3/m3core, but it doesn't. >>> >>> Everything is demand paged so there is cost to distribute over the network >>> and copy around, but at runtime, the pages just sit mostly cold on disk. >>> >>> One difficulty though is the need to have and build the LLVM code. >>> For that reason, delayload-dynamically-linked might be preferable. >>> It depends on how small/easy-to-build LLVM is. >>> >>> I guess LLVM provides more choices than before. >>> In order of efficiency and inverse order of debuggability: >>> 1 We could construct LLVM IR in memory and run LLVM in-proc and write .o. >>> 2 We could write out LLVM bytes and run an executable. >>> 3 We could write out LLVM text and run an executable. >>> >>> > My personal preference would be to only have one default targetstatically compiled in >>> It has never worked that away. Granted, we didn't really have backends before, just writing mainly IR. >>> And I don't think LLVM works that way, does it? >>> I like one compiler to have all targets and just select with a command line switch. >>> I don't like how hard it is to acquire various cross-toolschains. >>> Granted, we cheat and are incomplete -- you still need the next piece of the pipeline, >>> be it LLVM or m3cc (which has one target), or a C compiler or assembler or linker or "libc.a". >>> >>> binutils at least has this "all" notion reasonably well working now I believe. >>> There are tradeoffs though. If only one backend has a bug, and they are all statically linked together, you have to update them all. >>> And the largely wasted bloat. >>> Ultimately really, I'd like the C backend to output portable C and then just one C backend, one distribution .tar.gz for all targets. >>> There is work to do there..not easy..and no progress lately. >>> Things like INTEGER preserving flexibility in the output, and using sizeof(INTEGER) in expressions instead of using 4 or 8 and folding... >>> >>> - Jay >>> >>> >>> >>> >>> > Date: Thu, 21 May 2015 20:13:18 +0200 >>> > From:estellnb at elstel.org >>> > To:rodney.m.bates at acm.org ; m3devel at elegosoft.com >>> > Subject:Re: [M3devel] How to integrate llvm into cm3 >>> > >>> > Am 21.05.15 um 19:24 schriebRodney M. Bates: >>> > > >>> > > There are pros and cons.Integrating Peter's cm3-to-llvm conversion into >>> > > the cm3executable would be faster compiling--one fewer time per >>> > > interface >>> > >or module for the OS to create a process and run an executable. But it >>> >> would also entail linking in this code, along with some of llvm's >>> > > infrastructure, >>> >> into cm3, making its executable bigger, with code that might not be >>> > > executed >>> > >at all, when a different backend is used. We already have the x86 >>> > > integrated >>> > >backend and the C backend linked in to cm3, whether used or not. >>> >> >>> > > Anybody have thoughts on this? I suppose it could be set upto be fairly >>> > > easily changed either way too. >>> >> >>> > >>> > Why notput each backend into a shared library and load it dynamically? >>> > Arethere still problems with shared libraries for some build targets? >>> > Onthe other hand having cm3-IR handy and being able to translate >>> > cm3-IRby an executable like m3cc into any desired target has proven >>> > to bevery handy for debugging as well as chocking the Modula-3 >>> > compiler ona new platform. >>> > My personal preference would be to only have onedefault target >>> > statically compiled in namely that on for cm3-IR andload all other >>> > targets by a shared libarary dynamically. If thatshould fail for some >>> > reason one can still use m3cc or one of itscounterparts to >>> > accomplish the translation process. >>> > >>> > Elmar >>> > >>> > >>> > >>> > >>> > >>> > > -- Rodney Bates rodney.m.bates at acm.org From jay.krell at cornell.edu Sat May 23 03:58:43 2015 From: jay.krell at cornell.edu (Jay) Date: Fri, 22 May 2015 18:58:43 -0700 Subject: [M3devel] How to integrate llvm into cm3 In-Reply-To: <94C9A717-B0EA-4257-A728-C926FC8A4FEB@elstel.org> References: <555E14BC.2040805@lcwb.coop> <555E203E.4040203@elstel.org> <0A1CDD8C-EEB5-40E2-A38B-28E8EEA8C37E@elstel.org> <94C9A717-B0EA-4257-A728-C926FC8A4FEB@elstel.org> Message-ID: <105678F8-0E9B-4CE8-84ED-93F88F73E5AD@gmail.com> We use things with varying levels of abstraction. & concrete details are filled in at varying stages. C "long" is NOT specified as having an exact size and does NOT necessarily hold a pointer, and this is ok. C99 is pretty complete, messy. For each of 8, 16, 32, 64, It gives "least", "fast", and "exact" types. And pointer sized. Signed and unsigned. 32 types! INTEGER is always pointer sized. LONGINT is on all platforms. C# has this feature too. IntPtr & UIntPtr. But C# is dubious -- array indexes are always 32 bit signed. - Jay On May 22, 2015, at 5:26 AM, Elmar Stellnberger wrote: > > Am 22.05.2015 um 13:06 schrieb Henning Thielemann: > >> >> >> On Fri, 22 May 2015, dirk muysers wrote: >> >>>>> What about the said platform dependencies you have discovered? >> >>> Not me (I never seriously considered using it), but many people on the llvm forums pointed to the fact. One example among many: >> >> Why should the LLVM IR be platform independent? Like object files, the ll bitcode files are platform dependent. Of course, there must be a way to address processor specific instructions. Intrinsics are used for that purpose. If you want processor specific optimizations, then LL cannot be platform independent. > > > You are right; not an issue of llvm though someone who is used to Java or C#/.net bytecode would not expect such a 'feature'. > > > Am 22.05.2015 um 12:53 schrieb Elmar Stellnberger: > >> Now let us think of Modula-3. I believe we had a long type for cm3 the last >> time I have seen it. However an equivalent to long long which does also >> exist on 32bit platforms would be an absolute requirement to not break >> things for llvm! Many Thanks for notifying us about this issue, Dirk. >> >> As far as I can see a Modula-3 programmer will need a good core for >> portable programming anyway as we did not even uphold a guarantee for >> WIDECHAR to be either 16 or 32bit. > > Nonetheless we actually need to demand the necessary precautions from Modula-3 for platform independent programming. > Having a type > > (1) which is at least 64bit long (why not also 128bit) for numeric purposes (at best also available on 32bit platforms) > (2) a type which is exactly as long as a pointer (f.i. for subtracting two pointers) > (3) the regular INTEGER defined to be at most 32bit in order to avoid an overkill in memory consumption and computing power > > Anyone here who can tell me about the current state of LONGINT support for cm3? > As far as I can remember we had a LONGINT but only on 64bit machines. > For portable programming we will at least need types for (2) and (3). > (1) would be an additional plus. > > So writing code which will execute seamlessly either in a 32bit or 64bit environment as I have frequently tested it and done in > the last eight years should at least become possible with Modula-3. It needs to be doable when using gcc as well as llvm though > the 'advantages' are more obvious when it comes to arch-all llvm bytecode. > From hendrik at topoi.pooq.com Sat May 23 11:41:51 2015 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Sat, 23 May 2015 05:41:51 -0400 Subject: [M3devel] How to integrate llvm into cm3 In-Reply-To: <555F560A.4010506@lcwb.coop> References: <555E14BC.2040805@lcwb.coop> <555E203E.4040203@elstel.org> <555F560A.4010506@lcwb.coop> Message-ID: <20150523094151.GA16324@topoi.pooq.com> On Fri, May 22, 2015 at 11:15:06AM -0500, Rodney M. Bates wrote: > > >Ideally also cm3 would dynamically link to libm3/m3core, but it doesn't. > > > > > >Everything is demand paged so there is cost to distribute over the network > >and copy around, but at runtime, the pages just sit mostly cold on disk. > > > > Hadn't thought of that. It pretty well addresses my concerns about how much > to link in. We can just be extravagant and let the paging take care of it. Doesn't the executable have to be copied from the binary file to paged memory in order to run it? As far as I know, it's possible to replace the file being executed once execution has begun and it will just continue running. If this is true, the size of the llvm library might indicate it's best to load it dynaically from a shared library if and when needed. -- hendrik > > > > >One difficulty though is the need to have and build the LLVM code. > >For that reason, delayload-dynamically-linked might be preferable. > >It depends on how small/easy-to-build LLVM is. in Linux, one can presumably rely on the distribution to provide the llvm library. -- hendrik From estellnb at elstel.org Wed May 27 17:20:35 2015 From: estellnb at elstel.org (Elmar Stellnberger) Date: Wed, 27 May 2015 17:20:35 +0200 Subject: [M3devel] 64bit INTEGERs, WIDECHAR: language specified or configuration/target dependent? In-Reply-To: <555F6D8F.4070109@lcwb.coop> References: <555E14BC.2040805@lcwb.coop>, <555E203E.4040203@elstel.org> <0A1CDD8C-EEB5-40E2-A38B-28E8EEA8C37E@elstel.org> <8A3AB2ED-C11E-4787-A7F8-C8F12157EAA5@elstel.org> <555F6D8F.4070109@lcwb.coop> Message-ID: <6F9B9534-7DC2-4D4D-88CB-90D7FA05E8F9@elstel.org> > We use things with varying levels of abstraction. & concrete details are filled in at varying stages. C "long" is NOT specified as having an exact size and does NOT necessarily hold a pointer, and this is ok. > C99 is pretty complete, messy. > For each of 8, 16, 32, 64, > It gives "least", "fast", and "exact" types. And pointer sized. Signed and unsigned. 32 types! * long in C is not guaranteed to hold a pointer by the language definition Though not in the language definition (I believe the language definition of C is simply too old for anticipating all the developments from 8/16bit up to 64bit machines) this has evolved as a de facto standard at least on all x86 up to x86_64 targets as far as I know. Jay, do you know a single arch / target where sizeof(long) != sizeof(void*)? > > Whether types like integer have a language-specified or target-dependent > range is a tough language design question. I have tended to favor a > fixed, language-specified range, but there are pros and cons. I do > think all the time about end-of-range cases and native word size dependencies. > It takes a great deal of care, and I know of no way to design a language > that doesn't, to some extent, trade one set of problems for another. > Signed/unsigned creates similar language dilemmas. * language-specified or target-dependent As I have already suggested I believe there is some justification to have both kinds of type: a language dependent type and a target dependent one The advantages of a language dependent type are rather clear when it comes to mere INTEGERs for numeric/counting/calculation purposes. Once you have a fixed size you can rely on support of a certain value range. Use of the native word size on the other hand should yield better performance at least in the general case. If that question were "either - or" I would clearly favor language specified types. Rewriting certain parts of a program to gain more performance on a special arch is not as bad as a broken program. However if we look into the details at least of 8, 16, 32 and 64bit arches things need to be seen more differentiated: When extending the address range from 8 to 16 and from 16 to 32bit automatically extending the value ranges of integers was a known concern. 65536 (16bit) is not that a high value and we would even have liked to extend most array indices to 32bit as we gained something with the value range while using whole words was also somewhat faster. However things turned out to be very different when the extension from 32bit to 64bit was at stake. There was no more gain by automatically extending the value ranges from 2^32 to 2^64 for 95% of all application purposes while the memory hierarchy has increasingly become a bottle neck in recent time. Additionally doubling the size of all integers would initially have doubled our memory needs which would have been a potential drawback for introducing the AMD64 arch. Just think of a machine with 4GB of RAM: It can not be addressed by 32bit (only ~3GB can) while making all INTS 64bit would have shrunken our memory to an effective size of 2GB. Luckily the decision was taken differently this time: * keep all ints of at most 32bit and just extend pointers to 64bit Elmar P.S.: My next email will start a discussion for all these issues. Am 22.05.2015 um 19:55 schrieb Rodney M. Bates: > This is a worthwhile discussion, but it has very little to do with using > llvm as a back end. In the llvm-IR, sizes of integers, pointers, etc. > are constant numbers. The frontend, whether Clang, CM3, or any other, makes > the decisions about mapping language types like long, INTEGER, pointers, > etc. to a size, target-dependently or otherwise, according to the language's > rules. LLvm does not make these decisions. Its target dependencies are > mostly in the line of different code generators for different instruction sets. > > On 05/22/2015 05:53 AM, Elmar Stellnberger wrote: >> >> Am 22.05.2015 um 12:16 schrieb dirk muysers: >> >>> >> What about the said platform dependencies you have discovered? >>> Not me (I never seriously considered using it), but many people on the llvm >>> forums pointed to the fact. One example among >>> many: >>> >>> Does your C code ever use the 'long' type? If so, the LLVM IR will be >>> different depending on whether it's targeting linux-32 or linux-64. Do >>> you ever use size_t? Same problem. Do you ever use a union containing >>> both pointers and integers? See above. In principle, it's possible to >>> write platform-independent IR, or even C code that compiles to >>> platform-independent IR. In practice, especially if you include any >>> system headers, it's remarkably hard. >>> (Jeffrey Yasskin jyasskin at google.com) >> >> Concerning me I am a very conscientious programmer when it comes to >> make a difference between long, long long and int. I only use long if my >> code requires a data item to be exactly as large as a pointer (in special >> cases also when it comes to tap the power of 64bit machines, f.i. that >> might be either 32/64bit as a base type for arbitrary length integers; >> however not without taking special provisions that will tackle the >> difference in data size. ). Usually aligning the pointers for the next >> structure at the beginning would also solve such an issue when it comes >> to reuse existing code where data sizes may not be changed from long >> either to int or long long without special consideration. Those who use >> glib f.i. additionally have a g[u]int32/64 which they can use instead of int >> / long long though that should at last never make a difference for Intel x86 >> based systems. So when it comes to use int or long long I mostly rely >> on them being either 32 or 64bit. >> I know that most programmers do not care and just always use long which >> I consider to be a particularly bad practice. Even in the Linux kernel they >> have declared "typedef long time_t" instead of "typedef long long time_t" >> which will create an Y2K mess all over in 2038 for all 32bit machines still >> in use then. A somehow bad decision which needs to be changed sooner >> or later even without llvm. >> >> Now let us think of Modula-3. I believe we had a long type for cm3 the last >> time I have seen it. However an equivalent to long long which does also >> exist on 32bit platforms would be an absolute requirement to not break >> things for llvm! Many Thanks for notifying us about this issue, Dirk. >> > > Whether types like integer have a language-specified or target-dependent > range is a tough language design question. I have tended to favor a > fixed, language-specified range, but there are pros and cons. I do > think all the time about end-of-range cases and native word size dependencies. > It takes a great deal of care, and I know of no way to design a language > that doesn't, to some extent, trade one set of problems for another. > Signed/unsigned creates similar language dilemmas. > >> As far as I can see a Modula-3 programmer will need a good core for >> portable programming anyway as we did not even uphold a guarantee for >> WIDECHAR to be either 16 or 32bit. >> > > The evolving nature of first UCS and then Unicode standards has left > many language designers knocked off balance. Critical Mass first > introduced WIDECHAR as 16-bit when that was what everybody thought > was enough. Then things changed, and it wasn't anymore. Right now, > it's a configuration parameter (must be the same for the entire link > closure) in Modula-3. I personally favor making it full Unicode > by default, in the next release, as this is where the world is now. > This is hopefully a simpler problem than INTEGER, etc., because, as of > now, the Unicode committee has emphatically assured us that the range will > *never* increase. We can hope. Am 23.05.2015 um 03:58 schrieb Jay: > We use things with varying levels of abstraction. & concrete details are filled in at varying stages. C "long" is NOT specified as having an exact size and does NOT necessarily hold a pointer, and this is ok. > > > C99 is pretty complete, messy. > For each of 8, 16, 32, 64, > It gives "least", "fast", and "exact" types. And pointer sized. Signed and unsigned. 32 types! > > > INTEGER is always pointer sized. > LONGINT is on all platforms. > > > C# has this feature too. IntPtr & UIntPtr. But C# is dubious -- array indexes are always 32 bit signed. > > > - Jay From mika at async.caltech.edu Wed May 27 18:17:17 2015 From: mika at async.caltech.edu (mika at async.caltech.edu) Date: Wed, 27 May 2015 09:17:17 -0700 Subject: [M3devel] 64bit INTEGERs, WIDECHAR: language specified or configuration/target dependent? In-Reply-To: <6F9B9534-7DC2-4D4D-88CB-90D7FA05E8F9@elstel.org> References: <555E14BC.2040805@lcwb.coop>, <555E203E.4040203@elstel.org> <0A1CDD8C-EEB5-40E2-A38B-28E8EEA8C37E@elstel.org> <8A3AB2ED-C11E-4787-A7F8-C8F12157EAA5@elstel.org> <555F6D8F.4070109@lcwb.coop> <6F9B9534-7DC2-4D4D-88CB-90D7FA05E8F9@elstel.org> Message-ID: <20150527161717.83E761A2065@async.async.caltech.edu> ... >> Whether types like integer have a language-specified or = >target-dependent >> range is a tough language design question. I have tended to favor a >> fixed, language-specified range, but there are pros and cons. I do >> think all the time about end-of-range cases and native word size = >dependencies. >> It takes a great deal of care, and I know of no way to design a = >language >> that doesn't, to some extent, trade one set of problems for another. >> Signed/unsigned creates similar language dilemmas. > >* language-specified or target-dependent >As I have already suggested I believe there is some justification to = >have >both kinds of type: a language dependent type and a target dependent one > >The advantages of a language dependent type are rather clear when it >comes to mere INTEGERs for numeric/counting/calculation purposes. Once >you have a fixed size you can rely on support of a certain value range.=20= Hmm? Modula-3's INTEGERs are the "integers" of mathematics. The intent is that if your implementation is limited and doesn't support a particular operation because it goes out of range, your computation aborts. Same as any other implementation limitation. There is no reason I can think of you couldn't come up with an implementation that has unlimited-range integers. FIRST(INTEGER) and LAST(INTEGER) would have to be a little special. Mika From mika at async.caltech.edu Wed May 27 18:37:36 2015 From: mika at async.caltech.edu (mika at async.caltech.edu) Date: Wed, 27 May 2015 09:37:36 -0700 Subject: [M3devel] 64bit INTEGERs, WIDECHAR: language specified or configuration/target dependent? In-Reply-To: References: <555E14BC.2040805@lcwb.coop>, <555E203E.4040203@elstel.org> <0A1CDD8C-EEB5-40E2-A38B-28E8EEA8C37E@elstel.org> <8A3AB2ED-C11E-4787-A7F8-C8F12157EAA5@elstel.org> <555F6D8F.4070109@lcwb.coop> <6F9B9534-7DC2-4D4D-88CB-90D7FA05E8F9@elstel.org> <20150527161717.83E761A2065@async.async.caltech.edu> Message-ID: <20150527163736.B32DE1A2065@async.async.caltech.edu> Elmar Stellnberger writes: ... >I would have loved it to make INTEGER =3D BITS 32 FOR INTEGER and to = >allow >BITS 64 for INTEGER at the same time. However the way we have already = >gone is >to make LONGINT an own type with an own suffix like floats (the 'l' = >suffix). More >strictly typed and not so bad either.= Ah yes, LONGINT. I remain strongly opposed to that. I think it was a big mistake, it runs completely counter to Modula-3 design philosophy. INTEGERs are integers are integers are integers... fm: Command not found. Mika From estellnb at elstel.org Wed May 27 18:31:42 2015 From: estellnb at elstel.org (Elmar Stellnberger) Date: Wed, 27 May 2015 18:31:42 +0200 Subject: [M3devel] 64bit INTEGERs, WIDECHAR: language specified or configuration/target dependent? In-Reply-To: <20150527161717.83E761A2065@async.async.caltech.edu> References: <555E14BC.2040805@lcwb.coop>, <555E203E.4040203@elstel.org> <0A1CDD8C-EEB5-40E2-A38B-28E8EEA8C37E@elstel.org> <8A3AB2ED-C11E-4787-A7F8-C8F12157EAA5@elstel.org> <555F6D8F.4070109@lcwb.coop> <6F9B9534-7DC2-4D4D-88CB-90D7FA05E8F9@elstel.org> <20150527161717.83E761A2065@async.async.caltech.edu> Message-ID: Am 27.05.2015 um 18:17 schrieb mika at async.caltech.edu: > ... >>> Whether types like integer have a language-specified or = >> target-dependent >>> range is a tough language design question. I have tended to favor a >>> fixed, language-specified range, but there are pros and cons. I do >>> think all the time about end-of-range cases and native word size = >> dependencies. >>> It takes a great deal of care, and I know of no way to design a = >> language >>> that doesn't, to some extent, trade one set of problems for another. >>> Signed/unsigned creates similar language dilemmas. >> >> * language-specified or target-dependent >> As I have already suggested I believe there is some justification to = >> have >> both kinds of type: a language dependent type and a target dependent one >> >> The advantages of a language dependent type are rather clear when it >> comes to mere INTEGERs for numeric/counting/calculation purposes. Once >> you have a fixed size you can rely on support of a certain value range.=20= > > Hmm? > > Modula-3's INTEGERs are the "integers" of mathematics. The intent is > that if your implementation is limited and doesn't support a particular > operation because it goes out of range, your computation aborts. Same > as any other implementation limitation. > > There is no reason I can think of you couldn't come up with an implementation > that has unlimited-range integers. FIRST(INTEGER) and LAST(INTEGER) would have > to be a little special. > > Mika > I would have loved it to make INTEGER = BITS 32 FOR INTEGER and to allow BITS 64 for INTEGER at the same time. However the way we have already gone is to make LONGINT an own type with an own suffix like floats (the 'l' suffix). More strictly typed and not so bad either. From estellnb at elstel.org Wed May 27 18:32:20 2015 From: estellnb at elstel.org (Elmar Stellnberger) Date: Wed, 27 May 2015 18:32:20 +0200 Subject: [M3devel] 64bit INTEGERs, WIDECHAR: language specified or configuration/target dependent? In-Reply-To: <6F9B9534-7DC2-4D4D-88CB-90D7FA05E8F9@elstel.org> References: <555E14BC.2040805@lcwb.coop>, <555E203E.4040203@elstel.org> <0A1CDD8C-EEB5-40E2-A38B-28E8EEA8C37E@elstel.org> <8A3AB2ED-C11E-4787-A7F8-C8F12157EAA5@elstel.org> <555F6D8F.4070109@lcwb.coop> <6F9B9534-7DC2-4D4D-88CB-90D7FA05E8F9@elstel.org> Message-ID: <8BBBC94B-EECC-464A-86BB-FD1C94EC5496@elstel.org> Enough words about the history, now let us see how we can profit from both kinds of types when we wanna step on virgin soil: In what way we may ever turn things there actually needs to be a target sized type which is uses to be unsigned: the pointer. However there needs to be a way to do certain address calculations manually, apart from array indexing: multiply, add, subtract & evtl. shift. I would also believe that it would be handy to have such a type signed. i.e. offset = adress1 - adress2 Naturally such a type will profit from extending its value range to the bit size of pointers. Up to now converting everything to an int has sufficed. However it will no more for a 64bit arch. Will we need to convert to a LONGINT then? - but that will be in- compatible as LONGINT currently takes the 'l'-suffix and longint is not even supported for the 32bit arch as far as I know. Having an own type for this and other purposes like optimized numeric code would to my believe be beneficial. Call it OFFSET, TARGETINT, TargetInt.T or Offset.T Whether to just support such a type by a Word.T like interface or by a built-in type would likely be worth another discussion. So what for now? As I recall things we have introduced a LONGINT which takes the 0l - suffix for AMD64 only. The first thing would be to introduce a 64bit LONGINT for x86/32bit. and then? TYPE Offset.T = BITS BITSIZE(ADDRESS) FOR LONGINT ? We will have to rewrite some code that assumed offsets to be integers, then. The other possibility we have would be to make an offset a built-in type and assignment compatible to both int and longint which will save us from rewriting too much old code. I would claim this not to be a too big problem as converting back and forth between an OFFSET and an [LONG]INT should rarely happen. It would only be used in unsafe interfaces as all address arithmetics i.e. we should at least make that require an explicit conversion outside of unsafe interfaces. That way all expressions remained 100% compatible while only having to declare certain variables as OFFSET rather than INTEGER. > > Am 22.05.2015 um 19:55 schrieb Rodney M. Bates: >> The evolving nature of first UCS and then Unicode standards has left >> many language designers knocked off balance. Critical Mass first >> introduced WIDECHAR as 16-bit when that was what everybody thought >> was enough. Then things changed, and it wasn't anymore. Right now, >> it's a configuration parameter (must be the same for the entire link >> closure) in Modula-3. I personally favor making it full Unicode >> by default, in the next release, as this is where the world is now. >> This is hopefully a simpler problem than INTEGER, etc., because, as of >> now, the Unicode committee has emphatically assured us that the range will >> *never* increase. We can hope. By now I welcome your decision to make the WIDECHAR 32bit! I believe it should become the default for the upcoming release. Pure Modula-3 code will take advantage of the new value range. Just interfacing with certain external toolkits is not enough justification to freeze things as they are - interfaces need to be adapted anyway while supporting all three types is just too much unnecessary work. From hendrik at topoi.pooq.com Wed May 27 18:14:12 2015 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Wed, 27 May 2015 12:14:12 -0400 Subject: [M3devel] 64bit INTEGERs, WIDECHAR: language specified or configuration/target dependent? In-Reply-To: <20150527161717.83E761A2065@async.async.caltech.edu> References: <555E14BC.2040805@lcwb.coop> <555E203E.4040203@elstel.org> <0A1CDD8C-EEB5-40E2-A38B-28E8EEA8C37E@elstel.org> <8A3AB2ED-C11E-4787-A7F8-C8F12157EAA5@elstel.org> <555F6D8F.4070109@lcwb.coop> <6F9B9534-7DC2-4D4D-88CB-90D7FA05E8F9@elstel.org> <20150527161717.83E761A2065@async.async.caltech.edu> Message-ID: <20150527161412.GA18812@topoi.pooq.com> On Wed, May 27, 2015 at 09:17:17AM -0700, mika at async.caltech.edu wrote: > > Hmm? > > Modula-3's INTEGERs are the "integers" of mathematics. The intent is > that if your implementation is limited and doesn't support a particular > operation because it goes out of range, your computation aborts. Same > as any other implementation limitation. > > There is no reason I can think of you couldn't come up with an implementation > that has unlimited-range integers. FIRST(INTEGER) and LAST(INTEGER) would have > to be a little special. That was, in essence, my proposal for LONGINT, not for INTEGER. We still need an integer length that's efficient. I wasn't proposing to change the definition of INTEGER, FIRST(INTEGER), and so forth. But if one had a base tyoe of LONGINT and forbade declaring anything of type LONGINT, you could still have BITS 45 FOR LONGINT and the like. It just happens that the usual arithmetic operations are bounded in nature -- the number of bits in the result are bounded by functions of the numbers of bits in the operands, and an assignment so assigning to variable of could end up truncating, possibly with an overflow check. In fact, one could possibly define INTEGER to be BITS 32 FOR LONGINT, but that might involve further consequences in corrner case in the language. -- hendrik > > Mika From rodney_bates at lcwb.coop Thu May 28 01:30:50 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Wed, 27 May 2015 18:30:50 -0500 Subject: [M3devel] 64bit INTEGERs, WIDECHAR: language specified or configuration/target dependent? In-Reply-To: <20150527161412.GA18812@topoi.pooq.com> References: <555E14BC.2040805@lcwb.coop> <555E203E.4040203@elstel.org> <0A1CDD8C-EEB5-40E2-A38B-28E8EEA8C37E@elstel.org> <8A3AB2ED-C11E-4787-A7F8-C8F12157EAA5@elstel.org> <555F6D8F.4070109@lcwb.coop> <6F9B9534-7DC2-4D4D-88CB-90D7FA05E8F9@elstel.org> <20150527161717.83E761A2065@async.async.caltech.edu> <20150527161412.GA18812@topoi.pooq.com> Message-ID: <556653AA.1010105@lcwb.coop> Once more, with feeling. On 05/27/2015 11:14 AM, Hendrik Boom wrote: > On Wed, May 27, 2015 at 09:17:17AM -0700, mika at async.caltech.edu wrote: >> >> Hmm? >> >> Modula-3's INTEGERs are the "integers" of mathematics. The intent is >> that if your implementation is limited and doesn't support a particular >> operation because it goes out of range, your computation aborts. Same >> as any other implementation limitation. >> >> There is no reason I can think of you couldn't come up with an implementation >> that has unlimited-range integers. FIRST(INTEGER) and LAST(INTEGER) would have >> to be a little special. > > That was, in essence, my proposal for LONGINT, not for INTEGER. > We still need an integer length that's efficient. I wasn't proposing to > change the definition of INTEGER, FIRST(INTEGER), and so forth. > > But if one had a base tyoe of LONGINT and forbade declaring anything of > type LONGINT, you could still have BITS 45 FOR LONGINT and the like. TYPE U = BITS n FOR T *does not change the range of values.* The range of U is the same as that of T. If you try to stuff it into too few bits, e.g., BITS 4 FOR [ 0 .. 255 ], it is a static error. If you try to assign a value outside the value range, it is an error, generally at runtime, even if that value would fit in the bit count. E.g., VAR V : BITS 16 FOR [ 0 .. 255 ] := 256 is illegal. The *only* thing BITS n FOR does is, if legal, affect the amount of storage the compiler allocates, and *only for array elements and fields of RECORDs and OBJECTs*. Look at 2.2.5. > It just happens that the usual arithmetic operations are bounded in > nature -- the number of bits in the result are bounded by functions of > the numbers of bits in the operands, and an assignment so assigning > to variable of could end up truncating, possibly with an overflow > check. > > In fact, one could possibly define INTEGER to be BITS 32 FOR > LONGINT, but that might involve further consequences in corrner > case in the language. > > -- hendrik > >> >> Mika > -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Thu May 28 01:45:02 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Wed, 27 May 2015 18:45:02 -0500 Subject: [M3devel] 64bit INTEGERs, WIDECHAR: language specified or configuration/target dependent? In-Reply-To: <20150527163736.B32DE1A2065@async.async.caltech.edu> References: <555E14BC.2040805@lcwb.coop>, <555E203E.4040203@elstel.org> <0A1CDD8C-EEB5-40E2-A38B-28E8EEA8C37E@elstel.org> <8A3AB2ED-C11E-4787-A7F8-C8F12157EAA5@elstel.org> <555F6D8F.4070109@lcwb.coop> <6F9B9534-7DC2-4D4D-88CB-90D7FA05E8F9@elstel.org> <20150527161717.83E761A2065@async.async.caltech.edu> <20150527163736.B32DE1A2065@async.async.caltech.edu> Message-ID: <556656FE.1020003@lcwb.coop> On 05/27/2015 11:37 AM, mika at async.caltech.edu wrote: > Elmar Stellnberger writes: > ... >> I would have loved it to make INTEGER =3D BITS 32 FOR INTEGER and to = >> allow >> BITS 64 for INTEGER at the same time. However the way we have already = >> gone is >> to make LONGINT an own type with an own suffix like floats (the 'l' = >> suffix). More >> strictly typed and not so bad either.= > > Ah yes, LONGINT. > > I remain strongly opposed to that. I think it was a big mistake, it > runs completely counter to Modula-3 design philosophy. INTEGERs are > integers are integers are integers... fm: Command not found. > > Mika > The purpose of LONGINT is, cases where the program won't work with only 32-bit range, but you want the most efficient arithmetic possible on either a 32-bit or a 64-bit machine, without recoding. The compiler will generate either one-word machine arithmetic if the target has it, or two-word, if not. I suffered through this during the 16/32-bit transition, in Pascal and Modula-2. I had to write source-coded 2-word arithmetic, which would have been OK, if the entire universe didn't' have and never would have 32-bit machines. Instead, it unnecessarily wasted storage and computation when compiled on a 32-bit machine. The source code differences for best efficiency on either were a huge pain. -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Thu May 28 02:23:33 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Wed, 27 May 2015 19:23:33 -0500 Subject: [M3devel] 64bit INTEGERs, WIDECHAR: language specified or configuration/target dependent? In-Reply-To: <8BBBC94B-EECC-464A-86BB-FD1C94EC5496@elstel.org> References: <555E14BC.2040805@lcwb.coop>, <555E203E.4040203@elstel.org> <0A1CDD8C-EEB5-40E2-A38B-28E8EEA8C37E@elstel.org> <8A3AB2ED-C11E-4787-A7F8-C8F12157EAA5@elstel.org> <555F6D8F.4070109@lcwb.coop> <6F9B9534-7DC2-4D4D-88CB-90D7FA05E8F9@elstel.org> <8BBBC94B-EECC-464A-86BB-FD1C94EC5496@elstel.org> Message-ID: <55666005.4080406@lcwb.coop> On 05/27/2015 11:32 AM, Elmar Stellnberger wrote: > Enough words about the history, now let us see how we can profit > from both kinds of types when we wanna step on virgin soil: > > In what way we may ever turn things there actually needs to be > a target sized type which is uses to be unsigned: the pointer. > However there needs to be a way to do certain address > calculations manually, apart from array indexing: > multiply, add, subtract & evtl. shift. > I would also believe that it would be handy to have such a type > signed. > i.e. offset = adress1 - adress2 > > Naturally such a type will profit from extending its value range > to the bit size of pointers. > Up to now converting everything to an int has sufficed. However > it will no more for a 64bit arch. > Will we need to convert to a LONGINT then? - but that will be in- > compatible as LONGINT currently takes the 'l'-suffix and longint > is not even supported for the 32bit arch as far as I know. > > Having an own type for this and other purposes like optimized > numeric code would to my believe be beneficial. > Call it OFFSET, TARGETINT, TargetInt.T or Offset.T > Whether to just support such a type by a Word.T like interface > or by a built-in type would likely be worth another discussion. > Word.T (or Long.T, if INTEGER is smaller than a pointer) should pretty much do what you want. Of course, Word.T = INTEGER and Long.T = LONGINT. But the functions on Word/Long apply unsigned interpretation to the bits, with wraparound. The place you have to be careful is which arithmetic to use when, the builtin operators, or the functions in Word/Long. When I do this kind of arithmetic, I am careful about what variables are declared as INTEGER and what ones Word.T, solely to serve as documentation of whether the value is interpreted as signed or unsigned. With wraparound arithmetic, this distinction seldom or never matters for intermediate results, as long as you are clear about which invariant applies to each operand variable and the result variable. And, you are equally careful to think about the true overflow cases, as they affect the final result--something I doubt many do, even with ordinary, all-signed or all-unsigned arithmetic. > So what for now? As I recall things we have introduced > a LONGINT which takes the 0l - suffix for AMD64 only. No, ... > > The first thing would be to introduce a 64bit LONGINT for x86/32bit. We already have this. From 2.2.1: There are two integer types, which in order of increasing range are \verb|INTEGER| and \verb|LONGINT|. I do have the impression that some Windows targets are not currently in compliance, though. Can anybody elaborate? > > and then? > TYPE Offset.T = BITS BITSIZE(ADDRESS) FOR LONGINT ? > One thing we may not have is a way to make the choice between Word and Long self-adapt to match the size of reference types. BITS won't do it. See my recent post about BITS FOR. It could probably be done in the build system with some quake code. > We will have to rewrite some code that assumed offsets to be > integers, then. > > The other possibility we have would be to make an offset a built-in > type and assignment compatible to both int and longint which will > save us from rewriting too much old code. I would claim this not to > be a too big problem as converting back and forth between an > OFFSET and an [LONG]INT should rarely happen. It would only > be used in unsafe interfaces as all address arithmetics > i.e. we should at least make that require an explicit conversion > outside of unsafe interfaces. That way all expressions remained > 100% compatible while only having to declare certain variables > as OFFSET rather than INTEGER. > > >> >> Am 22.05.2015 um 19:55 schrieb Rodney M. Bates: > >>> The evolving nature of first UCS and then Unicode standards has left >>> many language designers knocked off balance. Critical Mass first >>> introduced WIDECHAR as 16-bit when that was what everybody thought >>> was enough. Then things changed, and it wasn't anymore. Right now, >>> it's a configuration parameter (must be the same for the entire link >>> closure) in Modula-3. I personally favor making it full Unicode >>> by default, in the next release, as this is where the world is now. >>> This is hopefully a simpler problem than INTEGER, etc., because, as of >>> now, the Unicode committee has emphatically assured us that the range will >>> *never* increase. We can hope. > > By now I welcome your decision to make the WIDECHAR 32bit! > I believe it should become the default for the upcoming release. > Pure Modula-3 code will take advantage of the new value range. > Just interfacing with certain external toolkits is not enough > justification to freeze things as they are - interfaces need to be > adapted anyway while supporting all three types is just too much > unnecessary work. > > -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Thu May 28 02:41:35 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Wed, 27 May 2015 19:41:35 -0500 Subject: [M3devel] 64bit INTEGERs, WIDECHAR: language specified or configuration/target dependent? In-Reply-To: <20150527161717.83E761A2065@async.async.caltech.edu> References: <555E14BC.2040805@lcwb.coop>, <555E203E.4040203@elstel.org> <0A1CDD8C-EEB5-40E2-A38B-28E8EEA8C37E@elstel.org> <8A3AB2ED-C11E-4787-A7F8-C8F12157EAA5@elstel.org> <555F6D8F.4070109@lcwb.coop> <6F9B9534-7DC2-4D4D-88CB-90D7FA05E8F9@elstel.org> <20150527161717.83E761A2065@async.async.caltech.edu> Message-ID: <5566643F.3090603@lcwb.coop> On 05/27/2015 11:17 AM, mika at async.caltech.edu wrote: > ... >>> Whether types like integer have a language-specified or = >> target-dependent >>> range is a tough language design question. I have tended to favor a >>> fixed, language-specified range, but there are pros and cons. I do >>> think all the time about end-of-range cases and native word size = >> dependencies. >>> It takes a great deal of care, and I know of no way to design a = >> language >>> that doesn't, to some extent, trade one set of problems for another. >>> Signed/unsigned creates similar language dilemmas. >> >> * language-specified or target-dependent >> As I have already suggested I believe there is some justification to = >> have >> both kinds of type: a language dependent type and a target dependent one >> >> The advantages of a language dependent type are rather clear when it >> comes to mere INTEGERs for numeric/counting/calculation purposes. Once >> you have a fixed size you can rely on support of a certain value range.=20= > > Hmm? > > Modula-3's INTEGERs are the "integers" of mathematics. The intent is > that if your implementation is limited and doesn't support a particular > operation because it goes out of range, your computation aborts. Same > as any other implementation limitation. > > There is no reason I can think of you couldn't come up with an implementation > that has unlimited-range integers. FIRST(INTEGER) and LAST(INTEGER) would have > to be a little special. > We've got it in library code: cm3/m3-libs/arithmetic/src/basictypes/biginteger/BigInteger.i3 Does it need to be improved? I've never used it. But it can't just replace a fixed-sized integer type like INTEGER in a language, because we really need INTEGER for subscripts to the array of INTEGERs that implements BigInteger, and lots of other stuff. For a precedent, mathematicians have never, AFAIK, proposed to generalize the infinite series' used to compute powers and roots by replacing the integer subscripts of the series with rationals, reals, or complexes. What is the Pi'th term in an infinite series? > Mika > -- Rodney Bates rodney.m.bates at acm.org From jay.krell at cornell.edu Thu May 28 07:52:51 2015 From: jay.krell at cornell.edu (Jay K) Date: Thu, 28 May 2015 05:52:51 +0000 Subject: [M3devel] 64bit INTEGERs, WIDECHAR: language specified or configuration/target dependent? In-Reply-To: <77605189-D966-4D4B-8946-838BD6E178AA@purdue.edu> References: <555E14BC.2040805@lcwb.coop> <555E203E.4040203@elstel.org>, , , <0A1CDD8C-EEB5-40E2-A38B-28E8EEA8C37E@elstel.org>, , <8A3AB2ED-C11E-4787-A7F8-C8F12157EAA5@elstel.org>, <555F6D8F.4070109@lcwb.coop>, <6F9B9534-7DC2-4D4D-88CB-90D7FA05E8F9@elstel.org>, <8BBBC94B-EECC-464A-86BB-FD1C94EC5496@elstel.org>, <77605189-D966-4D4B-8946-838BD6E178AA@purdue.edu> Message-ID: I believe the proposal is that INTEGER be more like int in C and C+ -- 32bits always. > I do have the impression that some Windows targets are not currently All targets have a 64bit LONGINT. I implemented this years ago in the NT/x86 backend. The C backend depends on the underlying C compiler having __int64 or long long or a 64bit long. All targets have BYTESIZE(INTEGER) == BYTESIZE(ADDRESS). In C and C++, long is smaller than a pointer on Win64. On Windows, int and long are always 32 bits. This might be the case at least sort of on VMS and HP-UX, at least when the upper bits of 64bit pointers are guaranteed all zeros or all ones or ignored. They have such environments -- 32bit-ish pointers on Alpha, 32bit-ish pointers on IA64. I started writing up more detail. There are obviously 8 underlying integer types: unsigned/signed 8/16/32/64 A typical C99 environment has around 40 names for them: stdint.h: 8+16+32+64 x signed/unsigned x fast+least+exact: 24 short/int/long/long long; unsigned: 8 char/unsigned char/signed char: 3 [u]intptr_t: 2 size_t/ptrdiff_t: 2 wchar_t: 1 => 40 In C++, some of them are distinct for overloading/mangling purposes. Windows has far more, like almost double, for various historical and typographical and stylistic reasons. e.g. INT, UINT, LONG, ULONG, WCHAR, CHAR, UCHAR, BYTE, WORD, DWORD, DWORD_PTR, INT_PTR, UINT_PTR, SIZE_T, HALF_PTR, etc. But still the same underlying 8 types. It can be difficult to chose the right type. It is tempting to discount many of them, and many can be discounted, but it hard to really narrow the list to be small. Should we add some more builtins to the frontend? Like [U]INT[8,16,32,64]? Or lowercase and _t? - Jay > Subject: Re: [M3devel] 64bit INTEGERs, WIDECHAR: language specified or configuration/target dependent? > From: hosking at purdue.edu > Date: Thu, 28 May 2015 05:03:39 +0300 > CC: rodney.m.bates at acm.org; jay.krell at cornell.edu; m3devel at elegosoft.com > To: estellnb at elstel.org > > BYTESIZE(ADDRESS) = BYTESIZE(INTEGER) in cm3 on all target platforms. I don't really understand what you are proposing. > > Sent from my iPhone > > > On May 27, 2015, at 7:32 PM, Elmar Stellnberger wrote: > > > > Enough words about the history, now let us see how we can profit > > from both kinds of types when we wanna step on virgin soil: > > > > In what way we may ever turn things there actually needs to be > > a target sized type which is uses to be unsigned: the pointer. > > However there needs to be a way to do certain address > > calculations manually, apart from array indexing: > > multiply, add, subtract & evtl. shift. > > I would also believe that it would be handy to have such a type > > signed. > > i.e. offset = adress1 - adress2 > > > > Naturally such a type will profit from extending its value range > > to the bit size of pointers. > > Up to now converting everything to an int has sufficed. However > > it will no more for a 64bit arch. > > Will we need to convert to a LONGINT then? - but that will be in- > > compatible as LONGINT currently takes the 'l'-suffix and longint > > is not even supported for the 32bit arch as far as I know. > > > > Having an own type for this and other purposes like optimized > > numeric code would to my believe be beneficial. > > Call it OFFSET, TARGETINT, TargetInt.T or Offset.T > > Whether to just support such a type by a Word.T like interface > > or by a built-in type would likely be worth another discussion. > > > > So what for now? As I recall things we have introduced > > a LONGINT which takes the 0l - suffix for AMD64 only. > > > > The first thing would be to introduce a 64bit LONGINT for x86/32bit. > > > > and then? > > TYPE Offset.T = BITS BITSIZE(ADDRESS) FOR LONGINT ? > > > > We will have to rewrite some code that assumed offsets to be > > integers, then. > > > > The other possibility we have would be to make an offset a built-in > > type and assignment compatible to both int and longint which will > > save us from rewriting too much old code. I would claim this not to > > be a too big problem as converting back and forth between an > > OFFSET and an [LONG]INT should rarely happen. It would only > > be used in unsafe interfaces as all address arithmetics > > i.e. we should at least make that require an explicit conversion > > outside of unsafe interfaces. That way all expressions remained > > 100% compatible while only having to declare certain variables > > as OFFSET rather than INTEGER. > > > > > >> > >> Am 22.05.2015 um 19:55 schrieb Rodney M. Bates: > > > >>> The evolving nature of first UCS and then Unicode standards has left > >>> many language designers knocked off balance. Critical Mass first > >>> introduced WIDECHAR as 16-bit when that was what everybody thought > >>> was enough. Then things changed, and it wasn't anymore. Right now, > >>> it's a configuration parameter (must be the same for the entire link > >>> closure) in Modula-3. I personally favor making it full Unicode > >>> by default, in the next release, as this is where the world is now. > >>> This is hopefully a simpler problem than INTEGER, etc., because, as of > >>> now, the Unicode committee has emphatically assured us that the range will > >>> *never* increase. We can hope. > > > > By now I welcome your decision to make the WIDECHAR 32bit! > > I believe it should become the default for the upcoming release. > > Pure Modula-3 code will take advantage of the new value range. > > Just interfacing with certain external toolkits is not enough > > justification to freeze things as they are - interfaces need to be > > adapted anyway while supporting all three types is just too much > > unnecessary work. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adacore at marino.st Thu May 28 11:50:13 2015 From: adacore at marino.st (John Marino) Date: Thu, 28 May 2015 11:50:13 +0200 Subject: [M3devel] scripts/README obsolete (where is boot-cm3-with-m3.sh ?) Message-ID: <5566E4D5.3070402@marino.st> I just downloaded the current repo at github. the scripts/README hasn't changed, it still talks about boot-cm3-with-m3.sh, but that script is missing now. What has taken its place? I recommend the README be updated because it is wrong now. John From adacore at marino.st Thu May 28 12:23:54 2015 From: adacore at marino.st (John Marino) Date: Thu, 28 May 2015 12:23:54 +0200 Subject: [M3devel] scripts/README obsolete (where is boot-cm3-with-m3.sh ?) In-Reply-To: <5566E4D5.3070402@marino.st> References: <5566E4D5.3070402@marino.st> Message-ID: <5566ECBA.2050006@marino.st> On 5/28/2015 11:50, John Marino wrote: > I just downloaded the current repo at github. > > the scripts/README hasn't changed, it still talks about > boot-cm3-with-m3.sh, but that script is missing now. > > What has taken its place? > > I recommend the README be updated because it is wrong now. > FWIW, I copied boot-cm3-with-m3.sh from 5.8.6 and it seemed to work for a while but when the compiler hit src/TIntN.i3 it blew up. So it appears that the bootstrap (5.8.6) can't build 5.10.0. John From adacore at marino.st Thu May 28 13:12:03 2015 From: adacore at marino.st (John Marino) Date: Thu, 28 May 2015 13:12:03 +0200 Subject: [M3devel] scripts/README obsolete (where is boot-cm3-with-m3.sh ?) In-Reply-To: <5566ECBA.2050006@marino.st> References: <5566E4D5.3070402@marino.st> <5566ECBA.2050006@marino.st> Message-ID: <5566F803.10902@marino.st> On 5/28/2015 12:23, John Marino wrote: > On 5/28/2015 11:50, John Marino wrote: >> I just downloaded the current repo at github. >> >> the scripts/README hasn't changed, it still talks about >> boot-cm3-with-m3.sh, but that script is missing now. >> >> What has taken its place? >> >> I recommend the README be updated because it is wrong now. >> > > FWIW, I copied boot-cm3-with-m3.sh from 5.8.6 and it seemed to work for > a while but when the compiler hit src/TIntN.i3 it blew up. > > So it appears that the bootstrap (5.8.6) can't build 5.10.0. > Searching old messages, I found scripts/python/upgrade.py which seems to be working. The documentation seems to be really behind! John From adacore at marino.st Thu May 28 13:49:04 2015 From: adacore at marino.st (John Marino) Date: Thu, 28 May 2015 13:49:04 +0200 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 Message-ID: <556700B0.8060500@marino.st> I got stuck again trying to build the latest on FreeBSD. 1. tar extracted to working directory along with a bootstrap compiler 2. CM3 and CM3_INSTALL defined in environment 3. executed scripts/python/upgrade.py result: http://leaf.dragonflybsd.org/~marino/m3.log I could guess that something is picking up a bootstrap component instead of a newly built one. I guess it's trying to build the c backend? Am I doing some kind of obvious mistake? John From wagner at elego.de Thu May 28 16:02:21 2015 From: wagner at elego.de (Olaf Wagner) Date: Thu, 28 May 2015 16:02:21 +0200 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <556700B0.8060500@marino.st> References: <556700B0.8060500@marino.st> Message-ID: <20150528160221.95d4c26d83f68f8cfa93d75a@elego.de> On Thu, 28 May 2015 13:49:04 +0200 John Marino wrote: > I got stuck again trying to build the latest on FreeBSD. > > 1. tar extracted to working directory along with a bootstrap compiler > 2. CM3 and CM3_INSTALL defined in environment > 3. executed scripts/python/upgrade.py > > result: > http://leaf.dragonflybsd.org/~marino/m3.log > > I could guess that something is picking up a bootstrap component instead > of a newly built one. I guess it's trying to build the c backend? > > Am I doing some kind of obvious mistake? No. I think upgrade.sh (or .py) cannot really cope with updating a 5.8.6 instance to the current state. It took me several days, too, on MacOS X, and I had to do a lot of manual tweaking and copying around. I don't think any casual user will understand the details :-| IMO the best thing we can do now is provide some more up-to-date binary archives (I'll upload my own stuff as soon as I find the time). A newer release has been missing for several years, and the existing scripts are no great help for new users. Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From adacore at marino.st Thu May 28 16:14:11 2015 From: adacore at marino.st (John Marino) Date: Thu, 28 May 2015 16:14:11 +0200 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <20150528160221.95d4c26d83f68f8cfa93d75a@elego.de> References: <556700B0.8060500@marino.st> <20150528160221.95d4c26d83f68f8cfa93d75a@elego.de> Message-ID: <556722B3.7080209@marino.st> On 5/28/2015 16:02, Olaf Wagner wrote: > On Thu, 28 May 2015 13:49:04 +0200 > John Marino wrote: >> Am I doing some kind of obvious mistake? > > No. I think upgrade.sh (or .py) cannot really cope with updating a 5.8.6 > instance to the current state. It took me several days, too, on > MacOS X, and I had to do a lot of manual tweaking and copying > around. I don't think any casual user will understand the details That's a pretty big sin given how 5.8.6 is the current release! > IMO the best thing we can do now is provide some more up-to-date > binary archives (I'll upload my own stuff as soon as I find the time). > A newer release has been missing for several years, and the existing > scripts are no great help for new users. Is there a git tag that can build from 5.8.6? Maybe I just have to keep doing this until I get a new bootstrap that can do it. John From rodney_bates at lcwb.coop Thu May 28 17:01:21 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 28 May 2015 10:01:21 -0500 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <556700B0.8060500@marino.st> References: <556700B0.8060500@marino.st> Message-ID: <55672DC1.7080509@lcwb.coop> On 05/28/2015 06:49 AM, John Marino wrote: > I got stuck again trying to build the latest on FreeBSD. > > 1. tar extracted to working directory along with a bootstrap compiler > 2. CM3 and CM3_INSTALL defined in environment > 3. executed scripts/python/upgrade.py > > result: > http://leaf.dragonflybsd.org/~marino/m3.log > > I could guess that something is picking up a bootstrap component instead > of a newly built one. Yes. >> m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 means it is trying to compile using a new cm3cg backend and an old cm3 front end. I just added this error message after Olaf had this problem. (Otherwise it would have failed anyway, but with a less informative message.) > I guess it's trying to build the c backend? > It finished the C backend and was trying to build m3core, using the inconsistent compiler. Usually, neither cm3 nor cm3cg is copied to the bin directory, even when doing a ship, in order to avoid this, which is an exception. For all other executables, ship copies them to the bin directory. The shell script scripts/install-cm3-compiler.sh is then run manually, after both cm3 and cm3cg are compiled, to copy them to bin atomically (sort of). I don't know why that happened. I don't have experience with the Python scripts. Jay? Also, this script built the compiler before the support libraries m3core and libm3. I think there may have been one bootstrap scenario where this was the way it needed to be done, but usually it is the other way around--these two libraries first. > Am I doing some kind of obvious mistake? > No, it's a bootstrap barrier. These pop up somewhat regularly. We all usually just build from the most recent development build, which works for getting new things tried out initially. But we need to make a habit of regularly rebuilding from the previous release to flush these out. You might try scripts/do-cm3-front.sh realclean scripts/do-cm3-front.sh buildship (I usually save /usr/local/cm3/bin/cm3 and /usr/local/cm3/bin/cm3cg at this point. The step below does it somewhat redundantly, but only one level, unless the version number changes.) scripts/install-cm3-compiler.sh upgrade. From here, you are using the new compiler. scripts/do-cm3-.sh buildship That this works, starting with the previous release compiler, is my criterion for having removed bootstrap barriers. > John > -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Thu May 28 17:17:08 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 28 May 2015 10:17:08 -0500 Subject: [M3devel] Too many names for the gcc backend. Was: m3cgc1: fatal error ... In-Reply-To: <556700B0.8060500@marino.st> References: <556700B0.8060500@marino.st> Message-ID: <55673174.80804@lcwb.coop> BTW, the gcc-derived back end has too many names. m3cc: The package name m3cg: The directory containing glue code to gcc m3cgc1: The executable built inside m3cc. Also, what it identifies itself as in error messages cm3cg: The executable, when installed in /usr/local/cm3/bin Did I even get it complete or right? On 05/28/2015 06:49 AM, John Marino wrote: > I got stuck again trying to build the latest on FreeBSD. > > 1. tar extracted to working directory along with a bootstrap compiler > 2. CM3 and CM3_INSTALL defined in environment > 3. executed scripts/python/upgrade.py > > result: > http://leaf.dragonflybsd.org/~marino/m3.log > > I could guess that something is picking up a bootstrap component instead > of a newly built one. I guess it's trying to build the c backend? > > Am I doing some kind of obvious mistake? > > John > -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Thu May 28 17:21:47 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 28 May 2015 10:21:47 -0500 Subject: [M3devel] 64bit INTEGERs, WIDECHAR: language specified or configuration/target dependent? In-Reply-To: <77605189-D966-4D4B-8946-838BD6E178AA@purdue.edu> References: <555E14BC.2040805@lcwb.coop> <555E203E.4040203@elstel.org> <0A1CDD8C-EEB5-40E2-A38B-28E8EEA8C37E@elstel.org> <8A3AB2ED-C11E-4787-A7F8-C8F12157EAA5@elstel.org> <555F6D8F.4070109@lcwb.coop> <6F9B9534-7DC2-4D4D-88CB-90D7FA05E8F9@elstel.org> <8BBBC94B-EECC-464A-86BB-FD1C94EC5496@elstel.org> <77605189-D966-4D4B-8946-838BD6E178AA@purdue.edu> Message-ID: <5567328B.70003@lcwb.coop> On 05/27/2015 09:03 PM, Antony Hosking wrote: > BYTESIZE(ADDRESS) = BYTESIZE(INTEGER) in cm3 on all target platforms. I don't really understand what you are proposing. > I am glad to hear that. > Sent from my iPhone > -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Thu May 28 17:23:48 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 28 May 2015 10:23:48 -0500 Subject: [M3devel] 64bit INTEGERs, WIDECHAR: language specified or configuration/target dependent? In-Reply-To: References: <555E14BC.2040805@lcwb.coop> <555E203E.4040203@elstel.org>, , , <0A1CDD8C-EEB5-40E2-A38B-28E8EEA8C37E@elstel.org>, , <8A3AB2ED-C11E-4787-A7F8-C8F12157EAA5@elstel.org>, <555F6D8F.4070109@lcwb.coop>, <6F9B9534-7DC2-4D4D-88CB-90D7FA05E8F9@elstel.org>, <8BBBC94B-EECC-464A-86BB-FD1C94EC5496@elstel.org>, <77605189-D966-4D4B-8946-838BD6E178AA@purdue.edu> Message-ID: <55673304.5090602@lcwb.coop> On 05/28/2015 12:52 AM, Jay K wrote: > I believe the proposal is that INTEGER be more like int in C and C+ -- 32bits always. > > > > I do have the impression that some Windows targets are not currently > > > All targets have a 64bit LONGINT. I implemented this years ago in the NT/x86 backend. Glad to hear that, too. -- Rodney Bates rodney.m.bates at acm.org From adacore at marino.st Thu May 28 17:56:20 2015 From: adacore at marino.st (John Marino) Date: Thu, 28 May 2015 17:56:20 +0200 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <55672DC1.7080509@lcwb.coop> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> Message-ID: <55673AA4.8050100@marino.st> On 5/28/2015 17:01, Rodney M. Bates wrote: > I don't know why that happened. I don't have experience with the > Python scripts. > > Jay? > > Also, this script built the compiler before the support libraries > m3core and libm3. I think there may have been one bootstrap scenario > where this was the way it needed to be done, but usually it is the > other way around--these two libraries first. > >> Am I doing some kind of obvious mistake? >> > No, it's a bootstrap barrier. These pop up somewhat regularly. We > all usually just build from the most recent development build, which > works for getting new things tried out initially. But we need to > make a habit of regularly rebuilding from the previous release to > flush these out. Olaf said, IIUC, that the current code can't be built by the last release compiler. Putting aside that I believe that should be a hard requirement for the project, it sounds like maybe the last release can build it if the build order is fixed (e.g. a better upgrade.py script)? It's not clear to me what the real situation is. > You might try scripts/do-cm3-front.sh realclean > scripts/do-cm3-front.sh buildship > > (I usually save /usr/local/cm3/bin/cm3 and /usr/local/cm3/bin/cm3cg > at this point. The step below does it somewhat redundantly, but only > one level, unless the version number changes.) > > scripts/install-cm3-compiler.sh upgrade. > From here, you are using the new compiler. > scripts/do-cm3-.sh buildship > > That this works, starting with the previous release compiler, is my > criterion for having removed bootstrap barriers. My work takes place within a Makefile and moving things in /usr/local (for example) is actually illegal. Now I could do all this manually for the purpose of building a new bootstrap, but as I mentioned in a previous post, it might be more effective to emulate what you guy have done: essentially build a series of bootstraps at strategic hashes until I've acquired a compiler that can build this (and then use that product as bootstrap for FreeBSD ports). If I did that approach, I could use a hint on the hashes to try... John From jay.krell at cornell.edu Thu May 28 18:16:48 2015 From: jay.krell at cornell.edu (Jay) Date: Thu, 28 May 2015 09:16:48 -0700 Subject: [M3devel] 64bit INTEGERs, WIDECHAR: language specified or configuration/target dependent? In-Reply-To: <20150527161412.GA18812@topoi.pooq.com> References: <555E14BC.2040805@lcwb.coop> <555E203E.4040203@elstel.org> <0A1CDD8C-EEB5-40E2-A38B-28E8EEA8C37E@elstel.org> <8A3AB2ED-C11E-4787-A7F8-C8F12157EAA5@elstel.org> <555F6D8F.4070109@lcwb.coop> <6F9B9534-7DC2-4D4D-88CB-90D7FA05E8F9@elstel.org> <20150527161717.83E761A2065@async.async.caltech.edu> <20150527161412.GA18812@topoi.pooq.com> Message-ID: <11BEF01E-B5F6-4FD3-A7B3-FDEDAD481D42@gmail.com> Arbitrary fixed width integers in the language? Kinda nice. 1. Bits X for integer? Why call it longint? Make the range affected? 2. Once you have operator overloading these language debates fall away and become easier but still non-trivial library debates. Similar thing happens with strings, complex numbers, arrays. Stuff that people like to build into languages because the language can't accommodate writing efficient easy to use libraries. Mutexes too but due to other language features (stack allocated classes with destructors). Even hashtables benefit, from operator[]. Maybe worth evolving the language this way? Name overloading too. e.g. You want String.Plus(char) and String.Plus(string). - Jay On May 27, 2015, at 9:14 AM, Hendrik Boom wrote: > On Wed, May 27, 2015 at 09:17:17AM -0700, mika at async.caltech.edu wrote: >> >> Hmm? >> >> Modula-3's INTEGERs are the "integers" of mathematics. The intent is >> that if your implementation is limited and doesn't support a particular >> operation because it goes out of range, your computation aborts. Same >> as any other implementation limitation. >> >> There is no reason I can think of you couldn't come up with an implementation >> that has unlimited-range integers. FIRST(INTEGER) and LAST(INTEGER) would have >> to be a little special. > > That was, in essence, my proposal for LONGINT, not for INTEGER. > We still need an integer length that's efficient. I wasn't proposing to > change the definition of INTEGER, FIRST(INTEGER), and so forth. > > But if one had a base tyoe of LONGINT and forbade declaring anything of > type LONGINT, you could still have BITS 45 FOR LONGINT and the like. > It just happens that the usual arithmetic operations are bounded in > nature -- the number of bits in the result are bounded by functions of > the numbers of bits in the operands, and an assignment so assigning > to variable of could end up truncating, possibly with an overflow > check. > > In fact, one could possibly define INTEGER to be BITS 32 FOR > LONGINT, but that might involve further consequences in corrner > case in the language. > > -- hendrik > >> >> Mika From wagner at elegosoft.com Thu May 28 19:06:43 2015 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 28 May 2015 19:06:43 +0200 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <55673AA4.8050100@marino.st> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> Message-ID: <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> On Thu, 28 May 2015 17:56:20 +0200 John Marino wrote: > On 5/28/2015 17:01, Rodney M. Bates wrote: > > I don't know why that happened. I don't have experience with the > > Python scripts. > > > > Jay? > > > > Also, this script built the compiler before the support libraries > > m3core and libm3. I think there may have been one bootstrap scenario > > where this was the way it needed to be done, but usually it is the > > other way around--these two libraries first. > > > >> Am I doing some kind of obvious mistake? > >> > > No, it's a bootstrap barrier. These pop up somewhat regularly. We > > all usually just build from the most recent development build, which > > works for getting new things tried out initially. But we need to > > make a habit of regularly rebuilding from the previous release to > > flush these out. > > Olaf said, IIUC, that the current code can't be built by the last > release compiler. Putting aside that I believe that should be a hard > requirement for the project, it sounds like maybe the last release can > build it if the build order is fixed (e.g. a better upgrade.py script)? > It's not clear to me what the real situation is. No, this is a misunderstanding. I just said or tried to say that there is no script (yet) that is smart enough to do all the things necessary to build the current compiler on base of 5.8.6. > > You might try scripts/do-cm3-front.sh realclean > > scripts/do-cm3-front.sh buildship > > > > (I usually save /usr/local/cm3/bin/cm3 and /usr/local/cm3/bin/cm3cg > > at this point. The step below does it somewhat redundantly, but only > > one level, unless the version number changes.) > > > > scripts/install-cm3-compiler.sh upgrade. > > From here, you are using the new compiler. > > scripts/do-cm3-.sh buildship > > > > That this works, starting with the previous release compiler, is my > > criterion for having removed bootstrap barriers. Rodney, have you really tried that? I'm not sure the steps above will work. I had the feeling that we're missing some intermediate releases, but I might be wrong there. > My work takes place within a Makefile and moving things in /usr/local > (for example) is actually illegal. Now I could do all this manually for > the purpose of building a new bootstrap, but as I mentioned in a > previous post, it might be more effective to emulate what you guy have > done: essentially build a series of bootstraps at strategic hashes until > I've acquired a compiler that can build this (and then use that product > as bootstrap for FreeBSD ports). > > If I did that approach, I could use a hint on the hashes to try... We should be able to script something that sets up the current compiler at least on a given specific platform with a well-defined environment. I might be able to offer more help in the second week of June, if you can wait until then. Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Thu May 28 19:12:19 2015 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 28 May 2015 19:12:19 +0200 Subject: [M3devel] Too many names for the gcc backend. Was: m3cgc1: fatal error ... In-Reply-To: <55673174.80804@lcwb.coop> References: <556700B0.8060500@marino.st> <55673174.80804@lcwb.coop> Message-ID: <20150528191219.2718dd20002b3678121306c9@elegosoft.com> On Thu, 28 May 2015 10:17:08 -0500 "Rodney M. Bates" wrote: > BTW, the gcc-derived back end has too many names. > > m3cc: The package name > m3cg: The directory containing glue code to gcc > m3cgc1: The executable built inside m3cc. > Also, what it identifies itself as in error messages > cm3cg: The executable, when installed in /usr/local/cm3/bin > > Did I even get it complete or right? Yes. It's all due to historical reasons, IIRC. m3cgc1 was the name in the PM3 distribution, and Critical Mass used the cm3cg name. I never changed any of the names intentionally, though I should perhaps have done that, when we made the open source release of the CM3 code base. Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From estellnb at elstel.org Thu May 28 19:46:12 2015 From: estellnb at elstel.org (Elmar Stellnberger) Date: Thu, 28 May 2015 19:46:12 +0200 Subject: [M3devel] 64bit INTEGERs, WIDECHAR: language specified or configuration/target dependent? In-Reply-To: <77605189-D966-4D4B-8946-838BD6E178AA@purdue.edu> References: <555E14BC.2040805@lcwb.coop> <555E203E.4040203@elstel.org> <0A1CDD8C-EEB5-40E2-A38B-28E8EEA8C37E@elstel.org> <8A3AB2ED-C11E-4787-A7F8-C8F12157EAA5@elstel.org> <555F6D8F.4070109@lcwb.coop> <6F9B9534-7DC2-4D4D-88CB-90D7FA05E8F9@elstel.org> <8BBBC94B-EECC-464A-86BB-FD1C94EC5496@elstel.org> <77605189-D966-4D4B-8946-838BD6E178AA@purdue.edu> Message-ID: <55675464.5090306@elstel.org> Am 28.05.15 um 04:03 schrieb Antony Hosking: > BYTESIZE(ADDRESS) = BYTESIZE(INTEGER) in cm3 on all target platforms. I don't really understand what you are proposing. > on AMD64: BITSIZE(INTEGER) = BITSIZE(LONGINT) = 64bit I have just noticed that and when taking a practical standpoint - i.e. what really matters to new and old programs - this is a really bad decision which I wish to change for the next release. If you have not examined it yet please reclaim the design decisions for leaving int 32bit in C: /However things turned out to be very different when the extension from 32bit to 64bit was at stake. There was no more gain by automatically extending the value ranges from 2^32 to 2^64 for 95% of all application purposes while the memory hierarchy has increasingly become a bottle neck in recent time. Additionally doubling the size of all integers would initially have doubled our memory needs which would have been a potential drawback for introducing the AMD64 arch. Just think of a machine with 4GB of RAM: It can not be addressed by 32bit (only ~3GB can) while making all INTS 64bit would have shrunken our memory to an effective size of 2GB. Luckily the decision was taken differently this time: * keep all ints of at most 32bit and just extend pointers to 64bit / Same reasoning applies to Modula-3. - and I believe you have failed to notice when making your decisions for cm3 5.8.6. Or do you want to tell me that Modula-3 developers are more prudent than the C/C++ community? Even worse I have discovered the following: BITS 8 FOR INTEGER and BITS 32 FOR INTEGER do not work with cm3 5.8.6: :: BITS FOR size too small, must be at least (64) That will break existing legacy code when trying to compile it with cm3 5.8.6. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Thu May 28 16:18:11 2015 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Thu, 28 May 2015 10:18:11 -0400 Subject: [M3devel] 64bit INTEGERs, WIDECHAR: language specified or configuration/target dependent? In-Reply-To: <556653AA.1010105@lcwb.coop> References: <0A1CDD8C-EEB5-40E2-A38B-28E8EEA8C37E@elstel.org> <8A3AB2ED-C11E-4787-A7F8-C8F12157EAA5@elstel.org> <555F6D8F.4070109@lcwb.coop> <6F9B9534-7DC2-4D4D-88CB-90D7FA05E8F9@elstel.org> <20150527161717.83E761A2065@async.async.caltech.edu> <20150527161412.GA18812@topoi.pooq.com> <556653AA.1010105@lcwb.coop> Message-ID: <20150528141810.GA19285@topoi.pooq.com> On Wed, May 27, 2015 at 06:30:50PM -0500, Rodney M. Bates wrote: > Once more, with feeling. > > On 05/27/2015 11:14 AM, Hendrik Boom wrote: > >On Wed, May 27, 2015 at 09:17:17AM -0700, mika at async.caltech.edu wrote: > >> > >>Hmm? > >> > >>Modula-3's INTEGERs are the "integers" of mathematics. The intent is > >>that if your implementation is limited and doesn't support a particular > >>operation because it goes out of range, your computation aborts. Same > >>as any other implementation limitation. > >> > >>There is no reason I can think of you couldn't come up with an implementation > >>that has unlimited-range integers. FIRST(INTEGER) and LAST(INTEGER) would have > >>to be a little special. > > > >That was, in essence, my proposal for LONGINT, not for INTEGER. > >We still need an integer length that's efficient. I wasn't proposing to > >change the definition of INTEGER, FIRST(INTEGER), and so forth. > > > >But if one had a base tyoe of LONGINT and forbade declaring anything of > >type LONGINT, you could still have BITS 45 FOR LONGINT and the like. I should probably have said something like -2^44-1 .. 2^44, or whatever those numbers are when spelled out in decimal. Of course the syntax for this might still have to indicate LONGINT somehow, because I'd have doubts about the base type depending on the size of the numbers I coded. The base type affects a lot of assumptions about things like the default subscript type for dynamic arrays and the like. > > TYPE U = BITS n FOR T *does not change the range of values.* The range > of U is the same as that of T. WHich is why I should have used a range instead of a number of bits. > > If you try to stuff it into too few bits, e.g., BITS 4 FOR [ 0 .. 255 ], > it is a static error. > > If you try to assign a value outside the value range, it is an error, > generally at runtime, even if that value would fit in the bit count. > E.g., VAR V : BITS 16 FOR [ 0 .. 255 ] := 256 is illegal. > > The *only* thing BITS n FOR does is, if legal, affect the amount of > storage the compiler allocates, and *only for array elements and > fields of RECORDs and OBJECTs*. ... > > > >In fact, one could possibly define INTEGER to be BITS 32 FOR > >LONGINT, but that might involve further consequences in corrner > >case in the language. > > > >-- hendrik > > > >> > >> Mika > > > > -- > Rodney Bates > rodney.m.bates at acm.org From hendrik at topoi.pooq.com Thu May 28 16:21:58 2015 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Thu, 28 May 2015 10:21:58 -0400 Subject: [M3devel] 64bit INTEGERs, WIDECHAR: language specified or configuration/target dependent? In-Reply-To: <55675464.5090306@elstel.org> References: <0A1CDD8C-EEB5-40E2-A38B-28E8EEA8C37E@elstel.org> <8A3AB2ED-C11E-4787-A7F8-C8F12157EAA5@elstel.org> <555F6D8F.4070109@lcwb.coop> <6F9B9534-7DC2-4D4D-88CB-90D7FA05E8F9@elstel.org> <8BBBC94B-EECC-464A-86BB-FD1C94EC5496@elstel.org> <77605189-D966-4D4B-8946-838BD6E178AA@purdue.edu> <55675464.5090306@elstel.org> Message-ID: <20150528142158.GB19285@topoi.pooq.com> On Thu, May 28, 2015 at 07:46:12PM +0200, Elmar Stellnberger wrote: > Am 28.05.15 um 04:03 schrieb Antony Hosking: > >BYTESIZE(ADDRESS) = BYTESIZE(INTEGER) in cm3 on all target platforms. I don't really understand what you are proposing. > > > on AMD64: BITSIZE(INTEGER) = BITSIZE(LONGINT) = 64bit > > I have just noticed that and when taking a practical standpoint - > i.e. what really matters to new and old programs - > this is a really bad decision which I wish to change for the next release. > > If you have not examined it yet please reclaim the design decisions > for leaving int 32bit in C: > > /However things turned out to be very different when the extension from > 32bit to 64bit was at stake. There was no more gain by automatically > extending the value ranges from 2^32 to 2^64 for 95% of all application > purposes while the memory hierarchy has increasingly become a bottle > neck in recent time. Additionally doubling the size of all integers would > initially have doubled our memory needs which would have been a > potential drawback for introducing the AMD64 arch. Just think of a machine > with 4GB of RAM: It can not be addressed by 32bit (only ~3GB can) while > making all INTS 64bit would have shrunken our memory to an effective size > of 2GB. Luckily the decision was taken differently this time: > > * keep all ints of at most 32bit and just extend pointers to 64bit > / > > Same reasoning applies to Modula-3. - and I believe you have failed > to notice when > making your decisions for cm3 5.8.6. Or do you want to tell me that > Modula-3 > developers are more prudent than the C/C++ community? > > Even worse I have discovered the following: > BITS 8 FOR INTEGER and BITS 32 FOR INTEGER do not work with cm3 5.8.6: As I understand it from Rodney Bates' reply to my recent post, BITS 8 FOR INTEGER should never have worked. BITS 32 FOR INTEGER should work only if INTEGER is 32 bits wide. > > :: BITS FOR size too small, must be at least (64) > > That will break existing legacy code when trying to compile it with > cm3 5.8.6. From adacore at marino.st Thu May 28 21:13:44 2015 From: adacore at marino.st (John Marino) Date: Thu, 28 May 2015 21:13:44 +0200 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> Message-ID: <556768E8.10107@marino.st> On 5/28/2015 19:06, Olaf Wagner wrote: > On Thu, 28 May 2015 17:56:20 +0200 > John Marino wrote: >> If I did that approach, I could use a hint on the hashes to try... > > We should be able to script something that sets up the current compiler > at least on a given specific platform with a well-defined environment. > I might be able to offer more help in the second week of June, if you > can wait until then. I honestly don't know if I can. In general I have a zillion irons in the fire (it's taken almost 18 months to cycle back to M3) and this is not a normal summer. What I'm saying is, if it's done mid-June, it could be Christmas before I take advantage of it. Or not. One never knows. John From estellnb at elstel.org Thu May 28 21:53:33 2015 From: estellnb at elstel.org (Elmar Stellnberger) Date: Thu, 28 May 2015 21:53:33 +0200 Subject: [M3devel] 64bit INTEGERs, WIDECHAR: language specified or configuration/target dependent? In-Reply-To: <55675464.5090306@elstel.org> References: <555E14BC.2040805@lcwb.coop> <555E203E.4040203@elstel.org> <0A1CDD8C-EEB5-40E2-A38B-28E8EEA8C37E@elstel.org> <8A3AB2ED-C11E-4787-A7F8-C8F12157EAA5@elstel.org> <555F6D8F.4070109@lcwb.coop> <6F9B9534-7DC2-4D4D-88CB-90D7FA05E8F9@elstel.org> <8BBBC94B-EECC-464A-86BB-FD1C94EC5496@elstel.org> <77605189-D966-4D4B-8946-838BD6E178AA@purdue.edu> <55675464.5090306@elstel.org> Message-ID: <5567723D.3020706@elstel.org> How for the hell do you interface with operating system services requiring a 32bit int when you only have the 64bit INTEGER?? Am 28.05.15 um 19:46 schrieb Elmar Stellnberger: > Am 28.05.15 um 04:03 schrieb Antony Hosking: >> BYTESIZE(ADDRESS) = BYTESIZE(INTEGER) in cm3 on all target platforms. I don't really understand what you are proposing. >> > on AMD64: BITSIZE(INTEGER) = BITSIZE(LONGINT) = 64bit > > I have just noticed that and when taking a practical standpoint - i.e. > what really matters to new and old programs - > this is a really bad decision which I wish to change for the next release. > > If you have not examined it yet please reclaim the design decisions > for leaving int 32bit in C: > /However things turned out to be very different when the extension from > 32bit to 64bit was at stake. There was no more gain by automatically > extending the value ranges from 2^32 to 2^64 for 95% of all application > purposes while the memory hierarchy has increasingly become a bottle > neck in recent time. Additionally doubling the size of all integers would > initially have doubled our memory needs which would have been a > potential drawback for introducing the AMD64 arch. Just think of a machine > with 4GB of RAM: It can not be addressed by 32bit (only ~3GB can) while > making all INTS 64bit would have shrunken our memory to an effective size > of 2GB. Luckily the decision was taken differently this time: > > * keep all ints of at most 32bit and just extend pointers to 64bit > / > Same reasoning applies to Modula-3. - and I believe you have failed > to notice when > making your decisions for cm3 5.8.6. Or do you want to tell me that > Modula-3 > developers are more prudent than the C/C++ community? > > Even worse I have discovered the following: > BITS 8 FOR INTEGER and BITS 32 FOR INTEGER do not work with cm3 5.8.6: > > :: BITS FOR size too small, must be at least (64) > > That will break existing legacy code when trying to compile it with > cm3 5.8.6. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu May 28 22:14:49 2015 From: jay.krell at cornell.edu (Jay K) Date: Thu, 28 May 2015 20:14:49 +0000 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <55672DC1.7080509@lcwb.coop> References: <556700B0.8060500@marino.st>,<55672DC1.7080509@lcwb.coop> Message-ID: > Also, this script built the compiler before the support libraries m3core and > libm3. I think there may have been one bootstrap scenario where this was the > way it needed to be done, but usually it is the other way around--these two > libraries first. This is very deliberate and should always work, when doing a native upgrade. It is true it is not always required. When doing a "clean" cross build, it is true that it is backwards. It is required when upgrading from an older build. Native upgrades start at least with a working compiler and its matching runtime. Cross builds start with a working host compiler and nothing for the target -- so they do start with m3core. The idea that people don't get right away is that the compiler and runtime are very coupled. A compiler targets a particular runtime. Its output requires a certain runtime. Look at RT0.i3 in particular. We haven't changed that in over 10 years, but Critical Mass did. For example. Or if you change the size of WIDECHAR. The compiler outputs data that the garbage collector uses. The compiler outputs function calls that are to functions in m3core. The coupling to libm3 is less clear to me, but the coupling to m3core is significant. m3core is kind of the lowest level runtime that compiler pretty much unavoidably requires to be with its output. Perhaps if you write code w/o any traced types and without try/finally or raise, you can avoid m3core. But there is still module initialization and running "main". So m3core is unavoidable. In the Unix world, consider like crtstart.o. In the Windows world, consider that main is called from mainCRTStartup and this is like wherever that is. (Or DllMain is called from DllMainCRTSTartup, WinMain is called from WinMainCRTStartup, etc. There is an analog between DllMain and the entry points of each module other than Main.) libm3 is more a convenience library that you can maybe possibly do without. Consider this, like, not the startup code, but stdio, stdlib, STL, etc. Another dependency people don't understand is between the frontend and the backend. The gcc backend in particular. When you change the "M3CG", the persisted IR, these two have to be updated together. Again, these things don't change much, so we get away without worrying about and without automating it and without people understanding it. We changed this, for example, when the atomics were added. I think I made changes too. I believe I automated this, but then wimped out and commented out one line. I'll report back later on this. I didn't want to diverge from the shell scripts, perhaps. I'll try to find some time here. I agree an upgrade from 5.8.6 to current is desirable. I go back and forth on this. I have likely broken it, and fixed it. For example, the mklib dependency on the Win32 headers. That should be ok now. For another potential example, the frontend can't use LONGINT until a release has it. But I think we have that now. We do not support going arbitrarily back, but the previous release is a good target. I have at times gone further back and fixed things up. You can also bootstrap via the cross mechanism even if you aren't crossing, but I suppose that is too difficult. Here: https://github.com/modula3/cm3/blob/master/scripts/python/upgrade.py 51 # 52 # ... and continue with the backend, if needed 53 # 54 55 a = Root + "/m3-sys/m3cggen/" + Target + "/m3cggen > " + Root + "/m3-sys/m3cc/gcc/gcc/m3cg/m3cg.h" 56 print(a) 57 # os.system(a) 58 FilterPackages([ "m3cc" ]) and DoPackage(argv_BuildShip, [ "m3cc" ]) uncomment out line 57. That is where I wimped out. That line should be there. Hopefully it is still correct.It is a little gross in that it outputs into the source tree.This really shouldn't be needed if you build correctly from a consistent checkout. It is only for when you have local edits.Even bootstrap/upgrade should not require it. The output should just match what is already there. And another thing: When I wrote upgrade.py, I thought I was mimicking upgrade.sh, and I mostly was. One thing I missed though was that upgrade.sh does actually build the entire system, whereas upgrade.py only builds the compiler. So consider this, somewhat overkill instead: cd scripts ./upgrade.py && ./do-cm3-all.py realclean skipgcc && ./do-cm3-all buildship skipgcc Also note that in-place updates are done while it goes. Certain errors force a need to go backwards. So you should maintain a backup of the minimum -- cm3, cm3.cfg, config directory, m3core, libm3, cm3cg. Or be able to restore from a release. That list is important, so I'll repeat: cm3, cm3.cfg, config directory in newer releases (cm3.cfg delegages to it), m3core, libm3, cm3cg (optional). To put this another way: consider the compiler itself to be a very portable and minimalist Modula-3 program. It has few dependencies and does most things itself. Consider the C program that just uses very little of the standard library but does use printf("main"). What do you need to build such things? You don't need, you know, a marshaling library, a windowing library etc., but you need a working compiler, frontend, backend, assembler, linker, and a minimal library That is what is required to a native upgrade. - Jay > Date: Thu, 28 May 2015 10:01:21 -0500 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > > > On 05/28/2015 06:49 AM, John Marino wrote: > > I got stuck again trying to build the latest on FreeBSD. > > > > 1. tar extracted to working directory along with a bootstrap compiler > > 2. CM3 and CM3_INSTALL defined in environment > > 3. executed scripts/python/upgrade.py > > > > result: > > http://leaf.dragonflybsd.org/~marino/m3.log > > > > I could guess that something is picking up a bootstrap component instead > > of a newly built one. > > Yes. > > >> m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > > means it is trying to compile using a new cm3cg backend and an old cm3 front end. > I just added this error message after Olaf had this problem. (Otherwise it would > have failed anyway, but with a less informative message.) > > > I guess it's trying to build the c backend? > > > > It finished the C backend and was trying to build m3core, using the inconsistent > compiler. Usually, neither cm3 nor cm3cg is copied to the bin directory, > even when doing a ship, in order to avoid this, which is an exception. For all > other executables, ship copies them to the bin directory. The shell script > scripts/install-cm3-compiler.sh is then run manually, after both cm3 and cm3cg > are compiled, to copy them to bin atomically (sort of). > > I don't know why that happened. I don't have experience with the Python scripts. > > Jay? > > Also, this script built the compiler before the support libraries m3core and > libm3. I think there may have been one bootstrap scenario where this was the > way it needed to be done, but usually it is the other way around--these two > libraries first. > > > > Am I doing some kind of obvious mistake? > > > > No, it's a bootstrap barrier. These pop up somewhat regularly. We all usually > just build from the most recent development build, which works for getting new > things tried out initially. But we need to make a habit of regularly rebuilding > from the previous release to flush these out. > > You might try scripts/do-cm3-front.sh realclean > scripts/do-cm3-front.sh buildship > > (I usually save /usr/local/cm3/bin/cm3 and /usr/local/cm3/bin/cm3cg at this point. > The step below does it somewhat redundantly, but only one level, unless the > version number changes.) > > scripts/install-cm3-compiler.sh upgrade. > > From here, you are using the new compiler. > > scripts/do-cm3-.sh buildship > > That this works, starting with the previous release compiler, is my criterion > for having removed bootstrap barriers. > > > > > John > > > > -- > Rodney Bates > rodney.m.bates at acm.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu May 28 22:13:24 2015 From: jay.krell at cornell.edu (Jay K) Date: Thu, 28 May 2015 20:13:24 +0000 Subject: [M3devel] 64bit INTEGERs, WIDECHAR: language specified or configuration/target dependent? In-Reply-To: <5567723D.3020706@elstel.org> References: <555E14BC.2040805@lcwb.coop> <555E203E.4040203@elstel.org>, , , <0A1CDD8C-EEB5-40E2-A38B-28E8EEA8C37E@elstel.org>, , <8A3AB2ED-C11E-4787-A7F8-C8F12157EAA5@elstel.org>, <555F6D8F.4070109@lcwb.coop>, <6F9B9534-7DC2-4D4D-88CB-90D7FA05E8F9@elstel.org>, <8BBBC94B-EECC-464A-86BB-FD1C94EC5496@elstel.org>, <77605189-D966-4D4B-8946-838BD6E178AA@purdue.edu>, <55675464.5090306@elstel.org>, <5567723D.3020706@elstel.org> Message-ID: 1) Ctypes.int 2) I wrapped everything anyway because the rewriting of /usr/include in m3core/unix was terribly tedious and error prone and a frequent source of problems.I favor size_t/INTEGER. The "direct" calls were not worth the trouble. I've debugged enough stack corruptions due to getting struct stat wrong there. 3) But not always, the Win32 and X windows stuff is still direct. INTEGER is not the only integer type, it is just kinda the default easiest to use if you must use one, use it.If you want to think more about it, there are more options. The 8 underlying types are all in there -- 8/16/32/64 unsigned and signed.Perhaps they should be exposes differently, like as INT8, UINT8, INT16, UINT16, INT32, UINT32, INT64, UINT64?Or int8_t, uint8_t, int16_t, uint16_t, etc.? Those types are all available to all programs, albeit in the WinNT and cstdint modules I believe. Not "global" like INTEGER. - Jay Date: Thu, 28 May 2015 21:53:33 +0200 From: estellnb at elstel.org To: hosking at purdue.edu CC: m3devel at elegosoft.com; jay.krell at cornell.edu; rodney.m.bates at acm.org Subject: Re: [M3devel] 64bit INTEGERs, WIDECHAR: language specified or configuration/target dependent? How for the hell do you interface with operating system services requiring a 32bit int when you only have the 64bit INTEGER?? Am 28.05.15 um 19:46 schrieb Elmar Stellnberger: Am 28.05.15 um 04:03 schrieb Antony Hosking: BYTESIZE(ADDRESS) = BYTESIZE(INTEGER) in cm3 on all target platforms. I don't really understand what you are proposing. on AMD64: BITSIZE(INTEGER) = BITSIZE(LONGINT) = 64bit I have just noticed that and when taking a practical standpoint - i.e. what really matters to new and old programs - this is a really bad decision which I wish to change for the next release. If you have not examined it yet please reclaim the design decisions for leaving int 32bit in C: However things turned out to be very different when the extension from 32bit to 64bit was at stake. There was no more gain by automatically extending the value ranges from 2^32 to 2^64 for 95% of all application purposes while the memory hierarchy has increasingly become a bottle neck in recent time. Additionally doubling the size of all integers would initially have doubled our memory needs which would have been a potential drawback for introducing the AMD64 arch. Just think of a machine with 4GB of RAM: It can not be addressed by 32bit (only ~3GB can) while making all INTS 64bit would have shrunken our memory to an effective size of 2GB. Luckily the decision was taken differently this time: * keep all ints of at most 32bit and just extend pointers to 64bit Same reasoning applies to Modula-3. - and I believe you have failed to notice when making your decisions for cm3 5.8.6. Or do you want to tell me that Modula-3 developers are more prudent than the C/C++ community? Even worse I have discovered the following: BITS 8 FOR INTEGER and BITS 32 FOR INTEGER do not work with cm3 5.8.6: :: BITS FOR size too small, must be at least (64) That will break existing legacy code when trying to compile it with cm3 5.8.6. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu May 28 22:29:44 2015 From: jay.krell at cornell.edu (Jay K) Date: Thu, 28 May 2015 20:29:44 +0000 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <55673AA4.8050100@marino.st> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop>,<55673AA4.8050100@marino.st> Message-ID: The build order in upgrade.py is correct. Since it is deliberately starting with whatever cm3 the user already has,it must also start deliberately with whatever m3core and libm3 the user already has.They go together. It builds a cm3 that uses the old m3core/libm3 (statically linked),and then rebuilds everything with itself, starting from m3core."everything" being only up to cm3/mklib, not the gui stuff, for example. Really in the past I've used this stuff a lot and I use the unedited checked in copy.There could be a problem building from the latest release, and that we should fix.The problem will likely be in m3front/m3back/m3link/m3quake, etc. The scripts should already be ok. The in-place nature of upgrade.py is perhaps not ideal. Esp. when it doesn't work.make-dist.py may be preferable. - Jay > Date: Thu, 28 May 2015 17:56:20 +0200 > From: adacore at marino.st > To: rodney.m.bates at acm.org; m3devel at elegosoft.com > Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > > On 5/28/2015 17:01, Rodney M. Bates wrote: > > I don't know why that happened. I don't have experience with the > > Python scripts. > > > > Jay? > > > > Also, this script built the compiler before the support libraries > > m3core and libm3. I think there may have been one bootstrap scenario > > where this was the way it needed to be done, but usually it is the > > other way around--these two libraries first. > > > >> Am I doing some kind of obvious mistake? > >> > > No, it's a bootstrap barrier. These pop up somewhat regularly. We > > all usually just build from the most recent development build, which > > works for getting new things tried out initially. But we need to > > make a habit of regularly rebuilding from the previous release to > > flush these out. > > Olaf said, IIUC, that the current code can't be built by the last > release compiler. Putting aside that I believe that should be a hard > requirement for the project, it sounds like maybe the last release can > build it if the build order is fixed (e.g. a better upgrade.py script)? > It's not clear to me what the real situation is. > > > > You might try scripts/do-cm3-front.sh realclean > > scripts/do-cm3-front.sh buildship > > > > (I usually save /usr/local/cm3/bin/cm3 and /usr/local/cm3/bin/cm3cg > > at this point. The step below does it somewhat redundantly, but only > > one level, unless the version number changes.) > > > > scripts/install-cm3-compiler.sh upgrade. > > From here, you are using the new compiler. > > scripts/do-cm3-.sh buildship > > > > That this works, starting with the previous release compiler, is my > > criterion for having removed bootstrap barriers. > > My work takes place within a Makefile and moving things in /usr/local > (for example) is actually illegal. Now I could do all this manually for > the purpose of building a new bootstrap, but as I mentioned in a > previous post, it might be more effective to emulate what you guy have > done: essentially build a series of bootstraps at strategic hashes until > I've acquired a compiler that can build this (and then use that product > as bootstrap for FreeBSD ports). > > If I did that approach, I could use a hint on the hashes to try... > > John -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu May 28 22:24:14 2015 From: jay.krell at cornell.edu (Jay K) Date: Thu, 28 May 2015 20:24:14 +0000 Subject: [M3devel] Too many names for the gcc backend. Was: m3cgc1: fatal error ... In-Reply-To: <55673174.80804@lcwb.coop> References: <556700B0.8060500@marino.st>,<55673174.80804@lcwb.coop> Message-ID: "1" is because gcc is structured as having the gcc "driver" and "frontends" like cc1 and cc1plus.cm3cg is a frontend from the gcc point of view. So it has/had a "1" in iis name.I believe we rename from m3cgc1 to cm3cg.The gcc backends are always linked into the frontends anyway -- libbackend.a.If this wasn't the case, they'd probably be called things like cc2. With Visual C++, for example, the "driver" is cl.exe and the frontends are c1.dll and c1xx.dll and the backend is c2.dll.Most compilers are structured in about the same way. Your .log: --- building in AMD64_FREEBSD --- ignoring ../src/m3overrides new source -> compiling RTHooks.i3 m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 compilation terminated. m3_backend => 1 > cp -Pv /mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a/m3-sys/cminstall/src/config-no-install/ALPHA32_VMS /mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a/bin/config/ALPHA32_VMS I think the problem is that upgrade wants to do things in-place, but you have asked to ship/install to a new place.It kind of does install while it builds. make-dist.py kinda does this better. It builds into a new place, but first copies from the old. Can you do that? Or, similarly, if you are building into a new empty place, can you add it to the start of $PATH, so as it fills in, it will take precedence? I understand this is all not ideal. The default method of "ugprade.py" building should be more like make-dist. The result should be a directory or .tar.gz that the user is told to copy or extract. No in-place updates ought to be done. make-dist.py is really better. Or, can you try make-dist.py?? Maybe if people use that a bit, we can delete upgrade and just point people at make-dist.py instead.It does "min" and "all". - Jay > Date: Thu, 28 May 2015 10:17:08 -0500 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: [M3devel] Too many names for the gcc backend. Was: m3cgc1: fatal error ... > > BTW, the gcc-derived back end has too many names. > > m3cc: The package name > m3cg: The directory containing glue code to gcc > m3cgc1: The executable built inside m3cc. > Also, what it identifies itself as in error messages > cm3cg: The executable, when installed in /usr/local/cm3/bin > > Did I even get it complete or right? > > On 05/28/2015 06:49 AM, John Marino wrote: > > I got stuck again trying to build the latest on FreeBSD. > > > > 1. tar extracted to working directory along with a bootstrap compiler > > 2. CM3 and CM3_INSTALL defined in environment > > 3. executed scripts/python/upgrade.py > > > > result: > > http://leaf.dragonflybsd.org/~marino/m3.log > > > > I could guess that something is picking up a bootstrap component instead > > of a newly built one. I guess it's trying to build the c backend? > > > > Am I doing some kind of obvious mistake? > > > > John > > > > -- > Rodney Bates > rodney.m.bates at acm.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Thu May 28 23:05:54 2015 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 28 May 2015 23:05:54 +0200 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> Message-ID: <20150528230554.80920c53f002da8beb3f29d0@elegosoft.com> On Thu, 28 May 2015 20:14:49 +0000 Jay K wrote: > > Also, this script built the compiler before the support libraries m3core and > > libm3. I think there may have been one bootstrap scenario where this was the > > way it needed to be done, but usually it is the other way around--these two > > libraries first. > > This is very deliberate and should always work, when doing a native upgrade. > It is true it is not always required. > When doing a "clean" cross build, it is true that it is backwards. > It is required when upgrading from an older build. > > Native upgrades start at least with a working compiler and its matching runtime. > Cross builds start with a working host compiler and nothing for the target -- so they do start with m3core. I've had a look at the build log, and I think the problem in this case with upgrade.py might be that it doesn't install the new backend, but only the new frontend: [...] Not shipping cm3cg. --- shipping from AMD64_FREEBSD --- missing ".M3SHIP" file, build the package first. dula3/work/bootstrap/bin/cm3 -build -DROOT=/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a +++ ==> /mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a/m3-sys/m3cc done +++ /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin/cm3 -ship -DROOT=/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a +++ ==> /mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a/m3-sys/m3cc done mkdir -p /mech/construction/mech/ptrees/default/lang/modula3/work/stage/usr/local/bin cp -Pv /mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a/m3-sys/cm3/AMD64_FREEBSD/cm3 /mech/construction/mech/ptrees/default/lang/modula3/work/stage/usr/local/bin/cm3 [...] In the upgrade.sh script I used install-cm3-compiler.sh, which always installs both. In m3-sys/m3cc/src/m3makefile I find the following code: if equal($INSTALL_CM3_IN_BIN, "yes") deriveds("", ["cm3cg", "cm3cg.exe"]) write ( "Forced ship of cm3cg." & CR) BindExport (AppendExeExtension ("cm3cg")) if DoMipsTfile BindExport ("mips-tfile") end else write ( "Not shipping cm3cg." & CR) end So perhaps simply setting INSTALL_CM3_IN_BIN=yes in the environment will fix that problem? Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From rodney_bates at lcwb.coop Thu May 28 23:56:06 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 28 May 2015 16:56:06 -0500 Subject: [M3devel] 64bit INTEGERs, WIDECHAR: language specified or configuration/target dependent? In-Reply-To: <20150528142158.GB19285@topoi.pooq.com> References: <0A1CDD8C-EEB5-40E2-A38B-28E8EEA8C37E@elstel.org> <8A3AB2ED-C11E-4787-A7F8-C8F12157EAA5@elstel.org> <555F6D8F.4070109@lcwb.coop> <6F9B9534-7DC2-4D4D-88CB-90D7FA05E8F9@elstel.org> <8BBBC94B-EECC-464A-86BB-FD1C94EC5496@elstel.org> <77605189-D966-4D4B-8946-838BD6E178AA@purdue.edu> <55675464.5090306@elstel.org> <20150528142158.GB19285@topoi.pooq.com> Message-ID: <55678EF6.4010108@lcwb.coop> On 05/28/2015 09:21 AM, Hendrik Boom wrote: > On Thu, May 28, 2015 at 07:46:12PM +0200, Elmar Stellnberger wrote: >> Am 28.05.15 um 04:03 schrieb Antony Hosking: >>> BYTESIZE(ADDRESS) = BYTESIZE(INTEGER) in cm3 on all target platforms. I don't really understand what you are proposing. >>> >> on AMD64: BITSIZE(INTEGER) = BITSIZE(LONGINT) = 64bit >> >> I have just noticed that and when taking a practical standpoint - >> i.e. what really matters to new and old programs - >> this is a really bad decision which I wish to change for the next release. >> >> If you have not examined it yet please reclaim the design decisions >> for leaving int 32bit in C: >> >> /However things turned out to be very different when the extension from >> 32bit to 64bit was at stake. There was no more gain by automatically >> extending the value ranges from 2^32 to 2^64 for 95% of all application >> purposes while the memory hierarchy has increasingly become a bottle >> neck in recent time. Additionally doubling the size of all integers would >> initially have doubled our memory needs which would have been a >> potential drawback for introducing the AMD64 arch. Just think of a machine >> with 4GB of RAM: It can not be addressed by 32bit (only ~3GB can) while >> making all INTS 64bit would have shrunken our memory to an effective size >> of 2GB. Luckily the decision was taken differently this time: >> >> * keep all ints of at most 32bit and just extend pointers to 64bit >> / >> >> Same reasoning applies to Modula-3. - and I believe you have failed >> to notice when >> making your decisions for cm3 5.8.6. Or do you want to tell me that >> Modula-3 >> developers are more prudent than the C/C++ community? >> >> Even worse I have discovered the following: >> BITS 8 FOR INTEGER and BITS 32 FOR INTEGER do not work with cm3 5.8.6: > > As I understand it from Rodney Bates' reply to my recent post, > BITS 8 FOR INTEGER should never have worked. BITS 32 FOR INTEGER > should work only if INTEGER is 32 bits wide. > Yes. >> >> :: BITS FOR size too small, must be at least (64) >> >> That will break existing legacy code when trying to compile it with >> cm3 5.8.6. > -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Fri May 29 00:15:35 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 28 May 2015 17:15:35 -0500 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> Message-ID: <55679387.8040701@lcwb.coop> On 05/28/2015 12:06 PM, Olaf Wagner wrote: > On Thu, 28 May 2015 17:56:20 +0200 > John Marino wrote: > >> On 5/28/2015 17:01, Rodney M. Bates wrote: >>> I don't know why that happened. I don't have experience with the >>> Python scripts. >>> >>> Jay? >>> >>> Also, this script built the compiler before the support libraries >>> m3core and libm3. I think there may have been one bootstrap scenario >>> where this was the way it needed to be done, but usually it is the >>> other way around--these two libraries first. >>> >>>> Am I doing some kind of obvious mistake? >>>> >>> No, it's a bootstrap barrier. These pop up somewhat regularly. We >>> all usually just build from the most recent development build, which >>> works for getting new things tried out initially. But we need to >>> make a habit of regularly rebuilding from the previous release to >>> flush these out. >> >> Olaf said, IIUC, that the current code can't be built by the last >> release compiler. Putting aside that I believe that should be a hard >> requirement for the project, it sounds like maybe the last release can >> build it if the build order is fixed (e.g. a better upgrade.py script)? >> It's not clear to me what the real situation is. > > No, this is a misunderstanding. I just said or tried to say that there > is no script (yet) that is smart enough to do all the things necessary to > build the current compiler on base of 5.8.6. > >>> You might try scripts/do-cm3-front.sh realclean >>> scripts/do-cm3-front.sh buildship >>> >>> (I usually save /usr/local/cm3/bin/cm3 and /usr/local/cm3/bin/cm3cg >>> at this point. The step below does it somewhat redundantly, but only >>> one level, unless the version number changes.) >>> >>> scripts/install-cm3-compiler.sh upgrade. >>> From here, you are using the new compiler. >>> scripts/do-cm3-.sh buildship >>> >>> That this works, starting with the previous release compiler, is my >>> criterion for having removed bootstrap barriers. > > Rodney, have you really tried that? I'm not sure the steps above will > work. I had the feeling that we're missing some intermediate releases, but > I might be wrong there. > I have done it a number of times for AMD64_LINUX and LINUXLIBC6, using the last release compiler, and successfully building a development compiler, for several different development snapshots. The last time was probably a few months ago, and I don't think much has happened in the compiler and library packages that would make them not compile. It will take a me a little time, but I will try it again on these platforms. >> My work takes place within a Makefile and moving things in /usr/local >> (for example) is actually illegal. Now I could do all this manually for >> the purpose of building a new bootstrap, but as I mentioned in a >> previous post, it might be more effective to emulate what you guy have >> done: essentially build a series of bootstraps at strategic hashes until >> I've acquired a compiler that can build this (and then use that product >> as bootstrap for FreeBSD ports). >> >> If I did that approach, I could use a hint on the hashes to try... > > We should be able to script something that sets up the current compiler > at least on a given specific platform with a well-defined environment. > I might be able to offer more help in the second week of June, if you > can wait until then. > > Olaf > -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Fri May 29 00:17:48 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 28 May 2015 17:17:48 -0500 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <55673AA4.8050100@marino.st> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> Message-ID: <5567940C.6080409@lcwb.coop> On 05/28/2015 10:56 AM, John Marino wrote: > On 5/28/2015 17:01, Rodney M. Bates wrote: >> I don't know why that happened. I don't have experience with the >> Python scripts. >> >> Jay? >> >> Also, this script built the compiler before the support libraries >> m3core and libm3. I think there may have been one bootstrap scenario >> where this was the way it needed to be done, but usually it is the >> other way around--these two libraries first. >> >>> Am I doing some kind of obvious mistake? >>> >> No, it's a bootstrap barrier. These pop up somewhat regularly. We >> all usually just build from the most recent development build, which >> works for getting new things tried out initially. But we need to >> make a habit of regularly rebuilding from the previous release to >> flush these out. > > Olaf said, IIUC, that the current code can't be built by the last > release compiler. Putting aside that I believe that should be a hard > requirement for the project, it sounds like maybe the last release can > build it if the build order is fixed (e.g. a better upgrade.py script)? > It's not clear to me what the real situation is. > > >> You might try scripts/do-cm3-front.sh realclean >> scripts/do-cm3-front.sh buildship >> >> (I usually save /usr/local/cm3/bin/cm3 and /usr/local/cm3/bin/cm3cg >> at this point. The step below does it somewhat redundantly, but only >> one level, unless the version number changes.) >> >> scripts/install-cm3-compiler.sh upgrade. >> From here, you are using the new compiler. >> scripts/do-cm3-.sh buildship >> >> That this works, starting with the previous release compiler, is my >> criterion for having removed bootstrap barriers. > > My work takes place within a Makefile and moving things in /usr/local > (for example) is actually illegal. Now I could do all this manually for > the purpose of building a new bootstrap, but as I mentioned in a > previous post, it might be more effective to emulate what you guy have > done: essentially build a series of bootstraps at strategic hashes until > I've acquired a compiler that can build this (and then use that product > as bootstrap for FreeBSD ports). I don't think that will be necessary. Give me a few days. > > If I did that approach, I could use a hint on the hashes to try... > > John > -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Fri May 29 00:25:19 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 28 May 2015 17:25:19 -0500 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <556722B3.7080209@marino.st> References: <556700B0.8060500@marino.st> <20150528160221.95d4c26d83f68f8cfa93d75a@elego.de> <556722B3.7080209@marino.st> Message-ID: <556795CF.7090409@lcwb.coop> On 05/28/2015 09:14 AM, John Marino wrote: > On 5/28/2015 16:02, Olaf Wagner wrote: >> On Thu, 28 May 2015 13:49:04 +0200 >> John Marino wrote: >>> Am I doing some kind of obvious mistake? >> >> No. I think upgrade.sh (or .py) cannot really cope with updating a 5.8.6 >> instance to the current state. It took me several days, too, on >> MacOS X, and I had to do a lot of manual tweaking and copying >> around. I don't think any casual user will understand the details > > That's a pretty big sin given how 5.8.6 is the current release! > I am in adamant agreement with you here. I periodically interrupt things to go back and prove I can build the development version from the last release. In the process, I have discovered and fixed several bootstrap barriers in the past. I really think it is a build process problem. > >> IMO the best thing we can do now is provide some more up-to-date >> binary archives (I'll upload my own stuff as soon as I find the time). >> A newer release has been missing for several years, and the existing >> scripts are no great help for new users. > > Is there a git tag that can build from 5.8.6? Maybe I just have to keep > doing this until I get a new bootstrap that can do it. > > John > -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Fri May 29 00:54:32 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 28 May 2015 17:54:32 -0500 Subject: [M3devel] 64bit INTEGERs, WIDECHAR: language specified or configuration/target dependent? In-Reply-To: <5567723D.3020706@elstel.org> References: <555E14BC.2040805@lcwb.coop> <555E203E.4040203@elstel.org> <0A1CDD8C-EEB5-40E2-A38B-28E8EEA8C37E@elstel.org> <8A3AB2ED-C11E-4787-A7F8-C8F12157EAA5@elstel.org> <555F6D8F.4070109@lcwb.coop> <6F9B9534-7DC2-4D4D-88CB-90D7FA05E8F9@elstel.org> <8BBBC94B-EECC-464A-86BB-FD1C94EC5496@elstel.org> <77605189-D966-4D4B-8946-838BD6E178AA@purdue.edu> <55675464.5090306@elstel.org> <5567723D.3020706@elstel.org> Message-ID: <55679CA8.2030905@lcwb.coop> On 05/28/2015 02:53 PM, Elmar Stellnberger wrote: > > How for the hell do you interface with operating system services requiring a 32bit int when you only have the 64bit INTEGER?? > Use subranges. Just declare its type [-16_7fffffff-1 .. 16_7fffffff]. Our compiler will allocate nice round bit sizes for everything that isn't BITS n FOR ... . And if it is BITS ..., just use the same subrange type, as above, then use BITS 32 FOR ... . But remember BITS has no effect except when it's an array element or record/object field. It's the subrange, not the BITS spec that determines the range. The language reference doesn't constrain the allocated size, but I'm skeptical about adding things like that to the language. Interfacing with another language is low-level programming, and specifying all the things in that category would be huge and overconstrain the language. Well, maybe not stack variables, if the stack has a bigger alignment to be honored, quite possibly a hardware requirement. No doubt taking and using the address of such would be endian-dependent. Would a C compiler do differently in this case? Can you rely on them all doing it the same? Does C specify it? > Am 28.05.15 um 19:46 schrieb Elmar Stellnberger: >> Am 28.05.15 um 04:03 schrieb Antony Hosking: >>> BYTESIZE(ADDRESS) = BYTESIZE(INTEGER) in cm3 on all target platforms. I don't really understand what you are proposing. >>> >> on AMD64: BITSIZE(INTEGER) = BITSIZE(LONGINT) = 64bit >> >> I have just noticed that and when taking a practical standpoint - i.e. what really matters to new and old programs - >> this is a really bad decision which I wish to change for the next release. >> >> If you have not examined it yet please reclaim the design decisions for leaving int 32bit in C: >> /However things turned out to be very different when the extension from >> 32bit to 64bit was at stake. There was no more gain by automatically >> extending the value ranges from 2^32 to 2^64 for 95% of all application >> purposes while the memory hierarchy has increasingly become a bottle >> neck in recent time. Additionally doubling the size of all integers would >> initially have doubled our memory needs which would have been a >> potential drawback for introducing the AMD64 arch. Just think of a machine >> with 4GB of RAM: It can not be addressed by 32bit (only ~3GB can) while >> making all INTS 64bit would have shrunken our memory to an effective size >> of 2GB. Luckily the decision was taken differently this time: >> >> * keep all ints of at most 32bit and just extend pointers to 64bit >> / >> Same reasoning applies to Modula-3. - and I believe you have failed to notice when >> making your decisions for cm3 5.8.6. Or do you want to tell me that Modula-3 >> developers are more prudent than the C/C++ community? >> >> Even worse I have discovered the following: >> BITS 8 FOR INTEGER and BITS 32 FOR INTEGER do not work with cm3 5.8.6: >> >> :: BITS FOR size too small, must be at least (64) >> >> That will break existing legacy code when trying to compile it with cm3 5.8.6. > -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Fri May 29 05:18:36 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 28 May 2015 22:18:36 -0500 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <55679387.8040701@lcwb.coop> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> Message-ID: <5567DA8C.3050802@lcwb.coop> On 05/28/2015 05:15 PM, Rodney M. Bates wrote: > > > On 05/28/2015 12:06 PM, Olaf Wagner wrote: >> On Thu, 28 May 2015 17:56:20 +0200 >> John Marino wrote: >> >>> On 5/28/2015 17:01, Rodney M. Bates wrote: >>>> I don't know why that happened. I don't have experience with the >>>> Python scripts. >>>> >>>> Jay? >>>> >>>> Also, this script built the compiler before the support libraries >>>> m3core and libm3. I think there may have been one bootstrap scenario >>>> where this was the way it needed to be done, but usually it is the >>>> other way around--these two libraries first. >>>> >>>>> Am I doing some kind of obvious mistake? >>>>> >>>> No, it's a bootstrap barrier. These pop up somewhat regularly. We >>>> all usually just build from the most recent development build, which >>>> works for getting new things tried out initially. But we need to >>>> make a habit of regularly rebuilding from the previous release to >>>> flush these out. >>> >>> Olaf said, IIUC, that the current code can't be built by the last >>> release compiler. Putting aside that I believe that should be a hard >>> requirement for the project, it sounds like maybe the last release can >>> build it if the build order is fixed (e.g. a better upgrade.py script)? >>> It's not clear to me what the real situation is. >> >> No, this is a misunderstanding. I just said or tried to say that there >> is no script (yet) that is smart enough to do all the things necessary to >> build the current compiler on base of 5.8.6. >> >>>> You might try scripts/do-cm3-front.sh realclean >>>> scripts/do-cm3-front.sh buildship >>>> >>>> (I usually save /usr/local/cm3/bin/cm3 and /usr/local/cm3/bin/cm3cg >>>> at this point. The step below does it somewhat redundantly, but only >>>> one level, unless the version number changes.) >>>> >>>> scripts/install-cm3-compiler.sh upgrade. >>>> From here, you are using the new compiler. >>>> scripts/do-cm3-.sh buildship >>>> >>>> That this works, starting with the previous release compiler, is my >>>> criterion for having removed bootstrap barriers. >> >> Rodney, have you really tried that? I'm not sure the steps above will >> work. I had the feeling that we're missing some intermediate releases, but >> I might be wrong there. >> > > I have done it a number of times for AMD64_LINUX and LINUXLIBC6, using the > last release compiler, and successfully building a development compiler, > for several different development snapshots. The last time was probably > a few months ago, and I don't think much has happened in the compiler > and library packages that would make them not compile. It will take a > me a little time, but I will try it again on these platforms. > OK, this is working for me on LINUXLIBC6. With the release compiler installed: $ cm3 -version Critical Mass Modula-3 version 5.8.6 last updated: 2010-04-11 compiled: 2013-09-13 21:38:06 configuration: /usr/local/cm3/bin/cm3.cfg host: AMD64_LINUX target: AMD64_LINUX And a freshly pulled git repository from github, in cm3/scripts: 1) $ ./do-cm3-all.sh realclean #Clean everything 2) $ ./do-cm3-front.sh buildship #Build a compiler & its support libraries All compiles succeeded. 4) $ ./install-cm3-compiler.sh upgrade # Install the compiler $ cm3 -version Critical Mass Modula-3 version d5.10.0 last updated: 2015-05-21 compiled: 2015-05-29 02:54:41 configuration: /usr/local/cm3/bin/cm3.cfg host: AMD64_LINUX target: AMD64_LINUX Now repeat steps 1 and 2. This will use the newly compiled head compiler. to rebuild itself. All compiles succeeded. Finally, $./do-cm3-all.sh buildship #Build the rest. This compiles all the remaining stuff, none of which is involved in bootstrapping. All compiles succeeded. In the past, I often will install the second-time-compiled head compiler and do it all a third time. After getting this far, this has never failed, and I didn't do it this time. New package libunicode uses an addition to Compiler.i3 that is not in the release, so you have to install the new compiler before compiling libunicode. >>> My work takes place within a Makefile and moving things in /usr/local >>> (for example) is actually illegal. Now I could do all this manually for >>> the purpose of building a new bootstrap, but as I mentioned in a >>> previous post, it might be more effective to emulate what you guy have >>> done: essentially build a series of bootstraps at strategic hashes until >>> I've acquired a compiler that can build this (and then use that product >>> as bootstrap for FreeBSD ports). >>> >>> If I did that approach, I could use a hint on the hashes to try... >> >> We should be able to script something that sets up the current compiler >> at least on a given specific platform with a well-defined environment. >> I might be able to offer more help in the second week of June, if you >> can wait until then. >> >> Olaf >> > -- Rodney Bates rodney.m.bates at acm.org From wagner at elegosoft.com Fri May 29 08:57:50 2015 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 29 May 2015 08:57:50 +0200 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <5567DA8C.3050802@lcwb.coop> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop> Message-ID: <20150529085750.0a8f9e2c62f01c2a0d1be4ca@elegosoft.com> On Thu, 28 May 2015 22:18:36 -0500 "Rodney M. Bates" wrote: > On 05/28/2015 05:15 PM, Rodney M. Bates wrote: > > > > On 05/28/2015 12:06 PM, Olaf Wagner wrote: > >> On Thu, 28 May 2015 17:56:20 +0200 > >> John Marino wrote: > >> > >>> On 5/28/2015 17:01, Rodney M. Bates wrote: > >>>> I don't know why that happened. I don't have experience with the > >>>> Python scripts. > >>>> > >>>> Jay? > >>>> > >>>> Also, this script built the compiler before the support libraries > >>>> m3core and libm3. I think there may have been one bootstrap scenario > >>>> where this was the way it needed to be done, but usually it is the > >>>> other way around--these two libraries first. > >>>> > >>>>> Am I doing some kind of obvious mistake? > >>>>> > >>>> No, it's a bootstrap barrier. These pop up somewhat regularly. We > >>>> all usually just build from the most recent development build, which > >>>> works for getting new things tried out initially. But we need to > >>>> make a habit of regularly rebuilding from the previous release to > >>>> flush these out. > >>> > >>> Olaf said, IIUC, that the current code can't be built by the last > >>> release compiler. Putting aside that I believe that should be a hard > >>> requirement for the project, it sounds like maybe the last release can > >>> build it if the build order is fixed (e.g. a better upgrade.py script)? > >>> It's not clear to me what the real situation is. > >> > >> No, this is a misunderstanding. I just said or tried to say that there > >> is no script (yet) that is smart enough to do all the things necessary to > >> build the current compiler on base of 5.8.6. > >> > >>>> You might try scripts/do-cm3-front.sh realclean > >>>> scripts/do-cm3-front.sh buildship > >>>> > >>>> (I usually save /usr/local/cm3/bin/cm3 and /usr/local/cm3/bin/cm3cg > >>>> at this point. The step below does it somewhat redundantly, but only > >>>> one level, unless the version number changes.) > >>>> > >>>> scripts/install-cm3-compiler.sh upgrade. > >>>> From here, you are using the new compiler. > >>>> scripts/do-cm3-.sh buildship > >>>> > >>>> That this works, starting with the previous release compiler, is my > >>>> criterion for having removed bootstrap barriers. > >> > >> Rodney, have you really tried that? I'm not sure the steps above will > >> work. I had the feeling that we're missing some intermediate releases, but > >> I might be wrong there. > >> > > > > I have done it a number of times for AMD64_LINUX and LINUXLIBC6, using the > > last release compiler, and successfully building a development compiler, > > for several different development snapshots. The last time was probably > > a few months ago, and I don't think much has happened in the compiler > > and library packages that would make them not compile. It will take a > > me a little time, but I will try it again on these platforms. > > > > OK, this is working for me on LINUXLIBC6. > > With the release compiler installed: > > $ cm3 -version > Critical Mass Modula-3 version 5.8.6 > last updated: 2010-04-11 > compiled: 2013-09-13 21:38:06 > configuration: /usr/local/cm3/bin/cm3.cfg > host: AMD64_LINUX > target: AMD64_LINUX > > And a freshly pulled git repository from github, > in cm3/scripts: > > 1) $ ./do-cm3-all.sh realclean #Clean everything > 2) $ ./do-cm3-front.sh buildship #Build a compiler & its support libraries > > All compiles succeeded. > > 4) $ ./install-cm3-compiler.sh upgrade # Install the compiler > > $ cm3 -version > Critical Mass Modula-3 version d5.10.0 > last updated: 2015-05-21 > compiled: 2015-05-29 02:54:41 > configuration: /usr/local/cm3/bin/cm3.cfg > host: AMD64_LINUX > target: AMD64_LINUX > > Now repeat steps 1 and 2. This will use the newly compiled head compiler. > to rebuild itself. All compiles succeeded. > > Finally, $./do-cm3-all.sh buildship #Build the rest. > > This compiles all the remaining stuff, none of which is involved in bootstrapping. > All compiles succeeded. > > In the past, I often will install the second-time-compiled head compiler and > do it all a third time. After getting this far, this has never failed, and > I didn't do it this time. > > New package libunicode uses an addition to Compiler.i3 that is not in the release, so > you have to install the new compiler before compiling libunicode. Great. So the situation is better than I assumed after my struggles a week ago. Thanks for verifying that. Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From adacore at marino.st Fri May 29 09:39:13 2015 From: adacore at marino.st (John Marino) Date: Fri, 29 May 2015 09:39:13 +0200 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <5567DA8C.3050802@lcwb.coop> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop> Message-ID: <556817A1.2090206@marino.st> On 5/29/2015 05:18, Rodney M. Bates wrote: > OK, this is working for me on LINUXLIBC6. > > With the release compiler installed: > > $ cm3 -version > Critical Mass Modula-3 version 5.8.6 > last updated: 2010-04-11 > compiled: 2013-09-13 21:38:06 > configuration: /usr/local/cm3/bin/cm3.cfg > host: AMD64_LINUX > target: AMD64_LINUX > > And a freshly pulled git repository from github, > in cm3/scripts: > > 1) $ ./do-cm3-all.sh realclean #Clean everything > 2) $ ./do-cm3-front.sh buildship #Build a compiler & its support libraries > > All compiles succeeded. At first I was thinking "this is kind of horrible" until I realized that this is pretty much what the former boot-cm3-with-m3.sh script was doing. I figured out a way to incorporate this technique into the port's makefile. Unfortunately, I can't say I found success. # /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin/cm3 -version Critical Mass Modula-3 version 5.8.6 last updated: 2010-04-11 compiled: 2014-01-02 01:01:20 configuration: /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin/cm3.cfg host: AMD64_FREEBSD target: AMD64_FREEBSD I am seeing the same exact m3cg version stamp errors as I saw on the python upgrade script. Here's my build log so you can verify I followed the procedure: http://leaf.dragonflybsd.org/~marino/m3a.log I don't know it would work for you on linux but not me on FreeBSD ... John From wagner at elego.de Fri May 29 10:54:51 2015 From: wagner at elego.de (Olaf Wagner) Date: Fri, 29 May 2015 10:54:51 +0200 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <556817A1.2090206@marino.st> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop> <556817A1.2090206@marino.st> Message-ID: <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de> On Fri, 29 May 2015 09:39:13 +0200 John Marino wrote: > On 5/29/2015 05:18, Rodney M. Bates wrote: > > OK, this is working for me on LINUXLIBC6. > > > > With the release compiler installed: > > > > $ cm3 -version > > Critical Mass Modula-3 version 5.8.6 > > last updated: 2010-04-11 > > compiled: 2013-09-13 21:38:06 > > configuration: /usr/local/cm3/bin/cm3.cfg > > host: AMD64_LINUX > > target: AMD64_LINUX > > > > And a freshly pulled git repository from github, > > in cm3/scripts: > > > > 1) $ ./do-cm3-all.sh realclean #Clean everything > > 2) $ ./do-cm3-front.sh buildship #Build a compiler & its support libraries > > > > All compiles succeeded. > > At first I was thinking "this is kind of horrible" until I realized that > this is pretty much what the former boot-cm3-with-m3.sh script was > doing. I figured out a way to incorporate this technique into the > port's makefile. Unfortunately, I can't say I found success. > > # > /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin/cm3 > -version > > Critical Mass Modula-3 version 5.8.6 > last updated: 2010-04-11 > compiled: 2014-01-02 01:01:20 > configuration: > /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin/cm3.cfg > host: AMD64_FREEBSD > target: AMD64_FREEBSD > > > I am seeing the same exact m3cg version stamp errors as I saw on the > python upgrade script. Here's my build log so you can verify I followed > the procedure: > > http://leaf.dragonflybsd.org/~marino/m3a.log > > I don't know it would work for you on linux but not me on FreeBSD ... Please try what I suggested in the attached mail: define INSTALL_CM3_IN_BIN=yes in the environment and see if that helps. Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -------------- next part -------------- An embedded message was scrubbed... From: Olaf Wagner Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 Date: Thu, 28 May 2015 23:05:54 +0200 Size: 3481 URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From adacore at marino.st Fri May 29 11:10:50 2015 From: adacore at marino.st (John Marino) Date: Fri, 29 May 2015 11:10:50 +0200 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop> <556817A1.2090206@marino.st> <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de> Message-ID: <55682D1A.2030504@marino.st> On 5/29/2015 10:54, Olaf Wagner wrote: > Please try what I suggested in the attached mail: define > INSTALL_CM3_IN_BIN=yes > in the environment and see if that helps. > Unfortunately it seems the result is exactly the same, even when INSTALL_CM3_IN_BIN is defined in the environment. John From wagner at elego.de Fri May 29 11:39:35 2015 From: wagner at elego.de (Olaf Wagner) Date: Fri, 29 May 2015 11:39:35 +0200 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <55682D1A.2030504@marino.st> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop> <556817A1.2090206@marino.st> <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de> <55682D1A.2030504@marino.st> Message-ID: <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de> On Fri, 29 May 2015 11:10:50 +0200 John Marino wrote: > On 5/29/2015 10:54, Olaf Wagner wrote: > > Please try what I suggested in the attached mail: define > > INSTALL_CM3_IN_BIN=yes > > in the environment and see if that helps. > > > > Unfortunately it seems the result is exactly the same, even when > INSTALL_CM3_IN_BIN is defined in the environment. Can I see the new logs? Has the new backend (cm3cg) been installed now? Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From adacore at marino.st Fri May 29 11:51:05 2015 From: adacore at marino.st (John Marino) Date: Fri, 29 May 2015 11:51:05 +0200 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop> <556817A1.2090206@marino.st> <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de> <55682D1A.2030504@marino.st> <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de> Message-ID: <55683689.2090709@marino.st> On 5/29/2015 11:39, Olaf Wagner wrote: > On Fri, 29 May 2015 11:10:50 +0200 > John Marino wrote: > >> On 5/29/2015 10:54, Olaf Wagner wrote: >>> Please try what I suggested in the attached mail: define >>> INSTALL_CM3_IN_BIN=yes >>> in the environment and see if that helps. >>> >> >> Unfortunately it seems the result is exactly the same, even when >> INSTALL_CM3_IN_BIN is defined in the environment. > > Can I see the new logs? Has the new backend (cm3cg) been installed now? > It's here: http://leaf.dragonflybsd.org/~marino/m3c.log It never completes "do-cm3-front.sh buildship " Note that I'm using a bootstrap install and set INSTALL_ROOT to another location, but it never gets to the point of installing anything. John From wagner at elego.de Fri May 29 12:27:32 2015 From: wagner at elego.de (Olaf Wagner) Date: Fri, 29 May 2015 12:27:32 +0200 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <55683689.2090709@marino.st> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop> <556817A1.2090206@marino.st> <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de> <55682D1A.2030504@marino.st> <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de> <55683689.2090709@marino.st> Message-ID: <20150529122732.1396eb079ff9b404bcb21e40@elego.de> On Fri, 29 May 2015 11:51:05 +0200 John Marino wrote: > On 5/29/2015 11:39, Olaf Wagner wrote: > > On Fri, 29 May 2015 11:10:50 +0200 > > John Marino wrote: > > > >> On 5/29/2015 10:54, Olaf Wagner wrote: > >>> Please try what I suggested in the attached mail: define > >>> INSTALL_CM3_IN_BIN=yes > >>> in the environment and see if that helps. > >>> > >> > >> Unfortunately it seems the result is exactly the same, even when > >> INSTALL_CM3_IN_BIN is defined in the environment. > > > > Can I see the new logs? Has the new backend (cm3cg) been installed now? > > > It's here: > http://leaf.dragonflybsd.org/~marino/m3c.log > > It never completes "do-cm3-front.sh buildship " > > Note that I'm using a bootstrap install and set INSTALL_ROOT to another > location, but it never gets to the point of installing anything. It now has shipped the new gcc-backend as expected, but that doesn't seem to be the problem :-( I'm afraid I'll have to reproduce your setup locally on my FreeBSD system at home, as I don't see the wrong step in the logs 8-| After Rodney's success on Linux I was hoping that everything still just worked as some years ago. Just to make sure: you start with a 5.8.6 release archive for AMD64_FREEBSD, install that, check out the git sources, and run the script(s) in the checked-out repository, correct? Or did I miss anything? Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From adacore at marino.st Fri May 29 12:40:29 2015 From: adacore at marino.st (John Marino) Date: Fri, 29 May 2015 12:40:29 +0200 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <20150529122732.1396eb079ff9b404bcb21e40@elego.de> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop> <556817A1.2090206@marino.st> <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de> <55682D1A.2030504@marino.st> <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de> <55683689.2090709@marino.st> <20150529122732.1396eb079ff9b404bcb21e40@elego.de> Message-ID: <5568421D.3050209@marino.st> On 5/29/2015 12:27, Olaf Wagner wrote: > > I'm afraid I'll have to reproduce your setup locally on my FreeBSD > system at home, as I don't see the wrong step in the logs 8-| > > After Rodney's success on Linux I was hoping that everything still > just worked as some years ago. > > Just to make sure: you start with a 5.8.6 release archive for > AMD64_FREEBSD, install that, check out the git sources, and > run the script(s) in the checked-out repository, correct? Or > did I miss anything? I maintain the "port" for M3 on FreeBSD. see here: http://www.freshports.org/lang/modula3 Because I'm building these in ports, there are certain "rules" I have to follow using makefiles. I've attached the in-work "port" that I'm using. You can "rm -rf /usr/ports/lang/modula3; cd /usr/ports/lang; tar -xf m3-port.tar.gz" to use it to reproduce what I'm doing. All you'd do to reproduce is: "cd /usr/ports/lang/modula3 ; make build" To be more specific, the current repo is downloaded from github as a tarball along with the bootstrap compiler (only once, then the tarball is reused on subsequent). Then it tries to build a new bootstrap compiler in the build target and that's where it's failing. Regards, John -------------- next part -------------- A non-text attachment was scrubbed... Name: m3-port.tar.gz Type: application/x-gzip Size: 3344 bytes Desc: not available URL: From jay.krell at cornell.edu Fri May 29 13:22:15 2015 From: jay.krell at cornell.edu (Jay K) Date: Fri, 29 May 2015 11:22:15 +0000 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <20150528230554.80920c53f002da8beb3f29d0@elegosoft.com> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop>, , <20150528230554.80920c53f002da8beb3f29d0@elegosoft.com> Message-ID: > if equal($INSTALL_CM3_IN_BIN, "yes") Hm. That is relatively new. Rodney, This is a mistake: https://github.com/modula3/cm3/commit/1994f950bb30c3021fd24c07a555f0f7bace933f I see you commented it heavily, but we had working automation before that this broke. The automation already took into account what you were trying to take into account. I agree having the config search all over, which I did, is not good, as it undermines attempts to ship at just the right time. If you don't want to ship cm3cg, then don't run cm3 -ship for it. cm3cg is not actually running when cm3 -ship is run. The reasons cm3 doesn't ship itself do not apply. I agree it seems tempting to sync this behavior with the behavior of shipping cm3. But I don't think it should be. Yes the files have to be updated together. You do that by shipping cm3cg and somehow otherwise copying cm3. I agree that having this "somehow otherwise copy" is not great. I wonder if we can remove that though. The reason cm3 ship is disabled by default is not so that things are updated together, but because having an executable copy over itself reportedly does not work on some operating systems. It is nothing to do with our need to copy multiple files automatically. It is because it will fail. Now..I must say..Windows is extremely often labeled as one of these systems. Countless people believe this myth. But it isn't true. You can copy over an "in use" .dll or .exe. You merely have to rename it away first. Yes, that is still a bit wierd. And I have to investigate how to eventually delete it. Yes, there is a way to defer the delete..until a reboot..if you are an administrator.. but that is clearly an inadequate mechanism. It is quite possible you open with delete_on_close, and close, and then the last close might do it, when the .exe stops running. We should try this out. However, with Windows possibly eliminated as a concern (once ship does the rename, which it doesn't currently), does that leave other systems? AIX I believe is similar..that a direct copy will fail. But will rename work around it there too? Should we let cm3 be able to ship itself, and see what comes of it? Like, maybe every system people really use can do it? When an AIX user speaks up, we can fix it then?? Either way, I believe this change to m3cc/src/m3makefile should be undone. In the meantime, everyone can workaround it by setting the environment variable. The other angle, which I've been pushing unsuccessfully is never update in place. That is portable. Start with a new empty directory tree and fill it in by shipping, even cm3. Like make-dist.py does. One wrinkle here is that cm3, if it doesn't already, must favor looking next to itself, and not searching $PATH. So that you ship cm3cg to the new place, and then cm3, and cm3 shipping second finishes the transaction (ok, you'd also copy/ship other files, like configs and m3core/libm3, and then cm3 last). I would really really like that code for an executable to find its full path, on all supported systems. I don't think Posix can do it. Win32 GetModuleFileName(NULL or &__ImageBase) for example. Then strip off the last path element and append stuff, to find things you go with. It is a nice technique. I'm leary of techniques that rely on $PATH search or applying argv[0] to getcwd, as the current directory can change at any time. (and another unsuccessful angle is to move away from all the .sh files; I've been using the .py files for years...well, I was...) - Jay > Date: Thu, 28 May 2015 23:05:54 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: rodney.m.bates at acm.org; m3devel at elegosoft.com; adacore at marino.st > Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > > On Thu, 28 May 2015 20:14:49 +0000 > Jay K wrote: > > > > Also, this script built the compiler before the support libraries m3core and > > > libm3. I think there may have been one bootstrap scenario where this was the > > > way it needed to be done, but usually it is the other way around--these two > > > libraries first. > > > > This is very deliberate and should always work, when doing a native upgrade. > > It is true it is not always required. > > When doing a "clean" cross build, it is true that it is backwards. > > It is required when upgrading from an older build. > > > > Native upgrades start at least with a working compiler and its matching runtime. > > Cross builds start with a working host compiler and nothing for the target -- so they do start with m3core. > > I've had a look at the build log, and I think the problem in this case > with upgrade.py might be that it doesn't install the new backend, but > only the new frontend: > > [...] > Not shipping cm3cg. > --- shipping from AMD64_FREEBSD --- > > missing ".M3SHIP" file, build the package first. > dula3/work/bootstrap/bin/cm3 -build -DROOT=/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a +++ > ==> /mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a/m3-sys/m3cc done > > +++ /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin/cm3 -ship -DROOT=/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a +++ > ==> /mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a/m3-sys/m3cc done > > mkdir -p /mech/construction/mech/ptrees/default/lang/modula3/work/stage/usr/local/bin > cp -Pv /mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a/m3-sys/cm3/AMD64_FREEBSD/cm3 /mech/construction/mech/ptrees/default/lang/modula3/work/stage/usr/local/bin/cm3 > [...] > > In the upgrade.sh script I used install-cm3-compiler.sh, which always > installs both. In m3-sys/m3cc/src/m3makefile I find the following code: > > if equal($INSTALL_CM3_IN_BIN, "yes") > deriveds("", ["cm3cg", "cm3cg.exe"]) > write ( "Forced ship of cm3cg." & CR) > BindExport (AppendExeExtension ("cm3cg")) > if DoMipsTfile > BindExport ("mips-tfile") > end > else > write ( "Not shipping cm3cg." & CR) > end > > So perhaps simply setting INSTALL_CM3_IN_BIN=yes in the environment > will fix that problem? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri May 29 13:42:32 2015 From: jay.krell at cornell.edu (Jay K) Date: Fri, 29 May 2015 11:42:32 +0000 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop>, , , , <20150528230554.80920c53f002da8beb3f29d0@elegosoft.com>, Message-ID: > One wrinkle here is that cm3, if it doesn't already, must favor looking next to itself, and not searching $PATH. dladdr appears to be the answer. It appears to be supported on MacOSX 10.4. OpenBSD, NetBSD, FreeBSD, Solaris, AIX, HP-UX, Irix, OpenVMS, Tru64. At least later versions of all of them. Non-authoritative web searches indicate so... And GetModuleFileName on Windows. Any objections to using it in cm3? (and GetModuleFileName on Windows)? This way, cm3 can easily and reliably look next to itself for config files and the pkg directory and cm3cg. I can double double check, but I doubt what it does today is totally reliable. Thanks, - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com Date: Fri, 29 May 2015 11:22:15 +0000 CC: m3devel at elegosoft.com; rodney.m.bates at acm.org Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > if equal($INSTALL_CM3_IN_BIN, "yes") Hm. That is relatively new. Rodney, This is a mistake: https://github.com/modula3/cm3/commit/1994f950bb30c3021fd24c07a555f0f7bace933f I see you commented it heavily, but we had working automation before that this broke. The automation already took into account what you were trying to take into account. I agree having the config search all over, which I did, is not good, as it undermines attempts to ship at just the right time. If you don't want to ship cm3cg, then don't run cm3 -ship for it. cm3cg is not actually running when cm3 -ship is run. The reasons cm3 doesn't ship itself do not apply. I agree it seems tempting to sync this behavior with the behavior of shipping cm3. But I don't think it should be. Yes the files have to be updated together. You do that by shipping cm3cg and somehow otherwise copying cm3. I agree that having this "somehow otherwise copy" is not great. I wonder if we can remove that though. The reason cm3 ship is disabled by default is not so that things are updated together, but because having an executable copy over itself reportedly does not work on some operating systems. It is nothing to do with our need to copy multiple files automatically. It is because it will fail. Now..I must say..Windows is extremely often labeled as one of these systems. Countless people believe this myth. But it isn't true. You can copy over an "in use" .dll or .exe. You merely have to rename it away first. Yes, that is still a bit wierd. And I have to investigate how to eventually delete it. Yes, there is a way to defer the delete..until a reboot..if you are an administrator.. but that is clearly an inadequate mechanism. It is quite possible you open with delete_on_close, and close, and then the last close might do it, when the .exe stops running. We should try this out. However, with Windows possibly eliminated as a concern (once ship does the rename, which it doesn't currently), does that leave other systems? AIX I believe is similar..that a direct copy will fail. But will rename work around it there too? Should we let cm3 be able to ship itself, and see what comes of it? Like, maybe every system people really use can do it? When an AIX user speaks up, we can fix it then?? Either way, I believe this change to m3cc/src/m3makefile should be undone. In the meantime, everyone can workaround it by setting the environment variable. The other angle, which I've been pushing unsuccessfully is never update in place. That is portable. Start with a new empty directory tree and fill it in by shipping, even cm3. Like make-dist.py does. One wrinkle here is that cm3, if it doesn't already, must favor looking next to itself, and not searching $PATH. So that you ship cm3cg to the new place, and then cm3, and cm3 shipping second finishes the transaction (ok, you'd also copy/ship other files, like configs and m3core/libm3, and then cm3 last). I would really really like that code for an executable to find its full path, on all supported systems. I don't think Posix can do it. Win32 GetModuleFileName(NULL or &__ImageBase) for example. Then strip off the last path element and append stuff, to find things you go with. It is a nice technique. I'm leary of techniques that rely on $PATH search or applying argv[0] to getcwd, as the current directory can change at any time. (and another unsuccessful angle is to move away from all the .sh files; I've been using the .py files for years...well, I was...) - Jay > Date: Thu, 28 May 2015 23:05:54 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: rodney.m.bates at acm.org; m3devel at elegosoft.com; adacore at marino.st > Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > > On Thu, 28 May 2015 20:14:49 +0000 > Jay K wrote: > > > > Also, this script built the compiler before the support libraries m3core and > > > libm3. I think there may have been one bootstrap scenario where this was the > > > way it needed to be done, but usually it is the other way around--these two > > > libraries first. > > > > This is very deliberate and should always work, when doing a native upgrade. > > It is true it is not always required. > > When doing a "clean" cross build, it is true that it is backwards. > > It is required when upgrading from an older build. > > > > Native upgrades start at least with a working compiler and its matching runtime. > > Cross builds start with a working host compiler and nothing for the target -- so they do start with m3core. > > I've had a look at the build log, and I think the problem in this case > with upgrade.py might be that it doesn't install the new backend, but > only the new frontend: > > [...] > Not shipping cm3cg. > --- shipping from AMD64_FREEBSD --- > > missing ".M3SHIP" file, build the package first. > dula3/work/bootstrap/bin/cm3 -build -DROOT=/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a +++ > ==> /mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a/m3-sys/m3cc done > > +++ /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin/cm3 -ship -DROOT=/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a +++ > ==> /mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a/m3-sys/m3cc done > > mkdir -p /mech/construction/mech/ptrees/default/lang/modula3/work/stage/usr/local/bin > cp -Pv /mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a/m3-sys/cm3/AMD64_FREEBSD/cm3 /mech/construction/mech/ptrees/default/lang/modula3/work/stage/usr/local/bin/cm3 > [...] > > In the upgrade.sh script I used install-cm3-compiler.sh, which always > installs both. In m3-sys/m3cc/src/m3makefile I find the following code: > > if equal($INSTALL_CM3_IN_BIN, "yes") > deriveds("", ["cm3cg", "cm3cg.exe"]) > write ( "Forced ship of cm3cg." & CR) > BindExport (AppendExeExtension ("cm3cg")) > if DoMipsTfile > BindExport ("mips-tfile") > end > else > write ( "Not shipping cm3cg." & CR) > end > > So perhaps simply setting INSTALL_CM3_IN_BIN=yes in the environment > will fix that problem? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri May 29 13:45:02 2015 From: jay.krell at cornell.edu (Jay K) Date: Fri, 29 May 2015 11:45:02 +0000 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop>, , , , <20150528230554.80920c53f002da8beb3f29d0@elegosoft.com>, Message-ID: The workaround is bad, as it affects m3-sys/cm3 also. Rodney, this really should be removed. If you must have something like this, make it a separate variable from cm3. Please. - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com Date: Fri, 29 May 2015 11:22:15 +0000 CC: m3devel at elegosoft.com; rodney.m.bates at acm.org Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > if equal($INSTALL_CM3_IN_BIN, "yes") Hm. That is relatively new. Rodney, This is a mistake: https://github.com/modula3/cm3/commit/1994f950bb30c3021fd24c07a555f0f7bace933f I see you commented it heavily, but we had working automation before that this broke. The automation already took into account what you were trying to take into account. I agree having the config search all over, which I did, is not good, as it undermines attempts to ship at just the right time. If you don't want to ship cm3cg, then don't run cm3 -ship for it. cm3cg is not actually running when cm3 -ship is run. The reasons cm3 doesn't ship itself do not apply. I agree it seems tempting to sync this behavior with the behavior of shipping cm3. But I don't think it should be. Yes the files have to be updated together. You do that by shipping cm3cg and somehow otherwise copying cm3. I agree that having this "somehow otherwise copy" is not great. I wonder if we can remove that though. The reason cm3 ship is disabled by default is not so that things are updated together, but because having an executable copy over itself reportedly does not work on some operating systems. It is nothing to do with our need to copy multiple files automatically. It is because it will fail. Now..I must say..Windows is extremely often labeled as one of these systems. Countless people believe this myth. But it isn't true. You can copy over an "in use" .dll or .exe. You merely have to rename it away first. Yes, that is still a bit wierd. And I have to investigate how to eventually delete it. Yes, there is a way to defer the delete..until a reboot..if you are an administrator.. but that is clearly an inadequate mechanism. It is quite possible you open with delete_on_close, and close, and then the last close might do it, when the .exe stops running. We should try this out. However, with Windows possibly eliminated as a concern (once ship does the rename, which it doesn't currently), does that leave other systems? AIX I believe is similar..that a direct copy will fail. But will rename work around it there too? Should we let cm3 be able to ship itself, and see what comes of it? Like, maybe every system people really use can do it? When an AIX user speaks up, we can fix it then?? Either way, I believe this change to m3cc/src/m3makefile should be undone. In the meantime, everyone can workaround it by setting the environment variable. The other angle, which I've been pushing unsuccessfully is never update in place. That is portable. Start with a new empty directory tree and fill it in by shipping, even cm3. Like make-dist.py does. One wrinkle here is that cm3, if it doesn't already, must favor looking next to itself, and not searching $PATH. So that you ship cm3cg to the new place, and then cm3, and cm3 shipping second finishes the transaction (ok, you'd also copy/ship other files, like configs and m3core/libm3, and then cm3 last). I would really really like that code for an executable to find its full path, on all supported systems. I don't think Posix can do it. Win32 GetModuleFileName(NULL or &__ImageBase) for example. Then strip off the last path element and append stuff, to find things you go with. It is a nice technique. I'm leary of techniques that rely on $PATH search or applying argv[0] to getcwd, as the current directory can change at any time. (and another unsuccessful angle is to move away from all the .sh files; I've been using the .py files for years...well, I was...) - Jay > Date: Thu, 28 May 2015 23:05:54 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: rodney.m.bates at acm.org; m3devel at elegosoft.com; adacore at marino.st > Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > > On Thu, 28 May 2015 20:14:49 +0000 > Jay K wrote: > > > > Also, this script built the compiler before the support libraries m3core and > > > libm3. I think there may have been one bootstrap scenario where this was the > > > way it needed to be done, but usually it is the other way around--these two > > > libraries first. > > > > This is very deliberate and should always work, when doing a native upgrade. > > It is true it is not always required. > > When doing a "clean" cross build, it is true that it is backwards. > > It is required when upgrading from an older build. > > > > Native upgrades start at least with a working compiler and its matching runtime. > > Cross builds start with a working host compiler and nothing for the target -- so they do start with m3core. > > I've had a look at the build log, and I think the problem in this case > with upgrade.py might be that it doesn't install the new backend, but > only the new frontend: > > [...] > Not shipping cm3cg. > --- shipping from AMD64_FREEBSD --- > > missing ".M3SHIP" file, build the package first. > dula3/work/bootstrap/bin/cm3 -build -DROOT=/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a +++ > ==> /mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a/m3-sys/m3cc done > > +++ /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin/cm3 -ship -DROOT=/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a +++ > ==> /mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a/m3-sys/m3cc done > > mkdir -p /mech/construction/mech/ptrees/default/lang/modula3/work/stage/usr/local/bin > cp -Pv /mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a/m3-sys/cm3/AMD64_FREEBSD/cm3 /mech/construction/mech/ptrees/default/lang/modula3/work/stage/usr/local/bin/cm3 > [...] > > In the upgrade.sh script I used install-cm3-compiler.sh, which always > installs both. In m3-sys/m3cc/src/m3makefile I find the following code: > > if equal($INSTALL_CM3_IN_BIN, "yes") > deriveds("", ["cm3cg", "cm3cg.exe"]) > write ( "Forced ship of cm3cg." & CR) > BindExport (AppendExeExtension ("cm3cg")) > if DoMipsTfile > BindExport ("mips-tfile") > end > else > write ( "Not shipping cm3cg." & CR) > end > > So perhaps simply setting INSTALL_CM3_IN_BIN=yes in the environment > will fix that problem? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elego.de Fri May 29 14:04:02 2015 From: wagner at elego.de (Olaf Wagner) Date: Fri, 29 May 2015 14:04:02 +0200 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <20150528230554.80920c53f002da8beb3f29d0@elegosoft.com> Message-ID: <20150529140402.d87ddf6435a145c466ed3434@elego.de> On Fri, 29 May 2015 11:45:02 +0000 Jay K wrote: > The workaround is bad, as it affects m3-sys/cm3 also. > Rodney, this really should be removed. If you must have something like this, make it a separate variable from cm3. Please. I don't think Rodney introduced this variable ;-) Olaf > - Jay > > > > From: jay.krell at cornell.edu > To: wagner at elegosoft.com > Date: Fri, 29 May 2015 11:22:15 +0000 > CC: m3devel at elegosoft.com; rodney.m.bates at acm.org > Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > > > > > > if equal($INSTALL_CM3_IN_BIN, "yes") > > > Hm. That is relatively new. > Rodney, This is a mistake: > https://github.com/modula3/cm3/commit/1994f950bb30c3021fd24c07a555f0f7bace933f > > > I see you commented it heavily, but we had working automation before that this broke. > The automation already took into account what you were trying to take into account. > > > I agree having the config search all over, which I did, is not good, > as it undermines attempts to ship at just the right time. > > > If you don't want to ship cm3cg, then don't run cm3 -ship for it. > cm3cg is not actually running when cm3 -ship is run. > The reasons cm3 doesn't ship itself do not apply. > > > I agree it seems tempting to sync this behavior with the behavior of shipping cm3. > But I don't think it should be. > > > Yes the files have to be updated together. > You do that by shipping cm3cg and somehow otherwise copying cm3. > I agree that having this "somehow otherwise copy" is not great. > I wonder if we can remove that though. > > > The reason cm3 ship is disabled by default is not so that things are updated together, > but because having an executable copy over itself reportedly does not work on some operating systems. > It is nothing to do with our need to copy multiple files automatically. It is because it will fail. > > > > Now..I must say..Windows is extremely often labeled as one of these systems. > Countless people believe this myth. But it isn't true. > You can copy over an "in use" .dll or .exe. > You merely have to rename it away first. Yes, that is still a bit wierd. > And I have to investigate how to eventually delete it. > Yes, there is a way to defer the delete..until a reboot..if you are an administrator.. > but that is clearly an inadequate mechanism. It is quite possible you open with delete_on_close, > and close, and then the last close might do it, when the .exe stops running. > We should try this out. > > > > However, with Windows possibly eliminated as a concern (once ship does the rename, which it doesn't currently), > does that leave other systems? AIX I believe is similar..that a direct copy will fail. > But will rename work around it there too? > > > Should we let cm3 be able to ship itself, and see what comes of it? > Like, maybe every system people really use can do it? > When an AIX user speaks up, we can fix it then?? > > > > Either way, I believe this change to m3cc/src/m3makefile should be undone. > > > In the meantime, everyone can workaround it by setting the environment variable. > > > The other angle, which I've been pushing unsuccessfully is never update in place. > That is portable. > Start with a new empty directory tree and fill it in by shipping, even cm3. > Like make-dist.py does. > One wrinkle here is that cm3, if it doesn't already, must favor looking next to itself, and not searching $PATH. > So that you ship cm3cg to the new place, and then cm3, and cm3 shipping second finishes the transaction (ok, > you'd also copy/ship other files, like configs and m3core/libm3, and then cm3 last). > > > > I would really really like that code for an executable to find its full path, on all supported systems. > I don't think Posix can do it. Win32 GetModuleFileName(NULL or &__ImageBase) for example. > Then strip off the last path element and append stuff, to find things you go with. > It is a nice technique. > I'm leary of techniques that rely on $PATH search or applying argv[0] to getcwd, as the current directory can change at any time. > > > (and another unsuccessful angle is to move away from all the .sh files; I've been using the .py files for years...well, I was...) > > > > - Jay > > > > > Date: Thu, 28 May 2015 23:05:54 +0200 > > From: wagner at elegosoft.com > > To: jay.krell at cornell.edu > > CC: rodney.m.bates at acm.org; m3devel at elegosoft.com; adacore at marino.st > > Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > > > > On Thu, 28 May 2015 20:14:49 +0000 > > Jay K wrote: > > > > > > Also, this script built the compiler before the support libraries m3core and > > > > libm3. I think there may have been one bootstrap scenario where this was the > > > > way it needed to be done, but usually it is the other way around--these two > > > > libraries first. > > > > > > This is very deliberate and should always work, when doing a native upgrade. > > > It is true it is not always required. > > > When doing a "clean" cross build, it is true that it is backwards. > > > It is required when upgrading from an older build. > > > > > > Native upgrades start at least with a working compiler and its matching runtime. > > > Cross builds start with a working host compiler and nothing for the target -- so they do start with m3core. > > > > I've had a look at the build log, and I think the problem in this case > > with upgrade.py might be that it doesn't install the new backend, but > > only the new frontend: > > > > [...] > > Not shipping cm3cg. > > --- shipping from AMD64_FREEBSD --- > > > > missing ".M3SHIP" file, build the package first. > > dula3/work/bootstrap/bin/cm3 -build -DROOT=/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a +++ > > ==> /mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a/m3-sys/m3cc done > > > > +++ /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin/cm3 -ship -DROOT=/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a +++ > > ==> /mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a/m3-sys/m3cc done > > > > mkdir -p /mech/construction/mech/ptrees/default/lang/modula3/work/stage/usr/local/bin > > cp -Pv /mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a/m3-sys/cm3/AMD64_FREEBSD/cm3 /mech/construction/mech/ptrees/default/lang/modula3/work/stage/usr/local/bin/cm3 > > [...] > > > > In the upgrade.sh script I used install-cm3-compiler.sh, which always > > installs both. In m3-sys/m3cc/src/m3makefile I find the following code: > > > > if equal($INSTALL_CM3_IN_BIN, "yes") > > deriveds("", ["cm3cg", "cm3cg.exe"]) > > write ( "Forced ship of cm3cg." & CR) > > BindExport (AppendExeExtension ("cm3cg")) > > if DoMipsTfile > > BindExport ("mips-tfile") > > end > > else > > write ( "Not shipping cm3cg." & CR) > > end > > > > So perhaps simply setting INSTALL_CM3_IN_BIN=yes in the environment > > will fix that problem? > > > > Olaf > > -- > > Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > > Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From wagner at elego.de Fri May 29 15:58:33 2015 From: wagner at elego.de (Olaf Wagner) Date: Fri, 29 May 2015 15:58:33 +0200 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <5568421D.3050209@marino.st> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop> <556817A1.2090206@marino.st> <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de> <55682D1A.2030504@marino.st> <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de> <55683689.2090709@marino.st> <20150529122732.1396eb079ff9b404bcb21e40@elego.de> <5568421D.3050209@marino.st> Message-ID: <20150529155833.8454664b88391d93708e8f85@elego.de> On Fri, 29 May 2015 12:40:29 +0200 John Marino wrote: > On 5/29/2015 12:27, Olaf Wagner wrote: > > > > > I'm afraid I'll have to reproduce your setup locally on my FreeBSD > > system at home, as I don't see the wrong step in the logs 8-| > > > > After Rodney's success on Linux I was hoping that everything still > > just worked as some years ago. > > > > Just to make sure: you start with a 5.8.6 release archive for > > AMD64_FREEBSD, install that, check out the git sources, and > > run the script(s) in the checked-out repository, correct? Or > > did I miss anything? > > I maintain the "port" for M3 on FreeBSD. see here: > http://www.freshports.org/lang/modula3 > > Because I'm building these in ports, there are certain "rules" I have to > follow using makefiles. I've attached the in-work "port" that I'm > using. You can "rm -rf /usr/ports/lang/modula3; cd /usr/ports/lang; tar > -xf m3-port.tar.gz" to use it to reproduce what I'm doing. > > All you'd do to reproduce is: "cd /usr/ports/lang/modula3 ; make build" > > To be more specific, the current repo is downloaded from github as a > tarball along with the bootstrap compiler (only once, then the tarball > is reused on subsequent). Then it tries to build a new bootstrap > compiler in the build target and that's where it's failing. I unpacked your port and tried the first step. But my system seems to be too old: % make fetch ===> modula3-5.10.0 the bootstrap compiler only runs on FreeBSD 9.0 or later. *** Error code 1 Stop in /src/ports/lang/modula3. Why would it only run on FreeBSD 9? I actually _have_ a working cm3 installation on this system ;-) Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From adacore at marino.st Fri May 29 16:06:30 2015 From: adacore at marino.st (John Marino) Date: Fri, 29 May 2015 16:06:30 +0200 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <20150529155833.8454664b88391d93708e8f85@elego.de> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop> <556817A1.2090206@marino.st> <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de> <55682D1A.2030504@marino.st> <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de> <55683689.2090709@marino.st> <20150529122732.1396eb079ff9b404bcb21e40@elego.de> <5568421D.3050209@marino.st> <20150529155833.8454664b88391d93708e8f85@elego.de> Message-ID: <55687266.3090400@marino.st> On 5/29/2015 15:58, Olaf Wagner wrote: > On Fri, 29 May 2015 12:40:29 +0200 > John Marino wrote: > I unpacked your port and tried the first step. > But my system seems to be too old: > > % make fetch > ===> modula3-5.10.0 the bootstrap compiler only runs on FreeBSD 9.0 or later. > *** Error code 1 This means at best your machine is FreeBSD 8.x. The last FreeBSD 8, 8.4 (a long-term support version) expires in 4 weeks. So you should update. :) > Stop in /src/ports/lang/modula3. > > Why would it only run on FreeBSD 9? > I actually _have_ a working cm3 installation on this system ;-) The port doesn't consider installed CM3. It has to do with how ports are now built in "clean" jails where nothing is installed. You *could* package your working CM3 as a bootstrap compiler [1] but I would think your time would be better spent with FreeBSD Update: https://www.freebsd.org/doc/handbook/updating-upgrading-freebsdupdate.html John [1] Just look in work/bootstrap and emulate if you want to do this. From wagner at elego.de Fri May 29 16:20:28 2015 From: wagner at elego.de (Olaf Wagner) Date: Fri, 29 May 2015 16:20:28 +0200 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <55687266.3090400@marino.st> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop> <556817A1.2090206@marino.st> <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de> <55682D1A.2030504@marino.st> <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de> <55683689.2090709@marino.st> <20150529122732.1396eb079ff9b404bcb21e40@elego.de> <5568421D.3050209@marino.st> <20150529155833.8454664b88391d93708e8f85@elego.de> <55687266.3090400@marino.st> Message-ID: <20150529162028.388911007a614006049beb42@elego.de> On Fri, 29 May 2015 16:06:30 +0200 John Marino wrote: > On 5/29/2015 15:58, Olaf Wagner wrote: > > On Fri, 29 May 2015 12:40:29 +0200 > > John Marino wrote: > > I unpacked your port and tried the first step. > > But my system seems to be too old: > > > > % make fetch > > ===> modula3-5.10.0 the bootstrap compiler only runs on FreeBSD 9.0 or later. > > *** Error code 1 > > This means at best your machine is FreeBSD 8.x. The last FreeBSD 8, 8.4 > (a long-term support version) expires in 4 weeks. So you should update. :) > > > > Stop in /src/ports/lang/modula3. > > > > Why would it only run on FreeBSD 9? > > I actually _have_ a working cm3 installation on this system ;-) > > The port doesn't consider installed CM3. It has to do with how ports > are now built in "clean" jails where nothing is installed. > > You *could* package your working CM3 as a bootstrap compiler [1] but I > would think your time would be better spent with FreeBSD Update: > https://www.freebsd.org/doc/handbook/updating-upgrading-freebsdupdate.html > > John > > > [1] Just look in work/bootstrap and emulate if you want to do this. I will update the system (it's the latest 8.4 stable) but it's unlikely that I'll do it within the next two weeks, because I won't be at home. I'll try to reproduce the problem without the port makefile though. Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From wagner at elego.de Fri May 29 17:23:05 2015 From: wagner at elego.de (Olaf Wagner) Date: Fri, 29 May 2015 17:23:05 +0200 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <20150529162028.388911007a614006049beb42@elego.de> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop> <556817A1.2090206@marino.st> <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de> <55682D1A.2030504@marino.st> <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de> <55683689.2090709@marino.st> <20150529122732.1396eb079ff9b404bcb21e40@elego.de> <5568421D.3050209@marino.st> <20150529155833.8454664b88391d93708e8f85@elego.de> <55687266.3090400@marino.st> <20150529162028.388911007a614006049beb42@elego.de> Message-ID: <20150529172305.a3fc2a9865b5250a5b9140fc@elego.de> On Fri, 29 May 2015 16:20:28 +0200 Olaf Wagner wrote: > On Fri, 29 May 2015 16:06:30 +0200 > John Marino wrote: > > > On 5/29/2015 15:58, Olaf Wagner wrote: > > > On Fri, 29 May 2015 12:40:29 +0200 > > > John Marino wrote: > > > I unpacked your port and tried the first step. > > > But my system seems to be too old: > > > > > > % make fetch > > > ===> modula3-5.10.0 the bootstrap compiler only runs on FreeBSD 9.0 or later. > > > *** Error code 1 > > > > This means at best your machine is FreeBSD 8.x. The last FreeBSD 8, 8.4 > > (a long-term support version) expires in 4 weeks. So you should update. :) > > > > > > > Stop in /src/ports/lang/modula3. > > > > > > Why would it only run on FreeBSD 9? > > > I actually _have_ a working cm3 installation on this system ;-) > > > > The port doesn't consider installed CM3. It has to do with how ports > > are now built in "clean" jails where nothing is installed. > > > > You *could* package your working CM3 as a bootstrap compiler [1] but I > > would think your time would be better spent with FreeBSD Update: > > https://www.freebsd.org/doc/handbook/updating-upgrading-freebsdupdate.html > > > > John > > > > > > [1] Just look in work/bootstrap and emulate if you want to do this. > > I will update the system (it's the latest 8.4 stable) but it's > unlikely that I'll do it within the next two weeks, because I won't > be at home. > > I'll try to reproduce the problem without the port makefile though. The bootstrap compiler backend doesn't run on my system: new exporters -> recompiling FSUtils.i3 /libexec/ld-elf.so.1: /usr/ports/lang/modula3/work/bootstrap//bin/cm3cg: Undefined symbol "_ThreadRuneLocale" m3_backend => 1 m3cc (aka cm3cg) failed compiling: FSUtils.ic It seems there's no way around a system upgrade. But that won't happen today, sorry. I'll make a final test with an older bootstrap archive from opencm3.net later. Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From jay.krell at cornell.edu Fri May 29 17:18:35 2015 From: jay.krell at cornell.edu (Jay K) Date: Fri, 29 May 2015 15:18:35 +0000 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <20150529140402.d87ddf6435a145c466ed3434@elego.de> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop>, , <20150528230554.80920c53f002da8beb3f29d0@elegosoft.com>, , , <20150529140402.d87ddf6435a145c466ed3434@elego.de> Message-ID: I believe the variable existed for cm3, but not m3cc/cm3cg. Rodney added it for m3cc/cm3cg. - Jay > Date: Fri, 29 May 2015 14:04:02 +0200 > From: wagner at elego.de > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com; rodney.m.bates at acm.org > Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > > On Fri, 29 May 2015 11:45:02 +0000 > Jay K wrote: > > > The workaround is bad, as it affects m3-sys/cm3 also. > > Rodney, this really should be removed. If you must have something like this, make it a separate variable from cm3. Please. > > I don't think Rodney introduced this variable ;-) > > Olaf > > > - Jay > > > > > > > > From: jay.krell at cornell.edu > > To: wagner at elegosoft.com > > Date: Fri, 29 May 2015 11:22:15 +0000 > > CC: m3devel at elegosoft.com; rodney.m.bates at acm.org > > Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > > > > > > > > > > > if equal($INSTALL_CM3_IN_BIN, "yes") > > > > > > Hm. That is relatively new. > > Rodney, This is a mistake: > > https://github.com/modula3/cm3/commit/1994f950bb30c3021fd24c07a555f0f7bace933f > > > > > > I see you commented it heavily, but we had working automation before that this broke. > > The automation already took into account what you were trying to take into account. > > > > > > I agree having the config search all over, which I did, is not good, > > as it undermines attempts to ship at just the right time. > > > > > > If you don't want to ship cm3cg, then don't run cm3 -ship for it. > > cm3cg is not actually running when cm3 -ship is run. > > The reasons cm3 doesn't ship itself do not apply. > > > > > > I agree it seems tempting to sync this behavior with the behavior of shipping cm3. > > But I don't think it should be. > > > > > > Yes the files have to be updated together. > > You do that by shipping cm3cg and somehow otherwise copying cm3. > > I agree that having this "somehow otherwise copy" is not great. > > I wonder if we can remove that though. > > > > > > The reason cm3 ship is disabled by default is not so that things are updated together, > > but because having an executable copy over itself reportedly does not work on some operating systems. > > It is nothing to do with our need to copy multiple files automatically. It is because it will fail. > > > > > > > > Now..I must say..Windows is extremely often labeled as one of these systems. > > Countless people believe this myth. But it isn't true. > > You can copy over an "in use" .dll or .exe. > > You merely have to rename it away first. Yes, that is still a bit wierd. > > And I have to investigate how to eventually delete it. > > Yes, there is a way to defer the delete..until a reboot..if you are an administrator.. > > but that is clearly an inadequate mechanism. It is quite possible you open with delete_on_close, > > and close, and then the last close might do it, when the .exe stops running. > > We should try this out. > > > > > > > > However, with Windows possibly eliminated as a concern (once ship does the rename, which it doesn't currently), > > does that leave other systems? AIX I believe is similar..that a direct copy will fail. > > But will rename work around it there too? > > > > > > Should we let cm3 be able to ship itself, and see what comes of it? > > Like, maybe every system people really use can do it? > > When an AIX user speaks up, we can fix it then?? > > > > > > > > Either way, I believe this change to m3cc/src/m3makefile should be undone. > > > > > > In the meantime, everyone can workaround it by setting the environment variable. > > > > > > The other angle, which I've been pushing unsuccessfully is never update in place. > > That is portable. > > Start with a new empty directory tree and fill it in by shipping, even cm3. > > Like make-dist.py does. > > One wrinkle here is that cm3, if it doesn't already, must favor looking next to itself, and not searching $PATH. > > So that you ship cm3cg to the new place, and then cm3, and cm3 shipping second finishes the transaction (ok, > > you'd also copy/ship other files, like configs and m3core/libm3, and then cm3 last). > > > > > > > > I would really really like that code for an executable to find its full path, on all supported systems. > > I don't think Posix can do it. Win32 GetModuleFileName(NULL or &__ImageBase) for example. > > Then strip off the last path element and append stuff, to find things you go with. > > It is a nice technique. > > I'm leary of techniques that rely on $PATH search or applying argv[0] to getcwd, as the current directory can change at any time. > > > > > > (and another unsuccessful angle is to move away from all the .sh files; I've been using the .py files for years...well, I was...) > > > > > > > > - Jay > > > > > > > > > Date: Thu, 28 May 2015 23:05:54 +0200 > > > From: wagner at elegosoft.com > > > To: jay.krell at cornell.edu > > > CC: rodney.m.bates at acm.org; m3devel at elegosoft.com; adacore at marino.st > > > Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > > > > > > On Thu, 28 May 2015 20:14:49 +0000 > > > Jay K wrote: > > > > > > > > Also, this script built the compiler before the support libraries m3core and > > > > > libm3. I think there may have been one bootstrap scenario where this was the > > > > > way it needed to be done, but usually it is the other way around--these two > > > > > libraries first. > > > > > > > > This is very deliberate and should always work, when doing a native upgrade. > > > > It is true it is not always required. > > > > When doing a "clean" cross build, it is true that it is backwards. > > > > It is required when upgrading from an older build. > > > > > > > > Native upgrades start at least with a working compiler and its matching runtime. > > > > Cross builds start with a working host compiler and nothing for the target -- so they do start with m3core. > > > > > > I've had a look at the build log, and I think the problem in this case > > > with upgrade.py might be that it doesn't install the new backend, but > > > only the new frontend: > > > > > > [...] > > > Not shipping cm3cg. > > > --- shipping from AMD64_FREEBSD --- > > > > > > missing ".M3SHIP" file, build the package first. > > > dula3/work/bootstrap/bin/cm3 -build -DROOT=/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a +++ > > > ==> /mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a/m3-sys/m3cc done > > > > > > +++ /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin/cm3 -ship -DROOT=/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a +++ > > > ==> /mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a/m3-sys/m3cc done > > > > > > mkdir -p /mech/construction/mech/ptrees/default/lang/modula3/work/stage/usr/local/bin > > > cp -Pv /mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a/m3-sys/cm3/AMD64_FREEBSD/cm3 /mech/construction/mech/ptrees/default/lang/modula3/work/stage/usr/local/bin/cm3 > > > [...] > > > > > > In the upgrade.sh script I used install-cm3-compiler.sh, which always > > > installs both. In m3-sys/m3cc/src/m3makefile I find the following code: > > > > > > if equal($INSTALL_CM3_IN_BIN, "yes") > > > deriveds("", ["cm3cg", "cm3cg.exe"]) > > > write ( "Forced ship of cm3cg." & CR) > > > BindExport (AppendExeExtension ("cm3cg")) > > > if DoMipsTfile > > > BindExport ("mips-tfile") > > > end > > > else > > > write ( "Not shipping cm3cg." & CR) > > > end > > > > > > So perhaps simply setting INSTALL_CM3_IN_BIN=yes in the environment > > > will fix that problem? > > > > > > Olaf > > > -- > > > Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com > > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > > > Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > > > > -- > Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -------------- next part -------------- An HTML attachment was scrubbed... URL: From adacore at marino.st Fri May 29 17:30:05 2015 From: adacore at marino.st (John Marino) Date: Fri, 29 May 2015 17:30:05 +0200 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <20150529172305.a3fc2a9865b5250a5b9140fc@elego.de> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop> <556817A1.2090206@marino.st> <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de> <55682D1A.2030504@marino.st> <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de> <55683689.2090709@marino.st> <20150529122732.1396eb079ff9b404bcb21e40@elego.de> <5568421D.3050209@marino.st> <20150529155833.8454664b88391d93708e8f85@elego.de> <55687266.3090400@marino.st> <20150529162028.388911007a614006049beb42@elego.de> <20150529172305.a3fc2a9865b5250a5b9140fc@elego.de> Message-ID: <556885FD.6010800@marino.st> On 5/29/2015 17:23, Olaf Wagner wrote: > On Fri, 29 May 2015 16:20:28 +0200 > Olaf Wagner wrote: >> I'll try to reproduce the problem without the port makefile though. > > The bootstrap compiler backend doesn't run on my system: > > new exporters -> recompiling FSUtils.i3 > /libexec/ld-elf.so.1: /usr/ports/lang/modula3/work/bootstrap//bin/cm3cg: Undefined symbol "_ThreadRuneLocale" > m3_backend => 1 > m3cc (aka cm3cg) failed compiling: FSUtils.ic I didn't realize you meant you were going to try the bootstrap outside of the port. I knew that wouldn't work. As to "why", it's my fault. I built the bootstrap on FreeBSD 9, meaning it would work on 9 and new, but not 8. I should have built it on 8 but was tired of fooling with it by that point. > > It seems there's no way around a system upgrade. But that won't happen > today, sorry. > > I'll make a final test with an older bootstrap archive from opencm3.net > later. It might work -- as long as you have older gmp, mpfr, etc. I found the problem with those bootstrap is they were dynamically linked to libraries that don't exist anymore. John From rodney_bates at lcwb.coop Fri May 29 17:55:43 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Fri, 29 May 2015 10:55:43 -0500 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <55683689.2090709@marino.st> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop> <556817A1.2090206@marino.st> <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de> <55682D1A.2030504@marino.st> <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de> <55683689.2090709@marino.st> Message-ID: <55688BFF.5040701@lcwb.coop> I don't know yet why, or what needs to change, but here is definitely the problem, starting in line 4575 of your m3c log: g++48 -O2 -pipe -fstack-protector -Wl,-rpath=/usr/local/lib/gcc48 -fno-strict-aliasing -Wl,-rpath=/usr/local/lib/gcc48 -DIN_GCC -Wno-missing-field-initializers -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -o m3cgc1 m3cg/parse.o attribs.o main.o tree-browser.o libbackend.a libcommon-target.a libcommon.a ../libcpp/libcpp.a libcommon.a ../libcpp/libcpp.a ../libiberty/libiberty.a gmake[1]: Leaving directory `/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a/m3-sys/m3cc/AMD64_FREEBSD/gcc' This is copying the newly-built cm3cg (the compiler back end) to your bin directory: Forced ship of cm3cg. --- shipping from AMD64_FREEBSD --- . => /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin cm3cg ==> m3-sys/m3cc done === package m3-libs/m3core === And this is using the cm3 (compiler front end) that was already in the bin directory, and is the release version. +++ /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin/cm3 -build -DROOT='/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a' $RARGS && /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin/cm3 -ship $RARGS -DROOT='/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a' +++ --- building in AMD64_FREEBSD --- ignoring ../src/m3overrides new source -> compiling RTHooks.i3 This is cm3cg (aka m3cgc1) detecting the incompatibility: m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 compilation terminated. Here is the counterpart section of my log: g++ -g -O2 -DIN_GCC -Wno-missing-field-initializers -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -o m3cgc1 m3cg/parse.o attribs.o main.o tree-browser.o libbackend.a libcommon-target.a libcommon.a ../libcpp/libcpp.a libcommon.a ../libcpp/libcpp.a ../libiberty/libiberty.a On my build, it's not shipping: Not shipping cm3cg. --- shipping from AMD64_LINUX --- missing ".M3SHIP" file, build the package first. ==> /home/rodney/proj/m3/git/cm3/m3-sys/m3cc done === package /home/rodney/proj/m3/git/cm3/m3-libs/m3core === +++ cm3 -build -DROOT='/home/rodney/proj/m3/git/cm3' $RARGS && cm3 -ship $RARGS -DROOT='/home/rodney/proj/m3/git/cm3' +++ --- building in AMD64_LINUX --- ignoring ../src/m3overrides new source -> compiling RTHooks.i3 new source -> compiling RT0.i3 When it works, the copying of both cm3 and cm3cg to the bin directory is delayed until after both have been built, in the 'install-cm3-compiler.sh upgrade' step. I see your build is using a full path to the bin directory and mine is letting it come from the usual $PATH search, but that should make no difference, as long as the bin directory is found in a consistent way, which seems to be the case in both builds. On 05/29/2015 04:51 AM, John Marino wrote: > On 5/29/2015 11:39, Olaf Wagner wrote: >> On Fri, 29 May 2015 11:10:50 +0200 >> John Marino wrote: >> >>> On 5/29/2015 10:54, Olaf Wagner wrote: >>>> Please try what I suggested in the attached mail: define >>>> INSTALL_CM3_IN_BIN=yes >>>> in the environment and see if that helps. >>>> >>> >>> Unfortunately it seems the result is exactly the same, even when >>> INSTALL_CM3_IN_BIN is defined in the environment. >> >> Can I see the new logs? Has the new backend (cm3cg) been installed now? >> > > It's here: > http://leaf.dragonflybsd.org/~marino/m3c.log > > It never completes "do-cm3-front.sh buildship " > > Note that I'm using a bootstrap install and set INSTALL_ROOT to another > location, but it never gets to the point of installing anything. > > John > -- Rodney Bates rodney.m.bates at acm.org From adacore at marino.st Fri May 29 18:03:29 2015 From: adacore at marino.st (John Marino) Date: Fri, 29 May 2015 18:03:29 +0200 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <55688BFF.5040701@lcwb.coop> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop> <556817A1.2090206@marino.st> <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de> <55682D1A.2030504@marino.st> <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de> <55683689.2090709@marino.st> <55688BFF.5040701@lcwb.coop> Message-ID: <55688DD1.9070804@marino.st> On 5/29/2015 17:55, Rodney M. Bates wrote: > This is copying the newly-built cm3cg (the compiler back end) to your > bin directory: > > Forced ship of cm3cg. > --- shipping from AMD64_FREEBSD --- > > . => > /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin > cm3cg > ==> m3-sys/m3cc done Ok, I was expecting it to install at: /mech/construction/mech/ptrees/default/lang/modula3/work/intermediate/bin I was not trying to overwrite the bootstrap, but create a minimal new one that could build the whole thing (like I did before with boot-cm3-with-cm3) > This is cm3cg (aka m3cgc1) detecting the incompatibility: > > m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected > 0x110 > compilation terminated. Not surprising considering above... John From wagner at elego.de Fri May 29 18:02:23 2015 From: wagner at elego.de (Olaf Wagner) Date: Fri, 29 May 2015 18:02:23 +0200 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <556885FD.6010800@marino.st> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop> <556817A1.2090206@marino.st> <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de> <55682D1A.2030504@marino.st> <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de> <55683689.2090709@marino.st> <20150529122732.1396eb079ff9b404bcb21e40@elego.de> <5568421D.3050209@marino.st> <20150529155833.8454664b88391d93708e8f85@elego.de> <55687266.3090400@marino.st> <20150529162028.388911007a614006049beb42@elego.de> <20150529172305.a3fc2a9865b5250a5b9140fc@elego.de> <556885FD.6010800@marino.st> Message-ID: <20150529180223.d467621b68ebf665da685b12@elego.de> On Fri, 29 May 2015 17:30:05 +0200 John Marino wrote: > > I'll make a final test with an older bootstrap archive from opencm3.net > > later. > > It might work -- as long as you have older gmp, mpfr, etc. I found the > problem with those bootstrap is they were dynamically linked to > libraries that don't exist anymore. Surprisingly, that went very well without any problem :-) [...] Critical Mass Modula-3 version d5.10.0 last updated: 2015-05-21 compiled: 2015-05-29 15:50:50 configuration: /usr/ports/lang/modula3/work/bootstrap/bin/cm3.cfg host: AMD64_FREEBSD target: AMD64_FREEBSD Modula-3 backend (GCC) version 4.7.1 (x86_64-unknown-freebsd8.4) compiled by GNU C version 4.2.1 20070831 patched [FreeBSD], GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 create config directory /usr/ports/lang/modula3/work/bootstrap/bin/config new config files copied/generated in /usr/ports/lang/modula3/work/bootstrap/bin/cm3.cfg, /usr/ports/lang/modula3/work/bootstrap/bin/config Let's see what I have and did: % uname -a FreeBSD luthien.iceflower.in-berlin.de 8.4-STABLE FreeBSD 8.4-STABLE #0 r268069: Tue Jul 1 23:12:27 CEST 2014 root at luthien:/src/obj/src/sys/GENERIC amd64 Current Code Base form Github: % wget --no-check-certificate https://codeload.github.com/modula3/cm3/tar.gz Old CM3 5.8.6 archive from www.opencm3.net: % wget --no-check-certificate http://www.opencm3.net/releng/cm3-bin-core-AMD64_FREEBSD-5.8.6-REL.tgz I unpacked the system.tgz archive contained in the cm3-bin-core archive into a bootstrap directory and set some path: % echo $PATH /usr/ports/lang/modula3/work/bootstrap/bin:/home/wagner/bin:/usr/local/dcvs/bin:/usr/local/cm3/bin:/bin:/usr/bin:/usr/local/bin:/usr/contrib/bin:/usr/gnu/bin:/usr/X11R6/bin:/usr/local/sbin:/usr/sbin:/sbin:/sbin:/usr/sbin % echo $LD_LIBRARY_PATH /usr/ports/lang/modula3/work/bootstrap/lib I had to fake libgmp.so.8 by making a link to libgmp.so.10 for the old cm3cg: % sudo ln -s /usr/local/lib/libgmp.so /usr/local/lib/libgmp.so.8 % cd cm3-8c1b86a/ % ./scripts/upgrade.sh I didn't apply any patches. I can repeat everything and send you the log, or you could even get a login on that machine to have a look around. Let me know what you need. I hope this helps, Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From adacore at marino.st Fri May 29 18:14:29 2015 From: adacore at marino.st (John Marino) Date: Fri, 29 May 2015 18:14:29 +0200 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <20150529180223.d467621b68ebf665da685b12@elego.de> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop> <556817A1.2090206@marino.st> <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de> <55682D1A.2030504@marino.st> <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de> <55683689.2090709@marino.st> <20150529122732.1396eb079ff9b404bcb21e40@elego.de> <5568421D.3050209@marino.st> <20150529155833.8454664b88391d93708e8f85@elego.de> <55687266.3090400@marino.st> <20150529162028.388911007a614006049beb42@elego.de> <20150529172305.a3fc2a9865b5250a5b9140fc@elego.de> <556885FD.6010800@marino.st> <20150529180223.d467621b68ebf665da685b12@elego.de> Message-ID: <55689065.1040207@marino.st> On 5/29/2015 18:02, Olaf Wagner wrote: > On Fri, 29 May 2015 17:30:05 +0200 > John Marino wrote: > >>> I'll make a final test with an older bootstrap archive from opencm3.net >>> later. >> >> It might work -- as long as you have older gmp, mpfr, etc. I found the >> problem with those bootstrap is they were dynamically linked to >> libraries that don't exist anymore. > > Surprisingly, that went very well without any problem :-) I'm having a hard time understanding what went very well. I think you are saying you took an old bootstrap from an archive, and did Rodney's manual steps and it built without the errors I have. If so, that doesn't particularly help me unless I want to manually build another bootstrap. I have to get this thing building systematically without manual intervention or overwriting itself within a port's work area inside a clean jail. Probably my attempt isn't following Rodney's approach exactly, and maybe I have to overwrite the bootstrap rather than create an intermediate one. I'll be curious how this goes with the port and the current bootstrap (I'm trying to avoid having to generate a new 5.10 bootstrap when I feel it should be possible to use 5.8.6, but If I had to, I will) John From rodney_bates at lcwb.coop Fri May 29 18:35:41 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Fri, 29 May 2015 11:35:41 -0500 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <55688BFF.5040701@lcwb.coop> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop> <556817A1.2090206@marino.st> <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de> <55682D1A.2030504@marino.st> <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de> <55683689.2090709@marino.st> <55688BFF.5040701@lcwb.coop> Message-ID: <5568955D.4060200@lcwb.coop> Setting INSTALL_CM3_IN_BIN=yes is what forces the premature install of cm3cg. I see I had encountered this problem two years ago, but then it was happening regardless of the value of this variable. My fix only addresses the case when the variable is not set. I naively went to extra trouble to preserve the existing behavior when it is set--obviously not right. I don't see an easy way to make the variable work, as there is no constraint on the order that cm3 and cm3cg are built. do-cm3-front.sh happens to do cm3cg first, but that is not necessarily required. So INSTALL_CM3_IN_BIN is broken and hard to fix, if the two need compatible upgrades. For now, it looks like install-cm3-compiler.sh is the only working way. But maybe John and Olaf have found a different way around this. On 05/29/2015 10:55 AM, Rodney M. Bates wrote: > I don't know yet why, or what needs to change, but here is definitely the problem, starting > in line 4575 of your m3c log: > > > g++48 -O2 -pipe -fstack-protector -Wl,-rpath=/usr/local/lib/gcc48 -fno-strict-aliasing -Wl,-rpath=/usr/local/lib/gcc48 -DIN_GCC -Wno-missing-field-initializers -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -o m3cgc1 m3cg/parse.o attribs.o main.o tree-browser.o libbackend.a libcommon-target.a libcommon.a ../libcpp/libcpp.a libcommon.a ../libcpp/libcpp.a ../libiberty/libiberty.a > gmake[1]: Leaving directory `/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a/m3-sys/m3cc/AMD64_FREEBSD/gcc' > > > This is copying the newly-built cm3cg (the compiler back end) to your > bin directory: > > Forced ship of cm3cg. > --- shipping from AMD64_FREEBSD --- > > . => /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin > cm3cg > ==> m3-sys/m3cc done > > === package m3-libs/m3core === > > And this is using the cm3 (compiler front end) that was already in the bin > directory, and is the release version. > > +++ /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin/cm3 -build -DROOT='/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a' $RARGS && /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin/cm3 -ship $RARGS -DROOT='/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a' +++ > --- building in AMD64_FREEBSD --- > > ignoring ../src/m3overrides > > new source -> compiling RTHooks.i3 > > This is cm3cg (aka m3cgc1) detecting the incompatibility: > > m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > compilation terminated. > > Here is the counterpart section of my log: > > g++ -g -O2 -DIN_GCC -Wno-missing-field-initializers -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -o m3cgc1 m3cg/parse.o attribs.o main.o tree-browser.o libbackend.a libcommon-target.a libcommon.a ../libcpp/libcpp.a libcommon.a ../libcpp/libcpp.a ../libiberty/libiberty.a > > On my build, it's not shipping: > > Not shipping cm3cg. > --- shipping from AMD64_LINUX --- > > missing ".M3SHIP" file, build the package first. > ==> /home/rodney/proj/m3/git/cm3/m3-sys/m3cc done > > === package /home/rodney/proj/m3/git/cm3/m3-libs/m3core === > +++ cm3 -build -DROOT='/home/rodney/proj/m3/git/cm3' $RARGS && cm3 -ship $RARGS -DROOT='/home/rodney/proj/m3/git/cm3' +++ > --- building in AMD64_LINUX --- > > ignoring ../src/m3overrides > > new source -> compiling RTHooks.i3 > new source -> compiling RT0.i3 > > When it works, the copying of both cm3 and cm3cg to the bin directory is delayed until after both have been > built, in the 'install-cm3-compiler.sh upgrade' step. > > I see your build is using a full path to the bin directory and mine is letting > it come from the usual $PATH search, but that should make no difference, as long > as the bin directory is found in a consistent way, which seems to be the case > in both builds. > > > > On 05/29/2015 04:51 AM, John Marino wrote: >> On 5/29/2015 11:39, Olaf Wagner wrote: >>> On Fri, 29 May 2015 11:10:50 +0200 >>> John Marino wrote: >>> >>>> On 5/29/2015 10:54, Olaf Wagner wrote: >>>>> Please try what I suggested in the attached mail: define >>>>> INSTALL_CM3_IN_BIN=yes >>>>> in the environment and see if that helps. >>>>> >>>> >>>> Unfortunately it seems the result is exactly the same, even when >>>> INSTALL_CM3_IN_BIN is defined in the environment. >>> >>> Can I see the new logs? Has the new backend (cm3cg) been installed now? >>> >> >> It's here: >> http://leaf.dragonflybsd.org/~marino/m3c.log >> >> It never completes "do-cm3-front.sh buildship " >> >> Note that I'm using a bootstrap install and set INSTALL_ROOT to another >> location, but it never gets to the point of installing anything. >> >> John >> > -- Rodney Bates rodney.m.bates at acm.org From jay.krell at cornell.edu Fri May 29 20:03:10 2015 From: jay.krell at cornell.edu (Jay K) Date: Fri, 29 May 2015 18:03:10 +0000 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <556885FD.6010800@marino.st> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop> <556817A1.2090206@marino.st> <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de> <55682D1A.2030504@marino.st> <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de> <55683689.2090709@marino.st> <20150529122732.1396eb079ff9b404bcb21e40@elego.de> <5568421D.3050209@marino.st> <20150529155833.8454664b88391d93708e8f85@elego.de> <55687266.3090400@marino.st> <20150529162028.388911007a614006049beb42@elego.de>, <20150529172305.a3fc2a9865b5250a5b9140fc@elego.de>, <556885FD.6010800@marino.st> Message-ID: > It might work -- as long as you have older gmp, mpfr, etc. I found the > problem with those bootstrap is they were dynamically linked to > libraries that don't exist anymore. We went far out of our way to statically link this. Darn. > > /libexec/ld-elf.so.1: /usr/ports/lang/modula3/work/bootstrap//bin/cm3cg: Undefined symbol "_ThreadRuneLocale" _ThreadRuneLocale --- we should look into.Ideally we can build on newer systems and still target older systems.That is very commonly done on Mac and Windows, at least.Maybe there are #defines or config to suppress unused newer stuff? I also went out of my way to suppress dynamic links to libiconv.That has been a problem e.g. on Solaris.It was coming in I believe because cm3cg linked in a C preprocessor (seriously),because you know, like, all gcc frontends can use that.. (and the cm3cg backend again,is a gcc frontend, for an unusual binary-encoded language).. - Jay [snip] -------------- next part -------------- An HTML attachment was scrubbed... URL: From adacore at marino.st Fri May 29 20:10:35 2015 From: adacore at marino.st (John Marino) Date: Fri, 29 May 2015 20:10:35 +0200 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop> <556817A1.2090206@marino.st> <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de> <55682D1A.2030504@marino.st> <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de> <55683689.2090709@marino.st> <20150529122732.1396eb079ff9b404bcb21e40@elego.de> <5568421D.3050209@marino.st> <20150529155833.8454664b88391d93708e8f85@elego.de> <55687266.3090400@marino.st> <20150529162028.388911007a614006049beb42@elego.de>, <20150529172305.a3fc2a9865b5250a5b9140fc@elego.de>, <556885FD.6010800@marino.st> Message-ID: <5568AB9B.3010101@marino.st> On 5/29/2015 20:03, Jay K wrote: > > > It might work -- as long as you have older gmp, mpfr, etc. I found the > > problem with those bootstrap is they were dynamically linked to > > libraries that don't exist anymore. > > > We went far out of our way to statically link this. Darn. It is okay, the port M3 bootstrap is statically linked. > _ThreadRuneLocale --- we should look into. > Ideally we can build on newer systems and still target older systems. > That is very commonly done on Mac and Windows, at least. > Maybe there are #defines or config to suppress unused newer stuff? This was 100% my fault. The bootstrap was built on FreeBSD 9. I should have built it on FreeBSD 8, but I didn't know the impact. If I had done that, you wouldn't be seeing this error. FreeBSD 8 "expires" at the end of June, so it's a non-issue really. John From wagner at elegosoft.com Fri May 29 20:11:24 2015 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 29 May 2015 20:11:24 +0200 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <5568955D.4060200@lcwb.coop> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop> <556817A1.2090206@marino.st> <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de> <55682D1A.2030504@marino.st> <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de> <55683689.2090709@marino.st> <55688BFF.5040701@lcwb.coop> <5568955D.4060200@lcwb.coop> Message-ID: <20150529201124.fd4b2bc6b239df2a7a97cc19@elegosoft.com> On Fri, 29 May 2015 11:35:41 -0500 "Rodney M. Bates" wrote: > Setting INSTALL_CM3_IN_BIN=yes is what forces the premature install of cm3cg. > I see I had encountered this problem two years ago, but then it was happening > regardless of the value of this variable. My fix only addresses the case when > the variable is not set. I naively went to extra trouble to preserve the > existing behavior when it is set--obviously not right. > > I don't see an easy way to make the variable work, as there is no > constraint on the order that cm3 and cm3cg are built. do-cm3-front.sh > happens to do cm3cg first, but that is not necessarily required. > > So INSTALL_CM3_IN_BIN is broken and hard to fix, if the two need > compatible upgrades. For now, it looks like install-cm3-compiler.sh > is the only working way. > > But maybe John and Olaf have found a different way around this. Setting that to yes was just my suggestion after seeing in the first log that he did install cm3 but not cm3cg. I think we should all forget about INSTALL_CM3_IN_BIN now and leave that unset. I still don't undertstand what he's doing differently than a simple upgrade of the compiler based on an initial install, which does work for AMD64_FREEBSD, as I have tested it. I think it's the elaborate setup and build environment into which the rather inflexible cm3 installation is forced. Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Fri May 29 20:06:11 2015 From: jay.krell at cornell.edu (Jay K) Date: Fri, 29 May 2015 18:06:11 +0000 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <5568955D.4060200@lcwb.coop> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop> <556817A1.2090206@marino.st> <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de> <55682D1A.2030504@marino.st> <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de> <55683689.2090709@marino.st>, <55688BFF.5040701@lcwb.coop>, <5568955D.4060200@lcwb.coop> Message-ID: > I don't see an easy way to make the variable work, as there is no > constraint on the order that cm3 and cm3cg are built. do-cm3-front.sh > happens to do cm3cg first, but that is not necessarily required. [please pardon my editing...] I see what you mean that cm3cg is an independent node in the graph and can be built in any order,but, I guess, the story is/was, you have to know the safe order to ship things. It is encoded in pkginfo.txt and the Python scripts honor it..though they don't always use pkginfo.txt for their ordering..And encoding the dependency graph there isn't ideal. It is really encoded in the import declarationsin the m3makefiles, usually, but not in this case... The way that works is to build but don't ship cm3cg. Then ship cm3cg. Then copy cm3. Then use the new cm3. But perhaps it isn't strictly enforced enough. I used do this fairly often. Though breaking changes in cm3cg were rare, granted. But I'd also occasionally bootstrap from an older release. I'll have to try to do that again soon -- actually make the current tree easily buildable from the last release. update.py handled it. I'm on the fence. "buildship" of multiple packages is in general problematic. I kinda think the whole mechanism needs to be revampled. Let me draw a close analogy. In the slightly larger software world we have: make make install make install DESTDIR=somewhere_new buildship is equivalent make && make install, or a make install that includes the make part, as they sometimes do. Read up on building glibc and they point out how dangerous this is -- how dangerous make install is w/o DESTDIR. We have the same danger on a smaller scale. You aren't going to break the "OS", but you can break "cm3". The safe recommendation is make install DESTDIR. Basically "install" "everything" "on the side", get it all installed, multiple "packages", then copy or tar/untar it all. Or chroot into it and test it out, and then do an in-place update. Or swap into the chroot and never return? (tail call install) Don't do a "rolling upgrade". Don't install each package as it is built. No package, no cm3, not cm3cg, nothing. I'm basically suggesting that. Now, if you say "don't ever ship, but somehow otherwise manually copy", well that does kind of resolve to the same thing. If you say, "almost don't ever ship, but provide a way to", that is almost the same. make-dist.py follows the make install DESTDIR way. It is "better" I guess because I wrote it later, and because I was following the example of the other .sh files that make distributions. So blame/credit Olaf? :) It starts with a working compiler, copies parts into /temp, builds a new compiler into /tmp, and uses what it builds to build everything. Again I suggest it be looked into, and maybe be promoted as basically the replacement for upgrade.py and upgrade.sh. upgrade.py could wrap it and do the final steps of copy/untar in-place. Or make-dist.py could just print the last optional command. Anyway, I have no time lately, just email. :( - Jay > Date: Fri, 29 May 2015 11:35:41 -0500 > From: rodney_bates at lcwb.coop > To: adacore at marino.st; wagner at elego.de > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > > Setting INSTALL_CM3_IN_BIN=yes is what forces the premature install of cm3cg. > I see I had encountered this problem two years ago, but then it was happening > regardless of the value of this variable. My fix only addresses the case when > the variable is not set. I naively went to extra trouble to preserve the > existing behavior when it is set--obviously not right. > > I don't see an easy way to make the variable work, as there is no > constraint on the order that cm3 and cm3cg are built. do-cm3-front.sh > happens to do cm3cg first, but that is not necessarily required. > > So INSTALL_CM3_IN_BIN is broken and hard to fix, if the two need > compatible upgrades. For now, it looks like install-cm3-compiler.sh > is the only working way. > > But maybe John and Olaf have found a different way around this. > > On 05/29/2015 10:55 AM, Rodney M. Bates wrote: > > I don't know yet why, or what needs to change, but here is definitely the problem, starting > > in line 4575 of your m3c log: > > > > > > g++48 -O2 -pipe -fstack-protector -Wl,-rpath=/usr/local/lib/gcc48 -fno-strict-aliasing -Wl,-rpath=/usr/local/lib/gcc48 -DIN_GCC -Wno-missing-field-initializers -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -o m3cgc1 m3cg/parse.o attribs.o main.o tree-browser.o libbackend.a libcommon-target.a libcommon.a ../libcpp/libcpp.a libcommon.a ../libcpp/libcpp.a ../libiberty/libiberty.a > > gmake[1]: Leaving directory `/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a/m3-sys/m3cc/AMD64_FREEBSD/gcc' > > > > > > This is copying the newly-built cm3cg (the compiler back end) to your > > bin directory: > > > > Forced ship of cm3cg. > > --- shipping from AMD64_FREEBSD --- > > > > . => /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin > > cm3cg > > ==> m3-sys/m3cc done > > > > === package m3-libs/m3core === > > > > And this is using the cm3 (compiler front end) that was already in the bin > > directory, and is the release version. > > > > +++ /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin/cm3 -build -DROOT='/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a' $RARGS && /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin/cm3 -ship $RARGS -DROOT='/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a' +++ > > --- building in AMD64_FREEBSD --- > > > > ignoring ../src/m3overrides > > > > new source -> compiling RTHooks.i3 > > > > This is cm3cg (aka m3cgc1) detecting the incompatibility: > > > > m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > > compilation terminated. > > > > Here is the counterpart section of my log: > > > > g++ -g -O2 -DIN_GCC -Wno-missing-field-initializers -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -o m3cgc1 m3cg/parse.o attribs.o main.o tree-browser.o libbackend.a libcommon-target.a libcommon.a ../libcpp/libcpp.a libcommon.a ../libcpp/libcpp.a ../libiberty/libiberty.a > > > > On my build, it's not shipping: > > > > Not shipping cm3cg. > > --- shipping from AMD64_LINUX --- > > > > missing ".M3SHIP" file, build the package first. > > ==> /home/rodney/proj/m3/git/cm3/m3-sys/m3cc done > > > > === package /home/rodney/proj/m3/git/cm3/m3-libs/m3core === > > +++ cm3 -build -DROOT='/home/rodney/proj/m3/git/cm3' $RARGS && cm3 -ship $RARGS -DROOT='/home/rodney/proj/m3/git/cm3' +++ > > --- building in AMD64_LINUX --- > > > > ignoring ../src/m3overrides > > > > new source -> compiling RTHooks.i3 > > new source -> compiling RT0.i3 > > > > When it works, the copying of both cm3 and cm3cg to the bin directory is delayed until after both have been > > built, in the 'install-cm3-compiler.sh upgrade' step. > > > > I see your build is using a full path to the bin directory and mine is letting > > it come from the usual $PATH search, but that should make no difference, as long > > as the bin directory is found in a consistent way, which seems to be the case > > in both builds. > > > > > > > > On 05/29/2015 04:51 AM, John Marino wrote: > >> On 5/29/2015 11:39, Olaf Wagner wrote: > >>> On Fri, 29 May 2015 11:10:50 +0200 > >>> John Marino wrote: > >>> > >>>> On 5/29/2015 10:54, Olaf Wagner wrote: > >>>>> Please try what I suggested in the attached mail: define > >>>>> INSTALL_CM3_IN_BIN=yes > >>>>> in the environment and see if that helps. > >>>>> > >>>> > >>>> Unfortunately it seems the result is exactly the same, even when > >>>> INSTALL_CM3_IN_BIN is defined in the environment. > >>> > >>> Can I see the new logs? Has the new backend (cm3cg) been installed now? > >>> > >> > >> It's here: > >> http://leaf.dragonflybsd.org/~marino/m3c.log > >> > >> It never completes "do-cm3-front.sh buildship " > >> > >> Note that I'm using a bootstrap install and set INSTALL_ROOT to another > >> location, but it never gets to the point of installing anything. > >> > >> John > >> > > > > -- > Rodney Bates > rodney.m.bates at acm.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Fri May 29 20:15:31 2015 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 29 May 2015 20:15:31 +0200 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <55689065.1040207@marino.st> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop> <556817A1.2090206@marino.st> <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de> <55682D1A.2030504@marino.st> <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de> <55683689.2090709@marino.st> <20150529122732.1396eb079ff9b404bcb21e40@elego.de> <5568421D.3050209@marino.st> <20150529155833.8454664b88391d93708e8f85@elego.de> <55687266.3090400@marino.st> <20150529162028.388911007a614006049beb42@elego.de> <20150529172305.a3fc2a9865b5250a5b9140fc@elego.de> <556885FD.6010800@marino.st> <20150529180223.d467621b68ebf665da685b12@elego.de> <55689065.1040207@marino.st> Message-ID: <20150529201531.b35e3cfdafeb9e2735e0020b@elegosoft.com> On Fri, 29 May 2015 18:14:29 +0200 John Marino wrote: > On 5/29/2015 18:02, Olaf Wagner wrote: > > On Fri, 29 May 2015 17:30:05 +0200 > > John Marino wrote: > > > >>> I'll make a final test with an older bootstrap archive from opencm3.net > >>> later. > >> > >> It might work -- as long as you have older gmp, mpfr, etc. I found the > >> problem with those bootstrap is they were dynamically linked to > >> libraries that don't exist anymore. > > > > Surprisingly, that went very well without any problem :-) > > I'm having a hard time understanding what went very well. I think you > are saying you took an old bootstrap from an archive, and did Rodney's > manual steps and it built without the errors I have. > > If so, that doesn't particularly help me unless I want to manually build > another bootstrap. I have to get this thing building systematically > without manual intervention or overwriting itself within a port's work > area inside a clean jail. > > Probably my attempt isn't following Rodney's approach exactly, and maybe > I have to overwrite the bootstrap rather than create an intermediate one. > > I'll be curious how this goes with the port and the current bootstrap > (I'm trying to avoid having to generate a new 5.10 bootstrap when I feel > it should be possible to use 5.8.6, but If I had to, I will) Well, yes, I understand that. I would have tried your exact setup, but I have no system available to test that on. At least I have validated that based on the origianl 5.8.6 installation archive for AMD64_FREEBSD you can build the new compiler from the current sources with a simple call of the upgrade.sh script. which I still doubted yesterday. Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From adacore at marino.st Fri May 29 20:43:30 2015 From: adacore at marino.st (John Marino) Date: Fri, 29 May 2015 20:43:30 +0200 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <20150529201531.b35e3cfdafeb9e2735e0020b@elegosoft.com> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop> <556817A1.2090206@marino.st> <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de> <55682D1A.2030504@marino.st> <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de> <55683689.2090709@marino.st> <20150529122732.1396eb079ff9b404bcb21e40@elego.de> <5568421D.3050209@marino.st> <20150529155833.8454664b88391d93708e8f85@elego.de> <55687266.3090400@marino.st> <20150529162028.388911007a614006049beb42@elego.de> <20150529172305.a3fc2a9865b5250a5b9140fc@elego.de> <556885FD.6010800@marino.st> <20150529180223.d467621b68ebf665da685b12@elego.de> <55689065.1040207@marino.st> <20150529201531.b35e3cfdafeb9e2735e0020b@elegosoft.com> Message-ID: <5568B352.8060005@marino.st> On 5/29/2015 20:15, Olaf Wagner wrote: > > Well, yes, I understand that. I would have tried your exact setup, > but I have no system available to test that on. > > At least I have validated that based on the origianl 5.8.6 installation > archive for AMD64_FREEBSD you can build the new compiler from the current > sources with a simple call of the upgrade.sh script. which I still doubted > yesterday. The card I still have left to play is to extract the bootstrap, let it overwrite itself per Rodney's technique and then build the real compiler (dumping the whole "intermediate" area). I would try that now but I've booted into another OS to work on some GCC patches that are long overdue to be submitted. John From estellnb at elstel.org Fri May 29 21:00:44 2015 From: estellnb at elstel.org (Elmar Stellnberger) Date: Fri, 29 May 2015 21:00:44 +0200 Subject: [M3devel] WeakRef.T does not clean all WeakRefs on prorgam exit Message-ID: <5568B75C.4010202@elstel.org> Today I was writing an object oriented interface to some external library. As every object holds at least a reference to an embedded C-heap object I wanted to make use of WeakRefs to get an automatic cleanup for the embedded C-heap objects. However I had to notice that no cleanup occurs and that the reference can still be reconstructed from the WeakRef even after assigning NULL and running the garbage collector by calling two times RTCollectorSRC.StartCollection & FinishCollection in sequence. I have further tried to disable incremental and generational collection and to set the gcRatio to 100.0 as well as moving the RefAny into a subprocedure but all of it did not help either. There is only one Refany in my program and thus no cyclic dependency. Does anyone have a suggestion on how I could make the automatic cleanup work ready for testing it (appart from calling the cleanup proc directly)? From the past I know the WeakRef implementation of PM3 to some extent: there was no special cleanup on program exit. I believe on program exit all WeakRefs should be freed in order to let the operating system reclaim all resources. Under Linux that should work automatically though some resources like sockets may last long until they become available again. Other OSes like the eComstation can not reclaim all resources when it comes f.i. to shared memory. Anyone here who believes that special cleanup for WeakRefs should be done on program exit? ... and one more question about how to handle WeakRefs? Do I need to keep the WeakRef-record after installing the cleanup proc with WeakRef.FromRef(...)? - or may I simply discard it while the cleanup should still be done without it? From estellnb at elstel.org Fri May 29 21:13:38 2015 From: estellnb at elstel.org (Elmar Stellnberger) Date: Fri, 29 May 2015 21:13:38 +0200 Subject: [M3devel] WeakRef.T does not clean all WeakRefs on prorgam exit Message-ID: <5568BA62.9070109@elstel.org> Today I was writing an object oriented interface to some external library. As every object holds at least a reference to an embedded C-heap object I wanted to make use of WeakRefs to get an automatic cleanup for the embedded C-heap objects. However I had to notice that no cleanup occurs and that the reference can still be reconstructed from the WeakRef even after assigning NULL and running the garbage collector by calling two times RTCollectorSRC.StartCollection & FinishCollection in sequence. I have further tried to disable incremental and generational collection and to set the gcRatio to 100.0 as well as moving the RefAny into a subprocedure but all of it did not help either. There is only one Refany in my program and thus no cyclic dependency. Does anyone have a suggestion on how I could make the automatic cleanup work ready for testing it (appart from calling the cleanup proc directly)? From the past I know the WeakRef implementation of PM3 to some extent: there was no special cleanup on program exit. I believe on program exit all WeakRefs should be freed in order to let the operating system reclaim all resources. Under Linux that should work automatically though some resources like sockets may last long until they become available again. Other OSes like the eComstation can not reclaim all resources when it comes f.i. to shared memory. Anyone here who believes that special cleanup for WeakRefs should be done on program exit? ... and one more question about how to handle WeakRefs? Do I need to keep the WeakRef-record after installing the cleanup proc with WeakRef.FromRef(...)? - or may I simply discard it while the cleanup should still be done without it? From jay.krell at cornell.edu Fri May 29 22:49:30 2015 From: jay.krell at cornell.edu (Jay K) Date: Fri, 29 May 2015 20:49:30 +0000 Subject: [M3devel] WeakRef.T does not clean all WeakRefs on prorgam exit In-Reply-To: <5568BA62.9070109@elstel.org> References: <5568BA62.9070109@elstel.org> Message-ID: Imho you should take this approach: If you are only managing memory and file handles and socket handles, or Win32 kernel handles (events/mutexes/semaphores/registry keys), you should just rely on the kernel cleaning everything up when the process dies. Doing everything peacemeal is just a waste of time. Imagine that there is a null deref and you abruptly go away.That shouldn't/doesn't leak either.And attempting to cleanup in this path is dangerous. In fact, any resource that you want to guaranteeably be cleaned up, should be backed by the kernel. If you are talking over the network to something, and you abruptly exit, that network server will eventually notice a timeout and clean up anything it has allocated on your behalf. Now, on the other hand, if your .dll is gracefull unloaded and the processis still running, that is another matter, and one I suspect we don't handle.I'm not sure we really handle .dll/.sos in Modula-3 w/o the main executable being Modula-3.That could use repair.On Windows it is a matter of writing DllMain in m3core.Likely something similar on the other systems. Heck, maybe just a C++ static with a constructor and destructor.That is kinda the portable interface to DllMain(process attach) and whatever are the Unix analogs.Seriously. Just as we have main optionally in C. Agreed? Thread notifications would also be nice. This is an area that hasn't evolved as well as process notification. - Jay > Date: Fri, 29 May 2015 21:13:38 +0200 > From: estellnb at elstel.org > To: m3devel at elegosoft.com > Subject: [M3devel] WeakRef.T does not clean all WeakRefs on prorgam exit > > Today I was writing an object oriented interface to some external > library. > As every object holds at least a reference to an embedded C-heap object I > wanted to make use of WeakRefs to get an automatic cleanup for the > embedded C-heap objects. However I had to notice that no cleanup occurs > and that the reference can still be reconstructed from the WeakRef even > after assigning NULL and running the garbage collector by calling two times > RTCollectorSRC.StartCollection & FinishCollection in sequence. I have > further tried to disable incremental and generational collection and to set > the gcRatio to 100.0 as well as moving the RefAny into a subprocedure > but all of it did not help either. There is only one Refany in my program > and thus no cyclic dependency. > Does anyone have a suggestion on how I could make the automatic > cleanup work ready for testing it (appart from calling the cleanup proc > directly)? > From the past I know the WeakRef implementation of PM3 to some extent: > there was no special cleanup on program exit. I believe on program exit > all WeakRefs should be freed in order to let the operating system reclaim > all resources. Under Linux that should work automatically though some > resources like sockets may last long until they become available again. > Other OSes like the eComstation can not reclaim all resources when it > comes f.i. to shared memory. > Anyone here who believes that special cleanup for WeakRefs should be > done on program exit? > > ... and one more question about how to handle WeakRefs? > Do I need to keep the WeakRef-record after installing the cleanup proc > with WeakRef.FromRef(...)? - or may I simply discard it while the cleanup > should still be done without it? > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Fri May 29 23:10:41 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Fri, 29 May 2015 16:10:41 -0500 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop> <556817A1.2090206@marino.st> <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de> <55682D1A.2030504@marino.st> <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de> <55683689.2090709@marino.st>, <55688BFF.5040701@lcwb.coop>, <5568955D.4060200@lcwb.coop> Message-ID: <5568D5D1.5040405@lcwb.coop> Yes, we could have a better organization. I agree, the principal way should be to build a complete set of everything that matters to the implementation of the language, them replace them all at once. A separate DESTDIR or such is needed. The set, as Jay points out, is larger than just cm3 and m3cc. It includes at least m3core, probably libm3, and cm3, the executable depends on several separately built packages--cm3, m3middle, m3front, m3quake, m3makefile, etc. In general, we can't really assume anything about the kinds of dependencies of one package on old or new versions of another. Right now, cm3 and m3cc are known mutually incompatible between 5.8 and the head, because the numbering in M3CG_Binary.i3 has changed. We could probably establish some coding rules and order-of-install rules that would allow a newer m3cc to work with an older cm3, but that's only one pattern. I once thought do-cm3-*.sh build would do what we are talking about, but it if I remember right, puts every package into immediate use as it is built and also uses overrides, which keeps things inside the source tree, but makes it unshippable. So I always use buildship. This has never, to my knowledge run afoul of any compatibility problem other than between cm3 and m3cc, but it does ship every package besides these two as it is built, so the potential is there. I haven't had the energy to even try to understand just what the upgrade scripts do, but they have not treated me well. If I had done different patterns of incompatible changes, they would probably have been better than the procedure I use. On 05/29/2015 01:06 PM, Jay K wrote: > > I don't see an easy way to make the variable work, as there is no > > constraint on the order that cm3 and cm3cg are built. do-cm3-front.sh > > happens to do cm3cg first, but that is not necessarily required. > > [please pardon my editing...] > > > I see what you mean that cm3cg is an independent node in the graph and can be built in any order, > but, I guess, the story is/was, you have to know the safe order to ship things. > > > It is encoded in pkginfo.txt and the Python scripts honor it..though they don't always use pkginfo.txt for their ordering.. > And encoding the dependency graph there isn't ideal. It is really encoded in the import declarations > in the m3makefiles, usually, but not in this case... > > > The way that works is to build but don't ship cm3cg. > Then ship cm3cg. > Then copy cm3. > Then use the new cm3. > But perhaps it isn't strictly enforced enough. > > > > I used do this fairly often. > Though breaking changes in cm3cg were rare, granted. > But I'd also occasionally bootstrap from an older release. > I'll have to try to do that again soon -- actually make the current > tree easily buildable from the last release. > > > update.py handled it. > > > I'm on the fence. > "buildship" of multiple packages is in general problematic. > I kinda think the whole mechanism needs to be revampled. > > > Let me draw a close analogy. > > > In the slightly larger software world we have: > > make > make install > make install DESTDIR=somewhere_new > > > buildship is equivalent make && make install, or a make install that includes the make part, > as they sometimes do. > Read up on building glibc and they point out how dangerous this is -- how dangerous make install is w/o DESTDIR. > We have the same danger on a smaller scale. > You aren't going to break the "OS", but you can break "cm3". > > > The safe recommendation is make install DESTDIR. > Basically "install" "everything" "on the side", get it all installed, multiple > "packages", then copy or tar/untar it all. Or chroot into it and test it out, and > then do an in-place update. Or swap into the chroot and never return? (tail call install) > > > Don't do a "rolling upgrade". Don't install each package as it is built. No package, no cm3, > not cm3cg, nothing. > > > I'm basically suggesting that. > > > Now, if you say "don't ever ship, but somehow otherwise manually copy", well > that does kind of resolve to the same thing. > > > If you say, "almost don't ever ship, but provide a way to", that is almost the same. > > > make-dist.py follows the make install DESTDIR way. > > It is "better" I guess because I wrote it later, and because I was following > the example of the other .sh files that make distributions. So blame/credit Olaf? :) > > > It starts with a working compiler, copies parts into /temp, builds a new compiler into /tmp, and > uses what it builds to build everything. > > > Again I suggest it be looked into, and maybe be promoted as basically > the replacement for upgrade.py and upgrade.sh. > > > upgrade.py could wrap it and do the final steps of copy/untar in-place. > Or make-dist.py could just print the last optional command. > > > Anyway, I have no time lately, just email. :( > > > - Jay > > > > > Date: Fri, 29 May 2015 11:35:41 -0500 > > From: rodney_bates at lcwb.coop > > To: adacore at marino.st; wagner at elego.de > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > > > > Setting INSTALL_CM3_IN_BIN=yes is what forces the premature install of cm3cg. > > I see I had encountered this problem two years ago, but then it was happening > > regardless of the value of this variable. My fix only addresses the case when > > the variable is not set. I naively went to extra trouble to preserve the > > existing behavior when it is set--obviously not right. > > > > I don't see an easy way to make the variable work, as there is no > > constraint on the order that cm3 and cm3cg are built. do-cm3-front.sh > > happens to do cm3cg first, but that is not necessarily required. > > > > So INSTALL_CM3_IN_BIN is broken and hard to fix, if the two need > > compatible upgrades. For now, it looks like install-cm3-compiler.sh > > is the only working way. > > > > But maybe John and Olaf have found a different way around this. > > > > On 05/29/2015 10:55 AM, Rodney M. Bates wrote: > > > I don't know yet why, or what needs to change, but here is definitely the problem, starting > > > in line 4575 of your m3c log: > > > > > > > > > g++48 -O2 -pipe -fstack-protector -Wl,-rpath=/usr/local/lib/gcc48 -fno-strict-aliasing -Wl,-rpath=/usr/local/lib/gcc48 -DIN_GCC -Wno-missing-field-initializers -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -o m3cgc1 m3cg/parse.o attribs.o main.o tree-browser.o libbackend.a libcommon-target.a libcommon.a ../libcpp/libcpp.a libcommon.a ../libcpp/libcpp.a ../libiberty/libiberty.a > > > gmake[1]: Leaving directory `/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a/m3-sys/m3cc/AMD64_FREEBSD/gcc' > > > > > > > > > This is copying the newly-built cm3cg (the compiler back end) to your > > > bin directory: > > > > > > Forced ship of cm3cg. > > > --- shipping from AMD64_FREEBSD --- > > > > > > . => /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin > > > cm3cg > > > ==> m3-sys/m3cc done > > > > > > === package m3-libs/m3core === > > > > > > And this is using the cm3 (compiler front end) that was already in the bin > > > directory, and is the release version. > > > > > > +++ /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin/cm3 -build -DROOT='/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a' $RARGS && /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin/cm3 -ship $RARGS -DROOT='/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a' +++ > > > --- building in AMD64_FREEBSD --- > > > > > > ignoring ../src/m3overrides > > > > > > new source -> compiling RTHooks.i3 > > > > > > This is cm3cg (aka m3cgc1) detecting the incompatibility: > > > > > > m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > > > compilation terminated. > > > > > > Here is the counterpart section of my log: > > > > > > g++ -g -O2 -DIN_GCC -Wno-missing-field-initializers -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -o m3cgc1 m3cg/parse.o attribs.o main.o tree-browser.o libbackend.a libcommon-target.a libcommon.a ../libcpp/libcpp.a libcommon.a ../libcpp/libcpp.a ../libiberty/libiberty.a > > > > > > On my build, it's not shipping: > > > > > > Not shipping cm3cg. > > > --- shipping from AMD64_LINUX --- > > > > > > missing ".M3SHIP" file, build the package first. > > > ==> /home/rodney/proj/m3/git/cm3/m3-sys/m3cc done > > > > > > === package /home/rodney/proj/m3/git/cm3/m3-libs/m3core === > > > +++ cm3 -build -DROOT='/home/rodney/proj/m3/git/cm3' $RARGS && cm3 -ship $RARGS -DROOT='/home/rodney/proj/m3/git/cm3' +++ > > > --- building in AMD64_LINUX --- > > > > > > ignoring ../src/m3overrides > > > > > > new source -> compiling RTHooks.i3 > > > new source -> compiling RT0.i3 > > > > > > When it works, the copying of both cm3 and cm3cg to the bin directory is delayed until after both have been > > > built, in the 'install-cm3-compiler.sh upgrade' step. > > > > > > I see your build is using a full path to the bin directory and mine is letting > > > it come from the usual $PATH search, but that should make no difference, as long > > > as the bin directory is found in a consistent way, which seems to be the case > > > in both builds. > > > > > > > > > > > > On 05/29/2015 04:51 AM, John Marino wrote: > > >> On 5/29/2015 11:39, Olaf Wagner wrote: > > >>> On Fri, 29 May 2015 11:10:50 +0200 > > >>> John Marino wrote: > > >>> > > >>>> On 5/29/2015 10:54, Olaf Wagner wrote: > > >>>>> Please try what I suggested in the attached mail: define > > >>>>> INSTALL_CM3_IN_BIN=yes > > >>>>> in the environment and see if that helps. > > >>>>> > > >>>> > > >>>> Unfortunately it seems the result is exactly the same, even when > > >>>> INSTALL_CM3_IN_BIN is defined in the environment. > > >>> > > >>> Can I see the new logs? Has the new backend (cm3cg) been installed now? > > >>> > > >> > > >> It's here: > > >> http://leaf.dragonflybsd.org/~marino/m3c.log > > >> > > >> It never completes "do-cm3-front.sh buildship " > > >> > > >> Note that I'm using a bootstrap install and set INSTALL_ROOT to another > > >> location, but it never gets to the point of installing anything. > > >> > > >> John > > >> > > > > > > > -- > > Rodney Bates > > rodney.m.bates at acm.org -- Rodney Bates rodney.m.bates at acm.org From jay.krell at cornell.edu Sat May 30 00:31:50 2015 From: jay.krell at cornell.edu (Jay K) Date: Fri, 29 May 2015 22:31:50 +0000 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <5568D5D1.5040405@lcwb.coop> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop> <556817A1.2090206@marino.st> <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de> <55682D1A.2030504@marino.st> <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de> <55683689.2090709@marino.st>,,<55688BFF.5040701@lcwb.coop>, <5568955D.4060200@lcwb.coop>, , <5568D5D1.5040405@lcwb.coop> Message-ID: cm3/cm3cg are more special than the others, because cm3 is statically linked. There is no m3core.dll, that cm3 uses, or m3quake.dll, etc. There is m3core.dll, but cm3 doesn't uses it. Shipping it doesn't affect the in-use cm3. If/when we fix this, in fact, we can stop doing that static linking. It makes sense for m3quake, etc. as there are few/no other users. But for libm3/m3core, it'll provide a nice size optimization. The mutual incompatibilty between old/new cm3/cm3cg is perfectly ok. It is meant to be dealt with, not avoided. I believe upgrade.py did deal with this correctly, but this environment variable required to quash shipping of cm3cg broke it. The environment variable change really should imho be removed from cm3cg. Please. And then we can switch to "destdir" and remove all the in place updating, perhaps. Or I need to update upgrade.py to ship cm3cg itself. I guess I'll do that. upgrade.py may not have worked for you, but I have used it many many times.It worked. But currently it is probably broken by the m3cc/src/m3makefile change.I'll update it to accommodate that change.. And upgrade.sh I believe was in heavy use by Hudson. - Jay > Date: Fri, 29 May 2015 16:10:41 -0500 > From: rodney_bates at lcwb.coop > CC: m3devel at elegosoft.com > To: > Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > > Yes, we could have a better organization. I agree, the principal way > should be to build a complete set of everything that matters to the > implementation of the language, them replace them all at once. A > separate DESTDIR or such is needed. > > The set, as Jay points out, is larger than just cm3 and m3cc. It includes > at least m3core, probably libm3, and cm3, the executable depends on several > separately built packages--cm3, m3middle, m3front, m3quake, m3makefile, etc. > > In general, we can't really assume anything about the kinds of dependencies > of one package on old or new versions of another. Right now, cm3 and m3cc > are known mutually incompatible between 5.8 and the head, because the numbering > in M3CG_Binary.i3 has changed. We could probably establish some coding rules and > order-of-install rules that would allow a newer m3cc to work with an older cm3, > but that's only one pattern. > > I once thought do-cm3-*.sh build would do what we are talking about, but it > if I remember right, puts every package into immediate use as it is built > and also uses overrides, which keeps things inside the source tree, but makes > it unshippable. So I always use buildship. This has never, to my knowledge > run afoul of any compatibility problem other than between cm3 and m3cc, but it > does ship every package besides these two as it is built, so the potential > is there. > > I haven't had the energy to even try to understand just what the upgrade > scripts do, but they have not treated me well. If I had done different > patterns of incompatible changes, they would probably have been better > than the procedure I use. > > On 05/29/2015 01:06 PM, Jay K wrote: > > > I don't see an easy way to make the variable work, as there is no > > > constraint on the order that cm3 and cm3cg are built. do-cm3-front.sh > > > happens to do cm3cg first, but that is not necessarily required. > > > > [please pardon my editing...] > > > > > > I see what you mean that cm3cg is an independent node in the graph and can be built in any order, > > but, I guess, the story is/was, you have to know the safe order to ship things. > > > > > > It is encoded in pkginfo.txt and the Python scripts honor it..though they don't always use pkginfo.txt for their ordering.. > > And encoding the dependency graph there isn't ideal. It is really encoded in the import declarations > > in the m3makefiles, usually, but not in this case... > > > > > > The way that works is to build but don't ship cm3cg. > > Then ship cm3cg. > > Then copy cm3. > > Then use the new cm3. > > But perhaps it isn't strictly enforced enough. > > > > > > > > I used do this fairly often. > > Though breaking changes in cm3cg were rare, granted. > > But I'd also occasionally bootstrap from an older release. > > I'll have to try to do that again soon -- actually make the current > > tree easily buildable from the last release. > > > > > > update.py handled it. > > > > > > I'm on the fence. > > "buildship" of multiple packages is in general problematic. > > I kinda think the whole mechanism needs to be revampled. > > > > > > Let me draw a close analogy. > > > > > > In the slightly larger software world we have: > > > > make > > make install > > make install DESTDIR=somewhere_new > > > > > > buildship is equivalent make && make install, or a make install that includes the make part, > > as they sometimes do. > > Read up on building glibc and they point out how dangerous this is -- how dangerous make install is w/o DESTDIR. > > We have the same danger on a smaller scale. > > You aren't going to break the "OS", but you can break "cm3". > > > > > > The safe recommendation is make install DESTDIR. > > Basically "install" "everything" "on the side", get it all installed, multiple > > "packages", then copy or tar/untar it all. Or chroot into it and test it out, and > > then do an in-place update. Or swap into the chroot and never return? (tail call install) > > > > > > Don't do a "rolling upgrade". Don't install each package as it is built. No package, no cm3, > > not cm3cg, nothing. > > > > > > I'm basically suggesting that. > > > > > > Now, if you say "don't ever ship, but somehow otherwise manually copy", well > > that does kind of resolve to the same thing. > > > > > > If you say, "almost don't ever ship, but provide a way to", that is almost the same. > > > > > > make-dist.py follows the make install DESTDIR way. > > > > It is "better" I guess because I wrote it later, and because I was following > > the example of the other .sh files that make distributions. So blame/credit Olaf? :) > > > > > > It starts with a working compiler, copies parts into /temp, builds a new compiler into /tmp, and > > uses what it builds to build everything. > > > > > > Again I suggest it be looked into, and maybe be promoted as basically > > the replacement for upgrade.py and upgrade.sh. > > > > > > upgrade.py could wrap it and do the final steps of copy/untar in-place. > > Or make-dist.py could just print the last optional command. > > > > > > Anyway, I have no time lately, just email. :( > > > > > > - Jay > > > > > > > > > Date: Fri, 29 May 2015 11:35:41 -0500 > > > From: rodney_bates at lcwb.coop > > > To: adacore at marino.st; wagner at elego.de > > > CC: m3devel at elegosoft.com > > > Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > > > > > > Setting INSTALL_CM3_IN_BIN=yes is what forces the premature install of cm3cg. > > > I see I had encountered this problem two years ago, but then it was happening > > > regardless of the value of this variable. My fix only addresses the case when > > > the variable is not set. I naively went to extra trouble to preserve the > > > existing behavior when it is set--obviously not right. > > > > > > I don't see an easy way to make the variable work, as there is no > > > constraint on the order that cm3 and cm3cg are built. do-cm3-front.sh > > > happens to do cm3cg first, but that is not necessarily required. > > > > > > So INSTALL_CM3_IN_BIN is broken and hard to fix, if the two need > > > compatible upgrades. For now, it looks like install-cm3-compiler.sh > > > is the only working way. > > > > > > But maybe John and Olaf have found a different way around this. > > > > > > On 05/29/2015 10:55 AM, Rodney M. Bates wrote: > > > > I don't know yet why, or what needs to change, but here is definitely the problem, starting > > > > in line 4575 of your m3c log: > > > > > > > > > > > > g++48 -O2 -pipe -fstack-protector -Wl,-rpath=/usr/local/lib/gcc48 -fno-strict-aliasing -Wl,-rpath=/usr/local/lib/gcc48 -DIN_GCC -Wno-missing-field-initializers -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -o m3cgc1 m3cg/parse.o attribs.o main.o tree-browser.o libbackend.a libcommon-target.a libcommon.a ../libcpp/libcpp.a libcommon.a ../libcpp/libcpp.a ../libiberty/libiberty.a > > > > gmake[1]: Leaving directory `/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a/m3-sys/m3cc/AMD64_FREEBSD/gcc' > > > > > > > > > > > > This is copying the newly-built cm3cg (the compiler back end) to your > > > > bin directory: > > > > > > > > Forced ship of cm3cg. > > > > --- shipping from AMD64_FREEBSD --- > > > > > > > > . => /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin > > > > cm3cg > > > > ==> m3-sys/m3cc done > > > > > > > > === package m3-libs/m3core === > > > > > > > > And this is using the cm3 (compiler front end) that was already in the bin > > > > directory, and is the release version. > > > > > > > > +++ /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin/cm3 -build -DROOT='/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a' $RARGS && /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin/cm3 -ship $RARGS -DROOT='/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a' +++ > > > > --- building in AMD64_FREEBSD --- > > > > > > > > ignoring ../src/m3overrides > > > > > > > > new source -> compiling RTHooks.i3 > > > > > > > > This is cm3cg (aka m3cgc1) detecting the incompatibility: > > > > > > > > m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > > > > compilation terminated. > > > > > > > > Here is the counterpart section of my log: > > > > > > > > g++ -g -O2 -DIN_GCC -Wno-missing-field-initializers -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -o m3cgc1 m3cg/parse.o attribs.o main.o tree-browser.o libbackend.a libcommon-target.a libcommon.a ../libcpp/libcpp.a libcommon.a ../libcpp/libcpp.a ../libiberty/libiberty.a > > > > > > > > On my build, it's not shipping: > > > > > > > > Not shipping cm3cg. > > > > --- shipping from AMD64_LINUX --- > > > > > > > > missing ".M3SHIP" file, build the package first. > > > > ==> /home/rodney/proj/m3/git/cm3/m3-sys/m3cc done > > > > > > > > === package /home/rodney/proj/m3/git/cm3/m3-libs/m3core === > > > > +++ cm3 -build -DROOT='/home/rodney/proj/m3/git/cm3' $RARGS && cm3 -ship $RARGS -DROOT='/home/rodney/proj/m3/git/cm3' +++ > > > > --- building in AMD64_LINUX --- > > > > > > > > ignoring ../src/m3overrides > > > > > > > > new source -> compiling RTHooks.i3 > > > > new source -> compiling RT0.i3 > > > > > > > > When it works, the copying of both cm3 and cm3cg to the bin directory is delayed until after both have been > > > > built, in the 'install-cm3-compiler.sh upgrade' step. > > > > > > > > I see your build is using a full path to the bin directory and mine is letting > > > > it come from the usual $PATH search, but that should make no difference, as long > > > > as the bin directory is found in a consistent way, which seems to be the case > > > > in both builds. > > > > > > > > > > > > > > > > On 05/29/2015 04:51 AM, John Marino wrote: > > > >> On 5/29/2015 11:39, Olaf Wagner wrote: > > > >>> On Fri, 29 May 2015 11:10:50 +0200 > > > >>> John Marino wrote: > > > >>> > > > >>>> On 5/29/2015 10:54, Olaf Wagner wrote: > > > >>>>> Please try what I suggested in the attached mail: define > > > >>>>> INSTALL_CM3_IN_BIN=yes > > > >>>>> in the environment and see if that helps. > > > >>>>> > > > >>>> > > > >>>> Unfortunately it seems the result is exactly the same, even when > > > >>>> INSTALL_CM3_IN_BIN is defined in the environment. > > > >>> > > > >>> Can I see the new logs? Has the new backend (cm3cg) been installed now? > > > >>> > > > >> > > > >> It's here: > > > >> http://leaf.dragonflybsd.org/~marino/m3c.log > > > >> > > > >> It never completes "do-cm3-front.sh buildship " > > > >> > > > >> Note that I'm using a bootstrap install and set INSTALL_ROOT to another > > > >> location, but it never gets to the point of installing anything. > > > >> > > > >> John > > > >> > > > > > > > > > > -- > > > Rodney Bates > > > rodney.m.bates at acm.org > > -- > Rodney Bates > rodney.m.bates at acm.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Sat May 30 16:55:37 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sat, 30 May 2015 09:55:37 -0500 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop> <556817A1.2090206@marino.st> <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de> <55682D1A.2030504@marino.st> <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de> <55683689.2090709@marino.st>, , <55688BFF.5040701@lcwb.coop>, <5568955D.4060200@lcwb.coop>, , <5568D5D1.5040405@lcwb.coop> Message-ID: <5569CF69.6020504@lcwb.coop> On 05/29/2015 05:31 PM, Jay K wrote: > cm3/cm3cg are more special than the others, because cm3 is statically linked. > There is no m3core.dll, that cm3 uses, or m3quake.dll, etc. > There is m3core.dll, but cm3 doesn't uses it. > Shipping it doesn't affect the in-use cm3. > > > If/when we fix this, in fact, we can stop doing that static linking. > It makes sense for m3quake, etc. as there are few/no other users. > But for libm3/m3core, it'll provide a nice size optimization. > > > The mutual incompatibilty between old/new cm3/cm3cg is perfectly ok. > It is meant to be dealt with, not avoided. > > > I believe upgrade.py did deal with this correctly, but this environment > variable required to quash shipping of cm3cg broke it. > > > The environment variable change really should imho be removed from cm3cg. > Please. > Jay, I am not sure what you are proposing. When I first looked at the commit for this change, I was quite confused by my own change. While the comments say it is to _not_ prematurely ship cm3cg, the code appears to add code to conditionally ship if INSTALL_CM3_IN_BIN=yes. After the n-th look, I realized that before the change, it _always_ shipped, regardless of the variable. So it really does provide for less premature shipping. If I just revert it, do-cm3-front.sh will be unconditionally and unusably broken. As is, it is at least usable if you don't set the variable. Even if there is some use case where one would want it to ship, (none occurs to me), as is, you can get this behavior by just setting the variable. Moreover, the current behavior for cm3cg is consistent with the current and long-standing behavior for cm3, i.e., ship iff the variable is set. It would make more sense to me to remove the variable check by unconditionally _not_ shipping. At least do-cm3-front.sh would be usable. But then, what would be the purpose of the inconsistent use of the variable for cm3? > > And then we can switch to "destdir" and remove all the in place updating, perhaps. > > > Or I need to update upgrade.py to ship cm3cg itself. > I guess I'll do that. > > > upgrade.py may not have worked for you, but I have used it many many times. > It worked. But currently it is probably broken by the m3cc/src/m3makefile change. > I'll update it to accommodate that change.. > > > And upgrade.sh I believe was in heavy use by Hudson. > > > - Jay > > > > > Date: Fri, 29 May 2015 16:10:41 -0500 > > From: rodney_bates at lcwb.coop > > CC: m3devel at elegosoft.com > > To: > > Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > > > > Yes, we could have a better organization. I agree, the principal way > > should be to build a complete set of everything that matters to the > > implementation of the language, them replace them all at once. A > > separate DESTDIR or such is needed. > > > > The set, as Jay points out, is larger than just cm3 and m3cc. It includes > > at least m3core, probably libm3, and cm3, the executable depends on several > > separately built packages--cm3, m3middle, m3front, m3quake, m3makefile, etc. > > > > In general, we can't really assume anything about the kinds of dependencies > > of one package on old or new versions of another. Right now, cm3 and m3cc > > are known mutually incompatible between 5.8 and the head, because the numbering > > in M3CG_Binary.i3 has changed. We could probably establish some coding rules and > > order-of-install rules that would allow a newer m3cc to work with an older cm3, > > but that's only one pattern. > > > > I once thought do-cm3-*.sh build would do what we are talking about, but it > > if I remember right, puts every package into immediate use as it is built > > and also uses overrides, which keeps things inside the source tree, but makes > > it unshippable. So I always use buildship. This has never, to my knowledge > > run afoul of any compatibility problem other than between cm3 and m3cc, but it > > does ship every package besides these two as it is built, so the potential > > is there. > > > > I haven't had the energy to even try to understand just what the upgrade > > scripts do, but they have not treated me well. If I had done different > > patterns of incompatible changes, they would probably have been better > > than the procedure I use. > > > > On 05/29/2015 01:06 PM, Jay K wrote: > > > > I don't see an easy way to make the variable work, as there is no > > > > constraint on the order that cm3 and cm3cg are built. do-cm3-front.sh > > > > happens to do cm3cg first, but that is not necessarily required. > > > > > > [please pardon my editing...] > > > > > > > > > I see what you mean that cm3cg is an independent node in the graph and can be built in any order, > > > but, I guess, the story is/was, you have to know the safe order to ship things. > > > > > > > > > It is encoded in pkginfo.txt and the Python scripts honor it..though they don't always use pkginfo.txt for their ordering.. > > > And encoding the dependency graph there isn't ideal. It is really encoded in the import declarations > > > in the m3makefiles, usually, but not in this case... > > > > > > > > > The way that works is to build but don't ship cm3cg. > > > Then ship cm3cg. > > > Then copy cm3. > > > Then use the new cm3. > > > But perhaps it isn't strictly enforced enough. > > > > > > > > > > > > I used do this fairly often. > > > Though breaking changes in cm3cg were rare, granted. > > > But I'd also occasionally bootstrap from an older release. > > > I'll have to try to do that again soon -- actually make the current > > > tree easily buildable from the last release. > > > > > > > > > update.py handled it. > > > > > > > > > I'm on the fence. > > > "buildship" of multiple packages is in general problematic. > > > I kinda think the whole mechanism needs to be revampled. > > > > > > > > > Let me draw a close analogy. > > > > > > > > > In the slightly larger software world we have: > > > > > > make > > > make install > > > make install DESTDIR=somewhere_new > > > > > > > > > buildship is equivalent make && make install, or a make install that includes the make part, > > > as they sometimes do. > > > Read up on building glibc and they point out how dangerous this is -- how dangerous make install is w/o DESTDIR. > > > We have the same danger on a smaller scale. > > > You aren't going to break the "OS", but you can break "cm3". > > > > > > > > > The safe recommendation is make install DESTDIR. > > > Basically "install" "everything" "on the side", get it all installed, multiple > > > "packages", then copy or tar/untar it all. Or chroot into it and test it out, and > > > then do an in-place update. Or swap into the chroot and never return? (tail call install) > > > > > > > > > Don't do a "rolling upgrade". Don't install each package as it is built. No package, no cm3, > > > not cm3cg, nothing. > > > > > > > > > I'm basically suggesting that. > > > > > > > > > Now, if you say "don't ever ship, but somehow otherwise manually copy", well > > > that does kind of resolve to the same thing. > > > > > > > > > If you say, "almost don't ever ship, but provide a way to", that is almost the same. > > > > > > > > > make-dist.py follows the make install DESTDIR way. > > > > > > It is "better" I guess because I wrote it later, and because I was following > > > the example of the other .sh files that make distributions. So blame/credit Olaf? :) > > > > > > > > > It starts with a working compiler, copies parts into /temp, builds a new compiler into /tmp, and > > > uses what it builds to build everything. > > > > > > > > > Again I suggest it be looked into, and maybe be promoted as basically > > > the replacement for upgrade.py and upgrade.sh. > > > > > > > > > upgrade.py could wrap it and do the final steps of copy/untar in-place. > > > Or make-dist.py could just print the last optional command. > > > > > > > > > Anyway, I have no time lately, just email. :( > > > > > > > > > - Jay > > > > > > > > > > > > > Date: Fri, 29 May 2015 11:35:41 -0500 > > > > From: rodney_bates at lcwb.coop > > > > To: adacore at marino.st; wagner at elego.de > > > > CC: m3devel at elegosoft.com > > > > Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > > > > > > > > Setting INSTALL_CM3_IN_BIN=yes is what forces the premature install of cm3cg. > > > > I see I had encountered this problem two years ago, but then it was happening > > > > regardless of the value of this variable. My fix only addresses the case when > > > > the variable is not set. I naively went to extra trouble to preserve the > > > > existing behavior when it is set--obviously not right. > > > > > > > > I don't see an easy way to make the variable work, as there is no > > > > constraint on the order that cm3 and cm3cg are built. do-cm3-front.sh > > > > happens to do cm3cg first, but that is not necessarily required. > > > > > > > > So INSTALL_CM3_IN_BIN is broken and hard to fix, if the two need > > > > compatible upgrades. For now, it looks like install-cm3-compiler.sh > > > > is the only working way. > > > > > > > > But maybe John and Olaf have found a different way around this. > > > > > > > > On 05/29/2015 10:55 AM, Rodney M. Bates wrote: > > > > > I don't know yet why, or what needs to change, but here is definitely the problem, starting > > > > > in line 4575 of your m3c log: > > > > > > > > > > > > > > > g++48 -O2 -pipe -fstack-protector -Wl,-rpath=/usr/local/lib/gcc48 -fno-strict-aliasing -Wl,-rpath=/usr/local/lib/gcc48 -DIN_GCC -Wno-missing-field-initializers -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -o m3cgc1 m3cg/parse.o attribs.o main.o tree-browser.o libbackend.a libcommon-target.a libcommon.a ../libcpp/libcpp.a libcommon.a ../libcpp/libcpp.a ../libiberty/libiberty.a > > > > > gmake[1]: Leaving directory `/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a/m3-sys/m3cc/AMD64_FREEBSD/gcc' > > > > > > > > > > > > > > > This is copying the newly-built cm3cg (the compiler back end) to your > > > > > bin directory: > > > > > > > > > > Forced ship of cm3cg. > > > > > --- shipping from AMD64_FREEBSD --- > > > > > > > > > > . => /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin > > > > > cm3cg > > > > > ==> m3-sys/m3cc done > > > > > > > > > > === package m3-libs/m3core === > > > > > > > > > > And this is using the cm3 (compiler front end) that was already in the bin > > > > > directory, and is the release version. > > > > > > > > > > +++ /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin/cm3 -build -DROOT='/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a' $RARGS && /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin/cm3 -ship $RARGS -DROOT='/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a' +++ > > > > > --- building in AMD64_FREEBSD --- > > > > > > > > > > ignoring ../src/m3overrides > > > > > > > > > > new source -> compiling RTHooks.i3 > > > > > > > > > > This is cm3cg (aka m3cgc1) detecting the incompatibility: > > > > > > > > > > m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > > > > > compilation terminated. > > > > > > > > > > Here is the counterpart section of my log: > > > > > > > > > > g++ -g -O2 -DIN_GCC -Wno-missing-field-initializers -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -o m3cgc1 m3cg/parse.o attribs.o main.o tree-browser.o libbackend.a libcommon-target.a libcommon.a ../libcpp/libcpp.a libcommon.a ../libcpp/libcpp.a ../libiberty/libiberty.a > > > > > > > > > > On my build, it's not shipping: > > > > > > > > > > Not shipping cm3cg. > > > > > --- shipping from AMD64_LINUX --- > > > > > > > > > > missing ".M3SHIP" file, build the package first. > > > > > ==> /home/rodney/proj/m3/git/cm3/m3-sys/m3cc done > > > > > > > > > > === package /home/rodney/proj/m3/git/cm3/m3-libs/m3core === > > > > > +++ cm3 -build -DROOT='/home/rodney/proj/m3/git/cm3' $RARGS && cm3 -ship $RARGS -DROOT='/home/rodney/proj/m3/git/cm3' +++ > > > > > --- building in AMD64_LINUX --- > > > > > > > > > > ignoring ../src/m3overrides > > > > > > > > > > new source -> compiling RTHooks.i3 > > > > > new source -> compiling RT0.i3 > > > > > > > > > > When it works, the copying of both cm3 and cm3cg to the bin directory is delayed until after both have been > > > > > built, in the 'install-cm3-compiler.sh upgrade' step. > > > > > > > > > > I see your build is using a full path to the bin directory and mine is letting > > > > > it come from the usual $PATH search, but that should make no difference, as long > > > > > as the bin directory is found in a consistent way, which seems to be the case > > > > > in both builds. > > > > > > > > > > > > > > > > > > > > On 05/29/2015 04:51 AM, John Marino wrote: > > > > >> On 5/29/2015 11:39, Olaf Wagner wrote: > > > > >>> On Fri, 29 May 2015 11:10:50 +0200 > > > > >>> John Marino wrote: > > > > >>> > > > > >>>> On 5/29/2015 10:54, Olaf Wagner wrote: > > > > >>>>> Please try what I suggested in the attached mail: define > > > > >>>>> INSTALL_CM3_IN_BIN=yes > > > > >>>>> in the environment and see if that helps. > > > > >>>>> > > > > >>>> > > > > >>>> Unfortunately it seems the result is exactly the same, even when > > > > >>>> INSTALL_CM3_IN_BIN is defined in the environment. > > > > >>> > > > > >>> Can I see the new logs? Has the new backend (cm3cg) been installed now? > > > > >>> > > > > >> > > > > >> It's here: > > > > >> http://leaf.dragonflybsd.org/~marino/m3c.log > > > > >> > > > > >> It never completes "do-cm3-front.sh buildship " > > > > >> > > > > >> Note that I'm using a bootstrap install and set INSTALL_ROOT to another > > > > >> location, but it never gets to the point of installing anything. > > > > >> > > > > >> John > > > > >> > > > > > > > > > > > > > -- > > > > Rodney Bates > > > > rodney.m.bates at acm.org > > > > -- > > Rodney Bates > > rodney.m.bates at acm.org -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Sat May 30 16:58:31 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sat, 30 May 2015 09:58:31 -0500 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop> <556817A1.2090206@marino.st> <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de> <55682D1A.2030504@marino.st> <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de> <55683689.2090709@marino.st>, , <55688BFF.5040701@lcwb.coop>, <5568955D.4060200@lcwb.coop>, , <5568D5D1.5040405@lcwb.coop> Message-ID: <5569D017.5000201@lcwb.coop> On 05/29/2015 05:31 PM, Jay K wrote: > cm3/cm3cg are more special than the others, because cm3 is statically linked. > There is no m3core.dll, that cm3 uses, or m3quake.dll, etc. > There is m3core.dll, but cm3 doesn't uses it. > Shipping it doesn't affect the in-use cm3. > > > If/when we fix this, in fact, we can stop doing that static linking. > It makes sense for m3quake, etc. as there are few/no other users. > But for libm3/m3core, it'll provide a nice size optimization. > > > The mutual incompatibilty between old/new cm3/cm3cg is perfectly ok. > It is meant to be dealt with, not avoided. > I agree it's OK. Disallowing it would overly hamstring future development. But dealing with it means we need to be able to prevent either package immediately after it is built. > > I believe upgrade.py did deal with this correctly, but this environment > variable required to quash shipping of cm3cg broke it. > > > The environment variable change really should imho be removed from cm3cg. > Please. > Jay, I am not sure what you are proposing. When I first looked at the commit for this change, I was quite confused by my own change. While the comments say it is to _not_ prematurely ship cm3cg, the code appears to add code to conditionally ship if INSTALL_CM3_IN_BIN=yes. After the n-th look, I realized that before the change, it _always_ shipped, regardless of the variable. So it really does provide for less premature shipping. If I just revert it, do-cm3-front.sh will be unconditionally and unusably broken. As is, it is at least usable if you don't set the variable. Even if there is some use case where one would want it to ship, (none occurs to me), as is, you can get this behavior by just setting the variable. Moreover, the current behavior for cm3cg is consistent with the current and long-standing behavior for cm3, i.e., ship iff the variable is set. It would make more sense to me to remove the variable check by unconditionally _not_ shipping. At least do-cm3-front.sh would be usable. But then, what would be the purpose of the inconsistent use of the variable for cm3? > > And then we can switch to "destdir" and remove all the in place updating, perhaps. > > > Or I need to update upgrade.py to ship cm3cg itself. > I guess I'll do that. > > > upgrade.py may not have worked for you, but I have used it many many times. > It worked. But currently it is probably broken by the m3cc/src/m3makefile change. > I'll update it to accommodate that change.. > > > And upgrade.sh I believe was in heavy use by Hudson. > > > - Jay > > > > > Date: Fri, 29 May 2015 16:10:41 -0500 > > From: rodney_bates at lcwb.coop > > CC: m3devel at elegosoft.com > > To: > > Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > > > > Yes, we could have a better organization. I agree, the principal way > > should be to build a complete set of everything that matters to the > > implementation of the language, them replace them all at once. A > > separate DESTDIR or such is needed. > > > > The set, as Jay points out, is larger than just cm3 and m3cc. It includes > > at least m3core, probably libm3, and cm3, the executable depends on several > > separately built packages--cm3, m3middle, m3front, m3quake, m3makefile, etc. > > > > In general, we can't really assume anything about the kinds of dependencies > > of one package on old or new versions of another. Right now, cm3 and m3cc > > are known mutually incompatible between 5.8 and the head, because the numbering > > in M3CG_Binary.i3 has changed. We could probably establish some coding rules and > > order-of-install rules that would allow a newer m3cc to work with an older cm3, > > but that's only one pattern. > > > > I once thought do-cm3-*.sh build would do what we are talking about, but it > > if I remember right, puts every package into immediate use as it is built > > and also uses overrides, which keeps things inside the source tree, but makes > > it unshippable. So I always use buildship. This has never, to my knowledge > > run afoul of any compatibility problem other than between cm3 and m3cc, but it > > does ship every package besides these two as it is built, so the potential > > is there. > > > > I haven't had the energy to even try to understand just what the upgrade > > scripts do, but they have not treated me well. If I had done different > > patterns of incompatible changes, they would probably have been better > > than the procedure I use. > > > > On 05/29/2015 01:06 PM, Jay K wrote: > > > > I don't see an easy way to make the variable work, as there is no > > > > constraint on the order that cm3 and cm3cg are built. do-cm3-front.sh > > > > happens to do cm3cg first, but that is not necessarily required. > > > > > > [please pardon my editing...] > > > > > > > > > I see what you mean that cm3cg is an independent node in the graph and can be built in any order, > > > but, I guess, the story is/was, you have to know the safe order to ship things. > > > > > > > > > It is encoded in pkginfo.txt and the Python scripts honor it..though they don't always use pkginfo.txt for their ordering.. > > > And encoding the dependency graph there isn't ideal. It is really encoded in the import declarations > > > in the m3makefiles, usually, but not in this case... > > > > > > > > > The way that works is to build but don't ship cm3cg. > > > Then ship cm3cg. > > > Then copy cm3. > > > Then use the new cm3. > > > But perhaps it isn't strictly enforced enough. > > > > > > > > > > > > I used do this fairly often. > > > Though breaking changes in cm3cg were rare, granted. > > > But I'd also occasionally bootstrap from an older release. > > > I'll have to try to do that again soon -- actually make the current > > > tree easily buildable from the last release. > > > > > > > > > update.py handled it. > > > > > > > > > I'm on the fence. > > > "buildship" of multiple packages is in general problematic. > > > I kinda think the whole mechanism needs to be revampled. > > > > > > > > > Let me draw a close analogy. > > > > > > > > > In the slightly larger software world we have: > > > > > > make > > > make install > > > make install DESTDIR=somewhere_new > > > > > > > > > buildship is equivalent make && make install, or a make install that includes the make part, > > > as they sometimes do. > > > Read up on building glibc and they point out how dangerous this is -- how dangerous make install is w/o DESTDIR. > > > We have the same danger on a smaller scale. > > > You aren't going to break the "OS", but you can break "cm3". > > > > > > > > > The safe recommendation is make install DESTDIR. > > > Basically "install" "everything" "on the side", get it all installed, multiple > > > "packages", then copy or tar/untar it all. Or chroot into it and test it out, and > > > then do an in-place update. Or swap into the chroot and never return? (tail call install) > > > > > > > > > Don't do a "rolling upgrade". Don't install each package as it is built. No package, no cm3, > > > not cm3cg, nothing. > > > > > > > > > I'm basically suggesting that. > > > > > > > > > Now, if you say "don't ever ship, but somehow otherwise manually copy", well > > > that does kind of resolve to the same thing. > > > > > > > > > If you say, "almost don't ever ship, but provide a way to", that is almost the same. > > > > > > > > > make-dist.py follows the make install DESTDIR way. > > > > > > It is "better" I guess because I wrote it later, and because I was following > > > the example of the other .sh files that make distributions. So blame/credit Olaf? :) > > > > > > > > > It starts with a working compiler, copies parts into /temp, builds a new compiler into /tmp, and > > > uses what it builds to build everything. > > > > > > > > > Again I suggest it be looked into, and maybe be promoted as basically > > > the replacement for upgrade.py and upgrade.sh. > > > > > > > > > upgrade.py could wrap it and do the final steps of copy/untar in-place. > > > Or make-dist.py could just print the last optional command. > > > > > > > > > Anyway, I have no time lately, just email. :( > > > > > > > > > - Jay > > > > > > > > > > > > > Date: Fri, 29 May 2015 11:35:41 -0500 > > > > From: rodney_bates at lcwb.coop > > > > To: adacore at marino.st; wagner at elego.de > > > > CC: m3devel at elegosoft.com > > > > Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > > > > > > > > Setting INSTALL_CM3_IN_BIN=yes is what forces the premature install of cm3cg. > > > > I see I had encountered this problem two years ago, but then it was happening > > > > regardless of the value of this variable. My fix only addresses the case when > > > > the variable is not set. I naively went to extra trouble to preserve the > > > > existing behavior when it is set--obviously not right. > > > > > > > > I don't see an easy way to make the variable work, as there is no > > > > constraint on the order that cm3 and cm3cg are built. do-cm3-front.sh > > > > happens to do cm3cg first, but that is not necessarily required. > > > > > > > > So INSTALL_CM3_IN_BIN is broken and hard to fix, if the two need > > > > compatible upgrades. For now, it looks like install-cm3-compiler.sh > > > > is the only working way. > > > > > > > > But maybe John and Olaf have found a different way around this. > > > > > > > > On 05/29/2015 10:55 AM, Rodney M. Bates wrote: > > > > > I don't know yet why, or what needs to change, but here is definitely the problem, starting > > > > > in line 4575 of your m3c log: > > > > > > > > > > > > > > > g++48 -O2 -pipe -fstack-protector -Wl,-rpath=/usr/local/lib/gcc48 -fno-strict-aliasing -Wl,-rpath=/usr/local/lib/gcc48 -DIN_GCC -Wno-missing-field-initializers -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -o m3cgc1 m3cg/parse.o attribs.o main.o tree-browser.o libbackend.a libcommon-target.a libcommon.a ../libcpp/libcpp.a libcommon.a ../libcpp/libcpp.a ../libiberty/libiberty.a > > > > > gmake[1]: Leaving directory `/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a/m3-sys/m3cc/AMD64_FREEBSD/gcc' > > > > > > > > > > > > > > > This is copying the newly-built cm3cg (the compiler back end) to your > > > > > bin directory: > > > > > > > > > > Forced ship of cm3cg. > > > > > --- shipping from AMD64_FREEBSD --- > > > > > > > > > > . => /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin > > > > > cm3cg > > > > > ==> m3-sys/m3cc done > > > > > > > > > > === package m3-libs/m3core === > > > > > > > > > > And this is using the cm3 (compiler front end) that was already in the bin > > > > > directory, and is the release version. > > > > > > > > > > +++ /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin/cm3 -build -DROOT='/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a' $RARGS && /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin/cm3 -ship $RARGS -DROOT='/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a' +++ > > > > > --- building in AMD64_FREEBSD --- > > > > > > > > > > ignoring ../src/m3overrides > > > > > > > > > > new source -> compiling RTHooks.i3 > > > > > > > > > > This is cm3cg (aka m3cgc1) detecting the incompatibility: > > > > > > > > > > m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > > > > > compilation terminated. > > > > > > > > > > Here is the counterpart section of my log: > > > > > > > > > > g++ -g -O2 -DIN_GCC -Wno-missing-field-initializers -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -o m3cgc1 m3cg/parse.o attribs.o main.o tree-browser.o libbackend.a libcommon-target.a libcommon.a ../libcpp/libcpp.a libcommon.a ../libcpp/libcpp.a ../libiberty/libiberty.a > > > > > > > > > > On my build, it's not shipping: > > > > > > > > > > Not shipping cm3cg. > > > > > --- shipping from AMD64_LINUX --- > > > > > > > > > > missing ".M3SHIP" file, build the package first. > > > > > ==> /home/rodney/proj/m3/git/cm3/m3-sys/m3cc done > > > > > > > > > > === package /home/rodney/proj/m3/git/cm3/m3-libs/m3core === > > > > > +++ cm3 -build -DROOT='/home/rodney/proj/m3/git/cm3' $RARGS && cm3 -ship $RARGS -DROOT='/home/rodney/proj/m3/git/cm3' +++ > > > > > --- building in AMD64_LINUX --- > > > > > > > > > > ignoring ../src/m3overrides > > > > > > > > > > new source -> compiling RTHooks.i3 > > > > > new source -> compiling RT0.i3 > > > > > > > > > > When it works, the copying of both cm3 and cm3cg to the bin directory is delayed until after both have been > > > > > built, in the 'install-cm3-compiler.sh upgrade' step. > > > > > > > > > > I see your build is using a full path to the bin directory and mine is letting > > > > > it come from the usual $PATH search, but that should make no difference, as long > > > > > as the bin directory is found in a consistent way, which seems to be the case > > > > > in both builds. > > > > > > > > > > > > > > > > > > > > On 05/29/2015 04:51 AM, John Marino wrote: > > > > >> On 5/29/2015 11:39, Olaf Wagner wrote: > > > > >>> On Fri, 29 May 2015 11:10:50 +0200 > > > > >>> John Marino wrote: > > > > >>> > > > > >>>> On 5/29/2015 10:54, Olaf Wagner wrote: > > > > >>>>> Please try what I suggested in the attached mail: define > > > > >>>>> INSTALL_CM3_IN_BIN=yes > > > > >>>>> in the environment and see if that helps. > > > > >>>>> > > > > >>>> > > > > >>>> Unfortunately it seems the result is exactly the same, even when > > > > >>>> INSTALL_CM3_IN_BIN is defined in the environment. > > > > >>> > > > > >>> Can I see the new logs? Has the new backend (cm3cg) been installed now? > > > > >>> > > > > >> > > > > >> It's here: > > > > >> http://leaf.dragonflybsd.org/~marino/m3c.log > > > > >> > > > > >> It never completes "do-cm3-front.sh buildship " > > > > >> > > > > >> Note that I'm using a bootstrap install and set INSTALL_ROOT to another > > > > >> location, but it never gets to the point of installing anything. > > > > >> > > > > >> John > > > > >> > > > > > > > > > > > > > -- > > > > Rodney Bates > > > > rodney.m.bates at acm.org > > > > -- > > Rodney Bates > > rodney.m.bates at acm.org -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Sat May 30 17:13:46 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sat, 30 May 2015 10:13:46 -0500 Subject: [M3devel] The role INTEGER and subranges in Modula-3 Message-ID: <5569D3AA.2040009@lcwb.coop> I am suspecting there is some misunderstanding about Modula-3's approach to integer sizes. The original idea is to use subrange types, (which are programmer-defined,) not different builtin types, to match the value range you need. The safety rules of the language ensure that values stored in variables are in the type's range. But all arithmetic is done in the full native word size of the machine. Types are more abstract than most languages, in that different machine representations (particularly, bit count) need not be different base types in the language. There are no implicit type conversions. Instead, this need is met by the concept of assignability. If the abstract value is in a variable's range, it can be assigned to the variable. Size changes, if needed, are the code generator's problem. All this drastically simplifies the language, while also allowing the programmer to define an exact match between type-imposed value ranges and what the application needs, rather than just a few powers of two. Having implied type conversions, which also interact with sizes of intermediate arithmetic results, requires many pages of language definition that we avoid. LONGINT, which I have advocated, flies in the face of this tidy scheme. If we could do all arithmetic efficiently in the biggest size likely to be commonly needed, LONGINT would have no place. But native sized arithmetic is always the most efficient. In today's world, there are two very common classes of use cases: 1) 32-bit arithmetic is wide enough, 2) 32-bit is not wide enough, but 64-bit is. In both cases, on machines of either native arithmetic size, we want the best efficiency. LONGINT is for case 2, and when you further need to be able to run on either size of machine. INTEGER is for otherwise. Whether you believe in LONGINT or not, there is certainly no justification for more base integer types than two: one the native size of the machine and one bigger. Note that, as defined in Modula-3 today, INTEGER and LONGINT are always distinct types (distinct, regardless of either their value ranges or of the machine's native word size), with no subtype relation between them, no assignability between them, no implied conversions between them, no mixed arithmetic operators, no questions about intermediate result range, and literals of unambiguous type. Thus we stay out of the semantic tar pit most languages fall into with multiple integer sizes, while giving the programmer drastically more choices on range limits. Note that original Modula-3, in contrast to the single integer type, has three floating point types, no doubt motivated by the messy realities of taking full advantage of hardware-provided arithmetics. These three have the same type isolation properties as INTEGER and LONGINT, with the same consequences. In fact, the integer type isolation is directly modeled after the floating type isolation. -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Sat May 30 17:27:22 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sat, 30 May 2015 10:27:22 -0500 Subject: [M3devel] Integrating llvm Message-ID: <5569D6DA.9050404@lcwb.coop> In order to simplify integrating the emerging llvm backend, I propose to split the current llvm package into three: A library package containing just binding-related stuff to the llvm infrastructure. (llvmbindings) A library package containing M3CG_LLVM.[im]3 and anything that might get added for the actual cm3-IR to llvm-IR conversion. (llvmback) A program package with a main program for llvm (currently llvm/src/Main.m3) (llvmstaloneback) This would provide more flexibility in doing the integration into the compiler, and maybe some other things some day. Any objections or comments? Peter? -- Rodney Bates rodney.m.bates at acm.org From jay.krell at cornell.edu Sat May 30 18:24:17 2015 From: jay.krell at cornell.edu (Jay K) Date: Sat, 30 May 2015 16:24:17 +0000 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <5569D017.5000201@lcwb.coop> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop> <556817A1.2090206@marino.st> <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de> <55682D1A.2030504@marino.st> <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de> <55683689.2090709@marino.st>,,, <55688BFF.5040701@lcwb.coop>, <5568955D.4060200@lcwb.coop>, , , , <5568D5D1.5040405@lcwb.coop>, , <5569D017.5000201@lcwb.coop> Message-ID: The variable is not for atomic update of multiple files. The variable exists because updating in-use files reportedly fails on some operating systems. Though I question the truth of even that. If we change ship to rename away upon copy failure, and find a reliable simple way to ensure eventual deletion of the renamed file, then we don't need this. I'll have to experiment on NT. Presumably we've written off Win9x, and I'm not sure about AIX. So consistency with cm3 isn't necessarily desirable/required. do-cm3-front.sh isn't necessarily meant to work when there is an IR change. perhaps m3cc wasn't supposed to be in front. I'll have to double check that later. upgrade.sh is meant to. It doesn't ship anything and manually copies both cm3 and cm3cg. So that still works. And upgrade.py handles it, but other way I think, so it doesn't work any longer. Perhaps the upgrade.sh approach is better and perhaps I missed this when I rewrote it. I can make it copy cm3cg manually. I haven't gotten a chance to fix anything yet. - Jay > Date: Sat, 30 May 2015 09:58:31 -0500 > From: rodney_bates at lcwb.coop > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > > > > On 05/29/2015 05:31 PM, Jay K wrote: > > cm3/cm3cg are more special than the others, because cm3 is statically linked. > > There is no m3core.dll, that cm3 uses, or m3quake.dll, etc. > > There is m3core.dll, but cm3 doesn't uses it. > > Shipping it doesn't affect the in-use cm3. > > > > > > If/when we fix this, in fact, we can stop doing that static linking. > > It makes sense for m3quake, etc. as there are few/no other users. > > But for libm3/m3core, it'll provide a nice size optimization. > > > > > > The mutual incompatibilty between old/new cm3/cm3cg is perfectly ok. > > It is meant to be dealt with, not avoided. > > > > I agree it's OK. Disallowing it would overly hamstring future development. > But dealing with it means we need to be able to prevent either package > immediately after it is built. > > > > > I believe upgrade.py did deal with this correctly, but this environment > > variable required to quash shipping of cm3cg broke it. > > > > > > The environment variable change really should imho be removed from cm3cg. > > Please. > > > > Jay, I am not sure what you are proposing. When I first looked at the commit for > this change, I was quite confused by my own change. While the comments say it > is to _not_ prematurely ship cm3cg, the code appears to add code to conditionally > ship if INSTALL_CM3_IN_BIN=yes. After the n-th look, I realized that before > the change, it _always_ shipped, regardless of the variable. So it really does > provide for less premature shipping. > > If I just revert it, do-cm3-front.sh will be unconditionally and unusably broken. > As is, it is at least usable if you don't set the variable. Even if there is > some use case where one would want it to ship, (none occurs to me), as is, you > can get this behavior by just setting the variable. > > Moreover, the current behavior for cm3cg is consistent with the current and > long-standing behavior for cm3, i.e., ship iff the variable is set. > > It would make more sense to me to remove the variable check by unconditionally > _not_ shipping. At least do-cm3-front.sh would be usable. But then, what > would be the purpose of the inconsistent use of the variable for cm3? > > > > > > > And then we can switch to "destdir" and remove all the in place updating, perhaps. > > > > > > Or I need to update upgrade.py to ship cm3cg itself. > > I guess I'll do that. > > > > > > upgrade.py may not have worked for you, but I have used it many many times. > > It worked. But currently it is probably broken by the m3cc/src/m3makefile change. > > I'll update it to accommodate that change.. > > > > > > And upgrade.sh I believe was in heavy use by Hudson. > > > > > > - Jay > > > > > > > > > Date: Fri, 29 May 2015 16:10:41 -0500 > > > From: rodney_bates at lcwb.coop > > > CC: m3devel at elegosoft.com > > > To: > > > Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > > > > > > Yes, we could have a better organization. I agree, the principal way > > > should be to build a complete set of everything that matters to the > > > implementation of the language, them replace them all at once. A > > > separate DESTDIR or such is needed. > > > > > > The set, as Jay points out, is larger than just cm3 and m3cc. It includes > > > at least m3core, probably libm3, and cm3, the executable depends on several > > > separately built packages--cm3, m3middle, m3front, m3quake, m3makefile, etc. > > > > > > In general, we can't really assume anything about the kinds of dependencies > > > of one package on old or new versions of another. Right now, cm3 and m3cc > > > are known mutually incompatible between 5.8 and the head, because the numbering > > > in M3CG_Binary.i3 has changed. We could probably establish some coding rules and > > > order-of-install rules that would allow a newer m3cc to work with an older cm3, > > > but that's only one pattern. > > > > > > I once thought do-cm3-*.sh build would do what we are talking about, but it > > > if I remember right, puts every package into immediate use as it is built > > > and also uses overrides, which keeps things inside the source tree, but makes > > > it unshippable. So I always use buildship. This has never, to my knowledge > > > run afoul of any compatibility problem other than between cm3 and m3cc, but it > > > does ship every package besides these two as it is built, so the potential > > > is there. > > > > > > I haven't had the energy to even try to understand just what the upgrade > > > scripts do, but they have not treated me well. If I had done different > > > patterns of incompatible changes, they would probably have been better > > > than the procedure I use. > > > > > > On 05/29/2015 01:06 PM, Jay K wrote: > > > > > I don't see an easy way to make the variable work, as there is no > > > > > constraint on the order that cm3 and cm3cg are built. do-cm3-front.sh > > > > > happens to do cm3cg first, but that is not necessarily required. > > > > > > > > [please pardon my editing...] > > > > > > > > > > > > I see what you mean that cm3cg is an independent node in the graph and can be built in any order, > > > > but, I guess, the story is/was, you have to know the safe order to ship things. > > > > > > > > > > > > It is encoded in pkginfo.txt and the Python scripts honor it..though they don't always use pkginfo.txt for their ordering.. > > > > And encoding the dependency graph there isn't ideal. It is really encoded in the import declarations > > > > in the m3makefiles, usually, but not in this case... > > > > > > > > > > > > The way that works is to build but don't ship cm3cg. > > > > Then ship cm3cg. > > > > Then copy cm3. > > > > Then use the new cm3. > > > > But perhaps it isn't strictly enforced enough. > > > > > > > > > > > > > > > > I used do this fairly often. > > > > Though breaking changes in cm3cg were rare, granted. > > > > But I'd also occasionally bootstrap from an older release. > > > > I'll have to try to do that again soon -- actually make the current > > > > tree easily buildable from the last release. > > > > > > > > > > > > update.py handled it. > > > > > > > > > > > > I'm on the fence. > > > > "buildship" of multiple packages is in general problematic. > > > > I kinda think the whole mechanism needs to be revampled. > > > > > > > > > > > > Let me draw a close analogy. > > > > > > > > > > > > In the slightly larger software world we have: > > > > > > > > make > > > > make install > > > > make install DESTDIR=somewhere_new > > > > > > > > > > > > buildship is equivalent make && make install, or a make install that includes the make part, > > > > as they sometimes do. > > > > Read up on building glibc and they point out how dangerous this is -- how dangerous make install is w/o DESTDIR. > > > > We have the same danger on a smaller scale. > > > > You aren't going to break the "OS", but you can break "cm3". > > > > > > > > > > > > The safe recommendation is make install DESTDIR. > > > > Basically "install" "everything" "on the side", get it all installed, multiple > > > > "packages", then copy or tar/untar it all. Or chroot into it and test it out, and > > > > then do an in-place update. Or swap into the chroot and never return? (tail call install) > > > > > > > > > > > > Don't do a "rolling upgrade". Don't install each package as it is built. No package, no cm3, > > > > not cm3cg, nothing. > > > > > > > > > > > > I'm basically suggesting that. > > > > > > > > > > > > Now, if you say "don't ever ship, but somehow otherwise manually copy", well > > > > that does kind of resolve to the same thing. > > > > > > > > > > > > If you say, "almost don't ever ship, but provide a way to", that is almost the same. > > > > > > > > > > > > make-dist.py follows the make install DESTDIR way. > > > > > > > > It is "better" I guess because I wrote it later, and because I was following > > > > the example of the other .sh files that make distributions. So blame/credit Olaf? :) > > > > > > > > > > > > It starts with a working compiler, copies parts into /temp, builds a new compiler into /tmp, and > > > > uses what it builds to build everything. > > > > > > > > > > > > Again I suggest it be looked into, and maybe be promoted as basically > > > > the replacement for upgrade.py and upgrade.sh. > > > > > > > > > > > > upgrade.py could wrap it and do the final steps of copy/untar in-place. > > > > Or make-dist.py could just print the last optional command. > > > > > > > > > > > > Anyway, I have no time lately, just email. :( > > > > > > > > > > > > - Jay > > > > > > > > > > > > > > > > > Date: Fri, 29 May 2015 11:35:41 -0500 > > > > > From: rodney_bates at lcwb.coop > > > > > To: adacore at marino.st; wagner at elego.de > > > > > CC: m3devel at elegosoft.com > > > > > Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > > > > > > > > > > Setting INSTALL_CM3_IN_BIN=yes is what forces the premature install of cm3cg. > > > > > I see I had encountered this problem two years ago, but then it was happening > > > > > regardless of the value of this variable. My fix only addresses the case when > > > > > the variable is not set. I naively went to extra trouble to preserve the > > > > > existing behavior when it is set--obviously not right. > > > > > > > > > > I don't see an easy way to make the variable work, as there is no > > > > > constraint on the order that cm3 and cm3cg are built. do-cm3-front.sh > > > > > happens to do cm3cg first, but that is not necessarily required. > > > > > > > > > > So INSTALL_CM3_IN_BIN is broken and hard to fix, if the two need > > > > > compatible upgrades. For now, it looks like install-cm3-compiler.sh > > > > > is the only working way. > > > > > > > > > > But maybe John and Olaf have found a different way around this. > > > > > > > > > > On 05/29/2015 10:55 AM, Rodney M. Bates wrote: > > > > > > I don't know yet why, or what needs to change, but here is definitely the problem, starting > > > > > > in line 4575 of your m3c log: > > > > > > > > > > > > > > > > > > g++48 -O2 -pipe -fstack-protector -Wl,-rpath=/usr/local/lib/gcc48 -fno-strict-aliasing -Wl,-rpath=/usr/local/lib/gcc48 -DIN_GCC -Wno-missing-field-initializers -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -o m3cgc1 m3cg/parse.o attribs.o main.o tree-browser.o libbackend.a libcommon-target.a libcommon.a ../libcpp/libcpp.a libcommon.a ../libcpp/libcpp.a ../libiberty/libiberty.a > > > > > > gmake[1]: Leaving directory `/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a/m3-sys/m3cc/AMD64_FREEBSD/gcc' > > > > > > > > > > > > > > > > > > This is copying the newly-built cm3cg (the compiler back end) to your > > > > > > bin directory: > > > > > > > > > > > > Forced ship of cm3cg. > > > > > > --- shipping from AMD64_FREEBSD --- > > > > > > > > > > > > . => /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin > > > > > > cm3cg > > > > > > ==> m3-sys/m3cc done > > > > > > > > > > > > === package m3-libs/m3core === > > > > > > > > > > > > And this is using the cm3 (compiler front end) that was already in the bin > > > > > > directory, and is the release version. > > > > > > > > > > > > +++ /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin/cm3 -build -DROOT='/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a' $RARGS && /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin/cm3 -ship $RARGS -DROOT='/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a' +++ > > > > > > --- building in AMD64_FREEBSD --- > > > > > > > > > > > > ignoring ../src/m3overrides > > > > > > > > > > > > new source -> compiling RTHooks.i3 > > > > > > > > > > > > This is cm3cg (aka m3cgc1) detecting the incompatibility: > > > > > > > > > > > > m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > > > > > > compilation terminated. > > > > > > > > > > > > Here is the counterpart section of my log: > > > > > > > > > > > > g++ -g -O2 -DIN_GCC -Wno-missing-field-initializers -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -o m3cgc1 m3cg/parse.o attribs.o main.o tree-browser.o libbackend.a libcommon-target.a libcommon.a ../libcpp/libcpp.a libcommon.a ../libcpp/libcpp.a ../libiberty/libiberty.a > > > > > > > > > > > > On my build, it's not shipping: > > > > > > > > > > > > Not shipping cm3cg. > > > > > > --- shipping from AMD64_LINUX --- > > > > > > > > > > > > missing ".M3SHIP" file, build the package first. > > > > > > ==> /home/rodney/proj/m3/git/cm3/m3-sys/m3cc done > > > > > > > > > > > > === package /home/rodney/proj/m3/git/cm3/m3-libs/m3core === > > > > > > +++ cm3 -build -DROOT='/home/rodney/proj/m3/git/cm3' $RARGS && cm3 -ship $RARGS -DROOT='/home/rodney/proj/m3/git/cm3' +++ > > > > > > --- building in AMD64_LINUX --- > > > > > > > > > > > > ignoring ../src/m3overrides > > > > > > > > > > > > new source -> compiling RTHooks.i3 > > > > > > new source -> compiling RT0.i3 > > > > > > > > > > > > When it works, the copying of both cm3 and cm3cg to the bin directory is delayed until after both have been > > > > > > built, in the 'install-cm3-compiler.sh upgrade' step. > > > > > > > > > > > > I see your build is using a full path to the bin directory and mine is letting > > > > > > it come from the usual $PATH search, but that should make no difference, as long > > > > > > as the bin directory is found in a consistent way, which seems to be the case > > > > > > in both builds. > > > > > > > > > > > > > > > > > > > > > > > > On 05/29/2015 04:51 AM, John Marino wrote: > > > > > >> On 5/29/2015 11:39, Olaf Wagner wrote: > > > > > >>> On Fri, 29 May 2015 11:10:50 +0200 > > > > > >>> John Marino wrote: > > > > > >>> > > > > > >>>> On 5/29/2015 10:54, Olaf Wagner wrote: > > > > > >>>>> Please try what I suggested in the attached mail: define > > > > > >>>>> INSTALL_CM3_IN_BIN=yes > > > > > >>>>> in the environment and see if that helps. > > > > > >>>>> > > > > > >>>> > > > > > >>>> Unfortunately it seems the result is exactly the same, even when > > > > > >>>> INSTALL_CM3_IN_BIN is defined in the environment. > > > > > >>> > > > > > >>> Can I see the new logs? Has the new backend (cm3cg) been installed now? > > > > > >>> > > > > > >> > > > > > >> It's here: > > > > > >> http://leaf.dragonflybsd.org/~marino/m3c.log > > > > > >> > > > > > >> It never completes "do-cm3-front.sh buildship " > > > > > >> > > > > > >> Note that I'm using a bootstrap install and set INSTALL_ROOT to another > > > > > >> location, but it never gets to the point of installing anything. > > > > > >> > > > > > >> John > > > > > >> > > > > > > > > > > > > > > > > -- > > > > > Rodney Bates > > > > > rodney.m.bates at acm.org > > > > > > -- > > > Rodney Bates > > > rodney.m.bates at acm.org > > -- > Rodney Bates > rodney.m.bates at acm.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Sat May 30 18:38:46 2015 From: mika at async.caltech.edu (mika at async.caltech.edu) Date: Sat, 30 May 2015 09:38:46 -0700 Subject: [M3devel] The role INTEGER and subranges in Modula-3 In-Reply-To: <5569D3AA.2040009@lcwb.coop> References: <5569D3AA.2040009@lcwb.coop> Message-ID: <20150530163846.6EE551A2062@async.async.caltech.edu> Very clear explanation. I might even have been sold on LONGINT. Well, almost. Thanks for the explanation, anyhow! Mika "Rodney M. Bates" writes: >I am suspecting there is some misunderstanding about Modula-3's approach >to integer sizes. > >The original idea is to use subrange types, (which are >programmer-defined,) not different builtin types, to match the value >range you need. The safety rules of the language ensure that values >stored in variables are in the type's range. But all arithmetic is >done in the full native word size of the machine. > >Types are more abstract than most languages, in that different machine >representations (particularly, bit count) need not be different base >types in the language. > >There are no implicit type conversions. Instead, this need is met by >the concept of assignability. If the abstract value is in a >variable's range, it can be assigned to the variable. Size changes, >if needed, are the code generator's problem. > >All this drastically simplifies the language, while also allowing the >programmer to define an exact match between type-imposed value ranges >and what the application needs, rather than just a few powers of two. >Having implied type conversions, which also interact with sizes of >intermediate arithmetic results, requires many pages of language >definition that we avoid. > >LONGINT, which I have advocated, flies in the face of this tidy >scheme. If we could do all arithmetic efficiently in the biggest size >likely to be commonly needed, LONGINT would have no place. But native >sized arithmetic is always the most efficient. In today's world, >there are two very common classes of use cases: 1) 32-bit arithmetic >is wide enough, 2) 32-bit is not wide enough, but 64-bit is. In both >cases, on machines of either native arithmetic size, we want the best >efficiency. LONGINT is for case 2, and when you further need to be >able to run on either size of machine. INTEGER is for otherwise. > >Whether you believe in LONGINT or not, there is certainly no >justification for more base integer types than two: one the native >size of the machine and one bigger. > >Note that, as defined in Modula-3 today, INTEGER and LONGINT are >always distinct types (distinct, regardless of either their value >ranges or of the machine's native word size), with no subtype relation >between them, no assignability between them, no implied conversions >between them, no mixed arithmetic operators, no questions about >intermediate result range, and literals of unambiguous type. Thus we >stay out of the semantic tar pit most languages fall into with >multiple integer sizes, while giving the programmer drastically more >choices on range limits. > >Note that original Modula-3, in contrast to the single integer type, >has three floating point types, no doubt motivated by the messy >realities of taking full advantage of hardware-provided arithmetics. >These three have the same type isolation properties as INTEGER and >LONGINT, with the same consequences. In fact, the integer type >isolation is directly modeled after the floating type isolation. > >-- >Rodney Bates >rodney.m.bates at acm.org From jay.krell at cornell.edu Sat May 30 18:37:49 2015 From: jay.krell at cornell.edu (Jay K) Date: Sat, 30 May 2015 16:37:49 +0000 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop>, <55673AA4.8050100@marino.st>, <20150528190643.faf81897fc5698a06bf37838@elegosoft.com>, <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop>, <556817A1.2090206@marino.st>, <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de>, <55682D1A.2030504@marino.st>, <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de>, <55683689.2090709@marino.st>, , , <55688BFF.5040701@lcwb.coop>,,<5568955D.4060200@lcwb.coop>, ,,, , , <5568D5D1.5040405@lcwb.coop>, , , , <5569D017.5000201@lcwb.coop>, Message-ID: Here is the model to consider. Think of make install. In gcc and glibc, is it special cased? Probably not. Do they have an extra environment variable to turn it on/off? Probably not. Is it fraught with problems like cm3? Probably. Though DESTDIR is the safe way. The environment variable is a workaround for OS limitations, that may or may not exist. If it might exist anywhere, then all OS'es are treated consistently. If we can determine that it exists nowhere, then we can remove. The environment variable does not provide for shipping in the correct order. The user is obligated to do that. Removing the environment variable from cm3 and cm3cg is meant to work. You do this by splitting up build from ship. Build everything, then ship everything. Since shipping doesn't use cm3cg. If there are problems, they aren't found till the results are partly commited and must be backed out -- if you are shipping in-place. That is just the nature of it. That is why make install for glibc is particularly dangerous. My upgrade.py's use of buildship is probably not the right approach. That was probably a mistake and it is easy for me to fix. So it won't end up mattering -- nobody will ever ship cm3 or cm3cg. But when no incompatible change is being made, it is meant to just work. When an incompatible change is made, more care is meant to be taken. - Jay From: jay.krell at cornell.edu To: rodney.m.bates at acm.org Date: Sat, 30 May 2015 16:24:17 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 The variable is not for atomic update of multiple files. The variable exists because updating in-use files reportedly fails on some operating systems. Though I question the truth of even that. If we change ship to rename away upon copy failure, and find a reliable simple way to ensure eventual deletion of the renamed file, then we don't need this. I'll have to experiment on NT. Presumably we've written off Win9x, and I'm not sure about AIX. So consistency with cm3 isn't necessarily desirable/required. do-cm3-front.sh isn't necessarily meant to work when there is an IR change. perhaps m3cc wasn't supposed to be in front. I'll have to double check that later. upgrade.sh is meant to. It doesn't ship anything and manually copies both cm3 and cm3cg. So that still works. And upgrade.py handles it, but other way I think, so it doesn't work any longer. Perhaps the upgrade.sh approach is better and perhaps I missed this when I rewrote it. I can make it copy cm3cg manually. I haven't gotten a chance to fix anything yet. - Jay > Date: Sat, 30 May 2015 09:58:31 -0500 > From: rodney_bates at lcwb.coop > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > > > > On 05/29/2015 05:31 PM, Jay K wrote: > > cm3/cm3cg are more special than the others, because cm3 is statically linked. > > There is no m3core.dll, that cm3 uses, or m3quake.dll, etc. > > There is m3core.dll, but cm3 doesn't uses it. > > Shipping it doesn't affect the in-use cm3. > > > > > > If/when we fix this, in fact, we can stop doing that static linking. > > It makes sense for m3quake, etc. as there are few/no other users. > > But for libm3/m3core, it'll provide a nice size optimization. > > > > > > The mutual incompatibilty between old/new cm3/cm3cg is perfectly ok. > > It is meant to be dealt with, not avoided. > > > > I agree it's OK. Disallowing it would overly hamstring future development. > But dealing with it means we need to be able to prevent either package > immediately after it is built. > > > > > I believe upgrade.py did deal with this correctly, but this environment > > variable required to quash shipping of cm3cg broke it. > > > > > > The environment variable change really should imho be removed from cm3cg. > > Please. > > > > Jay, I am not sure what you are proposing. When I first looked at the commit for > this change, I was quite confused by my own change. While the comments say it > is to _not_ prematurely ship cm3cg, the code appears to add code to conditionally > ship if INSTALL_CM3_IN_BIN=yes. After the n-th look, I realized that before > the change, it _always_ shipped, regardless of the variable. So it really does > provide for less premature shipping. > > If I just revert it, do-cm3-front.sh will be unconditionally and unusably broken. > As is, it is at least usable if you don't set the variable. Even if there is > some use case where one would want it to ship, (none occurs to me), as is, you > can get this behavior by just setting the variable. > > Moreover, the current behavior for cm3cg is consistent with the current and > long-standing behavior for cm3, i.e., ship iff the variable is set. > > It would make more sense to me to remove the variable check by unconditionally > _not_ shipping. At least do-cm3-front.sh would be usable. But then, what > would be the purpose of the inconsistent use of the variable for cm3? > > > > > > > And then we can switch to "destdir" and remove all the in place updating, perhaps. > > > > > > Or I need to update upgrade.py to ship cm3cg itself. > > I guess I'll do that. > > > > > > upgrade.py may not have worked for you, but I have used it many many times. > > It worked. But currently it is probably broken by the m3cc/src/m3makefile change. > > I'll update it to accommodate that change.. > > > > > > And upgrade.sh I believe was in heavy use by Hudson. > > > > > > - Jay > > > > > > > > > Date: Fri, 29 May 2015 16:10:41 -0500 > > > From: rodney_bates at lcwb.coop > > > CC: m3devel at elegosoft.com > > > To: > > > Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > > > > > > Yes, we could have a better organization. I agree, the principal way > > > should be to build a complete set of everything that matters to the > > > implementation of the language, them replace them all at once. A > > > separate DESTDIR or such is needed. > > > > > > The set, as Jay points out, is larger than just cm3 and m3cc. It includes > > > at least m3core, probably libm3, and cm3, the executable depends on several > > > separately built packages--cm3, m3middle, m3front, m3quake, m3makefile, etc. > > > > > > In general, we can't really assume anything about the kinds of dependencies > > > of one package on old or new versions of another. Right now, cm3 and m3cc > > > are known mutually incompatible between 5.8 and the head, because the numbering > > > in M3CG_Binary.i3 has changed. We could probably establish some coding rules and > > > order-of-install rules that would allow a newer m3cc to work with an older cm3, > > > but that's only one pattern. > > > > > > I once thought do-cm3-*.sh build would do what we are talking about, but it > > > if I remember right, puts every package into immediate use as it is built > > > and also uses overrides, which keeps things inside the source tree, but makes > > > it unshippable. So I always use buildship. This has never, to my knowledge > > > run afoul of any compatibility problem other than between cm3 and m3cc, but it > > > does ship every package besides these two as it is built, so the potential > > > is there. > > > > > > I haven't had the energy to even try to understand just what the upgrade > > > scripts do, but they have not treated me well. If I had done different > > > patterns of incompatible changes, they would probably have been better > > > than the procedure I use. > > > > > > On 05/29/2015 01:06 PM, Jay K wrote: > > > > > I don't see an easy way to make the variable work, as there is no > > > > > constraint on the order that cm3 and cm3cg are built. do-cm3-front.sh > > > > > happens to do cm3cg first, but that is not necessarily required. > > > > > > > > [please pardon my editing...] > > > > > > > > > > > > I see what you mean that cm3cg is an independent node in the graph and can be built in any order, > > > > but, I guess, the story is/was, you have to know the safe order to ship things. > > > > > > > > > > > > It is encoded in pkginfo.txt and the Python scripts honor it..though they don't always use pkginfo.txt for their ordering.. > > > > And encoding the dependency graph there isn't ideal. It is really encoded in the import declarations > > > > in the m3makefiles, usually, but not in this case... > > > > > > > > > > > > The way that works is to build but don't ship cm3cg. > > > > Then ship cm3cg. > > > > Then copy cm3. > > > > Then use the new cm3. > > > > But perhaps it isn't strictly enforced enough. > > > > > > > > > > > > > > > > I used do this fairly often. > > > > Though breaking changes in cm3cg were rare, granted. > > > > But I'd also occasionally bootstrap from an older release. > > > > I'll have to try to do that again soon -- actually make the current > > > > tree easily buildable from the last release. > > > > > > > > > > > > update.py handled it. > > > > > > > > > > > > I'm on the fence. > > > > "buildship" of multiple packages is in general problematic. > > > > I kinda think the whole mechanism needs to be revampled. > > > > > > > > > > > > Let me draw a close analogy. > > > > > > > > > > > > In the slightly larger software world we have: > > > > > > > > make > > > > make install > > > > make install DESTDIR=somewhere_new > > > > > > > > > > > > buildship is equivalent make && make install, or a make install that includes the make part, > > > > as they sometimes do. > > > > Read up on building glibc and they point out how dangerous this is -- how dangerous make install is w/o DESTDIR. > > > > We have the same danger on a smaller scale. > > > > You aren't going to break the "OS", but you can break "cm3". > > > > > > > > > > > > The safe recommendation is make install DESTDIR. > > > > Basically "install" "everything" "on the side", get it all installed, multiple > > > > "packages", then copy or tar/untar it all. Or chroot into it and test it out, and > > > > then do an in-place update. Or swap into the chroot and never return? (tail call install) > > > > > > > > > > > > Don't do a "rolling upgrade". Don't install each package as it is built. No package, no cm3, > > > > not cm3cg, nothing. > > > > > > > > > > > > I'm basically suggesting that. > > > > > > > > > > > > Now, if you say "don't ever ship, but somehow otherwise manually copy", well > > > > that does kind of resolve to the same thing. > > > > > > > > > > > > If you say, "almost don't ever ship, but provide a way to", that is almost the same. > > > > > > > > > > > > make-dist.py follows the make install DESTDIR way. > > > > > > > > It is "better" I guess because I wrote it later, and because I was following > > > > the example of the other .sh files that make distributions. So blame/credit Olaf? :) > > > > > > > > > > > > It starts with a working compiler, copies parts into /temp, builds a new compiler into /tmp, and > > > > uses what it builds to build everything. > > > > > > > > > > > > Again I suggest it be looked into, and maybe be promoted as basically > > > > the replacement for upgrade.py and upgrade.sh. > > > > > > > > > > > > upgrade.py could wrap it and do the final steps of copy/untar in-place. > > > > Or make-dist.py could just print the last optional command. > > > > > > > > > > > > Anyway, I have no time lately, just email. :( > > > > > > > > > > > > - Jay > > > > > > > > > > > > > > > > > Date: Fri, 29 May 2015 11:35:41 -0500 > > > > > From: rodney_bates at lcwb.coop > > > > > To: adacore at marino.st; wagner at elego.de > > > > > CC: m3devel at elegosoft.com > > > > > Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > > > > > > > > > > Setting INSTALL_CM3_IN_BIN=yes is what forces the premature install of cm3cg. > > > > > I see I had encountered this problem two years ago, but then it was happening > > > > > regardless of the value of this variable. My fix only addresses the case when > > > > > the variable is not set. I naively went to extra trouble to preserve the > > > > > existing behavior when it is set--obviously not right. > > > > > > > > > > I don't see an easy way to make the variable work, as there is no > > > > > constraint on the order that cm3 and cm3cg are built. do-cm3-front.sh > > > > > happens to do cm3cg first, but that is not necessarily required. > > > > > > > > > > So INSTALL_CM3_IN_BIN is broken and hard to fix, if the two need > > > > > compatible upgrades. For now, it looks like install-cm3-compiler.sh > > > > > is the only working way. > > > > > > > > > > But maybe John and Olaf have found a different way around this. > > > > > > > > > > On 05/29/2015 10:55 AM, Rodney M. Bates wrote: > > > > > > I don't know yet why, or what needs to change, but here is definitely the problem, starting > > > > > > in line 4575 of your m3c log: > > > > > > > > > > > > > > > > > > g++48 -O2 -pipe -fstack-protector -Wl,-rpath=/usr/local/lib/gcc48 -fno-strict-aliasing -Wl,-rpath=/usr/local/lib/gcc48 -DIN_GCC -Wno-missing-field-initializers -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -o m3cgc1 m3cg/parse.o attribs.o main.o tree-browser.o libbackend.a libcommon-target.a libcommon.a ../libcpp/libcpp.a libcommon.a ../libcpp/libcpp.a ../libiberty/libiberty.a > > > > > > gmake[1]: Leaving directory `/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a/m3-sys/m3cc/AMD64_FREEBSD/gcc' > > > > > > > > > > > > > > > > > > This is copying the newly-built cm3cg (the compiler back end) to your > > > > > > bin directory: > > > > > > > > > > > > Forced ship of cm3cg. > > > > > > --- shipping from AMD64_FREEBSD --- > > > > > > > > > > > > . => /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin > > > > > > cm3cg > > > > > > ==> m3-sys/m3cc done > > > > > > > > > > > > === package m3-libs/m3core === > > > > > > > > > > > > And this is using the cm3 (compiler front end) that was already in the bin > > > > > > directory, and is the release version. > > > > > > > > > > > > +++ /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin/cm3 -build -DROOT='/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a' $RARGS && /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin/cm3 -ship $RARGS -DROOT='/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a' +++ > > > > > > --- building in AMD64_FREEBSD --- > > > > > > > > > > > > ignoring ../src/m3overrides > > > > > > > > > > > > new source -> compiling RTHooks.i3 > > > > > > > > > > > > This is cm3cg (aka m3cgc1) detecting the incompatibility: > > > > > > > > > > > > m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > > > > > > compilation terminated. > > > > > > > > > > > > Here is the counterpart section of my log: > > > > > > > > > > > > g++ -g -O2 -DIN_GCC -Wno-missing-field-initializers -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -o m3cgc1 m3cg/parse.o attribs.o main.o tree-browser.o libbackend.a libcommon-target.a libcommon.a ../libcpp/libcpp.a libcommon.a ../libcpp/libcpp.a ../libiberty/libiberty.a > > > > > > > > > > > > On my build, it's not shipping: > > > > > > > > > > > > Not shipping cm3cg. > > > > > > --- shipping from AMD64_LINUX --- > > > > > > > > > > > > missing ".M3SHIP" file, build the package first. > > > > > > ==> /home/rodney/proj/m3/git/cm3/m3-sys/m3cc done > > > > > > > > > > > > === package /home/rodney/proj/m3/git/cm3/m3-libs/m3core === > > > > > > +++ cm3 -build -DROOT='/home/rodney/proj/m3/git/cm3' $RARGS && cm3 -ship $RARGS -DROOT='/home/rodney/proj/m3/git/cm3' +++ > > > > > > --- building in AMD64_LINUX --- > > > > > > > > > > > > ignoring ../src/m3overrides > > > > > > > > > > > > new source -> compiling RTHooks.i3 > > > > > > new source -> compiling RT0.i3 > > > > > > > > > > > > When it works, the copying of both cm3 and cm3cg to the bin directory is delayed until after both have been > > > > > > built, in the 'install-cm3-compiler.sh upgrade' step. > > > > > > > > > > > > I see your build is using a full path to the bin directory and mine is letting > > > > > > it come from the usual $PATH search, but that should make no difference, as long > > > > > > as the bin directory is found in a consistent way, which seems to be the case > > > > > > in both builds. > > > > > > > > > > > > > > > > > > > > > > > > On 05/29/2015 04:51 AM, John Marino wrote: > > > > > >> On 5/29/2015 11:39, Olaf Wagner wrote: > > > > > >>> On Fri, 29 May 2015 11:10:50 +0200 > > > > > >>> John Marino wrote: > > > > > >>> > > > > > >>>> On 5/29/2015 10:54, Olaf Wagner wrote: > > > > > >>>>> Please try what I suggested in the attached mail: define > > > > > >>>>> INSTALL_CM3_IN_BIN=yes > > > > > >>>>> in the environment and see if that helps. > > > > > >>>>> > > > > > >>>> > > > > > >>>> Unfortunately it seems the result is exactly the same, even when > > > > > >>>> INSTALL_CM3_IN_BIN is defined in the environment. > > > > > >>> > > > > > >>> Can I see the new logs? Has the new backend (cm3cg) been installed now? > > > > > >>> > > > > > >> > > > > > >> It's here: > > > > > >> http://leaf.dragonflybsd.org/~marino/m3c.log > > > > > >> > > > > > >> It never completes "do-cm3-front.sh buildship " > > > > > >> > > > > > >> Note that I'm using a bootstrap install and set INSTALL_ROOT to another > > > > > >> location, but it never gets to the point of installing anything. > > > > > >> > > > > > >> John > > > > > >> > > > > > > > > > > > > > > > > -- > > > > > Rodney Bates > > > > > rodney.m.bates at acm.org > > > > > > -- > > > Rodney Bates > > > rodney.m.bates at acm.org > > -- > Rodney Bates > rodney.m.bates at acm.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From estellnb at elstel.org Sat May 30 18:33:26 2015 From: estellnb at elstel.org (Elmar Stellnberger) Date: Sat, 30 May 2015 18:33:26 +0200 Subject: [M3devel] The role INTEGER and subranges in Modula-3 In-Reply-To: <5569D3AA.2040009@lcwb.coop> References: <5569D3AA.2040009@lcwb.coop> Message-ID: <5569E656.6080909@elstel.org> Am 30.05.15 um 17:13 schrieb Rodney M. Bates: > There are no implicit type conversions. Instead, this need is met by > the concept of assignability. If the abstract value is in a > variable's range, it can be assigned to the variable. Size changes, > if needed, are the code generator's problem. So what does the code generator do if there is an overflow not checked by the predefined value range (i.e. BITS 8 FOR INTEGER instead of BITS 8 for [0..255]) > All this drastically simplifies the language, while also allowing the ... Yes, I understand your decision. > likely to be commonly needed, LONGINT would have no place. But native > sized arithmetic is always the most efficient. In today's world, > there are two very common classes of use cases: 1) 32-bit arithmetic > is wide enough, 2) 32-bit is not wide enough, but 64-bit is. In both > cases, on machines of either native arithmetic size, we want the best > efficiency. LONGINT is for case 2, and when you further need to be > able to run on either size of machine. INTEGER is for otherwise. Well, that was exactly my argument for a language specified type size of INTEGER, because things do not get faster if you use 64bit integers instead of 32bit integers. CPU arithmetics perhaps but the real bottleneck of today is the memory hierarchy - and using 64bit integers doubles our memory need at least for scalars. > > Whether you believe in LONGINT or not, there is certainly no > justification for more base integer types than two: one the native > size of the machine and one bigger. Yes, we really don`t need them as anything becomes 64bit or the native word size respectively on the stack (that is why Ctypes.int works). Memory latency should be a minor issue as long as our parameters and parts of the activation records fit into the cache. From estellnb at elstel.org Sat May 30 18:51:12 2015 From: estellnb at elstel.org (Elmar Stellnberger) Date: Sat, 30 May 2015 18:51:12 +0200 Subject: [M3devel] 64bit INTEGERs, WIDECHAR: language specified or configuration/target dependent? In-Reply-To: <55679CA8.2030905@lcwb.coop> References: <555E14BC.2040805@lcwb.coop> <555E203E.4040203@elstel.org> <0A1CDD8C-EEB5-40E2-A38B-28E8EEA8C37E@elstel.org> <8A3AB2ED-C11E-4787-A7F8-C8F12157EAA5@elstel.org> <555F6D8F.4070109@lcwb.coop> <6F9B9534-7DC2-4D4D-88CB-90D7FA05E8F9@elstel.org> <8BBBC94B-EECC-464A-86BB-FD1C94EC5496@elstel.org> <77605189-D966-4D4B-8946-838BD6E178AA@purdue.edu> <55675464.5090306@elstel.org> <5567723D.3020706@elstel.org> <55679CA8.2030905@lcwb.coop> Message-ID: <5569EA80.7050700@elstel.org> > Well, maybe not stack variables, if the stack has a bigger alignment > to be honored, > quite possibly a hardware requirement. No doubt taking and using the > address of > such would be endian-dependent. Would a C compiler do differently in > this case? > Can you rely on them all doing it the same? Does C specify it? No, as far as I know C can provide multiple calling conventions. However any x86 based system has a word size aligned stack. No way to push or pop half of a word. That way we are at least save for any x86 Intel/AMD - system. From jay.krell at cornell.edu Sat May 30 23:55:06 2015 From: jay.krell at cornell.edu (Jay K) Date: Sat, 30 May 2015 21:55:06 +0000 Subject: [M3devel] 64bit INTEGERs, WIDECHAR: language specified or configuration/target dependent? In-Reply-To: <5569EA80.7050700@elstel.org> References: <555E14BC.2040805@lcwb.coop> <555E203E.4040203@elstel.org> <0A1CDD8C-EEB5-40E2-A38B-28E8EEA8C37E@elstel.org> <8A3AB2ED-C11E-4787-A7F8-C8F12157EAA5@elstel.org> <555F6D8F.4070109@lcwb.coop> <6F9B9534-7DC2-4D4D-88CB-90D7FA05E8F9@elstel.org> <8BBBC94B-EECC-464A-86BB-FD1C94EC5496@elstel.org> <77605189-D966-4D4B-8946-838BD6E178AA@purdue.edu> <55675464.5090306@elstel.org> <5567723D.3020706@elstel.org>, <55679CA8.2030905@lcwb.coop>, <5569EA80.7050700@elstel.org> Message-ID: > No way to push or pop half of a word. sub esp, 2 But nobody does that. Parameters may generally fill whole words, but I doubt locals do. - Jay > Date: Sat, 30 May 2015 18:51:12 +0200 > From: estellnb at elstel.org > To: rodney.m.bates at acm.org; m3devel at elegosoft.com > Subject: Re: [M3devel] 64bit INTEGERs, WIDECHAR: language specified or configuration/target dependent? > > > > Well, maybe not stack variables, if the stack has a bigger alignment > > to be honored, > > quite possibly a hardware requirement. No doubt taking and using the > > address of > > such would be endian-dependent. Would a C compiler do differently in > > this case? > > Can you rely on them all doing it the same? Does C specify it? > No, as far as I know C can provide multiple calling conventions. > However any x86 based system has a word size aligned stack. > No way to push or pop half of a word. That way we are at least save > for any x86 Intel/AMD - system. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.mckinna at gmail.com Sun May 31 01:06:26 2015 From: peter.mckinna at gmail.com (Peter McKinna) Date: Sun, 31 May 2015 09:06:26 +1000 Subject: [M3devel] extended Message-ID: Hi While we are on the subject of integer types can we diverge slightly to floating point types. I wonder if anyone can explain why the extended type is treated exactly the same as longreal in the frontend? They have the same sizes and ranges and precisions. As for backends, at the moment m3cc is generating 8 byte sse instructions for both types. The llvm is generating 10 byte float instructions as per its x86fp80 type which are a fair bit slower at the expense of greater range and precision. However they are not interoperable with legacy libraries and we should probably change the type to agree with m3cc and the frontend. It seems that the 8087 80 bit float is being phased out see http://csapp.cs.cmu.edu/2e/waside/waside-x87.pdf so maybe the m3 implementors saw the writing on the wall and and decided to wait for hardware to catch up. Anyway I wonder if its worth considering making extended one of the 128 bit floating point types which although emulated in software would at least give us a different type and one which would give some applications a huge precision (and range ~10^4090) boost. Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun May 31 03:52:41 2015 From: jay.krell at cornell.edu (Jay K) Date: Sun, 31 May 2015 01:52:41 +0000 Subject: [M3devel] extended In-Reply-To: References: Message-ID: Half seriously: Do we need FLOAT32, FLOAT64, FLOAT80, FLOAT128? And some way to indicate what is available? On many/most/but-not-all modern 32bit x86 systems, "long double" is the same as "double". Modula-3 is in agreement with many/most/but-not-all C systems. m3cc might be using x87 instructions on some platforms, at least sometimes. But that doesn't change in-memory extended to other than 64 bits. Just temporary in-register values might be 80 bits. - Jay Date: Sun, 31 May 2015 09:06:26 +1000 From: peter.mckinna at gmail.com To: m3devel at elegosoft.com Subject: [M3devel] extended Hi While we are on the subject of integer types can we diverge slightly to floating point types. I wonder if anyone can explain why the extended type is treated exactly the same as longreal in the frontend? They have the same sizes and ranges and precisions. As for backends, at the moment m3cc is generating 8 byte sse instructions for both types. The llvm is generating 10 byte float instructions as per its x86fp80 type which are a fair bit slower at the expense of greater range and precision. However they are not interoperable with legacy libraries and we should probably change the type to agree with m3cc and the frontend. It seems that the 8087 80 bit float is being phased out see http://csapp.cs.cmu.edu/2e/waside/waside-x87.pdfso maybe the m3 implementors saw the writing on the wall and and decided to wait for hardware to catch up. Anyway I wonder if its worth considering making extended one of the 128 bit floating point types which although emulated in software would at least give us a different type and one which would give some applications a huge precision (and range ~10^4090) boost. Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Sun May 31 04:09:46 2015 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Sat, 30 May 2015 22:09:46 -0400 Subject: [M3devel] extended In-Reply-To: References: Message-ID: <20150531020946.GA10463@topoi.pooq.com> On Sun, May 31, 2015 at 01:52:41AM +0000, Jay K wrote: > Half seriously: Do we need FLOAT32, FLOAT64, FLOAT80, FLOAT128? > And some way to indicate what is available? Those who do serious numerical analysis for a iving are very careful of their precisions. They really care about these datails to an extent most of us mortalls don't. I've even had freinds complain about compilers that gave them *more* precision than they had asked for. -- hendrik > > > On many/most/but-not-all modern 32bit x86 systems, "long double" is the > same as "double". Modula-3 is in agreement with many/most/but-not-all C systems. > > > m3cc might be using x87 instructions on some platforms, at least sometimes. > But that doesn't change in-memory extended to other than 64 bits. > Just temporary in-register values might be 80 bits. > > > - Jay > > > > Date: Sun, 31 May 2015 09:06:26 +1000 > From: peter.mckinna at gmail.com > To: m3devel at elegosoft.com > Subject: [M3devel] extended > > Hi > While we are on the subject of integer types can we diverge slightly to floating point types. I wonder if anyone can explain why the extended type is treated exactly the same as longreal in the frontend? They have the same sizes and ranges and precisions. As for backends, at the moment m3cc is generating 8 byte sse instructions for both types. The llvm is generating 10 byte float instructions as per its x86fp80 type which are a fair bit slower at the expense of greater range and precision. However they are not interoperable with legacy libraries and we should probably change the type to agree with m3cc and the frontend. It seems that the 8087 80 bit float is being phased out see http://csapp.cs.cmu.edu/2e/waside/waside-x87.pdfso maybe the m3 implementors saw the writing on the wall and and decided to wait for hardware to catch up. Anyway I wonder if its worth considering making extended one of the 128 bit floating point types which although emulated in software would at least give us a different type and one which would give some applications a huge precision (and range ~10^4090) boost. > Peter From mika at async.caltech.edu Sun May 31 04:18:31 2015 From: mika at async.caltech.edu (mika at async.caltech.edu) Date: Sat, 30 May 2015 19:18:31 -0700 Subject: [M3devel] extended In-Reply-To: <20150531020946.GA10463@topoi.pooq.com> References: <20150531020946.GA10463@topoi.pooq.com> Message-ID: <20150531021831.160751A2062@async.async.caltech.edu> Yes, it is standard practice to write x87 registers to memory and read them back to guarantee one is not getting "extended" precision by mistake. Modula-3 does a pretty good job of defining what all the floating formats are, if you look at the various interfaces for the formats. I seem to remember the story is that one of Kahan's grad students was interning at SRC one summer and wrote the interfaces. "Among the best in the business." Mika Hendrik Boom writes: >On Sun, May 31, 2015 at 01:52:41AM +0000, Jay K wrote: >> Half seriously: Do we need FLOAT32, FLOAT64, FLOAT80, FLOAT128? >> And some way to indicate what is available? > >Those who do serious numerical analysis for a iving are very careful of=20 >their precisions. > >They really care about these datails to an extent most of us mortalls=20 >don't. > >I've even had freinds complain about compilers that gave them *more*=20 >precision than they had asked for. > >-- hendrik > >>=20 >> =20 >> On many/most/but-not-all modern 32bit x86 systems, "long double" is the >> same as "double". Modula-3 is in agreement with many/most/but-not-all C s= >ystems. >> =20 >>=20 >> m3cc might be using x87 instructions on some platforms, at least sometime= >s. >> But that doesn't change in-memory extended to other than 64 bits. >> Just temporary in-register values might be 80 bits. >> =20 >>=20 >> - Jay >>=20 >>=20 >> =20 >> Date: Sun, 31 May 2015 09:06:26 +1000 >> From: peter.mckinna at gmail.com >> To: m3devel at elegosoft.com >> Subject: [M3devel] extended >>=20 >> Hi >> While we are on the subject of integer types can we diverge slightly to= > floating point types. I wonder if anyone can explain why the extended type= > is treated exactly the same as longreal in the frontend? They have the sam= >e sizes and ranges and precisions. As for backends, at the moment m3cc i= >s generating 8 byte sse instructions for both types. The llvm is generating= > 10 byte float instructions as per its x86fp80 type which are a fair bit sl= >ower at the expense of greater range and precision. However they are not in= >teroperable with legacy libraries and we should probably change the type to= > agree with m3cc and the frontend. It seems that the 8087 80 bit float is = >being phased out see http://csapp.cs.cmu.edu/2e/waside/waside-x87.pdfso may= >be the m3 implementors saw the writing on the wall and and decided to wait = >for hardware to catch up. Anyway I wonder if its worth considering making e= >xtended one of the 128 bit floating point types which although emulated in = >software would at least give us a different type and one which would give s= >ome applications a huge precision (and range ~10^4090) boost. >> Peter =20 From jay.krell at cornell.edu Sun May 31 06:43:07 2015 From: jay.krell at cornell.edu (Jay K) Date: Sun, 31 May 2015 04:43:07 +0000 Subject: [M3devel] extended In-Reply-To: <20150531021831.160751A2062@async.async.caltech.edu> References: , , <20150531020946.GA10463@topoi.pooq.com>, <20150531021831.160751A2062@async.async.caltech.edu> Message-ID: Modula-3 may be good, but it isn't likely unique here. Apple did a good job probably. C9x caught up probably. - Jay > To: hendrik at topoi.pooq.com > Date: Sat, 30 May 2015 19:18:31 -0700 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] extended > > > Yes, it is standard practice to write x87 registers to memory and read > them back to guarantee one is not getting "extended" precision by mistake. > > Modula-3 does a pretty good job of defining what all the floating formats > are, if you look at the various interfaces for the formats. > > I seem to remember the story is that one of Kahan's grad students was > interning at SRC one summer and wrote the interfaces. > > "Among the best in the business." > > Mika > > Hendrik Boom writes: > >On Sun, May 31, 2015 at 01:52:41AM +0000, Jay K wrote: > >> Half seriously: Do we need FLOAT32, FLOAT64, FLOAT80, FLOAT128? > >> And some way to indicate what is available? > > > >Those who do serious numerical analysis for a iving are very careful of=20 > >their precisions. > > > >They really care about these datails to an extent most of us mortalls=20 > >don't. > > > >I've even had freinds complain about compilers that gave them *more*=20 > >precision than they had asked for. > > > >-- hendrik > > > >>=20 > >> =20 > >> On many/most/but-not-all modern 32bit x86 systems, "long double" is the > >> same as "double". Modula-3 is in agreement with many/most/but-not-all C s= > >ystems. > >> =20 > >>=20 > >> m3cc might be using x87 instructions on some platforms, at least sometime= > >s. > >> But that doesn't change in-memory extended to other than 64 bits. > >> Just temporary in-register values might be 80 bits. > >> =20 > >>=20 > >> - Jay > >>=20 > >>=20 > >> =20 > >> Date: Sun, 31 May 2015 09:06:26 +1000 > >> From: peter.mckinna at gmail.com > >> To: m3devel at elegosoft.com > >> Subject: [M3devel] extended > >>=20 > >> Hi > >> While we are on the subject of integer types can we diverge slightly to= > > floating point types. I wonder if anyone can explain why the extended type= > > is treated exactly the same as longreal in the frontend? They have the sam= > >e sizes and ranges and precisions. As for backends, at the moment m3cc i= > >s generating 8 byte sse instructions for both types. The llvm is generating= > > 10 byte float instructions as per its x86fp80 type which are a fair bit sl= > >ower at the expense of greater range and precision. However they are not in= > >teroperable with legacy libraries and we should probably change the type to= > > agree with m3cc and the frontend. It seems that the 8087 80 bit float is = > >being phased out see http://csapp.cs.cmu.edu/2e/waside/waside-x87.pdfso may= > >be the m3 implementors saw the writing on the wall and and decided to wait = > >for hardware to catch up. Anyway I wonder if its worth considering making e= > >xtended one of the 128 bit floating point types which although emulated in = > >software would at least give us a different type and one which would give s= > >ome applications a huge precision (and range ~10^4090) boost. > >> Peter =20 -------------- next part -------------- An HTML attachment was scrubbed... URL: From adacore at marino.st Sun May 31 09:41:16 2015 From: adacore at marino.st (John Marino) Date: Sun, 31 May 2015 09:41:16 +0200 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <5568B352.8060005@marino.st> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop> <556817A1.2090206@marino.st> <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de> <55682D1A.2030504@marino.st> <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de> <55683689.2090709@marino.st> <20150529122732.1396eb079ff9b404bcb21e40@elego.de> <5568421D.3050209@marino.st> <20150529155833.8454664b88391d93708e8f85@elego.de> <55687266.3090400@marino.st> <20150529162028.388911007a614006049beb42@elego.de> <20150529172305.a3fc2a9865b5250a5b9140fc@elego.de> <556885FD.6010800@marino.st> <20150529180223.d467621b68ebf665da685b12@elego.de> <55689065.1040207@marino.st> <20150529201531.b35e3cfdafeb9e2735e0020b@elegosoft.com> <5568B352.8060005@marino.st> Message-ID: <556ABB1C.5080607@marino.st> On 5/29/2015 20:43, John Marino wrote: > On 5/29/2015 20:15, Olaf Wagner wrote: >> >> Well, yes, I understand that. I would have tried your exact setup, >> but I have no system available to test that on. >> >> At least I have validated that based on the origianl 5.8.6 installation >> archive for AMD64_FREEBSD you can build the new compiler from the current >> sources with a simple call of the upgrade.sh script. which I still doubted >> yesterday. > > > The card I still have left to play is to extract the bootstrap, let it > overwrite itself per Rodney's technique and then build the real compiler > (dumping the whole "intermediate" area). FWIW, this did not work either. Rodney's technique doesn't seem to work with the ports bootstrap. I don't know why it would work with provided 5.8.6 but not rebuilt one. As far as I can tell, I did what he said would always work. I'm at a loss as to where to go from here. It's starting to look like I have to throw away the ports 5.8.6 bootstrap and start over somehow. I don't think it should be this hard. :( John From jay.krell at cornell.edu Sun May 31 11:53:59 2015 From: jay.krell at cornell.edu (Jay K) Date: Sun, 31 May 2015 09:53:59 +0000 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <556ABB1C.5080607@marino.st> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop> <556817A1.2090206@marino.st> <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de> <55682D1A.2030504@marino.st> <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de> <55683689.2090709@marino.st> <20150529122732.1396eb079ff9b404bcb21e40@elego.de> <5568421D.3050209@marino.st> <20150529155833.8454664b88391d93708e8f85@elego.de> <55687266.3090400@marino.st> <20150529162028.388911007a614006049beb42@elego.de> <20150529172305.a3fc2a9865b5250a5b9140fc@elego.de> <556885FD.6010800@marino.st> <20150529180223.d467621b68ebf665da685b12@elego.de> <55689065.1040207@marino.st> <20150529201531.b35e3cfdafeb9e2735e0020b@elegosoft.com>, <5568B352.8060005@marino.st>, <556ABB1C.5080607@marino.st> Message-ID: John, have you tried make-dist.py? i.e. https://github.com/modula3/cm3/blob/master/scripts/python/make-dist.py While it might not be exactly what you need, it should demonstrate the elements. I will try to try this all soon, really, I hope so. It starts with a working compiler, does no in-place updates, build into a unique directory in /tmp, and gives you .tar.gz or such at the end. It does "min" and "all". If you set the STAGE environment variable, it uses that instead of /tmp. It should probably be called M3_STATE or M3_MAKEDIST_STAGE. - Jay > Date: Sun, 31 May 2015 09:41:16 +0200 > From: adacore at marino.st > To: m3devel at elegosoft.com > Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > > On 5/29/2015 20:43, John Marino wrote: > > On 5/29/2015 20:15, Olaf Wagner wrote: > >> > >> Well, yes, I understand that. I would have tried your exact setup, > >> but I have no system available to test that on. > >> > >> At least I have validated that based on the origianl 5.8.6 installation > >> archive for AMD64_FREEBSD you can build the new compiler from the current > >> sources with a simple call of the upgrade.sh script. which I still doubted > >> yesterday. > > > > > > The card I still have left to play is to extract the bootstrap, let it > > overwrite itself per Rodney's technique and then build the real compiler > > (dumping the whole "intermediate" area). > > FWIW, this did not work either. Rodney's technique doesn't seem to work > with the ports bootstrap. I don't know why it would work with provided > 5.8.6 but not rebuilt one. As far as I can tell, I did what he said > would always work. > > I'm at a loss as to where to go from here. It's starting to look like I > have to throw away the ports 5.8.6 bootstrap and start over somehow. I > don't think it should be this hard. :( > > John -------------- next part -------------- An HTML attachment was scrubbed... URL: From adacore at marino.st Sun May 31 16:57:02 2015 From: adacore at marino.st (John Marino) Date: Sun, 31 May 2015 16:57:02 +0200 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop> <556817A1.2090206@marino.st> <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de> <55682D1A.2030504@marino.st> <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de> <55683689.2090709@marino.st> <20150529122732.1396eb079ff9b404bcb21e40@elego.de> <5568421D.3050209@marino.st> <20150529155833.8454664b88391d93708e8f85@elego.de> <55687266.3090400@marino.st> <20150529162028.388911007a614006049beb42@elego.de> <20150529172305.a3fc2a9865b5250a5b9140fc@elego.de> <556885FD.6010800@marino.st> <20150529180223.d467621b68ebf665da685b12@elego.de> <55689065.1040207@marino.st> <20150529201531.b35e3cfdafeb9e2735e0020b@elegosoft.com>, <5568B352.8060005@marino.st>, <556ABB1C.5080607@marino.st> Message-ID: <556B213E.8030108@marino.st> On 5/31/2015 11:53, Jay K wrote: > John, have you tried make-dist.py? > i.e. https://github.com/modula3/cm3/blob/master/scripts/python/make-dist.py > > While it might not be exactly what you need, it should demonstrate the > elements. > > I will try to try this all soon, really, I hope so. > > It starts with a working compiler, does no in-place updates, build into > a unique directory in /tmp, and gives you .tar.gz or such at the end. > It does "min" and "all". > > If you set the STAGE environment variable, it uses that instead of /tmp. > It should probably be called M3_STATE or M3_MAKEDIST_STAGE. > > - Jay > Hi Jay, I'm getting the same error as always using make-dist script: http://leaf.dragonflybsd.org/~marino/m3d.log Thanks, John From jay.krell at cornell.edu Sun May 31 18:45:42 2015 From: jay.krell at cornell.edu (Jay K) Date: Sun, 31 May 2015 16:45:42 +0000 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <556B213E.8030108@marino.st> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop>, <55673AA4.8050100@marino.st>, <20150528190643.faf81897fc5698a06bf37838@elegosoft.com>, <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop>, <556817A1.2090206@marino.st>, <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de>, <55682D1A.2030504@marino.st>, <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de>, <55683689.2090709@marino.st>, <20150529122732.1396eb079ff9b404bcb21e40@elego.de>, <5568421D.3050209@marino.st>, <20150529155833.8454664b88391d93708e8f85@elego.de>, <55687266.3090400@marino.st>, <20150529162028.388911007a614006049beb42@elego.de>, <20150529172305.a3fc2a9865b5250a5b9140fc@elego.de>, <556885FD.6010800@marino.st>, <20150529180223.d467621b68ebf665da685b12@elego.de>, <55689065.1040207@marino.st>, <20150529201531.b35e3cfdafeb9e2735e0020b@elegosoft.com>, <5568B352.8060005@marino.st>, <556ABB1C.5080607@marino.st>, , <556B213E.8030108@marino.st> Message-ID: Hm. Strange. I need to read more closely. I see it skipping shipping, but my read was it didn't try that. So.. with INSTALL_CM3_IN_BIN=yes? I need to try this all, and "fix" it to set that. The whole thing in m3cc/src/m3makefile is relatively new vs. when I was actively using all this. :( - Jay > Date: Sun, 31 May 2015 16:57:02 +0200 > From: adacore at marino.st > To: jay.krell at cornell.edu; m3devel at elegosoft.com > Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > > On 5/31/2015 11:53, Jay K wrote: > > John, have you tried make-dist.py? > > i.e. https://github.com/modula3/cm3/blob/master/scripts/python/make-dist.py > > > > While it might not be exactly what you need, it should demonstrate the > > elements. > > > > I will try to try this all soon, really, I hope so. > > > > It starts with a working compiler, does no in-place updates, build into > > a unique directory in /tmp, and gives you .tar.gz or such at the end. > > It does "min" and "all". > > > > If you set the STAGE environment variable, it uses that instead of /tmp. > > It should probably be called M3_STATE or M3_MAKEDIST_STAGE. > > > > - Jay > > > > Hi Jay, > I'm getting the same error as always using make-dist script: > http://leaf.dragonflybsd.org/~marino/m3d.log > > Thanks, > John -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun May 31 19:09:24 2015 From: jay.krell at cornell.edu (Jay K) Date: Sun, 31 May 2015 17:09:24 +0000 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: References: <556700B0.8060500@marino.st>,<55672DC1.7080509@lcwb.coop>, <55673AA4.8050100@marino.st>, , <20150528190643.faf81897fc5698a06bf37838@elegosoft.com>, , <55679387.8040701@lcwb.coop>, <5567DA8C.3050802@lcwb.coop>, <556817A1.2090206@marino.st>, , <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de>, , <55682D1A.2030504@marino.st>, , <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de>, , <55683689.2090709@marino.st>, , <20150529122732.1396eb079ff9b404bcb21e40@elego.de>, , <5568421D.3050209@marino.st>, , <20150529155833.8454664b88391d93708e8f85@elego.de>, , <55687266.3090400@marino.st>, , <20150529162028.388911007a614006049beb42@elego.de>, , <20150529172305.a3fc2a9865b5250a5b9140fc@elego.de>, , <556885FD.6010800@marino.st>, , <20150529180223.d467621b68ebf665da685b12@elego.de>, , <55689065.1040207@marino.st>, , <20150529201531.b35e3cfdafeb9e2735e0020b@elegosoft.com>, , <5568B352.8060005@marino.st>, <556ABB1C.5080607@marino.st>, , , , <556B213E.8030108@marino.st>, Message-ID: Oh probably the problem is using the backend premature actually. Darn, I can't help right now. - Jay From: jay.krell at cornell.edu To: adacore at marino.st; m3devel at elegosoft.com Date: Sun, 31 May 2015 16:45:42 +0000 Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 Hm. Strange. I need to read more closely. I see it skipping shipping, but my read was it didn't try that. So.. with INSTALL_CM3_IN_BIN=yes? I need to try this all, and "fix" it to set that. The whole thing in m3cc/src/m3makefile is relatively new vs. when I was actively using all this. :( - Jay > Date: Sun, 31 May 2015 16:57:02 +0200 > From: adacore at marino.st > To: jay.krell at cornell.edu; m3devel at elegosoft.com > Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > > On 5/31/2015 11:53, Jay K wrote: > > John, have you tried make-dist.py? > > i.e. https://github.com/modula3/cm3/blob/master/scripts/python/make-dist.py > > > > While it might not be exactly what you need, it should demonstrate the > > elements. > > > > I will try to try this all soon, really, I hope so. > > > > It starts with a working compiler, does no in-place updates, build into > > a unique directory in /tmp, and gives you .tar.gz or such at the end. > > It does "min" and "all". > > > > If you set the STAGE environment variable, it uses that instead of /tmp. > > It should probably be called M3_STATE or M3_MAKEDIST_STAGE. > > > > - Jay > > > > Hi Jay, > I'm getting the same error as always using make-dist script: > http://leaf.dragonflybsd.org/~marino/m3d.log > > Thanks, > John -------------- next part -------------- An HTML attachment was scrubbed... URL: From adacore at marino.st Sun May 31 19:59:05 2015 From: adacore at marino.st (John Marino) Date: Sun, 31 May 2015 19:59:05 +0200 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: References: <556700B0.8060500@marino.st>, <55679387.8040701@lcwb.coop>, <5567DA8C.3050802@lcwb.coop>, <556817A1.2090206@marino.st>, , <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de>, , <55682D1A.2030504@marino.st>, , <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de>, , <55683689.2090709@marino.st>, , <20150529122732.1396eb079ff9b404bcb21e40@elego.de>, , <5568421D.3050209@marino.st>, , <20150529155833.8454664b88391d93708e8f85@elego.de>, , <55687266.3090400@marino.st>, , <20150529162028.388911007a614006049beb42@elego.de>, , <20150529172305.a3fc2a9865b5250a5b9140fc@elego.de>, , <556885FD.6010800@marino.st>, , <20150529180223.d467621b68ebf665da685b12@elego.de>, , <55689065.1040207@marino.st>, , <20150529201531.b35e3cfdafeb9e2735e0020b@elegosoft.com>, , <5568B352.8060005@marino.st>, <556ABB1C.5080607@marino.st>, , , , <556B213E.8030108@marino.st>, Message-ID: <556B4BE9.1000902@marino.st> I removed "INSTALL_CM3_IN_BIN=yes" after reading the thread about it. Should I put it back? From the last response I'm guessing that wasn't the problem. John On 5/31/2015 19:09, Jay K wrote: > Oh probably the problem is using the backend premature actually. > Darn, I can't help right now. > > - Jay > > > > ------------------------------------------------------------------------ > From: jay.krell at cornell.edu > To: adacore at marino.st; m3devel at elegosoft.com > Date: Sun, 31 May 2015 16:45:42 +0000 > Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp > (0x100), expected 0x110 > > Hm. Strange. I need to read more closely. I see it skipping shipping, > but my read was it didn't try that. > So.. with INSTALL_CM3_IN_BIN=yes? > I need to try this all, and "fix" it to set that. The whole thing in > m3cc/src/m3makefile is relatively > new vs. when I was actively using all this. :( > > - Jay > > >> Date: Sun, 31 May 2015 16:57:02 +0200 >> From: adacore at marino.st >> To: jay.krell at cornell.edu; m3devel at elegosoft.com >> Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp > (0x100), expected 0x110 >> >> On 5/31/2015 11:53, Jay K wrote: >> > John, have you tried make-dist.py? >> > i.e. > https://github.com/modula3/cm3/blob/master/scripts/python/make-dist.py >> > >> > While it might not be exactly what you need, it should demonstrate the >> > elements. >> > >> > I will try to try this all soon, really, I hope so. >> > >> > It starts with a working compiler, does no in-place updates, build into >> > a unique directory in /tmp, and gives you .tar.gz or such at the end. >> > It does "min" and "all". >> > >> > If you set the STAGE environment variable, it uses that instead of /tmp. >> > It should probably be called M3_STATE or M3_MAKEDIST_STAGE. >> > >> > - Jay >> > >> >> Hi Jay, >> I'm getting the same error as always using make-dist script: >> http://leaf.dragonflybsd.org/~marino/m3d.log >> >> Thanks, >> John From estellnb at elstel.org Sun May 31 19:50:21 2015 From: estellnb at elstel.org (Elmar Stellnberger) Date: Sun, 31 May 2015 19:50:21 +0200 Subject: [M3devel] cm3/m3quake: setting environment variables for exec Message-ID: <556B49DD.20909@elstel.org> How can I set environment variables for exec with cm3? Using /usr/bin/env would be inherently non-portable. With SRC M3 I remember this was the 4th parameter or so. However cm3 exec seems to do something very different. From rodney_bates at lcwb.coop Sun May 31 20:30:46 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sun, 31 May 2015 13:30:46 -0500 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <556B4BE9.1000902@marino.st> References: <556700B0.8060500@marino.st>, <5567DA8C.3050802@lcwb.coop>, <556817A1.2090206@marino.st>, , <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de>, , <55682D1A.2030504@marino.st>, , <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de>, , <55683689.2090709@marino.st>, , <20150529122732.1396eb079ff9b404bcb21e40@elego.de>, , <5568421D.3050209@marino.st>, , <20150529155833.8454664b88391d93708e8f85@elego.de>, , <55687266.3090400@marino.st>, , <20150529162028.388911007a614006049beb42@elego.de>, , <20150529172305.a3fc2a9865b5250a5b9140fc@elego.de>, , <556885FD.6010800@marino.st>, , <20150529180223.d467621b68ebf665da685b12@elego.de>, , <55689065.1040207@marino.st>, , <20150529201531.b35e3cfdafeb9e2735e0020b@elegosoft.com>, , <5568B352.8060005@marino.st>, <556ABB1C.5080607@marino.st>, , , , <556B213E.8030108@marino.st>, <556B4BE9.1000902@marino .st> Message-ID: <556B5356.40809@lcwb.coop> On 05/31/2015 12:59 PM, John Marino wrote: > I removed "INSTALL_CM3_IN_BIN=yes" after reading the thread about it. > Should I put it back? From the last response I'm guessing that wasn't > the problem. > > John > It apparently wasn't the only problem, but it definitely was a problem. Don't put it back. I causes the new cm3cg executable to be copied to your bin directory immediately after it has been built. It is incompatible with the old cm3 executable, and the next attempted build (m3core, as I remember) runs the old cm3, then the new cm3cg, which correctly recognizes that its input is in an old version format and refuses, giving the error message. > > On 5/31/2015 19:09, Jay K wrote: >> Oh probably the problem is using the backend premature actually. >> Darn, I can't help right now. >> >> - Jay >> >> >> >> ------------------------------------------------------------------------ >> From: jay.krell at cornell.edu >> To: adacore at marino.st; m3devel at elegosoft.com >> Date: Sun, 31 May 2015 16:45:42 +0000 >> Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp >> (0x100), expected 0x110 >> >> Hm. Strange. I need to read more closely. I see it skipping shipping, >> but my read was it didn't try that. >> So.. with INSTALL_CM3_IN_BIN=yes? >> I need to try this all, and "fix" it to set that. The whole thing in >> m3cc/src/m3makefile is relatively >> new vs. when I was actively using all this. :( >> >> - Jay >> >> >>> Date: Sun, 31 May 2015 16:57:02 +0200 >>> From: adacore at marino.st >>> To: jay.krell at cornell.edu; m3devel at elegosoft.com >>> Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp >> (0x100), expected 0x110 >>> >>> On 5/31/2015 11:53, Jay K wrote: >>>> John, have you tried make-dist.py? >>>> i.e. >> https://github.com/modula3/cm3/blob/master/scripts/python/make-dist.py >>>> >>>> While it might not be exactly what you need, it should demonstrate the >>>> elements. >>>> >>>> I will try to try this all soon, really, I hope so. >>>> >>>> It starts with a working compiler, does no in-place updates, build into >>>> a unique directory in /tmp, and gives you .tar.gz or such at the end. >>>> It does "min" and "all". >>>> >>>> If you set the STAGE environment variable, it uses that instead of /tmp. >>>> It should probably be called M3_STATE or M3_MAKEDIST_STAGE. >>>> >>>> - Jay >>>> >>> >>> Hi Jay, >>> I'm getting the same error as always using make-dist script: >>> http://leaf.dragonflybsd.org/~marino/m3d.log >>> >>> Thanks, >>> John > -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Sun May 31 21:13:46 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sun, 31 May 2015 14:13:46 -0500 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <556ABB1C.5080607@marino.st> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop> <556817A1.2090206@marino.st> <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de> <55682D1A.2030504@marino.st> <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de> <55683689.2090709@marino.st> <20150529122732.1396eb079ff9b404bcb21e40@elego.de> <5568421D.3050209@marino.st> <20150529155833.8454664b88391d93708e8f85@elego.de> <55687266.3090400@marino.st> <20150529162028.388911007a614006049beb42@elego.de> <20150529172305.a3fc2a9865b5250a5b9140fc@elego.de> <556885FD.6010800@marino.st> <20150529180223.d467621b68ebf665da685b12@elego.de> <55689065.1040207@marino.st> <20150529201531.b35e3cfdafeb9e2735e0020b@elegosoft.com> <5568B352.8060005@marino.st> <556ABB1C.5080607@marino.st> Message-ID: <556B5D6A.3030403@lcwb.coop> The error message you keep getting pretty certainly means it is running a new cm3cg with an old cm3. And it consistently happens immediately after cm3cg is rebuilt. The build of cm3cg (package m3cc) appears to be the first use of cm3 in all your failed builds, and I don't think that package would ever run cm3cg, as there is no Modula-3 code in it. Which means there is no proof that the version of cm3cg that would have been used before it was rebuilt is the old one. (Could it be a new one left over from a previous incomplete build?) One experiment that would prove this would be, in the state your are starting from before trying a full build, try any means of running cm3 on a package that contains Modula-3 code, to see if it avoids the recurring problem. But I have another theory. I don't know what this ports bootstrap is, but there was a time when things where set up so that cm3, instead of looking in just the same directory as its own executable was found, was looking several alternative places for an executable cm3cg. This caused the same problem to occur in a different way. Even when the newly rebuilt cm3cg executable was not copied to the bin directory right away, its mere existence where it was built was causing it to be found the next time cm3 started up, leading to the same failure. I don't remember how this was fixed, but either Jay or I did something about it. Perhaps the ports bootstrap was made during a time when this behavior was happening. On 05/31/2015 02:41 AM, John Marino wrote: > On 5/29/2015 20:43, John Marino wrote: >> On 5/29/2015 20:15, Olaf Wagner wrote: >>> >>> Well, yes, I understand that. I would have tried your exact setup, >>> but I have no system available to test that on. >>> >>> At least I have validated that based on the origianl 5.8.6 installation >>> archive for AMD64_FREEBSD you can build the new compiler from the current >>> sources with a simple call of the upgrade.sh script. which I still doubted >>> yesterday. >> >> >> The card I still have left to play is to extract the bootstrap, let it >> overwrite itself per Rodney's technique and then build the real compiler >> (dumping the whole "intermediate" area). > > FWIW, this did not work either. Rodney's technique doesn't seem to work > with the ports bootstrap. I don't know why it would work with provided > 5.8.6 but not rebuilt one. As far as I can tell, I did what he said > would always work. > > I'm at a loss as to where to go from here. It's starting to look like I > have to throw away the ports 5.8.6 bootstrap and start over somehow. I > don't think it should be this hard. :( > > John > -- Rodney Bates rodney.m.bates at acm.org From adacore at marino.st Sun May 31 21:26:45 2015 From: adacore at marino.st (John Marino) Date: Sun, 31 May 2015 21:26:45 +0200 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <556B5D6A.3030403@lcwb.coop> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop> <556817A1.2090206@marino.st> <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de> <55682D1A.2030504@marino.st> <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de> <55683689.2090709@marino.st> <20150529122732.1396eb079ff9b404bcb21e40@elego.de> <5568421D.3050209@marino.st> <20150529155833.8454664b88391d93708e8f85@elego.de> <55687266.3090400@marino.st> <20150529162028.388911007a614006049beb42@elego.de> <20150529172305.a3fc2a9865b5250a5b9140fc@elego.de> <556885FD.6010800@marino.st> <20150529180223.d467621b68ebf665da685b12@elego.de> <55689065.1040207@marino.st> <20150529201531.b35e3cfdafeb9e2735e0020b@elegosoft.com> <5568B352.8060005@marino.st> <556ABB1C.5080607@marino.st> <556B5D6A.3030403@lcwb.coop> Message-ID: <556B6075.6010703@marino.st> On 5/31/2015 21:13, Rodney M. Bates wrote: > The error message you keep getting pretty certainly means it is running a > new cm3cg with an old cm3. And it consistently happens immediately after > cm3cg is rebuilt. > > The build of cm3cg (package m3cc) appears to be the first use of cm3 in all > your failed builds, and I don't think that package would ever run cm3cg, as > there is no Modula-3 code in it. Which means there is no proof that the > version of cm3cg that would have been used before it was rebuilt is the old > one. (Could it be a new one left over from a previous incomplete build?) That's not possible. The bootstrap is packaged in a compressed tarball and extracted for the sole purpose of building M3. It would have not leftovers in it. It comes with cm3, cm3cg, m3bundle, and mklib in the bin directory. the contents of the bootstrap M3 cm3.cfg are: INSTALL_ROOT = path() & "/.." include (path() & "/../etc/modula3/AMD64_FREEBSD") > One experiment that would prove this would be, in the state your are > starting from before trying a full build, try any means of running > cm3 on a package that contains Modula-3 code, to see if it avoids the > recurring problem. I think this is N/A. The bootstrap compiler is extracted to a directory that is not on the path (and only exists right before trying to build modula3 port) > But I have another theory. I don't know what this ports bootstrap > is, but there was a time when things where set up so that cm3, instead > of looking in just the same directory as its own executable was found, > was looking several alternative places for an executable cm3cg. This It's 5.8.6 and the cm3.cfg is listed above. You can download it yourself here: http://downloads.dragonlace.net/m3/m3-bootstrap.AMD64.FREEBSD.92.tar.bz2 > caused the same problem to occur in a different way. Even when the > newly rebuilt cm3cg executable was not copied to the bin directory > right away, its mere existence where it was built was causing it to > be found the next time cm3 started up, leading to the same failure. > > I don't remember how this was fixed, but either Jay or I did something > about it. Perhaps the ports bootstrap was made during a time when this > behavior was happening. Probably not as I am 99% sure the bootstrap was built from the release source. Thanks, John From rodney_bates at lcwb.coop Sun May 31 22:14:09 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sun, 31 May 2015 15:14:09 -0500 Subject: [M3devel] The role INTEGER and subranges in Modula-3 In-Reply-To: <5569E656.6080909@elstel.org> References: <5569D3AA.2040009@lcwb.coop> <5569E656.6080909@elstel.org> Message-ID: <556B6B91.1030600@lcwb.coop> On 05/30/2015 11:33 AM, Elmar Stellnberger wrote: > Am 30.05.15 um 17:13 schrieb Rodney M. Bates: >> There are no implicit type conversions. Instead, this need is met by >> the concept of assignability. If the abstract value is in a >> variable's range, it can be assigned to the variable. Size changes, >> if needed, are the code generator's problem. > So what does the code generator do if there is an overflow not checked > by the predefined value range (i.e. BITS 8 FOR INTEGER instead of > BITS 8 for [0..255]) BITS 8 FOR INTEGER will not compile. It is statically illegal, because the asked-for bit size is not enough to hold the value range of the type INTEGER. (Unless the compiler is configured with FIRST(INTEGER) = -128 and LAST(INTEGER) = 127, as might be done for an 8-bit microprocessor.) >> All this drastically simplifies the language, while also allowing the ... > Yes, I understand your decision. >> likely to be commonly needed, LONGINT would have no place. But native >> sized arithmetic is always the most efficient. In today's world, >> there are two very common classes of use cases: 1) 32-bit arithmetic is wide enough, 2) 32-bit is not wide enough, but 64-bit is. In both >> cases, on machines of either native arithmetic size, we want the best >> efficiency. LONGINT is for case 2, and when you further need to be >> able to run on either size of machine. INTEGER is for otherwise. > Well, that was exactly my argument for a language specified type > size of INTEGER, because things do not get faster if you use 64bit > integers instead of 32bit integers. CPU arithmetics perhaps but the > real bottleneck of today is the memory hierarchy - and using 64bit > integers doubles our memory need at least for scalars. >> >> Whether you believe in LONGINT or not, there is certainly no >> justification for more base integer types than two: one the native >> size of the machine and one bigger. > Yes, we really don`t need them as anything becomes 64bit or the native > word size respectively on the stack (that is why Ctypes.int works). > Memory latency should be a minor issue as long as our parameters and > parts of the activation records fit into the cache. > > > > -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Sun May 31 22:51:10 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sun, 31 May 2015 15:51:10 -0500 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <556B6075.6010703@marino.st> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop> <556817A1.2090206@marino.st> <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de> <55682D1A.2030504@marino.st> <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de> <55683689.2090709@marino.st> <20150529122732.1396eb079ff9b404bcb21e40@elego.de> <5568421D.3050209@marino.st> <20150529155833.8454664b88391d93708e8f85@elego.de> <55687266.3090400@marino.st> <20150529162028.388911007a614006049beb42@elego.de> <20150529172305.a3fc2a9865b5250a5b9140fc@elego.de> <556885FD.6010800@marino.st> <20150529180223.d467621b68ebf665da685b12@elego.de> <55689065.1040207@marino.st> <20150529201531.b35e3cfdafeb9e2735e0020b@elegosoft.com> <5568B352.8060005@marino.st> <556ABB1C.5080607@marino.st> <556B5D6A.3030403@lcwb.coop> <556B6075.6010703@marino.st> Message-ID: <556B743E.7030504@lcwb.coop> On 05/31/2015 02:26 PM, John Marino wrote: > On 5/31/2015 21:13, Rodney M. Bates wrote: >> The error message you keep getting pretty certainly means it is running a >> new cm3cg with an old cm3. And it consistently happens immediately after >> cm3cg is rebuilt. >> >> The build of cm3cg (package m3cc) appears to be the first use of cm3 in all >> your failed builds, and I don't think that package would ever run cm3cg, as >> there is no Modula-3 code in it. Which means there is no proof that the >> version of cm3cg that would have been used before it was rebuilt is the old >> one. (Could it be a new one left over from a previous incomplete build?) > > That's not possible. The bootstrap is packaged in a compressed tarball > and extracted for the sole purpose of building M3. It would have not > leftovers in it. > > It comes with cm3, cm3cg, m3bundle, and mklib in the bin directory. > > the contents of the bootstrap M3 cm3.cfg are: > INSTALL_ROOT = path() & "/.." > include (path() & "/../etc/modula3/AMD64_FREEBSD") > > >> One experiment that would prove this would be, in the state your are >> starting from before trying a full build, try any means of running >> cm3 on a package that contains Modula-3 code, to see if it avoids the >> recurring problem. > > I think this is N/A. The bootstrap compiler is extracted to a directory > that is not on the path (and only exists right before trying to build > modula3 port) > > >> But I have another theory. I don't know what this ports bootstrap >> is, but there was a time when things where set up so that cm3, instead >> of looking in just the same directory as its own executable was found, >> was looking several alternative places for an executable cm3cg. This > > It's 5.8.6 and the cm3.cfg is listed above. You can download it > yourself here: > http://downloads.dragonlace.net/m3/m3-bootstrap.AMD64.FREEBSD.92.tar.bz2 > OK, the fix I mentioned is in the 5.8 release branch on github, but it is not in the above bootstrap. In file bootstrap/etc/modula3/cm3cfg.common, line 274 needs to change from: 274: foreach root in [ m3cc, bin ] to: 274: foreach root in [ bin ] Before building the Modula-3 head. > >> caused the same problem to occur in a different way. Even when the >> newly rebuilt cm3cg executable was not copied to the bin directory >> right away, its mere existence where it was built was causing it to >> be found the next time cm3 started up, leading to the same failure. >> >> I don't remember how this was fixed, but either Jay or I did something >> about it. Perhaps the ports bootstrap was made during a time when this >> behavior was happening. > > Probably not as I am 99% sure the bootstrap was built from the release > source. > > Thanks, > John > > > > -- Rodney Bates rodney.m.bates at acm.org From jay.krell at cornell.edu Sat May 2 11:16:49 2015 From: jay.krell at cornell.edu (Jay K) Date: Sat, 2 May 2015 09:16:49 +0000 Subject: [M3devel] the need for cooperative suspend Message-ID: We really need to move away from preemptive suspend. 1) It is a large fraction of the target-dependent code in m3core. 2) It doesn't really work in "wow64", the x86-on-amd64 Windows system. The SuspendThread + GetThreadContext does not actually reliably give you current and coherent context. I'm not sure about x86-on-ia64. The context can be old. The context can be mid-update. Which might be ok, depending on what the updates are. LIke if Eip and Esp are being updated, we don't care about Eip anyway. You can find out if either is the case, and let the thread run longer, but being in a long running syscall I believe is reported as possibly invalid even though it is valid. NT/native is ok. We should just use cooperative suspend and not worry about it. Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Sat May 2 17:57:13 2015 From: mika at async.caltech.edu (mika at async.caltech.edu) Date: Sat, 02 May 2015 08:57:13 -0700 Subject: [M3devel] the need for cooperative suspend In-Reply-To: References: Message-ID: <20150502155713.29DCC1A2062@async.async.caltech.edu> Jay, Can you explain precisely what you mean by "suspend"? A thread is suspended by ... a timer expiration? Another thread at higher priority needing resources? I'm thinking about a tight loop "for(;;) ;"... how do you stop a thread from running that (it could have been coded in assembly...)? Jay K writes: >--_6bc62225-3263-437a-a88c-4b1ff9473d58_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > >We really need to move away from preemptive suspend. > >1) It is a large fraction of the target-dependent code in m3core. >=20 > >2) It doesn't really work in "wow64"=2C the x86-on-amd64 Windows system. >The SuspendThread + GetThreadContext does not actually reliably give you >current and coherent context. >I'm not sure about x86-on-ia64. >=20 > > The context can be old. > The context can be mid-update. Which might be ok=2C depending on what the = >updates are. > LIke if Eip and Esp are being updated=2C we don't care about Eip anyway. >=20 > >You can find out if either is the case=2C and let the thread run longer=2C >but being in a long running syscall I believe is reported as possibly >invalid even though it is valid. >=20 >=20 >NT/native is ok. >=20 > >We should just use cooperative suspend and not worry about it. >=20 >=20 >Thanks=2C > - Jay > > >=20 > = > >--_6bc62225-3263-437a-a88c-4b1ff9473d58_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > >
We really need to move away from= > preemptive suspend.

1) It is a large fraction of the target-depende= >nt code in m3core.
 =3B

2) It doesn't really work in "wow64"= >=2C the x86-on-amd64 Windows system.
The SuspendThread + GetThreadContex= >t does not actually reliably give you
current and coherent context.
I= >'m not sure about x86-on-ia64.
 =3B

 =3BThe context can b= >e old.
 =3BThe context can be mid-update. Which might be ok=2C depen= >ding on what the updates are.
 =3BLIke if Eip and Esp are being upda= >ted=2C we don't care about Eip anyway.
 =3B

You can find out = >if either is the case=2C and let the thread run longer=2C
but being in a= > long running syscall I believe is reported as possibly
invalid even tho= >ugh it is valid.
 =3B
 =3B
NT/native is ok.
 =3B>
We should just use cooperative suspend and not worry about it.
&nbs= >p=3B
 =3B
Thanks=2C
 =3B- Jay


 =3B
= >
>= > >--_6bc62225-3263-437a-a88c-4b1ff9473d58_-- From jay.krell at cornell.edu Sat May 2 21:13:31 2015 From: jay.krell at cornell.edu (Jay) Date: Sat, 2 May 2015 12:13:31 -0700 Subject: [M3devel] the need for cooperative suspend In-Reply-To: <20150502155713.29DCC1A2062@async.async.caltech.edu> References: <20150502155713.29DCC1A2062@async.async.caltech.edu> Message-ID: In the preemptive case, you call SuspendThread and a hardware interrupt is sent to the processor. Cooperative suspend does not have this power. There ends up being, I guess, an analog between non-polling code and the "fixed" wow64 method that is also easily starved w/o more sophistication. Thinking more about this...maybe preemptive is viable with a little more work. In particular we can record when we leave "managed" code and leave a reliable stack pointer for ourselves. We can then safely preempt "native" code, getting context from our own data structures instead of the operating system. Native code though could allocate traced data though, without registering with the runtime somehow. - Jay On May 2, 2015, at 8:57 AM, wrote: > Jay, > > Can you explain precisely what you mean by "suspend"? > > A thread is suspended by ... a timer expiration? Another thread at higher priority needing resources? > > I'm thinking about a tight loop "for(;;) ;"... how do you stop a thread from running that (it could have > been coded in assembly...)? > > Jay K writes: >> --_6bc62225-3263-437a-a88c-4b1ff9473d58_ >> Content-Type: text/plain; charset="iso-8859-1" >> Content-Transfer-Encoding: quoted-printable >> >> We really need to move away from preemptive suspend. >> >> 1) It is a large fraction of the target-dependent code in m3core. >> =20 >> >> 2) It doesn't really work in "wow64"=2C the x86-on-amd64 Windows system. >> The SuspendThread + GetThreadContext does not actually reliably give you >> current and coherent context. >> I'm not sure about x86-on-ia64. >> =20 >> >> The context can be old. >> The context can be mid-update. Which might be ok=2C depending on what the = >> updates are. >> LIke if Eip and Esp are being updated=2C we don't care about Eip anyway. >> =20 >> >> You can find out if either is the case=2C and let the thread run longer=2C >> but being in a long running syscall I believe is reported as possibly >> invalid even though it is valid. >> =20 >> =20 >> NT/native is ok. >> =20 >> >> We should just use cooperative suspend and not worry about it. >> =20 >> =20 >> Thanks=2C >> - Jay >> >> >> =20 >> = >> >> --_6bc62225-3263-437a-a88c-4b1ff9473d58_ >> Content-Type: text/html; charset="iso-8859-1" >> Content-Transfer-Encoding: quoted-printable >> >> >> >> >>
We really need to move away from= >> preemptive suspend.

1) It is a large fraction of the target-depende= >> nt code in m3core.
 =3B

2) It doesn't really work in "wow64"= >> =2C the x86-on-amd64 Windows system.
The SuspendThread + GetThreadContex= >> t does not actually reliably give you
current and coherent context.
I= >> 'm not sure about x86-on-ia64.
 =3B

 =3BThe context can b= >> e old.
 =3BThe context can be mid-update. Which might be ok=2C depen= >> ding on what the updates are.
 =3BLIke if Eip and Esp are being upda= >> ted=2C we don't care about Eip anyway.
 =3B

You can find out = >> if either is the case=2C and let the thread run longer=2C
but being in a= >> long running syscall I believe is reported as possibly
invalid even tho= >> ugh it is valid.
 =3B
 =3B
NT/native is ok.
 =3B>>
We should just use cooperative suspend and not worry about it.
&nbs= >> p=3B
 =3B
Thanks=2C
 =3B- Jay


 =3B
= >>
>> = >> >> --_6bc62225-3263-437a-a88c-4b1ff9473d58_-- From rodney_bates at lcwb.coop Fri May 15 21:50:28 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Fri, 15 May 2015 14:50:28 -0500 Subject: [M3devel] Not getting github notifications Message-ID: <55564E04.1080401@lcwb.coop> After a lot of poking around in github.com/modula3, it is apparent that there has been some activity that I hadn't heard about. I have, for some time, had my account set up so that (I thought) I would get generated emails for pushes to the repository. But apparently, it only works when _I_ push, which, of course, is not big news to me. I also tried adding m3commit at elegosoft.com to the list of email addresses to be sent to, but that one doesn't come through at all. Any advice? -- Rodney Bates rodney.m.bates at acm.org From wagner at elegosoft.com Sun May 17 01:18:24 2015 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 17 May 2015 01:18:24 +0200 Subject: [M3devel] Bootstrapping cm3 on OS X 10.9.5 Message-ID: <20150517011824.75f096c832d5da56e4810bbf@elegosoft.com> After several years I've just tried to setup a current cm3 on my computer again. I've cloned the repository from github/modula3/cm3, installed the latest binary archive for Darwin I could find -- which is that of the 5.8.6 release several years ago -- and tried to compile some sources. This always fails with lots of these errors: m3cc (aka cm3cg) failed compiling: PklFpMap.mc new source -> compiling FpIntTbl.m3 m3cgc1: fatal error: *** illegal type: 0x17, at m3cg_lineno 4 compilation terminated. regardless if I use the 5.8.6 backend or build a new cm3cg from sources (which actually succeeds). Any suggestions how to continue? Are newer bootstrap archives available somewhere? Any hints are appreciated. Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From rodney_bates at lcwb.coop Sun May 17 16:48:00 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sun, 17 May 2015 09:48:00 -0500 Subject: [M3devel] Bootstrapping cm3 on OS X 10.9.5 In-Reply-To: <20150517011824.75f096c832d5da56e4810bbf@elegosoft.com> References: <20150517011824.75f096c832d5da56e4810bbf@elegosoft.com> Message-ID: <5558AA20.1090208@lcwb.coop> This is a familiar error to me, but I can't remember the details right off hand. I would have said it was an old m3cc, but you have built the latest one, so that theory goes down the drain. I'll see what I can reconstruct. On 05/16/2015 06:18 PM, Olaf Wagner wrote: > After several years I've just tried to setup a current cm3 on my computer > again. I've cloned the repository from github/modula3/cm3, installed > the latest binary archive for Darwin I could find -- which is that of > the 5.8.6 release several years ago -- and tried to compile some sources. > > This always fails with lots of these errors: > > m3cc (aka cm3cg) failed compiling: PklFpMap.mc > new source -> compiling FpIntTbl.m3 > m3cgc1: fatal error: *** illegal type: 0x17, at m3cg_lineno 4 > compilation terminated. > > regardless if I use the 5.8.6 backend or build a new cm3cg from > sources (which actually succeeds). > > Any suggestions how to continue? > Are newer bootstrap archives available somewhere? > Any hints are appreciated. > > Olaf > -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Mon May 18 18:34:58 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Mon, 18 May 2015 11:34:58 -0500 Subject: [M3devel] Bootstrapping cm3 on OS X 10.9.5 In-Reply-To: <5558AA20.1090208@lcwb.coop> References: <20150517011824.75f096c832d5da56e4810bbf@elegosoft.com> <5558AA20.1090208@lcwb.coop> Message-ID: <555A14B2.7090900@lcwb.coop> Well, I have not been able to reproduce this on AMD64_LINUX, nor see by looking at code what it might be. ISTR that it is some kind of front-end/back-end mismatch. But the CGType codes that m3cc in trying to read have not changed in either the front-end nor the back-end since the release. 0x17 is well out of range. m3cc must be lost and trying to interpret something else as a type. On 05/17/2015 09:48 AM, Rodney M. Bates wrote: > This is a familiar error to me, but I can't remember the details right off hand. > I would have said it was an old m3cc, but you have built the latest one, > so that theory goes down the drain. I'll see what I can reconstruct. > > On 05/16/2015 06:18 PM, Olaf Wagner wrote: >> After several years I've just tried to setup a current cm3 on my computer >> again. I've cloned the repository from github/modula3/cm3, installed >> the latest binary archive for Darwin I could find -- which is that of >> the 5.8.6 release several years ago -- and tried to compile some sources. >> >> This always fails with lots of these errors: >> >> m3cc (aka cm3cg) failed compiling: PklFpMap.mc >> new source -> compiling FpIntTbl.m3 >> m3cgc1: fatal error: *** illegal type: 0x17, at m3cg_lineno 4 >> compilation terminated. >> >> regardless if I use the 5.8.6 backend or build a new cm3cg from >> sources (which actually succeeds). >> >> Any suggestions how to continue? >> Are newer bootstrap archives available somewhere? >> Any hints are appreciated. >> >> Olaf >> > -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Mon May 18 18:55:10 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Mon, 18 May 2015 11:55:10 -0500 Subject: [M3devel] Bootstrapping cm3 on OS X 10.9.5 In-Reply-To: <555A14B2.7090900@lcwb.coop> References: <20150517011824.75f096c832d5da56e4810bbf@elegosoft.com> <5558AA20.1090208@lcwb.coop> <555A14B2.7090900@lcwb.coop> Message-ID: <555A196E.2020106@lcwb.coop> Olaf, I think you must have a wrong version of cm3cg. I paper-traced through the first few IR opcodes of PklFpMap.mc (as generated by my cm3 executable, fairly recently built from the git repository) and encountered several changes to the binary opcodes, one of which I made. Using a release 5.8 version of cm3cg, I got a similar (though not identical) error: rodney at allegheny:~/proj/m3/git/cm3/m3-libs/libm3/AMD64_LINUX$ /usr/local/cm3-release/bin/cm3cg -quiet -fno-reorder-blocks -funwind-tables -fPIC -m64 -gstabs+ PklFpMap.mc -o PklFpMap.ms cm3cg: fatal error: *** illegal type: 0x20, at m3cg_lineno 2 compilation terminated. The type 0x20 and and m3cg_lineno 2 values agree with what I expect from the source code I have for the release branch, CVS repository. That suggests you have a third version of cm3cg. (Or maybe not the right version of cm3 front-end?) This is on AMD64_LINUX. On 05/18/2015 11:34 AM, Rodney M. Bates wrote: > Well, I have not been able to reproduce this on AMD64_LINUX, nor see by looking > at code what it might be. ISTR that it is some kind of front-end/back-end > mismatch. But the CGType codes that m3cc in trying to read have not changed > in either the front-end nor the back-end since the release. 0x17 is well > out of range. m3cc must be lost and trying to interpret something else as > a type. > > On 05/17/2015 09:48 AM, Rodney M. Bates wrote: >> This is a familiar error to me, but I can't remember the details right off hand. >> I would have said it was an old m3cc, but you have built the latest one, >> so that theory goes down the drain. I'll see what I can reconstruct. >> >> On 05/16/2015 06:18 PM, Olaf Wagner wrote: >>> After several years I've just tried to setup a current cm3 on my computer >>> again. I've cloned the repository from github/modula3/cm3, installed >>> the latest binary archive for Darwin I could find -- which is that of >>> the 5.8.6 release several years ago -- and tried to compile some sources. >>> >>> This always fails with lots of these errors: >>> >>> m3cc (aka cm3cg) failed compiling: PklFpMap.mc >>> new source -> compiling FpIntTbl.m3 >>> m3cgc1: fatal error: *** illegal type: 0x17, at m3cg_lineno 4 >>> compilation terminated. >>> >>> regardless if I use the 5.8.6 backend or build a new cm3cg from >>> sources (which actually succeeds). >>> >>> Any suggestions how to continue? >>> Are newer bootstrap archives available somewhere? >>> Any hints are appreciated. >>> >>> Olaf >>> >> > -- Rodney Bates rodney.m.bates at acm.org From wagner at elegosoft.com Mon May 18 23:47:14 2015 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 18 May 2015 23:47:14 +0200 Subject: [M3devel] Bootstrapping cm3 on OS X 10.9.5 In-Reply-To: <555A196E.2020106@lcwb.coop> References: <20150517011824.75f096c832d5da56e4810bbf@elegosoft.com> <5558AA20.1090208@lcwb.coop> <555A14B2.7090900@lcwb.coop> <555A196E.2020106@lcwb.coop> Message-ID: <20150518234714.dd1c111374ba3614cd74a63e@elegosoft.com> On Mon, 18 May 2015 11:55:10 -0500 "Rodney M. Bates" wrote: > Olaf, I think you must have a wrong version of cm3cg. I paper-traced through the first > few IR opcodes of PklFpMap.mc (as generated by my cm3 executable, fairly recently built > from the git repository) and encountered several changes to the binary opcodes, > one of which I made. Using a release 5.8 version of cm3cg, I got a similar (though > not identical) error: > > rodney at allegheny:~/proj/m3/git/cm3/m3-libs/libm3/AMD64_LINUX$ /usr/local/cm3-release/bin/cm3cg -quiet -fno-reorder-blocks -funwind-tables -fPIC -m64 -gstabs+ PklFpMap.mc -o PklFpMap.ms > cm3cg: fatal error: *** illegal type: 0x20, at m3cg_lineno 2 > compilation terminated. > > The type 0x20 and and m3cg_lineno 2 values agree with what I expect from the source code > I have for the release branch, CVS repository. That suggests you have a third version > of cm3cg. (Or maybe not the right version of cm3 front-end?) > > This is on AMD64_LINUX. OK, I'll try to check that again. Thank you very much for the help. It may take some time but I'll let you know what I find out. Weekend is over... Olaf > On 05/18/2015 11:34 AM, Rodney M. Bates wrote: > > Well, I have not been able to reproduce this on AMD64_LINUX, nor see by looking > > at code what it might be. ISTR that it is some kind of front-end/back-end > > mismatch. But the CGType codes that m3cc in trying to read have not changed > > in either the front-end nor the back-end since the release. 0x17 is well > > out of range. m3cc must be lost and trying to interpret something else as > > a type. > > > > On 05/17/2015 09:48 AM, Rodney M. Bates wrote: > >> This is a familiar error to me, but I can't remember the details right off hand. > >> I would have said it was an old m3cc, but you have built the latest one, > >> so that theory goes down the drain. I'll see what I can reconstruct. > >> > >> On 05/16/2015 06:18 PM, Olaf Wagner wrote: > >>> After several years I've just tried to setup a current cm3 on my computer > >>> again. I've cloned the repository from github/modula3/cm3, installed > >>> the latest binary archive for Darwin I could find -- which is that of > >>> the 5.8.6 release several years ago -- and tried to compile some sources. > >>> > >>> This always fails with lots of these errors: > >>> > >>> m3cc (aka cm3cg) failed compiling: PklFpMap.mc > >>> new source -> compiling FpIntTbl.m3 > >>> m3cgc1: fatal error: *** illegal type: 0x17, at m3cg_lineno 4 > >>> compilation terminated. > >>> > >>> regardless if I use the 5.8.6 backend or build a new cm3cg from > >>> sources (which actually succeeds). > >>> > >>> Any suggestions how to continue? > >>> Are newer bootstrap archives available somewhere? > >>> Any hints are appreciated. > >>> > >>> Olaf > >>> > >> > > > > -- > Rodney Bates > rodney.m.bates at acm.org -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Tue May 19 01:33:49 2015 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 19 May 2015 01:33:49 +0200 Subject: [M3devel] Bootstrapping cm3 on OS X 10.9.5 In-Reply-To: <20150518234714.dd1c111374ba3614cd74a63e@elegosoft.com> References: <20150517011824.75f096c832d5da56e4810bbf@elegosoft.com> <5558AA20.1090208@lcwb.coop> <555A14B2.7090900@lcwb.coop> <555A196E.2020106@lcwb.coop> <20150518234714.dd1c111374ba3614cd74a63e@elegosoft.com> Message-ID: <20150519013349.0ba8729443cabb394424d3cd@elegosoft.com> On Mon, 18 May 2015 23:47:14 +0200 Olaf Wagner wrote: > On Mon, 18 May 2015 11:55:10 -0500 > "Rodney M. Bates" wrote: > > > Olaf, I think you must have a wrong version of cm3cg. I paper-traced through the first > > few IR opcodes of PklFpMap.mc (as generated by my cm3 executable, fairly recently built > > from the git repository) and encountered several changes to the binary opcodes, > > one of which I made. Using a release 5.8 version of cm3cg, I got a similar (though > > not identical) error: > > > > rodney at allegheny:~/proj/m3/git/cm3/m3-libs/libm3/AMD64_LINUX$ /usr/local/cm3-release/bin/cm3cg -quiet -fno-reorder-blocks -funwind-tables -fPIC -m64 -gstabs+ PklFpMap.mc -o PklFpMap.ms > > cm3cg: fatal error: *** illegal type: 0x20, at m3cg_lineno 2 > > compilation terminated. > > > > The type 0x20 and and m3cg_lineno 2 values agree with what I expect from the source code > > I have for the release branch, CVS repository. That suggests you have a third version > > of cm3cg. (Or maybe not the right version of cm3 front-end?) > > > > This is on AMD64_LINUX. > > OK, I'll try to check that again. Thank you very much for the help. > It may take some time but I'll let you know what I find out. Weekend > is over... Couldn't let this rest though... It seems I made a really stupid mistake by installing an I386_DARWIN archive, as I have a 64 bit processor. AMD64_DARWIN should work much better, and I've even found one from March 2011. After replacing the configuration files with those from the current code base and adapting some basic system tool definitions like gcc and libtool I have now successfully compiled m3core. This looks good so far. It would have taken me much longer without your hint. But now I need some sleep, Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From rodney_bates at lcwb.coop Tue May 19 21:32:40 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Tue, 19 May 2015 14:32:40 -0500 Subject: [M3devel] New llvm backend Message-ID: <555B8FD8.2000109@lcwb.coop> I just noticed Peter's llvm backend in the github repository. I'm glad to see it. We need this. I had started some work on this too, much of it complementary. I have a version of cm3 that integrates an llvm backend, either as a separate executable, or with (some of) llvm linked in. I will work on getting that set up for Peter's main program. I also have done quite a bit of work on expanded bindings to more llvm stuff, especially for building debug info, plus a few other things that were missing from llvm's core interface. I had started a cm3-IR to llvm-IR converter, but got bogged down in making Modula-3's recursive definitions fit llvm's. The latter was not general enough for Modula-3, at least not in a direct way. I did a lot on an algorithm to wrap a minimal set of pointers, each in an artificial llvm struct, which is the only thing the llvm IR allows forward declarations for. Just when I had a pretty good draft coded, some of the llvm folks announced that the typed pointers in their IR were really unnecessary anyway, and reworked their head to have pointers with no referent type. Since that is most of what I had coded, I think it best to abandon that and adopt Peter's. I do think it would be good to have a branch for the llvm backend work. From what I have seen so far, git branches look to be pretty easy to use. -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Tue May 19 22:17:30 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Tue, 19 May 2015 15:17:30 -0500 Subject: [M3devel] Rerunning m3cggen Message-ID: <555B9A5A.2090106@lcwb.coop> What does it take to get m3cggen to be rerun? scripts/do-pkg.sh buildship m3cc doesn't appear to do it, nor does cm3 in m3-sys/m3cc. Does it need to be done manually? -- Rodney Bates rodney.m.bates at acm.org From wagner at elegosoft.com Tue May 19 23:56:09 2015 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 19 May 2015 23:56:09 +0200 Subject: [M3devel] Bootstrapping cm3 on OS X 10.9.5 In-Reply-To: <20150519013349.0ba8729443cabb394424d3cd@elegosoft.com> References: <20150517011824.75f096c832d5da56e4810bbf@elegosoft.com> <5558AA20.1090208@lcwb.coop> <555A14B2.7090900@lcwb.coop> <555A196E.2020106@lcwb.coop> <20150518234714.dd1c111374ba3614cd74a63e@elegosoft.com> <20150519013349.0ba8729443cabb394424d3cd@elegosoft.com> Message-ID: <20150519235609.41e93f178398d113bdecb79d@elegosoft.com> On Tue, 19 May 2015 01:33:49 +0200 Olaf Wagner wrote: > After replacing the configuration files with those from the current code > base and adapting some basic system tool definitions like gcc and libtool > I have now successfully compiled m3core. This looks good so far. I almost succeeded in building a new cm3 from sources now, but I'm stuck at something again I don't understand. Symbol ___eprintf is referenced from m3core, but there is no static definition for it in any library I can find. -> linking cm3 generate _m3main.new compare _m3main.new _m3main.c rm _m3main.new /usr/bin/gcc -o cm3 _m3main.o cm3unix.o Version.io M3Backend.io M3Backend.mo UtilsPosix.mo Arg.io Arg.mo Builder.io Builder.mo Dirs.io Dirs.mo M3Build.io M3Build.mo M3Loc.io M3Loc.mo M3Options.io M3Options.mo M3Unit.io M3Unit.mo Makefile.io Makefile.mo Msg.io Msg.mo Utils.io Utils.mo WebFile.io WebFile.mo Main.mo /usr/local/cm3/pkg/m3back/AMD64_DARWIN/libm3back.a /usr/local/cm3/pkg/m3objfile/AMD64_DARWIN/libm3objfile.a /usr/local/cm3/pkg/m3quake/AMD64_DARWIN/libm3quake.a /usr/local/cm3/pkg/m3front/AMD64_DARWIN/libm3front.a /usr/local/cm3/pkg/m3linker/AMD64_DARWIN/libm3link.a /usr/local/cm3/pkg/m3middle/AMD64_DARWIN/libm3middle.a /usr/local/cm3/pkg/sysutils/AMD64_DARWIN/libsysutils.a /usr/local/cm3/pkg/libm3/AMD64_DARWIN/libm3.a /usr/local/cm3/pkg/m3core/AMD64_DARWIN/libm3core.a -multiply_defined suppress -bind_at_load -shared-libgcc -dead_strip -headerpad_max_install_names Undefined symbols for architecture x86_64: "___eprintf", referenced from: _ThreadPThread__ProcessStopped in libm3core.a(ThreadApple.o) _InstallOneHandler in libm3core.a(RTSignalC.o) ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) ---- elegos-MacBook-Pro:cm3 wagner$ for f in $(find /usr/lib /usr/local/lib /opt/local/lib /usr/local/cm3/lib -name *.a); do nm $f 2>/dev/null | grep ___eprintf && echo "found in $f"; done U ___eprintf U ___eprintf found in /usr/local/cm3/lib/libm3core.a ---- elegos-MacBook-Pro:cm3 wagner$ for f in $(find /usr/lib /usr/local/lib /opt/local/lib /usr/local/cm3/lib -name *.dylib); do nm $f 2>/dev/null | grep ___eprintf && echo "found in $f"; done U ___eprintf 000141c0 t ___eprintf found in /usr/lib/lib6200Lib.dylib U ___eprintf 00019bf0 t ___eprintf found in /usr/lib/lib7225lib.dylib 00016c60 t ___eprintf U ___eprintf found in /usr/lib/lib8200Alib.dylib 00017d30 t ___eprintf U ___eprintf found in /usr/lib/lib8220lib.dylib U ___eprintf 00009a10 t ___eprintf found in /usr/lib/libAgent.dylib U ___eprintf 00018f00 t ___eprintf found in /usr/lib/libIceraDownloadLib.dylib U ___eprintf 000081bb t ___eprintf found in /usr/lib/libTinyXml.dylib 0000000000001850 t ___eprintf found in /usr/local/cm3/lib/libm3core.5.2.dylib 0000000000001850 t ___eprintf found in /usr/local/cm3/lib/libm3core.5.dylib 0000000000001850 t ___eprintf found in /usr/local/cm3/lib/libm3core.dylib ---- Does anybody know what it the standard solution for this? The symbol is even defined in the dynamic version of m3core itself. Is static linking not supported anymore? Or should I just link against one of the above dynamically? The m3makefile for cm3 still contains build_standalone () %-- we don't want to depend on the shared libraries... Any hint will be appreciated. Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Wed May 20 00:21:41 2015 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 20 May 2015 00:21:41 +0200 Subject: [M3devel] Rerunning m3cggen In-Reply-To: <555B9A5A.2090106@lcwb.coop> References: <555B9A5A.2090106@lcwb.coop> Message-ID: <20150520002141.1291106319a5d76adad4415e@elegosoft.com> On Tue, 19 May 2015 15:17:30 -0500 "Rodney M. Bates" wrote: > What does it take to get m3cggen to be rerun? scripts/do-pkg.sh buildship m3cc doesn't > appear to do it, nor does cm3 in m3-sys/m3cc. Does it need to be done manually? As long as I remember, I never automated anything that runs m3cggen. So I assume the answer should be yes. Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Wed May 20 21:01:09 2015 From: jay.krell at cornell.edu (Jay K) Date: Wed, 20 May 2015 19:01:09 +0000 Subject: [M3devel] Rerunning m3cggen In-Reply-To: <20150520002141.1291106319a5d76adad4415e@elegosoft.com> References: <555B9A5A.2090106@lcwb.coop>, <20150520002141.1291106319a5d76adad4415e@elegosoft.com> Message-ID: I think I automated it. But historically, in those other paths, it wasn't automated.Not a problem with the C backend. :) - Jay > Date: Wed, 20 May 2015 00:21:41 +0200 > From: wagner at elegosoft.com > To: rodney.m.bates at acm.org > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Rerunning m3cggen > > On Tue, 19 May 2015 15:17:30 -0500 > "Rodney M. Bates" wrote: > > > What does it take to get m3cggen to be rerun? scripts/do-pkg.sh buildship m3cc doesn't > > appear to do it, nor does cm3 in m3-sys/m3cc. Does it need to be done manually? > > As long as I remember, I never automated anything that runs m3cggen. > So I assume the answer should be yes. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed May 20 21:11:22 2015 From: jay.krell at cornell.edu (Jay K) Date: Wed, 20 May 2015 19:11:22 +0000 Subject: [M3devel] Bootstrapping cm3 on OS X 10.9.5 In-Reply-To: <20150519235609.41e93f178398d113bdecb79d@elegosoft.com> References: <20150517011824.75f096c832d5da56e4810bbf@elegosoft.com>, <5558AA20.1090208@lcwb.coop> <555A14B2.7090900@lcwb.coop>, <555A196E.2020106@lcwb.coop>, <20150518234714.dd1c111374ba3614cd74a63e@elegosoft.com>, <20150519013349.0ba8729443cabb394424d3cd@elegosoft.com>, <20150519235609.41e93f178398d113bdecb79d@elegosoft.com> Message-ID: Hi Olaf, This is surely some printf/sprint wrapper from stdio.h.Did you copy files across from some other machine or this is all one-machine?Try the C backend? I -lSystem? #include int main(){char buffer[10];printf("");sprint(buffer, "");return 0;} gcc -E 1.c gcc -S 1.c gcc 1.c gcc -v 1.c libtool a.out ? Hopefully I'll find more time here.. - Jay > Date: Tue, 19 May 2015 23:56:09 +0200 > From: wagner at elegosoft.com > To: rodney.m.bates at acm.org; m3devel at elegosoft.com > Subject: Re: [M3devel] Bootstrapping cm3 on OS X 10.9.5 > > On Tue, 19 May 2015 01:33:49 +0200 > Olaf Wagner wrote: > > > After replacing the configuration files with those from the current code > > base and adapting some basic system tool definitions like gcc and libtool > > I have now successfully compiled m3core. This looks good so far. > > I almost succeeded in building a new cm3 from sources now, but I'm > stuck at something again I don't understand. Symbol ___eprintf is > referenced from m3core, but there is no static definition for it in > any library I can find. > > -> linking cm3 > generate _m3main.new > compare _m3main.new _m3main.c > rm _m3main.new > /usr/bin/gcc -o cm3 _m3main.o cm3unix.o Version.io M3Backend.io M3Backend.mo UtilsPosix.mo Arg.io Arg.mo Builder.io Builder.mo Dirs.io Dirs.mo M3Build.io M3Build.mo M3Loc.io M3Loc.mo M3Options.io M3Options.mo M3Unit.io M3Unit.mo Makefile.io Makefile.mo Msg.io Msg.mo Utils.io Utils.mo WebFile.io WebFile.mo Main.mo /usr/local/cm3/pkg/m3back/AMD64_DARWIN/libm3back.a /usr/local/cm3/pkg/m3objfile/AMD64_DARWIN/libm3objfile.a /usr/local/cm3/pkg/m3quake/AMD64_DARWIN/libm3quake.a /usr/local/cm3/pkg/m3front/AMD64_DARWIN/libm3front.a /usr/local/cm3/pkg/m3linker/AMD64_DARWIN/libm3link.a /usr/local/cm3/pkg/m3middle/AMD64_DARWIN/libm3middle.a /usr/local/cm3/pkg/sysutils/AMD64_DARWIN/libsysutils.a /usr/local/cm3/pkg/libm3/AMD64_DARWIN/libm3.a /usr/local/cm3/pkg/m3core/AMD64_DARWIN/libm3core.a -multiply_defined suppress -bind_at_load -shared-libgcc -dead_strip -headerpad_max_install_names > Undefined symbols for architecture x86_64: > "___eprintf", referenced from: > _ThreadPThread__ProcessStopped in libm3core.a(ThreadApple.o) > _InstallOneHandler in libm3core.a(RTSignalC.o) > ld: symbol(s) not found for architecture x86_64 > clang: error: linker command failed with exit code 1 (use -v to see invocation) > > ---- > > elegos-MacBook-Pro:cm3 wagner$ for f in $(find /usr/lib /usr/local/lib /opt/local/lib /usr/local/cm3/lib -name *.a); do nm $f 2>/dev/null | grep ___eprintf && echo "found in $f"; done > U ___eprintf > U ___eprintf > found in /usr/local/cm3/lib/libm3core.a > > ---- > > elegos-MacBook-Pro:cm3 wagner$ for f in $(find /usr/lib /usr/local/lib /opt/local/lib /usr/local/cm3/lib -name *.dylib); do nm $f 2>/dev/null | grep ___eprintf && echo "found in $f"; done > U ___eprintf > 000141c0 t ___eprintf > found in /usr/lib/lib6200Lib.dylib > U ___eprintf > 00019bf0 t ___eprintf > found in /usr/lib/lib7225lib.dylib > 00016c60 t ___eprintf > U ___eprintf > found in /usr/lib/lib8200Alib.dylib > 00017d30 t ___eprintf > U ___eprintf > found in /usr/lib/lib8220lib.dylib > U ___eprintf > 00009a10 t ___eprintf > found in /usr/lib/libAgent.dylib > U ___eprintf > 00018f00 t ___eprintf > found in /usr/lib/libIceraDownloadLib.dylib > U ___eprintf > 000081bb t ___eprintf > found in /usr/lib/libTinyXml.dylib > 0000000000001850 t ___eprintf > found in /usr/local/cm3/lib/libm3core.5.2.dylib > 0000000000001850 t ___eprintf > found in /usr/local/cm3/lib/libm3core.5.dylib > 0000000000001850 t ___eprintf > found in /usr/local/cm3/lib/libm3core.dylib > > ---- > > Does anybody know what it the standard solution for this? > The symbol is even defined in the dynamic version of m3core itself. > Is static linking not supported anymore? Or should I just link > against one of the above dynamically? > The m3makefile for cm3 still contains > > build_standalone () %-- we don't want to depend on the shared libraries... > > > Any hint will be appreciated. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Wed May 20 22:12:50 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Wed, 20 May 2015 15:12:50 -0500 Subject: [M3devel] Rerunning m3cggen In-Reply-To: References: <555B9A5A.2090106@lcwb.coop>, <20150520002141.1291106319a5d76adad4415e@elegosoft.com> Message-ID: <555CEAC2.8050202@lcwb.coop> So what command(s) now take care of it? I wasn't getting it to happen, until I did it manually. On 05/20/2015 02:01 PM, Jay K wrote: > I think I automated it. But historically, in those other paths, it wasn't automated. > Not a problem with the C backend. :) > > - Jay > > > > > Date: Wed, 20 May 2015 00:21:41 +0200 > > From: wagner at elegosoft.com > > To: rodney.m.bates at acm.org > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] Rerunning m3cggen > > > > On Tue, 19 May 2015 15:17:30 -0500 > > "Rodney M. Bates" wrote: > > > > > What does it take to get m3cggen to be rerun? scripts/do-pkg.sh buildship m3cc doesn't > > > appear to do it, nor does cm3 in m3-sys/m3cc. Does it need to be done manually? > > > > As long as I remember, I never automated anything that runs m3cggen. > > So I assume the answer should be yes. > > > > Olaf > > -- > > Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > > Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -- Rodney Bates rodney.m.bates at acm.org From wagner at elegosoft.com Thu May 21 01:51:15 2015 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 21 May 2015 01:51:15 +0200 Subject: [M3devel] Bootstrapping cm3 on OS X 10.9.5 In-Reply-To: References: <20150517011824.75f096c832d5da56e4810bbf@elegosoft.com> <5558AA20.1090208@lcwb.coop> <555A14B2.7090900@lcwb.coop> <555A196E.2020106@lcwb.coop> <20150518234714.dd1c111374ba3614cd74a63e@elegosoft.com> <20150519013349.0ba8729443cabb394424d3cd@elegosoft.com> <20150519235609.41e93f178398d113bdecb79d@elegosoft.com> Message-ID: <20150521015115.1c558406fe4358c833242628@elegosoft.com> On Wed, 20 May 2015 19:11:22 +0000 Jay K wrote: > Hi Olaf, > This is surely some printf/sprint wrapper from stdio.h.Did you copy files across from some other machine or this is all one-machine?Try the C backend? I > -lSystem? > > #include int main(){char buffer[10];printf("");sprint(buffer, "");return 0;} > gcc -E 1.c gcc -S 1.c gcc 1.c gcc -v 1.c libtool a.out ? > Hopefully I'll find more time here.. Of course the binary distribution came from another machine and was several years old and had a different setup than my current computer. However, I think I had enough of an idea what was going on finally, and with much tweaking and manual intervention I was able to do a complete bootstrap. I've compiled all the packages now, and the demo programs I tried worked as expected (fisheye, Solitaire). Trying the C backend would have been my next attempt ;-) If anybody is interested in a copy of the installed system I can try to upload that somewhere in the next week. I'm not sure if there is currently a repository for packages or installation archives different from the old one on the M3 (elego) web site, which contains only packages several years old. Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Thu May 21 10:05:31 2015 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 21 May 2015 10:05:31 +0200 Subject: [M3devel] Repo access, was: Re: Bootstrapping cm3 on OS X 10.9.5 In-Reply-To: References: <20150517011824.75f096c832d5da56e4810bbf@elegosoft.com> <5558AA20.1090208@lcwb.coop> <555A14B2.7090900@lcwb.coop> <555A196E.2020106@lcwb.coop> <20150518234714.dd1c111374ba3614cd74a63e@elegosoft.com> <20150519013349.0ba8729443cabb394424d3cd@elegosoft.com> <20150519235609.41e93f178398d113bdecb79d@elegosoft.com> <20150521015115.1c558406fe4358c833242628@elegosoft.com> Message-ID: <20150521100531.8ca0c02c2553e513e480e6dc@elegosoft.com> On Wed, 20 May 2015 20:58:13 -0400 Antony Hosking wrote: > That's great! > I suppose bootstrap binaries should go on guthub? Can I get commit permissions again? I think I read somewhere that you managed that now. elegos-MacBook-Pro:cm3 wagner$ git push X11 forwarding request failed on channel 0 ERROR: Permission to modula3/cm3.git denied to olaf-wagner. fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. I'd just like to increase the compiler version number and make some minor updates to scripts. You can find me among the watchers of cm3. Olaf > Sent from my iPhone > > > On May 20, 2015, at 7:51 PM, Olaf Wagner wrote: > > > > On Wed, 20 May 2015 19:11:22 +0000 > > Jay K wrote: > > > >> Hi Olaf, > >> This is surely some printf/sprint wrapper from stdio.h.Did you copy files across from some other machine or this is all one-machine?Try the C backend? I > >> -lSystem? > >> > >> #include int main(){char buffer[10];printf("");sprint(buffer, "");return 0;} > >> gcc -E 1.c gcc -S 1.c gcc 1.c gcc -v 1.c libtool a.out ? > >> Hopefully I'll find more time here.. > > > > Of course the binary distribution came from another machine and was > > several years old and had a different setup than my current computer. > > > > However, I think I had enough of an idea what was going on finally, > > and with much tweaking and manual intervention I was able to do a > > complete bootstrap. I've compiled all the packages now, and > > the demo programs I tried worked as expected (fisheye, Solitaire). > > > > Trying the C backend would have been my next attempt ;-) > > > > If anybody is interested in a copy of the installed system I can try > > to upload that somewhere in the next week. I'm not sure if there is > > currently a repository for packages or installation archives different > > from the old one on the M3 (elego) web site, which contains only > > packages several years old. > > > > Olaf > > -- > > Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > > Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From estellnb at elstel.org Thu May 21 12:07:53 2015 From: estellnb at elstel.org (Elmar Stellnberger) Date: Thu, 21 May 2015 12:07:53 +0200 Subject: [M3devel] Bootstrapping cm3 on OS X 10.9.5 In-Reply-To: <20150521015115.1c558406fe4358c833242628@elegosoft.com> References: <20150517011824.75f096c832d5da56e4810bbf@elegosoft.com> <5558AA20.1090208@lcwb.coop> <555A14B2.7090900@lcwb.coop> <555A196E.2020106@lcwb.coop> <20150518234714.dd1c111374ba3614cd74a63e@elegosoft.com> <20150519013349.0ba8729443cabb394424d3cd@elegosoft.com> <20150519235609.41e93f178398d113bdecb79d@elegosoft.com> <20150521015115.1c558406fe4358c833242628@elegosoft.com> Message-ID: <40F30E19-16FB-4993-9712-3B67B9A624B4@elstel.org> Dear Olaf, I have Mac OS 10.7.5 here and would like to give your new binaries a try. Do the binaries include a version of Qt or will I have to install qt4/5 in addition to your binaries? It should not be a problem for me if Qt is only available to C/C++ externals. Elmar Am 21.05.2015 um 01:51 schrieb Olaf Wagner: > On Wed, 20 May 2015 19:11:22 +0000 > Jay K wrote: > >> Hi Olaf, >> This is surely some printf/sprint wrapper from stdio.h.Did you copy files across from some other machine or this is all one-machine?Try the C backend? I >> -lSystem? >> >> #include int main(){char buffer[10];printf("");sprint(buffer, "");return 0;} >> gcc -E 1.c gcc -S 1.c gcc 1.c gcc -v 1.c libtool a.out ? >> Hopefully I'll find more time here.. > > Of course the binary distribution came from another machine and was > several years old and had a different setup than my current computer. > > However, I think I had enough of an idea what was going on finally, > and with much tweaking and manual intervention I was able to do a > complete bootstrap. I've compiled all the packages now, and > the demo programs I tried worked as expected (fisheye, Solitaire). > > Trying the C backend would have been my next attempt ;-) > > If anybody is interested in a copy of the installed system I can try > to upload that somewhere in the next week. I'm not sure if there is > currently a repository for packages or installation archives different > from the old one on the M3 (elego) web site, which contains only > packages several years old. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From wagner at elegosoft.com Thu May 21 17:50:16 2015 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 21 May 2015 17:50:16 +0200 Subject: [M3devel] Qt bindings, was: Re: Bootstrapping cm3 on OS X 10.9.5 In-Reply-To: <40F30E19-16FB-4993-9712-3B67B9A624B4@elstel.org> References: <20150517011824.75f096c832d5da56e4810bbf@elegosoft.com> <5558AA20.1090208@lcwb.coop> <555A14B2.7090900@lcwb.coop> <555A196E.2020106@lcwb.coop> <20150518234714.dd1c111374ba3614cd74a63e@elegosoft.com> <20150519013349.0ba8729443cabb394424d3cd@elegosoft.com> <20150519235609.41e93f178398d113bdecb79d@elegosoft.com> <20150521015115.1c558406fe4358c833242628@elegosoft.com> <40F30E19-16FB-4993-9712-3B67B9A624B4@elstel.org> Message-ID: <20150521175016.a551cb784f3bed67aa833835@elegosoft.com> On Thu, 21 May 2015 12:07:53 +0200 Elmar Stellnberger wrote: > Dear Olaf, > > I have Mac OS 10.7.5 here and would like to give your new binaries a try. > Do the binaries include a version of Qt or will I have to install qt4/5 in addition to your binaries? > It should not be a problem for me if Qt is only available to C/C++ externals. I just gave that a try. QtEventLoopRaw.m3 cannot be found: === package m3-ui/qt/m3qtcore === +++ cm3 -build -override $RARGS -DROOT='/Users/wagner/work/cm3' +++ --- building in AMD64_DARWIN --- unable to read ../src/m3overrides, options "-override" and "-x" ignored. compiling ../src/dynamicqobject.cxx compiling ../src/QtNamespace_wrap.cxx compiling ../src/QtDynamic_wrap.cxx ../src/QtDynamic_wrap.cxx:164:3: warning: delete called on 'AbstractDynamicSlot' that is abstract but has non-virtual destructor [-Wdelete-non-virtual-dtor] delete arg1; ^ 1 warning generated. compiling ../src/QtCoreApplication_wrap.cxx compiling ../src/QtByteArray_wrap.cxx compiling ../src/QtString_wrap.cxx compiling ../src/QtList_wrap.cxx compiling ../src/QtStringList_wrap.cxx compiling ../src/QtEventLoop_wrap.cxx compiling ../src/QtEvent_wrap.cxx ../src/QtEvent_wrap.cxx:376:23: warning: 'QDynamicPropertyChangeEvent_propertyName' has C-linkage specified, but returns user-defined type 'QByteArray' which is incompatible with C [-Wreturn-type-c-linkage] SWIGEXPORT QByteArray QDynamicPropertyChangeEvent_propertyName(QDynamicPropertyChangeEvent const * self) { ^ 1 warning generated. compiling ../src/QtObject_wrap.cxx compiling ../src/QtPoint_wrap.cxx ../src/QtPoint_wrap.cxx:472:21: warning: 'QPointF_rx' has C-linkage specified, but returns user-defined type 'double &' which is incompatible with C [-Wreturn-type-c-linkage] SWIGEXPORT double & QPointF_rx(QPointF * self) { ^ ../src/QtPoint_wrap.cxx:484:21: warning: 'QPointF_ry' has C-linkage specified, but returns user-defined type 'double &' which is incompatible with C [-Wreturn-type-c-linkage] SWIGEXPORT double & QPointF_ry(QPointF * self) { ^ 2 warnings generated. compiling ../src/QtLine_wrap.cxx compiling ../src/QtSize_wrap.cxx ../src/QtSize_wrap.cxx:584:21: warning: 'QSizeF_rwidth' has C-linkage specified, but returns user-defined type 'double &' which is incompatible with C [-Wreturn-type-c-linkage] SWIGEXPORT double & QSizeF_rwidth(QSizeF * self) { ^ ../src/QtSize_wrap.cxx:596:21: warning: 'QSizeF_rheight' has C-linkage specified, but returns user-defined type 'double &' which is incompatible with C [-Wreturn-type-c-linkage] SWIGEXPORT double & QSizeF_rheight(QSizeF * self) { ^ 2 warnings generated. compiling ../src/QtRect_wrap.cxx compiling ../src/QtDateTime_wrap.cxx compiling ../src/QtMargins_wrap.cxx compiling ../src/QtAbstractItemModel_wrap.cxx ../src/QtAbstractItemModel_wrap.cxx:266:26: warning: 'QModelIndex_flags' has C-linkage specified, but returns user-defined type 'Qt::ItemFlags' (aka 'QFlags') which is incompatible with C [-Wreturn-type-c-linkage] SWIGEXPORT Qt::ItemFlags QModelIndex_flags(QModelIndex const * self) { ^ ../src/QtAbstractItemModel_wrap.cxx:416:26: warning: 'QPersistentModelIndex_flags' has C-linkage specified, but returns user-defined type 'Qt::ItemFlags' (aka 'QFlags') which is incompatible with C [-Wreturn-type-c-linkage] SWIGEXPORT Qt::ItemFlags QPersistentModelIndex_flags(QPersistentModelIndex const * self) { ^ ../src/QtAbstractItemModel_wrap.cxx:652:28: warning: 'QAbstractItemModel_supportedDropActions' has C-linkage specified, but returns user-defined type 'Qt::DropActions' (aka 'QFlags') which is incompatible with C [-Wreturn-type-c-linkage] SWIGEXPORT Qt::DropActions QAbstractItemModel_supportedDropActions(QAbstractItemModel * self) { ^ ../src/QtAbstractItemModel_wrap.cxx:662:28: warning: 'QAbstractItemModel_supportedDragActions' has C-linkage specified, but returns user-defined type 'Qt::DropActions' (aka 'QFlags') which is incompatible with C [-Wreturn-type-c-linkage] SWIGEXPORT Qt::DropActions QAbstractItemModel_supportedDragActions(QAbstractItemModel * self) { ^ ../src/QtAbstractItemModel_wrap.cxx:962:26: warning: 'QAbstractItemModel_flags' has C-linkage specified, but returns user-defined type 'Qt::ItemFlags' (aka 'QFlags') which is incompatible with C [-Wreturn-type-c-linkage] SWIGEXPORT Qt::ItemFlags QAbstractItemModel_flags(QAbstractItemModel * self, QModelIndex const & index) { ^ 5 warnings generated. unable to open file for reading: ../src/QtEventLoopRaw.m3: errno=2 open failed on: ../src/QtEventLoopRaw.m3 Fatal Error: failed compiling: *** execution of cm3 -build -override $RARGS -DROOT='/Users/wagner/work/cm3' failed *** elegos-MacBook-Pro:cm3 wagner$ find m3-ui -name '*EventLoop*' -print m3-ui/qt/m3qtcore/AMD64_DARWIN/QtEventLoop.io m3-ui/qt/m3qtcore/AMD64_DARWIN/QtEventLoop_wrap.o m3-ui/qt/m3qtcore/AMD64_DARWIN/QtEventLoopRaw.io m3-ui/qt/m3qtcore/src/QtEventLoop.i3 m3-ui/qt/m3qtcore/src/QtEventLoop.m3 m3-ui/qt/m3qtcore/src/QtEventLoop_wrap.cxx m3-ui/qt/m3qtcore/src/QtEventLoop_wrap.o m3-ui/qt/m3qtcore/src/QtEventLoopRaw.i3 m3-ui/qt/m3qtcore/src/swig/QtEventLoop.i The warnings seem to indicate that there may be more problems. I installed qt 4.8.6 via brew: elegos-MacBook-Pro:cm3 wagner$ brew install qt ==> Downloading https://downloads.sf.net/project/machomebrew/Bottles/qt-4.8.6.mavericks.bottle.6.tar.gz ######################################################################## 100.0% ==> Pouring qt-4.8.6.mavericks.bottle.6.tar.gz ==> Caveats We agreed to the Qt opensource license for you. If this is unacceptable you should uninstall. .app bundles were installed. Run `brew linkapps` to symlink these to /Applications. ==> Summary /usr/local/Cellar/qt/4.8.6: 2790 files, 122M Any advice what I did wrong? Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From rodney_bates at lcwb.coop Thu May 21 18:57:07 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 21 May 2015 11:57:07 -0500 Subject: [M3devel] LLVM version and patches thereto Message-ID: <555E0E63.6070506@lcwb.coop> Peter, what version of llvm are you using? Also, can you tell us what the patches you have made to it are? Have you sent these to the llvm developers to incorporate? I can guess one is to tolerate DW_LANG_Modula3. -- Rodney Bates rodney.m.bates at acm.org From hendrik at topoi.pooq.com Thu May 21 18:56:00 2015 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Thu, 21 May 2015 12:56:00 -0400 Subject: [M3devel] Bootstrapping cm3 on OS X 10.9.5 In-Reply-To: <40F30E19-16FB-4993-9712-3B67B9A624B4@elstel.org> References: <20150517011824.75f096c832d5da56e4810bbf@elegosoft.com> <5558AA20.1090208@lcwb.coop> <555A14B2.7090900@lcwb.coop> <555A196E.2020106@lcwb.coop> <20150518234714.dd1c111374ba3614cd74a63e@elegosoft.com> <20150519013349.0ba8729443cabb394424d3cd@elegosoft.com> <20150519235609.41e93f178398d113bdecb79d@elegosoft.com> <20150521015115.1c558406fe4358c833242628@elegosoft.com> <40F30E19-16FB-4993-9712-3B67B9A624B4@elstel.org> Message-ID: <20150521165600.GA13058@topoi.pooq.com> On Thu, May 21, 2015 at 12:07:53PM +0200, Elmar Stellnberger wrote: > Dear Olaf, > > I have Mac OS 10.7.5 here and would like to give your new binaries a try. > Do the binaries include a version of Qt or will I have to install qt4/5 in addition to your binaries? > It should not be a problem for me if Qt is only available to C/C++ externals. Live and learn! I didn't know there *was* a Qt binding for Modula 3. I could sure use it. What interfaces and modules provide it? -- hendrik From rodney_bates at lcwb.coop Thu May 21 19:24:12 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 21 May 2015 12:24:12 -0500 Subject: [M3devel] How to integrate llvm into cm3 Message-ID: <555E14BC.2040805@lcwb.coop> I previously made significant changes to cm3 and related, to drive an llvm backend and have them in a branch. I added 4 new backend modes. IntLlvmObj and IntLlvmAsm are "internal", meaning a complete llvm-derived back end is linked in with cm3, similar to the x86 internal backend, found in m3back. Obj/Asm is whether it produces object modules or assembly code. (I did not set out to use these, just put them in for completeness.) ExtLlvmObj and ExtLlvmAsm are for "external". In these, a separate executable llvm backend is used (llc) that reads llvm bitcode, generated by cm3. The code to produce the llvm-IR is in a package m3llvmgen. It links in some amount of llvm infrastructure to build llvm IR in-memory trees, then write them to llvm bitcode. Peter's cm3-IR to llvm-IR conversion is a separately compiled executable, which differs from both the above organizations. It relys on cm3's existing ability to write cm3-IR to a file in binary form. It reads this (either binary or text form, with a small code change) and produces llvm bitcode files. So, do we have any preference about how to do this. Code changes to either read cm3-IR from a binary file, a text file, or get it directly inside the cm3 executable are nearly trivial. Just substitute a different subtype of M3CG.T. to supply the cm3-IR operator stream. Cm3 changes would be a bit bigger to drive the separate executable pass. There are pros and cons. Integrating Peter's cm3-to-llvm conversion into the cm3 executable would be faster compiling--one fewer time per interface or module for the OS to create a process and run an executable. But it would also entail linking in this code, along with some of llvm's infrastructure, into cm3, making its executable bigger, with code that might not be executed at all, when a different backend is used. We already have the x86 integrated backend and the C backend linked in to cm3, whether used or not. Anybody have thoughts on this? I suppose it could be set up to be fairly easily changed either way too. -- Rodney Bates rodney.m.bates at acm.org From estellnb at elstel.org Thu May 21 20:13:18 2015 From: estellnb at elstel.org (Elmar Stellnberger) Date: Thu, 21 May 2015 20:13:18 +0200 Subject: [M3devel] How to integrate llvm into cm3 In-Reply-To: <555E14BC.2040805@lcwb.coop> References: <555E14BC.2040805@lcwb.coop> Message-ID: <555E203E.4040203@elstel.org> Am 21.05.15 um 19:24 schrieb Rodney M. Bates: > > There are pros and cons. Integrating Peter's cm3-to-llvm conversion into > the cm3 executable would be faster compiling--one fewer time per > interface > or module for the OS to create a process and run an executable. But it > would also entail linking in this code, along with some of llvm's > infrastructure, > into cm3, making its executable bigger, with code that might not be > executed > at all, when a different backend is used. We already have the x86 > integrated > backend and the C backend linked in to cm3, whether used or not. > > Anybody have thoughts on this? I suppose it could be set up to be fairly > easily changed either way too. > Why not put each backend into a shared library and load it dynamically? Are there still problems with shared libraries for some build targets? On the other hand having cm3-IR handy and being able to translate cm3-IR by an executable like m3cc into any desired target has proven to be very handy for debugging as well as chocking the Modula-3 compiler on a new platform. My personal preference would be to only have one default target statically compiled in namely that on for cm3-IR and load all other targets by a shared libarary dynamically. If that should fail for some reason one can still use m3cc or one of its counterparts to accomplish the translation process. Elmar From peter.mckinna at gmail.com Fri May 22 00:09:28 2015 From: peter.mckinna at gmail.com (Peter McKinna) Date: Fri, 22 May 2015 08:09:28 +1000 Subject: [M3devel] LLVM version and patches thereto In-Reply-To: <555E0E63.6070506@lcwb.coop> References: <555E0E63.6070506@lcwb.coop> Message-ID: Hi Rodney, Good to see this stuff moving forward. I had no idea how to integrate it with the front end. I'm using llvm 3.5 . I downloaded 3.6 and built it but then could not get some dibuilder bindings I had added to compile, some sort of problem with the wrap function which I have yet to sort out. I think they made a change to the way metadata is treated. Anyway I have attached the 2 sets of bindings I have been using. I have to commit a few bug fixes and my initial attempt at debug support. Speaking of debugging, I was following what I think clang uses which is the dibuilder class . So far its very primitive and could probably be split into its own module. I managed to get simple scalars, enumerations, arrays and records to be debugged with stock gdb and none of the name mangling I usually get. But globals, objects and sets dont work. I think this needs an expert and mybe a chat with the llvm people, they seem pretty helpful. Anyway it runs the maze program, I compiled the collector the other day, 15,000 lines of llvm ir. The code quality looks pretty good from a brief inspection of the assembly thats compiled at O3 although O2 doesnt make much difference. I read in tips for programmers somewhere that pascal like languages with lots of runtime checks should be running some extra passes for better optimisation. We could look at that in the future. Regards Peter On Fri, May 22, 2015 at 2:57 AM, Rodney M. Bates wrote: > Peter, what version of llvm are you using? Also, can you tell us what the > patches > you have made to it are? Have you sent these to the llvm developers to > incorporate? > I can guess one is to tolerate DW_LANG_Modula3. > > > -- > Rodney Bates > rodney.m.bates at acm.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: M3Extras.h Type: text/x-chdr Size: 838 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DIBuilderBindings.h Type: text/x-chdr Size: 6034 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: M3Extras.cpp Type: text/x-c++src Size: 2354 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DIBuilderBindings.cpp Type: text/x-c++src Size: 11648 bytes Desc: not available URL: From jay.krell at cornell.edu Fri May 22 02:57:07 2015 From: jay.krell at cornell.edu (Jay K) Date: Fri, 22 May 2015 00:57:07 +0000 Subject: [M3devel] How to integrate llvm into cm3 In-Reply-To: <555E203E.4040203@elstel.org> References: <555E14BC.2040805@lcwb.coop>,<555E203E.4040203@elstel.org> Message-ID: Imho "all" options should be implemented, for purposes of convenient debugging/development of the backends. "external" is good for developing backends. You can "snapshot" the state of things slightly into the pipeline and then just iterate on later parts. At the cost of having all the serialization code. "integrated" is usually preferable for performance, for users. E.g. NTx86 backend has been sitting in there for decades unused by half the users. Having extra backends sitting in there unused is ok. Ideally, agreed, they'd be .dll/.sos if we can construct it that way, but ok either way imho. Ideally also cm3 would dynamically link to libm3/m3core, but it doesn't. Everything is demand paged so there is cost to distribute over the network and copy around, but at runtime, the pages just sit mostly cold on disk. One difficulty though is the need to have and build the LLVM code. For that reason, delayload-dynamically-linked might be preferable. It depends on how small/easy-to-build LLVM is. I guess LLVM provides more choices than before. In order of efficiency and inverse order of debuggability: 1 We could construct LLVM IR in memory and run LLVM in-proc and write .o. 2 We could write out LLVM bytes and run an executable. 3 We could write out LLVM text and run an executable. > My personal preference would be to only have one default target statically compiled in It has never worked that away. Granted, we didn't really have backends before, just writing mainly IR. And I don't think LLVM works that way, does it? I like one compiler to have all targets and just select with a command line switch. I don't like how hard it is to acquire various cross-toolschains. Granted, we cheat and are incomplete -- you still need the next piece of the pipeline, be it LLVM or m3cc (which has one target), or a C compiler or assembler or linker or "libc.a". binutils at least has this "all" notion reasonably well working now I believe. There are tradeoffs though. If only one backend has a bug, and they are all statically linked together, you have to update them all.And the largely wasted bloat. Ultimately really, I'd like the C backend to output portable C and then just one C backend, one distribution .tar.gz for all targets.There is work to do there..not easy..and no progress lately.Things like INTEGER preserving flexibility in the output, and using sizeof(INTEGER) in expressions instead of using 4 or 8 and folding... - Jay > Date: Thu, 21 May 2015 20:13:18 +0200 > From: estellnb at elstel.org > To: rodney.m.bates at acm.org; m3devel at elegosoft.com > Subject: Re: [M3devel] How to integrate llvm into cm3 > > Am 21.05.15 um 19:24 schrieb Rodney M. Bates: > > > > There are pros and cons. Integrating Peter's cm3-to-llvm conversion into > > the cm3 executable would be faster compiling--one fewer time per > > interface > > or module for the OS to create a process and run an executable. But it > > would also entail linking in this code, along with some of llvm's > > infrastructure, > > into cm3, making its executable bigger, with code that might not be > > executed > > at all, when a different backend is used. We already have the x86 > > integrated > > backend and the C backend linked in to cm3, whether used or not. > > > > Anybody have thoughts on this? I suppose it could be set up to be fairly > > easily changed either way too. > > > > Why not put each backend into a shared library and load it dynamically? > Are there still problems with shared libraries for some build targets? > On the other hand having cm3-IR handy and being able to translate > cm3-IR by an executable like m3cc into any desired target has proven > to be very handy for debugging as well as chocking the Modula-3 > compiler on a new platform. > My personal preference would be to only have one default target > statically compiled in namely that on for cm3-IR and load all other > targets by a shared libarary dynamically. If that should fail for some > reason one can still use m3cc or one of its counterparts to > accomplish the translation process. > > Elmar > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.mckinna at gmail.com Fri May 22 05:01:25 2015 From: peter.mckinna at gmail.com (Peter McKinna) Date: Fri, 22 May 2015 13:01:25 +1000 Subject: [M3devel] How to integrate llvm into cm3 In-Reply-To: References: <555E14BC.2040805@lcwb.coop> <555E203E.4040203@elstel.org> Message-ID: I followed the m3cc design mainly because I didnt want to include the llvm libs in the link for cm3. It is a c++ lib set and requires the c++ linker which if you have ever built llvm or clang leaves you wondering about that linker. I was watching it link an llvm lib once and it took over 19 seconds. In fact watching the llvm build is like watching grass grow, it takes over 2 hours on my humble laptop (core i3). They estimate about 40 minutes on a "fast" machine. I digress. If llvm or other library is statically linked into cm3 and its not part of the standard toolchain then we would have to ship the those libs woudnt we? We dont have the package mechanism like debian and others which will drag in dependant libraries. At the moment we ship the sources and say build this with what youve got installed. Peter On Fri, May 22, 2015 at 10:57 AM, Jay K wrote: > Imho "all" options should be implemented, for purposes of convenient > debugging/development of the backends. > > > "external" is good for developing backends. You can "snapshot" the state > of things > slightly into the pipeline and then just iterate on later parts. > > > At the cost of having all the serialization code. > > > "integrated" is usually preferable for performance, for users. > > > E.g. NTx86 backend has been sitting in there for decades unused by half > the users. > > > Having extra backends sitting in there unused is ok. > Ideally, agreed, they'd be .dll/.sos if we can construct it that way, but > ok either way imho. > Ideally also cm3 would dynamically link to libm3/m3core, but it doesn't. > > > Everything is demand paged so there is cost to distribute over the network > and copy around, but at runtime, the pages just sit mostly cold on disk. > > > One difficulty though is the need to have and build the LLVM code. > For that reason, delayload-dynamically-linked might be preferable. > It depends on how small/easy-to-build LLVM is. > > > I guess LLVM provides more choices than before. > In order of efficiency and inverse order of debuggability: > 1 We could construct LLVM IR in memory and run LLVM in-proc and write > .o. > 2 We could write out LLVM bytes and run an executable. > 3 We could write out LLVM text and run an executable. > > > > My personal preference would be to only have one default target > statically compiled in > > It has never worked that away. Granted, we didn't really have backends > before, just writing mainly IR. > And I don't think LLVM works that way, does it? > > I like one compiler to have all targets and just select with a command > line switch. > > I don't like how hard it is to acquire various cross-toolschains. > Granted, we cheat and are incomplete -- you still need the next piece of > the pipeline, > be it LLVM or m3cc (which has one target), or a C compiler or assembler > or linker or "libc.a". > > > binutils at least has this "all" notion reasonably well working now I > believe. > > > > There are tradeoffs though. If only one backend has a bug, and they are > all statically linked together, you have to update them all. > And the largely wasted bloat. > > > Ultimately really, I'd like the C backend to output portable C and then > just one C backend, one distribution .tar.gz for all targets. > There is work to do there..not easy..and no progress lately. > Things like INTEGER preserving flexibility in the output, and using > sizeof(INTEGER) in expressions instead of using 4 or 8 and folding... > > > > - Jay > > > > > > Date: Thu, 21 May 2015 20:13:18 +0200 > > From: estellnb at elstel.org > > To: rodney.m.bates at acm.org; m3devel at elegosoft.com > > Subject: Re: [M3devel] How to integrate llvm into cm3 > > > > > Am 21.05.15 um 19:24 schrieb Rodney M. Bates: > > > > > > There are pros and cons. Integrating Peter's cm3-to-llvm conversion > into > > > the cm3 executable would be faster compiling--one fewer time per > > > interface > > > or module for the OS to create a process and run an executable. But it > > > would also entail linking in this code, along with some of llvm's > > > infrastructure, > > > into cm3, making its executable bigger, with code that might not be > > > executed > > > at all, when a different backend is used. We already have the x86 > > > integrated > > > backend and the C backend linked in to cm3, whether used or not. > > > > > > Anybody have thoughts on this? I suppose it could be set up to be > fairly > > > easily changed either way too. > > > > > > > Why not put each backend into a shared library and load it dynamically? > > Are there still problems with shared libraries for some build targets? > > On the other hand having cm3-IR handy and being able to translate > > cm3-IR by an executable like m3cc into any desired target has proven > > to be very handy for debugging as well as chocking the Modula-3 > > compiler on a new platform. > > My personal preference would be to only have one default target > > statically compiled in namely that on for cm3-IR and load all other > > targets by a shared libarary dynamically. If that should fail for some > > reason one can still use m3cc or one of its counterparts to > > accomplish the translation process. > > > > Elmar > > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmuysers at hotmail.com Fri May 22 10:48:36 2015 From: dmuysers at hotmail.com (dirk muysers) Date: Fri, 22 May 2015 10:48:36 +0200 Subject: [M3devel] How to integrate llvm into cm3 In-Reply-To: References: <555E14BC.2040805@lcwb.coop>, <555E203E.4040203@elstel.org> Message-ID: Personally I have a strong dislike towards LLVM. 1. You first have to compile the whole tool chain. 2. It is a monstrous blob of code, mainly on Windows. 3. Contrary to a widespread belief, It is definitely NOT platform independent. 4. It changes at every release. 5. Having built your objects, you still have to run them through a platform assembler-linker. If I still had the energy of my younger years I would try to pack the platform dependent part of the libraries into a dynamic load library together with a JIT translator (e.g. libjit) for the portable application code and have a single byte-code producing compiler backend. From: Jay K Sent: Friday, May 22, 2015 2:57 AM To: Elmar Stellnberger ; rodney.m.bates at acm.org ; m3devel Subject: Re: [M3devel] How to integrate llvm into cm3 Imho "all" options should be implemented, for purposes of convenient debugging/development of the backends. "external" is good for developing backends. You can "snapshot" the state of things slightly into the pipeline and then just iterate on later parts. At the cost of having all the serialization code. "integrated" is usually preferable for performance, for users. E.g. NTx86 backend has been sitting in there for decades unused by half the users. Having extra backends sitting in there unused is ok. Ideally, agreed, they'd be .dll/.sos if we can construct it that way, but ok either way imho. Ideally also cm3 would dynamically link to libm3/m3core, but it doesn't. Everything is demand paged so there is cost to distribute over the network and copy around, but at runtime, the pages just sit mostly cold on disk. One difficulty though is the need to have and build the LLVM code. For that reason, delayload-dynamically-linked might be preferable. It depends on how small/easy-to-build LLVM is. I guess LLVM provides more choices than before. In order of efficiency and inverse order of debuggability: 1 We could construct LLVM IR in memory and run LLVM in-proc and write .o. 2 We could write out LLVM bytes and run an executable. 3 We could write out LLVM text and run an executable. > My personal preference would be to only have one default target statically compiled in It has never worked that away. Granted, we didn't really have backends before, just writing mainly IR. And I don't think LLVM works that way, does it? I like one compiler to have all targets and just select with a command line switch. I don't like how hard it is to acquire various cross-toolschains. Granted, we cheat and are incomplete -- you still need the next piece of the pipeline, be it LLVM or m3cc (which has one target), or a C compiler or assembler or linker or "libc.a". binutils at least has this "all" notion reasonably well working now I believe. There are tradeoffs though. If only one backend has a bug, and they are all statically linked together, you have to update them all. And the largely wasted bloat. Ultimately really, I'd like the C backend to output portable C and then just one C backend, one distribution .tar.gz for all targets. There is work to do there..not easy..and no progress lately. Things like INTEGER preserving flexibility in the output, and using sizeof(INTEGER) in expressions instead of using 4 or 8 and folding... - Jay > Date: Thu, 21 May 2015 20:13:18 +0200 > From: estellnb at elstel.org > To: rodney.m.bates at acm.org; m3devel at elegosoft.com > Subject: Re: [M3devel] How to integrate llvm into cm3 > > Am 21.05.15 um 19:24 schrieb Rodney M. Bates: > > > > There are pros and cons. Integrating Peter's cm3-to-llvm conversion into > > the cm3 executable would be faster compiling--one fewer time per > > interface > > or module for the OS to create a process and run an executable. But it > > would also entail linking in this code, along with some of llvm's > > infrastructure, > > into cm3, making its executable bigger, with code that might not be > > executed > > at all, when a different backend is used. We already have the x86 > > integrated > > backend and the C backend linked in to cm3, whether used or not. > > > > Anybody have thoughts on this? I suppose it could be set up to be fairly > > easily changed either way too. > > > > Why not put each backend into a shared library and load it dynamically? > Are there still problems with shared libraries for some build targets? > On the other hand having cm3-IR handy and being able to translate > cm3-IR by an executable like m3cc into any desired target has proven > to be very handy for debugging as well as chocking the Modula-3 > compiler on a new platform. > My personal preference would be to only have one default target > statically compiled in namely that on for cm3-IR and load all other > targets by a shared libarary dynamically. If that should fail for some > reason one can still use m3cc or one of its counterparts to > accomplish the translation process. > > Elmar > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From estellnb at elstel.org Fri May 22 11:50:38 2015 From: estellnb at elstel.org (Elmar Stellnberger) Date: Fri, 22 May 2015 11:50:38 +0200 Subject: [M3devel] How to integrate llvm into cm3 In-Reply-To: References: <555E14BC.2040805@lcwb.coop>, <555E203E.4040203@elstel.org> Message-ID: <780C53B1-C9EA-479C-86EA-82D4670879DC@elstel.org> Am 22.05.2015 um 10:48 schrieb dirk muysers: > Personally I have a strong dislike towards LLVM. > 1. You first have to compile the whole tool chain. > 2. It is a monstrous blob of code, mainly on Windows. > 3. Contrary to a widespread belief, It is definitely NOT platform independent. > 4. It changes at every release. > 5. Having built your objects, you still have to run them through a platform assembler-linker. Is it really that bad? What about the said platform dependencies you have discovered? I believe llvm could be beneficial in deed when it comes to debugging and/or analyzing Modula-3 programs, as there are tools like SAFECode and to my knowledge we never had a fully featured m3gdb. Besides this I would hardly like to believe that llvm is still that volatile when it comes to changes. I know it had some issues in its first days but I can hardly believe that qt5 on MacOS would rely on clang/llvm if that were not a ready to use technology nowadays. I would hope the main changes to llvm had already been done when Apple started to adopt llvm for its own needs. Concerning the code size of llvm that should not be a problem as long as it remains a separate module compiling into an own executable or a shared library loaded in addition to other backends at runtime. > > If I still had the energy of my younger years I would try to pack the platform > dependent part of the libraries into a dynamic load library together with a JIT > translator (e.g. libjit) for the portable application code and have a single byte-code > producing compiler backend. > > From: Jay K > Sent: Friday, May 22, 2015 2:57 AM > To: Elmar Stellnberger ; rodney.m.bates at acm.org ; m3devel > Subject: Re: [M3devel] How to integrate llvm into cm3 > > Imho "all" options should be implemented, for purposes of convenient debugging/development of the backends. > > > "external" is good for developing backends. You can "snapshot" the state of things > slightly into the pipeline and then just iterate on later parts. > > > At the cost of having all the serialization code. > > > "integrated" is usually preferable for performance, for users. > > > E.g. NTx86 backend has been sitting in there for decades unused by half the users. > > > Having extra backends sitting in there unused is ok. > Ideally, agreed, they'd be .dll/.sos if we can construct it that way, but ok either way imho. > Ideally also cm3 would dynamically link to libm3/m3core, but it doesn't. > > > Everything is demand paged so there is cost to distribute over the network > and copy around, but at runtime, the pages just sit mostly cold on disk. > > > One difficulty though is the need to have and build the LLVM code. > For that reason, delayload-dynamically-linked might be preferable. > It depends on how small/easy-to-build LLVM is. > > > I guess LLVM provides more choices than before. > In order of efficiency and inverse order of debuggability: > 1 We could construct LLVM IR in memory and run LLVM in-proc and write .o. > 2 We could write out LLVM bytes and run an executable. > 3 We could write out LLVM text and run an executable. > > > > My personal preference would be to only have one default target statically compiled in > > It has never worked that away. Granted, we didn't really have backends before, just writing mainly IR. > And I don't think LLVM works that way, does it? > > I like one compiler to have all targets and just select with a command line switch. > > I don't like how hard it is to acquire various cross-toolschains. > Granted, we cheat and are incomplete -- you still need the next piece of the pipeline, > be it LLVM or m3cc (which has one target), or a C compiler or assembler or linker or "libc.a". > > > binutils at least has this "all" notion reasonably well working now I believe. > > > > There are tradeoffs though. If only one backend has a bug, and they are all statically linked together, you have to update them all. > And the largely wasted bloat. > > > Ultimately really, I'd like the C backend to output portable C and then just one C backend, one distribution .tar.gz for all targets. > There is work to do there..not easy..and no progress lately. > Things like INTEGER preserving flexibility in the output, and using sizeof(INTEGER) in expressions instead of using 4 or 8 and folding... > > > > - Jay > > > > > > Date: Thu, 21 May 2015 20:13:18 +0200 > > From: estellnb at elstel.org > > To: rodney.m.bates at acm.org; m3devel at elegosoft.com > > Subject: Re: [M3devel] How to integrate llvm into cm3 > > > > Am 21.05.15 um 19:24 schrieb Rodney M. Bates: > > > > > > There are pros and cons. Integrating Peter's cm3-to-llvm conversion into > > > the cm3 executable would be faster compiling--one fewer time per > > > interface > > > or module for the OS to create a process and run an executable. But it > > > would also entail linking in this code, along with some of llvm's > > > infrastructure, > > > into cm3, making its executable bigger, with code that might not be > > > executed > > > at all, when a different backend is used. We already have the x86 > > > integrated > > > backend and the C backend linked in to cm3, whether used or not. > > > > > > Anybody have thoughts on this? I suppose it could be set up to be fairly > > > easily changed either way too. > > > > > > > Why not put each backend into a shared library and load it dynamically? > > Are there still problems with shared libraries for some build targets? > > On the other hand having cm3-IR handy and being able to translate > > cm3-IR by an executable like m3cc into any desired target has proven > > to be very handy for debugging as well as chocking the Modula-3 > > compiler on a new platform. > > My personal preference would be to only have one default target > > statically compiled in namely that on for cm3-IR and load all other > > targets by a shared libarary dynamically. If that should fail for some > > reason one can still use m3cc or one of its counterparts to > > accomplish the translation process. > > > > Elmar > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmuysers at hotmail.com Fri May 22 12:16:21 2015 From: dmuysers at hotmail.com (dirk muysers) Date: Fri, 22 May 2015 12:16:21 +0200 Subject: [M3devel] How to integrate llvm into cm3 In-Reply-To: <0A1CDD8C-EEB5-40E2-A38B-28E8EEA8C37E@elstel.org> References: <555E14BC.2040805@lcwb.coop>, <555E203E.4040203@elstel.org> <0A1CDD8C-EEB5-40E2-A38B-28E8EEA8C37E@elstel.org> Message-ID: >> What about the said platform dependencies you have discovered? Not me (I never seriously considered using it), but many people on the llvm forums pointed to the fact. One example among many: Does your C code ever use the 'long' type? If so, the LLVM IR will be different depending on whether it's targeting linux-32 or linux-64. Do you ever use size_t? Same problem. Do you ever use a union containing both pointers and integers? See above. In principle, it's possible to write platform-independent IR, or even C code that compiles to platform-independent IR. In practice, especially if you include any system headers, it's remarkably hard. (Jeffrey Yasskin jyasskin at google.com) And then, besides the IR proper, there is that steadily increasing legion of intrinsics. Unless you translate C-like code and build upon the existing technical LLVM heritage, je vous souhaite bien du plaisir as the French say... From: Elmar Stellnberger Sent: Friday, May 22, 2015 11:49 AM To: dirk muysers Subject: Re: [M3devel] How to integrate llvm into cm3 Am 22.05.2015 um 10:48 schrieb dirk muysers: Personally I have a strong dislike towards LLVM. 1. You first have to compile the whole tool chain. 2. It is a monstrous blob of code, mainly on Windows. 3. Contrary to a widespread belief, It is definitely NOT platform independent. 4. It changes at every release. 5. Having built your objects, you still have to run them through a platform assembler-linker. Is it really that bad? What about the said platform dependencies you have discovered? I believe llvm could be beneficial in deed when it comes to debugging and/or analyzing Modula-3 programs, as there are tools like SAFECode and to my knowledge we never had a fully featured m3gdb. Besides this I would hardly like to believe that llvm is still that volatile when it comes to changes. I know it had some issues in its first days but I can hardly believe that qt5 on MacOS would rely on clang/llvm if that were not a ready to use technology nowadays. I would hope the main changes to llvm had already been done when Apple started to adopt llvm for its own needs. Concerning the code size of llvm that should not be a problem as long as it remains a separate module compiling into an own executable or a shared library loaded in addition to other backends at runtime. If I still had the energy of my younger years I would try to pack the platform dependent part of the libraries into a dynamic load library together with a JIT translator (e.g. libjit) for the portable application code and have a single byte-code producing compiler backend. From: Jay K Sent: Friday, May 22, 2015 2:57 AM To: Elmar Stellnberger ; rodney.m.bates at acm.org ; m3devel Subject: Re: [M3devel] How to integrate llvm into cm3 Imho "all" options should be implemented, for purposes of convenient debugging/development of the backends. "external" is good for developing backends. You can "snapshot" the state of things slightly into the pipeline and then just iterate on later parts. At the cost of having all the serialization code. "integrated" is usually preferable for performance, for users. E.g. NTx86 backend has been sitting in there for decades unused by half the users. Having extra backends sitting in there unused is ok. Ideally, agreed, they'd be .dll/.sos if we can construct it that way, but ok either way imho. Ideally also cm3 would dynamically link to libm3/m3core, but it doesn't. Everything is demand paged so there is cost to distribute over the network and copy around, but at runtime, the pages just sit mostly cold on disk. One difficulty though is the need to have and build the LLVM code. For that reason, delayload-dynamically-linked might be preferable. It depends on how small/easy-to-build LLVM is. I guess LLVM provides more choices than before. In order of efficiency and inverse order of debuggability: 1 We could construct LLVM IR in memory and run LLVM in-proc and write .o. 2 We could write out LLVM bytes and run an executable. 3 We could write out LLVM text and run an executable. > My personal preference would be to only have one default target statically compiled in It has never worked that away. Granted, we didn't really have backends before, just writing mainly IR. And I don't think LLVM works that way, does it? I like one compiler to have all targets and just select with a command line switch. I don't like how hard it is to acquire various cross-toolschains. Granted, we cheat and are incomplete -- you still need the next piece of the pipeline, be it LLVM or m3cc (which has one target), or a C compiler or assembler or linker or "libc.a". binutils at least has this "all" notion reasonably well working now I believe. There are tradeoffs though. If only one backend has a bug, and they are all statically linked together, you have to update them all. And the largely wasted bloat. Ultimately really, I'd like the C backend to output portable C and then just one C backend, one distribution .tar.gz for all targets. There is work to do there..not easy..and no progress lately. Things like INTEGER preserving flexibility in the output, and using sizeof(INTEGER) in expressions instead of using 4 or 8 and folding... - Jay > Date: Thu, 21 May 2015 20:13:18 +0200 > From: estellnb at elstel.org > To: rodney.m.bates at acm.org; m3devel at elegosoft.com > Subject: Re: [M3devel] How to integrate llvm into cm3 > > Am 21.05.15 um 19:24 schrieb Rodney M. Bates: > > > > There are pros and cons. Integrating Peter's cm3-to-llvm conversion into > > the cm3 executable would be faster compiling--one fewer time per > > interface > > or module for the OS to create a process and run an executable. But it > > would also entail linking in this code, along with some of llvm's > > infrastructure, > > into cm3, making its executable bigger, with code that might not be > > executed > > at all, when a different backend is used. We already have the x86 > > integrated > > backend and the C backend linked in to cm3, whether used or not. > > > > Anybody have thoughts on this? I suppose it could be set up to be fairly > > easily changed either way too. > > > > Why not put each backend into a shared library and load it dynamically? > Are there still problems with shared libraries for some build targets? > On the other hand having cm3-IR handy and being able to translate > cm3-IR by an executable like m3cc into any desired target has proven > to be very handy for debugging as well as chocking the Modula-3 > compiler on a new platform. > My personal preference would be to only have one default target > statically compiled in namely that on for cm3-IR and load all other > targets by a shared libarary dynamically. If that should fail for some > reason one can still use m3cc or one of its counterparts to > accomplish the translation process. > > Elmar > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From estellnb at elstel.org Fri May 22 12:53:14 2015 From: estellnb at elstel.org (Elmar Stellnberger) Date: Fri, 22 May 2015 12:53:14 +0200 Subject: [M3devel] How to integrate llvm into cm3 In-Reply-To: References: <555E14BC.2040805@lcwb.coop>, <555E203E.4040203@elstel.org> <0A1CDD8C-EEB5-40E2-A38B-28E8EEA8C37E@elstel.org> Message-ID: <8A3AB2ED-C11E-4787-A7F8-C8F12157EAA5@elstel.org> Am 22.05.2015 um 12:16 schrieb dirk muysers: > >> What about the said platform dependencies you have discovered? > > Not me (I never seriously considered using it), but many people on the llvm > forums pointed to the fact. One example among > many: > > Does your C code ever use the 'long' type? If so, the LLVM IR will be > different depending on whether it's targeting linux-32 or linux-64. Do > you ever use size_t? Same problem. Do you ever use a union containing > both pointers and integers? See above. In principle, it's possible to > write platform-independent IR, or even C code that compiles to > platform-independent IR. In practice, especially if you include any > system headers, it's remarkably hard. > (Jeffrey Yasskin jyasskin at google.com) Concerning me I am a very conscientious programmer when it comes to make a difference between long, long long and int. I only use long if my code requires a data item to be exactly as large as a pointer (in special cases also when it comes to tap the power of 64bit machines, f.i. that might be either 32/64bit as a base type for arbitrary length integers; however not without taking special provisions that will tackle the difference in data size. ). Usually aligning the pointers for the next structure at the beginning would also solve such an issue when it comes to reuse existing code where data sizes may not be changed from long either to int or long long without special consideration. Those who use glib f.i. additionally have a g[u]int32/64 which they can use instead of int / long long though that should at last never make a difference for Intel x86 based systems. So when it comes to use int or long long I mostly rely on them being either 32 or 64bit. I know that most programmers do not care and just always use long which I consider to be a particularly bad practice. Even in the Linux kernel they have declared "typedef long time_t" instead of "typedef long long time_t" which will create an Y2K mess all over in 2038 for all 32bit machines still in use then. A somehow bad decision which needs to be changed sooner or later even without llvm. Now let us think of Modula-3. I believe we had a long type for cm3 the last time I have seen it. However an equivalent to long long which does also exist on 32bit platforms would be an absolute requirement to not break things for llvm! Many Thanks for notifying us about this issue, Dirk. As far as I can see a Modula-3 programmer will need a good core for portable programming anyway as we did not even uphold a guarantee for WIDECHAR to be either 16 or 32bit. > > And then, besides the IR proper, there is that steadily increasing > legion of intrinsics. > > Unless you translate C-like code and build upon the existing technical > LLVM heritage, je vous souhaite bien du plaisir as the French say... > > From: Elmar Stellnberger > Sent: Friday, May 22, 2015 11:49 AM > To: dirk muysers > Subject: Re: [M3devel] How to integrate llvm into cm3 > > > Am 22.05.2015 um 10:48 schrieb dirk muysers: > >> Personally I have a strong dislike towards LLVM. >> 1. You first have to compile the whole tool chain. >> 2. It is a monstrous blob of code, mainly on Windows. >> 3. Contrary to a widespread belief, It is definitely NOT platform independent. >> 4. It changes at every release. >> 5. Having built your objects, you still have to run them through a platform assembler-linker. >> > > Is it really that bad? What about the said platform dependencies you have discovered? > I believe llvm could be beneficial in deed when it comes to debugging and/or analyzing Modula-3 programs, > as there are tools like SAFECode and to my knowledge we never had a fully featured m3gdb. > Besides this I would hardly like to believe that llvm is still that volatile when it comes to changes. > I know it had some issues in its first days but I can hardly believe that qt5 on MacOS would rely on clang/llvm > if that were not a ready to use technology nowadays. I would hope the main changes to llvm had already > been done when Apple started to adopt llvm for its own needs. > Concerning the code size of llvm that should not be a problem as long as it remains a separate module > compiling into an own executable or a shared library loaded in addition to other backends at runtime. > > >> If I still had the energy of my younger years I would try to pack the platform >> dependent part of the libraries into a dynamic load library together with a JIT >> translator (e.g. libjit) for the portable application code and have a single byte-code >> producing compiler backend. >> >> From: Jay K >> Sent: Friday, May 22, 2015 2:57 AM >> To: Elmar Stellnberger ; rodney.m.bates at acm.org ; m3devel >> Subject: Re: [M3devel] How to integrate llvm into cm3 >> >> Imho "all" options should be implemented, for purposes of convenient debugging/development of the backends. >> >> >> "external" is good for developing backends. You can "snapshot" the state of things >> slightly into the pipeline and then just iterate on later parts. >> >> >> At the cost of having all the serialization code. >> >> >> "integrated" is usually preferable for performance, for users. >> >> >> E.g. NTx86 backend has been sitting in there for decades unused by half the users. >> >> >> Having extra backends sitting in there unused is ok. >> Ideally, agreed, they'd be .dll/.sos if we can construct it that way, but ok either way imho. >> Ideally also cm3 would dynamically link to libm3/m3core, but it doesn't. >> >> >> Everything is demand paged so there is cost to distribute over the network >> and copy around, but at runtime, the pages just sit mostly cold on disk. >> >> >> One difficulty though is the need to have and build the LLVM code. >> For that reason, delayload-dynamically-linked might be preferable. >> It depends on how small/easy-to-build LLVM is. >> >> >> I guess LLVM provides more choices than before. >> In order of efficiency and inverse order of debuggability: >> 1 We could construct LLVM IR in memory and run LLVM in-proc and write .o. >> 2 We could write out LLVM bytes and run an executable. >> 3 We could write out LLVM text and run an executable. >> >> >> > My personal preference would be to only have one default target statically compiled in >> >> It has never worked that away. Granted, we didn't really have backends before, just writing mainly IR. >> And I don't think LLVM works that way, does it? >> >> I like one compiler to have all targets and just select with a command line switch. >> >> I don't like how hard it is to acquire various cross-toolschains. >> Granted, we cheat and are incomplete -- you still need the next piece of the pipeline, >> be it LLVM or m3cc (which has one target), or a C compiler or assembler or linker or "libc.a". >> >> >> binutils at least has this "all" notion reasonably well working now I believe. >> >> >> >> There are tradeoffs though. If only one backend has a bug, and they are all statically linked together, you have to update them all. >> And the largely wasted bloat. >> >> >> Ultimately really, I'd like the C backend to output portable C and then just one C backend, one distribution .tar.gz for all targets. >> There is work to do there..not easy..and no progress lately. >> Things like INTEGER preserving flexibility in the output, and using sizeof(INTEGER) in expressions instead of using 4 or 8 and folding... >> >> >> >> - Jay >> >> >> >> >> > Date: Thu, 21 May 2015 20:13:18 +0200 >> > From: estellnb at elstel.org >> > To: rodney.m.bates at acm.org; m3devel at elegosoft.com >> > Subject: Re: [M3devel] How to integrate llvm into cm3 >> > >> > Am 21.05.15 um 19:24 schrieb Rodney M. Bates: >> > > >> > > There are pros and cons. Integrating Peter's cm3-to-llvm conversion into >> > > the cm3 executable would be faster compiling--one fewer time per >> > > interface >> > > or module for the OS to create a process and run an executable. But it >> > > would also entail linking in this code, along with some of llvm's >> > > infrastructure, >> > > into cm3, making its executable bigger, with code that might not be >> > > executed >> > > at all, when a different backend is used. We already have the x86 >> > > integrated >> > > backend and the C backend linked in to cm3, whether used or not. >> > > >> > > Anybody have thoughts on this? I suppose it could be set up to be fairly >> > > easily changed either way too. >> > > >> > >> > Why not put each backend into a shared library and load it dynamically? >> > Are there still problems with shared libraries for some build targets? >> > On the other hand having cm3-IR handy and being able to translate >> > cm3-IR by an executable like m3cc into any desired target has proven >> > to be very handy for debugging as well as chocking the Modula-3 >> > compiler on a new platform. >> > My personal preference would be to only have one default target >> > statically compiled in namely that on for cm3-IR and load all other >> > targets by a shared libarary dynamically. If that should fail for some >> > reason one can still use m3cc or one of its counterparts to >> > accomplish the translation process. >> > >> > Elmar >> > >> > >> > >> > >> > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From estellnb at elstel.org Fri May 22 12:58:56 2015 From: estellnb at elstel.org (Elmar Stellnberger) Date: Fri, 22 May 2015 12:58:56 +0200 Subject: [M3devel] How to integrate llvm into cm3 In-Reply-To: References: <555E14BC.2040805@lcwb.coop>, <555E203E.4040203@elstel.org> <0A1CDD8C-EEB5-40E2-A38B-28E8EEA8C37E@elstel.org> Message-ID: <7E7A129A-7EAB-4424-98BD-D2D1900CF0AB@elstel.org> > (Jeffrey Yasskin jyasskin at google.com) > > And then, besides the IR proper, there is that steadily increasing > legion of intrinsics. Dirk, what can you tell us about intrinsics? Do they have a sufficient abstraction level for LLVM or do they really expose hidden language dependencies? -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Fri May 22 13:06:00 2015 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri, 22 May 2015 13:06:00 +0200 (CEST) Subject: [M3devel] How to integrate llvm into cm3 In-Reply-To: References: <555E14BC.2040805@lcwb.coop>, <555E203E.4040203@elstel.org> <0A1CDD8C-EEB5-40E2-A38B-28E8EEA8C37E@elstel.org> Message-ID: On Fri, 22 May 2015, dirk muysers wrote: > >> What about the said platform dependencies you have discovered? > Not me (I never seriously considered using it), but many people on the > llvm forums pointed to the fact. One example among many: Why should the LLVM IR be platform independent? Like object files, the ll bitcode files are platform dependent. Of course, there must be a way to address processor specific instructions. Intrinsics are used for that purpose. If you want processor specific optimizations, then LL cannot be platform independent. From estellnb at elstel.org Fri May 22 14:26:28 2015 From: estellnb at elstel.org (Elmar Stellnberger) Date: Fri, 22 May 2015 14:26:28 +0200 Subject: [M3devel] How to integrate llvm into cm3 In-Reply-To: References: <555E14BC.2040805@lcwb.coop>, <555E203E.4040203@elstel.org> <0A1CDD8C-EEB5-40E2-A38B-28E8EEA8C37E@elstel.org> Message-ID: <94C9A717-B0EA-4257-A728-C926FC8A4FEB@elstel.org> Am 22.05.2015 um 13:06 schrieb Henning Thielemann: > > > On Fri, 22 May 2015, dirk muysers wrote: > >> >> What about the said platform dependencies you have discovered? > >> Not me (I never seriously considered using it), but many people on the llvm forums pointed to the fact. One example among many: > > Why should the LLVM IR be platform independent? Like object files, the ll bitcode files are platform dependent. Of course, there must be a way to address processor specific instructions. Intrinsics are used for that purpose. If you want processor specific optimizations, then LL cannot be platform independent. > You are right; not an issue of llvm though someone who is used to Java or C#/.net bytecode would not expect such a 'feature'. Am 22.05.2015 um 12:53 schrieb Elmar Stellnberger: > Now let us think of Modula-3. I believe we had a long type for cm3 the last > time I have seen it. However an equivalent to long long which does also > exist on 32bit platforms would be an absolute requirement to not break > things for llvm! Many Thanks for notifying us about this issue, Dirk. > > As far as I can see a Modula-3 programmer will need a good core for > portable programming anyway as we did not even uphold a guarantee for > WIDECHAR to be either 16 or 32bit. > > Nonetheless we actually need to demand the necessary precautions from Modula-3 for platform independent programming. Having a type (1) which is at least 64bit long (why not also 128bit) for numeric purposes (at best also available on 32bit platforms) (2) a type which is exactly as long as a pointer (f.i. for subtracting two pointers) (3) the regular INTEGER defined to be at most 32bit in order to avoid an overkill in memory consumption and computing power Anyone here who can tell me about the current state of LONGINT support for cm3? As far as I can remember we had a LONGINT but only on 64bit machines. For portable programming we will at least need types for (2) and (3). (1) would be an additional plus. So writing code which will execute seamlessly either in a 32bit or 64bit environment as I have frequently tested it and done in the last eight years should at least become possible with Modula-3. It needs to be doable when using gcc as well as llvm though the 'advantages' are more obvious when it comes to arch-all llvm bytecode. From rodney_bates at lcwb.coop Fri May 22 18:15:06 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Fri, 22 May 2015 11:15:06 -0500 Subject: [M3devel] How to integrate llvm into cm3 In-Reply-To: References: <555E14BC.2040805@lcwb.coop>, <555E203E.4040203@elstel.org> Message-ID: <555F560A.4010506@lcwb.coop> On 05/21/2015 07:57 PM, Jay K wrote: > Imho "all" options should be implemented, for purposes of convenient debugging/development of the backends. > Yes, I like that idea. We should be able to do it without a huge coding burden. > > "external" is good for developing backends. You can "snapshot" the state of things > slightly into the pipeline and then just iterate on later parts. > Yes. > > At the cost of having all the serialization code. > Yes, although it is already there now, for cm3-IR. It exists in llvm for llvm-IR, but has to be linked in. > > "integrated" is usually preferable for performance, for users. > Yes > > E.g. NTx86 backend has been sitting in there for decades unused by half the users. > > > Having extra backends sitting in there unused is ok. > Ideally, agreed, they'd be .dll/.sos if we can construct it that way, but ok either way imho. Thank you. > Ideally also cm3 would dynamically link to libm3/m3core, but it doesn't. > > > Everything is demand paged so there is cost to distribute over the network > and copy around, but at runtime, the pages just sit mostly cold on disk. > Hadn't thought of that. It pretty well addresses my concerns about how much to link in. We can just be extravagant and let the paging take care of it. > > One difficulty though is the need to have and build the LLVM code. > For that reason, delayload-dynamically-linked might be preferable. > It depends on how small/easy-to-build LLVM is. > All of llvm is huge and takes a long time to build. Both Peter and I are currently following the approach of linking in only a subset of llvm, containing code to build its internal trees and serialize them. I haven't checked actual sizes of compiled code, but in library count, it's perhaps 1/4 or so. Of course, you still need the rest for the separate executable that optimizes/codegens. > > I guess LLVM provides more choices than before. > In order of efficiency and inverse order of debuggability: > 1 We could construct LLVM IR in memory and run LLVM in-proc and write .o. > 2 We could write out LLVM bytes and run an executable. > 3 We could write out LLVM text and run an executable. > > One consideration is that there is a *lot* of command-line processing, etc. in driving llvm opt/codegen. llc, a separate executable which comes as part of llvm already provides this. Doing 1 above would require duplicating this, or maybe ripping out the C++ code and somehow repackaging it. We would still have to pass all these options through cm3. The way I have Builder working now, what of this stuff that is handled, comes from Quake code, etc. bypasses cm3 and gets passed in to llc. > > My personal preference would be to only have one default target statically compiled in > > It has never worked that away. Granted, we didn't really have backends before, just writing mainly IR. > And I don't think LLVM works that way, does it? > > I like one compiler to have all targets and just select with a command line switch. > > I don't like how hard it is to acquire various cross-toolschains. > Granted, we cheat and are incomplete -- you still need the next piece of the pipeline, > be it LLVM or m3cc (which has one target), or a C compiler or assembler or linker or "libc.a". > > > binutils at least has this "all" notion reasonably well working now I believe. > > > > There are tradeoffs though. If only one backend has a bug, and they are all statically linked together, you have to update them all. > And the largely wasted bloat. > > > Ultimately really, I'd like the C backend to output portable C and then just one C backend, one distribution .tar.gz for all targets. > There is work to do there..not easy..and no progress lately. > Things like INTEGER preserving flexibility in the output, and using sizeof(INTEGER) in expressions instead of using 4 or 8 and folding... > > > > - Jay > > > > > > Date: Thu, 21 May 2015 20:13:18 +0200 > > From: estellnb at elstel.org > > To: rodney.m.bates at acm.org; m3devel at elegosoft.com > > Subject: Re: [M3devel] How to integrate llvm into cm3 > > > > Am 21.05.15 um 19:24 schrieb Rodney M. Bates: > > > > > > There are pros and cons. Integrating Peter's cm3-to-llvm conversion into > > > the cm3 executable would be faster compiling--one fewer time per > > > interface > > > or module for the OS to create a process and run an executable. But it > > > would also entail linking in this code, along with some of llvm's > > > infrastructure, > > > into cm3, making its executable bigger, with code that might not be > > > executed > > > at all, when a different backend is used. We already have the x86 > > > integrated > > > backend and the C backend linked in to cm3, whether used or not. > > > > > > Anybody have thoughts on this? I suppose it could be set up to be fairly > > > easily changed either way too. > > > > > > > Why not put each backend into a shared library and load it dynamically? > > Are there still problems with shared libraries for some build targets? > > On the other hand having cm3-IR handy and being able to translate > > cm3-IR by an executable like m3cc into any desired target has proven > > to be very handy for debugging as well as chocking the Modula-3 > > compiler on a new platform. > > My personal preference would be to only have one default target > > statically compiled in namely that on for cm3-IR and load all other > > targets by a shared libarary dynamically. If that should fail for some > > reason one can still use m3cc or one of its counterparts to > > accomplish the translation process. > > > > Elmar > > > > > > > > > > > > -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Fri May 22 18:59:15 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Fri, 22 May 2015 11:59:15 -0500 Subject: [M3devel] LLVM version and patches thereto In-Reply-To: References: <555E0E63.6070506@lcwb.coop> Message-ID: <555F6063.2000204@lcwb.coop> On 05/21/2015 05:09 PM, Peter McKinna wrote: > Hi Rodney, > > Good to see this stuff moving forward. I had no idea how to integrate it with the front end. I'm using llvm 3.5 . I downloaded 3.6 and built it but then could not get some dibuilder bindings I had added to compile, some sort of problem with the wrap function which I have yet to sort out. I think they made a change to the way metadata is treated. Anyway I have attached the 2 sets of bindings I have been using. I have to commit a few bug fixes and my initial attempt at debug support. I have been using llvm 3.4.2, which was the current release when I first started thinking about this. I want to avoid overlapping heavy development, while simultaneously constantly reworking what's already done to new versions. However, I am well past due to update to as late a version as reasonable. They have made a couple of changes that I know will be relevant. (I've been monitoring their mailing list--very high traffic.) One is the metadata class is no longer a subclass of Value, with various implications to the IR. Another is that there is only one pointer type. It no longer gives its referent type. We (Peter and I) have duplicated on DIBuilder bindings. Yours is tidier looking, but mine is pretty much complete. I will undertake merging them and adapting to latest llvm. I had some real nightmares getting wrap and unwrap unravelled, and will probably have to do some of that again. IMO, this is, by far, the most extreme specific example I have ever seen for why user-defined overloading is disastrous idea. There are a bazillion overloads of wrap and unwrap, whose declarations are scattered all over the universe. Figuring out which one you got, or, in case none was found, where the one you wanted is horrible. It's further complicated by the fact that there are various user-defined implicit conversions that the compiler can insert with no syntactic clue in the call you are trying to decrypt. These are just as spread out, maybe more. And have you ever tried to construct a transitive #include closure in something as big as llvm? > Speaking of debugging, I was following what I think clang uses which is the dibuilder class . So far its very primitive and could probably be split into its own module. I managed to get simple scalars, enumerations, arrays and records to be debugged with stock gdb and none of the name mangling I usually get. But globals, objects and sets dont work. I think this needs an expert and mybe a chat with the llvm people, they seem pretty helpful. > Anyway it runs the maze program, I compiled the collector the other day, 15,000 lines of llvm ir. The code quality looks pretty good from a brief inspection of the assembly thats compiled at O3 although O2 doesnt make much difference. I read in tips for programmers somewhere that pascal like languages with lots of runtime checks should be running some extra passes for better optimisation. We could look at that in the future. > > Regards Peter > > On Fri, May 22, 2015 at 2:57 AM, Rodney M. Bates > wrote: > > Peter, what version of llvm are you using? Also, can you tell us what the patches > you have made to it are? Have you sent these to the llvm developers to incorporate? > I can guess one is to tolerate DW_LANG_Modula3. > > > -- > Rodney Bates > rodney.m.bates at acm.org > > -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Fri May 22 19:20:17 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Fri, 22 May 2015 12:20:17 -0500 Subject: [M3devel] How to integrate llvm into cm3 In-Reply-To: References: <555E14BC.2040805@lcwb.coop>, <555E203E.4040203@elstel.org> Message-ID: <555F6551.3000300@lcwb.coop> On 05/22/2015 03:48 AM, dirk muysers wrote: > Personally I have a strong dislike towards LLVM. > 1. You first have to compile the whole tool chain. > 2. It is a monstrous blob of code, mainly on Windows. > 3. Contrary to a widespread belief, It is definitely NOT platform independent. > 4. It changes at every release. > 5. Having built your objects, you still have to run them through a platform assembler-linker. Having grubbed around in it a bit, I can't say I'm exactly ecstatic about llvm. However, its developers have at least adopted the intention of providing clear documentation. While the documentation has trapped/misled me in some areas, this is dramatically better than gcc, where, as I understand, there is intentional avoidance of documenting internal formats and data structures, as a way to make it difficult to work on for any but programmers who are both very skilled and have a lot of time to spend on it. Further, it appears gcc changes about as fast as llvm. > If I still had the energy of my younger years I would try to pack the platform > dependent part of the libraries into a dynamic load library together with a JIT > translator (e.g. libjit) for the portable application code and have a single byte-code > producing compiler backend. I don't think things like this are at all unrealistic, if we get a basic llvm backend developed. > *From:* Jay K > *Sent:* Friday, May 22, 2015 2:57 AM > *To:* Elmar Stellnberger ; rodney.m.bates at acm.org ; m3devel > *Subject:* Re: [M3devel] How to integrate llvm into cm3 > Imho "all" options should be implemented, for purposes of convenient debugging/development of the backends. > > "external" is good for developing backends. You can "snapshot" the state of things > slightly into the pipeline and then just iterate on later parts. > > At the cost of having all the serialization code. > > "integrated" is usually preferable for performance, for users. > > E.g. NTx86 backend has been sitting in there for decades unused by half the users. > > Having extra backends sitting in there unused is ok. > Ideally, agreed, they'd be .dll/.sos if we can construct it that way, but ok either way imho. > Ideally also cm3 would dynamically link to libm3/m3core, but it doesn't. > > Everything is demand paged so there is cost to distribute over the network > and copy around, but at runtime, the pages just sit mostly cold on disk. > > One difficulty though is the need to have and build the LLVM code. > For that reason, delayload-dynamically-linked might be preferable. > It depends on how small/easy-to-build LLVM is. > > I guess LLVM provides more choices than before. > In order of efficiency and inverse order of debuggability: > 1 We could construct LLVM IR in memory and run LLVM in-proc and write .o. > 2 We could write out LLVM bytes and run an executable. > 3 We could write out LLVM text and run an executable. > > > My personal preference would be to only have one default target statically compiled in > It has never worked that away. Granted, we didn't really have backends before, just writing mainly IR. > And I don't think LLVM works that way, does it? > I like one compiler to have all targets and just select with a command line switch. > I don't like how hard it is to acquire various cross-toolschains. > Granted, we cheat and are incomplete -- you still need the next piece of the pipeline, > be it LLVM or m3cc (which has one target), or a C compiler or assembler or linker or "libc.a". > > binutils at least has this "all" notion reasonably well working now I believe. > There are tradeoffs though. If only one backend has a bug, and they are all statically linked together, you have to update them all. > And the largely wasted bloat. > Ultimately really, I'd like the C backend to output portable C and then just one C backend, one distribution .tar.gz for all targets. > There is work to do there..not easy..and no progress lately. > Things like INTEGER preserving flexibility in the output, and using sizeof(INTEGER) in expressions instead of using 4 or 8 and folding... > > - Jay > > > > > > Date: Thu, 21 May 2015 20:13:18 +0200 > > From: estellnb at elstel.org > > To: rodney.m.bates at acm.org; m3devel at elegosoft.com > > Subject: Re: [M3devel] How to integrate llvm into cm3 > > > > Am 21.05.15 um 19:24 schrieb Rodney M. Bates: > > > > > > There are pros and cons. Integrating Peter's cm3-to-llvm conversion into > > > the cm3 executable would be faster compiling--one fewer time per > > > interface > > > or module for the OS to create a process and run an executable. But it > > > would also entail linking in this code, along with some of llvm's > > > infrastructure, > > > into cm3, making its executable bigger, with code that might not be > > > executed > > > at all, when a different backend is used. We already have the x86 > > > integrated > > > backend and the C backend linked in to cm3, whether used or not. > > > > > > Anybody have thoughts on this? I suppose it could be set up to be fairly > > > easily changed either way too. > > > > > > > Why not put each backend into a shared library and load it dynamically? > > Are there still problems with shared libraries for some build targets? > > On the other hand having cm3-IR handy and being able to translate > > cm3-IR by an executable like m3cc into any desired target has proven > > to be very handy for debugging as well as chocking the Modula-3 > > compiler on a new platform. > > My personal preference would be to only have one default target > > statically compiled in namely that on for cm3-IR and load all other > > targets by a shared libarary dynamically. If that should fail for some > > reason one can still use m3cc or one of its counterparts to > > accomplish the translation process. > > > > Elmar > > > > > > > > > > > > -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Fri May 22 19:55:27 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Fri, 22 May 2015 12:55:27 -0500 Subject: [M3devel] How to integrate llvm into cm3 In-Reply-To: <8A3AB2ED-C11E-4787-A7F8-C8F12157EAA5@elstel.org> References: <555E14BC.2040805@lcwb.coop>, <555E203E.4040203@elstel.org> <0A1CDD8C-EEB5-40E2-A38B-28E8EEA8C37E@elstel.org> <8A3AB2ED-C11E-4787-A7F8-C8F12157EAA5@elstel.org> Message-ID: <555F6D8F.4070109@lcwb.coop> This is a worthwhile discussion, but it has very little to do with using llvm as a back end. In the llvm-IR, sizes of integers, pointers, etc. are constant numbers. The frontend, whether Clang, CM3, or any other, makes the decisions about mapping language types like long, INTEGER, pointers, etc. to a size, target-dependently or otherwise, according to the language's rules. LLvm does not make these decisions. Its target dependencies are mostly in the line of different code generators for different instruction sets. On 05/22/2015 05:53 AM, Elmar Stellnberger wrote: > > Am 22.05.2015 um 12:16 schrieb dirk muysers: > >> >> What about the said platform dependencies you have discovered? >> Not me (I never seriously considered using it), but many people on the llvm >> forums pointed to the fact. One example among >> many: >> >> Does your C code ever use the 'long' type? If so, the LLVM IR will be >> different depending on whether it's targeting linux-32 or linux-64. Do >> you ever use size_t? Same problem. Do you ever use a union containing >> both pointers and integers? See above. In principle, it's possible to >> write platform-independent IR, or even C code that compiles to >> platform-independent IR. In practice, especially if you include any >> system headers, it's remarkably hard. >> (Jeffrey Yasskin jyasskin at google.com) > > Concerning me I am a very conscientious programmer when it comes to > make a difference between long, long long and int. I only use long if my > code requires a data item to be exactly as large as a pointer (in special > cases also when it comes to tap the power of 64bit machines, f.i. that > might be either 32/64bit as a base type for arbitrary length integers; > however not without taking special provisions that will tackle the > difference in data size. ). Usually aligning the pointers for the next > structure at the beginning would also solve such an issue when it comes > to reuse existing code where data sizes may not be changed from long > either to int or long long without special consideration. Those who use > glib f.i. additionally have a g[u]int32/64 which they can use instead of int > / long long though that should at last never make a difference for Intel x86 > based systems. So when it comes to use int or long long I mostly rely > on them being either 32 or 64bit. > I know that most programmers do not care and just always use long which > I consider to be a particularly bad practice. Even in the Linux kernel they > have declared "typedef long time_t" instead of "typedef long long time_t" > which will create an Y2K mess all over in 2038 for all 32bit machines still > in use then. A somehow bad decision which needs to be changed sooner > or later even without llvm. > > Now let us think of Modula-3. I believe we had a long type for cm3 the last > time I have seen it. However an equivalent to long long which does also > exist on 32bit platforms would be an absolute requirement to not break > things for llvm! Many Thanks for notifying us about this issue, Dirk. > Whether types like integer have a language-specified or target-dependent range is a tough language design question. I have tended to favor a fixed, language-specified range, but there are pros and cons. I do think all the time about end-of-range cases and native word size dependencies. It takes a great deal of care, and I know of no way to design a language that doesn't, to some extent, trade one set of problems for another. Signed/unsigned creates similar language dilemmas. > As far as I can see a Modula-3 programmer will need a good core for > portable programming anyway as we did not even uphold a guarantee for > WIDECHAR to be either 16 or 32bit. > The evolving nature of first UCS and then Unicode standards has left many language designers knocked off balance. Critical Mass first introduced WIDECHAR as 16-bit when that was what everybody thought was enough. Then things changed, and it wasn't anymore. Right now, it's a configuration parameter (must be the same for the entire link closure) in Modula-3. I personally favor making it full Unicode by default, in the next release, as this is where the world is now. This is hopefully a simpler problem than INTEGER, etc., because, as of now, the Unicode committee has emphatically assured us that the range will *never* increase. We can hope. > > > > >> And then, besides the IR proper, there is that steadily increasing >> legion of intrinsics. >> Unless you translate C-like code and build upon the existing technical >> LLVM heritage, /je vous souhaite bien du plaisir/ as the French say... >> ** >> *From:* Elmar Stellnberger >> *Sent:* Friday, May 22, 2015 11:49 AM >> *To:* dirk muysers >> *Subject:* Re: [M3devel] How to integrate llvm into cm3 >> Am 22.05.2015 um 10:48 schrieb dirk muysers: >> >>> Personally I have a strong dislike towards LLVM. >>> 1. You first have to compile the whole tool chain. >>> 2. It is a monstrous blob of code, mainly on Windows. >>> 3. Contrary to a widespread belief, It is definitely NOT platform independent. >>> 4. It changes at every release. >>> 5. Having built your objects, you still have to run them through a platform assembler-linker. >> Is it really that bad? What about the said platform dependencies you have discovered? >> I believe llvm could be beneficial in deed when it comes to debugging and/or analyzing Modula-3 programs, >> as there are tools like SAFECode and to my knowledge we never had a fully featured m3gdb. >> Besides this I would hardly like to believe that llvm is still that volatile when it comes to changes. >> I know it had some issues in its first days but I can hardly believe that qt5 on MacOS would rely on clang/llvm >> if that were not a ready to use technology nowadays. I would hope the main changes to llvm had already >> been done when Apple started to adopt llvm for its own needs. >> Concerning the code size of llvm that should not be a problem as long as it remains a separate module >> compiling into an own executable or a shared library loaded in addition to other backends at runtime. >> >>> If I still had the energy of my younger years I would try to pack the platform >>> dependent part of the libraries into a dynamic load library together with a JIT >>> translator (e.g. libjit) for the portable application code and have a single byte-code >>> producing compiler backend. >>> *From:*Jay K >>> *Sent:*Friday, May 22, 2015 2:57 AM >>> *To:*Elmar Stellnberger ;rodney.m.bates at acm.org ;m3devel >>> *Subject:*Re: [M3devel] How to integrate llvm into cm3 >>> Imho "all" options should be implemented, for purposes of convenient debugging/development of the backends. >>> >>> "external" is good for developing backends. You can "snapshot" the state of things >>> slightly into the pipeline and then just iterate on later parts. >>> >>> At the cost of having all the serialization code. >>> >>> "integrated" is usually preferable for performance, for users. >>> >>> E.g. NTx86 backend has been sitting in there for decades unused by half the users. >>> >>> Having extra backends sitting in there unused is ok. >>> Ideally, agreed, they'd be .dll/.sos if we can construct it that way, but ok either way imho. >>> Ideally also cm3 would dynamically link to libm3/m3core, but it doesn't. >>> >>> Everything is demand paged so there is cost to distribute over the network >>> and copy around, but at runtime, the pages just sit mostly cold on disk. >>> >>> One difficulty though is the need to have and build the LLVM code. >>> For that reason, delayload-dynamically-linked might be preferable. >>> It depends on how small/easy-to-build LLVM is. >>> >>> I guess LLVM provides more choices than before. >>> In order of efficiency and inverse order of debuggability: >>> 1 We could construct LLVM IR in memory and run LLVM in-proc and write .o. >>> 2 We could write out LLVM bytes and run an executable. >>> 3 We could write out LLVM text and run an executable. >>> >>> > My personal preference would be to only have one default targetstatically compiled in >>> It has never worked that away. Granted, we didn't really have backends before, just writing mainly IR. >>> And I don't think LLVM works that way, does it? >>> I like one compiler to have all targets and just select with a command line switch. >>> I don't like how hard it is to acquire various cross-toolschains. >>> Granted, we cheat and are incomplete -- you still need the next piece of the pipeline, >>> be it LLVM or m3cc (which has one target), or a C compiler or assembler or linker or "libc.a". >>> >>> binutils at least has this "all" notion reasonably well working now I believe. >>> There are tradeoffs though. If only one backend has a bug, and they are all statically linked together, you have to update them all. >>> And the largely wasted bloat. >>> Ultimately really, I'd like the C backend to output portable C and then just one C backend, one distribution .tar.gz for all targets. >>> There is work to do there..not easy..and no progress lately. >>> Things like INTEGER preserving flexibility in the output, and using sizeof(INTEGER) in expressions instead of using 4 or 8 and folding... >>> >>> - Jay >>> >>> >>> >>> >>> > Date: Thu, 21 May 2015 20:13:18 +0200 >>> > From:estellnb at elstel.org >>> > To:rodney.m.bates at acm.org ; m3devel at elegosoft.com >>> > Subject:Re: [M3devel] How to integrate llvm into cm3 >>> > >>> > Am 21.05.15 um 19:24 schriebRodney M. Bates: >>> > > >>> > > There are pros and cons.Integrating Peter's cm3-to-llvm conversion into >>> > > the cm3executable would be faster compiling--one fewer time per >>> > > interface >>> > >or module for the OS to create a process and run an executable. But it >>> >> would also entail linking in this code, along with some of llvm's >>> > > infrastructure, >>> >> into cm3, making its executable bigger, with code that might not be >>> > > executed >>> > >at all, when a different backend is used. We already have the x86 >>> > > integrated >>> > >backend and the C backend linked in to cm3, whether used or not. >>> >> >>> > > Anybody have thoughts on this? I suppose it could be set upto be fairly >>> > > easily changed either way too. >>> >> >>> > >>> > Why notput each backend into a shared library and load it dynamically? >>> > Arethere still problems with shared libraries for some build targets? >>> > Onthe other hand having cm3-IR handy and being able to translate >>> > cm3-IRby an executable like m3cc into any desired target has proven >>> > to bevery handy for debugging as well as chocking the Modula-3 >>> > compiler ona new platform. >>> > My personal preference would be to only have onedefault target >>> > statically compiled in namely that on for cm3-IR andload all other >>> > targets by a shared libarary dynamically. If thatshould fail for some >>> > reason one can still use m3cc or one of itscounterparts to >>> > accomplish the translation process. >>> > >>> > Elmar >>> > >>> > >>> > >>> > >>> > >>> > > -- Rodney Bates rodney.m.bates at acm.org From jay.krell at cornell.edu Sat May 23 03:58:43 2015 From: jay.krell at cornell.edu (Jay) Date: Fri, 22 May 2015 18:58:43 -0700 Subject: [M3devel] How to integrate llvm into cm3 In-Reply-To: <94C9A717-B0EA-4257-A728-C926FC8A4FEB@elstel.org> References: <555E14BC.2040805@lcwb.coop> <555E203E.4040203@elstel.org> <0A1CDD8C-EEB5-40E2-A38B-28E8EEA8C37E@elstel.org> <94C9A717-B0EA-4257-A728-C926FC8A4FEB@elstel.org> Message-ID: <105678F8-0E9B-4CE8-84ED-93F88F73E5AD@gmail.com> We use things with varying levels of abstraction. & concrete details are filled in at varying stages. C "long" is NOT specified as having an exact size and does NOT necessarily hold a pointer, and this is ok. C99 is pretty complete, messy. For each of 8, 16, 32, 64, It gives "least", "fast", and "exact" types. And pointer sized. Signed and unsigned. 32 types! INTEGER is always pointer sized. LONGINT is on all platforms. C# has this feature too. IntPtr & UIntPtr. But C# is dubious -- array indexes are always 32 bit signed. - Jay On May 22, 2015, at 5:26 AM, Elmar Stellnberger wrote: > > Am 22.05.2015 um 13:06 schrieb Henning Thielemann: > >> >> >> On Fri, 22 May 2015, dirk muysers wrote: >> >>>>> What about the said platform dependencies you have discovered? >> >>> Not me (I never seriously considered using it), but many people on the llvm forums pointed to the fact. One example among many: >> >> Why should the LLVM IR be platform independent? Like object files, the ll bitcode files are platform dependent. Of course, there must be a way to address processor specific instructions. Intrinsics are used for that purpose. If you want processor specific optimizations, then LL cannot be platform independent. > > > You are right; not an issue of llvm though someone who is used to Java or C#/.net bytecode would not expect such a 'feature'. > > > Am 22.05.2015 um 12:53 schrieb Elmar Stellnberger: > >> Now let us think of Modula-3. I believe we had a long type for cm3 the last >> time I have seen it. However an equivalent to long long which does also >> exist on 32bit platforms would be an absolute requirement to not break >> things for llvm! Many Thanks for notifying us about this issue, Dirk. >> >> As far as I can see a Modula-3 programmer will need a good core for >> portable programming anyway as we did not even uphold a guarantee for >> WIDECHAR to be either 16 or 32bit. > > Nonetheless we actually need to demand the necessary precautions from Modula-3 for platform independent programming. > Having a type > > (1) which is at least 64bit long (why not also 128bit) for numeric purposes (at best also available on 32bit platforms) > (2) a type which is exactly as long as a pointer (f.i. for subtracting two pointers) > (3) the regular INTEGER defined to be at most 32bit in order to avoid an overkill in memory consumption and computing power > > Anyone here who can tell me about the current state of LONGINT support for cm3? > As far as I can remember we had a LONGINT but only on 64bit machines. > For portable programming we will at least need types for (2) and (3). > (1) would be an additional plus. > > So writing code which will execute seamlessly either in a 32bit or 64bit environment as I have frequently tested it and done in > the last eight years should at least become possible with Modula-3. It needs to be doable when using gcc as well as llvm though > the 'advantages' are more obvious when it comes to arch-all llvm bytecode. > From hendrik at topoi.pooq.com Sat May 23 11:41:51 2015 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Sat, 23 May 2015 05:41:51 -0400 Subject: [M3devel] How to integrate llvm into cm3 In-Reply-To: <555F560A.4010506@lcwb.coop> References: <555E14BC.2040805@lcwb.coop> <555E203E.4040203@elstel.org> <555F560A.4010506@lcwb.coop> Message-ID: <20150523094151.GA16324@topoi.pooq.com> On Fri, May 22, 2015 at 11:15:06AM -0500, Rodney M. Bates wrote: > > >Ideally also cm3 would dynamically link to libm3/m3core, but it doesn't. > > > > > >Everything is demand paged so there is cost to distribute over the network > >and copy around, but at runtime, the pages just sit mostly cold on disk. > > > > Hadn't thought of that. It pretty well addresses my concerns about how much > to link in. We can just be extravagant and let the paging take care of it. Doesn't the executable have to be copied from the binary file to paged memory in order to run it? As far as I know, it's possible to replace the file being executed once execution has begun and it will just continue running. If this is true, the size of the llvm library might indicate it's best to load it dynaically from a shared library if and when needed. -- hendrik > > > > >One difficulty though is the need to have and build the LLVM code. > >For that reason, delayload-dynamically-linked might be preferable. > >It depends on how small/easy-to-build LLVM is. in Linux, one can presumably rely on the distribution to provide the llvm library. -- hendrik From estellnb at elstel.org Wed May 27 17:20:35 2015 From: estellnb at elstel.org (Elmar Stellnberger) Date: Wed, 27 May 2015 17:20:35 +0200 Subject: [M3devel] 64bit INTEGERs, WIDECHAR: language specified or configuration/target dependent? In-Reply-To: <555F6D8F.4070109@lcwb.coop> References: <555E14BC.2040805@lcwb.coop>, <555E203E.4040203@elstel.org> <0A1CDD8C-EEB5-40E2-A38B-28E8EEA8C37E@elstel.org> <8A3AB2ED-C11E-4787-A7F8-C8F12157EAA5@elstel.org> <555F6D8F.4070109@lcwb.coop> Message-ID: <6F9B9534-7DC2-4D4D-88CB-90D7FA05E8F9@elstel.org> > We use things with varying levels of abstraction. & concrete details are filled in at varying stages. C "long" is NOT specified as having an exact size and does NOT necessarily hold a pointer, and this is ok. > C99 is pretty complete, messy. > For each of 8, 16, 32, 64, > It gives "least", "fast", and "exact" types. And pointer sized. Signed and unsigned. 32 types! * long in C is not guaranteed to hold a pointer by the language definition Though not in the language definition (I believe the language definition of C is simply too old for anticipating all the developments from 8/16bit up to 64bit machines) this has evolved as a de facto standard at least on all x86 up to x86_64 targets as far as I know. Jay, do you know a single arch / target where sizeof(long) != sizeof(void*)? > > Whether types like integer have a language-specified or target-dependent > range is a tough language design question. I have tended to favor a > fixed, language-specified range, but there are pros and cons. I do > think all the time about end-of-range cases and native word size dependencies. > It takes a great deal of care, and I know of no way to design a language > that doesn't, to some extent, trade one set of problems for another. > Signed/unsigned creates similar language dilemmas. * language-specified or target-dependent As I have already suggested I believe there is some justification to have both kinds of type: a language dependent type and a target dependent one The advantages of a language dependent type are rather clear when it comes to mere INTEGERs for numeric/counting/calculation purposes. Once you have a fixed size you can rely on support of a certain value range. Use of the native word size on the other hand should yield better performance at least in the general case. If that question were "either - or" I would clearly favor language specified types. Rewriting certain parts of a program to gain more performance on a special arch is not as bad as a broken program. However if we look into the details at least of 8, 16, 32 and 64bit arches things need to be seen more differentiated: When extending the address range from 8 to 16 and from 16 to 32bit automatically extending the value ranges of integers was a known concern. 65536 (16bit) is not that a high value and we would even have liked to extend most array indices to 32bit as we gained something with the value range while using whole words was also somewhat faster. However things turned out to be very different when the extension from 32bit to 64bit was at stake. There was no more gain by automatically extending the value ranges from 2^32 to 2^64 for 95% of all application purposes while the memory hierarchy has increasingly become a bottle neck in recent time. Additionally doubling the size of all integers would initially have doubled our memory needs which would have been a potential drawback for introducing the AMD64 arch. Just think of a machine with 4GB of RAM: It can not be addressed by 32bit (only ~3GB can) while making all INTS 64bit would have shrunken our memory to an effective size of 2GB. Luckily the decision was taken differently this time: * keep all ints of at most 32bit and just extend pointers to 64bit Elmar P.S.: My next email will start a discussion for all these issues. Am 22.05.2015 um 19:55 schrieb Rodney M. Bates: > This is a worthwhile discussion, but it has very little to do with using > llvm as a back end. In the llvm-IR, sizes of integers, pointers, etc. > are constant numbers. The frontend, whether Clang, CM3, or any other, makes > the decisions about mapping language types like long, INTEGER, pointers, > etc. to a size, target-dependently or otherwise, according to the language's > rules. LLvm does not make these decisions. Its target dependencies are > mostly in the line of different code generators for different instruction sets. > > On 05/22/2015 05:53 AM, Elmar Stellnberger wrote: >> >> Am 22.05.2015 um 12:16 schrieb dirk muysers: >> >>> >> What about the said platform dependencies you have discovered? >>> Not me (I never seriously considered using it), but many people on the llvm >>> forums pointed to the fact. One example among >>> many: >>> >>> Does your C code ever use the 'long' type? If so, the LLVM IR will be >>> different depending on whether it's targeting linux-32 or linux-64. Do >>> you ever use size_t? Same problem. Do you ever use a union containing >>> both pointers and integers? See above. In principle, it's possible to >>> write platform-independent IR, or even C code that compiles to >>> platform-independent IR. In practice, especially if you include any >>> system headers, it's remarkably hard. >>> (Jeffrey Yasskin jyasskin at google.com) >> >> Concerning me I am a very conscientious programmer when it comes to >> make a difference between long, long long and int. I only use long if my >> code requires a data item to be exactly as large as a pointer (in special >> cases also when it comes to tap the power of 64bit machines, f.i. that >> might be either 32/64bit as a base type for arbitrary length integers; >> however not without taking special provisions that will tackle the >> difference in data size. ). Usually aligning the pointers for the next >> structure at the beginning would also solve such an issue when it comes >> to reuse existing code where data sizes may not be changed from long >> either to int or long long without special consideration. Those who use >> glib f.i. additionally have a g[u]int32/64 which they can use instead of int >> / long long though that should at last never make a difference for Intel x86 >> based systems. So when it comes to use int or long long I mostly rely >> on them being either 32 or 64bit. >> I know that most programmers do not care and just always use long which >> I consider to be a particularly bad practice. Even in the Linux kernel they >> have declared "typedef long time_t" instead of "typedef long long time_t" >> which will create an Y2K mess all over in 2038 for all 32bit machines still >> in use then. A somehow bad decision which needs to be changed sooner >> or later even without llvm. >> >> Now let us think of Modula-3. I believe we had a long type for cm3 the last >> time I have seen it. However an equivalent to long long which does also >> exist on 32bit platforms would be an absolute requirement to not break >> things for llvm! Many Thanks for notifying us about this issue, Dirk. >> > > Whether types like integer have a language-specified or target-dependent > range is a tough language design question. I have tended to favor a > fixed, language-specified range, but there are pros and cons. I do > think all the time about end-of-range cases and native word size dependencies. > It takes a great deal of care, and I know of no way to design a language > that doesn't, to some extent, trade one set of problems for another. > Signed/unsigned creates similar language dilemmas. > >> As far as I can see a Modula-3 programmer will need a good core for >> portable programming anyway as we did not even uphold a guarantee for >> WIDECHAR to be either 16 or 32bit. >> > > The evolving nature of first UCS and then Unicode standards has left > many language designers knocked off balance. Critical Mass first > introduced WIDECHAR as 16-bit when that was what everybody thought > was enough. Then things changed, and it wasn't anymore. Right now, > it's a configuration parameter (must be the same for the entire link > closure) in Modula-3. I personally favor making it full Unicode > by default, in the next release, as this is where the world is now. > This is hopefully a simpler problem than INTEGER, etc., because, as of > now, the Unicode committee has emphatically assured us that the range will > *never* increase. We can hope. Am 23.05.2015 um 03:58 schrieb Jay: > We use things with varying levels of abstraction. & concrete details are filled in at varying stages. C "long" is NOT specified as having an exact size and does NOT necessarily hold a pointer, and this is ok. > > > C99 is pretty complete, messy. > For each of 8, 16, 32, 64, > It gives "least", "fast", and "exact" types. And pointer sized. Signed and unsigned. 32 types! > > > INTEGER is always pointer sized. > LONGINT is on all platforms. > > > C# has this feature too. IntPtr & UIntPtr. But C# is dubious -- array indexes are always 32 bit signed. > > > - Jay From mika at async.caltech.edu Wed May 27 18:17:17 2015 From: mika at async.caltech.edu (mika at async.caltech.edu) Date: Wed, 27 May 2015 09:17:17 -0700 Subject: [M3devel] 64bit INTEGERs, WIDECHAR: language specified or configuration/target dependent? In-Reply-To: <6F9B9534-7DC2-4D4D-88CB-90D7FA05E8F9@elstel.org> References: <555E14BC.2040805@lcwb.coop>, <555E203E.4040203@elstel.org> <0A1CDD8C-EEB5-40E2-A38B-28E8EEA8C37E@elstel.org> <8A3AB2ED-C11E-4787-A7F8-C8F12157EAA5@elstel.org> <555F6D8F.4070109@lcwb.coop> <6F9B9534-7DC2-4D4D-88CB-90D7FA05E8F9@elstel.org> Message-ID: <20150527161717.83E761A2065@async.async.caltech.edu> ... >> Whether types like integer have a language-specified or = >target-dependent >> range is a tough language design question. I have tended to favor a >> fixed, language-specified range, but there are pros and cons. I do >> think all the time about end-of-range cases and native word size = >dependencies. >> It takes a great deal of care, and I know of no way to design a = >language >> that doesn't, to some extent, trade one set of problems for another. >> Signed/unsigned creates similar language dilemmas. > >* language-specified or target-dependent >As I have already suggested I believe there is some justification to = >have >both kinds of type: a language dependent type and a target dependent one > >The advantages of a language dependent type are rather clear when it >comes to mere INTEGERs for numeric/counting/calculation purposes. Once >you have a fixed size you can rely on support of a certain value range.=20= Hmm? Modula-3's INTEGERs are the "integers" of mathematics. The intent is that if your implementation is limited and doesn't support a particular operation because it goes out of range, your computation aborts. Same as any other implementation limitation. There is no reason I can think of you couldn't come up with an implementation that has unlimited-range integers. FIRST(INTEGER) and LAST(INTEGER) would have to be a little special. Mika From mika at async.caltech.edu Wed May 27 18:37:36 2015 From: mika at async.caltech.edu (mika at async.caltech.edu) Date: Wed, 27 May 2015 09:37:36 -0700 Subject: [M3devel] 64bit INTEGERs, WIDECHAR: language specified or configuration/target dependent? In-Reply-To: References: <555E14BC.2040805@lcwb.coop>, <555E203E.4040203@elstel.org> <0A1CDD8C-EEB5-40E2-A38B-28E8EEA8C37E@elstel.org> <8A3AB2ED-C11E-4787-A7F8-C8F12157EAA5@elstel.org> <555F6D8F.4070109@lcwb.coop> <6F9B9534-7DC2-4D4D-88CB-90D7FA05E8F9@elstel.org> <20150527161717.83E761A2065@async.async.caltech.edu> Message-ID: <20150527163736.B32DE1A2065@async.async.caltech.edu> Elmar Stellnberger writes: ... >I would have loved it to make INTEGER =3D BITS 32 FOR INTEGER and to = >allow >BITS 64 for INTEGER at the same time. However the way we have already = >gone is >to make LONGINT an own type with an own suffix like floats (the 'l' = >suffix). More >strictly typed and not so bad either.= Ah yes, LONGINT. I remain strongly opposed to that. I think it was a big mistake, it runs completely counter to Modula-3 design philosophy. INTEGERs are integers are integers are integers... fm: Command not found. Mika From estellnb at elstel.org Wed May 27 18:31:42 2015 From: estellnb at elstel.org (Elmar Stellnberger) Date: Wed, 27 May 2015 18:31:42 +0200 Subject: [M3devel] 64bit INTEGERs, WIDECHAR: language specified or configuration/target dependent? In-Reply-To: <20150527161717.83E761A2065@async.async.caltech.edu> References: <555E14BC.2040805@lcwb.coop>, <555E203E.4040203@elstel.org> <0A1CDD8C-EEB5-40E2-A38B-28E8EEA8C37E@elstel.org> <8A3AB2ED-C11E-4787-A7F8-C8F12157EAA5@elstel.org> <555F6D8F.4070109@lcwb.coop> <6F9B9534-7DC2-4D4D-88CB-90D7FA05E8F9@elstel.org> <20150527161717.83E761A2065@async.async.caltech.edu> Message-ID: Am 27.05.2015 um 18:17 schrieb mika at async.caltech.edu: > ... >>> Whether types like integer have a language-specified or = >> target-dependent >>> range is a tough language design question. I have tended to favor a >>> fixed, language-specified range, but there are pros and cons. I do >>> think all the time about end-of-range cases and native word size = >> dependencies. >>> It takes a great deal of care, and I know of no way to design a = >> language >>> that doesn't, to some extent, trade one set of problems for another. >>> Signed/unsigned creates similar language dilemmas. >> >> * language-specified or target-dependent >> As I have already suggested I believe there is some justification to = >> have >> both kinds of type: a language dependent type and a target dependent one >> >> The advantages of a language dependent type are rather clear when it >> comes to mere INTEGERs for numeric/counting/calculation purposes. Once >> you have a fixed size you can rely on support of a certain value range.=20= > > Hmm? > > Modula-3's INTEGERs are the "integers" of mathematics. The intent is > that if your implementation is limited and doesn't support a particular > operation because it goes out of range, your computation aborts. Same > as any other implementation limitation. > > There is no reason I can think of you couldn't come up with an implementation > that has unlimited-range integers. FIRST(INTEGER) and LAST(INTEGER) would have > to be a little special. > > Mika > I would have loved it to make INTEGER = BITS 32 FOR INTEGER and to allow BITS 64 for INTEGER at the same time. However the way we have already gone is to make LONGINT an own type with an own suffix like floats (the 'l' suffix). More strictly typed and not so bad either. From estellnb at elstel.org Wed May 27 18:32:20 2015 From: estellnb at elstel.org (Elmar Stellnberger) Date: Wed, 27 May 2015 18:32:20 +0200 Subject: [M3devel] 64bit INTEGERs, WIDECHAR: language specified or configuration/target dependent? In-Reply-To: <6F9B9534-7DC2-4D4D-88CB-90D7FA05E8F9@elstel.org> References: <555E14BC.2040805@lcwb.coop>, <555E203E.4040203@elstel.org> <0A1CDD8C-EEB5-40E2-A38B-28E8EEA8C37E@elstel.org> <8A3AB2ED-C11E-4787-A7F8-C8F12157EAA5@elstel.org> <555F6D8F.4070109@lcwb.coop> <6F9B9534-7DC2-4D4D-88CB-90D7FA05E8F9@elstel.org> Message-ID: <8BBBC94B-EECC-464A-86BB-FD1C94EC5496@elstel.org> Enough words about the history, now let us see how we can profit from both kinds of types when we wanna step on virgin soil: In what way we may ever turn things there actually needs to be a target sized type which is uses to be unsigned: the pointer. However there needs to be a way to do certain address calculations manually, apart from array indexing: multiply, add, subtract & evtl. shift. I would also believe that it would be handy to have such a type signed. i.e. offset = adress1 - adress2 Naturally such a type will profit from extending its value range to the bit size of pointers. Up to now converting everything to an int has sufficed. However it will no more for a 64bit arch. Will we need to convert to a LONGINT then? - but that will be in- compatible as LONGINT currently takes the 'l'-suffix and longint is not even supported for the 32bit arch as far as I know. Having an own type for this and other purposes like optimized numeric code would to my believe be beneficial. Call it OFFSET, TARGETINT, TargetInt.T or Offset.T Whether to just support such a type by a Word.T like interface or by a built-in type would likely be worth another discussion. So what for now? As I recall things we have introduced a LONGINT which takes the 0l - suffix for AMD64 only. The first thing would be to introduce a 64bit LONGINT for x86/32bit. and then? TYPE Offset.T = BITS BITSIZE(ADDRESS) FOR LONGINT ? We will have to rewrite some code that assumed offsets to be integers, then. The other possibility we have would be to make an offset a built-in type and assignment compatible to both int and longint which will save us from rewriting too much old code. I would claim this not to be a too big problem as converting back and forth between an OFFSET and an [LONG]INT should rarely happen. It would only be used in unsafe interfaces as all address arithmetics i.e. we should at least make that require an explicit conversion outside of unsafe interfaces. That way all expressions remained 100% compatible while only having to declare certain variables as OFFSET rather than INTEGER. > > Am 22.05.2015 um 19:55 schrieb Rodney M. Bates: >> The evolving nature of first UCS and then Unicode standards has left >> many language designers knocked off balance. Critical Mass first >> introduced WIDECHAR as 16-bit when that was what everybody thought >> was enough. Then things changed, and it wasn't anymore. Right now, >> it's a configuration parameter (must be the same for the entire link >> closure) in Modula-3. I personally favor making it full Unicode >> by default, in the next release, as this is where the world is now. >> This is hopefully a simpler problem than INTEGER, etc., because, as of >> now, the Unicode committee has emphatically assured us that the range will >> *never* increase. We can hope. By now I welcome your decision to make the WIDECHAR 32bit! I believe it should become the default for the upcoming release. Pure Modula-3 code will take advantage of the new value range. Just interfacing with certain external toolkits is not enough justification to freeze things as they are - interfaces need to be adapted anyway while supporting all three types is just too much unnecessary work. From hendrik at topoi.pooq.com Wed May 27 18:14:12 2015 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Wed, 27 May 2015 12:14:12 -0400 Subject: [M3devel] 64bit INTEGERs, WIDECHAR: language specified or configuration/target dependent? In-Reply-To: <20150527161717.83E761A2065@async.async.caltech.edu> References: <555E14BC.2040805@lcwb.coop> <555E203E.4040203@elstel.org> <0A1CDD8C-EEB5-40E2-A38B-28E8EEA8C37E@elstel.org> <8A3AB2ED-C11E-4787-A7F8-C8F12157EAA5@elstel.org> <555F6D8F.4070109@lcwb.coop> <6F9B9534-7DC2-4D4D-88CB-90D7FA05E8F9@elstel.org> <20150527161717.83E761A2065@async.async.caltech.edu> Message-ID: <20150527161412.GA18812@topoi.pooq.com> On Wed, May 27, 2015 at 09:17:17AM -0700, mika at async.caltech.edu wrote: > > Hmm? > > Modula-3's INTEGERs are the "integers" of mathematics. The intent is > that if your implementation is limited and doesn't support a particular > operation because it goes out of range, your computation aborts. Same > as any other implementation limitation. > > There is no reason I can think of you couldn't come up with an implementation > that has unlimited-range integers. FIRST(INTEGER) and LAST(INTEGER) would have > to be a little special. That was, in essence, my proposal for LONGINT, not for INTEGER. We still need an integer length that's efficient. I wasn't proposing to change the definition of INTEGER, FIRST(INTEGER), and so forth. But if one had a base tyoe of LONGINT and forbade declaring anything of type LONGINT, you could still have BITS 45 FOR LONGINT and the like. It just happens that the usual arithmetic operations are bounded in nature -- the number of bits in the result are bounded by functions of the numbers of bits in the operands, and an assignment so assigning to variable of could end up truncating, possibly with an overflow check. In fact, one could possibly define INTEGER to be BITS 32 FOR LONGINT, but that might involve further consequences in corrner case in the language. -- hendrik > > Mika From rodney_bates at lcwb.coop Thu May 28 01:30:50 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Wed, 27 May 2015 18:30:50 -0500 Subject: [M3devel] 64bit INTEGERs, WIDECHAR: language specified or configuration/target dependent? In-Reply-To: <20150527161412.GA18812@topoi.pooq.com> References: <555E14BC.2040805@lcwb.coop> <555E203E.4040203@elstel.org> <0A1CDD8C-EEB5-40E2-A38B-28E8EEA8C37E@elstel.org> <8A3AB2ED-C11E-4787-A7F8-C8F12157EAA5@elstel.org> <555F6D8F.4070109@lcwb.coop> <6F9B9534-7DC2-4D4D-88CB-90D7FA05E8F9@elstel.org> <20150527161717.83E761A2065@async.async.caltech.edu> <20150527161412.GA18812@topoi.pooq.com> Message-ID: <556653AA.1010105@lcwb.coop> Once more, with feeling. On 05/27/2015 11:14 AM, Hendrik Boom wrote: > On Wed, May 27, 2015 at 09:17:17AM -0700, mika at async.caltech.edu wrote: >> >> Hmm? >> >> Modula-3's INTEGERs are the "integers" of mathematics. The intent is >> that if your implementation is limited and doesn't support a particular >> operation because it goes out of range, your computation aborts. Same >> as any other implementation limitation. >> >> There is no reason I can think of you couldn't come up with an implementation >> that has unlimited-range integers. FIRST(INTEGER) and LAST(INTEGER) would have >> to be a little special. > > That was, in essence, my proposal for LONGINT, not for INTEGER. > We still need an integer length that's efficient. I wasn't proposing to > change the definition of INTEGER, FIRST(INTEGER), and so forth. > > But if one had a base tyoe of LONGINT and forbade declaring anything of > type LONGINT, you could still have BITS 45 FOR LONGINT and the like. TYPE U = BITS n FOR T *does not change the range of values.* The range of U is the same as that of T. If you try to stuff it into too few bits, e.g., BITS 4 FOR [ 0 .. 255 ], it is a static error. If you try to assign a value outside the value range, it is an error, generally at runtime, even if that value would fit in the bit count. E.g., VAR V : BITS 16 FOR [ 0 .. 255 ] := 256 is illegal. The *only* thing BITS n FOR does is, if legal, affect the amount of storage the compiler allocates, and *only for array elements and fields of RECORDs and OBJECTs*. Look at 2.2.5. > It just happens that the usual arithmetic operations are bounded in > nature -- the number of bits in the result are bounded by functions of > the numbers of bits in the operands, and an assignment so assigning > to variable of could end up truncating, possibly with an overflow > check. > > In fact, one could possibly define INTEGER to be BITS 32 FOR > LONGINT, but that might involve further consequences in corrner > case in the language. > > -- hendrik > >> >> Mika > -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Thu May 28 01:45:02 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Wed, 27 May 2015 18:45:02 -0500 Subject: [M3devel] 64bit INTEGERs, WIDECHAR: language specified or configuration/target dependent? In-Reply-To: <20150527163736.B32DE1A2065@async.async.caltech.edu> References: <555E14BC.2040805@lcwb.coop>, <555E203E.4040203@elstel.org> <0A1CDD8C-EEB5-40E2-A38B-28E8EEA8C37E@elstel.org> <8A3AB2ED-C11E-4787-A7F8-C8F12157EAA5@elstel.org> <555F6D8F.4070109@lcwb.coop> <6F9B9534-7DC2-4D4D-88CB-90D7FA05E8F9@elstel.org> <20150527161717.83E761A2065@async.async.caltech.edu> <20150527163736.B32DE1A2065@async.async.caltech.edu> Message-ID: <556656FE.1020003@lcwb.coop> On 05/27/2015 11:37 AM, mika at async.caltech.edu wrote: > Elmar Stellnberger writes: > ... >> I would have loved it to make INTEGER =3D BITS 32 FOR INTEGER and to = >> allow >> BITS 64 for INTEGER at the same time. However the way we have already = >> gone is >> to make LONGINT an own type with an own suffix like floats (the 'l' = >> suffix). More >> strictly typed and not so bad either.= > > Ah yes, LONGINT. > > I remain strongly opposed to that. I think it was a big mistake, it > runs completely counter to Modula-3 design philosophy. INTEGERs are > integers are integers are integers... fm: Command not found. > > Mika > The purpose of LONGINT is, cases where the program won't work with only 32-bit range, but you want the most efficient arithmetic possible on either a 32-bit or a 64-bit machine, without recoding. The compiler will generate either one-word machine arithmetic if the target has it, or two-word, if not. I suffered through this during the 16/32-bit transition, in Pascal and Modula-2. I had to write source-coded 2-word arithmetic, which would have been OK, if the entire universe didn't' have and never would have 32-bit machines. Instead, it unnecessarily wasted storage and computation when compiled on a 32-bit machine. The source code differences for best efficiency on either were a huge pain. -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Thu May 28 02:23:33 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Wed, 27 May 2015 19:23:33 -0500 Subject: [M3devel] 64bit INTEGERs, WIDECHAR: language specified or configuration/target dependent? In-Reply-To: <8BBBC94B-EECC-464A-86BB-FD1C94EC5496@elstel.org> References: <555E14BC.2040805@lcwb.coop>, <555E203E.4040203@elstel.org> <0A1CDD8C-EEB5-40E2-A38B-28E8EEA8C37E@elstel.org> <8A3AB2ED-C11E-4787-A7F8-C8F12157EAA5@elstel.org> <555F6D8F.4070109@lcwb.coop> <6F9B9534-7DC2-4D4D-88CB-90D7FA05E8F9@elstel.org> <8BBBC94B-EECC-464A-86BB-FD1C94EC5496@elstel.org> Message-ID: <55666005.4080406@lcwb.coop> On 05/27/2015 11:32 AM, Elmar Stellnberger wrote: > Enough words about the history, now let us see how we can profit > from both kinds of types when we wanna step on virgin soil: > > In what way we may ever turn things there actually needs to be > a target sized type which is uses to be unsigned: the pointer. > However there needs to be a way to do certain address > calculations manually, apart from array indexing: > multiply, add, subtract & evtl. shift. > I would also believe that it would be handy to have such a type > signed. > i.e. offset = adress1 - adress2 > > Naturally such a type will profit from extending its value range > to the bit size of pointers. > Up to now converting everything to an int has sufficed. However > it will no more for a 64bit arch. > Will we need to convert to a LONGINT then? - but that will be in- > compatible as LONGINT currently takes the 'l'-suffix and longint > is not even supported for the 32bit arch as far as I know. > > Having an own type for this and other purposes like optimized > numeric code would to my believe be beneficial. > Call it OFFSET, TARGETINT, TargetInt.T or Offset.T > Whether to just support such a type by a Word.T like interface > or by a built-in type would likely be worth another discussion. > Word.T (or Long.T, if INTEGER is smaller than a pointer) should pretty much do what you want. Of course, Word.T = INTEGER and Long.T = LONGINT. But the functions on Word/Long apply unsigned interpretation to the bits, with wraparound. The place you have to be careful is which arithmetic to use when, the builtin operators, or the functions in Word/Long. When I do this kind of arithmetic, I am careful about what variables are declared as INTEGER and what ones Word.T, solely to serve as documentation of whether the value is interpreted as signed or unsigned. With wraparound arithmetic, this distinction seldom or never matters for intermediate results, as long as you are clear about which invariant applies to each operand variable and the result variable. And, you are equally careful to think about the true overflow cases, as they affect the final result--something I doubt many do, even with ordinary, all-signed or all-unsigned arithmetic. > So what for now? As I recall things we have introduced > a LONGINT which takes the 0l - suffix for AMD64 only. No, ... > > The first thing would be to introduce a 64bit LONGINT for x86/32bit. We already have this. From 2.2.1: There are two integer types, which in order of increasing range are \verb|INTEGER| and \verb|LONGINT|. I do have the impression that some Windows targets are not currently in compliance, though. Can anybody elaborate? > > and then? > TYPE Offset.T = BITS BITSIZE(ADDRESS) FOR LONGINT ? > One thing we may not have is a way to make the choice between Word and Long self-adapt to match the size of reference types. BITS won't do it. See my recent post about BITS FOR. It could probably be done in the build system with some quake code. > We will have to rewrite some code that assumed offsets to be > integers, then. > > The other possibility we have would be to make an offset a built-in > type and assignment compatible to both int and longint which will > save us from rewriting too much old code. I would claim this not to > be a too big problem as converting back and forth between an > OFFSET and an [LONG]INT should rarely happen. It would only > be used in unsafe interfaces as all address arithmetics > i.e. we should at least make that require an explicit conversion > outside of unsafe interfaces. That way all expressions remained > 100% compatible while only having to declare certain variables > as OFFSET rather than INTEGER. > > >> >> Am 22.05.2015 um 19:55 schrieb Rodney M. Bates: > >>> The evolving nature of first UCS and then Unicode standards has left >>> many language designers knocked off balance. Critical Mass first >>> introduced WIDECHAR as 16-bit when that was what everybody thought >>> was enough. Then things changed, and it wasn't anymore. Right now, >>> it's a configuration parameter (must be the same for the entire link >>> closure) in Modula-3. I personally favor making it full Unicode >>> by default, in the next release, as this is where the world is now. >>> This is hopefully a simpler problem than INTEGER, etc., because, as of >>> now, the Unicode committee has emphatically assured us that the range will >>> *never* increase. We can hope. > > By now I welcome your decision to make the WIDECHAR 32bit! > I believe it should become the default for the upcoming release. > Pure Modula-3 code will take advantage of the new value range. > Just interfacing with certain external toolkits is not enough > justification to freeze things as they are - interfaces need to be > adapted anyway while supporting all three types is just too much > unnecessary work. > > -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Thu May 28 02:41:35 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Wed, 27 May 2015 19:41:35 -0500 Subject: [M3devel] 64bit INTEGERs, WIDECHAR: language specified or configuration/target dependent? In-Reply-To: <20150527161717.83E761A2065@async.async.caltech.edu> References: <555E14BC.2040805@lcwb.coop>, <555E203E.4040203@elstel.org> <0A1CDD8C-EEB5-40E2-A38B-28E8EEA8C37E@elstel.org> <8A3AB2ED-C11E-4787-A7F8-C8F12157EAA5@elstel.org> <555F6D8F.4070109@lcwb.coop> <6F9B9534-7DC2-4D4D-88CB-90D7FA05E8F9@elstel.org> <20150527161717.83E761A2065@async.async.caltech.edu> Message-ID: <5566643F.3090603@lcwb.coop> On 05/27/2015 11:17 AM, mika at async.caltech.edu wrote: > ... >>> Whether types like integer have a language-specified or = >> target-dependent >>> range is a tough language design question. I have tended to favor a >>> fixed, language-specified range, but there are pros and cons. I do >>> think all the time about end-of-range cases and native word size = >> dependencies. >>> It takes a great deal of care, and I know of no way to design a = >> language >>> that doesn't, to some extent, trade one set of problems for another. >>> Signed/unsigned creates similar language dilemmas. >> >> * language-specified or target-dependent >> As I have already suggested I believe there is some justification to = >> have >> both kinds of type: a language dependent type and a target dependent one >> >> The advantages of a language dependent type are rather clear when it >> comes to mere INTEGERs for numeric/counting/calculation purposes. Once >> you have a fixed size you can rely on support of a certain value range.=20= > > Hmm? > > Modula-3's INTEGERs are the "integers" of mathematics. The intent is > that if your implementation is limited and doesn't support a particular > operation because it goes out of range, your computation aborts. Same > as any other implementation limitation. > > There is no reason I can think of you couldn't come up with an implementation > that has unlimited-range integers. FIRST(INTEGER) and LAST(INTEGER) would have > to be a little special. > We've got it in library code: cm3/m3-libs/arithmetic/src/basictypes/biginteger/BigInteger.i3 Does it need to be improved? I've never used it. But it can't just replace a fixed-sized integer type like INTEGER in a language, because we really need INTEGER for subscripts to the array of INTEGERs that implements BigInteger, and lots of other stuff. For a precedent, mathematicians have never, AFAIK, proposed to generalize the infinite series' used to compute powers and roots by replacing the integer subscripts of the series with rationals, reals, or complexes. What is the Pi'th term in an infinite series? > Mika > -- Rodney Bates rodney.m.bates at acm.org From jay.krell at cornell.edu Thu May 28 07:52:51 2015 From: jay.krell at cornell.edu (Jay K) Date: Thu, 28 May 2015 05:52:51 +0000 Subject: [M3devel] 64bit INTEGERs, WIDECHAR: language specified or configuration/target dependent? In-Reply-To: <77605189-D966-4D4B-8946-838BD6E178AA@purdue.edu> References: <555E14BC.2040805@lcwb.coop> <555E203E.4040203@elstel.org>, , , <0A1CDD8C-EEB5-40E2-A38B-28E8EEA8C37E@elstel.org>, , <8A3AB2ED-C11E-4787-A7F8-C8F12157EAA5@elstel.org>, <555F6D8F.4070109@lcwb.coop>, <6F9B9534-7DC2-4D4D-88CB-90D7FA05E8F9@elstel.org>, <8BBBC94B-EECC-464A-86BB-FD1C94EC5496@elstel.org>, <77605189-D966-4D4B-8946-838BD6E178AA@purdue.edu> Message-ID: I believe the proposal is that INTEGER be more like int in C and C+ -- 32bits always. > I do have the impression that some Windows targets are not currently All targets have a 64bit LONGINT. I implemented this years ago in the NT/x86 backend. The C backend depends on the underlying C compiler having __int64 or long long or a 64bit long. All targets have BYTESIZE(INTEGER) == BYTESIZE(ADDRESS). In C and C++, long is smaller than a pointer on Win64. On Windows, int and long are always 32 bits. This might be the case at least sort of on VMS and HP-UX, at least when the upper bits of 64bit pointers are guaranteed all zeros or all ones or ignored. They have such environments -- 32bit-ish pointers on Alpha, 32bit-ish pointers on IA64. I started writing up more detail. There are obviously 8 underlying integer types: unsigned/signed 8/16/32/64 A typical C99 environment has around 40 names for them: stdint.h: 8+16+32+64 x signed/unsigned x fast+least+exact: 24 short/int/long/long long; unsigned: 8 char/unsigned char/signed char: 3 [u]intptr_t: 2 size_t/ptrdiff_t: 2 wchar_t: 1 => 40 In C++, some of them are distinct for overloading/mangling purposes. Windows has far more, like almost double, for various historical and typographical and stylistic reasons. e.g. INT, UINT, LONG, ULONG, WCHAR, CHAR, UCHAR, BYTE, WORD, DWORD, DWORD_PTR, INT_PTR, UINT_PTR, SIZE_T, HALF_PTR, etc. But still the same underlying 8 types. It can be difficult to chose the right type. It is tempting to discount many of them, and many can be discounted, but it hard to really narrow the list to be small. Should we add some more builtins to the frontend? Like [U]INT[8,16,32,64]? Or lowercase and _t? - Jay > Subject: Re: [M3devel] 64bit INTEGERs, WIDECHAR: language specified or configuration/target dependent? > From: hosking at purdue.edu > Date: Thu, 28 May 2015 05:03:39 +0300 > CC: rodney.m.bates at acm.org; jay.krell at cornell.edu; m3devel at elegosoft.com > To: estellnb at elstel.org > > BYTESIZE(ADDRESS) = BYTESIZE(INTEGER) in cm3 on all target platforms. I don't really understand what you are proposing. > > Sent from my iPhone > > > On May 27, 2015, at 7:32 PM, Elmar Stellnberger wrote: > > > > Enough words about the history, now let us see how we can profit > > from both kinds of types when we wanna step on virgin soil: > > > > In what way we may ever turn things there actually needs to be > > a target sized type which is uses to be unsigned: the pointer. > > However there needs to be a way to do certain address > > calculations manually, apart from array indexing: > > multiply, add, subtract & evtl. shift. > > I would also believe that it would be handy to have such a type > > signed. > > i.e. offset = adress1 - adress2 > > > > Naturally such a type will profit from extending its value range > > to the bit size of pointers. > > Up to now converting everything to an int has sufficed. However > > it will no more for a 64bit arch. > > Will we need to convert to a LONGINT then? - but that will be in- > > compatible as LONGINT currently takes the 'l'-suffix and longint > > is not even supported for the 32bit arch as far as I know. > > > > Having an own type for this and other purposes like optimized > > numeric code would to my believe be beneficial. > > Call it OFFSET, TARGETINT, TargetInt.T or Offset.T > > Whether to just support such a type by a Word.T like interface > > or by a built-in type would likely be worth another discussion. > > > > So what for now? As I recall things we have introduced > > a LONGINT which takes the 0l - suffix for AMD64 only. > > > > The first thing would be to introduce a 64bit LONGINT for x86/32bit. > > > > and then? > > TYPE Offset.T = BITS BITSIZE(ADDRESS) FOR LONGINT ? > > > > We will have to rewrite some code that assumed offsets to be > > integers, then. > > > > The other possibility we have would be to make an offset a built-in > > type and assignment compatible to both int and longint which will > > save us from rewriting too much old code. I would claim this not to > > be a too big problem as converting back and forth between an > > OFFSET and an [LONG]INT should rarely happen. It would only > > be used in unsafe interfaces as all address arithmetics > > i.e. we should at least make that require an explicit conversion > > outside of unsafe interfaces. That way all expressions remained > > 100% compatible while only having to declare certain variables > > as OFFSET rather than INTEGER. > > > > > >> > >> Am 22.05.2015 um 19:55 schrieb Rodney M. Bates: > > > >>> The evolving nature of first UCS and then Unicode standards has left > >>> many language designers knocked off balance. Critical Mass first > >>> introduced WIDECHAR as 16-bit when that was what everybody thought > >>> was enough. Then things changed, and it wasn't anymore. Right now, > >>> it's a configuration parameter (must be the same for the entire link > >>> closure) in Modula-3. I personally favor making it full Unicode > >>> by default, in the next release, as this is where the world is now. > >>> This is hopefully a simpler problem than INTEGER, etc., because, as of > >>> now, the Unicode committee has emphatically assured us that the range will > >>> *never* increase. We can hope. > > > > By now I welcome your decision to make the WIDECHAR 32bit! > > I believe it should become the default for the upcoming release. > > Pure Modula-3 code will take advantage of the new value range. > > Just interfacing with certain external toolkits is not enough > > justification to freeze things as they are - interfaces need to be > > adapted anyway while supporting all three types is just too much > > unnecessary work. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adacore at marino.st Thu May 28 11:50:13 2015 From: adacore at marino.st (John Marino) Date: Thu, 28 May 2015 11:50:13 +0200 Subject: [M3devel] scripts/README obsolete (where is boot-cm3-with-m3.sh ?) Message-ID: <5566E4D5.3070402@marino.st> I just downloaded the current repo at github. the scripts/README hasn't changed, it still talks about boot-cm3-with-m3.sh, but that script is missing now. What has taken its place? I recommend the README be updated because it is wrong now. John From adacore at marino.st Thu May 28 12:23:54 2015 From: adacore at marino.st (John Marino) Date: Thu, 28 May 2015 12:23:54 +0200 Subject: [M3devel] scripts/README obsolete (where is boot-cm3-with-m3.sh ?) In-Reply-To: <5566E4D5.3070402@marino.st> References: <5566E4D5.3070402@marino.st> Message-ID: <5566ECBA.2050006@marino.st> On 5/28/2015 11:50, John Marino wrote: > I just downloaded the current repo at github. > > the scripts/README hasn't changed, it still talks about > boot-cm3-with-m3.sh, but that script is missing now. > > What has taken its place? > > I recommend the README be updated because it is wrong now. > FWIW, I copied boot-cm3-with-m3.sh from 5.8.6 and it seemed to work for a while but when the compiler hit src/TIntN.i3 it blew up. So it appears that the bootstrap (5.8.6) can't build 5.10.0. John From adacore at marino.st Thu May 28 13:12:03 2015 From: adacore at marino.st (John Marino) Date: Thu, 28 May 2015 13:12:03 +0200 Subject: [M3devel] scripts/README obsolete (where is boot-cm3-with-m3.sh ?) In-Reply-To: <5566ECBA.2050006@marino.st> References: <5566E4D5.3070402@marino.st> <5566ECBA.2050006@marino.st> Message-ID: <5566F803.10902@marino.st> On 5/28/2015 12:23, John Marino wrote: > On 5/28/2015 11:50, John Marino wrote: >> I just downloaded the current repo at github. >> >> the scripts/README hasn't changed, it still talks about >> boot-cm3-with-m3.sh, but that script is missing now. >> >> What has taken its place? >> >> I recommend the README be updated because it is wrong now. >> > > FWIW, I copied boot-cm3-with-m3.sh from 5.8.6 and it seemed to work for > a while but when the compiler hit src/TIntN.i3 it blew up. > > So it appears that the bootstrap (5.8.6) can't build 5.10.0. > Searching old messages, I found scripts/python/upgrade.py which seems to be working. The documentation seems to be really behind! John From adacore at marino.st Thu May 28 13:49:04 2015 From: adacore at marino.st (John Marino) Date: Thu, 28 May 2015 13:49:04 +0200 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 Message-ID: <556700B0.8060500@marino.st> I got stuck again trying to build the latest on FreeBSD. 1. tar extracted to working directory along with a bootstrap compiler 2. CM3 and CM3_INSTALL defined in environment 3. executed scripts/python/upgrade.py result: http://leaf.dragonflybsd.org/~marino/m3.log I could guess that something is picking up a bootstrap component instead of a newly built one. I guess it's trying to build the c backend? Am I doing some kind of obvious mistake? John From wagner at elego.de Thu May 28 16:02:21 2015 From: wagner at elego.de (Olaf Wagner) Date: Thu, 28 May 2015 16:02:21 +0200 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <556700B0.8060500@marino.st> References: <556700B0.8060500@marino.st> Message-ID: <20150528160221.95d4c26d83f68f8cfa93d75a@elego.de> On Thu, 28 May 2015 13:49:04 +0200 John Marino wrote: > I got stuck again trying to build the latest on FreeBSD. > > 1. tar extracted to working directory along with a bootstrap compiler > 2. CM3 and CM3_INSTALL defined in environment > 3. executed scripts/python/upgrade.py > > result: > http://leaf.dragonflybsd.org/~marino/m3.log > > I could guess that something is picking up a bootstrap component instead > of a newly built one. I guess it's trying to build the c backend? > > Am I doing some kind of obvious mistake? No. I think upgrade.sh (or .py) cannot really cope with updating a 5.8.6 instance to the current state. It took me several days, too, on MacOS X, and I had to do a lot of manual tweaking and copying around. I don't think any casual user will understand the details :-| IMO the best thing we can do now is provide some more up-to-date binary archives (I'll upload my own stuff as soon as I find the time). A newer release has been missing for several years, and the existing scripts are no great help for new users. Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From adacore at marino.st Thu May 28 16:14:11 2015 From: adacore at marino.st (John Marino) Date: Thu, 28 May 2015 16:14:11 +0200 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <20150528160221.95d4c26d83f68f8cfa93d75a@elego.de> References: <556700B0.8060500@marino.st> <20150528160221.95d4c26d83f68f8cfa93d75a@elego.de> Message-ID: <556722B3.7080209@marino.st> On 5/28/2015 16:02, Olaf Wagner wrote: > On Thu, 28 May 2015 13:49:04 +0200 > John Marino wrote: >> Am I doing some kind of obvious mistake? > > No. I think upgrade.sh (or .py) cannot really cope with updating a 5.8.6 > instance to the current state. It took me several days, too, on > MacOS X, and I had to do a lot of manual tweaking and copying > around. I don't think any casual user will understand the details That's a pretty big sin given how 5.8.6 is the current release! > IMO the best thing we can do now is provide some more up-to-date > binary archives (I'll upload my own stuff as soon as I find the time). > A newer release has been missing for several years, and the existing > scripts are no great help for new users. Is there a git tag that can build from 5.8.6? Maybe I just have to keep doing this until I get a new bootstrap that can do it. John From rodney_bates at lcwb.coop Thu May 28 17:01:21 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 28 May 2015 10:01:21 -0500 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <556700B0.8060500@marino.st> References: <556700B0.8060500@marino.st> Message-ID: <55672DC1.7080509@lcwb.coop> On 05/28/2015 06:49 AM, John Marino wrote: > I got stuck again trying to build the latest on FreeBSD. > > 1. tar extracted to working directory along with a bootstrap compiler > 2. CM3 and CM3_INSTALL defined in environment > 3. executed scripts/python/upgrade.py > > result: > http://leaf.dragonflybsd.org/~marino/m3.log > > I could guess that something is picking up a bootstrap component instead > of a newly built one. Yes. >> m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 means it is trying to compile using a new cm3cg backend and an old cm3 front end. I just added this error message after Olaf had this problem. (Otherwise it would have failed anyway, but with a less informative message.) > I guess it's trying to build the c backend? > It finished the C backend and was trying to build m3core, using the inconsistent compiler. Usually, neither cm3 nor cm3cg is copied to the bin directory, even when doing a ship, in order to avoid this, which is an exception. For all other executables, ship copies them to the bin directory. The shell script scripts/install-cm3-compiler.sh is then run manually, after both cm3 and cm3cg are compiled, to copy them to bin atomically (sort of). I don't know why that happened. I don't have experience with the Python scripts. Jay? Also, this script built the compiler before the support libraries m3core and libm3. I think there may have been one bootstrap scenario where this was the way it needed to be done, but usually it is the other way around--these two libraries first. > Am I doing some kind of obvious mistake? > No, it's a bootstrap barrier. These pop up somewhat regularly. We all usually just build from the most recent development build, which works for getting new things tried out initially. But we need to make a habit of regularly rebuilding from the previous release to flush these out. You might try scripts/do-cm3-front.sh realclean scripts/do-cm3-front.sh buildship (I usually save /usr/local/cm3/bin/cm3 and /usr/local/cm3/bin/cm3cg at this point. The step below does it somewhat redundantly, but only one level, unless the version number changes.) scripts/install-cm3-compiler.sh upgrade. From here, you are using the new compiler. scripts/do-cm3-.sh buildship That this works, starting with the previous release compiler, is my criterion for having removed bootstrap barriers. > John > -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Thu May 28 17:17:08 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 28 May 2015 10:17:08 -0500 Subject: [M3devel] Too many names for the gcc backend. Was: m3cgc1: fatal error ... In-Reply-To: <556700B0.8060500@marino.st> References: <556700B0.8060500@marino.st> Message-ID: <55673174.80804@lcwb.coop> BTW, the gcc-derived back end has too many names. m3cc: The package name m3cg: The directory containing glue code to gcc m3cgc1: The executable built inside m3cc. Also, what it identifies itself as in error messages cm3cg: The executable, when installed in /usr/local/cm3/bin Did I even get it complete or right? On 05/28/2015 06:49 AM, John Marino wrote: > I got stuck again trying to build the latest on FreeBSD. > > 1. tar extracted to working directory along with a bootstrap compiler > 2. CM3 and CM3_INSTALL defined in environment > 3. executed scripts/python/upgrade.py > > result: > http://leaf.dragonflybsd.org/~marino/m3.log > > I could guess that something is picking up a bootstrap component instead > of a newly built one. I guess it's trying to build the c backend? > > Am I doing some kind of obvious mistake? > > John > -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Thu May 28 17:21:47 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 28 May 2015 10:21:47 -0500 Subject: [M3devel] 64bit INTEGERs, WIDECHAR: language specified or configuration/target dependent? In-Reply-To: <77605189-D966-4D4B-8946-838BD6E178AA@purdue.edu> References: <555E14BC.2040805@lcwb.coop> <555E203E.4040203@elstel.org> <0A1CDD8C-EEB5-40E2-A38B-28E8EEA8C37E@elstel.org> <8A3AB2ED-C11E-4787-A7F8-C8F12157EAA5@elstel.org> <555F6D8F.4070109@lcwb.coop> <6F9B9534-7DC2-4D4D-88CB-90D7FA05E8F9@elstel.org> <8BBBC94B-EECC-464A-86BB-FD1C94EC5496@elstel.org> <77605189-D966-4D4B-8946-838BD6E178AA@purdue.edu> Message-ID: <5567328B.70003@lcwb.coop> On 05/27/2015 09:03 PM, Antony Hosking wrote: > BYTESIZE(ADDRESS) = BYTESIZE(INTEGER) in cm3 on all target platforms. I don't really understand what you are proposing. > I am glad to hear that. > Sent from my iPhone > -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Thu May 28 17:23:48 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 28 May 2015 10:23:48 -0500 Subject: [M3devel] 64bit INTEGERs, WIDECHAR: language specified or configuration/target dependent? In-Reply-To: References: <555E14BC.2040805@lcwb.coop> <555E203E.4040203@elstel.org>, , , <0A1CDD8C-EEB5-40E2-A38B-28E8EEA8C37E@elstel.org>, , <8A3AB2ED-C11E-4787-A7F8-C8F12157EAA5@elstel.org>, <555F6D8F.4070109@lcwb.coop>, <6F9B9534-7DC2-4D4D-88CB-90D7FA05E8F9@elstel.org>, <8BBBC94B-EECC-464A-86BB-FD1C94EC5496@elstel.org>, <77605189-D966-4D4B-8946-838BD6E178AA@purdue.edu> Message-ID: <55673304.5090602@lcwb.coop> On 05/28/2015 12:52 AM, Jay K wrote: > I believe the proposal is that INTEGER be more like int in C and C+ -- 32bits always. > > > > I do have the impression that some Windows targets are not currently > > > All targets have a 64bit LONGINT. I implemented this years ago in the NT/x86 backend. Glad to hear that, too. -- Rodney Bates rodney.m.bates at acm.org From adacore at marino.st Thu May 28 17:56:20 2015 From: adacore at marino.st (John Marino) Date: Thu, 28 May 2015 17:56:20 +0200 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <55672DC1.7080509@lcwb.coop> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> Message-ID: <55673AA4.8050100@marino.st> On 5/28/2015 17:01, Rodney M. Bates wrote: > I don't know why that happened. I don't have experience with the > Python scripts. > > Jay? > > Also, this script built the compiler before the support libraries > m3core and libm3. I think there may have been one bootstrap scenario > where this was the way it needed to be done, but usually it is the > other way around--these two libraries first. > >> Am I doing some kind of obvious mistake? >> > No, it's a bootstrap barrier. These pop up somewhat regularly. We > all usually just build from the most recent development build, which > works for getting new things tried out initially. But we need to > make a habit of regularly rebuilding from the previous release to > flush these out. Olaf said, IIUC, that the current code can't be built by the last release compiler. Putting aside that I believe that should be a hard requirement for the project, it sounds like maybe the last release can build it if the build order is fixed (e.g. a better upgrade.py script)? It's not clear to me what the real situation is. > You might try scripts/do-cm3-front.sh realclean > scripts/do-cm3-front.sh buildship > > (I usually save /usr/local/cm3/bin/cm3 and /usr/local/cm3/bin/cm3cg > at this point. The step below does it somewhat redundantly, but only > one level, unless the version number changes.) > > scripts/install-cm3-compiler.sh upgrade. > From here, you are using the new compiler. > scripts/do-cm3-.sh buildship > > That this works, starting with the previous release compiler, is my > criterion for having removed bootstrap barriers. My work takes place within a Makefile and moving things in /usr/local (for example) is actually illegal. Now I could do all this manually for the purpose of building a new bootstrap, but as I mentioned in a previous post, it might be more effective to emulate what you guy have done: essentially build a series of bootstraps at strategic hashes until I've acquired a compiler that can build this (and then use that product as bootstrap for FreeBSD ports). If I did that approach, I could use a hint on the hashes to try... John From jay.krell at cornell.edu Thu May 28 18:16:48 2015 From: jay.krell at cornell.edu (Jay) Date: Thu, 28 May 2015 09:16:48 -0700 Subject: [M3devel] 64bit INTEGERs, WIDECHAR: language specified or configuration/target dependent? In-Reply-To: <20150527161412.GA18812@topoi.pooq.com> References: <555E14BC.2040805@lcwb.coop> <555E203E.4040203@elstel.org> <0A1CDD8C-EEB5-40E2-A38B-28E8EEA8C37E@elstel.org> <8A3AB2ED-C11E-4787-A7F8-C8F12157EAA5@elstel.org> <555F6D8F.4070109@lcwb.coop> <6F9B9534-7DC2-4D4D-88CB-90D7FA05E8F9@elstel.org> <20150527161717.83E761A2065@async.async.caltech.edu> <20150527161412.GA18812@topoi.pooq.com> Message-ID: <11BEF01E-B5F6-4FD3-A7B3-FDEDAD481D42@gmail.com> Arbitrary fixed width integers in the language? Kinda nice. 1. Bits X for integer? Why call it longint? Make the range affected? 2. Once you have operator overloading these language debates fall away and become easier but still non-trivial library debates. Similar thing happens with strings, complex numbers, arrays. Stuff that people like to build into languages because the language can't accommodate writing efficient easy to use libraries. Mutexes too but due to other language features (stack allocated classes with destructors). Even hashtables benefit, from operator[]. Maybe worth evolving the language this way? Name overloading too. e.g. You want String.Plus(char) and String.Plus(string). - Jay On May 27, 2015, at 9:14 AM, Hendrik Boom wrote: > On Wed, May 27, 2015 at 09:17:17AM -0700, mika at async.caltech.edu wrote: >> >> Hmm? >> >> Modula-3's INTEGERs are the "integers" of mathematics. The intent is >> that if your implementation is limited and doesn't support a particular >> operation because it goes out of range, your computation aborts. Same >> as any other implementation limitation. >> >> There is no reason I can think of you couldn't come up with an implementation >> that has unlimited-range integers. FIRST(INTEGER) and LAST(INTEGER) would have >> to be a little special. > > That was, in essence, my proposal for LONGINT, not for INTEGER. > We still need an integer length that's efficient. I wasn't proposing to > change the definition of INTEGER, FIRST(INTEGER), and so forth. > > But if one had a base tyoe of LONGINT and forbade declaring anything of > type LONGINT, you could still have BITS 45 FOR LONGINT and the like. > It just happens that the usual arithmetic operations are bounded in > nature -- the number of bits in the result are bounded by functions of > the numbers of bits in the operands, and an assignment so assigning > to variable of could end up truncating, possibly with an overflow > check. > > In fact, one could possibly define INTEGER to be BITS 32 FOR > LONGINT, but that might involve further consequences in corrner > case in the language. > > -- hendrik > >> >> Mika From wagner at elegosoft.com Thu May 28 19:06:43 2015 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 28 May 2015 19:06:43 +0200 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <55673AA4.8050100@marino.st> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> Message-ID: <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> On Thu, 28 May 2015 17:56:20 +0200 John Marino wrote: > On 5/28/2015 17:01, Rodney M. Bates wrote: > > I don't know why that happened. I don't have experience with the > > Python scripts. > > > > Jay? > > > > Also, this script built the compiler before the support libraries > > m3core and libm3. I think there may have been one bootstrap scenario > > where this was the way it needed to be done, but usually it is the > > other way around--these two libraries first. > > > >> Am I doing some kind of obvious mistake? > >> > > No, it's a bootstrap barrier. These pop up somewhat regularly. We > > all usually just build from the most recent development build, which > > works for getting new things tried out initially. But we need to > > make a habit of regularly rebuilding from the previous release to > > flush these out. > > Olaf said, IIUC, that the current code can't be built by the last > release compiler. Putting aside that I believe that should be a hard > requirement for the project, it sounds like maybe the last release can > build it if the build order is fixed (e.g. a better upgrade.py script)? > It's not clear to me what the real situation is. No, this is a misunderstanding. I just said or tried to say that there is no script (yet) that is smart enough to do all the things necessary to build the current compiler on base of 5.8.6. > > You might try scripts/do-cm3-front.sh realclean > > scripts/do-cm3-front.sh buildship > > > > (I usually save /usr/local/cm3/bin/cm3 and /usr/local/cm3/bin/cm3cg > > at this point. The step below does it somewhat redundantly, but only > > one level, unless the version number changes.) > > > > scripts/install-cm3-compiler.sh upgrade. > > From here, you are using the new compiler. > > scripts/do-cm3-.sh buildship > > > > That this works, starting with the previous release compiler, is my > > criterion for having removed bootstrap barriers. Rodney, have you really tried that? I'm not sure the steps above will work. I had the feeling that we're missing some intermediate releases, but I might be wrong there. > My work takes place within a Makefile and moving things in /usr/local > (for example) is actually illegal. Now I could do all this manually for > the purpose of building a new bootstrap, but as I mentioned in a > previous post, it might be more effective to emulate what you guy have > done: essentially build a series of bootstraps at strategic hashes until > I've acquired a compiler that can build this (and then use that product > as bootstrap for FreeBSD ports). > > If I did that approach, I could use a hint on the hashes to try... We should be able to script something that sets up the current compiler at least on a given specific platform with a well-defined environment. I might be able to offer more help in the second week of June, if you can wait until then. Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Thu May 28 19:12:19 2015 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 28 May 2015 19:12:19 +0200 Subject: [M3devel] Too many names for the gcc backend. Was: m3cgc1: fatal error ... In-Reply-To: <55673174.80804@lcwb.coop> References: <556700B0.8060500@marino.st> <55673174.80804@lcwb.coop> Message-ID: <20150528191219.2718dd20002b3678121306c9@elegosoft.com> On Thu, 28 May 2015 10:17:08 -0500 "Rodney M. Bates" wrote: > BTW, the gcc-derived back end has too many names. > > m3cc: The package name > m3cg: The directory containing glue code to gcc > m3cgc1: The executable built inside m3cc. > Also, what it identifies itself as in error messages > cm3cg: The executable, when installed in /usr/local/cm3/bin > > Did I even get it complete or right? Yes. It's all due to historical reasons, IIRC. m3cgc1 was the name in the PM3 distribution, and Critical Mass used the cm3cg name. I never changed any of the names intentionally, though I should perhaps have done that, when we made the open source release of the CM3 code base. Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From estellnb at elstel.org Thu May 28 19:46:12 2015 From: estellnb at elstel.org (Elmar Stellnberger) Date: Thu, 28 May 2015 19:46:12 +0200 Subject: [M3devel] 64bit INTEGERs, WIDECHAR: language specified or configuration/target dependent? In-Reply-To: <77605189-D966-4D4B-8946-838BD6E178AA@purdue.edu> References: <555E14BC.2040805@lcwb.coop> <555E203E.4040203@elstel.org> <0A1CDD8C-EEB5-40E2-A38B-28E8EEA8C37E@elstel.org> <8A3AB2ED-C11E-4787-A7F8-C8F12157EAA5@elstel.org> <555F6D8F.4070109@lcwb.coop> <6F9B9534-7DC2-4D4D-88CB-90D7FA05E8F9@elstel.org> <8BBBC94B-EECC-464A-86BB-FD1C94EC5496@elstel.org> <77605189-D966-4D4B-8946-838BD6E178AA@purdue.edu> Message-ID: <55675464.5090306@elstel.org> Am 28.05.15 um 04:03 schrieb Antony Hosking: > BYTESIZE(ADDRESS) = BYTESIZE(INTEGER) in cm3 on all target platforms. I don't really understand what you are proposing. > on AMD64: BITSIZE(INTEGER) = BITSIZE(LONGINT) = 64bit I have just noticed that and when taking a practical standpoint - i.e. what really matters to new and old programs - this is a really bad decision which I wish to change for the next release. If you have not examined it yet please reclaim the design decisions for leaving int 32bit in C: /However things turned out to be very different when the extension from 32bit to 64bit was at stake. There was no more gain by automatically extending the value ranges from 2^32 to 2^64 for 95% of all application purposes while the memory hierarchy has increasingly become a bottle neck in recent time. Additionally doubling the size of all integers would initially have doubled our memory needs which would have been a potential drawback for introducing the AMD64 arch. Just think of a machine with 4GB of RAM: It can not be addressed by 32bit (only ~3GB can) while making all INTS 64bit would have shrunken our memory to an effective size of 2GB. Luckily the decision was taken differently this time: * keep all ints of at most 32bit and just extend pointers to 64bit / Same reasoning applies to Modula-3. - and I believe you have failed to notice when making your decisions for cm3 5.8.6. Or do you want to tell me that Modula-3 developers are more prudent than the C/C++ community? Even worse I have discovered the following: BITS 8 FOR INTEGER and BITS 32 FOR INTEGER do not work with cm3 5.8.6: :: BITS FOR size too small, must be at least (64) That will break existing legacy code when trying to compile it with cm3 5.8.6. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Thu May 28 16:18:11 2015 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Thu, 28 May 2015 10:18:11 -0400 Subject: [M3devel] 64bit INTEGERs, WIDECHAR: language specified or configuration/target dependent? In-Reply-To: <556653AA.1010105@lcwb.coop> References: <0A1CDD8C-EEB5-40E2-A38B-28E8EEA8C37E@elstel.org> <8A3AB2ED-C11E-4787-A7F8-C8F12157EAA5@elstel.org> <555F6D8F.4070109@lcwb.coop> <6F9B9534-7DC2-4D4D-88CB-90D7FA05E8F9@elstel.org> <20150527161717.83E761A2065@async.async.caltech.edu> <20150527161412.GA18812@topoi.pooq.com> <556653AA.1010105@lcwb.coop> Message-ID: <20150528141810.GA19285@topoi.pooq.com> On Wed, May 27, 2015 at 06:30:50PM -0500, Rodney M. Bates wrote: > Once more, with feeling. > > On 05/27/2015 11:14 AM, Hendrik Boom wrote: > >On Wed, May 27, 2015 at 09:17:17AM -0700, mika at async.caltech.edu wrote: > >> > >>Hmm? > >> > >>Modula-3's INTEGERs are the "integers" of mathematics. The intent is > >>that if your implementation is limited and doesn't support a particular > >>operation because it goes out of range, your computation aborts. Same > >>as any other implementation limitation. > >> > >>There is no reason I can think of you couldn't come up with an implementation > >>that has unlimited-range integers. FIRST(INTEGER) and LAST(INTEGER) would have > >>to be a little special. > > > >That was, in essence, my proposal for LONGINT, not for INTEGER. > >We still need an integer length that's efficient. I wasn't proposing to > >change the definition of INTEGER, FIRST(INTEGER), and so forth. > > > >But if one had a base tyoe of LONGINT and forbade declaring anything of > >type LONGINT, you could still have BITS 45 FOR LONGINT and the like. I should probably have said something like -2^44-1 .. 2^44, or whatever those numbers are when spelled out in decimal. Of course the syntax for this might still have to indicate LONGINT somehow, because I'd have doubts about the base type depending on the size of the numbers I coded. The base type affects a lot of assumptions about things like the default subscript type for dynamic arrays and the like. > > TYPE U = BITS n FOR T *does not change the range of values.* The range > of U is the same as that of T. WHich is why I should have used a range instead of a number of bits. > > If you try to stuff it into too few bits, e.g., BITS 4 FOR [ 0 .. 255 ], > it is a static error. > > If you try to assign a value outside the value range, it is an error, > generally at runtime, even if that value would fit in the bit count. > E.g., VAR V : BITS 16 FOR [ 0 .. 255 ] := 256 is illegal. > > The *only* thing BITS n FOR does is, if legal, affect the amount of > storage the compiler allocates, and *only for array elements and > fields of RECORDs and OBJECTs*. ... > > > >In fact, one could possibly define INTEGER to be BITS 32 FOR > >LONGINT, but that might involve further consequences in corrner > >case in the language. > > > >-- hendrik > > > >> > >> Mika > > > > -- > Rodney Bates > rodney.m.bates at acm.org From hendrik at topoi.pooq.com Thu May 28 16:21:58 2015 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Thu, 28 May 2015 10:21:58 -0400 Subject: [M3devel] 64bit INTEGERs, WIDECHAR: language specified or configuration/target dependent? In-Reply-To: <55675464.5090306@elstel.org> References: <0A1CDD8C-EEB5-40E2-A38B-28E8EEA8C37E@elstel.org> <8A3AB2ED-C11E-4787-A7F8-C8F12157EAA5@elstel.org> <555F6D8F.4070109@lcwb.coop> <6F9B9534-7DC2-4D4D-88CB-90D7FA05E8F9@elstel.org> <8BBBC94B-EECC-464A-86BB-FD1C94EC5496@elstel.org> <77605189-D966-4D4B-8946-838BD6E178AA@purdue.edu> <55675464.5090306@elstel.org> Message-ID: <20150528142158.GB19285@topoi.pooq.com> On Thu, May 28, 2015 at 07:46:12PM +0200, Elmar Stellnberger wrote: > Am 28.05.15 um 04:03 schrieb Antony Hosking: > >BYTESIZE(ADDRESS) = BYTESIZE(INTEGER) in cm3 on all target platforms. I don't really understand what you are proposing. > > > on AMD64: BITSIZE(INTEGER) = BITSIZE(LONGINT) = 64bit > > I have just noticed that and when taking a practical standpoint - > i.e. what really matters to new and old programs - > this is a really bad decision which I wish to change for the next release. > > If you have not examined it yet please reclaim the design decisions > for leaving int 32bit in C: > > /However things turned out to be very different when the extension from > 32bit to 64bit was at stake. There was no more gain by automatically > extending the value ranges from 2^32 to 2^64 for 95% of all application > purposes while the memory hierarchy has increasingly become a bottle > neck in recent time. Additionally doubling the size of all integers would > initially have doubled our memory needs which would have been a > potential drawback for introducing the AMD64 arch. Just think of a machine > with 4GB of RAM: It can not be addressed by 32bit (only ~3GB can) while > making all INTS 64bit would have shrunken our memory to an effective size > of 2GB. Luckily the decision was taken differently this time: > > * keep all ints of at most 32bit and just extend pointers to 64bit > / > > Same reasoning applies to Modula-3. - and I believe you have failed > to notice when > making your decisions for cm3 5.8.6. Or do you want to tell me that > Modula-3 > developers are more prudent than the C/C++ community? > > Even worse I have discovered the following: > BITS 8 FOR INTEGER and BITS 32 FOR INTEGER do not work with cm3 5.8.6: As I understand it from Rodney Bates' reply to my recent post, BITS 8 FOR INTEGER should never have worked. BITS 32 FOR INTEGER should work only if INTEGER is 32 bits wide. > > :: BITS FOR size too small, must be at least (64) > > That will break existing legacy code when trying to compile it with > cm3 5.8.6. From adacore at marino.st Thu May 28 21:13:44 2015 From: adacore at marino.st (John Marino) Date: Thu, 28 May 2015 21:13:44 +0200 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> Message-ID: <556768E8.10107@marino.st> On 5/28/2015 19:06, Olaf Wagner wrote: > On Thu, 28 May 2015 17:56:20 +0200 > John Marino wrote: >> If I did that approach, I could use a hint on the hashes to try... > > We should be able to script something that sets up the current compiler > at least on a given specific platform with a well-defined environment. > I might be able to offer more help in the second week of June, if you > can wait until then. I honestly don't know if I can. In general I have a zillion irons in the fire (it's taken almost 18 months to cycle back to M3) and this is not a normal summer. What I'm saying is, if it's done mid-June, it could be Christmas before I take advantage of it. Or not. One never knows. John From estellnb at elstel.org Thu May 28 21:53:33 2015 From: estellnb at elstel.org (Elmar Stellnberger) Date: Thu, 28 May 2015 21:53:33 +0200 Subject: [M3devel] 64bit INTEGERs, WIDECHAR: language specified or configuration/target dependent? In-Reply-To: <55675464.5090306@elstel.org> References: <555E14BC.2040805@lcwb.coop> <555E203E.4040203@elstel.org> <0A1CDD8C-EEB5-40E2-A38B-28E8EEA8C37E@elstel.org> <8A3AB2ED-C11E-4787-A7F8-C8F12157EAA5@elstel.org> <555F6D8F.4070109@lcwb.coop> <6F9B9534-7DC2-4D4D-88CB-90D7FA05E8F9@elstel.org> <8BBBC94B-EECC-464A-86BB-FD1C94EC5496@elstel.org> <77605189-D966-4D4B-8946-838BD6E178AA@purdue.edu> <55675464.5090306@elstel.org> Message-ID: <5567723D.3020706@elstel.org> How for the hell do you interface with operating system services requiring a 32bit int when you only have the 64bit INTEGER?? Am 28.05.15 um 19:46 schrieb Elmar Stellnberger: > Am 28.05.15 um 04:03 schrieb Antony Hosking: >> BYTESIZE(ADDRESS) = BYTESIZE(INTEGER) in cm3 on all target platforms. I don't really understand what you are proposing. >> > on AMD64: BITSIZE(INTEGER) = BITSIZE(LONGINT) = 64bit > > I have just noticed that and when taking a practical standpoint - i.e. > what really matters to new and old programs - > this is a really bad decision which I wish to change for the next release. > > If you have not examined it yet please reclaim the design decisions > for leaving int 32bit in C: > /However things turned out to be very different when the extension from > 32bit to 64bit was at stake. There was no more gain by automatically > extending the value ranges from 2^32 to 2^64 for 95% of all application > purposes while the memory hierarchy has increasingly become a bottle > neck in recent time. Additionally doubling the size of all integers would > initially have doubled our memory needs which would have been a > potential drawback for introducing the AMD64 arch. Just think of a machine > with 4GB of RAM: It can not be addressed by 32bit (only ~3GB can) while > making all INTS 64bit would have shrunken our memory to an effective size > of 2GB. Luckily the decision was taken differently this time: > > * keep all ints of at most 32bit and just extend pointers to 64bit > / > Same reasoning applies to Modula-3. - and I believe you have failed > to notice when > making your decisions for cm3 5.8.6. Or do you want to tell me that > Modula-3 > developers are more prudent than the C/C++ community? > > Even worse I have discovered the following: > BITS 8 FOR INTEGER and BITS 32 FOR INTEGER do not work with cm3 5.8.6: > > :: BITS FOR size too small, must be at least (64) > > That will break existing legacy code when trying to compile it with > cm3 5.8.6. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu May 28 22:14:49 2015 From: jay.krell at cornell.edu (Jay K) Date: Thu, 28 May 2015 20:14:49 +0000 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <55672DC1.7080509@lcwb.coop> References: <556700B0.8060500@marino.st>,<55672DC1.7080509@lcwb.coop> Message-ID: > Also, this script built the compiler before the support libraries m3core and > libm3. I think there may have been one bootstrap scenario where this was the > way it needed to be done, but usually it is the other way around--these two > libraries first. This is very deliberate and should always work, when doing a native upgrade. It is true it is not always required. When doing a "clean" cross build, it is true that it is backwards. It is required when upgrading from an older build. Native upgrades start at least with a working compiler and its matching runtime. Cross builds start with a working host compiler and nothing for the target -- so they do start with m3core. The idea that people don't get right away is that the compiler and runtime are very coupled. A compiler targets a particular runtime. Its output requires a certain runtime. Look at RT0.i3 in particular. We haven't changed that in over 10 years, but Critical Mass did. For example. Or if you change the size of WIDECHAR. The compiler outputs data that the garbage collector uses. The compiler outputs function calls that are to functions in m3core. The coupling to libm3 is less clear to me, but the coupling to m3core is significant. m3core is kind of the lowest level runtime that compiler pretty much unavoidably requires to be with its output. Perhaps if you write code w/o any traced types and without try/finally or raise, you can avoid m3core. But there is still module initialization and running "main". So m3core is unavoidable. In the Unix world, consider like crtstart.o. In the Windows world, consider that main is called from mainCRTStartup and this is like wherever that is. (Or DllMain is called from DllMainCRTSTartup, WinMain is called from WinMainCRTStartup, etc. There is an analog between DllMain and the entry points of each module other than Main.) libm3 is more a convenience library that you can maybe possibly do without. Consider this, like, not the startup code, but stdio, stdlib, STL, etc. Another dependency people don't understand is between the frontend and the backend. The gcc backend in particular. When you change the "M3CG", the persisted IR, these two have to be updated together. Again, these things don't change much, so we get away without worrying about and without automating it and without people understanding it. We changed this, for example, when the atomics were added. I think I made changes too. I believe I automated this, but then wimped out and commented out one line. I'll report back later on this. I didn't want to diverge from the shell scripts, perhaps. I'll try to find some time here. I agree an upgrade from 5.8.6 to current is desirable. I go back and forth on this. I have likely broken it, and fixed it. For example, the mklib dependency on the Win32 headers. That should be ok now. For another potential example, the frontend can't use LONGINT until a release has it. But I think we have that now. We do not support going arbitrarily back, but the previous release is a good target. I have at times gone further back and fixed things up. You can also bootstrap via the cross mechanism even if you aren't crossing, but I suppose that is too difficult. Here: https://github.com/modula3/cm3/blob/master/scripts/python/upgrade.py 51 # 52 # ... and continue with the backend, if needed 53 # 54 55 a = Root + "/m3-sys/m3cggen/" + Target + "/m3cggen > " + Root + "/m3-sys/m3cc/gcc/gcc/m3cg/m3cg.h" 56 print(a) 57 # os.system(a) 58 FilterPackages([ "m3cc" ]) and DoPackage(argv_BuildShip, [ "m3cc" ]) uncomment out line 57. That is where I wimped out. That line should be there. Hopefully it is still correct.It is a little gross in that it outputs into the source tree.This really shouldn't be needed if you build correctly from a consistent checkout. It is only for when you have local edits.Even bootstrap/upgrade should not require it. The output should just match what is already there. And another thing: When I wrote upgrade.py, I thought I was mimicking upgrade.sh, and I mostly was. One thing I missed though was that upgrade.sh does actually build the entire system, whereas upgrade.py only builds the compiler. So consider this, somewhat overkill instead: cd scripts ./upgrade.py && ./do-cm3-all.py realclean skipgcc && ./do-cm3-all buildship skipgcc Also note that in-place updates are done while it goes. Certain errors force a need to go backwards. So you should maintain a backup of the minimum -- cm3, cm3.cfg, config directory, m3core, libm3, cm3cg. Or be able to restore from a release. That list is important, so I'll repeat: cm3, cm3.cfg, config directory in newer releases (cm3.cfg delegages to it), m3core, libm3, cm3cg (optional). To put this another way: consider the compiler itself to be a very portable and minimalist Modula-3 program. It has few dependencies and does most things itself. Consider the C program that just uses very little of the standard library but does use printf("main"). What do you need to build such things? You don't need, you know, a marshaling library, a windowing library etc., but you need a working compiler, frontend, backend, assembler, linker, and a minimal library That is what is required to a native upgrade. - Jay > Date: Thu, 28 May 2015 10:01:21 -0500 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > > > On 05/28/2015 06:49 AM, John Marino wrote: > > I got stuck again trying to build the latest on FreeBSD. > > > > 1. tar extracted to working directory along with a bootstrap compiler > > 2. CM3 and CM3_INSTALL defined in environment > > 3. executed scripts/python/upgrade.py > > > > result: > > http://leaf.dragonflybsd.org/~marino/m3.log > > > > I could guess that something is picking up a bootstrap component instead > > of a newly built one. > > Yes. > > >> m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > > means it is trying to compile using a new cm3cg backend and an old cm3 front end. > I just added this error message after Olaf had this problem. (Otherwise it would > have failed anyway, but with a less informative message.) > > > I guess it's trying to build the c backend? > > > > It finished the C backend and was trying to build m3core, using the inconsistent > compiler. Usually, neither cm3 nor cm3cg is copied to the bin directory, > even when doing a ship, in order to avoid this, which is an exception. For all > other executables, ship copies them to the bin directory. The shell script > scripts/install-cm3-compiler.sh is then run manually, after both cm3 and cm3cg > are compiled, to copy them to bin atomically (sort of). > > I don't know why that happened. I don't have experience with the Python scripts. > > Jay? > > Also, this script built the compiler before the support libraries m3core and > libm3. I think there may have been one bootstrap scenario where this was the > way it needed to be done, but usually it is the other way around--these two > libraries first. > > > > Am I doing some kind of obvious mistake? > > > > No, it's a bootstrap barrier. These pop up somewhat regularly. We all usually > just build from the most recent development build, which works for getting new > things tried out initially. But we need to make a habit of regularly rebuilding > from the previous release to flush these out. > > You might try scripts/do-cm3-front.sh realclean > scripts/do-cm3-front.sh buildship > > (I usually save /usr/local/cm3/bin/cm3 and /usr/local/cm3/bin/cm3cg at this point. > The step below does it somewhat redundantly, but only one level, unless the > version number changes.) > > scripts/install-cm3-compiler.sh upgrade. > > From here, you are using the new compiler. > > scripts/do-cm3-.sh buildship > > That this works, starting with the previous release compiler, is my criterion > for having removed bootstrap barriers. > > > > > John > > > > -- > Rodney Bates > rodney.m.bates at acm.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu May 28 22:13:24 2015 From: jay.krell at cornell.edu (Jay K) Date: Thu, 28 May 2015 20:13:24 +0000 Subject: [M3devel] 64bit INTEGERs, WIDECHAR: language specified or configuration/target dependent? In-Reply-To: <5567723D.3020706@elstel.org> References: <555E14BC.2040805@lcwb.coop> <555E203E.4040203@elstel.org>, , , <0A1CDD8C-EEB5-40E2-A38B-28E8EEA8C37E@elstel.org>, , <8A3AB2ED-C11E-4787-A7F8-C8F12157EAA5@elstel.org>, <555F6D8F.4070109@lcwb.coop>, <6F9B9534-7DC2-4D4D-88CB-90D7FA05E8F9@elstel.org>, <8BBBC94B-EECC-464A-86BB-FD1C94EC5496@elstel.org>, <77605189-D966-4D4B-8946-838BD6E178AA@purdue.edu>, <55675464.5090306@elstel.org>, <5567723D.3020706@elstel.org> Message-ID: 1) Ctypes.int 2) I wrapped everything anyway because the rewriting of /usr/include in m3core/unix was terribly tedious and error prone and a frequent source of problems.I favor size_t/INTEGER. The "direct" calls were not worth the trouble. I've debugged enough stack corruptions due to getting struct stat wrong there. 3) But not always, the Win32 and X windows stuff is still direct. INTEGER is not the only integer type, it is just kinda the default easiest to use if you must use one, use it.If you want to think more about it, there are more options. The 8 underlying types are all in there -- 8/16/32/64 unsigned and signed.Perhaps they should be exposes differently, like as INT8, UINT8, INT16, UINT16, INT32, UINT32, INT64, UINT64?Or int8_t, uint8_t, int16_t, uint16_t, etc.? Those types are all available to all programs, albeit in the WinNT and cstdint modules I believe. Not "global" like INTEGER. - Jay Date: Thu, 28 May 2015 21:53:33 +0200 From: estellnb at elstel.org To: hosking at purdue.edu CC: m3devel at elegosoft.com; jay.krell at cornell.edu; rodney.m.bates at acm.org Subject: Re: [M3devel] 64bit INTEGERs, WIDECHAR: language specified or configuration/target dependent? How for the hell do you interface with operating system services requiring a 32bit int when you only have the 64bit INTEGER?? Am 28.05.15 um 19:46 schrieb Elmar Stellnberger: Am 28.05.15 um 04:03 schrieb Antony Hosking: BYTESIZE(ADDRESS) = BYTESIZE(INTEGER) in cm3 on all target platforms. I don't really understand what you are proposing. on AMD64: BITSIZE(INTEGER) = BITSIZE(LONGINT) = 64bit I have just noticed that and when taking a practical standpoint - i.e. what really matters to new and old programs - this is a really bad decision which I wish to change for the next release. If you have not examined it yet please reclaim the design decisions for leaving int 32bit in C: However things turned out to be very different when the extension from 32bit to 64bit was at stake. There was no more gain by automatically extending the value ranges from 2^32 to 2^64 for 95% of all application purposes while the memory hierarchy has increasingly become a bottle neck in recent time. Additionally doubling the size of all integers would initially have doubled our memory needs which would have been a potential drawback for introducing the AMD64 arch. Just think of a machine with 4GB of RAM: It can not be addressed by 32bit (only ~3GB can) while making all INTS 64bit would have shrunken our memory to an effective size of 2GB. Luckily the decision was taken differently this time: * keep all ints of at most 32bit and just extend pointers to 64bit Same reasoning applies to Modula-3. - and I believe you have failed to notice when making your decisions for cm3 5.8.6. Or do you want to tell me that Modula-3 developers are more prudent than the C/C++ community? Even worse I have discovered the following: BITS 8 FOR INTEGER and BITS 32 FOR INTEGER do not work with cm3 5.8.6: :: BITS FOR size too small, must be at least (64) That will break existing legacy code when trying to compile it with cm3 5.8.6. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu May 28 22:29:44 2015 From: jay.krell at cornell.edu (Jay K) Date: Thu, 28 May 2015 20:29:44 +0000 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <55673AA4.8050100@marino.st> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop>,<55673AA4.8050100@marino.st> Message-ID: The build order in upgrade.py is correct. Since it is deliberately starting with whatever cm3 the user already has,it must also start deliberately with whatever m3core and libm3 the user already has.They go together. It builds a cm3 that uses the old m3core/libm3 (statically linked),and then rebuilds everything with itself, starting from m3core."everything" being only up to cm3/mklib, not the gui stuff, for example. Really in the past I've used this stuff a lot and I use the unedited checked in copy.There could be a problem building from the latest release, and that we should fix.The problem will likely be in m3front/m3back/m3link/m3quake, etc. The scripts should already be ok. The in-place nature of upgrade.py is perhaps not ideal. Esp. when it doesn't work.make-dist.py may be preferable. - Jay > Date: Thu, 28 May 2015 17:56:20 +0200 > From: adacore at marino.st > To: rodney.m.bates at acm.org; m3devel at elegosoft.com > Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > > On 5/28/2015 17:01, Rodney M. Bates wrote: > > I don't know why that happened. I don't have experience with the > > Python scripts. > > > > Jay? > > > > Also, this script built the compiler before the support libraries > > m3core and libm3. I think there may have been one bootstrap scenario > > where this was the way it needed to be done, but usually it is the > > other way around--these two libraries first. > > > >> Am I doing some kind of obvious mistake? > >> > > No, it's a bootstrap barrier. These pop up somewhat regularly. We > > all usually just build from the most recent development build, which > > works for getting new things tried out initially. But we need to > > make a habit of regularly rebuilding from the previous release to > > flush these out. > > Olaf said, IIUC, that the current code can't be built by the last > release compiler. Putting aside that I believe that should be a hard > requirement for the project, it sounds like maybe the last release can > build it if the build order is fixed (e.g. a better upgrade.py script)? > It's not clear to me what the real situation is. > > > > You might try scripts/do-cm3-front.sh realclean > > scripts/do-cm3-front.sh buildship > > > > (I usually save /usr/local/cm3/bin/cm3 and /usr/local/cm3/bin/cm3cg > > at this point. The step below does it somewhat redundantly, but only > > one level, unless the version number changes.) > > > > scripts/install-cm3-compiler.sh upgrade. > > From here, you are using the new compiler. > > scripts/do-cm3-.sh buildship > > > > That this works, starting with the previous release compiler, is my > > criterion for having removed bootstrap barriers. > > My work takes place within a Makefile and moving things in /usr/local > (for example) is actually illegal. Now I could do all this manually for > the purpose of building a new bootstrap, but as I mentioned in a > previous post, it might be more effective to emulate what you guy have > done: essentially build a series of bootstraps at strategic hashes until > I've acquired a compiler that can build this (and then use that product > as bootstrap for FreeBSD ports). > > If I did that approach, I could use a hint on the hashes to try... > > John -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu May 28 22:24:14 2015 From: jay.krell at cornell.edu (Jay K) Date: Thu, 28 May 2015 20:24:14 +0000 Subject: [M3devel] Too many names for the gcc backend. Was: m3cgc1: fatal error ... In-Reply-To: <55673174.80804@lcwb.coop> References: <556700B0.8060500@marino.st>,<55673174.80804@lcwb.coop> Message-ID: "1" is because gcc is structured as having the gcc "driver" and "frontends" like cc1 and cc1plus.cm3cg is a frontend from the gcc point of view. So it has/had a "1" in iis name.I believe we rename from m3cgc1 to cm3cg.The gcc backends are always linked into the frontends anyway -- libbackend.a.If this wasn't the case, they'd probably be called things like cc2. With Visual C++, for example, the "driver" is cl.exe and the frontends are c1.dll and c1xx.dll and the backend is c2.dll.Most compilers are structured in about the same way. Your .log: --- building in AMD64_FREEBSD --- ignoring ../src/m3overrides new source -> compiling RTHooks.i3 m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 compilation terminated. m3_backend => 1 > cp -Pv /mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a/m3-sys/cminstall/src/config-no-install/ALPHA32_VMS /mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a/bin/config/ALPHA32_VMS I think the problem is that upgrade wants to do things in-place, but you have asked to ship/install to a new place.It kind of does install while it builds. make-dist.py kinda does this better. It builds into a new place, but first copies from the old. Can you do that? Or, similarly, if you are building into a new empty place, can you add it to the start of $PATH, so as it fills in, it will take precedence? I understand this is all not ideal. The default method of "ugprade.py" building should be more like make-dist. The result should be a directory or .tar.gz that the user is told to copy or extract. No in-place updates ought to be done. make-dist.py is really better. Or, can you try make-dist.py?? Maybe if people use that a bit, we can delete upgrade and just point people at make-dist.py instead.It does "min" and "all". - Jay > Date: Thu, 28 May 2015 10:17:08 -0500 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: [M3devel] Too many names for the gcc backend. Was: m3cgc1: fatal error ... > > BTW, the gcc-derived back end has too many names. > > m3cc: The package name > m3cg: The directory containing glue code to gcc > m3cgc1: The executable built inside m3cc. > Also, what it identifies itself as in error messages > cm3cg: The executable, when installed in /usr/local/cm3/bin > > Did I even get it complete or right? > > On 05/28/2015 06:49 AM, John Marino wrote: > > I got stuck again trying to build the latest on FreeBSD. > > > > 1. tar extracted to working directory along with a bootstrap compiler > > 2. CM3 and CM3_INSTALL defined in environment > > 3. executed scripts/python/upgrade.py > > > > result: > > http://leaf.dragonflybsd.org/~marino/m3.log > > > > I could guess that something is picking up a bootstrap component instead > > of a newly built one. I guess it's trying to build the c backend? > > > > Am I doing some kind of obvious mistake? > > > > John > > > > -- > Rodney Bates > rodney.m.bates at acm.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Thu May 28 23:05:54 2015 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 28 May 2015 23:05:54 +0200 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> Message-ID: <20150528230554.80920c53f002da8beb3f29d0@elegosoft.com> On Thu, 28 May 2015 20:14:49 +0000 Jay K wrote: > > Also, this script built the compiler before the support libraries m3core and > > libm3. I think there may have been one bootstrap scenario where this was the > > way it needed to be done, but usually it is the other way around--these two > > libraries first. > > This is very deliberate and should always work, when doing a native upgrade. > It is true it is not always required. > When doing a "clean" cross build, it is true that it is backwards. > It is required when upgrading from an older build. > > Native upgrades start at least with a working compiler and its matching runtime. > Cross builds start with a working host compiler and nothing for the target -- so they do start with m3core. I've had a look at the build log, and I think the problem in this case with upgrade.py might be that it doesn't install the new backend, but only the new frontend: [...] Not shipping cm3cg. --- shipping from AMD64_FREEBSD --- missing ".M3SHIP" file, build the package first. dula3/work/bootstrap/bin/cm3 -build -DROOT=/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a +++ ==> /mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a/m3-sys/m3cc done +++ /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin/cm3 -ship -DROOT=/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a +++ ==> /mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a/m3-sys/m3cc done mkdir -p /mech/construction/mech/ptrees/default/lang/modula3/work/stage/usr/local/bin cp -Pv /mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a/m3-sys/cm3/AMD64_FREEBSD/cm3 /mech/construction/mech/ptrees/default/lang/modula3/work/stage/usr/local/bin/cm3 [...] In the upgrade.sh script I used install-cm3-compiler.sh, which always installs both. In m3-sys/m3cc/src/m3makefile I find the following code: if equal($INSTALL_CM3_IN_BIN, "yes") deriveds("", ["cm3cg", "cm3cg.exe"]) write ( "Forced ship of cm3cg." & CR) BindExport (AppendExeExtension ("cm3cg")) if DoMipsTfile BindExport ("mips-tfile") end else write ( "Not shipping cm3cg." & CR) end So perhaps simply setting INSTALL_CM3_IN_BIN=yes in the environment will fix that problem? Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From rodney_bates at lcwb.coop Thu May 28 23:56:06 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 28 May 2015 16:56:06 -0500 Subject: [M3devel] 64bit INTEGERs, WIDECHAR: language specified or configuration/target dependent? In-Reply-To: <20150528142158.GB19285@topoi.pooq.com> References: <0A1CDD8C-EEB5-40E2-A38B-28E8EEA8C37E@elstel.org> <8A3AB2ED-C11E-4787-A7F8-C8F12157EAA5@elstel.org> <555F6D8F.4070109@lcwb.coop> <6F9B9534-7DC2-4D4D-88CB-90D7FA05E8F9@elstel.org> <8BBBC94B-EECC-464A-86BB-FD1C94EC5496@elstel.org> <77605189-D966-4D4B-8946-838BD6E178AA@purdue.edu> <55675464.5090306@elstel.org> <20150528142158.GB19285@topoi.pooq.com> Message-ID: <55678EF6.4010108@lcwb.coop> On 05/28/2015 09:21 AM, Hendrik Boom wrote: > On Thu, May 28, 2015 at 07:46:12PM +0200, Elmar Stellnberger wrote: >> Am 28.05.15 um 04:03 schrieb Antony Hosking: >>> BYTESIZE(ADDRESS) = BYTESIZE(INTEGER) in cm3 on all target platforms. I don't really understand what you are proposing. >>> >> on AMD64: BITSIZE(INTEGER) = BITSIZE(LONGINT) = 64bit >> >> I have just noticed that and when taking a practical standpoint - >> i.e. what really matters to new and old programs - >> this is a really bad decision which I wish to change for the next release. >> >> If you have not examined it yet please reclaim the design decisions >> for leaving int 32bit in C: >> >> /However things turned out to be very different when the extension from >> 32bit to 64bit was at stake. There was no more gain by automatically >> extending the value ranges from 2^32 to 2^64 for 95% of all application >> purposes while the memory hierarchy has increasingly become a bottle >> neck in recent time. Additionally doubling the size of all integers would >> initially have doubled our memory needs which would have been a >> potential drawback for introducing the AMD64 arch. Just think of a machine >> with 4GB of RAM: It can not be addressed by 32bit (only ~3GB can) while >> making all INTS 64bit would have shrunken our memory to an effective size >> of 2GB. Luckily the decision was taken differently this time: >> >> * keep all ints of at most 32bit and just extend pointers to 64bit >> / >> >> Same reasoning applies to Modula-3. - and I believe you have failed >> to notice when >> making your decisions for cm3 5.8.6. Or do you want to tell me that >> Modula-3 >> developers are more prudent than the C/C++ community? >> >> Even worse I have discovered the following: >> BITS 8 FOR INTEGER and BITS 32 FOR INTEGER do not work with cm3 5.8.6: > > As I understand it from Rodney Bates' reply to my recent post, > BITS 8 FOR INTEGER should never have worked. BITS 32 FOR INTEGER > should work only if INTEGER is 32 bits wide. > Yes. >> >> :: BITS FOR size too small, must be at least (64) >> >> That will break existing legacy code when trying to compile it with >> cm3 5.8.6. > -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Fri May 29 00:15:35 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 28 May 2015 17:15:35 -0500 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> Message-ID: <55679387.8040701@lcwb.coop> On 05/28/2015 12:06 PM, Olaf Wagner wrote: > On Thu, 28 May 2015 17:56:20 +0200 > John Marino wrote: > >> On 5/28/2015 17:01, Rodney M. Bates wrote: >>> I don't know why that happened. I don't have experience with the >>> Python scripts. >>> >>> Jay? >>> >>> Also, this script built the compiler before the support libraries >>> m3core and libm3. I think there may have been one bootstrap scenario >>> where this was the way it needed to be done, but usually it is the >>> other way around--these two libraries first. >>> >>>> Am I doing some kind of obvious mistake? >>>> >>> No, it's a bootstrap barrier. These pop up somewhat regularly. We >>> all usually just build from the most recent development build, which >>> works for getting new things tried out initially. But we need to >>> make a habit of regularly rebuilding from the previous release to >>> flush these out. >> >> Olaf said, IIUC, that the current code can't be built by the last >> release compiler. Putting aside that I believe that should be a hard >> requirement for the project, it sounds like maybe the last release can >> build it if the build order is fixed (e.g. a better upgrade.py script)? >> It's not clear to me what the real situation is. > > No, this is a misunderstanding. I just said or tried to say that there > is no script (yet) that is smart enough to do all the things necessary to > build the current compiler on base of 5.8.6. > >>> You might try scripts/do-cm3-front.sh realclean >>> scripts/do-cm3-front.sh buildship >>> >>> (I usually save /usr/local/cm3/bin/cm3 and /usr/local/cm3/bin/cm3cg >>> at this point. The step below does it somewhat redundantly, but only >>> one level, unless the version number changes.) >>> >>> scripts/install-cm3-compiler.sh upgrade. >>> From here, you are using the new compiler. >>> scripts/do-cm3-.sh buildship >>> >>> That this works, starting with the previous release compiler, is my >>> criterion for having removed bootstrap barriers. > > Rodney, have you really tried that? I'm not sure the steps above will > work. I had the feeling that we're missing some intermediate releases, but > I might be wrong there. > I have done it a number of times for AMD64_LINUX and LINUXLIBC6, using the last release compiler, and successfully building a development compiler, for several different development snapshots. The last time was probably a few months ago, and I don't think much has happened in the compiler and library packages that would make them not compile. It will take a me a little time, but I will try it again on these platforms. >> My work takes place within a Makefile and moving things in /usr/local >> (for example) is actually illegal. Now I could do all this manually for >> the purpose of building a new bootstrap, but as I mentioned in a >> previous post, it might be more effective to emulate what you guy have >> done: essentially build a series of bootstraps at strategic hashes until >> I've acquired a compiler that can build this (and then use that product >> as bootstrap for FreeBSD ports). >> >> If I did that approach, I could use a hint on the hashes to try... > > We should be able to script something that sets up the current compiler > at least on a given specific platform with a well-defined environment. > I might be able to offer more help in the second week of June, if you > can wait until then. > > Olaf > -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Fri May 29 00:17:48 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 28 May 2015 17:17:48 -0500 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <55673AA4.8050100@marino.st> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> Message-ID: <5567940C.6080409@lcwb.coop> On 05/28/2015 10:56 AM, John Marino wrote: > On 5/28/2015 17:01, Rodney M. Bates wrote: >> I don't know why that happened. I don't have experience with the >> Python scripts. >> >> Jay? >> >> Also, this script built the compiler before the support libraries >> m3core and libm3. I think there may have been one bootstrap scenario >> where this was the way it needed to be done, but usually it is the >> other way around--these two libraries first. >> >>> Am I doing some kind of obvious mistake? >>> >> No, it's a bootstrap barrier. These pop up somewhat regularly. We >> all usually just build from the most recent development build, which >> works for getting new things tried out initially. But we need to >> make a habit of regularly rebuilding from the previous release to >> flush these out. > > Olaf said, IIUC, that the current code can't be built by the last > release compiler. Putting aside that I believe that should be a hard > requirement for the project, it sounds like maybe the last release can > build it if the build order is fixed (e.g. a better upgrade.py script)? > It's not clear to me what the real situation is. > > >> You might try scripts/do-cm3-front.sh realclean >> scripts/do-cm3-front.sh buildship >> >> (I usually save /usr/local/cm3/bin/cm3 and /usr/local/cm3/bin/cm3cg >> at this point. The step below does it somewhat redundantly, but only >> one level, unless the version number changes.) >> >> scripts/install-cm3-compiler.sh upgrade. >> From here, you are using the new compiler. >> scripts/do-cm3-.sh buildship >> >> That this works, starting with the previous release compiler, is my >> criterion for having removed bootstrap barriers. > > My work takes place within a Makefile and moving things in /usr/local > (for example) is actually illegal. Now I could do all this manually for > the purpose of building a new bootstrap, but as I mentioned in a > previous post, it might be more effective to emulate what you guy have > done: essentially build a series of bootstraps at strategic hashes until > I've acquired a compiler that can build this (and then use that product > as bootstrap for FreeBSD ports). I don't think that will be necessary. Give me a few days. > > If I did that approach, I could use a hint on the hashes to try... > > John > -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Fri May 29 00:25:19 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 28 May 2015 17:25:19 -0500 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <556722B3.7080209@marino.st> References: <556700B0.8060500@marino.st> <20150528160221.95d4c26d83f68f8cfa93d75a@elego.de> <556722B3.7080209@marino.st> Message-ID: <556795CF.7090409@lcwb.coop> On 05/28/2015 09:14 AM, John Marino wrote: > On 5/28/2015 16:02, Olaf Wagner wrote: >> On Thu, 28 May 2015 13:49:04 +0200 >> John Marino wrote: >>> Am I doing some kind of obvious mistake? >> >> No. I think upgrade.sh (or .py) cannot really cope with updating a 5.8.6 >> instance to the current state. It took me several days, too, on >> MacOS X, and I had to do a lot of manual tweaking and copying >> around. I don't think any casual user will understand the details > > That's a pretty big sin given how 5.8.6 is the current release! > I am in adamant agreement with you here. I periodically interrupt things to go back and prove I can build the development version from the last release. In the process, I have discovered and fixed several bootstrap barriers in the past. I really think it is a build process problem. > >> IMO the best thing we can do now is provide some more up-to-date >> binary archives (I'll upload my own stuff as soon as I find the time). >> A newer release has been missing for several years, and the existing >> scripts are no great help for new users. > > Is there a git tag that can build from 5.8.6? Maybe I just have to keep > doing this until I get a new bootstrap that can do it. > > John > -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Fri May 29 00:54:32 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 28 May 2015 17:54:32 -0500 Subject: [M3devel] 64bit INTEGERs, WIDECHAR: language specified or configuration/target dependent? In-Reply-To: <5567723D.3020706@elstel.org> References: <555E14BC.2040805@lcwb.coop> <555E203E.4040203@elstel.org> <0A1CDD8C-EEB5-40E2-A38B-28E8EEA8C37E@elstel.org> <8A3AB2ED-C11E-4787-A7F8-C8F12157EAA5@elstel.org> <555F6D8F.4070109@lcwb.coop> <6F9B9534-7DC2-4D4D-88CB-90D7FA05E8F9@elstel.org> <8BBBC94B-EECC-464A-86BB-FD1C94EC5496@elstel.org> <77605189-D966-4D4B-8946-838BD6E178AA@purdue.edu> <55675464.5090306@elstel.org> <5567723D.3020706@elstel.org> Message-ID: <55679CA8.2030905@lcwb.coop> On 05/28/2015 02:53 PM, Elmar Stellnberger wrote: > > How for the hell do you interface with operating system services requiring a 32bit int when you only have the 64bit INTEGER?? > Use subranges. Just declare its type [-16_7fffffff-1 .. 16_7fffffff]. Our compiler will allocate nice round bit sizes for everything that isn't BITS n FOR ... . And if it is BITS ..., just use the same subrange type, as above, then use BITS 32 FOR ... . But remember BITS has no effect except when it's an array element or record/object field. It's the subrange, not the BITS spec that determines the range. The language reference doesn't constrain the allocated size, but I'm skeptical about adding things like that to the language. Interfacing with another language is low-level programming, and specifying all the things in that category would be huge and overconstrain the language. Well, maybe not stack variables, if the stack has a bigger alignment to be honored, quite possibly a hardware requirement. No doubt taking and using the address of such would be endian-dependent. Would a C compiler do differently in this case? Can you rely on them all doing it the same? Does C specify it? > Am 28.05.15 um 19:46 schrieb Elmar Stellnberger: >> Am 28.05.15 um 04:03 schrieb Antony Hosking: >>> BYTESIZE(ADDRESS) = BYTESIZE(INTEGER) in cm3 on all target platforms. I don't really understand what you are proposing. >>> >> on AMD64: BITSIZE(INTEGER) = BITSIZE(LONGINT) = 64bit >> >> I have just noticed that and when taking a practical standpoint - i.e. what really matters to new and old programs - >> this is a really bad decision which I wish to change for the next release. >> >> If you have not examined it yet please reclaim the design decisions for leaving int 32bit in C: >> /However things turned out to be very different when the extension from >> 32bit to 64bit was at stake. There was no more gain by automatically >> extending the value ranges from 2^32 to 2^64 for 95% of all application >> purposes while the memory hierarchy has increasingly become a bottle >> neck in recent time. Additionally doubling the size of all integers would >> initially have doubled our memory needs which would have been a >> potential drawback for introducing the AMD64 arch. Just think of a machine >> with 4GB of RAM: It can not be addressed by 32bit (only ~3GB can) while >> making all INTS 64bit would have shrunken our memory to an effective size >> of 2GB. Luckily the decision was taken differently this time: >> >> * keep all ints of at most 32bit and just extend pointers to 64bit >> / >> Same reasoning applies to Modula-3. - and I believe you have failed to notice when >> making your decisions for cm3 5.8.6. Or do you want to tell me that Modula-3 >> developers are more prudent than the C/C++ community? >> >> Even worse I have discovered the following: >> BITS 8 FOR INTEGER and BITS 32 FOR INTEGER do not work with cm3 5.8.6: >> >> :: BITS FOR size too small, must be at least (64) >> >> That will break existing legacy code when trying to compile it with cm3 5.8.6. > -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Fri May 29 05:18:36 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 28 May 2015 22:18:36 -0500 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <55679387.8040701@lcwb.coop> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> Message-ID: <5567DA8C.3050802@lcwb.coop> On 05/28/2015 05:15 PM, Rodney M. Bates wrote: > > > On 05/28/2015 12:06 PM, Olaf Wagner wrote: >> On Thu, 28 May 2015 17:56:20 +0200 >> John Marino wrote: >> >>> On 5/28/2015 17:01, Rodney M. Bates wrote: >>>> I don't know why that happened. I don't have experience with the >>>> Python scripts. >>>> >>>> Jay? >>>> >>>> Also, this script built the compiler before the support libraries >>>> m3core and libm3. I think there may have been one bootstrap scenario >>>> where this was the way it needed to be done, but usually it is the >>>> other way around--these two libraries first. >>>> >>>>> Am I doing some kind of obvious mistake? >>>>> >>>> No, it's a bootstrap barrier. These pop up somewhat regularly. We >>>> all usually just build from the most recent development build, which >>>> works for getting new things tried out initially. But we need to >>>> make a habit of regularly rebuilding from the previous release to >>>> flush these out. >>> >>> Olaf said, IIUC, that the current code can't be built by the last >>> release compiler. Putting aside that I believe that should be a hard >>> requirement for the project, it sounds like maybe the last release can >>> build it if the build order is fixed (e.g. a better upgrade.py script)? >>> It's not clear to me what the real situation is. >> >> No, this is a misunderstanding. I just said or tried to say that there >> is no script (yet) that is smart enough to do all the things necessary to >> build the current compiler on base of 5.8.6. >> >>>> You might try scripts/do-cm3-front.sh realclean >>>> scripts/do-cm3-front.sh buildship >>>> >>>> (I usually save /usr/local/cm3/bin/cm3 and /usr/local/cm3/bin/cm3cg >>>> at this point. The step below does it somewhat redundantly, but only >>>> one level, unless the version number changes.) >>>> >>>> scripts/install-cm3-compiler.sh upgrade. >>>> From here, you are using the new compiler. >>>> scripts/do-cm3-.sh buildship >>>> >>>> That this works, starting with the previous release compiler, is my >>>> criterion for having removed bootstrap barriers. >> >> Rodney, have you really tried that? I'm not sure the steps above will >> work. I had the feeling that we're missing some intermediate releases, but >> I might be wrong there. >> > > I have done it a number of times for AMD64_LINUX and LINUXLIBC6, using the > last release compiler, and successfully building a development compiler, > for several different development snapshots. The last time was probably > a few months ago, and I don't think much has happened in the compiler > and library packages that would make them not compile. It will take a > me a little time, but I will try it again on these platforms. > OK, this is working for me on LINUXLIBC6. With the release compiler installed: $ cm3 -version Critical Mass Modula-3 version 5.8.6 last updated: 2010-04-11 compiled: 2013-09-13 21:38:06 configuration: /usr/local/cm3/bin/cm3.cfg host: AMD64_LINUX target: AMD64_LINUX And a freshly pulled git repository from github, in cm3/scripts: 1) $ ./do-cm3-all.sh realclean #Clean everything 2) $ ./do-cm3-front.sh buildship #Build a compiler & its support libraries All compiles succeeded. 4) $ ./install-cm3-compiler.sh upgrade # Install the compiler $ cm3 -version Critical Mass Modula-3 version d5.10.0 last updated: 2015-05-21 compiled: 2015-05-29 02:54:41 configuration: /usr/local/cm3/bin/cm3.cfg host: AMD64_LINUX target: AMD64_LINUX Now repeat steps 1 and 2. This will use the newly compiled head compiler. to rebuild itself. All compiles succeeded. Finally, $./do-cm3-all.sh buildship #Build the rest. This compiles all the remaining stuff, none of which is involved in bootstrapping. All compiles succeeded. In the past, I often will install the second-time-compiled head compiler and do it all a third time. After getting this far, this has never failed, and I didn't do it this time. New package libunicode uses an addition to Compiler.i3 that is not in the release, so you have to install the new compiler before compiling libunicode. >>> My work takes place within a Makefile and moving things in /usr/local >>> (for example) is actually illegal. Now I could do all this manually for >>> the purpose of building a new bootstrap, but as I mentioned in a >>> previous post, it might be more effective to emulate what you guy have >>> done: essentially build a series of bootstraps at strategic hashes until >>> I've acquired a compiler that can build this (and then use that product >>> as bootstrap for FreeBSD ports). >>> >>> If I did that approach, I could use a hint on the hashes to try... >> >> We should be able to script something that sets up the current compiler >> at least on a given specific platform with a well-defined environment. >> I might be able to offer more help in the second week of June, if you >> can wait until then. >> >> Olaf >> > -- Rodney Bates rodney.m.bates at acm.org From wagner at elegosoft.com Fri May 29 08:57:50 2015 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 29 May 2015 08:57:50 +0200 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <5567DA8C.3050802@lcwb.coop> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop> Message-ID: <20150529085750.0a8f9e2c62f01c2a0d1be4ca@elegosoft.com> On Thu, 28 May 2015 22:18:36 -0500 "Rodney M. Bates" wrote: > On 05/28/2015 05:15 PM, Rodney M. Bates wrote: > > > > On 05/28/2015 12:06 PM, Olaf Wagner wrote: > >> On Thu, 28 May 2015 17:56:20 +0200 > >> John Marino wrote: > >> > >>> On 5/28/2015 17:01, Rodney M. Bates wrote: > >>>> I don't know why that happened. I don't have experience with the > >>>> Python scripts. > >>>> > >>>> Jay? > >>>> > >>>> Also, this script built the compiler before the support libraries > >>>> m3core and libm3. I think there may have been one bootstrap scenario > >>>> where this was the way it needed to be done, but usually it is the > >>>> other way around--these two libraries first. > >>>> > >>>>> Am I doing some kind of obvious mistake? > >>>>> > >>>> No, it's a bootstrap barrier. These pop up somewhat regularly. We > >>>> all usually just build from the most recent development build, which > >>>> works for getting new things tried out initially. But we need to > >>>> make a habit of regularly rebuilding from the previous release to > >>>> flush these out. > >>> > >>> Olaf said, IIUC, that the current code can't be built by the last > >>> release compiler. Putting aside that I believe that should be a hard > >>> requirement for the project, it sounds like maybe the last release can > >>> build it if the build order is fixed (e.g. a better upgrade.py script)? > >>> It's not clear to me what the real situation is. > >> > >> No, this is a misunderstanding. I just said or tried to say that there > >> is no script (yet) that is smart enough to do all the things necessary to > >> build the current compiler on base of 5.8.6. > >> > >>>> You might try scripts/do-cm3-front.sh realclean > >>>> scripts/do-cm3-front.sh buildship > >>>> > >>>> (I usually save /usr/local/cm3/bin/cm3 and /usr/local/cm3/bin/cm3cg > >>>> at this point. The step below does it somewhat redundantly, but only > >>>> one level, unless the version number changes.) > >>>> > >>>> scripts/install-cm3-compiler.sh upgrade. > >>>> From here, you are using the new compiler. > >>>> scripts/do-cm3-.sh buildship > >>>> > >>>> That this works, starting with the previous release compiler, is my > >>>> criterion for having removed bootstrap barriers. > >> > >> Rodney, have you really tried that? I'm not sure the steps above will > >> work. I had the feeling that we're missing some intermediate releases, but > >> I might be wrong there. > >> > > > > I have done it a number of times for AMD64_LINUX and LINUXLIBC6, using the > > last release compiler, and successfully building a development compiler, > > for several different development snapshots. The last time was probably > > a few months ago, and I don't think much has happened in the compiler > > and library packages that would make them not compile. It will take a > > me a little time, but I will try it again on these platforms. > > > > OK, this is working for me on LINUXLIBC6. > > With the release compiler installed: > > $ cm3 -version > Critical Mass Modula-3 version 5.8.6 > last updated: 2010-04-11 > compiled: 2013-09-13 21:38:06 > configuration: /usr/local/cm3/bin/cm3.cfg > host: AMD64_LINUX > target: AMD64_LINUX > > And a freshly pulled git repository from github, > in cm3/scripts: > > 1) $ ./do-cm3-all.sh realclean #Clean everything > 2) $ ./do-cm3-front.sh buildship #Build a compiler & its support libraries > > All compiles succeeded. > > 4) $ ./install-cm3-compiler.sh upgrade # Install the compiler > > $ cm3 -version > Critical Mass Modula-3 version d5.10.0 > last updated: 2015-05-21 > compiled: 2015-05-29 02:54:41 > configuration: /usr/local/cm3/bin/cm3.cfg > host: AMD64_LINUX > target: AMD64_LINUX > > Now repeat steps 1 and 2. This will use the newly compiled head compiler. > to rebuild itself. All compiles succeeded. > > Finally, $./do-cm3-all.sh buildship #Build the rest. > > This compiles all the remaining stuff, none of which is involved in bootstrapping. > All compiles succeeded. > > In the past, I often will install the second-time-compiled head compiler and > do it all a third time. After getting this far, this has never failed, and > I didn't do it this time. > > New package libunicode uses an addition to Compiler.i3 that is not in the release, so > you have to install the new compiler before compiling libunicode. Great. So the situation is better than I assumed after my struggles a week ago. Thanks for verifying that. Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From adacore at marino.st Fri May 29 09:39:13 2015 From: adacore at marino.st (John Marino) Date: Fri, 29 May 2015 09:39:13 +0200 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <5567DA8C.3050802@lcwb.coop> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop> Message-ID: <556817A1.2090206@marino.st> On 5/29/2015 05:18, Rodney M. Bates wrote: > OK, this is working for me on LINUXLIBC6. > > With the release compiler installed: > > $ cm3 -version > Critical Mass Modula-3 version 5.8.6 > last updated: 2010-04-11 > compiled: 2013-09-13 21:38:06 > configuration: /usr/local/cm3/bin/cm3.cfg > host: AMD64_LINUX > target: AMD64_LINUX > > And a freshly pulled git repository from github, > in cm3/scripts: > > 1) $ ./do-cm3-all.sh realclean #Clean everything > 2) $ ./do-cm3-front.sh buildship #Build a compiler & its support libraries > > All compiles succeeded. At first I was thinking "this is kind of horrible" until I realized that this is pretty much what the former boot-cm3-with-m3.sh script was doing. I figured out a way to incorporate this technique into the port's makefile. Unfortunately, I can't say I found success. # /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin/cm3 -version Critical Mass Modula-3 version 5.8.6 last updated: 2010-04-11 compiled: 2014-01-02 01:01:20 configuration: /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin/cm3.cfg host: AMD64_FREEBSD target: AMD64_FREEBSD I am seeing the same exact m3cg version stamp errors as I saw on the python upgrade script. Here's my build log so you can verify I followed the procedure: http://leaf.dragonflybsd.org/~marino/m3a.log I don't know it would work for you on linux but not me on FreeBSD ... John From wagner at elego.de Fri May 29 10:54:51 2015 From: wagner at elego.de (Olaf Wagner) Date: Fri, 29 May 2015 10:54:51 +0200 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <556817A1.2090206@marino.st> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop> <556817A1.2090206@marino.st> Message-ID: <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de> On Fri, 29 May 2015 09:39:13 +0200 John Marino wrote: > On 5/29/2015 05:18, Rodney M. Bates wrote: > > OK, this is working for me on LINUXLIBC6. > > > > With the release compiler installed: > > > > $ cm3 -version > > Critical Mass Modula-3 version 5.8.6 > > last updated: 2010-04-11 > > compiled: 2013-09-13 21:38:06 > > configuration: /usr/local/cm3/bin/cm3.cfg > > host: AMD64_LINUX > > target: AMD64_LINUX > > > > And a freshly pulled git repository from github, > > in cm3/scripts: > > > > 1) $ ./do-cm3-all.sh realclean #Clean everything > > 2) $ ./do-cm3-front.sh buildship #Build a compiler & its support libraries > > > > All compiles succeeded. > > At first I was thinking "this is kind of horrible" until I realized that > this is pretty much what the former boot-cm3-with-m3.sh script was > doing. I figured out a way to incorporate this technique into the > port's makefile. Unfortunately, I can't say I found success. > > # > /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin/cm3 > -version > > Critical Mass Modula-3 version 5.8.6 > last updated: 2010-04-11 > compiled: 2014-01-02 01:01:20 > configuration: > /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin/cm3.cfg > host: AMD64_FREEBSD > target: AMD64_FREEBSD > > > I am seeing the same exact m3cg version stamp errors as I saw on the > python upgrade script. Here's my build log so you can verify I followed > the procedure: > > http://leaf.dragonflybsd.org/~marino/m3a.log > > I don't know it would work for you on linux but not me on FreeBSD ... Please try what I suggested in the attached mail: define INSTALL_CM3_IN_BIN=yes in the environment and see if that helps. Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -------------- next part -------------- An embedded message was scrubbed... From: Olaf Wagner Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 Date: Thu, 28 May 2015 23:05:54 +0200 Size: 3481 URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From adacore at marino.st Fri May 29 11:10:50 2015 From: adacore at marino.st (John Marino) Date: Fri, 29 May 2015 11:10:50 +0200 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop> <556817A1.2090206@marino.st> <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de> Message-ID: <55682D1A.2030504@marino.st> On 5/29/2015 10:54, Olaf Wagner wrote: > Please try what I suggested in the attached mail: define > INSTALL_CM3_IN_BIN=yes > in the environment and see if that helps. > Unfortunately it seems the result is exactly the same, even when INSTALL_CM3_IN_BIN is defined in the environment. John From wagner at elego.de Fri May 29 11:39:35 2015 From: wagner at elego.de (Olaf Wagner) Date: Fri, 29 May 2015 11:39:35 +0200 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <55682D1A.2030504@marino.st> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop> <556817A1.2090206@marino.st> <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de> <55682D1A.2030504@marino.st> Message-ID: <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de> On Fri, 29 May 2015 11:10:50 +0200 John Marino wrote: > On 5/29/2015 10:54, Olaf Wagner wrote: > > Please try what I suggested in the attached mail: define > > INSTALL_CM3_IN_BIN=yes > > in the environment and see if that helps. > > > > Unfortunately it seems the result is exactly the same, even when > INSTALL_CM3_IN_BIN is defined in the environment. Can I see the new logs? Has the new backend (cm3cg) been installed now? Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From adacore at marino.st Fri May 29 11:51:05 2015 From: adacore at marino.st (John Marino) Date: Fri, 29 May 2015 11:51:05 +0200 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop> <556817A1.2090206@marino.st> <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de> <55682D1A.2030504@marino.st> <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de> Message-ID: <55683689.2090709@marino.st> On 5/29/2015 11:39, Olaf Wagner wrote: > On Fri, 29 May 2015 11:10:50 +0200 > John Marino wrote: > >> On 5/29/2015 10:54, Olaf Wagner wrote: >>> Please try what I suggested in the attached mail: define >>> INSTALL_CM3_IN_BIN=yes >>> in the environment and see if that helps. >>> >> >> Unfortunately it seems the result is exactly the same, even when >> INSTALL_CM3_IN_BIN is defined in the environment. > > Can I see the new logs? Has the new backend (cm3cg) been installed now? > It's here: http://leaf.dragonflybsd.org/~marino/m3c.log It never completes "do-cm3-front.sh buildship " Note that I'm using a bootstrap install and set INSTALL_ROOT to another location, but it never gets to the point of installing anything. John From wagner at elego.de Fri May 29 12:27:32 2015 From: wagner at elego.de (Olaf Wagner) Date: Fri, 29 May 2015 12:27:32 +0200 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <55683689.2090709@marino.st> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop> <556817A1.2090206@marino.st> <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de> <55682D1A.2030504@marino.st> <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de> <55683689.2090709@marino.st> Message-ID: <20150529122732.1396eb079ff9b404bcb21e40@elego.de> On Fri, 29 May 2015 11:51:05 +0200 John Marino wrote: > On 5/29/2015 11:39, Olaf Wagner wrote: > > On Fri, 29 May 2015 11:10:50 +0200 > > John Marino wrote: > > > >> On 5/29/2015 10:54, Olaf Wagner wrote: > >>> Please try what I suggested in the attached mail: define > >>> INSTALL_CM3_IN_BIN=yes > >>> in the environment and see if that helps. > >>> > >> > >> Unfortunately it seems the result is exactly the same, even when > >> INSTALL_CM3_IN_BIN is defined in the environment. > > > > Can I see the new logs? Has the new backend (cm3cg) been installed now? > > > It's here: > http://leaf.dragonflybsd.org/~marino/m3c.log > > It never completes "do-cm3-front.sh buildship " > > Note that I'm using a bootstrap install and set INSTALL_ROOT to another > location, but it never gets to the point of installing anything. It now has shipped the new gcc-backend as expected, but that doesn't seem to be the problem :-( I'm afraid I'll have to reproduce your setup locally on my FreeBSD system at home, as I don't see the wrong step in the logs 8-| After Rodney's success on Linux I was hoping that everything still just worked as some years ago. Just to make sure: you start with a 5.8.6 release archive for AMD64_FREEBSD, install that, check out the git sources, and run the script(s) in the checked-out repository, correct? Or did I miss anything? Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From adacore at marino.st Fri May 29 12:40:29 2015 From: adacore at marino.st (John Marino) Date: Fri, 29 May 2015 12:40:29 +0200 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <20150529122732.1396eb079ff9b404bcb21e40@elego.de> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop> <556817A1.2090206@marino.st> <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de> <55682D1A.2030504@marino.st> <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de> <55683689.2090709@marino.st> <20150529122732.1396eb079ff9b404bcb21e40@elego.de> Message-ID: <5568421D.3050209@marino.st> On 5/29/2015 12:27, Olaf Wagner wrote: > > I'm afraid I'll have to reproduce your setup locally on my FreeBSD > system at home, as I don't see the wrong step in the logs 8-| > > After Rodney's success on Linux I was hoping that everything still > just worked as some years ago. > > Just to make sure: you start with a 5.8.6 release archive for > AMD64_FREEBSD, install that, check out the git sources, and > run the script(s) in the checked-out repository, correct? Or > did I miss anything? I maintain the "port" for M3 on FreeBSD. see here: http://www.freshports.org/lang/modula3 Because I'm building these in ports, there are certain "rules" I have to follow using makefiles. I've attached the in-work "port" that I'm using. You can "rm -rf /usr/ports/lang/modula3; cd /usr/ports/lang; tar -xf m3-port.tar.gz" to use it to reproduce what I'm doing. All you'd do to reproduce is: "cd /usr/ports/lang/modula3 ; make build" To be more specific, the current repo is downloaded from github as a tarball along with the bootstrap compiler (only once, then the tarball is reused on subsequent). Then it tries to build a new bootstrap compiler in the build target and that's where it's failing. Regards, John -------------- next part -------------- A non-text attachment was scrubbed... Name: m3-port.tar.gz Type: application/x-gzip Size: 3344 bytes Desc: not available URL: From jay.krell at cornell.edu Fri May 29 13:22:15 2015 From: jay.krell at cornell.edu (Jay K) Date: Fri, 29 May 2015 11:22:15 +0000 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <20150528230554.80920c53f002da8beb3f29d0@elegosoft.com> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop>, , <20150528230554.80920c53f002da8beb3f29d0@elegosoft.com> Message-ID: > if equal($INSTALL_CM3_IN_BIN, "yes") Hm. That is relatively new. Rodney, This is a mistake: https://github.com/modula3/cm3/commit/1994f950bb30c3021fd24c07a555f0f7bace933f I see you commented it heavily, but we had working automation before that this broke. The automation already took into account what you were trying to take into account. I agree having the config search all over, which I did, is not good, as it undermines attempts to ship at just the right time. If you don't want to ship cm3cg, then don't run cm3 -ship for it. cm3cg is not actually running when cm3 -ship is run. The reasons cm3 doesn't ship itself do not apply. I agree it seems tempting to sync this behavior with the behavior of shipping cm3. But I don't think it should be. Yes the files have to be updated together. You do that by shipping cm3cg and somehow otherwise copying cm3. I agree that having this "somehow otherwise copy" is not great. I wonder if we can remove that though. The reason cm3 ship is disabled by default is not so that things are updated together, but because having an executable copy over itself reportedly does not work on some operating systems. It is nothing to do with our need to copy multiple files automatically. It is because it will fail. Now..I must say..Windows is extremely often labeled as one of these systems. Countless people believe this myth. But it isn't true. You can copy over an "in use" .dll or .exe. You merely have to rename it away first. Yes, that is still a bit wierd. And I have to investigate how to eventually delete it. Yes, there is a way to defer the delete..until a reboot..if you are an administrator.. but that is clearly an inadequate mechanism. It is quite possible you open with delete_on_close, and close, and then the last close might do it, when the .exe stops running. We should try this out. However, with Windows possibly eliminated as a concern (once ship does the rename, which it doesn't currently), does that leave other systems? AIX I believe is similar..that a direct copy will fail. But will rename work around it there too? Should we let cm3 be able to ship itself, and see what comes of it? Like, maybe every system people really use can do it? When an AIX user speaks up, we can fix it then?? Either way, I believe this change to m3cc/src/m3makefile should be undone. In the meantime, everyone can workaround it by setting the environment variable. The other angle, which I've been pushing unsuccessfully is never update in place. That is portable. Start with a new empty directory tree and fill it in by shipping, even cm3. Like make-dist.py does. One wrinkle here is that cm3, if it doesn't already, must favor looking next to itself, and not searching $PATH. So that you ship cm3cg to the new place, and then cm3, and cm3 shipping second finishes the transaction (ok, you'd also copy/ship other files, like configs and m3core/libm3, and then cm3 last). I would really really like that code for an executable to find its full path, on all supported systems. I don't think Posix can do it. Win32 GetModuleFileName(NULL or &__ImageBase) for example. Then strip off the last path element and append stuff, to find things you go with. It is a nice technique. I'm leary of techniques that rely on $PATH search or applying argv[0] to getcwd, as the current directory can change at any time. (and another unsuccessful angle is to move away from all the .sh files; I've been using the .py files for years...well, I was...) - Jay > Date: Thu, 28 May 2015 23:05:54 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: rodney.m.bates at acm.org; m3devel at elegosoft.com; adacore at marino.st > Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > > On Thu, 28 May 2015 20:14:49 +0000 > Jay K wrote: > > > > Also, this script built the compiler before the support libraries m3core and > > > libm3. I think there may have been one bootstrap scenario where this was the > > > way it needed to be done, but usually it is the other way around--these two > > > libraries first. > > > > This is very deliberate and should always work, when doing a native upgrade. > > It is true it is not always required. > > When doing a "clean" cross build, it is true that it is backwards. > > It is required when upgrading from an older build. > > > > Native upgrades start at least with a working compiler and its matching runtime. > > Cross builds start with a working host compiler and nothing for the target -- so they do start with m3core. > > I've had a look at the build log, and I think the problem in this case > with upgrade.py might be that it doesn't install the new backend, but > only the new frontend: > > [...] > Not shipping cm3cg. > --- shipping from AMD64_FREEBSD --- > > missing ".M3SHIP" file, build the package first. > dula3/work/bootstrap/bin/cm3 -build -DROOT=/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a +++ > ==> /mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a/m3-sys/m3cc done > > +++ /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin/cm3 -ship -DROOT=/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a +++ > ==> /mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a/m3-sys/m3cc done > > mkdir -p /mech/construction/mech/ptrees/default/lang/modula3/work/stage/usr/local/bin > cp -Pv /mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a/m3-sys/cm3/AMD64_FREEBSD/cm3 /mech/construction/mech/ptrees/default/lang/modula3/work/stage/usr/local/bin/cm3 > [...] > > In the upgrade.sh script I used install-cm3-compiler.sh, which always > installs both. In m3-sys/m3cc/src/m3makefile I find the following code: > > if equal($INSTALL_CM3_IN_BIN, "yes") > deriveds("", ["cm3cg", "cm3cg.exe"]) > write ( "Forced ship of cm3cg." & CR) > BindExport (AppendExeExtension ("cm3cg")) > if DoMipsTfile > BindExport ("mips-tfile") > end > else > write ( "Not shipping cm3cg." & CR) > end > > So perhaps simply setting INSTALL_CM3_IN_BIN=yes in the environment > will fix that problem? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri May 29 13:42:32 2015 From: jay.krell at cornell.edu (Jay K) Date: Fri, 29 May 2015 11:42:32 +0000 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop>, , , , <20150528230554.80920c53f002da8beb3f29d0@elegosoft.com>, Message-ID: > One wrinkle here is that cm3, if it doesn't already, must favor looking next to itself, and not searching $PATH. dladdr appears to be the answer. It appears to be supported on MacOSX 10.4. OpenBSD, NetBSD, FreeBSD, Solaris, AIX, HP-UX, Irix, OpenVMS, Tru64. At least later versions of all of them. Non-authoritative web searches indicate so... And GetModuleFileName on Windows. Any objections to using it in cm3? (and GetModuleFileName on Windows)? This way, cm3 can easily and reliably look next to itself for config files and the pkg directory and cm3cg. I can double double check, but I doubt what it does today is totally reliable. Thanks, - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com Date: Fri, 29 May 2015 11:22:15 +0000 CC: m3devel at elegosoft.com; rodney.m.bates at acm.org Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > if equal($INSTALL_CM3_IN_BIN, "yes") Hm. That is relatively new. Rodney, This is a mistake: https://github.com/modula3/cm3/commit/1994f950bb30c3021fd24c07a555f0f7bace933f I see you commented it heavily, but we had working automation before that this broke. The automation already took into account what you were trying to take into account. I agree having the config search all over, which I did, is not good, as it undermines attempts to ship at just the right time. If you don't want to ship cm3cg, then don't run cm3 -ship for it. cm3cg is not actually running when cm3 -ship is run. The reasons cm3 doesn't ship itself do not apply. I agree it seems tempting to sync this behavior with the behavior of shipping cm3. But I don't think it should be. Yes the files have to be updated together. You do that by shipping cm3cg and somehow otherwise copying cm3. I agree that having this "somehow otherwise copy" is not great. I wonder if we can remove that though. The reason cm3 ship is disabled by default is not so that things are updated together, but because having an executable copy over itself reportedly does not work on some operating systems. It is nothing to do with our need to copy multiple files automatically. It is because it will fail. Now..I must say..Windows is extremely often labeled as one of these systems. Countless people believe this myth. But it isn't true. You can copy over an "in use" .dll or .exe. You merely have to rename it away first. Yes, that is still a bit wierd. And I have to investigate how to eventually delete it. Yes, there is a way to defer the delete..until a reboot..if you are an administrator.. but that is clearly an inadequate mechanism. It is quite possible you open with delete_on_close, and close, and then the last close might do it, when the .exe stops running. We should try this out. However, with Windows possibly eliminated as a concern (once ship does the rename, which it doesn't currently), does that leave other systems? AIX I believe is similar..that a direct copy will fail. But will rename work around it there too? Should we let cm3 be able to ship itself, and see what comes of it? Like, maybe every system people really use can do it? When an AIX user speaks up, we can fix it then?? Either way, I believe this change to m3cc/src/m3makefile should be undone. In the meantime, everyone can workaround it by setting the environment variable. The other angle, which I've been pushing unsuccessfully is never update in place. That is portable. Start with a new empty directory tree and fill it in by shipping, even cm3. Like make-dist.py does. One wrinkle here is that cm3, if it doesn't already, must favor looking next to itself, and not searching $PATH. So that you ship cm3cg to the new place, and then cm3, and cm3 shipping second finishes the transaction (ok, you'd also copy/ship other files, like configs and m3core/libm3, and then cm3 last). I would really really like that code for an executable to find its full path, on all supported systems. I don't think Posix can do it. Win32 GetModuleFileName(NULL or &__ImageBase) for example. Then strip off the last path element and append stuff, to find things you go with. It is a nice technique. I'm leary of techniques that rely on $PATH search or applying argv[0] to getcwd, as the current directory can change at any time. (and another unsuccessful angle is to move away from all the .sh files; I've been using the .py files for years...well, I was...) - Jay > Date: Thu, 28 May 2015 23:05:54 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: rodney.m.bates at acm.org; m3devel at elegosoft.com; adacore at marino.st > Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > > On Thu, 28 May 2015 20:14:49 +0000 > Jay K wrote: > > > > Also, this script built the compiler before the support libraries m3core and > > > libm3. I think there may have been one bootstrap scenario where this was the > > > way it needed to be done, but usually it is the other way around--these two > > > libraries first. > > > > This is very deliberate and should always work, when doing a native upgrade. > > It is true it is not always required. > > When doing a "clean" cross build, it is true that it is backwards. > > It is required when upgrading from an older build. > > > > Native upgrades start at least with a working compiler and its matching runtime. > > Cross builds start with a working host compiler and nothing for the target -- so they do start with m3core. > > I've had a look at the build log, and I think the problem in this case > with upgrade.py might be that it doesn't install the new backend, but > only the new frontend: > > [...] > Not shipping cm3cg. > --- shipping from AMD64_FREEBSD --- > > missing ".M3SHIP" file, build the package first. > dula3/work/bootstrap/bin/cm3 -build -DROOT=/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a +++ > ==> /mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a/m3-sys/m3cc done > > +++ /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin/cm3 -ship -DROOT=/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a +++ > ==> /mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a/m3-sys/m3cc done > > mkdir -p /mech/construction/mech/ptrees/default/lang/modula3/work/stage/usr/local/bin > cp -Pv /mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a/m3-sys/cm3/AMD64_FREEBSD/cm3 /mech/construction/mech/ptrees/default/lang/modula3/work/stage/usr/local/bin/cm3 > [...] > > In the upgrade.sh script I used install-cm3-compiler.sh, which always > installs both. In m3-sys/m3cc/src/m3makefile I find the following code: > > if equal($INSTALL_CM3_IN_BIN, "yes") > deriveds("", ["cm3cg", "cm3cg.exe"]) > write ( "Forced ship of cm3cg." & CR) > BindExport (AppendExeExtension ("cm3cg")) > if DoMipsTfile > BindExport ("mips-tfile") > end > else > write ( "Not shipping cm3cg." & CR) > end > > So perhaps simply setting INSTALL_CM3_IN_BIN=yes in the environment > will fix that problem? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri May 29 13:45:02 2015 From: jay.krell at cornell.edu (Jay K) Date: Fri, 29 May 2015 11:45:02 +0000 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop>, , , , <20150528230554.80920c53f002da8beb3f29d0@elegosoft.com>, Message-ID: The workaround is bad, as it affects m3-sys/cm3 also. Rodney, this really should be removed. If you must have something like this, make it a separate variable from cm3. Please. - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com Date: Fri, 29 May 2015 11:22:15 +0000 CC: m3devel at elegosoft.com; rodney.m.bates at acm.org Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > if equal($INSTALL_CM3_IN_BIN, "yes") Hm. That is relatively new. Rodney, This is a mistake: https://github.com/modula3/cm3/commit/1994f950bb30c3021fd24c07a555f0f7bace933f I see you commented it heavily, but we had working automation before that this broke. The automation already took into account what you were trying to take into account. I agree having the config search all over, which I did, is not good, as it undermines attempts to ship at just the right time. If you don't want to ship cm3cg, then don't run cm3 -ship for it. cm3cg is not actually running when cm3 -ship is run. The reasons cm3 doesn't ship itself do not apply. I agree it seems tempting to sync this behavior with the behavior of shipping cm3. But I don't think it should be. Yes the files have to be updated together. You do that by shipping cm3cg and somehow otherwise copying cm3. I agree that having this "somehow otherwise copy" is not great. I wonder if we can remove that though. The reason cm3 ship is disabled by default is not so that things are updated together, but because having an executable copy over itself reportedly does not work on some operating systems. It is nothing to do with our need to copy multiple files automatically. It is because it will fail. Now..I must say..Windows is extremely often labeled as one of these systems. Countless people believe this myth. But it isn't true. You can copy over an "in use" .dll or .exe. You merely have to rename it away first. Yes, that is still a bit wierd. And I have to investigate how to eventually delete it. Yes, there is a way to defer the delete..until a reboot..if you are an administrator.. but that is clearly an inadequate mechanism. It is quite possible you open with delete_on_close, and close, and then the last close might do it, when the .exe stops running. We should try this out. However, with Windows possibly eliminated as a concern (once ship does the rename, which it doesn't currently), does that leave other systems? AIX I believe is similar..that a direct copy will fail. But will rename work around it there too? Should we let cm3 be able to ship itself, and see what comes of it? Like, maybe every system people really use can do it? When an AIX user speaks up, we can fix it then?? Either way, I believe this change to m3cc/src/m3makefile should be undone. In the meantime, everyone can workaround it by setting the environment variable. The other angle, which I've been pushing unsuccessfully is never update in place. That is portable. Start with a new empty directory tree and fill it in by shipping, even cm3. Like make-dist.py does. One wrinkle here is that cm3, if it doesn't already, must favor looking next to itself, and not searching $PATH. So that you ship cm3cg to the new place, and then cm3, and cm3 shipping second finishes the transaction (ok, you'd also copy/ship other files, like configs and m3core/libm3, and then cm3 last). I would really really like that code for an executable to find its full path, on all supported systems. I don't think Posix can do it. Win32 GetModuleFileName(NULL or &__ImageBase) for example. Then strip off the last path element and append stuff, to find things you go with. It is a nice technique. I'm leary of techniques that rely on $PATH search or applying argv[0] to getcwd, as the current directory can change at any time. (and another unsuccessful angle is to move away from all the .sh files; I've been using the .py files for years...well, I was...) - Jay > Date: Thu, 28 May 2015 23:05:54 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: rodney.m.bates at acm.org; m3devel at elegosoft.com; adacore at marino.st > Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > > On Thu, 28 May 2015 20:14:49 +0000 > Jay K wrote: > > > > Also, this script built the compiler before the support libraries m3core and > > > libm3. I think there may have been one bootstrap scenario where this was the > > > way it needed to be done, but usually it is the other way around--these two > > > libraries first. > > > > This is very deliberate and should always work, when doing a native upgrade. > > It is true it is not always required. > > When doing a "clean" cross build, it is true that it is backwards. > > It is required when upgrading from an older build. > > > > Native upgrades start at least with a working compiler and its matching runtime. > > Cross builds start with a working host compiler and nothing for the target -- so they do start with m3core. > > I've had a look at the build log, and I think the problem in this case > with upgrade.py might be that it doesn't install the new backend, but > only the new frontend: > > [...] > Not shipping cm3cg. > --- shipping from AMD64_FREEBSD --- > > missing ".M3SHIP" file, build the package first. > dula3/work/bootstrap/bin/cm3 -build -DROOT=/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a +++ > ==> /mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a/m3-sys/m3cc done > > +++ /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin/cm3 -ship -DROOT=/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a +++ > ==> /mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a/m3-sys/m3cc done > > mkdir -p /mech/construction/mech/ptrees/default/lang/modula3/work/stage/usr/local/bin > cp -Pv /mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a/m3-sys/cm3/AMD64_FREEBSD/cm3 /mech/construction/mech/ptrees/default/lang/modula3/work/stage/usr/local/bin/cm3 > [...] > > In the upgrade.sh script I used install-cm3-compiler.sh, which always > installs both. In m3-sys/m3cc/src/m3makefile I find the following code: > > if equal($INSTALL_CM3_IN_BIN, "yes") > deriveds("", ["cm3cg", "cm3cg.exe"]) > write ( "Forced ship of cm3cg." & CR) > BindExport (AppendExeExtension ("cm3cg")) > if DoMipsTfile > BindExport ("mips-tfile") > end > else > write ( "Not shipping cm3cg." & CR) > end > > So perhaps simply setting INSTALL_CM3_IN_BIN=yes in the environment > will fix that problem? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elego.de Fri May 29 14:04:02 2015 From: wagner at elego.de (Olaf Wagner) Date: Fri, 29 May 2015 14:04:02 +0200 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <20150528230554.80920c53f002da8beb3f29d0@elegosoft.com> Message-ID: <20150529140402.d87ddf6435a145c466ed3434@elego.de> On Fri, 29 May 2015 11:45:02 +0000 Jay K wrote: > The workaround is bad, as it affects m3-sys/cm3 also. > Rodney, this really should be removed. If you must have something like this, make it a separate variable from cm3. Please. I don't think Rodney introduced this variable ;-) Olaf > - Jay > > > > From: jay.krell at cornell.edu > To: wagner at elegosoft.com > Date: Fri, 29 May 2015 11:22:15 +0000 > CC: m3devel at elegosoft.com; rodney.m.bates at acm.org > Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > > > > > > if equal($INSTALL_CM3_IN_BIN, "yes") > > > Hm. That is relatively new. > Rodney, This is a mistake: > https://github.com/modula3/cm3/commit/1994f950bb30c3021fd24c07a555f0f7bace933f > > > I see you commented it heavily, but we had working automation before that this broke. > The automation already took into account what you were trying to take into account. > > > I agree having the config search all over, which I did, is not good, > as it undermines attempts to ship at just the right time. > > > If you don't want to ship cm3cg, then don't run cm3 -ship for it. > cm3cg is not actually running when cm3 -ship is run. > The reasons cm3 doesn't ship itself do not apply. > > > I agree it seems tempting to sync this behavior with the behavior of shipping cm3. > But I don't think it should be. > > > Yes the files have to be updated together. > You do that by shipping cm3cg and somehow otherwise copying cm3. > I agree that having this "somehow otherwise copy" is not great. > I wonder if we can remove that though. > > > The reason cm3 ship is disabled by default is not so that things are updated together, > but because having an executable copy over itself reportedly does not work on some operating systems. > It is nothing to do with our need to copy multiple files automatically. It is because it will fail. > > > > Now..I must say..Windows is extremely often labeled as one of these systems. > Countless people believe this myth. But it isn't true. > You can copy over an "in use" .dll or .exe. > You merely have to rename it away first. Yes, that is still a bit wierd. > And I have to investigate how to eventually delete it. > Yes, there is a way to defer the delete..until a reboot..if you are an administrator.. > but that is clearly an inadequate mechanism. It is quite possible you open with delete_on_close, > and close, and then the last close might do it, when the .exe stops running. > We should try this out. > > > > However, with Windows possibly eliminated as a concern (once ship does the rename, which it doesn't currently), > does that leave other systems? AIX I believe is similar..that a direct copy will fail. > But will rename work around it there too? > > > Should we let cm3 be able to ship itself, and see what comes of it? > Like, maybe every system people really use can do it? > When an AIX user speaks up, we can fix it then?? > > > > Either way, I believe this change to m3cc/src/m3makefile should be undone. > > > In the meantime, everyone can workaround it by setting the environment variable. > > > The other angle, which I've been pushing unsuccessfully is never update in place. > That is portable. > Start with a new empty directory tree and fill it in by shipping, even cm3. > Like make-dist.py does. > One wrinkle here is that cm3, if it doesn't already, must favor looking next to itself, and not searching $PATH. > So that you ship cm3cg to the new place, and then cm3, and cm3 shipping second finishes the transaction (ok, > you'd also copy/ship other files, like configs and m3core/libm3, and then cm3 last). > > > > I would really really like that code for an executable to find its full path, on all supported systems. > I don't think Posix can do it. Win32 GetModuleFileName(NULL or &__ImageBase) for example. > Then strip off the last path element and append stuff, to find things you go with. > It is a nice technique. > I'm leary of techniques that rely on $PATH search or applying argv[0] to getcwd, as the current directory can change at any time. > > > (and another unsuccessful angle is to move away from all the .sh files; I've been using the .py files for years...well, I was...) > > > > - Jay > > > > > Date: Thu, 28 May 2015 23:05:54 +0200 > > From: wagner at elegosoft.com > > To: jay.krell at cornell.edu > > CC: rodney.m.bates at acm.org; m3devel at elegosoft.com; adacore at marino.st > > Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > > > > On Thu, 28 May 2015 20:14:49 +0000 > > Jay K wrote: > > > > > > Also, this script built the compiler before the support libraries m3core and > > > > libm3. I think there may have been one bootstrap scenario where this was the > > > > way it needed to be done, but usually it is the other way around--these two > > > > libraries first. > > > > > > This is very deliberate and should always work, when doing a native upgrade. > > > It is true it is not always required. > > > When doing a "clean" cross build, it is true that it is backwards. > > > It is required when upgrading from an older build. > > > > > > Native upgrades start at least with a working compiler and its matching runtime. > > > Cross builds start with a working host compiler and nothing for the target -- so they do start with m3core. > > > > I've had a look at the build log, and I think the problem in this case > > with upgrade.py might be that it doesn't install the new backend, but > > only the new frontend: > > > > [...] > > Not shipping cm3cg. > > --- shipping from AMD64_FREEBSD --- > > > > missing ".M3SHIP" file, build the package first. > > dula3/work/bootstrap/bin/cm3 -build -DROOT=/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a +++ > > ==> /mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a/m3-sys/m3cc done > > > > +++ /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin/cm3 -ship -DROOT=/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a +++ > > ==> /mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a/m3-sys/m3cc done > > > > mkdir -p /mech/construction/mech/ptrees/default/lang/modula3/work/stage/usr/local/bin > > cp -Pv /mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a/m3-sys/cm3/AMD64_FREEBSD/cm3 /mech/construction/mech/ptrees/default/lang/modula3/work/stage/usr/local/bin/cm3 > > [...] > > > > In the upgrade.sh script I used install-cm3-compiler.sh, which always > > installs both. In m3-sys/m3cc/src/m3makefile I find the following code: > > > > if equal($INSTALL_CM3_IN_BIN, "yes") > > deriveds("", ["cm3cg", "cm3cg.exe"]) > > write ( "Forced ship of cm3cg." & CR) > > BindExport (AppendExeExtension ("cm3cg")) > > if DoMipsTfile > > BindExport ("mips-tfile") > > end > > else > > write ( "Not shipping cm3cg." & CR) > > end > > > > So perhaps simply setting INSTALL_CM3_IN_BIN=yes in the environment > > will fix that problem? > > > > Olaf > > -- > > Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > > Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From wagner at elego.de Fri May 29 15:58:33 2015 From: wagner at elego.de (Olaf Wagner) Date: Fri, 29 May 2015 15:58:33 +0200 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <5568421D.3050209@marino.st> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop> <556817A1.2090206@marino.st> <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de> <55682D1A.2030504@marino.st> <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de> <55683689.2090709@marino.st> <20150529122732.1396eb079ff9b404bcb21e40@elego.de> <5568421D.3050209@marino.st> Message-ID: <20150529155833.8454664b88391d93708e8f85@elego.de> On Fri, 29 May 2015 12:40:29 +0200 John Marino wrote: > On 5/29/2015 12:27, Olaf Wagner wrote: > > > > > I'm afraid I'll have to reproduce your setup locally on my FreeBSD > > system at home, as I don't see the wrong step in the logs 8-| > > > > After Rodney's success on Linux I was hoping that everything still > > just worked as some years ago. > > > > Just to make sure: you start with a 5.8.6 release archive for > > AMD64_FREEBSD, install that, check out the git sources, and > > run the script(s) in the checked-out repository, correct? Or > > did I miss anything? > > I maintain the "port" for M3 on FreeBSD. see here: > http://www.freshports.org/lang/modula3 > > Because I'm building these in ports, there are certain "rules" I have to > follow using makefiles. I've attached the in-work "port" that I'm > using. You can "rm -rf /usr/ports/lang/modula3; cd /usr/ports/lang; tar > -xf m3-port.tar.gz" to use it to reproduce what I'm doing. > > All you'd do to reproduce is: "cd /usr/ports/lang/modula3 ; make build" > > To be more specific, the current repo is downloaded from github as a > tarball along with the bootstrap compiler (only once, then the tarball > is reused on subsequent). Then it tries to build a new bootstrap > compiler in the build target and that's where it's failing. I unpacked your port and tried the first step. But my system seems to be too old: % make fetch ===> modula3-5.10.0 the bootstrap compiler only runs on FreeBSD 9.0 or later. *** Error code 1 Stop in /src/ports/lang/modula3. Why would it only run on FreeBSD 9? I actually _have_ a working cm3 installation on this system ;-) Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From adacore at marino.st Fri May 29 16:06:30 2015 From: adacore at marino.st (John Marino) Date: Fri, 29 May 2015 16:06:30 +0200 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <20150529155833.8454664b88391d93708e8f85@elego.de> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop> <556817A1.2090206@marino.st> <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de> <55682D1A.2030504@marino.st> <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de> <55683689.2090709@marino.st> <20150529122732.1396eb079ff9b404bcb21e40@elego.de> <5568421D.3050209@marino.st> <20150529155833.8454664b88391d93708e8f85@elego.de> Message-ID: <55687266.3090400@marino.st> On 5/29/2015 15:58, Olaf Wagner wrote: > On Fri, 29 May 2015 12:40:29 +0200 > John Marino wrote: > I unpacked your port and tried the first step. > But my system seems to be too old: > > % make fetch > ===> modula3-5.10.0 the bootstrap compiler only runs on FreeBSD 9.0 or later. > *** Error code 1 This means at best your machine is FreeBSD 8.x. The last FreeBSD 8, 8.4 (a long-term support version) expires in 4 weeks. So you should update. :) > Stop in /src/ports/lang/modula3. > > Why would it only run on FreeBSD 9? > I actually _have_ a working cm3 installation on this system ;-) The port doesn't consider installed CM3. It has to do with how ports are now built in "clean" jails where nothing is installed. You *could* package your working CM3 as a bootstrap compiler [1] but I would think your time would be better spent with FreeBSD Update: https://www.freebsd.org/doc/handbook/updating-upgrading-freebsdupdate.html John [1] Just look in work/bootstrap and emulate if you want to do this. From wagner at elego.de Fri May 29 16:20:28 2015 From: wagner at elego.de (Olaf Wagner) Date: Fri, 29 May 2015 16:20:28 +0200 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <55687266.3090400@marino.st> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop> <556817A1.2090206@marino.st> <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de> <55682D1A.2030504@marino.st> <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de> <55683689.2090709@marino.st> <20150529122732.1396eb079ff9b404bcb21e40@elego.de> <5568421D.3050209@marino.st> <20150529155833.8454664b88391d93708e8f85@elego.de> <55687266.3090400@marino.st> Message-ID: <20150529162028.388911007a614006049beb42@elego.de> On Fri, 29 May 2015 16:06:30 +0200 John Marino wrote: > On 5/29/2015 15:58, Olaf Wagner wrote: > > On Fri, 29 May 2015 12:40:29 +0200 > > John Marino wrote: > > I unpacked your port and tried the first step. > > But my system seems to be too old: > > > > % make fetch > > ===> modula3-5.10.0 the bootstrap compiler only runs on FreeBSD 9.0 or later. > > *** Error code 1 > > This means at best your machine is FreeBSD 8.x. The last FreeBSD 8, 8.4 > (a long-term support version) expires in 4 weeks. So you should update. :) > > > > Stop in /src/ports/lang/modula3. > > > > Why would it only run on FreeBSD 9? > > I actually _have_ a working cm3 installation on this system ;-) > > The port doesn't consider installed CM3. It has to do with how ports > are now built in "clean" jails where nothing is installed. > > You *could* package your working CM3 as a bootstrap compiler [1] but I > would think your time would be better spent with FreeBSD Update: > https://www.freebsd.org/doc/handbook/updating-upgrading-freebsdupdate.html > > John > > > [1] Just look in work/bootstrap and emulate if you want to do this. I will update the system (it's the latest 8.4 stable) but it's unlikely that I'll do it within the next two weeks, because I won't be at home. I'll try to reproduce the problem without the port makefile though. Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From wagner at elego.de Fri May 29 17:23:05 2015 From: wagner at elego.de (Olaf Wagner) Date: Fri, 29 May 2015 17:23:05 +0200 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <20150529162028.388911007a614006049beb42@elego.de> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop> <556817A1.2090206@marino.st> <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de> <55682D1A.2030504@marino.st> <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de> <55683689.2090709@marino.st> <20150529122732.1396eb079ff9b404bcb21e40@elego.de> <5568421D.3050209@marino.st> <20150529155833.8454664b88391d93708e8f85@elego.de> <55687266.3090400@marino.st> <20150529162028.388911007a614006049beb42@elego.de> Message-ID: <20150529172305.a3fc2a9865b5250a5b9140fc@elego.de> On Fri, 29 May 2015 16:20:28 +0200 Olaf Wagner wrote: > On Fri, 29 May 2015 16:06:30 +0200 > John Marino wrote: > > > On 5/29/2015 15:58, Olaf Wagner wrote: > > > On Fri, 29 May 2015 12:40:29 +0200 > > > John Marino wrote: > > > I unpacked your port and tried the first step. > > > But my system seems to be too old: > > > > > > % make fetch > > > ===> modula3-5.10.0 the bootstrap compiler only runs on FreeBSD 9.0 or later. > > > *** Error code 1 > > > > This means at best your machine is FreeBSD 8.x. The last FreeBSD 8, 8.4 > > (a long-term support version) expires in 4 weeks. So you should update. :) > > > > > > > Stop in /src/ports/lang/modula3. > > > > > > Why would it only run on FreeBSD 9? > > > I actually _have_ a working cm3 installation on this system ;-) > > > > The port doesn't consider installed CM3. It has to do with how ports > > are now built in "clean" jails where nothing is installed. > > > > You *could* package your working CM3 as a bootstrap compiler [1] but I > > would think your time would be better spent with FreeBSD Update: > > https://www.freebsd.org/doc/handbook/updating-upgrading-freebsdupdate.html > > > > John > > > > > > [1] Just look in work/bootstrap and emulate if you want to do this. > > I will update the system (it's the latest 8.4 stable) but it's > unlikely that I'll do it within the next two weeks, because I won't > be at home. > > I'll try to reproduce the problem without the port makefile though. The bootstrap compiler backend doesn't run on my system: new exporters -> recompiling FSUtils.i3 /libexec/ld-elf.so.1: /usr/ports/lang/modula3/work/bootstrap//bin/cm3cg: Undefined symbol "_ThreadRuneLocale" m3_backend => 1 m3cc (aka cm3cg) failed compiling: FSUtils.ic It seems there's no way around a system upgrade. But that won't happen today, sorry. I'll make a final test with an older bootstrap archive from opencm3.net later. Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From jay.krell at cornell.edu Fri May 29 17:18:35 2015 From: jay.krell at cornell.edu (Jay K) Date: Fri, 29 May 2015 15:18:35 +0000 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <20150529140402.d87ddf6435a145c466ed3434@elego.de> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop>, , <20150528230554.80920c53f002da8beb3f29d0@elegosoft.com>, , , <20150529140402.d87ddf6435a145c466ed3434@elego.de> Message-ID: I believe the variable existed for cm3, but not m3cc/cm3cg. Rodney added it for m3cc/cm3cg. - Jay > Date: Fri, 29 May 2015 14:04:02 +0200 > From: wagner at elego.de > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com; rodney.m.bates at acm.org > Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > > On Fri, 29 May 2015 11:45:02 +0000 > Jay K wrote: > > > The workaround is bad, as it affects m3-sys/cm3 also. > > Rodney, this really should be removed. If you must have something like this, make it a separate variable from cm3. Please. > > I don't think Rodney introduced this variable ;-) > > Olaf > > > - Jay > > > > > > > > From: jay.krell at cornell.edu > > To: wagner at elegosoft.com > > Date: Fri, 29 May 2015 11:22:15 +0000 > > CC: m3devel at elegosoft.com; rodney.m.bates at acm.org > > Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > > > > > > > > > > > if equal($INSTALL_CM3_IN_BIN, "yes") > > > > > > Hm. That is relatively new. > > Rodney, This is a mistake: > > https://github.com/modula3/cm3/commit/1994f950bb30c3021fd24c07a555f0f7bace933f > > > > > > I see you commented it heavily, but we had working automation before that this broke. > > The automation already took into account what you were trying to take into account. > > > > > > I agree having the config search all over, which I did, is not good, > > as it undermines attempts to ship at just the right time. > > > > > > If you don't want to ship cm3cg, then don't run cm3 -ship for it. > > cm3cg is not actually running when cm3 -ship is run. > > The reasons cm3 doesn't ship itself do not apply. > > > > > > I agree it seems tempting to sync this behavior with the behavior of shipping cm3. > > But I don't think it should be. > > > > > > Yes the files have to be updated together. > > You do that by shipping cm3cg and somehow otherwise copying cm3. > > I agree that having this "somehow otherwise copy" is not great. > > I wonder if we can remove that though. > > > > > > The reason cm3 ship is disabled by default is not so that things are updated together, > > but because having an executable copy over itself reportedly does not work on some operating systems. > > It is nothing to do with our need to copy multiple files automatically. It is because it will fail. > > > > > > > > Now..I must say..Windows is extremely often labeled as one of these systems. > > Countless people believe this myth. But it isn't true. > > You can copy over an "in use" .dll or .exe. > > You merely have to rename it away first. Yes, that is still a bit wierd. > > And I have to investigate how to eventually delete it. > > Yes, there is a way to defer the delete..until a reboot..if you are an administrator.. > > but that is clearly an inadequate mechanism. It is quite possible you open with delete_on_close, > > and close, and then the last close might do it, when the .exe stops running. > > We should try this out. > > > > > > > > However, with Windows possibly eliminated as a concern (once ship does the rename, which it doesn't currently), > > does that leave other systems? AIX I believe is similar..that a direct copy will fail. > > But will rename work around it there too? > > > > > > Should we let cm3 be able to ship itself, and see what comes of it? > > Like, maybe every system people really use can do it? > > When an AIX user speaks up, we can fix it then?? > > > > > > > > Either way, I believe this change to m3cc/src/m3makefile should be undone. > > > > > > In the meantime, everyone can workaround it by setting the environment variable. > > > > > > The other angle, which I've been pushing unsuccessfully is never update in place. > > That is portable. > > Start with a new empty directory tree and fill it in by shipping, even cm3. > > Like make-dist.py does. > > One wrinkle here is that cm3, if it doesn't already, must favor looking next to itself, and not searching $PATH. > > So that you ship cm3cg to the new place, and then cm3, and cm3 shipping second finishes the transaction (ok, > > you'd also copy/ship other files, like configs and m3core/libm3, and then cm3 last). > > > > > > > > I would really really like that code for an executable to find its full path, on all supported systems. > > I don't think Posix can do it. Win32 GetModuleFileName(NULL or &__ImageBase) for example. > > Then strip off the last path element and append stuff, to find things you go with. > > It is a nice technique. > > I'm leary of techniques that rely on $PATH search or applying argv[0] to getcwd, as the current directory can change at any time. > > > > > > (and another unsuccessful angle is to move away from all the .sh files; I've been using the .py files for years...well, I was...) > > > > > > > > - Jay > > > > > > > > > Date: Thu, 28 May 2015 23:05:54 +0200 > > > From: wagner at elegosoft.com > > > To: jay.krell at cornell.edu > > > CC: rodney.m.bates at acm.org; m3devel at elegosoft.com; adacore at marino.st > > > Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > > > > > > On Thu, 28 May 2015 20:14:49 +0000 > > > Jay K wrote: > > > > > > > > Also, this script built the compiler before the support libraries m3core and > > > > > libm3. I think there may have been one bootstrap scenario where this was the > > > > > way it needed to be done, but usually it is the other way around--these two > > > > > libraries first. > > > > > > > > This is very deliberate and should always work, when doing a native upgrade. > > > > It is true it is not always required. > > > > When doing a "clean" cross build, it is true that it is backwards. > > > > It is required when upgrading from an older build. > > > > > > > > Native upgrades start at least with a working compiler and its matching runtime. > > > > Cross builds start with a working host compiler and nothing for the target -- so they do start with m3core. > > > > > > I've had a look at the build log, and I think the problem in this case > > > with upgrade.py might be that it doesn't install the new backend, but > > > only the new frontend: > > > > > > [...] > > > Not shipping cm3cg. > > > --- shipping from AMD64_FREEBSD --- > > > > > > missing ".M3SHIP" file, build the package first. > > > dula3/work/bootstrap/bin/cm3 -build -DROOT=/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a +++ > > > ==> /mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a/m3-sys/m3cc done > > > > > > +++ /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin/cm3 -ship -DROOT=/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a +++ > > > ==> /mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a/m3-sys/m3cc done > > > > > > mkdir -p /mech/construction/mech/ptrees/default/lang/modula3/work/stage/usr/local/bin > > > cp -Pv /mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a/m3-sys/cm3/AMD64_FREEBSD/cm3 /mech/construction/mech/ptrees/default/lang/modula3/work/stage/usr/local/bin/cm3 > > > [...] > > > > > > In the upgrade.sh script I used install-cm3-compiler.sh, which always > > > installs both. In m3-sys/m3cc/src/m3makefile I find the following code: > > > > > > if equal($INSTALL_CM3_IN_BIN, "yes") > > > deriveds("", ["cm3cg", "cm3cg.exe"]) > > > write ( "Forced ship of cm3cg." & CR) > > > BindExport (AppendExeExtension ("cm3cg")) > > > if DoMipsTfile > > > BindExport ("mips-tfile") > > > end > > > else > > > write ( "Not shipping cm3cg." & CR) > > > end > > > > > > So perhaps simply setting INSTALL_CM3_IN_BIN=yes in the environment > > > will fix that problem? > > > > > > Olaf > > > -- > > > Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com > > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > > > Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > > > > -- > Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -------------- next part -------------- An HTML attachment was scrubbed... URL: From adacore at marino.st Fri May 29 17:30:05 2015 From: adacore at marino.st (John Marino) Date: Fri, 29 May 2015 17:30:05 +0200 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <20150529172305.a3fc2a9865b5250a5b9140fc@elego.de> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop> <556817A1.2090206@marino.st> <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de> <55682D1A.2030504@marino.st> <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de> <55683689.2090709@marino.st> <20150529122732.1396eb079ff9b404bcb21e40@elego.de> <5568421D.3050209@marino.st> <20150529155833.8454664b88391d93708e8f85@elego.de> <55687266.3090400@marino.st> <20150529162028.388911007a614006049beb42@elego.de> <20150529172305.a3fc2a9865b5250a5b9140fc@elego.de> Message-ID: <556885FD.6010800@marino.st> On 5/29/2015 17:23, Olaf Wagner wrote: > On Fri, 29 May 2015 16:20:28 +0200 > Olaf Wagner wrote: >> I'll try to reproduce the problem without the port makefile though. > > The bootstrap compiler backend doesn't run on my system: > > new exporters -> recompiling FSUtils.i3 > /libexec/ld-elf.so.1: /usr/ports/lang/modula3/work/bootstrap//bin/cm3cg: Undefined symbol "_ThreadRuneLocale" > m3_backend => 1 > m3cc (aka cm3cg) failed compiling: FSUtils.ic I didn't realize you meant you were going to try the bootstrap outside of the port. I knew that wouldn't work. As to "why", it's my fault. I built the bootstrap on FreeBSD 9, meaning it would work on 9 and new, but not 8. I should have built it on 8 but was tired of fooling with it by that point. > > It seems there's no way around a system upgrade. But that won't happen > today, sorry. > > I'll make a final test with an older bootstrap archive from opencm3.net > later. It might work -- as long as you have older gmp, mpfr, etc. I found the problem with those bootstrap is they were dynamically linked to libraries that don't exist anymore. John From rodney_bates at lcwb.coop Fri May 29 17:55:43 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Fri, 29 May 2015 10:55:43 -0500 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <55683689.2090709@marino.st> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop> <556817A1.2090206@marino.st> <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de> <55682D1A.2030504@marino.st> <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de> <55683689.2090709@marino.st> Message-ID: <55688BFF.5040701@lcwb.coop> I don't know yet why, or what needs to change, but here is definitely the problem, starting in line 4575 of your m3c log: g++48 -O2 -pipe -fstack-protector -Wl,-rpath=/usr/local/lib/gcc48 -fno-strict-aliasing -Wl,-rpath=/usr/local/lib/gcc48 -DIN_GCC -Wno-missing-field-initializers -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -o m3cgc1 m3cg/parse.o attribs.o main.o tree-browser.o libbackend.a libcommon-target.a libcommon.a ../libcpp/libcpp.a libcommon.a ../libcpp/libcpp.a ../libiberty/libiberty.a gmake[1]: Leaving directory `/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a/m3-sys/m3cc/AMD64_FREEBSD/gcc' This is copying the newly-built cm3cg (the compiler back end) to your bin directory: Forced ship of cm3cg. --- shipping from AMD64_FREEBSD --- . => /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin cm3cg ==> m3-sys/m3cc done === package m3-libs/m3core === And this is using the cm3 (compiler front end) that was already in the bin directory, and is the release version. +++ /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin/cm3 -build -DROOT='/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a' $RARGS && /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin/cm3 -ship $RARGS -DROOT='/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a' +++ --- building in AMD64_FREEBSD --- ignoring ../src/m3overrides new source -> compiling RTHooks.i3 This is cm3cg (aka m3cgc1) detecting the incompatibility: m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 compilation terminated. Here is the counterpart section of my log: g++ -g -O2 -DIN_GCC -Wno-missing-field-initializers -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -o m3cgc1 m3cg/parse.o attribs.o main.o tree-browser.o libbackend.a libcommon-target.a libcommon.a ../libcpp/libcpp.a libcommon.a ../libcpp/libcpp.a ../libiberty/libiberty.a On my build, it's not shipping: Not shipping cm3cg. --- shipping from AMD64_LINUX --- missing ".M3SHIP" file, build the package first. ==> /home/rodney/proj/m3/git/cm3/m3-sys/m3cc done === package /home/rodney/proj/m3/git/cm3/m3-libs/m3core === +++ cm3 -build -DROOT='/home/rodney/proj/m3/git/cm3' $RARGS && cm3 -ship $RARGS -DROOT='/home/rodney/proj/m3/git/cm3' +++ --- building in AMD64_LINUX --- ignoring ../src/m3overrides new source -> compiling RTHooks.i3 new source -> compiling RT0.i3 When it works, the copying of both cm3 and cm3cg to the bin directory is delayed until after both have been built, in the 'install-cm3-compiler.sh upgrade' step. I see your build is using a full path to the bin directory and mine is letting it come from the usual $PATH search, but that should make no difference, as long as the bin directory is found in a consistent way, which seems to be the case in both builds. On 05/29/2015 04:51 AM, John Marino wrote: > On 5/29/2015 11:39, Olaf Wagner wrote: >> On Fri, 29 May 2015 11:10:50 +0200 >> John Marino wrote: >> >>> On 5/29/2015 10:54, Olaf Wagner wrote: >>>> Please try what I suggested in the attached mail: define >>>> INSTALL_CM3_IN_BIN=yes >>>> in the environment and see if that helps. >>>> >>> >>> Unfortunately it seems the result is exactly the same, even when >>> INSTALL_CM3_IN_BIN is defined in the environment. >> >> Can I see the new logs? Has the new backend (cm3cg) been installed now? >> > > It's here: > http://leaf.dragonflybsd.org/~marino/m3c.log > > It never completes "do-cm3-front.sh buildship " > > Note that I'm using a bootstrap install and set INSTALL_ROOT to another > location, but it never gets to the point of installing anything. > > John > -- Rodney Bates rodney.m.bates at acm.org From adacore at marino.st Fri May 29 18:03:29 2015 From: adacore at marino.st (John Marino) Date: Fri, 29 May 2015 18:03:29 +0200 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <55688BFF.5040701@lcwb.coop> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop> <556817A1.2090206@marino.st> <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de> <55682D1A.2030504@marino.st> <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de> <55683689.2090709@marino.st> <55688BFF.5040701@lcwb.coop> Message-ID: <55688DD1.9070804@marino.st> On 5/29/2015 17:55, Rodney M. Bates wrote: > This is copying the newly-built cm3cg (the compiler back end) to your > bin directory: > > Forced ship of cm3cg. > --- shipping from AMD64_FREEBSD --- > > . => > /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin > cm3cg > ==> m3-sys/m3cc done Ok, I was expecting it to install at: /mech/construction/mech/ptrees/default/lang/modula3/work/intermediate/bin I was not trying to overwrite the bootstrap, but create a minimal new one that could build the whole thing (like I did before with boot-cm3-with-cm3) > This is cm3cg (aka m3cgc1) detecting the incompatibility: > > m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected > 0x110 > compilation terminated. Not surprising considering above... John From wagner at elego.de Fri May 29 18:02:23 2015 From: wagner at elego.de (Olaf Wagner) Date: Fri, 29 May 2015 18:02:23 +0200 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <556885FD.6010800@marino.st> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop> <556817A1.2090206@marino.st> <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de> <55682D1A.2030504@marino.st> <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de> <55683689.2090709@marino.st> <20150529122732.1396eb079ff9b404bcb21e40@elego.de> <5568421D.3050209@marino.st> <20150529155833.8454664b88391d93708e8f85@elego.de> <55687266.3090400@marino.st> <20150529162028.388911007a614006049beb42@elego.de> <20150529172305.a3fc2a9865b5250a5b9140fc@elego.de> <556885FD.6010800@marino.st> Message-ID: <20150529180223.d467621b68ebf665da685b12@elego.de> On Fri, 29 May 2015 17:30:05 +0200 John Marino wrote: > > I'll make a final test with an older bootstrap archive from opencm3.net > > later. > > It might work -- as long as you have older gmp, mpfr, etc. I found the > problem with those bootstrap is they were dynamically linked to > libraries that don't exist anymore. Surprisingly, that went very well without any problem :-) [...] Critical Mass Modula-3 version d5.10.0 last updated: 2015-05-21 compiled: 2015-05-29 15:50:50 configuration: /usr/ports/lang/modula3/work/bootstrap/bin/cm3.cfg host: AMD64_FREEBSD target: AMD64_FREEBSD Modula-3 backend (GCC) version 4.7.1 (x86_64-unknown-freebsd8.4) compiled by GNU C version 4.2.1 20070831 patched [FreeBSD], GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 create config directory /usr/ports/lang/modula3/work/bootstrap/bin/config new config files copied/generated in /usr/ports/lang/modula3/work/bootstrap/bin/cm3.cfg, /usr/ports/lang/modula3/work/bootstrap/bin/config Let's see what I have and did: % uname -a FreeBSD luthien.iceflower.in-berlin.de 8.4-STABLE FreeBSD 8.4-STABLE #0 r268069: Tue Jul 1 23:12:27 CEST 2014 root at luthien:/src/obj/src/sys/GENERIC amd64 Current Code Base form Github: % wget --no-check-certificate https://codeload.github.com/modula3/cm3/tar.gz Old CM3 5.8.6 archive from www.opencm3.net: % wget --no-check-certificate http://www.opencm3.net/releng/cm3-bin-core-AMD64_FREEBSD-5.8.6-REL.tgz I unpacked the system.tgz archive contained in the cm3-bin-core archive into a bootstrap directory and set some path: % echo $PATH /usr/ports/lang/modula3/work/bootstrap/bin:/home/wagner/bin:/usr/local/dcvs/bin:/usr/local/cm3/bin:/bin:/usr/bin:/usr/local/bin:/usr/contrib/bin:/usr/gnu/bin:/usr/X11R6/bin:/usr/local/sbin:/usr/sbin:/sbin:/sbin:/usr/sbin % echo $LD_LIBRARY_PATH /usr/ports/lang/modula3/work/bootstrap/lib I had to fake libgmp.so.8 by making a link to libgmp.so.10 for the old cm3cg: % sudo ln -s /usr/local/lib/libgmp.so /usr/local/lib/libgmp.so.8 % cd cm3-8c1b86a/ % ./scripts/upgrade.sh I didn't apply any patches. I can repeat everything and send you the log, or you could even get a login on that machine to have a look around. Let me know what you need. I hope this helps, Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From adacore at marino.st Fri May 29 18:14:29 2015 From: adacore at marino.st (John Marino) Date: Fri, 29 May 2015 18:14:29 +0200 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <20150529180223.d467621b68ebf665da685b12@elego.de> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop> <556817A1.2090206@marino.st> <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de> <55682D1A.2030504@marino.st> <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de> <55683689.2090709@marino.st> <20150529122732.1396eb079ff9b404bcb21e40@elego.de> <5568421D.3050209@marino.st> <20150529155833.8454664b88391d93708e8f85@elego.de> <55687266.3090400@marino.st> <20150529162028.388911007a614006049beb42@elego.de> <20150529172305.a3fc2a9865b5250a5b9140fc@elego.de> <556885FD.6010800@marino.st> <20150529180223.d467621b68ebf665da685b12@elego.de> Message-ID: <55689065.1040207@marino.st> On 5/29/2015 18:02, Olaf Wagner wrote: > On Fri, 29 May 2015 17:30:05 +0200 > John Marino wrote: > >>> I'll make a final test with an older bootstrap archive from opencm3.net >>> later. >> >> It might work -- as long as you have older gmp, mpfr, etc. I found the >> problem with those bootstrap is they were dynamically linked to >> libraries that don't exist anymore. > > Surprisingly, that went very well without any problem :-) I'm having a hard time understanding what went very well. I think you are saying you took an old bootstrap from an archive, and did Rodney's manual steps and it built without the errors I have. If so, that doesn't particularly help me unless I want to manually build another bootstrap. I have to get this thing building systematically without manual intervention or overwriting itself within a port's work area inside a clean jail. Probably my attempt isn't following Rodney's approach exactly, and maybe I have to overwrite the bootstrap rather than create an intermediate one. I'll be curious how this goes with the port and the current bootstrap (I'm trying to avoid having to generate a new 5.10 bootstrap when I feel it should be possible to use 5.8.6, but If I had to, I will) John From rodney_bates at lcwb.coop Fri May 29 18:35:41 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Fri, 29 May 2015 11:35:41 -0500 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <55688BFF.5040701@lcwb.coop> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop> <556817A1.2090206@marino.st> <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de> <55682D1A.2030504@marino.st> <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de> <55683689.2090709@marino.st> <55688BFF.5040701@lcwb.coop> Message-ID: <5568955D.4060200@lcwb.coop> Setting INSTALL_CM3_IN_BIN=yes is what forces the premature install of cm3cg. I see I had encountered this problem two years ago, but then it was happening regardless of the value of this variable. My fix only addresses the case when the variable is not set. I naively went to extra trouble to preserve the existing behavior when it is set--obviously not right. I don't see an easy way to make the variable work, as there is no constraint on the order that cm3 and cm3cg are built. do-cm3-front.sh happens to do cm3cg first, but that is not necessarily required. So INSTALL_CM3_IN_BIN is broken and hard to fix, if the two need compatible upgrades. For now, it looks like install-cm3-compiler.sh is the only working way. But maybe John and Olaf have found a different way around this. On 05/29/2015 10:55 AM, Rodney M. Bates wrote: > I don't know yet why, or what needs to change, but here is definitely the problem, starting > in line 4575 of your m3c log: > > > g++48 -O2 -pipe -fstack-protector -Wl,-rpath=/usr/local/lib/gcc48 -fno-strict-aliasing -Wl,-rpath=/usr/local/lib/gcc48 -DIN_GCC -Wno-missing-field-initializers -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -o m3cgc1 m3cg/parse.o attribs.o main.o tree-browser.o libbackend.a libcommon-target.a libcommon.a ../libcpp/libcpp.a libcommon.a ../libcpp/libcpp.a ../libiberty/libiberty.a > gmake[1]: Leaving directory `/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a/m3-sys/m3cc/AMD64_FREEBSD/gcc' > > > This is copying the newly-built cm3cg (the compiler back end) to your > bin directory: > > Forced ship of cm3cg. > --- shipping from AMD64_FREEBSD --- > > . => /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin > cm3cg > ==> m3-sys/m3cc done > > === package m3-libs/m3core === > > And this is using the cm3 (compiler front end) that was already in the bin > directory, and is the release version. > > +++ /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin/cm3 -build -DROOT='/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a' $RARGS && /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin/cm3 -ship $RARGS -DROOT='/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a' +++ > --- building in AMD64_FREEBSD --- > > ignoring ../src/m3overrides > > new source -> compiling RTHooks.i3 > > This is cm3cg (aka m3cgc1) detecting the incompatibility: > > m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > compilation terminated. > > Here is the counterpart section of my log: > > g++ -g -O2 -DIN_GCC -Wno-missing-field-initializers -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -o m3cgc1 m3cg/parse.o attribs.o main.o tree-browser.o libbackend.a libcommon-target.a libcommon.a ../libcpp/libcpp.a libcommon.a ../libcpp/libcpp.a ../libiberty/libiberty.a > > On my build, it's not shipping: > > Not shipping cm3cg. > --- shipping from AMD64_LINUX --- > > missing ".M3SHIP" file, build the package first. > ==> /home/rodney/proj/m3/git/cm3/m3-sys/m3cc done > > === package /home/rodney/proj/m3/git/cm3/m3-libs/m3core === > +++ cm3 -build -DROOT='/home/rodney/proj/m3/git/cm3' $RARGS && cm3 -ship $RARGS -DROOT='/home/rodney/proj/m3/git/cm3' +++ > --- building in AMD64_LINUX --- > > ignoring ../src/m3overrides > > new source -> compiling RTHooks.i3 > new source -> compiling RT0.i3 > > When it works, the copying of both cm3 and cm3cg to the bin directory is delayed until after both have been > built, in the 'install-cm3-compiler.sh upgrade' step. > > I see your build is using a full path to the bin directory and mine is letting > it come from the usual $PATH search, but that should make no difference, as long > as the bin directory is found in a consistent way, which seems to be the case > in both builds. > > > > On 05/29/2015 04:51 AM, John Marino wrote: >> On 5/29/2015 11:39, Olaf Wagner wrote: >>> On Fri, 29 May 2015 11:10:50 +0200 >>> John Marino wrote: >>> >>>> On 5/29/2015 10:54, Olaf Wagner wrote: >>>>> Please try what I suggested in the attached mail: define >>>>> INSTALL_CM3_IN_BIN=yes >>>>> in the environment and see if that helps. >>>>> >>>> >>>> Unfortunately it seems the result is exactly the same, even when >>>> INSTALL_CM3_IN_BIN is defined in the environment. >>> >>> Can I see the new logs? Has the new backend (cm3cg) been installed now? >>> >> >> It's here: >> http://leaf.dragonflybsd.org/~marino/m3c.log >> >> It never completes "do-cm3-front.sh buildship " >> >> Note that I'm using a bootstrap install and set INSTALL_ROOT to another >> location, but it never gets to the point of installing anything. >> >> John >> > -- Rodney Bates rodney.m.bates at acm.org From jay.krell at cornell.edu Fri May 29 20:03:10 2015 From: jay.krell at cornell.edu (Jay K) Date: Fri, 29 May 2015 18:03:10 +0000 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <556885FD.6010800@marino.st> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop> <556817A1.2090206@marino.st> <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de> <55682D1A.2030504@marino.st> <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de> <55683689.2090709@marino.st> <20150529122732.1396eb079ff9b404bcb21e40@elego.de> <5568421D.3050209@marino.st> <20150529155833.8454664b88391d93708e8f85@elego.de> <55687266.3090400@marino.st> <20150529162028.388911007a614006049beb42@elego.de>, <20150529172305.a3fc2a9865b5250a5b9140fc@elego.de>, <556885FD.6010800@marino.st> Message-ID: > It might work -- as long as you have older gmp, mpfr, etc. I found the > problem with those bootstrap is they were dynamically linked to > libraries that don't exist anymore. We went far out of our way to statically link this. Darn. > > /libexec/ld-elf.so.1: /usr/ports/lang/modula3/work/bootstrap//bin/cm3cg: Undefined symbol "_ThreadRuneLocale" _ThreadRuneLocale --- we should look into.Ideally we can build on newer systems and still target older systems.That is very commonly done on Mac and Windows, at least.Maybe there are #defines or config to suppress unused newer stuff? I also went out of my way to suppress dynamic links to libiconv.That has been a problem e.g. on Solaris.It was coming in I believe because cm3cg linked in a C preprocessor (seriously),because you know, like, all gcc frontends can use that.. (and the cm3cg backend again,is a gcc frontend, for an unusual binary-encoded language).. - Jay [snip] -------------- next part -------------- An HTML attachment was scrubbed... URL: From adacore at marino.st Fri May 29 20:10:35 2015 From: adacore at marino.st (John Marino) Date: Fri, 29 May 2015 20:10:35 +0200 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop> <556817A1.2090206@marino.st> <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de> <55682D1A.2030504@marino.st> <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de> <55683689.2090709@marino.st> <20150529122732.1396eb079ff9b404bcb21e40@elego.de> <5568421D.3050209@marino.st> <20150529155833.8454664b88391d93708e8f85@elego.de> <55687266.3090400@marino.st> <20150529162028.388911007a614006049beb42@elego.de>, <20150529172305.a3fc2a9865b5250a5b9140fc@elego.de>, <556885FD.6010800@marino.st> Message-ID: <5568AB9B.3010101@marino.st> On 5/29/2015 20:03, Jay K wrote: > > > It might work -- as long as you have older gmp, mpfr, etc. I found the > > problem with those bootstrap is they were dynamically linked to > > libraries that don't exist anymore. > > > We went far out of our way to statically link this. Darn. It is okay, the port M3 bootstrap is statically linked. > _ThreadRuneLocale --- we should look into. > Ideally we can build on newer systems and still target older systems. > That is very commonly done on Mac and Windows, at least. > Maybe there are #defines or config to suppress unused newer stuff? This was 100% my fault. The bootstrap was built on FreeBSD 9. I should have built it on FreeBSD 8, but I didn't know the impact. If I had done that, you wouldn't be seeing this error. FreeBSD 8 "expires" at the end of June, so it's a non-issue really. John From wagner at elegosoft.com Fri May 29 20:11:24 2015 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 29 May 2015 20:11:24 +0200 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <5568955D.4060200@lcwb.coop> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop> <556817A1.2090206@marino.st> <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de> <55682D1A.2030504@marino.st> <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de> <55683689.2090709@marino.st> <55688BFF.5040701@lcwb.coop> <5568955D.4060200@lcwb.coop> Message-ID: <20150529201124.fd4b2bc6b239df2a7a97cc19@elegosoft.com> On Fri, 29 May 2015 11:35:41 -0500 "Rodney M. Bates" wrote: > Setting INSTALL_CM3_IN_BIN=yes is what forces the premature install of cm3cg. > I see I had encountered this problem two years ago, but then it was happening > regardless of the value of this variable. My fix only addresses the case when > the variable is not set. I naively went to extra trouble to preserve the > existing behavior when it is set--obviously not right. > > I don't see an easy way to make the variable work, as there is no > constraint on the order that cm3 and cm3cg are built. do-cm3-front.sh > happens to do cm3cg first, but that is not necessarily required. > > So INSTALL_CM3_IN_BIN is broken and hard to fix, if the two need > compatible upgrades. For now, it looks like install-cm3-compiler.sh > is the only working way. > > But maybe John and Olaf have found a different way around this. Setting that to yes was just my suggestion after seeing in the first log that he did install cm3 but not cm3cg. I think we should all forget about INSTALL_CM3_IN_BIN now and leave that unset. I still don't undertstand what he's doing differently than a simple upgrade of the compiler based on an initial install, which does work for AMD64_FREEBSD, as I have tested it. I think it's the elaborate setup and build environment into which the rather inflexible cm3 installation is forced. Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Fri May 29 20:06:11 2015 From: jay.krell at cornell.edu (Jay K) Date: Fri, 29 May 2015 18:06:11 +0000 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <5568955D.4060200@lcwb.coop> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop> <556817A1.2090206@marino.st> <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de> <55682D1A.2030504@marino.st> <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de> <55683689.2090709@marino.st>, <55688BFF.5040701@lcwb.coop>, <5568955D.4060200@lcwb.coop> Message-ID: > I don't see an easy way to make the variable work, as there is no > constraint on the order that cm3 and cm3cg are built. do-cm3-front.sh > happens to do cm3cg first, but that is not necessarily required. [please pardon my editing...] I see what you mean that cm3cg is an independent node in the graph and can be built in any order,but, I guess, the story is/was, you have to know the safe order to ship things. It is encoded in pkginfo.txt and the Python scripts honor it..though they don't always use pkginfo.txt for their ordering..And encoding the dependency graph there isn't ideal. It is really encoded in the import declarationsin the m3makefiles, usually, but not in this case... The way that works is to build but don't ship cm3cg. Then ship cm3cg. Then copy cm3. Then use the new cm3. But perhaps it isn't strictly enforced enough. I used do this fairly often. Though breaking changes in cm3cg were rare, granted. But I'd also occasionally bootstrap from an older release. I'll have to try to do that again soon -- actually make the current tree easily buildable from the last release. update.py handled it. I'm on the fence. "buildship" of multiple packages is in general problematic. I kinda think the whole mechanism needs to be revampled. Let me draw a close analogy. In the slightly larger software world we have: make make install make install DESTDIR=somewhere_new buildship is equivalent make && make install, or a make install that includes the make part, as they sometimes do. Read up on building glibc and they point out how dangerous this is -- how dangerous make install is w/o DESTDIR. We have the same danger on a smaller scale. You aren't going to break the "OS", but you can break "cm3". The safe recommendation is make install DESTDIR. Basically "install" "everything" "on the side", get it all installed, multiple "packages", then copy or tar/untar it all. Or chroot into it and test it out, and then do an in-place update. Or swap into the chroot and never return? (tail call install) Don't do a "rolling upgrade". Don't install each package as it is built. No package, no cm3, not cm3cg, nothing. I'm basically suggesting that. Now, if you say "don't ever ship, but somehow otherwise manually copy", well that does kind of resolve to the same thing. If you say, "almost don't ever ship, but provide a way to", that is almost the same. make-dist.py follows the make install DESTDIR way. It is "better" I guess because I wrote it later, and because I was following the example of the other .sh files that make distributions. So blame/credit Olaf? :) It starts with a working compiler, copies parts into /temp, builds a new compiler into /tmp, and uses what it builds to build everything. Again I suggest it be looked into, and maybe be promoted as basically the replacement for upgrade.py and upgrade.sh. upgrade.py could wrap it and do the final steps of copy/untar in-place. Or make-dist.py could just print the last optional command. Anyway, I have no time lately, just email. :( - Jay > Date: Fri, 29 May 2015 11:35:41 -0500 > From: rodney_bates at lcwb.coop > To: adacore at marino.st; wagner at elego.de > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > > Setting INSTALL_CM3_IN_BIN=yes is what forces the premature install of cm3cg. > I see I had encountered this problem two years ago, but then it was happening > regardless of the value of this variable. My fix only addresses the case when > the variable is not set. I naively went to extra trouble to preserve the > existing behavior when it is set--obviously not right. > > I don't see an easy way to make the variable work, as there is no > constraint on the order that cm3 and cm3cg are built. do-cm3-front.sh > happens to do cm3cg first, but that is not necessarily required. > > So INSTALL_CM3_IN_BIN is broken and hard to fix, if the two need > compatible upgrades. For now, it looks like install-cm3-compiler.sh > is the only working way. > > But maybe John and Olaf have found a different way around this. > > On 05/29/2015 10:55 AM, Rodney M. Bates wrote: > > I don't know yet why, or what needs to change, but here is definitely the problem, starting > > in line 4575 of your m3c log: > > > > > > g++48 -O2 -pipe -fstack-protector -Wl,-rpath=/usr/local/lib/gcc48 -fno-strict-aliasing -Wl,-rpath=/usr/local/lib/gcc48 -DIN_GCC -Wno-missing-field-initializers -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -o m3cgc1 m3cg/parse.o attribs.o main.o tree-browser.o libbackend.a libcommon-target.a libcommon.a ../libcpp/libcpp.a libcommon.a ../libcpp/libcpp.a ../libiberty/libiberty.a > > gmake[1]: Leaving directory `/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a/m3-sys/m3cc/AMD64_FREEBSD/gcc' > > > > > > This is copying the newly-built cm3cg (the compiler back end) to your > > bin directory: > > > > Forced ship of cm3cg. > > --- shipping from AMD64_FREEBSD --- > > > > . => /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin > > cm3cg > > ==> m3-sys/m3cc done > > > > === package m3-libs/m3core === > > > > And this is using the cm3 (compiler front end) that was already in the bin > > directory, and is the release version. > > > > +++ /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin/cm3 -build -DROOT='/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a' $RARGS && /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin/cm3 -ship $RARGS -DROOT='/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a' +++ > > --- building in AMD64_FREEBSD --- > > > > ignoring ../src/m3overrides > > > > new source -> compiling RTHooks.i3 > > > > This is cm3cg (aka m3cgc1) detecting the incompatibility: > > > > m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > > compilation terminated. > > > > Here is the counterpart section of my log: > > > > g++ -g -O2 -DIN_GCC -Wno-missing-field-initializers -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -o m3cgc1 m3cg/parse.o attribs.o main.o tree-browser.o libbackend.a libcommon-target.a libcommon.a ../libcpp/libcpp.a libcommon.a ../libcpp/libcpp.a ../libiberty/libiberty.a > > > > On my build, it's not shipping: > > > > Not shipping cm3cg. > > --- shipping from AMD64_LINUX --- > > > > missing ".M3SHIP" file, build the package first. > > ==> /home/rodney/proj/m3/git/cm3/m3-sys/m3cc done > > > > === package /home/rodney/proj/m3/git/cm3/m3-libs/m3core === > > +++ cm3 -build -DROOT='/home/rodney/proj/m3/git/cm3' $RARGS && cm3 -ship $RARGS -DROOT='/home/rodney/proj/m3/git/cm3' +++ > > --- building in AMD64_LINUX --- > > > > ignoring ../src/m3overrides > > > > new source -> compiling RTHooks.i3 > > new source -> compiling RT0.i3 > > > > When it works, the copying of both cm3 and cm3cg to the bin directory is delayed until after both have been > > built, in the 'install-cm3-compiler.sh upgrade' step. > > > > I see your build is using a full path to the bin directory and mine is letting > > it come from the usual $PATH search, but that should make no difference, as long > > as the bin directory is found in a consistent way, which seems to be the case > > in both builds. > > > > > > > > On 05/29/2015 04:51 AM, John Marino wrote: > >> On 5/29/2015 11:39, Olaf Wagner wrote: > >>> On Fri, 29 May 2015 11:10:50 +0200 > >>> John Marino wrote: > >>> > >>>> On 5/29/2015 10:54, Olaf Wagner wrote: > >>>>> Please try what I suggested in the attached mail: define > >>>>> INSTALL_CM3_IN_BIN=yes > >>>>> in the environment and see if that helps. > >>>>> > >>>> > >>>> Unfortunately it seems the result is exactly the same, even when > >>>> INSTALL_CM3_IN_BIN is defined in the environment. > >>> > >>> Can I see the new logs? Has the new backend (cm3cg) been installed now? > >>> > >> > >> It's here: > >> http://leaf.dragonflybsd.org/~marino/m3c.log > >> > >> It never completes "do-cm3-front.sh buildship " > >> > >> Note that I'm using a bootstrap install and set INSTALL_ROOT to another > >> location, but it never gets to the point of installing anything. > >> > >> John > >> > > > > -- > Rodney Bates > rodney.m.bates at acm.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Fri May 29 20:15:31 2015 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 29 May 2015 20:15:31 +0200 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <55689065.1040207@marino.st> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop> <556817A1.2090206@marino.st> <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de> <55682D1A.2030504@marino.st> <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de> <55683689.2090709@marino.st> <20150529122732.1396eb079ff9b404bcb21e40@elego.de> <5568421D.3050209@marino.st> <20150529155833.8454664b88391d93708e8f85@elego.de> <55687266.3090400@marino.st> <20150529162028.388911007a614006049beb42@elego.de> <20150529172305.a3fc2a9865b5250a5b9140fc@elego.de> <556885FD.6010800@marino.st> <20150529180223.d467621b68ebf665da685b12@elego.de> <55689065.1040207@marino.st> Message-ID: <20150529201531.b35e3cfdafeb9e2735e0020b@elegosoft.com> On Fri, 29 May 2015 18:14:29 +0200 John Marino wrote: > On 5/29/2015 18:02, Olaf Wagner wrote: > > On Fri, 29 May 2015 17:30:05 +0200 > > John Marino wrote: > > > >>> I'll make a final test with an older bootstrap archive from opencm3.net > >>> later. > >> > >> It might work -- as long as you have older gmp, mpfr, etc. I found the > >> problem with those bootstrap is they were dynamically linked to > >> libraries that don't exist anymore. > > > > Surprisingly, that went very well without any problem :-) > > I'm having a hard time understanding what went very well. I think you > are saying you took an old bootstrap from an archive, and did Rodney's > manual steps and it built without the errors I have. > > If so, that doesn't particularly help me unless I want to manually build > another bootstrap. I have to get this thing building systematically > without manual intervention or overwriting itself within a port's work > area inside a clean jail. > > Probably my attempt isn't following Rodney's approach exactly, and maybe > I have to overwrite the bootstrap rather than create an intermediate one. > > I'll be curious how this goes with the port and the current bootstrap > (I'm trying to avoid having to generate a new 5.10 bootstrap when I feel > it should be possible to use 5.8.6, but If I had to, I will) Well, yes, I understand that. I would have tried your exact setup, but I have no system available to test that on. At least I have validated that based on the origianl 5.8.6 installation archive for AMD64_FREEBSD you can build the new compiler from the current sources with a simple call of the upgrade.sh script. which I still doubted yesterday. Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From adacore at marino.st Fri May 29 20:43:30 2015 From: adacore at marino.st (John Marino) Date: Fri, 29 May 2015 20:43:30 +0200 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <20150529201531.b35e3cfdafeb9e2735e0020b@elegosoft.com> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop> <556817A1.2090206@marino.st> <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de> <55682D1A.2030504@marino.st> <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de> <55683689.2090709@marino.st> <20150529122732.1396eb079ff9b404bcb21e40@elego.de> <5568421D.3050209@marino.st> <20150529155833.8454664b88391d93708e8f85@elego.de> <55687266.3090400@marino.st> <20150529162028.388911007a614006049beb42@elego.de> <20150529172305.a3fc2a9865b5250a5b9140fc@elego.de> <556885FD.6010800@marino.st> <20150529180223.d467621b68ebf665da685b12@elego.de> <55689065.1040207@marino.st> <20150529201531.b35e3cfdafeb9e2735e0020b@elegosoft.com> Message-ID: <5568B352.8060005@marino.st> On 5/29/2015 20:15, Olaf Wagner wrote: > > Well, yes, I understand that. I would have tried your exact setup, > but I have no system available to test that on. > > At least I have validated that based on the origianl 5.8.6 installation > archive for AMD64_FREEBSD you can build the new compiler from the current > sources with a simple call of the upgrade.sh script. which I still doubted > yesterday. The card I still have left to play is to extract the bootstrap, let it overwrite itself per Rodney's technique and then build the real compiler (dumping the whole "intermediate" area). I would try that now but I've booted into another OS to work on some GCC patches that are long overdue to be submitted. John From estellnb at elstel.org Fri May 29 21:00:44 2015 From: estellnb at elstel.org (Elmar Stellnberger) Date: Fri, 29 May 2015 21:00:44 +0200 Subject: [M3devel] WeakRef.T does not clean all WeakRefs on prorgam exit Message-ID: <5568B75C.4010202@elstel.org> Today I was writing an object oriented interface to some external library. As every object holds at least a reference to an embedded C-heap object I wanted to make use of WeakRefs to get an automatic cleanup for the embedded C-heap objects. However I had to notice that no cleanup occurs and that the reference can still be reconstructed from the WeakRef even after assigning NULL and running the garbage collector by calling two times RTCollectorSRC.StartCollection & FinishCollection in sequence. I have further tried to disable incremental and generational collection and to set the gcRatio to 100.0 as well as moving the RefAny into a subprocedure but all of it did not help either. There is only one Refany in my program and thus no cyclic dependency. Does anyone have a suggestion on how I could make the automatic cleanup work ready for testing it (appart from calling the cleanup proc directly)? From the past I know the WeakRef implementation of PM3 to some extent: there was no special cleanup on program exit. I believe on program exit all WeakRefs should be freed in order to let the operating system reclaim all resources. Under Linux that should work automatically though some resources like sockets may last long until they become available again. Other OSes like the eComstation can not reclaim all resources when it comes f.i. to shared memory. Anyone here who believes that special cleanup for WeakRefs should be done on program exit? ... and one more question about how to handle WeakRefs? Do I need to keep the WeakRef-record after installing the cleanup proc with WeakRef.FromRef(...)? - or may I simply discard it while the cleanup should still be done without it? From estellnb at elstel.org Fri May 29 21:13:38 2015 From: estellnb at elstel.org (Elmar Stellnberger) Date: Fri, 29 May 2015 21:13:38 +0200 Subject: [M3devel] WeakRef.T does not clean all WeakRefs on prorgam exit Message-ID: <5568BA62.9070109@elstel.org> Today I was writing an object oriented interface to some external library. As every object holds at least a reference to an embedded C-heap object I wanted to make use of WeakRefs to get an automatic cleanup for the embedded C-heap objects. However I had to notice that no cleanup occurs and that the reference can still be reconstructed from the WeakRef even after assigning NULL and running the garbage collector by calling two times RTCollectorSRC.StartCollection & FinishCollection in sequence. I have further tried to disable incremental and generational collection and to set the gcRatio to 100.0 as well as moving the RefAny into a subprocedure but all of it did not help either. There is only one Refany in my program and thus no cyclic dependency. Does anyone have a suggestion on how I could make the automatic cleanup work ready for testing it (appart from calling the cleanup proc directly)? From the past I know the WeakRef implementation of PM3 to some extent: there was no special cleanup on program exit. I believe on program exit all WeakRefs should be freed in order to let the operating system reclaim all resources. Under Linux that should work automatically though some resources like sockets may last long until they become available again. Other OSes like the eComstation can not reclaim all resources when it comes f.i. to shared memory. Anyone here who believes that special cleanup for WeakRefs should be done on program exit? ... and one more question about how to handle WeakRefs? Do I need to keep the WeakRef-record after installing the cleanup proc with WeakRef.FromRef(...)? - or may I simply discard it while the cleanup should still be done without it? From jay.krell at cornell.edu Fri May 29 22:49:30 2015 From: jay.krell at cornell.edu (Jay K) Date: Fri, 29 May 2015 20:49:30 +0000 Subject: [M3devel] WeakRef.T does not clean all WeakRefs on prorgam exit In-Reply-To: <5568BA62.9070109@elstel.org> References: <5568BA62.9070109@elstel.org> Message-ID: Imho you should take this approach: If you are only managing memory and file handles and socket handles, or Win32 kernel handles (events/mutexes/semaphores/registry keys), you should just rely on the kernel cleaning everything up when the process dies. Doing everything peacemeal is just a waste of time. Imagine that there is a null deref and you abruptly go away.That shouldn't/doesn't leak either.And attempting to cleanup in this path is dangerous. In fact, any resource that you want to guaranteeably be cleaned up, should be backed by the kernel. If you are talking over the network to something, and you abruptly exit, that network server will eventually notice a timeout and clean up anything it has allocated on your behalf. Now, on the other hand, if your .dll is gracefull unloaded and the processis still running, that is another matter, and one I suspect we don't handle.I'm not sure we really handle .dll/.sos in Modula-3 w/o the main executable being Modula-3.That could use repair.On Windows it is a matter of writing DllMain in m3core.Likely something similar on the other systems. Heck, maybe just a C++ static with a constructor and destructor.That is kinda the portable interface to DllMain(process attach) and whatever are the Unix analogs.Seriously. Just as we have main optionally in C. Agreed? Thread notifications would also be nice. This is an area that hasn't evolved as well as process notification. - Jay > Date: Fri, 29 May 2015 21:13:38 +0200 > From: estellnb at elstel.org > To: m3devel at elegosoft.com > Subject: [M3devel] WeakRef.T does not clean all WeakRefs on prorgam exit > > Today I was writing an object oriented interface to some external > library. > As every object holds at least a reference to an embedded C-heap object I > wanted to make use of WeakRefs to get an automatic cleanup for the > embedded C-heap objects. However I had to notice that no cleanup occurs > and that the reference can still be reconstructed from the WeakRef even > after assigning NULL and running the garbage collector by calling two times > RTCollectorSRC.StartCollection & FinishCollection in sequence. I have > further tried to disable incremental and generational collection and to set > the gcRatio to 100.0 as well as moving the RefAny into a subprocedure > but all of it did not help either. There is only one Refany in my program > and thus no cyclic dependency. > Does anyone have a suggestion on how I could make the automatic > cleanup work ready for testing it (appart from calling the cleanup proc > directly)? > From the past I know the WeakRef implementation of PM3 to some extent: > there was no special cleanup on program exit. I believe on program exit > all WeakRefs should be freed in order to let the operating system reclaim > all resources. Under Linux that should work automatically though some > resources like sockets may last long until they become available again. > Other OSes like the eComstation can not reclaim all resources when it > comes f.i. to shared memory. > Anyone here who believes that special cleanup for WeakRefs should be > done on program exit? > > ... and one more question about how to handle WeakRefs? > Do I need to keep the WeakRef-record after installing the cleanup proc > with WeakRef.FromRef(...)? - or may I simply discard it while the cleanup > should still be done without it? > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Fri May 29 23:10:41 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Fri, 29 May 2015 16:10:41 -0500 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop> <556817A1.2090206@marino.st> <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de> <55682D1A.2030504@marino.st> <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de> <55683689.2090709@marino.st>, <55688BFF.5040701@lcwb.coop>, <5568955D.4060200@lcwb.coop> Message-ID: <5568D5D1.5040405@lcwb.coop> Yes, we could have a better organization. I agree, the principal way should be to build a complete set of everything that matters to the implementation of the language, them replace them all at once. A separate DESTDIR or such is needed. The set, as Jay points out, is larger than just cm3 and m3cc. It includes at least m3core, probably libm3, and cm3, the executable depends on several separately built packages--cm3, m3middle, m3front, m3quake, m3makefile, etc. In general, we can't really assume anything about the kinds of dependencies of one package on old or new versions of another. Right now, cm3 and m3cc are known mutually incompatible between 5.8 and the head, because the numbering in M3CG_Binary.i3 has changed. We could probably establish some coding rules and order-of-install rules that would allow a newer m3cc to work with an older cm3, but that's only one pattern. I once thought do-cm3-*.sh build would do what we are talking about, but it if I remember right, puts every package into immediate use as it is built and also uses overrides, which keeps things inside the source tree, but makes it unshippable. So I always use buildship. This has never, to my knowledge run afoul of any compatibility problem other than between cm3 and m3cc, but it does ship every package besides these two as it is built, so the potential is there. I haven't had the energy to even try to understand just what the upgrade scripts do, but they have not treated me well. If I had done different patterns of incompatible changes, they would probably have been better than the procedure I use. On 05/29/2015 01:06 PM, Jay K wrote: > > I don't see an easy way to make the variable work, as there is no > > constraint on the order that cm3 and cm3cg are built. do-cm3-front.sh > > happens to do cm3cg first, but that is not necessarily required. > > [please pardon my editing...] > > > I see what you mean that cm3cg is an independent node in the graph and can be built in any order, > but, I guess, the story is/was, you have to know the safe order to ship things. > > > It is encoded in pkginfo.txt and the Python scripts honor it..though they don't always use pkginfo.txt for their ordering.. > And encoding the dependency graph there isn't ideal. It is really encoded in the import declarations > in the m3makefiles, usually, but not in this case... > > > The way that works is to build but don't ship cm3cg. > Then ship cm3cg. > Then copy cm3. > Then use the new cm3. > But perhaps it isn't strictly enforced enough. > > > > I used do this fairly often. > Though breaking changes in cm3cg were rare, granted. > But I'd also occasionally bootstrap from an older release. > I'll have to try to do that again soon -- actually make the current > tree easily buildable from the last release. > > > update.py handled it. > > > I'm on the fence. > "buildship" of multiple packages is in general problematic. > I kinda think the whole mechanism needs to be revampled. > > > Let me draw a close analogy. > > > In the slightly larger software world we have: > > make > make install > make install DESTDIR=somewhere_new > > > buildship is equivalent make && make install, or a make install that includes the make part, > as they sometimes do. > Read up on building glibc and they point out how dangerous this is -- how dangerous make install is w/o DESTDIR. > We have the same danger on a smaller scale. > You aren't going to break the "OS", but you can break "cm3". > > > The safe recommendation is make install DESTDIR. > Basically "install" "everything" "on the side", get it all installed, multiple > "packages", then copy or tar/untar it all. Or chroot into it and test it out, and > then do an in-place update. Or swap into the chroot and never return? (tail call install) > > > Don't do a "rolling upgrade". Don't install each package as it is built. No package, no cm3, > not cm3cg, nothing. > > > I'm basically suggesting that. > > > Now, if you say "don't ever ship, but somehow otherwise manually copy", well > that does kind of resolve to the same thing. > > > If you say, "almost don't ever ship, but provide a way to", that is almost the same. > > > make-dist.py follows the make install DESTDIR way. > > It is "better" I guess because I wrote it later, and because I was following > the example of the other .sh files that make distributions. So blame/credit Olaf? :) > > > It starts with a working compiler, copies parts into /temp, builds a new compiler into /tmp, and > uses what it builds to build everything. > > > Again I suggest it be looked into, and maybe be promoted as basically > the replacement for upgrade.py and upgrade.sh. > > > upgrade.py could wrap it and do the final steps of copy/untar in-place. > Or make-dist.py could just print the last optional command. > > > Anyway, I have no time lately, just email. :( > > > - Jay > > > > > Date: Fri, 29 May 2015 11:35:41 -0500 > > From: rodney_bates at lcwb.coop > > To: adacore at marino.st; wagner at elego.de > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > > > > Setting INSTALL_CM3_IN_BIN=yes is what forces the premature install of cm3cg. > > I see I had encountered this problem two years ago, but then it was happening > > regardless of the value of this variable. My fix only addresses the case when > > the variable is not set. I naively went to extra trouble to preserve the > > existing behavior when it is set--obviously not right. > > > > I don't see an easy way to make the variable work, as there is no > > constraint on the order that cm3 and cm3cg are built. do-cm3-front.sh > > happens to do cm3cg first, but that is not necessarily required. > > > > So INSTALL_CM3_IN_BIN is broken and hard to fix, if the two need > > compatible upgrades. For now, it looks like install-cm3-compiler.sh > > is the only working way. > > > > But maybe John and Olaf have found a different way around this. > > > > On 05/29/2015 10:55 AM, Rodney M. Bates wrote: > > > I don't know yet why, or what needs to change, but here is definitely the problem, starting > > > in line 4575 of your m3c log: > > > > > > > > > g++48 -O2 -pipe -fstack-protector -Wl,-rpath=/usr/local/lib/gcc48 -fno-strict-aliasing -Wl,-rpath=/usr/local/lib/gcc48 -DIN_GCC -Wno-missing-field-initializers -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -o m3cgc1 m3cg/parse.o attribs.o main.o tree-browser.o libbackend.a libcommon-target.a libcommon.a ../libcpp/libcpp.a libcommon.a ../libcpp/libcpp.a ../libiberty/libiberty.a > > > gmake[1]: Leaving directory `/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a/m3-sys/m3cc/AMD64_FREEBSD/gcc' > > > > > > > > > This is copying the newly-built cm3cg (the compiler back end) to your > > > bin directory: > > > > > > Forced ship of cm3cg. > > > --- shipping from AMD64_FREEBSD --- > > > > > > . => /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin > > > cm3cg > > > ==> m3-sys/m3cc done > > > > > > === package m3-libs/m3core === > > > > > > And this is using the cm3 (compiler front end) that was already in the bin > > > directory, and is the release version. > > > > > > +++ /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin/cm3 -build -DROOT='/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a' $RARGS && /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin/cm3 -ship $RARGS -DROOT='/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a' +++ > > > --- building in AMD64_FREEBSD --- > > > > > > ignoring ../src/m3overrides > > > > > > new source -> compiling RTHooks.i3 > > > > > > This is cm3cg (aka m3cgc1) detecting the incompatibility: > > > > > > m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > > > compilation terminated. > > > > > > Here is the counterpart section of my log: > > > > > > g++ -g -O2 -DIN_GCC -Wno-missing-field-initializers -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -o m3cgc1 m3cg/parse.o attribs.o main.o tree-browser.o libbackend.a libcommon-target.a libcommon.a ../libcpp/libcpp.a libcommon.a ../libcpp/libcpp.a ../libiberty/libiberty.a > > > > > > On my build, it's not shipping: > > > > > > Not shipping cm3cg. > > > --- shipping from AMD64_LINUX --- > > > > > > missing ".M3SHIP" file, build the package first. > > > ==> /home/rodney/proj/m3/git/cm3/m3-sys/m3cc done > > > > > > === package /home/rodney/proj/m3/git/cm3/m3-libs/m3core === > > > +++ cm3 -build -DROOT='/home/rodney/proj/m3/git/cm3' $RARGS && cm3 -ship $RARGS -DROOT='/home/rodney/proj/m3/git/cm3' +++ > > > --- building in AMD64_LINUX --- > > > > > > ignoring ../src/m3overrides > > > > > > new source -> compiling RTHooks.i3 > > > new source -> compiling RT0.i3 > > > > > > When it works, the copying of both cm3 and cm3cg to the bin directory is delayed until after both have been > > > built, in the 'install-cm3-compiler.sh upgrade' step. > > > > > > I see your build is using a full path to the bin directory and mine is letting > > > it come from the usual $PATH search, but that should make no difference, as long > > > as the bin directory is found in a consistent way, which seems to be the case > > > in both builds. > > > > > > > > > > > > On 05/29/2015 04:51 AM, John Marino wrote: > > >> On 5/29/2015 11:39, Olaf Wagner wrote: > > >>> On Fri, 29 May 2015 11:10:50 +0200 > > >>> John Marino wrote: > > >>> > > >>>> On 5/29/2015 10:54, Olaf Wagner wrote: > > >>>>> Please try what I suggested in the attached mail: define > > >>>>> INSTALL_CM3_IN_BIN=yes > > >>>>> in the environment and see if that helps. > > >>>>> > > >>>> > > >>>> Unfortunately it seems the result is exactly the same, even when > > >>>> INSTALL_CM3_IN_BIN is defined in the environment. > > >>> > > >>> Can I see the new logs? Has the new backend (cm3cg) been installed now? > > >>> > > >> > > >> It's here: > > >> http://leaf.dragonflybsd.org/~marino/m3c.log > > >> > > >> It never completes "do-cm3-front.sh buildship " > > >> > > >> Note that I'm using a bootstrap install and set INSTALL_ROOT to another > > >> location, but it never gets to the point of installing anything. > > >> > > >> John > > >> > > > > > > > -- > > Rodney Bates > > rodney.m.bates at acm.org -- Rodney Bates rodney.m.bates at acm.org From jay.krell at cornell.edu Sat May 30 00:31:50 2015 From: jay.krell at cornell.edu (Jay K) Date: Fri, 29 May 2015 22:31:50 +0000 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <5568D5D1.5040405@lcwb.coop> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop> <556817A1.2090206@marino.st> <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de> <55682D1A.2030504@marino.st> <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de> <55683689.2090709@marino.st>,,<55688BFF.5040701@lcwb.coop>, <5568955D.4060200@lcwb.coop>, , <5568D5D1.5040405@lcwb.coop> Message-ID: cm3/cm3cg are more special than the others, because cm3 is statically linked. There is no m3core.dll, that cm3 uses, or m3quake.dll, etc. There is m3core.dll, but cm3 doesn't uses it. Shipping it doesn't affect the in-use cm3. If/when we fix this, in fact, we can stop doing that static linking. It makes sense for m3quake, etc. as there are few/no other users. But for libm3/m3core, it'll provide a nice size optimization. The mutual incompatibilty between old/new cm3/cm3cg is perfectly ok. It is meant to be dealt with, not avoided. I believe upgrade.py did deal with this correctly, but this environment variable required to quash shipping of cm3cg broke it. The environment variable change really should imho be removed from cm3cg. Please. And then we can switch to "destdir" and remove all the in place updating, perhaps. Or I need to update upgrade.py to ship cm3cg itself. I guess I'll do that. upgrade.py may not have worked for you, but I have used it many many times.It worked. But currently it is probably broken by the m3cc/src/m3makefile change.I'll update it to accommodate that change.. And upgrade.sh I believe was in heavy use by Hudson. - Jay > Date: Fri, 29 May 2015 16:10:41 -0500 > From: rodney_bates at lcwb.coop > CC: m3devel at elegosoft.com > To: > Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > > Yes, we could have a better organization. I agree, the principal way > should be to build a complete set of everything that matters to the > implementation of the language, them replace them all at once. A > separate DESTDIR or such is needed. > > The set, as Jay points out, is larger than just cm3 and m3cc. It includes > at least m3core, probably libm3, and cm3, the executable depends on several > separately built packages--cm3, m3middle, m3front, m3quake, m3makefile, etc. > > In general, we can't really assume anything about the kinds of dependencies > of one package on old or new versions of another. Right now, cm3 and m3cc > are known mutually incompatible between 5.8 and the head, because the numbering > in M3CG_Binary.i3 has changed. We could probably establish some coding rules and > order-of-install rules that would allow a newer m3cc to work with an older cm3, > but that's only one pattern. > > I once thought do-cm3-*.sh build would do what we are talking about, but it > if I remember right, puts every package into immediate use as it is built > and also uses overrides, which keeps things inside the source tree, but makes > it unshippable. So I always use buildship. This has never, to my knowledge > run afoul of any compatibility problem other than between cm3 and m3cc, but it > does ship every package besides these two as it is built, so the potential > is there. > > I haven't had the energy to even try to understand just what the upgrade > scripts do, but they have not treated me well. If I had done different > patterns of incompatible changes, they would probably have been better > than the procedure I use. > > On 05/29/2015 01:06 PM, Jay K wrote: > > > I don't see an easy way to make the variable work, as there is no > > > constraint on the order that cm3 and cm3cg are built. do-cm3-front.sh > > > happens to do cm3cg first, but that is not necessarily required. > > > > [please pardon my editing...] > > > > > > I see what you mean that cm3cg is an independent node in the graph and can be built in any order, > > but, I guess, the story is/was, you have to know the safe order to ship things. > > > > > > It is encoded in pkginfo.txt and the Python scripts honor it..though they don't always use pkginfo.txt for their ordering.. > > And encoding the dependency graph there isn't ideal. It is really encoded in the import declarations > > in the m3makefiles, usually, but not in this case... > > > > > > The way that works is to build but don't ship cm3cg. > > Then ship cm3cg. > > Then copy cm3. > > Then use the new cm3. > > But perhaps it isn't strictly enforced enough. > > > > > > > > I used do this fairly often. > > Though breaking changes in cm3cg were rare, granted. > > But I'd also occasionally bootstrap from an older release. > > I'll have to try to do that again soon -- actually make the current > > tree easily buildable from the last release. > > > > > > update.py handled it. > > > > > > I'm on the fence. > > "buildship" of multiple packages is in general problematic. > > I kinda think the whole mechanism needs to be revampled. > > > > > > Let me draw a close analogy. > > > > > > In the slightly larger software world we have: > > > > make > > make install > > make install DESTDIR=somewhere_new > > > > > > buildship is equivalent make && make install, or a make install that includes the make part, > > as they sometimes do. > > Read up on building glibc and they point out how dangerous this is -- how dangerous make install is w/o DESTDIR. > > We have the same danger on a smaller scale. > > You aren't going to break the "OS", but you can break "cm3". > > > > > > The safe recommendation is make install DESTDIR. > > Basically "install" "everything" "on the side", get it all installed, multiple > > "packages", then copy or tar/untar it all. Or chroot into it and test it out, and > > then do an in-place update. Or swap into the chroot and never return? (tail call install) > > > > > > Don't do a "rolling upgrade". Don't install each package as it is built. No package, no cm3, > > not cm3cg, nothing. > > > > > > I'm basically suggesting that. > > > > > > Now, if you say "don't ever ship, but somehow otherwise manually copy", well > > that does kind of resolve to the same thing. > > > > > > If you say, "almost don't ever ship, but provide a way to", that is almost the same. > > > > > > make-dist.py follows the make install DESTDIR way. > > > > It is "better" I guess because I wrote it later, and because I was following > > the example of the other .sh files that make distributions. So blame/credit Olaf? :) > > > > > > It starts with a working compiler, copies parts into /temp, builds a new compiler into /tmp, and > > uses what it builds to build everything. > > > > > > Again I suggest it be looked into, and maybe be promoted as basically > > the replacement for upgrade.py and upgrade.sh. > > > > > > upgrade.py could wrap it and do the final steps of copy/untar in-place. > > Or make-dist.py could just print the last optional command. > > > > > > Anyway, I have no time lately, just email. :( > > > > > > - Jay > > > > > > > > > Date: Fri, 29 May 2015 11:35:41 -0500 > > > From: rodney_bates at lcwb.coop > > > To: adacore at marino.st; wagner at elego.de > > > CC: m3devel at elegosoft.com > > > Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > > > > > > Setting INSTALL_CM3_IN_BIN=yes is what forces the premature install of cm3cg. > > > I see I had encountered this problem two years ago, but then it was happening > > > regardless of the value of this variable. My fix only addresses the case when > > > the variable is not set. I naively went to extra trouble to preserve the > > > existing behavior when it is set--obviously not right. > > > > > > I don't see an easy way to make the variable work, as there is no > > > constraint on the order that cm3 and cm3cg are built. do-cm3-front.sh > > > happens to do cm3cg first, but that is not necessarily required. > > > > > > So INSTALL_CM3_IN_BIN is broken and hard to fix, if the two need > > > compatible upgrades. For now, it looks like install-cm3-compiler.sh > > > is the only working way. > > > > > > But maybe John and Olaf have found a different way around this. > > > > > > On 05/29/2015 10:55 AM, Rodney M. Bates wrote: > > > > I don't know yet why, or what needs to change, but here is definitely the problem, starting > > > > in line 4575 of your m3c log: > > > > > > > > > > > > g++48 -O2 -pipe -fstack-protector -Wl,-rpath=/usr/local/lib/gcc48 -fno-strict-aliasing -Wl,-rpath=/usr/local/lib/gcc48 -DIN_GCC -Wno-missing-field-initializers -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -o m3cgc1 m3cg/parse.o attribs.o main.o tree-browser.o libbackend.a libcommon-target.a libcommon.a ../libcpp/libcpp.a libcommon.a ../libcpp/libcpp.a ../libiberty/libiberty.a > > > > gmake[1]: Leaving directory `/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a/m3-sys/m3cc/AMD64_FREEBSD/gcc' > > > > > > > > > > > > This is copying the newly-built cm3cg (the compiler back end) to your > > > > bin directory: > > > > > > > > Forced ship of cm3cg. > > > > --- shipping from AMD64_FREEBSD --- > > > > > > > > . => /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin > > > > cm3cg > > > > ==> m3-sys/m3cc done > > > > > > > > === package m3-libs/m3core === > > > > > > > > And this is using the cm3 (compiler front end) that was already in the bin > > > > directory, and is the release version. > > > > > > > > +++ /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin/cm3 -build -DROOT='/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a' $RARGS && /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin/cm3 -ship $RARGS -DROOT='/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a' +++ > > > > --- building in AMD64_FREEBSD --- > > > > > > > > ignoring ../src/m3overrides > > > > > > > > new source -> compiling RTHooks.i3 > > > > > > > > This is cm3cg (aka m3cgc1) detecting the incompatibility: > > > > > > > > m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > > > > compilation terminated. > > > > > > > > Here is the counterpart section of my log: > > > > > > > > g++ -g -O2 -DIN_GCC -Wno-missing-field-initializers -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -o m3cgc1 m3cg/parse.o attribs.o main.o tree-browser.o libbackend.a libcommon-target.a libcommon.a ../libcpp/libcpp.a libcommon.a ../libcpp/libcpp.a ../libiberty/libiberty.a > > > > > > > > On my build, it's not shipping: > > > > > > > > Not shipping cm3cg. > > > > --- shipping from AMD64_LINUX --- > > > > > > > > missing ".M3SHIP" file, build the package first. > > > > ==> /home/rodney/proj/m3/git/cm3/m3-sys/m3cc done > > > > > > > > === package /home/rodney/proj/m3/git/cm3/m3-libs/m3core === > > > > +++ cm3 -build -DROOT='/home/rodney/proj/m3/git/cm3' $RARGS && cm3 -ship $RARGS -DROOT='/home/rodney/proj/m3/git/cm3' +++ > > > > --- building in AMD64_LINUX --- > > > > > > > > ignoring ../src/m3overrides > > > > > > > > new source -> compiling RTHooks.i3 > > > > new source -> compiling RT0.i3 > > > > > > > > When it works, the copying of both cm3 and cm3cg to the bin directory is delayed until after both have been > > > > built, in the 'install-cm3-compiler.sh upgrade' step. > > > > > > > > I see your build is using a full path to the bin directory and mine is letting > > > > it come from the usual $PATH search, but that should make no difference, as long > > > > as the bin directory is found in a consistent way, which seems to be the case > > > > in both builds. > > > > > > > > > > > > > > > > On 05/29/2015 04:51 AM, John Marino wrote: > > > >> On 5/29/2015 11:39, Olaf Wagner wrote: > > > >>> On Fri, 29 May 2015 11:10:50 +0200 > > > >>> John Marino wrote: > > > >>> > > > >>>> On 5/29/2015 10:54, Olaf Wagner wrote: > > > >>>>> Please try what I suggested in the attached mail: define > > > >>>>> INSTALL_CM3_IN_BIN=yes > > > >>>>> in the environment and see if that helps. > > > >>>>> > > > >>>> > > > >>>> Unfortunately it seems the result is exactly the same, even when > > > >>>> INSTALL_CM3_IN_BIN is defined in the environment. > > > >>> > > > >>> Can I see the new logs? Has the new backend (cm3cg) been installed now? > > > >>> > > > >> > > > >> It's here: > > > >> http://leaf.dragonflybsd.org/~marino/m3c.log > > > >> > > > >> It never completes "do-cm3-front.sh buildship " > > > >> > > > >> Note that I'm using a bootstrap install and set INSTALL_ROOT to another > > > >> location, but it never gets to the point of installing anything. > > > >> > > > >> John > > > >> > > > > > > > > > > -- > > > Rodney Bates > > > rodney.m.bates at acm.org > > -- > Rodney Bates > rodney.m.bates at acm.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Sat May 30 16:55:37 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sat, 30 May 2015 09:55:37 -0500 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop> <556817A1.2090206@marino.st> <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de> <55682D1A.2030504@marino.st> <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de> <55683689.2090709@marino.st>, , <55688BFF.5040701@lcwb.coop>, <5568955D.4060200@lcwb.coop>, , <5568D5D1.5040405@lcwb.coop> Message-ID: <5569CF69.6020504@lcwb.coop> On 05/29/2015 05:31 PM, Jay K wrote: > cm3/cm3cg are more special than the others, because cm3 is statically linked. > There is no m3core.dll, that cm3 uses, or m3quake.dll, etc. > There is m3core.dll, but cm3 doesn't uses it. > Shipping it doesn't affect the in-use cm3. > > > If/when we fix this, in fact, we can stop doing that static linking. > It makes sense for m3quake, etc. as there are few/no other users. > But for libm3/m3core, it'll provide a nice size optimization. > > > The mutual incompatibilty between old/new cm3/cm3cg is perfectly ok. > It is meant to be dealt with, not avoided. > > > I believe upgrade.py did deal with this correctly, but this environment > variable required to quash shipping of cm3cg broke it. > > > The environment variable change really should imho be removed from cm3cg. > Please. > Jay, I am not sure what you are proposing. When I first looked at the commit for this change, I was quite confused by my own change. While the comments say it is to _not_ prematurely ship cm3cg, the code appears to add code to conditionally ship if INSTALL_CM3_IN_BIN=yes. After the n-th look, I realized that before the change, it _always_ shipped, regardless of the variable. So it really does provide for less premature shipping. If I just revert it, do-cm3-front.sh will be unconditionally and unusably broken. As is, it is at least usable if you don't set the variable. Even if there is some use case where one would want it to ship, (none occurs to me), as is, you can get this behavior by just setting the variable. Moreover, the current behavior for cm3cg is consistent with the current and long-standing behavior for cm3, i.e., ship iff the variable is set. It would make more sense to me to remove the variable check by unconditionally _not_ shipping. At least do-cm3-front.sh would be usable. But then, what would be the purpose of the inconsistent use of the variable for cm3? > > And then we can switch to "destdir" and remove all the in place updating, perhaps. > > > Or I need to update upgrade.py to ship cm3cg itself. > I guess I'll do that. > > > upgrade.py may not have worked for you, but I have used it many many times. > It worked. But currently it is probably broken by the m3cc/src/m3makefile change. > I'll update it to accommodate that change.. > > > And upgrade.sh I believe was in heavy use by Hudson. > > > - Jay > > > > > Date: Fri, 29 May 2015 16:10:41 -0500 > > From: rodney_bates at lcwb.coop > > CC: m3devel at elegosoft.com > > To: > > Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > > > > Yes, we could have a better organization. I agree, the principal way > > should be to build a complete set of everything that matters to the > > implementation of the language, them replace them all at once. A > > separate DESTDIR or such is needed. > > > > The set, as Jay points out, is larger than just cm3 and m3cc. It includes > > at least m3core, probably libm3, and cm3, the executable depends on several > > separately built packages--cm3, m3middle, m3front, m3quake, m3makefile, etc. > > > > In general, we can't really assume anything about the kinds of dependencies > > of one package on old or new versions of another. Right now, cm3 and m3cc > > are known mutually incompatible between 5.8 and the head, because the numbering > > in M3CG_Binary.i3 has changed. We could probably establish some coding rules and > > order-of-install rules that would allow a newer m3cc to work with an older cm3, > > but that's only one pattern. > > > > I once thought do-cm3-*.sh build would do what we are talking about, but it > > if I remember right, puts every package into immediate use as it is built > > and also uses overrides, which keeps things inside the source tree, but makes > > it unshippable. So I always use buildship. This has never, to my knowledge > > run afoul of any compatibility problem other than between cm3 and m3cc, but it > > does ship every package besides these two as it is built, so the potential > > is there. > > > > I haven't had the energy to even try to understand just what the upgrade > > scripts do, but they have not treated me well. If I had done different > > patterns of incompatible changes, they would probably have been better > > than the procedure I use. > > > > On 05/29/2015 01:06 PM, Jay K wrote: > > > > I don't see an easy way to make the variable work, as there is no > > > > constraint on the order that cm3 and cm3cg are built. do-cm3-front.sh > > > > happens to do cm3cg first, but that is not necessarily required. > > > > > > [please pardon my editing...] > > > > > > > > > I see what you mean that cm3cg is an independent node in the graph and can be built in any order, > > > but, I guess, the story is/was, you have to know the safe order to ship things. > > > > > > > > > It is encoded in pkginfo.txt and the Python scripts honor it..though they don't always use pkginfo.txt for their ordering.. > > > And encoding the dependency graph there isn't ideal. It is really encoded in the import declarations > > > in the m3makefiles, usually, but not in this case... > > > > > > > > > The way that works is to build but don't ship cm3cg. > > > Then ship cm3cg. > > > Then copy cm3. > > > Then use the new cm3. > > > But perhaps it isn't strictly enforced enough. > > > > > > > > > > > > I used do this fairly often. > > > Though breaking changes in cm3cg were rare, granted. > > > But I'd also occasionally bootstrap from an older release. > > > I'll have to try to do that again soon -- actually make the current > > > tree easily buildable from the last release. > > > > > > > > > update.py handled it. > > > > > > > > > I'm on the fence. > > > "buildship" of multiple packages is in general problematic. > > > I kinda think the whole mechanism needs to be revampled. > > > > > > > > > Let me draw a close analogy. > > > > > > > > > In the slightly larger software world we have: > > > > > > make > > > make install > > > make install DESTDIR=somewhere_new > > > > > > > > > buildship is equivalent make && make install, or a make install that includes the make part, > > > as they sometimes do. > > > Read up on building glibc and they point out how dangerous this is -- how dangerous make install is w/o DESTDIR. > > > We have the same danger on a smaller scale. > > > You aren't going to break the "OS", but you can break "cm3". > > > > > > > > > The safe recommendation is make install DESTDIR. > > > Basically "install" "everything" "on the side", get it all installed, multiple > > > "packages", then copy or tar/untar it all. Or chroot into it and test it out, and > > > then do an in-place update. Or swap into the chroot and never return? (tail call install) > > > > > > > > > Don't do a "rolling upgrade". Don't install each package as it is built. No package, no cm3, > > > not cm3cg, nothing. > > > > > > > > > I'm basically suggesting that. > > > > > > > > > Now, if you say "don't ever ship, but somehow otherwise manually copy", well > > > that does kind of resolve to the same thing. > > > > > > > > > If you say, "almost don't ever ship, but provide a way to", that is almost the same. > > > > > > > > > make-dist.py follows the make install DESTDIR way. > > > > > > It is "better" I guess because I wrote it later, and because I was following > > > the example of the other .sh files that make distributions. So blame/credit Olaf? :) > > > > > > > > > It starts with a working compiler, copies parts into /temp, builds a new compiler into /tmp, and > > > uses what it builds to build everything. > > > > > > > > > Again I suggest it be looked into, and maybe be promoted as basically > > > the replacement for upgrade.py and upgrade.sh. > > > > > > > > > upgrade.py could wrap it and do the final steps of copy/untar in-place. > > > Or make-dist.py could just print the last optional command. > > > > > > > > > Anyway, I have no time lately, just email. :( > > > > > > > > > - Jay > > > > > > > > > > > > > Date: Fri, 29 May 2015 11:35:41 -0500 > > > > From: rodney_bates at lcwb.coop > > > > To: adacore at marino.st; wagner at elego.de > > > > CC: m3devel at elegosoft.com > > > > Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > > > > > > > > Setting INSTALL_CM3_IN_BIN=yes is what forces the premature install of cm3cg. > > > > I see I had encountered this problem two years ago, but then it was happening > > > > regardless of the value of this variable. My fix only addresses the case when > > > > the variable is not set. I naively went to extra trouble to preserve the > > > > existing behavior when it is set--obviously not right. > > > > > > > > I don't see an easy way to make the variable work, as there is no > > > > constraint on the order that cm3 and cm3cg are built. do-cm3-front.sh > > > > happens to do cm3cg first, but that is not necessarily required. > > > > > > > > So INSTALL_CM3_IN_BIN is broken and hard to fix, if the two need > > > > compatible upgrades. For now, it looks like install-cm3-compiler.sh > > > > is the only working way. > > > > > > > > But maybe John and Olaf have found a different way around this. > > > > > > > > On 05/29/2015 10:55 AM, Rodney M. Bates wrote: > > > > > I don't know yet why, or what needs to change, but here is definitely the problem, starting > > > > > in line 4575 of your m3c log: > > > > > > > > > > > > > > > g++48 -O2 -pipe -fstack-protector -Wl,-rpath=/usr/local/lib/gcc48 -fno-strict-aliasing -Wl,-rpath=/usr/local/lib/gcc48 -DIN_GCC -Wno-missing-field-initializers -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -o m3cgc1 m3cg/parse.o attribs.o main.o tree-browser.o libbackend.a libcommon-target.a libcommon.a ../libcpp/libcpp.a libcommon.a ../libcpp/libcpp.a ../libiberty/libiberty.a > > > > > gmake[1]: Leaving directory `/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a/m3-sys/m3cc/AMD64_FREEBSD/gcc' > > > > > > > > > > > > > > > This is copying the newly-built cm3cg (the compiler back end) to your > > > > > bin directory: > > > > > > > > > > Forced ship of cm3cg. > > > > > --- shipping from AMD64_FREEBSD --- > > > > > > > > > > . => /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin > > > > > cm3cg > > > > > ==> m3-sys/m3cc done > > > > > > > > > > === package m3-libs/m3core === > > > > > > > > > > And this is using the cm3 (compiler front end) that was already in the bin > > > > > directory, and is the release version. > > > > > > > > > > +++ /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin/cm3 -build -DROOT='/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a' $RARGS && /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin/cm3 -ship $RARGS -DROOT='/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a' +++ > > > > > --- building in AMD64_FREEBSD --- > > > > > > > > > > ignoring ../src/m3overrides > > > > > > > > > > new source -> compiling RTHooks.i3 > > > > > > > > > > This is cm3cg (aka m3cgc1) detecting the incompatibility: > > > > > > > > > > m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > > > > > compilation terminated. > > > > > > > > > > Here is the counterpart section of my log: > > > > > > > > > > g++ -g -O2 -DIN_GCC -Wno-missing-field-initializers -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -o m3cgc1 m3cg/parse.o attribs.o main.o tree-browser.o libbackend.a libcommon-target.a libcommon.a ../libcpp/libcpp.a libcommon.a ../libcpp/libcpp.a ../libiberty/libiberty.a > > > > > > > > > > On my build, it's not shipping: > > > > > > > > > > Not shipping cm3cg. > > > > > --- shipping from AMD64_LINUX --- > > > > > > > > > > missing ".M3SHIP" file, build the package first. > > > > > ==> /home/rodney/proj/m3/git/cm3/m3-sys/m3cc done > > > > > > > > > > === package /home/rodney/proj/m3/git/cm3/m3-libs/m3core === > > > > > +++ cm3 -build -DROOT='/home/rodney/proj/m3/git/cm3' $RARGS && cm3 -ship $RARGS -DROOT='/home/rodney/proj/m3/git/cm3' +++ > > > > > --- building in AMD64_LINUX --- > > > > > > > > > > ignoring ../src/m3overrides > > > > > > > > > > new source -> compiling RTHooks.i3 > > > > > new source -> compiling RT0.i3 > > > > > > > > > > When it works, the copying of both cm3 and cm3cg to the bin directory is delayed until after both have been > > > > > built, in the 'install-cm3-compiler.sh upgrade' step. > > > > > > > > > > I see your build is using a full path to the bin directory and mine is letting > > > > > it come from the usual $PATH search, but that should make no difference, as long > > > > > as the bin directory is found in a consistent way, which seems to be the case > > > > > in both builds. > > > > > > > > > > > > > > > > > > > > On 05/29/2015 04:51 AM, John Marino wrote: > > > > >> On 5/29/2015 11:39, Olaf Wagner wrote: > > > > >>> On Fri, 29 May 2015 11:10:50 +0200 > > > > >>> John Marino wrote: > > > > >>> > > > > >>>> On 5/29/2015 10:54, Olaf Wagner wrote: > > > > >>>>> Please try what I suggested in the attached mail: define > > > > >>>>> INSTALL_CM3_IN_BIN=yes > > > > >>>>> in the environment and see if that helps. > > > > >>>>> > > > > >>>> > > > > >>>> Unfortunately it seems the result is exactly the same, even when > > > > >>>> INSTALL_CM3_IN_BIN is defined in the environment. > > > > >>> > > > > >>> Can I see the new logs? Has the new backend (cm3cg) been installed now? > > > > >>> > > > > >> > > > > >> It's here: > > > > >> http://leaf.dragonflybsd.org/~marino/m3c.log > > > > >> > > > > >> It never completes "do-cm3-front.sh buildship " > > > > >> > > > > >> Note that I'm using a bootstrap install and set INSTALL_ROOT to another > > > > >> location, but it never gets to the point of installing anything. > > > > >> > > > > >> John > > > > >> > > > > > > > > > > > > > -- > > > > Rodney Bates > > > > rodney.m.bates at acm.org > > > > -- > > Rodney Bates > > rodney.m.bates at acm.org -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Sat May 30 16:58:31 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sat, 30 May 2015 09:58:31 -0500 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop> <556817A1.2090206@marino.st> <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de> <55682D1A.2030504@marino.st> <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de> <55683689.2090709@marino.st>, , <55688BFF.5040701@lcwb.coop>, <5568955D.4060200@lcwb.coop>, , <5568D5D1.5040405@lcwb.coop> Message-ID: <5569D017.5000201@lcwb.coop> On 05/29/2015 05:31 PM, Jay K wrote: > cm3/cm3cg are more special than the others, because cm3 is statically linked. > There is no m3core.dll, that cm3 uses, or m3quake.dll, etc. > There is m3core.dll, but cm3 doesn't uses it. > Shipping it doesn't affect the in-use cm3. > > > If/when we fix this, in fact, we can stop doing that static linking. > It makes sense for m3quake, etc. as there are few/no other users. > But for libm3/m3core, it'll provide a nice size optimization. > > > The mutual incompatibilty between old/new cm3/cm3cg is perfectly ok. > It is meant to be dealt with, not avoided. > I agree it's OK. Disallowing it would overly hamstring future development. But dealing with it means we need to be able to prevent either package immediately after it is built. > > I believe upgrade.py did deal with this correctly, but this environment > variable required to quash shipping of cm3cg broke it. > > > The environment variable change really should imho be removed from cm3cg. > Please. > Jay, I am not sure what you are proposing. When I first looked at the commit for this change, I was quite confused by my own change. While the comments say it is to _not_ prematurely ship cm3cg, the code appears to add code to conditionally ship if INSTALL_CM3_IN_BIN=yes. After the n-th look, I realized that before the change, it _always_ shipped, regardless of the variable. So it really does provide for less premature shipping. If I just revert it, do-cm3-front.sh will be unconditionally and unusably broken. As is, it is at least usable if you don't set the variable. Even if there is some use case where one would want it to ship, (none occurs to me), as is, you can get this behavior by just setting the variable. Moreover, the current behavior for cm3cg is consistent with the current and long-standing behavior for cm3, i.e., ship iff the variable is set. It would make more sense to me to remove the variable check by unconditionally _not_ shipping. At least do-cm3-front.sh would be usable. But then, what would be the purpose of the inconsistent use of the variable for cm3? > > And then we can switch to "destdir" and remove all the in place updating, perhaps. > > > Or I need to update upgrade.py to ship cm3cg itself. > I guess I'll do that. > > > upgrade.py may not have worked for you, but I have used it many many times. > It worked. But currently it is probably broken by the m3cc/src/m3makefile change. > I'll update it to accommodate that change.. > > > And upgrade.sh I believe was in heavy use by Hudson. > > > - Jay > > > > > Date: Fri, 29 May 2015 16:10:41 -0500 > > From: rodney_bates at lcwb.coop > > CC: m3devel at elegosoft.com > > To: > > Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > > > > Yes, we could have a better organization. I agree, the principal way > > should be to build a complete set of everything that matters to the > > implementation of the language, them replace them all at once. A > > separate DESTDIR or such is needed. > > > > The set, as Jay points out, is larger than just cm3 and m3cc. It includes > > at least m3core, probably libm3, and cm3, the executable depends on several > > separately built packages--cm3, m3middle, m3front, m3quake, m3makefile, etc. > > > > In general, we can't really assume anything about the kinds of dependencies > > of one package on old or new versions of another. Right now, cm3 and m3cc > > are known mutually incompatible between 5.8 and the head, because the numbering > > in M3CG_Binary.i3 has changed. We could probably establish some coding rules and > > order-of-install rules that would allow a newer m3cc to work with an older cm3, > > but that's only one pattern. > > > > I once thought do-cm3-*.sh build would do what we are talking about, but it > > if I remember right, puts every package into immediate use as it is built > > and also uses overrides, which keeps things inside the source tree, but makes > > it unshippable. So I always use buildship. This has never, to my knowledge > > run afoul of any compatibility problem other than between cm3 and m3cc, but it > > does ship every package besides these two as it is built, so the potential > > is there. > > > > I haven't had the energy to even try to understand just what the upgrade > > scripts do, but they have not treated me well. If I had done different > > patterns of incompatible changes, they would probably have been better > > than the procedure I use. > > > > On 05/29/2015 01:06 PM, Jay K wrote: > > > > I don't see an easy way to make the variable work, as there is no > > > > constraint on the order that cm3 and cm3cg are built. do-cm3-front.sh > > > > happens to do cm3cg first, but that is not necessarily required. > > > > > > [please pardon my editing...] > > > > > > > > > I see what you mean that cm3cg is an independent node in the graph and can be built in any order, > > > but, I guess, the story is/was, you have to know the safe order to ship things. > > > > > > > > > It is encoded in pkginfo.txt and the Python scripts honor it..though they don't always use pkginfo.txt for their ordering.. > > > And encoding the dependency graph there isn't ideal. It is really encoded in the import declarations > > > in the m3makefiles, usually, but not in this case... > > > > > > > > > The way that works is to build but don't ship cm3cg. > > > Then ship cm3cg. > > > Then copy cm3. > > > Then use the new cm3. > > > But perhaps it isn't strictly enforced enough. > > > > > > > > > > > > I used do this fairly often. > > > Though breaking changes in cm3cg were rare, granted. > > > But I'd also occasionally bootstrap from an older release. > > > I'll have to try to do that again soon -- actually make the current > > > tree easily buildable from the last release. > > > > > > > > > update.py handled it. > > > > > > > > > I'm on the fence. > > > "buildship" of multiple packages is in general problematic. > > > I kinda think the whole mechanism needs to be revampled. > > > > > > > > > Let me draw a close analogy. > > > > > > > > > In the slightly larger software world we have: > > > > > > make > > > make install > > > make install DESTDIR=somewhere_new > > > > > > > > > buildship is equivalent make && make install, or a make install that includes the make part, > > > as they sometimes do. > > > Read up on building glibc and they point out how dangerous this is -- how dangerous make install is w/o DESTDIR. > > > We have the same danger on a smaller scale. > > > You aren't going to break the "OS", but you can break "cm3". > > > > > > > > > The safe recommendation is make install DESTDIR. > > > Basically "install" "everything" "on the side", get it all installed, multiple > > > "packages", then copy or tar/untar it all. Or chroot into it and test it out, and > > > then do an in-place update. Or swap into the chroot and never return? (tail call install) > > > > > > > > > Don't do a "rolling upgrade". Don't install each package as it is built. No package, no cm3, > > > not cm3cg, nothing. > > > > > > > > > I'm basically suggesting that. > > > > > > > > > Now, if you say "don't ever ship, but somehow otherwise manually copy", well > > > that does kind of resolve to the same thing. > > > > > > > > > If you say, "almost don't ever ship, but provide a way to", that is almost the same. > > > > > > > > > make-dist.py follows the make install DESTDIR way. > > > > > > It is "better" I guess because I wrote it later, and because I was following > > > the example of the other .sh files that make distributions. So blame/credit Olaf? :) > > > > > > > > > It starts with a working compiler, copies parts into /temp, builds a new compiler into /tmp, and > > > uses what it builds to build everything. > > > > > > > > > Again I suggest it be looked into, and maybe be promoted as basically > > > the replacement for upgrade.py and upgrade.sh. > > > > > > > > > upgrade.py could wrap it and do the final steps of copy/untar in-place. > > > Or make-dist.py could just print the last optional command. > > > > > > > > > Anyway, I have no time lately, just email. :( > > > > > > > > > - Jay > > > > > > > > > > > > > Date: Fri, 29 May 2015 11:35:41 -0500 > > > > From: rodney_bates at lcwb.coop > > > > To: adacore at marino.st; wagner at elego.de > > > > CC: m3devel at elegosoft.com > > > > Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > > > > > > > > Setting INSTALL_CM3_IN_BIN=yes is what forces the premature install of cm3cg. > > > > I see I had encountered this problem two years ago, but then it was happening > > > > regardless of the value of this variable. My fix only addresses the case when > > > > the variable is not set. I naively went to extra trouble to preserve the > > > > existing behavior when it is set--obviously not right. > > > > > > > > I don't see an easy way to make the variable work, as there is no > > > > constraint on the order that cm3 and cm3cg are built. do-cm3-front.sh > > > > happens to do cm3cg first, but that is not necessarily required. > > > > > > > > So INSTALL_CM3_IN_BIN is broken and hard to fix, if the two need > > > > compatible upgrades. For now, it looks like install-cm3-compiler.sh > > > > is the only working way. > > > > > > > > But maybe John and Olaf have found a different way around this. > > > > > > > > On 05/29/2015 10:55 AM, Rodney M. Bates wrote: > > > > > I don't know yet why, or what needs to change, but here is definitely the problem, starting > > > > > in line 4575 of your m3c log: > > > > > > > > > > > > > > > g++48 -O2 -pipe -fstack-protector -Wl,-rpath=/usr/local/lib/gcc48 -fno-strict-aliasing -Wl,-rpath=/usr/local/lib/gcc48 -DIN_GCC -Wno-missing-field-initializers -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -o m3cgc1 m3cg/parse.o attribs.o main.o tree-browser.o libbackend.a libcommon-target.a libcommon.a ../libcpp/libcpp.a libcommon.a ../libcpp/libcpp.a ../libiberty/libiberty.a > > > > > gmake[1]: Leaving directory `/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a/m3-sys/m3cc/AMD64_FREEBSD/gcc' > > > > > > > > > > > > > > > This is copying the newly-built cm3cg (the compiler back end) to your > > > > > bin directory: > > > > > > > > > > Forced ship of cm3cg. > > > > > --- shipping from AMD64_FREEBSD --- > > > > > > > > > > . => /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin > > > > > cm3cg > > > > > ==> m3-sys/m3cc done > > > > > > > > > > === package m3-libs/m3core === > > > > > > > > > > And this is using the cm3 (compiler front end) that was already in the bin > > > > > directory, and is the release version. > > > > > > > > > > +++ /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin/cm3 -build -DROOT='/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a' $RARGS && /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin/cm3 -ship $RARGS -DROOT='/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a' +++ > > > > > --- building in AMD64_FREEBSD --- > > > > > > > > > > ignoring ../src/m3overrides > > > > > > > > > > new source -> compiling RTHooks.i3 > > > > > > > > > > This is cm3cg (aka m3cgc1) detecting the incompatibility: > > > > > > > > > > m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > > > > > compilation terminated. > > > > > > > > > > Here is the counterpart section of my log: > > > > > > > > > > g++ -g -O2 -DIN_GCC -Wno-missing-field-initializers -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -o m3cgc1 m3cg/parse.o attribs.o main.o tree-browser.o libbackend.a libcommon-target.a libcommon.a ../libcpp/libcpp.a libcommon.a ../libcpp/libcpp.a ../libiberty/libiberty.a > > > > > > > > > > On my build, it's not shipping: > > > > > > > > > > Not shipping cm3cg. > > > > > --- shipping from AMD64_LINUX --- > > > > > > > > > > missing ".M3SHIP" file, build the package first. > > > > > ==> /home/rodney/proj/m3/git/cm3/m3-sys/m3cc done > > > > > > > > > > === package /home/rodney/proj/m3/git/cm3/m3-libs/m3core === > > > > > +++ cm3 -build -DROOT='/home/rodney/proj/m3/git/cm3' $RARGS && cm3 -ship $RARGS -DROOT='/home/rodney/proj/m3/git/cm3' +++ > > > > > --- building in AMD64_LINUX --- > > > > > > > > > > ignoring ../src/m3overrides > > > > > > > > > > new source -> compiling RTHooks.i3 > > > > > new source -> compiling RT0.i3 > > > > > > > > > > When it works, the copying of both cm3 and cm3cg to the bin directory is delayed until after both have been > > > > > built, in the 'install-cm3-compiler.sh upgrade' step. > > > > > > > > > > I see your build is using a full path to the bin directory and mine is letting > > > > > it come from the usual $PATH search, but that should make no difference, as long > > > > > as the bin directory is found in a consistent way, which seems to be the case > > > > > in both builds. > > > > > > > > > > > > > > > > > > > > On 05/29/2015 04:51 AM, John Marino wrote: > > > > >> On 5/29/2015 11:39, Olaf Wagner wrote: > > > > >>> On Fri, 29 May 2015 11:10:50 +0200 > > > > >>> John Marino wrote: > > > > >>> > > > > >>>> On 5/29/2015 10:54, Olaf Wagner wrote: > > > > >>>>> Please try what I suggested in the attached mail: define > > > > >>>>> INSTALL_CM3_IN_BIN=yes > > > > >>>>> in the environment and see if that helps. > > > > >>>>> > > > > >>>> > > > > >>>> Unfortunately it seems the result is exactly the same, even when > > > > >>>> INSTALL_CM3_IN_BIN is defined in the environment. > > > > >>> > > > > >>> Can I see the new logs? Has the new backend (cm3cg) been installed now? > > > > >>> > > > > >> > > > > >> It's here: > > > > >> http://leaf.dragonflybsd.org/~marino/m3c.log > > > > >> > > > > >> It never completes "do-cm3-front.sh buildship " > > > > >> > > > > >> Note that I'm using a bootstrap install and set INSTALL_ROOT to another > > > > >> location, but it never gets to the point of installing anything. > > > > >> > > > > >> John > > > > >> > > > > > > > > > > > > > -- > > > > Rodney Bates > > > > rodney.m.bates at acm.org > > > > -- > > Rodney Bates > > rodney.m.bates at acm.org -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Sat May 30 17:13:46 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sat, 30 May 2015 10:13:46 -0500 Subject: [M3devel] The role INTEGER and subranges in Modula-3 Message-ID: <5569D3AA.2040009@lcwb.coop> I am suspecting there is some misunderstanding about Modula-3's approach to integer sizes. The original idea is to use subrange types, (which are programmer-defined,) not different builtin types, to match the value range you need. The safety rules of the language ensure that values stored in variables are in the type's range. But all arithmetic is done in the full native word size of the machine. Types are more abstract than most languages, in that different machine representations (particularly, bit count) need not be different base types in the language. There are no implicit type conversions. Instead, this need is met by the concept of assignability. If the abstract value is in a variable's range, it can be assigned to the variable. Size changes, if needed, are the code generator's problem. All this drastically simplifies the language, while also allowing the programmer to define an exact match between type-imposed value ranges and what the application needs, rather than just a few powers of two. Having implied type conversions, which also interact with sizes of intermediate arithmetic results, requires many pages of language definition that we avoid. LONGINT, which I have advocated, flies in the face of this tidy scheme. If we could do all arithmetic efficiently in the biggest size likely to be commonly needed, LONGINT would have no place. But native sized arithmetic is always the most efficient. In today's world, there are two very common classes of use cases: 1) 32-bit arithmetic is wide enough, 2) 32-bit is not wide enough, but 64-bit is. In both cases, on machines of either native arithmetic size, we want the best efficiency. LONGINT is for case 2, and when you further need to be able to run on either size of machine. INTEGER is for otherwise. Whether you believe in LONGINT or not, there is certainly no justification for more base integer types than two: one the native size of the machine and one bigger. Note that, as defined in Modula-3 today, INTEGER and LONGINT are always distinct types (distinct, regardless of either their value ranges or of the machine's native word size), with no subtype relation between them, no assignability between them, no implied conversions between them, no mixed arithmetic operators, no questions about intermediate result range, and literals of unambiguous type. Thus we stay out of the semantic tar pit most languages fall into with multiple integer sizes, while giving the programmer drastically more choices on range limits. Note that original Modula-3, in contrast to the single integer type, has three floating point types, no doubt motivated by the messy realities of taking full advantage of hardware-provided arithmetics. These three have the same type isolation properties as INTEGER and LONGINT, with the same consequences. In fact, the integer type isolation is directly modeled after the floating type isolation. -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Sat May 30 17:27:22 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sat, 30 May 2015 10:27:22 -0500 Subject: [M3devel] Integrating llvm Message-ID: <5569D6DA.9050404@lcwb.coop> In order to simplify integrating the emerging llvm backend, I propose to split the current llvm package into three: A library package containing just binding-related stuff to the llvm infrastructure. (llvmbindings) A library package containing M3CG_LLVM.[im]3 and anything that might get added for the actual cm3-IR to llvm-IR conversion. (llvmback) A program package with a main program for llvm (currently llvm/src/Main.m3) (llvmstaloneback) This would provide more flexibility in doing the integration into the compiler, and maybe some other things some day. Any objections or comments? Peter? -- Rodney Bates rodney.m.bates at acm.org From jay.krell at cornell.edu Sat May 30 18:24:17 2015 From: jay.krell at cornell.edu (Jay K) Date: Sat, 30 May 2015 16:24:17 +0000 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <5569D017.5000201@lcwb.coop> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop> <556817A1.2090206@marino.st> <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de> <55682D1A.2030504@marino.st> <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de> <55683689.2090709@marino.st>,,, <55688BFF.5040701@lcwb.coop>, <5568955D.4060200@lcwb.coop>, , , , <5568D5D1.5040405@lcwb.coop>, , <5569D017.5000201@lcwb.coop> Message-ID: The variable is not for atomic update of multiple files. The variable exists because updating in-use files reportedly fails on some operating systems. Though I question the truth of even that. If we change ship to rename away upon copy failure, and find a reliable simple way to ensure eventual deletion of the renamed file, then we don't need this. I'll have to experiment on NT. Presumably we've written off Win9x, and I'm not sure about AIX. So consistency with cm3 isn't necessarily desirable/required. do-cm3-front.sh isn't necessarily meant to work when there is an IR change. perhaps m3cc wasn't supposed to be in front. I'll have to double check that later. upgrade.sh is meant to. It doesn't ship anything and manually copies both cm3 and cm3cg. So that still works. And upgrade.py handles it, but other way I think, so it doesn't work any longer. Perhaps the upgrade.sh approach is better and perhaps I missed this when I rewrote it. I can make it copy cm3cg manually. I haven't gotten a chance to fix anything yet. - Jay > Date: Sat, 30 May 2015 09:58:31 -0500 > From: rodney_bates at lcwb.coop > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > > > > On 05/29/2015 05:31 PM, Jay K wrote: > > cm3/cm3cg are more special than the others, because cm3 is statically linked. > > There is no m3core.dll, that cm3 uses, or m3quake.dll, etc. > > There is m3core.dll, but cm3 doesn't uses it. > > Shipping it doesn't affect the in-use cm3. > > > > > > If/when we fix this, in fact, we can stop doing that static linking. > > It makes sense for m3quake, etc. as there are few/no other users. > > But for libm3/m3core, it'll provide a nice size optimization. > > > > > > The mutual incompatibilty between old/new cm3/cm3cg is perfectly ok. > > It is meant to be dealt with, not avoided. > > > > I agree it's OK. Disallowing it would overly hamstring future development. > But dealing with it means we need to be able to prevent either package > immediately after it is built. > > > > > I believe upgrade.py did deal with this correctly, but this environment > > variable required to quash shipping of cm3cg broke it. > > > > > > The environment variable change really should imho be removed from cm3cg. > > Please. > > > > Jay, I am not sure what you are proposing. When I first looked at the commit for > this change, I was quite confused by my own change. While the comments say it > is to _not_ prematurely ship cm3cg, the code appears to add code to conditionally > ship if INSTALL_CM3_IN_BIN=yes. After the n-th look, I realized that before > the change, it _always_ shipped, regardless of the variable. So it really does > provide for less premature shipping. > > If I just revert it, do-cm3-front.sh will be unconditionally and unusably broken. > As is, it is at least usable if you don't set the variable. Even if there is > some use case where one would want it to ship, (none occurs to me), as is, you > can get this behavior by just setting the variable. > > Moreover, the current behavior for cm3cg is consistent with the current and > long-standing behavior for cm3, i.e., ship iff the variable is set. > > It would make more sense to me to remove the variable check by unconditionally > _not_ shipping. At least do-cm3-front.sh would be usable. But then, what > would be the purpose of the inconsistent use of the variable for cm3? > > > > > > > And then we can switch to "destdir" and remove all the in place updating, perhaps. > > > > > > Or I need to update upgrade.py to ship cm3cg itself. > > I guess I'll do that. > > > > > > upgrade.py may not have worked for you, but I have used it many many times. > > It worked. But currently it is probably broken by the m3cc/src/m3makefile change. > > I'll update it to accommodate that change.. > > > > > > And upgrade.sh I believe was in heavy use by Hudson. > > > > > > - Jay > > > > > > > > > Date: Fri, 29 May 2015 16:10:41 -0500 > > > From: rodney_bates at lcwb.coop > > > CC: m3devel at elegosoft.com > > > To: > > > Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > > > > > > Yes, we could have a better organization. I agree, the principal way > > > should be to build a complete set of everything that matters to the > > > implementation of the language, them replace them all at once. A > > > separate DESTDIR or such is needed. > > > > > > The set, as Jay points out, is larger than just cm3 and m3cc. It includes > > > at least m3core, probably libm3, and cm3, the executable depends on several > > > separately built packages--cm3, m3middle, m3front, m3quake, m3makefile, etc. > > > > > > In general, we can't really assume anything about the kinds of dependencies > > > of one package on old or new versions of another. Right now, cm3 and m3cc > > > are known mutually incompatible between 5.8 and the head, because the numbering > > > in M3CG_Binary.i3 has changed. We could probably establish some coding rules and > > > order-of-install rules that would allow a newer m3cc to work with an older cm3, > > > but that's only one pattern. > > > > > > I once thought do-cm3-*.sh build would do what we are talking about, but it > > > if I remember right, puts every package into immediate use as it is built > > > and also uses overrides, which keeps things inside the source tree, but makes > > > it unshippable. So I always use buildship. This has never, to my knowledge > > > run afoul of any compatibility problem other than between cm3 and m3cc, but it > > > does ship every package besides these two as it is built, so the potential > > > is there. > > > > > > I haven't had the energy to even try to understand just what the upgrade > > > scripts do, but they have not treated me well. If I had done different > > > patterns of incompatible changes, they would probably have been better > > > than the procedure I use. > > > > > > On 05/29/2015 01:06 PM, Jay K wrote: > > > > > I don't see an easy way to make the variable work, as there is no > > > > > constraint on the order that cm3 and cm3cg are built. do-cm3-front.sh > > > > > happens to do cm3cg first, but that is not necessarily required. > > > > > > > > [please pardon my editing...] > > > > > > > > > > > > I see what you mean that cm3cg is an independent node in the graph and can be built in any order, > > > > but, I guess, the story is/was, you have to know the safe order to ship things. > > > > > > > > > > > > It is encoded in pkginfo.txt and the Python scripts honor it..though they don't always use pkginfo.txt for their ordering.. > > > > And encoding the dependency graph there isn't ideal. It is really encoded in the import declarations > > > > in the m3makefiles, usually, but not in this case... > > > > > > > > > > > > The way that works is to build but don't ship cm3cg. > > > > Then ship cm3cg. > > > > Then copy cm3. > > > > Then use the new cm3. > > > > But perhaps it isn't strictly enforced enough. > > > > > > > > > > > > > > > > I used do this fairly often. > > > > Though breaking changes in cm3cg were rare, granted. > > > > But I'd also occasionally bootstrap from an older release. > > > > I'll have to try to do that again soon -- actually make the current > > > > tree easily buildable from the last release. > > > > > > > > > > > > update.py handled it. > > > > > > > > > > > > I'm on the fence. > > > > "buildship" of multiple packages is in general problematic. > > > > I kinda think the whole mechanism needs to be revampled. > > > > > > > > > > > > Let me draw a close analogy. > > > > > > > > > > > > In the slightly larger software world we have: > > > > > > > > make > > > > make install > > > > make install DESTDIR=somewhere_new > > > > > > > > > > > > buildship is equivalent make && make install, or a make install that includes the make part, > > > > as they sometimes do. > > > > Read up on building glibc and they point out how dangerous this is -- how dangerous make install is w/o DESTDIR. > > > > We have the same danger on a smaller scale. > > > > You aren't going to break the "OS", but you can break "cm3". > > > > > > > > > > > > The safe recommendation is make install DESTDIR. > > > > Basically "install" "everything" "on the side", get it all installed, multiple > > > > "packages", then copy or tar/untar it all. Or chroot into it and test it out, and > > > > then do an in-place update. Or swap into the chroot and never return? (tail call install) > > > > > > > > > > > > Don't do a "rolling upgrade". Don't install each package as it is built. No package, no cm3, > > > > not cm3cg, nothing. > > > > > > > > > > > > I'm basically suggesting that. > > > > > > > > > > > > Now, if you say "don't ever ship, but somehow otherwise manually copy", well > > > > that does kind of resolve to the same thing. > > > > > > > > > > > > If you say, "almost don't ever ship, but provide a way to", that is almost the same. > > > > > > > > > > > > make-dist.py follows the make install DESTDIR way. > > > > > > > > It is "better" I guess because I wrote it later, and because I was following > > > > the example of the other .sh files that make distributions. So blame/credit Olaf? :) > > > > > > > > > > > > It starts with a working compiler, copies parts into /temp, builds a new compiler into /tmp, and > > > > uses what it builds to build everything. > > > > > > > > > > > > Again I suggest it be looked into, and maybe be promoted as basically > > > > the replacement for upgrade.py and upgrade.sh. > > > > > > > > > > > > upgrade.py could wrap it and do the final steps of copy/untar in-place. > > > > Or make-dist.py could just print the last optional command. > > > > > > > > > > > > Anyway, I have no time lately, just email. :( > > > > > > > > > > > > - Jay > > > > > > > > > > > > > > > > > Date: Fri, 29 May 2015 11:35:41 -0500 > > > > > From: rodney_bates at lcwb.coop > > > > > To: adacore at marino.st; wagner at elego.de > > > > > CC: m3devel at elegosoft.com > > > > > Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > > > > > > > > > > Setting INSTALL_CM3_IN_BIN=yes is what forces the premature install of cm3cg. > > > > > I see I had encountered this problem two years ago, but then it was happening > > > > > regardless of the value of this variable. My fix only addresses the case when > > > > > the variable is not set. I naively went to extra trouble to preserve the > > > > > existing behavior when it is set--obviously not right. > > > > > > > > > > I don't see an easy way to make the variable work, as there is no > > > > > constraint on the order that cm3 and cm3cg are built. do-cm3-front.sh > > > > > happens to do cm3cg first, but that is not necessarily required. > > > > > > > > > > So INSTALL_CM3_IN_BIN is broken and hard to fix, if the two need > > > > > compatible upgrades. For now, it looks like install-cm3-compiler.sh > > > > > is the only working way. > > > > > > > > > > But maybe John and Olaf have found a different way around this. > > > > > > > > > > On 05/29/2015 10:55 AM, Rodney M. Bates wrote: > > > > > > I don't know yet why, or what needs to change, but here is definitely the problem, starting > > > > > > in line 4575 of your m3c log: > > > > > > > > > > > > > > > > > > g++48 -O2 -pipe -fstack-protector -Wl,-rpath=/usr/local/lib/gcc48 -fno-strict-aliasing -Wl,-rpath=/usr/local/lib/gcc48 -DIN_GCC -Wno-missing-field-initializers -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -o m3cgc1 m3cg/parse.o attribs.o main.o tree-browser.o libbackend.a libcommon-target.a libcommon.a ../libcpp/libcpp.a libcommon.a ../libcpp/libcpp.a ../libiberty/libiberty.a > > > > > > gmake[1]: Leaving directory `/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a/m3-sys/m3cc/AMD64_FREEBSD/gcc' > > > > > > > > > > > > > > > > > > This is copying the newly-built cm3cg (the compiler back end) to your > > > > > > bin directory: > > > > > > > > > > > > Forced ship of cm3cg. > > > > > > --- shipping from AMD64_FREEBSD --- > > > > > > > > > > > > . => /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin > > > > > > cm3cg > > > > > > ==> m3-sys/m3cc done > > > > > > > > > > > > === package m3-libs/m3core === > > > > > > > > > > > > And this is using the cm3 (compiler front end) that was already in the bin > > > > > > directory, and is the release version. > > > > > > > > > > > > +++ /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin/cm3 -build -DROOT='/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a' $RARGS && /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin/cm3 -ship $RARGS -DROOT='/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a' +++ > > > > > > --- building in AMD64_FREEBSD --- > > > > > > > > > > > > ignoring ../src/m3overrides > > > > > > > > > > > > new source -> compiling RTHooks.i3 > > > > > > > > > > > > This is cm3cg (aka m3cgc1) detecting the incompatibility: > > > > > > > > > > > > m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > > > > > > compilation terminated. > > > > > > > > > > > > Here is the counterpart section of my log: > > > > > > > > > > > > g++ -g -O2 -DIN_GCC -Wno-missing-field-initializers -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -o m3cgc1 m3cg/parse.o attribs.o main.o tree-browser.o libbackend.a libcommon-target.a libcommon.a ../libcpp/libcpp.a libcommon.a ../libcpp/libcpp.a ../libiberty/libiberty.a > > > > > > > > > > > > On my build, it's not shipping: > > > > > > > > > > > > Not shipping cm3cg. > > > > > > --- shipping from AMD64_LINUX --- > > > > > > > > > > > > missing ".M3SHIP" file, build the package first. > > > > > > ==> /home/rodney/proj/m3/git/cm3/m3-sys/m3cc done > > > > > > > > > > > > === package /home/rodney/proj/m3/git/cm3/m3-libs/m3core === > > > > > > +++ cm3 -build -DROOT='/home/rodney/proj/m3/git/cm3' $RARGS && cm3 -ship $RARGS -DROOT='/home/rodney/proj/m3/git/cm3' +++ > > > > > > --- building in AMD64_LINUX --- > > > > > > > > > > > > ignoring ../src/m3overrides > > > > > > > > > > > > new source -> compiling RTHooks.i3 > > > > > > new source -> compiling RT0.i3 > > > > > > > > > > > > When it works, the copying of both cm3 and cm3cg to the bin directory is delayed until after both have been > > > > > > built, in the 'install-cm3-compiler.sh upgrade' step. > > > > > > > > > > > > I see your build is using a full path to the bin directory and mine is letting > > > > > > it come from the usual $PATH search, but that should make no difference, as long > > > > > > as the bin directory is found in a consistent way, which seems to be the case > > > > > > in both builds. > > > > > > > > > > > > > > > > > > > > > > > > On 05/29/2015 04:51 AM, John Marino wrote: > > > > > >> On 5/29/2015 11:39, Olaf Wagner wrote: > > > > > >>> On Fri, 29 May 2015 11:10:50 +0200 > > > > > >>> John Marino wrote: > > > > > >>> > > > > > >>>> On 5/29/2015 10:54, Olaf Wagner wrote: > > > > > >>>>> Please try what I suggested in the attached mail: define > > > > > >>>>> INSTALL_CM3_IN_BIN=yes > > > > > >>>>> in the environment and see if that helps. > > > > > >>>>> > > > > > >>>> > > > > > >>>> Unfortunately it seems the result is exactly the same, even when > > > > > >>>> INSTALL_CM3_IN_BIN is defined in the environment. > > > > > >>> > > > > > >>> Can I see the new logs? Has the new backend (cm3cg) been installed now? > > > > > >>> > > > > > >> > > > > > >> It's here: > > > > > >> http://leaf.dragonflybsd.org/~marino/m3c.log > > > > > >> > > > > > >> It never completes "do-cm3-front.sh buildship " > > > > > >> > > > > > >> Note that I'm using a bootstrap install and set INSTALL_ROOT to another > > > > > >> location, but it never gets to the point of installing anything. > > > > > >> > > > > > >> John > > > > > >> > > > > > > > > > > > > > > > > -- > > > > > Rodney Bates > > > > > rodney.m.bates at acm.org > > > > > > -- > > > Rodney Bates > > > rodney.m.bates at acm.org > > -- > Rodney Bates > rodney.m.bates at acm.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Sat May 30 18:38:46 2015 From: mika at async.caltech.edu (mika at async.caltech.edu) Date: Sat, 30 May 2015 09:38:46 -0700 Subject: [M3devel] The role INTEGER and subranges in Modula-3 In-Reply-To: <5569D3AA.2040009@lcwb.coop> References: <5569D3AA.2040009@lcwb.coop> Message-ID: <20150530163846.6EE551A2062@async.async.caltech.edu> Very clear explanation. I might even have been sold on LONGINT. Well, almost. Thanks for the explanation, anyhow! Mika "Rodney M. Bates" writes: >I am suspecting there is some misunderstanding about Modula-3's approach >to integer sizes. > >The original idea is to use subrange types, (which are >programmer-defined,) not different builtin types, to match the value >range you need. The safety rules of the language ensure that values >stored in variables are in the type's range. But all arithmetic is >done in the full native word size of the machine. > >Types are more abstract than most languages, in that different machine >representations (particularly, bit count) need not be different base >types in the language. > >There are no implicit type conversions. Instead, this need is met by >the concept of assignability. If the abstract value is in a >variable's range, it can be assigned to the variable. Size changes, >if needed, are the code generator's problem. > >All this drastically simplifies the language, while also allowing the >programmer to define an exact match between type-imposed value ranges >and what the application needs, rather than just a few powers of two. >Having implied type conversions, which also interact with sizes of >intermediate arithmetic results, requires many pages of language >definition that we avoid. > >LONGINT, which I have advocated, flies in the face of this tidy >scheme. If we could do all arithmetic efficiently in the biggest size >likely to be commonly needed, LONGINT would have no place. But native >sized arithmetic is always the most efficient. In today's world, >there are two very common classes of use cases: 1) 32-bit arithmetic >is wide enough, 2) 32-bit is not wide enough, but 64-bit is. In both >cases, on machines of either native arithmetic size, we want the best >efficiency. LONGINT is for case 2, and when you further need to be >able to run on either size of machine. INTEGER is for otherwise. > >Whether you believe in LONGINT or not, there is certainly no >justification for more base integer types than two: one the native >size of the machine and one bigger. > >Note that, as defined in Modula-3 today, INTEGER and LONGINT are >always distinct types (distinct, regardless of either their value >ranges or of the machine's native word size), with no subtype relation >between them, no assignability between them, no implied conversions >between them, no mixed arithmetic operators, no questions about >intermediate result range, and literals of unambiguous type. Thus we >stay out of the semantic tar pit most languages fall into with >multiple integer sizes, while giving the programmer drastically more >choices on range limits. > >Note that original Modula-3, in contrast to the single integer type, >has three floating point types, no doubt motivated by the messy >realities of taking full advantage of hardware-provided arithmetics. >These three have the same type isolation properties as INTEGER and >LONGINT, with the same consequences. In fact, the integer type >isolation is directly modeled after the floating type isolation. > >-- >Rodney Bates >rodney.m.bates at acm.org From jay.krell at cornell.edu Sat May 30 18:37:49 2015 From: jay.krell at cornell.edu (Jay K) Date: Sat, 30 May 2015 16:37:49 +0000 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop>, <55673AA4.8050100@marino.st>, <20150528190643.faf81897fc5698a06bf37838@elegosoft.com>, <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop>, <556817A1.2090206@marino.st>, <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de>, <55682D1A.2030504@marino.st>, <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de>, <55683689.2090709@marino.st>, , , <55688BFF.5040701@lcwb.coop>,,<5568955D.4060200@lcwb.coop>, ,,, , , <5568D5D1.5040405@lcwb.coop>, , , , <5569D017.5000201@lcwb.coop>, Message-ID: Here is the model to consider. Think of make install. In gcc and glibc, is it special cased? Probably not. Do they have an extra environment variable to turn it on/off? Probably not. Is it fraught with problems like cm3? Probably. Though DESTDIR is the safe way. The environment variable is a workaround for OS limitations, that may or may not exist. If it might exist anywhere, then all OS'es are treated consistently. If we can determine that it exists nowhere, then we can remove. The environment variable does not provide for shipping in the correct order. The user is obligated to do that. Removing the environment variable from cm3 and cm3cg is meant to work. You do this by splitting up build from ship. Build everything, then ship everything. Since shipping doesn't use cm3cg. If there are problems, they aren't found till the results are partly commited and must be backed out -- if you are shipping in-place. That is just the nature of it. That is why make install for glibc is particularly dangerous. My upgrade.py's use of buildship is probably not the right approach. That was probably a mistake and it is easy for me to fix. So it won't end up mattering -- nobody will ever ship cm3 or cm3cg. But when no incompatible change is being made, it is meant to just work. When an incompatible change is made, more care is meant to be taken. - Jay From: jay.krell at cornell.edu To: rodney.m.bates at acm.org Date: Sat, 30 May 2015 16:24:17 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 The variable is not for atomic update of multiple files. The variable exists because updating in-use files reportedly fails on some operating systems. Though I question the truth of even that. If we change ship to rename away upon copy failure, and find a reliable simple way to ensure eventual deletion of the renamed file, then we don't need this. I'll have to experiment on NT. Presumably we've written off Win9x, and I'm not sure about AIX. So consistency with cm3 isn't necessarily desirable/required. do-cm3-front.sh isn't necessarily meant to work when there is an IR change. perhaps m3cc wasn't supposed to be in front. I'll have to double check that later. upgrade.sh is meant to. It doesn't ship anything and manually copies both cm3 and cm3cg. So that still works. And upgrade.py handles it, but other way I think, so it doesn't work any longer. Perhaps the upgrade.sh approach is better and perhaps I missed this when I rewrote it. I can make it copy cm3cg manually. I haven't gotten a chance to fix anything yet. - Jay > Date: Sat, 30 May 2015 09:58:31 -0500 > From: rodney_bates at lcwb.coop > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > > > > On 05/29/2015 05:31 PM, Jay K wrote: > > cm3/cm3cg are more special than the others, because cm3 is statically linked. > > There is no m3core.dll, that cm3 uses, or m3quake.dll, etc. > > There is m3core.dll, but cm3 doesn't uses it. > > Shipping it doesn't affect the in-use cm3. > > > > > > If/when we fix this, in fact, we can stop doing that static linking. > > It makes sense for m3quake, etc. as there are few/no other users. > > But for libm3/m3core, it'll provide a nice size optimization. > > > > > > The mutual incompatibilty between old/new cm3/cm3cg is perfectly ok. > > It is meant to be dealt with, not avoided. > > > > I agree it's OK. Disallowing it would overly hamstring future development. > But dealing with it means we need to be able to prevent either package > immediately after it is built. > > > > > I believe upgrade.py did deal with this correctly, but this environment > > variable required to quash shipping of cm3cg broke it. > > > > > > The environment variable change really should imho be removed from cm3cg. > > Please. > > > > Jay, I am not sure what you are proposing. When I first looked at the commit for > this change, I was quite confused by my own change. While the comments say it > is to _not_ prematurely ship cm3cg, the code appears to add code to conditionally > ship if INSTALL_CM3_IN_BIN=yes. After the n-th look, I realized that before > the change, it _always_ shipped, regardless of the variable. So it really does > provide for less premature shipping. > > If I just revert it, do-cm3-front.sh will be unconditionally and unusably broken. > As is, it is at least usable if you don't set the variable. Even if there is > some use case where one would want it to ship, (none occurs to me), as is, you > can get this behavior by just setting the variable. > > Moreover, the current behavior for cm3cg is consistent with the current and > long-standing behavior for cm3, i.e., ship iff the variable is set. > > It would make more sense to me to remove the variable check by unconditionally > _not_ shipping. At least do-cm3-front.sh would be usable. But then, what > would be the purpose of the inconsistent use of the variable for cm3? > > > > > > > And then we can switch to "destdir" and remove all the in place updating, perhaps. > > > > > > Or I need to update upgrade.py to ship cm3cg itself. > > I guess I'll do that. > > > > > > upgrade.py may not have worked for you, but I have used it many many times. > > It worked. But currently it is probably broken by the m3cc/src/m3makefile change. > > I'll update it to accommodate that change.. > > > > > > And upgrade.sh I believe was in heavy use by Hudson. > > > > > > - Jay > > > > > > > > > Date: Fri, 29 May 2015 16:10:41 -0500 > > > From: rodney_bates at lcwb.coop > > > CC: m3devel at elegosoft.com > > > To: > > > Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > > > > > > Yes, we could have a better organization. I agree, the principal way > > > should be to build a complete set of everything that matters to the > > > implementation of the language, them replace them all at once. A > > > separate DESTDIR or such is needed. > > > > > > The set, as Jay points out, is larger than just cm3 and m3cc. It includes > > > at least m3core, probably libm3, and cm3, the executable depends on several > > > separately built packages--cm3, m3middle, m3front, m3quake, m3makefile, etc. > > > > > > In general, we can't really assume anything about the kinds of dependencies > > > of one package on old or new versions of another. Right now, cm3 and m3cc > > > are known mutually incompatible between 5.8 and the head, because the numbering > > > in M3CG_Binary.i3 has changed. We could probably establish some coding rules and > > > order-of-install rules that would allow a newer m3cc to work with an older cm3, > > > but that's only one pattern. > > > > > > I once thought do-cm3-*.sh build would do what we are talking about, but it > > > if I remember right, puts every package into immediate use as it is built > > > and also uses overrides, which keeps things inside the source tree, but makes > > > it unshippable. So I always use buildship. This has never, to my knowledge > > > run afoul of any compatibility problem other than between cm3 and m3cc, but it > > > does ship every package besides these two as it is built, so the potential > > > is there. > > > > > > I haven't had the energy to even try to understand just what the upgrade > > > scripts do, but they have not treated me well. If I had done different > > > patterns of incompatible changes, they would probably have been better > > > than the procedure I use. > > > > > > On 05/29/2015 01:06 PM, Jay K wrote: > > > > > I don't see an easy way to make the variable work, as there is no > > > > > constraint on the order that cm3 and cm3cg are built. do-cm3-front.sh > > > > > happens to do cm3cg first, but that is not necessarily required. > > > > > > > > [please pardon my editing...] > > > > > > > > > > > > I see what you mean that cm3cg is an independent node in the graph and can be built in any order, > > > > but, I guess, the story is/was, you have to know the safe order to ship things. > > > > > > > > > > > > It is encoded in pkginfo.txt and the Python scripts honor it..though they don't always use pkginfo.txt for their ordering.. > > > > And encoding the dependency graph there isn't ideal. It is really encoded in the import declarations > > > > in the m3makefiles, usually, but not in this case... > > > > > > > > > > > > The way that works is to build but don't ship cm3cg. > > > > Then ship cm3cg. > > > > Then copy cm3. > > > > Then use the new cm3. > > > > But perhaps it isn't strictly enforced enough. > > > > > > > > > > > > > > > > I used do this fairly often. > > > > Though breaking changes in cm3cg were rare, granted. > > > > But I'd also occasionally bootstrap from an older release. > > > > I'll have to try to do that again soon -- actually make the current > > > > tree easily buildable from the last release. > > > > > > > > > > > > update.py handled it. > > > > > > > > > > > > I'm on the fence. > > > > "buildship" of multiple packages is in general problematic. > > > > I kinda think the whole mechanism needs to be revampled. > > > > > > > > > > > > Let me draw a close analogy. > > > > > > > > > > > > In the slightly larger software world we have: > > > > > > > > make > > > > make install > > > > make install DESTDIR=somewhere_new > > > > > > > > > > > > buildship is equivalent make && make install, or a make install that includes the make part, > > > > as they sometimes do. > > > > Read up on building glibc and they point out how dangerous this is -- how dangerous make install is w/o DESTDIR. > > > > We have the same danger on a smaller scale. > > > > You aren't going to break the "OS", but you can break "cm3". > > > > > > > > > > > > The safe recommendation is make install DESTDIR. > > > > Basically "install" "everything" "on the side", get it all installed, multiple > > > > "packages", then copy or tar/untar it all. Or chroot into it and test it out, and > > > > then do an in-place update. Or swap into the chroot and never return? (tail call install) > > > > > > > > > > > > Don't do a "rolling upgrade". Don't install each package as it is built. No package, no cm3, > > > > not cm3cg, nothing. > > > > > > > > > > > > I'm basically suggesting that. > > > > > > > > > > > > Now, if you say "don't ever ship, but somehow otherwise manually copy", well > > > > that does kind of resolve to the same thing. > > > > > > > > > > > > If you say, "almost don't ever ship, but provide a way to", that is almost the same. > > > > > > > > > > > > make-dist.py follows the make install DESTDIR way. > > > > > > > > It is "better" I guess because I wrote it later, and because I was following > > > > the example of the other .sh files that make distributions. So blame/credit Olaf? :) > > > > > > > > > > > > It starts with a working compiler, copies parts into /temp, builds a new compiler into /tmp, and > > > > uses what it builds to build everything. > > > > > > > > > > > > Again I suggest it be looked into, and maybe be promoted as basically > > > > the replacement for upgrade.py and upgrade.sh. > > > > > > > > > > > > upgrade.py could wrap it and do the final steps of copy/untar in-place. > > > > Or make-dist.py could just print the last optional command. > > > > > > > > > > > > Anyway, I have no time lately, just email. :( > > > > > > > > > > > > - Jay > > > > > > > > > > > > > > > > > Date: Fri, 29 May 2015 11:35:41 -0500 > > > > > From: rodney_bates at lcwb.coop > > > > > To: adacore at marino.st; wagner at elego.de > > > > > CC: m3devel at elegosoft.com > > > > > Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > > > > > > > > > > Setting INSTALL_CM3_IN_BIN=yes is what forces the premature install of cm3cg. > > > > > I see I had encountered this problem two years ago, but then it was happening > > > > > regardless of the value of this variable. My fix only addresses the case when > > > > > the variable is not set. I naively went to extra trouble to preserve the > > > > > existing behavior when it is set--obviously not right. > > > > > > > > > > I don't see an easy way to make the variable work, as there is no > > > > > constraint on the order that cm3 and cm3cg are built. do-cm3-front.sh > > > > > happens to do cm3cg first, but that is not necessarily required. > > > > > > > > > > So INSTALL_CM3_IN_BIN is broken and hard to fix, if the two need > > > > > compatible upgrades. For now, it looks like install-cm3-compiler.sh > > > > > is the only working way. > > > > > > > > > > But maybe John and Olaf have found a different way around this. > > > > > > > > > > On 05/29/2015 10:55 AM, Rodney M. Bates wrote: > > > > > > I don't know yet why, or what needs to change, but here is definitely the problem, starting > > > > > > in line 4575 of your m3c log: > > > > > > > > > > > > > > > > > > g++48 -O2 -pipe -fstack-protector -Wl,-rpath=/usr/local/lib/gcc48 -fno-strict-aliasing -Wl,-rpath=/usr/local/lib/gcc48 -DIN_GCC -Wno-missing-field-initializers -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -o m3cgc1 m3cg/parse.o attribs.o main.o tree-browser.o libbackend.a libcommon-target.a libcommon.a ../libcpp/libcpp.a libcommon.a ../libcpp/libcpp.a ../libiberty/libiberty.a > > > > > > gmake[1]: Leaving directory `/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a/m3-sys/m3cc/AMD64_FREEBSD/gcc' > > > > > > > > > > > > > > > > > > This is copying the newly-built cm3cg (the compiler back end) to your > > > > > > bin directory: > > > > > > > > > > > > Forced ship of cm3cg. > > > > > > --- shipping from AMD64_FREEBSD --- > > > > > > > > > > > > . => /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin > > > > > > cm3cg > > > > > > ==> m3-sys/m3cc done > > > > > > > > > > > > === package m3-libs/m3core === > > > > > > > > > > > > And this is using the cm3 (compiler front end) that was already in the bin > > > > > > directory, and is the release version. > > > > > > > > > > > > +++ /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin/cm3 -build -DROOT='/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a' $RARGS && /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin/cm3 -ship $RARGS -DROOT='/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a' +++ > > > > > > --- building in AMD64_FREEBSD --- > > > > > > > > > > > > ignoring ../src/m3overrides > > > > > > > > > > > > new source -> compiling RTHooks.i3 > > > > > > > > > > > > This is cm3cg (aka m3cgc1) detecting the incompatibility: > > > > > > > > > > > > m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > > > > > > compilation terminated. > > > > > > > > > > > > Here is the counterpart section of my log: > > > > > > > > > > > > g++ -g -O2 -DIN_GCC -Wno-missing-field-initializers -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -o m3cgc1 m3cg/parse.o attribs.o main.o tree-browser.o libbackend.a libcommon-target.a libcommon.a ../libcpp/libcpp.a libcommon.a ../libcpp/libcpp.a ../libiberty/libiberty.a > > > > > > > > > > > > On my build, it's not shipping: > > > > > > > > > > > > Not shipping cm3cg. > > > > > > --- shipping from AMD64_LINUX --- > > > > > > > > > > > > missing ".M3SHIP" file, build the package first. > > > > > > ==> /home/rodney/proj/m3/git/cm3/m3-sys/m3cc done > > > > > > > > > > > > === package /home/rodney/proj/m3/git/cm3/m3-libs/m3core === > > > > > > +++ cm3 -build -DROOT='/home/rodney/proj/m3/git/cm3' $RARGS && cm3 -ship $RARGS -DROOT='/home/rodney/proj/m3/git/cm3' +++ > > > > > > --- building in AMD64_LINUX --- > > > > > > > > > > > > ignoring ../src/m3overrides > > > > > > > > > > > > new source -> compiling RTHooks.i3 > > > > > > new source -> compiling RT0.i3 > > > > > > > > > > > > When it works, the copying of both cm3 and cm3cg to the bin directory is delayed until after both have been > > > > > > built, in the 'install-cm3-compiler.sh upgrade' step. > > > > > > > > > > > > I see your build is using a full path to the bin directory and mine is letting > > > > > > it come from the usual $PATH search, but that should make no difference, as long > > > > > > as the bin directory is found in a consistent way, which seems to be the case > > > > > > in both builds. > > > > > > > > > > > > > > > > > > > > > > > > On 05/29/2015 04:51 AM, John Marino wrote: > > > > > >> On 5/29/2015 11:39, Olaf Wagner wrote: > > > > > >>> On Fri, 29 May 2015 11:10:50 +0200 > > > > > >>> John Marino wrote: > > > > > >>> > > > > > >>>> On 5/29/2015 10:54, Olaf Wagner wrote: > > > > > >>>>> Please try what I suggested in the attached mail: define > > > > > >>>>> INSTALL_CM3_IN_BIN=yes > > > > > >>>>> in the environment and see if that helps. > > > > > >>>>> > > > > > >>>> > > > > > >>>> Unfortunately it seems the result is exactly the same, even when > > > > > >>>> INSTALL_CM3_IN_BIN is defined in the environment. > > > > > >>> > > > > > >>> Can I see the new logs? Has the new backend (cm3cg) been installed now? > > > > > >>> > > > > > >> > > > > > >> It's here: > > > > > >> http://leaf.dragonflybsd.org/~marino/m3c.log > > > > > >> > > > > > >> It never completes "do-cm3-front.sh buildship " > > > > > >> > > > > > >> Note that I'm using a bootstrap install and set INSTALL_ROOT to another > > > > > >> location, but it never gets to the point of installing anything. > > > > > >> > > > > > >> John > > > > > >> > > > > > > > > > > > > > > > > -- > > > > > Rodney Bates > > > > > rodney.m.bates at acm.org > > > > > > -- > > > Rodney Bates > > > rodney.m.bates at acm.org > > -- > Rodney Bates > rodney.m.bates at acm.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From estellnb at elstel.org Sat May 30 18:33:26 2015 From: estellnb at elstel.org (Elmar Stellnberger) Date: Sat, 30 May 2015 18:33:26 +0200 Subject: [M3devel] The role INTEGER and subranges in Modula-3 In-Reply-To: <5569D3AA.2040009@lcwb.coop> References: <5569D3AA.2040009@lcwb.coop> Message-ID: <5569E656.6080909@elstel.org> Am 30.05.15 um 17:13 schrieb Rodney M. Bates: > There are no implicit type conversions. Instead, this need is met by > the concept of assignability. If the abstract value is in a > variable's range, it can be assigned to the variable. Size changes, > if needed, are the code generator's problem. So what does the code generator do if there is an overflow not checked by the predefined value range (i.e. BITS 8 FOR INTEGER instead of BITS 8 for [0..255]) > All this drastically simplifies the language, while also allowing the ... Yes, I understand your decision. > likely to be commonly needed, LONGINT would have no place. But native > sized arithmetic is always the most efficient. In today's world, > there are two very common classes of use cases: 1) 32-bit arithmetic > is wide enough, 2) 32-bit is not wide enough, but 64-bit is. In both > cases, on machines of either native arithmetic size, we want the best > efficiency. LONGINT is for case 2, and when you further need to be > able to run on either size of machine. INTEGER is for otherwise. Well, that was exactly my argument for a language specified type size of INTEGER, because things do not get faster if you use 64bit integers instead of 32bit integers. CPU arithmetics perhaps but the real bottleneck of today is the memory hierarchy - and using 64bit integers doubles our memory need at least for scalars. > > Whether you believe in LONGINT or not, there is certainly no > justification for more base integer types than two: one the native > size of the machine and one bigger. Yes, we really don`t need them as anything becomes 64bit or the native word size respectively on the stack (that is why Ctypes.int works). Memory latency should be a minor issue as long as our parameters and parts of the activation records fit into the cache. From estellnb at elstel.org Sat May 30 18:51:12 2015 From: estellnb at elstel.org (Elmar Stellnberger) Date: Sat, 30 May 2015 18:51:12 +0200 Subject: [M3devel] 64bit INTEGERs, WIDECHAR: language specified or configuration/target dependent? In-Reply-To: <55679CA8.2030905@lcwb.coop> References: <555E14BC.2040805@lcwb.coop> <555E203E.4040203@elstel.org> <0A1CDD8C-EEB5-40E2-A38B-28E8EEA8C37E@elstel.org> <8A3AB2ED-C11E-4787-A7F8-C8F12157EAA5@elstel.org> <555F6D8F.4070109@lcwb.coop> <6F9B9534-7DC2-4D4D-88CB-90D7FA05E8F9@elstel.org> <8BBBC94B-EECC-464A-86BB-FD1C94EC5496@elstel.org> <77605189-D966-4D4B-8946-838BD6E178AA@purdue.edu> <55675464.5090306@elstel.org> <5567723D.3020706@elstel.org> <55679CA8.2030905@lcwb.coop> Message-ID: <5569EA80.7050700@elstel.org> > Well, maybe not stack variables, if the stack has a bigger alignment > to be honored, > quite possibly a hardware requirement. No doubt taking and using the > address of > such would be endian-dependent. Would a C compiler do differently in > this case? > Can you rely on them all doing it the same? Does C specify it? No, as far as I know C can provide multiple calling conventions. However any x86 based system has a word size aligned stack. No way to push or pop half of a word. That way we are at least save for any x86 Intel/AMD - system. From jay.krell at cornell.edu Sat May 30 23:55:06 2015 From: jay.krell at cornell.edu (Jay K) Date: Sat, 30 May 2015 21:55:06 +0000 Subject: [M3devel] 64bit INTEGERs, WIDECHAR: language specified or configuration/target dependent? In-Reply-To: <5569EA80.7050700@elstel.org> References: <555E14BC.2040805@lcwb.coop> <555E203E.4040203@elstel.org> <0A1CDD8C-EEB5-40E2-A38B-28E8EEA8C37E@elstel.org> <8A3AB2ED-C11E-4787-A7F8-C8F12157EAA5@elstel.org> <555F6D8F.4070109@lcwb.coop> <6F9B9534-7DC2-4D4D-88CB-90D7FA05E8F9@elstel.org> <8BBBC94B-EECC-464A-86BB-FD1C94EC5496@elstel.org> <77605189-D966-4D4B-8946-838BD6E178AA@purdue.edu> <55675464.5090306@elstel.org> <5567723D.3020706@elstel.org>, <55679CA8.2030905@lcwb.coop>, <5569EA80.7050700@elstel.org> Message-ID: > No way to push or pop half of a word. sub esp, 2 But nobody does that. Parameters may generally fill whole words, but I doubt locals do. - Jay > Date: Sat, 30 May 2015 18:51:12 +0200 > From: estellnb at elstel.org > To: rodney.m.bates at acm.org; m3devel at elegosoft.com > Subject: Re: [M3devel] 64bit INTEGERs, WIDECHAR: language specified or configuration/target dependent? > > > > Well, maybe not stack variables, if the stack has a bigger alignment > > to be honored, > > quite possibly a hardware requirement. No doubt taking and using the > > address of > > such would be endian-dependent. Would a C compiler do differently in > > this case? > > Can you rely on them all doing it the same? Does C specify it? > No, as far as I know C can provide multiple calling conventions. > However any x86 based system has a word size aligned stack. > No way to push or pop half of a word. That way we are at least save > for any x86 Intel/AMD - system. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.mckinna at gmail.com Sun May 31 01:06:26 2015 From: peter.mckinna at gmail.com (Peter McKinna) Date: Sun, 31 May 2015 09:06:26 +1000 Subject: [M3devel] extended Message-ID: Hi While we are on the subject of integer types can we diverge slightly to floating point types. I wonder if anyone can explain why the extended type is treated exactly the same as longreal in the frontend? They have the same sizes and ranges and precisions. As for backends, at the moment m3cc is generating 8 byte sse instructions for both types. The llvm is generating 10 byte float instructions as per its x86fp80 type which are a fair bit slower at the expense of greater range and precision. However they are not interoperable with legacy libraries and we should probably change the type to agree with m3cc and the frontend. It seems that the 8087 80 bit float is being phased out see http://csapp.cs.cmu.edu/2e/waside/waside-x87.pdf so maybe the m3 implementors saw the writing on the wall and and decided to wait for hardware to catch up. Anyway I wonder if its worth considering making extended one of the 128 bit floating point types which although emulated in software would at least give us a different type and one which would give some applications a huge precision (and range ~10^4090) boost. Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun May 31 03:52:41 2015 From: jay.krell at cornell.edu (Jay K) Date: Sun, 31 May 2015 01:52:41 +0000 Subject: [M3devel] extended In-Reply-To: References: Message-ID: Half seriously: Do we need FLOAT32, FLOAT64, FLOAT80, FLOAT128? And some way to indicate what is available? On many/most/but-not-all modern 32bit x86 systems, "long double" is the same as "double". Modula-3 is in agreement with many/most/but-not-all C systems. m3cc might be using x87 instructions on some platforms, at least sometimes. But that doesn't change in-memory extended to other than 64 bits. Just temporary in-register values might be 80 bits. - Jay Date: Sun, 31 May 2015 09:06:26 +1000 From: peter.mckinna at gmail.com To: m3devel at elegosoft.com Subject: [M3devel] extended Hi While we are on the subject of integer types can we diverge slightly to floating point types. I wonder if anyone can explain why the extended type is treated exactly the same as longreal in the frontend? They have the same sizes and ranges and precisions. As for backends, at the moment m3cc is generating 8 byte sse instructions for both types. The llvm is generating 10 byte float instructions as per its x86fp80 type which are a fair bit slower at the expense of greater range and precision. However they are not interoperable with legacy libraries and we should probably change the type to agree with m3cc and the frontend. It seems that the 8087 80 bit float is being phased out see http://csapp.cs.cmu.edu/2e/waside/waside-x87.pdfso maybe the m3 implementors saw the writing on the wall and and decided to wait for hardware to catch up. Anyway I wonder if its worth considering making extended one of the 128 bit floating point types which although emulated in software would at least give us a different type and one which would give some applications a huge precision (and range ~10^4090) boost. Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Sun May 31 04:09:46 2015 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Sat, 30 May 2015 22:09:46 -0400 Subject: [M3devel] extended In-Reply-To: References: Message-ID: <20150531020946.GA10463@topoi.pooq.com> On Sun, May 31, 2015 at 01:52:41AM +0000, Jay K wrote: > Half seriously: Do we need FLOAT32, FLOAT64, FLOAT80, FLOAT128? > And some way to indicate what is available? Those who do serious numerical analysis for a iving are very careful of their precisions. They really care about these datails to an extent most of us mortalls don't. I've even had freinds complain about compilers that gave them *more* precision than they had asked for. -- hendrik > > > On many/most/but-not-all modern 32bit x86 systems, "long double" is the > same as "double". Modula-3 is in agreement with many/most/but-not-all C systems. > > > m3cc might be using x87 instructions on some platforms, at least sometimes. > But that doesn't change in-memory extended to other than 64 bits. > Just temporary in-register values might be 80 bits. > > > - Jay > > > > Date: Sun, 31 May 2015 09:06:26 +1000 > From: peter.mckinna at gmail.com > To: m3devel at elegosoft.com > Subject: [M3devel] extended > > Hi > While we are on the subject of integer types can we diverge slightly to floating point types. I wonder if anyone can explain why the extended type is treated exactly the same as longreal in the frontend? They have the same sizes and ranges and precisions. As for backends, at the moment m3cc is generating 8 byte sse instructions for both types. The llvm is generating 10 byte float instructions as per its x86fp80 type which are a fair bit slower at the expense of greater range and precision. However they are not interoperable with legacy libraries and we should probably change the type to agree with m3cc and the frontend. It seems that the 8087 80 bit float is being phased out see http://csapp.cs.cmu.edu/2e/waside/waside-x87.pdfso maybe the m3 implementors saw the writing on the wall and and decided to wait for hardware to catch up. Anyway I wonder if its worth considering making extended one of the 128 bit floating point types which although emulated in software would at least give us a different type and one which would give some applications a huge precision (and range ~10^4090) boost. > Peter From mika at async.caltech.edu Sun May 31 04:18:31 2015 From: mika at async.caltech.edu (mika at async.caltech.edu) Date: Sat, 30 May 2015 19:18:31 -0700 Subject: [M3devel] extended In-Reply-To: <20150531020946.GA10463@topoi.pooq.com> References: <20150531020946.GA10463@topoi.pooq.com> Message-ID: <20150531021831.160751A2062@async.async.caltech.edu> Yes, it is standard practice to write x87 registers to memory and read them back to guarantee one is not getting "extended" precision by mistake. Modula-3 does a pretty good job of defining what all the floating formats are, if you look at the various interfaces for the formats. I seem to remember the story is that one of Kahan's grad students was interning at SRC one summer and wrote the interfaces. "Among the best in the business." Mika Hendrik Boom writes: >On Sun, May 31, 2015 at 01:52:41AM +0000, Jay K wrote: >> Half seriously: Do we need FLOAT32, FLOAT64, FLOAT80, FLOAT128? >> And some way to indicate what is available? > >Those who do serious numerical analysis for a iving are very careful of=20 >their precisions. > >They really care about these datails to an extent most of us mortalls=20 >don't. > >I've even had freinds complain about compilers that gave them *more*=20 >precision than they had asked for. > >-- hendrik > >>=20 >> =20 >> On many/most/but-not-all modern 32bit x86 systems, "long double" is the >> same as "double". Modula-3 is in agreement with many/most/but-not-all C s= >ystems. >> =20 >>=20 >> m3cc might be using x87 instructions on some platforms, at least sometime= >s. >> But that doesn't change in-memory extended to other than 64 bits. >> Just temporary in-register values might be 80 bits. >> =20 >>=20 >> - Jay >>=20 >>=20 >> =20 >> Date: Sun, 31 May 2015 09:06:26 +1000 >> From: peter.mckinna at gmail.com >> To: m3devel at elegosoft.com >> Subject: [M3devel] extended >>=20 >> Hi >> While we are on the subject of integer types can we diverge slightly to= > floating point types. I wonder if anyone can explain why the extended type= > is treated exactly the same as longreal in the frontend? They have the sam= >e sizes and ranges and precisions. As for backends, at the moment m3cc i= >s generating 8 byte sse instructions for both types. The llvm is generating= > 10 byte float instructions as per its x86fp80 type which are a fair bit sl= >ower at the expense of greater range and precision. However they are not in= >teroperable with legacy libraries and we should probably change the type to= > agree with m3cc and the frontend. It seems that the 8087 80 bit float is = >being phased out see http://csapp.cs.cmu.edu/2e/waside/waside-x87.pdfso may= >be the m3 implementors saw the writing on the wall and and decided to wait = >for hardware to catch up. Anyway I wonder if its worth considering making e= >xtended one of the 128 bit floating point types which although emulated in = >software would at least give us a different type and one which would give s= >ome applications a huge precision (and range ~10^4090) boost. >> Peter =20 From jay.krell at cornell.edu Sun May 31 06:43:07 2015 From: jay.krell at cornell.edu (Jay K) Date: Sun, 31 May 2015 04:43:07 +0000 Subject: [M3devel] extended In-Reply-To: <20150531021831.160751A2062@async.async.caltech.edu> References: , , <20150531020946.GA10463@topoi.pooq.com>, <20150531021831.160751A2062@async.async.caltech.edu> Message-ID: Modula-3 may be good, but it isn't likely unique here. Apple did a good job probably. C9x caught up probably. - Jay > To: hendrik at topoi.pooq.com > Date: Sat, 30 May 2015 19:18:31 -0700 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] extended > > > Yes, it is standard practice to write x87 registers to memory and read > them back to guarantee one is not getting "extended" precision by mistake. > > Modula-3 does a pretty good job of defining what all the floating formats > are, if you look at the various interfaces for the formats. > > I seem to remember the story is that one of Kahan's grad students was > interning at SRC one summer and wrote the interfaces. > > "Among the best in the business." > > Mika > > Hendrik Boom writes: > >On Sun, May 31, 2015 at 01:52:41AM +0000, Jay K wrote: > >> Half seriously: Do we need FLOAT32, FLOAT64, FLOAT80, FLOAT128? > >> And some way to indicate what is available? > > > >Those who do serious numerical analysis for a iving are very careful of=20 > >their precisions. > > > >They really care about these datails to an extent most of us mortalls=20 > >don't. > > > >I've even had freinds complain about compilers that gave them *more*=20 > >precision than they had asked for. > > > >-- hendrik > > > >>=20 > >> =20 > >> On many/most/but-not-all modern 32bit x86 systems, "long double" is the > >> same as "double". Modula-3 is in agreement with many/most/but-not-all C s= > >ystems. > >> =20 > >>=20 > >> m3cc might be using x87 instructions on some platforms, at least sometime= > >s. > >> But that doesn't change in-memory extended to other than 64 bits. > >> Just temporary in-register values might be 80 bits. > >> =20 > >>=20 > >> - Jay > >>=20 > >>=20 > >> =20 > >> Date: Sun, 31 May 2015 09:06:26 +1000 > >> From: peter.mckinna at gmail.com > >> To: m3devel at elegosoft.com > >> Subject: [M3devel] extended > >>=20 > >> Hi > >> While we are on the subject of integer types can we diverge slightly to= > > floating point types. I wonder if anyone can explain why the extended type= > > is treated exactly the same as longreal in the frontend? They have the sam= > >e sizes and ranges and precisions. As for backends, at the moment m3cc i= > >s generating 8 byte sse instructions for both types. The llvm is generating= > > 10 byte float instructions as per its x86fp80 type which are a fair bit sl= > >ower at the expense of greater range and precision. However they are not in= > >teroperable with legacy libraries and we should probably change the type to= > > agree with m3cc and the frontend. It seems that the 8087 80 bit float is = > >being phased out see http://csapp.cs.cmu.edu/2e/waside/waside-x87.pdfso may= > >be the m3 implementors saw the writing on the wall and and decided to wait = > >for hardware to catch up. Anyway I wonder if its worth considering making e= > >xtended one of the 128 bit floating point types which although emulated in = > >software would at least give us a different type and one which would give s= > >ome applications a huge precision (and range ~10^4090) boost. > >> Peter =20 -------------- next part -------------- An HTML attachment was scrubbed... URL: From adacore at marino.st Sun May 31 09:41:16 2015 From: adacore at marino.st (John Marino) Date: Sun, 31 May 2015 09:41:16 +0200 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <5568B352.8060005@marino.st> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop> <556817A1.2090206@marino.st> <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de> <55682D1A.2030504@marino.st> <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de> <55683689.2090709@marino.st> <20150529122732.1396eb079ff9b404bcb21e40@elego.de> <5568421D.3050209@marino.st> <20150529155833.8454664b88391d93708e8f85@elego.de> <55687266.3090400@marino.st> <20150529162028.388911007a614006049beb42@elego.de> <20150529172305.a3fc2a9865b5250a5b9140fc@elego.de> <556885FD.6010800@marino.st> <20150529180223.d467621b68ebf665da685b12@elego.de> <55689065.1040207@marino.st> <20150529201531.b35e3cfdafeb9e2735e0020b@elegosoft.com> <5568B352.8060005@marino.st> Message-ID: <556ABB1C.5080607@marino.st> On 5/29/2015 20:43, John Marino wrote: > On 5/29/2015 20:15, Olaf Wagner wrote: >> >> Well, yes, I understand that. I would have tried your exact setup, >> but I have no system available to test that on. >> >> At least I have validated that based on the origianl 5.8.6 installation >> archive for AMD64_FREEBSD you can build the new compiler from the current >> sources with a simple call of the upgrade.sh script. which I still doubted >> yesterday. > > > The card I still have left to play is to extract the bootstrap, let it > overwrite itself per Rodney's technique and then build the real compiler > (dumping the whole "intermediate" area). FWIW, this did not work either. Rodney's technique doesn't seem to work with the ports bootstrap. I don't know why it would work with provided 5.8.6 but not rebuilt one. As far as I can tell, I did what he said would always work. I'm at a loss as to where to go from here. It's starting to look like I have to throw away the ports 5.8.6 bootstrap and start over somehow. I don't think it should be this hard. :( John From jay.krell at cornell.edu Sun May 31 11:53:59 2015 From: jay.krell at cornell.edu (Jay K) Date: Sun, 31 May 2015 09:53:59 +0000 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <556ABB1C.5080607@marino.st> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop> <556817A1.2090206@marino.st> <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de> <55682D1A.2030504@marino.st> <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de> <55683689.2090709@marino.st> <20150529122732.1396eb079ff9b404bcb21e40@elego.de> <5568421D.3050209@marino.st> <20150529155833.8454664b88391d93708e8f85@elego.de> <55687266.3090400@marino.st> <20150529162028.388911007a614006049beb42@elego.de> <20150529172305.a3fc2a9865b5250a5b9140fc@elego.de> <556885FD.6010800@marino.st> <20150529180223.d467621b68ebf665da685b12@elego.de> <55689065.1040207@marino.st> <20150529201531.b35e3cfdafeb9e2735e0020b@elegosoft.com>, <5568B352.8060005@marino.st>, <556ABB1C.5080607@marino.st> Message-ID: John, have you tried make-dist.py? i.e. https://github.com/modula3/cm3/blob/master/scripts/python/make-dist.py While it might not be exactly what you need, it should demonstrate the elements. I will try to try this all soon, really, I hope so. It starts with a working compiler, does no in-place updates, build into a unique directory in /tmp, and gives you .tar.gz or such at the end. It does "min" and "all". If you set the STAGE environment variable, it uses that instead of /tmp. It should probably be called M3_STATE or M3_MAKEDIST_STAGE. - Jay > Date: Sun, 31 May 2015 09:41:16 +0200 > From: adacore at marino.st > To: m3devel at elegosoft.com > Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > > On 5/29/2015 20:43, John Marino wrote: > > On 5/29/2015 20:15, Olaf Wagner wrote: > >> > >> Well, yes, I understand that. I would have tried your exact setup, > >> but I have no system available to test that on. > >> > >> At least I have validated that based on the origianl 5.8.6 installation > >> archive for AMD64_FREEBSD you can build the new compiler from the current > >> sources with a simple call of the upgrade.sh script. which I still doubted > >> yesterday. > > > > > > The card I still have left to play is to extract the bootstrap, let it > > overwrite itself per Rodney's technique and then build the real compiler > > (dumping the whole "intermediate" area). > > FWIW, this did not work either. Rodney's technique doesn't seem to work > with the ports bootstrap. I don't know why it would work with provided > 5.8.6 but not rebuilt one. As far as I can tell, I did what he said > would always work. > > I'm at a loss as to where to go from here. It's starting to look like I > have to throw away the ports 5.8.6 bootstrap and start over somehow. I > don't think it should be this hard. :( > > John -------------- next part -------------- An HTML attachment was scrubbed... URL: From adacore at marino.st Sun May 31 16:57:02 2015 From: adacore at marino.st (John Marino) Date: Sun, 31 May 2015 16:57:02 +0200 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop> <556817A1.2090206@marino.st> <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de> <55682D1A.2030504@marino.st> <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de> <55683689.2090709@marino.st> <20150529122732.1396eb079ff9b404bcb21e40@elego.de> <5568421D.3050209@marino.st> <20150529155833.8454664b88391d93708e8f85@elego.de> <55687266.3090400@marino.st> <20150529162028.388911007a614006049beb42@elego.de> <20150529172305.a3fc2a9865b5250a5b9140fc@elego.de> <556885FD.6010800@marino.st> <20150529180223.d467621b68ebf665da685b12@elego.de> <55689065.1040207@marino.st> <20150529201531.b35e3cfdafeb9e2735e0020b@elegosoft.com>, <5568B352.8060005@marino.st>, <556ABB1C.5080607@marino.st> Message-ID: <556B213E.8030108@marino.st> On 5/31/2015 11:53, Jay K wrote: > John, have you tried make-dist.py? > i.e. https://github.com/modula3/cm3/blob/master/scripts/python/make-dist.py > > While it might not be exactly what you need, it should demonstrate the > elements. > > I will try to try this all soon, really, I hope so. > > It starts with a working compiler, does no in-place updates, build into > a unique directory in /tmp, and gives you .tar.gz or such at the end. > It does "min" and "all". > > If you set the STAGE environment variable, it uses that instead of /tmp. > It should probably be called M3_STATE or M3_MAKEDIST_STAGE. > > - Jay > Hi Jay, I'm getting the same error as always using make-dist script: http://leaf.dragonflybsd.org/~marino/m3d.log Thanks, John From jay.krell at cornell.edu Sun May 31 18:45:42 2015 From: jay.krell at cornell.edu (Jay K) Date: Sun, 31 May 2015 16:45:42 +0000 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <556B213E.8030108@marino.st> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop>, <55673AA4.8050100@marino.st>, <20150528190643.faf81897fc5698a06bf37838@elegosoft.com>, <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop>, <556817A1.2090206@marino.st>, <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de>, <55682D1A.2030504@marino.st>, <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de>, <55683689.2090709@marino.st>, <20150529122732.1396eb079ff9b404bcb21e40@elego.de>, <5568421D.3050209@marino.st>, <20150529155833.8454664b88391d93708e8f85@elego.de>, <55687266.3090400@marino.st>, <20150529162028.388911007a614006049beb42@elego.de>, <20150529172305.a3fc2a9865b5250a5b9140fc@elego.de>, <556885FD.6010800@marino.st>, <20150529180223.d467621b68ebf665da685b12@elego.de>, <55689065.1040207@marino.st>, <20150529201531.b35e3cfdafeb9e2735e0020b@elegosoft.com>, <5568B352.8060005@marino.st>, <556ABB1C.5080607@marino.st>, , <556B213E.8030108@marino.st> Message-ID: Hm. Strange. I need to read more closely. I see it skipping shipping, but my read was it didn't try that. So.. with INSTALL_CM3_IN_BIN=yes? I need to try this all, and "fix" it to set that. The whole thing in m3cc/src/m3makefile is relatively new vs. when I was actively using all this. :( - Jay > Date: Sun, 31 May 2015 16:57:02 +0200 > From: adacore at marino.st > To: jay.krell at cornell.edu; m3devel at elegosoft.com > Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > > On 5/31/2015 11:53, Jay K wrote: > > John, have you tried make-dist.py? > > i.e. https://github.com/modula3/cm3/blob/master/scripts/python/make-dist.py > > > > While it might not be exactly what you need, it should demonstrate the > > elements. > > > > I will try to try this all soon, really, I hope so. > > > > It starts with a working compiler, does no in-place updates, build into > > a unique directory in /tmp, and gives you .tar.gz or such at the end. > > It does "min" and "all". > > > > If you set the STAGE environment variable, it uses that instead of /tmp. > > It should probably be called M3_STATE or M3_MAKEDIST_STAGE. > > > > - Jay > > > > Hi Jay, > I'm getting the same error as always using make-dist script: > http://leaf.dragonflybsd.org/~marino/m3d.log > > Thanks, > John -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun May 31 19:09:24 2015 From: jay.krell at cornell.edu (Jay K) Date: Sun, 31 May 2015 17:09:24 +0000 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: References: <556700B0.8060500@marino.st>,<55672DC1.7080509@lcwb.coop>, <55673AA4.8050100@marino.st>, , <20150528190643.faf81897fc5698a06bf37838@elegosoft.com>, , <55679387.8040701@lcwb.coop>, <5567DA8C.3050802@lcwb.coop>, <556817A1.2090206@marino.st>, , <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de>, , <55682D1A.2030504@marino.st>, , <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de>, , <55683689.2090709@marino.st>, , <20150529122732.1396eb079ff9b404bcb21e40@elego.de>, , <5568421D.3050209@marino.st>, , <20150529155833.8454664b88391d93708e8f85@elego.de>, , <55687266.3090400@marino.st>, , <20150529162028.388911007a614006049beb42@elego.de>, , <20150529172305.a3fc2a9865b5250a5b9140fc@elego.de>, , <556885FD.6010800@marino.st>, , <20150529180223.d467621b68ebf665da685b12@elego.de>, , <55689065.1040207@marino.st>, , <20150529201531.b35e3cfdafeb9e2735e0020b@elegosoft.com>, , <5568B352.8060005@marino.st>, <556ABB1C.5080607@marino.st>, , , , <556B213E.8030108@marino.st>, Message-ID: Oh probably the problem is using the backend premature actually. Darn, I can't help right now. - Jay From: jay.krell at cornell.edu To: adacore at marino.st; m3devel at elegosoft.com Date: Sun, 31 May 2015 16:45:42 +0000 Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 Hm. Strange. I need to read more closely. I see it skipping shipping, but my read was it didn't try that. So.. with INSTALL_CM3_IN_BIN=yes? I need to try this all, and "fix" it to set that. The whole thing in m3cc/src/m3makefile is relatively new vs. when I was actively using all this. :( - Jay > Date: Sun, 31 May 2015 16:57:02 +0200 > From: adacore at marino.st > To: jay.krell at cornell.edu; m3devel at elegosoft.com > Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > > On 5/31/2015 11:53, Jay K wrote: > > John, have you tried make-dist.py? > > i.e. https://github.com/modula3/cm3/blob/master/scripts/python/make-dist.py > > > > While it might not be exactly what you need, it should demonstrate the > > elements. > > > > I will try to try this all soon, really, I hope so. > > > > It starts with a working compiler, does no in-place updates, build into > > a unique directory in /tmp, and gives you .tar.gz or such at the end. > > It does "min" and "all". > > > > If you set the STAGE environment variable, it uses that instead of /tmp. > > It should probably be called M3_STATE or M3_MAKEDIST_STAGE. > > > > - Jay > > > > Hi Jay, > I'm getting the same error as always using make-dist script: > http://leaf.dragonflybsd.org/~marino/m3d.log > > Thanks, > John -------------- next part -------------- An HTML attachment was scrubbed... URL: From adacore at marino.st Sun May 31 19:59:05 2015 From: adacore at marino.st (John Marino) Date: Sun, 31 May 2015 19:59:05 +0200 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: References: <556700B0.8060500@marino.st>, <55679387.8040701@lcwb.coop>, <5567DA8C.3050802@lcwb.coop>, <556817A1.2090206@marino.st>, , <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de>, , <55682D1A.2030504@marino.st>, , <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de>, , <55683689.2090709@marino.st>, , <20150529122732.1396eb079ff9b404bcb21e40@elego.de>, , <5568421D.3050209@marino.st>, , <20150529155833.8454664b88391d93708e8f85@elego.de>, , <55687266.3090400@marino.st>, , <20150529162028.388911007a614006049beb42@elego.de>, , <20150529172305.a3fc2a9865b5250a5b9140fc@elego.de>, , <556885FD.6010800@marino.st>, , <20150529180223.d467621b68ebf665da685b12@elego.de>, , <55689065.1040207@marino.st>, , <20150529201531.b35e3cfdafeb9e2735e0020b@elegosoft.com>, , <5568B352.8060005@marino.st>, <556ABB1C.5080607@marino.st>, , , , <556B213E.8030108@marino.st>, Message-ID: <556B4BE9.1000902@marino.st> I removed "INSTALL_CM3_IN_BIN=yes" after reading the thread about it. Should I put it back? From the last response I'm guessing that wasn't the problem. John On 5/31/2015 19:09, Jay K wrote: > Oh probably the problem is using the backend premature actually. > Darn, I can't help right now. > > - Jay > > > > ------------------------------------------------------------------------ > From: jay.krell at cornell.edu > To: adacore at marino.st; m3devel at elegosoft.com > Date: Sun, 31 May 2015 16:45:42 +0000 > Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp > (0x100), expected 0x110 > > Hm. Strange. I need to read more closely. I see it skipping shipping, > but my read was it didn't try that. > So.. with INSTALL_CM3_IN_BIN=yes? > I need to try this all, and "fix" it to set that. The whole thing in > m3cc/src/m3makefile is relatively > new vs. when I was actively using all this. :( > > - Jay > > >> Date: Sun, 31 May 2015 16:57:02 +0200 >> From: adacore at marino.st >> To: jay.krell at cornell.edu; m3devel at elegosoft.com >> Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp > (0x100), expected 0x110 >> >> On 5/31/2015 11:53, Jay K wrote: >> > John, have you tried make-dist.py? >> > i.e. > https://github.com/modula3/cm3/blob/master/scripts/python/make-dist.py >> > >> > While it might not be exactly what you need, it should demonstrate the >> > elements. >> > >> > I will try to try this all soon, really, I hope so. >> > >> > It starts with a working compiler, does no in-place updates, build into >> > a unique directory in /tmp, and gives you .tar.gz or such at the end. >> > It does "min" and "all". >> > >> > If you set the STAGE environment variable, it uses that instead of /tmp. >> > It should probably be called M3_STATE or M3_MAKEDIST_STAGE. >> > >> > - Jay >> > >> >> Hi Jay, >> I'm getting the same error as always using make-dist script: >> http://leaf.dragonflybsd.org/~marino/m3d.log >> >> Thanks, >> John From estellnb at elstel.org Sun May 31 19:50:21 2015 From: estellnb at elstel.org (Elmar Stellnberger) Date: Sun, 31 May 2015 19:50:21 +0200 Subject: [M3devel] cm3/m3quake: setting environment variables for exec Message-ID: <556B49DD.20909@elstel.org> How can I set environment variables for exec with cm3? Using /usr/bin/env would be inherently non-portable. With SRC M3 I remember this was the 4th parameter or so. However cm3 exec seems to do something very different. From rodney_bates at lcwb.coop Sun May 31 20:30:46 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sun, 31 May 2015 13:30:46 -0500 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <556B4BE9.1000902@marino.st> References: <556700B0.8060500@marino.st>, <5567DA8C.3050802@lcwb.coop>, <556817A1.2090206@marino.st>, , <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de>, , <55682D1A.2030504@marino.st>, , <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de>, , <55683689.2090709@marino.st>, , <20150529122732.1396eb079ff9b404bcb21e40@elego.de>, , <5568421D.3050209@marino.st>, , <20150529155833.8454664b88391d93708e8f85@elego.de>, , <55687266.3090400@marino.st>, , <20150529162028.388911007a614006049beb42@elego.de>, , <20150529172305.a3fc2a9865b5250a5b9140fc@elego.de>, , <556885FD.6010800@marino.st>, , <20150529180223.d467621b68ebf665da685b12@elego.de>, , <55689065.1040207@marino.st>, , <20150529201531.b35e3cfdafeb9e2735e0020b@elegosoft.com>, , <5568B352.8060005@marino.st>, <556ABB1C.5080607@marino.st>, , , , <556B213E.8030108@marino.st>, <556B4BE9.1000902@marino .st> Message-ID: <556B5356.40809@lcwb.coop> On 05/31/2015 12:59 PM, John Marino wrote: > I removed "INSTALL_CM3_IN_BIN=yes" after reading the thread about it. > Should I put it back? From the last response I'm guessing that wasn't > the problem. > > John > It apparently wasn't the only problem, but it definitely was a problem. Don't put it back. I causes the new cm3cg executable to be copied to your bin directory immediately after it has been built. It is incompatible with the old cm3 executable, and the next attempted build (m3core, as I remember) runs the old cm3, then the new cm3cg, which correctly recognizes that its input is in an old version format and refuses, giving the error message. > > On 5/31/2015 19:09, Jay K wrote: >> Oh probably the problem is using the backend premature actually. >> Darn, I can't help right now. >> >> - Jay >> >> >> >> ------------------------------------------------------------------------ >> From: jay.krell at cornell.edu >> To: adacore at marino.st; m3devel at elegosoft.com >> Date: Sun, 31 May 2015 16:45:42 +0000 >> Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp >> (0x100), expected 0x110 >> >> Hm. Strange. I need to read more closely. I see it skipping shipping, >> but my read was it didn't try that. >> So.. with INSTALL_CM3_IN_BIN=yes? >> I need to try this all, and "fix" it to set that. The whole thing in >> m3cc/src/m3makefile is relatively >> new vs. when I was actively using all this. :( >> >> - Jay >> >> >>> Date: Sun, 31 May 2015 16:57:02 +0200 >>> From: adacore at marino.st >>> To: jay.krell at cornell.edu; m3devel at elegosoft.com >>> Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp >> (0x100), expected 0x110 >>> >>> On 5/31/2015 11:53, Jay K wrote: >>>> John, have you tried make-dist.py? >>>> i.e. >> https://github.com/modula3/cm3/blob/master/scripts/python/make-dist.py >>>> >>>> While it might not be exactly what you need, it should demonstrate the >>>> elements. >>>> >>>> I will try to try this all soon, really, I hope so. >>>> >>>> It starts with a working compiler, does no in-place updates, build into >>>> a unique directory in /tmp, and gives you .tar.gz or such at the end. >>>> It does "min" and "all". >>>> >>>> If you set the STAGE environment variable, it uses that instead of /tmp. >>>> It should probably be called M3_STATE or M3_MAKEDIST_STAGE. >>>> >>>> - Jay >>>> >>> >>> Hi Jay, >>> I'm getting the same error as always using make-dist script: >>> http://leaf.dragonflybsd.org/~marino/m3d.log >>> >>> Thanks, >>> John > -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Sun May 31 21:13:46 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sun, 31 May 2015 14:13:46 -0500 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <556ABB1C.5080607@marino.st> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop> <556817A1.2090206@marino.st> <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de> <55682D1A.2030504@marino.st> <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de> <55683689.2090709@marino.st> <20150529122732.1396eb079ff9b404bcb21e40@elego.de> <5568421D.3050209@marino.st> <20150529155833.8454664b88391d93708e8f85@elego.de> <55687266.3090400@marino.st> <20150529162028.388911007a614006049beb42@elego.de> <20150529172305.a3fc2a9865b5250a5b9140fc@elego.de> <556885FD.6010800@marino.st> <20150529180223.d467621b68ebf665da685b12@elego.de> <55689065.1040207@marino.st> <20150529201531.b35e3cfdafeb9e2735e0020b@elegosoft.com> <5568B352.8060005@marino.st> <556ABB1C.5080607@marino.st> Message-ID: <556B5D6A.3030403@lcwb.coop> The error message you keep getting pretty certainly means it is running a new cm3cg with an old cm3. And it consistently happens immediately after cm3cg is rebuilt. The build of cm3cg (package m3cc) appears to be the first use of cm3 in all your failed builds, and I don't think that package would ever run cm3cg, as there is no Modula-3 code in it. Which means there is no proof that the version of cm3cg that would have been used before it was rebuilt is the old one. (Could it be a new one left over from a previous incomplete build?) One experiment that would prove this would be, in the state your are starting from before trying a full build, try any means of running cm3 on a package that contains Modula-3 code, to see if it avoids the recurring problem. But I have another theory. I don't know what this ports bootstrap is, but there was a time when things where set up so that cm3, instead of looking in just the same directory as its own executable was found, was looking several alternative places for an executable cm3cg. This caused the same problem to occur in a different way. Even when the newly rebuilt cm3cg executable was not copied to the bin directory right away, its mere existence where it was built was causing it to be found the next time cm3 started up, leading to the same failure. I don't remember how this was fixed, but either Jay or I did something about it. Perhaps the ports bootstrap was made during a time when this behavior was happening. On 05/31/2015 02:41 AM, John Marino wrote: > On 5/29/2015 20:43, John Marino wrote: >> On 5/29/2015 20:15, Olaf Wagner wrote: >>> >>> Well, yes, I understand that. I would have tried your exact setup, >>> but I have no system available to test that on. >>> >>> At least I have validated that based on the origianl 5.8.6 installation >>> archive for AMD64_FREEBSD you can build the new compiler from the current >>> sources with a simple call of the upgrade.sh script. which I still doubted >>> yesterday. >> >> >> The card I still have left to play is to extract the bootstrap, let it >> overwrite itself per Rodney's technique and then build the real compiler >> (dumping the whole "intermediate" area). > > FWIW, this did not work either. Rodney's technique doesn't seem to work > with the ports bootstrap. I don't know why it would work with provided > 5.8.6 but not rebuilt one. As far as I can tell, I did what he said > would always work. > > I'm at a loss as to where to go from here. It's starting to look like I > have to throw away the ports 5.8.6 bootstrap and start over somehow. I > don't think it should be this hard. :( > > John > -- Rodney Bates rodney.m.bates at acm.org From adacore at marino.st Sun May 31 21:26:45 2015 From: adacore at marino.st (John Marino) Date: Sun, 31 May 2015 21:26:45 +0200 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <556B5D6A.3030403@lcwb.coop> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop> <556817A1.2090206@marino.st> <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de> <55682D1A.2030504@marino.st> <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de> <55683689.2090709@marino.st> <20150529122732.1396eb079ff9b404bcb21e40@elego.de> <5568421D.3050209@marino.st> <20150529155833.8454664b88391d93708e8f85@elego.de> <55687266.3090400@marino.st> <20150529162028.388911007a614006049beb42@elego.de> <20150529172305.a3fc2a9865b5250a5b9140fc@elego.de> <556885FD.6010800@marino.st> <20150529180223.d467621b68ebf665da685b12@elego.de> <55689065.1040207@marino.st> <20150529201531.b35e3cfdafeb9e2735e0020b@elegosoft.com> <5568B352.8060005@marino.st> <556ABB1C.5080607@marino.st> <556B5D6A.3030403@lcwb.coop> Message-ID: <556B6075.6010703@marino.st> On 5/31/2015 21:13, Rodney M. Bates wrote: > The error message you keep getting pretty certainly means it is running a > new cm3cg with an old cm3. And it consistently happens immediately after > cm3cg is rebuilt. > > The build of cm3cg (package m3cc) appears to be the first use of cm3 in all > your failed builds, and I don't think that package would ever run cm3cg, as > there is no Modula-3 code in it. Which means there is no proof that the > version of cm3cg that would have been used before it was rebuilt is the old > one. (Could it be a new one left over from a previous incomplete build?) That's not possible. The bootstrap is packaged in a compressed tarball and extracted for the sole purpose of building M3. It would have not leftovers in it. It comes with cm3, cm3cg, m3bundle, and mklib in the bin directory. the contents of the bootstrap M3 cm3.cfg are: INSTALL_ROOT = path() & "/.." include (path() & "/../etc/modula3/AMD64_FREEBSD") > One experiment that would prove this would be, in the state your are > starting from before trying a full build, try any means of running > cm3 on a package that contains Modula-3 code, to see if it avoids the > recurring problem. I think this is N/A. The bootstrap compiler is extracted to a directory that is not on the path (and only exists right before trying to build modula3 port) > But I have another theory. I don't know what this ports bootstrap > is, but there was a time when things where set up so that cm3, instead > of looking in just the same directory as its own executable was found, > was looking several alternative places for an executable cm3cg. This It's 5.8.6 and the cm3.cfg is listed above. You can download it yourself here: http://downloads.dragonlace.net/m3/m3-bootstrap.AMD64.FREEBSD.92.tar.bz2 > caused the same problem to occur in a different way. Even when the > newly rebuilt cm3cg executable was not copied to the bin directory > right away, its mere existence where it was built was causing it to > be found the next time cm3 started up, leading to the same failure. > > I don't remember how this was fixed, but either Jay or I did something > about it. Perhaps the ports bootstrap was made during a time when this > behavior was happening. Probably not as I am 99% sure the bootstrap was built from the release source. Thanks, John From rodney_bates at lcwb.coop Sun May 31 22:14:09 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sun, 31 May 2015 15:14:09 -0500 Subject: [M3devel] The role INTEGER and subranges in Modula-3 In-Reply-To: <5569E656.6080909@elstel.org> References: <5569D3AA.2040009@lcwb.coop> <5569E656.6080909@elstel.org> Message-ID: <556B6B91.1030600@lcwb.coop> On 05/30/2015 11:33 AM, Elmar Stellnberger wrote: > Am 30.05.15 um 17:13 schrieb Rodney M. Bates: >> There are no implicit type conversions. Instead, this need is met by >> the concept of assignability. If the abstract value is in a >> variable's range, it can be assigned to the variable. Size changes, >> if needed, are the code generator's problem. > So what does the code generator do if there is an overflow not checked > by the predefined value range (i.e. BITS 8 FOR INTEGER instead of > BITS 8 for [0..255]) BITS 8 FOR INTEGER will not compile. It is statically illegal, because the asked-for bit size is not enough to hold the value range of the type INTEGER. (Unless the compiler is configured with FIRST(INTEGER) = -128 and LAST(INTEGER) = 127, as might be done for an 8-bit microprocessor.) >> All this drastically simplifies the language, while also allowing the ... > Yes, I understand your decision. >> likely to be commonly needed, LONGINT would have no place. But native >> sized arithmetic is always the most efficient. In today's world, >> there are two very common classes of use cases: 1) 32-bit arithmetic is wide enough, 2) 32-bit is not wide enough, but 64-bit is. In both >> cases, on machines of either native arithmetic size, we want the best >> efficiency. LONGINT is for case 2, and when you further need to be >> able to run on either size of machine. INTEGER is for otherwise. > Well, that was exactly my argument for a language specified type > size of INTEGER, because things do not get faster if you use 64bit > integers instead of 32bit integers. CPU arithmetics perhaps but the > real bottleneck of today is the memory hierarchy - and using 64bit > integers doubles our memory need at least for scalars. >> >> Whether you believe in LONGINT or not, there is certainly no >> justification for more base integer types than two: one the native >> size of the machine and one bigger. > Yes, we really don`t need them as anything becomes 64bit or the native > word size respectively on the stack (that is why Ctypes.int works). > Memory latency should be a minor issue as long as our parameters and > parts of the activation records fit into the cache. > > > > -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Sun May 31 22:51:10 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sun, 31 May 2015 15:51:10 -0500 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <556B6075.6010703@marino.st> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop> <556817A1.2090206@marino.st> <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de> <55682D1A.2030504@marino.st> <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de> <55683689.2090709@marino.st> <20150529122732.1396eb079ff9b404bcb21e40@elego.de> <5568421D.3050209@marino.st> <20150529155833.8454664b88391d93708e8f85@elego.de> <55687266.3090400@marino.st> <20150529162028.388911007a614006049beb42@elego.de> <20150529172305.a3fc2a9865b5250a5b9140fc@elego.de> <556885FD.6010800@marino.st> <20150529180223.d467621b68ebf665da685b12@elego.de> <55689065.1040207@marino.st> <20150529201531.b35e3cfdafeb9e2735e0020b@elegosoft.com> <5568B352.8060005@marino.st> <556ABB1C.5080607@marino.st> <556B5D6A.3030403@lcwb.coop> <556B6075.6010703@marino.st> Message-ID: <556B743E.7030504@lcwb.coop> On 05/31/2015 02:26 PM, John Marino wrote: > On 5/31/2015 21:13, Rodney M. Bates wrote: >> The error message you keep getting pretty certainly means it is running a >> new cm3cg with an old cm3. And it consistently happens immediately after >> cm3cg is rebuilt. >> >> The build of cm3cg (package m3cc) appears to be the first use of cm3 in all >> your failed builds, and I don't think that package would ever run cm3cg, as >> there is no Modula-3 code in it. Which means there is no proof that the >> version of cm3cg that would have been used before it was rebuilt is the old >> one. (Could it be a new one left over from a previous incomplete build?) > > That's not possible. The bootstrap is packaged in a compressed tarball > and extracted for the sole purpose of building M3. It would have not > leftovers in it. > > It comes with cm3, cm3cg, m3bundle, and mklib in the bin directory. > > the contents of the bootstrap M3 cm3.cfg are: > INSTALL_ROOT = path() & "/.." > include (path() & "/../etc/modula3/AMD64_FREEBSD") > > >> One experiment that would prove this would be, in the state your are >> starting from before trying a full build, try any means of running >> cm3 on a package that contains Modula-3 code, to see if it avoids the >> recurring problem. > > I think this is N/A. The bootstrap compiler is extracted to a directory > that is not on the path (and only exists right before trying to build > modula3 port) > > >> But I have another theory. I don't know what this ports bootstrap >> is, but there was a time when things where set up so that cm3, instead >> of looking in just the same directory as its own executable was found, >> was looking several alternative places for an executable cm3cg. This > > It's 5.8.6 and the cm3.cfg is listed above. You can download it > yourself here: > http://downloads.dragonlace.net/m3/m3-bootstrap.AMD64.FREEBSD.92.tar.bz2 > OK, the fix I mentioned is in the 5.8 release branch on github, but it is not in the above bootstrap. In file bootstrap/etc/modula3/cm3cfg.common, line 274 needs to change from: 274: foreach root in [ m3cc, bin ] to: 274: foreach root in [ bin ] Before building the Modula-3 head. > >> caused the same problem to occur in a different way. Even when the >> newly rebuilt cm3cg executable was not copied to the bin directory >> right away, its mere existence where it was built was causing it to >> be found the next time cm3 started up, leading to the same failure. >> >> I don't remember how this was fixed, but either Jay or I did something >> about it. Perhaps the ports bootstrap was made during a time when this >> behavior was happening. > > Probably not as I am 99% sure the bootstrap was built from the release > source. > > Thanks, > John > > > > -- Rodney Bates rodney.m.bates at acm.org From jay.krell at cornell.edu Sat May 2 11:16:49 2015 From: jay.krell at cornell.edu (Jay K) Date: Sat, 2 May 2015 09:16:49 +0000 Subject: [M3devel] the need for cooperative suspend Message-ID: We really need to move away from preemptive suspend. 1) It is a large fraction of the target-dependent code in m3core. 2) It doesn't really work in "wow64", the x86-on-amd64 Windows system. The SuspendThread + GetThreadContext does not actually reliably give you current and coherent context. I'm not sure about x86-on-ia64. The context can be old. The context can be mid-update. Which might be ok, depending on what the updates are. LIke if Eip and Esp are being updated, we don't care about Eip anyway. You can find out if either is the case, and let the thread run longer, but being in a long running syscall I believe is reported as possibly invalid even though it is valid. NT/native is ok. We should just use cooperative suspend and not worry about it. Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Sat May 2 17:57:13 2015 From: mika at async.caltech.edu (mika at async.caltech.edu) Date: Sat, 02 May 2015 08:57:13 -0700 Subject: [M3devel] the need for cooperative suspend In-Reply-To: References: Message-ID: <20150502155713.29DCC1A2062@async.async.caltech.edu> Jay, Can you explain precisely what you mean by "suspend"? A thread is suspended by ... a timer expiration? Another thread at higher priority needing resources? I'm thinking about a tight loop "for(;;) ;"... how do you stop a thread from running that (it could have been coded in assembly...)? Jay K writes: >--_6bc62225-3263-437a-a88c-4b1ff9473d58_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > >We really need to move away from preemptive suspend. > >1) It is a large fraction of the target-dependent code in m3core. >=20 > >2) It doesn't really work in "wow64"=2C the x86-on-amd64 Windows system. >The SuspendThread + GetThreadContext does not actually reliably give you >current and coherent context. >I'm not sure about x86-on-ia64. >=20 > > The context can be old. > The context can be mid-update. Which might be ok=2C depending on what the = >updates are. > LIke if Eip and Esp are being updated=2C we don't care about Eip anyway. >=20 > >You can find out if either is the case=2C and let the thread run longer=2C >but being in a long running syscall I believe is reported as possibly >invalid even though it is valid. >=20 >=20 >NT/native is ok. >=20 > >We should just use cooperative suspend and not worry about it. >=20 >=20 >Thanks=2C > - Jay > > >=20 > = > >--_6bc62225-3263-437a-a88c-4b1ff9473d58_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > >
We really need to move away from= > preemptive suspend.

1) It is a large fraction of the target-depende= >nt code in m3core.
 =3B

2) It doesn't really work in "wow64"= >=2C the x86-on-amd64 Windows system.
The SuspendThread + GetThreadContex= >t does not actually reliably give you
current and coherent context.
I= >'m not sure about x86-on-ia64.
 =3B

 =3BThe context can b= >e old.
 =3BThe context can be mid-update. Which might be ok=2C depen= >ding on what the updates are.
 =3BLIke if Eip and Esp are being upda= >ted=2C we don't care about Eip anyway.
 =3B

You can find out = >if either is the case=2C and let the thread run longer=2C
but being in a= > long running syscall I believe is reported as possibly
invalid even tho= >ugh it is valid.
 =3B
 =3B
NT/native is ok.
 =3B>
We should just use cooperative suspend and not worry about it.
&nbs= >p=3B
 =3B
Thanks=2C
 =3B- Jay


 =3B
= >
>= > >--_6bc62225-3263-437a-a88c-4b1ff9473d58_-- From jay.krell at cornell.edu Sat May 2 21:13:31 2015 From: jay.krell at cornell.edu (Jay) Date: Sat, 2 May 2015 12:13:31 -0700 Subject: [M3devel] the need for cooperative suspend In-Reply-To: <20150502155713.29DCC1A2062@async.async.caltech.edu> References: <20150502155713.29DCC1A2062@async.async.caltech.edu> Message-ID: In the preemptive case, you call SuspendThread and a hardware interrupt is sent to the processor. Cooperative suspend does not have this power. There ends up being, I guess, an analog between non-polling code and the "fixed" wow64 method that is also easily starved w/o more sophistication. Thinking more about this...maybe preemptive is viable with a little more work. In particular we can record when we leave "managed" code and leave a reliable stack pointer for ourselves. We can then safely preempt "native" code, getting context from our own data structures instead of the operating system. Native code though could allocate traced data though, without registering with the runtime somehow. - Jay On May 2, 2015, at 8:57 AM, wrote: > Jay, > > Can you explain precisely what you mean by "suspend"? > > A thread is suspended by ... a timer expiration? Another thread at higher priority needing resources? > > I'm thinking about a tight loop "for(;;) ;"... how do you stop a thread from running that (it could have > been coded in assembly...)? > > Jay K writes: >> --_6bc62225-3263-437a-a88c-4b1ff9473d58_ >> Content-Type: text/plain; charset="iso-8859-1" >> Content-Transfer-Encoding: quoted-printable >> >> We really need to move away from preemptive suspend. >> >> 1) It is a large fraction of the target-dependent code in m3core. >> =20 >> >> 2) It doesn't really work in "wow64"=2C the x86-on-amd64 Windows system. >> The SuspendThread + GetThreadContext does not actually reliably give you >> current and coherent context. >> I'm not sure about x86-on-ia64. >> =20 >> >> The context can be old. >> The context can be mid-update. Which might be ok=2C depending on what the = >> updates are. >> LIke if Eip and Esp are being updated=2C we don't care about Eip anyway. >> =20 >> >> You can find out if either is the case=2C and let the thread run longer=2C >> but being in a long running syscall I believe is reported as possibly >> invalid even though it is valid. >> =20 >> =20 >> NT/native is ok. >> =20 >> >> We should just use cooperative suspend and not worry about it. >> =20 >> =20 >> Thanks=2C >> - Jay >> >> >> =20 >> = >> >> --_6bc62225-3263-437a-a88c-4b1ff9473d58_ >> Content-Type: text/html; charset="iso-8859-1" >> Content-Transfer-Encoding: quoted-printable >> >> >> >> >>
We really need to move away from= >> preemptive suspend.

1) It is a large fraction of the target-depende= >> nt code in m3core.
 =3B

2) It doesn't really work in "wow64"= >> =2C the x86-on-amd64 Windows system.
The SuspendThread + GetThreadContex= >> t does not actually reliably give you
current and coherent context.
I= >> 'm not sure about x86-on-ia64.
 =3B

 =3BThe context can b= >> e old.
 =3BThe context can be mid-update. Which might be ok=2C depen= >> ding on what the updates are.
 =3BLIke if Eip and Esp are being upda= >> ted=2C we don't care about Eip anyway.
 =3B

You can find out = >> if either is the case=2C and let the thread run longer=2C
but being in a= >> long running syscall I believe is reported as possibly
invalid even tho= >> ugh it is valid.
 =3B
 =3B
NT/native is ok.
 =3B>>
We should just use cooperative suspend and not worry about it.
&nbs= >> p=3B
 =3B
Thanks=2C
 =3B- Jay


 =3B
= >>
>> = >> >> --_6bc62225-3263-437a-a88c-4b1ff9473d58_-- From rodney_bates at lcwb.coop Fri May 15 21:50:28 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Fri, 15 May 2015 14:50:28 -0500 Subject: [M3devel] Not getting github notifications Message-ID: <55564E04.1080401@lcwb.coop> After a lot of poking around in github.com/modula3, it is apparent that there has been some activity that I hadn't heard about. I have, for some time, had my account set up so that (I thought) I would get generated emails for pushes to the repository. But apparently, it only works when _I_ push, which, of course, is not big news to me. I also tried adding m3commit at elegosoft.com to the list of email addresses to be sent to, but that one doesn't come through at all. Any advice? -- Rodney Bates rodney.m.bates at acm.org From wagner at elegosoft.com Sun May 17 01:18:24 2015 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 17 May 2015 01:18:24 +0200 Subject: [M3devel] Bootstrapping cm3 on OS X 10.9.5 Message-ID: <20150517011824.75f096c832d5da56e4810bbf@elegosoft.com> After several years I've just tried to setup a current cm3 on my computer again. I've cloned the repository from github/modula3/cm3, installed the latest binary archive for Darwin I could find -- which is that of the 5.8.6 release several years ago -- and tried to compile some sources. This always fails with lots of these errors: m3cc (aka cm3cg) failed compiling: PklFpMap.mc new source -> compiling FpIntTbl.m3 m3cgc1: fatal error: *** illegal type: 0x17, at m3cg_lineno 4 compilation terminated. regardless if I use the 5.8.6 backend or build a new cm3cg from sources (which actually succeeds). Any suggestions how to continue? Are newer bootstrap archives available somewhere? Any hints are appreciated. Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From rodney_bates at lcwb.coop Sun May 17 16:48:00 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sun, 17 May 2015 09:48:00 -0500 Subject: [M3devel] Bootstrapping cm3 on OS X 10.9.5 In-Reply-To: <20150517011824.75f096c832d5da56e4810bbf@elegosoft.com> References: <20150517011824.75f096c832d5da56e4810bbf@elegosoft.com> Message-ID: <5558AA20.1090208@lcwb.coop> This is a familiar error to me, but I can't remember the details right off hand. I would have said it was an old m3cc, but you have built the latest one, so that theory goes down the drain. I'll see what I can reconstruct. On 05/16/2015 06:18 PM, Olaf Wagner wrote: > After several years I've just tried to setup a current cm3 on my computer > again. I've cloned the repository from github/modula3/cm3, installed > the latest binary archive for Darwin I could find -- which is that of > the 5.8.6 release several years ago -- and tried to compile some sources. > > This always fails with lots of these errors: > > m3cc (aka cm3cg) failed compiling: PklFpMap.mc > new source -> compiling FpIntTbl.m3 > m3cgc1: fatal error: *** illegal type: 0x17, at m3cg_lineno 4 > compilation terminated. > > regardless if I use the 5.8.6 backend or build a new cm3cg from > sources (which actually succeeds). > > Any suggestions how to continue? > Are newer bootstrap archives available somewhere? > Any hints are appreciated. > > Olaf > -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Mon May 18 18:34:58 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Mon, 18 May 2015 11:34:58 -0500 Subject: [M3devel] Bootstrapping cm3 on OS X 10.9.5 In-Reply-To: <5558AA20.1090208@lcwb.coop> References: <20150517011824.75f096c832d5da56e4810bbf@elegosoft.com> <5558AA20.1090208@lcwb.coop> Message-ID: <555A14B2.7090900@lcwb.coop> Well, I have not been able to reproduce this on AMD64_LINUX, nor see by looking at code what it might be. ISTR that it is some kind of front-end/back-end mismatch. But the CGType codes that m3cc in trying to read have not changed in either the front-end nor the back-end since the release. 0x17 is well out of range. m3cc must be lost and trying to interpret something else as a type. On 05/17/2015 09:48 AM, Rodney M. Bates wrote: > This is a familiar error to me, but I can't remember the details right off hand. > I would have said it was an old m3cc, but you have built the latest one, > so that theory goes down the drain. I'll see what I can reconstruct. > > On 05/16/2015 06:18 PM, Olaf Wagner wrote: >> After several years I've just tried to setup a current cm3 on my computer >> again. I've cloned the repository from github/modula3/cm3, installed >> the latest binary archive for Darwin I could find -- which is that of >> the 5.8.6 release several years ago -- and tried to compile some sources. >> >> This always fails with lots of these errors: >> >> m3cc (aka cm3cg) failed compiling: PklFpMap.mc >> new source -> compiling FpIntTbl.m3 >> m3cgc1: fatal error: *** illegal type: 0x17, at m3cg_lineno 4 >> compilation terminated. >> >> regardless if I use the 5.8.6 backend or build a new cm3cg from >> sources (which actually succeeds). >> >> Any suggestions how to continue? >> Are newer bootstrap archives available somewhere? >> Any hints are appreciated. >> >> Olaf >> > -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Mon May 18 18:55:10 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Mon, 18 May 2015 11:55:10 -0500 Subject: [M3devel] Bootstrapping cm3 on OS X 10.9.5 In-Reply-To: <555A14B2.7090900@lcwb.coop> References: <20150517011824.75f096c832d5da56e4810bbf@elegosoft.com> <5558AA20.1090208@lcwb.coop> <555A14B2.7090900@lcwb.coop> Message-ID: <555A196E.2020106@lcwb.coop> Olaf, I think you must have a wrong version of cm3cg. I paper-traced through the first few IR opcodes of PklFpMap.mc (as generated by my cm3 executable, fairly recently built from the git repository) and encountered several changes to the binary opcodes, one of which I made. Using a release 5.8 version of cm3cg, I got a similar (though not identical) error: rodney at allegheny:~/proj/m3/git/cm3/m3-libs/libm3/AMD64_LINUX$ /usr/local/cm3-release/bin/cm3cg -quiet -fno-reorder-blocks -funwind-tables -fPIC -m64 -gstabs+ PklFpMap.mc -o PklFpMap.ms cm3cg: fatal error: *** illegal type: 0x20, at m3cg_lineno 2 compilation terminated. The type 0x20 and and m3cg_lineno 2 values agree with what I expect from the source code I have for the release branch, CVS repository. That suggests you have a third version of cm3cg. (Or maybe not the right version of cm3 front-end?) This is on AMD64_LINUX. On 05/18/2015 11:34 AM, Rodney M. Bates wrote: > Well, I have not been able to reproduce this on AMD64_LINUX, nor see by looking > at code what it might be. ISTR that it is some kind of front-end/back-end > mismatch. But the CGType codes that m3cc in trying to read have not changed > in either the front-end nor the back-end since the release. 0x17 is well > out of range. m3cc must be lost and trying to interpret something else as > a type. > > On 05/17/2015 09:48 AM, Rodney M. Bates wrote: >> This is a familiar error to me, but I can't remember the details right off hand. >> I would have said it was an old m3cc, but you have built the latest one, >> so that theory goes down the drain. I'll see what I can reconstruct. >> >> On 05/16/2015 06:18 PM, Olaf Wagner wrote: >>> After several years I've just tried to setup a current cm3 on my computer >>> again. I've cloned the repository from github/modula3/cm3, installed >>> the latest binary archive for Darwin I could find -- which is that of >>> the 5.8.6 release several years ago -- and tried to compile some sources. >>> >>> This always fails with lots of these errors: >>> >>> m3cc (aka cm3cg) failed compiling: PklFpMap.mc >>> new source -> compiling FpIntTbl.m3 >>> m3cgc1: fatal error: *** illegal type: 0x17, at m3cg_lineno 4 >>> compilation terminated. >>> >>> regardless if I use the 5.8.6 backend or build a new cm3cg from >>> sources (which actually succeeds). >>> >>> Any suggestions how to continue? >>> Are newer bootstrap archives available somewhere? >>> Any hints are appreciated. >>> >>> Olaf >>> >> > -- Rodney Bates rodney.m.bates at acm.org From wagner at elegosoft.com Mon May 18 23:47:14 2015 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 18 May 2015 23:47:14 +0200 Subject: [M3devel] Bootstrapping cm3 on OS X 10.9.5 In-Reply-To: <555A196E.2020106@lcwb.coop> References: <20150517011824.75f096c832d5da56e4810bbf@elegosoft.com> <5558AA20.1090208@lcwb.coop> <555A14B2.7090900@lcwb.coop> <555A196E.2020106@lcwb.coop> Message-ID: <20150518234714.dd1c111374ba3614cd74a63e@elegosoft.com> On Mon, 18 May 2015 11:55:10 -0500 "Rodney M. Bates" wrote: > Olaf, I think you must have a wrong version of cm3cg. I paper-traced through the first > few IR opcodes of PklFpMap.mc (as generated by my cm3 executable, fairly recently built > from the git repository) and encountered several changes to the binary opcodes, > one of which I made. Using a release 5.8 version of cm3cg, I got a similar (though > not identical) error: > > rodney at allegheny:~/proj/m3/git/cm3/m3-libs/libm3/AMD64_LINUX$ /usr/local/cm3-release/bin/cm3cg -quiet -fno-reorder-blocks -funwind-tables -fPIC -m64 -gstabs+ PklFpMap.mc -o PklFpMap.ms > cm3cg: fatal error: *** illegal type: 0x20, at m3cg_lineno 2 > compilation terminated. > > The type 0x20 and and m3cg_lineno 2 values agree with what I expect from the source code > I have for the release branch, CVS repository. That suggests you have a third version > of cm3cg. (Or maybe not the right version of cm3 front-end?) > > This is on AMD64_LINUX. OK, I'll try to check that again. Thank you very much for the help. It may take some time but I'll let you know what I find out. Weekend is over... Olaf > On 05/18/2015 11:34 AM, Rodney M. Bates wrote: > > Well, I have not been able to reproduce this on AMD64_LINUX, nor see by looking > > at code what it might be. ISTR that it is some kind of front-end/back-end > > mismatch. But the CGType codes that m3cc in trying to read have not changed > > in either the front-end nor the back-end since the release. 0x17 is well > > out of range. m3cc must be lost and trying to interpret something else as > > a type. > > > > On 05/17/2015 09:48 AM, Rodney M. Bates wrote: > >> This is a familiar error to me, but I can't remember the details right off hand. > >> I would have said it was an old m3cc, but you have built the latest one, > >> so that theory goes down the drain. I'll see what I can reconstruct. > >> > >> On 05/16/2015 06:18 PM, Olaf Wagner wrote: > >>> After several years I've just tried to setup a current cm3 on my computer > >>> again. I've cloned the repository from github/modula3/cm3, installed > >>> the latest binary archive for Darwin I could find -- which is that of > >>> the 5.8.6 release several years ago -- and tried to compile some sources. > >>> > >>> This always fails with lots of these errors: > >>> > >>> m3cc (aka cm3cg) failed compiling: PklFpMap.mc > >>> new source -> compiling FpIntTbl.m3 > >>> m3cgc1: fatal error: *** illegal type: 0x17, at m3cg_lineno 4 > >>> compilation terminated. > >>> > >>> regardless if I use the 5.8.6 backend or build a new cm3cg from > >>> sources (which actually succeeds). > >>> > >>> Any suggestions how to continue? > >>> Are newer bootstrap archives available somewhere? > >>> Any hints are appreciated. > >>> > >>> Olaf > >>> > >> > > > > -- > Rodney Bates > rodney.m.bates at acm.org -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Tue May 19 01:33:49 2015 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 19 May 2015 01:33:49 +0200 Subject: [M3devel] Bootstrapping cm3 on OS X 10.9.5 In-Reply-To: <20150518234714.dd1c111374ba3614cd74a63e@elegosoft.com> References: <20150517011824.75f096c832d5da56e4810bbf@elegosoft.com> <5558AA20.1090208@lcwb.coop> <555A14B2.7090900@lcwb.coop> <555A196E.2020106@lcwb.coop> <20150518234714.dd1c111374ba3614cd74a63e@elegosoft.com> Message-ID: <20150519013349.0ba8729443cabb394424d3cd@elegosoft.com> On Mon, 18 May 2015 23:47:14 +0200 Olaf Wagner wrote: > On Mon, 18 May 2015 11:55:10 -0500 > "Rodney M. Bates" wrote: > > > Olaf, I think you must have a wrong version of cm3cg. I paper-traced through the first > > few IR opcodes of PklFpMap.mc (as generated by my cm3 executable, fairly recently built > > from the git repository) and encountered several changes to the binary opcodes, > > one of which I made. Using a release 5.8 version of cm3cg, I got a similar (though > > not identical) error: > > > > rodney at allegheny:~/proj/m3/git/cm3/m3-libs/libm3/AMD64_LINUX$ /usr/local/cm3-release/bin/cm3cg -quiet -fno-reorder-blocks -funwind-tables -fPIC -m64 -gstabs+ PklFpMap.mc -o PklFpMap.ms > > cm3cg: fatal error: *** illegal type: 0x20, at m3cg_lineno 2 > > compilation terminated. > > > > The type 0x20 and and m3cg_lineno 2 values agree with what I expect from the source code > > I have for the release branch, CVS repository. That suggests you have a third version > > of cm3cg. (Or maybe not the right version of cm3 front-end?) > > > > This is on AMD64_LINUX. > > OK, I'll try to check that again. Thank you very much for the help. > It may take some time but I'll let you know what I find out. Weekend > is over... Couldn't let this rest though... It seems I made a really stupid mistake by installing an I386_DARWIN archive, as I have a 64 bit processor. AMD64_DARWIN should work much better, and I've even found one from March 2011. After replacing the configuration files with those from the current code base and adapting some basic system tool definitions like gcc and libtool I have now successfully compiled m3core. This looks good so far. It would have taken me much longer without your hint. But now I need some sleep, Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From rodney_bates at lcwb.coop Tue May 19 21:32:40 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Tue, 19 May 2015 14:32:40 -0500 Subject: [M3devel] New llvm backend Message-ID: <555B8FD8.2000109@lcwb.coop> I just noticed Peter's llvm backend in the github repository. I'm glad to see it. We need this. I had started some work on this too, much of it complementary. I have a version of cm3 that integrates an llvm backend, either as a separate executable, or with (some of) llvm linked in. I will work on getting that set up for Peter's main program. I also have done quite a bit of work on expanded bindings to more llvm stuff, especially for building debug info, plus a few other things that were missing from llvm's core interface. I had started a cm3-IR to llvm-IR converter, but got bogged down in making Modula-3's recursive definitions fit llvm's. The latter was not general enough for Modula-3, at least not in a direct way. I did a lot on an algorithm to wrap a minimal set of pointers, each in an artificial llvm struct, which is the only thing the llvm IR allows forward declarations for. Just when I had a pretty good draft coded, some of the llvm folks announced that the typed pointers in their IR were really unnecessary anyway, and reworked their head to have pointers with no referent type. Since that is most of what I had coded, I think it best to abandon that and adopt Peter's. I do think it would be good to have a branch for the llvm backend work. From what I have seen so far, git branches look to be pretty easy to use. -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Tue May 19 22:17:30 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Tue, 19 May 2015 15:17:30 -0500 Subject: [M3devel] Rerunning m3cggen Message-ID: <555B9A5A.2090106@lcwb.coop> What does it take to get m3cggen to be rerun? scripts/do-pkg.sh buildship m3cc doesn't appear to do it, nor does cm3 in m3-sys/m3cc. Does it need to be done manually? -- Rodney Bates rodney.m.bates at acm.org From wagner at elegosoft.com Tue May 19 23:56:09 2015 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 19 May 2015 23:56:09 +0200 Subject: [M3devel] Bootstrapping cm3 on OS X 10.9.5 In-Reply-To: <20150519013349.0ba8729443cabb394424d3cd@elegosoft.com> References: <20150517011824.75f096c832d5da56e4810bbf@elegosoft.com> <5558AA20.1090208@lcwb.coop> <555A14B2.7090900@lcwb.coop> <555A196E.2020106@lcwb.coop> <20150518234714.dd1c111374ba3614cd74a63e@elegosoft.com> <20150519013349.0ba8729443cabb394424d3cd@elegosoft.com> Message-ID: <20150519235609.41e93f178398d113bdecb79d@elegosoft.com> On Tue, 19 May 2015 01:33:49 +0200 Olaf Wagner wrote: > After replacing the configuration files with those from the current code > base and adapting some basic system tool definitions like gcc and libtool > I have now successfully compiled m3core. This looks good so far. I almost succeeded in building a new cm3 from sources now, but I'm stuck at something again I don't understand. Symbol ___eprintf is referenced from m3core, but there is no static definition for it in any library I can find. -> linking cm3 generate _m3main.new compare _m3main.new _m3main.c rm _m3main.new /usr/bin/gcc -o cm3 _m3main.o cm3unix.o Version.io M3Backend.io M3Backend.mo UtilsPosix.mo Arg.io Arg.mo Builder.io Builder.mo Dirs.io Dirs.mo M3Build.io M3Build.mo M3Loc.io M3Loc.mo M3Options.io M3Options.mo M3Unit.io M3Unit.mo Makefile.io Makefile.mo Msg.io Msg.mo Utils.io Utils.mo WebFile.io WebFile.mo Main.mo /usr/local/cm3/pkg/m3back/AMD64_DARWIN/libm3back.a /usr/local/cm3/pkg/m3objfile/AMD64_DARWIN/libm3objfile.a /usr/local/cm3/pkg/m3quake/AMD64_DARWIN/libm3quake.a /usr/local/cm3/pkg/m3front/AMD64_DARWIN/libm3front.a /usr/local/cm3/pkg/m3linker/AMD64_DARWIN/libm3link.a /usr/local/cm3/pkg/m3middle/AMD64_DARWIN/libm3middle.a /usr/local/cm3/pkg/sysutils/AMD64_DARWIN/libsysutils.a /usr/local/cm3/pkg/libm3/AMD64_DARWIN/libm3.a /usr/local/cm3/pkg/m3core/AMD64_DARWIN/libm3core.a -multiply_defined suppress -bind_at_load -shared-libgcc -dead_strip -headerpad_max_install_names Undefined symbols for architecture x86_64: "___eprintf", referenced from: _ThreadPThread__ProcessStopped in libm3core.a(ThreadApple.o) _InstallOneHandler in libm3core.a(RTSignalC.o) ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) ---- elegos-MacBook-Pro:cm3 wagner$ for f in $(find /usr/lib /usr/local/lib /opt/local/lib /usr/local/cm3/lib -name *.a); do nm $f 2>/dev/null | grep ___eprintf && echo "found in $f"; done U ___eprintf U ___eprintf found in /usr/local/cm3/lib/libm3core.a ---- elegos-MacBook-Pro:cm3 wagner$ for f in $(find /usr/lib /usr/local/lib /opt/local/lib /usr/local/cm3/lib -name *.dylib); do nm $f 2>/dev/null | grep ___eprintf && echo "found in $f"; done U ___eprintf 000141c0 t ___eprintf found in /usr/lib/lib6200Lib.dylib U ___eprintf 00019bf0 t ___eprintf found in /usr/lib/lib7225lib.dylib 00016c60 t ___eprintf U ___eprintf found in /usr/lib/lib8200Alib.dylib 00017d30 t ___eprintf U ___eprintf found in /usr/lib/lib8220lib.dylib U ___eprintf 00009a10 t ___eprintf found in /usr/lib/libAgent.dylib U ___eprintf 00018f00 t ___eprintf found in /usr/lib/libIceraDownloadLib.dylib U ___eprintf 000081bb t ___eprintf found in /usr/lib/libTinyXml.dylib 0000000000001850 t ___eprintf found in /usr/local/cm3/lib/libm3core.5.2.dylib 0000000000001850 t ___eprintf found in /usr/local/cm3/lib/libm3core.5.dylib 0000000000001850 t ___eprintf found in /usr/local/cm3/lib/libm3core.dylib ---- Does anybody know what it the standard solution for this? The symbol is even defined in the dynamic version of m3core itself. Is static linking not supported anymore? Or should I just link against one of the above dynamically? The m3makefile for cm3 still contains build_standalone () %-- we don't want to depend on the shared libraries... Any hint will be appreciated. Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Wed May 20 00:21:41 2015 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 20 May 2015 00:21:41 +0200 Subject: [M3devel] Rerunning m3cggen In-Reply-To: <555B9A5A.2090106@lcwb.coop> References: <555B9A5A.2090106@lcwb.coop> Message-ID: <20150520002141.1291106319a5d76adad4415e@elegosoft.com> On Tue, 19 May 2015 15:17:30 -0500 "Rodney M. Bates" wrote: > What does it take to get m3cggen to be rerun? scripts/do-pkg.sh buildship m3cc doesn't > appear to do it, nor does cm3 in m3-sys/m3cc. Does it need to be done manually? As long as I remember, I never automated anything that runs m3cggen. So I assume the answer should be yes. Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Wed May 20 21:01:09 2015 From: jay.krell at cornell.edu (Jay K) Date: Wed, 20 May 2015 19:01:09 +0000 Subject: [M3devel] Rerunning m3cggen In-Reply-To: <20150520002141.1291106319a5d76adad4415e@elegosoft.com> References: <555B9A5A.2090106@lcwb.coop>, <20150520002141.1291106319a5d76adad4415e@elegosoft.com> Message-ID: I think I automated it. But historically, in those other paths, it wasn't automated.Not a problem with the C backend. :) - Jay > Date: Wed, 20 May 2015 00:21:41 +0200 > From: wagner at elegosoft.com > To: rodney.m.bates at acm.org > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Rerunning m3cggen > > On Tue, 19 May 2015 15:17:30 -0500 > "Rodney M. Bates" wrote: > > > What does it take to get m3cggen to be rerun? scripts/do-pkg.sh buildship m3cc doesn't > > appear to do it, nor does cm3 in m3-sys/m3cc. Does it need to be done manually? > > As long as I remember, I never automated anything that runs m3cggen. > So I assume the answer should be yes. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed May 20 21:11:22 2015 From: jay.krell at cornell.edu (Jay K) Date: Wed, 20 May 2015 19:11:22 +0000 Subject: [M3devel] Bootstrapping cm3 on OS X 10.9.5 In-Reply-To: <20150519235609.41e93f178398d113bdecb79d@elegosoft.com> References: <20150517011824.75f096c832d5da56e4810bbf@elegosoft.com>, <5558AA20.1090208@lcwb.coop> <555A14B2.7090900@lcwb.coop>, <555A196E.2020106@lcwb.coop>, <20150518234714.dd1c111374ba3614cd74a63e@elegosoft.com>, <20150519013349.0ba8729443cabb394424d3cd@elegosoft.com>, <20150519235609.41e93f178398d113bdecb79d@elegosoft.com> Message-ID: Hi Olaf, This is surely some printf/sprint wrapper from stdio.h.Did you copy files across from some other machine or this is all one-machine?Try the C backend? I -lSystem? #include int main(){char buffer[10];printf("");sprint(buffer, "");return 0;} gcc -E 1.c gcc -S 1.c gcc 1.c gcc -v 1.c libtool a.out ? Hopefully I'll find more time here.. - Jay > Date: Tue, 19 May 2015 23:56:09 +0200 > From: wagner at elegosoft.com > To: rodney.m.bates at acm.org; m3devel at elegosoft.com > Subject: Re: [M3devel] Bootstrapping cm3 on OS X 10.9.5 > > On Tue, 19 May 2015 01:33:49 +0200 > Olaf Wagner wrote: > > > After replacing the configuration files with those from the current code > > base and adapting some basic system tool definitions like gcc and libtool > > I have now successfully compiled m3core. This looks good so far. > > I almost succeeded in building a new cm3 from sources now, but I'm > stuck at something again I don't understand. Symbol ___eprintf is > referenced from m3core, but there is no static definition for it in > any library I can find. > > -> linking cm3 > generate _m3main.new > compare _m3main.new _m3main.c > rm _m3main.new > /usr/bin/gcc -o cm3 _m3main.o cm3unix.o Version.io M3Backend.io M3Backend.mo UtilsPosix.mo Arg.io Arg.mo Builder.io Builder.mo Dirs.io Dirs.mo M3Build.io M3Build.mo M3Loc.io M3Loc.mo M3Options.io M3Options.mo M3Unit.io M3Unit.mo Makefile.io Makefile.mo Msg.io Msg.mo Utils.io Utils.mo WebFile.io WebFile.mo Main.mo /usr/local/cm3/pkg/m3back/AMD64_DARWIN/libm3back.a /usr/local/cm3/pkg/m3objfile/AMD64_DARWIN/libm3objfile.a /usr/local/cm3/pkg/m3quake/AMD64_DARWIN/libm3quake.a /usr/local/cm3/pkg/m3front/AMD64_DARWIN/libm3front.a /usr/local/cm3/pkg/m3linker/AMD64_DARWIN/libm3link.a /usr/local/cm3/pkg/m3middle/AMD64_DARWIN/libm3middle.a /usr/local/cm3/pkg/sysutils/AMD64_DARWIN/libsysutils.a /usr/local/cm3/pkg/libm3/AMD64_DARWIN/libm3.a /usr/local/cm3/pkg/m3core/AMD64_DARWIN/libm3core.a -multiply_defined suppress -bind_at_load -shared-libgcc -dead_strip -headerpad_max_install_names > Undefined symbols for architecture x86_64: > "___eprintf", referenced from: > _ThreadPThread__ProcessStopped in libm3core.a(ThreadApple.o) > _InstallOneHandler in libm3core.a(RTSignalC.o) > ld: symbol(s) not found for architecture x86_64 > clang: error: linker command failed with exit code 1 (use -v to see invocation) > > ---- > > elegos-MacBook-Pro:cm3 wagner$ for f in $(find /usr/lib /usr/local/lib /opt/local/lib /usr/local/cm3/lib -name *.a); do nm $f 2>/dev/null | grep ___eprintf && echo "found in $f"; done > U ___eprintf > U ___eprintf > found in /usr/local/cm3/lib/libm3core.a > > ---- > > elegos-MacBook-Pro:cm3 wagner$ for f in $(find /usr/lib /usr/local/lib /opt/local/lib /usr/local/cm3/lib -name *.dylib); do nm $f 2>/dev/null | grep ___eprintf && echo "found in $f"; done > U ___eprintf > 000141c0 t ___eprintf > found in /usr/lib/lib6200Lib.dylib > U ___eprintf > 00019bf0 t ___eprintf > found in /usr/lib/lib7225lib.dylib > 00016c60 t ___eprintf > U ___eprintf > found in /usr/lib/lib8200Alib.dylib > 00017d30 t ___eprintf > U ___eprintf > found in /usr/lib/lib8220lib.dylib > U ___eprintf > 00009a10 t ___eprintf > found in /usr/lib/libAgent.dylib > U ___eprintf > 00018f00 t ___eprintf > found in /usr/lib/libIceraDownloadLib.dylib > U ___eprintf > 000081bb t ___eprintf > found in /usr/lib/libTinyXml.dylib > 0000000000001850 t ___eprintf > found in /usr/local/cm3/lib/libm3core.5.2.dylib > 0000000000001850 t ___eprintf > found in /usr/local/cm3/lib/libm3core.5.dylib > 0000000000001850 t ___eprintf > found in /usr/local/cm3/lib/libm3core.dylib > > ---- > > Does anybody know what it the standard solution for this? > The symbol is even defined in the dynamic version of m3core itself. > Is static linking not supported anymore? Or should I just link > against one of the above dynamically? > The m3makefile for cm3 still contains > > build_standalone () %-- we don't want to depend on the shared libraries... > > > Any hint will be appreciated. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Wed May 20 22:12:50 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Wed, 20 May 2015 15:12:50 -0500 Subject: [M3devel] Rerunning m3cggen In-Reply-To: References: <555B9A5A.2090106@lcwb.coop>, <20150520002141.1291106319a5d76adad4415e@elegosoft.com> Message-ID: <555CEAC2.8050202@lcwb.coop> So what command(s) now take care of it? I wasn't getting it to happen, until I did it manually. On 05/20/2015 02:01 PM, Jay K wrote: > I think I automated it. But historically, in those other paths, it wasn't automated. > Not a problem with the C backend. :) > > - Jay > > > > > Date: Wed, 20 May 2015 00:21:41 +0200 > > From: wagner at elegosoft.com > > To: rodney.m.bates at acm.org > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] Rerunning m3cggen > > > > On Tue, 19 May 2015 15:17:30 -0500 > > "Rodney M. Bates" wrote: > > > > > What does it take to get m3cggen to be rerun? scripts/do-pkg.sh buildship m3cc doesn't > > > appear to do it, nor does cm3 in m3-sys/m3cc. Does it need to be done manually? > > > > As long as I remember, I never automated anything that runs m3cggen. > > So I assume the answer should be yes. > > > > Olaf > > -- > > Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > > Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -- Rodney Bates rodney.m.bates at acm.org From wagner at elegosoft.com Thu May 21 01:51:15 2015 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 21 May 2015 01:51:15 +0200 Subject: [M3devel] Bootstrapping cm3 on OS X 10.9.5 In-Reply-To: References: <20150517011824.75f096c832d5da56e4810bbf@elegosoft.com> <5558AA20.1090208@lcwb.coop> <555A14B2.7090900@lcwb.coop> <555A196E.2020106@lcwb.coop> <20150518234714.dd1c111374ba3614cd74a63e@elegosoft.com> <20150519013349.0ba8729443cabb394424d3cd@elegosoft.com> <20150519235609.41e93f178398d113bdecb79d@elegosoft.com> Message-ID: <20150521015115.1c558406fe4358c833242628@elegosoft.com> On Wed, 20 May 2015 19:11:22 +0000 Jay K wrote: > Hi Olaf, > This is surely some printf/sprint wrapper from stdio.h.Did you copy files across from some other machine or this is all one-machine?Try the C backend? I > -lSystem? > > #include int main(){char buffer[10];printf("");sprint(buffer, "");return 0;} > gcc -E 1.c gcc -S 1.c gcc 1.c gcc -v 1.c libtool a.out ? > Hopefully I'll find more time here.. Of course the binary distribution came from another machine and was several years old and had a different setup than my current computer. However, I think I had enough of an idea what was going on finally, and with much tweaking and manual intervention I was able to do a complete bootstrap. I've compiled all the packages now, and the demo programs I tried worked as expected (fisheye, Solitaire). Trying the C backend would have been my next attempt ;-) If anybody is interested in a copy of the installed system I can try to upload that somewhere in the next week. I'm not sure if there is currently a repository for packages or installation archives different from the old one on the M3 (elego) web site, which contains only packages several years old. Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Thu May 21 10:05:31 2015 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 21 May 2015 10:05:31 +0200 Subject: [M3devel] Repo access, was: Re: Bootstrapping cm3 on OS X 10.9.5 In-Reply-To: References: <20150517011824.75f096c832d5da56e4810bbf@elegosoft.com> <5558AA20.1090208@lcwb.coop> <555A14B2.7090900@lcwb.coop> <555A196E.2020106@lcwb.coop> <20150518234714.dd1c111374ba3614cd74a63e@elegosoft.com> <20150519013349.0ba8729443cabb394424d3cd@elegosoft.com> <20150519235609.41e93f178398d113bdecb79d@elegosoft.com> <20150521015115.1c558406fe4358c833242628@elegosoft.com> Message-ID: <20150521100531.8ca0c02c2553e513e480e6dc@elegosoft.com> On Wed, 20 May 2015 20:58:13 -0400 Antony Hosking wrote: > That's great! > I suppose bootstrap binaries should go on guthub? Can I get commit permissions again? I think I read somewhere that you managed that now. elegos-MacBook-Pro:cm3 wagner$ git push X11 forwarding request failed on channel 0 ERROR: Permission to modula3/cm3.git denied to olaf-wagner. fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. I'd just like to increase the compiler version number and make some minor updates to scripts. You can find me among the watchers of cm3. Olaf > Sent from my iPhone > > > On May 20, 2015, at 7:51 PM, Olaf Wagner wrote: > > > > On Wed, 20 May 2015 19:11:22 +0000 > > Jay K wrote: > > > >> Hi Olaf, > >> This is surely some printf/sprint wrapper from stdio.h.Did you copy files across from some other machine or this is all one-machine?Try the C backend? I > >> -lSystem? > >> > >> #include int main(){char buffer[10];printf("");sprint(buffer, "");return 0;} > >> gcc -E 1.c gcc -S 1.c gcc 1.c gcc -v 1.c libtool a.out ? > >> Hopefully I'll find more time here.. > > > > Of course the binary distribution came from another machine and was > > several years old and had a different setup than my current computer. > > > > However, I think I had enough of an idea what was going on finally, > > and with much tweaking and manual intervention I was able to do a > > complete bootstrap. I've compiled all the packages now, and > > the demo programs I tried worked as expected (fisheye, Solitaire). > > > > Trying the C backend would have been my next attempt ;-) > > > > If anybody is interested in a copy of the installed system I can try > > to upload that somewhere in the next week. I'm not sure if there is > > currently a repository for packages or installation archives different > > from the old one on the M3 (elego) web site, which contains only > > packages several years old. > > > > Olaf > > -- > > Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > > Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From estellnb at elstel.org Thu May 21 12:07:53 2015 From: estellnb at elstel.org (Elmar Stellnberger) Date: Thu, 21 May 2015 12:07:53 +0200 Subject: [M3devel] Bootstrapping cm3 on OS X 10.9.5 In-Reply-To: <20150521015115.1c558406fe4358c833242628@elegosoft.com> References: <20150517011824.75f096c832d5da56e4810bbf@elegosoft.com> <5558AA20.1090208@lcwb.coop> <555A14B2.7090900@lcwb.coop> <555A196E.2020106@lcwb.coop> <20150518234714.dd1c111374ba3614cd74a63e@elegosoft.com> <20150519013349.0ba8729443cabb394424d3cd@elegosoft.com> <20150519235609.41e93f178398d113bdecb79d@elegosoft.com> <20150521015115.1c558406fe4358c833242628@elegosoft.com> Message-ID: <40F30E19-16FB-4993-9712-3B67B9A624B4@elstel.org> Dear Olaf, I have Mac OS 10.7.5 here and would like to give your new binaries a try. Do the binaries include a version of Qt or will I have to install qt4/5 in addition to your binaries? It should not be a problem for me if Qt is only available to C/C++ externals. Elmar Am 21.05.2015 um 01:51 schrieb Olaf Wagner: > On Wed, 20 May 2015 19:11:22 +0000 > Jay K wrote: > >> Hi Olaf, >> This is surely some printf/sprint wrapper from stdio.h.Did you copy files across from some other machine or this is all one-machine?Try the C backend? I >> -lSystem? >> >> #include int main(){char buffer[10];printf("");sprint(buffer, "");return 0;} >> gcc -E 1.c gcc -S 1.c gcc 1.c gcc -v 1.c libtool a.out ? >> Hopefully I'll find more time here.. > > Of course the binary distribution came from another machine and was > several years old and had a different setup than my current computer. > > However, I think I had enough of an idea what was going on finally, > and with much tweaking and manual intervention I was able to do a > complete bootstrap. I've compiled all the packages now, and > the demo programs I tried worked as expected (fisheye, Solitaire). > > Trying the C backend would have been my next attempt ;-) > > If anybody is interested in a copy of the installed system I can try > to upload that somewhere in the next week. I'm not sure if there is > currently a repository for packages or installation archives different > from the old one on the M3 (elego) web site, which contains only > packages several years old. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From wagner at elegosoft.com Thu May 21 17:50:16 2015 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 21 May 2015 17:50:16 +0200 Subject: [M3devel] Qt bindings, was: Re: Bootstrapping cm3 on OS X 10.9.5 In-Reply-To: <40F30E19-16FB-4993-9712-3B67B9A624B4@elstel.org> References: <20150517011824.75f096c832d5da56e4810bbf@elegosoft.com> <5558AA20.1090208@lcwb.coop> <555A14B2.7090900@lcwb.coop> <555A196E.2020106@lcwb.coop> <20150518234714.dd1c111374ba3614cd74a63e@elegosoft.com> <20150519013349.0ba8729443cabb394424d3cd@elegosoft.com> <20150519235609.41e93f178398d113bdecb79d@elegosoft.com> <20150521015115.1c558406fe4358c833242628@elegosoft.com> <40F30E19-16FB-4993-9712-3B67B9A624B4@elstel.org> Message-ID: <20150521175016.a551cb784f3bed67aa833835@elegosoft.com> On Thu, 21 May 2015 12:07:53 +0200 Elmar Stellnberger wrote: > Dear Olaf, > > I have Mac OS 10.7.5 here and would like to give your new binaries a try. > Do the binaries include a version of Qt or will I have to install qt4/5 in addition to your binaries? > It should not be a problem for me if Qt is only available to C/C++ externals. I just gave that a try. QtEventLoopRaw.m3 cannot be found: === package m3-ui/qt/m3qtcore === +++ cm3 -build -override $RARGS -DROOT='/Users/wagner/work/cm3' +++ --- building in AMD64_DARWIN --- unable to read ../src/m3overrides, options "-override" and "-x" ignored. compiling ../src/dynamicqobject.cxx compiling ../src/QtNamespace_wrap.cxx compiling ../src/QtDynamic_wrap.cxx ../src/QtDynamic_wrap.cxx:164:3: warning: delete called on 'AbstractDynamicSlot' that is abstract but has non-virtual destructor [-Wdelete-non-virtual-dtor] delete arg1; ^ 1 warning generated. compiling ../src/QtCoreApplication_wrap.cxx compiling ../src/QtByteArray_wrap.cxx compiling ../src/QtString_wrap.cxx compiling ../src/QtList_wrap.cxx compiling ../src/QtStringList_wrap.cxx compiling ../src/QtEventLoop_wrap.cxx compiling ../src/QtEvent_wrap.cxx ../src/QtEvent_wrap.cxx:376:23: warning: 'QDynamicPropertyChangeEvent_propertyName' has C-linkage specified, but returns user-defined type 'QByteArray' which is incompatible with C [-Wreturn-type-c-linkage] SWIGEXPORT QByteArray QDynamicPropertyChangeEvent_propertyName(QDynamicPropertyChangeEvent const * self) { ^ 1 warning generated. compiling ../src/QtObject_wrap.cxx compiling ../src/QtPoint_wrap.cxx ../src/QtPoint_wrap.cxx:472:21: warning: 'QPointF_rx' has C-linkage specified, but returns user-defined type 'double &' which is incompatible with C [-Wreturn-type-c-linkage] SWIGEXPORT double & QPointF_rx(QPointF * self) { ^ ../src/QtPoint_wrap.cxx:484:21: warning: 'QPointF_ry' has C-linkage specified, but returns user-defined type 'double &' which is incompatible with C [-Wreturn-type-c-linkage] SWIGEXPORT double & QPointF_ry(QPointF * self) { ^ 2 warnings generated. compiling ../src/QtLine_wrap.cxx compiling ../src/QtSize_wrap.cxx ../src/QtSize_wrap.cxx:584:21: warning: 'QSizeF_rwidth' has C-linkage specified, but returns user-defined type 'double &' which is incompatible with C [-Wreturn-type-c-linkage] SWIGEXPORT double & QSizeF_rwidth(QSizeF * self) { ^ ../src/QtSize_wrap.cxx:596:21: warning: 'QSizeF_rheight' has C-linkage specified, but returns user-defined type 'double &' which is incompatible with C [-Wreturn-type-c-linkage] SWIGEXPORT double & QSizeF_rheight(QSizeF * self) { ^ 2 warnings generated. compiling ../src/QtRect_wrap.cxx compiling ../src/QtDateTime_wrap.cxx compiling ../src/QtMargins_wrap.cxx compiling ../src/QtAbstractItemModel_wrap.cxx ../src/QtAbstractItemModel_wrap.cxx:266:26: warning: 'QModelIndex_flags' has C-linkage specified, but returns user-defined type 'Qt::ItemFlags' (aka 'QFlags') which is incompatible with C [-Wreturn-type-c-linkage] SWIGEXPORT Qt::ItemFlags QModelIndex_flags(QModelIndex const * self) { ^ ../src/QtAbstractItemModel_wrap.cxx:416:26: warning: 'QPersistentModelIndex_flags' has C-linkage specified, but returns user-defined type 'Qt::ItemFlags' (aka 'QFlags') which is incompatible with C [-Wreturn-type-c-linkage] SWIGEXPORT Qt::ItemFlags QPersistentModelIndex_flags(QPersistentModelIndex const * self) { ^ ../src/QtAbstractItemModel_wrap.cxx:652:28: warning: 'QAbstractItemModel_supportedDropActions' has C-linkage specified, but returns user-defined type 'Qt::DropActions' (aka 'QFlags') which is incompatible with C [-Wreturn-type-c-linkage] SWIGEXPORT Qt::DropActions QAbstractItemModel_supportedDropActions(QAbstractItemModel * self) { ^ ../src/QtAbstractItemModel_wrap.cxx:662:28: warning: 'QAbstractItemModel_supportedDragActions' has C-linkage specified, but returns user-defined type 'Qt::DropActions' (aka 'QFlags') which is incompatible with C [-Wreturn-type-c-linkage] SWIGEXPORT Qt::DropActions QAbstractItemModel_supportedDragActions(QAbstractItemModel * self) { ^ ../src/QtAbstractItemModel_wrap.cxx:962:26: warning: 'QAbstractItemModel_flags' has C-linkage specified, but returns user-defined type 'Qt::ItemFlags' (aka 'QFlags') which is incompatible with C [-Wreturn-type-c-linkage] SWIGEXPORT Qt::ItemFlags QAbstractItemModel_flags(QAbstractItemModel * self, QModelIndex const & index) { ^ 5 warnings generated. unable to open file for reading: ../src/QtEventLoopRaw.m3: errno=2 open failed on: ../src/QtEventLoopRaw.m3 Fatal Error: failed compiling: *** execution of cm3 -build -override $RARGS -DROOT='/Users/wagner/work/cm3' failed *** elegos-MacBook-Pro:cm3 wagner$ find m3-ui -name '*EventLoop*' -print m3-ui/qt/m3qtcore/AMD64_DARWIN/QtEventLoop.io m3-ui/qt/m3qtcore/AMD64_DARWIN/QtEventLoop_wrap.o m3-ui/qt/m3qtcore/AMD64_DARWIN/QtEventLoopRaw.io m3-ui/qt/m3qtcore/src/QtEventLoop.i3 m3-ui/qt/m3qtcore/src/QtEventLoop.m3 m3-ui/qt/m3qtcore/src/QtEventLoop_wrap.cxx m3-ui/qt/m3qtcore/src/QtEventLoop_wrap.o m3-ui/qt/m3qtcore/src/QtEventLoopRaw.i3 m3-ui/qt/m3qtcore/src/swig/QtEventLoop.i The warnings seem to indicate that there may be more problems. I installed qt 4.8.6 via brew: elegos-MacBook-Pro:cm3 wagner$ brew install qt ==> Downloading https://downloads.sf.net/project/machomebrew/Bottles/qt-4.8.6.mavericks.bottle.6.tar.gz ######################################################################## 100.0% ==> Pouring qt-4.8.6.mavericks.bottle.6.tar.gz ==> Caveats We agreed to the Qt opensource license for you. If this is unacceptable you should uninstall. .app bundles were installed. Run `brew linkapps` to symlink these to /Applications. ==> Summary /usr/local/Cellar/qt/4.8.6: 2790 files, 122M Any advice what I did wrong? Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From rodney_bates at lcwb.coop Thu May 21 18:57:07 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 21 May 2015 11:57:07 -0500 Subject: [M3devel] LLVM version and patches thereto Message-ID: <555E0E63.6070506@lcwb.coop> Peter, what version of llvm are you using? Also, can you tell us what the patches you have made to it are? Have you sent these to the llvm developers to incorporate? I can guess one is to tolerate DW_LANG_Modula3. -- Rodney Bates rodney.m.bates at acm.org From hendrik at topoi.pooq.com Thu May 21 18:56:00 2015 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Thu, 21 May 2015 12:56:00 -0400 Subject: [M3devel] Bootstrapping cm3 on OS X 10.9.5 In-Reply-To: <40F30E19-16FB-4993-9712-3B67B9A624B4@elstel.org> References: <20150517011824.75f096c832d5da56e4810bbf@elegosoft.com> <5558AA20.1090208@lcwb.coop> <555A14B2.7090900@lcwb.coop> <555A196E.2020106@lcwb.coop> <20150518234714.dd1c111374ba3614cd74a63e@elegosoft.com> <20150519013349.0ba8729443cabb394424d3cd@elegosoft.com> <20150519235609.41e93f178398d113bdecb79d@elegosoft.com> <20150521015115.1c558406fe4358c833242628@elegosoft.com> <40F30E19-16FB-4993-9712-3B67B9A624B4@elstel.org> Message-ID: <20150521165600.GA13058@topoi.pooq.com> On Thu, May 21, 2015 at 12:07:53PM +0200, Elmar Stellnberger wrote: > Dear Olaf, > > I have Mac OS 10.7.5 here and would like to give your new binaries a try. > Do the binaries include a version of Qt or will I have to install qt4/5 in addition to your binaries? > It should not be a problem for me if Qt is only available to C/C++ externals. Live and learn! I didn't know there *was* a Qt binding for Modula 3. I could sure use it. What interfaces and modules provide it? -- hendrik From rodney_bates at lcwb.coop Thu May 21 19:24:12 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 21 May 2015 12:24:12 -0500 Subject: [M3devel] How to integrate llvm into cm3 Message-ID: <555E14BC.2040805@lcwb.coop> I previously made significant changes to cm3 and related, to drive an llvm backend and have them in a branch. I added 4 new backend modes. IntLlvmObj and IntLlvmAsm are "internal", meaning a complete llvm-derived back end is linked in with cm3, similar to the x86 internal backend, found in m3back. Obj/Asm is whether it produces object modules or assembly code. (I did not set out to use these, just put them in for completeness.) ExtLlvmObj and ExtLlvmAsm are for "external". In these, a separate executable llvm backend is used (llc) that reads llvm bitcode, generated by cm3. The code to produce the llvm-IR is in a package m3llvmgen. It links in some amount of llvm infrastructure to build llvm IR in-memory trees, then write them to llvm bitcode. Peter's cm3-IR to llvm-IR conversion is a separately compiled executable, which differs from both the above organizations. It relys on cm3's existing ability to write cm3-IR to a file in binary form. It reads this (either binary or text form, with a small code change) and produces llvm bitcode files. So, do we have any preference about how to do this. Code changes to either read cm3-IR from a binary file, a text file, or get it directly inside the cm3 executable are nearly trivial. Just substitute a different subtype of M3CG.T. to supply the cm3-IR operator stream. Cm3 changes would be a bit bigger to drive the separate executable pass. There are pros and cons. Integrating Peter's cm3-to-llvm conversion into the cm3 executable would be faster compiling--one fewer time per interface or module for the OS to create a process and run an executable. But it would also entail linking in this code, along with some of llvm's infrastructure, into cm3, making its executable bigger, with code that might not be executed at all, when a different backend is used. We already have the x86 integrated backend and the C backend linked in to cm3, whether used or not. Anybody have thoughts on this? I suppose it could be set up to be fairly easily changed either way too. -- Rodney Bates rodney.m.bates at acm.org From estellnb at elstel.org Thu May 21 20:13:18 2015 From: estellnb at elstel.org (Elmar Stellnberger) Date: Thu, 21 May 2015 20:13:18 +0200 Subject: [M3devel] How to integrate llvm into cm3 In-Reply-To: <555E14BC.2040805@lcwb.coop> References: <555E14BC.2040805@lcwb.coop> Message-ID: <555E203E.4040203@elstel.org> Am 21.05.15 um 19:24 schrieb Rodney M. Bates: > > There are pros and cons. Integrating Peter's cm3-to-llvm conversion into > the cm3 executable would be faster compiling--one fewer time per > interface > or module for the OS to create a process and run an executable. But it > would also entail linking in this code, along with some of llvm's > infrastructure, > into cm3, making its executable bigger, with code that might not be > executed > at all, when a different backend is used. We already have the x86 > integrated > backend and the C backend linked in to cm3, whether used or not. > > Anybody have thoughts on this? I suppose it could be set up to be fairly > easily changed either way too. > Why not put each backend into a shared library and load it dynamically? Are there still problems with shared libraries for some build targets? On the other hand having cm3-IR handy and being able to translate cm3-IR by an executable like m3cc into any desired target has proven to be very handy for debugging as well as chocking the Modula-3 compiler on a new platform. My personal preference would be to only have one default target statically compiled in namely that on for cm3-IR and load all other targets by a shared libarary dynamically. If that should fail for some reason one can still use m3cc or one of its counterparts to accomplish the translation process. Elmar From peter.mckinna at gmail.com Fri May 22 00:09:28 2015 From: peter.mckinna at gmail.com (Peter McKinna) Date: Fri, 22 May 2015 08:09:28 +1000 Subject: [M3devel] LLVM version and patches thereto In-Reply-To: <555E0E63.6070506@lcwb.coop> References: <555E0E63.6070506@lcwb.coop> Message-ID: Hi Rodney, Good to see this stuff moving forward. I had no idea how to integrate it with the front end. I'm using llvm 3.5 . I downloaded 3.6 and built it but then could not get some dibuilder bindings I had added to compile, some sort of problem with the wrap function which I have yet to sort out. I think they made a change to the way metadata is treated. Anyway I have attached the 2 sets of bindings I have been using. I have to commit a few bug fixes and my initial attempt at debug support. Speaking of debugging, I was following what I think clang uses which is the dibuilder class . So far its very primitive and could probably be split into its own module. I managed to get simple scalars, enumerations, arrays and records to be debugged with stock gdb and none of the name mangling I usually get. But globals, objects and sets dont work. I think this needs an expert and mybe a chat with the llvm people, they seem pretty helpful. Anyway it runs the maze program, I compiled the collector the other day, 15,000 lines of llvm ir. The code quality looks pretty good from a brief inspection of the assembly thats compiled at O3 although O2 doesnt make much difference. I read in tips for programmers somewhere that pascal like languages with lots of runtime checks should be running some extra passes for better optimisation. We could look at that in the future. Regards Peter On Fri, May 22, 2015 at 2:57 AM, Rodney M. Bates wrote: > Peter, what version of llvm are you using? Also, can you tell us what the > patches > you have made to it are? Have you sent these to the llvm developers to > incorporate? > I can guess one is to tolerate DW_LANG_Modula3. > > > -- > Rodney Bates > rodney.m.bates at acm.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: M3Extras.h Type: text/x-chdr Size: 838 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DIBuilderBindings.h Type: text/x-chdr Size: 6034 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: M3Extras.cpp Type: text/x-c++src Size: 2354 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DIBuilderBindings.cpp Type: text/x-c++src Size: 11648 bytes Desc: not available URL: From jay.krell at cornell.edu Fri May 22 02:57:07 2015 From: jay.krell at cornell.edu (Jay K) Date: Fri, 22 May 2015 00:57:07 +0000 Subject: [M3devel] How to integrate llvm into cm3 In-Reply-To: <555E203E.4040203@elstel.org> References: <555E14BC.2040805@lcwb.coop>,<555E203E.4040203@elstel.org> Message-ID: Imho "all" options should be implemented, for purposes of convenient debugging/development of the backends. "external" is good for developing backends. You can "snapshot" the state of things slightly into the pipeline and then just iterate on later parts. At the cost of having all the serialization code. "integrated" is usually preferable for performance, for users. E.g. NTx86 backend has been sitting in there for decades unused by half the users. Having extra backends sitting in there unused is ok. Ideally, agreed, they'd be .dll/.sos if we can construct it that way, but ok either way imho. Ideally also cm3 would dynamically link to libm3/m3core, but it doesn't. Everything is demand paged so there is cost to distribute over the network and copy around, but at runtime, the pages just sit mostly cold on disk. One difficulty though is the need to have and build the LLVM code. For that reason, delayload-dynamically-linked might be preferable. It depends on how small/easy-to-build LLVM is. I guess LLVM provides more choices than before. In order of efficiency and inverse order of debuggability: 1 We could construct LLVM IR in memory and run LLVM in-proc and write .o. 2 We could write out LLVM bytes and run an executable. 3 We could write out LLVM text and run an executable. > My personal preference would be to only have one default target statically compiled in It has never worked that away. Granted, we didn't really have backends before, just writing mainly IR. And I don't think LLVM works that way, does it? I like one compiler to have all targets and just select with a command line switch. I don't like how hard it is to acquire various cross-toolschains. Granted, we cheat and are incomplete -- you still need the next piece of the pipeline, be it LLVM or m3cc (which has one target), or a C compiler or assembler or linker or "libc.a". binutils at least has this "all" notion reasonably well working now I believe. There are tradeoffs though. If only one backend has a bug, and they are all statically linked together, you have to update them all.And the largely wasted bloat. Ultimately really, I'd like the C backend to output portable C and then just one C backend, one distribution .tar.gz for all targets.There is work to do there..not easy..and no progress lately.Things like INTEGER preserving flexibility in the output, and using sizeof(INTEGER) in expressions instead of using 4 or 8 and folding... - Jay > Date: Thu, 21 May 2015 20:13:18 +0200 > From: estellnb at elstel.org > To: rodney.m.bates at acm.org; m3devel at elegosoft.com > Subject: Re: [M3devel] How to integrate llvm into cm3 > > Am 21.05.15 um 19:24 schrieb Rodney M. Bates: > > > > There are pros and cons. Integrating Peter's cm3-to-llvm conversion into > > the cm3 executable would be faster compiling--one fewer time per > > interface > > or module for the OS to create a process and run an executable. But it > > would also entail linking in this code, along with some of llvm's > > infrastructure, > > into cm3, making its executable bigger, with code that might not be > > executed > > at all, when a different backend is used. We already have the x86 > > integrated > > backend and the C backend linked in to cm3, whether used or not. > > > > Anybody have thoughts on this? I suppose it could be set up to be fairly > > easily changed either way too. > > > > Why not put each backend into a shared library and load it dynamically? > Are there still problems with shared libraries for some build targets? > On the other hand having cm3-IR handy and being able to translate > cm3-IR by an executable like m3cc into any desired target has proven > to be very handy for debugging as well as chocking the Modula-3 > compiler on a new platform. > My personal preference would be to only have one default target > statically compiled in namely that on for cm3-IR and load all other > targets by a shared libarary dynamically. If that should fail for some > reason one can still use m3cc or one of its counterparts to > accomplish the translation process. > > Elmar > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.mckinna at gmail.com Fri May 22 05:01:25 2015 From: peter.mckinna at gmail.com (Peter McKinna) Date: Fri, 22 May 2015 13:01:25 +1000 Subject: [M3devel] How to integrate llvm into cm3 In-Reply-To: References: <555E14BC.2040805@lcwb.coop> <555E203E.4040203@elstel.org> Message-ID: I followed the m3cc design mainly because I didnt want to include the llvm libs in the link for cm3. It is a c++ lib set and requires the c++ linker which if you have ever built llvm or clang leaves you wondering about that linker. I was watching it link an llvm lib once and it took over 19 seconds. In fact watching the llvm build is like watching grass grow, it takes over 2 hours on my humble laptop (core i3). They estimate about 40 minutes on a "fast" machine. I digress. If llvm or other library is statically linked into cm3 and its not part of the standard toolchain then we would have to ship the those libs woudnt we? We dont have the package mechanism like debian and others which will drag in dependant libraries. At the moment we ship the sources and say build this with what youve got installed. Peter On Fri, May 22, 2015 at 10:57 AM, Jay K wrote: > Imho "all" options should be implemented, for purposes of convenient > debugging/development of the backends. > > > "external" is good for developing backends. You can "snapshot" the state > of things > slightly into the pipeline and then just iterate on later parts. > > > At the cost of having all the serialization code. > > > "integrated" is usually preferable for performance, for users. > > > E.g. NTx86 backend has been sitting in there for decades unused by half > the users. > > > Having extra backends sitting in there unused is ok. > Ideally, agreed, they'd be .dll/.sos if we can construct it that way, but > ok either way imho. > Ideally also cm3 would dynamically link to libm3/m3core, but it doesn't. > > > Everything is demand paged so there is cost to distribute over the network > and copy around, but at runtime, the pages just sit mostly cold on disk. > > > One difficulty though is the need to have and build the LLVM code. > For that reason, delayload-dynamically-linked might be preferable. > It depends on how small/easy-to-build LLVM is. > > > I guess LLVM provides more choices than before. > In order of efficiency and inverse order of debuggability: > 1 We could construct LLVM IR in memory and run LLVM in-proc and write > .o. > 2 We could write out LLVM bytes and run an executable. > 3 We could write out LLVM text and run an executable. > > > > My personal preference would be to only have one default target > statically compiled in > > It has never worked that away. Granted, we didn't really have backends > before, just writing mainly IR. > And I don't think LLVM works that way, does it? > > I like one compiler to have all targets and just select with a command > line switch. > > I don't like how hard it is to acquire various cross-toolschains. > Granted, we cheat and are incomplete -- you still need the next piece of > the pipeline, > be it LLVM or m3cc (which has one target), or a C compiler or assembler > or linker or "libc.a". > > > binutils at least has this "all" notion reasonably well working now I > believe. > > > > There are tradeoffs though. If only one backend has a bug, and they are > all statically linked together, you have to update them all. > And the largely wasted bloat. > > > Ultimately really, I'd like the C backend to output portable C and then > just one C backend, one distribution .tar.gz for all targets. > There is work to do there..not easy..and no progress lately. > Things like INTEGER preserving flexibility in the output, and using > sizeof(INTEGER) in expressions instead of using 4 or 8 and folding... > > > > - Jay > > > > > > Date: Thu, 21 May 2015 20:13:18 +0200 > > From: estellnb at elstel.org > > To: rodney.m.bates at acm.org; m3devel at elegosoft.com > > Subject: Re: [M3devel] How to integrate llvm into cm3 > > > > > Am 21.05.15 um 19:24 schrieb Rodney M. Bates: > > > > > > There are pros and cons. Integrating Peter's cm3-to-llvm conversion > into > > > the cm3 executable would be faster compiling--one fewer time per > > > interface > > > or module for the OS to create a process and run an executable. But it > > > would also entail linking in this code, along with some of llvm's > > > infrastructure, > > > into cm3, making its executable bigger, with code that might not be > > > executed > > > at all, when a different backend is used. We already have the x86 > > > integrated > > > backend and the C backend linked in to cm3, whether used or not. > > > > > > Anybody have thoughts on this? I suppose it could be set up to be > fairly > > > easily changed either way too. > > > > > > > Why not put each backend into a shared library and load it dynamically? > > Are there still problems with shared libraries for some build targets? > > On the other hand having cm3-IR handy and being able to translate > > cm3-IR by an executable like m3cc into any desired target has proven > > to be very handy for debugging as well as chocking the Modula-3 > > compiler on a new platform. > > My personal preference would be to only have one default target > > statically compiled in namely that on for cm3-IR and load all other > > targets by a shared libarary dynamically. If that should fail for some > > reason one can still use m3cc or one of its counterparts to > > accomplish the translation process. > > > > Elmar > > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmuysers at hotmail.com Fri May 22 10:48:36 2015 From: dmuysers at hotmail.com (dirk muysers) Date: Fri, 22 May 2015 10:48:36 +0200 Subject: [M3devel] How to integrate llvm into cm3 In-Reply-To: References: <555E14BC.2040805@lcwb.coop>, <555E203E.4040203@elstel.org> Message-ID: Personally I have a strong dislike towards LLVM. 1. You first have to compile the whole tool chain. 2. It is a monstrous blob of code, mainly on Windows. 3. Contrary to a widespread belief, It is definitely NOT platform independent. 4. It changes at every release. 5. Having built your objects, you still have to run them through a platform assembler-linker. If I still had the energy of my younger years I would try to pack the platform dependent part of the libraries into a dynamic load library together with a JIT translator (e.g. libjit) for the portable application code and have a single byte-code producing compiler backend. From: Jay K Sent: Friday, May 22, 2015 2:57 AM To: Elmar Stellnberger ; rodney.m.bates at acm.org ; m3devel Subject: Re: [M3devel] How to integrate llvm into cm3 Imho "all" options should be implemented, for purposes of convenient debugging/development of the backends. "external" is good for developing backends. You can "snapshot" the state of things slightly into the pipeline and then just iterate on later parts. At the cost of having all the serialization code. "integrated" is usually preferable for performance, for users. E.g. NTx86 backend has been sitting in there for decades unused by half the users. Having extra backends sitting in there unused is ok. Ideally, agreed, they'd be .dll/.sos if we can construct it that way, but ok either way imho. Ideally also cm3 would dynamically link to libm3/m3core, but it doesn't. Everything is demand paged so there is cost to distribute over the network and copy around, but at runtime, the pages just sit mostly cold on disk. One difficulty though is the need to have and build the LLVM code. For that reason, delayload-dynamically-linked might be preferable. It depends on how small/easy-to-build LLVM is. I guess LLVM provides more choices than before. In order of efficiency and inverse order of debuggability: 1 We could construct LLVM IR in memory and run LLVM in-proc and write .o. 2 We could write out LLVM bytes and run an executable. 3 We could write out LLVM text and run an executable. > My personal preference would be to only have one default target statically compiled in It has never worked that away. Granted, we didn't really have backends before, just writing mainly IR. And I don't think LLVM works that way, does it? I like one compiler to have all targets and just select with a command line switch. I don't like how hard it is to acquire various cross-toolschains. Granted, we cheat and are incomplete -- you still need the next piece of the pipeline, be it LLVM or m3cc (which has one target), or a C compiler or assembler or linker or "libc.a". binutils at least has this "all" notion reasonably well working now I believe. There are tradeoffs though. If only one backend has a bug, and they are all statically linked together, you have to update them all. And the largely wasted bloat. Ultimately really, I'd like the C backend to output portable C and then just one C backend, one distribution .tar.gz for all targets. There is work to do there..not easy..and no progress lately. Things like INTEGER preserving flexibility in the output, and using sizeof(INTEGER) in expressions instead of using 4 or 8 and folding... - Jay > Date: Thu, 21 May 2015 20:13:18 +0200 > From: estellnb at elstel.org > To: rodney.m.bates at acm.org; m3devel at elegosoft.com > Subject: Re: [M3devel] How to integrate llvm into cm3 > > Am 21.05.15 um 19:24 schrieb Rodney M. Bates: > > > > There are pros and cons. Integrating Peter's cm3-to-llvm conversion into > > the cm3 executable would be faster compiling--one fewer time per > > interface > > or module for the OS to create a process and run an executable. But it > > would also entail linking in this code, along with some of llvm's > > infrastructure, > > into cm3, making its executable bigger, with code that might not be > > executed > > at all, when a different backend is used. We already have the x86 > > integrated > > backend and the C backend linked in to cm3, whether used or not. > > > > Anybody have thoughts on this? I suppose it could be set up to be fairly > > easily changed either way too. > > > > Why not put each backend into a shared library and load it dynamically? > Are there still problems with shared libraries for some build targets? > On the other hand having cm3-IR handy and being able to translate > cm3-IR by an executable like m3cc into any desired target has proven > to be very handy for debugging as well as chocking the Modula-3 > compiler on a new platform. > My personal preference would be to only have one default target > statically compiled in namely that on for cm3-IR and load all other > targets by a shared libarary dynamically. If that should fail for some > reason one can still use m3cc or one of its counterparts to > accomplish the translation process. > > Elmar > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From estellnb at elstel.org Fri May 22 11:50:38 2015 From: estellnb at elstel.org (Elmar Stellnberger) Date: Fri, 22 May 2015 11:50:38 +0200 Subject: [M3devel] How to integrate llvm into cm3 In-Reply-To: References: <555E14BC.2040805@lcwb.coop>, <555E203E.4040203@elstel.org> Message-ID: <780C53B1-C9EA-479C-86EA-82D4670879DC@elstel.org> Am 22.05.2015 um 10:48 schrieb dirk muysers: > Personally I have a strong dislike towards LLVM. > 1. You first have to compile the whole tool chain. > 2. It is a monstrous blob of code, mainly on Windows. > 3. Contrary to a widespread belief, It is definitely NOT platform independent. > 4. It changes at every release. > 5. Having built your objects, you still have to run them through a platform assembler-linker. Is it really that bad? What about the said platform dependencies you have discovered? I believe llvm could be beneficial in deed when it comes to debugging and/or analyzing Modula-3 programs, as there are tools like SAFECode and to my knowledge we never had a fully featured m3gdb. Besides this I would hardly like to believe that llvm is still that volatile when it comes to changes. I know it had some issues in its first days but I can hardly believe that qt5 on MacOS would rely on clang/llvm if that were not a ready to use technology nowadays. I would hope the main changes to llvm had already been done when Apple started to adopt llvm for its own needs. Concerning the code size of llvm that should not be a problem as long as it remains a separate module compiling into an own executable or a shared library loaded in addition to other backends at runtime. > > If I still had the energy of my younger years I would try to pack the platform > dependent part of the libraries into a dynamic load library together with a JIT > translator (e.g. libjit) for the portable application code and have a single byte-code > producing compiler backend. > > From: Jay K > Sent: Friday, May 22, 2015 2:57 AM > To: Elmar Stellnberger ; rodney.m.bates at acm.org ; m3devel > Subject: Re: [M3devel] How to integrate llvm into cm3 > > Imho "all" options should be implemented, for purposes of convenient debugging/development of the backends. > > > "external" is good for developing backends. You can "snapshot" the state of things > slightly into the pipeline and then just iterate on later parts. > > > At the cost of having all the serialization code. > > > "integrated" is usually preferable for performance, for users. > > > E.g. NTx86 backend has been sitting in there for decades unused by half the users. > > > Having extra backends sitting in there unused is ok. > Ideally, agreed, they'd be .dll/.sos if we can construct it that way, but ok either way imho. > Ideally also cm3 would dynamically link to libm3/m3core, but it doesn't. > > > Everything is demand paged so there is cost to distribute over the network > and copy around, but at runtime, the pages just sit mostly cold on disk. > > > One difficulty though is the need to have and build the LLVM code. > For that reason, delayload-dynamically-linked might be preferable. > It depends on how small/easy-to-build LLVM is. > > > I guess LLVM provides more choices than before. > In order of efficiency and inverse order of debuggability: > 1 We could construct LLVM IR in memory and run LLVM in-proc and write .o. > 2 We could write out LLVM bytes and run an executable. > 3 We could write out LLVM text and run an executable. > > > > My personal preference would be to only have one default target statically compiled in > > It has never worked that away. Granted, we didn't really have backends before, just writing mainly IR. > And I don't think LLVM works that way, does it? > > I like one compiler to have all targets and just select with a command line switch. > > I don't like how hard it is to acquire various cross-toolschains. > Granted, we cheat and are incomplete -- you still need the next piece of the pipeline, > be it LLVM or m3cc (which has one target), or a C compiler or assembler or linker or "libc.a". > > > binutils at least has this "all" notion reasonably well working now I believe. > > > > There are tradeoffs though. If only one backend has a bug, and they are all statically linked together, you have to update them all. > And the largely wasted bloat. > > > Ultimately really, I'd like the C backend to output portable C and then just one C backend, one distribution .tar.gz for all targets. > There is work to do there..not easy..and no progress lately. > Things like INTEGER preserving flexibility in the output, and using sizeof(INTEGER) in expressions instead of using 4 or 8 and folding... > > > > - Jay > > > > > > Date: Thu, 21 May 2015 20:13:18 +0200 > > From: estellnb at elstel.org > > To: rodney.m.bates at acm.org; m3devel at elegosoft.com > > Subject: Re: [M3devel] How to integrate llvm into cm3 > > > > Am 21.05.15 um 19:24 schrieb Rodney M. Bates: > > > > > > There are pros and cons. Integrating Peter's cm3-to-llvm conversion into > > > the cm3 executable would be faster compiling--one fewer time per > > > interface > > > or module for the OS to create a process and run an executable. But it > > > would also entail linking in this code, along with some of llvm's > > > infrastructure, > > > into cm3, making its executable bigger, with code that might not be > > > executed > > > at all, when a different backend is used. We already have the x86 > > > integrated > > > backend and the C backend linked in to cm3, whether used or not. > > > > > > Anybody have thoughts on this? I suppose it could be set up to be fairly > > > easily changed either way too. > > > > > > > Why not put each backend into a shared library and load it dynamically? > > Are there still problems with shared libraries for some build targets? > > On the other hand having cm3-IR handy and being able to translate > > cm3-IR by an executable like m3cc into any desired target has proven > > to be very handy for debugging as well as chocking the Modula-3 > > compiler on a new platform. > > My personal preference would be to only have one default target > > statically compiled in namely that on for cm3-IR and load all other > > targets by a shared libarary dynamically. If that should fail for some > > reason one can still use m3cc or one of its counterparts to > > accomplish the translation process. > > > > Elmar > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmuysers at hotmail.com Fri May 22 12:16:21 2015 From: dmuysers at hotmail.com (dirk muysers) Date: Fri, 22 May 2015 12:16:21 +0200 Subject: [M3devel] How to integrate llvm into cm3 In-Reply-To: <0A1CDD8C-EEB5-40E2-A38B-28E8EEA8C37E@elstel.org> References: <555E14BC.2040805@lcwb.coop>, <555E203E.4040203@elstel.org> <0A1CDD8C-EEB5-40E2-A38B-28E8EEA8C37E@elstel.org> Message-ID: >> What about the said platform dependencies you have discovered? Not me (I never seriously considered using it), but many people on the llvm forums pointed to the fact. One example among many: Does your C code ever use the 'long' type? If so, the LLVM IR will be different depending on whether it's targeting linux-32 or linux-64. Do you ever use size_t? Same problem. Do you ever use a union containing both pointers and integers? See above. In principle, it's possible to write platform-independent IR, or even C code that compiles to platform-independent IR. In practice, especially if you include any system headers, it's remarkably hard. (Jeffrey Yasskin jyasskin at google.com) And then, besides the IR proper, there is that steadily increasing legion of intrinsics. Unless you translate C-like code and build upon the existing technical LLVM heritage, je vous souhaite bien du plaisir as the French say... From: Elmar Stellnberger Sent: Friday, May 22, 2015 11:49 AM To: dirk muysers Subject: Re: [M3devel] How to integrate llvm into cm3 Am 22.05.2015 um 10:48 schrieb dirk muysers: Personally I have a strong dislike towards LLVM. 1. You first have to compile the whole tool chain. 2. It is a monstrous blob of code, mainly on Windows. 3. Contrary to a widespread belief, It is definitely NOT platform independent. 4. It changes at every release. 5. Having built your objects, you still have to run them through a platform assembler-linker. Is it really that bad? What about the said platform dependencies you have discovered? I believe llvm could be beneficial in deed when it comes to debugging and/or analyzing Modula-3 programs, as there are tools like SAFECode and to my knowledge we never had a fully featured m3gdb. Besides this I would hardly like to believe that llvm is still that volatile when it comes to changes. I know it had some issues in its first days but I can hardly believe that qt5 on MacOS would rely on clang/llvm if that were not a ready to use technology nowadays. I would hope the main changes to llvm had already been done when Apple started to adopt llvm for its own needs. Concerning the code size of llvm that should not be a problem as long as it remains a separate module compiling into an own executable or a shared library loaded in addition to other backends at runtime. If I still had the energy of my younger years I would try to pack the platform dependent part of the libraries into a dynamic load library together with a JIT translator (e.g. libjit) for the portable application code and have a single byte-code producing compiler backend. From: Jay K Sent: Friday, May 22, 2015 2:57 AM To: Elmar Stellnberger ; rodney.m.bates at acm.org ; m3devel Subject: Re: [M3devel] How to integrate llvm into cm3 Imho "all" options should be implemented, for purposes of convenient debugging/development of the backends. "external" is good for developing backends. You can "snapshot" the state of things slightly into the pipeline and then just iterate on later parts. At the cost of having all the serialization code. "integrated" is usually preferable for performance, for users. E.g. NTx86 backend has been sitting in there for decades unused by half the users. Having extra backends sitting in there unused is ok. Ideally, agreed, they'd be .dll/.sos if we can construct it that way, but ok either way imho. Ideally also cm3 would dynamically link to libm3/m3core, but it doesn't. Everything is demand paged so there is cost to distribute over the network and copy around, but at runtime, the pages just sit mostly cold on disk. One difficulty though is the need to have and build the LLVM code. For that reason, delayload-dynamically-linked might be preferable. It depends on how small/easy-to-build LLVM is. I guess LLVM provides more choices than before. In order of efficiency and inverse order of debuggability: 1 We could construct LLVM IR in memory and run LLVM in-proc and write .o. 2 We could write out LLVM bytes and run an executable. 3 We could write out LLVM text and run an executable. > My personal preference would be to only have one default target statically compiled in It has never worked that away. Granted, we didn't really have backends before, just writing mainly IR. And I don't think LLVM works that way, does it? I like one compiler to have all targets and just select with a command line switch. I don't like how hard it is to acquire various cross-toolschains. Granted, we cheat and are incomplete -- you still need the next piece of the pipeline, be it LLVM or m3cc (which has one target), or a C compiler or assembler or linker or "libc.a". binutils at least has this "all" notion reasonably well working now I believe. There are tradeoffs though. If only one backend has a bug, and they are all statically linked together, you have to update them all. And the largely wasted bloat. Ultimately really, I'd like the C backend to output portable C and then just one C backend, one distribution .tar.gz for all targets. There is work to do there..not easy..and no progress lately. Things like INTEGER preserving flexibility in the output, and using sizeof(INTEGER) in expressions instead of using 4 or 8 and folding... - Jay > Date: Thu, 21 May 2015 20:13:18 +0200 > From: estellnb at elstel.org > To: rodney.m.bates at acm.org; m3devel at elegosoft.com > Subject: Re: [M3devel] How to integrate llvm into cm3 > > Am 21.05.15 um 19:24 schrieb Rodney M. Bates: > > > > There are pros and cons. Integrating Peter's cm3-to-llvm conversion into > > the cm3 executable would be faster compiling--one fewer time per > > interface > > or module for the OS to create a process and run an executable. But it > > would also entail linking in this code, along with some of llvm's > > infrastructure, > > into cm3, making its executable bigger, with code that might not be > > executed > > at all, when a different backend is used. We already have the x86 > > integrated > > backend and the C backend linked in to cm3, whether used or not. > > > > Anybody have thoughts on this? I suppose it could be set up to be fairly > > easily changed either way too. > > > > Why not put each backend into a shared library and load it dynamically? > Are there still problems with shared libraries for some build targets? > On the other hand having cm3-IR handy and being able to translate > cm3-IR by an executable like m3cc into any desired target has proven > to be very handy for debugging as well as chocking the Modula-3 > compiler on a new platform. > My personal preference would be to only have one default target > statically compiled in namely that on for cm3-IR and load all other > targets by a shared libarary dynamically. If that should fail for some > reason one can still use m3cc or one of its counterparts to > accomplish the translation process. > > Elmar > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From estellnb at elstel.org Fri May 22 12:53:14 2015 From: estellnb at elstel.org (Elmar Stellnberger) Date: Fri, 22 May 2015 12:53:14 +0200 Subject: [M3devel] How to integrate llvm into cm3 In-Reply-To: References: <555E14BC.2040805@lcwb.coop>, <555E203E.4040203@elstel.org> <0A1CDD8C-EEB5-40E2-A38B-28E8EEA8C37E@elstel.org> Message-ID: <8A3AB2ED-C11E-4787-A7F8-C8F12157EAA5@elstel.org> Am 22.05.2015 um 12:16 schrieb dirk muysers: > >> What about the said platform dependencies you have discovered? > > Not me (I never seriously considered using it), but many people on the llvm > forums pointed to the fact. One example among > many: > > Does your C code ever use the 'long' type? If so, the LLVM IR will be > different depending on whether it's targeting linux-32 or linux-64. Do > you ever use size_t? Same problem. Do you ever use a union containing > both pointers and integers? See above. In principle, it's possible to > write platform-independent IR, or even C code that compiles to > platform-independent IR. In practice, especially if you include any > system headers, it's remarkably hard. > (Jeffrey Yasskin jyasskin at google.com) Concerning me I am a very conscientious programmer when it comes to make a difference between long, long long and int. I only use long if my code requires a data item to be exactly as large as a pointer (in special cases also when it comes to tap the power of 64bit machines, f.i. that might be either 32/64bit as a base type for arbitrary length integers; however not without taking special provisions that will tackle the difference in data size. ). Usually aligning the pointers for the next structure at the beginning would also solve such an issue when it comes to reuse existing code where data sizes may not be changed from long either to int or long long without special consideration. Those who use glib f.i. additionally have a g[u]int32/64 which they can use instead of int / long long though that should at last never make a difference for Intel x86 based systems. So when it comes to use int or long long I mostly rely on them being either 32 or 64bit. I know that most programmers do not care and just always use long which I consider to be a particularly bad practice. Even in the Linux kernel they have declared "typedef long time_t" instead of "typedef long long time_t" which will create an Y2K mess all over in 2038 for all 32bit machines still in use then. A somehow bad decision which needs to be changed sooner or later even without llvm. Now let us think of Modula-3. I believe we had a long type for cm3 the last time I have seen it. However an equivalent to long long which does also exist on 32bit platforms would be an absolute requirement to not break things for llvm! Many Thanks for notifying us about this issue, Dirk. As far as I can see a Modula-3 programmer will need a good core for portable programming anyway as we did not even uphold a guarantee for WIDECHAR to be either 16 or 32bit. > > And then, besides the IR proper, there is that steadily increasing > legion of intrinsics. > > Unless you translate C-like code and build upon the existing technical > LLVM heritage, je vous souhaite bien du plaisir as the French say... > > From: Elmar Stellnberger > Sent: Friday, May 22, 2015 11:49 AM > To: dirk muysers > Subject: Re: [M3devel] How to integrate llvm into cm3 > > > Am 22.05.2015 um 10:48 schrieb dirk muysers: > >> Personally I have a strong dislike towards LLVM. >> 1. You first have to compile the whole tool chain. >> 2. It is a monstrous blob of code, mainly on Windows. >> 3. Contrary to a widespread belief, It is definitely NOT platform independent. >> 4. It changes at every release. >> 5. Having built your objects, you still have to run them through a platform assembler-linker. >> > > Is it really that bad? What about the said platform dependencies you have discovered? > I believe llvm could be beneficial in deed when it comes to debugging and/or analyzing Modula-3 programs, > as there are tools like SAFECode and to my knowledge we never had a fully featured m3gdb. > Besides this I would hardly like to believe that llvm is still that volatile when it comes to changes. > I know it had some issues in its first days but I can hardly believe that qt5 on MacOS would rely on clang/llvm > if that were not a ready to use technology nowadays. I would hope the main changes to llvm had already > been done when Apple started to adopt llvm for its own needs. > Concerning the code size of llvm that should not be a problem as long as it remains a separate module > compiling into an own executable or a shared library loaded in addition to other backends at runtime. > > >> If I still had the energy of my younger years I would try to pack the platform >> dependent part of the libraries into a dynamic load library together with a JIT >> translator (e.g. libjit) for the portable application code and have a single byte-code >> producing compiler backend. >> >> From: Jay K >> Sent: Friday, May 22, 2015 2:57 AM >> To: Elmar Stellnberger ; rodney.m.bates at acm.org ; m3devel >> Subject: Re: [M3devel] How to integrate llvm into cm3 >> >> Imho "all" options should be implemented, for purposes of convenient debugging/development of the backends. >> >> >> "external" is good for developing backends. You can "snapshot" the state of things >> slightly into the pipeline and then just iterate on later parts. >> >> >> At the cost of having all the serialization code. >> >> >> "integrated" is usually preferable for performance, for users. >> >> >> E.g. NTx86 backend has been sitting in there for decades unused by half the users. >> >> >> Having extra backends sitting in there unused is ok. >> Ideally, agreed, they'd be .dll/.sos if we can construct it that way, but ok either way imho. >> Ideally also cm3 would dynamically link to libm3/m3core, but it doesn't. >> >> >> Everything is demand paged so there is cost to distribute over the network >> and copy around, but at runtime, the pages just sit mostly cold on disk. >> >> >> One difficulty though is the need to have and build the LLVM code. >> For that reason, delayload-dynamically-linked might be preferable. >> It depends on how small/easy-to-build LLVM is. >> >> >> I guess LLVM provides more choices than before. >> In order of efficiency and inverse order of debuggability: >> 1 We could construct LLVM IR in memory and run LLVM in-proc and write .o. >> 2 We could write out LLVM bytes and run an executable. >> 3 We could write out LLVM text and run an executable. >> >> >> > My personal preference would be to only have one default target statically compiled in >> >> It has never worked that away. Granted, we didn't really have backends before, just writing mainly IR. >> And I don't think LLVM works that way, does it? >> >> I like one compiler to have all targets and just select with a command line switch. >> >> I don't like how hard it is to acquire various cross-toolschains. >> Granted, we cheat and are incomplete -- you still need the next piece of the pipeline, >> be it LLVM or m3cc (which has one target), or a C compiler or assembler or linker or "libc.a". >> >> >> binutils at least has this "all" notion reasonably well working now I believe. >> >> >> >> There are tradeoffs though. If only one backend has a bug, and they are all statically linked together, you have to update them all. >> And the largely wasted bloat. >> >> >> Ultimately really, I'd like the C backend to output portable C and then just one C backend, one distribution .tar.gz for all targets. >> There is work to do there..not easy..and no progress lately. >> Things like INTEGER preserving flexibility in the output, and using sizeof(INTEGER) in expressions instead of using 4 or 8 and folding... >> >> >> >> - Jay >> >> >> >> >> > Date: Thu, 21 May 2015 20:13:18 +0200 >> > From: estellnb at elstel.org >> > To: rodney.m.bates at acm.org; m3devel at elegosoft.com >> > Subject: Re: [M3devel] How to integrate llvm into cm3 >> > >> > Am 21.05.15 um 19:24 schrieb Rodney M. Bates: >> > > >> > > There are pros and cons. Integrating Peter's cm3-to-llvm conversion into >> > > the cm3 executable would be faster compiling--one fewer time per >> > > interface >> > > or module for the OS to create a process and run an executable. But it >> > > would also entail linking in this code, along with some of llvm's >> > > infrastructure, >> > > into cm3, making its executable bigger, with code that might not be >> > > executed >> > > at all, when a different backend is used. We already have the x86 >> > > integrated >> > > backend and the C backend linked in to cm3, whether used or not. >> > > >> > > Anybody have thoughts on this? I suppose it could be set up to be fairly >> > > easily changed either way too. >> > > >> > >> > Why not put each backend into a shared library and load it dynamically? >> > Are there still problems with shared libraries for some build targets? >> > On the other hand having cm3-IR handy and being able to translate >> > cm3-IR by an executable like m3cc into any desired target has proven >> > to be very handy for debugging as well as chocking the Modula-3 >> > compiler on a new platform. >> > My personal preference would be to only have one default target >> > statically compiled in namely that on for cm3-IR and load all other >> > targets by a shared libarary dynamically. If that should fail for some >> > reason one can still use m3cc or one of its counterparts to >> > accomplish the translation process. >> > >> > Elmar >> > >> > >> > >> > >> > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From estellnb at elstel.org Fri May 22 12:58:56 2015 From: estellnb at elstel.org (Elmar Stellnberger) Date: Fri, 22 May 2015 12:58:56 +0200 Subject: [M3devel] How to integrate llvm into cm3 In-Reply-To: References: <555E14BC.2040805@lcwb.coop>, <555E203E.4040203@elstel.org> <0A1CDD8C-EEB5-40E2-A38B-28E8EEA8C37E@elstel.org> Message-ID: <7E7A129A-7EAB-4424-98BD-D2D1900CF0AB@elstel.org> > (Jeffrey Yasskin jyasskin at google.com) > > And then, besides the IR proper, there is that steadily increasing > legion of intrinsics. Dirk, what can you tell us about intrinsics? Do they have a sufficient abstraction level for LLVM or do they really expose hidden language dependencies? -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Fri May 22 13:06:00 2015 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri, 22 May 2015 13:06:00 +0200 (CEST) Subject: [M3devel] How to integrate llvm into cm3 In-Reply-To: References: <555E14BC.2040805@lcwb.coop>, <555E203E.4040203@elstel.org> <0A1CDD8C-EEB5-40E2-A38B-28E8EEA8C37E@elstel.org> Message-ID: On Fri, 22 May 2015, dirk muysers wrote: > >> What about the said platform dependencies you have discovered? > Not me (I never seriously considered using it), but many people on the > llvm forums pointed to the fact. One example among many: Why should the LLVM IR be platform independent? Like object files, the ll bitcode files are platform dependent. Of course, there must be a way to address processor specific instructions. Intrinsics are used for that purpose. If you want processor specific optimizations, then LL cannot be platform independent. From estellnb at elstel.org Fri May 22 14:26:28 2015 From: estellnb at elstel.org (Elmar Stellnberger) Date: Fri, 22 May 2015 14:26:28 +0200 Subject: [M3devel] How to integrate llvm into cm3 In-Reply-To: References: <555E14BC.2040805@lcwb.coop>, <555E203E.4040203@elstel.org> <0A1CDD8C-EEB5-40E2-A38B-28E8EEA8C37E@elstel.org> Message-ID: <94C9A717-B0EA-4257-A728-C926FC8A4FEB@elstel.org> Am 22.05.2015 um 13:06 schrieb Henning Thielemann: > > > On Fri, 22 May 2015, dirk muysers wrote: > >> >> What about the said platform dependencies you have discovered? > >> Not me (I never seriously considered using it), but many people on the llvm forums pointed to the fact. One example among many: > > Why should the LLVM IR be platform independent? Like object files, the ll bitcode files are platform dependent. Of course, there must be a way to address processor specific instructions. Intrinsics are used for that purpose. If you want processor specific optimizations, then LL cannot be platform independent. > You are right; not an issue of llvm though someone who is used to Java or C#/.net bytecode would not expect such a 'feature'. Am 22.05.2015 um 12:53 schrieb Elmar Stellnberger: > Now let us think of Modula-3. I believe we had a long type for cm3 the last > time I have seen it. However an equivalent to long long which does also > exist on 32bit platforms would be an absolute requirement to not break > things for llvm! Many Thanks for notifying us about this issue, Dirk. > > As far as I can see a Modula-3 programmer will need a good core for > portable programming anyway as we did not even uphold a guarantee for > WIDECHAR to be either 16 or 32bit. > > Nonetheless we actually need to demand the necessary precautions from Modula-3 for platform independent programming. Having a type (1) which is at least 64bit long (why not also 128bit) for numeric purposes (at best also available on 32bit platforms) (2) a type which is exactly as long as a pointer (f.i. for subtracting two pointers) (3) the regular INTEGER defined to be at most 32bit in order to avoid an overkill in memory consumption and computing power Anyone here who can tell me about the current state of LONGINT support for cm3? As far as I can remember we had a LONGINT but only on 64bit machines. For portable programming we will at least need types for (2) and (3). (1) would be an additional plus. So writing code which will execute seamlessly either in a 32bit or 64bit environment as I have frequently tested it and done in the last eight years should at least become possible with Modula-3. It needs to be doable when using gcc as well as llvm though the 'advantages' are more obvious when it comes to arch-all llvm bytecode. From rodney_bates at lcwb.coop Fri May 22 18:15:06 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Fri, 22 May 2015 11:15:06 -0500 Subject: [M3devel] How to integrate llvm into cm3 In-Reply-To: References: <555E14BC.2040805@lcwb.coop>, <555E203E.4040203@elstel.org> Message-ID: <555F560A.4010506@lcwb.coop> On 05/21/2015 07:57 PM, Jay K wrote: > Imho "all" options should be implemented, for purposes of convenient debugging/development of the backends. > Yes, I like that idea. We should be able to do it without a huge coding burden. > > "external" is good for developing backends. You can "snapshot" the state of things > slightly into the pipeline and then just iterate on later parts. > Yes. > > At the cost of having all the serialization code. > Yes, although it is already there now, for cm3-IR. It exists in llvm for llvm-IR, but has to be linked in. > > "integrated" is usually preferable for performance, for users. > Yes > > E.g. NTx86 backend has been sitting in there for decades unused by half the users. > > > Having extra backends sitting in there unused is ok. > Ideally, agreed, they'd be .dll/.sos if we can construct it that way, but ok either way imho. Thank you. > Ideally also cm3 would dynamically link to libm3/m3core, but it doesn't. > > > Everything is demand paged so there is cost to distribute over the network > and copy around, but at runtime, the pages just sit mostly cold on disk. > Hadn't thought of that. It pretty well addresses my concerns about how much to link in. We can just be extravagant and let the paging take care of it. > > One difficulty though is the need to have and build the LLVM code. > For that reason, delayload-dynamically-linked might be preferable. > It depends on how small/easy-to-build LLVM is. > All of llvm is huge and takes a long time to build. Both Peter and I are currently following the approach of linking in only a subset of llvm, containing code to build its internal trees and serialize them. I haven't checked actual sizes of compiled code, but in library count, it's perhaps 1/4 or so. Of course, you still need the rest for the separate executable that optimizes/codegens. > > I guess LLVM provides more choices than before. > In order of efficiency and inverse order of debuggability: > 1 We could construct LLVM IR in memory and run LLVM in-proc and write .o. > 2 We could write out LLVM bytes and run an executable. > 3 We could write out LLVM text and run an executable. > > One consideration is that there is a *lot* of command-line processing, etc. in driving llvm opt/codegen. llc, a separate executable which comes as part of llvm already provides this. Doing 1 above would require duplicating this, or maybe ripping out the C++ code and somehow repackaging it. We would still have to pass all these options through cm3. The way I have Builder working now, what of this stuff that is handled, comes from Quake code, etc. bypasses cm3 and gets passed in to llc. > > My personal preference would be to only have one default target statically compiled in > > It has never worked that away. Granted, we didn't really have backends before, just writing mainly IR. > And I don't think LLVM works that way, does it? > > I like one compiler to have all targets and just select with a command line switch. > > I don't like how hard it is to acquire various cross-toolschains. > Granted, we cheat and are incomplete -- you still need the next piece of the pipeline, > be it LLVM or m3cc (which has one target), or a C compiler or assembler or linker or "libc.a". > > > binutils at least has this "all" notion reasonably well working now I believe. > > > > There are tradeoffs though. If only one backend has a bug, and they are all statically linked together, you have to update them all. > And the largely wasted bloat. > > > Ultimately really, I'd like the C backend to output portable C and then just one C backend, one distribution .tar.gz for all targets. > There is work to do there..not easy..and no progress lately. > Things like INTEGER preserving flexibility in the output, and using sizeof(INTEGER) in expressions instead of using 4 or 8 and folding... > > > > - Jay > > > > > > Date: Thu, 21 May 2015 20:13:18 +0200 > > From: estellnb at elstel.org > > To: rodney.m.bates at acm.org; m3devel at elegosoft.com > > Subject: Re: [M3devel] How to integrate llvm into cm3 > > > > Am 21.05.15 um 19:24 schrieb Rodney M. Bates: > > > > > > There are pros and cons. Integrating Peter's cm3-to-llvm conversion into > > > the cm3 executable would be faster compiling--one fewer time per > > > interface > > > or module for the OS to create a process and run an executable. But it > > > would also entail linking in this code, along with some of llvm's > > > infrastructure, > > > into cm3, making its executable bigger, with code that might not be > > > executed > > > at all, when a different backend is used. We already have the x86 > > > integrated > > > backend and the C backend linked in to cm3, whether used or not. > > > > > > Anybody have thoughts on this? I suppose it could be set up to be fairly > > > easily changed either way too. > > > > > > > Why not put each backend into a shared library and load it dynamically? > > Are there still problems with shared libraries for some build targets? > > On the other hand having cm3-IR handy and being able to translate > > cm3-IR by an executable like m3cc into any desired target has proven > > to be very handy for debugging as well as chocking the Modula-3 > > compiler on a new platform. > > My personal preference would be to only have one default target > > statically compiled in namely that on for cm3-IR and load all other > > targets by a shared libarary dynamically. If that should fail for some > > reason one can still use m3cc or one of its counterparts to > > accomplish the translation process. > > > > Elmar > > > > > > > > > > > > -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Fri May 22 18:59:15 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Fri, 22 May 2015 11:59:15 -0500 Subject: [M3devel] LLVM version and patches thereto In-Reply-To: References: <555E0E63.6070506@lcwb.coop> Message-ID: <555F6063.2000204@lcwb.coop> On 05/21/2015 05:09 PM, Peter McKinna wrote: > Hi Rodney, > > Good to see this stuff moving forward. I had no idea how to integrate it with the front end. I'm using llvm 3.5 . I downloaded 3.6 and built it but then could not get some dibuilder bindings I had added to compile, some sort of problem with the wrap function which I have yet to sort out. I think they made a change to the way metadata is treated. Anyway I have attached the 2 sets of bindings I have been using. I have to commit a few bug fixes and my initial attempt at debug support. I have been using llvm 3.4.2, which was the current release when I first started thinking about this. I want to avoid overlapping heavy development, while simultaneously constantly reworking what's already done to new versions. However, I am well past due to update to as late a version as reasonable. They have made a couple of changes that I know will be relevant. (I've been monitoring their mailing list--very high traffic.) One is the metadata class is no longer a subclass of Value, with various implications to the IR. Another is that there is only one pointer type. It no longer gives its referent type. We (Peter and I) have duplicated on DIBuilder bindings. Yours is tidier looking, but mine is pretty much complete. I will undertake merging them and adapting to latest llvm. I had some real nightmares getting wrap and unwrap unravelled, and will probably have to do some of that again. IMO, this is, by far, the most extreme specific example I have ever seen for why user-defined overloading is disastrous idea. There are a bazillion overloads of wrap and unwrap, whose declarations are scattered all over the universe. Figuring out which one you got, or, in case none was found, where the one you wanted is horrible. It's further complicated by the fact that there are various user-defined implicit conversions that the compiler can insert with no syntactic clue in the call you are trying to decrypt. These are just as spread out, maybe more. And have you ever tried to construct a transitive #include closure in something as big as llvm? > Speaking of debugging, I was following what I think clang uses which is the dibuilder class . So far its very primitive and could probably be split into its own module. I managed to get simple scalars, enumerations, arrays and records to be debugged with stock gdb and none of the name mangling I usually get. But globals, objects and sets dont work. I think this needs an expert and mybe a chat with the llvm people, they seem pretty helpful. > Anyway it runs the maze program, I compiled the collector the other day, 15,000 lines of llvm ir. The code quality looks pretty good from a brief inspection of the assembly thats compiled at O3 although O2 doesnt make much difference. I read in tips for programmers somewhere that pascal like languages with lots of runtime checks should be running some extra passes for better optimisation. We could look at that in the future. > > Regards Peter > > On Fri, May 22, 2015 at 2:57 AM, Rodney M. Bates > wrote: > > Peter, what version of llvm are you using? Also, can you tell us what the patches > you have made to it are? Have you sent these to the llvm developers to incorporate? > I can guess one is to tolerate DW_LANG_Modula3. > > > -- > Rodney Bates > rodney.m.bates at acm.org > > -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Fri May 22 19:20:17 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Fri, 22 May 2015 12:20:17 -0500 Subject: [M3devel] How to integrate llvm into cm3 In-Reply-To: References: <555E14BC.2040805@lcwb.coop>, <555E203E.4040203@elstel.org> Message-ID: <555F6551.3000300@lcwb.coop> On 05/22/2015 03:48 AM, dirk muysers wrote: > Personally I have a strong dislike towards LLVM. > 1. You first have to compile the whole tool chain. > 2. It is a monstrous blob of code, mainly on Windows. > 3. Contrary to a widespread belief, It is definitely NOT platform independent. > 4. It changes at every release. > 5. Having built your objects, you still have to run them through a platform assembler-linker. Having grubbed around in it a bit, I can't say I'm exactly ecstatic about llvm. However, its developers have at least adopted the intention of providing clear documentation. While the documentation has trapped/misled me in some areas, this is dramatically better than gcc, where, as I understand, there is intentional avoidance of documenting internal formats and data structures, as a way to make it difficult to work on for any but programmers who are both very skilled and have a lot of time to spend on it. Further, it appears gcc changes about as fast as llvm. > If I still had the energy of my younger years I would try to pack the platform > dependent part of the libraries into a dynamic load library together with a JIT > translator (e.g. libjit) for the portable application code and have a single byte-code > producing compiler backend. I don't think things like this are at all unrealistic, if we get a basic llvm backend developed. > *From:* Jay K > *Sent:* Friday, May 22, 2015 2:57 AM > *To:* Elmar Stellnberger ; rodney.m.bates at acm.org ; m3devel > *Subject:* Re: [M3devel] How to integrate llvm into cm3 > Imho "all" options should be implemented, for purposes of convenient debugging/development of the backends. > > "external" is good for developing backends. You can "snapshot" the state of things > slightly into the pipeline and then just iterate on later parts. > > At the cost of having all the serialization code. > > "integrated" is usually preferable for performance, for users. > > E.g. NTx86 backend has been sitting in there for decades unused by half the users. > > Having extra backends sitting in there unused is ok. > Ideally, agreed, they'd be .dll/.sos if we can construct it that way, but ok either way imho. > Ideally also cm3 would dynamically link to libm3/m3core, but it doesn't. > > Everything is demand paged so there is cost to distribute over the network > and copy around, but at runtime, the pages just sit mostly cold on disk. > > One difficulty though is the need to have and build the LLVM code. > For that reason, delayload-dynamically-linked might be preferable. > It depends on how small/easy-to-build LLVM is. > > I guess LLVM provides more choices than before. > In order of efficiency and inverse order of debuggability: > 1 We could construct LLVM IR in memory and run LLVM in-proc and write .o. > 2 We could write out LLVM bytes and run an executable. > 3 We could write out LLVM text and run an executable. > > > My personal preference would be to only have one default target statically compiled in > It has never worked that away. Granted, we didn't really have backends before, just writing mainly IR. > And I don't think LLVM works that way, does it? > I like one compiler to have all targets and just select with a command line switch. > I don't like how hard it is to acquire various cross-toolschains. > Granted, we cheat and are incomplete -- you still need the next piece of the pipeline, > be it LLVM or m3cc (which has one target), or a C compiler or assembler or linker or "libc.a". > > binutils at least has this "all" notion reasonably well working now I believe. > There are tradeoffs though. If only one backend has a bug, and they are all statically linked together, you have to update them all. > And the largely wasted bloat. > Ultimately really, I'd like the C backend to output portable C and then just one C backend, one distribution .tar.gz for all targets. > There is work to do there..not easy..and no progress lately. > Things like INTEGER preserving flexibility in the output, and using sizeof(INTEGER) in expressions instead of using 4 or 8 and folding... > > - Jay > > > > > > Date: Thu, 21 May 2015 20:13:18 +0200 > > From: estellnb at elstel.org > > To: rodney.m.bates at acm.org; m3devel at elegosoft.com > > Subject: Re: [M3devel] How to integrate llvm into cm3 > > > > Am 21.05.15 um 19:24 schrieb Rodney M. Bates: > > > > > > There are pros and cons. Integrating Peter's cm3-to-llvm conversion into > > > the cm3 executable would be faster compiling--one fewer time per > > > interface > > > or module for the OS to create a process and run an executable. But it > > > would also entail linking in this code, along with some of llvm's > > > infrastructure, > > > into cm3, making its executable bigger, with code that might not be > > > executed > > > at all, when a different backend is used. We already have the x86 > > > integrated > > > backend and the C backend linked in to cm3, whether used or not. > > > > > > Anybody have thoughts on this? I suppose it could be set up to be fairly > > > easily changed either way too. > > > > > > > Why not put each backend into a shared library and load it dynamically? > > Are there still problems with shared libraries for some build targets? > > On the other hand having cm3-IR handy and being able to translate > > cm3-IR by an executable like m3cc into any desired target has proven > > to be very handy for debugging as well as chocking the Modula-3 > > compiler on a new platform. > > My personal preference would be to only have one default target > > statically compiled in namely that on for cm3-IR and load all other > > targets by a shared libarary dynamically. If that should fail for some > > reason one can still use m3cc or one of its counterparts to > > accomplish the translation process. > > > > Elmar > > > > > > > > > > > > -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Fri May 22 19:55:27 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Fri, 22 May 2015 12:55:27 -0500 Subject: [M3devel] How to integrate llvm into cm3 In-Reply-To: <8A3AB2ED-C11E-4787-A7F8-C8F12157EAA5@elstel.org> References: <555E14BC.2040805@lcwb.coop>, <555E203E.4040203@elstel.org> <0A1CDD8C-EEB5-40E2-A38B-28E8EEA8C37E@elstel.org> <8A3AB2ED-C11E-4787-A7F8-C8F12157EAA5@elstel.org> Message-ID: <555F6D8F.4070109@lcwb.coop> This is a worthwhile discussion, but it has very little to do with using llvm as a back end. In the llvm-IR, sizes of integers, pointers, etc. are constant numbers. The frontend, whether Clang, CM3, or any other, makes the decisions about mapping language types like long, INTEGER, pointers, etc. to a size, target-dependently or otherwise, according to the language's rules. LLvm does not make these decisions. Its target dependencies are mostly in the line of different code generators for different instruction sets. On 05/22/2015 05:53 AM, Elmar Stellnberger wrote: > > Am 22.05.2015 um 12:16 schrieb dirk muysers: > >> >> What about the said platform dependencies you have discovered? >> Not me (I never seriously considered using it), but many people on the llvm >> forums pointed to the fact. One example among >> many: >> >> Does your C code ever use the 'long' type? If so, the LLVM IR will be >> different depending on whether it's targeting linux-32 or linux-64. Do >> you ever use size_t? Same problem. Do you ever use a union containing >> both pointers and integers? See above. In principle, it's possible to >> write platform-independent IR, or even C code that compiles to >> platform-independent IR. In practice, especially if you include any >> system headers, it's remarkably hard. >> (Jeffrey Yasskin jyasskin at google.com) > > Concerning me I am a very conscientious programmer when it comes to > make a difference between long, long long and int. I only use long if my > code requires a data item to be exactly as large as a pointer (in special > cases also when it comes to tap the power of 64bit machines, f.i. that > might be either 32/64bit as a base type for arbitrary length integers; > however not without taking special provisions that will tackle the > difference in data size. ). Usually aligning the pointers for the next > structure at the beginning would also solve such an issue when it comes > to reuse existing code where data sizes may not be changed from long > either to int or long long without special consideration. Those who use > glib f.i. additionally have a g[u]int32/64 which they can use instead of int > / long long though that should at last never make a difference for Intel x86 > based systems. So when it comes to use int or long long I mostly rely > on them being either 32 or 64bit. > I know that most programmers do not care and just always use long which > I consider to be a particularly bad practice. Even in the Linux kernel they > have declared "typedef long time_t" instead of "typedef long long time_t" > which will create an Y2K mess all over in 2038 for all 32bit machines still > in use then. A somehow bad decision which needs to be changed sooner > or later even without llvm. > > Now let us think of Modula-3. I believe we had a long type for cm3 the last > time I have seen it. However an equivalent to long long which does also > exist on 32bit platforms would be an absolute requirement to not break > things for llvm! Many Thanks for notifying us about this issue, Dirk. > Whether types like integer have a language-specified or target-dependent range is a tough language design question. I have tended to favor a fixed, language-specified range, but there are pros and cons. I do think all the time about end-of-range cases and native word size dependencies. It takes a great deal of care, and I know of no way to design a language that doesn't, to some extent, trade one set of problems for another. Signed/unsigned creates similar language dilemmas. > As far as I can see a Modula-3 programmer will need a good core for > portable programming anyway as we did not even uphold a guarantee for > WIDECHAR to be either 16 or 32bit. > The evolving nature of first UCS and then Unicode standards has left many language designers knocked off balance. Critical Mass first introduced WIDECHAR as 16-bit when that was what everybody thought was enough. Then things changed, and it wasn't anymore. Right now, it's a configuration parameter (must be the same for the entire link closure) in Modula-3. I personally favor making it full Unicode by default, in the next release, as this is where the world is now. This is hopefully a simpler problem than INTEGER, etc., because, as of now, the Unicode committee has emphatically assured us that the range will *never* increase. We can hope. > > > > >> And then, besides the IR proper, there is that steadily increasing >> legion of intrinsics. >> Unless you translate C-like code and build upon the existing technical >> LLVM heritage, /je vous souhaite bien du plaisir/ as the French say... >> ** >> *From:* Elmar Stellnberger >> *Sent:* Friday, May 22, 2015 11:49 AM >> *To:* dirk muysers >> *Subject:* Re: [M3devel] How to integrate llvm into cm3 >> Am 22.05.2015 um 10:48 schrieb dirk muysers: >> >>> Personally I have a strong dislike towards LLVM. >>> 1. You first have to compile the whole tool chain. >>> 2. It is a monstrous blob of code, mainly on Windows. >>> 3. Contrary to a widespread belief, It is definitely NOT platform independent. >>> 4. It changes at every release. >>> 5. Having built your objects, you still have to run them through a platform assembler-linker. >> Is it really that bad? What about the said platform dependencies you have discovered? >> I believe llvm could be beneficial in deed when it comes to debugging and/or analyzing Modula-3 programs, >> as there are tools like SAFECode and to my knowledge we never had a fully featured m3gdb. >> Besides this I would hardly like to believe that llvm is still that volatile when it comes to changes. >> I know it had some issues in its first days but I can hardly believe that qt5 on MacOS would rely on clang/llvm >> if that were not a ready to use technology nowadays. I would hope the main changes to llvm had already >> been done when Apple started to adopt llvm for its own needs. >> Concerning the code size of llvm that should not be a problem as long as it remains a separate module >> compiling into an own executable or a shared library loaded in addition to other backends at runtime. >> >>> If I still had the energy of my younger years I would try to pack the platform >>> dependent part of the libraries into a dynamic load library together with a JIT >>> translator (e.g. libjit) for the portable application code and have a single byte-code >>> producing compiler backend. >>> *From:*Jay K >>> *Sent:*Friday, May 22, 2015 2:57 AM >>> *To:*Elmar Stellnberger ;rodney.m.bates at acm.org ;m3devel >>> *Subject:*Re: [M3devel] How to integrate llvm into cm3 >>> Imho "all" options should be implemented, for purposes of convenient debugging/development of the backends. >>> >>> "external" is good for developing backends. You can "snapshot" the state of things >>> slightly into the pipeline and then just iterate on later parts. >>> >>> At the cost of having all the serialization code. >>> >>> "integrated" is usually preferable for performance, for users. >>> >>> E.g. NTx86 backend has been sitting in there for decades unused by half the users. >>> >>> Having extra backends sitting in there unused is ok. >>> Ideally, agreed, they'd be .dll/.sos if we can construct it that way, but ok either way imho. >>> Ideally also cm3 would dynamically link to libm3/m3core, but it doesn't. >>> >>> Everything is demand paged so there is cost to distribute over the network >>> and copy around, but at runtime, the pages just sit mostly cold on disk. >>> >>> One difficulty though is the need to have and build the LLVM code. >>> For that reason, delayload-dynamically-linked might be preferable. >>> It depends on how small/easy-to-build LLVM is. >>> >>> I guess LLVM provides more choices than before. >>> In order of efficiency and inverse order of debuggability: >>> 1 We could construct LLVM IR in memory and run LLVM in-proc and write .o. >>> 2 We could write out LLVM bytes and run an executable. >>> 3 We could write out LLVM text and run an executable. >>> >>> > My personal preference would be to only have one default targetstatically compiled in >>> It has never worked that away. Granted, we didn't really have backends before, just writing mainly IR. >>> And I don't think LLVM works that way, does it? >>> I like one compiler to have all targets and just select with a command line switch. >>> I don't like how hard it is to acquire various cross-toolschains. >>> Granted, we cheat and are incomplete -- you still need the next piece of the pipeline, >>> be it LLVM or m3cc (which has one target), or a C compiler or assembler or linker or "libc.a". >>> >>> binutils at least has this "all" notion reasonably well working now I believe. >>> There are tradeoffs though. If only one backend has a bug, and they are all statically linked together, you have to update them all. >>> And the largely wasted bloat. >>> Ultimately really, I'd like the C backend to output portable C and then just one C backend, one distribution .tar.gz for all targets. >>> There is work to do there..not easy..and no progress lately. >>> Things like INTEGER preserving flexibility in the output, and using sizeof(INTEGER) in expressions instead of using 4 or 8 and folding... >>> >>> - Jay >>> >>> >>> >>> >>> > Date: Thu, 21 May 2015 20:13:18 +0200 >>> > From:estellnb at elstel.org >>> > To:rodney.m.bates at acm.org ; m3devel at elegosoft.com >>> > Subject:Re: [M3devel] How to integrate llvm into cm3 >>> > >>> > Am 21.05.15 um 19:24 schriebRodney M. Bates: >>> > > >>> > > There are pros and cons.Integrating Peter's cm3-to-llvm conversion into >>> > > the cm3executable would be faster compiling--one fewer time per >>> > > interface >>> > >or module for the OS to create a process and run an executable. But it >>> >> would also entail linking in this code, along with some of llvm's >>> > > infrastructure, >>> >> into cm3, making its executable bigger, with code that might not be >>> > > executed >>> > >at all, when a different backend is used. We already have the x86 >>> > > integrated >>> > >backend and the C backend linked in to cm3, whether used or not. >>> >> >>> > > Anybody have thoughts on this? I suppose it could be set upto be fairly >>> > > easily changed either way too. >>> >> >>> > >>> > Why notput each backend into a shared library and load it dynamically? >>> > Arethere still problems with shared libraries for some build targets? >>> > Onthe other hand having cm3-IR handy and being able to translate >>> > cm3-IRby an executable like m3cc into any desired target has proven >>> > to bevery handy for debugging as well as chocking the Modula-3 >>> > compiler ona new platform. >>> > My personal preference would be to only have onedefault target >>> > statically compiled in namely that on for cm3-IR andload all other >>> > targets by a shared libarary dynamically. If thatshould fail for some >>> > reason one can still use m3cc or one of itscounterparts to >>> > accomplish the translation process. >>> > >>> > Elmar >>> > >>> > >>> > >>> > >>> > >>> > > -- Rodney Bates rodney.m.bates at acm.org From jay.krell at cornell.edu Sat May 23 03:58:43 2015 From: jay.krell at cornell.edu (Jay) Date: Fri, 22 May 2015 18:58:43 -0700 Subject: [M3devel] How to integrate llvm into cm3 In-Reply-To: <94C9A717-B0EA-4257-A728-C926FC8A4FEB@elstel.org> References: <555E14BC.2040805@lcwb.coop> <555E203E.4040203@elstel.org> <0A1CDD8C-EEB5-40E2-A38B-28E8EEA8C37E@elstel.org> <94C9A717-B0EA-4257-A728-C926FC8A4FEB@elstel.org> Message-ID: <105678F8-0E9B-4CE8-84ED-93F88F73E5AD@gmail.com> We use things with varying levels of abstraction. & concrete details are filled in at varying stages. C "long" is NOT specified as having an exact size and does NOT necessarily hold a pointer, and this is ok. C99 is pretty complete, messy. For each of 8, 16, 32, 64, It gives "least", "fast", and "exact" types. And pointer sized. Signed and unsigned. 32 types! INTEGER is always pointer sized. LONGINT is on all platforms. C# has this feature too. IntPtr & UIntPtr. But C# is dubious -- array indexes are always 32 bit signed. - Jay On May 22, 2015, at 5:26 AM, Elmar Stellnberger wrote: > > Am 22.05.2015 um 13:06 schrieb Henning Thielemann: > >> >> >> On Fri, 22 May 2015, dirk muysers wrote: >> >>>>> What about the said platform dependencies you have discovered? >> >>> Not me (I never seriously considered using it), but many people on the llvm forums pointed to the fact. One example among many: >> >> Why should the LLVM IR be platform independent? Like object files, the ll bitcode files are platform dependent. Of course, there must be a way to address processor specific instructions. Intrinsics are used for that purpose. If you want processor specific optimizations, then LL cannot be platform independent. > > > You are right; not an issue of llvm though someone who is used to Java or C#/.net bytecode would not expect such a 'feature'. > > > Am 22.05.2015 um 12:53 schrieb Elmar Stellnberger: > >> Now let us think of Modula-3. I believe we had a long type for cm3 the last >> time I have seen it. However an equivalent to long long which does also >> exist on 32bit platforms would be an absolute requirement to not break >> things for llvm! Many Thanks for notifying us about this issue, Dirk. >> >> As far as I can see a Modula-3 programmer will need a good core for >> portable programming anyway as we did not even uphold a guarantee for >> WIDECHAR to be either 16 or 32bit. > > Nonetheless we actually need to demand the necessary precautions from Modula-3 for platform independent programming. > Having a type > > (1) which is at least 64bit long (why not also 128bit) for numeric purposes (at best also available on 32bit platforms) > (2) a type which is exactly as long as a pointer (f.i. for subtracting two pointers) > (3) the regular INTEGER defined to be at most 32bit in order to avoid an overkill in memory consumption and computing power > > Anyone here who can tell me about the current state of LONGINT support for cm3? > As far as I can remember we had a LONGINT but only on 64bit machines. > For portable programming we will at least need types for (2) and (3). > (1) would be an additional plus. > > So writing code which will execute seamlessly either in a 32bit or 64bit environment as I have frequently tested it and done in > the last eight years should at least become possible with Modula-3. It needs to be doable when using gcc as well as llvm though > the 'advantages' are more obvious when it comes to arch-all llvm bytecode. > From hendrik at topoi.pooq.com Sat May 23 11:41:51 2015 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Sat, 23 May 2015 05:41:51 -0400 Subject: [M3devel] How to integrate llvm into cm3 In-Reply-To: <555F560A.4010506@lcwb.coop> References: <555E14BC.2040805@lcwb.coop> <555E203E.4040203@elstel.org> <555F560A.4010506@lcwb.coop> Message-ID: <20150523094151.GA16324@topoi.pooq.com> On Fri, May 22, 2015 at 11:15:06AM -0500, Rodney M. Bates wrote: > > >Ideally also cm3 would dynamically link to libm3/m3core, but it doesn't. > > > > > >Everything is demand paged so there is cost to distribute over the network > >and copy around, but at runtime, the pages just sit mostly cold on disk. > > > > Hadn't thought of that. It pretty well addresses my concerns about how much > to link in. We can just be extravagant and let the paging take care of it. Doesn't the executable have to be copied from the binary file to paged memory in order to run it? As far as I know, it's possible to replace the file being executed once execution has begun and it will just continue running. If this is true, the size of the llvm library might indicate it's best to load it dynaically from a shared library if and when needed. -- hendrik > > > > >One difficulty though is the need to have and build the LLVM code. > >For that reason, delayload-dynamically-linked might be preferable. > >It depends on how small/easy-to-build LLVM is. in Linux, one can presumably rely on the distribution to provide the llvm library. -- hendrik From estellnb at elstel.org Wed May 27 17:20:35 2015 From: estellnb at elstel.org (Elmar Stellnberger) Date: Wed, 27 May 2015 17:20:35 +0200 Subject: [M3devel] 64bit INTEGERs, WIDECHAR: language specified or configuration/target dependent? In-Reply-To: <555F6D8F.4070109@lcwb.coop> References: <555E14BC.2040805@lcwb.coop>, <555E203E.4040203@elstel.org> <0A1CDD8C-EEB5-40E2-A38B-28E8EEA8C37E@elstel.org> <8A3AB2ED-C11E-4787-A7F8-C8F12157EAA5@elstel.org> <555F6D8F.4070109@lcwb.coop> Message-ID: <6F9B9534-7DC2-4D4D-88CB-90D7FA05E8F9@elstel.org> > We use things with varying levels of abstraction. & concrete details are filled in at varying stages. C "long" is NOT specified as having an exact size and does NOT necessarily hold a pointer, and this is ok. > C99 is pretty complete, messy. > For each of 8, 16, 32, 64, > It gives "least", "fast", and "exact" types. And pointer sized. Signed and unsigned. 32 types! * long in C is not guaranteed to hold a pointer by the language definition Though not in the language definition (I believe the language definition of C is simply too old for anticipating all the developments from 8/16bit up to 64bit machines) this has evolved as a de facto standard at least on all x86 up to x86_64 targets as far as I know. Jay, do you know a single arch / target where sizeof(long) != sizeof(void*)? > > Whether types like integer have a language-specified or target-dependent > range is a tough language design question. I have tended to favor a > fixed, language-specified range, but there are pros and cons. I do > think all the time about end-of-range cases and native word size dependencies. > It takes a great deal of care, and I know of no way to design a language > that doesn't, to some extent, trade one set of problems for another. > Signed/unsigned creates similar language dilemmas. * language-specified or target-dependent As I have already suggested I believe there is some justification to have both kinds of type: a language dependent type and a target dependent one The advantages of a language dependent type are rather clear when it comes to mere INTEGERs for numeric/counting/calculation purposes. Once you have a fixed size you can rely on support of a certain value range. Use of the native word size on the other hand should yield better performance at least in the general case. If that question were "either - or" I would clearly favor language specified types. Rewriting certain parts of a program to gain more performance on a special arch is not as bad as a broken program. However if we look into the details at least of 8, 16, 32 and 64bit arches things need to be seen more differentiated: When extending the address range from 8 to 16 and from 16 to 32bit automatically extending the value ranges of integers was a known concern. 65536 (16bit) is not that a high value and we would even have liked to extend most array indices to 32bit as we gained something with the value range while using whole words was also somewhat faster. However things turned out to be very different when the extension from 32bit to 64bit was at stake. There was no more gain by automatically extending the value ranges from 2^32 to 2^64 for 95% of all application purposes while the memory hierarchy has increasingly become a bottle neck in recent time. Additionally doubling the size of all integers would initially have doubled our memory needs which would have been a potential drawback for introducing the AMD64 arch. Just think of a machine with 4GB of RAM: It can not be addressed by 32bit (only ~3GB can) while making all INTS 64bit would have shrunken our memory to an effective size of 2GB. Luckily the decision was taken differently this time: * keep all ints of at most 32bit and just extend pointers to 64bit Elmar P.S.: My next email will start a discussion for all these issues. Am 22.05.2015 um 19:55 schrieb Rodney M. Bates: > This is a worthwhile discussion, but it has very little to do with using > llvm as a back end. In the llvm-IR, sizes of integers, pointers, etc. > are constant numbers. The frontend, whether Clang, CM3, or any other, makes > the decisions about mapping language types like long, INTEGER, pointers, > etc. to a size, target-dependently or otherwise, according to the language's > rules. LLvm does not make these decisions. Its target dependencies are > mostly in the line of different code generators for different instruction sets. > > On 05/22/2015 05:53 AM, Elmar Stellnberger wrote: >> >> Am 22.05.2015 um 12:16 schrieb dirk muysers: >> >>> >> What about the said platform dependencies you have discovered? >>> Not me (I never seriously considered using it), but many people on the llvm >>> forums pointed to the fact. One example among >>> many: >>> >>> Does your C code ever use the 'long' type? If so, the LLVM IR will be >>> different depending on whether it's targeting linux-32 or linux-64. Do >>> you ever use size_t? Same problem. Do you ever use a union containing >>> both pointers and integers? See above. In principle, it's possible to >>> write platform-independent IR, or even C code that compiles to >>> platform-independent IR. In practice, especially if you include any >>> system headers, it's remarkably hard. >>> (Jeffrey Yasskin jyasskin at google.com) >> >> Concerning me I am a very conscientious programmer when it comes to >> make a difference between long, long long and int. I only use long if my >> code requires a data item to be exactly as large as a pointer (in special >> cases also when it comes to tap the power of 64bit machines, f.i. that >> might be either 32/64bit as a base type for arbitrary length integers; >> however not without taking special provisions that will tackle the >> difference in data size. ). Usually aligning the pointers for the next >> structure at the beginning would also solve such an issue when it comes >> to reuse existing code where data sizes may not be changed from long >> either to int or long long without special consideration. Those who use >> glib f.i. additionally have a g[u]int32/64 which they can use instead of int >> / long long though that should at last never make a difference for Intel x86 >> based systems. So when it comes to use int or long long I mostly rely >> on them being either 32 or 64bit. >> I know that most programmers do not care and just always use long which >> I consider to be a particularly bad practice. Even in the Linux kernel they >> have declared "typedef long time_t" instead of "typedef long long time_t" >> which will create an Y2K mess all over in 2038 for all 32bit machines still >> in use then. A somehow bad decision which needs to be changed sooner >> or later even without llvm. >> >> Now let us think of Modula-3. I believe we had a long type for cm3 the last >> time I have seen it. However an equivalent to long long which does also >> exist on 32bit platforms would be an absolute requirement to not break >> things for llvm! Many Thanks for notifying us about this issue, Dirk. >> > > Whether types like integer have a language-specified or target-dependent > range is a tough language design question. I have tended to favor a > fixed, language-specified range, but there are pros and cons. I do > think all the time about end-of-range cases and native word size dependencies. > It takes a great deal of care, and I know of no way to design a language > that doesn't, to some extent, trade one set of problems for another. > Signed/unsigned creates similar language dilemmas. > >> As far as I can see a Modula-3 programmer will need a good core for >> portable programming anyway as we did not even uphold a guarantee for >> WIDECHAR to be either 16 or 32bit. >> > > The evolving nature of first UCS and then Unicode standards has left > many language designers knocked off balance. Critical Mass first > introduced WIDECHAR as 16-bit when that was what everybody thought > was enough. Then things changed, and it wasn't anymore. Right now, > it's a configuration parameter (must be the same for the entire link > closure) in Modula-3. I personally favor making it full Unicode > by default, in the next release, as this is where the world is now. > This is hopefully a simpler problem than INTEGER, etc., because, as of > now, the Unicode committee has emphatically assured us that the range will > *never* increase. We can hope. Am 23.05.2015 um 03:58 schrieb Jay: > We use things with varying levels of abstraction. & concrete details are filled in at varying stages. C "long" is NOT specified as having an exact size and does NOT necessarily hold a pointer, and this is ok. > > > C99 is pretty complete, messy. > For each of 8, 16, 32, 64, > It gives "least", "fast", and "exact" types. And pointer sized. Signed and unsigned. 32 types! > > > INTEGER is always pointer sized. > LONGINT is on all platforms. > > > C# has this feature too. IntPtr & UIntPtr. But C# is dubious -- array indexes are always 32 bit signed. > > > - Jay From mika at async.caltech.edu Wed May 27 18:17:17 2015 From: mika at async.caltech.edu (mika at async.caltech.edu) Date: Wed, 27 May 2015 09:17:17 -0700 Subject: [M3devel] 64bit INTEGERs, WIDECHAR: language specified or configuration/target dependent? In-Reply-To: <6F9B9534-7DC2-4D4D-88CB-90D7FA05E8F9@elstel.org> References: <555E14BC.2040805@lcwb.coop>, <555E203E.4040203@elstel.org> <0A1CDD8C-EEB5-40E2-A38B-28E8EEA8C37E@elstel.org> <8A3AB2ED-C11E-4787-A7F8-C8F12157EAA5@elstel.org> <555F6D8F.4070109@lcwb.coop> <6F9B9534-7DC2-4D4D-88CB-90D7FA05E8F9@elstel.org> Message-ID: <20150527161717.83E761A2065@async.async.caltech.edu> ... >> Whether types like integer have a language-specified or = >target-dependent >> range is a tough language design question. I have tended to favor a >> fixed, language-specified range, but there are pros and cons. I do >> think all the time about end-of-range cases and native word size = >dependencies. >> It takes a great deal of care, and I know of no way to design a = >language >> that doesn't, to some extent, trade one set of problems for another. >> Signed/unsigned creates similar language dilemmas. > >* language-specified or target-dependent >As I have already suggested I believe there is some justification to = >have >both kinds of type: a language dependent type and a target dependent one > >The advantages of a language dependent type are rather clear when it >comes to mere INTEGERs for numeric/counting/calculation purposes. Once >you have a fixed size you can rely on support of a certain value range.=20= Hmm? Modula-3's INTEGERs are the "integers" of mathematics. The intent is that if your implementation is limited and doesn't support a particular operation because it goes out of range, your computation aborts. Same as any other implementation limitation. There is no reason I can think of you couldn't come up with an implementation that has unlimited-range integers. FIRST(INTEGER) and LAST(INTEGER) would have to be a little special. Mika From mika at async.caltech.edu Wed May 27 18:37:36 2015 From: mika at async.caltech.edu (mika at async.caltech.edu) Date: Wed, 27 May 2015 09:37:36 -0700 Subject: [M3devel] 64bit INTEGERs, WIDECHAR: language specified or configuration/target dependent? In-Reply-To: References: <555E14BC.2040805@lcwb.coop>, <555E203E.4040203@elstel.org> <0A1CDD8C-EEB5-40E2-A38B-28E8EEA8C37E@elstel.org> <8A3AB2ED-C11E-4787-A7F8-C8F12157EAA5@elstel.org> <555F6D8F.4070109@lcwb.coop> <6F9B9534-7DC2-4D4D-88CB-90D7FA05E8F9@elstel.org> <20150527161717.83E761A2065@async.async.caltech.edu> Message-ID: <20150527163736.B32DE1A2065@async.async.caltech.edu> Elmar Stellnberger writes: ... >I would have loved it to make INTEGER =3D BITS 32 FOR INTEGER and to = >allow >BITS 64 for INTEGER at the same time. However the way we have already = >gone is >to make LONGINT an own type with an own suffix like floats (the 'l' = >suffix). More >strictly typed and not so bad either.= Ah yes, LONGINT. I remain strongly opposed to that. I think it was a big mistake, it runs completely counter to Modula-3 design philosophy. INTEGERs are integers are integers are integers... fm: Command not found. Mika From estellnb at elstel.org Wed May 27 18:31:42 2015 From: estellnb at elstel.org (Elmar Stellnberger) Date: Wed, 27 May 2015 18:31:42 +0200 Subject: [M3devel] 64bit INTEGERs, WIDECHAR: language specified or configuration/target dependent? In-Reply-To: <20150527161717.83E761A2065@async.async.caltech.edu> References: <555E14BC.2040805@lcwb.coop>, <555E203E.4040203@elstel.org> <0A1CDD8C-EEB5-40E2-A38B-28E8EEA8C37E@elstel.org> <8A3AB2ED-C11E-4787-A7F8-C8F12157EAA5@elstel.org> <555F6D8F.4070109@lcwb.coop> <6F9B9534-7DC2-4D4D-88CB-90D7FA05E8F9@elstel.org> <20150527161717.83E761A2065@async.async.caltech.edu> Message-ID: Am 27.05.2015 um 18:17 schrieb mika at async.caltech.edu: > ... >>> Whether types like integer have a language-specified or = >> target-dependent >>> range is a tough language design question. I have tended to favor a >>> fixed, language-specified range, but there are pros and cons. I do >>> think all the time about end-of-range cases and native word size = >> dependencies. >>> It takes a great deal of care, and I know of no way to design a = >> language >>> that doesn't, to some extent, trade one set of problems for another. >>> Signed/unsigned creates similar language dilemmas. >> >> * language-specified or target-dependent >> As I have already suggested I believe there is some justification to = >> have >> both kinds of type: a language dependent type and a target dependent one >> >> The advantages of a language dependent type are rather clear when it >> comes to mere INTEGERs for numeric/counting/calculation purposes. Once >> you have a fixed size you can rely on support of a certain value range.=20= > > Hmm? > > Modula-3's INTEGERs are the "integers" of mathematics. The intent is > that if your implementation is limited and doesn't support a particular > operation because it goes out of range, your computation aborts. Same > as any other implementation limitation. > > There is no reason I can think of you couldn't come up with an implementation > that has unlimited-range integers. FIRST(INTEGER) and LAST(INTEGER) would have > to be a little special. > > Mika > I would have loved it to make INTEGER = BITS 32 FOR INTEGER and to allow BITS 64 for INTEGER at the same time. However the way we have already gone is to make LONGINT an own type with an own suffix like floats (the 'l' suffix). More strictly typed and not so bad either. From estellnb at elstel.org Wed May 27 18:32:20 2015 From: estellnb at elstel.org (Elmar Stellnberger) Date: Wed, 27 May 2015 18:32:20 +0200 Subject: [M3devel] 64bit INTEGERs, WIDECHAR: language specified or configuration/target dependent? In-Reply-To: <6F9B9534-7DC2-4D4D-88CB-90D7FA05E8F9@elstel.org> References: <555E14BC.2040805@lcwb.coop>, <555E203E.4040203@elstel.org> <0A1CDD8C-EEB5-40E2-A38B-28E8EEA8C37E@elstel.org> <8A3AB2ED-C11E-4787-A7F8-C8F12157EAA5@elstel.org> <555F6D8F.4070109@lcwb.coop> <6F9B9534-7DC2-4D4D-88CB-90D7FA05E8F9@elstel.org> Message-ID: <8BBBC94B-EECC-464A-86BB-FD1C94EC5496@elstel.org> Enough words about the history, now let us see how we can profit from both kinds of types when we wanna step on virgin soil: In what way we may ever turn things there actually needs to be a target sized type which is uses to be unsigned: the pointer. However there needs to be a way to do certain address calculations manually, apart from array indexing: multiply, add, subtract & evtl. shift. I would also believe that it would be handy to have such a type signed. i.e. offset = adress1 - adress2 Naturally such a type will profit from extending its value range to the bit size of pointers. Up to now converting everything to an int has sufficed. However it will no more for a 64bit arch. Will we need to convert to a LONGINT then? - but that will be in- compatible as LONGINT currently takes the 'l'-suffix and longint is not even supported for the 32bit arch as far as I know. Having an own type for this and other purposes like optimized numeric code would to my believe be beneficial. Call it OFFSET, TARGETINT, TargetInt.T or Offset.T Whether to just support such a type by a Word.T like interface or by a built-in type would likely be worth another discussion. So what for now? As I recall things we have introduced a LONGINT which takes the 0l - suffix for AMD64 only. The first thing would be to introduce a 64bit LONGINT for x86/32bit. and then? TYPE Offset.T = BITS BITSIZE(ADDRESS) FOR LONGINT ? We will have to rewrite some code that assumed offsets to be integers, then. The other possibility we have would be to make an offset a built-in type and assignment compatible to both int and longint which will save us from rewriting too much old code. I would claim this not to be a too big problem as converting back and forth between an OFFSET and an [LONG]INT should rarely happen. It would only be used in unsafe interfaces as all address arithmetics i.e. we should at least make that require an explicit conversion outside of unsafe interfaces. That way all expressions remained 100% compatible while only having to declare certain variables as OFFSET rather than INTEGER. > > Am 22.05.2015 um 19:55 schrieb Rodney M. Bates: >> The evolving nature of first UCS and then Unicode standards has left >> many language designers knocked off balance. Critical Mass first >> introduced WIDECHAR as 16-bit when that was what everybody thought >> was enough. Then things changed, and it wasn't anymore. Right now, >> it's a configuration parameter (must be the same for the entire link >> closure) in Modula-3. I personally favor making it full Unicode >> by default, in the next release, as this is where the world is now. >> This is hopefully a simpler problem than INTEGER, etc., because, as of >> now, the Unicode committee has emphatically assured us that the range will >> *never* increase. We can hope. By now I welcome your decision to make the WIDECHAR 32bit! I believe it should become the default for the upcoming release. Pure Modula-3 code will take advantage of the new value range. Just interfacing with certain external toolkits is not enough justification to freeze things as they are - interfaces need to be adapted anyway while supporting all three types is just too much unnecessary work. From hendrik at topoi.pooq.com Wed May 27 18:14:12 2015 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Wed, 27 May 2015 12:14:12 -0400 Subject: [M3devel] 64bit INTEGERs, WIDECHAR: language specified or configuration/target dependent? In-Reply-To: <20150527161717.83E761A2065@async.async.caltech.edu> References: <555E14BC.2040805@lcwb.coop> <555E203E.4040203@elstel.org> <0A1CDD8C-EEB5-40E2-A38B-28E8EEA8C37E@elstel.org> <8A3AB2ED-C11E-4787-A7F8-C8F12157EAA5@elstel.org> <555F6D8F.4070109@lcwb.coop> <6F9B9534-7DC2-4D4D-88CB-90D7FA05E8F9@elstel.org> <20150527161717.83E761A2065@async.async.caltech.edu> Message-ID: <20150527161412.GA18812@topoi.pooq.com> On Wed, May 27, 2015 at 09:17:17AM -0700, mika at async.caltech.edu wrote: > > Hmm? > > Modula-3's INTEGERs are the "integers" of mathematics. The intent is > that if your implementation is limited and doesn't support a particular > operation because it goes out of range, your computation aborts. Same > as any other implementation limitation. > > There is no reason I can think of you couldn't come up with an implementation > that has unlimited-range integers. FIRST(INTEGER) and LAST(INTEGER) would have > to be a little special. That was, in essence, my proposal for LONGINT, not for INTEGER. We still need an integer length that's efficient. I wasn't proposing to change the definition of INTEGER, FIRST(INTEGER), and so forth. But if one had a base tyoe of LONGINT and forbade declaring anything of type LONGINT, you could still have BITS 45 FOR LONGINT and the like. It just happens that the usual arithmetic operations are bounded in nature -- the number of bits in the result are bounded by functions of the numbers of bits in the operands, and an assignment so assigning to variable of could end up truncating, possibly with an overflow check. In fact, one could possibly define INTEGER to be BITS 32 FOR LONGINT, but that might involve further consequences in corrner case in the language. -- hendrik > > Mika From rodney_bates at lcwb.coop Thu May 28 01:30:50 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Wed, 27 May 2015 18:30:50 -0500 Subject: [M3devel] 64bit INTEGERs, WIDECHAR: language specified or configuration/target dependent? In-Reply-To: <20150527161412.GA18812@topoi.pooq.com> References: <555E14BC.2040805@lcwb.coop> <555E203E.4040203@elstel.org> <0A1CDD8C-EEB5-40E2-A38B-28E8EEA8C37E@elstel.org> <8A3AB2ED-C11E-4787-A7F8-C8F12157EAA5@elstel.org> <555F6D8F.4070109@lcwb.coop> <6F9B9534-7DC2-4D4D-88CB-90D7FA05E8F9@elstel.org> <20150527161717.83E761A2065@async.async.caltech.edu> <20150527161412.GA18812@topoi.pooq.com> Message-ID: <556653AA.1010105@lcwb.coop> Once more, with feeling. On 05/27/2015 11:14 AM, Hendrik Boom wrote: > On Wed, May 27, 2015 at 09:17:17AM -0700, mika at async.caltech.edu wrote: >> >> Hmm? >> >> Modula-3's INTEGERs are the "integers" of mathematics. The intent is >> that if your implementation is limited and doesn't support a particular >> operation because it goes out of range, your computation aborts. Same >> as any other implementation limitation. >> >> There is no reason I can think of you couldn't come up with an implementation >> that has unlimited-range integers. FIRST(INTEGER) and LAST(INTEGER) would have >> to be a little special. > > That was, in essence, my proposal for LONGINT, not for INTEGER. > We still need an integer length that's efficient. I wasn't proposing to > change the definition of INTEGER, FIRST(INTEGER), and so forth. > > But if one had a base tyoe of LONGINT and forbade declaring anything of > type LONGINT, you could still have BITS 45 FOR LONGINT and the like. TYPE U = BITS n FOR T *does not change the range of values.* The range of U is the same as that of T. If you try to stuff it into too few bits, e.g., BITS 4 FOR [ 0 .. 255 ], it is a static error. If you try to assign a value outside the value range, it is an error, generally at runtime, even if that value would fit in the bit count. E.g., VAR V : BITS 16 FOR [ 0 .. 255 ] := 256 is illegal. The *only* thing BITS n FOR does is, if legal, affect the amount of storage the compiler allocates, and *only for array elements and fields of RECORDs and OBJECTs*. Look at 2.2.5. > It just happens that the usual arithmetic operations are bounded in > nature -- the number of bits in the result are bounded by functions of > the numbers of bits in the operands, and an assignment so assigning > to variable of could end up truncating, possibly with an overflow > check. > > In fact, one could possibly define INTEGER to be BITS 32 FOR > LONGINT, but that might involve further consequences in corrner > case in the language. > > -- hendrik > >> >> Mika > -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Thu May 28 01:45:02 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Wed, 27 May 2015 18:45:02 -0500 Subject: [M3devel] 64bit INTEGERs, WIDECHAR: language specified or configuration/target dependent? In-Reply-To: <20150527163736.B32DE1A2065@async.async.caltech.edu> References: <555E14BC.2040805@lcwb.coop>, <555E203E.4040203@elstel.org> <0A1CDD8C-EEB5-40E2-A38B-28E8EEA8C37E@elstel.org> <8A3AB2ED-C11E-4787-A7F8-C8F12157EAA5@elstel.org> <555F6D8F.4070109@lcwb.coop> <6F9B9534-7DC2-4D4D-88CB-90D7FA05E8F9@elstel.org> <20150527161717.83E761A2065@async.async.caltech.edu> <20150527163736.B32DE1A2065@async.async.caltech.edu> Message-ID: <556656FE.1020003@lcwb.coop> On 05/27/2015 11:37 AM, mika at async.caltech.edu wrote: > Elmar Stellnberger writes: > ... >> I would have loved it to make INTEGER =3D BITS 32 FOR INTEGER and to = >> allow >> BITS 64 for INTEGER at the same time. However the way we have already = >> gone is >> to make LONGINT an own type with an own suffix like floats (the 'l' = >> suffix). More >> strictly typed and not so bad either.= > > Ah yes, LONGINT. > > I remain strongly opposed to that. I think it was a big mistake, it > runs completely counter to Modula-3 design philosophy. INTEGERs are > integers are integers are integers... fm: Command not found. > > Mika > The purpose of LONGINT is, cases where the program won't work with only 32-bit range, but you want the most efficient arithmetic possible on either a 32-bit or a 64-bit machine, without recoding. The compiler will generate either one-word machine arithmetic if the target has it, or two-word, if not. I suffered through this during the 16/32-bit transition, in Pascal and Modula-2. I had to write source-coded 2-word arithmetic, which would have been OK, if the entire universe didn't' have and never would have 32-bit machines. Instead, it unnecessarily wasted storage and computation when compiled on a 32-bit machine. The source code differences for best efficiency on either were a huge pain. -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Thu May 28 02:23:33 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Wed, 27 May 2015 19:23:33 -0500 Subject: [M3devel] 64bit INTEGERs, WIDECHAR: language specified or configuration/target dependent? In-Reply-To: <8BBBC94B-EECC-464A-86BB-FD1C94EC5496@elstel.org> References: <555E14BC.2040805@lcwb.coop>, <555E203E.4040203@elstel.org> <0A1CDD8C-EEB5-40E2-A38B-28E8EEA8C37E@elstel.org> <8A3AB2ED-C11E-4787-A7F8-C8F12157EAA5@elstel.org> <555F6D8F.4070109@lcwb.coop> <6F9B9534-7DC2-4D4D-88CB-90D7FA05E8F9@elstel.org> <8BBBC94B-EECC-464A-86BB-FD1C94EC5496@elstel.org> Message-ID: <55666005.4080406@lcwb.coop> On 05/27/2015 11:32 AM, Elmar Stellnberger wrote: > Enough words about the history, now let us see how we can profit > from both kinds of types when we wanna step on virgin soil: > > In what way we may ever turn things there actually needs to be > a target sized type which is uses to be unsigned: the pointer. > However there needs to be a way to do certain address > calculations manually, apart from array indexing: > multiply, add, subtract & evtl. shift. > I would also believe that it would be handy to have such a type > signed. > i.e. offset = adress1 - adress2 > > Naturally such a type will profit from extending its value range > to the bit size of pointers. > Up to now converting everything to an int has sufficed. However > it will no more for a 64bit arch. > Will we need to convert to a LONGINT then? - but that will be in- > compatible as LONGINT currently takes the 'l'-suffix and longint > is not even supported for the 32bit arch as far as I know. > > Having an own type for this and other purposes like optimized > numeric code would to my believe be beneficial. > Call it OFFSET, TARGETINT, TargetInt.T or Offset.T > Whether to just support such a type by a Word.T like interface > or by a built-in type would likely be worth another discussion. > Word.T (or Long.T, if INTEGER is smaller than a pointer) should pretty much do what you want. Of course, Word.T = INTEGER and Long.T = LONGINT. But the functions on Word/Long apply unsigned interpretation to the bits, with wraparound. The place you have to be careful is which arithmetic to use when, the builtin operators, or the functions in Word/Long. When I do this kind of arithmetic, I am careful about what variables are declared as INTEGER and what ones Word.T, solely to serve as documentation of whether the value is interpreted as signed or unsigned. With wraparound arithmetic, this distinction seldom or never matters for intermediate results, as long as you are clear about which invariant applies to each operand variable and the result variable. And, you are equally careful to think about the true overflow cases, as they affect the final result--something I doubt many do, even with ordinary, all-signed or all-unsigned arithmetic. > So what for now? As I recall things we have introduced > a LONGINT which takes the 0l - suffix for AMD64 only. No, ... > > The first thing would be to introduce a 64bit LONGINT for x86/32bit. We already have this. From 2.2.1: There are two integer types, which in order of increasing range are \verb|INTEGER| and \verb|LONGINT|. I do have the impression that some Windows targets are not currently in compliance, though. Can anybody elaborate? > > and then? > TYPE Offset.T = BITS BITSIZE(ADDRESS) FOR LONGINT ? > One thing we may not have is a way to make the choice between Word and Long self-adapt to match the size of reference types. BITS won't do it. See my recent post about BITS FOR. It could probably be done in the build system with some quake code. > We will have to rewrite some code that assumed offsets to be > integers, then. > > The other possibility we have would be to make an offset a built-in > type and assignment compatible to both int and longint which will > save us from rewriting too much old code. I would claim this not to > be a too big problem as converting back and forth between an > OFFSET and an [LONG]INT should rarely happen. It would only > be used in unsafe interfaces as all address arithmetics > i.e. we should at least make that require an explicit conversion > outside of unsafe interfaces. That way all expressions remained > 100% compatible while only having to declare certain variables > as OFFSET rather than INTEGER. > > >> >> Am 22.05.2015 um 19:55 schrieb Rodney M. Bates: > >>> The evolving nature of first UCS and then Unicode standards has left >>> many language designers knocked off balance. Critical Mass first >>> introduced WIDECHAR as 16-bit when that was what everybody thought >>> was enough. Then things changed, and it wasn't anymore. Right now, >>> it's a configuration parameter (must be the same for the entire link >>> closure) in Modula-3. I personally favor making it full Unicode >>> by default, in the next release, as this is where the world is now. >>> This is hopefully a simpler problem than INTEGER, etc., because, as of >>> now, the Unicode committee has emphatically assured us that the range will >>> *never* increase. We can hope. > > By now I welcome your decision to make the WIDECHAR 32bit! > I believe it should become the default for the upcoming release. > Pure Modula-3 code will take advantage of the new value range. > Just interfacing with certain external toolkits is not enough > justification to freeze things as they are - interfaces need to be > adapted anyway while supporting all three types is just too much > unnecessary work. > > -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Thu May 28 02:41:35 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Wed, 27 May 2015 19:41:35 -0500 Subject: [M3devel] 64bit INTEGERs, WIDECHAR: language specified or configuration/target dependent? In-Reply-To: <20150527161717.83E761A2065@async.async.caltech.edu> References: <555E14BC.2040805@lcwb.coop>, <555E203E.4040203@elstel.org> <0A1CDD8C-EEB5-40E2-A38B-28E8EEA8C37E@elstel.org> <8A3AB2ED-C11E-4787-A7F8-C8F12157EAA5@elstel.org> <555F6D8F.4070109@lcwb.coop> <6F9B9534-7DC2-4D4D-88CB-90D7FA05E8F9@elstel.org> <20150527161717.83E761A2065@async.async.caltech.edu> Message-ID: <5566643F.3090603@lcwb.coop> On 05/27/2015 11:17 AM, mika at async.caltech.edu wrote: > ... >>> Whether types like integer have a language-specified or = >> target-dependent >>> range is a tough language design question. I have tended to favor a >>> fixed, language-specified range, but there are pros and cons. I do >>> think all the time about end-of-range cases and native word size = >> dependencies. >>> It takes a great deal of care, and I know of no way to design a = >> language >>> that doesn't, to some extent, trade one set of problems for another. >>> Signed/unsigned creates similar language dilemmas. >> >> * language-specified or target-dependent >> As I have already suggested I believe there is some justification to = >> have >> both kinds of type: a language dependent type and a target dependent one >> >> The advantages of a language dependent type are rather clear when it >> comes to mere INTEGERs for numeric/counting/calculation purposes. Once >> you have a fixed size you can rely on support of a certain value range.=20= > > Hmm? > > Modula-3's INTEGERs are the "integers" of mathematics. The intent is > that if your implementation is limited and doesn't support a particular > operation because it goes out of range, your computation aborts. Same > as any other implementation limitation. > > There is no reason I can think of you couldn't come up with an implementation > that has unlimited-range integers. FIRST(INTEGER) and LAST(INTEGER) would have > to be a little special. > We've got it in library code: cm3/m3-libs/arithmetic/src/basictypes/biginteger/BigInteger.i3 Does it need to be improved? I've never used it. But it can't just replace a fixed-sized integer type like INTEGER in a language, because we really need INTEGER for subscripts to the array of INTEGERs that implements BigInteger, and lots of other stuff. For a precedent, mathematicians have never, AFAIK, proposed to generalize the infinite series' used to compute powers and roots by replacing the integer subscripts of the series with rationals, reals, or complexes. What is the Pi'th term in an infinite series? > Mika > -- Rodney Bates rodney.m.bates at acm.org From jay.krell at cornell.edu Thu May 28 07:52:51 2015 From: jay.krell at cornell.edu (Jay K) Date: Thu, 28 May 2015 05:52:51 +0000 Subject: [M3devel] 64bit INTEGERs, WIDECHAR: language specified or configuration/target dependent? In-Reply-To: <77605189-D966-4D4B-8946-838BD6E178AA@purdue.edu> References: <555E14BC.2040805@lcwb.coop> <555E203E.4040203@elstel.org>, , , <0A1CDD8C-EEB5-40E2-A38B-28E8EEA8C37E@elstel.org>, , <8A3AB2ED-C11E-4787-A7F8-C8F12157EAA5@elstel.org>, <555F6D8F.4070109@lcwb.coop>, <6F9B9534-7DC2-4D4D-88CB-90D7FA05E8F9@elstel.org>, <8BBBC94B-EECC-464A-86BB-FD1C94EC5496@elstel.org>, <77605189-D966-4D4B-8946-838BD6E178AA@purdue.edu> Message-ID: I believe the proposal is that INTEGER be more like int in C and C+ -- 32bits always. > I do have the impression that some Windows targets are not currently All targets have a 64bit LONGINT. I implemented this years ago in the NT/x86 backend. The C backend depends on the underlying C compiler having __int64 or long long or a 64bit long. All targets have BYTESIZE(INTEGER) == BYTESIZE(ADDRESS). In C and C++, long is smaller than a pointer on Win64. On Windows, int and long are always 32 bits. This might be the case at least sort of on VMS and HP-UX, at least when the upper bits of 64bit pointers are guaranteed all zeros or all ones or ignored. They have such environments -- 32bit-ish pointers on Alpha, 32bit-ish pointers on IA64. I started writing up more detail. There are obviously 8 underlying integer types: unsigned/signed 8/16/32/64 A typical C99 environment has around 40 names for them: stdint.h: 8+16+32+64 x signed/unsigned x fast+least+exact: 24 short/int/long/long long; unsigned: 8 char/unsigned char/signed char: 3 [u]intptr_t: 2 size_t/ptrdiff_t: 2 wchar_t: 1 => 40 In C++, some of them are distinct for overloading/mangling purposes. Windows has far more, like almost double, for various historical and typographical and stylistic reasons. e.g. INT, UINT, LONG, ULONG, WCHAR, CHAR, UCHAR, BYTE, WORD, DWORD, DWORD_PTR, INT_PTR, UINT_PTR, SIZE_T, HALF_PTR, etc. But still the same underlying 8 types. It can be difficult to chose the right type. It is tempting to discount many of them, and many can be discounted, but it hard to really narrow the list to be small. Should we add some more builtins to the frontend? Like [U]INT[8,16,32,64]? Or lowercase and _t? - Jay > Subject: Re: [M3devel] 64bit INTEGERs, WIDECHAR: language specified or configuration/target dependent? > From: hosking at purdue.edu > Date: Thu, 28 May 2015 05:03:39 +0300 > CC: rodney.m.bates at acm.org; jay.krell at cornell.edu; m3devel at elegosoft.com > To: estellnb at elstel.org > > BYTESIZE(ADDRESS) = BYTESIZE(INTEGER) in cm3 on all target platforms. I don't really understand what you are proposing. > > Sent from my iPhone > > > On May 27, 2015, at 7:32 PM, Elmar Stellnberger wrote: > > > > Enough words about the history, now let us see how we can profit > > from both kinds of types when we wanna step on virgin soil: > > > > In what way we may ever turn things there actually needs to be > > a target sized type which is uses to be unsigned: the pointer. > > However there needs to be a way to do certain address > > calculations manually, apart from array indexing: > > multiply, add, subtract & evtl. shift. > > I would also believe that it would be handy to have such a type > > signed. > > i.e. offset = adress1 - adress2 > > > > Naturally such a type will profit from extending its value range > > to the bit size of pointers. > > Up to now converting everything to an int has sufficed. However > > it will no more for a 64bit arch. > > Will we need to convert to a LONGINT then? - but that will be in- > > compatible as LONGINT currently takes the 'l'-suffix and longint > > is not even supported for the 32bit arch as far as I know. > > > > Having an own type for this and other purposes like optimized > > numeric code would to my believe be beneficial. > > Call it OFFSET, TARGETINT, TargetInt.T or Offset.T > > Whether to just support such a type by a Word.T like interface > > or by a built-in type would likely be worth another discussion. > > > > So what for now? As I recall things we have introduced > > a LONGINT which takes the 0l - suffix for AMD64 only. > > > > The first thing would be to introduce a 64bit LONGINT for x86/32bit. > > > > and then? > > TYPE Offset.T = BITS BITSIZE(ADDRESS) FOR LONGINT ? > > > > We will have to rewrite some code that assumed offsets to be > > integers, then. > > > > The other possibility we have would be to make an offset a built-in > > type and assignment compatible to both int and longint which will > > save us from rewriting too much old code. I would claim this not to > > be a too big problem as converting back and forth between an > > OFFSET and an [LONG]INT should rarely happen. It would only > > be used in unsafe interfaces as all address arithmetics > > i.e. we should at least make that require an explicit conversion > > outside of unsafe interfaces. That way all expressions remained > > 100% compatible while only having to declare certain variables > > as OFFSET rather than INTEGER. > > > > > >> > >> Am 22.05.2015 um 19:55 schrieb Rodney M. Bates: > > > >>> The evolving nature of first UCS and then Unicode standards has left > >>> many language designers knocked off balance. Critical Mass first > >>> introduced WIDECHAR as 16-bit when that was what everybody thought > >>> was enough. Then things changed, and it wasn't anymore. Right now, > >>> it's a configuration parameter (must be the same for the entire link > >>> closure) in Modula-3. I personally favor making it full Unicode > >>> by default, in the next release, as this is where the world is now. > >>> This is hopefully a simpler problem than INTEGER, etc., because, as of > >>> now, the Unicode committee has emphatically assured us that the range will > >>> *never* increase. We can hope. > > > > By now I welcome your decision to make the WIDECHAR 32bit! > > I believe it should become the default for the upcoming release. > > Pure Modula-3 code will take advantage of the new value range. > > Just interfacing with certain external toolkits is not enough > > justification to freeze things as they are - interfaces need to be > > adapted anyway while supporting all three types is just too much > > unnecessary work. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adacore at marino.st Thu May 28 11:50:13 2015 From: adacore at marino.st (John Marino) Date: Thu, 28 May 2015 11:50:13 +0200 Subject: [M3devel] scripts/README obsolete (where is boot-cm3-with-m3.sh ?) Message-ID: <5566E4D5.3070402@marino.st> I just downloaded the current repo at github. the scripts/README hasn't changed, it still talks about boot-cm3-with-m3.sh, but that script is missing now. What has taken its place? I recommend the README be updated because it is wrong now. John From adacore at marino.st Thu May 28 12:23:54 2015 From: adacore at marino.st (John Marino) Date: Thu, 28 May 2015 12:23:54 +0200 Subject: [M3devel] scripts/README obsolete (where is boot-cm3-with-m3.sh ?) In-Reply-To: <5566E4D5.3070402@marino.st> References: <5566E4D5.3070402@marino.st> Message-ID: <5566ECBA.2050006@marino.st> On 5/28/2015 11:50, John Marino wrote: > I just downloaded the current repo at github. > > the scripts/README hasn't changed, it still talks about > boot-cm3-with-m3.sh, but that script is missing now. > > What has taken its place? > > I recommend the README be updated because it is wrong now. > FWIW, I copied boot-cm3-with-m3.sh from 5.8.6 and it seemed to work for a while but when the compiler hit src/TIntN.i3 it blew up. So it appears that the bootstrap (5.8.6) can't build 5.10.0. John From adacore at marino.st Thu May 28 13:12:03 2015 From: adacore at marino.st (John Marino) Date: Thu, 28 May 2015 13:12:03 +0200 Subject: [M3devel] scripts/README obsolete (where is boot-cm3-with-m3.sh ?) In-Reply-To: <5566ECBA.2050006@marino.st> References: <5566E4D5.3070402@marino.st> <5566ECBA.2050006@marino.st> Message-ID: <5566F803.10902@marino.st> On 5/28/2015 12:23, John Marino wrote: > On 5/28/2015 11:50, John Marino wrote: >> I just downloaded the current repo at github. >> >> the scripts/README hasn't changed, it still talks about >> boot-cm3-with-m3.sh, but that script is missing now. >> >> What has taken its place? >> >> I recommend the README be updated because it is wrong now. >> > > FWIW, I copied boot-cm3-with-m3.sh from 5.8.6 and it seemed to work for > a while but when the compiler hit src/TIntN.i3 it blew up. > > So it appears that the bootstrap (5.8.6) can't build 5.10.0. > Searching old messages, I found scripts/python/upgrade.py which seems to be working. The documentation seems to be really behind! John From adacore at marino.st Thu May 28 13:49:04 2015 From: adacore at marino.st (John Marino) Date: Thu, 28 May 2015 13:49:04 +0200 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 Message-ID: <556700B0.8060500@marino.st> I got stuck again trying to build the latest on FreeBSD. 1. tar extracted to working directory along with a bootstrap compiler 2. CM3 and CM3_INSTALL defined in environment 3. executed scripts/python/upgrade.py result: http://leaf.dragonflybsd.org/~marino/m3.log I could guess that something is picking up a bootstrap component instead of a newly built one. I guess it's trying to build the c backend? Am I doing some kind of obvious mistake? John From wagner at elego.de Thu May 28 16:02:21 2015 From: wagner at elego.de (Olaf Wagner) Date: Thu, 28 May 2015 16:02:21 +0200 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <556700B0.8060500@marino.st> References: <556700B0.8060500@marino.st> Message-ID: <20150528160221.95d4c26d83f68f8cfa93d75a@elego.de> On Thu, 28 May 2015 13:49:04 +0200 John Marino wrote: > I got stuck again trying to build the latest on FreeBSD. > > 1. tar extracted to working directory along with a bootstrap compiler > 2. CM3 and CM3_INSTALL defined in environment > 3. executed scripts/python/upgrade.py > > result: > http://leaf.dragonflybsd.org/~marino/m3.log > > I could guess that something is picking up a bootstrap component instead > of a newly built one. I guess it's trying to build the c backend? > > Am I doing some kind of obvious mistake? No. I think upgrade.sh (or .py) cannot really cope with updating a 5.8.6 instance to the current state. It took me several days, too, on MacOS X, and I had to do a lot of manual tweaking and copying around. I don't think any casual user will understand the details :-| IMO the best thing we can do now is provide some more up-to-date binary archives (I'll upload my own stuff as soon as I find the time). A newer release has been missing for several years, and the existing scripts are no great help for new users. Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From adacore at marino.st Thu May 28 16:14:11 2015 From: adacore at marino.st (John Marino) Date: Thu, 28 May 2015 16:14:11 +0200 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <20150528160221.95d4c26d83f68f8cfa93d75a@elego.de> References: <556700B0.8060500@marino.st> <20150528160221.95d4c26d83f68f8cfa93d75a@elego.de> Message-ID: <556722B3.7080209@marino.st> On 5/28/2015 16:02, Olaf Wagner wrote: > On Thu, 28 May 2015 13:49:04 +0200 > John Marino wrote: >> Am I doing some kind of obvious mistake? > > No. I think upgrade.sh (or .py) cannot really cope with updating a 5.8.6 > instance to the current state. It took me several days, too, on > MacOS X, and I had to do a lot of manual tweaking and copying > around. I don't think any casual user will understand the details That's a pretty big sin given how 5.8.6 is the current release! > IMO the best thing we can do now is provide some more up-to-date > binary archives (I'll upload my own stuff as soon as I find the time). > A newer release has been missing for several years, and the existing > scripts are no great help for new users. Is there a git tag that can build from 5.8.6? Maybe I just have to keep doing this until I get a new bootstrap that can do it. John From rodney_bates at lcwb.coop Thu May 28 17:01:21 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 28 May 2015 10:01:21 -0500 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <556700B0.8060500@marino.st> References: <556700B0.8060500@marino.st> Message-ID: <55672DC1.7080509@lcwb.coop> On 05/28/2015 06:49 AM, John Marino wrote: > I got stuck again trying to build the latest on FreeBSD. > > 1. tar extracted to working directory along with a bootstrap compiler > 2. CM3 and CM3_INSTALL defined in environment > 3. executed scripts/python/upgrade.py > > result: > http://leaf.dragonflybsd.org/~marino/m3.log > > I could guess that something is picking up a bootstrap component instead > of a newly built one. Yes. >> m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 means it is trying to compile using a new cm3cg backend and an old cm3 front end. I just added this error message after Olaf had this problem. (Otherwise it would have failed anyway, but with a less informative message.) > I guess it's trying to build the c backend? > It finished the C backend and was trying to build m3core, using the inconsistent compiler. Usually, neither cm3 nor cm3cg is copied to the bin directory, even when doing a ship, in order to avoid this, which is an exception. For all other executables, ship copies them to the bin directory. The shell script scripts/install-cm3-compiler.sh is then run manually, after both cm3 and cm3cg are compiled, to copy them to bin atomically (sort of). I don't know why that happened. I don't have experience with the Python scripts. Jay? Also, this script built the compiler before the support libraries m3core and libm3. I think there may have been one bootstrap scenario where this was the way it needed to be done, but usually it is the other way around--these two libraries first. > Am I doing some kind of obvious mistake? > No, it's a bootstrap barrier. These pop up somewhat regularly. We all usually just build from the most recent development build, which works for getting new things tried out initially. But we need to make a habit of regularly rebuilding from the previous release to flush these out. You might try scripts/do-cm3-front.sh realclean scripts/do-cm3-front.sh buildship (I usually save /usr/local/cm3/bin/cm3 and /usr/local/cm3/bin/cm3cg at this point. The step below does it somewhat redundantly, but only one level, unless the version number changes.) scripts/install-cm3-compiler.sh upgrade. From here, you are using the new compiler. scripts/do-cm3-.sh buildship That this works, starting with the previous release compiler, is my criterion for having removed bootstrap barriers. > John > -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Thu May 28 17:17:08 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 28 May 2015 10:17:08 -0500 Subject: [M3devel] Too many names for the gcc backend. Was: m3cgc1: fatal error ... In-Reply-To: <556700B0.8060500@marino.st> References: <556700B0.8060500@marino.st> Message-ID: <55673174.80804@lcwb.coop> BTW, the gcc-derived back end has too many names. m3cc: The package name m3cg: The directory containing glue code to gcc m3cgc1: The executable built inside m3cc. Also, what it identifies itself as in error messages cm3cg: The executable, when installed in /usr/local/cm3/bin Did I even get it complete or right? On 05/28/2015 06:49 AM, John Marino wrote: > I got stuck again trying to build the latest on FreeBSD. > > 1. tar extracted to working directory along with a bootstrap compiler > 2. CM3 and CM3_INSTALL defined in environment > 3. executed scripts/python/upgrade.py > > result: > http://leaf.dragonflybsd.org/~marino/m3.log > > I could guess that something is picking up a bootstrap component instead > of a newly built one. I guess it's trying to build the c backend? > > Am I doing some kind of obvious mistake? > > John > -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Thu May 28 17:21:47 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 28 May 2015 10:21:47 -0500 Subject: [M3devel] 64bit INTEGERs, WIDECHAR: language specified or configuration/target dependent? In-Reply-To: <77605189-D966-4D4B-8946-838BD6E178AA@purdue.edu> References: <555E14BC.2040805@lcwb.coop> <555E203E.4040203@elstel.org> <0A1CDD8C-EEB5-40E2-A38B-28E8EEA8C37E@elstel.org> <8A3AB2ED-C11E-4787-A7F8-C8F12157EAA5@elstel.org> <555F6D8F.4070109@lcwb.coop> <6F9B9534-7DC2-4D4D-88CB-90D7FA05E8F9@elstel.org> <8BBBC94B-EECC-464A-86BB-FD1C94EC5496@elstel.org> <77605189-D966-4D4B-8946-838BD6E178AA@purdue.edu> Message-ID: <5567328B.70003@lcwb.coop> On 05/27/2015 09:03 PM, Antony Hosking wrote: > BYTESIZE(ADDRESS) = BYTESIZE(INTEGER) in cm3 on all target platforms. I don't really understand what you are proposing. > I am glad to hear that. > Sent from my iPhone > -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Thu May 28 17:23:48 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 28 May 2015 10:23:48 -0500 Subject: [M3devel] 64bit INTEGERs, WIDECHAR: language specified or configuration/target dependent? In-Reply-To: References: <555E14BC.2040805@lcwb.coop> <555E203E.4040203@elstel.org>, , , <0A1CDD8C-EEB5-40E2-A38B-28E8EEA8C37E@elstel.org>, , <8A3AB2ED-C11E-4787-A7F8-C8F12157EAA5@elstel.org>, <555F6D8F.4070109@lcwb.coop>, <6F9B9534-7DC2-4D4D-88CB-90D7FA05E8F9@elstel.org>, <8BBBC94B-EECC-464A-86BB-FD1C94EC5496@elstel.org>, <77605189-D966-4D4B-8946-838BD6E178AA@purdue.edu> Message-ID: <55673304.5090602@lcwb.coop> On 05/28/2015 12:52 AM, Jay K wrote: > I believe the proposal is that INTEGER be more like int in C and C+ -- 32bits always. > > > > I do have the impression that some Windows targets are not currently > > > All targets have a 64bit LONGINT. I implemented this years ago in the NT/x86 backend. Glad to hear that, too. -- Rodney Bates rodney.m.bates at acm.org From adacore at marino.st Thu May 28 17:56:20 2015 From: adacore at marino.st (John Marino) Date: Thu, 28 May 2015 17:56:20 +0200 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <55672DC1.7080509@lcwb.coop> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> Message-ID: <55673AA4.8050100@marino.st> On 5/28/2015 17:01, Rodney M. Bates wrote: > I don't know why that happened. I don't have experience with the > Python scripts. > > Jay? > > Also, this script built the compiler before the support libraries > m3core and libm3. I think there may have been one bootstrap scenario > where this was the way it needed to be done, but usually it is the > other way around--these two libraries first. > >> Am I doing some kind of obvious mistake? >> > No, it's a bootstrap barrier. These pop up somewhat regularly. We > all usually just build from the most recent development build, which > works for getting new things tried out initially. But we need to > make a habit of regularly rebuilding from the previous release to > flush these out. Olaf said, IIUC, that the current code can't be built by the last release compiler. Putting aside that I believe that should be a hard requirement for the project, it sounds like maybe the last release can build it if the build order is fixed (e.g. a better upgrade.py script)? It's not clear to me what the real situation is. > You might try scripts/do-cm3-front.sh realclean > scripts/do-cm3-front.sh buildship > > (I usually save /usr/local/cm3/bin/cm3 and /usr/local/cm3/bin/cm3cg > at this point. The step below does it somewhat redundantly, but only > one level, unless the version number changes.) > > scripts/install-cm3-compiler.sh upgrade. > From here, you are using the new compiler. > scripts/do-cm3-.sh buildship > > That this works, starting with the previous release compiler, is my > criterion for having removed bootstrap barriers. My work takes place within a Makefile and moving things in /usr/local (for example) is actually illegal. Now I could do all this manually for the purpose of building a new bootstrap, but as I mentioned in a previous post, it might be more effective to emulate what you guy have done: essentially build a series of bootstraps at strategic hashes until I've acquired a compiler that can build this (and then use that product as bootstrap for FreeBSD ports). If I did that approach, I could use a hint on the hashes to try... John From jay.krell at cornell.edu Thu May 28 18:16:48 2015 From: jay.krell at cornell.edu (Jay) Date: Thu, 28 May 2015 09:16:48 -0700 Subject: [M3devel] 64bit INTEGERs, WIDECHAR: language specified or configuration/target dependent? In-Reply-To: <20150527161412.GA18812@topoi.pooq.com> References: <555E14BC.2040805@lcwb.coop> <555E203E.4040203@elstel.org> <0A1CDD8C-EEB5-40E2-A38B-28E8EEA8C37E@elstel.org> <8A3AB2ED-C11E-4787-A7F8-C8F12157EAA5@elstel.org> <555F6D8F.4070109@lcwb.coop> <6F9B9534-7DC2-4D4D-88CB-90D7FA05E8F9@elstel.org> <20150527161717.83E761A2065@async.async.caltech.edu> <20150527161412.GA18812@topoi.pooq.com> Message-ID: <11BEF01E-B5F6-4FD3-A7B3-FDEDAD481D42@gmail.com> Arbitrary fixed width integers in the language? Kinda nice. 1. Bits X for integer? Why call it longint? Make the range affected? 2. Once you have operator overloading these language debates fall away and become easier but still non-trivial library debates. Similar thing happens with strings, complex numbers, arrays. Stuff that people like to build into languages because the language can't accommodate writing efficient easy to use libraries. Mutexes too but due to other language features (stack allocated classes with destructors). Even hashtables benefit, from operator[]. Maybe worth evolving the language this way? Name overloading too. e.g. You want String.Plus(char) and String.Plus(string). - Jay On May 27, 2015, at 9:14 AM, Hendrik Boom wrote: > On Wed, May 27, 2015 at 09:17:17AM -0700, mika at async.caltech.edu wrote: >> >> Hmm? >> >> Modula-3's INTEGERs are the "integers" of mathematics. The intent is >> that if your implementation is limited and doesn't support a particular >> operation because it goes out of range, your computation aborts. Same >> as any other implementation limitation. >> >> There is no reason I can think of you couldn't come up with an implementation >> that has unlimited-range integers. FIRST(INTEGER) and LAST(INTEGER) would have >> to be a little special. > > That was, in essence, my proposal for LONGINT, not for INTEGER. > We still need an integer length that's efficient. I wasn't proposing to > change the definition of INTEGER, FIRST(INTEGER), and so forth. > > But if one had a base tyoe of LONGINT and forbade declaring anything of > type LONGINT, you could still have BITS 45 FOR LONGINT and the like. > It just happens that the usual arithmetic operations are bounded in > nature -- the number of bits in the result are bounded by functions of > the numbers of bits in the operands, and an assignment so assigning > to variable of could end up truncating, possibly with an overflow > check. > > In fact, one could possibly define INTEGER to be BITS 32 FOR > LONGINT, but that might involve further consequences in corrner > case in the language. > > -- hendrik > >> >> Mika From wagner at elegosoft.com Thu May 28 19:06:43 2015 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 28 May 2015 19:06:43 +0200 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <55673AA4.8050100@marino.st> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> Message-ID: <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> On Thu, 28 May 2015 17:56:20 +0200 John Marino wrote: > On 5/28/2015 17:01, Rodney M. Bates wrote: > > I don't know why that happened. I don't have experience with the > > Python scripts. > > > > Jay? > > > > Also, this script built the compiler before the support libraries > > m3core and libm3. I think there may have been one bootstrap scenario > > where this was the way it needed to be done, but usually it is the > > other way around--these two libraries first. > > > >> Am I doing some kind of obvious mistake? > >> > > No, it's a bootstrap barrier. These pop up somewhat regularly. We > > all usually just build from the most recent development build, which > > works for getting new things tried out initially. But we need to > > make a habit of regularly rebuilding from the previous release to > > flush these out. > > Olaf said, IIUC, that the current code can't be built by the last > release compiler. Putting aside that I believe that should be a hard > requirement for the project, it sounds like maybe the last release can > build it if the build order is fixed (e.g. a better upgrade.py script)? > It's not clear to me what the real situation is. No, this is a misunderstanding. I just said or tried to say that there is no script (yet) that is smart enough to do all the things necessary to build the current compiler on base of 5.8.6. > > You might try scripts/do-cm3-front.sh realclean > > scripts/do-cm3-front.sh buildship > > > > (I usually save /usr/local/cm3/bin/cm3 and /usr/local/cm3/bin/cm3cg > > at this point. The step below does it somewhat redundantly, but only > > one level, unless the version number changes.) > > > > scripts/install-cm3-compiler.sh upgrade. > > From here, you are using the new compiler. > > scripts/do-cm3-.sh buildship > > > > That this works, starting with the previous release compiler, is my > > criterion for having removed bootstrap barriers. Rodney, have you really tried that? I'm not sure the steps above will work. I had the feeling that we're missing some intermediate releases, but I might be wrong there. > My work takes place within a Makefile and moving things in /usr/local > (for example) is actually illegal. Now I could do all this manually for > the purpose of building a new bootstrap, but as I mentioned in a > previous post, it might be more effective to emulate what you guy have > done: essentially build a series of bootstraps at strategic hashes until > I've acquired a compiler that can build this (and then use that product > as bootstrap for FreeBSD ports). > > If I did that approach, I could use a hint on the hashes to try... We should be able to script something that sets up the current compiler at least on a given specific platform with a well-defined environment. I might be able to offer more help in the second week of June, if you can wait until then. Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Thu May 28 19:12:19 2015 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 28 May 2015 19:12:19 +0200 Subject: [M3devel] Too many names for the gcc backend. Was: m3cgc1: fatal error ... In-Reply-To: <55673174.80804@lcwb.coop> References: <556700B0.8060500@marino.st> <55673174.80804@lcwb.coop> Message-ID: <20150528191219.2718dd20002b3678121306c9@elegosoft.com> On Thu, 28 May 2015 10:17:08 -0500 "Rodney M. Bates" wrote: > BTW, the gcc-derived back end has too many names. > > m3cc: The package name > m3cg: The directory containing glue code to gcc > m3cgc1: The executable built inside m3cc. > Also, what it identifies itself as in error messages > cm3cg: The executable, when installed in /usr/local/cm3/bin > > Did I even get it complete or right? Yes. It's all due to historical reasons, IIRC. m3cgc1 was the name in the PM3 distribution, and Critical Mass used the cm3cg name. I never changed any of the names intentionally, though I should perhaps have done that, when we made the open source release of the CM3 code base. Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From estellnb at elstel.org Thu May 28 19:46:12 2015 From: estellnb at elstel.org (Elmar Stellnberger) Date: Thu, 28 May 2015 19:46:12 +0200 Subject: [M3devel] 64bit INTEGERs, WIDECHAR: language specified or configuration/target dependent? In-Reply-To: <77605189-D966-4D4B-8946-838BD6E178AA@purdue.edu> References: <555E14BC.2040805@lcwb.coop> <555E203E.4040203@elstel.org> <0A1CDD8C-EEB5-40E2-A38B-28E8EEA8C37E@elstel.org> <8A3AB2ED-C11E-4787-A7F8-C8F12157EAA5@elstel.org> <555F6D8F.4070109@lcwb.coop> <6F9B9534-7DC2-4D4D-88CB-90D7FA05E8F9@elstel.org> <8BBBC94B-EECC-464A-86BB-FD1C94EC5496@elstel.org> <77605189-D966-4D4B-8946-838BD6E178AA@purdue.edu> Message-ID: <55675464.5090306@elstel.org> Am 28.05.15 um 04:03 schrieb Antony Hosking: > BYTESIZE(ADDRESS) = BYTESIZE(INTEGER) in cm3 on all target platforms. I don't really understand what you are proposing. > on AMD64: BITSIZE(INTEGER) = BITSIZE(LONGINT) = 64bit I have just noticed that and when taking a practical standpoint - i.e. what really matters to new and old programs - this is a really bad decision which I wish to change for the next release. If you have not examined it yet please reclaim the design decisions for leaving int 32bit in C: /However things turned out to be very different when the extension from 32bit to 64bit was at stake. There was no more gain by automatically extending the value ranges from 2^32 to 2^64 for 95% of all application purposes while the memory hierarchy has increasingly become a bottle neck in recent time. Additionally doubling the size of all integers would initially have doubled our memory needs which would have been a potential drawback for introducing the AMD64 arch. Just think of a machine with 4GB of RAM: It can not be addressed by 32bit (only ~3GB can) while making all INTS 64bit would have shrunken our memory to an effective size of 2GB. Luckily the decision was taken differently this time: * keep all ints of at most 32bit and just extend pointers to 64bit / Same reasoning applies to Modula-3. - and I believe you have failed to notice when making your decisions for cm3 5.8.6. Or do you want to tell me that Modula-3 developers are more prudent than the C/C++ community? Even worse I have discovered the following: BITS 8 FOR INTEGER and BITS 32 FOR INTEGER do not work with cm3 5.8.6: :: BITS FOR size too small, must be at least (64) That will break existing legacy code when trying to compile it with cm3 5.8.6. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Thu May 28 16:18:11 2015 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Thu, 28 May 2015 10:18:11 -0400 Subject: [M3devel] 64bit INTEGERs, WIDECHAR: language specified or configuration/target dependent? In-Reply-To: <556653AA.1010105@lcwb.coop> References: <0A1CDD8C-EEB5-40E2-A38B-28E8EEA8C37E@elstel.org> <8A3AB2ED-C11E-4787-A7F8-C8F12157EAA5@elstel.org> <555F6D8F.4070109@lcwb.coop> <6F9B9534-7DC2-4D4D-88CB-90D7FA05E8F9@elstel.org> <20150527161717.83E761A2065@async.async.caltech.edu> <20150527161412.GA18812@topoi.pooq.com> <556653AA.1010105@lcwb.coop> Message-ID: <20150528141810.GA19285@topoi.pooq.com> On Wed, May 27, 2015 at 06:30:50PM -0500, Rodney M. Bates wrote: > Once more, with feeling. > > On 05/27/2015 11:14 AM, Hendrik Boom wrote: > >On Wed, May 27, 2015 at 09:17:17AM -0700, mika at async.caltech.edu wrote: > >> > >>Hmm? > >> > >>Modula-3's INTEGERs are the "integers" of mathematics. The intent is > >>that if your implementation is limited and doesn't support a particular > >>operation because it goes out of range, your computation aborts. Same > >>as any other implementation limitation. > >> > >>There is no reason I can think of you couldn't come up with an implementation > >>that has unlimited-range integers. FIRST(INTEGER) and LAST(INTEGER) would have > >>to be a little special. > > > >That was, in essence, my proposal for LONGINT, not for INTEGER. > >We still need an integer length that's efficient. I wasn't proposing to > >change the definition of INTEGER, FIRST(INTEGER), and so forth. > > > >But if one had a base tyoe of LONGINT and forbade declaring anything of > >type LONGINT, you could still have BITS 45 FOR LONGINT and the like. I should probably have said something like -2^44-1 .. 2^44, or whatever those numbers are when spelled out in decimal. Of course the syntax for this might still have to indicate LONGINT somehow, because I'd have doubts about the base type depending on the size of the numbers I coded. The base type affects a lot of assumptions about things like the default subscript type for dynamic arrays and the like. > > TYPE U = BITS n FOR T *does not change the range of values.* The range > of U is the same as that of T. WHich is why I should have used a range instead of a number of bits. > > If you try to stuff it into too few bits, e.g., BITS 4 FOR [ 0 .. 255 ], > it is a static error. > > If you try to assign a value outside the value range, it is an error, > generally at runtime, even if that value would fit in the bit count. > E.g., VAR V : BITS 16 FOR [ 0 .. 255 ] := 256 is illegal. > > The *only* thing BITS n FOR does is, if legal, affect the amount of > storage the compiler allocates, and *only for array elements and > fields of RECORDs and OBJECTs*. ... > > > >In fact, one could possibly define INTEGER to be BITS 32 FOR > >LONGINT, but that might involve further consequences in corrner > >case in the language. > > > >-- hendrik > > > >> > >> Mika > > > > -- > Rodney Bates > rodney.m.bates at acm.org From hendrik at topoi.pooq.com Thu May 28 16:21:58 2015 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Thu, 28 May 2015 10:21:58 -0400 Subject: [M3devel] 64bit INTEGERs, WIDECHAR: language specified or configuration/target dependent? In-Reply-To: <55675464.5090306@elstel.org> References: <0A1CDD8C-EEB5-40E2-A38B-28E8EEA8C37E@elstel.org> <8A3AB2ED-C11E-4787-A7F8-C8F12157EAA5@elstel.org> <555F6D8F.4070109@lcwb.coop> <6F9B9534-7DC2-4D4D-88CB-90D7FA05E8F9@elstel.org> <8BBBC94B-EECC-464A-86BB-FD1C94EC5496@elstel.org> <77605189-D966-4D4B-8946-838BD6E178AA@purdue.edu> <55675464.5090306@elstel.org> Message-ID: <20150528142158.GB19285@topoi.pooq.com> On Thu, May 28, 2015 at 07:46:12PM +0200, Elmar Stellnberger wrote: > Am 28.05.15 um 04:03 schrieb Antony Hosking: > >BYTESIZE(ADDRESS) = BYTESIZE(INTEGER) in cm3 on all target platforms. I don't really understand what you are proposing. > > > on AMD64: BITSIZE(INTEGER) = BITSIZE(LONGINT) = 64bit > > I have just noticed that and when taking a practical standpoint - > i.e. what really matters to new and old programs - > this is a really bad decision which I wish to change for the next release. > > If you have not examined it yet please reclaim the design decisions > for leaving int 32bit in C: > > /However things turned out to be very different when the extension from > 32bit to 64bit was at stake. There was no more gain by automatically > extending the value ranges from 2^32 to 2^64 for 95% of all application > purposes while the memory hierarchy has increasingly become a bottle > neck in recent time. Additionally doubling the size of all integers would > initially have doubled our memory needs which would have been a > potential drawback for introducing the AMD64 arch. Just think of a machine > with 4GB of RAM: It can not be addressed by 32bit (only ~3GB can) while > making all INTS 64bit would have shrunken our memory to an effective size > of 2GB. Luckily the decision was taken differently this time: > > * keep all ints of at most 32bit and just extend pointers to 64bit > / > > Same reasoning applies to Modula-3. - and I believe you have failed > to notice when > making your decisions for cm3 5.8.6. Or do you want to tell me that > Modula-3 > developers are more prudent than the C/C++ community? > > Even worse I have discovered the following: > BITS 8 FOR INTEGER and BITS 32 FOR INTEGER do not work with cm3 5.8.6: As I understand it from Rodney Bates' reply to my recent post, BITS 8 FOR INTEGER should never have worked. BITS 32 FOR INTEGER should work only if INTEGER is 32 bits wide. > > :: BITS FOR size too small, must be at least (64) > > That will break existing legacy code when trying to compile it with > cm3 5.8.6. From adacore at marino.st Thu May 28 21:13:44 2015 From: adacore at marino.st (John Marino) Date: Thu, 28 May 2015 21:13:44 +0200 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> Message-ID: <556768E8.10107@marino.st> On 5/28/2015 19:06, Olaf Wagner wrote: > On Thu, 28 May 2015 17:56:20 +0200 > John Marino wrote: >> If I did that approach, I could use a hint on the hashes to try... > > We should be able to script something that sets up the current compiler > at least on a given specific platform with a well-defined environment. > I might be able to offer more help in the second week of June, if you > can wait until then. I honestly don't know if I can. In general I have a zillion irons in the fire (it's taken almost 18 months to cycle back to M3) and this is not a normal summer. What I'm saying is, if it's done mid-June, it could be Christmas before I take advantage of it. Or not. One never knows. John From estellnb at elstel.org Thu May 28 21:53:33 2015 From: estellnb at elstel.org (Elmar Stellnberger) Date: Thu, 28 May 2015 21:53:33 +0200 Subject: [M3devel] 64bit INTEGERs, WIDECHAR: language specified or configuration/target dependent? In-Reply-To: <55675464.5090306@elstel.org> References: <555E14BC.2040805@lcwb.coop> <555E203E.4040203@elstel.org> <0A1CDD8C-EEB5-40E2-A38B-28E8EEA8C37E@elstel.org> <8A3AB2ED-C11E-4787-A7F8-C8F12157EAA5@elstel.org> <555F6D8F.4070109@lcwb.coop> <6F9B9534-7DC2-4D4D-88CB-90D7FA05E8F9@elstel.org> <8BBBC94B-EECC-464A-86BB-FD1C94EC5496@elstel.org> <77605189-D966-4D4B-8946-838BD6E178AA@purdue.edu> <55675464.5090306@elstel.org> Message-ID: <5567723D.3020706@elstel.org> How for the hell do you interface with operating system services requiring a 32bit int when you only have the 64bit INTEGER?? Am 28.05.15 um 19:46 schrieb Elmar Stellnberger: > Am 28.05.15 um 04:03 schrieb Antony Hosking: >> BYTESIZE(ADDRESS) = BYTESIZE(INTEGER) in cm3 on all target platforms. I don't really understand what you are proposing. >> > on AMD64: BITSIZE(INTEGER) = BITSIZE(LONGINT) = 64bit > > I have just noticed that and when taking a practical standpoint - i.e. > what really matters to new and old programs - > this is a really bad decision which I wish to change for the next release. > > If you have not examined it yet please reclaim the design decisions > for leaving int 32bit in C: > /However things turned out to be very different when the extension from > 32bit to 64bit was at stake. There was no more gain by automatically > extending the value ranges from 2^32 to 2^64 for 95% of all application > purposes while the memory hierarchy has increasingly become a bottle > neck in recent time. Additionally doubling the size of all integers would > initially have doubled our memory needs which would have been a > potential drawback for introducing the AMD64 arch. Just think of a machine > with 4GB of RAM: It can not be addressed by 32bit (only ~3GB can) while > making all INTS 64bit would have shrunken our memory to an effective size > of 2GB. Luckily the decision was taken differently this time: > > * keep all ints of at most 32bit and just extend pointers to 64bit > / > Same reasoning applies to Modula-3. - and I believe you have failed > to notice when > making your decisions for cm3 5.8.6. Or do you want to tell me that > Modula-3 > developers are more prudent than the C/C++ community? > > Even worse I have discovered the following: > BITS 8 FOR INTEGER and BITS 32 FOR INTEGER do not work with cm3 5.8.6: > > :: BITS FOR size too small, must be at least (64) > > That will break existing legacy code when trying to compile it with > cm3 5.8.6. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu May 28 22:14:49 2015 From: jay.krell at cornell.edu (Jay K) Date: Thu, 28 May 2015 20:14:49 +0000 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <55672DC1.7080509@lcwb.coop> References: <556700B0.8060500@marino.st>,<55672DC1.7080509@lcwb.coop> Message-ID: > Also, this script built the compiler before the support libraries m3core and > libm3. I think there may have been one bootstrap scenario where this was the > way it needed to be done, but usually it is the other way around--these two > libraries first. This is very deliberate and should always work, when doing a native upgrade. It is true it is not always required. When doing a "clean" cross build, it is true that it is backwards. It is required when upgrading from an older build. Native upgrades start at least with a working compiler and its matching runtime. Cross builds start with a working host compiler and nothing for the target -- so they do start with m3core. The idea that people don't get right away is that the compiler and runtime are very coupled. A compiler targets a particular runtime. Its output requires a certain runtime. Look at RT0.i3 in particular. We haven't changed that in over 10 years, but Critical Mass did. For example. Or if you change the size of WIDECHAR. The compiler outputs data that the garbage collector uses. The compiler outputs function calls that are to functions in m3core. The coupling to libm3 is less clear to me, but the coupling to m3core is significant. m3core is kind of the lowest level runtime that compiler pretty much unavoidably requires to be with its output. Perhaps if you write code w/o any traced types and without try/finally or raise, you can avoid m3core. But there is still module initialization and running "main". So m3core is unavoidable. In the Unix world, consider like crtstart.o. In the Windows world, consider that main is called from mainCRTStartup and this is like wherever that is. (Or DllMain is called from DllMainCRTSTartup, WinMain is called from WinMainCRTStartup, etc. There is an analog between DllMain and the entry points of each module other than Main.) libm3 is more a convenience library that you can maybe possibly do without. Consider this, like, not the startup code, but stdio, stdlib, STL, etc. Another dependency people don't understand is between the frontend and the backend. The gcc backend in particular. When you change the "M3CG", the persisted IR, these two have to be updated together. Again, these things don't change much, so we get away without worrying about and without automating it and without people understanding it. We changed this, for example, when the atomics were added. I think I made changes too. I believe I automated this, but then wimped out and commented out one line. I'll report back later on this. I didn't want to diverge from the shell scripts, perhaps. I'll try to find some time here. I agree an upgrade from 5.8.6 to current is desirable. I go back and forth on this. I have likely broken it, and fixed it. For example, the mklib dependency on the Win32 headers. That should be ok now. For another potential example, the frontend can't use LONGINT until a release has it. But I think we have that now. We do not support going arbitrarily back, but the previous release is a good target. I have at times gone further back and fixed things up. You can also bootstrap via the cross mechanism even if you aren't crossing, but I suppose that is too difficult. Here: https://github.com/modula3/cm3/blob/master/scripts/python/upgrade.py 51 # 52 # ... and continue with the backend, if needed 53 # 54 55 a = Root + "/m3-sys/m3cggen/" + Target + "/m3cggen > " + Root + "/m3-sys/m3cc/gcc/gcc/m3cg/m3cg.h" 56 print(a) 57 # os.system(a) 58 FilterPackages([ "m3cc" ]) and DoPackage(argv_BuildShip, [ "m3cc" ]) uncomment out line 57. That is where I wimped out. That line should be there. Hopefully it is still correct.It is a little gross in that it outputs into the source tree.This really shouldn't be needed if you build correctly from a consistent checkout. It is only for when you have local edits.Even bootstrap/upgrade should not require it. The output should just match what is already there. And another thing: When I wrote upgrade.py, I thought I was mimicking upgrade.sh, and I mostly was. One thing I missed though was that upgrade.sh does actually build the entire system, whereas upgrade.py only builds the compiler. So consider this, somewhat overkill instead: cd scripts ./upgrade.py && ./do-cm3-all.py realclean skipgcc && ./do-cm3-all buildship skipgcc Also note that in-place updates are done while it goes. Certain errors force a need to go backwards. So you should maintain a backup of the minimum -- cm3, cm3.cfg, config directory, m3core, libm3, cm3cg. Or be able to restore from a release. That list is important, so I'll repeat: cm3, cm3.cfg, config directory in newer releases (cm3.cfg delegages to it), m3core, libm3, cm3cg (optional). To put this another way: consider the compiler itself to be a very portable and minimalist Modula-3 program. It has few dependencies and does most things itself. Consider the C program that just uses very little of the standard library but does use printf("main"). What do you need to build such things? You don't need, you know, a marshaling library, a windowing library etc., but you need a working compiler, frontend, backend, assembler, linker, and a minimal library That is what is required to a native upgrade. - Jay > Date: Thu, 28 May 2015 10:01:21 -0500 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > > > On 05/28/2015 06:49 AM, John Marino wrote: > > I got stuck again trying to build the latest on FreeBSD. > > > > 1. tar extracted to working directory along with a bootstrap compiler > > 2. CM3 and CM3_INSTALL defined in environment > > 3. executed scripts/python/upgrade.py > > > > result: > > http://leaf.dragonflybsd.org/~marino/m3.log > > > > I could guess that something is picking up a bootstrap component instead > > of a newly built one. > > Yes. > > >> m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > > means it is trying to compile using a new cm3cg backend and an old cm3 front end. > I just added this error message after Olaf had this problem. (Otherwise it would > have failed anyway, but with a less informative message.) > > > I guess it's trying to build the c backend? > > > > It finished the C backend and was trying to build m3core, using the inconsistent > compiler. Usually, neither cm3 nor cm3cg is copied to the bin directory, > even when doing a ship, in order to avoid this, which is an exception. For all > other executables, ship copies them to the bin directory. The shell script > scripts/install-cm3-compiler.sh is then run manually, after both cm3 and cm3cg > are compiled, to copy them to bin atomically (sort of). > > I don't know why that happened. I don't have experience with the Python scripts. > > Jay? > > Also, this script built the compiler before the support libraries m3core and > libm3. I think there may have been one bootstrap scenario where this was the > way it needed to be done, but usually it is the other way around--these two > libraries first. > > > > Am I doing some kind of obvious mistake? > > > > No, it's a bootstrap barrier. These pop up somewhat regularly. We all usually > just build from the most recent development build, which works for getting new > things tried out initially. But we need to make a habit of regularly rebuilding > from the previous release to flush these out. > > You might try scripts/do-cm3-front.sh realclean > scripts/do-cm3-front.sh buildship > > (I usually save /usr/local/cm3/bin/cm3 and /usr/local/cm3/bin/cm3cg at this point. > The step below does it somewhat redundantly, but only one level, unless the > version number changes.) > > scripts/install-cm3-compiler.sh upgrade. > > From here, you are using the new compiler. > > scripts/do-cm3-.sh buildship > > That this works, starting with the previous release compiler, is my criterion > for having removed bootstrap barriers. > > > > > John > > > > -- > Rodney Bates > rodney.m.bates at acm.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu May 28 22:13:24 2015 From: jay.krell at cornell.edu (Jay K) Date: Thu, 28 May 2015 20:13:24 +0000 Subject: [M3devel] 64bit INTEGERs, WIDECHAR: language specified or configuration/target dependent? In-Reply-To: <5567723D.3020706@elstel.org> References: <555E14BC.2040805@lcwb.coop> <555E203E.4040203@elstel.org>, , , <0A1CDD8C-EEB5-40E2-A38B-28E8EEA8C37E@elstel.org>, , <8A3AB2ED-C11E-4787-A7F8-C8F12157EAA5@elstel.org>, <555F6D8F.4070109@lcwb.coop>, <6F9B9534-7DC2-4D4D-88CB-90D7FA05E8F9@elstel.org>, <8BBBC94B-EECC-464A-86BB-FD1C94EC5496@elstel.org>, <77605189-D966-4D4B-8946-838BD6E178AA@purdue.edu>, <55675464.5090306@elstel.org>, <5567723D.3020706@elstel.org> Message-ID: 1) Ctypes.int 2) I wrapped everything anyway because the rewriting of /usr/include in m3core/unix was terribly tedious and error prone and a frequent source of problems.I favor size_t/INTEGER. The "direct" calls were not worth the trouble. I've debugged enough stack corruptions due to getting struct stat wrong there. 3) But not always, the Win32 and X windows stuff is still direct. INTEGER is not the only integer type, it is just kinda the default easiest to use if you must use one, use it.If you want to think more about it, there are more options. The 8 underlying types are all in there -- 8/16/32/64 unsigned and signed.Perhaps they should be exposes differently, like as INT8, UINT8, INT16, UINT16, INT32, UINT32, INT64, UINT64?Or int8_t, uint8_t, int16_t, uint16_t, etc.? Those types are all available to all programs, albeit in the WinNT and cstdint modules I believe. Not "global" like INTEGER. - Jay Date: Thu, 28 May 2015 21:53:33 +0200 From: estellnb at elstel.org To: hosking at purdue.edu CC: m3devel at elegosoft.com; jay.krell at cornell.edu; rodney.m.bates at acm.org Subject: Re: [M3devel] 64bit INTEGERs, WIDECHAR: language specified or configuration/target dependent? How for the hell do you interface with operating system services requiring a 32bit int when you only have the 64bit INTEGER?? Am 28.05.15 um 19:46 schrieb Elmar Stellnberger: Am 28.05.15 um 04:03 schrieb Antony Hosking: BYTESIZE(ADDRESS) = BYTESIZE(INTEGER) in cm3 on all target platforms. I don't really understand what you are proposing. on AMD64: BITSIZE(INTEGER) = BITSIZE(LONGINT) = 64bit I have just noticed that and when taking a practical standpoint - i.e. what really matters to new and old programs - this is a really bad decision which I wish to change for the next release. If you have not examined it yet please reclaim the design decisions for leaving int 32bit in C: However things turned out to be very different when the extension from 32bit to 64bit was at stake. There was no more gain by automatically extending the value ranges from 2^32 to 2^64 for 95% of all application purposes while the memory hierarchy has increasingly become a bottle neck in recent time. Additionally doubling the size of all integers would initially have doubled our memory needs which would have been a potential drawback for introducing the AMD64 arch. Just think of a machine with 4GB of RAM: It can not be addressed by 32bit (only ~3GB can) while making all INTS 64bit would have shrunken our memory to an effective size of 2GB. Luckily the decision was taken differently this time: * keep all ints of at most 32bit and just extend pointers to 64bit Same reasoning applies to Modula-3. - and I believe you have failed to notice when making your decisions for cm3 5.8.6. Or do you want to tell me that Modula-3 developers are more prudent than the C/C++ community? Even worse I have discovered the following: BITS 8 FOR INTEGER and BITS 32 FOR INTEGER do not work with cm3 5.8.6: :: BITS FOR size too small, must be at least (64) That will break existing legacy code when trying to compile it with cm3 5.8.6. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu May 28 22:29:44 2015 From: jay.krell at cornell.edu (Jay K) Date: Thu, 28 May 2015 20:29:44 +0000 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <55673AA4.8050100@marino.st> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop>,<55673AA4.8050100@marino.st> Message-ID: The build order in upgrade.py is correct. Since it is deliberately starting with whatever cm3 the user already has,it must also start deliberately with whatever m3core and libm3 the user already has.They go together. It builds a cm3 that uses the old m3core/libm3 (statically linked),and then rebuilds everything with itself, starting from m3core."everything" being only up to cm3/mklib, not the gui stuff, for example. Really in the past I've used this stuff a lot and I use the unedited checked in copy.There could be a problem building from the latest release, and that we should fix.The problem will likely be in m3front/m3back/m3link/m3quake, etc. The scripts should already be ok. The in-place nature of upgrade.py is perhaps not ideal. Esp. when it doesn't work.make-dist.py may be preferable. - Jay > Date: Thu, 28 May 2015 17:56:20 +0200 > From: adacore at marino.st > To: rodney.m.bates at acm.org; m3devel at elegosoft.com > Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > > On 5/28/2015 17:01, Rodney M. Bates wrote: > > I don't know why that happened. I don't have experience with the > > Python scripts. > > > > Jay? > > > > Also, this script built the compiler before the support libraries > > m3core and libm3. I think there may have been one bootstrap scenario > > where this was the way it needed to be done, but usually it is the > > other way around--these two libraries first. > > > >> Am I doing some kind of obvious mistake? > >> > > No, it's a bootstrap barrier. These pop up somewhat regularly. We > > all usually just build from the most recent development build, which > > works for getting new things tried out initially. But we need to > > make a habit of regularly rebuilding from the previous release to > > flush these out. > > Olaf said, IIUC, that the current code can't be built by the last > release compiler. Putting aside that I believe that should be a hard > requirement for the project, it sounds like maybe the last release can > build it if the build order is fixed (e.g. a better upgrade.py script)? > It's not clear to me what the real situation is. > > > > You might try scripts/do-cm3-front.sh realclean > > scripts/do-cm3-front.sh buildship > > > > (I usually save /usr/local/cm3/bin/cm3 and /usr/local/cm3/bin/cm3cg > > at this point. The step below does it somewhat redundantly, but only > > one level, unless the version number changes.) > > > > scripts/install-cm3-compiler.sh upgrade. > > From here, you are using the new compiler. > > scripts/do-cm3-.sh buildship > > > > That this works, starting with the previous release compiler, is my > > criterion for having removed bootstrap barriers. > > My work takes place within a Makefile and moving things in /usr/local > (for example) is actually illegal. Now I could do all this manually for > the purpose of building a new bootstrap, but as I mentioned in a > previous post, it might be more effective to emulate what you guy have > done: essentially build a series of bootstraps at strategic hashes until > I've acquired a compiler that can build this (and then use that product > as bootstrap for FreeBSD ports). > > If I did that approach, I could use a hint on the hashes to try... > > John -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu May 28 22:24:14 2015 From: jay.krell at cornell.edu (Jay K) Date: Thu, 28 May 2015 20:24:14 +0000 Subject: [M3devel] Too many names for the gcc backend. Was: m3cgc1: fatal error ... In-Reply-To: <55673174.80804@lcwb.coop> References: <556700B0.8060500@marino.st>,<55673174.80804@lcwb.coop> Message-ID: "1" is because gcc is structured as having the gcc "driver" and "frontends" like cc1 and cc1plus.cm3cg is a frontend from the gcc point of view. So it has/had a "1" in iis name.I believe we rename from m3cgc1 to cm3cg.The gcc backends are always linked into the frontends anyway -- libbackend.a.If this wasn't the case, they'd probably be called things like cc2. With Visual C++, for example, the "driver" is cl.exe and the frontends are c1.dll and c1xx.dll and the backend is c2.dll.Most compilers are structured in about the same way. Your .log: --- building in AMD64_FREEBSD --- ignoring ../src/m3overrides new source -> compiling RTHooks.i3 m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 compilation terminated. m3_backend => 1 > cp -Pv /mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a/m3-sys/cminstall/src/config-no-install/ALPHA32_VMS /mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a/bin/config/ALPHA32_VMS I think the problem is that upgrade wants to do things in-place, but you have asked to ship/install to a new place.It kind of does install while it builds. make-dist.py kinda does this better. It builds into a new place, but first copies from the old. Can you do that? Or, similarly, if you are building into a new empty place, can you add it to the start of $PATH, so as it fills in, it will take precedence? I understand this is all not ideal. The default method of "ugprade.py" building should be more like make-dist. The result should be a directory or .tar.gz that the user is told to copy or extract. No in-place updates ought to be done. make-dist.py is really better. Or, can you try make-dist.py?? Maybe if people use that a bit, we can delete upgrade and just point people at make-dist.py instead.It does "min" and "all". - Jay > Date: Thu, 28 May 2015 10:17:08 -0500 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: [M3devel] Too many names for the gcc backend. Was: m3cgc1: fatal error ... > > BTW, the gcc-derived back end has too many names. > > m3cc: The package name > m3cg: The directory containing glue code to gcc > m3cgc1: The executable built inside m3cc. > Also, what it identifies itself as in error messages > cm3cg: The executable, when installed in /usr/local/cm3/bin > > Did I even get it complete or right? > > On 05/28/2015 06:49 AM, John Marino wrote: > > I got stuck again trying to build the latest on FreeBSD. > > > > 1. tar extracted to working directory along with a bootstrap compiler > > 2. CM3 and CM3_INSTALL defined in environment > > 3. executed scripts/python/upgrade.py > > > > result: > > http://leaf.dragonflybsd.org/~marino/m3.log > > > > I could guess that something is picking up a bootstrap component instead > > of a newly built one. I guess it's trying to build the c backend? > > > > Am I doing some kind of obvious mistake? > > > > John > > > > -- > Rodney Bates > rodney.m.bates at acm.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Thu May 28 23:05:54 2015 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 28 May 2015 23:05:54 +0200 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> Message-ID: <20150528230554.80920c53f002da8beb3f29d0@elegosoft.com> On Thu, 28 May 2015 20:14:49 +0000 Jay K wrote: > > Also, this script built the compiler before the support libraries m3core and > > libm3. I think there may have been one bootstrap scenario where this was the > > way it needed to be done, but usually it is the other way around--these two > > libraries first. > > This is very deliberate and should always work, when doing a native upgrade. > It is true it is not always required. > When doing a "clean" cross build, it is true that it is backwards. > It is required when upgrading from an older build. > > Native upgrades start at least with a working compiler and its matching runtime. > Cross builds start with a working host compiler and nothing for the target -- so they do start with m3core. I've had a look at the build log, and I think the problem in this case with upgrade.py might be that it doesn't install the new backend, but only the new frontend: [...] Not shipping cm3cg. --- shipping from AMD64_FREEBSD --- missing ".M3SHIP" file, build the package first. dula3/work/bootstrap/bin/cm3 -build -DROOT=/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a +++ ==> /mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a/m3-sys/m3cc done +++ /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin/cm3 -ship -DROOT=/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a +++ ==> /mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a/m3-sys/m3cc done mkdir -p /mech/construction/mech/ptrees/default/lang/modula3/work/stage/usr/local/bin cp -Pv /mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a/m3-sys/cm3/AMD64_FREEBSD/cm3 /mech/construction/mech/ptrees/default/lang/modula3/work/stage/usr/local/bin/cm3 [...] In the upgrade.sh script I used install-cm3-compiler.sh, which always installs both. In m3-sys/m3cc/src/m3makefile I find the following code: if equal($INSTALL_CM3_IN_BIN, "yes") deriveds("", ["cm3cg", "cm3cg.exe"]) write ( "Forced ship of cm3cg." & CR) BindExport (AppendExeExtension ("cm3cg")) if DoMipsTfile BindExport ("mips-tfile") end else write ( "Not shipping cm3cg." & CR) end So perhaps simply setting INSTALL_CM3_IN_BIN=yes in the environment will fix that problem? Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From rodney_bates at lcwb.coop Thu May 28 23:56:06 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 28 May 2015 16:56:06 -0500 Subject: [M3devel] 64bit INTEGERs, WIDECHAR: language specified or configuration/target dependent? In-Reply-To: <20150528142158.GB19285@topoi.pooq.com> References: <0A1CDD8C-EEB5-40E2-A38B-28E8EEA8C37E@elstel.org> <8A3AB2ED-C11E-4787-A7F8-C8F12157EAA5@elstel.org> <555F6D8F.4070109@lcwb.coop> <6F9B9534-7DC2-4D4D-88CB-90D7FA05E8F9@elstel.org> <8BBBC94B-EECC-464A-86BB-FD1C94EC5496@elstel.org> <77605189-D966-4D4B-8946-838BD6E178AA@purdue.edu> <55675464.5090306@elstel.org> <20150528142158.GB19285@topoi.pooq.com> Message-ID: <55678EF6.4010108@lcwb.coop> On 05/28/2015 09:21 AM, Hendrik Boom wrote: > On Thu, May 28, 2015 at 07:46:12PM +0200, Elmar Stellnberger wrote: >> Am 28.05.15 um 04:03 schrieb Antony Hosking: >>> BYTESIZE(ADDRESS) = BYTESIZE(INTEGER) in cm3 on all target platforms. I don't really understand what you are proposing. >>> >> on AMD64: BITSIZE(INTEGER) = BITSIZE(LONGINT) = 64bit >> >> I have just noticed that and when taking a practical standpoint - >> i.e. what really matters to new and old programs - >> this is a really bad decision which I wish to change for the next release. >> >> If you have not examined it yet please reclaim the design decisions >> for leaving int 32bit in C: >> >> /However things turned out to be very different when the extension from >> 32bit to 64bit was at stake. There was no more gain by automatically >> extending the value ranges from 2^32 to 2^64 for 95% of all application >> purposes while the memory hierarchy has increasingly become a bottle >> neck in recent time. Additionally doubling the size of all integers would >> initially have doubled our memory needs which would have been a >> potential drawback for introducing the AMD64 arch. Just think of a machine >> with 4GB of RAM: It can not be addressed by 32bit (only ~3GB can) while >> making all INTS 64bit would have shrunken our memory to an effective size >> of 2GB. Luckily the decision was taken differently this time: >> >> * keep all ints of at most 32bit and just extend pointers to 64bit >> / >> >> Same reasoning applies to Modula-3. - and I believe you have failed >> to notice when >> making your decisions for cm3 5.8.6. Or do you want to tell me that >> Modula-3 >> developers are more prudent than the C/C++ community? >> >> Even worse I have discovered the following: >> BITS 8 FOR INTEGER and BITS 32 FOR INTEGER do not work with cm3 5.8.6: > > As I understand it from Rodney Bates' reply to my recent post, > BITS 8 FOR INTEGER should never have worked. BITS 32 FOR INTEGER > should work only if INTEGER is 32 bits wide. > Yes. >> >> :: BITS FOR size too small, must be at least (64) >> >> That will break existing legacy code when trying to compile it with >> cm3 5.8.6. > -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Fri May 29 00:15:35 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 28 May 2015 17:15:35 -0500 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> Message-ID: <55679387.8040701@lcwb.coop> On 05/28/2015 12:06 PM, Olaf Wagner wrote: > On Thu, 28 May 2015 17:56:20 +0200 > John Marino wrote: > >> On 5/28/2015 17:01, Rodney M. Bates wrote: >>> I don't know why that happened. I don't have experience with the >>> Python scripts. >>> >>> Jay? >>> >>> Also, this script built the compiler before the support libraries >>> m3core and libm3. I think there may have been one bootstrap scenario >>> where this was the way it needed to be done, but usually it is the >>> other way around--these two libraries first. >>> >>>> Am I doing some kind of obvious mistake? >>>> >>> No, it's a bootstrap barrier. These pop up somewhat regularly. We >>> all usually just build from the most recent development build, which >>> works for getting new things tried out initially. But we need to >>> make a habit of regularly rebuilding from the previous release to >>> flush these out. >> >> Olaf said, IIUC, that the current code can't be built by the last >> release compiler. Putting aside that I believe that should be a hard >> requirement for the project, it sounds like maybe the last release can >> build it if the build order is fixed (e.g. a better upgrade.py script)? >> It's not clear to me what the real situation is. > > No, this is a misunderstanding. I just said or tried to say that there > is no script (yet) that is smart enough to do all the things necessary to > build the current compiler on base of 5.8.6. > >>> You might try scripts/do-cm3-front.sh realclean >>> scripts/do-cm3-front.sh buildship >>> >>> (I usually save /usr/local/cm3/bin/cm3 and /usr/local/cm3/bin/cm3cg >>> at this point. The step below does it somewhat redundantly, but only >>> one level, unless the version number changes.) >>> >>> scripts/install-cm3-compiler.sh upgrade. >>> From here, you are using the new compiler. >>> scripts/do-cm3-.sh buildship >>> >>> That this works, starting with the previous release compiler, is my >>> criterion for having removed bootstrap barriers. > > Rodney, have you really tried that? I'm not sure the steps above will > work. I had the feeling that we're missing some intermediate releases, but > I might be wrong there. > I have done it a number of times for AMD64_LINUX and LINUXLIBC6, using the last release compiler, and successfully building a development compiler, for several different development snapshots. The last time was probably a few months ago, and I don't think much has happened in the compiler and library packages that would make them not compile. It will take a me a little time, but I will try it again on these platforms. >> My work takes place within a Makefile and moving things in /usr/local >> (for example) is actually illegal. Now I could do all this manually for >> the purpose of building a new bootstrap, but as I mentioned in a >> previous post, it might be more effective to emulate what you guy have >> done: essentially build a series of bootstraps at strategic hashes until >> I've acquired a compiler that can build this (and then use that product >> as bootstrap for FreeBSD ports). >> >> If I did that approach, I could use a hint on the hashes to try... > > We should be able to script something that sets up the current compiler > at least on a given specific platform with a well-defined environment. > I might be able to offer more help in the second week of June, if you > can wait until then. > > Olaf > -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Fri May 29 00:17:48 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 28 May 2015 17:17:48 -0500 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <55673AA4.8050100@marino.st> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> Message-ID: <5567940C.6080409@lcwb.coop> On 05/28/2015 10:56 AM, John Marino wrote: > On 5/28/2015 17:01, Rodney M. Bates wrote: >> I don't know why that happened. I don't have experience with the >> Python scripts. >> >> Jay? >> >> Also, this script built the compiler before the support libraries >> m3core and libm3. I think there may have been one bootstrap scenario >> where this was the way it needed to be done, but usually it is the >> other way around--these two libraries first. >> >>> Am I doing some kind of obvious mistake? >>> >> No, it's a bootstrap barrier. These pop up somewhat regularly. We >> all usually just build from the most recent development build, which >> works for getting new things tried out initially. But we need to >> make a habit of regularly rebuilding from the previous release to >> flush these out. > > Olaf said, IIUC, that the current code can't be built by the last > release compiler. Putting aside that I believe that should be a hard > requirement for the project, it sounds like maybe the last release can > build it if the build order is fixed (e.g. a better upgrade.py script)? > It's not clear to me what the real situation is. > > >> You might try scripts/do-cm3-front.sh realclean >> scripts/do-cm3-front.sh buildship >> >> (I usually save /usr/local/cm3/bin/cm3 and /usr/local/cm3/bin/cm3cg >> at this point. The step below does it somewhat redundantly, but only >> one level, unless the version number changes.) >> >> scripts/install-cm3-compiler.sh upgrade. >> From here, you are using the new compiler. >> scripts/do-cm3-.sh buildship >> >> That this works, starting with the previous release compiler, is my >> criterion for having removed bootstrap barriers. > > My work takes place within a Makefile and moving things in /usr/local > (for example) is actually illegal. Now I could do all this manually for > the purpose of building a new bootstrap, but as I mentioned in a > previous post, it might be more effective to emulate what you guy have > done: essentially build a series of bootstraps at strategic hashes until > I've acquired a compiler that can build this (and then use that product > as bootstrap for FreeBSD ports). I don't think that will be necessary. Give me a few days. > > If I did that approach, I could use a hint on the hashes to try... > > John > -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Fri May 29 00:25:19 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 28 May 2015 17:25:19 -0500 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <556722B3.7080209@marino.st> References: <556700B0.8060500@marino.st> <20150528160221.95d4c26d83f68f8cfa93d75a@elego.de> <556722B3.7080209@marino.st> Message-ID: <556795CF.7090409@lcwb.coop> On 05/28/2015 09:14 AM, John Marino wrote: > On 5/28/2015 16:02, Olaf Wagner wrote: >> On Thu, 28 May 2015 13:49:04 +0200 >> John Marino wrote: >>> Am I doing some kind of obvious mistake? >> >> No. I think upgrade.sh (or .py) cannot really cope with updating a 5.8.6 >> instance to the current state. It took me several days, too, on >> MacOS X, and I had to do a lot of manual tweaking and copying >> around. I don't think any casual user will understand the details > > That's a pretty big sin given how 5.8.6 is the current release! > I am in adamant agreement with you here. I periodically interrupt things to go back and prove I can build the development version from the last release. In the process, I have discovered and fixed several bootstrap barriers in the past. I really think it is a build process problem. > >> IMO the best thing we can do now is provide some more up-to-date >> binary archives (I'll upload my own stuff as soon as I find the time). >> A newer release has been missing for several years, and the existing >> scripts are no great help for new users. > > Is there a git tag that can build from 5.8.6? Maybe I just have to keep > doing this until I get a new bootstrap that can do it. > > John > -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Fri May 29 00:54:32 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 28 May 2015 17:54:32 -0500 Subject: [M3devel] 64bit INTEGERs, WIDECHAR: language specified or configuration/target dependent? In-Reply-To: <5567723D.3020706@elstel.org> References: <555E14BC.2040805@lcwb.coop> <555E203E.4040203@elstel.org> <0A1CDD8C-EEB5-40E2-A38B-28E8EEA8C37E@elstel.org> <8A3AB2ED-C11E-4787-A7F8-C8F12157EAA5@elstel.org> <555F6D8F.4070109@lcwb.coop> <6F9B9534-7DC2-4D4D-88CB-90D7FA05E8F9@elstel.org> <8BBBC94B-EECC-464A-86BB-FD1C94EC5496@elstel.org> <77605189-D966-4D4B-8946-838BD6E178AA@purdue.edu> <55675464.5090306@elstel.org> <5567723D.3020706@elstel.org> Message-ID: <55679CA8.2030905@lcwb.coop> On 05/28/2015 02:53 PM, Elmar Stellnberger wrote: > > How for the hell do you interface with operating system services requiring a 32bit int when you only have the 64bit INTEGER?? > Use subranges. Just declare its type [-16_7fffffff-1 .. 16_7fffffff]. Our compiler will allocate nice round bit sizes for everything that isn't BITS n FOR ... . And if it is BITS ..., just use the same subrange type, as above, then use BITS 32 FOR ... . But remember BITS has no effect except when it's an array element or record/object field. It's the subrange, not the BITS spec that determines the range. The language reference doesn't constrain the allocated size, but I'm skeptical about adding things like that to the language. Interfacing with another language is low-level programming, and specifying all the things in that category would be huge and overconstrain the language. Well, maybe not stack variables, if the stack has a bigger alignment to be honored, quite possibly a hardware requirement. No doubt taking and using the address of such would be endian-dependent. Would a C compiler do differently in this case? Can you rely on them all doing it the same? Does C specify it? > Am 28.05.15 um 19:46 schrieb Elmar Stellnberger: >> Am 28.05.15 um 04:03 schrieb Antony Hosking: >>> BYTESIZE(ADDRESS) = BYTESIZE(INTEGER) in cm3 on all target platforms. I don't really understand what you are proposing. >>> >> on AMD64: BITSIZE(INTEGER) = BITSIZE(LONGINT) = 64bit >> >> I have just noticed that and when taking a practical standpoint - i.e. what really matters to new and old programs - >> this is a really bad decision which I wish to change for the next release. >> >> If you have not examined it yet please reclaim the design decisions for leaving int 32bit in C: >> /However things turned out to be very different when the extension from >> 32bit to 64bit was at stake. There was no more gain by automatically >> extending the value ranges from 2^32 to 2^64 for 95% of all application >> purposes while the memory hierarchy has increasingly become a bottle >> neck in recent time. Additionally doubling the size of all integers would >> initially have doubled our memory needs which would have been a >> potential drawback for introducing the AMD64 arch. Just think of a machine >> with 4GB of RAM: It can not be addressed by 32bit (only ~3GB can) while >> making all INTS 64bit would have shrunken our memory to an effective size >> of 2GB. Luckily the decision was taken differently this time: >> >> * keep all ints of at most 32bit and just extend pointers to 64bit >> / >> Same reasoning applies to Modula-3. - and I believe you have failed to notice when >> making your decisions for cm3 5.8.6. Or do you want to tell me that Modula-3 >> developers are more prudent than the C/C++ community? >> >> Even worse I have discovered the following: >> BITS 8 FOR INTEGER and BITS 32 FOR INTEGER do not work with cm3 5.8.6: >> >> :: BITS FOR size too small, must be at least (64) >> >> That will break existing legacy code when trying to compile it with cm3 5.8.6. > -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Fri May 29 05:18:36 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 28 May 2015 22:18:36 -0500 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <55679387.8040701@lcwb.coop> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> Message-ID: <5567DA8C.3050802@lcwb.coop> On 05/28/2015 05:15 PM, Rodney M. Bates wrote: > > > On 05/28/2015 12:06 PM, Olaf Wagner wrote: >> On Thu, 28 May 2015 17:56:20 +0200 >> John Marino wrote: >> >>> On 5/28/2015 17:01, Rodney M. Bates wrote: >>>> I don't know why that happened. I don't have experience with the >>>> Python scripts. >>>> >>>> Jay? >>>> >>>> Also, this script built the compiler before the support libraries >>>> m3core and libm3. I think there may have been one bootstrap scenario >>>> where this was the way it needed to be done, but usually it is the >>>> other way around--these two libraries first. >>>> >>>>> Am I doing some kind of obvious mistake? >>>>> >>>> No, it's a bootstrap barrier. These pop up somewhat regularly. We >>>> all usually just build from the most recent development build, which >>>> works for getting new things tried out initially. But we need to >>>> make a habit of regularly rebuilding from the previous release to >>>> flush these out. >>> >>> Olaf said, IIUC, that the current code can't be built by the last >>> release compiler. Putting aside that I believe that should be a hard >>> requirement for the project, it sounds like maybe the last release can >>> build it if the build order is fixed (e.g. a better upgrade.py script)? >>> It's not clear to me what the real situation is. >> >> No, this is a misunderstanding. I just said or tried to say that there >> is no script (yet) that is smart enough to do all the things necessary to >> build the current compiler on base of 5.8.6. >> >>>> You might try scripts/do-cm3-front.sh realclean >>>> scripts/do-cm3-front.sh buildship >>>> >>>> (I usually save /usr/local/cm3/bin/cm3 and /usr/local/cm3/bin/cm3cg >>>> at this point. The step below does it somewhat redundantly, but only >>>> one level, unless the version number changes.) >>>> >>>> scripts/install-cm3-compiler.sh upgrade. >>>> From here, you are using the new compiler. >>>> scripts/do-cm3-.sh buildship >>>> >>>> That this works, starting with the previous release compiler, is my >>>> criterion for having removed bootstrap barriers. >> >> Rodney, have you really tried that? I'm not sure the steps above will >> work. I had the feeling that we're missing some intermediate releases, but >> I might be wrong there. >> > > I have done it a number of times for AMD64_LINUX and LINUXLIBC6, using the > last release compiler, and successfully building a development compiler, > for several different development snapshots. The last time was probably > a few months ago, and I don't think much has happened in the compiler > and library packages that would make them not compile. It will take a > me a little time, but I will try it again on these platforms. > OK, this is working for me on LINUXLIBC6. With the release compiler installed: $ cm3 -version Critical Mass Modula-3 version 5.8.6 last updated: 2010-04-11 compiled: 2013-09-13 21:38:06 configuration: /usr/local/cm3/bin/cm3.cfg host: AMD64_LINUX target: AMD64_LINUX And a freshly pulled git repository from github, in cm3/scripts: 1) $ ./do-cm3-all.sh realclean #Clean everything 2) $ ./do-cm3-front.sh buildship #Build a compiler & its support libraries All compiles succeeded. 4) $ ./install-cm3-compiler.sh upgrade # Install the compiler $ cm3 -version Critical Mass Modula-3 version d5.10.0 last updated: 2015-05-21 compiled: 2015-05-29 02:54:41 configuration: /usr/local/cm3/bin/cm3.cfg host: AMD64_LINUX target: AMD64_LINUX Now repeat steps 1 and 2. This will use the newly compiled head compiler. to rebuild itself. All compiles succeeded. Finally, $./do-cm3-all.sh buildship #Build the rest. This compiles all the remaining stuff, none of which is involved in bootstrapping. All compiles succeeded. In the past, I often will install the second-time-compiled head compiler and do it all a third time. After getting this far, this has never failed, and I didn't do it this time. New package libunicode uses an addition to Compiler.i3 that is not in the release, so you have to install the new compiler before compiling libunicode. >>> My work takes place within a Makefile and moving things in /usr/local >>> (for example) is actually illegal. Now I could do all this manually for >>> the purpose of building a new bootstrap, but as I mentioned in a >>> previous post, it might be more effective to emulate what you guy have >>> done: essentially build a series of bootstraps at strategic hashes until >>> I've acquired a compiler that can build this (and then use that product >>> as bootstrap for FreeBSD ports). >>> >>> If I did that approach, I could use a hint on the hashes to try... >> >> We should be able to script something that sets up the current compiler >> at least on a given specific platform with a well-defined environment. >> I might be able to offer more help in the second week of June, if you >> can wait until then. >> >> Olaf >> > -- Rodney Bates rodney.m.bates at acm.org From wagner at elegosoft.com Fri May 29 08:57:50 2015 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 29 May 2015 08:57:50 +0200 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <5567DA8C.3050802@lcwb.coop> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop> Message-ID: <20150529085750.0a8f9e2c62f01c2a0d1be4ca@elegosoft.com> On Thu, 28 May 2015 22:18:36 -0500 "Rodney M. Bates" wrote: > On 05/28/2015 05:15 PM, Rodney M. Bates wrote: > > > > On 05/28/2015 12:06 PM, Olaf Wagner wrote: > >> On Thu, 28 May 2015 17:56:20 +0200 > >> John Marino wrote: > >> > >>> On 5/28/2015 17:01, Rodney M. Bates wrote: > >>>> I don't know why that happened. I don't have experience with the > >>>> Python scripts. > >>>> > >>>> Jay? > >>>> > >>>> Also, this script built the compiler before the support libraries > >>>> m3core and libm3. I think there may have been one bootstrap scenario > >>>> where this was the way it needed to be done, but usually it is the > >>>> other way around--these two libraries first. > >>>> > >>>>> Am I doing some kind of obvious mistake? > >>>>> > >>>> No, it's a bootstrap barrier. These pop up somewhat regularly. We > >>>> all usually just build from the most recent development build, which > >>>> works for getting new things tried out initially. But we need to > >>>> make a habit of regularly rebuilding from the previous release to > >>>> flush these out. > >>> > >>> Olaf said, IIUC, that the current code can't be built by the last > >>> release compiler. Putting aside that I believe that should be a hard > >>> requirement for the project, it sounds like maybe the last release can > >>> build it if the build order is fixed (e.g. a better upgrade.py script)? > >>> It's not clear to me what the real situation is. > >> > >> No, this is a misunderstanding. I just said or tried to say that there > >> is no script (yet) that is smart enough to do all the things necessary to > >> build the current compiler on base of 5.8.6. > >> > >>>> You might try scripts/do-cm3-front.sh realclean > >>>> scripts/do-cm3-front.sh buildship > >>>> > >>>> (I usually save /usr/local/cm3/bin/cm3 and /usr/local/cm3/bin/cm3cg > >>>> at this point. The step below does it somewhat redundantly, but only > >>>> one level, unless the version number changes.) > >>>> > >>>> scripts/install-cm3-compiler.sh upgrade. > >>>> From here, you are using the new compiler. > >>>> scripts/do-cm3-.sh buildship > >>>> > >>>> That this works, starting with the previous release compiler, is my > >>>> criterion for having removed bootstrap barriers. > >> > >> Rodney, have you really tried that? I'm not sure the steps above will > >> work. I had the feeling that we're missing some intermediate releases, but > >> I might be wrong there. > >> > > > > I have done it a number of times for AMD64_LINUX and LINUXLIBC6, using the > > last release compiler, and successfully building a development compiler, > > for several different development snapshots. The last time was probably > > a few months ago, and I don't think much has happened in the compiler > > and library packages that would make them not compile. It will take a > > me a little time, but I will try it again on these platforms. > > > > OK, this is working for me on LINUXLIBC6. > > With the release compiler installed: > > $ cm3 -version > Critical Mass Modula-3 version 5.8.6 > last updated: 2010-04-11 > compiled: 2013-09-13 21:38:06 > configuration: /usr/local/cm3/bin/cm3.cfg > host: AMD64_LINUX > target: AMD64_LINUX > > And a freshly pulled git repository from github, > in cm3/scripts: > > 1) $ ./do-cm3-all.sh realclean #Clean everything > 2) $ ./do-cm3-front.sh buildship #Build a compiler & its support libraries > > All compiles succeeded. > > 4) $ ./install-cm3-compiler.sh upgrade # Install the compiler > > $ cm3 -version > Critical Mass Modula-3 version d5.10.0 > last updated: 2015-05-21 > compiled: 2015-05-29 02:54:41 > configuration: /usr/local/cm3/bin/cm3.cfg > host: AMD64_LINUX > target: AMD64_LINUX > > Now repeat steps 1 and 2. This will use the newly compiled head compiler. > to rebuild itself. All compiles succeeded. > > Finally, $./do-cm3-all.sh buildship #Build the rest. > > This compiles all the remaining stuff, none of which is involved in bootstrapping. > All compiles succeeded. > > In the past, I often will install the second-time-compiled head compiler and > do it all a third time. After getting this far, this has never failed, and > I didn't do it this time. > > New package libunicode uses an addition to Compiler.i3 that is not in the release, so > you have to install the new compiler before compiling libunicode. Great. So the situation is better than I assumed after my struggles a week ago. Thanks for verifying that. Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From adacore at marino.st Fri May 29 09:39:13 2015 From: adacore at marino.st (John Marino) Date: Fri, 29 May 2015 09:39:13 +0200 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <5567DA8C.3050802@lcwb.coop> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop> Message-ID: <556817A1.2090206@marino.st> On 5/29/2015 05:18, Rodney M. Bates wrote: > OK, this is working for me on LINUXLIBC6. > > With the release compiler installed: > > $ cm3 -version > Critical Mass Modula-3 version 5.8.6 > last updated: 2010-04-11 > compiled: 2013-09-13 21:38:06 > configuration: /usr/local/cm3/bin/cm3.cfg > host: AMD64_LINUX > target: AMD64_LINUX > > And a freshly pulled git repository from github, > in cm3/scripts: > > 1) $ ./do-cm3-all.sh realclean #Clean everything > 2) $ ./do-cm3-front.sh buildship #Build a compiler & its support libraries > > All compiles succeeded. At first I was thinking "this is kind of horrible" until I realized that this is pretty much what the former boot-cm3-with-m3.sh script was doing. I figured out a way to incorporate this technique into the port's makefile. Unfortunately, I can't say I found success. # /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin/cm3 -version Critical Mass Modula-3 version 5.8.6 last updated: 2010-04-11 compiled: 2014-01-02 01:01:20 configuration: /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin/cm3.cfg host: AMD64_FREEBSD target: AMD64_FREEBSD I am seeing the same exact m3cg version stamp errors as I saw on the python upgrade script. Here's my build log so you can verify I followed the procedure: http://leaf.dragonflybsd.org/~marino/m3a.log I don't know it would work for you on linux but not me on FreeBSD ... John From wagner at elego.de Fri May 29 10:54:51 2015 From: wagner at elego.de (Olaf Wagner) Date: Fri, 29 May 2015 10:54:51 +0200 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <556817A1.2090206@marino.st> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop> <556817A1.2090206@marino.st> Message-ID: <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de> On Fri, 29 May 2015 09:39:13 +0200 John Marino wrote: > On 5/29/2015 05:18, Rodney M. Bates wrote: > > OK, this is working for me on LINUXLIBC6. > > > > With the release compiler installed: > > > > $ cm3 -version > > Critical Mass Modula-3 version 5.8.6 > > last updated: 2010-04-11 > > compiled: 2013-09-13 21:38:06 > > configuration: /usr/local/cm3/bin/cm3.cfg > > host: AMD64_LINUX > > target: AMD64_LINUX > > > > And a freshly pulled git repository from github, > > in cm3/scripts: > > > > 1) $ ./do-cm3-all.sh realclean #Clean everything > > 2) $ ./do-cm3-front.sh buildship #Build a compiler & its support libraries > > > > All compiles succeeded. > > At first I was thinking "this is kind of horrible" until I realized that > this is pretty much what the former boot-cm3-with-m3.sh script was > doing. I figured out a way to incorporate this technique into the > port's makefile. Unfortunately, I can't say I found success. > > # > /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin/cm3 > -version > > Critical Mass Modula-3 version 5.8.6 > last updated: 2010-04-11 > compiled: 2014-01-02 01:01:20 > configuration: > /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin/cm3.cfg > host: AMD64_FREEBSD > target: AMD64_FREEBSD > > > I am seeing the same exact m3cg version stamp errors as I saw on the > python upgrade script. Here's my build log so you can verify I followed > the procedure: > > http://leaf.dragonflybsd.org/~marino/m3a.log > > I don't know it would work for you on linux but not me on FreeBSD ... Please try what I suggested in the attached mail: define INSTALL_CM3_IN_BIN=yes in the environment and see if that helps. Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -------------- next part -------------- An embedded message was scrubbed... From: Olaf Wagner Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 Date: Thu, 28 May 2015 23:05:54 +0200 Size: 3481 URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From adacore at marino.st Fri May 29 11:10:50 2015 From: adacore at marino.st (John Marino) Date: Fri, 29 May 2015 11:10:50 +0200 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop> <556817A1.2090206@marino.st> <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de> Message-ID: <55682D1A.2030504@marino.st> On 5/29/2015 10:54, Olaf Wagner wrote: > Please try what I suggested in the attached mail: define > INSTALL_CM3_IN_BIN=yes > in the environment and see if that helps. > Unfortunately it seems the result is exactly the same, even when INSTALL_CM3_IN_BIN is defined in the environment. John From wagner at elego.de Fri May 29 11:39:35 2015 From: wagner at elego.de (Olaf Wagner) Date: Fri, 29 May 2015 11:39:35 +0200 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <55682D1A.2030504@marino.st> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop> <556817A1.2090206@marino.st> <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de> <55682D1A.2030504@marino.st> Message-ID: <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de> On Fri, 29 May 2015 11:10:50 +0200 John Marino wrote: > On 5/29/2015 10:54, Olaf Wagner wrote: > > Please try what I suggested in the attached mail: define > > INSTALL_CM3_IN_BIN=yes > > in the environment and see if that helps. > > > > Unfortunately it seems the result is exactly the same, even when > INSTALL_CM3_IN_BIN is defined in the environment. Can I see the new logs? Has the new backend (cm3cg) been installed now? Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From adacore at marino.st Fri May 29 11:51:05 2015 From: adacore at marino.st (John Marino) Date: Fri, 29 May 2015 11:51:05 +0200 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop> <556817A1.2090206@marino.st> <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de> <55682D1A.2030504@marino.st> <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de> Message-ID: <55683689.2090709@marino.st> On 5/29/2015 11:39, Olaf Wagner wrote: > On Fri, 29 May 2015 11:10:50 +0200 > John Marino wrote: > >> On 5/29/2015 10:54, Olaf Wagner wrote: >>> Please try what I suggested in the attached mail: define >>> INSTALL_CM3_IN_BIN=yes >>> in the environment and see if that helps. >>> >> >> Unfortunately it seems the result is exactly the same, even when >> INSTALL_CM3_IN_BIN is defined in the environment. > > Can I see the new logs? Has the new backend (cm3cg) been installed now? > It's here: http://leaf.dragonflybsd.org/~marino/m3c.log It never completes "do-cm3-front.sh buildship " Note that I'm using a bootstrap install and set INSTALL_ROOT to another location, but it never gets to the point of installing anything. John From wagner at elego.de Fri May 29 12:27:32 2015 From: wagner at elego.de (Olaf Wagner) Date: Fri, 29 May 2015 12:27:32 +0200 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <55683689.2090709@marino.st> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop> <556817A1.2090206@marino.st> <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de> <55682D1A.2030504@marino.st> <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de> <55683689.2090709@marino.st> Message-ID: <20150529122732.1396eb079ff9b404bcb21e40@elego.de> On Fri, 29 May 2015 11:51:05 +0200 John Marino wrote: > On 5/29/2015 11:39, Olaf Wagner wrote: > > On Fri, 29 May 2015 11:10:50 +0200 > > John Marino wrote: > > > >> On 5/29/2015 10:54, Olaf Wagner wrote: > >>> Please try what I suggested in the attached mail: define > >>> INSTALL_CM3_IN_BIN=yes > >>> in the environment and see if that helps. > >>> > >> > >> Unfortunately it seems the result is exactly the same, even when > >> INSTALL_CM3_IN_BIN is defined in the environment. > > > > Can I see the new logs? Has the new backend (cm3cg) been installed now? > > > It's here: > http://leaf.dragonflybsd.org/~marino/m3c.log > > It never completes "do-cm3-front.sh buildship " > > Note that I'm using a bootstrap install and set INSTALL_ROOT to another > location, but it never gets to the point of installing anything. It now has shipped the new gcc-backend as expected, but that doesn't seem to be the problem :-( I'm afraid I'll have to reproduce your setup locally on my FreeBSD system at home, as I don't see the wrong step in the logs 8-| After Rodney's success on Linux I was hoping that everything still just worked as some years ago. Just to make sure: you start with a 5.8.6 release archive for AMD64_FREEBSD, install that, check out the git sources, and run the script(s) in the checked-out repository, correct? Or did I miss anything? Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From adacore at marino.st Fri May 29 12:40:29 2015 From: adacore at marino.st (John Marino) Date: Fri, 29 May 2015 12:40:29 +0200 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <20150529122732.1396eb079ff9b404bcb21e40@elego.de> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop> <556817A1.2090206@marino.st> <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de> <55682D1A.2030504@marino.st> <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de> <55683689.2090709@marino.st> <20150529122732.1396eb079ff9b404bcb21e40@elego.de> Message-ID: <5568421D.3050209@marino.st> On 5/29/2015 12:27, Olaf Wagner wrote: > > I'm afraid I'll have to reproduce your setup locally on my FreeBSD > system at home, as I don't see the wrong step in the logs 8-| > > After Rodney's success on Linux I was hoping that everything still > just worked as some years ago. > > Just to make sure: you start with a 5.8.6 release archive for > AMD64_FREEBSD, install that, check out the git sources, and > run the script(s) in the checked-out repository, correct? Or > did I miss anything? I maintain the "port" for M3 on FreeBSD. see here: http://www.freshports.org/lang/modula3 Because I'm building these in ports, there are certain "rules" I have to follow using makefiles. I've attached the in-work "port" that I'm using. You can "rm -rf /usr/ports/lang/modula3; cd /usr/ports/lang; tar -xf m3-port.tar.gz" to use it to reproduce what I'm doing. All you'd do to reproduce is: "cd /usr/ports/lang/modula3 ; make build" To be more specific, the current repo is downloaded from github as a tarball along with the bootstrap compiler (only once, then the tarball is reused on subsequent). Then it tries to build a new bootstrap compiler in the build target and that's where it's failing. Regards, John -------------- next part -------------- A non-text attachment was scrubbed... Name: m3-port.tar.gz Type: application/x-gzip Size: 3344 bytes Desc: not available URL: From jay.krell at cornell.edu Fri May 29 13:22:15 2015 From: jay.krell at cornell.edu (Jay K) Date: Fri, 29 May 2015 11:22:15 +0000 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <20150528230554.80920c53f002da8beb3f29d0@elegosoft.com> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop>, , <20150528230554.80920c53f002da8beb3f29d0@elegosoft.com> Message-ID: > if equal($INSTALL_CM3_IN_BIN, "yes") Hm. That is relatively new. Rodney, This is a mistake: https://github.com/modula3/cm3/commit/1994f950bb30c3021fd24c07a555f0f7bace933f I see you commented it heavily, but we had working automation before that this broke. The automation already took into account what you were trying to take into account. I agree having the config search all over, which I did, is not good, as it undermines attempts to ship at just the right time. If you don't want to ship cm3cg, then don't run cm3 -ship for it. cm3cg is not actually running when cm3 -ship is run. The reasons cm3 doesn't ship itself do not apply. I agree it seems tempting to sync this behavior with the behavior of shipping cm3. But I don't think it should be. Yes the files have to be updated together. You do that by shipping cm3cg and somehow otherwise copying cm3. I agree that having this "somehow otherwise copy" is not great. I wonder if we can remove that though. The reason cm3 ship is disabled by default is not so that things are updated together, but because having an executable copy over itself reportedly does not work on some operating systems. It is nothing to do with our need to copy multiple files automatically. It is because it will fail. Now..I must say..Windows is extremely often labeled as one of these systems. Countless people believe this myth. But it isn't true. You can copy over an "in use" .dll or .exe. You merely have to rename it away first. Yes, that is still a bit wierd. And I have to investigate how to eventually delete it. Yes, there is a way to defer the delete..until a reboot..if you are an administrator.. but that is clearly an inadequate mechanism. It is quite possible you open with delete_on_close, and close, and then the last close might do it, when the .exe stops running. We should try this out. However, with Windows possibly eliminated as a concern (once ship does the rename, which it doesn't currently), does that leave other systems? AIX I believe is similar..that a direct copy will fail. But will rename work around it there too? Should we let cm3 be able to ship itself, and see what comes of it? Like, maybe every system people really use can do it? When an AIX user speaks up, we can fix it then?? Either way, I believe this change to m3cc/src/m3makefile should be undone. In the meantime, everyone can workaround it by setting the environment variable. The other angle, which I've been pushing unsuccessfully is never update in place. That is portable. Start with a new empty directory tree and fill it in by shipping, even cm3. Like make-dist.py does. One wrinkle here is that cm3, if it doesn't already, must favor looking next to itself, and not searching $PATH. So that you ship cm3cg to the new place, and then cm3, and cm3 shipping second finishes the transaction (ok, you'd also copy/ship other files, like configs and m3core/libm3, and then cm3 last). I would really really like that code for an executable to find its full path, on all supported systems. I don't think Posix can do it. Win32 GetModuleFileName(NULL or &__ImageBase) for example. Then strip off the last path element and append stuff, to find things you go with. It is a nice technique. I'm leary of techniques that rely on $PATH search or applying argv[0] to getcwd, as the current directory can change at any time. (and another unsuccessful angle is to move away from all the .sh files; I've been using the .py files for years...well, I was...) - Jay > Date: Thu, 28 May 2015 23:05:54 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: rodney.m.bates at acm.org; m3devel at elegosoft.com; adacore at marino.st > Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > > On Thu, 28 May 2015 20:14:49 +0000 > Jay K wrote: > > > > Also, this script built the compiler before the support libraries m3core and > > > libm3. I think there may have been one bootstrap scenario where this was the > > > way it needed to be done, but usually it is the other way around--these two > > > libraries first. > > > > This is very deliberate and should always work, when doing a native upgrade. > > It is true it is not always required. > > When doing a "clean" cross build, it is true that it is backwards. > > It is required when upgrading from an older build. > > > > Native upgrades start at least with a working compiler and its matching runtime. > > Cross builds start with a working host compiler and nothing for the target -- so they do start with m3core. > > I've had a look at the build log, and I think the problem in this case > with upgrade.py might be that it doesn't install the new backend, but > only the new frontend: > > [...] > Not shipping cm3cg. > --- shipping from AMD64_FREEBSD --- > > missing ".M3SHIP" file, build the package first. > dula3/work/bootstrap/bin/cm3 -build -DROOT=/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a +++ > ==> /mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a/m3-sys/m3cc done > > +++ /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin/cm3 -ship -DROOT=/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a +++ > ==> /mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a/m3-sys/m3cc done > > mkdir -p /mech/construction/mech/ptrees/default/lang/modula3/work/stage/usr/local/bin > cp -Pv /mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a/m3-sys/cm3/AMD64_FREEBSD/cm3 /mech/construction/mech/ptrees/default/lang/modula3/work/stage/usr/local/bin/cm3 > [...] > > In the upgrade.sh script I used install-cm3-compiler.sh, which always > installs both. In m3-sys/m3cc/src/m3makefile I find the following code: > > if equal($INSTALL_CM3_IN_BIN, "yes") > deriveds("", ["cm3cg", "cm3cg.exe"]) > write ( "Forced ship of cm3cg." & CR) > BindExport (AppendExeExtension ("cm3cg")) > if DoMipsTfile > BindExport ("mips-tfile") > end > else > write ( "Not shipping cm3cg." & CR) > end > > So perhaps simply setting INSTALL_CM3_IN_BIN=yes in the environment > will fix that problem? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri May 29 13:42:32 2015 From: jay.krell at cornell.edu (Jay K) Date: Fri, 29 May 2015 11:42:32 +0000 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop>, , , , <20150528230554.80920c53f002da8beb3f29d0@elegosoft.com>, Message-ID: > One wrinkle here is that cm3, if it doesn't already, must favor looking next to itself, and not searching $PATH. dladdr appears to be the answer. It appears to be supported on MacOSX 10.4. OpenBSD, NetBSD, FreeBSD, Solaris, AIX, HP-UX, Irix, OpenVMS, Tru64. At least later versions of all of them. Non-authoritative web searches indicate so... And GetModuleFileName on Windows. Any objections to using it in cm3? (and GetModuleFileName on Windows)? This way, cm3 can easily and reliably look next to itself for config files and the pkg directory and cm3cg. I can double double check, but I doubt what it does today is totally reliable. Thanks, - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com Date: Fri, 29 May 2015 11:22:15 +0000 CC: m3devel at elegosoft.com; rodney.m.bates at acm.org Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > if equal($INSTALL_CM3_IN_BIN, "yes") Hm. That is relatively new. Rodney, This is a mistake: https://github.com/modula3/cm3/commit/1994f950bb30c3021fd24c07a555f0f7bace933f I see you commented it heavily, but we had working automation before that this broke. The automation already took into account what you were trying to take into account. I agree having the config search all over, which I did, is not good, as it undermines attempts to ship at just the right time. If you don't want to ship cm3cg, then don't run cm3 -ship for it. cm3cg is not actually running when cm3 -ship is run. The reasons cm3 doesn't ship itself do not apply. I agree it seems tempting to sync this behavior with the behavior of shipping cm3. But I don't think it should be. Yes the files have to be updated together. You do that by shipping cm3cg and somehow otherwise copying cm3. I agree that having this "somehow otherwise copy" is not great. I wonder if we can remove that though. The reason cm3 ship is disabled by default is not so that things are updated together, but because having an executable copy over itself reportedly does not work on some operating systems. It is nothing to do with our need to copy multiple files automatically. It is because it will fail. Now..I must say..Windows is extremely often labeled as one of these systems. Countless people believe this myth. But it isn't true. You can copy over an "in use" .dll or .exe. You merely have to rename it away first. Yes, that is still a bit wierd. And I have to investigate how to eventually delete it. Yes, there is a way to defer the delete..until a reboot..if you are an administrator.. but that is clearly an inadequate mechanism. It is quite possible you open with delete_on_close, and close, and then the last close might do it, when the .exe stops running. We should try this out. However, with Windows possibly eliminated as a concern (once ship does the rename, which it doesn't currently), does that leave other systems? AIX I believe is similar..that a direct copy will fail. But will rename work around it there too? Should we let cm3 be able to ship itself, and see what comes of it? Like, maybe every system people really use can do it? When an AIX user speaks up, we can fix it then?? Either way, I believe this change to m3cc/src/m3makefile should be undone. In the meantime, everyone can workaround it by setting the environment variable. The other angle, which I've been pushing unsuccessfully is never update in place. That is portable. Start with a new empty directory tree and fill it in by shipping, even cm3. Like make-dist.py does. One wrinkle here is that cm3, if it doesn't already, must favor looking next to itself, and not searching $PATH. So that you ship cm3cg to the new place, and then cm3, and cm3 shipping second finishes the transaction (ok, you'd also copy/ship other files, like configs and m3core/libm3, and then cm3 last). I would really really like that code for an executable to find its full path, on all supported systems. I don't think Posix can do it. Win32 GetModuleFileName(NULL or &__ImageBase) for example. Then strip off the last path element and append stuff, to find things you go with. It is a nice technique. I'm leary of techniques that rely on $PATH search or applying argv[0] to getcwd, as the current directory can change at any time. (and another unsuccessful angle is to move away from all the .sh files; I've been using the .py files for years...well, I was...) - Jay > Date: Thu, 28 May 2015 23:05:54 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: rodney.m.bates at acm.org; m3devel at elegosoft.com; adacore at marino.st > Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > > On Thu, 28 May 2015 20:14:49 +0000 > Jay K wrote: > > > > Also, this script built the compiler before the support libraries m3core and > > > libm3. I think there may have been one bootstrap scenario where this was the > > > way it needed to be done, but usually it is the other way around--these two > > > libraries first. > > > > This is very deliberate and should always work, when doing a native upgrade. > > It is true it is not always required. > > When doing a "clean" cross build, it is true that it is backwards. > > It is required when upgrading from an older build. > > > > Native upgrades start at least with a working compiler and its matching runtime. > > Cross builds start with a working host compiler and nothing for the target -- so they do start with m3core. > > I've had a look at the build log, and I think the problem in this case > with upgrade.py might be that it doesn't install the new backend, but > only the new frontend: > > [...] > Not shipping cm3cg. > --- shipping from AMD64_FREEBSD --- > > missing ".M3SHIP" file, build the package first. > dula3/work/bootstrap/bin/cm3 -build -DROOT=/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a +++ > ==> /mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a/m3-sys/m3cc done > > +++ /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin/cm3 -ship -DROOT=/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a +++ > ==> /mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a/m3-sys/m3cc done > > mkdir -p /mech/construction/mech/ptrees/default/lang/modula3/work/stage/usr/local/bin > cp -Pv /mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a/m3-sys/cm3/AMD64_FREEBSD/cm3 /mech/construction/mech/ptrees/default/lang/modula3/work/stage/usr/local/bin/cm3 > [...] > > In the upgrade.sh script I used install-cm3-compiler.sh, which always > installs both. In m3-sys/m3cc/src/m3makefile I find the following code: > > if equal($INSTALL_CM3_IN_BIN, "yes") > deriveds("", ["cm3cg", "cm3cg.exe"]) > write ( "Forced ship of cm3cg." & CR) > BindExport (AppendExeExtension ("cm3cg")) > if DoMipsTfile > BindExport ("mips-tfile") > end > else > write ( "Not shipping cm3cg." & CR) > end > > So perhaps simply setting INSTALL_CM3_IN_BIN=yes in the environment > will fix that problem? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri May 29 13:45:02 2015 From: jay.krell at cornell.edu (Jay K) Date: Fri, 29 May 2015 11:45:02 +0000 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop>, , , , <20150528230554.80920c53f002da8beb3f29d0@elegosoft.com>, Message-ID: The workaround is bad, as it affects m3-sys/cm3 also. Rodney, this really should be removed. If you must have something like this, make it a separate variable from cm3. Please. - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com Date: Fri, 29 May 2015 11:22:15 +0000 CC: m3devel at elegosoft.com; rodney.m.bates at acm.org Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > if equal($INSTALL_CM3_IN_BIN, "yes") Hm. That is relatively new. Rodney, This is a mistake: https://github.com/modula3/cm3/commit/1994f950bb30c3021fd24c07a555f0f7bace933f I see you commented it heavily, but we had working automation before that this broke. The automation already took into account what you were trying to take into account. I agree having the config search all over, which I did, is not good, as it undermines attempts to ship at just the right time. If you don't want to ship cm3cg, then don't run cm3 -ship for it. cm3cg is not actually running when cm3 -ship is run. The reasons cm3 doesn't ship itself do not apply. I agree it seems tempting to sync this behavior with the behavior of shipping cm3. But I don't think it should be. Yes the files have to be updated together. You do that by shipping cm3cg and somehow otherwise copying cm3. I agree that having this "somehow otherwise copy" is not great. I wonder if we can remove that though. The reason cm3 ship is disabled by default is not so that things are updated together, but because having an executable copy over itself reportedly does not work on some operating systems. It is nothing to do with our need to copy multiple files automatically. It is because it will fail. Now..I must say..Windows is extremely often labeled as one of these systems. Countless people believe this myth. But it isn't true. You can copy over an "in use" .dll or .exe. You merely have to rename it away first. Yes, that is still a bit wierd. And I have to investigate how to eventually delete it. Yes, there is a way to defer the delete..until a reboot..if you are an administrator.. but that is clearly an inadequate mechanism. It is quite possible you open with delete_on_close, and close, and then the last close might do it, when the .exe stops running. We should try this out. However, with Windows possibly eliminated as a concern (once ship does the rename, which it doesn't currently), does that leave other systems? AIX I believe is similar..that a direct copy will fail. But will rename work around it there too? Should we let cm3 be able to ship itself, and see what comes of it? Like, maybe every system people really use can do it? When an AIX user speaks up, we can fix it then?? Either way, I believe this change to m3cc/src/m3makefile should be undone. In the meantime, everyone can workaround it by setting the environment variable. The other angle, which I've been pushing unsuccessfully is never update in place. That is portable. Start with a new empty directory tree and fill it in by shipping, even cm3. Like make-dist.py does. One wrinkle here is that cm3, if it doesn't already, must favor looking next to itself, and not searching $PATH. So that you ship cm3cg to the new place, and then cm3, and cm3 shipping second finishes the transaction (ok, you'd also copy/ship other files, like configs and m3core/libm3, and then cm3 last). I would really really like that code for an executable to find its full path, on all supported systems. I don't think Posix can do it. Win32 GetModuleFileName(NULL or &__ImageBase) for example. Then strip off the last path element and append stuff, to find things you go with. It is a nice technique. I'm leary of techniques that rely on $PATH search or applying argv[0] to getcwd, as the current directory can change at any time. (and another unsuccessful angle is to move away from all the .sh files; I've been using the .py files for years...well, I was...) - Jay > Date: Thu, 28 May 2015 23:05:54 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: rodney.m.bates at acm.org; m3devel at elegosoft.com; adacore at marino.st > Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > > On Thu, 28 May 2015 20:14:49 +0000 > Jay K wrote: > > > > Also, this script built the compiler before the support libraries m3core and > > > libm3. I think there may have been one bootstrap scenario where this was the > > > way it needed to be done, but usually it is the other way around--these two > > > libraries first. > > > > This is very deliberate and should always work, when doing a native upgrade. > > It is true it is not always required. > > When doing a "clean" cross build, it is true that it is backwards. > > It is required when upgrading from an older build. > > > > Native upgrades start at least with a working compiler and its matching runtime. > > Cross builds start with a working host compiler and nothing for the target -- so they do start with m3core. > > I've had a look at the build log, and I think the problem in this case > with upgrade.py might be that it doesn't install the new backend, but > only the new frontend: > > [...] > Not shipping cm3cg. > --- shipping from AMD64_FREEBSD --- > > missing ".M3SHIP" file, build the package first. > dula3/work/bootstrap/bin/cm3 -build -DROOT=/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a +++ > ==> /mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a/m3-sys/m3cc done > > +++ /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin/cm3 -ship -DROOT=/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a +++ > ==> /mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a/m3-sys/m3cc done > > mkdir -p /mech/construction/mech/ptrees/default/lang/modula3/work/stage/usr/local/bin > cp -Pv /mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a/m3-sys/cm3/AMD64_FREEBSD/cm3 /mech/construction/mech/ptrees/default/lang/modula3/work/stage/usr/local/bin/cm3 > [...] > > In the upgrade.sh script I used install-cm3-compiler.sh, which always > installs both. In m3-sys/m3cc/src/m3makefile I find the following code: > > if equal($INSTALL_CM3_IN_BIN, "yes") > deriveds("", ["cm3cg", "cm3cg.exe"]) > write ( "Forced ship of cm3cg." & CR) > BindExport (AppendExeExtension ("cm3cg")) > if DoMipsTfile > BindExport ("mips-tfile") > end > else > write ( "Not shipping cm3cg." & CR) > end > > So perhaps simply setting INSTALL_CM3_IN_BIN=yes in the environment > will fix that problem? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elego.de Fri May 29 14:04:02 2015 From: wagner at elego.de (Olaf Wagner) Date: Fri, 29 May 2015 14:04:02 +0200 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <20150528230554.80920c53f002da8beb3f29d0@elegosoft.com> Message-ID: <20150529140402.d87ddf6435a145c466ed3434@elego.de> On Fri, 29 May 2015 11:45:02 +0000 Jay K wrote: > The workaround is bad, as it affects m3-sys/cm3 also. > Rodney, this really should be removed. If you must have something like this, make it a separate variable from cm3. Please. I don't think Rodney introduced this variable ;-) Olaf > - Jay > > > > From: jay.krell at cornell.edu > To: wagner at elegosoft.com > Date: Fri, 29 May 2015 11:22:15 +0000 > CC: m3devel at elegosoft.com; rodney.m.bates at acm.org > Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > > > > > > if equal($INSTALL_CM3_IN_BIN, "yes") > > > Hm. That is relatively new. > Rodney, This is a mistake: > https://github.com/modula3/cm3/commit/1994f950bb30c3021fd24c07a555f0f7bace933f > > > I see you commented it heavily, but we had working automation before that this broke. > The automation already took into account what you were trying to take into account. > > > I agree having the config search all over, which I did, is not good, > as it undermines attempts to ship at just the right time. > > > If you don't want to ship cm3cg, then don't run cm3 -ship for it. > cm3cg is not actually running when cm3 -ship is run. > The reasons cm3 doesn't ship itself do not apply. > > > I agree it seems tempting to sync this behavior with the behavior of shipping cm3. > But I don't think it should be. > > > Yes the files have to be updated together. > You do that by shipping cm3cg and somehow otherwise copying cm3. > I agree that having this "somehow otherwise copy" is not great. > I wonder if we can remove that though. > > > The reason cm3 ship is disabled by default is not so that things are updated together, > but because having an executable copy over itself reportedly does not work on some operating systems. > It is nothing to do with our need to copy multiple files automatically. It is because it will fail. > > > > Now..I must say..Windows is extremely often labeled as one of these systems. > Countless people believe this myth. But it isn't true. > You can copy over an "in use" .dll or .exe. > You merely have to rename it away first. Yes, that is still a bit wierd. > And I have to investigate how to eventually delete it. > Yes, there is a way to defer the delete..until a reboot..if you are an administrator.. > but that is clearly an inadequate mechanism. It is quite possible you open with delete_on_close, > and close, and then the last close might do it, when the .exe stops running. > We should try this out. > > > > However, with Windows possibly eliminated as a concern (once ship does the rename, which it doesn't currently), > does that leave other systems? AIX I believe is similar..that a direct copy will fail. > But will rename work around it there too? > > > Should we let cm3 be able to ship itself, and see what comes of it? > Like, maybe every system people really use can do it? > When an AIX user speaks up, we can fix it then?? > > > > Either way, I believe this change to m3cc/src/m3makefile should be undone. > > > In the meantime, everyone can workaround it by setting the environment variable. > > > The other angle, which I've been pushing unsuccessfully is never update in place. > That is portable. > Start with a new empty directory tree and fill it in by shipping, even cm3. > Like make-dist.py does. > One wrinkle here is that cm3, if it doesn't already, must favor looking next to itself, and not searching $PATH. > So that you ship cm3cg to the new place, and then cm3, and cm3 shipping second finishes the transaction (ok, > you'd also copy/ship other files, like configs and m3core/libm3, and then cm3 last). > > > > I would really really like that code for an executable to find its full path, on all supported systems. > I don't think Posix can do it. Win32 GetModuleFileName(NULL or &__ImageBase) for example. > Then strip off the last path element and append stuff, to find things you go with. > It is a nice technique. > I'm leary of techniques that rely on $PATH search or applying argv[0] to getcwd, as the current directory can change at any time. > > > (and another unsuccessful angle is to move away from all the .sh files; I've been using the .py files for years...well, I was...) > > > > - Jay > > > > > Date: Thu, 28 May 2015 23:05:54 +0200 > > From: wagner at elegosoft.com > > To: jay.krell at cornell.edu > > CC: rodney.m.bates at acm.org; m3devel at elegosoft.com; adacore at marino.st > > Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > > > > On Thu, 28 May 2015 20:14:49 +0000 > > Jay K wrote: > > > > > > Also, this script built the compiler before the support libraries m3core and > > > > libm3. I think there may have been one bootstrap scenario where this was the > > > > way it needed to be done, but usually it is the other way around--these two > > > > libraries first. > > > > > > This is very deliberate and should always work, when doing a native upgrade. > > > It is true it is not always required. > > > When doing a "clean" cross build, it is true that it is backwards. > > > It is required when upgrading from an older build. > > > > > > Native upgrades start at least with a working compiler and its matching runtime. > > > Cross builds start with a working host compiler and nothing for the target -- so they do start with m3core. > > > > I've had a look at the build log, and I think the problem in this case > > with upgrade.py might be that it doesn't install the new backend, but > > only the new frontend: > > > > [...] > > Not shipping cm3cg. > > --- shipping from AMD64_FREEBSD --- > > > > missing ".M3SHIP" file, build the package first. > > dula3/work/bootstrap/bin/cm3 -build -DROOT=/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a +++ > > ==> /mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a/m3-sys/m3cc done > > > > +++ /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin/cm3 -ship -DROOT=/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a +++ > > ==> /mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a/m3-sys/m3cc done > > > > mkdir -p /mech/construction/mech/ptrees/default/lang/modula3/work/stage/usr/local/bin > > cp -Pv /mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a/m3-sys/cm3/AMD64_FREEBSD/cm3 /mech/construction/mech/ptrees/default/lang/modula3/work/stage/usr/local/bin/cm3 > > [...] > > > > In the upgrade.sh script I used install-cm3-compiler.sh, which always > > installs both. In m3-sys/m3cc/src/m3makefile I find the following code: > > > > if equal($INSTALL_CM3_IN_BIN, "yes") > > deriveds("", ["cm3cg", "cm3cg.exe"]) > > write ( "Forced ship of cm3cg." & CR) > > BindExport (AppendExeExtension ("cm3cg")) > > if DoMipsTfile > > BindExport ("mips-tfile") > > end > > else > > write ( "Not shipping cm3cg." & CR) > > end > > > > So perhaps simply setting INSTALL_CM3_IN_BIN=yes in the environment > > will fix that problem? > > > > Olaf > > -- > > Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > > Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From wagner at elego.de Fri May 29 15:58:33 2015 From: wagner at elego.de (Olaf Wagner) Date: Fri, 29 May 2015 15:58:33 +0200 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <5568421D.3050209@marino.st> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop> <556817A1.2090206@marino.st> <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de> <55682D1A.2030504@marino.st> <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de> <55683689.2090709@marino.st> <20150529122732.1396eb079ff9b404bcb21e40@elego.de> <5568421D.3050209@marino.st> Message-ID: <20150529155833.8454664b88391d93708e8f85@elego.de> On Fri, 29 May 2015 12:40:29 +0200 John Marino wrote: > On 5/29/2015 12:27, Olaf Wagner wrote: > > > > > I'm afraid I'll have to reproduce your setup locally on my FreeBSD > > system at home, as I don't see the wrong step in the logs 8-| > > > > After Rodney's success on Linux I was hoping that everything still > > just worked as some years ago. > > > > Just to make sure: you start with a 5.8.6 release archive for > > AMD64_FREEBSD, install that, check out the git sources, and > > run the script(s) in the checked-out repository, correct? Or > > did I miss anything? > > I maintain the "port" for M3 on FreeBSD. see here: > http://www.freshports.org/lang/modula3 > > Because I'm building these in ports, there are certain "rules" I have to > follow using makefiles. I've attached the in-work "port" that I'm > using. You can "rm -rf /usr/ports/lang/modula3; cd /usr/ports/lang; tar > -xf m3-port.tar.gz" to use it to reproduce what I'm doing. > > All you'd do to reproduce is: "cd /usr/ports/lang/modula3 ; make build" > > To be more specific, the current repo is downloaded from github as a > tarball along with the bootstrap compiler (only once, then the tarball > is reused on subsequent). Then it tries to build a new bootstrap > compiler in the build target and that's where it's failing. I unpacked your port and tried the first step. But my system seems to be too old: % make fetch ===> modula3-5.10.0 the bootstrap compiler only runs on FreeBSD 9.0 or later. *** Error code 1 Stop in /src/ports/lang/modula3. Why would it only run on FreeBSD 9? I actually _have_ a working cm3 installation on this system ;-) Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From adacore at marino.st Fri May 29 16:06:30 2015 From: adacore at marino.st (John Marino) Date: Fri, 29 May 2015 16:06:30 +0200 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <20150529155833.8454664b88391d93708e8f85@elego.de> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop> <556817A1.2090206@marino.st> <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de> <55682D1A.2030504@marino.st> <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de> <55683689.2090709@marino.st> <20150529122732.1396eb079ff9b404bcb21e40@elego.de> <5568421D.3050209@marino.st> <20150529155833.8454664b88391d93708e8f85@elego.de> Message-ID: <55687266.3090400@marino.st> On 5/29/2015 15:58, Olaf Wagner wrote: > On Fri, 29 May 2015 12:40:29 +0200 > John Marino wrote: > I unpacked your port and tried the first step. > But my system seems to be too old: > > % make fetch > ===> modula3-5.10.0 the bootstrap compiler only runs on FreeBSD 9.0 or later. > *** Error code 1 This means at best your machine is FreeBSD 8.x. The last FreeBSD 8, 8.4 (a long-term support version) expires in 4 weeks. So you should update. :) > Stop in /src/ports/lang/modula3. > > Why would it only run on FreeBSD 9? > I actually _have_ a working cm3 installation on this system ;-) The port doesn't consider installed CM3. It has to do with how ports are now built in "clean" jails where nothing is installed. You *could* package your working CM3 as a bootstrap compiler [1] but I would think your time would be better spent with FreeBSD Update: https://www.freebsd.org/doc/handbook/updating-upgrading-freebsdupdate.html John [1] Just look in work/bootstrap and emulate if you want to do this. From wagner at elego.de Fri May 29 16:20:28 2015 From: wagner at elego.de (Olaf Wagner) Date: Fri, 29 May 2015 16:20:28 +0200 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <55687266.3090400@marino.st> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop> <556817A1.2090206@marino.st> <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de> <55682D1A.2030504@marino.st> <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de> <55683689.2090709@marino.st> <20150529122732.1396eb079ff9b404bcb21e40@elego.de> <5568421D.3050209@marino.st> <20150529155833.8454664b88391d93708e8f85@elego.de> <55687266.3090400@marino.st> Message-ID: <20150529162028.388911007a614006049beb42@elego.de> On Fri, 29 May 2015 16:06:30 +0200 John Marino wrote: > On 5/29/2015 15:58, Olaf Wagner wrote: > > On Fri, 29 May 2015 12:40:29 +0200 > > John Marino wrote: > > I unpacked your port and tried the first step. > > But my system seems to be too old: > > > > % make fetch > > ===> modula3-5.10.0 the bootstrap compiler only runs on FreeBSD 9.0 or later. > > *** Error code 1 > > This means at best your machine is FreeBSD 8.x. The last FreeBSD 8, 8.4 > (a long-term support version) expires in 4 weeks. So you should update. :) > > > > Stop in /src/ports/lang/modula3. > > > > Why would it only run on FreeBSD 9? > > I actually _have_ a working cm3 installation on this system ;-) > > The port doesn't consider installed CM3. It has to do with how ports > are now built in "clean" jails where nothing is installed. > > You *could* package your working CM3 as a bootstrap compiler [1] but I > would think your time would be better spent with FreeBSD Update: > https://www.freebsd.org/doc/handbook/updating-upgrading-freebsdupdate.html > > John > > > [1] Just look in work/bootstrap and emulate if you want to do this. I will update the system (it's the latest 8.4 stable) but it's unlikely that I'll do it within the next two weeks, because I won't be at home. I'll try to reproduce the problem without the port makefile though. Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From wagner at elego.de Fri May 29 17:23:05 2015 From: wagner at elego.de (Olaf Wagner) Date: Fri, 29 May 2015 17:23:05 +0200 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <20150529162028.388911007a614006049beb42@elego.de> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop> <556817A1.2090206@marino.st> <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de> <55682D1A.2030504@marino.st> <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de> <55683689.2090709@marino.st> <20150529122732.1396eb079ff9b404bcb21e40@elego.de> <5568421D.3050209@marino.st> <20150529155833.8454664b88391d93708e8f85@elego.de> <55687266.3090400@marino.st> <20150529162028.388911007a614006049beb42@elego.de> Message-ID: <20150529172305.a3fc2a9865b5250a5b9140fc@elego.de> On Fri, 29 May 2015 16:20:28 +0200 Olaf Wagner wrote: > On Fri, 29 May 2015 16:06:30 +0200 > John Marino wrote: > > > On 5/29/2015 15:58, Olaf Wagner wrote: > > > On Fri, 29 May 2015 12:40:29 +0200 > > > John Marino wrote: > > > I unpacked your port and tried the first step. > > > But my system seems to be too old: > > > > > > % make fetch > > > ===> modula3-5.10.0 the bootstrap compiler only runs on FreeBSD 9.0 or later. > > > *** Error code 1 > > > > This means at best your machine is FreeBSD 8.x. The last FreeBSD 8, 8.4 > > (a long-term support version) expires in 4 weeks. So you should update. :) > > > > > > > Stop in /src/ports/lang/modula3. > > > > > > Why would it only run on FreeBSD 9? > > > I actually _have_ a working cm3 installation on this system ;-) > > > > The port doesn't consider installed CM3. It has to do with how ports > > are now built in "clean" jails where nothing is installed. > > > > You *could* package your working CM3 as a bootstrap compiler [1] but I > > would think your time would be better spent with FreeBSD Update: > > https://www.freebsd.org/doc/handbook/updating-upgrading-freebsdupdate.html > > > > John > > > > > > [1] Just look in work/bootstrap and emulate if you want to do this. > > I will update the system (it's the latest 8.4 stable) but it's > unlikely that I'll do it within the next two weeks, because I won't > be at home. > > I'll try to reproduce the problem without the port makefile though. The bootstrap compiler backend doesn't run on my system: new exporters -> recompiling FSUtils.i3 /libexec/ld-elf.so.1: /usr/ports/lang/modula3/work/bootstrap//bin/cm3cg: Undefined symbol "_ThreadRuneLocale" m3_backend => 1 m3cc (aka cm3cg) failed compiling: FSUtils.ic It seems there's no way around a system upgrade. But that won't happen today, sorry. I'll make a final test with an older bootstrap archive from opencm3.net later. Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From jay.krell at cornell.edu Fri May 29 17:18:35 2015 From: jay.krell at cornell.edu (Jay K) Date: Fri, 29 May 2015 15:18:35 +0000 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <20150529140402.d87ddf6435a145c466ed3434@elego.de> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop>, , <20150528230554.80920c53f002da8beb3f29d0@elegosoft.com>, , , <20150529140402.d87ddf6435a145c466ed3434@elego.de> Message-ID: I believe the variable existed for cm3, but not m3cc/cm3cg. Rodney added it for m3cc/cm3cg. - Jay > Date: Fri, 29 May 2015 14:04:02 +0200 > From: wagner at elego.de > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com; rodney.m.bates at acm.org > Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > > On Fri, 29 May 2015 11:45:02 +0000 > Jay K wrote: > > > The workaround is bad, as it affects m3-sys/cm3 also. > > Rodney, this really should be removed. If you must have something like this, make it a separate variable from cm3. Please. > > I don't think Rodney introduced this variable ;-) > > Olaf > > > - Jay > > > > > > > > From: jay.krell at cornell.edu > > To: wagner at elegosoft.com > > Date: Fri, 29 May 2015 11:22:15 +0000 > > CC: m3devel at elegosoft.com; rodney.m.bates at acm.org > > Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > > > > > > > > > > > if equal($INSTALL_CM3_IN_BIN, "yes") > > > > > > Hm. That is relatively new. > > Rodney, This is a mistake: > > https://github.com/modula3/cm3/commit/1994f950bb30c3021fd24c07a555f0f7bace933f > > > > > > I see you commented it heavily, but we had working automation before that this broke. > > The automation already took into account what you were trying to take into account. > > > > > > I agree having the config search all over, which I did, is not good, > > as it undermines attempts to ship at just the right time. > > > > > > If you don't want to ship cm3cg, then don't run cm3 -ship for it. > > cm3cg is not actually running when cm3 -ship is run. > > The reasons cm3 doesn't ship itself do not apply. > > > > > > I agree it seems tempting to sync this behavior with the behavior of shipping cm3. > > But I don't think it should be. > > > > > > Yes the files have to be updated together. > > You do that by shipping cm3cg and somehow otherwise copying cm3. > > I agree that having this "somehow otherwise copy" is not great. > > I wonder if we can remove that though. > > > > > > The reason cm3 ship is disabled by default is not so that things are updated together, > > but because having an executable copy over itself reportedly does not work on some operating systems. > > It is nothing to do with our need to copy multiple files automatically. It is because it will fail. > > > > > > > > Now..I must say..Windows is extremely often labeled as one of these systems. > > Countless people believe this myth. But it isn't true. > > You can copy over an "in use" .dll or .exe. > > You merely have to rename it away first. Yes, that is still a bit wierd. > > And I have to investigate how to eventually delete it. > > Yes, there is a way to defer the delete..until a reboot..if you are an administrator.. > > but that is clearly an inadequate mechanism. It is quite possible you open with delete_on_close, > > and close, and then the last close might do it, when the .exe stops running. > > We should try this out. > > > > > > > > However, with Windows possibly eliminated as a concern (once ship does the rename, which it doesn't currently), > > does that leave other systems? AIX I believe is similar..that a direct copy will fail. > > But will rename work around it there too? > > > > > > Should we let cm3 be able to ship itself, and see what comes of it? > > Like, maybe every system people really use can do it? > > When an AIX user speaks up, we can fix it then?? > > > > > > > > Either way, I believe this change to m3cc/src/m3makefile should be undone. > > > > > > In the meantime, everyone can workaround it by setting the environment variable. > > > > > > The other angle, which I've been pushing unsuccessfully is never update in place. > > That is portable. > > Start with a new empty directory tree and fill it in by shipping, even cm3. > > Like make-dist.py does. > > One wrinkle here is that cm3, if it doesn't already, must favor looking next to itself, and not searching $PATH. > > So that you ship cm3cg to the new place, and then cm3, and cm3 shipping second finishes the transaction (ok, > > you'd also copy/ship other files, like configs and m3core/libm3, and then cm3 last). > > > > > > > > I would really really like that code for an executable to find its full path, on all supported systems. > > I don't think Posix can do it. Win32 GetModuleFileName(NULL or &__ImageBase) for example. > > Then strip off the last path element and append stuff, to find things you go with. > > It is a nice technique. > > I'm leary of techniques that rely on $PATH search or applying argv[0] to getcwd, as the current directory can change at any time. > > > > > > (and another unsuccessful angle is to move away from all the .sh files; I've been using the .py files for years...well, I was...) > > > > > > > > - Jay > > > > > > > > > Date: Thu, 28 May 2015 23:05:54 +0200 > > > From: wagner at elegosoft.com > > > To: jay.krell at cornell.edu > > > CC: rodney.m.bates at acm.org; m3devel at elegosoft.com; adacore at marino.st > > > Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > > > > > > On Thu, 28 May 2015 20:14:49 +0000 > > > Jay K wrote: > > > > > > > > Also, this script built the compiler before the support libraries m3core and > > > > > libm3. I think there may have been one bootstrap scenario where this was the > > > > > way it needed to be done, but usually it is the other way around--these two > > > > > libraries first. > > > > > > > > This is very deliberate and should always work, when doing a native upgrade. > > > > It is true it is not always required. > > > > When doing a "clean" cross build, it is true that it is backwards. > > > > It is required when upgrading from an older build. > > > > > > > > Native upgrades start at least with a working compiler and its matching runtime. > > > > Cross builds start with a working host compiler and nothing for the target -- so they do start with m3core. > > > > > > I've had a look at the build log, and I think the problem in this case > > > with upgrade.py might be that it doesn't install the new backend, but > > > only the new frontend: > > > > > > [...] > > > Not shipping cm3cg. > > > --- shipping from AMD64_FREEBSD --- > > > > > > missing ".M3SHIP" file, build the package first. > > > dula3/work/bootstrap/bin/cm3 -build -DROOT=/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a +++ > > > ==> /mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a/m3-sys/m3cc done > > > > > > +++ /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin/cm3 -ship -DROOT=/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a +++ > > > ==> /mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a/m3-sys/m3cc done > > > > > > mkdir -p /mech/construction/mech/ptrees/default/lang/modula3/work/stage/usr/local/bin > > > cp -Pv /mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a/m3-sys/cm3/AMD64_FREEBSD/cm3 /mech/construction/mech/ptrees/default/lang/modula3/work/stage/usr/local/bin/cm3 > > > [...] > > > > > > In the upgrade.sh script I used install-cm3-compiler.sh, which always > > > installs both. In m3-sys/m3cc/src/m3makefile I find the following code: > > > > > > if equal($INSTALL_CM3_IN_BIN, "yes") > > > deriveds("", ["cm3cg", "cm3cg.exe"]) > > > write ( "Forced ship of cm3cg." & CR) > > > BindExport (AppendExeExtension ("cm3cg")) > > > if DoMipsTfile > > > BindExport ("mips-tfile") > > > end > > > else > > > write ( "Not shipping cm3cg." & CR) > > > end > > > > > > So perhaps simply setting INSTALL_CM3_IN_BIN=yes in the environment > > > will fix that problem? > > > > > > Olaf > > > -- > > > Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com > > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > > > Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > > > > -- > Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -------------- next part -------------- An HTML attachment was scrubbed... URL: From adacore at marino.st Fri May 29 17:30:05 2015 From: adacore at marino.st (John Marino) Date: Fri, 29 May 2015 17:30:05 +0200 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <20150529172305.a3fc2a9865b5250a5b9140fc@elego.de> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop> <556817A1.2090206@marino.st> <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de> <55682D1A.2030504@marino.st> <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de> <55683689.2090709@marino.st> <20150529122732.1396eb079ff9b404bcb21e40@elego.de> <5568421D.3050209@marino.st> <20150529155833.8454664b88391d93708e8f85@elego.de> <55687266.3090400@marino.st> <20150529162028.388911007a614006049beb42@elego.de> <20150529172305.a3fc2a9865b5250a5b9140fc@elego.de> Message-ID: <556885FD.6010800@marino.st> On 5/29/2015 17:23, Olaf Wagner wrote: > On Fri, 29 May 2015 16:20:28 +0200 > Olaf Wagner wrote: >> I'll try to reproduce the problem without the port makefile though. > > The bootstrap compiler backend doesn't run on my system: > > new exporters -> recompiling FSUtils.i3 > /libexec/ld-elf.so.1: /usr/ports/lang/modula3/work/bootstrap//bin/cm3cg: Undefined symbol "_ThreadRuneLocale" > m3_backend => 1 > m3cc (aka cm3cg) failed compiling: FSUtils.ic I didn't realize you meant you were going to try the bootstrap outside of the port. I knew that wouldn't work. As to "why", it's my fault. I built the bootstrap on FreeBSD 9, meaning it would work on 9 and new, but not 8. I should have built it on 8 but was tired of fooling with it by that point. > > It seems there's no way around a system upgrade. But that won't happen > today, sorry. > > I'll make a final test with an older bootstrap archive from opencm3.net > later. It might work -- as long as you have older gmp, mpfr, etc. I found the problem with those bootstrap is they were dynamically linked to libraries that don't exist anymore. John From rodney_bates at lcwb.coop Fri May 29 17:55:43 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Fri, 29 May 2015 10:55:43 -0500 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <55683689.2090709@marino.st> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop> <556817A1.2090206@marino.st> <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de> <55682D1A.2030504@marino.st> <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de> <55683689.2090709@marino.st> Message-ID: <55688BFF.5040701@lcwb.coop> I don't know yet why, or what needs to change, but here is definitely the problem, starting in line 4575 of your m3c log: g++48 -O2 -pipe -fstack-protector -Wl,-rpath=/usr/local/lib/gcc48 -fno-strict-aliasing -Wl,-rpath=/usr/local/lib/gcc48 -DIN_GCC -Wno-missing-field-initializers -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -o m3cgc1 m3cg/parse.o attribs.o main.o tree-browser.o libbackend.a libcommon-target.a libcommon.a ../libcpp/libcpp.a libcommon.a ../libcpp/libcpp.a ../libiberty/libiberty.a gmake[1]: Leaving directory `/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a/m3-sys/m3cc/AMD64_FREEBSD/gcc' This is copying the newly-built cm3cg (the compiler back end) to your bin directory: Forced ship of cm3cg. --- shipping from AMD64_FREEBSD --- . => /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin cm3cg ==> m3-sys/m3cc done === package m3-libs/m3core === And this is using the cm3 (compiler front end) that was already in the bin directory, and is the release version. +++ /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin/cm3 -build -DROOT='/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a' $RARGS && /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin/cm3 -ship $RARGS -DROOT='/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a' +++ --- building in AMD64_FREEBSD --- ignoring ../src/m3overrides new source -> compiling RTHooks.i3 This is cm3cg (aka m3cgc1) detecting the incompatibility: m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 compilation terminated. Here is the counterpart section of my log: g++ -g -O2 -DIN_GCC -Wno-missing-field-initializers -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -o m3cgc1 m3cg/parse.o attribs.o main.o tree-browser.o libbackend.a libcommon-target.a libcommon.a ../libcpp/libcpp.a libcommon.a ../libcpp/libcpp.a ../libiberty/libiberty.a On my build, it's not shipping: Not shipping cm3cg. --- shipping from AMD64_LINUX --- missing ".M3SHIP" file, build the package first. ==> /home/rodney/proj/m3/git/cm3/m3-sys/m3cc done === package /home/rodney/proj/m3/git/cm3/m3-libs/m3core === +++ cm3 -build -DROOT='/home/rodney/proj/m3/git/cm3' $RARGS && cm3 -ship $RARGS -DROOT='/home/rodney/proj/m3/git/cm3' +++ --- building in AMD64_LINUX --- ignoring ../src/m3overrides new source -> compiling RTHooks.i3 new source -> compiling RT0.i3 When it works, the copying of both cm3 and cm3cg to the bin directory is delayed until after both have been built, in the 'install-cm3-compiler.sh upgrade' step. I see your build is using a full path to the bin directory and mine is letting it come from the usual $PATH search, but that should make no difference, as long as the bin directory is found in a consistent way, which seems to be the case in both builds. On 05/29/2015 04:51 AM, John Marino wrote: > On 5/29/2015 11:39, Olaf Wagner wrote: >> On Fri, 29 May 2015 11:10:50 +0200 >> John Marino wrote: >> >>> On 5/29/2015 10:54, Olaf Wagner wrote: >>>> Please try what I suggested in the attached mail: define >>>> INSTALL_CM3_IN_BIN=yes >>>> in the environment and see if that helps. >>>> >>> >>> Unfortunately it seems the result is exactly the same, even when >>> INSTALL_CM3_IN_BIN is defined in the environment. >> >> Can I see the new logs? Has the new backend (cm3cg) been installed now? >> > > It's here: > http://leaf.dragonflybsd.org/~marino/m3c.log > > It never completes "do-cm3-front.sh buildship " > > Note that I'm using a bootstrap install and set INSTALL_ROOT to another > location, but it never gets to the point of installing anything. > > John > -- Rodney Bates rodney.m.bates at acm.org From adacore at marino.st Fri May 29 18:03:29 2015 From: adacore at marino.st (John Marino) Date: Fri, 29 May 2015 18:03:29 +0200 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <55688BFF.5040701@lcwb.coop> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop> <556817A1.2090206@marino.st> <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de> <55682D1A.2030504@marino.st> <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de> <55683689.2090709@marino.st> <55688BFF.5040701@lcwb.coop> Message-ID: <55688DD1.9070804@marino.st> On 5/29/2015 17:55, Rodney M. Bates wrote: > This is copying the newly-built cm3cg (the compiler back end) to your > bin directory: > > Forced ship of cm3cg. > --- shipping from AMD64_FREEBSD --- > > . => > /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin > cm3cg > ==> m3-sys/m3cc done Ok, I was expecting it to install at: /mech/construction/mech/ptrees/default/lang/modula3/work/intermediate/bin I was not trying to overwrite the bootstrap, but create a minimal new one that could build the whole thing (like I did before with boot-cm3-with-cm3) > This is cm3cg (aka m3cgc1) detecting the incompatibility: > > m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected > 0x110 > compilation terminated. Not surprising considering above... John From wagner at elego.de Fri May 29 18:02:23 2015 From: wagner at elego.de (Olaf Wagner) Date: Fri, 29 May 2015 18:02:23 +0200 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <556885FD.6010800@marino.st> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop> <556817A1.2090206@marino.st> <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de> <55682D1A.2030504@marino.st> <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de> <55683689.2090709@marino.st> <20150529122732.1396eb079ff9b404bcb21e40@elego.de> <5568421D.3050209@marino.st> <20150529155833.8454664b88391d93708e8f85@elego.de> <55687266.3090400@marino.st> <20150529162028.388911007a614006049beb42@elego.de> <20150529172305.a3fc2a9865b5250a5b9140fc@elego.de> <556885FD.6010800@marino.st> Message-ID: <20150529180223.d467621b68ebf665da685b12@elego.de> On Fri, 29 May 2015 17:30:05 +0200 John Marino wrote: > > I'll make a final test with an older bootstrap archive from opencm3.net > > later. > > It might work -- as long as you have older gmp, mpfr, etc. I found the > problem with those bootstrap is they were dynamically linked to > libraries that don't exist anymore. Surprisingly, that went very well without any problem :-) [...] Critical Mass Modula-3 version d5.10.0 last updated: 2015-05-21 compiled: 2015-05-29 15:50:50 configuration: /usr/ports/lang/modula3/work/bootstrap/bin/cm3.cfg host: AMD64_FREEBSD target: AMD64_FREEBSD Modula-3 backend (GCC) version 4.7.1 (x86_64-unknown-freebsd8.4) compiled by GNU C version 4.2.1 20070831 patched [FreeBSD], GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 create config directory /usr/ports/lang/modula3/work/bootstrap/bin/config new config files copied/generated in /usr/ports/lang/modula3/work/bootstrap/bin/cm3.cfg, /usr/ports/lang/modula3/work/bootstrap/bin/config Let's see what I have and did: % uname -a FreeBSD luthien.iceflower.in-berlin.de 8.4-STABLE FreeBSD 8.4-STABLE #0 r268069: Tue Jul 1 23:12:27 CEST 2014 root at luthien:/src/obj/src/sys/GENERIC amd64 Current Code Base form Github: % wget --no-check-certificate https://codeload.github.com/modula3/cm3/tar.gz Old CM3 5.8.6 archive from www.opencm3.net: % wget --no-check-certificate http://www.opencm3.net/releng/cm3-bin-core-AMD64_FREEBSD-5.8.6-REL.tgz I unpacked the system.tgz archive contained in the cm3-bin-core archive into a bootstrap directory and set some path: % echo $PATH /usr/ports/lang/modula3/work/bootstrap/bin:/home/wagner/bin:/usr/local/dcvs/bin:/usr/local/cm3/bin:/bin:/usr/bin:/usr/local/bin:/usr/contrib/bin:/usr/gnu/bin:/usr/X11R6/bin:/usr/local/sbin:/usr/sbin:/sbin:/sbin:/usr/sbin % echo $LD_LIBRARY_PATH /usr/ports/lang/modula3/work/bootstrap/lib I had to fake libgmp.so.8 by making a link to libgmp.so.10 for the old cm3cg: % sudo ln -s /usr/local/lib/libgmp.so /usr/local/lib/libgmp.so.8 % cd cm3-8c1b86a/ % ./scripts/upgrade.sh I didn't apply any patches. I can repeat everything and send you the log, or you could even get a login on that machine to have a look around. Let me know what you need. I hope this helps, Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From adacore at marino.st Fri May 29 18:14:29 2015 From: adacore at marino.st (John Marino) Date: Fri, 29 May 2015 18:14:29 +0200 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <20150529180223.d467621b68ebf665da685b12@elego.de> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop> <556817A1.2090206@marino.st> <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de> <55682D1A.2030504@marino.st> <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de> <55683689.2090709@marino.st> <20150529122732.1396eb079ff9b404bcb21e40@elego.de> <5568421D.3050209@marino.st> <20150529155833.8454664b88391d93708e8f85@elego.de> <55687266.3090400@marino.st> <20150529162028.388911007a614006049beb42@elego.de> <20150529172305.a3fc2a9865b5250a5b9140fc@elego.de> <556885FD.6010800@marino.st> <20150529180223.d467621b68ebf665da685b12@elego.de> Message-ID: <55689065.1040207@marino.st> On 5/29/2015 18:02, Olaf Wagner wrote: > On Fri, 29 May 2015 17:30:05 +0200 > John Marino wrote: > >>> I'll make a final test with an older bootstrap archive from opencm3.net >>> later. >> >> It might work -- as long as you have older gmp, mpfr, etc. I found the >> problem with those bootstrap is they were dynamically linked to >> libraries that don't exist anymore. > > Surprisingly, that went very well without any problem :-) I'm having a hard time understanding what went very well. I think you are saying you took an old bootstrap from an archive, and did Rodney's manual steps and it built without the errors I have. If so, that doesn't particularly help me unless I want to manually build another bootstrap. I have to get this thing building systematically without manual intervention or overwriting itself within a port's work area inside a clean jail. Probably my attempt isn't following Rodney's approach exactly, and maybe I have to overwrite the bootstrap rather than create an intermediate one. I'll be curious how this goes with the port and the current bootstrap (I'm trying to avoid having to generate a new 5.10 bootstrap when I feel it should be possible to use 5.8.6, but If I had to, I will) John From rodney_bates at lcwb.coop Fri May 29 18:35:41 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Fri, 29 May 2015 11:35:41 -0500 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <55688BFF.5040701@lcwb.coop> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop> <556817A1.2090206@marino.st> <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de> <55682D1A.2030504@marino.st> <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de> <55683689.2090709@marino.st> <55688BFF.5040701@lcwb.coop> Message-ID: <5568955D.4060200@lcwb.coop> Setting INSTALL_CM3_IN_BIN=yes is what forces the premature install of cm3cg. I see I had encountered this problem two years ago, but then it was happening regardless of the value of this variable. My fix only addresses the case when the variable is not set. I naively went to extra trouble to preserve the existing behavior when it is set--obviously not right. I don't see an easy way to make the variable work, as there is no constraint on the order that cm3 and cm3cg are built. do-cm3-front.sh happens to do cm3cg first, but that is not necessarily required. So INSTALL_CM3_IN_BIN is broken and hard to fix, if the two need compatible upgrades. For now, it looks like install-cm3-compiler.sh is the only working way. But maybe John and Olaf have found a different way around this. On 05/29/2015 10:55 AM, Rodney M. Bates wrote: > I don't know yet why, or what needs to change, but here is definitely the problem, starting > in line 4575 of your m3c log: > > > g++48 -O2 -pipe -fstack-protector -Wl,-rpath=/usr/local/lib/gcc48 -fno-strict-aliasing -Wl,-rpath=/usr/local/lib/gcc48 -DIN_GCC -Wno-missing-field-initializers -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -o m3cgc1 m3cg/parse.o attribs.o main.o tree-browser.o libbackend.a libcommon-target.a libcommon.a ../libcpp/libcpp.a libcommon.a ../libcpp/libcpp.a ../libiberty/libiberty.a > gmake[1]: Leaving directory `/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a/m3-sys/m3cc/AMD64_FREEBSD/gcc' > > > This is copying the newly-built cm3cg (the compiler back end) to your > bin directory: > > Forced ship of cm3cg. > --- shipping from AMD64_FREEBSD --- > > . => /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin > cm3cg > ==> m3-sys/m3cc done > > === package m3-libs/m3core === > > And this is using the cm3 (compiler front end) that was already in the bin > directory, and is the release version. > > +++ /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin/cm3 -build -DROOT='/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a' $RARGS && /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin/cm3 -ship $RARGS -DROOT='/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a' +++ > --- building in AMD64_FREEBSD --- > > ignoring ../src/m3overrides > > new source -> compiling RTHooks.i3 > > This is cm3cg (aka m3cgc1) detecting the incompatibility: > > m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > compilation terminated. > > Here is the counterpart section of my log: > > g++ -g -O2 -DIN_GCC -Wno-missing-field-initializers -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -o m3cgc1 m3cg/parse.o attribs.o main.o tree-browser.o libbackend.a libcommon-target.a libcommon.a ../libcpp/libcpp.a libcommon.a ../libcpp/libcpp.a ../libiberty/libiberty.a > > On my build, it's not shipping: > > Not shipping cm3cg. > --- shipping from AMD64_LINUX --- > > missing ".M3SHIP" file, build the package first. > ==> /home/rodney/proj/m3/git/cm3/m3-sys/m3cc done > > === package /home/rodney/proj/m3/git/cm3/m3-libs/m3core === > +++ cm3 -build -DROOT='/home/rodney/proj/m3/git/cm3' $RARGS && cm3 -ship $RARGS -DROOT='/home/rodney/proj/m3/git/cm3' +++ > --- building in AMD64_LINUX --- > > ignoring ../src/m3overrides > > new source -> compiling RTHooks.i3 > new source -> compiling RT0.i3 > > When it works, the copying of both cm3 and cm3cg to the bin directory is delayed until after both have been > built, in the 'install-cm3-compiler.sh upgrade' step. > > I see your build is using a full path to the bin directory and mine is letting > it come from the usual $PATH search, but that should make no difference, as long > as the bin directory is found in a consistent way, which seems to be the case > in both builds. > > > > On 05/29/2015 04:51 AM, John Marino wrote: >> On 5/29/2015 11:39, Olaf Wagner wrote: >>> On Fri, 29 May 2015 11:10:50 +0200 >>> John Marino wrote: >>> >>>> On 5/29/2015 10:54, Olaf Wagner wrote: >>>>> Please try what I suggested in the attached mail: define >>>>> INSTALL_CM3_IN_BIN=yes >>>>> in the environment and see if that helps. >>>>> >>>> >>>> Unfortunately it seems the result is exactly the same, even when >>>> INSTALL_CM3_IN_BIN is defined in the environment. >>> >>> Can I see the new logs? Has the new backend (cm3cg) been installed now? >>> >> >> It's here: >> http://leaf.dragonflybsd.org/~marino/m3c.log >> >> It never completes "do-cm3-front.sh buildship " >> >> Note that I'm using a bootstrap install and set INSTALL_ROOT to another >> location, but it never gets to the point of installing anything. >> >> John >> > -- Rodney Bates rodney.m.bates at acm.org From jay.krell at cornell.edu Fri May 29 20:03:10 2015 From: jay.krell at cornell.edu (Jay K) Date: Fri, 29 May 2015 18:03:10 +0000 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <556885FD.6010800@marino.st> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop> <556817A1.2090206@marino.st> <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de> <55682D1A.2030504@marino.st> <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de> <55683689.2090709@marino.st> <20150529122732.1396eb079ff9b404bcb21e40@elego.de> <5568421D.3050209@marino.st> <20150529155833.8454664b88391d93708e8f85@elego.de> <55687266.3090400@marino.st> <20150529162028.388911007a614006049beb42@elego.de>, <20150529172305.a3fc2a9865b5250a5b9140fc@elego.de>, <556885FD.6010800@marino.st> Message-ID: > It might work -- as long as you have older gmp, mpfr, etc. I found the > problem with those bootstrap is they were dynamically linked to > libraries that don't exist anymore. We went far out of our way to statically link this. Darn. > > /libexec/ld-elf.so.1: /usr/ports/lang/modula3/work/bootstrap//bin/cm3cg: Undefined symbol "_ThreadRuneLocale" _ThreadRuneLocale --- we should look into.Ideally we can build on newer systems and still target older systems.That is very commonly done on Mac and Windows, at least.Maybe there are #defines or config to suppress unused newer stuff? I also went out of my way to suppress dynamic links to libiconv.That has been a problem e.g. on Solaris.It was coming in I believe because cm3cg linked in a C preprocessor (seriously),because you know, like, all gcc frontends can use that.. (and the cm3cg backend again,is a gcc frontend, for an unusual binary-encoded language).. - Jay [snip] -------------- next part -------------- An HTML attachment was scrubbed... URL: From adacore at marino.st Fri May 29 20:10:35 2015 From: adacore at marino.st (John Marino) Date: Fri, 29 May 2015 20:10:35 +0200 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop> <556817A1.2090206@marino.st> <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de> <55682D1A.2030504@marino.st> <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de> <55683689.2090709@marino.st> <20150529122732.1396eb079ff9b404bcb21e40@elego.de> <5568421D.3050209@marino.st> <20150529155833.8454664b88391d93708e8f85@elego.de> <55687266.3090400@marino.st> <20150529162028.388911007a614006049beb42@elego.de>, <20150529172305.a3fc2a9865b5250a5b9140fc@elego.de>, <556885FD.6010800@marino.st> Message-ID: <5568AB9B.3010101@marino.st> On 5/29/2015 20:03, Jay K wrote: > > > It might work -- as long as you have older gmp, mpfr, etc. I found the > > problem with those bootstrap is they were dynamically linked to > > libraries that don't exist anymore. > > > We went far out of our way to statically link this. Darn. It is okay, the port M3 bootstrap is statically linked. > _ThreadRuneLocale --- we should look into. > Ideally we can build on newer systems and still target older systems. > That is very commonly done on Mac and Windows, at least. > Maybe there are #defines or config to suppress unused newer stuff? This was 100% my fault. The bootstrap was built on FreeBSD 9. I should have built it on FreeBSD 8, but I didn't know the impact. If I had done that, you wouldn't be seeing this error. FreeBSD 8 "expires" at the end of June, so it's a non-issue really. John From wagner at elegosoft.com Fri May 29 20:11:24 2015 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 29 May 2015 20:11:24 +0200 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <5568955D.4060200@lcwb.coop> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop> <556817A1.2090206@marino.st> <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de> <55682D1A.2030504@marino.st> <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de> <55683689.2090709@marino.st> <55688BFF.5040701@lcwb.coop> <5568955D.4060200@lcwb.coop> Message-ID: <20150529201124.fd4b2bc6b239df2a7a97cc19@elegosoft.com> On Fri, 29 May 2015 11:35:41 -0500 "Rodney M. Bates" wrote: > Setting INSTALL_CM3_IN_BIN=yes is what forces the premature install of cm3cg. > I see I had encountered this problem two years ago, but then it was happening > regardless of the value of this variable. My fix only addresses the case when > the variable is not set. I naively went to extra trouble to preserve the > existing behavior when it is set--obviously not right. > > I don't see an easy way to make the variable work, as there is no > constraint on the order that cm3 and cm3cg are built. do-cm3-front.sh > happens to do cm3cg first, but that is not necessarily required. > > So INSTALL_CM3_IN_BIN is broken and hard to fix, if the two need > compatible upgrades. For now, it looks like install-cm3-compiler.sh > is the only working way. > > But maybe John and Olaf have found a different way around this. Setting that to yes was just my suggestion after seeing in the first log that he did install cm3 but not cm3cg. I think we should all forget about INSTALL_CM3_IN_BIN now and leave that unset. I still don't undertstand what he's doing differently than a simple upgrade of the compiler based on an initial install, which does work for AMD64_FREEBSD, as I have tested it. I think it's the elaborate setup and build environment into which the rather inflexible cm3 installation is forced. Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Fri May 29 20:06:11 2015 From: jay.krell at cornell.edu (Jay K) Date: Fri, 29 May 2015 18:06:11 +0000 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <5568955D.4060200@lcwb.coop> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop> <556817A1.2090206@marino.st> <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de> <55682D1A.2030504@marino.st> <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de> <55683689.2090709@marino.st>, <55688BFF.5040701@lcwb.coop>, <5568955D.4060200@lcwb.coop> Message-ID: > I don't see an easy way to make the variable work, as there is no > constraint on the order that cm3 and cm3cg are built. do-cm3-front.sh > happens to do cm3cg first, but that is not necessarily required. [please pardon my editing...] I see what you mean that cm3cg is an independent node in the graph and can be built in any order,but, I guess, the story is/was, you have to know the safe order to ship things. It is encoded in pkginfo.txt and the Python scripts honor it..though they don't always use pkginfo.txt for their ordering..And encoding the dependency graph there isn't ideal. It is really encoded in the import declarationsin the m3makefiles, usually, but not in this case... The way that works is to build but don't ship cm3cg. Then ship cm3cg. Then copy cm3. Then use the new cm3. But perhaps it isn't strictly enforced enough. I used do this fairly often. Though breaking changes in cm3cg were rare, granted. But I'd also occasionally bootstrap from an older release. I'll have to try to do that again soon -- actually make the current tree easily buildable from the last release. update.py handled it. I'm on the fence. "buildship" of multiple packages is in general problematic. I kinda think the whole mechanism needs to be revampled. Let me draw a close analogy. In the slightly larger software world we have: make make install make install DESTDIR=somewhere_new buildship is equivalent make && make install, or a make install that includes the make part, as they sometimes do. Read up on building glibc and they point out how dangerous this is -- how dangerous make install is w/o DESTDIR. We have the same danger on a smaller scale. You aren't going to break the "OS", but you can break "cm3". The safe recommendation is make install DESTDIR. Basically "install" "everything" "on the side", get it all installed, multiple "packages", then copy or tar/untar it all. Or chroot into it and test it out, and then do an in-place update. Or swap into the chroot and never return? (tail call install) Don't do a "rolling upgrade". Don't install each package as it is built. No package, no cm3, not cm3cg, nothing. I'm basically suggesting that. Now, if you say "don't ever ship, but somehow otherwise manually copy", well that does kind of resolve to the same thing. If you say, "almost don't ever ship, but provide a way to", that is almost the same. make-dist.py follows the make install DESTDIR way. It is "better" I guess because I wrote it later, and because I was following the example of the other .sh files that make distributions. So blame/credit Olaf? :) It starts with a working compiler, copies parts into /temp, builds a new compiler into /tmp, and uses what it builds to build everything. Again I suggest it be looked into, and maybe be promoted as basically the replacement for upgrade.py and upgrade.sh. upgrade.py could wrap it and do the final steps of copy/untar in-place. Or make-dist.py could just print the last optional command. Anyway, I have no time lately, just email. :( - Jay > Date: Fri, 29 May 2015 11:35:41 -0500 > From: rodney_bates at lcwb.coop > To: adacore at marino.st; wagner at elego.de > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > > Setting INSTALL_CM3_IN_BIN=yes is what forces the premature install of cm3cg. > I see I had encountered this problem two years ago, but then it was happening > regardless of the value of this variable. My fix only addresses the case when > the variable is not set. I naively went to extra trouble to preserve the > existing behavior when it is set--obviously not right. > > I don't see an easy way to make the variable work, as there is no > constraint on the order that cm3 and cm3cg are built. do-cm3-front.sh > happens to do cm3cg first, but that is not necessarily required. > > So INSTALL_CM3_IN_BIN is broken and hard to fix, if the two need > compatible upgrades. For now, it looks like install-cm3-compiler.sh > is the only working way. > > But maybe John and Olaf have found a different way around this. > > On 05/29/2015 10:55 AM, Rodney M. Bates wrote: > > I don't know yet why, or what needs to change, but here is definitely the problem, starting > > in line 4575 of your m3c log: > > > > > > g++48 -O2 -pipe -fstack-protector -Wl,-rpath=/usr/local/lib/gcc48 -fno-strict-aliasing -Wl,-rpath=/usr/local/lib/gcc48 -DIN_GCC -Wno-missing-field-initializers -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -o m3cgc1 m3cg/parse.o attribs.o main.o tree-browser.o libbackend.a libcommon-target.a libcommon.a ../libcpp/libcpp.a libcommon.a ../libcpp/libcpp.a ../libiberty/libiberty.a > > gmake[1]: Leaving directory `/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a/m3-sys/m3cc/AMD64_FREEBSD/gcc' > > > > > > This is copying the newly-built cm3cg (the compiler back end) to your > > bin directory: > > > > Forced ship of cm3cg. > > --- shipping from AMD64_FREEBSD --- > > > > . => /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin > > cm3cg > > ==> m3-sys/m3cc done > > > > === package m3-libs/m3core === > > > > And this is using the cm3 (compiler front end) that was already in the bin > > directory, and is the release version. > > > > +++ /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin/cm3 -build -DROOT='/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a' $RARGS && /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin/cm3 -ship $RARGS -DROOT='/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a' +++ > > --- building in AMD64_FREEBSD --- > > > > ignoring ../src/m3overrides > > > > new source -> compiling RTHooks.i3 > > > > This is cm3cg (aka m3cgc1) detecting the incompatibility: > > > > m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > > compilation terminated. > > > > Here is the counterpart section of my log: > > > > g++ -g -O2 -DIN_GCC -Wno-missing-field-initializers -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -o m3cgc1 m3cg/parse.o attribs.o main.o tree-browser.o libbackend.a libcommon-target.a libcommon.a ../libcpp/libcpp.a libcommon.a ../libcpp/libcpp.a ../libiberty/libiberty.a > > > > On my build, it's not shipping: > > > > Not shipping cm3cg. > > --- shipping from AMD64_LINUX --- > > > > missing ".M3SHIP" file, build the package first. > > ==> /home/rodney/proj/m3/git/cm3/m3-sys/m3cc done > > > > === package /home/rodney/proj/m3/git/cm3/m3-libs/m3core === > > +++ cm3 -build -DROOT='/home/rodney/proj/m3/git/cm3' $RARGS && cm3 -ship $RARGS -DROOT='/home/rodney/proj/m3/git/cm3' +++ > > --- building in AMD64_LINUX --- > > > > ignoring ../src/m3overrides > > > > new source -> compiling RTHooks.i3 > > new source -> compiling RT0.i3 > > > > When it works, the copying of both cm3 and cm3cg to the bin directory is delayed until after both have been > > built, in the 'install-cm3-compiler.sh upgrade' step. > > > > I see your build is using a full path to the bin directory and mine is letting > > it come from the usual $PATH search, but that should make no difference, as long > > as the bin directory is found in a consistent way, which seems to be the case > > in both builds. > > > > > > > > On 05/29/2015 04:51 AM, John Marino wrote: > >> On 5/29/2015 11:39, Olaf Wagner wrote: > >>> On Fri, 29 May 2015 11:10:50 +0200 > >>> John Marino wrote: > >>> > >>>> On 5/29/2015 10:54, Olaf Wagner wrote: > >>>>> Please try what I suggested in the attached mail: define > >>>>> INSTALL_CM3_IN_BIN=yes > >>>>> in the environment and see if that helps. > >>>>> > >>>> > >>>> Unfortunately it seems the result is exactly the same, even when > >>>> INSTALL_CM3_IN_BIN is defined in the environment. > >>> > >>> Can I see the new logs? Has the new backend (cm3cg) been installed now? > >>> > >> > >> It's here: > >> http://leaf.dragonflybsd.org/~marino/m3c.log > >> > >> It never completes "do-cm3-front.sh buildship " > >> > >> Note that I'm using a bootstrap install and set INSTALL_ROOT to another > >> location, but it never gets to the point of installing anything. > >> > >> John > >> > > > > -- > Rodney Bates > rodney.m.bates at acm.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Fri May 29 20:15:31 2015 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 29 May 2015 20:15:31 +0200 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <55689065.1040207@marino.st> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop> <556817A1.2090206@marino.st> <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de> <55682D1A.2030504@marino.st> <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de> <55683689.2090709@marino.st> <20150529122732.1396eb079ff9b404bcb21e40@elego.de> <5568421D.3050209@marino.st> <20150529155833.8454664b88391d93708e8f85@elego.de> <55687266.3090400@marino.st> <20150529162028.388911007a614006049beb42@elego.de> <20150529172305.a3fc2a9865b5250a5b9140fc@elego.de> <556885FD.6010800@marino.st> <20150529180223.d467621b68ebf665da685b12@elego.de> <55689065.1040207@marino.st> Message-ID: <20150529201531.b35e3cfdafeb9e2735e0020b@elegosoft.com> On Fri, 29 May 2015 18:14:29 +0200 John Marino wrote: > On 5/29/2015 18:02, Olaf Wagner wrote: > > On Fri, 29 May 2015 17:30:05 +0200 > > John Marino wrote: > > > >>> I'll make a final test with an older bootstrap archive from opencm3.net > >>> later. > >> > >> It might work -- as long as you have older gmp, mpfr, etc. I found the > >> problem with those bootstrap is they were dynamically linked to > >> libraries that don't exist anymore. > > > > Surprisingly, that went very well without any problem :-) > > I'm having a hard time understanding what went very well. I think you > are saying you took an old bootstrap from an archive, and did Rodney's > manual steps and it built without the errors I have. > > If so, that doesn't particularly help me unless I want to manually build > another bootstrap. I have to get this thing building systematically > without manual intervention or overwriting itself within a port's work > area inside a clean jail. > > Probably my attempt isn't following Rodney's approach exactly, and maybe > I have to overwrite the bootstrap rather than create an intermediate one. > > I'll be curious how this goes with the port and the current bootstrap > (I'm trying to avoid having to generate a new 5.10 bootstrap when I feel > it should be possible to use 5.8.6, but If I had to, I will) Well, yes, I understand that. I would have tried your exact setup, but I have no system available to test that on. At least I have validated that based on the origianl 5.8.6 installation archive for AMD64_FREEBSD you can build the new compiler from the current sources with a simple call of the upgrade.sh script. which I still doubted yesterday. Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From adacore at marino.st Fri May 29 20:43:30 2015 From: adacore at marino.st (John Marino) Date: Fri, 29 May 2015 20:43:30 +0200 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <20150529201531.b35e3cfdafeb9e2735e0020b@elegosoft.com> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop> <556817A1.2090206@marino.st> <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de> <55682D1A.2030504@marino.st> <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de> <55683689.2090709@marino.st> <20150529122732.1396eb079ff9b404bcb21e40@elego.de> <5568421D.3050209@marino.st> <20150529155833.8454664b88391d93708e8f85@elego.de> <55687266.3090400@marino.st> <20150529162028.388911007a614006049beb42@elego.de> <20150529172305.a3fc2a9865b5250a5b9140fc@elego.de> <556885FD.6010800@marino.st> <20150529180223.d467621b68ebf665da685b12@elego.de> <55689065.1040207@marino.st> <20150529201531.b35e3cfdafeb9e2735e0020b@elegosoft.com> Message-ID: <5568B352.8060005@marino.st> On 5/29/2015 20:15, Olaf Wagner wrote: > > Well, yes, I understand that. I would have tried your exact setup, > but I have no system available to test that on. > > At least I have validated that based on the origianl 5.8.6 installation > archive for AMD64_FREEBSD you can build the new compiler from the current > sources with a simple call of the upgrade.sh script. which I still doubted > yesterday. The card I still have left to play is to extract the bootstrap, let it overwrite itself per Rodney's technique and then build the real compiler (dumping the whole "intermediate" area). I would try that now but I've booted into another OS to work on some GCC patches that are long overdue to be submitted. John From estellnb at elstel.org Fri May 29 21:00:44 2015 From: estellnb at elstel.org (Elmar Stellnberger) Date: Fri, 29 May 2015 21:00:44 +0200 Subject: [M3devel] WeakRef.T does not clean all WeakRefs on prorgam exit Message-ID: <5568B75C.4010202@elstel.org> Today I was writing an object oriented interface to some external library. As every object holds at least a reference to an embedded C-heap object I wanted to make use of WeakRefs to get an automatic cleanup for the embedded C-heap objects. However I had to notice that no cleanup occurs and that the reference can still be reconstructed from the WeakRef even after assigning NULL and running the garbage collector by calling two times RTCollectorSRC.StartCollection & FinishCollection in sequence. I have further tried to disable incremental and generational collection and to set the gcRatio to 100.0 as well as moving the RefAny into a subprocedure but all of it did not help either. There is only one Refany in my program and thus no cyclic dependency. Does anyone have a suggestion on how I could make the automatic cleanup work ready for testing it (appart from calling the cleanup proc directly)? From the past I know the WeakRef implementation of PM3 to some extent: there was no special cleanup on program exit. I believe on program exit all WeakRefs should be freed in order to let the operating system reclaim all resources. Under Linux that should work automatically though some resources like sockets may last long until they become available again. Other OSes like the eComstation can not reclaim all resources when it comes f.i. to shared memory. Anyone here who believes that special cleanup for WeakRefs should be done on program exit? ... and one more question about how to handle WeakRefs? Do I need to keep the WeakRef-record after installing the cleanup proc with WeakRef.FromRef(...)? - or may I simply discard it while the cleanup should still be done without it? From estellnb at elstel.org Fri May 29 21:13:38 2015 From: estellnb at elstel.org (Elmar Stellnberger) Date: Fri, 29 May 2015 21:13:38 +0200 Subject: [M3devel] WeakRef.T does not clean all WeakRefs on prorgam exit Message-ID: <5568BA62.9070109@elstel.org> Today I was writing an object oriented interface to some external library. As every object holds at least a reference to an embedded C-heap object I wanted to make use of WeakRefs to get an automatic cleanup for the embedded C-heap objects. However I had to notice that no cleanup occurs and that the reference can still be reconstructed from the WeakRef even after assigning NULL and running the garbage collector by calling two times RTCollectorSRC.StartCollection & FinishCollection in sequence. I have further tried to disable incremental and generational collection and to set the gcRatio to 100.0 as well as moving the RefAny into a subprocedure but all of it did not help either. There is only one Refany in my program and thus no cyclic dependency. Does anyone have a suggestion on how I could make the automatic cleanup work ready for testing it (appart from calling the cleanup proc directly)? From the past I know the WeakRef implementation of PM3 to some extent: there was no special cleanup on program exit. I believe on program exit all WeakRefs should be freed in order to let the operating system reclaim all resources. Under Linux that should work automatically though some resources like sockets may last long until they become available again. Other OSes like the eComstation can not reclaim all resources when it comes f.i. to shared memory. Anyone here who believes that special cleanup for WeakRefs should be done on program exit? ... and one more question about how to handle WeakRefs? Do I need to keep the WeakRef-record after installing the cleanup proc with WeakRef.FromRef(...)? - or may I simply discard it while the cleanup should still be done without it? From jay.krell at cornell.edu Fri May 29 22:49:30 2015 From: jay.krell at cornell.edu (Jay K) Date: Fri, 29 May 2015 20:49:30 +0000 Subject: [M3devel] WeakRef.T does not clean all WeakRefs on prorgam exit In-Reply-To: <5568BA62.9070109@elstel.org> References: <5568BA62.9070109@elstel.org> Message-ID: Imho you should take this approach: If you are only managing memory and file handles and socket handles, or Win32 kernel handles (events/mutexes/semaphores/registry keys), you should just rely on the kernel cleaning everything up when the process dies. Doing everything peacemeal is just a waste of time. Imagine that there is a null deref and you abruptly go away.That shouldn't/doesn't leak either.And attempting to cleanup in this path is dangerous. In fact, any resource that you want to guaranteeably be cleaned up, should be backed by the kernel. If you are talking over the network to something, and you abruptly exit, that network server will eventually notice a timeout and clean up anything it has allocated on your behalf. Now, on the other hand, if your .dll is gracefull unloaded and the processis still running, that is another matter, and one I suspect we don't handle.I'm not sure we really handle .dll/.sos in Modula-3 w/o the main executable being Modula-3.That could use repair.On Windows it is a matter of writing DllMain in m3core.Likely something similar on the other systems. Heck, maybe just a C++ static with a constructor and destructor.That is kinda the portable interface to DllMain(process attach) and whatever are the Unix analogs.Seriously. Just as we have main optionally in C. Agreed? Thread notifications would also be nice. This is an area that hasn't evolved as well as process notification. - Jay > Date: Fri, 29 May 2015 21:13:38 +0200 > From: estellnb at elstel.org > To: m3devel at elegosoft.com > Subject: [M3devel] WeakRef.T does not clean all WeakRefs on prorgam exit > > Today I was writing an object oriented interface to some external > library. > As every object holds at least a reference to an embedded C-heap object I > wanted to make use of WeakRefs to get an automatic cleanup for the > embedded C-heap objects. However I had to notice that no cleanup occurs > and that the reference can still be reconstructed from the WeakRef even > after assigning NULL and running the garbage collector by calling two times > RTCollectorSRC.StartCollection & FinishCollection in sequence. I have > further tried to disable incremental and generational collection and to set > the gcRatio to 100.0 as well as moving the RefAny into a subprocedure > but all of it did not help either. There is only one Refany in my program > and thus no cyclic dependency. > Does anyone have a suggestion on how I could make the automatic > cleanup work ready for testing it (appart from calling the cleanup proc > directly)? > From the past I know the WeakRef implementation of PM3 to some extent: > there was no special cleanup on program exit. I believe on program exit > all WeakRefs should be freed in order to let the operating system reclaim > all resources. Under Linux that should work automatically though some > resources like sockets may last long until they become available again. > Other OSes like the eComstation can not reclaim all resources when it > comes f.i. to shared memory. > Anyone here who believes that special cleanup for WeakRefs should be > done on program exit? > > ... and one more question about how to handle WeakRefs? > Do I need to keep the WeakRef-record after installing the cleanup proc > with WeakRef.FromRef(...)? - or may I simply discard it while the cleanup > should still be done without it? > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Fri May 29 23:10:41 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Fri, 29 May 2015 16:10:41 -0500 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop> <556817A1.2090206@marino.st> <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de> <55682D1A.2030504@marino.st> <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de> <55683689.2090709@marino.st>, <55688BFF.5040701@lcwb.coop>, <5568955D.4060200@lcwb.coop> Message-ID: <5568D5D1.5040405@lcwb.coop> Yes, we could have a better organization. I agree, the principal way should be to build a complete set of everything that matters to the implementation of the language, them replace them all at once. A separate DESTDIR or such is needed. The set, as Jay points out, is larger than just cm3 and m3cc. It includes at least m3core, probably libm3, and cm3, the executable depends on several separately built packages--cm3, m3middle, m3front, m3quake, m3makefile, etc. In general, we can't really assume anything about the kinds of dependencies of one package on old or new versions of another. Right now, cm3 and m3cc are known mutually incompatible between 5.8 and the head, because the numbering in M3CG_Binary.i3 has changed. We could probably establish some coding rules and order-of-install rules that would allow a newer m3cc to work with an older cm3, but that's only one pattern. I once thought do-cm3-*.sh build would do what we are talking about, but it if I remember right, puts every package into immediate use as it is built and also uses overrides, which keeps things inside the source tree, but makes it unshippable. So I always use buildship. This has never, to my knowledge run afoul of any compatibility problem other than between cm3 and m3cc, but it does ship every package besides these two as it is built, so the potential is there. I haven't had the energy to even try to understand just what the upgrade scripts do, but they have not treated me well. If I had done different patterns of incompatible changes, they would probably have been better than the procedure I use. On 05/29/2015 01:06 PM, Jay K wrote: > > I don't see an easy way to make the variable work, as there is no > > constraint on the order that cm3 and cm3cg are built. do-cm3-front.sh > > happens to do cm3cg first, but that is not necessarily required. > > [please pardon my editing...] > > > I see what you mean that cm3cg is an independent node in the graph and can be built in any order, > but, I guess, the story is/was, you have to know the safe order to ship things. > > > It is encoded in pkginfo.txt and the Python scripts honor it..though they don't always use pkginfo.txt for their ordering.. > And encoding the dependency graph there isn't ideal. It is really encoded in the import declarations > in the m3makefiles, usually, but not in this case... > > > The way that works is to build but don't ship cm3cg. > Then ship cm3cg. > Then copy cm3. > Then use the new cm3. > But perhaps it isn't strictly enforced enough. > > > > I used do this fairly often. > Though breaking changes in cm3cg were rare, granted. > But I'd also occasionally bootstrap from an older release. > I'll have to try to do that again soon -- actually make the current > tree easily buildable from the last release. > > > update.py handled it. > > > I'm on the fence. > "buildship" of multiple packages is in general problematic. > I kinda think the whole mechanism needs to be revampled. > > > Let me draw a close analogy. > > > In the slightly larger software world we have: > > make > make install > make install DESTDIR=somewhere_new > > > buildship is equivalent make && make install, or a make install that includes the make part, > as they sometimes do. > Read up on building glibc and they point out how dangerous this is -- how dangerous make install is w/o DESTDIR. > We have the same danger on a smaller scale. > You aren't going to break the "OS", but you can break "cm3". > > > The safe recommendation is make install DESTDIR. > Basically "install" "everything" "on the side", get it all installed, multiple > "packages", then copy or tar/untar it all. Or chroot into it and test it out, and > then do an in-place update. Or swap into the chroot and never return? (tail call install) > > > Don't do a "rolling upgrade". Don't install each package as it is built. No package, no cm3, > not cm3cg, nothing. > > > I'm basically suggesting that. > > > Now, if you say "don't ever ship, but somehow otherwise manually copy", well > that does kind of resolve to the same thing. > > > If you say, "almost don't ever ship, but provide a way to", that is almost the same. > > > make-dist.py follows the make install DESTDIR way. > > It is "better" I guess because I wrote it later, and because I was following > the example of the other .sh files that make distributions. So blame/credit Olaf? :) > > > It starts with a working compiler, copies parts into /temp, builds a new compiler into /tmp, and > uses what it builds to build everything. > > > Again I suggest it be looked into, and maybe be promoted as basically > the replacement for upgrade.py and upgrade.sh. > > > upgrade.py could wrap it and do the final steps of copy/untar in-place. > Or make-dist.py could just print the last optional command. > > > Anyway, I have no time lately, just email. :( > > > - Jay > > > > > Date: Fri, 29 May 2015 11:35:41 -0500 > > From: rodney_bates at lcwb.coop > > To: adacore at marino.st; wagner at elego.de > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > > > > Setting INSTALL_CM3_IN_BIN=yes is what forces the premature install of cm3cg. > > I see I had encountered this problem two years ago, but then it was happening > > regardless of the value of this variable. My fix only addresses the case when > > the variable is not set. I naively went to extra trouble to preserve the > > existing behavior when it is set--obviously not right. > > > > I don't see an easy way to make the variable work, as there is no > > constraint on the order that cm3 and cm3cg are built. do-cm3-front.sh > > happens to do cm3cg first, but that is not necessarily required. > > > > So INSTALL_CM3_IN_BIN is broken and hard to fix, if the two need > > compatible upgrades. For now, it looks like install-cm3-compiler.sh > > is the only working way. > > > > But maybe John and Olaf have found a different way around this. > > > > On 05/29/2015 10:55 AM, Rodney M. Bates wrote: > > > I don't know yet why, or what needs to change, but here is definitely the problem, starting > > > in line 4575 of your m3c log: > > > > > > > > > g++48 -O2 -pipe -fstack-protector -Wl,-rpath=/usr/local/lib/gcc48 -fno-strict-aliasing -Wl,-rpath=/usr/local/lib/gcc48 -DIN_GCC -Wno-missing-field-initializers -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -o m3cgc1 m3cg/parse.o attribs.o main.o tree-browser.o libbackend.a libcommon-target.a libcommon.a ../libcpp/libcpp.a libcommon.a ../libcpp/libcpp.a ../libiberty/libiberty.a > > > gmake[1]: Leaving directory `/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a/m3-sys/m3cc/AMD64_FREEBSD/gcc' > > > > > > > > > This is copying the newly-built cm3cg (the compiler back end) to your > > > bin directory: > > > > > > Forced ship of cm3cg. > > > --- shipping from AMD64_FREEBSD --- > > > > > > . => /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin > > > cm3cg > > > ==> m3-sys/m3cc done > > > > > > === package m3-libs/m3core === > > > > > > And this is using the cm3 (compiler front end) that was already in the bin > > > directory, and is the release version. > > > > > > +++ /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin/cm3 -build -DROOT='/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a' $RARGS && /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin/cm3 -ship $RARGS -DROOT='/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a' +++ > > > --- building in AMD64_FREEBSD --- > > > > > > ignoring ../src/m3overrides > > > > > > new source -> compiling RTHooks.i3 > > > > > > This is cm3cg (aka m3cgc1) detecting the incompatibility: > > > > > > m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > > > compilation terminated. > > > > > > Here is the counterpart section of my log: > > > > > > g++ -g -O2 -DIN_GCC -Wno-missing-field-initializers -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -o m3cgc1 m3cg/parse.o attribs.o main.o tree-browser.o libbackend.a libcommon-target.a libcommon.a ../libcpp/libcpp.a libcommon.a ../libcpp/libcpp.a ../libiberty/libiberty.a > > > > > > On my build, it's not shipping: > > > > > > Not shipping cm3cg. > > > --- shipping from AMD64_LINUX --- > > > > > > missing ".M3SHIP" file, build the package first. > > > ==> /home/rodney/proj/m3/git/cm3/m3-sys/m3cc done > > > > > > === package /home/rodney/proj/m3/git/cm3/m3-libs/m3core === > > > +++ cm3 -build -DROOT='/home/rodney/proj/m3/git/cm3' $RARGS && cm3 -ship $RARGS -DROOT='/home/rodney/proj/m3/git/cm3' +++ > > > --- building in AMD64_LINUX --- > > > > > > ignoring ../src/m3overrides > > > > > > new source -> compiling RTHooks.i3 > > > new source -> compiling RT0.i3 > > > > > > When it works, the copying of both cm3 and cm3cg to the bin directory is delayed until after both have been > > > built, in the 'install-cm3-compiler.sh upgrade' step. > > > > > > I see your build is using a full path to the bin directory and mine is letting > > > it come from the usual $PATH search, but that should make no difference, as long > > > as the bin directory is found in a consistent way, which seems to be the case > > > in both builds. > > > > > > > > > > > > On 05/29/2015 04:51 AM, John Marino wrote: > > >> On 5/29/2015 11:39, Olaf Wagner wrote: > > >>> On Fri, 29 May 2015 11:10:50 +0200 > > >>> John Marino wrote: > > >>> > > >>>> On 5/29/2015 10:54, Olaf Wagner wrote: > > >>>>> Please try what I suggested in the attached mail: define > > >>>>> INSTALL_CM3_IN_BIN=yes > > >>>>> in the environment and see if that helps. > > >>>>> > > >>>> > > >>>> Unfortunately it seems the result is exactly the same, even when > > >>>> INSTALL_CM3_IN_BIN is defined in the environment. > > >>> > > >>> Can I see the new logs? Has the new backend (cm3cg) been installed now? > > >>> > > >> > > >> It's here: > > >> http://leaf.dragonflybsd.org/~marino/m3c.log > > >> > > >> It never completes "do-cm3-front.sh buildship " > > >> > > >> Note that I'm using a bootstrap install and set INSTALL_ROOT to another > > >> location, but it never gets to the point of installing anything. > > >> > > >> John > > >> > > > > > > > -- > > Rodney Bates > > rodney.m.bates at acm.org -- Rodney Bates rodney.m.bates at acm.org From jay.krell at cornell.edu Sat May 30 00:31:50 2015 From: jay.krell at cornell.edu (Jay K) Date: Fri, 29 May 2015 22:31:50 +0000 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <5568D5D1.5040405@lcwb.coop> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop> <556817A1.2090206@marino.st> <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de> <55682D1A.2030504@marino.st> <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de> <55683689.2090709@marino.st>,,<55688BFF.5040701@lcwb.coop>, <5568955D.4060200@lcwb.coop>, , <5568D5D1.5040405@lcwb.coop> Message-ID: cm3/cm3cg are more special than the others, because cm3 is statically linked. There is no m3core.dll, that cm3 uses, or m3quake.dll, etc. There is m3core.dll, but cm3 doesn't uses it. Shipping it doesn't affect the in-use cm3. If/when we fix this, in fact, we can stop doing that static linking. It makes sense for m3quake, etc. as there are few/no other users. But for libm3/m3core, it'll provide a nice size optimization. The mutual incompatibilty between old/new cm3/cm3cg is perfectly ok. It is meant to be dealt with, not avoided. I believe upgrade.py did deal with this correctly, but this environment variable required to quash shipping of cm3cg broke it. The environment variable change really should imho be removed from cm3cg. Please. And then we can switch to "destdir" and remove all the in place updating, perhaps. Or I need to update upgrade.py to ship cm3cg itself. I guess I'll do that. upgrade.py may not have worked for you, but I have used it many many times.It worked. But currently it is probably broken by the m3cc/src/m3makefile change.I'll update it to accommodate that change.. And upgrade.sh I believe was in heavy use by Hudson. - Jay > Date: Fri, 29 May 2015 16:10:41 -0500 > From: rodney_bates at lcwb.coop > CC: m3devel at elegosoft.com > To: > Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > > Yes, we could have a better organization. I agree, the principal way > should be to build a complete set of everything that matters to the > implementation of the language, them replace them all at once. A > separate DESTDIR or such is needed. > > The set, as Jay points out, is larger than just cm3 and m3cc. It includes > at least m3core, probably libm3, and cm3, the executable depends on several > separately built packages--cm3, m3middle, m3front, m3quake, m3makefile, etc. > > In general, we can't really assume anything about the kinds of dependencies > of one package on old or new versions of another. Right now, cm3 and m3cc > are known mutually incompatible between 5.8 and the head, because the numbering > in M3CG_Binary.i3 has changed. We could probably establish some coding rules and > order-of-install rules that would allow a newer m3cc to work with an older cm3, > but that's only one pattern. > > I once thought do-cm3-*.sh build would do what we are talking about, but it > if I remember right, puts every package into immediate use as it is built > and also uses overrides, which keeps things inside the source tree, but makes > it unshippable. So I always use buildship. This has never, to my knowledge > run afoul of any compatibility problem other than between cm3 and m3cc, but it > does ship every package besides these two as it is built, so the potential > is there. > > I haven't had the energy to even try to understand just what the upgrade > scripts do, but they have not treated me well. If I had done different > patterns of incompatible changes, they would probably have been better > than the procedure I use. > > On 05/29/2015 01:06 PM, Jay K wrote: > > > I don't see an easy way to make the variable work, as there is no > > > constraint on the order that cm3 and cm3cg are built. do-cm3-front.sh > > > happens to do cm3cg first, but that is not necessarily required. > > > > [please pardon my editing...] > > > > > > I see what you mean that cm3cg is an independent node in the graph and can be built in any order, > > but, I guess, the story is/was, you have to know the safe order to ship things. > > > > > > It is encoded in pkginfo.txt and the Python scripts honor it..though they don't always use pkginfo.txt for their ordering.. > > And encoding the dependency graph there isn't ideal. It is really encoded in the import declarations > > in the m3makefiles, usually, but not in this case... > > > > > > The way that works is to build but don't ship cm3cg. > > Then ship cm3cg. > > Then copy cm3. > > Then use the new cm3. > > But perhaps it isn't strictly enforced enough. > > > > > > > > I used do this fairly often. > > Though breaking changes in cm3cg were rare, granted. > > But I'd also occasionally bootstrap from an older release. > > I'll have to try to do that again soon -- actually make the current > > tree easily buildable from the last release. > > > > > > update.py handled it. > > > > > > I'm on the fence. > > "buildship" of multiple packages is in general problematic. > > I kinda think the whole mechanism needs to be revampled. > > > > > > Let me draw a close analogy. > > > > > > In the slightly larger software world we have: > > > > make > > make install > > make install DESTDIR=somewhere_new > > > > > > buildship is equivalent make && make install, or a make install that includes the make part, > > as they sometimes do. > > Read up on building glibc and they point out how dangerous this is -- how dangerous make install is w/o DESTDIR. > > We have the same danger on a smaller scale. > > You aren't going to break the "OS", but you can break "cm3". > > > > > > The safe recommendation is make install DESTDIR. > > Basically "install" "everything" "on the side", get it all installed, multiple > > "packages", then copy or tar/untar it all. Or chroot into it and test it out, and > > then do an in-place update. Or swap into the chroot and never return? (tail call install) > > > > > > Don't do a "rolling upgrade". Don't install each package as it is built. No package, no cm3, > > not cm3cg, nothing. > > > > > > I'm basically suggesting that. > > > > > > Now, if you say "don't ever ship, but somehow otherwise manually copy", well > > that does kind of resolve to the same thing. > > > > > > If you say, "almost don't ever ship, but provide a way to", that is almost the same. > > > > > > make-dist.py follows the make install DESTDIR way. > > > > It is "better" I guess because I wrote it later, and because I was following > > the example of the other .sh files that make distributions. So blame/credit Olaf? :) > > > > > > It starts with a working compiler, copies parts into /temp, builds a new compiler into /tmp, and > > uses what it builds to build everything. > > > > > > Again I suggest it be looked into, and maybe be promoted as basically > > the replacement for upgrade.py and upgrade.sh. > > > > > > upgrade.py could wrap it and do the final steps of copy/untar in-place. > > Or make-dist.py could just print the last optional command. > > > > > > Anyway, I have no time lately, just email. :( > > > > > > - Jay > > > > > > > > > Date: Fri, 29 May 2015 11:35:41 -0500 > > > From: rodney_bates at lcwb.coop > > > To: adacore at marino.st; wagner at elego.de > > > CC: m3devel at elegosoft.com > > > Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > > > > > > Setting INSTALL_CM3_IN_BIN=yes is what forces the premature install of cm3cg. > > > I see I had encountered this problem two years ago, but then it was happening > > > regardless of the value of this variable. My fix only addresses the case when > > > the variable is not set. I naively went to extra trouble to preserve the > > > existing behavior when it is set--obviously not right. > > > > > > I don't see an easy way to make the variable work, as there is no > > > constraint on the order that cm3 and cm3cg are built. do-cm3-front.sh > > > happens to do cm3cg first, but that is not necessarily required. > > > > > > So INSTALL_CM3_IN_BIN is broken and hard to fix, if the two need > > > compatible upgrades. For now, it looks like install-cm3-compiler.sh > > > is the only working way. > > > > > > But maybe John and Olaf have found a different way around this. > > > > > > On 05/29/2015 10:55 AM, Rodney M. Bates wrote: > > > > I don't know yet why, or what needs to change, but here is definitely the problem, starting > > > > in line 4575 of your m3c log: > > > > > > > > > > > > g++48 -O2 -pipe -fstack-protector -Wl,-rpath=/usr/local/lib/gcc48 -fno-strict-aliasing -Wl,-rpath=/usr/local/lib/gcc48 -DIN_GCC -Wno-missing-field-initializers -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -o m3cgc1 m3cg/parse.o attribs.o main.o tree-browser.o libbackend.a libcommon-target.a libcommon.a ../libcpp/libcpp.a libcommon.a ../libcpp/libcpp.a ../libiberty/libiberty.a > > > > gmake[1]: Leaving directory `/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a/m3-sys/m3cc/AMD64_FREEBSD/gcc' > > > > > > > > > > > > This is copying the newly-built cm3cg (the compiler back end) to your > > > > bin directory: > > > > > > > > Forced ship of cm3cg. > > > > --- shipping from AMD64_FREEBSD --- > > > > > > > > . => /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin > > > > cm3cg > > > > ==> m3-sys/m3cc done > > > > > > > > === package m3-libs/m3core === > > > > > > > > And this is using the cm3 (compiler front end) that was already in the bin > > > > directory, and is the release version. > > > > > > > > +++ /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin/cm3 -build -DROOT='/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a' $RARGS && /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin/cm3 -ship $RARGS -DROOT='/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a' +++ > > > > --- building in AMD64_FREEBSD --- > > > > > > > > ignoring ../src/m3overrides > > > > > > > > new source -> compiling RTHooks.i3 > > > > > > > > This is cm3cg (aka m3cgc1) detecting the incompatibility: > > > > > > > > m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > > > > compilation terminated. > > > > > > > > Here is the counterpart section of my log: > > > > > > > > g++ -g -O2 -DIN_GCC -Wno-missing-field-initializers -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -o m3cgc1 m3cg/parse.o attribs.o main.o tree-browser.o libbackend.a libcommon-target.a libcommon.a ../libcpp/libcpp.a libcommon.a ../libcpp/libcpp.a ../libiberty/libiberty.a > > > > > > > > On my build, it's not shipping: > > > > > > > > Not shipping cm3cg. > > > > --- shipping from AMD64_LINUX --- > > > > > > > > missing ".M3SHIP" file, build the package first. > > > > ==> /home/rodney/proj/m3/git/cm3/m3-sys/m3cc done > > > > > > > > === package /home/rodney/proj/m3/git/cm3/m3-libs/m3core === > > > > +++ cm3 -build -DROOT='/home/rodney/proj/m3/git/cm3' $RARGS && cm3 -ship $RARGS -DROOT='/home/rodney/proj/m3/git/cm3' +++ > > > > --- building in AMD64_LINUX --- > > > > > > > > ignoring ../src/m3overrides > > > > > > > > new source -> compiling RTHooks.i3 > > > > new source -> compiling RT0.i3 > > > > > > > > When it works, the copying of both cm3 and cm3cg to the bin directory is delayed until after both have been > > > > built, in the 'install-cm3-compiler.sh upgrade' step. > > > > > > > > I see your build is using a full path to the bin directory and mine is letting > > > > it come from the usual $PATH search, but that should make no difference, as long > > > > as the bin directory is found in a consistent way, which seems to be the case > > > > in both builds. > > > > > > > > > > > > > > > > On 05/29/2015 04:51 AM, John Marino wrote: > > > >> On 5/29/2015 11:39, Olaf Wagner wrote: > > > >>> On Fri, 29 May 2015 11:10:50 +0200 > > > >>> John Marino wrote: > > > >>> > > > >>>> On 5/29/2015 10:54, Olaf Wagner wrote: > > > >>>>> Please try what I suggested in the attached mail: define > > > >>>>> INSTALL_CM3_IN_BIN=yes > > > >>>>> in the environment and see if that helps. > > > >>>>> > > > >>>> > > > >>>> Unfortunately it seems the result is exactly the same, even when > > > >>>> INSTALL_CM3_IN_BIN is defined in the environment. > > > >>> > > > >>> Can I see the new logs? Has the new backend (cm3cg) been installed now? > > > >>> > > > >> > > > >> It's here: > > > >> http://leaf.dragonflybsd.org/~marino/m3c.log > > > >> > > > >> It never completes "do-cm3-front.sh buildship " > > > >> > > > >> Note that I'm using a bootstrap install and set INSTALL_ROOT to another > > > >> location, but it never gets to the point of installing anything. > > > >> > > > >> John > > > >> > > > > > > > > > > -- > > > Rodney Bates > > > rodney.m.bates at acm.org > > -- > Rodney Bates > rodney.m.bates at acm.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Sat May 30 16:55:37 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sat, 30 May 2015 09:55:37 -0500 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop> <556817A1.2090206@marino.st> <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de> <55682D1A.2030504@marino.st> <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de> <55683689.2090709@marino.st>, , <55688BFF.5040701@lcwb.coop>, <5568955D.4060200@lcwb.coop>, , <5568D5D1.5040405@lcwb.coop> Message-ID: <5569CF69.6020504@lcwb.coop> On 05/29/2015 05:31 PM, Jay K wrote: > cm3/cm3cg are more special than the others, because cm3 is statically linked. > There is no m3core.dll, that cm3 uses, or m3quake.dll, etc. > There is m3core.dll, but cm3 doesn't uses it. > Shipping it doesn't affect the in-use cm3. > > > If/when we fix this, in fact, we can stop doing that static linking. > It makes sense for m3quake, etc. as there are few/no other users. > But for libm3/m3core, it'll provide a nice size optimization. > > > The mutual incompatibilty between old/new cm3/cm3cg is perfectly ok. > It is meant to be dealt with, not avoided. > > > I believe upgrade.py did deal with this correctly, but this environment > variable required to quash shipping of cm3cg broke it. > > > The environment variable change really should imho be removed from cm3cg. > Please. > Jay, I am not sure what you are proposing. When I first looked at the commit for this change, I was quite confused by my own change. While the comments say it is to _not_ prematurely ship cm3cg, the code appears to add code to conditionally ship if INSTALL_CM3_IN_BIN=yes. After the n-th look, I realized that before the change, it _always_ shipped, regardless of the variable. So it really does provide for less premature shipping. If I just revert it, do-cm3-front.sh will be unconditionally and unusably broken. As is, it is at least usable if you don't set the variable. Even if there is some use case where one would want it to ship, (none occurs to me), as is, you can get this behavior by just setting the variable. Moreover, the current behavior for cm3cg is consistent with the current and long-standing behavior for cm3, i.e., ship iff the variable is set. It would make more sense to me to remove the variable check by unconditionally _not_ shipping. At least do-cm3-front.sh would be usable. But then, what would be the purpose of the inconsistent use of the variable for cm3? > > And then we can switch to "destdir" and remove all the in place updating, perhaps. > > > Or I need to update upgrade.py to ship cm3cg itself. > I guess I'll do that. > > > upgrade.py may not have worked for you, but I have used it many many times. > It worked. But currently it is probably broken by the m3cc/src/m3makefile change. > I'll update it to accommodate that change.. > > > And upgrade.sh I believe was in heavy use by Hudson. > > > - Jay > > > > > Date: Fri, 29 May 2015 16:10:41 -0500 > > From: rodney_bates at lcwb.coop > > CC: m3devel at elegosoft.com > > To: > > Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > > > > Yes, we could have a better organization. I agree, the principal way > > should be to build a complete set of everything that matters to the > > implementation of the language, them replace them all at once. A > > separate DESTDIR or such is needed. > > > > The set, as Jay points out, is larger than just cm3 and m3cc. It includes > > at least m3core, probably libm3, and cm3, the executable depends on several > > separately built packages--cm3, m3middle, m3front, m3quake, m3makefile, etc. > > > > In general, we can't really assume anything about the kinds of dependencies > > of one package on old or new versions of another. Right now, cm3 and m3cc > > are known mutually incompatible between 5.8 and the head, because the numbering > > in M3CG_Binary.i3 has changed. We could probably establish some coding rules and > > order-of-install rules that would allow a newer m3cc to work with an older cm3, > > but that's only one pattern. > > > > I once thought do-cm3-*.sh build would do what we are talking about, but it > > if I remember right, puts every package into immediate use as it is built > > and also uses overrides, which keeps things inside the source tree, but makes > > it unshippable. So I always use buildship. This has never, to my knowledge > > run afoul of any compatibility problem other than between cm3 and m3cc, but it > > does ship every package besides these two as it is built, so the potential > > is there. > > > > I haven't had the energy to even try to understand just what the upgrade > > scripts do, but they have not treated me well. If I had done different > > patterns of incompatible changes, they would probably have been better > > than the procedure I use. > > > > On 05/29/2015 01:06 PM, Jay K wrote: > > > > I don't see an easy way to make the variable work, as there is no > > > > constraint on the order that cm3 and cm3cg are built. do-cm3-front.sh > > > > happens to do cm3cg first, but that is not necessarily required. > > > > > > [please pardon my editing...] > > > > > > > > > I see what you mean that cm3cg is an independent node in the graph and can be built in any order, > > > but, I guess, the story is/was, you have to know the safe order to ship things. > > > > > > > > > It is encoded in pkginfo.txt and the Python scripts honor it..though they don't always use pkginfo.txt for their ordering.. > > > And encoding the dependency graph there isn't ideal. It is really encoded in the import declarations > > > in the m3makefiles, usually, but not in this case... > > > > > > > > > The way that works is to build but don't ship cm3cg. > > > Then ship cm3cg. > > > Then copy cm3. > > > Then use the new cm3. > > > But perhaps it isn't strictly enforced enough. > > > > > > > > > > > > I used do this fairly often. > > > Though breaking changes in cm3cg were rare, granted. > > > But I'd also occasionally bootstrap from an older release. > > > I'll have to try to do that again soon -- actually make the current > > > tree easily buildable from the last release. > > > > > > > > > update.py handled it. > > > > > > > > > I'm on the fence. > > > "buildship" of multiple packages is in general problematic. > > > I kinda think the whole mechanism needs to be revampled. > > > > > > > > > Let me draw a close analogy. > > > > > > > > > In the slightly larger software world we have: > > > > > > make > > > make install > > > make install DESTDIR=somewhere_new > > > > > > > > > buildship is equivalent make && make install, or a make install that includes the make part, > > > as they sometimes do. > > > Read up on building glibc and they point out how dangerous this is -- how dangerous make install is w/o DESTDIR. > > > We have the same danger on a smaller scale. > > > You aren't going to break the "OS", but you can break "cm3". > > > > > > > > > The safe recommendation is make install DESTDIR. > > > Basically "install" "everything" "on the side", get it all installed, multiple > > > "packages", then copy or tar/untar it all. Or chroot into it and test it out, and > > > then do an in-place update. Or swap into the chroot and never return? (tail call install) > > > > > > > > > Don't do a "rolling upgrade". Don't install each package as it is built. No package, no cm3, > > > not cm3cg, nothing. > > > > > > > > > I'm basically suggesting that. > > > > > > > > > Now, if you say "don't ever ship, but somehow otherwise manually copy", well > > > that does kind of resolve to the same thing. > > > > > > > > > If you say, "almost don't ever ship, but provide a way to", that is almost the same. > > > > > > > > > make-dist.py follows the make install DESTDIR way. > > > > > > It is "better" I guess because I wrote it later, and because I was following > > > the example of the other .sh files that make distributions. So blame/credit Olaf? :) > > > > > > > > > It starts with a working compiler, copies parts into /temp, builds a new compiler into /tmp, and > > > uses what it builds to build everything. > > > > > > > > > Again I suggest it be looked into, and maybe be promoted as basically > > > the replacement for upgrade.py and upgrade.sh. > > > > > > > > > upgrade.py could wrap it and do the final steps of copy/untar in-place. > > > Or make-dist.py could just print the last optional command. > > > > > > > > > Anyway, I have no time lately, just email. :( > > > > > > > > > - Jay > > > > > > > > > > > > > Date: Fri, 29 May 2015 11:35:41 -0500 > > > > From: rodney_bates at lcwb.coop > > > > To: adacore at marino.st; wagner at elego.de > > > > CC: m3devel at elegosoft.com > > > > Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > > > > > > > > Setting INSTALL_CM3_IN_BIN=yes is what forces the premature install of cm3cg. > > > > I see I had encountered this problem two years ago, but then it was happening > > > > regardless of the value of this variable. My fix only addresses the case when > > > > the variable is not set. I naively went to extra trouble to preserve the > > > > existing behavior when it is set--obviously not right. > > > > > > > > I don't see an easy way to make the variable work, as there is no > > > > constraint on the order that cm3 and cm3cg are built. do-cm3-front.sh > > > > happens to do cm3cg first, but that is not necessarily required. > > > > > > > > So INSTALL_CM3_IN_BIN is broken and hard to fix, if the two need > > > > compatible upgrades. For now, it looks like install-cm3-compiler.sh > > > > is the only working way. > > > > > > > > But maybe John and Olaf have found a different way around this. > > > > > > > > On 05/29/2015 10:55 AM, Rodney M. Bates wrote: > > > > > I don't know yet why, or what needs to change, but here is definitely the problem, starting > > > > > in line 4575 of your m3c log: > > > > > > > > > > > > > > > g++48 -O2 -pipe -fstack-protector -Wl,-rpath=/usr/local/lib/gcc48 -fno-strict-aliasing -Wl,-rpath=/usr/local/lib/gcc48 -DIN_GCC -Wno-missing-field-initializers -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -o m3cgc1 m3cg/parse.o attribs.o main.o tree-browser.o libbackend.a libcommon-target.a libcommon.a ../libcpp/libcpp.a libcommon.a ../libcpp/libcpp.a ../libiberty/libiberty.a > > > > > gmake[1]: Leaving directory `/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a/m3-sys/m3cc/AMD64_FREEBSD/gcc' > > > > > > > > > > > > > > > This is copying the newly-built cm3cg (the compiler back end) to your > > > > > bin directory: > > > > > > > > > > Forced ship of cm3cg. > > > > > --- shipping from AMD64_FREEBSD --- > > > > > > > > > > . => /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin > > > > > cm3cg > > > > > ==> m3-sys/m3cc done > > > > > > > > > > === package m3-libs/m3core === > > > > > > > > > > And this is using the cm3 (compiler front end) that was already in the bin > > > > > directory, and is the release version. > > > > > > > > > > +++ /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin/cm3 -build -DROOT='/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a' $RARGS && /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin/cm3 -ship $RARGS -DROOT='/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a' +++ > > > > > --- building in AMD64_FREEBSD --- > > > > > > > > > > ignoring ../src/m3overrides > > > > > > > > > > new source -> compiling RTHooks.i3 > > > > > > > > > > This is cm3cg (aka m3cgc1) detecting the incompatibility: > > > > > > > > > > m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > > > > > compilation terminated. > > > > > > > > > > Here is the counterpart section of my log: > > > > > > > > > > g++ -g -O2 -DIN_GCC -Wno-missing-field-initializers -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -o m3cgc1 m3cg/parse.o attribs.o main.o tree-browser.o libbackend.a libcommon-target.a libcommon.a ../libcpp/libcpp.a libcommon.a ../libcpp/libcpp.a ../libiberty/libiberty.a > > > > > > > > > > On my build, it's not shipping: > > > > > > > > > > Not shipping cm3cg. > > > > > --- shipping from AMD64_LINUX --- > > > > > > > > > > missing ".M3SHIP" file, build the package first. > > > > > ==> /home/rodney/proj/m3/git/cm3/m3-sys/m3cc done > > > > > > > > > > === package /home/rodney/proj/m3/git/cm3/m3-libs/m3core === > > > > > +++ cm3 -build -DROOT='/home/rodney/proj/m3/git/cm3' $RARGS && cm3 -ship $RARGS -DROOT='/home/rodney/proj/m3/git/cm3' +++ > > > > > --- building in AMD64_LINUX --- > > > > > > > > > > ignoring ../src/m3overrides > > > > > > > > > > new source -> compiling RTHooks.i3 > > > > > new source -> compiling RT0.i3 > > > > > > > > > > When it works, the copying of both cm3 and cm3cg to the bin directory is delayed until after both have been > > > > > built, in the 'install-cm3-compiler.sh upgrade' step. > > > > > > > > > > I see your build is using a full path to the bin directory and mine is letting > > > > > it come from the usual $PATH search, but that should make no difference, as long > > > > > as the bin directory is found in a consistent way, which seems to be the case > > > > > in both builds. > > > > > > > > > > > > > > > > > > > > On 05/29/2015 04:51 AM, John Marino wrote: > > > > >> On 5/29/2015 11:39, Olaf Wagner wrote: > > > > >>> On Fri, 29 May 2015 11:10:50 +0200 > > > > >>> John Marino wrote: > > > > >>> > > > > >>>> On 5/29/2015 10:54, Olaf Wagner wrote: > > > > >>>>> Please try what I suggested in the attached mail: define > > > > >>>>> INSTALL_CM3_IN_BIN=yes > > > > >>>>> in the environment and see if that helps. > > > > >>>>> > > > > >>>> > > > > >>>> Unfortunately it seems the result is exactly the same, even when > > > > >>>> INSTALL_CM3_IN_BIN is defined in the environment. > > > > >>> > > > > >>> Can I see the new logs? Has the new backend (cm3cg) been installed now? > > > > >>> > > > > >> > > > > >> It's here: > > > > >> http://leaf.dragonflybsd.org/~marino/m3c.log > > > > >> > > > > >> It never completes "do-cm3-front.sh buildship " > > > > >> > > > > >> Note that I'm using a bootstrap install and set INSTALL_ROOT to another > > > > >> location, but it never gets to the point of installing anything. > > > > >> > > > > >> John > > > > >> > > > > > > > > > > > > > -- > > > > Rodney Bates > > > > rodney.m.bates at acm.org > > > > -- > > Rodney Bates > > rodney.m.bates at acm.org -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Sat May 30 16:58:31 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sat, 30 May 2015 09:58:31 -0500 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop> <556817A1.2090206@marino.st> <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de> <55682D1A.2030504@marino.st> <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de> <55683689.2090709@marino.st>, , <55688BFF.5040701@lcwb.coop>, <5568955D.4060200@lcwb.coop>, , <5568D5D1.5040405@lcwb.coop> Message-ID: <5569D017.5000201@lcwb.coop> On 05/29/2015 05:31 PM, Jay K wrote: > cm3/cm3cg are more special than the others, because cm3 is statically linked. > There is no m3core.dll, that cm3 uses, or m3quake.dll, etc. > There is m3core.dll, but cm3 doesn't uses it. > Shipping it doesn't affect the in-use cm3. > > > If/when we fix this, in fact, we can stop doing that static linking. > It makes sense for m3quake, etc. as there are few/no other users. > But for libm3/m3core, it'll provide a nice size optimization. > > > The mutual incompatibilty between old/new cm3/cm3cg is perfectly ok. > It is meant to be dealt with, not avoided. > I agree it's OK. Disallowing it would overly hamstring future development. But dealing with it means we need to be able to prevent either package immediately after it is built. > > I believe upgrade.py did deal with this correctly, but this environment > variable required to quash shipping of cm3cg broke it. > > > The environment variable change really should imho be removed from cm3cg. > Please. > Jay, I am not sure what you are proposing. When I first looked at the commit for this change, I was quite confused by my own change. While the comments say it is to _not_ prematurely ship cm3cg, the code appears to add code to conditionally ship if INSTALL_CM3_IN_BIN=yes. After the n-th look, I realized that before the change, it _always_ shipped, regardless of the variable. So it really does provide for less premature shipping. If I just revert it, do-cm3-front.sh will be unconditionally and unusably broken. As is, it is at least usable if you don't set the variable. Even if there is some use case where one would want it to ship, (none occurs to me), as is, you can get this behavior by just setting the variable. Moreover, the current behavior for cm3cg is consistent with the current and long-standing behavior for cm3, i.e., ship iff the variable is set. It would make more sense to me to remove the variable check by unconditionally _not_ shipping. At least do-cm3-front.sh would be usable. But then, what would be the purpose of the inconsistent use of the variable for cm3? > > And then we can switch to "destdir" and remove all the in place updating, perhaps. > > > Or I need to update upgrade.py to ship cm3cg itself. > I guess I'll do that. > > > upgrade.py may not have worked for you, but I have used it many many times. > It worked. But currently it is probably broken by the m3cc/src/m3makefile change. > I'll update it to accommodate that change.. > > > And upgrade.sh I believe was in heavy use by Hudson. > > > - Jay > > > > > Date: Fri, 29 May 2015 16:10:41 -0500 > > From: rodney_bates at lcwb.coop > > CC: m3devel at elegosoft.com > > To: > > Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > > > > Yes, we could have a better organization. I agree, the principal way > > should be to build a complete set of everything that matters to the > > implementation of the language, them replace them all at once. A > > separate DESTDIR or such is needed. > > > > The set, as Jay points out, is larger than just cm3 and m3cc. It includes > > at least m3core, probably libm3, and cm3, the executable depends on several > > separately built packages--cm3, m3middle, m3front, m3quake, m3makefile, etc. > > > > In general, we can't really assume anything about the kinds of dependencies > > of one package on old or new versions of another. Right now, cm3 and m3cc > > are known mutually incompatible between 5.8 and the head, because the numbering > > in M3CG_Binary.i3 has changed. We could probably establish some coding rules and > > order-of-install rules that would allow a newer m3cc to work with an older cm3, > > but that's only one pattern. > > > > I once thought do-cm3-*.sh build would do what we are talking about, but it > > if I remember right, puts every package into immediate use as it is built > > and also uses overrides, which keeps things inside the source tree, but makes > > it unshippable. So I always use buildship. This has never, to my knowledge > > run afoul of any compatibility problem other than between cm3 and m3cc, but it > > does ship every package besides these two as it is built, so the potential > > is there. > > > > I haven't had the energy to even try to understand just what the upgrade > > scripts do, but they have not treated me well. If I had done different > > patterns of incompatible changes, they would probably have been better > > than the procedure I use. > > > > On 05/29/2015 01:06 PM, Jay K wrote: > > > > I don't see an easy way to make the variable work, as there is no > > > > constraint on the order that cm3 and cm3cg are built. do-cm3-front.sh > > > > happens to do cm3cg first, but that is not necessarily required. > > > > > > [please pardon my editing...] > > > > > > > > > I see what you mean that cm3cg is an independent node in the graph and can be built in any order, > > > but, I guess, the story is/was, you have to know the safe order to ship things. > > > > > > > > > It is encoded in pkginfo.txt and the Python scripts honor it..though they don't always use pkginfo.txt for their ordering.. > > > And encoding the dependency graph there isn't ideal. It is really encoded in the import declarations > > > in the m3makefiles, usually, but not in this case... > > > > > > > > > The way that works is to build but don't ship cm3cg. > > > Then ship cm3cg. > > > Then copy cm3. > > > Then use the new cm3. > > > But perhaps it isn't strictly enforced enough. > > > > > > > > > > > > I used do this fairly often. > > > Though breaking changes in cm3cg were rare, granted. > > > But I'd also occasionally bootstrap from an older release. > > > I'll have to try to do that again soon -- actually make the current > > > tree easily buildable from the last release. > > > > > > > > > update.py handled it. > > > > > > > > > I'm on the fence. > > > "buildship" of multiple packages is in general problematic. > > > I kinda think the whole mechanism needs to be revampled. > > > > > > > > > Let me draw a close analogy. > > > > > > > > > In the slightly larger software world we have: > > > > > > make > > > make install > > > make install DESTDIR=somewhere_new > > > > > > > > > buildship is equivalent make && make install, or a make install that includes the make part, > > > as they sometimes do. > > > Read up on building glibc and they point out how dangerous this is -- how dangerous make install is w/o DESTDIR. > > > We have the same danger on a smaller scale. > > > You aren't going to break the "OS", but you can break "cm3". > > > > > > > > > The safe recommendation is make install DESTDIR. > > > Basically "install" "everything" "on the side", get it all installed, multiple > > > "packages", then copy or tar/untar it all. Or chroot into it and test it out, and > > > then do an in-place update. Or swap into the chroot and never return? (tail call install) > > > > > > > > > Don't do a "rolling upgrade". Don't install each package as it is built. No package, no cm3, > > > not cm3cg, nothing. > > > > > > > > > I'm basically suggesting that. > > > > > > > > > Now, if you say "don't ever ship, but somehow otherwise manually copy", well > > > that does kind of resolve to the same thing. > > > > > > > > > If you say, "almost don't ever ship, but provide a way to", that is almost the same. > > > > > > > > > make-dist.py follows the make install DESTDIR way. > > > > > > It is "better" I guess because I wrote it later, and because I was following > > > the example of the other .sh files that make distributions. So blame/credit Olaf? :) > > > > > > > > > It starts with a working compiler, copies parts into /temp, builds a new compiler into /tmp, and > > > uses what it builds to build everything. > > > > > > > > > Again I suggest it be looked into, and maybe be promoted as basically > > > the replacement for upgrade.py and upgrade.sh. > > > > > > > > > upgrade.py could wrap it and do the final steps of copy/untar in-place. > > > Or make-dist.py could just print the last optional command. > > > > > > > > > Anyway, I have no time lately, just email. :( > > > > > > > > > - Jay > > > > > > > > > > > > > Date: Fri, 29 May 2015 11:35:41 -0500 > > > > From: rodney_bates at lcwb.coop > > > > To: adacore at marino.st; wagner at elego.de > > > > CC: m3devel at elegosoft.com > > > > Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > > > > > > > > Setting INSTALL_CM3_IN_BIN=yes is what forces the premature install of cm3cg. > > > > I see I had encountered this problem two years ago, but then it was happening > > > > regardless of the value of this variable. My fix only addresses the case when > > > > the variable is not set. I naively went to extra trouble to preserve the > > > > existing behavior when it is set--obviously not right. > > > > > > > > I don't see an easy way to make the variable work, as there is no > > > > constraint on the order that cm3 and cm3cg are built. do-cm3-front.sh > > > > happens to do cm3cg first, but that is not necessarily required. > > > > > > > > So INSTALL_CM3_IN_BIN is broken and hard to fix, if the two need > > > > compatible upgrades. For now, it looks like install-cm3-compiler.sh > > > > is the only working way. > > > > > > > > But maybe John and Olaf have found a different way around this. > > > > > > > > On 05/29/2015 10:55 AM, Rodney M. Bates wrote: > > > > > I don't know yet why, or what needs to change, but here is definitely the problem, starting > > > > > in line 4575 of your m3c log: > > > > > > > > > > > > > > > g++48 -O2 -pipe -fstack-protector -Wl,-rpath=/usr/local/lib/gcc48 -fno-strict-aliasing -Wl,-rpath=/usr/local/lib/gcc48 -DIN_GCC -Wno-missing-field-initializers -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -o m3cgc1 m3cg/parse.o attribs.o main.o tree-browser.o libbackend.a libcommon-target.a libcommon.a ../libcpp/libcpp.a libcommon.a ../libcpp/libcpp.a ../libiberty/libiberty.a > > > > > gmake[1]: Leaving directory `/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a/m3-sys/m3cc/AMD64_FREEBSD/gcc' > > > > > > > > > > > > > > > This is copying the newly-built cm3cg (the compiler back end) to your > > > > > bin directory: > > > > > > > > > > Forced ship of cm3cg. > > > > > --- shipping from AMD64_FREEBSD --- > > > > > > > > > > . => /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin > > > > > cm3cg > > > > > ==> m3-sys/m3cc done > > > > > > > > > > === package m3-libs/m3core === > > > > > > > > > > And this is using the cm3 (compiler front end) that was already in the bin > > > > > directory, and is the release version. > > > > > > > > > > +++ /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin/cm3 -build -DROOT='/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a' $RARGS && /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin/cm3 -ship $RARGS -DROOT='/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a' +++ > > > > > --- building in AMD64_FREEBSD --- > > > > > > > > > > ignoring ../src/m3overrides > > > > > > > > > > new source -> compiling RTHooks.i3 > > > > > > > > > > This is cm3cg (aka m3cgc1) detecting the incompatibility: > > > > > > > > > > m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > > > > > compilation terminated. > > > > > > > > > > Here is the counterpart section of my log: > > > > > > > > > > g++ -g -O2 -DIN_GCC -Wno-missing-field-initializers -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -o m3cgc1 m3cg/parse.o attribs.o main.o tree-browser.o libbackend.a libcommon-target.a libcommon.a ../libcpp/libcpp.a libcommon.a ../libcpp/libcpp.a ../libiberty/libiberty.a > > > > > > > > > > On my build, it's not shipping: > > > > > > > > > > Not shipping cm3cg. > > > > > --- shipping from AMD64_LINUX --- > > > > > > > > > > missing ".M3SHIP" file, build the package first. > > > > > ==> /home/rodney/proj/m3/git/cm3/m3-sys/m3cc done > > > > > > > > > > === package /home/rodney/proj/m3/git/cm3/m3-libs/m3core === > > > > > +++ cm3 -build -DROOT='/home/rodney/proj/m3/git/cm3' $RARGS && cm3 -ship $RARGS -DROOT='/home/rodney/proj/m3/git/cm3' +++ > > > > > --- building in AMD64_LINUX --- > > > > > > > > > > ignoring ../src/m3overrides > > > > > > > > > > new source -> compiling RTHooks.i3 > > > > > new source -> compiling RT0.i3 > > > > > > > > > > When it works, the copying of both cm3 and cm3cg to the bin directory is delayed until after both have been > > > > > built, in the 'install-cm3-compiler.sh upgrade' step. > > > > > > > > > > I see your build is using a full path to the bin directory and mine is letting > > > > > it come from the usual $PATH search, but that should make no difference, as long > > > > > as the bin directory is found in a consistent way, which seems to be the case > > > > > in both builds. > > > > > > > > > > > > > > > > > > > > On 05/29/2015 04:51 AM, John Marino wrote: > > > > >> On 5/29/2015 11:39, Olaf Wagner wrote: > > > > >>> On Fri, 29 May 2015 11:10:50 +0200 > > > > >>> John Marino wrote: > > > > >>> > > > > >>>> On 5/29/2015 10:54, Olaf Wagner wrote: > > > > >>>>> Please try what I suggested in the attached mail: define > > > > >>>>> INSTALL_CM3_IN_BIN=yes > > > > >>>>> in the environment and see if that helps. > > > > >>>>> > > > > >>>> > > > > >>>> Unfortunately it seems the result is exactly the same, even when > > > > >>>> INSTALL_CM3_IN_BIN is defined in the environment. > > > > >>> > > > > >>> Can I see the new logs? Has the new backend (cm3cg) been installed now? > > > > >>> > > > > >> > > > > >> It's here: > > > > >> http://leaf.dragonflybsd.org/~marino/m3c.log > > > > >> > > > > >> It never completes "do-cm3-front.sh buildship " > > > > >> > > > > >> Note that I'm using a bootstrap install and set INSTALL_ROOT to another > > > > >> location, but it never gets to the point of installing anything. > > > > >> > > > > >> John > > > > >> > > > > > > > > > > > > > -- > > > > Rodney Bates > > > > rodney.m.bates at acm.org > > > > -- > > Rodney Bates > > rodney.m.bates at acm.org -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Sat May 30 17:13:46 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sat, 30 May 2015 10:13:46 -0500 Subject: [M3devel] The role INTEGER and subranges in Modula-3 Message-ID: <5569D3AA.2040009@lcwb.coop> I am suspecting there is some misunderstanding about Modula-3's approach to integer sizes. The original idea is to use subrange types, (which are programmer-defined,) not different builtin types, to match the value range you need. The safety rules of the language ensure that values stored in variables are in the type's range. But all arithmetic is done in the full native word size of the machine. Types are more abstract than most languages, in that different machine representations (particularly, bit count) need not be different base types in the language. There are no implicit type conversions. Instead, this need is met by the concept of assignability. If the abstract value is in a variable's range, it can be assigned to the variable. Size changes, if needed, are the code generator's problem. All this drastically simplifies the language, while also allowing the programmer to define an exact match between type-imposed value ranges and what the application needs, rather than just a few powers of two. Having implied type conversions, which also interact with sizes of intermediate arithmetic results, requires many pages of language definition that we avoid. LONGINT, which I have advocated, flies in the face of this tidy scheme. If we could do all arithmetic efficiently in the biggest size likely to be commonly needed, LONGINT would have no place. But native sized arithmetic is always the most efficient. In today's world, there are two very common classes of use cases: 1) 32-bit arithmetic is wide enough, 2) 32-bit is not wide enough, but 64-bit is. In both cases, on machines of either native arithmetic size, we want the best efficiency. LONGINT is for case 2, and when you further need to be able to run on either size of machine. INTEGER is for otherwise. Whether you believe in LONGINT or not, there is certainly no justification for more base integer types than two: one the native size of the machine and one bigger. Note that, as defined in Modula-3 today, INTEGER and LONGINT are always distinct types (distinct, regardless of either their value ranges or of the machine's native word size), with no subtype relation between them, no assignability between them, no implied conversions between them, no mixed arithmetic operators, no questions about intermediate result range, and literals of unambiguous type. Thus we stay out of the semantic tar pit most languages fall into with multiple integer sizes, while giving the programmer drastically more choices on range limits. Note that original Modula-3, in contrast to the single integer type, has three floating point types, no doubt motivated by the messy realities of taking full advantage of hardware-provided arithmetics. These three have the same type isolation properties as INTEGER and LONGINT, with the same consequences. In fact, the integer type isolation is directly modeled after the floating type isolation. -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Sat May 30 17:27:22 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sat, 30 May 2015 10:27:22 -0500 Subject: [M3devel] Integrating llvm Message-ID: <5569D6DA.9050404@lcwb.coop> In order to simplify integrating the emerging llvm backend, I propose to split the current llvm package into three: A library package containing just binding-related stuff to the llvm infrastructure. (llvmbindings) A library package containing M3CG_LLVM.[im]3 and anything that might get added for the actual cm3-IR to llvm-IR conversion. (llvmback) A program package with a main program for llvm (currently llvm/src/Main.m3) (llvmstaloneback) This would provide more flexibility in doing the integration into the compiler, and maybe some other things some day. Any objections or comments? Peter? -- Rodney Bates rodney.m.bates at acm.org From jay.krell at cornell.edu Sat May 30 18:24:17 2015 From: jay.krell at cornell.edu (Jay K) Date: Sat, 30 May 2015 16:24:17 +0000 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <5569D017.5000201@lcwb.coop> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop> <556817A1.2090206@marino.st> <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de> <55682D1A.2030504@marino.st> <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de> <55683689.2090709@marino.st>,,, <55688BFF.5040701@lcwb.coop>, <5568955D.4060200@lcwb.coop>, , , , <5568D5D1.5040405@lcwb.coop>, , <5569D017.5000201@lcwb.coop> Message-ID: The variable is not for atomic update of multiple files. The variable exists because updating in-use files reportedly fails on some operating systems. Though I question the truth of even that. If we change ship to rename away upon copy failure, and find a reliable simple way to ensure eventual deletion of the renamed file, then we don't need this. I'll have to experiment on NT. Presumably we've written off Win9x, and I'm not sure about AIX. So consistency with cm3 isn't necessarily desirable/required. do-cm3-front.sh isn't necessarily meant to work when there is an IR change. perhaps m3cc wasn't supposed to be in front. I'll have to double check that later. upgrade.sh is meant to. It doesn't ship anything and manually copies both cm3 and cm3cg. So that still works. And upgrade.py handles it, but other way I think, so it doesn't work any longer. Perhaps the upgrade.sh approach is better and perhaps I missed this when I rewrote it. I can make it copy cm3cg manually. I haven't gotten a chance to fix anything yet. - Jay > Date: Sat, 30 May 2015 09:58:31 -0500 > From: rodney_bates at lcwb.coop > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > > > > On 05/29/2015 05:31 PM, Jay K wrote: > > cm3/cm3cg are more special than the others, because cm3 is statically linked. > > There is no m3core.dll, that cm3 uses, or m3quake.dll, etc. > > There is m3core.dll, but cm3 doesn't uses it. > > Shipping it doesn't affect the in-use cm3. > > > > > > If/when we fix this, in fact, we can stop doing that static linking. > > It makes sense for m3quake, etc. as there are few/no other users. > > But for libm3/m3core, it'll provide a nice size optimization. > > > > > > The mutual incompatibilty between old/new cm3/cm3cg is perfectly ok. > > It is meant to be dealt with, not avoided. > > > > I agree it's OK. Disallowing it would overly hamstring future development. > But dealing with it means we need to be able to prevent either package > immediately after it is built. > > > > > I believe upgrade.py did deal with this correctly, but this environment > > variable required to quash shipping of cm3cg broke it. > > > > > > The environment variable change really should imho be removed from cm3cg. > > Please. > > > > Jay, I am not sure what you are proposing. When I first looked at the commit for > this change, I was quite confused by my own change. While the comments say it > is to _not_ prematurely ship cm3cg, the code appears to add code to conditionally > ship if INSTALL_CM3_IN_BIN=yes. After the n-th look, I realized that before > the change, it _always_ shipped, regardless of the variable. So it really does > provide for less premature shipping. > > If I just revert it, do-cm3-front.sh will be unconditionally and unusably broken. > As is, it is at least usable if you don't set the variable. Even if there is > some use case where one would want it to ship, (none occurs to me), as is, you > can get this behavior by just setting the variable. > > Moreover, the current behavior for cm3cg is consistent with the current and > long-standing behavior for cm3, i.e., ship iff the variable is set. > > It would make more sense to me to remove the variable check by unconditionally > _not_ shipping. At least do-cm3-front.sh would be usable. But then, what > would be the purpose of the inconsistent use of the variable for cm3? > > > > > > > And then we can switch to "destdir" and remove all the in place updating, perhaps. > > > > > > Or I need to update upgrade.py to ship cm3cg itself. > > I guess I'll do that. > > > > > > upgrade.py may not have worked for you, but I have used it many many times. > > It worked. But currently it is probably broken by the m3cc/src/m3makefile change. > > I'll update it to accommodate that change.. > > > > > > And upgrade.sh I believe was in heavy use by Hudson. > > > > > > - Jay > > > > > > > > > Date: Fri, 29 May 2015 16:10:41 -0500 > > > From: rodney_bates at lcwb.coop > > > CC: m3devel at elegosoft.com > > > To: > > > Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > > > > > > Yes, we could have a better organization. I agree, the principal way > > > should be to build a complete set of everything that matters to the > > > implementation of the language, them replace them all at once. A > > > separate DESTDIR or such is needed. > > > > > > The set, as Jay points out, is larger than just cm3 and m3cc. It includes > > > at least m3core, probably libm3, and cm3, the executable depends on several > > > separately built packages--cm3, m3middle, m3front, m3quake, m3makefile, etc. > > > > > > In general, we can't really assume anything about the kinds of dependencies > > > of one package on old or new versions of another. Right now, cm3 and m3cc > > > are known mutually incompatible between 5.8 and the head, because the numbering > > > in M3CG_Binary.i3 has changed. We could probably establish some coding rules and > > > order-of-install rules that would allow a newer m3cc to work with an older cm3, > > > but that's only one pattern. > > > > > > I once thought do-cm3-*.sh build would do what we are talking about, but it > > > if I remember right, puts every package into immediate use as it is built > > > and also uses overrides, which keeps things inside the source tree, but makes > > > it unshippable. So I always use buildship. This has never, to my knowledge > > > run afoul of any compatibility problem other than between cm3 and m3cc, but it > > > does ship every package besides these two as it is built, so the potential > > > is there. > > > > > > I haven't had the energy to even try to understand just what the upgrade > > > scripts do, but they have not treated me well. If I had done different > > > patterns of incompatible changes, they would probably have been better > > > than the procedure I use. > > > > > > On 05/29/2015 01:06 PM, Jay K wrote: > > > > > I don't see an easy way to make the variable work, as there is no > > > > > constraint on the order that cm3 and cm3cg are built. do-cm3-front.sh > > > > > happens to do cm3cg first, but that is not necessarily required. > > > > > > > > [please pardon my editing...] > > > > > > > > > > > > I see what you mean that cm3cg is an independent node in the graph and can be built in any order, > > > > but, I guess, the story is/was, you have to know the safe order to ship things. > > > > > > > > > > > > It is encoded in pkginfo.txt and the Python scripts honor it..though they don't always use pkginfo.txt for their ordering.. > > > > And encoding the dependency graph there isn't ideal. It is really encoded in the import declarations > > > > in the m3makefiles, usually, but not in this case... > > > > > > > > > > > > The way that works is to build but don't ship cm3cg. > > > > Then ship cm3cg. > > > > Then copy cm3. > > > > Then use the new cm3. > > > > But perhaps it isn't strictly enforced enough. > > > > > > > > > > > > > > > > I used do this fairly often. > > > > Though breaking changes in cm3cg were rare, granted. > > > > But I'd also occasionally bootstrap from an older release. > > > > I'll have to try to do that again soon -- actually make the current > > > > tree easily buildable from the last release. > > > > > > > > > > > > update.py handled it. > > > > > > > > > > > > I'm on the fence. > > > > "buildship" of multiple packages is in general problematic. > > > > I kinda think the whole mechanism needs to be revampled. > > > > > > > > > > > > Let me draw a close analogy. > > > > > > > > > > > > In the slightly larger software world we have: > > > > > > > > make > > > > make install > > > > make install DESTDIR=somewhere_new > > > > > > > > > > > > buildship is equivalent make && make install, or a make install that includes the make part, > > > > as they sometimes do. > > > > Read up on building glibc and they point out how dangerous this is -- how dangerous make install is w/o DESTDIR. > > > > We have the same danger on a smaller scale. > > > > You aren't going to break the "OS", but you can break "cm3". > > > > > > > > > > > > The safe recommendation is make install DESTDIR. > > > > Basically "install" "everything" "on the side", get it all installed, multiple > > > > "packages", then copy or tar/untar it all. Or chroot into it and test it out, and > > > > then do an in-place update. Or swap into the chroot and never return? (tail call install) > > > > > > > > > > > > Don't do a "rolling upgrade". Don't install each package as it is built. No package, no cm3, > > > > not cm3cg, nothing. > > > > > > > > > > > > I'm basically suggesting that. > > > > > > > > > > > > Now, if you say "don't ever ship, but somehow otherwise manually copy", well > > > > that does kind of resolve to the same thing. > > > > > > > > > > > > If you say, "almost don't ever ship, but provide a way to", that is almost the same. > > > > > > > > > > > > make-dist.py follows the make install DESTDIR way. > > > > > > > > It is "better" I guess because I wrote it later, and because I was following > > > > the example of the other .sh files that make distributions. So blame/credit Olaf? :) > > > > > > > > > > > > It starts with a working compiler, copies parts into /temp, builds a new compiler into /tmp, and > > > > uses what it builds to build everything. > > > > > > > > > > > > Again I suggest it be looked into, and maybe be promoted as basically > > > > the replacement for upgrade.py and upgrade.sh. > > > > > > > > > > > > upgrade.py could wrap it and do the final steps of copy/untar in-place. > > > > Or make-dist.py could just print the last optional command. > > > > > > > > > > > > Anyway, I have no time lately, just email. :( > > > > > > > > > > > > - Jay > > > > > > > > > > > > > > > > > Date: Fri, 29 May 2015 11:35:41 -0500 > > > > > From: rodney_bates at lcwb.coop > > > > > To: adacore at marino.st; wagner at elego.de > > > > > CC: m3devel at elegosoft.com > > > > > Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > > > > > > > > > > Setting INSTALL_CM3_IN_BIN=yes is what forces the premature install of cm3cg. > > > > > I see I had encountered this problem two years ago, but then it was happening > > > > > regardless of the value of this variable. My fix only addresses the case when > > > > > the variable is not set. I naively went to extra trouble to preserve the > > > > > existing behavior when it is set--obviously not right. > > > > > > > > > > I don't see an easy way to make the variable work, as there is no > > > > > constraint on the order that cm3 and cm3cg are built. do-cm3-front.sh > > > > > happens to do cm3cg first, but that is not necessarily required. > > > > > > > > > > So INSTALL_CM3_IN_BIN is broken and hard to fix, if the two need > > > > > compatible upgrades. For now, it looks like install-cm3-compiler.sh > > > > > is the only working way. > > > > > > > > > > But maybe John and Olaf have found a different way around this. > > > > > > > > > > On 05/29/2015 10:55 AM, Rodney M. Bates wrote: > > > > > > I don't know yet why, or what needs to change, but here is definitely the problem, starting > > > > > > in line 4575 of your m3c log: > > > > > > > > > > > > > > > > > > g++48 -O2 -pipe -fstack-protector -Wl,-rpath=/usr/local/lib/gcc48 -fno-strict-aliasing -Wl,-rpath=/usr/local/lib/gcc48 -DIN_GCC -Wno-missing-field-initializers -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -o m3cgc1 m3cg/parse.o attribs.o main.o tree-browser.o libbackend.a libcommon-target.a libcommon.a ../libcpp/libcpp.a libcommon.a ../libcpp/libcpp.a ../libiberty/libiberty.a > > > > > > gmake[1]: Leaving directory `/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a/m3-sys/m3cc/AMD64_FREEBSD/gcc' > > > > > > > > > > > > > > > > > > This is copying the newly-built cm3cg (the compiler back end) to your > > > > > > bin directory: > > > > > > > > > > > > Forced ship of cm3cg. > > > > > > --- shipping from AMD64_FREEBSD --- > > > > > > > > > > > > . => /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin > > > > > > cm3cg > > > > > > ==> m3-sys/m3cc done > > > > > > > > > > > > === package m3-libs/m3core === > > > > > > > > > > > > And this is using the cm3 (compiler front end) that was already in the bin > > > > > > directory, and is the release version. > > > > > > > > > > > > +++ /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin/cm3 -build -DROOT='/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a' $RARGS && /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin/cm3 -ship $RARGS -DROOT='/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a' +++ > > > > > > --- building in AMD64_FREEBSD --- > > > > > > > > > > > > ignoring ../src/m3overrides > > > > > > > > > > > > new source -> compiling RTHooks.i3 > > > > > > > > > > > > This is cm3cg (aka m3cgc1) detecting the incompatibility: > > > > > > > > > > > > m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > > > > > > compilation terminated. > > > > > > > > > > > > Here is the counterpart section of my log: > > > > > > > > > > > > g++ -g -O2 -DIN_GCC -Wno-missing-field-initializers -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -o m3cgc1 m3cg/parse.o attribs.o main.o tree-browser.o libbackend.a libcommon-target.a libcommon.a ../libcpp/libcpp.a libcommon.a ../libcpp/libcpp.a ../libiberty/libiberty.a > > > > > > > > > > > > On my build, it's not shipping: > > > > > > > > > > > > Not shipping cm3cg. > > > > > > --- shipping from AMD64_LINUX --- > > > > > > > > > > > > missing ".M3SHIP" file, build the package first. > > > > > > ==> /home/rodney/proj/m3/git/cm3/m3-sys/m3cc done > > > > > > > > > > > > === package /home/rodney/proj/m3/git/cm3/m3-libs/m3core === > > > > > > +++ cm3 -build -DROOT='/home/rodney/proj/m3/git/cm3' $RARGS && cm3 -ship $RARGS -DROOT='/home/rodney/proj/m3/git/cm3' +++ > > > > > > --- building in AMD64_LINUX --- > > > > > > > > > > > > ignoring ../src/m3overrides > > > > > > > > > > > > new source -> compiling RTHooks.i3 > > > > > > new source -> compiling RT0.i3 > > > > > > > > > > > > When it works, the copying of both cm3 and cm3cg to the bin directory is delayed until after both have been > > > > > > built, in the 'install-cm3-compiler.sh upgrade' step. > > > > > > > > > > > > I see your build is using a full path to the bin directory and mine is letting > > > > > > it come from the usual $PATH search, but that should make no difference, as long > > > > > > as the bin directory is found in a consistent way, which seems to be the case > > > > > > in both builds. > > > > > > > > > > > > > > > > > > > > > > > > On 05/29/2015 04:51 AM, John Marino wrote: > > > > > >> On 5/29/2015 11:39, Olaf Wagner wrote: > > > > > >>> On Fri, 29 May 2015 11:10:50 +0200 > > > > > >>> John Marino wrote: > > > > > >>> > > > > > >>>> On 5/29/2015 10:54, Olaf Wagner wrote: > > > > > >>>>> Please try what I suggested in the attached mail: define > > > > > >>>>> INSTALL_CM3_IN_BIN=yes > > > > > >>>>> in the environment and see if that helps. > > > > > >>>>> > > > > > >>>> > > > > > >>>> Unfortunately it seems the result is exactly the same, even when > > > > > >>>> INSTALL_CM3_IN_BIN is defined in the environment. > > > > > >>> > > > > > >>> Can I see the new logs? Has the new backend (cm3cg) been installed now? > > > > > >>> > > > > > >> > > > > > >> It's here: > > > > > >> http://leaf.dragonflybsd.org/~marino/m3c.log > > > > > >> > > > > > >> It never completes "do-cm3-front.sh buildship " > > > > > >> > > > > > >> Note that I'm using a bootstrap install and set INSTALL_ROOT to another > > > > > >> location, but it never gets to the point of installing anything. > > > > > >> > > > > > >> John > > > > > >> > > > > > > > > > > > > > > > > -- > > > > > Rodney Bates > > > > > rodney.m.bates at acm.org > > > > > > -- > > > Rodney Bates > > > rodney.m.bates at acm.org > > -- > Rodney Bates > rodney.m.bates at acm.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Sat May 30 18:38:46 2015 From: mika at async.caltech.edu (mika at async.caltech.edu) Date: Sat, 30 May 2015 09:38:46 -0700 Subject: [M3devel] The role INTEGER and subranges in Modula-3 In-Reply-To: <5569D3AA.2040009@lcwb.coop> References: <5569D3AA.2040009@lcwb.coop> Message-ID: <20150530163846.6EE551A2062@async.async.caltech.edu> Very clear explanation. I might even have been sold on LONGINT. Well, almost. Thanks for the explanation, anyhow! Mika "Rodney M. Bates" writes: >I am suspecting there is some misunderstanding about Modula-3's approach >to integer sizes. > >The original idea is to use subrange types, (which are >programmer-defined,) not different builtin types, to match the value >range you need. The safety rules of the language ensure that values >stored in variables are in the type's range. But all arithmetic is >done in the full native word size of the machine. > >Types are more abstract than most languages, in that different machine >representations (particularly, bit count) need not be different base >types in the language. > >There are no implicit type conversions. Instead, this need is met by >the concept of assignability. If the abstract value is in a >variable's range, it can be assigned to the variable. Size changes, >if needed, are the code generator's problem. > >All this drastically simplifies the language, while also allowing the >programmer to define an exact match between type-imposed value ranges >and what the application needs, rather than just a few powers of two. >Having implied type conversions, which also interact with sizes of >intermediate arithmetic results, requires many pages of language >definition that we avoid. > >LONGINT, which I have advocated, flies in the face of this tidy >scheme. If we could do all arithmetic efficiently in the biggest size >likely to be commonly needed, LONGINT would have no place. But native >sized arithmetic is always the most efficient. In today's world, >there are two very common classes of use cases: 1) 32-bit arithmetic >is wide enough, 2) 32-bit is not wide enough, but 64-bit is. In both >cases, on machines of either native arithmetic size, we want the best >efficiency. LONGINT is for case 2, and when you further need to be >able to run on either size of machine. INTEGER is for otherwise. > >Whether you believe in LONGINT or not, there is certainly no >justification for more base integer types than two: one the native >size of the machine and one bigger. > >Note that, as defined in Modula-3 today, INTEGER and LONGINT are >always distinct types (distinct, regardless of either their value >ranges or of the machine's native word size), with no subtype relation >between them, no assignability between them, no implied conversions >between them, no mixed arithmetic operators, no questions about >intermediate result range, and literals of unambiguous type. Thus we >stay out of the semantic tar pit most languages fall into with >multiple integer sizes, while giving the programmer drastically more >choices on range limits. > >Note that original Modula-3, in contrast to the single integer type, >has three floating point types, no doubt motivated by the messy >realities of taking full advantage of hardware-provided arithmetics. >These three have the same type isolation properties as INTEGER and >LONGINT, with the same consequences. In fact, the integer type >isolation is directly modeled after the floating type isolation. > >-- >Rodney Bates >rodney.m.bates at acm.org From jay.krell at cornell.edu Sat May 30 18:37:49 2015 From: jay.krell at cornell.edu (Jay K) Date: Sat, 30 May 2015 16:37:49 +0000 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop>, <55673AA4.8050100@marino.st>, <20150528190643.faf81897fc5698a06bf37838@elegosoft.com>, <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop>, <556817A1.2090206@marino.st>, <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de>, <55682D1A.2030504@marino.st>, <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de>, <55683689.2090709@marino.st>, , , <55688BFF.5040701@lcwb.coop>,,<5568955D.4060200@lcwb.coop>, ,,, , , <5568D5D1.5040405@lcwb.coop>, , , , <5569D017.5000201@lcwb.coop>, Message-ID: Here is the model to consider. Think of make install. In gcc and glibc, is it special cased? Probably not. Do they have an extra environment variable to turn it on/off? Probably not. Is it fraught with problems like cm3? Probably. Though DESTDIR is the safe way. The environment variable is a workaround for OS limitations, that may or may not exist. If it might exist anywhere, then all OS'es are treated consistently. If we can determine that it exists nowhere, then we can remove. The environment variable does not provide for shipping in the correct order. The user is obligated to do that. Removing the environment variable from cm3 and cm3cg is meant to work. You do this by splitting up build from ship. Build everything, then ship everything. Since shipping doesn't use cm3cg. If there are problems, they aren't found till the results are partly commited and must be backed out -- if you are shipping in-place. That is just the nature of it. That is why make install for glibc is particularly dangerous. My upgrade.py's use of buildship is probably not the right approach. That was probably a mistake and it is easy for me to fix. So it won't end up mattering -- nobody will ever ship cm3 or cm3cg. But when no incompatible change is being made, it is meant to just work. When an incompatible change is made, more care is meant to be taken. - Jay From: jay.krell at cornell.edu To: rodney.m.bates at acm.org Date: Sat, 30 May 2015 16:24:17 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 The variable is not for atomic update of multiple files. The variable exists because updating in-use files reportedly fails on some operating systems. Though I question the truth of even that. If we change ship to rename away upon copy failure, and find a reliable simple way to ensure eventual deletion of the renamed file, then we don't need this. I'll have to experiment on NT. Presumably we've written off Win9x, and I'm not sure about AIX. So consistency with cm3 isn't necessarily desirable/required. do-cm3-front.sh isn't necessarily meant to work when there is an IR change. perhaps m3cc wasn't supposed to be in front. I'll have to double check that later. upgrade.sh is meant to. It doesn't ship anything and manually copies both cm3 and cm3cg. So that still works. And upgrade.py handles it, but other way I think, so it doesn't work any longer. Perhaps the upgrade.sh approach is better and perhaps I missed this when I rewrote it. I can make it copy cm3cg manually. I haven't gotten a chance to fix anything yet. - Jay > Date: Sat, 30 May 2015 09:58:31 -0500 > From: rodney_bates at lcwb.coop > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > > > > On 05/29/2015 05:31 PM, Jay K wrote: > > cm3/cm3cg are more special than the others, because cm3 is statically linked. > > There is no m3core.dll, that cm3 uses, or m3quake.dll, etc. > > There is m3core.dll, but cm3 doesn't uses it. > > Shipping it doesn't affect the in-use cm3. > > > > > > If/when we fix this, in fact, we can stop doing that static linking. > > It makes sense for m3quake, etc. as there are few/no other users. > > But for libm3/m3core, it'll provide a nice size optimization. > > > > > > The mutual incompatibilty between old/new cm3/cm3cg is perfectly ok. > > It is meant to be dealt with, not avoided. > > > > I agree it's OK. Disallowing it would overly hamstring future development. > But dealing with it means we need to be able to prevent either package > immediately after it is built. > > > > > I believe upgrade.py did deal with this correctly, but this environment > > variable required to quash shipping of cm3cg broke it. > > > > > > The environment variable change really should imho be removed from cm3cg. > > Please. > > > > Jay, I am not sure what you are proposing. When I first looked at the commit for > this change, I was quite confused by my own change. While the comments say it > is to _not_ prematurely ship cm3cg, the code appears to add code to conditionally > ship if INSTALL_CM3_IN_BIN=yes. After the n-th look, I realized that before > the change, it _always_ shipped, regardless of the variable. So it really does > provide for less premature shipping. > > If I just revert it, do-cm3-front.sh will be unconditionally and unusably broken. > As is, it is at least usable if you don't set the variable. Even if there is > some use case where one would want it to ship, (none occurs to me), as is, you > can get this behavior by just setting the variable. > > Moreover, the current behavior for cm3cg is consistent with the current and > long-standing behavior for cm3, i.e., ship iff the variable is set. > > It would make more sense to me to remove the variable check by unconditionally > _not_ shipping. At least do-cm3-front.sh would be usable. But then, what > would be the purpose of the inconsistent use of the variable for cm3? > > > > > > > And then we can switch to "destdir" and remove all the in place updating, perhaps. > > > > > > Or I need to update upgrade.py to ship cm3cg itself. > > I guess I'll do that. > > > > > > upgrade.py may not have worked for you, but I have used it many many times. > > It worked. But currently it is probably broken by the m3cc/src/m3makefile change. > > I'll update it to accommodate that change.. > > > > > > And upgrade.sh I believe was in heavy use by Hudson. > > > > > > - Jay > > > > > > > > > Date: Fri, 29 May 2015 16:10:41 -0500 > > > From: rodney_bates at lcwb.coop > > > CC: m3devel at elegosoft.com > > > To: > > > Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > > > > > > Yes, we could have a better organization. I agree, the principal way > > > should be to build a complete set of everything that matters to the > > > implementation of the language, them replace them all at once. A > > > separate DESTDIR or such is needed. > > > > > > The set, as Jay points out, is larger than just cm3 and m3cc. It includes > > > at least m3core, probably libm3, and cm3, the executable depends on several > > > separately built packages--cm3, m3middle, m3front, m3quake, m3makefile, etc. > > > > > > In general, we can't really assume anything about the kinds of dependencies > > > of one package on old or new versions of another. Right now, cm3 and m3cc > > > are known mutually incompatible between 5.8 and the head, because the numbering > > > in M3CG_Binary.i3 has changed. We could probably establish some coding rules and > > > order-of-install rules that would allow a newer m3cc to work with an older cm3, > > > but that's only one pattern. > > > > > > I once thought do-cm3-*.sh build would do what we are talking about, but it > > > if I remember right, puts every package into immediate use as it is built > > > and also uses overrides, which keeps things inside the source tree, but makes > > > it unshippable. So I always use buildship. This has never, to my knowledge > > > run afoul of any compatibility problem other than between cm3 and m3cc, but it > > > does ship every package besides these two as it is built, so the potential > > > is there. > > > > > > I haven't had the energy to even try to understand just what the upgrade > > > scripts do, but they have not treated me well. If I had done different > > > patterns of incompatible changes, they would probably have been better > > > than the procedure I use. > > > > > > On 05/29/2015 01:06 PM, Jay K wrote: > > > > > I don't see an easy way to make the variable work, as there is no > > > > > constraint on the order that cm3 and cm3cg are built. do-cm3-front.sh > > > > > happens to do cm3cg first, but that is not necessarily required. > > > > > > > > [please pardon my editing...] > > > > > > > > > > > > I see what you mean that cm3cg is an independent node in the graph and can be built in any order, > > > > but, I guess, the story is/was, you have to know the safe order to ship things. > > > > > > > > > > > > It is encoded in pkginfo.txt and the Python scripts honor it..though they don't always use pkginfo.txt for their ordering.. > > > > And encoding the dependency graph there isn't ideal. It is really encoded in the import declarations > > > > in the m3makefiles, usually, but not in this case... > > > > > > > > > > > > The way that works is to build but don't ship cm3cg. > > > > Then ship cm3cg. > > > > Then copy cm3. > > > > Then use the new cm3. > > > > But perhaps it isn't strictly enforced enough. > > > > > > > > > > > > > > > > I used do this fairly often. > > > > Though breaking changes in cm3cg were rare, granted. > > > > But I'd also occasionally bootstrap from an older release. > > > > I'll have to try to do that again soon -- actually make the current > > > > tree easily buildable from the last release. > > > > > > > > > > > > update.py handled it. > > > > > > > > > > > > I'm on the fence. > > > > "buildship" of multiple packages is in general problematic. > > > > I kinda think the whole mechanism needs to be revampled. > > > > > > > > > > > > Let me draw a close analogy. > > > > > > > > > > > > In the slightly larger software world we have: > > > > > > > > make > > > > make install > > > > make install DESTDIR=somewhere_new > > > > > > > > > > > > buildship is equivalent make && make install, or a make install that includes the make part, > > > > as they sometimes do. > > > > Read up on building glibc and they point out how dangerous this is -- how dangerous make install is w/o DESTDIR. > > > > We have the same danger on a smaller scale. > > > > You aren't going to break the "OS", but you can break "cm3". > > > > > > > > > > > > The safe recommendation is make install DESTDIR. > > > > Basically "install" "everything" "on the side", get it all installed, multiple > > > > "packages", then copy or tar/untar it all. Or chroot into it and test it out, and > > > > then do an in-place update. Or swap into the chroot and never return? (tail call install) > > > > > > > > > > > > Don't do a "rolling upgrade". Don't install each package as it is built. No package, no cm3, > > > > not cm3cg, nothing. > > > > > > > > > > > > I'm basically suggesting that. > > > > > > > > > > > > Now, if you say "don't ever ship, but somehow otherwise manually copy", well > > > > that does kind of resolve to the same thing. > > > > > > > > > > > > If you say, "almost don't ever ship, but provide a way to", that is almost the same. > > > > > > > > > > > > make-dist.py follows the make install DESTDIR way. > > > > > > > > It is "better" I guess because I wrote it later, and because I was following > > > > the example of the other .sh files that make distributions. So blame/credit Olaf? :) > > > > > > > > > > > > It starts with a working compiler, copies parts into /temp, builds a new compiler into /tmp, and > > > > uses what it builds to build everything. > > > > > > > > > > > > Again I suggest it be looked into, and maybe be promoted as basically > > > > the replacement for upgrade.py and upgrade.sh. > > > > > > > > > > > > upgrade.py could wrap it and do the final steps of copy/untar in-place. > > > > Or make-dist.py could just print the last optional command. > > > > > > > > > > > > Anyway, I have no time lately, just email. :( > > > > > > > > > > > > - Jay > > > > > > > > > > > > > > > > > Date: Fri, 29 May 2015 11:35:41 -0500 > > > > > From: rodney_bates at lcwb.coop > > > > > To: adacore at marino.st; wagner at elego.de > > > > > CC: m3devel at elegosoft.com > > > > > Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > > > > > > > > > > Setting INSTALL_CM3_IN_BIN=yes is what forces the premature install of cm3cg. > > > > > I see I had encountered this problem two years ago, but then it was happening > > > > > regardless of the value of this variable. My fix only addresses the case when > > > > > the variable is not set. I naively went to extra trouble to preserve the > > > > > existing behavior when it is set--obviously not right. > > > > > > > > > > I don't see an easy way to make the variable work, as there is no > > > > > constraint on the order that cm3 and cm3cg are built. do-cm3-front.sh > > > > > happens to do cm3cg first, but that is not necessarily required. > > > > > > > > > > So INSTALL_CM3_IN_BIN is broken and hard to fix, if the two need > > > > > compatible upgrades. For now, it looks like install-cm3-compiler.sh > > > > > is the only working way. > > > > > > > > > > But maybe John and Olaf have found a different way around this. > > > > > > > > > > On 05/29/2015 10:55 AM, Rodney M. Bates wrote: > > > > > > I don't know yet why, or what needs to change, but here is definitely the problem, starting > > > > > > in line 4575 of your m3c log: > > > > > > > > > > > > > > > > > > g++48 -O2 -pipe -fstack-protector -Wl,-rpath=/usr/local/lib/gcc48 -fno-strict-aliasing -Wl,-rpath=/usr/local/lib/gcc48 -DIN_GCC -Wno-missing-field-initializers -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -o m3cgc1 m3cg/parse.o attribs.o main.o tree-browser.o libbackend.a libcommon-target.a libcommon.a ../libcpp/libcpp.a libcommon.a ../libcpp/libcpp.a ../libiberty/libiberty.a > > > > > > gmake[1]: Leaving directory `/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a/m3-sys/m3cc/AMD64_FREEBSD/gcc' > > > > > > > > > > > > > > > > > > This is copying the newly-built cm3cg (the compiler back end) to your > > > > > > bin directory: > > > > > > > > > > > > Forced ship of cm3cg. > > > > > > --- shipping from AMD64_FREEBSD --- > > > > > > > > > > > > . => /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin > > > > > > cm3cg > > > > > > ==> m3-sys/m3cc done > > > > > > > > > > > > === package m3-libs/m3core === > > > > > > > > > > > > And this is using the cm3 (compiler front end) that was already in the bin > > > > > > directory, and is the release version. > > > > > > > > > > > > +++ /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin/cm3 -build -DROOT='/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a' $RARGS && /mech/construction/mech/ptrees/default/lang/modula3/work/bootstrap/bin/cm3 -ship $RARGS -DROOT='/mech/construction/mech/ptrees/default/lang/modula3/work/cm3-8c1b86a' +++ > > > > > > --- building in AMD64_FREEBSD --- > > > > > > > > > > > > ignoring ../src/m3overrides > > > > > > > > > > > > new source -> compiling RTHooks.i3 > > > > > > > > > > > > This is cm3cg (aka m3cgc1) detecting the incompatibility: > > > > > > > > > > > > m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > > > > > > compilation terminated. > > > > > > > > > > > > Here is the counterpart section of my log: > > > > > > > > > > > > g++ -g -O2 -DIN_GCC -Wno-missing-field-initializers -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -o m3cgc1 m3cg/parse.o attribs.o main.o tree-browser.o libbackend.a libcommon-target.a libcommon.a ../libcpp/libcpp.a libcommon.a ../libcpp/libcpp.a ../libiberty/libiberty.a > > > > > > > > > > > > On my build, it's not shipping: > > > > > > > > > > > > Not shipping cm3cg. > > > > > > --- shipping from AMD64_LINUX --- > > > > > > > > > > > > missing ".M3SHIP" file, build the package first. > > > > > > ==> /home/rodney/proj/m3/git/cm3/m3-sys/m3cc done > > > > > > > > > > > > === package /home/rodney/proj/m3/git/cm3/m3-libs/m3core === > > > > > > +++ cm3 -build -DROOT='/home/rodney/proj/m3/git/cm3' $RARGS && cm3 -ship $RARGS -DROOT='/home/rodney/proj/m3/git/cm3' +++ > > > > > > --- building in AMD64_LINUX --- > > > > > > > > > > > > ignoring ../src/m3overrides > > > > > > > > > > > > new source -> compiling RTHooks.i3 > > > > > > new source -> compiling RT0.i3 > > > > > > > > > > > > When it works, the copying of both cm3 and cm3cg to the bin directory is delayed until after both have been > > > > > > built, in the 'install-cm3-compiler.sh upgrade' step. > > > > > > > > > > > > I see your build is using a full path to the bin directory and mine is letting > > > > > > it come from the usual $PATH search, but that should make no difference, as long > > > > > > as the bin directory is found in a consistent way, which seems to be the case > > > > > > in both builds. > > > > > > > > > > > > > > > > > > > > > > > > On 05/29/2015 04:51 AM, John Marino wrote: > > > > > >> On 5/29/2015 11:39, Olaf Wagner wrote: > > > > > >>> On Fri, 29 May 2015 11:10:50 +0200 > > > > > >>> John Marino wrote: > > > > > >>> > > > > > >>>> On 5/29/2015 10:54, Olaf Wagner wrote: > > > > > >>>>> Please try what I suggested in the attached mail: define > > > > > >>>>> INSTALL_CM3_IN_BIN=yes > > > > > >>>>> in the environment and see if that helps. > > > > > >>>>> > > > > > >>>> > > > > > >>>> Unfortunately it seems the result is exactly the same, even when > > > > > >>>> INSTALL_CM3_IN_BIN is defined in the environment. > > > > > >>> > > > > > >>> Can I see the new logs? Has the new backend (cm3cg) been installed now? > > > > > >>> > > > > > >> > > > > > >> It's here: > > > > > >> http://leaf.dragonflybsd.org/~marino/m3c.log > > > > > >> > > > > > >> It never completes "do-cm3-front.sh buildship " > > > > > >> > > > > > >> Note that I'm using a bootstrap install and set INSTALL_ROOT to another > > > > > >> location, but it never gets to the point of installing anything. > > > > > >> > > > > > >> John > > > > > >> > > > > > > > > > > > > > > > > -- > > > > > Rodney Bates > > > > > rodney.m.bates at acm.org > > > > > > -- > > > Rodney Bates > > > rodney.m.bates at acm.org > > -- > Rodney Bates > rodney.m.bates at acm.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From estellnb at elstel.org Sat May 30 18:33:26 2015 From: estellnb at elstel.org (Elmar Stellnberger) Date: Sat, 30 May 2015 18:33:26 +0200 Subject: [M3devel] The role INTEGER and subranges in Modula-3 In-Reply-To: <5569D3AA.2040009@lcwb.coop> References: <5569D3AA.2040009@lcwb.coop> Message-ID: <5569E656.6080909@elstel.org> Am 30.05.15 um 17:13 schrieb Rodney M. Bates: > There are no implicit type conversions. Instead, this need is met by > the concept of assignability. If the abstract value is in a > variable's range, it can be assigned to the variable. Size changes, > if needed, are the code generator's problem. So what does the code generator do if there is an overflow not checked by the predefined value range (i.e. BITS 8 FOR INTEGER instead of BITS 8 for [0..255]) > All this drastically simplifies the language, while also allowing the ... Yes, I understand your decision. > likely to be commonly needed, LONGINT would have no place. But native > sized arithmetic is always the most efficient. In today's world, > there are two very common classes of use cases: 1) 32-bit arithmetic > is wide enough, 2) 32-bit is not wide enough, but 64-bit is. In both > cases, on machines of either native arithmetic size, we want the best > efficiency. LONGINT is for case 2, and when you further need to be > able to run on either size of machine. INTEGER is for otherwise. Well, that was exactly my argument for a language specified type size of INTEGER, because things do not get faster if you use 64bit integers instead of 32bit integers. CPU arithmetics perhaps but the real bottleneck of today is the memory hierarchy - and using 64bit integers doubles our memory need at least for scalars. > > Whether you believe in LONGINT or not, there is certainly no > justification for more base integer types than two: one the native > size of the machine and one bigger. Yes, we really don`t need them as anything becomes 64bit or the native word size respectively on the stack (that is why Ctypes.int works). Memory latency should be a minor issue as long as our parameters and parts of the activation records fit into the cache. From estellnb at elstel.org Sat May 30 18:51:12 2015 From: estellnb at elstel.org (Elmar Stellnberger) Date: Sat, 30 May 2015 18:51:12 +0200 Subject: [M3devel] 64bit INTEGERs, WIDECHAR: language specified or configuration/target dependent? In-Reply-To: <55679CA8.2030905@lcwb.coop> References: <555E14BC.2040805@lcwb.coop> <555E203E.4040203@elstel.org> <0A1CDD8C-EEB5-40E2-A38B-28E8EEA8C37E@elstel.org> <8A3AB2ED-C11E-4787-A7F8-C8F12157EAA5@elstel.org> <555F6D8F.4070109@lcwb.coop> <6F9B9534-7DC2-4D4D-88CB-90D7FA05E8F9@elstel.org> <8BBBC94B-EECC-464A-86BB-FD1C94EC5496@elstel.org> <77605189-D966-4D4B-8946-838BD6E178AA@purdue.edu> <55675464.5090306@elstel.org> <5567723D.3020706@elstel.org> <55679CA8.2030905@lcwb.coop> Message-ID: <5569EA80.7050700@elstel.org> > Well, maybe not stack variables, if the stack has a bigger alignment > to be honored, > quite possibly a hardware requirement. No doubt taking and using the > address of > such would be endian-dependent. Would a C compiler do differently in > this case? > Can you rely on them all doing it the same? Does C specify it? No, as far as I know C can provide multiple calling conventions. However any x86 based system has a word size aligned stack. No way to push or pop half of a word. That way we are at least save for any x86 Intel/AMD - system. From jay.krell at cornell.edu Sat May 30 23:55:06 2015 From: jay.krell at cornell.edu (Jay K) Date: Sat, 30 May 2015 21:55:06 +0000 Subject: [M3devel] 64bit INTEGERs, WIDECHAR: language specified or configuration/target dependent? In-Reply-To: <5569EA80.7050700@elstel.org> References: <555E14BC.2040805@lcwb.coop> <555E203E.4040203@elstel.org> <0A1CDD8C-EEB5-40E2-A38B-28E8EEA8C37E@elstel.org> <8A3AB2ED-C11E-4787-A7F8-C8F12157EAA5@elstel.org> <555F6D8F.4070109@lcwb.coop> <6F9B9534-7DC2-4D4D-88CB-90D7FA05E8F9@elstel.org> <8BBBC94B-EECC-464A-86BB-FD1C94EC5496@elstel.org> <77605189-D966-4D4B-8946-838BD6E178AA@purdue.edu> <55675464.5090306@elstel.org> <5567723D.3020706@elstel.org>, <55679CA8.2030905@lcwb.coop>, <5569EA80.7050700@elstel.org> Message-ID: > No way to push or pop half of a word. sub esp, 2 But nobody does that. Parameters may generally fill whole words, but I doubt locals do. - Jay > Date: Sat, 30 May 2015 18:51:12 +0200 > From: estellnb at elstel.org > To: rodney.m.bates at acm.org; m3devel at elegosoft.com > Subject: Re: [M3devel] 64bit INTEGERs, WIDECHAR: language specified or configuration/target dependent? > > > > Well, maybe not stack variables, if the stack has a bigger alignment > > to be honored, > > quite possibly a hardware requirement. No doubt taking and using the > > address of > > such would be endian-dependent. Would a C compiler do differently in > > this case? > > Can you rely on them all doing it the same? Does C specify it? > No, as far as I know C can provide multiple calling conventions. > However any x86 based system has a word size aligned stack. > No way to push or pop half of a word. That way we are at least save > for any x86 Intel/AMD - system. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.mckinna at gmail.com Sun May 31 01:06:26 2015 From: peter.mckinna at gmail.com (Peter McKinna) Date: Sun, 31 May 2015 09:06:26 +1000 Subject: [M3devel] extended Message-ID: Hi While we are on the subject of integer types can we diverge slightly to floating point types. I wonder if anyone can explain why the extended type is treated exactly the same as longreal in the frontend? They have the same sizes and ranges and precisions. As for backends, at the moment m3cc is generating 8 byte sse instructions for both types. The llvm is generating 10 byte float instructions as per its x86fp80 type which are a fair bit slower at the expense of greater range and precision. However they are not interoperable with legacy libraries and we should probably change the type to agree with m3cc and the frontend. It seems that the 8087 80 bit float is being phased out see http://csapp.cs.cmu.edu/2e/waside/waside-x87.pdf so maybe the m3 implementors saw the writing on the wall and and decided to wait for hardware to catch up. Anyway I wonder if its worth considering making extended one of the 128 bit floating point types which although emulated in software would at least give us a different type and one which would give some applications a huge precision (and range ~10^4090) boost. Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun May 31 03:52:41 2015 From: jay.krell at cornell.edu (Jay K) Date: Sun, 31 May 2015 01:52:41 +0000 Subject: [M3devel] extended In-Reply-To: References: Message-ID: Half seriously: Do we need FLOAT32, FLOAT64, FLOAT80, FLOAT128? And some way to indicate what is available? On many/most/but-not-all modern 32bit x86 systems, "long double" is the same as "double". Modula-3 is in agreement with many/most/but-not-all C systems. m3cc might be using x87 instructions on some platforms, at least sometimes. But that doesn't change in-memory extended to other than 64 bits. Just temporary in-register values might be 80 bits. - Jay Date: Sun, 31 May 2015 09:06:26 +1000 From: peter.mckinna at gmail.com To: m3devel at elegosoft.com Subject: [M3devel] extended Hi While we are on the subject of integer types can we diverge slightly to floating point types. I wonder if anyone can explain why the extended type is treated exactly the same as longreal in the frontend? They have the same sizes and ranges and precisions. As for backends, at the moment m3cc is generating 8 byte sse instructions for both types. The llvm is generating 10 byte float instructions as per its x86fp80 type which are a fair bit slower at the expense of greater range and precision. However they are not interoperable with legacy libraries and we should probably change the type to agree with m3cc and the frontend. It seems that the 8087 80 bit float is being phased out see http://csapp.cs.cmu.edu/2e/waside/waside-x87.pdfso maybe the m3 implementors saw the writing on the wall and and decided to wait for hardware to catch up. Anyway I wonder if its worth considering making extended one of the 128 bit floating point types which although emulated in software would at least give us a different type and one which would give some applications a huge precision (and range ~10^4090) boost. Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Sun May 31 04:09:46 2015 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Sat, 30 May 2015 22:09:46 -0400 Subject: [M3devel] extended In-Reply-To: References: Message-ID: <20150531020946.GA10463@topoi.pooq.com> On Sun, May 31, 2015 at 01:52:41AM +0000, Jay K wrote: > Half seriously: Do we need FLOAT32, FLOAT64, FLOAT80, FLOAT128? > And some way to indicate what is available? Those who do serious numerical analysis for a iving are very careful of their precisions. They really care about these datails to an extent most of us mortalls don't. I've even had freinds complain about compilers that gave them *more* precision than they had asked for. -- hendrik > > > On many/most/but-not-all modern 32bit x86 systems, "long double" is the > same as "double". Modula-3 is in agreement with many/most/but-not-all C systems. > > > m3cc might be using x87 instructions on some platforms, at least sometimes. > But that doesn't change in-memory extended to other than 64 bits. > Just temporary in-register values might be 80 bits. > > > - Jay > > > > Date: Sun, 31 May 2015 09:06:26 +1000 > From: peter.mckinna at gmail.com > To: m3devel at elegosoft.com > Subject: [M3devel] extended > > Hi > While we are on the subject of integer types can we diverge slightly to floating point types. I wonder if anyone can explain why the extended type is treated exactly the same as longreal in the frontend? They have the same sizes and ranges and precisions. As for backends, at the moment m3cc is generating 8 byte sse instructions for both types. The llvm is generating 10 byte float instructions as per its x86fp80 type which are a fair bit slower at the expense of greater range and precision. However they are not interoperable with legacy libraries and we should probably change the type to agree with m3cc and the frontend. It seems that the 8087 80 bit float is being phased out see http://csapp.cs.cmu.edu/2e/waside/waside-x87.pdfso maybe the m3 implementors saw the writing on the wall and and decided to wait for hardware to catch up. Anyway I wonder if its worth considering making extended one of the 128 bit floating point types which although emulated in software would at least give us a different type and one which would give some applications a huge precision (and range ~10^4090) boost. > Peter From mika at async.caltech.edu Sun May 31 04:18:31 2015 From: mika at async.caltech.edu (mika at async.caltech.edu) Date: Sat, 30 May 2015 19:18:31 -0700 Subject: [M3devel] extended In-Reply-To: <20150531020946.GA10463@topoi.pooq.com> References: <20150531020946.GA10463@topoi.pooq.com> Message-ID: <20150531021831.160751A2062@async.async.caltech.edu> Yes, it is standard practice to write x87 registers to memory and read them back to guarantee one is not getting "extended" precision by mistake. Modula-3 does a pretty good job of defining what all the floating formats are, if you look at the various interfaces for the formats. I seem to remember the story is that one of Kahan's grad students was interning at SRC one summer and wrote the interfaces. "Among the best in the business." Mika Hendrik Boom writes: >On Sun, May 31, 2015 at 01:52:41AM +0000, Jay K wrote: >> Half seriously: Do we need FLOAT32, FLOAT64, FLOAT80, FLOAT128? >> And some way to indicate what is available? > >Those who do serious numerical analysis for a iving are very careful of=20 >their precisions. > >They really care about these datails to an extent most of us mortalls=20 >don't. > >I've even had freinds complain about compilers that gave them *more*=20 >precision than they had asked for. > >-- hendrik > >>=20 >> =20 >> On many/most/but-not-all modern 32bit x86 systems, "long double" is the >> same as "double". Modula-3 is in agreement with many/most/but-not-all C s= >ystems. >> =20 >>=20 >> m3cc might be using x87 instructions on some platforms, at least sometime= >s. >> But that doesn't change in-memory extended to other than 64 bits. >> Just temporary in-register values might be 80 bits. >> =20 >>=20 >> - Jay >>=20 >>=20 >> =20 >> Date: Sun, 31 May 2015 09:06:26 +1000 >> From: peter.mckinna at gmail.com >> To: m3devel at elegosoft.com >> Subject: [M3devel] extended >>=20 >> Hi >> While we are on the subject of integer types can we diverge slightly to= > floating point types. I wonder if anyone can explain why the extended type= > is treated exactly the same as longreal in the frontend? They have the sam= >e sizes and ranges and precisions. As for backends, at the moment m3cc i= >s generating 8 byte sse instructions for both types. The llvm is generating= > 10 byte float instructions as per its x86fp80 type which are a fair bit sl= >ower at the expense of greater range and precision. However they are not in= >teroperable with legacy libraries and we should probably change the type to= > agree with m3cc and the frontend. It seems that the 8087 80 bit float is = >being phased out see http://csapp.cs.cmu.edu/2e/waside/waside-x87.pdfso may= >be the m3 implementors saw the writing on the wall and and decided to wait = >for hardware to catch up. Anyway I wonder if its worth considering making e= >xtended one of the 128 bit floating point types which although emulated in = >software would at least give us a different type and one which would give s= >ome applications a huge precision (and range ~10^4090) boost. >> Peter =20 From jay.krell at cornell.edu Sun May 31 06:43:07 2015 From: jay.krell at cornell.edu (Jay K) Date: Sun, 31 May 2015 04:43:07 +0000 Subject: [M3devel] extended In-Reply-To: <20150531021831.160751A2062@async.async.caltech.edu> References: , , <20150531020946.GA10463@topoi.pooq.com>, <20150531021831.160751A2062@async.async.caltech.edu> Message-ID: Modula-3 may be good, but it isn't likely unique here. Apple did a good job probably. C9x caught up probably. - Jay > To: hendrik at topoi.pooq.com > Date: Sat, 30 May 2015 19:18:31 -0700 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] extended > > > Yes, it is standard practice to write x87 registers to memory and read > them back to guarantee one is not getting "extended" precision by mistake. > > Modula-3 does a pretty good job of defining what all the floating formats > are, if you look at the various interfaces for the formats. > > I seem to remember the story is that one of Kahan's grad students was > interning at SRC one summer and wrote the interfaces. > > "Among the best in the business." > > Mika > > Hendrik Boom writes: > >On Sun, May 31, 2015 at 01:52:41AM +0000, Jay K wrote: > >> Half seriously: Do we need FLOAT32, FLOAT64, FLOAT80, FLOAT128? > >> And some way to indicate what is available? > > > >Those who do serious numerical analysis for a iving are very careful of=20 > >their precisions. > > > >They really care about these datails to an extent most of us mortalls=20 > >don't. > > > >I've even had freinds complain about compilers that gave them *more*=20 > >precision than they had asked for. > > > >-- hendrik > > > >>=20 > >> =20 > >> On many/most/but-not-all modern 32bit x86 systems, "long double" is the > >> same as "double". Modula-3 is in agreement with many/most/but-not-all C s= > >ystems. > >> =20 > >>=20 > >> m3cc might be using x87 instructions on some platforms, at least sometime= > >s. > >> But that doesn't change in-memory extended to other than 64 bits. > >> Just temporary in-register values might be 80 bits. > >> =20 > >>=20 > >> - Jay > >>=20 > >>=20 > >> =20 > >> Date: Sun, 31 May 2015 09:06:26 +1000 > >> From: peter.mckinna at gmail.com > >> To: m3devel at elegosoft.com > >> Subject: [M3devel] extended > >>=20 > >> Hi > >> While we are on the subject of integer types can we diverge slightly to= > > floating point types. I wonder if anyone can explain why the extended type= > > is treated exactly the same as longreal in the frontend? They have the sam= > >e sizes and ranges and precisions. As for backends, at the moment m3cc i= > >s generating 8 byte sse instructions for both types. The llvm is generating= > > 10 byte float instructions as per its x86fp80 type which are a fair bit sl= > >ower at the expense of greater range and precision. However they are not in= > >teroperable with legacy libraries and we should probably change the type to= > > agree with m3cc and the frontend. It seems that the 8087 80 bit float is = > >being phased out see http://csapp.cs.cmu.edu/2e/waside/waside-x87.pdfso may= > >be the m3 implementors saw the writing on the wall and and decided to wait = > >for hardware to catch up. Anyway I wonder if its worth considering making e= > >xtended one of the 128 bit floating point types which although emulated in = > >software would at least give us a different type and one which would give s= > >ome applications a huge precision (and range ~10^4090) boost. > >> Peter =20 -------------- next part -------------- An HTML attachment was scrubbed... URL: From adacore at marino.st Sun May 31 09:41:16 2015 From: adacore at marino.st (John Marino) Date: Sun, 31 May 2015 09:41:16 +0200 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <5568B352.8060005@marino.st> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop> <556817A1.2090206@marino.st> <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de> <55682D1A.2030504@marino.st> <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de> <55683689.2090709@marino.st> <20150529122732.1396eb079ff9b404bcb21e40@elego.de> <5568421D.3050209@marino.st> <20150529155833.8454664b88391d93708e8f85@elego.de> <55687266.3090400@marino.st> <20150529162028.388911007a614006049beb42@elego.de> <20150529172305.a3fc2a9865b5250a5b9140fc@elego.de> <556885FD.6010800@marino.st> <20150529180223.d467621b68ebf665da685b12@elego.de> <55689065.1040207@marino.st> <20150529201531.b35e3cfdafeb9e2735e0020b@elegosoft.com> <5568B352.8060005@marino.st> Message-ID: <556ABB1C.5080607@marino.st> On 5/29/2015 20:43, John Marino wrote: > On 5/29/2015 20:15, Olaf Wagner wrote: >> >> Well, yes, I understand that. I would have tried your exact setup, >> but I have no system available to test that on. >> >> At least I have validated that based on the origianl 5.8.6 installation >> archive for AMD64_FREEBSD you can build the new compiler from the current >> sources with a simple call of the upgrade.sh script. which I still doubted >> yesterday. > > > The card I still have left to play is to extract the bootstrap, let it > overwrite itself per Rodney's technique and then build the real compiler > (dumping the whole "intermediate" area). FWIW, this did not work either. Rodney's technique doesn't seem to work with the ports bootstrap. I don't know why it would work with provided 5.8.6 but not rebuilt one. As far as I can tell, I did what he said would always work. I'm at a loss as to where to go from here. It's starting to look like I have to throw away the ports 5.8.6 bootstrap and start over somehow. I don't think it should be this hard. :( John From jay.krell at cornell.edu Sun May 31 11:53:59 2015 From: jay.krell at cornell.edu (Jay K) Date: Sun, 31 May 2015 09:53:59 +0000 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <556ABB1C.5080607@marino.st> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop> <556817A1.2090206@marino.st> <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de> <55682D1A.2030504@marino.st> <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de> <55683689.2090709@marino.st> <20150529122732.1396eb079ff9b404bcb21e40@elego.de> <5568421D.3050209@marino.st> <20150529155833.8454664b88391d93708e8f85@elego.de> <55687266.3090400@marino.st> <20150529162028.388911007a614006049beb42@elego.de> <20150529172305.a3fc2a9865b5250a5b9140fc@elego.de> <556885FD.6010800@marino.st> <20150529180223.d467621b68ebf665da685b12@elego.de> <55689065.1040207@marino.st> <20150529201531.b35e3cfdafeb9e2735e0020b@elegosoft.com>, <5568B352.8060005@marino.st>, <556ABB1C.5080607@marino.st> Message-ID: John, have you tried make-dist.py? i.e. https://github.com/modula3/cm3/blob/master/scripts/python/make-dist.py While it might not be exactly what you need, it should demonstrate the elements. I will try to try this all soon, really, I hope so. It starts with a working compiler, does no in-place updates, build into a unique directory in /tmp, and gives you .tar.gz or such at the end. It does "min" and "all". If you set the STAGE environment variable, it uses that instead of /tmp. It should probably be called M3_STATE or M3_MAKEDIST_STAGE. - Jay > Date: Sun, 31 May 2015 09:41:16 +0200 > From: adacore at marino.st > To: m3devel at elegosoft.com > Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > > On 5/29/2015 20:43, John Marino wrote: > > On 5/29/2015 20:15, Olaf Wagner wrote: > >> > >> Well, yes, I understand that. I would have tried your exact setup, > >> but I have no system available to test that on. > >> > >> At least I have validated that based on the origianl 5.8.6 installation > >> archive for AMD64_FREEBSD you can build the new compiler from the current > >> sources with a simple call of the upgrade.sh script. which I still doubted > >> yesterday. > > > > > > The card I still have left to play is to extract the bootstrap, let it > > overwrite itself per Rodney's technique and then build the real compiler > > (dumping the whole "intermediate" area). > > FWIW, this did not work either. Rodney's technique doesn't seem to work > with the ports bootstrap. I don't know why it would work with provided > 5.8.6 but not rebuilt one. As far as I can tell, I did what he said > would always work. > > I'm at a loss as to where to go from here. It's starting to look like I > have to throw away the ports 5.8.6 bootstrap and start over somehow. I > don't think it should be this hard. :( > > John -------------- next part -------------- An HTML attachment was scrubbed... URL: From adacore at marino.st Sun May 31 16:57:02 2015 From: adacore at marino.st (John Marino) Date: Sun, 31 May 2015 16:57:02 +0200 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop> <556817A1.2090206@marino.st> <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de> <55682D1A.2030504@marino.st> <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de> <55683689.2090709@marino.st> <20150529122732.1396eb079ff9b404bcb21e40@elego.de> <5568421D.3050209@marino.st> <20150529155833.8454664b88391d93708e8f85@elego.de> <55687266.3090400@marino.st> <20150529162028.388911007a614006049beb42@elego.de> <20150529172305.a3fc2a9865b5250a5b9140fc@elego.de> <556885FD.6010800@marino.st> <20150529180223.d467621b68ebf665da685b12@elego.de> <55689065.1040207@marino.st> <20150529201531.b35e3cfdafeb9e2735e0020b@elegosoft.com>, <5568B352.8060005@marino.st>, <556ABB1C.5080607@marino.st> Message-ID: <556B213E.8030108@marino.st> On 5/31/2015 11:53, Jay K wrote: > John, have you tried make-dist.py? > i.e. https://github.com/modula3/cm3/blob/master/scripts/python/make-dist.py > > While it might not be exactly what you need, it should demonstrate the > elements. > > I will try to try this all soon, really, I hope so. > > It starts with a working compiler, does no in-place updates, build into > a unique directory in /tmp, and gives you .tar.gz or such at the end. > It does "min" and "all". > > If you set the STAGE environment variable, it uses that instead of /tmp. > It should probably be called M3_STATE or M3_MAKEDIST_STAGE. > > - Jay > Hi Jay, I'm getting the same error as always using make-dist script: http://leaf.dragonflybsd.org/~marino/m3d.log Thanks, John From jay.krell at cornell.edu Sun May 31 18:45:42 2015 From: jay.krell at cornell.edu (Jay K) Date: Sun, 31 May 2015 16:45:42 +0000 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <556B213E.8030108@marino.st> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop>, <55673AA4.8050100@marino.st>, <20150528190643.faf81897fc5698a06bf37838@elegosoft.com>, <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop>, <556817A1.2090206@marino.st>, <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de>, <55682D1A.2030504@marino.st>, <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de>, <55683689.2090709@marino.st>, <20150529122732.1396eb079ff9b404bcb21e40@elego.de>, <5568421D.3050209@marino.st>, <20150529155833.8454664b88391d93708e8f85@elego.de>, <55687266.3090400@marino.st>, <20150529162028.388911007a614006049beb42@elego.de>, <20150529172305.a3fc2a9865b5250a5b9140fc@elego.de>, <556885FD.6010800@marino.st>, <20150529180223.d467621b68ebf665da685b12@elego.de>, <55689065.1040207@marino.st>, <20150529201531.b35e3cfdafeb9e2735e0020b@elegosoft.com>, <5568B352.8060005@marino.st>, <556ABB1C.5080607@marino.st>, , <556B213E.8030108@marino.st> Message-ID: Hm. Strange. I need to read more closely. I see it skipping shipping, but my read was it didn't try that. So.. with INSTALL_CM3_IN_BIN=yes? I need to try this all, and "fix" it to set that. The whole thing in m3cc/src/m3makefile is relatively new vs. when I was actively using all this. :( - Jay > Date: Sun, 31 May 2015 16:57:02 +0200 > From: adacore at marino.st > To: jay.krell at cornell.edu; m3devel at elegosoft.com > Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > > On 5/31/2015 11:53, Jay K wrote: > > John, have you tried make-dist.py? > > i.e. https://github.com/modula3/cm3/blob/master/scripts/python/make-dist.py > > > > While it might not be exactly what you need, it should demonstrate the > > elements. > > > > I will try to try this all soon, really, I hope so. > > > > It starts with a working compiler, does no in-place updates, build into > > a unique directory in /tmp, and gives you .tar.gz or such at the end. > > It does "min" and "all". > > > > If you set the STAGE environment variable, it uses that instead of /tmp. > > It should probably be called M3_STATE or M3_MAKEDIST_STAGE. > > > > - Jay > > > > Hi Jay, > I'm getting the same error as always using make-dist script: > http://leaf.dragonflybsd.org/~marino/m3d.log > > Thanks, > John -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun May 31 19:09:24 2015 From: jay.krell at cornell.edu (Jay K) Date: Sun, 31 May 2015 17:09:24 +0000 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: References: <556700B0.8060500@marino.st>,<55672DC1.7080509@lcwb.coop>, <55673AA4.8050100@marino.st>, , <20150528190643.faf81897fc5698a06bf37838@elegosoft.com>, , <55679387.8040701@lcwb.coop>, <5567DA8C.3050802@lcwb.coop>, <556817A1.2090206@marino.st>, , <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de>, , <55682D1A.2030504@marino.st>, , <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de>, , <55683689.2090709@marino.st>, , <20150529122732.1396eb079ff9b404bcb21e40@elego.de>, , <5568421D.3050209@marino.st>, , <20150529155833.8454664b88391d93708e8f85@elego.de>, , <55687266.3090400@marino.st>, , <20150529162028.388911007a614006049beb42@elego.de>, , <20150529172305.a3fc2a9865b5250a5b9140fc@elego.de>, , <556885FD.6010800@marino.st>, , <20150529180223.d467621b68ebf665da685b12@elego.de>, , <55689065.1040207@marino.st>, , <20150529201531.b35e3cfdafeb9e2735e0020b@elegosoft.com>, , <5568B352.8060005@marino.st>, <556ABB1C.5080607@marino.st>, , , , <556B213E.8030108@marino.st>, Message-ID: Oh probably the problem is using the backend premature actually. Darn, I can't help right now. - Jay From: jay.krell at cornell.edu To: adacore at marino.st; m3devel at elegosoft.com Date: Sun, 31 May 2015 16:45:42 +0000 Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 Hm. Strange. I need to read more closely. I see it skipping shipping, but my read was it didn't try that. So.. with INSTALL_CM3_IN_BIN=yes? I need to try this all, and "fix" it to set that. The whole thing in m3cc/src/m3makefile is relatively new vs. when I was actively using all this. :( - Jay > Date: Sun, 31 May 2015 16:57:02 +0200 > From: adacore at marino.st > To: jay.krell at cornell.edu; m3devel at elegosoft.com > Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 > > On 5/31/2015 11:53, Jay K wrote: > > John, have you tried make-dist.py? > > i.e. https://github.com/modula3/cm3/blob/master/scripts/python/make-dist.py > > > > While it might not be exactly what you need, it should demonstrate the > > elements. > > > > I will try to try this all soon, really, I hope so. > > > > It starts with a working compiler, does no in-place updates, build into > > a unique directory in /tmp, and gives you .tar.gz or such at the end. > > It does "min" and "all". > > > > If you set the STAGE environment variable, it uses that instead of /tmp. > > It should probably be called M3_STATE or M3_MAKEDIST_STAGE. > > > > - Jay > > > > Hi Jay, > I'm getting the same error as always using make-dist script: > http://leaf.dragonflybsd.org/~marino/m3d.log > > Thanks, > John -------------- next part -------------- An HTML attachment was scrubbed... URL: From adacore at marino.st Sun May 31 19:59:05 2015 From: adacore at marino.st (John Marino) Date: Sun, 31 May 2015 19:59:05 +0200 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: References: <556700B0.8060500@marino.st>, <55679387.8040701@lcwb.coop>, <5567DA8C.3050802@lcwb.coop>, <556817A1.2090206@marino.st>, , <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de>, , <55682D1A.2030504@marino.st>, , <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de>, , <55683689.2090709@marino.st>, , <20150529122732.1396eb079ff9b404bcb21e40@elego.de>, , <5568421D.3050209@marino.st>, , <20150529155833.8454664b88391d93708e8f85@elego.de>, , <55687266.3090400@marino.st>, , <20150529162028.388911007a614006049beb42@elego.de>, , <20150529172305.a3fc2a9865b5250a5b9140fc@elego.de>, , <556885FD.6010800@marino.st>, , <20150529180223.d467621b68ebf665da685b12@elego.de>, , <55689065.1040207@marino.st>, , <20150529201531.b35e3cfdafeb9e2735e0020b@elegosoft.com>, , <5568B352.8060005@marino.st>, <556ABB1C.5080607@marino.st>, , , , <556B213E.8030108@marino.st>, Message-ID: <556B4BE9.1000902@marino.st> I removed "INSTALL_CM3_IN_BIN=yes" after reading the thread about it. Should I put it back? From the last response I'm guessing that wasn't the problem. John On 5/31/2015 19:09, Jay K wrote: > Oh probably the problem is using the backend premature actually. > Darn, I can't help right now. > > - Jay > > > > ------------------------------------------------------------------------ > From: jay.krell at cornell.edu > To: adacore at marino.st; m3devel at elegosoft.com > Date: Sun, 31 May 2015 16:45:42 +0000 > Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp > (0x100), expected 0x110 > > Hm. Strange. I need to read more closely. I see it skipping shipping, > but my read was it didn't try that. > So.. with INSTALL_CM3_IN_BIN=yes? > I need to try this all, and "fix" it to set that. The whole thing in > m3cc/src/m3makefile is relatively > new vs. when I was actively using all this. :( > > - Jay > > >> Date: Sun, 31 May 2015 16:57:02 +0200 >> From: adacore at marino.st >> To: jay.krell at cornell.edu; m3devel at elegosoft.com >> Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp > (0x100), expected 0x110 >> >> On 5/31/2015 11:53, Jay K wrote: >> > John, have you tried make-dist.py? >> > i.e. > https://github.com/modula3/cm3/blob/master/scripts/python/make-dist.py >> > >> > While it might not be exactly what you need, it should demonstrate the >> > elements. >> > >> > I will try to try this all soon, really, I hope so. >> > >> > It starts with a working compiler, does no in-place updates, build into >> > a unique directory in /tmp, and gives you .tar.gz or such at the end. >> > It does "min" and "all". >> > >> > If you set the STAGE environment variable, it uses that instead of /tmp. >> > It should probably be called M3_STATE or M3_MAKEDIST_STAGE. >> > >> > - Jay >> > >> >> Hi Jay, >> I'm getting the same error as always using make-dist script: >> http://leaf.dragonflybsd.org/~marino/m3d.log >> >> Thanks, >> John From estellnb at elstel.org Sun May 31 19:50:21 2015 From: estellnb at elstel.org (Elmar Stellnberger) Date: Sun, 31 May 2015 19:50:21 +0200 Subject: [M3devel] cm3/m3quake: setting environment variables for exec Message-ID: <556B49DD.20909@elstel.org> How can I set environment variables for exec with cm3? Using /usr/bin/env would be inherently non-portable. With SRC M3 I remember this was the 4th parameter or so. However cm3 exec seems to do something very different. From rodney_bates at lcwb.coop Sun May 31 20:30:46 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sun, 31 May 2015 13:30:46 -0500 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <556B4BE9.1000902@marino.st> References: <556700B0.8060500@marino.st>, <5567DA8C.3050802@lcwb.coop>, <556817A1.2090206@marino.st>, , <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de>, , <55682D1A.2030504@marino.st>, , <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de>, , <55683689.2090709@marino.st>, , <20150529122732.1396eb079ff9b404bcb21e40@elego.de>, , <5568421D.3050209@marino.st>, , <20150529155833.8454664b88391d93708e8f85@elego.de>, , <55687266.3090400@marino.st>, , <20150529162028.388911007a614006049beb42@elego.de>, , <20150529172305.a3fc2a9865b5250a5b9140fc@elego.de>, , <556885FD.6010800@marino.st>, , <20150529180223.d467621b68ebf665da685b12@elego.de>, , <55689065.1040207@marino.st>, , <20150529201531.b35e3cfdafeb9e2735e0020b@elegosoft.com>, , <5568B352.8060005@marino.st>, <556ABB1C.5080607@marino.st>, , , , <556B213E.8030108@marino.st>, <556B4BE9.1000902@marino .st> Message-ID: <556B5356.40809@lcwb.coop> On 05/31/2015 12:59 PM, John Marino wrote: > I removed "INSTALL_CM3_IN_BIN=yes" after reading the thread about it. > Should I put it back? From the last response I'm guessing that wasn't > the problem. > > John > It apparently wasn't the only problem, but it definitely was a problem. Don't put it back. I causes the new cm3cg executable to be copied to your bin directory immediately after it has been built. It is incompatible with the old cm3 executable, and the next attempted build (m3core, as I remember) runs the old cm3, then the new cm3cg, which correctly recognizes that its input is in an old version format and refuses, giving the error message. > > On 5/31/2015 19:09, Jay K wrote: >> Oh probably the problem is using the backend premature actually. >> Darn, I can't help right now. >> >> - Jay >> >> >> >> ------------------------------------------------------------------------ >> From: jay.krell at cornell.edu >> To: adacore at marino.st; m3devel at elegosoft.com >> Date: Sun, 31 May 2015 16:45:42 +0000 >> Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp >> (0x100), expected 0x110 >> >> Hm. Strange. I need to read more closely. I see it skipping shipping, >> but my read was it didn't try that. >> So.. with INSTALL_CM3_IN_BIN=yes? >> I need to try this all, and "fix" it to set that. The whole thing in >> m3cc/src/m3makefile is relatively >> new vs. when I was actively using all this. :( >> >> - Jay >> >> >>> Date: Sun, 31 May 2015 16:57:02 +0200 >>> From: adacore at marino.st >>> To: jay.krell at cornell.edu; m3devel at elegosoft.com >>> Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp >> (0x100), expected 0x110 >>> >>> On 5/31/2015 11:53, Jay K wrote: >>>> John, have you tried make-dist.py? >>>> i.e. >> https://github.com/modula3/cm3/blob/master/scripts/python/make-dist.py >>>> >>>> While it might not be exactly what you need, it should demonstrate the >>>> elements. >>>> >>>> I will try to try this all soon, really, I hope so. >>>> >>>> It starts with a working compiler, does no in-place updates, build into >>>> a unique directory in /tmp, and gives you .tar.gz or such at the end. >>>> It does "min" and "all". >>>> >>>> If you set the STAGE environment variable, it uses that instead of /tmp. >>>> It should probably be called M3_STATE or M3_MAKEDIST_STAGE. >>>> >>>> - Jay >>>> >>> >>> Hi Jay, >>> I'm getting the same error as always using make-dist script: >>> http://leaf.dragonflybsd.org/~marino/m3d.log >>> >>> Thanks, >>> John > -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Sun May 31 21:13:46 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sun, 31 May 2015 14:13:46 -0500 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <556ABB1C.5080607@marino.st> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop> <556817A1.2090206@marino.st> <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de> <55682D1A.2030504@marino.st> <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de> <55683689.2090709@marino.st> <20150529122732.1396eb079ff9b404bcb21e40@elego.de> <5568421D.3050209@marino.st> <20150529155833.8454664b88391d93708e8f85@elego.de> <55687266.3090400@marino.st> <20150529162028.388911007a614006049beb42@elego.de> <20150529172305.a3fc2a9865b5250a5b9140fc@elego.de> <556885FD.6010800@marino.st> <20150529180223.d467621b68ebf665da685b12@elego.de> <55689065.1040207@marino.st> <20150529201531.b35e3cfdafeb9e2735e0020b@elegosoft.com> <5568B352.8060005@marino.st> <556ABB1C.5080607@marino.st> Message-ID: <556B5D6A.3030403@lcwb.coop> The error message you keep getting pretty certainly means it is running a new cm3cg with an old cm3. And it consistently happens immediately after cm3cg is rebuilt. The build of cm3cg (package m3cc) appears to be the first use of cm3 in all your failed builds, and I don't think that package would ever run cm3cg, as there is no Modula-3 code in it. Which means there is no proof that the version of cm3cg that would have been used before it was rebuilt is the old one. (Could it be a new one left over from a previous incomplete build?) One experiment that would prove this would be, in the state your are starting from before trying a full build, try any means of running cm3 on a package that contains Modula-3 code, to see if it avoids the recurring problem. But I have another theory. I don't know what this ports bootstrap is, but there was a time when things where set up so that cm3, instead of looking in just the same directory as its own executable was found, was looking several alternative places for an executable cm3cg. This caused the same problem to occur in a different way. Even when the newly rebuilt cm3cg executable was not copied to the bin directory right away, its mere existence where it was built was causing it to be found the next time cm3 started up, leading to the same failure. I don't remember how this was fixed, but either Jay or I did something about it. Perhaps the ports bootstrap was made during a time when this behavior was happening. On 05/31/2015 02:41 AM, John Marino wrote: > On 5/29/2015 20:43, John Marino wrote: >> On 5/29/2015 20:15, Olaf Wagner wrote: >>> >>> Well, yes, I understand that. I would have tried your exact setup, >>> but I have no system available to test that on. >>> >>> At least I have validated that based on the origianl 5.8.6 installation >>> archive for AMD64_FREEBSD you can build the new compiler from the current >>> sources with a simple call of the upgrade.sh script. which I still doubted >>> yesterday. >> >> >> The card I still have left to play is to extract the bootstrap, let it >> overwrite itself per Rodney's technique and then build the real compiler >> (dumping the whole "intermediate" area). > > FWIW, this did not work either. Rodney's technique doesn't seem to work > with the ports bootstrap. I don't know why it would work with provided > 5.8.6 but not rebuilt one. As far as I can tell, I did what he said > would always work. > > I'm at a loss as to where to go from here. It's starting to look like I > have to throw away the ports 5.8.6 bootstrap and start over somehow. I > don't think it should be this hard. :( > > John > -- Rodney Bates rodney.m.bates at acm.org From adacore at marino.st Sun May 31 21:26:45 2015 From: adacore at marino.st (John Marino) Date: Sun, 31 May 2015 21:26:45 +0200 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <556B5D6A.3030403@lcwb.coop> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop> <556817A1.2090206@marino.st> <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de> <55682D1A.2030504@marino.st> <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de> <55683689.2090709@marino.st> <20150529122732.1396eb079ff9b404bcb21e40@elego.de> <5568421D.3050209@marino.st> <20150529155833.8454664b88391d93708e8f85@elego.de> <55687266.3090400@marino.st> <20150529162028.388911007a614006049beb42@elego.de> <20150529172305.a3fc2a9865b5250a5b9140fc@elego.de> <556885FD.6010800@marino.st> <20150529180223.d467621b68ebf665da685b12@elego.de> <55689065.1040207@marino.st> <20150529201531.b35e3cfdafeb9e2735e0020b@elegosoft.com> <5568B352.8060005@marino.st> <556ABB1C.5080607@marino.st> <556B5D6A.3030403@lcwb.coop> Message-ID: <556B6075.6010703@marino.st> On 5/31/2015 21:13, Rodney M. Bates wrote: > The error message you keep getting pretty certainly means it is running a > new cm3cg with an old cm3. And it consistently happens immediately after > cm3cg is rebuilt. > > The build of cm3cg (package m3cc) appears to be the first use of cm3 in all > your failed builds, and I don't think that package would ever run cm3cg, as > there is no Modula-3 code in it. Which means there is no proof that the > version of cm3cg that would have been used before it was rebuilt is the old > one. (Could it be a new one left over from a previous incomplete build?) That's not possible. The bootstrap is packaged in a compressed tarball and extracted for the sole purpose of building M3. It would have not leftovers in it. It comes with cm3, cm3cg, m3bundle, and mklib in the bin directory. the contents of the bootstrap M3 cm3.cfg are: INSTALL_ROOT = path() & "/.." include (path() & "/../etc/modula3/AMD64_FREEBSD") > One experiment that would prove this would be, in the state your are > starting from before trying a full build, try any means of running > cm3 on a package that contains Modula-3 code, to see if it avoids the > recurring problem. I think this is N/A. The bootstrap compiler is extracted to a directory that is not on the path (and only exists right before trying to build modula3 port) > But I have another theory. I don't know what this ports bootstrap > is, but there was a time when things where set up so that cm3, instead > of looking in just the same directory as its own executable was found, > was looking several alternative places for an executable cm3cg. This It's 5.8.6 and the cm3.cfg is listed above. You can download it yourself here: http://downloads.dragonlace.net/m3/m3-bootstrap.AMD64.FREEBSD.92.tar.bz2 > caused the same problem to occur in a different way. Even when the > newly rebuilt cm3cg executable was not copied to the bin directory > right away, its mere existence where it was built was causing it to > be found the next time cm3 started up, leading to the same failure. > > I don't remember how this was fixed, but either Jay or I did something > about it. Perhaps the ports bootstrap was made during a time when this > behavior was happening. Probably not as I am 99% sure the bootstrap was built from the release source. Thanks, John From rodney_bates at lcwb.coop Sun May 31 22:14:09 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sun, 31 May 2015 15:14:09 -0500 Subject: [M3devel] The role INTEGER and subranges in Modula-3 In-Reply-To: <5569E656.6080909@elstel.org> References: <5569D3AA.2040009@lcwb.coop> <5569E656.6080909@elstel.org> Message-ID: <556B6B91.1030600@lcwb.coop> On 05/30/2015 11:33 AM, Elmar Stellnberger wrote: > Am 30.05.15 um 17:13 schrieb Rodney M. Bates: >> There are no implicit type conversions. Instead, this need is met by >> the concept of assignability. If the abstract value is in a >> variable's range, it can be assigned to the variable. Size changes, >> if needed, are the code generator's problem. > So what does the code generator do if there is an overflow not checked > by the predefined value range (i.e. BITS 8 FOR INTEGER instead of > BITS 8 for [0..255]) BITS 8 FOR INTEGER will not compile. It is statically illegal, because the asked-for bit size is not enough to hold the value range of the type INTEGER. (Unless the compiler is configured with FIRST(INTEGER) = -128 and LAST(INTEGER) = 127, as might be done for an 8-bit microprocessor.) >> All this drastically simplifies the language, while also allowing the ... > Yes, I understand your decision. >> likely to be commonly needed, LONGINT would have no place. But native >> sized arithmetic is always the most efficient. In today's world, >> there are two very common classes of use cases: 1) 32-bit arithmetic is wide enough, 2) 32-bit is not wide enough, but 64-bit is. In both >> cases, on machines of either native arithmetic size, we want the best >> efficiency. LONGINT is for case 2, and when you further need to be >> able to run on either size of machine. INTEGER is for otherwise. > Well, that was exactly my argument for a language specified type > size of INTEGER, because things do not get faster if you use 64bit > integers instead of 32bit integers. CPU arithmetics perhaps but the > real bottleneck of today is the memory hierarchy - and using 64bit > integers doubles our memory need at least for scalars. >> >> Whether you believe in LONGINT or not, there is certainly no >> justification for more base integer types than two: one the native >> size of the machine and one bigger. > Yes, we really don`t need them as anything becomes 64bit or the native > word size respectively on the stack (that is why Ctypes.int works). > Memory latency should be a minor issue as long as our parameters and > parts of the activation records fit into the cache. > > > > -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Sun May 31 22:51:10 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sun, 31 May 2015 15:51:10 -0500 Subject: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110 In-Reply-To: <556B6075.6010703@marino.st> References: <556700B0.8060500@marino.st> <55672DC1.7080509@lcwb.coop> <55673AA4.8050100@marino.st> <20150528190643.faf81897fc5698a06bf37838@elegosoft.com> <55679387.8040701@lcwb.coop> <5567DA8C.3050802@lcwb.coop> <556817A1.2090206@marino.st> <20150529105451.e9c9b9c2a5578a28bc654f97@elego.de> <55682D1A.2030504@marino.st> <20150529113935.7b0ebcf1bb584c5a8543e0b5@elego.de> <55683689.2090709@marino.st> <20150529122732.1396eb079ff9b404bcb21e40@elego.de> <5568421D.3050209@marino.st> <20150529155833.8454664b88391d93708e8f85@elego.de> <55687266.3090400@marino.st> <20150529162028.388911007a614006049beb42@elego.de> <20150529172305.a3fc2a9865b5250a5b9140fc@elego.de> <556885FD.6010800@marino.st> <20150529180223.d467621b68ebf665da685b12@elego.de> <55689065.1040207@marino.st> <20150529201531.b35e3cfdafeb9e2735e0020b@elegosoft.com> <5568B352.8060005@marino.st> <556ABB1C.5080607@marino.st> <556B5D6A.3030403@lcwb.coop> <556B6075.6010703@marino.st> Message-ID: <556B743E.7030504@lcwb.coop> On 05/31/2015 02:26 PM, John Marino wrote: > On 5/31/2015 21:13, Rodney M. Bates wrote: >> The error message you keep getting pretty certainly means it is running a >> new cm3cg with an old cm3. And it consistently happens immediately after >> cm3cg is rebuilt. >> >> The build of cm3cg (package m3cc) appears to be the first use of cm3 in all >> your failed builds, and I don't think that package would ever run cm3cg, as >> there is no Modula-3 code in it. Which means there is no proof that the >> version of cm3cg that would have been used before it was rebuilt is the old >> one. (Could it be a new one left over from a previous incomplete build?) > > That's not possible. The bootstrap is packaged in a compressed tarball > and extracted for the sole purpose of building M3. It would have not > leftovers in it. > > It comes with cm3, cm3cg, m3bundle, and mklib in the bin directory. > > the contents of the bootstrap M3 cm3.cfg are: > INSTALL_ROOT = path() & "/.." > include (path() & "/../etc/modula3/AMD64_FREEBSD") > > >> One experiment that would prove this would be, in the state your are >> starting from before trying a full build, try any means of running >> cm3 on a package that contains Modula-3 code, to see if it avoids the >> recurring problem. > > I think this is N/A. The bootstrap compiler is extracted to a directory > that is not on the path (and only exists right before trying to build > modula3 port) > > >> But I have another theory. I don't know what this ports bootstrap >> is, but there was a time when things where set up so that cm3, instead >> of looking in just the same directory as its own executable was found, >> was looking several alternative places for an executable cm3cg. This > > It's 5.8.6 and the cm3.cfg is listed above. You can download it > yourself here: > http://downloads.dragonlace.net/m3/m3-bootstrap.AMD64.FREEBSD.92.tar.bz2 > OK, the fix I mentioned is in the 5.8 release branch on github, but it is not in the above bootstrap. In file bootstrap/etc/modula3/cm3cfg.common, line 274 needs to change from: 274: foreach root in [ m3cc, bin ] to: 274: foreach root in [ bin ] Before building the Modula-3 head. > >> caused the same problem to occur in a different way. Even when the >> newly rebuilt cm3cg executable was not copied to the bin directory >> right away, its mere existence where it was built was causing it to >> be found the next time cm3 started up, leading to the same failure. >> >> I don't remember how this was fixed, but either Jay or I did something >> about it. Perhaps the ports bootstrap was made during a time when this >> behavior was happening. > > Probably not as I am 99% sure the bootstrap was built from the release > source. > > Thanks, > John > > > > -- Rodney Bates rodney.m.bates at acm.org