From rodney.bates at wichita.edu Fri Feb 1 15:33:43 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Fri, 01 Feb 2008 08:33:43 -0600 Subject: [M3devel] [Fwd: Sanity check request regarding CT arithmetic] In-Reply-To: <338F5FD0-A818-4792-A583-A17B72EF956D@cs.purdue.edu> References: <47A1F5BF.3070201@wichita.edu> <338F5FD0-A818-4792-A583-A17B72EF956D@cs.purdue.edu> Message-ID: <47A32DC7.5080909@wichita.edu> Ah, and this is a systematic way of ensuring the precondition a.n=b.n always holds. Does the MIN function hint at someday generalizing to not require this condition? That would be tidy, but seems like an awful lot of work, if it is never used. Tony Hosking wrote: > Hi Rodney, > > Yes, you are missing one crucial thing. Namely, that the front-end > compiler *carefully* uses these target integer simulations only with > values that are *explicitly* the same length. LONGINT and INTEGER are > different types. INTEGER is the *representation* type for all values > 32 bits or less. LONGINT is the representation type for only LONGINT > values. You cannot mix LONGINT with INTEGER in source code > expressions. They need to be converted explicitly using ORD/VAL. > Indeed, you are right that the interfaces should document that behavior > explicitly, or alternatively, perhaps the implementations should > <*ASSERT a.n=b.n*>. The change from the way PM3 does things was > necessary for the introduction of LONGINT. > > Hope this helps and sorry for the imprecision of documentation. > > On Jan 31, 2008, at 11:22 AM, Rodney M. Bates wrote: > >> Whenever I run across something this unbelievable, I figure I must >> be missing something. Can anybody tell me what? >> >> While working on making Pickles work on LONGINT, I have noted the >> following code snippets for doing target arithmetic at compile time: >> >> From m3-sys/m3middle/src/Target.i3: >> >> (* The bits of a target INTEGER (in 2's complement) are stored in >> an array of small host values, with the low order bits in the first >> element of the array. *) >> >> TYPE >> Int = (* OPAQUE *) RECORD >> n: CARDINAL; (* only bytes [0..n-1] contain valid bits *) >> x := IBytes{0,..}; (* default is Zero *) >> END; >> IBytes = ARRAY [0..7] OF IByte; >> IByte = BITS 8 FOR [0..16_ff]; >> >> From m3-sys/m3middle/src/TWord.m3: >> >> PROCEDURE Subtract (READONLY a, b: Int; VAR r: Int) = >> VAR borrow := 0; n := MIN (a.n, b.n); >> BEGIN >> <*ASSERT n # 0*> >> r.n := n; >> FOR i := 0 TO n-1 DO >> borrow := a.x[i] - b.x[i] - borrow; >> r.x[i] := Word.And (borrow, Mask); >> borrow := Word.And (RShift (borrow, BITSIZE (IByte)), 1); >> END; >> END Subtract; >> >> Unless the two values have equal numbers of bytes, Subtract just >> throws away the high bytes of the longer operand. It looks like >> pretty much all the CT target arithmetic in TWord.m3 and TInt.m3 >> does this. >> >> It seems just about inconceivable that the arithmetic could be this >> broken and not have created many impossible-to-ignore bugs. SRC >> and pm3 do it differently. They have a single global variable that >> gives the used size of all CT target values. >> >> The only possible explanation I can think of is that the cm3 compiler >> happens never to pass two Target.Int values with different values of n. >> The relevant declarations give no hint of such a counter-intuitive >> requirement. If this is an essential precondition, it should be >> documented in the interfaces. >> >> -- >> ------------------------------------------------------------- >> Rodney M. Bates, retired assistant professor >> Dept. of Computer Science, Wichita State University >> Wichita, KS 67260-0083 >> 316-978-3922 >> rodney.bates at wichita.edu >> >> > > -- ------------------------------------------------------------- Rodney M. Bates, retired assistant professor Dept. of Computer Science, Wichita State University Wichita, KS 67260-0083 316-978-3922 rodney.bates at wichita.edu From hosking at cs.purdue.edu Fri Feb 1 20:57:15 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 1 Feb 2008 14:57:15 -0500 Subject: [M3devel] [Fwd: Sanity check request regarding CT arithmetic] In-Reply-To: <47A32DC7.5080909@wichita.edu> References: <47A1F5BF.3070201@wichita.edu> <338F5FD0-A818-4792-A583-A17B72EF956D@cs.purdue.edu> <47A32DC7.5080909@wichita.edu> Message-ID: <02DFFA0A-3768-413C-8D84-0354BC9CB08A@cs.purdue.edu> On Feb 1, 2008, at 9:33 AM, Rodney M. Bates wrote: > Ah, and this is a systematic way of ensuring the precondition > a.n=b.n always holds. Does the MIN function hint at someday > generalizing to not require this condition? Yes, that's the general idea. > That would be tidy, > but seems like an awful lot of work, if it is never used. Yeah, I played around with this a great deal and decided it wasn't worth the effort. > > Tony Hosking wrote: >> Hi Rodney, >> Yes, you are missing one crucial thing. Namely, that the front- >> end compiler *carefully* uses these target integer simulations >> only with values that are *explicitly* the same length. LONGINT >> and INTEGER are different types. INTEGER is the *representation* >> type for all values 32 bits or less. LONGINT is the >> representation type for only LONGINT values. You cannot mix >> LONGINT with INTEGER in source code expressions. They need to be >> converted explicitly using ORD/VAL. Indeed, you are right that >> the interfaces should document that behavior explicitly, or >> alternatively, perhaps the implementations should <*ASSERT >> a.n=b.n*>. The change from the way PM3 does things was necessary >> for the introduction of LONGINT. >> Hope this helps and sorry for the imprecision of documentation. >> On Jan 31, 2008, at 11:22 AM, Rodney M. Bates wrote: >>> Whenever I run across something this unbelievable, I figure I must >>> be missing something. Can anybody tell me what? >>> >>> While working on making Pickles work on LONGINT, I have noted the >>> following code snippets for doing target arithmetic at compile time: >>> >>> From m3-sys/m3middle/src/Target.i3: >>> >>> (* The bits of a target INTEGER (in 2's complement) are stored in >>> an array of small host values, with the low order bits in the >>> first >>> element of the array. *) >>> >>> TYPE >>> Int = (* OPAQUE *) RECORD >>> n: CARDINAL; (* only bytes [0..n-1] contain valid >>> bits *) >>> x := IBytes{0,..}; (* default is Zero *) >>> END; >>> IBytes = ARRAY [0..7] OF IByte; >>> IByte = BITS 8 FOR [0..16_ff]; >>> >>> From m3-sys/m3middle/src/TWord.m3: >>> >>> PROCEDURE Subtract (READONLY a, b: Int; VAR r: Int) = >>> VAR borrow := 0; n := MIN (a.n, b.n); >>> BEGIN >>> <*ASSERT n # 0*> >>> r.n := n; >>> FOR i := 0 TO n-1 DO >>> borrow := a.x[i] - b.x[i] - borrow; >>> r.x[i] := Word.And (borrow, Mask); >>> borrow := Word.And (RShift (borrow, BITSIZE (IByte)), 1); >>> END; >>> END Subtract; >>> >>> Unless the two values have equal numbers of bytes, Subtract just >>> throws away the high bytes of the longer operand. It looks like >>> pretty much all the CT target arithmetic in TWord.m3 and TInt.m3 >>> does this. >>> >>> It seems just about inconceivable that the arithmetic could be this >>> broken and not have created many impossible-to-ignore bugs. SRC >>> and pm3 do it differently. They have a single global variable that >>> gives the used size of all CT target values. >>> >>> The only possible explanation I can think of is that the cm3 >>> compiler >>> happens never to pass two Target.Int values with different >>> values of n. >>> The relevant declarations give no hint of such a counter-intuitive >>> requirement. If this is an essential precondition, it should be >>> documented in the interfaces. >>> >>> -- >>> ------------------------------------------------------------- >>> Rodney M. Bates, retired assistant professor >>> Dept. of Computer Science, Wichita State University >>> Wichita, KS 67260-0083 >>> 316-978-3922 >>> rodney.bates at wichita.edu >>> >>> > > -- > ------------------------------------------------------------- > Rodney M. Bates, retired assistant professor > Dept. of Computer Science, Wichita State University > Wichita, KS 67260-0083 > 316-978-3922 > rodney.bates at wichita.edu From wagner at elegosoft.com Fri Feb 1 21:26:30 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 01 Feb 2008 21:26:30 +0100 Subject: [M3devel] quake extensions for tests / RFC In-Reply-To: <20080131013425.f1wph3ypkwc8wkw8@mail.elegosoft.com> References: <20080131013425.f1wph3ypkwc8wkw8@mail.elegosoft.com> Message-ID: <20080201212630.u71dug6hw0oso0c4@mail.elegosoft.com> Yesterday I've added some more functions, and today I've updated the quake reference. I'm still open for name or semantics changes or other improvements. Please have a look at http://modula3.elegosoft.com/cm3/doc/help/cm3/quake.html Best regards, Olaf -- Olaf Wagner -- elego Software Solutions GmbH 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 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Sat Feb 2 00:57:32 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 1 Feb 2008 18:57:32 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20080201234353.F351E10D4655@birch.elegosoft.com> References: <20080201234353.F351E10D4655@birch.elegosoft.com> Message-ID: <449D00C2-1B6D-40BE-865D-08AF083DE54D@cs.purdue.edu> I just checked in support for full declaration of paramters even on imported procedures in the gcc-based backend. This is to support proper generation of stdcall calling convention on Windows. In the process of testing this I discovered that cm3 on non-Windows platforms now needs to build and ship both of the Windows x86 support libraries m3back and m3objfile, even though non-Windows platforms don't use or need them. This seems broken to me. It seems that cm3 has changed so that it now has these dependencies. Can we please undo this? -- I see no need to have to build these for non-x86 platforms that will never use them. On Feb 2, 2008, at 12:43 AM, Antony Hosking wrote: > CVSROOT: /usr/cvs > Changes by: hosking at birch. 08/02/02 00:43:53 > > Modified files: > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > Log message: > Add parameter decls even for imported procedures, as per Jay > Krell's request > to support stdcall parameter passing mode on Windows. From jayk123 at hotmail.com Sat Feb 2 01:12:27 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 2 Feb 2008 00:12:27 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <449D00C2-1B6D-40BE-865D-08AF083DE54D@cs.purdue.edu> References: <20080201234353.F351E10D4655@birch.elegosoft.com> <449D00C2-1B6D-40BE-865D-08AF083DE54D@cs.purdue.edu> Message-ID: This was deliberate. It enables some cross-build scenarios. That I admit I haven't used (yet?), but I really like the idea. If m3linker were completed, then "full" cross builds would be real. The "extra" packages are small and build fast (well, at least not using cm3cg...). Is it really so onerous? Really? Isn't it nice to have less filtering of packages as well? Like, when you are building on non-NT386, you can easily see that you didn't break building on NT386, at least partly. ? - Jay > From: hosking at cs.purdue.edu> Date: Fri, 1 Feb 2008 18:57:32 -0500> To: hosking at elego.de> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > I just checked in support for full declaration of paramters even on > imported procedures in the gcc-based backend. This is to support > proper generation of stdcall calling convention on Windows. In the > process of testing this I discovered that cm3 on non-Windows > platforms now needs to build and ship both of the Windows x86 support > libraries m3back and m3objfile, even though non-Windows platforms > don't use or need them. This seems broken to me. It seems that cm3 > has changed so that it now has these dependencies. Can we please > undo this? -- I see no need to have to build these for non-x86 > platforms that will never use them.> > On Feb 2, 2008, at 12:43 AM, Antony Hosking wrote:> > > CVSROOT: /usr/cvs> > Changes by: hosking at birch. 08/02/02 00:43:53> >> > Modified files:> > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c> >> > Log message:> > Add parameter decls even for imported procedures, as per Jay > > Krell's request> > to support stdcall parameter passing mode on Windows.> _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat Feb 2 01:19:05 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 2 Feb 2008 00:19:05 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20080201234353.F351E10D4655@birch.elegosoft.com> <449D00C2-1B6D-40BE-865D-08AF083DE54D@cs.purdue.edu> Message-ID: Actually it's slightly more real than I said. One cm3.exe on Windows can do any of NT386/NT386GNU/NT386MINGNU. Sometimes it uses the "extra" code, sometimes not. These are in a sense a limited form of cross build. Granted, if it was only for those three psuedo platforms, you wouldn't mind. - Jay From: jayk123 at hotmail.comTo: hosking at cs.purdue.edu; hosking at elego.deDate: Sat, 2 Feb 2008 00:12:27 +0000CC: m3devel at elegosoft.comSubject: Re: [M3devel] [M3commit] CVS Update: cm3 This was deliberate. It enables some cross-build scenarios. That I admit I haven't used (yet?), but I really like the idea. If m3linker were completed, then "full" cross builds would be real. The "extra" packages are small and build fast (well, at least not using cm3cg...).Is it really so onerous? Really? Isn't it nice to have less filtering of packages as well?Like, when you are building on non-NT386, you can easily see that you didn't break building on NT386, at least partly.? - Jay > From: hosking at cs.purdue.edu> Date: Fri, 1 Feb 2008 18:57:32 -0500> To: hosking at elego.de> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > I just checked in support for full declaration of paramters even on > imported procedures in the gcc-based backend. This is to support > proper generation of stdcall calling convention on Windows. In the > process of testing this I discovered that cm3 on non-Windows > platforms now needs to build and ship both of the Windows x86 support > libraries m3back and m3objfile, even though non-Windows platforms > don't use or need them. This seems broken to me. It seems that cm3 > has changed so that it now has these dependencies. Can we please > undo this? -- I see no need to have to build these for non-x86 > platforms that will never use them.> > On Feb 2, 2008, at 12:43 AM, Antony Hosking wrote:> > > CVSROOT: /usr/cvs> > Changes by: hosking at birch. 08/02/02 00:43:53> >> > Modified files:> > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c> >> > Log message:> > Add parameter decls even for imported procedures, as per Jay > > Krell's request> > to support stdcall parameter passing mode on Windows.> Connect and share in new ways with Windows Live. Get it now! _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Feb 2 01:22:56 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 1 Feb 2008 19:22:56 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20080201234353.F351E10D4655@birch.elegosoft.com> <449D00C2-1B6D-40BE-865D-08AF083DE54D@cs.purdue.edu> Message-ID: Hmm. OK, yes, perhaps I am prepared to live with it. Hopefully, that gnarly x86 backend will go away soon anyway -- it's probably never going to survive in the x86_64 universe and beyond! On Feb 1, 2008, at 7:19 PM, Jay wrote: > Actually it's slightly more real than I said. > One cm3.exe on Windows can do any of NT386/NT386GNU/NT386MINGNU. > Sometimes it uses the "extra" code, sometimes not. These are in a > sense a limited form of cross build. Granted, if it was only for > those three psuedo platforms, you wouldn't mind. > > - Jay > > From: jayk123 at hotmail.com > To: hosking at cs.purdue.edu; hosking at elego.de > Date: Sat, 2 Feb 2008 00:12:27 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > This was deliberate. It enables some cross-build scenarios. That I > admit I haven't used (yet?), but I really like the idea. > If m3linker were completed, then "full" cross builds would be real. > > The "extra" packages are small and build fast (well, at least not > using cm3cg...). > Is it really so onerous? Really? > > Isn't it nice to have less filtering of packages as well? > Like, when you are building on non-NT386, you can easily see that > you didn't break building on NT386, at least partly. > ? > > - Jay > > > > From: hosking at cs.purdue.edu > > Date: Fri, 1 Feb 2008 18:57:32 -0500 > > To: hosking at elego.de > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > I just checked in support for full declaration of paramters even on > > imported procedures in the gcc-based backend. This is to support > > proper generation of stdcall calling convention on Windows. In the > > process of testing this I discovered that cm3 on non-Windows > > platforms now needs to build and ship both of the Windows x86 > support > > libraries m3back and m3objfile, even though non-Windows platforms > > don't use or need them. This seems broken to me. It seems that cm3 > > has changed so that it now has these dependencies. Can we please > > undo this? -- I see no need to have to build these for non-x86 > > platforms that will never use them. > > > > On Feb 2, 2008, at 12:43 AM, Antony Hosking wrote: > > > > > CVSROOT: /usr/cvs > > > Changes by: hosking at birch. 08/02/02 00:43:53 > > > > > > Modified files: > > > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > > > > > Log message: > > > Add parameter decls even for imported procedures, as per Jay > > > Krell's request > > > to support stdcall parameter passing mode on Windows. > > > > > Connect and share in new ways with Windows Live. Get it now! > Shed those extra pounds with MSN and The Biggest Loser! Learn more. From jayk123 at hotmail.com Sat Feb 2 01:45:25 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 2 Feb 2008 00:45:25 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20080201234353.F351E10D4655@birch.elegosoft.com> <449D00C2-1B6D-40BE-865D-08AF083DE54D@cs.purdue.edu> Message-ID: Hey, I'd kind of like that backend to stay actually. It's quite fast and generates better code than unoptimized gcc and competitive code with optimized gcc. There's no AMD64 support anywhere yet in Modula-3 that I know of. Maybe it will appear here first? :) I don't think it is all that gnarly either. But somewhat. It's a bit like code I've see that is so often handling one case after another case after yet another case, yet who knows what all the cases are and which order (if any particular) they should be handled in? That is, it's actually kind of easier to read it and understand what it does do, and realize that is "correct" in the "necessary" sense, but hard to know if it is "sufficient". I've got outstanding diffs for int64 support I'd like to get back to. AMD64 shouldn't be difficult...that's kind of the point, eh? It's just a slight alteration of x86.. Granted, it isn't set up, doesn't have a "framework", to generate substantially better code. It doesn't remember much, doesn't make multiple passes, doesn't have a high level representation, etc. In the unlikely event that I succeed, presumably PPC would be next...:) (But yeah yeah, LLVM is probably easier and much more fruitful, both in terms of platform each and optimization..and hopefully build speed.) - Jay > CC: hosking at elego.de; m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: [M3devel] [M3commit] CVS Update: cm3> Date: Fri, 1 Feb 2008 19:22:56 -0500> To: jayk123 at hotmail.com> > Hmm. OK, yes, perhaps I am prepared to live with it. Hopefully, > that gnarly x86 backend will go away soon anyway -- it's probably > never going to survive in the x86_64 universe and beyond!> > On Feb 1, 2008, at 7:19 PM, Jay wrote:> > > Actually it's slightly more real than I said.> > One cm3.exe on Windows can do any of NT386/NT386GNU/NT386MINGNU. > > Sometimes it uses the "extra" code, sometimes not. These are in a > > sense a limited form of cross build. Granted, if it was only for > > those three psuedo platforms, you wouldn't mind.> >> > - Jay> >> > From: jayk123 at hotmail.com> > To: hosking at cs.purdue.edu; hosking at elego.de> > Date: Sat, 2 Feb 2008 00:12:27 +0000> > CC: m3devel at elegosoft.com> > Subject: Re: [M3devel] [M3commit] CVS Update: cm3> >> > This was deliberate. It enables some cross-build scenarios. That I > > admit I haven't used (yet?), but I really like the idea.> > If m3linker were completed, then "full" cross builds would be real.> >> > The "extra" packages are small and build fast (well, at least not > > using cm3cg...).> > Is it really so onerous? Really?> >> > Isn't it nice to have less filtering of packages as well?> > Like, when you are building on non-NT386, you can easily see that > > you didn't break building on NT386, at least partly.> > ?> >> > - Jay> >> >> > > From: hosking at cs.purdue.edu> > > Date: Fri, 1 Feb 2008 18:57:32 -0500> > > To: hosking at elego.de> > > CC: m3devel at elegosoft.com> > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > >> > > I just checked in support for full declaration of paramters even on> > > imported procedures in the gcc-based backend. This is to support> > > proper generation of stdcall calling convention on Windows. In the> > > process of testing this I discovered that cm3 on non-Windows> > > platforms now needs to build and ship both of the Windows x86 > > support> > > libraries m3back and m3objfile, even though non-Windows platforms> > > don't use or need them. This seems broken to me. It seems that cm3> > > has changed so that it now has these dependencies. Can we please> > > undo this? -- I see no need to have to build these for non-x86> > > platforms that will never use them.> > >> > > On Feb 2, 2008, at 12:43 AM, Antony Hosking wrote:> > >> > > > CVSROOT: /usr/cvs> > > > Changes by: hosking at birch. 08/02/02 00:43:53> > > >> > > > Modified files:> > > > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c> > > >> > > > Log message:> > > > Add parameter decls even for imported procedures, as per Jay> > > > Krell's request> > > > to support stdcall parameter passing mode on Windows.> > >> >> >> > Connect and share in new ways with Windows Live. Get it now!> > Shed those extra pounds with MSN and The Biggest Loser! Learn more.> _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Feb 2 01:56:18 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 1 Feb 2008 19:56:18 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20080201234353.F351E10D4655@birch.elegosoft.com> <449D00C2-1B6D-40BE-865D-08AF083DE54D@cs.purdue.edu> Message-ID: <9ABD4D1E-F9F8-4D50-AD2C-12BC284B164E@cs.purdue.edu> It would be nice to have the x86 integrated backend for I386_LINUX and LINUXLIBC6 too -- just like the old PM3 did. On Feb 1, 2008, at 7:45 PM, Jay wrote: > Hey, I'd kind of like that backend to stay actually. It's quite > fast and generates better code than unoptimized gcc and competitive > code with optimized gcc. There's no AMD64 support anywhere yet in > Modula-3 that I know of. Maybe it will appear here first? :) > > I don't think it is all that gnarly either. But somewhat. It's a > bit like code I've see that is so often handling one case after > another case after yet another case, yet who knows what all the > cases are and which order (if any particular) they should be > handled in? That is, it's actually kind of easier to read it and > understand what it does do, and realize that is "correct" in the > "necessary" sense, but hard to know if it is "sufficient". > I've got outstanding diffs for int64 support I'd like to get back to. > > AMD64 shouldn't be difficult...that's kind of the point, eh? > It's just a slight alteration of x86.. > > Granted, it isn't set up, doesn't have a "framework", to generate > substantially better code. > It doesn't remember much, doesn't make multiple passes, doesn't > have a high level representation, etc. > > In the unlikely event that I succeed, presumably PPC would be > next...:) > > (But yeah yeah, LLVM is probably easier and much more fruitful, > both in terms of platform each and optimization..and hopefully > build speed.) > > - Jay > > > > CC: hosking at elego.de; m3devel at elegosoft.com > > From: hosking at cs.purdue.edu > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > Date: Fri, 1 Feb 2008 19:22:56 -0500 > > To: jayk123 at hotmail.com > > > > Hmm. OK, yes, perhaps I am prepared to live with it. Hopefully, > > that gnarly x86 backend will go away soon anyway -- it's probably > > never going to survive in the x86_64 universe and beyond! > > > > On Feb 1, 2008, at 7:19 PM, Jay wrote: > > > > > Actually it's slightly more real than I said. > > > One cm3.exe on Windows can do any of NT386/NT386GNU/NT386MINGNU. > > > Sometimes it uses the "extra" code, sometimes not. These are in a > > > sense a limited form of cross build. Granted, if it was only for > > > those three psuedo platforms, you wouldn't mind. > > > > > > - Jay > > > > > > From: jayk123 at hotmail.com > > > To: hosking at cs.purdue.edu; hosking at elego.de > > > Date: Sat, 2 Feb 2008 00:12:27 +0000 > > > CC: m3devel at elegosoft.com > > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > > > This was deliberate. It enables some cross-build scenarios. That I > > > admit I haven't used (yet?), but I really like the idea. > > > If m3linker were completed, then "full" cross builds would be > real. > > > > > > The "extra" packages are small and build fast (well, at least not > > > using cm3cg...). > > > Is it really so onerous? Really? > > > > > > Isn't it nice to have less filtering of packages as well? > > > Like, when you are building on non-NT386, you can easily see that > > > you didn't break building on NT386, at least partly. > > > ? > > > > > > - Jay > > > > > > > > > > From: hosking at cs.purdue.edu > > > > Date: Fri, 1 Feb 2008 18:57:32 -0500 > > > > To: hosking at elego.de > > > > CC: m3devel at elegosoft.com > > > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > > > > > I just checked in support for full declaration of paramters > even on > > > > imported procedures in the gcc-based backend. This is to support > > > > proper generation of stdcall calling convention on Windows. > In the > > > > process of testing this I discovered that cm3 on non-Windows > > > > platforms now needs to build and ship both of the Windows x86 > > > support > > > > libraries m3back and m3objfile, even though non-Windows > platforms > > > > don't use or need them. This seems broken to me. It seems > that cm3 > > > > has changed so that it now has these dependencies. Can we please > > > > undo this? -- I see no need to have to build these for non-x86 > > > > platforms that will never use them. > > > > > > > > On Feb 2, 2008, at 12:43 AM, Antony Hosking wrote: > > > > > > > > > CVSROOT: /usr/cvs > > > > > Changes by: hosking at birch. 08/02/02 00:43:53 > > > > > > > > > > Modified files: > > > > > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > > > > > > > > > Log message: > > > > > Add parameter decls even for imported procedures, as per Jay > > > > > Krell's request > > > > > to support stdcall parameter passing mode on Windows. > > > > > > > > > > > > > Connect and share in new ways with Windows Live. Get it now! > > > Shed those extra pounds with MSN and The Biggest Loser! Learn > more. > > > > > Shed those extra pounds with MSN and The Biggest Loser! Learn more. From rcoleburn at scires.com Sat Feb 2 01:57:24 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 01 Feb 2008 19:57:24 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20080201234353.F351E10D4655@birch.elegosoft.com> <449D00C2-1B6D-40BE-865D-08AF083DE54D@cs.purdue.edu> Message-ID: <47A379A4.1E75.00D7.1@scires.com> I too want to keep that backend. All of my Modula-3 production code in the past was built using it. Regards, Randy >>> Jay 2/1/2008 7:45 PM >>> Hey, I'd kind of like that backend to stay actually. It's quite fast and generates better code than unoptimized gcc and competitive code with optimized gcc. There's no AMD64 support anywhere yet in Modula-3 that I know of. Maybe it will appear here first? :) I don't think it is all that gnarly either. But somewhat. It's a bit like code I've see that is so often handling one case after another case after yet another case, yet who knows what all the cases are and which order (if any particular) they should be handled in? That is, it's actually kind of easier to read it and understand what it does do, and realize that is "correct" in the "necessary" sense, but hard to know if it is "sufficient". I've got outstanding diffs for int64 support I'd like to get back to. AMD64 shouldn't be difficult...that's kind of the point, eh? It's just a slight alteration of x86.. Granted, it isn't set up, doesn't have a "framework", to generate substantially better code. It doesn't remember much, doesn't make multiple passes, doesn't have a high level representation, etc. In the unlikely event that I succeed, presumably PPC would be next...:) (But yeah yeah, LLVM is probably easier and much more fruitful, both in terms of platform each and optimization..and hopefully build speed.) - Jay > CC: hosking at elego.de; m3devel at elegosoft.com > From: hosking at cs.purdue.edu > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > Date: Fri, 1 Feb 2008 19:22:56 -0500 > To: jayk123 at hotmail.com > > Hmm. OK, yes, perhaps I am prepared to live with it. Hopefully, > that gnarly x86 backend will go away soon anyway -- it's probably > never going to survive in the x86_64 universe and beyond! > > On Feb 1, 2008, at 7:19 PM, Jay wrote: > > > Actually it's slightly more real than I said. > > One cm3.exe on Windows can do any of NT386/NT386GNU/NT386MINGNU. > > Sometimes it uses the "extra" code, sometimes not. These are in a > > sense a limited form of cross build. Granted, if it was only for > > those three psuedo platforms, you wouldn't mind. > > > > - Jay > > > > From: jayk123 at hotmail.com > > To: hosking at cs.purdue.edu; hosking at elego.de > > Date: Sat, 2 Feb 2008 00:12:27 +0000 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > This was deliberate. It enables some cross-build scenarios. That I > > admit I haven't used (yet?), but I really like the idea. > > If m3linker were completed, then "full" cross builds would be real. > > > > The "extra" packages are small and build fast (well, at least not > > using cm3cg...). > > Is it really so onerous? Really? > > > > Isn't it nice to have less filtering of packages as well? > > Like, when you are building on non-NT386, you can easily see that > > you didn't break building on NT386, at least partly. > > ? > > > > - Jay > > > > > > > From: hosking at cs.purdue.edu > > > Date: Fri, 1 Feb 2008 18:57:32 -0500 > > > To: hosking at elego.de > > > CC: m3devel at elegosoft.com > > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > > > I just checked in support for full declaration of paramters even on > > > imported procedures in the gcc-based backend. This is to support > > > proper generation of stdcall calling convention on Windows. In the > > > process of testing this I discovered that cm3 on non-Windows > > > platforms now needs to build and ship both of the Windows x86 > > support > > > libraries m3back and m3objfile, even though non-Windows platforms > > > don't use or need them. This seems broken to me. It seems that cm3 > > > has changed so that it now has these dependencies. Can we please > > > undo this? -- I see no need to have to build these for non-x86 > > > platforms that will never use them. > > > > > > On Feb 2, 2008, at 12:43 AM, Antony Hosking wrote: > > > > > > > CVSROOT: /usr/cvs > > > > Changes by: hosking at birch. 08/02/02 00:43:53 > > > > > > > > Modified files: > > > > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > > > > > > > Log message: > > > > Add parameter decls even for imported procedures, as per Jay > > > > Krell's request > > > > to support stdcall parameter passing mode on Windows. > > > > > > > > > Connect and share in new ways with Windows Live. Get it now! > > Shed those extra pounds with MSN and The Biggest Loser! Learn more. > Shed those extra pounds with MSN and The Biggest Loser! Learn more. ( http://biggestloser.msn.com/ ) -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat Feb 2 02:02:10 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 2 Feb 2008 01:02:10 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <9ABD4D1E-F9F8-4D50-AD2C-12BC284B164E@cs.purdue.edu> References: <20080201234353.F351E10D4655@birch.elegosoft.com> <449D00C2-1B6D-40BE-865D-08AF083DE54D@cs.purdue.edu> <9ABD4D1E-F9F8-4D50-AD2C-12BC284B164E@cs.purdue.edu> Message-ID: "I386_LINUX"? You aren't off renaming platforms now are you Tony? :) Agreed. I stopped looking when I noticed the license.. Aha..I guess that is the point of the two "integrated" x86 backends? There's just one code base, there there is m3back and m3staloneback. One builds a .lib, one builds an .exe. The .exe probably reads the binary file and then replays the function calls..it's marshaling layer and all that... You can move the code around to avoid spreading the license and all that.. - Jay > CC: hosking at elego.de; m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: [M3devel] [M3commit] CVS Update: cm3> Date: Fri, 1 Feb 2008 19:56:18 -0500> To: jayk123 at hotmail.com> > It would be nice to have the x86 integrated backend for I386_LINUX > and LINUXLIBC6 too -- just like the old PM3 did.> > On Feb 1, 2008, at 7:45 PM, Jay wrote:> > > Hey, I'd kind of like that backend to stay actually. It's quite > > fast and generates better code than unoptimized gcc and competitive > > code with optimized gcc. There's no AMD64 support anywhere yet in > > Modula-3 that I know of. Maybe it will appear here first? :)> >> > I don't think it is all that gnarly either. But somewhat. It's a > > bit like code I've see that is so often handling one case after > > another case after yet another case, yet who knows what all the > > cases are and which order (if any particular) they should be > > handled in? That is, it's actually kind of easier to read it and > > understand what it does do, and realize that is "correct" in the > > "necessary" sense, but hard to know if it is "sufficient".> > I've got outstanding diffs for int64 support I'd like to get back to.> >> > AMD64 shouldn't be difficult...that's kind of the point, eh?> > It's just a slight alteration of x86..> >> > Granted, it isn't set up, doesn't have a "framework", to generate > > substantially better code.> > It doesn't remember much, doesn't make multiple passes, doesn't > > have a high level representation, etc.> >> > In the unlikely event that I succeed, presumably PPC would be > > next...:)> >> > (But yeah yeah, LLVM is probably easier and much more fruitful, > > both in terms of platform each and optimization..and hopefully > > build speed.)> >> > - Jay> >> >> > > CC: hosking at elego.de; m3devel at elegosoft.com> > > From: hosking at cs.purdue.edu> > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > > Date: Fri, 1 Feb 2008 19:22:56 -0500> > > To: jayk123 at hotmail.com> > >> > > Hmm. OK, yes, perhaps I am prepared to live with it. Hopefully,> > > that gnarly x86 backend will go away soon anyway -- it's probably> > > never going to survive in the x86_64 universe and beyond!> > >> > > On Feb 1, 2008, at 7:19 PM, Jay wrote:> > >> > > > Actually it's slightly more real than I said.> > > > One cm3.exe on Windows can do any of NT386/NT386GNU/NT386MINGNU.> > > > Sometimes it uses the "extra" code, sometimes not. These are in a> > > > sense a limited form of cross build. Granted, if it was only for> > > > those three psuedo platforms, you wouldn't mind.> > > >> > > > - Jay> > > >> > > > From: jayk123 at hotmail.com> > > > To: hosking at cs.purdue.edu; hosking at elego.de> > > > Date: Sat, 2 Feb 2008 00:12:27 +0000> > > > CC: m3devel at elegosoft.com> > > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > > >> > > > This was deliberate. It enables some cross-build scenarios. That I> > > > admit I haven't used (yet?), but I really like the idea.> > > > If m3linker were completed, then "full" cross builds would be > > real.> > > >> > > > The "extra" packages are small and build fast (well, at least not> > > > using cm3cg...).> > > > Is it really so onerous? Really?> > > >> > > > Isn't it nice to have less filtering of packages as well?> > > > Like, when you are building on non-NT386, you can easily see that> > > > you didn't break building on NT386, at least partly.> > > > ?> > > >> > > > - Jay> > > >> > > >> > > > > From: hosking at cs.purdue.edu> > > > > Date: Fri, 1 Feb 2008 18:57:32 -0500> > > > > To: hosking at elego.de> > > > > CC: m3devel at elegosoft.com> > > > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > > > >> > > > > I just checked in support for full declaration of paramters > > even on> > > > > imported procedures in the gcc-based backend. This is to support> > > > > proper generation of stdcall calling convention on Windows. > > In the> > > > > process of testing this I discovered that cm3 on non-Windows> > > > > platforms now needs to build and ship both of the Windows x86> > > > support> > > > > libraries m3back and m3objfile, even though non-Windows > > platforms> > > > > don't use or need them. This seems broken to me. It seems > > that cm3> > > > > has changed so that it now has these dependencies. Can we please> > > > > undo this? -- I see no need to have to build these for non-x86> > > > > platforms that will never use them.> > > > >> > > > > On Feb 2, 2008, at 12:43 AM, Antony Hosking wrote:> > > > >> > > > > > CVSROOT: /usr/cvs> > > > > > Changes by: hosking at birch. 08/02/02 00:43:53> > > > > >> > > > > > Modified files:> > > > > > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c> > > > > >> > > > > > Log message:> > > > > > Add parameter decls even for imported procedures, as per Jay> > > > > > Krell's request> > > > > > to support stdcall parameter passing mode on Windows.> > > > >> > > >> > > >> > > > Connect and share in new ways with Windows Live. Get it now!> > > > Shed those extra pounds with MSN and The Biggest Loser! Learn > > more.> > >> >> >> > Shed those extra pounds with MSN and The Biggest Loser! Learn more.> _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Sat Feb 2 02:08:59 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 01 Feb 2008 20:08:59 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20080201234353.F351E10D4655@birch.elegosoft.com> <449D00C2-1B6D-40BE-865D-08AF083DE54D@cs.purdue.edu> <9ABD4D1E-F9F8-4D50-AD2C-12BC284B164E@cs.purdue.edu> Message-ID: <47A37C5A.1E75.00D7.1@scires.com> Hey Jay, do you suppose this may have some explanation for why pixmaps only work on NT386 when buildstandalone() is given? --Randy >>> Jay 2/1/2008 8:02 PM >>> "I386_LINUX"? You aren't off renaming platforms now are you Tony? :) Agreed. I stopped looking when I noticed the license.. Aha..I guess that is the point of the two "integrated" x86 backends? There's just one code base, there there is m3back and m3staloneback. One builds a .lib, one builds an .exe. The .exe probably reads the binary file and then replays the function calls..it's marshaling layer and all that... You can move the code around to avoid spreading the license and all that.. - Jay > CC: hosking at elego.de; m3devel at elegosoft.com > From: hosking at cs.purdue.edu > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > Date: Fri, 1 Feb 2008 19:56:18 -0500 > To: jayk123 at hotmail.com > > It would be nice to have the x86 integrated backend for I386_LINUX > and LINUXLIBC6 too -- just like the old PM3 did. > > On Feb 1, 2008, at 7:45 PM, Jay wrote: > > > Hey, I'd kind of like that backend to stay actually. It's quite > > fast and generates better code than unoptimized gcc and competitive > > code with optimized gcc. There's no AMD64 support anywhere yet in > > Modula-3 that I know of. Maybe it will appear here first? :) > > > > I don't think it is all that gnarly either. But somewhat. It's a > > bit like code I've see that is so often handling one case after > > another case after yet another case, yet who knows what all the > > cases are and which order (if any particular) they should be > > handled in? That is, it's actually kind of easier to read it and > > understand what it does do, and realize that is "correct" in the > > "necessary" sense, but hard to know if it is "sufficient". > > I've got outstanding diffs for int64 support I'd like to get back to. > > > > AMD64 shouldn't be difficult...that's kind of the point, eh? > > It's just a slight alteration of x86.. > > > > Granted, it isn't set up, doesn't have a "framework", to generate > > substantially better code. > > It doesn't remember much, doesn't make multiple passes, doesn't > > have a high level representation, etc. > > > > In the unlikely event that I succeed, presumably PPC would be > > next...:) > > > > (But yeah yeah, LLVM is probably easier and much more fruitful, > > both in terms of platform each and optimization..and hopefully > > build speed.) > > > > - Jay > > > > > > > CC: hosking at elego.de; m3devel at elegosoft.com > > > From: hosking at cs.purdue.edu > > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > Date: Fri, 1 Feb 2008 19:22:56 -0500 > > > To: jayk123 at hotmail.com > > > > > > Hmm. OK, yes, perhaps I am prepared to live with it. Hopefully, > > > that gnarly x86 backend will go away soon anyway -- it's probably > > > never going to survive in the x86_64 universe and beyond! > > > > > > On Feb 1, 2008, at 7:19 PM, Jay wrote: > > > > > > > Actually it's slightly more real than I said. > > > > One cm3.exe on Windows can do any of NT386/NT386GNU/NT386MINGNU. > > > > Sometimes it uses the "extra" code, sometimes not. These are in a > > > > sense a limited form of cross build. Granted, if it was only for > > > > those three psuedo platforms, you wouldn't mind. > > > > > > > > - Jay > > > > > > > > From: jayk123 at hotmail.com > > > > To: hosking at cs.purdue.edu; hosking at elego.de > > > > Date: Sat, 2 Feb 2008 00:12:27 +0000 > > > > CC: m3devel at elegosoft.com > > > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > > > > > This was deliberate. It enables some cross-build scenarios. That I > > > > admit I haven't used (yet?), but I really like the idea. > > > > If m3linker were completed, then "full" cross builds would be > > real. > > > > > > > > The "extra" packages are small and build fast (well, at least not > > > > using cm3cg...). > > > > Is it really so onerous? Really? > > > > > > > > Isn't it nice to have less filtering of packages as well? > > > > Like, when you are building on non-NT386, you can easily see that > > > > you didn't break building on NT386, at least partly. > > > > ? > > > > > > > > - Jay > > > > > > > > > > > > > From: hosking at cs.purdue.edu > > > > > Date: Fri, 1 Feb 2008 18:57:32 -0500 > > > > > To: hosking at elego.de > > > > > CC: m3devel at elegosoft.com > > > > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > > > > > > > I just checked in support for full declaration of paramters > > even on > > > > > imported procedures in the gcc-based backend. This is to support > > > > > proper generation of stdcall calling convention on Windows. > > In the > > > > > process of testing this I discovered that cm3 on non-Windows > > > > > platforms now needs to build and ship both of the Windows x86 > > > > support > > > > > libraries m3back and m3objfile, even though non-Windows > > platforms > > > > > don't use or need them. This seems broken to me. It seems > > that cm3 > > > > > has changed so that it now has these dependencies. Can we please > > > > > undo this? -- I see no need to have to build these for non-x86 > > > > > platforms that will never use them. > > > > > > > > > > On Feb 2, 2008, at 12:43 AM, Antony Hosking wrote: > > > > > > > > > > > CVSROOT: /usr/cvs > > > > > > Changes by: hosking at birch. 08/02/02 00:43:53 > > > > > > > > > > > > Modified files: > > > > > > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > > > > > > > > > > > Log message: > > > > > > Add parameter decls even for imported procedures, as per Jay > > > > > > Krell's request > > > > > > to support stdcall parameter passing mode on Windows. > > > > > > > > > > > > > > > > > Connect and share in new ways with Windows Live. Get it now! > > > > Shed those extra pounds with MSN and The Biggest Loser! Learn > > more. > > > > > > > > > Shed those extra pounds with MSN and The Biggest Loser! Learn more. > Connect and share in new ways with Windows Live. Get it now! ( http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 ) -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat Feb 2 02:19:28 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 2 Feb 2008 01:19:28 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <47A37C5A.1E75.00D7.1@scires.com> References: <20080201234353.F351E10D4655@birch.elegosoft.com> <449D00C2-1B6D-40BE-865D-08AF083DE54D@cs.purdue.edu> <9ABD4D1E-F9F8-4D50-AD2C-12BC284B164E@cs.purdue.edu> <47A37C5A.1E75.00D7.1@scires.com> Message-ID: No. (I fully admit I don't know yet what the problem is, and the way the system is designed in my understanding, variations like this are "impossible", therefore throw out nearly all expectations and entertain nearly all ideas, but I don't think this is related. It'll just have to be debugged and code studied and skimmed for hints, and I apologize for the long delay. Maybe some code checks for function equality?? (not sure Modula-3 even supports that, but it's one the small subtleties of dynamic linking that can trip up some unusual slightly sleazy C code)) - Jay Date: Fri, 1 Feb 2008 20:08:59 -0500From: rcoleburn at scires.comTo: hosking at cs.purdue.edu; jayk123 at hotmail.comCC: hosking at elego.de; m3devel at elegosoft.comSubject: Re: [M3devel] [M3commit] CVS Update: cm3 Hey Jay, do you suppose this may have some explanation for why pixmaps only work on NT386 when buildstandalone() is given? --Randy>>> Jay 2/1/2008 8:02 PM >>>"I386_LINUX"? You aren't off renaming platforms now are you Tony? :)Agreed. I stopped looking when I noticed the license..Aha..I guess that is the point of the two "integrated" x86 backends?There's just one code base, there there is m3back and m3staloneback. One builds a .lib, one builds an .exe.The .exe probably reads the binary file and then replays the function calls..it's marshaling layer and all that...You can move the code around to avoid spreading the license and all that.. - Jay > CC: hosking at elego.de; m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: [M3devel] [M3commit] CVS Update: cm3> Date: Fri, 1 Feb 2008 19:56:18 -0500> To: jayk123 at hotmail.com> > It would be nice to have the x86 integrated backend for I386_LINUX > and LINUXLIBC6 too -- just like the old PM3 did.> > On Feb 1, 2008, at 7:45 PM, Jay wrote:> > > Hey, I'd kind of like that backend to stay actually. It's quite > > fast and generates better code than unoptimized gcc and competitive > > code with optimized gcc. There's no AMD64 support anywhere yet in > > Modula-3 that I know of. Maybe it will appear here first? :)> >> > I don't think it is all that gnarly either. But somewhat. It's a > > bit like code I've see that is so often handling one case after > > another case after yet another case, yet who knows what all the > > cases are and which order (if any particular) they should be > > handled in? That is, it's actually kind of easier to read it and > > understand what it does do, and realize that is "correct" in the > > "necessary" sense, but hard to know if it is "sufficient".> > I've got outstanding diffs for int64 support I'd like to get back to.> >> > AMD64 shouldn't be difficult...that's kind of the point, eh?> > It's just a slight alteration of x86..> >> > Granted, it isn't set up, doesn't have a "framework", to generate > > substantially better code.> > It doesn't remember much, doesn't make multiple passes, doesn't > > have a high level representation, etc.> >> > In the unlikely event that I succeed, presumably PPC would be > > next...:)> >> > (But yeah yeah, LLVM is probably easier and much more fruitful, > > both in terms of platform each and optimization..and hopefully > > build speed.)> >> > - Jay> >> >> > > CC: hosking at elego.de; m3devel at elegosoft.com> > > From: hosking at cs.purdue.edu> > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > > Date: Fri, 1 Feb 2008 19:22:56 -0500> > > To: jayk123 at hotmail.com> > >> > > Hmm. OK, yes, perhaps I am prepared to live with it. Hopefully,> > > that gnarly x86 backend will go away soon anyway -- it's probably> > > never going to survive in the x86_64 universe and beyond!> > >> > > On Feb 1, 2008, at 7:19 PM, Jay wrote:> > >> > > > Actually it's slightly more real than I said.> > > > One cm3.exe on Windows can do any of NT386/NT386GNU/NT386MINGNU.> > > > Sometimes it uses the "extra" code, sometimes not. These are in a> > > > sense a limited form of cross build. Granted, if it was only for> > > > those three psuedo platforms, you wouldn't mind.> > > >> > > > - Jay> > > >> > > > From: jayk123 at hotmail.com> > > > To: hosking at cs.purdue.edu; hosking at elego.de> > > > Date: Sat, 2 Feb 2008 00:12:27 +0000> > > > CC: m3devel at elegosoft.com> > > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > > >> > > > This was deliberate. It enables some cross-build scenarios. That I> > > > admit I haven't used (yet?), but I really like the idea.> > > > If m3linker were completed, then "full" cross builds would be > > real.> > > >> > > > The "extra" packages are small and build fast (well, at least not> > > > using cm3cg...).> > > > Is it really so onerous? Really?> > > >> > > > Isn't it nice to have less filtering of packages as well?> > > > Like, when you are building on non-NT386, you can easily see that> > > > you didn't break building on NT386, at least partly.> > > > ?> > > >> > > > - Jay> > > >> > > >> > > > > From: hosking at cs.purdue.edu> > > > > Date: Fri, 1 Feb 2008 18:57:32 -0500> > > > > To: hosking at elego.de> > > > > CC: m3devel at elegosoft.com> > > > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > > > >> > > > > I just checked in support for full declaration of paramters > > even on> > > > > imported procedures in the gcc-based backend. This is to support> > > > > proper generation of stdcall calling convention on Windows. > > In the> > > > > process of testing this I discovered that cm3 on non-Windows> > > > > platforms now needs to build and ship both of the Windows x86> > > > support> > > > > libraries m3back and m3objfile, even though non-Windows > > platforms> > > > > don't use or need them. This seems broken to me. It seems > > that cm3> > > > > has changed so that it now has these dependencies. Can we please> > > > > undo this? -- I see no need to have to build these for non-x86> > > > > platforms that will never use them.> > > > >> > > > > On Feb 2, 2008, at 12:43 AM, Antony Hosking wrote:> > > > >> > > > > > CVSROOT: /usr/cvs> > > > > > Changes by: hosking at birch. 08/02/02 00:43:53> > > > > >> > > > > > Modified files:> > > > > > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c> > > > > >> > > > > > Log message:> > > > > > Add parameter decls even for imported procedures, as per Jay> > > > > > Krell's request> > > > > > to support stdcall parameter passing mode on Windows.> > > > >> > > >> > > >> > > > Connect and share in new ways with Windows Live. Get it now!> > > > Shed those extra pounds with MSN and The Biggest Loser! Learn > > more.> > >> >> >> > Shed those extra pounds with MSN and The Biggest Loser! Learn more.> Connect and share in new ways with Windows Live. Get it now! _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Feb 2 03:23:24 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 1 Feb 2008 21:23:24 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20080201234353.F351E10D4655@birch.elegosoft.com> <449D00C2-1B6D-40BE-865D-08AF083DE54D@cs.purdue.edu> <9ABD4D1E-F9F8-4D50-AD2C-12BC284B164E@cs.purdue.edu> Message-ID: <3F43F984-4CF8-4F74-A422-0F129FD00707@cs.purdue.edu> Sorry: I386_DARWIN. On Feb 1, 2008, at 8:02 PM, Jay wrote: > "I386_LINUX"? You aren't off renaming platforms now are you Tony? :) > Agreed. I stopped looking when I noticed the license.. > Aha..I guess that is the point of the two "integrated" x86 backends? > There's just one code base, there there is m3back and > m3staloneback. One builds a .lib, one builds an .exe. > The .exe probably reads the binary file and then replays the > function calls..it's marshaling layer and all that... > You can move the code around to avoid spreading the license and all > that.. > > > - Jay > > > > CC: hosking at elego.de; m3devel at elegosoft.com > > From: hosking at cs.purdue.edu > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > Date: Fri, 1 Feb 2008 19:56:18 -0500 > > To: jayk123 at hotmail.com > > > > It would be nice to have the x86 integrated backend for I386_LINUX > > and LINUXLIBC6 too -- just like the old PM3 did. > > > > On Feb 1, 2008, at 7:45 PM, Jay wrote: > > > > > Hey, I'd kind of like that backend to stay actually. It's quite > > > fast and generates better code than unoptimized gcc and > competitive > > > code with optimized gcc. There's no AMD64 support anywhere yet in > > > Modula-3 that I know of. Maybe it will appear here first? :) > > > > > > I don't think it is all that gnarly either. But somewhat. It's a > > > bit like code I've see that is so often handling one case after > > > another case after yet another case, yet who knows what all the > > > cases are and which order (if any particular) they should be > > > handled in? That is, it's actually kind of easier to read it and > > > understand what it does do, and realize that is "correct" in the > > > "necessary" sense, but hard to know if it is "sufficient". > > > I've got outstanding diffs for int64 support I'd like to get > back to. > > > > > > AMD64 shouldn't be difficult...that's kind of the point, eh? > > > It's just a slight alteration of x86.. > > > > > > Granted, it isn't set up, doesn't have a "framework", to generate > > > substantially better code. > > > It doesn't remember much, doesn't make multiple passes, doesn't > > > have a high level representation, etc. > > > > > > In the unlikely event that I succeed, presumably PPC would be > > > next...:) > > > > > > (But yeah yeah, LLVM is probably easier and much more fruitful, > > > both in terms of platform each and optimization..and hopefully > > > build speed.) > > > > > > - Jay > > > > > > > > > > CC: hosking at elego.de; m3devel at elegosoft.com > > > > From: hosking at cs.purdue.edu > > > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > Date: Fri, 1 Feb 2008 19:22:56 -0500 > > > > To: jayk123 at hotmail.com > > > > > > > > Hmm. OK, yes, perhaps I am prepared to live with it. Hopefully, > > > > that gnarly x86 backend will go away soon anyway -- it's > probably > > > > never going to survive in the x86_64 universe and beyond! > > > > > > > > On Feb 1, 2008, at 7:19 PM, Jay wrote: > > > > > > > > > Actually it's slightly more real than I said. > > > > > One cm3.exe on Windows can do any of NT386/NT386GNU/ > NT386MINGNU. > > > > > Sometimes it uses the "extra" code, sometimes not. These > are in a > > > > > sense a limited form of cross build. Granted, if it was > only for > > > > > those three psuedo platforms, you wouldn't mind. > > > > > > > > > > - Jay > > > > > > > > > > From: jayk123 at hotmail.com > > > > > To: hosking at cs.purdue.edu; hosking at elego.de > > > > > Date: Sat, 2 Feb 2008 00:12:27 +0000 > > > > > CC: m3devel at elegosoft.com > > > > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > > > > > > > This was deliberate. It enables some cross-build scenarios. > That I > > > > > admit I haven't used (yet?), but I really like the idea. > > > > > If m3linker were completed, then "full" cross builds would be > > > real. > > > > > > > > > > The "extra" packages are small and build fast (well, at > least not > > > > > using cm3cg...). > > > > > Is it really so onerous? Really? > > > > > > > > > > Isn't it nice to have less filtering of packages as well? > > > > > Like, when you are building on non-NT386, you can easily > see that > > > > > you didn't break building on NT386, at least partly. > > > > > ? > > > > > > > > > > - Jay > > > > > > > > > > > > > > > > From: hosking at cs.purdue.edu > > > > > > Date: Fri, 1 Feb 2008 18:57:32 -0500 > > > > > > To: hosking at elego.de > > > > > > CC: m3devel at elegosoft.com > > > > > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > > > > > > > > > > I just checked in support for full declaration of paramters > > > even on > > > > > > imported procedures in the gcc-based backend. This is to > support > > > > > > proper generation of stdcall calling convention on Windows. > > > In the > > > > > > process of testing this I discovered that cm3 on non-Windows > > > > > > platforms now needs to build and ship both of the Windows > x86 > > > > > support > > > > > > libraries m3back and m3objfile, even though non-Windows > > > platforms > > > > > > don't use or need them. This seems broken to me. It seems > > > that cm3 > > > > > > has changed so that it now has these dependencies. Can we > please > > > > > > undo this? -- I see no need to have to build these for > non-x86 > > > > > > platforms that will never use them. > > > > > > > > > > > > On Feb 2, 2008, at 12:43 AM, Antony Hosking wrote: > > > > > > > > > > > > > CVSROOT: /usr/cvs > > > > > > > Changes by: hosking at birch. 08/02/02 00:43:53 > > > > > > > > > > > > > > Modified files: > > > > > > > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > > > > > > > > > > > > > Log message: > > > > > > > Add parameter decls even for imported procedures, as > per Jay > > > > > > > Krell's request > > > > > > > to support stdcall parameter passing mode on Windows. > > > > > > > > > > > > > > > > > > > > > Connect and share in new ways with Windows Live. Get it now! > > > > > Shed those extra pounds with MSN and The Biggest Loser! Learn > > > more. > > > > > > > > > > > > > Shed those extra pounds with MSN and The Biggest Loser! Learn > more. > > > > > Connect and share in new ways with Windows Live. Get it now! From jayk123 at hotmail.com Mon Feb 4 07:23:09 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 4 Feb 2008 06:23:09 +0000 Subject: [M3devel] stdcall naming discrepancy? In-Reply-To: <20080204054529.A4C4F10D4611@birch.elegosoft.com> References: <20080204054529.A4C4F10D4611@birch.elegosoft.com> Message-ID: (and codegen..) C:\dev2\j\m3\t>type t.c typedef struct { int a,b,c,d,e,f;} Foo_t; void __stdcall Sleep(Foo_t foo); extern Foo_t a; void F1(){ Sleep(a);} C:\dev2\j\m3\t>gcc -c -S t.c C:\dev2\j\m3\t>type t.s .file "t.c" .text.globl _F1 .def _F1; .scl 2; .type 32; .endef_F1: pushl %ebp movl %esp, %ebp subl $24, %esp movl _a, %eax movl %eax, (%esp) movl _a+4, %eax movl %eax, 4(%esp) movl _a+8, %eax movl %eax, 8(%esp) movl _a+12, %eax movl %eax, 12(%esp) movl _a+16, %eax movl %eax, 16(%esp) movl _a+20, %eax movl %eax, 20(%esp) call _Sleep at 24 subl $24, %esp leave ret C:\dev2\j\m3\t>(NOTE: This is NOT the correct declaration of Sleep, but ok for testing purposes.) C:\dev2\j\m3\t>type t.i3INTERFACE T; TYPE Foo_t = RECORD a,b,c,d,e,f : INTEGER;END; <*EXTERNAL Sleep:WINAPI*>PROCEDURE Sleep (dwMilliseconds1: Foo_t); END T. C:\dev2\j\m3\t>type t.m3 MODULE T; VAR Foo: Foo_t; BEGIN Sleep(Foo);END T. LM1: movl 8(%ebp), %eax xorl $1, %eax testb %al, %al jne L2 .stabn 68,0,6,LM2-_T_M3LM2: movl $_MM_T+52, %eax movl %eax, %edx subl $8, %esp subl $24, %esp movl %esp, %eax movl %eax, %edi movl %edx, %esi cld movl $6, %eax movl %eax, %ecx rep movsl call _Sleep at 4 addl $8, %espL2: movl $_MM_T, %eaxLBE2: leal -8(%ebp), %esp popl %esi popl %edi leave ret ? - Jay _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Feb 4 15:52:31 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 4 Feb 2008 09:52:31 -0500 Subject: [M3devel] stdcall naming discrepancy? In-Reply-To: References: <20080204054529.A4C4F10D4611@birch.elegosoft.com> Message-ID: Any chance that standard_structs in Target.i3 is causing the front- end to pass structs by reference (standard structs=TRUE)? Also, looking at pop_struct in parse.c it seems to want to pass them by reference (standard_structs=FALSE)? In any case, what does the integrated back-end do with pop_struct? I bet it is passing by value... whereas parse.c passes by ref. Blurgh! Looks like we need to smarten things up for calls to non-M3 stdcall procedures. On Feb 4, 2008, at 1:23 AM, Jay wrote: > (and codegen..) > > C:\dev2\j\m3\t>type t.c > > typedef struct { > int a,b,c,d,e,f; > } Foo_t; > > void __stdcall Sleep(Foo_t foo); > > extern Foo_t a; > > void F1() > { > Sleep(a); > } > > C:\dev2\j\m3\t>gcc -c -S t.c > > C:\dev2\j\m3\t>type t.s > .file "t.c" > .text > .globl _F1 > .def _F1; .scl 2; .type 32; .endef > _F1: > pushl %ebp > movl %esp, %ebp > subl $24, %esp > movl _a, %eax > movl %eax, (%esp) > movl _a+4, %eax > movl %eax, 4(%esp) > movl _a+8, %eax > movl %eax, 8(%esp) > movl _a+12, %eax > movl %eax, 12(%esp) > movl _a+16, %eax > movl %eax, 16(%esp) > movl _a+20, %eax > movl %eax, 20(%esp) > call _Sleep at 24 > subl $24, %esp > leave > ret > C:\dev2\j\m3\t> > > (NOTE: This is NOT the correct declaration of Sleep, but ok for > testing purposes.) > > C:\dev2\j\m3\t>type t.i3 > INTERFACE T; > > TYPE Foo_t = RECORD > a,b,c,d,e,f : INTEGER; > END; > > <*EXTERNAL Sleep:WINAPI*> > PROCEDURE Sleep (dwMilliseconds1: Foo_t); > END T. > > C:\dev2\j\m3\t>type t.m3 > > MODULE T; > VAR > Foo: Foo_t; > > BEGIN > Sleep(Foo); > END T. > > > LM1: > movl 8(%ebp), %eax > xorl $1, %eax > testb %al, %al > jne L2 > .stabn 68,0,6,LM2-_T_M3 > LM2: > movl $_MM_T+52, %eax > movl %eax, %edx > subl $8, %esp > subl $24, %esp > movl %esp, %eax > movl %eax, %edi > movl %edx, %esi > cld > movl $6, %eax > movl %eax, %ecx > rep > movsl > call _Sleep at 4 > addl $8, %esp > L2: > movl $_MM_T, %eax > LBE2: > leal -8(%ebp), %esp > popl %esi > popl %edi > leave > ret > > ? > > - Jay > > Connect and share in new ways with Windows Live. Get it now! From jayk123 at hotmail.com Mon Feb 4 20:43:43 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 4 Feb 2008 19:43:43 +0000 Subject: [M3devel] stdcall naming discrepancy? In-Reply-To: References: <20080204054529.A4C4F10D4611@birch.elegosoft.com> Message-ID: I think they are being passed correctly, by value. pop_struct and not pop_param is used. When I get time, I will put my parse.c back (uncommited) and then just try some tests with "__cdecl" passing and returning structs. That removes the naming issue and PART of the calling convention issue and tests what is left. Then I'll see if I can hack something up to test the rest. - Jay > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: stdcall naming discrepancy?> Date: Mon, 4 Feb 2008 09:52:31 -0500> To: jayk123 at hotmail.com> > Any chance that standard_structs in Target.i3 is causing the front- > end to pass structs by reference (standard structs=TRUE)? Also, > looking at pop_struct in parse.c it seems to want to pass them by > reference (standard_structs=FALSE)? In any case, what does the > integrated back-end do with pop_struct? I bet it is passing by > value... whereas parse.c passes by ref. Blurgh! Looks like we need > to smarten things up for calls to non-M3 stdcall procedures.> > On Feb 4, 2008, at 1:23 AM, Jay wrote:> > > (and codegen..)> >> > C:\dev2\j\m3\t>type t.c> >> > typedef struct {> > int a,b,c,d,e,f;> > } Foo_t;> >> > void __stdcall Sleep(Foo_t foo);> >> > extern Foo_t a;> >> > void F1()> > {> > Sleep(a);> > }> >> > C:\dev2\j\m3\t>gcc -c -S t.c> >> > C:\dev2\j\m3\t>type t.s> > .file "t.c"> > .text> > .globl _F1> > .def _F1; .scl 2; .type 32; .endef> > _F1:> > pushl %ebp> > movl %esp, %ebp> > subl $24, %esp> > movl _a, %eax> > movl %eax, (%esp)> > movl _a+4, %eax> > movl %eax, 4(%esp)> > movl _a+8, %eax> > movl %eax, 8(%esp)> > movl _a+12, %eax> > movl %eax, 12(%esp)> > movl _a+16, %eax> > movl %eax, 16(%esp)> > movl _a+20, %eax> > movl %eax, 20(%esp)> > call _Sleep at 24> > subl $24, %esp> > leave> > ret> > C:\dev2\j\m3\t>> >> > (NOTE: This is NOT the correct declaration of Sleep, but ok for > > testing purposes.)> >> > C:\dev2\j\m3\t>type t.i3> > INTERFACE T;> >> > TYPE Foo_t = RECORD> > a,b,c,d,e,f : INTEGER;> > END;> >> > <*EXTERNAL Sleep:WINAPI*>> > PROCEDURE Sleep (dwMilliseconds1: Foo_t);> > END T.> >> > C:\dev2\j\m3\t>type t.m3> >> > MODULE T;> > VAR> > Foo: Foo_t;> >> > BEGIN> > Sleep(Foo);> > END T.> >> >> > LM1:> > movl 8(%ebp), %eax> > xorl $1, %eax> > testb %al, %al> > jne L2> > .stabn 68,0,6,LM2-_T_M3> > LM2:> > movl $_MM_T+52, %eax> > movl %eax, %edx> > subl $8, %esp> > subl $24, %esp> > movl %esp, %eax> > movl %eax, %edi> > movl %edx, %esi> > cld> > movl $6, %eax> > movl %eax, %ecx> > rep> > movsl> > call _Sleep at 4> > addl $8, %esp> > L2:> > movl $_MM_T, %eax> > LBE2:> > leal -8(%ebp), %esp> > popl %esi> > popl %edi> > leave> > ret> >> > ?> >> > - Jay> >> > Connect and share in new ways with Windows Live. Get it now!> _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Feb 4 20:46:00 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 4 Feb 2008 19:46:00 +0000 Subject: [M3devel] stdcall naming discrepancy? In-Reply-To: References: <20080204054529.A4C4F10D4611@birch.elegosoft.com> Message-ID: > value... whereas parse.c passes by ref. Blurgh! Looks like we need > to smarten things up for calls to non-M3 stdcall procedures. ps: m3 or not m3 I would think. stdcall is stdcall, independent of the implementing language. Though sure, the C declaration could declare the thing by const pointer. Given some existing unchanged C declarations for "callbacks" however, I should be able to implement them in M3. - Jay > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: stdcall naming discrepancy?> Date: Mon, 4 Feb 2008 09:52:31 -0500> To: jayk123 at hotmail.com> > Any chance that standard_structs in Target.i3 is causing the front- > end to pass structs by reference (standard structs=TRUE)? Also, > looking at pop_struct in parse.c it seems to want to pass them by > reference (standard_structs=FALSE)? In any case, what does the > integrated back-end do with pop_struct? I bet it is passing by > value... whereas parse.c passes by ref. Blurgh! Looks like we need > to smarten things up for calls to non-M3 stdcall procedures.> > On Feb 4, 2008, at 1:23 AM, Jay wrote:> > > (and codegen..)> >> > C:\dev2\j\m3\t>type t.c> >> > typedef struct {> > int a,b,c,d,e,f;> > } Foo_t;> >> > void __stdcall Sleep(Foo_t foo);> >> > extern Foo_t a;> >> > void F1()> > {> > Sleep(a);> > }> >> > C:\dev2\j\m3\t>gcc -c -S t.c> >> > C:\dev2\j\m3\t>type t.s> > .file "t.c"> > .text> > .globl _F1> > .def _F1; .scl 2; .type 32; .endef> > _F1:> > pushl %ebp> > movl %esp, %ebp> > subl $24, %esp> > movl _a, %eax> > movl %eax, (%esp)> > movl _a+4, %eax> > movl %eax, 4(%esp)> > movl _a+8, %eax> > movl %eax, 8(%esp)> > movl _a+12, %eax> > movl %eax, 12(%esp)> > movl _a+16, %eax> > movl %eax, 16(%esp)> > movl _a+20, %eax> > movl %eax, 20(%esp)> > call _Sleep at 24> > subl $24, %esp> > leave> > ret> > C:\dev2\j\m3\t>> >> > (NOTE: This is NOT the correct declaration of Sleep, but ok for > > testing purposes.)> >> > C:\dev2\j\m3\t>type t.i3> > INTERFACE T;> >> > TYPE Foo_t = RECORD> > a,b,c,d,e,f : INTEGER;> > END;> >> > <*EXTERNAL Sleep:WINAPI*>> > PROCEDURE Sleep (dwMilliseconds1: Foo_t);> > END T.> >> > C:\dev2\j\m3\t>type t.m3> >> > MODULE T;> > VAR> > Foo: Foo_t;> >> > BEGIN> > Sleep(Foo);> > END T.> >> >> > LM1:> > movl 8(%ebp), %eax> > xorl $1, %eax> > testb %al, %al> > jne L2> > .stabn 68,0,6,LM2-_T_M3> > LM2:> > movl $_MM_T+52, %eax> > movl %eax, %edx> > subl $8, %esp> > subl $24, %esp> > movl %esp, %eax> > movl %eax, %edi> > movl %edx, %esi> > cld> > movl $6, %eax> > movl %eax, %ecx> > rep> > movsl> > call _Sleep at 4> > addl $8, %esp> > L2:> > movl $_MM_T, %eax> > LBE2:> > leal -8(%ebp), %esp> > popl %esi> > popl %edi> > leave> > ret> >> > ?> >> > - Jay> >> > Connect and share in new ways with Windows Live. Get it now!> _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Feb 4 21:30:23 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 4 Feb 2008 15:30:23 -0500 Subject: [M3devel] stdcall naming discrepancy? In-Reply-To: References: <20080204054529.A4C4F10D4611@birch.elegosoft.com> Message-ID: <05A22848-0B42-4827-B161-A780949D0707@cs.purdue.edu> OK. Not sure I understand what is going on then -- I would like to see the .mc file to get a sense of things. On Feb 4, 2008, at 2:43 PM, Jay wrote: > I think they are being passed correctly, by value. pop_struct and > not pop_param is used. > When I get time, I will put my parse.c back (uncommited) and then > just try some tests with "__cdecl" passing and returning structs. > That removes the naming issue and PART of the calling convention > issue and tests what is left. > Then I'll see if I can hack something up to test the rest. > > - Jay > > > > > CC: m3devel at elegosoft.com > > From: hosking at cs.purdue.edu > > Subject: Re: stdcall naming discrepancy? > > Date: Mon, 4 Feb 2008 09:52:31 -0500 > > To: jayk123 at hotmail.com > > > > Any chance that standard_structs in Target.i3 is causing the front- > > end to pass structs by reference (standard structs=TRUE)? Also, > > looking at pop_struct in parse.c it seems to want to pass them by > > reference (standard_structs=FALSE)? In any case, what does the > > integrated back-end do with pop_struct? I bet it is passing by > > value... whereas parse.c passes by ref. Blurgh! Looks like we need > > to smarten things up for calls to non-M3 stdcall procedures. > > > > On Feb 4, 2008, at 1:23 AM, Jay wrote: > > > > > (and codegen..) > > > > > > C:\dev2\j\m3\t>type t.c > > > > > > typedef struct { > > > int a,b,c,d,e,f; > > > } Foo_t; > > > > > > void __stdcall Sleep(Foo_t foo); > > > > > > extern Foo_t a; > > > > > > void F1() > > > { > > > Sleep(a); > > > } > > > > > > C:\dev2\j\m3\t>gcc -c -S t.c > > > > > > C:\dev2\j\m3\t>type t.s > > > .file "t.c" > > > .text > > > .globl _F1 > > > .def _F1; .scl 2; .type 32; .endef > > > _F1: > > > pushl %ebp > > > movl %esp, %ebp > > > subl $24, %esp > > > movl _a, %eax > > > movl %eax, (%esp) > > > movl _a+4, %eax > > > movl %eax, 4(%esp) > > > movl _a+8, %eax > > > movl %eax, 8(%esp) > > > movl _a+12, %eax > > > movl %eax, 12(%esp) > > > movl _a+16, %eax > > > movl %eax, 16(%esp) > > > movl _a+20, %eax > > > movl %eax, 20(%esp) > > > call _Sleep at 24 > > > subl $24, %esp > > > leave > > > ret > > > C:\dev2\j\m3\t> > > > > > > (NOTE: This is NOT the correct declaration of Sleep, but ok for > > > testing purposes.) > > > > > > C:\dev2\j\m3\t>type t.i3 > > > INTERFACE T; > > > > > > TYPE Foo_t = RECORD > > > a,b,c,d,e,f : INTEGER; > > > END; > > > > > > <*EXTERNAL Sleep:WINAPI*> > > > PROCEDURE Sleep (dwMilliseconds1: Foo_t); > > > END T. > > > > > > C:\dev2\j\m3\t>type t.m3 > > > > > > MODULE T; > > > VAR > > > Foo: Foo_t; > > > > > > BEGIN > > > Sleep(Foo); > > > END T. > > > > > > > > > LM1: > > > movl 8(%ebp), %eax > > > xorl $1, %eax > > > testb %al, %al > > > jne L2 > > > .stabn 68,0,6,LM2-_T_M3 > > > LM2: > > > movl $_MM_T+52, %eax > > > movl %eax, %edx > > > subl $8, %esp > > > subl $24, %esp > > > movl %esp, %eax > > > movl %eax, %edi > > > movl %edx, %esi > > > cld > > > movl $6, %eax > > > movl %eax, %ecx > > > rep > > > movsl > > > call _Sleep at 4 > > > addl $8, %esp > > > L2: > > > movl $_MM_T, %eax > > > LBE2: > > > leal -8(%ebp), %esp > > > popl %esi > > > popl %edi > > > leave > > > ret > > > > > > ? > > > > > > - Jay > > > > > > Connect and share in new ways with Windows Live. Get it now! > > > > > Climb to the top of the charts! Play the word scramble challenge > with star power. Play now! From hosking at cs.purdue.edu Mon Feb 4 21:30:59 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 4 Feb 2008 15:30:59 -0500 Subject: [M3devel] stdcall naming discrepancy? In-Reply-To: References: <20080204054529.A4C4F10D4611@birch.elegosoft.com> Message-ID: I don't think I follow you. On Feb 4, 2008, at 2:46 PM, Jay wrote: > > value... whereas parse.c passes by ref. Blurgh! Looks like we need > > to smarten things up for calls to non-M3 stdcall procedures. > > ps: m3 or not m3 I would think. stdcall is stdcall, independent of > the implementing language. > Though sure, the C declaration could declare the thing by const > pointer. > > Given some existing unchanged C declarations for "callbacks" > however, I should be able to implement them in M3. > > - Jay > > > > > CC: m3devel at elegosoft.com > > From: hosking at cs.purdue.edu > > Subject: Re: stdcall naming discrepancy? > > Date: Mon, 4 Feb 2008 09:52:31 -0500 > > To: jayk123 at hotmail.com > > > > Any chance that standard_structs in Target.i3 is causing the front- > > end to pass structs by reference (standard structs=TRUE)? Also, > > looking at pop_struct in parse.c it seems to want to pass them by > > reference (standard_structs=FALSE)? In any case, what does the > > integrated back-end do with pop_struct? I bet it is passing by > > value... whereas parse.c passes by ref. Blurgh! Looks like we need > > to smarten things up for calls to non-M3 stdcall procedures. > > > > On Feb 4, 2008, at 1:23 AM, Jay wrote: > > > > > (and codegen..) > > > > > > C:\dev2\j\m3\t>type t.c > > > > > > typedef struct { > > > int a,b,c,d,e,f; > > > } Foo_t; > > > > > > void __stdcall Sleep(Foo_t foo); > > > > > > extern Foo_t a; > > > > > > void F1() > > > { > > > Sleep(a); > > > } > > > > > > C:\dev2\j\m3\t>gcc -c -S t.c > > > > > > C:\dev2\j\m3\t>type t.s > > > .file "t.c" > > > .text > > > .globl _F1 > > > .def _F1; .scl 2; .type 32; .endef > > > _F1: > > > pushl %ebp > > > movl %esp, %ebp > > > subl $24, %esp > > > movl _a, %eax > > > movl %eax, (%esp) > > > movl _a+4, %eax > > > movl %eax, 4(%esp) > > > movl _a+8, %eax > > > movl %eax, 8(%esp) > > > movl _a+12, %eax > > > movl %eax, 12(%esp) > > > movl _a+16, %eax > > > movl %eax, 16(%esp) > > > movl _a+20, %eax > > > movl %eax, 20(%esp) > > > call _Sleep at 24 > > > subl $24, %esp > > > leave > > > ret > > > C:\dev2\j\m3\t> > > > > > > (NOTE: This is NOT the correct declaration of Sleep, but ok for > > > testing purposes.) > > > > > > C:\dev2\j\m3\t>type t.i3 > > > INTERFACE T; > > > > > > TYPE Foo_t = RECORD > > > a,b,c,d,e,f : INTEGER; > > > END; > > > > > > <*EXTERNAL Sleep:WINAPI*> > > > PROCEDURE Sleep (dwMilliseconds1: Foo_t); > > > END T. > > > > > > C:\dev2\j\m3\t>type t.m3 > > > > > > MODULE T; > > > VAR > > > Foo: Foo_t; > > > > > > BEGIN > > > Sleep(Foo); > > > END T. > > > > > > > > > LM1: > > > movl 8(%ebp), %eax > > > xorl $1, %eax > > > testb %al, %al > > > jne L2 > > > .stabn 68,0,6,LM2-_T_M3 > > > LM2: > > > movl $_MM_T+52, %eax > > > movl %eax, %edx > > > subl $8, %esp > > > subl $24, %esp > > > movl %esp, %eax > > > movl %eax, %edi > > > movl %edx, %esi > > > cld > > > movl $6, %eax > > > movl %eax, %ecx > > > rep > > > movsl > > > call _Sleep at 4 > > > addl $8, %esp > > > L2: > > > movl $_MM_T, %eax > > > LBE2: > > > leal -8(%ebp), %esp > > > popl %esi > > > popl %edi > > > leave > > > ret > > > > > > ? > > > > > > - Jay > > > > > > Connect and share in new ways with Windows Live. Get it now! > > > > > Helping your favorite cause is as easy as instant messaging. You > IM, we give. Learn more. From jayk123 at hotmail.com Mon Feb 4 21:38:28 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 4 Feb 2008 20:38:28 +0000 Subject: [M3devel] stdcall naming discrepancy? In-Reply-To: References: <20080204054529.A4C4F10D4611@birch.elegosoft.com> Message-ID: > > > to smarten things up for calls to non-M3 stdcall procedures. Why is the smartening specific to non-M3 procedures?I should be able to write stdcall functions in M3 as well, that take and return structs, I am so inclined or "forced". (Arguably, it should be the default. It is slightly more efficient.) - Jay > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: stdcall naming discrepancy?> Date: Mon, 4 Feb 2008 15:30:59 -0500> To: jayk123 at hotmail.com> > I don't think I follow you.> > On Feb 4, 2008, at 2:46 PM, Jay wrote:> > > > value... whereas parse.c passes by ref. Blurgh! Looks like we need> > > to smarten things up for calls to non-M3 stdcall procedures.> >> > ps: m3 or not m3 I would think. stdcall is stdcall, independent of > > the implementing language.> > Though sure, the C declaration could declare the thing by const > > pointer.> >> > Given some existing unchanged C declarations for "callbacks" > > however, I should be able to implement them in M3.> >> > - Jay> >> >> >> > > CC: m3devel at elegosoft.com> > > From: hosking at cs.purdue.edu> > > Subject: Re: stdcall naming discrepancy?> > > Date: Mon, 4 Feb 2008 09:52:31 -0500> > > To: jayk123 at hotmail.com> > >> > > Any chance that standard_structs in Target.i3 is causing the front-> > > end to pass structs by reference (standard structs=TRUE)? Also,> > > looking at pop_struct in parse.c it seems to want to pass them by> > > reference (standard_structs=FALSE)? In any case, what does the> > > integrated back-end do with pop_struct? I bet it is passing by> > > value... whereas parse.c passes by ref. Blurgh! Looks like we need> > > to smarten things up for calls to non-M3 stdcall procedures.> > >> > > On Feb 4, 2008, at 1:23 AM, Jay wrote:> > >> > > > (and codegen..)> > > >> > > > C:\dev2\j\m3\t>type t.c> > > >> > > > typedef struct {> > > > int a,b,c,d,e,f;> > > > } Foo_t;> > > >> > > > void __stdcall Sleep(Foo_t foo);> > > >> > > > extern Foo_t a;> > > >> > > > void F1()> > > > {> > > > Sleep(a);> > > > }> > > >> > > > C:\dev2\j\m3\t>gcc -c -S t.c> > > >> > > > C:\dev2\j\m3\t>type t.s> > > > .file "t.c"> > > > .text> > > > .globl _F1> > > > .def _F1; .scl 2; .type 32; .endef> > > > _F1:> > > > pushl %ebp> > > > movl %esp, %ebp> > > > subl $24, %esp> > > > movl _a, %eax> > > > movl %eax, (%esp)> > > > movl _a+4, %eax> > > > movl %eax, 4(%esp)> > > > movl _a+8, %eax> > > > movl %eax, 8(%esp)> > > > movl _a+12, %eax> > > > movl %eax, 12(%esp)> > > > movl _a+16, %eax> > > > movl %eax, 16(%esp)> > > > movl _a+20, %eax> > > > movl %eax, 20(%esp)> > > > call _Sleep at 24> > > > subl $24, %esp> > > > leave> > > > ret> > > > C:\dev2\j\m3\t>> > > >> > > > (NOTE: This is NOT the correct declaration of Sleep, but ok for> > > > testing purposes.)> > > >> > > > C:\dev2\j\m3\t>type t.i3> > > > INTERFACE T;> > > >> > > > TYPE Foo_t = RECORD> > > > a,b,c,d,e,f : INTEGER;> > > > END;> > > >> > > > <*EXTERNAL Sleep:WINAPI*>> > > > PROCEDURE Sleep (dwMilliseconds1: Foo_t);> > > > END T.> > > >> > > > C:\dev2\j\m3\t>type t.m3> > > >> > > > MODULE T;> > > > VAR> > > > Foo: Foo_t;> > > >> > > > BEGIN> > > > Sleep(Foo);> > > > END T.> > > >> > > >> > > > LM1:> > > > movl 8(%ebp), %eax> > > > xorl $1, %eax> > > > testb %al, %al> > > > jne L2> > > > .stabn 68,0,6,LM2-_T_M3> > > > LM2:> > > > movl $_MM_T+52, %eax> > > > movl %eax, %edx> > > > subl $8, %esp> > > > subl $24, %esp> > > > movl %esp, %eax> > > > movl %eax, %edi> > > > movl %edx, %esi> > > > cld> > > > movl $6, %eax> > > > movl %eax, %ecx> > > > rep> > > > movsl> > > > call _Sleep at 4> > > > addl $8, %esp> > > > L2:> > > > movl $_MM_T, %eax> > > > LBE2:> > > > leal -8(%ebp), %esp> > > > popl %esi> > > > popl %edi> > > > leave> > > > ret> > > >> > > > ?> > > >> > > > - Jay> > > >> > > > Connect and share in new ways with Windows Live. Get it now!> > >> >> >> > Helping your favorite cause is as easy as instant messaging. You > > IM, we give. Learn more.> _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Feb 4 21:51:01 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 4 Feb 2008 20:51:01 +0000 Subject: [M3devel] bootstrapping from old versions? In-Reply-To: <05A22848-0B42-4827-B161-A780949D0707@cs.purdue.edu> References: <20080204054529.A4C4F10D4611@birch.elegosoft.com> <05A22848-0B42-4827-B161-A780949D0707@cs.purdue.edu> Message-ID: It appears by quick/lazy inspection, that bootstrapping from, say, 5.1.3, just stopped working. m3quake => sysutils => libm3/TextExtras but TextExtras is not in 5.1.3. Ok? It looks like 5.1.8 will do. I'll try it. - Jay _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Feb 4 22:01:44 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 4 Feb 2008 21:01:44 +0000 Subject: [M3devel] stdcall naming discrepancy? In-Reply-To: <05A22848-0B42-4827-B161-A780949D0707@cs.purdue.edu> References: <20080204054529.A4C4F10D4611@birch.elegosoft.com> <05A22848-0B42-4827-B161-A780949D0707@cs.purdue.edu> Message-ID: This is without your most recent changes. > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: stdcall naming discrepancy?> Date: Mon, 4 Feb 2008 15:30:23 -0500> To: jayk123 at hotmail.com> > OK. Not sure I understand what is going on then -- I would like to > see the .mc file to get a sense of things.> > On Feb 4, 2008, at 2:43 PM, Jay wrote:> > > I think they are being passed correctly, by value. pop_struct and > > not pop_param is used.> > When I get time, I will put my parse.c back (uncommited) and then > > just try some tests with "__cdecl" passing and returning structs. > > That removes the naming issue and PART of the calling convention > > issue and tests what is left.> > Then I'll see if I can hack something up to test the rest.> >> > - Jay> >> >> >> > > CC: m3devel at elegosoft.com> > > From: hosking at cs.purdue.edu> > > Subject: Re: stdcall naming discrepancy?> > > Date: Mon, 4 Feb 2008 09:52:31 -0500> > > To: jayk123 at hotmail.com> > >> > > Any chance that standard_structs in Target.i3 is causing the front-> > > end to pass structs by reference (standard structs=TRUE)? Also,> > > looking at pop_struct in parse.c it seems to want to pass them by> > > reference (standard_structs=FALSE)? In any case, what does the> > > integrated back-end do with pop_struct? I bet it is passing by> > > value... whereas parse.c passes by ref. Blurgh! Looks like we need> > > to smarten things up for calls to non-M3 stdcall procedures.> > >> > > On Feb 4, 2008, at 1:23 AM, Jay wrote:> > >> > > > (and codegen..)> > > >> > > > C:\dev2\j\m3\t>type t.c> > > >> > > > typedef struct {> > > > int a,b,c,d,e,f;> > > > } Foo_t;> > > >> > > > void __stdcall Sleep(Foo_t foo);> > > >> > > > extern Foo_t a;> > > >> > > > void F1()> > > > {> > > > Sleep(a);> > > > }> > > >> > > > C:\dev2\j\m3\t>gcc -c -S t.c> > > >> > > > C:\dev2\j\m3\t>type t.s> > > > .file "t.c"> > > > .text> > > > .globl _F1> > > > .def _F1; .scl 2; .type 32; .endef> > > > _F1:> > > > pushl %ebp> > > > movl %esp, %ebp> > > > subl $24, %esp> > > > movl _a, %eax> > > > movl %eax, (%esp)> > > > movl _a+4, %eax> > > > movl %eax, 4(%esp)> > > > movl _a+8, %eax> > > > movl %eax, 8(%esp)> > > > movl _a+12, %eax> > > > movl %eax, 12(%esp)> > > > movl _a+16, %eax> > > > movl %eax, 16(%esp)> > > > movl _a+20, %eax> > > > movl %eax, 20(%esp)> > > > call _Sleep at 24> > > > subl $24, %esp> > > > leave> > > > ret> > > > C:\dev2\j\m3\t>> > > >> > > > (NOTE: This is NOT the correct declaration of Sleep, but ok for> > > > testing purposes.)> > > >> > > > C:\dev2\j\m3\t>type t.i3> > > > INTERFACE T;> > > >> > > > TYPE Foo_t = RECORD> > > > a,b,c,d,e,f : INTEGER;> > > > END;> > > >> > > > <*EXTERNAL Sleep:WINAPI*>> > > > PROCEDURE Sleep (dwMilliseconds1: Foo_t);> > > > END T.> > > >> > > > C:\dev2\j\m3\t>type t.m3> > > >> > > > MODULE T;> > > > VAR> > > > Foo: Foo_t;> > > >> > > > BEGIN> > > > Sleep(Foo);> > > > END T.> > > >> > > >> > > > LM1:> > > > movl 8(%ebp), %eax> > > > xorl $1, %eax> > > > testb %al, %al> > > > jne L2> > > > .stabn 68,0,6,LM2-_T_M3> > > > LM2:> > > > movl $_MM_T+52, %eax> > > > movl %eax, %edx> > > > subl $8, %esp> > > > subl $24, %esp> > > > movl %esp, %eax> > > > movl %eax, %edi> > > > movl %edx, %esi> > > > cld> > > > movl $6, %eax> > > > movl %eax, %ecx> > > > rep> > > > movsl> > > > call _Sleep at 4> > > > addl $8, %esp> > > > L2:> > > > movl $_MM_T, %eax> > > > LBE2:> > > > leal -8(%ebp), %esp> > > > popl %esi> > > > popl %edi> > > > leave> > > > ret> > > >> > > > ?> > > >> > > > - Jay> > > >> > > > Connect and share in new ways with Windows Live. Get it now!> > >> >> >> > Climb to the top of the charts! Play the word scramble challenge > > with star power. Play now!> _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: t.tar.bz2 Type: application/octet-stream Size: 4484 bytes Desc: not available URL: From hosking at cs.purdue.edu Mon Feb 4 22:05:00 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 4 Feb 2008 16:05:00 -0500 Subject: [M3devel] stdcall naming discrepancy? In-Reply-To: References: <20080204054529.A4C4F10D4611@birch.elegosoft.com> Message-ID: <927CD38A-8DA0-4963-83D4-265C9098BDCC@cs.purdue.edu> I agree. I was suspicious of the standard_structs flag -- you probably know better than I do what it is supposed to do. On Feb 4, 2008, at 3:38 PM, Jay wrote: > > > > to smarten things up for calls to non-M3 stdcall procedures. > > Why is the smartening specific to non-M3 procedures? > I should be able to write stdcall functions in M3 as well, that > take and return structs, I am so inclined or "forced". > (Arguably, it should be the default. It is slightly more efficient.) > > - Jay > > > > > CC: m3devel at elegosoft.com > > From: hosking at cs.purdue.edu > > Subject: Re: stdcall naming discrepancy? > > Date: Mon, 4 Feb 2008 15:30:59 -0500 > > To: jayk123 at hotmail.com > > > > I don't think I follow you. > > > > On Feb 4, 2008, at 2:46 PM, Jay wrote: > > > > > > value... whereas parse.c passes by ref. Blurgh! Looks like we > need > > > > to smarten things up for calls to non-M3 stdcall procedures. > > > > > > ps: m3 or not m3 I would think. stdcall is stdcall, independent of > > > the implementing language. > > > Though sure, the C declaration could declare the thing by const > > > pointer. > > > > > > Given some existing unchanged C declarations for "callbacks" > > > however, I should be able to implement them in M3. > > > > > > - Jay > > > > > > > > > > > > > CC: m3devel at elegosoft.com > > > > From: hosking at cs.purdue.edu > > > > Subject: Re: stdcall naming discrepancy? > > > > Date: Mon, 4 Feb 2008 09:52:31 -0500 > > > > To: jayk123 at hotmail.com > > > > > > > > Any chance that standard_structs in Target.i3 is causing the > front- > > > > end to pass structs by reference (standard structs=TRUE)? Also, > > > > looking at pop_struct in parse.c it seems to want to pass > them by > > > > reference (standard_structs=FALSE)? In any case, what does the > > > > integrated back-end do with pop_struct? I bet it is passing by > > > > value... whereas parse.c passes by ref. Blurgh! Looks like we > need > > > > to smarten things up for calls to non-M3 stdcall procedures. > > > > > > > > On Feb 4, 2008, at 1:23 AM, Jay wrote: > > > > > > > > > (and codegen..) > > > > > > > > > > C:\dev2\j\m3\t>type t.c > > > > > > > > > > typedef struct { > > > > > int a,b,c,d,e,f; > > > > > } Foo_t; > > > > > > > > > > void __stdcall Sleep(Foo_t foo); > > > > > > > > > > extern Foo_t a; > > > > > > > > > > void F1() > > > > > { > > > > > Sleep(a); > > > > > } > > > > > > > > > > C:\dev2\j\m3\t>gcc -c -S t.c > > > > > > > > > > C:\dev2\j\m3\t>type t.s > > > > > .file "t.c" > > > > > .text > > > > > .globl _F1 > > > > > .def _F1; .scl 2; .type 32; .endef > > > > > _F1: > > > > > pushl %ebp > > > > > movl %esp, %ebp > > > > > subl $24, %esp > > > > > movl _a, %eax > > > > > movl %eax, (%esp) > > > > > movl _a+4, %eax > > > > > movl %eax, 4(%esp) > > > > > movl _a+8, %eax > > > > > movl %eax, 8(%esp) > > > > > movl _a+12, %eax > > > > > movl %eax, 12(%esp) > > > > > movl _a+16, %eax > > > > > movl %eax, 16(%esp) > > > > > movl _a+20, %eax > > > > > movl %eax, 20(%esp) > > > > > call _Sleep at 24 > > > > > subl $24, %esp > > > > > leave > > > > > ret > > > > > C:\dev2\j\m3\t> > > > > > > > > > > (NOTE: This is NOT the correct declaration of Sleep, but ok > for > > > > > testing purposes.) > > > > > > > > > > C:\dev2\j\m3\t>type t.i3 > > > > > INTERFACE T; > > > > > > > > > > TYPE Foo_t = RECORD > > > > > a,b,c,d,e,f : INTEGER; > > > > > END; > > > > > > > > > > <*EXTERNAL Sleep:WINAPI*> > > > > > PROCEDURE Sleep (dwMilliseconds1: Foo_t); > > > > > END T. > > > > > > > > > > C:\dev2\j\m3\t>type t.m3 > > > > > > > > > > MODULE T; > > > > > VAR > > > > > Foo: Foo_t; > > > > > > > > > > BEGIN > > > > > Sleep(Foo); > > > > > END T. > > > > > > > > > > > > > > > LM1: > > > > > movl 8(%ebp), %eax > > > > > xorl $1, %eax > > > > > testb %al, %al > > > > > jne L2 > > > > > .stabn 68,0,6,LM2-_T_M3 > > > > > LM2: > > > > > movl $_MM_T+52, %eax > > > > > movl %eax, %edx > > > > > subl $8, %esp > > > > > subl $24, %esp > > > > > movl %esp, %eax > > > > > movl %eax, %edi > > > > > movl %edx, %esi > > > > > cld > > > > > movl $6, %eax > > > > > movl %eax, %ecx > > > > > rep > > > > > movsl > > > > > call _Sleep at 4 > > > > > addl $8, %esp > > > > > L2: > > > > > movl $_MM_T, %eax > > > > > LBE2: > > > > > leal -8(%ebp), %esp > > > > > popl %esi > > > > > popl %edi > > > > > leave > > > > > ret > > > > > > > > > > ? > > > > > > > > > > - Jay > > > > > > > > > > Connect and share in new ways with Windows Live. Get it now! > > > > > > > > > > > > > Helping your favorite cause is as easy as instant messaging. You > > > IM, we give. Learn more. > > > > > Need to know the score, the latest news, or you need your Hotmail?- > get your "fix". Check it out. From jayk123 at hotmail.com Mon Feb 4 22:09:50 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 4 Feb 2008 21:09:50 +0000 Subject: [M3devel] bootstrapping from old versions? In-Reply-To: <05A22848-0B42-4827-B161-A780949D0707@cs.purdue.edu> References: <20080204054529.A4C4F10D4611@birch.elegosoft.com> <05A22848-0B42-4827-B161-A780949D0707@cs.purdue.edu> Message-ID: 5.1.8 worked From: jayk123 at hotmail.comTo: wagner at elegosoft.com; m3devel at elegosoft.comSubject: bootstrapping from old versions?Date: Mon, 4 Feb 2008 20:51:01 +0000 It appears by quick/lazy inspection, that bootstrapping from, say, 5.1.3, just stopped working.m3quake => sysutils => libm3/TextExtrasbut TextExtras is not in 5.1.3. Ok? It looks like 5.1.8 will do.I'll try it. - Jay _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Feb 4 22:19:38 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 4 Feb 2008 16:19:38 -0500 Subject: [M3devel] stdcall naming discrepancy? In-Reply-To: References: <20080204054529.A4C4F10D4611@birch.elegosoft.com> <05A22848-0B42-4827-B161-A780949D0707@cs.purdue.edu> Message-ID: Jay, I'm not on Windows so I can't diagnose the stdcall problem. I want to see the .mc file so I can get a sense of what is going on. On Feb 4, 2008, at 4:01 PM, Jay wrote: > This is without your most recent changes. > > > > > > CC: m3devel at elegosoft.com > > From: hosking at cs.purdue.edu > > Subject: Re: stdcall naming discrepancy? > > Date: Mon, 4 Feb 2008 15:30:23 -0500 > > To: jayk123 at hotmail.com > > > > OK. Not sure I understand what is going on then -- I would like to > > see the .mc file to get a sense of things. > > > > On Feb 4, 2008, at 2:43 PM, Jay wrote: > > > > > I think they are being passed correctly, by value. pop_struct and > > > not pop_param is used. > > > When I get time, I will put my parse.c back (uncommited) and then > > > just try some tests with "__cdecl" passing and returning structs. > > > That removes the naming issue and PART of the calling convention > > > issue and tests what is left. > > > Then I'll see if I can hack something up to test the rest. > > > > > > - Jay > > > > > > > > > > > > > CC: m3devel at elegosoft.com > > > > From: hosking at cs.purdue.edu > > > > Subject: Re: stdcall naming discrepancy? > > > > Date: Mon, 4 Feb 2008 09:52:31 -0500 > > > > To: jayk123 at hotmail.com > > > > > > > > Any chance that standard_structs in Target.i3 is causing the > front- > > > > end to pass structs by reference (standard structs=TRUE)? Also, > > > > looking at pop_struct in parse.c it seems to want to pass > them by > > > > reference (standard_structs=FALSE)? In any case, what does the > > > > integrated back-end do with pop_struct? I bet it is passing by > > > > value... whereas parse.c passes by ref. Blurgh! Looks like we > need > > > > to smarten things up for calls to non-M3 stdcall procedures. > > > > > > > > On Feb 4, 2008, at 1:23 AM, Jay wrote: > > > > > > > > > (and codegen..) > > > > > > > > > > C:\dev2\j\m3\t>type t.c > > > > > > > > > > typedef struct { > > > > > int a,b,c,d,e,f; > > > > > } Foo_t; > > > > > > > > > > void __stdcall Sleep(Foo_t foo); > > > > > > > > > > extern Foo_t a; > > > > > > > > > > void F1() > > > > > { > > > > > Sleep(a); > > > > > } > > > > > > > > > > C:\dev2\j\m3\t>gcc -c -S t.c > > > > > > > > > > C:\dev2\j\m3\t>type t.s > > > > > .file "t.c" > > > > > .text > > > > > .globl _F1 > > > > > .def _F1; .scl 2; .type 32; .endef > > > > > _F1: > > > > > pushl %ebp > > > > > movl %esp, %ebp > > > > > subl $24, %esp > > > > > movl _a, %eax > > > > > movl %eax, (%esp) > > > > > movl _a+4, %eax > > > > > movl %eax, 4(%esp) > > > > > movl _a+8, %eax > > > > > movl %eax, 8(%esp) > > > > > movl _a+12, %eax > > > > > movl %eax, 12(%esp) > > > > > movl _a+16, %eax > > > > > movl %eax, 16(%esp) > > > > > movl _a+20, %eax > > > > > movl %eax, 20(%esp) > > > > > call _Sleep at 24 > > > > > subl $24, %esp > > > > > leave > > > > > ret > > > > > C:\dev2\j\m3\t> > > > > > > > > > > (NOTE: This is NOT the correct declaration of Sleep, but ok > for > > > > > testing purposes.) > > > > > > > > > > C:\dev2\j\m3\t>type t.i3 > > > > > INTERFACE T; > > > > > > > > > > TYPE Foo_t = RECORD > > > > > a,b,c,d,e,f : INTEGER; > > > > > END; > > > > > > > > > > <*EXTERNAL Sleep:WINAPI*> > > > > > PROCEDURE Sleep (dwMilliseconds1: Foo_t); > > > > > END T. > > > > > > > > > > C:\dev2\j\m3\t>type t.m3 > > > > > > > > > > MODULE T; > > > > > VAR > > > > > Foo: Foo_t; > > > > > > > > > > BEGIN > > > > > Sleep(Foo); > > > > > END T. > > > > > > > > > > > > > > > LM1: > > > > > movl 8(%ebp), %eax > > > > > xorl $1, %eax > > > > > testb %al, %al > > > > > jne L2 > > > > > .stabn 68,0,6,LM2-_T_M3 > > > > > LM2: > > > > > movl $_MM_T+52, %eax > > > > > movl %eax, %edx > > > > > subl $8, %esp > > > > > subl $24, %esp > > > > > movl %esp, %eax > > > > > movl %eax, %edi > > > > > movl %edx, %esi > > > > > cld > > > > > movl $6, %eax > > > > > movl %eax, %ecx > > > > > rep > > > > > movsl > > > > > call _Sleep at 4 > > > > > addl $8, %esp > > > > > L2: > > > > > movl $_MM_T, %eax > > > > > LBE2: > > > > > leal -8(%ebp), %esp > > > > > popl %esi > > > > > popl %edi > > > > > leave > > > > > ret > > > > > > > > > > ? > > > > > > > > > > - Jay > > > > > > > > > > Connect and share in new ways with Windows Live. Get it now! > > > > > > > > > > > > > Climb to the top of the charts! Play the word scramble challenge > > > with star power. Play now! > > > > > Connect and share in new ways with Windows Live. Get it now! > From jayk123 at hotmail.com Mon Feb 4 22:28:49 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 4 Feb 2008 21:28:49 +0000 Subject: [M3devel] stdcall naming discrepancy? In-Reply-To: References: <20080204054529.A4C4F10D4611@birch.elegosoft.com> <05A22848-0B42-4827-B161-A780949D0707@cs.purdue.edu> Message-ID: understood, did the attachment not come through? attached again (parse.c changes aren't really relevant here anyway, not for the *c files, but for the *s files) - Jay > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: stdcall naming discrepancy?> Date: Mon, 4 Feb 2008 16:19:38 -0500> To: jayk123 at hotmail.com> > Jay,> > I'm not on Windows so I can't diagnose the stdcall problem. I want > to see the .mc file so I can get a sense of what is going on.> > On Feb 4, 2008, at 4:01 PM, Jay wrote:> > > This is without your most recent changes.> >> >> >> >> > > CC: m3devel at elegosoft.com> > > From: hosking at cs.purdue.edu> > > Subject: Re: stdcall naming discrepancy?> > > Date: Mon, 4 Feb 2008 15:30:23 -0500> > > To: jayk123 at hotmail.com> > >> > > OK. Not sure I understand what is going on then -- I would like to> > > see the .mc file to get a sense of things.> > >> > > On Feb 4, 2008, at 2:43 PM, Jay wrote:> > >> > > > I think they are being passed correctly, by value. pop_struct and> > > > not pop_param is used.> > > > When I get time, I will put my parse.c back (uncommited) and then> > > > just try some tests with "__cdecl" passing and returning structs.> > > > That removes the naming issue and PART of the calling convention> > > > issue and tests what is left.> > > > Then I'll see if I can hack something up to test the rest.> > > >> > > > - Jay> > > >> > > >> > > >> > > > > CC: m3devel at elegosoft.com> > > > > From: hosking at cs.purdue.edu> > > > > Subject: Re: stdcall naming discrepancy?> > > > > Date: Mon, 4 Feb 2008 09:52:31 -0500> > > > > To: jayk123 at hotmail.com> > > > >> > > > > Any chance that standard_structs in Target.i3 is causing the > > front-> > > > > end to pass structs by reference (standard structs=TRUE)? Also,> > > > > looking at pop_struct in parse.c it seems to want to pass > > them by> > > > > reference (standard_structs=FALSE)? In any case, what does the> > > > > integrated back-end do with pop_struct? I bet it is passing by> > > > > value... whereas parse.c passes by ref. Blurgh! Looks like we > > need> > > > > to smarten things up for calls to non-M3 stdcall procedures.> > > > >> > > > > On Feb 4, 2008, at 1:23 AM, Jay wrote:> > > > >> > > > > > (and codegen..)> > > > > >> > > > > > C:\dev2\j\m3\t>type t.c> > > > > >> > > > > > typedef struct {> > > > > > int a,b,c,d,e,f;> > > > > > } Foo_t;> > > > > >> > > > > > void __stdcall Sleep(Foo_t foo);> > > > > >> > > > > > extern Foo_t a;> > > > > >> > > > > > void F1()> > > > > > {> > > > > > Sleep(a);> > > > > > }> > > > > >> > > > > > C:\dev2\j\m3\t>gcc -c -S t.c> > > > > >> > > > > > C:\dev2\j\m3\t>type t.s> > > > > > .file "t.c"> > > > > > .text> > > > > > .globl _F1> > > > > > .def _F1; .scl 2; .type 32; .endef> > > > > > _F1:> > > > > > pushl %ebp> > > > > > movl %esp, %ebp> > > > > > subl $24, %esp> > > > > > movl _a, %eax> > > > > > movl %eax, (%esp)> > > > > > movl _a+4, %eax> > > > > > movl %eax, 4(%esp)> > > > > > movl _a+8, %eax> > > > > > movl %eax, 8(%esp)> > > > > > movl _a+12, %eax> > > > > > movl %eax, 12(%esp)> > > > > > movl _a+16, %eax> > > > > > movl %eax, 16(%esp)> > > > > > movl _a+20, %eax> > > > > > movl %eax, 20(%esp)> > > > > > call _Sleep at 24> > > > > > subl $24, %esp> > > > > > leave> > > > > > ret> > > > > > C:\dev2\j\m3\t>> > > > > >> > > > > > (NOTE: This is NOT the correct declaration of Sleep, but ok > > for> > > > > > testing purposes.)> > > > > >> > > > > > C:\dev2\j\m3\t>type t.i3> > > > > > INTERFACE T;> > > > > >> > > > > > TYPE Foo_t = RECORD> > > > > > a,b,c,d,e,f : INTEGER;> > > > > > END;> > > > > >> > > > > > <*EXTERNAL Sleep:WINAPI*>> > > > > > PROCEDURE Sleep (dwMilliseconds1: Foo_t);> > > > > > END T.> > > > > >> > > > > > C:\dev2\j\m3\t>type t.m3> > > > > >> > > > > > MODULE T;> > > > > > VAR> > > > > > Foo: Foo_t;> > > > > >> > > > > > BEGIN> > > > > > Sleep(Foo);> > > > > > END T.> > > > > >> > > > > >> > > > > > LM1:> > > > > > movl 8(%ebp), %eax> > > > > > xorl $1, %eax> > > > > > testb %al, %al> > > > > > jne L2> > > > > > .stabn 68,0,6,LM2-_T_M3> > > > > > LM2:> > > > > > movl $_MM_T+52, %eax> > > > > > movl %eax, %edx> > > > > > subl $8, %esp> > > > > > subl $24, %esp> > > > > > movl %esp, %eax> > > > > > movl %eax, %edi> > > > > > movl %edx, %esi> > > > > > cld> > > > > > movl $6, %eax> > > > > > movl %eax, %ecx> > > > > > rep> > > > > > movsl> > > > > > call _Sleep at 4> > > > > > addl $8, %esp> > > > > > L2:> > > > > > movl $_MM_T, %eax> > > > > > LBE2:> > > > > > leal -8(%ebp), %esp> > > > > > popl %esi> > > > > > popl %edi> > > > > > leave> > > > > > ret> > > > > >> > > > > > ?> > > > > >> > > > > > - Jay> > > > > >> > > > > > Connect and share in new ways with Windows Live. Get it now!> > > > >> > > >> > > >> > > > Climb to the top of the charts! Play the word scramble challenge> > > > with star power. Play now!> > >> >> >> > Connect and share in new ways with Windows Live. Get it now! > > > _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: t.tar.bz2 Type: application/octet-stream Size: 4484 bytes Desc: not available URL: From hosking at cs.purdue.edu Mon Feb 4 22:59:00 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 4 Feb 2008 16:59:00 -0500 Subject: [M3devel] stdcall naming discrepancy? In-Reply-To: References: <20080204054529.A4C4F10D4611@birch.elegosoft.com> <05A22848-0B42-4827-B161-A780949D0707@cs.purdue.edu> Message-ID: I just checked in a fix that initializes void_list_node. I think this may be the fix you need for stdargs. As far as I know, void_list_node is used to mark the end of non-varargs parameter lists. On Feb 4, 2008, at 4:28 PM, Jay wrote: > understood, did the attachment not come through? > attached again > (parse.c changes aren't really relevant here anyway, not for the *c > files, but for the *s files) > > - Jay > > > > > CC: m3devel at elegosoft.com > > From: hosking at cs.purdue.edu > > Subject: Re: stdcall naming discrepancy? > > Date: Mon, 4 Feb 2008 16:19:38 -0500 > > To: jayk123 at hotmail.com > > > > Jay, > > > > I'm not on Windows so I can't diagnose the stdcall problem. I want > > to see the .mc file so I can get a sense of what is going on. > > > > On Feb 4, 2008, at 4:01 PM, Jay wrote: > > > > > This is without your most recent changes. > > > > > > > > > > > > > > > > CC: m3devel at elegosoft.com > > > > From: hosking at cs.purdue.edu > > > > Subject: Re: stdcall naming discrepancy? > > > > Date: Mon, 4 Feb 2008 15:30:23 -0500 > > > > To: jayk123 at hotmail.com > > > > > > > > OK. Not sure I understand what is going on then -- I would > like to > > > > see the .mc file to get a sense of things. > > > > > > > > On Feb 4, 2008, at 2:43 PM, Jay wrote: > > > > > > > > > I think they are being passed correctly, by value. > pop_struct and > > > > > not pop_param is used. > > > > > When I get time, I will put my parse.c back (uncommited) > and then > > > > > just try some tests with "__cdecl" passing and returning > structs. > > > > > That removes the naming issue and PART of the calling > convention > > > > > issue and tests what is left. > > > > > Then I'll see if I can hack something up to test the rest. > > > > > > > > > > - Jay > > > > > > > > > > > > > > > > > > > > > CC: m3devel at elegosoft.com > > > > > > From: hosking at cs.purdue.edu > > > > > > Subject: Re: stdcall naming discrepancy? > > > > > > Date: Mon, 4 Feb 2008 09:52:31 -0500 > > > > > > To: jayk123 at hotmail.com > > > > > > > > > > > > Any chance that standard_structs in Target.i3 is causing the > > > front- > > > > > > end to pass structs by reference (standard structs=TRUE)? > Also, > > > > > > looking at pop_struct in parse.c it seems to want to pass > > > them by > > > > > > reference (standard_structs=FALSE)? In any case, what > does the > > > > > > integrated back-end do with pop_struct? I bet it is > passing by > > > > > > value... whereas parse.c passes by ref. Blurgh! Looks > like we > > > need > > > > > > to smarten things up for calls to non-M3 stdcall procedures. > > > > > > > > > > > > On Feb 4, 2008, at 1:23 AM, Jay wrote: > > > > > > > > > > > > > (and codegen..) > > > > > > > > > > > > > > C:\dev2\j\m3\t>type t.c > > > > > > > > > > > > > > typedef struct { > > > > > > > int a,b,c,d,e,f; > > > > > > > } Foo_t; > > > > > > > > > > > > > > void __stdcall Sleep(Foo_t foo); > > > > > > > > > > > > > > extern Foo_t a; > > > > > > > > > > > > > > void F1() > > > > > > > { > > > > > > > Sleep(a); > > > > > > > } > > > > > > > > > > > > > > C:\dev2\j\m3\t>gcc -c -S t.c > > > > > > > > > > > > > > C:\dev2\j\m3\t>type t.s > > > > > > > .file "t.c" > > > > > > > .text > > > > > > > .globl _F1 > > > > > > > .def _F1; .scl 2; .type 32; .endef > > > > > > > _F1: > > > > > > > pushl %ebp > > > > > > > movl %esp, %ebp > > > > > > > subl $24, %esp > > > > > > > movl _a, %eax > > > > > > > movl %eax, (%esp) > > > > > > > movl _a+4, %eax > > > > > > > movl %eax, 4(%esp) > > > > > > > movl _a+8, %eax > > > > > > > movl %eax, 8(%esp) > > > > > > > movl _a+12, %eax > > > > > > > movl %eax, 12(%esp) > > > > > > > movl _a+16, %eax > > > > > > > movl %eax, 16(%esp) > > > > > > > movl _a+20, %eax > > > > > > > movl %eax, 20(%esp) > > > > > > > call _Sleep at 24 > > > > > > > subl $24, %esp > > > > > > > leave > > > > > > > ret > > > > > > > C:\dev2\j\m3\t> > > > > > > > > > > > > > > (NOTE: This is NOT the correct declaration of Sleep, > but ok > > > for > > > > > > > testing purposes.) > > > > > > > > > > > > > > C:\dev2\j\m3\t>type t.i3 > > > > > > > INTERFACE T; > > > > > > > > > > > > > > TYPE Foo_t = RECORD > > > > > > > a,b,c,d,e,f : INTEGER; > > > > > > > END; > > > > > > > > > > > > > > <*EXTERNAL Sleep:WINAPI*> > > > > > > > PROCEDURE Sleep (dwMilliseconds1: Foo_t); > > > > > > > END T. > > > > > > > > > > > > > > C:\dev2\j\m3\t>type t.m3 > > > > > > > > > > > > > > MODULE T; > > > > > > > VAR > > > > > > > Foo: Foo_t; > > > > > > > > > > > > > > BEGIN > > > > > > > Sleep(Foo); > > > > > > > END T. > > > > > > > > > > > > > > > > > > > > > LM1: > > > > > > > movl 8(%ebp), %eax > > > > > > > xorl $1, %eax > > > > > > > testb %al, %al > > > > > > > jne L2 > > > > > > > .stabn 68,0,6,LM2-_T_M3 > > > > > > > LM2: > > > > > > > movl $_MM_T+52, %eax > > > > > > > movl %eax, %edx > > > > > > > subl $8, %esp > > > > > > > subl $24, %esp > > > > > > > movl %esp, %eax > > > > > > > movl %eax, %edi > > > > > > > movl %edx, %esi > > > > > > > cld > > > > > > > movl $6, %eax > > > > > > > movl %eax, %ecx > > > > > > > rep > > > > > > > movsl > > > > > > > call _Sleep at 4 > > > > > > > addl $8, %esp > > > > > > > L2: > > > > > > > movl $_MM_T, %eax > > > > > > > LBE2: > > > > > > > leal -8(%ebp), %esp > > > > > > > popl %esi > > > > > > > popl %edi > > > > > > > leave > > > > > > > ret > > > > > > > > > > > > > > ? > > > > > > > > > > > > > > - Jay > > > > > > > > > > > > > > Connect and share in new ways with Windows Live. Get it > now! > > > > > > > > > > > > > > > > > > > > > Climb to the top of the charts! Play the word scramble > challenge > > > > > with star power. Play now! > > > > > > > > > > > > > Connect and share in new ways with Windows Live. Get it now! > > > > > > > > Helping your favorite cause is as easy as instant messaging. You > IM, we give. Learn more. From hosking at cs.purdue.edu Mon Feb 4 23:14:16 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 4 Feb 2008 17:14:16 -0500 Subject: [M3devel] Latest parse.c Message-ID: See this snip from gcc/gcc/config/winnt.c: > formal_type = TYPE_ARG_TYPES (TREE_TYPE (decl)); > if (formal_type != NULL_TREE) > { > /* These attributes are ignored for variadic functions in > i386.c:ix86_return_pops_args. For compatibility with MS > compiler do not add @0 suffix here. */ > if (TREE_VALUE (tree_last (formal_type)) != void_type_node) > return DECL_ASSEMBLER_NAME (decl); We need a void_type_node there -- void_list_node now captures that properly. > /* Quit if we hit an incomplete type. Error is reported > by convert_arguments in c-typeck.c or cp/typeck.c. */ I wonder if the remaining problem with the wrong @N value is because we don't have a complete type on the formals? > while (TREE_VALUE (formal_type) != void_type_node > && COMPLETE_TYPE_P (TREE_VALUE (formal_type))) > { > int parm_size > = TREE_INT_CST_LOW (TYPE_SIZE (TREE_VALUE (formal_type))); > /* Must round up to include padding. This is done the same > way as in store_one_arg. */ > parm_size = ((parm_size + PARM_BOUNDARY - 1) > / PARM_BOUNDARY * PARM_BOUNDARY); > total += parm_size; > formal_type = TREE_CHAIN (formal_type);\ > } > } From jayk123 at hotmail.com Mon Feb 4 23:25:52 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 4 Feb 2008 22:25:52 +0000 Subject: [M3devel] Latest parse.c In-Reply-To: References: Message-ID: I'll try later. I tried stepping through some of this in gdb but couldn't make much sense of the data. Perhaps due to optimization. And I read some of it, but didn't really notice what you point out, thanks. I need to be more willing to resort to printf debugging..it worked well with those aligned doubles.. It should help (any of us) to use that small repro I provided. I don't think it "quits" for us, but worth the printf'ing and such. It does append "@4" to Sleep. Another thing would be try: like Sleep(int,record,int,record); I wouldn't be surprised if you get @16, but I'm placing no bets here. :) I should also try building some cross m3cg's so I can nag you to do the same. :) (if it only it were that easy, also need cross gcc, ld, headers, libs, and then could build all distributions from one machine, albeit NT386 is the real laggard here...) - Jay > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Latest parse.c> Date: Mon, 4 Feb 2008 17:14:16 -0500> To: jayk123 at hotmail.com> > See this snip from gcc/gcc/config/winnt.c:> > > formal_type = TYPE_ARG_TYPES (TREE_TYPE (decl));> > if (formal_type != NULL_TREE)> > {> > /* These attributes are ignored for variadic functions in> > i386.c:ix86_return_pops_args. For compatibility with MS> > compiler do not add @0 suffix here. */> > if (TREE_VALUE (tree_last (formal_type)) != void_type_node)> > return DECL_ASSEMBLER_NAME (decl);> > We need a void_type_node there -- void_list_node now captures that > properly.> > > /* Quit if we hit an incomplete type. Error is reported> > by convert_arguments in c-typeck.c or cp/typeck.c. */> > I wonder if the remaining problem with the wrong @N value is because > we don't have a complete type on the formals?> > > while (TREE_VALUE (formal_type) != void_type_node> > && COMPLETE_TYPE_P (TREE_VALUE (formal_type))) > > {> > int parm_size> > = TREE_INT_CST_LOW (TYPE_SIZE (TREE_VALUE (formal_type)));> > /* Must round up to include padding. This is done the same> > way as in store_one_arg. */> > parm_size = ((parm_size + PARM_BOUNDARY - 1)> > / PARM_BOUNDARY * PARM_BOUNDARY);> > total += parm_size;> > formal_type = TREE_CHAIN (formal_type);\> > }> > }> > _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Feb 5 10:36:55 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 5 Feb 2008 09:36:55 +0000 Subject: [M3devel] nt386gnu threads? In-Reply-To: <200801291036.m0TAaVws062299@camembert.async.caltech.edu> References: Your message of "Mon, 28 Jan 2008 12:38:38 GMT." <200801291036.m0TAaVws062299@camembert.async.caltech.edu> Message-ID: Mika you are right, e.g.: C:\pm3\bin>mentor.exe ****** runtime error:*** ThreadWin32.m3, line 726: Windows OS failure, GetLastError = 8*** use option @M3stackdump to get a stack trace 20754 [unknown (0xF84)] mentor 2780 _cygtls::handle_exceptions: Exception: STATUS_ACCESS_VIOLATION 42083 [unknown (0xF84)] mentor 2780 open_stackdumpfile: Dumping stack trace to mentor.exe.stackdump And it uses Win32 gui. I am still inclined to use pthreads though.. - Jay > To: jayk123 at hotmail.com> Subject: Re: [M3devel] nt386gnu threads? > Date: Tue, 29 Jan 2008 02:36:31 -0800> From: mika at async.caltech.edu> > > Sorry, I don't have the m3makefiles. I just have a binary installation> of PM3/Klagenfurt.> > Practice your German:> > http://www.1o0.de/wi-links/informatik/praxis/programmiersprachen/modula3/installation/windows/windows.html> > here...> > http://www.1o0.de/wi-links/modula3/> > (Sorry I don't even have access to my Windows system right now.)> > Mika> > Jay writes:> >--_14fad708-4bac-4aaf-ab93-c9649038a920_> >Content-Type: text/plain; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >Um, so the file exists..does it get compiled? Did you look at the m3makefil=> >es?> >I skimmed the m3makefiles. I have not tried building PM3 myself.> >=20> > - Jay _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Tue Feb 5 12:15:44 2008 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Tue, 5 Feb 2008 12:15:44 +0100 (CET) Subject: [M3devel] quake extensions for tests / RFC In-Reply-To: <20080201212630.u71dug6hw0oso0c4@mail.elegosoft.com> Message-ID: <630679.89563.qm@web27101.mail.ukl.yahoo.com> Hi Olaf: Is still possible to add Literate programming support, I mean using several functions that are just a commentary at the end of the file on M3Build.m3: http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/~checkout~/cm3/m3-sys/cm3/src/M3Build.m3?rev=1.8;content-type=text%2Fplain Also there is a missing one on Built-in functions, one that "copy" the derived source of a noweb file (specifically a generic) from the Target (e.g LINUXLIBC6) directory of the compiler to the src directory. In that way the compiler can use the source. The name of functions could be: "derived_generic_interface", "derived_generic_implementation" This stuff is used on ldb debugger : http://www.eecs.harvard.edu/nr/ldb/ The literate programming support was present on DEC SRC M3 I think: http://www.wiwi.uni-rostock.de/LABOR_NETZ/DOKUS/MODULA_3/html/modula-3/html/m3build/noweb.html Thanks Daniel Benavides Olaf Wagner escribi?: Yesterday I've added some more functions, and today I've updated the quake reference. I'm still open for name or semantics changes or other improvements. Please have a look at http://modula3.elegosoft.com/cm3/doc/help/cm3/quake.html Best regards, Olaf -- Olaf Wagner -- elego Software Solutions GmbH 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 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 --------------------------------- ?Con Mascota por primera vez? - S? un mejor Amigo Entra en Yahoo! Respuestas. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Feb 5 12:39:23 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 05 Feb 2008 12:39:23 +0100 Subject: [M3devel] quake extensions for tests / RFC In-Reply-To: <630679.89563.qm@web27101.mail.ukl.yahoo.com> References: <630679.89563.qm@web27101.mail.ukl.yahoo.com> Message-ID: <20080205123923.qvlr4noeocgkc8gs@mail.elegosoft.com> Quoting "Daniel Alejandro Benavides D." : > Hi Olaf: > Is still possible to add Literate programming support, I mean using > several functions that are just a commentary at the end of the file > on M3Build.m3: > http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/~checkout~/cm3/m3-sys/cm3/src/M3Build.m3?rev=1.8;content-type=text%2Fplain You're talking of the builder's built-in functions; I haven't had a close look at them yet (just extended the pure quake built-ins). Of course it should be possible to add support for literate programming; but I haven't any experience with this. > Also there is a missing one on Built-in functions, one that "copy" > the derived source of a noweb file (specifically a generic) from the > Target (e.g LINUXLIBC6) directory of the compiler to the src > directory. I don't think it should be done this way, and it wouldn't really work, as the compiler would need two passes for each package then; all derived files should be kept in the TARGET directory. I think derived sources for literate programming should be handled in the same way as instantiated generics (e.g. based on quake templates). > In that way the compiler can use the source. The name of functions > could be: "derived_generic_interface", > "derived_generic_implementation" The actual implementation could be done in quake first and maybe later be implemented in M3 in the builder for performance reasons. > This stuff is used on ldb debugger : http://www.eecs.harvard.edu/nr/ldb/ > The literate programming support was present on DEC SRC M3 I think: > http://www.wiwi.uni-rostock.de/LABOR_NETZ/DOKUS/MODULA_3/html/modula-3/html/m3build/noweb.html As I said, I've never used it and don't know about it, but will have a look at it when I've got some time. If you could provide some of the needed quake functions, that would of course be great ;-) Olaf -- Olaf Wagner -- elego Software Solutions GmbH 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 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Wed Feb 6 20:15:26 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 06 Feb 2008 20:15:26 +0100 Subject: [M3devel] quake extensions for tests / RFC In-Reply-To: <630679.89563.qm@web27101.mail.ukl.yahoo.com> References: <630679.89563.qm@web27101.mail.ukl.yahoo.com> Message-ID: <20080206201526.xhrf6759wcskss8s@mail.elegosoft.com> Quoting "Daniel Alejandro Benavides D." : > Hi Olaf: > Is still possible to add Literate programming support, I mean using > several functions that are just a commentary at the end of the file > on M3Build.m3: > http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/~checkout~/cm3/m3-sys/cm3/src/M3Build.m3?rev=1.8;content-type=text%2Fplain > > Also there is a missing one on Built-in functions, one that "copy" > the derived source of a noweb file (specifically a generic) from the > Target (e.g LINUXLIBC6) directory of the compiler to the src > directory. In that way the compiler can use the source. The name of > functions could be: "derived_generic_interface", > "derived_generic_implementation" > > This stuff is used on ldb debugger : http://www.eecs.harvard.edu/nr/ldb/ > The literate programming support was present on DEC SRC M3 I think: > http://www.wiwi.uni-rostock.de/LABOR_NETZ/DOKUS/MODULA_3/html/modula-3/html/m3build/noweb.html Hi again, I've had a look at all that stuff, even downloaded ldb and installed noweb. Still, I'd need a simple example to understand what exactly you would like to have included in CM3 by default. Just the four commented-out noweb procedures from M3Build.m3? Or more elaborate stuff like that included in the ldb distribution? Is there any problem with just including the 4 quake procedures as template? Anything that would not work? If you could provide a simple m3 package which contains all the uses you'd like to see supported, we could even use that as a regression test add-on. So if you send me a more specific and exact definition and example, I'll try to add everything that is needed. I've never done literate programming myself, and haven't got the time to learn everything now and decide what is needed. Olaf -- Olaf Wagner -- elego Software Solutions GmbH 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 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jayk123 at hotmail.com Wed Feb 6 22:46:31 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 6 Feb 2008 21:46:31 +0000 Subject: [M3devel] quake extensions for tests / RFC In-Reply-To: <20080206201526.xhrf6759wcskss8s@mail.elegosoft.com> References: <630679.89563.qm@web27101.mail.ukl.yahoo.com> <20080206201526.xhrf6759wcskss8s@mail.elegosoft.com> Message-ID: Modula-3 and quake both support writing comments already. :) I guess a "cross referencing" scheme would be nice, but to some extent that should be automatic. To some extent, or entirely, it is what Reactor is. All the calls to a function or references to a type are immediately findable, I think. All you really need is a) a completely global namespace so every identifier is unique b) plain text search based on an index. I like C++ and I like some about Modula-3, but hierarchical namespaces really stink in the face of (indexed) plain text search, and no other kind of search can keep up with large codebases. How do I find uses of this particular "T" when people can and do make aliases? I realize C has typedefs to establish aliases, and nesting, so that argument is somewhat moot (the point is more relevant for C++, trying to make it Modula-3-relevant). In C++, how do I search for calls to a particular operator=? Or to a constructor? I'm just being obnoxious. ...Jay > Date: Wed, 6 Feb 2008 20:15:26 +0100> From: wagner at elegosoft.com> To: dabenavidesd at yahoo.es> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] quake extensions for tests / RFC> > Quoting "Daniel Alejandro Benavides D." :> > > Hi Olaf:> > Is still possible to add Literate programming support, I mean using > > several functions that are just a commentary at the end of the file > > on M3Build.m3:> > http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/~checkout~/cm3/m3-sys/cm3/src/M3Build.m3?rev=1.8;content-type=text%2Fplain> >> > Also there is a missing one on Built-in functions, one that "copy" > > the derived source of a noweb file (specifically a generic) from the > > Target (e.g LINUXLIBC6) directory of the compiler to the src > > directory. In that way the compiler can use the source. The name of > > functions could be: "derived_generic_interface", > > "derived_generic_implementation"> >> > This stuff is used on ldb debugger : http://www.eecs.harvard.edu/nr/ldb/> > The literate programming support was present on DEC SRC M3 I think:> > http://www.wiwi.uni-rostock.de/LABOR_NETZ/DOKUS/MODULA_3/html/modula-3/html/m3build/noweb.html> > Hi again,> > I've had a look at all that stuff, even downloaded ldb and installed noweb.> Still, I'd need a simple example to understand what exactly you would> like to have included in CM3 by default. Just the four commented-out> noweb procedures from M3Build.m3? Or more elaborate stuff like that> included in the ldb distribution?> > Is there any problem with just including the 4 quake procedures as> template? Anything that would not work?> > If you could provide a simple m3 package which contains all the uses> you'd like to see supported, we could even use that as a regression> test add-on. So if you send me a more specific and exact definition> and example, I'll try to add everything that is needed.> > I've never done literate programming myself, and haven't got the time> to learn everything now and decide what is needed.> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> 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> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Wed Feb 6 23:04:43 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Wed, 06 Feb 2008 14:04:43 -0800 Subject: [M3devel] quake extensions for tests / RFC In-Reply-To: Your message of "Wed, 06 Feb 2008 21:46:31 GMT." Message-ID: <200802062204.m16M4iS7021745@camembert.async.caltech.edu> Isn't Nelson's book "Systems Programming with Modula-3" to a large extent composed of literate programming (Threads interfaces, etc.)? Modula-3 has really cool literate programming support and it'd be a shame to lose it. Also m3browser does support the automatic cross referencing you're talking about. Last I checked it was a bit buggy. In my experience, one of the really nice things about Modula-3 when you write moderately large programs is actually that it's very easy to find out where a T is being used, without using any special tools (like m3browser). You just grep for the name of the interface where that T is defined, and that gives you a superset of all possible uses of T. Modula-3 doesn't have the nasty Javaism "import libm3.*;" Mika Jay writes: >--_2ffd3106-b4e0-4fbd-8e26-22c3f2b01f8a_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > >Modula-3 and quake both support writing comments already. :) >=20 >I guess a "cross referencing" scheme would be nice, but to some extent that= > should be automatic. >To some extent, or entirely, it is what Reactor is. All the calls to a func= >tion or references to a type are immediately findable, I think. >=20 >All you really need is a) a completely global namespace so every identifier= > is unique b) plain text search based on an index. >=20 >I like C++ and I like some about Modula-3, but hierarchical namespaces real= >ly stink in the face of (indexed) plain text search, and no other kind of s= >earch can keep up with large codebases. How do I find uses of this particul= >ar "T" when people can and do make aliases? I realize C has typedefs to est= >ablish aliases, and nesting, so that argument is somewhat moot (the point i= >s more relevant for C++, trying to make it Modula-3-relevant). In C++, how = >do I search for calls to a particular operator=3D? Or to a constructor? >=20 >I'm just being obnoxious. >=20 > ...Jay > > > >> Date: Wed, 6 Feb 2008 20:15:26 +0100> From: wagner at elegosoft.com> To: dab= >enavidesd at yahoo.es> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] quake= > extensions for tests / RFC> > Quoting "Daniel Alejandro Benavides D." enavidesd at yahoo.es>:> > > Hi Olaf:> > Is still possible to add Literate pro= >gramming support, I mean using > > several functions that are just a commen= >tary at the end of the file > > on M3Build.m3:> > http://modula3.elegosoft.= >com/cgi-bin/cvsweb.cgi/~checkout~/cm3/m3-sys/cm3/src/M3Build.m3?rev=3D1.8;c= >ontent-type=3Dtext%2Fplain> >> > Also there is a missing one on Built-in fu= >nctions, one that "copy" > > the derived source of a noweb file (specifical= >ly a generic) from the > > Target (e.g LINUXLIBC6) directory of the compile= >r to the src > > directory. In that way the compiler can use the source. Th= >e name of > > functions could be: "derived_generic_interface", > > "derived= >_generic_implementation"> >> > This stuff is used on ldb debugger : http://= >www.eecs.harvard.edu/nr/ldb/> > The literate programming support was presen= >t on DEC SRC M3 I think:> > http://www.wiwi.uni-rostock.de/LABOR_NETZ/DOKUS= >/MODULA_3/html/modula-3/html/m3build/noweb.html> > Hi again,> > I've had a = >look at all that stuff, even downloaded ldb and installed noweb.> Still, I'= >d need a simple example to understand what exactly you would> like to have = >included in CM3 by default. Just the four commented-out> noweb procedures f= >rom M3Build.m3? Or more elaborate stuff like that> included in the ldb dist= >ribution?> > Is there any problem with just including the 4 quake procedure= >s as> template? Anything that would not work?> > If you could provide a sim= >ple m3 package which contains all the uses> you'd like to see supported, we= > could even use that as a regression> test add-on. So if you send me a more= > specific and exact definition> and example, I'll try to add everything tha= >t is needed.> > I've never done literate programming myself, and haven't go= >t the time> to learn everything now and decide what is needed.> > Olaf> -- = >> Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb= >=E4ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177= > 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch=E4ftsf= >=FChrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlotten= >burg HRB 77719 | USt-IdNr: DE163214194>=20 >_________________________________________________________________ >Connect and share in new ways with Windows Live. >http://www.windowslive.com/share.html?ocid=3DTXT_TAGHM_Wave2_sharelife_0120= >08= > >--_2ffd3106-b4e0-4fbd-8e26-22c3f2b01f8a_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > >Modula-3 and quake both support writing comments = >already. :)
> 
>I guess a "cross referencing" scheme would be nice, but to some extent that= > should be automatic.
>To some extent, or entirely, it is what Reactor is. All the calls to a func= >tion or references to a type are immediately findable, I think.
> 
>All you really need is a) a completely global namespace so every identifier= > is unique b) plain text search based on an index.
> 
>I like C++ and I like some about Modula-3, but hierarchical namespaces real= >ly stink in the face of (indexed) plain text search, and no other kind of s= >earch can keep up with large codebases. How do I find uses of this particul= >ar "T" when people can and do make aliases? I realize C has typedefs to est= >ablish aliases, and nesting, so that argument is somewhat moot (the point i= >s more relevant for C++, trying to make it Modula-3-relevant). In C++, how = >do I search for calls to a particular operator=3D? Or to a constructor?
> 
>I'm just being obnoxious.
> 
> ...Jay


> >
>
>> Date: Wed, 6 Feb 2008 20:15:26 +0100
> From: wagner at elegosoft.co= >m
> To: dabenavidesd at yahoo.es
> CC: m3devel at elegosoft.com
&g= >t; Subject: Re: [M3devel] quake extensions for tests / RFC
>
>= > Quoting "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>:
= >>
> > Hi Olaf:
> > Is still possible to add Literate = >programming support, I mean using
> > several functions that are = >just a commentary at the end of the file
> > on M3Build.m3:
&g= >t; > http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/~checkout~/cm3/m3-s= >ys/cm3/src/M3Build.m3?rev=3D1.8;content-type=3Dtext%2Fplain
> >>> > Also there is a missing one on Built-in functions, one that "cop= >y"
> > the derived source of a noweb file (specifically a generic= >) from the
> > Target (e.g LINUXLIBC6) directory of the compiler = >to the src
> > directory. In that way the compiler can use the so= >urce. The name of
> > functions could be: "derived_generic_interf= >ace",
> > "derived_generic_implementation"
> >
> &= >gt; This stuff is used on ldb debugger : http://www.eecs.harvard.edu/nr/ldb= >/
> > The literate programming support was present on DEC SRC M3 I= > think:
> > http://www.wiwi.uni-rostock.de/LABOR_NETZ/DOKUS/MODULA= >_3/html/modula-3/html/m3build/noweb.html
>
> Hi again,
>= >
> I've had a look at all that stuff, even downloaded ldb and instal= >led noweb.
> Still, I'd need a simple example to understand what exac= >tly you would
> like to have included in CM3 by default. Just the fou= >r commented-out
> noweb procedures from M3Build.m3? Or more elaborate= > stuff like that
> included in the ldb distribution?
>
>= > Is there any problem with just including the 4 quake procedures as
>= > template? Anything that would not work?
>
> If you could prov= >ide a simple m3 package which contains all the uses
> you'd like to s= >ee supported, we could even use that as a regression
> test add-on. S= >o if you send me a more specific and exact definition
> and example, = >I'll try to add everything that is needed.
>
> I've never done= > literate programming myself, and haven't got the time
> to learn eve= >rything now and decide what is needed.
>
> Olaf
> -- >> Olaf Wagner -- elego Software Solutions GmbH
> Gustav-Meyer-All= >ee 25 / Geb=E4ude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 = >96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
> http://www.eleg= >osoft.com | Gesch=E4ftsf=FChrer: Olaf Wagner | Sitz: Berlin
> Handelr= >egister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
&g= >t;


Connect and share in new ways with Windows Live. href=3D'http://www.windowslive.com/share.html?ocid=3DTXT_TAGHM_Wave2_sharel= >ife_012008' target=3D'_new'>Get it now! >= > >--_2ffd3106-b4e0-4fbd-8e26-22c3f2b01f8a_-- From wagner at elegosoft.com Thu Feb 7 00:07:08 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 07 Feb 2008 00:07:08 +0100 Subject: [M3devel] quake extensions for tests / RFC In-Reply-To: <200802062204.m16M4iS7021745@camembert.async.caltech.edu> References: <200802062204.m16M4iS7021745@camembert.async.caltech.edu> Message-ID: <20080207000708.380w844gg80cws0k@mail.elegosoft.com> Quoting Mika Nystrom : > Isn't Nelson's book "Systems Programming with Modula-3" to a large > extent composed of literate programming (Threads interfaces, etc.)? > Modula-3 has really cool literate programming support and it'd be > a shame to lose it. Also m3browser does support the automatic cross > referencing you're talking about. Last I checked it was a bit > buggy. Well, I think you're right and one can see m3browser as a kind of special literate programming support. And if it is currently buggy -- perhaps you could explain what exactly is wrong -- we should certainly fix it. However, I understood the request of Daniel Alejandro Benavides as one to re-add support for some generic literate programming tools which where already supported in earlier releases of M3. There is no harm in that, and I think we should be open for integrations of many such tools. I don't think it will be very difficult to add this support (as it has already been there), I'm just not familiar enough with the noweb tools to exactly know what is needed, so I asked for some help. I also think the SGML tools that were used for the PM3 documentation are a kind of literate programming support; and that's probably the most powerful and promising solution. Olaf -- Olaf Wagner -- elego Software Solutions GmbH 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 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From dabenavidesd at yahoo.es Thu Feb 7 03:30:49 2008 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Thu, 7 Feb 2008 03:30:49 +0100 (CET) Subject: [M3devel] quake extensions for tests / RFC In-Reply-To: <20080206201526.xhrf6759wcskss8s@mail.elegosoft.com> Message-ID: <740158.42013.qm@web27105.mail.ukl.yahoo.com> Hi Olaf: Thanks for your work, yes I think there are several functions more than those in the comments of M3Build.m3 that are needed, however I can confirm that these functions (the ones on M3Build.m3) are needed for be able to use noweb from quake. But one thing worry me: I don't know if it is good to have code that depends on external tools (noweb for example). I would like to know what all you think about this respect. Daniel Benavides Olaf Wagner escribi?: Quoting "Daniel Alejandro Benavides D." : > Hi Olaf: > Is still possible to add Literate programming support, I mean using > several functions that are just a commentary at the end of the file > on M3Build.m3: > http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/~checkout~/cm3/m3-sys/cm3/src/M3Build.m3?rev=1.8;content-type=text%2Fplain > > Also there is a missing one on Built-in functions, one that "copy" > the derived source of a noweb file (specifically a generic) from the > Target (e.g LINUXLIBC6) directory of the compiler to the src > directory. In that way the compiler can use the source. The name of > functions could be: "derived_generic_interface", > "derived_generic_implementation" > > This stuff is used on ldb debugger : http://www.eecs.harvard.edu/nr/ldb/ > The literate programming support was present on DEC SRC M3 I think: > http://www.wiwi.uni-rostock.de/LABOR_NETZ/DOKUS/MODULA_3/html/modula-3/html/m3build/noweb.html Hi again, I've had a look at all that stuff, even downloaded ldb and installed noweb. Still, I'd need a simple example to understand what exactly you would like to have included in CM3 by default. Just the four commented-out noweb procedures from M3Build.m3? Or more elaborate stuff like that included in the ldb distribution? Is there any problem with just including the 4 quake procedures as template? Anything that would not work? If you could provide a simple m3 package which contains all the uses you'd like to see supported, we could even use that as a regression test add-on. So if you send me a more specific and exact definition and example, I'll try to add everything that is needed. I've never done literate programming myself, and haven't got the time to learn everything now and decide what is needed. Olaf -- Olaf Wagner -- elego Software Solutions GmbH 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 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 --------------------------------- ?Con Mascota por primera vez? - S? un mejor Amigo Entra en Yahoo! Respuestas. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Fri Feb 8 21:49:19 2008 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Fri, 8 Feb 2008 21:49:19 +0100 (CET) Subject: [M3devel] quake extensions for tests / RFC In-Reply-To: <740158.42013.qm@web27105.mail.ukl.yahoo.com> Message-ID: <32680.74034.qm@web27114.mail.ukl.yahoo.com> Hi: I'm sorry for not writing you all the things I like to see on CM3. It seems that the creator of ldb (Norman Ramsey) has been the creator of noweb, so I think his package as far as I have compiled it, is a good test, but maybe too large, so yes I would love to contribute with it. >Is there any problem with just including the 4 quake procedures as >template? Anything that would not work? There isn`t (I think I have compiled with those functions as a ldb-template package template on ldb), but the builtin procedure which I don't see is the one I wrote so I think it should be added in this text case of ldb but also in other cases (I think quake acts as a prepocessor of the noweb Modula-3/generic sources). Thanks again, and hope that I answeres better this time. "Daniel Alejandro Benavides D." escribi?: Hi Olaf: Thanks for your work, yes I think there are several functions more than those in the comments of M3Build.m3 that are needed, however I can confirm that these functions (the ones on M3Build.m3) are needed for be able to use noweb from quake. But one thing worry me: I don't know if it is good to have code that depends on external tools (noweb for example). I would like to know what all you think about this respect. Daniel Benavides Olaf Wagner escribi?: Quoting "Daniel Alejandro Benavides D." : > Hi Olaf: > Is still possible to add Literate programming support, I mean using > several functions that are just a commentary at the end of the file > on M3Build.m3: > http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/~checkout~/cm3/m3-sys/cm3/src/M3Build.m3?rev=1.8;content-type=text%2Fplain > > Also there is a missing one on Built-in functions, one that "copy" > the derived source of a noweb file (specifically a generic) from the > Target (e.g LINUXLIBC6) directory of the compiler to the src > directory. In that way the compiler can use the source. The name of > functions could be: "derived_generic_interface", > "derived_generic_implementation" > > This stuff is used on ldb debugger : http://www.eecs.harvard.edu/nr/ldb/ > The literate programming support was present on DEC SRC M3 I think: > http://www.wiwi.uni-rostock.de/LABOR_NETZ/DOKUS/MODULA_3/html/modula-3/html/m3build/noweb.html Hi again, I've had a look at all that stuff, even downloaded ldb and installed noweb. Still, I'd need a simple example to understand what exactly you would like to have included in CM3 by default. Just the four commented-out noweb procedures from M3Build.m3? Or more elaborate stuff like that included in the ldb distribution? Is there any problem with just including the 4 quake procedures as template? Anything that would not work? If you could provide a simple m3 package which contains all the uses you'd like to see supported, we could even use that as a regression test add-on. So if you send me a more specific and exact definition and example, I'll try to add everything that is needed. I've never done literate programming myself, and haven't got the time to learn everything now and decide what is needed. Olaf -- Olaf Wagner -- elego Software Solutions GmbH 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 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 --------------------------------- ?Con Mascota por primera vez? - S? un mejor Amigo Entra en Yahoo! Respuestas. --------------------------------- ?Con Mascota por primera vez? - S? un mejor Amigo Entra en Yahoo! Respuestas. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sat Feb 9 18:52:43 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 09 Feb 2008 18:52:43 +0100 Subject: [M3devel] www.opencm3.net, m3tohtml and current CM3 source browser Message-ID: <20080209185243.kbm6grheyoks40g0@mail.elegosoft.com> After looking for some suitable domain names that are still available, Elego has secured www.opencm3.net to allow easier access to the CM3 project. http://www.opemcm3.net is now the same as http://modula3.elegosoft.com/cm3/ but shorter and probably easier to remember. Unfortunately www.opencm3.org and the shorter www.cm3.xxx domains are already owned by others. I've made a small update to m3tohtml and automated the HTML doc generation in cm3/scripts/regression/defs.sh:test_m3tohtml. This is now also run nightly on birch.elegosoft.com. Next to running m3browser directly on our web server, this seems the easiest way to allow browsing of all current sources. Have a look at http://www.opencm3.net/doc/help/gen_html/INDEX.html. Olaf -- Olaf Wagner -- elego Software Solutions GmbH 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 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jayk123 at hotmail.com Sun Feb 10 10:28:22 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 10 Feb 2008 09:28:22 +0000 Subject: [M3devel] FW: nanosleep messes up signals? Message-ID: "cross posting", guilty. (This might have something to do with NT386GNU CM3 hanging upon startup but I haven't figured out much..in CM3, nanosleep fails and I don't think ThreadPThread__SignalHandler is ever called, whereas here nanosleep succeeds and the signal handler is called at least a few times; I'm going to try some hack with the Cygwin nanosleep uses sleep instead or something...) From: jayk123 at hotmail.comTo: cygwin at cygwin.comSubject: nanosleep messes up signals?Date: Sun, 10 Feb 2008 09:25:35 +0000 I'm no expert in pthreads, signals, sleep, etc., but..does this program not demonstrate incorrect behavior?If you run it as shown, a few signals get delivered, and then they stop.If you switch the #if 0, they get steadily delivered. #include #include #include #include void*ThreadMain( void* p ){ struct timespec a = { 1, 1 }; struct timespec b = { 1, 1 }; printf("in thread %x\n", GetCurrentThreadId()); while (1) { printf("thread %x\n", GetCurrentThreadId()); nanosleep(&a, &b); //sleep(0); Sleep(100); } return 0;}voidSignalHandler( int sig, siginfo_t * a, void* b ){ printf("in SignalHandler %x thread %x\n", sig, GetCurrentThreadId());}int main(){ struct timespec a = { 1, 1 }; struct timespec b = { 1, 1 }; int NotMagic = 0; /* avoid an access violation */ pthread_attr_t attr = { (void*) &NotMagic }; pthread_t thr = { (void*) &NotMagic }; struct sigaction act = { 0 }; struct sigaction oldact = { 0 }; printf("main thread %x\n", GetCurrentThreadId()); act.sa_flags = (SA_RESTART | SA_SIGINFO); act.sa_sigaction = SignalHandler; sigaction(SIGUSR2, &act, &oldact); pthread_attr_init (&attr); pthread_create(&thr, 0, ThreadMain, 0); while(1) {#if 0 sleep(1);#else printf("%d\n", nanosleep(&a, &b));#endif pthread_kill(thr, SIGUSR2); pthread_kill(thr, SIGUSR2); } return 0;} Climb to the top of the charts! Play the word scramble challenge with star power. Play now! _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sun Feb 10 10:43:58 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 10 Feb 2008 09:43:58 +0000 Subject: [M3devel] FW: nanosleep messes up signals? Message-ID: oh the burden of my own cross-posting.. - Jay From: jayk123 at hotmail.comTo: cygwin at cygwin.comSubject: RE: nanosleep messes up signals?Date: Sun, 10 Feb 2008 09:43:20 +0000 Given that sleep is implemented via nanosleep in the obvious simple way..Still, any additional clues/explanations are welcome. :) - Jay From: jayk123 at hotmail.comTo: cygwin at cygwin.comSubject: nanosleep messes up signals?Date: Sun, 10 Feb 2008 09:25:35 +0000 I'm no expert in pthreads, signals, sleep, etc., but..does this program not demonstrate incorrect behavior?If you run it as shown, a few signals get delivered, and then they stop.If you switch the #if 0, they get steadily delivered. #include #include #include #include void*ThreadMain( void* p ){ struct timespec a = { 1, 1 }; struct timespec b = { 1, 1 }; printf("in thread %x\n", GetCurrentThreadId()); while (1) { printf("thread %x\n", GetCurrentThreadId()); nanosleep(&a, &b); //sleep(0); Sleep(100); } return 0;}voidSignalHandler( int sig, siginfo_t * a, void* b ){ printf("in SignalHandler %x thread %x\n", sig, GetCurrentThreadId());}int main(){ struct timespec a = { 1, 1 }; struct timespec b = { 1, 1 }; int NotMagic = 0; /* avoid an access violation */ pthread_attr_t attr = { (void*) &NotMagic }; pthread_t thr = { (void*) &NotMagic }; struct sigaction act = { 0 }; struct sigaction oldact = { 0 }; printf("main thread %x\n", GetCurrentThreadId()); act.sa_flags = (SA_RESTART | SA_SIGINFO); act.sa_sigaction = SignalHandler; sigaction(SIGUSR2, &act, &oldact); pthread_attr_init (&attr); pthread_create(&thr, 0, ThreadMain, 0); while(1) {#if 0 sleep(1);#else printf("%d\n", nanosleep(&a, &b));#endif pthread_kill(thr, SIGUSR2); pthread_kill(thr, SIGUSR2); } return 0;} Climb to the top of the charts! Play the word scramble challenge with star power. Play now! Connect and share in new ways with Windows Live. Get it now! _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney.bates at wichita.edu Sun Feb 10 22:55:01 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Sun, 10 Feb 2008 15:55:01 -0600 Subject: [M3devel] <*LAZYALIGN*> Message-ID: <47AF72B5.2080308@wichita.edu> Does anybody know about the status of pragma <*LAZYALIGN*>? Is it being used anywhere? It is not documented in pragmas.html. The compiler front end appears to accept it. (In fact, Decls.m3 contains constants that suggest limitations on what declarations the pragma can appear on, but these are not actually enforced.) It liberalizes the alignment rules, generally allowing scalars to start on any byte boundary. Pickles have to be able to reconstruct the layout of types as the compiler would have done it for a machine (on which a now-being-read pickle was written) with different word size and alignment properties. Currently, pickles are completely unaware of lazy alignment. It would have to be encoded in type descriptions generated by the compiler using TipeDesc and read by pickles using RTTipe. Most troubling to me is what looks like a linguistic Pandora's box. The pragma can be associated with any constant, variable, or type _declaration_ (not type definition), with the result that different values of the same type can actually be different in their alignment rules and thus their layout. Similarly for different identifiers equated to the same type. Although the effects of this could possibly be hidden from the programmer in purely safe code, not so with unsafe code. I haven't thoroughly thought this through, but seems to me to really fly in the face of the whole typing philosophy of the language. For example, if pickles were to read in an object value, and there were >1 variants of the object's type in the reading program, differing only in the alignment rules, how would it decide which one to build? In fact, ignoring pickles altogether and just looking at a single program, if the object's type doesn't actually uniquely give its memory layout, how can it be accessed correctly? Additionally, a quick look at the compiler suggests it won't generate correct code for whole record assignment when the LHS and RHS are the same type but have different alignment characteristics. The more I think about it, it seems the only workable possibilities are: 1) Require the pragma to be associated only with a type _definition_ not a declaration (e.g., allow RECORD <*LAZYALIGN*> ... END) and make this a property of the type that propagates to all names for the type and all variables, constants, etc. Also, this would make this property a part of the type signature that pickles uses when reading, -OR- 2) Forget it altogether. What do people think? -- ------------------------------------------------------------- Rodney M. Bates, retired assistant professor Dept. of Computer Science, Wichita State University Wichita, KS 67260-0083 316-978-3922 rodney.bates at wichita.edu From jayk123 at hotmail.com Mon Feb 11 10:15:50 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 11 Feb 2008 09:15:50 +0000 Subject: [M3devel] FW: [M3commit] CVS Update: cm3 In-Reply-To: <20080211091341.D290C10D4527@birch.elegosoft.com> References: <20080211091341.D290C10D4527@birch.elegosoft.com> Message-ID: Aren't we better off with more VAR parameters and fewer UNTRACED REFs?That way more interfaces/modules can be "safe", as this one changed? (Does anyone care about NT 3.1 or, gasp, Win32s compat? :) ) (Maybe a "DJGPP" target will satisfy? :) ) - Jay > Date: Mon, 11 Feb 2008 10:13:41 +0000> To: m3commit at elegosoft.com> From: jkrell at elego.de> Subject: [M3commit] CVS Update: cm3> > CVSROOT: /usr/cvs> Changes by: jkrell at birch. 08/02/11 10:13:41> > Modified files:> cm3/m3-libs/m3core/src/time/WIN32/: Time.m3 > cm3/m3-libs/m3core/src/win32/: WinBase.i3 > > Log message:> at the expense of NT 3.1 compatibility use GetSystemTimeAsFileTime> instead of GetSystemTime + SystemTimeToFileTime> _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Feb 11 10:29:10 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 11 Feb 2008 09:29:10 +0000 Subject: [M3devel] introducing VAR in more places? In-Reply-To: <20080211092401.1068410D466B@birch.elegosoft.com> References: <20080211092401.1068410D466B@birch.elegosoft.com> Message-ID: Does anyone else find it bothersome that you can't introduce VARs anywhere? Kind of like in C++? Ok, or if you grant that frame size doesn't matter THAT much, and the compiler might do stack packing anyway, you can move all your locals up top like typical C, but still, how about for the module initializer? Still it seems good to me to do manual stack packing since it is often so easy.. WITH helps, but only for "relative constants". It would be nice if the code below could have still loops until t0 != t1, but the repeat condition is outside the scope in which t1 is available. This feels quite lame.. - Jay > Date: Mon, 11 Feb 2008 10:24:00 +0000> To: m3commit at elegosoft.com> From: jkrell at elego.de> Subject: [M3commit] CVS Update: cm3> > CVSROOT: /usr/cvs> Changes by: jkrell at birch. 08/02/11 10:24:00> > Modified files:> cm3/m3-libs/m3core/src/time/WIN32/: Time.m3 > > Log message:> no need for globals here..> _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Feb 11 10:35:16 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 11 Feb 2008 09:35:16 +0000 Subject: [M3devel] what processors anyone cares about? In-Reply-To: References: <20080211091341.D290C10D4527@birch.elegosoft.com> Message-ID: ps: I will point out that NT 3.1 doesn't have have good compatibility with things like VMware or Virtual PC (or vice versa), not sure it will even run on modern hardware (the problem is probably these virtual machines exposing too much?) also what processors do people care about? 386? 486? Pentium I? (Pentium's with the FDIV bug? I still see remnants of the workaround for that..) The newer processors have some nice seeming instructions. Like read timestamp counter, interlocked compare exchange 64, interlocked increment/decrement (on circa 386, those Win32 functions don't return the new value, only <0, 0, or >0), conditional mov, etc. And there is MMX, XMM (SSE?), SSE2/3/4..the instruction set advances don't seem to ever stop.. Nice thing about AMD64 is it establishes a new baseline. I can't claim to have done any profiling with or without these instructions used.. nor that the integrated backend will ever advance in these areas.. - Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Mon, 11 Feb 2008 09:15:50 +0000Subject: [M3devel] FW: [M3commit] CVS Update: cm3 Aren't we better off with more VAR parameters and fewer UNTRACED REFs?That way more interfaces/modules can be "safe", as this one changed? (Does anyone care about NT 3.1 or, gasp, Win32s compat? :) )(Maybe a "DJGPP" target will satisfy? :) ) - Jay > Date: Mon, 11 Feb 2008 10:13:41 +0000> To: m3commit at elegosoft.com> From: jkrell at elego.de> Subject: [M3commit] CVS Update: cm3> > CVSROOT: /usr/cvs> Changes by: jkrell at birch. 08/02/11 10:13:41> > Modified files:> cm3/m3-libs/m3core/src/time/WIN32/: Time.m3 > cm3/m3-libs/m3core/src/win32/: WinBase.i3 > > Log message:> at the expense of NT 3.1 compatibility use GetSystemTimeAsFileTime> instead of GetSystemTime + SystemTimeToFileTime> Need to know the score, the latest news, or you need your Hotmail?-get your "fix". Check it out. _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Mon Feb 11 10:58:18 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 11 Feb 2008 01:58:18 -0800 Subject: [M3devel] introducing VAR in more places? In-Reply-To: Your message of "Mon, 11 Feb 2008 09:29:10 GMT." Message-ID: <200802110958.m1B9wJ9u035766@camembert.async.caltech.edu> Jay writes: >--_568f4bdf-b056-453b-9c29-b8dff8a8bb4c_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > >Does anyone else find it bothersome that you can't introduce VARs anywhere?= > Kind of like in C++? No. From jayk123 at hotmail.com Mon Feb 11 11:13:09 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 11 Feb 2008 10:13:09 +0000 Subject: [M3devel] <*external winapi*> silently ignored on all platforms? Message-ID: I know this won't be popular but... over in m3-db\odbc\src, there is POSIX and WIN32, and they are ALMOST identical. The differences are the UNUSED type SQLHWND is ADDRESS or HWNDThis should just be removed. In Win32 all the <*external*> pragmas have WINAPI. In Posix, they lack it. For this and other reasons, I suggest that all CM3 frontends accept but silentlyignore the Win32/x86 calling conventions in <*external*> pragmas,similar to what the non-x86 Windows compilers do. The other reasons would be the "FARPROC" warning that I already cleared up otherwise. And anything else minor that comes up. I know this won't be popular but I REALLY REALLY REALLY believe is the right thing.It is a small safe change that will allow a little more Modula-3 source portability. A similar suggestion would be to change the default calling convention in Modula-3,it would very possibly reduce code size, but is very very very much a breakingchange so probably can never happen.Better probably would be to a) add a switch for this b) extend the .m3exportsor whatnot files to indicate what switch was used. A "blanket pragma" might also be good, so that the various *.i3 files cansay just to assume __stdcall for the rest of the file instead of annotating each functions. - Jay _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Mon Feb 11 11:20:59 2008 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Mon, 11 Feb 2008 11:20:59 +0100 Subject: [M3devel] introducing VAR in more places? In-Reply-To: References: <20080211092401.1068410D466B@birch.elegosoft.com> Message-ID: <1202725259.8543.22.camel@faramir.m3w.org> Why would we, when in M3 we can have blocks as statements? Isn't that a mechanism to localize scope even more? d On Mon, 2008-02-11 at 09:29 +0000, Jay wrote: > Does anyone else find it bothersome that you can't introduce VARs > anywhere? Kind of like in C++? > Ok, or if you grant that frame size doesn't matter THAT much, and the > compiler might do stack packing anyway, you can move all your locals > up top like typical C, but still, how about for the module > initializer? > Still it seems good to me to do manual stack packing since it is often > so easy.. > WITH helps, but only for "relative constants". > > It would be nice if the code below could have still loops until t0 != > t1, but the repeat condition is outside the scope in which t1 is > available. This feels quite lame.. > > - Jay > > > > ______________________________________________________________________ > > > Date: Mon, 11 Feb 2008 10:24:00 +0000 > > To: m3commit at elegosoft.com > > From: jkrell at elego.de > > Subject: [M3commit] CVS Update: cm3 > > > > CVSROOT: /usr/cvs > > Changes by: jkrell at birch. 08/02/11 10:24:00 > > > > Modified files: > > cm3/m3-libs/m3core/src/time/WIN32/: Time.m3 > > > > Log message: > > no need for globals here.. > > > > > > ______________________________________________________________________ > Helping your favorite cause is as easy as instant messaging. You IM, > we give. Learn more. -- Dragi?a Duri? From jayk123 at hotmail.com Mon Feb 11 11:34:19 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 11 Feb 2008 10:34:19 +0000 Subject: [M3devel] __declspec(dllimport)? Message-ID: __declspec(dllimport) is a nice little cheap optimization on Windows. When you are calling a function that you will be dynamically linking to, it saves one instructions per call. On Windows, the way dynamic linking works is that for all your imports, there is one array of pointers in your .dll/.exe. It could actually be discontiguous. It is an array per .dll rather, with a terminal NULL for each .dll you import from. All the dynamic loader does is write pointers into this array at load time. It does not have to, like, go all through your code patching stuff up. If you just call Foo, but end up importing Foo, the linker generates a one instruction function: Foo: jmp dword ptr[__imp__Foo] __imp__Foo is in that array that gets patched up. However if you declare Foo to be __declspec(dllimport), the compiler will instead of: call Foo generate: call dword ptr[__imp__Foo] in fact, if you have multiple nearby calls to Foo, the compiler knows these pointers are "relatively const" and will fetch the pointer and hold it in a register and make the calls through the register. There is a problem with __declspec(dllimport). Essentially, you know, for every imported function Foo, there is somewhere out there someone implementing it. They are not importing it. They are exporting it. While getting this declaration wrong is actually "ok", it ends up costing the implementer an extra instruction on their calls, and generates a linker warning ("importing local function"). So what ends up happening usually is either a) the implementer doesn't #include his own header files, generally a bad bad bad idea or b) for every .dll bar.dll, a macro is made up BARAPI and then the code usually goes like: #ifndef BARAPI #define BARAPI __declspec(dllimport) #endif BARAPI void __stdcall Foo(void); and the implementer will define BARAPI to either be nothing/empty, or __declspec(dllexport). (__declspec(dllexport) is another topic, I'll try not to go into here.) This is a little gross, this proliferation of "cover" macros for __declspec(dllimport). But it IS a nice little optimization. Actually I suspect many people think these annotations are required. But they almost never ever are. But they are nice to have. So, what do people think? Worth some syntax? In <*extern*> pragmas? Gcc already understand this stuff I believe. I think I noticed it when looking at the __stdcall stuff. Another wrinkle here is that Modula-3 has this nice build_standalone() feature, which switches whether or not you dynamically link. It would tend to invalidate statements here, at least about Modula-3 code. On the matter of when __declspec(dllimport) is needed. - I'm not sure about C++ classes. You should just never import then really, but use COM instead, but people do. (COM is just using pure virtual function calls -- ie: calls through structs containing all function pointers, and get a pointer to said struct via a special C creation function). - It is needed for data, at least with Microsoft tools. The GNU tools seem to have some workaround here. Notice I pointed out the linker generates a function for you if you don't make the annotation. You can't intervene on data accesses with a function call, unless, say, you've inserted a function call for every single data access, or if you can still go back and change the code, like at link time. Data imports are rare and I suggest just never use them. But they are much faster when they suffice, true. __declspec(dllexport) can generally just be replaced with a .def file. - again, I don't know about C++ classes - for C++ functions, the .def file will contain some ugly processor-specific mangled names, a little bit difficult/annoying to come up with and put in the .def file, but not impossible by far (link /dump /symbols | findstr /v UNDEF for example) - again, just don't export C++ classes, or mangled/overloaded/etc. names, only export C functions and you are set with a .def file; this also aids compatibility with multiple compilers and languages (!) - (C++ is largely well and good and I can tell you what is good about it, but one thing it is NOT good for is defining dynamically linked interfaces; I think Modula-3 can get into the same trap -- e.g. traffic only in a few base types (integer, text) and opaque types, don't let dynamically linked callers know about your record format/offsets, else you'll have to recompile "too often") __declspec(dllexport) provides no optimization analogous to __declspec(dllimport). - Jay _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Feb 11 11:36:19 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 11 Feb 2008 10:36:19 +0000 Subject: [M3devel] introducing VAR in more places? In-Reply-To: <1202725259.8543.22.camel@faramir.m3w.org> References: <20080211092401.1068410D466B@birch.elegosoft.com> <1202725259.8543.22.camel@faramir.m3w.org> Message-ID: Could be my ignorance of Modula-3 then..let me try a bit more.. - Jay > Subject: Re: [M3devel] introducing VAR in more places?> From: dragisha at m3w.org> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Date: Mon, 11 Feb 2008 11:20:59 +0100> > Why would we, when in M3 we can have blocks as statements? Isn't that a> mechanism to localize scope even more?> > d> > On Mon, 2008-02-11 at 09:29 +0000, Jay wrote:> > Does anyone else find it bothersome that you can't introduce VARs> > anywhere? Kind of like in C++?> > Ok, or if you grant that frame size doesn't matter THAT much, and the> > compiler might do stack packing anyway, you can move all your locals> > up top like typical C, but still, how about for the module> > initializer?> > Still it seems good to me to do manual stack packing since it is often> > so easy..> > WITH helps, but only for "relative constants".> > > > It would be nice if the code below could have still loops until t0 !=> > t1, but the repeat condition is outside the scope in which t1 is> > available. This feels quite lame..> > > > - Jay> > > > > > > > ______________________________________________________________________> > > > > Date: Mon, 11 Feb 2008 10:24:00 +0000> > > To: m3commit at elegosoft.com> > > From: jkrell at elego.de> > > Subject: [M3commit] CVS Update: cm3> > > > > > CVSROOT: /usr/cvs> > > Changes by: jkrell at birch. 08/02/11 10:24:00> > > > > > Modified files:> > > cm3/m3-libs/m3core/src/time/WIN32/: Time.m3 > > > > > > Log message:> > > no need for globals here..> > > > > > > > > > > ______________________________________________________________________> > Helping your favorite cause is as easy as instant messaging. You IM,> > we give. Learn more.> -- > Dragi?a Duri? > _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Mon Feb 11 12:04:09 2008 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Mon, 11 Feb 2008 12:04:09 +0100 Subject: [M3devel] introducing VAR in more places? In-Reply-To: <1202725259.8543.22.camel@faramir.m3w.org> References: <20080211092401.1068410D466B@birch.elegosoft.com> <1202725259.8543.22.camel@faramir.m3w.org> Message-ID: <1202727849.8543.24.camel@faramir.m3w.org> A piece of code, from the middle of somewhere... len:=Wr.Length(swr.wr); data := TextWr.ToText(swr.wr); VAR s: Ctypes.char_star := M3toC.CopyTtoS(data); ff: ADDRESS := LOOPHOLE(s, ADDRESS); a: UNTRACED REF CHAR; spent: CARDINAL := 0; checkSum: Word.T := 0; BEGIN a := ff; WITH sum = NEW(Sumator) DO sum.reset(); > On Mon, 2008-02-11 at 11:20 +0100, Dragi?a Duri? wrote: > Why would we, when in M3 we can have blocks as statements? Isn't that a > mechanism to localize scope even more? > > d > > On Mon, 2008-02-11 at 09:29 +0000, Jay wrote: > > Does anyone else find it bothersome that you can't introduce VARs > > anywhere? Kind of like in C++? > > Ok, or if you grant that frame size doesn't matter THAT much, and the > > compiler might do stack packing anyway, you can move all your locals > > up top like typical C, but still, how about for the module > > initializer? > > Still it seems good to me to do manual stack packing since it is often > > so easy.. > > WITH helps, but only for "relative constants". > > > > It would be nice if the code below could have still loops until t0 != > > t1, but the repeat condition is outside the scope in which t1 is > > available. This feels quite lame.. > > > > - Jay > > > > > > > > ______________________________________________________________________ > > > > > Date: Mon, 11 Feb 2008 10:24:00 +0000 > > > To: m3commit at elegosoft.com > > > From: jkrell at elego.de > > > Subject: [M3commit] CVS Update: cm3 > > > > > > CVSROOT: /usr/cvs > > > Changes by: jkrell at birch. 08/02/11 10:24:00 > > > > > > Modified files: > > > cm3/m3-libs/m3core/src/time/WIN32/: Time.m3 > > > > > > Log message: > > > no need for globals here.. > > > > > > > > > > > ______________________________________________________________________ > > Helping your favorite cause is as easy as instant messaging. You IM, > > we give. Learn more. -- Dragi?a Duri? From jayk123 at hotmail.com Mon Feb 11 12:23:18 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 11 Feb 2008 11:23:18 +0000 Subject: [M3devel] size_t? In-Reply-To: <1202725259.8543.22.camel@faramir.m3w.org> References: <20080211092401.1068410D466B@birch.elegosoft.com> <1202725259.8543.22.camel@faramir.m3w.org> Message-ID: C:\dev2\cm3.2\m3-libs\m3core\src\C\Common\Cstddef.i3(12): size_t = INTEGER; really? it is signed? and we are sure this is going to be 64 bits on 64 bit targets? size_t and ptrdiff_t ought to be in BasicCtypes, right?That has a 32 bit and 64 bit version, at least. Does INTEGER effectively equal int or ptrdiff_t? - Jay _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Feb 11 12:28:01 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 11 Feb 2008 11:28:01 +0000 Subject: [M3devel] introducing VAR in more places? In-Reply-To: <1202727849.8543.24.camel@faramir.m3w.org> References: <20080211092401.1068410D466B@birch.elegosoft.com> <1202725259.8543.22.camel@faramir.m3w.org> <1202727849.8543.24.camel@faramir.m3w.org> Message-ID: ok thanks, done > Subject: Re: [M3devel] introducing VAR in more places?> From: dragisha at m3w.org> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Date: Mon, 11 Feb 2008 12:04:09 +0100> > A piece of code, from the middle of somewhere...> > len:=Wr.Length(swr.wr);> data := TextWr.ToText(swr.wr);> VAR> s: Ctypes.char_star := M3toC.CopyTtoS(data);> ff: ADDRESS := LOOPHOLE(s, ADDRESS);> a: UNTRACED REF CHAR;> > spent: CARDINAL := 0;> checkSum: Word.T := 0;> BEGIN> a := ff;> WITH sum = NEW(Sumator) DO> sum.reset();> > > > On Mon, 2008-02-11 at 11:20 +0100, Dragi?a Duri? wrote:> > Why would we, when in M3 we can have blocks as statements? Isn't that a> > mechanism to localize scope even more?> > > > d> > > > On Mon, 2008-02-11 at 09:29 +0000, Jay wrote:> > > Does anyone else find it bothersome that you can't introduce VARs> > > anywhere? Kind of like in C++?> > > Ok, or if you grant that frame size doesn't matter THAT much, and the> > > compiler might do stack packing anyway, you can move all your locals> > > up top like typical C, but still, how about for the module> > > initializer?> > > Still it seems good to me to do manual stack packing since it is often> > > so easy..> > > WITH helps, but only for "relative constants".> > > > > > It would be nice if the code below could have still loops until t0 !=> > > t1, but the repeat condition is outside the scope in which t1 is> > > available. This feels quite lame..> > > > > > - Jay> > > > > > > > > > > > ______________________________________________________________________> > > > > > > Date: Mon, 11 Feb 2008 10:24:00 +0000> > > > To: m3commit at elegosoft.com> > > > From: jkrell at elego.de> > > > Subject: [M3commit] CVS Update: cm3> > > > > > > > CVSROOT: /usr/cvs> > > > Changes by: jkrell at birch. 08/02/11 10:24:00> > > > > > > > Modified files:> > > > cm3/m3-libs/m3core/src/time/WIN32/: Time.m3 > > > > > > > > Log message:> > > > no need for globals here..> > > > > > > > > > > > > > > > ______________________________________________________________________> > > Helping your favorite cause is as easy as instant messaging. You IM,> > > we give. Learn more.> -- > Dragi?a Duri? > _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Feb 11 12:30:37 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 11 Feb 2008 12:30:37 +0100 Subject: [M3devel] <*external winapi*> silently ignored on all platforms? In-Reply-To: References: Message-ID: <20080211123037.khzk55js4k0kccc0@mail.elegosoft.com> Quoting Jay : > I know this won't be popular but... > over in m3-db\odbc\src, there is POSIX and WIN32, and they are > ALMOST identical. > The differences are > the UNUSED type SQLHWND is ADDRESS or HWNDThis should just be removed. > In Win32 all the <*external*> pragmas have WINAPI. > In Posix, they lack it. > For this and other reasons, I suggest that all CM3 frontends accept > but silentlyignore the Win32/x86 calling conventions in <*external*> > pragmas,similar to what the non-x86 Windows compilers do. > The other reasons would be the "FARPROC" warning that I already > cleared up otherwise. > And anything else minor that comes up. > > I know this won't be popular but I REALLY REALLY REALLY believe is > the right thing.It is a small safe change that will allow a little > more Modula-3 source portability. If I understand you correctly, you'd like to declare the external procedures as WINAPI in general and let all backends except the Windows one ignore it. We should not call it WINAPI then, I think; what about SYSAPI as a general abstraction? > A similar suggestion would be to change the default calling > convention in Modula-3,it would very possibly reduce code size, but > is very very very much a breakingchange so probably can never > happen.Better probably would be to a) add a switch for this b) > extend the .m3exportsor whatnot files to indicate what switch was > used. We shouldn't change the default calling conventions. That is, we should check very very carefully if there are negative effects of doing this and how we cope with them. Until this has been done, we shouldn't change the default calling conventions :-) > A "blanket pragma" might also be good, so that the various *.i3 > files cansay just to assume __stdcall for the rest of the file > instead of annotating each functions. You're talking about a pragma default for all declarations in a file, aren't you? I wouldn't object to that, but it would probably need some compiler extensions, wouldn't it? Olaf -- Olaf Wagner -- elego Software Solutions GmbH 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 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jayk123 at hotmail.com Mon Feb 11 13:41:39 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 11 Feb 2008 12:41:39 +0000 Subject: [M3devel] <*external winapi*> silently ignored on all platforms? In-Reply-To: <20080211123037.khzk55js4k0kccc0@mail.elegosoft.com> References: <20080211123037.khzk55js4k0kccc0@mail.elegosoft.com> Message-ID: Olaf, yes you understand me. I strongly object to calling it SYSAPI however, or pretty much any attempt at further abstraction here. I would consider some sort of qualifier that says when to pay attention, when to ignore. For example using a platform name, <*external NT386:WINAPI*>. This is edging toward "preprocessing" but an incredibly small step. (Even though a big problem with preprocessing is rampant context sensitivity, sensitivity to what the target is, and reparsing for every target, is reasonable, and is how M3 already works.) It isn't the "system" calling convention really, it is just very commonly used by the "OS". The "OS" is just a bunch of .dlls, and many of them happen to use __stdcall aka WINAPI a lot, but not all, and not for all functions. "system" MIGHT be how you call the kernel, but that is different. (calling the kernel is not directly exposed in Win32, "kernel32.dll" is not the kernel, ntoskrnl.exe is). msvcrt.dll uses __cdecl for the most part. Anything that accepts varargs, which is very few functions, uses __cdecl, out of necessity (at least give a "normal" point of view, I did used to use a system where calleee popped varargs...). If you write drivers, a small number of functions are __fastcall. I would rather drop the synonyms and just have __cdecl, __fastcall, __stdcall, than to invent "SYSAPI". However I don't really want to do that, "WINAPI" and the other names are useful for a more literal translation of headers. There is a mix of calling conventions on x86 Windows and there is not really one "SYSAPI". The negative affects of changing the default calling convention is breaking all existing dynamic links where you only rebuild one side and where the calling convention wasn't explicit (all of them). Very very bad. > you'd like to declare the external procedures as WINAPI in general Not quite in general perhaps. But I guess any file for which someone has portable C and it is built for NT386 and anything else. Explicit calling conventions are always reasonable on NT386 and never reasonable anywhere else. The Visual C++ compiler has a command line switch as to what the default calling convention is, and widely used headers should work no matter what is the default. - Jay > Date: Mon, 11 Feb 2008 12:30:37 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] <*external winapi*> silently ignored on all platforms?> > Quoting Jay :> > > I know this won't be popular but...> > over in m3-db\odbc\src, there is POSIX and WIN32, and they are > > ALMOST identical.> > The differences are> > the UNUSED type SQLHWND is ADDRESS or HWNDThis should just be removed.> > In Win32 all the <*external*> pragmas have WINAPI.> > In Posix, they lack it.> > For this and other reasons, I suggest that all CM3 frontends accept > > but silentlyignore the Win32/x86 calling conventions in <*external*> > > pragmas,similar to what the non-x86 Windows compilers do.> > The other reasons would be the "FARPROC" warning that I already > > cleared up otherwise.> > And anything else minor that comes up.> >> > I know this won't be popular but I REALLY REALLY REALLY believe is > > the right thing.It is a small safe change that will allow a little > > more Modula-3 source portability.> > If I understand you correctly, you'd like to declare the external> procedures as WINAPI in general and let all backends except the> Windows one ignore it. We should not call it WINAPI then, I think;> what about SYSAPI as a general abstraction?> > > A similar suggestion would be to change the default calling > > convention in Modula-3,it would very possibly reduce code size, but > > is very very very much a breakingchange so probably can never > > happen.Better probably would be to a) add a switch for this b) > > extend the .m3exportsor whatnot files to indicate what switch was > > used.> > We shouldn't change the default calling conventions. That is, we should> check very very carefully if there are negative effects of doing this> and how we cope with them.> Until this has been done, we shouldn't change the default calling> conventions :-)> > > A "blanket pragma" might also be good, so that the various *.i3 > > files cansay just to assume __stdcall for the rest of the file > > instead of annotating each functions.> > You're talking about a pragma default for all declarations in a> file, aren't you? I wouldn't object to that, but it would> probably need some compiler extensions, wouldn't it?> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> 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> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Feb 11 13:48:23 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 11 Feb 2008 12:48:23 +0000 Subject: [M3devel] imports anywhere? In-Reply-To: <20080211111256.22C8E10D4628@birch.elegosoft.com> References: <20080211111256.22C8E10D4628@birch.elegosoft.com> Message-ID: Here is another SMALL gripe with the language. The need to put IMPORTS at the top (or is it just common style?), leads to something I have seen several times. You comment out some code, thereby deleting the only/last use of some import, that nets you warnings about unused imports. Granted, they are "only" warnings, but I try to have none. Also granted, you can either comment out or just go ahead and remove the imports, easy. It might be nice if the IMPORTS could be adjacent to the code using the IMPORTS, so that they can be comment out or removed together. This "problem" is not unique to Modula-3, by far. In fact, Modula-3 is probably more able to warn about this low cost waste due to its much better module system, compared to say, C and C++ #includes... - Jay > Date: Mon, 11 Feb 2008 12:12:56 +0000> To: m3commit at elegosoft.com> From: jkrell at elego.de> Subject: [M3commit] CVS Update: cm3> > CVSROOT: /usr/cvs> Changes by: jkrell at birch. 08/02/11 12:12:56> > Modified files:> cm3/m3-ui/ui/src/winvbt/: WinScreenType.m3 > > Log message:> fix warning about unused import (the use is commented out..would be nice> to be able to move the import to near the code so they can be commented> out together..)> _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Feb 11 14:12:03 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 11 Feb 2008 14:12:03 +0100 Subject: [M3devel] <*external winapi*> silently ignored on all platforms? In-Reply-To: References: <20080211123037.khzk55js4k0kccc0@mail.elegosoft.com> Message-ID: <20080211141203.c41zlbvp8gsw84k4@mail.elegosoft.com> Quoting Jay : > Olaf, yes you understand me. > > I strongly object to calling it SYSAPI however, or pretty much any > attempt at further abstraction here. > > I would consider some sort of qualifier that says when to pay > attention, when to ignore. > For example using a platform name, <*external NT386:WINAPI*>. > This is edging toward "preprocessing" but an incredibly small step. > (Even though a big problem with preprocessing is rampant context > sensitivity, sensitivity to what the target is, and reparsing for > every target, is reasonable, and is how M3 already works.) > > It isn't the "system" calling convention really, it is just very > commonly used by the "OS". The "OS" is just a bunch of .dlls, and > many of them happen to use __stdcall aka WINAPI a lot, but not all, > and not for all functions. "system" MIGHT be how you call the > kernel, but that is different. (calling the kernel is not directly > exposed in Win32, "kernel32.dll" is not the kernel, ntoskrnl.exe is). OK, so it's not system specific, but its system specific that there are multiple calling conventions for Windows. However, I'm still not convinced that this may affect only Windows systems and no others. It may sound academic, but wouldn't it be possible that suddenly Apple (or even some new OS player :) comes up with similar distinctions? I think we shouldn't implement a pragma convention that is usable only for Windows, but one that is more generic. If we can just extend your example to something like <*EXTERNAL NT386:WINAPI, ANOTHER_TARGET:VERY_SPECIAL_CALLING_CONVENTION, ...*> this would be better. As for the semantic differences on different target platforms, I think we could live with them given that all this stuff is system dependent and unsafe anyway, but I'd like to hear the opinion of others on this topic, too. Olaf > msvcrt.dll uses __cdecl for the most part. > Anything that accepts varargs, which is very few functions, uses > __cdecl, out of necessity (at least give a "normal" point of view, I > did used to use a system where calleee popped varargs...). > If you write drivers, a small number of functions are __fastcall. > I would rather drop the synonyms and just have __cdecl, __fastcall, > __stdcall, than to invent "SYSAPI". > However I don't really want to do that, "WINAPI" and the other names > are useful for a more literal translation of headers. > There is a mix of calling conventions on x86 Windows and there is > not really one "SYSAPI". > > The negative affects of changing the default calling convention is > breaking all existing dynamic links where you only rebuild one side > and where the calling convention wasn't explicit (all of them). Very > very bad. > > > you'd like to declare the external procedures as WINAPI in general > > Not quite in general perhaps. > But I guess any file for which someone has portable C and it is > built for NT386 and anything else. > Explicit calling conventions are always reasonable on NT386 and > never reasonable anywhere else. > The Visual C++ compiler has a command line switch as to what the > default calling convention is, and widely used headers should work > no matter what is the default. -- Olaf Wagner -- elego Software Solutions GmbH 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 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Mon Feb 11 14:17:56 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 11 Feb 2008 14:17:56 +0100 Subject: [M3devel] imports anywhere? In-Reply-To: References: <20080211111256.22C8E10D4628@birch.elegosoft.com> Message-ID: <20080211141756.n2w5tkktkoo4s08o@mail.elegosoft.com> Quoting Jay : > Here is another SMALL gripe with the language. > The need to put IMPORTS at the top (or is it just common style?), > leads to something I have seen several times. > You comment out some code, thereby deleting the only/last use of > some import, that nets you warnings about unused imports. Granted, > they are "only" warnings, but I try to have none. Also granted, you > can either comment out or just go ahead and remove the imports, easy. > > It might be nice if the IMPORTS could be adjacent to the code using > the IMPORTS, so that they can be comment out or removed together. > > This "problem" is not unique to Modula-3, by far. > In fact, Modula-3 is probably more able to warn about this low cost > waste due to its much better module system, compared to say, C and > C++ #includes.. I wouldn't like to see any changes here. It is good that all the imports are explicit, and it is good that they are at the top (to define the dependencies). It's not much effort to add or remove an import for debugging etc. If you are really lazy, you can always use the NOWARN pragma: IMPOPRT IO <*NOWARN*> to suppres the warnings for that declaration. That was not your point though. Olaf -- Olaf Wagner -- elego Software Solutions GmbH 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 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jayk123 at hotmail.com Mon Feb 11 14:31:41 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 11 Feb 2008 13:31:41 +0000 Subject: [M3devel] <*external winapi*> silently ignored on all platforms? In-Reply-To: <20080211141203.c41zlbvp8gsw84k4@mail.elegosoft.com> References: <20080211123037.khzk55js4k0kccc0@mail.elegosoft.com> <20080211141203.c41zlbvp8gsw84k4@mail.elegosoft.com> Message-ID: I don't think anyone else will commit the error of having multiple calling conventions. It's a bad place to be. Granted, kernels often do have an unusual calling convention, but that gets wrapped up in something "normal". > <*EXTERNAL NT386:WINAPI, > ANOTHER_TARGET:VERY_SPECIAL_CALLING_CONVENTION, ...*> In practice this will only ever be: > <*EXTERNAL NT386:WINAPI *> and I am satisfied. :) oh, btw, the other obvious: > <*NT386:EXTERNAL WINAPI *> or even in general both -- pragms can all be prefixed with a platform. In practise, "external" is platform-independent, calling convention is not. There might be exceptions, where particular platforms require a Modula-3 wrapper. As Cygwin had briefly for semaphore initialization. I guess this really does in general resemble preprocessing, only by target, only of pragmas, and the point really is to limit per-platform branching when the platforms are indeed extremely similar. This is a common pattern -- if'ing stuff midly, if'ing stuff to heck, vs. splitting out in separate implementation with no ugly if'ing. OpenGL is in a similar boat here, except that it seems to be a disproof. It appears the Cygwin/X OpenGL functions use __cdecl while the Microsoft ones use __stdcall. Again the *.i3 files are almost the same, except for calling conventions, but it seems the "NT386 POSIX" variant uses a different calling convention than the "NT386 WIN32" variant. I am not 100% what is going on in OpenGL. Building "std" for NT386GNU gets at least as far as anim3d, however I haven't run much of the code at all -- only enough of cm3 to see it has a problem with paths... I'm still just using a "regular" NT386 in a sort of cross scenario. - Jay > Date: Mon, 11 Feb 2008 14:12:03 +0100> From: wagner at elegosoft.com> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: RE: [M3devel] <*external winapi*> silently ignored on all platforms?> > Quoting Jay :> > Olaf, yes you understand me.> >> > I strongly object to calling it SYSAPI however, or pretty much any > > attempt at further abstraction here.> >> > I would consider some sort of qualifier that says when to pay > > attention, when to ignore.> > For example using a platform name, <*external NT386:WINAPI*>.> > This is edging toward "preprocessing" but an incredibly small step.> > (Even though a big problem with preprocessing is rampant context > > sensitivity, sensitivity to what the target is, and reparsing for > > every target, is reasonable, and is how M3 already works.)> >> > It isn't the "system" calling convention really, it is just very > > commonly used by the "OS". The "OS" is just a bunch of .dlls, and > > many of them happen to use __stdcall aka WINAPI a lot, but not all, > > and not for all functions. "system" MIGHT be how you call the > > kernel, but that is different. (calling the kernel is not directly > > exposed in Win32, "kernel32.dll" is not the kernel, ntoskrnl.exe is).> > OK, so it's not system specific, but its system specific that there> are multiple calling conventions for Windows. However, I'm still not> convinced that this may affect only Windows systems and no others.> It may sound academic, but wouldn't it be possible that suddenly> Apple (or even some new OS player :) comes up with similar distinctions?> > I think we shouldn't implement a pragma convention that is usable> only for Windows, but one that is more generic. If we can just> extend your example to something like> > <*EXTERNAL NT386:WINAPI, > ANOTHER_TARGET:VERY_SPECIAL_CALLING_CONVENTION, ...*>> > this would be better.> > As for the semantic differences on different target platforms, I think> we could live with them given that all this stuff is system dependent> and unsafe anyway, but I'd like to hear the opinion of others on this> topic, too.> > Olaf> > > msvcrt.dll uses __cdecl for the most part.> > Anything that accepts varargs, which is very few functions, uses > > __cdecl, out of necessity (at least give a "normal" point of view, I > > did used to use a system where calleee popped varargs...).> > If you write drivers, a small number of functions are __fastcall.> > I would rather drop the synonyms and just have __cdecl, __fastcall, > > __stdcall, than to invent "SYSAPI".> > However I don't really want to do that, "WINAPI" and the other names > > are useful for a more literal translation of headers.> > There is a mix of calling conventions on x86 Windows and there is > > not really one "SYSAPI".> >> > The negative affects of changing the default calling convention is > > breaking all existing dynamic links where you only rebuild one side > > and where the calling convention wasn't explicit (all of them). Very > > very bad.> >> > > you'd like to declare the external procedures as WINAPI in general> >> > Not quite in general perhaps.> > But I guess any file for which someone has portable C and it is > > built for NT386 and anything else.> > Explicit calling conventions are always reasonable on NT386 and > > never reasonable anywhere else.> > The Visual C++ compiler has a command line switch as to what the > > default calling convention is, and widely used headers should work > > no matter what is the default.> > -- > Olaf Wagner -- elego Software Solutions GmbH> 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> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Feb 11 14:33:42 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 11 Feb 2008 13:33:42 +0000 Subject: [M3devel] imports anywhere? In-Reply-To: <20080211141756.n2w5tkktkoo4s08o@mail.elegosoft.com> References: <20080211111256.22C8E10D4628@birch.elegosoft.com> <20080211141756.n2w5tkktkoo4s08o@mail.elegosoft.com> Message-ID: > If you are really lazy, you can always use the NOWARN pragma: What if I am really really really lazy? :) > I wouldn't like to see any changes here. ok. - Jay > Date: Mon, 11 Feb 2008 14:17:56 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] imports anywhere?> > Quoting Jay :> > > Here is another SMALL gripe with the language.> > The need to put IMPORTS at the top (or is it just common style?), > > leads to something I have seen several times.> > You comment out some code, thereby deleting the only/last use of > > some import, that nets you warnings about unused imports. Granted, > > they are "only" warnings, but I try to have none. Also granted, you > > can either comment out or just go ahead and remove the imports, easy.> >> > It might be nice if the IMPORTS could be adjacent to the code using > > the IMPORTS, so that they can be comment out or removed together.> >> > This "problem" is not unique to Modula-3, by far.> > In fact, Modula-3 is probably more able to warn about this low cost > > waste due to its much better module system, compared to say, C and > > C++ #includes..> > I wouldn't like to see any changes here.> > It is good that all the imports are explicit, and it is good that> they are at the top (to define the dependencies). It's not much> effort to add or remove an import for debugging etc.> > If you are really lazy, you can always use the NOWARN pragma:> > IMPOPRT IO <*NOWARN*>> > to suppres the warnings for that declaration. That was not your> point though.> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> 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> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Feb 11 15:38:14 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 11 Feb 2008 14:38:14 +0000 Subject: [M3devel] external in module? In-Reply-To: <20080211142730.E6B3A10D4655@birch.elegosoft.com> References: <20080211142730.E6B3A10D4655@birch.elegosoft.com> Message-ID: It'd be nice if I could declare externals in modules. In this example, setitimer_ only exists for the wrapper implementation. I don't need it to be visible outside the one module that uses it. I guess I could push it into an unexposed interface, even dedicate "internal.i3" to it?Is that an ok idiom? It's another problem that I don't know what to call these things.. - Jay > Date: Mon, 11 Feb 2008 15:27:30 +0000> To: m3commit at elegosoft.com> From: jkrell at elego.de> Subject: [M3commit] CVS Update: cm3> > CVSROOT: /usr/cvs> Changes by: jkrell at birch. 08/02/11 15:27:30> > Modified files:> cm3/m3-libs/m3core/src/unix/cygwin/: Utime.i3 m3makefile > Added files:> cm3/m3-libs/m3core/src/unix/cygwin/: Utime.m3 > > Log message:> make setitimer(ITIMER_VIRTUAL) always succeed, even though Cygwin> would always fail it (not so accurate a Unix emulation eh?)> _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Feb 11 16:02:40 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 11 Feb 2008 16:02:40 +0100 Subject: [M3devel] external in module? In-Reply-To: References: <20080211142730.E6B3A10D4655@birch.elegosoft.com> Message-ID: <20080211160240.dinb09tktcg44gcs@mail.elegosoft.com> Quoting Jay : > It'd be nice if I could declare externals in modules. > In this example, setitimer_ only exists for the wrapper implementation. > I don't need it to be visible outside the one module that uses it. > I guess I could push it into an unexposed interface, even dedicate > "internal.i3" to it?Is that an ok idiom? Yes, use an internal interface of the package. But you should use another name (something longer and more unique), since the CM3 builder still has problems with multiple defined units AFAIK. This is something that should really be fixed, but that's another topic. (We'd need hierarchical name spaces, but introduce them in a compatible way.) Olaf > It's another problem that I don't know what to call these things.. This usually is _my_ problem :-) -- Olaf Wagner -- elego Software Solutions GmbH 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 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Mon Feb 11 17:23:47 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 11 Feb 2008 11:23:47 -0500 Subject: [M3devel] __declspec(dllimport)? In-Reply-To: References: Message-ID: <34257B37-565F-4ACE-9939-04CCBDE34D1E@cs.purdue.edu> Do we know that this actually results in any real performance improvement. On Feb 11, 2008, at 5:34 AM, Jay wrote: > __declspec(dllimport) is a nice little cheap optimization on Windows. > When you are calling a function that you will be dynamically > linking to, it saves one instructions per call. > > On Windows, the way dynamic linking works is that for all your > imports, there is one array of pointers in your .dll/.exe. > It could actually be discontiguous. It is an array per .dll rather, > with a terminal NULL for each .dll you import from. All the dynamic > loader does is write pointers into this array at load time. It does > not have to, like, go all through your code patching stuff up. > > If you just call Foo, but end up importing Foo, the linker > generates a one instruction function: > Foo: > jmp dword ptr[__imp__Foo] > > __imp__Foo is in that array that gets patched up. > > However if you declare Foo to be __declspec(dllimport), the > compiler will instead of: > call Foo > generate: > call dword ptr[__imp__Foo] > > in fact, if you have multiple nearby calls to Foo, the compiler > knows these pointers are "relatively const" and will fetch the > pointer and hold it in a register and make the calls through the > register. > > There is a problem with __declspec(dllimport). > Essentially, you know, for every imported function Foo, there is > somewhere out there someone implementing it. > They are not importing it. They are exporting it. > While getting this declaration wrong is actually "ok", it ends up > costing the implementer an extra instruction on their calls, and > generates a linker warning ("importing local function"). > > So what ends up happening usually is either a) the implementer > doesn't #include his own header files, generally a bad bad bad idea > or b) for every .dll bar.dll, a macro is made up BARAPI and then > the code usually goes like: > > #ifndef BARAPI > #define BARAPI __declspec(dllimport) > #endif > > BARAPI void __stdcall Foo(void); > > and the implementer will define BARAPI to either be nothing/empty, > or __declspec(dllexport). > (__declspec(dllexport) is another topic, I'll try not to go into > here.) > > This is a little gross, this proliferation of "cover" macros for > __declspec(dllimport). > But it IS a nice little optimization. > Actually I suspect many people think these annotations are required. > But they almost never ever are. But they are nice to have. > > So, what do people think? > Worth some syntax? In <*extern*> pragmas? > Gcc already understand this stuff I believe. > I think I noticed it when looking at the __stdcall stuff. > > Another wrinkle here is that Modula-3 has this nice build_standalone > () feature, which switches whether or not you dynamically link. It > would tend to invalidate statements here, at least about Modula-3 > code. > > On the matter of when __declspec(dllimport) is needed. > - I'm not sure about C++ classes. You should just never import > then really, but use COM instead, but people do. > (COM is just using pure virtual function calls -- ie: calls > through structs containing all function pointers, and get a pointer > to said struct via a special C creation function). > > - It is needed for data, at least with Microsoft tools. The GNU > tools seem to have some workaround here. > Notice I pointed out the linker generates a function for you if > you don't make the annotation. You can't intervene on data accesses > with a function call, unless, say, you've inserted a function call > for every single data access, or if you can still go back and > change the code, like at link time. Data imports are rare and I > suggest just never use them. But they are much faster when they > suffice, true. > > __declspec(dllexport) can generally just be replaced with a .def file. > - again, I don't know about C++ classes > - for C++ functions, the .def file will contain some ugly > processor-specific mangled names, a little bit difficult/annoying > to come up with and put in the .def file, but not impossible by far > (link /dump /symbols | findstr /v UNDEF for example) > - again, just don't export C++ classes, or mangled/overloaded/ > etc. names, only export C functions and you are set with a .def > file; this also aids compatibility with multiple compilers and > languages (!) > - (C++ is largely well and good and I can tell you what is good > about it, but one thing it is NOT good for is defining dynamically > linked interfaces; I think Modula-3 can get into the same trap -- > e.g. traffic only in a few base types (integer, text) and opaque > types, don't let dynamically linked callers know about your record > format/offsets, else you'll have to recompile "too often") > > __declspec(dllexport) provides no optimization analogous to > __declspec(dllimport). > > - Jay > > Connect and share in new ways with Windows Live. Get it now! From hosking at cs.purdue.edu Mon Feb 11 17:26:50 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 11 Feb 2008 11:26:50 -0500 Subject: [M3devel] <*external winapi*> silently ignored on all platforms? In-Reply-To: References: Message-ID: Why not simply default EXTERNAL on Win32 to WINAPI instead? That way, all EXTERNALs will look the same but you won't clutter up non- Win32 with ugly WINAPI. On Feb 11, 2008, at 5:13 AM, Jay wrote: > I know this won't be popular but... > > over in m3-db\odbc\src, there is POSIX and WIN32, and they are > ALMOST identical. > > The differences are > > the UNUSED type SQLHWND is ADDRESS or HWND > This should just be removed. > > In Win32 all the <*external*> pragmas have WINAPI. > In Posix, they lack it. > > For this and other reasons, I suggest that all CM3 frontends accept > but silently > ignore the Win32/x86 calling conventions in <*external*> pragmas, > similar to what the non-x86 Windows compilers do. > > The other reasons would be the "FARPROC" warning that I already > cleared up otherwise. > > And anything else minor that comes up. > > I know this won't be popular but I REALLY REALLY REALLY believe is > the right thing. > It is a small safe change that will allow a little more Modula-3 > source portability. > > A similar suggestion would be to change the default calling > convention in Modula-3, > it would very possibly reduce code size, but is very very very much > a breaking > change so probably can never happen. > Better probably would be to a) add a switch for this b) extend > the .m3exports > or whatnot files to indicate what switch was used. > > A "blanket pragma" might also be good, so that the various *.i3 > files can > say just to assume __stdcall for the rest of the file instead of > annotating each functions. > > - Jay > > > Need to know the score, the latest news, or you need your Hotmail?- > get your "fix". Check it out. From hosking at cs.purdue.edu Mon Feb 11 17:28:56 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 11 Feb 2008 11:28:56 -0500 Subject: [M3devel] <*external winapi*> silently ignored on all platforms? In-Reply-To: References: <20080211123037.khzk55js4k0kccc0@mail.elegosoft.com> <20080211141203.c41zlbvp8gsw84k4@mail.elegosoft.com> Message-ID: <38355684-DFFB-43B0-81D9-D6745EA195BB@cs.purdue.edu> On Feb 11, 2008, at 8:31 AM, Jay wrote: > I don't think anyone else will commit the error of having multiple > calling conventions. > It's a bad place to be. > Granted, kernels often do have an unusual calling convention, but > that gets wrapped up in something "normal". > > > <*EXTERNAL NT386:WINAPI, > > ANOTHER_TARGET:VERY_SPECIAL_CALLING_CONVENTION, ...*> > > In practice this will only ever be: > > > <*EXTERNAL NT386:WINAPI *> I can live with this. > > > and I am satisfied. :) > > oh, btw, the other obvious: > > <*NT386:EXTERNAL WINAPI *> > > or even in general both -- pragms can all be prefixed with a platform. > In practise, "external" is platform-independent, calling convention > is not. > > There might be exceptions, where particular platforms require a > Modula-3 wrapper. As Cygwin had briefly for semaphore > initialization. I guess this really does in general resemble > preprocessing, only by target, only of pragmas, and the point > really is to limit per-platform branching when the platforms are > indeed extremely similar. > > This is a common pattern -- if'ing stuff midly, if'ing stuff to > heck, vs. splitting out in separate implementation with no ugly > if'ing. > > OpenGL is in a similar boat here, except that it seems to be a > disproof. > It appears the Cygwin/X OpenGL functions use __cdecl while the > Microsoft ones use __stdcall. > Again the *.i3 files are almost the same, except for calling > conventions, but it seems the "NT386 POSIX" variant uses a > different calling convention than the "NT386 WIN32" variant. > > I am not 100% what is going on in OpenGL. Building "std" for > NT386GNU gets at least as far as anim3d, however I haven't run much > of the code at all -- only enough of cm3 to see it has a problem > with paths... I'm still just using a "regular" NT386 in a sort of > cross scenario. > > - Jay > > > > Date: Mon, 11 Feb 2008 14:12:03 +0100 > > From: wagner at elegosoft.com > > To: jayk123 at hotmail.com > > CC: m3devel at elegosoft.com > > Subject: RE: [M3devel] <*external winapi*> silently ignored on > all platforms? > > > > Quoting Jay : > > > Olaf, yes you understand me. > > > > > > I strongly object to calling it SYSAPI however, or pretty much any > > > attempt at further abstraction here. > > > > > > I would consider some sort of qualifier that says when to pay > > > attention, when to ignore. > > > For example using a platform name, <*external NT386:WINAPI*>. > > > This is edging toward "preprocessing" but an incredibly small > step. > > > (Even though a big problem with preprocessing is rampant context > > > sensitivity, sensitivity to what the target is, and reparsing for > > > every target, is reasonable, and is how M3 already works.) > > > > > > It isn't the "system" calling convention really, it is just very > > > commonly used by the "OS". The "OS" is just a bunch of .dlls, and > > > many of them happen to use __stdcall aka WINAPI a lot, but not > all, > > > and not for all functions. "system" MIGHT be how you call the > > > kernel, but that is different. (calling the kernel is not directly > > > exposed in Win32, "kernel32.dll" is not the kernel, > ntoskrnl.exe is). > > > > OK, so it's not system specific, but its system specific that there > > are multiple calling conventions for Windows. However, I'm still not > > convinced that this may affect only Windows systems and no others. > > It may sound academic, but wouldn't it be possible that suddenly > > Apple (or even some new OS player :) comes up with similar > distinctions? > > > > I think we shouldn't implement a pragma convention that is usable > > only for Windows, but one that is more generic. If we can just > > extend your example to something like > > > > <*EXTERNAL NT386:WINAPI, > > ANOTHER_TARGET:VERY_SPECIAL_CALLING_CONVENTION, ...*> > > > > this would be better. > > > > As for the semantic differences on different target platforms, I > think > > we could live with them given that all this stuff is system > dependent > > and unsafe anyway, but I'd like to hear the opinion of others on > this > > topic, too. > > > > Olaf > > > > > msvcrt.dll uses __cdecl for the most part. > > > Anything that accepts varargs, which is very few functions, uses > > > __cdecl, out of necessity (at least give a "normal" point of > view, I > > > did used to use a system where calleee popped varargs...). > > > If you write drivers, a small number of functions are __fastcall. > > > I would rather drop the synonyms and just have __cdecl, > __fastcall, > > > __stdcall, than to invent "SYSAPI". > > > However I don't really want to do that, "WINAPI" and the other > names > > > are useful for a more literal translation of headers. > > > There is a mix of calling conventions on x86 Windows and there is > > > not really one "SYSAPI". > > > > > > The negative affects of changing the default calling convention is > > > breaking all existing dynamic links where you only rebuild one > side > > > and where the calling convention wasn't explicit (all of them). > Very > > > very bad. > > > > > > > you'd like to declare the external procedures as WINAPI in > general > > > > > > Not quite in general perhaps. > > > But I guess any file for which someone has portable C and it is > > > built for NT386 and anything else. > > > Explicit calling conventions are always reasonable on NT386 and > > > never reasonable anywhere else. > > > The Visual C++ compiler has a command line switch as to what the > > > default calling convention is, and widely used headers should work > > > no matter what is the default. > > > > -- > > Olaf Wagner -- elego Software Solutions GmbH > > 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 > > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > > > > > Helping your favorite cause is as easy as instant messaging. You > IM, we give. Learn more. From hosking at cs.purdue.edu Mon Feb 11 17:33:07 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 11 Feb 2008 11:33:07 -0500 Subject: [M3devel] FW: [M3commit] CVS Update: cm3 In-Reply-To: References: <20080211091341.D290C10D4527@birch.elegosoft.com> Message-ID: <8B8213B4-3DBF-47CE-BC3E-1EE96B5F43F6@cs.purdue.edu> On Feb 11, 2008, at 4:15 AM, Jay wrote: > Aren't we better off with more VAR parameters and fewer UNTRACED REFs? > That way more interfaces/modules can be "safe", as this one changed? Indeed! I agree. > > > (Does anyone care about NT 3.1 or, gasp, Win32s compat? :) ) > (Maybe a "DJGPP" target will satisfy? :) ) I barely care about Windows :-), whatever version you choose. > > > - Jay > > > > > Date: Mon, 11 Feb 2008 10:13:41 +0000 > > To: m3commit at elegosoft.com > > From: jkrell at elego.de > > Subject: [M3commit] CVS Update: cm3 > > > > CVSROOT: /usr/cvs > > Changes by: jkrell at birch. 08/02/11 10:13:41 > > > > Modified files: > > cm3/m3-libs/m3core/src/time/WIN32/: Time.m3 > > cm3/m3-libs/m3core/src/win32/: WinBase.i3 > > > > Log message: > > at the expense of NT 3.1 compatibility use GetSystemTimeAsFileTime > > instead of GetSystemTime + SystemTimeToFileTime > > > > > Need to know the score, the latest news, or you need your Hotmail?- > get your "fix". Check it out. From hosking at cs.purdue.edu Mon Feb 11 17:34:54 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 11 Feb 2008 11:34:54 -0500 Subject: [M3devel] introducing VAR in more places? In-Reply-To: References: <20080211092401.1068410D466B@birch.elegosoft.com> Message-ID: <400989C4-C086-4F4C-866C-A83F8854B34F@cs.purdue.edu> You can, except you need to explicitly give the block scope: VAR ... BEGIN ... END; I find this much better than C++ where the scope of the new variable is imprecisely defined. On Feb 11, 2008, at 4:29 AM, Jay wrote: > Does anyone else find it bothersome that you can't introduce VARs > anywhere? Kind of like in C++? > Ok, or if you grant that frame size doesn't matter THAT much, and > the compiler might do stack packing anyway, you can move all your > locals up top like typical C, but still, how about for the module > initializer? > Still it seems good to me to do manual stack packing since it is > often so easy.. > WITH helps, but only for "relative constants". > > It would be nice if the code below could have still loops until t0 ! > = t1, but the repeat condition is outside the scope in which t1 is > available. This feels quite lame.. > > - Jay > > > > > Date: Mon, 11 Feb 2008 10:24:00 +0000 > > To: m3commit at elegosoft.com > > From: jkrell at elego.de > > Subject: [M3commit] CVS Update: cm3 > > > > CVSROOT: /usr/cvs > > Changes by: jkrell at birch. 08/02/11 10:24:00 > > > > Modified files: > > cm3/m3-libs/m3core/src/time/WIN32/: Time.m3 > > > > Log message: > > no need for globals here.. > > > > > Helping your favorite cause is as easy as instant messaging. You > IM, we give. Learn more. From hosking at cs.purdue.edu Mon Feb 11 17:38:48 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 11 Feb 2008 11:38:48 -0500 Subject: [M3devel] size_t? In-Reply-To: References: <20080211092401.1068410D466B@birch.elegosoft.com> <1202725259.8543.22.camel@faramir.m3w.org> Message-ID: <5ED85017-467B-4269-903A-AC512E78DF50@cs.purdue.edu> On Feb 11, 2008, at 6:23 AM, Jay wrote: > C:\dev2\cm3.2\m3-libs\m3core\src\C\Common\Cstddef.i3(12): size_t = > INTEGER; > > really? it is signed? > and we are sure this is going to be 64 bits on 64 bit targets? > > size_t and ptrdiff_t ought to be in BasicCtypes, right? > That has a 32 bit and 64 bit version, at least. These are OS-dependent! They should not be in BasicCtypes. > > > Does INTEGER effectively equal int or ptrdiff_t? > > - Jay > > > > > > Shed those extra pounds with MSN and The Biggest Loser! Learn more. From hosking at cs.purdue.edu Mon Feb 11 17:40:11 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 11 Feb 2008 11:40:11 -0500 Subject: [M3devel] imports anywhere? In-Reply-To: References: <20080211111256.22C8E10D4628@birch.elegosoft.com> Message-ID: I hate imports that are scattered throughout since it hides dependencies deep in the guts of the code. Much better to have them explicit at the top! On Feb 11, 2008, at 7:48 AM, Jay wrote: > Here is another SMALL gripe with the language. > The need to put IMPORTS at the top (or is it just common style?), > leads to something I have seen several times. > You comment out some code, thereby deleting the only/last use of > some import, that nets you warnings about unused imports. Granted, > they are "only" warnings, but I try to have none. Also granted, you > can either comment out or just go ahead and remove the imports, easy. > > It might be nice if the IMPORTS could be adjacent to the code using > the IMPORTS, so that they can be comment out or removed together. > > This "problem" is not unique to Modula-3, by far. > In fact, Modula-3 is probably more able to warn about this low cost > waste due to its much better module system, compared to say, C and C > ++ #includes.. From hosking at cs.purdue.edu Mon Feb 11 17:41:24 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 11 Feb 2008 11:41:24 -0500 Subject: [M3devel] external in module? In-Reply-To: <20080211160240.dinb09tktcg44gcs@mail.elegosoft.com> References: <20080211142730.E6B3A10D4655@birch.elegosoft.com> <20080211160240.dinb09tktcg44gcs@mail.elegosoft.com> Message-ID: Please -- no hierarchical namespaces. Ultimately, they need a definitive hierarchy anyway. On Feb 11, 2008, at 10:02 AM, Olaf Wagner wrote: > Quoting Jay : > >> It'd be nice if I could declare externals in modules. >> In this example, setitimer_ only exists for the wrapper >> implementation. >> I don't need it to be visible outside the one module that uses it. >> I guess I could push it into an unexposed interface, even >> dedicate "internal.i3" to it?Is that an ok idiom? > > Yes, use an internal interface of the package. But you should use > another name (something longer and more unique), since the CM3 > builder still has problems with multiple defined units AFAIK. > > This is something that should really be fixed, but that's another > topic. (We'd need hierarchical name spaces, but introduce them in > a compatible way.) > > Olaf > >> It's another problem that I don't know what to call these things.. > > This usually is _my_ problem :-) > -- > Olaf Wagner -- elego Software Solutions GmbH > 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 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > From hendrik at topoi.pooq.com Mon Feb 11 17:42:00 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 11 Feb 2008 11:42:00 -0500 Subject: [M3devel] __declspec(dllimport)? In-Reply-To: <34257B37-565F-4ACE-9939-04CCBDE34D1E@cs.purdue.edu> References: <34257B37-565F-4ACE-9939-04CCBDE34D1E@cs.purdue.edu> Message-ID: <20080211164200.GB20791@topoi.pooq.com> On Mon, Feb 11, 2008 at 11:23:47AM -0500, Tony Hosking wrote: > Do we know that this actually results in any real performance > improvement. Not clear -- hardware is getting pretty clever at doing at run-time the things that compilers used to sweat blood doing at compile time. I suspect that with fetch-and-branch-predictiong processors, the difference may unmeasurable. -- hendrik From hendrik at topoi.pooq.com Mon Feb 11 17:50:54 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 11 Feb 2008 11:50:54 -0500 Subject: [M3devel] imports anywhere? In-Reply-To: References: <20080211111256.22C8E10D4628@birch.elegosoft.com> Message-ID: <20080211165054.GC20791@topoi.pooq.com> On Mon, Feb 11, 2008 at 11:40:11AM -0500, Tony Hosking wrote: > I hate imports that are scattered throughout since it hides > dependencies deep in the guts of the code. Much better to have them > explicit at the top! > > On Feb 11, 2008, at 7:48 AM, Jay wrote: > > >Here is another SMALL gripe with the language. > >The need to put IMPORTS at the top (or is it just common style?), > >leads to something I have seen several times. > >You comment out some code, thereby deleting the only/last use of > >some import, that nets you warnings about unused imports. Granted, > >they are "only" warnings, but I try to have none. Also granted, you > >can either comment out or just go ahead and remove the imports, easy. > > > >It might be nice if the IMPORTS could be adjacent to the code using > >the IMPORTS, so that they can be comment out or removed together. > > > >This "problem" is not unique to Modula-3, by far. > >In fact, Modula-3 is probably more able to warn about this low cost > >waste due to its much better module system, compared to say, C and C > >++ #includes.. > I don't know if this is still the case, but long long ago, when I was reading the OS/2 port of Modula 3, there seemed to be an early phase that determined which source files had to be compiled. It could determine this from just the beginnings of the source files, and did not have to do full-scale Modula 3 parsing. I thought it a clever engineering trick. -- hendrik From rcoleburn at scires.com Mon Feb 11 17:58:15 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Mon, 11 Feb 2008 11:58:15 -0500 Subject: [M3devel] what processors anyone cares about? In-Reply-To: References: <20080211091341.D290C10D4527@birch.elegosoft.com> Message-ID: <47B03853.1E75.00D7.1@scires.com> Jay: Not sure exactly what you are doing and how my answer will impact what you are doing, but here is my 2 cents. If there is stuff out there to deal with these old computers, we shouldn't remove it just because they are old. I still have Modula-3 code that is running on old computers. Indeed, the government tends to have some interesting requirements to keep alive certain systems that use old technology. I have delivered many systems over the course of my career whose actual lifetime was much longer than what anyone projected in the beginning. If we remove support for the old stuff, then we shoot ourselves in the foot for any type of support on these old systems. Indeed, I've recently been approached about making some changes to a system that I first developed back in the late 1990's. It is still around and working. One of the system components has been upgraded and they want me to make software changes to let the Modula-3 code work with the new component. This software controls and monitors satellite radio communications systems. Regards, Randy >>> Jay 2/11/2008 4:35 AM >>> ps: I will point out that NT 3.1 doesn't have have good compatibility with things like VMware or Virtual PC (or vice versa), not sure it will even run on modern hardware (the problem is probably these virtual machines exposing too much?) also what processors do people care about? 386? 486? Pentium I? (Pentium's with the FDIV bug? I still see remnants of the workaround for that..) The newer processors have some nice seeming instructions. Like read timestamp counter, interlocked compare exchange 64, interlocked increment/decrement (on circa 386, those Win32 functions don't return the new value, only <0, 0, or >0), conditional mov, etc. And there is MMX, XMM (SSE?), SSE2/3/4..the instruction set advances don't seem to ever stop.. Nice thing about AMD64 is it establishes a new baseline. I can't claim to have done any profiling with or without these instructions used.. nor that the integrated backend will ever advance in these areas.. - Jay From: jayk123 at hotmail.com To: m3devel at elegosoft.com Date: Mon, 11 Feb 2008 09:15:50 +0000 Subject: [M3devel] FW: [M3commit] CVS Update: cm3 Aren't we better off with more VAR parameters and fewer UNTRACED REFs? That way more interfaces/modules can be "safe", as this one changed? (Does anyone care about NT 3.1 or, gasp, Win32s compat? :) ) (Maybe a "DJGPP" target will satisfy? :) ) - Jay > Date: Mon, 11 Feb 2008 10:13:41 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 08/02/11 10:13:41 > > Modified files: > cm3/m3-libs/m3core/src/time/WIN32/: Time.m3 > cm3/m3-libs/m3core/src/win32/: WinBase.i3 > > Log message: > at the expense of NT 3.1 compatibility use GetSystemTimeAsFileTime > instead of GetSystemTime + SystemTimeToFileTime > Need to know the score, the latest news, or you need your Hotmail*-get your "fix". Check it out. ( http://www.msnmobilefix.com/Default.aspx ) Climb to the top of the charts! Play the word scramble challenge with star power. Play now! ( http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan ) -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Feb 11 17:59:40 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 11 Feb 2008 11:59:40 -0500 Subject: [M3devel] __declspec(dllimport)? In-Reply-To: <20080211164200.GB20791@topoi.pooq.com> References: <34257B37-565F-4ACE-9939-04CCBDE34D1E@cs.purdue.edu> <20080211164200.GB20791@topoi.pooq.com> Message-ID: <3DF581F4-F781-4A0E-8EC7-8D722A91A474@cs.purdue.edu> My thoughts exactly. Let's not expend effort for no gain! On Feb 11, 2008, at 11:42 AM, hendrik at topoi.pooq.com wrote: > On Mon, Feb 11, 2008 at 11:23:47AM -0500, Tony Hosking wrote: >> Do we know that this actually results in any real performance >> improvement. > > Not clear -- hardware is getting pretty clever at doing at run-time > the > things that compilers used to sweat blood doing at compile time. I > suspect that with fetch-and-branch-predictiong processors, the > difference may > unmeasurable. > > -- hendrik From wagner at elegosoft.com Mon Feb 11 18:19:59 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 11 Feb 2008 18:19:59 +0100 Subject: [M3devel] external in module? In-Reply-To: References: <20080211142730.E6B3A10D4655@birch.elegosoft.com> <20080211160240.dinb09tktcg44gcs@mail.elegosoft.com> Message-ID: <20080211181959.c6l6imuzuokcos8o@mail.elegosoft.com> Quoting Tony Hosking : > Please -- no hierarchical namespaces. Ultimately, they need a > definitive hierarchy anyway. I wasn't going to write the code, so no need to worry. However, if this is not the solution we aim at, then we need to do something else about the increasing probability of the builder failing because some module in a completely different package which I don't even use directly happens to have the same name as my internal module and thus cannot be compiled. Or even worse: if I use two packages that happen to contain one module of the same name and have never been used together before. Olaf PS: This reminds me of Leslie Lamports definition of distributed computing: when a computer you didn't even know existed can render your own computer unusable :) > On Feb 11, 2008, at 10:02 AM, Olaf Wagner wrote: > >> Quoting Jay : >> >>> It'd be nice if I could declare externals in modules. >>> In this example, setitimer_ only exists for the wrapper implementation. >>> I don't need it to be visible outside the one module that uses it. >>> I guess I could push it into an unexposed interface, even dedicate >>> "internal.i3" to it?Is that an ok idiom? >> >> Yes, use an internal interface of the package. But you should use >> another name (something longer and more unique), since the CM3 >> builder still has problems with multiple defined units AFAIK. >> >> This is something that should really be fixed, but that's another >> topic. (We'd need hierarchical name spaces, but introduce them in >> a compatible way.) >> >> Olaf >> >>> It's another problem that I don't know what to call these things.. >> >> This usually is _my_ problem :-) >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> 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 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >> -- Olaf Wagner -- elego Software Solutions GmbH 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 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Mon Feb 11 18:52:33 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 11 Feb 2008 12:52:33 -0500 Subject: [M3devel] external in module? In-Reply-To: <20080211181959.c6l6imuzuokcos8o@mail.elegosoft.com> References: <20080211142730.E6B3A10D4655@birch.elegosoft.com> <20080211160240.dinb09tktcg44gcs@mail.elegosoft.com> <20080211181959.c6l6imuzuokcos8o@mail.elegosoft.com> Message-ID: This would be a bigger issue if we had dynamic loading like Java. To some degree, m3makefile imports give us some protection against name clashes. But, I do see your point that a name clash may prevent reuse of separately developed packages. On Feb 11, 2008, at 12:19 PM, Olaf Wagner wrote: > Quoting Tony Hosking : > >> Please -- no hierarchical namespaces. Ultimately, they need a >> definitive hierarchy anyway. > > I wasn't going to write the code, so no need to worry. > However, if this is not the solution we aim at, then we need to > do something else about the increasing probability of the builder > failing because some module in a completely different package > which I don't even use directly happens to have the same name > as my internal module and thus cannot be compiled. Or even worse: > if I use two packages that happen to contain one module of the > same name and have never been used together before. > > Olaf > > PS: This reminds me of Leslie Lamports definition of distributed > computing: when a computer you didn't even know existed > can render your own computer unusable :) > >> On Feb 11, 2008, at 10:02 AM, Olaf Wagner wrote: >> >>> Quoting Jay : >>> >>>> It'd be nice if I could declare externals in modules. >>>> In this example, setitimer_ only exists for the wrapper >>>> implementation. >>>> I don't need it to be visible outside the one module that uses it. >>>> I guess I could push it into an unexposed interface, even >>>> dedicate "internal.i3" to it?Is that an ok idiom? >>> >>> Yes, use an internal interface of the package. But you should use >>> another name (something longer and more unique), since the CM3 >>> builder still has problems with multiple defined units AFAIK. >>> >>> This is something that should really be fixed, but that's another >>> topic. (We'd need hierarchical name spaces, but introduce them in >>> a compatible way.) >>> >>> Olaf >>> >>>> It's another problem that I don't know what to call these things.. >>> >>> This usually is _my_ problem :-) >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> 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 >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >>> Berlin >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>> DE163214194 >>> > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > 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 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > From hendrik at topoi.pooq.com Mon Feb 11 21:06:13 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 11 Feb 2008 15:06:13 -0500 Subject: [M3devel] external in module? In-Reply-To: <20080211181959.c6l6imuzuokcos8o@mail.elegosoft.com> References: <20080211142730.E6B3A10D4655@birch.elegosoft.com> <20080211160240.dinb09tktcg44gcs@mail.elegosoft.com> <20080211181959.c6l6imuzuokcos8o@mail.elegosoft.com> Message-ID: <20080211200613.GA20997@topoi.pooq.com> On Mon, Feb 11, 2008 at 06:19:59PM +0100, Olaf Wagner wrote: > Quoting Tony Hosking : > > >Please -- no hierarchical namespaces. Ultimately, they need a > >definitive hierarchy anyway. > > I wasn't going to write the code, so no need to worry. > However, if this is not the solution we aim at, then we need to > do something else about the increasing probability of the builder > failing because some module in a completely different package > which I don't even use directly happens to have the same name > as my internal module and thus cannot be compiled. Or even worse: > if I use two packages that happen to contain one module of the > same name and have never been used together before. > > Olaf Packages are a lot like modules on a larger scale. Maybe we should be able to syntactically nest modules? And enable modules to export some of their submodules? Or, if the source file gets unwieldy (it will!), use the nesting structure of directories as part of the syntax of the language? Or, for another approach: The various Eiffel implementations have separate module-interconnection language in which they get to collect modules into groups, and indicate some are internal to the group, and also things like <>, or <>. They set this up with programming-language syntax, syntactic nesting, indentation, and so forth. It seems to work, and you don't have to embed everything into an unweildy world-wide, global namespace. But the different implementations seem to have grown their own interconnection languages :-( -- hendrik From jayk123 at hotmail.com Mon Feb 11 22:42:30 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 11 Feb 2008 21:42:30 +0000 Subject: [M3devel] external in module? In-Reply-To: <20080211181959.c6l6imuzuokcos8o@mail.elegosoft.com> References: <20080211142730.E6B3A10D4655@birch.elegosoft.com> <20080211160240.dinb09tktcg44gcs@mail.elegosoft.com> <20080211181959.c6l6imuzuokcos8o@mail.elegosoft.com> Message-ID: Lack of hierarchical namespaces in Modula-3 has long bugged me, but I actually pretty much got over it. So agreed. :) Yes it sounds like the builder, not the language, has a bug. - Jay > Date: Mon, 11 Feb 2008 18:19:59 +0100> From: wagner at elegosoft.com> To: hosking at cs.purdue.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] external in module?> > Quoting Tony Hosking :> > > Please -- no hierarchical namespaces. Ultimately, they need a> > definitive hierarchy anyway.> > I wasn't going to write the code, so no need to worry.> However, if this is not the solution we aim at, then we need to> do something else about the increasing probability of the builder> failing because some module in a completely different package> which I don't even use directly happens to have the same name> as my internal module and thus cannot be compiled. Or even worse:> if I use two packages that happen to contain one module of the> same name and have never been used together before.> > Olaf> > PS: This reminds me of Leslie Lamports definition of distributed> computing: when a computer you didn't even know existed> can render your own computer unusable :)> > > On Feb 11, 2008, at 10:02 AM, Olaf Wagner wrote:> >> >> Quoting Jay :> >>> >>> It'd be nice if I could declare externals in modules.> >>> In this example, setitimer_ only exists for the wrapper implementation.> >>> I don't need it to be visible outside the one module that uses it.> >>> I guess I could push it into an unexposed interface, even dedicate > >>> "internal.i3" to it?Is that an ok idiom?> >>> >> Yes, use an internal interface of the package. But you should use> >> another name (something longer and more unique), since the CM3> >> builder still has problems with multiple defined units AFAIK.> >>> >> This is something that should really be fixed, but that's another> >> topic. (We'd need hierarchical name spaces, but introduce them in> >> a compatible way.)> >>> >> Olaf> >>> >>> It's another problem that I don't know what to call these things..> >>> >> This usually is _my_ problem :-)> >> -- > >> Olaf Wagner -- elego Software Solutions GmbH> >> 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> >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> >>> > > > -- > Olaf Wagner -- elego Software Solutions GmbH> 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> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Feb 11 22:44:18 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 11 Feb 2008 21:44:18 +0000 Subject: [M3devel] __declspec(dllimport)? In-Reply-To: <3DF581F4-F781-4A0E-8EC7-8D722A91A474@cs.purdue.edu> References: <34257B37-565F-4ACE-9939-04CCBDE34D1E@cs.purdue.edu> <20080211164200.GB20791@topoi.pooq.com> <3DF581F4-F781-4A0E-8EC7-8D722A91A474@cs.purdue.edu> Message-ID: Smaller code is good, reduce memory pressure, processor speed ups hardly can fight memory use.. - Jay > From: hosking at cs.purdue.edu> Date: Mon, 11 Feb 2008 11:59:40 -0500> To: hendrik at topoi.pooq.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] __declspec(dllimport)?> > My thoughts exactly. Let's not expend effort for no gain!> > On Feb 11, 2008, at 11:42 AM, hendrik at topoi.pooq.com wrote:> > > On Mon, Feb 11, 2008 at 11:23:47AM -0500, Tony Hosking wrote:> >> Do we know that this actually results in any real performance> >> improvement.> >> > Not clear -- hardware is getting pretty clever at doing at run-time > > the> > things that compilers used to sweat blood doing at compile time. I> > suspect that with fetch-and-branch-predictiong processors, the> > difference may> > unmeasurable.> >> > -- hendrik> _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Feb 11 22:51:10 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 11 Feb 2008 21:51:10 +0000 Subject: [M3devel] size_t? In-Reply-To: <5ED85017-467B-4269-903A-AC512E78DF50@cs.purdue.edu> References: <20080211092401.1068410D466B@birch.elegosoft.com> <1202725259.8543.22.camel@faramir.m3w.org> <5ED85017-467B-4269-903A-AC512E78DF50@cs.purdue.edu> Message-ID: > These are OS-dependent! They should not be in BasicCtypes. 1) There is no Utypes on Windows. These are very basic types that belong at a very low level. In C++ for example, size_t is provided "automatically" by the compiler, no header is needed. 2) Are they really OS dependent? What OS makes my definitions wrong? On what 32 bit architecture is size_t not an unsigned 32 bit integer and ptrdiff_t not a signed 32 bit integer? Ditto for 64 bit. These should always be the same size as a pointer and with the proper signedness. Even if some of the *.i3 files make size_t = int, is that really correct? And, I assume int vs. long issue is not an issue here. Though they may be different types in C and C++, they need not be in Modula-3 (when they are the same size, of course) - Jay > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: [M3devel] size_t?> Date: Mon, 11 Feb 2008 11:38:48 -0500> To: jayk123 at hotmail.com> > > On Feb 11, 2008, at 6:23 AM, Jay wrote:> > > C:\dev2\cm3.2\m3-libs\m3core\src\C\Common\Cstddef.i3(12): size_t = > > INTEGER;> >> > really? it is signed?> > and we are sure this is going to be 64 bits on 64 bit targets?> >> > size_t and ptrdiff_t ought to be in BasicCtypes, right?> > That has a 32 bit and 64 bit version, at least.> > These are OS-dependent! They should not be in BasicCtypes.> > >> >> > Does INTEGER effectively equal int or ptrdiff_t?> >> > - Jay _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Feb 11 22:52:06 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 11 Feb 2008 21:52:06 +0000 Subject: [M3devel] __declspec(dllimport)? In-Reply-To: References: <34257B37-565F-4ACE-9939-04CCBDE34D1E@cs.purdue.edu> <20080211164200.GB20791@topoi.pooq.com> <3DF581F4-F781-4A0E-8EC7-8D722A91A474@cs.purdue.edu> Message-ID: I guess I should switch the default calling convention and see what the code size difference is. - Jay From: jayk123 at hotmail.comTo: hosking at cs.purdue.edu; hendrik at topoi.pooq.comDate: Mon, 11 Feb 2008 21:44:18 +0000CC: m3devel at elegosoft.comSubject: Re: [M3devel] __declspec(dllimport)? Smaller code is good, reduce memory pressure, processor speed ups hardly can fight memory use.. - Jay > From: hosking at cs.purdue.edu> Date: Mon, 11 Feb 2008 11:59:40 -0500> To: hendrik at topoi.pooq.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] __declspec(dllimport)?> > My thoughts exactly. Let's not expend effort for no gain!> > On Feb 11, 2008, at 11:42 AM, hendrik at topoi.pooq.com wrote:> > > On Mon, Feb 11, 2008 at 11:23:47AM -0500, Tony Hosking wrote:> >> Do we know that this actually results in any real performance> >> improvement.> >> > Not clear -- hardware is getting pretty clever at doing at run-time > > the> > things that compilers used to sweat blood doing at compile time. I> > suspect that with fetch-and-branch-predictiong processors, the> > difference may> > unmeasurable.> >> > -- hendrik> Shed those extra pounds with MSN and The Biggest Loser! Learn more. _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Feb 11 22:56:55 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 11 Feb 2008 21:56:55 +0000 Subject: [M3devel] introducing VAR in more places? In-Reply-To: <400989C4-C086-4F4C-866C-A83F8854B34F@cs.purdue.edu> References: <20080211092401.1068410D466B@birch.elegosoft.com> <400989C4-C086-4F4C-866C-A83F8854B34F@cs.purdue.edu> Message-ID: If you want a precise scope in C++, just but in an opening brace. Just like how in Modula-3 (now I know) you can have "BEGIN" almost anywhere, in C++ you can have an open brace almost anywhere. Ditto in C. It isn't often used though, granted. - Jay > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: [M3devel] introducing VAR in more places?> Date: Mon, 11 Feb 2008 11:34:54 -0500> To: jayk123 at hotmail.com> > You can, except you need to explicitly give the block scope:> > VAR ...> BEGIN> ...> END;> > I find this much better than C++ where the scope of the new variable > is imprecisely defined.> > On Feb 11, 2008, at 4:29 AM, Jay wrote:> > > Does anyone else find it bothersome that you can't introduce VARs > > anywhere? Kind of like in C++?> > Ok, or if you grant that frame size doesn't matter THAT much, and > > the compiler might do stack packing anyway, you can move all your > > locals up top like typical C, but still, how about for the module > > initializer?> > Still it seems good to me to do manual stack packing since it is > > often so easy..> > WITH helps, but only for "relative constants".> >> > It would be nice if the code below could have still loops until t0 ! > > = t1, but the repeat condition is outside the scope in which t1 is > > available. This feels quite lame..> >> > - Jay> >> >> >> > > Date: Mon, 11 Feb 2008 10:24:00 +0000> > > To: m3commit at elegosoft.com> > > From: jkrell at elego.de> > > Subject: [M3commit] CVS Update: cm3> > >> > > CVSROOT: /usr/cvs> > > Changes by: jkrell at birch. 08/02/11 10:24:00> > >> > > Modified files:> > > cm3/m3-libs/m3core/src/time/WIN32/: Time.m3> > >> > > Log message:> > > no need for globals here..> > >> >> >> > Helping your favorite cause is as easy as instant messaging. You > > IM, we give. Learn more.> _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Mon Feb 11 22:33:20 2008 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Mon, 11 Feb 2008 22:33:20 +0100 Subject: [M3devel] external in module? In-Reply-To: References: <20080211142730.E6B3A10D4655@birch.elegosoft.com> <20080211160240.dinb09tktcg44gcs@mail.elegosoft.com> <20080211181959.c6l6imuzuokcos8o@mail.elegosoft.com> Message-ID: <1202765600.8543.32.camel@faramir.m3w.org> But... We DO HAVE dynamic loading, and it's not altogether unlike Java :). Did these patches of mine made to CM3 HEAD? dd On Mon, 2008-02-11 at 12:52 -0500, Tony Hosking wrote: > This would be a bigger issue if we had dynamic loading like Java. To > some degree, m3makefile imports give us some protection against name > clashes. But, I do see your point that a name clash may prevent > reuse of separately developed packages. > > On Feb 11, 2008, at 12:19 PM, Olaf Wagner wrote: > > > Quoting Tony Hosking : > > > >> Please -- no hierarchical namespaces. Ultimately, they need a > >> definitive hierarchy anyway. > > > > I wasn't going to write the code, so no need to worry. > > However, if this is not the solution we aim at, then we need to > > do something else about the increasing probability of the builder > > failing because some module in a completely different package > > which I don't even use directly happens to have the same name > > as my internal module and thus cannot be compiled. Or even worse: > > if I use two packages that happen to contain one module of the > > same name and have never been used together before. > > > > Olaf > > > > PS: This reminds me of Leslie Lamports definition of distributed > > computing: when a computer you didn't even know existed > > can render your own computer unusable :) > > > >> On Feb 11, 2008, at 10:02 AM, Olaf Wagner wrote: > >> > >>> Quoting Jay : > >>> > >>>> It'd be nice if I could declare externals in modules. > >>>> In this example, setitimer_ only exists for the wrapper > >>>> implementation. > >>>> I don't need it to be visible outside the one module that uses it. > >>>> I guess I could push it into an unexposed interface, even > >>>> dedicate "internal.i3" to it?Is that an ok idiom? > >>> > >>> Yes, use an internal interface of the package. But you should use > >>> another name (something longer and more unique), since the CM3 > >>> builder still has problems with multiple defined units AFAIK. > >>> > >>> This is something that should really be fixed, but that's another > >>> topic. (We'd need hierarchical name spaces, but introduce them in > >>> a compatible way.) > >>> > >>> Olaf > >>> > >>>> It's another problem that I don't know what to call these things.. > >>> > >>> This usually is _my_ problem :-) > >>> -- > >>> Olaf Wagner -- elego Software Solutions GmbH > >>> 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 > >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > >>> Berlin > >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > >>> DE163214194 > >>> > > > > > > > > -- > > Olaf Wagner -- elego Software Solutions GmbH > > 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 > > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > > Berlin > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > > DE163214194 > > > -- Dragi?a Duri? From jayk123 at hotmail.com Mon Feb 11 23:03:22 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 11 Feb 2008 22:03:22 +0000 Subject: [M3devel] <*external winapi*> silently ignored on all platforms? In-Reply-To: References: Message-ID: That's also a good idea too. Though I think maybe safer to say: <*NT386:callingconvention push*><*NT386:callingconvention winapi*> ..bunch of decls .. <*NT386:callingconvention pop*> > way, all EXTERNALs will look the same but you won't clutter up non- > Win32 with ugly WINAPI. Tony, is /everything/ Win32 ugly? :) The status of SQLHWND is less clear to me now, seems I have trouble with the basic find-in-files.. Even so -- it used like once, its type is almost the same, the Windef definition is now available, the headers are almost the same. I did notice the Win32 headers actually #ifdef: #if defined(WIN32) || defined(OS2)typedef HWND SQLHWND;#elif defined (UNIX)typedef Widget SQLHWND;#else/* placehold for future O/S GUI window handle definition */typedef SQLPOINTER SQLHWND;#endif Might be nice to have a limited form of #if in Modula-3. I understand -- don't want to have to parse headers over and over. Maybe only if on TARGET and nothing else? Slippery slope. So far ODBC is the main place I've seen this and I'm just about over it. The status of OpenGL here isn't clear, seems maybe the opposite -- __stdcall on NT386, __cdecl on NT386GNU. - Jay > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: [M3devel] <*external winapi*> silently ignored on all platforms?> Date: Mon, 11 Feb 2008 11:26:50 -0500> To: jayk123 at hotmail.com> > Why not simply default EXTERNAL on Win32 to WINAPI instead? That > way, all EXTERNALs will look the same but you won't clutter up non- > Win32 with ugly WINAPI.> > On Feb 11, 2008, at 5:13 AM, Jay wrote:> > > I know this won't be popular but...> >> > over in m3-db\odbc\src, there is POSIX and WIN32, and they are > > ALMOST identical.> >> > The differences are> >> > the UNUSED type SQLHWND is ADDRESS or HWND> > This should just be removed.> >> > In Win32 all the <*external*> pragmas have WINAPI.> > In Posix, they lack it.> >> > For this and other reasons, I suggest that all CM3 frontends accept > > but silently> > ignore the Win32/x86 calling conventions in <*external*> pragmas,> > similar to what the non-x86 Windows compilers do.> >> > The other reasons would be the "FARPROC" warning that I already > > cleared up otherwise.> >> > And anything else minor that comes up.> >> > I know this won't be popular but I REALLY REALLY REALLY believe is > > the right thing.> > It is a small safe change that will allow a little more Modula-3 > > source portability.> >> > A similar suggestion would be to change the default calling > > convention in Modula-3,> > it would very possibly reduce code size, but is very very very much > > a breaking> > change so probably can never happen.> > Better probably would be to a) add a switch for this b) extend > > the .m3exports> > or whatnot files to indicate what switch was used.> >> > A "blanket pragma" might also be good, so that the various *.i3 > > files can> > say just to assume __stdcall for the rest of the file instead of > > annotating each functions.> >> > - Jay> >> >> > Need to know the score, the latest news, or you need your Hotmail?- > > get your "fix". Check it out.> _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Feb 11 23:04:10 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 11 Feb 2008 17:04:10 -0500 Subject: [M3devel] size_t? In-Reply-To: References: <20080211092401.1068410D466B@birch.elegosoft.com> <1202725259.8543.22.camel@faramir.m3w.org> <5ED85017-467B-4269-903A-AC512E78DF50@cs.purdue.edu> Message-ID: <9C682AFA-0D4C-486C-B51C-629AF426344A@cs.purdue.edu> Sorry. They belong in Cstddef.i3. size_t is already there. Let's try to stick to the C ".h" structure. size_t = INTEGER. On Feb 11, 2008, at 4:51 PM, Jay wrote: > > These are OS-dependent! They should not be in BasicCtypes. > > 1) There is no Utypes on Windows. > These are very basic types that belong at a very low level. > In C++ for example, size_t is provided "automatically" by the > compiler, no header is needed. > > 2) Are they really OS dependent? What OS makes my definitions wrong? > On what 32 bit architecture is size_t not an unsigned 32 bit > integer and ptrdiff_t not a signed 32 bit integer? > Ditto for 64 bit. > These should always be the same size as a pointer and with the > proper signedness. > Even if some of the *.i3 files make size_t = int, is that really > correct? > And, I assume int vs. long issue is not an issue here. > Though they may be different types in C and C++, they need not be > in Modula-3 (when they are the same size, of course) > > - Jay > > > > > CC: m3devel at elegosoft.com > > From: hosking at cs.purdue.edu > > Subject: Re: [M3devel] size_t? > > Date: Mon, 11 Feb 2008 11:38:48 -0500 > > To: jayk123 at hotmail.com > > > > > > On Feb 11, 2008, at 6:23 AM, Jay wrote: > > > > > C:\dev2\cm3.2\m3-libs\m3core\src\C\Common\Cstddef.i3(12): size_t = > > > INTEGER; > > > > > > really? it is signed? > > > and we are sure this is going to be 64 bits on 64 bit targets? > > > > > > size_t and ptrdiff_t ought to be in BasicCtypes, right? > > > That has a 32 bit and 64 bit version, at least. > > > > These are OS-dependent! They should not be in BasicCtypes. > > > > > > > > > > > Does INTEGER effectively equal int or ptrdiff_t? > > > > > > - Jay > > Need to know the score, the latest news, or you need your Hotmail?- > get your "fix". Check it out. From jayk123 at hotmail.com Mon Feb 11 23:34:27 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 11 Feb 2008 22:34:27 +0000 Subject: [M3devel] size_t? In-Reply-To: <9C682AFA-0D4C-486C-B51C-629AF426344A@cs.purdue.edu> References: <20080211092401.1068410D466B@birch.elegosoft.com> <1202725259.8543.22.camel@faramir.m3w.org> <5ED85017-467B-4269-903A-AC512E78DF50@cs.purdue.edu> <9C682AFA-0D4C-486C-B51C-629AF426344A@cs.purdue.edu> Message-ID: I did later notice size_t was there. I think what I earlier noticed was ptrdiff_t nowhere. > size_t = INTEGER. But unsigned presumably? What I had was correct, right? In C++ no header is needed for size_t, it is just so basic and widespread. Not sure about ptrdiff_t. Either way, they both do live in that middle ground between compiler and library -- a very low level -- as size_t is defined as the type of sizeof() expressions and ptrdiff_t is defined as the type you get when you subtract pointers. And you don't need nay header to use sizeof() or subtract pointers. If it were really up to me, I'd have the Modula-3 language predefine all of int8, uint8, int16, uint16, int32, uint32, int64, uint64, size_t, ptrdiff_t, and maybe char and wchar_t and INTEGER. There is a corralary dilemna here that I haven't figured out, and have seen code address that I haven't adjusted to yet. That is, the code uses uint32 "everywhere", instead of something "more abstract/vague". When it comes down to it, I suspect this is the right thing. The abstraction only seems to buy problems. UNLESS you have a processor with a larger natural integer that performs poorly on smaller integers, or a processor that perfs badly with 32 bit integers. Perhaps Modula-3 has solved it ok, in that INTEGER == ptrdiff_t. In many and growing systems, "int", besides its signedness, is too small for many occurences. That is the problem I think in C. If Modula-3 has essentially defined INTEGER to be the size of a pointer, then ok. - Jay > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: [M3devel] size_t?> Date: Mon, 11 Feb 2008 17:04:10 -0500> To: jayk123 at hotmail.com> > Sorry.> > They belong in Cstddef.i3. size_t is already there. Let's try to > stick to the C ".h" structure.> > size_t = INTEGER.> > On Feb 11, 2008, at 4:51 PM, Jay wrote:> > > > These are OS-dependent! They should not be in BasicCtypes.> >> > 1) There is no Utypes on Windows.> > These are very basic types that belong at a very low level.> > In C++ for example, size_t is provided "automatically" by the > > compiler, no header is needed.> >> > 2) Are they really OS dependent? What OS makes my definitions wrong?> > On what 32 bit architecture is size_t not an unsigned 32 bit > > integer and ptrdiff_t not a signed 32 bit integer?> > Ditto for 64 bit.> > These should always be the same size as a pointer and with the > > proper signedness.> > Even if some of the *.i3 files make size_t = int, is that really > > correct?> > And, I assume int vs. long issue is not an issue here.> > Though they may be different types in C and C++, they need not be > > in Modula-3 (when they are the same size, of course)> >> > - Jay> >> >> >> > > CC: m3devel at elegosoft.com> > > From: hosking at cs.purdue.edu> > > Subject: Re: [M3devel] size_t?> > > Date: Mon, 11 Feb 2008 11:38:48 -0500> > > To: jayk123 at hotmail.com> > >> > >> > > On Feb 11, 2008, at 6:23 AM, Jay wrote:> > >> > > > C:\dev2\cm3.2\m3-libs\m3core\src\C\Common\Cstddef.i3(12): size_t => > > > INTEGER;> > > >> > > > really? it is signed?> > > > and we are sure this is going to be 64 bits on 64 bit targets?> > > >> > > > size_t and ptrdiff_t ought to be in BasicCtypes, right?> > > > That has a 32 bit and 64 bit version, at least.> > >> > > These are OS-dependent! They should not be in BasicCtypes.> > >> > > >> > > >> > > > Does INTEGER effectively equal int or ptrdiff_t?> > > >> > > > - Jay> >> > Need to know the score, the latest news, or you need your Hotmail?- > > get your "fix". Check it out.> _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Feb 11 23:40:44 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 11 Feb 2008 17:40:44 -0500 Subject: [M3devel] external in module? In-Reply-To: <1202765600.8543.32.camel@faramir.m3w.org> References: <20080211142730.E6B3A10D4655@birch.elegosoft.com> <20080211160240.dinb09tktcg44gcs@mail.elegosoft.com> <20080211181959.c6l6imuzuokcos8o@mail.elegosoft.com> <1202765600.8543.32.camel@faramir.m3w.org> Message-ID: Not sure... On Feb 11, 2008, at 4:33 PM, Dragi?a Duri? wrote: > But... We DO HAVE dynamic loading, and it's not altogether unlike > Java :). > > Did these patches of mine made to CM3 HEAD? > > dd > > On Mon, 2008-02-11 at 12:52 -0500, Tony Hosking wrote: >> This would be a bigger issue if we had dynamic loading like Java. To >> some degree, m3makefile imports give us some protection against name >> clashes. But, I do see your point that a name clash may prevent >> reuse of separately developed packages. >> >> On Feb 11, 2008, at 12:19 PM, Olaf Wagner wrote: >> >>> Quoting Tony Hosking : >>> >>>> Please -- no hierarchical namespaces. Ultimately, they need a >>>> definitive hierarchy anyway. >>> >>> I wasn't going to write the code, so no need to worry. >>> However, if this is not the solution we aim at, then we need to >>> do something else about the increasing probability of the builder >>> failing because some module in a completely different package >>> which I don't even use directly happens to have the same name >>> as my internal module and thus cannot be compiled. Or even worse: >>> if I use two packages that happen to contain one module of the >>> same name and have never been used together before. >>> >>> Olaf >>> >>> PS: This reminds me of Leslie Lamports definition of distributed >>> computing: when a computer you didn't even know existed >>> can render your own computer unusable :) >>> >>>> On Feb 11, 2008, at 10:02 AM, Olaf Wagner wrote: >>>> >>>>> Quoting Jay : >>>>> >>>>>> It'd be nice if I could declare externals in modules. >>>>>> In this example, setitimer_ only exists for the wrapper >>>>>> implementation. >>>>>> I don't need it to be visible outside the one module that uses >>>>>> it. >>>>>> I guess I could push it into an unexposed interface, even >>>>>> dedicate "internal.i3" to it?Is that an ok idiom? >>>>> >>>>> Yes, use an internal interface of the package. But you should use >>>>> another name (something longer and more unique), since the CM3 >>>>> builder still has problems with multiple defined units AFAIK. >>>>> >>>>> This is something that should really be fixed, but that's another >>>>> topic. (We'd need hierarchical name spaces, but introduce them in >>>>> a compatible way.) >>>>> >>>>> Olaf >>>>> >>>>>> It's another problem that I don't know what to call these >>>>>> things.. >>>>> >>>>> This usually is _my_ problem :-) >>>>> -- >>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>> 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 >>>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | >>>>> Sitz: >>>>> Berlin >>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>>>> DE163214194 >>>>> >>> >>> >>> >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> 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 >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: >>> Berlin >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: >>> DE163214194 >>> >> > -- > Dragi?a Duri? From hosking at cs.purdue.edu Tue Feb 12 00:37:56 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 11 Feb 2008 18:37:56 -0500 Subject: [M3devel] size_t? In-Reply-To: References: <20080211092401.1068410D466B@birch.elegosoft.com> <1202725259.8543.22.camel@faramir.m3w.org> <5ED85017-467B-4269-903A-AC512E78DF50@cs.purdue.edu> <9C682AFA-0D4C-486C-B51C-629AF426344A@cs.purdue.edu> Message-ID: <649A7621-D82E-4024-BC45-193892355AC4@cs.purdue.edu> Yes, the ANSI C standard defines size_t and ptrdiff_t in stddef.h. Subtracting two pointers yields ptrdiff_t, so in M3 it would presumably be INTEGER. size_t is what sizeof returns, so I imagine size_t=CARDINAL is probably OK (to match BITSIZE/BYTESIZE/ADRSIZE), but maybe should better be Word.T to match C's unsigned interpretation. Of course, Word.T is simply INTEGER anyway in the current CM3 implementation. Note that neither of these need to be defined in the 32bit/64bit subdirectories since they are straightforwardly the same as the underlying word size. On Feb 11, 2008, at 5:34 PM, Jay wrote: > I did later notice size_t was there. > I think what I earlier noticed was ptrdiff_t nowhere. > > > size_t = INTEGER. > > But unsigned presumably? > > What I had was correct, right? > In C++ no header is needed for size_t, it is just so basic and > widespread. > Not sure about ptrdiff_t. > > Either way, they both do live in that middle ground between > compiler and library -- a very low level -- > as size_t is defined as the type of sizeof() expressions and > ptrdiff_t is defined as the type you get when you subtract > pointers. And you don't need nay header to use sizeof() or subtract > pointers. > > If it were really up to me, I'd have the Modula-3 language > predefine all of int8, uint8, int16, uint16, int32, uint32, int64, > uint64, size_t, ptrdiff_t, and maybe char and wchar_t and INTEGER. > There is a corralary dilemna here that I haven't figured out, and > have seen code address that I haven't adjusted to yet. That is, the > code uses uint32 "everywhere", instead of something "more abstract/ > vague". When it comes down to it, I suspect this is the right > thing. The abstraction only seems to buy problems. UNLESS you have > a processor with a larger natural integer that performs poorly on > smaller integers, or a processor that perfs badly with 32 bit > integers. > > Perhaps Modula-3 has solved it ok, in that INTEGER == ptrdiff_t. > In many and growing systems, "int", besides its signedness, is too > small for many occurences. > That is the problem I think in C. If Modula-3 has essentially > defined INTEGER to be the size of a pointer, then ok. > > - Jay > > > > CC: m3devel at elegosoft.com > > From: hosking at cs.purdue.edu > > Subject: Re: [M3devel] size_t? > > Date: Mon, 11 Feb 2008 17:04:10 -0500 > > To: jayk123 at hotmail.com > > > > Sorry. > > > > They belong in Cstddef.i3. size_t is already there. Let's try to > > stick to the C ".h" structure. > > > > size_t = INTEGER. > > > > On Feb 11, 2008, at 4:51 PM, Jay wrote: > > > > > > These are OS-dependent! They should not be in BasicCtypes. > > > > > > 1) There is no Utypes on Windows. > > > These are very basic types that belong at a very low level. > > > In C++ for example, size_t is provided "automatically" by the > > > compiler, no header is needed. > > > > > > 2) Are they really OS dependent? What OS makes my definitions > wrong? > > > On what 32 bit architecture is size_t not an unsigned 32 bit > > > integer and ptrdiff_t not a signed 32 bit integer? > > > Ditto for 64 bit. > > > These should always be the same size as a pointer and with the > > > proper signedness. > > > Even if some of the *.i3 files make size_t = int, is that really > > > correct? > > > And, I assume int vs. long issue is not an issue here. > > > Though they may be different types in C and C++, they need not be > > > in Modula-3 (when they are the same size, of course) > > > > > > - Jay > > > > > > > > > > > > > CC: m3devel at elegosoft.com > > > > From: hosking at cs.purdue.edu > > > > Subject: Re: [M3devel] size_t? > > > > Date: Mon, 11 Feb 2008 11:38:48 -0500 > > > > To: jayk123 at hotmail.com > > > > > > > > > > > > On Feb 11, 2008, at 6:23 AM, Jay wrote: > > > > > > > > > C:\dev2\cm3.2\m3-libs\m3core\src\C\Common\Cstddef.i3(12): > size_t = > > > > > INTEGER; > > > > > > > > > > really? it is signed? > > > > > and we are sure this is going to be 64 bits on 64 bit targets? > > > > > > > > > > size_t and ptrdiff_t ought to be in BasicCtypes, right? > > > > > That has a 32 bit and 64 bit version, at least. > > > > > > > > These are OS-dependent! They should not be in BasicCtypes. > > > > > > > > > > > > > > > > > > > Does INTEGER effectively equal int or ptrdiff_t? > > > > > > > > > > - Jay > > > > > > Need to know the score, the latest news, or you need your > Hotmail?- > > > get your "fix". Check it out. > > > > > Climb to the top of the charts! Play the word scramble challenge > with star power. Play now! From jayk123 at hotmail.com Tue Feb 12 02:05:39 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 12 Feb 2008 01:05:39 +0000 Subject: [M3devel] size_t? In-Reply-To: <649A7621-D82E-4024-BC45-193892355AC4@cs.purdue.edu> References: <20080211092401.1068410D466B@birch.elegosoft.com> <1202725259.8543.22.camel@faramir.m3w.org> <5ED85017-467B-4269-903A-AC512E78DF50@cs.purdue.edu> <9C682AFA-0D4C-486C-B51C-629AF426344A@cs.purdue.edu> <649A7621-D82E-4024-BC45-193892355AC4@cs.purdue.edu> Message-ID: I think ANSI C is a bit of a mess here. For the most part, no header is defined as #including any other. That is good. Each header exposes certain names and few names are exposed by more than one header. As well, for good measure, your own #includes of ANSI C headers I believe is speced as order-independent. These are all aspects of a "good module system", except this solid foundation is built on a foundation of quicksand and there is inadequate support for it in the language -- i.e. no static enforcement... Anyway.. But there are some symbols, such as size_t, that you can get from multiple headers, directly or indirectly. For example, strlen returns size_t, so #include must define it (directly or indirectly). Malloc takes size_t, so #include must define it (directly or indirectly). fread/fwrite/stdio.h ditto. I don't know if string.h/stdlib.h/stdio.h are speced as exposing all of stddef.h however. IF NOT, then there must be some underlying implementation defined layer, OR the headers have to duplicate the definition. This notion of combining one interface into another wholesale is probably usually a bad idea, but it can also be darn convenient. Just #include everything, and have everything available in the global namespace. The "language" does live in this space. INTEGER is ALWAYS available and always has the same meaning (per-target). I cannot redefine it (again, other than by making a new target). Pushing some things into fewer larger integers is a step in this direction. It breaks "modularity" and so should be done very selectively, but /arguably/ size_t and ptrdiff_t are fundamental enough to warrant such treatment. So I guess my point is that size_t and ptrdiff_t should perhaps be in the language. Or, ok, ptrdiff_t == INTEGER, guaranteed, always and forever, on all targets, no question. So maybe just size_t is missing? I guess maybe it is BITS BITSIZE(INTEGER) FOR 0..LAST(INTEGER) ? Good enough? Really, I'm sure you have all figured out, I want Modula-3 to look more like C. :) The more I use C lately (as opposed to C++) and the more I use Modula-3 lately..the more I find C perfectly ok, the unsafety easy enough to not be bitten by, the more the heap allocations and copying that "safety" cost seem not worth it.. It's an interesting system largely just because it is yet another system, in need (arguably) of more targets, and where "NT386" exists but gets little support. Someone who "likes" Modula-3 more would serve it better than me, perhaps. But I'm here. :) I also like that a decent module system was worked out such as to build fast, at least when using the integrated backend. So maybe I just write all my Modula-3 as "unsafe" and be happy. :) - Jay > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: [M3devel] size_t?> Date: Mon, 11 Feb 2008 18:37:56 -0500> To: jayk123 at hotmail.com> > Yes, the ANSI C standard defines size_t and ptrdiff_t in stddef.h.> > Subtracting two pointers yields ptrdiff_t, so in M3 it would > presumably be INTEGER.> size_t is what sizeof returns, so I imagine size_t=CARDINAL is > probably OK (to match BITSIZE/BYTESIZE/ADRSIZE), but maybe should > better be Word.T to match C's unsigned interpretation. Of course, > Word.T is simply INTEGER anyway in the current CM3 implementation. > Note that neither of these need to be defined in the 32bit/64bit > subdirectories since they are straightforwardly the same as the > underlying word size.> > On Feb 11, 2008, at 5:34 PM, Jay wrote:> > > I did later notice size_t was there.> > I think what I earlier noticed was ptrdiff_t nowhere.> >> > > size_t = INTEGER.> >> > But unsigned presumably?> >> > What I had was correct, right?> > In C++ no header is needed for size_t, it is just so basic and > > widespread.> > Not sure about ptrdiff_t.> >> > Either way, they both do live in that middle ground between > > compiler and library -- a very low level --> > as size_t is defined as the type of sizeof() expressions and > > ptrdiff_t is defined as the type you get when you subtract > > pointers. And you don't need nay header to use sizeof() or subtract > > pointers.> >> > If it were really up to me, I'd have the Modula-3 language > > predefine all of int8, uint8, int16, uint16, int32, uint32, int64, > > uint64, size_t, ptrdiff_t, and maybe char and wchar_t and INTEGER.> > There is a corralary dilemna here that I haven't figured out, and > > have seen code address that I haven't adjusted to yet. That is, the > > code uses uint32 "everywhere", instead of something "more abstract/ > > vague". When it comes down to it, I suspect this is the right > > thing. The abstraction only seems to buy problems. UNLESS you have > > a processor with a larger natural integer that performs poorly on > > smaller integers, or a processor that perfs badly with 32 bit > > integers.> >> > Perhaps Modula-3 has solved it ok, in that INTEGER == ptrdiff_t.> > In many and growing systems, "int", besides its signedness, is too > > small for many occurences.> > That is the problem I think in C. If Modula-3 has essentially > > defined INTEGER to be the size of a pointer, then ok.> >> > - Jay> >> >> > > CC: m3devel at elegosoft.com> > > From: hosking at cs.purdue.edu> > > Subject: Re: [M3devel] size_t?> > > Date: Mon, 11 Feb 2008 17:04:10 -0500> > > To: jayk123 at hotmail.com> > >> > > Sorry.> > >> > > They belong in Cstddef.i3. size_t is already there. Let's try to> > > stick to the C ".h" structure.> > >> > > size_t = INTEGER.> > >> > > On Feb 11, 2008, at 4:51 PM, Jay wrote:> > >> > > > > These are OS-dependent! They should not be in BasicCtypes.> > > >> > > > 1) There is no Utypes on Windows.> > > > These are very basic types that belong at a very low level.> > > > In C++ for example, size_t is provided "automatically" by the> > > > compiler, no header is needed.> > > >> > > > 2) Are they really OS dependent? What OS makes my definitions > > wrong?> > > > On what 32 bit architecture is size_t not an unsigned 32 bit> > > > integer and ptrdiff_t not a signed 32 bit integer?> > > > Ditto for 64 bit.> > > > These should always be the same size as a pointer and with the> > > > proper signedness.> > > > Even if some of the *.i3 files make size_t = int, is that really> > > > correct?> > > > And, I assume int vs. long issue is not an issue here.> > > > Though they may be different types in C and C++, they need not be> > > > in Modula-3 (when they are the same size, of course)> > > >> > > > - Jay> > > >> > > >> > > >> > > > > CC: m3devel at elegosoft.com> > > > > From: hosking at cs.purdue.edu> > > > > Subject: Re: [M3devel] size_t?> > > > > Date: Mon, 11 Feb 2008 11:38:48 -0500> > > > > To: jayk123 at hotmail.com> > > > >> > > > >> > > > > On Feb 11, 2008, at 6:23 AM, Jay wrote:> > > > >> > > > > > C:\dev2\cm3.2\m3-libs\m3core\src\C\Common\Cstddef.i3(12): > > size_t => > > > > > INTEGER;> > > > > >> > > > > > really? it is signed?> > > > > > and we are sure this is going to be 64 bits on 64 bit targets?> > > > > >> > > > > > size_t and ptrdiff_t ought to be in BasicCtypes, right?> > > > > > That has a 32 bit and 64 bit version, at least.> > > > >> > > > > These are OS-dependent! They should not be in BasicCtypes.> > > > >> > > > > >> > > > > >> > > > > > Does INTEGER effectively equal int or ptrdiff_t?> > > > > >> > > > > > - Jay> > > >> > > > Need to know the score, the latest news, or you need your > > Hotmail?-> > > > get your "fix". Check it out.> > >> >> >> > Climb to the top of the charts! Play the word scramble challenge > > with star power. Play now!> _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Feb 12 02:21:24 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 12 Feb 2008 01:21:24 +0000 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <649A7621-D82E-4024-BC45-193892355AC4@cs.purdue.edu> References: <20080211092401.1068410D466B@birch.elegosoft.com> <1202725259.8543.22.camel@faramir.m3w.org> <5ED85017-467B-4269-903A-AC512E78DF50@cs.purdue.edu> <9C682AFA-0D4C-486C-B51C-629AF426344A@cs.purdue.edu> <649A7621-D82E-4024-BC45-193892355AC4@cs.purdue.edu> Message-ID: So I have NOT thought this through. I wonder if "preprocessing" dependent only on "target" is a good idea. Something like either the ability to prefix pragmas with a target, or an "iftarget" and "ifnottarget" pragma. Something like so: <* IF_TARGET NT386 *> <* END_IF_TARGET*> <* IF_TARGET NT386 *> <* END_IF_TARGET*> It's a small can of worms. Where can they be placed? Only at "global" scope? (ie: toplevel in an interface/module). What about IF_OSTYPE? What about expressions? IF_TARGET NT386 OR NTAMD64 IF_TARGET STARTS(NT) etc. I don't really have enough interest here to work through this, just sending out the bait... Obviously this was triggered by my happening into the odbc directory and bringing up ignoring WINAPI on non-NT386 or prefixing calling conventions with a target. This reminds me of an important point here however -- nobody else is going to make the mistake of ever having multiple calling conventions. Therefore the generality of prefixing WINAPI with NT386: is useless. Unless Mac68K support is added. And here is some rationale even. The PC and Mac evolved from "small" systems, where assembly programming was common, more people knew more lower level details and playing games with calling conventions was something anyone could do. Most other current systems are rooted in C programming. Working in C, calling conventions are generally in a hidden layer below what anyone thinks about. Therefore, the smaller number of capable people working at that level have the good sense to only have one calling convention. No more systems will evolve from "small", at least not without having observed this history. Therefore, there will no longer be multiple calling conventions. That is my theory at least. Oh, Windows does also have __thiscall and __clrcall. __thiscall is only x86. __clrcall sort of doesn't count. It really must means "managed code", using the only calling convention available. - Jay _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From darko at darko.org Tue Feb 12 02:29:12 2008 From: darko at darko.org (Darko) Date: Tue, 12 Feb 2008 12:29:12 +1100 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <47AF72B5.2080308@wichita.edu> References: <47AF72B5.2080308@wichita.edu> Message-ID: The liberalised alignment rules are required for the native Mac OS X API and should stay. You cannot use that API without them. I think the pragma is not required and can be removed. I agree with all the points you make. The effect of the modified alignment rules it to allow *packed* structures to have members aligned on byte boundaries. This has the effect of packing the fields in the tightest arrangement allowed by the platform. This might affect performance, but if the user is concerned about this they should specify field bit sizes that deliver improved performance. I don't see a need to specify this on a structure level, for the reasons you give and because the difference isn't significant enough in the case of packed structures and their physical layout and restrictions are platform dependent anyway. I might also add that the alignment code is currently broken on I386_DARWIN. - Darko On 11/02/2008, at 8:55 AM, Rodney M. Bates wrote: > Does anybody know about the status of pragma <*LAZYALIGN*>? Is it > being used anywhere? > > It is not documented in pragmas.html. The compiler front end appears > to accept it. (In fact, Decls.m3 contains constants that suggest > limitations on what declarations the pragma can appear on, but these > are not actually enforced.) It liberalizes the alignment rules, > generally allowing scalars to start on any byte boundary. > > Pickles have to be able to reconstruct the layout of types as the > compiler would have done it for a machine (on which a now-being-read > pickle was written) with different word size and alignment properties. > Currently, pickles are completely unaware of lazy alignment. It > would have to be encoded in type descriptions generated by the > compiler > using TipeDesc and read by pickles using RTTipe. > > Most troubling to me is what looks like a linguistic Pandora's box. > The pragma can be associated with any constant, variable, or type > _declaration_ (not type definition), with the result that different > values of the same type can actually be different in their alignment > rules and thus their layout. Similarly for different identifiers > equated to the same type. Although the effects of this could possibly > be hidden from the programmer in purely safe code, not so with unsafe > code. I haven't thoroughly thought this through, but seems to me to > really fly in the face of the whole typing philosophy of the language. > > For example, if pickles were to read in an object value, and there > were >1 variants of the object's type in the reading program, > differing > only in the alignment rules, how would it decide which one to build? > In fact, ignoring pickles altogether and just looking at a single > program, > if the object's type doesn't actually uniquely give its memory layout, > how can it be accessed correctly? > > Additionally, a quick look at the compiler suggests it won't generate > correct code for whole record assignment when the LHS and RHS are the > same type but have different alignment characteristics. > > The more I think about it, it seems the only workable possibilities > are: > > 1) Require the pragma to be associated only with a type _definition_ > not a > declaration (e.g., allow RECORD <*LAZYALIGN*> ... END) and make > this a > property of the type that propagates to all names for the type and > all variables, constants, etc. Also, this would make this property > a part of the type signature that pickles uses when reading, -OR- > > 2) Forget it altogether. > > What do people think? > -- > ------------------------------------------------------------- > Rodney M. Bates, retired assistant professor > Dept. of Computer Science, Wichita State University > Wichita, KS 67260-0083 > 316-978-3922 > rodney.bates at wichita.edu From darko at darko.org Tue Feb 12 02:37:49 2008 From: darko at darko.org (Darko) Date: Tue, 12 Feb 2008 12:37:49 +1100 Subject: [M3devel] "target specific pragmas"? In-Reply-To: References: <20080211092401.1068410D466B@birch.elegosoft.com> <1202725259.8543.22.camel@faramir.m3w.org> <5ED85017-467B-4269-903A-AC512E78DF50@cs.purdue.edu> <9C682AFA-0D4C-486C-B51C-629AF426344A@cs.purdue.edu> <649A7621-D82E-4024-BC45-193892355AC4@cs.purdue.edu> Message-ID: <48FBBB48-71D5-44CD-9A7C-BF6389A7B07F@darko.org> I think it's not a good idea. I think all platform specific code should be in a separate file. I'd also like to see an option to move calling conventions to the makefile rather than in pramas to avoid having to duplicate interface files just to have a different calling convention for a different platform. - Darko On 12/02/2008, at 12:21 PM, Jay wrote: > So I have NOT thought this through. > > I wonder if "preprocessing" dependent only on "target" is a good idea. > > Something like either the ability to prefix pragmas with a target, > or an "iftarget" and "ifnottarget" pragma. > > Something like so: > > <* IF_TARGET NT386 *> > <* END_IF_TARGET*> > > > <* IF_TARGET NT386 *> > <* END_IF_TARGET*> > It's a small can of worms. > Where can they be placed? Only at "global" scope? (ie: toplevel in > an interface/module). > > What about IF_OSTYPE? > What about expressions? > IF_TARGET NT386 OR NTAMD64 > > IF_TARGET STARTS(NT) > > etc. > > I don't really have enough interest here to work through this, just > sending out the bait... > > Obviously this was triggered by my happening into the odbc directory > and bringing up ignoring WINAPI on non-NT386 or prefixing calling > conventions with a target. > > This reminds me of an important point here however -- nobody else is > going to make the mistake of ever having multiple calling > conventions. Therefore the generality of prefixing WINAPI with > NT386: is useless. > Unless Mac68K support is added. > > And here is some rationale even. The PC and Mac evolved from "small" > systems, where assembly programming was common, more people knew > more lower level details and playing games with calling conventions > was something anyone could do. Most other current systems are rooted > in C programming. Working in C, calling conventions are generally in > a hidden layer below what anyone thinks about. Therefore, the > smaller number of capable people working at that level have the good > sense to only have one calling convention. No more systems will > evolve from "small", at least not without having observed this > history. Therefore, there will no longer be multiple calling > conventions. > > That is my theory at least. > > Oh, Windows does also have __thiscall and __clrcall. __thiscall is > only x86 From hosking at cs.purdue.edu Tue Feb 12 03:07:04 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 11 Feb 2008 21:07:04 -0500 Subject: [M3devel] "target specific pragmas"? In-Reply-To: References: <20080211092401.1068410D466B@birch.elegosoft.com> <1202725259.8543.22.camel@faramir.m3w.org> <5ED85017-467B-4269-903A-AC512E78DF50@cs.purdue.edu> <9C682AFA-0D4C-486C-B51C-629AF426344A@cs.purdue.edu> <649A7621-D82E-4024-BC45-193892355AC4@cs.purdue.edu> Message-ID: So, here's the thing about pragmas. According to the language definition, they can be ignored and the program should still "mean" the same thing. Preprocessing definitely does not fit that model. On Feb 11, 2008, at 8:21 PM, Jay wrote: > So I have NOT thought this through. > > I wonder if "preprocessing" dependent only on "target" is a good idea. > > Something like either the ability to prefix pragmas with a target, > or an "iftarget" and "ifnottarget" pragma. > > Something like so: > > <* IF_TARGET NT386 *> > <* END_IF_TARGET*> > > > <* IF_TARGET NT386 *> > <* END_IF_TARGET*> > It's a small can of worms. > Where can they be placed? Only at "global" scope? (ie: toplevel in > an interface/module). > > What about IF_OSTYPE? > What about expressions? > IF_TARGET NT386 OR NTAMD64 > > IF_TARGET STARTS(NT) > > etc. > > I don't really have enough interest here to work through this, just > sending out the bait... > > Obviously this was triggered by my happening into the odbc > directory and bringing up ignoring WINAPI on non-NT386 or prefixing > calling conventions with a target. > > This reminds me of an important point here however -- nobody else > is going to make the mistake of ever having multiple calling > conventions. Therefore the generality of prefixing WINAPI with > NT386: is useless. > Unless Mac68K support is added. > > And here is some rationale even. The PC and Mac evolved from > "small" systems, where assembly programming was common, more people > knew more lower level details and playing games with calling > conventions was something anyone could do. Most other current > systems are rooted in C programming. Working in C, calling > conventions are generally in a hidden layer below what anyone > thinks about. Therefore, the smaller number of capable people > working at that level have the good sense to only have one calling > convention. No more systems will evolve from "small", at least not > without having observed this history. Therefore, there will no > longer be multiple calling conventions. > > That is my theory at least. > > Oh, Windows does also have __thiscall and __clrcall. __thiscall is > only x86 From hosking at cs.purdue.edu Tue Feb 12 03:08:27 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 11 Feb 2008 21:08:27 -0500 Subject: [M3devel] size_t? In-Reply-To: References: <20080211092401.1068410D466B@birch.elegosoft.com> <1202725259.8543.22.camel@faramir.m3w.org> <5ED85017-467B-4269-903A-AC512E78DF50@cs.purdue.edu> <9C682AFA-0D4C-486C-B51C-629AF426344A@cs.purdue.edu> <649A7621-D82E-4024-BC45-193892355AC4@cs.purdue.edu> Message-ID: <65396937-761B-4CA3-A20F-A04D53FAA6D2@cs.purdue.edu> C and Modula-3 fill different needs. I use C when it makes sense. I use Modula-3 when it makes sense. I'd hate to blur the distinction between them though! On Feb 11, 2008, at 8:05 PM, Jay wrote: > I think ANSI C is a bit of a mess here. > For the most part, no header is defined as #including any other. > That is good. Each header exposes certain names and few names are > exposed by more than one header. As well, for good measure, your > own #includes of ANSI C headers I believe is speced as order- > independent. These are all aspects of a "good module system", > except this solid foundation is built on a foundation of quicksand > and there is inadequate support for it in the language -- i.e. no > static enforcement... > > Anyway.. > But there are some symbols, such as size_t, that you can get from > multiple headers, directly or indirectly. > For example, strlen returns size_t, so #include must > define it (directly or indirectly). > Malloc takes size_t, so #include must define it > (directly or indirectly). > fread/fwrite/stdio.h ditto. > > I don't know if string.h/stdlib.h/stdio.h are speced as exposing > all of stddef.h however. > IF NOT, then there must be some underlying implementation defined > layer, OR the headers have to duplicate the definition. > > This notion of combining one interface into another wholesale is > probably usually a bad idea, but it can also be darn convenient. > Just #include everything, and have everything available in the > global namespace. > The "language" does live in this space. INTEGER is ALWAYS available > and always has the same meaning (per-target). I cannot redefine it > (again, other than by making a new target). > > Pushing some things into fewer larger integers is a step in this > direction. > It breaks "modularity" and so should be done very selectively, but / > arguably/ size_t and ptrdiff_t are fundamental enough to warrant > such treatment. > > So I guess my point is that size_t and ptrdiff_t should perhaps be > in the language. > Or, ok, ptrdiff_t == INTEGER, guaranteed, always and forever, on > all targets, no question. > So maybe just size_t is missing? > > I guess maybe it is BITS BITSIZE(INTEGER) FOR 0..LAST(INTEGER) ? > Good enough? > > Really, I'm sure you have all figured out, I want Modula-3 to look > more like C. :) > The more I use C lately (as opposed to C++) and the more I use > Modula-3 lately..the more I find C perfectly ok, the unsafety easy > enough to not be bitten by, the more the heap allocations and > copying that "safety" cost seem not worth it.. > > It's an interesting system largely just because it is yet another > system, in need (arguably) of more targets, and where "NT386" > exists but gets little support. Someone who "likes" Modula-3 more > would serve it better than me, perhaps. But I'm here. :) > > I also like that a decent module system was worked out such as to > build fast, at least when using the integrated backend. > So maybe I just write all my Modula-3 as "unsafe" and be happy. :) > > - Jay > > > > CC: m3devel at elegosoft.com > > From: hosking at cs.purdue.edu > > Subject: Re: [M3devel] size_t? > > Date: Mon, 11 Feb 2008 18:37:56 -0500 > > To: jayk123 at hotmail.com > > > > Yes, the ANSI C standard defines size_t and ptrdiff_t in stddef.h. > > > > Subtracting two pointers yields ptrdiff_t, so in M3 it would > > presumably be INTEGER. > > size_t is what sizeof returns, so I imagine size_t=CARDINAL is > > probably OK (to match BITSIZE/BYTESIZE/ADRSIZE), but maybe should > > better be Word.T to match C's unsigned interpretation. Of course, > > Word.T is simply INTEGER anyway in the current CM3 implementation. > > Note that neither of these need to be defined in the 32bit/64bit > > subdirectories since they are straightforwardly the same as the > > underlying word size. > > > > On Feb 11, 2008, at 5:34 PM, Jay wrote: > > > > > I did later notice size_t was there. > > > I think what I earlier noticed was ptrdiff_t nowhere. > > > > > > > size_t = INTEGER. > > > > > > But unsigned presumably? > > > > > > What I had was correct, right? > > > In C++ no header is needed for size_t, it is just so basic and > > > widespread. > > > Not sure about ptrdiff_t. > > > > > > Either way, they both do live in that middle ground between > > > compiler and library -- a very low level -- > > > as size_t is defined as the type of sizeof() expressions and > > > ptrdiff_t is defined as the type you get when you subtract > > > pointers. And you don't need nay header to use sizeof() or > subtract > > > pointers. > > > > > > If it were really up to me, I'd have the Modula-3 language > > > predefine all of int8, uint8, int16, uint16, int32, uint32, int64, > > > uint64, size_t, ptrdiff_t, and maybe char and wchar_t and INTEGER. > > > There is a corralary dilemna here that I haven't figured out, and > > > have seen code address that I haven't adjusted to yet. That is, > the > > > code uses uint32 "everywhere", instead of something "more > abstract/ > > > vague". When it comes down to it, I suspect this is the right > > > thing. The abstraction only seems to buy problems. UNLESS you have > > > a processor with a larger natural integer that performs poorly on > > > smaller integers, or a processor that perfs badly with 32 bit > > > integers. > > > > > > Perhaps Modula-3 has solved it ok, in that INTEGER == ptrdiff_t. > > > In many and growing systems, "int", besides its signedness, is too > > > small for many occurences. > > > That is the problem I think in C. If Modula-3 has essentially > > > defined INTEGER to be the size of a pointer, then ok. > > > > > > - Jay > > > > > > > > > > CC: m3devel at elegosoft.com > > > > From: hosking at cs.purdue.edu > > > > Subject: Re: [M3devel] size_t? > > > > Date: Mon, 11 Feb 2008 17:04:10 -0500 > > > > To: jayk123 at hotmail.com > > > > > > > > Sorry. > > > > > > > > They belong in Cstddef.i3. size_t is already there. Let's try to > > > > stick to the C ".h" structure. > > > > > > > > size_t = INTEGER. > > > > > > > > On Feb 11, 2008, at 4:51 PM, Jay wrote: > > > > > > > > > > These are OS-dependent! They should not be in BasicCtypes. > > > > > > > > > > 1) There is no Utypes on Windows. > > > > > These are very basic types that belong at a very low level. > > > > > In C++ for example, size_t is provided "automatically" by the > > > > > compiler, no header is needed. > > > > > > > > > > 2) Are they really OS dependent? What OS makes my definitions > > > wrong? > > > > > On what 32 bit architecture is size_t not an unsigned 32 bit > > > > > integer and ptrdiff_t not a signed 32 bit integer? > > > > > Ditto for 64 bit. > > > > > These should always be the same size as a pointer and with the > > > > > proper signedness. > > > > > Even if some of the *.i3 files make size_t = int, is that > really > > > > > correct? > > > > > And, I assume int vs. long issue is not an issue here. > > > > > Though they may be different types in C and C++, they need > not be > > > > > in Modula-3 (when they are the same size, of course) > > > > > > > > > > - Jay > > > > > > > > > > > > > > > > > > > > > CC: m3devel at elegosoft.com > > > > > > From: hosking at cs.purdue.edu > > > > > > Subject: Re: [M3devel] size_t? > > > > > > Date: Mon, 11 Feb 2008 11:38:48 -0500 > > > > > > To: jayk123 at hotmail.com > > > > > > > > > > > > > > > > > > On Feb 11, 2008, at 6:23 AM, Jay wrote: > > > > > > > > > > > > > C:\dev2\cm3.2\m3-libs\m3core\src\C\Common\Cstddef.i3(12): > > > size_t = > > > > > > > INTEGER; > > > > > > > > > > > > > > really? it is signed? > > > > > > > and we are sure this is going to be 64 bits on 64 bit > targets? > > > > > > > > > > > > > > size_t and ptrdiff_t ought to be in BasicCtypes, right? > > > > > > > That has a 32 bit and 64 bit version, at least. > > > > > > > > > > > > These are OS-dependent! They should not be in BasicCtypes. > > > > > > > > > > > > > > > > > > > > > > > > > > > Does INTEGER effectively equal int or ptrdiff_t? > > > > > > > > > > > > > > - Jay > > > > > > > > > > Need to know the score, the latest news, or you need your > > > Hotmail?- > > > > > get your "fix". Check it out. > > > > > > > > > > > > > Climb to the top of the charts! Play the word scramble challenge > > > with star power. Play now! > > > > > Helping your favorite cause is as easy as instant messaging. You > IM, we give. Learn more. From hosking at cs.purdue.edu Tue Feb 12 03:08:46 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 11 Feb 2008 21:08:46 -0500 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <48FBBB48-71D5-44CD-9A7C-BF6389A7B07F@darko.org> References: <20080211092401.1068410D466B@birch.elegosoft.com> <1202725259.8543.22.camel@faramir.m3w.org> <5ED85017-467B-4269-903A-AC512E78DF50@cs.purdue.edu> <9C682AFA-0D4C-486C-B51C-629AF426344A@cs.purdue.edu> <649A7621-D82E-4024-BC45-193892355AC4@cs.purdue.edu> <48FBBB48-71D5-44CD-9A7C-BF6389A7B07F@darko.org> Message-ID: <39FA50F1-347D-4AB3-9A0C-C3A8A7DCFCB7@cs.purdue.edu> Indeed! On Feb 11, 2008, at 8:37 PM, Darko wrote: > I think it's not a good idea. I think all platform specific code > should be in a separate file. I'd also like to see an option to > move calling conventions to the makefile rather than in pramas to > avoid having to duplicate interface files just to have a different > calling convention for a different platform. > > - Darko > > > On 12/02/2008, at 12:21 PM, Jay wrote: > >> So I have NOT thought this through. >> >> I wonder if "preprocessing" dependent only on "target" is a good >> idea. >> >> Something like either the ability to prefix pragmas with a target, >> or an "iftarget" and "ifnottarget" pragma. >> >> Something like so: >> >> <* IF_TARGET NT386 *> >> <* END_IF_TARGET*> >> >> >> <* IF_TARGET NT386 *> >> <* END_IF_TARGET*> >> It's a small can of worms. >> Where can they be placed? Only at "global" scope? (ie: toplevel in >> an interface/module). >> >> What about IF_OSTYPE? >> What about expressions? >> IF_TARGET NT386 OR NTAMD64 >> >> IF_TARGET STARTS(NT) >> >> etc. >> >> I don't really have enough interest here to work through this, >> just sending out the bait... >> >> Obviously this was triggered by my happening into the odbc >> directory and bringing up ignoring WINAPI on non-NT386 or >> prefixing calling conventions with a target. >> >> This reminds me of an important point here however -- nobody else >> is going to make the mistake of ever having multiple calling >> conventions. Therefore the generality of prefixing WINAPI with >> NT386: is useless. >> Unless Mac68K support is added. >> >> And here is some rationale even. The PC and Mac evolved from >> "small" systems, where assembly programming was common, more >> people knew more lower level details and playing games with >> calling conventions was something anyone could do. Most other >> current systems are rooted in C programming. Working in C, calling >> conventions are generally in a hidden layer below what anyone >> thinks about. Therefore, the smaller number of capable people >> working at that level have the good sense to only have one calling >> convention. No more systems will evolve from "small", at least not >> without having observed this history. Therefore, there will no >> longer be multiple calling conventions. >> >> That is my theory at least. >> >> Oh, Windows does also have __thiscall and __clrcall. __thiscall is >> only x86 From rodney.bates at wichita.edu Tue Feb 12 05:17:13 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Mon, 11 Feb 2008 22:17:13 -0600 Subject: [M3devel] introducing VAR in more places? In-Reply-To: References: <20080211092401.1068410D466B@birch.elegosoft.com> <400989C4-C086-4F4C-866C-A83F8854B34F@cs.purdue.edu> Message-ID: <47B11DC9.1040902@wichita.edu> I don't think this is what Tony meant. In C++, an opening brace starts a block, but every local declaration in that block has its own unique scope that only starts at that declaration and goes to the end of the block. This is particularly messy because the local declarations of a block need not all precede all the statements, and even worse because the distinction between declarations and statements is extremely subtle and, unless things have changed, never actually defined. (Do you remember Stroustrup's famous quote when taken to task about this? "If it looks like a declaration, it's a declaration. If it looks like a statement, it's a statement. If it doesn't look like either, it's a syntax error.") In contrast, in Modula-3, the scope of every local declaration starts at the beginning of the block and ends at the end of the block. The C++ reference makes an attempt at defining different terms for the entire block and the region where the identifier can be referred-to, i.e., from declaration to end of block (which I have called "scope" here). But as I recall, they ended up carefully defining their terminology in one section but then not using it consistently in the rest of the language definition. One of the few things Ada did better than Modula-3 was that the syntax has an explicit delimiter at all three relevant points: beginning of block, between declarations and statements, and end of block. (But it still has C++-like scopes for every declaration>.) I am an adamant believer in a high level of syntactic explicitness. Ada Modula-3 C++ start of block: DECLARE { between decls and stmts: BEGIN BEGIN end of block: END END } Jay wrote: > If you want a precise scope in C++, just but in an opening brace. > Just like how in Modula-3 (now I know) you can have "BEGIN" almost > anywhere, in C++ you can have an open brace almost anywhere. Ditto in C. > It isn't often used though, granted. > > - Jay > > ------------------------------------------------------------------------ > > > CC: m3devel at elegosoft.com > > From: hosking at cs.purdue.edu > > Subject: Re: [M3devel] introducing VAR in more places? > > Date: Mon, 11 Feb 2008 11:34:54 -0500 > > To: jayk123 at hotmail.com > > > > You can, except you need to explicitly give the block scope: > > > > VAR ... > > BEGIN > > ... > > END; > > > > I find this much better than C++ where the scope of the new variable > > is imprecisely defined. > > > > On Feb 11, 2008, at 4:29 AM, Jay wrote: > > > > > Does anyone else find it bothersome that you can't introduce VARs > > > anywhere? Kind of like in C++? > > > Ok, or if you grant that frame size doesn't matter THAT much, and > > > the compiler might do stack packing anyway, you can move all your > > > locals up top like typical C, but still, how about for the module > > > initializer? > > > Still it seems good to me to do manual stack packing since it is > > > often so easy.. > > > WITH helps, but only for "relative constants". > > > > > > It would be nice if the code below could have still loops until t0 ! > > > = t1, but the repeat condition is outside the scope in which t1 is > > > available. This feels quite lame.. > > > > > > - Jay > > > > > > > > > > > > > Date: Mon, 11 Feb 2008 10:24:00 +0000 > > > > To: m3commit at elegosoft.com > > > > From: jkrell at elego.de > > > > Subject: [M3commit] CVS Update: cm3 > > > > > > > > CVSROOT: /usr/cvs > > > > Changes by: jkrell at birch. 08/02/11 10:24:00 > > > > > > > > Modified files: > > > > cm3/m3-libs/m3core/src/time/WIN32/: Time.m3 > > > > > > > > Log message: > > > > no need for globals here.. > > > > > > > > > > > > > Helping your favorite cause is as easy as instant messaging. You > > > IM, we give. Learn more. > > > > > ------------------------------------------------------------------------ > Connect and share in new ways with Windows Live. Get it now! > -- ------------------------------------------------------------- Rodney M. Bates, retired assistant professor Dept. of Computer Science, Wichita State University Wichita, KS 67260-0083 316-978-3922 rodney.bates at wichita.edu From hosking at cs.purdue.edu Tue Feb 12 05:10:20 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 11 Feb 2008 23:10:20 -0500 Subject: [M3devel] Looking for CM3 Tinderbox regression test participants, was: Re: M3 concerns In-Reply-To: <20080131124304.w0aq9ygt2ckw4okc@mail.elegosoft.com> References: <477B7629.1E75.00D7.1@scires.com> <20080104221059.uwf80xrms0gw8880@mail.elegosoft.com> <063F2D47-D837-4E11-9001-D152527E8694@cs.purdue.edu> <20080105011335.n767h3zbz4gcgk4k@mail.elegosoft.com> <20080105011719.GA5064@topoi.pooq.com> <20080105143235.ujed2tl3ksogws8k@mail.elegosoft.com> <20080131124304.w0aq9ygt2ckw4okc@mail.elegosoft.com> Message-ID: <427855DD-C178-414E-8AEC-3BB723699B87@cs.purdue.edu> Score a big win for the regression test framework! I would not have devoted the time to finding the recently fixed race condition for mutex/condition initialization in the pthreads-based thread implementation if I had not been told about the problem with p007 on FreeBSD4. The problem only revealed itself in a repeatable way on FreeBSD4, and not repeatably enough to be debuggable on all the other systems I use (I386_DARWIN, PPC_DARWIN, LINUXLIBC6, or Solaris -- except for a clue in an error report from Alex Bochanek). Regression testing on multiple platforms is practically the only way to shake out these sorts of insidious bugs. Yay! Good work guys! On Jan 31, 2008, at 6:43 AM, Olaf Wagner wrote: > Quoting Olaf Wagner : >> o I think we have agreed on the fact that automatic regression >> testing >> would help and should be introduced. Tests should be run daily/ >> nightly >> on as many platforms as possible, and results should be collected >> and made available via WWW (elego offers to host these >> services, as >> it does for CVS repositories and CM3 web access). > > As you've surely all seen in the Status section of > > http://modula3.elegosoft.com/cm3/ > > the Elego Tinderbox regression test framework for CM3 has now been > working for about two weeks. Though it's still not as complete and > stable as I'd like it to be, I think it is now the right time for > others > to join the test framework and run the prepared tests in regular > intervals on their favourite platforms. The results can now be > transfered > to Elego via your ssh account you also use for repository commits. > > Currently the tests are running on a Debian Linux system and a > FreeBSD 6 > system at Elego, and now and then I'm starting a run on my MacOS X > laptop. The latter is not ideal for this purpose though. > > I'm now looking for other who would be willing to setup nightly tests > on their own servers. The following systems are of interest > > o PPC_DARWIN on MacOS X 10.4 or 10.5 > o I386_DARWIN > o SOLgnu on any Solaris version > o SOLsun " > o LINUXLIBC6 on RedHat, Fedora, Ubuntu, Suse Linux (have I forgotten > some variants?) > o NT386* on Windows 2000/XP/Vista > o NetBSD2_i386 > o FreeBSD4 on older FreeBSD systems (4.x, 5.x) and on current (7.0) > o PPC_LINUX (though this seems to be broken for some time) > o ALPHA_OSF -- is anybody still using Alphas? > > I think the other targets are more or less unused, but would of > course not > object to test results for them. > > There's a short description by Kaspar Schleiser of how to > participate in > cm3/scripts/regression/README. Basically you need to checkout the > scripts, install 5.4.0 manually once, and setup a cron job. > > We're mostly interested in the results of `tinderbox-build.sh > cm3.build', > which is the complete bootstrap and release build based on 5.4.0, > as I think the lastok build need not run on all platforms. It's mainly > there to detect incompatible changes. > > The release build includes the package and m3tests tests. > > If you want to participate, I'd suggest to setup everything and run > it once without transferring your results, then enable the transfer > in cm3.build: > > tinderbox_mailer() { > true # needed if function is emtpy without this... > # to report to the elego tinderbox host, check README and uncomment > this: > # cat "$1" | ssh tinderbox.elego.de "sudo -u tinderbox /usr/ > local/tinderbox/tinderbox-cgi/processmail_builds.cgi" > } > > That's all. Please let me know in advance if you setup the tests, > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > 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 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > From hosking at cs.purdue.edu Tue Feb 12 05:27:35 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 11 Feb 2008 23:27:35 -0500 Subject: [M3devel] scripts/PKGS Message-ID: I notice scripts/PKGS is no longer in the repository. Does this get generated somehow now? I know that do-cm3-std.sh depends on it because my copy of PKGS was broken (missing sysutils). Can someone explain to me how the build scripts have changed and how I should be using them? From darko at darko.org Tue Feb 12 05:37:52 2008 From: darko at darko.org (Darko) Date: Tue, 12 Feb 2008 15:37:52 +1100 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <47B1168F.8020302@wichita.edu> References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> Message-ID: <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> That's not quite right. Certain Mac API structures need to be aligned to Motorola 68K alignment for historical reasons. All other structures should use normal alignment to be compatible with C and Unix interfaces. The alignment change was implemented to be supported only in packed structures as a natural and intuitive way to "force" alignment. You could view it as a bug fix to overly restrictive alignment rules in packed structures. On 12/02/2008, at 2:46 PM, Rodney M. Bates wrote: > It sounds like all that Mac OS X needs is for _all_ types in an entire > program to use the liberal packing rules. Have I understood > correctly? > I would have no grief over that. > > Darko wrote: >> The liberalised alignment rules are required for the native Mac OS >> X API and should stay. You cannot use that API without them. I >> think the pragma is not required and can be removed. I agree with >> all the points you make. The effect of the modified alignment >> rules it to allow *packed* structures to have members aligned on >> byte boundaries. This has the effect of packing the fields in the >> tightest arrangement allowed by the platform. This might affect >> performance, but if the user is concerned about this they should >> specify field bit sizes that deliver improved performance. I don't >> see a need to specify this on a structure level, for the reasons >> you give and because the difference isn't significant enough in >> the case of packed structures and their physical layout and >> restrictions are platform dependent anyway. >> I might also add that the alignment code is currently broken on >> I386_DARWIN. >> - Darko >> On 11/02/2008, at 8:55 AM, Rodney M. Bates wrote: >>> Does anybody know about the status of pragma <*LAZYALIGN*>? Is it >>> being used anywhere? >>> >>> It is not documented in pragmas.html. The compiler front end >>> appears >>> to accept it. (In fact, Decls.m3 contains constants that suggest >>> limitations on what declarations the pragma can appear on, but these >>> are not actually enforced.) It liberalizes the alignment rules, >>> generally allowing scalars to start on any byte boundary. >>> >>> Pickles have to be able to reconstruct the layout of types as the >>> compiler would have done it for a machine (on which a now-being-read >>> pickle was written) with different word size and alignment >>> properties. >>> Currently, pickles are completely unaware of lazy alignment. It >>> would have to be encoded in type descriptions generated by the >>> compiler >>> using TipeDesc and read by pickles using RTTipe. >>> >>> Most troubling to me is what looks like a linguistic Pandora's box. >>> The pragma can be associated with any constant, variable, or type >>> _declaration_ (not type definition), with the result that different >>> values of the same type can actually be different in their alignment >>> rules and thus their layout. Similarly for different identifiers >>> equated to the same type. Although the effects of this could >>> possibly >>> be hidden from the programmer in purely safe code, not so with >>> unsafe >>> code. I haven't thoroughly thought this through, but seems to me >>> to >>> really fly in the face of the whole typing philosophy of the >>> language. >>> >>> For example, if pickles were to read in an object value, and there >>> were >1 variants of the object's type in the reading program, >>> differing >>> only in the alignment rules, how would it decide which one to build? >>> In fact, ignoring pickles altogether and just looking at a single >>> program, >>> if the object's type doesn't actually uniquely give its memory >>> layout, >>> how can it be accessed correctly? >>> >>> Additionally, a quick look at the compiler suggests it won't >>> generate >>> correct code for whole record assignment when the LHS and RHS are >>> the >>> same type but have different alignment characteristics. >>> >>> The more I think about it, it seems the only workable >>> possibilities are: >>> >>> 1) Require the pragma to be associated only with a type >>> _definition_ not a >>> declaration (e.g., allow RECORD <*LAZYALIGN*> ... END) and make >>> this a >>> property of the type that propagates to all names for the type and >>> all variables, constants, etc. Also, this would make this property >>> a part of the type signature that pickles uses when reading, -OR- >>> >>> 2) Forget it altogether. >>> >>> What do people think? >>> -- >>> ------------------------------------------------------------- >>> Rodney M. Bates, retired assistant professor >>> Dept. of Computer Science, Wichita State University >>> Wichita, KS 67260-0083 >>> 316-978-3922 >>> rodney.bates at wichita.edu > > -- > ------------------------------------------------------------- > Rodney M. Bates, retired assistant professor > Dept. of Computer Science, Wichita State University > Wichita, KS 67260-0083 > 316-978-3922 > rodney.bates at wichita.edu From hendrik at topoi.pooq.com Tue Feb 12 05:35:55 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 11 Feb 2008 23:35:55 -0500 Subject: [M3devel] size_t? In-Reply-To: References: <20080211092401.1068410D466B@birch.elegosoft.com> <1202725259.8543.22.camel@faramir.m3w.org> <5ED85017-467B-4269-903A-AC512E78DF50@cs.purdue.edu> <9C682AFA-0D4C-486C-B51C-629AF426344A@cs.purdue.edu> <649A7621-D82E-4024-BC45-193892355AC4@cs.purdue.edu> Message-ID: <20080212043555.GA21429@topoi.pooq.com> On Tue, Feb 12, 2008 at 01:05:39AM +0000, Jay wrote: > I think ANSI C is a bit of a mess here. > For the most part, no header is defined as #including any other. That is good. Each header exposes certain names and few names are exposed by more than one header. As well, for good measure, your own #includes of ANSI C headers I believe is speced as order-independent. These are all aspects of a "good module system", except this solid foundation is built on a foundation of quicksand and there is inadequate support for it in the language -- i.e. no static enforcement... > > Anyway.. > But there are some symbols, such as size_t, that you can get from multiple headers, directly or indirectly. > For example, strlen returns size_t, so #include must define it (directly or indirectly). > Malloc takes size_t, so #include must define it (directly or indirectly). > fread/fwrite/stdio.h ditto. > > I don't know if string.h/stdlib.h/stdio.h are speced as exposing all of stddef.h however. > IF NOT, then there must be some underlying implementation defined layer, OR the headers have to duplicate the definition. > > This notion of combining one interface into another wholesale is probably usually a bad idea, but it can also be darn convenient. Just #include everything, and have everything available in the global namespace. > The "language" does live in this space. INTEGER is ALWAYS available and always has the same meaning (per-target). I cannot redefine it (again, other than by making a new target). > > Pushing some things into fewer larger integers is a step in this direction. > It breaks "modularity" and so should be done very selectively, but /arguably/ size_t and ptrdiff_t are fundamental enough to warrant such treatment. > > So I guess my point is that size_t and ptrdiff_t should perhaps be in the language. > Or, ok, ptrdiff_t == INTEGER, guaranteed, always and forever, on all targets, no question. > So maybe just size_t is missing? > > I guess maybe it is BITS BITSIZE(INTEGER) FOR 0..LAST(INTEGER) ? > Good enough? The real requirement on size_t is that values of that type can be used freely in address arithmetic. -- hendrik From hendrik at topoi.pooq.com Tue Feb 12 05:38:21 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 11 Feb 2008 23:38:21 -0500 Subject: [M3devel] <*external winapi*> silently ignored on all platforms? In-Reply-To: References: Message-ID: <20080212043821.GB21429@topoi.pooq.com> On Mon, Feb 11, 2008 at 10:03:22PM +0000, Jay wrote: > Tony, is /everything/ Win32 ugly? :) No. Some of the video games are breathtakingly beautiful. -- hendrik From hendrik at topoi.pooq.com Tue Feb 12 05:39:29 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 11 Feb 2008 23:39:29 -0500 Subject: [M3devel] __declspec(dllimport)? In-Reply-To: References: <34257B37-565F-4ACE-9939-04CCBDE34D1E@cs.purdue.edu> <20080211164200.GB20791@topoi.pooq.com> <3DF581F4-F781-4A0E-8EC7-8D722A91A474@cs.purdue.edu> Message-ID: <20080212043929.GC21429@topoi.pooq.com> On Mon, Feb 11, 2008 at 09:52:06PM +0000, Jay wrote: > I guess I should switch the default calling convention and see what > the code size difference is. > Yes. Code size can be neasured. -- hendrik From jayk123 at hotmail.com Tue Feb 12 07:16:45 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 12 Feb 2008 06:16:45 +0000 Subject: [M3devel] scripts/PKGS In-Reply-To: References: Message-ID: It is generated if it doesn't exist. Delete your current one. - Jay > To: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Date: Mon, 11 Feb 2008 23:27:35 -0500> Subject: [M3devel] scripts/PKGS> > I notice scripts/PKGS is no longer in the repository. Does this get > generated somehow now? I know that do-cm3-std.sh depends on it > because my copy of PKGS was broken (missing sysutils). Can someone > explain to me how the build scripts have changed and how I should be > using them?> _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Feb 12 07:18:01 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 12 Feb 2008 06:18:01 +0000 Subject: [M3devel] $Id$ ? In-Reply-To: <20080212042047.A12E210D4686@birch.elegosoft.com> References: <20080212042047.A12E210D4686@birch.elegosoft.com> Message-ID: I added some files a while ago and someone either complained or added them, so I've been adding them since. - Jay > Date: Tue, 12 Feb 2008 05:20:47 +0000> To: m3commit at elegosoft.com> From: hosking at elego.de> Subject: [M3commit] CVS Update: cm3> > CVSROOT: /usr/cvs> Changes by: hosking at birch. 08/02/12 05:20:47> > Modified files:> cm3/m3-sys/cm3/src/: m3makefile > > Log message:> Let's avoid RCS id stuff shall we. Just clutters up the files...> _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Feb 12 07:22:28 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 12 Feb 2008 06:22:28 +0000 Subject: [M3devel] val? In-Reply-To: <20080212043242.37D6510D4686@birch.elegosoft.com> References: <20080212043242.37D6510D4686@birch.elegosoft.com> Message-ID: Sorry, I hadn't gotten around to testing this on other platforms. I do have PPC_DARWIN and PPC_LINUX available. There is/was a compilation problem with what I was doing. I"ll look into it more later. - Jay > Date: Tue, 12 Feb 2008 05:32:41 +0000> To: m3commit at elegosoft.com> From: hosking at elego.de> Subject: [M3commit] CVS Update: cm3> > CVSROOT: /usr/cvs> Changes by: hosking at birch. 08/02/12 05:32:41> > Modified files:> cm3/m3-libs/libm3/src/os/POSIX/: FilePosix.m3 > > Log message:> This checkin fixes something Jay left behind.> > Please check things build on platforms other than yours before making> changes. The VAL is necessary on some targets because 0 is INTEGER whereas> result is Utypes.off_t (LONGINT on I386_DARWIN) and cannot be directly> compared with an INTEGER (result). The VAL is how we do the conversion to> LONGINT.> > On platforms where Utypes.off_t is INTEGER this code will work the same as it> is.> _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Feb 12 08:20:33 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 12 Feb 2008 07:20:33 +0000 Subject: [M3devel] scripts/PKGS In-Reply-To: References: Message-ID: This is not my doing, at least not knowingly, just reporting the facts, officer. I wonder if maybe something more like Randy's scheme should be put in place. He has a smaller hand authored checked in file. The current system is more automatic, but doesn't handle changes automatically, and generates far more data than necessary I think. Perhaps another approach is to keep a timestamp/revision, embedded in the name, pkgs.v1234, someone rev the name as needed, and if the desired name doesn't exist rm pkgs.v* and recreate? This is a nice simple model imho. Changes are also very infrequent in my short observance. (I do go so far in the python directory to always use forward slashes, so the files are more portable across systems. :) Really, you know, it doesn't matter what the underlying system uses, as long as you translate at all the appropriate places and as long as you pick a syntax that can represent everything needed (not necessarily anything the underlying system supports). However you do have to translate at all the appropriate levels, possibly under the guidance of user settings. In particular, I can set M3CONFIG, M3ROOT, etc. to have forward slashes and it works just fine on Windows, but when errors are reported with paths, I can't paste them into file.open dialogs without changing the slashes....) - Jay From: jayk123 at hotmail.comTo: hosking at cs.purdue.edu; m3devel at elegosoft.comDate: Tue, 12 Feb 2008 06:16:45 +0000Subject: Re: [M3devel] scripts/PKGS It is generated if it doesn't exist.Delete your current one. - Jay > To: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Date: Mon, 11 Feb 2008 23:27:35 -0500> Subject: [M3devel] scripts/PKGS> > I notice scripts/PKGS is no longer in the repository. Does this get > generated somehow now? I know that do-cm3-std.sh depends on it > because my copy of PKGS was broken (missing sysutils). Can someone > explain to me how the build scripts have changed and how I should be > using them? _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Feb 12 09:16:42 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 12 Feb 2008 09:16:42 +0100 Subject: [M3devel] HEADS UP: CM3 builds broken Message-ID: <20080212091642.h1euh9btc8c0gsc4@mail.elegosoft.com> Tonight some of the tinderbox builds failed for CM3. First I thought it was just these changes to FilePosix which had already been fixed: ---------------------------- revision 1.8 date: 2008-02-12 04:32:40 +0000; author: hosking; state: Exp; lines: +1 -1; commitid: pvCLLyqdDKQm24Rs; This checkin fixes something Jay left behind. Please check things build on platforms other than yours before making changes. The VAL is necessary on some targets because 0 is INTEGER whereas result is Utypes.off_t (LONGINT on I386_DARWIN) and cannot be directly compared with an INTEGER (result). The VAL is how we do the conversion to LONGINT. On platforms where Utypes.off_t is INTEGER this code will work the same as it is. ---------------------------- revision 1.7 date: 2008-02-11 05:38:23 +0000; author: jkrell; state: Exp; lines: +1 -1; commitid: j3ewJLumr87rqWQs; more cygwin header cleanup, various dead types were used in further dead types in Ushm.i3; go ahead and delete dead stuff instead of commenting out remove seemingly unnecessary VAL() that fails to compile but when I try to build now on my FreeBSD system, I get this from cm3: % ./m3-sys/cm3/FreeBSD4/cm3 -version *** *** runtime error: *** Segmentation violation - possible attempt to dereference NIL *** pc = 0x821cf26 = EmptyBuffer + 0xc6 in ../src/rw/FileWr.m3 *** ^C Please check all the latest commits carefully and back out anything that seems suspicious or has not been tested. Thanks, Olaf -- Olaf Wagner -- elego Software Solutions GmbH 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 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jayk123 at hotmail.com Tue Feb 12 09:27:40 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 12 Feb 2008 08:27:40 +0000 Subject: [M3devel] HEADS UP: CM3 builds broken In-Reply-To: <20080212091642.h1euh9btc8c0gsc4@mail.elegosoft.com> References: <20080212091642.h1euh9btc8c0gsc4@mail.elegosoft.com> Message-ID: drat...I'd like to punt just a few hours here and will get to it then. Sorry. I hardly changed anything "live" other than what Tony put back. Yes I need to test more/at-all on Linux/x86 and/or FreeBSD/x86.. Great to have the tinderbox though, catch stuff "early" (yeah yeah, not as early as you'd like). - Jay > Date: Tue, 12 Feb 2008 09:16:42 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: [M3devel] HEADS UP: CM3 builds broken> > Tonight some of the tinderbox builds failed for CM3. First I thought> it was just these changes to FilePosix which had already been fixed:> > ----------------------------> revision 1.8> date: 2008-02-12 04:32:40 +0000; author: hosking; state: Exp; > lines: +1 -1; commitid: pvCLLyqdDKQm24Rs;> This checkin fixes something Jay left behind.> > Please check things build on platforms other than yours before making> changes. The VAL is necessary on some targets because 0 is INTEGER whereas> result is Utypes.off_t (LONGINT on I386_DARWIN) and cannot be directly> compared with an INTEGER (result). The VAL is how we do the conversion to> LONGINT.> > On platforms where Utypes.off_t is INTEGER this code will work the same as it> is.> ----------------------------> revision 1.7> date: 2008-02-11 05:38:23 +0000; author: jkrell; state: Exp; lines: > +1 -1; commitid: j3ewJLumr87rqWQs;> more cygwin header cleanup, various dead types were used> in further dead types in Ushm.i3; go ahead and delete> dead stuff instead of commenting out> remove seemingly unnecessary VAL() that fails to compile> > but when I try to build now on my FreeBSD system, I get this from cm3:> > % ./m3-sys/cm3/FreeBSD4/cm3 -version> > ***> *** runtime error:> *** Segmentation violation - possible attempt to dereference NIL> *** pc = 0x821cf26 = EmptyBuffer + 0xc6 in ../src/rw/FileWr.m3> ***> > ^C> > Please check all the latest commits carefully and back out anything> that seems suspicious or has not been tested.> > Thanks,> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> 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> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Feb 12 09:45:24 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 12 Feb 2008 08:45:24 +0000 Subject: [M3devel] HEADS UP: CM3 builds broken In-Reply-To: References: <20080212091642.h1euh9btc8c0gsc4@mail.elegosoft.com> Message-ID: The only other non-NT386/GNU change by me, from a quick scan of ChangeLog, is: 2008-02-10 23:24 jkrell * m3-libs/m3core/src/: runtime/m3makefile, thread/m3makefile, thread/Common/SchedulerPosix.i3, thread/Common/m3makefile, thread/POSIX/SchedulerPosix.i3, thread/POSIX/m3makefile, thread/PTHREAD/SchedulerPosix.i3, thread/PTHREAD/m3makefile, thread/WIN32/ThreadWin32.m3: cheat just a tad and provide SchedulePosix interface on Win32 albeit not a good implementation currently this way NT386GNU can build with Win32 threads and cm3 gets as far as printing an error and exiting, probably something to do with pesky slashes; a lot better than hanging due to nanosleep failing and worrying about a lot of non trivial cygwin code.. which looks very ok. I moved SchedulerPosix to common and provided a do-nothing implementation for NT386. This is so NT386GNU can use native Win32 threads, but Posix in other places like i/o. (Sometimes I wonder...maybe all that's needed is handling forward and backward slashes the same c:/foo/bar, which I already put in, plus allowing X Windows... (Trestle builds now btw...std packages get at least as far as anim3d. Running stuff is known to have problems..the slash issues were just because I had backslashes (and colons) in paths in environment variables... the current problem is that cm3 always seems to think files are out of date and that all builds fail, but it does actually run cm3cg over everything and seems to work...surely an easy issue to deal with...oh I think m3bundle crashes, the only other thing I've run besides cm3...like..for example, keeping time in seconds since 1970 in a 32bit signed integer seems more like a bug than a feature....maybe I'll start another thread here....even the Win32 Modula-3 interfaces I think use that poor representation, just that they go to the effort of converting from a better format....)) Anyway I'll at least test on birch later and maybe install FreeBSD in a virtual machine..... - Jay From: jayk123 at hotmail.comTo: wagner at elegosoft.com; m3devel at elegosoft.comDate: Tue, 12 Feb 2008 08:27:40 +0000Subject: Re: [M3devel] HEADS UP: CM3 builds broken drat...I'd like to punt just a few hours here and will get to it then.Sorry.I hardly changed anything "live" other than what Tony put back.Yes I need to test more/at-all on Linux/x86 and/or FreeBSD/x86.. Great to have the tinderbox though, catch stuff "early" (yeah yeah, not as early as you'd like). - Jay > Date: Tue, 12 Feb 2008 09:16:42 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: [M3devel] HEADS UP: CM3 builds broken> > Tonight some of the tinderbox builds failed for CM3. First I thought> it was just these changes to FilePosix which had already been fixed:> > ----------------------------> revision 1.8> date: 2008-02-12 04:32:40 +0000; author: hosking; state: Exp; > lines: +1 -1; commitid: pvCLLyqdDKQm24Rs;> This checkin fixes something Jay left behind.> > Please check things build on platforms other than yours before making> changes. The VAL is necessary on some targets because 0 is INTEGER whereas> result is Utypes.off_t (LONGINT on I386_DARWIN) and cannot be directly> compared with an INTEGER (result). The VAL is how we do the conversion to> LONGINT.> > On platforms where Utypes.off_t is INTEGER this code will work the same as it> is.> ----------------------------> revision 1.7> date: 2008-02-11 05:38:23 +0000; author: jkrell; state: Exp; lines: > +1 -1; commitid: j3ewJLumr87rqWQs;> more cygwin header cleanup, various dead types were used> in further dead types in Ushm.i3; go ahead and delete> dead stuff instead of commenting out> remove seemingly unnecessary VAL() that fails to compile> > but when I try to build now on my FreeBSD system, I get this from cm3:> > % ./m3-sys/cm3/FreeBSD4/cm3 -version> > ***> *** runtime error:> *** Segmentation violation - possible attempt to dereference NIL> *** pc = 0x821cf26 = EmptyBuffer + 0xc6 in ../src/rw/FileWr.m3> ***> > ^C> > Please check all the latest commits carefully and back out anything> that seems suspicious or has not been tested.> > Thanks,> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> 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> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> Shed those extra pounds with MSN and The Biggest Loser! Learn more. _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Feb 12 11:34:42 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 12 Feb 2008 11:34:42 +0100 Subject: [M3devel] scripts/PKGS In-Reply-To: References: Message-ID: <20080212113442.p5eudv3y0w4ks04o@mail.elegosoft.com> Quoting Tony Hosking : > I notice scripts/PKGS is no longer in the repository. Does this get > generated somehow now? I know that do-cm3-std.sh depends on it because > my copy of PKGS was broken (missing sysutils). Can someone explain to > me how the build scripts have changed and how I should be using them? PKGS has never been checked-in and should not as far as I know. It contains workspace-dependent paths and is built by find-packages.sh if I remember correctly. All shell scripts will generate it if it does not exist. It can be deleted any time, and indeed must be deleted if packages are added (or they will not be found). This is arguably a bug, but then all the scripts were never intended to be a general user interface for CM3 users (only for the maintenance). Olaf -- Olaf Wagner -- elego Software Solutions GmbH 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 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jayk123 at hotmail.com Tue Feb 12 12:23:21 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 12 Feb 2008 11:23:21 +0000 Subject: [M3devel] scripts/PKGS In-Reply-To: <20080212113442.p5eudv3y0w4ks04o@mail.elegosoft.com> References: <20080212113442.p5eudv3y0w4ks04o@mail.elegosoft.com> Message-ID: Obviously if the paths are relative to CM3_ROOT, it isn't workspace dependent... How about my idea of making the name have a "version" in it, and the version can be bumped as needed? Or making it contain relative paths and just maintain it manually? - Jay > Date: Tue, 12 Feb 2008 11:34:42 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] scripts/PKGS> > Quoting Tony Hosking :> > > I notice scripts/PKGS is no longer in the repository. Does this get> > generated somehow now? I know that do-cm3-std.sh depends on it because> > my copy of PKGS was broken (missing sysutils). Can someone explain to> > me how the build scripts have changed and how I should be using them?> > PKGS has never been checked-in and should not as far as I know.> It contains workspace-dependent paths and is built by find-packages.sh> if I remember correctly. All shell scripts will generate it if it> does not exist. It can be deleted any time, and indeed must be deleted> if packages are added (or they will not be found). This is arguably a bug,> but then all the scripts were never intended to be a general user interface> for CM3 users (only for the maintenance).> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> 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> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Feb 12 12:34:08 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 12 Feb 2008 11:34:08 +0000 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> Message-ID: I strongly suggest that at least in some contexts, no padding ever be quietly inserted, and that all seeming need for padding generate an error, unless explicitly quashed, preferably by explicit insertion of padding fields by the programmer, and/or rearrangement sorted by size, or possibly some annotation of the overall struct/record/class/module, an annotation such as <* silent padding ok*>. Alignment issues really bug me... I realize many data structures are only ever seen in memory, by one process, so it doesn't matter, but when it matter, the languages/tools seem to fall down. As well, "padding" fields should be annotated as such and the compiler warn or error if they aren't needed. It's just dumb that code like: struct { int32 a; int64 b;}; when defining some stable important binary layout can have a varying but silently allowed meaning based on command line switches or targets.. Yes, I'm a dumb programmer to write it, but man the tools are lagging. This will fall on deaf ears and far from sufficient ears even if they were hearing. It's the C compilers that are somewhat broken here imho. C is unnecessarily broken here. Imho it's a big cause for headaches and easily solved....it doesn't have to stink so badly, if anyone cared.. I have had to maintain structs that had to look the same across different targets and therefore insert target-dependent padding. Ok, but it should have been easier. When I was done, I put in compile time asserts as to the offset of every single field so the next guy would have an easier time, and assiduously commented every byte of padding in the struct and its target-dependentness.... This was like for shared memory. Grumble, - Jay > From: darko at darko.org> To: rodney.bates at wichita.edu> Date: Tue, 12 Feb 2008 15:37:52 +1100> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] <*LAZYALIGN*>> > That's not quite right. Certain Mac API structures need to be aligned > to Motorola 68K alignment for historical reasons. All other structures > should use normal alignment to be compatible with C and Unix > interfaces. The alignment change was implemented to be supported only > in packed structures as a natural and intuitive way to "force" > alignment. You could view it as a bug fix to overly restrictive > alignment rules in packed structures.> > > On 12/02/2008, at 2:46 PM, Rodney M. Bates wrote:> > > It sounds like all that Mac OS X needs is for _all_ types in an entire> > program to use the liberal packing rules. Have I understood > > correctly?> > I would have no grief over that.> >> > Darko wrote:> >> The liberalised alignment rules are required for the native Mac OS > >> X API and should stay. You cannot use that API without them. I > >> think the pragma is not required and can be removed. I agree with > >> all the points you make. The effect of the modified alignment > >> rules it to allow *packed* structures to have members aligned on > >> byte boundaries. This has the effect of packing the fields in the > >> tightest arrangement allowed by the platform. This might affect > >> performance, but if the user is concerned about this they should > >> specify field bit sizes that deliver improved performance. I don't > >> see a need to specify this on a structure level, for the reasons > >> you give and because the difference isn't significant enough in > >> the case of packed structures and their physical layout and > >> restrictions are platform dependent anyway.> >> I might also add that the alignment code is currently broken on > >> I386_DARWIN.> >> - Darko> >> On 11/02/2008, at 8:55 AM, Rodney M. Bates wrote:> >>> Does anybody know about the status of pragma <*LAZYALIGN*>? Is it> >>> being used anywhere?> >>>> >>> It is not documented in pragmas.html. The compiler front end > >>> appears> >>> to accept it. (In fact, Decls.m3 contains constants that suggest> >>> limitations on what declarations the pragma can appear on, but these> >>> are not actually enforced.) It liberalizes the alignment rules,> >>> generally allowing scalars to start on any byte boundary.> >>>> >>> Pickles have to be able to reconstruct the layout of types as the> >>> compiler would have done it for a machine (on which a now-being-read> >>> pickle was written) with different word size and alignment > >>> properties.> >>> Currently, pickles are completely unaware of lazy alignment. It> >>> would have to be encoded in type descriptions generated by the > >>> compiler> >>> using TipeDesc and read by pickles using RTTipe.> >>>> >>> Most troubling to me is what looks like a linguistic Pandora's box.> >>> The pragma can be associated with any constant, variable, or type> >>> _declaration_ (not type definition), with the result that different> >>> values of the same type can actually be different in their alignment> >>> rules and thus their layout. Similarly for different identifiers> >>> equated to the same type. Although the effects of this could > >>> possibly> >>> be hidden from the programmer in purely safe code, not so with > >>> unsafe> >>> code. I haven't thoroughly thought this through, but seems to me > >>> to> >>> really fly in the face of the whole typing philosophy of the > >>> language.> >>>> >>> For example, if pickles were to read in an object value, and there> >>> were >1 variants of the object's type in the reading program, > >>> differing> >>> only in the alignment rules, how would it decide which one to build?> >>> In fact, ignoring pickles altogether and just looking at a single > >>> program,> >>> if the object's type doesn't actually uniquely give its memory > >>> layout,> >>> how can it be accessed correctly?> >>>> >>> Additionally, a quick look at the compiler suggests it won't > >>> generate> >>> correct code for whole record assignment when the LHS and RHS are > >>> the> >>> same type but have different alignment characteristics.> >>>> >>> The more I think about it, it seems the only workable > >>> possibilities are:> >>>> >>> 1) Require the pragma to be associated only with a type > >>> _definition_ not a> >>> declaration (e.g., allow RECORD <*LAZYALIGN*> ... END) and make > >>> this a> >>> property of the type that propagates to all names for the type and> >>> all variables, constants, etc. Also, this would make this property> >>> a part of the type signature that pickles uses when reading, -OR-> >>>> >>> 2) Forget it altogether.> >>>> >>> What do people think?> >>> -- > >>> -------------------------------------------------------------> >>> Rodney M. Bates, retired assistant professor> >>> Dept. of Computer Science, Wichita State University> >>> Wichita, KS 67260-0083> >>> 316-978-3922> >>> rodney.bates at wichita.edu> >> > -- > > -------------------------------------------------------------> > Rodney M. Bates, retired assistant professor> > Dept. of Computer Science, Wichita State University> > Wichita, KS 67260-0083> > 316-978-3922> > rodney.bates at wichita.edu> _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Feb 12 12:50:00 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 12 Feb 2008 11:50:00 +0000 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <39FA50F1-347D-4AB3-9A0C-C3A8A7DCFCB7@cs.purdue.edu> References: <20080211092401.1068410D466B@birch.elegosoft.com> <1202725259.8543.22.camel@faramir.m3w.org> <5ED85017-467B-4269-903A-AC512E78DF50@cs.purdue.edu> <9C682AFA-0D4C-486C-B51C-629AF426344A@cs.purdue.edu> <649A7621-D82E-4024-BC45-193892355AC4@cs.purdue.edu> <48FBBB48-71D5-44CD-9A7C-BF6389A7B07F@darko.org> <39FA50F1-347D-4AB3-9A0C-C3A8A7DCFCB7@cs.purdue.edu> Message-ID: I insist that it depends. Putting every platform-specific piece of code in its own file/directory can lead to mass duplication of nearly identical code. Sometimes an #if here or there goes very far in /improving/ code maintainability. A lot of #if here there and everywhere of course can have the opposite effect. And I realize if you were to drop support for a target, it is easier to find/delete files/directories than #ifs, but I don't think that's a good enough reason to sway the decision. It goes both ways. Yes, you could endeavor factor things down so that everything common is in common, and everything not-common is in platform-specific. But this is inadequate I think. The tail is wagging the dog unnecessarily I think. If my code very nearly all goes together, don't make me separate it. Also sometimes a different factoring is "encouraged" for other reasons, to match someone else's factoring. Look at the C*.i3 files. They actually can be almost all be nearly the same, yet they are hardly shared at all. I realize you could also do a sort of "forwarding", though I'm not sure that Modula-3 offers all the right capabilities for this. Type forwarding, sure. But how about procedure forwarding? Like nt386\cstdio.i3 fopen = common\ccommonstdio.i3 fopen? And having to duplicate a line per type/procedure is lame anyway, you KIND OF want "module inheritance". However, if you allow preprocessing based on target, perhaps the need for that goes away. While extern C varargs functions are generally useless in Modula-3, and therefore extern __cdecl is fairly rare, it DOES occur when you write little helpers in C, such as for errno. A good /heuristic/ might be to change the default in any directory that has no c_source. But it is only heuristic. Whatever is done here, some allowance should probably be made for multiple calling conventions in the same file. Switching the default to the overwhelming majority and then annotating the minority is reasonable. I still believe that silently ignoring calling conventions on all but NT386 is VERY reasonable, and that no other platform from here on out will ever have calling conventions. Esp. not with the same names. When OS/FOO has the FOOAPI calling convention, you can just ignore that one on all but target OS/FOO. Just as all but NT386 ignore WINAPI. Yes this COULD possibly get ugly something like: <*EXTERN FOOAPI WINAPI*> fopen(); FOOAPI for OS/FOO, WINAPI ignored. WINAPI for NT386, FOOAPI ignored. The One True Calling Convention for all others, calling convention ignored. I really believe this is highly highly unlikely to occur, and it is not a terrible outcome, and this bridge could be crossed in the far off future. The functions that are usually in need of calling conventions are usually only present on one system. Perhaps ODBC is an extremely rare anomaly and the whole issue is nearly nonexistant. That could be also. A change just for ODBC is probably not the best, though it is a very small safe harmless change (I always say that :) ) - Jay > CC: jayk123 at hotmail.com; m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: [M3devel] "target specific pragmas"?> Date: Mon, 11 Feb 2008 21:08:46 -0500> To: darko at darko.org> > Indeed!> > On Feb 11, 2008, at 8:37 PM, Darko wrote:> > > I think it's not a good idea. I think all platform specific code > > should be in a separate file. I'd also like to see an option to > > move calling conventions to the makefile rather than in pramas to > > avoid having to duplicate interface files just to have a different > > calling convention for a different platform.> >> > - Darko> >> >> > On 12/02/2008, at 12:21 PM, Jay wrote:> >> >> So I have NOT thought this through.> >>> >> I wonder if "preprocessing" dependent only on "target" is a good > >> idea.> >>> >> Something like either the ability to prefix pragmas with a target, > >> or an "iftarget" and "ifnottarget" pragma.> >>> >> Something like so:> >>> >> <* IF_TARGET NT386 *>> >> <* END_IF_TARGET*>> >>> >>> >> <* IF_TARGET NT386 *>> >> <* END_IF_TARGET*>> >> It's a small can of worms.> >> Where can they be placed? Only at "global" scope? (ie: toplevel in > >> an interface/module).> >>> >> What about IF_OSTYPE?> >> What about expressions?> >> IF_TARGET NT386 OR NTAMD64> >>> >> IF_TARGET STARTS(NT)> >>> >> etc.> >>> >> I don't really have enough interest here to work through this, > >> just sending out the bait...> >>> >> Obviously this was triggered by my happening into the odbc > >> directory and bringing up ignoring WINAPI on non-NT386 or > >> prefixing calling conventions with a target.> >>> >> This reminds me of an important point here however -- nobody else > >> is going to make the mistake of ever having multiple calling > >> conventions. Therefore the generality of prefixing WINAPI with > >> NT386: is useless.> >> Unless Mac68K support is added.> >>> >> And here is some rationale even. The PC and Mac evolved from > >> "small" systems, where assembly programming was common, more > >> people knew more lower level details and playing games with > >> calling conventions was something anyone could do. Most other > >> current systems are rooted in C programming. Working in C, calling > >> conventions are generally in a hidden layer below what anyone > >> thinks about. Therefore, the smaller number of capable people > >> working at that level have the good sense to only have one calling > >> convention. No more systems will evolve from "small", at least not > >> without having observed this history. Therefore, there will no > >> longer be multiple calling conventions.> >>> >> That is my theory at least.> >>> >> Oh, Windows does also have __thiscall and __clrcall. __thiscall is > >> only x86> _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Feb 12 13:05:56 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 12 Feb 2008 13:05:56 +0100 Subject: [M3devel] HEADS UP: CM3 builds broken In-Reply-To: <20080212091642.h1euh9btc8c0gsc4@mail.elegosoft.com> References: <20080212091642.h1euh9btc8c0gsc4@mail.elegosoft.com> Message-ID: <20080212130556.0niuix6mm8088ssc@mail.elegosoft.com> Hi again, the builds I started again this morning before leaving home seem to have succeeded again. I don't understand why compilation with the latest sources on my own system was broken though; I'll have to check that tonight. There's seems to be no immediate need for action though :-) It would be great if all committers would check the tinderbox status on http://www.opencm3.net at least after check-ins. You'll find it under "Status -> Tinderbox Tests", or directly at http://tinderbox.elegosoft.com/tinderbox/cm3/status.html. It contains links to all the build logs and the m3tests and package build test results, as well as a list of check-ins that may be responsible for any breakage (click on the dates in the left column). Olaf Quoting Olaf Wagner : > Tonight some of the tinderbox builds failed for CM3. First I thought > it was just these changes to FilePosix which had already been fixed: > > ---------------------------- > revision 1.8 > date: 2008-02-12 04:32:40 +0000; author: hosking; state: Exp; lines: > +1 -1; commitid: pvCLLyqdDKQm24Rs; > This checkin fixes something Jay left behind. > > Please check things build on platforms other than yours before making > changes. The VAL is necessary on some targets because 0 is INTEGER whereas > result is Utypes.off_t (LONGINT on I386_DARWIN) and cannot be directly > compared with an INTEGER (result). The VAL is how we do the conversion to > LONGINT. > > On platforms where Utypes.off_t is INTEGER this code will work the same as it > is. > ---------------------------- > revision 1.7 > date: 2008-02-11 05:38:23 +0000; author: jkrell; state: Exp; lines: > +1 -1; commitid: j3ewJLumr87rqWQs; > more cygwin header cleanup, various dead types were used > in further dead types in Ushm.i3; go ahead and delete > dead stuff instead of commenting out > remove seemingly unnecessary VAL() that fails to compile > > but when I try to build now on my FreeBSD system, I get this from cm3: > > % ./m3-sys/cm3/FreeBSD4/cm3 -version > > *** > *** runtime error: > *** Segmentation violation - possible attempt to dereference NIL > *** pc = 0x821cf26 = EmptyBuffer + 0xc6 in ../src/rw/FileWr.m3 > *** > > ^C > > Please check all the latest commits carefully and back out anything > that seems suspicious or has not been tested. > > Thanks, > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > 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 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -- Olaf Wagner -- elego Software Solutions GmbH 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 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From mika at async.caltech.edu Tue Feb 12 13:56:02 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 12 Feb 2008 04:56:02 -0800 Subject: [M3devel] "target specific pragmas"? In-Reply-To: Your message of "Tue, 12 Feb 2008 11:50:00 GMT." Message-ID: <200802121256.m1CCu2ct089960@camembert.async.caltech.edu> Can you just generate the Modula-3 code you want using a Python script or COBOL or whatever you like instead of trying to foist preprocessing nastiness on innocent users of high-level Modula-3? Preprocessing is super nasty. It's not just a question of human readability. m3tk has to be able to read the code, too. I should be able to write a program that reads in (using m3tk) an arbitrary Modula-3 interface and understands it to the point that it can generate Network Object stubs, inter-language call stubs, etc. The stubs should ALSO be human- and m3tk-readable after the transformation! This should work even if the programmer has been very "clever" in his use of Modula-3 constructs. (Just try getting something like that to work with C or C++... it's hopeless once the preprocessor gets involved, and possibly before.) Also if I may make a little request, if at all possible, please try not to break binary compatibility with gcc-compiled C and Fortran on NT386GNU (not sure if your ideas about calling conventions could possibly do that...) Mika Jay writes: >--_8b04f633-e2a4-411d-940a-739ab79b0616_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > >I insist that it depends. >Putting every platform-specific piece of code in its own file/directory can= > lead to mass duplication of nearly identical code. >Sometimes an #if here or there goes very far in /improving/ code maintainab= >ility. >A lot of #if here there and everywhere of course can have the opposite effe= >ct. >And I realize if you were to drop support for a target, it is easier to fin= >d/delete files/directories than #ifs, but I don't think that's a good enoug= >h reason to sway the decision. >It goes both ways. >=20 >Yes, you could endeavor factor things down so that everything common is in = >common, and everything not-common is in platform-specific. But this is inad= >equate I think. The tail is wagging the dog unnecessarily I think. If my co= >de very nearly all goes together, don't make me separate it. Also sometimes= > a different factoring is "encouraged" for other reasons, to match someone = >else's factoring. Look at the C*.i3 files. They actually can be almost all = >be nearly the same, yet they are hardly shared at all. I realize you could = >also do a sort of "forwarding", though I'm not sure that Modula-3 offers al= >l the right capabilities for this. Type forwarding, sure. But how about pro= >cedure forwarding? Like nt386\cstdio.i3 fopen =3D common\ccommonstdio.i3 fo= >pen? And having to duplicate a line per type/procedure is lame anyway, you = >KIND OF want "module inheritance". However, if you allow preprocessing base= >d on target, perhaps the need for that goes away. >=20 >While extern C varargs functions are generally useless in Modula-3, and the= >refore extern __cdecl is fairly rare, it DOES occur when you write little h= >elpers in C, such as for errno. >=20 >A good /heuristic/ might be to change the default in any directory that has= > no c_source. >But it is only heuristic. >=20 >Whatever is done here, some allowance should probably be made for multiple = >calling conventions in the same file. >Switching the default to the overwhelming majority and then annotating the = >minority is reasonable. >=20 >I still believe that silently ignoring calling conventions on all but NT386= > is VERY reasonable, and that no other platform from here on out will ever = >have calling conventions. Esp. not with the same names. When OS/FOO has the= > FOOAPI calling convention, you can just ignore that one on all but target = >OS/FOO. Just as all but NT386 ignore WINAPI. Yes this COULD possibly get ug= >ly something like: ><*EXTERN FOOAPI WINAPI*> fopen(); >FOOAPI for OS/FOO, WINAPI ignored. >WINAPI for NT386, FOOAPI ignored. >The One True Calling Convention for all others, calling convention ignored. >=20 >I really believe this is highly highly unlikely to occur, and it is not a t= >errible outcome, and this bridge could be crossed in the far off future. >The functions that are usually in need of calling conventions are usually o= >nly present on one system. >Perhaps ODBC is an extremely rare anomaly and the whole issue is nearly non= >existant. >That could be also. >A change just for ODBC is probably not the best, though it is a very small = >safe harmless change (I always say that :) ) >=20 >=20 > - Jay > > > >> CC: jayk123 at hotmail.com; m3devel at elegosoft.com> From: hosking at cs.purdue.e= >du> Subject: Re: [M3devel] "target specific pragmas"?> Date: Mon, 11 Feb 20= >08 21:08:46 -0500> To: darko at darko.org> > Indeed!> > On Feb 11, 2008, at 8:= >37 PM, Darko wrote:> > > I think it's not a good idea. I think all platform= > specific code > > should be in a separate file. I'd also like to see an op= >tion to > > move calling conventions to the makefile rather than in pramas = >to > > avoid having to duplicate interface files just to have a different >= > > calling convention for a different platform.> >> > - Darko> >> >> > On 1= >2/02/2008, at 12:21 PM, Jay wrote:> >> >> So I have NOT thought this throug= >h.> >>> >> I wonder if "preprocessing" dependent only on "target" is a good= > > >> idea.> >>> >> Something like either the ability to prefix pragmas wit= >h a target, > >> or an "iftarget" and "ifnottarget" pragma.> >>> >> Somethi= >ng like so:> >>> >> <* IF_TARGET NT386 *>> >> <* END_IF_TARGET*>> >>> >>> >= >> <* IF_TARGET NT386 *>> >> <* END_IF_TARGET*>> >> It's a small can of worm= >s.> >> Where can they be placed? Only at "global" scope? (ie: toplevel in >= > >> an interface/module).> >>> >> What about IF_OSTYPE?> >> What about expr= >essions?> >> IF_TARGET NT386 OR NTAMD64> >>> >> IF_TARGET STARTS(NT)> >>> >= >> etc.> >>> >> I don't really have enough interest here to work through thi= >s, > >> just sending out the bait...> >>> >> Obviously this was triggered b= >y my happening into the odbc > >> directory and bringing up ignoring WINAPI= > on non-NT386 or > >> prefixing calling conventions with a target.> >>> >> = >This reminds me of an important point here however -- nobody else > >> is g= >oing to make the mistake of ever having multiple calling > >> conventions. = >Therefore the generality of prefixing WINAPI with > >> NT386: is useless.> = >>> Unless Mac68K support is added.> >>> >> And here is some rationale even.= > The PC and Mac evolved from > >> "small" systems, where assembly programmi= >ng was common, more > >> people knew more lower level details and playing g= >ames with > >> calling conventions was something anyone could do. Most othe= >r > >> current systems are rooted in C programming. Working in C, calling >= > >> conventions are generally in a hidden layer below what anyone > >> thin= >ks about. Therefore, the smaller number of capable people > >> working at t= >hat level have the good sense to only have one calling > >> convention. No = >more systems will evolve from "small", at least not > >> without having obs= >erved this history. Therefore, there will no > >> longer be multiple callin= >g conventions.> >>> >> That is my theory at least.> >>> >> Oh, Windows does= > also have __thiscall and __clrcall. __thiscall is > >> only x86>=20 >_________________________________________________________________ >Climb to the top of the charts!=A0Play the word scramble challenge with sta= >r power. >http://club.live.com/star_shuffle.aspx?icid=3Dstarshuffle_wlmailtextlink_ja= >n= > >--_8b04f633-e2a4-411d-940a-739ab79b0616_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > >I insist that it depends.
>Putting every platform-specific piece of code in its own file/directory can= > lead to mass duplication of nearly identical code.
>Sometimes an #if here or there goes very far in /improving/ code maintainab= >ility.
>A lot of #if here there and everywhere of course can have the opposite effe= >ct.
>And I realize if you were to drop support for a target, it is easier to fin= >d/delete files/directories than #ifs, but I don't think that's a good enoug= >h reason to sway the decision.
>It goes both ways.
> 
>Yes, you could endeavor factor things down so that everything common i= >s in common, and everything not-common is in platform-specific. But this is= > inadequate I think. The tail is wagging the dog unnecessarily I think. If = >my code very nearly all goes together, don't make me separate it. = >;Also sometimes a different factoring is "encouraged" for other reasons, to= > match someone else's factoring. Look at the C*.i3 files. They actually can= > be almost all be nearly the same, yet they are hardly shared at all. I rea= >lize you could also do a sort of "forwarding", though I'm not sure that Mod= >ula-3 offers all the right capabilities for this. Type forwarding, sure. Bu= >t how about procedure forwarding? Like nt386\cstdio.i3 fopen =3D common\cco= >mmonstdio.i3 fopen? And having to duplicate a line per type/procedure is la= >me anyway, you KIND OF want "module inheritance". However, if you allow pre= >processing based on target, perhaps the need for that goes away.
> 
>While extern C varargs functions are generally useless in Modula-3, and the= >refore extern __cdecl is fairly rare, it DOES occur when you write little h= >elpers in C, such as for errno.
> 
>A good /heuristic/ might be to change the default in any directory that has= > no c_source.
>But it is only heuristic.
> 
>Whatever is done here, some allowance should probably be made for multiple = >calling conventions in the same file.
>Switching the default to the overwhelming majority and then annotating the = >minority is reasonable.
> 
>I still believe that silently ignoring calling conventions on all but NT386= > is VERY reasonable, and that no other platform from here on out will ever = >have calling conventions. Esp. not with the same names. When OS/FOO has the= > FOOAPI calling convention, you can just ignore that one on all but target = >OS/FOO. Just as all but NT386 ignore WINAPI. Yes this COULD possibly get ug= >ly something like:
><*EXTERN FOOAPI WINAPI*> fopen();
>FOOAPI for OS/FOO, WINAPI ignored.
>WINAPI for NT386, FOOAPI ignored.
>The One True Calling Convention for all others, calling convention ignored.= >
> 
>I really believe this is highly highly unlikely to occur, and it is not a t= >errible outcome, and this bridge could be crossed in the far off future.> >The functions that are usually in need of calling conventions are usually o= >nly present on one system.
>Perhaps ODBC is an extremely rare anomaly and the whole issue is nearly non= >existant.
>That could be also.
>A change just for ODBC is probably not the best, though it is a very small = >safe harmless change (I always say that :) )
> 
> 
> - Jay

> >
>
>> CC: jayk123 at hotmail.com; m3devel at elegosoft.com
> From: hosking at c= >s.purdue.edu
> Subject: Re: [M3devel] "target specific pragmas"?
&= >gt; Date: Mon, 11 Feb 2008 21:08:46 -0500
> To: darko at darko.org
&g= >t;
> Indeed!
>
> On Feb 11, 2008, at 8:37 PM, Darko wro= >te:
>
> > I think it's not a good idea. I think all platfor= >m specific code
> > should be in a separate file. I'd also like t= >o see an option to
> > move calling conventions to the makefile r= >ather than in pramas to
> > avoid having to duplicate interface f= >iles just to have a different
> > calling convention for a differ= >ent platform.
> >
> > - Darko
> >
> >R>> > On 12/02/2008, at 12:21 PM, Jay wrote:
> >
> >= >;> So I have NOT thought this through.
> >>
> >>= > I wonder if "preprocessing" dependent only on "target" is a good
> = >>> idea.
> >>
> >> Something like either the = >ability to prefix pragmas with a target,
> >> or an "iftarget"= > and "ifnottarget" pragma.
> >>
> >> Something like= > so:
> >>
> >> <* IF_TARGET NT386 *>
> = >>> <* END_IF_TARGET*>
> >>
> >>
>= > >> <* IF_TARGET NT386 *>
> >> <* END_IF_TARGET*= >>
> >> It's a small can of worms.
> >> Where can= > they be placed? Only at "global" scope? (ie: toplevel in
> >>= > an interface/module).
> >>
> >> What about IF_OSTY= >PE?
> >> What about expressions?
> >> IF_TARGET NT3= >86 OR NTAMD64
> >>
> >> IF_TARGET STARTS(NT)
>= >; >>
> >> etc.
> >>
> >> I don't = >really have enough interest here to work through this,
> >> ju= >st sending out the bait...
> >>
> >> Obviously this= > was triggered by my happening into the odbc
> >> directory an= >d bringing up ignoring WINAPI on non-NT386 or
> >> prefixing c= >alling conventions with a target.
> >>
> >> This re= >minds me of an important point here however -- nobody else
> >>= >; is going to make the mistake of ever having multiple calling
> >= >;> conventions. Therefore the generality of prefixing WINAPI with
&g= >t; >> NT386: is useless.
> >> Unless Mac68K support is ad= >ded.
> >>
> >> And here is some rationale even. The= > PC and Mac evolved from
> >> "small" systems, where assembly = >programming was common, more
> >> people knew more lower level= > details and playing games with
> >> calling conventions was s= >omething anyone could do. Most other
> >> current systems are = >rooted in C programming. Working in C, calling
> >> convention= >s are generally in a hidden layer below what anyone
> >> think= >s about. Therefore, the smaller number of capable people
> >> = >working at that level have the good sense to only have one calling
>= > >> convention. No more systems will evolve from "small", at least no= >t
> >> without having observed this history. Therefore, there = >will no
> >> longer be multiple calling conventions.
> &= >gt;>
> >> That is my theory at least.
> >>
&g= >t; >> Oh, Windows does also have __thiscall and __clrcall. __thiscall= > is
> >> only x86
>


Climb to the top= > of the charts!=A0Play the word scramble challenge with star power. =3D'http://club.live.com/star_shuffle.aspx?icid=3Dstarshuffle_wlmailtextlin= >k_jan' target=3D'_new'>Play now! >= > >--_8b04f633-e2a4-411d-940a-739ab79b0616_-- From jayk123 at hotmail.com Tue Feb 12 14:18:18 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 12 Feb 2008 13:18:18 +0000 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <200802121256.m1CCu2ct089960@camembert.async.caltech.edu> References: Your message of "Tue, 12 Feb 2008 11:50:00 GMT." <200802121256.m1CCu2ct089960@camembert.async.caltech.edu> Message-ID: Mika, I'm not going to change the default calling convention. Don't worry. At "best", try it out, measure it, and then provide pragmas/command line switches if folks want largescale change, but never by default, and even command line switch could be dangerous..the safe form is it'd only affect implemented implementation in a directory with a particular m3makefile directive, it would not affect imported implementations. And this is way way way down any nonexistant list.. Probably more interesting than more efficient but "canonical" calling conventions is "whole program optimization" like cross "module (source file) inlining, custom calling conventions, cross function constant propagation, etc. Stuff all left to gcc. :) Moving to AMD64 will make this go away quite nicely. - Jay > To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] "target specific pragmas"? > Date: Tue, 12 Feb 2008 04:56:02 -0800> From: mika at async.caltech.edu> > > Can you just generate the Modula-3 code you want using a Python> script or COBOL or whatever you like instead of trying to foist> preprocessing nastiness on innocent users of high-level Modula-3?> > Preprocessing is super nasty. It's not just a question of human> readability. m3tk has to be able to read the code, too. I should> be able to write a program that reads in (using m3tk) an arbitrary> Modula-3 interface and understands it to the point that it can> generate Network Object stubs, inter-language call stubs, etc. The> stubs should ALSO be human- and m3tk-readable after the transformation!> This should work even if the programmer has been very "clever" in> his use of Modula-3 constructs. (Just try getting something like> that to work with C or C++... it's hopeless once the preprocessor> gets involved, and possibly before.)> > Also if I may make a little request, if at all possible, please try> not to break binary compatibility with gcc-compiled C and Fortran> on NT386GNU (not sure if your ideas about calling conventions could> possibly do that...)> > Mika> > Jay writes:> >--_8b04f633-e2a4-411d-940a-739ab79b0616_> >Content-Type: text/plain; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >I insist that it depends.> >Putting every platform-specific piece of code in its own file/directory can=> > lead to mass duplication of nearly identical code.> >Sometimes an #if here or there goes very far in /improving/ code maintainab=> >ility.> >A lot of #if here there and everywhere of course can have the opposite effe=> >ct.> >And I realize if you were to drop support for a target, it is easier to fin=> >d/delete files/directories than #ifs, but I don't think that's a good enoug=> >h reason to sway the decision.> >It goes both ways.> >=20> >Yes, you could endeavor factor things down so that everything common is in => >common, and everything not-common is in platform-specific. But this is inad=> >equate I think. The tail is wagging the dog unnecessarily I think. If my co=> >de very nearly all goes together, don't make me separate it. Also sometimes=> > a different factoring is "encouraged" for other reasons, to match someone => >else's factoring. Look at the C*.i3 files. They actually can be almost all => >be nearly the same, yet they are hardly shared at all. I realize you could => >also do a sort of "forwarding", though I'm not sure that Modula-3 offers al=> >l the right capabilities for this. Type forwarding, sure. But how about pro=> >cedure forwarding? Like nt386\cstdio.i3 fopen =3D common\ccommonstdio.i3 fo=> >pen? And having to duplicate a line per type/procedure is lame anyway, you => >KIND OF want "module inheritance". However, if you allow preprocessing base=> >d on target, perhaps the need for that goes away.> >=20> >While extern C varargs functions are generally useless in Modula-3, and the=> >refore extern __cdecl is fairly rare, it DOES occur when you write little h=> >elpers in C, such as for errno.> >=20> >A good /heuristic/ might be to change the default in any directory that has=> > no c_source.> >But it is only heuristic.> >=20> >Whatever is done here, some allowance should probably be made for multiple => >calling conventions in the same file.> >Switching the default to the overwhelming majority and then annotating the => >minority is reasonable.> >=20> >I still believe that silently ignoring calling conventions on all but NT386=> > is VERY reasonable, and that no other platform from here on out will ever => >have calling conventions. Esp. not with the same names. When OS/FOO has the=> > FOOAPI calling convention, you can just ignore that one on all but target => >OS/FOO. Just as all but NT386 ignore WINAPI. Yes this COULD possibly get ug=> >ly something like:> ><*EXTERN FOOAPI WINAPI*> fopen();> >FOOAPI for OS/FOO, WINAPI ignored.> >WINAPI for NT386, FOOAPI ignored.> >The One True Calling Convention for all others, calling convention ignored.> >=20> >I really believe this is highly highly unlikely to occur, and it is not a t=> >errible outcome, and this bridge could be crossed in the far off future.> >The functions that are usually in need of calling conventions are usually o=> >nly present on one system.> >Perhaps ODBC is an extremely rare anomaly and the whole issue is nearly non=> >existant.> >That could be also.> >A change just for ODBC is probably not the best, though it is a very small => >safe harmless change (I always say that :) )> >=20> >=20> > - Jay> >> >> >> >> CC: jayk123 at hotmail.com; m3devel at elegosoft.com> From: hosking at cs.purdue.e=> >du> Subject: Re: [M3devel] "target specific pragmas"?> Date: Mon, 11 Feb 20=> >08 21:08:46 -0500> To: darko at darko.org> > Indeed!> > On Feb 11, 2008, at 8:=> >37 PM, Darko wrote:> > > I think it's not a good idea. I think all platform=> > specific code > > should be in a separate file. I'd also like to see an op=> >tion to > > move calling conventions to the makefile rather than in pramas => >to > > avoid having to duplicate interface files just to have a different >=> > > calling convention for a different platform.> >> > - Darko> >> >> > On 1=> >2/02/2008, at 12:21 PM, Jay wrote:> >> >> So I have NOT thought this throug=> >h.> >>> >> I wonder if "preprocessing" dependent only on "target" is a good=> > > >> idea.> >>> >> Something like either the ability to prefix pragmas wit=> >h a target, > >> or an "iftarget" and "ifnottarget" pragma.> >>> >> Somethi=> >ng like so:> >>> >> <* IF_TARGET NT386 *>> >> <* END_IF_TARGET*>> >>> >>> >=> >> <* IF_TARGET NT386 *>> >> <* END_IF_TARGET*>> >> It's a small can of worm=> >s.> >> Where can they be placed? Only at "global" scope? (ie: toplevel in >=> > >> an interface/module).> >>> >> What about IF_OSTYPE?> >> What about expr=> >essions?> >> IF_TARGET NT386 OR NTAMD64> >>> >> IF_TARGET STARTS(NT)> >>> >=> >> etc.> >>> >> I don't really have enough interest here to work through thi=> >s, > >> just sending out the bait...> >>> >> Obviously this was triggered b=> >y my happening into the odbc > >> directory and bringing up ignoring WINAPI=> > on non-NT386 or > >> prefixing calling conventions with a target.> >>> >> => >This reminds me of an important point here however -- nobody else > >> is g=> >oing to make the mistake of ever having multiple calling > >> conventions. => >Therefore the generality of prefixing WINAPI with > >> NT386: is useless.> => >>> Unless Mac68K support is added.> >>> >> And here is some rationale even.=> > The PC and Mac evolved from > >> "small" systems, where assembly programmi=> >ng was common, more > >> people knew more lower level details and playing g=> >ames with > >> calling conventions was something anyone could do. Most othe=> >r > >> current systems are rooted in C programming. Working in C, calling >=> > >> conventions are generally in a hidden layer below what anyone > >> thin=> >ks about. Therefore, the smaller number of capable people > >> working at t=> >hat level have the good sense to only have one calling > >> convention. No => >more systems will evolve from "small", at least not > >> without having obs=> >erved this history. Therefore, there will no > >> longer be multiple callin=> >g conventions.> >>> >> That is my theory at least.> >>> >> Oh, Windows does=> > also have __thiscall and __clrcall. __thiscall is > >> only x86>=20> >_________________________________________________________________> >Climb to the top of the charts!=A0Play the word scramble challenge with sta=> >r power.> >http://club.live.com/star_shuffle.aspx?icid=3Dstarshuffle_wlmailtextlink_ja=> >n=> >> >--_8b04f633-e2a4-411d-940a-739ab79b0616_> >Content-Type: text/html; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >> >> >> >> >I insist that it depends.
> >Putting every platform-specific piece of code in its own file/directory can=> > lead to mass duplication of nearly identical code.
> >Sometimes an #if here or there goes very far in /improving/ code maintainab=> >ility.
> >A lot of #if here there and everywhere of course can have the opposite effe=> >ct.
> >And I realize if you were to drop support for a target, it is easier to fin=> >d/delete files/directories than #ifs, but I don't think that's a good enoug=> >h reason to sway the decision.
> >It goes both ways.
> > 
> >Yes, you could endeavor factor things down so that everything common i=> >s in common, and everything not-common is in platform-specific. But this is=> > inadequate I think. The tail is wagging the dog unnecessarily I think. If => >my code very nearly all goes together, don't make me separate it. => >;Also sometimes a different factoring is "encouraged" for other reasons, to=> > match someone else's factoring. Look at the C*.i3 files. They actually can=> > be almost all be nearly the same, yet they are hardly shared at all. I rea=> >lize you could also do a sort of "forwarding", though I'm not sure that Mod=> >ula-3 offers all the right capabilities for this. Type forwarding, sure. Bu=> >t how about procedure forwarding? Like nt386\cstdio.i3 fopen =3D common\cco=> >mmonstdio.i3 fopen? And having to duplicate a line per type/procedure is la=> >me anyway, you KIND OF want "module inheritance". However, if you allow pre=> >processing based on target, perhaps the need for that goes away.
> > 
> >While extern C varargs functions are generally useless in Modula-3, and the=> >refore extern __cdecl is fairly rare, it DOES occur when you write little h=> >elpers in C, such as for errno.
> > 
> >A good /heuristic/ might be to change the default in any directory that has=> > no c_source.
> >But it is only heuristic.
> > 
> >Whatever is done here, some allowance should probably be made for multiple => >calling conventions in the same file.
> >Switching the default to the overwhelming majority and then annotating the => >minority is reasonable.
> > 
> >I still believe that silently ignoring calling conventions on all but NT386=> > is VERY reasonable, and that no other platform from here on out will ever => >have calling conventions. Esp. not with the same names. When OS/FOO has the=> > FOOAPI calling convention, you can just ignore that one on all but target => >OS/FOO. Just as all but NT386 ignore WINAPI. Yes this COULD possibly get ug=> >ly something like:
> ><*EXTERN FOOAPI WINAPI*> fopen();
> >FOOAPI for OS/FOO, WINAPI ignored.
> >WINAPI for NT386, FOOAPI ignored.
> >The One True Calling Convention for all others, calling convention ignored.=> >
> > 
> >I really believe this is highly highly unlikely to occur, and it is not a t=> >errible outcome, and this bridge could be crossed in the far off future. >>> >The functions that are usually in need of calling conventions are usually o=> >nly present on one system.
> >Perhaps ODBC is an extremely rare anomaly and the whole issue is nearly non=> >existant.
> >That could be also.
> >A change just for ODBC is probably not the best, though it is a very small => >safe harmless change (I always say that :) )
> > 
> > 
> > - Jay

> >> >
> >
> >> CC: jayk123 at hotmail.com; m3devel at elegosoft.com
> From: hosking at c=> >s.purdue.edu
> Subject: Re: [M3devel] "target specific pragmas"?
&=> >gt; Date: Mon, 11 Feb 2008 21:08:46 -0500
> To: darko at darko.org
&g=> >t;
> Indeed!
>
> On Feb 11, 2008, at 8:37 PM, Darko wro=> >te:
>
> > I think it's not a good idea. I think all platfor=> >m specific code
> > should be in a separate file. I'd also like t=> >o see an option to
> > move calling conventions to the makefile r=> >ather than in pramas to
> > avoid having to duplicate interface f=> >iles just to have a different
> > calling convention for a differ=> >ent platform.
> >
> > - Darko
> >
> > >R>> > On 12/02/2008, at 12:21 PM, Jay wrote:
> >
> >=> >;> So I have NOT thought this through.
> >>
> >>=> > I wonder if "preprocessing" dependent only on "target" is a good
> => >>> idea.
> >>
> >> Something like either the => >ability to prefix pragmas with a target,
> >> or an "iftarget"=> > and "ifnottarget" pragma.
> >>
> >> Something like=> > so:
> >>
> >> <* IF_TARGET NT386 *>
> => >>> <* END_IF_TARGET*>
> >>
> >>
>=> > >> <* IF_TARGET NT386 *>
> >> <* END_IF_TARGET*=> >>
> >> It's a small can of worms.
> >> Where can=> > they be placed? Only at "global" scope? (ie: toplevel in
> >>=> > an interface/module).
> >>
> >> What about IF_OSTY=> >PE?
> >> What about expressions?
> >> IF_TARGET NT3=> >86 OR NTAMD64
> >>
> >> IF_TARGET STARTS(NT)
>=> >; >>
> >> etc.
> >>
> >> I don't => >really have enough interest here to work through this,
> >> ju=> >st sending out the bait...
> >>
> >> Obviously this=> > was triggered by my happening into the odbc
> >> directory an=> >d bringing up ignoring WINAPI on non-NT386 or
> >> prefixing c=> >alling conventions with a target.
> >>
> >> This re=> >minds me of an important point here however -- nobody else
> >>=> >; is going to make the mistake of ever having multiple calling
> >=> >;> conventions. Therefore the generality of prefixing WINAPI with
&g=> >t; >> NT386: is useless.
> >> Unless Mac68K support is ad=> >ded.
> >>
> >> And here is some rationale even. The=> > PC and Mac evolved from
> >> "small" systems, where assembly => >programming was common, more
> >> people knew more lower level=> > details and playing games with
> >> calling conventions was s=> >omething anyone could do. Most other
> >> current systems are => >rooted in C programming. Working in C, calling
> >> convention=> >s are generally in a hidden layer below what anyone
> >> think=> >s about. Therefore, the smaller number of capable people
> >> => >working at that level have the good sense to only have one calling
>=> > >> convention. No more systems will evolve from "small", at least no=> >t
> >> without having observed this history. Therefore, there => >will no
> >> longer be multiple calling conventions.
> &=> >gt;>
> >> That is my theory at least.
> >>
&g=> >t; >> Oh, Windows does also have __thiscall and __clrcall. __thiscall=> > is
> >> only x86
>


Climb to the top=> > of the charts!=A0Play the word scramble challenge with star power. >=3D'http://club.live.com/star_shuffle.aspx?icid=3Dstarshuffle_wlmailtextlin=> >k_jan' target=3D'_new'>Play now!> >=> >> >--_8b04f633-e2a4-411d-940a-739ab79b0616_-- _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Tue Feb 12 14:23:26 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 12 Feb 2008 08:23:26 -0500 Subject: [M3devel] introducing VAR in more places? In-Reply-To: <47B11DC9.1040902@wichita.edu> References: <20080211092401.1068410D466B@birch.elegosoft.com> <400989C4-C086-4F4C-866C-A83F8854B34F@cs.purdue.edu> <47B11DC9.1040902@wichita.edu> Message-ID: <20080212132326.GA22149@topoi.pooq.com> On Mon, Feb 11, 2008 at 10:17:13PM -0600, Rodney M. Bates wrote: > I don't think this is what Tony meant. In C++, an opening brace > starts a block, but every local declaration in that block has its own > unique scope that only starts at that declaration and goes to the end > of the block. This is particularly messy because the local declarations > of a block need not all precede all the statements, That is, in my opinion, one of the few things that C and C++ did right, well, almost right. It permits a coding style in which every variable declaration is initialised, and is declared if and only if it has a value. Now that's a useful property. It fails for recursion, so there are limits in how far it can apply. And when coding like this, you want the simplest syntax to define a constant identifier -- one whose value cannot be rebound except by reexecuting the entire block. Making something that can change should require more effort -- like adding a keyword "var" or some such. It's amazing how many identifiers end up fitting this constraint, yielding very little visual ambiguity as to whether the value of a variable has changed since initialisation. This tends to be the style in functional languages. In my opinion, functional-style languages would benefit from detailed static typing (as detailed as Modula 3) and some imperative features, like assignment to things that are explicitly declared as being variable. While rarely needed (but usually at least a few times per program), doing completely without imperative features I consider an exercise in masochism. But I can't see any way that this would fit seamlessly into Modula 3 syntax. -- hendrik > and even worse > because the distinction between declarations and statements is extremely > subtle and, unless things have changed, never actually defined. > > (Do you remember Stroustrup's famous quote when taken to task about this? > "If it looks like a declaration, it's a declaration. If it looks like a > statement, it's a statement. If it doesn't look like either, it's a > syntax error.") Last time I looked at it (when I was involved in a C++ implementation a decade or more ago) the rule was "If it looks like a declaration, it's a declaration; *otherwise* if it looks like a statement, it's a statement.", with precise constraints on what contextual information the compiler was allowed to look at when deciding what it looked like. The only correct way I found to implement this was to parse every statement-declaration-like thing first as a declaration, and, if that failed, as a statement. It was a mess. -- hendrik > In contrast, in Modula-3, the scope of every local declaration > starts at the beginning of the block and ends at the end of the > block. A simple rule, but, in my opinion, a little too simple. > > The C++ reference makes an attempt at defining different terms for the > entire block and the region where the identifier can be referred-to, i.e., > from declaration to end of block (which I have called "scope" here). > But as I recall, they ended up carefully defining their terminology in > one section but then not using it consistently in the rest of the > language definition. Their heart wasn't really into it, was it? Much rather let the implementation define the language. -- hendrik From mika at async.caltech.edu Tue Feb 12 14:41:31 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 12 Feb 2008 05:41:31 -0800 Subject: [M3devel] introducing VAR in more places? In-Reply-To: Your message of "Tue, 12 Feb 2008 08:23:26 EST." <20080212132326.GA22149@topoi.pooq.com> Message-ID: <200802121341.m1CDfVoZ091241@camembert.async.caltech.edu> hendrik at topoi.pooq.com writes: >On Mon, Feb 11, 2008 at 10:17:13PM -0600, Rodney M. Bates wrote: >> I don't think this is what Tony meant. In C++, an opening brace >> starts a block, but every local declaration in that block has its own >> unique scope that only starts at that declaration and goes to the end >> of the block. This is particularly messy because the local declarations >> of a block need not all precede all the statements, > >That is, in my opinion, one of the few things that C and C++ did right, >well, almost right. It permits a coding style in which every >variable declaration is initialised, and is declared if and only if it You can do all kinds of fun stuff with C's declarations/initializations. switch (a) { int x=7; case 0: use(x); /* oops */ ... } goto somewherefun; { int y=7; somewherefun: use(y); /* oops again */ } >has a value. Now that's a useful property. It fails for recursion, >so there are limits in how far it can apply. And when coding like this, >you want the simplest syntax to define a constant identifier -- one >whose value cannot be rebound except by reexecuting the entire block. >Making something that can change should require more effort -- like >adding a keyword "var" or some such. Sounds to me like you're talking about Modula-3's WITH! Mika From jayk123 at hotmail.com Tue Feb 12 14:50:22 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 12 Feb 2008 13:50:22 +0000 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <200802121256.m1CCu2ct089960@camembert.async.caltech.edu> References: Your message of "Tue, 12 Feb 2008 11:50:00 GMT." <200802121256.m1CCu2ct089960@camembert.async.caltech.edu> Message-ID: Mika good point, I know that, forgot, thanks for reminding me. One of the interesting things about Modula-3, or rather anything but C and C++, is easy parsing, easy building of other tools. Just to be clear though, independent of my crazy ideas, such tools can't just enumerate a source tree. I guess they should operate over the pkg tree? You know, they can't understand the source tree without understanding m3makefiles. I started a little experiment here. I added m3-libs/m3core/src/C/common/Cstdio.i3. This is a file that ought to be nearly identical for all targets. For now I only changed NT386. I'm thinking either: a) I'm not quite on base and just fork it per-target, as it was b) provide a little bit of C code with #ifdefs, like making the SEEK_* constants into VARs and using C to initialize them. That's a bit of a downer though, since constants ought to be constants. c) factor it somehow as I was alluding, like, well, again I'm not sure Modula-3 has what I'd want here, but at least for types and constants, you can push the non-portable stuff into Ctargetstdio.i3 and then expose them in Cstdio.i3, forking only Ctargetstdio.i. I'll explain so I can get my question in. :) I understand, say: Ctargetstdio.i3 (* one of these per target, with not much content *) CONST SEEK_CUR = ..; (* target specific probably *) SEEK_SET = ..; ditto SEEK_END = ..; ditto TYPE FOO = ... ditto Cstdio.i3 (* portable *) CONST SEEK_CUR = Ctargetstdio.SEEK_CUR; SEEK_SET = Ctargetstdio.SEEK_SET; SEEK_END = Ctargetstdio.SEEK_END; TYPE FOO = Ctargetstdio.FOO; FILE = UNTRACED REF RECORD END; procedure fopen(a: const_char_star; b: const_char_star): FILE; It is tedious but I believe it works. It'd be nice, I think, if every symbol in one interface could be automatically aliases/exposed in another. At least for this purpose, maybe not for any other. I'm speculating here, so please respond kindly. :) The non portable types and constants can be pushed out and then reexposed as if they were portable and in one place. However, let's say, for argument/question's sake, that some function accepts int on some targets, off_t on another. Nevermind for now how you can portably call it. Ctargetstdio.i3 (* one of these for every target, but another question in a sec ... *) PROCEDURE seeksomething(a: off_t); let's say it is int on some platforms. Cstdio.i3 (* the portable one *) seeksomething = Ctargetstdio.seeksomething; does this work? I should try it out, read the docs. But then the next question would be, let's say there's 20 platforms and 5 use off_t and 15 use int. It's unfortunate if I have to repeat the content 20 times when there are only two variants. You can see this kind of thing where sometimes we include_dir(TARGET), sometimes include_dir(OS_TYPE). OS_TYPE implies less work, nice. Perhaps concatening stuff in arbitrary way with Quake really is the way? It seems almost sarcastic, but perhaps not. As long as the pkg store is easily parsed? (There's a setting to ship implementation files. I guess that must be left on? I thought it'd be nice to reduce distribution size..) But for that matter --- could be processed by the compiler and result in a file with it already accounted for and ship that. Isn't that just as good? EXCEPT that more thought would have to go into the spec, whereas m3makefile is already a general purpose system that anyone can do anything with? ?? - Jay > To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] "target specific pragmas"? > Date: Tue, 12 Feb 2008 04:56:02 -0800> From: mika at async.caltech.edu> > > Can you just generate the Modula-3 code you want using a Python> script or COBOL or whatever you like instead of trying to foist> preprocessing nastiness on innocent users of high-level Modula-3?> > Preprocessing is super nasty. It's not just a question of human> readability. m3tk has to be able to read the code, too. I should> be able to write a program that reads in (using m3tk) an arbitrary> Modula-3 interface and understands it to the point that it can> generate Network Object stubs, inter-language call stubs, etc. The> stubs should ALSO be human- and m3tk-readable after the transformation!> This should work even if the programmer has been very "clever" in> his use of Modula-3 constructs. (Just try getting something like> that to work with C or C++... it's hopeless once the preprocessor> gets involved, and possibly before.)> > Also if I may make a little request, if at all possible, please try> not to break binary compatibility with gcc-compiled C and Fortran> on NT386GNU (not sure if your ideas about calling conventions could> possibly do that...)> > Mika> > Jay writes:> >--_8b04f633-e2a4-411d-940a-739ab79b0616_> >Content-Type: text/plain; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >I insist that it depends.> >Putting every platform-specific piece of code in its own file/directory can=> > lead to mass duplication of nearly identical code.> >Sometimes an #if here or there goes very far in /improving/ code maintainab=> >ility.> >A lot of #if here there and everywhere of course can have the opposite effe=> >ct.> >And I realize if you were to drop support for a target, it is easier to fin=> >d/delete files/directories than #ifs, but I don't think that's a good enoug=> >h reason to sway the decision.> >It goes both ways.> >=20> >Yes, you could endeavor factor things down so that everything common is in => >common, and everything not-common is in platform-specific. But this is inad=> >equate I think. The tail is wagging the dog unnecessarily I think. If my co=> >de very nearly all goes together, don't make me separate it. Also sometimes=> > a different factoring is "encouraged" for other reasons, to match someone => >else's factoring. Look at the C*.i3 files. They actually can be almost all => >be nearly the same, yet they are hardly shared at all. I realize you could => >also do a sort of "forwarding", though I'm not sure that Modula-3 offers al=> >l the right capabilities for this. Type forwarding, sure. But how about pro=> >cedure forwarding? Like nt386\cstdio.i3 fopen =3D common\ccommonstdio.i3 fo=> >pen? And having to duplicate a line per type/procedure is lame anyway, you => >KIND OF want "module inheritance". However, if you allow preprocessing base=> >d on target, perhaps the need for that goes away.> >=20> >While extern C varargs functions are generally useless in Modula-3, and the=> >refore extern __cdecl is fairly rare, it DOES occur when you write little h=> >elpers in C, such as for errno.> >=20> >A good /heuristic/ might be to change the default in any directory that has=> > no c_source.> >But it is only heuristic.> >=20> >Whatever is done here, some allowance should probably be made for multiple => >calling conventions in the same file.> >Switching the default to the overwhelming majority and then annotating the => >minority is reasonable.> >=20> >I still believe that silently ignoring calling conventions on all but NT386=> > is VERY reasonable, and that no other platform from here on out will ever => >have calling conventions. Esp. not with the same names. When OS/FOO has the=> > FOOAPI calling convention, you can just ignore that one on all but target => >OS/FOO. Just as all but NT386 ignore WINAPI. Yes this COULD possibly get ug=> >ly something like:> ><*EXTERN FOOAPI WINAPI*> fopen();> >FOOAPI for OS/FOO, WINAPI ignored.> >WINAPI for NT386, FOOAPI ignored.> >The One True Calling Convention for all others, calling convention ignored.> >=20> >I really believe this is highly highly unlikely to occur, and it is not a t=> >errible outcome, and this bridge could be crossed in the far off future.> >The functions that are usually in need of calling conventions are usually o=> >nly present on one system.> >Perhaps ODBC is an extremely rare anomaly and the whole issue is nearly non=> >existant.> >That could be also.> >A change just for ODBC is probably not the best, though it is a very small => >safe harmless change (I always say that :) )> >=20> >=20> > - Jay> >> >> >> >> CC: jayk123 at hotmail.com; m3devel at elegosoft.com> From: hosking at cs.purdue.e=> >du> Subject: Re: [M3devel] "target specific pragmas"?> Date: Mon, 11 Feb 20=> >08 21:08:46 -0500> To: darko at darko.org> > Indeed!> > On Feb 11, 2008, at 8:=> >37 PM, Darko wrote:> > > I think it's not a good idea. I think all platform=> > specific code > > should be in a separate file. I'd also like to see an op=> >tion to > > move calling conventions to the makefile rather than in pramas => >to > > avoid having to duplicate interface files just to have a different >=> > > calling convention for a different platform.> >> > - Darko> >> >> > On 1=> >2/02/2008, at 12:21 PM, Jay wrote:> >> >> So I have NOT thought this throug=> >h.> >>> >> I wonder if "preprocessing" dependent only on "target" is a good=> > > >> idea.> >>> >> Something like either the ability to prefix pragmas wit=> >h a target, > >> or an "iftarget" and "ifnottarget" pragma.> >>> >> Somethi=> >ng like so:> >>> >> <* IF_TARGET NT386 *>> >> <* END_IF_TARGET*>> >>> >>> >=> >> <* IF_TARGET NT386 *>> >> <* END_IF_TARGET*>> >> It's a small can of worm=> >s.> >> Where can they be placed? Only at "global" scope? (ie: toplevel in >=> > >> an interface/module).> >>> >> What about IF_OSTYPE?> >> What about expr=> >essions?> >> IF_TARGET NT386 OR NTAMD64> >>> >> IF_TARGET STARTS(NT)> >>> >=> >> etc.> >>> >> I don't really have enough interest here to work through thi=> >s, > >> just sending out the bait...> >>> >> Obviously this was triggered b=> >y my happening into the odbc > >> directory and bringing up ignoring WINAPI=> > on non-NT386 or > >> prefixing calling conventions with a target.> >>> >> => >This reminds me of an important point here however -- nobody else > >> is g=> >oing to make the mistake of ever having multiple calling > >> conventions. => >Therefore the generality of prefixing WINAPI with > >> NT386: is useless.> => >>> Unless Mac68K support is added.> >>> >> And here is some rationale even.=> > The PC and Mac evolved from > >> "small" systems, where assembly programmi=> >ng was common, more > >> people knew more lower level details and playing g=> >ames with > >> calling conventions was something anyone could do. Most othe=> >r > >> current systems are rooted in C programming. Working in C, calling >=> > >> conventions are generally in a hidden layer below what anyone > >> thin=> >ks about. Therefore, the smaller number of capable people > >> working at t=> >hat level have the good sense to only have one calling > >> convention. No => >more systems will evolve from "small", at least not > >> without having obs=> >erved this history. Therefore, there will no > >> longer be multiple callin=> >g conventions.> >>> >> That is my theory at least.> >>> >> Oh, Windows does=> > also have __thiscall and __clrcall. __thiscall is > >> only x86>=20> >_________________________________________________________________> >Climb to the top of the charts!=A0Play the word scramble challenge with sta=> >r power.> >http://club.live.com/star_shuffle.aspx?icid=3Dstarshuffle_wlmailtextlink_ja=> >n=> >> >--_8b04f633-e2a4-411d-940a-739ab79b0616_> >Content-Type: text/html; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >> >> >> >> >I insist that it depends.
> >Putting every platform-specific piece of code in its own file/directory can=> > lead to mass duplication of nearly identical code.
> >Sometimes an #if here or there goes very far in /improving/ code maintainab=> >ility.
> >A lot of #if here there and everywhere of course can have the opposite effe=> >ct.
> >And I realize if you were to drop support for a target, it is easier to fin=> >d/delete files/directories than #ifs, but I don't think that's a good enoug=> >h reason to sway the decision.
> >It goes both ways.
> > 
> >Yes, you could endeavor factor things down so that everything common i=> >s in common, and everything not-common is in platform-specific. But this is=> > inadequate I think. The tail is wagging the dog unnecessarily I think. If => >my code very nearly all goes together, don't make me separate it. => >;Also sometimes a different factoring is "encouraged" for other reasons, to=> > match someone else's factoring. Look at the C*.i3 files. They actually can=> > be almost all be nearly the same, yet they are hardly shared at all. I rea=> >lize you could also do a sort of "forwarding", though I'm not sure that Mod=> >ula-3 offers all the right capabilities for this. Type forwarding, sure. Bu=> >t how about procedure forwarding? Like nt386\cstdio.i3 fopen =3D common\cco=> >mmonstdio.i3 fopen? And having to duplicate a line per type/procedure is la=> >me anyway, you KIND OF want "module inheritance". However, if you allow pre=> >processing based on target, perhaps the need for that goes away.
> > 
> >While extern C varargs functions are generally useless in Modula-3, and the=> >refore extern __cdecl is fairly rare, it DOES occur when you write little h=> >elpers in C, such as for errno.
> > 
> >A good /heuristic/ might be to change the default in any directory that has=> > no c_source.
> >But it is only heuristic.
> > 
> >Whatever is done here, some allowance should probably be made for multiple => >calling conventions in the same file.
> >Switching the default to the overwhelming majority and then annotating the => >minority is reasonable.
> > 
> >I still believe that silently ignoring calling conventions on all but NT386=> > is VERY reasonable, and that no other platform from here on out will ever => >have calling conventions. Esp. not with the same names. When OS/FOO has the=> > FOOAPI calling convention, you can just ignore that one on all but target => >OS/FOO. Just as all but NT386 ignore WINAPI. Yes this COULD possibly get ug=> >ly something like:
> ><*EXTERN FOOAPI WINAPI*> fopen();
> >FOOAPI for OS/FOO, WINAPI ignored.
> >WINAPI for NT386, FOOAPI ignored.
> >The One True Calling Convention for all others, calling convention ignored.=> >
> > 
> >I really believe this is highly highly unlikely to occur, and it is not a t=> >errible outcome, and this bridge could be crossed in the far off future. >>> >The functions that are usually in need of calling conventions are usually o=> >nly present on one system.
> >Perhaps ODBC is an extremely rare anomaly and the whole issue is nearly non=> >existant.
> >That could be also.
> >A change just for ODBC is probably not the best, though it is a very small => >safe harmless change (I always say that :) )
> > 
> > 
> > - Jay

> >> >
> >
> >> CC: jayk123 at hotmail.com; m3devel at elegosoft.com
> From: hosking at c=> >s.purdue.edu
> Subject: Re: [M3devel] "target specific pragmas"?
&=> >gt; Date: Mon, 11 Feb 2008 21:08:46 -0500
> To: darko at darko.org
&g=> >t;
> Indeed!
>
> On Feb 11, 2008, at 8:37 PM, Darko wro=> >te:
>
> > I think it's not a good idea. I think all platfor=> >m specific code
> > should be in a separate file. I'd also like t=> >o see an option to
> > move calling conventions to the makefile r=> >ather than in pramas to
> > avoid having to duplicate interface f=> >iles just to have a different
> > calling convention for a differ=> >ent platform.
> >
> > - Darko
> >
> > >R>> > On 12/02/2008, at 12:21 PM, Jay wrote:
> >
> >=> >;> So I have NOT thought this through.
> >>
> >>=> > I wonder if "preprocessing" dependent only on "target" is a good
> => >>> idea.
> >>
> >> Something like either the => >ability to prefix pragmas with a target,
> >> or an "iftarget"=> > and "ifnottarget" pragma.
> >>
> >> Something like=> > so:
> >>
> >> <* IF_TARGET NT386 *>
> => >>> <* END_IF_TARGET*>
> >>
> >>
>=> > >> <* IF_TARGET NT386 *>
> >> <* END_IF_TARGET*=> >>
> >> It's a small can of worms.
> >> Where can=> > they be placed? Only at "global" scope? (ie: toplevel in
> >>=> > an interface/module).
> >>
> >> What about IF_OSTY=> >PE?
> >> What about expressions?
> >> IF_TARGET NT3=> >86 OR NTAMD64
> >>
> >> IF_TARGET STARTS(NT)
>=> >; >>
> >> etc.
> >>
> >> I don't => >really have enough interest here to work through this,
> >> ju=> >st sending out the bait...
> >>
> >> Obviously this=> > was triggered by my happening into the odbc
> >> directory an=> >d bringing up ignoring WINAPI on non-NT386 or
> >> prefixing c=> >alling conventions with a target.
> >>
> >> This re=> >minds me of an important point here however -- nobody else
> >>=> >; is going to make the mistake of ever having multiple calling
> >=> >;> conventions. Therefore the generality of prefixing WINAPI with
&g=> >t; >> NT386: is useless.
> >> Unless Mac68K support is ad=> >ded.
> >>
> >> And here is some rationale even. The=> > PC and Mac evolved from
> >> "small" systems, where assembly => >programming was common, more
> >> people knew more lower level=> > details and playing games with
> >> calling conventions was s=> >omething anyone could do. Most other
> >> current systems are => >rooted in C programming. Working in C, calling
> >> convention=> >s are generally in a hidden layer below what anyone
> >> think=> >s about. Therefore, the smaller number of capable people
> >> => >working at that level have the good sense to only have one calling
>=> > >> convention. No more systems will evolve from "small", at least no=> >t
> >> without having observed this history. Therefore, there => >will no
> >> longer be multiple calling conventions.
> &=> >gt;>
> >> That is my theory at least.
> >>
&g=> >t; >> Oh, Windows does also have __thiscall and __clrcall. __thiscall=> > is
> >> only x86
>


Climb to the top=> > of the charts!=A0Play the word scramble challenge with star power. >=3D'http://club.live.com/star_shuffle.aspx?icid=3Dstarshuffle_wlmailtextlin=> >k_jan' target=3D'_new'>Play now!> >=> >> >--_8b04f633-e2a4-411d-940a-739ab79b0616_-- _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Tue Feb 12 14:52:05 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 12 Feb 2008 08:52:05 -0500 Subject: [M3devel] introducing VAR in more places? In-Reply-To: <200802121341.m1CDfVoZ091241@camembert.async.caltech.edu> References: <20080212132326.GA22149@topoi.pooq.com> <200802121341.m1CDfVoZ091241@camembert.async.caltech.edu> Message-ID: <20080212135205.GC22149@topoi.pooq.com> On Tue, Feb 12, 2008 at 05:41:31AM -0800, Mika Nystrom wrote: > hendrik at topoi.pooq.com writes: > >On Mon, Feb 11, 2008 at 10:17:13PM -0600, Rodney M. Bates wrote: > >> I don't think this is what Tony meant. In C++, an opening brace > >> starts a block, but every local declaration in that block has its own > >> unique scope that only starts at that declaration and goes to the end > >> of the block. This is particularly messy because the local declarations > >> of a block need not all precede all the statements, > > > >That is, in my opinion, one of the few things that C and C++ did right, > >well, almost right. It permits a coding style in which every > >variable declaration is initialised, and is declared if and only if it > > You can do all kinds of fun stuff with C's declarations/initializations. > > switch (a) { > int x=7; > case 0: > use(x); /* oops */ > ... > } > > goto somewherefun; > > { > int y=7; > > somewherefun: > use(y); /* oops again */ > } That's more a problem with C's control structures. Each case should be a block of its own. The bits outside any case shouldn't be there. etc., etc. > > > >has a value. Now that's a useful property. It fails for recursion, > >so there are limits in how far it can apply. And when coding like this, > >you want the simplest syntax to define a constant identifier -- one > >whose value cannot be rebound except by reexecuting the entire block. > >Making something that can change should require more effort -- like > >adding a keyword "var" or some such. > > Sounds to me like you're talking about Modula-3's WITH! Close, except for syntax. If you use WITH in the stype I'm advocating you end up with extremely deep syntactic nesting, and you indent off the side of the page. Also, the whole WITH syntax is quite heavy. -- hendrik From jayk123 at hotmail.com Tue Feb 12 15:02:23 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 12 Feb 2008 14:02:23 +0000 Subject: [M3devel] introducing VAR in more places? In-Reply-To: <200802121341.m1CDfVoZ091241@camembert.async.caltech.edu> References: Your message of "Tue, 12 Feb 2008 08:23:26 EST." <20080212132326.GA22149@topoi.pooq.com> <200802121341.m1CDfVoZ091241@camembert.async.caltech.edu> Message-ID: C++ fixes this sort of thing. goto around initialization is an error. C++ constructors and destructors are a really good thing -- can't forgot to initialize or cleanup stuff. Very much like try/finally, but the finally code is better "positioned". Rather than special case memory with some fancy garbage collector, provide a mechanism for any type. RAII and all that. It's a very good theory at least. However I've become uncertain of it. Could be that a huge part of it is ok, if only you could train everyone in RAII and constructors/destructors. But then there are close pesky fopen/fclose/malloc/free you have to get rid of. And a lot of complexity around templates, unrelated, but can you allow C++ in a codebase but rigorously ban certain aspects? Maybe draw an analogy to Itanium. Lots of obviously good features, not even all that novel. But must we really combine them all together all at once? (register windows a la SPARC, loop unrolling a la any decent compiler..) And maybe memory is really vastly more interesting than other resources?Oh, and locks, special case those too... Mika your switch example, besides being invalid C++, is just not fair. I don't think people even think to write their code like that. Introducing variables at the top of a switch is rare, esp. initializing them. That C allows variables declared anywhere, and open braces anywhere, seems little known and little taken advantage of. Everyone just moves all the locals to the top, and either programmers do careful static flow analysis, or "lazily" (but reasonably) "over initialize" things, like maybe to 0 or { 0 }. C++ is what really fixes this properly and people know and understand it. Declare stuff anywhere, closest to first, use, and preferably initialized or a user defined type with a constructor. EXCEPT that it doesn't play nicely with goto, and if you aren't using exceptions, then goto is the next best thing...so then you are forced into something closer to the C style, though you gain constructors to help some. And hopefully the compiler can optimize away a lot of the unnecessary initialization... Java and I presume C# have a nice feature here too where they require the compiler to error for use of uninitialized variables, though I suspect the specced algorithm misses some things, like: if (...) initialize x common code if (same thing) use x <== possible use of uninitialize x, not At least I've seen other tools (not Java/C# compilers, I don't use those) get confused by this.. - Jay > To: hendrik at topoi.pooq.com> Date: Tue, 12 Feb 2008 05:41:31 -0800> From: mika at async.caltech.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] introducing VAR in more places?> > hendrik at topoi.pooq.com writes:> >On Mon, Feb 11, 2008 at 10:17:13PM -0600, Rodney M. Bates wrote:> >> I don't think this is what Tony meant. In C++, an opening brace> >> starts a block, but every local declaration in that block has its own> >> unique scope that only starts at that declaration and goes to the end> >> of the block. This is particularly messy because the local declarations> >> of a block need not all precede all the statements,> >> >That is, in my opinion, one of the few things that C and C++ did right, > >well, almost right. It permits a coding style in which every > >variable declaration is initialised, and is declared if and only if it > > You can do all kinds of fun stuff with C's declarations/initializations.> > switch (a) {> int x=7;> case 0:> use(x); /* oops */> ...> }> > goto somewherefun;> > {> int y=7;> > somewherefun:> use(y); /* oops again */> }> > > >has a value. Now that's a useful property. It fails for recursion, > >so there are limits in how far it can apply. And when coding like this, > >you want the simplest syntax to define a constant identifier -- one > >whose value cannot be rebound except by reexecuting the entire block. > >Making something that can change should require more effort -- like > >adding a keyword "var" or some such.> > Sounds to me like you're talking about Modula-3's WITH!> > Mika _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Feb 12 15:05:46 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 12 Feb 2008 14:05:46 +0000 Subject: [M3devel] introducing VAR in more places? In-Reply-To: <20080212135205.GC22149@topoi.pooq.com> References: <20080212132326.GA22149@topoi.pooq.com> <200802121341.m1CDfVoZ091241@camembert.async.caltech.edu> <20080212135205.GC22149@topoi.pooq.com> Message-ID: Agreed! C++ vs. WITH, C++ wins by not indenting unnecessarily. See that change I was fiddling with in Time.m3 for examle. Hm. Can we get consensus on a language change? :) BEGIN VAR a := 1; IO.PutInt(a); VAR b := 2, (* ? *) c := 3; (* ? *) IO.PutInt(b); ? Easier to require "VAR" on each, a bit wordy. - Jay > Date: Tue, 12 Feb 2008 08:52:05 -0500> From: hendrik at topoi.pooq.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] introducing VAR in more places?> > On Tue, Feb 12, 2008 at 05:41:31AM -0800, Mika Nystrom wrote:> > hendrik at topoi.pooq.com writes:> > >On Mon, Feb 11, 2008 at 10:17:13PM -0600, Rodney M. Bates wrote:> > >> I don't think this is what Tony meant. In C++, an opening brace> > >> starts a block, but every local declaration in that block has its own> > >> unique scope that only starts at that declaration and goes to the end> > >> of the block. This is particularly messy because the local declarations> > >> of a block need not all precede all the statements,> > >> > >That is, in my opinion, one of the few things that C and C++ did right, > > >well, almost right. It permits a coding style in which every > > >variable declaration is initialised, and is declared if and only if it > > > > You can do all kinds of fun stuff with C's declarations/initializations.> > > > switch (a) {> > int x=7;> > case 0:> > use(x); /* oops */> > ...> > }> > > > goto somewherefun;> > > > {> > int y=7;> > > > somewherefun:> > use(y); /* oops again */> > }> > That's more a problem with C's control structures. Each case should be > a block of its own. The bits outside any case shouldn't be there. > etc., etc.> > > > > > > >has a value. Now that's a useful property. It fails for recursion, > > >so there are limits in how far it can apply. And when coding like this, > > >you want the simplest syntax to define a constant identifier -- one > > >whose value cannot be rebound except by reexecuting the entire block. > > >Making something that can change should require more effort -- like > > >adding a keyword "var" or some such.> > > > Sounds to me like you're talking about Modula-3's WITH!> > Close, except for syntax. If you use WITH in the stype I'm > advocating you end up with extremely deep syntactic nesting, and you > indent off the side of the page. Also, the whole WITH syntax is quite > heavy.> > -- hendrik _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Feb 12 16:57:25 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 12 Feb 2008 15:57:25 +0000 Subject: [M3devel] utime.i3 and imported data Message-ID: For good reason, imported (dynamically linked) data doesn't work great on Win32. Functions work much better. Data can work, but you generally need the header to say __declspec(dllimport), to change it to a declaration of a pointer. I've seen GNU ld has some workaround but I'm not familiar with it, it doesn't worthwhile to me, and I'm having a problem. I strongly suggest all the Utime.i3: <*EXTERNAL*> VAR timezone: time_t;<*EXTERNAL*> VAR daylight: int;<*EXTERNAL*> VAR tzname: ARRAY [0..1] OF char_star; be changed to functions: <*EXTERNAL Utime__get_timezone*> get_timezone(): time_t;<*EXTERNAL Utime__get_daylight*> get_daylight(): int;<*EXTERNAL Utime__get_tzname*> get_tzname(a: [0..1]): char_star; with an implementation in C: UtimeC.c#include time_t Utime__get_timezone(void){ return timezone;} int Utime__get_daylight(void){ return daylight;} char* Utime__get_tzname(unsigned a){ return tzname[a];} for now I'm going to try another workaround..where NT386GNU has this data as not external and some C code to call tzset and then copy the data from the C globals to Modula-3 globals. The datetime feature I added to Quake is crashing, I think due to this... - Jay _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Feb 12 17:27:38 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 12 Feb 2008 16:27:38 +0000 Subject: [M3devel] utime.i3 and imported data In-Reply-To: References: Message-ID: sorry, still not a bad idea, but not where my crash is. I wasn't paying close enough attention. Those aren't used on NT386GNU. The crash is probably here: C:\dev2\cm3.2\m3-libs\m3core\src\time\posix\DateBsd.m3(47): date.zone := M3toC.CopyStoT (tm.tm_zone); I don't know why yet. (meta reason -- these time formats aren't worthwhile even if forward slashes in paths and X Windows are....) - Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Tue, 12 Feb 2008 15:57:25 +0000Subject: [M3devel] utime.i3 and imported data For good reason, imported (dynamically linked) data doesn't work great on Win32.Functions work much better. Data can work, but you generally need the header to say __declspec(dllimport), to change it to a declaration of a pointer. I've seen GNU ld has some workaround but I'm not familiar with it, it doesn't worthwhile to me, and I'm having a problem. I strongly suggest all the Utime.i3: <*EXTERNAL*> VAR timezone: time_t;<*EXTERNAL*> VAR daylight: int;<*EXTERNAL*> VAR tzname: ARRAY [0..1] OF char_star;be changed to functions: <*EXTERNAL Utime__get_timezone*> get_timezone(): time_t;<*EXTERNAL Utime__get_daylight*> get_daylight(): int;<*EXTERNAL Utime__get_tzname*> get_tzname(a: [0..1]): char_star; with an implementation in C: UtimeC.c#include time_t Utime__get_timezone(void){ return timezone;} int Utime__get_daylight(void){ return daylight;} char* Utime__get_tzname(unsigned a){ return tzname[a];}for now I'm going to try another workaround..where NT386GNU has this data as not external and some C code to call tzset and then copy the data from the C globals to Modula-3 globals. The datetime feature I added to Quake is crashing, I think due to this... - Jay Shed those extra pounds with MSN and The Biggest Loser! Learn more. _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Feb 12 18:07:24 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 12 Feb 2008 17:07:24 +0000 Subject: [M3devel] utime.i3 and imported data In-Reply-To: References: Message-ID: well..we were accessing fields at the end of struct tm that aren't there..switched from DateBsd to DateLinux and now my exact first proposal stands. :) I worked around but it is lame, imho more lame than my suggestion. My suggestion still imports/shares the data, just via a C function call, so that the right declarations are present. The right declarations are..difficult in Modula-3. You'd have to declare the variables as pointers and change their name, and then somehow either layer portable code over that, or fork DateBsd/DateLinux to DateCygwin..which I just don't think is worth it. I don't like per-platform forks, too much duplicity, too much multiplication out of code, too much code, too much cruft, too little maintenance.... better to merge stuff if it isn't a mess and have less overall source code to maintain.... - Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comSubject: RE: [M3devel] utime.i3 and imported dataDate: Tue, 12 Feb 2008 16:27:38 +0000 sorry, still not a bad idea, but not where my crash is.I wasn't paying close enough attention. Those aren't used on NT386GNU.The crash is probably here: C:\dev2\cm3.2\m3-libs\m3core\src\time\posix\DateBsd.m3(47): date.zone := M3toC.CopyStoT (tm.tm_zone);I don't know why yet. (meta reason -- these time formats aren't worthwhile even if forward slashes in paths and X Windows are....) - Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Tue, 12 Feb 2008 15:57:25 +0000Subject: [M3devel] utime.i3 and imported data For good reason, imported (dynamically linked) data doesn't work great on Win32.Functions work much better. Data can work, but you generally need the header to say __declspec(dllimport), to change it to a declaration of a pointer. I've seen GNU ld has some workaround but I'm not familiar with it, it doesn't worthwhile to me, and I'm having a problem. I strongly suggest all the Utime.i3: <*EXTERNAL*> VAR timezone: time_t;<*EXTERNAL*> VAR daylight: int;<*EXTERNAL*> VAR tzname: ARRAY [0..1] OF char_star;be changed to functions: <*EXTERNAL Utime__get_timezone*> get_timezone(): time_t;<*EXTERNAL Utime__get_daylight*> get_daylight(): int;<*EXTERNAL Utime__get_tzname*> get_tzname(a: [0..1]): char_star; with an implementation in C: UtimeC.c#include time_t Utime__get_timezone(void){ return timezone;} int Utime__get_daylight(void){ return daylight;} char* Utime__get_tzname(unsigned a){ return tzname[a];}for now I'm going to try another workaround..where NT386GNU has this data as not external and some C code to call tzset and then copy the data from the C globals to Modula-3 globals. The datetime feature I added to Quake is crashing, I think due to this... - Jay Shed those extra pounds with MSN and The Biggest Loser! Learn more. Helping your favorite cause is as easy as instant messaging. You IM, we give. Learn more. _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Feb 12 18:21:15 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 12 Feb 2008 17:21:15 +0000 Subject: [M3devel] externs in modules instead of interfaces? In-Reply-To: References: Message-ID: I think I just said this over the weekend, but really, I should be able to put in modules and not be forced to put them in an interface. Look at the cygwin Utime.i3/m3/C.c for example... Yeah, it's a workaround, that I'd like to remove, but it could easily represent a non-workaround.. There's no real "interface/module" here, it's just that I wrote some of the code in C. sorry to be such an annoying whiner..but I ran into this multiple times over a short span of time... - Jay _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Feb 12 18:26:24 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 12 Feb 2008 12:26:24 -0500 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> Message-ID: Jay, Modula-3 has a perfectly good way of saying what you want as PACKED types. Whether they are fully implemented or not is another question. -- Tony On Feb 12, 2008, at 6:34 AM, Jay wrote: > I strongly suggest that at least in some contexts, no padding ever > be quietly inserted, and that all seeming need for padding generate > an error, unless explicitly quashed, preferably by explicit > insertion of padding fields by the programmer, and/or rearrangement > sorted by size, or possibly some annotation of the overall struct/ > record/class/module, an annotation such as <* silent padding ok*>. > Alignment issues really bug me... > I realize many data structures are only ever seen in memory, by one > process, so it doesn't matter, but when it matter, the languages/ > tools seem to fall down. > As well, "padding" fields should be annotated as such and the > compiler warn or error if they aren't needed. > > It's just dumb that code like: > > struct > { > int32 a; > int64 b; > }; > > when defining some stable important binary layout can have a > varying but silently allowed meaning based on command line switches > or targets.. Yes, I'm a dumb programmer to write it, but man the > tools are lagging. > > This will fall on deaf ears and far from sufficient ears even if > they were hearing. > It's the C compilers that are somewhat broken here imho. > C is unnecessarily broken here. Imho it's a big cause for headaches > and easily solved....it doesn't have to stink so badly, if anyone > cared.. > > I have had to maintain structs that had to look the same across > different targets and therefore insert target-dependent padding. > Ok, but it should have been easier. When I was done, I put in > compile time asserts as to the offset of every single field so the > next guy would have an easier time, and assiduously commented every > byte of padding in the struct and its target-dependentness.... > This was like for shared memory. > > Grumble, > - Jay > > > > > From: darko at darko.org > > To: rodney.bates at wichita.edu > > Date: Tue, 12 Feb 2008 15:37:52 +1100 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] <*LAZYALIGN*> > > > > That's not quite right. Certain Mac API structures need to be > aligned > > to Motorola 68K alignment for historical reasons. All other > structures > > should use normal alignment to be compatible with C and Unix > > interfaces. The alignment change was implemented to be supported > only > > in packed structures as a natural and intuitive way to "force" > > alignment. You could view it as a bug fix to overly restrictive > > alignment rules in packed structures. > > > > > > On 12/02/2008, at 2:46 PM, Rodney M. Bates wrote: > > > > > It sounds like all that Mac OS X needs is for _all_ types in an > entire > > > program to use the liberal packing rules. Have I understood > > > correctly? > > > I would have no grief over that. > > > > > > Darko wrote: > > >> The liberalised alignment rules are required for the native > Mac OS > > >> X API and should stay. You cannot use that API without them. I > > >> think the pragma is not required and can be removed. I agree with > > >> all the points you make. The effect of the modified alignment > > >> rules it to allow *packed* structures to have members aligned on > > >> byte boundaries. This has the effect of packing the fields in the > > >> tightest arrangement allowed by the platform. This might affect > > >> performance, but if the user is concerned about this they should > > >> specify field bit sizes that deliver improved performance. I > don't > > >> see a need to specify this on a structure level, for the reasons > > >> you give and because the difference isn't significant enough in > > >> the case of packed structures and their physical layout and > > >> restrictions are platform dependent anyway. > > >> I might also add that the alignment code is currently broken on > > >> I386_DARWIN. > > >> - Darko > > >> On 11/02/2008, at 8:55 AM, Rodney M. Bates wrote: > > >>> Does anybody know about the status of pragma <*LAZYALIGN*>? > Is it > > >>> being used anywhere? > > >>> > > >>> It is not documented in pragmas.html. The compiler front end > > >>> appears > > >>> to accept it. (In fact, Decls.m3 contains constants that suggest > > >>> limitations on what declarations the pragma can appear on, > but these > > >>> are not actually enforced.) It liberalizes the alignment rules, > > >>> generally allowing scalars to start on any byte boundary. > > >>> > > >>> Pickles have to be able to reconstruct the layout of types as > the > > >>> compiler would have done it for a machine (on which a now- > being-read > > >>> pickle was written) with different word size and alignment > > >>> properties. > > >>> Currently, pickles are completely unaware of lazy alignment. It > > >>> would have to be encoded in type descriptions generated by the > > >>> compiler > > >>> using TipeDesc and read by pickles using RTTipe. > > >>> > > >>> Most troubling to me is what looks like a linguistic > Pandora's box. > > >>> The pragma can be associated with any constant, variable, or > type > > >>> _declaration_ (not type definition), with the result that > different > > >>> values of the same type can actually be different in their > alignment > > >>> rules and thus their layout. Similarly for different identifiers > > >>> equated to the same type. Although the effects of this could > > >>> possibly > > >>> be hidden from the programmer in purely safe code, not so with > > >>> unsafe > > >>> code. I haven't thoroughly thought this through, but seems to me > > >>> to > > >>> really fly in the face of the whole typing philosophy of the > > >>> language. > > >>> > > >>> For example, if pickles were to read in an object value, and > there > > >>> were >1 variants of the object's type in the reading program, > > >>> differing > > >>> only in the alignment rules, how would it decide which one to > build? > > >>> In fact, ignoring pickles altogether and just looking at a > single > > >>> program, > > >>> if the object's type doesn't actually uniquely give its memory > > >>> layout, > > >>> how can it be accessed correctly? > > >>> > > >>> Additionally, a quick look at the compiler suggests it won't > > >>> generate > > >>> correct code for whole record assignment when the LHS and RHS > are > > >>> the > > >>> same type but have different alignment characteristics. > > >>> > > >>> The more I think about it, it seems the only workable > > >>> possibilities are: > > >>> > > >>> 1) Require the pragma to be associated only with a type > > >>> _definition_ not a > > >>> declaration (e.g., allow RECORD <*LAZYALIGN*> ... END) and make > > >>> this a > > >>> property of the type that propagates to all names for the > type and > > >>> all variables, constants, etc. Also, this would make this > property > > >>> a part of the type signature that pickles uses when reading, - > OR- > > >>> > > >>> 2) Forget it altogether. > > >>> > > >>> What do people think? > > >>> -- > > >>> ------------------------------------------------------------- > > >>> Rodney M. Bates, retired assistant professor > > >>> Dept. of Computer Science, Wichita State University > > >>> Wichita, KS 67260-0083 > > >>> 316-978-3922 > > >>> rodney.bates at wichita.edu > > > > > > -- > > > ------------------------------------------------------------- > > > Rodney M. Bates, retired assistant professor > > > Dept. of Computer Science, Wichita State University > > > Wichita, KS 67260-0083 > > > 316-978-3922 > > > rodney.bates at wichita.edu > > > > > Connect and share in new ways with Windows Live. Get it now! From jayk123 at hotmail.com Tue Feb 12 18:33:01 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 12 Feb 2008 17:33:01 +0000 Subject: [M3devel] val? In-Reply-To: <20080212043242.37D6510D4686@birch.elegosoft.com> References: <20080212043242.37D6510D4686@birch.elegosoft.com> Message-ID: This was to "fix" building NT386GNU because lseek was returning int or long instead of off_t. My mistake by changing the wrong side of things. The return type is fixed and NT386GNU is ok with the "VAL". - Jay From: jayk123 at hotmail.comTo: hosking at elego.de; m3commit at elegosoft.com; m3devel at elegosoft.comSubject: val?Date: Tue, 12 Feb 2008 06:22:28 +0000 Sorry, I hadn't gotten around to testing this on other platforms. I do have PPC_DARWIN and PPC_LINUX available.There is/was a compilation problem with what I was doing.I"ll look into it more later. - Jay > Date: Tue, 12 Feb 2008 05:32:41 +0000> To: m3commit at elegosoft.com> From: hosking at elego.de> Subject: [M3commit] CVS Update: cm3> > CVSROOT: /usr/cvs> Changes by: hosking at birch. 08/02/12 05:32:41> > Modified files:> cm3/m3-libs/libm3/src/os/POSIX/: FilePosix.m3 > > Log message:> This checkin fixes something Jay left behind.> > Please check things build on platforms other than yours before making> changes. The VAL is necessary on some targets because 0 is INTEGER whereas> result is Utypes.off_t (LONGINT on I386_DARWIN) and cannot be directly> compared with an INTEGER (result). The VAL is how we do the conversion to> LONGINT.> > On platforms where Utypes.off_t is INTEGER this code will work the same as it> is.> Connect and share in new ways with Windows Live. Get it now! _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Feb 12 18:34:12 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 12 Feb 2008 12:34:12 -0500 Subject: [M3devel] scripts/PKGS In-Reply-To: <20080212113442.p5eudv3y0w4ks04o@mail.elegosoft.com> References: <20080212113442.p5eudv3y0w4ks04o@mail.elegosoft.com> Message-ID: <8B40FF77-0AF5-4907-9935-03CEE1E24BB7@cs.purdue.edu> Thanks Jay and Olaf for your explanations. I am only ever a general user of the scripts, but perhaps as a maintainer I should understand them better. On Feb 12, 2008, at 5:34 AM, Olaf Wagner wrote: > Quoting Tony Hosking : > >> I notice scripts/PKGS is no longer in the repository. Does this get >> generated somehow now? I know that do-cm3-std.sh depends on it >> because >> my copy of PKGS was broken (missing sysutils). Can someone >> explain to >> me how the build scripts have changed and how I should be using them? > > PKGS has never been checked-in and should not as far as I know. > It contains workspace-dependent paths and is built by find-packages.sh > if I remember correctly. All shell scripts will generate it if it > does not exist. It can be deleted any time, and indeed must be deleted > if packages are added (or they will not be found). This is arguably > a bug, > but then all the scripts were never intended to be a general user > interface > for CM3 users (only for the maintenance). > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > 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 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > From hosking at cs.purdue.edu Tue Feb 12 18:42:01 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 12 Feb 2008 12:42:01 -0500 Subject: [M3devel] utime.i3 and imported data In-Reply-To: References: Message-ID: <83D7FEB7-0C73-4239-8B7F-71DD622E18C2@cs.purdue.edu> Aren't these all superseded by gettimeofday? I say just not support the global variable access. Utime.i3 on other platforms does not have these globals. On Feb 12, 2008, at 12:07 PM, Jay wrote: > well..we were accessing fields at the end of struct tm that aren't > there..switched from DateBsd to DateLinux and now my exact first > proposal stands. :) > > I worked around but it is lame, imho more lame than my suggestion. > My suggestion still imports/shares the data, just via a C function > call, so that the right declarations are present. > The right declarations are..difficult in Modula-3. > You'd have to declare the variables as pointers and change their > name, and then somehow either layer portable code over that, or > fork DateBsd/DateLinux to DateCygwin..which I just don't think is > worth it. I don't like per-platform forks, too much duplicity, too > much multiplication out of code, too much code, too much cruft, too > little maintenance.... better to merge stuff if it isn't a mess and > have less overall source code to maintain.... > > - Jay > > From: jayk123 at hotmail.com > To: m3devel at elegosoft.com > Subject: RE: [M3devel] utime.i3 and imported data > Date: Tue, 12 Feb 2008 16:27:38 +0000 > > sorry, still not a bad idea, but not where my crash is. > I wasn't paying close enough attention. Those aren't used on NT386GNU. > The crash is probably here: > > C:\dev2\cm3.2\m3-libs\m3core\src\time\posix\DateBsd.m3(47): > date.zone := M3toC.CopyStoT (tm.tm_zone); > > I don't know why yet. (meta reason -- these time formats aren't > worthwhile even if forward slashes in paths and X Windows are....) > > - Jay > > From: jayk123 at hotmail.com > To: m3devel at elegosoft.com > Date: Tue, 12 Feb 2008 15:57:25 +0000 > Subject: [M3devel] utime.i3 and imported data > > For good reason, imported (dynamically linked) data doesn't work > great on Win32. > Functions work much better. Data can work, but you generally need > the header to say __declspec(dllimport), to change it to a > declaration of a pointer. I've seen GNU ld has some workaround but > I'm not familiar with it, it doesn't worthwhile to me, and I'm > having a problem. > > I strongly suggest all the Utime.i3: > > <*EXTERNAL*> VAR timezone: time_t; > <*EXTERNAL*> VAR daylight: int; > <*EXTERNAL*> VAR tzname: ARRAY [0..1] OF char_star; > > be changed to functions: > > <*EXTERNAL Utime__get_timezone*> get_timezone(): time_t; > <*EXTERNAL Utime__get_daylight*> get_daylight(): int; > <*EXTERNAL Utime__get_tzname*> get_tzname(a: [0..1]): char_star; > > > with an implementation in C: > > UtimeC.c > #include > time_t Utime__get_timezone(void) > { > return timezone; > } > > int Utime__get_daylight(void) > { > return daylight; > } > > char* Utime__get_tzname(unsigned a) > { > return tzname[a]; > } > > for now I'm going to try another workaround..where NT386GNU has > this data as not external and some C code to call tzset and then > copy the data from the C globals to Modula-3 globals. > > The datetime feature I added to Quake is crashing, I think due to > this... > > - Jay > > Shed those extra pounds with MSN and The Biggest Loser! Learn more. > Helping your favorite cause is as easy as instant messaging. You > IM, we give. Learn more. > Connect and share in new ways with Windows Live. Get it now! From hosking at cs.purdue.edu Tue Feb 12 18:42:57 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 12 Feb 2008 12:42:57 -0500 Subject: [M3devel] externs in modules instead of interfaces? In-Reply-To: References: Message-ID: The globals are gross, and not available on other platforms. Let's just drop them... On Feb 12, 2008, at 12:21 PM, Jay wrote: > I think I just said this over the weekend, but really, I should be > able to put in modules and not be forced to put them in an > interface. > Look at the cygwin Utime.i3/m3/C.c for example... > Yeah, it's a workaround, that I'd like to remove, but it could > easily represent a non-workaround.. > There's no real "interface/module" here, it's just that I wrote > some of the code in C. > > sorry to be such an annoying whiner..but I ran into this multiple > times over a short span of time... > > - Jay > > > > > > Connect and share in new ways with Windows Live. Get it now! From hosking at cs.purdue.edu Tue Feb 12 18:43:53 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 12 Feb 2008 12:43:53 -0500 Subject: [M3devel] $Id$ ? In-Reply-To: References: <20080212042047.A12E210D4686@birch.elegosoft.com> Message-ID: The log tells the story much better than random comments in the code. On Feb 12, 2008, at 1:18 AM, Jay wrote: > I added some files a while ago and someone either complained or > added them, so I've been adding them since. > > - Jay > > > > Date: Tue, 12 Feb 2008 05:20:47 +0000 > > To: m3commit at elegosoft.com > > From: hosking at elego.de > > Subject: [M3commit] CVS Update: cm3 > > > > CVSROOT: /usr/cvs > > Changes by: hosking at birch. 08/02/12 05:20:47 > > > > Modified files: > > cm3/m3-sys/cm3/src/: m3makefile > > > > Log message: > > Let's avoid RCS id stuff shall we. Just clutters up the files... > > > > > Shed those extra pounds with MSN and The Biggest Loser! Learn more. From hosking at cs.purdue.edu Tue Feb 12 18:50:03 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 12 Feb 2008 12:50:03 -0500 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <200802121256.m1CCu2ct089960@camembert.async.caltech.edu> References: <200802121256.m1CCu2ct089960@camembert.async.caltech.edu> Message-ID: <98447784-CE9A-40E4-8305-DA711A0EEBE1@cs.purdue.edu> Hear hear! On Feb 12, 2008, at 7:56 AM, Mika Nystrom wrote: > > Can you just generate the Modula-3 code you want using a Python > script or COBOL or whatever you like instead of trying to foist > preprocessing nastiness on innocent users of high-level Modula-3? > > Preprocessing is super nasty. It's not just a question of human > readability. m3tk has to be able to read the code, too. I should > be able to write a program that reads in (using m3tk) an arbitrary > Modula-3 interface and understands it to the point that it can > generate Network Object stubs, inter-language call stubs, etc. The > stubs should ALSO be human- and m3tk-readable after the > transformation! > This should work even if the programmer has been very "clever" in > his use of Modula-3 constructs. (Just try getting something like > that to work with C or C++... it's hopeless once the preprocessor > gets involved, and possibly before.) > > Also if I may make a little request, if at all possible, please try > not to break binary compatibility with gcc-compiled C and Fortran > on NT386GNU (not sure if your ideas about calling conventions could > possibly do that...) > > Mika > > Jay writes: >> --_8b04f633-e2a4-411d-940a-739ab79b0616_ >> Content-Type: text/plain; charset="iso-8859-1" >> Content-Transfer-Encoding: quoted-printable >> >> I insist that it depends. >> Putting every platform-specific piece of code in its own file/ >> directory can= >> lead to mass duplication of nearly identical code. >> Sometimes an #if here or there goes very far in /improving/ code >> maintainab= >> ility. >> A lot of #if here there and everywhere of course can have the >> opposite effe= >> ct. >> And I realize if you were to drop support for a target, it is >> easier to fin= >> d/delete files/directories than #ifs, but I don't think that's a >> good enoug= >> h reason to sway the decision. >> It goes both ways. >> =20 >> Yes, you could endeavor factor things down so that everything >> common is in = >> common, and everything not-common is in platform-specific. But >> this is inad= >> equate I think. The tail is wagging the dog unnecessarily I think. >> If my co= >> de very nearly all goes together, don't make me separate it. Also >> sometimes= >> a different factoring is "encouraged" for other reasons, to match >> someone = >> else's factoring. Look at the C*.i3 files. They actually can be >> almost all = >> be nearly the same, yet they are hardly shared at all. I realize >> you could = >> also do a sort of "forwarding", though I'm not sure that Modula-3 >> offers al= >> l the right capabilities for this. Type forwarding, sure. But how >> about pro= >> cedure forwarding? Like nt386\cstdio.i3 fopen =3D common >> \ccommonstdio.i3 fo= >> pen? And having to duplicate a line per type/procedure is lame >> anyway, you = >> KIND OF want "module inheritance". However, if you allow >> preprocessing base= >> d on target, perhaps the need for that goes away. >> =20 >> While extern C varargs functions are generally useless in >> Modula-3, and the= >> refore extern __cdecl is fairly rare, it DOES occur when you write >> little h= >> elpers in C, such as for errno. >> =20 >> A good /heuristic/ might be to change the default in any directory >> that has= >> no c_source. >> But it is only heuristic. >> =20 >> Whatever is done here, some allowance should probably be made for >> multiple = >> calling conventions in the same file. >> Switching the default to the overwhelming majority and then >> annotating the = >> minority is reasonable. >> =20 >> I still believe that silently ignoring calling conventions on all >> but NT386= >> is VERY reasonable, and that no other platform from here on out >> will ever = >> have calling conventions. Esp. not with the same names. When OS/ >> FOO has the= >> FOOAPI calling convention, you can just ignore that one on all but >> target = >> OS/FOO. Just as all but NT386 ignore WINAPI. Yes this COULD >> possibly get ug= >> ly something like: >> <*EXTERN FOOAPI WINAPI*> fopen(); >> FOOAPI for OS/FOO, WINAPI ignored. >> WINAPI for NT386, FOOAPI ignored. >> The One True Calling Convention for all others, calling convention >> ignored. >> =20 >> I really believe this is highly highly unlikely to occur, and it >> is not a t= >> errible outcome, and this bridge could be crossed in the far off >> future. >> The functions that are usually in need of calling conventions are >> usually o= >> nly present on one system. >> Perhaps ODBC is an extremely rare anomaly and the whole issue is >> nearly non= >> existant. >> That could be also. >> A change just for ODBC is probably not the best, though it is a >> very small = >> safe harmless change (I always say that :) ) >> =20 >> =20 >> - Jay >> >> >> >>> CC: jayk123 at hotmail.com; m3devel at elegosoft.com> From: >>> hosking at cs.purdue.e= >> du> Subject: Re: [M3devel] "target specific pragmas"?> Date: Mon, >> 11 Feb 20= >> 08 21:08:46 -0500> To: darko at darko.org> > Indeed!> > On Feb 11, >> 2008, at 8:= >> 37 PM, Darko wrote:> > > I think it's not a good idea. I think all >> platform= >> specific code > > should be in a separate file. I'd also like to >> see an op= >> tion to > > move calling conventions to the makefile rather than >> in pramas = >> to > > avoid having to duplicate interface files just to have a >> different >= >>> calling convention for a different platform.> >> > - Darko> >> >> >>> > On 1= >> 2/02/2008, at 12:21 PM, Jay wrote:> >> >> So I have NOT thought >> this throug= >> h.> >>> >> I wonder if "preprocessing" dependent only on "target" >> is a good= >>>>> idea.> >>> >> Something like either the ability to prefix >>>>> pragmas wit= >> h a target, > >> or an "iftarget" and "ifnottarget" pragma.> >>> >> >> Somethi= >> ng like so:> >>> >> <* IF_TARGET NT386 *>> >> <* END_IF_TARGET*>> >> >>> >>> >= >>> <* IF_TARGET NT386 *>> >> <* END_IF_TARGET*>> >> It's a small can >>> of worm= >> s.> >> Where can they be placed? Only at "global" scope? (ie: >> toplevel in >= >>>> an interface/module).> >>> >> What about IF_OSTYPE?> >> What >>>> about expr= >> essions?> >> IF_TARGET NT386 OR NTAMD64> >>> >> IF_TARGET STARTS >> (NT)> >>> >= >>> etc.> >>> >> I don't really have enough interest here to work >>> through thi= >> s, > >> just sending out the bait...> >>> >> Obviously this was >> triggered b= >> y my happening into the odbc > >> directory and bringing up >> ignoring WINAPI= >> on non-NT386 or > >> prefixing calling conventions with a target.> >> >>> >> = >> This reminds me of an important point here however -- nobody else >> > >> is g= >> oing to make the mistake of ever having multiple calling > >> >> conventions. = >> Therefore the generality of prefixing WINAPI with > >> NT386: is >> useless.> = >>>> Unless Mac68K support is added.> >>> >> And here is some >>>> rationale even.= >> The PC and Mac evolved from > >> "small" systems, where assembly >> programmi= >> ng was common, more > >> people knew more lower level details and >> playing g= >> ames with > >> calling conventions was something anyone could do. >> Most othe= >> r > >> current systems are rooted in C programming. Working in C, >> calling >= >>>> conventions are generally in a hidden layer below what anyone > >>>> >> thin= >> ks about. Therefore, the smaller number of capable people > >> >> working at t= >> hat level have the good sense to only have one calling > >> >> convention. No = >> more systems will evolve from "small", at least not > >> without >> having obs= >> erved this history. Therefore, there will no > >> longer be >> multiple callin= >> g conventions.> >>> >> That is my theory at least.> >>> >> Oh, >> Windows does= >> also have __thiscall and __clrcall. __thiscall is > >> only x86>=20 >> _________________________________________________________________ >> Climb to the top of the charts!=A0Play the word scramble challenge >> with sta= >> r power. >> http://club.live.com/star_shuffle.aspx? >> icid=3Dstarshuffle_wlmailtextlink_ja= >> n= >> >> --_8b04f633-e2a4-411d-940a-739ab79b0616_ >> Content-Type: text/html; charset="iso-8859-1" >> Content-Transfer-Encoding: quoted-printable >> >> >> >> >> >> I insist that it depends.
>> Putting every platform-specific piece of code in its own file/ >> directory can= >> lead to mass duplication of nearly identical code.
>> Sometimes an #if here or there goes very far in /improving/ code >> maintainab= >> ility.
>> A lot of #if here there and everywhere of course can have the >> opposite effe= >> ct.
>> And I realize if you were to drop support for a target, it is >> easier to fin= >> d/delete files/directories than #ifs, but I don't think that's a >> good enoug= >> h reason to sway the decision.
>> It goes both ways.
>>  
>> Yes, you could endeavor factor things down so that everything >> common i= >> s in common, and everything not-common is in platform-specific. >> But this is= >> inadequate I think. The tail is wagging the dog unnecessarily I >> think. If = >> my code very nearly all goes together, don't make me separate >> it. = >> ;Also sometimes a different factoring is "encouraged" for other >> reasons, to= >> match someone else's factoring. Look at the C*.i3 files. They >> actually can= >> be almost all be nearly the same, yet they are hardly shared at >> all. I rea= >> lize you could also do a sort of "forwarding", though I'm not sure >> that Mod= >> ula-3 offers all the right capabilities for this. Type forwarding, >> sure. Bu= >> t how about procedure forwarding? Like nt386\cstdio.i3 fopen =3D >> common\cco= >> mmonstdio.i3 fopen? And having to duplicate a line per type/ >> procedure is la= >> me anyway, you KIND OF want "module inheritance". However, if you >> allow pre= >> processing based on target, perhaps the need for that goes away.
>>  
>> While extern C varargs functions are generally useless in >> Modula-3, and the= >> refore extern __cdecl is fairly rare, it DOES occur when you write >> little h= >> elpers in C, such as for errno.
>>  
>> A good /heuristic/ might be to change the default in any directory >> that has= >> no c_source.
>> But it is only heuristic.
>>  
>> Whatever is done here, some allowance should probably be made for >> multiple = >> calling conventions in the same file.
>> Switching the default to the overwhelming majority and then >> annotating the = >> minority is reasonable.
>>  
>> I still believe that silently ignoring calling conventions on all >> but NT386= >> is VERY reasonable, and that no other platform from here on out >> will ever = >> have calling conventions. Esp. not with the same names. When OS/ >> FOO has the= >> FOOAPI calling convention, you can just ignore that one on all but >> target = >> OS/FOO. Just as all but NT386 ignore WINAPI. Yes this COULD >> possibly get ug= >> ly something like:
>> <*EXTERN FOOAPI WINAPI*> fopen();
>> FOOAPI for OS/FOO, WINAPI ignored.
>> WINAPI for NT386, FOOAPI ignored.
>> The One True Calling Convention for all others, calling convention >> ignored.= >>
>>  
>> I really believe this is highly highly unlikely to occur, and it >> is not a t= >> errible outcome, and this bridge could be crossed in the far off >> future.>> >> The functions that are usually in need of calling conventions are >> usually o= >> nly present on one system.
>> Perhaps ODBC is an extremely rare anomaly and the whole issue is >> nearly non= >> existant.
>> That could be also.
>> A change just for ODBC is probably not the best, though it is a >> very small = >> safe harmless change (I always say that :) )
>>  
>>  
>>  - Jay

>> >>
>>
>> > CC: jayk123 at hotmail.com; m3devel at elegosoft.com
> From: >> hosking at c= >> s.purdue.edu
> Subject: Re: [M3devel] "target specific >> pragmas"?
&= >> gt; Date: Mon, 11 Feb 2008 21:08:46 -0500
> To: >> darko at darko.org
&g= >> t;
> Indeed!
>
> On Feb 11, 2008, at 8:37 PM, >> Darko wro= >> te:
>
> > I think it's not a good idea. I think >> all platfor= >> m specific code
> > should be in a separate file. I'd >> also like t= >> o see an option to
> > move calling conventions to the >> makefile r= >> ather than in pramas to
> > avoid having to duplicate >> interface f= >> iles just to have a different
> > calling convention for >> a differ= >> ent platform.
> >
> > - Darko
> >> >
> >> R>> > On 12/02/2008, at 12:21 PM, Jay wrote:
> >> >
> >= >> ;> So I have NOT thought this through.
> >>
> >> >>= >> I wonder if "preprocessing" dependent only on "target" is a good >>
> = >> >> idea.
> >>
> >> Something like >> either the = >> ability to prefix pragmas with a target,
> >> or an >> "iftarget"= >> and "ifnottarget" pragma.
> >>
> >> >> Something like= >> so:
> >>
> >> <* IF_TARGET NT386 >> *>
> = >> >> <* END_IF_TARGET*>
> >>
> >> >>
>= >> >> <* IF_TARGET NT386 *>
> >> <* >> END_IF_TARGET*= >> >
> >> It's a small can of worms.
> >> >> Where can= >> they be placed? Only at "global" scope? (ie: toplevel in
> >> >>= >> an interface/module).
> >>
> >> What about >> IF_OSTY= >> PE?
> >> What about expressions?
> >> >> IF_TARGET NT3= >> 86 OR NTAMD64
> >>
> >> IF_TARGET STARTS >> (NT)
>= >> ; >>
> >> etc.
> >>
> >> >> I don't = >> really have enough interest here to work through this,
> >> >> ju= >> st sending out the bait...
> >>
> >> >> Obviously this= >> was triggered by my happening into the odbc
> >> >> directory an= >> d bringing up ignoring WINAPI on non-NT386 or
> >> >> prefixing c= >> alling conventions with a target.
> >>
> >> >> This re= >> minds me of an important point here however -- nobody else >>
> >>= >> ; is going to make the mistake of ever having multiple calling >>
> >= >> ;> conventions. Therefore the generality of prefixing WINAPI >> with
&g= >> t; >> NT386: is useless.
> >> Unless Mac68K >> support is ad= >> ded.
> >>
> >> And here is some rationale >> even. The= >> PC and Mac evolved from
> >> "small" systems, where >> assembly = >> programming was common, more
> >> people knew more >> lower level= >> details and playing games with
> >> calling >> conventions was s= >> omething anyone could do. Most other
> >> current >> systems are = >> rooted in C programming. Working in C, calling
> >> >> convention= >> s are generally in a hidden layer below what anyone
> >> >> think= >> s about. Therefore, the smaller number of capable people
> >> >> = >> working at that level have the good sense to only have one calling >>
>= >> >> convention. No more systems will evolve from "small", at >> least no= >> t
> >> without having observed this history. >> Therefore, there = >> will no
> >> longer be multiple calling >> conventions.
> &= >> gt;>
> >> That is my theory at least.
> >> >>
&g= >> t; >> Oh, Windows does also have __thiscall and __clrcall. >> __thiscall= >> is
> >> only x86
>


Climb to >> the top= >> of the charts!=A0Play the word scramble challenge with star power. >> > =3D'http://club.live.com/star_shuffle.aspx? >> icid=3Dstarshuffle_wlmailtextlin= >> k_jan' target=3D'_new'>Play now! >> = >> >> --_8b04f633-e2a4-411d-940a-739ab79b0616_-- From hosking at cs.purdue.edu Tue Feb 12 18:54:15 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 12 Feb 2008 12:54:15 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20080212130518.F0C7B10D4659@birch.elegosoft.com> References: <20080212130518.F0C7B10D4659@birch.elegosoft.com> Message-ID: Jay, I *really* dislike the idea that you are putting target-specific code in a subdirectory labeled Common! If I want to search for target-specific stuff I grep for directories labeled by that target. Please, please, please think about the global picture before making these sorts of local changes! Please back this change out and put this where it belongs in cm3/m3- libs/m3core/src/C/NT386. I am happy to do it for you but I have other things to do with my time! On Feb 12, 2008, at 2:05 PM, Jay Krell wrote: > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 08/02/12 14:05:18 > > Modified files: > cm3/m3-libs/m3core/src/C/Common/: CstdioC.c > > Log message: > fix (NT386 only) From hosking at cs.purdue.edu Tue Feb 12 19:00:39 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 12 Feb 2008 13:00:39 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20080212125650.7DE8D10D4659@birch.elegosoft.com> References: <20080212125650.7DE8D10D4659@birch.elegosoft.com> Message-ID: <3BDD1B0E-CD23-43D1-9BC0-7B36FE6024AF@cs.purdue.edu> The C stuff is not intended to expose a full C API to Modula-3 programmers. It is there mostly for bridging to C-based libraries, particularly platform-specific functionality for platforms that are implemented in C. Some of that bridging is done in the OS-specific unix subdirectories and some in the C subdirectories. Choosing where to put that bridge code is a matter of style I guess, but it should probably be a matter of consensus among the developers of CM3. So, do folks out there have any opinions on how to best structure these bridging portions of m3core? I would argue for the minimum needed to support core M3 functionality. Jay seems to want to throw everything including the kitchen sink into the core libraries. I would argue that doing so makes the job of maintaining and porting Modula-3 a little more onerous. On Feb 12, 2008, at 1:56 PM, Jay Krell wrote: > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 08/02/12 13:56:50 > > Added files: > cm3/m3-libs/m3core/src/unix/NT386/: Unix.i3 Uuio.i3 > > Log message: > a fair amount of "unix i/o" is directly provided by msvcr*.dll and > should perhaps be exposed /somewhere/. Here is a start, of sorts. From dragisha at m3w.org Tue Feb 12 18:58:44 2008 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Tue, 12 Feb 2008 18:58:44 +0100 Subject: [M3devel] wtf "code generation errors"? Message-ID: <1202839124.623.1.camel@faramir.m3w.org> % cm3 --- building in ../LINUXLIBC6 --- new source -> compiling Connection.i3 new source -> compiling Connection.m3 new source -> compiling PDU.i3 new source -> compiling PDU.m3 "../src/PDU.m3", line 107: warning: not used (len) "../src/PDU.m3", line 104: warning: not used (b) "../src/PDU.m3", line 116: warning: open array passed by value (o) "../src/PDU.m3", line 118: warning: not used (cStr) "../src/PDU.m3", line 116: warning: not used (b) "../src/PDU.m3", line 116: warning: not used (o) "../src/PDU.m3", line 160: warning: not used (c) "../src/PDU.m3", line 59: warning: not used (GetInt) 8 warnings encountered new source -> compiling SMPP.m3 "../src/SMPP.m3", line 1: 4 code generation errors 1 error encountered compilation failed => not building program "smpp" Fatal Error: package build failed -- Dragi?a Duri? From hendrik at topoi.pooq.com Tue Feb 12 20:13:38 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 12 Feb 2008 14:13:38 -0500 Subject: [M3devel] introducing VAR in more places? In-Reply-To: References: <20080212132326.GA22149@topoi.pooq.com> <200802121341.m1CDfVoZ091241@camembert.async.caltech.edu> <20080212135205.GC22149@topoi.pooq.com> Message-ID: <20080212191338.GA24578@topoi.pooq.com> On Tue, Feb 12, 2008 at 02:05:46PM +0000, Jay wrote: > Agreed! > C++ vs. WITH, C++ wins by not indenting unnecessarily. > See that change I was fiddling with in Time.m3 for examle. > > Hm. Can we get consensus on a language change? :) > > BEGIN VAR a := 1; > IO.PutInt(a); > VAR b := 2, (* ? *) > c := 3; (* ? *) > IO.PutInt(b); > > ? Easier to require "VAR" on each, a bit wordy. > > - Jay That would work. But I'd use CONST more than VAR (if I had a choice) And I'd like to be able to specify the type. I'm a fanatic about making types explicit. -- hendrik From hosking at cs.purdue.edu Tue Feb 12 21:05:43 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 12 Feb 2008 15:05:43 -0500 Subject: [M3devel] wtf "code generation errors"? In-Reply-To: <1202839124.623.1.camel@faramir.m3w.org> References: <1202839124.623.1.camel@faramir.m3w.org> Message-ID: Did something change in m3middle/m3front lately? On Feb 12, 2008, at 12:58 PM, Dragi?a Duri? wrote: > % cm3 > --- building in ../LINUXLIBC6 --- > > new source -> compiling Connection.i3 > new source -> compiling Connection.m3 > new source -> compiling PDU.i3 > new source -> compiling PDU.m3 > "../src/PDU.m3", line 107: warning: not used (len) > "../src/PDU.m3", line 104: warning: not used (b) > "../src/PDU.m3", line 116: warning: open array passed by value (o) > "../src/PDU.m3", line 118: warning: not used (cStr) > "../src/PDU.m3", line 116: warning: not used (b) > "../src/PDU.m3", line 116: warning: not used (o) > "../src/PDU.m3", line 160: warning: not used (c) > "../src/PDU.m3", line 59: warning: not used (GetInt) > 8 warnings encountered > new source -> compiling SMPP.m3 > "../src/SMPP.m3", line 1: 4 code generation errors > 1 error encountered > compilation failed => not building program "smpp" > Fatal Error: package build failed > > -- > Dragi?a Duri? From rcoleburn at scires.com Tue Feb 12 21:16:27 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Tue, 12 Feb 2008 15:16:27 -0500 Subject: [M3devel] "target specific pragmas"? In-Reply-To: References: <20080211092401.1068410D466B@birch.elegosoft.com> <1202725259.8543.22.camel@faramir.m3w.org> <5ED85017-467B-4269-903A-AC512E78DF50@cs.purdue.edu> <9C682AFA-0D4C-486C-B51C-629AF426344A@cs.purdue.edu> <649A7621-D82E-4024-BC45-193892355AC4@cs.purdue.edu> Message-ID: <47B1B848.1E75.00D7.1@scires.com> Jay: My understanding of Modula-3 is that rather than cluttering up the source code with a bunch of preprocessor directives to deal with the various changes needed by various platforms, a separate source file is used for platforms whose implementation must diverge. The m3makefile is used to control the selection of these platform sources at build time. I like this approach much better. Regards, Randy >>> Jay 2/11/2008 8:21 PM >>> So I have NOT thought this through. I wonder if "preprocessing" dependent only on "target" is a good idea. Something like either the ability to prefix pragmas with a target, or an "iftarget" and "ifnottarget" pragma. Something like so: <* IF_TARGET NT386 *> <* END_IF_TARGET*> <* IF_TARGET NT386 *> <* END_IF_TARGET*> It's a small can of worms. Where can they be placed? Only at "global" scope? (ie: toplevel in an interface/module). What about IF_OSTYPE? What about expressions? IF_TARGET NT386 OR NTAMD64 IF_TARGET STARTS(NT) etc. I don't really have enough interest here to work through this, just sending out the bait... Obviously this was triggered by my happening into the odbc directory and bringing up ignoring WINAPI on non-NT386 or prefixing calling conventions with a target. This reminds me of an important point here however -- nobody else is going to make the mistake of ever having multiple calling conventions. Therefore the generality of prefixing WINAPI with NT386: is useless. Unless Mac68K support is added. And here is some rationale even. The PC and Mac evolved from "small" systems, where assembly programming was common, more people knew more lower level details and playing games with calling conventions was something anyone could do. Most other current systems are rooted in C programming. Working in C, calling conventions are generally in a hidden layer below what anyone thinks about. Therefore, the smaller number of capable people working at that level have the good sense to only have one calling convention. No more systems will evolve from "small", at least not without having observed this history. Therefore, there will no longer be multiple calling conventions. That is my theory at least. Oh, Windows does also have __thiscall and __clrcall. __thiscall is only x86 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Tue Feb 12 22:12:45 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 12 Feb 2008 13:12:45 -0800 Subject: [M3devel] "target specific pragmas"? In-Reply-To: Your message of "Tue, 12 Feb 2008 13:50:22 GMT." Message-ID: <200802122112.m1CLCjU0006778@camembert.async.caltech.edu> Your seeksomething = Ctargetstdio.seeksomething should work. Another thing that might work well is to use generics. For instance, have some interfaces Win32Types.i3 MacOSTypes.i3 FreeBSDTypes.i3 And then build your other stuff as generics passing in OSTypes... of course you can't do *everything* with generics, but type variants you can do. About preprocessing. It's clear you're going to have variable code. When you deal with OS things, of course you will. Currently this variability is expressed in Quake. There's no way of getting away from a certain amount of variability as long as you're interfacing with an OS, I think we all know that. But there's a difference between doing it in Quake and in Modula-3, which is why I used the expression "foisting preprocessing on innocent users of high-level Modula-3". As long as you do it in Quake, no one will expect things like m3tk to work properly all the time. Once you do it in Modula-3 itself, however, you're inviting users to code absolutely normal modules with preprocessing that really have no need for preprocessing. You can't really say "here's a part of the language we're using that you probably shouldn't use." If it's there, you have to expect programmers to use it. If it's not, if they do weird things in Quake, or generate code in Python, on the other hand, they themselves had better know what they are doing. Mika Jay writes: >--_91974b83-e297-4ab9-ba44-e888f600b934_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > >Mika good point, I know that, forgot, thanks for reminding me. > One of the interesting things about Modula-3, or rather anything but C an= >d C++, is easy parsing, easy building of other tools. >=20 >Just to be clear though, independent of my crazy ideas, such tools can't ju= >st enumerate a source tree. I guess they should operate over the pkg tree? = >You know, they can't understand the source tree without understanding m3mak= >efiles. >=20 >I started a little experiment here. >I added m3-libs/m3core/src/C/common/Cstdio.i3. >This is a file that ought to be nearly identical for all targets. For now I= > only changed NT386. >I'm thinking either: > a) I'm not quite on base and just fork it per-target, as it was > b) provide a little bit of C code with #ifdefs, like making the SEEK_* c= >onstants into VARs and using C to initialize them. That's a bit of a downer= > though, since constants ought to be constants. > c) factor it somehow as I was alluding, like, well, again I'm not sure M= >odula-3 has what I'd want here, but at least for types and constants, you c= >an push the non-portable stuff into Ctargetstdio.i3 and then expose them in= > Cstdio.i3, forking only Ctargetstdio.i. >=20 >I'll explain so I can get my question in. :) >=20 >I understand, say: >=20 >Ctargetstdio.i3 (* one of these per target, with not much content *)=20 >CONST > SEEK_CUR =3D ..; (* target specific probably *)=20 > SEEK_SET =3D ..; ditto=20 > SEEK_END =3D ..; ditto =20 >TYPE > FOO =3D ... ditto =20 >=20 >Cstdio.i3 (* portable *)=20 > CONST > SEEK_CUR =3D Ctargetstdio.SEEK_CUR; > SEEK_SET =3D Ctargetstdio.SEEK_SET; > SEEK_END =3D Ctargetstdio.SEEK_END; >TYPE > FOO =3D Ctargetstdio.FOO; >=20 >FILE =3D UNTRACED REF RECORD END; >=20 > procedure fopen(a: const_char_star; b: const_char_star): FILE; >=20 >It is tedious but I believe it works. >It'd be nice, I think, if every symbol in one interface could be automatica= >lly aliases/exposed in another. > At least for this purpose, maybe not for any other. I'm speculating here,= > so please respond kindly. :) >The non portable types and constants can be pushed out and then reexposed a= >s if they were portable and in one place. >=20 >However, let's say, for argument/question's sake, that some function accept= >s int on some targets, off_t on another. >Nevermind for now how you can portably call it. >=20 >Ctargetstdio.i3 (* one of these for every target, but another question in a= > sec ... *) >=20 > PROCEDURE seeksomething(a: off_t); let's say it is int on some pl= >atforms. >=20 >Cstdio.i3 (* the portable one *) >=20 >seeksomething =3D Ctargetstdio.seeksomething; does this work? I should t= >ry it out, read the docs. >=20 >But then the next question would be, let's say there's 20 platforms and 5 u= >se off_t and 15 use int. >It's unfortunate if I have to repeat the content 20 times when there are on= >ly two variants. >You can see this kind of thing where sometimes we include_dir(TARGET), some= >times include_dir(OS_TYPE). >OS_TYPE implies less work, nice. >=20 >Perhaps concatening stuff in arbitrary way with Quake really is the way? >It seems almost sarcastic, but perhaps not. >=20 >As long as the pkg store is easily parsed? >(There's a setting to ship implementation files. I guess that must be left = >on? I thought it'd be nice to reduce distribution size..) >=20 >But for that matter --- could be processed by the compiler and = >result in a file with it already accounted for and ship that. Isn't that ju= >st as good? EXCEPT that more thought would have to go into the spec, wherea= >s m3makefile is already a general purpose system that anyone can do anythin= >g with? >=20 >?? >=20 > - Jay > > > >> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel= >] "target specific pragmas"? > Date: Tue, 12 Feb 2008 04:56:02 -0800> From:= > mika at async.caltech.edu> > > Can you just generate the Modula-3 code you wa= >nt using a Python> script or COBOL or whatever you like instead of trying t= >o foist> preprocessing nastiness on innocent users of high-level Modula-3?>= > > Preprocessing is super nasty. It's not just a question of human> readabi= >lity. m3tk has to be able to read the code, too. I should> be able to write= > a program that reads in (using m3tk) an arbitrary> Modula-3 interface and = >understands it to the point that it can> generate Network Object stubs, int= >er-language call stubs, etc. The> stubs should ALSO be human- and m3tk-read= >able after the transformation!> This should work even if the programmer has= > been very "clever" in> his use of Modula-3 constructs. (Just try getting s= >omething like> that to work with C or C++... it's hopeless once the preproc= >essor> gets involved, and possibly before.)> > Also if I may make a little = >request, if at all possible, please try> not to break binary compatibility = >with gcc-compiled C and Fortran> on NT386GNU (not sure if your ideas about = >calling conventions could> possibly do that...)> > Mika> > Jay writes:> >--= >_8b04f633-e2a4-411d-940a-739ab79b0616_> >Content-Type: text/plain; charset= >=3D"iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >I insist= > that it depends.> >Putting every platform-specific piece of code in its ow= >n file/directory can=3D> > lead to mass duplication of nearly identical cod= >e.> >Sometimes an #if here or there goes very far in /improving/ code maint= >ainab=3D> >ility.> >A lot of #if here there and everywhere of course can ha= >ve the opposite effe=3D> >ct.> >And I realize if you were to drop support f= >or a target, it is easier to fin=3D> >d/delete files/directories than #ifs,= > but I don't think that's a good enoug=3D> >h reason to sway the decision.>= > >It goes both ways.> >=3D20> >Yes, you could endeavor factor things down s= >o that everything common is in =3D> >common, and everything not-common is i= >n platform-specific. But this is inad=3D> >equate I think. The tail is wagg= >ing the dog unnecessarily I think. If my co=3D> >de very nearly all goes to= >gether, don't make me separate it. Also sometimes=3D> > a different factori= >ng is "encouraged" for other reasons, to match someone =3D> >else's factori= >ng. Look at the C*.i3 files. They actually can be almost all =3D> >be nearl= >y the same, yet they are hardly shared at all. I realize you could =3D> >al= >so do a sort of "forwarding", though I'm not sure that Modula-3 offers al= >=3D> >l the right capabilities for this. Type forwarding, sure. But how abo= >ut pro=3D> >cedure forwarding? Like nt386\cstdio.i3 fopen =3D3D common\ccom= >monstdio.i3 fo=3D> >pen? And having to duplicate a line per type/procedure = >is lame anyway, you =3D> >KIND OF want "module inheritance". However, if yo= >u allow preprocessing base=3D> >d on target, perhaps the need for that goes= > away.> >=3D20> >While extern C varargs functions are generally useless in = >Modula-3, and the=3D> >refore extern __cdecl is fairly rare, it DOES occur = >when you write little h=3D> >elpers in C, such as for errno.> >=3D20> >A go= >od /heuristic/ might be to change the default in any directory that has=3D>= > > no c_source.> >But it is only heuristic.> >=3D20> >Whatever is done here= >, some allowance should probably be made for multiple =3D> >calling convent= >ions in the same file.> >Switching the default to the overwhelming majority= > and then annotating the =3D> >minority is reasonable.> >=3D20> >I still be= >lieve that silently ignoring calling conventions on all but NT386=3D> > is = >VERY reasonable, and that no other platform from here on out will ever =3D>= > >have calling conventions. Esp. not with the same names. When OS/FOO has t= >he=3D> > FOOAPI calling convention, you can just ignore that one on all but= > target =3D> >OS/FOO. Just as all but NT386 ignore WINAPI. Yes this COULD p= >ossibly get ug=3D> >ly something like:> ><*EXTERN FOOAPI WINAPI*> fopen();>= > >FOOAPI for OS/FOO, WINAPI ignored.> >WINAPI for NT386, FOOAPI ignored.> >= >The One True Calling Convention for all others, calling convention ignored.= >> >=3D20> >I really believe this is highly highly unlikely to occur, and it= > is not a t=3D> >errible outcome, and this bridge could be crossed in the f= >ar off future.> >The functions that are usually in need of calling conventi= >ons are usually o=3D> >nly present on one system.> >Perhaps ODBC is an extr= >emely rare anomaly and the whole issue is nearly non=3D> >existant.> >That = >could be also.> >A change just for ODBC is probably not the best, though it= > is a very small =3D> >safe harmless change (I always say that :) )> >=3D20= >> >=3D20> > - Jay> >> >> >> >> CC: jayk123 at hotmail.com; m3devel at elegosoft.c= >om> From: hosking at cs.purdue.e=3D> >du> Subject: Re: [M3devel] "target speci= >fic pragmas"?> Date: Mon, 11 Feb 20=3D> >08 21:08:46 -0500> To: darko at darko= >.org> > Indeed!> > On Feb 11, 2008, at 8:=3D> >37 PM, Darko wrote:> > > I t= >hink it's not a good idea. I think all platform=3D> > specific code > > sho= >uld be in a separate file. I'd also like to see an op=3D> >tion to > > move= > calling conventions to the makefile rather than in pramas =3D> >to > > avo= >id having to duplicate interface files just to have a different >=3D> > > c= >alling convention for a different platform.> >> > - Darko> >> >> > On 1=3D>= > >2/02/2008, at 12:21 PM, Jay wrote:> >> >> So I have NOT thought this thro= >ug=3D> >h.> >>> >> I wonder if "preprocessing" dependent only on "target" i= >s a good=3D> > > >> idea.> >>> >> Something like either the ability to pref= >ix pragmas wit=3D> >h a target, > >> or an "iftarget" and "ifnottarget" pra= >gma.> >>> >> Somethi=3D> >ng like so:> >>> >> <* IF_TARGET NT386 *>> >> <* = >END_IF_TARGET*>> >>> >>> >=3D> >> <* IF_TARGET NT386 *>> >> <* END_IF_TARGE= >T*>> >> It's a small can of worm=3D> >s.> >> Where can they be placed? Only= > at "global" scope? (ie: toplevel in >=3D> > >> an interface/module).> >>> = >>> What about IF_OSTYPE?> >> What about expr=3D> >essions?> >> IF_TARGET NT= >386 OR NTAMD64> >>> >> IF_TARGET STARTS(NT)> >>> >=3D> >> etc.> >>> >> I do= >n't really have enough interest here to work through thi=3D> >s, > >> just = >sending out the bait...> >>> >> Obviously this was triggered b=3D> >y my ha= >ppening into the odbc > >> directory and bringing up ignoring WINAPI=3D> > = >on non-NT386 or > >> prefixing calling conventions with a target.> >>> >> = >=3D> >This reminds me of an important point here however -- nobody else > >= >> is g=3D> >oing to make the mistake of ever having multiple calling > >> c= >onventions. =3D> >Therefore the generality of prefixing WINAPI with > >> NT= >386: is useless.> =3D> >>> Unless Mac68K support is added.> >>> >> And here= > is some rationale even.=3D> > The PC and Mac evolved from > >> "small" sys= >tems, where assembly programmi=3D> >ng was common, more > >> people knew mo= >re lower level details and playing g=3D> >ames with > >> calling convention= >s was something anyone could do. Most othe=3D> >r > >> current systems are = >rooted in C programming. Working in C, calling >=3D> > >> conventions are g= >enerally in a hidden layer below what anyone > >> thin=3D> >ks about. There= >fore, the smaller number of capable people > >> working at t=3D> >hat level= > have the good sense to only have one calling > >> convention. No =3D> >mor= >e systems will evolve from "small", at least not > >> without having obs=3D= >> >erved this history. Therefore, there will no > >> longer be multiple cal= >lin=3D> >g conventions.> >>> >> That is my theory at least.> >>> >> Oh, Win= >dows does=3D> > also have __thiscall and __clrcall. __thiscall is > >> only= > x86>=3D20> >______________________________________________________________= >___> >Climb to the top of the charts!=3DA0Play the word scramble challenge = >with sta=3D> >r power.> >http://club.live.com/star_shuffle.aspx?icid=3D3Dst= >arshuffle_wlmailtextlink_ja=3D> >n=3D> >> >--_8b04f633-e2a4-411d-940a-739ab= >79b0616_> >Content-Type: text/html; charset=3D"iso-8859-1"> >Content-Transf= >er-Encoding: quoted-printable> >> >> >> >> >> >e'>I insist that it depends.
> >Putting every platform-specific piece of= > code in its own file/directory can=3D> > lead to mass duplication of nearl= >y identical code.
> >Sometimes an #if here or there goes very far in /im= >proving/ code maintainab=3D> >ility.
> >A lot of #if here there and ever= >ywhere of course can have the opposite effe=3D> >ct.
> >And I realize if= > you were to drop support for a target, it is easier to fin=3D> >d/delete f= >iles/directories than #ifs, but I don't think that's a good enoug=3D> >h re= >ason to sway the decision.
> >It goes both ways.
> > 
> >Yes,= > you could endeavor factor things down so that everything common i=3D>= > >s in common, and everything not-common is in platform-specific. But this = >is=3D> > inadequate I think. The tail is wagging the dog unnecessarily I th= >ink. If =3D> >my code very nearly all goes together, don't make me sep= >arate it. =3D> >;Also sometimes a different factoring is "encouraged" f= >or other reasons, to=3D> > match someone else's factoring. Look at the C*.i= >3 files. They actually can=3D> > be almost all be nearly the same, yet they= > are hardly shared at all. I rea=3D> >lize you could also do a sort of "for= >warding", though I'm not sure that Mod=3D> >ula-3 offers all the right capa= >bilities for this. Type forwarding, sure. Bu=3D> >t how about procedure for= >warding? Like nt386\cstdio.i3 fopen =3D3D common\cco=3D> >mmonstdio.i3 fope= >n? And having to duplicate a line per type/procedure is la=3D> >me anyway, = >you KIND OF want "module inheritance". However, if you allow pre=3D> >proce= >ssing based on target, perhaps the need for that goes away.
> > >> >While extern C varargs functions are generally useless in Modula-3, and= > the=3D> >refore extern __cdecl is fairly rare, it DOES occur when you writ= >e little h=3D> >elpers in C, such as for errno.
> > 
> >A good /= >heuristic/ might be to change the default in any directory that has=3D> > n= >o c_source.
> >But it is only heuristic.
> > 
> >Whatever is = >done here, some allowance should probably be made for multiple =3D> >callin= >g conventions in the same file.
> >Switching the default to the overwhel= >ming majority and then annotating the =3D> >minority is reasonable.
> >&= >nbsp;
> >I still believe that silently ignoring calling conventions on a= >ll but NT386=3D> > is VERY reasonable, and that no other platform from here= > on out will ever =3D> >have calling conventions. Esp. not with the same na= >mes. When OS/FOO has the=3D> > FOOAPI calling convention, you can just igno= >re that one on all but target =3D> >OS/FOO. Just as all but NT386 ignore WI= >NAPI. Yes this COULD possibly get ug=3D> >ly something like:
> ><*EXT= >ERN FOOAPI WINAPI*> fopen();
> >FOOAPI for OS/FOO, WINAPI ignored.>> >WINAPI for NT386, FOOAPI ignored.
> >The One True Calling Convention= > for all others, calling convention ignored.=3D> >
> > 
> >I rea= >lly believe this is highly highly unlikely to occur, and it is not a t=3D> = >>errible outcome, and this bridge could be crossed in the far off future.R=3D> >>> >The functions that are usually in need of calling conventions ar= >e usually o=3D> >nly present on one system.
> >Perhaps ODBC is an extrem= >ely rare anomaly and the whole issue is nearly non=3D> >existant.
> >Tha= >t could be also.
> >A change just for ODBC is probably not the best, tho= >ugh it is a very small =3D> >safe harmless change (I always say that :) )R>> > 
> > 
> > - Jay

> >> >
ling>> >
> >> CC: jayk123 at hotmail.com; m3devel at elegosoft.com
> = >From: hosking at c=3D> >s.purdue.edu
> Subject: Re: [M3devel] "target sp= >ecific pragmas"?
&=3D> >gt; Date: Mon, 11 Feb 2008 21:08:46 -0500
>= >; To: darko at darko.org
&g=3D> >t;
> Indeed!
>
> On Fe= >b 11, 2008, at 8:37 PM, Darko wro=3D> >te:
>
> > I think it= >'s not a good idea. I think all platfor=3D> >m specific code
> > = >should be in a separate file. I'd also like t=3D> >o see an option to
&= >gt; > move calling conventions to the makefile r=3D> >ather than in pram= >as to
> > avoid having to duplicate interface f=3D> >iles just to= > have a different
> > calling convention for a differ=3D> >ent pl= >atform.
> >
> > - Darko
> >
> > >= >R>> > On 12/02/2008, at 12:21 PM, Jay wrote:
> >
> >= >=3D> >;> So I have NOT thought this through.
> >>
> &g= >t;>=3D> > I wonder if "preprocessing" dependent only on "target" is a go= >od
> =3D> >>> idea.
> >>
> >> Somethin= >g like either the =3D> >ability to prefix pragmas with a target,
> &= >gt;> or an "iftarget"=3D> > and "ifnottarget" pragma.
> >>R>> >> Something like=3D> > so:
> >>
> >> = ><* IF_TARGET NT386 *>
> =3D> >>> <* END_IF_TARGET*>= >
> >>
> >>
>=3D> > >> <* IF_TARGET N= >T386 *>
> >> <* END_IF_TARGET*=3D> >>
> >>= > It's a small can of worms.
> >> Where can=3D> > they be placed= >? Only at "global" scope? (ie: toplevel in
> >>=3D> > an inter= >face/module).
> >>
> >> What about IF_OSTY=3D> >PE?= >
> >> What about expressions?
> >> IF_TARGET NT3=3D= >> >86 OR NTAMD64
> >>
> >> IF_TARGET STARTS(NT)
= >>=3D> >; >>
> >> etc.
> >>
> >>= > I don't =3D> >really have enough interest here to work through this,
&= >gt; >> ju=3D> >st sending out the bait...
> >>
> &g= >t;> Obviously this=3D> > was triggered by my happening into the odbc >> >> directory an=3D> >d bringing up ignoring WINAPI on non-NT386= > or
> >> prefixing c=3D> >alling conventions with a target.>> >>
> >> This re=3D> >minds me of an important point= > here however -- nobody else
> >>=3D> >; is going to make the m= >istake of ever having multiple calling
> >=3D> >;> conventions.= > Therefore the generality of prefixing WINAPI with
&g=3D> >t; >> = >NT386: is useless.
> >> Unless Mac68K support is ad=3D> >ded.R>> >>
> >> And here is some rationale even. The=3D> >= > PC and Mac evolved from
> >> "small" systems, where assembly = >=3D> >programming was common, more
> >> people knew more lower= > level=3D> > details and playing games with
> >> calling conve= >ntions was s=3D> >omething anyone could do. Most other
> >> cu= >rrent systems are =3D> >rooted in C programming. Working in C, calling
= >> >> convention=3D> >s are generally in a hidden layer below what = >anyone
> >> think=3D> >s about. Therefore, the smaller number = >of capable people
> >> =3D> >working at that level have the go= >od sense to only have one calling
>=3D> > >> convention. No mo= >re systems will evolve from "small", at least no=3D> >t
> >> w= >ithout having observed this history. Therefore, there =3D> >will no
>= >; >> longer be multiple calling conventions.
> &=3D> >gt;>R>> >> That is my theory at least.
> >>
&g=3D> >t; = >>> Oh, Windows does also have __thiscall and __clrcall. __thiscall=3D= >> > is
> >> only x86
>


Climb to the = >top=3D> > of the charts!=3DA0Play the word scramble challenge with star pow= >er. >=3D3D'http://club.live.com/star_shuffle.aspx?icid=3D3Dstar= >shuffle_wlmailtextlin=3D> >k_jan' target=3D3D'_new'>Play now!> >= >=3D> >> >--_8b04f633-e2a4-411d-940a-739ab79b0616_-- >_________________________________________________________________ >Climb to the top of the charts!=A0Play the word scramble challenge with sta= >r power. >http://club.live.com/star_shuffle.aspx?icid=3Dstarshuffle_wlmailtextlink_ja= >n= > >--_91974b83-e297-4ab9-ba44-e888f600b934_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > >Mika good point, I know that, forgot, thanks for = >reminding me.
>  One of the interesting things about Modula-3, or rather anything but= > C and C++, is easy parsing, easy building of other tools.
> 
>Just to be clear though, independent of my crazy ideas, such tools can't ju= >st enumerate a source tree. I guess they should operate over the p= >kg tree? You know, they can't understand the source tree without understand= >ing m3makefiles.
> 
>I started a little experiment here.
>I added m3-libs/m3core/src/C/common/Cstdio.i3.
>This is a file that ought to be nearly identical for all targets. For now I= > only changed NT386.
>I'm thinking either:
>   a) I'm not quite on base and just fork it per-target, as it wa= >s
   b) provide a little bit of C code with #ifdefs, like making th= >e SEEK_* constants into VARs and using C to initialize them. That's a bit o= >f a downer though, since constants ought to be constants.
>   c) factor it somehow as I was alluding, like, well, again I'm = >not sure Modula-3 has what I'd want here, but at least for types and consta= >nts, you can push the non-portable stuff into Ctargetstdio.i3 and then expo= >se them in Cstdio.i3, forking only Ctargetstdio.i.
> 
>I'll explain so I can get my question in. :)
> 
>I understand, say:
> 
>Ctargetstdio.i3 (* one of these per target, with not much content *) <= >BR> >CONST
>  SEEK_CUR =3D ..; (* target specific probably *)
>  SEEK_SET =3D ..; ditto
>  SEEK_END =3D ..; ditto 
>TYPE
>  FOO =3D ... ditto 
> 
>Cstdio.i3 (* portable *)
> CONST
>  SEEK_CUR =3D Ctargetstdio.SEEK_CUR;
>  SEEK_SET =3D Ctargetstdio.SEEK_SET;
>  SEEK_END =3D Ctargetstdio.SEEK_END;
>TYPE
>  FOO =3D Ctargetstdio.FOO;
> 
>FILE =3D UNTRACED REF RECORD END;
> 
><extern> procedure fopen(a: const_char_star; b: const_char_star): FIL= >E;
> 
>It is tedious but I believe it works.
>It'd be nice, I think, if every symbol in one interface could be autom= >atically aliases/exposed in another.
>  At least for this purpose, maybe not for any other. I'm speculating = >here, so please respond kindly. :)
>The non portable types and constants can be pushed out and then reexposed a= >s if they were portable and in one place.
> 
>However, let's say, for argument/question's sake, that some function accept= >s int on some targets, off_t on another.
>Nevermind for now how you can portably call it.
> 
>Ctargetstdio.i3 (* one of these for every target, but another question in&n= >bsp;a sec ... *)
> 
><extern> PROCEDURE seeksomething(a: off_t);  let's say it is int= > on some platforms.
> 
>Cstdio.i3 (* the portable one *)
> 
>seeksomething =3D Ctargetstdio.seeksomething;    does this w= >ork? I should try it out, read the docs.
> 
>But then the next question would be, let's say there's 20 platforms and 5 u= >se off_t and 15 use int.
>It's unfortunate if I have to repeat the content 20 times when there are on= >ly two variants.
>You can see this kind of thing where sometimes we include_dir(TARGET), some= >times include_dir(OS_TYPE).
>OS_TYPE implies less work, nice.
> 
>Perhaps concatening stuff in arbitrary way with Quake really is the way?> >It seems almost sarcastic, but perhaps not.
> 
>As long as the pkg store is easily parsed?
>(There's a setting to ship implementation files. I guess that must be left = >on? I thought it'd be nice to reduce distribution size..)
> 
>But for that matter --- <IF_TARGET> could be processed by the compile= >r and result in a file with it already accounted for and ship that. Isn't t= >hat just as good? EXCEPT that more thought would have to go into the spec, = >whereas m3makefile is already a general purpose system that anyone can do a= >nything with?
> 
>??
> 
> - Jay

> >
>
>> To: jayk123 at hotmail.com
> CC: m3devel at elegosoft.com
> Subj= >ect: Re: [M3devel] "target specific pragmas"?
> Date: Tue, 12 Feb 20= >08 04:56:02 -0800
> From: mika at async.caltech.edu
>
> >> Can you just generate the Modula-3 code you want using a Python
&g= >t; script or COBOL or whatever you like instead of trying to foist
> = >preprocessing nastiness on innocent users of high-level Modula-3?
> <= >BR>> Preprocessing is super nasty. It's not just a question of human
= >> readability. m3tk has to be able to read the code, too. I should
&g= >t; be able to write a program that reads in (using m3tk) an arbitrary
&g= t; Modula-3 interface and understands it to the point that it can
> g= >enerate Network Object stubs, inter-language call stubs, etc. The
> s= >tubs should ALSO be human- and m3tk-readable after the transformation!
&= >gt; This should work even if the programmer has been very "clever" in
&g= >t; his use of Modula-3 constructs. (Just try getting something like
>= > that to work with C or C++... it's hopeless once the preprocessor
> = >gets involved, and possibly before.)
>
> Also if I may make a = >little request, if at all possible, please try
> not to break binary = >compatibility with gcc-compiled C and Fortran
> on NT386GNU (not sure= > if your ideas about calling conventions could
> possibly do that...)= >
>
> Mika
>
> Jay writes:
> >--_8b04f633= >-e2a4-411d-940a-739ab79b0616_
> >Content-Type: text/plain; charset= >=3D"iso-8859-1"
> >Content-Transfer-Encoding: quoted-printable
= >> >
> >I insist that it depends.
> >Putting every p= >latform-specific piece of code in its own file/directory can=3D
> >= >; lead to mass duplication of nearly identical code.
> >Sometimes = >an #if here or there goes very far in /improving/ code maintainab=3D
>= >; >ility.
> >A lot of #if here there and everywhere of course c= >an have the opposite effe=3D
> >ct.
> >And I realize if y= >ou were to drop support for a target, it is easier to fin=3D
> >d/= >delete files/directories than #ifs, but I don't think that's a good enoug= >=3D
> >h reason to sway the decision.
> >It goes both way= >s.
> >=3D20
> >Yes, you could endeavor factor things down= > so that everything common is in =3D
> >common, and everything not= >-common is in platform-specific. But this is inad=3D
> >equate I t= >hink. The tail is wagging the dog unnecessarily I think. If my co=3D
>= >; >de very nearly all goes together, don't make me separate it. Also som= >etimes=3D
> > a different factoring is "encouraged" for other reas= >ons, to match someone =3D
> >else's factoring. Look at the C*.i3 f= >iles. They actually can be almost all =3D
> >be nearly the same, y= >et they are hardly shared at all. I realize you could =3D
> >also = >do a sort of "forwarding", though I'm not sure that Modula-3 offers al=3DR>> >l the right capabilities for this. Type forwarding, sure. But ho= >w about pro=3D
> >cedure forwarding? Like nt386\cstdio.i3 fopen = >=3D3D common\ccommonstdio.i3 fo=3D
> >pen? And having to duplicate= > a line per type/procedure is lame anyway, you =3D
> >KIND OF want= > "module inheritance". However, if you allow preprocessing base=3D
> = >>d on target, perhaps the need for that goes away.
> >=3D20
= >> >While extern C varargs functions are generally useless in Modula-3= >, and the=3D
> >refore extern __cdecl is fairly rare, it DOES occu= >r when you write little h=3D
> >elpers in C, such as for errno.>> >=3D20
> >A good /heuristic/ might be to change the defau= >lt in any directory that has=3D
> > no c_source.
> >But i= >t is only heuristic.
> >=3D20
> >Whatever is done here, s= >ome allowance should probably be made for multiple =3D
> >calling = >conventions in the same file.
> >Switching the default to the over= >whelming majority and then annotating the =3D
> >minority is reaso= >nable.
> >=3D20
> >I still believe that silently ignoring= > calling conventions on all but NT386=3D
> > is VERY reasonable, a= >nd that no other platform from here on out will ever =3D
> >have c= >alling conventions. Esp. not with the same names. When OS/FOO has the=3D>> > FOOAPI calling convention, you can just ignore that one on all b= >ut target =3D
> >OS/FOO. Just as all but NT386 ignore WINAPI. Yes = >this COULD possibly get ug=3D
> >ly something like:
> >&l= >t;*EXTERN FOOAPI WINAPI*> fopen();
> >FOOAPI for OS/FOO, WINAPI= > ignored.
> >WINAPI for NT386, FOOAPI ignored.
> >The One= > True Calling Convention for all others, calling convention ignored.
>= >; >=3D20
> >I really believe this is highly highly unlikely to = >occur, and it is not a t=3D
> >errible outcome, and this bridge co= >uld be crossed in the far off future.
> >The functions that are us= >ually in need of calling conventions are usually o=3D
> >nly prese= >nt on one system.
> >Perhaps ODBC is an extremely rare anomaly and= > the whole issue is nearly non=3D
> >existant.
> >That co= >uld be also.
> >A change just for ODBC is probably not the best, t= >hough it is a very small =3D
> >safe harmless change (I always say= > that :) )
> >=3D20
> >=3D20
> > - Jay
> &= >gt;
> >
> >
> >> CC: jayk123 at hotmail.com; m3d= >evel at elegosoft.com> From: hosking at cs.purdue.e=3D
> >du> Subj= >ect: Re: [M3devel] "target specific pragmas"?> Date: Mon, 11 Feb 20=3DR>> >08 21:08:46 -0500> To: darko at darko.org> > Indeed!> &= >gt; On Feb 11, 2008, at 8:=3D
> >37 PM, Darko wrote:> > >= > I think it's not a good idea. I think all platform=3D
> > specifi= >c code > > should be in a separate file. I'd also like to see an op= >=3D
> >tion to > > move calling conventions to the makefile = >rather than in pramas =3D
> >to > > avoid having to duplicat= >e interface files just to have a different >=3D
> > > callin= >g convention for a different platform.> >> > - Darko> >&g= >t; >> > On 1=3D
> >2/02/2008, at 12:21 PM, Jay wrote:>= > >> >> So I have NOT thought this throug=3D
> >h.> = >>>> >> I wonder if "preprocessing" dependent only on "target= >" is a good=3D
> > > >> idea.> >>> >> S= >omething like either the ability to prefix pragmas wit=3D
> >h a t= >arget, > >> or an "iftarget" and "ifnottarget" pragma.> >>= >;> >> Somethi=3D
> >ng like so:> >>> >>= > <* IF_TARGET NT386 *>> >> <* END_IF_TARGET*>> >= >>> >>> >=3D
> >> <* IF_TARGET NT386 *>&= >gt; >> <* END_IF_TARGET*>> >> It's a small can of worm= >=3D
> >s.> >> Where can they be placed? Only at "global" = >scope? (ie: toplevel in >=3D
> > >> an interface/module).= >> >>> >> What about IF_OSTYPE?> >> What about ex= >pr=3D
> >essions?> >> IF_TARGET NT386 OR NTAMD64> >= >>> >> IF_TARGET STARTS(NT)> >>> >=3D
> >= >;> etc.> >>> >> I don't really have enough interest he= >re to work through thi=3D
> >s, > >> just sending out the= > bait...> >>> >> Obviously this was triggered b=3D
>= >; >y my happening into the odbc > >> directory and bringing up = >ignoring WINAPI=3D
> > on non-NT386 or > >> prefixing cal= >ling conventions with a target.> >>> >> =3D
> >T= >his reminds me of an important point here however -- nobody else > >&= >gt; is g=3D
> >oing to make the mistake of ever having multiple ca= >lling > >> conventions. =3D
> >Therefore the generality o= >f prefixing WINAPI with > >> NT386: is useless.> =3D
> &g= >t;>> Unless Mac68K support is added.> >>> >> And he= >re is some rationale even.=3D
> > The PC and Mac evolved from >= > >> "small" systems, where assembly programmi=3D
> >ng was c= >ommon, more > >> people knew more lower level details and playing = >g=3D
> >ames with > >> calling conventions was something = >anyone could do. Most othe=3D
> >r > >> current systems a= >re rooted in C programming. Working in C, calling >=3D
> > >= >> conventions are generally in a hidden layer below what anyone > >= >;> thin=3D
> >ks about. Therefore, the smaller number of capabl= >e people > >> working at t=3D
> >hat level have the good = >sense to only have one calling > >> convention. No =3D
> >= >;more systems will evolve from "small", at least not > >> without = >having obs=3D
> >erved this history. Therefore, there will no >= > >> longer be multiple callin=3D
> >g conventions.> >&= >gt;> >> That is my theory at least.> >>> >> Oh, = >Windows does=3D
> > also have __thiscall and __clrcall. __thiscall= > is > >> only x86>=3D20
> >___________________________= >______________________________________
> >Climb to the top of the = >charts!=3DA0Play the word scramble challenge with sta=3D
> >r powe= >r.
> >http://club.live.com/star_shuffle.aspx?icid=3D3Dstarshuffle_= >wlmailtextlink_ja=3D
> >n=3D
> >
> >--_8b04f633-= >e2a4-411d-940a-739ab79b0616_
> >Content-Type: text/html; charset= >=3D"iso-8859-1"
> >Content-Transfer-Encoding: quoted-printable
= >> >
> ><html>
> ><head>
> ><= >;style>
> >.hmmessage P
> >{
> >margin:0px;R>> >padding:0px
> >}
> >body.hmmessage
> >= >;{
> >FONT-SIZE: 10pt;
> >FONT-FAMILY:Tahoma
> >= >}
> ></style>
> ></head>
> ><body= > class=3D3D'hmmessage'>I insist that it depends.<BR>
> >P= >utting every platform-specific piece of code in its own file/directory can= >=3D
> > lead to mass duplication of nearly identical code.<BR&g= >t;
> >Sometimes an #if here or there goes very far in /improving/ = >code maintainab=3D
> >ility.<BR>
> >A lot of #if he= >re there and everywhere of course can have the opposite effe=3D
> >= >;ct.<BR>
> >And I realize if you were to drop support for a = >target, it is easier to fin=3D
> >d/delete files/directories than = >#ifs, but I don't think that's a good enoug=3D
> >h reason to sway= > the decision.<BR>
> >It goes both ways.<BR>
> &= >gt;&nbsp;<BR>
> >Yes, you could endeavor&nbsp;factor= > things down so that everything common i=3D
> >s in common, and ev= >erything not-common is in platform-specific. But this is=3D
> > in= >adequate I think. The tail is wagging the dog unnecessarily I think. If =3D= >
> >my code very nearly all goes together, don't make me&nbsp;= >separate it.&nbsp=3D
> >;Also sometimes a different factoring = >is "encouraged" for other reasons, to=3D
> > match someone else's = >factoring. Look at the C*.i3 files. They actually can=3D
> > be al= >most all be nearly the same, yet they are hardly shared at all. I rea=3D>> >lize you could also do a sort of "forwarding", though I'm not sur= >e that Mod=3D
> >ula-3 offers all the right capabilities for this.= > Type forwarding, sure. Bu=3D
> >t how about procedure forwarding?= > Like nt386\cstdio.i3 fopen =3D3D common\cco=3D
> >mmonstdio.i3 fo= >pen? And having to duplicate a line per type/procedure is la=3D
> >= >;me anyway, you KIND OF want "module inheritance". However, if you allow pr= >e=3D
> >processing based on target, perhaps the need for that goes= > away.<BR>
> >&nbsp;<BR>
> >While extern = >C varargs functions are generally useless in Modula-3, and the=3D
> &= >gt;refore extern __cdecl is fairly rare, it DOES occur when you write littl= >e h=3D
> >elpers in C, such as for errno.<BR>
> >&a= >mp;nbsp;<BR>
> >A good /heuristic/ might be to change the de= >fault in any directory that has=3D
> > no c_source.<BR>
&= >gt; >But it is only heuristic.<BR>
> >&nbsp;<BR>= >;
> >Whatever is done here, some allowance should probably be made= > for multiple =3D
> >calling conventions in the same file.<BR&g= >t;
> >Switching the default to the overwhelming majority and then = >annotating the =3D
> >minority is reasonable.<BR>
> &g= >t;&nbsp;<BR>
> >I still believe that silently ignoring c= >alling conventions on all but NT386=3D
> > is VERY reasonable, and= > that no other platform from here on out will ever =3D
> >have cal= >ling conventions. Esp. not with the same names. When OS/FOO has the=3D
&= >gt; > FOOAPI calling convention, you can just ignore that one on all but= > target =3D
> >OS/FOO. Just as all but NT386 ignore WINAPI. Yes th= is COULD possibly get ug=3D
> >ly something like:<BR>
>= >; >&lt;*EXTERN FOOAPI WINAPI*&gt; fopen();<BR>
> >= >;FOOAPI for OS/FOO, WINAPI ignored.<BR>
> >WINAPI for NT386,= > FOOAPI ignored.<BR>
> >The One True Calling Convention for = >all others, calling convention ignored.=3D
> ><BR>
> &= >gt;&nbsp;<BR>
> >I really believe this is highly highly = >unlikely to occur, and it is not a t=3D
> >errible outcome, and th= >is bridge could be crossed in the far off future.<BR=3D
> >>= >
> >The functions that are usually in need of calling conventions = >are usually o=3D
> >nly present on one system.<BR>
> &= >gt;Perhaps ODBC is an extremely rare anomaly and the whole issue is nearly = >non=3D
> >existant.<BR>
> >That could be also.<B= >R>
> >A change just for ODBC is probably not the best, though i= >t is a very small =3D
> >safe harmless change (I always say that := >) )<BR>
> >&nbsp;<BR>
> >&nbsp;<BR= >>
> >&nbsp;- Jay<BR><BR>
> >
> &= >gt;<HR id=3D3DstopSpelling>
> ><BR>
> >&g= >t; CC: jayk123 at hotmail.com; m3devel at elegosoft.com<BR>&gt; From: h= >osking at c=3D
> >s.purdue.edu<BR>&gt; Subject: Re: [M3deve= >l] "target specific pragmas"?<BR>&=3D
> >gt; Date: Mon, = >11 Feb 2008 21:08:46 -0500<BR>&gt; To: darko at darko.org<BR>&= >amp;g=3D
> >t; <BR>&gt; Indeed!<BR>&gt; <BR= >>&gt; On Feb 11, 2008, at 8:37 PM, Darko wro=3D
> >te:<B= >R>&gt; <BR>&gt; &gt; I think it's not a good idea. I t= >hink all platfor=3D
> >m specific code <BR>&gt; &gt;= > should be in a separate file. I'd also like t=3D
> >o see an opti= >on to <BR>&gt; &gt; move calling conventions to the makefile = >r=3D
> >ather than in pramas to <BR>&gt; &gt; avoid = >having to duplicate interface f=3D
> >iles just to have a differen= >t <BR>&gt; &gt; calling convention for a differ=3D
> &g= >t;ent platform.<BR>&gt; &gt;<BR>&gt; &gt; - Dar= >ko<BR>&gt; &gt;<BR>&gt; &gt;<B=3D
> &g= >t;R>&gt; &gt; On 12/02/2008, at 12:21 PM, Jay wrote:<BR>&a= >mp;gt; &gt;<BR>&gt; &gt=3D
> >;&gt; So I hav= >e NOT thought this through.<BR>&gt; &gt;&gt;<BR>&am= >p;gt; &gt;&gt;=3D
> > I wonder if "preprocessing" dependen= >t only on "target" is a good <BR>&gt; =3D
> >&gt;&am= >p;gt; idea.<BR>&gt; &gt;&gt;<BR>&gt; &gt;&a= >mp;gt; Something like either the =3D
> >ability to prefix pragmas = >with a target, <BR>&gt; &gt;&gt; or an "iftarget"=3D
&= >gt; > and "ifnottarget" pragma.<BR>&gt; &gt;&gt;<BR= >>&gt; &gt;&gt; Something like=3D
> > so:<BR>&= >amp;gt; &gt;&gt;<BR>&gt; &gt;&gt; &lt;* IF_TA= >RGET NT386 *&gt;<BR>&gt; =3D
> >&gt;&gt; &am= >p;lt;* END_IF_TARGET*&gt;<BR>&gt; &gt;&gt;<BR>&= >amp;gt; &gt;&gt;<BR>&gt;=3D
> > &gt;&gt;= > &lt;* IF_TARGET NT386 *&gt;<BR>&gt; &gt;&gt; &am= >p;lt;* END_IF_TARGET*=3D
> >&gt;<BR>&gt; &gt;&am= >p;gt; It's a small can of worms.<BR>&gt; &gt;&gt; Where c= >an=3D
> > they be placed? Only at "global" scope? (ie: toplevel in= > <BR>&gt; &gt;&gt;=3D
> > an interface/module).&= >lt;BR>&gt; &gt;&gt;<BR>&gt; &gt;&gt; What = >about IF_OSTY=3D
> >PE?<BR>&gt; &gt;&gt; What ab= >out expressions?<BR>&gt; &gt;&gt; IF_TARGET NT3=3D
>= >; >86 OR NTAMD64<BR>&gt; &gt;&gt;<BR>&gt; &a= >mp;gt;&gt; IF_TARGET STARTS(NT)<BR>&gt=3D
> >; &= >gt;&gt;<BR>&gt; &gt;&gt; etc.<BR>&gt; &= >gt;&gt;<BR>&gt; &gt;&gt; I don't =3D
> >real= >ly have enough interest here to work through this, <BR>&gt; &= >gt;&gt; ju=3D
> >st sending out the bait...<BR>&gt; = >&gt;&gt;<BR>&gt; &gt;&gt; Obviously this=3D
&g= >t; > was triggered by my happening into the odbc <BR>&gt; &= >;gt;&gt; directory an=3D
> >d bringing up ignoring WINAPI on n= >on-NT386 or <BR>&gt; &gt;&gt; prefixing c=3D
> >= >alling conventions with a target.<BR>&gt; &gt;&gt;<BR&= >gt;&gt; &gt;&gt; This re=3D
> >minds me of an importan= >t point here however -- nobody else <BR>&gt; &gt;&gt=3DR>> >; is going to make the mistake of ever having multiple calling &= >lt;BR>&gt; &gt=3D
> >;&gt; conventions. Therefore t= >he generality of prefixing WINAPI with <BR>&g=3D
> >t; &= >amp;gt;&gt; NT386: is useless.<BR>&gt; &gt;&gt; Unles= >s Mac68K support is ad=3D
> >ded.<BR>&gt; &gt;&g= >t;<BR>&gt; &gt;&gt; And here is some rationale even. The= >=3D
> > PC and Mac evolved from <BR>&gt; &gt;&gt= >; "small" systems, where assembly =3D
> >programming was common, m= >ore <BR>&gt; &gt;&gt; people knew more lower level=3D
= >> > details and playing games with <BR>&gt; &gt;&gt= >; calling conventions was s=3D
> >omething anyone could do. Most o= >ther <BR>&gt; &gt;&gt; current systems are =3D
> &g= >t;rooted in C programming. Working in C, calling <BR>&gt; &gt= >;&gt; convention=3D
> >s are generally in a hidden layer below= > what anyone <BR>&gt; &gt;&gt; think=3D
> >s abo= >ut. Therefore, the smaller number of capable people <BR>&gt; &= >;gt;&gt; =3D
> >working at that level have the good sense to o= >nly have one calling <BR>&gt;=3D
> > &gt;&gt; co= >nvention. No more systems will evolve from "small", at least no=3D
> = >>t <BR>&gt; &gt;&gt; without having observed this hist= >ory. Therefore, there =3D
> >will no <BR>&gt; &gt;&a= >mp;gt; longer be multiple calling conventions.<BR>&gt; &=3DR>> >gt;&gt;<BR>&gt; &gt;&gt; That is my theory= > at least.<BR>&gt; &gt;&gt;<BR>&g=3D
> &g= >t;t; &gt;&gt; Oh, Windows does also have __thiscall and __clrcall. = >__thiscall=3D
> > is <BR>&gt; &gt;&gt; only x86&= >lt;BR>&gt; <BR><BR><br /><hr />Climb to the = >top=3D
> > of the charts!=3DA0Play the word scramble challenge wit= >h star power. <a href=3D
> >=3D3D'http://club.live.com/star_shu= >ffle.aspx?icid=3D3Dstarshuffle_wlmailtextlin=3D
> >k_jan' target= >=3D3D'_new'>Play now!</a></body>
> ></html>= >=3D
> >
> >--_8b04f633-e2a4-411d-940a-739ab79b0616_--
= >

Climb to the top of the charts!=A0Play the word scramble ch= >allenge with star power. icid=3Dstarshuffle_wlmailtextlink_jan' target=3D'_new'>Play now! >= > >--_91974b83-e297-4ab9-ba44-e888f600b934_-- From mika at async.caltech.edu Tue Feb 12 22:27:15 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 12 Feb 2008 13:27:15 -0800 Subject: [M3devel] introducing VAR in more places? In-Reply-To: Your message of "Tue, 12 Feb 2008 14:02:23 GMT." Message-ID: <200802122127.m1CLRFi0007370@camembert.async.caltech.edu> Jay writes: >Mika your switch example, besides being invalid C++, is just not fair. >I don't think people even think to write their code like that. >Introducing variables at the top of a switch is rare, esp. initializing the= >m. The example didn't come out of nowhere. I once, a very long time ago, being a not completely competent C programmer, wrote a program like that and spent quite a while debugging it before I realized that the initializations weren't being called. I think I was thinking that initializations are like Fortran DATA statements, or at least should be, in any civilized programming language. If you're extending the stack frame to make room for the declared variables, shouldn't you be calling the initialization code, too? Apparently not... Another way of looking at it is that it was just one of those bizarre little bugs that led me to program in Modula-3. Actually, I remember what finally drove me over the edge. I had written a program to make plots of large VLSI chips at very high resolution (300+ megapixel) using alpha blending, etc., and it was working wonderfully (for years) on FreeBSD. I tried to port it to Linux (trivial, right?) and discovered that I couldn't write a bug-free generic linked list library in C to save my life. The data structures in the program were a bit tricky because of the size of the database, and the fact that I wanted to run it in a small amount of memory. In those days the custom was you had one server with a large amount of RAM (1GB) and a bunch of workstations with 64 or 128 MB. My goal was to run the program, which could take up to a week each time, on the workstations rather than tying up the server (which was busy with other stuff). After I had finally debugged the last memory problem with my program, I sat down and wrote a bug-free one in about two days in Modula-3, a programming language that I previously just vaguely knew as a "fancier Pascal". Mika From dragisha at m3w.org Tue Feb 12 22:24:55 2008 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Tue, 12 Feb 2008 22:24:55 +0100 Subject: [M3devel] wtf "code generation errors"? In-Reply-To: References: <1202839124.623.1.camel@faramir.m3w.org> Message-ID: <1202851495.3771.3.camel@faramir.m3w.org> This is new project... and it's pretty drafty, meaning it compiles but it does not run. I sumbitted this because it looks like some obscure (underreported?) error to me. Compiler I do use is pretty stable and build lots of my other apps. On Tue, 2008-02-12 at 15:05 -0500, Tony Hosking wrote: > Did something change in m3middle/m3front lately? > > On Feb 12, 2008, at 12:58 PM, Dragi?a Duri? wrote: > > > % cm3 > > --- building in ../LINUXLIBC6 --- > > > > new source -> compiling Connection.i3 > > new source -> compiling Connection.m3 > > new source -> compiling PDU.i3 > > new source -> compiling PDU.m3 > > "../src/PDU.m3", line 107: warning: not used (len) > > "../src/PDU.m3", line 104: warning: not used (b) > > "../src/PDU.m3", line 116: warning: open array passed by value (o) > > "../src/PDU.m3", line 118: warning: not used (cStr) > > "../src/PDU.m3", line 116: warning: not used (b) > > "../src/PDU.m3", line 116: warning: not used (o) > > "../src/PDU.m3", line 160: warning: not used (c) > > "../src/PDU.m3", line 59: warning: not used (GetInt) > > 8 warnings encountered > > new source -> compiling SMPP.m3 > > "../src/SMPP.m3", line 1: 4 code generation errors > > 1 error encountered > > compilation failed => not building program "smpp" > > Fatal Error: package build failed > > > > -- > > Dragi?a Duri? > -- Dragi?a Duri? From wagner at elegosoft.com Tue Feb 12 23:17:22 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 12 Feb 2008 23:17:22 +0100 Subject: [M3devel] HEADS UP: CM3 builds broken In-Reply-To: <20080212130556.0niuix6mm8088ssc@mail.elegosoft.com> References: <20080212091642.h1euh9btc8c0gsc4@mail.elegosoft.com> <20080212130556.0niuix6mm8088ssc@mail.elegosoft.com> Message-ID: <20080212231722.zco78ply3w4s48sc@mail.elegosoft.com> Quoting Olaf Wagner : > the builds I started again this morning before leaving home seem to > have succeeded again. I don't understand why compilation with the > latest sources on my own system was broken though; I'll have to > check that tonight. Just one more short followup on this. When I got home, I updated to the latest sources again and ran do-cm3-core.sh. Again, everything compiled, but the executable crashed immediately. I then removed all derived files (realclean) and built again, and this time it worked. So the changes made within the last two days must have touched a subtle dependency of compiler and runtime that the builder does not know or detect. I'd like to understand it better, but it is probably too much effort to isolate all the changes and test them one by one. Sometimes it's just easier to use realclean :-/ Olaf -- Olaf Wagner -- elego Software Solutions GmbH 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 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Tue Feb 12 23:22:45 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 12 Feb 2008 23:22:45 +0100 Subject: [M3devel] wtf "code generation errors"? In-Reply-To: <1202851495.3771.3.camel@faramir.m3w.org> References: <1202839124.623.1.camel@faramir.m3w.org> <1202851495.3771.3.camel@faramir.m3w.org> Message-ID: <20080212232245.fx9s7gzg2s0sw8sc@mail.elegosoft.com> Quoting Dragi?a Duri? : > This is new project... and it's pretty drafty, meaning it compiles but > it does not run. I sumbitted this because it looks like some obscure > (underreported?) error to me. > > Compiler I do use is pretty stable and build lots of my other apps. > > On Tue, 2008-02-12 at 15:05 -0500, Tony Hosking wrote: >> Did something change in m3middle/m3front lately? >> >> On Feb 12, 2008, at 12:58 PM, Dragi?a Duri? wrote: >> >> > % cm3 >> > --- building in ../LINUXLIBC6 --- [...] >> > "../src/SMPP.m3", line 1: 4 code generation errors >> > 1 error encountered If you could try and post a minimal example that provokes this failure, I'm sure someone on this list can help to solve the problem. Just the lines above provide too little information though. Olaf -- Olaf Wagner -- elego Software Solutions GmbH 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 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From dragisha at m3w.org Tue Feb 12 22:35:12 2008 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Tue, 12 Feb 2008 22:35:12 +0100 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <47B1B848.1E75.00D7.1@scires.com> References: <20080211092401.1068410D466B@birch.elegosoft.com> <1202725259.8543.22.camel@faramir.m3w.org> <5ED85017-467B-4269-903A-AC512E78DF50@cs.purdue.edu> <9C682AFA-0D4C-486C-B51C-629AF426344A@cs.purdue.edu> <649A7621-D82E-4024-BC45-193892355AC4@cs.purdue.edu> <47B1B848.1E75.00D7.1@scires.com> Message-ID: <1202852112.3771.13.camel@faramir.m3w.org> What we _maybe_ can do... is to make some special, preprocessable source form, which some quake command can parse into multiple files in their folders. And these file can be compiled later...Kind of how generic works. But, as current system works, and it does it very well, and as only case where we really need this is Windows... most Unices being or becoming POSIX... I don't see it's smart to spend resources on becoming more C... Esp when "founding fathers" made it so good and so much non-C :). If we really need to make some approach to "their world", it's much better to work on interoperability issues and thus cement our first-class-citizen language status even more. dd On Tue, 2008-02-12 at 15:16 -0500, Randy Coleburn wrote: > Jay: > > My understanding of Modula-3 is that rather than cluttering up the > source code with a bunch of preprocessor directives to deal with the > various changes needed by various platforms, a separate source file is > used for platforms whose implementation must diverge. The m3makefile > is used to control the selection of these platform sources at build > time. I like this approach much better. > > Regards, > Randy > > >>> Jay 2/11/2008 8:21 PM >>> > So I have NOT thought this through. > > I wonder if "preprocessing" dependent only on "target" is a good idea. > > Something like either the ability to prefix pragmas with a target, or > an "iftarget" and "ifnottarget" pragma. > > Something like so: > > <* IF_TARGET NT386 *> > <* END_IF_TARGET*> > > > <* IF_TARGET NT386 *> > <* END_IF_TARGET*> > It's a small can of worms. > Where can they be placed? Only at "global" scope? (ie: toplevel in an > interface/module). > > What about IF_OSTYPE? > What about expressions? > IF_TARGET NT386 OR NTAMD64 > > IF_TARGET STARTS(NT) > > etc. > > I don't really have enough interest here to work through this, just > sending out the bait... > > Obviously this was triggered by my happening into the odbc directory > and bringing up ignoring WINAPI on non-NT386 or prefixing calling > conventions with a target. > > This reminds me of an important point here however -- nobody else is > going to make the mistake of ever having multiple calling conventions. > Therefore the generality of prefixing WINAPI with NT386: is useless. > Unless Mac68K support is added. > > And here is some rationale even. The PC and Mac evolved from "small" > systems, where assembly programming was common, more people knew more > lower level details and playing games with calling conventions was > something anyone could do. Most other current systems are rooted in C > programming. Working in C, calling conventions are generally in a > hidden layer below what anyone thinks about. Therefore, the smaller > number of capable people working at that level have the good sense to > only have one calling convention. No more systems will evolve from > "small", at least not without having observed this history. Therefore, > there will no longer be multiple calling conventions. > > That is my theory at least. > > Oh, Windows does also have __thiscall and __clrcall. __thiscall is > only x86 -- Dragi?a Duri? From jayk123 at hotmail.com Tue Feb 12 23:23:30 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 12 Feb 2008 22:23:30 +0000 Subject: [M3devel] wtf "code generation errors"? In-Reply-To: <1202851495.3771.3.camel@faramir.m3w.org> References: <1202839124.623.1.camel@faramir.m3w.org> <1202851495.3771.3.camel@faramir.m3w.org> Message-ID: >From reading the code easily/quickly, this is strange. > > > "../src/SMPP.m3", line 1: 4 code generation errors should be preceded by other sorts of errors. And they all/almost all sound "like internal errors", like assertion failures in m3middle. In particular one of: m3-sys\m3middle\src\M3CG_Check.m3(190):PROCEDURE PutErr (u: U; a, b, c: TEXT := NIL) =m3-sys\m3middle\src\M3CG_Check.m3(194): END PutErr;m3-sys\m3middle\src\M3CG_Check.m3(242): PutErr (self, "bad stack: expected [ ",m3-sys\m3middle\src\M3CG_Check.m3(261): ELSE PutErr (self, "stack overflow");m3-sys\m3middle\src\M3CG_Check.m3(274): PutErr (self, "non-empty stack: ", Stack_Dump (self));m3-sys\m3middle\src\M3CG_Check.m3(382): PutErr (self, "redefined runtime proc: ", M3ID.ToText (n));m3-sys\m3middle\src\M3CG_Check.m3(391): PutErr (self, "redefined runtime hook: ", M3ID.ToText (n));m3-sys\m3middle\src\M3CG_Check.m3(400): PutErr (self, "undefined runtime hook: ", M3ID.ToText (n));m3-sys\m3middle\src\M3CG_Check.m3(410): PutErr (self, "NIL variable");m3-sys\m3middle\src\M3CG_Check.m3(432): PutErr (self, "temporary reused while live!");m3-sys\m3middle\src\M3CG_Check.m3(446): PutErr (self, "temp freed twice");m3-sys\m3middle\src\M3CG_Check.m3(458): PutErr (self, "nested static initialization");m3-sys\m3middle\src\M3CG_Check.m3(470): ELSE PutErr (self, "missing begin_init");m3-sys\m3middle\src\M3CG_Check.m3(477): IF (self.in_init <= 0) THEN PutErr (self, "missing begin_init") END;m3-sys\m3middle\src\M3CG_Check.m3(480): ELSE PutErr (self, "decreasing offsets");m3-sys\m3middle\src\M3CG_Check.m3(532): PutErr (self, "NIL procedure");m3-sys\m3middle\src\M3CG_Check.m3(540): PutErr (self, "nested procedure declaration");m3-sys\m3middle\src\M3CG_Check.m3(551): ELSE PutErr (self, "missing begin_procedure");m3-sys\m3middle\src\M3CG_Check.m3(554): PutErr (self, "missing end_blocks: ", Int (self.block_count));m3-sys\m3middle\src\M3CG_Check.m3(562): PutErr (self, "temp not freed, created on line ", Int (line));m3-sys\m3middle\src\M3CG_Check.m3(574): PutErr (self, "begin_block not in procedure");m3-sys\m3middle\src\M3CG_Check.m3(586): ELSE PutErr (self, "missing begin_block");m3-sys\m3middle\src\M3CG_Check.m3(604): PutErr (self, "undefined label: ", Int (l));m3-sys\m3middle\src\M3CG_Check.m3(716): IF NOT LegalLoad [t, u] THEN PutErr (self, "illegal load conversion"); END;m3-sys\m3middle\src\M3CG_Check.m3(724): IF NOT LegalStore [t, u] THEN PutErr (self, "illegal store conversion"); END;m3-sys\m3middle\src\M3CG_Check.m3(739): IF NOT LegalLoad [t, u] THEN PutErr (self, "illegal load conversion"); END;m3-sys\m3middle\src\M3CG_Check.m3(747): IF NOT LegalStore [t, u] THEN PutErr (self, "illegal store conversion"); END;m3-sys\m3middle\src\M3CG_Check.m3(775): PutErr (self, "floating-point literal doesn't match type");m3-sys\m3middle\src\M3CG_Check.m3(1231): PutErr (self, "nested procedure call");m3-sys\m3middle\src\M3CG_Check.m3(1242): PutErr (self, "nested procedure call");m3-sys\m3middle\src\M3CG_Check.m3(1251): IF (self.call_count <= 0) THEN PutErr (self, "missing start_call") END;m3-sys\m3middle\src\M3CG_Check.m3(1260): IF (self.call_count <= 0) THEN PutErr (self, "missing start_call") END;m3-sys\m3middle\src\M3CG_Check.m3(1268): IF (self.call_count <= 0) THEN PutErr (self, "missing start_call") END;m3-sys\m3middle\src\M3CG_Check.m3(1279): ELSE PutErr (self, "missing start_call");34 occurrence(s) have been found. - Jay > From: dragisha at m3w.org> To: hosking at cs.purdue.edu> Date: Tue, 12 Feb 2008 22:24:55 +0100> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] wtf "code generation errors"?> > This is new project... and it's pretty drafty, meaning it compiles but> it does not run. I sumbitted this because it looks like some obscure> (underreported?) error to me.> > Compiler I do use is pretty stable and build lots of my other apps.> > On Tue, 2008-02-12 at 15:05 -0500, Tony Hosking wrote:> > Did something change in m3middle/m3front lately?> > > > On Feb 12, 2008, at 12:58 PM, Dragi?a Duri? wrote:> > > > > % cm3> > > --- building in ../LINUXLIBC6 ---> > >> > > new source -> compiling Connection.i3> > > new source -> compiling Connection.m3> > > new source -> compiling PDU.i3> > > new source -> compiling PDU.m3> > > "../src/PDU.m3", line 107: warning: not used (len)> > > "../src/PDU.m3", line 104: warning: not used (b)> > > "../src/PDU.m3", line 116: warning: open array passed by value (o)> > > "../src/PDU.m3", line 118: warning: not used (cStr)> > > "../src/PDU.m3", line 116: warning: not used (b)> > > "../src/PDU.m3", line 116: warning: not used (o)> > > "../src/PDU.m3", line 160: warning: not used (c)> > > "../src/PDU.m3", line 59: warning: not used (GetInt)> > > 8 warnings encountered> > > new source -> compiling SMPP.m3> > > "../src/SMPP.m3", line 1: 4 code generation errors> > > 1 error encountered> > > compilation failed => not building program "smpp"> > > Fatal Error: package build failed> > >> > > -- > > > Dragi?a Duri? > > > -- > Dragi?a Duri? > _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Feb 12 23:26:57 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 12 Feb 2008 22:26:57 +0000 Subject: [M3devel] HEADS UP: CM3 builds broken In-Reply-To: <20080212231722.zco78ply3w4s48sc@mail.elegosoft.com> References: <20080212091642.h1euh9btc8c0gsc4@mail.elegosoft.com> <20080212130556.0niuix6mm8088ssc@mail.elegosoft.com> <20080212231722.zco78ply3w4s48sc@mail.elegosoft.com> Message-ID: Obviously I'm very suspect, but I looked through ChangeLog and "everything" of mine (except two noted) was nt386/nt386gnu specific pretty obviously from the file paths. And then you gave the "all clear" so I relaxed some. Does it happen on birch? Or only FreeBSD? I didn't install FreeBSD due to your all clear and probably was probably going to "work sprint" the next few days but I should look into this. Ideally it happens on birch, much quicker for me to get into. Or on ppc_darwin/linux. - Jay > Date: Tue, 12 Feb 2008 23:17:22 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] HEADS UP: CM3 builds broken> > Quoting Olaf Wagner :> > the builds I started again this morning before leaving home seem to> > have succeeded again. I don't understand why compilation with the> > latest sources on my own system was broken though; I'll have to> > check that tonight.> > Just one more short followup on this. When I got home, I updated> to the latest sources again and ran do-cm3-core.sh. Again, everything> compiled, but the executable crashed immediately. I then removed> all derived files (realclean) and built again, and this time it> worked. So the changes made within the last two days must have> touched a subtle dependency of compiler and runtime that the builder> does not know or detect. I'd like to understand it better, but it is> probably too much effort to isolate all the changes and test them> one by one. Sometimes it's just easier to use realclean :-/> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> 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> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Feb 12 23:30:23 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 12 Feb 2008 22:30:23 +0000 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <1202852112.3771.13.camel@faramir.m3w.org> References: <20080211092401.1068410D466B@birch.elegosoft.com> <1202725259.8543.22.camel@faramir.m3w.org> <5ED85017-467B-4269-903A-AC512E78DF50@cs.purdue.edu> <9C682AFA-0D4C-486C-B51C-629AF426344A@cs.purdue.edu> <649A7621-D82E-4024-BC45-193892355AC4@cs.purdue.edu> <47B1B848.1E75.00D7.1@scires.com> <1202852112.3771.13.camel@faramir.m3w.org> Message-ID: I'm still left wondering -- these other language tools -- you run them over the pkg store's shipped implementation files, right? Or at least check the BUILD_DIR for derived *3 files? Or do the tools, like, ignore missing implementations or other "small" problems? If the "forwarding" shown works, that goes very far in solving this problem without stepping on other language tools (again though, depending somewhat on the first question -- except, I just remembered -- a lot of these tools only need the *.i3 files and not the *.m3 files?) - Jay > Subject: Re: [M3devel] "target specific pragmas"?> From: dragisha at m3w.org> To: rcoleburn at scires.com> CC: m3devel at elegosoft.com; jayk123 at hotmail.com> Date: Tue, 12 Feb 2008 22:35:12 +0100> > What we _maybe_ can do... is to make some special, preprocessable source> form, which some quake command can parse into multiple files in their> folders. And these file can be compiled later...Kind of how generic> works. > > But, as current system works, and it does it very well, and as only case> where we really need this is Windows... most Unices being or becoming> POSIX... I don't see it's smart to spend resources on becoming more C...> Esp when "founding fathers" made it so good and so much non-C :).> > If we really need to make some approach to "their world", it's much> better to work on interoperability issues and thus cement our> first-class-citizen language status even more.> > dd> > On Tue, 2008-02-12 at 15:16 -0500, Randy Coleburn wrote:> > Jay:> > > > My understanding of Modula-3 is that rather than cluttering up the> > source code with a bunch of preprocessor directives to deal with the> > various changes needed by various platforms, a separate source file is> > used for platforms whose implementation must diverge. The m3makefile> > is used to control the selection of these platform sources at build> > time. I like this approach much better.> > > > Regards,> > Randy> > > > >>> Jay 2/11/2008 8:21 PM >>>> > So I have NOT thought this through.> > > > I wonder if "preprocessing" dependent only on "target" is a good idea.> > > > Something like either the ability to prefix pragmas with a target, or> > an "iftarget" and "ifnottarget" pragma.> > > > Something like so:> > > > <* IF_TARGET NT386 *>> > <* END_IF_TARGET*>> > > > > > <* IF_TARGET NT386 *>> > <* END_IF_TARGET*>> > It's a small can of worms.> > Where can they be placed? Only at "global" scope? (ie: toplevel in an> > interface/module).> > > > What about IF_OSTYPE?> > What about expressions?> > IF_TARGET NT386 OR NTAMD64> > > > IF_TARGET STARTS(NT)> > > > etc.> > > > I don't really have enough interest here to work through this, just> > sending out the bait...> > > > Obviously this was triggered by my happening into the odbc directory> > and bringing up ignoring WINAPI on non-NT386 or prefixing calling> > conventions with a target.> > > > This reminds me of an important point here however -- nobody else is> > going to make the mistake of ever having multiple calling conventions.> > Therefore the generality of prefixing WINAPI with NT386: is useless.> > Unless Mac68K support is added.> > > > And here is some rationale even. The PC and Mac evolved from "small"> > systems, where assembly programming was common, more people knew more> > lower level details and playing games with calling conventions was> > something anyone could do. Most other current systems are rooted in C> > programming. Working in C, calling conventions are generally in a> > hidden layer below what anyone thinks about. Therefore, the smaller> > number of capable people working at that level have the good sense to> > only have one calling convention. No more systems will evolve from> > "small", at least not without having observed this history. Therefore,> > there will no longer be multiple calling conventions.> > > > That is my theory at least.> > > > Oh, Windows does also have __thiscall and __clrcall. __thiscall is> > only x86> -- > Dragi?a Duri? > _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Feb 12 23:33:34 2008 From: jayk123 at hotmail.com (Jay) Date: Tue, 12 Feb 2008 22:33:34 +0000 Subject: [M3devel] HEADS UP: CM3 builds broken In-Reply-To: References: <20080212091642.h1euh9btc8c0gsc4@mail.elegosoft.com> <20080212130556.0niuix6mm8088ssc@mail.elegosoft.com> <20080212231722.zco78ply3w4s48sc@mail.elegosoft.com> Message-ID: Olaf, Oh, upon closer read, things are ok now? This could still be somehow attributed to my "VAL" change? And once realclean once, build repeatedly, and it never comes back? - Jay From: jayk123 at hotmail.comTo: wagner at elegosoft.com; m3devel at elegosoft.comDate: Tue, 12 Feb 2008 22:26:57 +0000Subject: Re: [M3devel] HEADS UP: CM3 builds broken Obviously I'm very suspect, but I looked through ChangeLog and "everything" of mine (except two noted) was nt386/nt386gnu specific pretty obviously from the file paths. And then you gave the "all clear" so I relaxed some.Does it happen on birch? Or only FreeBSD?I didn't install FreeBSD due to your all clear and probably was probably going to "work sprint" the next few days but I should look into this.Ideally it happens on birch, much quicker for me to get into.Or on ppc_darwin/linux. - Jay > Date: Tue, 12 Feb 2008 23:17:22 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] HEADS UP: CM3 builds broken> > Quoting Olaf Wagner :> > the builds I started again this morning before leaving home seem to> > have succeeded again. I don't understand why compilation with the> > latest sources on my own system was broken though; I'll have to> > check that tonight.> > Just one more short followup on this. When I got home, I updated> to the latest sources again and ran do-cm3-core.sh. Again, everything> compiled, but the executable crashed immediately. I then removed> all derived files (realclean) and built again, and this time it> worked. So the changes made within the last two days must have> touched a subtle dependency of compiler and runtime that the builder> does not know or detect. I'd like to understand it better, but it is> probably too much effort to isolate all the changes and test them> one by one. Sometimes it's just easier to use realclean :-/> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> 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> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> Climb to the top of the charts! Play the word scramble challenge with star power. Play now! _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Feb 12 23:52:21 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 12 Feb 2008 23:52:21 +0100 Subject: [M3devel] HEADS UP: CM3 builds broken In-Reply-To: References: <20080212091642.h1euh9btc8c0gsc4@mail.elegosoft.com> <20080212130556.0niuix6mm8088ssc@mail.elegosoft.com> <20080212231722.zco78ply3w4s48sc@mail.elegosoft.com> Message-ID: <20080212235221.3l9sf3f9c088gw04@mail.elegosoft.com> Quoting Jay : > Olaf, Oh, upon closer read, things are ok now? This could still be > somehow attributed to my "VAL" change? > And once realclean once, build repeatedly, and it never comes back? It's all ok now, though we have introduced some incompatibility somewhere, and the builder can't find it. It shows up in other errors when trying to build the whole set of packages, for example: === package m3-ui/mgkit === +++ cm3 -build -override -DROOT='/d/home/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.6.0' -DCM3_VERSION_NUMBER='050600' -DCM3_LAST_CHANGED='2008-01-31' +++ --- building in FreeBSD4 --- Fatal Error: bad version stamps: PlttFrnds.i3 inconsistent opaque object info for type _t1541f475 super type: _te422a136 data: (size: 32, align: 32) method: (size: 0) => PlttFrnds.i3 super type: _te422a136 data: (size: 64, align: 32) method: (size: 0) => RectsVBT.i3 *** execution of cm3 -build -override -DROOT='/d/home/wagner/work/cm3' -DCM3_VERSION_TEXT='d5.6.0' -DCM3_VERSION_NUMBER='050600' -DCM3_LAST_CHANGED='2008-01-31' failed *** Ideally, such things shouldn't happen with M3, but I'm pretty sure the package will compile from scratch. Olaf -- Olaf Wagner -- elego Software Solutions GmbH 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 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Wed Feb 13 00:54:50 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 12 Feb 2008 18:54:50 -0500 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <1202852112.3771.13.camel@faramir.m3w.org> References: <20080211092401.1068410D466B@birch.elegosoft.com> <1202725259.8543.22.camel@faramir.m3w.org> <5ED85017-467B-4269-903A-AC512E78DF50@cs.purdue.edu> <9C682AFA-0D4C-486C-B51C-629AF426344A@cs.purdue.edu> <649A7621-D82E-4024-BC45-193892355AC4@cs.purdue.edu> <47B1B848.1E75.00D7.1@scires.com> <1202852112.3771.13.camel@faramir.m3w.org> Message-ID: My principle concern is that once we provide C APIs then C will permeate the M3 space more pervasively (both apps and libraries). What happens when I want to bring up a system where there is no C?!?! Consider the SPIN OS perhaps... Maybe I am just being overly fusty... On Feb 12, 2008, at 4:35 PM, Dragi?a Duri? wrote: > What we _maybe_ can do... is to make some special, preprocessable > source > form, which some quake command can parse into multiple files in their > folders. And these file can be compiled later...Kind of how generic > works. > > But, as current system works, and it does it very well, and as only > case > where we really need this is Windows... most Unices being or becoming > POSIX... I don't see it's smart to spend resources on becoming more > C... > Esp when "founding fathers" made it so good and so much non-C :). > > If we really need to make some approach to "their world", it's much > better to work on interoperability issues and thus cement our > first-class-citizen language status even more. > > dd > > On Tue, 2008-02-12 at 15:16 -0500, Randy Coleburn wrote: >> Jay: >> >> My understanding of Modula-3 is that rather than cluttering up the >> source code with a bunch of preprocessor directives to deal with the >> various changes needed by various platforms, a separate source >> file is >> used for platforms whose implementation must diverge. The m3makefile >> is used to control the selection of these platform sources at build >> time. I like this approach much better. >> >> Regards, >> Randy >> >>>>> Jay 2/11/2008 8:21 PM >>> >> So I have NOT thought this through. >> >> I wonder if "preprocessing" dependent only on "target" is a good >> idea. >> >> Something like either the ability to prefix pragmas with a target, or >> an "iftarget" and "ifnottarget" pragma. >> >> Something like so: >> >> <* IF_TARGET NT386 *> >> <* END_IF_TARGET*> >> >> >> <* IF_TARGET NT386 *> >> <* END_IF_TARGET*> >> It's a small can of worms. >> Where can they be placed? Only at "global" scope? (ie: toplevel in an >> interface/module). >> >> What about IF_OSTYPE? >> What about expressions? >> IF_TARGET NT386 OR NTAMD64 >> >> IF_TARGET STARTS(NT) >> >> etc. >> >> I don't really have enough interest here to work through this, just >> sending out the bait... >> >> Obviously this was triggered by my happening into the odbc directory >> and bringing up ignoring WINAPI on non-NT386 or prefixing calling >> conventions with a target. >> >> This reminds me of an important point here however -- nobody else is >> going to make the mistake of ever having multiple calling >> conventions. >> Therefore the generality of prefixing WINAPI with NT386: is useless. >> Unless Mac68K support is added. >> >> And here is some rationale even. The PC and Mac evolved from "small" >> systems, where assembly programming was common, more people knew more >> lower level details and playing games with calling conventions was >> something anyone could do. Most other current systems are rooted in C >> programming. Working in C, calling conventions are generally in a >> hidden layer below what anyone thinks about. Therefore, the smaller >> number of capable people working at that level have the good sense to >> only have one calling convention. No more systems will evolve from >> "small", at least not without having observed this history. >> Therefore, >> there will no longer be multiple calling conventions. >> >> That is my theory at least. >> >> Oh, Windows does also have __thiscall and __clrcall. __thiscall is >> only x86 > -- > Dragi?a Duri? From hosking at cs.purdue.edu Wed Feb 13 00:56:31 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 12 Feb 2008 18:56:31 -0500 Subject: [M3devel] wtf "code generation errors"? In-Reply-To: <20080212232245.fx9s7gzg2s0sw8sc@mail.elegosoft.com> References: <1202839124.623.1.camel@faramir.m3w.org> <1202851495.3771.3.camel@faramir.m3w.org> <20080212232245.fx9s7gzg2s0sw8sc@mail.elegosoft.com> Message-ID: <15AF5E94-4440-450A-BFC4-9553CEB25A03@cs.purdue.edu> Certainly, anything provoking an m3middle error of this kind needs fixing. Can we see a code fragment (and preferably a compilable test case) that generates this error? On Feb 12, 2008, at 5:22 PM, Olaf Wagner wrote: > Quoting Dragi?a Duri? : >> This is new project... and it's pretty drafty, meaning it compiles >> but >> it does not run. I sumbitted this because it looks like some obscure >> (underreported?) error to me. >> >> Compiler I do use is pretty stable and build lots of my other apps. >> >> On Tue, 2008-02-12 at 15:05 -0500, Tony Hosking wrote: >>> Did something change in m3middle/m3front lately? >>> >>> On Feb 12, 2008, at 12:58 PM, Dragi?a Duri? wrote: >>> >>> > % cm3 >>> > --- building in ../LINUXLIBC6 --- > [...] >>> > "../src/SMPP.m3", line 1: 4 code generation errors >>> > 1 error encountered > > If you could try and post a minimal example that provokes this > failure, I'm sure someone on this list can help to solve the problem. > Just the lines above provide too little information though. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > 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 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > From hosking at cs.purdue.edu Wed Feb 13 00:57:19 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 12 Feb 2008 18:57:19 -0500 Subject: [M3devel] HEADS UP: CM3 builds broken In-Reply-To: <20080212231722.zco78ply3w4s48sc@mail.elegosoft.com> References: <20080212091642.h1euh9btc8c0gsc4@mail.elegosoft.com> <20080212130556.0niuix6mm8088ssc@mail.elegosoft.com> <20080212231722.zco78ply3w4s48sc@mail.elegosoft.com> Message-ID: <562DD220-6570-4F79-85D9-85F74092A9F9@cs.purdue.edu> I am betting the change to MUTEX definition broke depedent code. On Feb 12, 2008, at 5:17 PM, Olaf Wagner wrote: > Quoting Olaf Wagner : >> the builds I started again this morning before leaving home seem to >> have succeeded again. I don't understand why compilation with the >> latest sources on my own system was broken though; I'll have to >> check that tonight. > > Just one more short followup on this. When I got home, I updated > to the latest sources again and ran do-cm3-core.sh. Again, everything > compiled, but the executable crashed immediately. I then removed > all derived files (realclean) and built again, and this time it > worked. So the changes made within the last two days must have > touched a subtle dependency of compiler and runtime that the builder > does not know or detect. I'd like to understand it better, but it is > probably too much effort to isolate all the changes and test them > one by one. Sometimes it's just easier to use realclean :-/ > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > 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 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > From mika at async.caltech.edu Wed Feb 13 01:37:43 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 12 Feb 2008 16:37:43 -0800 Subject: [M3devel] "target specific pragmas"? In-Reply-To: Your message of "Tue, 12 Feb 2008 18:54:50 EST." Message-ID: <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> This is also an excellent reason not to permit "interfaces" to C code inlined into MODULEs. Interfaces are the contract that the implementation has to live up to. Ok, so it happens that under operating system X on architecture Y, the easiest way to implement the interface is to call a C function that "just happens" to have the correct interface. But on another system, which either isn't built in C or where the function doesn't exist, it might be convenient to implement the interface in (gasp!) Modula-3! (I use this pattern as follows: on systems where Intel's Fortran compiler is available, compile from assembly (which was generated by ifort). On other systems, the code is implemented in Modula-3.) Mika Tony Hosking writes: >My principle concern is that once we provide C APIs then C will >permeate the M3 space more pervasively (both apps and libraries). >What happens when I want to bring up a system where there is no >C?!?! Consider the SPIN OS perhaps... > >Maybe I am just being overly fusty... > >On Feb 12, 2008, at 4:35 PM, Dragi??a Duri?? wrote: > >> What we _maybe_ can do... is to make some special, preprocessable >> source >> form, which some quake command can parse into multiple files in their >> folders. And these file can be compiled later...Kind of how generic >> works. >> >> But, as current system works, and it does it very well, and as only >> case >> where we really need this is Windows... most Unices being or becoming >> POSIX... I don't see it's smart to spend resources on becoming more >> C... >> Esp when "founding fathers" made it so good and so much non-C :). >> >> If we really need to make some approach to "their world", it's much >> better to work on interoperability issues and thus cement our >> first-class-citizen language status even more. >> >> dd >> >> On Tue, 2008-02-12 at 15:16 -0500, Randy Coleburn wrote: >>> Jay: >>> >>> My understanding of Modula-3 is that rather than cluttering up the >>> source code with a bunch of preprocessor directives to deal with the >>> various changes needed by various platforms, a separate source >>> file is >>> used for platforms whose implementation must diverge. The m3makefile >>> is used to control the selection of these platform sources at build >>> time. I like this approach much better. >>> >>> Regards, >>> Randy >>> >>>>>> Jay 2/11/2008 8:21 PM >>> >>> So I have NOT thought this through. >>> >>> I wonder if "preprocessing" dependent only on "target" is a good >>> idea. >>> >>> Something like either the ability to prefix pragmas with a target, or >>> an "iftarget" and "ifnottarget" pragma. >>> >>> Something like so: >>> >>> <* IF_TARGET NT386 *> >>> <* END_IF_TARGET*> >>> >>> >>> <* IF_TARGET NT386 *> >>> <* END_IF_TARGET*> >>> It's a small can of worms. >>> Where can they be placed? Only at "global" scope? (ie: toplevel in an >>> interface/module). >>> >>> What about IF_OSTYPE? >>> What about expressions? >>> IF_TARGET NT386 OR NTAMD64 >>> >>> IF_TARGET STARTS(NT) >>> >>> etc. >>> >>> I don't really have enough interest here to work through this, just >>> sending out the bait... >>> >>> Obviously this was triggered by my happening into the odbc directory >>> and bringing up ignoring WINAPI on non-NT386 or prefixing calling >>> conventions with a target. >>> >>> This reminds me of an important point here however -- nobody else is >>> going to make the mistake of ever having multiple calling >>> conventions. >>> Therefore the generality of prefixing WINAPI with NT386: is useless. >>> Unless Mac68K support is added. >>> >>> And here is some rationale even. The PC and Mac evolved from "small" >>> systems, where assembly programming was common, more people knew more >>> lower level details and playing games with calling conventions was >>> something anyone could do. Most other current systems are rooted in C >>> programming. Working in C, calling conventions are generally in a >>> hidden layer below what anyone thinks about. Therefore, the smaller >>> number of capable people working at that level have the good sense to >>> only have one calling convention. No more systems will evolve from >>> "small", at least not without having observed this history. >>> Therefore, >>> there will no longer be multiple calling conventions. >>> >>> That is my theory at least. >>> >>> Oh, Windows does also have __thiscall and __clrcall. __thiscall is >>> only x86 >> -- >> Dragi??a Duri?? From jayk123 at hotmail.com Wed Feb 13 05:28:41 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 13 Feb 2008 04:28:41 +0000 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> References: Your message of "Tue, 12 Feb 2008 18:54:50 EST." <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> Message-ID: > >My principle concern is that once we provide C APIs then C will > >permeate the M3 space more pervasively (both apps and libraries). This is somewhat my point. When I am debugging, I really miss printf. The debugging options seem really poor everywhere and esp. on NT386. gdb has all wierded out variable names for one thing. And I think we should fix it so that that the symbols have full source paths. I realize they would only be correct on one machine, and hopefully there's a decent story for copying the files. Yeah, I know about "dir" but haven't yet formed a .gdbinit or whatnot. Other than printf'ing, I also end up getting a stack in cdb with no symbols and then disasm in gdb to find what the functions were. That works fine a few times, but I hope not to do it often. Somewhat lucky I could even get a stack. Because, see, cdb is nice enough to stop on access violations by default (such as the time/date code was causing). gdb has a promising sounding feature, the ability to stop on "signals", which I think an access violation would count as, oh, but that feature isn't implemented, sorry. Ok, true, think about it more and I can break on the toplevel exception handler in cygwin1.dll, not sure that always works or not, it's an implementation detail, but heck, when you are debugging, take advantage of whatever you have. :) RTIO, is too verbose for me. But darnit, I can't really have printf..puts is about the best I could do.. Oh, but no, since TEXT != char* even that isn't useful. fread/fwrite maybe though. On a different hand (how many are there? :) ), have you looked in m3core\src\unix?There is just tons of dead stuff, stuff with comments about it perhaps being wrong, "use with care". It seemed to me maybe the point was to expose "all" of /usr/include. Someone, other than me, sure seems to have gone overboard, like someone using Ultrix and Linux 1.x, and then it copied around. Heck, look at the mem* functions being commented out (and probably using the incorrect type int) because Ultrix or somesuch didn't have them. I uncommented them to fix a build. And notice that these functions, again, like most of printf, are /extremely/ portable in functionality and exact binary interface (yeah yeah, I've heard of bcopy and bzero). What there was of Cstdio.i3 seemed very possibly wrong, at least on many targets, and very doubtfully useful for anything, and I think I've now shown unused. > Y, the easiest way to implement the interface is to call a C function > that "just happens" to have the correct interface. But on another But wrapping everything in Modula-3 is so tedious... Oh for all languages to just understand C headers so we can stop rewriting them... Or some other language, ok...not going to be solved in this forum. To go the unpopular route (again), MS CLR/.NET among many other things, attempts to solve this very problem. One way to describe "interfaces" that "all" languages can understand...at least for some subset of languages features.. Just as tedious btw, it is often more portable to wrap all the C APIs in C, exposing a portable controled Modula-3 interface independent of the precise header content. Like errno and my get_stderr/out/in. - Jay > To: hosking at cs.purdue.edu> Date: Tue, 12 Feb 2008 16:37:43 -0800> From: mika at async.caltech.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] "target specific pragmas"?> > > This is also an excellent reason not to permit "interfaces" to C> code inlined into MODULEs.> > Interfaces are the contract that the implementation has to live up> to. Ok, so it happens that under operating system X on architecture> Y, the easiest way to implement the interface is to call a C function> that "just happens" to have the correct interface. But on another> system, which either isn't built in C or where the function doesn't> exist, it might be convenient to implement the interface in (gasp!)> Modula-3!> > (I use this pattern as follows: on systems where Intel's Fortran> compiler is available, compile from assembly (which was generated> by ifort). On other systems, the code is implemented in Modula-3.)> > Mika> > Tony Hosking writes:> >My principle concern is that once we provide C APIs then C will > >permeate the M3 space more pervasively (both apps and libraries). > >What happens when I want to bring up a system where there is no > >C?!?! Consider the SPIN OS perhaps...> >> >Maybe I am just being overly fusty...> >> >On Feb 12, 2008, at 4:35 PM, Dragi??a Duri?? wrote:> >> >> What we _maybe_ can do... is to make some special, preprocessable > >> source> >> form, which some quake command can parse into multiple files in their> >> folders. And these file can be compiled later...Kind of how generic> >> works.> >>> >> But, as current system works, and it does it very well, and as only > >> case> >> where we really need this is Windows... most Unices being or becoming> >> POSIX... I don't see it's smart to spend resources on becoming more > >> C...> >> Esp when "founding fathers" made it so good and so much non-C :).> >>> >> If we really need to make some approach to "their world", it's much> >> better to work on interoperability issues and thus cement our> >> first-class-citizen language status even more.> >>> >> dd> >>> >> On Tue, 2008-02-12 at 15:16 -0500, Randy Coleburn wrote:> >>> Jay:> >>>> >>> My understanding of Modula-3 is that rather than cluttering up the> >>> source code with a bunch of preprocessor directives to deal with the> >>> various changes needed by various platforms, a separate source > >>> file is> >>> used for platforms whose implementation must diverge. The m3makefile> >>> is used to control the selection of these platform sources at build> >>> time. I like this approach much better.> >>>> >>> Regards,> >>> Randy> >>>> >>>>>> Jay 2/11/2008 8:21 PM >>>> >>> So I have NOT thought this through.> >>>> >>> I wonder if "preprocessing" dependent only on "target" is a good > >>> idea.> >>>> >>> Something like either the ability to prefix pragmas with a target, or> >>> an "iftarget" and "ifnottarget" pragma.> >>>> >>> Something like so:> >>>> >>> <* IF_TARGET NT386 *>> >>> <* END_IF_TARGET*>> >>>> >>>> >>> <* IF_TARGET NT386 *>> >>> <* END_IF_TARGET*>> >>> It's a small can of worms.> >>> Where can they be placed? Only at "global" scope? (ie: toplevel in an> >>> interface/module).> >>>> >>> What about IF_OSTYPE?> >>> What about expressions?> >>> IF_TARGET NT386 OR NTAMD64> >>>> >>> IF_TARGET STARTS(NT)> >>>> >>> etc.> >>>> >>> I don't really have enough interest here to work through this, just> >>> sending out the bait...> >>>> >>> Obviously this was triggered by my happening into the odbc directory> >>> and bringing up ignoring WINAPI on non-NT386 or prefixing calling> >>> conventions with a target.> >>>> >>> This reminds me of an important point here however -- nobody else is> >>> going to make the mistake of ever having multiple calling > >>> conventions.> >>> Therefore the generality of prefixing WINAPI with NT386: is useless.> >>> Unless Mac68K support is added.> >>>> >>> And here is some rationale even. The PC and Mac evolved from "small"> >>> systems, where assembly programming was common, more people knew more> >>> lower level details and playing games with calling conventions was> >>> something anyone could do. Most other current systems are rooted in C> >>> programming. Working in C, calling conventions are generally in a> >>> hidden layer below what anyone thinks about. Therefore, the smaller> >>> number of capable people working at that level have the good sense to> >>> only have one calling convention. No more systems will evolve from> >>> "small", at least not without having observed this history. > >>> Therefore,> >>> there will no longer be multiple calling conventions.> >>>> >>> That is my theory at least.> >>>> >>> Oh, Windows does also have __thiscall and __clrcall. __thiscall is> >>> only x86> >> -- > >> Dragi??a Duri?? _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Wed Feb 13 11:18:24 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 13 Feb 2008 10:18:24 +0000 Subject: [M3devel] full paths to sources to slightly ease debugging self-built binaries? In-Reply-To: References: <20080211092401.1068410D466B@birch.elegosoft.com> <1202725259.8543.22.camel@faramir.m3w.org> <5ED85017-467B-4269-903A-AC512E78DF50@cs.purdue.edu> <9C682AFA-0D4C-486C-B51C-629AF426344A@cs.purdue.edu> <649A7621-D82E-4024-BC45-193892355AC4@cs.purdue.edu> <47B1B848.1E75.00D7.1@scires.com> <1202852112.3771.13.camel@faramir.m3w.org> Message-ID: >> And I think we should fix it so that that the symbols have full source paths. >> I realize they would only be correct on one machine, and hopefully there's a decent story for copying the files. My experience using gdb suggests that the symbols have paths like foo.m3 and/or ../bar.i3 but never "full paths". You can tell gdb where to look for files, it isn't that hard, and it works. However I would really like the paths to be full paths and gdb to automatically show the source. (I'd also like a mode that shows no source and only assembly, switching off and on, presumably I'll find this in the gdb docs; it's pretty stinky that in the absence of source, you have to tell it display/i $pc but oh well...) Now, 1) Do people mind their full paths "leaking" out in binaries they give people? Make the behavior an option here? 2) When such binaries are moved across machines, presumably you are back roughly where you started. Ok. And then the same "fix"? Or does the full paths defeat any sort of search in provided paths? (It's pretty obvious where this leads if you think about the implementation -- they can look for leaf path elements in a list of directories, and they can be super aggressive and do something iterative where they try cutting off an element at a time from the start of the path and append that to each "search path", and furthermore, they can "remember" which prefixes' removal tended to work and skip right to that, however that could also lead to missing other matches, and this all rapidly explodes into many probes for files and not clearly worth it; I've never implemented a debugger but I've been a greedy/whiny user. :) ) I have not at all looked into this but I assume once I do it's not that difficult to fix. It's probably a matter of a small number of strategically placed calls to get the full path to a file. There will be the inevitable issues with the two or more different path syntaxes (essentially, mingwin and cygwin have different syntaxes, though you can setup symlinks easily enough to make them able to share each other's paths). I don't know if it plays into any "fingerprinting", and if so, that could be a total deal breaker. I kind of expect it does not. Not in anything people expect to read/write into pickles. Could be that switching this causes a rebuild of everything. Could be the full and relative paths are needed, like for cm3 -ship to work or something, or for the resulting shipped .m3exports files to work. Could be some of the builtin very well hidden stuff, the quake functions that .m3exports files use need an extra parameter, but maybe not. You know, as long as only m3cg/as get the changed paths and nothing else does... - Jay _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Wed Feb 13 11:38:17 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 13 Feb 2008 10:38:17 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20080212130518.F0C7B10D4659@birch.elegosoft.com> Message-ID: done hours ago, not sure I saw the commitI still find a bit unsatisfactory.. but I guess that's plenty good. :) - Jay > From: hosking at cs.purdue.edu> Date: Tue, 12 Feb 2008 12:54:15 -0500> To: jkrell at elego.de> CC: m3devel at elegosoft.com; m3commit at elegosoft.com> Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > Jay, I *really* dislike the idea that you are putting target-specific > code in a subdirectory labeled Common!> > If I want to search for target-specific stuff I grep for directories > labeled by that target.> > Please, please, please think about the global picture before making > these sorts of local changes!> > Please back this change out and put this where it belongs in cm3/m3- > libs/m3core/src/C/NT386. I am happy to do it for you but I have > other things to do with my time!> > On Feb 12, 2008, at 2:05 PM, Jay Krell wrote:> > > CVSROOT: /usr/cvs> > Changes by: jkrell at birch. 08/02/12 14:05:18> >> > Modified files:> > cm3/m3-libs/m3core/src/C/Common/: CstdioC.c> >> > Log message:> > fix (NT386 only)> _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Wed Feb 13 11:53:03 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 13 Feb 2008 10:53:03 +0000 Subject: [M3devel] $Id$ ? In-Reply-To: References: <20080212042047.A12E210D4686@birch.elegosoft.com> Message-ID: I don't disagree much or care much. But I like seeing my name in lights. :) - Jay > CC: hosking at elego.de; m3commit at elegosoft.com; m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: $Id$ ?> Date: Tue, 12 Feb 2008 12:43:53 -0500> To: jayk123 at hotmail.com> > The log tells the story much better than random comments in the code.> > On Feb 12, 2008, at 1:18 AM, Jay wrote:> > > I added some files a while ago and someone either complained or > > added them, so I've been adding them since.> >> > - Jay> >> >> > > Date: Tue, 12 Feb 2008 05:20:47 +0000> > > To: m3commit at elegosoft.com> > > From: hosking at elego.de> > > Subject: [M3commit] CVS Update: cm3> > >> > > CVSROOT: /usr/cvs> > > Changes by: hosking at birch. 08/02/12 05:20:47> > >> > > Modified files:> > > cm3/m3-sys/cm3/src/: m3makefile> > >> > > Log message:> > > Let's avoid RCS id stuff shall we. Just clutters up the files...> > >> >> >> > Shed those extra pounds with MSN and The Biggest Loser! Learn more.> _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Wed Feb 13 11:53:55 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 13 Feb 2008 10:53:55 +0000 Subject: [M3devel] externs in modules instead of interfaces? In-Reply-To: References: Message-ID: Sounds good to me! - Jay > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: [M3devel] externs in modules instead of interfaces?> Date: Tue, 12 Feb 2008 12:42:57 -0500> To: jayk123 at hotmail.com> > The globals are gross, and not available on other platforms. Let's > just drop them...> > On Feb 12, 2008, at 12:21 PM, Jay wrote:> > > I think I just said this over the weekend, but really, I should be > > able to put in modules and not be forced to put them in an > > interface.> > Look at the cygwin Utime.i3/m3/C.c for example...> > Yeah, it's a workaround, that I'd like to remove, but it could > > easily represent a non-workaround..> > There's no real "interface/module" here, it's just that I wrote > > some of the code in C.> >> > sorry to be such an annoying whiner..but I ran into this multiple > > times over a short span of time...> >> > - Jay _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Wed Feb 13 12:01:51 2008 From: jayk123 at hotmail.com (Jay) Date: Wed, 13 Feb 2008 11:01:51 +0000 Subject: [M3devel] utime.i3 and imported data In-Reply-To: <83D7FEB7-0C73-4239-8B7F-71DD622E18C2@cs.purdue.edu> References: <83D7FEB7-0C73-4239-8B7F-71DD622E18C2@cs.purdue.edu> Message-ID: > From: hosking at cs.purdue.edu> > Aren't these all superseded by gettimeofday?> > I say just not support the global variable access.> > Utime.i3 on other platforms does not have these globals. Could be. I don't know this stuff.. They are currently used though. I didn't happen here by chance.. I'll maybe poke around. I guess this is a time to send diffs and get sign off on all platforms. OR fork the file backwards to DateLinuxOld.m3, DateBsdOld.m3, move everyone to it, then fix DateLinux/Bsd to have no data and as people test their platform move forward? And the last guy turn off the lights? (This is a philosophical and real question. The first approach is slower but moves cleanly all at once from good to good. The second approach allows a gradual migration that starts right away and leaves a cluttered history in its wake but arrives at the same place, possibly but not necessarily sooner.) Anyway, my workaround I think is working.. - Jay _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Feb 13 14:53:11 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 13 Feb 2008 08:53:11 -0500 Subject: [M3devel] "target specific pragmas"? In-Reply-To: References: Your message of "Tue, 12 Feb 2008 18:54:50 EST." <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> Message-ID: <7EF4EBB4-D4F2-4964-80C0-78576D0C9812@cs.purdue.edu> On Feb 12, 2008, at 11:28 PM, Jay wrote: > > >My principle concern is that once we provide C APIs then C will > > >permeate the M3 space more pervasively (both apps and libraries). > > This is somewhat my point. > When I am debugging, I really miss printf. I think you will meet strong resistance here for precisely the opposite reason that you are arguing. If you want C write in C. From hosking at cs.purdue.edu Wed Feb 13 14:55:20 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 13 Feb 2008 08:55:20 -0500 Subject: [M3devel] full paths to sources to slightly ease debugging self-built binaries? In-Reply-To: References: <20080211092401.1068410D466B@birch.elegosoft.com> <1202725259.8543.22.camel@faramir.m3w.org> <5ED85017-467B-4269-903A-AC512E78DF50@cs.purdue.edu> <9C682AFA-0D4C-486C-B51C-629AF426344A@cs.purdue.edu> <649A7621-D82E-4024-BC45-193892355AC4@cs.purdue.edu> <47B1B848.1E75.00D7.1@scires.com> <1202852112.3771.13.camel@faramir.m3w.org> Message-ID: These behaviors are derivative of the GNU tools, not CM3 per se. The munged names are understood by m3gdb, which uses them to obtain type information. You don't see the munged name in m3gdb. On Feb 13, 2008, at 5:18 AM, Jay wrote: > >> And I think we should fix it so that that the symbols have full > source paths. > >> I realize they would only be correct on one machine, and > hopefully there's a decent story for copying the files. > > My experience using gdb suggests that the symbols have paths like > foo.m3 and/or ../bar.i3 but never "full paths". > You can tell gdb where to look for files, it isn't that hard, and > it works. > > However I would really like the paths to be full paths and gdb to > automatically show the source. > (I'd also like a mode that shows no source and only assembly, > switching off and on, presumably I'll find this in the gdb docs; > it's pretty stinky that in the absence of source, you have to tell > it display/i $pc but oh well...) > > Now, > 1) Do people mind their full paths "leaking" out in binaries they > give people? > Make the behavior an option here? > > 2) When such binaries are moved across machines, presumably you are > back roughly where you started. Ok. > And then the same "fix"? Or does the full paths defeat any sort of > search in provided paths? > (It's pretty obvious where this leads if you think about the > implementation -- they can look for leaf path elements in a list of > directories, and they can be super aggressive and do something > iterative where they try cutting off an element at a time from the > start of the path and append that to each "search path", and > furthermore, they can "remember" which prefixes' removal tended to > work and skip right to that, however that could also lead to > missing other matches, and this all rapidly explodes into many > probes for files and not clearly worth it; I've never implemented a > debugger but I've been a greedy/whiny user. :) ) > > I have not at all looked into this but I assume once I do it's not > that difficult to fix. > It's probably a matter of a small number of strategically placed > calls to get the full path to a file. > There will be the inevitable issues with the two or more different > path syntaxes (essentially, mingwin and cygwin have different > syntaxes, though you can setup symlinks easily enough to make them > able to share each other's paths). > > I don't know if it plays into any "fingerprinting", and if so, that > could be a total deal breaker. > I kind of expect it does not. Not in anything people expect to read/ > write into pickles. > Could be that switching this causes a rebuild of everything. > Could be the full and relative paths are needed, like for cm3 -ship > to work or something, or for the resulting shipped .m3exports files > to work. Could be some of the builtin very well hidden stuff, the > quake functions that .m3exports files use need an extra parameter, > but maybe not. You know, as long as only m3cg/as get the changed > paths and nothing else does... > > > - Jay > > Need to know the score, the latest news, or you need your Hotmail?- > get your "fix". Check it out. From wagner at elegosoft.com Wed Feb 13 14:58:28 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 13 Feb 2008 14:58:28 +0100 Subject: [M3devel] full paths to sources to slightly ease debugging self-built binaries? In-Reply-To: References: <20080211092401.1068410D466B@birch.elegosoft.com> <1202725259.8543.22.camel@faramir.m3w.org> <5ED85017-467B-4269-903A-AC512E78DF50@cs.purdue.edu> <9C682AFA-0D4C-486C-B51C-629AF426344A@cs.purdue.edu> <649A7621-D82E-4024-BC45-193892355AC4@cs.purdue.edu> <47B1B848.1E75.00D7.1@scires.com> <1202852112.3771.13.camel@faramir.m3w.org> Message-ID: <20080213145828.npvgox31w8g8k8sw@mail.elegosoft.com> Quoting Jay : > >> And I think we should fix it so that that the symbols have full > source paths. >> I realize they would only be correct on one > machine, and hopefully there's a decent story for copying the files. > > My experience using gdb suggests that the symbols have paths like > foo.m3 and/or ../bar.i3 but never "full paths". > You can tell gdb where to look for files, it isn't that hard, and it works. What exactly is the full path of a module? That of your private workspace (assuming you are using overrides for everything) or that in the global package pool (/usr/local/cm3/pkg/...)? Olaf -- Olaf Wagner -- elego Software Solutions GmbH 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 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From rcoleburn at scires.com Wed Feb 13 18:44:31 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Wed, 13 Feb 2008 12:44:31 -0500 Subject: [M3devel] "target specific pragmas"? In-Reply-To: References: Your message of "Tue, 12 Feb 2008 18:54:50 EST." <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> Message-ID: <47B2E62D.1E75.00D7.1@scires.com> Jay: I don't want to be offensive, but quite frankly I'm tired of continually reading your gripes about Modula-3 as a language and your pining for C. This forum is for those people interested in advancing the state of Modula-3. We don't care about C/C++/C#/etc in this forum. Those of us who are M3 zealots for the most part probably would welcome any move to divest CM3 of all underpinnings from the C world. Have you seriously studied the Modula-3 language and used it to build production software? I think some of your comments suggest that you are not a true Modula-3 programmer and that you still cling to the C-way of doing things rather than embracing the Modula-3 way. Now, I do think that most people are interested in improving things and no language is perfect, so any well-thought-out proposal for a change to the language is welcome for consideration, But in this mail list forum, I for one would appreciate less ranting about C and more constructive Modula-3. Truly, I do not want to offend you. Maybe I'm just having a bad day, but I encourage you to try and focus your posts to the advancement of Modula-3. Regards, Randy >>> Jay 2/12/2008 11:28 PM >>> > >My principle concern is that once we provide C APIs then C will > >permeate the M3 space more pervasively (both apps and libraries). This is somewhat my point. When I am debugging, I really miss printf. The debugging options seem really poor everywhere and esp. on NT386. gdb has all wierded out variable names for one thing. And I think we should fix it so that that the symbols have full source paths. I realize they would only be correct on one machine, and hopefully there's a decent story for copying the files. Yeah, I know about "dir" but haven't yet formed a .gdbinit or whatnot. Other than printf'ing, I also end up getting a stack in cdb with no symbols and then disasm in gdb to find what the functions were. That works fine a few times, but I hope not to do it often. Somewhat lucky I could even get a stack. Because, see, cdb is nice enough to stop on access violations by default (such as the time/date code was causing). gdb has a promising sounding feature, the ability to stop on "signals", which I think an access violation would count as, oh, but that feature isn't implemented, sorry. Ok, true, think about it more and I can break on the toplevel exception handler in cygwin1.dll, not sure that always works or not, it's an implementation detail, but heck, when you are debugging, take advantage of whatever you have. :) RTIO, is too verbose for me. But darnit, I can't really have printf..puts is about the best I could do.. Oh, but no, since TEXT != char* even that isn't useful. fread/fwrite maybe though. On a different hand (how many are there? :) ), have you looked in m3core\src\unix? There is just tons of dead stuff, stuff with comments about it perhaps being wrong, "use with care". It seemed to me maybe the point was to expose "all" of /usr/include. Someone, other than me, sure seems to have gone overboard, like someone using Ultrix and Linux 1.x, and then it copied around. Heck, look at the mem* functions being commented out (and probably using the incorrect type int) because Ultrix or somesuch didn't have them. I uncommented them to fix a build. And notice that these functions, again, like most of printf, are /extremely/ portable in functionality and exact binary interface (yeah yeah, I've heard of bcopy and bzero). What there was of Cstdio.i3 seemed very possibly wrong, at least on many targets, and very doubtfully useful for anything, and I think I've now shown unused. > Y, the easiest way to implement the interface is to call a C function > that "just happens" to have the correct interface. But on another But wrapping everything in Modula-3 is so tedious... Oh for all languages to just understand C headers so we can stop rewriting them... Or some other language, ok...not going to be solved in this forum. To go the unpopular route (again), MS CLR/.NET among many other things, attempts to solve this very problem. One way to describe "interfaces" that "all" languages can understand...at least for some subset of languages features.. Just as tedious btw, it is often more portable to wrap all the C APIs in C, exposing a portable controled Modula-3 interface independent of the precise header content. Like errno and my get_stderr/out/in. - Jay > To: hosking at cs.purdue.edu > Date: Tue, 12 Feb 2008 16:37:43 -0800 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] "target specific pragmas"? > > > This is also an excellent reason not to permit "interfaces" to C > code inlined into MODULEs. > > Interfaces are the contract that the implementation has to live up > to. Ok, so it happens that under operating system X on architecture > Y, the easiest way to implement the interface is to call a C function > that "just happens" to have the correct interface. But on another > system, which either isn't built in C or where the function doesn't > exist, it might be convenient to implement the interface in (gasp!) > Modula-3! > > (I use this pattern as follows: on systems where Intel's Fortran > compiler is available, compile from assembly (which was generated > by ifort). On other systems, the code is implemented in Modula-3.) > > Mika > > Tony Hosking writes: > >My principle concern is that once we provide C APIs then C will > >permeate the M3 space more pervasively (both apps and libraries). > >What happens when I want to bring up a system where there is no > >C?!?! Consider the SPIN OS perhaps... > > > >Maybe I am just being overly fusty... > > > >On Feb 12, 2008, at 4:35 PM, Dragi?*a Duri?* wrote: > > > >> What we _maybe_ can do... is to make some special, preprocessable > >> source > >> form, which some quake command can parse into multiple files in their > >> folders. And these file can be compiled later...Kind of how generic > >> works. > >> > >> But, as current system works, and it does it very well, and as only > >> case > >> where we really need this is Windows... most Unices being or becoming > >> POSIX... I don't see it's smart to spend resources on becoming more > >> C... > >> Esp when "founding fathers" made it so good and so much non-C :). > >> > >> If we really need to make some approach to "their world", it's much > >> better to work on interoperability issues and thus cement our > >> first-class-citizen language status even more. > >> > >> dd > >> > >> On Tue, 2008-02-12 at 15:16 -0500, Randy Coleburn wrote: > >>> Jay: > >>> > >>> My understanding of Modula-3 is that rather than cluttering up the > >>> source code with a bunch of preprocessor directives to deal with the > >>> various changes needed by various platforms, a separate source > >>> file is > >>> used for platforms whose implementation must diverge. The m3makefile > >>> is used to control the selection of these platform sources at build > >>> time. I like this approach much better. > >>> > >>> Regards, > >>> Randy > >>> > >>>>>> Jay 2/11/2008 8:21 PM >>> > >>> So I have NOT thought this through. > >>> > >>> I wonder if "preprocessing" dependent only on "target" is a good > >>> idea. > >>> > >>> Something like either the ability to prefix pragmas with a target, or > >>> an "iftarget" and "ifnottarget" pragma. > >>> > >>> Something like so: > >>> > >>> <* IF_TARGET NT386 *> > >>> <* END_IF_TARGET*> > >>> > >>> > >>> <* IF_TARGET NT386 *> > >>> <* END_IF_TARGET*> > >>> It's a small can of worms. > >>> Where can they be placed? Only at "global" scope? (ie: toplevel in an > >>> interface/module). > >>> > >>> What about IF_OSTYPE? > >>> What about expressions? > >>> IF_TARGET NT386 OR NTAMD64 > >>> > >>> IF_TARGET STARTS(NT) > >>> > >>> etc. > >>> > >>> I don't really have enough interest here to work through this, just > >>> sending out the bait... > >>> > >>> Obviously this was triggered by my happening into the odbc directory > >>> and bringing up ignoring WINAPI on non-NT386 or prefixing calling > >>> conventions with a target. > >>> > >>> This reminds me of an important point here however -- nobody else is > >>> going to make the mistake of ever having multiple calling > >>> conventions. > >>> Therefore the generality of prefixing WINAPI with NT386: is useless. > >>> Unless Mac68K support is added. > >>> > >>> And here is some rationale even. The PC and Mac evolved from "small" > >>> systems, where assembly programming was common, more people knew more > >>> lower level details and playing games with calling conventions was > >>> something anyone could do. Most other current systems are rooted in C > >>> programming. Working in C, calling conventions are generally in a > >>> hidden layer below what anyone thinks about. Therefore, the smaller > >>> number of capable people working at that level have the good sense to > >>> only have one calling convention. No more systems will evolve from > >>> "small", at least not without having observed this history. > >>> Therefore, > >>> there will no longer be multiple calling conventions. > >>> > >>> That is my theory at least. > >>> > >>> Oh, Windows does also have __thiscall and __clrcall. __thiscall is > >>> only x86 > >> -- > >> Dragi?*a Duri?* Connect and share in new ways with Windows Live. Get it now! ( http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 ) -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney.bates at wichita.edu Wed Feb 13 19:04:15 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Wed, 13 Feb 2008 12:04:15 -0600 Subject: [M3devel] "target specific pragmas"? In-Reply-To: References: "Your message of Tue, 12 Feb 2008 18:54:50 EST." <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> Message-ID: <47B3311F.4070507@wichita.edu> I haven't tried building it on any form of Windows in a long time, but m3gdb accepts unmangled Modula-3 variable (and procedure and type) names, starting with a module or interface name and supplying a fully- qualified path outside-in with procedure names and anonymous block numbers. Or, if you are stopped at a spot in the code, it will look up unqualified, unmangled names using the language's scope rules from the current point. (Hence my concern about having static links stored.) From there, you can put on additional qualifiers. Naming executable points in the code (e.g. to set breakpoints) works similarly, although that is somewhat different, and obviously, variable names aren't meaningful here. It doesn't accept paths in the filesystem, though. I'm not sure I think that would be a good idea, as it is really mostly finding things in the executable program, not the source code. It also doesn't find constant or exception names, as these currently produce no debug information. Perhaps it is time for me to modify the m3gdb web page, and also see if m3gdb can be built in Windows. Jay wrote: > > gdb has all wierded out variable names for one thing. > And I think we should fix it so that that the symbols have full source > paths. > I realize they would only be correct on one machine, and hopefully > there's a decent story for copying the files. > Yeah, I know about "dir" but haven't yet formed a .gdbinit or whatnot. > -- ------------------------------------------------------------- Rodney M. Bates, retired assistant professor Dept. of Computer Science, Wichita State University Wichita, KS 67260-0083 316-978-3922 rodney.bates at wichita.edu From wagner at elegosoft.com Wed Feb 13 22:38:04 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 13 Feb 2008 22:38:04 +0100 Subject: [M3devel] "Microlocation" In-Reply-To: <1202893163.3771.33.camel@faramir.m3w.org> References: <1202893163.3771.33.camel@faramir.m3w.org> Message-ID: <20080213223804.jkey99zegwks8sc4@mail.elegosoft.com> As a first step, I've added p204 to the regression tests in m3tests which contains this program: MODULE Main; IMPORT IO, IP; CONST null = IP.Address{a := ARRAY OF BITS 8 FOR [0..255] {0,0,0,0}}; VAR addr: IP.Address; one := IP.Address{a := ARRAY OF BITS 8 FOR [0..255] {1,1,1,1}}; BEGIN addr := IP.Address{a := ARRAY OF BITS 8 FOR [0..255] {87,250,125,7}}; addr := null; addr := one; IO.Put("OK\n"); END Main. Initializers null and one work, only the one in the main body leads to code generation errors: "../src/Main.m3", line 1: 4 code generation errors 1 error encountered Any volunteers? -- Olaf Wagner -- elego Software Solutions GmbH 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 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From darko at darko.org Thu Feb 14 01:10:18 2008 From: darko at darko.org (Darko) Date: Thu, 14 Feb 2008 11:10:18 +1100 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <47B2E62D.1E75.00D7.1@scires.com> References: Your message of "Tue, 12 Feb 2008 18:54:50 EST." <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> <47B2E62D.1E75.00D7.1@scires.com> Message-ID: <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> I actually see some benefit to Jay's postings since they make us examine some of the differences between M3 and C and explain the benefits. These questions might be asked by any C programmer approaching the M3 language. It may be the point that Jay hasn't created and serious software in M3 and needs to be informed of the benefits. I've seen some good responses along these lines from members of the list. But Randy does have a valid point. M3 is is not just different to C, it's the antithesis of C. It's everything C isn't and the language designers went to great lengths to make it this way. It's why most of us use the language. I certainly wouldn't like to drive anyone away because they have a different point of view, but it may be a good idea to examine problems and solutions more closely and offer other solutions that 'why not do it like C'. In the case of printf, it is useful, when debugging especially, and I've created some code which takes a list of refany parameters and prints them out. It is a bit inefficient since any 'atomic' values such as integers need to be allocated but it also prints out all the fields of structures and arrays. But it is completely safe. If there were a need for a more efficient way to generated formatted strings, I'd write something else more efficient but also configurable since embedding fixed strings in your code is generally a a bad idea. On 14/02/2008, at 4:44 AM, Randy Coleburn wrote: > Jay: > > I don't want to be offensive, but quite frankly I'm tired of > continually reading your gripes about Modula-3 as a language and > your pining for C. > > This forum is for those people interested in advancing the state of > Modula-3. We don't care about C/C++/C#/etc in this forum. Those of > us who are M3 zealots for the most part probably would welcome any > move to divest CM3 of all underpinnings from the C world. > > Have you seriously studied the Modula-3 language and used it to > build production software? I think some of your comments suggest > that you are not a true Modula-3 programmer and that you still cling > to the C-way of doing things rather than embracing the Modula-3 way. > > Now, I do think that most people are interested in improving things > and no language is perfect, so any well-thought-out proposal for a > change to the language is welcome for consideration, But in this > mail list forum, I for one would appreciate less ranting about C and > more constructive Modula-3. > > Truly, I do not want to offend you. Maybe I'm just having a bad > day, but I encourage you to try and focus your posts to the > advancement of Modula-3. > > Regards, > Randy > > >>> Jay 2/12/2008 11:28 PM >>> > > >My principle concern is that once we provide C APIs then C will > > >permeate the M3 space more pervasively (both apps and libraries). > > This is somewhat my point. > When I am debugging, I really miss printf. > > The debugging options seem really poor everywhere and esp. on NT386. > > gdb has all wierded out variable names for one thing. > And I think we should fix it so that that the symbols have full > source paths. > I realize they would only be correct on one machine, and hopefully > there's a decent story for copying the files. > Yeah, I know about "dir" but haven't yet formed a .gdbinit or whatnot. > > Other than printf'ing, I also end up getting a stack in cdb with no > symbols and then disasm in gdb to find what the functions were. That > works fine a few times, but I hope not to do it often. Somewhat > lucky I could even get a stack. Because, see, cdb is nice enough to > stop on access violations by default (such as the time/date code was > causing). gdb has a promising sounding feature, the ability to stop > on "signals", which I think an access violation would count as, oh, > but that feature isn't implemented, sorry. Ok, true, think about it > more and I can break on the toplevel exception handler in > cygwin1.dll, not sure that always works or not, it's an > implementation detail, but heck, when you are debugging, take > advantage of whatever you have. :) > > RTIO, is too verbose for me. > But darnit, I can't really have printf..puts is about the best I > could do.. > Oh, but no, since TEXT != char* even that isn't useful. > fread/fwrite maybe though. > > On a different hand (how many are there? :) ), have you looked in > m3core\src\unix? > There is just tons of dead stuff, stuff with comments about it > perhaps being wrong, "use with care". > It seemed to me maybe the point was to expose "all" of /usr/include. > Someone, other than me, sure seems to have gone overboard, like > someone using Ultrix and Linux 1.x, and then it copied around. > Heck, look at the mem* functions being commented out (and probably > using the incorrect type int) because Ultrix or somesuch didn't have > them. I uncommented them to fix a build. And notice that these > functions, again, like most of printf, are /extremely/ portable in > functionality and exact binary interface (yeah yeah, I've heard of > bcopy and bzero). > > What there was of Cstdio.i3 seemed very possibly wrong, at least on > many targets, and very doubtfully useful for anything, and I think > I've now shown unused. > > > Y, the easiest way to implement the interface is to call a C > function > > that "just happens" to have the correct interface. But on another > > But wrapping everything in Modula-3 is so tedious... > Oh for all languages to just understand C headers so we can stop > rewriting them... > Or some other language, ok...not going to be solved in this forum. > To go the unpopular route (again), MS CLR/.NET among many other > things, attempts to solve this very problem. > One way to describe "interfaces" that "all" languages can > understand...at least for some subset of languages features.. > > Just as tedious btw, it is often more portable to wrap all the C > APIs in C, exposing a portable controled Modula-3 interface > independent of the precise header content. Like errno and my > get_stderr/out/in. > > - Jay > > > > To: hosking at cs.purdue.edu > > Date: Tue, 12 Feb 2008 16:37:43 -0800 > > From: mika at async.caltech.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] "target specific pragmas"? > > > > > > This is also an excellent reason not to permit "interfaces" to C > > code inlined into MODULEs. > > > > Interfaces are the contract that the implementation has to live up > > to. Ok, so it happens that under operating system X on architecture > > Y, the easiest way to implement the interface is to call a C > function > > that "just happens" to have the correct interface. But on another > > system, which either isn't built in C or where the function doesn't > > exist, it might be convenient to implement the interface in (gasp!) > > Modula-3! > > > > (I use this pattern as follows: on systems where Intel's Fortran > > compiler is available, compile from assembly (which was generated > > by ifort). On other systems, the code is implemented in Modula-3.) > > > > Mika > > > > Tony Hosking writes: > > >My principle concern is that once we provide C APIs then C will > > >permeate the M3 space more pervasively (both apps and libraries). > > >What happens when I want to bring up a system where there is no > > >C?!?! Consider the SPIN OS perhaps... > > > > > >Maybe I am just being overly fusty... > > > > > >On Feb 12, 2008, at 4:35 PM, Dragi??a Duri?? wrote: > > > > > >> What we _maybe_ can do... is to make some special, preprocessable > > >> source > > >> form, which some quake command can parse into multiple files in > their > > >> folders. And these file can be compiled later...Kind of how > generic > > >> works. > > >> > > >> But, as current system works, and it does it very well, and as > only > > >> case > > >> where we really need this is Windows... most Unices being or > becoming > > >> POSIX... I don't see it's smart to spend resources on becoming > more > > >> C... > > >> Esp when "founding fathers" made it so good and so much non-C :). > > >> > > >> If we really need to make some approach to "their world", it's > much > > >> better to work on interoperability issues and thus cement our > > >> first-class-citizen language status even more. > > >> > > >> dd > > >> > > >> On Tue, 2008-02-12 at 15:16 -0500, Randy Coleburn wrote: > > >>> Jay: > > >>> > > >>> My understanding of Modula-3 is that rather than cluttering up > the > > >>> source code with a bunch of preprocessor directives to deal > with the > > >>> various changes needed by various platforms, a separate source > > >>> file is > > >>> used for platforms whose implementation must diverge. The > m3makefile > > >>> is used to control the selection of these platform sources at > build > > >>> time. I like this approach much better. > > >>> > > >>> Regards, > > >>> Randy > > >>> > > >>>>>> Jay 2/11/2008 8:21 PM >>> > > >>> So I have NOT thought this through. > > >>> > > >>> I wonder if "preprocessing" dependent only on "target" is a good > > >>> idea. > > >>> > > >>> Something like either the ability to prefix pragmas with a > target, or > > >>> an "iftarget" and "ifnottarget" pragma. > > >>> > > >>> Something like so: > > >>> > > >>> <* IF_TARGET NT386 *> > > >>> <* END_IF_TARGET*> > > >>> > > >>> > > >>> <* IF_TARGET NT386 *> > > >>> <* END_IF_TARGET*> > > >>> It's a small can of worms. > > >>> Where can they be placed? Only at "global" scope? (ie: > toplevel in an > > >>> interface/module). > > >>> > > >>> What about IF_OSTYPE? > > >>> What about expressions? > > >>> IF_TARGET NT386 OR NTAMD64 > > >>> > > >>> IF_TARGET STARTS(NT) > > >>> > > >>> etc. > > >>> > > >>> I don't really have enough interest here to work through this, > just > > >>> sending out the bait... > > >>> > > >>> Obviously this was triggered by my happening into the odbc > directory > > >>> and bringing up ignoring WINAPI on non-NT386 or prefixing > calling > > >>> conventions with a target. > > >>> > > >>> This reminds me of an important point here however -- nobody > else is > > >>> going to make the mistake of ever having multiple calling > > >>> conventions. > > >>> Therefore the generality of prefixing WINAPI with NT386: is > useless. > > >>> Unless Mac68K support is added. > > >>> > > >>> And here is some rationale even. The PC and Mac evolved from > "small" > > >>> systems, where assembly programming was common, more people > knew more > > >>> lower level details and playing games with calling conventions > was > > >>> something anyone could do. Most other current systems are > rooted in C > > >>> programming. Working in C, calling conventions are generally > in a > > >>> hidden layer below what anyone thinks about. Therefore, the > smaller > > >>> number of capable people working at that level have the good > sense to > > >>> only have one calling convention. No more systems will evolve > from > > >>> "small", at least not without having observed this history. > > >>> Therefore, > > >>> there will no longer be multiple calling conventions. > > >>> > > >>> That is my theory at least. > > >>> > > >>> Oh, Windows does also have __thiscall and __clrcall. > __thiscall is > > >>> only x86 > > >> -- > > >> Dragi??a Duri?? > > > Connect and share in new ways with Windows Live. Get it now! From jayk123 at hotmail.com Thu Feb 14 01:34:44 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 14 Feb 2008 00:34:44 +0000 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> References: Your message of "Tue, 12 Feb 2008 18:54:50 EST." <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> <47B2E62D.1E75.00D7.1@scires.com> <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> Message-ID: I'll try to repeat myself less and ramble less, and stay constructive... I understand that printf type unsafety stinks and I have been bitten by it, but it is nicely terse, crude but effective, I'm going to throw away the code probably once the bug is fixed. (Ok, I like to comment out or somehow disable sometimes maybe but that is a different point, it's still not the height of production code; and yes, I realize it's a slippery slope and the next thing I'll do is use it in production code; debugging is just what I'm doing now, next up, real code). You can't just be the antithesis of C. You have to decide what it is about C that is wrong and fix it or do it over. And then of course, agreement on what is wrong. I probably see less wrong than you. Bad module system -- #include. Bad module system -- preprocesor which kills or damages other efforts at language-aware tools. Beyond this, at the moment, I am unsure. I have "argued for" C++ for further "problems" in C, but I have "grown" (or shrunk? :) ) to appreciate that C might not be as bad as I used to think. If you start over completely from scratch, you should still look at what is out there. Granted, some things are mostly arbitrary. Braces vs. begin/end. But the editors all support braces now. Until you get me to change editors (probably never), Modula-3 is always going to be less convenient. At this point you are just fighting the vast majority (except Python...). It could have gone differently, but C won. If you ignore that lowest level thing, there are places where Modula-3 is perfectly good, but doesn't take the next step. A good example I think here is it has nice "objects", however it requires they be heap allocated I think even in unsafe code. You should be able stack (or global) allocate something with "virtual functions". It seems an arbitrary limitation. I realize in safe code, you have to heap allocate more anyway, but that is a different point I think. Similarly is "multiple inheritance just of interfaces". I realize though..this hides a "vtable per interface". Maybe is much more expensive than people realize and shouldn't be provided lightly. SUBARRAY is probably example where I don't/didn't know the language well enough. And maybe the docs aren't good here. And VAR/BEGIN. Maybe I just need to reread Nelson's book. You know..reference vs. tutorial. The language reference is very very terse and that is ok. Short on examples. A tutorial that gives many examples might be good. Hey maybe I'm just the newbie in a good position to write it. (not) I guess I should be in comp.lang.c.advocacy. :) To a large extent I'm just looking for a small smart group to have a friendly intellectual discussion with. (and of course, don't mess up their code) - Jay > CC: jayk123 at hotmail.com; m3devel at elegosoft.com> From: darko at darko.org> To: rcoleburn at scires.com> Subject: Re: [M3devel] "target specific pragmas"?> Date: Thu, 14 Feb 2008 11:10:18 +1100> > I actually see some benefit to Jay's postings since they make us > examine some of the differences between M3 and C and explain the > benefits. These questions might be asked by any C programmer > approaching the M3 language. It may be the point that Jay hasn't > created and serious software in M3 and needs to be informed of the > benefits. I've seen some good responses along these lines from members > of the list.> > But Randy does have a valid point. M3 is is not just different to C, > it's the antithesis of C. It's everything C isn't and the language > designers went to great lengths to make it this way. It's why most of > us use the language.> > I certainly wouldn't like to drive anyone away because they have a > different point of view, but it may be a good idea to examine problems > and solutions more closely and offer other solutions that 'why not do > it like C'.> > In the case of printf, it is useful, when debugging especially, and > I've created some code which takes a list of refany parameters and > prints them out. It is a bit inefficient since any 'atomic' values > such as integers need to be allocated but it also prints out all the > fields of structures and arrays. But it is completely safe. If there > were a need for a more efficient way to generated formatted strings, > I'd write something else more efficient but also configurable since > embedding fixed strings in your code is generally a a bad idea.> > > On 14/02/2008, at 4:44 AM, Randy Coleburn wrote:> > > Jay:> >> > I don't want to be offensive, but quite frankly I'm tired of > > continually reading your gripes about Modula-3 as a language and > > your pining for C.> >> > This forum is for those people interested in advancing the state of > > Modula-3. We don't care about C/C++/C#/etc in this forum. Those of > > us who are M3 zealots for the most part probably would welcome any > > move to divest CM3 of all underpinnings from the C world.> >> > Have you seriously studied the Modula-3 language and used it to > > build production software? I think some of your comments suggest > > that you are not a true Modula-3 programmer and that you still cling > > to the C-way of doing things rather than embracing the Modula-3 way.> >> > Now, I do think that most people are interested in improving things > > and no language is perfect, so any well-thought-out proposal for a > > change to the language is welcome for consideration, But in this > > mail list forum, I for one would appreciate less ranting about C and > > more constructive Modula-3.> >> > Truly, I do not want to offend you. Maybe I'm just having a bad > > day, but I encourage you to try and focus your posts to the > > advancement of Modula-3.> >> > Regards,> > Randy> >> > >>> Jay 2/12/2008 11:28 PM >>>> > > >My principle concern is that once we provide C APIs then C will> > > >permeate the M3 space more pervasively (both apps and libraries).> >> > This is somewhat my point.> > When I am debugging, I really miss printf.> >> > The debugging options seem really poor everywhere and esp. on NT386.> >> > gdb has all wierded out variable names for one thing.> > And I think we should fix it so that that the symbols have full > > source paths.> > I realize they would only be correct on one machine, and hopefully > > there's a decent story for copying the files.> > Yeah, I know about "dir" but haven't yet formed a .gdbinit or whatnot.> >> > Other than printf'ing, I also end up getting a stack in cdb with no > > symbols and then disasm in gdb to find what the functions were. That > > works fine a few times, but I hope not to do it often. Somewhat > > lucky I could even get a stack. Because, see, cdb is nice enough to > > stop on access violations by default (such as the time/date code was > > causing). gdb has a promising sounding feature, the ability to stop > > on "signals", which I think an access violation would count as, oh, > > but that feature isn't implemented, sorry. Ok, true, think about it > > more and I can break on the toplevel exception handler in > > cygwin1.dll, not sure that always works or not, it's an > > implementation detail, but heck, when you are debugging, take > > advantage of whatever you have. :)> >> > RTIO, is too verbose for me.> > But darnit, I can't really have printf..puts is about the best I > > could do..> > Oh, but no, since TEXT != char* even that isn't useful.> > fread/fwrite maybe though.> >> > On a different hand (how many are there? :) ), have you looked in > > m3core\src\unix?> > There is just tons of dead stuff, stuff with comments about it > > perhaps being wrong, "use with care".> > It seemed to me maybe the point was to expose "all" of /usr/include.> > Someone, other than me, sure seems to have gone overboard, like > > someone using Ultrix and Linux 1.x, and then it copied around.> > Heck, look at the mem* functions being commented out (and probably > > using the incorrect type int) because Ultrix or somesuch didn't have > > them. I uncommented them to fix a build. And notice that these > > functions, again, like most of printf, are /extremely/ portable in > > functionality and exact binary interface (yeah yeah, I've heard of > > bcopy and bzero).> >> > What there was of Cstdio.i3 seemed very possibly wrong, at least on > > many targets, and very doubtfully useful for anything, and I think > > I've now shown unused.> >> > > Y, the easiest way to implement the interface is to call a C > > function> > > that "just happens" to have the correct interface. But on another> >> > But wrapping everything in Modula-3 is so tedious...> > Oh for all languages to just understand C headers so we can stop > > rewriting them...> > Or some other language, ok...not going to be solved in this forum.> > To go the unpopular route (again), MS CLR/.NET among many other > > things, attempts to solve this very problem.> > One way to describe "interfaces" that "all" languages can > > understand...at least for some subset of languages features..> >> > Just as tedious btw, it is often more portable to wrap all the C > > APIs in C, exposing a portable controled Modula-3 interface > > independent of the precise header content. Like errno and my > > get_stderr/out/in.> >> > - Jay> >> >> > > To: hosking at cs.purdue.edu> > > Date: Tue, 12 Feb 2008 16:37:43 -0800> > > From: mika at async.caltech.edu> > > CC: m3devel at elegosoft.com> > > Subject: Re: [M3devel] "target specific pragmas"?> > >> > >> > > This is also an excellent reason not to permit "interfaces" to C> > > code inlined into MODULEs.> > >> > > Interfaces are the contract that the implementation has to live up> > > to. Ok, so it happens that under operating system X on architecture> > > Y, the easiest way to implement the interface is to call a C > > function> > > that "just happens" to have the correct interface. But on another> > > system, which either isn't built in C or where the function doesn't> > > exist, it might be convenient to implement the interface in (gasp!)> > > Modula-3!> > >> > > (I use this pattern as follows: on systems where Intel's Fortran> > > compiler is available, compile from assembly (which was generated> > > by ifort). On other systems, the code is implemented in Modula-3.)> > >> > > Mika> > >> > > Tony Hosking writes:> > > >My principle concern is that once we provide C APIs then C will> > > >permeate the M3 space more pervasively (both apps and libraries).> > > >What happens when I want to bring up a system where there is no> > > >C?!?! Consider the SPIN OS perhaps...> > > >> > > >Maybe I am just being overly fusty...> > > >> > > >On Feb 12, 2008, at 4:35 PM, Dragi??a Duri?? wrote:> > > >> > > >> What we _maybe_ can do... is to make some special, preprocessable> > > >> source> > > >> form, which some quake command can parse into multiple files in > > their> > > >> folders. And these file can be compiled later...Kind of how > > generic> > > >> works.> > > >>> > > >> But, as current system works, and it does it very well, and as > > only> > > >> case> > > >> where we really need this is Windows... most Unices being or > > becoming> > > >> POSIX... I don't see it's smart to spend resources on becoming > > more> > > >> C...> > > >> Esp when "founding fathers" made it so good and so much non-C :).> > > >>> > > >> If we really need to make some approach to "their world", it's > > much> > > >> better to work on interoperability issues and thus cement our> > > >> first-class-citizen language status even more.> > > >>> > > >> dd> > > >>> > > >> On Tue, 2008-02-12 at 15:16 -0500, Randy Coleburn wrote:> > > >>> Jay:> > > >>>> > > >>> My understanding of Modula-3 is that rather than cluttering up > > the> > > >>> source code with a bunch of preprocessor directives to deal > > with the> > > >>> various changes needed by various platforms, a separate source> > > >>> file is> > > >>> used for platforms whose implementation must diverge. The > > m3makefile> > > >>> is used to control the selection of these platform sources at > > build> > > >>> time. I like this approach much better.> > > >>>> > > >>> Regards,> > > >>> Randy> > > >>>> > > >>>>>> Jay 2/11/2008 8:21 PM >>>> > > >>> So I have NOT thought this through.> > > >>>> > > >>> I wonder if "preprocessing" dependent only on "target" is a good> > > >>> idea.> > > >>>> > > >>> Something like either the ability to prefix pragmas with a > > target, or> > > >>> an "iftarget" and "ifnottarget" pragma.> > > >>>> > > >>> Something like so:> > > >>>> > > >>> <* IF_TARGET NT386 *>> > > >>> <* END_IF_TARGET*>> > > >>>> > > >>>> > > >>> <* IF_TARGET NT386 *>> > > >>> <* END_IF_TARGET*>> > > >>> It's a small can of worms.> > > >>> Where can they be placed? Only at "global" scope? (ie: > > toplevel in an> > > >>> interface/module).> > > >>>> > > >>> What about IF_OSTYPE?> > > >>> What about expressions?> > > >>> IF_TARGET NT386 OR NTAMD64> > > >>>> > > >>> IF_TARGET STARTS(NT)> > > >>>> > > >>> etc.> > > >>>> > > >>> I don't really have enough interest here to work through this, > > just> > > >>> sending out the bait...> > > >>>> > > >>> Obviously this was triggered by my happening into the odbc > > directory> > > >>> and bringing up ignoring WINAPI on non-NT386 or prefixing > > calling> > > >>> conventions with a target.> > > >>>> > > >>> This reminds me of an important point here however -- nobody > > else is> > > >>> going to make the mistake of ever having multiple calling> > > >>> conventions.> > > >>> Therefore the generality of prefixing WINAPI with NT386: is > > useless.> > > >>> Unless Mac68K support is added.> > > >>>> > > >>> And here is some rationale even. The PC and Mac evolved from > > "small"> > > >>> systems, where assembly programming was common, more people > > knew more> > > >>> lower level details and playing games with calling conventions > > was> > > >>> something anyone could do. Most other current systems are > > rooted in C> > > >>> programming. Working in C, calling conventions are generally > > in a> > > >>> hidden layer below what anyone thinks about. Therefore, the > > smaller> > > >>> number of capable people working at that level have the good > > sense to> > > >>> only have one calling convention. No more systems will evolve > > from> > > >>> "small", at least not without having observed this history.> > > >>> Therefore,> > > >>> there will no longer be multiple calling conventions.> > > >>>> > > >>> That is my theory at least.> > > >>>> > > >>> Oh, Windows does also have __thiscall and __clrcall. > > __thiscall is> > > >>> only x86> > > >> --> > > >> Dragi??a Duri?? > >> >> > Connect and share in new ways with Windows Live. Get it now!> _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From darko at darko.org Thu Feb 14 02:09:40 2008 From: darko at darko.org (Darko) Date: Thu, 14 Feb 2008 12:09:40 +1100 Subject: [M3devel] "target specific pragmas"? In-Reply-To: References: Your message of "Tue, 12 Feb 2008 18:54:50 EST." <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> <47B2E62D.1E75.00D7.1@scires.com> <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> Message-ID: <5973F6E5-D030-4AF6-A28A-3D5172D130A6@darko.org> M3 is the antithesis in the sense that it takes the opposite approach. C has few protections, M3 has many. M3 does examine what was wrong with C and other languages and fix them and it did a good job. The M3 design team made an explicit goal to look at features from other languages and take the best. The fact that M3 works so well is the proof. Some of the things you raise, like braces or stack allocations of objects are just features of C++ with no justification. Can you show that typing less characters is important? You say M3 is less convenient, but what is less convenient, less typing or less bugs? Do you spend most of your time typing or thinking when you write code? Should language include every feature anyone can think of? How is excluding unimportant features 'arbitrary'? Each feature must be weighed to avoid unnecessary complexity and size, which have a direct impact on compiler maintainability and language usability. Language bloat is a real problem. I doubt that anyone understands the full semantics of C++. You say that C has 'won', but in what sense? More people use it? Language design is not American Idol, it's not a question of who has the most votes. You have to do more than list features of C or C++ and your opinions on them. You have to provide some rationale as to their benefit which convinces people. On 14/02/2008, at 11:34 AM, Jay wrote: > I'll try to repeat myself less and ramble less, and stay > constructive... > > I understand that printf type unsafety stinks and I have been bitten > by it, but it is nicely terse, crude but effective, I'm going to > throw away the code probably once the bug is fixed. (Ok, I like to > comment out or somehow disable sometimes maybe but that is a > different point, it's still not the height of production code; and > yes, I realize it's a slippery slope and the next thing I'll do is > use it in production code; debugging is just what I'm doing now, > next up, real code). > > You can't just be the antithesis of C. You have to decide what it is > about C that is wrong and fix it or do it over. > And then of course, agreement on what is wrong. I probably see less > wrong than you. > Bad module system -- #include. > Bad module system -- preprocesor which kills or damages other > efforts at language-aware tools. > Beyond this, at the moment, I am unsure. > I have "argued for" C++ for further "problems" in C, but I have > "grown" (or shrunk? :) ) to appreciate that C might not be as bad as > I used to think. > > If you start over completely from scratch, you should still look at > what is out there. > Granted, some things are mostly arbitrary. Braces vs. begin/end. But > the editors all support braces now. > Until you get me to change editors (probably never), Modula-3 is > always going to be less convenient. > At this point you are just fighting the vast majority (except > Python...). It could have gone differently, but C won. > > If you ignore that lowest level thing, there are places where > Modula-3 is perfectly good, but doesn't take the next step. > A good example I think here is it has nice "objects", however it > requires they be heap allocated I think even in unsafe code. You > should be able stack (or global) allocate something with "virtual > functions". It seems an arbitrary limitation. I realize in safe > code, you have to heap allocate more anyway, but that is a different > point I think. > > Similarly is "multiple inheritance just of interfaces". I realize > though..this hides a "vtable per interface". Maybe is much more > expensive than people realize and shouldn't be provided lightly. > > SUBARRAY is probably example where I don't/didn't know the language > well enough. > And maybe the docs aren't good here. > And VAR/BEGIN. > Maybe I just need to reread Nelson's book. You know..reference vs. > tutorial. The language reference is very very terse and that is ok. > Short on examples. A tutorial that gives many examples might be > good. Hey maybe I'm just the newbie in a good position to write it. > (not) > > I guess I should be in comp.lang.c.advocacy. :) > > To a large extent I'm just looking for a small smart group to have a > friendly intellectual discussion with. > (and of course, don't mess up their code) > > - Jay > > > > > CC: jayk123 at hotmail.com; m3devel at elegosoft.com > > From: darko at darko.org > > To: rcoleburn at scires.com > > Subject: Re: [M3devel] "target specific pragmas"? > > Date: Thu, 14 Feb 2008 11:10:18 +1100 > > > > I actually see some benefit to Jay's postings since they make us > > examine some of the differences between M3 and C and explain the > > benefits. These questions might be asked by any C programmer > > approaching the M3 language. It may be the point that Jay hasn't > > created and serious software in M3 and needs to be informed of the > > benefits. I've seen some good responses along these lines from > members > > of the list. > > > > But Randy does have a valid point. M3 is is not just different to C, > > it's the antithesis of C. It's everything C isn't and the language > > designers went to great lengths to make it this way. It's why most > of > > us use the language. > > > > I certainly wouldn't like to drive anyone away because they have a > > different point of view, but it may be a good idea to examine > problems > > and solutions more closely and offer other solutions that 'why not > do > > it like C'. > > > > In the case of printf, it is useful, when debugging especially, and > > I've created some code which takes a list of refany parameters and > > prints them out. It is a bit inefficient since any 'atomic' values > > such as integers need to be allocated but it also prints out all the > > fields of structures and arrays. But it is completely safe. If there > > were a need for a more efficient way to generated formatted strings, > > I'd write something else more efficient but also configurable since > > embedding fixed strings in your code is generally a a bad idea. > > > > > > On 14/02/2008, at 4:44 AM, Randy Coleburn wrote: > > > > > Jay: > > > > > > I don't want to be offensive, but quite frankly I'm tired of > > > continually reading your gripes about Modula-3 as a language and > > > your pining for C. > > > > > > This forum is for those people interested in advancing the state > of > > > Modula-3. We don't care about C/C++/C#/etc in this forum. Those of > > > us who are M3 zealots for the most part probably would welcome any > > > move to divest CM3 of all underpinnings from the C world. > > > > > > Have you seriously studied the Modula-3 language and used it to > > > build production software? I think some of your comments suggest > > > that you are not a true Modula-3 programmer and that you still > cling > > > to the C-way of doing things rather than embracing the Modula-3 > way. > > > > > > Now, I do think that most people are interested in improving > things > > > and no language is perfect, so any well-thought-out proposal for a > > > change to the language is welcome for consideration, But in this > > > mail list forum, I for one would appreciate less ranting about C > and > > > more constructive Modula-3. > > > > > > Truly, I do not want to offend you. Maybe I'm just having a bad > > > day, but I encourage you to try and focus your posts to the > > > advancement of Modula-3. > > > > > > Regards, > > > Randy > > > > > > >>> Jay 2/12/2008 11:28 PM >>> > > > > >My principle concern is that once we provide C APIs then C will > > > > >permeate the M3 space more pervasively (both apps and > libraries). > > > > > > This is somewhat my point. > > > When I am debugging, I really miss printf. > > > > > > The debugging options seem really poor everywhere and esp. on > NT386. > > > > > > gdb has all wierded out variable names for one thing. > > > And I think we should fix it so that that the symbols have full > > > source paths. > > > I realize they would only be correct on one machine, and hopefully > > > there's a decent story for copying the files. > > > Yeah, I know about "dir" but haven't yet formed a .gdbinit or > whatnot. > > > > > > Other than printf'ing, I also end up getting a stack in cdb with > no > > > symbols and then disasm in gdb to find what the functions were. > That > > > works fine a few times, but I hope not to do it often. Somewhat > > > lucky I could even get a stack. Because, see, cdb is nice enough > to > > > stop on access violations by default (such as the time/date code > was > > > causing). gdb has a promising sounding feature, the ability to > stop > > > on "signals", which I think an access violation would count as, > oh, > > > but that feature isn't implemented, sorry. Ok, true, think about > it > > > more and I can break on the toplevel exception handler in > > > cygwin1.dll, not sure that always works or not, it's an > > > implementation detail, but heck, when you are debugging, take > > > advantage of whatever you have. :) > > > > > > RTIO, is too verbose for me. > > > But darnit, I can't really have printf..puts is about the best I > > > could do.. > > > Oh, but no, since TEXT != char* even that isn't useful. > > > fread/fwrite maybe though. > > > > > > On a different hand (how many are there? :) ), have you looked in > > > m3core\src\unix? > > > There is just tons of dead stuff, stuff with comments about it > > > perhaps being wrong, "use with care". > > > It seemed to me maybe the point was to expose "all" of /usr/ > include. > > > Someone, other than me, sure seems to have gone overboard, like > > > someone using Ultrix and Linux 1.x, and then it copied around. > > > Heck, look at the mem* functions being commented out (and probably > > > using the incorrect type int) because Ultrix or somesuch didn't > have > > > them. I uncommented them to fix a build. And notice that these > > > functions, again, like most of printf, are /extremely/ portable in > > > functionality and exact binary interface (yeah yeah, I've heard of > > > bcopy and bzero). > > > > > > What there was of Cstdio.i3 seemed very possibly wrong, at least > on > > > many targets, and very doubtfully useful for anything, and I think > > > I've now shown unused. > > > > > > > Y, the easiest way to implement the interface is to call a C > > > function > > > > that "just happens" to have the correct interface. But on > another > > > > > > But wrapping everything in Modula-3 is so tedious... > > > Oh for all languages to just understand C headers so we can stop > > > rewriting them... > > > Or some other language, ok...not going to be solved in this forum. > > > To go the unpopular route (again), MS CLR/.NET among many other > > > things, attempts to solve this very problem. > > > One way to describe "interfaces" that "all" languages can > > > understand...at least for some subset of languages features.. > > > > > > Just as tedious btw, it is often more portable to wrap all the C > > > APIs in C, exposing a portable controled Modula-3 interface > > > independent of the precise header content. Like errno and my > > > get_stderr/out/in. > > > > > > - Jay > > > > > > > > > > To: hosking at cs.purdue.edu > > > > Date: Tue, 12 Feb 2008 16:37:43 -0800 > > > > From: mika at async.caltech.edu > > > > CC: m3devel at elegosoft.com > > > > Subject: Re: [M3devel] "target specific pragmas"? > > > > > > > > > > > > This is also an excellent reason not to permit "interfaces" to C > > > > code inlined into MODULEs. > > > > > > > > Interfaces are the contract that the implementation has to > live up > > > > to. Ok, so it happens that under operating system X on > architecture > > > > Y, the easiest way to implement the interface is to call a C > > > function > > > > that "just happens" to have the correct interface. But on > another > > > > system, which either isn't built in C or where the function > doesn't > > > > exist, it might be convenient to implement the interface in > (gasp!) > > > > Modula-3! > > > > > > > > (I use this pattern as follows: on systems where Intel's Fortran > > > > compiler is available, compile from assembly (which was > generated > > > > by ifort). On other systems, the code is implemented in > Modula-3.) > > > > > > > > Mika > > > > > > > > Tony Hosking writes: > > > > >My principle concern is that once we provide C APIs then C will > > > > >permeate the M3 space more pervasively (both apps and > libraries). > > > > >What happens when I want to bring up a system where there is no > > > > >C?!?! Consider the SPIN OS perhaps... > > > > > > > > > >Maybe I am just being overly fusty... > > > > > > > > > >On Feb 12, 2008, at 4:35 PM, Dragi??a Duri?? wrote: > > > > > > > > > >> What we _maybe_ can do... is to make some special, > preprocessable > > > > >> source > > > > >> form, which some quake command can parse into multiple > files in > > > their > > > > >> folders. And these file can be compiled later...Kind of how > > > generic > > > > >> works. > > > > >> > > > > >> But, as current system works, and it does it very well, and > as > > > only > > > > >> case > > > > >> where we really need this is Windows... most Unices being or > > > becoming > > > > >> POSIX... I don't see it's smart to spend resources on > becoming > > > more > > > > >> C... > > > > >> Esp when "founding fathers" made it so good and so much non- > C :). > > > > >> > > > > >> If we really need to make some approach to "their world", > it's > > > much > > > > >> better to work on interoperability issues and thus cement our > > > > >> first-class-citizen language status even more. > > > > >> > > > > >> dd > > > > >> > > > > >> On Tue, 2008-02-12 at 15:16 -0500, Randy Coleburn wrote: > > > > >>> Jay: > > > > >>> > > > > >>> My understanding of Modula-3 is that rather than > cluttering up > > > the > > > > >>> source code with a bunch of preprocessor directives to deal > > > with the > > > > >>> various changes needed by various platforms, a separate > source > > > > >>> file is > > > > >>> used for platforms whose implementation must diverge. The > > > m3makefile > > > > >>> is used to control the selection of these platform sources > at > > > build > > > > >>> time. I like this approach much better. > > > > >>> > > > > >>> Regards, > > > > >>> Randy > > > > >>> > > > > >>>>>> Jay 2/11/2008 8:21 PM >>> > > > > >>> So I have NOT thought this through. > > > > >>> > > > > >>> I wonder if "preprocessing" dependent only on "target" is > a good > > > > >>> idea. > > > > >>> > > > > >>> Something like either the ability to prefix pragmas with a > > > target, or > > > > >>> an "iftarget" and "ifnottarget" pragma. > > > > >>> > > > > >>> Something like so: > > > > >>> > > > > >>> <* IF_TARGET NT386 *> > > > > >>> <* END_IF_TARGET*> > > > > >>> > > > > >>> > > > > >>> <* IF_TARGET NT386 *> > > > > >>> <* END_IF_TARGET*> > > > > >>> It's a small can of worms. > > > > >>> Where can they be placed? Only at "global" scope? (ie: > > > toplevel in an > > > > >>> interface/module). > > > > >>> > > > > >>> What about IF_OSTYPE? > > > > >>> What about expressions? > > > > >>> IF_TARGET NT386 OR NTAMD64 > > > > >>> > > > > >>> IF_TARGET STARTS(NT) > > > > >>> > > > > >>> etc. > > > > >>> > > > > >>> I don't really have enough interest here to work through > this, > > > just > > > > >>> sending out the bait... > > > > >>> > > > > >>> Obviously this was triggered by my happening into the odbc > > > directory > > > > >>> and bringing up ignoring WINAPI on non-NT386 or prefixing > > > calling > > > > >>> conventions with a target. > > > > >>> > > > > >>> This reminds me of an important point here however -- nobody > > > else is > > > > >>> going to make the mistake of ever having multiple calling > > > > >>> conventions. > > > > >>> Therefore the generality of prefixing WINAPI with NT386: is > > > useless. > > > > >>> Unless Mac68K support is added. > > > > >>> > > > > >>> And here is some rationale even. The PC and Mac evolved from > > > "small" > > > > >>> systems, where assembly programming was common, more people > > > knew more > > > > >>> lower level details and playing games with calling > conventions > > > was > > > > >>> something anyone could do. Most other current systems are > > > rooted in C > > > > >>> programming. Working in C, calling conventions are generally > > > in a > > > > >>> hidden layer below what anyone thinks about. Therefore, the > > > smaller > > > > >>> number of capable people working at that level have the good > > > sense to > > > > >>> only have one calling convention. No more systems will > evolve > > > from > > > > >>> "small", at least not without having observed this history. > > > > >>> Therefore, > > > > >>> there will no longer be multiple calling conventions. > > > > >>> > > > > >>> That is my theory at least. > > > > >>> > > > > >>> Oh, Windows does also have __thiscall and __clrcall. > > > __thiscall is > > > > >>> only x86 > > > > >> -- > > > > >> Dragi??a Duri?? > > > > > > > > > Connect and share in new ways with Windows Live. Get it now! > > > > > Shed those extra pounds with MSN and The Biggest Loser! Learn more. From mika at async.caltech.edu Thu Feb 14 02:43:13 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Wed, 13 Feb 2008 17:43:13 -0800 Subject: [M3devel] "target specific pragmas"? In-Reply-To: Your message of "Thu, 14 Feb 2008 00:34:44 GMT." Message-ID: <200802140143.m1E1hDBv062411@camembert.async.caltech.edu> Jay writes: >--_26c72f2f-07a7-4258-b083-944d52866fbb_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > >I'll try to repeat myself less and ramble less, and stay constructive... >=20 >I understand that printf type unsafety stinks and I have been bitten by it,= > but it is nicely terse, crude but effective, I'm going to throw away the c= >ode probably once the bug is fixed. (Ok, I like to comment out or somehow d= >isable sometimes maybe but that is a different point, it's still not the he= >ight of production code; and yes, I realize it's a slippery slope and the n= >ext thing I'll do is use it in production code; debugging is just what I'm = >doing now, next up, real code). >=20 >You can't just be the antithesis of C. You have to decide what it is about = >C that is wrong and fix it or do it over. >And then of course, agreement on what is wrong. I probably see less wrong t= >han you. >Bad module system -- #include. >Bad module system -- preprocesor which kills or damages other efforts at la= >nguage-aware tools. >Beyond this, at the moment, I am unsure. A few things I know I like about M3, and don't exist in the C languages, are: * enumerated types that work well * integer subranges * arrays(!!) * arrays indexed by enumerations and subranges * absence of name mangling problems (I'm willing to accept Quake in return) * the ability to add code/declarations/types to ANY interface and not have it break a program. NO OTHER LANGUAGE (that I've heard of) HAS THIS PROPERTY. * a lot of other Java-ish properties, without being Java. >I have "argued for" C++ for further "problems" in C, but I have "grown" (or= > shrunk? :) ) to appreciate that C might not be as bad as I used to think. >=20 >If you start over completely from scratch, you should still look at what is= > out there. >Granted, some things are mostly arbitrary. Braces vs. begin/end. But the ed= >itors all support braces now. >Until you get me to change editors (probably never), Modula-3 is always goi= >ng to be less convenient. >At this point you are just fighting the vast majority (except Python...). I= >t could have gone differently, but C won. Yes it's a lot easier to code M3 in emacs... modula3.el is a wonderful little thing to have. >=20 >If you ignore that lowest level thing, there are places where Modula-3 is p= >erfectly good, but doesn't take the next step. >A good example I think here is it has nice "objects", however it requires t= >hey be heap allocated I think even in unsafe code. You should be able stack= > (or global) allocate something with "virtual functions". It seems an arbit= >rary limitation. I realize in safe code, you have to heap allocate more any= >way, but that is a different point I think. Not even C++ has virtual methods in stack-allocated objects does it? If there's a language that has a lot of arbitrary limitations in this area it's C++. It's kind of funny: if you know Modula-3, you start by wondering how C++ implements X, where X is a feature you would like but M3 lacks, and then you find that while C++ does indeed implement X', that is, X in a restricted sense, it does actually not implement X in the full generality you'd like. And for the same reasons that M3 doesn't touch it in the first place. Stack-allocated objects are an example of this. If you want stack-allocated data structures, use a RECORD and a PROCEDURE. That will give you almost exactly the same thing that a stack-allocated object gives you in C++! >=20 >Similarly is "multiple inheritance just of interfaces". I realize though..t= >his hides a "vtable per interface". Maybe is much more expensive than peopl= >e realize and shouldn't be provided lightly. >=20 >SUBARRAY is probably example where I don't/didn't know the language well en= >ough. > And maybe the docs aren't good here. >And VAR/BEGIN. >Maybe I just need to reread Nelson's book. You know..reference vs. tutorial= >. The language reference is very very terse and that is ok. Short on exampl= >es. A tutorial that gives many examples might be good. Hey maybe I'm just t= >he newbie in a good position to write it. (not) Try Harbison's book? Or read a lot of the SRC code. Some of it is quite beautiful. About C++: do you *really* know C++? I was reading Stroustrup's book a while back and after reading four or five times "if you want to try this, ask an experienced colleague first" I gave up in disgust on trying to understand C++. There are so many odd little ways you can go wrong in C++. Sometimes assigning an object to a variable causes your program to break in mysterious and horrible ways, sometimes... C++ programmers also tend to underestimate how effective garbage collection is in simplifying things. This is different from saying "garbage collection helps you avoid memory management errors" (because you say "I am a competent C++ programmer, I never make memory management errors"). Garbage collection lets you structure your code in ways that simply is not possible if you have to worry about which part of it is going to allocate and which part is going to deallocate memory. The last and probably biggest advantage of M3 over C++ is that you can look at a program and immediately know what it means. And also know that it *can't* mean anything else. The programmer couldn't, even if he was maximally sadistic, have overloaded equals to mean not-equals, right shift to mean left shift, and left shift to mean increment. C++ lets you do this, and there are a large number of programmers out there who seemingly take advantage of every language feature they can get their hands on that lets them obscure their programs. I would summarize it as follows. Modula-3 and C++ let you compile almost exactly the same machine code. Apart from that, Modula-3 does it in a way that lets you write safe programs, and C++ does it in a way that lets you write obscure programs. Something that has become increasingly clear to me is that Modula-3 and C++ live in something of a desert. There are very few modern programming languages that are as "close to the machine" as these two. All the work that people do today (that gets any attention) is in things like Java (which is incredibly complicated, have you ever tried to compile HotSpot?) and Python (which is all right but incredibly inefficient). The more academic languages like ML and things like Self... well I won't even say anything about those. If you want a safe language that works with traditional compiler tools, Modula-3 is just about the only one out there. Finally, there is something about Randy's comment that's very true. Modula-3 is a "dead language". People that "still" use it are going to be fanatics about why they use it, rather than C or C++. If you are asked what programming language you use for development, and you answer "Modula-3" people will almost always look at you like you're crazy. We do indeed use it because it is very different from C and C++, or else we would have saved ourselves a LOT of trouble (I forget just how many existing C and C++ libraries and tools I have reimplemented just so I could stay in Modula-3) by just going with the crowd. Mika >=20 >I guess I should be in comp.lang.c.advocacy. :) >=20 >To a large extent I'm just looking for a small smart group to have a friend= >ly intellectual discussion with. >(and of course, don't mess up their code) >=20 > - Jay > > > >> CC: jayk123 at hotmail.com; m3devel at elegosoft.com> From: darko at darko.org> To= >: rcoleburn at scires.com> Subject: Re: [M3devel] "target specific pragmas"?> = >Date: Thu, 14 Feb 2008 11:10:18 +1100> > I actually see some benefit to Jay= >'s postings since they make us > examine some of the differences between M3= > and C and explain the > benefits. These questions might be asked by any C = >programmer > approaching the M3 language. It may be the point that Jay hasn= >'t > created and serious software in M3 and needs to be informed of the > b= >enefits. I've seen some good responses along these lines from members > of = >the list.> > But Randy does have a valid point. M3 is is not just different= > to C, > it's the antithesis of C. It's everything C isn't and the language= > > designers went to great lengths to make it this way. It's why most of > = >us use the language.> > I certainly wouldn't like to drive anyone away beca= >use they have a > different point of view, but it may be a good idea to exa= >mine problems > and solutions more closely and offer other solutions that '= >why not do > it like C'.> > In the case of printf, it is useful, when debug= >ging especially, and > I've created some code which takes a list of refany = >parameters and > prints them out. It is a bit inefficient since any 'atomic= >' values > such as integers need to be allocated but it also prints out all= > the > fields of structures and arrays. But it is completely safe. If there= > > were a need for a more efficient way to generated formatted strings, > I= >'d write something else more efficient but also configurable since > embedd= >ing fixed strings in your code is generally a a bad idea.> > > On 14/02/200= >8, at 4:44 AM, Randy Coleburn wrote:> > > Jay:> >> > I don't want to be off= >ensive, but quite frankly I'm tired of > > continually reading your gripes = >about Modula-3 as a language and > > your pining for C.> >> > This forum is= > for those people interested in advancing the state of > > Modula-3. We don= >'t care about C/C++/C#/etc in this forum. Those of > > us who are M3 zealot= >s for the most part probably would welcome any > > move to divest CM3 of al= >l underpinnings from the C world.> >> > Have you seriously studied the Modu= >la-3 language and used it to > > build production software? I think some of= > your comments suggest > > that you are not a true Modula-3 programmer and = >that you still cling > > to the C-way of doing things rather than embracing= > the Modula-3 way.> >> > Now, I do think that most people are interested in= > improving things > > and no language is perfect, so any well-thought-out p= >roposal for a > > change to the language is welcome for consideration, But = >in this > > mail list forum, I for one would appreciate less ranting about = >C and > > more constructive Modula-3.> >> > Truly, I do not want to offend = >you. Maybe I'm just having a bad > > day, but I encourage you to try and fo= >cus your posts to the > > advancement of Modula-3.> >> > Regards,> > Randy>= > >> > >>> Jay 2/12/2008 11:28 PM >>>> > > >My princip= >le concern is that once we provide C APIs then C will> > > >permeate the M3= > space more pervasively (both apps and libraries).> >> > This is somewhat m= >y point.> > When I am debugging, I really miss printf.> >> > The debugging = >options seem really poor everywhere and esp. on NT386.> >> > gdb has all wi= >erded out variable names for one thing.> > And I think we should fix it so = >that that the symbols have full > > source paths.> > I realize they would o= >nly be correct on one machine, and hopefully > > there's a decent story for= > copying the files.> > Yeah, I know about "dir" but haven't yet formed a .g= >dbinit or whatnot.> >> > Other than printf'ing, I also end up getting a sta= >ck in cdb with no > > symbols and then disasm in gdb to find what the funct= >ions were. That > > works fine a few times, but I hope not to do it often. = >Somewhat > > lucky I could even get a stack. Because, see, cdb is nice enou= >gh to > > stop on access violations by default (such as the time/date code = >was > > causing). gdb has a promising sounding feature, the ability to stop= > > > on "signals", which I think an access violation would count as, oh, > = >> but that feature isn't implemented, sorry. Ok, true, think about it > > m= >ore and I can break on the toplevel exception handler in > > cygwin1.dll, n= >ot sure that always works or not, it's an > > implementation detail, but he= >ck, when you are debugging, take > > advantage of whatever you have. :)> >>= > > RTIO, is too verbose for me.> > But darnit, I can't really have printf..= >puts is about the best I > > could do..> > Oh, but no, since TEXT !=3D char= >* even that isn't useful.> > fread/fwrite maybe though.> >> > On a differen= >t hand (how many are there? :) ), have you looked in > > m3core\src\unix?> = >> There is just tons of dead stuff, stuff with comments about it > > perhap= >s being wrong, "use with care".> > It seemed to me maybe the point was to e= >xpose "all" of /usr/include.> > Someone, other than me, sure seems to have = >gone overboard, like > > someone using Ultrix and Linux 1.x, and then it co= >pied around.> > Heck, look at the mem* functions being commented out (and p= >robably > > using the incorrect type int) because Ultrix or somesuch didn't= > have > > them. I uncommented them to fix a build. And notice that these > = >> functions, again, like most of printf, are /extremely/ portable in > > fu= >nctionality and exact binary interface (yeah yeah, I've heard of > > bcopy = >and bzero).> >> > What there was of Cstdio.i3 seemed very possibly wrong, a= >t least on > > many targets, and very doubtfully useful for anything, and I= > think > > I've now shown unused.> >> > > Y, the easiest way to implement t= >he interface is to call a C > > function> > > that "just happens" to have t= >he correct interface. But on another> >> > But wrapping everything in Modul= >a-3 is so tedious...> > Oh for all languages to just understand C headers s= >o we can stop > > rewriting them...> > Or some other language, ok...not goi= >ng to be solved in this forum.> > To go the unpopular route (again), MS CLR= >/.NET among many other > > things, attempts to solve this very problem.> > = >One way to describe "interfaces" that "all" languages can > > understand...= >at least for some subset of languages features..> >> > Just as tedious btw,= > it is often more portable to wrap all the C > > APIs in C, exposing a port= >able controled Modula-3 interface > > independent of the precise header con= >tent. Like errno and my > > get_stderr/out/in.> >> > - Jay> >> >> > > To: h= >osking at cs.purdue.edu> > > Date: Tue, 12 Feb 2008 16:37:43 -0800> > > From: = >mika at async.caltech.edu> > > CC: m3devel at elegosoft.com> > > Subject: Re: [M3= >devel] "target specific pragmas"?> > >> > >> > > This is also an excellent = >reason not to permit "interfaces" to C> > > code inlined into MODULEs.> > >= >> > > Interfaces are the contract that the implementation has to live up> >= > > to. Ok, so it happens that under operating system X on architecture> > >= > Y, the easiest way to implement the interface is to call a C > > function>= > > > that "just happens" to have the correct interface. But on another> > >= > system, which either isn't built in C or where the function doesn't> > > e= >xist, it might be convenient to implement the interface in (gasp!)> > > Mod= >ula-3!> > >> > > (I use this pattern as follows: on systems where Intel's F= >ortran> > > compiler is available, compile from assembly (which was generat= >ed> > > by ifort). On other systems, the code is implemented in Modula-3.)>= > > >> > > Mika> > >> > > Tony Hosking writes:> > > >My principle concern is= > that once we provide C APIs then C will> > > >permeate the M3 space more p= >ervasively (both apps and libraries).> > > >What happens when I want to bri= >ng up a system where there is no> > > >C?!?! Consider the SPIN OS perhaps..= >.> > > >> > > >Maybe I am just being overly fusty...> > > >> > > >On Feb 12= >, 2008, at 4:35 PM, Dragi=C5=A1a Duri=C4? wrote:> > > >> > > >> What we _ma= >ybe_ can do... is to make some special, preprocessable> > > >> source> > > = >>> form, which some quake command can parse into multiple files in > > thei= >r> > > >> folders. And these file can be compiled later...Kind of how > > g= >eneric> > > >> works.> > > >>> > > >> But, as current system works, and it = >does it very well, and as > > only> > > >> case> > > >> where we really nee= >d this is Windows... most Unices being or > > becoming> > > >> POSIX... I d= >on't see it's smart to spend resources on becoming > > more> > > >> C...> >= > > >> Esp when "founding fathers" made it so good and so much non-C :).> > = >> >>> > > >> If we really need to make some approach to "their world", it's= > > > much> > > >> better to work on interoperability issues and thus cement= > our> > > >> first-class-citizen language status even more.> > > >>> > > >>= > dd> > > >>> > > >> On Tue, 2008-02-12 at 15:16 -0500, Randy Coleburn wrote= >:> > > >>> Jay:> > > >>>> > > >>> My understanding of Modula-3 is that rath= >er than cluttering up > > the> > > >>> source code with a bunch of preproce= >ssor directives to deal > > with the> > > >>> various changes needed by var= >ious platforms, a separate source> > > >>> file is> > > >>> used for platfo= >rms whose implementation must diverge. The > > m3makefile> > > >>> is used = >to control the selection of these platform sources at > > build> > > >>> ti= >me. I like this approach much better.> > > >>>> > > >>> Regards,> > > >>> R= >andy> > > >>>> > > >>>>>> Jay 2/11/2008 8:21 PM >>>> = >> > >>> So I have NOT thought this through.> > > >>>> > > >>> I wonder if "= >preprocessing" dependent only on "target" is a good> > > >>> idea.> > > >>>= >> > > >>> Something like either the ability to prefix pragmas with a > > ta= >rget, or> > > >>> an "iftarget" and "ifnottarget" pragma.> > > >>>> > > >>>= > Something like so:> > > >>>> > > >>> <* IF_TARGET NT386 *>> > > >>> <* END= >_IF_TARGET*>> > > >>>> > > >>>> > > >>> <* IF_TARGET NT386 *>> > > >>> <* E= >ND_IF_TARGET*>> > > >>> It's a small can of worms.> > > >>> Where can they = >be placed? Only at "global" scope? (ie: > > toplevel in an> > > >>> interfa= >ce/module).> > > >>>> > > >>> What about IF_OSTYPE?> > > >>> What about exp= >ressions?> > > >>> IF_TARGET NT386 OR NTAMD64> > > >>>> > > >>> IF_TARGET S= >TARTS(NT)> > > >>>> > > >>> etc.> > > >>>> > > >>> I don't really have enou= >gh interest here to work through this, > > just> > > >>> sending out the ba= >it...> > > >>>> > > >>> Obviously this was triggered by my happening into t= >he odbc > > directory> > > >>> and bringing up ignoring WINAPI on non-NT386= > or prefixing > > calling> > > >>> conventions with a target.> > > >>>> > >= > >>> This reminds me of an important point here however -- nobody > > else = >is> > > >>> going to make the mistake of ever having multiple calling> > > = >>>> conventions.> > > >>> Therefore the generality of prefixing WINAPI with= > NT386: is > > useless.> > > >>> Unless Mac68K support is added.> > > >>>> = >> > >>> And here is some rationale even. The PC and Mac evolved from > > "s= >mall"> > > >>> systems, where assembly programming was common, more people = >> > knew more> > > >>> lower level details and playing games with calling c= >onventions > > was> > > >>> something anyone could do. Most other current s= >ystems are > > rooted in C> > > >>> programming. Working in C, calling conv= >entions are generally > > in a> > > >>> hidden layer below what anyone thin= >ks about. Therefore, the > > smaller> > > >>> number of capable people work= >ing at that level have the good > > sense to> > > >>> only have one calling= > convention. No more systems will evolve > > from> > > >>> "small", at leas= >t not without having observed this history.> > > >>> Therefore,> > > >>> th= >ere will no longer be multiple calling conventions.> > > >>>> > > >>> That = >is my theory at least.> > > >>>> > > >>> Oh, Windows does also have __thisc= >all and __clrcall. > > __thiscall is> > > >>> only x86> > > >> --> > > >> D= >ragi=C5=A1a Duri=C4? > >> >> > Connect and share in new w= >ays with Windows Live. Get it now!>=20 >_________________________________________________________________ >Shed those extra pounds with MSN and The Biggest Loser! >http://biggestloser.msn.com/= > >--_26c72f2f-07a7-4258-b083-944d52866fbb_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > >I'll try to repeat myself less and rambl= >e less, and stay constructive...
> 
>I understand that printf type unsafety stinks and I have been bitten by it,= > but it is nicely terse, crude but effective, I'm going to throw away the c= >ode probably once the bug is fixed. (Ok, I like to comment out or somehow d= >isable sometimes maybe but that is a different point, it's still not the he= >ight of production code; and yes, I realize it's a slippery slope and the n= >ext thing I'll do is use it in production code; debugging is just what I'm = >doing now, next up, real code).
> 
>You can't just be the antithesis of C. You have to decide what it is about = >C that is wrong and fix it or do it over.
>And then of course, agreement on what is wrong. I probably see less wrong t= >han you.
>Bad module system -- #include.
>Bad module system -- preprocesor which kills or damages other efforts at la= >nguage-aware tools.
>Beyond this, at the moment, I am unsure.
>I have "argued for" C++ for further "problems" in C, but I have "grown" (or= > shrunk? :) ) to appreciate that C might not be as bad as I used to think.<= >BR> > 
>If you start over completely from scratch, you should still look at what is= > out there.
>Granted, some things are mostly arbitrary. Braces vs. begin/end. But the ed= >itors all support braces now.
>Until you get me to change editors (probably never), Modula-3 is always goi= >ng to be less convenient.
>At this point you are just fighting the vast majority (except Python...). I= >t could have gone differently, but C won.
> 
>If you ignore that lowest level thing, there are places where Modula-3 is p= >erfectly good, but doesn't take the next step.
>A good example I think here is it has nice "objects", however it requires t= >hey be heap allocated I think even in unsafe code. You should be able stack= > (or global) allocate something with "virtual functions". It seems an arbit= >rary limitation. I realize in safe code, you have to heap allocate more any= >way, but that is a different point I think.
> 
>Similarly is "multiple inheritance just of interfaces". I realize though..t= >his hides a "vtable per interface". Maybe is much more expensive than peopl= >e realize and shouldn't be provided lightly.
> 
>SUBARRAY is probably example where I don't/didn't know the language well en= >ough.
>  And maybe the docs aren't good here.
>And VAR/BEGIN.
>Maybe I just need to reread Nelson's book. You know..reference vs. tutorial= >. The language reference is very very terse and that is ok. Short on exampl= >es. A tutorial that gives many examples might be good. Hey maybe I'm just t= >he newbie in a good position to write it. (not)
> 
>I guess I should be in comp.lang.c.advocacy. :)
> 
>To a large extent I'm just looking for a small smart group to have a friend= >ly intellectual discussion with.
>(and of course, don't mess up their code)
> 
> - Jay


> >
>
>> CC: jayk123 at hotmail.com; m3devel at elegosoft.com
> From: darko at dar= >ko.org
> To: rcoleburn at scires.com
> Subject: Re: [M3devel] "tar= >get specific pragmas"?
> Date: Thu, 14 Feb 2008 11:10:18 +1100
>= >;
> I actually see some benefit to Jay's postings since they make us= >
> examine some of the differences between M3 and C and explain the = >
> benefits. These questions might be asked by any C programmer
&= >gt; approaching the M3 language. It may be the point that Jay hasn't
&g= >t; created and serious software in M3 and needs to be informed of the
&= >gt; benefits. I've seen some good responses along these lines from members = >
> of the list.
>
> But Randy does have a valid point. M= >3 is is not just different to C,
> it's the antithesis of C. It's ev= >erything C isn't and the language
> designers went to great lengths = >to make it this way. It's why most of
> us use the language.
>= >
> I certainly wouldn't like to drive anyone away because they have = >a
> different point of view, but it may be a good idea to examine pr= >oblems
> and solutions more closely and offer other solutions that '= >why not do
> it like C'.
>
> In the case of printf, it = >is useful, when debugging especially, and
> I've created some code w= >hich takes a list of refany parameters and
> prints them out. It is = >a bit inefficient since any 'atomic' values
> such as integers need = >to be allocated but it also prints out all the
> fields of structure= >s and arrays. But it is completely safe. If there
> were a need for = >a more efficient way to generated formatted strings,
> I'd write som= >ething else more efficient but also configurable since
> embedding f= >ixed strings in your code is generally a a bad idea.
>
>
&= >gt; On 14/02/2008, at 4:44 AM, Randy Coleburn wrote:
>
> > = >Jay:
> >
> > I don't want to be offensive, but quite fran= >kly I'm tired of
> > continually reading your gripes about Modula= >-3 as a language and
> > your pining for C.
> >
> = >> This forum is for those people interested in advancing the state of R>> > Modula-3. We don't care about C/C++/C#/etc in this forum. Those= > of
> > us who are M3 zealots for the most part probably would we= >lcome any
> > move to divest CM3 of all underpinnings from the C = >world.
> >
> > Have you seriously studied the Modula-3 la= >nguage and used it to
> > build production software? I think some= > of your comments suggest
> > that you are not a true Modula-3 pr= >ogrammer and that you still cling
> > to the C-way of doing thing= >s rather than embracing the Modula-3 way.
> >
> > Now, I = >do think that most people are interested in improving things
> > = >and no language is perfect, so any well-thought-out proposal for a
>= > > change to the language is welcome for consideration, But in this
= >> > mail list forum, I for one would appreciate less ranting about C = >and
> > more constructive Modula-3.
> >
> > Tru= >ly, I do not want to offend you. Maybe I'm just having a bad
> > = >day, but I encourage you to try and focus your posts to the
> > a= >dvancement of Modula-3.
> >
> > Regards,
> > Ran= >dy
> >
> > >>> Jay <jayk123 at hotmail.com> 2= >/12/2008 11:28 PM >>>
> > > >My principle concern i= >s that once we provide C APIs then C will
> > > >permeate th= >e M3 space more pervasively (both apps and libraries).
> >
>= > > This is somewhat my point.
> > When I am debugging, I really= > miss printf.
> >
> > The debugging options seem really p= >oor everywhere and esp. on NT386.
> >
> > gdb has all wie= >rded out variable names for one thing.
> > And I think we should f= >ix it so that that the symbols have full
> > source paths.
>= >; > I realize they would only be correct on one machine, and hopefully <= >BR>> > there's a decent story for copying the files.
> > Yea= >h, I know about "dir" but haven't yet formed a .gdbinit or whatnot.
>= > >
> > Other than printf'ing, I also end up getting a stack in = >cdb with no
> > symbols and then disasm in gdb to find what the f= >unctions were. That
> > works fine a few times, but I hope not to= > do it often. Somewhat
> > lucky I could even get a stack. Becaus= >e, see, cdb is nice enough to
> > stop on access violations by de= >fault (such as the time/date code was
> > causing). gdb has a pro= >mising sounding feature, the ability to stop
> > on "signals", wh= >ich I think an access violation would count as, oh,
> > but that = >feature isn't implemented, sorry. Ok, true, think about it
> > mo= >re and I can break on the toplevel exception handler in
> > cygwi= >n1.dll, not sure that always works or not, it's an
> > implementa= >tion detail, but heck, when you are debugging, take
> > advantage= > of whatever you have. :)
> >
> > RTIO, is too verbose fo= >r me.
> > But darnit, I can't really have printf..puts is about th= >e best I
> > could do..
> > Oh, but no, since TEXT !=3D = >char* even that isn't useful.
> > fread/fwrite maybe though.
&g= >t; >
> > On a different hand (how many are there? :) ), have yo= >u looked in
> > m3core\src\unix?
> > There is just tons = >of dead stuff, stuff with comments about it
> > perhaps being wro= >ng, "use with care".
> > It seemed to me maybe the point was to ex= >pose "all" of /usr/include.
> > Someone, other than me, sure seems= > to have gone overboard, like
> > someone using Ultrix and Linux = >1.x, and then it copied around.
> > Heck, look at the mem* functio= >ns being commented out (and probably
> > using the incorrect type= > int) because Ultrix or somesuch didn't have
> > them. I uncommen= >ted them to fix a build. And notice that these
> > functions, aga= >in, like most of printf, are /extremely/ portable in
> > function= >ality and exact binary interface (yeah yeah, I've heard of
> > bc= >opy and bzero).
> >
> > What there was of Cstdio.i3 seeme= >d very possibly wrong, at least on
> > many targets, and very dou= >btfully useful for anything, and I think
> > I've now shown unuse= >d.
> >
> > > Y, the easiest way to implement the inter= >face is to call a C
> > function
> > > that "just hap= >pens" to have the correct interface. But on another
> >
> &g= >t; But wrapping everything in Modula-3 is so tedious...
> > Oh for= > all languages to just understand C headers so we can stop
> > re= >writing them...
> > Or some other language, ok...not going to be s= >olved in this forum.
> > To go the unpopular route (again), MS CLR= >/.NET among many other
> > things, attempts to solve this very pr= >oblem.
> > One way to describe "interfaces" that "all" languages c= >an
> > understand...at least for some subset of languages feature= >s..
> >
> > Just as tedious btw, it is often more portabl= >e to wrap all the C
> > APIs in C, exposing a portable controled = >Modula-3 interface
> > independent of the precise header content.= > Like errno and my
> > get_stderr/out/in.
> >
> &g= >t; - Jay
> >
> >
> > > To: hosking at cs.purdue.= >edu
> > > Date: Tue, 12 Feb 2008 16:37:43 -0800
> > &g= >t; From: mika at async.caltech.edu
> > > CC: m3devel at elegosoft.com= >
> > > Subject: Re: [M3devel] "target specific pragmas"?
>= >; > >
> > >
> > > This is also an excellent r= >eason not to permit "interfaces" to C
> > > code inlined into M= >ODULEs.
> > >
> > > Interfaces are the contract tha= >t the implementation has to live up
> > > to. Ok, so it happens= > that under operating system X on architecture
> > > Y, the eas= >iest way to implement the interface is to call a C
> > functionR>> > > that "just happens" to have the correct interface. But on = >another
> > > system, which either isn't built in C or where th= >e function doesn't
> > > exist, it might be convenient to imple= >ment the interface in (gasp!)
> > > Modula-3!
> > >= >
> > > (I use this pattern as follows: on systems where Intel's= > Fortran
> > > compiler is available, compile from assembly (wh= >ich was generated
> > > by ifort). On other systems, the code i= >s implemented in Modula-3.)
> > >
> > > Mika
>= >; > >
> > > Tony Hosking writes:
> > > >My= > principle concern is that once we provide C APIs then C will
> > = >> >permeate the M3 space more pervasively (both apps and libraries).<= >BR>> > > >What happens when I want to bring up a system where t= >here is no
> > > >C?!?! Consider the SPIN OS perhaps...
&= >gt; > > >
> > > >Maybe I am just being overly fusty= >...
> > > >
> > > >On Feb 12, 2008, at 4:35 P= >M, Dragi=C5=A1a Duri=C4? wrote:
> > > >
> > > &g= >t;> What we _maybe_ can do... is to make some special, preprocessable>> > > >> source
> > > >> form, which some= > quake command can parse into multiple files in
> > their
>= > > > >> folders. And these file can be compiled later...Kind of= > how
> > generic
> > > >> works.
> > &= >gt; >>
> > > >> But, as current system works, and i= >t does it very well, and as
> > only
> > > >> c= >ase
> > > >> where we really need this is Windows... most= > Unices being or
> > becoming
> > > >> POSIX...= > I don't see it's smart to spend resources on becoming
> > moreR>> > > >> C...
> > > >> Esp when "foundin= >g fathers" made it so good and so much non-C :).
> > > >>= >
> > > >> If we really need to make some approach to "the= >ir world", it's
> > much
> > > >> better to wor= >k on interoperability issues and thus cement our
> > > >>= > first-class-citizen language status even more.
> > > >><= >BR>> > > >> dd
> > > >>
> > > = >>> On Tue, 2008-02-12 at 15:16 -0500, Randy Coleburn wrote:
> &= >gt; > >>> Jay:
> > > >>>
> > >= > >>> My understanding of Modula-3 is that rather than cluttering u= >p
> > the
> > > >>> source code with a bunch= > of preprocessor directives to deal
> > with the
> > >= >; >>> various changes needed by various platforms, a separate sour= >ce
> > > >>> file is
> > > >>> us= >ed for platforms whose implementation must diverge. The
> > m3mak= >efile
> > > >>> is used to control the selection of th= >ese platform sources at
> > build
> > > >>> = >time. I like this approach much better.
> > > >>>
&= >gt; > > >>> Regards,
> > > >>> Randy>> > > >>>
> > > >>>>>> Jay= > <jayk123 at hotmail.com> 2/11/2008 8:21 PM >>>
> > &g= >t; >>> So I have NOT thought this through.
> > > >&= >gt;>
> > > >>> I wonder if "preprocessing" dependen= >t only on "target" is a good
> > > >>> idea.
> &= >gt; > >>>
> > > >>> Something like either = >the ability to prefix pragmas with a
> > target, or
> > = >> >>> an "iftarget" and "ifnottarget" pragma.
> > >= > >>>
> > > >>> Something like so:
> >= >; > >>>
> > > >>> <* IF_TARGET NT386 *&= >gt;
> > > >>> <* END_IF_TARGET*>
> > &g= >t; >>>
> > > >>>
> > > >>&g= >t; <* IF_TARGET NT386 *>
> > > >>> <* END_IF_= >TARGET*>
> > > >>> It's a small can of worms.
&g= >t; > > >>> Where can they be placed? Only at "global" scope?= > (ie:
> > toplevel in an
> > > >>> interface= >/module).
> > > >>>
> > > >>> Wha= >t about IF_OSTYPE?
> > > >>> What about expressions?R>> > > >>> IF_TARGET NT386 OR NTAMD64
> > > = >>>>
> > > >>> IF_TARGET STARTS(NT)
> &g= >t; > >>>
> > > >>> etc.
> > > = >>>>
> > > >>> I don't really have enough inte= >rest here to work through this,
> > just
> > > >&g= >t;> sending out the bait...
> > > >>>
> > = >> >>> Obviously this was triggered by my happening into the odb= >c
> > directory
> > > >>> and bringing up ig= >noring WINAPI on non-NT386 or prefixing
> > calling
> > = >> >>> conventions with a target.
> > > >>>= >
> > > >>> This reminds me of an important point here = >however -- nobody
> > else is
> > > >>> goin= >g to make the mistake of ever having multiple calling
> > > >= >;>> conventions.
> > > >>> Therefore the general= >ity of prefixing WINAPI with NT386: is
> > useless.
> > = >> >>> Unless Mac68K support is added.
> > > >>= >;>
> > > >>> And here is some rationale even. The P= >C and Mac evolved from
> > "small"
> > > >>>= > systems, where assembly programming was common, more people
> > = >knew more
> > > >>> lower level details and playing ga= >mes with calling conventions
> > was
> > > >>&g= >t; something anyone could do. Most other current systems are
> > = >rooted in C
> > > >>> programming. Working in C, calli= >ng conventions are generally
> > in a
> > > >>&= >gt; hidden layer below what anyone thinks about. Therefore, the
> &g= >t; smaller
> > > >>> number of capable people working = >at that level have the good
> > sense to
> > > >&g= >t;> only have one calling convention. No more systems will evolve
&g= >t; > from
> > > >>> "small", at least not without h= >aving observed this history.
> > > >>> Therefore,
&= >gt; > > >>> there will no longer be multiple calling convent= >ions.
> > > >>>
> > > >>> That is= > my theory at least.
> > > >>>
> > > >&= >gt;> Oh, Windows does also have __thiscall and __clrcall.
> > = >__thiscall is
> > > >>> only x86
> > > >= >;> --
> > > >> Dragi=C5=A1a Duri=C4? <dragisha at m3w.= >org>
> >
> >
> > Connect and share in new way= >s with Windows Live. Get it now!
>


Shed those ext= >ra pounds with MSN and The Biggest Loser! n.com/' target=3D'_new'>Learn more. >= > >--_26c72f2f-07a7-4258-b083-944d52866fbb_-- From mika at async.caltech.edu Thu Feb 14 03:00:46 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Wed, 13 Feb 2008 18:00:46 -0800 Subject: [M3devel] "target specific pragmas"? In-Reply-To: Your message of "Thu, 14 Feb 2008 00:34:44 GMT." Message-ID: <200802140200.m1E20k5k062986@camembert.async.caltech.edu> I should point out that I am not trying to tell you that Modula-3 is better than C++ and you should immediately switch and stop talking about the wonderful features of C++. It's not and if you are competent enough to be coding in C++ and happy with it you should certainly not. A way to summarize what I said before is this. I do not consider myself a good programmer. Yet I sit in front of my computer trying to write software that plays with millions of dollars of other people's money. I simply do not trust myself to use a tool as sharp and unconstrained as C++. The constraints of enumerated types, subranges, typechecking at interfaces and runtime, bounds-checked arrays etc., let me sleep a bit better (but still not well). I am reminded of something my advisor's advisor once wrote, regarding the difficulty of producing large software systems: We shall do a much better programming job, provided that we approach the task with a full appreciation of its tremendous difficulty, provided that we stick to modest and elegant programming languages, provided that we respect the intrinsic limitations of the human mind and approach the task as Very Humble Programmers. ( http://www.cs.utexas.edu/~EWD/ewd03xx/EWD340.PDF CACM 15, 1972, #10, 859-866) Mika Jay writes: >--_26c72f2f-07a7-4258-b083-944d52866fbb_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > >I'll try to repeat myself less and ramble less, and stay constructive... >=20 >I understand that printf type unsafety stinks and I have been bitten by it,= > but it is nicely terse, crude but effective, I'm going to throw away the c= >ode probably once the bug is fixed. (Ok, I like to comment out or somehow d= >isable sometimes maybe but that is a different point, it's still not the he= >ight of production code; and yes, I realize it's a slippery slope and the n= >ext thing I'll do is use it in production code; debugging is just what I'm = >doing now, next up, real code). >=20 >You can't just be the antithesis of C. You have to decide what it is about = >C that is wrong and fix it or do it over. >And then of course, agreement on what is wrong. I probably see less wrong t= >han you. >Bad module system -- #include. >Bad module system -- preprocesor which kills or damages other efforts at la= >nguage-aware tools. >Beyond this, at the moment, I am unsure. >I have "argued for" C++ for further "problems" in C, but I have "grown" (or= > shrunk? :) ) to appreciate that C might not be as bad as I used to think. >=20 >If you start over completely from scratch, you should still look at what is= > out there. >Granted, some things are mostly arbitrary. Braces vs. begin/end. But the ed= >itors all support braces now. >Until you get me to change editors (probably never), Modula-3 is always goi= >ng to be less convenient. >At this point you are just fighting the vast majority (except Python...). I= >t could have gone differently, but C won. >=20 >If you ignore that lowest level thing, there are places where Modula-3 is p= >erfectly good, but doesn't take the next step. >A good example I think here is it has nice "objects", however it requires t= >hey be heap allocated I think even in unsafe code. You should be able stack= > (or global) allocate something with "virtual functions". It seems an arbit= >rary limitation. I realize in safe code, you have to heap allocate more any= >way, but that is a different point I think. >=20 >Similarly is "multiple inheritance just of interfaces". I realize though..t= >his hides a "vtable per interface". Maybe is much more expensive than peopl= >e realize and shouldn't be provided lightly. >=20 >SUBARRAY is probably example where I don't/didn't know the language well en= >ough. > And maybe the docs aren't good here. >And VAR/BEGIN. >Maybe I just need to reread Nelson's book. You know..reference vs. tutorial= >. The language reference is very very terse and that is ok. Short on exampl= >es. A tutorial that gives many examples might be good. Hey maybe I'm just t= >he newbie in a good position to write it. (not) >=20 >I guess I should be in comp.lang.c.advocacy. :) >=20 >To a large extent I'm just looking for a small smart group to have a friend= >ly intellectual discussion with. >(and of course, don't mess up their code) >=20 > - Jay > > > >> CC: jayk123 at hotmail.com; m3devel at elegosoft.com> From: darko at darko.org> To= >: rcoleburn at scires.com> Subject: Re: [M3devel] "target specific pragmas"?> = >Date: Thu, 14 Feb 2008 11:10:18 +1100> > I actually see some benefit to Jay= >'s postings since they make us > examine some of the differences between M3= > and C and explain the > benefits. These questions might be asked by any C = >programmer > approaching the M3 language. It may be the point that Jay hasn= >'t > created and serious software in M3 and needs to be informed of the > b= >enefits. I've seen some good responses along these lines from members > of = >the list.> > But Randy does have a valid point. M3 is is not just different= > to C, > it's the antithesis of C. It's everything C isn't and the language= > > designers went to great lengths to make it this way. It's why most of > = >us use the language.> > I certainly wouldn't like to drive anyone away beca= >use they have a > different point of view, but it may be a good idea to exa= >mine problems > and solutions more closely and offer other solutions that '= >why not do > it like C'.> > In the case of printf, it is useful, when debug= >ging especially, and > I've created some code which takes a list of refany = >parameters and > prints them out. It is a bit inefficient since any 'atomic= >' values > such as integers need to be allocated but it also prints out all= > the > fields of structures and arrays. But it is completely safe. If there= > > were a need for a more efficient way to generated formatted strings, > I= >'d write something else more efficient but also configurable since > embedd= >ing fixed strings in your code is generally a a bad idea.> > > On 14/02/200= >8, at 4:44 AM, Randy Coleburn wrote:> > > Jay:> >> > I don't want to be off= >ensive, but quite frankly I'm tired of > > continually reading your gripes = >about Modula-3 as a language and > > your pining for C.> >> > This forum is= > for those people interested in advancing the state of > > Modula-3. We don= >'t care about C/C++/C#/etc in this forum. Those of > > us who are M3 zealot= >s for the most part probably would welcome any > > move to divest CM3 of al= >l underpinnings from the C world.> >> > Have you seriously studied the Modu= >la-3 language and used it to > > build production software? I think some of= > your comments suggest > > that you are not a true Modula-3 programmer and = >that you still cling > > to the C-way of doing things rather than embracing= > the Modula-3 way.> >> > Now, I do think that most people are interested in= > improving things > > and no language is perfect, so any well-thought-out p= >roposal for a > > change to the language is welcome for consideration, But = >in this > > mail list forum, I for one would appreciate less ranting about = >C and > > more constructive Modula-3.> >> > Truly, I do not want to offend = >you. Maybe I'm just having a bad > > day, but I encourage you to try and fo= >cus your posts to the > > advancement of Modula-3.> >> > Regards,> > Randy>= > >> > >>> Jay 2/12/2008 11:28 PM >>>> > > >My princip= >le concern is that once we provide C APIs then C will> > > >permeate the M3= > space more pervasively (both apps and libraries).> >> > This is somewhat m= >y point.> > When I am debugging, I really miss printf.> >> > The debugging = >options seem really poor everywhere and esp. on NT386.> >> > gdb has all wi= >erded out variable names for one thing.> > And I think we should fix it so = >that that the symbols have full > > source paths.> > I realize they would o= >nly be correct on one machine, and hopefully > > there's a decent story for= > copying the files.> > Yeah, I know about "dir" but haven't yet formed a .g= >dbinit or whatnot.> >> > Other than printf'ing, I also end up getting a sta= >ck in cdb with no > > symbols and then disasm in gdb to find what the funct= >ions were. That > > works fine a few times, but I hope not to do it often. = >Somewhat > > lucky I could even get a stack. Because, see, cdb is nice enou= >gh to > > stop on access violations by default (such as the time/date code = >was > > causing). gdb has a promising sounding feature, the ability to stop= > > > on "signals", which I think an access violation would count as, oh, > = >> but that feature isn't implemented, sorry. Ok, true, think about it > > m= >ore and I can break on the toplevel exception handler in > > cygwin1.dll, n= >ot sure that always works or not, it's an > > implementation detail, but he= >ck, when you are debugging, take > > advantage of whatever you have. :)> >>= > > RTIO, is too verbose for me.> > But darnit, I can't really have printf..= >puts is about the best I > > could do..> > Oh, but no, since TEXT !=3D char= >* even that isn't useful.> > fread/fwrite maybe though.> >> > On a differen= >t hand (how many are there? :) ), have you looked in > > m3core\src\unix?> = >> There is just tons of dead stuff, stuff with comments about it > > perhap= >s being wrong, "use with care".> > It seemed to me maybe the point was to e= >xpose "all" of /usr/include.> > Someone, other than me, sure seems to have = >gone overboard, like > > someone using Ultrix and Linux 1.x, and then it co= >pied around.> > Heck, look at the mem* functions being commented out (and p= >robably > > using the incorrect type int) because Ultrix or somesuch didn't= > have > > them. I uncommented them to fix a build. And notice that these > = >> functions, again, like most of printf, are /extremely/ portable in > > fu= >nctionality and exact binary interface (yeah yeah, I've heard of > > bcopy = >and bzero).> >> > What there was of Cstdio.i3 seemed very possibly wrong, a= >t least on > > many targets, and very doubtfully useful for anything, and I= > think > > I've now shown unused.> >> > > Y, the easiest way to implement t= >he interface is to call a C > > function> > > that "just happens" to have t= >he correct interface. But on another> >> > But wrapping everything in Modul= >a-3 is so tedious...> > Oh for all languages to just understand C headers s= >o we can stop > > rewriting them...> > Or some other language, ok...not goi= >ng to be solved in this forum.> > To go the unpopular route (again), MS CLR= >/.NET among many other > > things, attempts to solve this very problem.> > = >One way to describe "interfaces" that "all" languages can > > understand...= >at least for some subset of languages features..> >> > Just as tedious btw,= > it is often more portable to wrap all the C > > APIs in C, exposing a port= >able controled Modula-3 interface > > independent of the precise header con= >tent. Like errno and my > > get_stderr/out/in.> >> > - Jay> >> >> > > To: h= >osking at cs.purdue.edu> > > Date: Tue, 12 Feb 2008 16:37:43 -0800> > > From: = >mika at async.caltech.edu> > > CC: m3devel at elegosoft.com> > > Subject: Re: [M3= >devel] "target specific pragmas"?> > >> > >> > > This is also an excellent = >reason not to permit "interfaces" to C> > > code inlined into MODULEs.> > >= >> > > Interfaces are the contract that the implementation has to live up> >= > > to. Ok, so it happens that under operating system X on architecture> > >= > Y, the easiest way to implement the interface is to call a C > > function>= > > > that "just happens" to have the correct interface. But on another> > >= > system, which either isn't built in C or where the function doesn't> > > e= >xist, it might be convenient to implement the interface in (gasp!)> > > Mod= >ula-3!> > >> > > (I use this pattern as follows: on systems where Intel's F= >ortran> > > compiler is available, compile from assembly (which was generat= >ed> > > by ifort). On other systems, the code is implemented in Modula-3.)>= > > >> > > Mika> > >> > > Tony Hosking writes:> > > >My principle concern is= > that once we provide C APIs then C will> > > >permeate the M3 space more p= >ervasively (both apps and libraries).> > > >What happens when I want to bri= >ng up a system where there is no> > > >C?!?! Consider the SPIN OS perhaps..= >.> > > >> > > >Maybe I am just being overly fusty...> > > >> > > >On Feb 12= >, 2008, at 4:35 PM, Dragi=C5=A1a Duri=C4? wrote:> > > >> > > >> What we _ma= >ybe_ can do... is to make some special, preprocessable> > > >> source> > > = >>> form, which some quake command can parse into multiple files in > > thei= >r> > > >> folders. And these file can be compiled later...Kind of how > > g= >eneric> > > >> works.> > > >>> > > >> But, as current system works, and it = >does it very well, and as > > only> > > >> case> > > >> where we really nee= >d this is Windows... most Unices being or > > becoming> > > >> POSIX... I d= >on't see it's smart to spend resources on becoming > > more> > > >> C...> >= > > >> Esp when "founding fathers" made it so good and so much non-C :).> > = >> >>> > > >> If we really need to make some approach to "their world", it's= > > > much> > > >> better to work on interoperability issues and thus cement= > our> > > >> first-class-citizen language status even more.> > > >>> > > >>= > dd> > > >>> > > >> On Tue, 2008-02-12 at 15:16 -0500, Randy Coleburn wrote= >:> > > >>> Jay:> > > >>>> > > >>> My understanding of Modula-3 is that rath= >er than cluttering up > > the> > > >>> source code with a bunch of preproce= >ssor directives to deal > > with the> > > >>> various changes needed by var= >ious platforms, a separate source> > > >>> file is> > > >>> used for platfo= >rms whose implementation must diverge. The > > m3makefile> > > >>> is used = >to control the selection of these platform sources at > > build> > > >>> ti= >me. I like this approach much better.> > > >>>> > > >>> Regards,> > > >>> R= >andy> > > >>>> > > >>>>>> Jay 2/11/2008 8:21 PM >>>> = >> > >>> So I have NOT thought this through.> > > >>>> > > >>> I wonder if "= >preprocessing" dependent only on "target" is a good> > > >>> idea.> > > >>>= >> > > >>> Something like either the ability to prefix pragmas with a > > ta= >rget, or> > > >>> an "iftarget" and "ifnottarget" pragma.> > > >>>> > > >>>= > Something like so:> > > >>>> > > >>> <* IF_TARGET NT386 *>> > > >>> <* END= >_IF_TARGET*>> > > >>>> > > >>>> > > >>> <* IF_TARGET NT386 *>> > > >>> <* E= >ND_IF_TARGET*>> > > >>> It's a small can of worms.> > > >>> Where can they = >be placed? Only at "global" scope? (ie: > > toplevel in an> > > >>> interfa= >ce/module).> > > >>>> > > >>> What about IF_OSTYPE?> > > >>> What about exp= >ressions?> > > >>> IF_TARGET NT386 OR NTAMD64> > > >>>> > > >>> IF_TARGET S= >TARTS(NT)> > > >>>> > > >>> etc.> > > >>>> > > >>> I don't really have enou= >gh interest here to work through this, > > just> > > >>> sending out the ba= >it...> > > >>>> > > >>> Obviously this was triggered by my happening into t= >he odbc > > directory> > > >>> and bringing up ignoring WINAPI on non-NT386= > or prefixing > > calling> > > >>> conventions with a target.> > > >>>> > >= > >>> This reminds me of an important point here however -- nobody > > else = >is> > > >>> going to make the mistake of ever having multiple calling> > > = >>>> conventions.> > > >>> Therefore the generality of prefixing WINAPI with= > NT386: is > > useless.> > > >>> Unless Mac68K support is added.> > > >>>> = >> > >>> And here is some rationale even. The PC and Mac evolved from > > "s= >mall"> > > >>> systems, where assembly programming was common, more people = >> > knew more> > > >>> lower level details and playing games with calling c= >onventions > > was> > > >>> something anyone could do. Most other current s= >ystems are > > rooted in C> > > >>> programming. Working in C, calling conv= >entions are generally > > in a> > > >>> hidden layer below what anyone thin= >ks about. Therefore, the > > smaller> > > >>> number of capable people work= >ing at that level have the good > > sense to> > > >>> only have one calling= > convention. No more systems will evolve > > from> > > >>> "small", at leas= >t not without having observed this history.> > > >>> Therefore,> > > >>> th= >ere will no longer be multiple calling conventions.> > > >>>> > > >>> That = >is my theory at least.> > > >>>> > > >>> Oh, Windows does also have __thisc= >all and __clrcall. > > __thiscall is> > > >>> only x86> > > >> --> > > >> D= >ragi=C5=A1a Duri=C4? > >> >> > Connect and share in new w= >ays with Windows Live. Get it now!>=20 >_________________________________________________________________ >Shed those extra pounds with MSN and The Biggest Loser! >http://biggestloser.msn.com/= > >--_26c72f2f-07a7-4258-b083-944d52866fbb_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > >I'll try to repeat myself less and rambl= >e less, and stay constructive...
> 
>I understand that printf type unsafety stinks and I have been bitten by it,= > but it is nicely terse, crude but effective, I'm going to throw away the c= >ode probably once the bug is fixed. (Ok, I like to comment out or somehow d= >isable sometimes maybe but that is a different point, it's still not the he= >ight of production code; and yes, I realize it's a slippery slope and the n= >ext thing I'll do is use it in production code; debugging is just what I'm = >doing now, next up, real code).
> 
>You can't just be the antithesis of C. You have to decide what it is about = >C that is wrong and fix it or do it over.
>And then of course, agreement on what is wrong. I probably see less wrong t= >han you.
>Bad module system -- #include.
>Bad module system -- preprocesor which kills or damages other efforts at la= >nguage-aware tools.
>Beyond this, at the moment, I am unsure.
>I have "argued for" C++ for further "problems" in C, but I have "grown" (or= > shrunk? :) ) to appreciate that C might not be as bad as I used to think.<= >BR> > 
>If you start over completely from scratch, you should still look at what is= > out there.
>Granted, some things are mostly arbitrary. Braces vs. begin/end. But the ed= >itors all support braces now.
>Until you get me to change editors (probably never), Modula-3 is always goi= >ng to be less convenient.
>At this point you are just fighting the vast majority (except Python...). I= >t could have gone differently, but C won.
> 
>If you ignore that lowest level thing, there are places where Modula-3 is p= >erfectly good, but doesn't take the next step.
>A good example I think here is it has nice "objects", however it requires t= >hey be heap allocated I think even in unsafe code. You should be able stack= > (or global) allocate something with "virtual functions". It seems an arbit= >rary limitation. I realize in safe code, you have to heap allocate more any= >way, but that is a different point I think.
> 
>Similarly is "multiple inheritance just of interfaces". I realize though..t= >his hides a "vtable per interface". Maybe is much more expensive than peopl= >e realize and shouldn't be provided lightly.
> 
>SUBARRAY is probably example where I don't/didn't know the language well en= >ough.
>  And maybe the docs aren't good here.
>And VAR/BEGIN.
>Maybe I just need to reread Nelson's book. You know..reference vs. tutorial= >. The language reference is very very terse and that is ok. Short on exampl= >es. A tutorial that gives many examples might be good. Hey maybe I'm just t= >he newbie in a good position to write it. (not)
> 
>I guess I should be in comp.lang.c.advocacy. :)
> 
>To a large extent I'm just looking for a small smart group to have a friend= >ly intellectual discussion with.
>(and of course, don't mess up their code)
> 
> - Jay


> >
>
>> CC: jayk123 at hotmail.com; m3devel at elegosoft.com
> From: darko at dar= >ko.org
> To: rcoleburn at scires.com
> Subject: Re: [M3devel] "tar= >get specific pragmas"?
> Date: Thu, 14 Feb 2008 11:10:18 +1100
>= >;
> I actually see some benefit to Jay's postings since they make us= >
> examine some of the differences between M3 and C and explain the = >
> benefits. These questions might be asked by any C programmer
&= >gt; approaching the M3 language. It may be the point that Jay hasn't
&g= >t; created and serious software in M3 and needs to be informed of the
&= >gt; benefits. I've seen some good responses along these lines from members = >
> of the list.
>
> But Randy does have a valid point. M= >3 is is not just different to C,
> it's the antithesis of C. It's ev= >erything C isn't and the language
> designers went to great lengths = >to make it this way. It's why most of
> us use the language.
>= >
> I certainly wouldn't like to drive anyone away because they have = >a
> different point of view, but it may be a good idea to examine pr= >oblems
> and solutions more closely and offer other solutions that '= >why not do
> it like C'.
>
> In the case of printf, it = >is useful, when debugging especially, and
> I've created some code w= >hich takes a list of refany parameters and
> prints them out. It is = >a bit inefficient since any 'atomic' values
> such as integers need = >to be allocated but it also prints out all the
> fields of structure= >s and arrays. But it is completely safe. If there
> were a need for = >a more efficient way to generated formatted strings,
> I'd write som= >ething else more efficient but also configurable since
> embedding f= >ixed strings in your code is generally a a bad idea.
>
>
&= >gt; On 14/02/2008, at 4:44 AM, Randy Coleburn wrote:
>
> > = >Jay:
> >
> > I don't want to be offensive, but quite fran= >kly I'm tired of
> > continually reading your gripes about Modula= >-3 as a language and
> > your pining for C.
> >
> = >> This forum is for those people interested in advancing the state of R>> > Modula-3. We don't care about C/C++/C#/etc in this forum. Those= > of
> > us who are M3 zealots for the most part probably would we= >lcome any
> > move to divest CM3 of all underpinnings from the C = >world.
> >
> > Have you seriously studied the Modula-3 la= >nguage and used it to
> > build production software? I think some= > of your comments suggest
> > that you are not a true Modula-3 pr= >ogrammer and that you still cling
> > to the C-way of doing thing= >s rather than embracing the Modula-3 way.
> >
> > Now, I = >do think that most people are interested in improving things
> > = >and no language is perfect, so any well-thought-out proposal for a
>= > > change to the language is welcome for consideration, But in this
= >> > mail list forum, I for one would appreciate less ranting about C = >and
> > more constructive Modula-3.
> >
> > Tru= >ly, I do not want to offend you. Maybe I'm just having a bad
> > = >day, but I encourage you to try and focus your posts to the
> > a= >dvancement of Modula-3.
> >
> > Regards,
> > Ran= >dy
> >
> > >>> Jay <jayk123 at hotmail.com> 2= >/12/2008 11:28 PM >>>
> > > >My principle concern i= >s that once we provide C APIs then C will
> > > >permeate th= >e M3 space more pervasively (both apps and libraries).
> >
>= > > This is somewhat my point.
> > When I am debugging, I really= > miss printf.
> >
> > The debugging options seem really p= >oor everywhere and esp. on NT386.
> >
> > gdb has all wie= >rded out variable names for one thing.
> > And I think we should f= >ix it so that that the symbols have full
> > source paths.
>= >; > I realize they would only be correct on one machine, and hopefully <= >BR>> > there's a decent story for copying the files.
> > Yea= >h, I know about "dir" but haven't yet formed a .gdbinit or whatnot.
>= > >
> > Other than printf'ing, I also end up getting a stack in = >cdb with no
> > symbols and then disasm in gdb to find what the f= >unctions were. That
> > works fine a few times, but I hope not to= > do it often. Somewhat
> > lucky I could even get a stack. Becaus= >e, see, cdb is nice enough to
> > stop on access violations by de= >fault (such as the time/date code was
> > causing). gdb has a pro= >mising sounding feature, the ability to stop
> > on "signals", wh= >ich I think an access violation would count as, oh,
> > but that = >feature isn't implemented, sorry. Ok, true, think about it
> > mo= >re and I can break on the toplevel exception handler in
> > cygwi= >n1.dll, not sure that always works or not, it's an
> > implementa= >tion detail, but heck, when you are debugging, take
> > advantage= > of whatever you have. :)
> >
> > RTIO, is too verbose fo= >r me.
> > But darnit, I can't really have printf..puts is about th= >e best I
> > could do..
> > Oh, but no, since TEXT !=3D = >char* even that isn't useful.
> > fread/fwrite maybe though.
&g= >t; >
> > On a different hand (how many are there? :) ), have yo= >u looked in
> > m3core\src\unix?
> > There is just tons = >of dead stuff, stuff with comments about it
> > perhaps being wro= >ng, "use with care".
> > It seemed to me maybe the point was to ex= >pose "all" of /usr/include.
> > Someone, other than me, sure seems= > to have gone overboard, like
> > someone using Ultrix and Linux = >1.x, and then it copied around.
> > Heck, look at the mem* functio= >ns being commented out (and probably
> > using the incorrect type= > int) because Ultrix or somesuch didn't have
> > them. I uncommen= >ted them to fix a build. And notice that these
> > functions, aga= >in, like most of printf, are /extremely/ portable in
> > function= >ality and exact binary interface (yeah yeah, I've heard of
> > bc= >opy and bzero).
> >
> > What there was of Cstdio.i3 seeme= >d very possibly wrong, at least on
> > many targets, and very dou= >btfully useful for anything, and I think
> > I've now shown unuse= >d.
> >
> > > Y, the easiest way to implement the inter= >face is to call a C
> > function
> > > that "just hap= >pens" to have the correct interface. But on another
> >
> &g= >t; But wrapping everything in Modula-3 is so tedious...
> > Oh for= > all languages to just understand C headers so we can stop
> > re= >writing them...
> > Or some other language, ok...not going to be s= >olved in this forum.
> > To go the unpopular route (again), MS CLR= >/.NET among many other
> > things, attempts to solve this very pr= >oblem.
> > One way to describe "interfaces" that "all" languages c= >an
> > understand...at least for some subset of languages feature= >s..
> >
> > Just as tedious btw, it is often more portabl= >e to wrap all the C
> > APIs in C, exposing a portable controled = >Modula-3 interface
> > independent of the precise header content.= > Like errno and my
> > get_stderr/out/in.
> >
> &g= >t; - Jay
> >
> >
> > > To: hosking at cs.purdue.= >edu
> > > Date: Tue, 12 Feb 2008 16:37:43 -0800
> > &g= >t; From: mika at async.caltech.edu
> > > CC: m3devel at elegosoft.com= >
> > > Subject: Re: [M3devel] "target specific pragmas"?
>= >; > >
> > >
> > > This is also an excellent r= >eason not to permit "interfaces" to C
> > > code inlined into M= >ODULEs.
> > >
> > > Interfaces are the contract tha= >t the implementation has to live up
> > > to. Ok, so it happens= > that under operating system X on architecture
> > > Y, the eas= >iest way to implement the interface is to call a C
> > functionR>> > > that "just happens" to have the correct interface. But on = >another
> > > system, which either isn't built in C or where th= >e function doesn't
> > > exist, it might be convenient to imple= >ment the interface in (gasp!)
> > > Modula-3!
> > >= >
> > > (I use this pattern as follows: on systems where Intel's= > Fortran
> > > compiler is available, compile from assembly (wh= >ich was generated
> > > by ifort). On other systems, the code i= >s implemented in Modula-3.)
> > >
> > > Mika
>= >; > >
> > > Tony Hosking writes:
> > > >My= > principle concern is that once we provide C APIs then C will
> > = >> >permeate the M3 space more pervasively (both apps and libraries).<= >BR>> > > >What happens when I want to bring up a system where t= >here is no
> > > >C?!?! Consider the SPIN OS perhaps...
&= >gt; > > >
> > > >Maybe I am just being overly fusty= >...
> > > >
> > > >On Feb 12, 2008, at 4:35 P= >M, Dragi=C5=A1a Duri=C4? wrote:
> > > >
> > > &g= >t;> What we _maybe_ can do... is to make some special, preprocessable>> > > >> source
> > > >> form, which some= > quake command can parse into multiple files in
> > their
>= > > > >> folders. And these file can be compiled later...Kind of= > how
> > generic
> > > >> works.
> > &= >gt; >>
> > > >> But, as current system works, and i= >t does it very well, and as
> > only
> > > >> c= >ase
> > > >> where we really need this is Windows... most= > Unices being or
> > becoming
> > > >> POSIX...= > I don't see it's smart to spend resources on becoming
> > moreR>> > > >> C...
> > > >> Esp when "foundin= >g fathers" made it so good and so much non-C :).
> > > >>= >
> > > >> If we really need to make some approach to "the= >ir world", it's
> > much
> > > >> better to wor= >k on interoperability issues and thus cement our
> > > >>= > first-class-citizen language status even more.
> > > >><= >BR>> > > >> dd
> > > >>
> > > = >>> On Tue, 2008-02-12 at 15:16 -0500, Randy Coleburn wrote:
> &= >gt; > >>> Jay:
> > > >>>
> > >= > >>> My understanding of Modula-3 is that rather than cluttering u= >p
> > the
> > > >>> source code with a bunch= > of preprocessor directives to deal
> > with the
> > >= >; >>> various changes needed by various platforms, a separate sour= >ce
> > > >>> file is
> > > >>> us= >ed for platforms whose implementation must diverge. The
> > m3mak= >efile
> > > >>> is used to control the selection of th= >ese platform sources at
> > build
> > > >>> = >time. I like this approach much better.
> > > >>>
&= >gt; > > >>> Regards,
> > > >>> Randy>> > > >>>
> > > >>>>>> Jay= > <jayk123 at hotmail.com> 2/11/2008 8:21 PM >>>
> > &g= >t; >>> So I have NOT thought this through.
> > > >&= >gt;>
> > > >>> I wonder if "preprocessing" dependen= >t only on "target" is a good
> > > >>> idea.
> &= >gt; > >>>
> > > >>> Something like either = >the ability to prefix pragmas with a
> > target, or
> > = >> >>> an "iftarget" and "ifnottarget" pragma.
> > >= > >>>
> > > >>> Something like so:
> >= >; > >>>
> > > >>> <* IF_TARGET NT386 *&= >gt;
> > > >>> <* END_IF_TARGET*>
> > &g= >t; >>>
> > > >>>
> > > >>&g= >t; <* IF_TARGET NT386 *>
> > > >>> <* END_IF_= >TARGET*>
> > > >>> It's a small can of worms.
&g= >t; > > >>> Where can they be placed? Only at "global" scope?= > (ie:
> > toplevel in an
> > > >>> interface= >/module).
> > > >>>
> > > >>> Wha= >t about IF_OSTYPE?
> > > >>> What about expressions?R>> > > >>> IF_TARGET NT386 OR NTAMD64
> > > = >>>>
> > > >>> IF_TARGET STARTS(NT)
> &g= >t; > >>>
> > > >>> etc.
> > > = >>>>
> > > >>> I don't really have enough inte= >rest here to work through this,
> > just
> > > >&g= >t;> sending out the bait...
> > > >>>
> > = >> >>> Obviously this was triggered by my happening into the odb= >c
> > directory
> > > >>> and bringing up ig= >noring WINAPI on non-NT386 or prefixing
> > calling
> > = >> >>> conventions with a target.
> > > >>>= >
> > > >>> This reminds me of an important point here = >however -- nobody
> > else is
> > > >>> goin= >g to make the mistake of ever having multiple calling
> > > >= >;>> conventions.
> > > >>> Therefore the general= >ity of prefixing WINAPI with NT386: is
> > useless.
> > = >> >>> Unless Mac68K support is added.
> > > >>= >;>
> > > >>> And here is some rationale even. The P= >C and Mac evolved from
> > "small"
> > > >>>= > systems, where assembly programming was common, more people
> > = >knew more
> > > >>> lower level details and playing ga= >mes with calling conventions
> > was
> > > >>&g= >t; something anyone could do. Most other current systems are
> > = >rooted in C
> > > >>> programming. Working in C, calli= >ng conventions are generally
> > in a
> > > >>&= >gt; hidden layer below what anyone thinks about. Therefore, the
> &g= >t; smaller
> > > >>> number of capable people working = >at that level have the good
> > sense to
> > > >&g= >t;> only have one calling convention. No more systems will evolve
&g= >t; > from
> > > >>> "small", at least not without h= >aving observed this history.
> > > >>> Therefore,
&= >gt; > > >>> there will no longer be multiple calling convent= >ions.
> > > >>>
> > > >>> That is= > my theory at least.
> > > >>>
> > > >&= >gt;> Oh, Windows does also have __thiscall and __clrcall.
> > = >__thiscall is
> > > >>> only x86
> > > >= >;> --
> > > >> Dragi=C5=A1a Duri=C4? <dragisha at m3w.= >org>
> >
> >
> > Connect and share in new way= >s with Windows Live. Get it now!
>


Shed those ext= >ra pounds with MSN and The Biggest Loser! n.com/' target=3D'_new'>Learn more. >= > >--_26c72f2f-07a7-4258-b083-944d52866fbb_-- From wagner at elegosoft.com Thu Feb 14 09:12:09 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 14 Feb 2008 09:12:09 +0100 Subject: [M3devel] "target specific pragmas"? In-Reply-To: References: Your message of "Tue, 12 Feb 2008 18:54:50 EST." <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> <47B2E62D.1E75.00D7.1@scires.com> <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> Message-ID: <20080214091209.cvyfdwqgcok0swoc@mail.elegosoft.com> Quoting Jay : > I'll try to repeat myself less and ramble less, and stay constructive... That would be great. It's really nice that there is much more discussion here since you joined and much more work on the Windows targets, but it would still even better if you could (a) be less sarcastic (which tends to annoy some others) and (b) think once again before hitting the send button. On some days there's even so much traffic here that I can only browse the headers (there are dozens of other mails I need to pay close attention to). > You can't just be the antithesis of C. You have to decide what it is > about C that is wrong and fix it or do it over. > And then of course, agreement on what is wrong. I probably see less > wrong than you. > Bad module system -- #include. > Bad module system -- preprocesor which kills or damages other > efforts at language-aware tools. > Beyond this, at the moment, I am unsure. C is good for special kinds of system programming, with very experienced users and a code base that can still be controlled by a few minds. Large projects tend to stretch these bounds easily. For large projects taking place in a commercial environment with many teams and well-specified layers and interfaces, M3 is IMO much better suited than C (or C++, or even Java), though ironically it's not really used there (which is a pity). > I have "argued for" C++ for further "problems" in C, but I have > "grown" (or shrunk? :) ) to appreciate that C might not be as bad as > I used to think. I like C much better than C++; it's small and can be useful. C++ is way too large and complex and has never been exactly defined. When we used to program point of sale systems in the early 90s for a company here in Berlin, we had two large files of more than 1200 pages which was the upcoming C++ spec draft. Nobody has ever read even 1/10 of it. We tried about half a dozen compilers, each with nice features, but they were completely incompatible, and cost much efforts to keep code even syntactically accepted. > If you start over completely from scratch, you should still look at > what is out there. Well, we're not doing that here (starting from scratch). M3 is a well-defined and well working language, and the community here likes to use it. I'm not against language changes in general, but they need to be considered very well if we really want to improve the language. Addition of a portable 64 bit integer type for once was something that was needed, because hardware architectures and operating systems have changed. > Granted, some things are mostly arbitrary. Braces vs. begin/end. But > the editors all support braces now. > Until you get me to change editors (probably never), Modula-3 is > always going to be less convenient. Any decent editor can be configured wrt. syntax highlighting and writing support (we even had that for the simple DOS editors we were using at the university together with Modula-2). Have you tried (X)Emacs? There's a really nice m3-mode for it, with highlighting and automatic completion of all language constructs. > At this point you are just fighting the vast majority (except > Python...). It could have gone differently, but C won. I'm not fighting anybody here ;-) > If you ignore that lowest level thing, there are places where > Modula-3 is perfectly good, but doesn't take the next step. > A good example I think here is it has nice "objects", however it > requires they be heap allocated I think even in unsafe code. You > should be able stack (or global) allocate something with "virtual > functions". It seems an arbitrary limitation. I realize in safe > code, you have to heap allocate more anyway, but that is a different > point I think. I'm not sure if that is really needed. > Similarly is "multiple inheritance just of interfaces". I realize > though..this hides a "vtable per interface". Maybe is much more > expensive than people realize and shouldn't be provided lightly. Multiple inheritance was left out of the language after long discussions because it was not really understood at that time. It may be that things have changed in this respect, but I still don't think it is. > Maybe I just need to reread Nelson's book. You know..reference vs. > tutorial. The language reference is very very terse and that is ok. > Short on examples. A tutorial that gives many examples might be > good. Hey maybe I'm just the newbie in a good position to write it. > (not) You can express quite a lot of unexpected things with the few language constructs. Often I'm still amazed at the ideas of other programmers when reading M3 code. > I guess I should be in comp.lang.c.advocacy. :) Yes, some of your comments would be better placed there :) > To a large extent I'm just looking for a small smart group to have a > friendly intellectual discussion with. > (and of course, don't mess up their code) I think you can have that here. People are willing to discuss and think things over, but the pace may be somewhat slower than you'd like :-) (It's not as bad as with Tolkien's Ents, but still ... slow :) So, as others have noted, it's great that there is so much activity recently, but it would still be better if the discussions and comments were more focused on important language related content about M3. Nobody has accused you of malicious intentions, and you've always accepted objections and corrections by others as far as I remember. I think what is mostly needed is to slightly adapt your style of working and discussing things to become better accepted here. Don't speak out too rash, and don't commit lots of small changes too soon. Work things out and become more self-confident about the results of your work. I'm sure you can contribute many interesting things to M3. Olaf PS: Sorry if some of the above reads as if I'm your teacher ;-) -- Olaf Wagner -- elego Software Solutions GmbH 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 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jayk123 at hotmail.com Thu Feb 14 09:38:14 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 14 Feb 2008 08:38:14 +0000 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <200802140200.m1E20k5k062986@camembert.async.caltech.edu> References: Your message of "Thu, 14 Feb 2008 00:34:44 GMT." <200802140200.m1E20k5k062986@camembert.async.caltech.edu> Message-ID: too much to respond to right now... Yes C++ certainly allows virtual functions on stack allocated objects. class Foo{public: virtual void Bar();}; void F(){ Foo foo; foo.Bar();} works fine. You can take the address and pass it around, etc., just don't return it of course. You are right that a record with procedures might suffice.I've been using them in C lately: struct Foo_t;typedef struct Foo_t Foo_t;struct FooFunctions_t;typedef struct FooFunctions_t FooFunctions_t; struct FooFunctions_t{ // probably never any data here, it muddies the model, but maybe void (*DoSomething)(Foo_t*); void (*OrSomethingElse)(Foo_t*, size_t a, size_t b);}; struct Foo_t{ // probably never any data here, it muddies the model, but maybe const FooFunctions_t* Functions;}; // see winnt.h for exactly correct definition#define CONTAINING_RECORD(basepointer, derivedtype, basefield) ((derivedtype*) ((char*)basepointer) - (offsetof(derivedtype, basefield)))) struct Bar_t{ size_t BarData...; Foo_t Base;}; void Bar_DoSomething(Foo_t* Foo){ Bar* = CONTAINING_RECORD(Foo, Bar_t, Base) do something with Bar->BarData...} void Bar_OrSomethingElse(...) ... const FooFunctions ={ &Bar_DoSomething, &Bar_OrSomethingElse}; Foo_t* Bar_Create(){ Bar_t* Bar = (Bar_t*) calloc(1, sizeof(*Bar)); if (Bar == NULL) .... Bar->Functions = &FooFunctions; return &Bar->Base; } Foo_t* f = Bar_Create(); f->Functions->DoSomething(f); // ouch a double pointer deref, maybe code will cache the functions though CONTAINING_RECORD isn't really needed here -- Base can be at the start -- but this slightly generalized pattern supports more types of inheritance better. Presumably I can just clone this in about as much Modula-3. I'll have to try it out when I find an excuse for having "COM-like" interfaces. "I can have my C and a good module system too." :) It is a little tedious, but it keeps you off the slippery slope of C++. :) C++ has few stupid limits I can think of. One is that types (or constants) with internal linkage can't be template parameters. void F() { struct point { int a,b; }; std::vector points; // error special_debugging_class<"print me"> abc; // error } Maybe the last is fixed though. And they are both widely acknowledged to be dumb. Though I think they have an obvious rationale. (You all can guess?) True I haven't written much Modula-3. I do look around the tree some and I do see a lot gross duplication of code/effort. Yes Modula-3 enums and sets and their interaction with arrays is nice. It was actually cryptically terse to me at first but I figured it out. Optional bounds checking on arrays, good. C++ gives you what you generally need to implement sets and good arrays. C is soso. You know, the main thing you have to give up in C regarding user defined types is using those special operator characters on them. You must make explicit function calls. There is this real tension between building stuff into a language vs. building in enough facilities for people to put in libraries what they "thought" should be in the language. Same thing even goes for libraries themselves. Do you put more functionality "in" them, or provide the right composable pieces for people to build what they want. Exceptions (which nobody mentioned) are a mixed bag btw. It's not that hard really to get C correct, esp. with macros and goto (seriously!) but also not clearly worth it. Optional garbage collection maybe nice, again not so hard in C, and C++ gives you, in a sense, garbage collection and much much more along these lines via "RIAA". Also true that lots of languages don't compile to native code. The CLR does promise to be the last system to need this (at runtime or install time) and everyone else can target it. Java (VM) is similar but not general purpose enough. True that name mangling is kind of lame. Try searching for the functions, or debugging (how do I specify the name to a command line debugger? It isn't necessarily impossible, but it's another varying complexity.) Also, on the "American Idol" point, true, good point, being right and good is better than being popular, but there are network affects and some of them are desirable. It's true you don't want everyone jumping on your bandwagon, you want to keep some folks out, but having other people writing tools (editors, etc.) that you can use CAN be very nice. True again I'm a lazy typist but a frequent reader. But begin/end are no more readable than braces. It seems arbitrary, except for the network affects that make my editor favor braces. ..Jay > To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] "target specific pragmas"? > Date: Wed, 13 Feb 2008 18:00:46 -0800> From: mika at async.caltech.edu> > > I should point out that I am not trying to tell you that Modula-3> is better than C++ and you should immediately switch and stop talking> about the wonderful features of C++. It's not and if you are> competent enough to be coding in C++ and happy with it you should> certainly not.> > A way to summarize what I said before is this. I do not consider> myself a good programmer. Yet I sit in front of my computer trying> to write software that plays with millions of dollars of other> people's money. I simply do not trust myself to use a tool as sharp> and unconstrained as C++. The constraints of enumerated types,> subranges, typechecking at interfaces and runtime, bounds-checked> arrays etc., let me sleep a bit better (but still not well).> > I am reminded of something my advisor's advisor once wrote, regarding> the difficulty of producing large software systems:> > We shall do a much better programming job, provided that we> approach the task with a full appreciation of its tremendous> difficulty, provided that we stick to modest and elegant programming> languages, provided that we respect the intrinsic limitations> of the human mind and approach the task as Very Humble Programmers.> > ( http://www.cs.utexas.edu/~EWD/ewd03xx/EWD340.PDF > CACM 15, 1972, #10, 859-866)> > Mika> > > > > > > Jay writes:> >--_26c72f2f-07a7-4258-b083-944d52866fbb_> >Content-Type: text/plain; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >I'll try to repeat myself less and ramble less, and stay constructive...> >=20> >I understand that printf type unsafety stinks and I have been bitten by it,=> > but it is nicely terse, crude but effective, I'm going to throw away the c=> >ode probably once the bug is fixed. (Ok, I like to comment out or somehow d=> >isable sometimes maybe but that is a different point, it's still not the he=> >ight of production code; and yes, I realize it's a slippery slope and the n=> >ext thing I'll do is use it in production code; debugging is just what I'm => >doing now, next up, real code).> >=20> >You can't just be the antithesis of C. You have to decide what it is about => >C that is wrong and fix it or do it over.> >And then of course, agreement on what is wrong. I probably see less wrong t=> >han you.> >Bad module system -- #include.> >Bad module system -- preprocesor which kills or damages other efforts at la=> >nguage-aware tools.> >Beyond this, at the moment, I am unsure.> >I have "argued for" C++ for further "problems" in C, but I have "grown" (or=> > shrunk? :) ) to appreciate that C might not be as bad as I used to think.> >=20> >If you start over completely from scratch, you should still look at what is=> > out there.> >Granted, some things are mostly arbitrary. Braces vs. begin/end. But the ed=> >itors all support braces now.> >Until you get me to change editors (probably never), Modula-3 is always goi=> >ng to be less convenient.> >At this point you are just fighting the vast majority (except Python...). I=> >t could have gone differently, but C won.> >=20> >If you ignore that lowest level thing, there are places where Modula-3 is p=> >erfectly good, but doesn't take the next step.> >A good example I think here is it has nice "objects", however it requires t=> >hey be heap allocated I think even in unsafe code. You should be able stack=> > (or global) allocate something with "virtual functions". It seems an arbit=> >rary limitation. I realize in safe code, you have to heap allocate more any=> >way, but that is a different point I think.> >=20> >Similarly is "multiple inheritance just of interfaces". I realize though..t=> >his hides a "vtable per interface". Maybe is much more expensive than peopl=> >e realize and shouldn't be provided lightly.> >=20> >SUBARRAY is probably example where I don't/didn't know the language well en=> >ough.> > And maybe the docs aren't good here.> >And VAR/BEGIN.> >Maybe I just need to reread Nelson's book. You know..reference vs. tutorial=> >. The language reference is very very terse and that is ok. Short on exampl=> >es. A tutorial that gives many examples might be good. Hey maybe I'm just t=> >he newbie in a good position to write it. (not)> >=20> >I guess I should be in comp.lang.c.advocacy. :)> >=20> >To a large extent I'm just looking for a small smart group to have a friend=> >ly intellectual discussion with.> >(and of course, don't mess up their code)> >=20> > - Jay> >> >> >> >> CC: jayk123 at hotmail.com; m3devel at elegosoft.com> From: darko at darko.org> To=> >: rcoleburn at scires.com> Subject: Re: [M3devel] "target specific pragmas"?> => >Date: Thu, 14 Feb 2008 11:10:18 +1100> > I actually see some benefit to Jay=> >'s postings since they make us > examine some of the differences between M3=> > and C and explain the > benefits. These questions might be asked by any C => >programmer > approaching the M3 language. It may be the point that Jay hasn=> >'t > created and serious software in M3 and needs to be informed of the > b=> >enefits. I've seen some good responses along these lines from members > of => >the list.> > But Randy does have a valid point. M3 is is not just different=> > to C, > it's the antithesis of C. It's everything C isn't and the language=> > > designers went to great lengths to make it this way. It's why most of > => >us use the language.> > I certainly wouldn't like to drive anyone away beca=> >use they have a > different point of view, but it may be a good idea to exa=> >mine problems > and solutions more closely and offer other solutions that '=> >why not do > it like C'.> > In the case of printf, it is useful, when debug=> >ging especially, and > I've created some code which takes a list of refany => >parameters and > prints them out. It is a bit inefficient since any 'atomic=> >' values > such as integers need to be allocated but it also prints out all=> > the > fields of structures and arrays. But it is completely safe. If there=> > > were a need for a more efficient way to generated formatted strings, > I=> >'d write something else more efficient but also configurable since > embedd=> >ing fixed strings in your code is generally a a bad idea.> > > On 14/02/200=> >8, at 4:44 AM, Randy Coleburn wrote:> > > Jay:> >> > I don't want to be off=> >ensive, but quite frankly I'm tired of > > continually reading your gripes => >about Modula-3 as a language and > > your pining for C.> >> > This forum is=> > for those people interested in advancing the state of > > Modula-3. We don=> >'t care about C/C++/C#/etc in this forum. Those of > > us who are M3 zealot=> >s for the most part probably would welcome any > > move to divest CM3 of al=> >l underpinnings from the C world.> >> > Have you seriously studied the Modu=> >la-3 language and used it to > > build production software? I think some of=> > your comments suggest > > that you are not a true Modula-3 programmer and => >that you still cling > > to the C-way of doing things rather than embracing=> > the Modula-3 way.> >> > Now, I do think that most people are interested in=> > improving things > > and no language is perfect, so any well-thought-out p=> >roposal for a > > change to the language is welcome for consideration, But => >in this > > mail list forum, I for one would appreciate less ranting about => >C and > > more constructive Modula-3.> >> > Truly, I do not want to offend => >you. Maybe I'm just having a bad > > day, but I encourage you to try and fo=> >cus your posts to the > > advancement of Modula-3.> >> > Regards,> > Randy>=> > >> > >>> Jay 2/12/2008 11:28 PM >>>> > > >My princip=> >le concern is that once we provide C APIs then C will> > > >permeate the M3=> > space more pervasively (both apps and libraries).> >> > This is somewhat m=> >y point.> > When I am debugging, I really miss printf.> >> > The debugging => >options seem really poor everywhere and esp. on NT386.> >> > gdb has all wi=> >erded out variable names for one thing.> > And I think we should fix it so => >that that the symbols have full > > source paths.> > I realize they would o=> >nly be correct on one machine, and hopefully > > there's a decent story for=> > copying the files.> > Yeah, I know about "dir" but haven't yet formed a .g=> >dbinit or whatnot.> >> > Other than printf'ing, I also end up getting a sta=> >ck in cdb with no > > symbols and then disasm in gdb to find what the funct=> >ions were. That > > works fine a few times, but I hope not to do it often. => >Somewhat > > lucky I could even get a stack. Because, see, cdb is nice enou=> >gh to > > stop on access violations by default (such as the time/date code => >was > > causing). gdb has a promising sounding feature, the ability to stop=> > > > on "signals", which I think an access violation would count as, oh, > => >> but that feature isn't implemented, sorry. Ok, true, think about it > > m=> >ore and I can break on the toplevel exception handler in > > cygwin1.dll, n=> >ot sure that always works or not, it's an > > implementation detail, but he=> >ck, when you are debugging, take > > advantage of whatever you have. :)> >>=> > > RTIO, is too verbose for me.> > But darnit, I can't really have printf..=> >puts is about the best I > > could do..> > Oh, but no, since TEXT !=3D char=> >* even that isn't useful.> > fread/fwrite maybe though.> >> > On a differen=> >t hand (how many are there? :) ), have you looked in > > m3core\src\unix?> => >> There is just tons of dead stuff, stuff with comments about it > > perhap=> >s being wrong, "use with care".> > It seemed to me maybe the point was to e=> >xpose "all" of /usr/include.> > Someone, other than me, sure seems to have => >gone overboard, like > > someone using Ultrix and Linux 1.x, and then it co=> >pied around.> > Heck, look at the mem* functions being commented out (and p=> >robably > > using the incorrect type int) because Ultrix or somesuch didn't=> > have > > them. I uncommented them to fix a build. And notice that these > => >> functions, again, like most of printf, are /extremely/ portable in > > fu=> >nctionality and exact binary interface (yeah yeah, I've heard of > > bcopy => >and bzero).> >> > What there was of Cstdio.i3 seemed very possibly wrong, a=> >t least on > > many targets, and very doubtfully useful for anything, and I=> > think > > I've now shown unused.> >> > > Y, the easiest way to implement t=> >he interface is to call a C > > function> > > that "just happens" to have t=> >he correct interface. But on another> >> > But wrapping everything in Modul=> >a-3 is so tedious...> > Oh for all languages to just understand C headers s=> >o we can stop > > rewriting them...> > Or some other language, ok...not goi=> >ng to be solved in this forum.> > To go the unpopular route (again), MS CLR=> >/.NET among many other > > things, attempts to solve this very problem.> > => >One way to describe "interfaces" that "all" languages can > > understand...=> >at least for some subset of languages features..> >> > Just as tedious btw,=> > it is often more portable to wrap all the C > > APIs in C, exposing a port=> >able controled Modula-3 interface > > independent of the precise header con=> >tent. Like errno and my > > get_stderr/out/in.> >> > - Jay> >> >> > > To: h=> >osking at cs.purdue.edu> > > Date: Tue, 12 Feb 2008 16:37:43 -0800> > > From: => >mika at async.caltech.edu> > > CC: m3devel at elegosoft.com> > > Subject: Re: [M3=> >devel] "target specific pragmas"?> > >> > >> > > This is also an excellent => >reason not to permit "interfaces" to C> > > code inlined into MODULEs.> > >=> >> > > Interfaces are the contract that the implementation has to live up> >=> > > to. Ok, so it happens that under operating system X on architecture> > >=> > Y, the easiest way to implement the interface is to call a C > > function>=> > > > that "just happens" to have the correct interface. But on another> > >=> > system, which either isn't built in C or where the function doesn't> > > e=> >xist, it might be convenient to implement the interface in (gasp!)> > > Mod=> >ula-3!> > >> > > (I use this pattern as follows: on systems where Intel's F=> >ortran> > > compiler is available, compile from assembly (which was generat=> >ed> > > by ifort). On other systems, the code is implemented in Modula-3.)>=> > > >> > > Mika> > >> > > Tony Hosking writes:> > > >My principle concern is=> > that once we provide C APIs then C will> > > >permeate the M3 space more p=> >ervasively (both apps and libraries).> > > >What happens when I want to bri=> >ng up a system where there is no> > > >C?!?! Consider the SPIN OS perhaps..=> >.> > > >> > > >Maybe I am just being overly fusty...> > > >> > > >On Feb 12=> >, 2008, at 4:35 PM, Dragi=C5=A1a Duri=C4? wrote:> > > >> > > >> What we _ma=> >ybe_ can do... is to make some special, preprocessable> > > >> source> > > => >>> form, which some quake command can parse into multiple files in > > thei=> >r> > > >> folders. And these file can be compiled later...Kind of how > > g=> >eneric> > > >> works.> > > >>> > > >> But, as current system works, and it => >does it very well, and as > > only> > > >> case> > > >> where we really nee=> >d this is Windows... most Unices being or > > becoming> > > >> POSIX... I d=> >on't see it's smart to spend resources on becoming > > more> > > >> C...> >=> > > >> Esp when "founding fathers" made it so good and so much non-C :).> > => >> >>> > > >> If we really need to make some approach to "their world", it's=> > > > much> > > >> better to work on interoperability issues and thus cement=> > our> > > >> first-class-citizen language status even more.> > > >>> > > >>=> > dd> > > >>> > > >> On Tue, 2008-02-12 at 15:16 -0500, Randy Coleburn wrote=> >:> > > >>> Jay:> > > >>>> > > >>> My understanding of Modula-3 is that rath=> >er than cluttering up > > the> > > >>> source code with a bunch of preproce=> >ssor directives to deal > > with the> > > >>> various changes needed by var=> >ious platforms, a separate source> > > >>> file is> > > >>> used for platfo=> >rms whose implementation must diverge. The > > m3makefile> > > >>> is used => >to control the selection of these platform sources at > > build> > > >>> ti=> >me. I like this approach much better.> > > >>>> > > >>> Regards,> > > >>> R=> >andy> > > >>>> > > >>>>>> Jay 2/11/2008 8:21 PM >>>> => >> > >>> So I have NOT thought this through.> > > >>>> > > >>> I wonder if "=> >preprocessing" dependent only on "target" is a good> > > >>> idea.> > > >>>=> >> > > >>> Something like either the ability to prefix pragmas with a > > ta=> >rget, or> > > >>> an "iftarget" and "ifnottarget" pragma.> > > >>>> > > >>>=> > Something like so:> > > >>>> > > >>> <* IF_TARGET NT386 *>> > > >>> <* END=> >_IF_TARGET*>> > > >>>> > > >>>> > > >>> <* IF_TARGET NT386 *>> > > >>> <* E=> >ND_IF_TARGET*>> > > >>> It's a small can of worms.> > > >>> Where can they => >be placed? Only at "global" scope? (ie: > > toplevel in an> > > >>> interfa=> >ce/module).> > > >>>> > > >>> What about IF_OSTYPE?> > > >>> What about exp=> >ressions?> > > >>> IF_TARGET NT386 OR NTAMD64> > > >>>> > > >>> IF_TARGET S=> >TARTS(NT)> > > >>>> > > >>> etc.> > > >>>> > > >>> I don't really have enou=> >gh interest here to work through this, > > just> > > >>> sending out the ba=> >it...> > > >>>> > > >>> Obviously this was triggered by my happening into t=> >he odbc > > directory> > > >>> and bringing up ignoring WINAPI on non-NT386=> > or prefixing > > calling> > > >>> conventions with a target.> > > >>>> > >=> > >>> This reminds me of an important point here however -- nobody > > else => >is> > > >>> going to make the mistake of ever having multiple calling> > > => >>>> conventions.> > > >>> Therefore the generality of prefixing WINAPI with=> > NT386: is > > useless.> > > >>> Unless Mac68K support is added.> > > >>>> => >> > >>> And here is some rationale even. The PC and Mac evolved from > > "s=> >mall"> > > >>> systems, where assembly programming was common, more people => >> > knew more> > > >>> lower level details and playing games with calling c=> >onventions > > was> > > >>> something anyone could do. Most other current s=> >ystems are > > rooted in C> > > >>> programming. Working in C, calling conv=> >entions are generally > > in a> > > >>> hidden layer below what anyone thin=> >ks about. Therefore, the > > smaller> > > >>> number of capable people work=> >ing at that level have the good > > sense to> > > >>> only have one calling=> > convention. No more systems will evolve > > from> > > >>> "small", at leas=> >t not without having observed this history.> > > >>> Therefore,> > > >>> th=> >ere will no longer be multiple calling conventions.> > > >>>> > > >>> That => >is my theory at least.> > > >>>> > > >>> Oh, Windows does also have __thisc=> >all and __clrcall. > > __thiscall is> > > >>> only x86> > > >> --> > > >> D=> >ragi=C5=A1a Duri=C4? > >> >> > Connect and share in new w=> >ays with Windows Live. Get it now!>=20> >_________________________________________________________________> >Shed those extra pounds with MSN and The Biggest Loser!> >http://biggestloser.msn.com/=> >> >--_26c72f2f-07a7-4258-b083-944d52866fbb_> >Content-Type: text/html; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >> >> >> >> >I'll try to repeat myself less and rambl=> >e less, and stay constructive...
> > 
> >I understand that printf type unsafety stinks and I have been bitten by it,=> > but it is nicely terse, crude but effective, I'm going to throw away the c=> >ode probably once the bug is fixed. (Ok, I like to comment out or somehow d=> >isable sometimes maybe but that is a different point, it's still not the he=> >ight of production code; and yes, I realize it's a slippery slope and the n=> >ext thing I'll do is use it in production code; debugging is just what I'm => >doing now, next up, real code).
> > 
> >You can't just be the antithesis of C. You have to decide what it is about => >C that is wrong and fix it or do it over.
> >And then of course, agreement on what is wrong. I probably see less wrong t=> >han you.
> >Bad module system -- #include.
> >Bad module system -- preprocesor which kills or damages other efforts at la=> >nguage-aware tools.
> >Beyond this, at the moment, I am unsure.
> >I have "argued for" C++ for further "problems" in C, but I have "grown" (or=> > shrunk? :) ) to appreciate that C might not be as bad as I used to think.<=> >BR>> > 
> >If you start over completely from scratch, you should still look at what is=> > out there.
> >Granted, some things are mostly arbitrary. Braces vs. begin/end. But the ed=> >itors all support braces now.
> >Until you get me to change editors (probably never), Modula-3 is always goi=> >ng to be less convenient.
> >At this point you are just fighting the vast majority (except Python...). I=> >t could have gone differently, but C won.
> > 
> >If you ignore that lowest level thing, there are places where Modula-3 is p=> >erfectly good, but doesn't take the next step.
> >A good example I think here is it has nice "objects", however it requires t=> >hey be heap allocated I think even in unsafe code. You should be able stack=> > (or global) allocate something with "virtual functions". It seems an arbit=> >rary limitation. I realize in safe code, you have to heap allocate more any=> >way, but that is a different point I think.
> > 
> >Similarly is "multiple inheritance just of interfaces". I realize though..t=> >his hides a "vtable per interface". Maybe is much more expensive than peopl=> >e realize and shouldn't be provided lightly.
> > 
> >SUBARRAY is probably example where I don't/didn't know the language well en=> >ough.
> >  And maybe the docs aren't good here.
> >And VAR/BEGIN.
> >Maybe I just need to reread Nelson's book. You know..reference vs. tutorial=> >. The language reference is very very terse and that is ok. Short on exampl=> >es. A tutorial that gives many examples might be good. Hey maybe I'm just t=> >he newbie in a good position to write it. (not)
> > 
> >I guess I should be in comp.lang.c.advocacy. :)
> > 
> >To a large extent I'm just looking for a small smart group to have a friend=> >ly intellectual discussion with.
> >(and of course, don't mess up their code)
> > 
> > - Jay


> >> >
> >
> >> CC: jayk123 at hotmail.com; m3devel at elegosoft.com
> From: darko at dar=> >ko.org
> To: rcoleburn at scires.com
> Subject: Re: [M3devel] "tar=> >get specific pragmas"?
> Date: Thu, 14 Feb 2008 11:10:18 +1100
>=> >;
> I actually see some benefit to Jay's postings since they make us=> >
> examine some of the differences between M3 and C and explain the => >
> benefits. These questions might be asked by any C programmer
&=> >gt; approaching the M3 language. It may be the point that Jay hasn't
&g=> >t; created and serious software in M3 and needs to be informed of the
&=> >gt; benefits. I've seen some good responses along these lines from members => >
> of the list.
>
> But Randy does have a valid point. M=> >3 is is not just different to C,
> it's the antithesis of C. It's ev=> >erything C isn't and the language
> designers went to great lengths => >to make it this way. It's why most of
> us use the language.
>=> >
> I certainly wouldn't like to drive anyone away because they have => >a
> different point of view, but it may be a good idea to examine pr=> >oblems
> and solutions more closely and offer other solutions that '=> >why not do
> it like C'.
>
> In the case of printf, it => >is useful, when debugging especially, and
> I've created some code w=> >hich takes a list of refany parameters and
> prints them out. It is => >a bit inefficient since any 'atomic' values
> such as integers need => >to be allocated but it also prints out all the
> fields of structure=> >s and arrays. But it is completely safe. If there
> were a need for => >a more efficient way to generated formatted strings,
> I'd write som=> >ething else more efficient but also configurable since
> embedding f=> >ixed strings in your code is generally a a bad idea.
>
>
&=> >gt; On 14/02/2008, at 4:44 AM, Randy Coleburn wrote:
>
> > => >Jay:
> >
> > I don't want to be offensive, but quite fran=> >kly I'm tired of
> > continually reading your gripes about Modula=> >-3 as a language and
> > your pining for C.
> >
> => >> This forum is for those people interested in advancing the state of >R>> > Modula-3. We don't care about C/C++/C#/etc in this forum. Those=> > of
> > us who are M3 zealots for the most part probably would we=> >lcome any
> > move to divest CM3 of all underpinnings from the C => >world.
> >
> > Have you seriously studied the Modula-3 la=> >nguage and used it to
> > build production software? I think some=> > of your comments suggest
> > that you are not a true Modula-3 pr=> >ogrammer and that you still cling
> > to the C-way of doing thing=> >s rather than embracing the Modula-3 way.
> >
> > Now, I => >do think that most people are interested in improving things
> > => >and no language is perfect, so any well-thought-out proposal for a
>=> > > change to the language is welcome for consideration, But in this
=> >> > mail list forum, I for one would appreciate less ranting about C => >and
> > more constructive Modula-3.
> >
> > Tru=> >ly, I do not want to offend you. Maybe I'm just having a bad
> > => >day, but I encourage you to try and focus your posts to the
> > a=> >dvancement of Modula-3.
> >
> > Regards,
> > Ran=> >dy
> >
> > >>> Jay <jayk123 at hotmail.com> 2=> >/12/2008 11:28 PM >>>
> > > >My principle concern i=> >s that once we provide C APIs then C will
> > > >permeate th=> >e M3 space more pervasively (both apps and libraries).
> >
>=> > > This is somewhat my point.
> > When I am debugging, I really=> > miss printf.
> >
> > The debugging options seem really p=> >oor everywhere and esp. on NT386.
> >
> > gdb has all wie=> >rded out variable names for one thing.
> > And I think we should f=> >ix it so that that the symbols have full
> > source paths.
>=> >; > I realize they would only be correct on one machine, and hopefully <=> >BR>> > there's a decent story for copying the files.
> > Yea=> >h, I know about "dir" but haven't yet formed a .gdbinit or whatnot.
>=> > >
> > Other than printf'ing, I also end up getting a stack in => >cdb with no
> > symbols and then disasm in gdb to find what the f=> >unctions were. That
> > works fine a few times, but I hope not to=> > do it often. Somewhat
> > lucky I could even get a stack. Becaus=> >e, see, cdb is nice enough to
> > stop on access violations by de=> >fault (such as the time/date code was
> > causing). gdb has a pro=> >mising sounding feature, the ability to stop
> > on "signals", wh=> >ich I think an access violation would count as, oh,
> > but that => >feature isn't implemented, sorry. Ok, true, think about it
> > mo=> >re and I can break on the toplevel exception handler in
> > cygwi=> >n1.dll, not sure that always works or not, it's an
> > implementa=> >tion detail, but heck, when you are debugging, take
> > advantage=> > of whatever you have. :)
> >
> > RTIO, is too verbose fo=> >r me.
> > But darnit, I can't really have printf..puts is about th=> >e best I
> > could do..
> > Oh, but no, since TEXT !=3D => >char* even that isn't useful.
> > fread/fwrite maybe though.
&g=> >t; >
> > On a different hand (how many are there? :) ), have yo=> >u looked in
> > m3core\src\unix?
> > There is just tons => >of dead stuff, stuff with comments about it
> > perhaps being wro=> >ng, "use with care".
> > It seemed to me maybe the point was to ex=> >pose "all" of /usr/include.
> > Someone, other than me, sure seems=> > to have gone overboard, like
> > someone using Ultrix and Linux => >1.x, and then it copied around.
> > Heck, look at the mem* functio=> >ns being commented out (and probably
> > using the incorrect type=> > int) because Ultrix or somesuch didn't have
> > them. I uncommen=> >ted them to fix a build. And notice that these
> > functions, aga=> >in, like most of printf, are /extremely/ portable in
> > function=> >ality and exact binary interface (yeah yeah, I've heard of
> > bc=> >opy and bzero).
> >
> > What there was of Cstdio.i3 seeme=> >d very possibly wrong, at least on
> > many targets, and very dou=> >btfully useful for anything, and I think
> > I've now shown unuse=> >d.
> >
> > > Y, the easiest way to implement the inter=> >face is to call a C
> > function
> > > that "just hap=> >pens" to have the correct interface. But on another
> >
> &g=> >t; But wrapping everything in Modula-3 is so tedious...
> > Oh for=> > all languages to just understand C headers so we can stop
> > re=> >writing them...
> > Or some other language, ok...not going to be s=> >olved in this forum.
> > To go the unpopular route (again), MS CLR=> >/.NET among many other
> > things, attempts to solve this very pr=> >oblem.
> > One way to describe "interfaces" that "all" languages c=> >an
> > understand...at least for some subset of languages feature=> >s..
> >
> > Just as tedious btw, it is often more portabl=> >e to wrap all the C
> > APIs in C, exposing a portable controled => >Modula-3 interface
> > independent of the precise header content.=> > Like errno and my
> > get_stderr/out/in.
> >
> &g=> >t; - Jay
> >
> >
> > > To: hosking at cs.purdue.=> >edu
> > > Date: Tue, 12 Feb 2008 16:37:43 -0800
> > &g=> >t; From: mika at async.caltech.edu
> > > CC: m3devel at elegosoft.com=> >
> > > Subject: Re: [M3devel] "target specific pragmas"?
>=> >; > >
> > >
> > > This is also an excellent r=> >eason not to permit "interfaces" to C
> > > code inlined into M=> >ODULEs.
> > >
> > > Interfaces are the contract tha=> >t the implementation has to live up
> > > to. Ok, so it happens=> > that under operating system X on architecture
> > > Y, the eas=> >iest way to implement the interface is to call a C
> > function >R>> > > that "just happens" to have the correct interface. But on => >another
> > > system, which either isn't built in C or where th=> >e function doesn't
> > > exist, it might be convenient to imple=> >ment the interface in (gasp!)
> > > Modula-3!
> > >=> >
> > > (I use this pattern as follows: on systems where Intel's=> > Fortran
> > > compiler is available, compile from assembly (wh=> >ich was generated
> > > by ifort). On other systems, the code i=> >s implemented in Modula-3.)
> > >
> > > Mika
>=> >; > >
> > > Tony Hosking writes:
> > > >My=> > principle concern is that once we provide C APIs then C will
> > => >> >permeate the M3 space more pervasively (both apps and libraries).<=> >BR>> > > >What happens when I want to bring up a system where t=> >here is no
> > > >C?!?! Consider the SPIN OS perhaps...
&=> >gt; > > >
> > > >Maybe I am just being overly fusty=> >...
> > > >
> > > >On Feb 12, 2008, at 4:35 P=> >M, Dragi=C5=A1a Duri=C4? wrote:
> > > >
> > > &g=> >t;> What we _maybe_ can do... is to make some special, preprocessable >>> > > >> source
> > > >> form, which some=> > quake command can parse into multiple files in
> > their
>=> > > > >> folders. And these file can be compiled later...Kind of=> > how
> > generic
> > > >> works.
> > &=> >gt; >>
> > > >> But, as current system works, and i=> >t does it very well, and as
> > only
> > > >> c=> >ase
> > > >> where we really need this is Windows... most=> > Unices being or
> > becoming
> > > >> POSIX...=> > I don't see it's smart to spend resources on becoming
> > more >R>> > > >> C...
> > > >> Esp when "foundin=> >g fathers" made it so good and so much non-C :).
> > > >>=> >
> > > >> If we really need to make some approach to "the=> >ir world", it's
> > much
> > > >> better to wor=> >k on interoperability issues and thus cement our
> > > >>=> > first-class-citizen language status even more.
> > > >><=> >BR>> > > >> dd
> > > >>
> > > => >>> On Tue, 2008-02-12 at 15:16 -0500, Randy Coleburn wrote:
> &=> >gt; > >>> Jay:
> > > >>>
> > >=> > >>> My understanding of Modula-3 is that rather than cluttering u=> >p
> > the
> > > >>> source code with a bunch=> > of preprocessor directives to deal
> > with the
> > >=> >; >>> various changes needed by various platforms, a separate sour=> >ce
> > > >>> file is
> > > >>> us=> >ed for platforms whose implementation must diverge. The
> > m3mak=> >efile
> > > >>> is used to control the selection of th=> >ese platform sources at
> > build
> > > >>> => >time. I like this approach much better.
> > > >>>
&=> >gt; > > >>> Regards,
> > > >>> Randy >>> > > >>>
> > > >>>>>> Jay=> > <jayk123 at hotmail.com> 2/11/2008 8:21 PM >>>
> > &g=> >t; >>> So I have NOT thought this through.
> > > >&=> >gt;>
> > > >>> I wonder if "preprocessing" dependen=> >t only on "target" is a good
> > > >>> idea.
> &=> >gt; > >>>
> > > >>> Something like either => >the ability to prefix pragmas with a
> > target, or
> > => >> >>> an "iftarget" and "ifnottarget" pragma.
> > >=> > >>>
> > > >>> Something like so:
> >=> >; > >>>
> > > >>> <* IF_TARGET NT386 *&=> >gt;
> > > >>> <* END_IF_TARGET*>
> > &g=> >t; >>>
> > > >>>
> > > >>&g=> >t; <* IF_TARGET NT386 *>
> > > >>> <* END_IF_=> >TARGET*>
> > > >>> It's a small can of worms.
&g=> >t; > > >>> Where can they be placed? Only at "global" scope?=> > (ie:
> > toplevel in an
> > > >>> interface=> >/module).
> > > >>>
> > > >>> Wha=> >t about IF_OSTYPE?
> > > >>> What about expressions? >R>> > > >>> IF_TARGET NT386 OR NTAMD64
> > > => >>>>
> > > >>> IF_TARGET STARTS(NT)
> &g=> >t; > >>>
> > > >>> etc.
> > > => >>>>
> > > >>> I don't really have enough inte=> >rest here to work through this,
> > just
> > > >&g=> >t;> sending out the bait...
> > > >>>
> > => >> >>> Obviously this was triggered by my happening into the odb=> >c
> > directory
> > > >>> and bringing up ig=> >noring WINAPI on non-NT386 or prefixing
> > calling
> > => >> >>> conventions with a target.
> > > >>>=> >
> > > >>> This reminds me of an important point here => >however -- nobody
> > else is
> > > >>> goin=> >g to make the mistake of ever having multiple calling
> > > >=> >;>> conventions.
> > > >>> Therefore the general=> >ity of prefixing WINAPI with NT386: is
> > useless.
> > => >> >>> Unless Mac68K support is added.
> > > >>=> >;>
> > > >>> And here is some rationale even. The P=> >C and Mac evolved from
> > "small"
> > > >>>=> > systems, where assembly programming was common, more people
> > => >knew more
> > > >>> lower level details and playing ga=> >mes with calling conventions
> > was
> > > >>&g=> >t; something anyone could do. Most other current systems are
> > => >rooted in C
> > > >>> programming. Working in C, calli=> >ng conventions are generally
> > in a
> > > >>&=> >gt; hidden layer below what anyone thinks about. Therefore, the
> &g=> >t; smaller
> > > >>> number of capable people working => >at that level have the good
> > sense to
> > > >&g=> >t;> only have one calling convention. No more systems will evolve
&g=> >t; > from
> > > >>> "small", at least not without h=> >aving observed this history.
> > > >>> Therefore,
&=> >gt; > > >>> there will no longer be multiple calling convent=> >ions.
> > > >>>
> > > >>> That is=> > my theory at least.
> > > >>>
> > > >&=> >gt;> Oh, Windows does also have __thiscall and __clrcall.
> > => >__thiscall is
> > > >>> only x86
> > > >=> >;> --
> > > >> Dragi=C5=A1a Duri=C4? <dragisha at m3w.=> >org>
> >
> >
> > Connect and share in new way=> >s with Windows Live. Get it now!
>


Shed those ext=> >ra pounds with MSN and The Biggest Loser! >n.com/' target=3D'_new'>Learn more.> >=> >> >--_26c72f2f-07a7-4258-b083-944d52866fbb_-- _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Feb 14 18:31:50 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 14 Feb 2008 12:31:50 -0500 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <20080214091209.cvyfdwqgcok0swoc@mail.elegosoft.com> References: Your message of "Tue, 12 Feb 2008 18:54:50 EST." <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> <47B2E62D.1E75.00D7.1@scires.com> <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> <20080214091209.cvyfdwqgcok0swoc@mail.elegosoft.com> Message-ID: <76456592-EA52-4524-BEE1-02952371DF44@cs.purdue.edu> On Feb 14, 2008, at 3:12 AM, Olaf Wagner wrote: [...many other good comments deleted...] > Multiple inheritance was left out of the language after long > discussions because it was not really understood at that time. > It may be that things have changed in this respect, but I still > don't think it is. Multiple inheritance is fine so long as it encodes only type, but *not* if it encodes representation as well. Witness single inheritance for classes in Java, versus multiple inheritance for interfaces in Java. That seems to be the general consensus these days. >> To a large extent I'm just looking for a small smart group to have >> a friendly intellectual discussion with. >> (and of course, don't mess up their code) > > I think you can have that here. People are willing to discuss and > think things over, but the pace may be somewhat slower than you'd > like :-) > (It's not as bad as with Tolkien's Ents, but still ... slow :) > So, as others have noted, it's great that there is so much activity > recently, but it would still be better if the discussions and comments > were more focused on important language related content about M3. > Nobody has accused you of malicious intentions, and you've always > accepted objections and corrections by others as far as I remember. > > I think what is mostly needed is to slightly adapt your style of > working and discussing things to become better accepted here. > Don't speak out too rash, and don't commit lots of small changes > too soon. Work things out and become more self-confident about > the results of your work. I'm sure you can contribute many interesting > things to M3. Indeed, Jay, we need your Windows energy -- M3 needs to play well on Windows if it is to serve its true purpose: a language that allows applications to be written easily that also run on a multitude of platforms (POSIX, Mach/Darwin/OS X, Windows, ...). Randy is very keen to have a *stable*, easily installed, reliable, version of CM3 running on Windows. I am not sure we have reached that goal yet, even as you have put some great work into achieving that goal. I would very much encourage you to focus your efforts on achieving that kind of stability/reliability/usability for Windows. > PS: Sorry if some of the above reads as if I'm your teacher ;-) We are all padawans Obi-wan. ;-) > -- > Olaf Wagner -- elego Software Solutions GmbH > 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 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > From hendrik at topoi.pooq.com Thu Feb 14 19:08:35 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 14 Feb 2008 13:08:35 -0500 Subject: [M3devel] "target specific pragmas"? In-Reply-To: References: <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> Message-ID: <20080214180835.GA30167@topoi.pooq.com> On Wed, Feb 13, 2008 at 04:28:41AM +0000, Jay wrote: > But wrapping everything in Modula-3 is so tedious... > Oh for all languages to just understand C headers so we can stop rewriting them... > Or some other language, ok...not going to be solved in this forum. As usual, the problem has no solutions, and there are programs that solve it. It can't be solved because a lot of C headers -- especially the standard ones -- use implementation-dependent, and often undocumented, code behind the scenes. This makes it essentially impossible to define what a "C header" is for purposes of implemetation. But it has been solved, for many practical purposes, byt a program that reads C header files and generates the interface code that's needed by other languages to interface with the C code. I'm not sure of that program's name but "swix" comes to mind. Can anyone confirm that? The program possiblyknown as swix has to be configured (in a configuration file) for the particular target language. And you'd best check the output -- it may not automagically handle *everything* C compilers can throw at it. But it is useful. -- hendrik From hendrik at topoi.pooq.com Thu Feb 14 19:34:27 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 14 Feb 2008 13:34:27 -0500 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <5973F6E5-D030-4AF6-A28A-3D5172D130A6@darko.org> References: <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> <47B2E62D.1E75.00D7.1@scires.com> <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> <5973F6E5-D030-4AF6-A28A-3D5172D130A6@darko.org> Message-ID: <20080214183427.GB30167@topoi.pooq.com> On Thu, Feb 14, 2008 at 12:09:40PM +1100, Darko wrote: > M3 is the antithesis in the sense that it takes the opposite approach. > C has few protections, M3 has many. M3 does examine what was wrong > with C and other languages and fix them and it did a good job. The M3 > design team made an explicit goal to look at features from other > languages and take the best. The fact that M3 works so well is the > proof. > > Some of the things you raise, like braces I'm assuming this is the use of '{' and '}' instead of 'BEGIN' and 'END'. Natural languages evolve in the direction of having the mopst-oftern used words be the shortest. This makes it possible to say muc in less space and time. And it makes it easier to get an overview of a program whose physical size is becoming inconvenient. Just haveing the code be readable and seeing enough of its context makes debugging easier. > or stack allocations of > objects are just features of C++ with no justification. Stack allocation of objects is not such a big issue in C++. But it can be a big issue in those programs where split-second real-time interaction is an issue. Yes, I know this is the traditional argument against garbage collection, and that it is usually based on FUD rather than reality. But I have recently been in close contact with a programmer of video games, and for some of them the fraction-of-a-second pauses are a real problem. He really *wants* to write his games in a decent language, and he knows that C is not one. But every time he avoids heap allocation he delays the pause. If he can delay it enough, it's a win. If he can delay it altogether, that's success. > Can you show > that typing less characters is important? You say M3 is less > convenient, but what is less convenient, less typing or less bugs? This is a false dichotomy. You may well be able to reduce typing *and* reduce bugs, just by making code more readable. I doubt that typing "PROC" instead of "PROCEDURE", for example, is likely to introdice bugs. Not typing '{' instead of "BEGIN". Using special characters and lower-case keywords is likely to reduce bugs, because it's less likely that one will be misread for another. > Do > you spend most of your time typing or thinking when you write code? I think before I write code. I don't stop thinking when I start writing code, and I like to record my thoughts as I think. The less typing I need to do, the better I can get visual feedback on my thoughts while thinking. Sometimes the typing gets so tedious I get bored and lose interest. Then extra typing causes extra bugs. > > Should language include every feature anyone can think of? No. > How is > excluding unimportant features 'arbitrary'? Each feature must be > weighed to avoid unnecessary complexity and size, which have a direct > impact on compiler maintainability and language usability. Language > bloat is a real problem. I doubt that anyone understands the full > semantics of C++. > > You say that C has 'won', but in what sense? More people use it? > Language design is not American Idol, it's not a question of who has > the most votes. Enough people use it that it has become a fixture in the programming world. If you want to reuse existing code instead of always writing new, you are pretty much forced into some kind of interfacing between C and a reasonable language. The convenience of this interfacing can well determine whether the reasonable language is feasible for a specific application. -- hendrik From hendrik at topoi.pooq.com Thu Feb 14 19:59:47 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 14 Feb 2008 13:59:47 -0500 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <200802140143.m1E1hDBv062411@camembert.async.caltech.edu> References: <200802140143.m1E1hDBv062411@camembert.async.caltech.edu> Message-ID: <20080214185947.GC30167@topoi.pooq.com> On Wed, Feb 13, 2008 at 05:43:13PM -0800, Mika Nystrom wrote: > Not even C++ has virtual methods in stack-allocated objects does > it? To my knowledge (as former C++ implementor), it does. But such a stack-allocated variable is of statically-known actual type, so the compiler can statically resolve all virtual methods to the actual function implementing them. And it you pass the address of such an object to another function, the other function will handle its virtual methods by the usual virtual function lookup. The only real problem is that it's a bloody disaster if you try to free one of them as if it has been dynamically allocated. But that wouldn't be a problem in a garbage-collected language. > If there's a language that has a lot of arbitrary limitations > in this area it's C++. It's kind of funny: if you know Modula-3, > you start by wondering how C++ implements X, where X is a feature > you would like but M3 lacks, and then you find that while C++ does > indeed implement X', that is, X in a restricted sense, it does > actually not implement X in the full generality you'd like. And > for the same reasons that M3 doesn't touch it in the first place. > Stack-allocated objects are an example of this. If you want > stack-allocated data structures, use a RECORD and a PROCEDURE. That > will give you almost exactly the same thing that a stack-allocated > object gives you in C++! Not quite -- you lose its ability to be considered an inheritor of another class. That's a big loss. > About C++: do you *really* know C++? I was reading Stroustrup's > book a while back and after reading four or five times "if you want > to try this, ask an experienced colleague first" I gave up in disgust > on trying to understand C++. As implementor, I suppose I might be considered an experienced colleague. > There are so many odd little ways you > can go wrong in C++. Yup. That's why I like to avoid using it. > Sometimes assigning an object to a variable > causes your program to break in mysterious and horrible ways, > sometimes... It should never have allowed those potentially type-violating assignments. > C++ programmers also tend to underestimate how effective > garbage collection is in simplifying things. This is different > from saying "garbage collection helps you avoid memory management > errors" (because you say "I am a competent C++ programmer, I never > make memory management errors"). Garbage collection lets you > structure your code in ways that simply is not possible if you have > to worry about which part of it is going to allocate and which part > is going to deallocate memory. There's code I wouldn't venture to write without built-in garbage collection. C++ throws a sop at the programmer in the form of enabling him to core reference-counting in an at least semi-automatic way, but it isn't enough. -- hendrik From rodney.bates at wichita.edu Thu Feb 14 23:56:13 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Thu, 14 Feb 2008 16:56:13 -0600 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> Message-ID: <47B4C70D.4010408@wichita.edu> OK. So would my proposal 1) below suffice, that the alignment rules are a property of a type and thus the same for every variable of that type? More immediately relevant, is it true that nothing that uses LAZYALIGN rules is ever pickled? I believe current pickles will trash things badly if that happens. Fixing this without invalidating existing pickles and/or compiled code looks tricky. If nothing LAZYALIGN is pickled, I am hoping to be able to come up with a scheme that will fix pickles, not require rewriting of any already existing pickle files or recompilation of existing object code, and yet not introduce any new bugs involving old pickles/code. Maybe I should just postpone this one until after LONGINT in pickles is supported (only with STRICTALIGN, as now for other types.) Darko wrote: > That's not quite right. Certain Mac API structures need to be aligned > to Motorola 68K alignment for historical reasons. All other structures > should use normal alignment to be compatible with C and Unix > interfaces. The alignment change was implemented to be supported only > in packed structures as a natural and intuitive way to "force" > alignment. You could view it as a bug fix to overly restrictive > alignment rules in packed structures. > > > On 12/02/2008, at 2:46 PM, Rodney M. Bates wrote: > >> It sounds like all that Mac OS X needs is for _all_ types in an entire >> program to use the liberal packing rules. Have I understood correctly? >> I would have no grief over that. >> >> Darko wrote: >> >>> The liberalised alignment rules are required for the native Mac OS >>> X API and should stay. You cannot use that API without them. I >>> think the pragma is not required and can be removed. I agree with >>> all the points you make. The effect of the modified alignment rules >>> it to allow *packed* structures to have members aligned on byte >>> boundaries. This has the effect of packing the fields in the >>> tightest arrangement allowed by the platform. This might affect >>> performance, but if the user is concerned about this they should >>> specify field bit sizes that deliver improved performance. I don't >>> see a need to specify this on a structure level, for the reasons >>> you give and because the difference isn't significant enough in the >>> case of packed structures and their physical layout and >>> restrictions are platform dependent anyway. >>> I might also add that the alignment code is currently broken on >>> I386_DARWIN. >>> - Darko >>> On 11/02/2008, at 8:55 AM, Rodney M. Bates wrote: >>> >>>> Does anybody know about the status of pragma <*LAZYALIGN*>? Is it >>>> being used anywhere? >>>> >>>> It is not documented in pragmas.html. The compiler front end appears >>>> to accept it. (In fact, Decls.m3 contains constants that suggest >>>> limitations on what declarations the pragma can appear on, but these >>>> are not actually enforced.) It liberalizes the alignment rules, >>>> generally allowing scalars to start on any byte boundary. >>>> >>>> Pickles have to be able to reconstruct the layout of types as the >>>> compiler would have done it for a machine (on which a now-being-read >>>> pickle was written) with different word size and alignment properties. >>>> Currently, pickles are completely unaware of lazy alignment. It >>>> would have to be encoded in type descriptions generated by the >>>> compiler >>>> using TipeDesc and read by pickles using RTTipe. >>>> >>>> Most troubling to me is what looks like a linguistic Pandora's box. >>>> The pragma can be associated with any constant, variable, or type >>>> _declaration_ (not type definition), with the result that different >>>> values of the same type can actually be different in their alignment >>>> rules and thus their layout. Similarly for different identifiers >>>> equated to the same type. Although the effects of this could possibly >>>> be hidden from the programmer in purely safe code, not so with unsafe >>>> code. I haven't thoroughly thought this through, but seems to me to >>>> really fly in the face of the whole typing philosophy of the language. >>>> >>>> For example, if pickles were to read in an object value, and there >>>> were >1 variants of the object's type in the reading program, >>>> differing >>>> only in the alignment rules, how would it decide which one to build? >>>> In fact, ignoring pickles altogether and just looking at a single >>>> program, >>>> if the object's type doesn't actually uniquely give its memory layout, >>>> how can it be accessed correctly? >>>> >>>> Additionally, a quick look at the compiler suggests it won't generate >>>> correct code for whole record assignment when the LHS and RHS are the >>>> same type but have different alignment characteristics. >>>> >>>> The more I think about it, it seems the only workable >>>> possibilities are: >>>> >>>> 1) Require the pragma to be associated only with a type >>>> _definition_ not a >>>> declaration (e.g., allow RECORD <*LAZYALIGN*> ... END) and make >>>> this a >>>> property of the type that propagates to all names for the type and >>>> all variables, constants, etc. Also, this would make this property >>>> a part of the type signature that pickles uses when reading, -OR- >>>> >>>> 2) Forget it altogether. >>>> >>>> What do people think? >>>> -- >>>> ------------------------------------------------------------- >>>> Rodney M. Bates, retired assistant professor >>>> Dept. of Computer Science, Wichita State University >>>> Wichita, KS 67260-0083 >>>> 316-978-3922 >>>> rodney.bates at wichita.edu >> >> >> -- >> ------------------------------------------------------------- >> Rodney M. Bates, retired assistant professor >> Dept. of Computer Science, Wichita State University >> Wichita, KS 67260-0083 >> 316-978-3922 >> rodney.bates at wichita.edu > > > -- ------------------------------------------------------------- Rodney M. Bates, retired assistant professor Dept. of Computer Science, Wichita State University Wichita, KS 67260-0083 316-978-3922 rodney.bates at wichita.edu From rodney.bates at wichita.edu Fri Feb 15 00:22:06 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Thu, 14 Feb 2008 17:22:06 -0600 Subject: [M3devel] introducing VAR in more places? In-Reply-To: References: "Your message of Tue, 12 Feb 2008 08:23:26 EST." <20080212132326.GA22149@topoi.pooq.com> <200802121341.m1CDfVoZ091241@camembert.async.caltech.edu> Message-ID: <47B4CD1E.100@wichita.edu> Detecting use of uninitialized variables statically is undecidable, although a good many specific (and common) cases can be caught or ruled out. Detecting at runtime requires a spare bit pattern that normal values of the type don't use, or an extra bit or something--not too convenient for some types. I have always been a bit ambivalent about Modula-3's rule that every variable is initialized to some unspecified bit pattern that is a valid value of the type. I understand this is the minimum requirement to ensure type safety. But for the same price already paid to do this (runtime initialization code), we could have default initialization to a language-specified value, which would make for more consistent behavior. I have been gradually expanding the habit of writing an explicit initial value on just about everything, whether bug-free code would need it or not, just for the reduced risk of unreproduceable bugs. Of course, if the type's representation uses every bit pattern, then the rule we have has no cost, whereas a language-specified initial value would. Jay wrote: ... > Java and I presume C# have a nice feature here too where they require > the compiler to error for use of uninitialized variables, though I > suspect the specced algorithm misses some things, like: > > if (...) > initialize x > > common code > > if (same thing) > use x <== possible use of uninitialize x, not > > At least I've seen other tools (not Java/C# compilers, I don't use > those) get confused by this.. >-- ------------------------------------------------------------- Rodney M. Bates, retired assistant professor Dept. of Computer Science, Wichita State University Wichita, KS 67260-0083 316-978-3922 rodney.bates at wichita.edu From hosking at cs.purdue.edu Fri Feb 15 00:05:11 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 14 Feb 2008 18:05:11 -0500 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <20080214183427.GB30167@topoi.pooq.com> References: <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> <47B2E62D.1E75.00D7.1@scires.com> <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> <5973F6E5-D030-4AF6-A28A-3D5172D130A6@darko.org> <20080214183427.GB30167@topoi.pooq.com> Message-ID: I don't want to add fuel to the fire, but .... On Feb 14, 2008, at 1:34 PM, hendrik at topoi.pooq.com wrote: > On Thu, Feb 14, 2008 at 12:09:40PM +1100, Darko wrote: >> M3 is the antithesis in the sense that it takes the opposite >> approach. >> C has few protections, M3 has many. M3 does examine what was wrong >> with C and other languages and fix them and it did a good job. The M3 >> design team made an explicit goal to look at features from other >> languages and take the best. The fact that M3 works so well is the >> proof. >> >> Some of the things you raise, like braces > > I'm assuming this is the use of '{' and '}' instead of 'BEGIN' and > 'END'. > > Natural languages evolve in the direction of having the mopst-oftern > used words be the shortest. This makes it possible to say muc in less > space and time. And it makes it easier to get an overview of a > program whose physical size is becoming inconvenient. Just haveing > the code be readable and seeing enough of its context makes > debugging easier. > >> or stack allocations of >> objects are just features of C++ with no justification. > > Stack allocation of objects is not such a big issue in C++. But it > can > be a big issue in those programs where split-second real-time > interaction is an issue. Yes, I know this is the traditional argument > against garbage collection, and that it is usually based on FUD rather > than reality. But I have recently been in close contact with a > programmer of video games, and for some of them the fraction-of-a- > second > pauses are a real problem. He really *wants* to write his games in a > decent language, and he knows that C is not one. > > But every time he avoids heap allocation he delays the pause. If > he can delay it enough, it's a win. If he can delay it altogether, > that's success. There are true "real-time" garbage collectors in development and deployment now that avoid applications from seeing pauses. Modula-3 is getting better in this respect, but it is still not quite there. But, fortunately, Modula-3 provides UNTRACED objects/ references which *never* themselves cause GC. In fact, for the current CM3 implementation it would be possible to have a real-time thread run and manipulate only UNTRACED references and never ever see a GC pause -- it would keep running even while other threads are caught up by GC! >> Can you show >> that typing less characters is important? You say M3 is less >> convenient, but what is less convenient, less typing or less bugs? > > This is a false dichotomy. You may well be able to reduce typing > *and* reduce bugs, just by making code more readable. I don't find M3 to be unreadable at all. In fact, I find it to be very readable. > I doubt that typing "PROC" instead of "PROCEDURE", for example, is > likely to introdice bugs. Not typing '{' instead of "BEGIN". Using > special characters and lower-case keywords is likely to reduce bugs, > because it's less likely that one will be misread for another. > >> Do >> you spend most of your time typing or thinking when you write code? > > I think before I write code. I don't stop thinking when I start > writing code, and I like to record my thoughts as I think. The less > typing I need to do, the better I can get visual feedback on my > thoughts while thinking. Sometimes the typing gets so tedious I get > bored and lose interest. Then extra typing causes extra bugs. Who types? I use an editor that completes and indents Modula-3 code with exactly the same number of keystrokes as I use when programming in C. >> >> Should language include every feature anyone can think of? > > No. > >> How is >> excluding unimportant features 'arbitrary'? Each feature must be >> weighed to avoid unnecessary complexity and size, which have a direct >> impact on compiler maintainability and language usability. Language >> bloat is a real problem. I doubt that anyone understands the full >> semantics of C++. >> >> You say that C has 'won', but in what sense? More people use it? >> Language design is not American Idol, it's not a question of who has >> the most votes. > > Enough people use it that it has become a fixture in the programming > world. If you want to reuse existing code instead of always writing > new, you are pretty much forced into some kind of interfacing > between C > and a reasonable language. The convenience of this interfacing can > well > determine whether the reasonable language is feasible for a specific > application. And CM3 does this very well -- that does not mean we should permeate the Modula-3 space with C'isms. > > -- hendrik From hosking at cs.purdue.edu Fri Feb 15 00:06:48 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 14 Feb 2008 18:06:48 -0500 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <20080214185947.GC30167@topoi.pooq.com> References: <200802140143.m1E1hDBv062411@camembert.async.caltech.edu> <20080214185947.GC30167@topoi.pooq.com> Message-ID: <3D050900-727C-4371-94C0-7357D8958194@cs.purdue.edu> PS The C++ standard committee is actively developing the next C++ standard to include garbage collection as part of the spec. The worm has turned... On Feb 14, 2008, at 1:59 PM, hendrik at topoi.pooq.com wrote: > On Wed, Feb 13, 2008 at 05:43:13PM -0800, Mika Nystrom wrote: > >> Not even C++ has virtual methods in stack-allocated objects does >> it? > > To my knowledge (as former C++ implementor), it does. But such a > stack-allocated variable is of statically-known actual type, so the > compiler can statically resolve all virtual methods to the actual > function implementing them. And it you pass the address of such an > object to another function, the other function will handle its virtual > methods by the usual virtual function lookup. > > The only real problem is that it's a bloody disaster if you try to > free one of them as if it has been dynamically allocated. But that > wouldn't be a problem in a garbage-collected language. > >> If there's a language that has a lot of arbitrary limitations >> in this area it's C++. It's kind of funny: if you know Modula-3, >> you start by wondering how C++ implements X, where X is a feature >> you would like but M3 lacks, and then you find that while C++ does >> indeed implement X', that is, X in a restricted sense, it does >> actually not implement X in the full generality you'd like. And >> for the same reasons that M3 doesn't touch it in the first place. >> Stack-allocated objects are an example of this. If you want >> stack-allocated data structures, use a RECORD and a PROCEDURE. That >> will give you almost exactly the same thing that a stack-allocated >> object gives you in C++! > > Not quite -- you lose its ability to be considered an inheritor of > another class. That's a big loss. > >> About C++: do you *really* know C++? I was reading Stroustrup's >> book a while back and after reading four or five times "if you want >> to try this, ask an experienced colleague first" I gave up in disgust >> on trying to understand C++. > > As implementor, I suppose I might be considered an experienced > colleague. > >> There are so many odd little ways you >> can go wrong in C++. > > Yup. That's why I like to avoid using it. > >> Sometimes assigning an object to a variable >> causes your program to break in mysterious and horrible ways, >> sometimes... > > It should never have allowed those potentially type-violating > assignments. > >> C++ programmers also tend to underestimate how effective >> garbage collection is in simplifying things. This is different >> from saying "garbage collection helps you avoid memory management >> errors" (because you say "I am a competent C++ programmer, I never >> make memory management errors"). Garbage collection lets you >> structure your code in ways that simply is not possible if you have >> to worry about which part of it is going to allocate and which part >> is going to deallocate memory. > > There's code I wouldn't venture to write without built-in garbage > collection. C++ throws a sop at the programmer in the form of > enabling > him to core reference-counting in an at least semi-automatic way, > but it > isn't enough. > > -- hendrik From rodney.bates at wichita.edu Fri Feb 15 00:32:57 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Thu, 14 Feb 2008 17:32:57 -0600 Subject: [M3devel] "target specific pragmas"? In-Reply-To: References: "Your message of Tue, 12 Feb 2008 18:54:50 EST." <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> <47B2E62D.1E75.00D7.1@scires.com> <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> Message-ID: <47B4CFA9.2060400@wichita.edu> Whether you agree with their conclusions or not, the designers of Modula-3 and predecessors Modula-2+ and Modula-2 spent a great deal of effort doing just that. Despite having a few complaints and ambivalences here and there, I for one, think the final result is unmatched for the ways it made all the very difficult tradeoffs among highly contradictory desiderata. Jay wrote: .... > You can't just be the antithesis of C. You have to decide what it is > about C that is wrong and fix it or do it over. > And then of course, agreement on what is wrong. .... > If you start over completely from scratch, you should still look at what > is out there. -- ------------------------------------------------------------- Rodney M. Bates, retired assistant professor Dept. of Computer Science, Wichita State University Wichita, KS 67260-0083 316-978-3922 rodney.bates at wichita.edu From hosking at cs.purdue.edu Fri Feb 15 00:18:32 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 14 Feb 2008 18:18:32 -0500 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <47B4C70D.4010408@wichita.edu> References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> <47B4C70D.4010408@wichita.edu> Message-ID: <7323567C-7632-4040-B858-47B8124759DC@cs.purdue.edu> Why is LONGINT for pickles not yet supported? On Feb 14, 2008, at 5:56 PM, Rodney M. Bates wrote: > OK. So would my proposal 1) below suffice, that the alignment > rules are a > property of a type and thus the same for every variable of that type? > > More immediately relevant, is it true that nothing that uses > LAZYALIGN rules > is ever pickled? I believe current pickles will trash things badly > if that > happens. Fixing this without invalidating existing pickles and/or > compiled > code looks tricky. > > If nothing LAZYALIGN is pickled, I am hoping to be able to come up > with > a scheme that will fix pickles, not require rewriting of any > already existing > pickle files or recompilation of existing object code, and yet not > introduce > any new bugs involving old pickles/code. > > Maybe I should just postpone this one until after LONGINT in > pickles is supported > (only with STRICTALIGN, as now for other types.) > > Darko wrote: >> That's not quite right. Certain Mac API structures need to be >> aligned to Motorola 68K alignment for historical reasons. All >> other structures should use normal alignment to be compatible >> with C and Unix interfaces. The alignment change was implemented >> to be supported only in packed structures as a natural and >> intuitive way to "force" alignment. You could view it as a bug >> fix to overly restrictive alignment rules in packed structures. >> On 12/02/2008, at 2:46 PM, Rodney M. Bates wrote: >>> It sounds like all that Mac OS X needs is for _all_ types in an >>> entire >>> program to use the liberal packing rules. Have I understood >>> correctly? >>> I would have no grief over that. >>> >>> Darko wrote: >>> >>>> The liberalised alignment rules are required for the native Mac >>>> OS X API and should stay. You cannot use that API without >>>> them. I think the pragma is not required and can be removed. I >>>> agree with all the points you make. The effect of the modified >>>> alignment rules it to allow *packed* structures to have >>>> members aligned on byte boundaries. This has the effect of >>>> packing the fields in the tightest arrangement allowed by the >>>> platform. This might affect performance, but if the user is >>>> concerned about this they should specify field bit sizes that >>>> deliver improved performance. I don't see a need to specify >>>> this on a structure level, for the reasons you give and >>>> because the difference isn't significant enough in the case of >>>> packed structures and their physical layout and restrictions >>>> are platform dependent anyway. >>>> I might also add that the alignment code is currently broken >>>> on I386_DARWIN. >>>> - Darko >>>> On 11/02/2008, at 8:55 AM, Rodney M. Bates wrote: >>>> >>>>> Does anybody know about the status of pragma <*LAZYALIGN*>? Is it >>>>> being used anywhere? >>>>> >>>>> It is not documented in pragmas.html. The compiler front end >>>>> appears >>>>> to accept it. (In fact, Decls.m3 contains constants that suggest >>>>> limitations on what declarations the pragma can appear on, but >>>>> these >>>>> are not actually enforced.) It liberalizes the alignment rules, >>>>> generally allowing scalars to start on any byte boundary. >>>>> >>>>> Pickles have to be able to reconstruct the layout of types as the >>>>> compiler would have done it for a machine (on which a now-being- >>>>> read >>>>> pickle was written) with different word size and alignment >>>>> properties. >>>>> Currently, pickles are completely unaware of lazy alignment. It >>>>> would have to be encoded in type descriptions generated by >>>>> the compiler >>>>> using TipeDesc and read by pickles using RTTipe. >>>>> >>>>> Most troubling to me is what looks like a linguistic Pandora's >>>>> box. >>>>> The pragma can be associated with any constant, variable, or type >>>>> _declaration_ (not type definition), with the result that >>>>> different >>>>> values of the same type can actually be different in their >>>>> alignment >>>>> rules and thus their layout. Similarly for different identifiers >>>>> equated to the same type. Although the effects of this could >>>>> possibly >>>>> be hidden from the programmer in purely safe code, not so with >>>>> unsafe >>>>> code. I haven't thoroughly thought this through, but seems to >>>>> me to >>>>> really fly in the face of the whole typing philosophy of the >>>>> language. >>>>> >>>>> For example, if pickles were to read in an object value, and there >>>>> were >1 variants of the object's type in the reading program, >>>>> differing >>>>> only in the alignment rules, how would it decide which one to >>>>> build? >>>>> In fact, ignoring pickles altogether and just looking at a >>>>> single program, >>>>> if the object's type doesn't actually uniquely give its memory >>>>> layout, >>>>> how can it be accessed correctly? >>>>> >>>>> Additionally, a quick look at the compiler suggests it won't >>>>> generate >>>>> correct code for whole record assignment when the LHS and RHS >>>>> are the >>>>> same type but have different alignment characteristics. >>>>> >>>>> The more I think about it, it seems the only workable >>>>> possibilities are: >>>>> >>>>> 1) Require the pragma to be associated only with a type >>>>> _definition_ not a >>>>> declaration (e.g., allow RECORD <*LAZYALIGN*> ... END) and >>>>> make this a >>>>> property of the type that propagates to all names for the type >>>>> and >>>>> all variables, constants, etc. Also, this would make this >>>>> property >>>>> a part of the type signature that pickles uses when reading, -OR- >>>>> >>>>> 2) Forget it altogether. >>>>> >>>>> What do people think? >>>>> -- >>>>> ------------------------------------------------------------- >>>>> Rodney M. Bates, retired assistant professor >>>>> Dept. of Computer Science, Wichita State University >>>>> Wichita, KS 67260-0083 >>>>> 316-978-3922 >>>>> rodney.bates at wichita.edu >>> >>> >>> -- >>> ------------------------------------------------------------- >>> Rodney M. Bates, retired assistant professor >>> Dept. of Computer Science, Wichita State University >>> Wichita, KS 67260-0083 >>> 316-978-3922 >>> rodney.bates at wichita.edu > > -- > ------------------------------------------------------------- > Rodney M. Bates, retired assistant professor > Dept. of Computer Science, Wichita State University > Wichita, KS 67260-0083 > 316-978-3922 > rodney.bates at wichita.edu From darko at darko.org Fri Feb 15 00:26:23 2008 From: darko at darko.org (Darko) Date: Fri, 15 Feb 2008 10:26:23 +1100 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <47B4C70D.4010408@wichita.edu> References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> <47B4C70D.4010408@wichita.edu> Message-ID: <94EB43F9-8E9E-4F6C-95BD-FB9872FD01A2@darko.org> The alignment rules are correctly associated with a type. I think the pragma can be removed. There are no pickles anywhere of these types. On 15/02/2008, at 9:56 AM, Rodney M. Bates wrote: > OK. So would my proposal 1) below suffice, that the alignment rules > are a > property of a type and thus the same for every variable of that type? > > More immediately relevant, is it true that nothing that uses > LAZYALIGN rules > is ever pickled? I believe current pickles will trash things badly > if that > happens. Fixing this without invalidating existing pickles and/or > compiled > code looks tricky. > > If nothing LAZYALIGN is pickled, I am hoping to be able to come up > with > a scheme that will fix pickles, not require rewriting of any already > existing > pickle files or recompilation of existing object code, and yet not > introduce > any new bugs involving old pickles/code. > > Maybe I should just postpone this one until after LONGINT in pickles > is supported > (only with STRICTALIGN, as now for other types.) > > Darko wrote: >> That's not quite right. Certain Mac API structures need to be >> aligned to Motorola 68K alignment for historical reasons. All >> other structures should use normal alignment to be compatible with >> C and Unix interfaces. The alignment change was implemented to be >> supported only in packed structures as a natural and intuitive way >> to "force" alignment. You could view it as a bug fix to overly >> restrictive alignment rules in packed structures. >> On 12/02/2008, at 2:46 PM, Rodney M. Bates wrote: >>> It sounds like all that Mac OS X needs is for _all_ types in an >>> entire >>> program to use the liberal packing rules. Have I understood >>> correctly? >>> I would have no grief over that. >>> >>> Darko wrote: >>> >>>> The liberalised alignment rules are required for the native Mac >>>> OS X API and should stay. You cannot use that API without them. >>>> I think the pragma is not required and can be removed. I agree >>>> with all the points you make. The effect of the modified >>>> alignment rules it to allow *packed* structures to have members >>>> aligned on byte boundaries. This has the effect of packing the >>>> fields in the tightest arrangement allowed by the platform. >>>> This might affect performance, but if the user is concerned >>>> about this they should specify field bit sizes that deliver >>>> improved performance. I don't see a need to specify this on a >>>> structure level, for the reasons you give and because the >>>> difference isn't significant enough in the case of packed >>>> structures and their physical layout and restrictions are >>>> platform dependent anyway. >>>> I might also add that the alignment code is currently broken on >>>> I386_DARWIN. >>>> - Darko >>>> On 11/02/2008, at 8:55 AM, Rodney M. Bates wrote: >>>> >>>>> Does anybody know about the status of pragma <*LAZYALIGN*>? Is it >>>>> being used anywhere? >>>>> >>>>> It is not documented in pragmas.html. The compiler front end >>>>> appears >>>>> to accept it. (In fact, Decls.m3 contains constants that suggest >>>>> limitations on what declarations the pragma can appear on, but >>>>> these >>>>> are not actually enforced.) It liberalizes the alignment rules, >>>>> generally allowing scalars to start on any byte boundary. >>>>> >>>>> Pickles have to be able to reconstruct the layout of types as the >>>>> compiler would have done it for a machine (on which a now-being- >>>>> read >>>>> pickle was written) with different word size and alignment >>>>> properties. >>>>> Currently, pickles are completely unaware of lazy alignment. It >>>>> would have to be encoded in type descriptions generated by the >>>>> compiler >>>>> using TipeDesc and read by pickles using RTTipe. >>>>> >>>>> Most troubling to me is what looks like a linguistic Pandora's >>>>> box. >>>>> The pragma can be associated with any constant, variable, or type >>>>> _declaration_ (not type definition), with the result that >>>>> different >>>>> values of the same type can actually be different in their >>>>> alignment >>>>> rules and thus their layout. Similarly for different identifiers >>>>> equated to the same type. Although the effects of this could >>>>> possibly >>>>> be hidden from the programmer in purely safe code, not so with >>>>> unsafe >>>>> code. I haven't thoroughly thought this through, but seems to >>>>> me to >>>>> really fly in the face of the whole typing philosophy of the >>>>> language. >>>>> >>>>> For example, if pickles were to read in an object value, and there >>>>> were >1 variants of the object's type in the reading program, >>>>> differing >>>>> only in the alignment rules, how would it decide which one to >>>>> build? >>>>> In fact, ignoring pickles altogether and just looking at a >>>>> single program, >>>>> if the object's type doesn't actually uniquely give its memory >>>>> layout, >>>>> how can it be accessed correctly? >>>>> >>>>> Additionally, a quick look at the compiler suggests it won't >>>>> generate >>>>> correct code for whole record assignment when the LHS and RHS >>>>> are the >>>>> same type but have different alignment characteristics. >>>>> >>>>> The more I think about it, it seems the only workable >>>>> possibilities are: >>>>> >>>>> 1) Require the pragma to be associated only with a type >>>>> _definition_ not a >>>>> declaration (e.g., allow RECORD <*LAZYALIGN*> ... END) and >>>>> make this a >>>>> property of the type that propagates to all names for the type and >>>>> all variables, constants, etc. Also, this would make this >>>>> property >>>>> a part of the type signature that pickles uses when reading, -OR- >>>>> >>>>> 2) Forget it altogether. >>>>> >>>>> What do people think? >>>>> -- >>>>> ------------------------------------------------------------- >>>>> Rodney M. Bates, retired assistant professor >>>>> Dept. of Computer Science, Wichita State University >>>>> Wichita, KS 67260-0083 >>>>> 316-978-3922 >>>>> rodney.bates at wichita.edu >>> >>> >>> -- >>> ------------------------------------------------------------- >>> Rodney M. Bates, retired assistant professor >>> Dept. of Computer Science, Wichita State University >>> Wichita, KS 67260-0083 >>> 316-978-3922 >>> rodney.bates at wichita.edu > > -- > ------------------------------------------------------------- > Rodney M. Bates, retired assistant professor > Dept. of Computer Science, Wichita State University > Wichita, KS 67260-0083 > 316-978-3922 > rodney.bates at wichita.edu From jayk123 at hotmail.com Fri Feb 15 00:31:03 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 14 Feb 2008 23:31:03 +0000 Subject: [M3devel] "target specific pragmas"? In-Reply-To: References: <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> <47B2E62D.1E75.00D7.1@scires.com> <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> <5973F6E5-D030-4AF6-A28A-3D5172D130A6@darko.org> <20080214183427.GB30167@topoi.pooq.com> Message-ID: > I don't want to add fuel to the fire, but .... > there. But, fortunately, Modula-3 provides UNTRACED objects/ > references which *never* themselves cause GC. In fact, for the Right, "optional safety" is a nice feature of Modula-3. C# has optional safety but I think maybe in fewer ways -- optional integer overflow checks, not sure what else. Otherwise optional safety seems to be pretty rare. This does remind us -- I don't think Modula-3's integer overflow rules are as obviously safe as they could be. I think it's a target-varying thing and most targets don't check. Integer overflow has started to become a concern like buffer overflow..so probably something should be done. HOWEVER something pervasive and automatic may be too risky in terms of compatibilty with existing code. I mean Modula-3. In C and C++, for "useful suggestions", there have been two obvious patterns: Functions to add, subtract, multiple integers, that can fail. Tedious but explicit. Probably good candidates for building into the language/compiler like Word, even if they are explicit functions. Templatized types with all the operators overloaded. Also a good candidate for inclusion in the language/compiler. What to call? There is "SafeInt". I think Modula-3 has more chance of getting away with just making it so for INTEGER but I would have to read up more. In C as I understand: The encoding and overflow behavior of signed integers is undefined/implemention-defined. You could have signed magnitude, one's complement, two's complement, or anything you want. You can have any behavior for integer overflow. Some sort of "wrap around", abort(), etc. For unsigned integers, overflow is well defined, never an error, and "wraps around". In practise, signed integers are always two's complement, overflow is never an error, and "wraps around", the same or nearly the same as unsigned integers. "Wrap around" being better defined as results are taken modulo 2^(bitsize(the type)). Signed and unsigned operations often generate identical code, but not always. For example add and subtract are often identical. Comparison can be identical and then use a different conditional branch. I'm just being lazy here, if I really dig into it I could remember/re-derive the rules, though I don't know the instructions sets. (on 6502, the compare instruction only works for unsigned, you have to subtract and destroy a register, of which there are only three, though another point of view considers memory, or certain memory, as registers, yes I know that sounds plain wrong, but when all you have is a,x,y and single byte addresses have more features (addressing modes) than larger addresses...). - Jay _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri Feb 15 00:35:52 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 14 Feb 2008 23:35:52 +0000 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <47B4CFA9.2060400@wichita.edu> References: "Your message of Tue, 12 Feb 2008 18:54:50 EST." <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> <47B2E62D.1E75.00D7.1@scires.com> <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> <47B4CFA9.2060400@wichita.edu> Message-ID: > From: rodney.bates at wichita.edu> > Whether you agree with their conclusions or not, the designers of Modula-3> and predecessors Modula-2+ and Modula-2 spent a great deal of effort doing The end of Nelson's book is VERY interesting in this regard, "How Modula-3 got its spots". I had previously never thought about type name vs. structural equivalence, or even knew to ask about them. - Noam :) _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From darko at darko.org Fri Feb 15 00:47:01 2008 From: darko at darko.org (Darko) Date: Fri, 15 Feb 2008 10:47:01 +1100 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <20080214183427.GB30167@topoi.pooq.com> References: <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> <47B2E62D.1E75.00D7.1@scires.com> <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> <5973F6E5-D030-4AF6-A28A-3D5172D130A6@darko.org> <20080214183427.GB30167@topoi.pooq.com> Message-ID: <32568FDB-AE71-4E19-B6FF-ED2D5FB098DE@darko.org> I don't really question the usefulness of any given feature, just the incremental cost of adding any given feature. One of M3's great strengths is that it is low on features, but the ones it has are powerful and well chosen. The comparison I meant in the typing discussion was between C and M3, not the length of symbols. C is a bit obsessive about source size, which was meaningful back in the day, but today is totally irrelevant. Even if you don't use macros on your editor, the amount of time spent staring and your code is much greater than the time you spend typing it. You could argue that BEGIN/END is easier to read than {/} but I think the more important point is that this issue is not a significant one. On 15/02/2008, at 5:34 AM, hendrik at topoi.pooq.com wrote: > On Thu, Feb 14, 2008 at 12:09:40PM +1100, Darko wrote: >> M3 is the antithesis in the sense that it takes the opposite >> approach. >> C has few protections, M3 has many. M3 does examine what was wrong >> with C and other languages and fix them and it did a good job. The M3 >> design team made an explicit goal to look at features from other >> languages and take the best. The fact that M3 works so well is the >> proof. >> >> Some of the things you raise, like braces > > I'm assuming this is the use of '{' and '}' instead of 'BEGIN' and > 'END'. > > Natural languages evolve in the direction of having the mopst-oftern > used words be the shortest. This makes it possible to say muc in less > space and time. And it makes it easier to get an overview of a > program whose physical size is becoming inconvenient. Just haveing > the code be readable and seeing enough of its context makes > debugging easier. > >> or stack allocations of >> objects are just features of C++ with no justification. > > Stack allocation of objects is not such a big issue in C++. But it > can > be a big issue in those programs where split-second real-time > interaction is an issue. Yes, I know this is the traditional argument > against garbage collection, and that it is usually based on FUD rather > than reality. But I have recently been in close contact with a > programmer of video games, and for some of them the fraction-of-a- > second > pauses are a real problem. He really *wants* to write his games in a > decent language, and he knows that C is not one. > > But every time he avoids heap allocation he delays the pause. If > he can delay it enough, it's a win. If he can delay it altogether, > that's success. > >> Can you show >> that typing less characters is important? You say M3 is less >> convenient, but what is less convenient, less typing or less bugs? > > This is a false dichotomy. You may well be able to reduce typing > *and* reduce bugs, just by making code more readable. > > I doubt that typing "PROC" instead of "PROCEDURE", for example, is > likely to introdice bugs. Not typing '{' instead of "BEGIN". Using > special characters and lower-case keywords is likely to reduce bugs, > because it's less likely that one will be misread for another. > >> Do >> you spend most of your time typing or thinking when you write code? > > I think before I write code. I don't stop thinking when I start > writing code, and I like to record my thoughts as I think. The less > typing I need to do, the better I can get visual feedback on my > thoughts while thinking. Sometimes the typing gets so tedious I get > bored and lose interest. Then extra typing causes extra bugs. >> >> Should language include every feature anyone can think of? > > No. > >> How is >> excluding unimportant features 'arbitrary'? Each feature must be >> weighed to avoid unnecessary complexity and size, which have a direct >> impact on compiler maintainability and language usability. Language >> bloat is a real problem. I doubt that anyone understands the full >> semantics of C++. >> >> You say that C has 'won', but in what sense? More people use it? >> Language design is not American Idol, it's not a question of who has >> the most votes. > > Enough people use it that it has become a fixture in the programming > world. If you want to reuse existing code instead of always writing > new, you are pretty much forced into some kind of interfacing > between C > and a reasonable language. The convenience of this interfacing can > well > determine whether the reasonable language is feasible for a specific > application. > > -- hendrik From hendrik at topoi.pooq.com Fri Feb 15 15:18:19 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 15 Feb 2008 09:18:19 -0500 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <32568FDB-AE71-4E19-B6FF-ED2D5FB098DE@darko.org> References: <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> <47B2E62D.1E75.00D7.1@scires.com> <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> <5973F6E5-D030-4AF6-A28A-3D5172D130A6@darko.org> <20080214183427.GB30167@topoi.pooq.com> <32568FDB-AE71-4E19-B6FF-ED2D5FB098DE@darko.org> Message-ID: <20080215141819.GB3639@topoi.pooq.com> On Fri, Feb 15, 2008 at 10:47:01AM +1100, Darko wrote: > I don't really question the usefulness of any given feature, just the > incremental cost of adding any given feature. One of M3's great > strengths is that it is low on features, but the ones it has are > powerful and well chosen. > > The comparison I meant in the typing discussion was between C and M3, > not the length of symbols. C is a bit obsessive about source size, > which was meaningful back in the day, but today is totally irrelevant. > Even if you don't use macros on your editor, the amount of time spent > staring and your code is much greater than the time you spend typing > it. You could argue that BEGIN/END is easier to read than {/} If I had to argue, I'd argue the reverse. In fact, if it weren't for disputes about the number of spaces that are equivalent to a tab and such, I'd argue for using indentation and dispensing with BEGIN/END/{/} altogether. Somewhere I have a C++ program with all the braces left out. If you manage to supply the right braces and get it compiled, you end up with a program that will do the job of supplying the right braces. I could post it here if anyone in interested in such a curiosity. There's one language I've seen that goes in the opposite direction. Every END is followed by an arbitrary amount of text from the start of the construct it closes and a semicolon. This a WHILE loop starting WHILE toronto == montreal could end with END WHILE toronto ==; making visual matchin unambiguous. I've got friends that complain about haveing to type the name if a procerure twice in its declaration -- once at the start and once at the end. They say they keep fprgetting to modify both. But I welcome this as a useful check on long-range bracket matching. Forcing it for short-range marching, though, is clutter. -- hendrik From hendrik at topoi.pooq.com Fri Feb 15 15:20:42 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 15 Feb 2008 09:20:42 -0500 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <3D050900-727C-4371-94C0-7357D8958194@cs.purdue.edu> References: <200802140143.m1E1hDBv062411@camembert.async.caltech.edu> <20080214185947.GC30167@topoi.pooq.com> <3D050900-727C-4371-94C0-7357D8958194@cs.purdue.edu> Message-ID: <20080215142042.GC3639@topoi.pooq.com> On Thu, Feb 14, 2008 at 06:06:48PM -0500, Tony Hosking wrote: > PS The C++ standard committee is actively developing the next C++ > standard to include garbage collection as part of the spec. What are they ever going to do with those autodecremented pointers into the middle of arrays? -- hendrik From jayk123 at hotmail.com Fri Feb 15 16:10:16 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 15 Feb 2008 15:10:16 +0000 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <20080215141819.GB3639@topoi.pooq.com> References: <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> <47B2E62D.1E75.00D7.1@scires.com> <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> <5973F6E5-D030-4AF6-A28A-3D5172D130A6@darko.org> <20080214183427.GB30167@topoi.pooq.com> <32568FDB-AE71-4E19-B6FF-ED2D5FB098DE@darko.org> <20080215141819.GB3639@topoi.pooq.com> Message-ID: Having written a bit of Python..really just a bit..you are all privy to ALL of the Python I have ever written...I'll bite. It's fairly obvious once you write a bit of Python what goes on here. First, we all know that we all strive to indent things "correctly". Now, "correctly" can vary somewhat, but the intent is universal. Deeper lexical nesting goes with increased indentation. You can pick the indent size, spaces vs. tabs, where the braces/begin/end go, but it's still the same intent. Now, when paired with begin/end or braces, you end up with a large duplication of information. The one the compiler uses only and the ones human use more. You get to keep them in sync. Your editor might help a lot. What Python does is merely throw out half the data, and require some consistency on your part for what in other languages the compiler ignores. I don't know the exact rules, but they are probably easy to think of. That is, it could easily allow either spaces or tabs. This approach is not bad. But I have two problems: 1) again, my editor 2) it's a little wierd and hard to see when you have a whole lot of closes in a row if print if print if print nothing here vs. either C or Modula-3. Perhaps a better approach is to require "end" and require consistent indentation. Python also can't cope with an empty statement because of this plus its lack of semicolons. You have to say "pass". That's a bit of an indictment. As to tabs, the answer is very easy. Never ever use them. Lots of folks use 4 space tabs, lots of folks use 8 space tabs. I used to be a 4 space tab guy, but I gave up tabs a few years ago. The Cygwin code uses 8 space tabs and is therefore unreadable to me. (I could change my editor setting, and since the 4 space tabs are pretty rare now, ok.) To those who suggested emacs for convenient Modula-3 editing, sorry, it's not likely going to happen. I have tried vi and emacs multiple times through the years and I can't use either. I use vi just for editing commit comments, which are often pasted in to the console from notepad anyway. My "problem" is that I make heavy use of the arrows, home, end, page up, page down, control, and shift. (control can "accelerate" arrows, shift is used for selecting). And some other ingrained keyboard short cuts like control-f, F3, etc. I use Visual C++ 5.0 and its support for these keys, plus a little bit of support for indentation, is excellent. It could be that the newer versions are better, and I would like find-and-REPLACE in files, and support for unicode files, but these aren't worth it so far. Oh, and the find-in-files, minus a replace option, is excellent, just super duper, I use it constantly. Nothing else compares. The only people I try to get to change editors is people that use notepad. On PPC_DARWIN I make do with TextWrangler. It is ok. (From the BBEdit folks). On PPC_LINUX I make do with kate (came with KDE/YellowDog). It is ok. If anyone out there is struggling with too-basic editors such as TextEdit or whatever it's called these days, I'd recommend trying these. But if you are already using a "programmer's editor", I'll leave you alone. :) If anyone knows of something more comparable to Visual C++ 5.0 on other platforms, I'm eager to hear. (Maybe under Wine? But that requires x86 I think..) Oh, CodeWarrior is ok too, and cross platform (well, Mac/Windows), but it starts up slowly on Windows, crashes a bit on Windows, and isn't being updated.. (Trying for "gentle advise" not "advocacy" here.) > > incremental cost of adding any given feature. One of M3's great I think the problem is more of multiplication than increment. How do the features interact with each other? Two features interact very very well -- destructors and exceptions. And constructors in that mix. Otherwise not certain. > C is a bit obsessive about source size, There used to be an assembler that used tabs and a competitor that used spaces. The tab guy advertised his much smaller files. :) And I think therefore faster assembling. Well, definitely much faster assembling either way, probably not because of or only because of the tabs. Yes I have that problem with procedures. And modules, and interfaces. This is where my editor and braces excel. You need to sprinkle in the matching text. You type control-brace on a brace and it shows you the matching one. Some editors do this just by moving the cursor across a brace (or paren). - Jay > Date: Fri, 15 Feb 2008 09:18:19 -0500> From: hendrik at topoi.pooq.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] "target specific pragmas"?> > On Fri, Feb 15, 2008 at 10:47:01AM +1100, Darko wrote:> > I don't really question the usefulness of any given feature, just the > > incremental cost of adding any given feature. One of M3's great > > strengths is that it is low on features, but the ones it has are > > powerful and well chosen.> > > > The comparison I meant in the typing discussion was between C and M3, > > not the length of symbols. C is a bit obsessive about source size, > > which was meaningful back in the day, but today is totally irrelevant. > > Even if you don't use macros on your editor, the amount of time spent > > staring and your code is much greater than the time you spend typing > > it. You could argue that BEGIN/END is easier to read than {/}> > If I had to argue, I'd argue the reverse. In fact, if it weren't for > disputes about the number of spaces that are equivalent to a tab and > such, I'd argue for using indentation and dispensing with BEGIN/END/{/} > altogether.> > Somewhere I have a C++ program with all the braces left out. If you > manage to supply the right braces and get it compiled, you end up > with a program that will do the job of supplying the right braces.> I could post it here if anyone in interested in such a curiosity.> > There's one language I've seen that goes in the opposite direction. > Every END is followed by an arbitrary amount of text from the start of > the construct it closes and a semicolon. This a WHILE loop starting> WHILE toronto == montreal > could end with> END WHILE toronto ==;> making visual matchin unambiguous.> > I've got friends that complain about haveing to type the name if a > procerure twice in its declaration -- once at the start and once at the > end. They say they keep fprgetting to modify both. But I welcome this > as a useful check on long-range bracket matching. Forcing it for > short-range marching, though, is clutter.> > -- hendrik _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri Feb 15 16:18:11 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 15 Feb 2008 15:18:11 +0000 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <20080215142042.GC3639@topoi.pooq.com> References: <200802140143.m1E1hDBv062411@camembert.async.caltech.edu> <20080214185947.GC30167@topoi.pooq.com> <3D050900-727C-4371-94C0-7357D8958194@cs.purdue.edu> <20080215142042.GC3639@topoi.pooq.com> Message-ID: I don't know but I could easily see pointer arithmetic banned on pointers to garbage collected types. I do NOT assume existing code will get garbage collection without source change. But then again, what does the Boehm collector do? And if I write: a: array of integer; for i := 0 to last(a) do (* or last - 1? Modula-3 array bounds not what I'm used to...*) IO.PutInt(a[i]); end in Modula-3, is the codegen a) really banned from and b) really avoids "rewriting" that with pointer arithmetic? I realize pointer arithmetic isn't even ever?often?usually?sometimes profitable these days i.e.: unsigned array[n]; for (size_t i = 0 ; i != n ; ++i) { printf("%u\n", array[i]); } vs. unsigned array[n]; for (unsigned* p = array ; p != (array + n) ; ++p) { printf("%u\n", *p); } compilers can often do better with the first. I've heard this. I don't know why. - Jay > Date: Fri, 15 Feb 2008 09:20:42 -0500> From: hendrik at topoi.pooq.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] "target specific pragmas"?> > On Thu, Feb 14, 2008 at 06:06:48PM -0500, Tony Hosking wrote:> > PS The C++ standard committee is actively developing the next C++ > > standard to include garbage collection as part of the spec.> > What are they ever going to do with those autodecremented pointers into > the middle of arrays?> > -- hendrik _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Fri Feb 15 16:31:42 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 15 Feb 2008 10:31:42 -0500 Subject: [M3devel] "target specific pragmas"? In-Reply-To: References: <200802140143.m1E1hDBv062411@camembert.async.caltech.edu> <20080214185947.GC30167@topoi.pooq.com> <3D050900-727C-4371-94C0-7357D8958194@cs.purdue.edu> <20080215142042.GC3639@topoi.pooq.com> Message-ID: <20080215153142.GD3639@topoi.pooq.com> On Fri, Feb 15, 2008 at 03:18:11PM +0000, Jay wrote: > I don't know but I could easily see pointer arithmetic banned on pointers to garbage collected types. > I do NOT assume existing code will get garbage collection without source change. > But then again, what does the Boehm collector do? I don't know. I'm mostly pointing out that it will involve radical change in C++ usage. > I realize pointer arithmetic isn't even ever?often?usually?sometimes profitable these days i.e.: > > unsigned array[n]; > for (size_t i = 0 ; i != n ; ++i) > { printf("%u\n", array[i]); > } > > vs. > unsigned array[n]; > for (unsigned* p = array ; p != (array + n) ; ++p) > { > printf("%u\n", *p); > } > > compilers can often do better with the first. I've heard this. I don't > know why. Perhaps because it's easier to tell that array[i] is (supposed to be) within the array? I believe C spec requires this (except for some futzing with the address just one element past the array, like array+n) but it's never checked in any C compiler I know of. I once explored the possibility of performing all of these chacks in a C/C++ implementation, and concluded that it would require sufficiently different data representation from the programmers' expectations that it would be essentially useless. One of the main uses of C is to communicate with strange program libraries that use strange in-memory data structures. When they include garbage-collection into C++, I fear the result will be that in the absence of type-safety and array-bound safety, garbage collection will seem to be one more thing that causes programs to crash. -- hendrik From hosking at cs.purdue.edu Fri Feb 15 16:51:43 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 15 Feb 2008 10:51:43 -0500 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <47B50EDF.8060807@wichita.edu> References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> <47B4C70D.4010408@wichita.edu> <7323567C-7632-4040-B858-47B8124759DC@cs.purdue.edu> <47B50EDF.8060807@wichita.edu> Message-ID: <3821B978-6149-40C5-9B2F-2C17ECE67843@cs.purdue.edu> Ah, OK. I don't much delve in pickle-land. Anything I can help with? On Feb 14, 2008, at 11:02 PM, Rodney M. Bates wrote: > 1) RTPacking.T and needs to have a separate size for LONGINT, > (which can vary independently of the size of INTEGER). > 2) Variable length values of subrange bounds found in type > descriptions (in TipeDesc.i3) can now have values beyond > what the native word size can represent. > 3) RTType.Kind.Longint (which I presume you, Tony, added recently) > is not handled by Pickles. > > I have done some coding on this, but have been interrupted. > > Tony Hosking wrote: >> Why is LONGINT for pickles not yet supported? > > -- > ------------------------------------------------------------- > Rodney M. Bates, retired assistant professor > Dept. of Computer Science, Wichita State University > Wichita, KS 67260-0083 > 316-978-3922 > rodney.bates at wichita.edu From hosking at cs.purdue.edu Fri Feb 15 17:13:53 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 15 Feb 2008 11:13:53 -0500 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <20080215142042.GC3639@topoi.pooq.com> References: <200802140143.m1E1hDBv062411@camembert.async.caltech.edu> <20080214185947.GC30167@topoi.pooq.com> <3D050900-727C-4371-94C0-7357D8958194@cs.purdue.edu> <20080215142042.GC3639@topoi.pooq.com> Message-ID: <0F7203EA-6D0B-4A5D-BF81-0141ADDFC89A@cs.purdue.edu> Interior references are derived from base pointers -- they can be dealt with or treated conservatively. On Feb 15, 2008, at 9:20 AM, hendrik at topoi.pooq.com wrote: > On Thu, Feb 14, 2008 at 06:06:48PM -0500, Tony Hosking wrote: >> PS The C++ standard committee is actively developing the next C++ >> standard to include garbage collection as part of the spec. > > What are they ever going to do with those autodecremented pointers > into > the middle of arrays? > > -- hendrik From hosking at cs.purdue.edu Fri Feb 15 17:14:36 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 15 Feb 2008 11:14:36 -0500 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <20080215142042.GC3639@topoi.pooq.com> References: <200802140143.m1E1hDBv062411@camembert.async.caltech.edu> <20080214185947.GC30167@topoi.pooq.com> <3D050900-727C-4371-94C0-7357D8958194@cs.purdue.edu> <20080215142042.GC3639@topoi.pooq.com> Message-ID: <54D818D0-97A3-494E-A329-13690DF2466E@cs.purdue.edu> PS CM3 permits interior pointers into the middle of arrays. The only way they get generated is with VAR parameters, but they do exist. :-) On Feb 15, 2008, at 9:20 AM, hendrik at topoi.pooq.com wrote: > On Thu, Feb 14, 2008 at 06:06:48PM -0500, Tony Hosking wrote: >> PS The C++ standard committee is actively developing the next C++ >> standard to include garbage collection as part of the spec. > > What are they ever going to do with those autodecremented pointers > into > the middle of arrays? > > -- hendrik From hosking at cs.purdue.edu Fri Feb 15 17:15:59 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 15 Feb 2008 11:15:59 -0500 Subject: [M3devel] "target specific pragmas"? In-Reply-To: References: <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> <47B2E62D.1E75.00D7.1@scires.com> <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> <5973F6E5-D030-4AF6-A28A-3D5172D130A6@darko.org> <20080214183427.GB30167@topoi.pooq.com> <32568FDB-AE71-4E19-B6FF-ED2D5FB098DE@darko.org> <20080215141819.GB3639@topoi.pooq.com> Message-ID: <1AAD7E29-676A-4C45-93D5-7B52D08968BE@cs.purdue.edu> The directions of these postings are off-topic for the m3devel mailing list. Let's try to get back to questions of Modula-3 development. On Feb 15, 2008, at 10:10 AM, Jay wrote: > Having written a bit of Python..really just a bit..you are all > privy to ALL of the Python I have ever written...I'll bite. > > It's fairly obvious once you write a bit of Python what goes on here. > > First, we all know that we all strive to indent things "correctly". > Now, "correctly" can vary somewhat, but the intent is universal. > Deeper lexical nesting goes with increased indentation. > You can pick the indent size, spaces vs. tabs, where the braces/ > begin/end go, but it's still the same intent. > > Now, when paired with begin/end or braces, you end up with a large > duplication of information. > The one the compiler uses only and the ones human use more. > You get to keep them in sync. Your editor might help a lot. > > What Python does is merely throw out half the data, and require > some consistency on your part for what in other languages the > compiler ignores. > I don't know the exact rules, but they are probably easy to think of. > That is, it could easily allow either spaces or tabs. > > This approach is not bad. But I have two problems: > 1) again, my editor > 2) it's a little wierd and hard to see when you have a whole lot of > closes in a row > > if > print > if > print > if > print > nothing here > > vs. either C or Modula-3. > Perhaps a better approach is to require "end" and require > consistent indentation. > Python also can't cope with an empty statement because of this plus > its lack of semicolons. > You have to say "pass". That's a bit of an indictment. > > As to tabs, the answer is very easy. Never ever use them. > Lots of folks use 4 space tabs, lots of folks use 8 space tabs. > I used to be a 4 space tab guy, but I gave up tabs a few years ago. > The Cygwin code uses 8 space tabs and is therefore unreadable to me. > (I could change my editor setting, and since the 4 space tabs are > pretty rare now, ok.) > > To those who suggested emacs for convenient Modula-3 editing, > sorry, it's not likely going to happen. > I have tried vi and emacs multiple times through the years and I > can't use either. > I use vi just for editing commit comments, which are often pasted > in to the console from notepad anyway. > > My "problem" is that I make heavy use of the arrows, home, end, > page up, page down, control, and shift. > (control can "accelerate" arrows, shift is used for selecting). > And some other ingrained keyboard short cuts like control-f, F3, etc. > I use Visual C++ 5.0 and its support for these keys, plus a little > bit of support for indentation, is excellent. > It could be that the newer versions are better, and I would like > find-and-REPLACE in files, and support for unicode files, but these > aren't worth it so far. Oh, and the find-in-files, minus a replace > option, is excellent, just super duper, I use it constantly. > Nothing else compares. > > The only people I try to get to change editors is people that use > notepad. > > On PPC_DARWIN I make do with TextWrangler. It is ok. (From the > BBEdit folks). > On PPC_LINUX I make do with kate (came with KDE/YellowDog). It is ok. > > If anyone out there is struggling with too-basic editors such as > TextEdit or whatever it's called these days, I'd recommend trying > these. But if you are already using a "programmer's editor", I'll > leave you alone. :) > If anyone knows of something more comparable to Visual C++ 5.0 on > other platforms, I'm eager to hear. > (Maybe under Wine? But that requires x86 I think..) > > Oh, CodeWarrior is ok too, and cross platform (well, Mac/Windows), > but it starts up slowly on Windows, crashes a bit on Windows, and > isn't being updated.. > > (Trying for "gentle advise" not "advocacy" here.) > > > > incremental cost of adding any given feature. One of M3's great > > I think the problem is more of multiplication than increment. > How do the features interact with each other? > Two features interact very very well -- destructors and exceptions. > And constructors in that mix. > Otherwise not certain. > > > C is a bit obsessive about source size, > > There used to be an assembler that used tabs and a competitor that > used spaces. > The tab guy advertised his much smaller files. :) And I think > therefore faster assembling. > Well, definitely much faster assembling either way, probably not > because of or only because > of the tabs. > > Yes I have that problem with procedures. And modules, and interfaces. > This is where my editor and braces excel. You need to sprinkle in > the matching text. > You type control-brace on a brace and it shows you the matching one. > Some editors do this just by moving the cursor across a brace (or > paren). > > - Jay > > > > > Date: Fri, 15 Feb 2008 09:18:19 -0500 > > From: hendrik at topoi.pooq.com > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] "target specific pragmas"? > > > > On Fri, Feb 15, 2008 at 10:47:01AM +1100, Darko wrote: > > > I don't really question the usefulness of any given feature, > just the > > > incremental cost of adding any given feature. One of M3's great > > > strengths is that it is low on features, but the ones it has are > > > powerful and well chosen. > > > > > > The comparison I meant in the typing discussion was between C > and M3, > > > not the length of symbols. C is a bit obsessive about source size, > > > which was meaningful back in the day, but today is totally > irrelevant. > > > Even if you don't use macros on your editor, the amount of time > spent > > > staring and your code is much greater than the time you spend > typing > > > it. You could argue that BEGIN/END is easier to read than {/} > > > > If I had to argue, I'd argue the reverse. In fact, if it weren't for > > disputes about the number of spaces that are equivalent to a tab and > > such, I'd argue for using indentation and dispensing with BEGIN/ > END/{/} > > altogether. > > > > Somewhere I have a C++ program with all the braces left out. If you > > manage to supply the right braces and get it compiled, you end up > > with a program that will do the job of supplying the right braces. > > I could post it here if anyone in interested in such a curiosity. > > > > There's one language I've seen that goes in the opposite direction. > > Every END is followed by an arbitrary amount of text from the > start of > > the construct it closes and a semicolon. This a WHILE loop starting > > WHILE toronto == montreal > > could end with > > END WHILE toronto ==; > > making visual matchin unambiguous. > > > > I've got friends that complain about haveing to type the name if a > > procerure twice in its declaration -- once at the start and once > at the > > end. They say they keep fprgetting to modify both. But I welcome > this > > as a useful check on long-range bracket matching. Forcing it for > > short-range marching, though, is clutter. > > > > -- hendrik > > > Shed those extra pounds with MSN and The Biggest Loser! Learn more. From hosking at cs.purdue.edu Fri Feb 15 17:20:19 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 15 Feb 2008 11:20:19 -0500 Subject: [M3devel] "target specific pragmas"? In-Reply-To: References: <200802140143.m1E1hDBv062411@camembert.async.caltech.edu> <20080214185947.GC30167@topoi.pooq.com> <3D050900-727C-4371-94C0-7357D8958194@cs.purdue.edu> <20080215142042.GC3639@topoi.pooq.com> Message-ID: <54998599-6E3D-425C-BA89-7BABBD9508D6@cs.purdue.edu> On Feb 15, 2008, at 10:18 AM, Jay wrote: > I don't know but I could easily see pointer arithmetic banned on > pointers to garbage collected types. If you check the C standard you will see that the only *defined* pointers to array elements are to the elements of the array and the "element" one index beyond the end of the array. Implementations of C are technically free to treat other pointer arithmetic however they like... :-) > I do NOT assume existing code will get garbage collection without > source change. > But then again, what does the Boehm collector do? > > And if I write: > > a: array of integer; > for i := 0 to last(a) do (* or last - 1? Modula-3 array bounds not > what I'm used to...*) > IO.PutInt(a[i]); > end > > in Modula-3, is the codegen a) really banned from and b) really avoids > "rewriting" that with pointer arithmetic? Not banned at all with the current GC. So long as a derived reference to the array exists the GC will use it to keep the array alive. From hosking at cs.purdue.edu Fri Feb 15 17:28:26 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 15 Feb 2008 11:28:26 -0500 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <3821B978-6149-40C5-9B2F-2C17ECE67843@cs.purdue.edu> References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> <47B4C70D.4010408@wichita.edu> <7323567C-7632-4040-B858-47B8124759DC@cs.purdue.edu> <47B50EDF.8060807@wichita.edu> <3821B978-6149-40C5-9B2F-2C17ECE67843@cs.purdue.edu> Message-ID: Rodney, Why does there need to be an entry for LONGINT in RTPacking? I would have thought all packing is done on word-sized units anyway. Each side of the connection can check BITSIZE(LONGINT) to figure out what to do presumably no differently from the way INTEGER is communicated between 32-bit and 64-bit machines. Am I missing something? -- Tony On Feb 15, 2008, at 10:51 AM, Tony Hosking wrote: > Ah, OK. I don't much delve in pickle-land. Anything I can help with? > > On Feb 14, 2008, at 11:02 PM, Rodney M. Bates wrote: > >> 1) RTPacking.T and needs to have a separate size for LONGINT, >> (which can vary independently of the size of INTEGER). >> 2) Variable length values of subrange bounds found in type >> descriptions (in TipeDesc.i3) can now have values beyond >> what the native word size can represent. >> 3) RTType.Kind.Longint (which I presume you, Tony, added recently) >> is not handled by Pickles. >> >> I have done some coding on this, but have been interrupted. >> >> Tony Hosking wrote: >>> Why is LONGINT for pickles not yet supported? >> >> -- >> ------------------------------------------------------------- >> Rodney M. Bates, retired assistant professor >> Dept. of Computer Science, Wichita State University >> Wichita, KS 67260-0083 >> 316-978-3922 >> rodney.bates at wichita.edu From rodney.bates at wichita.edu Fri Feb 15 21:50:27 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Fri, 15 Feb 2008 14:50:27 -0600 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> <47B4C70D.4010408@wichita.edu> <7323567C-7632-4040-B858-47B8124759DC@cs.purdue.edu> <47B50EDF.8060807@wichita.edu> <3821B978-6149-40C5-9B2F-2C17ECE67843@cs.purdue.edu> Message-ID: <47B5FB13.7070407@wichita.edu> The word "Packing" in RTPacking is perhaps misleading. Using BITSIZE, etc. only works for getting object layouts as on the machine executing the code, which is all that is needed when writing a pickle. When reading, Pickle code needs to know the layouts of a type both as it is on the reading machine and as it was on the machine that wrote the pickle. The type description that the compiler generates is excerpted and contains no field displacements, just lists of field types (which are either recursive type descriptions or builtin types). So it is independent of word sizes, etc. Pickles regenerates the displacements using the few target machine characteristics in a RTPacking.T It traverses a type description and simultaneously computes two sets of field displacements, both as they are on the reading machine and on the writing machine. For the latter, the value of RTPacking.T is (after a compact bit encoding) stored in the header of the pickle file. For the former, it's gotten by techniques like using BITSIZE. This is actually all done in RTTipe, part of m3core, and called by Pickle code. This is very fragile. RTTipe has to duplicate the compiler's layout behavior. There is no shared code. Making it common would involve quite a bit of rework, as the two use substantially different data structure and code organization. It will be obvious what kind of bit damage could occur if the two algorithms didn't agree. This is why I am obsessing over LAZYALIGN. I have been comparing the field displacement computations in RTTipe and in the compiler. The former is oblivious to LAZYALIGN. Note that all this is required even without any packing of small fields within words. E.G., a record with two INTEGER fields, pickled on a 32-bit machine and unpickled on a 64. Tony Hosking wrote: > Rodney, > > Why does there need to be an entry for LONGINT in RTPacking? I would > have thought all packing is done on word-sized units anyway. Each side > of the connection can check BITSIZE(LONGINT) to figure out what to do > presumably no differently from the way INTEGER is communicated between > 32-bit and 64-bit machines. Am I missing something? > > -- Tony > > On Feb 15, 2008, at 10:51 AM, Tony Hosking wrote: > >> Ah, OK. I don't much delve in pickle-land. Anything I can help with? >> >> On Feb 14, 2008, at 11:02 PM, Rodney M. Bates wrote: >> >>> 1) RTPacking.T and needs to have a separate size for LONGINT, >>> (which can vary independently of the size of INTEGER). >>> 2) Variable length values of subrange bounds found in type >>> descriptions (in TipeDesc.i3) can now have values beyond >>> what the native word size can represent. >>> 3) RTType.Kind.Longint (which I presume you, Tony, added recently) >>> is not handled by Pickles. >>> >>> I have done some coding on this, but have been interrupted. >>> >>> Tony Hosking wrote: >>> >>>> Why is LONGINT for pickles not yet supported? >>> >>> >>> -- >>> ------------------------------------------------------------- >>> Rodney M. Bates, retired assistant professor >>> Dept. of Computer Science, Wichita State University >>> Wichita, KS 67260-0083 >>> 316-978-3922 >>> rodney.bates at wichita.edu > > > -- ------------------------------------------------------------- Rodney M. Bates, retired assistant professor Dept. of Computer Science, Wichita State University Wichita, KS 67260-0083 316-978-3922 rodney.bates at wichita.edu From wagner at elegosoft.com Fri Feb 15 22:32:05 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 15 Feb 2008 22:32:05 +0100 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <47B5FB13.7070407@wichita.edu> References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> <47B4C70D.4010408@wichita.edu> <7323567C-7632-4040-B858-47B8124759DC@cs.purdue.edu> <47B50EDF.8060807@wichita.edu> <3821B978-6149-40C5-9B2F-2C17ECE67843@cs.purdue.edu> <47B5FB13.7070407@wichita.edu> Message-ID: <20080215223205.t9a01icx4okgco0o@mail.elegosoft.com> Perhaps we should check-in this description somewhere near the actual code? Or is there enough documentation already? Olaf PS: Based on your description, I'd say we should abandon LAZYALIGN. Or at least put a big sticker on that it will break pickles. Quoting "Rodney M. Bates" : > The word "Packing" in RTPacking is perhaps misleading. Using BITSIZE, > etc. only works for getting object layouts as on the machine executing > the code, which is all that is needed when writing a pickle. > > When reading, Pickle code needs to know the layouts of a type both as > it is on the reading machine and as it was on the machine that wrote > the pickle. The type description that the compiler generates is > excerpted and contains no field displacements, just lists of field > types (which are either recursive type descriptions or builtin types). > So it is independent of word sizes, etc. > > Pickles regenerates the displacements using the few target machine > characteristics in a RTPacking.T It traverses a type description and > simultaneously computes two sets of field displacements, both as they > are on the reading machine and on the writing machine. For the latter, > the value of RTPacking.T is (after a compact bit encoding) stored in the > header of the pickle file. For the former, it's gotten by techniques like > using BITSIZE. This is actually all done in RTTipe, part of m3core, and > called by Pickle code. > > This is very fragile. RTTipe has to duplicate the compiler's layout > behavior. There is no shared code. Making it common would involve > quite a bit of rework, as the two use substantially different data > structure and code organization. It will be obvious what kind of bit > damage could occur if the two algorithms didn't agree. > > This is why I am obsessing over LAZYALIGN. I have been comparing the > field displacement computations in RTTipe and in the compiler. The > former is oblivious to LAZYALIGN. > > Note that all this is required even without any packing of small fields > within words. E.G., a record with two INTEGER fields, pickled on a > 32-bit machine and unpickled on a 64. > > Tony Hosking wrote: >> Rodney, >> >> Why does there need to be an entry for LONGINT in RTPacking? I >> would have thought all packing is done on word-sized units anyway. >> Each side of the connection can check BITSIZE(LONGINT) to figure >> out what to do presumably no differently from the way INTEGER is >> communicated between 32-bit and 64-bit machines. Am I missing >> something? >> >> -- Tony >> >> On Feb 15, 2008, at 10:51 AM, Tony Hosking wrote: >> >>> Ah, OK. I don't much delve in pickle-land. Anything I can help with? >>> >>> On Feb 14, 2008, at 11:02 PM, Rodney M. Bates wrote: >>> >>>> 1) RTPacking.T and needs to have a separate size for LONGINT, >>>> (which can vary independently of the size of INTEGER). >>>> 2) Variable length values of subrange bounds found in type >>>> descriptions (in TipeDesc.i3) can now have values beyond >>>> what the native word size can represent. >>>> 3) RTType.Kind.Longint (which I presume you, Tony, added recently) >>>> is not handled by Pickles. >>>> >>>> I have done some coding on this, but have been interrupted. >>>> >>>> Tony Hosking wrote: >>>> >>>>> Why is LONGINT for pickles not yet supported? >>>> >>>> >>>> -- >>>> ------------------------------------------------------------- >>>> Rodney M. Bates, retired assistant professor >>>> Dept. of Computer Science, Wichita State University >>>> Wichita, KS 67260-0083 >>>> 316-978-3922 >>>> rodney.bates at wichita.edu >> >> >> > > -- > ------------------------------------------------------------- > Rodney M. Bates, retired assistant professor > Dept. of Computer Science, Wichita State University > Wichita, KS 67260-0083 > 316-978-3922 > rodney.bates at wichita.edu -- Olaf Wagner -- elego Software Solutions GmbH 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 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From rodney.bates at wichita.edu Fri Feb 15 23:06:24 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Fri, 15 Feb 2008 16:06:24 -0600 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <20080215223205.t9a01icx4okgco0o@mail.elegosoft.com> References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> <47B4C70D.4010408@wichita.edu> <7323567C-7632-4040-B858-47B8124759DC@cs.purdue.edu> <47B50EDF.8060807@wichita.edu> <3821B978-6149-40C5-9B2F-2C17ECE67843@cs.purdue.edu> <47B5FB13.7070407@wichita.edu> <20080215223205.t9a01icx4okgco0o@mail.elegosoft.com> Message-ID: <47B60CE0.8050506@wichita.edu> I'll put it in comments in the code. I am sure I can fix it to handle LAZYALIGN too, just not sure whether I can do it without requiring existing pickle files to be regenerated and/or existing code that reads/writes pickles to need recompilation. Anybody on this list who has code that might be affected if pickles or compiled code were invalidated by a change? I do propose we change the way of telling the compiler to do LAZYALIGN so that it is a property of a type and affects all variables of that type. Olaf Wagner wrote: > Perhaps we should check-in this description somewhere near the > actual code? Or is there enough documentation already? > > Olaf > > PS: Based on your description, I'd say we should abandon LAZYALIGN. > Or at least put a big sticker on that it will break pickles. > > Quoting "Rodney M. Bates" : > >> The word "Packing" in RTPacking is perhaps misleading. Using BITSIZE, >> etc. only works for getting object layouts as on the machine executing >> the code, which is all that is needed when writing a pickle. >> >> When reading, Pickle code needs to know the layouts of a type both as >> it is on the reading machine and as it was on the machine that wrote >> the pickle. The type description that the compiler generates is >> excerpted and contains no field displacements, just lists of field >> types (which are either recursive type descriptions or builtin types). >> So it is independent of word sizes, etc. >> >> Pickles regenerates the displacements using the few target machine >> characteristics in a RTPacking.T It traverses a type description and >> simultaneously computes two sets of field displacements, both as they >> are on the reading machine and on the writing machine. For the latter, >> the value of RTPacking.T is (after a compact bit encoding) stored in the >> header of the pickle file. For the former, it's gotten by techniques >> like >> using BITSIZE. This is actually all done in RTTipe, part of m3core, and >> called by Pickle code. >> >> This is very fragile. RTTipe has to duplicate the compiler's layout >> behavior. There is no shared code. Making it common would involve >> quite a bit of rework, as the two use substantially different data >> structure and code organization. It will be obvious what kind of bit >> damage could occur if the two algorithms didn't agree. >> >> This is why I am obsessing over LAZYALIGN. I have been comparing the >> field displacement computations in RTTipe and in the compiler. The >> former is oblivious to LAZYALIGN. >> >> Note that all this is required even without any packing of small fields >> within words. E.G., a record with two INTEGER fields, pickled on a >> 32-bit machine and unpickled on a 64. >> >> Tony Hosking wrote: >> >>> Rodney, >>> >>> Why does there need to be an entry for LONGINT in RTPacking? I >>> would have thought all packing is done on word-sized units anyway. >>> Each side of the connection can check BITSIZE(LONGINT) to figure >>> out what to do presumably no differently from the way INTEGER is >>> communicated between 32-bit and 64-bit machines. Am I missing >>> something? >>> >>> -- Tony >>> >>> On Feb 15, 2008, at 10:51 AM, Tony Hosking wrote: >>> >>>> Ah, OK. I don't much delve in pickle-land. Anything I can help with? >>>> >>>> On Feb 14, 2008, at 11:02 PM, Rodney M. Bates wrote: >>>> >>>>> 1) RTPacking.T and needs to have a separate size for LONGINT, >>>>> (which can vary independently of the size of INTEGER). >>>>> 2) Variable length values of subrange bounds found in type >>>>> descriptions (in TipeDesc.i3) can now have values beyond >>>>> what the native word size can represent. >>>>> 3) RTType.Kind.Longint (which I presume you, Tony, added recently) >>>>> is not handled by Pickles. >>>>> >>>>> I have done some coding on this, but have been interrupted. >>>>> >>>>> Tony Hosking wrote: >>>>> >>>>>> Why is LONGINT for pickles not yet supported? >>>>> >>>>> >>>>> >>>>> -- >>>>> ------------------------------------------------------------- >>>>> Rodney M. Bates, retired assistant professor >>>>> Dept. of Computer Science, Wichita State University >>>>> Wichita, KS 67260-0083 >>>>> 316-978-3922 >>>>> rodney.bates at wichita.edu >>> >>> >>> >>> >> >> -- >> ------------------------------------------------------------- >> Rodney M. Bates, retired assistant professor >> Dept. of Computer Science, Wichita State University >> Wichita, KS 67260-0083 >> 316-978-3922 >> rodney.bates at wichita.edu > > > > -- ------------------------------------------------------------- Rodney M. Bates, retired assistant professor Dept. of Computer Science, Wichita State University Wichita, KS 67260-0083 316-978-3922 rodney.bates at wichita.edu From rodney.bates at wichita.edu Fri Feb 15 23:08:46 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Fri, 15 Feb 2008 16:08:46 -0600 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <94EB43F9-8E9E-4F6C-95BD-FB9872FD01A2@darko.org> References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> <47B4C70D.4010408@wichita.edu> <94EB43F9-8E9E-4F6C-95BD-FB9872FD01A2@darko.org> Message-ID: <47B60D6E.8080704@wichita.edu> So how is lazy alignment invoked for these types? In my grepping and reading in the compiler, I saw internal lazy alignment booleans turned on only by the pragma. Darko wrote: > The alignment rules are correctly associated with a type. I think the > pragma can be removed. There are no pickles anywhere of these types. > > -- ------------------------------------------------------------- Rodney M. Bates, retired assistant professor Dept. of Computer Science, Wichita State University Wichita, KS 67260-0083 316-978-3922 rodney.bates at wichita.edu From rodney.bates at wichita.edu Fri Feb 15 23:41:09 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Fri, 15 Feb 2008 16:41:09 -0600 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <32568FDB-AE71-4E19-B6FF-ED2D5FB098DE@darko.org> References: <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> <47B2E62D.1E75.00D7.1@scires.com> <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> <5973F6E5-D030-4AF6-A28A-3D5172D130A6@darko.org> <20080214183427.GB30167@topoi.pooq.com> <32568FDB-AE71-4E19-B6FF-ED2D5FB098DE@darko.org> Message-ID: <47B61505.5080708@wichita.edu> I view this as more significant than it would first appear. More important than readability is that delimiters with several letters in all caps are more PROMINENT. This makes it quicker seeing the overall structure of a piece of code before looking at the deeper details such as which variable is being manipulated. Up to now, every person I have discussed it with who has spent enough time coding with this style of delimiters to get over their initial aversion has agreed the prominence of all caps makes the code structure easier to see quickly. Even Ada programmers who had significant prior experience in Modula-2 have preferred all caps in Ada (Ada is case- insensitive, so you can do it as you please.) As for readability, I recall seeing research some years back that showed all caps are less readable than lower case, that is, people read all caps slower and/or with less accuracy. For the delimiters, prominence is more important, especially since their vocabulary is far smaller than that of identifiers and doesn't change from program to program. As for esthetics, speaking for myself, after many years, I still think all caps reserved words are uglier than mud fences, but I happily accept that as the cost of easier scanning of code. It would be nice we had a standard character code that could handle lower case, bold face, as in the Algol 60 "publication language". That would be prominent and look great too. Of course, someone could undermine it all by making all the identifiers all caps too, loosing the quickly spotted reserved words, reducing readability where it matters more, and, IMO looking even uglier. Fortunately, Modula-3 culture seems to prevent that. Darko wrote: > I don't really question the usefulness of any given feature, just the > incremental cost of adding any given feature. One of M3's great > strengths is that it is low on features, but the ones it has are > powerful and well chosen. > > The comparison I meant in the typing discussion was between C and M3, > not the length of symbols. C is a bit obsessive about source size, > which was meaningful back in the day, but today is totally irrelevant. > Even if you don't use macros on your editor, the amount of time spent > staring and your code is much greater than the time you spend typing > it. You could argue that BEGIN/END is easier to read than {/} but I > think the more important point is that this issue is not a significant > one. -- ------------------------------------------------------------- Rodney M. Bates, retired assistant professor Dept. of Computer Science, Wichita State University Wichita, KS 67260-0083 316-978-3922 rodney.bates at wichita.edu From rodney.bates at wichita.edu Fri Feb 15 23:52:22 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Fri, 15 Feb 2008 16:52:22 -0600 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <5973F6E5-D030-4AF6-A28A-3D5172D130A6@darko.org> References: "Your message of Tue, 12 Feb 2008 18:54:50 EST." <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> <47B2E62D.1E75.00D7.1@scires.com> <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> <5973F6E5-D030-4AF6-A28A-3D5172D130A6@darko.org> Message-ID: <47B617A6.80305@wichita.edu> Darko wrote: > > You say that C has 'won', but in what sense? More people use it? > Language design is not American Idol, it's not a question of who has > the most votes. "It's what everybody is doing" motivates lemmings to jump off cliffs into the ocean and drown (according to the apparently exaggerated legend.) Thinking people need better reasons than popularity. > You have to do more than list features of C or C++ and your opinions on > them. You have to provide some rationale as to their benefit which > convinces people. Sadly, in my experience, most people are so deeply committed to lemming logic, that any attempt at engaging them in a polite but serious discussion about programming languages or giving real rationale is almost always dismissed, either as "That's just religion", or "This is what everybody is doing, ergo it has to be the right way." -- ------------------------------------------------------------- Rodney M. Bates, retired assistant professor Dept. of Computer Science, Wichita State University Wichita, KS 67260-0083 316-978-3922 rodney.bates at wichita.edu From mika at async.caltech.edu Fri Feb 15 23:58:55 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 15 Feb 2008 14:58:55 -0800 Subject: [M3devel] "target specific pragmas"? In-Reply-To: Your message of "Thu, 14 Feb 2008 13:34:27 EST." <20080214183427.GB30167@topoi.pooq.com> Message-ID: <200802152258.m1FMwtEH032083@camembert.async.caltech.edu> I just have to add a small comment on syntax, in response to how weird M3's syntax is, etc. One of the nice thing when I was teaching intro programming was that "serious" CS books (and a large fraction of academic publications) still use a kind of standard pseudocode that is based on Algol. And that pseudocode looks a lot more like Modula-3 than it looks like C! No explanation of braces or the fact that when you see "=" in the pseudocode you want "==" in the machine-readable version, and when you see ":=" you want "=". What your video game developer friend needs is to do exercise #12 in section 2.3.5 in Knuth. (There are references to three existing solutions in the answer key.) Mika hendrik at topoi.pooq.com writes: >On Thu, Feb 14, 2008 at 12:09:40PM +1100, Darko wrote: >> M3 is the antithesis in the sense that it takes the opposite approach. >> C has few protections, M3 has many. M3 does examine what was wrong >> with C and other languages and fix them and it did a good job. The M3 >> design team made an explicit goal to look at features from other >> languages and take the best. The fact that M3 works so well is the >> proof. >> >> Some of the things you raise, like braces > >I'm assuming this is the use of '{' and '}' instead of 'BEGIN' and >'END'. > >Natural languages evolve in the direction of having the mopst-oftern >used words be the shortest. This makes it possible to say muc in less >space and time. And it makes it easier to get an overview of a >program whose physical size is becoming inconvenient. Just haveing >the code be readable and seeing enough of its context makes >debugging easier. > >> or stack allocations of >> objects are just features of C++ with no justification. > >Stack allocation of objects is not such a big issue in C++. But it can >be a big issue in those programs where split-second real-time >interaction is an issue. Yes, I know this is the traditional argument >against garbage collection, and that it is usually based on FUD rather >than reality. But I have recently been in close contact with a >programmer of video games, and for some of them the fraction-of-a-second >pauses are a real problem. He really *wants* to write his games in a >decent language, and he knows that C is not one. > >But every time he avoids heap allocation he delays the pause. If >he can delay it enough, it's a win. If he can delay it altogether, >that's success. > >> Can you show >> that typing less characters is important? You say M3 is less >> convenient, but what is less convenient, less typing or less bugs? > > This is a false dichotomy. You may well be able to reduce typing >*and* reduce bugs, just by making code more readable. > >I doubt that typing "PROC" instead of "PROCEDURE", for example, is >likely to introdice bugs. Not typing '{' instead of "BEGIN". Using >special characters and lower-case keywords is likely to reduce bugs, >because it's less likely that one will be misread for another. > >> Do >> you spend most of your time typing or thinking when you write code? > >I think before I write code. I don't stop thinking when I start >writing code, and I like to record my thoughts as I think. The less >typing I need to do, the better I can get visual feedback on my >thoughts while thinking. Sometimes the typing gets so tedious I get >bored and lose interest. Then extra typing causes extra bugs. >> >> Should language include every feature anyone can think of? > >No. > >> How is >> excluding unimportant features 'arbitrary'? Each feature must be >> weighed to avoid unnecessary complexity and size, which have a direct >> impact on compiler maintainability and language usability. Language >> bloat is a real problem. I doubt that anyone understands the full >> semantics of C++. >> >> You say that C has 'won', but in what sense? More people use it? >> Language design is not American Idol, it's not a question of who has >> the most votes. > >Enough people use it that it has become a fixture in the programming >world. If you want to reuse existing code instead of always writing >new, you are pretty much forced into some kind of interfacing between C >and a reasonable language. The convenience of this interfacing can well >determine whether the reasonable language is feasible for a specific >application. > >-- hendrik From hendrik at topoi.pooq.com Sat Feb 16 00:17:41 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 15 Feb 2008 18:17:41 -0500 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <200802152258.m1FMwtEH032083@camembert.async.caltech.edu> References: <20080214183427.GB30167@topoi.pooq.com> <200802152258.m1FMwtEH032083@camembert.async.caltech.edu> Message-ID: <20080215231741.GA4216@topoi.pooq.com> On Fri, Feb 15, 2008 at 02:58:55PM -0800, Mika Nystrom wrote: > > What your video game developer friend needs is to do exercise #12 > in section 2.3.5 in Knuth. (There are references to three existing > solutions in the answer key.) Is that the one one completely concurrent garbage collection? Unfortunately, he wants to write video games, not implement programming languages. But ... I think he's tempted. I still feel I have to warn him of the time I wanted to write an applocation and got side-tracked into writing the language in which the application would be easy to write. I never got back to the application. I don't even remember what it was. That was in the 1960's. I'm still stuck on languages. -- hendrik From darko at darko.org Sat Feb 16 00:34:47 2008 From: darko at darko.org (Darko) Date: Sat, 16 Feb 2008 10:34:47 +1100 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <20080215141819.GB3639@topoi.pooq.com> References: <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> <47B2E62D.1E75.00D7.1@scires.com> <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> <5973F6E5-D030-4AF6-A28A-3D5172D130A6@darko.org> <20080214183427.GB30167@topoi.pooq.com> <32568FDB-AE71-4E19-B6FF-ED2D5FB098DE@darko.org> <20080215141819.GB3639@topoi.pooq.com> Message-ID: <25955172-E857-4B24-8D51-3701C7353687@darko.org> I'm sticking to my view about lexical arbitrariness, but on that basis, I'd really like to see an alternate syntax for M3, one that looks almost exactly like C, but roughly keeps the existing statement form. I think it would make the language much more palatable to C programmers and the like and would remove what is a silly barrier to broader adaption. We could call the syntax 'Modula-C'. On 16/02/2008, at 1:18 AM, hendrik at topoi.pooq.com wrote: > On Fri, Feb 15, 2008 at 10:47:01AM +1100, Darko wrote: >> I don't really question the usefulness of any given feature, just the >> incremental cost of adding any given feature. One of M3's great >> strengths is that it is low on features, but the ones it has are >> powerful and well chosen. >> >> The comparison I meant in the typing discussion was between C and M3, >> not the length of symbols. C is a bit obsessive about source size, >> which was meaningful back in the day, but today is totally >> irrelevant. >> Even if you don't use macros on your editor, the amount of time spent >> staring and your code is much greater than the time you spend typing >> it. You could argue that BEGIN/END is easier to read than {/} > > If I had to argue, I'd argue the reverse. In fact, if it weren't for > disputes about the number of spaces that are equivalent to a tab and > such, I'd argue for using indentation and dispensing with BEGIN/END/ > {/} > altogether. > > Somewhere I have a C++ program with all the braces left out. If you > manage to supply the right braces and get it compiled, you end up > with a program that will do the job of supplying the right braces. > I could post it here if anyone in interested in such a curiosity. > > There's one language I've seen that goes in the opposite direction. > Every END is followed by an arbitrary amount of text from the start of > the construct it closes and a semicolon. This a WHILE loop starting > WHILE toronto == montreal > could end with > END WHILE toronto ==; > making visual matchin unambiguous. > > I've got friends that complain about haveing to type the name if a > procerure twice in its declaration -- once at the start and once at > the > end. They say they keep fprgetting to modify both. But I welcome > this > as a useful check on long-range bracket matching. Forcing it for > short-range marching, though, is clutter. > > -- hendrik From mika at async.caltech.edu Sat Feb 16 00:38:09 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 15 Feb 2008 15:38:09 -0800 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: Your message of "Fri, 15 Feb 2008 14:50:27 CST." <47B5FB13.7070407@wichita.edu> Message-ID: <200802152338.m1FNc9gC033479@camembert.async.caltech.edu> Hi Rodney, I am not sure if I am reading your email entirely correctly, but I think so... you're trying to figure out things like offsets so the Pickle runtime can re-build arbitrary data structures. When we were doing some concurrent programming in my group about ten years ago, we were using a user-level threading system (very similar but not identical to the old user-level threads in M3) and we needed to figure out the location of the stack pointer in a C jmp_buf. We just wrote a program to do it... Could you do that? Write some arbitrary data whose bit pattern you know to a field, cast it to char * (or some such), and search for the bit pattern? Do it over and over with random data, and there you go... Mika "Rodney M. Bates" writes: >The word "Packing" in RTPacking is perhaps misleading. Using BITSIZE, >etc. only works for getting object layouts as on the machine executing >the code, which is all that is needed when writing a pickle. > >When reading, Pickle code needs to know the layouts of a type both as >it is on the reading machine and as it was on the machine that wrote >the pickle. The type description that the compiler generates is >excerpted and contains no field displacements, just lists of field >types (which are either recursive type descriptions or builtin types). >So it is independent of word sizes, etc. > >Pickles regenerates the displacements using the few target machine >characteristics in a RTPacking.T It traverses a type description and >simultaneously computes two sets of field displacements, both as they >are on the reading machine and on the writing machine. For the latter, >the value of RTPacking.T is (after a compact bit encoding) stored in the >header of the pickle file. For the former, it's gotten by techniques like >using BITSIZE. This is actually all done in RTTipe, part of m3core, and >called by Pickle code. > >This is very fragile. RTTipe has to duplicate the compiler's layout >behavior. There is no shared code. Making it common would involve >quite a bit of rework, as the two use substantially different data >structure and code organization. It will be obvious what kind of bit >damage could occur if the two algorithms didn't agree. > >This is why I am obsessing over LAZYALIGN. I have been comparing the >field displacement computations in RTTipe and in the compiler. The >former is oblivious to LAZYALIGN. > >Note that all this is required even without any packing of small fields >within words. E.G., a record with two INTEGER fields, pickled on a >32-bit machine and unpickled on a 64. > >Tony Hosking wrote: >> Rodney, >> >> Why does there need to be an entry for LONGINT in RTPacking? I would >> have thought all packing is done on word-sized units anyway. Each side >> of the connection can check BITSIZE(LONGINT) to figure out what to do >> presumably no differently from the way INTEGER is communicated between >> 32-bit and 64-bit machines. Am I missing something? >> >> -- Tony >> >> On Feb 15, 2008, at 10:51 AM, Tony Hosking wrote: >> >>> Ah, OK. I don't much delve in pickle-land. Anything I can help with? >>> >>> On Feb 14, 2008, at 11:02 PM, Rodney M. Bates wrote: >>> >>>> 1) RTPacking.T and needs to have a separate size for LONGINT, >>>> (which can vary independently of the size of INTEGER). >>>> 2) Variable length values of subrange bounds found in type >>>> descriptions (in TipeDesc.i3) can now have values beyond >>>> what the native word size can represent. >>>> 3) RTType.Kind.Longint (which I presume you, Tony, added recently) >>>> is not handled by Pickles. >>>> >>>> I have done some coding on this, but have been interrupted. >>>> >>>> Tony Hosking wrote: >>>> >>>>> Why is LONGINT for pickles not yet supported? >>>> >>>> >>>> -- >>>> ------------------------------------------------------------- >>>> Rodney M. Bates, retired assistant professor >>>> Dept. of Computer Science, Wichita State University >>>> Wichita, KS 67260-0083 >>>> 316-978-3922 >>>> rodney.bates at wichita.edu >> >> >> > >-- >------------------------------------------------------------- >Rodney M. Bates, retired assistant professor >Dept. of Computer Science, Wichita State University >Wichita, KS 67260-0083 >316-978-3922 >rodney.bates at wichita.edu From darko at darko.org Sat Feb 16 00:41:51 2008 From: darko at darko.org (Darko) Date: Sat, 16 Feb 2008 10:41:51 +1100 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <47B60D6E.8080704@wichita.edu> References: <47AF72B5.2080308@wichita.edu> <47B1168F.8020302@wichita.edu> <94E65369-025F-47A9-AD2F-5F34B4A21236@darko.org> <47B4C70D.4010408@wichita.edu> <94EB43F9-8E9E-4F6C-95BD-FB9872FD01A2@darko.org> <47B60D6E.8080704@wichita.edu> Message-ID: <385E6BF4-B476-4060-9EAD-DE1DCC74A2D9@darko.org> It's turned on at the platform level only. The result is that packed structures are packed as tightly as possible. On 16/02/2008, at 9:08 AM, Rodney M. Bates wrote: > So how is lazy alignment invoked for these types? In my grepping > and reading > in the compiler, I saw internal lazy alignment booleans turned on only > by the pragma. > > Darko wrote: >> The alignment rules are correctly associated with a type. I think >> the pragma can be removed. There are no pickles anywhere of these >> types. > > -- > ------------------------------------------------------------- > Rodney M. Bates, retired assistant professor > Dept. of Computer Science, Wichita State University > Wichita, KS 67260-0083 > 316-978-3922 > rodney.bates at wichita.edu From mika at async.caltech.edu Sat Feb 16 00:51:43 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 15 Feb 2008 15:51:43 -0800 Subject: [M3devel] "target specific pragmas"? In-Reply-To: Your message of "Sat, 16 Feb 2008 10:34:47 +1100." <25955172-E857-4B24-8D51-3701C7353687@darko.org> Message-ID: <200802152351.m1FNphNp033913@camembert.async.caltech.edu> Darko writes: >I'm sticking to my view about lexical arbitrariness, but on that >basis, I'd really like to see an alternate syntax for M3, one that >looks almost exactly like C, but roughly keeps the existing statement >form. I think it would make the language much more palatable to C >programmers and the like and would remove what is a silly barrier to >broader adaption. We could call the syntax 'Modula-C'. This is getting a bit silly, and I apologize to everyone reading this about wasting their time, but I just have to show you the following file. It is a header file from the original sources of "sh" (this copy is from 4.3 TAHOE UNIX, but of course the code is much older than that). After that, blok.c, an example of "Bournegol" in use. So, you want the opposite, huh? Mika /* mac.h 4.3 87/10/26 */ # /* * UNIX shell * * S. R. Bourne * Bell Telephone Laboratories * */ #define LOCAL static #define PROC extern #define TYPE typedef #define STRUCT TYPE struct #define UNION TYPE union #define REG register #define IF if( #define THEN ){ #define ELSE } else { #define ELIF } else if ( #define FI ;} #define BEGIN { #define END } #define SWITCH switch( #define IN ){ #define ENDSW } #define FOR for( #define WHILE while( #define DO ){ #define OD ;} #define REP do{ #define PER }while( #undef DONE #define DONE ); #define LOOP for(;;){ #define POOL } #define SKIP ; #define DIV / #define REM % #define NEQ ^ #define ANDF && #define ORF || #define TRUE (-1) #define FALSE 0 #define LOBYTE 0377 #define STRIP 0177 #define QUOTE 0200 #define EOF 0 #define NL '\n' #define SP ' ' #define LQ '`' #define RQ '\'' #define MINUS '-' #define COLON ':' #ifndef lint static char sccsid[] = "@(#)blok.c 4.2 8/11/83"; #endif # /* * UNIX shell * * S. R. Bourne * Bell Telephone Laboratories * */ #include "defs.h" /* * storage allocator * (circular first fit strategy) */ #define BUSY 01 #define busy(x) (Rcheat((x)->word)&BUSY) POS brkincr=BRKINCR; BLKPTR blokp; /*current search pointer*/ BLKPTR bloktop=BLK(end); /*top of arena (last blok)*/ ADDRESS alloc(nbytes) POS nbytes; { REG POS rbytes = round(nbytes+BYTESPERWORD,BYTESPERWORD); LOOP INT c=0; REG BLKPTR p = blokp; REG BLKPTR q; REP IF !busy(p) THEN WHILE !busy(q = p->word) DO p->word = q->word OD IF ADR(q)-ADR(p) >= rbytes THEN blokp = BLK(ADR(p)+rbytes); IF q > blokp THEN blokp->word = p->word; FI p->word=BLK(Rcheat(blokp)|BUSY); return(ADR(p+1)); FI FI q = p; p = BLK(Rcheat(p->word)&~BUSY); PER p>q ORF (c++)==0 DONE addblok(rbytes); POOL } VOID addblok(reqd) POS reqd; { IF stakbas!=staktop THEN REG STKPTR rndstak; REG BLKPTR blokstak; pushstak(0); rndstak=round(staktop,BYTESPERWORD); blokstak=BLK(stakbas)-1; blokstak->word=stakbsy; stakbsy=blokstak; bloktop->word=BLK(Rcheat(rndstak)|BUSY); bloktop=BLK(rndstak); FI reqd += brkincr; reqd &= ~(brkincr-1); blokp=bloktop; bloktop=bloktop->word=BLK(Rcheat(bloktop)+reqd); bloktop->word=BLK(ADR(end)+1); BEGIN REG STKPTR stakadr=STK(bloktop+2); staktop=movstr(stakbot,stakadr); stakbas=stakbot=stakadr; END } VOID free(ap) BLKPTR ap; { REG BLKPTR p; IF (p=ap) ANDF pword) &= ~BUSY; FI } #ifdef DEBUG chkbptr(ptr) BLKPTR ptr; { INT exf=0; REG BLKPTR p = end; REG BLKPTR q; INT us=0, un=0; LOOP q = Rcheat(p->word)&~BUSY; IF p==ptr THEN exf++ FI IF qbloktop THEN abort(3) FI IF p==bloktop THEN break FI IF busy(p) THEN us += q-p; ELSE un += q-p; FI IF p>=q THEN abort(4) FI p=q; POOL IF exf==0 THEN abort(1) FI prn(un); prc(SP); prn(us); prc(NL); } #endif From mika at async.caltech.edu Sat Feb 16 00:56:00 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 15 Feb 2008 15:56:00 -0800 Subject: [M3devel] "target specific pragmas"? In-Reply-To: Your message of "Fri, 15 Feb 2008 18:17:41 EST." <20080215231741.GA4216@topoi.pooq.com> Message-ID: <200802152356.m1FNu0F3034075@camembert.async.caltech.edu> hendrik at topoi.pooq.com writes: >On Fri, Feb 15, 2008 at 02:58:55PM -0800, Mika Nystrom wrote: >> >> What your video game developer friend needs is to do exercise #12 >> in section 2.3.5 in Knuth. (There are references to three existing >> solutions in the answer key.) > >Is that the one one completely concurrent garbage collection? Right, I think that's what Tony was (indirectly) referring to, as well. The publication dates on the three solutions range from 1975 to 1978... > >Unfortunately, he wants to write video games, not implement programming >languages. But ... I think he's tempted. > >I still feel I have to warn him of the time I wanted to write an >applocation and got side-tracked into writing the language in which the >application would be easy to write. I never got back to the >application. I don't even remember what it was. That was in the >1960's. I'm still stuck on languages. And, if you ask me, languages are still stuck! > >-- hendrik From hendrik at topoi.pooq.com Sat Feb 16 01:18:30 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 15 Feb 2008 19:18:30 -0500 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <47B61505.5080708@wichita.edu> References: <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> <47B2E62D.1E75.00D7.1@scires.com> <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> <5973F6E5-D030-4AF6-A28A-3D5172D130A6@darko.org> <20080214183427.GB30167@topoi.pooq.com> <32568FDB-AE71-4E19-B6FF-ED2D5FB098DE@darko.org> <47B61505.5080708@wichita.edu> Message-ID: <20080216001830.GB4216@topoi.pooq.com> On Fri, Feb 15, 2008 at 04:41:09PM -0600, Rodney M. Bates wrote: > I view this as more significant than it would first appear. More > important than readability is that delimiters with several letters > in all caps are more PROMINENT. This makes it quicker seeing the > overall structure of a piece of code before looking at the deeper > details such as which variable is being manipulated. > > Up to now, every person I have discussed it with who has spent enough > time coding with this style of delimiters to get over their initial > aversion has agreed the prominence of all caps makes the code structure > easier to see quickly. Even Ada programmers who had significant prior > experience in Modula-2 have preferred all caps in Ada (Ada is case- > insensitive, so you can do it as you please.) > > As for readability, I recall seeing research some years back that > showed all caps are less readable than lower case, that is, people > read all caps slower and/or with less accuracy. For the delimiters, > prominence is more important, especially since their vocabulary is > far smaller than that of identifiers and doesn't change from program > to program. As long as you don't have both else and elsf as keywords in the same language! It works find in lower-case but is hopeless in upper. > As for esthetics, speaking for myself, after many years, I still think > all caps reserved words are uglier than mud fences, but I happily accept > that as the cost of easier scanning of code. > > It would be nice we had a standard character code that could handle > lower case, bold face, as in the Algol 60 "publication language". > That would be prominent and look great too. Really, there should be nothing preventing us from writing editors that display all-upper-case words as red lower-case words, and m3-to-ps converters that print them as bold-face lower-case. -- hendrik From hendrik at topoi.pooq.com Sat Feb 16 01:25:15 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 15 Feb 2008 19:25:15 -0500 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <200802152351.m1FNphNp033913@camembert.async.caltech.edu> References: <25955172-E857-4B24-8D51-3701C7353687@darko.org> <200802152351.m1FNphNp033913@camembert.async.caltech.edu> Message-ID: <20080216002515.GC4216@topoi.pooq.com> On Fri, Feb 15, 2008 at 03:51:43PM -0800, Mika Nystrom wrote: > Darko writes: > > This is getting a bit silly, and I apologize to everyone reading this > about wasting their time, but I just have to show you the following > file. It is a header file from the original sources of "sh" > (this copy is from 4.3 TAHOE UNIX, but of course the code is much > older than that). > > After that, blok.c, an example of "Bournegol" in use. > > So, you want the opposite, huh? Yeah. Steve Bourne did an Algol 68 variant in Cambridge before he went to Bell Labs. He did his bit here to make C look more like Algol 68C. Except A68 allows things to be a lot more terse than here. I think A68 had the right idea about syntax. Except that it was horrible to parse. -- hendrik From darko at darko.org Sat Feb 16 08:30:29 2008 From: darko at darko.org (Darko) Date: Sat, 16 Feb 2008 18:30:29 +1100 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <200802152351.m1FNphNp033913@camembert.async.caltech.edu> References: <200802152351.m1FNphNp033913@camembert.async.caltech.edu> Message-ID: <5765973E-2C31-41C4-A178-80C1D712D40A@darko.org> I'm not sure what you're getting at or if I'm missing something witty. I've said the form of the keywords makes little or no difference in my opinion. In my mail you quote I say there should be a C like syntax for M3 as well as the existing one. I wasn't being sarcastic. It's a matter of taste. I write in both all the time and it doesn't have any impact on me, I go almost entirely by indentation, which I think is very important. The indentation is pretty awful in code you posted but it could me my mailer. On 16/02/2008, at 10:51 AM, Mika Nystrom wrote: > Darko writes: >> I'm sticking to my view about lexical arbitrariness, but on that >> basis, I'd really like to see an alternate syntax for M3, one that >> looks almost exactly like C, but roughly keeps the existing statement >> form. I think it would make the language much more palatable to C >> programmers and the like and would remove what is a silly barrier to >> broader adaption. We could call the syntax 'Modula-C'. > > This is getting a bit silly, and I apologize to everyone reading this > about wasting their time, but I just have to show you the following > file. It is a header file from the original sources of "sh" > (this copy is from 4.3 TAHOE UNIX, but of course the code is much > older than that). > > After that, blok.c, an example of "Bournegol" in use. > > So, you want the opposite, huh? > > Mika > > > /* mac.h 4.3 87/10/26 */ > > # > /* > * UNIX shell > * > * S. R. Bourne > * Bell Telephone Laboratories > * > */ > > #define LOCAL static > #define PROC extern > #define TYPE typedef > #define STRUCT TYPE struct > #define UNION TYPE union > #define REG register > > #define IF if( > #define THEN ){ > #define ELSE } else { > #define ELIF } else if ( > #define FI ;} > > #define BEGIN { > #define END } > #define SWITCH switch( > #define IN ){ > #define ENDSW } > #define FOR for( > #define WHILE while( > #define DO ){ > #define OD ;} > #define REP do{ > #define PER }while( > #undef DONE > #define DONE ); > #define LOOP for(;;){ > #define POOL } > > > #define SKIP ; > #define DIV / > #define REM % > #define NEQ ^ > #define ANDF && > #define ORF || > > #define TRUE (-1) > #define FALSE 0 > #define LOBYTE 0377 > #define STRIP 0177 > #define QUOTE 0200 > > #define EOF 0 > #define NL '\n' > #define SP ' ' > #define LQ '`' > #define RQ '\'' > #define MINUS '-' > #define COLON ':' > > > > #ifndef lint > static char sccsid[] = "@(#)blok.c 4.2 8/11/83"; > #endif > > # > /* > * UNIX shell > * > * S. R. Bourne > * Bell Telephone Laboratories > * > */ > > #include "defs.h" > > > /* > * storage allocator > * (circular first fit strategy) > */ > > #define BUSY 01 > #define busy(x) (Rcheat((x)->word)&BUSY) > > POS brkincr=BRKINCR; > BLKPTR blokp; /*current search pointer*/ > BLKPTR bloktop=BLK(end); /*top of arena (last blok)*/ > > > > ADDRESS alloc(nbytes) > POS nbytes; > { > REG POS rbytes = round(nbytes+BYTESPERWORD,BYTESPERWORD); > > LOOP INT c=0; > REG BLKPTR p = blokp; > REG BLKPTR q; > REP IF !busy(p) > THEN WHILE !busy(q = p->word) DO p->word = q->word OD > IF ADR(q)-ADR(p) >= rbytes > THEN blokp = BLK(ADR(p)+rbytes); > IF q > blokp > THEN blokp->word = p->word; > FI > p->word=BLK(Rcheat(blokp)|BUSY); > return(ADR(p+1)); > FI > FI > q = p; p = BLK(Rcheat(p->word)&~BUSY); > PER p>q ORF (c++)==0 DONE > addblok(rbytes); > POOL > } > > VOID addblok(reqd) > POS reqd; > { > IF stakbas!=staktop > THEN REG STKPTR rndstak; > REG BLKPTR blokstak; > > pushstak(0); > rndstak=round(staktop,BYTESPERWORD); > blokstak=BLK(stakbas)-1; > blokstak->word=stakbsy; stakbsy=blokstak; > bloktop->word=BLK(Rcheat(rndstak)|BUSY); > bloktop=BLK(rndstak); > FI > reqd += brkincr; reqd &= ~(brkincr-1); > blokp=bloktop; > bloktop=bloktop->word=BLK(Rcheat(bloktop)+reqd); > bloktop->word=BLK(ADR(end)+1); > BEGIN > REG STKPTR stakadr=STK(bloktop+2); > staktop=movstr(stakbot,stakadr); > stakbas=stakbot=stakadr; > END > } > > VOID free(ap) > BLKPTR ap; > { > REG BLKPTR p; > > IF (p=ap) ANDF p THEN Lcheat((--p)->word) &= ~BUSY; > FI > } > > #ifdef DEBUG > chkbptr(ptr) > BLKPTR ptr; > { > INT exf=0; > REG BLKPTR p = end; > REG BLKPTR q; > INT us=0, un=0; > > LOOP > q = Rcheat(p->word)&~BUSY; > IF p==ptr THEN exf++ FI > IF qbloktop THEN abort(3) FI > IF p==bloktop THEN break FI > IF busy(p) > THEN us += q-p; > ELSE un += q-p; > FI > IF p>=q THEN abort(4) FI > p=q; > POOL > IF exf==0 THEN abort(1) FI > prn(un); prc(SP); prn(us); prc(NL); > } > #endif From jayk123 at hotmail.com Sat Feb 16 08:34:27 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 16 Feb 2008 07:34:27 +0000 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <5765973E-2C31-41C4-A178-80C1D712D40A@darko.org> References: <200802152351.m1FNphNp033913@camembert.async.caltech.edu> <5765973E-2C31-41C4-A178-80C1D712D40A@darko.org> Message-ID: > The indentation is pretty awful in code you posted but > it could me my mailer. Yep..it was eight space tabs at every level for me. - Jay _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Sat Feb 16 10:42:28 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Sat, 16 Feb 2008 01:42:28 -0800 Subject: [M3devel] "target specific pragmas"? In-Reply-To: Your message of "Sat, 16 Feb 2008 18:30:29 +1100." <5765973E-2C31-41C4-A178-80C1D712D40A@darko.org> Message-ID: <200802160942.m1G9gS0r048290@camembert.async.caltech.edu> "If Steve Bourne could turn C into Algol using cpp, I'm sure you can figure out how to turn Algol[Modula] back into C using <...>"... If you think it would help acceptance of Modula-3, I don't see why not? I copied the code exactly the way it came off the old half-inch tape from Berkeley. Darko writes: >I'm not sure what you're getting at or if I'm missing something witty. >I've said the form of the keywords makes little or no difference in my >opinion. In my mail you quote I say there should be a C like syntax >for M3 as well as the existing one. I wasn't being sarcastic. It's a >matter of taste. I write in both all the time and it doesn't have any >impact on me, I go almost entirely by indentation, which I think is >very important. The indentation is pretty awful in code you posted but >it could me my mailer. > >On 16/02/2008, at 10:51 AM, Mika Nystrom wrote: ... From darko at darko.org Sat Feb 16 11:10:40 2008 From: darko at darko.org (Darko) Date: Sat, 16 Feb 2008 21:10:40 +1100 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <200802160942.m1G9gS0r048290@camembert.async.caltech.edu> References: <200802160942.m1G9gS0r048290@camembert.async.caltech.edu> Message-ID: <57422B50-5EDC-498B-88C6-4D2C9CFE92C7@darko.org> If you like the idea, maybe you'd like join me in working out what such a syntax would look like? Note that I want to keep the structure the same, so no assignments in expressions, for example. Also, would C programmers revolt at not having post and pre increment, also inside expressions (as statements would be ok)? Requiring some sort of EVAL statement? I guess the big question is whether removing these things would make the whole idea unacceptable to the target audience. Does the Algol syntax serve a purpose in making it clear that it isn't C? On 16/02/2008, at 8:42 PM, Mika Nystrom wrote: > > "If Steve Bourne could turn C into Algol using cpp, I'm sure you > can figure out how to turn Algol[Modula] back into C using <...>"... > > If you think it would help acceptance of Modula-3, I don't see why > not? > > I copied the code exactly the way it came off the old half-inch > tape from Berkeley. > > Darko writes: >> I'm not sure what you're getting at or if I'm missing something >> witty. >> I've said the form of the keywords makes little or no difference in >> my >> opinion. In my mail you quote I say there should be a C like syntax >> for M3 as well as the existing one. I wasn't being sarcastic. It's a >> matter of taste. I write in both all the time and it doesn't have any >> impact on me, I go almost entirely by indentation, which I think is >> very important. The indentation is pretty awful in code you posted >> but >> it could me my mailer. >> >> On 16/02/2008, at 10:51 AM, Mika Nystrom wrote: > ... From jayk123 at hotmail.com Sat Feb 16 20:30:01 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 16 Feb 2008 19:30:01 +0000 Subject: [M3devel] NT386GNU status/fishing for guesses.. In-Reply-To: <47B4CFA9.2060400@wichita.edu> References: "Your message of Tue, 12 Feb 2008 18:54:50 EST." <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> <47B2E62D.1E75.00D7.1@scires.com> <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> <47B4CFA9.2060400@wichita.edu> Message-ID: PROCEDURE ExecChild( argx: ArrCStr; (* see "AllocArgs" for layout *) envp: Ctypes.char_star_star; wdstr: Ctypes.char_star; stdin, stdout, stderr: INTEGER) : INTEGER RAISES {} =(* Modify Unix state using "stdin", ..., and invoke execve using "argx" and "envp". Do not invoke scheduler, allocator, or exceptions. Return only if a fatal Unix error is encountered, in which case Cerrno.GetErrno() is set. *) VAR res := 0; t: Ctypes.char_star; BEGIN IF wdstr # NIL THEN IF Unix.chdir(wdstr) < 0 THEN RETURN -1; END END;(* IF NOT (SetFd(0, stdin) AND SetFd(1, stdout) AND SetFd(2, stderr)) THEN RETURN -1; END; FOR fd := 3 TO Unix.getdtablesize() - 1 DO EVAL Unix.close(fd) (* ignore errors *) END;*) Without those lines commented out, only ever one file gets compiled. The process create for the second cm3cg fails (but not for the first as). Nearby code uses 99 for the exit code. With these commented out, it proceeds to compile everything (at least in one directory). Some combinations of the one block vs. the other (I realize there's only four cominations total) go and compile everything but claim failure at the end. Different point is that subsequent runs of cm3 always recompile everything. Probably the timestamps are misunderstood. I need to check the stat structure. Any one have any wild guesses on the process create angle? I figured this out with strace. The SetFd calls lead to dup failing because 0 isn't open. The Cygwin code is all very gnarly. For example when you do vfork + exec, it seems to relaunch the current .executable first (with kernel32.dll CreateProcess) and then child executables -- running cm3cg+as on just one file takes six CreateProcess calls -- cm3, sh, cm3cg, cm3, sh, as. I wonder if "Services for Unix" would satisfy folks at least as well as Cygwin. It is a free (beer) download.. - Jay _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat Feb 16 20:37:46 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 16 Feb 2008 19:37:46 +0000 Subject: [M3devel] NT386GNU status/fishing for guesses.. In-Reply-To: References: "Your message of Tue, 12 Feb 2008 18:54:50 EST." <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> <47B2E62D.1E75.00D7.1@scires.com> <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> <47B4CFA9.2060400@wichita.edu> Message-ID: Ok, is this reasonable for all platforms? Otherwise I can push into Unix.m3. ===================================================================RCS file: /usr/cvs/cm3/m3-libs/libm3/src/os/POSIX/ProcessPosix.m3,vretrieving revision 1.6diff -u -r1.6 ProcessPosix.m3--- ProcessPosix.m3 29 Nov 2007 05:05:56 -0000 1.6+++ ProcessPosix.m3 16 Feb 2008 19:36:08 -0000@@ -266,6 +266,9 @@ (* Make file descriptor "fd" refer to file "h", or set "fd"'s close-on-exec flag if "h=NoFile". Return "TRUE" if succesful. *) BEGIN+ IF fd = h THEN+ RETURN TRUE;+ END; IF h # NoFileDescriptor THEN RETURN NOT Unix.dup2(h, fd) < 0 ELSIF Unix.fcntl(fd, Unix.F_SETFD, 1) >= 0 THEN - Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Sat, 16 Feb 2008 19:30:01 +0000Subject: [M3devel] NT386GNU status/fishing for guesses.. PROCEDURE ExecChild( argx: ArrCStr; (* see "AllocArgs" for layout *) envp: Ctypes.char_star_star; wdstr: Ctypes.char_star; stdin, stdout, stderr: INTEGER) : INTEGER RAISES {} =(* Modify Unix state using "stdin", ..., and invoke execve using "argx" and "envp". Do not invoke scheduler, allocator, or exceptions. Return only if a fatal Unix error is encountered, in which case Cerrno.GetErrno() is set. *) VAR res := 0; t: Ctypes.char_star; BEGIN IF wdstr # NIL THEN IF Unix.chdir(wdstr) < 0 THEN RETURN -1; END END;(* IF NOT (SetFd(0, stdin) AND SetFd(1, stdout) AND SetFd(2, stderr)) THEN RETURN -1; END; FOR fd := 3 TO Unix.getdtablesize() - 1 DO EVAL Unix.close(fd) (* ignore errors *) END;*)Without those lines commented out, only ever one file gets compiled.The process create for the second cm3cg fails (but not for the first as).Nearby code uses 99 for the exit code. With these commented out, it proceeds to compile everything (at least in one directory). Some combinations of the one block vs. the other (I realize there's only four cominations total) go and compile everything but claim failure at the end. Different point is that subsequent runs of cm3 always recompile everything.Probably the timestamps are misunderstood. I need to check the stat structure. Any one have any wild guesses on the process create angle?I figured this out with strace.The SetFd calls lead to dup failing because 0 isn't open. The Cygwin code is all very gnarly.For example when you do vfork + exec, it seems to relaunch the current .executable first (with kernel32.dll CreateProcess) and then child executables -- running cm3cg+as on just one file takes six CreateProcess calls -- cm3, sh, cm3cg, cm3, sh, as. I wonder if "Services for Unix" would satisfy folks at least as well as Cygwin. It is a free (beer) download.. - Jay Need to know the score, the latest news, or you need your Hotmail?-get your "fix". Check it out. _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat Feb 16 21:31:53 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 16 Feb 2008 20:31:53 +0000 Subject: [M3devel] FW: NT386GNU status/fishing for guesses.. In-Reply-To: References: "Your message of Tue, 12 Feb 2008 18:54:50 EST." <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> <47B2E62D.1E75.00D7.1@scires.com> <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> <47B4CFA9.2060400@wichita.edu> Message-ID: seems to have gotten truncated.. From: jayk123 at hotmail.comTo: m3devel at elegosoft.comSubject: RE: [M3devel] NT386GNU status/fishing for guesses..Date: Sat, 16 Feb 2008 19:37:46 +0000 Ok, is this reasonable for all platforms? Otherwise I can push into Unix.m3. ===================================================================RCS file: /usr/cvs/cm3/m3-libs/libm3/src/os/POSIX/ProcessPosix.m3,vretrieving revision 1.6diff -u -r1.6 ProcessPosix.m3--- ProcessPosix.m3 29 Nov 2007 05:05:56 -0000 1.6+++ ProcessPosix.m3 16 Feb 2008 19:36:08 -0000@@ -266,6 +266,9 @@ (* Make file descriptor "fd" refer to file "h", or set "fd"'s close-on-exec flag if "h=NoFile". Return "TRUE" if succesful. *) BEGIN+ IF fd = h THEN+ RETURN TRUE;+ END; IF h # NoFileDescriptor THEN RETURN NOT Unix.dup2(h, fd) < 0 ELSIF Unix.fcntl(fd, Unix.F_SETFD, 1) >= 0 THEN - Jay _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Sun Feb 17 06:43:38 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Sat, 16 Feb 2008 21:43:38 -0800 Subject: [M3devel] C-like syntax for Modula-3 [was Re: "target specific pragmas"?] In-Reply-To: Your message of "Sat, 16 Feb 2008 21:10:40 +1100." <57422B50-5EDC-498B-88C6-4D2C9CFE92C7@darko.org> Message-ID: <200802170543.m1H5hcuX077398@camembert.async.caltech.edu> Well I used to be mostly a C programmer but I long since weaned myself off that syntax :) Your point of the post- and pre-increment might be a bit difficult for C programmers to stomach, but... well it is probably hard to tell what programmers will hate and what they will love. Wouldn't a way to go about it be to take the Modula-3 BNF and modify the rules as needed? Would you like to be able to convert back and forth (why not), e.g., using m3tk (m3pp?)? You have to lower-case all the keywords, convert the braces appropriately (a bit tricky since Modula-3 has abandoned the Pascal/Algol FOR i := 0 TO 10 DO BEGIN END, so braces map only to the ENDs, not BEGINs (for the most part)). Type "attributes"(is that the right word?) are also an area where Modula-3 is significantly different from the C family. In C, you write int *a, *b, c; we have REF INTEGER a, b; INTEGER c; And arrays? VAR arr : REF ARRAY OF ARRAY [FIRST(SomeEnum)..LAST(SomeEnum)] OF ARecord; ARecord *arr[][first(SomeEnum)..last(SomeEnum)]; I prefer Algol syntax myself but I could definitely see that there might be people who would prefer a syntax mapped to C. One might be able to sneak Modula-3 into places where it wouldn't otherwise be used... Would it be possible to make "m3c" close enough in syntax that some simple C header files could be processed? Am I just being ridiculous now? A compiler that can process both C and Modula-3 in the same file? Python, by the way, provides some interesting hooks for C programs to interact with the Python garbage collector. Something similar could be done here. (But there is far less reason to write C code to plug into M3 than there is to write it to plug into Python.) Mika Darko writes: >If you like the idea, maybe you'd like join me in working out what >such a syntax would look like? Note that I want to keep the structure >the same, so no assignments in expressions, for example. Also, would C >programmers revolt at not having post and pre increment, also inside >expressions (as statements would be ok)? Requiring some sort of EVAL >statement? I guess the big question is whether removing these things >would make the whole idea unacceptable to the target audience. Does >the Algol syntax serve a purpose in making it clear that it isn't C? > > >On 16/02/2008, at 8:42 PM, Mika Nystrom wrote: > >> >> "If Steve Bourne could turn C into Algol using cpp, I'm sure you >> can figure out how to turn Algol[Modula] back into C using <...>"... >> >> If you think it would help acceptance of Modula-3, I don't see why >> not? >> >> I copied the code exactly the way it came off the old half-inch >> tape from Berkeley. >> >> Darko writes: >>> I'm not sure what you're getting at or if I'm missing something >>> witty. >>> I've said the form of the keywords makes little or no difference in >>> my >>> opinion. In my mail you quote I say there should be a C like syntax >>> for M3 as well as the existing one. I wasn't being sarcastic. It's a >>> matter of taste. I write in both all the time and it doesn't have any >>> impact on me, I go almost entirely by indentation, which I think is >>> very important. The indentation is pretty awful in code you posted >>> but >>> it could me my mailer. >>> >>> On 16/02/2008, at 10:51 AM, Mika Nystrom wrote: >> ... From hendrik at topoi.pooq.com Sun Feb 17 07:29:03 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sun, 17 Feb 2008 01:29:03 -0500 Subject: [M3devel] C-like syntax for Modula-3 [was Re: "target specific pragmas"?] In-Reply-To: <200802170543.m1H5hcuX077398@camembert.async.caltech.edu> References: <57422B50-5EDC-498B-88C6-4D2C9CFE92C7@darko.org> <200802170543.m1H5hcuX077398@camembert.async.caltech.edu> Message-ID: <20080217062903.GA24856@topoi.pooq.com> On Sat, Feb 16, 2008 at 09:43:38PM -0800, Mika Nystrom wrote: > > > Well I used to be mostly a C programmer but I long since weaned > myself off that syntax :) > > Your point of the post- and pre-increment might be a bit difficult > for C programmers to stomach, but... well it is probably hard to > tell what programmers will hate and what they will love. > > Wouldn't a way to go about it be to take the Modula-3 BNF and modify > the rules as needed? Would you like to be able to convert back and > forth (why not), e.g., using m3tk (m3pp?)? You have to lower-case > all the keywords, convert the braces appropriately (a bit tricky > since Modula-3 has abandoned the Pascal/Algol FOR i := 0 TO 10 DO > BEGIN END, so braces map only to the ENDs, not BEGINs (for the most > part)). > > Type "attributes"(is that the right word?) are also an area where > Modula-3 is significantly different from the C family. In C, you > write > > int *a, *b, c; > > we have > > REF INTEGER a, b; > INTEGER c; The declarator syntax in C was a mistake. Let's not perpetuate it. -- hendrik From jayk123 at hotmail.com Sun Feb 17 09:47:52 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 17 Feb 2008 08:47:52 +0000 Subject: [M3devel] NT386GNU status/fishing for guesses.. In-Reply-To: References: "Your message of Tue, 12 Feb 2008 18:54:50 EST." <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> <47B2E62D.1E75.00D7.1@scires.com> <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> <47B4CFA9.2060400@wichita.edu> Message-ID: Nevermind, of course, I should have known, even though I'm working on fixing the stat struct (probably to blame for files always being out of date) and thought I might have it right, I should have known, I have it too small and the next variable is getting overwritten, causing us to close(0).. If I put in arbitrary large padding at the end, it grows enough to cover up the problem..now to get it right.. null_fd and the entire struct stat need not be globals, just the dev field...of course optimize that and I would have a stack corruption instead, not sure it would have been harder or easier to figure out..I should have started at the bottom of the system and gotten all the headers right in the first place....sigh. VAR null_done := FALSE; null_stat: Ustat.struct_stat; null_fd: INTEGER; PROCEDURE IsDevNull(READONLY statbuf: Ustat.struct_stat): BOOLEAN RAISES {} = VAR result: INTEGER; BEGIN IF NOT null_done THEN null_done := TRUE; null_fd := Unix.open( M3toC.FlatTtoS("/dev/null"), Unix.O_RDONLY, Unix.Mrwrwrw); IF null_fd < 0 THEN RETURN FALSE END; RTIO.PutText("1 null_fd is " & Fmt.Int(null_fd) & "\n"); 3 result := Ustat.fstat(null_fd, ADR(null_stat)); RTIO.PutText("2 null_fd is " & Fmt.Int(null_fd) & "\n"); 0 EVAL Unix.close(null_fd); and then close 0 here oops IF result # 0 THEN null_fd := -1 END From: jayk123 at hotmail.comTo: m3devel at elegosoft.comSubject: RE: [M3devel] NT386GNU status/fishing for guesses..Date: Sat, 16 Feb 2008 19:37:46 +0000 Ok, is this reasonable for all platforms? Otherwise I can push into Unix.m3. ===================================================================RCS file: /usr/cvs/cm3/m3-libs/libm3/src/os/POSIX/ProcessPosix.m3,vretrieving revision 1.6diff -u -r1.6 ProcessPosix.m3--- ProcessPosix.m3 29 Nov 2007 05:05:56 -0000 1.6+++ ProcessPosix.m3 16 Feb 2008 19:36:08 -0000@@ -266,6 +266,9 @@ (* Make file descriptor "fd" refer to file "h", or set "fd"'s close-on-exec flag if "h=NoFile". Return "TRUE" if succesful. *) BEGIN+ IF fd = h THEN+ RETURN TRUE;+ END; IF h # NoFileDescriptor THEN RETURN NOT Unix.dup2(h, fd) < 0 ELSIF Unix.fcntl(fd, Unix.F_SETFD, 1) >= 0 THEN - Jay From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Sat, 16 Feb 2008 19:30:01 +0000Subject: [M3devel] NT386GNU status/fishing for guesses.. PROCEDURE ExecChild( argx: ArrCStr; (* see "AllocArgs" for layout *) envp: Ctypes.char_star_star; wdstr: Ctypes.char_star; stdin, stdout, stderr: INTEGER) : INTEGER RAISES {} =(* Modify Unix state using "stdin", ..., and invoke execve using "argx" and "envp". Do not invoke scheduler, allocator, or exceptions. Return only if a fatal Unix error is encountered, in which case Cerrno.GetErrno() is set. *) VAR res := 0; t: Ctypes.char_star; BEGIN IF wdstr # NIL THEN IF Unix.chdir(wdstr) < 0 THEN RETURN -1; END END;(* IF NOT (SetFd(0, stdin) AND SetFd(1, stdout) AND SetFd(2, stderr)) THEN RETURN -1; END; FOR fd := 3 TO Unix.getdtablesize() - 1 DO EVAL Unix.close(fd) (* ignore errors *) END;*)Without those lines commented out, only ever one file gets compiled.The process create for the second cm3cg fails (but not for the first as).Nearby code uses 99 for the exit code. With these commented out, it proceeds to compile everything (at least in one directory). Some combinations of the one block vs. the other (I realize there's only four cominations total) go and compile everything but claim failure at the end. Different point is that subsequent runs of cm3 always recompile everything.Probably the timestamps are misunderstood. I need to check the stat structure. Any one have any wild guesses on the process create angle?I figured this out with strace.The SetFd calls lead to dup failing because 0 isn't open. The Cygwin code is all very gnarly.For example when you do vfork + exec, it seems to relaunch the current .executable first (with kernel32.dll CreateProcess) and then child executables -- running cm3cg+as on just one file takes six CreateProcess calls -- cm3, sh, cm3cg, cm3, sh, as. I wonder if "Services for Unix" would satisfy folks at least as well as Cygwin. It is a free (beer) download.. - Jay Need to know the score, the latest news, or you need your Hotmail?-get your "fix". Check it out. Connect and share in new ways with Windows Live. Get it now! _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sun Feb 17 10:30:01 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 17 Feb 2008 10:30:01 +0100 Subject: [M3devel] NT386GNU status/fishing for guesses.. In-Reply-To: References: "Your message of Tue, 12 Feb 2008 18:54:50 EST." <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> <47B2E62D.1E75.00D7.1@scires.com> <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> <47B4CFA9.2060400@wichita.edu> Message-ID: <20080217103001.j246vor4qsoogg88@mail.elegosoft.com> Quoting Jay : > Nevermind, of course, I should have known, even though I'm working > on fixing the stat struct (probably to blame for files always being > out of date) and thought I might have it right, I should have known, > I have it too small and the next variable is getting overwritten, > causing us to close(0).. Yes, the C interfaces are the place where ports are most likely to be broken. There are no checks there; it's completely unsafe. I wonder if one could write a checker that compares the sizes of the most important structures in C and M3, but that would probably not be trivial. > If I put in arbitrary large padding at the end, it grows enough to > cover up the problem..now to get it right.. > null_fd and the entire struct stat need not be globals, just the dev > field...of course optimize that and I would have a stack corruption > instead, not sure it would have been harder or easier to figure > out..I should have started at the bottom of the system and gotten > all the headers right in the first place....sigh. Yes, it's always a good idea to get the base right at the start. On the other hand, you will usually return there during ant porting, regardless of your best efforts ;-) > VAR null_done := FALSE; null_stat: Ustat.struct_stat; null_fd: INTEGER; > > PROCEDURE IsDevNull(READONLY statbuf: Ustat.struct_stat): BOOLEAN > RAISES {} = VAR result: INTEGER; BEGIN IF NOT null_done THEN > null_done := TRUE; null_fd := Unix.open( > M3toC.FlatTtoS("/dev/null"), Unix.O_RDONLY, Unix.Mrwrwrw); IF > null_fd < 0 THEN RETURN FALSE END; RTIO.PutText("1 null_fd is " > & Fmt.Int(null_fd) & "\n"); 3 result := Ustat.fstat(null_fd, > ADR(null_stat)); RTIO.PutText("2 null_fd is " & > Fmt.Int(null_fd) & "\n"); 0 EVAL Unix.close(null_fd); > and then close 0 here oops IF result # 0 THEN null_fd := -1 END [Could you try to persuade your mailer to produce a readable text form besides HTML? If not it looks like that :-(] Anyway, as your previous posting asked about a change in general POSIX support files, I'd really advise you to try out such changes on at least one other platform (e.g. Linux), however innocuous they may seem. Thanks for all the work, Olaf -- Olaf Wagner -- elego Software Solutions GmbH 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 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jayk123 at hotmail.com Sun Feb 17 10:57:15 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 17 Feb 2008 09:57:15 +0000 Subject: [M3devel] NT386GNU status/fishing for guesses.. In-Reply-To: <20080217103001.j246vor4qsoogg88@mail.elegosoft.com> References: "Your message of Tue, 12 Feb 2008 18:54:50 EST." <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> <47B2E62D.1E75.00D7.1@scires.com> <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> <47B4CFA9.2060400@wichita.edu> <20080217103001.j246vor4qsoogg88@mail.elegosoft.com> Message-ID: No need for a change in platform-independent code now. My question was sort of "can anyone else try this out, I'm lazy". But I looked up the definition of dup/dup2 and decided Cygwin wasn't doing anything wrong, looked at the strace, saw we were closing 0, started some RTIO... and if IsDebuggerPresent, DebugBreak and finally realized of course what was happening. (the debugging options are really not good. I couldn't even see the globals in gdb, neither of the obvious names worked...I was doing a little debugging in cdb as well and found a crashing bug in it, very very very unusual) Writing a struct checker should actually be pretty easy. The trick is probably mainly to limit the dependencies so it can work when much of the system is broken, or to use a cross strategy if possible..it helps that NT386 supports two sort of platforms/targets/configurations, so you can cross with a smaller context switch. :) I'm not sure how to get field offsets in Modula-3 but if you get as far as having the compiler working, it can generate C with assertions as to sizes and offsets. The compiler's dependency on stat is "the problem". Again I like that idea of wrapping C in C, to expose a portable interface.Of course, it's inefficient. The direct exporting of C interfaces, when they are /correct/ is pretty efficient. NT386GNU should be just about "self hosting" now -- able to build a "min" distribution and then "upgrade". Small hacks in pylib.py needed that might break Win32, no big deal, it's "just the scripts". :) Next steps will be: a) consider changing the "naming conventions" it's still foo.lib and not foo.a, foo.dll and not foo.so. b) see if X Windows works (stuff builds) c) the small set and bitmap bugs (running the tests!) I do have one more commit to enable stuff, a small one, where the Slash is determine at runtime in slightly more code. SL is already determined at runtime, but M3Path maps naming convensions (foo.lib vs. libfoo.a, foo.dll vs. foo.so) to also determine slashes. It might even work if they were escaped, but what I have is a good solution. (if I figure I can ramble here, since I'm on topic. :) ) - Jay > Date: Sun, 17 Feb 2008 10:30:01 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] NT386GNU status/fishing for guesses..> > Quoting Jay :> > > Nevermind, of course, I should have known, even though I'm working > > on fixing the stat struct (probably to blame for files always being > > out of date) and thought I might have it right, I should have known, > > I have it too small and the next variable is getting overwritten, > > causing us to close(0)..> > Yes, the C interfaces are the place where ports are most likely to> be broken. There are no checks there; it's completely unsafe.> I wonder if one could write a checker that compares the sizes of> the most important structures in C and M3, but that would probably> not be trivial.> > > If I put in arbitrary large padding at the end, it grows enough to > > cover up the problem..now to get it right..> > null_fd and the entire struct stat need not be globals, just the dev > > field...of course optimize that and I would have a stack corruption > > instead, not sure it would have been harder or easier to figure > > out..I should have started at the bottom of the system and gotten > > all the headers right in the first place....sigh.> > Yes, it's always a good idea to get the base right at the start.> On the other hand, you will usually return there during ant porting,> regardless of your best efforts ;-)> > > VAR null_done := FALSE; null_stat: Ustat.struct_stat; null_fd: INTEGER;> >> > PROCEDURE IsDevNull(READONLY statbuf: Ustat.struct_stat): BOOLEAN > > RAISES {} = VAR result: INTEGER; BEGIN IF NOT null_done THEN > > null_done := TRUE; null_fd := Unix.open( > > M3toC.FlatTtoS("/dev/null"), Unix.O_RDONLY, Unix.Mrwrwrw); IF > > null_fd < 0 THEN RETURN FALSE END; RTIO.PutText("1 null_fd is " > > & Fmt.Int(null_fd) & "\n"); 3 result := Ustat.fstat(null_fd, > > ADR(null_stat)); RTIO.PutText("2 null_fd is " & > > Fmt.Int(null_fd) & "\n"); 0 EVAL Unix.close(null_fd); > > and then close 0 here oops IF result # 0 THEN null_fd := -1 END> > [Could you try to persuade your mailer to produce a readable text> form besides HTML? If not it looks like that :-(]> > Anyway, as your previous posting asked about a change in general POSIX> support files, I'd really advise you to try out such changes on at> least one other platform (e.g. Linux), however innocuous they may seem.> > Thanks for all the work,> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> 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> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Sun Feb 17 14:16:59 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sun, 17 Feb 2008 08:16:59 -0500 Subject: [M3devel] "target specific pragmas"? In-Reply-To: <76456592-EA52-4524-BEE1-02952371DF44@cs.purdue.edu> References: <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> <47B2E62D.1E75.00D7.1@scires.com> <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> <20080214091209.cvyfdwqgcok0swoc@mail.elegosoft.com> <76456592-EA52-4524-BEE1-02952371DF44@cs.purdue.edu> Message-ID: <20080217131659.GA25696@topoi.pooq.com> On Thu, Feb 14, 2008 at 12:31:50PM -0500, Tony Hosking wrote: > On Feb 14, 2008, at 3:12 AM, Olaf Wagner wrote: > > [...many other good comments deleted...] > > > >Multiple inheritance was left out of the language after long > >discussions because it was not really understood at that time. > >It may be that things have changed in this respect, but I still > >don't think it is. > > Multiple inheritance is fine so long as it encodes only type, but > *not* if it encodes representation as well. Witness single > inheritance for classes in Java, versus multiple inheritance for > interfaces in Java. That seems to be the general consensus these days. Multiple inheritance could still work under the constraint that no two ancestors provided different representations for any feature. I'd count separate definitions of a virtual function as different even if their code happens to be textually identical. Then an interface (like in Java) would be nothing but a class that has no representation. Then to build a class you could combine little chunks of representation, much as a linker combines little pieces of program. and multiple MODULEs can implement parts of the same INTERFACE. And by combining chunks chunks differently you could build classes with different behaviour. This would make more code-sharing is feasible, without a crisis in semantics. I could consider adding the following clause, because I think it would help modularity (though I'm not sure it's necessary): But if both ancestors have the same defined representation but they are ultimately inherited from the same definition, I'd count them as the same (though I could be argued out of this clause). Actully, I suppose this might be necessary because all objects inherit representation from OBJECT, and a general rule might be better than a special case for OBJECT. -- hendrik From wagner at elegosoft.com Sun Feb 17 14:31:38 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 17 Feb 2008 14:31:38 +0100 Subject: [M3devel] Integration of package-local tests Message-ID: <20080217143138.izfhuwm2yosw0g4w@mail.elegosoft.com> As some of you may have noticed, the regression test scope is increasing steadily though slowly. During recent days I tried to integrate the existing tests that are local to some packages. It's working this way: During a complete package build run with ./scripts/do-cm3-all.sh -report build all pacakges are compiled and the results reported on the web server (see http://www.opencm3.net/logs/package-status.html). For an easy overview, packages that compile OK are coloured green, packages with errors are red, and those unsupported on a certain platform are marked yellow. Recently a fourth column has been added which reports the results of tests if they are present. Tests are assumed if in the package root a sub directory test or tests exists, and if beneath that src/m3makefile is found. The fourth column will be yellow if this is not the case. If tests are present, they are compiled and (probably) run with cm3 -build -override -DROOT=$ROOT -DRUN A sample tests/src/m3makefile from package arithmetic looks like this: import("libm3") import("tempfiles") import("arithmetic") implementation("TestWordEx") implementation("TestBits") %[more test sources omitted] implementation("TestFunctional") Module("Test") program("test") if defined("RUN") r = q_exec( "." & SL & "test" ) write( CR, "program returned ", r, CR ) end The last four lines will run the compiled test executable. Of course, more complex setups are possible there. The test result column will be red if the tests do not compile or another fatal error is detected, orange, if something is output to stderr, and green in all other cases. At least for the actual test candidate an appropriate override should be defined like this: override("arithmetic", PACKAGE_DIR & SL & ".." & SL & "..") As usual, this should be done in the src/m3overrides file. To give a slightly more complex example, the tests for patternmatching are performed thus: if defined("RUN") r = q_exec( "." & SL & "test-regex -unix < .." & SL & "tests.input" ) write( CR, "program returned ", r, CR ) r = q_exec( "." & SL & "test-regex -unix < .." & SL & "testsdiffer.input" ) write( CR, "program returned ", r, CR ) end Here, two test runs are made with different input files. I'd like to encourage all contributors to adapt or extend their packages accordingly, so that more things can be automatically validated every night on miscellaneous platforms. Of course it would also be great if the encountered errors get fixed :-) Thanks for your attention and cooperation, Olaf PS: I'll attach one current package report file for those too lazy to follow the links ;-) PPS: Of course you can run the tests and generate the reports locally, too. During development I've used something like HTML_REPORT=/var/tmp/cm3-pkg-report-FreeBSD4-2008-02-17.html \ time ./scripts/do-cm3-all.sh -report build 2>&1 | tee plog to generate a complete report with a fixed name and log all actions in plog. PPPS: The actual implementation of report generation is in scripts/pkgmap.sh. So you can use -report with almost all build scripts. -- Olaf Wagner -- elego Software Solutions GmbH 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 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sun Feb 17 18:39:07 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 17 Feb 2008 18:39:07 +0100 Subject: [M3devel] Looking for CM3 Tinderbox regression test participants, was: Re: M3 concerns In-Reply-To: <20080131124304.w0aq9ygt2ckw4okc@mail.elegosoft.com> References: <477B7629.1E75.00D7.1@scires.com> <20080104221059.uwf80xrms0gw8880@mail.elegosoft.com> <063F2D47-D837-4E11-9001-D152527E8694@cs.purdue.edu> <20080105011335.n767h3zbz4gcgk4k@mail.elegosoft.com> <20080105011719.GA5064@topoi.pooq.com> <20080105143235.ujed2tl3ksogws8k@mail.elegosoft.com> <20080131124304.w0aq9ygt2ckw4okc@mail.elegosoft.com> Message-ID: <20080217183907.3senktul2cg44scw@mail.elegosoft.com> It's now more than two weeks since I asked for participants, and none but the elego tests have shown up in the tinderbox since then. So I think it may be time for a reminder :-) I don't want to hurry anyone, but if anything does not work as expected or described or someone needs help getting tinderbox reports transfered, don't hesitate to contact me. I'd really love to see more platforms than FreeBSD and Linux and the occasional DARWIN tested on a regular basis. Olaf PS: No need to apologize for anyone who maybe hasn't found the time yet to setup the test runs. I really understand that there are many more important matters. Quoting Olaf Wagner : > Quoting Olaf Wagner : >> o I think we have agreed on the fact that automatic regression testing >> would help and should be introduced. Tests should be run daily/nightly >> on as many platforms as possible, and results should be collected >> and made available via WWW (elego offers to host these services, as >> it does for CVS repositories and CM3 web access). > > As you've surely all seen in the Status section of > > http://modula3.elegosoft.com/cm3/ > > the Elego Tinderbox regression test framework for CM3 has now been > working for about two weeks. Though it's still not as complete and > stable as I'd like it to be, I think it is now the right time for others > to join the test framework and run the prepared tests in regular > intervals on their favourite platforms. The results can now be transfered > to Elego via your ssh account you also use for repository commits. > > Currently the tests are running on a Debian Linux system and a FreeBSD 6 > system at Elego, and now and then I'm starting a run on my MacOS X > laptop. The latter is not ideal for this purpose though. > > I'm now looking for other who would be willing to setup nightly tests > on their own servers. The following systems are of interest > > o PPC_DARWIN on MacOS X 10.4 or 10.5 > o I386_DARWIN > o SOLgnu on any Solaris version > o SOLsun " > o LINUXLIBC6 on RedHat, Fedora, Ubuntu, Suse Linux (have I forgotten > some variants?) > o NT386* on Windows 2000/XP/Vista > o NetBSD2_i386 > o FreeBSD4 on older FreeBSD systems (4.x, 5.x) and on current (7.0) > o PPC_LINUX (though this seems to be broken for some time) > o ALPHA_OSF -- is anybody still using Alphas? > > I think the other targets are more or less unused, but would of course not > object to test results for them. > > There's a short description by Kaspar Schleiser of how to participate in > cm3/scripts/regression/README. Basically you need to checkout the > scripts, install 5.4.0 manually once, and setup a cron job. > > We're mostly interested in the results of `tinderbox-build.sh cm3.build', > which is the complete bootstrap and release build based on 5.4.0, > as I think the lastok build need not run on all platforms. It's mainly > there to detect incompatible changes. > > The release build includes the package and m3tests tests. > > If you want to participate, I'd suggest to setup everything and run > it once without transferring your results, then enable the transfer > in cm3.build: > > tinderbox_mailer() { > true # needed if function is emtpy without this... > # to report to the elego tinderbox host, check README and uncomment this: > # cat "$1" | ssh tinderbox.elego.de "sudo -u tinderbox > /usr/local/tinderbox/tinderbox-cgi/processmail_builds.cgi" > } > > That's all. Please let me know in advance if you setup the tests, > > Olaf -- Olaf Wagner -- elego Software Solutions GmbH 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 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From rodney.bates at wichita.edu Sun Feb 17 19:04:44 2008 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Sun, 17 Feb 2008 12:04:44 -0600 Subject: [M3devel] <*LAZYALIGN*> In-Reply-To: <200802152338.m1FNc9gC033479@camembert.async.caltech.edu> References: <200802152338.m1FNc9gC033479@camembert.async.caltech.edu> Message-ID: <47B8773C.50803@wichita.edu> Well, in the case of pickles, there is not currently any known bit pattern to look for. Everything is either user's data, which must be allowed to be arbitrary, or pickle protocol stuff, which is already written in target-independent ways, so it wouldn't reveal anything. Adding a record of carefully designed, known type and content to the pickle header would work for general machine characteristics, but it's easier just to add a field to RTPacking values, which are binary-encoded in 32 bits in the existing header, with bits to spare. Similarly, for lazy aligned objects (where each type can be different), it's easiest just to add a bit type descriptions, which are also binary encoded. Mika Nystrom wrote: > Hi Rodney, > > I am not sure if I am reading your email entirely correctly, but I > think so... you're trying to figure out things like offsets so the > Pickle runtime can re-build arbitrary data structures. > > When we were doing some concurrent programming in my group about ten > years ago, we were using a user-level threading system (very similar > but not identical to the old user-level threads in M3) and we needed > to figure out the location of the stack pointer in a C jmp_buf. > > We just wrote a program to do it... > > Could you do that? Write some arbitrary data whose bit pattern > you know to a field, cast it to char * (or some such), and search > for the bit pattern? Do it over and over with random data, and there > you go... > > Mika > -- ------------------------------------------------------------- Rodney M. Bates, retired assistant professor Dept. of Computer Science, Wichita State University Wichita, KS 67260-0083 316-978-3922 rodney.bates at wichita.edu From wagner at elegosoft.com Sun Feb 17 19:03:17 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 17 Feb 2008 19:03:17 +0100 Subject: [M3devel] C-like syntax for Modula-3 [was Re: "target specific pragmas"?] In-Reply-To: <200802170543.m1H5hcuX077398@camembert.async.caltech.edu> References: <200802170543.m1H5hcuX077398@camembert.async.caltech.edu> Message-ID: <20080217190317.3206jk5xgks40skk@mail.elegosoft.com> I'd rather not go this way and change the complete syntax and convert to and fro between the two. If we really want to do that, I'd rather have it as something like a compatible extension (as far as possible). What about changing only the keywords from uppercase to lowercase and using {} instead of BEGIN END? I'm not sure if that would satisfy the C-adherents, and I'm also not sure if it would introduce syntactic ambiguities, as {} are also used for sets. I'd like to keep the changes to the syntactical structure minimal (upper- and lowercase is only lexical matter after all). The abstract syntax should be kept as it is. If something like this would be possible, I'd vote for supporting both syntaxes in one compiler and turn on the C-style by a comment or automatically by recognizing the first word of a module. I'd not support mixing of styles within one module. Olaf PS: I'm not really suggesting we do this now, I just wanted to comment on the possibility of doing something like this. Anyway it will depend on somebody who provides appropriate patches and updates the language specification etc. Quoting Mika Nystrom : > Well I used to be mostly a C programmer but I long since weaned > myself off that syntax :) > > Your point of the post- and pre-increment might be a bit difficult > for C programmers to stomach, but... well it is probably hard to > tell what programmers will hate and what they will love. > > Wouldn't a way to go about it be to take the Modula-3 BNF and modify > the rules as needed? Would you like to be able to convert back and > forth (why not), e.g., using m3tk (m3pp?)? You have to lower-case > all the keywords, convert the braces appropriately (a bit tricky > since Modula-3 has abandoned the Pascal/Algol FOR i := 0 TO 10 DO > BEGIN END, so braces map only to the ENDs, not BEGINs (for the most > part)). > > Type "attributes"(is that the right word?) are also an area where > Modula-3 is significantly different from the C family. In C, you > write > > int *a, *b, c; > > we have > > REF INTEGER a, b; > INTEGER c; > > And arrays? > > VAR arr : REF ARRAY OF ARRAY [FIRST(SomeEnum)..LAST(SomeEnum)] OF ARecord; > > ARecord *arr[][first(SomeEnum)..last(SomeEnum)]; > > I prefer Algol syntax myself but I could definitely see that there > might be people who would prefer a syntax mapped to C. One might > be able to sneak Modula-3 into places where it wouldn't otherwise > be used... > > Would it be possible to make "m3c" close enough in syntax that some > simple C header files could be processed? Am I just being ridiculous > now? A compiler that can process both C and Modula-3 in the same > file? > > Python, by the way, provides some interesting hooks for C programs > to interact with the Python garbage collector. Something similar > could be done here. (But there is far less reason to write C code > to plug into M3 than there is to write it to plug into Python.) > > Mika > > > Darko writes: >> If you like the idea, maybe you'd like join me in working out what >> such a syntax would look like? Note that I want to keep the structure >> the same, so no assignments in expressions, for example. Also, would C >> programmers revolt at not having post and pre increment, also inside >> expressions (as statements would be ok)? Requiring some sort of EVAL >> statement? I guess the big question is whether removing these things >> would make the whole idea unacceptable to the target audience. Does >> the Algol syntax serve a purpose in making it clear that it isn't C? >> >> >> On 16/02/2008, at 8:42 PM, Mika Nystrom wrote: >> >>> >>> "If Steve Bourne could turn C into Algol using cpp, I'm sure you >>> can figure out how to turn Algol[Modula] back into C using <...>"... >>> >>> If you think it would help acceptance of Modula-3, I don't see why >>> not? >>> >>> I copied the code exactly the way it came off the old half-inch >>> tape from Berkeley. >>> >>> Darko writes: >>>> I'm not sure what you're getting at or if I'm missing something >>>> witty. >>>> I've said the form of the keywords makes little or no difference in >>>> my >>>> opinion. In my mail you quote I say there should be a C like syntax >>>> for M3 as well as the existing one. I wasn't being sarcastic. It's a >>>> matter of taste. I write in both all the time and it doesn't have any >>>> impact on me, I go almost entirely by indentation, which I think is >>>> very important. The indentation is pretty awful in code you posted >>>> but >>>> it could me my mailer. >>>> >>>> On 16/02/2008, at 10:51 AM, Mika Nystrom wrote: >>> ... > -- Olaf Wagner -- elego Software Solutions GmbH 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 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Sun Feb 17 19:11:39 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 17 Feb 2008 13:11:39 -0500 Subject: [M3devel] C-like syntax for Modula-3 [was Re: "target specific pragmas"?] In-Reply-To: <20080217190317.3206jk5xgks40skk@mail.elegosoft.com> References: <200802170543.m1H5hcuX077398@camembert.async.caltech.edu> <20080217190317.3206jk5xgks40skk@mail.elegosoft.com> Message-ID: Not to rain on this parade, but I hate the idea of Swiss-Army-knife programs that do a multitude of tasks. Better to have a program do one thing well (and correctly) than many things badly (incorrectly). So the notion of one compiler handling two syntaxes does not sit well with me. Why not just a preprocessor from C-like syntax, which observes Modula-3 typing and semantics, into regular Modula-3? But, I echo Olaf's point -- there are way more important things to be worrying about than the color of the ceiling tiles, or in this case syntactic sugar. On Feb 17, 2008, at 1:03 PM, Olaf Wagner wrote: > I'd rather not go this way and change the complete syntax and > convert to and fro between the two. If we really want to do that, > I'd rather have it as something like a compatible extension (as far > as possible). > > What about changing only the keywords from uppercase to lowercase > and using {} instead of BEGIN END? I'm not sure if that would > satisfy the C-adherents, and I'm also not sure if it would > introduce syntactic ambiguities, as {} are also used for sets. > I'd like to keep the changes to the syntactical structure minimal > (upper- and lowercase is only lexical matter after all). The abstract > syntax should be kept as it is. > > If something like this would be possible, I'd vote for supporting > both syntaxes in one compiler and turn on the C-style by a comment > or automatically by recognizing the first word of a module. I'd not > support mixing of styles within one module. > > Olaf > > PS: I'm not really suggesting we do this now, I just wanted to comment > on the possibility of doing something like this. Anyway it will > depend on somebody who provides appropriate patches and updates > the language specification etc. > > Quoting Mika Nystrom : > >> Well I used to be mostly a C programmer but I long since weaned >> myself off that syntax :) >> >> Your point of the post- and pre-increment might be a bit difficult >> for C programmers to stomach, but... well it is probably hard to >> tell what programmers will hate and what they will love. >> >> Wouldn't a way to go about it be to take the Modula-3 BNF and modify >> the rules as needed? Would you like to be able to convert back and >> forth (why not), e.g., using m3tk (m3pp?)? You have to lower-case >> all the keywords, convert the braces appropriately (a bit tricky >> since Modula-3 has abandoned the Pascal/Algol FOR i := 0 TO 10 DO >> BEGIN END, so braces map only to the ENDs, not BEGINs (for the most >> part)). >> >> Type "attributes"(is that the right word?) are also an area where >> Modula-3 is significantly different from the C family. In C, you >> write >> >> int *a, *b, c; >> >> we have >> >> REF INTEGER a, b; >> INTEGER c; >> >> And arrays? >> >> VAR arr : REF ARRAY OF ARRAY [FIRST(SomeEnum)..LAST(SomeEnum)] OF >> ARecord; >> >> ARecord *arr[][first(SomeEnum)..last(SomeEnum)]; >> >> I prefer Algol syntax myself but I could definitely see that there >> might be people who would prefer a syntax mapped to C. One might >> be able to sneak Modula-3 into places where it wouldn't otherwise >> be used... >> >> Would it be possible to make "m3c" close enough in syntax that some >> simple C header files could be processed? Am I just being ridiculous >> now? A compiler that can process both C and Modula-3 in the same >> file? >> >> Python, by the way, provides some interesting hooks for C programs >> to interact with the Python garbage collector. Something similar >> could be done here. (But there is far less reason to write C code >> to plug into M3 than there is to write it to plug into Python.) >> >> Mika >> >> >> Darko writes: >>> If you like the idea, maybe you'd like join me in working out what >>> such a syntax would look like? Note that I want to keep the >>> structure >>> the same, so no assignments in expressions, for example. Also, >>> would C >>> programmers revolt at not having post and pre increment, also inside >>> expressions (as statements would be ok)? Requiring some sort of EVAL >>> statement? I guess the big question is whether removing these things >>> would make the whole idea unacceptable to the target audience. Does >>> the Algol syntax serve a purpose in making it clear that it isn't C? >>> >>> >>> On 16/02/2008, at 8:42 PM, Mika Nystrom wrote: >>> >>>> >>>> "If Steve Bourne could turn C into Algol using cpp, I'm sure you >>>> can figure out how to turn Algol[Modula] back into C using >>>> <...>"... >>>> >>>> If you think it would help acceptance of Modula-3, I don't see why >>>> not? >>>> >>>> I copied the code exactly the way it came off the old half-inch >>>> tape from Berkeley. >>>> >>>> Darko writes: >>>>> I'm not sure what you're getting at or if I'm missing something >>>>> witty. >>>>> I've said the form of the keywords makes little or no >>>>> difference in >>>>> my >>>>> opinion. In my mail you quote I say there should be a C like >>>>> syntax >>>>> for M3 as well as the existing one. I wasn't being sarcastic. >>>>> It's a >>>>> matter of taste. I write in both all the time and it doesn't >>>>> have any >>>>> impact on me, I go almost entirely by indentation, which I >>>>> think is >>>>> very important. The indentation is pretty awful in code you posted >>>>> but >>>>> it could me my mailer. >>>>> >>>>> On 16/02/2008, at 10:51 AM, Mika Nystrom wrote: >>>> ... >> > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > 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 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > From hendrik at topoi.pooq.com Sun Feb 17 19:58:41 2008 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sun, 17 Feb 2008 13:58:41 -0500 Subject: [M3devel] C-like syntax for Modula-3 [was Re: "target specific pragmas"?] In-Reply-To: References: <200802170543.m1H5hcuX077398@camembert.async.caltech.edu> <20080217190317.3206jk5xgks40skk@mail.elegosoft.com> Message-ID: <20080217185841.GA27354@topoi.pooq.com> On Sun, Feb 17, 2008 at 01:11:39PM -0500, Tony Hosking wrote: > Not to rain on this parade, but I hate the idea of Swiss-Army-knife > programs that do a multitude of tasks. Better to have a program do > one thing well (and correctly) than many things badly (incorrectly). > So the notion of one compiler handling two syntaxes does not sit well > with me. Why not just a preprocessor from C-like syntax, which > observes Modula-3 typing and semantics, into regular Modula-3? But, > I echo Olaf's point -- there are way more important things to be > worrying about than the color of the ceiling tiles, or in this case > syntactic sugar. Even with a preprocessor from C-style syntax to Modula 3, there would have to be some mechanism inserted into the Modula 3 compiler to recognise the original line numbers for error messages and debuggers and the like. Doing it this way might also make it possible to unify the Eiffel and Modula 3 communities ... though tere are possible better ways to accomplish this. I've always thought there's a lot of duplication of effort in their run-time systems. -- hendrik From lemming at henning-thielemann.de Sun Feb 17 21:27:47 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sun, 17 Feb 2008 21:27:47 +0100 (MET) Subject: [M3devel] C-like syntax for Modula-3 In-Reply-To: References: <200802170543.m1H5hcuX077398@camembert.async.caltech.edu> <20080217190317.3206jk5xgks40skk@mail.elegosoft.com> Message-ID: On Sun, 17 Feb 2008, Tony Hosking wrote: > Not to rain on this parade, but I hate the idea of Swiss-Army-knife > programs that do a multitude of tasks. Better to have a program do > one thing well (and correctly) than many things badly (incorrectly). > So the notion of one compiler handling two syntaxes does not sit well > with me. Why not just a preprocessor from C-like syntax, which > observes Modula-3 typing and semantics, into regular Modula-3? But, > I echo Olaf's point -- there are way more important things to be > worrying about than the color of the ceiling tiles, or in this case > syntactic sugar. I see no need for Modula-3 with C syntax. I thought Java was created for this purpose. I collected a long list of C flaws, many of them are due to C syntax. From lemming at henning-thielemann.de Sun Feb 17 21:39:04 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sun, 17 Feb 2008 21:39:04 +0100 (MET) Subject: [M3devel] multiple inheritance In-Reply-To: <20080217131659.GA25696@topoi.pooq.com> References: <200802130037.m1D0bhaN014478@camembert.async.caltech.edu> <47B2E62D.1E75.00D7.1@scires.com> <271CC44A-2E61-400E-A70B-9EFE0AAAF649@darko.org> <20080214091209.cvyfdwqgcok0swoc@mail.elegosoft.com> <76456592-EA52-4524-BEE1-02952371DF44@cs.purdue.edu> <20080217131659.GA25696@topoi.pooq.com> Message-ID: On Sun, 17 Feb 2008 hendrik at topoi.pooq.com wrote: > On Thu, Feb 14, 2008 at 12:31:50PM -0500, Tony Hosking wrote: > > On Feb 14, 2008, at 3:12 AM, Olaf Wagner wrote: > > > > [...many other good comments deleted...] > > > > > > >Multiple inheritance was left out of the language after long > > >discussions because it was not really understood at that time. > > >It may be that things have changed in this respect, but I still > > >don't think it is. Without knowing details I have heard that Eiffel has a satisfying implementation of multiple inheritance. However, since programming in Haskell I'm no longer missing traditional object oriented typing at all. From mika at async.caltech.edu Sun Feb 17 22:30:50 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 17 Feb 2008 13:30:50 -0800 Subject: [M3devel] C-like syntax for Modula-3 [was Re: "target specific pragmas"?] In-Reply-To: Your message of "Sun, 17 Feb 2008 13:58:41 EST." <20080217185841.GA27354@topoi.pooq.com> Message-ID: <200802172130.m1HLUoMd000557@camembert.async.caltech.edu> hendrik at topoi.pooq.com writes: >On Sun, Feb 17, 2008 at 01:11:39PM -0500, Tony Hosking wrote: >> Not to rain on this parade, but I hate the idea of Swiss-Army-knife >> programs that do a multitude of tasks. Better to have a program do >> one thing well (and correctly) than many things badly (incorrectly). >> So the notion of one compiler handling two syntaxes does not sit well >> with me. Why not just a preprocessor from C-like syntax, which >> observes Modula-3 typing and semantics, into regular Modula-3? But, >> I echo Olaf's point -- there are way more important things to be >> worrying about than the color of the ceiling tiles, or in this case >> syntactic sugar. > >Even with a preprocessor from C-style syntax to Modula 3, there would >have to be some mechanism inserted into the Modula 3 compiler to >recognise the original line numbers for error messages and debuggers and >the like. > >Doing it this way might also make it possible to unify the Eiffel and >Modula 3 communities ... though tere are possible better ways to >accomplish this. I've always thought there's a lot of duplication of >effort in their run-time systems. > >-- hendrik I agree entirely with Tony's comments. I think a preprocessor (two preprocessors M3-2-MC and MC-2-M3) would be the way to do it, and I really don't mind Algol syntax. But I can see the argument that it might really do something for "marketing". I believe the compiler already permits <* LINE *> pragmas?? I think I saw it in the caltech-parser? Also if you want to merge forces with another project, wouldn't a good way be to do as in Stallman's nightmares, and start by "selling" the compiler back ends to other languages? Mika From jayk123 at hotmail.com Mon Feb 18 05:03:23 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 18 Feb 2008 04:03:23 +0000 Subject: [M3devel] instructions for how to bring up a working NT386GNU toolset today Message-ID: This email has whitespace at the start/end of most lines in an attempt to preserve its formating. I already had cm3cg, and it is slow to rebuild. These instructions omit building that, but it is just build and ship in m3-sys\m3cc. Building m3cc does require a fair bit of Cygwin installed. Including but not limited to gcc, binutils, sed, make, awk. copy \cm3\bin\cm3cg.exe C:\cm3-min-WIN32-NT386-5.1.8\bin rmdir /q/s \cm3 xcopy /fivery C:\cm3-min-WIN32-NT386-5.1.8 c:\cm3 Older than 5.1.8 will not work. Setup a cm3/NT386 build environment, for example: set CM3_GCC_BACKEND=no set CM3_INSTALL=c:\cm3 set CM3_OSTYPE=WIN32 set CM3_ROOT=c:\dev2\cm3.2 set CM3_TARGET=NT386 set M3CONFIG=c:\dev2\cm3.2\m3-sys\cminstall\src\config\NT386 Almost none of these are needed, as they are probed for quite successfully. However this is what I am testing right now. Make sure Cygwin link.exe is not in %PATH%. I just delete it. del \cygwin\bin\link.exe I do actually have Cygwin always on my path, so there might be hidden dependencies on that. type \AUTOEXEC.BAT set CVS_RSH=ssh PATH %SystemDrive%\cygwin\bin;%PATH% There are also presently problems with slashes, such that managing M3CONFIG manually is a good idea for now. cd /d %cm3_root%\scripts\python .\do-cm3-all.py realclean .\upgrade.py In another cmd window, setup a CM3/NT386GNU environment, for example: set CM3_GCC_BACKEND=yes set CM3_INSTALL=/cm3 set CM3_OSTYPE=POSIX set CM3_ROOT=/dev2/cm3.2 set CM3_TARGET=NT386 set M3CONFIG=/dev2/cm3.2/m3-sys/cminstall/src/config/NT386GNU set OMIT_GCC=yes Again, this is largely redundant, but ok. What is most important is that CM3_OSTYPE=POSIX or that Cygwin uname is in the path. (Work is needed to cleanup this area that I have muddied over the past few months, including teaching cm3 that forward slashes work on Win32, except that won't help bootstrapping from 5.1.8) Also NOTE that I have symlinks setup for these paths to be correct: ls -l / lrwxrwxrwx 1 Jay None 11 Feb 10 01:10 c -> /cygdrive/c lrwxrwxrwx 1 Jay None 6 Feb 10 21:39 cm3 -> /c/cm3 lrwxrwxrwx 1 Jay None 7 Feb 10 01:10 dev2 -> /c/dev2 /cygdrive is long and ugly. .\do-cm3-all.py realclean Back in the NT386 environment: Point at the NT386GNU configuration file: set M3CONFIG=c:\dev2\cm3.2\m3-sys\cminstall\src\config\NT386GNU Build the minimum NT386GNU system using the NT386 host compiler: .\bootntgnu.py and then restore the configuration to "normal": set M3CONFIG=c:\dev2\cm3.2\m3-sys\cminstall\src\config\NT386 (Yeah yeah, to clean step should work here.) Back in the NT386GNU environment: .\install-cm3-compiler.py .\upgrade.py Done. Next step is to try make-dist.py. (It doesn't work.) Also note that do-cm3-std gets much further than these steps. But these are just to start and get your own "min" system. A crash in m3bundle needs investigation if is still happens. Lots of GUI stuff does build but I haven't tried running it yet. Also NOTE that the integrated backend should be viable for targeting the Cygwin runtime, and this will build MUCH faster. Of course, you must have current source for this to work. I have not yet run the tests, sorry Olaf. Anyone want to try this and report back how it goes? Please? - Jay _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx From hosking at cs.purdue.edu Mon Feb 18 05:16:06 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 17 Feb 2008 23:16:06 -0500 Subject: [M3devel] Looking for CM3 Tinderbox regression test participants, was: Re: M3 concerns In-Reply-To: <20080217183907.3senktul2cg44scw@mail.elegosoft.com> References: <477B7629.1E75.00D7.1@scires.com> <20080104221059.uwf80xrms0gw8880@mail.elegosoft.com> <063F2D47-D837-4E11-9001-D152527E8694@cs.purdue.edu> <20080105011335.n767h3zbz4gcgk4k@mail.elegosoft.com> <20080105011719.GA5064@topoi.pooq.com> <20080105143235.ujed2tl3ksogws8k@mail.elegosoft.com> <20080131124304.w0aq9ygt2ckw4okc@mail.elegosoft.com> <20080217183907.3senktul2cg44scw@mail.elegosoft.com> Message-ID: <776D06E2-D73F-47AB-ABA7-EE3FD5606403@cs.purdue.edu> Solaris does not have %s for date -- we need an alternative for that usage in tinderbox-build.sh. On Feb 17, 2008, at 12:39 PM, Olaf Wagner wrote: > It's now more than two weeks since I asked for participants, and > none but the elego tests have shown up in the tinderbox since then. > So I think it may be time for a reminder :-) > > I don't want to hurry anyone, but if anything does not work as > expected or described or someone needs help getting tinderbox > reports transfered, don't hesitate to contact me. I'd really love to > see more platforms than FreeBSD and Linux and the occasional DARWIN > tested on a regular basis. > > Olaf > > PS: No need to apologize for anyone who maybe hasn't found the time > yet > to setup the test runs. I really understand that there are many > more > important matters. > > Quoting Olaf Wagner : > >> Quoting Olaf Wagner : >>> o I think we have agreed on the fact that automatic regression >>> testing >>> would help and should be introduced. Tests should be run daily/ >>> nightly >>> on as many platforms as possible, and results should be collected >>> and made available via WWW (elego offers to host these >>> services, as >>> it does for CVS repositories and CM3 web access). >> >> As you've surely all seen in the Status section of >> >> http://modula3.elegosoft.com/cm3/ >> >> the Elego Tinderbox regression test framework for CM3 has now been >> working for about two weeks. Though it's still not as complete and >> stable as I'd like it to be, I think it is now the right time for >> others >> to join the test framework and run the prepared tests in regular >> intervals on their favourite platforms. The results can now be >> transfered >> to Elego via your ssh account you also use for repository commits. >> >> Currently the tests are running on a Debian Linux system and a >> FreeBSD 6 >> system at Elego, and now and then I'm starting a run on my MacOS X >> laptop. The latter is not ideal for this purpose though. >> >> I'm now looking for other who would be willing to setup nightly tests >> on their own servers. The following systems are of interest >> >> o PPC_DARWIN on MacOS X 10.4 or 10.5 >> o I386_DARWIN >> o SOLgnu on any Solaris version >> o SOLsun " >> o LINUXLIBC6 on RedHat, Fedora, Ubuntu, Suse Linux (have I forgotten >> some variants?) >> o NT386* on Windows 2000/XP/Vista >> o NetBSD2_i386 >> o FreeBSD4 on older FreeBSD systems (4.x, 5.x) and on current (7.0) >> o PPC_LINUX (though this seems to be broken for some time) >> o ALPHA_OSF -- is anybody still using Alphas? >> >> I think the other targets are more or less unused, but would of >> course not >> object to test results for them. >> >> There's a short description by Kaspar Schleiser of how to >> participate in >> cm3/scripts/regression/README. Basically you need to checkout the >> scripts, install 5.4.0 manually once, and setup a cron job. >> >> We're mostly interested in the results of `tinderbox-build.sh >> cm3.build', >> which is the complete bootstrap and release build based on 5.4.0, >> as I think the lastok build need not run on all platforms. It's >> mainly >> there to detect incompatible changes. >> >> The release build includes the package and m3tests tests. >> >> If you want to participate, I'd suggest to setup everything and run >> it once without transferring your results, then enable the transfer >> in cm3.build: >> >> tinderbox_mailer() { >> true # needed if function is emtpy without this... >> # to report to the elego tinderbox host, check README and >> uncomment this: >> # cat "$1" | ssh tinderbox.elego.de "sudo -u tinderbox >> /usr/local/tinderbox/tinderbox-cgi/processmail_builds.cgi" >> } >> >> That's all. Please let me know in advance if you setup the tests, >> >> Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > 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 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > From jayk123 at hotmail.com Mon Feb 18 05:26:17 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 18 Feb 2008 04:26:17 +0000 Subject: [M3devel] C-like syntax for Modula-3 [was Re: "target specific pragmas"?] In-Reply-To: <20080217190317.3206jk5xgks40skk@mail.elegosoft.com> References: <200802170543.m1H5hcuX077398@camembert.async.caltech.edu> <20080217190317.3206jk5xgks40skk@mail.elegosoft.com> Message-ID: I've been trying to stay out of this... If a comment at the top of the file can make the Modula-3 syntax more like C then.. replace = with == replace := with = make assignment an expression lowercase the keywords try to make braces work (with some alteration for C) use type name instead of name : type separate function parameters with commas and require each to state its type for that matter, subset C and require all declarations be separate like that? put back ++, --, -=, +=, etc. superset C and let . be used in place of -> new coding style is four space indent with opening braces on their own line :) Hm. I think if anyone really wants to do this, instead of nit picking about Modula-3 syntax here and there, go about it in a slightly different way? Pick apart what defines Modula-3 through much discussion. Optional safety -- probably but that for these purposes optional garbage collection -- maybe that too "object orientation" that is a subset of C++ try to use C++ syntax? generics (generic modules) independently and relatively easily parsable interface definitions (!) these are both important, but I think "independent" is more important and "relatively easily" could be omitted for the goals of this exercise compiles to native code sizeof(integer) == sizeof(address) (minor detail) built in sets and good enumerations arrays; I don't like them starting at non-zero, but enums for their index are interesting Take the existing definition of C and alter it to have these characteristics very very much like Modula-3 but with very very very much Modula-3 syntax. That is, this is a large exercise, but: if you keep optional safety, define what is safe, basically the same as in Modula-3 determine syntax for enums, arrays, sets Write a front end for it. Boom. Right there my patience wouldn't get far. Make it ABI compatible with Modula-3. Heck, start with the existing front end MAYBE. Compatibility with SOME existing code should be a goal. Compatibility with headers is problematic but very useful. This front end could help translation of headers to "independently parsable" form. (SWIG is the name of the thing someone mentioned the other day but had the name wrong.) Look into the D language. It might be just the ticket... you MIGHT find that it has all the aspects of Modula-3 that any of you desire, and more... - Jay > Date: Sun, 17 Feb 2008 19:03:17 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] C-like syntax for Modula-3 [was Re: "target specific pragmas"?]> > I'd rather not go this way and change the complete syntax and> convert to and fro between the two. If we really want to do that,> I'd rather have it as something like a compatible extension (as far> as possible).> > What about changing only the keywords from uppercase to lowercase> and using {} instead of BEGIN END? I'm not sure if that would> satisfy the C-adherents, and I'm also not sure if it would> introduce syntactic ambiguities, as {} are also used for sets.> I'd like to keep the changes to the syntactical structure minimal> (upper- and lowercase is only lexical matter after all). The abstract> syntax should be kept as it is.> > If something like this would be possible, I'd vote for supporting> both syntaxes in one compiler and turn on the C-style by a comment> or automatically by recognizing the first word of a module. I'd not> support mixing of styles within one module.> > Olaf> > PS: I'm not really suggesting we do this now, I just wanted to comment> on the possibility of doing something like this. Anyway it will> depend on somebody who provides appropriate patches and updates> the language specification etc.> > Quoting Mika Nystrom :> > > Well I used to be mostly a C programmer but I long since weaned> > myself off that syntax :)> >> > Your point of the post- and pre-increment might be a bit difficult> > for C programmers to stomach, but... well it is probably hard to> > tell what programmers will hate and what they will love.> >> > Wouldn't a way to go about it be to take the Modula-3 BNF and modify> > the rules as needed? Would you like to be able to convert back and> > forth (why not), e.g., using m3tk (m3pp?)? You have to lower-case> > all the keywords, convert the braces appropriately (a bit tricky> > since Modula-3 has abandoned the Pascal/Algol FOR i := 0 TO 10 DO> > BEGIN END, so braces map only to the ENDs, not BEGINs (for the most> > part)).> >> > Type "attributes"(is that the right word?) are also an area where> > Modula-3 is significantly different from the C family. In C, you> > write> >> > int *a, *b, c;> >> > we have> >> > REF INTEGER a, b;> > INTEGER c;> >> > And arrays?> >> > VAR arr : REF ARRAY OF ARRAY [FIRST(SomeEnum)..LAST(SomeEnum)] OF ARecord;> >> > ARecord *arr[][first(SomeEnum)..last(SomeEnum)];> >> > I prefer Algol syntax myself but I could definitely see that there> > might be people who would prefer a syntax mapped to C. One might> > be able to sneak Modula-3 into places where it wouldn't otherwise> > be used...> >> > Would it be possible to make "m3c" close enough in syntax that some> > simple C header files could be processed? Am I just being ridiculous> > now? A compiler that can process both C and Modula-3 in the same> > file?> >> > Python, by the way, provides some interesting hooks for C programs> > to interact with the Python garbage collector. Something similar> > could be done here. (But there is far less reason to write C code> > to plug into M3 than there is to write it to plug into Python.)> >> > Mika> >> >> > Darko writes:> >> If you like the idea, maybe you'd like join me in working out what> >> such a syntax would look like? Note that I want to keep the structure> >> the same, so no assignments in expressions, for example. Also, would C> >> programmers revolt at not having post and pre increment, also inside> >> expressions (as statements would be ok)? Requiring some sort of EVAL> >> statement? I guess the big question is whether removing these things> >> would make the whole idea unacceptable to the target audience. Does> >> the Algol syntax serve a purpose in making it clear that it isn't C?> >>> >>> >> On 16/02/2008, at 8:42 PM, Mika Nystrom wrote:> >>> >>>> >>> "If Steve Bourne could turn C into Algol using cpp, I'm sure you> >>> can figure out how to turn Algol[Modula] back into C using <...>"...> >>>> >>> If you think it would help acceptance of Modula-3, I don't see why> >>> not?> >>>> >>> I copied the code exactly the way it came off the old half-inch> >>> tape from Berkeley.> >>>> >>> Darko writes:> >>>> I'm not sure what you're getting at or if I'm missing something> >>>> witty.> >>>> I've said the form of the keywords makes little or no difference in> >>>> my> >>>> opinion. In my mail you quote I say there should be a C like syntax> >>>> for M3 as well as the existing one. I wasn't being sarcastic. It's a> >>>> matter of taste. I write in both all the time and it doesn't have any> >>>> impact on me, I go almost entirely by indentation, which I think is> >>>> very important. The indentation is pretty awful in code you posted> >>>> but> >>>> it could me my mailer.> >>>>> >>>> On 16/02/2008, at 10:51 AM, Mika Nystrom wrote:> >>> ...> >> > > > -- > Olaf Wagner -- elego Software Solutions GmbH> 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> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> _________________________________________________________________ Helping your favorite cause is as easy as instant messaging.?You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Mon Feb 18 05:41:29 2008 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 17 Feb 2008 20:41:29 -0800 Subject: [M3devel] code submission Message-ID: <200802180441.m1I4fTED010808@camembert.async.caltech.edu> Hello everyone, I was looking at some code I've written and realized that I have a very small piece of tested code that may be of interest to other Modula-3 users. It's a generic "trie" that I coded a few years ago. Does anyone have an opinion on adding it to cm3? Where, if so? http://www.async.caltech.edu/~mika/trie/ It's useful for parsing; if you're parsing a language with longish keywords it is many times faster to use this structure and ARRAY OF CHAR than using the standard hash tables with TEXTs. (I developed it to parse an old "punch-card", i.e., 80-character fixed-width records, format for financial data.) Mika From wagner at elegosoft.com Mon Feb 18 08:32:39 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 18 Feb 2008 08:32:39 +0100 Subject: [M3devel] Looking for CM3 Tinderbox regression test participants, was: Re: M3 concerns In-Reply-To: <776D06E2-D73F-47AB-ABA7-EE3FD5606403@cs.purdue.edu> References: <477B7629.1E75.00D7.1@scires.com> <20080104221059.uwf80xrms0gw8880@mail.elegosoft.com> <063F2D47-D837-4E11-9001-D152527E8694@cs.purdue.edu> <20080105011335.n767h3zbz4gcgk4k@mail.elegosoft.com> <20080105011719.GA5064@topoi.pooq.com> <20080105143235.ujed2tl3ksogws8k@mail.elegosoft.com> <20080131124304.w0aq9ygt2ckw4okc@mail.elegosoft.com> <20080217183907.3senktul2cg44scw@mail.elegosoft.com> <776D06E2-D73F-47AB-ABA7-EE3FD5606403@cs.purdue.edu> Message-ID: <20080218083239.zqdwlwki88ccc0ss@mail.elegosoft.com> Quoting Tony Hosking : > Solaris does not have %s for date -- we need an alternative for that > usage in tinderbox-build.sh. You mean as in date -u +'%Y-%m-%d-%H-%M-%S? It's used quite often: % grep -l date scripts/regression/*.sh scripts/regression/defs.sh scripts/regression/tinderbox-build.sh scripts/regression/tinderbox-status.sh scripts/regression/update_changelog.sh scripts/regression/update_m3tests.sh scripts/regression/update_pkg_status.sh scripts/regression/update_snapshot_status.sh Would it be possible, as a work-around, to install the GNU tools (date, sed, awk etc.)? I should have known something will fail on Solaris, because the standard command line utilities they ship are still bug-compatible to those from the 80s :-/ We've had lots of problems with them at one of our customers, too, and just installed openpkg as a stable environment. But I think GNU command line utilties should also be available as a Solaris package. If this is the only problem or if you cannot install an alternative environment, we'll have to do something about date. I'll make some tests later when I have access to a SPARC. Olaf -- Olaf Wagner -- elego Software Solutions GmbH 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 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jayk123 at hotmail.com Mon Feb 18 10:20:29 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 18 Feb 2008 09:20:29 +0000 Subject: [M3devel] C-like syntax for Modula-3 [was Re: "target specific pragmas"?] In-Reply-To: <20080217190317.3206jk5xgks40skk@mail.elegosoft.com> References: <200802170543.m1H5hcuX077398@camembert.async.caltech.edu> <20080217190317.3206jk5xgks40skk@mail.elegosoft.com> Message-ID: Some corrections.. try to make braces work (with some alteration for C) >> for SETS Optional safety -- probably but that for these purposes optional garbage collection -- maybe that too "but" should say "punt" That is, this dialect of C that has some Modula-3 features, might have optional safety, or even garbage collection. - Jay From: jayk123 at hotmail.comTo: wagner at elegosoft.com; m3devel at elegosoft.comSubject: RE: [M3devel] C-like syntax for Modula-3 [was Re: "target specific pragmas"?]Date: Mon, 18 Feb 2008 04:26:17 +0000 I've been trying to stay out of this... If a comment at the top of the file can make the Modula-3 syntax more like C then.. replace = with == replace := with = make assignment an expression lowercase the keywords try to make braces work (with some alteration for C) use type name instead of name : type separate function parameters with commas and require each to state its type for that matter, subset C and require all declarations be separate like that? put back ++, --, -=, +=, etc. superset C and let . be used in place of -> new coding style is four space indent with opening braces on their own line :) Hm. I think if anyone really wants to do this, instead of nit picking about Modula-3 syntax here and there, go about it in a slightly different way? Pick apart what defines Modula-3 through much discussion. Optional safety -- probably but that for these purposes optional garbage collection -- maybe that too "object orientation" that is a subset of C++ try to use C++ syntax? generics (generic modules) independently and relatively easily parsable interface definitions (!) these are both important, but I think "independent" is more important and "relatively easily" could be omitted for the goals of this exercise compiles to native code sizeof(integer) == sizeof(address) (minor detail) built in sets and good enumerations arrays; I don't like them starting at non-zero, but enums for their index are interesting Take the existing definition of C and alter it to have these characteristics very very much like Modula-3 but with very very very much Modula-3 syntax. That is, this is a large exercise, but: if you keep optional safety, define what is safe, basically the same as in Modula-3 determine syntax for enums, arrays, sets Write a front end for it. Boom. Right there my patience wouldn't get far. Make it ABI compatible with Modula-3.Heck, start with the existing front end MAYBE. Compatibility with SOME existing code should be a goal.Compatibility with headers is problematic but very useful.This front end could help translation of headers to "independently parsable" form. (SWIG is the name of the thing someone mentioned the other day but had the name wrong.) Look into the D language.It might be just the ticket... you MIGHT find that it has all the aspects of Modula-3 that any of you desire, and more... - Jay > Date: Sun, 17 Feb 2008 19:03:17 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] C-like syntax for Modula-3 [was Re: "target specifi