From rodney_bates at lcwb.coop Tue Dec 1 21:17:00 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Tue, 01 Dec 2015 14:17:00 -0600 Subject: [M3devel] [M3commit] [modula3/cm3] b3c18e: Rework indirect calls to possibly nested procedure... In-Reply-To: References: <565cb8dc1ef05_532e3fd1219432c01066b@hookshot-fe5-cp1-prd.iad.github.net.mail> Message-ID: <565E003C.60104@lcwb.coop> Yeah, I would like some changes to the IR too. But it is fairly painful. Many places need to be changed, and I recall some kind of rebuild/bootstrap problem too. I am collecting a list of things I would like, with the idea of doing it all in one change. Some of my wishes predate my writing them down, and I hope I can remember them too. Some of them are motivated by debug information. On 12/01/2015 01:41 PM, Jay wrote: > I suggest one or two changes to the IR. > > > 1. An "official" in-memory representation of a complete unit or program. Modern systems can afford it. > > > 2. More information with function calls. Likely combining parameters with calls. No more start/end. All parameters must be locals (possibly uplevel) or parameters or globals or temporaries, never expressions. This is likely the case already. > > > And, aside, look what I do for C. I made it work somehow. I don't remember off hand but I did odd stuff also because of static links. Like maybe always passing one, even if null, as last parameter, because extra parameters are always allowed in C. I declare the function pointers with "..." (slightly different in C vs. C++). > > > The gcc backend passes static link in a register dedicated to it. > > - Jay > > On Nov 30, 2015, at 2:00 PM, Rodney Bates wrote: > >> Moreover, CM3's seemingly nice idea of making IR operators >> method calls makes it very awkward to do idiom recognition or >> state-dependent handling of general-purpose operators. > _______________________________________________ > M3commit mailing list > M3commit at elegosoft.com > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3commit > -- Rodney Bates rodney.m.bates at acm.org From jay.krell at cornell.edu Wed Dec 2 05:03:48 2015 From: jay.krell at cornell.edu (Jay) Date: Tue, 1 Dec 2015 21:03:48 -0700 Subject: [M3devel] [M3commit] [modula3/cm3] b3c18e: Rework indirect calls to possibly nested procedure... In-Reply-To: <565E003C.60104@lcwb.coop> References: <565cb8dc1ef05_532e3fd1219432c01066b@hookshot-fe5-cp1-prd.iad.github.net.mail> <565E003C.60104@lcwb.coop> Message-ID: <33C83013-53BA-47D1-A878-A7B81A9D23AD@gmail.com> Feel free to checkin a wishlist/todo. I feel that I have been through a fair amount & that most of the obstacles to change are actually imaginary. & most of the "difficulties" are "equivalent". That is, the build order and scripts are what they should be, & accommodate all concievable changes. IF the compiler depends on new language/runtime features then they must be first implemented, build it all, then depend on it. But this probably doesn't apply here. - Jay On Dec 1, 2015, at 1:17 PM, "Rodney M. Bates" wrote: > Yeah, I would like some changes to the IR too. But it is fairly painful. > Many places need to be changed, and I recall some kind of rebuild/bootstrap > problem too. I am collecting a list of things I would like, with the idea > of doing it all in one change. Some of my wishes predate my writing them > down, and I hope I can remember them too. Some of them are motivated by > debug information. > > On 12/01/2015 01:41 PM, Jay wrote: >> I suggest one or two changes to the IR. >> >> >> 1. An "official" in-memory representation of a complete unit or program. Modern systems can afford it. >> >> >> 2. More information with function calls. Likely combining parameters with calls. No more start/end. All parameters must be locals (possibly uplevel) or parameters or globals or temporaries, never expressions. This is likely the case already. >> >> >> And, aside, look what I do for C. I made it work somehow. I don't remember off hand but I did odd stuff also because of static links. Like maybe always passing one, even if null, as last parameter, because extra parameters are always allowed in C. I declare the function pointers with "..." (slightly different in C vs. C++). >> >> >> The gcc backend passes static link in a register dedicated to it. >> >> - Jay >> >> On Nov 30, 2015, at 2:00 PM, Rodney Bates wrote: >> >>> Moreover, CM3's seemingly nice idea of making IR operators >>> method calls makes it very awkward to do idiom recognition or >>> state-dependent handling of general-purpose operators. >> _______________________________________________ >> M3commit mailing list >> M3commit at elegosoft.com >> https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3commit > > -- > Rodney Bates > rodney.m.bates at acm.org > _______________________________________________ > M3commit mailing list > M3commit at elegosoft.com > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3commit From hendrik at topoi.pooq.com Thu Dec 3 00:30:09 2015 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Wed, 2 Dec 2015 18:30:09 -0500 Subject: [M3devel] addition of GPL stuff In-Reply-To: References: Message-ID: <20151202233009.GB19699@topoi.pooq.com> On Mon, Sep 14, 2015 at 06:14:52AM +0000, Jay K wrote: > Um, sorry to bring up such annoying matters, but maybe we should not be licensingnew files as GPL, assuming they aren't derived from GPL files? > e.g. the LLVM m3makfiles and Makefiles? > Thank you, - Jay To resurrect a post from ages gone by. We should be licencing everything GPL, assuming it's original, and not already constrained by SRC's license. If another license is appropriate, use that too. Make it dual licensed. Dual licencing works as possible: anyone gets to choose which of the licences they are going to use. So if your use is allowed by *any* of the listed licenses, it's OK. It's a way to achieve greater compatibility than could be obtained by any one of those licenses. In particular, the copyright owner (initially the author) could grant rights under both the GPL and the SRC licenses, to assure copatibility with both. THe LGPL might be better than GPL for freedom, and the MIT licence even better. Tht way, if ever a viable collection of Modula 3 code is licenced under GPL, that collection can be used with GPL code freely. -- hendrik > > > > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel From lists at darko.org Thu Dec 3 01:35:26 2015 From: lists at darko.org (Darko Volaric) Date: Wed, 2 Dec 2015 16:35:26 -0800 Subject: [M3devel] addition of GPL stuff In-Reply-To: <20151202233009.GB19699@topoi.pooq.com> References: <20151202233009.GB19699@topoi.pooq.com> Message-ID: What's the argument against placing contributions in the public domain? Licences are tedious. Even short ones require reading and understanding when you're using the code, and most people use many projects. Renouncing copyright is simple, flexible and no-one can copyright the work. Or am I missing some important legal wrinkle? Do contributors want to keep control of their code? On Wed, Dec 2, 2015 at 3:30 PM, Hendrik Boom wrote: > On Mon, Sep 14, 2015 at 06:14:52AM +0000, Jay K wrote: > > Um, sorry to bring up such annoying matters, but maybe we should not > be licensingnew files as GPL, assuming they aren't derived from GPL files? > > e.g. the LLVM m3makfiles and Makefiles? > > Thank you, - Jay > > To resurrect a post from ages gone by. > > We should be licencing everything GPL, assuming it's original, and not > already constrained by SRC's license. > > If another license is appropriate, use that too. Make it dual licensed. > Dual licencing works as possible: anyone gets to choose which of > the licences they are going to use. So if your use is allowed by *any* > of the listed licenses, it's OK. > > It's a way to achieve greater compatibility than could be obtained by > any one of those licenses. > > In particular, the copyright owner (initially the author) could grant > rights under both the GPL and the SRC licenses, to assure copatibility > with both. THe LGPL might be better than GPL for freedom, and the MIT > licence even better. > > Tht way, if ever a viable collection of Modula 3 code is licenced under > GPL, that collection can be used with GPL code freely. > > -- hendrik > > > > > > > > > > _______________________________________________ > > M3devel mailing list > > M3devel at elegosoft.com > > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel > > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Thu Dec 3 04:52:36 2015 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Wed, 2 Dec 2015 22:52:36 -0500 Subject: [M3devel] addition of GPL stuff In-Reply-To: References: <20151202233009.GB19699@topoi.pooq.com> Message-ID: <20151203035236.GA22525@topoi.pooq.com> On Wed, Dec 02, 2015 at 04:35:26PM -0800, Darko Volaric wrote: > What's the argument against placing contributions in the public domain? Public Domain would satisfy me adequately. If it were universal. However, there are partss of the world where public domain is not an accepted legal concept. That's why there is a creative Commons licence that is essentially equivalent to public domain. > Licences are tedious. Even short ones require reading and understanding > when you're using the code, and most people use many projects. > > Renouncing copyright is simple, flexible and no-one can copyright the work. Actually, they can as soon as they make changes. The original remains public, but they can claim rights over the modifications. > > Or am I missing some important legal wrinkle? Do contributors want to keep > control of their code? The legal wrinkle is that public domain is not everywhere recognised. I believe the Creative Commons website has something to say about this. --- hendrik > > On Wed, Dec 2, 2015 at 3:30 PM, Hendrik Boom wrote: > > > On Mon, Sep 14, 2015 at 06:14:52AM +0000, Jay K wrote: > > > Um, sorry to bring up such annoying matters, but maybe we should not > > be licensingnew files as GPL, assuming they aren't derived from GPL files? > > > e.g. the LLVM m3makfiles and Makefiles? > > > Thank you, - Jay > > > > To resurrect a post from ages gone by. > > > > We should be licencing everything GPL, assuming it's original, and not > > already constrained by SRC's license. > > > > If another license is appropriate, use that too. Make it dual licensed. > > Dual licencing works as possible: anyone gets to choose which of > > the licences they are going to use. So if your use is allowed by *any* > > of the listed licenses, it's OK. > > > > It's a way to achieve greater compatibility than could be obtained by > > any one of those licenses. > > > > In particular, the copyright owner (initially the author) could grant > > rights under both the GPL and the SRC licenses, to assure copatibility > > with both. THe LGPL might be better than GPL for freedom, and the MIT > > licence even better. > > > > Tht way, if ever a viable collection of Modula 3 code is licenced under > > GPL, that collection can be used with GPL code freely. > > > > -- hendrik > > > > > > > > > > > > > > > > _______________________________________________ > > > M3devel mailing list > > > M3devel at elegosoft.com > > > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel > > > > _______________________________________________ > > M3devel mailing list > > M3devel at elegosoft.com > > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel > > From microcode at zoho.com Thu Dec 3 08:36:11 2015 From: microcode at zoho.com (microcode at zoho.com) Date: Thu, 3 Dec 2015 07:36:11 +0000 Subject: [M3devel] addition of GPL stuff In-Reply-To: <20151202233009.GB19699@topoi.pooq.com> References: <20151202233009.GB19699@topoi.pooq.com> Message-ID: <20151203073611.GH3127@zoho.com> On Wed, Dec 02, 2015 at 06:30:09PM -0500, Hendrik Boom wrote: > On Mon, Sep 14, 2015 at 06:14:52AM +0000, Jay K wrote: > > Um, sorry to bring up such annoying matters, but maybe we should not > be licensingnew files as GPL, assuming they aren't derived from GPL files? > > e.g. the LLVM m3makfiles and Makefiles? > > Thank you, - Jay snip > Tht way, if ever a viable collection of Modula 3 code is licenced under > GPL, that collection can be used with GPL code freely. No. MIT and BSD licensed code can be used in any project. GPL poisons the product and is not compatible with free software licenses. I realize my opinion is irrelevant but I agree with Jay 1,000% on this. And it's an open mailing list, so... From hendrik at topoi.pooq.com Thu Dec 3 19:36:58 2015 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Thu, 3 Dec 2015 13:36:58 -0500 Subject: [M3devel] addition of GPL stuff In-Reply-To: <20151203073611.GH3127@zoho.com> References: <20151202233009.GB19699@topoi.pooq.com> <20151203073611.GH3127@zoho.com> Message-ID: <20151203183657.GA4527@topoi.pooq.com> On Thu, Dec 03, 2015 at 07:36:11AM +0000, microcode at zoho.com wrote: > On Wed, Dec 02, 2015 at 06:30:09PM -0500, Hendrik Boom wrote: > > On Mon, Sep 14, 2015 at 06:14:52AM +0000, Jay K wrote: > > > Um, sorry to bring up such annoying matters, but maybe we should not > > be licensingnew files as GPL, assuming they aren't derived from GPL files? > > > e.g. the LLVM m3makfiles and Makefiles? > > > Thank you, - Jay > > snip > > > Tht way, if ever a viable collection of Modula 3 code is licenced under > > GPL, that collection can be used with GPL code freely. > > No. MIT and BSD licensed code can be used in any project. GPL poisons the > product and is not compatible with free software licenses. Yes, MIT licence is good. And it doesn't conflict with the SRC licence, either so that should be good, too. And so is the BSD licence without the advertising clause. Apple went to town with this one when theyy build OS/X, so it's definitely nonrestrictive. > > I realize my opinion is irrelevant but I agree with Jay 1,000% on this. And > it's an open mailing list, so... > > > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel From jay.krell at cornell.edu Sat Dec 5 12:54:05 2015 From: jay.krell at cornell.edu (Jay K) Date: Sat, 5 Dec 2015 11:54:05 +0000 Subject: [M3devel] addition of GPL stuff In-Reply-To: <20151203183657.GA4527@topoi.pooq.com> References: , <20151202233009.GB19699@topoi.pooq.com>, <20151203073611.GH3127@zoho.com>, <20151203183657.GA4527@topoi.pooq.com> Message-ID: We shouldn't spend much time on this, but... The license that OpenBSD, NetBSD, FreeBSD use, that is what we should use. It is the same license. These are fairly large heavily used projects, and they copy code around amongst eachother, and commercial ventures fork and close the code, without attribution -- that is allowed. This is a license that lets anyone do just about anything, including take it as their own and profit. it is a short license.Shorter than this email. It does not require giving credit.Giving credit is nice, but exactly how/where/when? And how muchtime/energy must people spend to figure that out?The older BSD license required giving credit, and there was protest and the claused was dropped. it does not require giving back. Again, giving back is great, but requiring it is too much.What if someone wants to release something but we are all on vacation not answering email?They have to wait for us to respond to take their changes before they can ship them? The point of this license is to remove any barrier to reuse that is easy to remove.(ignoring quality and functionality of the code) One of the reasons OpenBSD rejects licenses is because more licenses requires more readingand possibly more lawyer time, more uncertainty, when there are already sufficient tried-and-truelicenses. I believe this is why they reject the Apache 2.0 license. What the GPL does is quite different. It basically makes you GPL anythingyou link the GPL code to. It maybe doesn't require giving back, or require giving credit,but it requires source be available to anyone that receives the binaries. You can sell the binaries,but you must do so including source (or a link to download the source).Most commercial ventures believe that this requirement makes it impossible to make money.You might get one sale, but then the source is out and anyone can duplicate the functionality.Others claim that "support" is an adequate business model. (If you are just sitting on the binaries all by yourself and don't give them to anyone, the GPL has no effect, youcan keep the source to yourself as well. People sometimes misunderstand this.) MIT license is probably about the same and probably second best. - Jay > Date: Thu, 3 Dec 2015 13:36:58 -0500 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] addition of GPL stuff > > On Thu, Dec 03, 2015 at 07:36:11AM +0000, microcode at zoho.com wrote: > > On Wed, Dec 02, 2015 at 06:30:09PM -0500, Hendrik Boom wrote: > > > On Mon, Sep 14, 2015 at 06:14:52AM +0000, Jay K wrote: > > > > Um, sorry to bring up such annoying matters, but maybe we should not > > > be licensingnew files as GPL, assuming they aren't derived from GPL files? > > > > e.g. the LLVM m3makfiles and Makefiles? > > > > Thank you, - Jay > > > > snip > > > > > Tht way, if ever a viable collection of Modula 3 code is licenced under > > > GPL, that collection can be used with GPL code freely. > > > > No. MIT and BSD licensed code can be used in any project. GPL poisons the > > product and is not compatible with free software licenses. > > Yes, MIT licence is good. And it doesn't conflict with the SRC > licence, either so that should be good, too. > > And so is the BSD licence without the advertising clause. > > Apple went to town with this one when theyy build OS/X, so it's > definitely nonrestrictive. > > > > > I realize my opinion is irrelevant but I agree with Jay 1,000% on this. And > > it's an open mailing list, so... > > > > > > _______________________________________________ > > M3devel mailing list > > M3devel at elegosoft.com > > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Sat Dec 5 23:15:20 2015 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sat, 5 Dec 2015 22:15:20 +0000 (UTC) Subject: [M3devel] addition of GPL stuff In-Reply-To: References: Message-ID: <1157844485.26117551.1449353720968.JavaMail.yahoo@mail.yahoo.com> Hey a little bit off topic, what about SRC reports, can we track down all the Green Book's (Systems programming with Modula-3) chapters and reformat them to make it public?I mean, I haven't seen anything of that quality in terms of intellectual strictness and so easy to read in any computer language book. Thanks in advance El S?bado 5 de diciembre de 2015 6:54, Jay K escribi?: #yiv5960026191 #yiv5960026191 --.yiv5960026191hmmessage P{margin:0px;padding:0px;}#yiv5960026191 body.yiv5960026191hmmessage{font-size:12pt;font-family:Calibri;}#yiv5960026191 We shouldn't spend much time on this, but... The license that OpenBSD, NetBSD, FreeBSD use, that is what we should use. It is the same license. These are fairly large heavily used projects, and they copy code around amongst eachother, and commercial ventures fork and close the code, without attribution -- that is allowed. This is a license that lets anyone do just about anything, including take it as their own and profit. it is a short license.Shorter than this email. It does not require giving credit.Giving credit is nice, but exactly how/where/when? And how muchtime/energy must people spend to figure that out?The older BSD license required giving credit, and there was protest and the claused was dropped. it does not require giving back. Again, giving back is great, but requiring it is too much.What if someone wants to release something but we are all on vacation not answering email?They have to wait for us to respond to take their changes before they can ship them? The point of this license is to remove any barrier to reuse that is easy to remove.(ignoring quality and functionality of the code) One of the reasons OpenBSD rejects licenses is because more licenses requires more readingand possibly more lawyer time, more uncertainty, when there are already sufficient tried-and-truelicenses. I believe this is why they reject the?Apache 2.0 license. What the GPL does is quite different. It basically makes you GPL anythingyou link the GPL code to. It maybe doesn't require giving back, or require giving credit,but it requires source be available to anyone that receives the binaries. You can sell the binaries,but you must do so including source (or a link to download the source).Most commercial ventures believe that this requirement makes it impossible to make money.You might get one sale, but then the source is out and anyone can duplicate the functionality.Others claim that "support" is an adequate business model. (If you are just sitting on the binaries all?by yourself and don't give them to anyone, the GPL has no effect, youcan keep the source to yourself as well.?People sometimes misunderstand this.) MIT license is probably about the same and probably second best. ?- Jay > Date: Thu, 3 Dec 2015 13:36:58 -0500 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] addition of GPL stuff > > On Thu, Dec 03, 2015 at 07:36:11AM +0000, microcode at zoho.com wrote: > > On Wed, Dec 02, 2015 at 06:30:09PM -0500, Hendrik Boom wrote: > > > On Mon, Sep 14, 2015 at 06:14:52AM +0000, Jay K wrote: > > > > Um, sorry to bring up such annoying matters, but maybe we should not > > > be licensingnew files as GPL, assuming they aren't derived from GPL files? > > > > e.g. the LLVM m3makfiles and Makefiles? > > > > Thank you, - Jay > > > > snip > > > > > Tht way, if ever a viable collection of Modula 3 code is licenced under > > > GPL, that collection can be used with GPL code freely. > > > > No. MIT and BSD licensed code can be used in any project. GPL poisons the > > product and is not compatible with free software licenses. > > Yes, MIT licence is good. And it doesn't conflict with the SRC > licence, either so that should be good, too. > > And so is the BSD licence without the advertising clause. > > Apple went to town with this one when theyy build OS/X, so it's > definitely nonrestrictive. > > > > > I realize my opinion is irrelevant but I agree with Jay 1,000% on this. And > > it's an open mailing list, so... > > > > > > _______________________________________________ > > M3devel mailing list > > M3devel at elegosoft.com > > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel _______________________________________________ M3devel mailing list M3devel at elegosoft.com https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Sun Dec 6 00:20:45 2015 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Sat, 5 Dec 2015 18:20:45 -0500 Subject: [M3devel] addition of GPL stuff In-Reply-To: <1157844485.26117551.1449353720968.JavaMail.yahoo@mail.yahoo.com> References: <1157844485.26117551.1449353720968.JavaMail.yahoo@mail.yahoo.com> Message-ID: <20151205232045.GA25815@topoi.pooq.com> On Sat, Dec 05, 2015 at 10:15:20PM +0000, Daniel Alejandro Benavides D. wrote: > Hey a little bit off topic, what about SRC reports, can we track down all the Green Book's (Systems programming with Modula-3) chapters and reformat them to make it public?I mean, I haven't seen anything of that quality in terms of intellectual strictness and so easy to read in any computer language book. > Thanks in advance Only the copyright holder can do that, unless it is in he public domain. -- hendrik From dabenavidesd at yahoo.es Sun Dec 6 00:47:56 2015 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sat, 5 Dec 2015 23:47:56 +0000 (UTC) Subject: [M3devel] addition of GPL stuff In-Reply-To: <20151205232045.GA25815@topoi.pooq.com> References: <20151205232045.GA25815@topoi.pooq.com> Message-ID: <1330494183.25980356.1449359276781.JavaMail.yahoo@mail.yahoo.com> Hello:I understand it can be a literally impossible to track down copyright holders as no Modula-3 sources are apart of any entity besides Elego (is this not a solution of the problem?). Respect of the RR, at some point in time, they start to be universally accessible (like 70 years) or so? Thanks in advance El S?bado 5 de diciembre de 2015 18:20, Hendrik Boom escribi?: On Sat, Dec 05, 2015 at 10:15:20PM +0000, Daniel Alejandro Benavides D. wrote: > Hey a little bit off topic, what about SRC reports, can we track down all the Green Book's (Systems programming with Modula-3) chapters and reformat them to make it public?I mean, I haven't seen anything of that quality in terms of intellectual strictness and so easy to read in any computer language book. > Thanks in advance Only the copyright holder can do that, unless it is in he public domain. -- hendrik _______________________________________________ M3devel mailing list M3devel at elegosoft.com https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sun Dec 6 01:07:40 2015 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 6 Dec 2015 01:07:40 +0100 Subject: [M3devel] addition of GPL stuff In-Reply-To: <1157844485.26117551.1449353720968.JavaMail.yahoo@mail.yahoo.com> References: <1157844485.26117551.1449353720968.JavaMail.yahoo@mail.yahoo.com> Message-ID: <20151206010740.a58ec527ca708a8dd33955f8@elegosoft.com> On Sat, 5 Dec 2015 22:15:20 +0000 (UTC) "Daniel Alejandro Benavides D." wrote: > Hey a little bit off topic, what about SRC reports, can we track down all the Green Book's (Systems programming with Modula-3) chapters and reformat them to make it public?I mean, I haven't seen anything of that quality in terms of intellectual strictness and so easy to read in any computer language book. The complete language definition, which is one part of the Green Book, is already online: http://www.opencm3.net/doc/reference/complete/html/Modula_3_Language_definitio.html Also a complete description of all the available interfaces http://www.opencm3.net/doc/help/interfaces.html and the quake reference: http://www.opencm3.net/doc/help/cm3/quake.html Alas, I haven't found an active site for some time that actually servers the SRC reports; they're not in the HP archive and gatekeeper seems to be gone forever. If anybody knows where to download them, I would appreciate a hint. 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 dabenavidesd at yahoo.es Sun Dec 6 01:28:34 2015 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sun, 6 Dec 2015 00:28:34 +0000 (UTC) Subject: [M3devel] addition of GPL stuff In-Reply-To: <20151206010740.a58ec527ca708a8dd33955f8@elegosoft.com> References: <20151206010740.a58ec527ca708a8dd33955f8@elegosoft.com> Message-ID: <1636697213.26135778.1449361714400.JavaMail.yahoo@mail.yahoo.com> Hi:yeah they are here:http://www.mirrorservice.org/sites/www.bitsavers.org/pdf/dec/tech_reports/ But unintendedly found Network Systems Laboratory ones: https://archive.org/stream/bitsavers_dectechrep_48346/NSL-NN-11_djvu.txt Thanks for point out this and in advance | ? | | ? | | ? | ? | ? | ? | ? | | Index of /sites/www.bitsavers.org/pdf/dec/tech_reportsIndex of /sites/www.bitsavers.org/pdf/dec/tech_reports/ Name Last modified Size | | | | Ver en www.mirrorservice.org | Vista previa por Yahoo | | | | ? | El S?bado 5 de diciembre de 2015 19:07, Olaf Wagner escribi?: On Sat, 5 Dec 2015 22:15:20 +0000 (UTC) "Daniel Alejandro Benavides D." wrote: > Hey a little bit off topic, what about SRC reports, can we track down all the Green Book's (Systems programming with Modula-3) chapters and reformat them to make it public?I mean, I haven't seen anything of that quality in terms of intellectual strictness and so easy to read in any computer language book. The complete language definition, which is one part of the Green Book, is already online: http://www.opencm3.net/doc/reference/complete/html/Modula_3_Language_definitio.html Also a complete description of all the available interfaces http://www.opencm3.net/doc/help/interfaces.html and the quake reference: http://www.opencm3.net/doc/help/cm3/quake.html Alas, I haven't found an active site for some time that actually servers the SRC reports; they're not in the HP archive and gatekeeper seems to be gone forever. If anybody knows where to download them, I would appreciate a hint. 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 Thu Dec 10 19:15:48 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 10 Dec 2015 12:15:48 -0600 Subject: [M3devel] M3CG loophole operator is not LOOPHOLE (but what?) Message-ID: <5669C154.90603@lcwb.coop> I have just discovered the hard way that the following comment, from M3CG_Ops.i3: loophole (from, two: ZType); (* s0.two := LOOPHOLE(s0.from, two) *) is not true. The front end can produce M3CG loophole ops in which the two types do not have the same size. For example, the front end passes a small exception argument to RaiseEx by value as CGType.Addr, whose size is native word size, and if the argument has a different stack size (e.g. REAL is 32-bit, even on a native 64-bit machine), then it first converts it using the M3CG loophole operator. Almost the same thing can happen for an explicit LOOPHOLE in M3 source code. On a 64-bit machine, compiling libm3/src/geometry/Transform.m3, M3 source code equivalent to: LOOPHOLE (REALvariable, BITS BITSIZE(REAL) FOR [-16_7fffffff-1 .. 16_7fffffff]) (translated by CastExpr.m3:286) produces almost the same M3CG loophole operator, because the stack size of the subrange is 64-bit, even though its memory size is 32. So the loophole comes out converting REAL to Int64. (Note that BITS has no effect, since the type is not used as a field or array element). Since loophole takes its operand off the abstract stack and puts its result back there, the stack size is the right one to use here, for both from-type and to-type. But what are the complete rules about loophole? Apparently some combinations really are bitcasts, but which ones? Exactly those where the sizes match? What is the actual conversion for other combinations? 32-bit REAL to 64-bit integer or address is particularly unclear. If anybody has any knowledge about this, it would be helpful. There is quite a bit of code to vet, otherwise. 15 different places in the front end generate loophole. -- Rodney Bates rodney.m.bates at acm.org From jay.krell at cornell.edu Fri Dec 11 07:53:08 2015 From: jay.krell at cornell.edu (Jay K) Date: Fri, 11 Dec 2015 06:53:08 +0000 Subject: [M3devel] M3CG loophole operator is not LOOPHOLE (but what?) In-Reply-To: <5669C154.90603@lcwb.coop> References: <5669C154.90603@lcwb.coop> Message-ID: I don't recall...but it doesn't look like M3C handles this specially,but indeed m3cc has special logic for loophole and floats. Ugh.It makes a temporary. I'll have to experiment. The right thing to do, really, is take the address of a float, loopholethat into an address of another type, and dereference that.Not in the backend, but in the Modula-3 code. Never to loophole to or from a float value.And hardly ever loophole values at all.Loopholing between pointers and same-sized integers, ok.Or pointers and other pointers, ok. I don't know if it called loophole, but between varying sized/signedness integers also ok.(really that is chop or extend) We should considering changing m3front to honor these rules.That is how you write semi-portable C to dissect floats.Or via unions. There are intrinsics in some compilers for doing better.Visual C++ for non-x86 platforsm (ARM and CE) has it right, with stuff like_CopyDoubleToInt64, _CopyInt64ToDouble, _CopyInt32ToFloat, CopyFloatToInt32.You can argue the names, but really those are the exact 4 intrinsics you want.Leaving it to the compiler to know if it can do a register move or must go through memory.But the portable way requires going through memory. And, really, put all the float dissection into C anyway. - Jay > Date: Thu, 10 Dec 2015 12:15:48 -0600 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: [M3devel] M3CG loophole operator is not LOOPHOLE (but what?) > > I have just discovered the hard way that the following comment, from M3CG_Ops.i3: > > loophole (from, two: ZType); > (* s0.two := LOOPHOLE(s0.from, two) *) > > is not true. > > The front end can produce M3CG loophole ops in which the two types do not have > the same size. For example, the front end passes a small exception argument > to RaiseEx by value as CGType.Addr, whose size is native word size, and if > the argument has a different stack size (e.g. REAL is 32-bit, even on a native > 64-bit machine), then it first converts it using the M3CG loophole operator. > > Almost the same thing can happen for an explicit LOOPHOLE in M3 source code. On a > 64-bit machine, compiling libm3/src/geometry/Transform.m3, M3 source code > equivalent to: > > LOOPHOLE (REALvariable, BITS BITSIZE(REAL) FOR [-16_7fffffff-1 .. 16_7fffffff]) > > (translated by CastExpr.m3:286) produces almost the same M3CG loophole operator, > because the stack size of the subrange is 64-bit, even though its memory size is > 32. So the loophole comes out converting REAL to Int64. (Note that BITS has no > effect, since the type is not used as a field or array element). > > Since loophole takes its operand off the abstract stack and puts its result back > there, the stack size is the right one to use here, for both from-type and to-type. > > But what are the complete rules about loophole? Apparently some combinations > really are bitcasts, but which ones? Exactly those where the sizes match? What > is the actual conversion for other combinations? 32-bit REAL to 64-bit integer > or address is particularly unclear. > > If anybody has any knowledge about this, it would be helpful. There is quite a > bit of code to vet, otherwise. 15 different places in the front end generate > loophole. > > -- > Rodney Bates > rodney.m.bates at acm.org > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 14 03:20:55 2015 From: jay.krell at cornell.edu (Jay) Date: Sun, 13 Dec 2015 18:20:55 -0800 Subject: [M3devel] M3CG loophole operator is not LOOPHOLE (but what?) In-Reply-To: References: <5669C154.90603@lcwb.coop> Message-ID: I know, but this pattern is pretty rare. - Jay On Dec 13, 2015, at 1:46 AM, Antony Hosking wrote: > Excepting that in some cases taking the address may force the value into memory, when it could have stayed in a register. > The intent is to allow the backend to avoid that. > >> On 11 Dec 2015, at 5:53 PM, Jay K wrote: >> >> The right thing to do, really, is take the address of a float, loophole >> that into an address of another type, and dereference that. >> Not in the backend, but in the Modula-3 code. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Mon Dec 14 03:40:46 2015 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Mon, 14 Dec 2015 02:40:46 +0000 (UTC) Subject: [M3devel] M3CG loophole operator is not LOOPHOLE (but what?) In-Reply-To: References: <5669C154.90603@lcwb.coop> Message-ID: <1615931268.1036686.1450060846633.JavaMail.yahoo@mail.yahoo.com> Hello:Excuse me if is wrong to say, but doesn't the specification of Modula-3 explicit about how the UNSAFE stuff is implementation-dependent, that is to say; "it's your decision how to implement it".Thanks in advance El Domingo 13 de diciembre de 2015 21:20, Jay escribi?: I know, but this pattern is pretty rare.? ?- Jay On Dec 13, 2015, at 1:46 AM, Antony Hosking wrote: Excepting that in some cases taking the address may force the value into memory, when it could have stayed in a register.The intent is to allow the backend to avoid that. On 11 Dec 2015, at 5:53 PM, Jay K wrote: The right thing to do, really, is take the address of a float, loopholethat into an address of another type, and dereference that.Not in the backend, but in the Modula-3 code. _______________________________________________ M3devel mailing list M3devel at elegosoft.com https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Mon Dec 14 04:05:18 2015 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Mon, 14 Dec 2015 03:05:18 +0000 (UTC) Subject: [M3devel] M3CG loophole operator is not LOOPHOLE (but what?) In-Reply-To: <300C917B-B104-469E-8885-99CC5D1D964F@purdue.edu> References: <5669C154.90603@lcwb.coop> <1615931268.1036686.1450060846633.JavaMail.yahoo@mail.yahoo.com> <300C917B-B104-469E-8885-99CC5D1D964F@purdue.edu> Message-ID: <832820227.1031770.1450062318650.JavaMail.yahoo@mail.yahoo.com> Hi:exactly, if the bit pattern is unequal in two implementations, surely you will be having 2 different results El Domingo 13 de diciembre de 2015 21:51, "Hosking, Antony L" escribi?: From the language definition: An?unchecked type transfer operation has the form: ? ? LOOPHOLE(e, T) where?e?is an expression whose type is not an open array type and?T?is a type. It denotes?e's bit pattern?interpreted as a variable or value of type?T. It is a designator if?e?is, and is writable if?e?is. An unchecked?runtime error can occur if?e's bit pattern is not a legal?T, or if?e?is a designator and some legal bit pattern for?T?is not legal for?e. If?T?is not an open array type,?BITSIZE(e)?must equal?BITSIZE(T). If?T?is an open array type, its element type must not be an open array?type, and?e's bit pattern is interpreted as an array whose length is?BITSIZE(e)?divided by?BITSIZE(the element type of?T). The division?must come out even. On 14 Dec 2015, at 1:40 PM, Daniel Alejandro Benavides D. wrote: Hello: Excuse me if is wrong to say, but doesn't the specification of Modula-3 explicit about how the?UNSAFE stuff is implementation-dependent, that is to say; "it's your decision how to implement?it". Thanks in advance El Domingo 13 de diciembre de 2015 21:20, Jay escribi?: I know, but this pattern is pretty rare.? ?- Jay On Dec 13, 2015, at 1:46 AM, Antony Hosking wrote: Excepting that in some cases taking the address may force the value into memory, when it?could have stayed in a register. The intent is to allow the backend to avoid that. On 11 Dec 2015, at 5:53 PM, Jay K wrote: The right thing to do, really, is take the address of a float, loophole that into an address of another type, and dereference that. Not in the backend, but in the Modula-3 code. _______________________________________________ M3devel mailing list M3devel at elegosoft.com https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Mon Dec 14 04:19:32 2015 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Mon, 14 Dec 2015 03:19:32 +0000 (UTC) Subject: [M3devel] M3CG loophole operator is not LOOPHOLE (but what?) In-Reply-To: References: <5669C154.90603@lcwb.coop> <1615931268.1036686.1450060846633.JavaMail.yahoo@mail.yahoo.com> <300C917B-B104-469E-8885-99CC5D1D964F@purdue.edu> <832820227.1031770.1450062318650.JavaMail.yahoo@mail.yahoo.com> Message-ID: <2041142346.1036456.1450063172587.JavaMail.yahoo@mail.yahoo.com> Hi:but isn't the bit pattern, the data layout, what it makes the difference Anthony? Thanks in advance El Domingo 13 de diciembre de 2015 22:14, "Hosking, Antony L" escribi?: Bits are bits. ?It is implementation-dependent because bits one machine will be different on another. ?My point was that the bit sizes are expected to be the same (except when T is an open array, in which case the bits form the payload of the open array, with the size constructed accordingly). On 14 Dec 2015, at 2:05 PM, Daniel Alejandro Benavides D. wrote: Hi:exactly, if the bit pattern is unequal in two implementations, surely you will be having 2 different results El Domingo 13 de diciembre de 2015 21:51, "Hosking, Antony L" escribi?: >From the language definition: An?unchecked type transfer operation has the form: ? ? LOOPHOLE(e, T) where?e?is an expression whose type is not an open array type and?T?is a type. It denotes?e's bit pattern?interpreted as a variable or value of type?T. It is a designator if?e?is, and is writable if?e?is. An unchecked?runtime error can occur if?e's bit pattern is not a legal?T, or if?e?is a designator and some legal bit pattern for?T?is not legal for?e. If?T?is not an open array type,?BITSIZE(e)?must equal?BITSIZE(T). If?T?is an open array type, its element type must not be an open array?type, and?e's bit pattern is interpreted as an array whose length is?BITSIZE(e)?divided by?BITSIZE(the element type of?T). The division?must come out even. On 14 Dec 2015, at 1:40 PM, Daniel Alejandro Benavides D. wrote: Hello: Excuse me if is wrong to say, but doesn't the specification of Modula-3 explicit about how the?UNSAFE stuff is implementation-dependent, that is to say; "it's your decision how to implement?it". Thanks in advance El Domingo 13 de diciembre de 2015 21:20, Jay escribi?: I know, but this pattern is pretty rare.? ?- Jay On Dec 13, 2015, at 1:46 AM, Antony Hosking wrote: Excepting that in some cases taking the address may force the value into memory, when it?could have stayed in a register. The intent is to allow the backend to avoid that. On 11 Dec 2015, at 5:53 PM, Jay K wrote: The right thing to do, really, is take the address of a float, loophole that into an address of another type, and dereference that. Not in the backend, but in the Modula-3 code. _______________________________________________ M3devel mailing list M3devel at elegosoft.com https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Mon Dec 14 04:30:47 2015 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Mon, 14 Dec 2015 03:30:47 +0000 (UTC) Subject: [M3devel] M3CG loophole operator is not LOOPHOLE (but what?) In-Reply-To: <2041142346.1036456.1450063172587.JavaMail.yahoo@mail.yahoo.com> References: <5669C154.90603@lcwb.coop> <1615931268.1036686.1450060846633.JavaMail.yahoo@mail.yahoo.com> <300C917B-B104-469E-8885-99CC5D1D964F@purdue.edu> <832820227.1031770.1450062318650.JavaMail.yahoo@mail.yahoo.com> <2041142346.1036456.1450063172587.JavaMail.yahoo@mail.yahoo.com> Message-ID: <1714007729.1032434.1450063847030.JavaMail.yahoo@mail.yahoo.com> Hi:You know m3middle uses unsafe stuff, probably as Rodney points out m3front too, it doesn't have the correct implementation (as in m3middle) because it worked in another architecture, but not in here. That's why these modules need different treatment to care after release new versions.Thanks in advance El Domingo 13 de diciembre de 2015 22:19, Daniel Alejandro Benavides D. escribi?: Hi:but isn't the bit pattern, the data layout, what it makes the difference Anthony? Thanks in advance El Domingo 13 de diciembre de 2015 22:14, "Hosking, Antony L" escribi?: Bits are bits. ?It is implementation-dependent because bits one machine will be different on another. ?My point was that the bit sizes are expected to be the same (except when T is an open array, in which case the bits form the payload of the open array, with the size constructed accordingly). On 14 Dec 2015, at 2:05 PM, Daniel Alejandro Benavides D. wrote: Hi:exactly, if the bit pattern is unequal in two implementations, surely you will be having 2 different results El Domingo 13 de diciembre de 2015 21:51, "Hosking, Antony L" escribi?: >From the language definition: An?unchecked type transfer operation has the form: ? ? LOOPHOLE(e, T) where?e?is an expression whose type is not an open array type and?T?is a type. It denotes?e's bit pattern?interpreted as a variable or value of type?T. It is a designator if?e?is, and is writable if?e?is. An unchecked?runtime error can occur if?e's bit pattern is not a legal?T, or if?e?is a designator and some legal bit pattern for?T?is not legal for?e. If?T?is not an open array type,?BITSIZE(e)?must equal?BITSIZE(T). If?T?is an open array type, its element type must not be an open array?type, and?e's bit pattern is interpreted as an array whose length is?BITSIZE(e)?divided by?BITSIZE(the element type of?T). The division?must come out even. On 14 Dec 2015, at 1:40 PM, Daniel Alejandro Benavides D. wrote: Hello: Excuse me if is wrong to say, but doesn't the specification of Modula-3 explicit about how the?UNSAFE stuff is implementation-dependent, that is to say; "it's your decision how to implement?it". Thanks in advance El Domingo 13 de diciembre de 2015 21:20, Jay escribi?: I know, but this pattern is pretty rare.? ?- Jay On Dec 13, 2015, at 1:46 AM, Antony Hosking wrote: Excepting that in some cases taking the address may force the value into memory, when it?could have stayed in a register. The intent is to allow the backend to avoid that. On 11 Dec 2015, at 5:53 PM, Jay K wrote: The right thing to do, really, is take the address of a float, loophole that into an address of another type, and dereference that. Not in the backend, but in the Modula-3 code. _______________________________________________ M3devel mailing list M3devel at elegosoft.com https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel _______________________________________________ M3devel mailing list M3devel at elegosoft.com https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Mon Dec 14 14:30:58 2015 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Mon, 14 Dec 2015 13:30:58 +0000 (UTC) Subject: [M3devel] M3CG loophole operator is not LOOPHOLE (but what?) In-Reply-To: References: <5669C154.90603@lcwb.coop> <1615931268.1036686.1450060846633.JavaMail.yahoo@mail.yahoo.com> <300C917B-B104-469E-8885-99CC5D1D964F@purdue.edu> <832820227.1031770.1450062318650.JavaMail.yahoo@mail.yahoo.com> <2041142346.1036456.1450063172587.JavaMail.yahoo@mail.yahoo.com> <1714007729.1032434.1450063847030.JavaMail.yahoo@mail.yahoo.com> Message-ID: <554364982.1425193.1450099858596.JavaMail.yahoo@mail.yahoo.com> Hi:the difference between two types isn't bitsize, but structure or brand. Similarly, the cast between to types is possible by its bitpattern not by its bitsize. The implementation has the authority to adjust their sizes I believe (because it's implementation dependent). Antony m3devel isn't getting your mails in December archive, and here I have been struggling to read it -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at darko.org Wed Dec 16 16:47:49 2015 From: lists at darko.org (Darko Volaric) Date: Wed, 16 Dec 2015 16:47:49 +0100 Subject: [M3devel] Missing GitHub commits in M3commit Message-ID: It seems that Peter's commits on GitHub are not showing up in the commit list. I'm guessing that this is due to the "send from author" option on GitHub plus Peter's GitHub email not being the one subscribed to the list. Can we change it so that the "send from author option" is disabled and subscribe the GitHub notification email address to the list? This would save potentially having to fix this problem for each contributor. - Darko -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Wed Dec 16 19:01:27 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Wed, 16 Dec 2015 12:01:27 -0600 Subject: [M3devel] M3CG loophole operator is not LOOPHOLE (but what?) In-Reply-To: <1615931268.1036686.1450060846633.JavaMail.yahoo@mail.yahoo.com> References: <5669C154.90603@lcwb.coop> <1615931268.1036686.1450060846633.JavaMail.yahoo@mail.yahoo.com> Message-ID: <5671A6F7.6040805@lcwb.coop> The issue I raised is not with the M3 LOOPHOLE builtin function. The compiler currently implements it correctly, according to the language definition, as Tony quoted. The front end verifies the size equality, as required by the language, then emits an intermediate "loophole" operator, which will be same size, and thus well-defined as equivalent to LOOPHOLE. (And also llvm bitcast, which is now being used to translate the loophole operator in this case.) My issue is that there are 13 other places the front-end emits an internally generated "loophole", and these (almost?) all can do so with unequal sizes. Moreover, what should be done with the unequal sizes varies from place to place. It is possible that the "loophole" operator can be defined to do what is correct in every case by a conditional rule based on the two types. I need to do another pass through them to be sure. This may be the quickest way to get the llvm backend working, but I think it is not good design. It would be carefully tailored to just a specific set of uses of "loophole", instead of making a reasonable abstraction out of" loophole". It would be rather fragile and involve a lot of analysis on the full Cartesian product of both supplier and client side cases of "loophole" to define and verify. The best way, IMO, is to fix each "loophole"-generating site to use other operators, as appropriate. It is at these sites that it is known what should be done in each case. I suspect existing intermediate operators "widen", "insert_mn" and "extract_mn" are sufficient. Again, another pass through the cases is indicated. The only pragmatic drawback to this is that this requires considerable care and retesting to avoid breakage of existing behavior. At worst, it risks inability to bootstrap the compiler. I would prefer one change at a time, each tested by reboostrapping twice. On 12/13/2015 08:40 PM, Daniel Alejandro Benavides D. wrote: > Hello: > Excuse me if is wrong to say, but doesn't the specification of Modula-3 explicit about how the UNSAFE stuff is implementation-dependent, that is to say; "it's your decision how to implement it". > Thanks in advance > > > > El Domingo 13 de diciembre de 2015 21:20, Jay escribi?: > > > I know, but this pattern is pretty rare. > > - Jay > > On Dec 13, 2015, at 1:46 AM, Antony Hosking > wrote: > >> Excepting that in some cases taking the address may force the value into memory, when it could have stayed in a register. >> The intent is to allow the backend to avoid that. >> >>> On 11 Dec 2015, at 5:53 PM, Jay K > wrote: >>> >>> The right thing to do, really, is take the address of a float, loophole >>> that into an address of another type, and dereference that. >>> Not in the backend, but in the Modula-3 code. >>> >> > > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel > > > > > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel > -- Rodney Bates rodney.m.bates at acm.org From lists at darko.org Thu Dec 17 08:55:19 2015 From: lists at darko.org (Darko Volaric) Date: Thu, 17 Dec 2015 08:55:19 +0100 Subject: [M3devel] Missing GitHub commits in M3commit In-Reply-To: References: Message-ID: If there are no objections in the next few days, I'll make the required changes. On Wed, Dec 16, 2015 at 4:47 PM, Darko Volaric wrote: > It seems that Peter's commits on GitHub are not showing up in the commit > list. I'm guessing that this is due to the "send from author" option on > GitHub plus Peter's GitHub email not being the one subscribed to the list. > > Can we change it so that the "send from author option" is disabled and > subscribe the GitHub notification email address to the list? This would > save potentially having to fix this problem for each contributor. > > - Darko > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Mon Dec 21 04:18:17 2015 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Mon, 21 Dec 2015 03:18:17 +0000 (UTC) Subject: [M3devel] M3CG loophole operator is not LOOPHOLE (but what?) In-Reply-To: <5671A6F7.6040805@lcwb.coop> References: <5669C154.90603@lcwb.coop> <1615931268.1036686.1450060846633.JavaMail.yahoo@mail.yahoo.com> <5671A6F7.6040805@lcwb.coop> Message-ID: <297203610.2445107.1450667897642.JavaMail.yahoo@mail.yahoo.com> Hi all: I don't like to repeat nor answer myself, but for the benefit of the discussion lets put it as in the below comment UNSAFE LOOPHOLE alternative VIEW in SPIN OS [1]:A couple of years later, there was an OS project - called, I think, SPIN - that built the entire OS in Modula-3. They used only a tiny amount of UNSAFE code. One area that's often full of bit-twiddling and type munging is network code, where you somehow need to convert a bag-of-bytes into some typed object. The SPIN team added an interesting primitive: "Here's a bag-of-bytes with the same size as an object of type X. View it as an object of type X." This was legal only if every field in X, recursively, had a type for which any bit pattern was legal. (I'd guess - but don't know - that you could have enum type values, with the compiler inserting a check that what was in the buffer as a enumerated value was actually legal. It may have done this for some other types as well - e.g., there was a CARDINAL type which was a subset of INTEGER and consisted only of the non-negative values.)Which inadvertently is the Modula-3 language definition but downsized in terms of UNSAFE operations for normal safety, which only lefts pointer arithmetic and DISPOSE memory management for UNSAFE operations. Now, I wonder given that this is allowed to be safe in SPIN, what is the "UNSAFE" part of casting in Modula-3.I Do rememeber viewing a videotape lecture of James Donahue, and speakign of UNSAFE operations, he said that they were very careful in selecting that as UNSAFE and the other operations. [1][En l?nea]. Disponible en: https://www.marc.info/?l=cryptography&m=139784275512662&q=raw. [Accedido: 21-dic-2015]. Thanks in advance El Mi?rcoles 16 de diciembre de 2015 13:02, Rodney M. Bates escribi?: The issue I raised is not with the M3 LOOPHOLE builtin function.? The compiler currently implements it correctly, according to the language definition, as Tony quoted.? The front end verifies the size equality, as required by the language, then emits an intermediate "loophole" operator, which will be same size, and thus well-defined as equivalent to LOOPHOLE.? (And also llvm bitcast, which is now being used to translate the loophole operator in this case.) My issue is that there are 13 other places the front-end emits an internally generated "loophole", and these (almost?) all can do so with unequal sizes. Moreover, what should be done with the unequal sizes varies from place to place. It is possible that the "loophole" operator can be defined to do what is correct in every case by a conditional rule based on the two types.? I need to do another pass through them to be sure.? This may be the quickest way to get the llvm backend working, but I think it is not good design. It would be carefully tailored to just a specific set of uses of "loophole", instead of making a reasonable abstraction out of" loophole".? It would be rather fragile and involve a lot of analysis on the full Cartesian product of both supplier and client side cases of "loophole" to define and verify. The best way, IMO, is to fix each "loophole"-generating site to use other operators, as appropriate.? It is at these sites that it is known what should be done in each case.? I suspect existing intermediate operators "widen", "insert_mn" and "extract_mn" are sufficient.? Again, another pass through the cases is indicated.? The only pragmatic drawback to this is that this requires considerable care and retesting to avoid breakage of existing behavior.? At worst, it risks inability to bootstrap the compiler. I would prefer one change at a time, each tested by reboostrapping twice. On 12/13/2015 08:40 PM, Daniel Alejandro Benavides D. wrote: > Hello: > Excuse me if is wrong to say, but doesn't the specification of Modula-3 explicit about how the UNSAFE stuff is implementation-dependent, that is to say; "it's your decision how to implement it". > Thanks in advance > > > > El Domingo 13 de diciembre de 2015 21:20, Jay escribi?: > > > I know, but this pattern is pretty rare. > >? - Jay > > On Dec 13, 2015, at 1:46 AM, Antony Hosking > wrote: > >> Excepting that in some cases taking the address may force the value into memory, when it could have stayed in a register. >> The intent is to allow the backend to avoid that. >> >>> On 11 Dec 2015, at 5:53 PM, Jay K > wrote: >>> >>> The right thing to do, really, is take the address of a float, loophole >>> that into an address of another type, and dereference that. >>> Not in the backend, but in the Modula-3 code. >>> >> > > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel > > > > > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel > -- Rodney Bates rodney.m.bates at acm.org _______________________________________________ M3devel mailing list M3devel at elegosoft.com https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Dec 27 18:42:52 2015 From: jay.krell at cornell.edu (Jay K) Date: Sun, 27 Dec 2015 17:42:52 +0000 Subject: [M3devel] binary distribution incompatibility with very old C runtime Message-ID: For the record.. If you try to build the current source with the 5.8.6 release.. or rather, if you try to do anything with 5.8.6, and have a particularly old C/C++ toolset, like over 10 years old, on Windows, you get: m3core.lib.sa(ThreadWin32C.obj) : error LNK2019: unresolved external symbol __wassert referenced in function _ThreadWin32__ProcessStopped m3core.lib.sa(dtoa.obj) : error LNK2019: unresolved external symbol __ftol2_sse referenced in function _m3_strtod The C compiler and runtime change a surprising much through the years. Merely using assert or floating point to integer converson via casting, with a new compiler, does not work with older runtimes. We can do better such as either: 1) Generate all C, so the binary distribution matters less. 2) This is using static linking of m3core for bootstrapping. Deliberately not just because cm3 always does that, but also as a policy for supposed higher/easier compatibility with older releases. Perhaps that is a mistake. For today I'll just install a newer compiler. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Dec 29 07:55:13 2015 From: jay.krell at cornell.edu (Jay K) Date: Tue, 29 Dec 2015 06:55:13 +0000 Subject: [M3devel] NT386 and alloca/jmpbuf change Message-ID: fyi, it looks like I didn't finish the NT386 side of this. I'm working on it "now". - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Dec 30 11:07:00 2015 From: jay.krell at cornell.edu (Jay K) Date: Wed, 30 Dec 2015 10:07:00 +0000 Subject: [M3devel] Add support for real time threads breaks on Mac In-Reply-To: References: , Message-ID: https://github.com/modula3/cm3/commit/af5b2314a8a7ea76d04dbedcb51dee56ab347c51 Add support for real time threads Fails to compile for me on MacOSX. Can we undo it? Or #ifndef __APPLE__ out some parts? ../src/thread/PTHREAD/ThreadPThreadC.c:711:58: error: unknown type name 'cpu_set_t' ThreadPThread__add_core_to_cpuset(int core_id, int size, cpu_set_t *cpuset) Maybe can be implemented using Apple-specific code? What systems does it work on? I'll go off and read.. Thank you, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Dec 30 11:12:50 2015 From: jay.krell at cornell.edu (Jay K) Date: Wed, 30 Dec 2015 10:12:50 +0000 Subject: [M3devel] Add support for real time threads breaks on Mac In-Reply-To: References: , , , Message-ID: I suspect this only works on Linux and will fail on everything else: MacOSX, NetBSD, FreeBSD, OpenBSD, Solaris, Cygwin, Interix and the hypothetical AIX, Irix, HP-UX, VMS, etc. ?- Jay ________________________________ > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com; peter.mckinna at gmail.com > Date: Wed, 30 Dec 2015 10:07:00 +0000 > Subject: [M3devel] Add support for real time threads breaks on Mac > > https://github.com/modula3/cm3/commit/af5b2314a8a7ea76d04dbedcb51dee56ab347c51 > Add support for real time threads Fails to compile for me on MacOSX. > Can we undo it? Or #ifndef __APPLE__ out some parts? > ../src/thread/PTHREAD/ThreadPThreadC.c:711:58: error: unknown type name > 'cpu_set_t' ThreadPThread__add_core_to_cpuset(int core_id, int size, > cpu_set_t *cpuset) Maybe can be implemented using Apple-specific code? > What systems does it work on? I'll go off and read.. Thank you, - Jay > > _______________________________________________ M3devel mailing list > M3devel at elegosoft.com > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel From rodney_bates at lcwb.coop Tue Dec 1 21:17:00 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Tue, 01 Dec 2015 14:17:00 -0600 Subject: [M3devel] [M3commit] [modula3/cm3] b3c18e: Rework indirect calls to possibly nested procedure... In-Reply-To: References: <565cb8dc1ef05_532e3fd1219432c01066b@hookshot-fe5-cp1-prd.iad.github.net.mail> Message-ID: <565E003C.60104@lcwb.coop> Yeah, I would like some changes to the IR too. But it is fairly painful. Many places need to be changed, and I recall some kind of rebuild/bootstrap problem too. I am collecting a list of things I would like, with the idea of doing it all in one change. Some of my wishes predate my writing them down, and I hope I can remember them too. Some of them are motivated by debug information. On 12/01/2015 01:41 PM, Jay wrote: > I suggest one or two changes to the IR. > > > 1. An "official" in-memory representation of a complete unit or program. Modern systems can afford it. > > > 2. More information with function calls. Likely combining parameters with calls. No more start/end. All parameters must be locals (possibly uplevel) or parameters or globals or temporaries, never expressions. This is likely the case already. > > > And, aside, look what I do for C. I made it work somehow. I don't remember off hand but I did odd stuff also because of static links. Like maybe always passing one, even if null, as last parameter, because extra parameters are always allowed in C. I declare the function pointers with "..." (slightly different in C vs. C++). > > > The gcc backend passes static link in a register dedicated to it. > > - Jay > > On Nov 30, 2015, at 2:00 PM, Rodney Bates wrote: > >> Moreover, CM3's seemingly nice idea of making IR operators >> method calls makes it very awkward to do idiom recognition or >> state-dependent handling of general-purpose operators. > _______________________________________________ > M3commit mailing list > M3commit at elegosoft.com > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3commit > -- Rodney Bates rodney.m.bates at acm.org From jay.krell at cornell.edu Wed Dec 2 05:03:48 2015 From: jay.krell at cornell.edu (Jay) Date: Tue, 1 Dec 2015 21:03:48 -0700 Subject: [M3devel] [M3commit] [modula3/cm3] b3c18e: Rework indirect calls to possibly nested procedure... In-Reply-To: <565E003C.60104@lcwb.coop> References: <565cb8dc1ef05_532e3fd1219432c01066b@hookshot-fe5-cp1-prd.iad.github.net.mail> <565E003C.60104@lcwb.coop> Message-ID: <33C83013-53BA-47D1-A878-A7B81A9D23AD@gmail.com> Feel free to checkin a wishlist/todo. I feel that I have been through a fair amount & that most of the obstacles to change are actually imaginary. & most of the "difficulties" are "equivalent". That is, the build order and scripts are what they should be, & accommodate all concievable changes. IF the compiler depends on new language/runtime features then they must be first implemented, build it all, then depend on it. But this probably doesn't apply here. - Jay On Dec 1, 2015, at 1:17 PM, "Rodney M. Bates" wrote: > Yeah, I would like some changes to the IR too. But it is fairly painful. > Many places need to be changed, and I recall some kind of rebuild/bootstrap > problem too. I am collecting a list of things I would like, with the idea > of doing it all in one change. Some of my wishes predate my writing them > down, and I hope I can remember them too. Some of them are motivated by > debug information. > > On 12/01/2015 01:41 PM, Jay wrote: >> I suggest one or two changes to the IR. >> >> >> 1. An "official" in-memory representation of a complete unit or program. Modern systems can afford it. >> >> >> 2. More information with function calls. Likely combining parameters with calls. No more start/end. All parameters must be locals (possibly uplevel) or parameters or globals or temporaries, never expressions. This is likely the case already. >> >> >> And, aside, look what I do for C. I made it work somehow. I don't remember off hand but I did odd stuff also because of static links. Like maybe always passing one, even if null, as last parameter, because extra parameters are always allowed in C. I declare the function pointers with "..." (slightly different in C vs. C++). >> >> >> The gcc backend passes static link in a register dedicated to it. >> >> - Jay >> >> On Nov 30, 2015, at 2:00 PM, Rodney Bates wrote: >> >>> Moreover, CM3's seemingly nice idea of making IR operators >>> method calls makes it very awkward to do idiom recognition or >>> state-dependent handling of general-purpose operators. >> _______________________________________________ >> M3commit mailing list >> M3commit at elegosoft.com >> https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3commit > > -- > Rodney Bates > rodney.m.bates at acm.org > _______________________________________________ > M3commit mailing list > M3commit at elegosoft.com > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3commit From hendrik at topoi.pooq.com Thu Dec 3 00:30:09 2015 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Wed, 2 Dec 2015 18:30:09 -0500 Subject: [M3devel] addition of GPL stuff In-Reply-To: References: Message-ID: <20151202233009.GB19699@topoi.pooq.com> On Mon, Sep 14, 2015 at 06:14:52AM +0000, Jay K wrote: > Um, sorry to bring up such annoying matters, but maybe we should not be licensingnew files as GPL, assuming they aren't derived from GPL files? > e.g. the LLVM m3makfiles and Makefiles? > Thank you, - Jay To resurrect a post from ages gone by. We should be licencing everything GPL, assuming it's original, and not already constrained by SRC's license. If another license is appropriate, use that too. Make it dual licensed. Dual licencing works as possible: anyone gets to choose which of the licences they are going to use. So if your use is allowed by *any* of the listed licenses, it's OK. It's a way to achieve greater compatibility than could be obtained by any one of those licenses. In particular, the copyright owner (initially the author) could grant rights under both the GPL and the SRC licenses, to assure copatibility with both. THe LGPL might be better than GPL for freedom, and the MIT licence even better. Tht way, if ever a viable collection of Modula 3 code is licenced under GPL, that collection can be used with GPL code freely. -- hendrik > > > > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel From lists at darko.org Thu Dec 3 01:35:26 2015 From: lists at darko.org (Darko Volaric) Date: Wed, 2 Dec 2015 16:35:26 -0800 Subject: [M3devel] addition of GPL stuff In-Reply-To: <20151202233009.GB19699@topoi.pooq.com> References: <20151202233009.GB19699@topoi.pooq.com> Message-ID: What's the argument against placing contributions in the public domain? Licences are tedious. Even short ones require reading and understanding when you're using the code, and most people use many projects. Renouncing copyright is simple, flexible and no-one can copyright the work. Or am I missing some important legal wrinkle? Do contributors want to keep control of their code? On Wed, Dec 2, 2015 at 3:30 PM, Hendrik Boom wrote: > On Mon, Sep 14, 2015 at 06:14:52AM +0000, Jay K wrote: > > Um, sorry to bring up such annoying matters, but maybe we should not > be licensingnew files as GPL, assuming they aren't derived from GPL files? > > e.g. the LLVM m3makfiles and Makefiles? > > Thank you, - Jay > > To resurrect a post from ages gone by. > > We should be licencing everything GPL, assuming it's original, and not > already constrained by SRC's license. > > If another license is appropriate, use that too. Make it dual licensed. > Dual licencing works as possible: anyone gets to choose which of > the licences they are going to use. So if your use is allowed by *any* > of the listed licenses, it's OK. > > It's a way to achieve greater compatibility than could be obtained by > any one of those licenses. > > In particular, the copyright owner (initially the author) could grant > rights under both the GPL and the SRC licenses, to assure copatibility > with both. THe LGPL might be better than GPL for freedom, and the MIT > licence even better. > > Tht way, if ever a viable collection of Modula 3 code is licenced under > GPL, that collection can be used with GPL code freely. > > -- hendrik > > > > > > > > > > _______________________________________________ > > M3devel mailing list > > M3devel at elegosoft.com > > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel > > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Thu Dec 3 04:52:36 2015 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Wed, 2 Dec 2015 22:52:36 -0500 Subject: [M3devel] addition of GPL stuff In-Reply-To: References: <20151202233009.GB19699@topoi.pooq.com> Message-ID: <20151203035236.GA22525@topoi.pooq.com> On Wed, Dec 02, 2015 at 04:35:26PM -0800, Darko Volaric wrote: > What's the argument against placing contributions in the public domain? Public Domain would satisfy me adequately. If it were universal. However, there are partss of the world where public domain is not an accepted legal concept. That's why there is a creative Commons licence that is essentially equivalent to public domain. > Licences are tedious. Even short ones require reading and understanding > when you're using the code, and most people use many projects. > > Renouncing copyright is simple, flexible and no-one can copyright the work. Actually, they can as soon as they make changes. The original remains public, but they can claim rights over the modifications. > > Or am I missing some important legal wrinkle? Do contributors want to keep > control of their code? The legal wrinkle is that public domain is not everywhere recognised. I believe the Creative Commons website has something to say about this. --- hendrik > > On Wed, Dec 2, 2015 at 3:30 PM, Hendrik Boom wrote: > > > On Mon, Sep 14, 2015 at 06:14:52AM +0000, Jay K wrote: > > > Um, sorry to bring up such annoying matters, but maybe we should not > > be licensingnew files as GPL, assuming they aren't derived from GPL files? > > > e.g. the LLVM m3makfiles and Makefiles? > > > Thank you, - Jay > > > > To resurrect a post from ages gone by. > > > > We should be licencing everything GPL, assuming it's original, and not > > already constrained by SRC's license. > > > > If another license is appropriate, use that too. Make it dual licensed. > > Dual licencing works as possible: anyone gets to choose which of > > the licences they are going to use. So if your use is allowed by *any* > > of the listed licenses, it's OK. > > > > It's a way to achieve greater compatibility than could be obtained by > > any one of those licenses. > > > > In particular, the copyright owner (initially the author) could grant > > rights under both the GPL and the SRC licenses, to assure copatibility > > with both. THe LGPL might be better than GPL for freedom, and the MIT > > licence even better. > > > > Tht way, if ever a viable collection of Modula 3 code is licenced under > > GPL, that collection can be used with GPL code freely. > > > > -- hendrik > > > > > > > > > > > > > > > > _______________________________________________ > > > M3devel mailing list > > > M3devel at elegosoft.com > > > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel > > > > _______________________________________________ > > M3devel mailing list > > M3devel at elegosoft.com > > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel > > From microcode at zoho.com Thu Dec 3 08:36:11 2015 From: microcode at zoho.com (microcode at zoho.com) Date: Thu, 3 Dec 2015 07:36:11 +0000 Subject: [M3devel] addition of GPL stuff In-Reply-To: <20151202233009.GB19699@topoi.pooq.com> References: <20151202233009.GB19699@topoi.pooq.com> Message-ID: <20151203073611.GH3127@zoho.com> On Wed, Dec 02, 2015 at 06:30:09PM -0500, Hendrik Boom wrote: > On Mon, Sep 14, 2015 at 06:14:52AM +0000, Jay K wrote: > > Um, sorry to bring up such annoying matters, but maybe we should not > be licensingnew files as GPL, assuming they aren't derived from GPL files? > > e.g. the LLVM m3makfiles and Makefiles? > > Thank you, - Jay snip > Tht way, if ever a viable collection of Modula 3 code is licenced under > GPL, that collection can be used with GPL code freely. No. MIT and BSD licensed code can be used in any project. GPL poisons the product and is not compatible with free software licenses. I realize my opinion is irrelevant but I agree with Jay 1,000% on this. And it's an open mailing list, so... From hendrik at topoi.pooq.com Thu Dec 3 19:36:58 2015 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Thu, 3 Dec 2015 13:36:58 -0500 Subject: [M3devel] addition of GPL stuff In-Reply-To: <20151203073611.GH3127@zoho.com> References: <20151202233009.GB19699@topoi.pooq.com> <20151203073611.GH3127@zoho.com> Message-ID: <20151203183657.GA4527@topoi.pooq.com> On Thu, Dec 03, 2015 at 07:36:11AM +0000, microcode at zoho.com wrote: > On Wed, Dec 02, 2015 at 06:30:09PM -0500, Hendrik Boom wrote: > > On Mon, Sep 14, 2015 at 06:14:52AM +0000, Jay K wrote: > > > Um, sorry to bring up such annoying matters, but maybe we should not > > be licensingnew files as GPL, assuming they aren't derived from GPL files? > > > e.g. the LLVM m3makfiles and Makefiles? > > > Thank you, - Jay > > snip > > > Tht way, if ever a viable collection of Modula 3 code is licenced under > > GPL, that collection can be used with GPL code freely. > > No. MIT and BSD licensed code can be used in any project. GPL poisons the > product and is not compatible with free software licenses. Yes, MIT licence is good. And it doesn't conflict with the SRC licence, either so that should be good, too. And so is the BSD licence without the advertising clause. Apple went to town with this one when theyy build OS/X, so it's definitely nonrestrictive. > > I realize my opinion is irrelevant but I agree with Jay 1,000% on this. And > it's an open mailing list, so... > > > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel From jay.krell at cornell.edu Sat Dec 5 12:54:05 2015 From: jay.krell at cornell.edu (Jay K) Date: Sat, 5 Dec 2015 11:54:05 +0000 Subject: [M3devel] addition of GPL stuff In-Reply-To: <20151203183657.GA4527@topoi.pooq.com> References: , <20151202233009.GB19699@topoi.pooq.com>, <20151203073611.GH3127@zoho.com>, <20151203183657.GA4527@topoi.pooq.com> Message-ID: We shouldn't spend much time on this, but... The license that OpenBSD, NetBSD, FreeBSD use, that is what we should use. It is the same license. These are fairly large heavily used projects, and they copy code around amongst eachother, and commercial ventures fork and close the code, without attribution -- that is allowed. This is a license that lets anyone do just about anything, including take it as their own and profit. it is a short license.Shorter than this email. It does not require giving credit.Giving credit is nice, but exactly how/where/when? And how muchtime/energy must people spend to figure that out?The older BSD license required giving credit, and there was protest and the claused was dropped. it does not require giving back. Again, giving back is great, but requiring it is too much.What if someone wants to release something but we are all on vacation not answering email?They have to wait for us to respond to take their changes before they can ship them? The point of this license is to remove any barrier to reuse that is easy to remove.(ignoring quality and functionality of the code) One of the reasons OpenBSD rejects licenses is because more licenses requires more readingand possibly more lawyer time, more uncertainty, when there are already sufficient tried-and-truelicenses. I believe this is why they reject the Apache 2.0 license. What the GPL does is quite different. It basically makes you GPL anythingyou link the GPL code to. It maybe doesn't require giving back, or require giving credit,but it requires source be available to anyone that receives the binaries. You can sell the binaries,but you must do so including source (or a link to download the source).Most commercial ventures believe that this requirement makes it impossible to make money.You might get one sale, but then the source is out and anyone can duplicate the functionality.Others claim that "support" is an adequate business model. (If you are just sitting on the binaries all by yourself and don't give them to anyone, the GPL has no effect, youcan keep the source to yourself as well. People sometimes misunderstand this.) MIT license is probably about the same and probably second best. - Jay > Date: Thu, 3 Dec 2015 13:36:58 -0500 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] addition of GPL stuff > > On Thu, Dec 03, 2015 at 07:36:11AM +0000, microcode at zoho.com wrote: > > On Wed, Dec 02, 2015 at 06:30:09PM -0500, Hendrik Boom wrote: > > > On Mon, Sep 14, 2015 at 06:14:52AM +0000, Jay K wrote: > > > > Um, sorry to bring up such annoying matters, but maybe we should not > > > be licensingnew files as GPL, assuming they aren't derived from GPL files? > > > > e.g. the LLVM m3makfiles and Makefiles? > > > > Thank you, - Jay > > > > snip > > > > > Tht way, if ever a viable collection of Modula 3 code is licenced under > > > GPL, that collection can be used with GPL code freely. > > > > No. MIT and BSD licensed code can be used in any project. GPL poisons the > > product and is not compatible with free software licenses. > > Yes, MIT licence is good. And it doesn't conflict with the SRC > licence, either so that should be good, too. > > And so is the BSD licence without the advertising clause. > > Apple went to town with this one when theyy build OS/X, so it's > definitely nonrestrictive. > > > > > I realize my opinion is irrelevant but I agree with Jay 1,000% on this. And > > it's an open mailing list, so... > > > > > > _______________________________________________ > > M3devel mailing list > > M3devel at elegosoft.com > > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Sat Dec 5 23:15:20 2015 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sat, 5 Dec 2015 22:15:20 +0000 (UTC) Subject: [M3devel] addition of GPL stuff In-Reply-To: References: Message-ID: <1157844485.26117551.1449353720968.JavaMail.yahoo@mail.yahoo.com> Hey a little bit off topic, what about SRC reports, can we track down all the Green Book's (Systems programming with Modula-3) chapters and reformat them to make it public?I mean, I haven't seen anything of that quality in terms of intellectual strictness and so easy to read in any computer language book. Thanks in advance El S?bado 5 de diciembre de 2015 6:54, Jay K escribi?: #yiv5960026191 #yiv5960026191 --.yiv5960026191hmmessage P{margin:0px;padding:0px;}#yiv5960026191 body.yiv5960026191hmmessage{font-size:12pt;font-family:Calibri;}#yiv5960026191 We shouldn't spend much time on this, but... The license that OpenBSD, NetBSD, FreeBSD use, that is what we should use. It is the same license. These are fairly large heavily used projects, and they copy code around amongst eachother, and commercial ventures fork and close the code, without attribution -- that is allowed. This is a license that lets anyone do just about anything, including take it as their own and profit. it is a short license.Shorter than this email. It does not require giving credit.Giving credit is nice, but exactly how/where/when? And how muchtime/energy must people spend to figure that out?The older BSD license required giving credit, and there was protest and the claused was dropped. it does not require giving back. Again, giving back is great, but requiring it is too much.What if someone wants to release something but we are all on vacation not answering email?They have to wait for us to respond to take their changes before they can ship them? The point of this license is to remove any barrier to reuse that is easy to remove.(ignoring quality and functionality of the code) One of the reasons OpenBSD rejects licenses is because more licenses requires more readingand possibly more lawyer time, more uncertainty, when there are already sufficient tried-and-truelicenses. I believe this is why they reject the?Apache 2.0 license. What the GPL does is quite different. It basically makes you GPL anythingyou link the GPL code to. It maybe doesn't require giving back, or require giving credit,but it requires source be available to anyone that receives the binaries. You can sell the binaries,but you must do so including source (or a link to download the source).Most commercial ventures believe that this requirement makes it impossible to make money.You might get one sale, but then the source is out and anyone can duplicate the functionality.Others claim that "support" is an adequate business model. (If you are just sitting on the binaries all?by yourself and don't give them to anyone, the GPL has no effect, youcan keep the source to yourself as well.?People sometimes misunderstand this.) MIT license is probably about the same and probably second best. ?- Jay > Date: Thu, 3 Dec 2015 13:36:58 -0500 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] addition of GPL stuff > > On Thu, Dec 03, 2015 at 07:36:11AM +0000, microcode at zoho.com wrote: > > On Wed, Dec 02, 2015 at 06:30:09PM -0500, Hendrik Boom wrote: > > > On Mon, Sep 14, 2015 at 06:14:52AM +0000, Jay K wrote: > > > > Um, sorry to bring up such annoying matters, but maybe we should not > > > be licensingnew files as GPL, assuming they aren't derived from GPL files? > > > > e.g. the LLVM m3makfiles and Makefiles? > > > > Thank you, - Jay > > > > snip > > > > > Tht way, if ever a viable collection of Modula 3 code is licenced under > > > GPL, that collection can be used with GPL code freely. > > > > No. MIT and BSD licensed code can be used in any project. GPL poisons the > > product and is not compatible with free software licenses. > > Yes, MIT licence is good. And it doesn't conflict with the SRC > licence, either so that should be good, too. > > And so is the BSD licence without the advertising clause. > > Apple went to town with this one when theyy build OS/X, so it's > definitely nonrestrictive. > > > > > I realize my opinion is irrelevant but I agree with Jay 1,000% on this. And > > it's an open mailing list, so... > > > > > > _______________________________________________ > > M3devel mailing list > > M3devel at elegosoft.com > > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel _______________________________________________ M3devel mailing list M3devel at elegosoft.com https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Sun Dec 6 00:20:45 2015 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Sat, 5 Dec 2015 18:20:45 -0500 Subject: [M3devel] addition of GPL stuff In-Reply-To: <1157844485.26117551.1449353720968.JavaMail.yahoo@mail.yahoo.com> References: <1157844485.26117551.1449353720968.JavaMail.yahoo@mail.yahoo.com> Message-ID: <20151205232045.GA25815@topoi.pooq.com> On Sat, Dec 05, 2015 at 10:15:20PM +0000, Daniel Alejandro Benavides D. wrote: > Hey a little bit off topic, what about SRC reports, can we track down all the Green Book's (Systems programming with Modula-3) chapters and reformat them to make it public?I mean, I haven't seen anything of that quality in terms of intellectual strictness and so easy to read in any computer language book. > Thanks in advance Only the copyright holder can do that, unless it is in he public domain. -- hendrik From dabenavidesd at yahoo.es Sun Dec 6 00:47:56 2015 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sat, 5 Dec 2015 23:47:56 +0000 (UTC) Subject: [M3devel] addition of GPL stuff In-Reply-To: <20151205232045.GA25815@topoi.pooq.com> References: <20151205232045.GA25815@topoi.pooq.com> Message-ID: <1330494183.25980356.1449359276781.JavaMail.yahoo@mail.yahoo.com> Hello:I understand it can be a literally impossible to track down copyright holders as no Modula-3 sources are apart of any entity besides Elego (is this not a solution of the problem?). Respect of the RR, at some point in time, they start to be universally accessible (like 70 years) or so? Thanks in advance El S?bado 5 de diciembre de 2015 18:20, Hendrik Boom escribi?: On Sat, Dec 05, 2015 at 10:15:20PM +0000, Daniel Alejandro Benavides D. wrote: > Hey a little bit off topic, what about SRC reports, can we track down all the Green Book's (Systems programming with Modula-3) chapters and reformat them to make it public?I mean, I haven't seen anything of that quality in terms of intellectual strictness and so easy to read in any computer language book. > Thanks in advance Only the copyright holder can do that, unless it is in he public domain. -- hendrik _______________________________________________ M3devel mailing list M3devel at elegosoft.com https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sun Dec 6 01:07:40 2015 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 6 Dec 2015 01:07:40 +0100 Subject: [M3devel] addition of GPL stuff In-Reply-To: <1157844485.26117551.1449353720968.JavaMail.yahoo@mail.yahoo.com> References: <1157844485.26117551.1449353720968.JavaMail.yahoo@mail.yahoo.com> Message-ID: <20151206010740.a58ec527ca708a8dd33955f8@elegosoft.com> On Sat, 5 Dec 2015 22:15:20 +0000 (UTC) "Daniel Alejandro Benavides D." wrote: > Hey a little bit off topic, what about SRC reports, can we track down all the Green Book's (Systems programming with Modula-3) chapters and reformat them to make it public?I mean, I haven't seen anything of that quality in terms of intellectual strictness and so easy to read in any computer language book. The complete language definition, which is one part of the Green Book, is already online: http://www.opencm3.net/doc/reference/complete/html/Modula_3_Language_definitio.html Also a complete description of all the available interfaces http://www.opencm3.net/doc/help/interfaces.html and the quake reference: http://www.opencm3.net/doc/help/cm3/quake.html Alas, I haven't found an active site for some time that actually servers the SRC reports; they're not in the HP archive and gatekeeper seems to be gone forever. If anybody knows where to download them, I would appreciate a hint. 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 dabenavidesd at yahoo.es Sun Dec 6 01:28:34 2015 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sun, 6 Dec 2015 00:28:34 +0000 (UTC) Subject: [M3devel] addition of GPL stuff In-Reply-To: <20151206010740.a58ec527ca708a8dd33955f8@elegosoft.com> References: <20151206010740.a58ec527ca708a8dd33955f8@elegosoft.com> Message-ID: <1636697213.26135778.1449361714400.JavaMail.yahoo@mail.yahoo.com> Hi:yeah they are here:http://www.mirrorservice.org/sites/www.bitsavers.org/pdf/dec/tech_reports/ But unintendedly found Network Systems Laboratory ones: https://archive.org/stream/bitsavers_dectechrep_48346/NSL-NN-11_djvu.txt Thanks for point out this and in advance | ? | | ? | | ? | ? | ? | ? | ? | | Index of /sites/www.bitsavers.org/pdf/dec/tech_reportsIndex of /sites/www.bitsavers.org/pdf/dec/tech_reports/ Name Last modified Size | | | | Ver en www.mirrorservice.org | Vista previa por Yahoo | | | | ? | El S?bado 5 de diciembre de 2015 19:07, Olaf Wagner escribi?: On Sat, 5 Dec 2015 22:15:20 +0000 (UTC) "Daniel Alejandro Benavides D." wrote: > Hey a little bit off topic, what about SRC reports, can we track down all the Green Book's (Systems programming with Modula-3) chapters and reformat them to make it public?I mean, I haven't seen anything of that quality in terms of intellectual strictness and so easy to read in any computer language book. The complete language definition, which is one part of the Green Book, is already online: http://www.opencm3.net/doc/reference/complete/html/Modula_3_Language_definitio.html Also a complete description of all the available interfaces http://www.opencm3.net/doc/help/interfaces.html and the quake reference: http://www.opencm3.net/doc/help/cm3/quake.html Alas, I haven't found an active site for some time that actually servers the SRC reports; they're not in the HP archive and gatekeeper seems to be gone forever. If anybody knows where to download them, I would appreciate a hint. 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 Thu Dec 10 19:15:48 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 10 Dec 2015 12:15:48 -0600 Subject: [M3devel] M3CG loophole operator is not LOOPHOLE (but what?) Message-ID: <5669C154.90603@lcwb.coop> I have just discovered the hard way that the following comment, from M3CG_Ops.i3: loophole (from, two: ZType); (* s0.two := LOOPHOLE(s0.from, two) *) is not true. The front end can produce M3CG loophole ops in which the two types do not have the same size. For example, the front end passes a small exception argument to RaiseEx by value as CGType.Addr, whose size is native word size, and if the argument has a different stack size (e.g. REAL is 32-bit, even on a native 64-bit machine), then it first converts it using the M3CG loophole operator. Almost the same thing can happen for an explicit LOOPHOLE in M3 source code. On a 64-bit machine, compiling libm3/src/geometry/Transform.m3, M3 source code equivalent to: LOOPHOLE (REALvariable, BITS BITSIZE(REAL) FOR [-16_7fffffff-1 .. 16_7fffffff]) (translated by CastExpr.m3:286) produces almost the same M3CG loophole operator, because the stack size of the subrange is 64-bit, even though its memory size is 32. So the loophole comes out converting REAL to Int64. (Note that BITS has no effect, since the type is not used as a field or array element). Since loophole takes its operand off the abstract stack and puts its result back there, the stack size is the right one to use here, for both from-type and to-type. But what are the complete rules about loophole? Apparently some combinations really are bitcasts, but which ones? Exactly those where the sizes match? What is the actual conversion for other combinations? 32-bit REAL to 64-bit integer or address is particularly unclear. If anybody has any knowledge about this, it would be helpful. There is quite a bit of code to vet, otherwise. 15 different places in the front end generate loophole. -- Rodney Bates rodney.m.bates at acm.org From jay.krell at cornell.edu Fri Dec 11 07:53:08 2015 From: jay.krell at cornell.edu (Jay K) Date: Fri, 11 Dec 2015 06:53:08 +0000 Subject: [M3devel] M3CG loophole operator is not LOOPHOLE (but what?) In-Reply-To: <5669C154.90603@lcwb.coop> References: <5669C154.90603@lcwb.coop> Message-ID: I don't recall...but it doesn't look like M3C handles this specially,but indeed m3cc has special logic for loophole and floats. Ugh.It makes a temporary. I'll have to experiment. The right thing to do, really, is take the address of a float, loopholethat into an address of another type, and dereference that.Not in the backend, but in the Modula-3 code. Never to loophole to or from a float value.And hardly ever loophole values at all.Loopholing between pointers and same-sized integers, ok.Or pointers and other pointers, ok. I don't know if it called loophole, but between varying sized/signedness integers also ok.(really that is chop or extend) We should considering changing m3front to honor these rules.That is how you write semi-portable C to dissect floats.Or via unions. There are intrinsics in some compilers for doing better.Visual C++ for non-x86 platforsm (ARM and CE) has it right, with stuff like_CopyDoubleToInt64, _CopyInt64ToDouble, _CopyInt32ToFloat, CopyFloatToInt32.You can argue the names, but really those are the exact 4 intrinsics you want.Leaving it to the compiler to know if it can do a register move or must go through memory.But the portable way requires going through memory. And, really, put all the float dissection into C anyway. - Jay > Date: Thu, 10 Dec 2015 12:15:48 -0600 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: [M3devel] M3CG loophole operator is not LOOPHOLE (but what?) > > I have just discovered the hard way that the following comment, from M3CG_Ops.i3: > > loophole (from, two: ZType); > (* s0.two := LOOPHOLE(s0.from, two) *) > > is not true. > > The front end can produce M3CG loophole ops in which the two types do not have > the same size. For example, the front end passes a small exception argument > to RaiseEx by value as CGType.Addr, whose size is native word size, and if > the argument has a different stack size (e.g. REAL is 32-bit, even on a native > 64-bit machine), then it first converts it using the M3CG loophole operator. > > Almost the same thing can happen for an explicit LOOPHOLE in M3 source code. On a > 64-bit machine, compiling libm3/src/geometry/Transform.m3, M3 source code > equivalent to: > > LOOPHOLE (REALvariable, BITS BITSIZE(REAL) FOR [-16_7fffffff-1 .. 16_7fffffff]) > > (translated by CastExpr.m3:286) produces almost the same M3CG loophole operator, > because the stack size of the subrange is 64-bit, even though its memory size is > 32. So the loophole comes out converting REAL to Int64. (Note that BITS has no > effect, since the type is not used as a field or array element). > > Since loophole takes its operand off the abstract stack and puts its result back > there, the stack size is the right one to use here, for both from-type and to-type. > > But what are the complete rules about loophole? Apparently some combinations > really are bitcasts, but which ones? Exactly those where the sizes match? What > is the actual conversion for other combinations? 32-bit REAL to 64-bit integer > or address is particularly unclear. > > If anybody has any knowledge about this, it would be helpful. There is quite a > bit of code to vet, otherwise. 15 different places in the front end generate > loophole. > > -- > Rodney Bates > rodney.m.bates at acm.org > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 14 03:20:55 2015 From: jay.krell at cornell.edu (Jay) Date: Sun, 13 Dec 2015 18:20:55 -0800 Subject: [M3devel] M3CG loophole operator is not LOOPHOLE (but what?) In-Reply-To: References: <5669C154.90603@lcwb.coop> Message-ID: I know, but this pattern is pretty rare. - Jay On Dec 13, 2015, at 1:46 AM, Antony Hosking wrote: > Excepting that in some cases taking the address may force the value into memory, when it could have stayed in a register. > The intent is to allow the backend to avoid that. > >> On 11 Dec 2015, at 5:53 PM, Jay K wrote: >> >> The right thing to do, really, is take the address of a float, loophole >> that into an address of another type, and dereference that. >> Not in the backend, but in the Modula-3 code. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Mon Dec 14 03:40:46 2015 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Mon, 14 Dec 2015 02:40:46 +0000 (UTC) Subject: [M3devel] M3CG loophole operator is not LOOPHOLE (but what?) In-Reply-To: References: <5669C154.90603@lcwb.coop> Message-ID: <1615931268.1036686.1450060846633.JavaMail.yahoo@mail.yahoo.com> Hello:Excuse me if is wrong to say, but doesn't the specification of Modula-3 explicit about how the UNSAFE stuff is implementation-dependent, that is to say; "it's your decision how to implement it".Thanks in advance El Domingo 13 de diciembre de 2015 21:20, Jay escribi?: I know, but this pattern is pretty rare.? ?- Jay On Dec 13, 2015, at 1:46 AM, Antony Hosking wrote: Excepting that in some cases taking the address may force the value into memory, when it could have stayed in a register.The intent is to allow the backend to avoid that. On 11 Dec 2015, at 5:53 PM, Jay K wrote: The right thing to do, really, is take the address of a float, loopholethat into an address of another type, and dereference that.Not in the backend, but in the Modula-3 code. _______________________________________________ M3devel mailing list M3devel at elegosoft.com https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Mon Dec 14 04:05:18 2015 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Mon, 14 Dec 2015 03:05:18 +0000 (UTC) Subject: [M3devel] M3CG loophole operator is not LOOPHOLE (but what?) In-Reply-To: <300C917B-B104-469E-8885-99CC5D1D964F@purdue.edu> References: <5669C154.90603@lcwb.coop> <1615931268.1036686.1450060846633.JavaMail.yahoo@mail.yahoo.com> <300C917B-B104-469E-8885-99CC5D1D964F@purdue.edu> Message-ID: <832820227.1031770.1450062318650.JavaMail.yahoo@mail.yahoo.com> Hi:exactly, if the bit pattern is unequal in two implementations, surely you will be having 2 different results El Domingo 13 de diciembre de 2015 21:51, "Hosking, Antony L" escribi?: From the language definition: An?unchecked type transfer operation has the form: ? ? LOOPHOLE(e, T) where?e?is an expression whose type is not an open array type and?T?is a type. It denotes?e's bit pattern?interpreted as a variable or value of type?T. It is a designator if?e?is, and is writable if?e?is. An unchecked?runtime error can occur if?e's bit pattern is not a legal?T, or if?e?is a designator and some legal bit pattern for?T?is not legal for?e. If?T?is not an open array type,?BITSIZE(e)?must equal?BITSIZE(T). If?T?is an open array type, its element type must not be an open array?type, and?e's bit pattern is interpreted as an array whose length is?BITSIZE(e)?divided by?BITSIZE(the element type of?T). The division?must come out even. On 14 Dec 2015, at 1:40 PM, Daniel Alejandro Benavides D. wrote: Hello: Excuse me if is wrong to say, but doesn't the specification of Modula-3 explicit about how the?UNSAFE stuff is implementation-dependent, that is to say; "it's your decision how to implement?it". Thanks in advance El Domingo 13 de diciembre de 2015 21:20, Jay escribi?: I know, but this pattern is pretty rare.? ?- Jay On Dec 13, 2015, at 1:46 AM, Antony Hosking wrote: Excepting that in some cases taking the address may force the value into memory, when it?could have stayed in a register. The intent is to allow the backend to avoid that. On 11 Dec 2015, at 5:53 PM, Jay K wrote: The right thing to do, really, is take the address of a float, loophole that into an address of another type, and dereference that. Not in the backend, but in the Modula-3 code. _______________________________________________ M3devel mailing list M3devel at elegosoft.com https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Mon Dec 14 04:19:32 2015 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Mon, 14 Dec 2015 03:19:32 +0000 (UTC) Subject: [M3devel] M3CG loophole operator is not LOOPHOLE (but what?) In-Reply-To: References: <5669C154.90603@lcwb.coop> <1615931268.1036686.1450060846633.JavaMail.yahoo@mail.yahoo.com> <300C917B-B104-469E-8885-99CC5D1D964F@purdue.edu> <832820227.1031770.1450062318650.JavaMail.yahoo@mail.yahoo.com> Message-ID: <2041142346.1036456.1450063172587.JavaMail.yahoo@mail.yahoo.com> Hi:but isn't the bit pattern, the data layout, what it makes the difference Anthony? Thanks in advance El Domingo 13 de diciembre de 2015 22:14, "Hosking, Antony L" escribi?: Bits are bits. ?It is implementation-dependent because bits one machine will be different on another. ?My point was that the bit sizes are expected to be the same (except when T is an open array, in which case the bits form the payload of the open array, with the size constructed accordingly). On 14 Dec 2015, at 2:05 PM, Daniel Alejandro Benavides D. wrote: Hi:exactly, if the bit pattern is unequal in two implementations, surely you will be having 2 different results El Domingo 13 de diciembre de 2015 21:51, "Hosking, Antony L" escribi?: >From the language definition: An?unchecked type transfer operation has the form: ? ? LOOPHOLE(e, T) where?e?is an expression whose type is not an open array type and?T?is a type. It denotes?e's bit pattern?interpreted as a variable or value of type?T. It is a designator if?e?is, and is writable if?e?is. An unchecked?runtime error can occur if?e's bit pattern is not a legal?T, or if?e?is a designator and some legal bit pattern for?T?is not legal for?e. If?T?is not an open array type,?BITSIZE(e)?must equal?BITSIZE(T). If?T?is an open array type, its element type must not be an open array?type, and?e's bit pattern is interpreted as an array whose length is?BITSIZE(e)?divided by?BITSIZE(the element type of?T). The division?must come out even. On 14 Dec 2015, at 1:40 PM, Daniel Alejandro Benavides D. wrote: Hello: Excuse me if is wrong to say, but doesn't the specification of Modula-3 explicit about how the?UNSAFE stuff is implementation-dependent, that is to say; "it's your decision how to implement?it". Thanks in advance El Domingo 13 de diciembre de 2015 21:20, Jay escribi?: I know, but this pattern is pretty rare.? ?- Jay On Dec 13, 2015, at 1:46 AM, Antony Hosking wrote: Excepting that in some cases taking the address may force the value into memory, when it?could have stayed in a register. The intent is to allow the backend to avoid that. On 11 Dec 2015, at 5:53 PM, Jay K wrote: The right thing to do, really, is take the address of a float, loophole that into an address of another type, and dereference that. Not in the backend, but in the Modula-3 code. _______________________________________________ M3devel mailing list M3devel at elegosoft.com https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Mon Dec 14 04:30:47 2015 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Mon, 14 Dec 2015 03:30:47 +0000 (UTC) Subject: [M3devel] M3CG loophole operator is not LOOPHOLE (but what?) In-Reply-To: <2041142346.1036456.1450063172587.JavaMail.yahoo@mail.yahoo.com> References: <5669C154.90603@lcwb.coop> <1615931268.1036686.1450060846633.JavaMail.yahoo@mail.yahoo.com> <300C917B-B104-469E-8885-99CC5D1D964F@purdue.edu> <832820227.1031770.1450062318650.JavaMail.yahoo@mail.yahoo.com> <2041142346.1036456.1450063172587.JavaMail.yahoo@mail.yahoo.com> Message-ID: <1714007729.1032434.1450063847030.JavaMail.yahoo@mail.yahoo.com> Hi:You know m3middle uses unsafe stuff, probably as Rodney points out m3front too, it doesn't have the correct implementation (as in m3middle) because it worked in another architecture, but not in here. That's why these modules need different treatment to care after release new versions.Thanks in advance El Domingo 13 de diciembre de 2015 22:19, Daniel Alejandro Benavides D. escribi?: Hi:but isn't the bit pattern, the data layout, what it makes the difference Anthony? Thanks in advance El Domingo 13 de diciembre de 2015 22:14, "Hosking, Antony L" escribi?: Bits are bits. ?It is implementation-dependent because bits one machine will be different on another. ?My point was that the bit sizes are expected to be the same (except when T is an open array, in which case the bits form the payload of the open array, with the size constructed accordingly). On 14 Dec 2015, at 2:05 PM, Daniel Alejandro Benavides D. wrote: Hi:exactly, if the bit pattern is unequal in two implementations, surely you will be having 2 different results El Domingo 13 de diciembre de 2015 21:51, "Hosking, Antony L" escribi?: >From the language definition: An?unchecked type transfer operation has the form: ? ? LOOPHOLE(e, T) where?e?is an expression whose type is not an open array type and?T?is a type. It denotes?e's bit pattern?interpreted as a variable or value of type?T. It is a designator if?e?is, and is writable if?e?is. An unchecked?runtime error can occur if?e's bit pattern is not a legal?T, or if?e?is a designator and some legal bit pattern for?T?is not legal for?e. If?T?is not an open array type,?BITSIZE(e)?must equal?BITSIZE(T). If?T?is an open array type, its element type must not be an open array?type, and?e's bit pattern is interpreted as an array whose length is?BITSIZE(e)?divided by?BITSIZE(the element type of?T). The division?must come out even. On 14 Dec 2015, at 1:40 PM, Daniel Alejandro Benavides D. wrote: Hello: Excuse me if is wrong to say, but doesn't the specification of Modula-3 explicit about how the?UNSAFE stuff is implementation-dependent, that is to say; "it's your decision how to implement?it". Thanks in advance El Domingo 13 de diciembre de 2015 21:20, Jay escribi?: I know, but this pattern is pretty rare.? ?- Jay On Dec 13, 2015, at 1:46 AM, Antony Hosking wrote: Excepting that in some cases taking the address may force the value into memory, when it?could have stayed in a register. The intent is to allow the backend to avoid that. On 11 Dec 2015, at 5:53 PM, Jay K wrote: The right thing to do, really, is take the address of a float, loophole that into an address of another type, and dereference that. Not in the backend, but in the Modula-3 code. _______________________________________________ M3devel mailing list M3devel at elegosoft.com https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel _______________________________________________ M3devel mailing list M3devel at elegosoft.com https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Mon Dec 14 14:30:58 2015 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Mon, 14 Dec 2015 13:30:58 +0000 (UTC) Subject: [M3devel] M3CG loophole operator is not LOOPHOLE (but what?) In-Reply-To: References: <5669C154.90603@lcwb.coop> <1615931268.1036686.1450060846633.JavaMail.yahoo@mail.yahoo.com> <300C917B-B104-469E-8885-99CC5D1D964F@purdue.edu> <832820227.1031770.1450062318650.JavaMail.yahoo@mail.yahoo.com> <2041142346.1036456.1450063172587.JavaMail.yahoo@mail.yahoo.com> <1714007729.1032434.1450063847030.JavaMail.yahoo@mail.yahoo.com> Message-ID: <554364982.1425193.1450099858596.JavaMail.yahoo@mail.yahoo.com> Hi:the difference between two types isn't bitsize, but structure or brand. Similarly, the cast between to types is possible by its bitpattern not by its bitsize. The implementation has the authority to adjust their sizes I believe (because it's implementation dependent). Antony m3devel isn't getting your mails in December archive, and here I have been struggling to read it -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at darko.org Wed Dec 16 16:47:49 2015 From: lists at darko.org (Darko Volaric) Date: Wed, 16 Dec 2015 16:47:49 +0100 Subject: [M3devel] Missing GitHub commits in M3commit Message-ID: It seems that Peter's commits on GitHub are not showing up in the commit list. I'm guessing that this is due to the "send from author" option on GitHub plus Peter's GitHub email not being the one subscribed to the list. Can we change it so that the "send from author option" is disabled and subscribe the GitHub notification email address to the list? This would save potentially having to fix this problem for each contributor. - Darko -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Wed Dec 16 19:01:27 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Wed, 16 Dec 2015 12:01:27 -0600 Subject: [M3devel] M3CG loophole operator is not LOOPHOLE (but what?) In-Reply-To: <1615931268.1036686.1450060846633.JavaMail.yahoo@mail.yahoo.com> References: <5669C154.90603@lcwb.coop> <1615931268.1036686.1450060846633.JavaMail.yahoo@mail.yahoo.com> Message-ID: <5671A6F7.6040805@lcwb.coop> The issue I raised is not with the M3 LOOPHOLE builtin function. The compiler currently implements it correctly, according to the language definition, as Tony quoted. The front end verifies the size equality, as required by the language, then emits an intermediate "loophole" operator, which will be same size, and thus well-defined as equivalent to LOOPHOLE. (And also llvm bitcast, which is now being used to translate the loophole operator in this case.) My issue is that there are 13 other places the front-end emits an internally generated "loophole", and these (almost?) all can do so with unequal sizes. Moreover, what should be done with the unequal sizes varies from place to place. It is possible that the "loophole" operator can be defined to do what is correct in every case by a conditional rule based on the two types. I need to do another pass through them to be sure. This may be the quickest way to get the llvm backend working, but I think it is not good design. It would be carefully tailored to just a specific set of uses of "loophole", instead of making a reasonable abstraction out of" loophole". It would be rather fragile and involve a lot of analysis on the full Cartesian product of both supplier and client side cases of "loophole" to define and verify. The best way, IMO, is to fix each "loophole"-generating site to use other operators, as appropriate. It is at these sites that it is known what should be done in each case. I suspect existing intermediate operators "widen", "insert_mn" and "extract_mn" are sufficient. Again, another pass through the cases is indicated. The only pragmatic drawback to this is that this requires considerable care and retesting to avoid breakage of existing behavior. At worst, it risks inability to bootstrap the compiler. I would prefer one change at a time, each tested by reboostrapping twice. On 12/13/2015 08:40 PM, Daniel Alejandro Benavides D. wrote: > Hello: > Excuse me if is wrong to say, but doesn't the specification of Modula-3 explicit about how the UNSAFE stuff is implementation-dependent, that is to say; "it's your decision how to implement it". > Thanks in advance > > > > El Domingo 13 de diciembre de 2015 21:20, Jay escribi?: > > > I know, but this pattern is pretty rare. > > - Jay > > On Dec 13, 2015, at 1:46 AM, Antony Hosking > wrote: > >> Excepting that in some cases taking the address may force the value into memory, when it could have stayed in a register. >> The intent is to allow the backend to avoid that. >> >>> On 11 Dec 2015, at 5:53 PM, Jay K > wrote: >>> >>> The right thing to do, really, is take the address of a float, loophole >>> that into an address of another type, and dereference that. >>> Not in the backend, but in the Modula-3 code. >>> >> > > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel > > > > > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel > -- Rodney Bates rodney.m.bates at acm.org From lists at darko.org Thu Dec 17 08:55:19 2015 From: lists at darko.org (Darko Volaric) Date: Thu, 17 Dec 2015 08:55:19 +0100 Subject: [M3devel] Missing GitHub commits in M3commit In-Reply-To: References: Message-ID: If there are no objections in the next few days, I'll make the required changes. On Wed, Dec 16, 2015 at 4:47 PM, Darko Volaric wrote: > It seems that Peter's commits on GitHub are not showing up in the commit > list. I'm guessing that this is due to the "send from author" option on > GitHub plus Peter's GitHub email not being the one subscribed to the list. > > Can we change it so that the "send from author option" is disabled and > subscribe the GitHub notification email address to the list? This would > save potentially having to fix this problem for each contributor. > > - Darko > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Mon Dec 21 04:18:17 2015 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Mon, 21 Dec 2015 03:18:17 +0000 (UTC) Subject: [M3devel] M3CG loophole operator is not LOOPHOLE (but what?) In-Reply-To: <5671A6F7.6040805@lcwb.coop> References: <5669C154.90603@lcwb.coop> <1615931268.1036686.1450060846633.JavaMail.yahoo@mail.yahoo.com> <5671A6F7.6040805@lcwb.coop> Message-ID: <297203610.2445107.1450667897642.JavaMail.yahoo@mail.yahoo.com> Hi all: I don't like to repeat nor answer myself, but for the benefit of the discussion lets put it as in the below comment UNSAFE LOOPHOLE alternative VIEW in SPIN OS [1]:A couple of years later, there was an OS project - called, I think, SPIN - that built the entire OS in Modula-3. They used only a tiny amount of UNSAFE code. One area that's often full of bit-twiddling and type munging is network code, where you somehow need to convert a bag-of-bytes into some typed object. The SPIN team added an interesting primitive: "Here's a bag-of-bytes with the same size as an object of type X. View it as an object of type X." This was legal only if every field in X, recursively, had a type for which any bit pattern was legal. (I'd guess - but don't know - that you could have enum type values, with the compiler inserting a check that what was in the buffer as a enumerated value was actually legal. It may have done this for some other types as well - e.g., there was a CARDINAL type which was a subset of INTEGER and consisted only of the non-negative values.)Which inadvertently is the Modula-3 language definition but downsized in terms of UNSAFE operations for normal safety, which only lefts pointer arithmetic and DISPOSE memory management for UNSAFE operations. Now, I wonder given that this is allowed to be safe in SPIN, what is the "UNSAFE" part of casting in Modula-3.I Do rememeber viewing a videotape lecture of James Donahue, and speakign of UNSAFE operations, he said that they were very careful in selecting that as UNSAFE and the other operations. [1][En l?nea]. Disponible en: https://www.marc.info/?l=cryptography&m=139784275512662&q=raw. [Accedido: 21-dic-2015]. Thanks in advance El Mi?rcoles 16 de diciembre de 2015 13:02, Rodney M. Bates escribi?: The issue I raised is not with the M3 LOOPHOLE builtin function.? The compiler currently implements it correctly, according to the language definition, as Tony quoted.? The front end verifies the size equality, as required by the language, then emits an intermediate "loophole" operator, which will be same size, and thus well-defined as equivalent to LOOPHOLE.? (And also llvm bitcast, which is now being used to translate the loophole operator in this case.) My issue is that there are 13 other places the front-end emits an internally generated "loophole", and these (almost?) all can do so with unequal sizes. Moreover, what should be done with the unequal sizes varies from place to place. It is possible that the "loophole" operator can be defined to do what is correct in every case by a conditional rule based on the two types.? I need to do another pass through them to be sure.? This may be the quickest way to get the llvm backend working, but I think it is not good design. It would be carefully tailored to just a specific set of uses of "loophole", instead of making a reasonable abstraction out of" loophole".? It would be rather fragile and involve a lot of analysis on the full Cartesian product of both supplier and client side cases of "loophole" to define and verify. The best way, IMO, is to fix each "loophole"-generating site to use other operators, as appropriate.? It is at these sites that it is known what should be done in each case.? I suspect existing intermediate operators "widen", "insert_mn" and "extract_mn" are sufficient.? Again, another pass through the cases is indicated.? The only pragmatic drawback to this is that this requires considerable care and retesting to avoid breakage of existing behavior.? At worst, it risks inability to bootstrap the compiler. I would prefer one change at a time, each tested by reboostrapping twice. On 12/13/2015 08:40 PM, Daniel Alejandro Benavides D. wrote: > Hello: > Excuse me if is wrong to say, but doesn't the specification of Modula-3 explicit about how the UNSAFE stuff is implementation-dependent, that is to say; "it's your decision how to implement it". > Thanks in advance > > > > El Domingo 13 de diciembre de 2015 21:20, Jay escribi?: > > > I know, but this pattern is pretty rare. > >? - Jay > > On Dec 13, 2015, at 1:46 AM, Antony Hosking > wrote: > >> Excepting that in some cases taking the address may force the value into memory, when it could have stayed in a register. >> The intent is to allow the backend to avoid that. >> >>> On 11 Dec 2015, at 5:53 PM, Jay K > wrote: >>> >>> The right thing to do, really, is take the address of a float, loophole >>> that into an address of another type, and dereference that. >>> Not in the backend, but in the Modula-3 code. >>> >> > > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel > > > > > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel > -- Rodney Bates rodney.m.bates at acm.org _______________________________________________ M3devel mailing list M3devel at elegosoft.com https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Dec 27 18:42:52 2015 From: jay.krell at cornell.edu (Jay K) Date: Sun, 27 Dec 2015 17:42:52 +0000 Subject: [M3devel] binary distribution incompatibility with very old C runtime Message-ID: For the record.. If you try to build the current source with the 5.8.6 release.. or rather, if you try to do anything with 5.8.6, and have a particularly old C/C++ toolset, like over 10 years old, on Windows, you get: m3core.lib.sa(ThreadWin32C.obj) : error LNK2019: unresolved external symbol __wassert referenced in function _ThreadWin32__ProcessStopped m3core.lib.sa(dtoa.obj) : error LNK2019: unresolved external symbol __ftol2_sse referenced in function _m3_strtod The C compiler and runtime change a surprising much through the years. Merely using assert or floating point to integer converson via casting, with a new compiler, does not work with older runtimes. We can do better such as either: 1) Generate all C, so the binary distribution matters less. 2) This is using static linking of m3core for bootstrapping. Deliberately not just because cm3 always does that, but also as a policy for supposed higher/easier compatibility with older releases. Perhaps that is a mistake. For today I'll just install a newer compiler. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Dec 29 07:55:13 2015 From: jay.krell at cornell.edu (Jay K) Date: Tue, 29 Dec 2015 06:55:13 +0000 Subject: [M3devel] NT386 and alloca/jmpbuf change Message-ID: fyi, it looks like I didn't finish the NT386 side of this. I'm working on it "now". - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Dec 30 11:07:00 2015 From: jay.krell at cornell.edu (Jay K) Date: Wed, 30 Dec 2015 10:07:00 +0000 Subject: [M3devel] Add support for real time threads breaks on Mac In-Reply-To: References: , Message-ID: https://github.com/modula3/cm3/commit/af5b2314a8a7ea76d04dbedcb51dee56ab347c51 Add support for real time threads Fails to compile for me on MacOSX. Can we undo it? Or #ifndef __APPLE__ out some parts? ../src/thread/PTHREAD/ThreadPThreadC.c:711:58: error: unknown type name 'cpu_set_t' ThreadPThread__add_core_to_cpuset(int core_id, int size, cpu_set_t *cpuset) Maybe can be implemented using Apple-specific code? What systems does it work on? I'll go off and read.. Thank you, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Dec 30 11:12:50 2015 From: jay.krell at cornell.edu (Jay K) Date: Wed, 30 Dec 2015 10:12:50 +0000 Subject: [M3devel] Add support for real time threads breaks on Mac In-Reply-To: References: , , , Message-ID: I suspect this only works on Linux and will fail on everything else: MacOSX, NetBSD, FreeBSD, OpenBSD, Solaris, Cygwin, Interix and the hypothetical AIX, Irix, HP-UX, VMS, etc. ?- Jay ________________________________ > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com; peter.mckinna at gmail.com > Date: Wed, 30 Dec 2015 10:07:00 +0000 > Subject: [M3devel] Add support for real time threads breaks on Mac > > https://github.com/modula3/cm3/commit/af5b2314a8a7ea76d04dbedcb51dee56ab347c51 > Add support for real time threads Fails to compile for me on MacOSX. > Can we undo it? Or #ifndef __APPLE__ out some parts? > ../src/thread/PTHREAD/ThreadPThreadC.c:711:58: error: unknown type name > 'cpu_set_t' ThreadPThread__add_core_to_cpuset(int core_id, int size, > cpu_set_t *cpuset) Maybe can be implemented using Apple-specific code? > What systems does it work on? I'll go off and read.. Thank you, - Jay > > _______________________________________________ M3devel mailing list > M3devel at elegosoft.com > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel From rodney_bates at lcwb.coop Tue Dec 1 21:17:00 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Tue, 01 Dec 2015 14:17:00 -0600 Subject: [M3devel] [M3commit] [modula3/cm3] b3c18e: Rework indirect calls to possibly nested procedure... In-Reply-To: References: <565cb8dc1ef05_532e3fd1219432c01066b@hookshot-fe5-cp1-prd.iad.github.net.mail> Message-ID: <565E003C.60104@lcwb.coop> Yeah, I would like some changes to the IR too. But it is fairly painful. Many places need to be changed, and I recall some kind of rebuild/bootstrap problem too. I am collecting a list of things I would like, with the idea of doing it all in one change. Some of my wishes predate my writing them down, and I hope I can remember them too. Some of them are motivated by debug information. On 12/01/2015 01:41 PM, Jay wrote: > I suggest one or two changes to the IR. > > > 1. An "official" in-memory representation of a complete unit or program. Modern systems can afford it. > > > 2. More information with function calls. Likely combining parameters with calls. No more start/end. All parameters must be locals (possibly uplevel) or parameters or globals or temporaries, never expressions. This is likely the case already. > > > And, aside, look what I do for C. I made it work somehow. I don't remember off hand but I did odd stuff also because of static links. Like maybe always passing one, even if null, as last parameter, because extra parameters are always allowed in C. I declare the function pointers with "..." (slightly different in C vs. C++). > > > The gcc backend passes static link in a register dedicated to it. > > - Jay > > On Nov 30, 2015, at 2:00 PM, Rodney Bates wrote: > >> Moreover, CM3's seemingly nice idea of making IR operators >> method calls makes it very awkward to do idiom recognition or >> state-dependent handling of general-purpose operators. > _______________________________________________ > M3commit mailing list > M3commit at elegosoft.com > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3commit > -- Rodney Bates rodney.m.bates at acm.org From jay.krell at cornell.edu Wed Dec 2 05:03:48 2015 From: jay.krell at cornell.edu (Jay) Date: Tue, 1 Dec 2015 21:03:48 -0700 Subject: [M3devel] [M3commit] [modula3/cm3] b3c18e: Rework indirect calls to possibly nested procedure... In-Reply-To: <565E003C.60104@lcwb.coop> References: <565cb8dc1ef05_532e3fd1219432c01066b@hookshot-fe5-cp1-prd.iad.github.net.mail> <565E003C.60104@lcwb.coop> Message-ID: <33C83013-53BA-47D1-A878-A7B81A9D23AD@gmail.com> Feel free to checkin a wishlist/todo. I feel that I have been through a fair amount & that most of the obstacles to change are actually imaginary. & most of the "difficulties" are "equivalent". That is, the build order and scripts are what they should be, & accommodate all concievable changes. IF the compiler depends on new language/runtime features then they must be first implemented, build it all, then depend on it. But this probably doesn't apply here. - Jay On Dec 1, 2015, at 1:17 PM, "Rodney M. Bates" wrote: > Yeah, I would like some changes to the IR too. But it is fairly painful. > Many places need to be changed, and I recall some kind of rebuild/bootstrap > problem too. I am collecting a list of things I would like, with the idea > of doing it all in one change. Some of my wishes predate my writing them > down, and I hope I can remember them too. Some of them are motivated by > debug information. > > On 12/01/2015 01:41 PM, Jay wrote: >> I suggest one or two changes to the IR. >> >> >> 1. An "official" in-memory representation of a complete unit or program. Modern systems can afford it. >> >> >> 2. More information with function calls. Likely combining parameters with calls. No more start/end. All parameters must be locals (possibly uplevel) or parameters or globals or temporaries, never expressions. This is likely the case already. >> >> >> And, aside, look what I do for C. I made it work somehow. I don't remember off hand but I did odd stuff also because of static links. Like maybe always passing one, even if null, as last parameter, because extra parameters are always allowed in C. I declare the function pointers with "..." (slightly different in C vs. C++). >> >> >> The gcc backend passes static link in a register dedicated to it. >> >> - Jay >> >> On Nov 30, 2015, at 2:00 PM, Rodney Bates wrote: >> >>> Moreover, CM3's seemingly nice idea of making IR operators >>> method calls makes it very awkward to do idiom recognition or >>> state-dependent handling of general-purpose operators. >> _______________________________________________ >> M3commit mailing list >> M3commit at elegosoft.com >> https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3commit > > -- > Rodney Bates > rodney.m.bates at acm.org > _______________________________________________ > M3commit mailing list > M3commit at elegosoft.com > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3commit From hendrik at topoi.pooq.com Thu Dec 3 00:30:09 2015 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Wed, 2 Dec 2015 18:30:09 -0500 Subject: [M3devel] addition of GPL stuff In-Reply-To: References: Message-ID: <20151202233009.GB19699@topoi.pooq.com> On Mon, Sep 14, 2015 at 06:14:52AM +0000, Jay K wrote: > Um, sorry to bring up such annoying matters, but maybe we should not be licensingnew files as GPL, assuming they aren't derived from GPL files? > e.g. the LLVM m3makfiles and Makefiles? > Thank you, - Jay To resurrect a post from ages gone by. We should be licencing everything GPL, assuming it's original, and not already constrained by SRC's license. If another license is appropriate, use that too. Make it dual licensed. Dual licencing works as possible: anyone gets to choose which of the licences they are going to use. So if your use is allowed by *any* of the listed licenses, it's OK. It's a way to achieve greater compatibility than could be obtained by any one of those licenses. In particular, the copyright owner (initially the author) could grant rights under both the GPL and the SRC licenses, to assure copatibility with both. THe LGPL might be better than GPL for freedom, and the MIT licence even better. Tht way, if ever a viable collection of Modula 3 code is licenced under GPL, that collection can be used with GPL code freely. -- hendrik > > > > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel From lists at darko.org Thu Dec 3 01:35:26 2015 From: lists at darko.org (Darko Volaric) Date: Wed, 2 Dec 2015 16:35:26 -0800 Subject: [M3devel] addition of GPL stuff In-Reply-To: <20151202233009.GB19699@topoi.pooq.com> References: <20151202233009.GB19699@topoi.pooq.com> Message-ID: What's the argument against placing contributions in the public domain? Licences are tedious. Even short ones require reading and understanding when you're using the code, and most people use many projects. Renouncing copyright is simple, flexible and no-one can copyright the work. Or am I missing some important legal wrinkle? Do contributors want to keep control of their code? On Wed, Dec 2, 2015 at 3:30 PM, Hendrik Boom wrote: > On Mon, Sep 14, 2015 at 06:14:52AM +0000, Jay K wrote: > > Um, sorry to bring up such annoying matters, but maybe we should not > be licensingnew files as GPL, assuming they aren't derived from GPL files? > > e.g. the LLVM m3makfiles and Makefiles? > > Thank you, - Jay > > To resurrect a post from ages gone by. > > We should be licencing everything GPL, assuming it's original, and not > already constrained by SRC's license. > > If another license is appropriate, use that too. Make it dual licensed. > Dual licencing works as possible: anyone gets to choose which of > the licences they are going to use. So if your use is allowed by *any* > of the listed licenses, it's OK. > > It's a way to achieve greater compatibility than could be obtained by > any one of those licenses. > > In particular, the copyright owner (initially the author) could grant > rights under both the GPL and the SRC licenses, to assure copatibility > with both. THe LGPL might be better than GPL for freedom, and the MIT > licence even better. > > Tht way, if ever a viable collection of Modula 3 code is licenced under > GPL, that collection can be used with GPL code freely. > > -- hendrik > > > > > > > > > > _______________________________________________ > > M3devel mailing list > > M3devel at elegosoft.com > > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel > > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Thu Dec 3 04:52:36 2015 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Wed, 2 Dec 2015 22:52:36 -0500 Subject: [M3devel] addition of GPL stuff In-Reply-To: References: <20151202233009.GB19699@topoi.pooq.com> Message-ID: <20151203035236.GA22525@topoi.pooq.com> On Wed, Dec 02, 2015 at 04:35:26PM -0800, Darko Volaric wrote: > What's the argument against placing contributions in the public domain? Public Domain would satisfy me adequately. If it were universal. However, there are partss of the world where public domain is not an accepted legal concept. That's why there is a creative Commons licence that is essentially equivalent to public domain. > Licences are tedious. Even short ones require reading and understanding > when you're using the code, and most people use many projects. > > Renouncing copyright is simple, flexible and no-one can copyright the work. Actually, they can as soon as they make changes. The original remains public, but they can claim rights over the modifications. > > Or am I missing some important legal wrinkle? Do contributors want to keep > control of their code? The legal wrinkle is that public domain is not everywhere recognised. I believe the Creative Commons website has something to say about this. --- hendrik > > On Wed, Dec 2, 2015 at 3:30 PM, Hendrik Boom wrote: > > > On Mon, Sep 14, 2015 at 06:14:52AM +0000, Jay K wrote: > > > Um, sorry to bring up such annoying matters, but maybe we should not > > be licensingnew files as GPL, assuming they aren't derived from GPL files? > > > e.g. the LLVM m3makfiles and Makefiles? > > > Thank you, - Jay > > > > To resurrect a post from ages gone by. > > > > We should be licencing everything GPL, assuming it's original, and not > > already constrained by SRC's license. > > > > If another license is appropriate, use that too. Make it dual licensed. > > Dual licencing works as possible: anyone gets to choose which of > > the licences they are going to use. So if your use is allowed by *any* > > of the listed licenses, it's OK. > > > > It's a way to achieve greater compatibility than could be obtained by > > any one of those licenses. > > > > In particular, the copyright owner (initially the author) could grant > > rights under both the GPL and the SRC licenses, to assure copatibility > > with both. THe LGPL might be better than GPL for freedom, and the MIT > > licence even better. > > > > Tht way, if ever a viable collection of Modula 3 code is licenced under > > GPL, that collection can be used with GPL code freely. > > > > -- hendrik > > > > > > > > > > > > > > > > _______________________________________________ > > > M3devel mailing list > > > M3devel at elegosoft.com > > > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel > > > > _______________________________________________ > > M3devel mailing list > > M3devel at elegosoft.com > > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel > > From microcode at zoho.com Thu Dec 3 08:36:11 2015 From: microcode at zoho.com (microcode at zoho.com) Date: Thu, 3 Dec 2015 07:36:11 +0000 Subject: [M3devel] addition of GPL stuff In-Reply-To: <20151202233009.GB19699@topoi.pooq.com> References: <20151202233009.GB19699@topoi.pooq.com> Message-ID: <20151203073611.GH3127@zoho.com> On Wed, Dec 02, 2015 at 06:30:09PM -0500, Hendrik Boom wrote: > On Mon, Sep 14, 2015 at 06:14:52AM +0000, Jay K wrote: > > Um, sorry to bring up such annoying matters, but maybe we should not > be licensingnew files as GPL, assuming they aren't derived from GPL files? > > e.g. the LLVM m3makfiles and Makefiles? > > Thank you, - Jay snip > Tht way, if ever a viable collection of Modula 3 code is licenced under > GPL, that collection can be used with GPL code freely. No. MIT and BSD licensed code can be used in any project. GPL poisons the product and is not compatible with free software licenses. I realize my opinion is irrelevant but I agree with Jay 1,000% on this. And it's an open mailing list, so... From hendrik at topoi.pooq.com Thu Dec 3 19:36:58 2015 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Thu, 3 Dec 2015 13:36:58 -0500 Subject: [M3devel] addition of GPL stuff In-Reply-To: <20151203073611.GH3127@zoho.com> References: <20151202233009.GB19699@topoi.pooq.com> <20151203073611.GH3127@zoho.com> Message-ID: <20151203183657.GA4527@topoi.pooq.com> On Thu, Dec 03, 2015 at 07:36:11AM +0000, microcode at zoho.com wrote: > On Wed, Dec 02, 2015 at 06:30:09PM -0500, Hendrik Boom wrote: > > On Mon, Sep 14, 2015 at 06:14:52AM +0000, Jay K wrote: > > > Um, sorry to bring up such annoying matters, but maybe we should not > > be licensingnew files as GPL, assuming they aren't derived from GPL files? > > > e.g. the LLVM m3makfiles and Makefiles? > > > Thank you, - Jay > > snip > > > Tht way, if ever a viable collection of Modula 3 code is licenced under > > GPL, that collection can be used with GPL code freely. > > No. MIT and BSD licensed code can be used in any project. GPL poisons the > product and is not compatible with free software licenses. Yes, MIT licence is good. And it doesn't conflict with the SRC licence, either so that should be good, too. And so is the BSD licence without the advertising clause. Apple went to town with this one when theyy build OS/X, so it's definitely nonrestrictive. > > I realize my opinion is irrelevant but I agree with Jay 1,000% on this. And > it's an open mailing list, so... > > > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel From jay.krell at cornell.edu Sat Dec 5 12:54:05 2015 From: jay.krell at cornell.edu (Jay K) Date: Sat, 5 Dec 2015 11:54:05 +0000 Subject: [M3devel] addition of GPL stuff In-Reply-To: <20151203183657.GA4527@topoi.pooq.com> References: , <20151202233009.GB19699@topoi.pooq.com>, <20151203073611.GH3127@zoho.com>, <20151203183657.GA4527@topoi.pooq.com> Message-ID: We shouldn't spend much time on this, but... The license that OpenBSD, NetBSD, FreeBSD use, that is what we should use. It is the same license. These are fairly large heavily used projects, and they copy code around amongst eachother, and commercial ventures fork and close the code, without attribution -- that is allowed. This is a license that lets anyone do just about anything, including take it as their own and profit. it is a short license.Shorter than this email. It does not require giving credit.Giving credit is nice, but exactly how/where/when? And how muchtime/energy must people spend to figure that out?The older BSD license required giving credit, and there was protest and the claused was dropped. it does not require giving back. Again, giving back is great, but requiring it is too much.What if someone wants to release something but we are all on vacation not answering email?They have to wait for us to respond to take their changes before they can ship them? The point of this license is to remove any barrier to reuse that is easy to remove.(ignoring quality and functionality of the code) One of the reasons OpenBSD rejects licenses is because more licenses requires more readingand possibly more lawyer time, more uncertainty, when there are already sufficient tried-and-truelicenses. I believe this is why they reject the Apache 2.0 license. What the GPL does is quite different. It basically makes you GPL anythingyou link the GPL code to. It maybe doesn't require giving back, or require giving credit,but it requires source be available to anyone that receives the binaries. You can sell the binaries,but you must do so including source (or a link to download the source).Most commercial ventures believe that this requirement makes it impossible to make money.You might get one sale, but then the source is out and anyone can duplicate the functionality.Others claim that "support" is an adequate business model. (If you are just sitting on the binaries all by yourself and don't give them to anyone, the GPL has no effect, youcan keep the source to yourself as well. People sometimes misunderstand this.) MIT license is probably about the same and probably second best. - Jay > Date: Thu, 3 Dec 2015 13:36:58 -0500 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] addition of GPL stuff > > On Thu, Dec 03, 2015 at 07:36:11AM +0000, microcode at zoho.com wrote: > > On Wed, Dec 02, 2015 at 06:30:09PM -0500, Hendrik Boom wrote: > > > On Mon, Sep 14, 2015 at 06:14:52AM +0000, Jay K wrote: > > > > Um, sorry to bring up such annoying matters, but maybe we should not > > > be licensingnew files as GPL, assuming they aren't derived from GPL files? > > > > e.g. the LLVM m3makfiles and Makefiles? > > > > Thank you, - Jay > > > > snip > > > > > Tht way, if ever a viable collection of Modula 3 code is licenced under > > > GPL, that collection can be used with GPL code freely. > > > > No. MIT and BSD licensed code can be used in any project. GPL poisons the > > product and is not compatible with free software licenses. > > Yes, MIT licence is good. And it doesn't conflict with the SRC > licence, either so that should be good, too. > > And so is the BSD licence without the advertising clause. > > Apple went to town with this one when theyy build OS/X, so it's > definitely nonrestrictive. > > > > > I realize my opinion is irrelevant but I agree with Jay 1,000% on this. And > > it's an open mailing list, so... > > > > > > _______________________________________________ > > M3devel mailing list > > M3devel at elegosoft.com > > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Sat Dec 5 23:15:20 2015 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sat, 5 Dec 2015 22:15:20 +0000 (UTC) Subject: [M3devel] addition of GPL stuff In-Reply-To: References: Message-ID: <1157844485.26117551.1449353720968.JavaMail.yahoo@mail.yahoo.com> Hey a little bit off topic, what about SRC reports, can we track down all the Green Book's (Systems programming with Modula-3) chapters and reformat them to make it public?I mean, I haven't seen anything of that quality in terms of intellectual strictness and so easy to read in any computer language book. Thanks in advance El S?bado 5 de diciembre de 2015 6:54, Jay K escribi?: #yiv5960026191 #yiv5960026191 --.yiv5960026191hmmessage P{margin:0px;padding:0px;}#yiv5960026191 body.yiv5960026191hmmessage{font-size:12pt;font-family:Calibri;}#yiv5960026191 We shouldn't spend much time on this, but... The license that OpenBSD, NetBSD, FreeBSD use, that is what we should use. It is the same license. These are fairly large heavily used projects, and they copy code around amongst eachother, and commercial ventures fork and close the code, without attribution -- that is allowed. This is a license that lets anyone do just about anything, including take it as their own and profit. it is a short license.Shorter than this email. It does not require giving credit.Giving credit is nice, but exactly how/where/when? And how muchtime/energy must people spend to figure that out?The older BSD license required giving credit, and there was protest and the claused was dropped. it does not require giving back. Again, giving back is great, but requiring it is too much.What if someone wants to release something but we are all on vacation not answering email?They have to wait for us to respond to take their changes before they can ship them? The point of this license is to remove any barrier to reuse that is easy to remove.(ignoring quality and functionality of the code) One of the reasons OpenBSD rejects licenses is because more licenses requires more readingand possibly more lawyer time, more uncertainty, when there are already sufficient tried-and-truelicenses. I believe this is why they reject the?Apache 2.0 license. What the GPL does is quite different. It basically makes you GPL anythingyou link the GPL code to. It maybe doesn't require giving back, or require giving credit,but it requires source be available to anyone that receives the binaries. You can sell the binaries,but you must do so including source (or a link to download the source).Most commercial ventures believe that this requirement makes it impossible to make money.You might get one sale, but then the source is out and anyone can duplicate the functionality.Others claim that "support" is an adequate business model. (If you are just sitting on the binaries all?by yourself and don't give them to anyone, the GPL has no effect, youcan keep the source to yourself as well.?People sometimes misunderstand this.) MIT license is probably about the same and probably second best. ?- Jay > Date: Thu, 3 Dec 2015 13:36:58 -0500 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] addition of GPL stuff > > On Thu, Dec 03, 2015 at 07:36:11AM +0000, microcode at zoho.com wrote: > > On Wed, Dec 02, 2015 at 06:30:09PM -0500, Hendrik Boom wrote: > > > On Mon, Sep 14, 2015 at 06:14:52AM +0000, Jay K wrote: > > > > Um, sorry to bring up such annoying matters, but maybe we should not > > > be licensingnew files as GPL, assuming they aren't derived from GPL files? > > > > e.g. the LLVM m3makfiles and Makefiles? > > > > Thank you, - Jay > > > > snip > > > > > Tht way, if ever a viable collection of Modula 3 code is licenced under > > > GPL, that collection can be used with GPL code freely. > > > > No. MIT and BSD licensed code can be used in any project. GPL poisons the > > product and is not compatible with free software licenses. > > Yes, MIT licence is good. And it doesn't conflict with the SRC > licence, either so that should be good, too. > > And so is the BSD licence without the advertising clause. > > Apple went to town with this one when theyy build OS/X, so it's > definitely nonrestrictive. > > > > > I realize my opinion is irrelevant but I agree with Jay 1,000% on this. And > > it's an open mailing list, so... > > > > > > _______________________________________________ > > M3devel mailing list > > M3devel at elegosoft.com > > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel _______________________________________________ M3devel mailing list M3devel at elegosoft.com https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Sun Dec 6 00:20:45 2015 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Sat, 5 Dec 2015 18:20:45 -0500 Subject: [M3devel] addition of GPL stuff In-Reply-To: <1157844485.26117551.1449353720968.JavaMail.yahoo@mail.yahoo.com> References: <1157844485.26117551.1449353720968.JavaMail.yahoo@mail.yahoo.com> Message-ID: <20151205232045.GA25815@topoi.pooq.com> On Sat, Dec 05, 2015 at 10:15:20PM +0000, Daniel Alejandro Benavides D. wrote: > Hey a little bit off topic, what about SRC reports, can we track down all the Green Book's (Systems programming with Modula-3) chapters and reformat them to make it public?I mean, I haven't seen anything of that quality in terms of intellectual strictness and so easy to read in any computer language book. > Thanks in advance Only the copyright holder can do that, unless it is in he public domain. -- hendrik From dabenavidesd at yahoo.es Sun Dec 6 00:47:56 2015 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sat, 5 Dec 2015 23:47:56 +0000 (UTC) Subject: [M3devel] addition of GPL stuff In-Reply-To: <20151205232045.GA25815@topoi.pooq.com> References: <20151205232045.GA25815@topoi.pooq.com> Message-ID: <1330494183.25980356.1449359276781.JavaMail.yahoo@mail.yahoo.com> Hello:I understand it can be a literally impossible to track down copyright holders as no Modula-3 sources are apart of any entity besides Elego (is this not a solution of the problem?). Respect of the RR, at some point in time, they start to be universally accessible (like 70 years) or so? Thanks in advance El S?bado 5 de diciembre de 2015 18:20, Hendrik Boom escribi?: On Sat, Dec 05, 2015 at 10:15:20PM +0000, Daniel Alejandro Benavides D. wrote: > Hey a little bit off topic, what about SRC reports, can we track down all the Green Book's (Systems programming with Modula-3) chapters and reformat them to make it public?I mean, I haven't seen anything of that quality in terms of intellectual strictness and so easy to read in any computer language book. > Thanks in advance Only the copyright holder can do that, unless it is in he public domain. -- hendrik _______________________________________________ M3devel mailing list M3devel at elegosoft.com https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sun Dec 6 01:07:40 2015 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 6 Dec 2015 01:07:40 +0100 Subject: [M3devel] addition of GPL stuff In-Reply-To: <1157844485.26117551.1449353720968.JavaMail.yahoo@mail.yahoo.com> References: <1157844485.26117551.1449353720968.JavaMail.yahoo@mail.yahoo.com> Message-ID: <20151206010740.a58ec527ca708a8dd33955f8@elegosoft.com> On Sat, 5 Dec 2015 22:15:20 +0000 (UTC) "Daniel Alejandro Benavides D." wrote: > Hey a little bit off topic, what about SRC reports, can we track down all the Green Book's (Systems programming with Modula-3) chapters and reformat them to make it public?I mean, I haven't seen anything of that quality in terms of intellectual strictness and so easy to read in any computer language book. The complete language definition, which is one part of the Green Book, is already online: http://www.opencm3.net/doc/reference/complete/html/Modula_3_Language_definitio.html Also a complete description of all the available interfaces http://www.opencm3.net/doc/help/interfaces.html and the quake reference: http://www.opencm3.net/doc/help/cm3/quake.html Alas, I haven't found an active site for some time that actually servers the SRC reports; they're not in the HP archive and gatekeeper seems to be gone forever. If anybody knows where to download them, I would appreciate a hint. 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 dabenavidesd at yahoo.es Sun Dec 6 01:28:34 2015 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sun, 6 Dec 2015 00:28:34 +0000 (UTC) Subject: [M3devel] addition of GPL stuff In-Reply-To: <20151206010740.a58ec527ca708a8dd33955f8@elegosoft.com> References: <20151206010740.a58ec527ca708a8dd33955f8@elegosoft.com> Message-ID: <1636697213.26135778.1449361714400.JavaMail.yahoo@mail.yahoo.com> Hi:yeah they are here:http://www.mirrorservice.org/sites/www.bitsavers.org/pdf/dec/tech_reports/ But unintendedly found Network Systems Laboratory ones: https://archive.org/stream/bitsavers_dectechrep_48346/NSL-NN-11_djvu.txt Thanks for point out this and in advance | ? | | ? | | ? | ? | ? | ? | ? | | Index of /sites/www.bitsavers.org/pdf/dec/tech_reportsIndex of /sites/www.bitsavers.org/pdf/dec/tech_reports/ Name Last modified Size | | | | Ver en www.mirrorservice.org | Vista previa por Yahoo | | | | ? | El S?bado 5 de diciembre de 2015 19:07, Olaf Wagner escribi?: On Sat, 5 Dec 2015 22:15:20 +0000 (UTC) "Daniel Alejandro Benavides D." wrote: > Hey a little bit off topic, what about SRC reports, can we track down all the Green Book's (Systems programming with Modula-3) chapters and reformat them to make it public?I mean, I haven't seen anything of that quality in terms of intellectual strictness and so easy to read in any computer language book. The complete language definition, which is one part of the Green Book, is already online: http://www.opencm3.net/doc/reference/complete/html/Modula_3_Language_definitio.html Also a complete description of all the available interfaces http://www.opencm3.net/doc/help/interfaces.html and the quake reference: http://www.opencm3.net/doc/help/cm3/quake.html Alas, I haven't found an active site for some time that actually servers the SRC reports; they're not in the HP archive and gatekeeper seems to be gone forever. If anybody knows where to download them, I would appreciate a hint. 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 Thu Dec 10 19:15:48 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 10 Dec 2015 12:15:48 -0600 Subject: [M3devel] M3CG loophole operator is not LOOPHOLE (but what?) Message-ID: <5669C154.90603@lcwb.coop> I have just discovered the hard way that the following comment, from M3CG_Ops.i3: loophole (from, two: ZType); (* s0.two := LOOPHOLE(s0.from, two) *) is not true. The front end can produce M3CG loophole ops in which the two types do not have the same size. For example, the front end passes a small exception argument to RaiseEx by value as CGType.Addr, whose size is native word size, and if the argument has a different stack size (e.g. REAL is 32-bit, even on a native 64-bit machine), then it first converts it using the M3CG loophole operator. Almost the same thing can happen for an explicit LOOPHOLE in M3 source code. On a 64-bit machine, compiling libm3/src/geometry/Transform.m3, M3 source code equivalent to: LOOPHOLE (REALvariable, BITS BITSIZE(REAL) FOR [-16_7fffffff-1 .. 16_7fffffff]) (translated by CastExpr.m3:286) produces almost the same M3CG loophole operator, because the stack size of the subrange is 64-bit, even though its memory size is 32. So the loophole comes out converting REAL to Int64. (Note that BITS has no effect, since the type is not used as a field or array element). Since loophole takes its operand off the abstract stack and puts its result back there, the stack size is the right one to use here, for both from-type and to-type. But what are the complete rules about loophole? Apparently some combinations really are bitcasts, but which ones? Exactly those where the sizes match? What is the actual conversion for other combinations? 32-bit REAL to 64-bit integer or address is particularly unclear. If anybody has any knowledge about this, it would be helpful. There is quite a bit of code to vet, otherwise. 15 different places in the front end generate loophole. -- Rodney Bates rodney.m.bates at acm.org From jay.krell at cornell.edu Fri Dec 11 07:53:08 2015 From: jay.krell at cornell.edu (Jay K) Date: Fri, 11 Dec 2015 06:53:08 +0000 Subject: [M3devel] M3CG loophole operator is not LOOPHOLE (but what?) In-Reply-To: <5669C154.90603@lcwb.coop> References: <5669C154.90603@lcwb.coop> Message-ID: I don't recall...but it doesn't look like M3C handles this specially,but indeed m3cc has special logic for loophole and floats. Ugh.It makes a temporary. I'll have to experiment. The right thing to do, really, is take the address of a float, loopholethat into an address of another type, and dereference that.Not in the backend, but in the Modula-3 code. Never to loophole to or from a float value.And hardly ever loophole values at all.Loopholing between pointers and same-sized integers, ok.Or pointers and other pointers, ok. I don't know if it called loophole, but between varying sized/signedness integers also ok.(really that is chop or extend) We should considering changing m3front to honor these rules.That is how you write semi-portable C to dissect floats.Or via unions. There are intrinsics in some compilers for doing better.Visual C++ for non-x86 platforsm (ARM and CE) has it right, with stuff like_CopyDoubleToInt64, _CopyInt64ToDouble, _CopyInt32ToFloat, CopyFloatToInt32.You can argue the names, but really those are the exact 4 intrinsics you want.Leaving it to the compiler to know if it can do a register move or must go through memory.But the portable way requires going through memory. And, really, put all the float dissection into C anyway. - Jay > Date: Thu, 10 Dec 2015 12:15:48 -0600 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: [M3devel] M3CG loophole operator is not LOOPHOLE (but what?) > > I have just discovered the hard way that the following comment, from M3CG_Ops.i3: > > loophole (from, two: ZType); > (* s0.two := LOOPHOLE(s0.from, two) *) > > is not true. > > The front end can produce M3CG loophole ops in which the two types do not have > the same size. For example, the front end passes a small exception argument > to RaiseEx by value as CGType.Addr, whose size is native word size, and if > the argument has a different stack size (e.g. REAL is 32-bit, even on a native > 64-bit machine), then it first converts it using the M3CG loophole operator. > > Almost the same thing can happen for an explicit LOOPHOLE in M3 source code. On a > 64-bit machine, compiling libm3/src/geometry/Transform.m3, M3 source code > equivalent to: > > LOOPHOLE (REALvariable, BITS BITSIZE(REAL) FOR [-16_7fffffff-1 .. 16_7fffffff]) > > (translated by CastExpr.m3:286) produces almost the same M3CG loophole operator, > because the stack size of the subrange is 64-bit, even though its memory size is > 32. So the loophole comes out converting REAL to Int64. (Note that BITS has no > effect, since the type is not used as a field or array element). > > Since loophole takes its operand off the abstract stack and puts its result back > there, the stack size is the right one to use here, for both from-type and to-type. > > But what are the complete rules about loophole? Apparently some combinations > really are bitcasts, but which ones? Exactly those where the sizes match? What > is the actual conversion for other combinations? 32-bit REAL to 64-bit integer > or address is particularly unclear. > > If anybody has any knowledge about this, it would be helpful. There is quite a > bit of code to vet, otherwise. 15 different places in the front end generate > loophole. > > -- > Rodney Bates > rodney.m.bates at acm.org > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 14 03:20:55 2015 From: jay.krell at cornell.edu (Jay) Date: Sun, 13 Dec 2015 18:20:55 -0800 Subject: [M3devel] M3CG loophole operator is not LOOPHOLE (but what?) In-Reply-To: References: <5669C154.90603@lcwb.coop> Message-ID: I know, but this pattern is pretty rare. - Jay On Dec 13, 2015, at 1:46 AM, Antony Hosking wrote: > Excepting that in some cases taking the address may force the value into memory, when it could have stayed in a register. > The intent is to allow the backend to avoid that. > >> On 11 Dec 2015, at 5:53 PM, Jay K wrote: >> >> The right thing to do, really, is take the address of a float, loophole >> that into an address of another type, and dereference that. >> Not in the backend, but in the Modula-3 code. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Mon Dec 14 03:40:46 2015 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Mon, 14 Dec 2015 02:40:46 +0000 (UTC) Subject: [M3devel] M3CG loophole operator is not LOOPHOLE (but what?) In-Reply-To: References: <5669C154.90603@lcwb.coop> Message-ID: <1615931268.1036686.1450060846633.JavaMail.yahoo@mail.yahoo.com> Hello:Excuse me if is wrong to say, but doesn't the specification of Modula-3 explicit about how the UNSAFE stuff is implementation-dependent, that is to say; "it's your decision how to implement it".Thanks in advance El Domingo 13 de diciembre de 2015 21:20, Jay escribi?: I know, but this pattern is pretty rare.? ?- Jay On Dec 13, 2015, at 1:46 AM, Antony Hosking wrote: Excepting that in some cases taking the address may force the value into memory, when it could have stayed in a register.The intent is to allow the backend to avoid that. On 11 Dec 2015, at 5:53 PM, Jay K wrote: The right thing to do, really, is take the address of a float, loopholethat into an address of another type, and dereference that.Not in the backend, but in the Modula-3 code. _______________________________________________ M3devel mailing list M3devel at elegosoft.com https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Mon Dec 14 04:05:18 2015 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Mon, 14 Dec 2015 03:05:18 +0000 (UTC) Subject: [M3devel] M3CG loophole operator is not LOOPHOLE (but what?) In-Reply-To: <300C917B-B104-469E-8885-99CC5D1D964F@purdue.edu> References: <5669C154.90603@lcwb.coop> <1615931268.1036686.1450060846633.JavaMail.yahoo@mail.yahoo.com> <300C917B-B104-469E-8885-99CC5D1D964F@purdue.edu> Message-ID: <832820227.1031770.1450062318650.JavaMail.yahoo@mail.yahoo.com> Hi:exactly, if the bit pattern is unequal in two implementations, surely you will be having 2 different results El Domingo 13 de diciembre de 2015 21:51, "Hosking, Antony L" escribi?: From the language definition: An?unchecked type transfer operation has the form: ? ? LOOPHOLE(e, T) where?e?is an expression whose type is not an open array type and?T?is a type. It denotes?e's bit pattern?interpreted as a variable or value of type?T. It is a designator if?e?is, and is writable if?e?is. An unchecked?runtime error can occur if?e's bit pattern is not a legal?T, or if?e?is a designator and some legal bit pattern for?T?is not legal for?e. If?T?is not an open array type,?BITSIZE(e)?must equal?BITSIZE(T). If?T?is an open array type, its element type must not be an open array?type, and?e's bit pattern is interpreted as an array whose length is?BITSIZE(e)?divided by?BITSIZE(the element type of?T). The division?must come out even. On 14 Dec 2015, at 1:40 PM, Daniel Alejandro Benavides D. wrote: Hello: Excuse me if is wrong to say, but doesn't the specification of Modula-3 explicit about how the?UNSAFE stuff is implementation-dependent, that is to say; "it's your decision how to implement?it". Thanks in advance El Domingo 13 de diciembre de 2015 21:20, Jay escribi?: I know, but this pattern is pretty rare.? ?- Jay On Dec 13, 2015, at 1:46 AM, Antony Hosking wrote: Excepting that in some cases taking the address may force the value into memory, when it?could have stayed in a register. The intent is to allow the backend to avoid that. On 11 Dec 2015, at 5:53 PM, Jay K wrote: The right thing to do, really, is take the address of a float, loophole that into an address of another type, and dereference that. Not in the backend, but in the Modula-3 code. _______________________________________________ M3devel mailing list M3devel at elegosoft.com https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Mon Dec 14 04:19:32 2015 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Mon, 14 Dec 2015 03:19:32 +0000 (UTC) Subject: [M3devel] M3CG loophole operator is not LOOPHOLE (but what?) In-Reply-To: References: <5669C154.90603@lcwb.coop> <1615931268.1036686.1450060846633.JavaMail.yahoo@mail.yahoo.com> <300C917B-B104-469E-8885-99CC5D1D964F@purdue.edu> <832820227.1031770.1450062318650.JavaMail.yahoo@mail.yahoo.com> Message-ID: <2041142346.1036456.1450063172587.JavaMail.yahoo@mail.yahoo.com> Hi:but isn't the bit pattern, the data layout, what it makes the difference Anthony? Thanks in advance El Domingo 13 de diciembre de 2015 22:14, "Hosking, Antony L" escribi?: Bits are bits. ?It is implementation-dependent because bits one machine will be different on another. ?My point was that the bit sizes are expected to be the same (except when T is an open array, in which case the bits form the payload of the open array, with the size constructed accordingly). On 14 Dec 2015, at 2:05 PM, Daniel Alejandro Benavides D. wrote: Hi:exactly, if the bit pattern is unequal in two implementations, surely you will be having 2 different results El Domingo 13 de diciembre de 2015 21:51, "Hosking, Antony L" escribi?: >From the language definition: An?unchecked type transfer operation has the form: ? ? LOOPHOLE(e, T) where?e?is an expression whose type is not an open array type and?T?is a type. It denotes?e's bit pattern?interpreted as a variable or value of type?T. It is a designator if?e?is, and is writable if?e?is. An unchecked?runtime error can occur if?e's bit pattern is not a legal?T, or if?e?is a designator and some legal bit pattern for?T?is not legal for?e. If?T?is not an open array type,?BITSIZE(e)?must equal?BITSIZE(T). If?T?is an open array type, its element type must not be an open array?type, and?e's bit pattern is interpreted as an array whose length is?BITSIZE(e)?divided by?BITSIZE(the element type of?T). The division?must come out even. On 14 Dec 2015, at 1:40 PM, Daniel Alejandro Benavides D. wrote: Hello: Excuse me if is wrong to say, but doesn't the specification of Modula-3 explicit about how the?UNSAFE stuff is implementation-dependent, that is to say; "it's your decision how to implement?it". Thanks in advance El Domingo 13 de diciembre de 2015 21:20, Jay escribi?: I know, but this pattern is pretty rare.? ?- Jay On Dec 13, 2015, at 1:46 AM, Antony Hosking wrote: Excepting that in some cases taking the address may force the value into memory, when it?could have stayed in a register. The intent is to allow the backend to avoid that. On 11 Dec 2015, at 5:53 PM, Jay K wrote: The right thing to do, really, is take the address of a float, loophole that into an address of another type, and dereference that. Not in the backend, but in the Modula-3 code. _______________________________________________ M3devel mailing list M3devel at elegosoft.com https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Mon Dec 14 04:30:47 2015 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Mon, 14 Dec 2015 03:30:47 +0000 (UTC) Subject: [M3devel] M3CG loophole operator is not LOOPHOLE (but what?) In-Reply-To: <2041142346.1036456.1450063172587.JavaMail.yahoo@mail.yahoo.com> References: <5669C154.90603@lcwb.coop> <1615931268.1036686.1450060846633.JavaMail.yahoo@mail.yahoo.com> <300C917B-B104-469E-8885-99CC5D1D964F@purdue.edu> <832820227.1031770.1450062318650.JavaMail.yahoo@mail.yahoo.com> <2041142346.1036456.1450063172587.JavaMail.yahoo@mail.yahoo.com> Message-ID: <1714007729.1032434.1450063847030.JavaMail.yahoo@mail.yahoo.com> Hi:You know m3middle uses unsafe stuff, probably as Rodney points out m3front too, it doesn't have the correct implementation (as in m3middle) because it worked in another architecture, but not in here. That's why these modules need different treatment to care after release new versions.Thanks in advance El Domingo 13 de diciembre de 2015 22:19, Daniel Alejandro Benavides D. escribi?: Hi:but isn't the bit pattern, the data layout, what it makes the difference Anthony? Thanks in advance El Domingo 13 de diciembre de 2015 22:14, "Hosking, Antony L" escribi?: Bits are bits. ?It is implementation-dependent because bits one machine will be different on another. ?My point was that the bit sizes are expected to be the same (except when T is an open array, in which case the bits form the payload of the open array, with the size constructed accordingly). On 14 Dec 2015, at 2:05 PM, Daniel Alejandro Benavides D. wrote: Hi:exactly, if the bit pattern is unequal in two implementations, surely you will be having 2 different results El Domingo 13 de diciembre de 2015 21:51, "Hosking, Antony L" escribi?: >From the language definition: An?unchecked type transfer operation has the form: ? ? LOOPHOLE(e, T) where?e?is an expression whose type is not an open array type and?T?is a type. It denotes?e's bit pattern?interpreted as a variable or value of type?T. It is a designator if?e?is, and is writable if?e?is. An unchecked?runtime error can occur if?e's bit pattern is not a legal?T, or if?e?is a designator and some legal bit pattern for?T?is not legal for?e. If?T?is not an open array type,?BITSIZE(e)?must equal?BITSIZE(T). If?T?is an open array type, its element type must not be an open array?type, and?e's bit pattern is interpreted as an array whose length is?BITSIZE(e)?divided by?BITSIZE(the element type of?T). The division?must come out even. On 14 Dec 2015, at 1:40 PM, Daniel Alejandro Benavides D. wrote: Hello: Excuse me if is wrong to say, but doesn't the specification of Modula-3 explicit about how the?UNSAFE stuff is implementation-dependent, that is to say; "it's your decision how to implement?it". Thanks in advance El Domingo 13 de diciembre de 2015 21:20, Jay escribi?: I know, but this pattern is pretty rare.? ?- Jay On Dec 13, 2015, at 1:46 AM, Antony Hosking wrote: Excepting that in some cases taking the address may force the value into memory, when it?could have stayed in a register. The intent is to allow the backend to avoid that. On 11 Dec 2015, at 5:53 PM, Jay K wrote: The right thing to do, really, is take the address of a float, loophole that into an address of another type, and dereference that. Not in the backend, but in the Modula-3 code. _______________________________________________ M3devel mailing list M3devel at elegosoft.com https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel _______________________________________________ M3devel mailing list M3devel at elegosoft.com https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Mon Dec 14 14:30:58 2015 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Mon, 14 Dec 2015 13:30:58 +0000 (UTC) Subject: [M3devel] M3CG loophole operator is not LOOPHOLE (but what?) In-Reply-To: References: <5669C154.90603@lcwb.coop> <1615931268.1036686.1450060846633.JavaMail.yahoo@mail.yahoo.com> <300C917B-B104-469E-8885-99CC5D1D964F@purdue.edu> <832820227.1031770.1450062318650.JavaMail.yahoo@mail.yahoo.com> <2041142346.1036456.1450063172587.JavaMail.yahoo@mail.yahoo.com> <1714007729.1032434.1450063847030.JavaMail.yahoo@mail.yahoo.com> Message-ID: <554364982.1425193.1450099858596.JavaMail.yahoo@mail.yahoo.com> Hi:the difference between two types isn't bitsize, but structure or brand. Similarly, the cast between to types is possible by its bitpattern not by its bitsize. The implementation has the authority to adjust their sizes I believe (because it's implementation dependent). Antony m3devel isn't getting your mails in December archive, and here I have been struggling to read it -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at darko.org Wed Dec 16 16:47:49 2015 From: lists at darko.org (Darko Volaric) Date: Wed, 16 Dec 2015 16:47:49 +0100 Subject: [M3devel] Missing GitHub commits in M3commit Message-ID: It seems that Peter's commits on GitHub are not showing up in the commit list. I'm guessing that this is due to the "send from author" option on GitHub plus Peter's GitHub email not being the one subscribed to the list. Can we change it so that the "send from author option" is disabled and subscribe the GitHub notification email address to the list? This would save potentially having to fix this problem for each contributor. - Darko -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Wed Dec 16 19:01:27 2015 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Wed, 16 Dec 2015 12:01:27 -0600 Subject: [M3devel] M3CG loophole operator is not LOOPHOLE (but what?) In-Reply-To: <1615931268.1036686.1450060846633.JavaMail.yahoo@mail.yahoo.com> References: <5669C154.90603@lcwb.coop> <1615931268.1036686.1450060846633.JavaMail.yahoo@mail.yahoo.com> Message-ID: <5671A6F7.6040805@lcwb.coop> The issue I raised is not with the M3 LOOPHOLE builtin function. The compiler currently implements it correctly, according to the language definition, as Tony quoted. The front end verifies the size equality, as required by the language, then emits an intermediate "loophole" operator, which will be same size, and thus well-defined as equivalent to LOOPHOLE. (And also llvm bitcast, which is now being used to translate the loophole operator in this case.) My issue is that there are 13 other places the front-end emits an internally generated "loophole", and these (almost?) all can do so with unequal sizes. Moreover, what should be done with the unequal sizes varies from place to place. It is possible that the "loophole" operator can be defined to do what is correct in every case by a conditional rule based on the two types. I need to do another pass through them to be sure. This may be the quickest way to get the llvm backend working, but I think it is not good design. It would be carefully tailored to just a specific set of uses of "loophole", instead of making a reasonable abstraction out of" loophole". It would be rather fragile and involve a lot of analysis on the full Cartesian product of both supplier and client side cases of "loophole" to define and verify. The best way, IMO, is to fix each "loophole"-generating site to use other operators, as appropriate. It is at these sites that it is known what should be done in each case. I suspect existing intermediate operators "widen", "insert_mn" and "extract_mn" are sufficient. Again, another pass through the cases is indicated. The only pragmatic drawback to this is that this requires considerable care and retesting to avoid breakage of existing behavior. At worst, it risks inability to bootstrap the compiler. I would prefer one change at a time, each tested by reboostrapping twice. On 12/13/2015 08:40 PM, Daniel Alejandro Benavides D. wrote: > Hello: > Excuse me if is wrong to say, but doesn't the specification of Modula-3 explicit about how the UNSAFE stuff is implementation-dependent, that is to say; "it's your decision how to implement it". > Thanks in advance > > > > El Domingo 13 de diciembre de 2015 21:20, Jay escribi?: > > > I know, but this pattern is pretty rare. > > - Jay > > On Dec 13, 2015, at 1:46 AM, Antony Hosking > wrote: > >> Excepting that in some cases taking the address may force the value into memory, when it could have stayed in a register. >> The intent is to allow the backend to avoid that. >> >>> On 11 Dec 2015, at 5:53 PM, Jay K > wrote: >>> >>> The right thing to do, really, is take the address of a float, loophole >>> that into an address of another type, and dereference that. >>> Not in the backend, but in the Modula-3 code. >>> >> > > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel > > > > > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel > -- Rodney Bates rodney.m.bates at acm.org From lists at darko.org Thu Dec 17 08:55:19 2015 From: lists at darko.org (Darko Volaric) Date: Thu, 17 Dec 2015 08:55:19 +0100 Subject: [M3devel] Missing GitHub commits in M3commit In-Reply-To: References: Message-ID: If there are no objections in the next few days, I'll make the required changes. On Wed, Dec 16, 2015 at 4:47 PM, Darko Volaric wrote: > It seems that Peter's commits on GitHub are not showing up in the commit > list. I'm guessing that this is due to the "send from author" option on > GitHub plus Peter's GitHub email not being the one subscribed to the list. > > Can we change it so that the "send from author option" is disabled and > subscribe the GitHub notification email address to the list? This would > save potentially having to fix this problem for each contributor. > > - Darko > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Mon Dec 21 04:18:17 2015 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Mon, 21 Dec 2015 03:18:17 +0000 (UTC) Subject: [M3devel] M3CG loophole operator is not LOOPHOLE (but what?) In-Reply-To: <5671A6F7.6040805@lcwb.coop> References: <5669C154.90603@lcwb.coop> <1615931268.1036686.1450060846633.JavaMail.yahoo@mail.yahoo.com> <5671A6F7.6040805@lcwb.coop> Message-ID: <297203610.2445107.1450667897642.JavaMail.yahoo@mail.yahoo.com> Hi all: I don't like to repeat nor answer myself, but for the benefit of the discussion lets put it as in the below comment UNSAFE LOOPHOLE alternative VIEW in SPIN OS [1]:A couple of years later, there was an OS project - called, I think, SPIN - that built the entire OS in Modula-3. They used only a tiny amount of UNSAFE code. One area that's often full of bit-twiddling and type munging is network code, where you somehow need to convert a bag-of-bytes into some typed object. The SPIN team added an interesting primitive: "Here's a bag-of-bytes with the same size as an object of type X. View it as an object of type X." This was legal only if every field in X, recursively, had a type for which any bit pattern was legal. (I'd guess - but don't know - that you could have enum type values, with the compiler inserting a check that what was in the buffer as a enumerated value was actually legal. It may have done this for some other types as well - e.g., there was a CARDINAL type which was a subset of INTEGER and consisted only of the non-negative values.)Which inadvertently is the Modula-3 language definition but downsized in terms of UNSAFE operations for normal safety, which only lefts pointer arithmetic and DISPOSE memory management for UNSAFE operations. Now, I wonder given that this is allowed to be safe in SPIN, what is the "UNSAFE" part of casting in Modula-3.I Do rememeber viewing a videotape lecture of James Donahue, and speakign of UNSAFE operations, he said that they were very careful in selecting that as UNSAFE and the other operations. [1][En l?nea]. Disponible en: https://www.marc.info/?l=cryptography&m=139784275512662&q=raw. [Accedido: 21-dic-2015]. Thanks in advance El Mi?rcoles 16 de diciembre de 2015 13:02, Rodney M. Bates escribi?: The issue I raised is not with the M3 LOOPHOLE builtin function.? The compiler currently implements it correctly, according to the language definition, as Tony quoted.? The front end verifies the size equality, as required by the language, then emits an intermediate "loophole" operator, which will be same size, and thus well-defined as equivalent to LOOPHOLE.? (And also llvm bitcast, which is now being used to translate the loophole operator in this case.) My issue is that there are 13 other places the front-end emits an internally generated "loophole", and these (almost?) all can do so with unequal sizes. Moreover, what should be done with the unequal sizes varies from place to place. It is possible that the "loophole" operator can be defined to do what is correct in every case by a conditional rule based on the two types.? I need to do another pass through them to be sure.? This may be the quickest way to get the llvm backend working, but I think it is not good design. It would be carefully tailored to just a specific set of uses of "loophole", instead of making a reasonable abstraction out of" loophole".? It would be rather fragile and involve a lot of analysis on the full Cartesian product of both supplier and client side cases of "loophole" to define and verify. The best way, IMO, is to fix each "loophole"-generating site to use other operators, as appropriate.? It is at these sites that it is known what should be done in each case.? I suspect existing intermediate operators "widen", "insert_mn" and "extract_mn" are sufficient.? Again, another pass through the cases is indicated.? The only pragmatic drawback to this is that this requires considerable care and retesting to avoid breakage of existing behavior.? At worst, it risks inability to bootstrap the compiler. I would prefer one change at a time, each tested by reboostrapping twice. On 12/13/2015 08:40 PM, Daniel Alejandro Benavides D. wrote: > Hello: > Excuse me if is wrong to say, but doesn't the specification of Modula-3 explicit about how the UNSAFE stuff is implementation-dependent, that is to say; "it's your decision how to implement it". > Thanks in advance > > > > El Domingo 13 de diciembre de 2015 21:20, Jay escribi?: > > > I know, but this pattern is pretty rare. > >? - Jay > > On Dec 13, 2015, at 1:46 AM, Antony Hosking > wrote: > >> Excepting that in some cases taking the address may force the value into memory, when it could have stayed in a register. >> The intent is to allow the backend to avoid that. >> >>> On 11 Dec 2015, at 5:53 PM, Jay K > wrote: >>> >>> The right thing to do, really, is take the address of a float, loophole >>> that into an address of another type, and dereference that. >>> Not in the backend, but in the Modula-3 code. >>> >> > > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel > > > > > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel > -- Rodney Bates rodney.m.bates at acm.org _______________________________________________ M3devel mailing list M3devel at elegosoft.com https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Dec 27 18:42:52 2015 From: jay.krell at cornell.edu (Jay K) Date: Sun, 27 Dec 2015 17:42:52 +0000 Subject: [M3devel] binary distribution incompatibility with very old C runtime Message-ID: For the record.. If you try to build the current source with the 5.8.6 release.. or rather, if you try to do anything with 5.8.6, and have a particularly old C/C++ toolset, like over 10 years old, on Windows, you get: m3core.lib.sa(ThreadWin32C.obj) : error LNK2019: unresolved external symbol __wassert referenced in function _ThreadWin32__ProcessStopped m3core.lib.sa(dtoa.obj) : error LNK2019: unresolved external symbol __ftol2_sse referenced in function _m3_strtod The C compiler and runtime change a surprising much through the years. Merely using assert or floating point to integer converson via casting, with a new compiler, does not work with older runtimes. We can do better such as either: 1) Generate all C, so the binary distribution matters less. 2) This is using static linking of m3core for bootstrapping. Deliberately not just because cm3 always does that, but also as a policy for supposed higher/easier compatibility with older releases. Perhaps that is a mistake. For today I'll just install a newer compiler. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Dec 29 07:55:13 2015 From: jay.krell at cornell.edu (Jay K) Date: Tue, 29 Dec 2015 06:55:13 +0000 Subject: [M3devel] NT386 and alloca/jmpbuf change Message-ID: fyi, it looks like I didn't finish the NT386 side of this. I'm working on it "now". - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Dec 30 11:07:00 2015 From: jay.krell at cornell.edu (Jay K) Date: Wed, 30 Dec 2015 10:07:00 +0000 Subject: [M3devel] Add support for real time threads breaks on Mac In-Reply-To: References: , Message-ID: https://github.com/modula3/cm3/commit/af5b2314a8a7ea76d04dbedcb51dee56ab347c51 Add support for real time threads Fails to compile for me on MacOSX. Can we undo it? Or #ifndef __APPLE__ out some parts? ../src/thread/PTHREAD/ThreadPThreadC.c:711:58: error: unknown type name 'cpu_set_t' ThreadPThread__add_core_to_cpuset(int core_id, int size, cpu_set_t *cpuset) Maybe can be implemented using Apple-specific code? What systems does it work on? I'll go off and read.. Thank you, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Dec 30 11:12:50 2015 From: jay.krell at cornell.edu (Jay K) Date: Wed, 30 Dec 2015 10:12:50 +0000 Subject: [M3devel] Add support for real time threads breaks on Mac In-Reply-To: References: , , , Message-ID: I suspect this only works on Linux and will fail on everything else: MacOSX, NetBSD, FreeBSD, OpenBSD, Solaris, Cygwin, Interix and the hypothetical AIX, Irix, HP-UX, VMS, etc. ?- Jay ________________________________ > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com; peter.mckinna at gmail.com > Date: Wed, 30 Dec 2015 10:07:00 +0000 > Subject: [M3devel] Add support for real time threads breaks on Mac > > https://github.com/modula3/cm3/commit/af5b2314a8a7ea76d04dbedcb51dee56ab347c51 > Add support for real time threads Fails to compile for me on MacOSX. > Can we undo it? Or #ifndef __APPLE__ out some parts? > ../src/thread/PTHREAD/ThreadPThreadC.c:711:58: error: unknown type name > 'cpu_set_t' ThreadPThread__add_core_to_cpuset(int core_id, int size, > cpu_set_t *cpuset) Maybe can be implemented using Apple-specific code? > What systems does it work on? I'll go off and read.. Thank you, - Jay > > _______________________________________________ M3devel mailing list > M3devel at elegosoft.com > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel