From wagner at elegosoft.com Thu Apr 1 10:33:13 2010 From: wagner at elegosoft.com (wagner at elegosoft.com) Date: Thu, 01 Apr 2010 10:33:13 +0200 Subject: [M3devel] m3back directions? In-Reply-To: References: <20100331121830.22q33okrokkwsgwk@mail.elegosoft.com> Message-ID: <20100401103313.j86zit1w0kc0wkoc@mail.elegosoft.com> Quoting Tony Hosking : > On 31 Mar 2010, at 06:18, wagner at elegosoft.com wrote: > >> Quoting Jay K : >> >>> I'm curious what, if anything, people are interested in in m3back? >>> >>> There are several mostly independent directions: >>> >>> - remove it; use the gcc backend or other (burg, llvm, generate C) >>> >>> - expand to support other targets, AMD64_*, including AMD64_NT >>> >>> m3objfile would need macho/elf support for non-NT >> >> It would be great if we could use the integrated backend for other >> targets, too. Adding ELF support will be a lot of work, but it's probably >> worth it. > > Have you looked at the pm3 Linux support? Indeed I had forgotten about that. I'll take at look at the Easter holidays, Olaf From jay.krell at cornell.edu Thu Apr 1 14:33:52 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 1 Apr 2010 12:33:52 +0000 Subject: [M3devel] m3back directions? In-Reply-To: <20100401103313.j86zit1w0kc0wkoc@mail.elegosoft.com> References: , <20100331121830.22q33okrokkwsgwk@mail.elegosoft.com>, , <20100401103313.j86zit1w0kc0wkoc@mail.elegosoft.com> Message-ID: I think it was GPL though. - Jay > Date: Thu, 1 Apr 2010 10:33:13 +0200 > From: wagner at elegosoft.com > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] m3back directions? > > Quoting Tony Hosking : > > > On 31 Mar 2010, at 06:18, wagner at elegosoft.com wrote: > > > >> Quoting Jay K : > >> > >>> I'm curious what, if anything, people are interested in in m3back? > >>> > >>> There are several mostly independent directions: > >>> > >>> - remove it; use the gcc backend or other (burg, llvm, generate C) > >>> > >>> - expand to support other targets, AMD64_*, including AMD64_NT > >>> > >>> m3objfile would need macho/elf support for non-NT > >> > >> It would be great if we could use the integrated backend for other > >> targets, too. Adding ELF support will be a lot of work, but it's probably > >> worth it. > > > > Have you looked at the pm3 Linux support? > > Indeed I had forgotten about that. I'll take at look at the Easter > holidays, > > Olaf > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Thu Apr 1 16:28:53 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 01 Apr 2010 09:28:53 -0500 Subject: [M3devel] changing m3middle/m3back to have multiple passes? In-Reply-To: References: Message-ID: <4BB4ADA5.70003@lcwb.coop> Jay K wrote: > I'm thinking m3back could use multiple passes. This would be a big reversal of the fundamental design philosophy of this back end. Its primary design criterion was to be simple and fast. That means single-pass. There have been several compilers (often whole compilers, not just code generators) written to this principle. For some purposes, it is a good thing. This, of course, inevitably means the generated code is not as small/fast as it could be. It's part of the trade off. We have two points on this trade off scale now. I think we want to keep the one-pass code generator. If you change it, at least make a branch and keep the original design easily accessible. > > > There a few reasons, things that would be easier/possible if it had them. > > > I know adding passes will slow it down, but I suspect it will still be > about as pleasantly fast as it is now. > > > The optimizations I have in mind: > inlining, including where function definitions come after the call > I think inlining where the "small" functions come first is doable in > pass, > but not if uses come before calls. > > > not saving unused registers > This only a small optimization and could probably be done in one > pass if m3objfile got a "memmove" operation. Well, I already > have the optimization in somewhat, but it involves nop-ing out > code instead of removing it completely. > > > dead store removal, and then removing the resulting dead code to > compute the value > > > possibly better register allocation -- e.g. based on noticing which > variables are used often, or based on how they are used, for example > if a variable (or expression/temporary) ends serving a shift count, > we should favor putting it in ecx up front, instead of moving it to > ecx later, but we don't generally know this till too late > > > As I understand, m3middle already has the notion of "recording" > and "playing back" calls to the M3CG interface. > That seems like a good starting point? > > > Some optimizations can be made via "CG to CG" transforms. > > > However I think in general I think the required design would include: > - ability to add in "private operations"; maybe > - ability to add "private data" to existing operations > A very simple one is annotate functions with required frame size. > This isn't currently known until the end of the function. > - clearly, ability to remove operations > > > Can/should we somehow augment m3middle in support of this line of thinking? > > > Or is that just not the way to go? > Each backend should have its own internal representation and loop over it? > > - Jay > From jay.krell at cornell.edu Thu Apr 1 17:10:04 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 1 Apr 2010 15:10:04 +0000 Subject: [M3devel] changing m3middle/m3back to have multiple passes? In-Reply-To: <4BB4ADA5.70003@lcwb.coop> References: , <4BB4ADA5.70003@lcwb.coop> Message-ID: Simple and fast does not entirely preclude multiple passes, and one pass does not equate to simple, though yes probably fast. The front end already makes multiple passes I believe, and is still fast. Sometimes decomposition into more smaller pieces (passes, layers, etc.) make things simpler. Albeit slower. A more historical factor here is that multiple passes imply keeping more data in memory longer. Implies slower. However memory capacity has increased tremendously. Whereas I'm only thinking about multiple passes, while still compiling one file at a time, other compilation systems have capitalized on larger memories and now compile entire programs at once, including multiple passes. This goes by multiple names -- "whole program optimization", "link time codegen (LTCG)". And enables even more aggressive but still "fairly simple" optimization, such as cross module inlining, custom calling conventions. I say "fairly simple", because these are just the same optimizations one would perform within a module, merely applied across module boundaries. (Sometimes what people do is #include all .c files into one master .c file, to help get the compiler to see everything at once. sqllite does this, for example.) Surely we can afford multiple passes on a per-file basis. ? The code is already not that easy to understand imho. It took me quite some time to get comfortable and add the 64 bit integer support, years. And there's a few things I still don't understand (you can tell from my comments in the code, like where do I need to call "newdest")? Embrace it and make it incrementally harder to understand (by virtue of simply adding to it), or decide it is stuck asis? I'm not entirely sure. While it is an interesting compromise in its current form, I'm fairly certain there are other viable compromises that achieve better code quality, are still plenty fast, and aren't much more difficult to understand. Heck, I found it confusing at first that the -debug output is wrong in some places. That is a fallout from it being single pass "plus patching". The debug output doesn't include the "patches". I have some very simple small optimizations in mind. And then, in stepping through code, and writing code, inlining constantly comes to mind. In fact, I frequently see "manual partial inlining" in the Modula-3 code. It'd be nifty if the Modula-3 code could have less duplication, relying on the compiler more. I don't see inlining as entirely simple, but I've given it a little thought and it might not be so hard. I think it can be done, roughly, by taking the body of a procedure as expressed as cg.i3 calls, omitting the begin/procedure, and just "playing them back" at the call site. You'd only do this for "small" functions. You'd have to make some adjustments like merging local variables and exception handling, though really the inlined function would just be a "block". Probably the way to go here, if inlining is really to be considered, is first implement it as "one pass plus some memory", and only inline when the definition comes before the call. Once that is achieved, no small feat, further considering can be made to allow for inlining when the call precedes the definition. eh, sorry, I'm tried, rambling. - Jay > Date: Thu, 1 Apr 2010 09:28:53 -0500 > From: rodney_bates at lcwb.coop > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] changing m3middle/m3back to have multiple passes? > > > > Jay K wrote: > > I'm thinking m3back could use multiple passes. > > This would be a big reversal of the fundamental design philosophy of this > back end. Its primary design criterion was to be simple and fast. That > means single-pass. There have been several compilers (often whole compilers, > not just code generators) written to this principle. For some purposes, > it is a good thing. > > This, of course, inevitably means the generated code is not as small/fast > as it could be. It's part of the trade off. We have two points on this > trade off scale now. I think we want to keep the one-pass code generator. > If you change it, at least make a branch and keep the original design > easily accessible. > > > > > > > > There a few reasons, things that would be easier/possible if it had them. > > > > > > I know adding passes will slow it down, but I suspect it will still be > > about as pleasantly fast as it is now. > > > > > > The optimizations I have in mind: > > inlining, including where function definitions come after the call > > I think inlining where the "small" functions come first is doable in > > pass, > > but not if uses come before calls. > > > > > > not saving unused registers > > This only a small optimization and could probably be done in one > > pass if m3objfile got a "memmove" operation. Well, I already > > have the optimization in somewhat, but it involves nop-ing out > > code instead of removing it completely. > > > > > > dead store removal, and then removing the resulting dead code to > > compute the value > > > > > > possibly better register allocation -- e.g. based on noticing which > > variables are used often, or based on how they are used, for example > > if a variable (or expression/temporary) ends serving a shift count, > > we should favor putting it in ecx up front, instead of moving it to > > ecx later, but we don't generally know this till too late > > > > > > As I understand, m3middle already has the notion of "recording" > > and "playing back" calls to the M3CG interface. > > That seems like a good starting point? > > > > > > Some optimizations can be made via "CG to CG" transforms. > > > > > > However I think in general I think the required design would include: > > - ability to add in "private operations"; maybe > > - ability to add "private data" to existing operations > > A very simple one is annotate functions with required frame size. > > This isn't currently known until the end of the function. > > - clearly, ability to remove operations > > > > > > Can/should we somehow augment m3middle in support of this line of thinking? > > > > > > Or is that just not the way to go? > > Each backend should have its own internal representation and loop over it? > > > > - Jay > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Apr 1 17:59:58 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 1 Apr 2010 11:59:58 -0400 Subject: [M3devel] m3back directions? In-Reply-To: References: , <20100331121830.22q33okrokkwsgwk@mail.elegosoft.com>, , <20100401103313.j86zit1w0kc0wkoc@mail.elegosoft.com> Message-ID: All of PM3 is licensed the same way as CM3 (they both derive from the same DEC SRC sources). On 1 Apr 2010, at 08:33, Jay K wrote: > I think it was GPL though. > > - Jay > > > Date: Thu, 1 Apr 2010 10:33:13 +0200 > > From: wagner at elegosoft.com > > To: hosking at cs.purdue.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] m3back directions? > > > > Quoting Tony Hosking : > > > > > On 31 Mar 2010, at 06:18, wagner at elegosoft.com wrote: > > > > > >> Quoting Jay K : > > >> > > >>> I'm curious what, if anything, people are interested in in m3back? > > >>> > > >>> There are several mostly independent directions: > > >>> > > >>> - remove it; use the gcc backend or other (burg, llvm, generate C) > > >>> > > >>> - expand to support other targets, AMD64_*, including AMD64_NT > > >>> > > >>> m3objfile would need macho/elf support for non-NT > > >> > > >> It would be great if we could use the integrated backend for other > > >> targets, too. Adding ELF support will be a lot of work, but it's probably > > >> worth it. > > > > > > Have you looked at the pm3 Linux support? > > > > Indeed I had forgotten about that. I'll take at look at the Easter > > holidays, > > > > Olaf > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Apr 1 18:08:52 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 1 Apr 2010 12:08:52 -0400 Subject: [M3devel] changing m3middle/m3back to have multiple passes? In-Reply-To: <4BB4ADA5.70003@lcwb.coop> References: <4BB4ADA5.70003@lcwb.coop> Message-ID: <452F7418-679D-49D3-BC44-EA07B157AEF5@cs.purdue.edu> Indeed. I think we would be better served exploring alternatives like LLVM where we can rely on others to implement the grungy compiler optimisations and we can sail above the fray worrying about the language proper On 1 Apr 2010, at 10:28, Rodney M. Bates wrote: > > > Jay K wrote: >> I'm thinking m3back could use multiple passes. > > This would be a big reversal of the fundamental design philosophy of this > back end. Its primary design criterion was to be simple and fast. That > means single-pass. There have been several compilers (often whole compilers, > not just code generators) written to this principle. For some purposes, > it is a good thing. > > This, of course, inevitably means the generated code is not as small/fast > as it could be. It's part of the trade off. We have two points on this > trade off scale now. I think we want to keep the one-pass code generator. > If you change it, at least make a branch and keep the original design > easily accessible. > > >> There a few reasons, things that would be easier/possible if it had them. >> I know adding passes will slow it down, but I suspect it will still be >> about as pleasantly fast as it is now. >> The optimizations I have in mind: >> inlining, including where function definitions come after the call >> I think inlining where the "small" functions come first is doable in pass, >> but not if uses come before calls. >> not saving unused registers >> This only a small optimization and could probably be done in one >> pass if m3objfile got a "memmove" operation. Well, I already >> have the optimization in somewhat, but it involves nop-ing out >> code instead of removing it completely. >> dead store removal, and then removing the resulting dead code to compute the value >> possibly better register allocation -- e.g. based on noticing which >> variables are used often, or based on how they are used, for example >> if a variable (or expression/temporary) ends serving a shift count, >> we should favor putting it in ecx up front, instead of moving it to >> ecx later, but we don't generally know this till too late >> As I understand, m3middle already has the notion of "recording" >> and "playing back" calls to the M3CG interface. >> That seems like a good starting point? >> Some optimizations can be made via "CG to CG" transforms. >> However I think in general I think the required design would include: >> - ability to add in "private operations"; maybe >> - ability to add "private data" to existing operations >> A very simple one is annotate functions with required frame size. >> This isn't currently known until the end of the function. >> - clearly, ability to remove operations >> Can/should we somehow augment m3middle in support of this line of thinking? >> Or is that just not the way to go? >> Each backend should have its own internal representation and loop over it? >> - Jay From hendrik at topoi.pooq.com Sun Apr 4 03:20:57 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sat, 3 Apr 2010 21:20:57 -0400 Subject: [M3devel] changing m3middle/m3back to have multiple passes? In-Reply-To: References: <4BB4ADA5.70003@lcwb.coop> Message-ID: <20100404012057.GA20078@topoi.pooq.com> On Thu, Apr 01, 2010 at 03:10:04PM +0000, Jay K wrote: > > However memory capacity has increased tremendously. > > > > > > Whereas I'm only thinking about multiple passes, while still compiling > one file at a time, > > other compilation systems have capitalized on larger memories and now > compile entire programs at once, including multiple passes. > > This goes by multiple names -- "whole program optimization", "link > time codegen (LTCG)". Link-time code generation was already involved in Mark Rain's Mary 2 compiler in the early 80's. It didn't actually require today's huge memories. Every now and then the Modula 3 compiler seems to decide to recompile something because new source had been discovered, or soething like that. I suspect this is because a new .m3 file changes the memory layout that was assumed in aanother source file, so that other one needs to be reconsidered. Is the complexity of tracking that simpler or more complex than doing whole-program compilation? It's possible that file-by-file compilation is a simpler match for interacting with foreign-language compilations, theough. It two languages insist on only compiling whole programs, it makes mixed-language programming difficult. -- hendrik From jay.krell at cornell.edu Sat Apr 3 03:34:22 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 3 Apr 2010 01:34:22 +0000 Subject: [M3devel] changing m3middle/m3back to have multiple passes? In-Reply-To: <20100404012057.GA20078@topoi.pooq.com> References: <4BB4ADA5.70003@lcwb.coop>, , <20100404012057.GA20078@topoi.pooq.com> Message-ID: Good points. I forgot to clarify that to some extent I just want to make multiple passes over functions, not files. => even less memory and slow down In particular, I want to know if a frame size is < 256, or < 4K or >= 4K. The >= 4K case isn't handled correctly today I believe, though will generally work. < 256 affords one byte of savings. I'd also like to know what registers are used, for 1, 2, or 3 bytes saved. While these are small, they are very broadly applicable. Consider that even the smallest of functions: PROCEDURE F(): INTEGER = BEGIN RETURN 1 END F; compiles/compiled to something like: push ebp mov ebp, esp sub esp, 0 ; yes, we are willing to put zero here, and it takes 2 bytes push esi ; I nop this out now. push edi ; I nop this out now. push ebx ; I nop this out now. mov eax, 1 pop ebx ; I optimize this out now. pop edi ; I optimize this out now. pop esi ; I optimize this out now. leave 0 ; I think ret when, if you punt the point of frame point omission, it could be: push ebp mov ebp, esp mov eax, 1 leave 0 ; I think. ret or if you allow for frame pointer omission: mov eax, 1 ret (Let's assume the address is taken, therefore it can't always easily be inlined.) "imagine if all code was multiplied out like this" Omitting the frame pointer hurts stack walk and debugging, however I think there is a midddle ground that people don't discuss: if a function takes no parameters and has no locals, then omit the frame pointer Possibly also if it has no locals and/or makes no function calls. Like, if it never uses esp or ebp. Actually this is encoded in PowerPC and AMD64 calling conventions, leaf functions can optimize their prologue/epilogue. But it doesn't seem come up with regarding x86. There again, multiple passes help. Multiple passes over a function would also offer things like eliminating dead stores, and cascading elimination of dead code, e.g: a := b + 1; (* eliminate this whole line *) a := b + 2; Granted, I am interested in multiple passes over a file too, for inlining. What I'm really going to do though is try to provide ObjFile.Move so that at the end of the function, I can "move" the entire function up or down a few bytes, or maybe only up. You can imagine "down" to fix the >= 4K case, but you might as well model that as reserving room for the worst case in first pass, and then move down usually. I think it just requires that I understand relocs much better, which is a good goal anyway for working with the code. You know -- perform a not well motivated change to some code, for purposes of exercise -- understanding the code and how to change it, so that when a better motivated change comes along, we aren't stuck. Also, I only recently realized/learned the high value of "sequential access" as it relates to "working set". Let's say you really have more data than memory? In a compiler we don't, but some applications do (plain text indexing of large data). Then what you do is: To whatever extent you can, break the data down into smaller pieces. At some level, random access is unavoidable, say, to sort small data. When you can't break the data down: Access it linearly, not randomly: mergesort instead of quicksort. Minimize the number of passes, but there is tradeoff between number of passes and working set size. Linear access keeps working set "constant", even if you are slowed down by having to reread data from disk. Yes I do see that message from the front end. I haven't looked into what it means, but yeah presumably something like a pessimistic first pass, followed by discovery of layout information, followed by more optimistic second pass. You might imagine, for example, knowing the sizes of opaque or object types. The front end makes multiple passes. I suspect for significant simplicity or "possibility" -- it might be darn difficult to implement in fewer passes, without contorting the code a lot. If you look how how "patching" and "labels" work in the backend, that's probably an example of where multiple passes would be more general and simpler, but where the "contortions" are well known and not too bad. It uses "patching" to fill in the frame size for example, and I now use that to nop out unnecessary prolog instructions (on the theory that nop it is a small optimization). Though, again, patching isn't sufficient for >4K frames. Very long standing bug there, I have to confirm and fix soon. Good points about whole program optimization. I think there are ways to address this. Not any time soon. Doing optimization and codegen at "link time" I think is somewhat of a hack in these systems. One we can't easily play into, as you point out. However, where we use the gcc backend and linker, we probably can, easily. That is many platforms. gcc does have this option. Also we could optimize "among" all the *.m3 files, just lose out on any M3<=>C optimizations. In reality, let me first think about NTObjFile.Move as a way to do some small optimizations, NTObjFile CodeView generation, maybe inlining, maybe LLVM. Testing/optimizing the atomics (add,sub,xor can improve, also store and probably load). Everything else is too much for the time being. Maybe we can do some target independent optimizations in m3front or m3front/cg or m3middle as well. Inlining could be done there, but the metrics of when to do it aren't really available. Only for *extremely* cheap seeming functions could the front end make a reliable target-independent choice. Oh wait -- that is interesting. If you consider just the case of inlining functions whose definitions precede use, the backend could "measure" a function, after generating it, and report back to the frontend if it should strongly consider inlining it. Then upon subsequent calls, the frontend could do the inlining. Such measurement is always going to be heuristic, but you can imagine stuff like number of cg calls number of parameters does it return a value As well, if had a <* FORCEINLINE *> pragma, the frontend could implement that. I'm pretty sure. Not clear if better to leave the decision to the compiler or not. After all, C and C++ have "inline" and "__inline" that are just hints that modern compilers ignore, and Visual C++ has "__forceinline", which generates a warning when not honored. Seems to be a bit of an arms race in terms of who things he knows better, programmer or compiler. Used to always be the programmer, then shifted to compiler, now not clear. - Jay > Date: Sat, 3 Apr 2010 21:20:57 -0400 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] changing m3middle/m3back to have multiple passes? > > On Thu, Apr 01, 2010 at 03:10:04PM +0000, Jay K wrote: > > > > However memory capacity has increased tremendously. > > > > > > > > > > > > Whereas I'm only thinking about multiple passes, while still compiling > > one file at a time, > > > > other compilation systems have capitalized on larger memories and now > > compile entire programs at once, including multiple passes. > > > > This goes by multiple names -- "whole program optimization", "link > > time codegen (LTCG)". > > Link-time code generation was already involved in Mark Rain's Mary 2 > compiler in the early 80's. It didn't actually require today's huge > memories. > > Every now and then the Modula 3 compiler seems to decide to recompile > something because new source had been discovered, or soething like that. > I suspect this is because a new .m3 file changes the memory layout that > was assumed in aanother source file, so that other one needs to be > reconsidered. Is the complexity of tracking that simpler or more > complex than doing whole-program compilation? > > It's possible that file-by-file compilation is a simpler match for > interacting with foreign-language compilations, theough. It two > languages insist on only compiling whole programs, it makes > mixed-language programming difficult. > > -- hendrik -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Apr 3 13:02:56 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 3 Apr 2010 11:02:56 +0000 Subject: [M3devel] m3back directions? In-Reply-To: References: , , <20100331121830.22q33okrokkwsgwk@mail.elegosoft.com>, , , , <20100401103313.j86zit1w0kc0wkoc@mail.elegosoft.com>, , Message-ID: No, really. GPL. http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/pm3/m3/pm3/language/modula3/m3compiler/m3back/src/linux/Codex86.m3?rev=1.3;content-type=text%2Fplain http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/pm3/m3/pm3/language/modula3/m3compiler/m3objfile/src/linux/ELFObjFile.m3?rev=1.2;content-type=text%2Fplain - Jay From: hosking at cs.purdue.edu Date: Thu, 1 Apr 2010 11:59:58 -0400 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] m3back directions? All of PM3 is licensed the same way as CM3 (they both derive from the same DEC SRC sources). On 1 Apr 2010, at 08:33, Jay K wrote: I think it was GPL though. - Jay > Date: Thu, 1 Apr 2010 10:33:13 +0200 > From: wagner at elegosoft.com > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] m3back directions? > > Quoting Tony Hosking : > > > On 31 Mar 2010, at 06:18, wagner at elegosoft.com wrote: > > > >> Quoting Jay K : > >> > >>> I'm curious what, if anything, people are interested in in m3back? > >>> > >>> There are several mostly independent directions: > >>> > >>> - remove it; use the gcc backend or other (burg, llvm, generate C) > >>> > >>> - expand to support other targets, AMD64_*, including AMD64_NT > >>> > >>> m3objfile would need macho/elf support for non-NT > >> > >> It would be great if we could use the integrated backend for other > >> targets, too. Adding ELF support will be a lot of work, but it's probably > >> worth it. > > > > Have you looked at the pm3 Linux support? > > Indeed I had forgotten about that. I'll take at look at the Easter > holidays, > > Olaf > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Apr 3 19:24:16 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 3 Apr 2010 13:24:16 -0400 Subject: [M3devel] m3back directions? In-Reply-To: References: , , <20100331121830.22q33okrokkwsgwk@mail.elegosoft.com>, , , , <20100401103313.j86zit1w0kc0wkoc@mail.elegosoft.com>, , Message-ID: <4C7DFD56-676D-4E33-983F-29FA41357053@cs.purdue.edu> Interesting. We can still use it (like gcc) right? Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 3 Apr 2010, at 07:02, Jay K wrote: > No, really. GPL. > > http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/pm3/m3/pm3/language/modula3/m3compiler/m3back/src/linux/Codex86.m3?rev=1.3;content-type=text%2Fplain > > http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/pm3/m3/pm3/language/modula3/m3compiler/m3objfile/src/linux/ELFObjFile.m3?rev=1.2;content-type=text%2Fplain > > - Jay > > > From: hosking at cs.purdue.edu > Date: Thu, 1 Apr 2010 11:59:58 -0400 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] m3back directions? > > All of PM3 is licensed the same way as CM3 (they both derive from the same DEC SRC sources). > > > On 1 Apr 2010, at 08:33, Jay K wrote: > > I think it was GPL though. > > - Jay > > > Date: Thu, 1 Apr 2010 10:33:13 +0200 > > From: wagner at elegosoft.com > > To: hosking at cs.purdue.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] m3back directions? > > > > Quoting Tony Hosking : > > > > > On 31 Mar 2010, at 06:18, wagner at elegosoft.com wrote: > > > > > >> Quoting Jay K : > > >> > > >>> I'm curious what, if anything, people are interested in in m3back? > > >>> > > >>> There are several mostly independent directions: > > >>> > > >>> - remove it; use the gcc backend or other (burg, llvm, generate C) > > >>> > > >>> - expand to support other targets, AMD64_*, including AMD64_NT > > >>> > > >>> m3objfile would need macho/elf support for non-NT > > >> > > >> It would be great if we could use the integrated backend for other > > >> targets, too. Adding ELF support will be a lot of work, but it's probably > > >> worth it. > > > > > > Have you looked at the pm3 Linux support? > > > > Indeed I had forgotten about that. I'll take at look at the Easter > > holidays, > > > > Olaf > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Sun Apr 4 01:41:31 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sat, 03 Apr 2010 18:41:31 -0500 Subject: [M3devel] m3back directions? In-Reply-To: References: , , <20100331121830.22q33okrokkwsgwk@mail.elegosoft.com>, , , , <20100401103313.j86zit1w0kc0wkoc@mail.elegosoft.com>, , Message-ID: <4BB7D22B.5000107@lcwb.coop> Wasn't it written an Montreal Poly as a student project or something? Jay K wrote: > No, really. GPL. > > http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/pm3/m3/pm3/language/modula3/m3compiler/m3back/src/linux/Codex86.m3?rev=1.3;content-type=text%2Fplain > > http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/pm3/m3/pm3/language/modula3/m3compiler/m3objfile/src/linux/ELFObjFile.m3?rev=1.2;content-type=text%2Fplain > > - Jay > > > ------------------------------------------------------------------------ > From: hosking at cs.purdue.edu > Date: Thu, 1 Apr 2010 11:59:58 -0400 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] m3back directions? > > All of PM3 is licensed the same way as CM3 (they both derive from the > same DEC SRC sources). > > > On 1 Apr 2010, at 08:33, Jay K wrote: > > I think it was GPL though. > > - Jay > > > Date: Thu, 1 Apr 2010 10:33:13 +0200 > > From: wagner at elegosoft.com > > To: hosking at cs.purdue.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] m3back directions? > > > > Quoting Tony Hosking >: > > > > > On 31 Mar 2010, at 06:18, wagner at elegosoft.com > wrote: > > > > > >> Quoting Jay K >: > > >> > > >>> I'm curious what, if anything, people are interested in in m3back? > > >>> > > >>> There are several mostly independent directions: > > >>> > > >>> - remove it; use the gcc backend or other (burg, llvm, generate C) > > >>> > > >>> - expand to support other targets, AMD64_*, including AMD64_NT > > >>> > > >>> m3objfile would need macho/elf support for non-NT > > >> > > >> It would be great if we could use the integrated backend for other > > >> targets, too. Adding ELF support will be a lot of work, but > it's probably > > >> worth it. > > > > > > Have you looked at the pm3 Linux support? > > > > Indeed I had forgotten about that. I'll take at look at the Easter > > holidays, > > > > Olaf > > > > > > From jay.krell at cornell.edu Sun Apr 4 02:35:32 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 4 Apr 2010 00:35:32 +0000 Subject: [M3devel] m3back directions? In-Reply-To: <4BB7D22B.5000107@lcwb.coop> References: , ,,<20100331121830.22q33okrokkwsgwk@mail.elegosoft.com>, ,,, , , <20100401103313.j86zit1w0kc0wkoc@mail.elegosoft.com>, , , , , , <4BB7D22B.5000107@lcwb.coop> Message-ID: Do you mean to ask, am I embarassed that I nor any of us have done it ourselves by now? Yes. :) (Though I don't know about the question as stated.) Interest level here is higher than I expected in non-gcc backends. And Tony gave the answer I expected. :) I don't know. It's kind of cheating, less fun, very hard to ramp up on, but once there very useful and good reuse and code quality. So I'll consider this higher priority, if nobody beats me to it. I also noticed the two burg backends in the 3.6 tree. Did they build and work? Eh, rhetorical mostly. It's hard to get one's head around this stuff. Easier to improve m3back. Though they had a MIPS backend too and I do have some MIPS machines.. (SGIs and router). I'd like to first: current release CodeView debugging test/optimize atomics (anyone can test this, please do) test/fix 64bit range checks (anyone can test this, please do) the micro optimizations I've been repeatedly describing (not multi pass, just "objfile.move") And then once I have "move", fix the >4K frame bug. And then I'll try to consider other x86 backends again. - Jay > Date: Sat, 3 Apr 2010 18:41:31 -0500 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: Re: [M3devel] m3back directions? > > Wasn't it written an Montreal Poly as a student project or something? > > Jay K wrote: > > No, really. GPL. > > > > http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/pm3/m3/pm3/language/modula3/m3compiler/m3back/src/linux/Codex86.m3?rev=1.3;content-type=text%2Fplain > > > > http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/pm3/m3/pm3/language/modula3/m3compiler/m3objfile/src/linux/ELFObjFile.m3?rev=1.2;content-type=text%2Fplain > > > > - Jay > > > > > > ------------------------------------------------------------------------ > > From: hosking at cs.purdue.edu > > Date: Thu, 1 Apr 2010 11:59:58 -0400 > > To: jay.krell at cornell.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] m3back directions? > > > > All of PM3 is licensed the same way as CM3 (they both derive from the > > same DEC SRC sources). > > > > > > On 1 Apr 2010, at 08:33, Jay K wrote: > > > > I think it was GPL though. > > > > - Jay > > > > > Date: Thu, 1 Apr 2010 10:33:13 +0200 > > > From: wagner at elegosoft.com > > > To: hosking at cs.purdue.edu > > > CC: m3devel at elegosoft.com > > > Subject: Re: [M3devel] m3back directions? > > > > > > Quoting Tony Hosking > >: > > > > > > > On 31 Mar 2010, at 06:18, wagner at elegosoft.com > > wrote: > > > > > > > >> Quoting Jay K > >: > > > >> > > > >>> I'm curious what, if anything, people are interested in in m3back? > > > >>> > > > >>> There are several mostly independent directions: > > > >>> > > > >>> - remove it; use the gcc backend or other (burg, llvm, generate C) > > > >>> > > > >>> - expand to support other targets, AMD64_*, including AMD64_NT > > > >>> > > > >>> m3objfile would need macho/elf support for non-NT > > > >> > > > >> It would be great if we could use the integrated backend for other > > > >> targets, too. Adding ELF support will be a lot of work, but > > it's probably > > > >> worth it. > > > > > > > > Have you looked at the pm3 Linux support? > > > > > > Indeed I had forgotten about that. I'll take at look at the Easter > > > holidays, > > > > > > Olaf > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Apr 4 10:29:31 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 4 Apr 2010 08:29:31 +0000 Subject: [M3devel] interesting comment in caltech-parser m3overrides Message-ID: /* when overriding, ld.so doesn't know where to find libraries */ /* this is even more true if we want to move the binaries or */ /* clean.. */ %if defined("pm3_version") % /* Polytechnique de Montreal Modula-3 */ % option("shared_lib","") %else % /* SRC Modula-3 */ % m3_option ("-X2 at -static@") %end which is the same problem we discussed here a bunch. To which there is no good solution, just various compromises. For the next (not current) release though I think all .so and executables should build (not just ship) into a common place. So $ORIGIN works, without having to ship. They also have this interesting technique: /* these are the packages that are part of this distribution */ override("prsparse",TOP) ... % override other libraries if they exist locally (use not stale on each) m3core = ROOT & SL & "m3-libs" & SL & "m3core" if not stale(m3core, m3core) override("m3core", ROOT & SL & "m3-libs") end ... override should probably do the existance check if it doesn't already. Though the idea of building stuff to a common directory I believe obsoletes this entire override thing. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Apr 4 12:02:09 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 4 Apr 2010 10:02:09 +0000 Subject: [M3devel] initializing field with record size? Message-ID: TYPE struct_stat = RECORD type_size: LONGINT := VAL(BYTESIZE(struct_stat), LONGINT); st_dev : LONGINT; (* Utypes.dev_t *) ... END; new source -> compiling Ustat.i3 "..\src\unix\Common\Ustat.i3", line 57: illegal recursive declaration (struct_stat) "..\src\unix\Common\Ustat.i3", line 57: illegal recursive type declaration 2 errors encountered compilation failed => not building library "m3core.lib" Fatal Error: package build failed really can't be allowed? I know, I can compute it myself, or I can make it a default parameter to functions that traffic in the type. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Apr 4 12:25:08 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 4 Apr 2010 10:25:08 +0000 Subject: [M3devel] some new NT386 builds from release branch Message-ID: http://modula3.elegosoft.com/cm3/uploaded-archives/index.html Has some new NT386 builds out of the release branch. e.g. http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-all-x86-pre5.8.5-VC80.msi http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-all-x86-pre5.8.5-VC90.msi http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-x86-pre5.8.5-VC80.msi http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-x86-pre5.8.5-VC70.zip http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-x86-pre5.8.5-VC60.zip etc. It is all very automated. I can trivially update them if/when we fix more bugs. It is really no trouble to support the older versions of Visual C++. I can provide .msis or "all" for the older Visual C++ if anyone needs. There's a bug that strongly suggests we should provide separate per-toolset builds like this. (#1077 win32 install problem's jkrell sw-bug medium installation current) I've taken the liberty of assuming .msi and even .zip imply NT, thus the file names. Next step maybe is for the web page to suggest the right target download, like how http://www.mozilla.com does? (with a link to other systems, etc.) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Apr 4 15:01:35 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 4 Apr 2010 09:01:35 -0400 Subject: [M3devel] interesting comment in caltech-parser m3overrides In-Reply-To: References: Message-ID: override was used before the existence of shared libs in CM3/PM3 so not surprising. On 4 Apr 2010, at 04:29, Jay K wrote: > /* when overriding, ld.so doesn't know where to find libraries */ > /* this is even more true if we want to move the binaries or */ > /* clean.. */ > > %if defined("pm3_version") > % /* Polytechnique de Montreal Modula-3 */ > % option("shared_lib","") > %else > % /* SRC Modula-3 */ > % m3_option ("-X2 at -static@") > %end > > > which is the same problem we discussed here a bunch. > To which there is no good solution, just various compromises. > For the next (not current) release though I think all .so and executables should build (not just ship) into a common place. > So $ORIGIN works, without having to ship. > > > They also have this interesting technique: > > /* these are the packages that are part of this distribution */ > override("prsparse",TOP) > ... > > > % override other libraries if they exist locally (use not stale on each) > > m3core = ROOT & SL & "m3-libs" & SL & "m3core" > if not stale(m3core, m3core) > override("m3core", ROOT & SL & "m3-libs") > end > ... > > > override should probably do the existance check if it doesn't already. > Though the idea of building stuff to a common directory I believe obsoletes this entire override thing. > > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Apr 5 13:41:10 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 5 Apr 2010 11:41:10 +0000 Subject: [M3devel] RTMachine.PointerAlignment = 1 on NT? Message-ID: For the vast majority of platforms: RTMachine.PointerAlignment = BYTESIZE(INTEGER). except 1 for NT386, 2 for M68K (dead). PointerAlignment = BYTESIZE(INTEGER); (* The C compiler allocates all pointers on 'PointerAlignment'-byte boundaries. The garbage collector scans thread stacks, but only looks at these possible pointer locations. Setting this value smaller than is needed will only make your system run slower. Setting it too large will cause the collector to collect storage that is not free. *) I suggest this is not exactly true. 1) Of what relevance is the C compiler? vs. the Modula-3 compiler. 2) We really think the number is 1 for NT386? I understand I could say: void F(void* traced) { #pragma pack(1) struct { char a; void* p} = {0, traced}; } but 1) That seems highly unlikely. 2) Do we really anticipate the case where C code is the *only* holder of a traced reference? And more so, it wasn't a parameter to the C code -- the location of parameters is controlled by Modula-3, assuming a pointer-aligned stack. 3) Can't we know/assume/verify that Modula-3 code only stores pointers at more aligned location? My real goal is to make there only be one RTMachine for systems that don't have stack walkers. Leave SOLgnu/SOLsun alone. (Later on implement stack walking for many platforms via libunwind.) There are I believe only two differences to iron out. Allocation size (8K vs. 64K) and PointerAlignment (1 vs. BYTESIZE(INTEGER)). There is a reason for NT to be 64K allocation size -- that is what VirtualAlloc uses. I can test 64K on others. Historically smaller is probably more efficient. These days larger but not *too* large is probably more efficient. 64K should work fine on all platforms. Heck, even something larger like 1MB is probably good. I'll test out 64K. Can/should we have "paranoidgc" imply PointerAlignment = 1, and report whenever a pointer is found at a location with alignment less than BYTESIZE(pointer)? A form of this is reasonable today, right? If PointerAligment = 1, I can have it report any found at less than BYTESIZE(pointer), test it a while, if none found, elevate NT386 to that value? If any found, that'll help educate me/us on why it is 1, and maybe how to change it, or why leave it alone. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Apr 5 13:55:16 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 5 Apr 2010 11:55:16 +0000 Subject: [M3devel] RTMachine.PointerAlignment = 1 on NT? In-Reply-To: References: Message-ID: Interesting: PROCEDURE NoteStackLocations (start, stop: ADDRESS) = VAR fp : UNTRACED REF ADDRESS := start; BEGIN IF NOT (start < stop) THEN RETURN END; stop := stop - ADRSIZE (ADDRESS); (* so we don't overrun the valid addresses *) WHILE fp <= stop DO (* with the memory read on the next line. *) WITH page = AddressToPage(fp^) DO IF page # NIL AND page.desc.space = Space.Previous THEN IF RTMachine.PointerAlignment = 1 THEN IF Word.And(LOOPHOLE(fp, INTEGER), BYTESIZE(INTEGER) - 1) # 0 THEN RTIO.PutText("pointer found on unaligned stack stack="); RTIO.PutAddr(fp); RTIO.PutText(" addr="); RTIO.PutAddr(fp^); RTIO.PutText("\n"); RTIO.Flush(); END; END; IF page.desc.pure THEN PromotePage(page, PromoteReason.AmbiguousPure); ELSE PromotePage(page, PromoteReason.AmbiguousImpure); END; END; END; INC(fp, RTMachine.PointerAlignment); END; END NoteStackLocations; generates a fair amount of output: C:\dev2\cm3.2\m3-sys\mklib>cm3 --- building in NT386 --- ignoring ..\src\m3overrides pointer found on unaligned stack stack=0x12f3d2 addr=0x1400000 pointer found on unaligned stack stack=0x12f11e addr=0x1400000 pointer found on unaligned stack stack=0x12f186 addr=0x1400000 pointer found on unaligned stack stack=0x12f12e addr=0x1780000 pointer found on unaligned stack stack=0x12f1ba addr=0x1400000 pointer found on unaligned stack stack=0x12f442 addr=0x1460147 new source -> compiling Main.m3 pointer found on unaligned stack stack=0x12f3d2 addr=0x1400000 -> linking mklib.exe I need to look a bit more, see what these values are. We are probably being way over conservative, on NT. Such unaligned values as 0x1460147 surely shouldn't count as traced pointers. This example only has one but usually I see many more. C:\dev2\cm3.2\m3-sys\cm3>cm3 --- building in NT386 --- ignoring ..\src\m3overrides pointer found on unaligned stack stack=0x12f3d2 addr=0x1400000 pointer found on unaligned stack stack=0x12f642 addr=0x1400000 pointer found on unaligned stack stack=0x12f176 addr=0x1400000 pointer found on unaligned stack stack=0x12f11e addr=0x1400000 pointer found on unaligned stack stack=0x12f12a addr=0x1780000 pointer found on unaligned stack stack=0x12f1b6 addr=0x1400000 pointer found on unaligned stack stack=0x12f61e addr=0x1400000 pointer found on unaligned stack stack=0x12f6de addr=0x1900069 pointer found on unaligned stack stack=0x12f43e addr=0x1400000 pointer found on unaligned stack stack=0x12f156 addr=0x1400000 pointer found on unaligned stack stack=0x12f66e addr=0x1400000 pointer found on unaligned stack stack=0x12f72e addr=0x1900069 pointer found on unaligned stack stack=0x12f792 addr=0x1cc0000 pointer found on unaligned stack stack=0x12fb26 addr=0x1d7015c pointer found on unaligned stack stack=0x12fb52 addr=0x1d90142 All this scanning around in memory the garbage collector has to do, doesn't that kill working set? It makes all heap and stack part of the working set? Even if I'm not going to access it for long periods? - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Mon, 5 Apr 2010 11:41:10 +0000 Subject: [M3devel] RTMachine.PointerAlignment = 1 on NT? For the vast majority of platforms: RTMachine.PointerAlignment = BYTESIZE(INTEGER). except 1 for NT386, 2 for M68K (dead). PointerAlignment = BYTESIZE(INTEGER); (* The C compiler allocates all pointers on 'PointerAlignment'-byte boundaries. The garbage collector scans thread stacks, but only looks at these possible pointer locations. Setting this value smaller than is needed will only make your system run slower. Setting it too large will cause the collector to collect storage that is not free. *) I suggest this is not exactly true. 1) Of what relevance is the C compiler? vs. the Modula-3 compiler. 2) We really think the number is 1 for NT386? I understand I could say: void F(void* traced) { #pragma pack(1) struct { char a; void* p} = {0, traced}; } but 1) That seems highly unlikely. 2) Do we really anticipate the case where C code is the *only* holder of a traced reference? And more so, it wasn't a parameter to the C code -- the location of parameters is controlled by Modula-3, assuming a pointer-aligned stack. 3) Can't we know/assume/verify that Modula-3 code only stores pointers at more aligned location? My real goal is to make there only be one RTMachine for systems that don't have stack walkers. Leave SOLgnu/SOLsun alone. (Later on implement stack walking for many platforms via libunwind.) There are I believe only two differences to iron out. Allocation size (8K vs. 64K) and PointerAlignment (1 vs. BYTESIZE(INTEGER)). There is a reason for NT to be 64K allocation size -- that is what VirtualAlloc uses. I can test 64K on others. Historically smaller is probably more efficient. These days larger but not *too* large is probably more efficient. 64K should work fine on all platforms. Heck, even something larger like 1MB is probably good. I'll test out 64K. Can/should we have "paranoidgc" imply PointerAlignment = 1, and report whenever a pointer is found at a location with alignment less than BYTESIZE(pointer)? A form of this is reasonable today, right? If PointerAligment = 1, I can have it report any found at less than BYTESIZE(pointer), test it a while, if none found, elevate NT386 to that value? If any found, that'll help educate me/us on why it is 1, and maybe how to change it, or why leave it alone. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Apr 5 14:03:45 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 5 Apr 2010 12:03:45 +0000 Subject: [M3devel] RTMachine.PointerAlignment = 1 on NT? In-Reply-To: References: , Message-ID: hm I guess pointers themselves (not where they are stored) need not have any alignemnt? We might only have a pointer into an array of bytes to keep the array alive, no pointer to the base of the array? PROCEDURE F1() VAR a: ARRAY OF CHAR := NEW(CHAR, 10); i: INTEGER; BEGIN FOR i := FIRST(a) TO LAST(a) DO something with a[i]; END END F1; might only have pointers to elements in a? - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Mon, 5 Apr 2010 11:55:16 +0000 Subject: Re: [M3devel] RTMachine.PointerAlignment = 1 on NT? Interesting: PROCEDURE NoteStackLocations (start, stop: ADDRESS) = VAR fp : UNTRACED REF ADDRESS := start; BEGIN IF NOT (start < stop) THEN RETURN END; stop := stop - ADRSIZE (ADDRESS); (* so we don't overrun the valid addresses *) WHILE fp <= stop DO (* with the memory read on the next line. *) WITH page = AddressToPage(fp^) DO IF page # NIL AND page.desc.space = Space.Previous THEN IF RTMachine.PointerAlignment = 1 THEN IF Word.And(LOOPHOLE(fp, INTEGER), BYTESIZE(INTEGER) - 1) # 0 THEN RTIO.PutText("pointer found on unaligned stack stack="); RTIO.PutAddr(fp); RTIO.PutText(" addr="); RTIO.PutAddr(fp^); RTIO.PutText("\n"); RTIO.Flush(); END; END; IF page.desc.pure THEN PromotePage(page, PromoteReason.AmbiguousPure); ELSE PromotePage(page, PromoteReason.AmbiguousImpure); END; END; END; INC(fp, RTMachine.PointerAlignment); END; END NoteStackLocations; generates a fair amount of output: C:\dev2\cm3.2\m3-sys\mklib>cm3 --- building in NT386 --- ignoring ..\src\m3overrides pointer found on unaligned stack stack=0x12f3d2 addr=0x1400000 pointer found on unaligned stack stack=0x12f11e addr=0x1400000 pointer found on unaligned stack stack=0x12f186 addr=0x1400000 pointer found on unaligned stack stack=0x12f12e addr=0x1780000 pointer found on unaligned stack stack=0x12f1ba addr=0x1400000 pointer found on unaligned stack stack=0x12f442 addr=0x1460147 new source -> compiling Main.m3 pointer found on unaligned stack stack=0x12f3d2 addr=0x1400000 -> linking mklib.exe I need to look a bit more, see what these values are. We are probably being way over conservative, on NT. Such unaligned values as 0x1460147 surely shouldn't count as traced pointers. This example only has one but usually I see many more. C:\dev2\cm3.2\m3-sys\cm3>cm3 --- building in NT386 --- ignoring ..\src\m3overrides pointer found on unaligned stack stack=0x12f3d2 addr=0x1400000 pointer found on unaligned stack stack=0x12f642 addr=0x1400000 pointer found on unaligned stack stack=0x12f176 addr=0x1400000 pointer found on unaligned stack stack=0x12f11e addr=0x1400000 pointer found on unaligned stack stack=0x12f12a addr=0x1780000 pointer found on unaligned stack stack=0x12f1b6 addr=0x1400000 pointer found on unaligned stack stack=0x12f61e addr=0x1400000 pointer found on unaligned stack stack=0x12f6de addr=0x1900069 pointer found on unaligned stack stack=0x12f43e addr=0x1400000 pointer found on unaligned stack stack=0x12f156 addr=0x1400000 pointer found on unaligned stack stack=0x12f66e addr=0x1400000 pointer found on unaligned stack stack=0x12f72e addr=0x1900069 pointer found on unaligned stack stack=0x12f792 addr=0x1cc0000 pointer found on unaligned stack stack=0x12fb26 addr=0x1d7015c pointer found on unaligned stack stack=0x12fb52 addr=0x1d90142 All this scanning around in memory the garbage collector has to do, doesn't that kill working set? It makes all heap and stack part of the working set? Even if I'm not going to access it for long periods? - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Mon, 5 Apr 2010 11:41:10 +0000 Subject: [M3devel] RTMachine.PointerAlignment = 1 on NT? For the vast majority of platforms: RTMachine.PointerAlignment = BYTESIZE(INTEGER). except 1 for NT386, 2 for M68K (dead). PointerAlignment = BYTESIZE(INTEGER); (* The C compiler allocates all pointers on 'PointerAlignment'-byte boundaries. The garbage collector scans thread stacks, but only looks at these possible pointer locations. Setting this value smaller than is needed will only make your system run slower. Setting it too large will cause the collector to collect storage that is not free. *) I suggest this is not exactly true. 1) Of what relevance is the C compiler? vs. the Modula-3 compiler. 2) We really think the number is 1 for NT386? I understand I could say: void F(void* traced) { #pragma pack(1) struct { char a; void* p} = {0, traced}; } but 1) That seems highly unlikely. 2) Do we really anticipate the case where C code is the *only* holder of a traced reference? And more so, it wasn't a parameter to the C code -- the location of parameters is controlled by Modula-3, assuming a pointer-aligned stack. 3) Can't we know/assume/verify that Modula-3 code only stores pointers at more aligned location? My real goal is to make there only be one RTMachine for systems that don't have stack walkers. Leave SOLgnu/SOLsun alone. (Later on implement stack walking for many platforms via libunwind.) There are I believe only two differences to iron out. Allocation size (8K vs. 64K) and PointerAlignment (1 vs. BYTESIZE(INTEGER)). There is a reason for NT to be 64K allocation size -- that is what VirtualAlloc uses. I can test 64K on others. Historically smaller is probably more efficient. These days larger but not *too* large is probably more efficient. 64K should work fine on all platforms. Heck, even something larger like 1MB is probably good. I'll test out 64K. Can/should we have "paranoidgc" imply PointerAlignment = 1, and report whenever a pointer is found at a location with alignment less than BYTESIZE(pointer)? A form of this is reasonable today, right? If PointerAligment = 1, I can have it report any found at less than BYTESIZE(pointer), test it a while, if none found, elevate NT386 to that value? If any found, that'll help educate me/us on why it is 1, and maybe how to change it, or why leave it alone. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Apr 5 16:25:20 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 5 Apr 2010 10:25:20 -0400 Subject: [M3devel] RTMachine.PointerAlignment = 1 on NT? In-Reply-To: References: , Message-ID: <76C0DE79-7904-49B4-AE3F-83632B48CFDD@cs.purdue.edu> Yes, correct. Pointers from the stacks may be "derived" from object base references by the compiler or through use of VAR/READONLY parameters. So, the pointer values from the stack themselves need not be aligned. The PointerAlignment tells the collector at what alignment to expect to find pointers stored in the stack. Some compilers/targets may not require that pointer-valued fields in the stack be stored at aligned locations. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 5 Apr 2010, at 08:03, Jay K wrote: > hm I guess pointers themselves (not where they are stored) need not have any alignemnt? > We might only have a pointer into an array of bytes to keep the array alive, > no pointer to the base of the array? > > PROCEDURE F1() > VAR a: ARRAY OF CHAR := NEW(CHAR, 10); > i: INTEGER; > BEGIN > FOR i := FIRST(a) TO LAST(a) DO > something with a[i]; > END > END F1; > > might only have pointers to elements in a? > > - Jay > > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Mon, 5 Apr 2010 11:55:16 +0000 > Subject: Re: [M3devel] RTMachine.PointerAlignment = 1 on NT? > > Interesting: > > PROCEDURE NoteStackLocations (start, stop: ADDRESS) = > VAR fp : UNTRACED REF ADDRESS := start; > BEGIN > IF NOT (start < stop) THEN RETURN END; > stop := stop - ADRSIZE (ADDRESS); (* so we don't overrun the valid addresses *) > WHILE fp <= stop DO (* with the memory read on the next line. *) > WITH page = AddressToPage(fp^) DO > IF page # NIL AND page.desc.space = Space.Previous THEN > IF RTMachine.PointerAlignment = 1 THEN > IF Word.And(LOOPHOLE(fp, INTEGER), BYTESIZE(INTEGER) - 1) # 0 THEN > RTIO.PutText("pointer found on unaligned stack stack="); > RTIO.PutAddr(fp); > RTIO.PutText(" addr="); > RTIO.PutAddr(fp^); > RTIO.PutText("\n"); > RTIO.Flush(); > END; > END; > IF page.desc.pure > THEN PromotePage(page, PromoteReason.AmbiguousPure); > ELSE PromotePage(page, PromoteReason.AmbiguousImpure); > END; > END; > END; > INC(fp, RTMachine.PointerAlignment); > END; > END NoteStackLocations; > > > generates a fair amount of output: > > > C:\dev2\cm3.2\m3-sys\mklib>cm3 > --- building in NT386 --- > ignoring ..\src\m3overrides > pointer found on unaligned stack stack=0x12f3d2 addr=0x1400000 > pointer found on unaligned stack stack=0x12f11e addr=0x1400000 > pointer found on unaligned stack stack=0x12f186 addr=0x1400000 > pointer found on unaligned stack stack=0x12f12e addr=0x1780000 > pointer found on unaligned stack stack=0x12f1ba addr=0x1400000 > pointer found on unaligned stack stack=0x12f442 addr=0x1460147 > new source -> compiling Main.m3 > pointer found on unaligned stack stack=0x12f3d2 addr=0x1400000 > -> linking mklib.exe > > > I need to look a bit more, see what these values are. > We are probably being way over conservative, on NT. > Such unaligned values as 0x1460147 surely shouldn't count as traced pointers. > This example only has one but usually I see many more. > > > C:\dev2\cm3.2\m3-sys\cm3>cm3 > --- building in NT386 --- > ignoring ..\src\m3overrides > pointer found on unaligned stack stack=0x12f3d2 addr=0x1400000 > pointer found on unaligned stack stack=0x12f642 addr=0x1400000 > pointer found on unaligned stack stack=0x12f176 addr=0x1400000 > pointer found on unaligned stack stack=0x12f11e addr=0x1400000 > pointer found on unaligned stack stack=0x12f12a addr=0x1780000 > pointer found on unaligned stack stack=0x12f1b6 addr=0x1400000 > pointer found on unaligned stack stack=0x12f61e addr=0x1400000 > pointer found on unaligned stack stack=0x12f6de addr=0x1900069 > pointer found on unaligned stack stack=0x12f43e addr=0x1400000 > pointer found on unaligned stack stack=0x12f156 addr=0x1400000 > pointer found on unaligned stack stack=0x12f66e addr=0x1400000 > pointer found on unaligned stack stack=0x12f72e addr=0x1900069 > pointer found on unaligned stack stack=0x12f792 addr=0x1cc0000 > pointer found on unaligned stack stack=0x12fb26 addr=0x1d7015c > pointer found on unaligned stack stack=0x12fb52 addr=0x1d90142 > > > All this scanning around in memory the garbage collector has to do, doesn't that kill working set? > It makes all heap and stack part of the working set? Even if I'm not going to access it for long periods? > > > - Jay > > > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Mon, 5 Apr 2010 11:41:10 +0000 > Subject: [M3devel] RTMachine.PointerAlignment = 1 on NT? > > For the vast majority of platforms: > > > RTMachine.PointerAlignment = BYTESIZE(INTEGER). > > > except 1 for NT386, 2 for M68K (dead). > > > PointerAlignment = BYTESIZE(INTEGER); > (* The C compiler allocates all pointers on 'PointerAlignment'-byte > boundaries. The garbage collector scans thread stacks, but only > looks at these possible pointer locations. Setting this value > smaller than is needed will only make your system run slower. > Setting it too large will cause the collector to collect storage > that is not free. *) > > > I suggest this is not exactly true. > 1) Of what relevance is the C compiler? vs. the Modula-3 compiler. > 2) We really think the number is 1 for NT386? > > I understand I could say: > void F(void* traced) > { > #pragma pack(1) > struct { char a; void* p} = {0, traced}; > } > > but > 1) That seems highly unlikely. > 2) Do we really anticipate the case where C code is the *only* holder of a traced reference? > And more so, it wasn't a parameter to the C code -- the location of parameters is controlled by Modula-3, assuming a pointer-aligned stack. > 3) Can't we know/assume/verify that Modula-3 code only stores pointers at more aligned location? > > > My real goal is to make there only be one RTMachine for systems that don't have stack walkers. > Leave SOLgnu/SOLsun alone. > (Later on implement stack walking for many platforms via libunwind.) > > > There are I believe only two differences to iron out. Allocation size (8K vs. 64K) and PointerAlignment (1 vs. BYTESIZE(INTEGER)). > There is a reason for NT to be 64K allocation size -- that is what VirtualAlloc uses. > I can test 64K on others. > Historically smaller is probably more efficient. > These days larger but not *too* large is probably more efficient. > 64K should work fine on all platforms. Heck, even something larger like 1MB is probably good. > I'll test out 64K. > > > Can/should we have "paranoidgc" imply PointerAlignment = 1, and report whenever a pointer is found at a location with alignment less than BYTESIZE(pointer)? > > > A form of this is reasonable today, right? If PointerAligment = 1, I can have it report any found at less than BYTESIZE(pointer), test it a while, if none found, elevate NT386 to that value? > If any found, that'll help educate me/us on why it is 1, and maybe how to change it, or why leave it alone. > > > - Jay > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Apr 5 16:40:36 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 5 Apr 2010 14:40:36 +0000 Subject: [M3devel] RTMachine.PointerAlignment = 1 on NT? In-Reply-To: <76C0DE79-7904-49B4-AE3F-83632B48CFDD@cs.purdue.edu> References: , , <76C0DE79-7904-49B4-AE3F-83632B48CFDD@cs.purdue.edu> Message-ID: I think we can safely dispense with RTMachine.PointerAlignment and use BYTESIZE(INTEGER). NT386 is the only current exception. Even though it isn't required, of any x86 target, it seems the overwhelming practice. - Jay Subject: Re: [M3devel] RTMachine.PointerAlignment = 1 on NT? From: hosking at cs.purdue.edu Date: Mon, 5 Apr 2010 10:25:20 -0400 CC: m3devel at elegosoft.com To: jay.krell at cornell.edu Yes, correct. Pointers from the stacks may be "derived" from object base references by the compiler or through use of VAR/READONLY parameters. So, the pointer values from the stack themselves need not be aligned. The PointerAlignment tells the collector at what alignment to expect to find pointers stored in the stack. Some compilers/targets may not require that pointer-valued fields in the stack be stored at aligned locations. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 5 Apr 2010, at 08:03, Jay K wrote: hm I guess pointers themselves (not where they are stored) need not have any alignemnt? We might only have a pointer into an array of bytes to keep the array alive, no pointer to the base of the array? PROCEDURE F1() VAR a: ARRAY OF CHAR := NEW(CHAR, 10); i: INTEGER; BEGIN FOR i := FIRST(a) TO LAST(a) DO something with a[i]; END END F1; might only have pointers to elements in a? - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Mon, 5 Apr 2010 11:55:16 +0000 Subject: Re: [M3devel] RTMachine.PointerAlignment = 1 on NT? Interesting: PROCEDURE NoteStackLocations (start, stop: ADDRESS) = VAR fp : UNTRACED REF ADDRESS := start; BEGIN IF NOT (start < stop) THEN RETURN END; stop := stop - ADRSIZE (ADDRESS); (* so we don't overrun the valid addresses *) WHILE fp <= stop DO (* with the memory read on the next line. *) WITH page = AddressToPage(fp^) DO IF page # NIL AND page.desc.space = Space.Previous THEN IF RTMachine.PointerAlignment = 1 THEN IF Word.And(LOOPHOLE(fp, INTEGER), BYTESIZE(INTEGER) - 1) # 0 THEN RTIO.PutText("pointer found on unaligned stack stack="); RTIO.PutAddr(fp); RTIO.PutText(" addr="); RTIO.PutAddr(fp^); RTIO.PutText("\n"); RTIO.Flush(); END; END; IF page.desc.pure THEN PromotePage(page, PromoteReason.AmbiguousPure); ELSE PromotePage(page, PromoteReason.AmbiguousImpure); END; END; END; INC(fp, RTMachine.PointerAlignment); END; END NoteStackLocations; generates a fair amount of output: C:\dev2\cm3.2\m3-sys\mklib>cm3 --- building in NT386 --- ignoring ..\src\m3overrides pointer found on unaligned stack stack=0x12f3d2 addr=0x1400000 pointer found on unaligned stack stack=0x12f11e addr=0x1400000 pointer found on unaligned stack stack=0x12f186 addr=0x1400000 pointer found on unaligned stack stack=0x12f12e addr=0x1780000 pointer found on unaligned stack stack=0x12f1ba addr=0x1400000 pointer found on unaligned stack stack=0x12f442 addr=0x1460147 new source -> compiling Main.m3 pointer found on unaligned stack stack=0x12f3d2 addr=0x1400000 -> linking mklib.exe I need to look a bit more, see what these values are. We are probably being way over conservative, on NT. Such unaligned values as 0x1460147 surely shouldn't count as traced pointers. This example only has one but usually I see many more. C:\dev2\cm3.2\m3-sys\cm3>cm3 --- building in NT386 --- ignoring ..\src\m3overrides pointer found on unaligned stack stack=0x12f3d2 addr=0x1400000 pointer found on unaligned stack stack=0x12f642 addr=0x1400000 pointer found on unaligned stack stack=0x12f176 addr=0x1400000 pointer found on unaligned stack stack=0x12f11e addr=0x1400000 pointer found on unaligned stack stack=0x12f12a addr=0x1780000 pointer found on unaligned stack stack=0x12f1b6 addr=0x1400000 pointer found on unaligned stack stack=0x12f61e addr=0x1400000 pointer found on unaligned stack stack=0x12f6de addr=0x1900069 pointer found on unaligned stack stack=0x12f43e addr=0x1400000 pointer found on unaligned stack stack=0x12f156 addr=0x1400000 pointer found on unaligned stack stack=0x12f66e addr=0x1400000 pointer found on unaligned stack stack=0x12f72e addr=0x1900069 pointer found on unaligned stack stack=0x12f792 addr=0x1cc0000 pointer found on unaligned stack stack=0x12fb26 addr=0x1d7015c pointer found on unaligned stack stack=0x12fb52 addr=0x1d90142 All this scanning around in memory the garbage collector has to do, doesn't that kill working set? It makes all heap and stack part of the working set? Even if I'm not going to access it for long periods? - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Mon, 5 Apr 2010 11:41:10 +0000 Subject: [M3devel] RTMachine.PointerAlignment = 1 on NT? For the vast majority of platforms: RTMachine.PointerAlignment = BYTESIZE(INTEGER). except 1 for NT386, 2 for M68K (dead). PointerAlignment = BYTESIZE(INTEGER); (* The C compiler allocates all pointers on 'PointerAlignment'-byte boundaries. The garbage collector scans thread stacks, but only looks at these possible pointer locations. Setting this value smaller than is needed will only make your system run slower. Setting it too large will cause the collector to collect storage that is not free. *) I suggest this is not exactly true. 1) Of what relevance is the C compiler? vs. the Modula-3 compiler. 2) We really think the number is 1 for NT386? I understand I could say: void F(void* traced) { #pragma pack(1) struct { char a; void* p} = {0, traced}; } but 1) That seems highly unlikely. 2) Do we really anticipate the case where C code is the *only* holder of a traced reference? And more so, it wasn't a parameter to the C code -- the location of parameters is controlled by Modula-3, assuming a pointer-aligned stack. 3) Can't we know/assume/verify that Modula-3 code only stores pointers at more aligned location? My real goal is to make there only be one RTMachine for systems that don't have stack walkers. Leave SOLgnu/SOLsun alone. (Later on implement stack walking for many platforms via libunwind.) There are I believe only two differences to iron out. Allocation size (8K vs. 64K) and PointerAlignment (1 vs. BYTESIZE(INTEGER)). There is a reason for NT to be 64K allocation size -- that is what VirtualAlloc uses. I can test 64K on others. Historically smaller is probably more efficient. These days larger but not *too* large is probably more efficient. 64K should work fine on all platforms. Heck, even something larger like 1MB is probably good. I'll test out 64K. Can/should we have "paranoidgc" imply PointerAlignment = 1, and report whenever a pointer is found at a location with alignment less than BYTESIZE(pointer)? A form of this is reasonable today, right? If PointerAligment = 1, I can have it report any found at less than BYTESIZE(pointer), test it a while, if none found, elevate NT386 to that value? If any found, that'll help educate me/us on why it is 1, and maybe how to change it, or why leave it alone. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Apr 5 19:31:45 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 5 Apr 2010 13:31:45 -0400 Subject: [M3devel] RTMachine.PointerAlignment = 1 on NT? In-Reply-To: References: , , <76C0DE79-7904-49B4-AE3F-83632B48CFDD@cs.purdue.edu> Message-ID: More accurately, BYTESIZE(ADDRESS)? Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 5 Apr 2010, at 10:40, Jay K wrote: > I think we can safely dispense with RTMachine.PointerAlignment and use BYTESIZE(INTEGER). > NT386 is the only current exception. > Even though it isn't required, of any x86 target, it seems the overwhelming practice. > > - Jay > > Subject: Re: [M3devel] RTMachine.PointerAlignment = 1 on NT? > From: hosking at cs.purdue.edu > Date: Mon, 5 Apr 2010 10:25:20 -0400 > CC: m3devel at elegosoft.com > To: jay.krell at cornell.edu > > Yes, correct. Pointers from the stacks may be "derived" from object base references by the compiler or through use of VAR/READONLY parameters. So, the pointer values from the stack themselves need not be aligned. The PointerAlignment tells the collector at what alignment to expect to find pointers stored in the stack. Some compilers/targets may not require that pointer-valued fields in the stack be stored at aligned locations. > > > > Antony Hosking | Associate Professor | Computer Science | Purdue University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > On 5 Apr 2010, at 08:03, Jay K wrote: > > hm I guess pointers themselves (not where they are stored) need not have any alignemnt? > We might only have a pointer into an array of bytes to keep the array alive, > no pointer to the base of the array? > > PROCEDURE F1() > VAR a: ARRAY OF CHAR := NEW(CHAR, 10); > i: INTEGER; > BEGIN > FOR i := FIRST(a) TO LAST(a) DO > something with a[i]; > END > END F1; > > might only have pointers to elements in a? > > - Jay > > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Mon, 5 Apr 2010 11:55:16 +0000 > Subject: Re: [M3devel] RTMachine.PointerAlignment = 1 on NT? > > Interesting: > > PROCEDURE NoteStackLocations (start, stop: ADDRESS) = > VAR fp : UNTRACED REF ADDRESS := start; > BEGIN > IF NOT (start < stop) THEN RETURN END; > stop := stop - ADRSIZE (ADDRESS); (* so we don't overrun the valid addresses *) > WHILE fp <= stop DO (* with the memory read on the next line. *) > WITH page = AddressToPage(fp^) DO > IF page # NIL AND page.desc.space = Space.Previous THEN > IF RTMachine.PointerAlignment = 1 THEN > IF Word.And(LOOPHOLE(fp, INTEGER), BYTESIZE(INTEGER) - 1) # 0 THEN > RTIO.PutText("pointer found on unaligned stack stack="); > RTIO.PutAddr(fp); > RTIO.PutText(" addr="); > RTIO.PutAddr(fp^); > RTIO.PutText("\n"); > RTIO.Flush(); > END; > END; > IF page.desc.pure > THEN PromotePage(page, PromoteReason.AmbiguousPure); > ELSE PromotePage(page, PromoteReason.AmbiguousImpure); > END; > END; > END; > INC(fp, RTMachine.PointerAlignment); > END; > END NoteStackLocations; > > > generates a fair amount of output: > > > C:\dev2\cm3.2\m3-sys\mklib>cm3 > --- building in NT386 --- > ignoring ..\src\m3overrides > pointer found on unaligned stack stack=0x12f3d2 addr=0x1400000 > pointer found on unaligned stack stack=0x12f11e addr=0x1400000 > pointer found on unaligned stack stack=0x12f186 addr=0x1400000 > pointer found on unaligned stack stack=0x12f12e addr=0x1780000 > pointer found on unaligned stack stack=0x12f1ba addr=0x1400000 > pointer found on unaligned stack stack=0x12f442 addr=0x1460147 > new source -> compiling Main.m3 > pointer found on unaligned stack stack=0x12f3d2 addr=0x1400000 > -> linking mklib.exe > > > I need to look a bit more, see what these values are. > We are probably being way over conservative, on NT. > Such unaligned values as 0x1460147 surely shouldn't count as traced pointers. > This example only has one but usually I see many more. > > > C:\dev2\cm3.2\m3-sys\cm3>cm3 > --- building in NT386 --- > ignoring ..\src\m3overrides > pointer found on unaligned stack stack=0x12f3d2 addr=0x1400000 > pointer found on unaligned stack stack=0x12f642 addr=0x1400000 > pointer found on unaligned stack stack=0x12f176 addr=0x1400000 > pointer found on unaligned stack stack=0x12f11e addr=0x1400000 > pointer found on unaligned stack stack=0x12f12a addr=0x1780000 > pointer found on unaligned stack stack=0x12f1b6 addr=0x1400000 > pointer found on unaligned stack stack=0x12f61e addr=0x1400000 > pointer found on unaligned stack stack=0x12f6de addr=0x1900069 > pointer found on unaligned stack stack=0x12f43e addr=0x1400000 > pointer found on unaligned stack stack=0x12f156 addr=0x1400000 > pointer found on unaligned stack stack=0x12f66e addr=0x1400000 > pointer found on unaligned stack stack=0x12f72e addr=0x1900069 > pointer found on unaligned stack stack=0x12f792 addr=0x1cc0000 > pointer found on unaligned stack stack=0x12fb26 addr=0x1d7015c > pointer found on unaligned stack stack=0x12fb52 addr=0x1d90142 > > > All this scanning around in memory the garbage collector has to do, doesn't that kill working set? > It makes all heap and stack part of the working set? Even if I'm not going to access it for long periods? > > > - Jay > > > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Mon, 5 Apr 2010 11:41:10 +0000 > Subject: [M3devel] RTMachine.PointerAlignment = 1 on NT? > > For the vast majority of platforms: > > > RTMachine.PointerAlignment = BYTESIZE(INTEGER). > > > except 1 for NT386, 2 for M68K (dead). > > > PointerAlignment = BYTESIZE(INTEGER); > (* The C compiler allocates all pointers on 'PointerAlignment'-byte > boundaries. The garbage collector scans thread stacks, but only > looks at these possible pointer locations. Setting this value > smaller than is needed will only make your system run slower. > Setting it too large will cause the collector to collect storage > that is not free. *) > > > I suggest this is not exactly true. > 1) Of what relevance is the C compiler? vs. the Modula-3 compiler. > 2) We really think the number is 1 for NT386? > > I understand I could say: > void F(void* traced) > { > #pragma pack(1) > struct { char a; void* p} = {0, traced}; > } > > but > 1) That seems highly unlikely. > 2) Do we really anticipate the case where C code is the *only* holder of a traced reference? > And more so, it wasn't a parameter to the C code -- the location of parameters is controlled by Modula-3, assuming a pointer-aligned stack. > 3) Can't we know/assume/verify that Modula-3 code only stores pointers at more aligned location? > > > My real goal is to make there only be one RTMachine for systems that don't have stack walkers. > Leave SOLgnu/SOLsun alone. > (Later on implement stack walking for many platforms via libunwind.) > > > There are I believe only two differences to iron out. Allocation size (8K vs. 64K) and PointerAlignment (1 vs. BYTESIZE(INTEGER)). > There is a reason for NT to be 64K allocation size -- that is what VirtualAlloc uses. > I can test 64K on others. > Historically smaller is probably more efficient. > These days larger but not *too* large is probably more efficient. > 64K should work fine on all platforms. Heck, even something larger like 1MB is probably good. > I'll test out 64K. > > > Can/should we have "paranoidgc" imply PointerAlignment = 1, and report whenever a pointer is found at a location with alignment less than BYTESIZE(pointer)? > > > A form of this is reasonable today, right? If PointerAligment = 1, I can have it report any found at less than BYTESIZE(pointer), test it a while, if none found, elevate NT386 to that value? > If any found, that'll help educate me/us on why it is 1, and maybe how to change it, or why leave it alone. > > > - Jay > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Apr 6 00:03:25 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 5 Apr 2010 22:03:25 +0000 Subject: [M3devel] RTMachine.PointerAlignment = 1 on NT? In-Reply-To: References: , , , , , <76C0DE79-7904-49B4-AE3F-83632B48CFDD@cs.purdue.edu>, , Message-ID: Yes. Same thing. - Jay From: hosking at cs.purdue.edu Date: Mon, 5 Apr 2010 13:31:45 -0400 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] RTMachine.PointerAlignment = 1 on NT? More accurately, BYTESIZE(ADDRESS)? Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 5 Apr 2010, at 10:40, Jay K wrote: I think we can safely dispense with RTMachine.PointerAlignment and use BYTESIZE(INTEGER). NT386 is the only current exception. Even though it isn't required, of any x86 target, it seems the overwhelming practice. - Jay Subject: Re: [M3devel] RTMachine.PointerAlignment = 1 on NT? From: hosking at cs.purdue.edu Date: Mon, 5 Apr 2010 10:25:20 -0400 CC: m3devel at elegosoft.com To: jay.krell at cornell.edu Yes, correct. Pointers from the stacks may be "derived" from object base references by the compiler or through use of VAR/READONLY parameters. So, the pointer values from the stack themselves need not be aligned. The PointerAlignment tells the collector at what alignment to expect to find pointers stored in the stack. Some compilers/targets may not require that pointer-valued fields in the stack be stored at aligned locations. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 5 Apr 2010, at 08:03, Jay K wrote: hm I guess pointers themselves (not where they are stored) need not have any alignemnt? We might only have a pointer into an array of bytes to keep the array alive, no pointer to the base of the array? PROCEDURE F1() VAR a: ARRAY OF CHAR := NEW(CHAR, 10); i: INTEGER; BEGIN FOR i := FIRST(a) TO LAST(a) DO something with a[i]; END END F1; might only have pointers to elements in a? - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Mon, 5 Apr 2010 11:55:16 +0000 Subject: Re: [M3devel] RTMachine.PointerAlignment = 1 on NT? Interesting: PROCEDURE NoteStackLocations (start, stop: ADDRESS) = VAR fp : UNTRACED REF ADDRESS := start; BEGIN IF NOT (start < stop) THEN RETURN END; stop := stop - ADRSIZE (ADDRESS); (* so we don't overrun the valid addresses *) WHILE fp <= stop DO (* with the memory read on the next line. *) WITH page = AddressToPage(fp^) DO IF page # NIL AND page.desc.space = Space.Previous THEN IF RTMachine.PointerAlignment = 1 THEN IF Word.And(LOOPHOLE(fp, INTEGER), BYTESIZE(INTEGER) - 1) # 0 THEN RTIO.PutText("pointer found on unaligned stack stack="); RTIO.PutAddr(fp); RTIO.PutText(" addr="); RTIO.PutAddr(fp^); RTIO.PutText("\n"); RTIO.Flush(); END; END; IF page.desc.pure THEN PromotePage(page, PromoteReason.AmbiguousPure); ELSE PromotePage(page, PromoteReason.AmbiguousImpure); END; END; END; INC(fp, RTMachine.PointerAlignment); END; END NoteStackLocations; generates a fair amount of output: C:\dev2\cm3.2\m3-sys\mklib>cm3 --- building in NT386 --- ignoring ..\src\m3overrides pointer found on unaligned stack stack=0x12f3d2 addr=0x1400000 pointer found on unaligned stack stack=0x12f11e addr=0x1400000 pointer found on unaligned stack stack=0x12f186 addr=0x1400000 pointer found on unaligned stack stack=0x12f12e addr=0x1780000 pointer found on unaligned stack stack=0x12f1ba addr=0x1400000 pointer found on unaligned stack stack=0x12f442 addr=0x1460147 new source -> compiling Main.m3 pointer found on unaligned stack stack=0x12f3d2 addr=0x1400000 -> linking mklib.exe I need to look a bit more, see what these values are. We are probably being way over conservative, on NT. Such unaligned values as 0x1460147 surely shouldn't count as traced pointers. This example only has one but usually I see many more. C:\dev2\cm3.2\m3-sys\cm3>cm3 --- building in NT386 --- ignoring ..\src\m3overrides pointer found on unaligned stack stack=0x12f3d2 addr=0x1400000 pointer found on unaligned stack stack=0x12f642 addr=0x1400000 pointer found on unaligned stack stack=0x12f176 addr=0x1400000 pointer found on unaligned stack stack=0x12f11e addr=0x1400000 pointer found on unaligned stack stack=0x12f12a addr=0x1780000 pointer found on unaligned stack stack=0x12f1b6 addr=0x1400000 pointer found on unaligned stack stack=0x12f61e addr=0x1400000 pointer found on unaligned stack stack=0x12f6de addr=0x1900069 pointer found on unaligned stack stack=0x12f43e addr=0x1400000 pointer found on unaligned stack stack=0x12f156 addr=0x1400000 pointer found on unaligned stack stack=0x12f66e addr=0x1400000 pointer found on unaligned stack stack=0x12f72e addr=0x1900069 pointer found on unaligned stack stack=0x12f792 addr=0x1cc0000 pointer found on unaligned stack stack=0x12fb26 addr=0x1d7015c pointer found on unaligned stack stack=0x12fb52 addr=0x1d90142 All this scanning around in memory the garbage collector has to do, doesn't that kill working set? It makes all heap and stack part of the working set? Even if I'm not going to access it for long periods? - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Mon, 5 Apr 2010 11:41:10 +0000 Subject: [M3devel] RTMachine.PointerAlignment = 1 on NT? For the vast majority of platforms: RTMachine.PointerAlignment = BYTESIZE(INTEGER). except 1 for NT386, 2 for M68K (dead). PointerAlignment = BYTESIZE(INTEGER); (* The C compiler allocates all pointers on 'PointerAlignment'-byte boundaries. The garbage collector scans thread stacks, but only looks at these possible pointer locations. Setting this value smaller than is needed will only make your system run slower. Setting it too large will cause the collector to collect storage that is not free. *) I suggest this is not exactly true. 1) Of what relevance is the C compiler? vs. the Modula-3 compiler. 2) We really think the number is 1 for NT386? I understand I could say: void F(void* traced) { #pragma pack(1) struct { char a; void* p} = {0, traced}; } but 1) That seems highly unlikely. 2) Do we really anticipate the case where C code is the *only* holder of a traced reference? And more so, it wasn't a parameter to the C code -- the location of parameters is controlled by Modula-3, assuming a pointer-aligned stack. 3) Can't we know/assume/verify that Modula-3 code only stores pointers at more aligned location? My real goal is to make there only be one RTMachine for systems that don't have stack walkers. Leave SOLgnu/SOLsun alone. (Later on implement stack walking for many platforms via libunwind.) There are I believe only two differences to iron out. Allocation size (8K vs. 64K) and PointerAlignment (1 vs. BYTESIZE(INTEGER)). There is a reason for NT to be 64K allocation size -- that is what VirtualAlloc uses. I can test 64K on others. Historically smaller is probably more efficient. These days larger but not *too* large is probably more efficient. 64K should work fine on all platforms. Heck, even something larger like 1MB is probably good. I'll test out 64K. Can/should we have "paranoidgc" imply PointerAlignment = 1, and report whenever a pointer is found at a location with alignment less than BYTESIZE(pointer)? A form of this is reasonable today, right? If PointerAligment = 1, I can have it report any found at less than BYTESIZE(pointer), test it a while, if none found, elevate NT386 to that value? If any found, that'll help educate me/us on why it is 1, and maybe how to change it, or why leave it alone. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Tue Apr 6 01:35:32 2010 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Tue, 06 Apr 2010 01:35:32 +0200 Subject: [M3devel] lock performance, random thoughts Message-ID: <1270510533.10280.32.camel@faramir.m3w.org> I've been thinking few days about this lock performance thing. As POSIX mutexes are getting us too many times into kernel space by way of syscalls, maybe we can get some performance back while not loosing scheduling efficiency and multi-processor side of kernel-space/POSIX threading? User-space threads were two things. One - user-space threads. Two - user-space synchronizing. If we implement former inCritical by using lockfree abilities of modern multi-processor/multi-core/cluster systems and then revert to user-space synchronizing _only_ we can have best of both worlds. We need user-space threads because we need to have our Modula-3 process spread it's threads over whatever we run it on. And we will be very happy to have synchronizing efficency back. Few details to decide how to implement would be preempting/wakeup cycle, and waiting loop on our inCritical flag. Both can be solved by POSIX primitives. What do you think about this? dd -- Dragi?a Duri? From hosking at cs.purdue.edu Tue Apr 6 01:44:02 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 5 Apr 2010 19:44:02 -0400 Subject: [M3devel] RTMachine.PointerAlignment = 1 on NT? In-Reply-To: References: , , , , , <76C0DE79-7904-49B4-AE3F-83632B48CFDD@cs.purdue.edu>, , Message-ID: Same thing only for implementations where BYTESIZE(Word.T) = BYTESIZE(INTEGER) = BYTESIZE(ADDRESS). But that's all of ours. On 5 Apr 2010, at 18:03, Jay K wrote: > Yes. Same thing. > > - Jay > > From: hosking at cs.purdue.edu > Date: Mon, 5 Apr 2010 13:31:45 -0400 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] RTMachine.PointerAlignment = 1 on NT? > > More accurately, BYTESIZE(ADDRESS)? > > Antony Hosking | Associate Professor | Computer Science | Purdue University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > On 5 Apr 2010, at 10:40, Jay K wrote: > > I think we can safely dispense with RTMachine.PointerAlignment and use BYTESIZE(INTEGER). > NT386 is the only current exception. > Even though it isn't required, of any x86 target, it seems the overwhelming practice. > > - Jay > > Subject: Re: [M3devel] RTMachine.PointerAlignment = 1 on NT? > From: hosking at cs.purdue.edu > Date: Mon, 5 Apr 2010 10:25:20 -0400 > CC: m3devel at elegosoft.com > To: jay.krell at cornell.edu > > Yes, correct. Pointers from the stacks may be "derived" from object base references by the compiler or through use of VAR/READONLY parameters. So, the pointer values from the stack themselves need not be aligned. The PointerAlignment tells the collector at what alignment to expect to find pointers stored in the stack. Some compilers/targets may not require that pointer-valued fields in the stack be stored at aligned locations. > > > > Antony Hosking | Associate Professor | Computer Science | Purdue University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > On 5 Apr 2010, at 08:03, Jay K wrote: > > hm I guess pointers themselves (not where they are stored) need not have any alignemnt? > We might only have a pointer into an array of bytes to keep the array alive, > no pointer to the base of the array? > > PROCEDURE F1() > VAR a: ARRAY OF CHAR := NEW(CHAR, 10); > i: INTEGER; > BEGIN > FOR i := FIRST(a) TO LAST(a) DO > something with a[i]; > END > END F1; > > might only have pointers to elements in a? > > - Jay > > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Mon, 5 Apr 2010 11:55:16 +0000 > Subject: Re: [M3devel] RTMachine.PointerAlignment = 1 on NT? > > Interesting: > > PROCEDURE NoteStackLocations (start, stop: ADDRESS) = > VAR fp : UNTRACED REF ADDRESS := start; > BEGIN > IF NOT (start < stop) THEN RETURN END; > stop := stop - ADRSIZE (ADDRESS); (* so we don't overrun the valid addresses *) > WHILE fp <= stop DO (* with the memory read on the next line. *) > WITH page = AddressToPage(fp^) DO > IF page # NIL AND page.desc.space = Space.Previous THEN > IF RTMachine.PointerAlignment = 1 THEN > IF Word.And(LOOPHOLE(fp, INTEGER), BYTESIZE(INTEGER) - 1) # 0 THEN > RTIO.PutText("pointer found on unaligned stack stack="); > RTIO.PutAddr(fp); > RTIO.PutText(" addr="); > RTIO.PutAddr(fp^); > RTIO.PutText("\n"); > RTIO.Flush(); > END; > END; > IF page.desc.pure > THEN PromotePage(page, PromoteReason.AmbiguousPure); > ELSE PromotePage(page, PromoteReason.AmbiguousImpure); > END; > END; > END; > INC(fp, RTMachine.PointerAlignment); > END; > END NoteStackLocations; > > > generates a fair amount of output: > > > C:\dev2\cm3.2\m3-sys\mklib>cm3 > --- building in NT386 --- > ignoring ..\src\m3overrides > pointer found on unaligned stack stack=0x12f3d2 addr=0x1400000 > pointer found on unaligned stack stack=0x12f11e addr=0x1400000 > pointer found on unaligned stack stack=0x12f186 addr=0x1400000 > pointer found on unaligned stack stack=0x12f12e addr=0x1780000 > pointer found on unaligned stack stack=0x12f1ba addr=0x1400000 > pointer found on unaligned stack stack=0x12f442 addr=0x1460147 > new source -> compiling Main.m3 > pointer found on unaligned stack stack=0x12f3d2 addr=0x1400000 > -> linking mklib.exe > > > I need to look a bit more, see what these values are. > We are probably being way over conservative, on NT. > Such unaligned values as 0x1460147 surely shouldn't count as traced pointers. > This example only has one but usually I see many more. > > > C:\dev2\cm3.2\m3-sys\cm3>cm3 > --- building in NT386 --- > ignoring ..\src\m3overrides > pointer found on unaligned stack stack=0x12f3d2 addr=0x1400000 > pointer found on unaligned stack stack=0x12f642 addr=0x1400000 > pointer found on unaligned stack stack=0x12f176 addr=0x1400000 > pointer found on unaligned stack stack=0x12f11e addr=0x1400000 > pointer found on unaligned stack stack=0x12f12a addr=0x1780000 > pointer found on unaligned stack stack=0x12f1b6 addr=0x1400000 > pointer found on unaligned stack stack=0x12f61e addr=0x1400000 > pointer found on unaligned stack stack=0x12f6de addr=0x1900069 > pointer found on unaligned stack stack=0x12f43e addr=0x1400000 > pointer found on unaligned stack stack=0x12f156 addr=0x1400000 > pointer found on unaligned stack stack=0x12f66e addr=0x1400000 > pointer found on unaligned stack stack=0x12f72e addr=0x1900069 > pointer found on unaligned stack stack=0x12f792 addr=0x1cc0000 > pointer found on unaligned stack stack=0x12fb26 addr=0x1d7015c > pointer found on unaligned stack stack=0x12fb52 addr=0x1d90142 > > > All this scanning around in memory the garbage collector has to do, doesn't that kill working set? > It makes all heap and stack part of the working set? Even if I'm not going to access it for long periods? > > > - Jay > > > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Mon, 5 Apr 2010 11:41:10 +0000 > Subject: [M3devel] RTMachine.PointerAlignment = 1 on NT? > > For the vast majority of platforms: > > > RTMachine.PointerAlignment = BYTESIZE(INTEGER). > > > except 1 for NT386, 2 for M68K (dead). > > > PointerAlignment = BYTESIZE(INTEGER); > (* The C compiler allocates all pointers on 'PointerAlignment'-byte > boundaries. The garbage collector scans thread stacks, but only > looks at these possible pointer locations. Setting this value > smaller than is needed will only make your system run slower. > Setting it too large will cause the collector to collect storage > that is not free. *) > > > I suggest this is not exactly true. > 1) Of what relevance is the C compiler? vs. the Modula-3 compiler. > 2) We really think the number is 1 for NT386? > > I understand I could say: > void F(void* traced) > { > #pragma pack(1) > struct { char a; void* p} = {0, traced}; > } > > but > 1) That seems highly unlikely. > 2) Do we really anticipate the case where C code is the *only* holder of a traced reference? > And more so, it wasn't a parameter to the C code -- the location of parameters is controlled by Modula-3, assuming a pointer-aligned stack. > 3) Can't we know/assume/verify that Modula-3 code only stores pointers at more aligned location? > > > My real goal is to make there only be one RTMachine for systems that don't have stack walkers. > Leave SOLgnu/SOLsun alone. > (Later on implement stack walking for many platforms via libunwind.) > > > There are I believe only two differences to iron out. Allocation size (8K vs. 64K) and PointerAlignment (1 vs. BYTESIZE(INTEGER)). > There is a reason for NT to be 64K allocation size -- that is what VirtualAlloc uses. > I can test 64K on others. > Historically smaller is probably more efficient. > These days larger but not *too* large is probably more efficient. > 64K should work fine on all platforms. Heck, even something larger like 1MB is probably good. > I'll test out 64K. > > > Can/should we have "paranoidgc" imply PointerAlignment = 1, and report whenever a pointer is found at a location with alignment less than BYTESIZE(pointer)? > > > A form of this is reasonable today, right? If PointerAligment = 1, I can have it report any found at less than BYTESIZE(pointer), test it a while, if none found, elevate NT386 to that value? > If any found, that'll help educate me/us on why it is 1, and maybe how to change it, or why leave it alone. > > > - Jay > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Apr 6 01:45:20 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 5 Apr 2010 19:45:20 -0400 Subject: [M3devel] lock performance, random thoughts In-Reply-To: <1270510533.10280.32.camel@faramir.m3w.org> References: <1270510533.10280.32.camel@faramir.m3w.org> Message-ID: <1F5A794A-40AB-4F94-B11A-9218DAA30ED4@cs.purdue.edu> Yes, that's pretty much what modern Java implementations do. On 5 Apr 2010, at 19:35, Dragi?a Duri? wrote: > I've been thinking few days about this lock performance thing. As POSIX > mutexes are getting us too many times into kernel space by way of > syscalls, maybe we can get some performance back while not loosing > scheduling efficiency and multi-processor side of kernel-space/POSIX > threading? > > User-space threads were two things. One - user-space threads. Two - > user-space synchronizing. If we implement former inCritical by using > lockfree abilities of modern multi-processor/multi-core/cluster systems > and then revert to user-space synchronizing _only_ we can have best of > both worlds. > > We need user-space threads because we need to have our Modula-3 process > spread it's threads over whatever we run it on. And we will be very > happy to have synchronizing efficency back. > > Few details to decide how to implement would be preempting/wakeup cycle, > and waiting loop on our inCritical flag. Both can be solved by POSIX > primitives. > > What do you think about this? > > dd > > -- > Dragi?a Duri? From dragisha at m3w.org Tue Apr 6 01:57:07 2010 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Tue, 06 Apr 2010 01:57:07 +0200 Subject: [M3devel] lock performance, random thoughts In-Reply-To: <1F5A794A-40AB-4F94-B11A-9218DAA30ED4@cs.purdue.edu> References: <1270510533.10280.32.camel@faramir.m3w.org> <1F5A794A-40AB-4F94-B11A-9218DAA30ED4@cs.purdue.edu> Message-ID: <1270511827.10280.37.camel@faramir.m3w.org> I've used Java for one project, "GUI" app frontend for mobile phones... What I saw first was their mixup of mutex/condition/cheese in single root object... But, ok... offtopic there :) What I think is important about whole idea is it's simplicity and (almost) obvious efficiency. It also needs nothing fancy (not today, at least) and nothing maybe-it-works to implement. Nothing comparable to early implementations of kernel space threading/thread suspending for gc/... Any takers? :) On Mon, 2010-04-05 at 19:45 -0400, Tony Hosking wrote: > Yes, that's pretty much what modern Java implementations do. > > -- Dragi?a Duri? From jay.krell at cornell.edu Tue Apr 6 02:13:07 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 6 Apr 2010 00:13:07 +0000 Subject: [M3devel] lock performance, random thoughts In-Reply-To: <1270511827.10280.37.camel@faramir.m3w.org> References: <1270510533.10280.32.camel@faramir.m3w.org>, <1F5A794A-40AB-4F94-B11A-9218DAA30ED4@cs.purdue.edu>, <1270511827.10280.37.camel@faramir.m3w.org> Message-ID: pthread_mutex_lock/unlock does not imply a kernel call. ! pthreads can synchronize in usermode just as well (or only almost as well?) as Tony's design. Only upon contention is a kernel call needed, in both. That's not to say that everyone implements this well. Linux does. Win32 does. The others I don't know. Also Tony avoids even atomic operations often. I'm not sure how others compare there. I'm just referring to kernel/syscalls. Are they really so terrible? - Jay > From: dragisha at m3w.org > To: hosking at cs.purdue.edu > Date: Tue, 6 Apr 2010 01:57:07 +0200 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] lock performance, random thoughts > > I've used Java for one project, "GUI" app frontend for mobile phones... > What I saw first was their mixup of mutex/condition/cheese in single > root object... But, ok... offtopic there :) > > What I think is important about whole idea is it's simplicity and > (almost) obvious efficiency. It also needs nothing fancy (not today, at > least) and nothing maybe-it-works to implement. Nothing comparable to > early implementations of kernel space threading/thread suspending for > gc/... > > Any takers? :) > > > On Mon, 2010-04-05 at 19:45 -0400, Tony Hosking wrote: > > Yes, that's pretty much what modern Java implementations do. > > > > > -- > Dragi?a Duri? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Apr 6 02:20:18 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 6 Apr 2010 00:20:18 +0000 Subject: [M3devel] RTMachine.PointerAlignment = 1 on NT? In-Reply-To: References: , , , , , , , , <76C0DE79-7904-49B4-AE3F-83632B48CFDD@cs.purdue.edu>, , , , , , Message-ID: Isn't this kind of "architectural"? Like, assumed in a bunch of code, too hard to change, better to adhere to than change? Can continue to write code assuming it. Consider AMD64_NT. I assume INTEGER there should be 64bits, even though int and long are both 32. Corralary: long shouldn't be used for anything, ever. int is 32 bits, always; ignoring old systems INTEGER is pointer size, always (the question here) long is sometimes 32 bits, sometimes pointer size, but neither is always true, on modern systems If you consider Win64. If you ignore Win64, then, yes, I realize, long is always a pointer. The types to use in C for pointer sized integers are size_t and ptrdiff_t. For that matter..BYTESIZE and ADRSIZE, they are always the same and will always be, right? "All machines are byte-addressable", these days and forever more? - Jay From: hosking at cs.purdue.edu Date: Mon, 5 Apr 2010 19:44:02 -0400 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] RTMachine.PointerAlignment = 1 on NT? Same thing only for implementations where BYTESIZE(Word.T) = BYTESIZE(INTEGER) = BYTESIZE(ADDRESS). But that's all of ours. On 5 Apr 2010, at 18:03, Jay K wrote: Yes. Same thing. - Jay From: hosking at cs.purdue.edu Date: Mon, 5 Apr 2010 13:31:45 -0400 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] RTMachine.PointerAlignment = 1 on NT? More accurately, BYTESIZE(ADDRESS)? Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 5 Apr 2010, at 10:40, Jay K wrote: I think we can safely dispense with RTMachine.PointerAlignment and use BYTESIZE(INTEGER). NT386 is the only current exception. Even though it isn't required, of any x86 target, it seems the overwhelming practice. - Jay Subject: Re: [M3devel] RTMachine.PointerAlignment = 1 on NT? From: hosking at cs.purdue.edu Date: Mon, 5 Apr 2010 10:25:20 -0400 CC: m3devel at elegosoft.com To: jay.krell at cornell.edu Yes, correct. Pointers from the stacks may be "derived" from object base references by the compiler or through use of VAR/READONLY parameters. So, the pointer values from the stack themselves need not be aligned. The PointerAlignment tells the collector at what alignment to expect to find pointers stored in the stack. Some compilers/targets may not require that pointer-valued fields in the stack be stored at aligned locations. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 5 Apr 2010, at 08:03, Jay K wrote: hm I guess pointers themselves (not where they are stored) need not have any alignemnt? We might only have a pointer into an array of bytes to keep the array alive, no pointer to the base of the array? PROCEDURE F1() VAR a: ARRAY OF CHAR := NEW(CHAR, 10); i: INTEGER; BEGIN FOR i := FIRST(a) TO LAST(a) DO something with a[i]; END END F1; might only have pointers to elements in a? - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Mon, 5 Apr 2010 11:55:16 +0000 Subject: Re: [M3devel] RTMachine.PointerAlignment = 1 on NT? Interesting: PROCEDURE NoteStackLocations (start, stop: ADDRESS) = VAR fp : UNTRACED REF ADDRESS := start; BEGIN IF NOT (start < stop) THEN RETURN END; stop := stop - ADRSIZE (ADDRESS); (* so we don't overrun the valid addresses *) WHILE fp <= stop DO (* with the memory read on the next line. *) WITH page = AddressToPage(fp^) DO IF page # NIL AND page.desc.space = Space.Previous THEN IF RTMachine.PointerAlignment = 1 THEN IF Word.And(LOOPHOLE(fp, INTEGER), BYTESIZE(INTEGER) - 1) # 0 THEN RTIO.PutText("pointer found on unaligned stack stack="); RTIO.PutAddr(fp); RTIO.PutText(" addr="); RTIO.PutAddr(fp^); RTIO.PutText("\n"); RTIO.Flush(); END; END; IF page.desc.pure THEN PromotePage(page, PromoteReason.AmbiguousPure); ELSE PromotePage(page, PromoteReason.AmbiguousImpure); END; END; END; INC(fp, RTMachine.PointerAlignment); END; END NoteStackLocations; generates a fair amount of output: C:\dev2\cm3.2\m3-sys\mklib>cm3 --- building in NT386 --- ignoring ..\src\m3overrides pointer found on unaligned stack stack=0x12f3d2 addr=0x1400000 pointer found on unaligned stack stack=0x12f11e addr=0x1400000 pointer found on unaligned stack stack=0x12f186 addr=0x1400000 pointer found on unaligned stack stack=0x12f12e addr=0x1780000 pointer found on unaligned stack stack=0x12f1ba addr=0x1400000 pointer found on unaligned stack stack=0x12f442 addr=0x1460147 new source -> compiling Main.m3 pointer found on unaligned stack stack=0x12f3d2 addr=0x1400000 -> linking mklib.exe I need to look a bit more, see what these values are. We are probably being way over conservative, on NT. Such unaligned values as 0x1460147 surely shouldn't count as traced pointers. This example only has one but usually I see many more. C:\dev2\cm3.2\m3-sys\cm3>cm3 --- building in NT386 --- ignoring ..\src\m3overrides pointer found on unaligned stack stack=0x12f3d2 addr=0x1400000 pointer found on unaligned stack stack=0x12f642 addr=0x1400000 pointer found on unaligned stack stack=0x12f176 addr=0x1400000 pointer found on unaligned stack stack=0x12f11e addr=0x1400000 pointer found on unaligned stack stack=0x12f12a addr=0x1780000 pointer found on unaligned stack stack=0x12f1b6 addr=0x1400000 pointer found on unaligned stack stack=0x12f61e addr=0x1400000 pointer found on unaligned stack stack=0x12f6de addr=0x1900069 pointer found on unaligned stack stack=0x12f43e addr=0x1400000 pointer found on unaligned stack stack=0x12f156 addr=0x1400000 pointer found on unaligned stack stack=0x12f66e addr=0x1400000 pointer found on unaligned stack stack=0x12f72e addr=0x1900069 pointer found on unaligned stack stack=0x12f792 addr=0x1cc0000 pointer found on unaligned stack stack=0x12fb26 addr=0x1d7015c pointer found on unaligned stack stack=0x12fb52 addr=0x1d90142 All this scanning around in memory the garbage collector has to do, doesn't that kill working set? It makes all heap and stack part of the working set? Even if I'm not going to access it for long periods? - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Mon, 5 Apr 2010 11:41:10 +0000 Subject: [M3devel] RTMachine.PointerAlignment = 1 on NT? For the vast majority of platforms: RTMachine.PointerAlignment = BYTESIZE(INTEGER). except 1 for NT386, 2 for M68K (dead). PointerAlignment = BYTESIZE(INTEGER); (* The C compiler allocates all pointers on 'PointerAlignment'-byte boundaries. The garbage collector scans thread stacks, but only looks at these possible pointer locations. Setting this value smaller than is needed will only make your system run slower. Setting it too large will cause the collector to collect storage that is not free. *) I suggest this is not exactly true. 1) Of what relevance is the C compiler? vs. the Modula-3 compiler. 2) We really think the number is 1 for NT386? I understand I could say: void F(void* traced) { #pragma pack(1) struct { char a; void* p} = {0, traced}; } but 1) That seems highly unlikely. 2) Do we really anticipate the case where C code is the *only* holder of a traced reference? And more so, it wasn't a parameter to the C code -- the location of parameters is controlled by Modula-3, assuming a pointer-aligned stack. 3) Can't we know/assume/verify that Modula-3 code only stores pointers at more aligned location? My real goal is to make there only be one RTMachine for systems that don't have stack walkers. Leave SOLgnu/SOLsun alone. (Later on implement stack walking for many platforms via libunwind.) There are I believe only two differences to iron out. Allocation size (8K vs. 64K) and PointerAlignment (1 vs. BYTESIZE(INTEGER)). There is a reason for NT to be 64K allocation size -- that is what VirtualAlloc uses. I can test 64K on others. Historically smaller is probably more efficient. These days larger but not *too* large is probably more efficient. 64K should work fine on all platforms. Heck, even something larger like 1MB is probably good. I'll test out 64K. Can/should we have "paranoidgc" imply PointerAlignment = 1, and report whenever a pointer is found at a location with alignment less than BYTESIZE(pointer)? A form of this is reasonable today, right? If PointerAligment = 1, I can have it report any found at less than BYTESIZE(pointer), test it a while, if none found, elevate NT386 to that value? If any found, that'll help educate me/us on why it is 1, and maybe how to change it, or why leave it alone. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Apr 6 02:38:19 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 6 Apr 2010 00:38:19 +0000 Subject: [M3devel] lock performance, random thoughts In-Reply-To: References: <1270510533.10280.32.camel@faramir.m3w.org>, , <1F5A794A-40AB-4F94-B11A-9218DAA30ED4@cs.purdue.edu>, , <1270511827.10280.37.camel@faramir.m3w.org>, Message-ID: > pthread_mutex_lock/unlock does not imply a kernel call. ! > pthreads can synchronize in usermode just as well (or only almost as well?) as Tony's design. > Only upon contention is a kernel call needed, in both. Without the extra biasing and avoiding atomic ops, I believe it goes something like: typedef struct recursive_exclusive_lock_t { long owner; long count = -1; /* -1 for 386 compat, else 0 is ok and adjust below */ void* kernel object; /* may or may not initialize this up front or on demand, if on demand, beware low resources in the middle of locking */ } recursive_exclusive_lock_t; recursive_exclusive_lock: while (1) new_count = InterlockedIncrement(count); if new_count == 0 /* 1 for 486+, allows for zero initialization */ owner = current thread return if new_count > 0 /* 1 for 486+, allows for zero initialization */ if owner == current thread id return InterlockedDecrement(count); maybe an extra brief spin here on MP systems, in case contention is very short wait on kernel object recursive_exclusive_unlock: assert(owner == current thread id) InterlockedDecrement(count); typedef struct exclusive_lock_t { long owner; void* kernel object; } exclusive_lock_t; exclusive_lock: while (1) if interlocked compare exchange(owner, 0, current thread id) == 0 return maybe an extra brief spin here on MP systems, in case contention is very short wait on kernel object exclusive_unlock: assert(owner == current thread id) owner = 0 The first resembles Win32 critical sections. The second is what the Sun Java VM does on Win32. kernel_lock is a Win32 event. I had that in Modula-3 but only briefly. No kernel call in uncontended cases. But still atomics. - Jay From: jay.krell at cornell.edu To: dragisha at m3w.org; hosking at cs.purdue.edu Date: Tue, 6 Apr 2010 00:13:07 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] lock performance, random thoughts pthread_mutex_lock/unlock does not imply a kernel call. ! pthreads can synchronize in usermode just as well (or only almost as well?) as Tony's design. Only upon contention is a kernel call needed, in both. That's not to say that everyone implements this well. Linux does. Win32 does. The others I don't know. Also Tony avoids even atomic operations often. I'm not sure how others compare there. I'm just referring to kernel/syscalls. Are they really so terrible? - Jay > From: dragisha at m3w.org > To: hosking at cs.purdue.edu > Date: Tue, 6 Apr 2010 01:57:07 +0200 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] lock performance, random thoughts > > I've used Java for one project, "GUI" app frontend for mobile phones... > What I saw first was their mixup of mutex/condition/cheese in single > root object... But, ok... offtopic there :) > > What I think is important about whole idea is it's simplicity and > (almost) obvious efficiency. It also needs nothing fancy (not today, at > least) and nothing maybe-it-works to implement. Nothing comparable to > early implementations of kernel space threading/thread suspending for > gc/... > > Any takers? :) > > > On Mon, 2010-04-05 at 19:45 -0400, Tony Hosking wrote: > > Yes, that's pretty much what modern Java implementations do. > > > > > -- > Dragi?a Duri? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Apr 6 03:21:03 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 5 Apr 2010 21:21:03 -0400 Subject: [M3devel] RTMachine.PointerAlignment = 1 on NT? In-Reply-To: References: , , , , , , , , <76C0DE79-7904-49B4-AE3F-83632B48CFDD@cs.purdue.edu>, , , , , , Message-ID: <141A7DFE-839D-4DD6-B8B4-934476DAE9A6@cs.purdue.edu> Fair enough. That says it should be ADRSIZE(ADDRESS). ;-) On 5 Apr 2010, at 20:20, Jay K wrote: > Isn't this kind of "architectural"? > Like, assumed in a bunch of code, too hard to change, better to adhere to than change? > Can continue to write code assuming it. > > > Consider AMD64_NT. > I assume INTEGER there should be 64bits, even though int and long are both 32. > Corralary: long shouldn't be used for anything, ever. > int is 32 bits, always; ignoring old systems > INTEGER is pointer size, always (the question here) > long is sometimes 32 bits, sometimes pointer size, but neither is always true, on modern systems > If you consider Win64. If you ignore Win64, then, yes, I realize, long is always a pointer. > The types to use in C for pointer sized integers are size_t and ptrdiff_t. > > > For that matter..BYTESIZE and ADRSIZE, they are always the same and will always be, right? > "All machines are byte-addressable", these days and forever more? > > > - Jay > > > From: hosking at cs.purdue.edu > Date: Mon, 5 Apr 2010 19:44:02 -0400 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] RTMachine.PointerAlignment = 1 on NT? > > Same thing only for implementations where BYTESIZE(Word.T) = BYTESIZE(INTEGER) = BYTESIZE(ADDRESS). But that's all of ours. > > On 5 Apr 2010, at 18:03, Jay K wrote: > > Yes. Same thing. > > - Jay > > From: hosking at cs.purdue.edu > Date: Mon, 5 Apr 2010 13:31:45 -0400 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] RTMachine.PointerAlignment = 1 on NT? > > More accurately, BYTESIZE(ADDRESS)? > > Antony Hosking | Associate Professor | Computer Science | Purdue University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > On 5 Apr 2010, at 10:40, Jay K wrote: > > I think we can safely dispense with RTMachine.PointerAlignment and use BYTESIZE(INTEGER). > NT386 is the only current exception. > Even though it isn't required, of any x86 target, it seems the overwhelming practice. > > - Jay > > Subject: Re: [M3devel] RTMachine.PointerAlignment = 1 on NT? > From: hosking at cs.purdue.edu > Date: Mon, 5 Apr 2010 10:25:20 -0400 > CC: m3devel at elegosoft.com > To: jay.krell at cornell.edu > > Yes, correct. Pointers from the stacks may be "derived" from object base references by the compiler or through use of VAR/READONLY parameters. So, the pointer values from the stack themselves need not be aligned. The PointerAlignment tells the collector at what alignment to expect to find pointers stored in the stack. Some compilers/targets may not require that pointer-valued fields in the stack be stored at aligned locations. > > > > Antony Hosking | Associate Professor | Computer Science | Purdue University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > On 5 Apr 2010, at 08:03, Jay K wrote: > > hm I guess pointers themselves (not where they are stored) need not have any alignemnt? > We might only have a pointer into an array of bytes to keep the array alive, > no pointer to the base of the array? > > PROCEDURE F1() > VAR a: ARRAY OF CHAR := NEW(CHAR, 10); > i: INTEGER; > BEGIN > FOR i := FIRST(a) TO LAST(a) DO > something with a[i]; > END > END F1; > > might only have pointers to elements in a? > > - Jay > > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Mon, 5 Apr 2010 11:55:16 +0000 > Subject: Re: [M3devel] RTMachine.PointerAlignment = 1 on NT? > > Interesting: > > PROCEDURE NoteStackLocations (start, stop: ADDRESS) = > VAR fp : UNTRACED REF ADDRESS := start; > BEGIN > IF NOT (start < stop) THEN RETURN END; > stop := stop - ADRSIZE (ADDRESS); (* so we don't overrun the valid addresses *) > WHILE fp <= stop DO (* with the memory read on the next line. *) > WITH page = AddressToPage(fp^) DO > IF page # NIL AND page.desc.space = Space.Previous THEN > IF RTMachine.PointerAlignment = 1 THEN > IF Word.And(LOOPHOLE(fp, INTEGER), BYTESIZE(INTEGER) - 1) # 0 THEN > RTIO.PutText("pointer found on unaligned stack stack="); > RTIO.PutAddr(fp); > RTIO.PutText(" addr="); > RTIO.PutAddr(fp^); > RTIO.PutText("\n"); > RTIO.Flush(); > END; > END; > IF page.desc.pure > THEN PromotePage(page, PromoteReason.AmbiguousPure); > ELSE PromotePage(page, PromoteReason.AmbiguousImpure); > END; > END; > END; > INC(fp, RTMachine.PointerAlignment); > END; > END NoteStackLocations; > > > generates a fair amount of output: > > > C:\dev2\cm3.2\m3-sys\mklib>cm3 > --- building in NT386 --- > ignoring ..\src\m3overrides > pointer found on unaligned stack stack=0x12f3d2 addr=0x1400000 > pointer found on unaligned stack stack=0x12f11e addr=0x1400000 > pointer found on unaligned stack stack=0x12f186 addr=0x1400000 > pointer found on unaligned stack stack=0x12f12e addr=0x1780000 > pointer found on unaligned stack stack=0x12f1ba addr=0x1400000 > pointer found on unaligned stack stack=0x12f442 addr=0x1460147 > new source -> compiling Main.m3 > pointer found on unaligned stack stack=0x12f3d2 addr=0x1400000 > -> linking mklib.exe > > > I need to look a bit more, see what these values are. > We are probably being way over conservative, on NT. > Such unaligned values as 0x1460147 surely shouldn't count as traced pointers. > This example only has one but usually I see many more. > > > C:\dev2\cm3.2\m3-sys\cm3>cm3 > --- building in NT386 --- > ignoring ..\src\m3overrides > pointer found on unaligned stack stack=0x12f3d2 addr=0x1400000 > pointer found on unaligned stack stack=0x12f642 addr=0x1400000 > pointer found on unaligned stack stack=0x12f176 addr=0x1400000 > pointer found on unaligned stack stack=0x12f11e addr=0x1400000 > pointer found on unaligned stack stack=0x12f12a addr=0x1780000 > pointer found on unaligned stack stack=0x12f1b6 addr=0x1400000 > pointer found on unaligned stack stack=0x12f61e addr=0x1400000 > pointer found on unaligned stack stack=0x12f6de addr=0x1900069 > pointer found on unaligned stack stack=0x12f43e addr=0x1400000 > pointer found on unaligned stack stack=0x12f156 addr=0x1400000 > pointer found on unaligned stack stack=0x12f66e addr=0x1400000 > pointer found on unaligned stack stack=0x12f72e addr=0x1900069 > pointer found on unaligned stack stack=0x12f792 addr=0x1cc0000 > pointer found on unaligned stack stack=0x12fb26 addr=0x1d7015c > pointer found on unaligned stack stack=0x12fb52 addr=0x1d90142 > > > All this scanning around in memory the garbage collector has to do, doesn't that kill working set? > It makes all heap and stack part of the working set? Even if I'm not going to access it for long periods? > > > - Jay > > > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Mon, 5 Apr 2010 11:41:10 +0000 > Subject: [M3devel] RTMachine.PointerAlignment = 1 on NT? > > For the vast majority of platforms: > > > RTMachine.PointerAlignment = BYTESIZE(INTEGER). > > > except 1 for NT386, 2 for M68K (dead). > > > PointerAlignment = BYTESIZE(INTEGER); > (* The C compiler allocates all pointers on 'PointerAlignment'-byte > boundaries. The garbage collector scans thread stacks, but only > looks at these possible pointer locations. Setting this value > smaller than is needed will only make your system run slower. > Setting it too large will cause the collector to collect storage > that is not free. *) > > > I suggest this is not exactly true. > 1) Of what relevance is the C compiler? vs. the Modula-3 compiler. > 2) We really think the number is 1 for NT386? > > I understand I could say: > void F(void* traced) > { > #pragma pack(1) > struct { char a; void* p} = {0, traced}; > } > > but > 1) That seems highly unlikely. > 2) Do we really anticipate the case where C code is the *only* holder of a traced reference? > And more so, it wasn't a parameter to the C code -- the location of parameters is controlled by Modula-3, assuming a pointer-aligned stack. > 3) Can't we know/assume/verify that Modula-3 code only stores pointers at more aligned location? > > > My real goal is to make there only be one RTMachine for systems that don't have stack walkers. > Leave SOLgnu/SOLsun alone. > (Later on implement stack walking for many platforms via libunwind.) > > > There are I believe only two differences to iron out. Allocation size (8K vs. 64K) and PointerAlignment (1 vs. BYTESIZE(INTEGER)). > There is a reason for NT to be 64K allocation size -- that is what VirtualAlloc uses. > I can test 64K on others. > Historically smaller is probably more efficient. > These days larger but not *too* large is probably more efficient. > 64K should work fine on all platforms. Heck, even something larger like 1MB is probably good. > I'll test out 64K. > > > Can/should we have "paranoidgc" imply PointerAlignment = 1, and report whenever a pointer is found at a location with alignment less than BYTESIZE(pointer)? > > > A form of this is reasonable today, right? If PointerAligment = 1, I can have it report any found at less than BYTESIZE(pointer), test it a while, if none found, elevate NT386 to that value? > If any found, that'll help educate me/us on why it is 1, and maybe how to change it, or why leave it alone. > > > - Jay > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Wed Apr 7 20:56:54 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Wed, 7 Apr 2010 14:56:54 -0400 Subject: [M3devel] RTMachine.PointerAlignment = 1 on NT? In-Reply-To: References: Message-ID: <20100407185654.GA29570@topoi.pooq.com> On Mon, Apr 05, 2010 at 11:41:10AM +0000, Jay K wrote: > > For the vast majority of platforms: > > > > > > RTMachine.PointerAlignment = BYTESIZE(INTEGER). > > > > > > except 1 for NT386, 2 for M68K (dead). > > > > > > PointerAlignment = BYTESIZE(INTEGER); > (* The C compiler allocates all pointers on 'PointerAlignment'-byte > boundaries. The garbage collector scans thread stacks, but only > looks at these possible pointer locations. Setting this value > smaller than is needed will only make your system run slower. > Setting it too large will cause the collector to collect storage > that is not free. *) > > > > > I suggest this is not exactly true. > > 1) Of what relevance is the C compiler? vs. the Modula-3 compiler. The C compiler is not that relevant. What is relevant is possible other languages that might want to share a garbage collector. I dream of the day when multilanguage programming can be done cleanly for other than the malloc/free kinds of languages. The one big problem with garbage-collected languages at the moment is that they interwork very poorly because they have incompatible storage layouts. Let's not make it harder than necessary. As far as I know, most allocate pointers on pointer-sized boundaries. But pointers may point into objects as well as to them, not necessarily at nice boundaries. -- hendrik From jay.krell at cornell.edu Tue Apr 6 07:31:39 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 6 Apr 2010 05:31:39 +0000 Subject: [M3devel] RTMachine.PointerAlignment = 1 on NT? In-Reply-To: <20100407185654.GA29570@topoi.pooq.com> References: , <20100407185654.GA29570@topoi.pooq.com> Message-ID: > I dream of the day when multilanguage programming can be done cleanly > for other than the malloc/free kinds of languages. The point of .NET, eh? > The one big problem with garbage-collected languages at the moment is > that they interwork very poorly because they have incompatible storage > layouts. "storage layout"? Isn't that kind of underselling it? Seems to me these things encompass like the whole system. You either play into it or you don't. There is a bit of a pick and chose option as I understand, like with "managed C++" you can have native code instead of IL+JIT. Seems to me, syntax isn't all that interesting, but libraries and runtimes are. Syntax matters to the extent that editor supports it. While .NET may support various syntaxes, the point is really to use the one and only runtime and library. You might as well just use C#. Mono works fairly well. Imho. ..Jay > Date: Wed, 7 Apr 2010 14:56:54 -0400 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] RTMachine.PointerAlignment = 1 on NT? > > On Mon, Apr 05, 2010 at 11:41:10AM +0000, Jay K wrote: > > > > For the vast majority of platforms: > > > > RTMachine.PointerAlignment = BYTESIZE(INTEGER). > > > > except 1 for NT386, 2 for M68K (dead). > > > > PointerAlignment = BYTESIZE(INTEGER); > > (* The C compiler allocates all pointers on 'PointerAlignment'-byte > > boundaries. The garbage collector scans thread stacks, but only > > looks at these possible pointer locations. Setting this value > > smaller than is needed will only make your system run slower. > > Setting it too large will cause the collector to collect storage > > that is not free. *) > > > > I suggest this is not exactly true. > > > > 1) Of what relevance is the C compiler? vs. the Modula-3 compiler. > > The C compiler is not that relevant. What is relevant is possible other > languages that might want to share a garbage collector. > > I dream of the day when multilanguage programming can be done cleanly > for other than the malloc/free kinds of languages. > > The one big problem with garbage-collected languages at the moment is > that they interwork very poorly because they have incompatible storage > layouts. > > Let's not make it harder than necessary. > > As far as I know, most allocate pointers on pointer-sized boundaries. > But pointers may point into objects as well as to them, not necessarily > at nice boundaries. > > -- hendrik -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Tue Apr 6 08:14:40 2010 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Tue, 06 Apr 2010 08:14:40 +0200 Subject: [M3devel] lock performance, random thoughts (also current cvsup situation) In-Reply-To: <1F5A794A-40AB-4F94-B11A-9218DAA30ED4@cs.purdue.edu> References: <1270510533.10280.32.camel@faramir.m3w.org> <1F5A794A-40AB-4F94-B11A-9218DAA30ED4@cs.purdue.edu> Message-ID: <1270534480.10280.43.camel@faramir.m3w.org> It's good to read more about subject, which is what I usually do after some tabula rasa thinking on it :). It looks like Linux has optimized this for some time now. Bias by way of very fast operation in uncontended cases. What is current m3devel decision on this? And how I (with Linux and only Linux) can feel this slowdown in cvsup at all? Is it because Elego rebuild cvsupd and is not using Linux server-side?? On Mon, 2010-04-05 at 19:45 -0400, Tony Hosking wrote: > Yes, that's pretty much what modern Java implementations do. -- Dragi?a Duri? From jay.krell at cornell.edu Tue Apr 6 08:41:39 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 6 Apr 2010 06:41:39 +0000 Subject: [M3devel] lock performance, random thoughts (also current cvsup situation) In-Reply-To: <1270534480.10280.43.camel@faramir.m3w.org> References: <1270510533.10280.32.camel@faramir.m3w.org>, <1F5A794A-40AB-4F94-B11A-9218DAA30ED4@cs.purdue.edu>, <1270534480.10280.43.camel@faramir.m3w.org> Message-ID: I don't quite understand your question. I'll answer related things. Do you know notice the slow down in cvsup/cvsupd? I do. But I'm curious if it is just me. Everything except OpenBSD uses pthreads in cm3. Which I believe are always kernel threads though don't know 100%. (FreeBSD? NetBSD?) OpenBSD always uses user threads. Its pthreads are user threads and don't work well enough for us. Always pthreads: Unless you do something "special" -- rebuild with cm3 -DUSER_THREADS or such -- I edit m3core/src/thread.quake, since I don't have support for passing extra parameters around from scripts, dumb, I know. The code I showed is not what Modula-3 does. We just call pthread_lock_mutex. It is what pthread_lock_mutex should look like. Or perhaps something even better, but it is a simple efficient start. We don't inline the locking, which Tony is keen on doing. I don't think we inline for user threads locking either though. Inline is often very good, but I don't know if it would be significant here. Some profiling is probably in order. You? had said that pthread_self or pthread_getspecific/set were showing in profiling? Some kernel calls where? I don't believe any of those three are kernel calls, nor as well that pthread_lock_mutex is without contention. We call self/getspecific/setspecific too often. But they should be fairly fast. There is an approximate plan to improve this post-release -- use libunwind. Again, maybe some profiling is in order. Maybe just of hello world? I'd have to test hello world user threads and kernel threads. See if it is noticably different. Again, cvsup/cvsupd it is very noticable the speed of userthreads vs. kernelthreads. Heck, it maybe isn't even threads. Maybe it is just startup/shutdown. - Jay > From: dragisha at m3w.org > To: hosking at cs.purdue.edu > Date: Tue, 6 Apr 2010 08:14:40 +0200 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] lock performance, random thoughts (also current cvsup situation) > > It's good to read more about subject, which is what I usually do after > some tabula rasa thinking on it :). > > It looks like Linux has optimized this for some time now. Bias by way of > very fast operation in uncontended cases. > > What is current m3devel decision on this? And how I (with Linux and only > Linux) can feel this slowdown in cvsup at all? Is it because Elego > rebuild cvsupd and is not using Linux server-side?? > > On Mon, 2010-04-05 at 19:45 -0400, Tony Hosking wrote: > > Yes, that's pretty much what modern Java implementations do. > > -- > Dragi?a Duri? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Wed Apr 7 05:30:38 2010 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Wed, 7 Apr 2010 03:30:38 +0000 (GMT) Subject: [M3devel] lock performance, random thoughts In-Reply-To: Message-ID: <694635.45812.qm@web23602.mail.ird.yahoo.com> Hi all: I remember that someone inside Acorn reported their use was overwhelming if running in user mode and gave an interesting idea about that in terms of operating system development. They wrote a huge amount of Modula-2+ code even with GUI in Acorn (Olivetti) for the Acorn Archimedes workstation in middle end eighties for its development As the language primitives were the same in use at DEC SRC I guess they didn't consider the language as the problem, but a machine architecture lack of performance factor and in turn affect programs performance by itself. However this got into the development of the ARM architecture introduced since then for the Archimedes ARM and the OS itself. http://lists.cloud9.co.uk/pipermail/bbc-micro/2010-January/007795.html http://www.chiark.greenend.org.uk/~theom/riscos/docs/ultimate/a252swp.txt As a new operating system belongs to a new era the SPIN OS was ahead of its time in terms of performance improvements and no been hit by itself (in terms of performance) which was not an issue because of its nature of safety but still they addressed the use of other operating system code at the operating system level which of course gave problems of performance? but didn't? play a important issue by itself as non safe code could be extra checked or run in space of kernel with no user rights to modify heap allocated space or if not needed to be run in kernel space as a client of an extern library OS in user space with no use in kernel space IMO both approaches either hardware level and operating system level have pros and cons as the operating system level threading is a plus nowadays in multi threaded programs running on multi core equipped hardware but in most cases the use of it could be not a winning situation because not all hardware by its own is multi core in new computer Minis (net books) or systems run in hardware assisted virtualization and not to forget old machines which in most cases can run many applications no multi threaded of today like we use in normal with no performance improvement in new ones on tasks which may no benefit of the extra hardware that may still have at hand so there could be a balance that could benefit most of all cases. Therefore not to say that we may suck user level threading but still considering as a important part of it and needing a new development for the cases of lack of performance an improvement over the cases it lacks and better use of the better hardware like in Acorn did use of the new development to aid it. Probably the best solution is a matter of match between the underlying hardware with proper system-level handling of it to best performance and less penalty in favour of the language developer and final user just to get easier of development and performance gain solution. ?? My vote for operating system level threading (i.e of SPIN) if lacks of performance of faster user threading as a solution for the performance hit problems and user level threading for the systems with no gain over it? so we may gain of language and hardware capabilities to extract the best of both. --- El lun, 5/4/10, Jay K escribi?: De: Jay K Asunto: Re: [M3devel] lock performance, random thoughts Para: dragisha at m3w.org, "Tony" CC: "m3devel" Fecha: lunes, 5 de abril, 2010 19:13 pthread_mutex_lock/unlock does not imply a kernel call. ! pthreads can synchronize in usermode just as well (or only almost as well?) as Tony's design. Only upon contention is a kernel call needed, in both. ? ? That's not to say that everyone implements this well. Linux does. Win32 does. The others I don't know. ? ? Also Tony avoids even atomic operations often. I'm not sure how others compare there. I'm just referring to kernel/syscalls. Are they really so terrible? ? ? ?- Jay ? > From: dragisha at m3w.org > To: hosking at cs.purdue.edu > Date: Tue, 6 Apr 2010 01:57:07 +0200 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] lock performance, random thoughts > > I've used Java for one project, "GUI" app frontend for mobile phones... > What I saw first was their mixup of mutex/condition/cheese in single > root object... But, ok... offtopic there :) > > What I think is important about whole idea is it's simplicity and > (almost) obvious efficiency. It also needs nothing fancy (not today, at > least) and nothing maybe-it-works to implement. Nothing comparable to > early implementations of kernel space threading/thread suspending for > gc/... > > Any takers? :) > > > On Mon, 2010-04-05 at 19:45 -0400, Tony Hosking wrote: > > Yes, that's pretty much what modern Java implementations do. > > > > > -- > Dragi?a Duri? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Highjinks at gmx.com Wed Apr 7 22:09:27 2010 From: Highjinks at gmx.com (Chris) Date: Wed, 7 Apr 2010 22:09:27 +0200 (CEST) Subject: [M3devel] lock performance, random thoughts In-Reply-To: <694635.45812.qm@web23602.mail.ird.yahoo.com> References: <694635.45812.qm@web23602.mail.ird.yahoo.com> Message-ID: <20100407161333.014d6539.Highjinks@gmx.com> As I've said before, this really has NOTHING to do with user/kernel level threading. It's all about synchronization. The only thing a user level thread offers is the possibility to completely avoid context switches, such as is common in a State Machine/Automata. You could also approach it as a Direct Threaded environment, as is common in many Forth implementations. Look at pthreads read and write barriers. Look at http://www-sop.inria.fr/meije/rp/LOFT/ This is a tool which comfortably integrates both Kernel Space and User Space threads into a whole. In general the Synchronous Model(typically implemented as user space threads, due to lack of Kernel support) will typically be much faster when doing interactive and multimedia programming. The Asynchronous model(typically done as Kernel Space threads) will usually be faster at Batch processing. You can do both with Posix Threads. No need to limit the environment exclusively to one or the other. A mixed model provides the best flexibility. -- Chris From dragisha at m3w.org Thu Apr 8 00:06:29 2010 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Thu, 08 Apr 2010 00:06:29 +0200 Subject: [M3devel] lock performance, random thoughts In-Reply-To: <20100407161333.014d6539.Highjinks@gmx.com> References: <694635.45812.qm@web23602.mail.ird.yahoo.com> <20100407161333.014d6539.Highjinks@gmx.com> Message-ID: <1270677989.3816.7.camel@faramir.m3w.org> It's all about synchronization in kernel space, ie part of it when it comes to kernel space through syscalls. Context switching is lesser problem as it is what happens a lot less often than synchronization. Synchronization problem is with systems which are, unlike Linux, doing syscalls on every pthread_mutex_lock and friends. Hybridization of thread system (mixing user and kernel threads) is done talk and I hope nobody takes such thing seriously anymore. On Wed, 2010-04-07 at 22:09 +0200, Chris wrote: > As I've said before, this really has NOTHING to do with user/kernel > level threading. It's all about synchronization. -- Dragi?a Duri? From jay.krell at cornell.edu Thu Apr 8 02:39:05 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 8 Apr 2010 00:39:05 +0000 Subject: [M3devel] lock performance, random thoughts In-Reply-To: <1270677989.3816.7.camel@faramir.m3w.org> References: , <694635.45812.qm@web23602.mail.ird.yahoo.com>, <20100407161333.014d6539.Highjinks@gmx.com>, <1270677989.3816.7.camel@faramir.m3w.org> Message-ID: uncontended pthread_mutex_lock/unlock: syscall on FreeBSD? Solaris? NetBSD? Darwin? Not on Linux. I really doubt on Solaris. Ditto pthread_self, pthread_getspecific, pthread_setspecific? (Though I don't believe we call them frequently on Solaris, and I have a very rough plan to reduce them *later* -- libunwind.) - Jay > From: dragisha at m3w.org > To: Highjinks at gmx.com > Date: Thu, 8 Apr 2010 00:06:29 +0200 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] lock performance, random thoughts > > It's all about synchronization in kernel space, ie part of it when it > comes to kernel space through syscalls. > > Context switching is lesser problem as it is what happens a lot less > often than synchronization. > > Synchronization problem is with systems which are, unlike Linux, doing > syscalls on every pthread_mutex_lock and friends. > > Hybridization of thread system (mixing user and kernel threads) is done > talk and I hope nobody takes such thing seriously anymore. > > On Wed, 2010-04-07 at 22:09 +0200, Chris wrote: > > As I've said before, this really has NOTHING to do with user/kernel > > level threading. It's all about synchronization. > -- > Dragi?a Duri? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Apr 9 12:04:16 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 9 Apr 2010 10:04:16 +0000 Subject: [M3devel] gcc atomics supported ordering? Message-ID: Tony I thought you recently said all memory orderings are supported by the gcc backend with atomics. But there is still: jbook2:m3cg jay$ grep Relaxed * parse.c:typedef enum { Relaxed, Release, Acquire, AcquireRelease, Sequential } O rder; parse.c: if (order != Relaxed) parse.c: warning (0, "only Relaxed memory order for stores is supported"); parse.c: if (order != Relaxed) parse.c: warning (0, "only Relaxed memory order for loads is supported"); - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Apr 9 12:52:09 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 9 Apr 2010 10:52:09 +0000 Subject: [M3devel] ROUND vs. FLOOR in ThreadPThread.m3 nano vs. micro time conversions? Message-ID: Why does UTimeFromTime use FLOOR but ToNTime uses ROUND? PROCEDURE ToNTime (n: LONGREAL; VAR ts: Utime.struct_timespec) = BEGIN ts.tv_sec := TRUNC(n); ts.tv_nsec := ROUND((n - FLOAT(ts.tv_sec, LONGREAL)) * 1.0D9); END ToNTime; TYPE UTime = Utime.struct_timeval; PROCEDURE UTimeFromTime (time: Time.T): UTime = VAR floor := FLOOR(time); BEGIN RETURN UTime{floor, FLOOR(1.0D6 * (time - FLOAT(floor, LONGREAL)))}; END UTimeFromTime; I've changed this code to pass doubles to C and do the conversion there. To reduce/eliminate use of cloned headers. For ROUND I'm using C99: /* C99, very portable */ long lround(double); long long llround(double); #ifdef __CYGWIN__ #define ROUND lround #else #define ROUND llround #endif typedef double FloatSeconds, LONGREAL; typedef struct timeval MicrosecondsStruct_t; #define FLOAT(value, type) ((type)value) #define FLOOR floor static MicrosecondsStruct_t* FloatSecondsToNanosecondsStruct(LONGREAL n, MicrosecondsStruct_t* ts) { ts->tv_sec = (time_t)n; ts->tv_nsec = ROUND((n - FLOAT(ts->tv_sec, LONGREAL)) * 1.0E9); return ts; } static MicrosecondsStruct_t* FloatSecondsToMicrosecondsStruct(FloatSeconds timeout, MicrosecondsStruct_t* utime) { LONGINT sec = FLOOR(timeout); utime->tv_sec = (time_t)sec; utime->tv_usec = (suseconds_t)FLOOR(1.0E6 * (timeout - FLOAT(sec, LONGREAL))); return utime; } Just arbitrarily a little more correct in the nano case vs. the micro case? Matters little? Would matter more for micro due to lower resolution? Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Apr 9 19:01:19 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 9 Apr 2010 13:01:19 -0400 Subject: [M3devel] gcc atomics supported ordering? In-Reply-To: References: Message-ID: Never said any such thing. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 9 Apr 2010, at 06:04, Jay K wrote: > Tony I thought you recently said all memory orderings are supported by the gcc backend with atomics. > But there is still: > > jbook2:m3cg jay$ grep Relaxed * > parse.c:typedef enum { Relaxed, Release, Acquire, AcquireRelease, Sequential } O > rder; > parse.c: if (order != Relaxed) > parse.c: warning (0, "only Relaxed memory order for stores is supported"); > parse.c: if (order != Relaxed) > parse.c: warning (0, "only Relaxed memory order for loads is supported"); > > - Jay > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Apr 11 07:08:07 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 11 Apr 2010 05:08:07 +0000 Subject: [M3devel] m3core/unix directions Message-ID: m3core/unix directions My intent here is to further reduce platform dependencies and header cloning. I know there isn't much left, but there is some. In particular: eliminate struct_timespec (done) eliminate struct_timeval (partly done, more to do) implies eliminating select wrapper implies eliminating gettimeofday wrapper eliminate MAX_FDSET Though there is a possible bug workaround in m3core, that Interix's header is wrong. eliminate time_t (I'd also like to find some way to get 64bit time_t everywhere, though my research so far says it isn't available) eliminate struct_tm Mainly used by m3core/src/time. As well as fix m3-mail/webcard, m3-mail/postcard which have crashing bugs due to declaring their own form. eliminate struct_sockaddr_in maybe eliminate struct_sockaddr_un (I know it was requested) eliminate all of the Usysdep.i3 files (MAX_FDSET, struct_tm) maybe eliminate ioctl/fcntl; there are precious few uses; is the Solaris bug workaround for them needed? That bug workaround is a good reason to keep the wrappers. maybe eliminate stat; there there again there are interesting bug workarounds in the wrappers, the incorrect headers I had for Darwin/arm maybe reduce what all m3core/src/unix provides/wraps, leave it to the clients; however to the extent that they are just const char* and int, probably ok to just leave asis (e.g. open/read/write/close) I'm not sure I'll succeed at all of this, but each step I believe has value. General strategy is to push C up one level. Pass around types that we have complete control of. There is always C below the Posix ports of Modula-3, as well as the Win32/NT port. It is "just" a matter at where the line is. A hypothetical Modula-3 "OS" wouldn't necessarily use any of this C, if it provided m3core/libm3/tcp directly. btw, here's a likely example of the bugs these patterns have caused: C:\dev2\cm3.2\m3-www\http\src\AppBackup.m3(77):(* Nov 16: file.lock broken in call to fcntl - int vs. long confusion C:\dev2\cm3.2\m3-www\http\src\AppBackup.m3(103):(* Nov 16: file.lock broken in call to fcntl - int vs. long confusion To mitigate appearance of hypocrisy, I'm willing to do this work on the Win32 header clones also. Though I think they are a smaller and bigger problem. Bigger because we have cloned *a lot*. Smaller because they vary less across the various Win32 architectures. Similar in size because we use only a small part of them, analogous to what we use for Unix. I speculate that stuff like OpenGL and X Windows aren't as problematic because they are fairly independent of OS/kernel. It is the "libc as kernel wrapper" where the problems are worse, given the relatively large number of varieties (Linux, *BSD, NT, Solaris, Darwin). Though they could still embed e.g. time_t, struct timeval, etc. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Apr 11 07:15:44 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 11 Apr 2010 05:15:44 +0000 Subject: [M3devel] UtimeExtra.i3 Message-ID: Just a note that the following are both duplicated and slightly buggy: C:\dev2\cm3.2\m3-mail\postcard\src\UtimeExtra.i3 C:\dev2\cm3.2\m3-mail\postcard\src\OSUtils.m3 C:\dev2\cm3.2\m3-mail\postcard\src\OSUtils.i3 C:\dev2\cm3.2\m3-mail\webcard\src\UtimeExtra.i3 C:\dev2\cm3.2\m3-mail\webcard\src\OSUtils.m3 C:\dev2\cm3.2\m3-mail\webcard\src\OSUtils.i3 The copies are identical. UtimeExtra.i3: (* The declaration of struct_tm in Utime omits "gmtoff"; mktime isn there at all. *) TYPE struct_tm = RECORD tm_sec: int; (* seconds (0 - 59) *) tm_min: int; (* minutes (0 - 59) *) tm_hour: int; (* hours (0 - 23) *) tm_mday: int; (* day of month (1 - 31) *) tm_mon: int; (* month of year (0 - 11) *) tm_year: int; (* year - 1900 *) tm_wday: int; (* day of week (Sunday = 0) *) tm_yday: int; (* day of year (0 - 365) *) tm_isdst: int; (* flag: daylight savings time in effect *) tm_gmtoff: long; (* offset from GMT in seconds *) tm_zone: char_star;(* abbreviation of timezone name *) END; struct_tm_star = UNTRACED REF struct_tm; <*EXTERNAL*> PROCEDURE localtime (clock: long_star): struct_tm_star; <*EXTERNAL*> PROCEDURE gmtime (clock: long_star): struct_tm_star; <*EXTERNAL*> PROCEDURE mktime (VAR tm: struct_tm): long; gmtoff is omitted deliberately, because it isn't always there. e.g. on Cygwin, Solaris, Interix, Posix. They are #ifed on Linux -- they are there. I don't believe the order of the fields is guaranteed either, but everything I looked at has them the same. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Apr 11 07:43:35 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 11 Apr 2010 05:43:35 +0000 Subject: [M3devel] unused/little used stuff in m3core/unix? Message-ID: Following are not used: fchmod fchown getpagesize sbrk creat isatty That isn't necessarily all. Some are used only in: C:\dev2\cm3.2\m3-libs\libm3\src\os\POSIX e.g. chdir getdtablesize execve Some are used only in the unused m3-pkgtools directory or by cvsup. e.g. umask These all traffic in pretty "plain" types (e.g. no structs, no time_t). So just keep them all? Note of course, uses of these somewhat or significantly inhibit porting to native Win32. Account for somewhat arbirary Posix-specific code outside the cm3 tree and err toward wrapping stuff that is easy? Or push the idea that m3core/libm3 are a good (and safe) portability layer and only provide what they need, and gradually move them towards C to reduce their needs? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Apr 11 16:30:44 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 11 Apr 2010 14:30:44 +0000 Subject: [M3devel] Control-c tends to hang? Message-ID: I'm seeing that pressing control-C has a very high propensity to hang. e.g. release branch, LINUXLIBC6, pthreads cd m3-libs/m3core rm -rf LINUXLIBC6 /cm3/bin/cm3 wait for it to print a file or two control-C if it doesn't hang, again: /cm3/bin/cm3 wait a second control-c It hangs about 25% of the time. gdb is generally useless..I find that true generally lately: Failed to read a valid object file image from memory. (gdb) thread apply all bt Thread 1 (Thread -1210542400 (LWP 4640)): #0 0xb7eff410 in ?? () #1 0xbfd35868 in ?? () #2 0x00000002 in ?? () #3 0x00000000 in ?? () #0 0xb7eff410 in ?? () maybe to do with.. strace gdb: open("/proc/5688/mem", O_RDONLY|O_LARGEFILE) = 6 pread64(6, 0xbfcd1d78, 52, 4294959104) = -1 EIO (Input/output error) close(6) = 0 ptrace(PTRACE_PEEKTEXT, 5688, 0xffffe000, [0]) = -1 EIO (Input/output error) rt_sigprocmask(SIG_SETMASK, [CHLD], NULL, 8) = 0 write(2, "Failed to read a valid object fi"..., 53Failed to read a valid object file image from memory.) = 53 Aha I thought I was running Debian 5.0, but only 4.0..maybe with a newer Debian/gdb. (There was a known problem in older kernels with this signature, I didn't realize I was running old..) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sun Apr 11 17:19:33 2010 From: wagner at elegosoft.com (wagner at elegosoft.com) Date: Sun, 11 Apr 2010 17:19:33 +0200 Subject: [M3devel] release engineering: build release_CM3_5_8_RC5 now? Message-ID: <20100411171933.szof1k9n2ss48sg8@mail.elegosoft.com> I'm currently tagging the release branch with release_CM3_5_8_RC5. Are there still any objections to use the current state of the branch? I'll soon try a sample build on birch. Olaf From jay.krell at cornell.edu Mon Apr 12 01:50:14 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 11 Apr 2010 23:50:14 +0000 Subject: [M3devel] Control-c tends to hang? Message-ID: I upgraded to Debian 5.0 to fix the debugging, and now I haven't been able to get the hang to occur. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Subject: Control-c tends to hang? Date: Sun, 11 Apr 2010 14:30:44 +0000 I'm seeing that pressing control-C has a very high propensity to hang. e.g. release branch, LINUXLIBC6, pthreads cd m3-libs/m3core rm -rf LINUXLIBC6 /cm3/bin/cm3 wait for it to print a file or two control-C if it doesn't hang, again: /cm3/bin/cm3 wait a second control-c It hangs about 25% of the time. gdb is generally useless..I find that true generally lately: Failed to read a valid object file image from memory. (gdb) thread apply all bt Thread 1 (Thread -1210542400 (LWP 4640)): #0 0xb7eff410 in ?? () #1 0xbfd35868 in ?? () #2 0x00000002 in ?? () #3 0x00000000 in ?? () #0 0xb7eff410 in ?? () maybe to do with.. strace gdb: open("/proc/5688/mem", O_RDONLY|O_LARGEFILE) = 6 pread64(6, 0xbfcd1d78, 52, 4294959104) = -1 EIO (Input/output error) close(6) = 0 ptrace(PTRACE_PEEKTEXT, 5688, 0xffffe000, [0]) = -1 EIO (Input/output error) rt_sigprocmask(SIG_SETMASK, [CHLD], NULL, 8) = 0 write(2, "Failed to read a valid object fi"..., 53Failed to read a valid object file image from memory.) = 53 Aha I thought I was running Debian 5.0, but only 4.0..maybe with a newer Debian/gdb. (There was a known problem in older kernels with this signature, I didn't realize I was running old..) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Apr 12 10:12:12 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 12 Apr 2010 10:12:12 +0200 Subject: [M3devel] unused/little used stuff in m3core/unix? In-Reply-To: References: Message-ID: <20100412101212.e3h8b4chco48cc0c@mail.elegosoft.com> Quoting Jay K : > Following are not used: > > fchmod > fchown > getpagesize > sbrk > creat > isatty > > That isn't necessarily all. > > Some are used only in: > > C:\dev2\cm3.2\m3-libs\libm3\src\os\POSIX > e.g. > chdir > getdtablesize > execve > > Some are used only in the unused m3-pkgtools directory or by cvsup. > e.g. umask > > These all traffic in pretty "plain" types (e.g. no structs, no > time_t). So just keep them all? Yes. These are standard POSIX or Unix legacy interfaces. Do not throw them out. > Note of course, uses of these somewhat or significantly inhibit > porting to native Win32. As these are POSIX, that is to be expected. > Account for somewhat arbirary Posix-specific code outside the cm3 tree > and err toward wrapping stuff that is easy? > > Or push the idea that m3core/libm3 are a good (and safe) portability > layer and only provide what they need, and > gradually move them towards C to reduce their needs? As a systems programming language, we should support standard OS interfaces IMO. 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 Mon Apr 12 10:25:20 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 12 Apr 2010 10:25:20 +0200 Subject: [M3devel] regression in m3tests? Message-ID: <20100412102520.dgxs973lk0kgg84s@mail.elegosoft.com> This one is new: http://hudson.modula3.com:8080/job/cm3-test-m3tests-LINUXLIBC6/250/testReport/%28root%29/m3tests/r001__unhandled_exception/ Is it just a new OS version, now writing out an additional line? --- ../src/r0/r001/stderr.build 2008-01-08 17:15:47.000000000 -0800 +++ ../src/r0/r001/LINUXLIBC6/stderr.build 2010-04-11 21:06:07.000000000 -0700 @@ -0,0 +1 @@ +/bin/sh: line 1: 8334 Aborted ./pgm > stdout.pgm.raw 2> stderr.pgm.raw I assume, r002/3/4 are actually OK on Linux, too, just the output is different? We need to adapt the output for r004 (line change in RTAllocator), and probably make our compare a bit more lenient. Any good ideas how to accomplish this easily? 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 jay.krell at cornell.edu Mon Apr 12 11:36:23 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 12 Apr 2010 09:36:23 +0000 Subject: [M3devel] regression in m3tests? In-Reply-To: <20100412102520.dgxs973lk0kgg84s@mail.elegosoft.com> References: <20100412102520.dgxs973lk0kgg84s@mail.elegosoft.com> Message-ID: Tests that abort et. al. have always been a problem. I did a bunch of work to make them less of a problem. But maybe not enough. - Jay > Date: Mon, 12 Apr 2010 10:25:20 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] regression in m3tests? > > This one is new: > > http://hudson.modula3.com:8080/job/cm3-test-m3tests-LINUXLIBC6/250/testReport/%28root%29/m3tests/r001__unhandled_exception/ > > Is it just a new OS version, now writing out an additional line? > > --- ../src/r0/r001/stderr.build 2008-01-08 17:15:47.000000000 -0800 > +++ ../src/r0/r001/LINUXLIBC6/stderr.build 2010-04-11 21:06:07.000000000 -0700 > @@ -0,0 +1 @@ > +/bin/sh: line 1: 8334 Aborted ./pgm > stdout.pgm.raw > 2> stderr.pgm.raw > > I assume, r002/3/4 are actually OK on Linux, too, just the output is > different? > > We need to adapt the output for r004 (line change in RTAllocator), > and probably make our compare a bit more lenient. > > Any good ideas how to accomplish this easily? > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Apr 12 13:13:11 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 12 Apr 2010 13:13:11 +0200 Subject: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? In-Reply-To: <20100411171933.szof1k9n2ss48sg8@mail.elegosoft.com> References: <20100411171933.szof1k9n2ss48sg8@mail.elegosoft.com> Message-ID: <20100412131311.5ax5opbuskcw00sk@mail.elegosoft.com> Quoting wagner at elegosoft.com: > I'm currently tagging the release branch with release_CM3_5_8_RC5. > > Are there still any objections to use the current state of the branch? > > I'll soon try a sample build on birch. As nobody has called `Stop', I've started to build the release packages for RC5. Some can already be found on the download page currently still reachable via the RC4 download (scroll down to the end). http://www.modula3.com/cm3/releng/download.html There have been 401 single changes since the last RC though :-/ See http://hudson.modula3.com:8080/view/makedist/job/cm3-makedist-AMD64_LINUX/changes for details. I don't know how to summarize that or even to motivate this amound of changes that late in a release. Perhaps it's best to just say nothing... If you find any problem with RC5, please let me know as soon as possible. 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 jay.krell at cornell.edu Mon Apr 12 14:45:50 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 12 Apr 2010 12:45:50 +0000 Subject: [M3devel] unused/little used stuff in m3core/unix? In-Reply-To: <20100412101212.e3h8b4chco48cc0c@mail.elegosoft.com> References: , <20100412101212.e3h8b4chco48cc0c@mail.elegosoft.com> Message-ID: Ok on preserving most/all of these but note I'm not keen on preserving like anything dealing with structs or time_t. There are various arguments for/against. This "systems" language interoperates well with C, directly, IF you control the C. Thus we have wrappers. We almost never interface directly with "the OS". Then again, same is true of C. Actual "kernels" have custom calling mechanisms, which gets wrapped in C. I'm not sure we should provide a general set of wrappers, or leave it to each user to write his own, or provide some simple small set. Leaving it to each user is error prone, granted. The historical implementation here was awful and *really* *not* the way. The question then is what should the implementation be. - Jay > Date: Mon, 12 Apr 2010 10:12:12 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] unused/little used stuff in m3core/unix? > > Quoting Jay K : > > > Following are not used: > > > > fchmod > > fchown > > getpagesize > > sbrk > > creat > > isatty > > > > That isn't necessarily all. > > > > Some are used only in: > > > > C:\dev2\cm3.2\m3-libs\libm3\src\os\POSIX > > e.g. > > chdir > > getdtablesize > > execve > > > > Some are used only in the unused m3-pkgtools directory or by cvsup. > > e.g. umask > > > > These all traffic in pretty "plain" types (e.g. no structs, no > > time_t). So just keep them all? > > Yes. These are standard POSIX or Unix legacy interfaces. > Do not throw them out. > > > Note of course, uses of these somewhat or significantly inhibit > > porting to native Win32. > > As these are POSIX, that is to be expected. > > > Account for somewhat arbirary Posix-specific code outside the cm3 tree > > and err toward wrapping stuff that is easy? > > > > Or push the idea that m3core/libm3 are a good (and safe) portability > > layer and only provide what they need, and > > gradually move them towards C to reduce their needs? > > As a systems programming language, we should support standard OS > interfaces IMO. > > Olaf -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Apr 12 15:03:26 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 12 Apr 2010 13:03:26 +0000 Subject: [M3devel] JVideo/struct_timeval? Message-ID: This seems wierd: C:\dev2\cm3.2\m3-ui\jvideo\src\POSIX\jvprotocol.i3(193): timestamp: Utime.struct_timeval; I think they are defining a wire protocol, but embedding platform-specific types in it. How about I just change to Time.T? (64bit floating point, seconds since 1970). We could do like: C:\dev2\cm3.2\m3-ui\jvideo\src\POSIX\decunix\JVSink.m3(440): jvb.timestamp.tv_sec := signed_ntohl(hdr.timestamp.tv_sec); and define it to be transferred as a network order 64bit integer (big endian LONGINT), or maybe an array of 8 bytes. Or maybe define a local struct_timeval separate from Utime that hardcodes the sizes..and maybe using LONGINT? 32bit time_t is apparently still very common, though it seems obviously a big mistake.. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Apr 12 16:46:39 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 12 Apr 2010 14:46:39 +0000 Subject: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? In-Reply-To: <20100412131311.5ax5opbuskcw00sk@mail.elegosoft.com> References: <20100411171933.szof1k9n2ss48sg8@mail.elegosoft.com>, <20100412131311.5ax5opbuskcw00sk@mail.elegosoft.com> Message-ID: Thanks. I see the NT386 packages, but not .msi. - Jay > Date: Mon, 12 Apr 2010 13:13:11 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? > > Quoting wagner at elegosoft.com: > > > I'm currently tagging the release branch with release_CM3_5_8_RC5. > > > > Are there still any objections to use the current state of the branch? > > > > I'll soon try a sample build on birch. > > As nobody has called `Stop', I've started to build the release packages > for RC5. Some can already be found on the download page currently > still reachable via the RC4 download (scroll down to the end). > > http://www.modula3.com/cm3/releng/download.html > > There have been 401 single changes since the last RC though :-/ > See > http://hudson.modula3.com:8080/view/makedist/job/cm3-makedist-AMD64_LINUX/changes > for details. I don't know how to summarize that or even to motivate > this amound of changes that late in a release. Perhaps it's best to > just say nothing... > > If you find any problem with RC5, please let me know as soon as possible. > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Apr 12 17:05:48 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 12 Apr 2010 17:05:48 +0200 Subject: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? In-Reply-To: References: <20100411171933.szof1k9n2ss48sg8@mail.elegosoft.com>, <20100412131311.5ax5opbuskcw00sk@mail.elegosoft.com> Message-ID: <20100412170548.o3go4tu8ys4wgwo4@mail.elegosoft.com> Quoting Jay K : > > Thanks. I see the NT386 packages, but not .msi. I'll check that later; the new index isn't in place, and perhaps the update script is still buggy. Please have a look at the SOLgnu build though: http://hudson.modula3.com:8080/view/makedist/job/cm3-makedist-SOLgnu/16/console This used to work. Anything you changed? Olaf > > > > - Jay > > >> Date: Mon, 12 Apr 2010 13:13:11 +0200 >> From: wagner at elegosoft.com >> To: m3devel at elegosoft.com >> Subject: [M3devel] release 5.8 RC5 build in progress, was: Re: >> release engineering: build release_CM3_5_8_RC5 now? >> >> Quoting wagner at elegosoft.com: >> >> > I'm currently tagging the release branch with release_CM3_5_8_RC5. >> > >> > Are there still any objections to use the current state of the branch? >> > >> > I'll soon try a sample build on birch. >> >> As nobody has called `Stop', I've started to build the release packages >> for RC5. Some can already be found on the download page currently >> still reachable via the RC4 download (scroll down to the end). >> >> http://www.modula3.com/cm3/releng/download.html >> >> There have been 401 single changes since the last RC though :-/ >> See >> http://hudson.modula3.com:8080/view/makedist/job/cm3-makedist-AMD64_LINUX/changes >> for details. I don't know how to summarize that or even to motivate >> this amound of changes that late in a release. Perhaps it's best to >> just say nothing... >> >> If you find any problem with RC5, please let me know as soon as possible. >> >> 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 wagner at elegosoft.com Mon Apr 12 17:26:59 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 12 Apr 2010 17:26:59 +0200 Subject: [M3devel] more RC5 build package problems Message-ID: <20100412172659.fdpk7fn728sgs0c8@mail.elegosoft.com> PPC_DARWIN build failed, too :-( Do you have any idea what could be causing this? http://hudson.modula3.com:8080/view/makedist/job/cm3-makedist-PPC_DARWIN/8/console [...] -rw-r--r-- 1 hudson hudson 1886008 12 Apr 16:18 /Users/hudson/tmp/cm3-bin-ws-tool-PPC_DARWIN-5.8.5-RC5.tgz collection-math.html -rw-r--r-- 1 hudson hudson 2866838 12 Apr 16:19 /Users/hudson/tmp/cm3-bin-ws-math-PPC_DARWIN-5.8.5-RC5.tgz m3-games/columns/PPC_DARWIN/.M3SHIP seems to be broken: Finished: FAILURE The .M3SHIP files looks completely innocent... Olaf PS: Looks like it will take a week to build all target platforms as usual... Invariant could be: never works twice in succession for a give target ;-) -- 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 jay.krell at cornell.edu Mon Apr 12 22:59:34 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 12 Apr 2010 20:59:34 +0000 Subject: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? In-Reply-To: <20100412170548.o3go4tu8ys4wgwo4@mail.elegosoft.com> References: <20100411171933.szof1k9n2ss48sg8@mail.elegosoft.com>, <20100412131311.5ax5opbuskcw00sk@mail.elegosoft.com>, , <20100412170548.o3go4tu8ys4wgwo4@mail.elegosoft.com> Message-ID: SOLgnu partial explanation: Building cm3 itself is going down the path that occurs when you don't -DCM3_VERSION_NUMBER -DCM3_VERSION_TEXT -DCM3_LAST_CHANGED. Not specifying them is supposed to work, but "you" are supposed to specify them really. Enough of a hint? (I don't have the full answer myself.) - Jay > Date: Mon, 12 Apr 2010 17:05:48 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? > > Quoting Jay K : > > > > > Thanks. I see the NT386 packages, but not .msi. > > I'll check that later; the new index isn't in place, and perhaps > the update script is still buggy. > > Please have a look at the SOLgnu build though: > > > http://hudson.modula3.com:8080/view/makedist/job/cm3-makedist-SOLgnu/16/console > > This used to work. Anything you changed? > > Olaf > > > > > > > > - Jay > > > > > >> Date: Mon, 12 Apr 2010 13:13:11 +0200 > >> From: wagner at elegosoft.com > >> To: m3devel at elegosoft.com > >> Subject: [M3devel] release 5.8 RC5 build in progress, was: Re: > >> release engineering: build release_CM3_5_8_RC5 now? > >> > >> Quoting wagner at elegosoft.com: > >> > >> > I'm currently tagging the release branch with release_CM3_5_8_RC5. > >> > > >> > Are there still any objections to use the current state of the branch? > >> > > >> > I'll soon try a sample build on birch. > >> > >> As nobody has called `Stop', I've started to build the release packages > >> for RC5. Some can already be found on the download page currently > >> still reachable via the RC4 download (scroll down to the end). > >> > >> http://www.modula3.com/cm3/releng/download.html > >> > >> There have been 401 single changes since the last RC though :-/ > >> See > >> http://hudson.modula3.com:8080/view/makedist/job/cm3-makedist-AMD64_LINUX/changes > >> for details. I don't know how to summarize that or even to motivate > >> this amound of changes that late in a release. Perhaps it's best to > >> just say nothing... > >> > >> If you find any problem with RC5, please let me know as soon as possible. > >> > >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Apr 12 23:07:02 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 12 Apr 2010 21:07:02 +0000 Subject: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? In-Reply-To: References: <20100411171933.szof1k9n2ss48sg8@mail.elegosoft.com>, , <20100412131311.5ax5opbuskcw00sk@mail.elegosoft.com>, , , , <20100412170548.o3go4tu8ys4wgwo4@mail.elegosoft.com>, Message-ID: I'm *guessing* some *sh problem. Want to try /usr/bin/bash? - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com Date: Mon, 12 Apr 2010 20:59:34 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? SOLgnu partial explanation: Building cm3 itself is going down the path that occurs when you don't -DCM3_VERSION_NUMBER -DCM3_VERSION_TEXT -DCM3_LAST_CHANGED. Not specifying them is supposed to work, but "you" are supposed to specify them really. Enough of a hint? (I don't have the full answer myself.) - Jay > Date: Mon, 12 Apr 2010 17:05:48 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? > > Quoting Jay K : > > > > > Thanks. I see the NT386 packages, but not .msi. > > I'll check that later; the new index isn't in place, and perhaps > the update script is still buggy. > > Please have a look at the SOLgnu build though: > > > http://hudson.modula3.com:8080/view/makedist/job/cm3-makedist-SOLgnu/16/console > > This used to work. Anything you changed? > > Olaf > > > > > > > > - Jay > > > > > >> Date: Mon, 12 Apr 2010 13:13:11 +0200 > >> From: wagner at elegosoft.com > >> To: m3devel at elegosoft.com > >> Subject: [M3devel] release 5.8 RC5 build in progress, was: Re: > >> release engineering: build release_CM3_5_8_RC5 now? > >> > >> Quoting wagner at elegosoft.com: > >> > >> > I'm currently tagging the release branch with release_CM3_5_8_RC5. > >> > > >> > Are there still any objections to use the current state of the branch? > >> > > >> > I'll soon try a sample build on birch. > >> > >> As nobody has called `Stop', I've started to build the release packages > >> for RC5. Some can already be found on the download page currently > >> still reachable via the RC4 download (scroll down to the end). > >> > >> http://www.modula3.com/cm3/releng/download.html > >> > >> There have been 401 single changes since the last RC though :-/ > >> See > >> http://hudson.modula3.com:8080/view/makedist/job/cm3-makedist-AMD64_LINUX/changes > >> for details. I don't know how to summarize that or even to motivate > >> this amound of changes that late in a release. Perhaps it's best to > >> just say nothing... > >> > >> If you find any problem with RC5, please let me know as soon as possible. > >> > >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Apr 12 23:14:47 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 12 Apr 2010 21:14:47 +0000 Subject: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? In-Reply-To: References: <20100411171933.szof1k9n2ss48sg8@mail.elegosoft.com>, ,,<20100412131311.5ax5opbuskcw00sk@mail.elegosoft.com>, ,,, , , <20100412170548.o3go4tu8ys4wgwo4@mail.elegosoft.com>, , , Message-ID: I see part of the problem. - You do define the version earlier in the build, but not later. From reading the log. - I don't know why the grep doesn't work. Searching for '-DROOT'... C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\make-bin-dist-min.sh(133):BUILDLOCAL="${CM3} -build -override -DROOT='${CM3ROOT}'" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\make-bin-dist-min.sh(134):CLEANLOCAL="${CM3} -clean -override -DROOT='${CM3ROOT}'" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\make-bin-dist-min.sh(135):BUILDGLOBAL="${CM3} -build -DROOT='${CM3ROOT}'" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\make-bin-dist-min.sh(136):CLEANGLOBAL="${CM3} -clean -DROOT='${CM3ROOT}'" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\make-bin-dist-min.sh(137):SHIP="${CM3} -ship -DROOT='${CM3ROOT}'" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgcmds.sh(21):DEFS="-DROOT='${CM3ROOT}' -DCM3_VERSION_TEXT='${CM3VERSION}' -DCM3_VERSION_NUMBER='${CM3VERSIONNUM}' -DCM3_LAST_CHANGED='${CM3LASTCHANGED}'" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgmap.sh(424): echo " +++ cm3 -build -override -DTEST -DRUN -DROOT=$ROOT +++" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgmap.sh(429): tres=`cm3 -build -override -DTEST -DRUN -DROOT="${ROOT}" 2> stderr` Maybe use ${DEFS} more? You could also hack cm3/src/m3makefile for the release. Copy the data into it. A better fix in head for the next one? Searching for 'DEFS'... C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgcmds.sh(21):DEFS="-DROOT='${CM3ROOT}' -DCM3_VERSION_TEXT='${CM3VERSION}' -DCM3_VERSION_NUMBER='${CM3VERSIONNUM}' -DCM3_LAST_CHANGED='${CM3LASTCHANGED}'" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgcmds.sh(22):BUILDLOCAL="${BUILDLOCAL:-${CM3} -build -override \$RARGS ${DEFS} ${BUILDARGS}}" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgcmds.sh(23):CLEANLOCAL="${CLEANLOCAL:-${CM3} -clean -override \$RARGS ${DEFS} ${CLEANARGS}}" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgcmds.sh(24):BUILDGLOBAL="${BUILDGLOBAL:-${CM3} -build ${DEFS} \$RARGS ${BUILDARGS}}" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgcmds.sh(25):CLEANGLOBAL="${CLEANGLOBAL:-${CM3} -clean ${DEFS} \$RARGS ${CLEANARGS}}" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgcmds.sh(26):SHIP="${SHIP:-${CM3} -ship \$RARGS ${DEFS} ${SHIPARGS}}" Is DEFS missing somewhere? - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com Date: Mon, 12 Apr 2010 21:07:02 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? I'm *guessing* some *sh problem. Want to try /usr/bin/bash? - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com Date: Mon, 12 Apr 2010 20:59:34 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? SOLgnu partial explanation: Building cm3 itself is going down the path that occurs when you don't -DCM3_VERSION_NUMBER -DCM3_VERSION_TEXT -DCM3_LAST_CHANGED. Not specifying them is supposed to work, but "you" are supposed to specify them really. Enough of a hint? (I don't have the full answer myself.) - Jay > Date: Mon, 12 Apr 2010 17:05:48 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? > > Quoting Jay K : > > > > > Thanks. I see the NT386 packages, but not .msi. > > I'll check that later; the new index isn't in place, and perhaps > the update script is still buggy. > > Please have a look at the SOLgnu build though: > > > http://hudson.modula3.com:8080/view/makedist/job/cm3-makedist-SOLgnu/16/console > > This used to work. Anything you changed? > > Olaf > > > > > > > > - Jay > > > > > >> Date: Mon, 12 Apr 2010 13:13:11 +0200 > >> From: wagner at elegosoft.com > >> To: m3devel at elegosoft.com > >> Subject: [M3devel] release 5.8 RC5 build in progress, was: Re: > >> release engineering: build release_CM3_5_8_RC5 now? > >> > >> Quoting wagner at elegosoft.com: > >> > >> > I'm currently tagging the release branch with release_CM3_5_8_RC5. > >> > > >> > Are there still any objections to use the current state of the branch? > >> > > >> > I'll soon try a sample build on birch. > >> > >> As nobody has called `Stop', I've started to build the release packages > >> for RC5. Some can already be found on the download page currently > >> still reachable via the RC4 download (scroll down to the end). > >> > >> http://www.modula3.com/cm3/releng/download.html > >> > >> There have been 401 single changes since the last RC though :-/ > >> See > >> http://hudson.modula3.com:8080/view/makedist/job/cm3-makedist-AMD64_LINUX/changes > >> for details. I don't know how to summarize that or even to motivate > >> this amound of changes that late in a release. Perhaps it's best to > >> just say nothing... > >> > >> If you find any problem with RC5, please let me know as soon as possible. > >> > >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Apr 12 23:24:03 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 12 Apr 2010 21:24:03 +0000 Subject: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? In-Reply-To: References: <20100411171933.szof1k9n2ss48sg8@mail.elegosoft.com>, , , , <20100412131311.5ax5opbuskcw00sk@mail.elegosoft.com>, , , , , , , , <20100412170548.o3go4tu8ys4wgwo4@mail.elegosoft.com>, , , , , , Message-ID: A good option is to export these three variables: CM3VERSIONNUM CM3VERSION CM3LASTCHANGED and/or use the -D switches. Otherwise m3-sys/cm3/m3makefile goes down a gnarly path (that I put in) of trying to read scripts/version. Which usually works, but could be too sensitive to /bin/sh behavior...often bites us you know. - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com Date: Mon, 12 Apr 2010 21:14:47 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? I see part of the problem. - You do define the version earlier in the build, but not later. From reading the log. - I don't know why the grep doesn't work. Searching for '-DROOT'... C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\make-bin-dist-min.sh(133):BUILDLOCAL="${CM3} -build -override -DROOT='${CM3ROOT}'" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\make-bin-dist-min.sh(134):CLEANLOCAL="${CM3} -clean -override -DROOT='${CM3ROOT}'" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\make-bin-dist-min.sh(135):BUILDGLOBAL="${CM3} -build -DROOT='${CM3ROOT}'" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\make-bin-dist-min.sh(136):CLEANGLOBAL="${CM3} -clean -DROOT='${CM3ROOT}'" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\make-bin-dist-min.sh(137):SHIP="${CM3} -ship -DROOT='${CM3ROOT}'" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgcmds.sh(21):DEFS="-DROOT='${CM3ROOT}' -DCM3_VERSION_TEXT='${CM3VERSION}' -DCM3_VERSION_NUMBER='${CM3VERSIONNUM}' -DCM3_LAST_CHANGED='${CM3LASTCHANGED}'" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgmap.sh(424): echo " +++ cm3 -build -override -DTEST -DRUN -DROOT=$ROOT +++" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgmap.sh(429): tres=`cm3 -build -override -DTEST -DRUN -DROOT="${ROOT}" 2> stderr` Maybe use ${DEFS} more? You could also hack cm3/src/m3makefile for the release. Copy the data into it. A better fix in head for the next one? Searching for 'DEFS'... C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgcmds.sh(21):DEFS="-DROOT='${CM3ROOT}' -DCM3_VERSION_TEXT='${CM3VERSION}' -DCM3_VERSION_NUMBER='${CM3VERSIONNUM}' -DCM3_LAST_CHANGED='${CM3LASTCHANGED}'" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgcmds.sh(22):BUILDLOCAL="${BUILDLOCAL:-${CM3} -build -override \$RARGS ${DEFS} ${BUILDARGS}}" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgcmds.sh(23):CLEANLOCAL="${CLEANLOCAL:-${CM3} -clean -override \$RARGS ${DEFS} ${CLEANARGS}}" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgcmds.sh(24):BUILDGLOBAL="${BUILDGLOBAL:-${CM3} -build ${DEFS} \$RARGS ${BUILDARGS}}" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgcmds.sh(25):CLEANGLOBAL="${CLEANGLOBAL:-${CM3} -clean ${DEFS} \$RARGS ${CLEANARGS}}" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgcmds.sh(26):SHIP="${SHIP:-${CM3} -ship \$RARGS ${DEFS} ${SHIPARGS}}" Is DEFS missing somewhere? - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com Date: Mon, 12 Apr 2010 21:07:02 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? I'm *guessing* some *sh problem. Want to try /usr/bin/bash? - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com Date: Mon, 12 Apr 2010 20:59:34 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? SOLgnu partial explanation: Building cm3 itself is going down the path that occurs when you don't -DCM3_VERSION_NUMBER -DCM3_VERSION_TEXT -DCM3_LAST_CHANGED. Not specifying them is supposed to work, but "you" are supposed to specify them really. Enough of a hint? (I don't have the full answer myself.) - Jay > Date: Mon, 12 Apr 2010 17:05:48 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? > > Quoting Jay K : > > > > > Thanks. I see the NT386 packages, but not .msi. > > I'll check that later; the new index isn't in place, and perhaps > the update script is still buggy. > > Please have a look at the SOLgnu build though: > > > http://hudson.modula3.com:8080/view/makedist/job/cm3-makedist-SOLgnu/16/console > > This used to work. Anything you changed? > > Olaf > > > > > > > > - Jay > > > > > >> Date: Mon, 12 Apr 2010 13:13:11 +0200 > >> From: wagner at elegosoft.com > >> To: m3devel at elegosoft.com > >> Subject: [M3devel] release 5.8 RC5 build in progress, was: Re: > >> release engineering: build release_CM3_5_8_RC5 now? > >> > >> Quoting wagner at elegosoft.com: > >> > >> > I'm currently tagging the release branch with release_CM3_5_8_RC5. > >> > > >> > Are there still any objections to use the current state of the branch? > >> > > >> > I'll soon try a sample build on birch. > >> > >> As nobody has called `Stop', I've started to build the release packages > >> for RC5. Some can already be found on the download page currently > >> still reachable via the RC4 download (scroll down to the end). > >> > >> http://www.modula3.com/cm3/releng/download.html > >> > >> There have been 401 single changes since the last RC though :-/ > >> See > >> http://hudson.modula3.com:8080/view/makedist/job/cm3-makedist-AMD64_LINUX/changes > >> for details. I don't know how to summarize that or even to motivate > >> this amound of changes that late in a release. Perhaps it's best to > >> just say nothing... > >> > >> If you find any problem with RC5, please let me know as soon as possible. > >> > >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Apr 12 23:30:19 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 12 Apr 2010 21:30:19 +0000 Subject: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? In-Reply-To: References: <20100411171933.szof1k9n2ss48sg8@mail.elegosoft.com>, , , , <20100412131311.5ax5opbuskcw00sk@mail.elegosoft.com>, , , , , , , , , <20100412170548.o3go4tu8ys4wgwo4@mail.elegosoft.com>, , , , , , , Message-ID: Actually it looks like the environment path is a little gnarly too. Best to use -D. Maybe we should check in scripts/version.quake along with scripts/version. Two copies are bad, but the machinations in m3-sys/cm3/m3makefile aren't great either. Or maybe version.quake would be the one and only? Depends on where else we really need it, and how easy it is to use in those contexts. Maybe the quake could be written in a better way. I can have another go at it esp. with the newer quake primitives. version.quake would be easy and simple though, at the cost of having the data checked in twice. I'll probably do that in head "soon" (at least 12 hours away). - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com CC: m3devel at elegosoft.com Subject: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? Date: Mon, 12 Apr 2010 21:24:03 +0000 A good option is to export these three variables: CM3VERSIONNUM CM3VERSION CM3LASTCHANGED and/or use the -D switches. Otherwise m3-sys/cm3/m3makefile goes down a gnarly path (that I put in) of trying to read scripts/version. Which usually works, but could be too sensitive to /bin/sh behavior...often bites us you know. - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com Date: Mon, 12 Apr 2010 21:14:47 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? I see part of the problem. - You do define the version earlier in the build, but not later. From reading the log. - I don't know why the grep doesn't work. Searching for '-DROOT'... C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\make-bin-dist-min.sh(133):BUILDLOCAL="${CM3} -build -override -DROOT='${CM3ROOT}'" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\make-bin-dist-min.sh(134):CLEANLOCAL="${CM3} -clean -override -DROOT='${CM3ROOT}'" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\make-bin-dist-min.sh(135):BUILDGLOBAL="${CM3} -build -DROOT='${CM3ROOT}'" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\make-bin-dist-min.sh(136):CLEANGLOBAL="${CM3} -clean -DROOT='${CM3ROOT}'" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\make-bin-dist-min.sh(137):SHIP="${CM3} -ship -DROOT='${CM3ROOT}'" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgcmds.sh(21):DEFS="-DROOT='${CM3ROOT}' -DCM3_VERSION_TEXT='${CM3VERSION}' -DCM3_VERSION_NUMBER='${CM3VERSIONNUM}' -DCM3_LAST_CHANGED='${CM3LASTCHANGED}'" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgmap.sh(424): echo " +++ cm3 -build -override -DTEST -DRUN -DROOT=$ROOT +++" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgmap.sh(429): tres=`cm3 -build -override -DTEST -DRUN -DROOT="${ROOT}" 2> stderr` Maybe use ${DEFS} more? You could also hack cm3/src/m3makefile for the release. Copy the data into it. A better fix in head for the next one? Searching for 'DEFS'... C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgcmds.sh(21):DEFS="-DROOT='${CM3ROOT}' -DCM3_VERSION_TEXT='${CM3VERSION}' -DCM3_VERSION_NUMBER='${CM3VERSIONNUM}' -DCM3_LAST_CHANGED='${CM3LASTCHANGED}'" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgcmds.sh(22):BUILDLOCAL="${BUILDLOCAL:-${CM3} -build -override \$RARGS ${DEFS} ${BUILDARGS}}" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgcmds.sh(23):CLEANLOCAL="${CLEANLOCAL:-${CM3} -clean -override \$RARGS ${DEFS} ${CLEANARGS}}" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgcmds.sh(24):BUILDGLOBAL="${BUILDGLOBAL:-${CM3} -build ${DEFS} \$RARGS ${BUILDARGS}}" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgcmds.sh(25):CLEANGLOBAL="${CLEANGLOBAL:-${CM3} -clean ${DEFS} \$RARGS ${CLEANARGS}}" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgcmds.sh(26):SHIP="${SHIP:-${CM3} -ship \$RARGS ${DEFS} ${SHIPARGS}}" Is DEFS missing somewhere? - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com Date: Mon, 12 Apr 2010 21:07:02 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? I'm *guessing* some *sh problem. Want to try /usr/bin/bash? - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com Date: Mon, 12 Apr 2010 20:59:34 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? SOLgnu partial explanation: Building cm3 itself is going down the path that occurs when you don't -DCM3_VERSION_NUMBER -DCM3_VERSION_TEXT -DCM3_LAST_CHANGED. Not specifying them is supposed to work, but "you" are supposed to specify them really. Enough of a hint? (I don't have the full answer myself.) - Jay > Date: Mon, 12 Apr 2010 17:05:48 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? > > Quoting Jay K : > > > > > Thanks. I see the NT386 packages, but not .msi. > > I'll check that later; the new index isn't in place, and perhaps > the update script is still buggy. > > Please have a look at the SOLgnu build though: > > > http://hudson.modula3.com:8080/view/makedist/job/cm3-makedist-SOLgnu/16/console > > This used to work. Anything you changed? > > Olaf > > > > > > > > - Jay > > > > > >> Date: Mon, 12 Apr 2010 13:13:11 +0200 > >> From: wagner at elegosoft.com > >> To: m3devel at elegosoft.com > >> Subject: [M3devel] release 5.8 RC5 build in progress, was: Re: > >> release engineering: build release_CM3_5_8_RC5 now? > >> > >> Quoting wagner at elegosoft.com: > >> > >> > I'm currently tagging the release branch with release_CM3_5_8_RC5. > >> > > >> > Are there still any objections to use the current state of the branch? > >> > > >> > I'll soon try a sample build on birch. > >> > >> As nobody has called `Stop', I've started to build the release packages > >> for RC5. Some can already be found on the download page currently > >> still reachable via the RC4 download (scroll down to the end). > >> > >> http://www.modula3.com/cm3/releng/download.html > >> > >> There have been 401 single changes since the last RC though :-/ > >> See > >> http://hudson.modula3.com:8080/view/makedist/job/cm3-makedist-AMD64_LINUX/changes > >> for details. I don't know how to summarize that or even to motivate > >> this amound of changes that late in a release. Perhaps it's best to > >> just say nothing... > >> > >> If you find any problem with RC5, please let me know as soon as possible. > >> > >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Apr 12 23:39:57 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 12 Apr 2010 23:39:57 +0200 Subject: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? In-Reply-To: References: <20100411171933.szof1k9n2ss48sg8@mail.elegosoft.com>, , , , <20100412131311.5ax5opbuskcw00sk@mail.elegosoft.com>, , , , , , , , , <20100412170548.o3go4tu8ys4wgwo4@mail.elegosoft.com>, , , , , , , Message-ID: <20100412233957.ftgkq5jpicoo800w@mail.elegosoft.com> Well, I was just wondering what has changed, since the scripts have worked for earlier RCs on your Solaris system. And they're working on half a dozen other platforms. I'll try to follow some of your hints tomorrow. Olaf Quoting Jay K : > Actually it looks like the environment path is a little gnarly too. > > Best to use -D. > > Maybe we should check in scripts/version.quake along with scripts/version. > > Two copies are bad, but the machinations in m3-sys/cm3/m3makefile > aren't great either. > > Or maybe version.quake would be the one and only? > > Depends on where else we really need it, and how easy it is to use > in those contexts. > > Maybe the quake could be written in a better way. I can have > another go at it esp. with the newer quake primitives. > > > > version.quake would be easy and simple though, at the cost of having > the data checked in twice. > > I'll probably do that in head "soon" (at least 12 hours away). > > > > - Jay > > > > > From: jay.krell at cornell.edu > To: wagner at elegosoft.com > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: > release engineering: build release_CM3_5_8_RC5 now? > Date: Mon, 12 Apr 2010 21:24:03 +0000 > > > > A good option is to export these three variables: > > CM3VERSIONNUM > CM3VERSION > CM3LASTCHANGED > > and/or use the -D switches. > Otherwise m3-sys/cm3/m3makefile goes down a gnarly path (that I put > in) of trying to read scripts/version. > Which usually works, but could be too sensitive to /bin/sh > behavior...often bites us you know. > > - Jay > > > > > From: jay.krell at cornell.edu > To: wagner at elegosoft.com > Date: Mon, 12 Apr 2010 21:14:47 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] release 5.8 RC5 build in progress, was: Re: > release engineering: build release_CM3_5_8_RC5 now? > > > > I see part of the problem. > - You do define the version earlier in the build, but not later. > From reading the log. > - I don't know why the grep doesn't work. > > > Searching for '-DROOT'... > C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\make-bin-dist-min.sh(133):BUILDLOCAL="${CM3} -build -override > -DROOT='${CM3ROOT}'" > C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\make-bin-dist-min.sh(134):CLEANLOCAL="${CM3} -clean -override > -DROOT='${CM3ROOT}'" > C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\make-bin-dist-min.sh(135):BUILDGLOBAL="${CM3} -build > -DROOT='${CM3ROOT}'" > C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\make-bin-dist-min.sh(136):CLEANGLOBAL="${CM3} -clean > -DROOT='${CM3ROOT}'" > C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\make-bin-dist-min.sh(137):SHIP="${CM3} -ship > -DROOT='${CM3ROOT}'" > C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgcmds.sh(21):DEFS="-DROOT='${CM3ROOT}' -DCM3_VERSION_TEXT='${CM3VERSION}' -DCM3_VERSION_NUMBER='${CM3VERSIONNUM}' > -DCM3_LAST_CHANGED='${CM3LASTCHANGED}'" > C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgmap.sh(424): > echo " +++ cm3 -build -override -DTEST -DRUN -DROOT=$ROOT +++" > C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgmap.sh(429): > tres=`cm3 -build -override -DTEST -DRUN -DROOT="${ROOT}" 2> stderr` > > > Maybe use ${DEFS} more? > You could also hack cm3/src/m3makefile for the release. Copy the > data into it. > A better fix in head for the next one? > > > Searching for 'DEFS'... > C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgcmds.sh(21):DEFS="-DROOT='${CM3ROOT}' -DCM3_VERSION_TEXT='${CM3VERSION}' -DCM3_VERSION_NUMBER='${CM3VERSIONNUM}' > -DCM3_LAST_CHANGED='${CM3LASTCHANGED}'" > C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgcmds.sh(22):BUILDLOCAL="${BUILDLOCAL:-${CM3} -build -override \$RARGS ${DEFS} > ${BUILDARGS}}" > C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgcmds.sh(23):CLEANLOCAL="${CLEANLOCAL:-${CM3} -clean -override \$RARGS ${DEFS} > ${CLEANARGS}}" > C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgcmds.sh(24):BUILDGLOBAL="${BUILDGLOBAL:-${CM3} -build ${DEFS} \$RARGS > ${BUILDARGS}}" > C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgcmds.sh(25):CLEANGLOBAL="${CLEANGLOBAL:-${CM3} -clean ${DEFS} \$RARGS > ${CLEANARGS}}" > C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgcmds.sh(26):SHIP="${SHIP:-${CM3} -ship \$RARGS ${DEFS} > ${SHIPARGS}}" > > > Is DEFS missing somewhere? > > > - Jay > > > > From: jay.krell at cornell.edu > To: wagner at elegosoft.com > Date: Mon, 12 Apr 2010 21:07:02 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] release 5.8 RC5 build in progress, was: Re: > release engineering: build release_CM3_5_8_RC5 now? > > > > I'm *guessing* some *sh problem. > Want to try /usr/bin/bash? > > - Jay > > > > > > From: jay.krell at cornell.edu > To: wagner at elegosoft.com > Date: Mon, 12 Apr 2010 20:59:34 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] release 5.8 RC5 build in progress, was: Re: > release engineering: build release_CM3_5_8_RC5 now? > > > > SOLgnu partial explanation: > Building cm3 itself is going down the path that occurs when you > don't -DCM3_VERSION_NUMBER -DCM3_VERSION_TEXT -DCM3_LAST_CHANGED. > Not specifying them is supposed to work, but "you" are supposed to > specify them really. > Enough of a hint? (I don't have the full answer myself.) > > - Jay > > >> Date: Mon, 12 Apr 2010 17:05:48 +0200 >> From: wagner at elegosoft.com >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: >> release engineering: build release_CM3_5_8_RC5 now? >> >> Quoting Jay K : >> >> > >> > Thanks. I see the NT386 packages, but not .msi. >> >> I'll check that later; the new index isn't in place, and perhaps >> the update script is still buggy. >> >> Please have a look at the SOLgnu build though: >> >> >> http://hudson.modula3.com:8080/view/makedist/job/cm3-makedist-SOLgnu/16/console >> >> This used to work. Anything you changed? >> >> Olaf >> > >> > >> > >> > - Jay >> > >> > >> >> Date: Mon, 12 Apr 2010 13:13:11 +0200 >> >> From: wagner at elegosoft.com >> >> To: m3devel at elegosoft.com >> >> Subject: [M3devel] release 5.8 RC5 build in progress, was: Re: >> >> release engineering: build release_CM3_5_8_RC5 now? >> >> >> >> Quoting wagner at elegosoft.com: >> >> >> >> > I'm currently tagging the release branch with release_CM3_5_8_RC5. >> >> > >> >> > Are there still any objections to use the current state of the branch? >> >> > >> >> > I'll soon try a sample build on birch. >> >> >> >> As nobody has called `Stop', I've started to build the release packages >> >> for RC5. Some can already be found on the download page currently >> >> still reachable via the RC4 download (scroll down to the end). >> >> >> >> http://www.modula3.com/cm3/releng/download.html >> >> >> >> There have been 401 single changes since the last RC though :-/ >> >> See >> >> >> http://hudson.modula3.com:8080/view/makedist/job/cm3-makedist-AMD64_LINUX/changes >> >> for details. I don't know how to summarize that or even to motivate >> >> this amound of changes that late in a release. Perhaps it's best to >> >> just say nothing... >> >> >> >> If you find any problem with RC5, please let me know as soon as possible. >> >> >> >> 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 >> > -- 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 jay.krell at cornell.edu Wed Apr 14 11:18:05 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 14 Apr 2010 09:18:05 +0000 Subject: [M3devel] SchedulerPosix.IOWait, IOAlertWait Message-ID: SchedulerPosix.IOWait, IOAlertWait: I think the pthread implementation here leaks for every call. The user thread implementation has global bit arrays for a select call, that it makes large enough to hold the largest file descriptor seen. The posix implementation seems to have made them locals, good, but never cleans them up. I'll see if I can confirm and fix. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Apr 14 11:32:32 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 14 Apr 2010 09:32:32 +0000 Subject: [M3devel] SchedulerPosix.IOWait, IOAlertWait In-Reply-To: References: Message-ID: sorry, nevermind, I thought it was untraced for some reaosn. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Wed, 14 Apr 2010 09:18:05 +0000 Subject: [M3devel] SchedulerPosix.IOWait, IOAlertWait SchedulerPosix.IOWait, IOAlertWait: I think the pthread implementation here leaks for every call. The user thread implementation has global bit arrays for a select call, that it makes large enough to hold the largest file descriptor seen. The posix implementation seems to have made them locals, good, but never cleans them up. I'll see if I can confirm and fix. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Apr 14 12:44:08 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 14 Apr 2010 10:44:08 +0000 Subject: [M3devel] hidden interface vs. public Interface? hidden isn't hidden? Message-ID: I tried changing from Interface("Utime") to interface("Utime"). Now, it turns out, that is a mistake anyway, there are still uses, and they aren't going away. But even so, this change doesn't do what it is supposed to. Utime gets marked "hidden" in the .M3EXPORTS files. I haven't yet decipered the .m3x file. I'm still able to build clients e.g. m3-games/tetris. I'm certain I'm using the updated one. I even rm -rf /cm3/pkg/m3core. It seems "hidden" doesn't work? I'll have to dig into the .m3x file I think. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Wed Apr 14 13:01:26 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 14 Apr 2010 13:01:26 +0200 Subject: [M3devel] hidden interface vs. public Interface? hidden isn't hidden? Message-ID: <20100414130126.b9g9pq79escw0g8c@mail.elegosoft.com> Quoting Jay K : > > I tried changing from Interface("Utime") to interface("Utime"). > > Now, it turns out, that is a mistake anyway, there are still > uses, and they aren't going away. > > But even so, this change doesn't do what it is supposed to. > Utime gets marked "hidden" in the .M3EXPORTS files. > I haven't yet decipered the .m3x file. > I'm still able to build clients e.g. m3-games/tetris. > I'm certain I'm using the updated one. I even rm -rf /cm3/pkg/m3core. > > It seems "hidden" doesn't work? > > I'll have to dig into the .m3x file I think. I remember that in the SRC system, hidden files weren't shipped at all to the global package pool. Critical Mass changed that, because hey wanted the source to be available for browsing. I always assumed that the compiler was able to hnour the hidden state of the interface nonetheless. If it doesn't work, we should fix 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 jay.krell at cornell.edu Wed Apr 14 13:37:19 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 14 Apr 2010 11:37:19 +0000 Subject: [M3devel] hidden interface vs. public Interface? hidden isn't hidden? In-Reply-To: <20100414130126.b9g9pq79escw0g8c@mail.elegosoft.com> References: <20100414130126.b9g9pq79escw0g8c@mail.elegosoft.com> Message-ID: Given that public interface TimePosix has functions that return types from Utime, it seems reasonable, though maybe with a warning. But I think when I hid TimePosix, just as an experiment, it still made them public. Something to be looked into much later. - Jay > Date: Wed, 14 Apr 2010 13:01:26 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] hidden interface vs. public Interface? hidden isn't hidden? > > Quoting Jay K : > > > > > I tried changing from Interface("Utime") to interface("Utime"). > > > > Now, it turns out, that is a mistake anyway, there are still > > uses, and they aren't going away. > > > > But even so, this change doesn't do what it is supposed to. > > Utime gets marked "hidden" in the .M3EXPORTS files. > > I haven't yet decipered the .m3x file. > > I'm still able to build clients e.g. m3-games/tetris. > > I'm certain I'm using the updated one. I even rm -rf /cm3/pkg/m3core. > > > > It seems "hidden" doesn't work? > > > > I'll have to dig into the .m3x file I think. > > I remember that in the SRC system, hidden files weren't shipped at all > to the global package pool. Critical Mass changed that, because hey > wanted the source to be available for browsing. > > I always assumed that the compiler was able to hnour the hidden state > of the interface nonetheless. > > If it doesn't work, we should fix 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Apr 14 13:41:30 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 14 Apr 2010 11:41:30 +0000 Subject: [M3devel] checking of timezone in DateBsd.m3 vs. DatePosix.m3? Message-ID: Seems inconsistent: DateBsd.m3: IF (z = NIL) OR (z^ = Local^) THEN tm := Utime.localtime(ADR(tv.tv_sec)); ELSIF z^ = UTC^ THEN tm := Utime.gmtime(ADR(tv.tv_sec)); ELSE (* unknown timezone *) <* ASSERT FALSE *> ? DatePosix.m3: IF (z = NIL) OR (z^ = 0) THEN EVAL Utime.localtime_r (tv.tv_sec, ADR (tm)); ELSE EVAL Utime.gmtime_r (tv.tv_sec, ADR(tm)); END; ? DateBsd.m3 is the overwhelmingly used version, so presumably we should be like it. ? readonly _DateImpls = { "CYGWIN" : "DatePosix", (* hardly counts *) "DARWIN" : "DateBsd", "FREEBSD" : "DateBsd", "HPUX" : "DatePosix", (* hardly counts *) "INTERIX" : "DatePosix", (* hardly counts *) "LINUX" : "DateBsd", "NETBSD" : "DateBsd", "NT" : "DatePosix", (* not actually used *) "OPENBSD" : "DateBsd", "SOLARIS" : "DatePosix", (* counts! *) } In both cases timezone is opaque but revealed to be a branded ref to an integer. Of course, I'm going through this code again for purposes of porting to C, a) to remove struct tm, b) use http://code.google.com/p/y2038/ c) remove struct_timeval/gettimeofday. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Wed Apr 14 16:10:43 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 14 Apr 2010 16:10:43 +0200 Subject: [M3devel] more release build problems, was: RE: release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? In-Reply-To: References: <20100411171933.szof1k9n2ss48sg8@mail.elegosoft.com>, , , , <20100412131311.5ax5opbuskcw00sk@mail.elegosoft.com>, , , , , , , , , , <20100412170548.o3go4tu8ys4wgwo4@mail.elegosoft.com>, , , , , , , , , <20100413171231.bvpqvjz0g0s08k4o@mail.elegosoft.com>, <20100413205035.s01zgk7nk4gggkso@mail.elegosoft.com>, <20100413224251.m5n8tfabk004gc40@mail.elegosoft.com>, , <20100414130624.ej61zwd0dcg0w848@mail.elegosoft.com>, <20100414131755.y55odckn404ws80c@mail.elegosoft.com> Message-ID: <20100414161043.xqhxn8nr40cockko@mail.elegosoft.com> Quoting Jay K : > Olaf, something I don't understand is why the distribution building > is a separate Hudson task. > > Or more specifically, why these don't just run "all the time", > either once a day, or after checkins, or something like that. Because it is a considerable load and we build a fixed (frozen) configuration with it. Once this release is out, we may try to build packages once a day, as tinderbox did/does. > Perhaps this stuff was occuring but I wasn't noticing the failures? > I do look sometimes but not enough. We just haven't looked. Breakage can be seen at http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLgnu/ http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLgnu/lastBuild/testReport/ m3core installation fails, too: "/home/hudson/workspace/cm3-test-all-pkgs-SOLgnu/cm3/m3-libs/m3core/SOLgnu/.M3SHIP", line 4: quake runtime error: unable to copy "libm3core.so.5" to "/home/hudson/work/cm3-inst/ssol/last-ok/lib/libm3core.so.5": errno=2 libm3core.so.5 Fatal Error: package build failed I'll try to improve the checks for serious failures before the next release. Olaf > - Jay > > > > From: jay.krell at cornell.edu > To: wagner at elegosoft.com > Subject: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: > release engineering: build release_CM3_5_8_RC5 now? > Date: Wed, 14 Apr 2010 12:55:23 +0000 > > > > For cvsup/zlib: > The libz hack for Solaris wasn't in release. > I noticed and fixed another minor problem. > > > Try these files: > > > scripts/branch.quake > m3-tools/cvsup/quake/cvsup.quake > > > There is also a more conservative fix if you just take > part of the m3-tools/m3-tools/cvsup/quake/cvsup.quake change. > Just adding SOLgnu and SOLsun to the list of platforms to check. > > > - Jay > > > > > From: jay.krell at cornell.edu > To: wagner at elegosoft.com > Subject: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: > release engineering: build release_CM3_5_8_RC5 now? > Date: Wed, 14 Apr 2010 11:55:46 +0000 > > > > I commited a simple untested fix for the tar -z problem. > Need a bit longer on cvsup/zlib. > > - Jay > > > > > From: jay.krell at cornell.edu > To: wagner at elegosoft.com > Subject: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: > release engineering: build release_CM3_5_8_RC5 now? > Date: Wed, 14 Apr 2010 11:47:47 +0000 > > > > Arg. First is something to do with libz. I thought I actually built > cvsup at least once on Solaris. > Granted, I've definitely noticed that machine is slow, been > testing Posix stuff lately, but Darwin/amd64 and Linux/x86.. > > We can either use /usr/sfw/bin/gtar if it exists (it does, Sun puts > it there), or use tar followed by gzip (optionally with a pipe). > tar + gzip is presumably more portable. > > - Jay > >> Date: Wed, 14 Apr 2010 13:17:55 +0200 >> From: wagner at elegosoft.com >> To: jay.krell at cornell.edu >> Subject: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: >> release engineering: build release_CM3_5_8_RC5 now? >> >> Quoting Olaf Wagner : >> >> > The build has finished, but most of the SOLgnu archives seem to be broken: >> > >> > >> http://hudson.modula3.com:8080/view/test-install/job/cm3-test-install-SOLgnu/7/testReport/ >> > >> > Any ideas why the .M3SHIP files are missing just on this target? >> >> The log shows that package building just stopped after this failure >> in cvsup: >> >> === package m3-tools/cvsup/suplib === >> +++ cm3 -build >> -DROOT='/home/hudson/workspace/cm3-makedist-SOLgnu/cm3' >> -DCM3_VERSION_TEXT='5.8.5' -DCM3_VERSION_NUMBER='050805' >> -DCM3_LAST_CHANGED='2010-04-11' $RARGS && cm3 -ship $RARGS >> -DROOT='/home/hudson/workspace/cm3-makedist-SOLgnu/cm3' >> -DCM3_VERSION_TEXT='5.8.5' -DCM3_VERSION_NUMBER='050805' >> -DCM3_LAST_CHANGED='2010-04-11' +++ >> Undefined first referenced >> symbol in file >> inflate GzipRd.mo >> deflateEnd GzipWr.mo >> inflateEnd GzipRd.mo >> deflate GzipWr.mo >> deflateInit_ Ugzip.mo >> inflateInit_ Ugzip.mo >> ld: fatal: Symbol referencing errors. No output written to libsuplib.so.5 >> collect2: ld returned 1 exit status >> make_lib => 1 >> librarian failed building: suplib >> >> And the .deb package is broken because the Sun tar does not understand >> the -z option you seem to use... >> >> 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 hosking at cs.purdue.edu Wed Apr 14 16:22:22 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 14 Apr 2010 10:22:22 -0400 Subject: [M3devel] hidden interface vs. public Interface? hidden isn't hidden? In-Reply-To: <20100414130126.b9g9pq79escw0g8c@mail.elegosoft.com> References: <20100414130126.b9g9pq79escw0g8c@mail.elegosoft.com> Message-ID: <8D709810-3ED8-4911-8D72-1E27564C8E60@cs.purdue.edu> This being hidden *source* files are not shipped. I'm pretty sure that is still the behaviour. Jay, is it possible that you had a source file left behind from previous install? On 14 Apr 2010, at 07:01, Olaf Wagner wrote: > Quoting Jay K : > >> >> I tried changing from Interface("Utime") to interface("Utime"). >> >> Now, it turns out, that is a mistake anyway, there are still uses, and they aren't going away. >> >> But even so, this change doesn't do what it is supposed to. >> Utime gets marked "hidden" in the .M3EXPORTS files. >> I haven't yet decipered the .m3x file. >> I'm still able to build clients e.g. m3-games/tetris. >> I'm certain I'm using the updated one. I even rm -rf /cm3/pkg/m3core. >> >> It seems "hidden" doesn't work? >> >> I'll have to dig into the .m3x file I think. > > I remember that in the SRC system, hidden files weren't shipped at all > to the global package pool. Critical Mass changed that, because hey > wanted the source to be available for browsing. > > I always assumed that the compiler was able to hnour the hidden state > of the interface nonetheless. > > If it doesn't work, we should fix 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 jay.krell at cornell.edu Wed Apr 14 18:17:53 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 14 Apr 2010 16:17:53 +0000 Subject: [M3devel] hidden interface vs. public Interface? hidden isn't hidden? In-Reply-To: <8D709810-3ED8-4911-8D72-1E27564C8E60@cs.purdue.edu> References: <20100414130126.b9g9pq79escw0g8c@mail.elegosoft.com>, <8D709810-3ED8-4911-8D72-1E27564C8E60@cs.purdue.edu> Message-ID: > Jay, is it possible that you had a source file left behind from previous install? Unlikely. I thought I did rm -rf /cm3/pkg/m3core. I'm testing it again. Just to experiment, I changed all "Interface" to "interface" in m3core/src/unix/Common. It still ships 19 .i3 files to /cm3/pkg/m3core/src/unix/Common. Though I don't think that's a problem. Frontend doesn't reparse imported .i3 files, right? The information is all in .m3x? Not a big concern for me right now though. - Jay > From: hosking at cs.purdue.edu > Date: Wed, 14 Apr 2010 10:22:22 -0400 > To: wagner at elegosoft.com > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] hidden interface vs. public Interface? hidden isn't hidden? > > This being hidden *source* files are not shipped. > I'm pretty sure that is still the behaviour. > Jay, is it possible that you had a source file left behind from previous install? > > On 14 Apr 2010, at 07:01, Olaf Wagner wrote: > > > Quoting Jay K : > > > >> > >> I tried changing from Interface("Utime") to interface("Utime"). > >> > >> Now, it turns out, that is a mistake anyway, there are still uses, and they aren't going away. > >> > >> But even so, this change doesn't do what it is supposed to. > >> Utime gets marked "hidden" in the .M3EXPORTS files. > >> I haven't yet decipered the .m3x file. > >> I'm still able to build clients e.g. m3-games/tetris. > >> I'm certain I'm using the updated one. I even rm -rf /cm3/pkg/m3core. > >> > >> It seems "hidden" doesn't work? > >> > >> I'll have to dig into the .m3x file I think. > > > > I remember that in the SRC system, hidden files weren't shipped at all > > to the global package pool. Critical Mass changed that, because hey > > wanted the source to be available for browsing. > > > > I always assumed that the compiler was able to hnour the hidden state > > of the interface nonetheless. > > > > If it doesn't work, we should fix 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 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Apr 14 18:19:32 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 14 Apr 2010 16:19:32 +0000 Subject: [M3devel] more release build problems, was: RE: release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? In-Reply-To: <20100414161043.xqhxn8nr40cockko@mail.elegosoft.com> References: <20100411171933.szof1k9n2ss48sg8@mail.elegosoft.com>, , , , <20100412131311.5ax5opbuskcw00sk@mail.elegosoft.com>, , , , , , , , , , <20100412170548.o3go4tu8ys4wgwo4@mail.elegosoft.com>, , , , , , , , , <20100413171231.bvpqvjz0g0s08k4o@mail.elegosoft.com>, <20100413205035.s01zgk7nk4gggkso@mail.elegosoft.com>, <20100413224251.m5n8tfabk004gc40@mail.elegosoft.com>, , <20100414130624.ej61zwd0dcg0w848@mail.elegosoft.com>, <20100414131755.y55odckn404ws80c@mail.elegosoft.com>, , <20100414161043.xqhxn8nr40cockko@mail.elegosoft.com> Message-ID: > "HasTrestle" My fault. - Jay > Date: Wed, 14 Apr 2010 16:10:43 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: more release build problems, was: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? > > Quoting Jay K : > > > Olaf, something I don't understand is why the distribution building > > is a separate Hudson task. > > > > Or more specifically, why these don't just run "all the time", > > either once a day, or after checkins, or something like that. > > Because it is a considerable load and we build a fixed (frozen) > configuration with it. > > Once this release is out, we may try to build packages once a day, > as tinderbox did/does. > > > Perhaps this stuff was occuring but I wasn't noticing the failures? > > I do look sometimes but not enough. > > We just haven't looked. Breakage can be seen at > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLgnu/ > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLgnu/lastBuild/testReport/ > > m3core installation fails, too: > > "/home/hudson/workspace/cm3-test-all-pkgs-SOLgnu/cm3/m3-libs/m3core/SOLgnu/.M3SHIP", line 4: quake runtime error: unable to copy "libm3core.so.5" to "/home/hudson/work/cm3-inst/ssol/last-ok/lib/libm3core.so.5": > errno=2 > libm3core.so.5 Fatal Error: package build failed > > I'll try to improve the checks for serious failures before the next release. > > Olaf > > > > - Jay > > > > > > > > From: jay.krell at cornell.edu > > To: wagner at elegosoft.com > > Subject: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: > > release engineering: build release_CM3_5_8_RC5 now? > > Date: Wed, 14 Apr 2010 12:55:23 +0000 > > > > > > > > For cvsup/zlib: > > The libz hack for Solaris wasn't in release. > > I noticed and fixed another minor problem. > > > > > > Try these files: > > > > > > scripts/branch.quake > > m3-tools/cvsup/quake/cvsup.quake > > > > > > There is also a more conservative fix if you just take > > part of the m3-tools/m3-tools/cvsup/quake/cvsup.quake change. > > Just adding SOLgnu and SOLsun to the list of platforms to check. > > > > > > - Jay > > > > > > > > > > From: jay.krell at cornell.edu > > To: wagner at elegosoft.com > > Subject: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: > > release engineering: build release_CM3_5_8_RC5 now? > > Date: Wed, 14 Apr 2010 11:55:46 +0000 > > > > > > > > I commited a simple untested fix for the tar -z problem. > > Need a bit longer on cvsup/zlib. > > > > - Jay > > > > > > > > > > From: jay.krell at cornell.edu > > To: wagner at elegosoft.com > > Subject: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: > > release engineering: build release_CM3_5_8_RC5 now? > > Date: Wed, 14 Apr 2010 11:47:47 +0000 > > > > > > > > Arg. First is something to do with libz. I thought I actually built > > cvsup at least once on Solaris. > > Granted, I've definitely noticed that machine is slow, been > > testing Posix stuff lately, but Darwin/amd64 and Linux/x86.. > > > > We can either use /usr/sfw/bin/gtar if it exists (it does, Sun puts > > it there), or use tar followed by gzip (optionally with a pipe). > > tar + gzip is presumably more portable. > > > > - Jay > > > >> Date: Wed, 14 Apr 2010 13:17:55 +0200 > >> From: wagner at elegosoft.com > >> To: jay.krell at cornell.edu > >> Subject: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: > >> release engineering: build release_CM3_5_8_RC5 now? > >> > >> Quoting Olaf Wagner : > >> > >> > The build has finished, but most of the SOLgnu archives seem to be broken: > >> > > >> > > >> http://hudson.modula3.com:8080/view/test-install/job/cm3-test-install-SOLgnu/7/testReport/ > >> > > >> > Any ideas why the .M3SHIP files are missing just on this target? > >> > >> The log shows that package building just stopped after this failure > >> in cvsup: > >> > >> === package m3-tools/cvsup/suplib === > >> +++ cm3 -build > >> -DROOT='/home/hudson/workspace/cm3-makedist-SOLgnu/cm3' > >> -DCM3_VERSION_TEXT='5.8.5' -DCM3_VERSION_NUMBER='050805' > >> -DCM3_LAST_CHANGED='2010-04-11' $RARGS && cm3 -ship $RARGS > >> -DROOT='/home/hudson/workspace/cm3-makedist-SOLgnu/cm3' > >> -DCM3_VERSION_TEXT='5.8.5' -DCM3_VERSION_NUMBER='050805' > >> -DCM3_LAST_CHANGED='2010-04-11' +++ > >> Undefined first referenced > >> symbol in file > >> inflate GzipRd.mo > >> deflateEnd GzipWr.mo > >> inflateEnd GzipRd.mo > >> deflate GzipWr.mo > >> deflateInit_ Ugzip.mo > >> inflateInit_ Ugzip.mo > >> ld: fatal: Symbol referencing errors. No output written to libsuplib.so.5 > >> collect2: ld returned 1 exit status > >> make_lib => 1 > >> librarian failed building: suplib > >> > >> And the .deb package is broken because the Sun tar does not understand > >> the -z option you seem to use... > >> > >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Apr 14 18:20:39 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 14 Apr 2010 16:20:39 +0000 Subject: [M3devel] more release build problems, was: RE: release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? In-Reply-To: <20100414161043.xqhxn8nr40cockko@mail.elegosoft.com> References: <20100411171933.szof1k9n2ss48sg8@mail.elegosoft.com>, , , , <20100412131311.5ax5opbuskcw00sk@mail.elegosoft.com>, , , , , , , , , , <20100412170548.o3go4tu8ys4wgwo4@mail.elegosoft.com>, , , , , , , , , <20100413171231.bvpqvjz0g0s08k4o@mail.elegosoft.com>, <20100413205035.s01zgk7nk4gggkso@mail.elegosoft.com>, <20100413224251.m5n8tfabk004gc40@mail.elegosoft.com>, , <20100414130624.ej61zwd0dcg0w848@mail.elegosoft.com>, <20100414131755.y55odckn404ws80c@mail.elegosoft.com>, , <20100414161043.xqhxn8nr40cockko@mail.elegosoft.com> Message-ID: er. wait, that function is in release though. - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com CC: m3devel at elegosoft.com Subject: RE: more release build problems, was: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? Date: Wed, 14 Apr 2010 16:19:32 +0000 > "HasTrestle" My fault. - Jay > Date: Wed, 14 Apr 2010 16:10:43 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: more release build problems, was: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? > > Quoting Jay K : > > > Olaf, something I don't understand is why the distribution building > > is a separate Hudson task. > > > > Or more specifically, why these don't just run "all the time", > > either once a day, or after checkins, or something like that. > > Because it is a considerable load and we build a fixed (frozen) > configuration with it. > > Once this release is out, we may try to build packages once a day, > as tinderbox did/does. > > > Perhaps this stuff was occuring but I wasn't noticing the failures? > > I do look sometimes but not enough. > > We just haven't looked. Breakage can be seen at > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLgnu/ > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLgnu/lastBuild/testReport/ > > m3core installation fails, too: > > "/home/hudson/workspace/cm3-test-all-pkgs-SOLgnu/cm3/m3-libs/m3core/SOLgnu/.M3SHIP", line 4: quake runtime error: unable to copy "libm3core.so.5" to "/home/hudson/work/cm3-inst/ssol/last-ok/lib/libm3core.so.5": > errno=2 > libm3core.so.5 Fatal Error: package build failed > > I'll try to improve the checks for serious failures before the next release. > > Olaf > > > > - Jay > > > > > > > > From: jay.krell at cornell.edu > > To: wagner at elegosoft.com > > Subject: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: > > release engineering: build release_CM3_5_8_RC5 now? > > Date: Wed, 14 Apr 2010 12:55:23 +0000 > > > > > > > > For cvsup/zlib: > > The libz hack for Solaris wasn't in release. > > I noticed and fixed another minor problem. > > > > > > Try these files: > > > > > > scripts/branch.quake > > m3-tools/cvsup/quake/cvsup.quake > > > > > > There is also a more conservative fix if you just take > > part of the m3-tools/m3-tools/cvsup/quake/cvsup.quake change. > > Just adding SOLgnu and SOLsun to the list of platforms to check. > > > > > > - Jay > > > > > > > > > > From: jay.krell at cornell.edu > > To: wagner at elegosoft.com > > Subject: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: > > release engineering: build release_CM3_5_8_RC5 now? > > Date: Wed, 14 Apr 2010 11:55:46 +0000 > > > > > > > > I commited a simple untested fix for the tar -z problem. > > Need a bit longer on cvsup/zlib. > > > > - Jay > > > > > > > > > > From: jay.krell at cornell.edu > > To: wagner at elegosoft.com > > Subject: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: > > release engineering: build release_CM3_5_8_RC5 now? > > Date: Wed, 14 Apr 2010 11:47:47 +0000 > > > > > > > > Arg. First is something to do with libz. I thought I actually built > > cvsup at least once on Solaris. > > Granted, I've definitely noticed that machine is slow, been > > testing Posix stuff lately, but Darwin/amd64 and Linux/x86.. > > > > We can either use /usr/sfw/bin/gtar if it exists (it does, Sun puts > > it there), or use tar followed by gzip (optionally with a pipe). > > tar + gzip is presumably more portable. > > > > - Jay > > > >> Date: Wed, 14 Apr 2010 13:17:55 +0200 > >> From: wagner at elegosoft.com > >> To: jay.krell at cornell.edu > >> Subject: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: > >> release engineering: build release_CM3_5_8_RC5 now? > >> > >> Quoting Olaf Wagner : > >> > >> > The build has finished, but most of the SOLgnu archives seem to be broken: > >> > > >> > > >> http://hudson.modula3.com:8080/view/test-install/job/cm3-test-install-SOLgnu/7/testReport/ > >> > > >> > Any ideas why the .M3SHIP files are missing just on this target? > >> > >> The log shows that package building just stopped after this failure > >> in cvsup: > >> > >> === package m3-tools/cvsup/suplib === > >> +++ cm3 -build > >> -DROOT='/home/hudson/workspace/cm3-makedist-SOLgnu/cm3' > >> -DCM3_VERSION_TEXT='5.8.5' -DCM3_VERSION_NUMBER='050805' > >> -DCM3_LAST_CHANGED='2010-04-11' $RARGS && cm3 -ship $RARGS > >> -DROOT='/home/hudson/workspace/cm3-makedist-SOLgnu/cm3' > >> -DCM3_VERSION_TEXT='5.8.5' -DCM3_VERSION_NUMBER='050805' > >> -DCM3_LAST_CHANGED='2010-04-11' +++ > >> Undefined first referenced > >> symbol in file > >> inflate GzipRd.mo > >> deflateEnd GzipWr.mo > >> inflateEnd GzipRd.mo > >> deflate GzipWr.mo > >> deflateInit_ Ugzip.mo > >> inflateInit_ Ugzip.mo > >> ld: fatal: Symbol referencing errors. No output written to libsuplib.so.5 > >> collect2: ld returned 1 exit status > >> make_lib => 1 > >> librarian failed building: suplib > >> > >> And the .deb package is broken because the Sun tar does not understand > >> the -z option you seem to use... > >> > >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Apr 14 18:28:48 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 14 Apr 2010 16:28:48 +0000 Subject: [M3devel] more release build problems, was: RE: release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? In-Reply-To: <20100414161043.xqhxn8nr40cockko@mail.elegosoft.com> References: <20100411171933.szof1k9n2ss48sg8@mail.elegosoft.com>, , , , <20100412131311.5ax5opbuskcw00sk@mail.elegosoft.com>, , , , , , , , , , <20100412170548.o3go4tu8ys4wgwo4@mail.elegosoft.com>, , , , , , , , , <20100413171231.bvpqvjz0g0s08k4o@mail.elegosoft.com>, <20100413205035.s01zgk7nk4gggkso@mail.elegosoft.com>, <20100413224251.m5n8tfabk004gc40@mail.elegosoft.com>, , <20100414130624.ej61zwd0dcg0w848@mail.elegosoft.com>, <20100414131755.y55odckn404ws80c@mail.elegosoft.com>, , <20100414161043.xqhxn8nr40cockko@mail.elegosoft.com> Message-ID: This will help but more looking ineeded. C:\dev2\cm3.release_branch_cm3_5_8\m3-obliq>cvs -z3 commit -m "acceptable hack for release branch, don't put in head" obliqbinanim/src/m3makefile obliqbinui/src/m3makefile /usr/cvs/cm3/m3-obliq/obliqbinanim/src/m3makefile,v <-- obliqbinanim/src/m3makefile new revision: 1.1.1.1.8.2; previous revision: 1.1.1.1.8.1 /usr/cvs/cm3/m3-obliq/obliqbinui/src/m3makefile,v <-- obliqbinui/src/m3makefile new revision: 1.1.1.1.8.2; previous revision: 1.1.1.1.8.1 - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com CC: m3devel at elegosoft.com Subject: RE: more release build problems, was: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? Date: Wed, 14 Apr 2010 16:20:39 +0000 er. wait, that function is in release though. - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com CC: m3devel at elegosoft.com Subject: RE: more release build problems, was: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? Date: Wed, 14 Apr 2010 16:19:32 +0000 > "HasTrestle" My fault. - Jay > Date: Wed, 14 Apr 2010 16:10:43 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: more release build problems, was: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? > > Quoting Jay K : > > > Olaf, something I don't understand is why the distribution building > > is a separate Hudson task. > > > > Or more specifically, why these don't just run "all the time", > > either once a day, or after checkins, or something like that. > > Because it is a considerable load and we build a fixed (frozen) > configuration with it. > > Once this release is out, we may try to build packages once a day, > as tinderbox did/does. > > > Perhaps this stuff was occuring but I wasn't noticing the failures? > > I do look sometimes but not enough. > > We just haven't looked. Breakage can be seen at > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLgnu/ > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLgnu/lastBuild/testReport/ > > m3core installation fails, too: > > "/home/hudson/workspace/cm3-test-all-pkgs-SOLgnu/cm3/m3-libs/m3core/SOLgnu/.M3SHIP", line 4: quake runtime error: unable to copy "libm3core.so.5" to "/home/hudson/work/cm3-inst/ssol/last-ok/lib/libm3core.so.5": > errno=2 > libm3core.so.5 Fatal Error: package build failed > > I'll try to improve the checks for serious failures before the next release. > > Olaf > > > > - Jay > > > > > > > > From: jay.krell at cornell.edu > > To: wagner at elegosoft.com > > Subject: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: > > release engineering: build release_CM3_5_8_RC5 now? > > Date: Wed, 14 Apr 2010 12:55:23 +0000 > > > > > > > > For cvsup/zlib: > > The libz hack for Solaris wasn't in release. > > I noticed and fixed another minor problem. > > > > > > Try these files: > > > > > > scripts/branch.quake > > m3-tools/cvsup/quake/cvsup.quake > > > > > > There is also a more conservative fix if you just take > > part of the m3-tools/m3-tools/cvsup/quake/cvsup.quake change. > > Just adding SOLgnu and SOLsun to the list of platforms to check. > > > > > > - Jay > > > > > > > > > > From: jay.krell at cornell.edu > > To: wagner at elegosoft.com > > Subject: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: > > release engineering: build release_CM3_5_8_RC5 now? > > Date: Wed, 14 Apr 2010 11:55:46 +0000 > > > > > > > > I commited a simple untested fix for the tar -z problem. > > Need a bit longer on cvsup/zlib. > > > > - Jay > > > > > > > > > > From: jay.krell at cornell.edu > > To: wagner at elegosoft.com > > Subject: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: > > release engineering: build release_CM3_5_8_RC5 now? > > Date: Wed, 14 Apr 2010 11:47:47 +0000 > > > > > > > > Arg. First is something to do with libz. I thought I actually built > > cvsup at least once on Solaris. > > Granted, I've definitely noticed that machine is slow, been > > testing Posix stuff lately, but Darwin/amd64 and Linux/x86.. > > > > We can either use /usr/sfw/bin/gtar if it exists (it does, Sun puts > > it there), or use tar followed by gzip (optionally with a pipe). > > tar + gzip is presumably more portable. > > > > - Jay > > > >> Date: Wed, 14 Apr 2010 13:17:55 +0200 > >> From: wagner at elegosoft.com > >> To: jay.krell at cornell.edu > >> Subject: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: > >> release engineering: build release_CM3_5_8_RC5 now? > >> > >> Quoting Olaf Wagner : > >> > >> > The build has finished, but most of the SOLgnu archives seem to be broken: > >> > > >> > > >> http://hudson.modula3.com:8080/view/test-install/job/cm3-test-install-SOLgnu/7/testReport/ > >> > > >> > Any ideas why the .M3SHIP files are missing just on this target? > >> > >> The log shows that package building just stopped after this failure > >> in cvsup: > >> > >> === package m3-tools/cvsup/suplib === > >> +++ cm3 -build > >> -DROOT='/home/hudson/workspace/cm3-makedist-SOLgnu/cm3' > >> -DCM3_VERSION_TEXT='5.8.5' -DCM3_VERSION_NUMBER='050805' > >> -DCM3_LAST_CHANGED='2010-04-11' $RARGS && cm3 -ship $RARGS > >> -DROOT='/home/hudson/workspace/cm3-makedist-SOLgnu/cm3' > >> -DCM3_VERSION_TEXT='5.8.5' -DCM3_VERSION_NUMBER='050805' > >> -DCM3_LAST_CHANGED='2010-04-11' +++ > >> Undefined first referenced > >> symbol in file > >> inflate GzipRd.mo > >> deflateEnd GzipWr.mo > >> inflateEnd GzipRd.mo > >> deflate GzipWr.mo > >> deflateInit_ Ugzip.mo > >> inflateInit_ Ugzip.mo > >> ld: fatal: Symbol referencing errors. No output written to libsuplib.so.5 > >> collect2: ld returned 1 exit status > >> make_lib => 1 > >> librarian failed building: suplib > >> > >> And the .deb package is broken because the Sun tar does not understand > >> the -z option you seem to use... > >> > >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Wed Apr 14 18:40:02 2010 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Wed, 14 Apr 2010 16:40:02 +0000 (GMT) Subject: [M3devel] hidden interface vs. public Interface? hidden isn't hidden? In-Reply-To: <8D709810-3ED8-4911-8D72-1E27564C8E60@cs.purdue.edu> Message-ID: <962394.19120.qm@web23606.mail.ird.yahoo.com> Hi all: there is a quake directive to export or hide interfaces to packages in cm3 this is from the DEC SRC packages and later pm3, heck the information is the same in all: http://modula3.com/cm3/doc/help/cm3/m3build/hiding.html http://cs.wheaton.edu/~cgray/misc/m3/pm3pkg/m3build/src/html/hiding.html http://www.cs.arizona.edu/~collberg/Research/Modula-3/modula-3/html/m3build/hiding.html Please note they mention they accept capitalization convention in commands initial letter but partly to support old style m3makefiles so they provide that to clarify better I think you can try with export_interface("Utime") and to check capitalization convention with /* interface("Utime")*/ Interface("Utime") export_interface("Utime") I remember there are some issues tough if the Unix file has owner only read permissions because the file will be exported as it is so other users included m3browser won't be able to read the file (for instance if you exported as root user and reading from the web in m3browser), same sort of things happens in NT386. Though in the above links mention they had this convention of uppercase first 'i' of Interface("Utime") I know related examples of this kind of missing of meaning, as as source directory called 'SRC' is not accepted (i.e it doesn't find source directory) in Unix platforms but it was accepted in NT386 (in DEC SRC M3, i.e it builds) perhaps because of capital letter symbols (in)discrimination in terminal platforms I guess (I'm aware unix make looks for Makefile and if not for makefile). Now I don't know what was is the case in M3/PC Klagenfurt (but as I see the the m3makefiles they had in M3PC 1994 release are C preprocessor directives with special function names a kind of similar to quake and mostly beginning in capital letters) port because it was a DOS platform and they wrote a shell into which can build programs (they didn't have m3make DEC SRC program which because it worked with unix make), I know the long names are ignored in DOS terminals (they substitute the last part with a ~) but they sort of fixed this behavior in the builder/shell they wrote using a name map see: http://web.archive.org/web/20000520073936/www.ifi.uni-klu.ac.at/Modula-3/m3pc/m3pc.html Thanks, I hope it helps --- El mi?, 14/4/10, Tony Hosking escribi?: > De: Tony Hosking > Asunto: Re: [M3devel] hidden interface vs. public Interface? hidden isn't hidden? > Para: "Olaf Wagner" > CC: m3devel at elegosoft.com > Fecha: mi?rcoles, 14 de abril, 2010 09:22 > This being hidden *source* files are > not shipped. > I'm pretty sure that is still the behaviour. > Jay, is it possible that you had a source file left behind > from previous install? > > On 14 Apr 2010, at 07:01, Olaf Wagner wrote: > > > Quoting Jay K : > > > >> > >> I tried changing from Interface("Utime") to > interface("Utime"). > >> > >> Now, it turns out, that is a mistake > anyway, there are still uses, and they aren't going > away. > >> > >> But even so, this change doesn't do what it is > supposed to. > >> Utime gets marked "hidden" in the .M3EXPORTS > files. > >> I haven't yet decipered the .m3x file. > >> I'm still able to build clients e.g. > m3-games/tetris. > >> I'm certain I'm using the updated one. I even rm > -rf /cm3/pkg/m3core. > >> > >> It seems "hidden" doesn't work? > >> > >> I'll have to dig into the .m3x file I think. > > > > I remember that in the SRC system, hidden files > weren't shipped at all > > to the global package pool. Critical Mass changed > that, because hey > > wanted the source to be available for browsing. > > > > I always assumed that the compiler was able to hnour > the hidden state > > of the interface nonetheless. > > > > If it doesn't work, we should fix 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 jay.krell at cornell.edu Wed Apr 14 18:48:04 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 14 Apr 2010 16:48:04 +0000 Subject: [M3devel] more release build problems, was: RE: release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? In-Reply-To: References: <20100411171933.szof1k9n2ss48sg8@mail.elegosoft.com>, , , ,,<20100412131311.5ax5opbuskcw00sk@mail.elegosoft.com>, , , ,,, , , , , ,,<20100412170548.o3go4tu8ys4wgwo4@mail.elegosoft.com>, , , ,,, , , , , , , , , <20100413171231.bvpqvjz0g0s08k4o@mail.elegosoft.com>, , <20100413205035.s01zgk7nk4gggkso@mail.elegosoft.com>, , <20100413224251.m5n8tfabk004gc40@mail.elegosoft.com>, , , , <20100414130624.ej61zwd0dcg0w848@mail.elegosoft.com>, , <20100414131755.y55odckn404ws80c@mail.elegosoft.com>, , , , <20100414161043.xqhxn8nr40cockko@mail.elegosoft.com>, Message-ID: postgres95/test and odbc/test I added filtering to match the package, should help. That's still not everything. The m3core error is odd. The cvsup one about merger.tmpl also. - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com Date: Wed, 14 Apr 2010 16:28:48 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] more release build problems, was: RE: release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? This will help but more looking ineeded. C:\dev2\cm3.release_branch_cm3_5_8\m3-obliq>cvs -z3 commit -m "acceptable hack for release branch, don't put in head" obliqbinanim/src/m3makefile obliqbinui/src/m3makefile /usr/cvs/cm3/m3-obliq/obliqbinanim/src/m3makefile,v <-- obliqbinanim/src/m3makefile new revision: 1.1.1.1.8.2; previous revision: 1.1.1.1.8.1 /usr/cvs/cm3/m3-obliq/obliqbinui/src/m3makefile,v <-- obliqbinui/src/m3makefile new revision: 1.1.1.1.8.2; previous revision: 1.1.1.1.8.1 - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com CC: m3devel at elegosoft.com Subject: RE: more release build problems, was: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? Date: Wed, 14 Apr 2010 16:20:39 +0000 er. wait, that function is in release though. - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com CC: m3devel at elegosoft.com Subject: RE: more release build problems, was: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? Date: Wed, 14 Apr 2010 16:19:32 +0000 > "HasTrestle" My fault. - Jay > Date: Wed, 14 Apr 2010 16:10:43 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: more release build problems, was: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? > > Quoting Jay K : > > > Olaf, something I don't understand is why the distribution building > > is a separate Hudson task. > > > > Or more specifically, why these don't just run "all the time", > > either once a day, or after checkins, or something like that. > > Because it is a considerable load and we build a fixed (frozen) > configuration with it. > > Once this release is out, we may try to build packages once a day, > as tinderbox did/does. > > > Perhaps this stuff was occuring but I wasn't noticing the failures? > > I do look sometimes but not enough. > > We just haven't looked. Breakage can be seen at > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLgnu/ > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLgnu/lastBuild/testReport/ > > m3core installation fails, too: > > "/home/hudson/workspace/cm3-test-all-pkgs-SOLgnu/cm3/m3-libs/m3core/SOLgnu/.M3SHIP", line 4: quake runtime error: unable to copy "libm3core.so.5" to "/home/hudson/work/cm3-inst/ssol/last-ok/lib/libm3core.so.5": > errno=2 > libm3core.so.5 Fatal Error: package build failed > > I'll try to improve the checks for serious failures before the next release. > > Olaf > > > > - Jay > > > > > > > > From: jay.krell at cornell.edu > > To: wagner at elegosoft.com > > Subject: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: > > release engineering: build release_CM3_5_8_RC5 now? > > Date: Wed, 14 Apr 2010 12:55:23 +0000 > > > > > > > > For cvsup/zlib: > > The libz hack for Solaris wasn't in release. > > I noticed and fixed another minor problem. > > > > > > Try these files: > > > > > > scripts/branch.quake > > m3-tools/cvsup/quake/cvsup.quake > > > > > > There is also a more conservative fix if you just take > > part of the m3-tools/m3-tools/cvsup/quake/cvsup.quake change. > > Just adding SOLgnu and SOLsun to the list of platforms to check. > > > > > > - Jay > > > > > > > > > > From: jay.krell at cornell.edu > > To: wagner at elegosoft.com > > Subject: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: > > release engineering: build release_CM3_5_8_RC5 now? > > Date: Wed, 14 Apr 2010 11:55:46 +0000 > > > > > > > > I commited a simple untested fix for the tar -z problem. > > Need a bit longer on cvsup/zlib. > > > > - Jay > > > > > > > > > > From: jay.krell at cornell.edu > > To: wagner at elegosoft.com > > Subject: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: > > release engineering: build release_CM3_5_8_RC5 now? > > Date: Wed, 14 Apr 2010 11:47:47 +0000 > > > > > > > > Arg. First is something to do with libz. I thought I actually built > > cvsup at least once on Solaris. > > Granted, I've definitely noticed that machine is slow, been > > testing Posix stuff lately, but Darwin/amd64 and Linux/x86.. > > > > We can either use /usr/sfw/bin/gtar if it exists (it does, Sun puts > > it there), or use tar followed by gzip (optionally with a pipe). > > tar + gzip is presumably more portable. > > > > - Jay > > > >> Date: Wed, 14 Apr 2010 13:17:55 +0200 > >> From: wagner at elegosoft.com > >> To: jay.krell at cornell.edu > >> Subject: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: > >> release engineering: build release_CM3_5_8_RC5 now? > >> > >> Quoting Olaf Wagner : > >> > >> > The build has finished, but most of the SOLgnu archives seem to be broken: > >> > > >> > > >> http://hudson.modula3.com:8080/view/test-install/job/cm3-test-install-SOLgnu/7/testReport/ > >> > > >> > Any ideas why the .M3SHIP files are missing just on this target? > >> > >> The log shows that package building just stopped after this failure > >> in cvsup: > >> > >> === package m3-tools/cvsup/suplib === > >> +++ cm3 -build > >> -DROOT='/home/hudson/workspace/cm3-makedist-SOLgnu/cm3' > >> -DCM3_VERSION_TEXT='5.8.5' -DCM3_VERSION_NUMBER='050805' > >> -DCM3_LAST_CHANGED='2010-04-11' $RARGS && cm3 -ship $RARGS > >> -DROOT='/home/hudson/workspace/cm3-makedist-SOLgnu/cm3' > >> -DCM3_VERSION_TEXT='5.8.5' -DCM3_VERSION_NUMBER='050805' > >> -DCM3_LAST_CHANGED='2010-04-11' +++ > >> Undefined first referenced > >> symbol in file > >> inflate GzipRd.mo > >> deflateEnd GzipWr.mo > >> inflateEnd GzipRd.mo > >> deflate GzipWr.mo > >> deflateInit_ Ugzip.mo > >> inflateInit_ Ugzip.mo > >> ld: fatal: Symbol referencing errors. No output written to libsuplib.so.5 > >> collect2: ld returned 1 exit status > >> make_lib => 1 > >> librarian failed building: suplib > >> > >> And the .deb package is broken because the Sun tar does not understand > >> the -z option you seem to use... > >> > >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Apr 14 18:59:15 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 14 Apr 2010 16:59:15 +0000 Subject: [M3devel] more release build problems, was: RE: release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? In-Reply-To: References: <20100411171933.szof1k9n2ss48sg8@mail.elegosoft.com>, , ,,,,<20100412131311.5ax5opbuskcw00sk@mail.elegosoft.com>, , ,,,,, , , , ,,,,<20100412170548.o3go4tu8ys4wgwo4@mail.elegosoft.com>, , ,,,,,,, , , ,,, ,,, ,,<20100413171231.bvpqvjz0g0s08k4o@mail.elegosoft.com>, ,,<20100413205035.s01zgk7nk4gggkso@mail.elegosoft.com>, ,,<20100413224251.m5n8tfabk004gc40@mail.elegosoft.com>, ,,, ,,<20100414130624.ej61zwd0dcg0w848@mail.elegosoft.com>, ,,<20100414131755.y55odckn404ws80c@mail.elegosoft.com>, ,,, , , <20100414161043.xqhxn8nr40cockko@mail.elegosoft.com>, , , Message-ID: pattern matching has some other odd problem, though this could be something in head or my machine: new source -> compiling regex.i3 "../src/regex.i3", line 20: Could not find a legal alignment for the packed type . it's just: regmatch_t = RECORD rm_so: off_t; rm_eo: off_t; END; though again, this is head and SOLsun. - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com Date: Wed, 14 Apr 2010 16:48:04 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] more release build problems, was: RE: release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? postgres95/test and odbc/test I added filtering to match the package, should help. That's still not everything. The m3core error is odd. The cvsup one about merger.tmpl also. - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com Date: Wed, 14 Apr 2010 16:28:48 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] more release build problems, was: RE: release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? This will help but more looking ineeded. C:\dev2\cm3.release_branch_cm3_5_8\m3-obliq>cvs -z3 commit -m "acceptable hack for release branch, don't put in head" obliqbinanim/src/m3makefile obliqbinui/src/m3makefile /usr/cvs/cm3/m3-obliq/obliqbinanim/src/m3makefile,v <-- obliqbinanim/src/m3makefile new revision: 1.1.1.1.8.2; previous revision: 1.1.1.1.8.1 /usr/cvs/cm3/m3-obliq/obliqbinui/src/m3makefile,v <-- obliqbinui/src/m3makefile new revision: 1.1.1.1.8.2; previous revision: 1.1.1.1.8.1 - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com CC: m3devel at elegosoft.com Subject: RE: more release build problems, was: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? Date: Wed, 14 Apr 2010 16:20:39 +0000 er. wait, that function is in release though. - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com CC: m3devel at elegosoft.com Subject: RE: more release build problems, was: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? Date: Wed, 14 Apr 2010 16:19:32 +0000 > "HasTrestle" My fault. - Jay > Date: Wed, 14 Apr 2010 16:10:43 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: more release build problems, was: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? > > Quoting Jay K : > > > Olaf, something I don't understand is why the distribution building > > is a separate Hudson task. > > > > Or more specifically, why these don't just run "all the time", > > either once a day, or after checkins, or something like that. > > Because it is a considerable load and we build a fixed (frozen) > configuration with it. > > Once this release is out, we may try to build packages once a day, > as tinderbox did/does. > > > Perhaps this stuff was occuring but I wasn't noticing the failures? > > I do look sometimes but not enough. > > We just haven't looked. Breakage can be seen at > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLgnu/ > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLgnu/lastBuild/testReport/ > > m3core installation fails, too: > > "/home/hudson/workspace/cm3-test-all-pkgs-SOLgnu/cm3/m3-libs/m3core/SOLgnu/.M3SHIP", line 4: quake runtime error: unable to copy "libm3core.so.5" to "/home/hudson/work/cm3-inst/ssol/last-ok/lib/libm3core.so.5": > errno=2 > libm3core.so.5 Fatal Error: package build failed > > I'll try to improve the checks for serious failures before the next release. > > Olaf > > > > - Jay > > > > > > > > From: jay.krell at cornell.edu > > To: wagner at elegosoft.com > > Subject: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: > > release engineering: build release_CM3_5_8_RC5 now? > > Date: Wed, 14 Apr 2010 12:55:23 +0000 > > > > > > > > For cvsup/zlib: > > The libz hack for Solaris wasn't in release. > > I noticed and fixed another minor problem. > > > > > > Try these files: > > > > > > scripts/branch.quake > > m3-tools/cvsup/quake/cvsup.quake > > > > > > There is also a more conservative fix if you just take > > part of the m3-tools/m3-tools/cvsup/quake/cvsup.quake change. > > Just adding SOLgnu and SOLsun to the list of platforms to check. > > > > > > - Jay > > > > > > > > > > From: jay.krell at cornell.edu > > To: wagner at elegosoft.com > > Subject: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: > > release engineering: build release_CM3_5_8_RC5 now? > > Date: Wed, 14 Apr 2010 11:55:46 +0000 > > > > > > > > I commited a simple untested fix for the tar -z problem. > > Need a bit longer on cvsup/zlib. > > > > - Jay > > > > > > > > > > From: jay.krell at cornell.edu > > To: wagner at elegosoft.com > > Subject: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: > > release engineering: build release_CM3_5_8_RC5 now? > > Date: Wed, 14 Apr 2010 11:47:47 +0000 > > > > > > > > Arg. First is something to do with libz. I thought I actually built > > cvsup at least once on Solaris. > > Granted, I've definitely noticed that machine is slow, been > > testing Posix stuff lately, but Darwin/amd64 and Linux/x86.. > > > > We can either use /usr/sfw/bin/gtar if it exists (it does, Sun puts > > it there), or use tar followed by gzip (optionally with a pipe). > > tar + gzip is presumably more portable. > > > > - Jay > > > >> Date: Wed, 14 Apr 2010 13:17:55 +0200 > >> From: wagner at elegosoft.com > >> To: jay.krell at cornell.edu > >> Subject: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: > >> release engineering: build release_CM3_5_8_RC5 now? > >> > >> Quoting Olaf Wagner : > >> > >> > The build has finished, but most of the SOLgnu archives seem to be broken: > >> > > >> > > >> http://hudson.modula3.com:8080/view/test-install/job/cm3-test-install-SOLgnu/7/testReport/ > >> > > >> > Any ideas why the .M3SHIP files are missing just on this target? > >> > >> The log shows that package building just stopped after this failure > >> in cvsup: > >> > >> === package m3-tools/cvsup/suplib === > >> +++ cm3 -build > >> -DROOT='/home/hudson/workspace/cm3-makedist-SOLgnu/cm3' > >> -DCM3_VERSION_TEXT='5.8.5' -DCM3_VERSION_NUMBER='050805' > >> -DCM3_LAST_CHANGED='2010-04-11' $RARGS && cm3 -ship $RARGS > >> -DROOT='/home/hudson/workspace/cm3-makedist-SOLgnu/cm3' > >> -DCM3_VERSION_TEXT='5.8.5' -DCM3_VERSION_NUMBER='050805' > >> -DCM3_LAST_CHANGED='2010-04-11' +++ > >> Undefined first referenced > >> symbol in file > >> inflate GzipRd.mo > >> deflateEnd GzipWr.mo > >> inflateEnd GzipRd.mo > >> deflate GzipWr.mo > >> deflateInit_ Ugzip.mo > >> inflateInit_ Ugzip.mo > >> ld: fatal: Symbol referencing errors. No output written to libsuplib.so.5 > >> collect2: ld returned 1 exit status > >> make_lib => 1 > >> librarian failed building: suplib > >> > >> And the .deb package is broken because the Sun tar does not understand > >> the -z option you seem to use... > >> > >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Apr 14 18:51:40 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 14 Apr 2010 16:51:40 +0000 Subject: [M3devel] hidden interface vs. public Interface? hidden isn't hidden? In-Reply-To: <962394.19120.qm@web23606.mail.ird.yahoo.com> References: <8D709810-3ED8-4911-8D72-1E27564C8E60@cs.purdue.edu>, <962394.19120.qm@web23606.mail.ird.yahoo.com> Message-ID: Daniel, "interface" and "Interface" aren't filenames. There's no issue regarding file name lengths and file system case sensitivity. I can see that "interface" results in "hidden" in the .m3exports file, at least. There are (many) parts of the system that I'm unaware how they work. Like, does importing just read the .m3x file, or not? Hopefully yes, because it is very efficiently encoded. But I don't know. - Jay > Date: Wed, 14 Apr 2010 16:40:02 +0000 > From: dabenavidesd at yahoo.es > To: wagner at elegosoft.com; hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] hidden interface vs. public Interface? hidden isn't hidden? > > Hi all: > there is a quake directive to export or hide interfaces to packages in cm3 this is from the DEC SRC packages and later pm3, heck the information is the same in all: > http://modula3.com/cm3/doc/help/cm3/m3build/hiding.html > http://cs.wheaton.edu/~cgray/misc/m3/pm3pkg/m3build/src/html/hiding.html > http://www.cs.arizona.edu/~collberg/Research/Modula-3/modula-3/html/m3build/hiding.html > > Please note they mention they accept capitalization convention in commands initial letter but partly to support old style m3makefiles so they provide that to clarify better > > I think you can try with > export_interface("Utime") > and to check capitalization convention with > /* interface("Utime")*/ > Interface("Utime") > export_interface("Utime") > > I remember there are some issues tough if the Unix file has owner only read permissions because the file will be exported as it is so other users included m3browser won't be able to read the file (for instance if you exported as root user and reading from the web in m3browser), same sort of things happens in NT386. > > Though in the above links mention they had this convention of uppercase first 'i' of Interface("Utime") > > I know related examples of this kind of missing of meaning, as as source directory called 'SRC' is not accepted (i.e it doesn't find source directory) in Unix platforms but it was accepted in NT386 (in DEC SRC M3, i.e it builds) perhaps because of capital letter symbols (in)discrimination in terminal platforms I guess (I'm aware unix make looks for Makefile and if not for makefile). > Now I don't know what was is the case in M3/PC Klagenfurt (but as I see the the m3makefiles they had in M3PC 1994 release are C preprocessor directives with special function names a kind of similar to quake and mostly beginning in capital letters) port because it was a DOS platform and they wrote a shell into which can build programs (they didn't have m3make DEC SRC program which because it worked with unix make), I know the long names are ignored in DOS terminals (they substitute the last part with a ~) but they sort of fixed this behavior in the builder/shell they wrote using a name map see: http://web.archive.org/web/20000520073936/www.ifi.uni-klu.ac.at/Modula-3/m3pc/m3pc.html > > Thanks, I hope it helps > > --- El mi?, 14/4/10, Tony Hosking escribi?: > > > De: Tony Hosking > > Asunto: Re: [M3devel] hidden interface vs. public Interface? hidden isn't hidden? > > Para: "Olaf Wagner" > > CC: m3devel at elegosoft.com > > Fecha: mi?rcoles, 14 de abril, 2010 09:22 > > This being hidden *source* files are > > not shipped. > > I'm pretty sure that is still the behaviour. > > Jay, is it possible that you had a source file left behind > > from previous install? > > > > On 14 Apr 2010, at 07:01, Olaf Wagner wrote: > > > > > Quoting Jay K : > > > > > >> > > >> I tried changing from Interface("Utime") to > > interface("Utime"). > > >> > > >> Now, it turns out, that is a mistake > > anyway, there are still uses, and they aren't going > > away. > > >> > > >> But even so, this change doesn't do what it is > > supposed to. > > >> Utime gets marked "hidden" in the .M3EXPORTS > > files. > > >> I haven't yet decipered the .m3x file. > > >> I'm still able to build clients e.g. > > m3-games/tetris. > > >> I'm certain I'm using the updated one. I even rm > > -rf /cm3/pkg/m3core. > > >> > > >> It seems "hidden" doesn't work? > > >> > > >> I'll have to dig into the .m3x file I think. > > > > > > I remember that in the SRC system, hidden files > > weren't shipped at all > > > to the global package pool. Critical Mass changed > > that, because hey > > > wanted the source to be available for browsing. > > > > > > I always assumed that the compiler was able to hnour > > the hidden state > > > of the interface nonetheless. > > > > > > If it doesn't work, we should fix 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 > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Apr 15 08:45:48 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 15 Apr 2010 06:45:48 +0000 Subject: [M3devel] Modula-3/C interop in Date/Time? Message-ID: Is this legal/correct? Date.i3: TYPE TimeZone <: REFANY; VAR Local, UTC: TimeZone; (* granted, will maybe change these to extern *) Date.m3:? REVEAL TimeZone = BRANDED "Date.TimeZone" REF INTEGER; ? DatePosixC.c: static const int Local = 0; static const int UTC = 1; extern const int const * const Date__Local = &Local; extern const int const * const Date__UTC = &UTC; ? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Apr 15 14:18:44 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 15 Apr 2010 12:18:44 +0000 Subject: [M3devel] date/time stuff In-Reply-To: References: <20100415114428.52D0D2474004@birch.elegosoft.com>, Message-ID: I still have small lingering concerns here. - when to call tzset? Historically we called at in the Posix version startup only. I believe localtime implicitcally calls tzset, so we kind of had it backwards? - foo vs. foo_r? I changed any to _r. However there are differences relative, again, to tzset. It seems to me, program can be long running, can span a timezone change. Calling tzset just at startup, not great. - So maybe a better approach is DisableScheduling/EnableScheduling Don't use the _r functions? and/or call tzset more often? - I think I should probably introduce an "idealized" "DatePosix.T" just containing INTEGERs or LONGINTs and no subranges. Besides making the layout totally clear, unlike today, that will also cause subrange checks when the Modula-3 code copies the C values out. Today there are no subrange checks. One needs to be careful defining the ranges, due to various "leap" conditions (not just days, but also seconds, etc.) - I have not run tests that span timezone changes. I think that should be done. It's not difficult actually. Just put an infinite loop around p235 and require user to press enter between iterations, meanwhile changing the system clock/timezone. I can get to that within a week. - There is some possibility here of sharing implementation with Win32! ANSI C has localtime/gmtime, of course and msvcr*.dll do expose daylight, tzname[]. Possibly we can have just one "Posix" implementation. Instead of today's three implementations. - Jay From: jay.krell at cornell.edu To: jkrell at elego.de; m3commit at elegosoft.com Date: Thu, 15 Apr 2010 11:49:09 +0000 Subject: Re: [M3commit] CVS Update: cm3 diff attached > Date: Thu, 15 Apr 2010 13:44:28 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/04/15 13:44:28 > > Modified files: > cm3/m3-libs/m3core/src/: m3core.h > cm3/m3-libs/m3core/src/time/POSIX/: DatePosix.m3 DatePosixC.c > TimePosix.i3 TimePosix.m3 > TimePosixC.c m3makefile > cm3/m3-libs/m3core/src/unix/: m3makefile > cm3/m3-libs/m3core/src/unix/Common/: Unix.i3 Utime.i3 UtimeC.c > Utypes.i3 > Added files: > cm3/m3-libs/m3core/src/time/POSIX/: DatePosix.i3 > > Log message: > eliminate struct_tm (somewhat platform specific) > eliminate struct_timeval (somewhat platform specific) > eliminate FDSet (somewhat platform specific) > eliminate MAX_FDSET (somewhat platform specific) > eliminate lots of functions from Utime > i.e. functions that use those types, like gettimeofday, localtime, gmtime > functions that were used only in m3core/src/time/*.m3 like get_timezone, altzone > > eliminate "all" the m3core/src/unix platform dependent directories *except* > Solaris/sparc32 (SOLgnu/SOLsun) for stack walking support > uin-common vs. uin-len > > change time_t to be 64bits for all platforms > but underlying implementation still needs work (elaborated below) > > tested on SOLgnu, AMD64_DARWIN, LINUXLIBC6 > It compiles and the assertions all hold. > Local and utc data appears correct, cross checking with date and date -u, including > setting Linux/x86 and Solaris/sparc32 system clocks back to Jan 1 2010. > Did not test functionaly on Darwin or any BSD (but note that Linux uses the BSD code). > > still to do: > use 64bit time_t code from http://code.google.com/p/y2038/ > combine some of lingering code in UtimeC.c into Time/DatePosixC.c, as static functions > We can actually add stuff back like localtime/gmtime trafficing in 64bit time_t, > as long as we use our own carefully controlled/copied types (i.e. omit the > extra two fields in struct tm). Just as well as we can provide gettimeofday, select. If we must. > Maybe test on Darwin, *BSD, Cygwin, Interix, etc. > Test in other timezones. > Enable a regularly run test? > Consider relayout Date.T to it doesn't have padding in the middle or perhaps anywhere. > (Hard to avoid if there are subranges, will be padded at least at end.) > > We can't achieve 64bit gettimeofday or file timestamps beyond year 2038 > but if you fill in a Date.T with year > 2038, that can be useful and be made > to work. It should roundtrip with Time.T and be printable. > > structure is a little odd > DatePosix.i3, TimePosix.i3 describe C code > DatePosix.m3, TimePosix.m3 expose Date, Time, call into DatePosix, TimePosix > This is just to reuse existing names or name patterns. > We could just as well introduce new interfaes TimeC, DateC, TimeInternal, DateTimeInternal, etc. > > Note: This also fixes the UTC timezone on Solaris, Interix, HP-UX, Cygwin, which appear to have been historically broken. > > Note: This also uncovered that my Solaris clock was behind by a few minutes. > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 1.txt URL: From jay.krell at cornell.edu Thu Apr 15 15:48:04 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 15 Apr 2010 13:48:04 +0000 Subject: [M3devel] date/time stuff In-Reply-To: References: <20100415114428.52D0D2474004@birch.elegosoft.com>, Message-ID: I forgot to mention another old bug I noticed here: they never check the return value of localtime/localtime_r/gmtime/gmtime_r. It is NULL for error. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Subject: RE: date/time stuff Date: Thu, 15 Apr 2010 13:47:03 +0000 Something went very wrong in the history here. Long ago. Not today. I think we never got the 5.1 changes out of a branch, or something. In version 1.2 I accidentally did copy them out of the branch somehow, and then in 1.3 I put it back, since I wasn't intending to do that. I don't know how I would have gotten that content. Maybe I scrolled down in the cvsweb and selected what I thought was previous, as part of editing/reverting my work. At the time now way I would have used cvs upd -r. I didn't learn till much later. See http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/time/POSIX/DatePosix.m3.diff?r1=1.1;r2=1.3 1.1 and 1.3 are identical. 1.1 to 1.4 http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/time/POSIX/DatePosix.m3.diff?r1=1.1;r2=1.4 is the change I was after. That leaves me uncertain which historical behavior to aim for. :( Need to write more tests.. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Subject: date/time stuff Date: Thu, 15 Apr 2010 12:18:44 +0000 I still have small lingering concerns here. - when to call tzset? Historically we called at in the Posix version startup only. I believe localtime implicitcally calls tzset, so we kind of had it backwards? - foo vs. foo_r? I changed any to _r. However there are differences relative, again, to tzset. It seems to me, program can be long running, can span a timezone change. Calling tzset just at startup, not great. - So maybe a better approach is DisableScheduling/EnableScheduling Don't use the _r functions? and/or call tzset more often? - I think I should probably introduce an "idealized" "DatePosix.T" just containing INTEGERs or LONGINTs and no subranges. Besides making the layout totally clear, unlike today, that will also cause subrange checks when the Modula-3 code copies the C values out. Today there are no subrange checks. One needs to be careful defining the ranges, due to various "leap" conditions (not just days, but also seconds, etc.) - I have not run tests that span timezone changes. I think that should be done. It's not difficult actually. Just put an infinite loop around p235 and require user to press enter between iterations, meanwhile changing the system clock/timezone. I can get to that within a week. - There is some possibility here of sharing implementation with Win32! ANSI C has localtime/gmtime, of course and msvcr*.dll do expose daylight, tzname[]. Possibly we can have just one "Posix" implementation. Instead of today's three implementations. - Jay From: jay.krell at cornell.edu To: jkrell at elego.de; m3commit at elegosoft.com Date: Thu, 15 Apr 2010 11:49:09 +0000 Subject: Re: [M3commit] CVS Update: cm3 diff attached > Date: Thu, 15 Apr 2010 13:44:28 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/04/15 13:44:28 > > Modified files: > cm3/m3-libs/m3core/src/: m3core.h > cm3/m3-libs/m3core/src/time/POSIX/: DatePosix.m3 DatePosixC.c > TimePosix.i3 TimePosix.m3 > TimePosixC.c m3makefile > cm3/m3-libs/m3core/src/unix/: m3makefile > cm3/m3-libs/m3core/src/unix/Common/: Unix.i3 Utime.i3 UtimeC.c > Utypes.i3 > Added files: > cm3/m3-libs/m3core/src/time/POSIX/: DatePosix.i3 > > Log message: > eliminate struct_tm (somewhat platform specific) > eliminate struct_timeval (somewhat platform specific) > eliminate FDSet (somewhat platform specific) > eliminate MAX_FDSET (somewhat platform specific) > eliminate lots of functions from Utime > i.e. functions that use those types, like gettimeofday, localtime, gmtime > functions that were used only in m3core/src/time/*.m3 like get_timezone, altzone > > eliminate "all" the m3core/src/unix platform dependent directories *except* > Solaris/sparc32 (SOLgnu/SOLsun) for stack walking support > uin-common vs. uin-len > > change time_t to be 64bits for all platforms > but underlying implementation still needs work (elaborated below) > > tested on SOLgnu, AMD64_DARWIN, LINUXLIBC6 > It compiles and the assertions all hold. > Local and utc data appears correct, cross checking with date and date -u, including > setting Linux/x86 and Solaris/sparc32 system clocks back to Jan 1 2010. > Did not test functionaly on Darwin or any BSD (but note that Linux uses the BSD code). > > still to do: > use 64bit time_t code from http://code.google.com/p/y2038/ > combine some of lingering code in UtimeC.c into Time/DatePosixC.c, as static functions > We can actually add stuff back like localtime/gmtime trafficing in 64bit time_t, > as long as we use our own carefully controlled/copied types (i.e. omit the > extra two fields in struct tm). Just as well as we can provide gettimeofday, select. If we must. > Maybe test on Darwin, *BSD, Cygwin, Interix, etc. > Test in other timezones. > Enable a regularly run test? > Consider relayout Date.T to it doesn't have padding in the middle or perhaps anywhere. > (Hard to avoid if there are subranges, will be padded at least at end.) > > We can't achieve 64bit gettimeofday or file timestamps beyond year 2038 > but if you fill in a Date.T with year > 2038, that can be useful and be made > to work. It should roundtrip with Time.T and be printable. > > structure is a little odd > DatePosix.i3, TimePosix.i3 describe C code > DatePosix.m3, TimePosix.m3 expose Date, Time, call into DatePosix, TimePosix > This is just to reuse existing names or name patterns. > We could just as well introduce new interfaes TimeC, DateC, TimeInternal, DateTimeInternal, etc. > > Note: This also fixes the UTC timezone on Solaris, Interix, HP-UX, Cygwin, which appear to have been historically broken. > > Note: This also uncovered that my Solaris clock was behind by a few minutes. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Apr 15 15:47:03 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 15 Apr 2010 13:47:03 +0000 Subject: [M3devel] date/time stuff In-Reply-To: References: <20100415114428.52D0D2474004@birch.elegosoft.com>, Message-ID: Something went very wrong in the history here. Long ago. Not today. I think we never got the 5.1 changes out of a branch, or something. In version 1.2 I accidentally did copy them out of the branch somehow, and then in 1.3 I put it back, since I wasn't intending to do that. I don't know how I would have gotten that content. Maybe I scrolled down in the cvsweb and selected what I thought was previous, as part of editing/reverting my work. At the time now way I would have used cvs upd -r. I didn't learn till much later. See http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/time/POSIX/DatePosix.m3.diff?r1=1.1;r2=1.3 1.1 and 1.3 are identical. 1.1 to 1.4 http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/time/POSIX/DatePosix.m3.diff?r1=1.1;r2=1.4 is the change I was after. That leaves me uncertain which historical behavior to aim for. :( Need to write more tests.. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Subject: date/time stuff Date: Thu, 15 Apr 2010 12:18:44 +0000 I still have small lingering concerns here. - when to call tzset? Historically we called at in the Posix version startup only. I believe localtime implicitcally calls tzset, so we kind of had it backwards? - foo vs. foo_r? I changed any to _r. However there are differences relative, again, to tzset. It seems to me, program can be long running, can span a timezone change. Calling tzset just at startup, not great. - So maybe a better approach is DisableScheduling/EnableScheduling Don't use the _r functions? and/or call tzset more often? - I think I should probably introduce an "idealized" "DatePosix.T" just containing INTEGERs or LONGINTs and no subranges. Besides making the layout totally clear, unlike today, that will also cause subrange checks when the Modula-3 code copies the C values out. Today there are no subrange checks. One needs to be careful defining the ranges, due to various "leap" conditions (not just days, but also seconds, etc.) - I have not run tests that span timezone changes. I think that should be done. It's not difficult actually. Just put an infinite loop around p235 and require user to press enter between iterations, meanwhile changing the system clock/timezone. I can get to that within a week. - There is some possibility here of sharing implementation with Win32! ANSI C has localtime/gmtime, of course and msvcr*.dll do expose daylight, tzname[]. Possibly we can have just one "Posix" implementation. Instead of today's three implementations. - Jay From: jay.krell at cornell.edu To: jkrell at elego.de; m3commit at elegosoft.com Date: Thu, 15 Apr 2010 11:49:09 +0000 Subject: Re: [M3commit] CVS Update: cm3 diff attached > Date: Thu, 15 Apr 2010 13:44:28 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/04/15 13:44:28 > > Modified files: > cm3/m3-libs/m3core/src/: m3core.h > cm3/m3-libs/m3core/src/time/POSIX/: DatePosix.m3 DatePosixC.c > TimePosix.i3 TimePosix.m3 > TimePosixC.c m3makefile > cm3/m3-libs/m3core/src/unix/: m3makefile > cm3/m3-libs/m3core/src/unix/Common/: Unix.i3 Utime.i3 UtimeC.c > Utypes.i3 > Added files: > cm3/m3-libs/m3core/src/time/POSIX/: DatePosix.i3 > > Log message: > eliminate struct_tm (somewhat platform specific) > eliminate struct_timeval (somewhat platform specific) > eliminate FDSet (somewhat platform specific) > eliminate MAX_FDSET (somewhat platform specific) > eliminate lots of functions from Utime > i.e. functions that use those types, like gettimeofday, localtime, gmtime > functions that were used only in m3core/src/time/*.m3 like get_timezone, altzone > > eliminate "all" the m3core/src/unix platform dependent directories *except* > Solaris/sparc32 (SOLgnu/SOLsun) for stack walking support > uin-common vs. uin-len > > change time_t to be 64bits for all platforms > but underlying implementation still needs work (elaborated below) > > tested on SOLgnu, AMD64_DARWIN, LINUXLIBC6 > It compiles and the assertions all hold. > Local and utc data appears correct, cross checking with date and date -u, including > setting Linux/x86 and Solaris/sparc32 system clocks back to Jan 1 2010. > Did not test functionaly on Darwin or any BSD (but note that Linux uses the BSD code). > > still to do: > use 64bit time_t code from http://code.google.com/p/y2038/ > combine some of lingering code in UtimeC.c into Time/DatePosixC.c, as static functions > We can actually add stuff back like localtime/gmtime trafficing in 64bit time_t, > as long as we use our own carefully controlled/copied types (i.e. omit the > extra two fields in struct tm). Just as well as we can provide gettimeofday, select. If we must. > Maybe test on Darwin, *BSD, Cygwin, Interix, etc. > Test in other timezones. > Enable a regularly run test? > Consider relayout Date.T to it doesn't have padding in the middle or perhaps anywhere. > (Hard to avoid if there are subranges, will be padded at least at end.) > > We can't achieve 64bit gettimeofday or file timestamps beyond year 2038 > but if you fill in a Date.T with year > 2038, that can be useful and be made > to work. It should roundtrip with Time.T and be printable. > > structure is a little odd > DatePosix.i3, TimePosix.i3 describe C code > DatePosix.m3, TimePosix.m3 expose Date, Time, call into DatePosix, TimePosix > This is just to reuse existing names or name patterns. > We could just as well introduce new interfaes TimeC, DateC, TimeInternal, DateTimeInternal, etc. > > Note: This also fixes the UTC timezone on Solaris, Interix, HP-UX, Cygwin, which appear to have been historically broken. > > Note: This also uncovered that my Solaris clock was behind by a few minutes. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Apr 15 16:43:23 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 15 Apr 2010 14:43:23 +0000 Subject: [M3devel] deleting most of m3core/src/unix? Message-ID: Ok..maybe now time to delete all of m3core/src/unix except for uin-*, Common, and part of solaris-2-x? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Apr 15 18:55:52 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 15 Apr 2010 12:55:52 -0400 Subject: [M3devel] Modula-3/C interop in Date/Time? In-Reply-To: References: Message-ID: <7C7408D0-9A40-4988-BADA-A9FD8C15D388@cs.purdue.edu> Excepting that INTEGER is not the same as int on 64-bit platforms. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 15 Apr 2010, at 02:45, Jay K wrote: > Is this legal/correct? > > > Date.i3: > TYPE TimeZone <: REFANY; > VAR Local, UTC: TimeZone; (* granted, will maybe change these to extern *) > > > Date.m3:? > REVEAL TimeZone = BRANDED "Date.TimeZone" REF INTEGER; > ? > > DatePosixC.c: > static const int Local = 0; > static const int UTC = 1; > extern const int const * const Date__Local = &Local; > extern const int const * const Date__UTC = &UTC; > ? > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Apr 15 23:26:06 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 15 Apr 2010 21:26:06 +0000 Subject: [M3devel] Modula-3/C interop in Date/Time? In-Reply-To: <7C7408D0-9A40-4988-BADA-A9FD8C15D388@cs.purdue.edu> References: , <7C7408D0-9A40-4988-BADA-A9FD8C15D388@cs.purdue.edu> Message-ID: Oops, right, of course. Important to get the things right I know to keep the question clear/narrow. - Jay From: hosking at cs.purdue.edu Date: Thu, 15 Apr 2010 12:55:52 -0400 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] Modula-3/C interop in Date/Time? Excepting that INTEGER is not the same as int on 64-bit platforms. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 15 Apr 2010, at 02:45, Jay K wrote: Is this legal/correct? Date.i3: TYPE TimeZone <: REFANY; VAR Local, UTC: TimeZone; (* granted, will maybe change these to extern *) Date.m3:? REVEAL TimeZone = BRANDED "Date.TimeZone" REF INTEGER; ? DatePosixC.c: static const int Local = 0; static const int UTC = 1; extern const int const * const Date__Local = &Local; extern const int const * const Date__UTC = &UTC; ? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcolebur at SCIRES.COM Fri Apr 16 00:10:44 2010 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Thu, 15 Apr 2010 18:10:44 -0400 Subject: [M3devel] Modula-3/C interop in Date/Time? In-Reply-To: References: , <7C7408D0-9A40-4988-BADA-A9FD8C15D388@cs.purdue.edu> Message-ID: Jay: I?m still catching up after being in hospital, but noticed you are working on the Date.i3/m3 interface and module. There is a problem that I?d like to post on the newsgroup that may be related. I?m not sure if the problem is due to the way Date.i3/m3 is coded, or perhaps a problem in the network objects stub generator, but I thought whilst you are looking at Date.i3/m3 something might trigger in your mind about how to fix the problem. I have several interfaces that export a Network Object. Of course, these get processed by the network objects stub generator at compile time. For some of these, the generated files fail to compile due to Date.i3 not being listed in the IMPORT list. Since these offending modules are generated at compile time, it?s not a programming error in the new source package that is being compiled. The way I work around the problem is by editing the generated files after the compile fails. Namely, I go to the target folder (in this case NT386) and edit the generated m3 files by adding ?IMPORT Date;?, then recompile and all is well. Of course, the next time you erase the target folder, change the underlying interface, or run ?cm3 -clean?, the generated file has to be created again and you have to go thru the compile-edit-compile cycle again to repair the problem. If you are delivering source code to a customer, you then have to document the work-around for them so that they can get the package to compile. I reported this problem years ago, but that was back before we were tracking bugs using the new system. It could be that the way Date.i3/m3 is coded is causing the stub generator not to think it needs to import it, or it could be that the stub generator isn?t doing its job right in the first place. Now after saying all this, I know I should provide a concrete example. I?ll have to go back and see if I ever reduced the code to a smaller set that demonstrates the problem. Otherwise, I can?t give anyone the full source code because it was a ?work-for-hire? and I don?t have the right to publish these sources. Let me know if you want a concrete example and I?ll see what I can do. Regards, Randy From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K Sent: Thursday, April 15, 2010 5:26 PM To: Tony Cc: m3devel Subject: Re: [M3devel] Modula-3/C interop in Date/Time? Oops, right, of course. Important to get the things right I know to keep the question clear/narrow. - Jay ________________________________ From: hosking at cs.purdue.edu Date: Thu, 15 Apr 2010 12:55:52 -0400 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] Modula-3/C interop in Date/Time? Excepting that INTEGER is not the same as int on 64-bit platforms. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 15 Apr 2010, at 02:45, Jay K wrote: Is this legal/correct? Date.i3: TYPE TimeZone <: REFANY; VAR Local, UTC: TimeZone; (* granted, will maybe change these to extern *) Date.m3:? REVEAL TimeZone = BRANDED "Date.TimeZone" REF INTEGER; ? DatePosixC.c: static const int Local = 0; static const int UTC = 1; extern const int const * const Date__Local = &Local; extern const int const * const Date__UTC = &UTC; ? - Jay ________________________________ CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This email may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from reviewing, copying, using, disclosing or distributing to others the information in this email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require advance export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Fri Apr 16 00:44:07 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 15 Apr 2010 17:44:07 -0500 Subject: [M3devel] Modula-3/C interop in Date/Time? In-Reply-To: References: Message-ID: <4BC796B7.7090707@lcwb.coop> Since these pointer variables are initialized by C code and their referents are also provided by C code as global variables, shouldn't the type be untraced? I suppose that, since they don't point into the traced heap, the collector implementation we have would quietly ignore them as roots. But that's relying on implementation- dependent information. Also, if someone created a field of type Date.TimeZone, (or an array of them) in a traced-heap-allocated object, which is a perfectly legitimate thing to do, what would our collector do then? Jay K wrote: > Is this legal/correct? > > > Date.i3: > TYPE TimeZone <: REFANY; > VAR Local, UTC: TimeZone; (* granted, will maybe change these to extern *) > > > Date.m3:? > REVEAL TimeZone = BRANDED "Date.TimeZone" REF INTEGER; > ? > > DatePosixC.c: > static const int Local = 0; > static const int UTC = 1; > extern const int const * const Date__Local = &Local; > extern const int const * const Date__UTC = &UTC; > ? > > - Jay From jay.krell at cornell.edu Fri Apr 16 01:13:23 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 15 Apr 2010 23:13:23 +0000 Subject: [M3devel] Modula-3/C interop in Date/Time? In-Reply-To: References: , , <7C7408D0-9A40-4988-BADA-A9FD8C15D388@cs.purdue.edu>, , Message-ID: Randy, I think I understand but yes please commit a small concrete example like in m3-sys/m3tests/src/p2/p237 or such. I think this is a bug in the stub generator. Probably time/date could workaround it with slight restructuring/renaming. But probably should fix the stub generator. While at it, maybe have it stop outputing unused stuff that triggers so many warnings... - Jay From: rcolebur at SCIRES.COM To: m3devel at elegosoft.com Date: Thu, 15 Apr 2010 18:10:44 -0400 Subject: Re: [M3devel] Modula-3/C interop in Date/Time? Jay: I?m still catching up after being in hospital, but noticed you are working on the Date.i3/m3 interface and module. There is a problem that I?d like to post on the newsgroup that may be related. I?m not sure if the problem is due to the way Date.i3/m3 is coded, or perhaps a problem in the network objects stub generator, but I thought whilst you are looking at Date.i3/m3 something might trigger in your mind about how to fix the problem. I have several interfaces that export a Network Object. Of course, these get processed by the network objects stub generator at compile time. For some of these, the generated files fail to compile due to Date.i3 not being listed in the IMPORT list. Since these offending modules are generated at compile time, it?s not a programming error in the new source package that is being compiled. The way I work around the problem is by editing the generated files after the compile fails. Namely, I go to the target folder (in this case NT386) and edit the generated m3 files by adding ?IMPORT Date;?, then recompile and all is well. Of course, the next time you erase the target folder, change the underlying interface, or run ?cm3 ?clean?, the generated file has to be created again and you have to go thru the compile-edit-compile cycle again to repair the problem. If you are delivering source code to a customer, you then have to document the work-around for them so that they can get the package to compile. I reported this problem years ago, but that was back before we were tracking bugs using the new system. It could be that the way Date.i3/m3 is coded is causing the stub generator not to think it needs to import it, or it could be that the stub generator isn?t doing its job right in the first place. Now after saying all this, I know I should provide a concrete example. I?ll have to go back and see if I ever reduced the code to a smaller set that demonstrates the problem. Otherwise, I can?t give anyone the full source code because it was a ?work-for-hire? and I don?t have the right to publish these sources. Let me know if you want a concrete example and I?ll see what I can do. Regards, Randy From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K Sent: Thursday, April 15, 2010 5:26 PM To: Tony Cc: m3devel Subject: Re: [M3devel] Modula-3/C interop in Date/Time? Oops, right, of course. Important to get the things right I know to keep the question clear/narrow. - Jay From: hosking at cs.purdue.edu Date: Thu, 15 Apr 2010 12:55:52 -0400 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] Modula-3/C interop in Date/Time? Excepting that INTEGER is not the same as int on 64-bit platforms. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 15 Apr 2010, at 02:45, Jay K wrote: Is this legal/correct? Date.i3: TYPE TimeZone <: REFANY; VAR Local, UTC: TimeZone; (* granted, will maybe change these to extern *) Date.m3:? REVEAL TimeZone = BRANDED "Date.TimeZone" REF INTEGER; ? DatePosixC.c: static const int Local = 0; static const int UTC = 1; extern const int const * const Date__Local = &Local; extern const int const * const Date__UTC = &UTC; ? - Jay CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This email may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from reviewing, copying, using, disclosing or distributing to others the information in this email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require advance export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Fri Apr 16 00:55:58 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 15 Apr 2010 17:55:58 -0500 Subject: [M3devel] Modula-3/C interop in Date/Time? In-Reply-To: References: , <7C7408D0-9A40-4988-BADA-A9FD8C15D388@cs.purdue.edu> Message-ID: <4BC7997E.5050708@lcwb.coop> Coleburn, Randy wrote: > Jay: > > > > I?m still catching up after being in hospital, but noticed you are > working on the Date.i3/m3 interface and module. > > > > There is a problem that I?d like to post on the newsgroup that may be > related. > > > > I?m not sure if the problem is due to the way Date.i3/m3 is coded, or > perhaps a problem in the network objects stub generator, but I thought > whilst you are looking at Date.i3/m3 something might trigger in your > mind about how to fix the problem. > > > > I have several interfaces that export a Network Object. Of course, > these get processed by the network objects stub generator at compile > time. For some of these, the generated files fail to compile due to > Date.i3 not being listed in the IMPORT list. > > > > Since these offending modules are generated at compile time, it?s not a > programming error in the new source package that is being compiled. > > > > The way I work around the problem is by editing the generated files > after the compile fails. Namely, I go to the target folder (in this > case NT386) and edit the generated m3 files by adding ?IMPORT Date;?, > then recompile and all is well. > > > > Of course, the next time you erase the target folder, change the > underlying interface, or run ?cm3 ?clean?, the generated file has to be > created again and you have to go thru the compile-edit-compile cycle > again to repair the problem. If you are delivering source code to a > customer, you then have to document the work-around for them so that > they can get the package to compile. > > > > I reported this problem years ago, but that was back before we were > tracking bugs using the new system. > > > > It could be that the way Date.i3/m3 is coded is causing the stub > generator not to think it needs to import it, or it could be that the > stub generator isn?t doing its job right in the first place. I can't think of a way this could be anything but a bug in stubgen. The very fact (and only the fact) that the generated stub code refers to Date necessitates the IMPORT Date, regardless of what is coded in interface Date or what within Date is being referred to. Is the reference to Date in the generated stub derived from a reference to Date in the interface that stubgen is processing, or is it produced within stubgen itself? Actually, either way, stubgen should produce the IMPORT. > > > > Now after saying all this, I know I should provide a concrete example. > I?ll have to go back and see if I ever reduced the code to a smaller set > that demonstrates the problem. Otherwise, I can?t give anyone the full > source code because it was a ?work-for-hire? and I don?t have the right > to publish these sources. > > > > Let me know if you want a concrete example and I?ll see what I can do. > > > > Regards, > > Randy > > > > *From:* jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] *On Behalf Of > *Jay K > *Sent:* Thursday, April 15, 2010 5:26 PM > *To:* Tony > *Cc:* m3devel > *Subject:* Re: [M3devel] Modula-3/C interop in Date/Time? > > > > Oops, right, of course. Important to get the things right I know to keep > the question clear/narrow. > > - Jay > > > > ------------------------------------------------------------------------ > > From: hosking at cs.purdue.edu > Date: Thu, 15 Apr 2010 12:55:52 -0400 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Modula-3/C interop in Date/Time? > > Excepting that INTEGER is not the same as int on 64-bit platforms. > > > > Antony Hosking | Associate Professor | Computer Science | Purdue University > > 305 N. University Street | West Lafayette | IN 47907 | USA > > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > > > > > > On 15 Apr 2010, at 02:45, Jay K wrote: > > > > Is this legal/correct? > > > Date.i3: > TYPE TimeZone <: REFANY; > VAR Local, UTC: TimeZone; (* granted, will maybe change these to > extern *) > > > Date.m3:? > REVEAL TimeZone = BRANDED "Date.TimeZone" REF INTEGER; > ? > > DatePosixC.c: > static const int Local = 0; > static const int UTC = 1; > extern const int const * const Date__Local = &Local; > extern const int const * const Date__UTC = &UTC; > ? > > - Jay > > > > > ------------------------------------------------------------------------ > CONFIDENTIALITY NOTICE: This email and any attachments are intended > solely for the use of the named recipient(s). This email may contain > confidential and/or proprietary information of Scientific Research > Corporation. If you are not a named recipient, you are prohibited from > reviewing, copying, using, disclosing or distributing to others the > information in this email and attachments. If you believe you have > received this email in error, please notify the sender immediately and > permanently delete the email, any attachments, and all copies thereof > from any drives or storage media and destroy any printouts of the email > or attachments. > > EXPORT COMPLIANCE NOTICE: This email and any attachments may contain > technical data subject to U.S export restrictions under the > International Traffic in Arms Regulations (ITAR) or the Export > Administration Regulations (EAR). Export or transfer of this technical > data and/or related information to any foreign person(s) or entity(ies), > either within the U.S. or outside of the U.S., may require advance > export authorization by the appropriate U.S. Government agency prior to > export or transfer. In addition, technical data may not be exported or > transferred to certain countries or specified designated nationals > identified by U.S. embargo controls without prior export authorization. > By accepting this email and any attachments, all recipients confirm that > they understand and will comply with all applicable ITAR, EAR and > embargo compliance requirements. From jay.krell at cornell.edu Fri Apr 16 01:17:38 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 15 Apr 2010 23:17:38 +0000 Subject: [M3devel] Modula-3/C interop in Date/Time? In-Reply-To: <4BC796B7.7090707@lcwb.coop> References: , <4BC796B7.7090707@lcwb.coop> Message-ID: Rodney, right, I was wondering about traced vs. untraced also. I think having a traced pointer point outside the traced heap is ok though. The data will never be collected, the pointer never updated. If the untraced data were ever freed (such as e.g. unloading the .dll! Which people usually forget about as a scenario..) then the traced pointers would go stale and there'd be a safety problem. In either case I'm not "rewriting" it, because there is a "unified interface" between Posix and Win32, and I can't make it <*external*> in one but not the other, unless I fork the file, not particularly worthwhile. - Jay > Date: Thu, 15 Apr 2010 17:44:07 -0500 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Modula-3/C interop in Date/Time? > > Since these pointer variables are initialized by > C code and their referents are also provided by C code > as global variables, shouldn't the type be untraced? > > I suppose that, since they don't point into the traced > heap, the collector implementation we have would quietly > ignore them as roots. But that's relying on implementation- > dependent information. > > Also, if someone created a field of type Date.TimeZone, > (or an array of them) in a traced-heap-allocated object, > which is a perfectly legitimate thing to do, what would > our collector do then? > > > > Jay K wrote: > > Is this legal/correct? > > > > > > Date.i3: > > TYPE TimeZone <: REFANY; > > VAR Local, UTC: TimeZone; (* granted, will maybe change these to extern *) > > > > > > Date.m3:? > > REVEAL TimeZone = BRANDED "Date.TimeZone" REF INTEGER; > > ? > > > > DatePosixC.c: > > static const int Local = 0; > > static const int UTC = 1; > > extern const int const * const Date__Local = &Local; > > extern const int const * const Date__UTC = &UTC; > > ? > > > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Apr 16 04:08:35 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 15 Apr 2010 22:08:35 -0400 Subject: [M3devel] Modula-3/C interop in Date/Time? In-Reply-To: References: , <4BC796B7.7090707@lcwb.coop> Message-ID: On 15 Apr 2010, at 19:17, Jay K wrote: > Rodney, right, I was wondering about traced vs. untraced also. I think having a traced pointer point outside the traced heap is ok though. The data will never be collected, the pointer never updated. There are assertions in the @M3paranoid collector that will complain if a reference outside the heap is not to a TEXT literal. Those should be the only ones we see. Correctness dictates that we use UNTRACED references (ADDRESS, UNTRACED REF...) here. > If the untraced data were ever freed (such as e.g. unloading the .dll! Which people usually forget about as a scenario..) then the traced pointers would go stale and there'd be a safety problem. > > > In either case I'm not "rewriting" it, because there is a "unified interface" between Posix and Win32, and I can't make it <*external*> in one but not the other, unless I fork the file, not particularly worthwhile. > > > - Jay > > > Date: Thu, 15 Apr 2010 17:44:07 -0500 > > From: rodney_bates at lcwb.coop > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] Modula-3/C interop in Date/Time? > > > > Since these pointer variables are initialized by > > C code and their referents are also provided by C code > > as global variables, shouldn't the type be untraced? > > > > I suppose that, since they don't point into the traced > > heap, the collector implementation we have would quietly > > ignore them as roots. But that's relying on implementation- > > dependent information. > > > > Also, if someone created a field of type Date.TimeZone, > > (or an array of them) in a traced-heap-allocated object, > > which is a perfectly legitimate thing to do, what would > > our collector do then? > > > > > > > > Jay K wrote: > > > Is this legal/correct? > > > > > > > > > Date.i3: > > & gt; TYPE TimeZone <: REFANY; > > > VAR Local, UTC: TimeZone; (* granted, will maybe change these to extern *) > > > > > > > > > Date.m3:? > > > REVEAL TimeZone = BRANDED "Date.TimeZone" REF INTEGER; > > > ? > > > > > > DatePosixC.c: > > > static const int Local = 0; > > > static const int UTC = 1; > > > extern const int const * const Date__Local = &Local; > > > extern const int const * const Date__UTC = &UTC; > > > ? > > > > > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Apr 16 04:06:14 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 15 Apr 2010 22:06:14 -0400 Subject: [M3devel] Modula-3/C interop in Date/Time? In-Reply-To: <4BC796B7.7090707@lcwb.coop> References: <4BC796B7.7090707@lcwb.coop> Message-ID: Indeed! UNTRACED. On 15 Apr 2010, at 18:44, Rodney M. Bates wrote: > Since these pointer variables are initialized by > C code and their referents are also provided by C code > as global variables, shouldn't the type be untraced? > > I suppose that, since they don't point into the traced > heap, the collector implementation we have would quietly > ignore them as roots. But that's relying on implementation- > dependent information. > > Also, if someone created a field of type Date.TimeZone, > (or an array of them) in a traced-heap-allocated object, > which is a perfectly legitimate thing to do, what would > our collector do then? > > > > Jay K wrote: >> Is this legal/correct? >> >> >> Date.i3: >> TYPE TimeZone <: REFANY; >> VAR Local, UTC: TimeZone; (* granted, will maybe change these to extern *) >> >> >> Date.m3:? >> REVEAL TimeZone = BRANDED "Date.TimeZone" REF INTEGER; >> ? >> >> DatePosixC.c: >> static const int Local = 0; >> static const int UTC = 1; >> extern const int const * const Date__Local = &Local; >> extern const int const * const Date__UTC = &UTC; >> ? >> >> - Jay From jay.krell at cornell.edu Fri Apr 16 06:24:43 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 16 Apr 2010 04:24:43 +0000 Subject: [M3devel] Modula-3/C interop in Date/Time? In-Reply-To: References: , <4BC796B7.7090707@lcwb.coop>, Message-ID: But then unsafe, right? - Jay > From: hosking at cs.purdue.edu > Date: Thu, 15 Apr 2010 22:06:14 -0400 > To: rodney_bates at lcwb.coop > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Modula-3/C interop in Date/Time? > > Indeed! UNTRACED. > > > On 15 Apr 2010, at 18:44, Rodney M. Bates wrote: > > > Since these pointer variables are initialized by > > C code and their referents are also provided by C code > > as global variables, shouldn't the type be untraced? > > > > I suppose that, since they don't point into the traced > > heap, the collector implementation we have would quietly > > ignore them as roots. But that's relying on implementation- > > dependent information. > > > > Also, if someone created a field of type Date.TimeZone, > > (or an array of them) in a traced-heap-allocated object, > > which is a perfectly legitimate thing to do, what would > > our collector do then? > > > > > > > > Jay K wrote: > >> Is this legal/correct? > >> > >> > >> Date.i3: > >> TYPE TimeZone <: REFANY; > >> VAR Local, UTC: TimeZone; (* granted, will maybe change these to extern *) > >> > >> > >> Date.m3:? > >> REVEAL TimeZone = BRANDED "Date.TimeZone" REF INTEGER; > >> ? > >> > >> DatePosixC.c: > >> static const int Local = 0; > >> static const int UTC = 1; > >> extern const int const * const Date__Local = &Local; > >> extern const int const * const Date__UTC = &UTC; > >> ? > >> > >> - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.async.caltech.edu Fri Apr 16 09:00:34 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Fri, 16 Apr 2010 00:00:34 -0700 Subject: [M3devel] Modula-3/C interop in Date/Time? In-Reply-To: References: , <4BC796B7.7090707@lcwb.coop>, Message-ID: <20100416070034.9C0911A20EB@async.async.caltech.edu> I don't think there's anything unsafe about UNTRACED. It's DISPOSE that's unsafe... Mika Jay K writes: >--_cbaca81c-f322-4f31-8684-e7f171e67f3d_ >Content-Type: text/plain; charset="iso-2022-jp" >Content-Transfer-Encoding: 7bit > >But then unsafe, right? > > - Jay > >> From: hosking at cs.purdue.edu >> Date: Thu, 15 Apr 2010 22:06:14 -0400 >> To: rodney_bates at lcwb.coop >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] Modula-3/C interop in Date/Time? >> >> Indeed! UNTRACED. >> >> >> On 15 Apr 2010, at 18:44, Rodney M. Bates wrote: >> >> > Since these pointer variables are initialized by >> > C code and their referents are also provided by C code >> > as global variables, shouldn't the type be untraced? >> > >> > I suppose that, since they don't point into the traced >> > heap, the collector implementation we have would quietly >> > ignore them as roots. But that's relying on implementation- >> > dependent information. >> > >> > Also, if someone created a field of type Date.TimeZone, >> > (or an array of them) in a traced-heap-allocated object, > > which is a perfectly legitimate thing to do, what would >> > our collector do then? >> > >> > >> > >> > Jay K wrote: >> >> Is this legal/correct? >> >> >> >> >> >> Date.i3: >> >> TYPE TimeZone <: REFANY; >> >> VAR Local, UTC: TimeZone; (* granted, will maybe change these to extern *) >> >> >> >> >> >> Date.m3:$B!!(B >> >> REVEAL TimeZone = BRANDED "Date.TimeZone" REF INTEGER; >> >> $B!!(B >> >> >> >> DatePosixC.c: >> >> static const int Local = 0; >> >> static const int UTC = 1; >> >> extern const int const * const Date__Local = &Local; >> >> extern const int const * const Date__UTC = &UTC; >> >> $B!!(B >> >> >> >> - Jay >> > >--_cbaca81c-f322-4f31-8684-e7f171e67f3d_ >Content-Type: text/html; charset="iso-2022-jp" >Content-Transfer-Encoding: 7bit > > > > > >But then unsafe, right?

- Jay

> From: hosking@cs.purdue.edu
> Date: Thu, 15 Apr 2010 22:06:14 -0400
> To: rodney_bates& >#64;lcwb.coop
> CC: m3devel@elegosoft.com
> Subject: Re: [M3devel] Modula-3/C interop in Date/Time?
>
> Indeed! UNTRACED.
>
> < >br>> On 15 Apr 2010, at 18:44, Rodney M. Bates wrote:
>
> > Since these pointer variables are initialized by
> > C code and their referents are also provided by C > code
> > as global variables, shouldn't the type be untraced?
> >
> > I suppose that, since they don't point into the traced
> > heap, the collect >or implementation we have would quietly
> > ignore them as roots. But that's relying on implementation-
> > dependent information.
> >
> > Also, if someon >e created a field of type Date.TimeZone,
> > > ; (or an array of them) in a traced-heap-allocated object,
> > which is a perfectly legitimate thing to do, what would
> > our collector do then?
> >
>> >
> >
> > Jay K wrote:
> >> Is this legal/correct?
> >>
> >>
> >> Date.i3:
> >> TYPE TimeZone > <: REFANY;
> >> VAR Local, UTC: TimeZone; (* granted, will maybe change these to extern *)
> >>
> >>
> >> > Date.m3: 
> >> REVEAL TimeZone = BRANDED "Date.TimeZone" REF INTEGER;
> >>  
> >>
> >> DatePosixC.c:
>> >> static const int Local = 0;
> >> static const int UTC = 1;
> >> extern const int const * const Date__Local = &Local;
> > >> extern const int const * const Dat > e__UTC = &UTC;
> >>  
> >>
> >> - Jay
>
> >--_cbaca81c-f322-4f31-8684-e7f171e67f3d_-- From jay.krell at cornell.edu Fri Apr 16 10:18:29 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 16 Apr 2010 08:18:29 +0000 Subject: [M3devel] Modula-3/C interop in Date/Time? In-Reply-To: <20100416070034.9C0911A20EB@async.async.caltech.edu> References: , , <4BC796B7.7090707@lcwb.coop>, , , , <20100416070034.9C0911A20EB@async.async.caltech.edu> Message-ID: Isn't making them unsafe? ADR? I'll try.. - Jay > To: jay.krell at cornell.edu > Date: Fri, 16 Apr 2010 00:00:34 -0700 > From: mika at async.async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Modula-3/C interop in Date/Time? > > I don't think there's anything unsafe about UNTRACED. > > It's DISPOSE that's unsafe... > > Mika > > Jay K writes: > >--_cbaca81c-f322-4f31-8684-e7f171e67f3d_ > >Content-Type: text/plain; charset="iso-2022-jp" > >Content-Transfer-Encoding: 7bit > > > >But then unsafe, right? > > > > - Jay > > > >> From: hosking at cs.purdue.edu > >> Date: Thu, 15 Apr 2010 22:06:14 -0400 > >> To: rodney_bates at lcwb.coop > >> CC: m3devel at elegosoft.com > >> Subject: Re: [M3devel] Modula-3/C interop in Date/Time? > >> > >> Indeed! UNTRACED. > >> > >> > >> On 15 Apr 2010, at 18:44, Rodney M. Bates wrote: > >> > >> > Since these pointer variables are initialized by > >> > C code and their referents are also provided by C code > >> > as global variables, shouldn't the type be untraced? > >> > > >> > I suppose that, since they don't point into the traced > >> > heap, the collector implementation we have would quietly > >> > ignore them as roots. But that's relying on implementation- > >> > dependent information. > >> > > >> > Also, if someone created a field of type Date.TimeZone, > >> > (or an array of them) in a traced-heap-allocated object, > > > which is a perfectly legitimate thing to do, what would > >> > our collector do then? > >> > > >> > > >> > > >> > Jay K wrote: > >> >> Is this legal/correct? > >> >> > >> >> > >> >> Date.i3: > >> >> TYPE TimeZone <: REFANY; > >> >> VAR Local, UTC: TimeZone; (* granted, will maybe change these to extern *) > >> >> > >> >> > >> >> Date.m3:? > >> >> REVEAL TimeZone = BRANDED "Date.TimeZone" REF INTEGER; > >> >> ? > >> >> > >> >> DatePosixC.c: > >> >> static const int Local = 0; > >> >> static const int UTC = 1; > >> >> extern const int const * const Date__Local = &Local; > >> >> extern const int const * const Date__UTC = &UTC; > >> >> ? > >> >> > >> >> - Jay > >> > > > >--_cbaca81c-f322-4f31-8684-e7f171e67f3d_ > >Content-Type: text/html; charset="iso-2022-jp" > >Content-Transfer-Encoding: 7bit > > > > > > > > > > > >But then unsafe, right?

- Jay

> From: hosking@cs.purdue.edu
> Date: Thu, 15 Apr 2010 22:06:14 -0400
> To: rodney_bates& > >#64;lcwb.coop
> CC: m3devel@elegosoft.com
> Subject: Re: [M3devel] Modula-3/C interop in Date/Time?
>
> Indeed! UNTRACED.
>
> < > >br>> On 15 Apr 2010, at 18:44, Rodney M. Bates wrote:
>
> > Since these pointer variables are initialized by
> > C code and their referents are also provided by C > > code
> > as global variables, shouldn't the type be untraced?
> >
> > I suppose that, since they don't point into the traced
> > heap, the collect > >or implementation we have would quietly
> > ignore them as roots. But that's relying on implementation-
> > dependent information.
> >
> > Also, if someon > >e created a field of type Date.TimeZone,
> > > > ; (or an array of them) in a traced-heap-allocated object,
> > which is a perfectly legitimate thing to do, what would
> > our collector do then?
> >
> >> >
> >
> > Jay K wrote:
> >> Is this legal/correct?
> >>
> >>
> >> Date.i3:
> >> TYPE TimeZone > > <: REFANY;
> >> VAR Local, UTC: TimeZone; (* granted, will maybe change these to extern *)
> >>
> >>
> >> > > Date.m3: 
> >> REVEAL TimeZone = BRANDED "Date.TimeZone" REF INTEGER;
> >>  
> >>
> >> DatePosixC.c:
> >> >> static const int Local = 0;
> >> static const int UTC = 1;
> >> extern const int const * const Date__Local = &Local;
> > > >> extern const int const * const Dat > > e__UTC = &UTC;
> >>  
> >>
> >> - Jay
>
> > > >--_cbaca81c-f322-4f31-8684-e7f171e67f3d_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Fri Apr 16 11:38:14 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 16 Apr 2010 11:38:14 +0200 Subject: [M3devel] release engineering 5.8: trac issue 1005 (open array initializers) Message-ID: <20100416113814.xwn126mk800808kc@mail.elegosoft.com> I'm currently reviewing the open issues again, and came across https://projects.elego.de/cm3/ticket/1005 Not sure if I've asked before, but do we need to solve this for this release? The GC error seems strange: --- ../src/p2/p209/stderr.build 2009-06-29 21:47:53.000000000 +0200 +++ ../src/p2/p209/AMD64_LINUX/stderr.build 2009-07-20 08:17:17.000000000 +0200 @@ -0,0 +1,13 @@ +o is 0x348 +init_pc is 0x0 +bias is 0x5c8 +Target.Address.align is 0x40 +Target.Byte is 0x8 + + +*** +*** runtime error: +*** <*ASSERT*> failed. +*** file "../src/misc/CG.m3", line 1077 +*** + 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 Fri Apr 16 11:45:09 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 16 Apr 2010 11:45:09 +0200 Subject: [M3devel] release engineering 5.8: code generator error for IP address initializers Message-ID: <20100416114509.eh8r662dwss44oo8@mail.elegosoft.com> We also have this error, which should perhaps not be ignored? http://hudson.modula3.com:8080/job/cm3-test-m3tests-AMD64_FREEBSD/lastBuild/testReport/(root)/m3tests/p204__IP_address_initializers 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 jay.krell at cornell.edu Fri Apr 16 11:58:13 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 16 Apr 2010 09:58:13 +0000 Subject: [M3devel] release engineering 5.8: trac issue 1005 (open array initializers) In-Reply-To: <20100416113814.xwn126mk800808kc@mail.elegosoft.com> References: <20100416113814.xwn126mk800808kc@mail.elegosoft.com> Message-ID: I believe Tony removed the print outs but imho they should be left in until the assertion failure is understood and fixed. They try to inform on what is going on when the assertion fails. - Jay > Date: Fri, 16 Apr 2010 11:38:14 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] release engineering 5.8: trac issue 1005 (open array initializers) > > I'm currently reviewing the open issues again, and came across > > https://projects.elego.de/cm3/ticket/1005 > > Not sure if I've asked before, but do we need to solve this for this > release? The GC error seems strange: > > --- ../src/p2/p209/stderr.build 2009-06-29 21:47:53.000000000 +0200 > +++ ../src/p2/p209/AMD64_LINUX/stderr.build 2009-07-20 > 08:17:17.000000000 +0200 > @@ -0,0 +1,13 @@ > +o is 0x348 > +init_pc is 0x0 > +bias is 0x5c8 > +Target.Address.align is 0x40 > +Target.Byte is 0x8 > + > + > +*** > +*** runtime error: > +*** <*ASSERT*> failed. > +*** file "../src/misc/CG.m3", line 1077 > +*** > + > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Apr 16 12:01:30 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 16 Apr 2010 10:01:30 +0000 Subject: [M3devel] release engineering 5.8: code generator error for IP address initializers In-Reply-To: <20100416114509.eh8r662dwss44oo8@mail.elegosoft.com> References: <20100416114509.eh8r662dwss44oo8@mail.elegosoft.com> Message-ID: "aside": http://hudson.modula3.com:8080/job/cm3-test-m3tests-AMD64_FREEBSD/lastBuild/testReport/(root)/m3tests/p206__ARRAY_constructors_in_var_decls_using_named_open_array_types/ http://hudson.modula3.com:8080/job/cm3-test-m3tests-AMD64_FREEBSD/lastBuild/testReport/(root)/m3tests/r004__negative_size_for_an_open_array/ It'd be nice if in Quake we had something regular expression-ish, so that we could factor out the line numbers, such as e.g. to match any decimal number. Maybe just check for lines that start how we expect and cut them off at some position. That might be doable with today's Quake. - Jay > Date: Fri, 16 Apr 2010 11:45:09 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] release engineering 5.8: code generator error for IP address initializers > > We also have this error, which should perhaps not be ignored? > > http://hudson.modula3.com:8080/job/cm3-test-m3tests-AMD64_FREEBSD/lastBuild/testReport/(root)/m3tests/p204__IP_address_initializers > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Fri Apr 16 12:50:48 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 16 Apr 2010 12:50:48 +0200 Subject: [M3devel] release engineering 5.8: code generator error for IP address initializers In-Reply-To: References: <20100416114509.eh8r662dwss44oo8@mail.elegosoft.com> Message-ID: <20100416125048.183752ukg4os0kgk@mail.elegosoft.com> I agree. Regular expressions in quake would be great for regression tests. Perhaps for the next release? Olaf Quoting Jay K : > "aside": > > http://hudson.modula3.com:8080/job/cm3-test-m3tests-AMD64_FREEBSD/lastBuild/testReport/(root)/m3tests/p206__ARRAY_constructors_in_var_decls_using_named_open_array_types/ > > http://hudson.modula3.com:8080/job/cm3-test-m3tests-AMD64_FREEBSD/lastBuild/testReport/(root)/m3tests/r004__negative_size_for_an_open_array/ > > > It'd be nice if in Quake we had something regular expression-ish, so > that we could factor out the line numbers, such as e.g. to match > any decimal number. > > > Maybe just check for lines that start how we expect and cut them off > at some position. > That might be doable with today's Quake. > > > > - Jay > > > >> Date: Fri, 16 Apr 2010 11:45:09 +0200 >> From: wagner at elegosoft.com >> To: m3devel at elegosoft.com >> Subject: [M3devel] release engineering 5.8: code generator error >> for IP address initializers >> >> We also have this error, which should perhaps not be ignored? >> >> http://hudson.modula3.com:8080/job/cm3-test-m3tests-AMD64_FREEBSD/lastBuild/testReport/(root)/m3tests/p204__IP_address_initializers >> >> 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 wagner at elegosoft.com Fri Apr 16 13:09:06 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 16 Apr 2010 13:09:06 +0200 Subject: [M3devel] unused/little used stuff in m3core/unix? Message-ID: <20100416130906.o573xyu9co004gks@mail.elegosoft.com> Quoting Jay K : > Ok on preserving most/all of these but note I'm not keen on > preserving like anything dealing with structs or time_t. > > There are various arguments for/against. > > This "systems" language interoperates well with C, directly, IF you > control the C. > > Thus we have wrappers. We almost never interface directly with "the OS". > > Then again, same is true of C. Actual "kernels" have custom > calling mechanisms, which gets wrapped in C. > > I'm not sure we should provide a general set of wrappers, or leave > it to each user to write his own, > or provide some simple small set. Leaving it to each user is error > prone, granted. > > The historical implementation here was awful and *really* *not* the way. > > The question then is what should the implementation be. One more or less POSIXish API within m3core would be OK with me. It even needs not be complete, but I'd expect some well-known standard functions there. Of course this doesn't answer the question what should be included and what not. Olaf >> Date: Mon, 12 Apr 2010 10:12:12 +0200 >> From: wagner at elegosoft.com >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] unused/little used stuff in m3core/unix? >> >> Quoting Jay K : >> >> > Following are not used: >> > >> > fchmod >> > fchown >> > getpagesize >> > sbrk >> > creat >> > isatty >> > >> > That isn't necessarily all. >> > >> > Some are used only in: >> > >> > C:\dev2\cm3.2\m3-libs\libm3\src\os\POSIX >> > e.g. >> > chdir >> > getdtablesize >> > execve >> > >> > Some are used only in the unused m3-pkgtools directory or by cvsup. >> > e.g. umask >> > >> > These all traffic in pretty "plain" types (e.g. no structs, no >> > time_t). So just keep them all? >> >> Yes. These are standard POSIX or Unix legacy interfaces. >> Do not throw them out. >> >> > Note of course, uses of these somewhat or significantly inhibit >> > porting to native Win32. >> >> As these are POSIX, that is to be expected. >> >> > Account for somewhat arbirary Posix-specific code outside the cm3 tree >> > and err toward wrapping stuff that is easy? >> > >> > Or push the idea that m3core/libm3 are a good (and safe) portability >> > layer and only provide what they need, and >> > gradually move them towards C to reduce their needs? >> >> As a systems programming language, we should support standard OS >> interfaces IMO. >> >> 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 jay.krell at cornell.edu Fri Apr 16 14:15:03 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 16 Apr 2010 12:15:03 +0000 Subject: [M3devel] release engineering 5.8: code generator error for IP address initializers In-Reply-To: <20100416125048.183752ukg4os0kgk@mail.elegosoft.com> References: <20100416114509.eh8r662dwss44oo8@mail.elegosoft.com>, , <20100416125048.183752ukg4os0kgk@mail.elegosoft.com> Message-ID: (back to the topic :) ) somewhat reduced case: MODULE Main; TYPE T1 = ARRAY [0..0] OF INTEGER; CONST const: T1 = ARRAY OF INTEGER{2}; BEGIN END Main. The problem is two global integers are overlapping. The open array size and its first element. new source -> compiling Main.m3 "..\Main.m3", line 5: warning: not used (const) m3front:cg:Init_int:NOT in_init: o: 32 s:32 value:2 <== m3front:cg:Init_int:NOT in_init: o: 32 s:32 value:1 <== m3front:cg:Init_int:NOT in_init: o: 384 s:32 value:3 m3front:cg:Init_int:in_init: o: 32 s:32 value:1 m3front:cg:Init_int:in_init: o: 32 s:32 value:2 Are these syntaxes legal? This apparent mixing of open and fixed arrays? - Jay > Date: Fri, 16 Apr 2010 12:50:48 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] release engineering 5.8: code generator error for IP address initializers > > I agree. Regular expressions in quake would be great for regression tests. > Perhaps for the next release? > > Olaf > > Quoting Jay K : > > > "aside": > > > > http://hudson.modula3.com:8080/job/cm3-test-m3tests-AMD64_FREEBSD/lastBuild/testReport/(root)/m3tests/p206__ARRAY_constructors_in_var_decls_using_named_open_array_types/ > > > > http://hudson.modula3.com:8080/job/cm3-test-m3tests-AMD64_FREEBSD/lastBuild/testReport/(root)/m3tests/r004__negative_size_for_an_open_array/ > > > > > > It'd be nice if in Quake we had something regular expression-ish, so > > that we could factor out the line numbers, such as e.g. to match > > any decimal number. > > > > > > Maybe just check for lines that start how we expect and cut them off > > at some position. > > That might be doable with today's Quake. > > > > > > > > - Jay > > > > > > > >> Date: Fri, 16 Apr 2010 11:45:09 +0200 > >> From: wagner at elegosoft.com > >> To: m3devel at elegosoft.com > >> Subject: [M3devel] release engineering 5.8: code generator error > >> for IP address initializers > >> > >> We also have this error, which should perhaps not be ignored? > >> > >> http://hudson.modula3.com:8080/job/cm3-test-m3tests-AMD64_FREEBSD/lastBuild/testReport/(root)/m3tests/p204__IP_address_initializers > >> > >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Fri Apr 16 14:55:21 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 16 Apr 2010 14:55:21 +0200 Subject: [M3devel] assignability of fixed and open arrays, was: RE: release engineering 5.8: code generator error for IP address initializers In-Reply-To: References: <20100416114509.eh8r662dwss44oo8@mail.elegosoft.com>, , <20100416125048.183752ukg4os0kgk@mail.elegosoft.com> Message-ID: <20100416145521.sywubhm3kgk440w4@mail.elegosoft.com> Quoting Jay K : > (back to the topic :) ) > > somewhat reduced case: > > MODULE Main; > > TYPE T1 = ARRAY [0..0] OF INTEGER; > > CONST const: T1 = ARRAY OF INTEGER{2}; > BEGIN > END Main. > > The problem is two global integers are overlapping. > The open array size and its first element. > > Are these syntaxes legal? > This apparent mixing of open and fixed arrays? You mean it would work for CONST const: T1 = ARRAY [0..0] OF INTEGER{2}; The type of const is no open array, but the fixed array A1. So the question would be: is an open array (of the correct size) assignable to a fixed array type? An expression e is assignable to a variable v if: * the type of e is assignable to the type of v, and * the value of e is a member of the type of v, is not a local procedure, and if it is an array, then it has the same shape as v. though this is not a variable assignment, but a constant definition. Nonetheless, if that's assumed to be equivalent, then it would depend on the definition of shape: does it include the length field or not? I'd tend to think it does not (since that's just a representation the compiler (writer) chose), but only the number of dimensions and elements should count. But this is certainly subtle and others may see it differently. 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 jay.krell at cornell.edu Fri Apr 16 14:53:35 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 16 Apr 2010 12:53:35 +0000 Subject: [M3devel] the checked in .html files vs. $Id and such Message-ID: Some of the checked in generated .html files only vary because they use $Id-type stuff -- $Log or such. We should remove those, so the files aren't always stale. There's over 90 of these in m3-comm/events. Needs some scripting to remove. I suggest throw out the lines between "created" and "history", and throw out empty history. "history" is actually "abstract" and worth keeping when it isn't empty. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Apr 16 16:28:08 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 16 Apr 2010 10:28:08 -0400 Subject: [M3devel] Modula-3/C interop in Date/Time? In-Reply-To: References: , <4BC796B7.7090707@lcwb.coop>, Message-ID: <655C3BEA-B54B-434B-B3E9-E42AF4FD6FA1@cs.purdue.edu> Why unsafe? Depends what you do with it. On 16 Apr 2010, at 00:24, Jay K wrote: > But then unsafe, right? > > - Jay > > > From: hosking at cs.purdue.edu > > Date: Thu, 15 Apr 2010 22:06:14 -0400 > > To: rodney_bates at lcwb.coop > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] Modula-3/C interop in Date/Time? > > > > Indeed! UNTRACED. > > > > > > On 15 Apr 2010, at 18:44, Rodney M. Bates wrote: > > > > > Since these pointer variables are initialized by > > > C code and their referents are also provided by C code > > > as global variables, shouldn't the type be untraced? > > > > > > I suppose that, since they don't point into the traced > > > heap, the collector implementation we have would quietly > > > ignore them as roots. But that's relying on implementation- > > > dependent information. > > > > > > Also, if someone created a field of type Date.TimeZone, > > ! 2; (or an array of them) in a traced-heap-allocated object, > > > which is a perfectly legitimate thing to do, what would > > > our collector do then? > > > > > > > > > > > > Jay K wrote: > > >> Is this legal/correct? > > >> > > >> > > >> Date.i3: > > >> TYPE TimeZone <: REFANY; > > >> VAR Local, UTC: TimeZone; (* granted, will maybe change these to extern *) > > >> > > >> > > >> Date.m3:? > > >> REVEAL TimeZone = BRANDED "Date.TimeZone" REF INTEGER; > > >> ? > > >> > > >> DatePosixC.c: > > >> static const int Local = 0; > > >> static const int UTC = 1; > > >> extern const int const * const Date__Local = &Local; > > >> extern const int const * const D! ate__UTC = &UTC; > > >> ? > > >> > > >> - Jay > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Apr 16 16:30:48 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 16 Apr 2010 10:30:48 -0400 Subject: [M3devel] Modula-3/C interop in Date/Time? In-Reply-To: References: , , <4BC796B7.7090707@lcwb.coop>, , , , <20100416070034.9C0911A20EB@async.async.caltech.edu> Message-ID: <81B495C9-A0B2-4884-A6FC-5D928FC38340@cs.purdue.edu> What is the use-case here? Merely having UNTRACED references doesn't make your code unsafe. Using ADR does. But why not have an interface with C that makes use of the fact that VAR parameters are passed as pointers to C. e.g., C function f(int *ref p) can be declared as <*EXTERNAL*> f(VAR i: INTEGER) and this is still safe. On 16 Apr 2010, at 04:18, Jay K wrote: > Isn't making them unsafe? ADR? I'll try.. > > - Jay > > > To: jay.krell at cornell.edu > > Date: Fri, 16 Apr 2010 00:00:34 -0700 > > From: mika at async.async.caltech.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] Modula-3/C interop in Date/Time? > > > > I don't think there's anything unsafe about UNTRACED. > > > > It's DISPOSE that's unsafe... > > > > Mika > > > > Jay K writes: > > >--_cbaca81c-f322-4f31-8684-e7f171e67f3d_ > > >Content-Type: text/plain; charset="iso-2022-jp" > > >Content-Transfer-Encoding: 7bit > > > > > >But then unsafe, right? > > > > > > - Jay > > > > > >> From: hosking at cs.purdue.edu > > >> Date: Thu, 15 Apr 2010 22:06:14 -0400 > > >> To: rodney_bates at lcwb.coop > > >> CC: m3dev el at elegosoft.com > > >> Subject: Re: [M3devel] Modula-3/C interop in Date/Time? > > >> > > >> Indeed! UNTRACED. > > >> > > >> > > >> On 15 Apr 2010, at 18:44, Rodney M. Bates wrote: > > >> > > >> > Since these pointer variables are initialized by > > >> > C code and their referents are also provided by C code > > >> > as global variables, shouldn't the type be untraced? > > >> > > > >> > I suppose that, since they don't point into the traced > > >> > heap, the collector implementation we have would quietly > > >> > ignore them as roots. But that's relying on implementation- > > >> > dependent information. > > >> > > > >> > Also, if someone created a field of type Date.TimeZone, > > >> > (or an array of them) in a traced-heap-allocated object, > > > > which is a perfectly legitimate thing to do, what would > > >> > our collector do then? > > >> > > > >> > > > >> > > > >> > Jay K wrote: > > >> >> Is this legal/correct? > > >> >> > > >> >> > > >> >> Date.i3: > > >> >> TYPE TimeZone <: REFANY; > > >> >> VAR Local, UTC: TimeZone; (* granted, will maybe change these to extern *) > > >> >> > > >> >> > > >> >> Date.m3:? > > >> >> REVEAL TimeZone = BRANDED "Date.TimeZone" REF INTEGER; > > >> >> ? > > >> >> > > >> >> DatePosixC.c: > > >> >> static const int Local = 0& #59; > > >> >> static const int UTC = 1; > > >> >> extern const int const * const Date__Local = &Local; > > >> >> extern const int const * const Date__UTC = &UTC; > > >> >> ? > > >> >> > > >> >> - Jay > > >> > > > > > >--_cbaca81c-f322-4f31-8684-e7f171e67f3d_ > > >Content-Type: text/html; charset="iso-2022-jp" > > >Content-Transfer-Encoding: 7bit > > > > > > > > > > > > > > > > >But then unsafe, right?

- Jay

> From: hosking@cs.purdue.edu
> Date: Thu, 15 Apr 2010 22:06:14 -0400
> To: rodney_bates& > > >#64;lcwb.coop
> CC: m3devel@elegosoft.com
> Subject: Re: [M3devel] Modula-3/C interop in Date/Time?
>
> Indeed! UNTRACED.
>
> < > > >br>> On 15 Apr 2010, at 18:44, Rodney M. Bates wrote:
>
> > Since these pointer variables are initialized by
> & #38;#62; C code and their referents are also provided by C > > > code
> > as global variables, shouldn't the type be untraced?
> >
> > I suppose that, since they don't point into the traced
> > heap, the collect > > >or implementation we have would quietly
> > ignore them as roots. But that's relying on implementation-
> > dependent information.
> >
> > Also, if someon > > >e created a field of type Date.TimeZone,
> > > > > ; (or an array of them) in a traced-heap-allocated object,
> > which is a perfectly legitimate thing to do, what would
> > our collector do then?
> >
> > >> >
> >
> > Jay K wrote:
> >> Is this legal/correct?
> >>
> >>
> >> Date.i3:
> >> TYPE TimeZone > > > <: REFANY;
> >> VAR Local, UTC: TimeZone; (* granted, will maybe change these to extern *)
> >>
> >&# 38;#62;
> >> > > > Date.m3: 
> >> REVEAL TimeZone = BRANDED "Date.TimeZone" REF INTEGER;
> >>  
> >>
> >> DatePosixC.c:
> > >> >> static const int Local = 0;
> >> static const int UTC = 1;
> >> extern const int const * const Date__Local = &Local;
> > > > >> extern const int con st * const Dat > > > e__UTC = &UTC;
> >>  
> >>
> >> - Jay
>
> > > > > >--_cbaca81c-f322-4f31-8684-e7f171e67f3d_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Apr 16 16:45:41 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 16 Apr 2010 10:45:41 -0400 Subject: [M3devel] release engineering 5.8: trac issue 1005 (open array initializers) In-Reply-To: <20100416113814.xwn126mk800808kc@mail.elegosoft.com> References: <20100416113814.xwn126mk800808kc@mail.elegosoft.com> Message-ID: Here's the testcase: MODULE Main; IMPORT IO; <*UNUSED*> VAR a : ARRAY [0..0] OF CHAR := ARRAY OF CHAR {'a'}; <*UNUSED*> VAR b : ARRAY [0..0] OF CHAR := ARRAY OF CHAR {'b'}; <*UNUSED*> VAR c : ARRAY [0..0] OF CHAR := ARRAY OF CHAR {'c'}; <*UNUSED*> VAR d : ARRAY [0..0] OF CHAR := ARRAY OF CHAR {'d'}; BEGIN IO.Put("OK\n"); END Main. I looked into this a while back and have some understanding of what is going on. Still no fix yet. Note that this is weird code that does have a more concise workaround, which is probably why we don't see it often: MODULE Main; IMPORT IO; <*UNUSED*> VAR a := ARRAY [0,0] OF CHAR {'a'}; <*UNUSED*> VAR b := ARRAY [0,0] OF CHAR {'b'}; <*UNUSED*> VAR c := ARRAY [0,0] OF CHAR {'c'}; <*UNUSED*> VAR d := ARRAY [0,0] OF CHAR {'d'}; BEGIN IO.Put("OK\n"); END Main. The problem arises because in the first form the compiler tries to initialise a literal array constant for each of the array constructor expressions before assigning them to the variables. In the second form it initialises the variables directly from the elements of the constructor. Need to dig deeper. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 16 Apr 2010, at 05:38, Olaf Wagner wrote: > I'm currently reviewing the open issues again, and came across > > https://projects.elego.de/cm3/ticket/1005 > > Not sure if I've asked before, but do we need to solve this for this > release? The GC error seems strange: > > --- ../src/p2/p209/stderr.build 2009-06-29 21:47:53.000000000 +0200 > +++ ../src/p2/p209/AMD64_LINUX/stderr.build 2009-07-20 08:17:17.000000000 +0200 > @@ -0,0 +1,13 @@ > +o is 0x348 > +init_pc is 0x0 > +bias is 0x5c8 > +Target.Address.align is 0x40 > +Target.Byte is 0x8 > + > + > +*** > +*** runtime error: > +*** <*ASSERT*> failed. > +*** file "../src/misc/CG.m3", line 1077 > +*** > + > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Apr 16 16:46:41 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 16 Apr 2010 10:46:41 -0400 Subject: [M3devel] release engineering 5.8: trac issue 1005 (open array initializers) In-Reply-To: References: <20100416113814.xwn126mk800808kc@mail.elegosoft.com> Message-ID: <9B6A5ED8-BB05-4856-96AC-1A28C498C443@cs.purdue.edu> PS I don't use printouts when debugging. I use a debugger. There is never a need to put verbose debugging printouts into the source tree. They just litter the code. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 16 Apr 2010, at 05:58, Jay K wrote: > I believe Tony removed the print outs but imho they should be left in until the assertion failure is understood and fixed. They try to inform on what is going on when the assertion fails. > > - Jay > > > Date: Fri, 16 Apr 2010 11:38:14 +0200 > > From: wagner at elegosoft.com > > To: m3devel at elegosoft.com > > Subject: [M3devel] release engineering 5.8: trac issue 1005 (open array initializers) > > > > I'm currently reviewing the open issues again, and came across > > > > https://projects.elego.de/cm3/ticket/1005 > > > > Not sure if I've asked before, but do we need to solve this for this > > release? The GC error seems strange: > > > > --- ../src/p2/p209/stderr.build 2009-06-29 21:47:53.000000000 +0200 > > +++ ../src/p2/p209/AMD64_LINUX/stderr.build 2009-07-20 > > 08:17:17.000000000 +0200 > > @@ -0,0 +1,13 @@ > > +o is 0x348 > > +init_pc is 0x0 > > +bias is 0x5c8 > > +Target.Address.align is 0x40 > > +Target.Byte is 0x8 > > + > > + > > +*** > > +*** runtime error: > > +*** <*ASSERT*> failed. > > +*** file "../src/misc/CG.m3", line 1077 > > +*** > > + > > > > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Apr 16 17:04:49 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 16 Apr 2010 11:04:49 -0400 Subject: [M3devel] release engineering 5.8: code generator error for IP address initializers In-Reply-To: References: <20100416114509.eh8r662dwss44oo8@mail.elegosoft.com>, , <20100416125048.183752ukg4os0kgk@mail.elegosoft.com> Message-ID: <908A7AC8-565B-4749-A325-BE13F99F70D7@cs.purdue.edu> You are confusing open array types with array constructors. On 16 Apr 2010, at 08:15, Jay K wrote: > (back to the topic :) ) > > somewhat reduced case: > MODULE Main; > TYPE T1 = ARRAY [0..0] OF INTEGER; > CONST const: T1 = ARRAY OF INTEGER{2}; This is an array constructor. I suspect this is the same issue as in my previous e-mail. The following concise rewrite should work: CONST const = T1{2}; > BEGIN > END Main. > > The problem is two global integers are overlapping. > The open array size and its first element. > > new source -> compiling Main.m3 > "..\Main.m3", line 5: warning: not used (const) > m3front:cg:Init_int:NOT in_init: o: 32 s:32 value:2 <== > m3front:cg:Init_int:NOT in_init: o: 32 s:32 value:1 <== > m3front:cg:Init_int:NOT in_init: o: 384 s:32 value:3 > m3front:cg:Init_int:in_init: o: 32 s:32 value:1 > m3front:cg:Init_int:in_init: o: 32 s:32 value:2 > > Are these syntaxes legal? > This apparent mixing of open and fixed arrays? > > - Jay > > > > Date: Fri, 16 Apr 2010 12:50:48 +0200 > > From: wagner at elegosoft.com > > To: jay.krell at cornell.edu > > CC: m3devel at elegosoft.com > > Subject: RE: [M3devel] release engineering 5.8: code generator error for IP address initializers > > > > I agree. Regular expressions in quake would be great for regression tests. > > Perhaps for the next release? > > > > Olaf > > > > Quoting Jay K : > > > > > "aside": > > > > > > http://hudson.modula3.com:8080/job/cm3-test-m3tests-AMD64_FREEBSD/lastBuild/testReport/(root)/m3tests/p206__ARRAY_constructors_in_var_decls_using_named_open_array_types/ > > > > > > http://hudson.modula3.com:8080/job/cm3-test-m3tests-AMD64_FREEBSD/lastBuild/testReport/(root)/m3tests/r004__negative_size_for_an_open_array/ > > > > > > > > > It'd be nice if in Quake we had something regular expression-ish, so > > > that we could factor out the line numbers, such as e.g. to match > > > any decimal number. > > > > > > > > > Maybe just check for lines that start how we expect and cut them off > > > at some position. > > > That might be doable with today's Quake. > > > > > > > > > > > > - Jay > > > > > > > > > > > >> Date: Fri, 16 Apr 2010 11:45:09 +0200 > > >> From: wagner at elegosoft.com > > >> To: m3devel at elegosoft.com > > >> Subject: [M3devel] release engineering 5.8: code generator error > > >> for IP address initializers > > >> > > >> We also have this error, which should perhaps not be ignored? > > >> > > >> http://hudson.modula3.com:8080/job/cm3-test-m3tests-AMD64_FREEBSD/lastBuild/testReport/(root)/m3tests/p204__IP_address_initializers > > >> > > >> 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Apr 16 17:06:27 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 16 Apr 2010 11:06:27 -0400 Subject: [M3devel] assignability of fixed and open arrays, was: RE: release engineering 5.8: code generator error for IP address initializers In-Reply-To: <20100416145521.sywubhm3kgk440w4@mail.elegosoft.com> References: <20100416114509.eh8r662dwss44oo8@mail.elegosoft.com>, , <20100416125048.183752ukg4os0kgk@mail.elegosoft.com> <20100416145521.sywubhm3kgk440w4@mail.elegosoft.com> Message-ID: <5DB7169E-073B-480B-A043-046E08ED53DE@cs.purdue.edu> There is no open array in this code. Just a fixed array type and an array constructor. It is perfectly reasonable code. On 16 Apr 2010, at 08:55, Olaf Wagner wrote: > Quoting Jay K : > >> (back to the topic :) ) >> >> somewhat reduced case: >> >> MODULE Main; >> >> TYPE T1 = ARRAY [0..0] OF INTEGER; >> >> CONST const: T1 = ARRAY OF INTEGER{2}; >> BEGIN >> END Main. >> >> The problem is two global integers are overlapping. >> The open array size and its first element. >> >> Are these syntaxes legal? >> This apparent mixing of open and fixed arrays? > > You mean it would work for > > CONST const: T1 = ARRAY [0..0] OF INTEGER{2}; > > The type of const is no open array, but the fixed array A1. > So the question would be: is an open array (of the correct size) > assignable to a fixed array type? > > An expression e is assignable to a variable v if: > > * the type of e is assignable to the type of v, and > * the value of e is a member of the type of v, is not a local procedure, > and if it is an array, then it has the same shape as v. > > though this is not a variable assignment, but a constant definition. > Nonetheless, if that's assumed to be equivalent, then it would depend > on the definition of shape: does it include the length field or not? > > I'd tend to think it does not (since that's just a representation the > compiler (writer) chose), but only the number of dimensions and elements > should count. > > But this is certainly subtle and others may see it differently. > > 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 rcolebur at SCIRES.COM Fri Apr 16 23:07:04 2010 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Fri, 16 Apr 2010 17:07:04 -0400 Subject: [M3devel] example of bug in NetObj Stub Generator In-Reply-To: References: , , <7C7408D0-9A40-4988-BADA-A9FD8C15D388@cs.purdue.edu>, , Message-ID: Jay / Rodney / et al: I?ve attached a ZIP file containing a stripped-down source package and NT386 folder that demonstrates the problem I am having with the stub generator. The generated file ?NT386\CV_Server_T_v2.m3? is missing the import of the ?Date? interface. The source interface that I wrote is in ?src\CV_Server.i3?. Regards, Randy From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K Sent: Thursday, April 15, 2010 7:13 PM To: Coleburn, Randy; m3devel Subject: RE: [M3devel] Modula-3/C interop in Date/Time? Randy, I think I understand but yes please commit a small concrete example like in m3-sys/m3tests/src/p2/p237 or such. I think this is a bug in the stub generator. Probably time/date could workaround it with slight restructuring/renaming. But probably should fix the stub generator. While at it, maybe have it stop outputing unused stuff that triggers so many warnings... - Jay ________________________________ From: rcolebur at SCIRES.COM To: m3devel at elegosoft.com Date: Thu, 15 Apr 2010 18:10:44 -0400 Subject: Re: [M3devel] Modula-3/C interop in Date/Time? Jay: I?m still catching up after being in hospital, but noticed you are working on the Date.i3/m3 interface and module. There is a problem that I?d like to post on the newsgroup that may be related. I?m not sure if the problem is due to the way Date.i3/m3 is coded, or perhaps a problem in the network objects stub generator, but I thought whilst you are looking at Date.i3/m3 something might trigger in your mind about how to fix the problem. I have several interfaces that export a Network Object. Of course, these get processed by the network objects stub generator at compile time. For some of these, the generated files fail to compile due to Date.i3 not being listed in the IMPORT list. Since these offending modules are generated at compile time, it?s not a programming error in the new source package that is being compiled. The way I work around the problem is by editing the generated files after the compile fails. Namely, I go to the target folder (in this case NT386) and edit the generated m3 files by adding ?IMPORT Date;?, then recompile and all is well. Of course, the next time you erase the target folder, change the underlying interface, or run ?cm3 -clean?, the generated file has to be created again and you have to go thru the compile-edit-compile cycle again to repair the problem. If you are delivering source code to a customer, you then have to document the work-around for them so that they can get the package to compile. I reported this problem years ago, but that was back before we were tracking bugs using the new system. It could be that the way Date.i3/m3 is coded is causing the stub generator not to think it needs to import it, or it could be that the stub generator isn?t doing its job right in the first place. Now after saying all this, I know I should provide a concrete example. I?ll have to go back and see if I ever reduced the code to a smaller set that demonstrates the problem. Otherwise, I can?t give anyone the full source code because it was a ?work-for-hire? and I don?t have the right to publish these sources. Let me know if you want a concrete example and I?ll see what I can do. Regards, Randy From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K Sent: Thursday, April 15, 2010 5:26 PM To: Tony Cc: m3devel Subject: Re: [M3devel] Modula-3/C interop in Date/Time? Oops, right, of course. Important to get the things right I know to keep the question clear/narrow. - Jay ________________________________ From: hosking at cs.purdue.edu Date: Thu, 15 Apr 2010 12:55:52 -0400 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] Modula-3/C interop in Date/Time? Excepting that INTEGER is not the same as int on 64-bit platforms. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 15 Apr 2010, at 02:45, Jay K wrote: Is this legal/correct? Date.i3: TYPE TimeZone <: REFANY; VAR Local, UTC: TimeZone; (* granted, will maybe change these to extern *) Date.m3:? REVEAL TimeZone = BRANDED "Date.TimeZone" REF INTEGER; ? DatePosixC.c: static const int Local = 0; static const int UTC = 1; extern const int const * const Date__Local = &Local; extern const int const * const Date__UTC = &UTC; ? - Jay ________________________________ CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This email may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from reviewing, copying, using, disclosing or distributing to others the information in this email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require advance export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. ________________________________ CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This email may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from reviewing, copying, using, disclosing or distributing to others the information in this email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require advance export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: BugExample.zip Type: application/x-zip-compressed Size: 8839 bytes Desc: BugExample.zip URL: From jay.krell at cornell.edu Sat Apr 17 03:50:54 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 17 Apr 2010 01:50:54 +0000 Subject: [M3devel] release engineering 5.8: code generator error for IP address initializers In-Reply-To: <908A7AC8-565B-4749-A325-BE13F99F70D7@cs.purdue.edu> References: <20100416114509.eh8r662dwss44oo8@mail.elegosoft.com>, , <20100416125048.183752ukg4os0kgk@mail.elegosoft.com> , <908A7AC8-565B-4749-A325-BE13F99F70D7@cs.purdue.edu> Message-ID: There is this thing I read, where the types of values/constants are known without context. The left hand side does not change the type of the right. That confuses me here. It would imply the right is an open array. - Jay Subject: Re: [M3devel] release engineering 5.8: code generator error for IP address initializers From: hosking at cs.purdue.edu Date: Fri, 16 Apr 2010 11:04:49 -0400 CC: wagner at elegosoft.com; m3devel at elegosoft.com To: jay.krell at cornell.edu You are confusing open array types with array constructors. On 16 Apr 2010, at 08:15, Jay K wrote: (back to the topic :) ) somewhat reduced case: MODULE Main; TYPE T1 = ARRAY [0..0] OF INTEGER; CONST const: T1 = ARRAY OF INTEGER{2}; This is an array constructor. I suspect this is the same issue as in my previous e-mail. The following concise rewrite should work: CONST const = T1{2}; BEGIN END Main. The problem is two global integers are overlapping. The open array size and its first element. new source -> compiling Main.m3 "..\Main.m3", line 5: warning: not used (const) m3front:cg:Init_int:NOT in_init: o: 32 s:32 value:2 <== m3front:cg:Init_int:NOT in_init: o: 32 s:32 value:1 <== m3front:cg:Init_int:NOT in_init: o: 384 s:32 value:3 m3front:cg:Init_int:in_init: o: 32 s:32 value:1 m3front:cg:Init_int:in_init: o: 32 s:32 value:2 Are these syntaxes legal? This apparent mixing of open and fixed arrays? - Jay > Date: Fri, 16 Apr 2010 12:50:48 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] release engineering 5.8: code generator error for IP address initializers > > I agree. Regular expressions in quake would be great for regression tests. > Perhaps for the next release? > > Olaf > > Quoting Jay K : > > > "aside": > > > > http://hudson.modula3.com:8080/job/cm3-test-m3tests-AMD64_FREEBSD/lastBuild/testReport/(root)/m3tests/p206__ARRAY_constructors_in_var_decls_using_named_open_array_types/ > > > > http://hudson.modula3.com:8080/job/cm3-test-m3tests-AMD64_FREEBSD/lastBuild/testReport/(root)/m3tests/r004__negative_size_for_an_open_array/ > > > > > > It'd be nice if in Quake we had something regular expression-ish, so > > that we could factor out the line numbers, such as e.g. to match > > any decimal number. > > > > > > Maybe just check for lines that start how we expect and cut them off > > at some position. > > That might be doable with today's Quake. > > > > > > > > - Jay > > > > > > > >> Date: Fri, 16 Apr 2010 11:45:09 +0200 > >> From: wagner at elegosoft.com > >> To: m3devel at elegosoft.com > >> Subject: [M3devel] release engineering 5.8: code generator error > >> for IP address initializers > >> > >> We also have this error, which should perhaps not be ignored? > >> > >> http://hudson.modula3.com:8080/job/cm3-test-m3tests-AMD64_FREEBSD/lastBuild/testReport/(root)/m3tests/p204__IP_address_initializers > >> > >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Apr 17 03:48:44 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 17 Apr 2010 01:48:44 +0000 Subject: [M3devel] release engineering 5.8: trac issue 1005 (open array initializers) In-Reply-To: <9B6A5ED8-BB05-4856-96AC-1A28C498C443@cs.purdue.edu> References: <20100416113814.xwn126mk800808kc@mail.elegosoft.com>, , <9B6A5ED8-BB05-4856-96AC-1A28C498C443@cs.purdue.edu> Message-ID: I haven't found a viable debugger for Modula-3. Could be better now that I'm on Debian 5.0 though. gdb is now good, eveything is void*. VisualStudio/cdb/windbb are no good due to lack of CodeView information. I'll try m3gdb again, since upgrading to Debian 5.0. I'm keen on generating good CodeView information because of this. - Jay From: hosking at cs.purdue.edu Date: Fri, 16 Apr 2010 10:46:41 -0400 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] release engineering 5.8: trac issue 1005 (open array initializers) PS I don't use printouts when debugging. I use a debugger. There is never a need to put verbose debugging printouts into the source tree. They just litter the code. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 16 Apr 2010, at 05:58, Jay K wrote: I believe Tony removed the print outs but imho they should be left in until the assertion failure is understood and fixed. They try to inform on what is going on when the assertion fails. - Jay > Date: Fri, 16 Apr 2010 11:38:14 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] release engineering 5.8: trac issue 1005 (open array initializers) > > I'm currently reviewing the open issues again, and came across > > https://projects.elego.de/cm3/ticket/1005 > > Not sure if I've asked before, but do we need to solve this for this > release? The GC error seems strange: > > --- ../src/p2/p209/stderr.build 2009-06-29 21:47:53.000000000 +0200 > +++ ../src/p2/p209/AMD64_LINUX/stderr.build 2009-07-20 > 08:17:17.000000000 +0200 > @@ -0,0 +1,13 @@ > +o is 0x348 > +init_pc is 0x0 > +bias is 0x5c8 > +Target.Address.align is 0x40 > +Target.Byte is 0x8 > + > + > +*** > +*** runtime error: > +*** <*ASSERT*> failed. > +*** file "../src/misc/CG.m3", line 1077 > +*** > + > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Apr 17 10:05:39 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 17 Apr 2010 08:05:39 +0000 Subject: [M3devel] picking which files to package? Message-ID: Olaf, any chance you can limit what files are picked up to the $TARGET and src directories? The I386_DARWIN/AMD64_DARWIN packages I made contain each of other's files due to just picking up "everything". Maybe: iff -u -r1.26.2.51 make-dist.sh --- make-dist.sh 17 Apr 2010 03:55:43 -0000 1.26.2.51 +++ make-dist.sh 17 Apr 2010 08:05:13 -0000 @@ -338,12 +338,16 @@ ) > collection-${c}.html echo "collection-${c}.html" ARCHIVE="${STAGE}/cm3-bin-ws-${c}-${TARGET}-${CM3VERSION}-${DS}.tgz" + a="" + for b in ${PKGS}; do + a="${a} ${b}/src ${b}/${TARGET}" + done if [ -z "${NOARCHIVE}" -a "${c}" != "min" ]; then "${TAR}" --exclude '*.o' --exclude '*.mo' --exclude '*.io' \ --exclude '*/CVS/*' --exclude '*/CVS' --exclude '*~' \ --exclude '*.tar.*' --exclude '*.tgz' --exclude "*/${TARGET}/gcc" \ --exclude "*/${TARGET}/*/*" \ - -czf "${ARCHIVE}" collection-${c}.html install.sh setup.txt setup.cmd ${PKGS} + -czf "${ARCHIVE}" collection-${c}.html install.sh setup.txt setup.cmd ${a} ls -l "${ARCHIVE}" fi done - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Apr 17 06:26:59 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 17 Apr 2010 04:26:59 +0000 Subject: [M3devel] ROUND vs. FLOOR in ThreadPThread.m3 nano vs. micro time conversions? Message-ID: I've gone ahead and "rewritten" this code (it's only a few lines), and I removed this distinction. New form uses modf to split floating point at the decimal point and then multiplies the fractional part by a million (struct timeval) or a billion (struct timespec). Should be equivalent to seconds = (int)floatseconds; microsseconds = (floatseconds - seconds) * billion or million or such I ended up not using the C99 stuff. Sometimes we know the time is less than a second and greater than 0 and so just pass around a microsecond or nanosecond count. Hm. Maybe it has to do with negative times? Rounding down vs. toward zero? I'll probably rereread the code with negative times in mind. Not too worried, as the select uses in the thread code doesn't pass negative times, gettimeofday can't return a negative time, the user thread scheduling intervals I believe are all positive, etc. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Subject: ROUND vs. FLOOR in ThreadPThread.m3 nano vs. micro time conversions? Date: Fri, 9 Apr 2010 10:52:09 +0000 Why does UTimeFromTime use FLOOR but ToNTime uses ROUND? PROCEDURE ToNTime (n: LONGREAL; VAR ts: Utime.struct_timespec) = BEGIN ts.tv_sec := TRUNC(n); ts.tv_nsec := ROUND((n - FLOAT(ts.tv_sec, LONGREAL)) * 1.0D9); END ToNTime; TYPE UTime = Utime.struct_timeval; PROCEDURE UTimeFromTime (time: Time.T): UTime = VAR floor := FLOOR(time); BEGIN RETURN UTime{floor, FLOOR(1.0D6 * (time - FLOAT(floor, LONGREAL)))}; END UTimeFromTime; I've changed this code to pass doubles to C and do the conversion there. To reduce/eliminate use of cloned headers. For ROUND I'm using C99: /* C99, very portable */ long lround(double); long long llround(double); #ifdef __CYGWIN__ #define ROUND lround #else #define ROUND llround #endif typedef double FloatSeconds, LONGREAL; typedef struct timeval MicrosecondsStruct_t; #define FLOAT(value, type) ((type)value) #define FLOOR floor static MicrosecondsStruct_t* FloatSecondsToNanosecondsStruct(LONGREAL n, MicrosecondsStruct_t* ts) { ts->tv_sec = (time_t)n; ts->tv_nsec = ROUND((n - FLOAT(ts->tv_sec, LONGREAL)) * 1.0E9); return ts; } static MicrosecondsStruct_t* FloatSecondsToMicrosecondsStruct(FloatSeconds timeout, MicrosecondsStruct_t* utime) { LONGINT sec = FLOOR(timeout); utime->tv_sec = (time_t)sec; utime->tv_usec = (suseconds_t)FLOOR(1.0E6 * (timeout - FLOAT(sec, LONGREAL))); return utime; } Just arbitrarily a little more correct in the nano case vs. the micro case? Matters little? Would matter more for micro due to lower resolution? Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Apr 17 04:31:25 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 17 Apr 2010 02:31:25 +0000 Subject: [M3devel] release engineering 5.8: trac issue 1005 (open array initializers) In-Reply-To: <9B6A5ED8-BB05-4856-96AC-1A28C498C443@cs.purdue.edu> References: <20100416113814.xwn126mk800808kc@mail.elegosoft.com>, , <9B6A5ED8-BB05-4856-96AC-1A28C498C443@cs.purdue.edu> Message-ID: There is another vague philosophical point I should maybe explore/teach here. The vaguer I make it, the more irrefutable it is. :) "Logging has a place". And debuggers do too. I have seen countless examples where logging exists, in some "reasonable" volume bugs are often largly or completely diagnosed from a log alone getting a debugger to the right point would be quite difficult Logging is always "in situ" and often enabled proactively -- all the time. That is, no need to figure out exactly which command line to run, where to insert the debugger command, no need to try to keep temp files, etc. Very good example: Our Hudson/Tinderbox jobs. Callstacks upon assertion failures are a form of logging. Would be even better if they showed the local variables of every frame. Maybe expanding pointers one level. I often make the prints subject to whether or not an upcoming assertion is going to fail. There are counterpoints, of course. Logging wastes time and space. It makes the source code bigger, the object code bigger. When it is enabled it slows down runtime and usually "wastes" space to store the logs. Except when they end up used. The vast majority of logged date goes unread. You can't log everything. Good debuggers show things at a much lower level than most logging. (Except gdb on Debian 4.0 can't do anything, and CodeView-based debuggers against Modula-3 show very little...) I'll have to try m3gdb again, on Debian 5.0. And generate CodeView information. The CodeView stuff I consider pretty high priority. I've done a fair amount of research and am better prepared to implement it than previously. A C generating backend has about the same value and more. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu CC: m3devel at elegosoft.com Subject: RE: [M3devel] release engineering 5.8: trac issue 1005 (open array initializers) Date: Sat, 17 Apr 2010 01:48:44 +0000 I haven't found a viable debugger for Modula-3. Could be better now that I'm on Debian 5.0 though. gdb is now good, eveything is void*. VisualStudio/cdb/windbb are no good due to lack of CodeView information. I'll try m3gdb again, since upgrading to Debian 5.0. I'm keen on generating good CodeView information because of this. - Jay From: hosking at cs.purdue.edu Date: Fri, 16 Apr 2010 10:46:41 -0400 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] release engineering 5.8: trac issue 1005 (open array initializers) PS I don't use printouts when debugging. I use a debugger. There is never a need to put verbose debugging printouts into the source tree. They just litter the code. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 16 Apr 2010, at 05:58, Jay K wrote: I believe Tony removed the print outs but imho they should be left in until the assertion failure is understood and fixed. They try to inform on what is going on when the assertion fails. - Jay > Date: Fri, 16 Apr 2010 11:38:14 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] release engineering 5.8: trac issue 1005 (open array initializers) > > I'm currently reviewing the open issues again, and came across > > https://projects.elego.de/cm3/ticket/1005 > > Not sure if I've asked before, but do we need to solve this for this > release? The GC error seems strange: > > --- ../src/p2/p209/stderr.build 2009-06-29 21:47:53.000000000 +0200 > +++ ../src/p2/p209/AMD64_LINUX/stderr.build 2009-07-20 > 08:17:17.000000000 +0200 > @@ -0,0 +1,13 @@ > +o is 0x348 > +init_pc is 0x0 > +bias is 0x5c8 > +Target.Address.align is 0x40 > +Target.Byte is 0x8 > + > + > +*** > +*** runtime error: > +*** <*ASSERT*> failed. > +*** file "../src/misc/CG.m3", line 1077 > +*** > + > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Apr 17 12:50:34 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 17 Apr 2010 10:50:34 +0000 Subject: [M3devel] new target names -- SOLsun vs. SOLgnu? Message-ID: If we have targets, say, I386_NT, I386_CYGWIN, I386_MINGW, I386_LINUX, I386_FREEBSD, I386_NETBSD, SPARC32_SOLARIS or SPARC_SOLARIS..how does one capture the SOLsun vs. SOLgnu difference? SPARC32_SOLARIS_SUN vs. SPARC32_SOLARIS_GNU? SPARC_SOLARIS_SUNCC, SPARC_SOLARIS_GCC? "target is underscore separated list of relevant names, usually two but not limited to two"? Drop SOLgnu and just equate SPARC32_SOLARIS with SOLsun? Given that the reason for SOLgnu was because cc was not bundled with OS at some point? But now gcc and cc are both bundled as I understand! Do some sort of autoconfig, sensitive to the CC environment variable? That's actually pretty easy and pretty cheap. Not a terrible idea. I'm not really pushing hard on this topic, just that I want to cross build Cygwin from non-NT and was hitting minor problems. Mainly I want to see if Cygwin pthreads works now, now that the hanging test case got "rewritten", so I can drop the SchedulerPosix.m3 file which duplicates content verbatim out of ThreadPThread.m3.. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Apr 17 10:31:05 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 17 Apr 2010 08:31:05 +0000 Subject: [M3devel] select vs. poll? Message-ID: It looks to me like poll is usually preferred over select? It appears to be standard and widely available. Appears to be *BSD, Solaris, Linux, Interix, AIX, Irix. At least searching the web and checking headers. It has no limit on the number or value of file descriptors waited on. It does use more memory for its parameters and more time to construct and read them. However I believe we only ever select/poll either one file at a time on pthreads one file per thread on user threads There are other better mechanisms -- /dev/poll on Solaris, kqueue on FreeBSD and maybe others, epoll on Linux. Though these are mostly (completely?) concerned with scaling to waiting on large number of file descriptors. I think I'll change over to poll very soon. I haven't yet figured out if select's read/write/except maps directly to poll's flags. I'm guessing: select read => poll POLLIN or maybe POLLPRI also? select write => poll POLLOUT select except => POLLERR or maybe POLLHUP also? I haven't yet found a description of "error conditions" with respect to select. Still looking. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Apr 17 04:44:39 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 17 Apr 2010 02:44:39 +0000 Subject: [M3devel] Modula-3/C interop in Date/Time? In-Reply-To: <81B495C9-A0B2-4884-A6FC-5D928FC38340@cs.purdue.edu> References: , ,,<4BC796B7.7090707@lcwb.coop>, , , , , , , <20100416070034.9C0911A20EB@async.async.caltech.edu>, , <81B495C9-A0B2-4884-A6FC-5D928FC38340@cs.purdue.edu> Message-ID: The use case is the TimeZone's in DatePosix.m3. It's not a big deal. There are just two constant timezones, "local", and "utc", identified by references to integers: NIL, ^ = 1 and ^ = 0. Where NIL is interpreted as 0 or 1. It could just be an enum, but the public type is REFANY and it is revealed in the Win32 flavor to actually be a reference to something else. I could maybe change that. But what is the effect on pickles either way? The Win32 one isn't picklable in either case?? I'm not sure. So Timezone isn't portably pickable? And therefore pickles of Posix timezones can be broken? If they were to be pickled, I think the representation is dubious -- probably should pickle the "offset" from GMT/UTC, not 0 or 1. The Win32 code is also dubious given evolution of the Win32 API over the years. It is more flexible now and I wonder if that implies the old API was insufficient. (Though "local" can change in time, not really "constant", as the daylight savings cutoff is crossed, or indeed when I travel with a computer and stuff says running but "asleep" and then "resumed". I'm quite suspicious that lots of code doesn't account for timezone changes. I'm also quite suspicious of any code that does anything timezone sensitive or uses "local" time for anything. Using GMT/UTC for everything, except display, is the way to go. It makes things vastly simpler and better defined. Could be that Unix/Posixy stuff is generally ok. Could be just an historical bogus favoring of localtime on PCs (and Macs?).) I actually strongly suspect as well that we can get by with just the one Posix implementation of this stuff, no BSD, no Win32. In particular, msvcr*.dll does expose tzname, timezone, daylight. Besides of course "small" localtime/gmtime. Have to think though "Time" vs. "Date". Win32 epoch is earlier, which is useful for representating dates in the past. Basically "this stuff" is more about "Date" and less about "Time", though they interact. I'm pretty sure we have bugs as well where we assume the current "daylight" status applies to all times/dates. Switching to "time64" is part of the equation. Maybe I should attack more from that angle. Make things work for Date{year := 2040} and see what all that implies. - Jay From: hosking at cs.purdue.edu Date: Fri, 16 Apr 2010 10:30:48 -0400 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] Modula-3/C interop in Date/Time? What is the use-case here? Merely having UNTRACED references doesn't make your code unsafe. Using ADR does. But why not have an interface with C that makes use of the fact that VAR parameters are passed as pointers to C. e.g., C function f(int *ref p) can be declared as <*EXTERNAL*> f(VAR i: INTEGER) and this is still safe. On 16 Apr 2010, at 04:18, Jay K wrote: Isn't making them unsafe? ADR? I'll try.. - Jay > To: jay.krell at cornell.edu > Date: Fri, 16 Apr 2010 00:00:34 -0700 > From: mika at async.async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Modula-3/C interop in Date/Time? > > I don't think there's anything unsafe about UNTRACED. > > It's DISPOSE that's unsafe... > > Mika > > Jay K writes: > >--_cbaca81c-f322-4f31-8684-e7f171e67f3d_ > >Content-Type: text/plain; charset="iso-2022-jp" > >Content-Transfer-Encoding: 7bit > > > >But then unsafe, right? > > > > - Jay > > > >> From: hosking at cs.purdue.edu > >> Date: Thu, 15 Apr 2010 22:06:14 -0400 > >> To: rodney_bates at lcwb.coop > >> CC: m3dev el at elegosoft.com > >> Subject: Re: [M3devel] Modula-3/C interop in Date/Time? > >> > >> Indeed! UNTRACED. > >> > >> > >> On 15 Apr 2010, at 18:44, Rodney M. Bates wrote: > >> > >> > Since these pointer variables are initialized by > >> > C code and their referents are also provided by C code > >> > as global variables, shouldn't the type be untraced? > >> > > >> > I suppose that, since they don't point into the traced > >> > heap, the collector implementation we have would quietly > >> > ignore them as roots. But that's relying on implementation- > >> > dependent information. > >> > > >> > Also, if someone created a field of type Date.TimeZone, > >> > (or an array of them) in a traced-heap-allocated object, > > > which is a perfectly legitimate thing to do, what would > >> > our collector do then? > >> > > >> > > >> > > >> > Jay K wrote: > >> >> Is this legal/correct? > >> >> > >> >> > >> >> Date.i3: > >> >> TYPE TimeZone <: REFANY; > >> >> VAR Local, UTC: TimeZone; (* granted, will maybe change these to extern *) > >> >> > >> >> > >> >> Date.m3:? > >> >> REVEAL TimeZone = BRANDED "Date.TimeZone" REF INTEGER; > >> >> ? > >> >> > >> >> DatePosixC.c: > >> >> static const int Local = 0& #59; > >> >> static const int UTC = 1; > >> >> extern const int const * const Date__Local = &Local; > >> >> extern const int const * const Date__UTC = &UTC; > >> >> ? > >> >> > >> >> - Jay > >> > > > >--_cbaca81c-f322-4f31-8684-e7f171e67f3d_ > >Content-Type: text/html; charset="iso-2022-jp" > >Content-Transfer-Encoding: 7bit > > > > > > > > > > >But then unsafe, right?

- Jay

> From: hosking@cs.purdue.edu
> Date: Thu, 15 Apr 2010 22:06:14 -0400
> To: rodney_bates& > >#64;lcwb.coop
> CC: m3devel@elegosoft.com
> Subject: Re: [M3devel] Modula-3/C interop in Date/Time?
>
> Indeed! UNTRACED.
>
> < > >br>> On 15 Apr 2010, at 18:44, Rodney M. Bates wrote:
>
> > Since these pointer variables are initialized by
> & #38;#62; C code and their referents are also provided by C > > code
> > as global variables, shouldn't the type be untraced?
> >
> > I suppose that, since they don't point into the traced
> > heap, the collect > >or implementation we have would quietly
> > ignore them as roots. But that's relying on implementation-
> > dependent information.
> >
> > Also, if someon > >e created a field of type Date.TimeZone,
> > > > ; (or an array of them) in a traced-heap-allocated object,
> > which is a perfectly legitimate thing to do, what would
> > our collector do then?
> >
> >> >
> >
> > Jay K wrote:
> >> Is this legal/correct?
> >>
> >>
> >> Date.i3:
> >> TYPE TimeZone > > <: REFANY;
> >> VAR Local, UTC: TimeZone; (* granted, will maybe change these to extern *)
> >>
> >&# 38;#62;
> >> > > Date.m3: 
> >> REVEAL TimeZone = BRANDED "Date.TimeZone" REF INTEGER;
> >>  
> >>
> >> DatePosixC.c:
> >> >> static const int Local = 0;
> >> static const int UTC = 1;
> >> extern const int const * const Date__Local = &Local;
> > > >> extern const int con st * const Dat > > e__UTC = &UTC;
> >>  
> >>
> >> - Jay
>
> > > >--_cbaca81c-f322-4f31-8684-e7f171e67f3d_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sat Apr 17 13:22:14 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 17 Apr 2010 13:22:14 +0200 Subject: [M3devel] picking which files to package? In-Reply-To: References: Message-ID: <20100417132214.a2z13qxcoc8g0gs4@mail.elegosoft.com> You need to set STAGE differently if you want to run make-dist for different targets on the same machine. It's been done for SOLgnu and SOLsun, too. If you really want to build concurrently, you also need to change INSTBASE before sourcing defs.sh. Olaf Quoting Jay K : > > Olaf, any chance you can limit what files are picked up to the > $TARGET and src directories? > The I386_DARWIN/AMD64_DARWIN packages I made contain each of other's files > due to just picking up "everything". > > Maybe: > > iff -u -r1.26.2.51 make-dist.sh > --- make-dist.sh 17 Apr 2010 03:55:43 -0000 1.26.2.51 > +++ make-dist.sh 17 Apr 2010 08:05:13 -0000 > @@ -338,12 +338,16 @@ > ) > collection-${c}.html > echo "collection-${c}.html" > ARCHIVE="${STAGE}/cm3-bin-ws-${c}-${TARGET}-${CM3VERSION}-${DS}.tgz" > + a="" > + for b in ${PKGS}; do > + a="${a} ${b}/src ${b}/${TARGET}" > + done > if [ -z "${NOARCHIVE}" -a "${c}" != "min" ]; then > "${TAR}" --exclude '*.o' --exclude '*.mo' --exclude '*.io' \ > --exclude '*/CVS/*' --exclude '*/CVS' --exclude '*~' \ > --exclude '*.tar.*' --exclude '*.tgz' --exclude "*/${TARGET}/gcc" \ > --exclude "*/${TARGET}/*/*" \ > - -czf "${ARCHIVE}" collection-${c}.html install.sh setup.txt > setup.cmd ${PKGS} > + -czf "${ARCHIVE}" collection-${c}.html install.sh setup.txt > setup.cmd ${a} > ls -l "${ARCHIVE}" > fi > done > > > - Jay > -- 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 Sat Apr 17 13:55:39 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 17 Apr 2010 13:55:39 +0200 Subject: [M3devel] releng 5.8 for I386_DARWIN In-Reply-To: References: <20100416141032.doe6pi088o0w8gsk@mail.elegosoft.com>, , <20100416150010.7yzjrn8dwkkwowcc@mail.elegosoft.com> Message-ID: <20100417135539.8bjp68negwk480ks@mail.elegosoft.com> Quoting Jay K : > I just made a somewhat significant change in head and then copied > head to release in m3-sys/cm3 to deal with this. > > I get other problems on AMD64_DARWIN I believe unrelated. > > I'll keep looking. Let's not put that in RC5 unless it's really broken for other targets, too. In this case we have to remove the existing packages and rebuild everything. I'd like to avoid that. I've moved the Darwin files into post-RC5. I'd really like to finish this release... Olaf > From: jay.krell at cornell.edu > To: wagner at elegosoft.com > Subject: RE: releng 5.8 for I386_DARWIN > Date: Fri, 16 Apr 2010 13:13:49 +0000 > > > > drat, AMD64_DARWIN gets far, but then complains about bad .M3SHIP files. > > - Jay -- 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 jay.krell at cornell.edu Sat Apr 17 14:03:17 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 17 Apr 2010 12:03:17 +0000 Subject: [M3devel] releng 5.8 for I386_DARWIN In-Reply-To: <20100417135539.8bjp68negwk480ks@mail.elegosoft.com> References: <20100416141032.doe6pi088o0w8gsk@mail.elegosoft.com>, , <20100416150010.7yzjrn8dwkkwowcc@mail.elegosoft.com>, , <20100417135539.8bjp68negwk480ks@mail.elegosoft.com> Message-ID: I don't actually understand the .M3SHIP breakage. Instead I made the code a bit more obviously correct -- apply some path canonicalization. I can understand that root/bin/../lib would prevent replacement with LIB_INSTALL, but BIN_INSTALL or INSTALL_ROOT should still have been unresolved. There's still an inconsistency in that all but one of the unresolved paths do not end in a slash. But it should be ok. Just that that the slash will or not be unresolved along with the rest. I understand it's not a great situation. I'm going to rebuild I386_DARWIN and AMD64_DARWIN, sequentially. - Jay > Date: Sat, 17 Apr 2010 13:55:39 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: RE: releng 5.8 for I386_DARWIN > > Quoting Jay K : > > > I just made a somewhat significant change in head and then copied > > head to release in m3-sys/cm3 to deal with this. > > > > I get other problems on AMD64_DARWIN I believe unrelated. > > > > I'll keep looking. > > Let's not put that in RC5 unless it's really broken for other targets, too. > In this case we have to remove the existing packages and rebuild everything. > I'd like to avoid that. > > I've moved the Darwin files into post-RC5. > > I'd really like to finish this release... > > Olaf > > > From: jay.krell at cornell.edu > > To: wagner at elegosoft.com > > Subject: RE: releng 5.8 for I386_DARWIN > > Date: Fri, 16 Apr 2010 13:13:49 +0000 > > > > > > > > drat, AMD64_DARWIN gets far, but then complains about bad .M3SHIP files. > > > > - Jay > -- > 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 jay.krell at cornell.edu Sat Apr 17 14:08:45 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 17 Apr 2010 12:08:45 +0000 Subject: [M3devel] picking which files to package? In-Reply-To: <20100417132214.a2z13qxcoc8g0gs4@mail.elegosoft.com> References: , <20100417132214.a2z13qxcoc8g0gs4@mail.elegosoft.com> Message-ID: Can you maybe append TARGET to $STAGE, $INSTBASE, etc. consistently, as needed, on all platforms? - There are other bi/multiarch platforms? I'm not sure how widely that notion has taken hold, e.g. AMD64_LINUX? - For when we extensively cross build. (soon?) I'll run sequentially for now. - Jay > Date: Sat, 17 Apr 2010 13:22:14 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: picking which files to package? > > You need to set STAGE differently if you want to run make-dist > for different targets on the same machine. It's been done for SOLgnu and > SOLsun, too. If you really want to build concurrently, you also need to > change INSTBASE before sourcing defs.sh. > > Olaf > > Quoting Jay K : > > > > > Olaf, any chance you can limit what files are picked up to the > > $TARGET and src directories? > > The I386_DARWIN/AMD64_DARWIN packages I made contain each of other's files > > due to just picking up "everything". > > > > Maybe: > > > > iff -u -r1.26.2.51 make-dist.sh > > --- make-dist.sh 17 Apr 2010 03:55:43 -0000 1.26.2.51 > > +++ make-dist.sh 17 Apr 2010 08:05:13 -0000 > > @@ -338,12 +338,16 @@ > > ) > collection-${c}.html > > echo "collection-${c}.html" > > ARCHIVE="${STAGE}/cm3-bin-ws-${c}-${TARGET}-${CM3VERSION}-${DS}.tgz" > > + a="" > > + for b in ${PKGS}; do > > + a="${a} ${b}/src ${b}/${TARGET}" > > + done > > if [ -z "${NOARCHIVE}" -a "${c}" != "min" ]; then > > "${TAR}" --exclude '*.o' --exclude '*.mo' --exclude '*.io' \ > > --exclude '*/CVS/*' --exclude '*/CVS' --exclude '*~' \ > > --exclude '*.tar.*' --exclude '*.tgz' --exclude "*/${TARGET}/gcc" \ > > --exclude "*/${TARGET}/*/*" \ > > - -czf "${ARCHIVE}" collection-${c}.html install.sh setup.txt > > setup.cmd ${PKGS} > > + -czf "${ARCHIVE}" collection-${c}.html install.sh setup.txt > > setup.cmd ${a} > > ls -l "${ARCHIVE}" > > fi > > done > > > > > > - Jay > > > > > > -- > 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 Sat Apr 17 14:34:34 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 17 Apr 2010 14:34:34 +0200 Subject: [M3devel] picking which files to package? In-Reply-To: References: , <20100417132214.a2z13qxcoc8g0gs4@mail.elegosoft.com> Message-ID: <20100417143434.lbf1epa6ec4kogsg@mail.elegosoft.com> Quoting Jay K : > > Can you maybe append TARGET to $STAGE, $INSTBASE, etc. consistently, > as needed, on all platforms? > - There are other bi/multiarch platforms? I'm not sure how widely > that notion has taken hold, e.g. AMD64_LINUX? > > - For when we extensively cross build. (soon?) > > I'll run sequentially for now. We can do that for the next builds. But let's be careful not to break the release tooling again. Olaf > - Jay > > >> Date: Sat, 17 Apr 2010 13:22:14 +0200 >> From: wagner at elegosoft.com >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: Re: picking which files to package? >> >> You need to set STAGE differently if you want to run make-dist >> for different targets on the same machine. It's been done for SOLgnu and >> SOLsun, too. If you really want to build concurrently, you also need to >> change INSTBASE before sourcing defs.sh. >> >> Olaf >> >> Quoting Jay K : >> >> > >> > Olaf, any chance you can limit what files are picked up to the >> > $TARGET and src directories? >> > The I386_DARWIN/AMD64_DARWIN packages I made contain each of other's files >> > due to just picking up "everything". >> > >> > Maybe: >> > >> > iff -u -r1.26.2.51 make-dist.sh >> > --- make-dist.sh 17 Apr 2010 03:55:43 -0000 1.26.2.51 >> > +++ make-dist.sh 17 Apr 2010 08:05:13 -0000 >> > @@ -338,12 +338,16 @@ >> > ) > collection-${c}.html >> > echo "collection-${c}.html" >> > ARCHIVE="${STAGE}/cm3-bin-ws-${c}-${TARGET}-${CM3VERSION}-${DS}.tgz" >> > + a="" >> > + for b in ${PKGS}; do >> > + a="${a} ${b}/src ${b}/${TARGET}" >> > + done >> > if [ -z "${NOARCHIVE}" -a "${c}" != "min" ]; then >> > "${TAR}" --exclude '*.o' --exclude '*.mo' --exclude '*.io' \ >> > --exclude '*/CVS/*' --exclude '*/CVS' --exclude '*~' \ >> > --exclude '*.tar.*' --exclude '*.tgz' --exclude "*/${TARGET}/gcc" \ >> > --exclude "*/${TARGET}/*/*" \ >> > - -czf "${ARCHIVE}" collection-${c}.html install.sh setup.txt >> > setup.cmd ${PKGS} >> > + -czf "${ARCHIVE}" collection-${c}.html install.sh setup.txt >> > setup.cmd ${a} >> > ls -l "${ARCHIVE}" >> > fi >> > done >> > >> > >> > - Jay >> > >> >> >> >> -- >> 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 Sat Apr 17 14:53:55 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 17 Apr 2010 08:53:55 -0400 Subject: [M3devel] release engineering 5.8: code generator error for IP address initializers In-Reply-To: References: <20100416114509.eh8r662dwss44oo8@mail.elegosoft.com>, , <20100416125048.183752ukg4os0kgk@mail.elegosoft.com> , <908A7AC8-565B-4749-A325-BE13F99F70D7@cs.purdue.edu> Message-ID: <64998360-2467-4204-9967-8C0B158FECC5@cs.purdue.edu> The RHS is a constant array *constructor*. On 16 Apr 2010, at 21:50, Jay K wrote: > There is this thing I read, where the types of values/constants are known without context. > The left hand side does not change the type of the right. > That confuses me here. It would imply the right is an open array. > > - Jay > > > Subject: Re: [M3devel] release engineering 5.8: code generator error for IP address initializers > From: hosking at cs.purdue.edu > Date: Fri, 16 Apr 2010 11:04:49 -0400 > CC: wagner at elegosoft.com; m3devel at elegosoft.com > To: jay.krell at cornell.edu > > You are confusing open array types with array constructors. > > On 16 Apr 2010, at 08:15, Jay K wrote: > > (back to the topic :) ) > > somewhat reduced case: > MODULE Main; > TYPE T1 = ARRAY [0..0] OF INTEGER; > CONST const: T1 = ARRAY OF INTEGER{2}; > > This is an array constructor. > > I suspect this is the same issue as in my previous e-mail. The following concise rewrite should work: > > CONST const = T1{2}; > > BEGIN > END Main. > > The problem is two global integers are overlapping. > The open array size and its first element. > > new source -> compiling Main.m3 > "..\Main.m3", line 5: warning: not used (const) > m3front:cg:Init_int:NOT in_init: o: 32 s:32 value:2 <== > m3front:cg:Init_int:NOT in_init: o: 32 s:32 value:1 <== > m3front:cg:Init_int:NOT in_init: o: 384 s:32 value:3 > m3front:cg:Init_int:in_init: o: 32 s:32 value:1 > m3front:cg:Init_int:in_init: o: 32 s:32 value:2 > > Are these syntaxes legal? > This apparent mixing of open and fixed arrays? > > - Jay > > > > Date: Fri, 16 Apr 2010 12:50:48 +0200 > > From: wagner at elegosoft.com > > To: jay.krell at cornell.edu > > CC: m3devel at elegosoft.com > > Subject: RE: [M3devel] release engineering 5.8: code generator error for IP address initializers > > > > I agree. Regular expressions in quake would be great for regression tests. > > Perhaps for the next release? > > > > Olaf > > > > Quoting Jay K : > > > > > "aside": > > > > > > http://hudson.modula3.com:8080/job/cm3-test-m3tests-AMD64_FREEBSD/lastBuild/testReport/(root)/m3tests/p206__ARRAY_constructors_in_var_decls_using_named_open_array_types/ > > > > > > http://hudson.modula3.com:8080/job/cm3-test-m3tests-AMD64_FREEBSD/lastBuild/testReport/(root)/m3tests/r004__negative_size_for_an_open_array/ > > > > > > > > > It'd be nice if in Quake we had something regular expression-ish, so > > > that we could factor out the line numbers, such as e.g. to match > > > any decimal number. > > > > > > > > > Maybe just check for lines that start how we expect and cut them off > > > at some position. > > > That might be doable with today's Quake. > > > > > > > > > > > > - Jay > > > > > > > > > > > >> Date: Fri, 16 Apr 2010 11:45:09 +0200 > > >> From: wagner at elegosoft.com > > >> To: m3devel at elegosoft.com > > >> Subject: [M3devel] release engineering 5.8: code generator error > > >> for IP address initializers > > >> > > >> We also have this error, which should perhaps not be ignored? > > >> > > >> http://hudson.modula3.com:8080/job/cm3-test-m3tests-AMD64_FREEBSD/lastBuild/testReport/(root)/m3tests/p204__IP_address_initializers > > >> > > >> 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 > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Sat Apr 17 02:41:34 2010 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sat, 17 Apr 2010 00:41:34 +0000 (GMT) Subject: [M3devel] About problem compiling with cm3-bin-core-AMD64_LINUX-5.8.5-RC5 Message-ID: <493637.42836.qm@web23603.mail.ird.yahoo.com> Hi all: I think I made a silly mistake I did compile the d5.7 tree so I guess m3cc is different than of the current RC5 m3cc. If you have a md5sum of RC5 please put it in the web page. I'm rebuilding it again now with the RC5 tree, so far it looks good. Thanks for your attention, --- El vie, 16/4/10, Daniel Alejandro Benavides D. escribi?: > De: Daniel Alejandro Benavides D. > Asunto: About problem compiling with cm3-bin-core-AMD64_LINUX-5.8.5-RC5 > Para: m3devel at elegosoft.com > Fecha: viernes, 16 de abril, 2010 19:18 > Hi all: > I'm trying to build in kubuntu karmic 9.10 the RC5 but got > early after compiling succesfully m3cc in this output a > problem at: > "internal compiler error: in emit_move_insn, at > expr.c:3379 > > > > > " > The file I downloaded has the following md5sum, is that > correct?: > d9ac8a12cdeccb8b5d7ee856c113366f > cm3-bin-core-AMD64_LINUX-5.8.5-RC5.tgz > > Could you suggest me something to do here? > Thanks in advance > > root at mm01:/home/dabenavidesd/code/cm3/scripts# ./do-pkg.sh > buildship m3core libm3 m3middle m3linker m3front sysutils > m3quake m3objfile m3back cm3 > > > > /home/dabenavidesd/code/cm3/scripts/pkgmap.sh -c > "/usr/local/cm3/bin/cm3 -build > -DROOT='/home/dabenavidesd/code/cm3' > -DCM3_VERSION_TEXT='d5.7.0' -DCM3_VERSION_NUMBER='050700' > -DCM3_LAST_CHANGED='2008-03-16' && > /usr/local/cm3/bin/cm3 -ship > -DROOT='/home/dabenavidesd/code/cm3' > -DCM3_VERSION_TEXT='d5.7.0' -DCM3_VERSION_NUMBER='050700' > -DCM3_LAST_CHANGED='2008-03-16' " m3core libm3 m3middle > m3linker m3front sysutils m3quake m3objfile m3back cm3 > > === package /home/dabenavidesd/code/cm3/m3-libs/m3core > === > > > +++ /usr/local/cm3/bin/cm3 -build > -DROOT='/home/dabenavidesd/code/cm3' > -DCM3_VERSION_TEXT='d5.7.0' -DCM3_VERSION_NUMBER='050700' > -DCM3_LAST_CHANGED='2008-03-16' && > /usr/local/cm3/bin/cm3 -ship > -DROOT='/home/dabenavidesd/code/cm3' > -DCM3_VERSION_TEXT='d5.7.0' -DCM3_VERSION_NUMBER='050700' > -DCM3_LAST_CHANGED='2008-03-16' +++ > > > > --- building in AMD64_LINUX --- > > > > > > ignoring ../src/m3overrides > > new source -> compiling RTHooks.i3 > new source -> compiling RT0.i3 > new source -> compiling RuntimeError.i3 > new source -> compiling WordRep.i3 > > new source -> compiling Word.i3 > > new source -> compiling RTException.i3 > new source -> compiling RTHooks.m3 > > ../src/runtime/common/RTHooks.m3: In function > 'RTHooks__ReportFault': > ../src/runtime/common/RTHooks.m3:95: internal compiler > error: in emit_move_insn, at expr.c:3379 > > > > > > > Please submit a full bug report, > > > > > with preprocessed source if appropriate. > > > > See for > instructions. > > > m3_backend => 4 > > > > > > m3cc (aka cm3cg) failed compiling: RTHooks.mc > > > > new source -> compiling RT0.m3 > > > > > new source -> compiling Compiler.i3 > > > > > new source -> compiling RuntimeError.m3 > > > > > ../src/runtime/common/RuntimeError.m3: In function > 'RuntimeError__Self': > > ../src/runtime/common/RuntimeError.m3:13: internal compiler > error: in int_mode_for_mode, at stor-layout.c:258 > > > > > > Please submit a full bug report, > > > > > with preprocessed source if appropriate. > > > > See for > instructions. > > > m3_backend => 4 > > > > > > m3cc (aka cm3cg) failed compiling: RuntimeError.mc > > > > > From jay.krell at cornell.edu Sat Apr 17 17:08:04 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 17 Apr 2010 15:08:04 +0000 Subject: [M3devel] getting mac address with netbios Message-ID: We have this code: C:\dev2\cm3.2\m3-libs\libm3\src\uid\WIN32\MachineIDWin32.m3(33): EVAL NB30.Netbios(ADR(ncb)); C:\dev2\cm3.2\m3-libs\libm3\src\uid\WIN32\MachineIDWin32.m3(41): EVAL NB30.Netbios(ADR(ncb)); C:\dev2\cm3.2\m3-libs\libm3\src\uid\WIN32\MachineIDWin32.m3(48): EVAL NB30.Netbios(ADR(ncb)); I just noticed: http://msdn.microsoft.com/en-us/library/bb870913(VS.85).aspx [Netbios is not supported on Windows Vista, Windows Server 2008, and subsequent versions of the operating system] someone should try this out.. and change it to work if needed.. http://www.codeguru.com/Cpp/I-N/network/networkinformation/article.php/c5451 I'm pretty partial to the UuidCreate/UuidCreateSequential solution really. This MachineID probably needs more work anyway -- support for more operating systems. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.async.caltech.edu Sat Apr 17 19:40:28 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Sat, 17 Apr 2010 10:40:28 -0700 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <7430A649-C3AF-4D02-A943-46844E2323D7@cs.purdue.edu> References: <20100417111631.901C22474008@birch.elegosoft.com> <7430A649-C3AF-4D02-A943-46844E2323D7@cs.purdue.edu> Message-ID: <20100417174028.41B551A20FA@async.async.caltech.edu> Tony Hosking writes: >I actually still have an ALPHA_OSF box that I sometimes think of = >resurrecting. Is it really dead? ;-) Me, too. Furthermore, I (and the Internet) have a binary for the Extended Static Checker for Modula-3 for OSF/1 on Alpha. Not sure it exists in any other form nowadays... :-/ Mika > >On 17 Apr 2010, at 13:16, Jay Krell wrote: > >> CVSROOT: /usr/cvs >> Changes by: jkrell at birch. 10/04/17 13:16:31 >>=20 >> Removed files: >> cm3/m3-libs/m3core/src/C/: ChangeLog=20 >> cm3/m3-libs/m3core/src/C/AIX386/: Csetjmp.i3 m3makefile=20 >> cm3/m3-libs/m3core/src/C/ALPHA_OSF/: Csetjmp.i3 m3makefile=20 >> cm3/m3-libs/m3core/src/C/AP3000/: Csetjmp.i3 m3makefile=20 >> cm3/m3-libs/m3core/src/C/ARM/: Csetjmp.i3 m3makefile=20 >> cm3/m3-libs/m3core/src/C/DS3100/: Csetjmp.i3 m3makefile=20 >> cm3/m3-libs/m3core/src/C/FreeBSD/: COPYRIGHT Csetjmp.i3=20 >> m3makefile=20 >> cm3/m3-libs/m3core/src/C/FreeBSD2/: Csetjmp.i3 m3makefile=20 >> cm3/m3-libs/m3core/src/C/FreeBSD3/: COPYRIGHT Csetjmp.i3=20 >> m3makefile=20 >> cm3/m3-libs/m3core/src/C/HP300/: Csetjmp.i3 m3makefile=20 >> cm3/m3-libs/m3core/src/C/HPPA/: Csetjmp.i3 m3makefile=20 >> cm3/m3-libs/m3core/src/C/IBMR2/: Csetjmp.i3 m3makefile=20 >> cm3/m3-libs/m3core/src/C/IBMRT/: Csetjmp.i3 m3makefile=20 >> cm3/m3-libs/m3core/src/C/IRIX5/: Csetjmp.i3 m3makefile=20 >> cm3/m3-libs/m3core/src/C/LINUX/: Csetjmp.i3 m3makefile=20 >> cm3/m3-libs/m3core/src/C/LINUXELF/: Csetjmp.i3 m3makefile=20 >> cm3/m3-libs/m3core/src/C/NEXT/: Csetjmp.i3 m3makefile=20 >> cm3/m3-libs/m3core/src/C/OKI/: Csetjmp.i3 m3makefile setjmp.s=20 >> signal.o=20 >> cm3/m3-libs/m3core/src/C/OS2/: Csetjmp.i3 m3makefile=20 >> cm3/m3-libs/m3core/src/C/SEQUENT/: Csetjmp.i3 m3makefile=20 >> cm3/m3-libs/m3core/src/C/SPARC/: Csetjmp.i3 m3makefile=20 >> cm3/m3-libs/m3core/src/C/SUN3/: Csetjmp.i3 m3makefile=20 >> cm3/m3-libs/m3core/src/C/SUN386/: Csetjmp.i3 m3makefile=20 >> cm3/m3-libs/m3core/src/C/VAX/: Csetjmp.i3 m3makefile=20 >>=20 >> Log message: >> delete lots of dead/dormant platforms, even some that *might* = >come back >> It is easy enough to bring them back. From mika at async.async.caltech.edu Sat Apr 17 20:35:54 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Sat, 17 Apr 2010 11:35:54 -0700 Subject: [M3devel] example of bug in NetObj Stub Generator In-Reply-To: References: , , <7C7408D0-9A40-4988-BADA-A9FD8C15D388@cs.purdue.edu>, , Message-ID: <20100417183554.431441A20FA@async.async.caltech.edu> Hi Randy, The issue is that RECORDs are marshalled "manually" by the stub code, rather than being passed as a Pickle. Therefore, imports are needed for record fields. The change that is needed is the following: Line 291 of CodeForType.m3, currently IF byName AND t.name # NIL THEN change to IF NOT ISTYPE(t,Type.Record) AND byName AND t.name # NIL THEN I would commit this myself but I have lost track of my non-anon CM3 checkout. Can someone do the honors, please? Mika P.S. It is possible the fix is a bit pessimistic, not sure the literal type name is required for every type of record field. Worst-case breakage: stub code generates a warning when compiled. From dabenavidesd at yahoo.es Sat Apr 17 02:18:27 2010 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sat, 17 Apr 2010 00:18:27 +0000 (GMT) Subject: [M3devel] About problem compiling with cm3-bin-core-AMD64_LINUX-5.8.5-RC5 Message-ID: <316058.64510.qm@web23604.mail.ird.yahoo.com> Hi all: I'm trying to build in kubuntu karmic 9.10 the RC5 but got early after compiling succesfully m3cc in this output a problem at: "internal compiler error: in emit_move_insn, at expr.c:3379 " The file I downloaded has the following md5sum, is that correct?: d9ac8a12cdeccb8b5d7ee856c113366f cm3-bin-core-AMD64_LINUX-5.8.5-RC5.tgz Could you suggest me something to do here? Thanks in advance root at mm01:/home/dabenavidesd/code/cm3/scripts# ./do-pkg.sh buildship m3core libm3 m3middle m3linker m3front sysutils m3quake m3objfile m3back cm3 /home/dabenavidesd/code/cm3/scripts/pkgmap.sh -c "/usr/local/cm3/bin/cm3 -build -DROOT='/home/dabenavidesd/code/cm3' -DCM3_VERSION_TEXT='d5.7.0' -DCM3_VERSION_NUMBER='050700' -DCM3_LAST_CHANGED='2008-03-16' && /usr/local/cm3/bin/cm3 -ship -DROOT='/home/dabenavidesd/code/cm3' -DCM3_VERSION_TEXT='d5.7.0' -DCM3_VERSION_NUMBER='050700' -DCM3_LAST_CHANGED='2008-03-16' " m3core libm3 m3middle m3linker m3front sysutils m3quake m3objfile m3back cm3 === package /home/dabenavidesd/code/cm3/m3-libs/m3core === +++ /usr/local/cm3/bin/cm3 -build -DROOT='/home/dabenavidesd/code/cm3' -DCM3_VERSION_TEXT='d5.7.0' -DCM3_VERSION_NUMBER='050700' -DCM3_LAST_CHANGED='2008-03-16' && /usr/local/cm3/bin/cm3 -ship -DROOT='/home/dabenavidesd/code/cm3' -DCM3_VERSION_TEXT='d5.7.0' -DCM3_VERSION_NUMBER='050700' -DCM3_LAST_CHANGED='2008-03-16' +++ --- building in AMD64_LINUX --- ignoring ../src/m3overrides new source -> compiling RTHooks.i3 new source -> compiling RT0.i3 new source -> compiling RuntimeError.i3 new source -> compiling WordRep.i3 new source -> compiling Word.i3 new source -> compiling RTException.i3 new source -> compiling RTHooks.m3 ../src/runtime/common/RTHooks.m3: In function 'RTHooks__ReportFault': ../src/runtime/common/RTHooks.m3:95: internal compiler error: in emit_move_insn, at expr.c:3379 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. m3_backend => 4 m3cc (aka cm3cg) failed compiling: RTHooks.mc new source -> compiling RT0.m3 new source -> compiling Compiler.i3 new source -> compiling RuntimeError.m3 ../src/runtime/common/RuntimeError.m3: In function 'RuntimeError__Self': ../src/runtime/common/RuntimeError.m3:13: internal compiler error: in int_mode_for_mode, at stor-layout.c:258 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. m3_backend => 4 m3cc (aka cm3cg) failed compiling: RuntimeError.mc From jay.krell at cornell.edu Sun Apr 18 00:50:28 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 17 Apr 2010 22:50:28 +0000 Subject: [M3devel] About problem compiling with cm3-bin-core-AMD64_LINUX-5.8.5-RC5 In-Reply-To: <316058.64510.qm@web23604.mail.ird.yahoo.com> References: <316058.64510.qm@web23604.mail.ird.yahoo.com> Message-ID: (probably the mail arrived out of order?) From: jay.krell at cornell.edu To: dabenavidesd at yahoo.es; m3devel at elegosoft.com Subject: RE: [M3devel] About problem compiling with cm3-bin-core-AMD64_LINUX-5.8.5-RC5 Date: Sat, 17 Apr 2010 22:49:34 +0000 Daniel, As your other mail indicated, you are building some old source. >> DCM3_VERSION_TEXT='d5.7.0' -DCM3_VERSION_NUMBER='050700' -DCM3_LAST_CHANGED='2008-03-16' Please try head or release. (Head doesn't even pass these -D version switches any more, but release does). "install" almost any release export PATH=/usr/local/cm3/bin:$PATH cvs -z3 checkout ... cd .../scripts/python ./upgrade.py ./do-cm3-all.py skipgcc realclean ./do-cm3-all.py skipgcc buildship (upgrade.py only builds the compiler and the libraries it uses; upgrade.sh builds everything) (Granted, whatever tree you are using, should work, but...) - Jay > Date: Sat, 17 Apr 2010 00:18:27 +0000 > From: dabenavidesd at yahoo.es > To: m3devel at elegosoft.com > Subject: [M3devel] About problem compiling with cm3-bin-core-AMD64_LINUX-5.8.5-RC5 > > Hi all: > I'm trying to build in kubuntu karmic 9.10 the RC5 but got early after compiling succesfully m3cc in this output a problem at: > "internal compiler error: in emit_move_insn, at expr.c:3379 " > The file I downloaded has the following md5sum, is that correct?: > d9ac8a12cdeccb8b5d7ee856c113366f cm3-bin-core-AMD64_LINUX-5.8.5-RC5.tgz > > Could you suggest me something to do here? > Thanks in advance > > root at mm01:/home/dabenavidesd/code/cm3/scripts# ./do-pkg.sh buildship m3core libm3 m3middle m3linker m3front sysutils m3quake m3objfile m3back cm3 > /home/dabenavidesd/code/cm3/scripts/pkgmap.sh -c "/usr/local/cm3/bin/cm3 -build -DROOT='/home/dabenavidesd/code/cm3' -DCM3_VERSION_TEXT='d5.7.0' -DCM3_VERSION_NUMBER='050700' -DCM3_LAST_CHANGED='2008-03-16' && /usr/local/cm3/bin/cm3 -ship -DROOT='/home/dabenavidesd/code/cm3' -DCM3_VERSION_TEXT='d5.7.0' -DCM3_VERSION_NUMBER='050700' -DCM3_LAST_CHANGED='2008-03-16' " m3core libm3 m3middle m3linker m3front sysutils m3quake m3objfile m3back cm3 > === package /home/dabenavidesd/code/cm3/m3-libs/m3core === > +++ /usr/local/cm3/bin/cm3 -build -DROOT='/home/dabenavidesd/code/cm3' -DCM3_VERSION_TEXT='d5.7.0' -DCM3_VERSION_NUMBER='050700' -DCM3_LAST_CHANGED='2008-03-16' && /usr/local/cm3/bin/cm3 -ship -DROOT='/home/dabenavidesd/code/cm3' -DCM3_VERSION_TEXT='d5.7.0' -DCM3_VERSION_NUMBER='050700' -DCM3_LAST_CHANGED='2008-03-16' +++ > --- building in AMD64_LINUX --- > > ignoring ../src/m3overrides > > new source -> compiling RTHooks.i3 > new source -> compiling RT0.i3 > new source -> compiling RuntimeError.i3 > new source -> compiling WordRep.i3 > new source -> compiling Word.i3 > new source -> compiling RTException.i3 > new source -> compiling RTHooks.m3 > ../src/runtime/common/RTHooks.m3: In function 'RTHooks__ReportFault': > ../src/runtime/common/RTHooks.m3:95: internal compiler error: in emit_move_insn, at expr.c:3379 > Please submit a full bug report, > with preprocessed source if appropriate. > See for instructions. > m3_backend => 4 > m3cc (aka cm3cg) failed compiling: RTHooks.mc > new source -> compiling RT0.m3 > new source -> compiling Compiler.i3 > new source -> compiling RuntimeError.m3 > ../src/runtime/common/RuntimeError.m3: In function 'RuntimeError__Self': > ../src/runtime/common/RuntimeError.m3:13: internal compiler error: in int_mode_for_mode, at stor-layout.c:258 > Please submit a full bug report, > with preprocessed source if appropriate. > See for instructions. > m3_backend => 4 > m3cc (aka cm3cg) failed compiling: RuntimeError.mc > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Apr 18 00:49:34 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 17 Apr 2010 22:49:34 +0000 Subject: [M3devel] About problem compiling with cm3-bin-core-AMD64_LINUX-5.8.5-RC5 In-Reply-To: <316058.64510.qm@web23604.mail.ird.yahoo.com> References: <316058.64510.qm@web23604.mail.ird.yahoo.com> Message-ID: Daniel, As your other mail indicated, you are building some old source. >> DCM3_VERSION_TEXT='d5.7.0' -DCM3_VERSION_NUMBER='050700' -DCM3_LAST_CHANGED='2008-03-16' Please try head or release. (Head doesn't even pass these -D version switches any more, but release does). "install" almost any release export PATH=/usr/local/cm3/bin:$PATH cvs -z3 checkout ... cd .../scripts/python ./upgrade.py ./do-cm3-all.py skipgcc realclean ./do-cm3-all.py skipgcc buildship (upgrade.py only builds the compiler and the libraries it uses; upgrade.sh builds everything) (Granted, whatever tree you are using, should work, but...) - Jay > Date: Sat, 17 Apr 2010 00:18:27 +0000 > From: dabenavidesd at yahoo.es > To: m3devel at elegosoft.com > Subject: [M3devel] About problem compiling with cm3-bin-core-AMD64_LINUX-5.8.5-RC5 > > Hi all: > I'm trying to build in kubuntu karmic 9.10 the RC5 but got early after compiling succesfully m3cc in this output a problem at: > "internal compiler error: in emit_move_insn, at expr.c:3379 " > The file I downloaded has the following md5sum, is that correct?: > d9ac8a12cdeccb8b5d7ee856c113366f cm3-bin-core-AMD64_LINUX-5.8.5-RC5.tgz > > Could you suggest me something to do here? > Thanks in advance > > root at mm01:/home/dabenavidesd/code/cm3/scripts# ./do-pkg.sh buildship m3core libm3 m3middle m3linker m3front sysutils m3quake m3objfile m3back cm3 > /home/dabenavidesd/code/cm3/scripts/pkgmap.sh -c "/usr/local/cm3/bin/cm3 -build -DROOT='/home/dabenavidesd/code/cm3' -DCM3_VERSION_TEXT='d5.7.0' -DCM3_VERSION_NUMBER='050700' -DCM3_LAST_CHANGED='2008-03-16' && /usr/local/cm3/bin/cm3 -ship -DROOT='/home/dabenavidesd/code/cm3' -DCM3_VERSION_TEXT='d5.7.0' -DCM3_VERSION_NUMBER='050700' -DCM3_LAST_CHANGED='2008-03-16' " m3core libm3 m3middle m3linker m3front sysutils m3quake m3objfile m3back cm3 > === package /home/dabenavidesd/code/cm3/m3-libs/m3core === > +++ /usr/local/cm3/bin/cm3 -build -DROOT='/home/dabenavidesd/code/cm3' -DCM3_VERSION_TEXT='d5.7.0' -DCM3_VERSION_NUMBER='050700' -DCM3_LAST_CHANGED='2008-03-16' && /usr/local/cm3/bin/cm3 -ship -DROOT='/home/dabenavidesd/code/cm3' -DCM3_VERSION_TEXT='d5.7.0' -DCM3_VERSION_NUMBER='050700' -DCM3_LAST_CHANGED='2008-03-16' +++ > --- building in AMD64_LINUX --- > > ignoring ../src/m3overrides > > new source -> compiling RTHooks.i3 > new source -> compiling RT0.i3 > new source -> compiling RuntimeError.i3 > new source -> compiling WordRep.i3 > new source -> compiling Word.i3 > new source -> compiling RTException.i3 > new source -> compiling RTHooks.m3 > ../src/runtime/common/RTHooks.m3: In function 'RTHooks__ReportFault': > ../src/runtime/common/RTHooks.m3:95: internal compiler error: in emit_move_insn, at expr.c:3379 > Please submit a full bug report, > with preprocessed source if appropriate. > See for instructions. > m3_backend => 4 > m3cc (aka cm3cg) failed compiling: RTHooks.mc > new source -> compiling RT0.m3 > new source -> compiling Compiler.i3 > new source -> compiling RuntimeError.m3 > ../src/runtime/common/RuntimeError.m3: In function 'RuntimeError__Self': > ../src/runtime/common/RuntimeError.m3:13: internal compiler error: in int_mode_for_mode, at stor-layout.c:258 > Please submit a full bug report, > with preprocessed source if appropriate. > See for instructions. > m3_backend => 4 > m3cc (aka cm3cg) failed compiling: RuntimeError.mc > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.async.caltech.edu Sun Apr 18 04:35:35 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Sat, 17 Apr 2010 19:35:35 -0700 Subject: [M3devel] INTEGER In-Reply-To: References: , , <7C7408D0-9A40-4988-BADA-A9FD8C15D388@cs.purdue.edu>, , Message-ID: <20100418023535.3BA9E1A2103@async.async.caltech.edu> Ok, sorry if I am beating a dead horse here. What is INTEGER on a 64-bit machine? Modula-3 doesn't specify it to be one or the other does it? But normally, 64 bits? I am asking because I was looking through some stub generator code, and I'm really wondering about the LONGINT. Now there are "longcard" things showing up, which means another set of changes to a lot of code. The rationale for LONGINT is, again? We need it to match 64-bit integers on 32-bit machines? That seems like a very weak rationale indeed, if the same functionality could be provided through some other mechanism (e.g., ARRAY [0..1] OF INTEGER---even with a pragma e.g. <*CLONGLONG*>.. if it is necessary to tell the compiler that a special linkage convention is needed). On a 64-bit machine INTEGER and CARDINAL are 64/63 bits (right?), so there is really no need for LONGINT there. And having an array with a LONGINT index seems silly since you can't address more memory than you can fit in an INTEGER anyhow... Mika >________________________________ >From: hosking at cs.purdue.edu >Date: Thu, 15 Apr 2010 12:55:52 -0400 >To: jay.krell at cornell.edu >CC: m3devel at elegosoft.com >Subject: Re: [M3devel] Modula-3/C interop in Date/Time? >Excepting that INTEGER is not the same as int on 64-bit platforms. > >Antony Hosking | Associate Professor | Computer Science | Purdue University >305 N. University Street | West Lafayette | IN 47907 | USA >Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > >On 15 Apr 2010, at 02:45, Jay K wrote: > >Is this legal/correct? > > >Date.i3: >TYPE TimeZone <: REFANY; >VAR Local, UTC: TimeZone; (* granted, will maybe change these to extern *) > > >Date.m3:=1B$B!!=1B(B >REVEAL TimeZone =3D BRANDED "Date.TimeZone" REF INTEGER; >=1B$B!!=1B(B > >DatePosixC.c: >static const int Local =3D 0; >static const int UTC =3D 1; >extern const int const * const Date__Local =3D &Local; >extern const int const * const Date__UTC =3D &UTC; >=1B$B!!=1B(B > >- Jay From hosking at cs.purdue.edu Sun Apr 18 04:40:20 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 17 Apr 2010 22:40:20 -0400 Subject: [M3devel] INTEGER In-Reply-To: <20100418023535.3BA9E1A2103@async.async.caltech.edu> References: , , <7C7408D0-9A40-4988-BADA-A9FD8C15D388@cs.purdue.edu>, , <20100418023535.3BA9E1A2103@async.async.caltech.edu> Message-ID: On 17 Apr 2010, at 22:35, Mika Nystrom wrote: > Ok, sorry if I am beating a dead horse here. > > What is INTEGER on a 64-bit machine? The language spec doesn't say, but CM3 pretty strongly assumes BITSIZE(INTEGER)=BITSIZE(ADDRESS). So, that means 64 bits. > Modula-3 doesn't specify it to be one or the other does it? > But normally, 64 bits? > > I am asking because I was looking through some stub generator code, > and I'm really wondering about the LONGINT. Now there are "longcard" > things showing up, which means another set of changes to a lot of code. > > The rationale for LONGINT is, again? Yes, LONGINT is to permit longer than "efficient" INTEGER. Mainly for 32 bit machines where we'd like to have a C "long long" equivalent. > We need it to match 64-bit integers on 32-bit machines? That seems like > a very weak rationale indeed, if the same functionality could be provided > through some other mechanism (e.g., ARRAY [0..1] OF INTEGER---even with > a pragma e.g. <*CLONGLONG*>.. if it is necessary to tell the compiler that > a special linkage convention is needed). There's no special linkage convention. Not sure what you mean here. > On a 64-bit machine INTEGER and CARDINAL are 64/63 bits (right?), so > there is really no need for LONGINT there. True. The only expectation is BITSIZE(LONGINT) >= BITSIZE(INTEGER). > And having an array with a LONGINT index seems silly since you can't > address more memory than you can fit in an INTEGER anyhow... We don't allow arrays with LONGINT indexes in the current implementation. > > Mika > >> ________________________________ >> From: hosking at cs.purdue.edu >> Date: Thu, 15 Apr 2010 12:55:52 -0400 >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] Modula-3/C interop in Date/Time? >> Excepting that INTEGER is not the same as int on 64-bit platforms. >> >> Antony Hosking | Associate Professor | Computer Science | Purdue University >> 305 N. University Street | West Lafayette | IN 47907 | USA >> Office +1 765 494 6001 | Mobile +1 765 427 5484 >> >> >> >> >> On 15 Apr 2010, at 02:45, Jay K wrote: >> >> Is this legal/correct? >> >> >> Date.i3: >> TYPE TimeZone <: REFANY; >> VAR Local, UTC: TimeZone; (* granted, will maybe change these to extern *) >> >> >> Date.m3:=1B$B!!=1B(B >> REVEAL TimeZone =3D BRANDED "Date.TimeZone" REF INTEGER; >> =1B$B!!=1B(B >> >> DatePosixC.c: >> static const int Local =3D 0; >> static const int UTC =3D 1; >> extern const int const * const Date__Local =3D &Local; >> extern const int const * const Date__UTC =3D &UTC; >> =1B$B!!=1B(B >> >> - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Apr 18 04:46:17 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 17 Apr 2010 22:46:17 -0400 Subject: [M3devel] INTEGER In-Reply-To: References: , , <7C7408D0-9A40-4988-BADA-A9FD8C15D388@cs.purdue.edu>, , <20100418023535.3BA9E1A2103@async.async.caltech.edu> Message-ID: <8604EE57-9661-4F82-BB51-DBFDC93844DC@cs.purdue.edu> On 17 Apr 2010, at 22:40, Tony Hosking wrote: > > On 17 Apr 2010, at 22:35, Mika Nystrom wrote: > >> Ok, sorry if I am beating a dead horse here. >> >> What is INTEGER on a 64-bit machine? > > The language spec doesn't say, but CM3 pretty strongly assumes BITSIZE(INTEGER)=BITSIZE(ADDRESS). > So, that means 64 bits. > >> Modula-3 doesn't specify it to be one or the other does it? >> But normally, 64 bits? >> >> I am asking because I was looking through some stub generator code, >> and I'm really wondering about the LONGINT. Now there are "longcard" >> things showing up, which means another set of changes to a lot of code. >> >> The rationale for LONGINT is, again? > > Yes, LONGINT is to permit longer than "efficient" INTEGER. Mainly for 32 bit machines where we'd like to have a C "long long" equivalent. > >> We need it to match 64-bit integers on 32-bit machines? That seems like >> a very weak rationale indeed, if the same functionality could be provided >> through some other mechanism (e.g., ARRAY [0..1] OF INTEGER---even with >> a pragma e.g. <*CLONGLONG*>.. if it is necessary to tell the compiler that >> a special linkage convention is needed). > > There's no special linkage convention. Not sure what you mean here. > >> On a 64-bit machine INTEGER and CARDINAL are 64/63 bits (right?), so >> there is really no need for LONGINT there. > > True. The only expectation is BITSIZE(LONGINT) >= BITSIZE(INTEGER). > >> And having an array with a LONGINT index seems silly since you can't >> address more memory than you can fit in an INTEGER anyhow... > > We don't allow arrays with LONGINT indexes in the current implementation. Correction. We do allow arrays with LONGINT subrange indexes, but the restriction is that NUMBER be representable as an INTEGER. > >> >> Mika >> >>> ________________________________ >>> From: hosking at cs.purdue.edu >>> Date: Thu, 15 Apr 2010 12:55:52 -0400 >>> To: jay.krell at cornell.edu >>> CC: m3devel at elegosoft.com >>> Subject: Re: [M3devel] Modula-3/C interop in Date/Time? >>> Excepting that INTEGER is not the same as int on 64-bit platforms. >>> >>> Antony Hosking | Associate Professor | Computer Science | Purdue University >>> 305 N. University Street | West Lafayette | IN 47907 | USA >>> Office +1 765 494 6001 | Mobile +1 765 427 5484 >>> >>> >>> >>> >>> On 15 Apr 2010, at 02:45, Jay K wrote: >>> >>> Is this legal/correct? >>> >>> >>> Date.i3: >>> TYPE TimeZone <: REFANY; >>> VAR Local, UTC: TimeZone; (* granted, will maybe change these to extern *) >>> >>> >>> Date.m3:=1B$B!!=1B(B >>> REVEAL TimeZone =3D BRANDED "Date.TimeZone" REF INTEGER; >>> =1B$B!!=1B(B >>> >>> DatePosixC.c: >>> static const int Local =3D 0; >>> static const int UTC =3D 1; >>> extern const int const * const Date__Local =3D &Local; >>> extern const int const * const Date__UTC =3D &UTC; >>> =1B$B!!=1B(B >>> >>> - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.async.caltech.edu Sun Apr 18 04:47:03 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Sat, 17 Apr 2010 19:47:03 -0700 Subject: [M3devel] INTEGER In-Reply-To: References: , , <7C7408D0-9A40-4988-BADA-A9FD8C15D388@cs.purdue.edu>, , <20100418023535.3BA9E1A2103@async.async.caltech.edu> Message-ID: <20100418024703.6965B1A2103@async.async.caltech.edu> Tony Hosking writes: > ... > >> We need it to match 64-bit integers on 32-bit machines? That seems = >like >> a very weak rationale indeed, if the same functionality could be = >provided >> through some other mechanism (e.g., ARRAY [0..1] OF INTEGER---even = >with >> a pragma e.g. <*CLONGLONG*>.. if it is necessary to tell the compiler = >that >> a special linkage convention is needed). > >There's no special linkage convention. Not sure what you mean here. > I just mean if we had TYPE LONGINT = ARRAY [0..1] OF INTEGER that would perhaps not match how C handles "long long" on the same platform (which is how, come to think of it?), and that would require special linkage tricks. But what would be lost? The ability to type literals. You could get the same code interface on 32- and 64-bit machine by defining TYPE FileOffset = ARRAY[0..1] OF [-16_80000000 .. +16_7fffffff ] and using that. Mika From jay.krell at cornell.edu Sun Apr 18 09:14:14 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 18 Apr 2010 07:14:14 +0000 Subject: [M3devel] INTEGER In-Reply-To: <20100418024703.6965B1A2103@async.async.caltech.edu> References: , , , <7C7408D0-9A40-4988-BADA-A9FD8C15D388@cs.purdue.edu>, , , , , , , <20100418023535.3BA9E1A2103@async.async.caltech.edu>, , <20100418024703.6965B1A2103@async.async.caltech.edu> Message-ID: TYPE LONGINT = ARRAY [0..1] OF INTEGER on a 32bit system is very close to LONGINT. Plus treating it opaquely and providing a bunch of functions to operate on it. Just as well therefore could be RECORD hi,lo:LONGINT END (see LARGE_INTEGER and ULARGE_INTEGER in winnt.h) Differences that come to mind: infix operators <=== possibly passed differently as a parameter or returned differently as a result ie. probably "directly compatible with" "long long", passed by value (of course you could always pass by pointer and achieve compatibilitity trivially) I have to say though, the biggest reason is in-fix operators. Convenient syntax. C++ is the best and some way worst of example of the general right way to do this -- you let programmers define types and their infix operators. Other languages just come with a passle of special cases of types that have in-fix operators. A good example is that Java infix operator + on string, besides the various integers, and nothing else. I think C# lets you define operators, yet people don't complain that it is "a mess" as they do of C++. I think Python does now too. So it is feature growing in popularity among "mainstream" languages, not just C++. C++ of course is extremely mainstream, but also a favorite target. (http://www.relisoft.com/tools/CppCritic.html) We also have subranges of LONGINT. I'm not sure what the generalization of subranges are, granted. Maybe some sort of C++ template that takes constants in the template and does range checks at runtime. Yeah, maybe. And as you point out, convenient literal syntax. People reasonably argue for library extension in place of language extension, but that requires a language which is flexible enough to write libraries with the desired interface, and so many languages don't let infix operators be in a user-written library. (There is a subtle but useless distinction here -- infix operators being in libraries vs. "user-written" libraries. The infix set operations for example are in a library, but not user-written, special, the compiler knows about it.) > that would perhaps not match how C handles "long long" on the same > platform (which is how, come to think of it?), and that would require On NT/x86, __int64/long long is returned in the register pair edx:eax. edx is high, eax is low. When passed as a parameter to __stdcall or __cdecl is just passed as two 32bit values adjacent on the stack, "hi, lo, hi, lo, it's off to push we go" is the Snow White-influenced mantra to remember how to pass them, at least on little endian stack-growing-down machines (which includes x86). For __fastcall I'm not sure they are passed in registers or on the stack. Passing and/or returning small structs also has special efficient handling in the ABI, so __int64 really might be equivalent to a small record. Not that cm3 necessarily implements that "correctly" -- for interop with C; for Modula-3 calling Modula-3 we can make up our own ABI so there isn't really an "incorrect" way. Notice the mingw problem I had passing a Win32 point struct by value, I cheated and passed it by VAR to a C wrapper to workaround the gcc backend bug (which was mentioned a few times and which I looked into the code for, but took the easy route) I don't know how long long works on other platforms but probably similar. Probably a certain register pair for return values. - Jay > To: hosking at cs.purdue.edu > Date: Sat, 17 Apr 2010 19:47:03 -0700 > From: mika at async.async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] INTEGER > > Tony Hosking writes: > > > ... > > > >> We need it to match 64-bit integers on 32-bit machines? That seems = > >like > >> a very weak rationale indeed, if the same functionality could be = > >provided > >> through some other mechanism (e.g., ARRAY [0..1] OF INTEGER---even = > >with > >> a pragma e.g. <*CLONGLONG*>.. if it is necessary to tell the compiler = > >that > >> a special linkage convention is needed). > > > >There's no special linkage convention. Not sure what you mean here. > > > > I just mean if we had > > TYPE LONGINT = ARRAY [0..1] OF INTEGER > > that would perhaps not match how C handles "long long" on the same > platform (which is how, come to think of it?), and that would require > special linkage tricks. > > But what would be lost? The ability to type literals. > > You could get the same code interface on 32- and 64-bit machine by > defining > > TYPE FileOffset = ARRAY[0..1] OF [-16_80000000 .. +16_7fffffff ] > > and using that. > > > Mika -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.async.caltech.edu Sun Apr 18 09:49:27 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Sun, 18 Apr 2010 00:49:27 -0700 Subject: [M3devel] INTEGER In-Reply-To: References: , , , <7C7408D0-9A40-4988-BADA-A9FD8C15D388@cs.purdue.edu>, , , , , , , <20100418023535.3BA9E1A2103@async.async.caltech.edu>, , <20100418024703.6965B1A2103@async.async.caltech.edu> Message-ID: <20100418074927.934461A2117@async.async.caltech.edu> Jay I know most of this, and it doesn't really answer the question "what is it for?" I think we've already established that LONGINT isn't useful for counting anything that might actually reside in the computer's memory: it makes no sense as an array index, for instance. INTEGER suffices for that. I thought that the only real reason for LONGINT was to match C's declaration of various seek-related routines on 32-bit machines. That's not a very good reason. C++ succeeds because it does very well in the area(s) it is good at. People who want to program in C++ will clearly program in C++, not Modula-3. Modula-3 is never, ever going to be the language of choice for people who want lots of snazzy infix operators. Modula-3 is supposed to be a language with about as powerful semantics as C++ and an extremely simple syntax and definition---snazzy infix is one of the things you give up for that. I don't see how LONGINT fits into this picture. Now we have LONGCARD too? And it's infected the definitions of FIRST and LAST? But not NUMBER... argh! so, NUMBER(a) and LAST(a) - FIRST(a) + 1 no longer mean the same thing? Are we going to see lots of comments in generics in the future where it says T may not be an open array type nor an array type indexed on LONGINT or a subrange thereof? Your comments about different parameter-passing techniques was what I was trying to address with my suggestion to have a pragma for this---just to match C (and Fortran?), of course. Name me a single Modula-3 programmer who cares in what order the bits in his parameters are pushed on the stack in a Modula-3-to-Modula-3 call. And I am definitely in that school of thought that says that programming languages should not "evolve". Better to leave well enough alone. How much Modula-3 code has been written that uses LONGINT? Other than to talk to C? I've certainly never used it. Mika Jay K writes: >--_264cb69b-0215-44c3-807c-8b4d8ea0ea59_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >TYPE LONGINT =3D ARRAY [0..1] OF INTEGER on a 32bit system is very close to= > LONGINT. > > Plus treating it opaquely and providing a bunch of functions to operate on= > it. > > Just as well therefore could be RECORD hi=2Clo:LONGINT END (see LARGE_INTE= >GER and ULARGE_INTEGER in winnt.h) > >=20 > >Differences that come to mind: > > infix operators <=3D=3D=3D=20 > > possibly passed differently as a parameter > > or returned differently as a result > > ie. probably "directly compatible with" "long long"=2C passed by value (o= >f course you could always pass by pointer and achieve compatibilitity trivi= >ally) > >=20 > >=20 > >I have to say though=2C the biggest reason is in-fix operators. Convenient = >syntax. > >C++ is the best and some way worst of example of the general right way to d= >o this -- you let programmers define types and their infix operators. Other= > languages just come with a passle of special cases of types that have in-f= >ix operators. > >A good example is that Java infix operator + on string=2C besides the vario= >us integers=2C and nothing else. > >=20 > >=20 > >I think C# lets you define operators=2C yet people don't complain that it i= >s "a mess" as they do of C++. > >I think Python does now too. > >So it is feature growing in popularity among "mainstream" languages=2C not = >just C++. > > C++ of course is extremely mainstream=2C but also a favorite target. (ht= >tp://www.relisoft.com/tools/CppCritic.html) > >=20 > >=20 > >We also have subranges of LONGINT. > >I'm not sure what the generalization of subranges are=2C granted. > > Maybe some sort of C++ template that takes constants in the template and d= >oes range checks at runtime. Yeah=2C maybe. > >=20 > >=20 > >And as you point out=2C convenient literal syntax. > >=20 > >=20 > >People reasonably argue for library extension in place of language extensio= >n=2C but that requires a language which is flexible enough to write librari= >es with the desired interface=2C and so many languages don't let infix oper= >ators be in a user-written library. > >(There is a subtle but useless distinction here -- infix operators being in= > libraries vs. "user-written" libraries. The infix set operations for examp= >le are in a library=2C but not user-written=2C special=2C the compiler know= >s about it.) > >=20 > >> that would perhaps not match how C handles "long long" on the same >> platform (which is how=2C come to think of it?)=2C and that would require > > >=20 > >On NT/x86=2C __int64/long long is returned in the register pair edx:eax. > >edx is high=2C eax is low. > >When passed as a parameter to __stdcall or __cdecl is just passed as two 32= >bit values adjacent on the stack=2C "hi=2C lo=2C hi=2C lo=2C it's off to pu= >sh we go" is the Snow White-influenced mantra to remember how to pass them= >=2C at least on little endian stack-growing-down machines (which includes x= >86). For __fastcall I'm not sure they are passed in registers or on the sta= >ck. > >Passing and/or returning small structs also has special efficient handling = >in the ABI=2C so __int64 really might be equivalent to a small record. Not = >that cm3 necessarily implements that "correctly" -- for interop with C=3B = >for Modula-3 calling Modula-3 we can make up our own ABI so there isn't rea= >lly an "incorrect" way. Notice the mingw problem I had passing a Win32 poin= >t struct by value=2C I cheated and passed it by VAR to a C wrapper to worka= >round the gcc backend bug (which was mentioned a few times and which I look= >ed into the code for=2C but took the easy route) > >=20 > >=20 > >I don't know how long long works on other platforms but probably similar. > >Probably a certain register pair for return values. > >=20 > > - Jay > >=20 >> To: hosking at cs.purdue.edu >> Date: Sat=2C 17 Apr 2010 19:47:03 -0700 >> From: mika at async.async.caltech.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] INTEGER >>=20 >> Tony Hosking writes: >> > >> ... >> > >> >> We need it to match 64-bit integers on 32-bit machines? That seems =3D >> >like >> >> a very weak rationale indeed=2C if the same functionality could be =3D >> >provided >> >> through some other mechanism (e.g.=2C ARRAY [0..1] OF INTEGER---even = >=3D >> >with >> >> a pragma e.g. <*CLONGLONG*>.. if it is necessary to tell the compiler = >=3D >> >that >> >> a special linkage convention is needed). >> > >> >There's no special linkage convention. Not sure what you mean here. >> > >>=20 >> I just mean if we had >>=20 >> TYPE LONGINT =3D ARRAY [0..1] OF INTEGER >>=20 >> that would perhaps not match how C handles "long long" on the same >> platform (which is how=2C come to think of it?)=2C and that would require >> special linkage tricks. >>=20 >> But what would be lost? The ability to type literals.=20 >>=20 >> You could get the same code interface on 32- and 64-bit machine by >> defining >>=20 >> TYPE FileOffset =3D ARRAY[0..1] OF [-16_80000000 .. +16_7fffffff ] >>=20 >> and using that. >>=20 >>=20 >> Mika > = > >--_264cb69b-0215-44c3-807c-8b4d8ea0ea59_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > > >TYPE LONGINT =3D ARRAY [0..1] OF INTEGER on a =3B32bit system is very c= >lose to LONGINT.
> =3BPlus treating it opaquely and providing a bunch of functions to ope= >rate on it.
> =3BJust as well therefore could be RECORD hi=2Clo:LONGINT END (see LAR= >GE_INTEGER and ULARGE_INTEGER in winnt.h)
> =3B
>Differences that come to mind:
> =3B =3Binfix operators =3B <=3B=3D=3D=3D
> =3B possibly passed differently =3Bas a parameter
> =3B or returned differently as a result
> =3B ie. probably "directly compatible with" "long long"=2C passed by v= >alue (of course you could always pass by pointer and achieve compatibilitit= >y trivially)
> =3B
> =3B
>I have to say though=2C the biggest reason is in-fix operators. Convenient = >syntax.
>C++ is the best and some way worst of example of the general right way to d= >o this -- you let programmers define types and their infix operators. Other= > languages just come with a passle of special cases of types that have in-f= >ix operators.
>A good example is that Java infix operator + on string=2C besides the vario= >us integers=2C and nothing else.
> =3B
> =3B
>I think C# lets you define operators=2C yet people don't complain that it i= >s "a mess" as they do of C++.
>I think Python does now too.
>So it is feature growing in popularity among "mainstream" languages=2C not = >just C++.
> =3B =3B C++ of course is extremely mainstream=2C but also a favori= >te target. (http:/= >/www.relisoft.com/tools/CppCritic.html)
> =3B
> =3B
>We also have subranges of LONGINT.
>I'm not sure what the generalization of subranges are=2C granted.
> =3BMaybe some sort of C++ template that takes constants in the templat= >e and does range checks at runtime. Yeah=2C maybe.
> =3B
> =3B
>And as you point out=2C convenient literal syntax.
> =3B
> =3B
>People reasonably argue for library extension in place of language extensio= >n=2C but that requires a language which is flexible enough to write librari= >es with the desired interface=2C and so many languages don't let infix oper= >ators be in a user-written library.
>(There is a subtle but useless distinction here -- infix operators being in= > libraries vs. "user-written" libraries. The infix set operations for examp= >le are in a library=2C but not user-written=2C special=2C the compiler know= >s about it.)
> =3B
>>=3B that would perhaps not match how C handles "long long" on the sameR>>=3B platform (which is how=2C come to think of it?)=2C and that would = >require

> =3B
>On NT/x86=2C __int64/long long is returned in the register pair edx:eax.> >edx is high=2C eax is low.
>When passed as a parameter to __stdcall or __cdecl is just passed as two 32= >bit values adjacent on the stack=2C "hi=2C lo=2C hi=2C lo=2C it's off to pu= >sh we go" is the Snow White-influenced mantra to remember how to pass them= >=2C at least on little endian stack-growing-down machines (which includes x= >86). For __fastcall I'm not sure they are passed in registers or on the sta= >ck.
>Passing and/or returning small structs also has special efficient handling = >in the ABI=2C so __int64 really might be equivalent to a small record. Not = >that cm3 necessarily implements that "correctly" =3B -- for interop wit= >h C=3B for Modula-3 calling Modula-3 we can make up our own ABI so there is= >n't =3Breally an "incorrect" way. =3BNotice the mingw problem I had= > passing a Win32 point struct by value=2C I cheated and passed it by VAR to= > a =3BC wrapper to workaround the gcc backend bug (which was mentioned = >a few times and which I looked into the code for=2C but took the easy route= >)
> =3B
> =3B
>I don't know how long long works on other platforms but probably similar.R> >Probably a certain register pair for return values.
> =3B
> =3B- Jay

 =3B
>=3B To: hosking at cs.purdue.edu
>=3B= > Date: Sat=2C 17 Apr 2010 19:47:03 -0700
>=3B From: mika at async.async.c= >altech.edu
>=3B CC: m3devel at elegosoft.com
>=3B Subject: Re: [M3de= >vel] INTEGER
>=3B
>=3B Tony Hosking writes:
>=3B >=3B
= >>=3B ...
>=3B >=3B
>=3B >=3B>=3B We need it to match 64-b= >it integers on 32-bit machines? That seems =3D
>=3B >=3Blike
>= >=3B >=3B>=3B a very weak rationale indeed=2C if the same functionality = >could be =3D
>=3B >=3Bprovided
>=3B >=3B>=3B through some o= >ther mechanism (e.g.=2C ARRAY [0..1] OF INTEGER---even =3D
>=3B >=3B= >with
>=3B >=3B>=3B a pragma e.g. <=3B*CLONGLONG*>=3B.. if it i= >s necessary to tell the compiler =3D
>=3B >=3Bthat
>=3B >=3B&= >gt=3B a special linkage convention is needed).
>=3B >=3B
>=3B &= >gt=3BThere's no special linkage convention. Not sure what you mean here.>>=3B >=3B
>=3B
>=3B I just mean if we had
>=3B
>= >=3B TYPE LONGINT =3D ARRAY [0..1] OF INTEGER
>=3B
>=3B that woul= >d perhaps not match how C handles "long long" on the same
>=3B platfor= >m (which is how=2C come to think of it?)=2C and that would require
>= >=3B special linkage tricks.
>=3B
>=3B But what would be lost? Th= >e ability to type literals.
>=3B
>=3B You could get the same co= >de interface on 32- and 64-bit machine by
>=3B defining
>=3B
= >>=3B TYPE FileOffset =3D ARRAY[0..1] OF [-16_80000000 .. +16_7fffffff ]R>>=3B
>=3B and using that.
>=3B
>=3B
>=3B Mika> >= > >--_264cb69b-0215-44c3-807c-8b4d8ea0ea59_-- From jay.krell at cornell.edu Sun Apr 18 11:23:24 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 18 Apr 2010 09:23:24 +0000 Subject: [M3devel] INTEGER In-Reply-To: <20100418074927.934461A2117@async.async.caltech.edu> References: , , ,,<7C7408D0-9A40-4988-BADA-A9FD8C15D388@cs.purdue.edu>, ,,, , , , , , , , , <20100418023535.3BA9E1A2103@async.async.caltech.edu>, , , , <20100418024703.6965B1A2103@async.async.caltech.edu>, , <20100418074927.934461A2117@async.async.caltech.edu> Message-ID: Mika, I'm not sure what the answer is. You might recall that Tony questioned the need for LONGINT, because it is "only" there to interface with C, and I've rewritten all the C interfacing, providing perhaps other means to solve that problem...I'm not sure what means Tony had in mind, but perhaps an array or record as you/I show. Others spoke up about the need to work with files larger than 2GB. Which isn't necessarily enabled by providing LONGINT, but it is a small convenient step ("convenient" to who? Not the compiler developer. :) ) A very small amount of code has been "fixed" to pass along large file sizes with complete fidelity. The Rd/Wr interface continues to not work, or work well or easily, with streams beyond 2GB in size. I still that that should be dealt with. And I still suspect a 64bit size is near enough to infinity (for I/O purposes), that the interfaces don't need a significant redesign, merely a widening of INTEGER to LONGINT. Pass the problem up yet one more level. Granted, I vaguely recall that most/many/all rd/wr users require their data to fit into memory, so they'll fail with >2GB file sizes. Recall that merely browsing to a directory with a large file with the normal Trestle GUI would hit a subrange fault and generally terminate the running program -- no need to try to open the file. That bug at least should now be fixed by LONGINT. Granted, it probably could have been fixed e.g. by lying and giving such files a size of LAST(INTEGER). ? "Obviously" 64 is just one special spot on a range of integer sizes. Realize however that a number of 64bit integer operations really can be very efficiently implemented on most 32bit processors. Though not all operations -- add, subtract, compare are reasonable, multiply, divide less so. However arbitrary precision arithmetic, not just double precision, can be done about as efficiently -- the critical piece is "exposing the carry flag efficiently", if it exists, and we don't actually do that. Another opinion is that 64bit platforms already work..and perhaps 32bit platforms won't be around much longer anyway. This feature is 10-20 years too late and its impact therefore won't be significant. ? (http://yarchive.net/comp/longlong.html dates "long long" to circa 18 years ago.) Again, I don't have an anwer. - Jay > To: jay.krell at cornell.edu > Date: Sun, 18 Apr 2010 00:49:27 -0700 > From: mika at async.async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] INTEGER > > > Jay I know most of this, and it doesn't really answer the question > "what is it for?" > > I think we've already established that LONGINT isn't useful for counting > anything that might actually reside in the computer's memory: it makes > no sense as an array index, for instance. INTEGER suffices for that. > > I thought that the only real reason for LONGINT was to match C's > declaration of various seek-related routines on 32-bit machines. > That's not a very good reason. > > C++ succeeds because it does very well in the area(s) it is good at. > People who want to program in C++ will clearly program in C++, not > Modula-3. Modula-3 is never, ever going to be the language of choice for > people who want lots of snazzy infix operators. Modula-3 is supposed to > be a language with about as powerful semantics as C++ and an extremely > simple syntax and definition---snazzy infix is one of the things you > give up for that. I don't see how LONGINT fits into this picture. > Now we have LONGCARD too? And it's infected the definitions > of FIRST and LAST? But not NUMBER... argh! > > so, > > NUMBER(a) and LAST(a) - FIRST(a) + 1 > > no longer mean the same thing? Are we going to see lots of comments > in generics in the future where it says T may not be an open array > type nor an array type indexed on LONGINT or a subrange thereof? > > Your comments about different parameter-passing techniques was what I was > trying to address with my suggestion to have a pragma for this---just to > match C (and Fortran?), of course. Name me a single Modula-3 programmer > who cares in what order the bits in his parameters are pushed on the > stack in a Modula-3-to-Modula-3 call. > > And I am definitely in that school of thought that says that programming > languages should not "evolve". Better to leave well enough alone. > > How much Modula-3 code has been written that uses LONGINT? Other than > to talk to C? I've certainly never used it. > > Mika > > > > Jay K writes: > >--_264cb69b-0215-44c3-807c-8b4d8ea0ea59_ > >Content-Type: text/plain; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > >TYPE LONGINT =3D ARRAY [0..1] OF INTEGER on a 32bit system is very close to= > > LONGINT. > > > > Plus treating it opaquely and providing a bunch of functions to operate on= > > it. > > > > Just as well therefore could be RECORD hi=2Clo:LONGINT END (see LARGE_INTE= > >GER and ULARGE_INTEGER in winnt.h) > > > >=20 > > > >Differences that come to mind: > > > > infix operators <=3D=3D=3D=20 > > > > possibly passed differently as a parameter > > > > or returned differently as a result > > > > ie. probably "directly compatible with" "long long"=2C passed by value (o= > >f course you could always pass by pointer and achieve compatibilitity trivi= > >ally) > > > >=20 > > > >=20 > > > >I have to say though=2C the biggest reason is in-fix operators. Convenient = > >syntax. > > > >C++ is the best and some way worst of example of the general right way to d= > >o this -- you let programmers define types and their infix operators. Other= > > languages just come with a passle of special cases of types that have in-f= > >ix operators. > > > >A good example is that Java infix operator + on string=2C besides the vario= > >us integers=2C and nothing else. > > > >=20 > > > >=20 > > > >I think C# lets you define operators=2C yet people don't complain that it i= > >s "a mess" as they do of C++. > > > >I think Python does now too. > > > >So it is feature growing in popularity among "mainstream" languages=2C not = > >just C++. > > > > C++ of course is extremely mainstream=2C but also a favorite target. (ht= > >tp://www.relisoft.com/tools/CppCritic.html) > > > >=20 > > > >=20 > > > >We also have subranges of LONGINT. > > > >I'm not sure what the generalization of subranges are=2C granted. > > > > Maybe some sort of C++ template that takes constants in the template and d= > >oes range checks at runtime. Yeah=2C maybe. > > > >=20 > > > >=20 > > > >And as you point out=2C convenient literal syntax. > > > >=20 > > > >=20 > > > >People reasonably argue for library extension in place of language extensio= > >n=2C but that requires a language which is flexible enough to write librari= > >es with the desired interface=2C and so many languages don't let infix oper= > >ators be in a user-written library. > > > >(There is a subtle but useless distinction here -- infix operators being in= > > libraries vs. "user-written" libraries. The infix set operations for examp= > >le are in a library=2C but not user-written=2C special=2C the compiler know= > >s about it.) > > > >=20 > > > >> that would perhaps not match how C handles "long long" on the same > >> platform (which is how=2C come to think of it?)=2C and that would require > > > > > >=20 > > > >On NT/x86=2C __int64/long long is returned in the register pair edx:eax. > > > >edx is high=2C eax is low. > > > >When passed as a parameter to __stdcall or __cdecl is just passed as two 32= > >bit values adjacent on the stack=2C "hi=2C lo=2C hi=2C lo=2C it's off to pu= > >sh we go" is the Snow White-influenced mantra to remember how to pass them= > >=2C at least on little endian stack-growing-down machines (which includes x= > >86). For __fastcall I'm not sure they are passed in registers or on the sta= > >ck. > > > >Passing and/or returning small structs also has special efficient handling = > >in the ABI=2C so __int64 really might be equivalent to a small record. Not = > >that cm3 necessarily implements that "correctly" -- for interop with C=3B = > >for Modula-3 calling Modula-3 we can make up our own ABI so there isn't rea= > >lly an "incorrect" way. Notice the mingw problem I had passing a Win32 poin= > >t struct by value=2C I cheated and passed it by VAR to a C wrapper to worka= > >round the gcc backend bug (which was mentioned a few times and which I look= > >ed into the code for=2C but took the easy route) > > > >=20 > > > >=20 > > > >I don't know how long long works on other platforms but probably similar. > > > >Probably a certain register pair for return values. > > > >=20 > > > > - Jay > > > >=20 > >> To: hosking at cs.purdue.edu > >> Date: Sat=2C 17 Apr 2010 19:47:03 -0700 > >> From: mika at async.async.caltech.edu > >> CC: m3devel at elegosoft.com > >> Subject: Re: [M3devel] INTEGER > >>=20 > >> Tony Hosking writes: > >> > > >> ... > >> > > >> >> We need it to match 64-bit integers on 32-bit machines? That seems =3D > >> >like > >> >> a very weak rationale indeed=2C if the same functionality could be =3D > >> >provided > >> >> through some other mechanism (e.g.=2C ARRAY [0..1] OF INTEGER---even = > >=3D > >> >with > >> >> a pragma e.g. <*CLONGLONG*>.. if it is necessary to tell the compiler = > >=3D > >> >that > >> >> a special linkage convention is needed). > >> > > >> >There's no special linkage convention. Not sure what you mean here. > >> > > >>=20 > >> I just mean if we had > >>=20 > >> TYPE LONGINT =3D ARRAY [0..1] OF INTEGER > >>=20 > >> that would perhaps not match how C handles "long long" on the same > >> platform (which is how=2C come to think of it?)=2C and that would require > >> special linkage tricks. > >>=20 > >> But what would be lost? The ability to type literals.=20 > >>=20 > >> You could get the same code interface on 32- and 64-bit machine by > >> defining > >>=20 > >> TYPE FileOffset =3D ARRAY[0..1] OF [-16_80000000 .. +16_7fffffff ] > >>=20 > >> and using that. > >>=20 > >>=20 > >> Mika > > = > > > >--_264cb69b-0215-44c3-807c-8b4d8ea0ea59_ > >Content-Type: text/html; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > > > > > > > > > >TYPE LONGINT =3D ARRAY [0..1] OF INTEGER on a =3B32bit system is very c= > >lose to LONGINT.
> > =3BPlus treating it opaquely and providing a bunch of functions to ope= > >rate on it.
> > =3BJust as well therefore could be RECORD hi=2Clo:LONGINT END (see LAR= > >GE_INTEGER and ULARGE_INTEGER in winnt.h)
> > =3B
> >Differences that come to mind:
> > =3B =3Binfix operators =3B <=3B=3D=3D=3D
> > =3B possibly passed differently =3Bas a parameter
> > =3B or returned differently as a result
> > =3B ie. probably "directly compatible with" "long long"=2C passed by v= > >alue (of course you could always pass by pointer and achieve compatibilitit= > >y trivially)
> > =3B
> > =3B
> >I have to say though=2C the biggest reason is in-fix operators. Convenient = > >syntax.
> >C++ is the best and some way worst of example of the general right way to d= > >o this -- you let programmers define types and their infix operators. Other= > > languages just come with a passle of special cases of types that have in-f= > >ix operators.
> >A good example is that Java infix operator + on string=2C besides the vario= > >us integers=2C and nothing else.
> > =3B
> > =3B
> >I think C# lets you define operators=2C yet people don't complain that it i= > >s "a mess" as they do of C++.
> >I think Python does now too.
> >So it is feature growing in popularity among "mainstream" languages=2C not = > >just C++.
> > =3B =3B C++ of course is extremely mainstream=2C but also a favori= > >te target. (http:/= > >/www.relisoft.com/tools/CppCritic.html)
> > =3B
> > =3B
> >We also have subranges of LONGINT.
> >I'm not sure what the generalization of subranges are=2C granted.
> > =3BMaybe some sort of C++ template that takes constants in the templat= > >e and does range checks at runtime. Yeah=2C maybe.
> > =3B
> > =3B
> >And as you point out=2C convenient literal syntax.
> > =3B
> > =3B
> >People reasonably argue for library extension in place of language extensio= > >n=2C but that requires a language which is flexible enough to write librari= > >es with the desired interface=2C and so many languages don't let infix oper= > >ators be in a user-written library.
> >(There is a subtle but useless distinction here -- infix operators being in= > > libraries vs. "user-written" libraries. The infix set operations for examp= > >le are in a library=2C but not user-written=2C special=2C the compiler know= > >s about it.)
> > =3B
> >>=3B that would perhaps not match how C handles "long long" on the same >R>>=3B platform (which is how=2C come to think of it?)=2C and that would = > >require

> > =3B
> >On NT/x86=2C __int64/long long is returned in the register pair edx:eax. >> > >edx is high=2C eax is low.
> >When passed as a parameter to __stdcall or __cdecl is just passed as two 32= > >bit values adjacent on the stack=2C "hi=2C lo=2C hi=2C lo=2C it's off to pu= > >sh we go" is the Snow White-influenced mantra to remember how to pass them= > >=2C at least on little endian stack-growing-down machines (which includes x= > >86). For __fastcall I'm not sure they are passed in registers or on the sta= > >ck.
> >Passing and/or returning small structs also has special efficient handling = > >in the ABI=2C so __int64 really might be equivalent to a small record. Not = > >that cm3 necessarily implements that "correctly" =3B -- for interop wit= > >h C=3B for Modula-3 calling Modula-3 we can make up our own ABI so there is= > >n't =3Breally an "incorrect" way. =3BNotice the mingw problem I had= > > passing a Win32 point struct by value=2C I cheated and passed it by VAR to= > > a =3BC wrapper to workaround the gcc backend bug (which was mentioned = > >a few times and which I looked into the code for=2C but took the easy route= > >)
> > =3B
> > =3B
> >I don't know how long long works on other platforms but probably similar. >R> > >Probably a certain register pair for return values.
> > =3B
> > =3B- Jay

 =3B
>=3B To: hosking at cs.purdue.edu
>=3B= > > Date: Sat=2C 17 Apr 2010 19:47:03 -0700
>=3B From: mika at async.async.c= > >altech.edu
>=3B CC: m3devel at elegosoft.com
>=3B Subject: Re: [M3de= > >vel] INTEGER
>=3B
>=3B Tony Hosking writes:
>=3B >=3B
= > >>=3B ...
>=3B >=3B
>=3B >=3B>=3B We need it to match 64-b= > >it integers on 32-bit machines? That seems =3D
>=3B >=3Blike
>= > >=3B >=3B>=3B a very weak rationale indeed=2C if the same functionality = > >could be =3D
>=3B >=3Bprovided
>=3B >=3B>=3B through some o= > >ther mechanism (e.g.=2C ARRAY [0..1] OF INTEGER---even =3D
>=3B >=3B= > >with
>=3B >=3B>=3B a pragma e.g. <=3B*CLONGLONG*>=3B.. if it i= > >s necessary to tell the compiler =3D
>=3B >=3Bthat
>=3B >=3B&= > >gt=3B a special linkage convention is needed).
>=3B >=3B
>=3B &= > >gt=3BThere's no special linkage convention. Not sure what you mean here. >>>=3B >=3B
>=3B
>=3B I just mean if we had
>=3B
>= > >=3B TYPE LONGINT =3D ARRAY [0..1] OF INTEGER
>=3B
>=3B that woul= > >d perhaps not match how C handles "long long" on the same
>=3B platfor= > >m (which is how=2C come to think of it?)=2C and that would require
>= > >=3B special linkage tricks.
>=3B
>=3B But what would be lost? Th= > >e ability to type literals.
>=3B
>=3B You could get the same co= > >de interface on 32- and 64-bit machine by
>=3B defining
>=3B
= > >>=3B TYPE FileOffset =3D ARRAY[0..1] OF [-16_80000000 .. +16_7fffffff ] >R>>=3B
>=3B and using that.
>=3B
>=3B
>=3B Mika >> > >= > > > >--_264cb69b-0215-44c3-807c-8b4d8ea0ea59_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Apr 18 15:57:23 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 18 Apr 2010 13:57:23 +0000 Subject: [M3devel] Posix < 0 vs. # 0 vs. = -1? Message-ID: Posix often says: function foo() returns 0 for success, -1 for error m3core/libm3/etc, often say if foo() < 0 or if foo() # 0 "instead". Generally ok to tighten these up to "= -1", perhaps upon checking manpages, or a known rat's nest of inconsistencies? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Apr 18 16:10:50 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 18 Apr 2010 14:10:50 +0000 Subject: [M3devel] giant lock in SocketWin32.m3? In-Reply-To: <20100418140821.428882474008@birch.elegosoft.com> References: <20100418140821.428882474008@birch.elegosoft.com> Message-ID: Anyone know why SocketWin32.m3 has had a giant lock around everything? I see no point to it. The only global variable is related to on-demand initialization. And even that wasn't handled correctly.. - Jay > Date: Sun, 18 Apr 2010 16:08:20 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/04/18 16:08:20 > > Modified files: > cm3/m3-libs/libm3/src/os/WIN32/: SocketWin32.m3 > > Log message: > fix race condition and eliminate giant lock > I'm guessing the original authors didn't realize WSAGetLastError returns a thread local. ? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Apr 18 21:07:28 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 18 Apr 2010 15:07:28 -0400 Subject: [M3devel] INTEGER In-Reply-To: <20100418074927.934461A2117@async.async.caltech.edu> References: , , , <7C7408D0-9A40-4988-BADA-A9FD8C15D388@cs.purdue.edu>, , , , , , , <20100418023535.3BA9E1A2103@async.async.caltech.edu>, , <20100418024703.6965B1A2103@async.async.caltech.edu> <20100418074927.934461A2117@async.async.caltech.edu> Message-ID: <04EB7FF8-D304-428D-839E-233FCE009C98@cs.purdue.edu> In the language spec NUMBER(a) and LAST(a) - FIRST(a) + 1 are *not* defined to mean the same thing for all types. NUMBER does have an INTEGER value, as expected for subranges of LONGINT that are not too large. This is as it has always been for subranges of INTEGER that are not too large. Mika, I'm not sure I see any of the problems you are worrying about in the current definition of LONGINT/LONGCARD. On 18 Apr 2010, at 03:49, Mika Nystrom wrote: > > Jay I know most of this, and it doesn't really answer the question > "what is it for?" > > I think we've already established that LONGINT isn't useful for counting > anything that might actually reside in the computer's memory: it makes > no sense as an array index, for instance. INTEGER suffices for that. > > I thought that the only real reason for LONGINT was to match C's > declaration of various seek-related routines on 32-bit machines. > That's not a very good reason. > > C++ succeeds because it does very well in the area(s) it is good at. > People who want to program in C++ will clearly program in C++, not > Modula-3. Modula-3 is never, ever going to be the language of choice for > people who want lots of snazzy infix operators. Modula-3 is supposed to > be a language with about as powerful semantics as C++ and an extremely > simple syntax and definition---snazzy infix is one of the things you > give up for that. I don't see how LONGINT fits into this picture. > Now we have LONGCARD too? And it's infected the definitions > of FIRST and LAST? But not NUMBER... argh! > > so, > > NUMBER(a) and LAST(a) - FIRST(a) + 1 > > no longer mean the same thing? Are we going to see lots of comments > in generics in the future where it says T may not be an open array > type nor an array type indexed on LONGINT or a subrange thereof? > > Your comments about different parameter-passing techniques was what I was > trying to address with my suggestion to have a pragma for this---just to > match C (and Fortran?), of course. Name me a single Modula-3 programmer > who cares in what order the bits in his parameters are pushed on the > stack in a Modula-3-to-Modula-3 call. > > And I am definitely in that school of thought that says that programming > languages should not "evolve". Better to leave well enough alone. > > How much Modula-3 code has been written that uses LONGINT? Other than > to talk to C? I've certainly never used it. > > Mika > > > > Jay K writes: >> --_264cb69b-0215-44c3-807c-8b4d8ea0ea59_ >> Content-Type: text/plain; charset="iso-8859-1" >> Content-Transfer-Encoding: quoted-printable >> >> >> TYPE LONGINT =3D ARRAY [0..1] OF INTEGER on a 32bit system is very close to= >> LONGINT. >> >> Plus treating it opaquely and providing a bunch of functions to operate on= >> it. >> >> Just as well therefore could be RECORD hi=2Clo:LONGINT END (see LARGE_INTE= >> GER and ULARGE_INTEGER in winnt.h) >> >> =20 >> >> Differences that come to mind: >> >> infix operators <=3D=3D=3D=20 >> >> possibly passed differently as a parameter >> >> or returned differently as a result >> >> ie. probably "directly compatible with" "long long"=2C passed by value (o= >> f course you could always pass by pointer and achieve compatibilitity trivi= >> ally) >> >> =20 >> >> =20 >> >> I have to say though=2C the biggest reason is in-fix operators. Convenient = >> syntax. >> >> C++ is the best and some way worst of example of the general right way to d= >> o this -- you let programmers define types and their infix operators. Other= >> languages just come with a passle of special cases of types that have in-f= >> ix operators. >> >> A good example is that Java infix operator + on string=2C besides the vario= >> us integers=2C and nothing else. >> >> =20 >> >> =20 >> >> I think C# lets you define operators=2C yet people don't complain that it i= >> s "a mess" as they do of C++. >> >> I think Python does now too. >> >> So it is feature growing in popularity among "mainstream" languages=2C not = >> just C++. >> >> C++ of course is extremely mainstream=2C but also a favorite target. (ht= >> tp://www.relisoft.com/tools/CppCritic.html) >> >> =20 >> >> =20 >> >> We also have subranges of LONGINT. >> >> I'm not sure what the generalization of subranges are=2C granted. >> >> Maybe some sort of C++ template that takes constants in the template and d= >> oes range checks at runtime. Yeah=2C maybe. >> >> =20 >> >> =20 >> >> And as you point out=2C convenient literal syntax. >> >> =20 >> >> =20 >> >> People reasonably argue for library extension in place of language extensio= >> n=2C but that requires a language which is flexible enough to write librari= >> es with the desired interface=2C and so many languages don't let infix oper= >> ators be in a user-written library. >> >> (There is a subtle but useless distinction here -- infix operators being in= >> libraries vs. "user-written" libraries. The infix set operations for examp= >> le are in a library=2C but not user-written=2C special=2C the compiler know= >> s about it.) >> >> =20 >> >>> that would perhaps not match how C handles "long long" on the same >>> platform (which is how=2C come to think of it?)=2C and that would require >> >> >> =20 >> >> On NT/x86=2C __int64/long long is returned in the register pair edx:eax. >> >> edx is high=2C eax is low. >> >> When passed as a parameter to __stdcall or __cdecl is just passed as two 32= >> bit values adjacent on the stack=2C "hi=2C lo=2C hi=2C lo=2C it's off to pu= >> sh we go" is the Snow White-influenced mantra to remember how to pass them= >> =2C at least on little endian stack-growing-down machines (which includes x= >> 86). For __fastcall I'm not sure they are passed in registers or on the sta= >> ck. >> >> Passing and/or returning small structs also has special efficient handling = >> in the ABI=2C so __int64 really might be equivalent to a small record. Not = >> that cm3 necessarily implements that "correctly" -- for interop with C=3B = >> for Modula-3 calling Modula-3 we can make up our own ABI so there isn't rea= >> lly an "incorrect" way. Notice the mingw problem I had passing a Win32 poin= >> t struct by value=2C I cheated and passed it by VAR to a C wrapper to worka= >> round the gcc backend bug (which was mentioned a few times and which I look= >> ed into the code for=2C but took the easy route) >> >> =20 >> >> =20 >> >> I don't know how long long works on other platforms but probably similar. >> >> Probably a certain register pair for return values. >> >> =20 >> >> - Jay >> >> =20 >>> To: hosking at cs.purdue.edu >>> Date: Sat=2C 17 Apr 2010 19:47:03 -0700 >>> From: mika at async.async.caltech.edu >>> CC: m3devel at elegosoft.com >>> Subject: Re: [M3devel] INTEGER >>> =20 >>> Tony Hosking writes: >>>> >>> ... >>>> >>>>> We need it to match 64-bit integers on 32-bit machines? That seems =3D >>>> like >>>>> a very weak rationale indeed=2C if the same functionality could be =3D >>>> provided >>>>> through some other mechanism (e.g.=2C ARRAY [0..1] OF INTEGER---even = >> =3D >>>> with >>>>> a pragma e.g. <*CLONGLONG*>.. if it is necessary to tell the compiler = >> =3D >>>> that >>>>> a special linkage convention is needed). >>>> >>>> There's no special linkage convention. Not sure what you mean here. >>>> >>> =20 >>> I just mean if we had >>> =20 >>> TYPE LONGINT =3D ARRAY [0..1] OF INTEGER >>> =20 >>> that would perhaps not match how C handles "long long" on the same >>> platform (which is how=2C come to think of it?)=2C and that would require >>> special linkage tricks. >>> =20 >>> But what would be lost? The ability to type literals.=20 >>> =20 >>> You could get the same code interface on 32- and 64-bit machine by >>> defining >>> =20 >>> TYPE FileOffset =3D ARRAY[0..1] OF [-16_80000000 .. +16_7fffffff ] >>> =20 >>> and using that. >>> =20 >>> =20 >>> Mika >> = >> >> --_264cb69b-0215-44c3-807c-8b4d8ea0ea59_ >> Content-Type: text/html; charset="iso-8859-1" >> Content-Transfer-Encoding: quoted-printable >> >> >> >> >> >> >> TYPE LONGINT =3D ARRAY [0..1] OF INTEGER on a =3B32bit system is very c= >> lose to LONGINT.
>>  =3BPlus treating it opaquely and providing a bunch of functions to ope= >> rate on it.
>>  =3BJust as well therefore could be RECORD hi=2Clo:LONGINT END (see LAR= >> GE_INTEGER and ULARGE_INTEGER in winnt.h)
>>  =3B
>> Differences that come to mind:
>>  =3B =3Binfix operators =3B <=3B=3D=3D=3D
>>  =3B possibly passed differently =3Bas a parameter
>>  =3B or returned differently as a result
>>  =3B ie. probably "directly compatible with" "long long"=2C passed by v= >> alue (of course you could always pass by pointer and achieve compatibilitit= >> y trivially)
>>  =3B
>>  =3B
>> I have to say though=2C the biggest reason is in-fix operators. Convenient = >> syntax.
>> C++ is the best and some way worst of example of the general right way to d= >> o this -- you let programmers define types and their infix operators. Other= >> languages just come with a passle of special cases of types that have in-f= >> ix operators.
>> A good example is that Java infix operator + on string=2C besides the vario= >> us integers=2C and nothing else.
>>  =3B
>>  =3B
>> I think C# lets you define operators=2C yet people don't complain that it i= >> s "a mess" as they do of C++.
>> I think Python does now too.
>> So it is feature growing in popularity among "mainstream" languages=2C not = >> just C++.
>>  =3B =3B C++ of course is extremely mainstream=2C but also a favori= >> te target. (http:/= >> /www.relisoft.com/tools/CppCritic.html)
>>  =3B
>>  =3B
>> We also have subranges of LONGINT.
>> I'm not sure what the generalization of subranges are=2C granted.
>>  =3BMaybe some sort of C++ template that takes constants in the templat= >> e and does range checks at runtime. Yeah=2C maybe.
>>  =3B
>>  =3B
>> And as you point out=2C convenient literal syntax.
>>  =3B
>>  =3B
>> People reasonably argue for library extension in place of language extensio= >> n=2C but that requires a language which is flexible enough to write librari= >> es with the desired interface=2C and so many languages don't let infix oper= >> ators be in a user-written library.
>> (There is a subtle but useless distinction here -- infix operators being in= >> libraries vs. "user-written" libraries. The infix set operations for examp= >> le are in a library=2C but not user-written=2C special=2C the compiler know= >> s about it.)
>>  =3B
>> >=3B that would perhaps not match how C handles "long long" on the same> R>>=3B platform (which is how=2C come to think of it?)=2C and that would = >> require

>>  =3B
>> On NT/x86=2C __int64/long long is returned in the register pair edx:eax.>> >> edx is high=2C eax is low.
>> When passed as a parameter to __stdcall or __cdecl is just passed as two 32= >> bit values adjacent on the stack=2C "hi=2C lo=2C hi=2C lo=2C it's off to pu= >> sh we go" is the Snow White-influenced mantra to remember how to pass them= >> =2C at least on little endian stack-growing-down machines (which includes x= >> 86). For __fastcall I'm not sure they are passed in registers or on the sta= >> ck.
>> Passing and/or returning small structs also has special efficient handling = >> in the ABI=2C so __int64 really might be equivalent to a small record. Not = >> that cm3 necessarily implements that "correctly" =3B -- for interop wit= >> h C=3B for Modula-3 calling Modula-3 we can make up our own ABI so there is= >> n't =3Breally an "incorrect" way. =3BNotice the mingw problem I had= >> passing a Win32 point struct by value=2C I cheated and passed it by VAR to= >> a =3BC wrapper to workaround the gcc backend bug (which was mentioned = >> a few times and which I looked into the code for=2C but took the easy route= >> )
>>  =3B
>>  =3B
>> I don't know how long long works on other platforms but probably similar.> R> >> Probably a certain register pair for return values.
>>  =3B
>>  =3B- Jay

 =3B
>=3B To: hosking at cs.purdue.edu
>=3B= >> Date: Sat=2C 17 Apr 2010 19:47:03 -0700
>=3B From: mika at async.async.c= >> altech.edu
>=3B CC: m3devel at elegosoft.com
>=3B Subject: Re: [M3de= >> vel] INTEGER
>=3B
>=3B Tony Hosking writes:
>=3B >=3B
= >> >=3B ...
>=3B >=3B
>=3B >=3B>=3B We need it to match 64-b= >> it integers on 32-bit machines? That seems =3D
>=3B >=3Blike
>= >> =3B >=3B>=3B a very weak rationale indeed=2C if the same functionality = >> could be =3D
>=3B >=3Bprovided
>=3B >=3B>=3B through some o= >> ther mechanism (e.g.=2C ARRAY [0..1] OF INTEGER---even =3D
>=3B >=3B= >> with
>=3B >=3B>=3B a pragma e.g. <=3B*CLONGLONG*>=3B.. if it i= >> s necessary to tell the compiler =3D
>=3B >=3Bthat
>=3B >=3B&= >> gt=3B a special linkage convention is needed).
>=3B >=3B
>=3B &= >> gt=3BThere's no special linkage convention. Not sure what you mean here.>> >=3B >=3B
>=3B
>=3B I just mean if we had
>=3B
>= >> =3B TYPE LONGINT =3D ARRAY [0..1] OF INTEGER
>=3B
>=3B that woul= >> d perhaps not match how C handles "long long" on the same
>=3B platfor= >> m (which is how=2C come to think of it?)=2C and that would require
>= >> =3B special linkage tricks.
>=3B
>=3B But what would be lost? Th= >> e ability to type literals.
>=3B
>=3B You could get the same co= >> de interface on 32- and 64-bit machine by
>=3B defining
>=3B
= >> >=3B TYPE FileOffset =3D ARRAY[0..1] OF [-16_80000000 .. +16_7fffffff ]> R>>=3B
>=3B and using that.
>=3B
>=3B
>=3B Mika>> >> = >> >> --_264cb69b-0215-44c3-807c-8b4d8ea0ea59_-- From hosking at cs.purdue.edu Sun Apr 18 21:09:00 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 18 Apr 2010 15:09:00 -0400 Subject: [M3devel] Posix < 0 vs. # 0 vs. = -1? In-Reply-To: References: Message-ID: Checking < 0 is much cheaper than checking = -1. C idioms typically check < 0. -1 is simply a convenient negative value to return. Leave it as is. On 18 Apr 2010, at 09:57, Jay K wrote: > Posix often says: > function foo() returns 0 for success, -1 for error > > m3core/libm3/etc, often say if foo() < 0 or if foo() # 0 "instead". > Generally ok to tighten these up to "= -1", perhaps upon checking manpages, > or a known rat's nest of inconsistencies? > > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.async.caltech.edu Sun Apr 18 21:41:59 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Sun, 18 Apr 2010 12:41:59 -0700 Subject: [M3devel] Posix < 0 vs. # 0 vs. = -1? In-Reply-To: References: Message-ID: <20100418194159.E07411A2119@async.async.caltech.edu> Jay K writes: >--_201b8a99-e8e8-4887-bb32-c65e8edd0b1a_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >Posix often says: > > function foo() returns 0 for success=2C -1 for error > >=20 > > m3core/libm3/etc=2C often say if foo() < 0 or if foo() # 0 "instead". > Generally ok to tighten these up to "=3D -1"=2C perhaps upon checking manp= >ages=2C > or a known rat's nest of inconsistencies? > Maybe this is just my personal style, but I would code it thus: <*EXTERNAL*> PROCEDURE F() : INTEGER; (* matches C declaration *) ... VAR result : [0..1] := F(); (* matches man page specification *) BEGIN CASE result OF 0 => ... | -1 => ... END END No way for any sneaky value problems to get through. The use of CASE also guards against typos. Mika From mika at async.async.caltech.edu Sun Apr 18 21:59:01 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Sun, 18 Apr 2010 12:59:01 -0700 Subject: [M3devel] INTEGER In-Reply-To: <04EB7FF8-D304-428D-839E-233FCE009C98@cs.purdue.edu> References: , , , <7C7408D0-9A40-4988-BADA-A9FD8C15D388@cs.purdue.edu>, , , , , , , <20100418023535.3BA9E1A2103@async.async.caltech.edu>, , <20100418024703.6965B1A2103@async.async.caltech.edu> <20100418074927.934461A2117@async.async.caltech.edu> <04EB7FF8-D304-428D-839E-233FCE009C98@cs.purdue.edu> Message-ID: <20100418195901.CDACB1A20F6@async.async.caltech.edu> My problem is really just that it's ugly. LONGx is showing up as an issue in all sorts of low-level code, which is not surprising since Modula-3 with LONGx is not the same language as Modula-3 (maybe we should call it Modula-3+?) The compiler bootstrapping process has gotten more complicated due to it, and when I cvs updated m3tk yesterday stubgen wouldn't compile because there was something "long" in it that wasn't there before. I have no idea what library or components I needed to update and recompile and didn't have the time to deal with the issue at the time. And the new m3tk, stubgen, and compiler(?) won't compile using PM3 or SRC M3 since we're no longer using the language of the Green Book. (Same comment goes for WIDECHAR, by the way.) One of the wonderful things about Modula-3 *used to be* that I could grab some old package from DECSRC and just use it without changes since no one had messed with the language definition. This is still true as far as programs that just use the tools go, but it's no longer true for programs that process Modula-3 code as input data. Of which there are more than a few: many aspects of Modula-3 were specifically designed to make the language easy to process by program, as an intermediate format and whatnot. To quote E.W.D.: 'Unfathomed misunderstanding is further revealed by the term "software maintenance", as a result of which many people continue to believe that programs and even programming languages themselves are subject to wear and tear. Your car needs maintenance too, doesn't it? Famous is the story of the oil company that believed that its PASCAL programs did not last as long as its FORTRAN programs "because PASCAL was not maintained".' LONGx is causing me to have to do "software maintenance" on Modula-3 programs... for a feature that no one appears to be using and is quickly becoming irrelevant. Mika Tony Hosking writes: >In the language spec NUMBER(a) and LAST(a) - FIRST(a) + 1 are *not* = >defined to mean the same thing for all types. >NUMBER does have an INTEGER value, as expected for subranges of LONGINT = >that are not too large. >This is as it has always been for subranges of INTEGER that are not too = >large. > >Mika, I'm not sure I see any of the problems you are worrying about in = >the current definition of LONGINT/LONGCARD. > >On 18 Apr 2010, at 03:49, Mika Nystrom wrote: > >>=20 >> Jay I know most of this, and it doesn't really answer the question >> "what is it for?" >>=20 >> I think we've already established that LONGINT isn't useful for = >counting >> anything that might actually reside in the computer's memory: it makes >> no sense as an array index, for instance. INTEGER suffices for that. >>=20 >> I thought that the only real reason for LONGINT was to match C's >> declaration of various seek-related routines on 32-bit machines. >> That's not a very good reason. >>=20 >> C++ succeeds because it does very well in the area(s) it is good at. >> People who want to program in C++ will clearly program in C++, not >> Modula-3. Modula-3 is never, ever going to be the language of choice = >for >> people who want lots of snazzy infix operators. Modula-3 is supposed = >to >> be a language with about as powerful semantics as C++ and an extremely >> simple syntax and definition---snazzy infix is one of the things you >> give up for that. I don't see how LONGINT fits into this picture. >> Now we have LONGCARD too? And it's infected the definitions >> of FIRST and LAST? But not NUMBER... argh! >>=20 >> so, >>=20 >> NUMBER(a) and LAST(a) - FIRST(a) + 1 >>=20 >> no longer mean the same thing? Are we going to see lots of comments >> in generics in the future where it says T may not be an open array >> type nor an array type indexed on LONGINT or a subrange thereof? >>=20 >> Your comments about different parameter-passing techniques was what I = >was >> trying to address with my suggestion to have a pragma for this---just = >to >> match C (and Fortran?), of course. Name me a single Modula-3 = >programmer >> who cares in what order the bits in his parameters are pushed on the >> stack in a Modula-3-to-Modula-3 call. >>=20 >> And I am definitely in that school of thought that says that = >programming >> languages should not "evolve". Better to leave well enough alone. >>=20 >> How much Modula-3 code has been written that uses LONGINT? Other than >> to talk to C? I've certainly never used it. >>=20 >> Mika >>=20 >>=20 >>=20 >> Jay K writes: >>> --_264cb69b-0215-44c3-807c-8b4d8ea0ea59_ >>> Content-Type: text/plain; charset=3D"iso-8859-1" >>> Content-Transfer-Encoding: quoted-printable >>>=20 >>>=20 >>> TYPE LONGINT =3D3D ARRAY [0..1] OF INTEGER on a 32bit system is very = >close to=3D >>> LONGINT. >>>=20 >>> Plus treating it opaquely and providing a bunch of functions to = >operate on=3D >>> it. >>>=20 >>> Just as well therefore could be RECORD hi=3D2Clo:LONGINT END (see = >LARGE_INTE=3D >>> GER and ULARGE_INTEGER in winnt.h) >>>=20 >>> =3D20 >>>=20 >>> Differences that come to mind: >>>=20 >>> infix operators <=3D3D=3D3D=3D3D=3D20 >>>=20 >>> possibly passed differently as a parameter >>>=20 >>> or returned differently as a result >>>=20 >>> ie. probably "directly compatible with" "long long"=3D2C passed by = >value (o=3D >>> f course you could always pass by pointer and achieve compatibilitity = >trivi=3D >>> ally) >>>=20 >>> =3D20 >>>=20 >>> =3D20 >>>=20 >>> I have to say though=3D2C the biggest reason is in-fix operators. = >Convenient =3D >>> syntax. >>>=20 >>> C++ is the best and some way worst of example of the general right = >way to d=3D >>> o this -- you let programmers define types and their infix operators. = >Other=3D >>> languages just come with a passle of special cases of types that have = >in-f=3D >>> ix operators. >>>=20 >>> A good example is that Java infix operator + on string=3D2C besides = >the vario=3D >>> us integers=3D2C and nothing else. >>>=20 >>> =3D20 >>>=20 >>> =3D20 >>>=20 >>> I think C# lets you define operators=3D2C yet people don't complain = >that it i=3D >>> s "a mess" as they do of C++. >>>=20 >>> I think Python does now too. >>>=20 >>> So it is feature growing in popularity among "mainstream" = >languages=3D2C not =3D >>> just C++. >>>=20 >>> C++ of course is extremely mainstream=3D2C but also a favorite = >target. (ht=3D >>> tp://www.relisoft.com/tools/CppCritic.html) >>>=20 >>> =3D20 >>>=20 >>> =3D20 >>>=20 >>> We also have subranges of LONGINT. >>>=20 >>> I'm not sure what the generalization of subranges are=3D2C granted. >>>=20 >>> Maybe some sort of C++ template that takes constants in the template = >and d=3D >>> oes range checks at runtime. Yeah=3D2C maybe. >>>=20 >>> =3D20 >>>=20 >>> =3D20 >>>=20 >>> And as you point out=3D2C convenient literal syntax. >>>=20 >>> =3D20 >>>=20 >>> =3D20 >>>=20 >>> People reasonably argue for library extension in place of language = >extensio=3D >>> n=3D2C but that requires a language which is flexible enough to write = >librari=3D >>> es with the desired interface=3D2C and so many languages don't let = >infix oper=3D >>> ators be in a user-written library. >>>=20 >>> (There is a subtle but useless distinction here -- infix operators = >being in=3D >>> libraries vs. "user-written" libraries. The infix set operations for = >examp=3D >>> le are in a library=3D2C but not user-written=3D2C special=3D2C the = >compiler know=3D >>> s about it.) >>>=20 >>> =3D20 >>>=20 >>>> that would perhaps not match how C handles "long long" on the same >>>> platform (which is how=3D2C come to think of it?)=3D2C and that = >would require >>>=20 >>>=20 >>> =3D20 >>>=20 >>> On NT/x86=3D2C __int64/long long is returned in the register pair = >edx:eax. >>>=20 >>> edx is high=3D2C eax is low. >>>=20 >>> When passed as a parameter to __stdcall or __cdecl is just passed as = >two 32=3D >>> bit values adjacent on the stack=3D2C "hi=3D2C lo=3D2C hi=3D2C lo=3D2C = >it's off to pu=3D >> sh we go" is the Snow White-influenced mantra to remember how to pass = >them=3D >>> =3D2C at least on little endian stack-growing-down machines (which = >includes x=3D >>> 86). For __fastcall I'm not sure they are passed in registers or on = >the sta=3D >>> ck. >>>=20 >>> Passing and/or returning small structs also has special efficient = >handling =3D >>> in the ABI=3D2C so __int64 really might be equivalent to a small = >record. Not =3D >>> that cm3 necessarily implements that "correctly" -- for interop with = >C=3D3B =3D >>> for Modula-3 calling Modula-3 we can make up our own ABI so there = >isn't rea=3D >>> lly an "incorrect" way. Notice the mingw problem I had passing a = >Win32 poin=3D >>> t struct by value=3D2C I cheated and passed it by VAR to a C wrapper = >to worka=3D >>> round the gcc backend bug (which was mentioned a few times and which = >I look=3D >>> ed into the code for=3D2C but took the easy route) >>>=20 >>> =3D20 >>>=20 >>> =3D20 >>>=20 >>> I don't know how long long works on other platforms but probably = >similar. >>>=20 >>> Probably a certain register pair for return values. >>>=20 >>> =3D20 >>>=20 >>> - Jay >>>=20 >>> =3D20 >>>> To: hosking at cs.purdue.edu >>>> Date: Sat=3D2C 17 Apr 2010 19:47:03 -0700 >>>> From: mika at async.async.caltech.edu >>>> CC: m3devel at elegosoft.com >>>> Subject: Re: [M3devel] INTEGER >>>> =3D20 >>>> Tony Hosking writes: >>>>>=20 >>>> ... >>>>>=20 >>>>>> We need it to match 64-bit integers on 32-bit machines? That seems = >=3D3D >>>>> like >>>>>> a very weak rationale indeed=3D2C if the same functionality could = >be =3D3D >>>>> provided >>>>>> through some other mechanism (e.g.=3D2C ARRAY [0..1] OF = >INTEGER---even =3D >>> =3D3D >>>>> with >>>>>> a pragma e.g. <*CLONGLONG*>.. if it is necessary to tell the = >compiler =3D >>> =3D3D >>>>> that >>>>>> a special linkage convention is needed). >>>>>=20 >>>>> There's no special linkage convention. Not sure what you mean here. >>>>>=20 >>>> =3D20 >>>> I just mean if we had >>>> =3D20 >>>> TYPE LONGINT =3D3D ARRAY [0..1] OF INTEGER >>>> =3D20 >>>> that would perhaps not match how C handles "long long" on the same >>>> platform (which is how=3D2C come to think of it?)=3D2C and that = >would require >>>> special linkage tricks. >>>> =3D20 >>>> But what would be lost? The ability to type literals.=3D20 >>>> =3D20 >>>> You could get the same code interface on 32- and 64-bit machine by >>>> defining >>>> =3D20 >>>> TYPE FileOffset =3D3D ARRAY[0..1] OF [-16_80000000 .. +16_7fffffff ] >>>> =3D20 >>>> and using that. >>>> =3D20 >>>> =3D20 >>>> Mika >>> =3D >>>=20 >>> --_264cb69b-0215-44c3-807c-8b4d8ea0ea59_ >>> Content-Type: text/html; charset=3D"iso-8859-1" >>> Content-Transfer-Encoding: quoted-printable >>>=20 >>> >>> >>> >>> >>> >>> TYPE LONGINT =3D3D ARRAY [0..1] OF INTEGER on a =3D3B32bit system = >is very c=3D >>> lose to LONGINT.
>>>  =3D3BPlus treating it opaquely and providing a bunch of = >functions to ope=3D >>> rate on it.
>>>  =3D3BJust as well therefore could be RECORD hi=3D2Clo:LONGINT = >END (see LAR=3D >>> GE_INTEGER and ULARGE_INTEGER in winnt.h)
>>>  =3D3B
>>> Differences that come to mind:
>>>  =3D3B =3D3Binfix operators =3D3B <=3D3B=3D3D=3D3D=3D3D = >
>>>  =3D3B possibly passed differently =3D3Bas a parameter
>>>  =3D3B or returned differently as a result
>>>  =3D3B ie. probably "directly compatible with" "long long"=3D2C = >passed by v=3D >>> alue (of course you could always pass by pointer and achieve = >compatibilitit=3D >>> y trivially)
>>>  =3D3B
>>>  =3D3B
>>> I have to say though=3D2C the biggest reason is in-fix operators. = >Convenient =3D >>> syntax.
>>> C++ is the best and some way worst of example of the general right = >way to d=3D >>> o this -- you let programmers define types and their infix operators. = >Other=3D >>> languages just come with a passle of special cases of types that have = >in-f=3D >>> ix operators.
>>> A good example is that Java infix operator + on string=3D2C besides = >the vario=3D >>> us integers=3D2C and nothing else.
>>>  =3D3B
>>>  =3D3B
>>> I think C# lets you define operators=3D2C yet people don't complain = >that it i=3D >>> s "a mess" as they do of C++.
>>> I think Python does now too.
>>> So it is feature growing in popularity among "mainstream" = >languages=3D2C not =3D >>> just C++.
>>>  =3D3B =3D3B C++ of course is extremely mainstream=3D2C but = >also a favori=3D >>> te target. (href=3D3D"http://www.relisoft.com/tools/CppCritic.html">http:/=3D >>> /www.relisoft.com/tools/CppCritic.html)
>>>  =3D3B
>>>  =3D3B
>>> We also have subranges of LONGINT.
>>> I'm not sure what the generalization of subranges are=3D2C = >granted.
>>>  =3D3BMaybe some sort of C++ template that takes constants in the = >templat=3D >>> e and does range checks at runtime. Yeah=3D2C maybe.
>>>  =3D3B
>>>  =3D3B
>>> And as you point out=3D2C convenient literal syntax.
>>>  =3D3B
>>>  =3D3B
>>> People reasonably argue for library extension in place of language = >extensio=3D >>> n=3D2C but that requires a language which is flexible enough to write = >librari=3D >>> es with the desired interface=3D2C and so many languages don't let = >infix oper=3D >>> ators be in a user-written library.
>>> (There is a subtle but useless distinction here -- infix operators = >being in=3D >>> libraries vs. "user-written" libraries. The infix set operations for = >examp=3D >>> le are in a library=3D2C but not user-written=3D2C special=3D2C the = >compiler know=3D >>> s about it.)
>>>  =3D3B
>>> >=3D3B that would perhaps not match how C handles "long long" on = >the same>> R>>=3D3B platform (which is how=3D2C come to think of it?)=3D2C and = >that would =3D >>> require

>>>  =3D3B
>>> On NT/x86=3D2C __int64/long long is returned in the register pair = >edx:eax.>>>=20 >>> edx is high=3D2C eax is low.
>>> When passed as a parameter to __stdcall or __cdecl is just passed as = >two 32=3D >>> bit values adjacent on the stack=3D2C "hi=3D2C lo=3D2C hi=3D2C lo=3D2C = >it's off to pu=3D >>> sh we go" is the Snow White-influenced mantra to remember how to pass = >them=3D >>> =3D2C at least on little endian stack-growing-down machines (which = >includes x=3D >>> 86). For __fastcall I'm not sure they are passed in registers or on = >the sta=3D >>> ck.
>>> Passing and/or returning small structs also has special efficient = >handling =3D >>> in the ABI=3D2C so __int64 really might be equivalent to a small = >record. Not =3D >>> that cm3 necessarily implements that "correctly" =3D3B -- for = >interop wit=3D >>> h C=3D3B for Modula-3 calling Modula-3 we can make up our own ABI so = >there is=3D >>> n't =3D3Breally an "incorrect" way. =3D3BNotice the mingw = >problem I had=3D >>> passing a Win32 point struct by value=3D2C I cheated and passed it by = >VAR to=3D >>> a =3D3BC wrapper to workaround the gcc backend bug (which was = >mentioned =3D >>> a few times and which I looked into the code for=3D2C but took the = >easy route=3D >>> )
>>>  =3D3B
>>>  =3D3B
>>> I don't know how long long works on other platforms but probably = >similar.>> R> >>> Probably a certain register pair for return values.
>>>  =3D3B
>>>  =3D3B- Jay

 =3D3B
>=3D3B To: = >hosking at cs.purdue.edu
>=3D3B=3D >>> Date: Sat=3D2C 17 Apr 2010 19:47:03 -0700
>=3D3B From: = >mika at async.async.c=3D >>> altech.edu
>=3D3B CC: m3devel at elegosoft.com
>=3D3B Subject: = >Re: [M3de=3D >>> vel] INTEGER
>=3D3B
>=3D3B Tony Hosking writes:
>=3D3B = >>=3D3B
=3D >>> >=3D3B ...
>=3D3B >=3D3B
>=3D3B >=3D3B>=3D3B We = >need it to match 64-b=3D >>> it integers on 32-bit machines? That seems =3D3D
>=3D3B = >>=3D3Blike
>=3D >>> =3D3B >=3D3B>=3D3B a very weak rationale indeed=3D2C if the same = >functionality =3D >>> could be =3D3D
>=3D3B >=3D3Bprovided
>=3D3B >=3D3B>=3D3= >B through some o=3D >>> ther mechanism (e.g.=3D2C ARRAY [0..1] OF INTEGER---even = >=3D3D
>=3D3B >=3D3B=3D >>> with
>=3D3B >=3D3B>=3D3B a pragma e.g. = ><=3D3B*CLONGLONG*>=3D3B.. if it i=3D >>> s necessary to tell the compiler =3D3D
>=3D3B = >>=3D3Bthat
>=3D3B >=3D3B&=3D >>> gt=3D3B a special linkage convention is needed).
>=3D3B = >>=3D3B
>=3D3B &=3D >>> gt=3D3BThere's no special linkage convention. Not sure what you mean = >here.>>> >=3D3B >=3D3B
>=3D3B
>=3D3B I just mean if we = >had
>=3D3B
>=3D >>> =3D3B TYPE LONGINT =3D3D ARRAY [0..1] OF INTEGER
>=3D3B = >
>=3D3B that woul=3D >>> d perhaps not match how C handles "long long" on the same
>=3D3B = >platfor=3D >>> m (which is how=3D2C come to think of it?)=3D2C and that would = >require
>=3D >>> =3D3B special linkage tricks.
>=3D3B
>=3D3B But what would = >be lost? Th=3D >>> e ability to type literals.
>=3D3B
>=3D3B You could get = >the same co=3D >>> de interface on 32- and 64-bit machine by
>=3D3B = >defining
>=3D3B
=3D >>> >=3D3B TYPE FileOffset =3D3D ARRAY[0..1] OF [-16_80000000 .. = >+16_7fffffff ]>> R>>=3D3B
>=3D3B and using that.
>=3D3B
>=3D3B = >
>=3D3B Mika>>> >>> =3D >>>=20 >>> --_264cb69b-0215-44c3-807c-8b4d8ea0ea59_-- From hosking at cs.purdue.edu Mon Apr 19 02:38:43 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 18 Apr 2010 20:38:43 -0400 Subject: [M3devel] INTEGER In-Reply-To: <20100418195901.CDACB1A20F6@async.async.caltech.edu> References: , , , <7C7408D0-9A40-4988-BADA-A9FD8C15D388@cs.purdue.edu>, , , , , , , <20100418023535.3BA9E1A2103@async.async.caltech.edu>, , <20100418024703.6965B1A2103@async.async.caltech.edu> <20100418074927.934461A2117@async.async.caltech.edu> <04EB7FF8-D304-428D-839E-233FCE009C98@cs.purdue.edu> <20100418195901.CDACB1A20F6@async.async.caltech.edu> Message-ID: Mika, First off, I'd be very interested to know what the issues are with LONGINT and stubgen. We are building that every day in regression testing. It would be really good to get some precise feedback. True, LONGINT is integrated with all of the language tools (same as WIDECHAR). I suppose that is the price we pay for the language having evolved. Nevertheless, CM3 should be totally backward compatible with the green book. There is no reason it should not build packages from PM3 or SRC. Now, this is not to say that perhaps we haven't overreached with LONGINT given that 64-bit is more prevalent. But then it is also useful to be able to interoperate with C libraries. The previous interfacing was pretty much a kludge, using ARRAY[0..1] OF INTEGER for "long long" but then not propagating the double INTEGER value properly throughout the Modula-3 libraries. I'm sorry to say that EWD was not particularly renowned for his practicality; pedant more like. Nice to be high and mighty but we also need to interact with the real world. We should be able to make this work. Is there a better alternative? Revoke LONGINT, and WIDECHAR? On 18 Apr 2010, at 15:59, Mika Nystrom wrote: > > My problem is really just that it's ugly. LONGx is showing up as an issue > in all sorts of low-level code, which is not surprising since Modula-3 > with LONGx is not the same language as Modula-3 (maybe we should call > it Modula-3+?) > > The compiler bootstrapping process has gotten more complicated due to it, > and when I cvs updated m3tk yesterday stubgen wouldn't compile because there > was something "long" in it that wasn't there before. I have no idea what > library or components I needed to update and recompile and didn't have the > time to deal with the issue at the time. > > And the new m3tk, stubgen, and compiler(?) won't compile using PM3 or > SRC M3 since we're no longer using the language of the Green Book. > (Same comment goes for WIDECHAR, by the way.) > > One of the wonderful things about Modula-3 *used to be* that I could > grab some old package from DECSRC and just use it without changes since > no one had messed with the language definition. This is still true as > far as programs that just use the tools go, but it's no longer true for > programs that process Modula-3 code as input data. Of which there are > more than a few: many aspects of Modula-3 were specifically designed to > make the language easy to process by program, as an intermediate format > and whatnot. > > To quote E.W.D.: > > 'Unfathomed misunderstanding is further revealed by the term "software > maintenance", as a result of which many people continue to believe that > programs and even programming languages themselves are subject to wear > and tear. Your car needs maintenance too, doesn't it? Famous is the story > of the oil company that believed that its PASCAL programs did not last > as long as its FORTRAN programs "because PASCAL was not maintained".' > > LONGx is causing me to have to do "software maintenance" on Modula-3 > programs... for a feature that no one appears to be using and is quickly > becoming irrelevant. > > Mika > > > Tony Hosking writes: >> In the language spec NUMBER(a) and LAST(a) - FIRST(a) + 1 are *not* = >> defined to mean the same thing for all types. >> NUMBER does have an INTEGER value, as expected for subranges of LONGINT = >> that are not too large. >> This is as it has always been for subranges of INTEGER that are not too = >> large. >> >> Mika, I'm not sure I see any of the problems you are worrying about in = >> the current definition of LONGINT/LONGCARD. >> >> On 18 Apr 2010, at 03:49, Mika Nystrom wrote: >> >>> =20 >>> Jay I know most of this, and it doesn't really answer the question >>> "what is it for?" >>> =20 >>> I think we've already established that LONGINT isn't useful for = >> counting >>> anything that might actually reside in the computer's memory: it makes >>> no sense as an array index, for instance. INTEGER suffices for that. >>> =20 >>> I thought that the only real reason for LONGINT was to match C's >>> declaration of various seek-related routines on 32-bit machines. >>> That's not a very good reason. >>> =20 >>> C++ succeeds because it does very well in the area(s) it is good at. >>> People who want to program in C++ will clearly program in C++, not >>> Modula-3. Modula-3 is never, ever going to be the language of choice = >> for >>> people who want lots of snazzy infix operators. Modula-3 is supposed = >> to >>> be a language with about as powerful semantics as C++ and an extremely >>> simple syntax and definition---snazzy infix is one of the things you >>> give up for that. I don't see how LONGINT fits into this picture. >>> Now we have LONGCARD too? And it's infected the definitions >>> of FIRST and LAST? But not NUMBER... argh! >>> =20 >>> so, >>> =20 >>> NUMBER(a) and LAST(a) - FIRST(a) + 1 >>> =20 >>> no longer mean the same thing? Are we going to see lots of comments >>> in generics in the future where it says T may not be an open array >>> type nor an array type indexed on LONGINT or a subrange thereof? >>> =20 >>> Your comments about different parameter-passing techniques was what I = >> was >>> trying to address with my suggestion to have a pragma for this---just = >> to >>> match C (and Fortran?), of course. Name me a single Modula-3 = >> programmer >>> who cares in what order the bits in his parameters are pushed on the >>> stack in a Modula-3-to-Modula-3 call. >>> =20 >>> And I am definitely in that school of thought that says that = >> programming >>> languages should not "evolve". Better to leave well enough alone. >>> =20 >>> How much Modula-3 code has been written that uses LONGINT? Other than >>> to talk to C? I've certainly never used it. >>> =20 >>> Mika >>> =20 >>> =20 >>> =20 >>> Jay K writes: >>>> --_264cb69b-0215-44c3-807c-8b4d8ea0ea59_ >>>> Content-Type: text/plain; charset=3D"iso-8859-1" >>>> Content-Transfer-Encoding: quoted-printable >>>> =20 >>>> =20 >>>> TYPE LONGINT =3D3D ARRAY [0..1] OF INTEGER on a 32bit system is very = >> close to=3D >>>> LONGINT. >>>> =20 >>>> Plus treating it opaquely and providing a bunch of functions to = >> operate on=3D >>>> it. >>>> =20 >>>> Just as well therefore could be RECORD hi=3D2Clo:LONGINT END (see = >> LARGE_INTE=3D >>>> GER and ULARGE_INTEGER in winnt.h) >>>> =20 >>>> =3D20 >>>> =20 >>>> Differences that come to mind: >>>> =20 >>>> infix operators <=3D3D=3D3D=3D3D=3D20 >>>> =20 >>>> possibly passed differently as a parameter >>>> =20 >>>> or returned differently as a result >>>> =20 >>>> ie. probably "directly compatible with" "long long"=3D2C passed by = >> value (o=3D >>>> f course you could always pass by pointer and achieve compatibilitity = >> trivi=3D >>>> ally) >>>> =20 >>>> =3D20 >>>> =20 >>>> =3D20 >>>> =20 >>>> I have to say though=3D2C the biggest reason is in-fix operators. = >> Convenient =3D >>>> syntax. >>>> =20 >>>> C++ is the best and some way worst of example of the general right = >> way to d=3D >>>> o this -- you let programmers define types and their infix operators. = >> Other=3D >>>> languages just come with a passle of special cases of types that have = >> in-f=3D >>>> ix operators. >>>> =20 >>>> A good example is that Java infix operator + on string=3D2C besides = >> the vario=3D >>>> us integers=3D2C and nothing else. >>>> =20 >>>> =3D20 >>>> =20 >>>> =3D20 >>>> =20 >>>> I think C# lets you define operators=3D2C yet people don't complain = >> that it i=3D >>>> s "a mess" as they do of C++. >>>> =20 >>>> I think Python does now too. >>>> =20 >>>> So it is feature growing in popularity among "mainstream" = >> languages=3D2C not =3D >>>> just C++. >>>> =20 >>>> C++ of course is extremely mainstream=3D2C but also a favorite = >> target. (ht=3D >>>> tp://www.relisoft.com/tools/CppCritic.html) >>>> =20 >>>> =3D20 >>>> =20 >>>> =3D20 >>>> =20 >>>> We also have subranges of LONGINT. >>>> =20 >>>> I'm not sure what the generalization of subranges are=3D2C granted. >>>> =20 >>>> Maybe some sort of C++ template that takes constants in the template = >> and d=3D >>>> oes range checks at runtime. Yeah=3D2C maybe. >>>> =20 >>>> =3D20 >>>> =20 >>>> =3D20 >>>> =20 >>>> And as you point out=3D2C convenient literal syntax. >>>> =20 >>>> =3D20 >>>> =20 >>>> =3D20 >>>> =20 >>>> People reasonably argue for library extension in place of language = >> extensio=3D >>>> n=3D2C but that requires a language which is flexible enough to write = >> librari=3D >>>> es with the desired interface=3D2C and so many languages don't let = >> infix oper=3D >>>> ators be in a user-written library. >>>> =20 >>>> (There is a subtle but useless distinction here -- infix operators = >> being in=3D >>>> libraries vs. "user-written" libraries. The infix set operations for = >> examp=3D >>>> le are in a library=3D2C but not user-written=3D2C special=3D2C the = >> compiler know=3D >>>> s about it.) >>>> =20 >>>> =3D20 >>>> =20 >>>>> that would perhaps not match how C handles "long long" on the same >>>>> platform (which is how=3D2C come to think of it?)=3D2C and that = >> would require >>>> =20 >>>> =20 >>>> =3D20 >>>> =20 >>>> On NT/x86=3D2C __int64/long long is returned in the register pair = >> edx:eax. >>>> =20 >>>> edx is high=3D2C eax is low. >>>> =20 >>>> When passed as a parameter to __stdcall or __cdecl is just passed as = >> two 32=3D >>>> bit values adjacent on the stack=3D2C "hi=3D2C lo=3D2C hi=3D2C lo=3D2C = >> it's off to pu=3D >>> sh we go" is the Snow White-influenced mantra to remember how to pass = >> them=3D >>>> =3D2C at least on little endian stack-growing-down machines (which = >> includes x=3D >>>> 86). For __fastcall I'm not sure they are passed in registers or on = >> the sta=3D >>>> ck. >>>> =20 >>>> Passing and/or returning small structs also has special efficient = >> handling =3D >>>> in the ABI=3D2C so __int64 really might be equivalent to a small = >> record. Not =3D >>>> that cm3 necessarily implements that "correctly" -- for interop with = >> C=3D3B =3D >>>> for Modula-3 calling Modula-3 we can make up our own ABI so there = >> isn't rea=3D >>>> lly an "incorrect" way. Notice the mingw problem I had passing a = >> Win32 poin=3D >>>> t struct by value=3D2C I cheated and passed it by VAR to a C wrapper = >> to worka=3D >>>> round the gcc backend bug (which was mentioned a few times and which = >> I look=3D >>>> ed into the code for=3D2C but took the easy route) >>>> =20 >>>> =3D20 >>>> =20 >>>> =3D20 >>>> =20 >>>> I don't know how long long works on other platforms but probably = >> similar. >>>> =20 >>>> Probably a certain register pair for return values. >>>> =20 >>>> =3D20 >>>> =20 >>>> - Jay >>>> =20 >>>> =3D20 >>>>> To: hosking at cs.purdue.edu >>>>> Date: Sat=3D2C 17 Apr 2010 19:47:03 -0700 >>>>> From: mika at async.async.caltech.edu >>>>> CC: m3devel at elegosoft.com >>>>> Subject: Re: [M3devel] INTEGER >>>>> =3D20 >>>>> Tony Hosking writes: >>>>>> =20 >>>>> ... >>>>>> =20 >>>>>>> We need it to match 64-bit integers on 32-bit machines? That seems = >> =3D3D >>>>>> like >>>>>>> a very weak rationale indeed=3D2C if the same functionality could = >> be =3D3D >>>>>> provided >>>>>>> through some other mechanism (e.g.=3D2C ARRAY [0..1] OF = >> INTEGER---even =3D >>>> =3D3D >>>>>> with >>>>>>> a pragma e.g. <*CLONGLONG*>.. if it is necessary to tell the = >> compiler =3D >>>> =3D3D >>>>>> that >>>>>>> a special linkage convention is needed). >>>>>> =20 >>>>>> There's no special linkage convention. Not sure what you mean here. >>>>>> =20 >>>>> =3D20 >>>>> I just mean if we had >>>>> =3D20 >>>>> TYPE LONGINT =3D3D ARRAY [0..1] OF INTEGER >>>>> =3D20 >>>>> that would perhaps not match how C handles "long long" on the same >>>>> platform (which is how=3D2C come to think of it?)=3D2C and that = >> would require >>>>> special linkage tricks. >>>>> =3D20 >>>>> But what would be lost? The ability to type literals.=3D20 >>>>> =3D20 >>>>> You could get the same code interface on 32- and 64-bit machine by >>>>> defining >>>>> =3D20 >>>>> TYPE FileOffset =3D3D ARRAY[0..1] OF [-16_80000000 .. +16_7fffffff ] >>>>> =3D20 >>>>> and using that. >>>>> =3D20 >>>>> =3D20 >>>>> Mika >>>> =3D >>>> =20 >>>> --_264cb69b-0215-44c3-807c-8b4d8ea0ea59_ >>>> Content-Type: text/html; charset=3D"iso-8859-1" >>>> Content-Transfer-Encoding: quoted-printable >>>> =20 >>>> >>>> >>>> >>>> >>>> >>>> TYPE LONGINT =3D3D ARRAY [0..1] OF INTEGER on a =3D3B32bit system = >> is very c=3D >>>> lose to LONGINT.
>>>>  =3D3BPlus treating it opaquely and providing a bunch of = >> functions to ope=3D >>>> rate on it.
>>>>  =3D3BJust as well therefore could be RECORD hi=3D2Clo:LONGINT = >> END (see LAR=3D >>>> GE_INTEGER and ULARGE_INTEGER in winnt.h)
>>>>  =3D3B
>>>> Differences that come to mind:
>>>>  =3D3B =3D3Binfix operators =3D3B <=3D3B=3D3D=3D3D=3D3D = >>
>>>>  =3D3B possibly passed differently =3D3Bas a parameter
>>>>  =3D3B or returned differently as a result
>>>>  =3D3B ie. probably "directly compatible with" "long long"=3D2C = >> passed by v=3D >>>> alue (of course you could always pass by pointer and achieve = >> compatibilitit=3D >>>> y trivially)
>>>>  =3D3B
>>>>  =3D3B
>>>> I have to say though=3D2C the biggest reason is in-fix operators. = >> Convenient =3D >>>> syntax.
>>>> C++ is the best and some way worst of example of the general right = >> way to d=3D >>>> o this -- you let programmers define types and their infix operators. = >> Other=3D >>>> languages just come with a passle of special cases of types that have = >> in-f=3D >>>> ix operators.
>>>> A good example is that Java infix operator + on string=3D2C besides = >> the vario=3D >>>> us integers=3D2C and nothing else.
>>>>  =3D3B
>>>>  =3D3B
>>>> I think C# lets you define operators=3D2C yet people don't complain = >> that it i=3D >>>> s "a mess" as they do of C++.
>>>> I think Python does now too.
>>>> So it is feature growing in popularity among "mainstream" = >> languages=3D2C not =3D >>>> just C++.
>>>>  =3D3B =3D3B C++ of course is extremely mainstream=3D2C but = >> also a favori=3D >>>> te target. (> href=3D3D"http://www.relisoft.com/tools/CppCritic.html">http:/=3D >>>> /www.relisoft.com/tools/CppCritic.html)
>>>>  =3D3B
>>>>  =3D3B
>>>> We also have subranges of LONGINT.
>>>> I'm not sure what the generalization of subranges are=3D2C = >> granted.
>>>>  =3D3BMaybe some sort of C++ template that takes constants in the = >> templat=3D >>>> e and does range checks at runtime. Yeah=3D2C maybe.
>>>>  =3D3B
>>>>  =3D3B
>>>> And as you point out=3D2C convenient literal syntax.
>>>>  =3D3B
>>>>  =3D3B
>>>> People reasonably argue for library extension in place of language = >> extensio=3D >>>> n=3D2C but that requires a language which is flexible enough to write = >> librari=3D >>>> es with the desired interface=3D2C and so many languages don't let = >> infix oper=3D >>>> ators be in a user-written library.
>>>> (There is a subtle but useless distinction here -- infix operators = >> being in=3D >>>> libraries vs. "user-written" libraries. The infix set operations for = >> examp=3D >>>> le are in a library=3D2C but not user-written=3D2C special=3D2C the = >> compiler know=3D >>>> s about it.)
>>>>  =3D3B
>>>> >=3D3B that would perhaps not match how C handles "long long" on = >> the same>>> R>>=3D3B platform (which is how=3D2C come to think of it?)=3D2C and = >> that would =3D >>>> require

>>>>  =3D3B
>>>> On NT/x86=3D2C __int64/long long is returned in the register pair = >> edx:eax.>>>> =20 >>>> edx is high=3D2C eax is low.
>>>> When passed as a parameter to __stdcall or __cdecl is just passed as = >> two 32=3D >>>> bit values adjacent on the stack=3D2C "hi=3D2C lo=3D2C hi=3D2C lo=3D2C = >> it's off to pu=3D >>>> sh we go" is the Snow White-influenced mantra to remember how to pass = >> them=3D >>>> =3D2C at least on little endian stack-growing-down machines (which = >> includes x=3D >>>> 86). For __fastcall I'm not sure they are passed in registers or on = >> the sta=3D >>>> ck.
>>>> Passing and/or returning small structs also has special efficient = >> handling =3D >>>> in the ABI=3D2C so __int64 really might be equivalent to a small = >> record. Not =3D >>>> that cm3 necessarily implements that "correctly" =3D3B -- for = >> interop wit=3D >>>> h C=3D3B for Modula-3 calling Modula-3 we can make up our own ABI so = >> there is=3D >>>> n't =3D3Breally an "incorrect" way. =3D3BNotice the mingw = >> problem I had=3D >>>> passing a Win32 point struct by value=3D2C I cheated and passed it by = >> VAR to=3D >>>> a =3D3BC wrapper to workaround the gcc backend bug (which was = >> mentioned =3D >>>> a few times and which I looked into the code for=3D2C but took the = >> easy route=3D >>>> )
>>>>  =3D3B
>>>>  =3D3B
>>>> I don't know how long long works on other platforms but probably = >> similar.>>> R> >>>> Probably a certain register pair for return values.
>>>>  =3D3B
>>>>  =3D3B- Jay

 =3D3B
>=3D3B To: = >> hosking at cs.purdue.edu
>=3D3B=3D >>>> Date: Sat=3D2C 17 Apr 2010 19:47:03 -0700
>=3D3B From: = >> mika at async.async.c=3D >>>> altech.edu
>=3D3B CC: m3devel at elegosoft.com
>=3D3B Subject: = >> Re: [M3de=3D >>>> vel] INTEGER
>=3D3B
>=3D3B Tony Hosking writes:
>=3D3B = >> >=3D3B
=3D >>>> >=3D3B ...
>=3D3B >=3D3B
>=3D3B >=3D3B>=3D3B We = >> need it to match 64-b=3D >>>> it integers on 32-bit machines? That seems =3D3D
>=3D3B = >> >=3D3Blike
>=3D >>>> =3D3B >=3D3B>=3D3B a very weak rationale indeed=3D2C if the same = >> functionality =3D >>>> could be =3D3D
>=3D3B >=3D3Bprovided
>=3D3B >=3D3B>=3D3= >> B through some o=3D >>>> ther mechanism (e.g.=3D2C ARRAY [0..1] OF INTEGER---even = >> =3D3D
>=3D3B >=3D3B=3D >>>> with
>=3D3B >=3D3B>=3D3B a pragma e.g. = >> <=3D3B*CLONGLONG*>=3D3B.. if it i=3D >>>> s necessary to tell the compiler =3D3D
>=3D3B = >> >=3D3Bthat
>=3D3B >=3D3B&=3D >>>> gt=3D3B a special linkage convention is needed).
>=3D3B = >> >=3D3B
>=3D3B &=3D >>>> gt=3D3BThere's no special linkage convention. Not sure what you mean = >> here.>>>> >=3D3B >=3D3B
>=3D3B
>=3D3B I just mean if we = >> had
>=3D3B
>=3D >>>> =3D3B TYPE LONGINT =3D3D ARRAY [0..1] OF INTEGER
>=3D3B = >>
>=3D3B that woul=3D >>>> d perhaps not match how C handles "long long" on the same
>=3D3B = >> platfor=3D >>>> m (which is how=3D2C come to think of it?)=3D2C and that would = >> require
>=3D >>>> =3D3B special linkage tricks.
>=3D3B
>=3D3B But what would = >> be lost? Th=3D >>>> e ability to type literals.
>=3D3B
>=3D3B You could get = >> the same co=3D >>>> de interface on 32- and 64-bit machine by
>=3D3B = >> defining
>=3D3B
=3D >>>> >=3D3B TYPE FileOffset =3D3D ARRAY[0..1] OF [-16_80000000 .. = >> +16_7fffffff ]>>> R>>=3D3B
>=3D3B and using that.
>=3D3B
>=3D3B = >>
>=3D3B Mika>>>> >>>> =3D >>>> =20 >>>> --_264cb69b-0215-44c3-807c-8b4d8ea0ea59_-- From jay.krell at cornell.edu Mon Apr 19 04:44:51 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 19 Apr 2010 02:44:51 +0000 Subject: [M3devel] INTEGER In-Reply-To: References: , , ,,<7C7408D0-9A40-4988-BADA-A9FD8C15D388@cs.purdue.edu>, ,,, , , , , , , , , <20100418023535.3BA9E1A2103@async.async.caltech.edu>, , , , <20100418024703.6965B1A2103@async.async.caltech.edu>, , <20100418074927.934461A2117@async.async.caltech.edu>, <04EB7FF8-D304-428D-839E-233FCE009C98@cs.purdue.edu>, <20100418195901.CDACB1A20F6@async.async.caltech.edu>, Message-ID: Mika, the build process hasn't "really" changed. There was always an occasional "bump" where you had to build the compiler skipping m3core/libm3, and then again with building m3core/libm3. It used to happen any time a target was added. But I fixed that. Then it also happened with WIDECHAR, then with LONGINT, then with LONGCARD and the VAL changes. There was also a "bump" when cm3 started using m3core's TextUtils, though I've removed that -- I've removed a few "bumps" where possible, but some remain. Old cm3 cannot compile "modern" m3core/libm3. Other than needing this "skipping" of m3core/libm3, you can actually build the current system starting with an old 5.x release. I haven't tried 5.1/4.1/3.6 yet but maybe I will soon. I actually use current configuration files when doing that though, so that probably inhibits 3.6 (unless I use its configuration files). Having skimmed through http://yarchive.net/comp/longlong.html ... wow folks are *adamant* that C needed long long, like in order to 32bit systems to cross compile for 64bit... I continue to suspect that infix operators and efficiency are the primary motivators. "efficiency" in terms of being sure to avoid function calls for some operations, which is likely doable otherwise. People really want their compiler to handle multiple precision arithmetic, at least to attain 64bit precision. It is nice and convenient, if not strictly necessary. Another view though, besides "interop" with C, is "keeping up" with C. Again that link suggests C has had long long for something like 18 years. We are late. Even C changed, C99 must be around 10 years old now? and has lnog long. Granted, I tend to think of C like you think of Modula-3 --- nice that it never changes. It is somewhat small, very well known. One only needs keep up with libraries now :) and one can assume a certain baseline is everywhere and write portable code to it. (But I've happened upon K&R compiler *recently* -- HP-UX/hppa only bundles a compiler for purposes of changing kernel configuration (constant data) and relinking kernel. The libraries that comprise the kernel are shipped. K&R suffices and is therefore bundled. Best is probably to use that compiler to build old gcc, and then use old gcc to build current gcc (current gcc can't be compiled with K&R)). WIDECHAR is maybe a bit funny. Notice how in C and C++, until subtle small later changes in C++, wchar_t was just a typedef of unsigned short, you could write literals L'a' and L"foo", and there was a bunch of library functions -- again, the "language" aspect being just literals, close to the situation with LONGINT where the language provides literals and infix notation. In fact I think the next version of C++ improves the situation for "literals" of user defined types, like the "constexpr" feature will make constructors better able to stand in for literals, I think. - Jay > From: hosking at cs.purdue.edu > Date: Sun, 18 Apr 2010 20:38:43 -0400 > To: mika at async.async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] INTEGER > > Mika, > > First off, I'd be very interested to know what the issues are with LONGINT and stubgen. We are building that every day in regression testing. It would be really good to get some precise feedback. > > True, LONGINT is integrated with all of the language tools (same as WIDECHAR). > > I suppose that is the price we pay for the language having evolved. Nevertheless, CM3 should be totally backward compatible with the green book. There is no reason it should not build packages from PM3 or SRC. > > Now, this is not to say that perhaps we haven't overreached with LONGINT given that 64-bit is more prevalent. But then it is also useful to be able to interoperate with C libraries. The previous interfacing was pretty much a kludge, using ARRAY[0..1] OF INTEGER for "long long" but then not propagating the double INTEGER value properly throughout the Modula-3 libraries. > > I'm sorry to say that EWD was not particularly renowned for his practicality; pedant more like. Nice to be high and mighty but we also need to interact with the real world. > > We should be able to make this work. Is there a better alternative? Revoke LONGINT, and WIDECHAR? > > On 18 Apr 2010, at 15:59, Mika Nystrom wrote: > > > > > My problem is really just that it's ugly. LONGx is showing up as an issue > > in all sorts of low-level code, which is not surprising since Modula-3 > > with LONGx is not the same language as Modula-3 (maybe we should call > > it Modula-3+?) > > > > The compiler bootstrapping process has gotten more complicated due to it, > > and when I cvs updated m3tk yesterday stubgen wouldn't compile because there > > was something "long" in it that wasn't there before. I have no idea what > > library or components I needed to update and recompile and didn't have the > > time to deal with the issue at the time. > > > > And the new m3tk, stubgen, and compiler(?) won't compile using PM3 or > > SRC M3 since we're no longer using the language of the Green Book. > > (Same comment goes for WIDECHAR, by the way.) > > > > One of the wonderful things about Modula-3 *used to be* that I could > > grab some old package from DECSRC and just use it without changes since > > no one had messed with the language definition. This is still true as > > far as programs that just use the tools go, but it's no longer true for > > programs that process Modula-3 code as input data. Of which there are > > more than a few: many aspects of Modula-3 were specifically designed to > > make the language easy to process by program, as an intermediate format > > and whatnot. > > > > To quote E.W.D.: > > > > 'Unfathomed misunderstanding is further revealed by the term "software > > maintenance", as a result of which many people continue to believe that > > programs and even programming languages themselves are subject to wear > > and tear. Your car needs maintenance too, doesn't it? Famous is the story > > of the oil company that believed that its PASCAL programs did not last > > as long as its FORTRAN programs "because PASCAL was not maintained".' > > > > LONGx is causing me to have to do "software maintenance" on Modula-3 > > programs... for a feature that no one appears to be using and is quickly > > becoming irrelevant. > > > > Mika > > > > > > Tony Hosking writes: > >> In the language spec NUMBER(a) and LAST(a) - FIRST(a) + 1 are *not* = > >> defined to mean the same thing for all types. > >> NUMBER does have an INTEGER value, as expected for subranges of LONGINT = > >> that are not too large. > >> This is as it has always been for subranges of INTEGER that are not too = > >> large. > >> > >> Mika, I'm not sure I see any of the problems you are worrying about in = > >> the current definition of LONGINT/LONGCARD. > >> > >> On 18 Apr 2010, at 03:49, Mika Nystrom wrote: > >> > >>> =20 > >>> Jay I know most of this, and it doesn't really answer the question > >>> "what is it for?" > >>> =20 > >>> I think we've already established that LONGINT isn't useful for = > >> counting > >>> anything that might actually reside in the computer's memory: it makes > >>> no sense as an array index, for instance. INTEGER suffices for that. > >>> =20 > >>> I thought that the only real reason for LONGINT was to match C's > >>> declaration of various seek-related routines on 32-bit machines. > >>> That's not a very good reason. > >>> =20 > >>> C++ succeeds because it does very well in the area(s) it is good at. > >>> People who want to program in C++ will clearly program in C++, not > >>> Modula-3. Modula-3 is never, ever going to be the language of choice = > >> for > >>> people who want lots of snazzy infix operators. Modula-3 is supposed = > >> to > >>> be a language with about as powerful semantics as C++ and an extremely > >>> simple syntax and definition---snazzy infix is one of the things you > >>> give up for that. I don't see how LONGINT fits into this picture. > >>> Now we have LONGCARD too? And it's infected the definitions > >>> of FIRST and LAST? But not NUMBER... argh! > >>> =20 > >>> so, > >>> =20 > >>> NUMBER(a) and LAST(a) - FIRST(a) + 1 > >>> =20 > >>> no longer mean the same thing? Are we going to see lots of comments > >>> in generics in the future where it says T may not be an open array > >>> type nor an array type indexed on LONGINT or a subrange thereof? > >>> =20 > >>> Your comments about different parameter-passing techniques was what I = > >> was > >>> trying to address with my suggestion to have a pragma for this---just = > >> to > >>> match C (and Fortran?), of course. Name me a single Modula-3 = > >> programmer > >>> who cares in what order the bits in his parameters are pushed on the > >>> stack in a Modula-3-to-Modula-3 call. > >>> =20 > >>> And I am definitely in that school of thought that says that = > >> programming > >>> languages should not "evolve". Better to leave well enough alone. > >>> =20 > >>> How much Modula-3 code has been written that uses LONGINT? Other than > >>> to talk to C? I've certainly never used it. > >>> =20 > >>> Mika > >>> =20 > >>> =20 > >>> =20 > >>> Jay K writes: > >>>> --_264cb69b-0215-44c3-807c-8b4d8ea0ea59_ > >>>> Content-Type: text/plain; charset=3D"iso-8859-1" > >>>> Content-Transfer-Encoding: quoted-printable > >>>> =20 > >>>> =20 > >>>> TYPE LONGINT =3D3D ARRAY [0..1] OF INTEGER on a 32bit system is very = > >> close to=3D > >>>> LONGINT. > >>>> =20 > >>>> Plus treating it opaquely and providing a bunch of functions to = > >> operate on=3D > >>>> it. > >>>> =20 > >>>> Just as well therefore could be RECORD hi=3D2Clo:LONGINT END (see = > >> LARGE_INTE=3D > >>>> GER and ULARGE_INTEGER in winnt.h) > >>>> =20 > >>>> =3D20 > >>>> =20 > >>>> Differences that come to mind: > >>>> =20 > >>>> infix operators <=3D3D=3D3D=3D3D=3D20 > >>>> =20 > >>>> possibly passed differently as a parameter > >>>> =20 > >>>> or returned differently as a result > >>>> =20 > >>>> ie. probably "directly compatible with" "long long"=3D2C passed by = > >> value (o=3D > >>>> f course you could always pass by pointer and achieve compatibilitity = > >> trivi=3D > >>>> ally) > >>>> =20 > >>>> =3D20 > >>>> =20 > >>>> =3D20 > >>>> =20 > >>>> I have to say though=3D2C the biggest reason is in-fix operators. = > >> Convenient =3D > >>>> syntax. > >>>> =20 > >>>> C++ is the best and some way worst of example of the general right = > >> way to d=3D > >>>> o this -- you let programmers define types and their infix operators. = > >> Other=3D > >>>> languages just come with a passle of special cases of types that have = > >> in-f=3D > >>>> ix operators. > >>>> =20 > >>>> A good example is that Java infix operator + on string=3D2C besides = > >> the vario=3D > >>>> us integers=3D2C and nothing else. > >>>> =20 > >>>> =3D20 > >>>> =20 > >>>> =3D20 > >>>> =20 > >>>> I think C# lets you define operators=3D2C yet people don't complain = > >> that it i=3D > >>>> s "a mess" as they do of C++. > >>>> =20 > >>>> I think Python does now too. > >>>> =20 > >>>> So it is feature growing in popularity among "mainstream" = > >> languages=3D2C not =3D > >>>> just C++. > >>>> =20 > >>>> C++ of course is extremely mainstream=3D2C but also a favorite = > >> target. (ht=3D > >>>> tp://www.relisoft.com/tools/CppCritic.html) > >>>> =20 > >>>> =3D20 > >>>> =20 > >>>> =3D20 > >>>> =20 > >>>> We also have subranges of LONGINT. > >>>> =20 > >>>> I'm not sure what the generalization of subranges are=3D2C granted. > >>>> =20 > >>>> Maybe some sort of C++ template that takes constants in the template = > >> and d=3D > >>>> oes range checks at runtime. Yeah=3D2C maybe. > >>>> =20 > >>>> =3D20 > >>>> =20 > >>>> =3D20 > >>>> =20 > >>>> And as you point out=3D2C convenient literal syntax. > >>>> =20 > >>>> =3D20 > >>>> =20 > >>>> =3D20 > >>>> =20 > >>>> People reasonably argue for library extension in place of language = > >> extensio=3D > >>>> n=3D2C but that requires a language which is flexible enough to write = > >> librari=3D > >>>> es with the desired interface=3D2C and so many languages don't let = > >> infix oper=3D > >>>> ators be in a user-written library. > >>>> =20 > >>>> (There is a subtle but useless distinction here -- infix operators = > >> being in=3D > >>>> libraries vs. "user-written" libraries. The infix set operations for = > >> examp=3D > >>>> le are in a library=3D2C but not user-written=3D2C special=3D2C the = > >> compiler know=3D > >>>> s about it.) > >>>> =20 > >>>> =3D20 > >>>> =20 > >>>>> that would perhaps not match how C handles "long long" on the same > >>>>> platform (which is how=3D2C come to think of it?)=3D2C and that = > >> would require > >>>> =20 > >>>> =20 > >>>> =3D20 > >>>> =20 > >>>> On NT/x86=3D2C __int64/long long is returned in the register pair = > >> edx:eax. > >>>> =20 > >>>> edx is high=3D2C eax is low. > >>>> =20 > >>>> When passed as a parameter to __stdcall or __cdecl is just passed as = > >> two 32=3D > >>>> bit values adjacent on the stack=3D2C "hi=3D2C lo=3D2C hi=3D2C lo=3D2C = > >> it's off to pu=3D > >>> sh we go" is the Snow White-influenced mantra to remember how to pass = > >> them=3D > >>>> =3D2C at least on little endian stack-growing-down machines (which = > >> includes x=3D > >>>> 86). For __fastcall I'm not sure they are passed in registers or on = > >> the sta=3D > >>>> ck. > >>>> =20 > >>>> Passing and/or returning small structs also has special efficient = > >> handling =3D > >>>> in the ABI=3D2C so __int64 really might be equivalent to a small = > >> record. Not =3D > >>>> that cm3 necessarily implements that "correctly" -- for interop with = > >> C=3D3B =3D > >>>> for Modula-3 calling Modula-3 we can make up our own ABI so there = > >> isn't rea=3D > >>>> lly an "incorrect" way. Notice the mingw problem I had passing a = > >> Win32 poin=3D > >>>> t struct by value=3D2C I cheated and passed it by VAR to a C wrapper = > >> to worka=3D > >>>> round the gcc backend bug (which was mentioned a few times and which = > >> I look=3D > >>>> ed into the code for=3D2C but took the easy route) > >>>> =20 > >>>> =3D20 > >>>> =20 > >>>> =3D20 > >>>> =20 > >>>> I don't know how long long works on other platforms but probably = > >> similar. > >>>> =20 > >>>> Probably a certain register pair for return values. > >>>> =20 > >>>> =3D20 > >>>> =20 > >>>> - Jay > >>>> =20 > >>>> =3D20 > >>>>> To: hosking at cs.purdue.edu > >>>>> Date: Sat=3D2C 17 Apr 2010 19:47:03 -0700 > >>>>> From: mika at async.async.caltech.edu > >>>>> CC: m3devel at elegosoft.com > >>>>> Subject: Re: [M3devel] INTEGER > >>>>> =3D20 > >>>>> Tony Hosking writes: > >>>>>> =20 > >>>>> ... > >>>>>> =20 > >>>>>>> We need it to match 64-bit integers on 32-bit machines? That seems = > >> =3D3D > >>>>>> like > >>>>>>> a very weak rationale indeed=3D2C if the same functionality could = > >> be =3D3D > >>>>>> provided > >>>>>>> through some other mechanism (e.g.=3D2C ARRAY [0..1] OF = > >> INTEGER---even =3D > >>>> =3D3D > >>>>>> with > >>>>>>> a pragma e.g. <*CLONGLONG*>.. if it is necessary to tell the = > >> compiler =3D > >>>> =3D3D > >>>>>> that > >>>>>>> a special linkage convention is needed). > >>>>>> =20 > >>>>>> There's no special linkage convention. Not sure what you mean here. > >>>>>> =20 > >>>>> =3D20 > >>>>> I just mean if we had > >>>>> =3D20 > >>>>> TYPE LONGINT =3D3D ARRAY [0..1] OF INTEGER > >>>>> =3D20 > >>>>> that would perhaps not match how C handles "long long" on the same > >>>>> platform (which is how=3D2C come to think of it?)=3D2C and that = > >> would require > >>>>> special linkage tricks. > >>>>> =3D20 > >>>>> But what would be lost? The ability to type literals.=3D20 > >>>>> =3D20 > >>>>> You could get the same code interface on 32- and 64-bit machine by > >>>>> defining > >>>>> =3D20 > >>>>> TYPE FileOffset =3D3D ARRAY[0..1] OF [-16_80000000 .. +16_7fffffff ] > >>>>> =3D20 > >>>>> and using that. > >>>>> =3D20 > >>>>> =3D20 > >>>>> Mika > >>>> =3D > >>>> =20 > >>>> --_264cb69b-0215-44c3-807c-8b4d8ea0ea59_ > >>>> Content-Type: text/html; charset=3D"iso-8859-1" > >>>> Content-Transfer-Encoding: quoted-printable > >>>> =20 > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> TYPE LONGINT =3D3D ARRAY [0..1] OF INTEGER on a =3D3B32bit system = > >> is very c=3D > >>>> lose to LONGINT.
> >>>>  =3D3BPlus treating it opaquely and providing a bunch of = > >> functions to ope=3D > >>>> rate on it.
> >>>>  =3D3BJust as well therefore could be RECORD hi=3D2Clo:LONGINT = > >> END (see LAR=3D > >>>> GE_INTEGER and ULARGE_INTEGER in winnt.h)
> >>>>  =3D3B
> >>>> Differences that come to mind:
> >>>>  =3D3B =3D3Binfix operators =3D3B <=3D3B=3D3D=3D3D=3D3D = > >>
> >>>>  =3D3B possibly passed differently =3D3Bas a parameter
> >>>>  =3D3B or returned differently as a result
> >>>>  =3D3B ie. probably "directly compatible with" "long long"=3D2C = > >> passed by v=3D > >>>> alue (of course you could always pass by pointer and achieve = > >> compatibilitit=3D > >>>> y trivially)
> >>>>  =3D3B
> >>>>  =3D3B
> >>>> I have to say though=3D2C the biggest reason is in-fix operators. = > >> Convenient =3D > >>>> syntax.
> >>>> C++ is the best and some way worst of example of the general right = > >> way to d=3D > >>>> o this -- you let programmers define types and their infix operators. = > >> Other=3D > >>>> languages just come with a passle of special cases of types that have = > >> in-f=3D > >>>> ix operators.
> >>>> A good example is that Java infix operator + on string=3D2C besides = > >> the vario=3D > >>>> us integers=3D2C and nothing else.
> >>>>  =3D3B
> >>>>  =3D3B
> >>>> I think C# lets you define operators=3D2C yet people don't complain = > >> that it i=3D > >>>> s "a mess" as they do of C++.
> >>>> I think Python does now too.
> >>>> So it is feature growing in popularity among "mainstream" = > >> languages=3D2C not =3D > >>>> just C++.
> >>>>  =3D3B =3D3B C++ of course is extremely mainstream=3D2C but = > >> also a favori=3D > >>>> te target. ( >> href=3D3D"http://www.relisoft.com/tools/CppCritic.html">http:/=3D > >>>> /www.relisoft.com/tools/CppCritic.html)
> >>>>  =3D3B
> >>>>  =3D3B
> >>>> We also have subranges of LONGINT.
> >>>> I'm not sure what the generalization of subranges are=3D2C = > >> granted.
> >>>>  =3D3BMaybe some sort of C++ template that takes constants in the = > >> templat=3D > >>>> e and does range checks at runtime. Yeah=3D2C maybe.
> >>>>  =3D3B
> >>>>  =3D3B
> >>>> And as you point out=3D2C convenient literal syntax.
> >>>>  =3D3B
> >>>>  =3D3B
> >>>> People reasonably argue for library extension in place of language = > >> extensio=3D > >>>> n=3D2C but that requires a language which is flexible enough to write = > >> librari=3D > >>>> es with the desired interface=3D2C and so many languages don't let = > >> infix oper=3D > >>>> ators be in a user-written library.
> >>>> (There is a subtle but useless distinction here -- infix operators = > >> being in=3D > >>>> libraries vs. "user-written" libraries. The infix set operations for = > >> examp=3D > >>>> le are in a library=3D2C but not user-written=3D2C special=3D2C the = > >> compiler know=3D > >>>> s about it.)
> >>>>  =3D3B
> >>>> >=3D3B that would perhaps not match how C handles "long long" on = > >> the same >>>> R>>=3D3B platform (which is how=3D2C come to think of it?)=3D2C and = > >> that would =3D > >>>> require

> >>>>  =3D3B
> >>>> On NT/x86=3D2C __int64/long long is returned in the register pair = > >> edx:eax. >>>>> =20 > >>>> edx is high=3D2C eax is low.
> >>>> When passed as a parameter to __stdcall or __cdecl is just passed as = > >> two 32=3D > >>>> bit values adjacent on the stack=3D2C "hi=3D2C lo=3D2C hi=3D2C lo=3D2C = > >> it's off to pu=3D > >>>> sh we go" is the Snow White-influenced mantra to remember how to pass = > >> them=3D > >>>> =3D2C at least on little endian stack-growing-down machines (which = > >> includes x=3D > >>>> 86). For __fastcall I'm not sure they are passed in registers or on = > >> the sta=3D > >>>> ck.
> >>>> Passing and/or returning small structs also has special efficient = > >> handling =3D > >>>> in the ABI=3D2C so __int64 really might be equivalent to a small = > >> record. Not =3D > >>>> that cm3 necessarily implements that "correctly" =3D3B -- for = > >> interop wit=3D > >>>> h C=3D3B for Modula-3 calling Modula-3 we can make up our own ABI so = > >> there is=3D > >>>> n't =3D3Breally an "incorrect" way. =3D3BNotice the mingw = > >> problem I had=3D > >>>> passing a Win32 point struct by value=3D2C I cheated and passed it by = > >> VAR to=3D > >>>> a =3D3BC wrapper to workaround the gcc backend bug (which was = > >> mentioned =3D > >>>> a few times and which I looked into the code for=3D2C but took the = > >> easy route=3D > >>>> )
> >>>>  =3D3B
> >>>>  =3D3B
> >>>> I don't know how long long works on other platforms but probably = > >> similar. >>>> R> > >>>> Probably a certain register pair for return values.
> >>>>  =3D3B
> >>>>  =3D3B- Jay

 =3D3B
>=3D3B To: = > >> hosking at cs.purdue.edu
>=3D3B=3D > >>>> Date: Sat=3D2C 17 Apr 2010 19:47:03 -0700
>=3D3B From: = > >> mika at async.async.c=3D > >>>> altech.edu
>=3D3B CC: m3devel at elegosoft.com
>=3D3B Subject: = > >> Re: [M3de=3D > >>>> vel] INTEGER
>=3D3B
>=3D3B Tony Hosking writes:
>=3D3B = > >> >=3D3B
=3D > >>>> >=3D3B ...
>=3D3B >=3D3B
>=3D3B >=3D3B>=3D3B We = > >> need it to match 64-b=3D > >>>> it integers on 32-bit machines? That seems =3D3D
>=3D3B = > >> >=3D3Blike
>=3D > >>>> =3D3B >=3D3B>=3D3B a very weak rationale indeed=3D2C if the same = > >> functionality =3D > >>>> could be =3D3D
>=3D3B >=3D3Bprovided
>=3D3B >=3D3B>=3D3= > >> B through some o=3D > >>>> ther mechanism (e.g.=3D2C ARRAY [0..1] OF INTEGER---even = > >> =3D3D
>=3D3B >=3D3B=3D > >>>> with
>=3D3B >=3D3B>=3D3B a pragma e.g. = > >> <=3D3B*CLONGLONG*>=3D3B.. if it i=3D > >>>> s necessary to tell the compiler =3D3D
>=3D3B = > >> >=3D3Bthat
>=3D3B >=3D3B&=3D > >>>> gt=3D3B a special linkage convention is needed).
>=3D3B = > >> >=3D3B
>=3D3B &=3D > >>>> gt=3D3BThere's no special linkage convention. Not sure what you mean = > >> here. >>>>> >=3D3B >=3D3B
>=3D3B
>=3D3B I just mean if we = > >> had
>=3D3B
>=3D > >>>> =3D3B TYPE LONGINT =3D3D ARRAY [0..1] OF INTEGER
>=3D3B = > >>
>=3D3B that woul=3D > >>>> d perhaps not match how C handles "long long" on the same
>=3D3B = > >> platfor=3D > >>>> m (which is how=3D2C come to think of it?)=3D2C and that would = > >> require
>=3D > >>>> =3D3B special linkage tricks.
>=3D3B
>=3D3B But what would = > >> be lost? Th=3D > >>>> e ability to type literals.
>=3D3B
>=3D3B You could get = > >> the same co=3D > >>>> de interface on 32- and 64-bit machine by
>=3D3B = > >> defining
>=3D3B
=3D > >>>> >=3D3B TYPE FileOffset =3D3D ARRAY[0..1] OF [-16_80000000 .. = > >> +16_7fffffff ] >>>> R>>=3D3B
>=3D3B and using that.
>=3D3B
>=3D3B = > >>
>=3D3B Mika >>>>> > >>>> =3D > >>>> =20 > >>>> --_264cb69b-0215-44c3-807c-8b4d8ea0ea59_-- > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Apr 19 05:27:01 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 19 Apr 2010 03:27:01 +0000 Subject: [M3devel] the lingering socket linger question, non-blocking Win32 sockets? Message-ID: shorter story: - Does anyone have significant socket-using Modula-3 code to test? That is used on Posix and Win32? - Given the extremely high similarly between the Windows and Posix (BSD) socket interfaces, I strongly suggest we unify the implementations, including removing some of the historical differences. I also strongly suspect the Posix implementation is the "better" one, that has recieved more thought and testing. The Win32 variants of the Modula-3 libraries often seem..suspicious. Like they were a very initial version but never really recieved the attention needed. longer story: So..I've asked a few times, why this seemingly opposite code: C:\dev2\cm3.2\m3-libs\libm3\src\os\POSIX\SocketPosix.m3(453): linger := struct_linger{1, 1}; C:\dev2\cm3.2\m3-libs\libm3\src\os\WIN32\SocketWin32.m3(401): linger := struct_linger{0, 0}; I have a *little* more information. Windows documentation warns about using linger{1} on non-blocking sockets. The default {0} seems to be what you'd want. Seems like the setsockopt isn't needed. SocketPosix.m3 sets sockets to be non-blocking. I associate "non blocking" with "prone to be slow or hang-until-timeout in real world, want to avoid that". Older SocketWin32.m3 seems to have in mind non-blocking: Searching for 'WSAEWOULDBLOCK'... C:\dev2\cm3.2\m3-libs\libm3\src\os\WIN32\SocketWin32.m3.sav(137): | WinSock.WSAEWOULDBLOCK => C:\dev2\cm3.2\m3-libs\libm3\src\os\WIN32\SocketWin32.m3.sav(189): | WinSock.WSAEWOULDBLOCK => C:\dev2\cm3.2\m3-libs\libm3\src\os\WIN32\SocketWin32.m3.sav(241): | WinSock.WSAEWOULDBLOCK => C:\dev2\cm3.2\m3-libs\libm3\src\os\WIN32\SocketWin32.m3.sav(274): | WinSock.WSAEWOULDBLOCK => C:\dev2\cm3.2\m3-libs\libm3\src\os\WIN32\SocketWin32.m3.sav(315): | WinSock.WSAEWOULDBLOCK => C:\dev2\cm3.2\m3-libs\libm3\src\os\WIN32\SocketWin32.m3.sav(356): | WinSock.WSAEWOULDBLOCK => current SocketWin32.m3 does *not* set the sockets to non-blocking. And there seems to be patterns to account for that -- checking BytesAvailable at the start of operations like Read and ReceiveFrom, where the Posix version does not. The Posix version using select/poll where the Win32 version does not (though the win32 ".sav" files does). SocketWin32.m3.sav: IF WinSock.ioctlsocket (sock, WinSock.FIONBIO, ADR(one)) = SockErr THEN Using select/poll in Posix is slightly complicated by user threads. The complexity is under the covers in the thread implementation. Win32 doesn't have that problem. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Apr 19 06:37:12 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 19 Apr 2010 04:37:12 +0000 Subject: [M3devel] Posix < 0 vs. # 0 vs. = -1? In-Reply-To: <20100418194159.E07411A2119@async.async.caltech.edu> References: , <20100418194159.E07411A2119@async.async.caltech.edu> Message-ID: Mika, you mean [-1..LAST(INTEGER)] right? - Jay > To: jay.krell at cornell.edu > Date: Sun, 18 Apr 2010 12:41:59 -0700 > From: mika at async.async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Posix < 0 vs. # 0 vs. = -1? > > Jay K writes: > >--_201b8a99-e8e8-4887-bb32-c65e8edd0b1a_ > >Content-Type: text/plain; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > >Posix often says: > > > > function foo() returns 0 for success=2C -1 for error > > > >=20 > > > > m3core/libm3/etc=2C often say if foo() < 0 or if foo() # 0 "instead". > > Generally ok to tighten these up to "=3D -1"=2C perhaps upon checking manp= > >ages=2C > > or a known rat's nest of inconsistencies? > > > > Maybe this is just my personal style, but I would code it thus: > > <*EXTERNAL*> > PROCEDURE F() : INTEGER; (* matches C declaration *) > > ... > > VAR result : [0..1] := F(); (* matches man page specification *) > BEGIN > CASE result OF > 0 => ... > | > -1 => ... > END > END > > No way for any sneaky value problems to get through. The use of > CASE also guards against typos. > > Mika -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Mon Apr 19 06:47:14 2010 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Mon, 19 Apr 2010 04:47:14 +0000 (GMT) Subject: [M3devel] INTEGER In-Reply-To: <20100418195901.CDACB1A20F6@async.async.caltech.edu> Message-ID: <141192.73575.qm@web23603.mail.ird.yahoo.com> Hi: I think the irrelevant point is arguable as there are SIMD instructions of 128-bit and later will be 256-bit packed types registers so the point of becoming irrelevant could be worrisome in time, probably not now. As packed types weren't to traumatic but are more needed now by this fact. If you wish more generality, a language change will be needed, not an extension, language extensions are easily doable with enough knowledge but right now you would need to do it or it will become harder and harder to reconstruct your own code. If you need backward compatibility why don't host cm3 with pm3, that is old cm3 can't compile cm3 but its negative inverse is true and it is old known old cm3 can build pm3 and src m3 (current cm3 built itself as I saw with RC5 on AMD64_LINUX). Still you want to host other older environments look for doing it with CM3, I think it wouldn't be so much traumatic, wouldn't it? You would compile and have two different runtime but you could do what you want to do, as I guess you were doing for other reasons and it wouldn't be so much effort to do it, maybe the ugly parts would be system dependent things as I think. I think there are many other options as to be backwards compatible like drop new features or build against other specific libraries, but again is not that the purpose you are looking for, then is simpler if you think the above intention in some sense to you? It's just an idea, hope it helps something. --- El dom, 18/4/10, Mika Nystrom escribi?: > De: Mika Nystrom > Asunto: Re: [M3devel] INTEGER > Para: "Tony Hosking" > CC: m3devel at elegosoft.com > Fecha: domingo, 18 de abril, 2010 14:59 > > My problem is really just that it's ugly. LONGx is > showing up as an issue > in all sorts of low-level code, which is not surprising > since Modula-3 > with LONGx is not the same language as Modula-3 (maybe we > should call > it Modula-3+?) > > The compiler bootstrapping process has gotten more > complicated due to it, > and when I cvs updated m3tk yesterday stubgen wouldn't > compile because there > was something "long" in it that wasn't there before. > I have no idea what > library or components I needed to update and recompile and > didn't have the > time to deal with the issue at the time. > > And the new m3tk, stubgen, and compiler(?) won't compile > using PM3 or > SRC M3 since we're no longer using the language of the > Green Book. > (Same comment goes for WIDECHAR, by the way.) > > One of the wonderful things about Modula-3 *used to be* > that I could > grab some old package from DECSRC and just use it without > changes since > no one had messed with the language definition. This > is still true as > far as programs that just use the tools go, but it's no > longer true for > programs that process Modula-3 code as input data. Of > which there are > more than a few: many aspects of Modula-3 were specifically > designed to > make the language easy to process by program, as an > intermediate format > and whatnot. > > To quote E.W.D.: > > 'Unfathomed misunderstanding is further revealed by the > term "software > maintenance", as a result of which many people continue to > believe that > programs and even programming languages themselves are > subject to wear > and tear. Your car needs maintenance too, doesn't it? > Famous is the story > of the oil company that believed that its PASCAL programs > did not last > as long as its FORTRAN programs "because PASCAL was not > maintained".' > > LONGx is causing me to have to do "software maintenance" on > Modula-3 > programs... for a feature that no one appears to be using > and is quickly > becoming irrelevant. > > Mika > > > Tony Hosking writes: > >In the language spec NUMBER(a) and LAST(a) - FIRST(a) + > 1 are *not* = > >defined to mean the same thing for all types. > >NUMBER does have an INTEGER value, as expected for > subranges of LONGINT = > >that are not too large. > >This is as it has always been for subranges of INTEGER > that are not too = > >large. > > > >Mika, I'm not sure I see any of the problems you are > worrying about in = > >the current definition of LONGINT/LONGCARD. > > > >On 18 Apr 2010, at 03:49, Mika Nystrom wrote: > > > >>=20 > >> Jay I know most of this, and it doesn't really > answer the question > >> "what is it for?" > >>=20 > >> I think we've already established that LONGINT > isn't useful for = > >counting > >> anything that might actually reside in the > computer's memory: it makes > >> no sense as an array index, for instance. > INTEGER suffices for that. > >>=20 > >> I thought that the only real reason for LONGINT > was to match C's > >> declaration of various seek-related routines on > 32-bit machines. > >> That's not a very good reason. > >>=20 > >> C++ succeeds because it does very well in the > area(s) it is good at. > >> People who want to program in C++ will clearly > program in C++, not > >> Modula-3. Modula-3 is never, ever going to > be the language of choice = > >for > >> people who want lots of snazzy infix > operators. Modula-3 is supposed = > >to > >> be a language with about as powerful semantics as > C++ and an extremely > >> simple syntax and definition---snazzy infix is one > of the things you > >> give up for that. I don't see how LONGINT > fits into this picture. > >> Now we have LONGCARD too? And it's infected > the definitions > >> of FIRST and LAST? But not NUMBER... argh! > >>=20 > >> so, > >>=20 > >> NUMBER(a) and LAST(a) - FIRST(a) + 1 > >>=20 > >> no longer mean the same thing? Are we going > to see lots of comments > >> in generics in the future where it says T may not > be an open array > >> type nor an array type indexed on LONGINT or a > subrange thereof? > >>=20 > >> Your comments about different parameter-passing > techniques was what I = > >was > >> trying to address with my suggestion to have a > pragma for this---just = > >to > >> match C (and Fortran?), of course. Name me a > single Modula-3 = > >programmer > >> who cares in what order the bits in his parameters > are pushed on the > >> stack in a Modula-3-to-Modula-3 call. > >>=20 > >> And I am definitely in that school of thought that > says that = > >programming > >> languages should not "evolve". Better to > leave well enough alone. > >>=20 > >> How much Modula-3 code has been written that uses > LONGINT? Other than > >> to talk to C? I've certainly never used it. > >>=20 > >> Mika > >>=20 > >>=20 > >>=20 > >> Jay K writes: > >>> --_264cb69b-0215-44c3-807c-8b4d8ea0ea59_ > >>> Content-Type: text/plain; > charset=3D"iso-8859-1" > >>> Content-Transfer-Encoding: quoted-printable > >>>=20 > >>>=20 > >>> TYPE LONGINT =3D3D ARRAY [0..1] OF INTEGER on > a 32bit system is very = > >close to=3D > >>> LONGINT. > >>>=20 > >>> Plus treating it opaquely and providing a > bunch of functions to = > >operate on=3D > >>> it. > >>>=20 > >>> Just as well therefore could be RECORD > hi=3D2Clo:LONGINT END (see = > >LARGE_INTE=3D > >>> GER and ULARGE_INTEGER in winnt.h) > >>>=20 > >>> =3D20 > >>>=20 > >>> Differences that come to mind: > >>>=20 > >>> infix operators > <=3D3D=3D3D=3D3D=3D20 > >>>=20 > >>> possibly passed differently as a parameter > >>>=20 > >>> or returned differently as a result > >>>=20 > >>> ie. probably "directly compatible with" "long > long"=3D2C passed by = > >value (o=3D > >>> f course you could always pass by pointer and > achieve compatibilitity = > >trivi=3D > >>> ally) > >>>=20 > >>> =3D20 > >>>=20 > >>> =3D20 > >>>=20 > >>> I have to say though=3D2C the biggest reason > is in-fix operators. = > >Convenient =3D > >>> syntax. > >>>=20 > >>> C++ is the best and some way worst of example > of the general right = > >way to d=3D > >>> o this -- you let programmers define types and > their infix operators. = > >Other=3D > >>> languages just come with a passle of special > cases of types that have = > >in-f=3D > >>> ix operators. > >>>=20 > >>> A good example is that Java infix operator + > on string=3D2C besides = > >the vario=3D > >>> us integers=3D2C and nothing else. > >>>=20 > >>> =3D20 > >>>=20 > >>> =3D20 > >>>=20 > >>> I think C# lets you define operators=3D2C yet > people don't complain = > >that it i=3D > >>> s "a mess" as they do of C++. > >>>=20 > >>> I think Python does now too. > >>>=20 > >>> So it is feature growing in popularity among > "mainstream" = > >languages=3D2C not =3D > >>> just C++. > >>>=20 > >>> C++ of course is extremely > mainstream=3D2C but also a favorite = > >target. (ht=3D > >>> tp://www.relisoft.com/tools/CppCritic.html) > >>>=20 > >>> =3D20 > >>>=20 > >>> =3D20 > >>>=20 > >>> We also have subranges of LONGINT. > >>>=20 > >>> I'm not sure what the generalization of > subranges are=3D2C granted. > >>>=20 > >>> Maybe some sort of C++ template that takes > constants in the template = > >and d=3D > >>> oes range checks at runtime. Yeah=3D2C maybe. > >>>=20 > >>> =3D20 > >>>=20 > >>> =3D20 > >>>=20 > >>> And as you point out=3D2C convenient literal > syntax. > >>>=20 > >>> =3D20 > >>>=20 > >>> =3D20 > >>>=20 > >>> People reasonably argue for library extension > in place of language = > >extensio=3D > >>> n=3D2C but that requires a language which is > flexible enough to write = > >librari=3D > >>> es with the desired interface=3D2C and so many > languages don't let = > >infix oper=3D > >>> ators be in a user-written library. > >>>=20 > >>> (There is a subtle but useless distinction > here -- infix operators = > >being in=3D > >>> libraries vs. "user-written" libraries. The > infix set operations for = > >examp=3D > >>> le are in a library=3D2C but not > user-written=3D2C special=3D2C the = > >compiler know=3D > >>> s about it.) > >>>=20 > >>> =3D20 > >>>=20 > >>>> that would perhaps not match how C handles > "long long" on the same > >>>> platform (which is how=3D2C come to think > of it?)=3D2C and that = > >would require > >>>=20 > >>>=20 > >>> =3D20 > >>>=20 > >>> On NT/x86=3D2C __int64/long long is returned > in the register pair = > >edx:eax. > >>>=20 > >>> edx is high=3D2C eax is low. > >>>=20 > >>> When passed as a parameter to __stdcall or > __cdecl is just passed as = > >two 32=3D > >>> bit values adjacent on the stack=3D2C "hi=3D2C > lo=3D2C hi=3D2C lo=3D2C = > >it's off to pu=3D > >> sh we go" is the Snow White-influenced mantra to > remember how to pass = > >them=3D > >>> =3D2C at least on little endian > stack-growing-down machines (which = > >includes x=3D > >>> 86). For __fastcall I'm not sure they are > passed in registers or on = > >the sta=3D > >>> ck. > >>>=20 > >>> Passing and/or returning small structs also > has special efficient = > >handling =3D > >>> in the ABI=3D2C so __int64 really might be > equivalent to a small = > >record. Not =3D > >>> that cm3 necessarily implements that > "correctly" -- for interop with = > >C=3D3B =3D > >>> for Modula-3 calling Modula-3 we can make up > our own ABI so there = > >isn't rea=3D > >>> lly an "incorrect" way. Notice the mingw > problem I had passing a = > >Win32 poin=3D > >>> t struct by value=3D2C I cheated and passed it > by VAR to a C wrapper = > >to worka=3D > >>> round the gcc backend bug (which was mentioned > a few times and which = > >I look=3D > >>> ed into the code for=3D2C but took the easy > route) > >>>=20 > >>> =3D20 > >>>=20 > >>> =3D20 > >>>=20 > >>> I don't know how long long works on other > platforms but probably = > >similar. > >>>=20 > >>> Probably a certain register pair for return > values. > >>>=20 > >>> =3D20 > >>>=20 > >>> - Jay > >>>=20 > >>> =3D20 > >>>> To: hosking at cs.purdue.edu > >>>> Date: Sat=3D2C 17 Apr 2010 19:47:03 -0700 > >>>> From: mika at async.async.caltech.edu > >>>> CC: m3devel at elegosoft.com > >>>> Subject: Re: [M3devel] INTEGER > >>>> =3D20 > >>>> Tony Hosking writes: > >>>>>=20 > >>>> ... > >>>>>=20 > >>>>>> We need it to match 64-bit > integers on 32-bit machines? That seems = > >=3D3D > >>>>> like > >>>>>> a very weak rationale indeed=3D2C > if the same functionality could = > >be =3D3D > >>>>> provided > >>>>>> through some other mechanism > (e.g.=3D2C ARRAY [0..1] OF = > >INTEGER---even =3D > >>> =3D3D > >>>>> with > >>>>>> a pragma e.g. > <*CLONGLONG*>.. if it is necessary to tell the = > >compiler =3D > >>> =3D3D > >>>>> that > >>>>>> a special linkage convention is > needed). > >>>>>=20 > >>>>> There's no special linkage convention. > Not sure what you mean here. > >>>>>=20 > >>>> =3D20 > >>>> I just mean if we had > >>>> =3D20 > >>>> TYPE LONGINT =3D3D ARRAY [0..1] OF > INTEGER > >>>> =3D20 > >>>> that would perhaps not match how C handles > "long long" on the same > >>>> platform (which is how=3D2C come to think > of it?)=3D2C and that = > >would require > >>>> special linkage tricks. > >>>> =3D20 > >>>> But what would be lost? The ability to > type literals.=3D20 > >>>> =3D20 > >>>> You could get the same code interface on > 32- and 64-bit machine by > >>>> defining > >>>> =3D20 > >>>> TYPE FileOffset =3D3D ARRAY[0..1] OF > [-16_80000000 .. +16_7fffffff ] > >>>> =3D20 > >>>> and using that. > >>>> =3D20 > >>>> =3D20 > >>>> Mika > >>> > > > =3D > >>>=20 > >>> --_264cb69b-0215-44c3-807c-8b4d8ea0ea59_ > >>> Content-Type: text/html; > charset=3D"iso-8859-1" > >>> Content-Transfer-Encoding: quoted-printable > >>>=20 > >>> > >>> > >>> > >>> > >>> > >>> TYPE LONGINT =3D3D ARRAY [0..1] OF INTEGER on > a =3D3B32bit system = > >is very c=3D > >>> lose to LONGINT.
> >>>  =3D3BPlus treating it opaquely and > providing a bunch of = > >functions to ope=3D > >>> rate on it.
> >>>  =3D3BJust as well therefore could be > RECORD hi=3D2Clo:LONGINT = > >END (see LAR=3D > >>> GE_INTEGER and ULARGE_INTEGER in > winnt.h)
> >>>  =3D3B
> >>> Differences that come to mind:
> >>>  =3D3B =3D3Binfix > operators =3D3B <=3D3B=3D3D=3D3D=3D3D = > >
> >>>  =3D3B possibly passed > differently =3D3Bas a parameter
> >>>  =3D3B or returned differently as a > result
> >>>  =3D3B ie. probably "directly > compatible with" "long long"=3D2C = > >passed by v=3D > >>> alue (of course you could always pass by > pointer and achieve = > >compatibilitit=3D > >>> y trivially)
> >>>  =3D3B
> >>>  =3D3B
> >>> I have to say though=3D2C the biggest reason > is in-fix operators. = > >Convenient =3D > >>> syntax.
> >>> C++ is the best and some way worst of example > of the general right = > >way to d=3D > >>> o this -- you let programmers define types and > their infix operators. = > >Other=3D > >>> languages just come with a passle of special > cases of types that have = > >in-f=3D > >>> ix operators.
> >>> A good example is that Java infix operator + > on string=3D2C besides = > >the vario=3D > >>> us integers=3D2C and nothing else.
> >>>  =3D3B
> >>>  =3D3B
> >>> I think C# lets you define operators=3D2C yet > people don't complain = > >that it i=3D > >>> s "a mess" as they do of C++.
> >>> I think Python does now too.
> >>> So it is feature growing in popularity among > "mainstream" = > >languages=3D2C not =3D > >>> just C++.
> >>>  =3D3B =3D3B C++ of course is > extremely mainstream=3D2C but = > >also a favori=3D > >>> te target. ( >href=3D3D"http://www.relisoft.com/tools/CppCritic.html">http:/=3D > >>> > /www.relisoft.com/tools/CppCritic.html)
> >>>  =3D3B
> >>>  =3D3B
> >>> We also have subranges of LONGINT.
> >>> I'm not sure what the generalization of > subranges are=3D2C = > >granted.
> >>>  =3D3BMaybe some sort of C++ template > that takes constants in the = > >templat=3D > >>> e and does range checks at runtime. Yeah=3D2C > maybe.
> >>>  =3D3B
> >>>  =3D3B
> >>> And as you point out=3D2C convenient literal > syntax.
> >>>  =3D3B
> >>>  =3D3B
> >>> People reasonably argue for library extension > in place of language = > >extensio=3D > >>> n=3D2C but that requires a language which is > flexible enough to write = > >librari=3D > >>> es with the desired interface=3D2C and so many > languages don't let = > >infix oper=3D > >>> ators be in a user-written library.
> >>> (There is a subtle but useless distinction > here -- infix operators = > >being in=3D > >>> libraries vs. "user-written" libraries. The > infix set operations for = > >examp=3D > >>> le are in a library=3D2C but not > user-written=3D2C special=3D2C the = > >compiler know=3D > >>> s about it.)
> >>>  =3D3B
> >>> >=3D3B that would perhaps not match how > C handles "long long" on = > >the same >>> R>>=3D3B platform (which is how=3D2C > come to think of it?)=3D2C and = > >that would =3D > >>> require

> >>>  =3D3B
> >>> On NT/x86=3D2C __int64/long long is returned > in the register pair = > >edx:eax. >>>>=20 > >>> edx is high=3D2C eax is low.
> >>> When passed as a parameter to __stdcall or > __cdecl is just passed as = > >two 32=3D > >>> bit values adjacent on the stack=3D2C "hi=3D2C > lo=3D2C hi=3D2C lo=3D2C = > >it's off to pu=3D > >>> sh we go" is the Snow White-influenced mantra > to remember how to pass = > >them=3D > >>> =3D2C at least on little endian > stack-growing-down machines (which = > >includes x=3D > >>> 86). For __fastcall I'm not sure they are > passed in registers or on = > >the sta=3D > >>> ck.
> >>> Passing and/or returning small structs also > has special efficient = > >handling =3D > >>> in the ABI=3D2C so __int64 really might be > equivalent to a small = > >record. Not =3D > >>> that cm3 necessarily implements that > "correctly" =3D3B -- for = > >interop wit=3D > >>> h C=3D3B for Modula-3 calling Modula-3 we can > make up our own ABI so = > >there is=3D > >>> n't =3D3Breally an "incorrect" > way. =3D3BNotice the mingw = > >problem I had=3D > >>> passing a Win32 point struct by value=3D2C I > cheated and passed it by = > >VAR to=3D > >>> a =3D3BC wrapper to workaround the gcc > backend bug (which was = > >mentioned =3D > >>> a few times and which I looked into the code > for=3D2C but took the = > >easy route=3D > >>> )
> >>>  =3D3B
> >>>  =3D3B
> >>> I don't know how long long works on other > platforms but probably = > >similar. >>> R> > >>> Probably a certain register pair for return > values.
> >>>  =3D3B
> >>>  =3D3B- > Jay

 =3D3B
>=3D3B > To: = > >hosking at cs.purdue.edu
>=3D3B=3D > >>> Date: Sat=3D2C 17 Apr 2010 19:47:03 > -0700
>=3D3B From: = > >mika at async.async.c=3D > >>> altech.edu
>=3D3B CC: m3devel at elegosoft.com
>=3D3B > Subject: = > >Re: [M3de=3D > >>> vel] INTEGER
>=3D3B >
>=3D3B Tony Hosking > writes:
>=3D3B = > >>=3D3B
=3D > >>> >=3D3B ...
>=3D3B > >=3D3B
>=3D3B >=3D3B>=3D3B > We = > >need it to match 64-b=3D > >>> it integers on 32-bit machines? That seems > =3D3D
>=3D3B = > >>=3D3Blike
>=3D > >>> =3D3B >=3D3B>=3D3B a very weak > rationale indeed=3D2C if the same = > >functionality =3D > >>> could be =3D3D
>=3D3B > >=3D3Bprovided
>=3D3B > >=3D3B>=3D3= > >B through some o=3D > >>> ther mechanism (e.g.=3D2C ARRAY [0..1] OF > INTEGER---even = > >=3D3D
>=3D3B >=3D3B=3D > >>> with
>=3D3B > >=3D3B>=3D3B a pragma e.g. = > ><=3D3B*CLONGLONG*>=3D3B.. if it i=3D > >>> s necessary to tell the compiler > =3D3D
>=3D3B = > >>=3D3Bthat
>=3D3B > >=3D3B&=3D > >>> gt=3D3B a special linkage convention is > needed).
>=3D3B = > >>=3D3B
>=3D3B &=3D > >>> gt=3D3BThere's no special linkage convention. > Not sure what you mean = > >here. >>>> >=3D3B > >=3D3B
>=3D3B
>=3D3B I > just mean if we = > >had
>=3D3B
>=3D > >>> =3D3B TYPE LONGINT =3D3D ARRAY [0..1] OF > INTEGER
>=3D3B = > >
>=3D3B that woul=3D > >>> d perhaps not match how C handles "long long" > on the same
>=3D3B = > >platfor=3D > >>> m (which is how=3D2C come to think of > it?)=3D2C and that would = > >require
>=3D > >>> =3D3B special linkage > tricks.
>=3D3B
>=3D3B But > what would = > >be lost? Th=3D > >>> e ability to type literals. >
>=3D3B
>=3D3B You could get > = > >the same co=3D > >>> de interface on 32- and 64-bit machine > by
>=3D3B = > >defining
>=3D3B
=3D > >>> >=3D3B TYPE FileOffset =3D3D ARRAY[0..1] > OF [-16_80000000 .. = > >+16_7fffffff ] >>> R>>=3D3B
>=3D3B and > using that.
>=3D3B
>=3D3B = > >
>=3D3B Mika >>>> > > > > >>> =3D > >>>=20 > >>> --_264cb69b-0215-44c3-807c-8b4d8ea0ea59_-- > From jay.krell at cornell.edu Mon Apr 19 06:43:54 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 19 Apr 2010 04:43:54 +0000 Subject: [M3devel] Posix < 0 vs. # 0 vs. = -1? In-Reply-To: References: , Message-ID: > much cheaper Ah. I hadn't considered that. It looks like we might gain commonality in socket code though by checking for a specific value. C:\dev2\cm3.2\m3-libs\m3core\src\win32\WinSock.i3(293): SOCKET_ERROR = -1; - Jay From: hosking at cs.purdue.edu Date: Sun, 18 Apr 2010 15:09:00 -0400 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] Posix < 0 vs. # 0 vs. = -1? Checking < 0 is much cheaper than checking = -1. C idioms typically check < 0. -1 is simply a convenient negative value to return. Leave it as is. On 18 Apr 2010, at 09:57, Jay K wrote: Posix often says: function foo() returns 0 for success, -1 for error m3core/libm3/etc, often say if foo() < 0 or if foo() # 0 "instead". Generally ok to tighten these up to "= -1", perhaps upon checking manpages, or a known rat's nest of inconsistencies? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Apr 19 08:54:09 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 19 Apr 2010 06:54:09 +0000 Subject: [M3devel] INTEGER In-Reply-To: <141192.73575.qm@web23603.mail.ird.yahoo.com> References: <20100418195901.CDACB1A20F6@async.async.caltech.edu>, <141192.73575.qm@web23603.mail.ird.yahoo.com> Message-ID: I believe the 128bit and 256bit types are implemented with compiler extensions but not language extensions. They declare records and "functions", but the compilers implement the "functions" inline (roughly one instruction each). This is akin to interface Word and generic interface Atomic. They are "just" libraries from a language point of view, but the compiler knows about them and inlines them. Well, at least the "packed" types. There are larger "scalar" types coming? That support infix operators? Again, so far as we have all figured out (I'm guessing and building on a hint Mika provided), it is mostly just about literals and infix notation. And if that is the case, it really shows that a language ought to be a bit more flexible in the first place (user defined infix operators on user defined types), and then it won't need as much extending later on. Nobody really prefers "Word.Plus(a, b)" over "a + b"... - Jay > Date: Mon, 19 Apr 2010 04:47:14 +0000 > From: dabenavidesd at yahoo.es > To: hosking at cs.purdue.edu; mika at async.async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] INTEGER > > Hi: > I think the irrelevant point is arguable as there are SIMD instructions of 128-bit and later will be 256-bit packed types registers so the point of becoming irrelevant could be worrisome in time, probably not now. As packed types weren't to traumatic but are more needed now by this fact. > If you wish more generality, a language change will be needed, not an extension, language extensions are easily doable with enough knowledge but right now you would need to do it or it will become harder and harder to reconstruct your own code. If you need backward compatibility why don't host cm3 with pm3, that is old cm3 can't compile cm3 but its negative inverse is true and it is old known old cm3 can build pm3 and src m3 (current cm3 built itself as I saw with RC5 on AMD64_LINUX). Still you want to host other older environments look for doing it with CM3, I think it wouldn't be so much traumatic, wouldn't it? You would compile and have two different runtime but you could do what you want to do, as I guess you were doing for other reasons and it wouldn't be so much effort to do it, maybe the ugly parts would be system dependent things as I think. > I think there are many other options as to be backwards compatible like drop new features or build against other specific libraries, but again is not that the purpose you are looking for, then is simpler if you think the above intention in some sense to you? > It's just an idea, hope it helps something. > > --- El dom, 18/4/10, Mika Nystrom escribi?: > > > De: Mika Nystrom > > Asunto: Re: [M3devel] INTEGER > > Para: "Tony Hosking" > > CC: m3devel at elegosoft.com > > Fecha: domingo, 18 de abril, 2010 14:59 > > > > My problem is really just that it's ugly. LONGx is > > showing up as an issue > > in all sorts of low-level code, which is not surprising > > since Modula-3 > > with LONGx is not the same language as Modula-3 (maybe we > > should call > > it Modula-3+?) > > > > The compiler bootstrapping process has gotten more > > complicated due to it, > > and when I cvs updated m3tk yesterday stubgen wouldn't > > compile because there > > was something "long" in it that wasn't there before. > > I have no idea what > > library or components I needed to update and recompile and > > didn't have the > > time to deal with the issue at the time. > > > > And the new m3tk, stubgen, and compiler(?) won't compile > > using PM3 or > > SRC M3 since we're no longer using the language of the > > Green Book. > > (Same comment goes for WIDECHAR, by the way.) > > > > One of the wonderful things about Modula-3 *used to be* > > that I could > > grab some old package from DECSRC and just use it without > > changes since > > no one had messed with the language definition. This > > is still true as > > far as programs that just use the tools go, but it's no > > longer true for > > programs that process Modula-3 code as input data. Of > > which there are > > more than a few: many aspects of Modula-3 were specifically > > designed to > > make the language easy to process by program, as an > > intermediate format > > and whatnot. > > > > To quote E.W.D.: > > > > 'Unfathomed misunderstanding is further revealed by the > > term "software > > maintenance", as a result of which many people continue to > > believe that > > programs and even programming languages themselves are > > subject to wear > > and tear. Your car needs maintenance too, doesn't it? > > Famous is the story > > of the oil company that believed that its PASCAL programs > > did not last > > as long as its FORTRAN programs "because PASCAL was not > > maintained".' > > > > LONGx is causing me to have to do "software maintenance" on > > Modula-3 > > programs... for a feature that no one appears to be using > > and is quickly > > becoming irrelevant. > > > > Mika > > > > > > Tony Hosking writes: > > >In the language spec NUMBER(a) and LAST(a) - FIRST(a) + > > 1 are *not* = > > >defined to mean the same thing for all types. > > >NUMBER does have an INTEGER value, as expected for > > subranges of LONGINT = > > >that are not too large. > > >This is as it has always been for subranges of INTEGER > > that are not too = > > >large. > > > > > >Mika, I'm not sure I see any of the problems you are > > worrying about in = > > >the current definition of LONGINT/LONGCARD. > > > > > >On 18 Apr 2010, at 03:49, Mika Nystrom wrote: > > > > > >>=20 > > >> Jay I know most of this, and it doesn't really > > answer the question > > >> "what is it for?" > > >>=20 > > >> I think we've already established that LONGINT > > isn't useful for = > > >counting > > >> anything that might actually reside in the > > computer's memory: it makes > > >> no sense as an array index, for instance. > > INTEGER suffices for that. > > >>=20 > > >> I thought that the only real reason for LONGINT > > was to match C's > > >> declaration of various seek-related routines on > > 32-bit machines. > > >> That's not a very good reason. > > >>=20 > > >> C++ succeeds because it does very well in the > > area(s) it is good at. > > >> People who want to program in C++ will clearly > > program in C++, not > > >> Modula-3. Modula-3 is never, ever going to > > be the language of choice = > > >for > > >> people who want lots of snazzy infix > > operators. Modula-3 is supposed = > > >to > > >> be a language with about as powerful semantics as > > C++ and an extremely > > >> simple syntax and definition---snazzy infix is one > > of the things you > > >> give up for that. I don't see how LONGINT > > fits into this picture. > > >> Now we have LONGCARD too? And it's infected > > the definitions > > >> of FIRST and LAST? But not NUMBER... argh! > > >>=20 > > >> so, > > >>=20 > > >> NUMBER(a) and LAST(a) - FIRST(a) + 1 > > >>=20 > > >> no longer mean the same thing? Are we going > > to see lots of comments > > >> in generics in the future where it says T may not > > be an open array > > >> type nor an array type indexed on LONGINT or a > > subrange thereof? > > >>=20 > > >> Your comments about different parameter-passing > > techniques was what I = > > >was > > >> trying to address with my suggestion to have a > > pragma for this---just = > > >to > > >> match C (and Fortran?), of course. Name me a > > single Modula-3 = > > >programmer > > >> who cares in what order the bits in his parameters > > are pushed on the > > >> stack in a Modula-3-to-Modula-3 call. > > >>=20 > > >> And I am definitely in that school of thought that > > says that = > > >programming > > >> languages should not "evolve". Better to > > leave well enough alone. > > >>=20 > > >> How much Modula-3 code has been written that uses > > LONGINT? Other than > > >> to talk to C? I've certainly never used it. > > >>=20 > > >> Mika > > >>=20 > > >>=20 > > >>=20 > > >> Jay K writes: > > >>> --_264cb69b-0215-44c3-807c-8b4d8ea0ea59_ > > >>> Content-Type: text/plain; > > charset=3D"iso-8859-1" > > >>> Content-Transfer-Encoding: quoted-printable > > >>>=20 > > >>>=20 > > >>> TYPE LONGINT =3D3D ARRAY [0..1] OF INTEGER on > > a 32bit system is very = > > >close to=3D > > >>> LONGINT. > > >>>=20 > > >>> Plus treating it opaquely and providing a > > bunch of functions to = > > >operate on=3D > > >>> it. > > >>>=20 > > >>> Just as well therefore could be RECORD > > hi=3D2Clo:LONGINT END (see = > > >LARGE_INTE=3D > > >>> GER and ULARGE_INTEGER in winnt.h) > > >>>=20 > > >>> =3D20 > > >>>=20 > > >>> Differences that come to mind: > > >>>=20 > > >>> infix operators > > <=3D3D=3D3D=3D3D=3D20 > > >>>=20 > > >>> possibly passed differently as a parameter > > >>>=20 > > >>> or returned differently as a result > > >>>=20 > > >>> ie. probably "directly compatible with" "long > > long"=3D2C passed by = > > >value (o=3D > > >>> f course you could always pass by pointer and > > achieve compatibilitity = > > >trivi=3D > > >>> ally) > > >>>=20 > > >>> =3D20 > > >>>=20 > > >>> =3D20 > > >>>=20 > > >>> I have to say though=3D2C the biggest reason > > is in-fix operators. = > > >Convenient =3D > > >>> syntax. > > >>>=20 > > >>> C++ is the best and some way worst of example > > of the general right = > > >way to d=3D > > >>> o this -- you let programmers define types and > > their infix operators. = > > >Other=3D > > >>> languages just come with a passle of special > > cases of types that have = > > >in-f=3D > > >>> ix operators. > > >>>=20 > > >>> A good example is that Java infix operator + > > on string=3D2C besides = > > >the vario=3D > > >>> us integers=3D2C and nothing else. > > >>>=20 > > >>> =3D20 > > >>>=20 > > >>> =3D20 > > >>>=20 > > >>> I think C# lets you define operators=3D2C yet > > people don't complain = > > >that it i=3D > > >>> s "a mess" as they do of C++. > > >>>=20 > > >>> I think Python does now too. > > >>>=20 > > >>> So it is feature growing in popularity among > > "mainstream" = > > >languages=3D2C not =3D > > >>> just C++. > > >>>=20 > > >>> C++ of course is extremely > > mainstream=3D2C but also a favorite = > > >target. (ht=3D > > >>> tp://www.relisoft.com/tools/CppCritic.html) > > >>>=20 > > >>> =3D20 > > >>>=20 > > >>> =3D20 > > >>>=20 > > >>> We also have subranges of LONGINT. > > >>>=20 > > >>> I'm not sure what the generalization of > > subranges are=3D2C granted. > > >>>=20 > > >>> Maybe some sort of C++ template that takes > > constants in the template = > > >and d=3D > > >>> oes range checks at runtime. Yeah=3D2C maybe. > > >>>=20 > > >>> =3D20 > > >>>=20 > > >>> =3D20 > > >>>=20 > > >>> And as you point out=3D2C convenient literal > > syntax. > > >>>=20 > > >>> =3D20 > > >>>=20 > > >>> =3D20 > > >>>=20 > > >>> People reasonably argue for library extension > > in place of language = > > >extensio=3D > > >>> n=3D2C but that requires a language which is > > flexible enough to write = > > >librari=3D > > >>> es with the desired interface=3D2C and so many > > languages don't let = > > >infix oper=3D > > >>> ators be in a user-written library. > > >>>=20 > > >>> (There is a subtle but useless distinction > > here -- infix operators = > > >being in=3D > > >>> libraries vs. "user-written" libraries. The > > infix set operations for = > > >examp=3D > > >>> le are in a library=3D2C but not > > user-written=3D2C special=3D2C the = > > >compiler know=3D > > >>> s about it.) > > >>>=20 > > >>> =3D20 > > >>>=20 > > >>>> that would perhaps not match how C handles > > "long long" on the same > > >>>> platform (which is how=3D2C come to think > > of it?)=3D2C and that = > > >would require > > >>>=20 > > >>>=20 > > >>> =3D20 > > >>>=20 > > >>> On NT/x86=3D2C __int64/long long is returned > > in the register pair = > > >edx:eax. > > >>>=20 > > >>> edx is high=3D2C eax is low. > > >>>=20 > > >>> When passed as a parameter to __stdcall or > > __cdecl is just passed as = > > >two 32=3D > > >>> bit values adjacent on the stack=3D2C "hi=3D2C > > lo=3D2C hi=3D2C lo=3D2C = > > >it's off to pu=3D > > >> sh we go" is the Snow White-influenced mantra to > > remember how to pass = > > >them=3D > > >>> =3D2C at least on little endian > > stack-growing-down machines (which = > > >includes x=3D > > >>> 86). For __fastcall I'm not sure they are > > passed in registers or on = > > >the sta=3D > > >>> ck. > > >>>=20 > > >>> Passing and/or returning small structs also > > has special efficient = > > >handling =3D > > >>> in the ABI=3D2C so __int64 really might be > > equivalent to a small = > > >record. Not =3D > > >>> that cm3 necessarily implements that > > "correctly" -- for interop with = > > >C=3D3B =3D > > >>> for Modula-3 calling Modula-3 we can make up > > our own ABI so there = > > >isn't rea=3D > > >>> lly an "incorrect" way. Notice the mingw > > problem I had passing a = > > >Win32 poin=3D > > >>> t struct by value=3D2C I cheated and passed it > > by VAR to a C wrapper = > > >to worka=3D > > >>> round the gcc backend bug (which was mentioned > > a few times and which = > > >I look=3D > > >>> ed into the code for=3D2C but took the easy > > route) > > >>>=20 > > >>> =3D20 > > >>>=20 > > >>> =3D20 > > >>>=20 > > >>> I don't know how long long works on other > > platforms but probably = > > >similar. > > >>>=20 > > >>> Probably a certain register pair for return > > values. > > >>>=20 > > >>> =3D20 > > >>>=20 > > >>> - Jay > > >>>=20 > > >>> =3D20 > > >>>> To: hosking at cs.purdue.edu > > >>>> Date: Sat=3D2C 17 Apr 2010 19:47:03 -0700 > > >>>> From: mika at async.async.caltech.edu > > >>>> CC: m3devel at elegosoft.com > > >>>> Subject: Re: [M3devel] INTEGER > > >>>> =3D20 > > >>>> Tony Hosking writes: > > >>>>>=20 > > >>>> ... > > >>>>>=20 > > >>>>>> We need it to match 64-bit > > integers on 32-bit machines? That seems = > > >=3D3D > > >>>>> like > > >>>>>> a very weak rationale indeed=3D2C > > if the same functionality could = > > >be =3D3D > > >>>>> provided > > >>>>>> through some other mechanism > > (e.g.=3D2C ARRAY [0..1] OF = > > >INTEGER---even =3D > > >>> =3D3D > > >>>>> with > > >>>>>> a pragma e.g. > > <*CLONGLONG*>.. if it is necessary to tell the = > > >compiler =3D > > >>> =3D3D > > >>>>> that > > >>>>>> a special linkage convention is > > needed). > > >>>>>=20 > > >>>>> There's no special linkage convention. > > Not sure what you mean here. > > >>>>>=20 > > >>>> =3D20 > > >>>> I just mean if we had > > >>>> =3D20 > > >>>> TYPE LONGINT =3D3D ARRAY [0..1] OF > > INTEGER > > >>>> =3D20 > > >>>> that would perhaps not match how C handles > > "long long" on the same > > >>>> platform (which is how=3D2C come to think > > of it?)=3D2C and that = > > >would require > > >>>> special linkage tricks. > > >>>> =3D20 > > >>>> But what would be lost? The ability to > > type literals.=3D20 > > >>>> =3D20 > > >>>> You could get the same code interface on > > 32- and 64-bit machine by > > >>>> defining > > >>>> =3D20 > > >>>> TYPE FileOffset =3D3D ARRAY[0..1] OF > > [-16_80000000 .. +16_7fffffff ] > > >>>> =3D20 > > >>>> and using that. > > >>>> =3D20 > > >>>> =3D20 > > >>>> Mika > > >>> > > > > > > =3D > > >>>=20 > > >>> --_264cb69b-0215-44c3-807c-8b4d8ea0ea59_ > > >>> Content-Type: text/html; > > charset=3D"iso-8859-1" > > >>> Content-Transfer-Encoding: quoted-printable > > >>>=20 > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> TYPE LONGINT =3D3D ARRAY [0..1] OF INTEGER on > > a =3D3B32bit system = > > >is very c=3D > > >>> lose to LONGINT.
> > >>>  =3D3BPlus treating it opaquely and > > providing a bunch of = > > >functions to ope=3D > > >>> rate on it.
> > >>>  =3D3BJust as well therefore could be > > RECORD hi=3D2Clo:LONGINT = > > >END (see LAR=3D > > >>> GE_INTEGER and ULARGE_INTEGER in > > winnt.h)
> > >>>  =3D3B
> > >>> Differences that come to mind:
> > >>>  =3D3B =3D3Binfix > > operators =3D3B <=3D3B=3D3D=3D3D=3D3D = > > >
> > >>>  =3D3B possibly passed > > differently =3D3Bas a parameter
> > >>>  =3D3B or returned differently as a > > result
> > >>>  =3D3B ie. probably "directly > > compatible with" "long long"=3D2C = > > >passed by v=3D > > >>> alue (of course you could always pass by > > pointer and achieve = > > >compatibilitit=3D > > >>> y trivially)
> > >>>  =3D3B
> > >>>  =3D3B
> > >>> I have to say though=3D2C the biggest reason > > is in-fix operators. = > > >Convenient =3D > > >>> syntax.
> > >>> C++ is the best and some way worst of example > > of the general right = > > >way to d=3D > > >>> o this -- you let programmers define types and > > their infix operators. = > > >Other=3D > > >>> languages just come with a passle of special > > cases of types that have = > > >in-f=3D > > >>> ix operators.
> > >>> A good example is that Java infix operator + > > on string=3D2C besides = > > >the vario=3D > > >>> us integers=3D2C and nothing else.
> > >>>  =3D3B
> > >>>  =3D3B
> > >>> I think C# lets you define operators=3D2C yet > > people don't complain = > > >that it i=3D > > >>> s "a mess" as they do of C++.
> > >>> I think Python does now too.
> > >>> So it is feature growing in popularity among > > "mainstream" = > > >languages=3D2C not =3D > > >>> just C++.
> > >>>  =3D3B =3D3B C++ of course is > > extremely mainstream=3D2C but = > > >also a favori=3D > > >>> te target. ( > >href=3D3D"http://www.relisoft.com/tools/CppCritic.html">http:/=3D > > >>> > > /www.relisoft.com/tools/CppCritic.html)
> > >>>  =3D3B
> > >>>  =3D3B
> > >>> We also have subranges of LONGINT.
> > >>> I'm not sure what the generalization of > > subranges are=3D2C = > > >granted.
> > >>>  =3D3BMaybe some sort of C++ template > > that takes constants in the = > > >templat=3D > > >>> e and does range checks at runtime. Yeah=3D2C > > maybe.
> > >>>  =3D3B
> > >>>  =3D3B
> > >>> And as you point out=3D2C convenient literal > > syntax.
> > >>>  =3D3B
> > >>>  =3D3B
> > >>> People reasonably argue for library extension > > in place of language = > > >extensio=3D > > >>> n=3D2C but that requires a language which is > > flexible enough to write = > > >librari=3D > > >>> es with the desired interface=3D2C and so many > > languages don't let = > > >infix oper=3D > > >>> ators be in a user-written library.
> > >>> (There is a subtle but useless distinction > > here -- infix operators = > > >being in=3D > > >>> libraries vs. "user-written" libraries. The > > infix set operations for = > > >examp=3D > > >>> le are in a library=3D2C but not > > user-written=3D2C special=3D2C the = > > >compiler know=3D > > >>> s about it.)
> > >>>  =3D3B
> > >>> >=3D3B that would perhaps not match how > > C handles "long long" on = > > >the same > >>> R>>=3D3B platform (which is how=3D2C > > come to think of it?)=3D2C and = > > >that would =3D > > >>> require

> > >>>  =3D3B
> > >>> On NT/x86=3D2C __int64/long long is returned > > in the register pair = > > >edx:eax. > >>>>=20 > > >>> edx is high=3D2C eax is low.
> > >>> When passed as a parameter to __stdcall or > > __cdecl is just passed as = > > >two 32=3D > > >>> bit values adjacent on the stack=3D2C "hi=3D2C > > lo=3D2C hi=3D2C lo=3D2C = > > >it's off to pu=3D > > >>> sh we go" is the Snow White-influenced mantra > > to remember how to pass = > > >them=3D > > >>> =3D2C at least on little endian > > stack-growing-down machines (which = > > >includes x=3D > > >>> 86). For __fastcall I'm not sure they are > > passed in registers or on = > > >the sta=3D > > >>> ck.
> > >>> Passing and/or returning small structs also > > has special efficient = > > >handling =3D > > >>> in the ABI=3D2C so __int64 really might be > > equivalent to a small = > > >record. Not =3D > > >>> that cm3 necessarily implements that > > "correctly" =3D3B -- for = > > >interop wit=3D > > >>> h C=3D3B for Modula-3 calling Modula-3 we can > > make up our own ABI so = > > >there is=3D > > >>> n't =3D3Breally an "incorrect" > > way. =3D3BNotice the mingw = > > >problem I had=3D > > >>> passing a Win32 point struct by value=3D2C I > > cheated and passed it by = > > >VAR to=3D > > >>> a =3D3BC wrapper to workaround the gcc > > backend bug (which was = > > >mentioned =3D > > >>> a few times and which I looked into the code > > for=3D2C but took the = > > >easy route=3D > > >>> )
> > >>>  =3D3B
> > >>>  =3D3B
> > >>> I don't know how long long works on other > > platforms but probably = > > >similar. > >>> R> > > >>> Probably a certain register pair for return > > values.
> > >>>  =3D3B
> > >>>  =3D3B- > > Jay

 =3D3B
>=3D3B > > To: = > > >hosking at cs.purdue.edu
>=3D3B=3D > > >>> Date: Sat=3D2C 17 Apr 2010 19:47:03 > > -0700
>=3D3B From: = > > >mika at async.async.c=3D > > >>> altech.edu
>=3D3B CC: m3devel at elegosoft.com
>=3D3B > > Subject: = > > >Re: [M3de=3D > > >>> vel] INTEGER
>=3D3B > >
>=3D3B Tony Hosking > > writes:
>=3D3B = > > >>=3D3B
=3D > > >>> >=3D3B ...
>=3D3B > > >=3D3B
>=3D3B >=3D3B>=3D3B > > We = > > >need it to match 64-b=3D > > >>> it integers on 32-bit machines? That seems > > =3D3D
>=3D3B = > > >>=3D3Blike
>=3D > > >>> =3D3B >=3D3B>=3D3B a very weak > > rationale indeed=3D2C if the same = > > >functionality =3D > > >>> could be =3D3D
>=3D3B > > >=3D3Bprovided
>=3D3B > > >=3D3B>=3D3= > > >B through some o=3D > > >>> ther mechanism (e.g.=3D2C ARRAY [0..1] OF > > INTEGER---even = > > >=3D3D
>=3D3B >=3D3B=3D > > >>> with
>=3D3B > > >=3D3B>=3D3B a pragma e.g. = > > ><=3D3B*CLONGLONG*>=3D3B.. if it i=3D > > >>> s necessary to tell the compiler > > =3D3D
>=3D3B = > > >>=3D3Bthat
>=3D3B > > >=3D3B&=3D > > >>> gt=3D3B a special linkage convention is > > needed).
>=3D3B = > > >>=3D3B
>=3D3B &=3D > > >>> gt=3D3BThere's no special linkage convention. > > Not sure what you mean = > > >here. > >>>> >=3D3B > > >=3D3B
>=3D3B
>=3D3B I > > just mean if we = > > >had
>=3D3B
>=3D > > >>> =3D3B TYPE LONGINT =3D3D ARRAY [0..1] OF > > INTEGER
>=3D3B = > > >
>=3D3B that woul=3D > > >>> d perhaps not match how C handles "long long" > > on the same
>=3D3B = > > >platfor=3D > > >>> m (which is how=3D2C come to think of > > it?)=3D2C and that would = > > >require
>=3D > > >>> =3D3B special linkage > > tricks.
>=3D3B
>=3D3B But > > what would = > > >be lost? Th=3D > > >>> e ability to type literals. > >
>=3D3B
>=3D3B You could get > > = > > >the same co=3D > > >>> de interface on 32- and 64-bit machine > > by
>=3D3B = > > >defining
>=3D3B
=3D > > >>> >=3D3B TYPE FileOffset =3D3D ARRAY[0..1] > > OF [-16_80000000 .. = > > >+16_7fffffff ] > >>> R>>=3D3B
>=3D3B and > > using that.
>=3D3B
>=3D3B = > > >
>=3D3B Mika > >>>> > > > > > > > > >>> =3D > > >>>=20 > > >>> --_264cb69b-0215-44c3-807c-8b4d8ea0ea59_-- > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Apr 19 12:20:45 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 19 Apr 2010 10:20:45 +0000 Subject: [M3devel] "post rc5" Message-ID: "post" archives appear on the main page. I'll try again to build AMD64/I386_DARWIN just via Hudson. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Apr 19 13:48:02 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 19 Apr 2010 13:48:02 +0200 Subject: [M3devel] hudson on birch down again Message-ID: <20100419134802.vxcfp982s0k4sgsc@mail.elegosoft.com> Can you please have a look and fix that? 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 kay.haeusler at elego.de Mon Apr 19 13:58:21 2010 From: kay.haeusler at elego.de (Kay =?UTF-8?B?SMOkdXNsZXI=?=) Date: Mon, 19 Apr 2010 13:58:21 +0200 Subject: [M3devel] hudson on birch down again In-Reply-To: <20100419134802.vxcfp982s0k4sgsc@mail.elegosoft.com> References: <20100419134802.vxcfp982s0k4sgsc@mail.elegosoft.com> Message-ID: <20100419135821.266c5b2e@pine.elego.de> Hallo Olaf, Olaf Wagner wrote: > Can you please have a look and fix that? I've restarted hudson. -- Mit freundlichen Gr??en Kay H?usler mailto:kay.haeusler at elego.de elego Software Solutions GmbH http://www.elego.de Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 13355 Berlin, Germany Amtsgericht Charlottenburg Tel.: +49 30 23458696 Sitz der Gesellschaft: Berlin Fax: +49 30 23458695 Gesch?ftsf?hrer: Olaf Wagner From jay.krell at cornell.edu Mon Apr 19 14:10:41 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 19 Apr 2010 12:10:41 +0000 Subject: [M3devel] SchedulerPosix/Win32/sockets Message-ID: short story: I think we should have SchedulerPosix.IOWait and SchedulerPosix.IOAlertWait, but not SchedulerPosix.WaitProces, on Win32. With the CARDINAL changed back to INTEGER. As well, as before, I'd like to only have one implementation of this. Currently there are two identical copies, due to Cygwin. But this proposal is for regular Win32. long story: Win32 has select, for sockets. Instead of a bitset, it uses an array of 64, so doesn't have the problem that poll fixes. SocketPosix.m3 makes sockets non-blocking and uses IOWait and IOAlertWait. SocketPosix.Connect/Accept are alertable. SocketWin32.Connect/Accept are not alertable. That seems wrong, eh? I assume this difference is due to original implementers not realizing their options on Win32. I assume this difference would be good to remove. IOWait is merely a call to select (assuming kernel threads). In rewritten-in-C, I can easily just #ifdef and call select on Win32. IOAlertWait is implemented by polling via select/poll for up to a maximum of a second at a time, testing alert between each. It is this code that I don't think should be duplicated. We already have two copies of it due to Cygwin. (I think we might be able to do better on Win32 though, by using Win32 alerting as part of Modula-3 alerting, but for the time being, sharing code with Posix that polls every second would be ok.) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Apr 19 14:11:52 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 19 Apr 2010 12:11:52 +0000 Subject: [M3devel] SchedulerPosix/Win32/sockets Message-ID: short story: I think we should have SchedulerPosix.IOWait and SchedulerPosix.IOAlertWait, but not SchedulerPosix.WaitProces, on Win32. With the CARDINAL changed back to INTEGER. As well, as before, I'd like to only have one implementation of this. Currently there are two identical copies, due to Cygwin. But this proposal is for regular Win32. long story: Win32 has select, for sockets. Instead of a bitset, it uses an array of 64, so doesn't have the problem that poll fixes. SocketPosix.m3 makes sockets non-blocking and uses IOWait and IOAlertWait. SocketPosix.Connect/Accept are alertable. SocketWin32.Connect/Accept are not alertable. That seems wrong, eh? I assume this difference is due to original implementers not realizing their options on Win32. I assume this difference would be good to remove. IOWait is merely a call to select (assuming kernel threads). In rewritten-in-C, I can easily just #ifdef and call select on Win32. IOAlertWait is implemented by polling via select/poll for up to a maximum of a second at a time, testing alert between each. It is this code that I don't think should be duplicated. We already have two copies of it due to Cygwin. (I think we might be able to do better on Win32 though, by using Win32 alerting as part of Modula-3 alerting, but for the time being, sharing code with Posix that polls every second would be ok.) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Apr 19 16:03:16 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 19 Apr 2010 14:03:16 +0000 Subject: [M3devel] deleting most of m3core/src/unix? Message-ID: I went ahead and did this. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Subject: deleting most of m3core/src/unix? Date: Thu, 15 Apr 2010 14:43:23 +0000 Ok..maybe now time to delete all of m3core/src/unix except for uin-*, Common, and part of solaris-2-x? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Apr 19 16:04:39 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 19 Apr 2010 14:04:39 +0000 Subject: [M3devel] JVideo/struct_timeval? Message-ID: I went ahead and put in a local type. Utime.struct_timeval is now gone. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Subject: JVideo/struct_timeval? Date: Mon, 12 Apr 2010 13:03:26 +0000 This seems wierd: C:\dev2\cm3.2\m3-ui\jvideo\src\POSIX\jvprotocol.i3(193): timestamp: Utime.struct_timeval; I think they are defining a wire protocol, but embedding platform-specific types in it. How about I just change to Time.T? (64bit floating point, seconds since 1970). We could do like: C:\dev2\cm3.2\m3-ui\jvideo\src\POSIX\decunix\JVSink.m3(440): jvb.timestamp.tv_sec := signed_ntohl(hdr.timestamp.tv_sec); and define it to be transferred as a network order 64bit integer (big endian LONGINT), or maybe an array of 8 bytes. Or maybe define a local struct_timeval separate from Utime that hardcodes the sizes..and maybe using LONGINT? 32bit time_t is apparently still very common, though it seems obviously a big mistake.. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Apr 19 16:15:06 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 19 Apr 2010 16:15:06 +0200 Subject: [M3devel] giant lock in SocketWin32.m3? In-Reply-To: References: <20100418140821.428882474008@birch.elegosoft.com> Message-ID: <20100419161506.w9l7qydxc08sggwk@mail.elegosoft.com> Quoting Jay K : > > Anyone know why SocketWin32.m3 has had a giant lock around everything? > > I see no point to it. > > The only global variable is related to on-demand initialization. > > And even that wasn't handled correctly.. Perhaps the network stack on Windows95/98 wasn't really reentrant? Just a guess though. The code is quite old as far as I know. 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 jay.krell at cornell.edu Mon Apr 19 17:31:33 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 19 Apr 2010 15:31:33 +0000 Subject: [M3devel] giant lock in SocketWin32.m3? In-Reply-To: <20100419161506.w9l7qydxc08sggwk@mail.elegosoft.com> References: <20100418140821.428882474008@birch.elegosoft.com>, , <20100419161506.w9l7qydxc08sggwk@mail.elegosoft.com> Message-ID: > Perhaps the network stack on Windows95/98 wasn't really reentrant? No. Your expectations are much too low. Imagine if this was true. Then all Windows networking code would have its own giant locks, and you'd read about this in documentation and such. I'm not sure of the terminology, but: "Reentrant" is a strong word. "Thread safe" is a weaker more common one. For example strtok is not reentrant, but typically thread safe, through use of "thread locals". You can't use strtok in a nested for loop though. It's not that the code is old per se. I think a lot of it was slapped together quickly and then not really reviewed or tested much, and doesn't get much use either. I constantly see incorrect on-demand initialization as well. This code had it as well. - Jay > Date: Mon, 19 Apr 2010 16:15:06 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] giant lock in SocketWin32.m3? > > Quoting Jay K : > > > > > Anyone know why SocketWin32.m3 has had a giant lock around everything? > > > > I see no point to it. > > > > The only global variable is related to on-demand initialization. > > > > And even that wasn't handled correctly.. > > Perhaps the network stack on Windows95/98 wasn't really reentrant? > > Just a guess though. The code is quite old as far as I know. > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.async.caltech.edu Mon Apr 19 19:23:13 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Mon, 19 Apr 2010 10:23:13 -0700 Subject: [M3devel] INTEGER In-Reply-To: References: , , , <7C7408D0-9A40-4988-BADA-A9FD8C15D388@cs.purdue.edu>, , , , , , , <20100418023535.3BA9E1A2103@async.async.caltech.edu>, , <20100418024703.6965B1A2103@async.async.caltech.edu> <20100418074927.934461A2117@async.async.caltech.edu> <04EB7FF8-D304-428D-839E-233FCE009C98@cs.purdue.edu> <20100418195901.CDACB1A20F6@async.async.caltech.edu> Message-ID: <20100419172313.68B241A20D6@async.async.caltech.edu> Well *my* problem is that I still use PM3 for a lot of things. Trying to switch to CM3, yes, but I can't "certify" CM3 for critical stuff yet. So I'm maintaining a significant amount of code that needs to compile under both PM3 and CM3. Two problems crop up. 1. If there are bugs in m3tk/stubgen, the fixes only apply to one or the other version of m3tk/stubgen. 2. Some of the code I'm maintaining processes Modula-3 code as input. It needs to be in two versions. In this kind of environment, programming languages don't really evolve, since the system depends on their being both forward- and backward-compatible. They "change" is more correct. The way Java changes. More in general, though, Modula-3's designers were clearly well acquainted with C, Fortran, and other languages that provide different-range integers. They chose not to indulge. I even have a version of Modula-3 for a 16-bit machine that doesn't do it, even though on this machine the need for a 32-bit integer is arguably greater than the need for 64-bit integers on 32-bit machines. Now we indulge in this language complication to solve what is clearly a temporary problem, since anyone who cares about large problems is going to have 64-bit systems yesterday... and meanwhile no one seems to have availed himself of the solution! My worst fear is that once the process gets started, the reason for staying with the original Green-Book specification has now been defeated and we will see more and more "evolution". Trying to actually build systems that process Modula-3 like data becomes, at that point, like trying to stand in quicksand. I'm not incredibly picky here... I just hope it doesn't go further. I would personally support either sticking with the current status quo or going back to the Green Book w.r.t. integers and characters. Saying that EWD wasn't renowned for his practicality is something he would have taken as a great compliment, I'm sure. Mika Tony Hosking writes: >Mika, > >First off, I'd be very interested to know what the issues are with = >LONGINT and stubgen. We are building that every day in regression = >testing. It would be really good to get some precise feedback. > >True, LONGINT is integrated with all of the language tools (same as = >WIDECHAR). > >I suppose that is the price we pay for the language having evolved. = >Nevertheless, CM3 should be totally backward compatible with the green = >book. There is no reason it should not build packages from PM3 or SRC. > >Now, this is not to say that perhaps we haven't overreached with LONGINT = >given that 64-bit is more prevalent. But then it is also useful to be = >able to interoperate with C libraries. The previous interfacing was = >pretty much a kludge, using ARRAY[0..1] OF INTEGER for "long long" but = >then not propagating the double INTEGER value properly throughout the = >Modula-3 libraries. > >I'm sorry to say that EWD was not particularly renowned for his = >practicality; pedant more like. Nice to be high and mighty but we also = >need to interact with the real world. > >We should be able to make this work. Is there a better alternative? = >Revoke LONGINT, and WIDECHAR? > >On 18 Apr 2010, at 15:59, Mika Nystrom wrote: > >>=20 >> My problem is really just that it's ugly. LONGx is showing up as an = >issue >> in all sorts of low-level code, which is not surprising since Modula-3 >> with LONGx is not the same language as Modula-3 (maybe we should call >> it Modula-3+?)=20 >>=20 >> The compiler bootstrapping process has gotten more complicated due to = >it, >> and when I cvs updated m3tk yesterday stubgen wouldn't compile because = >there >> was something "long" in it that wasn't there before. I have no idea = >what >> library or components I needed to update and recompile and didn't have = >the >> time to deal with the issue at the time. >>=20 >> And the new m3tk, stubgen, and compiler(?) won't compile using PM3 or >> SRC M3 since we're no longer using the language of the Green Book. >> (Same comment goes for WIDECHAR, by the way.) >>=20 >> One of the wonderful things about Modula-3 *used to be* that I could >> grab some old package from DECSRC and just use it without changes = >since >> no one had messed with the language definition. This is still true as >> far as programs that just use the tools go, but it's no longer true = >for >> programs that process Modula-3 code as input data. Of which there are >> more than a few: many aspects of Modula-3 were specifically designed = >to >> make the language easy to process by program, as an intermediate = >format >> and whatnot. >>=20 >> To quote E.W.D.: >>=20 >> 'Unfathomed misunderstanding is further revealed by the term "software >> maintenance", as a result of which many people continue to believe = >that >> programs and even programming languages themselves are subject to wear >> and tear. Your car needs maintenance too, doesn't it? Famous is the = >story >> of the oil company that believed that its PASCAL programs did not last >> as long as its FORTRAN programs "because PASCAL was not maintained".' >>=20 >> LONGx is causing me to have to do "software maintenance" on Modula-3 >> programs... for a feature that no one appears to be using and is = >quickly >> becoming irrelevant. >>=20 >> Mika >>=20 >>=20 >> Tony Hosking writes: >>> In the language spec NUMBER(a) and LAST(a) - FIRST(a) + 1 are *not* =3D= > >>> defined to mean the same thing for all types. >>> NUMBER does have an INTEGER value, as expected for subranges of = >LONGINT =3D >>> that are not too large. >>> This is as it has always been for subranges of INTEGER that are not = >too =3D >>> large. >>>=20 >>> Mika, I'm not sure I see any of the problems you are worrying about = >in =3D >>> the current definition of LONGINT/LONGCARD. >>>=20 >>> On 18 Apr 2010, at 03:49, Mika Nystrom wrote: >>>=20 >>>> =3D20 >>>> Jay I know most of this, and it doesn't really answer the question >>>> "what is it for?" >>>> =3D20 >>>> I think we've already established that LONGINT isn't useful for =3D >>> counting >>>> anything that might actually reside in the computer's memory: it = >makes >>>> no sense as an array index, for instance. INTEGER suffices for = >that. >>>> =3D20 >>>> I thought that the only real reason for LONGINT was to match C's >>>> declaration of various seek-related routines on 32-bit machines. >>>> That's not a very good reason. >>>> =3D20 >>>> C++ succeeds because it does very well in the area(s) it is good at. >>>> People who want to program in C++ will clearly program in C++, not >>>> Modula-3. Modula-3 is never, ever going to be the language of = >choice =3D >>> for >>>> people who want lots of snazzy infix operators. Modula-3 is = >supposed =3D >>> to >>>> be a language with about as powerful semantics as C++ and an = >extremely >>>> simple syntax and definition---snazzy infix is one of the things you >>>> give up for that. I don't see how LONGINT fits into this picture. >>>> Now we have LONGCARD too? And it's infected the definitions >>>> of FIRST and LAST? But not NUMBER... argh! >>>> =3D20 >>>> so, >>>> =3D20 >>>> NUMBER(a) and LAST(a) - FIRST(a) + 1 >>>> =3D20 >>>> no longer mean the same thing? Are we going to see lots of comments >>>> in generics in the future where it says T may not be an open array >>>> type nor an array type indexed on LONGINT or a subrange thereof? >>>> =3D20 >>>> Your comments about different parameter-passing techniques was what = >I =3D >>> was >>>> trying to address with my suggestion to have a pragma for = >this---just =3D >>> to >>>> match C (and Fortran?), of course. Name me a single Modula-3 =3D >>> programmer >>>> who cares in what order the bits in his parameters are pushed on the >>>> stack in a Modula-3-to-Modula-3 call. >>>> =3D20 >>>> And I am definitely in that school of thought that says that =3D >>> programming >>>> languages should not "evolve". Better to leave well enough alone. >>>> =3D20 >>>> How much Modula-3 code has been written that uses LONGINT? Other = >than >>>> to talk to C? I've certainly never used it. >>>> =3D20 >>>> Mika >>>> =3D20 >>>> =3D20 >>>> =3D20 >>>> Jay K writes: >>>>> --_264cb69b-0215-44c3-807c-8b4d8ea0ea59_ >>>>> Content-Type: text/plain; charset=3D3D"iso-8859-1" >>>>> Content-Transfer-Encoding: quoted-printable >>>>> =3D20 >>>>> =3D20 >>>>> TYPE LONGINT =3D3D3D ARRAY [0..1] OF INTEGER on a 32bit system is = >very =3D >>> close to=3D3D >>>>> LONGINT. >>>>> =3D20 >>>>> Plus treating it opaquely and providing a bunch of functions to =3D >>> operate on=3D3D >>>>> it. >>>>> =3D20 >>>>> Just as well therefore could be RECORD hi=3D3D2Clo:LONGINT END (see = >=3D >>> LARGE_INTE=3D3D >>>>> GER and ULARGE_INTEGER in winnt.h) >>>>> =3D20 >>>>> =3D3D20 >>>>> =3D20 >>>>> Differences that come to mind: >>>>> =3D20 >>>>> infix operators <=3D3D3D=3D3D3D=3D3D3D=3D3D20 >>>>> =3D20 >>>>> possibly passed differently as a parameter >>>>> =3D20 >>>>> or returned differently as a result >>>>> =3D20 >>>>> ie. probably "directly compatible with" "long long"=3D3D2C passed = >by =3D >>> value (o=3D3D >>>>> f course you could always pass by pointer and achieve = >compatibilitity =3D >>> trivi=3D3D >>>>> ally) >>>>> =3D20 >>>>> =3D3D20 >>>>> =3D20 >>>>> =3D3D20 >>>>> =3D20 >>>>> I have to say though=3D3D2C the biggest reason is in-fix operators. = >=3D >>> Convenient =3D3D >>>>> syntax. >>>>> =3D20 >>>>> C++ is the best and some way worst of example of the general right = >=3D >>> way to d=3D3D >>>>> o this -- you let programmers define types and their infix = >operators. =3D >>> Other=3D3D >>>>> languages just come with a passle of special cases of types that = >have =3D >>> in-f=3D3D >>>>> ix operators. >>>>> =3D20 >>>>> A good example is that Java infix operator + on string=3D3D2C = >besides =3D >>> the vario=3D3D >>>>> us integers=3D3D2C and nothing else. >>>>> =3D20 >>>>> =3D3D20 >>>>> =3D20 >>>>> =3D3D20 >>>>> =3D20 >>>>> I think C# lets you define operators=3D3D2C yet people don't = >complain =3D >>> that it i=3D3D >>>>> s "a mess" as they do of C++. >>>>> =3D20 >>>>> I think Python does now too. >>>>> =3D20 >>>>> So it is feature growing in popularity among "mainstream" =3D >>> languages=3D3D2C not =3D3D >>>>> just C++. >>>>> =3D20 >>>>> C++ of course is extremely mainstream=3D3D2C but also a favorite =3D >>> target. (ht=3D3D >>>>> tp://www.relisoft.com/tools/CppCritic.html) >>>>> =3D20 >>>>> =3D3D20 >>>>> =3D20 >>>>> =3D3D20 >>>>> =3D20 >>>>> We also have subranges of LONGINT. >>>>> =3D20 >>>>> I'm not sure what the generalization of subranges are=3D3D2C = >granted. >>>>> =3D20 >>>>> Maybe some sort of C++ template that takes constants in the = >template =3D >>> and d=3D3D >>>>> oes range checks at runtime. Yeah=3D3D2C maybe. >>>>> =3D20 >>>>> =3D3D20 >>>>> =3D20 >>>>> =3D3D20 >>>>> =3D20 >>>>> And as you point out=3D3D2C convenient literal syntax. >>>>> =3D20 >>>>> =3D3D20 >>>>> =3D20 >>>>> =3D3D20 >>>>> =3D20 >>>>> People reasonably argue for library extension in place of language = >=3D >>> extensio=3D3D >>>>> n=3D3D2C but that requires a language which is flexible enough to = >write =3D >>> librari=3D3D >>>>> es with the desired interface=3D3D2C and so many languages don't = >let =3D >>> infix oper=3D3D >>>>> ators be in a user-written library. >>>>> =3D20 >>>>> (There is a subtle but useless distinction here -- infix operators = >=3D >>> being in=3D3D >>>>> libraries vs. "user-written" libraries. The infix set operations = >for =3D >>> examp=3D3D >>>>> le are in a library=3D3D2C but not user-written=3D3D2C special=3D3D2C= > the =3D >>> compiler know=3D3D >>>>> s about it.) >>>>> =3D20 >>>>> =3D3D20 >>>>> =3D20 >>>>>> that would perhaps not match how C handles "long long" on the same >>>>>> platform (which is how=3D3D2C come to think of it?)=3D3D2C and = >that =3D >>> would require >>>>> =3D20 >>>>> =3D20 >>>>> =3D3D20 >>>>> =3D20 >>>>> On NT/x86=3D3D2C __int64/long long is returned in the register pair = >=3D >>> edx:eax. >>>>> =3D20 >>>>> edx is high=3D3D2C eax is low. >>>>> =3D20 >>>>> When passed as a parameter to __stdcall or __cdecl is just passed = >as =3D >>> two 32=3D3D >>>>> bit values adjacent on the stack=3D3D2C "hi=3D3D2C lo=3D3D2C = >hi=3D3D2C lo=3D3D2C =3D >>> it's off to pu=3D3D >>>> sh we go" is the Snow White-influenced mantra to remember how to = >pass =3D >>> them=3D3D >>>>> =3D3D2C at least on little endian stack-growing-down machines = >(which =3D >>> includes x=3D3D >>>>> 86). For __fastcall I'm not sure they are passed in registers or on = >=3D >>> the sta=3D3D >>>>> ck. >>>>> =3D20 >>>>> Passing and/or returning small structs also has special efficient =3D= > >>> handling =3D3D >>>>> in the ABI=3D3D2C so __int64 really might be equivalent to a small = >=3D >>> record. Not =3D3D >>>>> that cm3 necessarily implements that "correctly" -- for interop = >with =3D >>> C=3D3D3B =3D3D >>>>> for Modula-3 calling Modula-3 we can make up our own ABI so there =3D= > >>> isn't rea=3D3D >>>>> lly an "incorrect" way. Notice the mingw problem I had passing a =3D >>> Win32 poin=3D3D >>>>> t struct by value=3D3D2C I cheated and passed it by VAR to a C = >wrapper =3D >>> to worka=3D3D >>>>> round the gcc backend bug (which was mentioned a few times and = >which =3D >>> I look=3D3D >>>>> ed into the code for=3D3D2C but took the easy route) >>>>> =3D20 >>>>> =3D3D20 >>>>> =3D20 >>>>> =3D3D20 >>>>> =3D20 >>>>> I don't know how long long works on other platforms but probably =3D >>> similar. >>>>> =3D20 >>>>> Probably a certain register pair for return values. >>>>> =3D20 >>>>> =3D3D20 >>>>> =3D20 >>>>> - Jay >>>>> =3D20 >>>>> =3D3D20 >>>>>> To: hosking at cs.purdue.edu >>>>>> Date: Sat=3D3D2C 17 Apr 2010 19:47:03 -0700 >>>>>> From: mika at async.async.caltech.edu >>>>>> CC: m3devel at elegosoft.com >>>>>> Subject: Re: [M3devel] INTEGER >>>>>> =3D3D20 >>>>>> Tony Hosking writes: >>>>>>> =3D20 >>>>>> ... >>>>>>> =3D20 >>>>>>>> We need it to match 64-bit integers on 32-bit machines? That = >seems =3D >>> =3D3D3D >>>>>>> like >>>>>>>> a very weak rationale indeed=3D3D2C if the same functionality = >could =3D >>> be =3D3D3D >>>>>>> provided >>>>>>>> through some other mechanism (e.g.=3D3D2C ARRAY [0..1] OF =3D >>> INTEGER---even =3D3D >>>>> =3D3D3D >>>>>>> with >>>>>>>> a pragma e.g. <*CLONGLONG*>.. if it is necessary to tell the =3D >>> compiler =3D3D >>>>> =3D3D3D >>>>>>> that >>>>>>>> a special linkage convention is needed). >>>>>>> =3D20 >>>>>>> There's no special linkage convention. Not sure what you mean = >here. >>>>>>> =3D20 >>>>>> =3D3D20 >>>>>> I just mean if we had >>>>>> =3D3D20 >>>>>> TYPE LONGINT =3D3D3D ARRAY [0..1] OF INTEGER >>>>>> =3D3D20 >>>>>> that would perhaps not match how C handles "long long" on the same >>>>>> platform (which is how=3D3D2C come to think of it?)=3D3D2C and = >that =3D >>> would require >>>>>> special linkage tricks. >>>>>> =3D3D20 >>>>>> But what would be lost? The ability to type literals.=3D3D20 >>>>>> =3D3D20 >>>>>> You could get the same code interface on 32- and 64-bit machine by >>>>>> defining >>>>>> =3D3D20 >>>>>> TYPE FileOffset =3D3D3D ARRAY[0..1] OF [-16_80000000 .. = >+16_7fffffff ] >>>>>> =3D3D20 >>>>>> and using that. >>>>>> =3D3D20 >>>>>> =3D3D20 >>>>>> Mika >>>>> =3D3D >>>>> =3D20 >>>>> --_264cb69b-0215-44c3-807c-8b4d8ea0ea59_ >>>>> Content-Type: text/html; charset=3D3D"iso-8859-1" >>>>> Content-Transfer-Encoding: quoted-printable >>>>> =3D20 >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> TYPE LONGINT =3D3D3D ARRAY [0..1] OF INTEGER on a =3D3D3B32bit = >system =3D >>> is very c=3D3D >>>>> lose to LONGINT.
>>>>>  =3D3D3BPlus treating it opaquely and providing a bunch of =3D >>> functions to ope=3D3D >>>>> rate on it.
>>>>>  =3D3D3BJust as well therefore could be RECORD = >hi=3D3D2Clo:LONGINT =3D >>> END (see LAR=3D3D >>>>> GE_INTEGER and ULARGE_INTEGER in winnt.h)
>>>>>  =3D3D3B
>>>>> Differences that come to mind:
>>>>>  =3D3D3B =3D3D3Binfix operators =3D3D3B = ><=3D3D3B=3D3D3D=3D3D3D=3D3D3D =3D >>>
>>>>>  =3D3D3B possibly passed differently =3D3D3Bas a = >parameter
>>>>>  =3D3D3B or returned differently as a result
>>>>>  =3D3D3B ie. probably "directly compatible with" "long = >long"=3D3D2C =3D >>> passed by v=3D3D >>>>> alue (of course you could always pass by pointer and achieve =3D >>> compatibilitit=3D3D >>>>> y trivially)
>>>>>  =3D3D3B
>>>>>  =3D3D3B
>>>>> I have to say though=3D3D2C the biggest reason is in-fix operators. = >=3D >>> Convenient =3D3D >>>>> syntax.
>>>>> C++ is the best and some way worst of example of the general right = >=3D >>> way to d=3D3D >>>>> o this -- you let programmers define types and their infix = >operators. =3D >>> Other=3D3D >>>>> languages just come with a passle of special cases of types that = >have =3D >>> in-f=3D3D >>>>> ix operators.
>>>>> A good example is that Java infix operator + on string=3D3D2C = >besides =3D >>> the vario=3D3D >>>>> us integers=3D3D2C and nothing else.
>>>>>  =3D3D3B
>>>>>  =3D3D3B
>>>>> I think C# lets you define operators=3D3D2C yet people don't = >complain =3D >>> that it i=3D3D >>>>> s "a mess" as they do of C++.
>>>>> I think Python does now too.
>>>>> So it is feature growing in popularity among "mainstream" =3D >>> languages=3D3D2C not =3D3D >>>>> just C++.
>>>>>  =3D3D3B =3D3D3B C++ of course is extremely mainstream=3D3D2C= > but =3D >>> also a favori=3D3D >>>>> te target. (>> href=3D3D3D"http://www.relisoft.com/tools/CppCritic.html">http:/=3D3D >>>>> /www.relisoft.com/tools/CppCritic.html)
>>>>>  =3D3D3B
>>>>>  =3D3D3B
>>>>> We also have subranges of LONGINT.
>>>>> I'm not sure what the generalization of subranges are=3D3D2C =3D >>> granted.
>>>>>  =3D3D3BMaybe some sort of C++ template that takes constants in = >the =3D >>> templat=3D3D >>>>> e and does range checks at runtime. Yeah=3D3D2C maybe.
>>>>>  =3D3D3B
>>>>>  =3D3D3B
>>>>> And as you point out=3D3D2C convenient literal syntax.
>>>>>  =3D3D3B
>>>>>  =3D3D3B
>>>>> People reasonably argue for library extension in place of language = >=3D >>> extensio=3D3D >>>>> n=3D3D2C but that requires a language which is flexible enough to = >write =3D >>> librari=3D3D >>>>> es with the desired interface=3D3D2C and so many languages don't = >let =3D >>> infix oper=3D3D >>>>> ators be in a user-written library.
>>>>> (There is a subtle but useless distinction here -- infix operators = >=3D >>> being in=3D3D >>>>> libraries vs. "user-written" libraries. The infix set operations = >for =3D >>> examp=3D3D >>>>> le are in a library=3D3D2C but not user-written=3D3D2C special=3D3D2C= > the =3D >>> compiler know=3D3D >>>>> s about it.)
>>>>>  =3D3D3B
>>>>> >=3D3D3B that would perhaps not match how C handles "long long" = >on =3D >>> the same>>>> R>>=3D3D3B platform (which is how=3D3D2C come to think of = >it?)=3D3D2C and =3D >>> that would =3D3D >>>>> require

>>>>>  =3D3D3B
>>>>> On NT/x86=3D3D2C __int64/long long is returned in the register pair = >=3D >>> edx:eax.>>>>> =3D20 >>>>> edx is high=3D3D2C eax is low.
>>>>> When passed as a parameter to __stdcall or __cdecl is just passed = >as =3D >>> two 32=3D3D >>>>> bit values adjacent on the stack=3D3D2C "hi=3D3D2C lo=3D3D2C = >hi=3D3D2C lo=3D3D2C =3D >>> it's off to pu=3D3D >>>>> sh we go" is the Snow White-influenced mantra to remember how to = >pass =3D >>> them=3D3D >>>>> =3D3D2C at least on little endian stack-growing-down machines = >(which =3D >>> includes x=3D3D >>>>> 86). For __fastcall I'm not sure they are passed in registers or on = >=3D >>> the sta=3D3D >>>>> ck.
>>>>> Passing and/or returning small structs also has special efficient =3D= > >>> handling =3D3D >>>>> in the ABI=3D3D2C so __int64 really might be equivalent to a small = >=3D >>> record. Not =3D3D >>>>> that cm3 necessarily implements that "correctly" =3D3D3B -- for = >=3D >>> interop wit=3D3D >>>>> h C=3D3D3B for Modula-3 calling Modula-3 we can make up our own ABI = >so =3D >>> there is=3D3D >>>>> n't =3D3D3Breally an "incorrect" way. =3D3D3BNotice the = >mingw =3D >>> problem I had=3D3D >>>>> passing a Win32 point struct by value=3D3D2C I cheated and passed = >it by =3D >>> VAR to=3D3D >>>>> a =3D3D3BC wrapper to workaround the gcc backend bug (which was = >=3D >>> mentioned =3D3D >>>>> a few times and which I looked into the code for=3D3D2C but took = >the =3D >>> easy route=3D3D >>>>> )
>>>>>  =3D3D3B
>>>>>  =3D3D3B
>>>>> I don't know how long long works on other platforms but probably =3D >>> similar.>>>> R> >>>>> Probably a certain register pair for return values.
>>>>>  =3D3D3B
>>>>>  =3D3D3B- Jay

 =3D3D3B
>=3D3D3B To: =3D >>> hosking at cs.purdue.edu
>=3D3D3B=3D3D >>>>> Date: Sat=3D3D2C 17 Apr 2010 19:47:03 -0700
>=3D3D3B From: =3D >>> mika at async.async.c=3D3D >>>>> altech.edu
>=3D3D3B CC: m3devel at elegosoft.com
>=3D3D3B = >Subject: =3D >>> Re: [M3de=3D3D >>>>> vel] INTEGER
>=3D3D3B
>=3D3D3B Tony Hosking = >writes:
>=3D3D3B =3D >>> >=3D3D3B
=3D3D >>>>> >=3D3D3B ...
>=3D3D3B >=3D3D3B
>=3D3D3B = >>=3D3D3B>=3D3D3B We =3D >>> need it to match 64-b=3D3D >>>>> it integers on 32-bit machines? That seems =3D3D3D
>=3D3D3B =3D >>> >=3D3D3Blike
>=3D3D >>>>> =3D3D3B >=3D3D3B>=3D3D3B a very weak rationale indeed=3D3D2C if = >the same =3D >>> functionality =3D3D >>>>> could be =3D3D3D
>=3D3D3B >=3D3D3Bprovided
>=3D3D3B = >>=3D3D3B>=3D3D3=3D >>> B through some o=3D3D >>>>> ther mechanism (e.g.=3D3D2C ARRAY [0..1] OF INTEGER---even =3D >>> =3D3D3D
>=3D3D3B >=3D3D3B=3D3D >>>>> with
>=3D3D3B >=3D3D3B>=3D3D3B a pragma e.g. =3D >>> <=3D3D3B*CLONGLONG*>=3D3D3B.. if it i=3D3D >>>>> s necessary to tell the compiler =3D3D3D
>=3D3D3B =3D >>> >=3D3D3Bthat
>=3D3D3B >=3D3D3B&=3D3D >>>>> gt=3D3D3B a special linkage convention is needed).
>=3D3D3B =3D >>> >=3D3D3B
>=3D3D3B &=3D3D >>>>> gt=3D3D3BThere's no special linkage convention. Not sure what you = >mean =3D >>> here.>>>>> >=3D3D3B >=3D3D3B
>=3D3D3B
>=3D3D3B I just mean if = >we =3D >>> had
>=3D3D3B
>=3D3D >>>>> =3D3D3B TYPE LONGINT =3D3D3D ARRAY [0..1] OF INTEGER
>=3D3D3B = >=3D >>>
>=3D3D3B that woul=3D3D >>>>> d perhaps not match how C handles "long long" on the = >same
>=3D3D3B =3D >>> platfor=3D3D >>>>> m (which is how=3D3D2C come to think of it?)=3D3D2C and that would = >=3D >>> require
>=3D3D >>>>> =3D3D3B special linkage tricks.
>=3D3D3B
>=3D3D3B But = >what would =3D >>> be lost? Th=3D3D >>>>> e ability to type literals.
>=3D3D3B
>=3D3D3B You could = >get =3D >>> the same co=3D3D >>>>> de interface on 32- and 64-bit machine by
>=3D3D3B =3D >>> defining
>=3D3D3B
=3D3D >>>>> >=3D3D3B TYPE FileOffset =3D3D3D ARRAY[0..1] OF [-16_80000000 .. = >=3D >>> +16_7fffffff ]>>>> R>>=3D3D3B
>=3D3D3B and using that.
>=3D3D3B = >
>=3D3D3B =3D >>>
>=3D3D3B Mika>>>>> >>>>> =3D3D >>>>> =3D20 >>>>> --_264cb69b-0215-44c3-807c-8b4d8ea0ea59_-- From mika at async.async.caltech.edu Mon Apr 19 19:40:55 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Mon, 19 Apr 2010 10:40:55 -0700 Subject: [M3devel] INTEGER In-Reply-To: References: , , , , <7C7408D0-9A40-4988-BADA-A9FD8C15D388@cs.purdue.edu>, , , , , , , , , , , , <20100418023535.3BA9E1A2103@async.async.caltech.edu>, , , , <20100418024703.6965B1A2103@async.async.caltech.edu>, , <20100418074927.934461A2117@async.async.caltech.edu>, <04EB7FF8-D304-428D-839E-233FCE009C98@cs.purdue.edu>, <20100418195901.CDACB1A20F6@async.async.caltech.edu>, Message-ID: <20100419174055.D1A371A20EB@async.async.caltech.edu> Jay K writes: >--_54bd4884-6c8e-48b7-9b5f-c39a87170d04_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >Mika=2C the build process hasn't "really" changed. There was always an occa= ... > >I haven't tried 5.1/4.1/3.6 yet but maybe I will soon. I actually use curre= >nt configuration files when doing that though=2C so that probably inhibits = >3.6 (unless I use its configuration files). Sure, but as I mentioned to Tony, it is actually nice to be able to go "backwards" as well. ... >People really want their compiler to handle multiple precision arithmetic= >=2C at least to attain 64bit precision. > >It is nice and convenient=2C if not strictly necessary. > >=20 > >=20 > >Another view though=2C besides "interop" with C=2C is "keeping up" with C. > > Again that link suggests C has had long long for something like 18 years.= > We are late. > > Even C changed=2C C99 must be around 10 years old now? and has lnog long. > > Granted=2C I tend to think of C like you think of Modula-3 --- nice that = >it never changes. > C had all sorts of things long before Modula-3 was designed. Modula-3's designers *very specifically avoided* these things. To quote directly from the Green Book: "In the early days of the Ada project, a general in the Ada Program Office opined that 'obviously the Department of Defense is not interested in an artifically simplified language such as Pascal'. Modula-3 represents the opposite point of view. We used every artifice that we could find or invent to make the language simple." There is perhaps a place for "keeping up with C". It's not in Modula-3! It's more than "nice" that Modula-3 never changes. It's critical to what makes it special. The C/Java/whathaveyou crowd is constantly sinking in in the costs of maintaining their programs because everything needs to be rewritten every few years to "keep up", and---even worse---because bugs resulting from the changes are absolutely everywhere and no one is ever quite sure that anything works right. I don't have time for this kind of nonsense. I'll use F-77 if that's the only way to get out of that rat race, but hopefully there's a better way. > It is somewhat small=2C very well known. One only needs keep up with libr= >aries now :) and one can assume a certain baseline is everywhere and write = >portable code to it. (But I've happened upon K&R compiler *recently* -- HP-= >UX/hppa only bundles a compiler for purposes of changing kernel configurati= >on (constant data) and relinking kernel. The libraries that comprise the ke= >rnel are shipped. K&R suffices and is therefore bundled. Best is probably t= >o use that compiler to build old gcc=2C and then use old gcc to build curre= >nt gcc (current gcc can't be compiled with K&R)). > Yes, let's not forget that what made C popular was its *simplicity* (used to be that didn't have to be qualified with "somewhat"). Look at what they were competing with: PL/I! All the "features" you could shake a stick at, and where is it now? Mika From jay.krell at cornell.edu Mon Apr 19 19:44:32 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 19 Apr 2010 17:44:32 +0000 Subject: [M3devel] fw: deleting files In-Reply-To: <20100419173955.08CF82474003@birch.elegosoft.com> References: <20100419173955.08CF82474003@birch.elegosoft.com> Message-ID: Deleting files doesn't remove them from the package store. Arg. We should probably have a set of quake directives: delete_interface() delete_module() delete_implementation() delete_c_source() delete_h_source() I was tempted to empty out this stuff instead of deleting, anticipating that delete wouldn't work. I suspect attempting to import will still correctly fail, since I hope import uses the conside *.m3x files. - Jay > Date: Mon, 19 Apr 2010 19:39:54 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/04/19 19:39:54 > > Modified files: > cm3/m3-libs/libm3/src/os/Common/: m3makefile > cm3/m3-libs/libm3/src/os/POSIX/: m3makefile > cm3/m3-libs/libm3/src/os/WIN32/: m3makefile > Removed files: > cm3/m3-libs/libm3/src/os/Common/: Socket.i3 Socket.m3 > cm3/m3-libs/libm3/src/os/POSIX/: SocketPosix.m3 SocketPosixC.c > cm3/m3-libs/libm3/src/os/WIN32/: SocketWin32.m3 > SocketWin32.m3.sav > > Log message: > Nobody uses libm3's socket support. > So empty it out instead of fixing it. > Let's focus effort elsewhere, e.g. m3-comm/tcp. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Apr 19 20:05:15 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 19 Apr 2010 18:05:15 +0000 Subject: [M3devel] INTEGER In-Reply-To: <20100419172313.68B241A20D6@async.async.caltech.edu> References: , , ,,<7C7408D0-9A40-4988-BADA-A9FD8C15D388@cs.purdue.edu>, ,,, , , , , , , , , <20100418023535.3BA9E1A2103@async.async.caltech.edu>, , , , <20100418024703.6965B1A2103@async.async.caltech.edu>, , <20100418074927.934461A2117@async.async.caltech.edu>, <04EB7FF8-D304-428D-839E-233FCE009C98@cs.purdue.edu>, <20100418195901.CDACB1A20F6@async.async.caltech.edu>, , <20100419172313.68B241A20D6@async.async.caltech.edu> Message-ID: Mika, I must disagree on one point -- that people with large problems have 64bit machines. Large problem does not mean "large in memory" or large working set. It can mean "large on disk" and be combined with mostly sequential access to that disk. While 32bit is on the way out, we've had >2GB files for many years already, while 32bit was still very entrenched. You know -- disk costs vs. memory cost. It is memory beyond 4GB driving 64bit adoption, whereas disks went past 4GB long before at lower cost.. In your defense, I'll add "literals can be strings", something like: INTERFACE Int64; TYPE T = (* opaque! *) RECORD hi: INTEGER; low: Word.T; END; PROCEDURE Add(a,b:T):T; PROCEDURE Sub(a,b:T):T; PROCEDURE LT(a,b:T):BOOLEAN; PROCEDURE FromText(a:TEXT):T; <== PROCEDURE FromInt(a:INTEGER):T; PROCEDURE FromUInt64(a:UInt64.T):T RAISES{Overflow}; INTERFACE UInt64; TYPE T = (* opaque! *) RECORD hi, low: Word.T; END; PROCEDURE Add(a,b:T):T; PROCEDURE Sub(a,b:T):T; PROCEDURE LT(a,b:T):BOOLEAN; PROCEDURE FromText(a:TEXT):T; <== PROCEDURE FromInt(a:INTEGER):T; PROCEDURE FromInt64(a:Int64.T):T RAISES{Overflow}; thus reducing the need. Does Modula-3 offer opaque types whose size is known to the client? That is something I'd like, opacity without paying for heap allocation. (Notice these interfaces are circularly dependent, seems reasonable, but I believe not allowed?) ? I still say though, everyone prefers infix operators. "Things change". New needs are discovered. Better ways of doing things. Old restrictions fall away. Sometimes progress is made. Sometimes missteps are taken. I believe we even had some proposals that didn't change the language, e.g. big subranges or big packed types? TYPE INT64 = [-16_8000000000000000..16_7FFFFFFFFFFFFFFF] ? or TYPE INT64 = BITS 64 FOR[-16_8000000000000000..16_7FFFFFFFFFFFFFFF] ? but that's maybe not so simple? Well, I recently found that the compiler does chose sizes based on ranges: VAR a:[0..255] is only a byte, even without saying BITS 8 (at least when in a record). Do your language processing tools handle the notion that they are "cross compiling" to 64bit machines, where target integers don't fit in host integers? - Jay > To: hosking at cs.purdue.edu > Date: Mon, 19 Apr 2010 10:23:13 -0700 > From: mika at async.async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] INTEGER > > > Well *my* problem is that I still use PM3 for a lot of things. Trying to > switch to CM3, yes, but I can't "certify" CM3 for critical stuff yet. > > So I'm maintaining a significant amount of code that needs to compile > under both PM3 and CM3. Two problems crop up. > > 1. If there are bugs in m3tk/stubgen, the fixes only apply to one or > the other version of m3tk/stubgen. > > 2. Some of the code I'm maintaining processes Modula-3 code as input. > It needs to be in two versions. > > In this kind of environment, programming languages don't really > evolve, since the system depends on their being both forward- and > backward-compatible. They "change" is more correct. The way Java > changes. > > More in general, though, Modula-3's designers were clearly well acquainted > with C, Fortran, and other languages that provide different-range > integers. They chose not to indulge. I even have a version of Modula-3 > for a 16-bit machine that doesn't do it, even though on this machine the > need for a 32-bit integer is arguably greater than the need for 64-bit > integers on 32-bit machines. Now we indulge in this language complication > to solve what is clearly a temporary problem, since anyone who cares > about large problems is going to have 64-bit systems yesterday... and > meanwhile no one seems to have availed himself of the solution! > > My worst fear is that once the process gets started, the reason for > staying with the original Green-Book specification has now been defeated > and we will see more and more "evolution". Trying to actually build > systems that process Modula-3 like data becomes, at that point, like > trying to stand in quicksand. > > I'm not incredibly picky here... I just hope it doesn't go further. > I would personally support either sticking with the current status quo > or going back to the Green Book w.r.t. integers and characters. > > Saying that EWD wasn't renowned for his practicality is something he > would have taken as a great compliment, I'm sure. > > Mika > > Tony Hosking writes: > >Mika, > > > >First off, I'd be very interested to know what the issues are with = > >LONGINT and stubgen. We are building that every day in regression = > >testing. It would be really good to get some precise feedback. > > > >True, LONGINT is integrated with all of the language tools (same as = > >WIDECHAR). > > > >I suppose that is the price we pay for the language having evolved. = > >Nevertheless, CM3 should be totally backward compatible with the green = > >book. There is no reason it should not build packages from PM3 or SRC. > > > >Now, this is not to say that perhaps we haven't overreached with LONGINT = > >given that 64-bit is more prevalent. But then it is also useful to be = > >able to interoperate with C libraries. The previous interfacing was = > >pretty much a kludge, using ARRAY[0..1] OF INTEGER for "long long" but = > >then not propagating the double INTEGER value properly throughout the = > >Modula-3 libraries. > > > >I'm sorry to say that EWD was not particularly renowned for his = > >practicality; pedant more like. Nice to be high and mighty but we also = > >need to interact with the real world. > > > >We should be able to make this work. Is there a better alternative? = > >Revoke LONGINT, and WIDECHAR? > > > >On 18 Apr 2010, at 15:59, Mika Nystrom wrote: > > > >>=20 > >> My problem is really just that it's ugly. LONGx is showing up as an = > >issue > >> in all sorts of low-level code, which is not surprising since Modula-3 > >> with LONGx is not the same language as Modula-3 (maybe we should call > >> it Modula-3+?)=20 > >>=20 > >> The compiler bootstrapping process has gotten more complicated due to = > >it, > >> and when I cvs updated m3tk yesterday stubgen wouldn't compile because = > >there > >> was something "long" in it that wasn't there before. I have no idea = > >what > >> library or components I needed to update and recompile and didn't have = > >the > >> time to deal with the issue at the time. > >>=20 > >> And the new m3tk, stubgen, and compiler(?) won't compile using PM3 or > >> SRC M3 since we're no longer using the language of the Green Book. > >> (Same comment goes for WIDECHAR, by the way.) > >>=20 > >> One of the wonderful things about Modula-3 *used to be* that I could > >> grab some old package from DECSRC and just use it without changes = > >since > >> no one had messed with the language definition. This is still true as > >> far as programs that just use the tools go, but it's no longer true = > >for > >> programs that process Modula-3 code as input data. Of which there are > >> more than a few: many aspects of Modula-3 were specifically designed = > >to > >> make the language easy to process by program, as an intermediate = > >format > >> and whatnot. > >>=20 > >> To quote E.W.D.: > >>=20 > >> 'Unfathomed misunderstanding is further revealed by the term "software > >> maintenance", as a result of which many people continue to believe = > >that > >> programs and even programming languages themselves are subject to wear > >> and tear. Your car needs maintenance too, doesn't it? Famous is the = > >story > >> of the oil company that believed that its PASCAL programs did not last > >> as long as its FORTRAN programs "because PASCAL was not maintained".' > >>=20 > >> LONGx is causing me to have to do "software maintenance" on Modula-3 > >> programs... for a feature that no one appears to be using and is = > >quickly > >> becoming irrelevant. > >>=20 > >> Mika > >>=20 > >>=20 > >> Tony Hosking writes: > >>> In the language spec NUMBER(a) and LAST(a) - FIRST(a) + 1 are *not* =3D= > > > >>> defined to mean the same thing for all types. > >>> NUMBER does have an INTEGER value, as expected for subranges of = > >LONGINT =3D > >>> that are not too large. > >>> This is as it has always been for subranges of INTEGER that are not = > >too =3D > >>> large. > >>>=20 > >>> Mika, I'm not sure I see any of the problems you are worrying about = > >in =3D > >>> the current definition of LONGINT/LONGCARD. > >>>=20 > >>> On 18 Apr 2010, at 03:49, Mika Nystrom wrote: > >>>=20 > >>>> =3D20 > >>>> Jay I know most of this, and it doesn't really answer the question > >>>> "what is it for?" > >>>> =3D20 > >>>> I think we've already established that LONGINT isn't useful for =3D > >>> counting > >>>> anything that might actually reside in the computer's memory: it = > >makes > >>>> no sense as an array index, for instance. INTEGER suffices for = > >that. > >>>> =3D20 > >>>> I thought that the only real reason for LONGINT was to match C's > >>>> declaration of various seek-related routines on 32-bit machines. > >>>> That's not a very good reason. > >>>> =3D20 > >>>> C++ succeeds because it does very well in the area(s) it is good at. > >>>> People who want to program in C++ will clearly program in C++, not > >>>> Modula-3. Modula-3 is never, ever going to be the language of = > >choice =3D > >>> for > >>>> people who want lots of snazzy infix operators. Modula-3 is = > >supposed =3D > >>> to > >>>> be a language with about as powerful semantics as C++ and an = > >extremely > >>>> simple syntax and definition---snazzy infix is one of the things you > >>>> give up for that. I don't see how LONGINT fits into this picture. > >>>> Now we have LONGCARD too? And it's infected the definitions > >>>> of FIRST and LAST? But not NUMBER... argh! > >>>> =3D20 > >>>> so, > >>>> =3D20 > >>>> NUMBER(a) and LAST(a) - FIRST(a) + 1 > >>>> =3D20 > >>>> no longer mean the same thing? Are we going to see lots of comments > >>>> in generics in the future where it says T may not be an open array > >>>> type nor an array type indexed on LONGINT or a subrange thereof? > >>>> =3D20 > >>>> Your comments about different parameter-passing techniques was what = > >I =3D > >>> was > >>>> trying to address with my suggestion to have a pragma for = > >this---just =3D > >>> to > >>>> match C (and Fortran?), of course. Name me a single Modula-3 =3D > >>> programmer > >>>> who cares in what order the bits in his parameters are pushed on the > >>>> stack in a Modula-3-to-Modula-3 call. > >>>> =3D20 > >>>> And I am definitely in that school of thought that says that =3D > >>> programming > >>>> languages should not "evolve". Better to leave well enough alone. > >>>> =3D20 > >>>> How much Modula-3 code has been written that uses LONGINT? Other = > >than > >>>> to talk to C? I've certainly never used it. > >>>> =3D20 > >>>> Mika > >>>> =3D20 > >>>> =3D20 > >>>> =3D20 > >>>> Jay K writes: > >>>>> --_264cb69b-0215-44c3-807c-8b4d8ea0ea59_ > >>>>> Content-Type: text/plain; charset=3D3D"iso-8859-1" > >>>>> Content-Transfer-Encoding: quoted-printable > >>>>> =3D20 > >>>>> =3D20 > >>>>> TYPE LONGINT =3D3D3D ARRAY [0..1] OF INTEGER on a 32bit system is = > >very =3D > >>> close to=3D3D > >>>>> LONGINT. > >>>>> =3D20 > >>>>> Plus treating it opaquely and providing a bunch of functions to =3D > >>> operate on=3D3D > >>>>> it. > >>>>> =3D20 > >>>>> Just as well therefore could be RECORD hi=3D3D2Clo:LONGINT END (see = > >=3D > >>> LARGE_INTE=3D3D > >>>>> GER and ULARGE_INTEGER in winnt.h) > >>>>> =3D20 > >>>>> =3D3D20 > >>>>> =3D20 > >>>>> Differences that come to mind: > >>>>> =3D20 > >>>>> infix operators <=3D3D3D=3D3D3D=3D3D3D=3D3D20 > >>>>> =3D20 > >>>>> possibly passed differently as a parameter > >>>>> =3D20 > >>>>> or returned differently as a result > >>>>> =3D20 > >>>>> ie. probably "directly compatible with" "long long"=3D3D2C passed = > >by =3D > >>> value (o=3D3D > >>>>> f course you could always pass by pointer and achieve = > >compatibilitity =3D > >>> trivi=3D3D > >>>>> ally) > >>>>> =3D20 > >>>>> =3D3D20 > >>>>> =3D20 > >>>>> =3D3D20 > >>>>> =3D20 > >>>>> I have to say though=3D3D2C the biggest reason is in-fix operators. = > >=3D > >>> Convenient =3D3D > >>>>> syntax. > >>>>> =3D20 > >>>>> C++ is the best and some way worst of example of the general right = > >=3D > >>> way to d=3D3D > >>>>> o this -- you let programmers define types and their infix = > >operators. =3D > >>> Other=3D3D > >>>>> languages just come with a passle of special cases of types that = > >have =3D > >>> in-f=3D3D > >>>>> ix operators. > >>>>> =3D20 > >>>>> A good example is that Java infix operator + on string=3D3D2C = > >besides =3D > >>> the vario=3D3D > >>>>> us integers=3D3D2C and nothing else. > >>>>> =3D20 > >>>>> =3D3D20 > >>>>> =3D20 > >>>>> =3D3D20 > >>>>> =3D20 > >>>>> I think C# lets you define operators=3D3D2C yet people don't = > >complain =3D > >>> that it i=3D3D > >>>>> s "a mess" as they do of C++. > >>>>> =3D20 > >>>>> I think Python does now too. > >>>>> =3D20 > >>>>> So it is feature growing in popularity among "mainstream" =3D > >>> languages=3D3D2C not =3D3D > >>>>> just C++. > >>>>> =3D20 > >>>>> C++ of course is extremely mainstream=3D3D2C but also a favorite =3D > >>> target. (ht=3D3D > >>>>> tp://www.relisoft.com/tools/CppCritic.html) > >>>>> =3D20 > >>>>> =3D3D20 > >>>>> =3D20 > >>>>> =3D3D20 > >>>>> =3D20 > >>>>> We also have subranges of LONGINT. > >>>>> =3D20 > >>>>> I'm not sure what the generalization of subranges are=3D3D2C = > >granted. > >>>>> =3D20 > >>>>> Maybe some sort of C++ template that takes constants in the = > >template =3D > >>> and d=3D3D > >>>>> oes range checks at runtime. Yeah=3D3D2C maybe. > >>>>> =3D20 > >>>>> =3D3D20 > >>>>> =3D20 > >>>>> =3D3D20 > >>>>> =3D20 > >>>>> And as you point out=3D3D2C convenient literal syntax. > >>>>> =3D20 > >>>>> =3D3D20 > >>>>> =3D20 > >>>>> =3D3D20 > >>>>> =3D20 > >>>>> People reasonably argue for library extension in place of language = > >=3D > >>> extensio=3D3D > >>>>> n=3D3D2C but that requires a language which is flexible enough to = > >write =3D > >>> librari=3D3D > >>>>> es with the desired interface=3D3D2C and so many languages don't = > >let =3D > >>> infix oper=3D3D > >>>>> ators be in a user-written library. > >>>>> =3D20 > >>>>> (There is a subtle but useless distinction here -- infix operators = > >=3D > >>> being in=3D3D > >>>>> libraries vs. "user-written" libraries. The infix set operations = > >for =3D > >>> examp=3D3D > >>>>> le are in a library=3D3D2C but not user-written=3D3D2C special=3D3D2C= > > the =3D > >>> compiler know=3D3D > >>>>> s about it.) > >>>>> =3D20 > >>>>> =3D3D20 > >>>>> =3D20 > >>>>>> that would perhaps not match how C handles "long long" on the same > >>>>>> platform (which is how=3D3D2C come to think of it?)=3D3D2C and = > >that =3D > >>> would require > >>>>> =3D20 > >>>>> =3D20 > >>>>> =3D3D20 > >>>>> =3D20 > >>>>> On NT/x86=3D3D2C __int64/long long is returned in the register pair = > >=3D > >>> edx:eax. > >>>>> =3D20 > >>>>> edx is high=3D3D2C eax is low. > >>>>> =3D20 > >>>>> When passed as a parameter to __stdcall or __cdecl is just passed = > >as =3D > >>> two 32=3D3D > >>>>> bit values adjacent on the stack=3D3D2C "hi=3D3D2C lo=3D3D2C = > >hi=3D3D2C lo=3D3D2C =3D > >>> it's off to pu=3D3D > >>>> sh we go" is the Snow White-influenced mantra to remember how to = > >pass =3D > >>> them=3D3D > >>>>> =3D3D2C at least on little endian stack-growing-down machines = > >(which =3D > >>> includes x=3D3D > >>>>> 86). For __fastcall I'm not sure they are passed in registers or on = > >=3D > >>> the sta=3D3D > >>>>> ck. > >>>>> =3D20 > >>>>> Passing and/or returning small structs also has special efficient =3D= > > > >>> handling =3D3D > >>>>> in the ABI=3D3D2C so __int64 really might be equivalent to a small = > >=3D > >>> record. Not =3D3D > >>>>> that cm3 necessarily implements that "correctly" -- for interop = > >with =3D > >>> C=3D3D3B =3D3D > >>>>> for Modula-3 calling Modula-3 we can make up our own ABI so there =3D= > > > >>> isn't rea=3D3D > >>>>> lly an "incorrect" way. Notice the mingw problem I had passing a =3D > >>> Win32 poin=3D3D > >>>>> t struct by value=3D3D2C I cheated and passed it by VAR to a C = > >wrapper =3D > >>> to worka=3D3D > >>>>> round the gcc backend bug (which was mentioned a few times and = > >which =3D > >>> I look=3D3D > >>>>> ed into the code for=3D3D2C but took the easy route) > >>>>> =3D20 > >>>>> =3D3D20 > >>>>> =3D20 > >>>>> =3D3D20 > >>>>> =3D20 > >>>>> I don't know how long long works on other platforms but probably =3D > >>> similar. > >>>>> =3D20 > >>>>> Probably a certain register pair for return values. > >>>>> =3D20 > >>>>> =3D3D20 > >>>>> =3D20 > >>>>> - Jay > >>>>> =3D20 > >>>>> =3D3D20 > >>>>>> To: hosking at cs.purdue.edu > >>>>>> Date: Sat=3D3D2C 17 Apr 2010 19:47:03 -0700 > >>>>>> From: mika at async.async.caltech.edu > >>>>>> CC: m3devel at elegosoft.com > >>>>>> Subject: Re: [M3devel] INTEGER > >>>>>> =3D3D20 > >>>>>> Tony Hosking writes: > >>>>>>> =3D20 > >>>>>> ... > >>>>>>> =3D20 > >>>>>>>> We need it to match 64-bit integers on 32-bit machines? That = > >seems =3D > >>> =3D3D3D > >>>>>>> like > >>>>>>>> a very weak rationale indeed=3D3D2C if the same functionality = > >could =3D > >>> be =3D3D3D > >>>>>>> provided > >>>>>>>> through some other mechanism (e.g.=3D3D2C ARRAY [0..1] OF =3D > >>> INTEGER---even =3D3D > >>>>> =3D3D3D > >>>>>>> with > >>>>>>>> a pragma e.g. <*CLONGLONG*>.. if it is necessary to tell the =3D > >>> compiler =3D3D > >>>>> =3D3D3D > >>>>>>> that > >>>>>>>> a special linkage convention is needed). > >>>>>>> =3D20 > >>>>>>> There's no special linkage convention. Not sure what you mean = > >here. > >>>>>>> =3D20 > >>>>>> =3D3D20 > >>>>>> I just mean if we had > >>>>>> =3D3D20 > >>>>>> TYPE LONGINT =3D3D3D ARRAY [0..1] OF INTEGER > >>>>>> =3D3D20 > >>>>>> that would perhaps not match how C handles "long long" on the same > >>>>>> platform (which is how=3D3D2C come to think of it?)=3D3D2C and = > >that =3D > >>> would require > >>>>>> special linkage tricks. > >>>>>> =3D3D20 > >>>>>> But what would be lost? The ability to type literals.=3D3D20 > >>>>>> =3D3D20 > >>>>>> You could get the same code interface on 32- and 64-bit machine by > >>>>>> defining > >>>>>> =3D3D20 > >>>>>> TYPE FileOffset =3D3D3D ARRAY[0..1] OF [-16_80000000 .. = > >+16_7fffffff ] > >>>>>> =3D3D20 > >>>>>> and using that. > >>>>>> =3D3D20 > >>>>>> =3D3D20 > >>>>>> Mika > >>>>> =3D3D > >>>>> =3D20 > >>>>> --_264cb69b-0215-44c3-807c-8b4d8ea0ea59_ > >>>>> Content-Type: text/html; charset=3D3D"iso-8859-1" > >>>>> Content-Transfer-Encoding: quoted-printable > >>>>> =3D20 > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> TYPE LONGINT =3D3D3D ARRAY [0..1] OF INTEGER on a =3D3D3B32bit = > >system =3D > >>> is very c=3D3D > >>>>> lose to LONGINT.
> >>>>>  =3D3D3BPlus treating it opaquely and providing a bunch of =3D > >>> functions to ope=3D3D > >>>>> rate on it.
> >>>>>  =3D3D3BJust as well therefore could be RECORD = > >hi=3D3D2Clo:LONGINT =3D > >>> END (see LAR=3D3D > >>>>> GE_INTEGER and ULARGE_INTEGER in winnt.h)
> >>>>>  =3D3D3B
> >>>>> Differences that come to mind:
> >>>>>  =3D3D3B =3D3D3Binfix operators =3D3D3B = > ><=3D3D3B=3D3D3D=3D3D3D=3D3D3D =3D > >>>
> >>>>>  =3D3D3B possibly passed differently =3D3D3Bas a = > >parameter
> >>>>>  =3D3D3B or returned differently as a result
> >>>>>  =3D3D3B ie. probably "directly compatible with" "long = > >long"=3D3D2C =3D > >>> passed by v=3D3D > >>>>> alue (of course you could always pass by pointer and achieve =3D > >>> compatibilitit=3D3D > >>>>> y trivially)
> >>>>>  =3D3D3B
> >>>>>  =3D3D3B
> >>>>> I have to say though=3D3D2C the biggest reason is in-fix operators. = > >=3D > >>> Convenient =3D3D > >>>>> syntax.
> >>>>> C++ is the best and some way worst of example of the general right = > >=3D > >>> way to d=3D3D > >>>>> o this -- you let programmers define types and their infix = > >operators. =3D > >>> Other=3D3D > >>>>> languages just come with a passle of special cases of types that = > >have =3D > >>> in-f=3D3D > >>>>> ix operators.
> >>>>> A good example is that Java infix operator + on string=3D3D2C = > >besides =3D > >>> the vario=3D3D > >>>>> us integers=3D3D2C and nothing else.
> >>>>>  =3D3D3B
> >>>>>  =3D3D3B
> >>>>> I think C# lets you define operators=3D3D2C yet people don't = > >complain =3D > >>> that it i=3D3D > >>>>> s "a mess" as they do of C++.
> >>>>> I think Python does now too.
> >>>>> So it is feature growing in popularity among "mainstream" =3D > >>> languages=3D3D2C not =3D3D > >>>>> just C++.
> >>>>>  =3D3D3B =3D3D3B C++ of course is extremely mainstream=3D3D2C= > > but =3D > >>> also a favori=3D3D > >>>>> te target. ( >>> href=3D3D3D"http://www.relisoft.com/tools/CppCritic.html">http:/=3D3D > >>>>> /www.relisoft.com/tools/CppCritic.html)
> >>>>>  =3D3D3B
> >>>>>  =3D3D3B
> >>>>> We also have subranges of LONGINT.
> >>>>> I'm not sure what the generalization of subranges are=3D3D2C =3D > >>> granted.
> >>>>>  =3D3D3BMaybe some sort of C++ template that takes constants in = > >the =3D > >>> templat=3D3D > >>>>> e and does range checks at runtime. Yeah=3D3D2C maybe.
> >>>>>  =3D3D3B
> >>>>>  =3D3D3B
> >>>>> And as you point out=3D3D2C convenient literal syntax.
> >>>>>  =3D3D3B
> >>>>>  =3D3D3B
> >>>>> People reasonably argue for library extension in place of language = > >=3D > >>> extensio=3D3D > >>>>> n=3D3D2C but that requires a language which is flexible enough to = > >write =3D > >>> librari=3D3D > >>>>> es with the desired interface=3D3D2C and so many languages don't = > >let =3D > >>> infix oper=3D3D > >>>>> ators be in a user-written library.
> >>>>> (There is a subtle but useless distinction here -- infix operators = > >=3D > >>> being in=3D3D > >>>>> libraries vs. "user-written" libraries. The infix set operations = > >for =3D > >>> examp=3D3D > >>>>> le are in a library=3D3D2C but not user-written=3D3D2C special=3D3D2C= > > the =3D > >>> compiler know=3D3D > >>>>> s about it.)
> >>>>>  =3D3D3B
> >>>>> >=3D3D3B that would perhaps not match how C handles "long long" = > >on =3D > >>> the same >>>>> R>>=3D3D3B platform (which is how=3D3D2C come to think of = > >it?)=3D3D2C and =3D > >>> that would =3D3D > >>>>> require

> >>>>>  =3D3D3B
> >>>>> On NT/x86=3D3D2C __int64/long long is returned in the register pair = > >=3D > >>> edx:eax. >>>>>> =3D20 > >>>>> edx is high=3D3D2C eax is low.
> >>>>> When passed as a parameter to __stdcall or __cdecl is just passed = > >as =3D > >>> two 32=3D3D > >>>>> bit values adjacent on the stack=3D3D2C "hi=3D3D2C lo=3D3D2C = > >hi=3D3D2C lo=3D3D2C =3D > >>> it's off to pu=3D3D > >>>>> sh we go" is the Snow White-influenced mantra to remember how to = > >pass =3D > >>> them=3D3D > >>>>> =3D3D2C at least on little endian stack-growing-down machines = > >(which =3D > >>> includes x=3D3D > >>>>> 86). For __fastcall I'm not sure they are passed in registers or on = > >=3D > >>> the sta=3D3D > >>>>> ck.
> >>>>> Passing and/or returning small structs also has special efficient =3D= > > > >>> handling =3D3D > >>>>> in the ABI=3D3D2C so __int64 really might be equivalent to a small = > >=3D > >>> record. Not =3D3D > >>>>> that cm3 necessarily implements that "correctly" =3D3D3B -- for = > >=3D > >>> interop wit=3D3D > >>>>> h C=3D3D3B for Modula-3 calling Modula-3 we can make up our own ABI = > >so =3D > >>> there is=3D3D > >>>>> n't =3D3D3Breally an "incorrect" way. =3D3D3BNotice the = > >mingw =3D > >>> problem I had=3D3D > >>>>> passing a Win32 point struct by value=3D3D2C I cheated and passed = > >it by =3D > >>> VAR to=3D3D > >>>>> a =3D3D3BC wrapper to workaround the gcc backend bug (which was = > >=3D > >>> mentioned =3D3D > >>>>> a few times and which I looked into the code for=3D3D2C but took = > >the =3D > >>> easy route=3D3D > >>>>> )
> >>>>>  =3D3D3B
> >>>>>  =3D3D3B
> >>>>> I don't know how long long works on other platforms but probably =3D > >>> similar. >>>>> R> > >>>>> Probably a certain register pair for return values.
> >>>>>  =3D3D3B
> >>>>>  =3D3D3B- Jay

 =3D3D3B
>=3D3D3B To: =3D > >>> hosking at cs.purdue.edu
>=3D3D3B=3D3D > >>>>> Date: Sat=3D3D2C 17 Apr 2010 19:47:03 -0700
>=3D3D3B From: =3D > >>> mika at async.async.c=3D3D > >>>>> altech.edu
>=3D3D3B CC: m3devel at elegosoft.com
>=3D3D3B = > >Subject: =3D > >>> Re: [M3de=3D3D > >>>>> vel] INTEGER
>=3D3D3B
>=3D3D3B Tony Hosking = > >writes:
>=3D3D3B =3D > >>> >=3D3D3B
=3D3D > >>>>> >=3D3D3B ...
>=3D3D3B >=3D3D3B
>=3D3D3B = > >>=3D3D3B>=3D3D3B We =3D > >>> need it to match 64-b=3D3D > >>>>> it integers on 32-bit machines? That seems =3D3D3D
>=3D3D3B =3D > >>> >=3D3D3Blike
>=3D3D > >>>>> =3D3D3B >=3D3D3B>=3D3D3B a very weak rationale indeed=3D3D2C if = > >the same =3D > >>> functionality =3D3D > >>>>> could be =3D3D3D
>=3D3D3B >=3D3D3Bprovided
>=3D3D3B = > >>=3D3D3B>=3D3D3=3D > >>> B through some o=3D3D > >>>>> ther mechanism (e.g.=3D3D2C ARRAY [0..1] OF INTEGER---even =3D > >>> =3D3D3D
>=3D3D3B >=3D3D3B=3D3D > >>>>> with
>=3D3D3B >=3D3D3B>=3D3D3B a pragma e.g. =3D > >>> <=3D3D3B*CLONGLONG*>=3D3D3B.. if it i=3D3D > >>>>> s necessary to tell the compiler =3D3D3D
>=3D3D3B =3D > >>> >=3D3D3Bthat
>=3D3D3B >=3D3D3B&=3D3D > >>>>> gt=3D3D3B a special linkage convention is needed).
>=3D3D3B =3D > >>> >=3D3D3B
>=3D3D3B &=3D3D > >>>>> gt=3D3D3BThere's no special linkage convention. Not sure what you = > >mean =3D > >>> here. >>>>>> >=3D3D3B >=3D3D3B
>=3D3D3B
>=3D3D3B I just mean if = > >we =3D > >>> had
>=3D3D3B
>=3D3D > >>>>> =3D3D3B TYPE LONGINT =3D3D3D ARRAY [0..1] OF INTEGER
>=3D3D3B = > >=3D > >>>
>=3D3D3B that woul=3D3D > >>>>> d perhaps not match how C handles "long long" on the = > >same
>=3D3D3B =3D > >>> platfor=3D3D > >>>>> m (which is how=3D3D2C come to think of it?)=3D3D2C and that would = > >=3D > >>> require
>=3D3D > >>>>> =3D3D3B special linkage tricks.
>=3D3D3B
>=3D3D3B But = > >what would =3D > >>> be lost? Th=3D3D > >>>>> e ability to type literals.
>=3D3D3B
>=3D3D3B You could = > >get =3D > >>> the same co=3D3D > >>>>> de interface on 32- and 64-bit machine by
>=3D3D3B =3D > >>> defining
>=3D3D3B
=3D3D > >>>>> >=3D3D3B TYPE FileOffset =3D3D3D ARRAY[0..1] OF [-16_80000000 .. = > >=3D > >>> +16_7fffffff ] >>>>> R>>=3D3D3B
>=3D3D3B and using that.
>=3D3D3B = > >
>=3D3D3B =3D > >>>
>=3D3D3B Mika >>>>>> > >>>>> =3D3D > >>>>> =3D20 > >>>>> --_264cb69b-0215-44c3-807c-8b4d8ea0ea59_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Apr 19 20:44:00 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 19 Apr 2010 14:44:00 -0400 Subject: [M3devel] INTEGER In-Reply-To: <20100419172313.68B241A20D6@async.async.caltech.edu> References: , , , <7C7408D0-9A40-4988-BADA-A9FD8C15D388@cs.purdue.edu>, , , , , , , <20100418023535.3BA9E1A2103@async.async.caltech.edu>, , <20100418024703.6965B1A2103@async.async.caltech.edu> <20100418074927.934461A2117@async.async.caltech.edu> <04EB7FF8-D304-428D-839E-233FCE009C98@cs.purdue.edu> <20100418195901.CDACB1A20F6@async.async.caltech.edu> <20100419172313.68B241A20D6@async.async.caltech.edu> Message-ID: <4F3EE437-0298-410B-9642-C0381E333430@cs.purdue.edu> On 19 Apr 2010, at 13:23, Mika Nystrom wrote: > > Well *my* problem is that I still use PM3 for a lot of things. Trying to > switch to CM3, yes, but I can't "certify" CM3 for critical stuff yet. > > So I'm maintaining a significant amount of code that needs to compile > under both PM3 and CM3. Two problems crop up. > > 1. If there are bugs in m3tk/stubgen, the fixes only apply to one or > the other version of m3tk/stubgen. > > 2. Some of the code I'm maintaining processes Modula-3 code as input. > It needs to be in two versions. > > In this kind of environment, programming languages don't really > evolve, since the system depends on their being both forward- and > backward-compatible. They "change" is more correct. The way Java > changes. Indeed: Growing a Language, by Guy Steele > > More in general, though, Modula-3's designers were clearly well acquainted > with C, Fortran, and other languages that provide different-range > integers. They chose not to indulge. I even have a version of Modula-3 > for a 16-bit machine that doesn't do it, even though on this machine the > need for a 32-bit integer is arguably greater than the need for 64-bit > integers on 32-bit machines. Now we indulge in this language complication > to solve what is clearly a temporary problem, since anyone who cares > about large problems is going to have 64-bit systems yesterday... and > meanwhile no one seems to have availed himself of the solution! If we were to revert, I have no idea what the implications would be. Jay? > My worst fear is that once the process gets started, the reason for > staying with the original Green-Book specification has now been defeated > and we will see more and more "evolution". Trying to actually build > systems that process Modula-3 like data becomes, at that point, like > trying to stand in quicksand. Indeed! > > I'm not incredibly picky here... I just hope it doesn't go further. > I would personally support either sticking with the current status quo > or going back to the Green Book w.r.t. integers and characters. Indeed, I would not want to see this go any further. I am still not sure I am comfortable with the LONGINT extension (even though I put a lot of time into it). There just seemed to be a lot of pressure for it to so CM3 could handle large file indexes. I've never been convinced that WIDECHAR was a winner either -- it was a reflexive action in the face of Java's Unicode. The CM3 people were building a Java VM above CM3 at the time. > > Saying that EWD wasn't renowned for his practicality is something he > would have taken as a great compliment, I'm sure. ;-) > > Mika > > Tony Hosking writes: >> Mika, >> >> First off, I'd be very interested to know what the issues are with = >> LONGINT and stubgen. We are building that every day in regression = >> testing. It would be really good to get some precise feedback. >> >> True, LONGINT is integrated with all of the language tools (same as = >> WIDECHAR). >> >> I suppose that is the price we pay for the language having evolved. = >> Nevertheless, CM3 should be totally backward compatible with the green = >> book. There is no reason it should not build packages from PM3 or SRC. >> >> Now, this is not to say that perhaps we haven't overreached with LONGINT = >> given that 64-bit is more prevalent. But then it is also useful to be = >> able to interoperate with C libraries. The previous interfacing was = >> pretty much a kludge, using ARRAY[0..1] OF INTEGER for "long long" but = >> then not propagating the double INTEGER value properly throughout the = >> Modula-3 libraries. >> >> I'm sorry to say that EWD was not particularly renowned for his = >> practicality; pedant more like. Nice to be high and mighty but we also = >> need to interact with the real world. >> >> We should be able to make this work. Is there a better alternative? = >> Revoke LONGINT, and WIDECHAR? >> >> On 18 Apr 2010, at 15:59, Mika Nystrom wrote: >> >>> =20 >>> My problem is really just that it's ugly. LONGx is showing up as an = >> issue >>> in all sorts of low-level code, which is not surprising since Modula-3 >>> with LONGx is not the same language as Modula-3 (maybe we should call >>> it Modula-3+?)=20 >>> =20 >>> The compiler bootstrapping process has gotten more complicated due to = >> it, >>> and when I cvs updated m3tk yesterday stubgen wouldn't compile because = >> there >>> was something "long" in it that wasn't there before. I have no idea = >> what >>> library or components I needed to update and recompile and didn't have = >> the >>> time to deal with the issue at the time. >>> =20 >>> And the new m3tk, stubgen, and compiler(?) won't compile using PM3 or >>> SRC M3 since we're no longer using the language of the Green Book. >>> (Same comment goes for WIDECHAR, by the way.) >>> =20 >>> One of the wonderful things about Modula-3 *used to be* that I could >>> grab some old package from DECSRC and just use it without changes = >> since >>> no one had messed with the language definition. This is still true as >>> far as programs that just use the tools go, but it's no longer true = >> for >>> programs that process Modula-3 code as input data. Of which there are >>> more than a few: many aspects of Modula-3 were specifically designed = >> to >>> make the language easy to process by program, as an intermediate = >> format >>> and whatnot. >>> =20 >>> To quote E.W.D.: >>> =20 >>> 'Unfathomed misunderstanding is further revealed by the term "software >>> maintenance", as a result of which many people continue to believe = >> that >>> programs and even programming languages themselves are subject to wear >>> and tear. Your car needs maintenance too, doesn't it? Famous is the = >> story >>> of the oil company that believed that its PASCAL programs did not last >>> as long as its FORTRAN programs "because PASCAL was not maintained".' >>> =20 >>> LONGx is causing me to have to do "software maintenance" on Modula-3 >>> programs... for a feature that no one appears to be using and is = >> quickly >>> becoming irrelevant. >>> =20 >>> Mika >>> =20 >>> =20 >>> Tony Hosking writes: >>>> In the language spec NUMBER(a) and LAST(a) - FIRST(a) + 1 are *not* =3D= >> >>>> defined to mean the same thing for all types. >>>> NUMBER does have an INTEGER value, as expected for subranges of = >> LONGINT =3D >>>> that are not too large. >>>> This is as it has always been for subranges of INTEGER that are not = >> too =3D >>>> large. >>>> =20 >>>> Mika, I'm not sure I see any of the problems you are worrying about = >> in =3D >>>> the current definition of LONGINT/LONGCARD. >>>> =20 >>>> On 18 Apr 2010, at 03:49, Mika Nystrom wrote: >>>> =20 >>>>> =3D20 >>>>> Jay I know most of this, and it doesn't really answer the question >>>>> "what is it for?" >>>>> =3D20 >>>>> I think we've already established that LONGINT isn't useful for =3D >>>> counting >>>>> anything that might actually reside in the computer's memory: it = >> makes >>>>> no sense as an array index, for instance. INTEGER suffices for = >> that. >>>>> =3D20 >>>>> I thought that the only real reason for LONGINT was to match C's >>>>> declaration of various seek-related routines on 32-bit machines. >>>>> That's not a very good reason. >>>>> =3D20 >>>>> C++ succeeds because it does very well in the area(s) it is good at. >>>>> People who want to program in C++ will clearly program in C++, not >>>>> Modula-3. Modula-3 is never, ever going to be the language of = >> choice =3D >>>> for >>>>> people who want lots of snazzy infix operators. Modula-3 is = >> supposed =3D >>>> to >>>>> be a language with about as powerful semantics as C++ and an = >> extremely >>>>> simple syntax and definition---snazzy infix is one of the things you >>>>> give up for that. I don't see how LONGINT fits into this picture. >>>>> Now we have LONGCARD too? And it's infected the definitions >>>>> of FIRST and LAST? But not NUMBER... argh! >>>>> =3D20 >>>>> so, >>>>> =3D20 >>>>> NUMBER(a) and LAST(a) - FIRST(a) + 1 >>>>> =3D20 >>>>> no longer mean the same thing? Are we going to see lots of comments >>>>> in generics in the future where it says T may not be an open array >>>>> type nor an array type indexed on LONGINT or a subrange thereof? >>>>> =3D20 >>>>> Your comments about different parameter-passing techniques was what = >> I =3D >>>> was >>>>> trying to address with my suggestion to have a pragma for = >> this---just =3D >>>> to >>>>> match C (and Fortran?), of course. Name me a single Modula-3 =3D >>>> programmer >>>>> who cares in what order the bits in his parameters are pushed on the >>>>> stack in a Modula-3-to-Modula-3 call. >>>>> =3D20 >>>>> And I am definitely in that school of thought that says that =3D >>>> programming >>>>> languages should not "evolve". Better to leave well enough alone. >>>>> =3D20 >>>>> How much Modula-3 code has been written that uses LONGINT? Other = >> than >>>>> to talk to C? I've certainly never used it. >>>>> =3D20 >>>>> Mika >>>>> =3D20 >>>>> =3D20 >>>>> =3D20 >>>>> Jay K writes: >>>>>> --_264cb69b-0215-44c3-807c-8b4d8ea0ea59_ >>>>>> Content-Type: text/plain; charset=3D3D"iso-8859-1" >>>>>> Content-Transfer-Encoding: quoted-printable >>>>>> =3D20 >>>>>> =3D20 >>>>>> TYPE LONGINT =3D3D3D ARRAY [0..1] OF INTEGER on a 32bit system is = >> very =3D >>>> close to=3D3D >>>>>> LONGINT. >>>>>> =3D20 >>>>>> Plus treating it opaquely and providing a bunch of functions to =3D >>>> operate on=3D3D >>>>>> it. >>>>>> =3D20 >>>>>> Just as well therefore could be RECORD hi=3D3D2Clo:LONGINT END (see = >> =3D >>>> LARGE_INTE=3D3D >>>>>> GER and ULARGE_INTEGER in winnt.h) >>>>>> =3D20 >>>>>> =3D3D20 >>>>>> =3D20 >>>>>> Differences that come to mind: >>>>>> =3D20 >>>>>> infix operators <=3D3D3D=3D3D3D=3D3D3D=3D3D20 >>>>>> =3D20 >>>>>> possibly passed differently as a parameter >>>>>> =3D20 >>>>>> or returned differently as a result >>>>>> =3D20 >>>>>> ie. probably "directly compatible with" "long long"=3D3D2C passed = >> by =3D >>>> value (o=3D3D >>>>>> f course you could always pass by pointer and achieve = >> compatibilitity =3D >>>> trivi=3D3D >>>>>> ally) >>>>>> =3D20 >>>>>> =3D3D20 >>>>>> =3D20 >>>>>> =3D3D20 >>>>>> =3D20 >>>>>> I have to say though=3D3D2C the biggest reason is in-fix operators. = >> =3D >>>> Convenient =3D3D >>>>>> syntax. >>>>>> =3D20 >>>>>> C++ is the best and some way worst of example of the general right = >> =3D >>>> way to d=3D3D >>>>>> o this -- you let programmers define types and their infix = >> operators. =3D >>>> Other=3D3D >>>>>> languages just come with a passle of special cases of types that = >> have =3D >>>> in-f=3D3D >>>>>> ix operators. >>>>>> =3D20 >>>>>> A good example is that Java infix operator + on string=3D3D2C = >> besides =3D >>>> the vario=3D3D >>>>>> us integers=3D3D2C and nothing else. >>>>>> =3D20 >>>>>> =3D3D20 >>>>>> =3D20 >>>>>> =3D3D20 >>>>>> =3D20 >>>>>> I think C# lets you define operators=3D3D2C yet people don't = >> complain =3D >>>> that it i=3D3D >>>>>> s "a mess" as they do of C++. >>>>>> =3D20 >>>>>> I think Python does now too. >>>>>> =3D20 >>>>>> So it is feature growing in popularity among "mainstream" =3D >>>> languages=3D3D2C not =3D3D >>>>>> just C++. >>>>>> =3D20 >>>>>> C++ of course is extremely mainstream=3D3D2C but also a favorite =3D >>>> target. (ht=3D3D >>>>>> tp://www.relisoft.com/tools/CppCritic.html) >>>>>> =3D20 >>>>>> =3D3D20 >>>>>> =3D20 >>>>>> =3D3D20 >>>>>> =3D20 >>>>>> We also have subranges of LONGINT. >>>>>> =3D20 >>>>>> I'm not sure what the generalization of subranges are=3D3D2C = >> granted. >>>>>> =3D20 >>>>>> Maybe some sort of C++ template that takes constants in the = >> template =3D >>>> and d=3D3D >>>>>> oes range checks at runtime. Yeah=3D3D2C maybe. >>>>>> =3D20 >>>>>> =3D3D20 >>>>>> =3D20 >>>>>> =3D3D20 >>>>>> =3D20 >>>>>> And as you point out=3D3D2C convenient literal syntax. >>>>>> =3D20 >>>>>> =3D3D20 >>>>>> =3D20 >>>>>> =3D3D20 >>>>>> =3D20 >>>>>> People reasonably argue for library extension in place of language = >> =3D >>>> extensio=3D3D >>>>>> n=3D3D2C but that requires a language which is flexible enough to = >> write =3D >>>> librari=3D3D >>>>>> es with the desired interface=3D3D2C and so many languages don't = >> let =3D >>>> infix oper=3D3D >>>>>> ators be in a user-written library. >>>>>> =3D20 >>>>>> (There is a subtle but useless distinction here -- infix operators = >> =3D >>>> being in=3D3D >>>>>> libraries vs. "user-written" libraries. The infix set operations = >> for =3D >>>> examp=3D3D >>>>>> le are in a library=3D3D2C but not user-written=3D3D2C special=3D3D2C= >> the =3D >>>> compiler know=3D3D >>>>>> s about it.) >>>>>> =3D20 >>>>>> =3D3D20 >>>>>> =3D20 >>>>>>> that would perhaps not match how C handles "long long" on the same >>>>>>> platform (which is how=3D3D2C come to think of it?)=3D3D2C and = >> that =3D >>>> would require >>>>>> =3D20 >>>>>> =3D20 >>>>>> =3D3D20 >>>>>> =3D20 >>>>>> On NT/x86=3D3D2C __int64/long long is returned in the register pair = >> =3D >>>> edx:eax. >>>>>> =3D20 >>>>>> edx is high=3D3D2C eax is low. >>>>>> =3D20 >>>>>> When passed as a parameter to __stdcall or __cdecl is just passed = >> as =3D >>>> two 32=3D3D >>>>>> bit values adjacent on the stack=3D3D2C "hi=3D3D2C lo=3D3D2C = >> hi=3D3D2C lo=3D3D2C =3D >>>> it's off to pu=3D3D >>>>> sh we go" is the Snow White-influenced mantra to remember how to = >> pass =3D >>>> them=3D3D >>>>>> =3D3D2C at least on little endian stack-growing-down machines = >> (which =3D >>>> includes x=3D3D >>>>>> 86). For __fastcall I'm not sure they are passed in registers or on = >> =3D >>>> the sta=3D3D >>>>>> ck. >>>>>> =3D20 >>>>>> Passing and/or returning small structs also has special efficient =3D= >> >>>> handling =3D3D >>>>>> in the ABI=3D3D2C so __int64 really might be equivalent to a small = >> =3D >>>> record. Not =3D3D >>>>>> that cm3 necessarily implements that "correctly" -- for interop = >> with =3D >>>> C=3D3D3B =3D3D >>>>>> for Modula-3 calling Modula-3 we can make up our own ABI so there =3D= >> >>>> isn't rea=3D3D >>>>>> lly an "incorrect" way. Notice the mingw problem I had passing a =3D >>>> Win32 poin=3D3D >>>>>> t struct by value=3D3D2C I cheated and passed it by VAR to a C = >> wrapper =3D >>>> to worka=3D3D >>>>>> round the gcc backend bug (which was mentioned a few times and = >> which =3D >>>> I look=3D3D >>>>>> ed into the code for=3D3D2C but took the easy route) >>>>>> =3D20 >>>>>> =3D3D20 >>>>>> =3D20 >>>>>> =3D3D20 >>>>>> =3D20 >>>>>> I don't know how long long works on other platforms but probably =3D >>>> similar. >>>>>> =3D20 >>>>>> Probably a certain register pair for return values. >>>>>> =3D20 >>>>>> =3D3D20 >>>>>> =3D20 >>>>>> - Jay >>>>>> =3D20 >>>>>> =3D3D20 >>>>>>> To: hosking at cs.purdue.edu >>>>>>> Date: Sat=3D3D2C 17 Apr 2010 19:47:03 -0700 >>>>>>> From: mika at async.async.caltech.edu >>>>>>> CC: m3devel at elegosoft.com >>>>>>> Subject: Re: [M3devel] INTEGER >>>>>>> =3D3D20 >>>>>>> Tony Hosking writes: >>>>>>>> =3D20 >>>>>>> ... >>>>>>>> =3D20 >>>>>>>>> We need it to match 64-bit integers on 32-bit machines? That = >> seems =3D >>>> =3D3D3D >>>>>>>> like >>>>>>>>> a very weak rationale indeed=3D3D2C if the same functionality = >> could =3D >>>> be =3D3D3D >>>>>>>> provided >>>>>>>>> through some other mechanism (e.g.=3D3D2C ARRAY [0..1] OF =3D >>>> INTEGER---even =3D3D >>>>>> =3D3D3D >>>>>>>> with >>>>>>>>> a pragma e.g. <*CLONGLONG*>.. if it is necessary to tell the =3D >>>> compiler =3D3D >>>>>> =3D3D3D >>>>>>>> that >>>>>>>>> a special linkage convention is needed). >>>>>>>> =3D20 >>>>>>>> There's no special linkage convention. Not sure what you mean = >> here. >>>>>>>> =3D20 >>>>>>> =3D3D20 >>>>>>> I just mean if we had >>>>>>> =3D3D20 >>>>>>> TYPE LONGINT =3D3D3D ARRAY [0..1] OF INTEGER >>>>>>> =3D3D20 >>>>>>> that would perhaps not match how C handles "long long" on the same >>>>>>> platform (which is how=3D3D2C come to think of it?)=3D3D2C and = >> that =3D >>>> would require >>>>>>> special linkage tricks. >>>>>>> =3D3D20 >>>>>>> But what would be lost? The ability to type literals.=3D3D20 >>>>>>> =3D3D20 >>>>>>> You could get the same code interface on 32- and 64-bit machine by >>>>>>> defining >>>>>>> =3D3D20 >>>>>>> TYPE FileOffset =3D3D3D ARRAY[0..1] OF [-16_80000000 .. = >> +16_7fffffff ] >>>>>>> =3D3D20 >>>>>>> and using that. >>>>>>> =3D3D20 >>>>>>> =3D3D20 >>>>>>> Mika >>>>>> =3D3D >>>>>> =3D20 >>>>>> --_264cb69b-0215-44c3-807c-8b4d8ea0ea59_ >>>>>> Content-Type: text/html; charset=3D3D"iso-8859-1" >>>>>> Content-Transfer-Encoding: quoted-printable >>>>>> =3D20 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> TYPE LONGINT =3D3D3D ARRAY [0..1] OF INTEGER on a =3D3D3B32bit = >> system =3D >>>> is very c=3D3D >>>>>> lose to LONGINT.
>>>>>>  =3D3D3BPlus treating it opaquely and providing a bunch of =3D >>>> functions to ope=3D3D >>>>>> rate on it.
>>>>>>  =3D3D3BJust as well therefore could be RECORD = >> hi=3D3D2Clo:LONGINT =3D >>>> END (see LAR=3D3D >>>>>> GE_INTEGER and ULARGE_INTEGER in winnt.h)
>>>>>>  =3D3D3B
>>>>>> Differences that come to mind:
>>>>>>  =3D3D3B =3D3D3Binfix operators =3D3D3B = >> <=3D3D3B=3D3D3D=3D3D3D=3D3D3D =3D >>>>
>>>>>>  =3D3D3B possibly passed differently =3D3D3Bas a = >> parameter
>>>>>>  =3D3D3B or returned differently as a result
>>>>>>  =3D3D3B ie. probably "directly compatible with" "long = >> long"=3D3D2C =3D >>>> passed by v=3D3D >>>>>> alue (of course you could always pass by pointer and achieve =3D >>>> compatibilitit=3D3D >>>>>> y trivially)
>>>>>>  =3D3D3B
>>>>>>  =3D3D3B
>>>>>> I have to say though=3D3D2C the biggest reason is in-fix operators. = >> =3D >>>> Convenient =3D3D >>>>>> syntax.
>>>>>> C++ is the best and some way worst of example of the general right = >> =3D >>>> way to d=3D3D >>>>>> o this -- you let programmers define types and their infix = >> operators. =3D >>>> Other=3D3D >>>>>> languages just come with a passle of special cases of types that = >> have =3D >>>> in-f=3D3D >>>>>> ix operators.
>>>>>> A good example is that Java infix operator + on string=3D3D2C = >> besides =3D >>>> the vario=3D3D >>>>>> us integers=3D3D2C and nothing else.
>>>>>>  =3D3D3B
>>>>>>  =3D3D3B
>>>>>> I think C# lets you define operators=3D3D2C yet people don't = >> complain =3D >>>> that it i=3D3D >>>>>> s "a mess" as they do of C++.
>>>>>> I think Python does now too.
>>>>>> So it is feature growing in popularity among "mainstream" =3D >>>> languages=3D3D2C not =3D3D >>>>>> just C++.
>>>>>>  =3D3D3B =3D3D3B C++ of course is extremely mainstream=3D3D2C= >> but =3D >>>> also a favori=3D3D >>>>>> te target. (>>> href=3D3D3D"http://www.relisoft.com/tools/CppCritic.html">http:/=3D3D >>>>>> /www.relisoft.com/tools/CppCritic.html)
>>>>>>  =3D3D3B
>>>>>>  =3D3D3B
>>>>>> We also have subranges of LONGINT.
>>>>>> I'm not sure what the generalization of subranges are=3D3D2C =3D >>>> granted.
>>>>>>  =3D3D3BMaybe some sort of C++ template that takes constants in = >> the =3D >>>> templat=3D3D >>>>>> e and does range checks at runtime. Yeah=3D3D2C maybe.
>>>>>>  =3D3D3B
>>>>>>  =3D3D3B
>>>>>> And as you point out=3D3D2C convenient literal syntax.
>>>>>>  =3D3D3B
>>>>>>  =3D3D3B
>>>>>> People reasonably argue for library extension in place of language = >> =3D >>>> extensio=3D3D >>>>>> n=3D3D2C but that requires a language which is flexible enough to = >> write =3D >>>> librari=3D3D >>>>>> es with the desired interface=3D3D2C and so many languages don't = >> let =3D >>>> infix oper=3D3D >>>>>> ators be in a user-written library.
>>>>>> (There is a subtle but useless distinction here -- infix operators = >> =3D >>>> being in=3D3D >>>>>> libraries vs. "user-written" libraries. The infix set operations = >> for =3D >>>> examp=3D3D >>>>>> le are in a library=3D3D2C but not user-written=3D3D2C special=3D3D2C= >> the =3D >>>> compiler know=3D3D >>>>>> s about it.)
>>>>>>  =3D3D3B
>>>>>> >=3D3D3B that would perhaps not match how C handles "long long" = >> on =3D >>>> the same>>>>> R>>=3D3D3B platform (which is how=3D3D2C come to think of = >> it?)=3D3D2C and =3D >>>> that would =3D3D >>>>>> require

>>>>>>  =3D3D3B
>>>>>> On NT/x86=3D3D2C __int64/long long is returned in the register pair = >> =3D >>>> edx:eax.>>>>>> =3D20 >>>>>> edx is high=3D3D2C eax is low.
>>>>>> When passed as a parameter to __stdcall or __cdecl is just passed = >> as =3D >>>> two 32=3D3D >>>>>> bit values adjacent on the stack=3D3D2C "hi=3D3D2C lo=3D3D2C = >> hi=3D3D2C lo=3D3D2C =3D >>>> it's off to pu=3D3D >>>>>> sh we go" is the Snow White-influenced mantra to remember how to = >> pass =3D >>>> them=3D3D >>>>>> =3D3D2C at least on little endian stack-growing-down machines = >> (which =3D >>>> includes x=3D3D >>>>>> 86). For __fastcall I'm not sure they are passed in registers or on = >> =3D >>>> the sta=3D3D >>>>>> ck.
>>>>>> Passing and/or returning small structs also has special efficient =3D= >> >>>> handling =3D3D >>>>>> in the ABI=3D3D2C so __int64 really might be equivalent to a small = >> =3D >>>> record. Not =3D3D >>>>>> that cm3 necessarily implements that "correctly" =3D3D3B -- for = >> =3D >>>> interop wit=3D3D >>>>>> h C=3D3D3B for Modula-3 calling Modula-3 we can make up our own ABI = >> so =3D >>>> there is=3D3D >>>>>> n't =3D3D3Breally an "incorrect" way. =3D3D3BNotice the = >> mingw =3D >>>> problem I had=3D3D >>>>>> passing a Win32 point struct by value=3D3D2C I cheated and passed = >> it by =3D >>>> VAR to=3D3D >>>>>> a =3D3D3BC wrapper to workaround the gcc backend bug (which was = >> =3D >>>> mentioned =3D3D >>>>>> a few times and which I looked into the code for=3D3D2C but took = >> the =3D >>>> easy route=3D3D >>>>>> )
>>>>>>  =3D3D3B
>>>>>>  =3D3D3B
>>>>>> I don't know how long long works on other platforms but probably =3D >>>> similar.>>>>> R> >>>>>> Probably a certain register pair for return values.
>>>>>>  =3D3D3B
>>>>>>  =3D3D3B- Jay

 =3D3D3B
>=3D3D3B To: =3D >>>> hosking at cs.purdue.edu
>=3D3D3B=3D3D >>>>>> Date: Sat=3D3D2C 17 Apr 2010 19:47:03 -0700
>=3D3D3B From: =3D >>>> mika at async.async.c=3D3D >>>>>> altech.edu
>=3D3D3B CC: m3devel at elegosoft.com
>=3D3D3B = >> Subject: =3D >>>> Re: [M3de=3D3D >>>>>> vel] INTEGER
>=3D3D3B
>=3D3D3B Tony Hosking = >> writes:
>=3D3D3B =3D >>>> >=3D3D3B
=3D3D >>>>>> >=3D3D3B ...
>=3D3D3B >=3D3D3B
>=3D3D3B = >> >=3D3D3B>=3D3D3B We =3D >>>> need it to match 64-b=3D3D >>>>>> it integers on 32-bit machines? That seems =3D3D3D
>=3D3D3B =3D >>>> >=3D3D3Blike
>=3D3D >>>>>> =3D3D3B >=3D3D3B>=3D3D3B a very weak rationale indeed=3D3D2C if = >> the same =3D >>>> functionality =3D3D >>>>>> could be =3D3D3D
>=3D3D3B >=3D3D3Bprovided
>=3D3D3B = >> >=3D3D3B>=3D3D3=3D >>>> B through some o=3D3D >>>>>> ther mechanism (e.g.=3D3D2C ARRAY [0..1] OF INTEGER---even =3D >>>> =3D3D3D
>=3D3D3B >=3D3D3B=3D3D >>>>>> with
>=3D3D3B >=3D3D3B>=3D3D3B a pragma e.g. =3D >>>> <=3D3D3B*CLONGLONG*>=3D3D3B.. if it i=3D3D >>>>>> s necessary to tell the compiler =3D3D3D
>=3D3D3B =3D >>>> >=3D3D3Bthat
>=3D3D3B >=3D3D3B&=3D3D >>>>>> gt=3D3D3B a special linkage convention is needed).
>=3D3D3B =3D >>>> >=3D3D3B
>=3D3D3B &=3D3D >>>>>> gt=3D3D3BThere's no special linkage convention. Not sure what you = >> mean =3D >>>> here.>>>>>> >=3D3D3B >=3D3D3B
>=3D3D3B
>=3D3D3B I just mean if = >> we =3D >>>> had
>=3D3D3B
>=3D3D >>>>>> =3D3D3B TYPE LONGINT =3D3D3D ARRAY [0..1] OF INTEGER
>=3D3D3B = >> =3D >>>>
>=3D3D3B that woul=3D3D >>>>>> d perhaps not match how C handles "long long" on the = >> same
>=3D3D3B =3D >>>> platfor=3D3D >>>>>> m (which is how=3D3D2C come to think of it?)=3D3D2C and that would = >> =3D >>>> require
>=3D3D >>>>>> =3D3D3B special linkage tricks.
>=3D3D3B
>=3D3D3B But = >> what would =3D >>>> be lost? Th=3D3D >>>>>> e ability to type literals.
>=3D3D3B
>=3D3D3B You could = >> get =3D >>>> the same co=3D3D >>>>>> de interface on 32- and 64-bit machine by
>=3D3D3B =3D >>>> defining
>=3D3D3B
=3D3D >>>>>> >=3D3D3B TYPE FileOffset =3D3D3D ARRAY[0..1] OF [-16_80000000 .. = >> =3D >>>> +16_7fffffff ]>>>>> R>>=3D3D3B
>=3D3D3B and using that.
>=3D3D3B = >>
>=3D3D3B =3D >>>>
>=3D3D3B Mika>>>>>> >>>>>> =3D3D >>>>>> =3D20 >>>>>> --_264cb69b-0215-44c3-807c-8b4d8ea0ea59_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Mon Apr 19 17:48:02 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 19 Apr 2010 11:48:02 -0400 Subject: [M3devel] INTEGER In-Reply-To: <4F3EE437-0298-410B-9642-C0381E333430@cs.purdue.edu> References: <20100418024703.6965B1A2103@async.async.caltech.edu> <20100418074927.934461A2117@async.async.caltech.edu> <04EB7FF8-D304-428D-839E-233FCE009C98@cs.purdue.edu> <20100418195901.CDACB1A20F6@async.async.caltech.edu> <20100419172313.68B241A20D6@async.async.caltech.edu> <4F3EE437-0298-410B-9642-C0381E333430@cs.purdue.edu> Message-ID: <20100419154802.GA8759@topoi.pooq.com> On Mon, Apr 19, 2010 at 02:44:00PM -0400, Tony Hosking wrote: > > > On 19 Apr 2010, at 13:23, Mika Nystrom wrote: > > > > > Well *my* problem is that I still use PM3 for a lot of things. Trying to > > switch to CM3, yes, but I can't "certify" CM3 for critical stuff yet. > > > > So I'm maintaining a significant amount of code that needs to compile > > under both PM3 and CM3. Two problems crop up. > > > > 1. If there are bugs in m3tk/stubgen, the fixes only apply to one or > > the other version of m3tk/stubgen. > > > > 2. Some of the code I'm maintaining processes Modula-3 code as input. > > It needs to be in two versions. > > > > In this kind of environment, programming languages don't really > > evolve, since the system depends on their being both forward- and > > backward-compatible. They "change" is more correct. The way Java > > changes. > > Indeed: Growing a Language, by Guy Steele > > > > > More in general, though, Modula-3's designers were clearly well acquainted > > with C, Fortran, and other languages that provide different-range > > integers. They chose not to indulge. I even have a version of Modula-3 > > for a 16-bit machine that doesn't do it, even though on this machine the > > need for a 32-bit integer is arguably greater than the need for 64-bit > > integers on 32-bit machines. Now we indulge in this language complication > > to solve what is clearly a temporary problem, since anyone who cares > > about large problems is going to have 64-bit systems yesterday... and > > meanwhile no one seems to have availed himself of the solution! > > If we were to revert, I have no idea what the implications would be. Jay? > > > My worst fear is that once the process gets started, the reason for > > staying with the original Green-Book specification has now been defeated > > and we will see more and more "evolution". Trying to actually build > > systems that process Modula-3 like data becomes, at that point, like > > trying to stand in quicksand. > > Indeed! > > > > > I'm not incredibly picky here... I just hope it doesn't go further. > > I would personally support either sticking with the current status quo > > or going back to the Green Book w.r.t. integers and characters. > > Indeed, I would not want to see this go any further. I am still not > sure I am comfortable with the LONGINT extension (even though I put a > lot of time into it). There just seemed to be a lot of pressure for > it to so CM3 could handle large file indexes. I've never been > convinced that WIDECHAR was a winner either -- it was a reflexive > action in the face of Java's Unicode. The CM3 people were building a > Java VM above CM3 at the time. The LONGINT problem has several causes: (1) INTEGER being defined as the largest integer type in the language. (2) INTEGER being implemented as a specific fixed-size type that can be implemented "efficiently", whatever that means. (3) The world of Modula 3 programmers using INTEGER whenever they didn't want to worry about what actual range they needed. These three facts make it difficult to implement integer types that are larger than the ones that are "efficient" on the hardware. In my opinion it was a mistake to define the "efficient" integer type to necessarily be the "largest" integer type. It was this that made it necessary to invent a new type hierarchy of LONGINTs, which are not necessarily implemented efficiently. But I see no need to make the largest type in this hierarchy explicitly available to the programmer. It is possible to have only subranges of LONGINT available, and it is possible to track the maximum values achievable with arithmetic operations, and thus determine the subranges needed for intermediate results. Had we left LONGINT unconstrained, we could have had the simple rule: use INTEGER if efficiency is more important thatn correctness (or you know you'll be in-range), use LONGINT otherwise. Doing that thoroughly would have required some compiler energetics. Still, the necessaries could all have been done statically, without causing any further grief the day a third length of integer is needed. I have no idea whether that day will ever arrive, but it seems foolish to design the language in such a way as to make that day difficult to accomodate. My druthers would have been to have more-or-less the present LONGINT, but restrict programmers to use only subtypes of it. If there is to be a maximum LONGINT value (possibly as an implementation reastriciton), overflowing past it must be checked. -- hendrik > > > > > Saying that EWD wasn't renowned for his practicality is something he > > would have taken as a great compliment, I'm sure. > > ;-) > Actually, I kind of suspect he thought he *was* being practical. -- hendrik From hendrik at topoi.pooq.com Mon Apr 19 17:57:02 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 19 Apr 2010 11:57:02 -0400 Subject: [M3devel] INTEGER In-Reply-To: <20100418195901.CDACB1A20F6@async.async.caltech.edu> References: <20100418024703.6965B1A2103@async.async.caltech.edu> <20100418074927.934461A2117@async.async.caltech.edu> <04EB7FF8-D304-428D-839E-233FCE009C98@cs.purdue.edu> <20100418195901.CDACB1A20F6@async.async.caltech.edu> Message-ID: <20100419155702.GB8759@topoi.pooq.com> On Sun, Apr 18, 2010 at 12:59:01PM -0700, Mika Nystrom wrote: > > And the new m3tk, stubgen, and compiler(?) won't compile using PM3 or > SRC M3 since we're no longer using the language of the Green Book. > (Same comment goes for WIDECHAR, by the way.) When I use Unicode characters, I find myself defining them to be INTEGERs, because I'm always worried that WIDECHARs might be omly 16 bits. Strings of WIDECHARS are probably unnecesary. The last program I wrote that used Unicode used INTEGERs for characters, and arrays of INTEGERS for strings. But I think it was a mistake to do it this way, and when I have time I'll rewrite it. UTF-8 seems to be the way to go; strings of Unicode can easily be manipulated as ordinary TEXT. In fact, I think there are few if any places in my code where I would have had to do anything special whatsoever if I had just used UTF8 in TEXT. The program would simply become simpler. -- hendrik From jay.krell at cornell.edu Mon Apr 19 23:20:00 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 19 Apr 2010 21:20:00 +0000 Subject: [M3devel] INTEGER In-Reply-To: <20100419155702.GB8759@topoi.pooq.com> References: <20100418024703.6965B1A2103@async.async.caltech.edu>, , <20100418074927.934461A2117@async.async.caltech.edu>, <04EB7FF8-D304-428D-839E-233FCE009C98@cs.purdue.edu>, <20100418195901.CDACB1A20F6@async.async.caltech.edu>, <20100419155702.GB8759@topoi.pooq.com> Message-ID: For the record, anyone using Windows (NT/2000/XP/2003/etc.) is using 16bit characters *all the time*. MacOSX maybe also. I think utf8 is kind of a hack to let folks get away without really doing anything. Granted, I didn't realize till recently that strcmp works on utf8..maybe a really clever idea.. - Jay > Date: Mon, 19 Apr 2010 11:57:02 -0400 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] INTEGER > > On Sun, Apr 18, 2010 at 12:59:01PM -0700, Mika Nystrom wrote: > > > > And the new m3tk, stubgen, and compiler(?) won't compile using PM3 or > > SRC M3 since we're no longer using the language of the Green Book. > > (Same comment goes for WIDECHAR, by the way.) > > When I use Unicode characters, I find myself defining them to be > INTEGERs, because I'm always worried that WIDECHARs might be omly 16 bits. > > Strings of WIDECHARS are probably unnecesary. The last program I wrote > that used Unicode used INTEGERs for characters, and arrays of INTEGERS > for strings. But I think it was a mistake to do it this way, and when I > have time I'll rewrite it. UTF-8 seems to be the way to go; strings of > Unicode can easily be manipulated as ordinary TEXT. In fact, I > think there are few if any places in my code where I would have had to > do anything special whatsoever if I had just used UTF8 in TEXT. The > program would simply become simpler. > > -- hendrik -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Apr 19 23:25:48 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 19 Apr 2010 21:25:48 +0000 Subject: [M3devel] INTEGER In-Reply-To: <4F3EE437-0298-410B-9642-C0381E333430@cs.purdue.edu> References: , , ,,<7C7408D0-9A40-4988-BADA-A9FD8C15D388@cs.purdue.edu>, ,,, , , , , , , , , <20100418023535.3BA9E1A2103@async.async.caltech.edu>, , , , <20100418024703.6965B1A2103@async.async.caltech.edu>, , <20100418074927.934461A2117@async.async.caltech.edu>, <04EB7FF8-D304-428D-839E-233FCE009C98@cs.purdue.edu>, <20100418195901.CDACB1A20F6@async.async.caltech.edu>, , <20100419172313.68B241A20D6@async.async.caltech.edu>, <4F3EE437-0298-410B-9642-C0381E333430@cs.purdue.edu> Message-ID: > If we were to revert, I have no idea what the implications would be. Jay? I'm sure we could cope. Besides, we'd put in a library-based solution anyway? That the compiler inlines? Like atomics? Let me suggest a small exercise though: I'm not going to do it. Write a program that copies files. Or just one file. "cp.exe". Have it print "progress feedback" to the user -- how many bytes and percentage copied. Leave out "time estimation". And also write "ls.exe". And maybe one last program, like "dos2unix.exe" or "fix_nl.exe" that alters newlines. This program should work on files that don't fit in memory. That is, get some experience working with files that don't fit in memory/address space. But also for which lots memory/address space really aren't needed. Also think about what an idea representation of time is. Isn't a 64bit integer number of units smaller than a second a very good one? And aren't infix operators darned nice? - Jay From: hosking at cs.purdue.edu Date: Mon, 19 Apr 2010 14:44:00 -0400 To: mika at async.async.caltech.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] INTEGER On 19 Apr 2010, at 13:23, Mika Nystrom wrote: Well *my* problem is that I still use PM3 for a lot of things. Trying to switch to CM3, yes, but I can't "certify" CM3 for critical stuff yet. So I'm maintaining a significant amount of code that needs to compile under both PM3 and CM3. Two problems crop up. 1. If there are bugs in m3tk/stubgen, the fixes only apply to one or the other version of m3tk/stubgen. 2. Some of the code I'm maintaining processes Modula-3 code as input. It needs to be in two versions. In this kind of environment, programming languages don't really evolve, since the system depends on their being both forward- and backward-compatible. They "change" is more correct. The way Java changes. Indeed: Growing a Language, by Guy Steele More in general, though, Modula-3's designers were clearly well acquainted with C, Fortran, and other languages that provide different-range integers. They chose not to indulge. I even have a version of Modula-3 for a 16-bit machine that doesn't do it, even though on this machine the need for a 32-bit integer is arguably greater than the need for 64-bit integers on 32-bit machines. Now we indulge in this language complication to solve what is clearly a temporary problem, since anyone who cares about large problems is going to have 64-bit systems yesterday... and meanwhile no one seems to have availed himself of the solution! If we were to revert, I have no idea what the implications would be. Jay? My worst fear is that once the process gets started, the reason for staying with the original Green-Book specification has now been defeated and we will see more and more "evolution". Trying to actually build systems that process Modula-3 like data becomes, at that point, like trying to stand in quicksand. Indeed! I'm not incredibly picky here... I just hope it doesn't go further. I would personally support either sticking with the current status quo or going back to the Green Book w.r.t. integers and characters. Indeed, I would not want to see this go any further. I am still not sure I am comfortable with the LONGINT extension (even though I put a lot of time into it). There just seemed to be a lot of pressure for it to so CM3 could handle large file indexes. I've never been convinced that WIDECHAR was a winner either -- it was a reflexive action in the face of Java's Unicode. The CM3 people were building a Java VM above CM3 at the time. Saying that EWD wasn't renowned for his practicality is something he would have taken as a great compliment, I'm sure. ;-) Mika Tony Hosking writes: Mika, First off, I'd be very interested to know what the issues are with = LONGINT and stubgen. We are building that every day in regression = testing. It would be really good to get some precise feedback. True, LONGINT is integrated with all of the language tools (same as = WIDECHAR). I suppose that is the price we pay for the language having evolved. = Nevertheless, CM3 should be totally backward compatible with the green = book. There is no reason it should not build packages from PM3 or SRC. Now, this is not to say that perhaps we haven't overreached with LONGINT = given that 64-bit is more prevalent. But then it is also useful to be = able to interoperate with C libraries. The previous interfacing was = pretty much a kludge, using ARRAY[0..1] OF INTEGER for "long long" but = then not propagating the double INTEGER value properly throughout the = Modula-3 libraries. I'm sorry to say that EWD was not particularly renowned for his = practicality; pedant more like. Nice to be high and mighty but we also = need to interact with the real world. We should be able to make this work. Is there a better alternative? = Revoke LONGINT, and WIDECHAR? On 18 Apr 2010, at 15:59, Mika Nystrom wrote: =20 My problem is really just that it's ugly. LONGx is showing up as an = issue in all sorts of low-level code, which is not surprising since Modula-3 with LONGx is not the same language as Modula-3 (maybe we should call it Modula-3+?)=20 =20 The compiler bootstrapping process has gotten more complicated due to = it, and when I cvs updated m3tk yesterday stubgen wouldn't compile because = there was something "long" in it that wasn't there before. I have no idea = what library or components I needed to update and recompile and didn't have = the time to deal with the issue at the time. =20 And the new m3tk, stubgen, and compiler(?) won't compile using PM3 or SRC M3 since we're no longer using the language of the Green Book. (Same comment goes for WIDECHAR, by the way.) =20 One of the wonderful things about Modula-3 *used to be* that I could grab some old package from DECSRC and just use it without changes = since no one had messed with the language definition. This is still true as far as programs that just use the tools go, but it's no longer true = for programs that process Modula-3 code as input data. Of which there are more than a few: many aspects of Modula-3 were specifically designed = to make the language easy to process by program, as an intermediate = format and whatnot. =20 To quote E.W.D.: =20 'Unfathomed misunderstanding is further revealed by the term "software maintenance", as a result of which many people continue to believe = that programs and even programming languages themselves are subject to wear and tear. Your car needs maintenance too, doesn't it? Famous is the = story of the oil company that believed that its PASCAL programs did not last as long as its FORTRAN programs "because PASCAL was not maintained".' =20 LONGx is causing me to have to do "software maintenance" on Modula-3 programs... for a feature that no one appears to be using and is = quickly becoming irrelevant. =20 Mika =20 =20 Tony Hosking writes: In the language spec NUMBER(a) and LAST(a) - FIRST(a) + 1 are *not* =3D= defined to mean the same thing for all types. NUMBER does have an INTEGER value, as expected for subranges of = LONGINT =3D that are not too large. This is as it has always been for subranges of INTEGER that are not = too =3D large. =20 Mika, I'm not sure I see any of the problems you are worrying about = in =3D the current definition of LONGINT/LONGCARD. =20 On 18 Apr 2010, at 03:49, Mika Nystrom wrote: =20 =3D20 Jay I know most of this, and it doesn't really answer the question "what is it for?" =3D20 I think we've already established that LONGINT isn't useful for =3D counting anything that might actually reside in the computer's memory: it = makes no sense as an array index, for instance. INTEGER suffices for = that. =3D20 I thought that the only real reason for LONGINT was to match C's declaration of various seek-related routines on 32-bit machines. That's not a very good reason. =3D20 C++ succeeds because it does very well in the area(s) it is good at. People who want to program in C++ will clearly program in C++, not Modula-3. Modula-3 is never, ever going to be the language of = choice =3D for people who want lots of snazzy infix operators. Modula-3 is = supposed =3D to be a language with about as powerful semantics as C++ and an = extremely simple syntax and definition---snazzy infix is one of the things you give up for that. I don't see how LONGINT fits into this picture. Now we have LONGCARD too? And it's infected the definitions of FIRST and LAST? But not NUMBER... argh! =3D20 so, =3D20 NUMBER(a) and LAST(a) - FIRST(a) + 1 =3D20 no longer mean the same thing? Are we going to see lots of comments in generics in the future where it says T may not be an open array type nor an array type indexed on LONGINT or a subrange thereof? =3D20 Your comments about different parameter-passing techniques was what = I =3D was trying to address with my suggestion to have a pragma for = this---just =3D to match C (and Fortran?), of course. Name me a single Modula-3 =3D programmer who cares in what order the bits in his parameters are pushed on the stack in a Modula-3-to-Modula-3 call. =3D20 And I am definitely in that school of thought that says that =3D programming languages should not "evolve". Better to leave well enough alone. =3D20 How much Modula-3 code has been written that uses LONGINT? Other = than to talk to C? I've certainly never used it. =3D20 Mika =3D20 =3D20 =3D20 Jay K writes: --_264cb69b-0215-44c3-807c-8b4d8ea0ea59_ Content-Type: text/plain; charset=3D3D"iso-8859-1" Content-Transfer-Encoding: quoted-printable =3D20 =3D20 TYPE LONGINT =3D3D3D ARRAY [0..1] OF INTEGER on a 32bit system is = very =3D close to=3D3D LONGINT. =3D20 Plus treating it opaquely and providing a bunch of functions to =3D operate on=3D3D it. =3D20 Just as well therefore could be RECORD hi=3D3D2Clo:LONGINT END (see = =3D LARGE_INTE=3D3D GER and ULARGE_INTEGER in winnt.h) =3D20 =3D3D20 =3D20 Differences that come to mind: =3D20 infix operators <=3D3D3D=3D3D3D=3D3D3D=3D3D20 =3D20 possibly passed differently as a parameter =3D20 or returned differently as a result =3D20 ie. probably "directly compatible with" "long long"=3D3D2C passed = by =3D value (o=3D3D f course you could always pass by pointer and achieve = compatibilitity =3D trivi=3D3D ally) =3D20 =3D3D20 =3D20 =3D3D20 =3D20 I have to say though=3D3D2C the biggest reason is in-fix operators. = =3D Convenient =3D3D syntax. =3D20 C++ is the best and some way worst of example of the general right = =3D way to d=3D3D o this -- you let programmers define types and their infix = operators. =3D Other=3D3D languages just come with a passle of special cases of types that = have =3D in-f=3D3D ix operators. =3D20 A good example is that Java infix operator + on string=3D3D2C = besides =3D the vario=3D3D us integers=3D3D2C and nothing else. =3D20 =3D3D20 =3D20 =3D3D20 =3D20 I think C# lets you define operators=3D3D2C yet people don't = complain =3D that it i=3D3D s "a mess" as they do of C++. =3D20 I think Python does now too. =3D20 So it is feature growing in popularity among "mainstream" =3D languages=3D3D2C not =3D3D just C++. =3D20 C++ of course is extremely mainstream=3D3D2C but also a favorite =3D target. (ht=3D3D tp://www.relisoft.com/tools/CppCritic.html) =3D20 =3D3D20 =3D20 =3D3D20 =3D20 We also have subranges of LONGINT. =3D20 I'm not sure what the generalization of subranges are=3D3D2C = granted. =3D20 Maybe some sort of C++ template that takes constants in the = template =3D and d=3D3D oes range checks at runtime. Yeah=3D3D2C maybe. =3D20 =3D3D20 =3D20 =3D3D20 =3D20 And as you point out=3D3D2C convenient literal syntax. =3D20 =3D3D20 =3D20 =3D3D20 =3D20 People reasonably argue for library extension in place of language = =3D extensio=3D3D n=3D3D2C but that requires a language which is flexible enough to = write =3D librari=3D3D es with the desired interface=3D3D2C and so many languages don't = let =3D infix oper=3D3D ators be in a user-written library. =3D20 (There is a subtle but useless distinction here -- infix operators = =3D being in=3D3D libraries vs. "user-written" libraries. The infix set operations = for =3D examp=3D3D le are in a library=3D3D2C but not user-written=3D3D2C special=3D3D2C= the =3D compiler know=3D3D s about it.) =3D20 =3D3D20 =3D20 that would perhaps not match how C handles "long long" on the same platform (which is how=3D3D2C come to think of it?)=3D3D2C and = that =3D would require =3D20 =3D20 =3D3D20 =3D20 On NT/x86=3D3D2C __int64/long long is returned in the register pair = =3D edx:eax. =3D20 edx is high=3D3D2C eax is low. =3D20 When passed as a parameter to __stdcall or __cdecl is just passed = as =3D two 32=3D3D bit values adjacent on the stack=3D3D2C "hi=3D3D2C lo=3D3D2C = hi=3D3D2C lo=3D3D2C =3D it's off to pu=3D3D sh we go" is the Snow White-influenced mantra to remember how to = pass =3D them=3D3D =3D3D2C at least on little endian stack-growing-down machines = (which =3D includes x=3D3D 86). For __fastcall I'm not sure they are passed in registers or on = =3D the sta=3D3D ck. =3D20 Passing and/or returning small structs also has special efficient =3D= handling =3D3D in the ABI=3D3D2C so __int64 really might be equivalent to a small = =3D record. Not =3D3D that cm3 necessarily implements that "correctly" -- for interop = with =3D C=3D3D3B =3D3D for Modula-3 calling Modula-3 we can make up our own ABI so there =3D= isn't rea=3D3D lly an "incorrect" way. Notice the mingw problem I had passing a =3D Win32 poin=3D3D t struct by value=3D3D2C I cheated and passed it by VAR to a C = wrapper =3D to worka=3D3D round the gcc backend bug (which was mentioned a few times and = which =3D I look=3D3D ed into the code for=3D3D2C but took the easy route) =3D20 =3D3D20 =3D20 =3D3D20 =3D20 I don't know how long long works on other platforms but probably =3D similar. =3D20 Probably a certain register pair for return values. =3D20 =3D3D20 =3D20 - Jay =3D20 =3D3D20 To: hosking at cs.purdue.edu Date: Sat=3D3D2C 17 Apr 2010 19:47:03 -0700 From: mika at async.async.caltech.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] INTEGER =3D3D20 Tony Hosking writes: =3D20 ... =3D20 We need it to match 64-bit integers on 32-bit machines? That = seems =3D =3D3D3D like a very weak rationale indeed=3D3D2C if the same functionality = could =3D be =3D3D3D provided through some other mechanism (e.g.=3D3D2C ARRAY [0..1] OF =3D INTEGER---even =3D3D =3D3D3D with a pragma e.g. <*CLONGLONG*>.. if it is necessary to tell the =3D compiler =3D3D =3D3D3D that a special linkage convention is needed). =3D20 There's no special linkage convention. Not sure what you mean = here. =3D20 =3D3D20 I just mean if we had =3D3D20 TYPE LONGINT =3D3D3D ARRAY [0..1] OF INTEGER =3D3D20 that would perhaps not match how C handles "long long" on the same platform (which is how=3D3D2C come to think of it?)=3D3D2C and = that =3D would require special linkage tricks. =3D3D20 But what would be lost? The ability to type literals.=3D3D20 =3D3D20 You could get the same code interface on 32- and 64-bit machine by defining =3D3D20 TYPE FileOffset =3D3D3D ARRAY[0..1] OF [-16_80000000 .. = +16_7fffffff ] =3D3D20 and using that. =3D3D20 =3D3D20 Mika =3D3D =3D20 --_264cb69b-0215-44c3-807c-8b4d8ea0ea59_ Content-Type: text/html; charset=3D3D"iso-8859-1" Content-Transfer-Encoding: quoted-printable =3D20 TYPE LONGINT =3D3D3D ARRAY [0..1] OF INTEGER on a =3D3D3B32bit = system =3D is very c=3D3D lose to LONGINT.
 =3D3D3BPlus treating it opaquely and providing a bunch of =3D functions to ope=3D3D rate on it.
 =3D3D3BJust as well therefore could be RECORD = hi=3D3D2Clo:LONGINT =3D END (see LAR=3D3D GE_INTEGER and ULARGE_INTEGER in winnt.h)
 =3D3D3B
Differences that come to mind:
 =3D3D3B =3D3D3Binfix operators =3D3D3B = <=3D3D3B=3D3D3D=3D3D3D=3D3D3D =3D
 =3D3D3B possibly passed differently =3D3D3Bas a = parameter
 =3D3D3B or returned differently as a result
 =3D3D3B ie. probably "directly compatible with" "long = long"=3D3D2C =3D passed by v=3D3D alue (of course you could always pass by pointer and achieve =3D compatibilitit=3D3D y trivially)
 =3D3D3B
 =3D3D3B
I have to say though=3D3D2C the biggest reason is in-fix operators. = =3D Convenient =3D3D syntax.
C++ is the best and some way worst of example of the general right = =3D way to d=3D3D o this -- you let programmers define types and their infix = operators. =3D Other=3D3D languages just come with a passle of special cases of types that = have =3D in-f=3D3D ix operators.
A good example is that Java infix operator + on string=3D3D2C = besides =3D the vario=3D3D us integers=3D3D2C and nothing else.
 =3D3D3B
 =3D3D3B
I think C# lets you define operators=3D3D2C yet people don't = complain =3D that it i=3D3D s "a mess" as they do of C++.
I think Python does now too.
So it is feature growing in popularity among "mainstream" =3D languages=3D3D2C not =3D3D just C++.
 =3D3D3B =3D3D3B C++ of course is extremely mainstream=3D3D2C= but =3D also a favori=3D3D te target. (http:/=3D3D /www.relisoft.com/tools/CppCritic.html)
 =3D3D3B
 =3D3D3B
We also have subranges of LONGINT.
I'm not sure what the generalization of subranges are=3D3D2C =3D granted.
 =3D3D3BMaybe some sort of C++ template that takes constants in = the =3D templat=3D3D e and does range checks at runtime. Yeah=3D3D2C maybe.
 =3D3D3B
 =3D3D3B
And as you point out=3D3D2C convenient literal syntax.
 =3D3D3B
 =3D3D3B
People reasonably argue for library extension in place of language = =3D extensio=3D3D n=3D3D2C but that requires a language which is flexible enough to = write =3D librari=3D3D es with the desired interface=3D3D2C and so many languages don't = let =3D infix oper=3D3D ators be in a user-written library.
(There is a subtle but useless distinction here -- infix operators = =3D being in=3D3D libraries vs. "user-written" libraries. The infix set operations = for =3D examp=3D3D le are in a library=3D3D2C but not user-written=3D3D2C special=3D3D2C= the =3D compiler know=3D3D s about it.)
 =3D3D3B
>=3D3D3B that would perhaps not match how C handles "long long" = on =3D the same>=3D3D3B platform (which is how=3D3D2C come to think of = it?)=3D3D2C and =3D that would =3D3D require

 =3D3D3B
On NT/x86=3D3D2C __int64/long long is returned in the register pair = =3D edx:eax. When passed as a parameter to __stdcall or __cdecl is just passed = as =3D two 32=3D3D bit values adjacent on the stack=3D3D2C "hi=3D3D2C lo=3D3D2C = hi=3D3D2C lo=3D3D2C =3D it's off to pu=3D3D sh we go" is the Snow White-influenced mantra to remember how to = pass =3D them=3D3D =3D3D2C at least on little endian stack-growing-down machines = (which =3D includes x=3D3D 86). For __fastcall I'm not sure they are passed in registers or on = =3D the sta=3D3D ck.
Passing and/or returning small structs also has special efficient =3D= handling =3D3D in the ABI=3D3D2C so __int64 really might be equivalent to a small = =3D record. Not =3D3D that cm3 necessarily implements that "correctly" =3D3D3B -- for = =3D interop wit=3D3D h C=3D3D3B for Modula-3 calling Modula-3 we can make up our own ABI = so =3D there is=3D3D n't =3D3D3Breally an "incorrect" way. =3D3D3BNotice the = mingw =3D problem I had=3D3D passing a Win32 point struct by value=3D3D2C I cheated and passed = it by =3D VAR to=3D3D a =3D3D3BC wrapper to workaround the gcc backend bug (which was = =3D mentioned =3D3D a few times and which I looked into the code for=3D3D2C but took = the =3D easy route=3D3D )
 =3D3D3B
 =3D3D3B
I don't know how long long works on other platforms but probably =3D similar. Probably a certain register pair for return values.
 =3D3D3B
 =3D3D3B- Jay

 =3D3D3B
>=3D3D3B To: =3D hosking at cs.purdue.edu
>=3D3D3B=3D3D Date: Sat=3D3D2C 17 Apr 2010 19:47:03 -0700
>=3D3D3B From: =3D mika at async.async.c=3D3D altech.edu
>=3D3D3B CC: m3devel at elegosoft.com
>=3D3D3B = Subject: =3D Re: [M3de=3D3D vel] INTEGER
>=3D3D3B
>=3D3D3B Tony Hosking = writes:
>=3D3D3B =3D >=3D3D3B
=3D3D >=3D3D3B ...
>=3D3D3B >=3D3D3B
>=3D3D3B = >=3D3D3B>=3D3D3B We =3D need it to match 64-b=3D3D it integers on 32-bit machines? That seems =3D3D3D
>=3D3D3B =3D >=3D3D3Blike
>=3D3D =3D3D3B >=3D3D3B>=3D3D3B a very weak rationale indeed=3D3D2C if = the same =3D functionality =3D3D could be =3D3D3D
>=3D3D3B >=3D3D3Bprovided
>=3D3D3B = >=3D3D3B>=3D3D3=3D B through some o=3D3D ther mechanism (e.g.=3D3D2C ARRAY [0..1] OF INTEGER---even =3D =3D3D3D
>=3D3D3B >=3D3D3B=3D3D with
>=3D3D3B >=3D3D3B>=3D3D3B a pragma e.g. =3D <=3D3D3B*CLONGLONG*>=3D3D3B.. if it i=3D3D s necessary to tell the compiler =3D3D3D
>=3D3D3B =3D >=3D3D3Bthat
>=3D3D3B >=3D3D3B&=3D3D gt=3D3D3B a special linkage convention is needed).
>=3D3D3B =3D >=3D3D3B
>=3D3D3B &=3D3D gt=3D3D3BThere's no special linkage convention. Not sure what you = mean =3D here.>=3D3D3B
>=3D3D3B I just mean if = we =3D had
>=3D3D3B
>=3D3D =3D3D3B TYPE LONGINT =3D3D3D ARRAY [0..1] OF INTEGER
>=3D3D3B = =3D
>=3D3D3B that woul=3D3D d perhaps not match how C handles "long long" on the = same
>=3D3D3B =3D platfor=3D3D m (which is how=3D3D2C come to think of it?)=3D3D2C and that would = =3D require
>=3D3D =3D3D3B special linkage tricks.
>=3D3D3B
>=3D3D3B But = what would =3D be lost? Th=3D3D e ability to type literals.
>=3D3D3B
>=3D3D3B You could = get =3D the same co=3D3D de interface on 32- and 64-bit machine by
>=3D3D3B =3D defining
>=3D3D3B
=3D3D >=3D3D3B TYPE FileOffset =3D3D3D ARRAY[0..1] OF [-16_80000000 .. = =3D +16_7fffffff ]>=3D3D3B
>=3D3D3B and using that.
>=3D3D3B =
>=3D3D3B =3D
>=3D3D3B Mika =3D3D =3D20 --_264cb69b-0215-44c3-807c-8b4d8ea0ea59_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Apr 19 23:29:26 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 19 Apr 2010 21:29:26 +0000 Subject: [M3devel] libm3/socket? In-Reply-To: References: <20100419173955.08CF82474003@birch.elegosoft.com>, Message-ID: Yeah.. anyone one m3devel using it? I guess we'll have to support it either way. The m3-comm/tcp stuff seems to be heavily "based" on it -- copy/paste. This stuff has ipv4 address in its public interface. That really made me not want to deal with it. Though the m3-comm stuff too. Pickles are bound to get broken by any sort of IPv6 support, unless maybe we make new interfaces for it. The new interfaces will work with IPv4 or IPv6. - Jay From: hosking at cs.purdue.edu Date: Mon, 19 Apr 2010 14:36:59 -0400 To: jkrell at elego.de CC: m3commit at elegosoft.com Subject: Re: [M3commit] CVS Update: cm3 Who's nobody? Just because there are no CM3 sources that use does not mean that there are no users out there. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 19 Apr 2010, at 19:39, Jay Krell wrote: CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/04/19 19:39:54 Modified files: cm3/m3-libs/libm3/src/os/Common/: m3makefile cm3/m3-libs/libm3/src/os/POSIX/: m3makefile cm3/m3-libs/libm3/src/os/WIN32/: m3makefile Removed files: cm3/m3-libs/libm3/src/os/Common/: Socket.i3 Socket.m3 cm3/m3-libs/libm3/src/os/POSIX/: SocketPosix.m3 SocketPosixC.c cm3/m3-libs/libm3/src/os/WIN32/: SocketWin32.m3 SocketWin32.m3.sav Log message: Nobody uses libm3's socket support. So empty it out instead of fixing it. Let's focus effort elsewhere, e.g. m3-comm/tcp. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.async.caltech.edu Tue Apr 20 00:31:52 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Mon, 19 Apr 2010 15:31:52 -0700 Subject: [M3devel] INTEGER In-Reply-To: References: , , , , <7C7408D0-9A40-4988-BADA-A9FD8C15D388@cs.purdue.edu>, , , , , , , , , , , , <20100418023535.3BA9E1A2103@async.async.caltech.edu>, , , , <20100418024703.6965B1A2103@async.async.caltech.edu>, , <20100418074927.934461A2117@async.async.caltech.edu>, <04EB7FF8-D304-428D-839E-233FCE009C98@cs.purdue.edu>, <20100418195901.CDACB1A20F6@async.async.caltech.edu>, , <20100419172313.68B241A20D6@async.async.caltech.edu>, <4F3EE437-0298-410B-9642-C0381E333430@cs.purdue.edu> Message-ID: <20100419223152.3D7331A2122@async.async.caltech.edu> Jay K writes: ... >Let me suggest a small exercise though: > > I'm not going to do it. > > Write a program that copies files. Or just one file. "cp.exe". > > Have it print "progress feedback" to the user -- how many bytes and percen= >tage copied. Leave out "time estimation". > > And also write "ls.exe". > > And maybe one last program=2C like "dos2unix.exe" or "fix_nl.exe" that alt= >ers newlines. This program should work on files that don't fit in memory. > I use the rdwrreset package under PM3. It solves the most glaring problems. But clearly the file sizes should be done with some sort of data structure different from 32-bit INTEGER. ARRAY [0..1] OF INTEGER seems to be a candidate... ... >Also think about what an idea representation of time is. > >Isn't a 64bit integer number of units smaller than a second a very good one= >? Modula-3 already uses floating point for this, which has the advantage you don't need to worry what the base is. > >And aren't infix operators darned nice? I have mixed feelings about this. Yes, but... every infix operator takes several lines of language definition. Those lines can turn into ungodly amounts of code somewhere. I actually do like Hendrik's idea of providing some sort of bignum support. The reason I don't like LONGINT as much is that it seems it's just a waste if we're all going to be using 64-bit machines anyhow. It's arbitrary to have two fixed-width types. Why not three or four? And why not 128 bits or 16 bits or 36 bits? If on the other hand you got something substantial out of it that might be another story. In that case, I would say LONGINT would be a reference type (much like TEXT) with its associated Longint interface, and infix operators (the way TEXT has &) per Jay's fondest dreams. Come to think of it, TEXT and such a LONGINT would have a lot in common. Mika From hosking at cs.purdue.edu Tue Apr 20 01:16:59 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 19 Apr 2010 19:16:59 -0400 Subject: [M3devel] libm3/socket? In-Reply-To: References: <20100419173955.08CF82474003@birch.elegosoft.com>, Message-ID: <13143F7F-3922-4D49-AB31-74F7E366DB4A@cs.purdue.edu> An opportunity to build a better abstraction... ;-) Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 19 Apr 2010, at 17:29, Jay K wrote: > Yeah.. anyone one m3devel using it? > > I guess we'll have to support it either way. > The m3-comm/tcp stuff seems to be heavily "based" on it -- copy/paste. > > This stuff has ipv4 address in its public interface. > That really made me not want to deal with it. > Though the m3-comm stuff too. > Pickles are bound to get broken by any sort of IPv6 support, unless maybe we make new interfaces for it. > The new interfaces will work with IPv4 or IPv6. > > - Jay > > > From: hosking at cs.purdue.edu > Date: Mon, 19 Apr 2010 14:36:59 -0400 > To: jkrell at elego.de > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > Who's nobody? > > Just because there are no CM3 sources that use does not mean that there are no users out there. > > Antony Hosking | Associate Professor | Computer Science | Purdue University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > On 19 Apr 2010, at 19:39, Jay Krell wrote: > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/04/19 19:39:54 > > Modified files: > cm3/m3-libs/libm3/src/os/Common/: m3makefile > cm3/m3-libs/libm3/src/os/POSIX/: m3makefile > cm3/m3-libs/libm3/src/os/WIN32/: m3makefile > Removed files: > cm3/m3-libs/libm3/src/os/Common/: Socket.i3 Socket.m3 > cm3/m3-libs/libm3/src/os/POSIX/: SocketPosix.m3 SocketPosixC.c > cm3/m3-libs/libm3/src/os/WIN32/: SocketWin32.m3 > SocketWin32.m3.sav > > Log message: > Nobody uses libm3's socket support. > So empty it out instead of fixing it. > Let's focus effort elsewhere, e.g. m3-comm/tcp. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Apr 20 01:57:43 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 19 Apr 2010 23:57:43 +0000 Subject: [M3devel] INTEGER In-Reply-To: <20100419223152.3D7331A2122@async.async.caltech.edu> References: , , , ,,<7C7408D0-9A40-4988-BADA-A9FD8C15D388@cs.purdue.edu>, , ,,, , , , , , , , , , , , , <20100418023535.3BA9E1A2103@async.async.caltech.edu>, ,,, , , <20100418024703.6965B1A2103@async.async.caltech.edu>, , , , <20100418074927.934461A2117@async.async.caltech.edu>, , <04EB7FF8-D304-428D-839E-233FCE009C98@cs.purdue.edu>, , <20100418195901.CDACB1A20F6@async.async.caltech.edu>, , , , <20100419172313.68B241A20D6@async.async.caltech.edu>, , <4F3EE437-0298-410B-9642-C0381E333430@cs.purdue.edu>, , <20100419223152.3D7331A2122@async.async.caltech.edu> Message-ID: > Modula-3 already uses floating point for this, which has the advantage > you don't need to worry what the base is. What do you mean not worry about the "base"? I'm not a fan of floating point. > support. The reason I don't like LONGINT as much is that it seems it's > just a waste if we're all going to be using 64-bit machines anyhow. Again, you might be right. C got 64bit integers ~18 years ago. We are late. Do you think phones and embedded devices will move to 64bits soon too? Are gaming consoles 64bits? > I use the rdwrreset package under PM3 Probably we should plunder PM3 for anything we are missing. > different from 32-bit INTEGER. ARRAY [0..1] OF INTEGER seems to be a > candidate... Again, aside, can such an array be made truly abstract? I'd like opaque data structures without forcing heap allocation. Because, you know, it is somewhat tricky how to deal with, and people will differ as to their assumptions of the order of the integers. There is a bignum package, I haven't looked into it. I find code quality tends to go down the higher level you look. e.g. libm3's socket stuff.. so I haven't looked at a lot, but I should. - Jay > To: jay.krell at cornell.edu > Date: Mon, 19 Apr 2010 15:31:52 -0700 > From: mika at async.async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] INTEGER > > Jay K writes: > ... > >Let me suggest a small exercise though: > > > > I'm not going to do it. > > > > Write a program that copies files. Or just one file. "cp.exe". > > > > Have it print "progress feedback" to the user -- how many bytes and percen= > >tage copied. Leave out "time estimation". > > > > And also write "ls.exe". > > > > And maybe one last program=2C like "dos2unix.exe" or "fix_nl.exe" that alt= > >ers newlines. This program should work on files that don't fit in memory. > > > > I use the rdwrreset package under PM3. It solves the most glaring problems. > But clearly the file sizes should be done with some sort of data structure > different from 32-bit INTEGER. ARRAY [0..1] OF INTEGER seems to be a > candidate... > > ... > >Also think about what an idea representation of time is. > > > >Isn't a 64bit integer number of units smaller than a second a very good one= > >? > > Modula-3 already uses floating point for this, which has the advantage > you don't need to worry what the base is. > > > > >And aren't infix operators darned nice? > > I have mixed feelings about this. Yes, but... every infix operator takes > several lines of language definition. Those lines can turn into ungodly > amounts of code somewhere. > > I actually do like Hendrik's idea of providing some sort of bignum > support. The reason I don't like LONGINT as much is that it seems it's > just a waste if we're all going to be using 64-bit machines anyhow. > It's arbitrary to have two fixed-width types. Why not three or four? > And why not 128 bits or 16 bits or 36 bits? If on the other hand > you got something substantial out of it that might be another story. > In that case, I would say LONGINT would be a reference type (much like > TEXT) with its associated Longint interface, and infix operators (the > way TEXT has &) per Jay's fondest dreams. Come to think of it, > TEXT and such a LONGINT would have a lot in common. > > Mika -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.async.caltech.edu Tue Apr 20 02:09:58 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Mon, 19 Apr 2010 17:09:58 -0700 Subject: [M3devel] INTEGER In-Reply-To: References: , , , , , <7C7408D0-9A40-4988-BADA-A9FD8C15D388@cs.purdue.edu>, , , , , , , , , , , , , , , , , <20100418023535.3BA9E1A2103@async.async.caltech.edu>, , , , , , <20100418024703.6965B1A2103@async.async.caltech.edu>, , , , <20100418074927.934461A2117@async.async.caltech.edu>, , <04EB7FF8-D304-428D-839E-233FCE009C98@cs.purdue.edu>, , <20100418195901.CDACB1A20F6@async.async.caltech.edu>, , , , <20100419172313.68B241A20D6@async.async.caltech.edu>, , <4F3EE437-0298-410B-9642-C0381E333430@cs.purdue.edu>, , <20100419223152.3D7331A2122@async.async. caltech.edu> Message-ID: <20100420000958.7F5991A2122@async.async.caltech.edu> Jay K writes: >--_747381e9-b91f-4765-9877-7c09d53c76c7_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > Modula-3 already uses floating point for this=2C which has the advantage > > you don't need to worry what the base is.=20 > >=20 > >What do you mean not worry about the "base"? > >I'm not a fan of floating point. If you use integer counts of some small interval, that small interval is what I mean has to be specified somewhere. There's nothing much wrong with floating point. It works fine and Time.T can certainly represent intervals much smaller than a second using any reasonable epoch (almost the age of the universe, I think). > >=20 > >=20 > >> support. The reason I don't like LONGINT as much is that it seems it's >> just a waste if we're all going to be using 64-bit machines anyhow. > > >=20 > >Again=2C you might be right. C got 64bit integers ~18 years ago. We are lat= >e. > >Do you think phones and embedded devices will move to 64bits soon too? > >Are gaming consoles 64bits? No, but again the fact that C does something is not a good reason for us to do it. We need a new language type just to deal with file lengths? I think not. That's the only real use case I've seen so far...? > >Again=2C aside=2C can such an array be made truly abstract? > > I'd like opaque data structures without forcing heap allocation. > >Because=2C you know=2C it is somewhat tricky how to deal with=2C and people > >will differ as to their assumptions of the order of the integers. > Of course it has to be little endian. Mika From jay.krell at cornell.edu Tue Apr 20 02:01:44 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 20 Apr 2010 00:01:44 +0000 Subject: [M3devel] libm3/socket? In-Reply-To: <13143F7F-3922-4D49-AB31-74F7E366DB4A@cs.purdue.edu> References: <20100419173955.08CF82474003@birch.elegosoft.com>, , , , <13143F7F-3922-4D49-AB31-74F7E366DB4A@cs.purdue.edu> Message-ID: Do you think we should leave this one exactly asis, and anyone wanting IPv6 must move to a new abstraction? Or should we provide some partial source (in)compatibility but keep everything in interface Socket. I do believe, btw, that code should work with either IPv4 or v6, or even for that matter IPX. Just pass strings along and let layers below you figure it out. I wouldn't want to introduce Socket6 that only works with IPv6. The likely abstraction therefore is Address = TEXT. << I'm also not sure, but my rough reading of IPv6 stuff is that you don't call socket() until after you resolve the string -- getaddrinfo returns a list of families, so you can't just pass one to socket() and be done. That is, the current separation of Create/Bind/Connect/Accept is a bit off. It can be preserved, but Create wouldn't actually call socket(), it'd just store stream or dgram and put off the rest till Connect/Bind/Listen/Accept (probably just two of the four, when I really know what does what..) - Jay From: hosking at cs.purdue.edu Date: Mon, 19 Apr 2010 19:16:59 -0400 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] libm3/socket? An opportunity to build a better abstraction... ;-) Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 19 Apr 2010, at 17:29, Jay K wrote: Yeah.. anyone one m3devel using it? I guess we'll have to support it either way. The m3-comm/tcp stuff seems to be heavily "based" on it -- copy/paste. This stuff has ipv4 address in its public interface. That really made me not want to deal with it. Though the m3-comm stuff too. Pickles are bound to get broken by any sort of IPv6 support, unless maybe we make new interfaces for it. The new interfaces will work with IPv4 or IPv6. - Jay From: hosking at cs.purdue.edu Date: Mon, 19 Apr 2010 14:36:59 -0400 To: jkrell at elego.de CC: m3commit at elegosoft.com Subject: Re: [M3commit] CVS Update: cm3 Who's nobody? Just because there are no CM3 sources that use does not mean that there are no users out there. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 19 Apr 2010, at 19:39, Jay Krell wrote: CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/04/19 19:39:54 Modified files: cm3/m3-libs/libm3/src/os/Common/: m3makefile cm3/m3-libs/libm3/src/os/POSIX/: m3makefile cm3/m3-libs/libm3/src/os/WIN32/: m3makefile Removed files: cm3/m3-libs/libm3/src/os/Common/: Socket.i3 Socket.m3 cm3/m3-libs/libm3/src/os/POSIX/: SocketPosix.m3 SocketPosixC.c cm3/m3-libs/libm3/src/os/WIN32/: SocketWin32.m3 SocketWin32.m3.sav Log message: Nobody uses libm3's socket support. So empty it out instead of fixing it. Let's focus effort elsewhere, e.g. m3-comm/tcp. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Apr 20 02:43:25 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 20 Apr 2010 00:43:25 +0000 Subject: [M3devel] INTEGER In-Reply-To: <20100420000958.7F5991A2122@async.async.caltech.edu> References: , , , , ,,<7C7408D0-9A40-4988-BADA-A9FD8C15D388@cs.purdue.edu>, , , ,,, , , , , , , , , , , , , , , , , <20100418023535.3BA9E1A2103@async.async.caltech.edu>, , ,,, , ,,<20100418024703.6965B1A2103@async.async.caltech.edu>, ,,, ,,<20100418074927.934461A2117@async.async.caltech.edu>, ,,<04EB7FF8-D304-428D-839E-233FCE009C98@cs.purdue.edu>, ,,<20100418195901.CDACB1A20F6@async.async.caltech.edu>, ,,, ,,<20100419172313.68B241A20D6@async.async.caltech.edu>, , , <4F3EE437-0298-410B-9642-C0381E333430@cs.purdue.edu>, , , , <20100419223152.3D7331A2122@async.async., caltech.edu> , <20100420000958.7F5991A2122@async.async.caltech.edu> Message-ID: > If you use integer counts of some small interval, that small interval > is what I mean has to be specified somewhere. There would be one and only interval for all time measurements. => Whatever NT uses. 10s of nanoseconds I believe. Isn't that similar to saying you have to specify it is seconds? Or seconds is easier to remember and understand? NT's unit is a little difficult for me, granted. > There's nothing much wrong with floating point. It works fine and Time.T > can certainly represent intervals much smaller than a second using any > reasonable epoch (almost the age of the universe, I think). Does Time.T have a large range actually? I haven't figured it out. And are negative times allowed? If no negative times, then not a wide range. > No, but again the fact that C does something is not a good reason for us to do > it. We need a new language type just to deal with file lengths? I think not. > That's the only real use case I've seen so far...? National debt as an integer? I don't know if there are other uses. > Of course it has to be little endian. That's what I think, but I might just be corrupted. It still needs to abstract/opaque, though, so people don't get confused about the lower bits being unsigned, for example. gotta run, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Tue Apr 20 04:46:16 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Mon, 19 Apr 2010 21:46:16 -0500 Subject: [M3devel] INTEGER (and floating point) In-Reply-To: <20100419223152.3D7331A2122@async.async.caltech.edu> References: , , , , , , , , , , , , , <20100418023535.3BA9E1A2103@async.async.caltech.edu>, , , , <20100418024703.6965B1A2103@async.async.caltech.edu>, , <20100418074927.934461A2117@async.async.caltech.edu>, <04EB7FF8-D304-428D-839E-233FCE009C98@cs.purdue.edu>, <20100418195901.CDACB1A20F6@async.async.caltech.edu>, , <20100419172313.68B241A20D6@async.async.caltech.edu>, <4F3EE437-0298-410B-9642-C0381E333430@cs.purdue.edu> <20100419223152.3D7331A2122@async.async.caltech.edu> Message-ID: <4BCD1578.3050900@lcwb.coop> Mika Nystrom wrote: > > Modula-3 already uses floating point for this, which has the advantage > you don't need to worry what the base is. The designers of Algol 60 gave us several good new ideas, but one place they did a huge disservice was in renaming what had been called "floating point" as "real". This was and still is a lie. One ugly property that floating point has is that the smallest interval between representable values keeps getting larger as the value gets larger. Moreover, for representations of equal bit counts, floating will always eventually get to the point that it no longer can even represent the integers. The interval eventually becomes two, then four, eight, etc. (if the exponent is a power of two, as it usually is). There are places where you care about large value range *and* precision down to the integers, and file sizes are likely to be one of them. National budgets might be too. Ditto times. Sometimes you can stand the erosion of precision in large values, but not always. Of course, if you compare a 32-bit integer to a 64-bit float, this won't happen. But I think the 64-bit float should be compared to a 64-bit integer. > Mika > From hendrik at topoi.pooq.com Tue Apr 20 01:52:12 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 19 Apr 2010 19:52:12 -0400 Subject: [M3devel] INTEGER In-Reply-To: References: <20100419155702.GB8759@topoi.pooq.com> Message-ID: <20100419235212.GA10670@topoi.pooq.com> On Mon, Apr 19, 2010 at 09:20:00PM +0000, Jay K wrote: > > For the record, anyone using Windows (NT/2000/XP/2003/etc.) is using 16bit characters *all the time*. > > MacOSX maybe also. > > I think utf8 is kind of a hack to let folks get away without really doing anything. > > Granted, I didn't realize till recently that strcmp works on > utf8..maybe a really clever idea.. utf8 was a really clever idea. Unless you need to isolate specific characters and do something with them, most code manipulating text needn't care whether it's UTF8 or not. -- hendrik From jay.krell at cornell.edu Tue Apr 20 07:34:10 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 20 Apr 2010 05:34:10 +0000 Subject: [M3devel] INTEGER (and floating point) In-Reply-To: <4BCD1578.3050900@lcwb.coop> References: , , , ,,, , , , , , , , , , , , , <20100418023535.3BA9E1A2103@async.async.caltech.edu>, ,,, , , <20100418024703.6965B1A2103@async.async.caltech.edu>, , , , <20100418074927.934461A2117@async.async.caltech.edu>, , <04EB7FF8-D304-428D-839E-233FCE009C98@cs.purdue.edu>, , <20100418195901.CDACB1A20F6@async.async.caltech.edu>, , , , <20100419172313.68B241A20D6@async.async.caltech.edu>, , <4F3EE437-0298-410B-9642-C0381E333430@cs.purdue.edu> , <20100419223152.3D7331A2122@async.async.caltech.edu>, <4BCD1578.3050900@lcwb.coop> Message-ID: Floating point is just wierd. very large + very small = the same very large I realize that is approximately correct, but approximations can be worrisome. And it can be costly to avoid making them as well. Stuck. > Of course, if you compare a 32-bit integer to a 64-bit float, this > won't happen. But I think the 64-bit float should be compared to > a 64-bit integer. Eh? A 64bit float cannot store all 64bit integer values. Typically 64bit float has about 53bits of precision. Local float.h: #define DBL_MANT_DIG 53 /* # of bits in mantissa */ #define FLT_MANT_DIG 24 /* # of bits in mantissa */ Now, interestingly, the IA64 floating point registers are large enough, they do have at least 64bits of precision, and integer division/mod is implemented using floating point. I was surprised to step through my hash table code and see floating point used. :) - Jay > Date: Mon, 19 Apr 2010 21:46:16 -0500 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: Re: [M3devel] INTEGER (and floating point) > > > > Mika Nystrom wrote: > > > > Modula-3 already uses floating point for this, which has the advantage > > you don't need to worry what the base is. > > The designers of Algol 60 gave us several good new ideas, but one place > they did a huge disservice was in renaming what had been called "floating > point" as "real". This was and still is a lie. > > One ugly property that floating point has is that the smallest interval > between representable values keeps getting larger as the value gets > larger. Moreover, for representations of equal bit counts, floating > will always eventually get to the point that it no longer can even represent > the integers. The interval eventually becomes two, then four, eight, > etc. (if the exponent is a power of two, as it usually is). > > There are places where you care about large value range *and* precision > down to the integers, and file sizes are likely to be one of them. > National budgets might be too. Ditto times. Sometimes you can stand > the erosion of precision in large values, but not always. > > Of course, if you compare a 32-bit integer to a 64-bit float, this > won't happen. But I think the 64-bit float should be compared to > a 64-bit integer. > > > Mika > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Tue Apr 20 17:29:42 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Tue, 20 Apr 2010 10:29:42 -0500 Subject: [M3devel] INTEGER In-Reply-To: <20100419223152.3D7331A2122@async.async.caltech.edu> References: , , , , , , , , , , , , , <20100418023535.3BA9E1A2103@async.async.caltech.edu>, , , , <20100418024703.6965B1A2103@async.async.caltech.edu>, , <20100418074927.934461A2117@async.async.caltech.edu>, <04EB7FF8-D304-428D-839E-233FCE009C98@cs.purdue.edu>, <20100418195901.CDACB1A20F6@async.async.caltech.edu>, , <20100419172313.68B241A20D6@async.async.caltech.edu>, <4F3EE437-0298-410B-9642-C0381E333430@cs.purdue.edu> <20100419223152.3D7331A2122@async.async.caltech.edu> Message-ID: <4BCDC866.6050804@lcwb.coop> The designers of Modula-3 gave use not one but three floating point types. They explicitly justified this as matching the range of hardware arithmetic provided by set of common processors of the day. They didn't say this (to my knowledge), but one integer type also matched the hardware of the day. But the period when practically all processors had the same word size was a historical anomaly. It was a nice halcyon time in that respect, and it allowed us to avoid some messy problems. But it never was true prior to that era, and it is no longer true. I doubt it will be again. Despite the proliferation of 64-bit machines, there will be useful 32-bit ones around for a years. Not everybody buys the newest every three years, and 32 bits is still capable of a lot. I don't see them being retired at anything like the rate 16-bit machines were, because they don't suffer the limitations. And then we have the proliferation of embedded and hand-held devices, which as I am hearing, are already well out ahead of server and desktop computers in raw processor count. So I think keeping two integer sizes in the language removes what many people would consider a serious obstacle. Moreover, the way the two integer sizes is are now defined is cleaner than I have seen in any other language. It also somewhat follows the way the three floating types were done in the original language in that it preserves the type-uniqueness of every expression. It further makes the static legality and semantics of code as close to implementation-independent as it was in the unmodified language. And it does not change the legality or static semantics of any old code. Mika Nystrom wrote: > > I actually do like Hendrik's idea of providing some sort of bignum > support. The reason I don't like LONGINT as much is that it seems it's > just a waste if we're all going to be using 64-bit machines anyhow. > It's arbitrary to have two fixed-width types. Why not three or four? > And why not 128 bits or 16 bits or 36 bits? If on the other hand > you got something substantial out of it that might be another story. > In that case, I would say LONGINT would be a reference type (much like > TEXT) with its associated Longint interface, and infix operators (the > way TEXT has &) per Jay's fondest dreams. Come to think of it, > TEXT and such a LONGINT would have a lot in common. > > Mika > From rodney_bates at lcwb.coop Tue Apr 20 17:59:57 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Tue, 20 Apr 2010 10:59:57 -0500 Subject: [M3devel] INTEGER In-Reply-To: <20100419155702.GB8759@topoi.pooq.com> References: <20100418024703.6965B1A2103@async.async.caltech.edu> <20100418074927.934461A2117@async.async.caltech.edu> <04EB7FF8-D304-428D-839E-233FCE009C98@cs.purdue.edu> <20100418195901.CDACB1A20F6@async.async.caltech.edu> <20100419155702.GB8759@topoi.pooq.com> Message-ID: <4BCDCF7D.604@lcwb.coop> hendrik at topoi.pooq.com wrote: > On Sun, Apr 18, 2010 at 12:59:01PM -0700, Mika Nystrom wrote: >> And the new m3tk, stubgen, and compiler(?) won't compile using PM3 or >> SRC M3 since we're no longer using the language of the Green Book. >> (Same comment goes for WIDECHAR, by the way.) > > When I use Unicode characters, I find myself defining them to be > INTEGERs, because I'm always worried that WIDECHARs might be omly 16 bits. Actually, I favor making WIDECHAR big enough to hold all the defined Unicode values, which I understand have been more that 2^16 for some time now. The only thing the language definition says about WIDECHAR is that it has at least 65536 values and the first 65536 correspond to the first 65536 Unicode characters. It could be bigger. Moreover, as I recall from a while back, the compiler, old and new Text implementation, other libraries, m3gdb, and maybe pickles are only a couple of declaration changes away from supporting some bigger range for WIDECHAR. (I think I am the one who put WIDECHAR into the language reference, and that was only recently, despite its being in the cm3 language for years. I also see that this has not propagated from the .tex version into the .html and .pdf files.) > > Strings of WIDECHARS are probably unnecesary. The last program I wrote > that used Unicode used INTEGERs for characters, and arrays of INTEGERS > for strings. But I think it was a mistake to do it this way, and when I > have time I'll rewrite it. UTF-8 seems to be the way to go; strings of > Unicode can easily be manipulated as ordinary TEXT. In fact, I > think there are few if any places in my code where I would have had to > do anything special whatsoever if I had just used UTF8 in TEXT. The > program would simply become simpler. This is only true if you handle strings in certain common but restricted ways. If you just move strings around, UTF-8 will often work with little or no code change. OTOH, if you need to access characters non-sequentially or make any examination or production of individual characters not in the Iso-latin-1 subset, any variable-length encoding quickly becomes unworkable. Text.Sub and Text.GetChar won't work in any sensible way if they view the string as a string of 8-bit bytes, when it's actually not. Reimplementing these to understand UTF-8 would make what was O(1) become O(n). Ditto Text.Length. > > -- hendrik > From jay.krell at cornell.edu Tue Apr 20 18:59:53 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 20 Apr 2010 16:59:53 +0000 Subject: [M3devel] INTEGER In-Reply-To: <4BCDC866.6050804@lcwb.coop> References: , , , ,,, , , , , , , , , , , , , <20100418023535.3BA9E1A2103@async.async.caltech.edu>, ,,, , , <20100418024703.6965B1A2103@async.async.caltech.edu>, , , , <20100418074927.934461A2117@async.async.caltech.edu>, , <04EB7FF8-D304-428D-839E-233FCE009C98@cs.purdue.edu>, , <20100418195901.CDACB1A20F6@async.async.caltech.edu>, , , , <20100419172313.68B241A20D6@async.async.caltech.edu>, , <4F3EE437-0298-410B-9642-C0381E333430@cs.purdue.edu> , <20100419223152.3D7331A2122@async.async.caltech.edu>, <4BCDC866.6050804@lcwb.coop> Message-ID: Thank you Rodney. Good, interesting points. > and 32 bits is still capable of a lot Agreed. There is an interesting construct that seems common -- 64bit kernels that can run 32bit or 64bit usermode code. That is what NT looks like, and Solaris, and Linux on sparc, and Irix (obsolete thought it may be..), and AIX, and HP-UX, and at least some configurations of Mac. In particular I read that sparc32 is quite obsolete from the Linux kernel point of view, there is no 32bit sparc Linux kernel, but 32bit usermode code is still fine. There is probably some correlation to like "systems that moved to 64bit processors earlier provide better support for 32bit usermode", and "systems that moved to 64bit processors later see 32bit support as more temporary". ie. commercial Unix moved to 64bit first, NT and free Unix later. OpenBSD is "pure", they only ever support one "architecture". The seeming "problem" (not a problem in this context) is managing multiple GB of cheap physical RAM across an entire physical system. The overall system these days can have so much memory, but individual processes don't necessarily need it. As well, people often speak of 64bit being slower due to larger pointers, larger data. As well as larger code to load 64bit values. x86 is a bit of anomaly here in that the widening to 64bits also "cleaned up" a lot -- added many more registers not just wider registers, established a baseline for a different floating point instruction set (SSE), easier to generate position independent code via RIP-relative addressing, and at least on NT a better model for exception handling. So x86 switching to 64bit is a better sell than others. But still has the larger pointers/data. So you know, what size buffer do I need to hold the concatenation of two strings whose maximum length is 100? Or what size integer do I need to hold the result of multiplying two n bit integers? The kernel overarches all pieces/processes and needs perhaps larger capacity to handle it all than the pieces themselves need. > proliferation of embedded and hand-held devices, which as I am > hearing, are already well out ahead of server and desktop computers in raw processor count I heard this over 10 years ago, that embedded systems ship far more processors than "computers", though it was lower end devices -- cars, microwaves, digital watches. This world lingered in programming in assembly and using cheaper 8 and 16bit CPUs and MMU-less hardware longer. Manufacturing in such large volume, it was worth saving money. Nowadays we hear about them all being 32bit and having MMUs (e.g. phones). > Not everybody buys the newest every three years We are closer to 7 years into AMD64 though. :) Except then 32bit came back -- Atom. :) - Jay > Date: Tue, 20 Apr 2010 10:29:42 -0500 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: Re: [M3devel] INTEGER > > The designers of Modula-3 gave use not one but three floating point types. > They explicitly justified this as matching the range of hardware arithmetic > provided by set of common processors of the day. > > They didn't say this (to my knowledge), but one integer type also matched > the hardware of the day. But the period when practically all processors > had the same word size was a historical anomaly. It was a nice halcyon > time in that respect, and it allowed us to avoid some messy problems. > > But it never was true prior to that era, and it is no longer true. > I doubt it will be again. Despite the proliferation of 64-bit > machines, there will be useful 32-bit ones around for a years. > Not everybody buys the newest every three years, and 32 bits is > still capable of a lot. I don't see them being retired at anything > like the rate 16-bit machines were, because they don't suffer the > limitations. And then we have the proliferation of embedded and > hand-held devices, which as I am hearing, are already well out ahead > of server and desktop computers in raw processor count. > > So I think keeping two integer sizes in the language removes what > many people would consider a serious obstacle. Moreover, the way > the two integer sizes is are now defined is cleaner than I have > seen in any other language. It also somewhat follows the way the > three floating types were done in the original language in that > it preserves the type-uniqueness of every expression. It further > makes the static legality and semantics of code as close to > implementation-independent as it was in the unmodified language. > And it does not change the legality or static semantics of any > old code. > > Mika Nystrom wrote: > > > > I actually do like Hendrik's idea of providing some sort of bignum > > support. The reason I don't like LONGINT as much is that it seems it's > > just a waste if we're all going to be using 64-bit machines anyhow. > > It's arbitrary to have two fixed-width types. Why not three or four? > > And why not 128 bits or 16 bits or 36 bits? If on the other hand > > you got something substantial out of it that might be another story. > > In that case, I would say LONGINT would be a reference type (much like > > TEXT) with its associated Longint interface, and infix operators (the > > way TEXT has &) per Jay's fondest dreams. Come to think of it, > > TEXT and such a LONGINT would have a lot in common. > > > > Mika > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.async.caltech.edu Tue Apr 20 19:12:35 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Tue, 20 Apr 2010 10:12:35 -0700 Subject: [M3devel] INTEGER In-Reply-To: <4BCDC866.6050804@lcwb.coop> References: , , , , , , , , , , , , , <20100418023535.3BA9E1A2103@async.async.caltech.edu>, , , , <20100418024703.6965B1A2103@async.async.caltech.edu>, , <20100418074927.934461A2117@async.async.caltech.edu>, <04EB7FF8-D304-428D-839E-233FCE009C98@cs.purdue.edu>, <20100418195901.CDACB1A20F6@async.async.caltech.edu>, , <20100419172313.68B241A20D6@async.async.caltech.edu>, <4F3EE437-0298-410B-9642-C0381E333430@cs.purdue.edu> <20100419223152.3D7331A2122@async.async.caltech.edu> <4BCDC866.6050804@lcwb.coop> Message-ID: <20100420171235.B8F0C1A2103@async.async.caltech.edu> "Rodney M. Bates" writes: >The designers of Modula-3 gave use not one but three floating point types. >They explicitly justified this as matching the range of hardware arithmetic >provided by set of common processors of the day. > >They didn't say this (to my knowledge), but one integer type also matched >the hardware of the day. But the period when practically all processors >had the same word size was a historical anomaly. It was a nice halcyon >time in that respect, and it allowed us to avoid some messy problems. > >But it never was true prior to that era, and it is no longer true. >I doubt it will be again. Despite the proliferation of 64-bit >machines, there will be useful 32-bit ones around for a years. >Not everybody buys the newest every three years, and 32 bits is >still capable of a lot. I don't see them being retired at anything >like the rate 16-bit machines were, because they don't suffer the >limitations. And then we have the proliferation of embedded and >hand-held devices, which as I am hearing, are already well out ahead >of server and desktop computers in raw processor count. > >So I think keeping two integer sizes in the language removes what >many people would consider a serious obstacle. Moreover, the way >the two integer sizes is are now defined is cleaner than I have >seen in any other language. It also somewhat follows the way the >three floating types were done in the original language in that >it preserves the type-uniqueness of every expression. It further >makes the static legality and semantics of code as close to >implementation-independent as it was in the unmodified language. >And it does not change the legality or static semantics of any >old code. I agree LONGINT isn't horrible. However, I am not sure I agree with your description above. 1. Modula-3 provides three floating-point formats because *each* common processor architecture provided (and provides) support for generally at least three floating-point formats. The point was to give programmers easy access to the hardware in their own machines, not really so that IBM programmers could have an extra format for VAX compatibility. Note that I don't believe that it was intended that EXTENDED would be emulated by the compiler either: the point was really to give programmers access to the formats provided efficiently by their hardware. 2. 64-bit machines don't actually get two different integer formats with the way LONGINT works. INTEGER and LONGINT are both 64 bits. That was not the intention with the floating-point formats either. 3. 64-bit machines were hardly unforeseen by DEC's research people, given that their company introduced Alpha just after Modula-3 and that DECWRL across town was working on 64-bit ECL machines. In fact I think Modula-3 had versions with 64-bit INTEGERs already in 1992? (To use Jay's expression, it's now 18 years later, and many C environments still haven't caught up---int is still 32 bits in many of them!) People at SRC surely had a lot of 64-bit machines with Modula-3 programs running on them in the early 90s. Somehow the problem of representing 64-bit integers on older VAX, MIPS, i386 systems just didn't arise for them? 4. I still haven't seen any really convincing use cases. What's it for? The lack of LONGINT was an obstacle to what, precisely? 5. Finally, is it the intention that LONGINT be fixed at 64 bits forevermore? (See point 2.) This seems to completely fly in the face of M3's philosophy. (See Hendrik's arguments.) Mika From hosking at cs.purdue.edu Tue Apr 20 19:31:45 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 20 Apr 2010 13:31:45 -0400 Subject: [M3devel] INTEGER In-Reply-To: <20100420171235.B8F0C1A2103@async.async.caltech.edu> References: , , , , , , , , , , , , , <20100418023535.3BA9E1A2103@async.async.caltech.edu>, , , , <20100418024703.6965B1A2103@async.async.caltech.edu>, , <20100418074927.934461A2117@async.async.caltech.edu>, <04EB7FF8-D304-428D-839E-233FCE009C98@cs.purdue.edu>, <20100418195901.CDACB1A20F6@async.async.caltech.edu>, , <20100419172313.68B241A20D6@async.async.caltech.edu>, <4F3EE437-0298-410B-9642-C0381E333430@cs.purdue.edu> <20100419223152.3D7331A2122@async.async.caltech.edu> <4BCDC866.6050804@lcwb.coop> <20100420171235! .B8F0C1A2103@async.async.caltech.edu> Message-ID: On 20 Apr 2010, at 13:12, Mika Nystrom wrote: > "Rodney M. Bates" writes: >> The designers of Modula-3 gave use not one but three floating point types. >> They explicitly justified this as matching the range of hardware arithmetic >> provided by set of common processors of the day. >> >> They didn't say this (to my knowledge), but one integer type also matched >> the hardware of the day. But the period when practically all processors >> had the same word size was a historical anomaly. It was a nice halcyon >> time in that respect, and it allowed us to avoid some messy problems. >> >> But it never was true prior to that era, and it is no longer true. >> I doubt it will be again. Despite the proliferation of 64-bit >> machines, there will be useful 32-bit ones around for a years. >> Not everybody buys the newest every three years, and 32 bits is >> still capable of a lot. I don't see them being retired at anything >> like the rate 16-bit machines were, because they don't suffer the >> limitations. And then we have the proliferation of embedded and >> hand-held devices, which as I am hearing, are already well out ahead >> of server and desktop computers in raw processor count. >> >> So I think keeping two integer sizes in the language removes what >> many people would consider a serious obstacle. Moreover, the way >> the two integer sizes is are now defined is cleaner than I have >> seen in any other language. It also somewhat follows the way the >> three floating types were done in the original language in that >> it preserves the type-uniqueness of every expression. It further >> makes the static legality and semantics of code as close to >> implementation-independent as it was in the unmodified language. >> And it does not change the legality or static semantics of any >> old code. > > I agree LONGINT isn't horrible. However, I am not sure I agree > with your description above. > > 1. Modula-3 provides three floating-point formats because *each* common > processor architecture provided (and provides) support for generally at > least three floating-point formats. The point was to give programmers > easy access to the hardware in their own machines, not really so that IBM > programmers could have an extra format for VAX compatibility. Note that > I don't believe that it was intended that EXTENDED would be emulated by > the compiler either: the point was really to give programmers access to > the formats provided efficiently by their hardware. In the current implementation EXTENDED=LONGREAL. > 2. 64-bit machines don't actually get two different integer formats > with the way LONGINT works. INTEGER and LONGINT are both 64 bits. > That was not the intention with the floating-point formats either. Current implementation, yes, but this is not fixed. > 3. 64-bit machines were hardly unforeseen by DEC's research people, > given that their company introduced Alpha just after Modula-3 and that > DECWRL across town was working on 64-bit ECL machines. In fact I think > Modula-3 had versions with 64-bit INTEGERs already in 1992? (To use > Jay's expression, it's now 18 years later, and many C environments still > haven't caught up---int is still 32 bits in many of them!) People at > SRC surely had a lot of 64-bit machines with Modula-3 programs running > on them in the early 90s. Somehow the problem of representing 64-bit > integers on older VAX, MIPS, i386 systems just didn't arise for them? Yep. Love my Alpha so much I can't bear to throw it away. > 4. I still haven't seen any really convincing use cases. What's it for? > The lack of LONGINT was an obstacle to what, precisely? I think the only one we have is file sizes... > 5. Finally, is it the intention that LONGINT be fixed at 64 bits > forevermore? (See point 2.) This seems to completely fly in the face > of M3's philosophy. (See Hendrik's arguments.) The only constraint imposed is BITSIZE(LONGINT) >= BITSIZE(INTEGER). > > Mika > > > From jay.krell at cornell.edu Tue Apr 20 20:05:25 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 20 Apr 2010 18:05:25 +0000 Subject: [M3devel] INTEGER In-Reply-To: <20100420171235.B8F0C1A2103@async.async.caltech.edu> References: , , , ,,, , , , , , , , , , , , , <20100418023535.3BA9E1A2103@async.async.caltech.edu>, ,,, , , <20100418024703.6965B1A2103@async.async.caltech.edu>, , , , <20100418074927.934461A2117@async.async.caltech.edu>, , <04EB7FF8-D304-428D-839E-233FCE009C98@cs.purdue.edu>, , <20100418195901.CDACB1A20F6@async.async.caltech.edu>, , , , <20100419172313.68B241A20D6@async.async.caltech.edu>, , <4F3EE437-0298-410B-9642-C0381E333430@cs.purdue.edu>, , <20100419223152.3D7331A2122@async.async.caltech.edu>, <4BCDC866.6050804@lcwb.coop>, <20100420171235.B8F0C1A2103@async.async.caltech.edu> Message-ID: > (To use Jay's expression, it's now 18 years later, and > many C environments still haven't caught up---int is still 32 bits in many of them!) Int is 32 bits in almost every C environment. Maybe some Cray has 64bit int. But every system I've seen has 32 bit (or 16 bit) int. Do any C environments lack a 64bit "long" or "long long" or "__int64"? I believe gcc is written to not depend on any 64bit integer or "long long" being guaranteed available, so it can compile with a compiler that only has up to "long", be it 32bits or 64bits. I believe they represent 64bit integers internally as a pair of longs and always take 32bits from each. It is a little confusing but also makes sense. On systems with 64bit long, which there are many of, they waste space. It'd seem better to use a pair of 32bits ints or one 64bit long or long long. But it is portable, even if int is 16 bits. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.async.caltech.edu Tue Apr 20 20:07:15 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Tue, 20 Apr 2010 11:07:15 -0700 Subject: [M3devel] INTEGER In-Reply-To: References: , , , , , , , , , , , , , <20100418023535.3BA9E1A2103@async.async.caltech.edu>, , , , <20100418024703.6965B1A2103@async.async.caltech.edu>, , <20100418074927.934461A2117@async.async.caltech.edu>, <04EB7FF8-D304-428D-839E-233FCE009C98@cs.purdue.edu>, <20100418195901.CDACB1A20F6@async.async.caltech.edu>, , <20100419172313.68B241A20D6@async.async.caltech.edu>, <4F3EE437-0298-410B-9642-C0381E333430@cs.purdue.edu> <20100419223152.3D7331A2122@async.async.caltech.edu> <4BCDC866.6050804@lcwb.coop> <20100420171235! .B8F0C1A2103@async.async.caltech.edu> Message-ID: <20100420180715.52C391A2103@async.async.caltech.edu> Tony Hosking writes: >On 20 Apr 2010, at 13:12, Mika Nystrom wrote: ... >> easy access to the hardware in their own machines, not really so that = >IBM >> programmers could have an extra format for VAX compatibility. Note = >that >> I don't believe that it was intended that EXTENDED would be emulated = >by >> the compiler either: the point was really to give programmers access = >to >> the formats provided efficiently by their hardware. > >In the current implementation EXTENDED=3DLONGREAL. Ok, but EXTENDED is still something that is efficiently provided by my hardware. Not something efficiently provided by someone else's hardware! >> 4. I still haven't seen any really convincing use cases. What's it = >for? >> The lack of LONGINT was an obstacle to what, precisely? > >I think the only one we have is file sizes... > >> 5. Finally, is it the intention that LONGINT be fixed at 64 bits >> forevermore? (See point 2.) This seems to completely fly in the face >> of M3's philosophy. (See Hendrik's arguments.) > >The only constraint imposed is BITSIZE(LONGINT) >=3D BITSIZE(INTEGER). I am not so sure here. Rodney's argument has in fact convinced me that the current version of LONGINT is wrong and perhaps evil. It should either go away completely or be replaced by Hendrik's suggestion. Here's why. The argument is that if I have an N-bit machine, for N References: , , , , , , , , , , , , , <20100418023535.3BA9E1A2103@async.async.caltech.edu>, , , , <20100418024703.6965B1A2103@async.async.caltech.edu>, , <20100418074927.934461A2117@async.async.caltech.edu>, <04EB7FF8-D304-428D-839E-233FCE009C98@cs.purdue.edu>, <20100418195901.CDACB1A20F6@async.async.caltech.edu>, , <20100419172313.68B241A20D6@async.async.caltech.edu>, <4F3EE437-0298-410B-9642-C0381E333430@cs.purdue.edu> <20100419223152.3D7331A2122@async.async.caltech.edu> <4BCDC866.6050804@lcwb.coop> <20100420171235.B8F0C1A2103@async.async.caltech.edu> Message-ID: >-----Original Message----- >From: Mika Nystrom [mailto:mika at async.async.caltech.edu] >Sent: Tuesday, April 20, 2010 1:13 PM > >5. Finally, is it the intention that LONGINT be fixed at 64 bits >forevermore? (See point 2.) This seems to completely fly in the face >of M3's philosophy. (See Hendrik's arguments.) > Mika My "understanding" was that LONGINT would be a MINimum of 64-bits, but could be larger on certain platforms. For those platforms where the native integer size is already 64-bits, it could be possible that BITSIZE of INTEGER and LONGINT are indeed the same, 64-bits. It could also be that on some platforms we could have 64-bit INTEGER and maybe 128-bit LONGINT. Thus, the BITSIZE of LONGINT is both platform and implementation-dependent, but constrained to have a lower-bound of 64-bits. If I'm not understanding this correctly, someone please enlighten me. --Randy CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This email may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from reviewing, copying, using, disclosing or distributing to others the information in this email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require advance export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. From jay.krell at cornell.edu Tue Apr 20 23:36:12 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 20 Apr 2010 21:36:12 +0000 Subject: [M3devel] INTEGER In-Reply-To: References: , , , ,,, , , , , ,,, , , , ,,<20100418023535.3BA9E1A2103@async.async.caltech.edu>, ,,, , , <20100418024703.6965B1A2103@async.async.caltech.edu>, , , , <20100418074927.934461A2117@async.async.caltech.edu>, , <04EB7FF8-D304-428D-839E-233FCE009C98@cs.purdue.edu>, , <20100418195901.CDACB1A20F6@async.async.caltech.edu>, , , , <20100419172313.68B241A20D6@async.async.caltech.edu>, , <4F3EE437-0298-410B-9642-C0381E333430@cs.purdue.edu>, , <20100419223152.3D7331A2122@async.async.caltech.edu>, <4BCDC866.6050804@lcwb.coop>, <20100420171235.B8F0C1A2103@async.async.caltech.edu>, Message-ID: Randy, This is correct. Are we subtly suggesting that LONGINT be 128 bits on 64 bit systems, to avoid the creeping assumption that it is 64 bits? Seems ok, though it'd be some work in the compiler -- but maybe, again, a library based implementation, like how atomic is structured and possibly implemented. Would anyone use this type? Or there'd be m3core/unix/32bit/types.i3 off_t = LONGINT, m3core/unix/64bit/types.i3 off_t = INTEGER? And everywhere else anyone wanted a 64 bit type? Or we would say off_t = BITS 64 FOR [(-?)16_800000000000L..16_7FFFFFFFFFFFL]? That is preferable since it avoids forking a file..though it might be incorrect. 16_800000000000L is positive if 128bits, and -16_800000000000L is correct for 128bits but overflows for 64 bits. I think maybe. - Jay > From: rcolebur at SCIRES.COM > To: m3devel at elegosoft.com > Date: Tue, 20 Apr 2010 15:56:26 -0400 > Subject: Re: [M3devel] INTEGER > > >-----Original Message----- > >From: Mika Nystrom [mailto:mika at async.async.caltech.edu] > >Sent: Tuesday, April 20, 2010 1:13 PM > > > >5. Finally, is it the intention that LONGINT be fixed at 64 bits > >forevermore? (See point 2.) This seems to completely fly in the face > >of M3's philosophy. (See Hendrik's arguments.) > > Mika > > My "understanding" was that LONGINT would be a MINimum of 64-bits, but could be larger on certain platforms. For those platforms where the native integer size is already 64-bits, it could be possible that BITSIZE of INTEGER and LONGINT are indeed the same, 64-bits. It could also be that on some platforms we could have 64-bit INTEGER and maybe 128-bit LONGINT. Thus, the BITSIZE of LONGINT is both platform and implementation-dependent, but constrained to have a lower-bound of 64-bits. If I'm not understanding this correctly, someone please enlighten me. > --Randy > > > > > > CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This email may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from reviewing, copying, using, disclosing or distributing to others the information in this email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. > > EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require advance export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Apr 20 23:42:49 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 20 Apr 2010 21:42:49 +0000 Subject: [M3devel] INTEGER In-Reply-To: <20100420180715.52C391A2103@async.async.caltech.edu> References: , , , ,,, , , , , , , , , , , , , <20100418023535.3BA9E1A2103@async.async.caltech.edu>, ,,, , , <20100418024703.6965B1A2103@async.async.caltech.edu>, , , , <20100418074927.934461A2117@async.async.caltech.edu>, , <04EB7FF8-D304-428D-839E-233FCE009C98@cs.purdue.edu>, , <20100418195901.CDACB1A20F6@async.async.caltech.edu>, , , , <20100419172313.68B241A20D6@async.async.caltech.edu>, , <4F3EE437-0298-410B-9642-C0381E333430@cs.purdue.edu>, , <20100419223152.3D7331A2122@async.async.caltech.edu>, <4BCDC866.6050804@lcwb.coop> <20100420171235!, .B8F0C1A2103@async.async.caltech.edu>, , <20100420180715.52C391A2103@async.async.caltech.edu> Message-ID: Mika I think your point, which I missed for a while is that: Just because some hardware has an efficient 64bit integer called INTEGER, does not justify giving other (32bit) hardware a somewhat efficient 64bit integer called LONGINT. ? The analogy I missed is, just because EXTENDED ought to be 80 bits on x86, it should still be 64bits on most other systems. A "maximum" of 3 floating point types are provided names, but systems that don't want that many can equate some of them. In fact..one might argue... 64bit hardware has very efficient 32bit integer and very efficient 64bit integer, you almost want: 32bit: INTEGER = LONGINT = 32bits 64bit: INTEGER = 32bits, LONGINT = 64bits While I doubt that's is where we are heading, it is in fact what all current C environments do, with one exception, if you map "int" = "INTEGER", "long" = "LONGINT". (The exception is Win64.) But Modula-3 has subranges and packed types, so I guess: INT32 = BITS 32 for [16_80000000..16_7FFFFFFF]; suffices? - Jay > To: hosking at cs.purdue.edu > Date: Tue, 20 Apr 2010 11:07:15 -0700 > From: mika at async.async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] INTEGER > > Tony Hosking writes: > >On 20 Apr 2010, at 13:12, Mika Nystrom wrote: > ... > >> easy access to the hardware in their own machines, not really so that = > >IBM > >> programmers could have an extra format for VAX compatibility. Note = > >that > >> I don't believe that it was intended that EXTENDED would be emulated = > >by > >> the compiler either: the point was really to give programmers access = > >to > >> the formats provided efficiently by their hardware. > > > >In the current implementation EXTENDED=3DLONGREAL. > > Ok, but EXTENDED is still something that is efficiently provided by > my hardware. Not something efficiently provided by someone else's > hardware! > > >> 4. I still haven't seen any really convincing use cases. What's it = > >for? > >> The lack of LONGINT was an obstacle to what, precisely? > > > >I think the only one we have is file sizes... > > > >> 5. Finally, is it the intention that LONGINT be fixed at 64 bits > >> forevermore? (See point 2.) This seems to completely fly in the face > >> of M3's philosophy. (See Hendrik's arguments.) > > > >The only constraint imposed is BITSIZE(LONGINT) >=3D BITSIZE(INTEGER). > > I am not so sure here. > > Rodney's argument has in fact convinced me that the current version of > LONGINT is wrong and perhaps evil. It should either go away completely > or be replaced by Hendrik's suggestion. > > Here's why. The argument is that if I have an N-bit machine, for N out there in the world there is an M-bit machine that for some reason > matters a great deal to me. For some reason I need to be able to write > code that manipulates M-bit integers---because of the existence of this > M-bit machine (or machines)! (Normally we're dealing with the situation > that N=32 and M=64.) So we introduce an M-bit LONGINT. Now it stands to > reason that if the M-bit machine (which I do not own and upon which my > program does not run) is important to me, it is also important to other > Modula-3 programmers. Hence all other implementations of Modula-3 will > *also* provide M-bit integers. > > The M-bit machine of the previous paragraph is of course, in the real > world, a machine with the 64-bit version of the Intel x86 instruction set, > "amd64". How long is it from here to the point where we have programmers > who write code that depends on the fact that M=64, always? > > Mika > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Tue Apr 20 20:00:40 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 20 Apr 2010 14:00:40 -0400 Subject: [M3devel] INTEGER In-Reply-To: <4BCDCF7D.604@lcwb.coop> References: <20100418024703.6965B1A2103@async.async.caltech.edu> <20100418074927.934461A2117@async.async.caltech.edu> <04EB7FF8-D304-428D-839E-233FCE009C98@cs.purdue.edu> <20100418195901.CDACB1A20F6@async.async.caltech.edu> <20100419155702.GB8759@topoi.pooq.com> <4BCDCF7D.604@lcwb.coop> Message-ID: <20100420180040.GA13012@topoi.pooq.com> On Tue, Apr 20, 2010 at 10:59:57AM -0500, Rodney M. Bates wrote: > > > hendrik at topoi.pooq.com wrote: >> On Sun, Apr 18, 2010 at 12:59:01PM -0700, Mika Nystrom wrote: >>> And the new m3tk, stubgen, and compiler(?) won't compile using PM3 or >>> SRC M3 since we're no longer using the language of the Green Book. >>> (Same comment goes for WIDECHAR, by the way.) >> >> When I use Unicode characters, I find myself defining them to be >> INTEGERs, because I'm always worried that WIDECHARs might be omly 16 >> bits. > > Actually, I favor making WIDECHAR big enough to hold all the defined > Unicode values, which I understand have been more that 2^16 for some > time now. The only thing the language definition says about WIDECHAR > is that it has at least 65536 values and the first 65536 correspond to > the first 65536 Unicode characters. It could be bigger. Moreover, as > I recall from a while back, the compiler, old and new Text implementation, > other libraries, m3gdb, and maybe pickles are only a couple of declaration > changes away from supporting some bigger range for WIDECHAR. > > (I think I am the one who put WIDECHAR into the language reference, and > that was only recently, despite its being in the cm3 language for years. I > also see that this has not propagated from the .tex version into the .html > and .pdf files.) > > >> >> Strings of WIDECHARS are probably unnecesary. The last program I wrote >> that used Unicode used INTEGERs for characters, and arrays of INTEGERS >> for strings. But I think it was a mistake to do it this way, and when >> I have time I'll rewrite it. UTF-8 seems to be the way to go; strings >> of Unicode can easily be manipulated as ordinary TEXT. In fact, I >> think there are few if any places in my code where I would have had to >> do anything special whatsoever if I had just used UTF8 in TEXT. The >> program would simply become simpler. > > This is only true if you handle strings in certain common but restricted > ways. If you just move strings around, UTF-8 will often work with little > or no code change. OTOH, if you need to access characters non-sequentially > or make any examination or production of individual characters not in the > Iso-latin-1 subset, any variable-length encoding quickly becomes unworkable. Whe you are doing things like this, you are probably doing something like -- shall I say it? -- *parsing*. There's no need for parsing to stop at the character level. You might as well parse all the way down to bytes. And UTF-8 is designed so that that is particularly easy. > > Text.Sub and Text.GetChar won't work in any sensible way if they view the > string as a string of 8-bit bytes, when it's actually not. Reimplementing > these to understand UTF-8 would make what was O(1) become O(n). > Ditto Text.Length. Exactly. That's why you leave them as byte operations. It's pretty rare that you want to pull six characters out of a string. It's pretty common that you want to pull a word out of a string, having parsed part of it and discovering that the work is n characters wide. You could instead have parsed it and discovered that it is m bytes long. The point is, that it's almost never worthwhile to parse it once and turn it into an array of WIDECHARS and then to parse the result again. Just like compilers -- they don't start by lexically scanning the entire source code and storing it somewhere, and then parsing it afterward. Not normally, anyway. -- hendrik From jay.krell at cornell.edu Wed Apr 21 09:56:22 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 21 Apr 2010 07:56:22 +0000 Subject: [M3devel] Alpha is 32bits! Message-ID: Huh. I found that OpenVMS on Alpha is a hybrid 32bit/64bit system. The default pointer size is 32 bits. You can change it to 64 bits with compiler command line option. I guess this is for greater compatibility with VAX. There are two of many functions. Some are missing in 64 bits. size_t is always 32 bits! http://www.openvms.compaq.com/doc/72final/6467/6467pro_contents.html esp. http://www.openvms.compaq.com/doc/72final/6467/6467pro_006.html#64_bit_obtaining_long_ptrs_sec and newer similar: http://www.openvms.compaq.com/doc/83final/5763/5763pro_007.html#the_64_bit_sec WALLIS> type jmpbuf.c #include #include #include #define SIZE(x) ((unsigned)sizeof(x)) int main() { ? printf("%u %u %u %u %u\n", ??? SIZE(int), ??? SIZE(long), ??? SIZE(void*), ??? SIZE(size_t), ??? SIZE(jmp_buf)); ? return 0; } WALLIS> cc jmpbuf.c WALLIS> link jmpbuf.obj WALLIS> run jmpbuf 4 4 4 4 544 WALLIS> cc /pointer_size=64 jmpbuf.c WALLIS> link jmpbuf.obj WALLIS> run jmpbuf 4 4 8 4 544 I still haven't found the actual header files! So I'm going to work toward ALPHA32_VMS for now. I can try ALPHA64_VMS later. Assuming m3cg offers -m32 and -m64 to handle this. :) ?- Jay From mika at async.async.caltech.edu Wed Apr 21 10:10:22 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Wed, 21 Apr 2010 01:10:22 -0700 Subject: [M3devel] Alpha is 32bits! In-Reply-To: References: Message-ID: <20100421081022.358C01A20E1@async.async.caltech.edu> I remember that DEC cc had options on OSF/1 to use memory in such a way that you could guarantee the first 4 GB you touched were sign-extended 32-bit numbers (so the upper doubleword was 0xffffffff or 0x00000000 always) for some sort of compatibility. But Alpha doesn't have hardware instructions to do memory references with 32-bit pointers as far as I remember. I have the architecture reference here to look in... Mika Jay K writes: > >Huh. I found that OpenVMS on Alpha is a hybrid 32bit/64bit system. > >The default pointer size is 32 bits. You can change it to 64 bits with comp= >iler command line option. >I guess this is for greater compatibility with VAX. >There are two of many functions. Some are missing in 64 bits. >size_t is always 32 bits! > >http://www.openvms.compaq.com/doc/72final/6467/6467pro_contents.html >esp. http://www.openvms.compaq.com/doc/72final/6467/6467pro_006.html#64_bit= >_obtaining_long_ptrs_sec > >and newer similar: http://www.openvms.compaq.com/doc/83final/5763/5763pro_0= >07.html#the_64_bit_sec > >WALLIS> type jmpbuf.c > >#include > >#include > >#include > > > >#define SIZE(x) ((unsigned)sizeof(x)) > > > >int main() > >{ > >=A0 printf("%u %u %u %u %u\n"=2C > >=A0=A0=A0 SIZE(int)=2C > >=A0=A0=A0 SIZE(long)=2C > >=A0=A0=A0 SIZE(void*)=2C > >=A0=A0=A0 SIZE(size_t)=2C > >=A0=A0=A0 SIZE(jmp_buf))=3B > >=A0 return 0=3B > >} > > > >WALLIS> cc jmpbuf.c > >WALLIS> link jmpbuf.obj > >WALLIS> run jmpbuf > >4 4 4 4 544 > > > >WALLIS> cc /pointer_size=3D64 jmpbuf.c > >WALLIS> link jmpbuf.obj > >WALLIS> run jmpbuf > >4 4 8 4 544 > > > >I still haven't found the actual header files! > > >So I'm going to work toward ALPHA32_VMS for now. >I can try ALPHA64_VMS later. >Assuming m3cg offers -m32 and -m64 to handle this. :) > >=A0- Jay > = From jay.krell at cornell.edu Wed Apr 21 10:56:29 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 21 Apr 2010 08:56:29 +0000 Subject: [M3devel] Alpha is 32bits! In-Reply-To: <20100421081022.358C01A20E1@async.async.caltech.edu> References: , <20100421081022.358C01A20E1@async.async.caltech.edu> Message-ID: I believe registers are always 64bits, pointers are sign extended, memory is sure to be allocated in the top/bottom 2GB. The two types of functions can call each other, and 32bit pointers can be passed to functions expecting 64bit pointers. It looks like gcc supports alpha-dec-vms => 32bit and alpha64-dec-vms => 64bits. I'm going to introduce ALPHA32_VMS and ALPHA64_VMS but probably work more on the first initially. ?- Jay ---------------------------------------- > To: jay.krell at cornell.edu > Date: Wed, 21 Apr 2010 01:10:22 -0700 > From: mika at async.async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Alpha is 32bits! > > > > I remember that DEC cc had options on OSF/1 to use memory in such a > way that you could guarantee the first 4 GB you touched were sign-extended > 32-bit numbers (so the upper doubleword was 0xffffffff or 0x00000000 always) > for some sort of compatibility. > > But Alpha doesn't have hardware instructions to do memory references with > 32-bit pointers as far as I remember. I have the architecture reference > here to look in... > > Mika > > Jay K writes: >> >>Huh. I found that OpenVMS on Alpha is a hybrid 32bit/64bit system. >> >>The default pointer size is 32 bits. You can change it to 64 bits with comp= >>iler command line option. >>I guess this is for greater compatibility with VAX. >>There are two of many functions. Some are missing in 64 bits. >>size_t is always 32 bits! >> >>http://www.openvms.compaq.com/doc/72final/6467/6467pro_contents.html >>esp. http://www.openvms.compaq.com/doc/72final/6467/6467pro_006.html#64_bit= >>_obtaining_long_ptrs_sec >> >>and newer similar: http://www.openvms.compaq.com/doc/83final/5763/5763pro_0= >>07.html#the_64_bit_sec >> >>WALLIS> type jmpbuf.c >> >>#include >> >>#include >> >>#include >> >> >> >>#define SIZE(x) ((unsigned)sizeof(x)) >> >> >> >>int main() >> >>{ >> >>=A0 printf("%u %u %u %u %u\n"=2C >> >>=A0=A0=A0 SIZE(int)=2C >> >>=A0=A0=A0 SIZE(long)=2C >> >>=A0=A0=A0 SIZE(void*)=2C >> >>=A0=A0=A0 SIZE(size_t)=2C >> >>=A0=A0=A0 SIZE(jmp_buf))=3B >> >>=A0 return 0=3B >> >>} >> >> >> >>WALLIS> cc jmpbuf.c >> >>WALLIS> link jmpbuf.obj >> >>WALLIS> run jmpbuf >> >>4 4 4 4 544 >> >> >> >>WALLIS> cc /pointer_size=3D64 jmpbuf.c >> >>WALLIS> link jmpbuf.obj >> >>WALLIS> run jmpbuf >> >>4 4 8 4 544 >> >> >> >>I still haven't found the actual header files! >> >> >>So I'm going to work toward ALPHA32_VMS for now. >>I can try ALPHA64_VMS later. >>Assuming m3cg offers -m32 and -m64 to handle this. :) >> >>=A0- Jay >> = From rodney_bates at lcwb.coop Wed Apr 21 16:55:29 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Wed, 21 Apr 2010 09:55:29 -0500 Subject: [M3devel] INTEGER In-Reply-To: <20100420180715.52C391A2103@async.async.caltech.edu> References: , , , , , , <20100418023535.3BA9E1A2103@async.async.caltech.edu>, , , , <20100418024703.6965B1A2103@async.async.caltech.edu>, , <20100418074927.934461A2117@async.async.caltech.edu>, <04EB7FF8-D304-428D-839E-233FCE009C98@cs.purdue.edu>, <20100418195901.CDACB1A20F6@async.async.caltech.edu>, , <20100419172313.68B241A20D6@async.async.caltech.edu>, <4F3EE437-0298-410B-9642-C0381E333430@cs.purdue.edu> <20100419223152.3D7331A2122@async.async.caltech.edu> <4BCDC866.6050804@lcwb.coop> <20100420171235! .B8F0C1A2103@async.async.caltech.edu> <20100420180715.52C391A2103@async.async.caltech.edu> Message-ID: <4BCF11E1.5090609@lcwb.coop> Mika Nystrom wrote: > Tony Hosking writes: >> On 20 Apr 2010, at 13:12, Mika Nystrom wrote: > ... >>> easy access to the hardware in their own machines, not really so that = >> IBM >>> programmers could have an extra format for VAX compatibility. Note = >> that >>> I don't believe that it was intended that EXTENDED would be emulated = >> by >>> the compiler either: the point was really to give programmers access = >> to >>> the formats provided efficiently by their hardware. >> In the current implementation EXTENDED=3DLONGREAL. > > Ok, but EXTENDED is still something that is efficiently provided by > my hardware. Not something efficiently provided by someone else's > hardware! > >>> 4. I still haven't seen any really convincing use cases. What's it = >> for? >>> The lack of LONGINT was an obstacle to what, precisely? >> I think the only one we have is file sizes... >> >>> 5. Finally, is it the intention that LONGINT be fixed at 64 bits >>> forevermore? (See point 2.) This seems to completely fly in the face >>> of M3's philosophy. (See Hendrik's arguments.) >> The only constraint imposed is BITSIZE(LONGINT) >=3D BITSIZE(INTEGER). > > I am not so sure here. > > Rodney's argument has in fact convinced me that the current version of > LONGINT is wrong and perhaps evil. It should either go away completely > or be replaced by Hendrik's suggestion. > > Here's why. The argument is that if I have an N-bit machine, for N out there in the world there is an M-bit machine that for some reason > matters a great deal to me. For some reason I need to be able to write > code that manipulates M-bit integers---because of the existence of this > M-bit machine (or machines)! It has never been motivated by the existence of machines with various native arithmetic sizes. It is about problems that need big value ranges to work. Its also about making it convenient to write portable code that solves them. (Well, that part does have to do with the machines that exist.) And making the type checking, etc. not change on the different machines. And using the most efficient arithmetic consistent with correct answers. Normally we're dealing with the situation > that N=32 and M=64.) So we introduce an M-bit LONGINT. Now it stands to > reason that if the M-bit machine (which I do not own and upon which my > program does not run) is important to me, it is also important to other > Modula-3 programmers. Hence all other implementations of Modula-3 will > *also* provide M-bit integers. > > The M-bit machine of the previous paragraph is of course, in the real > world, a machine with the 64-bit version of the Intel x86 instruction set, > "amd64". How long is it from here to the point where we have programmers > who write code that depends on the fact that M=64, always? LONGINT presents the same opportunity/invitation/temptation to write code that make such assumptions as does INTEGER, or for that matter, REFANY, or gobs of other things in the original language. So LONGINT is just as evil as INTEGER. > > Mika > > From hendrik at topoi.pooq.com Wed Apr 21 20:56:31 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Wed, 21 Apr 2010 14:56:31 -0400 Subject: [M3devel] INTEGER In-Reply-To: <4BCF11E1.5090609@lcwb.coop> References: <4F3EE437-0298-410B-9642-C0381E333430@cs.purdue.edu> <20100419223152.3D7331A2122@async.async.caltech.edu> <4BCDC866.6050804@lcwb.coop> <20100420171235!.B8F0C1A2103@async.async.caltech.edu> <20100420180715.52C391A2103@async.async.caltech.edu> <4BCF11E1.5090609@lcwb.coop> Message-ID: <20100421185631.GA17051@topoi.pooq.com> On Wed, Apr 21, 2010 at 09:55:29AM -0500, Rodney M. Bates wrote: > > > Mika Nystrom wrote: >> Tony Hosking writes: >>> On 20 Apr 2010, at 13:12, Mika Nystrom wrote: >> ... >>>> easy access to the hardware in their own machines, not really so that = >>> IBM >>>> programmers could have an extra format for VAX compatibility. Note = >>> that >>>> I don't believe that it was intended that EXTENDED would be emulated = >>> by >>>> the compiler either: the point was really to give programmers access = >>> to >>>> the formats provided efficiently by their hardware. >>> In the current implementation EXTENDED=3DLONGREAL. >> >> Ok, but EXTENDED is still something that is efficiently provided by >> my hardware. Not something efficiently provided by someone else's >> hardware! >> >>>> 4. I still haven't seen any really convincing use cases. What's it = >>> for? >>>> The lack of LONGINT was an obstacle to what, precisely? >>> I think the only one we have is file sizes... >>> >>>> 5. Finally, is it the intention that LONGINT be fixed at 64 bits >>>> forevermore? (See point 2.) This seems to completely fly in the face >>>> of M3's philosophy. (See Hendrik's arguments.) >>> The only constraint imposed is BITSIZE(LONGINT) >=3D BITSIZE(INTEGER). >> >> I am not so sure here. >> >> Rodney's argument has in fact convinced me that the current version of >> LONGINT is wrong and perhaps evil. It should either go away completely >> or be replaced by Hendrik's suggestion. >> >> Here's why. The argument is that if I have an N-bit machine, for N> out there in the world there is an M-bit machine that for some reason >> matters a great deal to me. For some reason I need to be able to write >> code that manipulates M-bit integers---because of the existence of this >> M-bit machine (or machines)! > > It has never been motivated by the existence of machines with various native > arithmetic sizes. It is about problems that need big value ranges to work. > > Its also about making it convenient to write portable code that solves > them. (Well, that part does have to do with the machines that exist.) > And making the type checking, etc. not change on the different machines. > And using the most efficient arithmetic consistent with correct answers. > > Normally we're dealing with the situation >> that N=32 and M=64.) So we introduce an M-bit LONGINT. Now it stands to >> reason that if the M-bit machine (which I do not own and upon which my >> program does not run) is important to me, it is also important to other >> Modula-3 programmers. Hence all other implementations of Modula-3 will >> *also* provide M-bit integers. >> >> The M-bit machine of the previous paragraph is of course, in the real >> world, a machine with the 64-bit version of the Intel x86 instruction set, >> "amd64". How long is it from here to the point where we have programmers >> who write code that depends on the fact that M=64, always? > > LONGINT presents the same opportunity/invitation/temptation to > write code that make such assumptions as does INTEGER, or for that matter, > REFANY, or gobs of other things in the original language. So LONGINT is > just as evil as INTEGER. Which is why I'd allow only subranges of LONGINT to be mentioned in programs. -- hendrik > >> >> Mika >> >> From hosking at cs.purdue.edu Thu Apr 22 17:57:16 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 22 Apr 2010 11:57:16 -0400 Subject: [M3devel] INTEGER In-Reply-To: <20100421185631.GA17051@topoi.pooq.com> References: <4F3EE437-0298-410B-9642-C0381E333430@cs.purdue.edu> <20100419223152.3D7331A2122@async.async.caltech.edu> <4BCDC866.6050804@lcwb.coop> <20100420171235!.B8F0C1A2103@async.async.caltech.edu> <20100420180715.52C391A2103@async.async.caltech.edu> <4BCF11E1.5090609@lcwb.coop> <20100421185631.GA17051@topoi.pooq.com> Message-ID: <80775CA2-A2FD-40AF-B235-7DB84127762E@cs.purdue.edu> But this is bizarre. What type does an element of a subrange of LONGINT have if not LONGINT? If the subrange has a base type of INTEGER then we need a mapping between the elements of the subrange and the base INTEGER values. But then, values of the LONGINT subrange don't have the same representation as their INTEGER counterpart. All very odd. On 21 Apr 2010, at 14:56, hendrik at topoi.pooq.com wrote: > On Wed, Apr 21, 2010 at 09:55:29AM -0500, Rodney M. Bates wrote: >> >> >> Mika Nystrom wrote: >>> Tony Hosking writes: >>>> On 20 Apr 2010, at 13:12, Mika Nystrom wrote: >>> ... >>>>> easy access to the hardware in their own machines, not really so that = >>>> IBM >>>>> programmers could have an extra format for VAX compatibility. Note = >>>> that >>>>> I don't believe that it was intended that EXTENDED would be emulated = >>>> by >>>>> the compiler either: the point was really to give programmers access = >>>> to >>>>> the formats provided efficiently by their hardware. >>>> In the current implementation EXTENDED=3DLONGREAL. >>> >>> Ok, but EXTENDED is still something that is efficiently provided by >>> my hardware. Not something efficiently provided by someone else's >>> hardware! >>> >>>>> 4. I still haven't seen any really convincing use cases. What's it = >>>> for? >>>>> The lack of LONGINT was an obstacle to what, precisely? >>>> I think the only one we have is file sizes... >>>> >>>>> 5. Finally, is it the intention that LONGINT be fixed at 64 bits >>>>> forevermore? (See point 2.) This seems to completely fly in the face >>>>> of M3's philosophy. (See Hendrik's arguments.) >>>> The only constraint imposed is BITSIZE(LONGINT) >=3D BITSIZE(INTEGER). >>> >>> I am not so sure here. >>> >>> Rodney's argument has in fact convinced me that the current version of >>> LONGINT is wrong and perhaps evil. It should either go away completely >>> or be replaced by Hendrik's suggestion. >>> >>> Here's why. The argument is that if I have an N-bit machine, for N>> out there in the world there is an M-bit machine that for some reason >>> matters a great deal to me. For some reason I need to be able to write >>> code that manipulates M-bit integers---because of the existence of this >>> M-bit machine (or machines)! >> >> It has never been motivated by the existence of machines with various native >> arithmetic sizes. It is about problems that need big value ranges to work. >> >> Its also about making it convenient to write portable code that solves >> them. (Well, that part does have to do with the machines that exist.) >> And making the type checking, etc. not change on the different machines. >> And using the most efficient arithmetic consistent with correct answers. >> >> Normally we're dealing with the situation >>> that N=32 and M=64.) So we introduce an M-bit LONGINT. Now it stands to >>> reason that if the M-bit machine (which I do not own and upon which my >>> program does not run) is important to me, it is also important to other >>> Modula-3 programmers. Hence all other implementations of Modula-3 will >>> *also* provide M-bit integers. >>> >>> The M-bit machine of the previous paragraph is of course, in the real >>> world, a machine with the 64-bit version of the Intel x86 instruction set, >>> "amd64". How long is it from here to the point where we have programmers >>> who write code that depends on the fact that M=64, always? >> >> LONGINT presents the same opportunity/invitation/temptation to >> write code that make such assumptions as does INTEGER, or for that matter, >> REFANY, or gobs of other things in the original language. So LONGINT is >> just as evil as INTEGER. > > Which is why I'd allow only subranges of LONGINT to be mentioned in > programs. > > -- hendrik > >> >>> >>> Mika >>> >>> From hendrik at topoi.pooq.com Thu Apr 22 14:38:06 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 22 Apr 2010 08:38:06 -0400 Subject: [M3devel] INTEGER In-Reply-To: <80775CA2-A2FD-40AF-B235-7DB84127762E@cs.purdue.edu> References: <4F3EE437-0298-410B-9642-C0381E333430@cs.purdue.edu> <20100419223152.3D7331A2122@async.async.caltech.edu> <4BCDC866.6050804@lcwb.coop> <20100420171235!.B8F0C1A2103@async.async.caltech.edu> <20100420180715.52C391A2103@async.async.caltech.edu> <4BCF11E1.5090609@lcwb.coop> <20100421185631.GA17051@topoi.pooq.com> <80775CA2-A2FD-40AF-B235-7DB84127762E@cs.purdue.edu> Message-ID: <20100422123805.GA19259@topoi.pooq.com> On Thu, Apr 22, 2010 at 11:57:16AM -0400, Tony Hosking wrote: > But this is bizarre. What type does an element of a subrange of > LONGINT have if not LONGINT? It has LONGINT as a type. > If the subrange has a base type of INTEGER then we need a mapping > between the elements of the subrange and the base INTEGER values. Yes. And INTEGER is different from the notion mathematicians have of integers in that there is a limit on the size of integers. It's a machine or implementation-dependent limit, and it's imposed for efficiency reasons, but it's a specific limit just the same. This limit is precisely what we're up against. > But then, values of the LONGINT subrange don't have the same > representation as their INTEGER counterpart. Of course not. If they did have the same representation, there would be in-range for INTEGERs, and there would be no need to have LONGINT at all. LONGINT is there precisely for the integers that *don't* fit in INTEGER. > > All very odd. But dictated by the intended use -- that of having integral ranges whose bounds are dictated by the problem, not the hardware. -- hendrik From hosking at cs.purdue.edu Thu Apr 22 20:36:17 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 22 Apr 2010 14:36:17 -0400 Subject: [M3devel] INTEGER In-Reply-To: <20100422123805.GA19259@topoi.pooq.com> References: <4F3EE437-0298-410B-9642-C0381E333430@cs.purdue.edu> <20100419223152.3D7331A2122@async.async.caltech.edu> <4BCDC866.6050804@lcwb.coop> <20100420171235!.B8F0C1A2103@async.async.caltech.edu> <20100420180715.52C391A2103@async.async.caltech.edu> <4BCF11E1.5090609@lcwb.coop> <20100421185631.GA17051@topoi.pooq.com> <80775CA2-A2FD-40AF-B235-7DB84127762E@cs.purdue.edu> <20100422123805.GA19259@topoi.pooq.com> Message-ID: <87B45DCC-2B8A-4C69-97D7-240BC1E2252D@cs.purdue.edu> Let me see. The green book definition says the base type of a subrange of INTEGER literals is INTEGER. You say that the base type of a subrange of LONGINT literals is LONGINT. But you say that LONGINT is not a defined type. So, what is the type of a LONGINT literal? ... [I think I misunderstood you previously. I had interpreted that you meant LONGINT subranges to have base type INTEGER.] On 22 Apr 2010, at 08:38, hendrik at topoi.pooq.com wrote: > On Thu, Apr 22, 2010 at 11:57:16AM -0400, Tony Hosking wrote: >> But this is bizarre. What type does an element of a subrange of >> LONGINT have if not LONGINT? > > It has LONGINT as a type. > >> If the subrange has a base type of INTEGER then we need a mapping >> between the elements of the subrange and the base INTEGER values. > > Yes. And INTEGER is different from the notion mathematicians have of > integers in that there is a limit on the size of integers. It's a > machine or implementation-dependent limit, and it's imposed for > efficiency reasons, but it's a specific limit just the same. > This limit is precisely what we're up against. > >> But then, values of the LONGINT subrange don't have the same >> representation as their INTEGER counterpart. > > Of course not. If they did have the same representation, there would be > in-range for INTEGERs, and there would be no need to have LONGINT at > all. > > LONGINT is there precisely for the integers that *don't* fit in INTEGER. > >> >> All very odd. > > But dictated by the intended use -- that of having integral ranges > whose bounds are dictated by the problem, not the hardware. > > -- hendrik From hendrik at topoi.pooq.com Thu Apr 22 16:55:23 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 22 Apr 2010 10:55:23 -0400 Subject: [M3devel] INTEGER In-Reply-To: <87B45DCC-2B8A-4C69-97D7-240BC1E2252D@cs.purdue.edu> References: <20100419223152.3D7331A2122@async.async.caltech.edu> <4BCDC866.6050804@lcwb.coop> <20100420171235!.B8F0C1A2103@async.async.caltech.edu> <20100420180715.52C391A2103@async.async.caltech.edu> <4BCF11E1.5090609@lcwb.coop> <20100421185631.GA17051@topoi.pooq.com> <80775CA2-A2FD-40AF-B235-7DB84127762E@cs.purdue.edu> <20100422123805.GA19259@topoi.pooq.com> <87B45DCC-2B8A-4C69-97D7-240BC1E2252D@cs.purdue.edu> Message-ID: <20100422145522.GA19946@topoi.pooq.com> On Thu, Apr 22, 2010 at 02:36:17PM -0400, Tony Hosking wrote: > Let me see. > > The green book definition says the base type of a subrange of INTEGER literals is INTEGER. > You say that the base type of a subrange of LONGINT literals is LONGINT. > But you say that LONGINT is not a defined type. So, what is the type > of a LONGINT literal? (a) 3849587394875493920398438483929293484L could very well be of type 3849587394875493920398438483929293484L..3849587394875493920398438483929293484L which is a one-element subtype of LONGINT. LONGINY is a type. It's just one that's not available directly to the programmer. It would not need to have a defined size, if the language allowed LONGINT values to occur *only* where an upper bound on their size is known, such as by being elements of a subrange. -- hendrik > > [I think I misunderstood you previously. I had interpreted that you meant LONGINT subranges to have base type INTEGER.] > > On 22 Apr 2010, at 08:38, hendrik at topoi.pooq.com wrote: > > > On Thu, Apr 22, 2010 at 11:57:16AM -0400, Tony Hosking wrote: > >> But this is bizarre. What type does an element of a subrange of > >> LONGINT have if not LONGINT? > > > > It has LONGINT as a type. > > > >> If the subrange has a base type of INTEGER then we need a mapping > >> between the elements of the subrange and the base INTEGER values. > > > > Yes. And INTEGER is different from the notion mathematicians have of > > integers in that there is a limit on the size of integers. It's a > > machine or implementation-dependent limit, and it's imposed for > > efficiency reasons, but it's a specific limit just the same. > > This limit is precisely what we're up against. > > > >> But then, values of the LONGINT subrange don't have the same > >> representation as their INTEGER counterpart. > > > > Of course not. If they did have the same representation, there would be > > in-range for INTEGERs, and there would be no need to have LONGINT at > > all. > > > > LONGINT is there precisely for the integers that *don't* fit in INTEGER. > > > >> > >> All very odd. > > > > But dictated by the intended use -- that of having integral ranges > > whose bounds are dictated by the problem, not the hardware. > > > > -- hendrik > From hosking at cs.purdue.edu Thu Apr 22 21:27:50 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 22 Apr 2010 15:27:50 -0400 Subject: [M3devel] INTEGER In-Reply-To: <20100422145522.GA19946@topoi.pooq.com> References: <20100419223152.3D7331A2122@async.async.caltech.edu> <4BCDC866.6050804@lcwb.coop> <20100420171235!.B8F0C1A2103@async.async.caltech.edu> <20100420180715.52C391A2103@async.async.caltech.edu> <4BCF11E1.5090609@lcwb.coop> <20100421185631.GA17051@topoi.pooq.com> <80775CA2-A2FD-40AF-B235-7DB84127762E@cs.purdue.edu> <20100422123805.GA19259@topoi.pooq.com> <87B45DCC-2B8A-4C69-97D7-240BC1E2252D@cs.purdue.edu> <20100422145522.GA19946@topoi.pooq.com> Message-ID: <28339030-6005-4C28-872C-A68CF24BF4DF@cs.purdue.edu> This is bizarre, and perverts the language definition significantly more than the current scheme. What is the base type of that subrange? On 22 Apr 2010, at 10:55, hendrik at topoi.pooq.com wrote: > On Thu, Apr 22, 2010 at 02:36:17PM -0400, Tony Hosking wrote: >> Let me see. >> >> The green book definition says the base type of a subrange of INTEGER literals is INTEGER. >> You say that the base type of a subrange of LONGINT literals is LONGINT. >> But you say that LONGINT is not a defined type. So, what is the type >> of a LONGINT literal? > > (a) 3849587394875493920398438483929293484L could very well be of type > 3849587394875493920398438483929293484L..3849587394875493920398438483929293484L > which is a one-element subtype of LONGINT. > > LONGINY is a type. It's just one that's not available directly to the > programmer. It would not need to have a defined size, if the language > allowed LONGINT values to occur *only* where an upper bound on > their size is known, such as by being elements of a subrange. > > -- hendrik > >> >> [I think I misunderstood you previously. I had interpreted that you meant LONGINT subranges to have base type INTEGER.] >> >> On 22 Apr 2010, at 08:38, hendrik at topoi.pooq.com wrote: >> >>> On Thu, Apr 22, 2010 at 11:57:16AM -0400, Tony Hosking wrote: >>>> But this is bizarre. What type does an element of a subrange of >>>> LONGINT have if not LONGINT? >>> >>> It has LONGINT as a type. >>> >>>> If the subrange has a base type of INTEGER then we need a mapping >>>> between the elements of the subrange and the base INTEGER values. >>> >>> Yes. And INTEGER is different from the notion mathematicians have of >>> integers in that there is a limit on the size of integers. It's a >>> machine or implementation-dependent limit, and it's imposed for >>> efficiency reasons, but it's a specific limit just the same. >>> This limit is precisely what we're up against. >>> >>>> But then, values of the LONGINT subrange don't have the same >>>> representation as their INTEGER counterpart. >>> >>> Of course not. If they did have the same representation, there would be >>> in-range for INTEGERs, and there would be no need to have LONGINT at >>> all. >>> >>> LONGINT is there precisely for the integers that *don't* fit in INTEGER. >>> >>>> >>>> All very odd. >>> >>> But dictated by the intended use -- that of having integral ranges >>> whose bounds are dictated by the problem, not the hardware. >>> >>> -- hendrik >> From hendrik at topoi.pooq.com Thu Apr 22 17:43:57 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 22 Apr 2010 11:43:57 -0400 Subject: [M3devel] INTEGER In-Reply-To: <28339030-6005-4C28-872C-A68CF24BF4DF@cs.purdue.edu> References: <20100420171235!.B8F0C1A2103@async.async.caltech.edu> <20100420180715.52C391A2103@async.async.caltech.edu> <4BCF11E1.5090609@lcwb.coop> <20100421185631.GA17051@topoi.pooq.com> <80775CA2-A2FD-40AF-B235-7DB84127762E@cs.purdue.edu> <20100422123805.GA19259@topoi.pooq.com> <87B45DCC-2B8A-4C69-97D7-240BC1E2252D@cs.purdue.edu> <20100422145522.GA19946@topoi.pooq.com> <28339030-6005-4C28-872C-A68CF24BF4DF@cs.purdue.edu> Message-ID: <20100422154357.GA20043@topoi.pooq.com> On Thu, Apr 22, 2010 at 03:27:50PM -0400, Tony Hosking wrote: > This is bizarre, and perverts the language definition significantly more than the current scheme. > What is the base type of that subrange? LONGINT. -- hendrik > > On 22 Apr 2010, at 10:55, hendrik at topoi.pooq.com wrote: > > > On Thu, Apr 22, 2010 at 02:36:17PM -0400, Tony Hosking wrote: > >> Let me see. > >> > >> The green book definition says the base type of a subrange of INTEGER literals is INTEGER. > >> You say that the base type of a subrange of LONGINT literals is LONGINT. > >> But you say that LONGINT is not a defined type. So, what is the type > >> of a LONGINT literal? > > > > (a) 3849587394875493920398438483929293484L could very well be of type > > 3849587394875493920398438483929293484L..3849587394875493920398438483929293484L > > which is a one-element subtype of LONGINT. > > > > LONGINY is a type. It's just one that's not available directly to the > > programmer. It would not need to have a defined size, if the language > > allowed LONGINT values to occur *only* where an upper bound on > > their size is known, such as by being elements of a subrange. > > > > -- hendrik > > > >> > >> [I think I misunderstood you previously. I had interpreted that you meant LONGINT subranges to have base type INTEGER.] > >> > >> On 22 Apr 2010, at 08:38, hendrik at topoi.pooq.com wrote: > >> > >>> On Thu, Apr 22, 2010 at 11:57:16AM -0400, Tony Hosking wrote: > >>>> But this is bizarre. What type does an element of a subrange of > >>>> LONGINT have if not LONGINT? > >>> > >>> It has LONGINT as a type. > >>> > >>>> If the subrange has a base type of INTEGER then we need a mapping > >>>> between the elements of the subrange and the base INTEGER values. > >>> > >>> Yes. And INTEGER is different from the notion mathematicians have of > >>> integers in that there is a limit on the size of integers. It's a > >>> machine or implementation-dependent limit, and it's imposed for > >>> efficiency reasons, but it's a specific limit just the same. > >>> This limit is precisely what we're up against. > >>> > >>>> But then, values of the LONGINT subrange don't have the same > >>>> representation as their INTEGER counterpart. > >>> > >>> Of course not. If they did have the same representation, there would be > >>> in-range for INTEGERs, and there would be no need to have LONGINT at > >>> all. > >>> > >>> LONGINT is there precisely for the integers that *don't* fit in INTEGER. > >>> > >>>> > >>>> All very odd. > >>> > >>> But dictated by the intended use -- that of having integral ranges > >>> whose bounds are dictated by the problem, not the hardware. > >>> > >>> -- hendrik > >> > From hosking at cs.purdue.edu Thu Apr 22 21:44:03 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 22 Apr 2010 15:44:03 -0400 Subject: [M3devel] INTEGER In-Reply-To: <20100422154357.GA20043@topoi.pooq.com> References: <20100420171235!.B8F0C1A2103@async.async.caltech.edu> <20100420180715.52C391A2103@async.async.caltech.edu> <4BCF11E1.5090609@lcwb.coop> <20100421185631.GA17051@topoi.pooq.com> <80775CA2-A2FD-40AF-B235-7DB84127762E@cs.purdue.edu> <20100422123805.GA19259@topoi.pooq.com> <87B45DCC-2B8A-4C69-97D7-240BC1E2252D@cs.purdue.edu> <20100422145522.GA19946@topoi.pooq.com> <28339030-6005-4C28-872C-A68CF24BF4DF@cs.purdue.edu> <20100422154357.GA20043@topoi.pooq.com> Message-ID: <270A99B5-173E-413B-8C28-E1CA68870FD4@cs.purdue.edu> Defined as... On 22 Apr 2010, at 11:43, hendrik at topoi.pooq.com wrote: > On Thu, Apr 22, 2010 at 03:27:50PM -0400, Tony Hosking wrote: >> This is bizarre, and perverts the language definition significantly more than the current scheme. >> What is the base type of that subrange? > > LONGINT. > > -- hendrik > >> >> On 22 Apr 2010, at 10:55, hendrik at topoi.pooq.com wrote: >> >>> On Thu, Apr 22, 2010 at 02:36:17PM -0400, Tony Hosking wrote: >>>> Let me see. >>>> >>>> The green book definition says the base type of a subrange of INTEGER literals is INTEGER. >>>> You say that the base type of a subrange of LONGINT literals is LONGINT. >>>> But you say that LONGINT is not a defined type. So, what is the type >>>> of a LONGINT literal? >>> >>> (a) 3849587394875493920398438483929293484L could very well be of type >>> 3849587394875493920398438483929293484L..3849587394875493920398438483929293484L >>> which is a one-element subtype of LONGINT. >>> >>> LONGINY is a type. It's just one that's not available directly to the >>> programmer. It would not need to have a defined size, if the language >>> allowed LONGINT values to occur *only* where an upper bound on >>> their size is known, such as by being elements of a subrange. >>> >>> -- hendrik >>> >>>> >>>> [I think I misunderstood you previously. I had interpreted that you meant LONGINT subranges to have base type INTEGER.] >>>> >>>> On 22 Apr 2010, at 08:38, hendrik at topoi.pooq.com wrote: >>>> >>>>> On Thu, Apr 22, 2010 at 11:57:16AM -0400, Tony Hosking wrote: >>>>>> But this is bizarre. What type does an element of a subrange of >>>>>> LONGINT have if not LONGINT? >>>>> >>>>> It has LONGINT as a type. >>>>> >>>>>> If the subrange has a base type of INTEGER then we need a mapping >>>>>> between the elements of the subrange and the base INTEGER values. >>>>> >>>>> Yes. And INTEGER is different from the notion mathematicians have of >>>>> integers in that there is a limit on the size of integers. It's a >>>>> machine or implementation-dependent limit, and it's imposed for >>>>> efficiency reasons, but it's a specific limit just the same. >>>>> This limit is precisely what we're up against. >>>>> >>>>>> But then, values of the LONGINT subrange don't have the same >>>>>> representation as their INTEGER counterpart. >>>>> >>>>> Of course not. If they did have the same representation, there would be >>>>> in-range for INTEGERs, and there would be no need to have LONGINT at >>>>> all. >>>>> >>>>> LONGINT is there precisely for the integers that *don't* fit in INTEGER. >>>>> >>>>>> >>>>>> All very odd. >>>>> >>>>> But dictated by the intended use -- that of having integral ranges >>>>> whose bounds are dictated by the problem, not the hardware. >>>>> >>>>> -- hendrik >>>> >> From jay.krell at cornell.edu Thu Apr 22 21:38:03 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 22 Apr 2010 19:38:03 +0000 Subject: [M3devel] INTEGER In-Reply-To: <20100422145522.GA19946@topoi.pooq.com> References: <20100419223152.3D7331A2122@async.async.caltech.edu>, <4BCDC866.6050804@lcwb.coop>, <20100420171235!.B8F0C1A2103@async.async.caltech.edu>, , <20100420180715.52C391A2103@async.async.caltech.edu>, <4BCF11E1.5090609@lcwb.coop>, <20100421185631.GA17051@topoi.pooq.com>, <80775CA2-A2FD-40AF-B235-7DB84127762E@cs.purdue.edu>, <20100422123805.GA19259@topoi.pooq.com>, <87B45DCC-2B8A-4C69-97D7-240BC1E2252D@cs.purdue.edu>, <20100422145522.GA19946@topoi.pooq.com> Message-ID: I have to add something. There is another use of LONGINT. Kind of an annoying practical one, and a minor side affect. Not really a nice abstract one. And in fact, it implies a sort of use of "INT128". To declare opaque data with a particular alignment. To match an external definition. Specifically, jmpbuf. Many systems want a 64bit aligned jmpbuf. Even some 32bit ones. e.g. ALPHA32_VMS. But it isn't the only one. There are systems that prefer as high as 128 bit aligned jmpbuf, but I think are ok with less aligned (PPC_LINUX), or not (PA64_HPUX?). I'm not able to declare these today. And C doesn't do this necessarily with larger types, but with other syntax. I think 32bit Linux/ppc says something like: typedef struct __attribute___(align(128)) { /* 32 is ok, but 128 is ideal */ ... } jmpbuf; Ok, details: Oh. Maybe I should use "double" for this purpose? I did sometimes. I forgot. That solves part of the problem, as much as LONGINT solves. http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/C/PA32_HPUX/Csetjmp.i3?rev=1.3;content-type=text%2Fplain (* 200 bytes with 8 byte alignment *) TYPE jmp_buf = ARRAY [0..24] OF double; http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/C/PPC_LINUX/Csetjmp.i3?rev=1.10;content-type=text%2Fplain (* ideal alignment is 16 bytes but 4 is ok; 8 here *) TYPE jmp_buf = ARRAY [0..73] OF LONGINT; http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/C/PA64_HPUX/Csetjmp.i3?rev=1.3;content-type=text%2Fplain (* 640 bytes with 16 byte alignment if we can get it, else 8 byte alignment, which is the best we can ask for (front end internally uses 16 byte alignment) *) TYPE jmp_buf = ARRAY [0..79] OF double; I should use double? Or we should have another way to say this? Or, for that matter, as I've suggested, we shouldn't duplicate the information both in Csetjmp.i3 and Target.m3? Target.m3 has available to it arbitrary alignment. Ok, PPC_LINUX and PA32/64_HPUX were the only ones I could find that want >4 alignment on 32bit, or >8 on 64bit. And 8 on 32 you can get with double. I had forgotten about that technique. I think this is at least another good argument for removing the type declaration from Csetjmp.i3, maybe the function too, and putting it only in Target.m3 (Target.m3 currently only declares setjmp, not longjmp). If not a way to declare alignment in the language. The thing is, you know, the only need for this is to match external/C definitions, and those definitions are now tremendously more under our control than they used to be, so the need to describe "anything" is reduced. Tony is that at all difficult? Injecting the jmpbuf and longjmp information from Target.m3 instead of in Csetjmp.i3? I'll try to get to it. I'd like to further reduce the volume and "wide distribution" of target-specific data. There's still a lot of duplication and non-centralization. - Jay > Date: Thu, 22 Apr 2010 10:55:23 -0400 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] INTEGER > > On Thu, Apr 22, 2010 at 02:36:17PM -0400, Tony Hosking wrote: > > Let me see. > > > > The green book definition says the base type of a subrange of INTEGER literals is INTEGER. > > You say that the base type of a subrange of LONGINT literals is LONGINT. > > But you say that LONGINT is not a defined type. So, what is the type > > of a LONGINT literal? > > (a) 3849587394875493920398438483929293484L could very well be of type > 3849587394875493920398438483929293484L..3849587394875493920398438483929293484L > which is a one-element subtype of LONGINT. > > LONGINY is a type. It's just one that's not available directly to the > programmer. It would not need to have a defined size, if the language > allowed LONGINT values to occur *only* where an upper bound on > their size is known, such as by being elements of a subrange. > > -- hendrik > > > > > [I think I misunderstood you previously. I had interpreted that you meant LONGINT subranges to have base type INTEGER.] > > > > On 22 Apr 2010, at 08:38, hendrik at topoi.pooq.com wrote: > > > > > On Thu, Apr 22, 2010 at 11:57:16AM -0400, Tony Hosking wrote: > > >> But this is bizarre. What type does an element of a subrange of > > >> LONGINT have if not LONGINT? > > > > > > It has LONGINT as a type. > > > > > >> If the subrange has a base type of INTEGER then we need a mapping > > >> between the elements of the subrange and the base INTEGER values. > > > > > > Yes. And INTEGER is different from the notion mathematicians have of > > > integers in that there is a limit on the size of integers. It's a > > > machine or implementation-dependent limit, and it's imposed for > > > efficiency reasons, but it's a specific limit just the same. > > > This limit is precisely what we're up against. > > > > > >> But then, values of the LONGINT subrange don't have the same > > >> representation as their INTEGER counterpart. > > > > > > Of course not. If they did have the same representation, there would be > > > in-range for INTEGERs, and there would be no need to have LONGINT at > > > all. > > > > > > LONGINT is there precisely for the integers that *don't* fit in INTEGER. > > > > > >> > > >> All very odd. > > > > > > But dictated by the intended use -- that of having integral ranges > > > whose bounds are dictated by the problem, not the hardware. > > > > > > -- hendrik > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.async.caltech.edu Fri Apr 23 07:04:24 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Thu, 22 Apr 2010 22:04:24 -0700 Subject: [M3devel] INTEGER In-Reply-To: <4BCF11E1.5090609@lcwb.coop> References: , , , , , , <20100418023535.3BA9E1A2103@async.async.caltech.edu>, , , , <20100418024703.6965B1A2103@async.async.caltech.edu>, , <20100418074927.934461A2117@async.async.caltech.edu>, <04EB7FF8-D304-428D-839E-233FCE009C98@cs.purdue.edu>, <20100418195901.CDACB1A20F6@async.async.caltech.edu>, , <20100419172313.68B241A20D6@async.async.caltech.edu>, <4F3EE437-0298-410B-9642-C0381E333430@cs.purdue.edu> <20100419223152.3D7331A2122@async.async.caltech.edu> <4BCDC866.6050804@lcwb.coop> <20100420171235! .B8F0C1A2103@async.async.caltech.edu> <20100420180715.52C391A2103@async.async.caltech.edu> <4BCF11E1.5090609@lcwb.coop> Message-ID: <20100423050424.77EBE1A2106@async.async.caltech.edu> "Rodney M. Bates" writes: ... >It has never been motivated by the existence of machines with various native >arithmetic sizes. It is about problems that need big value ranges to work. > >Its also about making it convenient to write portable code that solves >them. (Well, that part does have to do with the machines that exist.) >And making the type checking, etc. not change on the different machines. >And using the most efficient arithmetic consistent with correct answers. > >Normally we're dealing with the situation >> that N=32 and M=64.) So we introduce an M-bit LONGINT. Now it stands to >> reason that if the M-bit machine (which I do not own and upon which my >> program does not run) is important to me, it is also important to other >> Modula-3 programmers. Hence all other implementations of Modula-3 will >> *also* provide M-bit integers. >> >> The M-bit machine of the previous paragraph is of course, in the real >> world, a machine with the 64-bit version of the Intel x86 instruction set, >> "amd64". How long is it from here to the point where we have programmers >> who write code that depends on the fact that M=64, always? > >LONGINT presents the same opportunity/invitation/temptation to >write code that make such assumptions as does INTEGER, or for that matter, >REFANY, or gobs of other things in the original language. So LONGINT is >just as evil as INTEGER. It is precisely my point that LONGINT is equally evil as INTEGER. The language doesn't need two "evil" integer types. If there is to be another one (an inefficient one, to boot!) I think it had better offer something that INTEGER does not (such as Hendrik's suggestion). In fact since I have now seen it suggested that LONGINT be at least 64 bits wide, (correct) LONGINT-based code will be *less* portable than (correct) INTEGER code, which is allowed to make no such assumptions and hence has to work whether INTEGER is 16, 32, 36, or even 666 bits wide. Mika From mika at async.async.caltech.edu Fri Apr 23 07:29:35 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Thu, 22 Apr 2010 22:29:35 -0700 Subject: [M3devel] INTEGER In-Reply-To: <80775CA2-A2FD-40AF-B235-7DB84127762E@cs.purdue.edu> References: <4F3EE437-0298-410B-9642-C0381E333430@cs.purdue.edu> <20100419223152.3D7331A2122@async.async.caltech.edu> <4BCDC866.6050804@lcwb.coop> <20100420171235!.B8F0C1A2103@async.async.caltech.edu> <20100420180715.52C391A2103@async.async.caltech.edu> <4BCF11E1.5090609@lcwb.coop> <20100421185631.GA17051@topoi.pooq.com> <80775CA2-A2FD-40AF-B235-7DB84127762E@cs.purdue.edu> Message-ID: <20100423052935.07F7C1A20F1@async.async.caltech.edu> My "proposal" would be TEXT-like bignums. Subranges would have to be based on LONGINT constants. Decree that they are instances of a particular GENERIC INTERFACE maybe. Hrmmm... TYPE Range = [ 1L .. 1000L*1000L*1000L*1000L ]; equivalent to REVEAL LONGINT <: ROOT; TYPE LongInt.T = LONGINT; GENERIC INTERFACE LongIntRange(R); TYPE T = LONGINT BRANDED LongInt.ToText(R.Low) & "_" & LongInt.ToText(R.High) OBJECT END; END LongIntRange. INTERFACE RR; CONST Low = 1L; High = 1000L*1000L*1000L*1000L; END RR. INTERFACE RRType = LongIntRange(RR) END RRType. TYPE Range = RRType.T; or somesuch... hrmph too complicated? It looks a lot like TEXT still. I just introduced a new function that the compiler needs to know: LongInt.ToText. And a fake interface. Ho hum, yes complicated. But it looks like a pretty normal Modula-3 type after these gyrations... Mika Tony Hosking writes: >But this is bizarre. What type does an element of a subrange of LONGINT = >have if not LONGINT? If the subrange has a base type of INTEGER then we = >need a mapping between the elements of the subrange and the base INTEGER = >values. But then, values of the LONGINT subrange don't have the same = >representation as their INTEGER counterpart. > >All very odd. > >On 21 Apr 2010, at 14:56, hendrik at topoi.pooq.com wrote: > >> On Wed, Apr 21, 2010 at 09:55:29AM -0500, Rodney M. Bates wrote: >>>=20 >>>=20 >>> Mika Nystrom wrote: >>>> Tony Hosking writes: >>>>> On 20 Apr 2010, at 13:12, Mika Nystrom wrote: >>>> ... >>>>>> easy access to the hardware in their own machines, not really so = >that =3D >>>>> IBM >>>>>> programmers could have an extra format for VAX compatibility. = >Note =3D >>>>> that >>>>>> I don't believe that it was intended that EXTENDED would be = >emulated =3D >>>>> by >>>>>> the compiler either: the point was really to give programmers = >access =3D >>>>> to >>>>>> the formats provided efficiently by their hardware. >>>>> In the current implementation EXTENDED=3D3DLONGREAL. >>>>=20 >>>> Ok, but EXTENDED is still something that is efficiently provided by >>>> my hardware. Not something efficiently provided by someone else's >>>> hardware! >>>>=20 >>>>>> 4. I still haven't seen any really convincing use cases. What's = >it =3D >>>>> for? >>>>>> The lack of LONGINT was an obstacle to what, precisely? >>>>> I think the only one we have is file sizes... >>>>>=20 >>>>>> 5. Finally, is it the intention that LONGINT be fixed at 64 bits >>>>>> forevermore? (See point 2.) This seems to completely fly in the = >face >>>>>> of M3's philosophy. (See Hendrik's arguments.) >>>>> The only constraint imposed is BITSIZE(LONGINT) >=3D3D = >BITSIZE(INTEGER). >>>>=20 >>>> I am not so sure here. >>>>=20 >>>> Rodney's argument has in fact convinced me that the current version = >of >>>> LONGINT is wrong and perhaps evil. It should either go away = >completely >>>> or be replaced by Hendrik's suggestion. >>>>=20 >>>> Here's why. The argument is that if I have an N-bit machine, for = >N>>> out there in the world there is an M-bit machine that for some = >reason >>>> matters a great deal to me. For some reason I need to be able to = >write >>>> code that manipulates M-bit integers---because of the existence of = >this >>>> M-bit machine (or machines)! =20 >>>=20 >>> It has never been motivated by the existence of machines with various = >native >>> arithmetic sizes. It is about problems that need big value ranges to = >work. >>>=20 >>> Its also about making it convenient to write portable code that = >solves >>> them. (Well, that part does have to do with the machines that exist.) >>> And making the type checking, etc. not change on the different = >machines. >>> And using the most efficient arithmetic consistent with correct = >answers. >>>=20 >>> Normally we're dealing with the situation >>>> that N=3D32 and M=3D64.) So we introduce an M-bit LONGINT. Now it = >stands to >>>> reason that if the M-bit machine (which I do not own and upon which = >my >>>> program does not run) is important to me, it is also important to = >other >>>> Modula-3 programmers. Hence all other implementations of Modula-3 = >will >>>> *also* provide M-bit integers. =20 >>>>=20 >>>> The M-bit machine of the previous paragraph is of course, in the = >real >>>> world, a machine with the 64-bit version of the Intel x86 = >instruction set, >>>> "amd64". How long is it from here to the point where we have = >programmers >>>> who write code that depends on the fact that M=3D64, always? >>>=20 >>> LONGINT presents the same opportunity/invitation/temptation to >>> write code that make such assumptions as does INTEGER, or for that = >matter, >>> REFANY, or gobs of other things in the original language. So LONGINT = >is >>> just as evil as INTEGER. >>=20 >> Which is why I'd allow only subranges of LONGINT to be mentioned in=20 >> programs. >>=20 >> -- hendrik >>=20 >>>=20 >>>>=20 >>>> Mika >>>>=20 >>>>=20 From mika at async.async.caltech.edu Fri Apr 23 07:38:51 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Thu, 22 Apr 2010 22:38:51 -0700 Subject: [M3devel] INTEGER In-Reply-To: References: <20100419223152.3D7331A2122@async.async.caltech.edu>, <4BCDC866.6050804@lcwb.coop>, <20100420171235!.B8F0C1A2103@async.async.caltech.edu>, , <20100420180715.52C391A2103@async.async.caltech.edu>, <4BCF11E1.5090609@lcwb.coop>, <20100421185631.GA17051@topoi.pooq.com>, <80775CA2-A2FD-40AF-B235-7DB84127762E@cs.purdue.edu>, <20100422123805.GA19259@topoi.pooq.com>, <87B45DCC-2B8A-4C69-97D7-240BC1E2252D@cs.purdue.edu>, <20100422145522.GA19946@topoi.pooq.com> Message-ID: <20100423053851.DB8DB1A20CF@async.async.caltech.edu> Jay K writes: >--_7f0c333b-7807-4538-bdd6-306666b4a0e7_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >I have to add something. There is another use of LONGINT. > >Kind of an annoying practical one=2C and a minor side affect. Not really a = >nice abstract one. > >And in fact=2C it implies a sort of use of "INT128". > >=20 > >=20 > >To declare opaque data with a particular alignment. > >=20 > >=20 > >To match an external definition. > >Specifically=2C jmpbuf. > >Many systems want a 64bit aligned jmpbuf. But does Modula-3 *allocate* jmpbufs? If not, why does the declaration have to record that C is guaranteed to allocate the jmpbufs with a certain alignment? I don't think this type of stuff belongs anywhere near the language definition. If it's really needed it ought to be in compiler pragmas. (I think.) Mika From wagner at elegosoft.com Fri Apr 23 09:52:08 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 23 Apr 2010 09:52:08 +0200 Subject: [M3devel] type in m3tests/src/m3makefile Message-ID: <20100423095208.ut3mklu58gkg00kw@mail.elegosoft.com> It seems I've just committed a syntax error to the m3tests makefile this morning: "/ad0e/home/hudson/workspace/cm3-test-m3tests-AMD64_FREEBSD/cm3/m3-sys/m3tests/AMD64_FREEBSD/m3make.args", line 5: quake runtime error: /ad0e/home/hudson/workspace/cm3-test-m3tests-AMD64_FREEBSD/cm3/m3-sys/m3tests/src/m3makefile, line 331: syntax error: missing: ] (found: ) This is on the release branch. I can only fix it tonight. If anybody is faster, that would be welcome. 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 hendrik at topoi.pooq.com Fri Apr 23 11:49:03 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 23 Apr 2010 05:49:03 -0400 Subject: [M3devel] INTEGER In-Reply-To: <270A99B5-173E-413B-8C28-E1CA68870FD4@cs.purdue.edu> References: <20100420180715.52C391A2103@async.async.caltech.edu> <4BCF11E1.5090609@lcwb.coop> <20100421185631.GA17051@topoi.pooq.com> <80775CA2-A2FD-40AF-B235-7DB84127762E@cs.purdue.edu> <20100422123805.GA19259@topoi.pooq.com> <87B45DCC-2B8A-4C69-97D7-240BC1E2252D@cs.purdue.edu> <20100422145522.GA19946@topoi.pooq.com> <28339030-6005-4C28-872C-A68CF24BF4DF@cs.purdue.edu> <20100422154357.GA20043@topoi.pooq.com> <270A99B5-173E-413B-8C28-E1CA68870FD4@cs.purdue.edu> Message-ID: <20100423094903.GC21281@topoi.pooq.com> On Thu, Apr 22, 2010 at 03:44:03PM -0400, Tony Hosking wrote: > Defined as... A type whose values are integers. If it's only used as subranges, its infinite extent is not an implementation difficulty. -- hendrik > > On 22 Apr 2010, at 11:43, hendrik at topoi.pooq.com wrote: > > > On Thu, Apr 22, 2010 at 03:27:50PM -0400, Tony Hosking wrote: > >> This is bizarre, and perverts the language definition significantly more than the current scheme. > >> What is the base type of that subrange? > > > > LONGINT. > > > > -- hendrik > > k From mika at async.async.caltech.edu Fri Apr 23 20:52:14 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Fri, 23 Apr 2010 11:52:14 -0700 Subject: [M3devel] INTEGER In-Reply-To: <20100423094903.GC21281@topoi.pooq.com> References: <20100420180715.52C391A2103@async.async.caltech.edu> <4BCF11E1.5090609@lcwb.coop> <20100421185631.GA17051@topoi.pooq.com> <80775CA2-A2FD-40AF-B235-7DB84127762E@cs.purdue.edu> <20100422123805.GA19259@topoi.pooq.com> <87B45DCC-2B8A-4C69-97D7-240BC1E2252D@cs.purdue.edu> <20100422145522.GA19946@topoi.pooq.com> <28339030-6005-4C28-872C-A68CF24BF4DF@cs.purdue.edu> <20100422154357.GA20043@topoi.pooq.com> <270A99B5-173E-413B-8C28-E1CA68870FD4@cs.purdue.edu> <20100423094903.GC21281@topoi.pooq.com> Message-ID: <20100423185214.BA2EF1A20E1@async.async.caltech.edu> Is the infinite extent of the TEXT type a serious implementation difficulty? :-) Mika hendrik at topoi.pooq.com writes: >On Thu, Apr 22, 2010 at 03:44:03PM -0400, Tony Hosking wrote: >> Defined as... > >A type whose values are integers. If it's only used as subranges, >its infinite extent is not an implementation difficulty. > >-- hendrik > >> >> On 22 Apr 2010, at 11:43, hendrik at topoi.pooq.com wrote: >> >> > On Thu, Apr 22, 2010 at 03:27:50PM -0400, Tony Hosking wrote: >> >> This is bizarre, and perverts the language definition significantly more than the current scheme. >> >> What is the base type of that subrange? >> > >> > LONGINT. >> > >> > -- hendrik >> > >k From jay.krell at cornell.edu Fri Apr 23 22:29:57 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 23 Apr 2010 20:29:57 +0000 Subject: [M3devel] word vs. long vs. pointer in parse.c Message-ID: I believe where parse.c uses BITS_PER_WORD, it should use POINTER_SIZE. The docs allude that "word" is a register. On Alpha32, that is 64 bits. However on Alpha32, LONG_SIZE and POINTER_SIZE are 32. This leads to assertion failures in parse.c about the type to the set functions being t_int. I imagine Alpha32 is a little strange, but that it exists for better source compatibility with VAX and maybe even HP-UX, and to keep data stored in memory and on disk smaller where 32bits suffices. (IA64 has 32bit modes also, I forgot if in HP-UX or VMS or both. Not necessarily hardware modes, but code gen modes. I wasn't planning on an IA6432_HPUX, IA6432_VMS ports though, just IA64_HPUX and IA64_VMS) The assertion failures went away when I tried LONG_SIZE. For purposes of AMD64_MINGW though, LONG_SIZE might be wrong and POINTER_SIZE the all around answer. I still have to test this on other platforms. That leaves I think just atomics failing all over for ALPHA32_VMS. ALPHA64_VMS I can already produce all the assembly for cm3 (including atomics apparently). I haven't yet assembled/linked/run it. Doing native-hosted builds of cm3cg might not be viable. (Since I haven't assembled/linked, and didn't look at the code, could be the atomics are function calls.) Another strange thing I think I saw is that sizeof(long,size_t,ptrdiff_t) with cc /pointer_size=64 is 4, but with alpha64-dec-vms-gcc it is 8. I think we might want something like: #if __pointer_size == 64 /* whatever cc /pointer_size=64 defines */ typedef __int64 INTEGER; typedef unsigned __int64 WORD; #else typedef ptrdiff_t INTEGER; typedef size_t WORD; #endif and use INTEGER and WORD whenever C code is interoperating with Modula-3. Maybe just punt ALPHA32_VMS? These systems don't have gobs of memory by modern standards -- the one I'm using is multi-user and has 768MB -- so the smaller data size might be worthwhile over ALPHA64_VMS. ? The platform seems fairly viable so far though. - Jay From hendrik at topoi.pooq.com Fri Apr 23 18:56:13 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 23 Apr 2010 12:56:13 -0400 Subject: [M3devel] INTEGER In-Reply-To: <20100423185214.BA2EF1A20E1@async.async.caltech.edu> References: <20100421185631.GA17051@topoi.pooq.com> <80775CA2-A2FD-40AF-B235-7DB84127762E@cs.purdue.edu> <20100422123805.GA19259@topoi.pooq.com> <87B45DCC-2B8A-4C69-97D7-240BC1E2252D@cs.purdue.edu> <20100422145522.GA19946@topoi.pooq.com> <28339030-6005-4C28-872C-A68CF24BF4DF@cs.purdue.edu> <20100422154357.GA20043@topoi.pooq.com> <270A99B5-173E-413B-8C28-E1CA68870FD4@cs.purdue.edu> <20100423094903.GC21281@topoi.pooq.com> <20100423185214.BA2EF1A20E1@async.async.caltech.edu> Message-ID: <20100423165613.GA22126@topoi.pooq.com> On Fri, Apr 23, 2010 at 11:52:14AM -0700, Mika Nystrom wrote: > > Is the infinite extent of the TEXT type a serious implementation difficulty? :-) Yes, actually. It requires heap storage allocation and indirection. That's just what it costs, so we pay it, since fixed-width strings aren't all that useful. But integer ranges of a size that matches the application (instead of the hardware) are quite feasible and useful; I'd rather not pay the proce of dynamic heap allocation for each integer. -- hendrik > > Mika > > hendrik at topoi.pooq.com writes: > >On Thu, Apr 22, 2010 at 03:44:03PM -0400, Tony Hosking wrote: > >> Defined as... > > > >A type whose values are integers. If it's only used as subranges, > >its infinite extent is not an implementation difficulty. > > > >-- hendrik > > > >> > >> On 22 Apr 2010, at 11:43, hendrik at topoi.pooq.com wrote: > >> > >> > On Thu, Apr 22, 2010 at 03:27:50PM -0400, Tony Hosking wrote: > >> >> This is bizarre, and perverts the language definition significantly more than the current scheme. > >> >> What is the base type of that subrange? > >> > > >> > LONGINT. > >> > > >> > -- hendrik > >> > > >k From mika at async.async.caltech.edu Sat Apr 24 12:34:35 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Sat, 24 Apr 2010 03:34:35 -0700 Subject: [M3devel] INTEGER In-Reply-To: <20100423165613.GA22126@topoi.pooq.com> References: <20100421185631.GA17051@topoi.pooq.com> <80775CA2-A2FD-40AF-B235-7DB84127762E@cs.purdue.edu> <20100422123805.GA19259@topoi.pooq.com> <87B45DCC-2B8A-4C69-97D7-240BC1E2252D@cs.purdue.edu> <20100422145522.GA19946@topoi.pooq.com> <28339030-6005-4C28-872C-A68CF24BF4DF@cs.purdue.edu> <20100422154357.GA20043@topoi.pooq.com> <270A99B5-173E-413B-8C28-E1CA68870FD4@cs.purdue.edu> <20100423094903.GC21281@topoi.pooq.com> <20100423185214.BA2EF1A20E1@async.async.caltech.edu> <20100423165613.GA22126@topoi.pooq.com> Message-ID: <20100424103435.A1CC41A20C2@async.async.caltech.edu> hendrik at topoi.pooq.com writes: >On Fri, Apr 23, 2010 at 11:52:14AM -0700, Mika Nystrom wrote: >> >> Is the infinite extent of the TEXT type a serious implementation difficulty? :-) > >Yes, actually. It requires heap storage allocation and indirection. That's just what >it costs, so we pay it, since fixed-width strings aren't all that useful. > >But integer ranges of a size that matches the application (instead of the hardware) >are quite feasible and useful; I'd rather not pay the proce of dynamic heap allocation >for each integer. > >-- hendrik Ok here I have a proposal, modeled on how Modula-3 does arrays. The type specifier LONGINT to be valid in every context where an open array is valid. A subrange of LONGINT to be treated like a non-open array. NEW(REF LONGINT, ..) would take two "size" specifiers, a minimum and a maximum, of type LONGINT. For L, U, LONGINT literals, NEW(REF LONGINT, L, U) would produce the same thing as NEW(REF [L..U]) NEW(REF LONGINT, ..) is needed for dynamically sized LONGINTs. And then overload the arithmetic operations, the way arrays and REF RECORDs are, so that for b and c REF LONGINT, b + c = b^ + c = b + c^ = b^ + c^ Assignments carry an implicit range check. Assignment rules the same as INTEGER and its subranges. Use VAL to convert...? In short, expressions involving LONGINT have type LONGINT, but no "bare" LONGINT can ever be created. However note the following, perfectly legal. WITH a = b + c, r = NEW(REF LONGINT, a, a) DO r^ := a END Also legal, note parameters: PROCEDURE Collatz(READONLY a : LONGINT; VAR b : LONGINT) = BEGIN CASE a MOD 2L OF 0L => b := a DIV 2L | 1L => b := 3L * a + 1L END END Collatz; VALUE a : LONGINT would be discouraged. Returning LONGINT would *not* be legal. ARRAY OF LONGINT would mean the LONGINTs are limited to the same range, and used in NEW would take three arguments, one of type INTEGER for the array size and two of type LONGINT to specify the LONGINTs' bounds. Perhaps... PROCEDURE Collatz2(READONLY a : LONGINT; VAR b : LONGINT) RAISES { Range } = BEGIN CASE a MOD 2L OF 0L => b := a DIV 2L | 1L => WITH new = 3L * a + 1L DO (* is new actually stored anywhere!? *) IF new > LAST(b) THEN RAISE Range ELSE b := new END END END END Collatz2; My proposal gives you both heap-allocated dynamically sized LONGINT and stack-allocated fixed-sized longints and allows you to mix them at will. Collatz2 does seem a little bit disturbing, however. Can we rely on alloca "under the covers"? (Architectures that don't provide alloca could heap-allocate new in that example, *if* they need to.) Another thing that occurs to me is that while + and - are straightforward, *, DIV, and MOD are things you may well want to use very special and specific algorithms for in a given application. It makes sense to let the user replace the code for these operations. And now it begins to look like C++. Sigh. Hendrik, I do think WITH causes similar problems even for strictly range-limited numbers like the ones you are proposing? (And so does expression evaluation, of course...) Now is it even reasonable to have this built in? What if the user wants lazy evaluation? Are non-lazy LONGINTs very useful? Of course, I have to admit I am using a hardware simulation environment where non-lazy LONGINTs would indeed be very useful. Mika From hosking at cs.purdue.edu Sat Apr 24 18:42:07 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 24 Apr 2010 12:42:07 -0400 Subject: [M3devel] INTEGER In-Reply-To: <20100424103435.A1CC41A20C2@async.async.caltech.edu> References: <20100421185631.GA17051@topoi.pooq.com> <80775CA2-A2FD-40AF-B235-7DB84127762E@cs.purdue.edu> <20100422123805.GA19259@topoi.pooq.com> <87B45DCC-2B8A-4C69-97D7-240BC1E2252D@cs.purdue.edu> <20100422145522.GA19946@topoi.pooq.com> <28339030-6005-4C28-872C-A68CF24BF4DF@cs.purdue.edu> <20100422154357.GA20043@topoi.pooq.com> <270A99B5-173E-413B-8C28-E1CA68870FD4@cs.purdue.edu> <20100423094903.GC21281@topoi.pooq.com> <20100423185214.BA2EF1A20E1@async.async.caltech.edu> <20100423165613.GA22126@topoi.pooq.com> <20100424103435.A1CC41A20C2@async.async.caltech.edu> Message-ID: This sounds like something that should be implemented initially as a library so it can be evaluated for its usefulness. If we need built-ins for efficiency then that could come later as needed. To that end, why not simply say: TYPE LONGINT = ARRAY OF INTEGER and implement operations in the same way as Word? On 24 Apr 2010, at 06:34, Mika Nystrom wrote: > hendrik at topoi.pooq.com writes: >> On Fri, Apr 23, 2010 at 11:52:14AM -0700, Mika Nystrom wrote: >>> >>> Is the infinite extent of the TEXT type a serious implementation difficulty? :-) >> >> Yes, actually. It requires heap storage allocation and indirection. That's just what >> it costs, so we pay it, since fixed-width strings aren't all that useful. >> >> But integer ranges of a size that matches the application (instead of the hardware) >> are quite feasible and useful; I'd rather not pay the proce of dynamic heap allocation >> for each integer. >> >> -- hendrik > > Ok here I have a proposal, modeled on how Modula-3 does arrays. > > The type specifier LONGINT to be valid in every context where an open > array is valid. > > A subrange of LONGINT to be treated like a non-open array. > > NEW(REF LONGINT, ..) would take two "size" specifiers, a minimum and a maximum, > of type LONGINT. > > For L, U, LONGINT literals, > > NEW(REF LONGINT, L, U) > > would produce the same thing as > > NEW(REF [L..U]) > > NEW(REF LONGINT, ..) is needed for dynamically sized LONGINTs. > > And then overload the arithmetic operations, the way arrays and REF RECORDs are, so > that for b and c REF LONGINT, > > b + c = b^ + c = b + c^ = b^ + c^ > > Assignments carry an implicit range check. > > Assignment rules the same as INTEGER and its subranges. > > Use VAL to convert...? > > In short, expressions involving LONGINT have type LONGINT, but no "bare" LONGINT can > ever be created. > > However note the following, perfectly legal. > > WITH a = b + c, > r = NEW(REF LONGINT, a, a) DO > r^ := a > END > > Also legal, note parameters: > > PROCEDURE Collatz(READONLY a : LONGINT; VAR b : LONGINT) = > BEGIN > CASE a MOD 2L OF > 0L => b := a DIV 2L > | > 1L => b := 3L * a + 1L > END > END Collatz; > > VALUE a : LONGINT would be discouraged. Returning LONGINT > would *not* be legal. ARRAY OF LONGINT would mean the LONGINTs > are limited to the same range, and used in NEW would take three > arguments, one of type INTEGER for the array size and two of type > LONGINT to specify the LONGINTs' bounds. > > Perhaps... > > PROCEDURE Collatz2(READONLY a : LONGINT; VAR b : LONGINT) > RAISES { Range } = > BEGIN > CASE a MOD 2L OF > 0L => b := a DIV 2L > | > 1L => > WITH new = 3L * a + 1L DO (* is new actually stored anywhere!? *) > IF new > LAST(b) THEN > RAISE Range > ELSE > b := new > END > END > END > END Collatz2; > > My proposal gives you both heap-allocated dynamically sized LONGINT and > stack-allocated fixed-sized longints and allows you to mix them at will. > Collatz2 does seem a little bit disturbing, however. Can we rely on > alloca "under the covers"? (Architectures that don't provide alloca > could heap-allocate new in that example, *if* they need to.) > > Another thing that occurs to me is that while + and - are straightforward, > *, DIV, and MOD are things you may well want to use very special and > specific algorithms for in a given application. It makes sense to let the > user replace the code for these operations. And now it begins to look > like C++. Sigh. > > Hendrik, I do think WITH causes similar problems even for strictly > range-limited numbers like the ones you are proposing? (And so does > expression evaluation, of course...) > > Now is it even reasonable to have this built in? What if the user wants > lazy evaluation? Are non-lazy LONGINTs very useful? > > Of course, I have to admit I am using a hardware simulation environment > where non-lazy LONGINTs would indeed be very useful. > > Mika From jay.krell at cornell.edu Sat Apr 24 23:20:49 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 24 Apr 2010 21:20:49 +0000 Subject: [M3devel] unsafe functions that read/write raw memory, integer conversions, obligation of unsafe code? Message-ID: What is the obligation of stuff like:? UNSAFE INTERFACE UnixIO; PROCEDURE read(file:int; buffer: ADDRESS; length: INTEGER); PROCEDURE write(file: int; ADDRESS; length: INTEGER); The reason I ask is kind of tangential. I'll explain it, but it again it doesn't necessarily matter: In m3core/src/unix/Usocket.c we have, my doing: /* assert that *plen fits in a 32 bit signed integer, no matter if it is unsigned or signed, or 32 bits or 64 bits */ #define ASSERT_PLEN \ ??? assert((plen == NULL) || (((*plen)>= 0) && ((*plen) < (m3_socklen_t)(1UL << 30)))); Sometimes *plen is signed, sometimes unsigned. I'm going to make it consistent from platform to platform. I used to try to match the underlying platform and avoid copying. The VMS C compiler is reasonably warning about *plen>= 0 always being true, given unsigned *plen. So I'm wondering again what m3_socklen_t should be anyway. There are at least four candidates: ?? 32bit signed int ?? 32bit unsigned int ?? pointer sized int (INTEGER) ?? pointer sized unsigned integer (Word.T, which is INTEGER but with a different interpretation) The numbers involves are always small and positive. ? It isn't a "buffer" size, but the size of a small struct. Most 64bit C environments use a 32bit unsigned int. Though, again, we don't have to match them. The comments I left say: Cygwin is 32bit int, HP-UX is size_t (32 or 64), the rest are unsigned int. VMS is usually size_t, or int under old setting. An size_t is surprisingly always 32 bits. But again the C settings aren't super relevant. I'm thinking I should definitely make it unsigned. That matches most platforms (which, again, doesn't matter), lets the assertion be cut in half, and thereby removing the warning. But again, what is my "safety obligation"? If some Modula-3 code passes in a "negative" number, am I doing a legitimate favor in failing an assertion? Or they might just as well have passed in an incorrectly very large integer and overflowed their buffer just as well? ? Making negative numbers invalid seems useful at first glance, but then when you realize that pretty darn large numbers ?? will still get through, it seems less useful. Now, thinking about this more, it is not just about avoiding buffer overflow. There is also the matter of truncating integers. If some Modula-3 code passes me the value 4GB + 1 and I in turm truncate that to just 1, I have done something wrong. Integer conversions have to be checked. Therefore, for one thing, I think these wrappers do need to know with certainty what the underlying socken_t is. ? Even on platforms that don't declare it. :) Cygwin and VMS. Asserting that they fit in a half range 32 bit integer is a way to avoid being completely precise. It is acceptable here -- it not the size of a "buffer", but the size of a fairly small struct, a struct addr. ?- Jay From mika at async.async.caltech.edu Sat Apr 24 23:25:23 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Sat, 24 Apr 2010 14:25:23 -0700 Subject: [M3devel] unsafe functions that read/write raw memory, integer conversions, obligation of unsafe code? In-Reply-To: References: Message-ID: <20100424212523.E37411A20B6@async.async.caltech.edu> Unsafe code that exports only an UNSAFE INTERFACE has no particular obligation. Unsafe code that exports a non-UNSAFE INTERFACE has to guarantee the absence of unchecked runtime errors regardless of input---this can be weakened to "regardless of input as long as that input can possibly be provided by a non-UNSAFE module", but the latter might be difficult to verify as it is a global property. Mika Jay K writes: > >What is the obligation of stuff like:? > > >UNSAFE INTERFACE UnixIO=3B > > >PROCEDURE read(file:int=3B buffer: ADDRESS=3B length: INTEGER)=3B >PROCEDURE write(file: int=3B ADDRESS=3B length: INTEGER)=3B > > > >The reason I ask is kind of tangential. > >I'll explain it=2C but it again it doesn't necessarily matter: > >In m3core/src/unix/Usocket.c we have=2C my doing: > > >/* assert that *plen fits in a 32 bit signed integer=2C no matter >if it is unsigned or signed=2C or 32 bits or 64 bits */ > >#define ASSERT_PLEN \ >=A0=A0=A0 assert((plen =3D=3D NULL) || (((*plen)>=3D 0) && ((*plen) < (m3_s= >ocklen_t)(1UL << 30))))=3B > > > >Sometimes *plen is signed=2C sometimes unsigned. >I'm going to make it consistent from platform to platform. >I used to try to match the underlying platform and avoid copying. > > > >The VMS C compiler is reasonably warning about *plen>=3D 0 always being tru= >e=2C given unsigned *plen. >So I'm wondering again what m3_socklen_t should be anyway. >There are at least four candidates: >=A0=A0 32bit signed int >=A0=A0 32bit unsigned int=20 >=A0=A0 pointer sized int (INTEGER) >=A0=A0 pointer sized unsigned integer (Word.T=2C which is INTEGER but with = >a different interpretation) > > >The numbers involves are always small and positive. >=A0 It isn't a "buffer" size=2C but the size of a small struct. >Most 64bit C environments use a 32bit unsigned int. Though=2C again=2C we d= >on't have to match them. >The comments I left say: Cygwin is 32bit int=2C HP-UX is size_t (32 or 64)= >=2C the rest are unsigned int. >VMS is usually size_t=2C or int under old setting. An size_t is surprisingl= >y always 32 bits. >But again the C settings aren't super relevant. > > >I'm thinking I should definitely make it unsigned. >That matches most platforms (which=2C again=2C doesn't matter)=2C lets the = >assertion be cut in half=2C and thereby removing the warning. > > >But again=2C what is my "safety obligation"? >If some Modula-3 code passes in a "negative" number=2C am I doing a legitim= >ate favor in failing an assertion? >Or they might just as well have passed in an incorrectly very large integer= > and overflowed their buffer just as well? >=A0 Making negative numbers invalid seems useful at first glance=2C but the= >n when you realize that pretty darn large numbers >=A0=A0 will still get through=2C it seems less useful. > > >Now=2C thinking about this more=2C it is not just about avoiding buffer ove= >rflow. >There is also the matter of truncating integers. >If some Modula-3 code passes me the value 4GB + 1 and I in turm truncate th= >at to just 1=2C I have done something wrong. >Integer conversions have to be checked. >Therefore=2C for one thing=2C I think these wrappers do need to know with c= >ertainty what the underlying socken_t is. >=A0 Even on platforms that don't declare it. :) Cygwin and VMS. > > >Asserting that they fit in a half range 32 bit integer is a way to avoid be= >ing completely precise. >It is acceptable here -- it not the size of a "buffer"=2C but the size of a= > fairly small struct=2C a struct addr. > > >=A0- Jay > > = From mika at async.async.caltech.edu Sat Apr 24 23:29:52 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Sat, 24 Apr 2010 14:29:52 -0700 Subject: [M3devel] Compiling Modula-3 to C Message-ID: <20100424212952.D9BDE1A20B7@async.async.caltech.edu> The question of making a Modula-3 compiler emit C code as output comes up on this mailing list from time to time. I just discovered a reference to a real example of this. http://caltechcstr.library.caltech.edu/218/01/93-15.pdf Note pages 49-50 (54-55 in the PDF). I also find the byte counts on page 49 interesting. I wish my m3core were that small! Mika From jay.krell at cornell.edu Sat Apr 24 23:58:18 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 24 Apr 2010 21:58:18 +0000 Subject: [M3devel] Compiling Modula-3 to C In-Reply-To: <20100424212952.D9BDE1A20B7@async.async.caltech.edu> References: <20100424212952.D9BDE1A20B7@async.async.caltech.edu> Message-ID: I haven't read this closely yet, I admit. I'm sure we'll get a Modula-3 to C backend before much longer. It greatly increases your real and theoretical platform support for one medium upfront cost, and perhaps a little bit of ongoing maintenance if some oddities are reported. I'll be tired of the old way fairly soon. There remain too many viable but unsupported targets. If it has pthreads (or sigaltstack), POSIX (or NT), and a C compiler, that should be all it takes. Notice that there are now affordable and somewhat performant MIPS laptops that ? run at least Linux and OpenBSD. Notice that FreeBSD is slowly expanding ? its targets, including PowerPC, MIPS, SPARC64. There will probably be an option to generate C++ as well, which should offer more efficient exception handling than portable C. Whether or not it it is all idiomatic and intuitive to interoperate with, unknown. Regarding that paper: One should try to remain mindful of when language change is needed vs. merely library. ?? I didn't read enough to see if they need language changes. ?? I do believe Modula-3 could benefit from some language changes. Though that might be mitigated ?? and/or eliminated by me knowing Modula-3 better. For example, can I have a type with ?? compiler-enforced opacity without requiring heap allocation? C compilers are probably better these days. ?Look -- gcc 4.5 just caught up some with Visual C++ and others and has "LTO": link time optimization. ? I believe Sun also has had this a while, and I'm sure others. ? I rarely turn on optimization though, I admit. ? Disk and network I/O tend to dominate all costs. I don't do heavy computation. Shared libraries are always going to seem bloated because they export everything, even unused stuff. The paper seems little confused on this matter, depending on the quality/behavior of the linker, and whether or not functions are "separated" within object files. Visual C++ has the -Gy flag which you should *always* use. I don't know why it is an even an option. It makes each function within an object separate, so you only link in what you use, and what that references, transitive closure. For better and for worse, data is not linked in with that same high level of granularity. If you get any data from an object, you get it all. And that includes pointers to functions, and whatever those functions call, even if the data isn't referenced. I know that historically linkers didn't strip out anything. I'm surprised such linkers existed. Are they still in use? (What do GNU, Sun, Mac do?) ?- Jay ---------------------------------------- > To: m3devel at elegosoft.com > Date: Sat, 24 Apr 2010 14:29:52 -0700 > From: mika at async.async.caltech.edu > Subject: [M3devel] Compiling Modula-3 to C > > > The question of making a Modula-3 compiler emit C code as output comes > up on this mailing list from time to time. > > I just discovered a reference to a real example of this. > > http://caltechcstr.library.caltech.edu/218/01/93-15.pdf > > Note pages 49-50 (54-55 in the PDF). > > I also find the byte counts on page 49 interesting. I wish my m3core > were that small! > > Mika From mika at async.async.caltech.edu Sun Apr 25 00:23:18 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Sat, 24 Apr 2010 15:23:18 -0700 Subject: [M3devel] Compiling Modula-3 to C In-Reply-To: References: <20100424212952.D9BDE1A20B7@async.async.caltech.edu> Message-ID: <20100424222319.08FF71A20B5@async.async.caltech.edu> Jay, My point in sharing that was not to agitate for making the changes in Modula-3 that Rustan did for his project. (It's his M.S. thesis.) I wanted to show the quality of the assembly code that one existing Modula-3-to-C-to-ASM toolchain has generated. It doesn't look *horrendous* to me, honestly, only maybe the footprint is a bit on the large side. One thing one could try of course is to type in Rustan's generated C code and compare what gcc spits out from compiling it it to the ASM generated by compiling the original M3 code. (On one's favorite modern architecture.) I have Modula-3D in source form so I am sure the Modula-3-to-C compiler is in there, and most of it is in the SRC sources anyhow. MIPS especially. No need to write a brand new one. No you cannot have a type with compiler-enforced opacity without requiring heap allocation. It's a shortcoming of the language, yes. But you know, you can just leave a comment that says the type is opaque. The point of M3's safety rules is to prevent unchecked runtime errors. M3's opaqueness rules are defined in terms of OBJECT which are always references. The designers felt that the C++ objects were too hard to achieve. BY THE WAY, the whole way Modula-3 does opaqueness is in the minds of anal-retentive OO people completely wrong (I think it is brilliant). They would have you declare in your object type who can touch the bits of it. friends, protected, etc. In Modula-3 it's mostly up to the *client* to decide how much opaqueness is right. For example: INTERFACE Q; TYPE T <: Public; END Q. INTERFACE QFriends; REVEAL Q.T <: Friendly; END QFriends. INTERFACE QPrivate; REVEAL Q.T <: Private; END QPrivate. A client R of Q can then go ahead and IMPORT QFriends and QPrivate as it pleases, regardless of what the relationship between R and Q is. (There is a hack in quake to hide certain interfaces but it's only done at one level and it's not part of the Modula-3 language proper.) Thus, Modula-3 assumes that programmers are a bit more responsible than the hiding rules available in C++ or Java. Which is why I say that not having the opaqueness available for non-ref types is not such a big deal, really. The language is trying to help you not make stupid mistakes---it's not some kind of "OO cleanliness police". I have written a lot of M3 code and have indeed missed opaque nonreference objects from time to time, but you learn to live with it, just like you learn to live with the idiosyncracies of any programming language. >From personal experience all I can say is that M3's idiosyncracies are far less annoying than those of any other "practical" programming language I've ever used. (This is not a criticism, but how much M3 have you actually written?) Oh, regarding link-time optimization, see: http://www.modula3.org/threads/2/#linkTimeOptimization Mika Jay K writes: > >I haven't read this closely yet=2C I admit. > > >I'm sure we'll get a Modula-3 to C backend before much longer. >It greatly increases your real and theoretical platform support for >one medium upfront cost=2C and perhaps a little bit of ongoing maintenance = >if some oddities are reported. >I'll be tired of the old way fairly soon. >There remain too many viable but unsupported targets. >If it has pthreads (or sigaltstack)=2C POSIX (or NT)=2C and a C compiler=2C= > that should be all it takes. >Notice that there are now affordable and somewhat performant MIPS laptops t= >hat >=A0 run at least Linux and OpenBSD. Notice that FreeBSD is slowly expanding >=A0 its targets=2C including PowerPC=2C MIPS=2C SPARC64. > > >There will probably be an option to generate C++ as well=2C which >should offer more efficient exception handling than portable C. > >Whether or not it it is all idiomatic and intuitive to interoperate with=2C= > unknown. > >Regarding that paper: > >One should try to remain mindful of when language change is needed vs. mere= >ly library. >=A0=A0 I didn't read enough to see if they need language changes. >=A0=A0 I do believe Modula-3 could benefit from some language changes. Thou= >gh that might be mitigated >=A0=A0 and/or eliminated by me knowing Modula-3 better. For example=2C can = >I have a type with >=A0=A0 compiler-enforced opacity without requiring heap allocation? > >C compilers are probably better these days. >=A0Look -- gcc 4.5 just caught up some with Visual C++ and others and has "= >LTO": link time optimization. >=A0 I believe Sun also has had this a while=2C and I'm sure others. >=A0 I rarely turn on optimization though=2C I admit. >=A0 Disk and network I/O tend to dominate all costs. I don't do heavy compu= >tation. > > >Shared libraries are always going to seem bloated because they export every= >thing=2C >even unused stuff. > > >The paper seems little confused on this matter=2C depending on the >quality/behavior of the linker=2C and whether or not functions are "separat= >ed" within >object files. Visual C++ has the -Gy flag which you should *always* use. >I don't know why it is an even an option. It makes each function within an = >object >separate=2C so you only link in what you use=2C and what that references=2C= > transitive closure. >For better and for worse=2C data is not linked in with that same high level= > of granularity. >If you get any data from an object=2C you get it all. >And that includes pointers to functions=2C and whatever those functions cal= >l=2C even >if the data isn't referenced. > > >I know that historically linkers didn't strip out anything. >I'm surprised such linkers existed. Are they still in use? >(What do GNU=2C Sun=2C Mac do?) > > >=A0- Jay > >---------------------------------------- >> To: m3devel at elegosoft.com >> Date: Sat=2C 24 Apr 2010 14:29:52 -0700 >> From: mika at async.async.caltech.edu >> Subject: [M3devel] Compiling Modula-3 to C >> >> >> The question of making a Modula-3 compiler emit C code as output comes >> up on this mailing list from time to time. >> >> I just discovered a reference to a real example of this. >> >> http://caltechcstr.library.caltech.edu/218/01/93-15.pdf >> >> Note pages 49-50 (54-55 in the PDF). >> >> I also find the byte counts on page 49 interesting. I wish my m3core >> were that small! >> >> Mika > = From jay.krell at cornell.edu Sun Apr 25 00:56:28 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 24 Apr 2010 22:56:28 +0000 Subject: [M3devel] Compiling Modula-3 to C In-Reply-To: <20100424222319.08FF71A20B5@async.async.caltech.edu> References: <20100424212952.D9BDE1A20B7@async.async.caltech.edu>, , <20100424222319.08FF71A20B5@async.async.caltech.edu> Message-ID: Agitation not necessarly inferred. :) Mika, the thing is.. consider "safety". I can argue..as a C programmer..I know what is safe, I don't need the language protection. Practise proves this is somewhat true, somewhat false. ?? ? Similar to your argument: ?I know what is opaque, I don't need the language protection. ? I don't think a comment declaring opacity is strong enough. C++ does this better, even though also a little weak. In C++ I would put in "private:" and the compiler enforces it. If someone is determined to break through, they must edit the header, possibly recompile, or duplicate the declaration without private and cast. There is no accidental violation of private. I understand there is the issue of the size still being revealed ? which is an important practical matter in terms of coupling ? and need to rebuild. But at the abstract enforced interface ? level, it doesn't matter. I understand that C++ is a little bit complicated, with public/private/protected, and friends. And C# has more options (visible to the assembly/.dll). I think at least one bit is worthwhile though. public or private. Public to all or nobody. I doubt new syntax would even be needed. Just like: foo.i3: TYPE Foo; or TYPE FooPublic = RECORD END; TYPE <: FooPublic; foo.m3 ?REVEAL Foo = RECORD ... END; Target.Int I think is a good example. It is small, fixed size, not a reference, not separately/heap allocated. But it is opaque only via comment. I have a 2.x tree somewhere, recently downloaded from the web. It does Modula-3-to-C within what was and is m3front. The "design" of the output C can be reclaimed. The code has to/should be sprinkled around elsewhere, behind an implementation of CG.i3. And as you allude, I might try doing it from scratch anyway. :) ?- Jay ---------------------------------------- > To: jay.krell at cornell.edu > Date: Sat, 24 Apr 2010 15:23:18 -0700 > From: mika at async.async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Compiling Modula-3 to C > > Jay, > > My point in sharing that was not to agitate for making the changes in > Modula-3 that Rustan did for his project. (It's his M.S. thesis.) > > I wanted to show the quality of the assembly code that one existing > Modula-3-to-C-to-ASM toolchain has generated. It doesn't look > *horrendous* to me, honestly, only maybe the footprint is a bit on the > large side. One thing one could try of course is to type in Rustan's > generated C code and compare what gcc spits out from compiling it it to > the ASM generated by compiling the original M3 code. (On one's favorite > modern architecture.) > > I have Modula-3D in source form so I am sure the Modula-3-to-C compiler is > in there, and most of it is in the SRC sources anyhow. MIPS especially. > No need to write a brand new one. > > No you cannot have a type with compiler-enforced opacity without requiring > heap allocation. It's a shortcoming of the language, yes. But you know, > you can just leave a comment that says the type is opaque. > > The point of M3's safety rules is to prevent unchecked runtime errors. > > M3's opaqueness rules are defined in terms of OBJECT which are always > references. The designers felt that the C++ objects were too hard to > achieve. > > BY THE WAY, the whole way Modula-3 does opaqueness is in the minds of > anal-retentive OO people completely wrong (I think it is brilliant). > They would have you declare in your object type who can touch the > bits of it. friends, protected, etc. In Modula-3 it's mostly up to > the *client* to decide how much opaqueness is right. > > For example: > > INTERFACE Q; TYPE T <: Public; END Q. > > INTERFACE QFriends; REVEAL Q.T <: Friendly; END QFriends. > > INTERFACE QPrivate; REVEAL Q.T <: Private; END QPrivate. > > A client R of Q can then go ahead and IMPORT QFriends and QPrivate as > it pleases, regardless of what the relationship between R and Q is. > (There is a hack in quake to hide certain interfaces but it's only > done at one level and it's not part of the Modula-3 language proper.) > > Thus, Modula-3 assumes that programmers are a bit more responsible than > the hiding rules available in C++ or Java. Which is why I say that > not having the opaqueness available for non-ref types is not such a big > deal, really. The language is trying to help you not make stupid > mistakes---it's not some kind of "OO cleanliness police". > > I have written a lot of M3 code and have indeed missed opaque nonreference > objects from time to time, but you learn to live with it, just like > you learn to live with the idiosyncracies of any programming language. > From personal experience all I can say is that M3's idiosyncracies > are far less annoying than those of any other "practical" programming > language I've ever used. (This is not a criticism, but how much M3 have > you actually written?) > > Oh, regarding link-time optimization, see: > > http://www.modula3.org/threads/2/#linkTimeOptimization > > Mika > > > > Jay K writes: >> >>I haven't read this closely yet=2C I admit. >> >> >>I'm sure we'll get a Modula-3 to C backend before much longer. >>It greatly increases your real and theoretical platform support for >>one medium upfront cost=2C and perhaps a little bit of ongoing maintenance = >>if some oddities are reported. >>I'll be tired of the old way fairly soon. >>There remain too many viable but unsupported targets. >>If it has pthreads (or sigaltstack)=2C POSIX (or NT)=2C and a C compiler=2C= >> that should be all it takes. >>Notice that there are now affordable and somewhat performant MIPS laptops t= >>hat >>=A0 run at least Linux and OpenBSD. Notice that FreeBSD is slowly expanding >>=A0 its targets=2C including PowerPC=2C MIPS=2C SPARC64. >> >> >>There will probably be an option to generate C++ as well=2C which >>should offer more efficient exception handling than portable C. >> >>Whether or not it it is all idiomatic and intuitive to interoperate with=2C= >> unknown. >> >>Regarding that paper: >> >>One should try to remain mindful of when language change is needed vs. mere= >>ly library. >>=A0=A0 I didn't read enough to see if they need language changes. >>=A0=A0 I do believe Modula-3 could benefit from some language changes. Thou= >>gh that might be mitigated >>=A0=A0 and/or eliminated by me knowing Modula-3 better. For example=2C can = >>I have a type with >>=A0=A0 compiler-enforced opacity without requiring heap allocation? >> >>C compilers are probably better these days. >>=A0Look -- gcc 4.5 just caught up some with Visual C++ and others and has "= >>LTO": link time optimization. >>=A0 I believe Sun also has had this a while=2C and I'm sure others. >>=A0 I rarely turn on optimization though=2C I admit. >>=A0 Disk and network I/O tend to dominate all costs. I don't do heavy compu= >>tation. >> >> >>Shared libraries are always going to seem bloated because they export every= >>thing=2C >>even unused stuff. >> >> >>The paper seems little confused on this matter=2C depending on the >>quality/behavior of the linker=2C and whether or not functions are "separat= >>ed" within >>object files. Visual C++ has the -Gy flag which you should *always* use. >>I don't know why it is an even an option. It makes each function within an = >>object >>separate=2C so you only link in what you use=2C and what that references=2C= >> transitive closure. >>For better and for worse=2C data is not linked in with that same high level= >> of granularity. >>If you get any data from an object=2C you get it all. >>And that includes pointers to functions=2C and whatever those functions cal= >>l=2C even >>if the data isn't referenced. >> >> >>I know that historically linkers didn't strip out anything. >>I'm surprised such linkers existed. Are they still in use? >>(What do GNU=2C Sun=2C Mac do?) >> >> >>=A0- Jay >> >>---------------------------------------- >>> To: m3devel at elegosoft.com >>> Date: Sat=2C 24 Apr 2010 14:29:52 -0700 >>> From: mika at async.async.caltech.edu >>> Subject: [M3devel] Compiling Modula-3 to C >>> >>> >>> The question of making a Modula-3 compiler emit C code as output comes >>> up on this mailing list from time to time. >>> >>> I just discovered a reference to a real example of this. >>> >>> http://caltechcstr.library.caltech.edu/218/01/93-15.pdf >>> >>> Note pages 49-50 (54-55 in the PDF). >>> >>> I also find the byte counts on page 49 interesting. I wish my m3core >>> were that small! >>> >>> Mika >> = From jay.krell at cornell.edu Sun Apr 25 02:00:57 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 25 Apr 2010 00:00:57 +0000 Subject: [M3devel] alpha32 atomic exchange char/widechar? Message-ID: Tony, any idea why on Alpha32 atomic exchange of char/widechar would hit assertion failures in the compiler? It works on Alpha64, and it works on Alpha32 from C (gcc 4.3.0) ? So it isn't for lacking the necessary instructions. ? It works with ev4 or ev6, just more efficiently with ev6. I edited Atomic.mg to just: (* Copyright (C) 1989, Digital Equipment Corporation?????????? *) (* All rights reserved.??????????????????????????????????????? *) (* See the file COPYRIGHT for a full description.????????????? *) GENERIC MODULE Atomic(Rep, Impl); PROCEDURE Swap (VAR var: T; val: Rep.T; order: Order): Rep.T = ? BEGIN RETURN Impl.Swap (var, val, Order.Sequential); ? END Swap; BEGIN END Atomic. and then I get: ../ALPHA32_VMS/AtomicChar.m3 => ../src/atomic/Atomic.mg:9: internal compiler error: in emit_move_insn, at expr.c:3379 ../ALPHA32_VMS/AtomicWideChar.m3 => ../src/atomic/Atomic.mg: In function 'AtomicWideChar__Swap': ../ALPHA32_VMS/AtomicWideChar.m3 => ../src/atomic/Atomic.mg:9: internal compiler error: in emit_move_insn, at expr.c:3379 Please submit a full bug report, rtx emit_move_insn (rtx x, rtx y) { ? enum machine_mode mode = GET_MODE (x); ? rtx y_cst = NULL_RTX; ? rtx last_insn, set; ? gcc_assert (mode != BLKmode ??? ????? && (GET_MODE (y) == mode || GET_MODE (y) == VOIDmode)); I'll dig a bit. ?- Jay From mika at async.async.caltech.edu Sun Apr 25 06:52:02 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Sat, 24 Apr 2010 21:52:02 -0700 Subject: [M3devel] Compiling Modula-3 to C In-Reply-To: References: <20100424212952.D9BDE1A20B7@async.async.caltech.edu>, , <20100424222319.08FF71A20B5@async.async.caltech.edu> Message-ID: <20100425045202.D57B91A20B4@async.async.caltech.edu> Jay K writes: > >Agitation not necessarly inferred. :) > > >Mika=2C the thing is.. consider "safety". >I can argue..as a C programmer..I know what is safe=2C I don't >need the language protection. >Practise proves this is somewhat true=2C somewhat false. >=A0=A0=20 >=A0 >Similar to your argument: >=A0I know what is opaque=2C I don't need the language protection. > >=A0 >I don't think a comment declaring opacity is strong enough. A little different. C never lets you have safety. Modula-3 gives you opacity. You just can't have it at the same time as stack allocation. Same thing with anything else that you only get with OBJECTs for that matter (e.g., dynamic method dispatch). You can't break through the opacity with a cast, either. ... > >I understand that C++ is a little bit complicated=2C with public/private/pr= >otected=2C and friends. >And C# has more options (visible to the assembly/.dll). >I think at least one bit is worthwhile though. >public or private. >Public to all or nobody. >I doubt new syntax would even be needed. >Just like: > >foo.i3: >TYPE Foo=3B >or TYPE FooPublic =3D RECORD END=3B TYPE <: FooPublic=3B > >foo.m3 >=A0REVEAL Foo =3D RECORD ... END=3B > I think you'd just want fully opaque types. Mixing in <: here seems inappropriate. <: has meaning for the abstract types (up till now), whereas I can't figure out what it means for RECORDs. If you want to reveal fields you can always do it through a PROCEDURE that converts from the opaque type to a visible type. TYPE T = OPAQUE RECORD; TYPE Visible = RECORD ... END; PROCEDURE MakeVisible(READONLY t : T) : Visible; Then in the implementation all you have is REVEAL T = RECORD ... END; Mika From jay.krell at cornell.edu Sun Apr 25 15:26:43 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 25 Apr 2010 13:26:43 +0000 Subject: [M3devel] alpha32 atomic exchange char/widechar? Message-ID: aha, gcc 4.3 hits the same assertion failure with -O1 or -O2. I should have noticed that earlier. ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: alpha32 atomic exchange char/widechar? > Date: Sun, 25 Apr 2010 00:00:57 +0000 > > > Tony, any idea why on Alpha32 atomic exchange of char/widechar would hit assertion failures in the compiler? > It works on Alpha64, and it works on Alpha32 from C (gcc 4.3.0) > So it isn't for lacking the necessary instructions. > It works with ev4 or ev6, just more efficiently with ev6. > > I edited Atomic.mg to just: > > (* Copyright (C) 1989, Digital Equipment Corporation *) > (* All rights reserved. *) > (* See the file COPYRIGHT for a full description. *) > > GENERIC MODULE Atomic(Rep, Impl); > > PROCEDURE Swap (VAR var: T; val: Rep.T; order: Order): Rep.T = > BEGIN > RETURN Impl.Swap (var, val, Order.Sequential); > END Swap; > > BEGIN > END Atomic. > > and then I get: > > ../ALPHA32_VMS/AtomicChar.m3 => ../src/atomic/Atomic.mg:9: internal compiler error: in emit_move_insn, at expr.c:3379 > ../ALPHA32_VMS/AtomicWideChar.m3 => ../src/atomic/Atomic.mg: In function 'AtomicWideChar__Swap': > ../ALPHA32_VMS/AtomicWideChar.m3 => ../src/atomic/Atomic.mg:9: internal compiler error: in emit_move_insn, at expr.c:3379 > Please submit a full bug report, > > rtx > emit_move_insn (rtx x, rtx y) > { > enum machine_mode mode = GET_MODE (x); > rtx y_cst = NULL_RTX; > rtx last_insn, set; > > gcc_assert (mode != BLKmode > && (GET_MODE (y) == mode || GET_MODE (y) == VOIDmode)); > > I'll dig a bit. > > - Jay > From jay.krell at cornell.edu Mon Apr 26 01:29:59 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 25 Apr 2010 23:29:59 +0000 Subject: [M3devel] fork/vfork Message-ID: so..in the area of not cloning C headers..fork/vfork has been a lingering still cloned thing. It was already bothering me. I was going to make fork a function pointer at least, so it could honor any #defines or renaming via target specific #pragmas. That way as well we could also go back to vfork where it is a /little/ faster. Fork and/or vfork are not portably wrappable in the usual way because the caller of one or both of them cannot return without calling _exit or an exec function. A wrapper would violate this. I believe I had this violation in temporarily and I believe it did cause a problem. But now there is a bigger problem: VMS: #if defined(__ALPHA) ??? __int64_ptr32 decc$$get_vfork_jmpbuf(void); ??? int LIB$GET_CURRENT_INVO_CONTEXT(__int64 *__invo_context); ??? int decc$$alloc_vfork_blocks(void); #?? define vfork() (decc$$alloc_vfork_blocks()>= 0 ? \ ??? LIB$GET_CURRENT_INVO_CONTEXT(decc$$get_vfork_jmpbuf()) : -1) which further motivates "rewriting" vfork users in C. There are only about two of them. I intend to look into and do this unless there is strong protest. vfork is implemented with a trick that is also mentioned in some Cygwin documentation, something Cygwin attempted but doesn't do. vfork calls setjmp. It returns -1 so the caller thinks it is in the child process. exec calls longjmp, returning the pid on the second return to the parent. Something like that. I almost wonder if we can do this ourselves. But not calling fork/vfork from Modula-3 directly was already a good idea. Now even better. We can leave in fork/vfork external declarations and folks that don't care to run on VMS can still call them. ?(and convert them to function pointers as per my previous thinking) ?- Jay From jay.krell at cornell.edu Tue Apr 27 11:01:23 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 27 Apr 2010 09:01:23 +0000 Subject: [M3devel] cooperative suspend? Message-ID: cooperative suspend Tony, you mind if I take a stab at "cooperative suspend" fairly soon? I can't find a good way to suspend threads on VMS. ? Or even get context in a signal handler. It will be a boolen in Target.i3, so no existing targets affected. ? Of course I'll test it on an existing target with the boolean set wrong. :) ? ? To optimize size instead of speed, I think the "every so often extra generated code" should be a call to a parameter-less function. Instead of checking a per-thread or global variable. Something like: VAR threadRequestingSuspend: ADDRESS; PROCEDURE Thread.PollSuspend() ? BEGIN ??? IF threadRequestingSuspend = NIL THEN RETURN END; ??? PollSuspendSlow(); ? END PollSuspend; (* This is split to avoid needing a frame in PollSuspend. *)? PROCEDURE PollSuspendSlow() ? VAR self: ADDRESS; ? BEGIN ??? IF threadRequestingSuspend = NIL THEN RETURN END; ??? self := GetActivation(); ??? IF self = threadRequestingSuspend THEN RETURN END; (* important consideration! *) ??? GetContext(self.context); (* roughly *) ??? self.suspended := TRUE; (* roughly *) ??? WaitForResume(); (* details to be determined, either the semaphore ????????????????????? * or maybe acquire per-thread lock. *) ? END PollSuspendSlow; The poll call could also be a function pointer and usually point to a function that does nothing. But that'd require loading the address from a global, and calling it. Probably more bloat than calling direct instead of indirect. ?- Jay From rodney_bates at lcwb.coop Tue Apr 27 16:40:47 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Tue, 27 Apr 2010 09:40:47 -0500 Subject: [M3devel] INTEGER In-Reply-To: <20100424103435.A1CC41A20C2@async.async.caltech.edu> References: <20100421185631.GA17051@topoi.pooq.com> <80775CA2-A2FD-40AF-B235-7DB84127762E@cs.purdue.edu> <20100422123805.GA19259@topoi.pooq.com> <87B45DCC-2B8A-4C69-97D7-240BC1E2252D@cs.purdue.edu> <20100422145522.GA19946@topoi.pooq.com> <28339030-6005-4C28-872C-A68CF24BF4DF@cs.purdue.edu> <20100422154357.GA20043@topoi.pooq.com> <270A99B5-173E-413B-8C28-E1CA68870FD4@cs.purdue.edu> <20100423094903.GC21281@topoi.pooq.com> <20100423185214.BA2EF1A20E1@async.async.caltech.edu> <20100423165613.GA22126@topoi.pooq.com> <20100424103435.A1CC41A20C2@async.async.caltech.edu> Message-ID: <4BD6F76F.6090603@lcwb.coop> A general discussion: (More to come on Mika's specific proposal) The problem with using subranges and only one integer type lies in the size of intermediate results of operators. This is sometimes important for programmers to manage carefully. All the more so in the age of network insecurity, where system crackers exploit boundary cases that would never occur in legitimate use. In original Modula-3, this is handled by making all intermediate results have type INTEGER, even if the operands have subrange types. This is a good compromise among conflicting needs, with these properties: 1) It is a simple rule for both compilers and programmers, and it satisfies the language properties that every expression has a unique type and it does not depend on how the expression is used. 2) Assuming the implementors choose the native word size for INTEGER, it is the most efficient arithmetic available. 3) It's the most liberal rule that doesn't have an efficiency penalty. 4) But it doesn't work when a value range greater than the native word size is needed for correctness. The problem arises when the application requirements make 4) relevant. Making INTEGER wider than the native word size necessarily sacrifices either 1) or 2). If all arithmetic were done in, say, double word size, there would be an efficiency penalty on it all. Not huge, but probably a factor of two for the best case of machine and operator. Integer arithmetic is especially sensitive to this kind of slowdown, since it is used in so many very basic ways. Any attempt at defining some system that does intermediate results conditionally in different sizes inevitably gets messy. Having two (or more) integer base types is about as simple as it can get. It satisfies 1) and gives a lot more slack before 4) becomes relevant. It gives programmers control over the efficiency/range tradeoff in a way that is about as simple to define as possible. Having different intermediate result sizes with the same base type gets a lot messier. To give satisfactory results, it would probably have to make types of operator expressions depend on how they are used, violating a fundamental principle of Modula-3. At best, I think the rules would be a lot more complicated that just having two integer base types. But anyone is welcome to prove me wrong with a proposal. Just be sure it completely defines all the type analysis and intermediate result size cases for the subranges, operators, and constant expressions, and allows programmers to control which size is used. And then see if it is simpler than separate integer types. Of course, there is always the library approach, like BigInteger It's much more flexible and much less efficient in general. Not to mention not as syntactically sweet. Two integer sizes seems like a good intermediate solution. Mika Nystrom wrote: > hendrik at topoi.pooq.com writes: >> On Fri, Apr 23, 2010 at 11:52:14AM -0700, Mika Nystrom wrote: >>> Is the infinite extent of the TEXT type a serious implementation difficulty? :-) >> Yes, actually. It requires heap storage allocation and indirection. That's just what >> it costs, so we pay it, since fixed-width strings aren't all that useful. >> >> But integer ranges of a size that matches the application (instead of the hardware) >> are quite feasible and useful; I'd rather not pay the proce of dynamic heap allocation >> for each integer. >> >> -- hendrik > > Ok here I have a proposal, modeled on how Modula-3 does arrays. > > The type specifier LONGINT to be valid in every context where an open > array is valid. > > A subrange of LONGINT to be treated like a non-open array. > > NEW(REF LONGINT, ..) would take two "size" specifiers, a minimum and a maximum, > of type LONGINT. > > For L, U, LONGINT literals, > > NEW(REF LONGINT, L, U) > > would produce the same thing as > > NEW(REF [L..U]) > > NEW(REF LONGINT, ..) is needed for dynamically sized LONGINTs. > > And then overload the arithmetic operations, the way arrays and REF RECORDs are, so > that for b and c REF LONGINT, > > b + c = b^ + c = b + c^ = b^ + c^ > > Assignments carry an implicit range check. > > Assignment rules the same as INTEGER and its subranges. > > Use VAL to convert...? > > In short, expressions involving LONGINT have type LONGINT, but no "bare" LONGINT can > ever be created. > > However note the following, perfectly legal. > > WITH a = b + c, > r = NEW(REF LONGINT, a, a) DO > r^ := a > END > > Also legal, note parameters: > > PROCEDURE Collatz(READONLY a : LONGINT; VAR b : LONGINT) = > BEGIN > CASE a MOD 2L OF > 0L => b := a DIV 2L > | > 1L => b := 3L * a + 1L > END > END Collatz; > > VALUE a : LONGINT would be discouraged. Returning LONGINT > would *not* be legal. ARRAY OF LONGINT would mean the LONGINTs > are limited to the same range, and used in NEW would take three > arguments, one of type INTEGER for the array size and two of type > LONGINT to specify the LONGINTs' bounds. > > Perhaps... > > PROCEDURE Collatz2(READONLY a : LONGINT; VAR b : LONGINT) > RAISES { Range } = > BEGIN > CASE a MOD 2L OF > 0L => b := a DIV 2L > | > 1L => > WITH new = 3L * a + 1L DO (* is new actually stored anywhere!? *) > IF new > LAST(b) THEN > RAISE Range > ELSE > b := new > END > END > END > END Collatz2; > > My proposal gives you both heap-allocated dynamically sized LONGINT and > stack-allocated fixed-sized longints and allows you to mix them at will. > Collatz2 does seem a little bit disturbing, however. Can we rely on > alloca "under the covers"? (Architectures that don't provide alloca > could heap-allocate new in that example, *if* they need to.) > > Another thing that occurs to me is that while + and - are straightforward, > *, DIV, and MOD are things you may well want to use very special and > specific algorithms for in a given application. It makes sense to let the > user replace the code for these operations. And now it begins to look > like C++. Sigh. > > Hendrik, I do think WITH causes similar problems even for strictly > range-limited numbers like the ones you are proposing? (And so does > expression evaluation, of course...) > > Now is it even reasonable to have this built in? What if the user wants > lazy evaluation? Are non-lazy LONGINTs very useful? > > Of course, I have to admit I am using a hardware simulation environment > where non-lazy LONGINTs would indeed be very useful. > > Mika > > From rodney_bates at lcwb.coop Tue Apr 27 18:41:43 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Tue, 27 Apr 2010 11:41:43 -0500 Subject: [M3devel] INTEGER In-Reply-To: <20100424103435.A1CC41A20C2@async.async.caltech.edu> References: <20100421185631.GA17051@topoi.pooq.com> <80775CA2-A2FD-40AF-B235-7DB84127762E@cs.purdue.edu> <20100422123805.GA19259@topoi.pooq.com> <87B45DCC-2B8A-4C69-97D7-240BC1E2252D@cs.purdue.edu> <20100422145522.GA19946@topoi.pooq.com> <28339030-6005-4C28-872C-A68CF24BF4DF@cs.purdue.edu> <20100422154357.GA20043@topoi.pooq.com> <270A99B5-173E-413B-8C28-E1CA68870FD4@cs.purdue.edu> <20100423094903.GC21281@topoi.pooq.com> <20100423185214.BA2EF1A20E1@async.async.caltech.edu> <20100423165613.GA22126@topoi.pooq.com> <20100424103435.A1CC41A20C2@async.async.caltech.edu> Message-ID: <4BD713C7.2060607@lcwb.coop> Mika Nystrom wrote: > hendrik at topoi.pooq.com writes: >> On Fri, Apr 23, 2010 at 11:52:14AM -0700, Mika Nystrom wrote: >>> Is the infinite extent of the TEXT type a serious implementation difficulty? :-) >> Yes, actually. It requires heap storage allocation and indirection. That's just what >> it costs, so we pay it, since fixed-width strings aren't all that useful. >> >> But integer ranges of a size that matches the application (instead of the hardware) >> are quite feasible and useful; I'd rather not pay the proce of dynamic heap allocation >> for each integer. >> >> -- hendrik > > Ok here I have a proposal, modeled on how Modula-3 does arrays. > > The type specifier LONGINT to be valid in every context where an open > array is valid. > > A subrange of LONGINT to be treated like a non-open array. > > NEW(REF LONGINT, ..) would take two "size" specifiers, a minimum and a maximum, > of type LONGINT. It would be better to call these "bounds". The implementation presumably needs to have a variable number of native words to hold values that is derived from, but different from the bounds. The word "size", plus the analogy to open arrays made me at first try to interpret these these specifiers as word counts. > > For L, U, LONGINT literals, > > NEW(REF LONGINT, L, U) Presumably, you want to allow the bounds above to be runtime expressions, not just literals. The WITH statement example below suggests so. > > would produce the same thing as > > NEW(REF [L..U]) But [L..U] by itself would require L and U to be constants, so [L..U] is analogous to a fixed array? > > NEW(REF LONGINT, ..) is needed for dynamically sized LONGINTs. > So, again in analogy to open arrays, a _variable_ of type LONGINT would have bounds that, although computable at runtime, remain unchanged for the lifetime of the variable? > And then overload the arithmetic operations, the way arrays and REF RECORDs are, so > that for b and c REF LONGINT, > > b + c = b^ + c = b + c^ = b^ + c^ Here is where the tough problem in intermediate results rears its ugly head. What is the type of b + c and what are the bounds of b + c? Each of b and c could be: Literals, which don't have any bounds defined at all, expressions of type [L..U], with static bounds, or LONGINT, with dynamic bounds. If b + c ends up having type LONGINT (i.e., not [L..U]), what are its bounds, which the type LONGINT doesn't specify. In the case where b and/or c have type LONGINT, is there a shape check analogy that requires b and c both to have the same bounds? Open arrays don't get into these problems because there are no operators that deliver a newly-computed open array result. You can only move values around, and that will never change the size/bounds. > > Assignments carry an implicit range check. > > Assignment rules the same as INTEGER and its subranges. > > Use VAL to convert...? > > In short, expressions involving LONGINT have type LONGINT, but no "bare" LONGINT can > ever be created. I can't intuit the meaning of "bare" LONGINT. > > However note the following, perfectly legal. > > WITH a = b + c, > r = NEW(REF LONGINT, a, a) DO > r^ := a > END > > Also legal, note parameters: > > PROCEDURE Collatz(READONLY a : LONGINT; VAR b : LONGINT) = > BEGIN > CASE a MOD 2L OF > 0L => b := a DIV 2L > | > 1L => b := 3L * a + 1L > END > END Collatz; > > VALUE a : LONGINT would be discouraged. Returning LONGINT > would *not* be legal. ARRAY OF LONGINT would mean the LONGINTs > are limited to the same range, and used in NEW would take three > arguments, one of type INTEGER for the array size and two of type > LONGINT to specify the LONGINTs' bounds. I haven't thought this through fully, but I think this is going to need: 1) ARRAY [c..d] OF LONGINT is not legal, (most interestingly as a formal parameter), analogous to the existing rule that ARRAY [c..d] OF ARRAY OF INTEGER is illegal. 2) An expanded subtype rule for open/fixed arrays of LONGINT/subrange-of-LONGINT, analogous the one existing rule for just open/fixed arrays. > > Perhaps... > > PROCEDURE Collatz2(READONLY a : LONGINT; VAR b : LONGINT) > RAISES { Range } = > BEGIN > CASE a MOD 2L OF > 0L => b := a DIV 2L In this case, a DIV 2L could lie below the lower end of the range of b. > | > 1L => > WITH new = 3L * a + 1L DO (* is new actually stored anywhere!? *) Yes, it would have to be ------------^ I take it from this example (and the open array analogy) that variables of type LONGINT, unlike BigInteger, can't grow in range by assigning to them. > IF new > LAST(b) THEN > RAISE Range > ELSE > b := new > END > END > END > END Collatz2; > > My proposal gives you both heap-allocated dynamically sized LONGINT and > stack-allocated fixed-sized longints and allows you to mix them at will. > Collatz2 does seem a little bit disturbing, however. Can we rely on > alloca "under the covers"? (Architectures that don't provide alloca > could heap-allocate new in that example, *if* they need to.) I am not half as bothered by the implementation problem of allocating space for dynamically-sized temporaries as by defining the language rules for what the bounds/sizes are. If you say an intermediate result such as b + c has bounds that come from the bounds of b and c, then you lose my property 3) in my previous, general post. That is, you lose the property that INTEGER and its subranges currently have, that the intermediate result is the biggest possible without expanding into more memory and paying a performance penalty. If you try to preserve this property and allow intermediate results to occupy as much space as the operands do, then you have to expose into the language semantics, the mapping between bounds, which the programmer is aware of, and representation sizes (probably native word counts). This gets complicated really fast. If you make intermediate results unbounded and fully dynamic, i.e., as big as needed to hold the computed value, then you don't have an open array analogue any more, you have BigInteger, which has its own pros and cons, but is a quite different abstraction. This is further complicated by the fact that LONGINT literals don't have either defined bounds or defined representation size, so how do you specify these properties of intermediate results when an operand is a literal? This will probably lose the long-standing principles that an expression has an unambiguous, unique type, and that does not depend on how the expression is used. Only the BigInteger approach seems to work here. To make VAL reasonably usable for programmer-specified range changes, which will definitely be needed, you will probably have to allow for arithmetic where both operands are literals, as well as declarations of named constants with values specified in this way. And it all is probably complicated by the distinction that the bounds bounds are static and part of the type, (as for type [L..U]), but dynamic and part of the value (as for LONGINT), > > Another thing that occurs to me is that while + and - are straightforward, > *, DIV, and MOD are things you may well want to use very special and > specific algorithms for in a given application. It makes sense to let the > user replace the code for these operations. And now it begins to look > like C++. Sigh. > > Hendrik, I do think WITH causes similar problems even for strictly > range-limited numbers like the ones you are proposing? (And so does > expression evaluation, of course...) > > Now is it even reasonable to have this built in? What if the user wants > lazy evaluation? Are non-lazy LONGINTs very useful? > > Of course, I have to admit I am using a hardware simulation environment > where non-lazy LONGINTs would indeed be very useful. > > Mika > > Perhaps what you really want is to replace the two-member set {INTEGER, LONGINT} with an unbounded set of multi-word arithmetics, for different word counts. To do this and keep the (relative) semantic integrity of {INTEGER, LONGINT}, you would need to make each size a distinct base type. But then, I fear it would be very difficult to have open-array-like formal parameters and heap objects. We, of course, don't have anything like this with INTEGER, LONGINT}. From mika at async.async.caltech.edu Tue Apr 27 19:24:00 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Tue, 27 Apr 2010 10:24:00 -0700 Subject: [M3devel] INTEGER In-Reply-To: <4BD713C7.2060607@lcwb.coop> References: <20100421185631.GA17051@topoi.pooq.com> <80775CA2-A2FD-40AF-B235-7DB84127762E@cs.purdue.edu> <20100422123805.GA19259@topoi.pooq.com> <87B45DCC-2B8A-4C69-97D7-240BC1E2252D@cs.purdue.edu> <20100422145522.GA19946@topoi.pooq.com> <28339030-6005-4C28-872C-A68CF24BF4DF@cs.purdue.edu> <20100422154357.GA20043@topoi.pooq.com> <270A99B5-173E-413B-8C28-E1CA68870FD4@cs.purdue.edu> <20100423094903.GC21281@topoi.pooq.com> <20100423185214.BA2EF1A20E1@async.async.caltech.edu> <20100423165613.GA22126@topoi.pooq.com> <20100424103435.A1CC41A20C2@async.async.caltech.edu> <4BD713C7.2060607@lcwb.coop> Message-ID: <20100427172400.D491F1A2096@async.async.caltech.edu> Hi Rodney, Yes most of what you write is exactly as I was thinking too. It is a bit odd that you can't have ARRAY OF LONGINT. You can have ARRAY OF REF LONGINT, though. You say the subtyping rule for open/fixed arrays has to be expanded. Can you expand on this statement? I am not worried as you are by the range problem. The saving grace is that the language has very few arithmetic operators on integers. + - * DIV MOD. It's not hard to do range arithmetic on these such that one can easily figure out how much memory is required to hold intermediate results. If you're happy with alloca (I don't mind it), that's what you do. You have three options in so far as calculating the required space: 1. For known subranges of LONGINT, do it at compile time (no alloca required) 2. For "open" LONGINTs, at runtime, based on the passed-in types 3. For "open" LONGINTs, at runtime, based on the passed-in values Now as I said the proposal is that variables can themselves not be of type LONGINT but only subranges thereof. That means you can get away with stack allocation and don't need to do heap allocation. Since you bring up BigInteger, yes, it's precisely BigInteger, except the fact that since variables are always of fixed range, you can do it completely on the stack (as long as you are allowed to use alloca). The "type" of a longint literal x can be [x..x]. Mika "Rodney M. Bates" writes: > > >Mika Nystrom wrote: >> hendrik at topoi.pooq.com writes: >>> On Fri, Apr 23, 2010 at 11:52:14AM -0700, Mika Nystrom wrote: >>>> Is the infinite extent of the TEXT type a serious implementation difficult >y? :-) >>> Yes, actually. It requires heap storage allocation and indirection. That' >s just what >>> it costs, so we pay it, since fixed-width strings aren't all that useful. >>> >>> But integer ranges of a size that matches the application (instead of the h >ardware) >>> are quite feasible and useful; I'd rather not pay the proce of dynamic heap > allocation >>> for each integer. >>> >>> -- hendrik >> >> Ok here I have a proposal, modeled on how Modula-3 does arrays. >> >> The type specifier LONGINT to be valid in every context where an open >> array is valid. >> >> A subrange of LONGINT to be treated like a non-open array. >> >> NEW(REF LONGINT, ..) would take two "size" specifiers, a minimum and a maxim >um, >> of type LONGINT. > >It would be better to call these "bounds". The implementation presumably need >s >to have a variable number of native words to hold values that is derived from, >but different from the bounds. The word "size", plus the analogy to open arra >ys >made me at first try to interpret these these specifiers as word counts. > >> >> For L, U, LONGINT literals, >> >> NEW(REF LONGINT, L, U) > >Presumably, you want to allow the bounds above to be runtime >expressions, not just literals. The WITH statement example below >suggests so. > >> >> would produce the same thing as >> >> NEW(REF [L..U]) > >But [L..U] by itself would require L and U to be constants, so >[L..U] is analogous to a fixed array? > >> >> NEW(REF LONGINT, ..) is needed for dynamically sized LONGINTs. >> > >So, again in analogy to open arrays, a _variable_ of type LONGINT would >have bounds that, although computable at runtime, remain unchanged for >the lifetime of the variable? > >> And then overload the arithmetic operations, the way arrays and REF RECORDs >are, so >> that for b and c REF LONGINT, >> >> b + c = b^ + c = b + c^ = b^ + c^ > >Here is where the tough problem in intermediate results rears its ugly head. >What is the type of b + c and what are the bounds of b + c? Each of b and c >could be: Literals, which don't have any bounds defined at all, expressions >of type [L..U], with static bounds, or LONGINT, with dynamic bounds. > >If b + c ends up having type LONGINT (i.e., not [L..U]), what are its bounds, >which the type LONGINT doesn't specify. > >In the case where b and/or c have type LONGINT, is there a shape check analogy >that requires b and c both to have the same bounds? > >Open arrays don't get into these problems because there are no operators that >deliver a newly-computed open array result. You can only move values around, >and that will never change the size/bounds. > >> >> Assignments carry an implicit range check. >> >> Assignment rules the same as INTEGER and its subranges. >> >> Use VAL to convert...? >> >> In short, expressions involving LONGINT have type LONGINT, but no "bare" LON >GINT can >> ever be created. > >I can't intuit the meaning of "bare" LONGINT. >> >> However note the following, perfectly legal. >> >> WITH a = b + c, >> r = NEW(REF LONGINT, a, a) DO >> r^ := a >> END >> >> Also legal, note parameters: >> >> PROCEDURE Collatz(READONLY a : LONGINT; VAR b : LONGINT) = >> BEGIN >> CASE a MOD 2L OF >> 0L => b := a DIV 2L >> | >> 1L => b := 3L * a + 1L >> END >> END Collatz; >> >> VALUE a : LONGINT would be discouraged. Returning LONGINT >> would *not* be legal. ARRAY OF LONGINT would mean the LONGINTs >> are limited to the same range, and used in NEW would take three >> arguments, one of type INTEGER for the array size and two of type >> LONGINT to specify the LONGINTs' bounds. > >I haven't thought this through fully, but I think this is going to need: > >1) ARRAY [c..d] OF LONGINT is not legal, (most interestingly as a formal param >eter), > analogous to the existing rule that ARRAY [c..d] OF ARRAY OF INTEGER is il >legal. > >2) An expanded subtype rule for open/fixed arrays of LONGINT/subrange-of-LONGI >NT, > analogous the one existing rule for just open/fixed arrays. > >> >> Perhaps... >> >> PROCEDURE Collatz2(READONLY a : LONGINT; VAR b : LONGINT) >> RAISES { Range } = >> BEGIN >> CASE a MOD 2L OF >> 0L => b := a DIV 2L > >In this case, a DIV 2L could lie below the lower end of the range of b. > >> | >> 1L => >> WITH new = 3L * a + 1L DO (* is new actually stored anywhere!? *) > >Yes, it would have to be ------------^ > >I take it from this example (and the open array analogy) that variables >of type LONGINT, unlike BigInteger, can't grow in range by assigning to them. > >> IF new > LAST(b) THEN >> RAISE Range >> ELSE >> b := new >> END >> END >> END >> END Collatz2; >> >> My proposal gives you both heap-allocated dynamically sized LONGINT and >> stack-allocated fixed-sized longints and allows you to mix them at will. >> Collatz2 does seem a little bit disturbing, however. Can we rely on >> alloca "under the covers"? (Architectures that don't provide alloca >> could heap-allocate new in that example, *if* they need to.) > >I am not half as bothered by the implementation problem of allocating >space for dynamically-sized temporaries as by defining the language rules >for what the bounds/sizes are. If you say an intermediate result such as >b + c has bounds that come from the bounds of b and c, then you lose my >property 3) in my previous, general post. That is, you lose the >property that INTEGER and its subranges currently have, that the intermediate >result is the biggest possible without expanding into more memory and >paying a performance penalty. > >If you try to preserve this property and allow intermediate results to >occupy as much space as the operands do, then you have to expose into the >language semantics, the mapping between bounds, which the programmer >is aware of, and representation sizes (probably native word counts). >This gets complicated really fast. > >If you make intermediate results unbounded and fully dynamic, i.e., as big >as needed to hold the computed value, then you don't have an open array >analogue any more, you have BigInteger, which has its own pros and cons, >but is a quite different abstraction. > >This is further complicated by the fact that LONGINT literals don't have >either defined bounds or defined representation size, so how do you >specify these properties of intermediate results when an operand is >a literal? This will probably lose the long-standing principles that >an expression has an unambiguous, unique type, and that does not depend on >how the expression is used. Only the BigInteger approach seems to work here. > >To make VAL reasonably usable for programmer-specified range changes, which wi >ll >definitely be needed, you will probably have to allow for arithmetic where bot >h >operands are literals, as well as declarations of named constants with >values specified in this way. > >And it all is probably complicated by the distinction that the bounds >bounds are static and part of the type, (as for type [L..U]), but dynamic >and part of the value (as for LONGINT), > > >> >> Another thing that occurs to me is that while + and - are straightforward, >> *, DIV, and MOD are things you may well want to use very special and >> specific algorithms for in a given application. It makes sense to let the >> user replace the code for these operations. And now it begins to look >> like C++. Sigh. >> >> Hendrik, I do think WITH causes similar problems even for strictly >> range-limited numbers like the ones you are proposing? (And so does >> expression evaluation, of course...) >> >> Now is it even reasonable to have this built in? What if the user wants >> lazy evaluation? Are non-lazy LONGINTs very useful? >> >> Of course, I have to admit I am using a hardware simulation environment >> where non-lazy LONGINTs would indeed be very useful. >> >> Mika >> >> > >Perhaps what you really want is to replace the two-member set {INTEGER, LONGIN >T} >with an unbounded set of multi-word arithmetics, for different word counts. > >To do this and keep the (relative) semantic integrity of {INTEGER, LONGINT}, >you would need to make each size a distinct base type. But then, I fear it >would be very difficult to have open-array-like formal parameters and >heap objects. We, of course, don't have anything like this with INTEGER, LONG >INT}. From mika at async.async.caltech.edu Tue Apr 27 19:30:36 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Tue, 27 Apr 2010 10:30:36 -0700 Subject: [M3devel] INTEGER In-Reply-To: <20100427172400.D491F1A2096@async.async.caltech.edu> References: <20100421185631.GA17051@topoi.pooq.com> <80775CA2-A2FD-40AF-B235-7DB84127762E@cs.purdue.edu> <20100422123805.GA19259@topoi.pooq.com> <87B45DCC-2B8A-4C69-97D7-240BC1E2252D@cs.purdue.edu> <20100422145522.GA19946@topoi.pooq.com> <28339030-6005-4C28-872C-A68CF24BF4DF@cs.purdue.edu> <20100422154357.GA20043@topoi.pooq.com> <270A99B5-173E-413B-8C28-E1CA68870FD4@cs.purdue.edu> <20100423094903.GC21281@topoi.pooq.com> <20100423185214.BA2EF1A20E1@async.async.caltech.edu> <20100423165613.GA22126@topoi.pooq.com> <20100424103435.A1CC41A20C2@async.async.caltech.edu> <4BD713C7.2060607@lcwb.coop> <20100427172400.D491F1A2096@async.async.caltech.edu> Message-ID: <20100427173036.7DC501A2096@async.async.caltech.edu> Mika Nystrom writes: ... >I am not worried as you are by the range problem. The saving grace is >that the language has very few arithmetic operators on integers. >+ - * DIV MOD. It's not hard to do range arithmetic on these such that >one can easily figure out how much memory is required to hold intermediate >results. If you're happy with alloca (I don't mind it), that's what >you do. You have three options in so far as calculating the required >space: ... To clarify a bit further, my proposal is that the ranges be lost in the evaluation. Everything in the expression is simply of type LONGINT. When the final result is assigned to a variable, there is a range check (which can be dispensed with if the compiler can prove that there can be no overrun). Isn't this how INTEGER subranges work? a : [0..2]; b : [0..1]; a := 4*b - 2*b Mika From jay.krell at cornell.edu Tue Apr 27 19:55:12 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 27 Apr 2010 17:55:12 +0000 Subject: [M3devel] INTEGER In-Reply-To: <20100427172400.D491F1A2096@async.async.caltech.edu> References: <20100421185631.GA17051@topoi.pooq.com>, <80775CA2-A2FD-40AF-B235-7DB84127762E@cs.purdue.edu>, <20100422123805.GA19259@topoi.pooq.com>, <87B45DCC-2B8A-4C69-97D7-240BC1E2252D@cs.purdue.edu>, <20100422145522.GA19946@topoi.pooq.com>, <28339030-6005-4C28-872C-A68CF24BF4DF@cs.purdue.edu>, <20100422154357.GA20043@topoi.pooq.com>, <270A99B5-173E-413B-8C28-E1CA68870FD4@cs.purdue.edu>, <20100423094903.GC21281@topoi.pooq.com>, <20100423185214.BA2EF1A20E1@async.async.caltech.edu>, <20100423165613.GA22126@topoi.pooq.com>, <20100424103435.A1CC41A20C2@async.async.caltech.edu>, <4BD713C7.2060607@lcwb.coop>, <20100427172400.D491F1A2096@async.async.caltech.edu> Message-ID: > Since you bring up BigInteger, yes, it's precisely BigInteger, except > the fact that since variables are always of fixed range, you can do it > completely on the stack (as long as you are allowed to use alloca). You could implement a generic biginteger parameterized by how many bits/bytes/integers of precision it has and therefore be a fixed small size. Target.Int for example always has 64 bits, which is determined on roughly one line (ie: almost "generic"). When you read through the various multiprecision libraries, you often find likewise two such sets of types/functions -- fixed precision and precision that grows to fit values. ?- Jay ---------------------------------------- > To: rodney_bates at lcwb.coop > Date: Tue, 27 Apr 2010 10:24:00 -0700 > From: mika at async.async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] INTEGER > > Hi Rodney, > > Yes most of what you write is exactly as I was thinking too. > It is a bit odd that you can't have ARRAY OF LONGINT. You can have > ARRAY OF REF LONGINT, though. > > You say the subtyping rule for open/fixed arrays has to be expanded. > Can you expand on this statement? > > I am not worried as you are by the range problem. The saving grace is > that the language has very few arithmetic operators on integers. > + - * DIV MOD. It's not hard to do range arithmetic on these such that > one can easily figure out how much memory is required to hold intermediate > results. If you're happy with alloca (I don't mind it), that's what > you do. You have three options in so far as calculating the required > space: > > 1. For known subranges of LONGINT, do it at compile time (no alloca > required) > 2. For "open" LONGINTs, at runtime, based on the passed-in types > 3. For "open" LONGINTs, at runtime, based on the passed-in values > > Now as I said the proposal is that variables can themselves not be of > type LONGINT but only subranges thereof. That means you can get away > with stack allocation and don't need to do heap allocation. > > Since you bring up BigInteger, yes, it's precisely BigInteger, except > the fact that since variables are always of fixed range, you can do it > completely on the stack (as long as you are allowed to use alloca). > > The "type" of a longint literal x can be [x..x]. > > Mika > > > "Rodney M. Bates" writes: >> >> >>Mika Nystrom wrote: >>> hendrik at topoi.pooq.com writes: >>>> On Fri, Apr 23, 2010 at 11:52:14AM -0700, Mika Nystrom wrote: >>>>> Is the infinite extent of the TEXT type a serious implementation difficult >>y? :-) >>>> Yes, actually. It requires heap storage allocation and indirection. That' >>s just what >>>> it costs, so we pay it, since fixed-width strings aren't all that useful. >>>> >>>> But integer ranges of a size that matches the application (instead of the h >>ardware) >>>> are quite feasible and useful; I'd rather not pay the proce of dynamic heap >> allocation >>>> for each integer. >>>> >>>> -- hendrik >>> >>> Ok here I have a proposal, modeled on how Modula-3 does arrays. >>> >>> The type specifier LONGINT to be valid in every context where an open >>> array is valid. >>> >>> A subrange of LONGINT to be treated like a non-open array. >>> >>> NEW(REF LONGINT, ..) would take two "size" specifiers, a minimum and a maxim >>um, >>> of type LONGINT. >> >>It would be better to call these "bounds". The implementation presumably need >>s >>to have a variable number of native words to hold values that is derived from, >>but different from the bounds. The word "size", plus the analogy to open arra >>ys >>made me at first try to interpret these these specifiers as word counts. >> >>> >>> For L, U, LONGINT literals, >>> >>> NEW(REF LONGINT, L, U) >> >>Presumably, you want to allow the bounds above to be runtime >>expressions, not just literals. The WITH statement example below >>suggests so. >> >>> >>> would produce the same thing as >>> >>> NEW(REF [L..U]) >> >>But [L..U] by itself would require L and U to be constants, so >>[L..U] is analogous to a fixed array? >> >>> >>> NEW(REF LONGINT, ..) is needed for dynamically sized LONGINTs. >>> >> >>So, again in analogy to open arrays, a _variable_ of type LONGINT would >>have bounds that, although computable at runtime, remain unchanged for >>the lifetime of the variable? >> >>> And then overload the arithmetic operations, the way arrays and REF RECORDs >>are, so >>> that for b and c REF LONGINT, >>> >>> b + c = b^ + c = b + c^ = b^ + c^ >> >>Here is where the tough problem in intermediate results rears its ugly head. >>What is the type of b + c and what are the bounds of b + c? Each of b and c >>could be: Literals, which don't have any bounds defined at all, expressions >>of type [L..U], with static bounds, or LONGINT, with dynamic bounds. >> >>If b + c ends up having type LONGINT (i.e., not [L..U]), what are its bounds, >>which the type LONGINT doesn't specify. >> >>In the case where b and/or c have type LONGINT, is there a shape check analogy >>that requires b and c both to have the same bounds? >> >>Open arrays don't get into these problems because there are no operators that >>deliver a newly-computed open array result. You can only move values around, >>and that will never change the size/bounds. >> >>> >>> Assignments carry an implicit range check. >>> >>> Assignment rules the same as INTEGER and its subranges. >>> >>> Use VAL to convert...? >>> >>> In short, expressions involving LONGINT have type LONGINT, but no "bare" LON >>GINT can >>> ever be created. >> >>I can't intuit the meaning of "bare" LONGINT. >>> >>> However note the following, perfectly legal. >>> >>> WITH a = b + c, >>> r = NEW(REF LONGINT, a, a) DO >>> r^ := a >>> END >>> >>> Also legal, note parameters: >>> >>> PROCEDURE Collatz(READONLY a : LONGINT; VAR b : LONGINT) = >>> BEGIN >>> CASE a MOD 2L OF >>> 0L => b := a DIV 2L >>> | >>> 1L => b := 3L * a + 1L >>> END >>> END Collatz; >>> >>> VALUE a : LONGINT would be discouraged. Returning LONGINT >>> would *not* be legal. ARRAY OF LONGINT would mean the LONGINTs >>> are limited to the same range, and used in NEW would take three >>> arguments, one of type INTEGER for the array size and two of type >>> LONGINT to specify the LONGINTs' bounds. >> >>I haven't thought this through fully, but I think this is going to need: >> >>1) ARRAY [c..d] OF LONGINT is not legal, (most interestingly as a formal param >>eter), >> analogous to the existing rule that ARRAY [c..d] OF ARRAY OF INTEGER is il >>legal. >> >>2) An expanded subtype rule for open/fixed arrays of LONGINT/subrange-of-LONGI >>NT, >> analogous the one existing rule for just open/fixed arrays. >> >>> >>> Perhaps... >>> >>> PROCEDURE Collatz2(READONLY a : LONGINT; VAR b : LONGINT) >>> RAISES { Range } = >>> BEGIN >>> CASE a MOD 2L OF >>> 0L => b := a DIV 2L >> >>In this case, a DIV 2L could lie below the lower end of the range of b. >> >>> | >>> 1L => >>> WITH new = 3L * a + 1L DO (* is new actually stored anywhere!? *) >> >>Yes, it would have to be ------------^ >> >>I take it from this example (and the open array analogy) that variables >>of type LONGINT, unlike BigInteger, can't grow in range by assigning to them. >> >>> IF new> LAST(b) THEN >>> RAISE Range >>> ELSE >>> b := new >>> END >>> END >>> END >>> END Collatz2; >>> >>> My proposal gives you both heap-allocated dynamically sized LONGINT and >>> stack-allocated fixed-sized longints and allows you to mix them at will. >>> Collatz2 does seem a little bit disturbing, however. Can we rely on >>> alloca "under the covers"? (Architectures that don't provide alloca >>> could heap-allocate new in that example, *if* they need to.) >> >>I am not half as bothered by the implementation problem of allocating >>space for dynamically-sized temporaries as by defining the language rules >>for what the bounds/sizes are. If you say an intermediate result such as >>b + c has bounds that come from the bounds of b and c, then you lose my >>property 3) in my previous, general post. That is, you lose the >>property that INTEGER and its subranges currently have, that the intermediate >>result is the biggest possible without expanding into more memory and >>paying a performance penalty. >> >>If you try to preserve this property and allow intermediate results to >>occupy as much space as the operands do, then you have to expose into the >>language semantics, the mapping between bounds, which the programmer >>is aware of, and representation sizes (probably native word counts). >>This gets complicated really fast. >> >>If you make intermediate results unbounded and fully dynamic, i.e., as big >>as needed to hold the computed value, then you don't have an open array >>analogue any more, you have BigInteger, which has its own pros and cons, >>but is a quite different abstraction. >> >>This is further complicated by the fact that LONGINT literals don't have >>either defined bounds or defined representation size, so how do you >>specify these properties of intermediate results when an operand is >>a literal? This will probably lose the long-standing principles that >>an expression has an unambiguous, unique type, and that does not depend on >>how the expression is used. Only the BigInteger approach seems to work here. >> >>To make VAL reasonably usable for programmer-specified range changes, which wi >>ll >>definitely be needed, you will probably have to allow for arithmetic where bot >>h >>operands are literals, as well as declarations of named constants with >>values specified in this way. >> >>And it all is probably complicated by the distinction that the bounds >>bounds are static and part of the type, (as for type [L..U]), but dynamic >>and part of the value (as for LONGINT), >> >> >>> >>> Another thing that occurs to me is that while + and - are straightforward, >>> *, DIV, and MOD are things you may well want to use very special and >>> specific algorithms for in a given application. It makes sense to let the >>> user replace the code for these operations. And now it begins to look >>> like C++. Sigh. >>> >>> Hendrik, I do think WITH causes similar problems even for strictly >>> range-limited numbers like the ones you are proposing? (And so does >>> expression evaluation, of course...) >>> >>> Now is it even reasonable to have this built in? What if the user wants >>> lazy evaluation? Are non-lazy LONGINTs very useful? >>> >>> Of course, I have to admit I am using a hardware simulation environment >>> where non-lazy LONGINTs would indeed be very useful. >>> >>> Mika >>> >>> >> >>Perhaps what you really want is to replace the two-member set {INTEGER, LONGIN >>T} >>with an unbounded set of multi-word arithmetics, for different word counts. >> >>To do this and keep the (relative) semantic integrity of {INTEGER, LONGINT}, >>you would need to make each size a distinct base type. But then, I fear it >>would be very difficult to have open-array-like formal parameters and >>heap objects. We, of course, don't have anything like this with INTEGER, LONG >>INT}. From hosking at cs.purdue.edu Wed Apr 28 03:51:53 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 27 Apr 2010 21:51:53 -0400 Subject: [M3devel] cooperative suspend? In-Reply-To: References: Message-ID: <19A8CA05-F586-4F54-8BAF-10BACFB1C45C@cs.purdue.edu> Ultimately we don't really want stop-the-world at all. What we really need is per-thread suspension. For scalability we should be aiming to stop threads individually rather than all at once. This means some sort of per-thread (local) mechanism. On 27 Apr 2010, at 05:01, Jay K wrote: > > cooperative suspend > > > Tony, you mind if I take a stab at "cooperative suspend" > fairly soon? > I can't find a good way to suspend threads on VMS. > Or even get context in a signal handler. > It will be a boolen in Target.i3, so no existing targets affected. > Of course I'll test it on an existing target with the boolean set wrong. :) > > > To optimize size instead of speed, I think the "every so often > extra generated code" should be a call to a parameter-less function. > Instead of checking a per-thread or global variable. > > Something like: > > > VAR threadRequestingSuspend: ADDRESS; > > > PROCEDURE Thread.PollSuspend() > BEGIN > IF threadRequestingSuspend = NIL THEN RETURN END; > PollSuspendSlow(); > END PollSuspend; > > > (* This is split to avoid needing a frame in PollSuspend. *) > PROCEDURE PollSuspendSlow() > VAR self: ADDRESS; > BEGIN > IF threadRequestingSuspend = NIL THEN RETURN END; > self := GetActivation(); > IF self = threadRequestingSuspend THEN RETURN END; (* important consideration! *) > GetContext(self.context); (* roughly *) > self.suspended := TRUE; (* roughly *) > WaitForResume(); (* details to be determined, either the semaphore > * or maybe acquire per-thread lock. *) > END PollSuspendSlow; > > > The poll call could also be a function pointer and usually point to a function that does nothing. > But that'd require loading the address from a global, and calling it. > Probably more bloat than calling direct instead of indirect. > > > - Jay > From jay.krell at cornell.edu Wed Apr 28 05:32:08 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 28 Apr 2010 03:32:08 +0000 Subject: [M3devel] cooperative suspend? In-Reply-To: <19A8CA05-F586-4F54-8BAF-10BACFB1C45C@cs.purdue.edu> References: , <19A8CA05-F586-4F54-8BAF-10BACFB1C45C@cs.purdue.edu> Message-ID: Ok. I still like calling a parameter-less function for code size. That would lead to perhaps, if any number of threads can be suspended, and compatible with current direction of suspending all of them: VAR anyThreadsBeingSuspended: BOOLEAN; PROCEDURE PollSuspend() = BEGIN IF anyThreadsBeingSuspended = FALSE THEN RETURN END; PollSuspendSlow(); END PollSuspend; PROCEDURE PollSuspendSlow() = VAR self := GetActivation(); BEGIN IF NOT self.suspend THEN RETURN END; .. more stuff here .. END PollSuspendSlow; or if only one suspend would be requested a time: VAR threadToSuspend: ADDRESS; PROCEDURE PollSuspend() = BEGIN IF threadToSuspend = NIL THEN RETURN END; PollSuspendSlow(); END PollSuspend; PROCEDURE PollSuspendSlow() = VAR self := GetActivation(); BEGIN IF self <> threadToSuspend THEN RETURN END; .. more stuff here .. END PollSuspendSlow; I imagine what is "really" ideal is to request 1 or more threads to suspend, and then in the "more stuff here", they tell the requester they have suspended. ? That way, if some thread takes a while to suspend, the whole process isn't backed up behind it. ? That would would favor my first exposition (with per thread self.suspend boolean). Which fits current scheme in that you'd just set them all to true. - Jay ---------------------------------------- > From: hosking at cs.purdue.edu > Date: Tue, 27 Apr 2010 21:51:53 -0400 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] cooperative suspend? > > Ultimately we don't really want stop-the-world at all. What we really need is per-thread suspension. For scalability we should be aiming to stop threads individually rather than all at once. This means some sort of per-thread (local) mechanism. > > On 27 Apr 2010, at 05:01, Jay K wrote: > >> >> cooperative suspend >> >> >> Tony, you mind if I take a stab at "cooperative suspend" >> fairly soon? >> I can't find a good way to suspend threads on VMS. >> Or even get context in a signal handler. >> It will be a boolen in Target.i3, so no existing targets affected. >> Of course I'll test it on an existing target with the boolean set wrong. :) >> >> >> To optimize size instead of speed, I think the "every so often >> extra generated code" should be a call to a parameter-less function. >> Instead of checking a per-thread or global variable. >> >> Something like: >> >> >> VAR threadRequestingSuspend: ADDRESS; >> >> >> PROCEDURE Thread.PollSuspend() >> BEGIN >> IF threadRequestingSuspend = NIL THEN RETURN END; >> PollSuspendSlow(); >> END PollSuspend; >> >> >> (* This is split to avoid needing a frame in PollSuspend. *) >> PROCEDURE PollSuspendSlow() >> VAR self: ADDRESS; >> BEGIN >> IF threadRequestingSuspend = NIL THEN RETURN END; >> self := GetActivation(); >> IF self = threadRequestingSuspend THEN RETURN END; (* important consideration! *) >> GetContext(self.context); (* roughly *) >> self.suspended := TRUE; (* roughly *) >> WaitForResume(); (* details to be determined, either the semaphore >> * or maybe acquire per-thread lock. *) >> END PollSuspendSlow; >> >> >> The poll call could also be a function pointer and usually point to a function that does nothing. >> But that'd require loading the address from a global, and calling it. >> Probably more bloat than calling direct instead of indirect. >> >> >> - Jay >> > From wagner at elegosoft.com Wed Apr 28 10:40:44 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 28 Apr 2010 10:40:44 +0200 Subject: [M3devel] Fwd: Re: [CM3] #1084: CM3 for Solaris X86? Message-ID: <20100428104044.14rqktckgk0w8kws@mail.elegosoft.com> Seems to have been discarded, so I forward it explicitly. Anybody interested? Olaf ----- Forwarded message from bugs at elego.de ----- Date: Wed, 28 Apr 2010 08:31:06 -0000 From: CM3 Reply-To: CM3 Subject: Re: [CM3] #1084: CM3 for Solaris X86? To: @MISSING_DOMAIN #1084: CM3 for Solaris X86? -------------------------------+-------------------------------------------- Reporter: risaac@? | Owner: wagner Type: sw-feature | Status: new Priority: medium | Milestone: CM3 Release 5.9 Component: installation | Version: 5.8-RC2 Severity: non-critical | Keywords: solaris x86 Relnote: | Confidential: no Org: | Estimatedhours: 0 Hours: 0 | Billable: 0 Totalhours: 0 | Internal: 0 -------------------------------+-------------------------------------------- Htr: Fix: Env: Solaris 10 x86: SunOS localhost 5.10 Generic_137138-09 i86pc i386 i86pc -------------------------------+-------------------------------------------- Changes (by wagner): * cc: m3devel@? (added) * milestone: => CM3 Release 5.9 Comment: Solaris for x86 probably wouldn't be difficult to add, as both operating system specific code and processor specific code should already be there. None of the developers seems to have set up such a system yet though. For more than a short-time availability and from a release engineering point of view the acquiration of an appropriate build and test server (preferrably working as a Hudson slave) would be important. So if you or one of the cm3 developers can arrange to place such a machine at Hudson's disposal (will generate some load now and then), that would be a great start. Jay Krell has a whole zoo of hardware/OS setup; I'm not sure if he's interested and willing to provide one more. But of course this request should not be restricted to his person, but to all who may be interested (CC'ed to m3devel for this purpose). A (virtual) machine with remote ssh access for an ordinary user should be all that is needed for a CM3 deveoper to add the target platform and for Hudson to run builds and tests. -- Ticket URL: CM3 Critical Mass Modula3 Compiler ----- End forwarded message ----- -- 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 Apr 28 16:22:55 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 28 Apr 2010 10:22:55 -0400 Subject: [M3devel] cooperative suspend? In-Reply-To: References: , <19A8CA05-F586-4F54-8BAF-10BACFB1C45C@cs.purdue.edu> Message-ID: <8E176F01-29AD-4A64-8395-966AE9A19181@cs.purdue.edu> On 27 Apr 2010, at 23:32, Jay K wrote: > > Ok. I still like calling a parameter-less function for code size. > > > That would lead to perhaps, if any number of threads can be suspended, > and compatible with current direction of suspending all of them: > > > VAR anyThreadsBeingSuspended: BOOLEAN; We could have a global array with an entry/bit per thread. It would limit the number of total threads (because we'd want it statically allocated), but has the advantage that we never divert threads that don't need to suspend. > PROCEDURE PollSuspend() = > BEGIN > IF anyThreadsBeingSuspended = FALSE THEN RETURN END; > PollSuspendSlow(); > END PollSuspend; We could easily inline the pollcheck using the compiler. > PROCEDURE PollSuspendSlow() = > VAR self := GetActivation(); > BEGIN > IF NOT self.suspend THEN RETURN END; > .. more stuff here .. > END PollSuspendSlow; > > > or if only one suspend would be requested a time: > > > VAR threadToSuspend: ADDRESS; Ultimately we want more than just suspend. We really want pairwise handshakes between threads, with the possibility of many in flight simultaneously. This gives us the ability to do biased lock revocation very efficiently. > PROCEDURE PollSuspend() = > BEGIN > IF threadToSuspend = NIL THEN RETURN END; > PollSuspendSlow(); > END PollSuspend; > > > PROCEDURE PollSuspendSlow() = > VAR self := GetActivation(); > BEGIN > IF self <> threadToSuspend THEN RETURN END; > .. more stuff here .. > END PollSuspendSlow; > > > I imagine what is "really" ideal is to request 1 or more threads to suspend, and then in the "more stuff here", they tell the requester they have suspended. ? Yeah, or simply deliver an ack that they have seen the event. > That way, if some thread takes a while to suspend, the whole process isn't backed up behind it. ? Exactly. > That would would favor my first exposition (with per thread self.suspend boolean). > Which fits current scheme in that you'd just set them all to true. Yes, that would work. I like it. > > > > - Jay > > > ---------------------------------------- >> From: hosking at cs.purdue.edu >> Date: Tue, 27 Apr 2010 21:51:53 -0400 >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] cooperative suspend? >> >> Ultimately we don't really want stop-the-world at all. What we really need is per-thread suspension. For scalability we should be aiming to stop threads individually rather than all at once. This means some sort of per-thread (local) mechanism. >> >> On 27 Apr 2010, at 05:01, Jay K wrote: >> >>> >>> cooperative suspend >>> >>> >>> Tony, you mind if I take a stab at "cooperative suspend" >>> fairly soon? >>> I can't find a good way to suspend threads on VMS. >>> Or even get context in a signal handler. >>> It will be a boolen in Target.i3, so no existing targets affected. >>> Of course I'll test it on an existing target with the boolean set wrong. :) >>> >>> >>> To optimize size instead of speed, I think the "every so often >>> extra generated code" should be a call to a parameter-less function. >>> Instead of checking a per-thread or global variable. >>> >>> Something like: >>> >>> >>> VAR threadRequestingSuspend: ADDRESS; >>> >>> >>> PROCEDURE Thread.PollSuspend() >>> BEGIN >>> IF threadRequestingSuspend = NIL THEN RETURN END; >>> PollSuspendSlow(); >>> END PollSuspend; >>> >>> >>> (* This is split to avoid needing a frame in PollSuspend. *) >>> PROCEDURE PollSuspendSlow() >>> VAR self: ADDRESS; >>> BEGIN >>> IF threadRequestingSuspend = NIL THEN RETURN END; >>> self := GetActivation(); >>> IF self = threadRequestingSuspend THEN RETURN END; (* important consideration! *) >>> GetContext(self.context); (* roughly *) >>> self.suspended := TRUE; (* roughly *) >>> WaitForResume(); (* details to be determined, either the semaphore >>> * or maybe acquire per-thread lock. *) >>> END PollSuspendSlow; >>> >>> >>> The poll call could also be a function pointer and usually point to a function that does nothing. >>> But that'd require loading the address from a global, and calling it. >>> Probably more bloat than calling direct instead of indirect. >>> >>> >>> - Jay >>> >> From rodney_bates at lcwb.coop Thu Apr 29 18:07:00 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 29 Apr 2010 11:07:00 -0500 Subject: [M3devel] INTEGER In-Reply-To: <20100427173036.7DC501A2096@async.async.caltech.edu> References: <20100421185631.GA17051@topoi.pooq.com> <80775CA2-A2FD-40AF-B235-7DB84127762E@cs.purdue.edu> <20100422123805.GA19259@topoi.pooq.com> <87B45DCC-2B8A-4C69-97D7-240BC1E2252D@cs.purdue.edu> <20100422145522.GA19946@topoi.pooq.com> <28339030-6005-4C28-872C-A68CF24BF4DF@cs.purdue.edu> <20100422154357.GA20043@topoi.pooq.com> <270A99B5-173E-413B-8C28-E1CA68870FD4@cs.purdue.edu> <20100423094903.GC21281@topoi.pooq.com> <20100423185214.BA2EF1A20E1@async.async.caltech.edu> <20100423165613.GA22126@topoi.pooq.com> <20100424103435.A1CC41A20C2@async.async.caltech.edu> <4BD713C7.2060607@lcwb.coop> <20100427172400.D491F1A2096@async.async.caltech.edu> <20100427173036.7DC501A2096@async.async.caltech.edu> Message-ID: <4BD9AEA4.9080505@lcwb.coop> Oh, I get it! You are proposing a _mixed_ approach, where the values the programmer can designate are of fixed (though possibly nonstatic) size (like open arrays) but the intermediate results are of unbounded size that re-adapts to hold the actual value each time an operator is evaluated, (like BigInteger). And because only intermediate results work this way, they can be stack allocated, because intermediate results have LIFO lifetimes. These are quite different approaches to arithmetic. It does seem at least a bit strange to mix them in this way. Mika Nystrom wrote: > Mika Nystrom writes: > ... >> I am not worried as you are by the range problem. The saving grace is >> that the language has very few arithmetic operators on integers. >> + - * DIV MOD. It's not hard to do range arithmetic on these such that >> one can easily figure out how much memory is required to hold intermediate >> results. If you're happy with alloca (I don't mind it), that's what >> you do. You have three options in so far as calculating the required >> space: > ... > > To clarify a bit further, my proposal is that the ranges be lost in > the evaluation. Everything in the expression is simply of type LONGINT. > When the final result is assigned to a variable, there is a range check > (which can be dispensed with if the compiler can prove that there can > be no overrun). > > Isn't this how INTEGER subranges work? > > a : [0..2]; > b : [0..1]; > > a := 4*b - 2*b Well, not really. INTEGER intermediate results (even when the operands have subrange type) are computed in the fixed size INTEGER. This could sometimes be a lot bigger than the subranges and in some cases big enough to hold all possible results, given small subrange operandss. But they are still fixed size (and maximally efficient). The intermediate result can still overflow in many cases. This is quite different from a size that always adapts to the actual value computed, every time the operator is evaluated, and thus can never overflow. I thought you were trying to do this in your proposal, just with bigger sizes. Of course, what happens when an overflow occurs is a different question. Not very satisfactorily handled now, even for INTEGER, IMO. But it is not really possible in any language to handle overflows both well and efficiently, given current hardware. In any case, it's an orthogonal issue to when overflows happen. > > Mika > From hendrik at topoi.pooq.com Thu Apr 29 14:43:15 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 29 Apr 2010 08:43:15 -0400 Subject: [M3devel] INTEGER In-Reply-To: <4BD9AEA4.9080505@lcwb.coop> References: <20100422154357.GA20043@topoi.pooq.com> <270A99B5-173E-413B-8C28-E1CA68870FD4@cs.purdue.edu> <20100423094903.GC21281@topoi.pooq.com> <20100423185214.BA2EF1A20E1@async.async.caltech.edu> <20100423165613.GA22126@topoi.pooq.com> <20100424103435.A1CC41A20C2@async.async.caltech.edu> <4BD713C7.2060607@lcwb.coop> <20100427172400.D491F1A2096@async.async.caltech.edu> <20100427173036.7DC501A2096@async.async.caltech.edu> <4BD9AEA4.9080505@lcwb.coop> Message-ID: <20100429124315.GB12060@topoi.pooq.com> On Thu, Apr 29, 2010 at 11:07:00AM -0500, Rodney M. Bates wrote: > Oh, I get it! You are proposing a _mixed_ approach, where the values > the programmer can designate are of fixed (though possibly nonstatic) > size (like open arrays) but the intermediate results are of unbounded > size that re-adapts to hold the actual value each time an operator is > evaluated, (like BigInteger). And because only intermediate results > work this way, they can be stack allocated, because intermediate > results have LIFO lifetimes. In fact, the sizes of intermediate results can be determined statically, in theory, at least. An arithmetic operation with subranges as arguments has at most a finite number of possible argument pairs, and therefore at mist a finite number of possible results. A finite set of integers has a maximum and a minimum. In practices, there might be operations (such as shifts and exponentiation) for which there bounds are impractical. -- hendrik > > These are quite different approaches to arithmetic. It does seem > at least a bit strange to mix them in this way. Keeping track of the maximum sizes statically makes it a little less strange. -- hendrik From mika at async.async.caltech.edu Thu Apr 29 20:59:43 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Thu, 29 Apr 2010 11:59:43 -0700 Subject: [M3devel] INTEGER In-Reply-To: <20100429124315.GB12060@topoi.pooq.com> References: <20100422154357.GA20043@topoi.pooq.com> <270A99B5-173E-413B-8C28-E1CA68870FD4@cs.purdue.edu> <20100423094903.GC21281@topoi.pooq.com> <20100423185214.BA2EF1A20E1@async.async.caltech.edu> <20100423165613.GA22126@topoi.pooq.com> <20100424103435.A1CC41A20C2@async.async.caltech.edu> <4BD713C7.2060607@lcwb.coop> <20100427172400.D491F1A2096@async.async.caltech.edu> <20100427173036.7DC501A2096@async.async.caltech.edu> <4BD9AEA4.9080505@lcwb.coop> <20100429124315.GB12060@topoi.pooq.com> Message-ID: <20100429185943.334171A20A4@async.async.caltech.edu> hendrik at topoi.pooq.com writes: >On Thu, Apr 29, 2010 at 11:07:00AM -0500, Rodney M. Bates wrote: >> Oh, I get it! You are proposing a _mixed_ approach, where the values >> the programmer can designate are of fixed (though possibly nonstatic) >> size (like open arrays) but the intermediate results are of unbounded >> size that re-adapts to hold the actual value each time an operator is >> evaluated, (like BigInteger). And because only intermediate results >> work this way, they can be stack allocated, because intermediate >> results have LIFO lifetimes. > >In fact, the sizes of intermediate results can be determined statically, >in theory, at least. An arithmetic operation with subranges as >arguments has at most a finite number of possible argument pairs, and >therefore at mist a finite number of possible results. A finite set of >integers has a maximum and a minimum. > >In practices, there might be operations (such as shifts and >exponentiation) for which there bounds are impractical. > >-- hendrik Well, the language only has built-in operations for which the range checks are easy. The problem with only allowing static sized LONGINTs is that you can't write PROCEDURE F(READONLY a, b : LONGINT; VAR c : LONGINT) = BEGIN c := a + b END F; Instead you get a proliferation of Fs to cover every possible range... I suppose you can do it with generics but oh what a pain. Mika From wagner at elegosoft.com Thu Apr 29 21:43:16 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 29 Apr 2010 21:43:16 +0200 Subject: [M3devel] one more (64 bit) m3tests issue Message-ID: <20100429214316.p9i0v1j5kw04swwk@mail.elegosoft.com> For AMD64_..., there is one more unexpected test failure: http://hudson.modula3.com:8080/view/cm3/job/cm3-test-m3tests-AMD64_LINUX/555/testReport/(root)/m3tests/p179__alignment_of_ARRAY_OF_BITS_32_FOR_INTEGER This test fails on all AMD64 platforms. Comments? Ignore? I think all the others are either ancient legacy or have been looked at by Tony and Jay and postponed. 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 Thu Apr 29 22:32:42 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 29 Apr 2010 22:32:42 +0200 Subject: [M3devel] M3 language definition in cm3/doc Message-ID: <20100429223242.qanzwguv4wks80kc@mail.elegosoft.com> The M3 language definition is contained in several formats in the cm3 repository and web pages. Recent changes to the language have been added by Antony Hosking and Rodney Bates to cm3/doc/reference/complete/m3-defn-complete.tex There are also versions in other formats: cm3/doc/reference/complete/m3-defn-complete.html cm3/doc/reference/complete/m3-defn-complete.ps cm3/doc/reference/complete/m3-defn-complete.pdf Critical Mass added a split-up HTML version for online access, which I was not able to exactly recreate: cm3/doc/reference/*.html There is now a new variant of split HTML files in cm3/doc/reference/complete/html/*.html The files in this directory as well as the complete versions above can now be generated automatically by simply running `make' in the directory cm3/doc/reference/complete/. latex2html is used for HTML conversion, dvips for PS, and dvipdf for PDF creation. Of course latex2e must also be installed to create the device independent file (.dvi). I have updated all the formats based on the (hopefully) latest and greatest language spec in m3-defn-complete.tex. I haven't checked that thoroughly but trusted that it was all right. If you find any mistakes, please let me know. Please also note that I had to change some tabbing environments, as the latex2html script had some problems with generating readable HTML for existing ones. To ensure readable indentation, all lines should begin with a tab (\>). I have merged all the changes from the release branch to the trunk, too. I haven't tested them there though. Thanks for your attention, 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 lcwb.coop Thu Apr 29 23:19:09 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 29 Apr 2010 16:19:09 -0500 Subject: [M3devel] INTEGER In-Reply-To: <20100429124315.GB12060@topoi.pooq.com> References: <20100422154357.GA20043@topoi.pooq.com> <270A99B5-173E-413B-8C28-E1CA68870FD4@cs.purdue.edu> <20100423094903.GC21281@topoi.pooq.com> <20100423185214.BA2EF1A20E1@async.async.caltech.edu> <20100423165613.GA22126@topoi.pooq.com> <20100424103435.A1CC41A20C2@async.async.caltech.edu> <4BD713C7.2060607@lcwb.coop> <20100427172400.D491F1A2096@async.async.caltech.edu> <20100427173036.7DC501A2096@async.async.caltech.edu> <4BD9AEA4.9080505@lcwb.coop> <20100429124315.GB12060@topoi.pooq.com> Message-ID: <4BD9F7CD.50704@lcwb.coop> hendrik at topoi.pooq.com wrote: > On Thu, Apr 29, 2010 at 11:07:00AM -0500, Rodney M. Bates wrote: >> Oh, I get it! You are proposing a _mixed_ approach, where the values >> the programmer can designate are of fixed (though possibly nonstatic) >> size (like open arrays) but the intermediate results are of unbounded >> size that re-adapts to hold the actual value each time an operator is >> evaluated, (like BigInteger). And because only intermediate results >> work this way, they can be stack allocated, because intermediate >> results have LIFO lifetimes. > > In fact, the sizes of intermediate results can be determined statically, > in theory, at least. Yes. But only when all operands are "fixed" longint types, i.e. [L..U]. If any of them are "open" LONGINT, then the bounds are dynamic, in the proposal. An arithmetic operation with subranges as > arguments has at most a finite number of possible argument pairs, and > therefore at mist a finite number of possible results. A finite set of > integers has a maximum and a minimum. > > In practices, there might be operations (such as shifts and > exponentiation) for which there bounds are impractical. > > -- hendrik > >> These are quite different approaches to arithmetic. It does seem >> at least a bit strange to mix them in this way. > > Keeping track of the maximum sizes statically makes it a little less > strange. > > -- hendrik > From rodney_bates at lcwb.coop Thu Apr 29 23:45:23 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 29 Apr 2010 16:45:23 -0500 Subject: [M3devel] one more (64 bit) m3tests issue In-Reply-To: <20100429214316.p9i0v1j5kw04swwk@mail.elegosoft.com> References: <20100429214316.p9i0v1j5kw04swwk@mail.elegosoft.com> Message-ID: <4BD9FDF3.6070701@lcwb.coop> Looks like a 32/64 bit independence bug in the test. The test description, from m3tests/src/makefile says "alignment of ARRAY OF BITS 32 FOR INTEGER". This type would be illegal on a 64-bit machine. But the description is wrong. The type in the source file m3test/src/p1/p179/Main.m3 is actually "BITS 32 FOR [16_80000000..16_7FFFFFFF]" And, on a 64-bit native machine, this really is an empty type, as the compiler complains. On a 64-bit machine, 16_80000000 means 16_00000000800000, positive and larger than the upper bound. How about BITS 32 FOR [Word.Shift(-1,31)..16_7FFFFFFF], to be the same on any machine with >= 32-bit native word size? Or (-16_7FFFFFFF)-1?, which would be non-overflowing and same value on >= 32 bits. I don't think this test can be coded for < 32 bits or other than 2's complement and still be the same test. Wasn't there a discussion of this a while back? Olaf Wagner wrote: > For AMD64_..., there is one more unexpected test failure: > > http://hudson.modula3.com:8080/view/cm3/job/cm3-test-m3tests-AMD64_LINUX/555/testReport/(root)/m3tests/p179__alignment_of_ARRAY_OF_BITS_32_FOR_INTEGER > > > This test fails on all AMD64 platforms. > > Comments? Ignore? > > I think all the others are either ancient legacy or have been looked at > by Tony and Jay and postponed. > > Olaf From mika at async.async.caltech.edu Fri Apr 30 00:07:19 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Thu, 29 Apr 2010 15:07:19 -0700 Subject: [M3devel] INTEGER In-Reply-To: <4BD9AEA4.9080505@lcwb.coop> References: <20100421185631.GA17051@topoi.pooq.com> <80775CA2-A2FD-40AF-B235-7DB84127762E@cs.purdue.edu> <20100422123805.GA19259@topoi.pooq.com> <87B45DCC-2B8A-4C69-97D7-240BC1E2252D@cs.purdue.edu> <20100422145522.GA19946@topoi.pooq.com> <28339030-6005-4C28-872C-A68CF24BF4DF@cs.purdue.edu> <20100422154357.GA20043@topoi.pooq.com> <270A99B5-173E-413B-8C28-E1CA68870FD4@cs.purdue.edu> <20100423094903.GC21281@topoi.pooq.com> <20100423185214.BA2EF1A20E1@async.async.caltech.edu> <20100423165613.GA22126@topoi.pooq.com> <20100424103435.A1CC41A20C2@async.async.caltech.edu> <4BD713C7.2060607@lcwb.coop> <20100427172400.D491F1A2096@async.async.caltech.edu> <20100427173036.7DC501A2096@async.async.caltech.edu> <4BD9AEA4.9080505@lcwb.coop> Message-ID: <20100429220719.6DD991A20A4@async.async.caltech.edu> "Rodney M. Bates" writes: >Oh, I get it! You are proposing a _mixed_ approach, where the values >the programmer can designate are of fixed (though possibly nonstatic) >size (like open arrays) but the intermediate results are of unbounded >size that re-adapts to hold the actual value each time an operator is >evaluated, (like BigInteger). And because only intermediate results >work this way, they can be stack allocated, because intermediate >results have LIFO lifetimes. > >These are quite different approaches to arithmetic. It does seem >at least a bit strange to mix them in this way. Speeeaking of stack allocation's being possible owing to LIFO lifetimes..... The Green Book says the following: "[Lisp, ML, Smalltalk, and CLU's] general disposition towards heap allocation rather than stack allocation remains" May I draw the conclusion that exposing the difference between stack and heap allocation in the language is fair game for the Modula-3 definition? What I'm getting at is this. If my LONGINT proposal is workable, the following ought to be workable too: VAR a : NEW(ARRAY OF T, n); (Note: no REF, also no =.) It's an object upon which it is legal to perform exactly those things that are legal to do to b^, where previously b := NEW(REF ARRAY OF T, n) I don't have a good name for the type of a ("evanescent array"?), but I think being able to do this would make it possible to write efficient code in ways that today only C++ (to my knowledge) allows. I think the Modula-3 rules on what can (more importantly can't) be done with open arrays may be enough to restrict the feature so it doesn't lead to new complications (in the language definition---the implementation I'm not sure about). The lowest levels of the implementation would use alloca with a fallback to heap allocation if for some reason variable-sized stack objects are not allowed. LONGINT is then a rather natural specialization of the same rules. (Cf. ARRAY OF BITS 1 FOR BOOLEAN vs. SET OF.) Mika From rodney_bates at lcwb.coop Fri Apr 30 02:30:44 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 29 Apr 2010 19:30:44 -0500 Subject: [M3devel] INTEGER In-Reply-To: <20100429220719.6DD991A20A4@async.async.caltech.edu> References: <20100421185631.GA17051@topoi.pooq.com> <80775CA2-A2FD-40AF-B235-7DB84127762E@cs.purdue.edu> <20100422123805.GA19259@topoi.pooq.com> <87B45DCC-2B8A-4C69-97D7-240BC1E2252D@cs.purdue.edu> <20100422145522.GA19946@topoi.pooq.com> <28339030-6005-4C28-872C-A68CF24BF4DF@cs.purdue.edu> <20100422154357.GA20043@topoi.pooq.com> <270A99B5-173E-413B-8C28-E1CA68870FD4@cs.purdue.edu> <20100423094903.GC21281@topoi.pooq.com> <20100423185214.BA2EF1A20E1@async.async.caltech.edu> <20100423165613.GA22126@topoi.pooq.com> <20100424103435.A1CC41A20C2@async.async.caltech.edu> <4BD713C7.2060607@lcwb.coop> <20100427172400.D491F1A2096@async.async.caltech.edu> <20100427173036.7DC501A2096@async.async.caltech.edu> <4BD9AEA4.9080505@lcwb.coop> <20100429220719.6DD991A20A4@async.async.caltech.edu> Message-ID: <4BDA24B4.3090100@lcwb.coop> Mika Nystrom wrote: > "Rodney M. Bates" writes: >> Oh, I get it! You are proposing a _mixed_ approach, where the values >> the programmer can designate are of fixed (though possibly nonstatic) >> size (like open arrays) but the intermediate results are of unbounded >> size that re-adapts to hold the actual value each time an operator is >> evaluated, (like BigInteger). And because only intermediate results >> work this way, they can be stack allocated, because intermediate >> results have LIFO lifetimes. >> >> These are quite different approaches to arithmetic. It does seem >> at least a bit strange to mix them in this way. > > Speeeaking of stack allocation's being possible owing to LIFO lifetimes..... > > The Green Book says the following: > > "[Lisp, ML, Smalltalk, and CLU's] general disposition towards heap allocation > rather than stack allocation remains" > > May I draw the conclusion that exposing the difference between stack and > heap allocation in the language is fair game for the Modula-3 definition? I think the distinction is already exposed. If it's created by NEW, it's heap allocated. If it's a declared variable by VAR, it's stack allocated. > > What I'm getting at is this. If my LONGINT proposal is workable, the > following ought to be workable too: > > VAR a : NEW(ARRAY OF T, n); I seem to recall an argument the original designers made to the effect they felt declared variables of non-constant size were not worth the complication over just heap allocating them. I don't remember where, or the details. But yes, it could be made to work, I think. > > (Note: no REF, also no =.) It's an object upon which it is legal to > perform exactly those things that are legal to do to b^, where previously > > b := NEW(REF ARRAY OF T, n) > > I don't have a good name for the type of a ("evanescent array"?), but > I think being able to do this would make it possible to write efficient > code in ways that today only C++ (to my knowledge) allows. I think the > Modula-3 rules on what can (more importantly can't) be done with open > arrays may be enough to restrict the feature so it doesn't lead to new > complications (in the language definition---the implementation I'm not > sure about). To be precise, the severe limitations on open arrays apply only to how you can use an open array _type_. A _variable_ (or formal, field, element of open array, WITH-temp, etc.) of open array type can be used just about any way one of fixed array type can be. The lowest levels of the implementation would use alloca > with a fallback to heap allocation if for some reason variable-sized > stack objects are not allowed. > > LONGINT is then a rather natural specialization of the same rules. > (Cf. ARRAY OF BITS 1 FOR BOOLEAN vs. SET OF.) > > Mika > > From mika at async.async.caltech.edu Fri Apr 30 03:39:22 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Thu, 29 Apr 2010 18:39:22 -0700 Subject: [M3devel] INTEGER In-Reply-To: <4BDA24B4.3090100@lcwb.coop> References: <20100421185631.GA17051@topoi.pooq.com> <80775CA2-A2FD-40AF-B235-7DB84127762E@cs.purdue.edu> <20100422123805.GA19259@topoi.pooq.com> <87B45DCC-2B8A-4C69-97D7-240BC1E2252D@cs.purdue.edu> <20100422145522.GA19946@topoi.pooq.com> <28339030-6005-4C28-872C-A68CF24BF4DF@cs.purdue.edu> <20100422154357.GA20043@topoi.pooq.com> <270A99B5-173E-413B-8C28-E1CA68870FD4@cs.purdue.edu> <20100423094903.GC21281@topoi.pooq.com> <20100423185214.BA2EF1A20E1@async.async.caltech.edu> <20100423165613.GA22126@topoi.pooq.com> <20100424103435.A1CC41A20C2@async.async.caltech.edu> <4BD713C7.2060607@lcwb.coop> <20100427172400.D491F1A2096@async.async.caltech.edu> <20100427173036.7DC501A2096@async.async.caltech.edu> <4BD9AEA4.9080505@lcwb.coop> <20100429220719.6DD991A20A4@async.async.caltech.edu> <4BDA24B4.3090100@lcwb.coop> Message-ID: <20100430013922.5DCB21A20A9@async.async.caltech.edu> "Rodney M. Bates" writes: > > >I seem to recall an argument the original designers made to the effect >they felt declared variables of non-constant size were not worth the >complication over just heap allocating them. I don't remember where, >or the details. But yes, it could be made to work, I think. Yes, of course, that is why they didn't do it. I'm not sure it's even particularly difficult. > >> >> (Note: no REF, also no =.) It's an object upon which it is legal to >> perform exactly those things that are legal to do to b^, where previously >> >> b := NEW(REF ARRAY OF T, n) >> >> I don't have a good name for the type of a ("evanescent array"?), but >> I think being able to do this would make it possible to write efficient >> code in ways that today only C++ (to my knowledge) allows. I think the >> Modula-3 rules on what can (more importantly can't) be done with open >> arrays may be enough to restrict the feature so it doesn't lead to new >> complications (in the language definition---the implementation I'm not >> sure about). > >To be precise, the severe limitations on open arrays apply only to how >you can use an open array _type_. A _variable_ (or formal, field, element >of open array, WITH-temp, etc.) of open array type can be used just >about any way one of fixed array type can be. Right, and I think it's enough. What we care about here is that we can't return the variable-sized array nor assign it to anything. I think it falls out rather naturally. E.g., to take an already fairly nasty example: PROCEDURE F() : ARRAY [0..1] OF T = VAR x : NEW(ARRAY OF T, 2); BEGIN RETURN x END F; here there is an implicit type check on return. This is probably already implemented by the compiler as: PROCEDURE F(VAR retval : ARRAY [0..1] OF T) = VAR x : NEW(ARRAY OF T, 2); BEGIN retval := x; (* implicit shape check *) RETURN END F; Another fairly nasty example: PROCEDURE G(x : ARRAY OF T) = ... VAR x : NEW(ARRAY OF T, 2); BEGIN G(x) END This is no different from writing VAR x : ARRAY [0..1] OF T; BEGIN G(x) END and I don't see how introducing the variable size makes it really any more difficult. If the compiler writer doesn't know how to do it in one particular case he can also just punt the problem to heap allocation. Maybe there is something I'm missing but it has always bugged me that most of the time I have to heap-allocate array temporaries. Mika From wagner at elegosoft.com Thu Apr 1 10:33:13 2010 From: wagner at elegosoft.com (wagner at elegosoft.com) Date: Thu, 01 Apr 2010 10:33:13 +0200 Subject: [M3devel] m3back directions? In-Reply-To: References: <20100331121830.22q33okrokkwsgwk@mail.elegosoft.com> Message-ID: <20100401103313.j86zit1w0kc0wkoc@mail.elegosoft.com> Quoting Tony Hosking : > On 31 Mar 2010, at 06:18, wagner at elegosoft.com wrote: > >> Quoting Jay K : >> >>> I'm curious what, if anything, people are interested in in m3back? >>> >>> There are several mostly independent directions: >>> >>> - remove it; use the gcc backend or other (burg, llvm, generate C) >>> >>> - expand to support other targets, AMD64_*, including AMD64_NT >>> >>> m3objfile would need macho/elf support for non-NT >> >> It would be great if we could use the integrated backend for other >> targets, too. Adding ELF support will be a lot of work, but it's probably >> worth it. > > Have you looked at the pm3 Linux support? Indeed I had forgotten about that. I'll take at look at the Easter holidays, Olaf From jay.krell at cornell.edu Thu Apr 1 14:33:52 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 1 Apr 2010 12:33:52 +0000 Subject: [M3devel] m3back directions? In-Reply-To: <20100401103313.j86zit1w0kc0wkoc@mail.elegosoft.com> References: , <20100331121830.22q33okrokkwsgwk@mail.elegosoft.com>, , <20100401103313.j86zit1w0kc0wkoc@mail.elegosoft.com> Message-ID: I think it was GPL though. - Jay > Date: Thu, 1 Apr 2010 10:33:13 +0200 > From: wagner at elegosoft.com > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] m3back directions? > > Quoting Tony Hosking : > > > On 31 Mar 2010, at 06:18, wagner at elegosoft.com wrote: > > > >> Quoting Jay K : > >> > >>> I'm curious what, if anything, people are interested in in m3back? > >>> > >>> There are several mostly independent directions: > >>> > >>> - remove it; use the gcc backend or other (burg, llvm, generate C) > >>> > >>> - expand to support other targets, AMD64_*, including AMD64_NT > >>> > >>> m3objfile would need macho/elf support for non-NT > >> > >> It would be great if we could use the integrated backend for other > >> targets, too. Adding ELF support will be a lot of work, but it's probably > >> worth it. > > > > Have you looked at the pm3 Linux support? > > Indeed I had forgotten about that. I'll take at look at the Easter > holidays, > > Olaf > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Thu Apr 1 16:28:53 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 01 Apr 2010 09:28:53 -0500 Subject: [M3devel] changing m3middle/m3back to have multiple passes? In-Reply-To: References: Message-ID: <4BB4ADA5.70003@lcwb.coop> Jay K wrote: > I'm thinking m3back could use multiple passes. This would be a big reversal of the fundamental design philosophy of this back end. Its primary design criterion was to be simple and fast. That means single-pass. There have been several compilers (often whole compilers, not just code generators) written to this principle. For some purposes, it is a good thing. This, of course, inevitably means the generated code is not as small/fast as it could be. It's part of the trade off. We have two points on this trade off scale now. I think we want to keep the one-pass code generator. If you change it, at least make a branch and keep the original design easily accessible. > > > There a few reasons, things that would be easier/possible if it had them. > > > I know adding passes will slow it down, but I suspect it will still be > about as pleasantly fast as it is now. > > > The optimizations I have in mind: > inlining, including where function definitions come after the call > I think inlining where the "small" functions come first is doable in > pass, > but not if uses come before calls. > > > not saving unused registers > This only a small optimization and could probably be done in one > pass if m3objfile got a "memmove" operation. Well, I already > have the optimization in somewhat, but it involves nop-ing out > code instead of removing it completely. > > > dead store removal, and then removing the resulting dead code to > compute the value > > > possibly better register allocation -- e.g. based on noticing which > variables are used often, or based on how they are used, for example > if a variable (or expression/temporary) ends serving a shift count, > we should favor putting it in ecx up front, instead of moving it to > ecx later, but we don't generally know this till too late > > > As I understand, m3middle already has the notion of "recording" > and "playing back" calls to the M3CG interface. > That seems like a good starting point? > > > Some optimizations can be made via "CG to CG" transforms. > > > However I think in general I think the required design would include: > - ability to add in "private operations"; maybe > - ability to add "private data" to existing operations > A very simple one is annotate functions with required frame size. > This isn't currently known until the end of the function. > - clearly, ability to remove operations > > > Can/should we somehow augment m3middle in support of this line of thinking? > > > Or is that just not the way to go? > Each backend should have its own internal representation and loop over it? > > - Jay > From jay.krell at cornell.edu Thu Apr 1 17:10:04 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 1 Apr 2010 15:10:04 +0000 Subject: [M3devel] changing m3middle/m3back to have multiple passes? In-Reply-To: <4BB4ADA5.70003@lcwb.coop> References: , <4BB4ADA5.70003@lcwb.coop> Message-ID: Simple and fast does not entirely preclude multiple passes, and one pass does not equate to simple, though yes probably fast. The front end already makes multiple passes I believe, and is still fast. Sometimes decomposition into more smaller pieces (passes, layers, etc.) make things simpler. Albeit slower. A more historical factor here is that multiple passes imply keeping more data in memory longer. Implies slower. However memory capacity has increased tremendously. Whereas I'm only thinking about multiple passes, while still compiling one file at a time, other compilation systems have capitalized on larger memories and now compile entire programs at once, including multiple passes. This goes by multiple names -- "whole program optimization", "link time codegen (LTCG)". And enables even more aggressive but still "fairly simple" optimization, such as cross module inlining, custom calling conventions. I say "fairly simple", because these are just the same optimizations one would perform within a module, merely applied across module boundaries. (Sometimes what people do is #include all .c files into one master .c file, to help get the compiler to see everything at once. sqllite does this, for example.) Surely we can afford multiple passes on a per-file basis. ? The code is already not that easy to understand imho. It took me quite some time to get comfortable and add the 64 bit integer support, years. And there's a few things I still don't understand (you can tell from my comments in the code, like where do I need to call "newdest")? Embrace it and make it incrementally harder to understand (by virtue of simply adding to it), or decide it is stuck asis? I'm not entirely sure. While it is an interesting compromise in its current form, I'm fairly certain there are other viable compromises that achieve better code quality, are still plenty fast, and aren't much more difficult to understand. Heck, I found it confusing at first that the -debug output is wrong in some places. That is a fallout from it being single pass "plus patching". The debug output doesn't include the "patches". I have some very simple small optimizations in mind. And then, in stepping through code, and writing code, inlining constantly comes to mind. In fact, I frequently see "manual partial inlining" in the Modula-3 code. It'd be nifty if the Modula-3 code could have less duplication, relying on the compiler more. I don't see inlining as entirely simple, but I've given it a little thought and it might not be so hard. I think it can be done, roughly, by taking the body of a procedure as expressed as cg.i3 calls, omitting the begin/procedure, and just "playing them back" at the call site. You'd only do this for "small" functions. You'd have to make some adjustments like merging local variables and exception handling, though really the inlined function would just be a "block". Probably the way to go here, if inlining is really to be considered, is first implement it as "one pass plus some memory", and only inline when the definition comes before the call. Once that is achieved, no small feat, further considering can be made to allow for inlining when the call precedes the definition. eh, sorry, I'm tried, rambling. - Jay > Date: Thu, 1 Apr 2010 09:28:53 -0500 > From: rodney_bates at lcwb.coop > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] changing m3middle/m3back to have multiple passes? > > > > Jay K wrote: > > I'm thinking m3back could use multiple passes. > > This would be a big reversal of the fundamental design philosophy of this > back end. Its primary design criterion was to be simple and fast. That > means single-pass. There have been several compilers (often whole compilers, > not just code generators) written to this principle. For some purposes, > it is a good thing. > > This, of course, inevitably means the generated code is not as small/fast > as it could be. It's part of the trade off. We have two points on this > trade off scale now. I think we want to keep the one-pass code generator. > If you change it, at least make a branch and keep the original design > easily accessible. > > > > > > > > There a few reasons, things that would be easier/possible if it had them. > > > > > > I know adding passes will slow it down, but I suspect it will still be > > about as pleasantly fast as it is now. > > > > > > The optimizations I have in mind: > > inlining, including where function definitions come after the call > > I think inlining where the "small" functions come first is doable in > > pass, > > but not if uses come before calls. > > > > > > not saving unused registers > > This only a small optimization and could probably be done in one > > pass if m3objfile got a "memmove" operation. Well, I already > > have the optimization in somewhat, but it involves nop-ing out > > code instead of removing it completely. > > > > > > dead store removal, and then removing the resulting dead code to > > compute the value > > > > > > possibly better register allocation -- e.g. based on noticing which > > variables are used often, or based on how they are used, for example > > if a variable (or expression/temporary) ends serving a shift count, > > we should favor putting it in ecx up front, instead of moving it to > > ecx later, but we don't generally know this till too late > > > > > > As I understand, m3middle already has the notion of "recording" > > and "playing back" calls to the M3CG interface. > > That seems like a good starting point? > > > > > > Some optimizations can be made via "CG to CG" transforms. > > > > > > However I think in general I think the required design would include: > > - ability to add in "private operations"; maybe > > - ability to add "private data" to existing operations > > A very simple one is annotate functions with required frame size. > > This isn't currently known until the end of the function. > > - clearly, ability to remove operations > > > > > > Can/should we somehow augment m3middle in support of this line of thinking? > > > > > > Or is that just not the way to go? > > Each backend should have its own internal representation and loop over it? > > > > - Jay > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Apr 1 17:59:58 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 1 Apr 2010 11:59:58 -0400 Subject: [M3devel] m3back directions? In-Reply-To: References: , <20100331121830.22q33okrokkwsgwk@mail.elegosoft.com>, , <20100401103313.j86zit1w0kc0wkoc@mail.elegosoft.com> Message-ID: All of PM3 is licensed the same way as CM3 (they both derive from the same DEC SRC sources). On 1 Apr 2010, at 08:33, Jay K wrote: > I think it was GPL though. > > - Jay > > > Date: Thu, 1 Apr 2010 10:33:13 +0200 > > From: wagner at elegosoft.com > > To: hosking at cs.purdue.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] m3back directions? > > > > Quoting Tony Hosking : > > > > > On 31 Mar 2010, at 06:18, wagner at elegosoft.com wrote: > > > > > >> Quoting Jay K : > > >> > > >>> I'm curious what, if anything, people are interested in in m3back? > > >>> > > >>> There are several mostly independent directions: > > >>> > > >>> - remove it; use the gcc backend or other (burg, llvm, generate C) > > >>> > > >>> - expand to support other targets, AMD64_*, including AMD64_NT > > >>> > > >>> m3objfile would need macho/elf support for non-NT > > >> > > >> It would be great if we could use the integrated backend for other > > >> targets, too. Adding ELF support will be a lot of work, but it's probably > > >> worth it. > > > > > > Have you looked at the pm3 Linux support? > > > > Indeed I had forgotten about that. I'll take at look at the Easter > > holidays, > > > > Olaf > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Apr 1 18:08:52 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 1 Apr 2010 12:08:52 -0400 Subject: [M3devel] changing m3middle/m3back to have multiple passes? In-Reply-To: <4BB4ADA5.70003@lcwb.coop> References: <4BB4ADA5.70003@lcwb.coop> Message-ID: <452F7418-679D-49D3-BC44-EA07B157AEF5@cs.purdue.edu> Indeed. I think we would be better served exploring alternatives like LLVM where we can rely on others to implement the grungy compiler optimisations and we can sail above the fray worrying about the language proper On 1 Apr 2010, at 10:28, Rodney M. Bates wrote: > > > Jay K wrote: >> I'm thinking m3back could use multiple passes. > > This would be a big reversal of the fundamental design philosophy of this > back end. Its primary design criterion was to be simple and fast. That > means single-pass. There have been several compilers (often whole compilers, > not just code generators) written to this principle. For some purposes, > it is a good thing. > > This, of course, inevitably means the generated code is not as small/fast > as it could be. It's part of the trade off. We have two points on this > trade off scale now. I think we want to keep the one-pass code generator. > If you change it, at least make a branch and keep the original design > easily accessible. > > >> There a few reasons, things that would be easier/possible if it had them. >> I know adding passes will slow it down, but I suspect it will still be >> about as pleasantly fast as it is now. >> The optimizations I have in mind: >> inlining, including where function definitions come after the call >> I think inlining where the "small" functions come first is doable in pass, >> but not if uses come before calls. >> not saving unused registers >> This only a small optimization and could probably be done in one >> pass if m3objfile got a "memmove" operation. Well, I already >> have the optimization in somewhat, but it involves nop-ing out >> code instead of removing it completely. >> dead store removal, and then removing the resulting dead code to compute the value >> possibly better register allocation -- e.g. based on noticing which >> variables are used often, or based on how they are used, for example >> if a variable (or expression/temporary) ends serving a shift count, >> we should favor putting it in ecx up front, instead of moving it to >> ecx later, but we don't generally know this till too late >> As I understand, m3middle already has the notion of "recording" >> and "playing back" calls to the M3CG interface. >> That seems like a good starting point? >> Some optimizations can be made via "CG to CG" transforms. >> However I think in general I think the required design would include: >> - ability to add in "private operations"; maybe >> - ability to add "private data" to existing operations >> A very simple one is annotate functions with required frame size. >> This isn't currently known until the end of the function. >> - clearly, ability to remove operations >> Can/should we somehow augment m3middle in support of this line of thinking? >> Or is that just not the way to go? >> Each backend should have its own internal representation and loop over it? >> - Jay From hendrik at topoi.pooq.com Sun Apr 4 03:20:57 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sat, 3 Apr 2010 21:20:57 -0400 Subject: [M3devel] changing m3middle/m3back to have multiple passes? In-Reply-To: References: <4BB4ADA5.70003@lcwb.coop> Message-ID: <20100404012057.GA20078@topoi.pooq.com> On Thu, Apr 01, 2010 at 03:10:04PM +0000, Jay K wrote: > > However memory capacity has increased tremendously. > > > > > > Whereas I'm only thinking about multiple passes, while still compiling > one file at a time, > > other compilation systems have capitalized on larger memories and now > compile entire programs at once, including multiple passes. > > This goes by multiple names -- "whole program optimization", "link > time codegen (LTCG)". Link-time code generation was already involved in Mark Rain's Mary 2 compiler in the early 80's. It didn't actually require today's huge memories. Every now and then the Modula 3 compiler seems to decide to recompile something because new source had been discovered, or soething like that. I suspect this is because a new .m3 file changes the memory layout that was assumed in aanother source file, so that other one needs to be reconsidered. Is the complexity of tracking that simpler or more complex than doing whole-program compilation? It's possible that file-by-file compilation is a simpler match for interacting with foreign-language compilations, theough. It two languages insist on only compiling whole programs, it makes mixed-language programming difficult. -- hendrik From jay.krell at cornell.edu Sat Apr 3 03:34:22 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 3 Apr 2010 01:34:22 +0000 Subject: [M3devel] changing m3middle/m3back to have multiple passes? In-Reply-To: <20100404012057.GA20078@topoi.pooq.com> References: <4BB4ADA5.70003@lcwb.coop>, , <20100404012057.GA20078@topoi.pooq.com> Message-ID: Good points. I forgot to clarify that to some extent I just want to make multiple passes over functions, not files. => even less memory and slow down In particular, I want to know if a frame size is < 256, or < 4K or >= 4K. The >= 4K case isn't handled correctly today I believe, though will generally work. < 256 affords one byte of savings. I'd also like to know what registers are used, for 1, 2, or 3 bytes saved. While these are small, they are very broadly applicable. Consider that even the smallest of functions: PROCEDURE F(): INTEGER = BEGIN RETURN 1 END F; compiles/compiled to something like: push ebp mov ebp, esp sub esp, 0 ; yes, we are willing to put zero here, and it takes 2 bytes push esi ; I nop this out now. push edi ; I nop this out now. push ebx ; I nop this out now. mov eax, 1 pop ebx ; I optimize this out now. pop edi ; I optimize this out now. pop esi ; I optimize this out now. leave 0 ; I think ret when, if you punt the point of frame point omission, it could be: push ebp mov ebp, esp mov eax, 1 leave 0 ; I think. ret or if you allow for frame pointer omission: mov eax, 1 ret (Let's assume the address is taken, therefore it can't always easily be inlined.) "imagine if all code was multiplied out like this" Omitting the frame pointer hurts stack walk and debugging, however I think there is a midddle ground that people don't discuss: if a function takes no parameters and has no locals, then omit the frame pointer Possibly also if it has no locals and/or makes no function calls. Like, if it never uses esp or ebp. Actually this is encoded in PowerPC and AMD64 calling conventions, leaf functions can optimize their prologue/epilogue. But it doesn't seem come up with regarding x86. There again, multiple passes help. Multiple passes over a function would also offer things like eliminating dead stores, and cascading elimination of dead code, e.g: a := b + 1; (* eliminate this whole line *) a := b + 2; Granted, I am interested in multiple passes over a file too, for inlining. What I'm really going to do though is try to provide ObjFile.Move so that at the end of the function, I can "move" the entire function up or down a few bytes, or maybe only up. You can imagine "down" to fix the >= 4K case, but you might as well model that as reserving room for the worst case in first pass, and then move down usually. I think it just requires that I understand relocs much better, which is a good goal anyway for working with the code. You know -- perform a not well motivated change to some code, for purposes of exercise -- understanding the code and how to change it, so that when a better motivated change comes along, we aren't stuck. Also, I only recently realized/learned the high value of "sequential access" as it relates to "working set". Let's say you really have more data than memory? In a compiler we don't, but some applications do (plain text indexing of large data). Then what you do is: To whatever extent you can, break the data down into smaller pieces. At some level, random access is unavoidable, say, to sort small data. When you can't break the data down: Access it linearly, not randomly: mergesort instead of quicksort. Minimize the number of passes, but there is tradeoff between number of passes and working set size. Linear access keeps working set "constant", even if you are slowed down by having to reread data from disk. Yes I do see that message from the front end. I haven't looked into what it means, but yeah presumably something like a pessimistic first pass, followed by discovery of layout information, followed by more optimistic second pass. You might imagine, for example, knowing the sizes of opaque or object types. The front end makes multiple passes. I suspect for significant simplicity or "possibility" -- it might be darn difficult to implement in fewer passes, without contorting the code a lot. If you look how how "patching" and "labels" work in the backend, that's probably an example of where multiple passes would be more general and simpler, but where the "contortions" are well known and not too bad. It uses "patching" to fill in the frame size for example, and I now use that to nop out unnecessary prolog instructions (on the theory that nop it is a small optimization). Though, again, patching isn't sufficient for >4K frames. Very long standing bug there, I have to confirm and fix soon. Good points about whole program optimization. I think there are ways to address this. Not any time soon. Doing optimization and codegen at "link time" I think is somewhat of a hack in these systems. One we can't easily play into, as you point out. However, where we use the gcc backend and linker, we probably can, easily. That is many platforms. gcc does have this option. Also we could optimize "among" all the *.m3 files, just lose out on any M3<=>C optimizations. In reality, let me first think about NTObjFile.Move as a way to do some small optimizations, NTObjFile CodeView generation, maybe inlining, maybe LLVM. Testing/optimizing the atomics (add,sub,xor can improve, also store and probably load). Everything else is too much for the time being. Maybe we can do some target independent optimizations in m3front or m3front/cg or m3middle as well. Inlining could be done there, but the metrics of when to do it aren't really available. Only for *extremely* cheap seeming functions could the front end make a reliable target-independent choice. Oh wait -- that is interesting. If you consider just the case of inlining functions whose definitions precede use, the backend could "measure" a function, after generating it, and report back to the frontend if it should strongly consider inlining it. Then upon subsequent calls, the frontend could do the inlining. Such measurement is always going to be heuristic, but you can imagine stuff like number of cg calls number of parameters does it return a value As well, if had a <* FORCEINLINE *> pragma, the frontend could implement that. I'm pretty sure. Not clear if better to leave the decision to the compiler or not. After all, C and C++ have "inline" and "__inline" that are just hints that modern compilers ignore, and Visual C++ has "__forceinline", which generates a warning when not honored. Seems to be a bit of an arms race in terms of who things he knows better, programmer or compiler. Used to always be the programmer, then shifted to compiler, now not clear. - Jay > Date: Sat, 3 Apr 2010 21:20:57 -0400 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] changing m3middle/m3back to have multiple passes? > > On Thu, Apr 01, 2010 at 03:10:04PM +0000, Jay K wrote: > > > > However memory capacity has increased tremendously. > > > > > > > > > > > > Whereas I'm only thinking about multiple passes, while still compiling > > one file at a time, > > > > other compilation systems have capitalized on larger memories and now > > compile entire programs at once, including multiple passes. > > > > This goes by multiple names -- "whole program optimization", "link > > time codegen (LTCG)". > > Link-time code generation was already involved in Mark Rain's Mary 2 > compiler in the early 80's. It didn't actually require today's huge > memories. > > Every now and then the Modula 3 compiler seems to decide to recompile > something because new source had been discovered, or soething like that. > I suspect this is because a new .m3 file changes the memory layout that > was assumed in aanother source file, so that other one needs to be > reconsidered. Is the complexity of tracking that simpler or more > complex than doing whole-program compilation? > > It's possible that file-by-file compilation is a simpler match for > interacting with foreign-language compilations, theough. It two > languages insist on only compiling whole programs, it makes > mixed-language programming difficult. > > -- hendrik -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Apr 3 13:02:56 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 3 Apr 2010 11:02:56 +0000 Subject: [M3devel] m3back directions? In-Reply-To: References: , , <20100331121830.22q33okrokkwsgwk@mail.elegosoft.com>, , , , <20100401103313.j86zit1w0kc0wkoc@mail.elegosoft.com>, , Message-ID: No, really. GPL. http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/pm3/m3/pm3/language/modula3/m3compiler/m3back/src/linux/Codex86.m3?rev=1.3;content-type=text%2Fplain http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/pm3/m3/pm3/language/modula3/m3compiler/m3objfile/src/linux/ELFObjFile.m3?rev=1.2;content-type=text%2Fplain - Jay From: hosking at cs.purdue.edu Date: Thu, 1 Apr 2010 11:59:58 -0400 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] m3back directions? All of PM3 is licensed the same way as CM3 (they both derive from the same DEC SRC sources). On 1 Apr 2010, at 08:33, Jay K wrote: I think it was GPL though. - Jay > Date: Thu, 1 Apr 2010 10:33:13 +0200 > From: wagner at elegosoft.com > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] m3back directions? > > Quoting Tony Hosking : > > > On 31 Mar 2010, at 06:18, wagner at elegosoft.com wrote: > > > >> Quoting Jay K : > >> > >>> I'm curious what, if anything, people are interested in in m3back? > >>> > >>> There are several mostly independent directions: > >>> > >>> - remove it; use the gcc backend or other (burg, llvm, generate C) > >>> > >>> - expand to support other targets, AMD64_*, including AMD64_NT > >>> > >>> m3objfile would need macho/elf support for non-NT > >> > >> It would be great if we could use the integrated backend for other > >> targets, too. Adding ELF support will be a lot of work, but it's probably > >> worth it. > > > > Have you looked at the pm3 Linux support? > > Indeed I had forgotten about that. I'll take at look at the Easter > holidays, > > Olaf > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Apr 3 19:24:16 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 3 Apr 2010 13:24:16 -0400 Subject: [M3devel] m3back directions? In-Reply-To: References: , , <20100331121830.22q33okrokkwsgwk@mail.elegosoft.com>, , , , <20100401103313.j86zit1w0kc0wkoc@mail.elegosoft.com>, , Message-ID: <4C7DFD56-676D-4E33-983F-29FA41357053@cs.purdue.edu> Interesting. We can still use it (like gcc) right? Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 3 Apr 2010, at 07:02, Jay K wrote: > No, really. GPL. > > http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/pm3/m3/pm3/language/modula3/m3compiler/m3back/src/linux/Codex86.m3?rev=1.3;content-type=text%2Fplain > > http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/pm3/m3/pm3/language/modula3/m3compiler/m3objfile/src/linux/ELFObjFile.m3?rev=1.2;content-type=text%2Fplain > > - Jay > > > From: hosking at cs.purdue.edu > Date: Thu, 1 Apr 2010 11:59:58 -0400 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] m3back directions? > > All of PM3 is licensed the same way as CM3 (they both derive from the same DEC SRC sources). > > > On 1 Apr 2010, at 08:33, Jay K wrote: > > I think it was GPL though. > > - Jay > > > Date: Thu, 1 Apr 2010 10:33:13 +0200 > > From: wagner at elegosoft.com > > To: hosking at cs.purdue.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] m3back directions? > > > > Quoting Tony Hosking : > > > > > On 31 Mar 2010, at 06:18, wagner at elegosoft.com wrote: > > > > > >> Quoting Jay K : > > >> > > >>> I'm curious what, if anything, people are interested in in m3back? > > >>> > > >>> There are several mostly independent directions: > > >>> > > >>> - remove it; use the gcc backend or other (burg, llvm, generate C) > > >>> > > >>> - expand to support other targets, AMD64_*, including AMD64_NT > > >>> > > >>> m3objfile would need macho/elf support for non-NT > > >> > > >> It would be great if we could use the integrated backend for other > > >> targets, too. Adding ELF support will be a lot of work, but it's probably > > >> worth it. > > > > > > Have you looked at the pm3 Linux support? > > > > Indeed I had forgotten about that. I'll take at look at the Easter > > holidays, > > > > Olaf > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Sun Apr 4 01:41:31 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sat, 03 Apr 2010 18:41:31 -0500 Subject: [M3devel] m3back directions? In-Reply-To: References: , , <20100331121830.22q33okrokkwsgwk@mail.elegosoft.com>, , , , <20100401103313.j86zit1w0kc0wkoc@mail.elegosoft.com>, , Message-ID: <4BB7D22B.5000107@lcwb.coop> Wasn't it written an Montreal Poly as a student project or something? Jay K wrote: > No, really. GPL. > > http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/pm3/m3/pm3/language/modula3/m3compiler/m3back/src/linux/Codex86.m3?rev=1.3;content-type=text%2Fplain > > http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/pm3/m3/pm3/language/modula3/m3compiler/m3objfile/src/linux/ELFObjFile.m3?rev=1.2;content-type=text%2Fplain > > - Jay > > > ------------------------------------------------------------------------ > From: hosking at cs.purdue.edu > Date: Thu, 1 Apr 2010 11:59:58 -0400 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] m3back directions? > > All of PM3 is licensed the same way as CM3 (they both derive from the > same DEC SRC sources). > > > On 1 Apr 2010, at 08:33, Jay K wrote: > > I think it was GPL though. > > - Jay > > > Date: Thu, 1 Apr 2010 10:33:13 +0200 > > From: wagner at elegosoft.com > > To: hosking at cs.purdue.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] m3back directions? > > > > Quoting Tony Hosking >: > > > > > On 31 Mar 2010, at 06:18, wagner at elegosoft.com > wrote: > > > > > >> Quoting Jay K >: > > >> > > >>> I'm curious what, if anything, people are interested in in m3back? > > >>> > > >>> There are several mostly independent directions: > > >>> > > >>> - remove it; use the gcc backend or other (burg, llvm, generate C) > > >>> > > >>> - expand to support other targets, AMD64_*, including AMD64_NT > > >>> > > >>> m3objfile would need macho/elf support for non-NT > > >> > > >> It would be great if we could use the integrated backend for other > > >> targets, too. Adding ELF support will be a lot of work, but > it's probably > > >> worth it. > > > > > > Have you looked at the pm3 Linux support? > > > > Indeed I had forgotten about that. I'll take at look at the Easter > > holidays, > > > > Olaf > > > > > > From jay.krell at cornell.edu Sun Apr 4 02:35:32 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 4 Apr 2010 00:35:32 +0000 Subject: [M3devel] m3back directions? In-Reply-To: <4BB7D22B.5000107@lcwb.coop> References: , ,,<20100331121830.22q33okrokkwsgwk@mail.elegosoft.com>, ,,, , , <20100401103313.j86zit1w0kc0wkoc@mail.elegosoft.com>, , , , , , <4BB7D22B.5000107@lcwb.coop> Message-ID: Do you mean to ask, am I embarassed that I nor any of us have done it ourselves by now? Yes. :) (Though I don't know about the question as stated.) Interest level here is higher than I expected in non-gcc backends. And Tony gave the answer I expected. :) I don't know. It's kind of cheating, less fun, very hard to ramp up on, but once there very useful and good reuse and code quality. So I'll consider this higher priority, if nobody beats me to it. I also noticed the two burg backends in the 3.6 tree. Did they build and work? Eh, rhetorical mostly. It's hard to get one's head around this stuff. Easier to improve m3back. Though they had a MIPS backend too and I do have some MIPS machines.. (SGIs and router). I'd like to first: current release CodeView debugging test/optimize atomics (anyone can test this, please do) test/fix 64bit range checks (anyone can test this, please do) the micro optimizations I've been repeatedly describing (not multi pass, just "objfile.move") And then once I have "move", fix the >4K frame bug. And then I'll try to consider other x86 backends again. - Jay > Date: Sat, 3 Apr 2010 18:41:31 -0500 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: Re: [M3devel] m3back directions? > > Wasn't it written an Montreal Poly as a student project or something? > > Jay K wrote: > > No, really. GPL. > > > > http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/pm3/m3/pm3/language/modula3/m3compiler/m3back/src/linux/Codex86.m3?rev=1.3;content-type=text%2Fplain > > > > http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/pm3/m3/pm3/language/modula3/m3compiler/m3objfile/src/linux/ELFObjFile.m3?rev=1.2;content-type=text%2Fplain > > > > - Jay > > > > > > ------------------------------------------------------------------------ > > From: hosking at cs.purdue.edu > > Date: Thu, 1 Apr 2010 11:59:58 -0400 > > To: jay.krell at cornell.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] m3back directions? > > > > All of PM3 is licensed the same way as CM3 (they both derive from the > > same DEC SRC sources). > > > > > > On 1 Apr 2010, at 08:33, Jay K wrote: > > > > I think it was GPL though. > > > > - Jay > > > > > Date: Thu, 1 Apr 2010 10:33:13 +0200 > > > From: wagner at elegosoft.com > > > To: hosking at cs.purdue.edu > > > CC: m3devel at elegosoft.com > > > Subject: Re: [M3devel] m3back directions? > > > > > > Quoting Tony Hosking > >: > > > > > > > On 31 Mar 2010, at 06:18, wagner at elegosoft.com > > wrote: > > > > > > > >> Quoting Jay K > >: > > > >> > > > >>> I'm curious what, if anything, people are interested in in m3back? > > > >>> > > > >>> There are several mostly independent directions: > > > >>> > > > >>> - remove it; use the gcc backend or other (burg, llvm, generate C) > > > >>> > > > >>> - expand to support other targets, AMD64_*, including AMD64_NT > > > >>> > > > >>> m3objfile would need macho/elf support for non-NT > > > >> > > > >> It would be great if we could use the integrated backend for other > > > >> targets, too. Adding ELF support will be a lot of work, but > > it's probably > > > >> worth it. > > > > > > > > Have you looked at the pm3 Linux support? > > > > > > Indeed I had forgotten about that. I'll take at look at the Easter > > > holidays, > > > > > > Olaf > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Apr 4 10:29:31 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 4 Apr 2010 08:29:31 +0000 Subject: [M3devel] interesting comment in caltech-parser m3overrides Message-ID: /* when overriding, ld.so doesn't know where to find libraries */ /* this is even more true if we want to move the binaries or */ /* clean.. */ %if defined("pm3_version") % /* Polytechnique de Montreal Modula-3 */ % option("shared_lib","") %else % /* SRC Modula-3 */ % m3_option ("-X2 at -static@") %end which is the same problem we discussed here a bunch. To which there is no good solution, just various compromises. For the next (not current) release though I think all .so and executables should build (not just ship) into a common place. So $ORIGIN works, without having to ship. They also have this interesting technique: /* these are the packages that are part of this distribution */ override("prsparse",TOP) ... % override other libraries if they exist locally (use not stale on each) m3core = ROOT & SL & "m3-libs" & SL & "m3core" if not stale(m3core, m3core) override("m3core", ROOT & SL & "m3-libs") end ... override should probably do the existance check if it doesn't already. Though the idea of building stuff to a common directory I believe obsoletes this entire override thing. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Apr 4 12:02:09 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 4 Apr 2010 10:02:09 +0000 Subject: [M3devel] initializing field with record size? Message-ID: TYPE struct_stat = RECORD type_size: LONGINT := VAL(BYTESIZE(struct_stat), LONGINT); st_dev : LONGINT; (* Utypes.dev_t *) ... END; new source -> compiling Ustat.i3 "..\src\unix\Common\Ustat.i3", line 57: illegal recursive declaration (struct_stat) "..\src\unix\Common\Ustat.i3", line 57: illegal recursive type declaration 2 errors encountered compilation failed => not building library "m3core.lib" Fatal Error: package build failed really can't be allowed? I know, I can compute it myself, or I can make it a default parameter to functions that traffic in the type. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Apr 4 12:25:08 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 4 Apr 2010 10:25:08 +0000 Subject: [M3devel] some new NT386 builds from release branch Message-ID: http://modula3.elegosoft.com/cm3/uploaded-archives/index.html Has some new NT386 builds out of the release branch. e.g. http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-all-x86-pre5.8.5-VC80.msi http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-all-x86-pre5.8.5-VC90.msi http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-x86-pre5.8.5-VC80.msi http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-x86-pre5.8.5-VC70.zip http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-x86-pre5.8.5-VC60.zip etc. It is all very automated. I can trivially update them if/when we fix more bugs. It is really no trouble to support the older versions of Visual C++. I can provide .msis or "all" for the older Visual C++ if anyone needs. There's a bug that strongly suggests we should provide separate per-toolset builds like this. (#1077 win32 install problem's jkrell sw-bug medium installation current) I've taken the liberty of assuming .msi and even .zip imply NT, thus the file names. Next step maybe is for the web page to suggest the right target download, like how http://www.mozilla.com does? (with a link to other systems, etc.) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Apr 4 15:01:35 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 4 Apr 2010 09:01:35 -0400 Subject: [M3devel] interesting comment in caltech-parser m3overrides In-Reply-To: References: Message-ID: override was used before the existence of shared libs in CM3/PM3 so not surprising. On 4 Apr 2010, at 04:29, Jay K wrote: > /* when overriding, ld.so doesn't know where to find libraries */ > /* this is even more true if we want to move the binaries or */ > /* clean.. */ > > %if defined("pm3_version") > % /* Polytechnique de Montreal Modula-3 */ > % option("shared_lib","") > %else > % /* SRC Modula-3 */ > % m3_option ("-X2 at -static@") > %end > > > which is the same problem we discussed here a bunch. > To which there is no good solution, just various compromises. > For the next (not current) release though I think all .so and executables should build (not just ship) into a common place. > So $ORIGIN works, without having to ship. > > > They also have this interesting technique: > > /* these are the packages that are part of this distribution */ > override("prsparse",TOP) > ... > > > % override other libraries if they exist locally (use not stale on each) > > m3core = ROOT & SL & "m3-libs" & SL & "m3core" > if not stale(m3core, m3core) > override("m3core", ROOT & SL & "m3-libs") > end > ... > > > override should probably do the existance check if it doesn't already. > Though the idea of building stuff to a common directory I believe obsoletes this entire override thing. > > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Apr 5 13:41:10 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 5 Apr 2010 11:41:10 +0000 Subject: [M3devel] RTMachine.PointerAlignment = 1 on NT? Message-ID: For the vast majority of platforms: RTMachine.PointerAlignment = BYTESIZE(INTEGER). except 1 for NT386, 2 for M68K (dead). PointerAlignment = BYTESIZE(INTEGER); (* The C compiler allocates all pointers on 'PointerAlignment'-byte boundaries. The garbage collector scans thread stacks, but only looks at these possible pointer locations. Setting this value smaller than is needed will only make your system run slower. Setting it too large will cause the collector to collect storage that is not free. *) I suggest this is not exactly true. 1) Of what relevance is the C compiler? vs. the Modula-3 compiler. 2) We really think the number is 1 for NT386? I understand I could say: void F(void* traced) { #pragma pack(1) struct { char a; void* p} = {0, traced}; } but 1) That seems highly unlikely. 2) Do we really anticipate the case where C code is the *only* holder of a traced reference? And more so, it wasn't a parameter to the C code -- the location of parameters is controlled by Modula-3, assuming a pointer-aligned stack. 3) Can't we know/assume/verify that Modula-3 code only stores pointers at more aligned location? My real goal is to make there only be one RTMachine for systems that don't have stack walkers. Leave SOLgnu/SOLsun alone. (Later on implement stack walking for many platforms via libunwind.) There are I believe only two differences to iron out. Allocation size (8K vs. 64K) and PointerAlignment (1 vs. BYTESIZE(INTEGER)). There is a reason for NT to be 64K allocation size -- that is what VirtualAlloc uses. I can test 64K on others. Historically smaller is probably more efficient. These days larger but not *too* large is probably more efficient. 64K should work fine on all platforms. Heck, even something larger like 1MB is probably good. I'll test out 64K. Can/should we have "paranoidgc" imply PointerAlignment = 1, and report whenever a pointer is found at a location with alignment less than BYTESIZE(pointer)? A form of this is reasonable today, right? If PointerAligment = 1, I can have it report any found at less than BYTESIZE(pointer), test it a while, if none found, elevate NT386 to that value? If any found, that'll help educate me/us on why it is 1, and maybe how to change it, or why leave it alone. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Apr 5 13:55:16 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 5 Apr 2010 11:55:16 +0000 Subject: [M3devel] RTMachine.PointerAlignment = 1 on NT? In-Reply-To: References: Message-ID: Interesting: PROCEDURE NoteStackLocations (start, stop: ADDRESS) = VAR fp : UNTRACED REF ADDRESS := start; BEGIN IF NOT (start < stop) THEN RETURN END; stop := stop - ADRSIZE (ADDRESS); (* so we don't overrun the valid addresses *) WHILE fp <= stop DO (* with the memory read on the next line. *) WITH page = AddressToPage(fp^) DO IF page # NIL AND page.desc.space = Space.Previous THEN IF RTMachine.PointerAlignment = 1 THEN IF Word.And(LOOPHOLE(fp, INTEGER), BYTESIZE(INTEGER) - 1) # 0 THEN RTIO.PutText("pointer found on unaligned stack stack="); RTIO.PutAddr(fp); RTIO.PutText(" addr="); RTIO.PutAddr(fp^); RTIO.PutText("\n"); RTIO.Flush(); END; END; IF page.desc.pure THEN PromotePage(page, PromoteReason.AmbiguousPure); ELSE PromotePage(page, PromoteReason.AmbiguousImpure); END; END; END; INC(fp, RTMachine.PointerAlignment); END; END NoteStackLocations; generates a fair amount of output: C:\dev2\cm3.2\m3-sys\mklib>cm3 --- building in NT386 --- ignoring ..\src\m3overrides pointer found on unaligned stack stack=0x12f3d2 addr=0x1400000 pointer found on unaligned stack stack=0x12f11e addr=0x1400000 pointer found on unaligned stack stack=0x12f186 addr=0x1400000 pointer found on unaligned stack stack=0x12f12e addr=0x1780000 pointer found on unaligned stack stack=0x12f1ba addr=0x1400000 pointer found on unaligned stack stack=0x12f442 addr=0x1460147 new source -> compiling Main.m3 pointer found on unaligned stack stack=0x12f3d2 addr=0x1400000 -> linking mklib.exe I need to look a bit more, see what these values are. We are probably being way over conservative, on NT. Such unaligned values as 0x1460147 surely shouldn't count as traced pointers. This example only has one but usually I see many more. C:\dev2\cm3.2\m3-sys\cm3>cm3 --- building in NT386 --- ignoring ..\src\m3overrides pointer found on unaligned stack stack=0x12f3d2 addr=0x1400000 pointer found on unaligned stack stack=0x12f642 addr=0x1400000 pointer found on unaligned stack stack=0x12f176 addr=0x1400000 pointer found on unaligned stack stack=0x12f11e addr=0x1400000 pointer found on unaligned stack stack=0x12f12a addr=0x1780000 pointer found on unaligned stack stack=0x12f1b6 addr=0x1400000 pointer found on unaligned stack stack=0x12f61e addr=0x1400000 pointer found on unaligned stack stack=0x12f6de addr=0x1900069 pointer found on unaligned stack stack=0x12f43e addr=0x1400000 pointer found on unaligned stack stack=0x12f156 addr=0x1400000 pointer found on unaligned stack stack=0x12f66e addr=0x1400000 pointer found on unaligned stack stack=0x12f72e addr=0x1900069 pointer found on unaligned stack stack=0x12f792 addr=0x1cc0000 pointer found on unaligned stack stack=0x12fb26 addr=0x1d7015c pointer found on unaligned stack stack=0x12fb52 addr=0x1d90142 All this scanning around in memory the garbage collector has to do, doesn't that kill working set? It makes all heap and stack part of the working set? Even if I'm not going to access it for long periods? - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Mon, 5 Apr 2010 11:41:10 +0000 Subject: [M3devel] RTMachine.PointerAlignment = 1 on NT? For the vast majority of platforms: RTMachine.PointerAlignment = BYTESIZE(INTEGER). except 1 for NT386, 2 for M68K (dead). PointerAlignment = BYTESIZE(INTEGER); (* The C compiler allocates all pointers on 'PointerAlignment'-byte boundaries. The garbage collector scans thread stacks, but only looks at these possible pointer locations. Setting this value smaller than is needed will only make your system run slower. Setting it too large will cause the collector to collect storage that is not free. *) I suggest this is not exactly true. 1) Of what relevance is the C compiler? vs. the Modula-3 compiler. 2) We really think the number is 1 for NT386? I understand I could say: void F(void* traced) { #pragma pack(1) struct { char a; void* p} = {0, traced}; } but 1) That seems highly unlikely. 2) Do we really anticipate the case where C code is the *only* holder of a traced reference? And more so, it wasn't a parameter to the C code -- the location of parameters is controlled by Modula-3, assuming a pointer-aligned stack. 3) Can't we know/assume/verify that Modula-3 code only stores pointers at more aligned location? My real goal is to make there only be one RTMachine for systems that don't have stack walkers. Leave SOLgnu/SOLsun alone. (Later on implement stack walking for many platforms via libunwind.) There are I believe only two differences to iron out. Allocation size (8K vs. 64K) and PointerAlignment (1 vs. BYTESIZE(INTEGER)). There is a reason for NT to be 64K allocation size -- that is what VirtualAlloc uses. I can test 64K on others. Historically smaller is probably more efficient. These days larger but not *too* large is probably more efficient. 64K should work fine on all platforms. Heck, even something larger like 1MB is probably good. I'll test out 64K. Can/should we have "paranoidgc" imply PointerAlignment = 1, and report whenever a pointer is found at a location with alignment less than BYTESIZE(pointer)? A form of this is reasonable today, right? If PointerAligment = 1, I can have it report any found at less than BYTESIZE(pointer), test it a while, if none found, elevate NT386 to that value? If any found, that'll help educate me/us on why it is 1, and maybe how to change it, or why leave it alone. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Apr 5 14:03:45 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 5 Apr 2010 12:03:45 +0000 Subject: [M3devel] RTMachine.PointerAlignment = 1 on NT? In-Reply-To: References: , Message-ID: hm I guess pointers themselves (not where they are stored) need not have any alignemnt? We might only have a pointer into an array of bytes to keep the array alive, no pointer to the base of the array? PROCEDURE F1() VAR a: ARRAY OF CHAR := NEW(CHAR, 10); i: INTEGER; BEGIN FOR i := FIRST(a) TO LAST(a) DO something with a[i]; END END F1; might only have pointers to elements in a? - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Mon, 5 Apr 2010 11:55:16 +0000 Subject: Re: [M3devel] RTMachine.PointerAlignment = 1 on NT? Interesting: PROCEDURE NoteStackLocations (start, stop: ADDRESS) = VAR fp : UNTRACED REF ADDRESS := start; BEGIN IF NOT (start < stop) THEN RETURN END; stop := stop - ADRSIZE (ADDRESS); (* so we don't overrun the valid addresses *) WHILE fp <= stop DO (* with the memory read on the next line. *) WITH page = AddressToPage(fp^) DO IF page # NIL AND page.desc.space = Space.Previous THEN IF RTMachine.PointerAlignment = 1 THEN IF Word.And(LOOPHOLE(fp, INTEGER), BYTESIZE(INTEGER) - 1) # 0 THEN RTIO.PutText("pointer found on unaligned stack stack="); RTIO.PutAddr(fp); RTIO.PutText(" addr="); RTIO.PutAddr(fp^); RTIO.PutText("\n"); RTIO.Flush(); END; END; IF page.desc.pure THEN PromotePage(page, PromoteReason.AmbiguousPure); ELSE PromotePage(page, PromoteReason.AmbiguousImpure); END; END; END; INC(fp, RTMachine.PointerAlignment); END; END NoteStackLocations; generates a fair amount of output: C:\dev2\cm3.2\m3-sys\mklib>cm3 --- building in NT386 --- ignoring ..\src\m3overrides pointer found on unaligned stack stack=0x12f3d2 addr=0x1400000 pointer found on unaligned stack stack=0x12f11e addr=0x1400000 pointer found on unaligned stack stack=0x12f186 addr=0x1400000 pointer found on unaligned stack stack=0x12f12e addr=0x1780000 pointer found on unaligned stack stack=0x12f1ba addr=0x1400000 pointer found on unaligned stack stack=0x12f442 addr=0x1460147 new source -> compiling Main.m3 pointer found on unaligned stack stack=0x12f3d2 addr=0x1400000 -> linking mklib.exe I need to look a bit more, see what these values are. We are probably being way over conservative, on NT. Such unaligned values as 0x1460147 surely shouldn't count as traced pointers. This example only has one but usually I see many more. C:\dev2\cm3.2\m3-sys\cm3>cm3 --- building in NT386 --- ignoring ..\src\m3overrides pointer found on unaligned stack stack=0x12f3d2 addr=0x1400000 pointer found on unaligned stack stack=0x12f642 addr=0x1400000 pointer found on unaligned stack stack=0x12f176 addr=0x1400000 pointer found on unaligned stack stack=0x12f11e addr=0x1400000 pointer found on unaligned stack stack=0x12f12a addr=0x1780000 pointer found on unaligned stack stack=0x12f1b6 addr=0x1400000 pointer found on unaligned stack stack=0x12f61e addr=0x1400000 pointer found on unaligned stack stack=0x12f6de addr=0x1900069 pointer found on unaligned stack stack=0x12f43e addr=0x1400000 pointer found on unaligned stack stack=0x12f156 addr=0x1400000 pointer found on unaligned stack stack=0x12f66e addr=0x1400000 pointer found on unaligned stack stack=0x12f72e addr=0x1900069 pointer found on unaligned stack stack=0x12f792 addr=0x1cc0000 pointer found on unaligned stack stack=0x12fb26 addr=0x1d7015c pointer found on unaligned stack stack=0x12fb52 addr=0x1d90142 All this scanning around in memory the garbage collector has to do, doesn't that kill working set? It makes all heap and stack part of the working set? Even if I'm not going to access it for long periods? - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Mon, 5 Apr 2010 11:41:10 +0000 Subject: [M3devel] RTMachine.PointerAlignment = 1 on NT? For the vast majority of platforms: RTMachine.PointerAlignment = BYTESIZE(INTEGER). except 1 for NT386, 2 for M68K (dead). PointerAlignment = BYTESIZE(INTEGER); (* The C compiler allocates all pointers on 'PointerAlignment'-byte boundaries. The garbage collector scans thread stacks, but only looks at these possible pointer locations. Setting this value smaller than is needed will only make your system run slower. Setting it too large will cause the collector to collect storage that is not free. *) I suggest this is not exactly true. 1) Of what relevance is the C compiler? vs. the Modula-3 compiler. 2) We really think the number is 1 for NT386? I understand I could say: void F(void* traced) { #pragma pack(1) struct { char a; void* p} = {0, traced}; } but 1) That seems highly unlikely. 2) Do we really anticipate the case where C code is the *only* holder of a traced reference? And more so, it wasn't a parameter to the C code -- the location of parameters is controlled by Modula-3, assuming a pointer-aligned stack. 3) Can't we know/assume/verify that Modula-3 code only stores pointers at more aligned location? My real goal is to make there only be one RTMachine for systems that don't have stack walkers. Leave SOLgnu/SOLsun alone. (Later on implement stack walking for many platforms via libunwind.) There are I believe only two differences to iron out. Allocation size (8K vs. 64K) and PointerAlignment (1 vs. BYTESIZE(INTEGER)). There is a reason for NT to be 64K allocation size -- that is what VirtualAlloc uses. I can test 64K on others. Historically smaller is probably more efficient. These days larger but not *too* large is probably more efficient. 64K should work fine on all platforms. Heck, even something larger like 1MB is probably good. I'll test out 64K. Can/should we have "paranoidgc" imply PointerAlignment = 1, and report whenever a pointer is found at a location with alignment less than BYTESIZE(pointer)? A form of this is reasonable today, right? If PointerAligment = 1, I can have it report any found at less than BYTESIZE(pointer), test it a while, if none found, elevate NT386 to that value? If any found, that'll help educate me/us on why it is 1, and maybe how to change it, or why leave it alone. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Apr 5 16:25:20 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 5 Apr 2010 10:25:20 -0400 Subject: [M3devel] RTMachine.PointerAlignment = 1 on NT? In-Reply-To: References: , Message-ID: <76C0DE79-7904-49B4-AE3F-83632B48CFDD@cs.purdue.edu> Yes, correct. Pointers from the stacks may be "derived" from object base references by the compiler or through use of VAR/READONLY parameters. So, the pointer values from the stack themselves need not be aligned. The PointerAlignment tells the collector at what alignment to expect to find pointers stored in the stack. Some compilers/targets may not require that pointer-valued fields in the stack be stored at aligned locations. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 5 Apr 2010, at 08:03, Jay K wrote: > hm I guess pointers themselves (not where they are stored) need not have any alignemnt? > We might only have a pointer into an array of bytes to keep the array alive, > no pointer to the base of the array? > > PROCEDURE F1() > VAR a: ARRAY OF CHAR := NEW(CHAR, 10); > i: INTEGER; > BEGIN > FOR i := FIRST(a) TO LAST(a) DO > something with a[i]; > END > END F1; > > might only have pointers to elements in a? > > - Jay > > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Mon, 5 Apr 2010 11:55:16 +0000 > Subject: Re: [M3devel] RTMachine.PointerAlignment = 1 on NT? > > Interesting: > > PROCEDURE NoteStackLocations (start, stop: ADDRESS) = > VAR fp : UNTRACED REF ADDRESS := start; > BEGIN > IF NOT (start < stop) THEN RETURN END; > stop := stop - ADRSIZE (ADDRESS); (* so we don't overrun the valid addresses *) > WHILE fp <= stop DO (* with the memory read on the next line. *) > WITH page = AddressToPage(fp^) DO > IF page # NIL AND page.desc.space = Space.Previous THEN > IF RTMachine.PointerAlignment = 1 THEN > IF Word.And(LOOPHOLE(fp, INTEGER), BYTESIZE(INTEGER) - 1) # 0 THEN > RTIO.PutText("pointer found on unaligned stack stack="); > RTIO.PutAddr(fp); > RTIO.PutText(" addr="); > RTIO.PutAddr(fp^); > RTIO.PutText("\n"); > RTIO.Flush(); > END; > END; > IF page.desc.pure > THEN PromotePage(page, PromoteReason.AmbiguousPure); > ELSE PromotePage(page, PromoteReason.AmbiguousImpure); > END; > END; > END; > INC(fp, RTMachine.PointerAlignment); > END; > END NoteStackLocations; > > > generates a fair amount of output: > > > C:\dev2\cm3.2\m3-sys\mklib>cm3 > --- building in NT386 --- > ignoring ..\src\m3overrides > pointer found on unaligned stack stack=0x12f3d2 addr=0x1400000 > pointer found on unaligned stack stack=0x12f11e addr=0x1400000 > pointer found on unaligned stack stack=0x12f186 addr=0x1400000 > pointer found on unaligned stack stack=0x12f12e addr=0x1780000 > pointer found on unaligned stack stack=0x12f1ba addr=0x1400000 > pointer found on unaligned stack stack=0x12f442 addr=0x1460147 > new source -> compiling Main.m3 > pointer found on unaligned stack stack=0x12f3d2 addr=0x1400000 > -> linking mklib.exe > > > I need to look a bit more, see what these values are. > We are probably being way over conservative, on NT. > Such unaligned values as 0x1460147 surely shouldn't count as traced pointers. > This example only has one but usually I see many more. > > > C:\dev2\cm3.2\m3-sys\cm3>cm3 > --- building in NT386 --- > ignoring ..\src\m3overrides > pointer found on unaligned stack stack=0x12f3d2 addr=0x1400000 > pointer found on unaligned stack stack=0x12f642 addr=0x1400000 > pointer found on unaligned stack stack=0x12f176 addr=0x1400000 > pointer found on unaligned stack stack=0x12f11e addr=0x1400000 > pointer found on unaligned stack stack=0x12f12a addr=0x1780000 > pointer found on unaligned stack stack=0x12f1b6 addr=0x1400000 > pointer found on unaligned stack stack=0x12f61e addr=0x1400000 > pointer found on unaligned stack stack=0x12f6de addr=0x1900069 > pointer found on unaligned stack stack=0x12f43e addr=0x1400000 > pointer found on unaligned stack stack=0x12f156 addr=0x1400000 > pointer found on unaligned stack stack=0x12f66e addr=0x1400000 > pointer found on unaligned stack stack=0x12f72e addr=0x1900069 > pointer found on unaligned stack stack=0x12f792 addr=0x1cc0000 > pointer found on unaligned stack stack=0x12fb26 addr=0x1d7015c > pointer found on unaligned stack stack=0x12fb52 addr=0x1d90142 > > > All this scanning around in memory the garbage collector has to do, doesn't that kill working set? > It makes all heap and stack part of the working set? Even if I'm not going to access it for long periods? > > > - Jay > > > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Mon, 5 Apr 2010 11:41:10 +0000 > Subject: [M3devel] RTMachine.PointerAlignment = 1 on NT? > > For the vast majority of platforms: > > > RTMachine.PointerAlignment = BYTESIZE(INTEGER). > > > except 1 for NT386, 2 for M68K (dead). > > > PointerAlignment = BYTESIZE(INTEGER); > (* The C compiler allocates all pointers on 'PointerAlignment'-byte > boundaries. The garbage collector scans thread stacks, but only > looks at these possible pointer locations. Setting this value > smaller than is needed will only make your system run slower. > Setting it too large will cause the collector to collect storage > that is not free. *) > > > I suggest this is not exactly true. > 1) Of what relevance is the C compiler? vs. the Modula-3 compiler. > 2) We really think the number is 1 for NT386? > > I understand I could say: > void F(void* traced) > { > #pragma pack(1) > struct { char a; void* p} = {0, traced}; > } > > but > 1) That seems highly unlikely. > 2) Do we really anticipate the case where C code is the *only* holder of a traced reference? > And more so, it wasn't a parameter to the C code -- the location of parameters is controlled by Modula-3, assuming a pointer-aligned stack. > 3) Can't we know/assume/verify that Modula-3 code only stores pointers at more aligned location? > > > My real goal is to make there only be one RTMachine for systems that don't have stack walkers. > Leave SOLgnu/SOLsun alone. > (Later on implement stack walking for many platforms via libunwind.) > > > There are I believe only two differences to iron out. Allocation size (8K vs. 64K) and PointerAlignment (1 vs. BYTESIZE(INTEGER)). > There is a reason for NT to be 64K allocation size -- that is what VirtualAlloc uses. > I can test 64K on others. > Historically smaller is probably more efficient. > These days larger but not *too* large is probably more efficient. > 64K should work fine on all platforms. Heck, even something larger like 1MB is probably good. > I'll test out 64K. > > > Can/should we have "paranoidgc" imply PointerAlignment = 1, and report whenever a pointer is found at a location with alignment less than BYTESIZE(pointer)? > > > A form of this is reasonable today, right? If PointerAligment = 1, I can have it report any found at less than BYTESIZE(pointer), test it a while, if none found, elevate NT386 to that value? > If any found, that'll help educate me/us on why it is 1, and maybe how to change it, or why leave it alone. > > > - Jay > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Apr 5 16:40:36 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 5 Apr 2010 14:40:36 +0000 Subject: [M3devel] RTMachine.PointerAlignment = 1 on NT? In-Reply-To: <76C0DE79-7904-49B4-AE3F-83632B48CFDD@cs.purdue.edu> References: , , <76C0DE79-7904-49B4-AE3F-83632B48CFDD@cs.purdue.edu> Message-ID: I think we can safely dispense with RTMachine.PointerAlignment and use BYTESIZE(INTEGER). NT386 is the only current exception. Even though it isn't required, of any x86 target, it seems the overwhelming practice. - Jay Subject: Re: [M3devel] RTMachine.PointerAlignment = 1 on NT? From: hosking at cs.purdue.edu Date: Mon, 5 Apr 2010 10:25:20 -0400 CC: m3devel at elegosoft.com To: jay.krell at cornell.edu Yes, correct. Pointers from the stacks may be "derived" from object base references by the compiler or through use of VAR/READONLY parameters. So, the pointer values from the stack themselves need not be aligned. The PointerAlignment tells the collector at what alignment to expect to find pointers stored in the stack. Some compilers/targets may not require that pointer-valued fields in the stack be stored at aligned locations. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 5 Apr 2010, at 08:03, Jay K wrote: hm I guess pointers themselves (not where they are stored) need not have any alignemnt? We might only have a pointer into an array of bytes to keep the array alive, no pointer to the base of the array? PROCEDURE F1() VAR a: ARRAY OF CHAR := NEW(CHAR, 10); i: INTEGER; BEGIN FOR i := FIRST(a) TO LAST(a) DO something with a[i]; END END F1; might only have pointers to elements in a? - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Mon, 5 Apr 2010 11:55:16 +0000 Subject: Re: [M3devel] RTMachine.PointerAlignment = 1 on NT? Interesting: PROCEDURE NoteStackLocations (start, stop: ADDRESS) = VAR fp : UNTRACED REF ADDRESS := start; BEGIN IF NOT (start < stop) THEN RETURN END; stop := stop - ADRSIZE (ADDRESS); (* so we don't overrun the valid addresses *) WHILE fp <= stop DO (* with the memory read on the next line. *) WITH page = AddressToPage(fp^) DO IF page # NIL AND page.desc.space = Space.Previous THEN IF RTMachine.PointerAlignment = 1 THEN IF Word.And(LOOPHOLE(fp, INTEGER), BYTESIZE(INTEGER) - 1) # 0 THEN RTIO.PutText("pointer found on unaligned stack stack="); RTIO.PutAddr(fp); RTIO.PutText(" addr="); RTIO.PutAddr(fp^); RTIO.PutText("\n"); RTIO.Flush(); END; END; IF page.desc.pure THEN PromotePage(page, PromoteReason.AmbiguousPure); ELSE PromotePage(page, PromoteReason.AmbiguousImpure); END; END; END; INC(fp, RTMachine.PointerAlignment); END; END NoteStackLocations; generates a fair amount of output: C:\dev2\cm3.2\m3-sys\mklib>cm3 --- building in NT386 --- ignoring ..\src\m3overrides pointer found on unaligned stack stack=0x12f3d2 addr=0x1400000 pointer found on unaligned stack stack=0x12f11e addr=0x1400000 pointer found on unaligned stack stack=0x12f186 addr=0x1400000 pointer found on unaligned stack stack=0x12f12e addr=0x1780000 pointer found on unaligned stack stack=0x12f1ba addr=0x1400000 pointer found on unaligned stack stack=0x12f442 addr=0x1460147 new source -> compiling Main.m3 pointer found on unaligned stack stack=0x12f3d2 addr=0x1400000 -> linking mklib.exe I need to look a bit more, see what these values are. We are probably being way over conservative, on NT. Such unaligned values as 0x1460147 surely shouldn't count as traced pointers. This example only has one but usually I see many more. C:\dev2\cm3.2\m3-sys\cm3>cm3 --- building in NT386 --- ignoring ..\src\m3overrides pointer found on unaligned stack stack=0x12f3d2 addr=0x1400000 pointer found on unaligned stack stack=0x12f642 addr=0x1400000 pointer found on unaligned stack stack=0x12f176 addr=0x1400000 pointer found on unaligned stack stack=0x12f11e addr=0x1400000 pointer found on unaligned stack stack=0x12f12a addr=0x1780000 pointer found on unaligned stack stack=0x12f1b6 addr=0x1400000 pointer found on unaligned stack stack=0x12f61e addr=0x1400000 pointer found on unaligned stack stack=0x12f6de addr=0x1900069 pointer found on unaligned stack stack=0x12f43e addr=0x1400000 pointer found on unaligned stack stack=0x12f156 addr=0x1400000 pointer found on unaligned stack stack=0x12f66e addr=0x1400000 pointer found on unaligned stack stack=0x12f72e addr=0x1900069 pointer found on unaligned stack stack=0x12f792 addr=0x1cc0000 pointer found on unaligned stack stack=0x12fb26 addr=0x1d7015c pointer found on unaligned stack stack=0x12fb52 addr=0x1d90142 All this scanning around in memory the garbage collector has to do, doesn't that kill working set? It makes all heap and stack part of the working set? Even if I'm not going to access it for long periods? - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Mon, 5 Apr 2010 11:41:10 +0000 Subject: [M3devel] RTMachine.PointerAlignment = 1 on NT? For the vast majority of platforms: RTMachine.PointerAlignment = BYTESIZE(INTEGER). except 1 for NT386, 2 for M68K (dead). PointerAlignment = BYTESIZE(INTEGER); (* The C compiler allocates all pointers on 'PointerAlignment'-byte boundaries. The garbage collector scans thread stacks, but only looks at these possible pointer locations. Setting this value smaller than is needed will only make your system run slower. Setting it too large will cause the collector to collect storage that is not free. *) I suggest this is not exactly true. 1) Of what relevance is the C compiler? vs. the Modula-3 compiler. 2) We really think the number is 1 for NT386? I understand I could say: void F(void* traced) { #pragma pack(1) struct { char a; void* p} = {0, traced}; } but 1) That seems highly unlikely. 2) Do we really anticipate the case where C code is the *only* holder of a traced reference? And more so, it wasn't a parameter to the C code -- the location of parameters is controlled by Modula-3, assuming a pointer-aligned stack. 3) Can't we know/assume/verify that Modula-3 code only stores pointers at more aligned location? My real goal is to make there only be one RTMachine for systems that don't have stack walkers. Leave SOLgnu/SOLsun alone. (Later on implement stack walking for many platforms via libunwind.) There are I believe only two differences to iron out. Allocation size (8K vs. 64K) and PointerAlignment (1 vs. BYTESIZE(INTEGER)). There is a reason for NT to be 64K allocation size -- that is what VirtualAlloc uses. I can test 64K on others. Historically smaller is probably more efficient. These days larger but not *too* large is probably more efficient. 64K should work fine on all platforms. Heck, even something larger like 1MB is probably good. I'll test out 64K. Can/should we have "paranoidgc" imply PointerAlignment = 1, and report whenever a pointer is found at a location with alignment less than BYTESIZE(pointer)? A form of this is reasonable today, right? If PointerAligment = 1, I can have it report any found at less than BYTESIZE(pointer), test it a while, if none found, elevate NT386 to that value? If any found, that'll help educate me/us on why it is 1, and maybe how to change it, or why leave it alone. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Apr 5 19:31:45 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 5 Apr 2010 13:31:45 -0400 Subject: [M3devel] RTMachine.PointerAlignment = 1 on NT? In-Reply-To: References: , , <76C0DE79-7904-49B4-AE3F-83632B48CFDD@cs.purdue.edu> Message-ID: More accurately, BYTESIZE(ADDRESS)? Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 5 Apr 2010, at 10:40, Jay K wrote: > I think we can safely dispense with RTMachine.PointerAlignment and use BYTESIZE(INTEGER). > NT386 is the only current exception. > Even though it isn't required, of any x86 target, it seems the overwhelming practice. > > - Jay > > Subject: Re: [M3devel] RTMachine.PointerAlignment = 1 on NT? > From: hosking at cs.purdue.edu > Date: Mon, 5 Apr 2010 10:25:20 -0400 > CC: m3devel at elegosoft.com > To: jay.krell at cornell.edu > > Yes, correct. Pointers from the stacks may be "derived" from object base references by the compiler or through use of VAR/READONLY parameters. So, the pointer values from the stack themselves need not be aligned. The PointerAlignment tells the collector at what alignment to expect to find pointers stored in the stack. Some compilers/targets may not require that pointer-valued fields in the stack be stored at aligned locations. > > > > Antony Hosking | Associate Professor | Computer Science | Purdue University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > On 5 Apr 2010, at 08:03, Jay K wrote: > > hm I guess pointers themselves (not where they are stored) need not have any alignemnt? > We might only have a pointer into an array of bytes to keep the array alive, > no pointer to the base of the array? > > PROCEDURE F1() > VAR a: ARRAY OF CHAR := NEW(CHAR, 10); > i: INTEGER; > BEGIN > FOR i := FIRST(a) TO LAST(a) DO > something with a[i]; > END > END F1; > > might only have pointers to elements in a? > > - Jay > > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Mon, 5 Apr 2010 11:55:16 +0000 > Subject: Re: [M3devel] RTMachine.PointerAlignment = 1 on NT? > > Interesting: > > PROCEDURE NoteStackLocations (start, stop: ADDRESS) = > VAR fp : UNTRACED REF ADDRESS := start; > BEGIN > IF NOT (start < stop) THEN RETURN END; > stop := stop - ADRSIZE (ADDRESS); (* so we don't overrun the valid addresses *) > WHILE fp <= stop DO (* with the memory read on the next line. *) > WITH page = AddressToPage(fp^) DO > IF page # NIL AND page.desc.space = Space.Previous THEN > IF RTMachine.PointerAlignment = 1 THEN > IF Word.And(LOOPHOLE(fp, INTEGER), BYTESIZE(INTEGER) - 1) # 0 THEN > RTIO.PutText("pointer found on unaligned stack stack="); > RTIO.PutAddr(fp); > RTIO.PutText(" addr="); > RTIO.PutAddr(fp^); > RTIO.PutText("\n"); > RTIO.Flush(); > END; > END; > IF page.desc.pure > THEN PromotePage(page, PromoteReason.AmbiguousPure); > ELSE PromotePage(page, PromoteReason.AmbiguousImpure); > END; > END; > END; > INC(fp, RTMachine.PointerAlignment); > END; > END NoteStackLocations; > > > generates a fair amount of output: > > > C:\dev2\cm3.2\m3-sys\mklib>cm3 > --- building in NT386 --- > ignoring ..\src\m3overrides > pointer found on unaligned stack stack=0x12f3d2 addr=0x1400000 > pointer found on unaligned stack stack=0x12f11e addr=0x1400000 > pointer found on unaligned stack stack=0x12f186 addr=0x1400000 > pointer found on unaligned stack stack=0x12f12e addr=0x1780000 > pointer found on unaligned stack stack=0x12f1ba addr=0x1400000 > pointer found on unaligned stack stack=0x12f442 addr=0x1460147 > new source -> compiling Main.m3 > pointer found on unaligned stack stack=0x12f3d2 addr=0x1400000 > -> linking mklib.exe > > > I need to look a bit more, see what these values are. > We are probably being way over conservative, on NT. > Such unaligned values as 0x1460147 surely shouldn't count as traced pointers. > This example only has one but usually I see many more. > > > C:\dev2\cm3.2\m3-sys\cm3>cm3 > --- building in NT386 --- > ignoring ..\src\m3overrides > pointer found on unaligned stack stack=0x12f3d2 addr=0x1400000 > pointer found on unaligned stack stack=0x12f642 addr=0x1400000 > pointer found on unaligned stack stack=0x12f176 addr=0x1400000 > pointer found on unaligned stack stack=0x12f11e addr=0x1400000 > pointer found on unaligned stack stack=0x12f12a addr=0x1780000 > pointer found on unaligned stack stack=0x12f1b6 addr=0x1400000 > pointer found on unaligned stack stack=0x12f61e addr=0x1400000 > pointer found on unaligned stack stack=0x12f6de addr=0x1900069 > pointer found on unaligned stack stack=0x12f43e addr=0x1400000 > pointer found on unaligned stack stack=0x12f156 addr=0x1400000 > pointer found on unaligned stack stack=0x12f66e addr=0x1400000 > pointer found on unaligned stack stack=0x12f72e addr=0x1900069 > pointer found on unaligned stack stack=0x12f792 addr=0x1cc0000 > pointer found on unaligned stack stack=0x12fb26 addr=0x1d7015c > pointer found on unaligned stack stack=0x12fb52 addr=0x1d90142 > > > All this scanning around in memory the garbage collector has to do, doesn't that kill working set? > It makes all heap and stack part of the working set? Even if I'm not going to access it for long periods? > > > - Jay > > > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Mon, 5 Apr 2010 11:41:10 +0000 > Subject: [M3devel] RTMachine.PointerAlignment = 1 on NT? > > For the vast majority of platforms: > > > RTMachine.PointerAlignment = BYTESIZE(INTEGER). > > > except 1 for NT386, 2 for M68K (dead). > > > PointerAlignment = BYTESIZE(INTEGER); > (* The C compiler allocates all pointers on 'PointerAlignment'-byte > boundaries. The garbage collector scans thread stacks, but only > looks at these possible pointer locations. Setting this value > smaller than is needed will only make your system run slower. > Setting it too large will cause the collector to collect storage > that is not free. *) > > > I suggest this is not exactly true. > 1) Of what relevance is the C compiler? vs. the Modula-3 compiler. > 2) We really think the number is 1 for NT386? > > I understand I could say: > void F(void* traced) > { > #pragma pack(1) > struct { char a; void* p} = {0, traced}; > } > > but > 1) That seems highly unlikely. > 2) Do we really anticipate the case where C code is the *only* holder of a traced reference? > And more so, it wasn't a parameter to the C code -- the location of parameters is controlled by Modula-3, assuming a pointer-aligned stack. > 3) Can't we know/assume/verify that Modula-3 code only stores pointers at more aligned location? > > > My real goal is to make there only be one RTMachine for systems that don't have stack walkers. > Leave SOLgnu/SOLsun alone. > (Later on implement stack walking for many platforms via libunwind.) > > > There are I believe only two differences to iron out. Allocation size (8K vs. 64K) and PointerAlignment (1 vs. BYTESIZE(INTEGER)). > There is a reason for NT to be 64K allocation size -- that is what VirtualAlloc uses. > I can test 64K on others. > Historically smaller is probably more efficient. > These days larger but not *too* large is probably more efficient. > 64K should work fine on all platforms. Heck, even something larger like 1MB is probably good. > I'll test out 64K. > > > Can/should we have "paranoidgc" imply PointerAlignment = 1, and report whenever a pointer is found at a location with alignment less than BYTESIZE(pointer)? > > > A form of this is reasonable today, right? If PointerAligment = 1, I can have it report any found at less than BYTESIZE(pointer), test it a while, if none found, elevate NT386 to that value? > If any found, that'll help educate me/us on why it is 1, and maybe how to change it, or why leave it alone. > > > - Jay > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Apr 6 00:03:25 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 5 Apr 2010 22:03:25 +0000 Subject: [M3devel] RTMachine.PointerAlignment = 1 on NT? In-Reply-To: References: , , , , , <76C0DE79-7904-49B4-AE3F-83632B48CFDD@cs.purdue.edu>, , Message-ID: Yes. Same thing. - Jay From: hosking at cs.purdue.edu Date: Mon, 5 Apr 2010 13:31:45 -0400 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] RTMachine.PointerAlignment = 1 on NT? More accurately, BYTESIZE(ADDRESS)? Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 5 Apr 2010, at 10:40, Jay K wrote: I think we can safely dispense with RTMachine.PointerAlignment and use BYTESIZE(INTEGER). NT386 is the only current exception. Even though it isn't required, of any x86 target, it seems the overwhelming practice. - Jay Subject: Re: [M3devel] RTMachine.PointerAlignment = 1 on NT? From: hosking at cs.purdue.edu Date: Mon, 5 Apr 2010 10:25:20 -0400 CC: m3devel at elegosoft.com To: jay.krell at cornell.edu Yes, correct. Pointers from the stacks may be "derived" from object base references by the compiler or through use of VAR/READONLY parameters. So, the pointer values from the stack themselves need not be aligned. The PointerAlignment tells the collector at what alignment to expect to find pointers stored in the stack. Some compilers/targets may not require that pointer-valued fields in the stack be stored at aligned locations. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 5 Apr 2010, at 08:03, Jay K wrote: hm I guess pointers themselves (not where they are stored) need not have any alignemnt? We might only have a pointer into an array of bytes to keep the array alive, no pointer to the base of the array? PROCEDURE F1() VAR a: ARRAY OF CHAR := NEW(CHAR, 10); i: INTEGER; BEGIN FOR i := FIRST(a) TO LAST(a) DO something with a[i]; END END F1; might only have pointers to elements in a? - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Mon, 5 Apr 2010 11:55:16 +0000 Subject: Re: [M3devel] RTMachine.PointerAlignment = 1 on NT? Interesting: PROCEDURE NoteStackLocations (start, stop: ADDRESS) = VAR fp : UNTRACED REF ADDRESS := start; BEGIN IF NOT (start < stop) THEN RETURN END; stop := stop - ADRSIZE (ADDRESS); (* so we don't overrun the valid addresses *) WHILE fp <= stop DO (* with the memory read on the next line. *) WITH page = AddressToPage(fp^) DO IF page # NIL AND page.desc.space = Space.Previous THEN IF RTMachine.PointerAlignment = 1 THEN IF Word.And(LOOPHOLE(fp, INTEGER), BYTESIZE(INTEGER) - 1) # 0 THEN RTIO.PutText("pointer found on unaligned stack stack="); RTIO.PutAddr(fp); RTIO.PutText(" addr="); RTIO.PutAddr(fp^); RTIO.PutText("\n"); RTIO.Flush(); END; END; IF page.desc.pure THEN PromotePage(page, PromoteReason.AmbiguousPure); ELSE PromotePage(page, PromoteReason.AmbiguousImpure); END; END; END; INC(fp, RTMachine.PointerAlignment); END; END NoteStackLocations; generates a fair amount of output: C:\dev2\cm3.2\m3-sys\mklib>cm3 --- building in NT386 --- ignoring ..\src\m3overrides pointer found on unaligned stack stack=0x12f3d2 addr=0x1400000 pointer found on unaligned stack stack=0x12f11e addr=0x1400000 pointer found on unaligned stack stack=0x12f186 addr=0x1400000 pointer found on unaligned stack stack=0x12f12e addr=0x1780000 pointer found on unaligned stack stack=0x12f1ba addr=0x1400000 pointer found on unaligned stack stack=0x12f442 addr=0x1460147 new source -> compiling Main.m3 pointer found on unaligned stack stack=0x12f3d2 addr=0x1400000 -> linking mklib.exe I need to look a bit more, see what these values are. We are probably being way over conservative, on NT. Such unaligned values as 0x1460147 surely shouldn't count as traced pointers. This example only has one but usually I see many more. C:\dev2\cm3.2\m3-sys\cm3>cm3 --- building in NT386 --- ignoring ..\src\m3overrides pointer found on unaligned stack stack=0x12f3d2 addr=0x1400000 pointer found on unaligned stack stack=0x12f642 addr=0x1400000 pointer found on unaligned stack stack=0x12f176 addr=0x1400000 pointer found on unaligned stack stack=0x12f11e addr=0x1400000 pointer found on unaligned stack stack=0x12f12a addr=0x1780000 pointer found on unaligned stack stack=0x12f1b6 addr=0x1400000 pointer found on unaligned stack stack=0x12f61e addr=0x1400000 pointer found on unaligned stack stack=0x12f6de addr=0x1900069 pointer found on unaligned stack stack=0x12f43e addr=0x1400000 pointer found on unaligned stack stack=0x12f156 addr=0x1400000 pointer found on unaligned stack stack=0x12f66e addr=0x1400000 pointer found on unaligned stack stack=0x12f72e addr=0x1900069 pointer found on unaligned stack stack=0x12f792 addr=0x1cc0000 pointer found on unaligned stack stack=0x12fb26 addr=0x1d7015c pointer found on unaligned stack stack=0x12fb52 addr=0x1d90142 All this scanning around in memory the garbage collector has to do, doesn't that kill working set? It makes all heap and stack part of the working set? Even if I'm not going to access it for long periods? - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Mon, 5 Apr 2010 11:41:10 +0000 Subject: [M3devel] RTMachine.PointerAlignment = 1 on NT? For the vast majority of platforms: RTMachine.PointerAlignment = BYTESIZE(INTEGER). except 1 for NT386, 2 for M68K (dead). PointerAlignment = BYTESIZE(INTEGER); (* The C compiler allocates all pointers on 'PointerAlignment'-byte boundaries. The garbage collector scans thread stacks, but only looks at these possible pointer locations. Setting this value smaller than is needed will only make your system run slower. Setting it too large will cause the collector to collect storage that is not free. *) I suggest this is not exactly true. 1) Of what relevance is the C compiler? vs. the Modula-3 compiler. 2) We really think the number is 1 for NT386? I understand I could say: void F(void* traced) { #pragma pack(1) struct { char a; void* p} = {0, traced}; } but 1) That seems highly unlikely. 2) Do we really anticipate the case where C code is the *only* holder of a traced reference? And more so, it wasn't a parameter to the C code -- the location of parameters is controlled by Modula-3, assuming a pointer-aligned stack. 3) Can't we know/assume/verify that Modula-3 code only stores pointers at more aligned location? My real goal is to make there only be one RTMachine for systems that don't have stack walkers. Leave SOLgnu/SOLsun alone. (Later on implement stack walking for many platforms via libunwind.) There are I believe only two differences to iron out. Allocation size (8K vs. 64K) and PointerAlignment (1 vs. BYTESIZE(INTEGER)). There is a reason for NT to be 64K allocation size -- that is what VirtualAlloc uses. I can test 64K on others. Historically smaller is probably more efficient. These days larger but not *too* large is probably more efficient. 64K should work fine on all platforms. Heck, even something larger like 1MB is probably good. I'll test out 64K. Can/should we have "paranoidgc" imply PointerAlignment = 1, and report whenever a pointer is found at a location with alignment less than BYTESIZE(pointer)? A form of this is reasonable today, right? If PointerAligment = 1, I can have it report any found at less than BYTESIZE(pointer), test it a while, if none found, elevate NT386 to that value? If any found, that'll help educate me/us on why it is 1, and maybe how to change it, or why leave it alone. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Tue Apr 6 01:35:32 2010 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Tue, 06 Apr 2010 01:35:32 +0200 Subject: [M3devel] lock performance, random thoughts Message-ID: <1270510533.10280.32.camel@faramir.m3w.org> I've been thinking few days about this lock performance thing. As POSIX mutexes are getting us too many times into kernel space by way of syscalls, maybe we can get some performance back while not loosing scheduling efficiency and multi-processor side of kernel-space/POSIX threading? User-space threads were two things. One - user-space threads. Two - user-space synchronizing. If we implement former inCritical by using lockfree abilities of modern multi-processor/multi-core/cluster systems and then revert to user-space synchronizing _only_ we can have best of both worlds. We need user-space threads because we need to have our Modula-3 process spread it's threads over whatever we run it on. And we will be very happy to have synchronizing efficency back. Few details to decide how to implement would be preempting/wakeup cycle, and waiting loop on our inCritical flag. Both can be solved by POSIX primitives. What do you think about this? dd -- Dragi?a Duri? From hosking at cs.purdue.edu Tue Apr 6 01:44:02 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 5 Apr 2010 19:44:02 -0400 Subject: [M3devel] RTMachine.PointerAlignment = 1 on NT? In-Reply-To: References: , , , , , <76C0DE79-7904-49B4-AE3F-83632B48CFDD@cs.purdue.edu>, , Message-ID: Same thing only for implementations where BYTESIZE(Word.T) = BYTESIZE(INTEGER) = BYTESIZE(ADDRESS). But that's all of ours. On 5 Apr 2010, at 18:03, Jay K wrote: > Yes. Same thing. > > - Jay > > From: hosking at cs.purdue.edu > Date: Mon, 5 Apr 2010 13:31:45 -0400 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] RTMachine.PointerAlignment = 1 on NT? > > More accurately, BYTESIZE(ADDRESS)? > > Antony Hosking | Associate Professor | Computer Science | Purdue University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > On 5 Apr 2010, at 10:40, Jay K wrote: > > I think we can safely dispense with RTMachine.PointerAlignment and use BYTESIZE(INTEGER). > NT386 is the only current exception. > Even though it isn't required, of any x86 target, it seems the overwhelming practice. > > - Jay > > Subject: Re: [M3devel] RTMachine.PointerAlignment = 1 on NT? > From: hosking at cs.purdue.edu > Date: Mon, 5 Apr 2010 10:25:20 -0400 > CC: m3devel at elegosoft.com > To: jay.krell at cornell.edu > > Yes, correct. Pointers from the stacks may be "derived" from object base references by the compiler or through use of VAR/READONLY parameters. So, the pointer values from the stack themselves need not be aligned. The PointerAlignment tells the collector at what alignment to expect to find pointers stored in the stack. Some compilers/targets may not require that pointer-valued fields in the stack be stored at aligned locations. > > > > Antony Hosking | Associate Professor | Computer Science | Purdue University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > On 5 Apr 2010, at 08:03, Jay K wrote: > > hm I guess pointers themselves (not where they are stored) need not have any alignemnt? > We might only have a pointer into an array of bytes to keep the array alive, > no pointer to the base of the array? > > PROCEDURE F1() > VAR a: ARRAY OF CHAR := NEW(CHAR, 10); > i: INTEGER; > BEGIN > FOR i := FIRST(a) TO LAST(a) DO > something with a[i]; > END > END F1; > > might only have pointers to elements in a? > > - Jay > > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Mon, 5 Apr 2010 11:55:16 +0000 > Subject: Re: [M3devel] RTMachine.PointerAlignment = 1 on NT? > > Interesting: > > PROCEDURE NoteStackLocations (start, stop: ADDRESS) = > VAR fp : UNTRACED REF ADDRESS := start; > BEGIN > IF NOT (start < stop) THEN RETURN END; > stop := stop - ADRSIZE (ADDRESS); (* so we don't overrun the valid addresses *) > WHILE fp <= stop DO (* with the memory read on the next line. *) > WITH page = AddressToPage(fp^) DO > IF page # NIL AND page.desc.space = Space.Previous THEN > IF RTMachine.PointerAlignment = 1 THEN > IF Word.And(LOOPHOLE(fp, INTEGER), BYTESIZE(INTEGER) - 1) # 0 THEN > RTIO.PutText("pointer found on unaligned stack stack="); > RTIO.PutAddr(fp); > RTIO.PutText(" addr="); > RTIO.PutAddr(fp^); > RTIO.PutText("\n"); > RTIO.Flush(); > END; > END; > IF page.desc.pure > THEN PromotePage(page, PromoteReason.AmbiguousPure); > ELSE PromotePage(page, PromoteReason.AmbiguousImpure); > END; > END; > END; > INC(fp, RTMachine.PointerAlignment); > END; > END NoteStackLocations; > > > generates a fair amount of output: > > > C:\dev2\cm3.2\m3-sys\mklib>cm3 > --- building in NT386 --- > ignoring ..\src\m3overrides > pointer found on unaligned stack stack=0x12f3d2 addr=0x1400000 > pointer found on unaligned stack stack=0x12f11e addr=0x1400000 > pointer found on unaligned stack stack=0x12f186 addr=0x1400000 > pointer found on unaligned stack stack=0x12f12e addr=0x1780000 > pointer found on unaligned stack stack=0x12f1ba addr=0x1400000 > pointer found on unaligned stack stack=0x12f442 addr=0x1460147 > new source -> compiling Main.m3 > pointer found on unaligned stack stack=0x12f3d2 addr=0x1400000 > -> linking mklib.exe > > > I need to look a bit more, see what these values are. > We are probably being way over conservative, on NT. > Such unaligned values as 0x1460147 surely shouldn't count as traced pointers. > This example only has one but usually I see many more. > > > C:\dev2\cm3.2\m3-sys\cm3>cm3 > --- building in NT386 --- > ignoring ..\src\m3overrides > pointer found on unaligned stack stack=0x12f3d2 addr=0x1400000 > pointer found on unaligned stack stack=0x12f642 addr=0x1400000 > pointer found on unaligned stack stack=0x12f176 addr=0x1400000 > pointer found on unaligned stack stack=0x12f11e addr=0x1400000 > pointer found on unaligned stack stack=0x12f12a addr=0x1780000 > pointer found on unaligned stack stack=0x12f1b6 addr=0x1400000 > pointer found on unaligned stack stack=0x12f61e addr=0x1400000 > pointer found on unaligned stack stack=0x12f6de addr=0x1900069 > pointer found on unaligned stack stack=0x12f43e addr=0x1400000 > pointer found on unaligned stack stack=0x12f156 addr=0x1400000 > pointer found on unaligned stack stack=0x12f66e addr=0x1400000 > pointer found on unaligned stack stack=0x12f72e addr=0x1900069 > pointer found on unaligned stack stack=0x12f792 addr=0x1cc0000 > pointer found on unaligned stack stack=0x12fb26 addr=0x1d7015c > pointer found on unaligned stack stack=0x12fb52 addr=0x1d90142 > > > All this scanning around in memory the garbage collector has to do, doesn't that kill working set? > It makes all heap and stack part of the working set? Even if I'm not going to access it for long periods? > > > - Jay > > > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Mon, 5 Apr 2010 11:41:10 +0000 > Subject: [M3devel] RTMachine.PointerAlignment = 1 on NT? > > For the vast majority of platforms: > > > RTMachine.PointerAlignment = BYTESIZE(INTEGER). > > > except 1 for NT386, 2 for M68K (dead). > > > PointerAlignment = BYTESIZE(INTEGER); > (* The C compiler allocates all pointers on 'PointerAlignment'-byte > boundaries. The garbage collector scans thread stacks, but only > looks at these possible pointer locations. Setting this value > smaller than is needed will only make your system run slower. > Setting it too large will cause the collector to collect storage > that is not free. *) > > > I suggest this is not exactly true. > 1) Of what relevance is the C compiler? vs. the Modula-3 compiler. > 2) We really think the number is 1 for NT386? > > I understand I could say: > void F(void* traced) > { > #pragma pack(1) > struct { char a; void* p} = {0, traced}; > } > > but > 1) That seems highly unlikely. > 2) Do we really anticipate the case where C code is the *only* holder of a traced reference? > And more so, it wasn't a parameter to the C code -- the location of parameters is controlled by Modula-3, assuming a pointer-aligned stack. > 3) Can't we know/assume/verify that Modula-3 code only stores pointers at more aligned location? > > > My real goal is to make there only be one RTMachine for systems that don't have stack walkers. > Leave SOLgnu/SOLsun alone. > (Later on implement stack walking for many platforms via libunwind.) > > > There are I believe only two differences to iron out. Allocation size (8K vs. 64K) and PointerAlignment (1 vs. BYTESIZE(INTEGER)). > There is a reason for NT to be 64K allocation size -- that is what VirtualAlloc uses. > I can test 64K on others. > Historically smaller is probably more efficient. > These days larger but not *too* large is probably more efficient. > 64K should work fine on all platforms. Heck, even something larger like 1MB is probably good. > I'll test out 64K. > > > Can/should we have "paranoidgc" imply PointerAlignment = 1, and report whenever a pointer is found at a location with alignment less than BYTESIZE(pointer)? > > > A form of this is reasonable today, right? If PointerAligment = 1, I can have it report any found at less than BYTESIZE(pointer), test it a while, if none found, elevate NT386 to that value? > If any found, that'll help educate me/us on why it is 1, and maybe how to change it, or why leave it alone. > > > - Jay > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Apr 6 01:45:20 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 5 Apr 2010 19:45:20 -0400 Subject: [M3devel] lock performance, random thoughts In-Reply-To: <1270510533.10280.32.camel@faramir.m3w.org> References: <1270510533.10280.32.camel@faramir.m3w.org> Message-ID: <1F5A794A-40AB-4F94-B11A-9218DAA30ED4@cs.purdue.edu> Yes, that's pretty much what modern Java implementations do. On 5 Apr 2010, at 19:35, Dragi?a Duri? wrote: > I've been thinking few days about this lock performance thing. As POSIX > mutexes are getting us too many times into kernel space by way of > syscalls, maybe we can get some performance back while not loosing > scheduling efficiency and multi-processor side of kernel-space/POSIX > threading? > > User-space threads were two things. One - user-space threads. Two - > user-space synchronizing. If we implement former inCritical by using > lockfree abilities of modern multi-processor/multi-core/cluster systems > and then revert to user-space synchronizing _only_ we can have best of > both worlds. > > We need user-space threads because we need to have our Modula-3 process > spread it's threads over whatever we run it on. And we will be very > happy to have synchronizing efficency back. > > Few details to decide how to implement would be preempting/wakeup cycle, > and waiting loop on our inCritical flag. Both can be solved by POSIX > primitives. > > What do you think about this? > > dd > > -- > Dragi?a Duri? From dragisha at m3w.org Tue Apr 6 01:57:07 2010 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Tue, 06 Apr 2010 01:57:07 +0200 Subject: [M3devel] lock performance, random thoughts In-Reply-To: <1F5A794A-40AB-4F94-B11A-9218DAA30ED4@cs.purdue.edu> References: <1270510533.10280.32.camel@faramir.m3w.org> <1F5A794A-40AB-4F94-B11A-9218DAA30ED4@cs.purdue.edu> Message-ID: <1270511827.10280.37.camel@faramir.m3w.org> I've used Java for one project, "GUI" app frontend for mobile phones... What I saw first was their mixup of mutex/condition/cheese in single root object... But, ok... offtopic there :) What I think is important about whole idea is it's simplicity and (almost) obvious efficiency. It also needs nothing fancy (not today, at least) and nothing maybe-it-works to implement. Nothing comparable to early implementations of kernel space threading/thread suspending for gc/... Any takers? :) On Mon, 2010-04-05 at 19:45 -0400, Tony Hosking wrote: > Yes, that's pretty much what modern Java implementations do. > > -- Dragi?a Duri? From jay.krell at cornell.edu Tue Apr 6 02:13:07 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 6 Apr 2010 00:13:07 +0000 Subject: [M3devel] lock performance, random thoughts In-Reply-To: <1270511827.10280.37.camel@faramir.m3w.org> References: <1270510533.10280.32.camel@faramir.m3w.org>, <1F5A794A-40AB-4F94-B11A-9218DAA30ED4@cs.purdue.edu>, <1270511827.10280.37.camel@faramir.m3w.org> Message-ID: pthread_mutex_lock/unlock does not imply a kernel call. ! pthreads can synchronize in usermode just as well (or only almost as well?) as Tony's design. Only upon contention is a kernel call needed, in both. That's not to say that everyone implements this well. Linux does. Win32 does. The others I don't know. Also Tony avoids even atomic operations often. I'm not sure how others compare there. I'm just referring to kernel/syscalls. Are they really so terrible? - Jay > From: dragisha at m3w.org > To: hosking at cs.purdue.edu > Date: Tue, 6 Apr 2010 01:57:07 +0200 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] lock performance, random thoughts > > I've used Java for one project, "GUI" app frontend for mobile phones... > What I saw first was their mixup of mutex/condition/cheese in single > root object... But, ok... offtopic there :) > > What I think is important about whole idea is it's simplicity and > (almost) obvious efficiency. It also needs nothing fancy (not today, at > least) and nothing maybe-it-works to implement. Nothing comparable to > early implementations of kernel space threading/thread suspending for > gc/... > > Any takers? :) > > > On Mon, 2010-04-05 at 19:45 -0400, Tony Hosking wrote: > > Yes, that's pretty much what modern Java implementations do. > > > > > -- > Dragi?a Duri? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Apr 6 02:20:18 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 6 Apr 2010 00:20:18 +0000 Subject: [M3devel] RTMachine.PointerAlignment = 1 on NT? In-Reply-To: References: , , , , , , , , <76C0DE79-7904-49B4-AE3F-83632B48CFDD@cs.purdue.edu>, , , , , , Message-ID: Isn't this kind of "architectural"? Like, assumed in a bunch of code, too hard to change, better to adhere to than change? Can continue to write code assuming it. Consider AMD64_NT. I assume INTEGER there should be 64bits, even though int and long are both 32. Corralary: long shouldn't be used for anything, ever. int is 32 bits, always; ignoring old systems INTEGER is pointer size, always (the question here) long is sometimes 32 bits, sometimes pointer size, but neither is always true, on modern systems If you consider Win64. If you ignore Win64, then, yes, I realize, long is always a pointer. The types to use in C for pointer sized integers are size_t and ptrdiff_t. For that matter..BYTESIZE and ADRSIZE, they are always the same and will always be, right? "All machines are byte-addressable", these days and forever more? - Jay From: hosking at cs.purdue.edu Date: Mon, 5 Apr 2010 19:44:02 -0400 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] RTMachine.PointerAlignment = 1 on NT? Same thing only for implementations where BYTESIZE(Word.T) = BYTESIZE(INTEGER) = BYTESIZE(ADDRESS). But that's all of ours. On 5 Apr 2010, at 18:03, Jay K wrote: Yes. Same thing. - Jay From: hosking at cs.purdue.edu Date: Mon, 5 Apr 2010 13:31:45 -0400 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] RTMachine.PointerAlignment = 1 on NT? More accurately, BYTESIZE(ADDRESS)? Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 5 Apr 2010, at 10:40, Jay K wrote: I think we can safely dispense with RTMachine.PointerAlignment and use BYTESIZE(INTEGER). NT386 is the only current exception. Even though it isn't required, of any x86 target, it seems the overwhelming practice. - Jay Subject: Re: [M3devel] RTMachine.PointerAlignment = 1 on NT? From: hosking at cs.purdue.edu Date: Mon, 5 Apr 2010 10:25:20 -0400 CC: m3devel at elegosoft.com To: jay.krell at cornell.edu Yes, correct. Pointers from the stacks may be "derived" from object base references by the compiler or through use of VAR/READONLY parameters. So, the pointer values from the stack themselves need not be aligned. The PointerAlignment tells the collector at what alignment to expect to find pointers stored in the stack. Some compilers/targets may not require that pointer-valued fields in the stack be stored at aligned locations. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 5 Apr 2010, at 08:03, Jay K wrote: hm I guess pointers themselves (not where they are stored) need not have any alignemnt? We might only have a pointer into an array of bytes to keep the array alive, no pointer to the base of the array? PROCEDURE F1() VAR a: ARRAY OF CHAR := NEW(CHAR, 10); i: INTEGER; BEGIN FOR i := FIRST(a) TO LAST(a) DO something with a[i]; END END F1; might only have pointers to elements in a? - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Mon, 5 Apr 2010 11:55:16 +0000 Subject: Re: [M3devel] RTMachine.PointerAlignment = 1 on NT? Interesting: PROCEDURE NoteStackLocations (start, stop: ADDRESS) = VAR fp : UNTRACED REF ADDRESS := start; BEGIN IF NOT (start < stop) THEN RETURN END; stop := stop - ADRSIZE (ADDRESS); (* so we don't overrun the valid addresses *) WHILE fp <= stop DO (* with the memory read on the next line. *) WITH page = AddressToPage(fp^) DO IF page # NIL AND page.desc.space = Space.Previous THEN IF RTMachine.PointerAlignment = 1 THEN IF Word.And(LOOPHOLE(fp, INTEGER), BYTESIZE(INTEGER) - 1) # 0 THEN RTIO.PutText("pointer found on unaligned stack stack="); RTIO.PutAddr(fp); RTIO.PutText(" addr="); RTIO.PutAddr(fp^); RTIO.PutText("\n"); RTIO.Flush(); END; END; IF page.desc.pure THEN PromotePage(page, PromoteReason.AmbiguousPure); ELSE PromotePage(page, PromoteReason.AmbiguousImpure); END; END; END; INC(fp, RTMachine.PointerAlignment); END; END NoteStackLocations; generates a fair amount of output: C:\dev2\cm3.2\m3-sys\mklib>cm3 --- building in NT386 --- ignoring ..\src\m3overrides pointer found on unaligned stack stack=0x12f3d2 addr=0x1400000 pointer found on unaligned stack stack=0x12f11e addr=0x1400000 pointer found on unaligned stack stack=0x12f186 addr=0x1400000 pointer found on unaligned stack stack=0x12f12e addr=0x1780000 pointer found on unaligned stack stack=0x12f1ba addr=0x1400000 pointer found on unaligned stack stack=0x12f442 addr=0x1460147 new source -> compiling Main.m3 pointer found on unaligned stack stack=0x12f3d2 addr=0x1400000 -> linking mklib.exe I need to look a bit more, see what these values are. We are probably being way over conservative, on NT. Such unaligned values as 0x1460147 surely shouldn't count as traced pointers. This example only has one but usually I see many more. C:\dev2\cm3.2\m3-sys\cm3>cm3 --- building in NT386 --- ignoring ..\src\m3overrides pointer found on unaligned stack stack=0x12f3d2 addr=0x1400000 pointer found on unaligned stack stack=0x12f642 addr=0x1400000 pointer found on unaligned stack stack=0x12f176 addr=0x1400000 pointer found on unaligned stack stack=0x12f11e addr=0x1400000 pointer found on unaligned stack stack=0x12f12a addr=0x1780000 pointer found on unaligned stack stack=0x12f1b6 addr=0x1400000 pointer found on unaligned stack stack=0x12f61e addr=0x1400000 pointer found on unaligned stack stack=0x12f6de addr=0x1900069 pointer found on unaligned stack stack=0x12f43e addr=0x1400000 pointer found on unaligned stack stack=0x12f156 addr=0x1400000 pointer found on unaligned stack stack=0x12f66e addr=0x1400000 pointer found on unaligned stack stack=0x12f72e addr=0x1900069 pointer found on unaligned stack stack=0x12f792 addr=0x1cc0000 pointer found on unaligned stack stack=0x12fb26 addr=0x1d7015c pointer found on unaligned stack stack=0x12fb52 addr=0x1d90142 All this scanning around in memory the garbage collector has to do, doesn't that kill working set? It makes all heap and stack part of the working set? Even if I'm not going to access it for long periods? - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Mon, 5 Apr 2010 11:41:10 +0000 Subject: [M3devel] RTMachine.PointerAlignment = 1 on NT? For the vast majority of platforms: RTMachine.PointerAlignment = BYTESIZE(INTEGER). except 1 for NT386, 2 for M68K (dead). PointerAlignment = BYTESIZE(INTEGER); (* The C compiler allocates all pointers on 'PointerAlignment'-byte boundaries. The garbage collector scans thread stacks, but only looks at these possible pointer locations. Setting this value smaller than is needed will only make your system run slower. Setting it too large will cause the collector to collect storage that is not free. *) I suggest this is not exactly true. 1) Of what relevance is the C compiler? vs. the Modula-3 compiler. 2) We really think the number is 1 for NT386? I understand I could say: void F(void* traced) { #pragma pack(1) struct { char a; void* p} = {0, traced}; } but 1) That seems highly unlikely. 2) Do we really anticipate the case where C code is the *only* holder of a traced reference? And more so, it wasn't a parameter to the C code -- the location of parameters is controlled by Modula-3, assuming a pointer-aligned stack. 3) Can't we know/assume/verify that Modula-3 code only stores pointers at more aligned location? My real goal is to make there only be one RTMachine for systems that don't have stack walkers. Leave SOLgnu/SOLsun alone. (Later on implement stack walking for many platforms via libunwind.) There are I believe only two differences to iron out. Allocation size (8K vs. 64K) and PointerAlignment (1 vs. BYTESIZE(INTEGER)). There is a reason for NT to be 64K allocation size -- that is what VirtualAlloc uses. I can test 64K on others. Historically smaller is probably more efficient. These days larger but not *too* large is probably more efficient. 64K should work fine on all platforms. Heck, even something larger like 1MB is probably good. I'll test out 64K. Can/should we have "paranoidgc" imply PointerAlignment = 1, and report whenever a pointer is found at a location with alignment less than BYTESIZE(pointer)? A form of this is reasonable today, right? If PointerAligment = 1, I can have it report any found at less than BYTESIZE(pointer), test it a while, if none found, elevate NT386 to that value? If any found, that'll help educate me/us on why it is 1, and maybe how to change it, or why leave it alone. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Apr 6 02:38:19 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 6 Apr 2010 00:38:19 +0000 Subject: [M3devel] lock performance, random thoughts In-Reply-To: References: <1270510533.10280.32.camel@faramir.m3w.org>, , <1F5A794A-40AB-4F94-B11A-9218DAA30ED4@cs.purdue.edu>, , <1270511827.10280.37.camel@faramir.m3w.org>, Message-ID: > pthread_mutex_lock/unlock does not imply a kernel call. ! > pthreads can synchronize in usermode just as well (or only almost as well?) as Tony's design. > Only upon contention is a kernel call needed, in both. Without the extra biasing and avoiding atomic ops, I believe it goes something like: typedef struct recursive_exclusive_lock_t { long owner; long count = -1; /* -1 for 386 compat, else 0 is ok and adjust below */ void* kernel object; /* may or may not initialize this up front or on demand, if on demand, beware low resources in the middle of locking */ } recursive_exclusive_lock_t; recursive_exclusive_lock: while (1) new_count = InterlockedIncrement(count); if new_count == 0 /* 1 for 486+, allows for zero initialization */ owner = current thread return if new_count > 0 /* 1 for 486+, allows for zero initialization */ if owner == current thread id return InterlockedDecrement(count); maybe an extra brief spin here on MP systems, in case contention is very short wait on kernel object recursive_exclusive_unlock: assert(owner == current thread id) InterlockedDecrement(count); typedef struct exclusive_lock_t { long owner; void* kernel object; } exclusive_lock_t; exclusive_lock: while (1) if interlocked compare exchange(owner, 0, current thread id) == 0 return maybe an extra brief spin here on MP systems, in case contention is very short wait on kernel object exclusive_unlock: assert(owner == current thread id) owner = 0 The first resembles Win32 critical sections. The second is what the Sun Java VM does on Win32. kernel_lock is a Win32 event. I had that in Modula-3 but only briefly. No kernel call in uncontended cases. But still atomics. - Jay From: jay.krell at cornell.edu To: dragisha at m3w.org; hosking at cs.purdue.edu Date: Tue, 6 Apr 2010 00:13:07 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] lock performance, random thoughts pthread_mutex_lock/unlock does not imply a kernel call. ! pthreads can synchronize in usermode just as well (or only almost as well?) as Tony's design. Only upon contention is a kernel call needed, in both. That's not to say that everyone implements this well. Linux does. Win32 does. The others I don't know. Also Tony avoids even atomic operations often. I'm not sure how others compare there. I'm just referring to kernel/syscalls. Are they really so terrible? - Jay > From: dragisha at m3w.org > To: hosking at cs.purdue.edu > Date: Tue, 6 Apr 2010 01:57:07 +0200 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] lock performance, random thoughts > > I've used Java for one project, "GUI" app frontend for mobile phones... > What I saw first was their mixup of mutex/condition/cheese in single > root object... But, ok... offtopic there :) > > What I think is important about whole idea is it's simplicity and > (almost) obvious efficiency. It also needs nothing fancy (not today, at > least) and nothing maybe-it-works to implement. Nothing comparable to > early implementations of kernel space threading/thread suspending for > gc/... > > Any takers? :) > > > On Mon, 2010-04-05 at 19:45 -0400, Tony Hosking wrote: > > Yes, that's pretty much what modern Java implementations do. > > > > > -- > Dragi?a Duri? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Apr 6 03:21:03 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 5 Apr 2010 21:21:03 -0400 Subject: [M3devel] RTMachine.PointerAlignment = 1 on NT? In-Reply-To: References: , , , , , , , , <76C0DE79-7904-49B4-AE3F-83632B48CFDD@cs.purdue.edu>, , , , , , Message-ID: <141A7DFE-839D-4DD6-B8B4-934476DAE9A6@cs.purdue.edu> Fair enough. That says it should be ADRSIZE(ADDRESS). ;-) On 5 Apr 2010, at 20:20, Jay K wrote: > Isn't this kind of "architectural"? > Like, assumed in a bunch of code, too hard to change, better to adhere to than change? > Can continue to write code assuming it. > > > Consider AMD64_NT. > I assume INTEGER there should be 64bits, even though int and long are both 32. > Corralary: long shouldn't be used for anything, ever. > int is 32 bits, always; ignoring old systems > INTEGER is pointer size, always (the question here) > long is sometimes 32 bits, sometimes pointer size, but neither is always true, on modern systems > If you consider Win64. If you ignore Win64, then, yes, I realize, long is always a pointer. > The types to use in C for pointer sized integers are size_t and ptrdiff_t. > > > For that matter..BYTESIZE and ADRSIZE, they are always the same and will always be, right? > "All machines are byte-addressable", these days and forever more? > > > - Jay > > > From: hosking at cs.purdue.edu > Date: Mon, 5 Apr 2010 19:44:02 -0400 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] RTMachine.PointerAlignment = 1 on NT? > > Same thing only for implementations where BYTESIZE(Word.T) = BYTESIZE(INTEGER) = BYTESIZE(ADDRESS). But that's all of ours. > > On 5 Apr 2010, at 18:03, Jay K wrote: > > Yes. Same thing. > > - Jay > > From: hosking at cs.purdue.edu > Date: Mon, 5 Apr 2010 13:31:45 -0400 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] RTMachine.PointerAlignment = 1 on NT? > > More accurately, BYTESIZE(ADDRESS)? > > Antony Hosking | Associate Professor | Computer Science | Purdue University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > On 5 Apr 2010, at 10:40, Jay K wrote: > > I think we can safely dispense with RTMachine.PointerAlignment and use BYTESIZE(INTEGER). > NT386 is the only current exception. > Even though it isn't required, of any x86 target, it seems the overwhelming practice. > > - Jay > > Subject: Re: [M3devel] RTMachine.PointerAlignment = 1 on NT? > From: hosking at cs.purdue.edu > Date: Mon, 5 Apr 2010 10:25:20 -0400 > CC: m3devel at elegosoft.com > To: jay.krell at cornell.edu > > Yes, correct. Pointers from the stacks may be "derived" from object base references by the compiler or through use of VAR/READONLY parameters. So, the pointer values from the stack themselves need not be aligned. The PointerAlignment tells the collector at what alignment to expect to find pointers stored in the stack. Some compilers/targets may not require that pointer-valued fields in the stack be stored at aligned locations. > > > > Antony Hosking | Associate Professor | Computer Science | Purdue University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > On 5 Apr 2010, at 08:03, Jay K wrote: > > hm I guess pointers themselves (not where they are stored) need not have any alignemnt? > We might only have a pointer into an array of bytes to keep the array alive, > no pointer to the base of the array? > > PROCEDURE F1() > VAR a: ARRAY OF CHAR := NEW(CHAR, 10); > i: INTEGER; > BEGIN > FOR i := FIRST(a) TO LAST(a) DO > something with a[i]; > END > END F1; > > might only have pointers to elements in a? > > - Jay > > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Mon, 5 Apr 2010 11:55:16 +0000 > Subject: Re: [M3devel] RTMachine.PointerAlignment = 1 on NT? > > Interesting: > > PROCEDURE NoteStackLocations (start, stop: ADDRESS) = > VAR fp : UNTRACED REF ADDRESS := start; > BEGIN > IF NOT (start < stop) THEN RETURN END; > stop := stop - ADRSIZE (ADDRESS); (* so we don't overrun the valid addresses *) > WHILE fp <= stop DO (* with the memory read on the next line. *) > WITH page = AddressToPage(fp^) DO > IF page # NIL AND page.desc.space = Space.Previous THEN > IF RTMachine.PointerAlignment = 1 THEN > IF Word.And(LOOPHOLE(fp, INTEGER), BYTESIZE(INTEGER) - 1) # 0 THEN > RTIO.PutText("pointer found on unaligned stack stack="); > RTIO.PutAddr(fp); > RTIO.PutText(" addr="); > RTIO.PutAddr(fp^); > RTIO.PutText("\n"); > RTIO.Flush(); > END; > END; > IF page.desc.pure > THEN PromotePage(page, PromoteReason.AmbiguousPure); > ELSE PromotePage(page, PromoteReason.AmbiguousImpure); > END; > END; > END; > INC(fp, RTMachine.PointerAlignment); > END; > END NoteStackLocations; > > > generates a fair amount of output: > > > C:\dev2\cm3.2\m3-sys\mklib>cm3 > --- building in NT386 --- > ignoring ..\src\m3overrides > pointer found on unaligned stack stack=0x12f3d2 addr=0x1400000 > pointer found on unaligned stack stack=0x12f11e addr=0x1400000 > pointer found on unaligned stack stack=0x12f186 addr=0x1400000 > pointer found on unaligned stack stack=0x12f12e addr=0x1780000 > pointer found on unaligned stack stack=0x12f1ba addr=0x1400000 > pointer found on unaligned stack stack=0x12f442 addr=0x1460147 > new source -> compiling Main.m3 > pointer found on unaligned stack stack=0x12f3d2 addr=0x1400000 > -> linking mklib.exe > > > I need to look a bit more, see what these values are. > We are probably being way over conservative, on NT. > Such unaligned values as 0x1460147 surely shouldn't count as traced pointers. > This example only has one but usually I see many more. > > > C:\dev2\cm3.2\m3-sys\cm3>cm3 > --- building in NT386 --- > ignoring ..\src\m3overrides > pointer found on unaligned stack stack=0x12f3d2 addr=0x1400000 > pointer found on unaligned stack stack=0x12f642 addr=0x1400000 > pointer found on unaligned stack stack=0x12f176 addr=0x1400000 > pointer found on unaligned stack stack=0x12f11e addr=0x1400000 > pointer found on unaligned stack stack=0x12f12a addr=0x1780000 > pointer found on unaligned stack stack=0x12f1b6 addr=0x1400000 > pointer found on unaligned stack stack=0x12f61e addr=0x1400000 > pointer found on unaligned stack stack=0x12f6de addr=0x1900069 > pointer found on unaligned stack stack=0x12f43e addr=0x1400000 > pointer found on unaligned stack stack=0x12f156 addr=0x1400000 > pointer found on unaligned stack stack=0x12f66e addr=0x1400000 > pointer found on unaligned stack stack=0x12f72e addr=0x1900069 > pointer found on unaligned stack stack=0x12f792 addr=0x1cc0000 > pointer found on unaligned stack stack=0x12fb26 addr=0x1d7015c > pointer found on unaligned stack stack=0x12fb52 addr=0x1d90142 > > > All this scanning around in memory the garbage collector has to do, doesn't that kill working set? > It makes all heap and stack part of the working set? Even if I'm not going to access it for long periods? > > > - Jay > > > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Mon, 5 Apr 2010 11:41:10 +0000 > Subject: [M3devel] RTMachine.PointerAlignment = 1 on NT? > > For the vast majority of platforms: > > > RTMachine.PointerAlignment = BYTESIZE(INTEGER). > > > except 1 for NT386, 2 for M68K (dead). > > > PointerAlignment = BYTESIZE(INTEGER); > (* The C compiler allocates all pointers on 'PointerAlignment'-byte > boundaries. The garbage collector scans thread stacks, but only > looks at these possible pointer locations. Setting this value > smaller than is needed will only make your system run slower. > Setting it too large will cause the collector to collect storage > that is not free. *) > > > I suggest this is not exactly true. > 1) Of what relevance is the C compiler? vs. the Modula-3 compiler. > 2) We really think the number is 1 for NT386? > > I understand I could say: > void F(void* traced) > { > #pragma pack(1) > struct { char a; void* p} = {0, traced}; > } > > but > 1) That seems highly unlikely. > 2) Do we really anticipate the case where C code is the *only* holder of a traced reference? > And more so, it wasn't a parameter to the C code -- the location of parameters is controlled by Modula-3, assuming a pointer-aligned stack. > 3) Can't we know/assume/verify that Modula-3 code only stores pointers at more aligned location? > > > My real goal is to make there only be one RTMachine for systems that don't have stack walkers. > Leave SOLgnu/SOLsun alone. > (Later on implement stack walking for many platforms via libunwind.) > > > There are I believe only two differences to iron out. Allocation size (8K vs. 64K) and PointerAlignment (1 vs. BYTESIZE(INTEGER)). > There is a reason for NT to be 64K allocation size -- that is what VirtualAlloc uses. > I can test 64K on others. > Historically smaller is probably more efficient. > These days larger but not *too* large is probably more efficient. > 64K should work fine on all platforms. Heck, even something larger like 1MB is probably good. > I'll test out 64K. > > > Can/should we have "paranoidgc" imply PointerAlignment = 1, and report whenever a pointer is found at a location with alignment less than BYTESIZE(pointer)? > > > A form of this is reasonable today, right? If PointerAligment = 1, I can have it report any found at less than BYTESIZE(pointer), test it a while, if none found, elevate NT386 to that value? > If any found, that'll help educate me/us on why it is 1, and maybe how to change it, or why leave it alone. > > > - Jay > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Wed Apr 7 20:56:54 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Wed, 7 Apr 2010 14:56:54 -0400 Subject: [M3devel] RTMachine.PointerAlignment = 1 on NT? In-Reply-To: References: Message-ID: <20100407185654.GA29570@topoi.pooq.com> On Mon, Apr 05, 2010 at 11:41:10AM +0000, Jay K wrote: > > For the vast majority of platforms: > > > > > > RTMachine.PointerAlignment = BYTESIZE(INTEGER). > > > > > > except 1 for NT386, 2 for M68K (dead). > > > > > > PointerAlignment = BYTESIZE(INTEGER); > (* The C compiler allocates all pointers on 'PointerAlignment'-byte > boundaries. The garbage collector scans thread stacks, but only > looks at these possible pointer locations. Setting this value > smaller than is needed will only make your system run slower. > Setting it too large will cause the collector to collect storage > that is not free. *) > > > > > I suggest this is not exactly true. > > 1) Of what relevance is the C compiler? vs. the Modula-3 compiler. The C compiler is not that relevant. What is relevant is possible other languages that might want to share a garbage collector. I dream of the day when multilanguage programming can be done cleanly for other than the malloc/free kinds of languages. The one big problem with garbage-collected languages at the moment is that they interwork very poorly because they have incompatible storage layouts. Let's not make it harder than necessary. As far as I know, most allocate pointers on pointer-sized boundaries. But pointers may point into objects as well as to them, not necessarily at nice boundaries. -- hendrik From jay.krell at cornell.edu Tue Apr 6 07:31:39 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 6 Apr 2010 05:31:39 +0000 Subject: [M3devel] RTMachine.PointerAlignment = 1 on NT? In-Reply-To: <20100407185654.GA29570@topoi.pooq.com> References: , <20100407185654.GA29570@topoi.pooq.com> Message-ID: > I dream of the day when multilanguage programming can be done cleanly > for other than the malloc/free kinds of languages. The point of .NET, eh? > The one big problem with garbage-collected languages at the moment is > that they interwork very poorly because they have incompatible storage > layouts. "storage layout"? Isn't that kind of underselling it? Seems to me these things encompass like the whole system. You either play into it or you don't. There is a bit of a pick and chose option as I understand, like with "managed C++" you can have native code instead of IL+JIT. Seems to me, syntax isn't all that interesting, but libraries and runtimes are. Syntax matters to the extent that editor supports it. While .NET may support various syntaxes, the point is really to use the one and only runtime and library. You might as well just use C#. Mono works fairly well. Imho. ..Jay > Date: Wed, 7 Apr 2010 14:56:54 -0400 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] RTMachine.PointerAlignment = 1 on NT? > > On Mon, Apr 05, 2010 at 11:41:10AM +0000, Jay K wrote: > > > > For the vast majority of platforms: > > > > RTMachine.PointerAlignment = BYTESIZE(INTEGER). > > > > except 1 for NT386, 2 for M68K (dead). > > > > PointerAlignment = BYTESIZE(INTEGER); > > (* The C compiler allocates all pointers on 'PointerAlignment'-byte > > boundaries. The garbage collector scans thread stacks, but only > > looks at these possible pointer locations. Setting this value > > smaller than is needed will only make your system run slower. > > Setting it too large will cause the collector to collect storage > > that is not free. *) > > > > I suggest this is not exactly true. > > > > 1) Of what relevance is the C compiler? vs. the Modula-3 compiler. > > The C compiler is not that relevant. What is relevant is possible other > languages that might want to share a garbage collector. > > I dream of the day when multilanguage programming can be done cleanly > for other than the malloc/free kinds of languages. > > The one big problem with garbage-collected languages at the moment is > that they interwork very poorly because they have incompatible storage > layouts. > > Let's not make it harder than necessary. > > As far as I know, most allocate pointers on pointer-sized boundaries. > But pointers may point into objects as well as to them, not necessarily > at nice boundaries. > > -- hendrik -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Tue Apr 6 08:14:40 2010 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Tue, 06 Apr 2010 08:14:40 +0200 Subject: [M3devel] lock performance, random thoughts (also current cvsup situation) In-Reply-To: <1F5A794A-40AB-4F94-B11A-9218DAA30ED4@cs.purdue.edu> References: <1270510533.10280.32.camel@faramir.m3w.org> <1F5A794A-40AB-4F94-B11A-9218DAA30ED4@cs.purdue.edu> Message-ID: <1270534480.10280.43.camel@faramir.m3w.org> It's good to read more about subject, which is what I usually do after some tabula rasa thinking on it :). It looks like Linux has optimized this for some time now. Bias by way of very fast operation in uncontended cases. What is current m3devel decision on this? And how I (with Linux and only Linux) can feel this slowdown in cvsup at all? Is it because Elego rebuild cvsupd and is not using Linux server-side?? On Mon, 2010-04-05 at 19:45 -0400, Tony Hosking wrote: > Yes, that's pretty much what modern Java implementations do. -- Dragi?a Duri? From jay.krell at cornell.edu Tue Apr 6 08:41:39 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 6 Apr 2010 06:41:39 +0000 Subject: [M3devel] lock performance, random thoughts (also current cvsup situation) In-Reply-To: <1270534480.10280.43.camel@faramir.m3w.org> References: <1270510533.10280.32.camel@faramir.m3w.org>, <1F5A794A-40AB-4F94-B11A-9218DAA30ED4@cs.purdue.edu>, <1270534480.10280.43.camel@faramir.m3w.org> Message-ID: I don't quite understand your question. I'll answer related things. Do you know notice the slow down in cvsup/cvsupd? I do. But I'm curious if it is just me. Everything except OpenBSD uses pthreads in cm3. Which I believe are always kernel threads though don't know 100%. (FreeBSD? NetBSD?) OpenBSD always uses user threads. Its pthreads are user threads and don't work well enough for us. Always pthreads: Unless you do something "special" -- rebuild with cm3 -DUSER_THREADS or such -- I edit m3core/src/thread.quake, since I don't have support for passing extra parameters around from scripts, dumb, I know. The code I showed is not what Modula-3 does. We just call pthread_lock_mutex. It is what pthread_lock_mutex should look like. Or perhaps something even better, but it is a simple efficient start. We don't inline the locking, which Tony is keen on doing. I don't think we inline for user threads locking either though. Inline is often very good, but I don't know if it would be significant here. Some profiling is probably in order. You? had said that pthread_self or pthread_getspecific/set were showing in profiling? Some kernel calls where? I don't believe any of those three are kernel calls, nor as well that pthread_lock_mutex is without contention. We call self/getspecific/setspecific too often. But they should be fairly fast. There is an approximate plan to improve this post-release -- use libunwind. Again, maybe some profiling is in order. Maybe just of hello world? I'd have to test hello world user threads and kernel threads. See if it is noticably different. Again, cvsup/cvsupd it is very noticable the speed of userthreads vs. kernelthreads. Heck, it maybe isn't even threads. Maybe it is just startup/shutdown. - Jay > From: dragisha at m3w.org > To: hosking at cs.purdue.edu > Date: Tue, 6 Apr 2010 08:14:40 +0200 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] lock performance, random thoughts (also current cvsup situation) > > It's good to read more about subject, which is what I usually do after > some tabula rasa thinking on it :). > > It looks like Linux has optimized this for some time now. Bias by way of > very fast operation in uncontended cases. > > What is current m3devel decision on this? And how I (with Linux and only > Linux) can feel this slowdown in cvsup at all? Is it because Elego > rebuild cvsupd and is not using Linux server-side?? > > On Mon, 2010-04-05 at 19:45 -0400, Tony Hosking wrote: > > Yes, that's pretty much what modern Java implementations do. > > -- > Dragi?a Duri? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Wed Apr 7 05:30:38 2010 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Wed, 7 Apr 2010 03:30:38 +0000 (GMT) Subject: [M3devel] lock performance, random thoughts In-Reply-To: Message-ID: <694635.45812.qm@web23602.mail.ird.yahoo.com> Hi all: I remember that someone inside Acorn reported their use was overwhelming if running in user mode and gave an interesting idea about that in terms of operating system development. They wrote a huge amount of Modula-2+ code even with GUI in Acorn (Olivetti) for the Acorn Archimedes workstation in middle end eighties for its development As the language primitives were the same in use at DEC SRC I guess they didn't consider the language as the problem, but a machine architecture lack of performance factor and in turn affect programs performance by itself. However this got into the development of the ARM architecture introduced since then for the Archimedes ARM and the OS itself. http://lists.cloud9.co.uk/pipermail/bbc-micro/2010-January/007795.html http://www.chiark.greenend.org.uk/~theom/riscos/docs/ultimate/a252swp.txt As a new operating system belongs to a new era the SPIN OS was ahead of its time in terms of performance improvements and no been hit by itself (in terms of performance) which was not an issue because of its nature of safety but still they addressed the use of other operating system code at the operating system level which of course gave problems of performance? but didn't? play a important issue by itself as non safe code could be extra checked or run in space of kernel with no user rights to modify heap allocated space or if not needed to be run in kernel space as a client of an extern library OS in user space with no use in kernel space IMO both approaches either hardware level and operating system level have pros and cons as the operating system level threading is a plus nowadays in multi threaded programs running on multi core equipped hardware but in most cases the use of it could be not a winning situation because not all hardware by its own is multi core in new computer Minis (net books) or systems run in hardware assisted virtualization and not to forget old machines which in most cases can run many applications no multi threaded of today like we use in normal with no performance improvement in new ones on tasks which may no benefit of the extra hardware that may still have at hand so there could be a balance that could benefit most of all cases. Therefore not to say that we may suck user level threading but still considering as a important part of it and needing a new development for the cases of lack of performance an improvement over the cases it lacks and better use of the better hardware like in Acorn did use of the new development to aid it. Probably the best solution is a matter of match between the underlying hardware with proper system-level handling of it to best performance and less penalty in favour of the language developer and final user just to get easier of development and performance gain solution. ?? My vote for operating system level threading (i.e of SPIN) if lacks of performance of faster user threading as a solution for the performance hit problems and user level threading for the systems with no gain over it? so we may gain of language and hardware capabilities to extract the best of both. --- El lun, 5/4/10, Jay K escribi?: De: Jay K Asunto: Re: [M3devel] lock performance, random thoughts Para: dragisha at m3w.org, "Tony" CC: "m3devel" Fecha: lunes, 5 de abril, 2010 19:13 pthread_mutex_lock/unlock does not imply a kernel call. ! pthreads can synchronize in usermode just as well (or only almost as well?) as Tony's design. Only upon contention is a kernel call needed, in both. ? ? That's not to say that everyone implements this well. Linux does. Win32 does. The others I don't know. ? ? Also Tony avoids even atomic operations often. I'm not sure how others compare there. I'm just referring to kernel/syscalls. Are they really so terrible? ? ? ?- Jay ? > From: dragisha at m3w.org > To: hosking at cs.purdue.edu > Date: Tue, 6 Apr 2010 01:57:07 +0200 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] lock performance, random thoughts > > I've used Java for one project, "GUI" app frontend for mobile phones... > What I saw first was their mixup of mutex/condition/cheese in single > root object... But, ok... offtopic there :) > > What I think is important about whole idea is it's simplicity and > (almost) obvious efficiency. It also needs nothing fancy (not today, at > least) and nothing maybe-it-works to implement. Nothing comparable to > early implementations of kernel space threading/thread suspending for > gc/... > > Any takers? :) > > > On Mon, 2010-04-05 at 19:45 -0400, Tony Hosking wrote: > > Yes, that's pretty much what modern Java implementations do. > > > > > -- > Dragi?a Duri? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Highjinks at gmx.com Wed Apr 7 22:09:27 2010 From: Highjinks at gmx.com (Chris) Date: Wed, 7 Apr 2010 22:09:27 +0200 (CEST) Subject: [M3devel] lock performance, random thoughts In-Reply-To: <694635.45812.qm@web23602.mail.ird.yahoo.com> References: <694635.45812.qm@web23602.mail.ird.yahoo.com> Message-ID: <20100407161333.014d6539.Highjinks@gmx.com> As I've said before, this really has NOTHING to do with user/kernel level threading. It's all about synchronization. The only thing a user level thread offers is the possibility to completely avoid context switches, such as is common in a State Machine/Automata. You could also approach it as a Direct Threaded environment, as is common in many Forth implementations. Look at pthreads read and write barriers. Look at http://www-sop.inria.fr/meije/rp/LOFT/ This is a tool which comfortably integrates both Kernel Space and User Space threads into a whole. In general the Synchronous Model(typically implemented as user space threads, due to lack of Kernel support) will typically be much faster when doing interactive and multimedia programming. The Asynchronous model(typically done as Kernel Space threads) will usually be faster at Batch processing. You can do both with Posix Threads. No need to limit the environment exclusively to one or the other. A mixed model provides the best flexibility. -- Chris From dragisha at m3w.org Thu Apr 8 00:06:29 2010 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Thu, 08 Apr 2010 00:06:29 +0200 Subject: [M3devel] lock performance, random thoughts In-Reply-To: <20100407161333.014d6539.Highjinks@gmx.com> References: <694635.45812.qm@web23602.mail.ird.yahoo.com> <20100407161333.014d6539.Highjinks@gmx.com> Message-ID: <1270677989.3816.7.camel@faramir.m3w.org> It's all about synchronization in kernel space, ie part of it when it comes to kernel space through syscalls. Context switching is lesser problem as it is what happens a lot less often than synchronization. Synchronization problem is with systems which are, unlike Linux, doing syscalls on every pthread_mutex_lock and friends. Hybridization of thread system (mixing user and kernel threads) is done talk and I hope nobody takes such thing seriously anymore. On Wed, 2010-04-07 at 22:09 +0200, Chris wrote: > As I've said before, this really has NOTHING to do with user/kernel > level threading. It's all about synchronization. -- Dragi?a Duri? From jay.krell at cornell.edu Thu Apr 8 02:39:05 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 8 Apr 2010 00:39:05 +0000 Subject: [M3devel] lock performance, random thoughts In-Reply-To: <1270677989.3816.7.camel@faramir.m3w.org> References: , <694635.45812.qm@web23602.mail.ird.yahoo.com>, <20100407161333.014d6539.Highjinks@gmx.com>, <1270677989.3816.7.camel@faramir.m3w.org> Message-ID: uncontended pthread_mutex_lock/unlock: syscall on FreeBSD? Solaris? NetBSD? Darwin? Not on Linux. I really doubt on Solaris. Ditto pthread_self, pthread_getspecific, pthread_setspecific? (Though I don't believe we call them frequently on Solaris, and I have a very rough plan to reduce them *later* -- libunwind.) - Jay > From: dragisha at m3w.org > To: Highjinks at gmx.com > Date: Thu, 8 Apr 2010 00:06:29 +0200 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] lock performance, random thoughts > > It's all about synchronization in kernel space, ie part of it when it > comes to kernel space through syscalls. > > Context switching is lesser problem as it is what happens a lot less > often than synchronization. > > Synchronization problem is with systems which are, unlike Linux, doing > syscalls on every pthread_mutex_lock and friends. > > Hybridization of thread system (mixing user and kernel threads) is done > talk and I hope nobody takes such thing seriously anymore. > > On Wed, 2010-04-07 at 22:09 +0200, Chris wrote: > > As I've said before, this really has NOTHING to do with user/kernel > > level threading. It's all about synchronization. > -- > Dragi?a Duri? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Apr 9 12:04:16 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 9 Apr 2010 10:04:16 +0000 Subject: [M3devel] gcc atomics supported ordering? Message-ID: Tony I thought you recently said all memory orderings are supported by the gcc backend with atomics. But there is still: jbook2:m3cg jay$ grep Relaxed * parse.c:typedef enum { Relaxed, Release, Acquire, AcquireRelease, Sequential } O rder; parse.c: if (order != Relaxed) parse.c: warning (0, "only Relaxed memory order for stores is supported"); parse.c: if (order != Relaxed) parse.c: warning (0, "only Relaxed memory order for loads is supported"); - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Apr 9 12:52:09 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 9 Apr 2010 10:52:09 +0000 Subject: [M3devel] ROUND vs. FLOOR in ThreadPThread.m3 nano vs. micro time conversions? Message-ID: Why does UTimeFromTime use FLOOR but ToNTime uses ROUND? PROCEDURE ToNTime (n: LONGREAL; VAR ts: Utime.struct_timespec) = BEGIN ts.tv_sec := TRUNC(n); ts.tv_nsec := ROUND((n - FLOAT(ts.tv_sec, LONGREAL)) * 1.0D9); END ToNTime; TYPE UTime = Utime.struct_timeval; PROCEDURE UTimeFromTime (time: Time.T): UTime = VAR floor := FLOOR(time); BEGIN RETURN UTime{floor, FLOOR(1.0D6 * (time - FLOAT(floor, LONGREAL)))}; END UTimeFromTime; I've changed this code to pass doubles to C and do the conversion there. To reduce/eliminate use of cloned headers. For ROUND I'm using C99: /* C99, very portable */ long lround(double); long long llround(double); #ifdef __CYGWIN__ #define ROUND lround #else #define ROUND llround #endif typedef double FloatSeconds, LONGREAL; typedef struct timeval MicrosecondsStruct_t; #define FLOAT(value, type) ((type)value) #define FLOOR floor static MicrosecondsStruct_t* FloatSecondsToNanosecondsStruct(LONGREAL n, MicrosecondsStruct_t* ts) { ts->tv_sec = (time_t)n; ts->tv_nsec = ROUND((n - FLOAT(ts->tv_sec, LONGREAL)) * 1.0E9); return ts; } static MicrosecondsStruct_t* FloatSecondsToMicrosecondsStruct(FloatSeconds timeout, MicrosecondsStruct_t* utime) { LONGINT sec = FLOOR(timeout); utime->tv_sec = (time_t)sec; utime->tv_usec = (suseconds_t)FLOOR(1.0E6 * (timeout - FLOAT(sec, LONGREAL))); return utime; } Just arbitrarily a little more correct in the nano case vs. the micro case? Matters little? Would matter more for micro due to lower resolution? Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Apr 9 19:01:19 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 9 Apr 2010 13:01:19 -0400 Subject: [M3devel] gcc atomics supported ordering? In-Reply-To: References: Message-ID: Never said any such thing. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 9 Apr 2010, at 06:04, Jay K wrote: > Tony I thought you recently said all memory orderings are supported by the gcc backend with atomics. > But there is still: > > jbook2:m3cg jay$ grep Relaxed * > parse.c:typedef enum { Relaxed, Release, Acquire, AcquireRelease, Sequential } O > rder; > parse.c: if (order != Relaxed) > parse.c: warning (0, "only Relaxed memory order for stores is supported"); > parse.c: if (order != Relaxed) > parse.c: warning (0, "only Relaxed memory order for loads is supported"); > > - Jay > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Apr 11 07:08:07 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 11 Apr 2010 05:08:07 +0000 Subject: [M3devel] m3core/unix directions Message-ID: m3core/unix directions My intent here is to further reduce platform dependencies and header cloning. I know there isn't much left, but there is some. In particular: eliminate struct_timespec (done) eliminate struct_timeval (partly done, more to do) implies eliminating select wrapper implies eliminating gettimeofday wrapper eliminate MAX_FDSET Though there is a possible bug workaround in m3core, that Interix's header is wrong. eliminate time_t (I'd also like to find some way to get 64bit time_t everywhere, though my research so far says it isn't available) eliminate struct_tm Mainly used by m3core/src/time. As well as fix m3-mail/webcard, m3-mail/postcard which have crashing bugs due to declaring their own form. eliminate struct_sockaddr_in maybe eliminate struct_sockaddr_un (I know it was requested) eliminate all of the Usysdep.i3 files (MAX_FDSET, struct_tm) maybe eliminate ioctl/fcntl; there are precious few uses; is the Solaris bug workaround for them needed? That bug workaround is a good reason to keep the wrappers. maybe eliminate stat; there there again there are interesting bug workarounds in the wrappers, the incorrect headers I had for Darwin/arm maybe reduce what all m3core/src/unix provides/wraps, leave it to the clients; however to the extent that they are just const char* and int, probably ok to just leave asis (e.g. open/read/write/close) I'm not sure I'll succeed at all of this, but each step I believe has value. General strategy is to push C up one level. Pass around types that we have complete control of. There is always C below the Posix ports of Modula-3, as well as the Win32/NT port. It is "just" a matter at where the line is. A hypothetical Modula-3 "OS" wouldn't necessarily use any of this C, if it provided m3core/libm3/tcp directly. btw, here's a likely example of the bugs these patterns have caused: C:\dev2\cm3.2\m3-www\http\src\AppBackup.m3(77):(* Nov 16: file.lock broken in call to fcntl - int vs. long confusion C:\dev2\cm3.2\m3-www\http\src\AppBackup.m3(103):(* Nov 16: file.lock broken in call to fcntl - int vs. long confusion To mitigate appearance of hypocrisy, I'm willing to do this work on the Win32 header clones also. Though I think they are a smaller and bigger problem. Bigger because we have cloned *a lot*. Smaller because they vary less across the various Win32 architectures. Similar in size because we use only a small part of them, analogous to what we use for Unix. I speculate that stuff like OpenGL and X Windows aren't as problematic because they are fairly independent of OS/kernel. It is the "libc as kernel wrapper" where the problems are worse, given the relatively large number of varieties (Linux, *BSD, NT, Solaris, Darwin). Though they could still embed e.g. time_t, struct timeval, etc. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Apr 11 07:15:44 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 11 Apr 2010 05:15:44 +0000 Subject: [M3devel] UtimeExtra.i3 Message-ID: Just a note that the following are both duplicated and slightly buggy: C:\dev2\cm3.2\m3-mail\postcard\src\UtimeExtra.i3 C:\dev2\cm3.2\m3-mail\postcard\src\OSUtils.m3 C:\dev2\cm3.2\m3-mail\postcard\src\OSUtils.i3 C:\dev2\cm3.2\m3-mail\webcard\src\UtimeExtra.i3 C:\dev2\cm3.2\m3-mail\webcard\src\OSUtils.m3 C:\dev2\cm3.2\m3-mail\webcard\src\OSUtils.i3 The copies are identical. UtimeExtra.i3: (* The declaration of struct_tm in Utime omits "gmtoff"; mktime isn there at all. *) TYPE struct_tm = RECORD tm_sec: int; (* seconds (0 - 59) *) tm_min: int; (* minutes (0 - 59) *) tm_hour: int; (* hours (0 - 23) *) tm_mday: int; (* day of month (1 - 31) *) tm_mon: int; (* month of year (0 - 11) *) tm_year: int; (* year - 1900 *) tm_wday: int; (* day of week (Sunday = 0) *) tm_yday: int; (* day of year (0 - 365) *) tm_isdst: int; (* flag: daylight savings time in effect *) tm_gmtoff: long; (* offset from GMT in seconds *) tm_zone: char_star;(* abbreviation of timezone name *) END; struct_tm_star = UNTRACED REF struct_tm; <*EXTERNAL*> PROCEDURE localtime (clock: long_star): struct_tm_star; <*EXTERNAL*> PROCEDURE gmtime (clock: long_star): struct_tm_star; <*EXTERNAL*> PROCEDURE mktime (VAR tm: struct_tm): long; gmtoff is omitted deliberately, because it isn't always there. e.g. on Cygwin, Solaris, Interix, Posix. They are #ifed on Linux -- they are there. I don't believe the order of the fields is guaranteed either, but everything I looked at has them the same. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Apr 11 07:43:35 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 11 Apr 2010 05:43:35 +0000 Subject: [M3devel] unused/little used stuff in m3core/unix? Message-ID: Following are not used: fchmod fchown getpagesize sbrk creat isatty That isn't necessarily all. Some are used only in: C:\dev2\cm3.2\m3-libs\libm3\src\os\POSIX e.g. chdir getdtablesize execve Some are used only in the unused m3-pkgtools directory or by cvsup. e.g. umask These all traffic in pretty "plain" types (e.g. no structs, no time_t). So just keep them all? Note of course, uses of these somewhat or significantly inhibit porting to native Win32. Account for somewhat arbirary Posix-specific code outside the cm3 tree and err toward wrapping stuff that is easy? Or push the idea that m3core/libm3 are a good (and safe) portability layer and only provide what they need, and gradually move them towards C to reduce their needs? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Apr 11 16:30:44 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 11 Apr 2010 14:30:44 +0000 Subject: [M3devel] Control-c tends to hang? Message-ID: I'm seeing that pressing control-C has a very high propensity to hang. e.g. release branch, LINUXLIBC6, pthreads cd m3-libs/m3core rm -rf LINUXLIBC6 /cm3/bin/cm3 wait for it to print a file or two control-C if it doesn't hang, again: /cm3/bin/cm3 wait a second control-c It hangs about 25% of the time. gdb is generally useless..I find that true generally lately: Failed to read a valid object file image from memory. (gdb) thread apply all bt Thread 1 (Thread -1210542400 (LWP 4640)): #0 0xb7eff410 in ?? () #1 0xbfd35868 in ?? () #2 0x00000002 in ?? () #3 0x00000000 in ?? () #0 0xb7eff410 in ?? () maybe to do with.. strace gdb: open("/proc/5688/mem", O_RDONLY|O_LARGEFILE) = 6 pread64(6, 0xbfcd1d78, 52, 4294959104) = -1 EIO (Input/output error) close(6) = 0 ptrace(PTRACE_PEEKTEXT, 5688, 0xffffe000, [0]) = -1 EIO (Input/output error) rt_sigprocmask(SIG_SETMASK, [CHLD], NULL, 8) = 0 write(2, "Failed to read a valid object fi"..., 53Failed to read a valid object file image from memory.) = 53 Aha I thought I was running Debian 5.0, but only 4.0..maybe with a newer Debian/gdb. (There was a known problem in older kernels with this signature, I didn't realize I was running old..) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sun Apr 11 17:19:33 2010 From: wagner at elegosoft.com (wagner at elegosoft.com) Date: Sun, 11 Apr 2010 17:19:33 +0200 Subject: [M3devel] release engineering: build release_CM3_5_8_RC5 now? Message-ID: <20100411171933.szof1k9n2ss48sg8@mail.elegosoft.com> I'm currently tagging the release branch with release_CM3_5_8_RC5. Are there still any objections to use the current state of the branch? I'll soon try a sample build on birch. Olaf From jay.krell at cornell.edu Mon Apr 12 01:50:14 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 11 Apr 2010 23:50:14 +0000 Subject: [M3devel] Control-c tends to hang? Message-ID: I upgraded to Debian 5.0 to fix the debugging, and now I haven't been able to get the hang to occur. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Subject: Control-c tends to hang? Date: Sun, 11 Apr 2010 14:30:44 +0000 I'm seeing that pressing control-C has a very high propensity to hang. e.g. release branch, LINUXLIBC6, pthreads cd m3-libs/m3core rm -rf LINUXLIBC6 /cm3/bin/cm3 wait for it to print a file or two control-C if it doesn't hang, again: /cm3/bin/cm3 wait a second control-c It hangs about 25% of the time. gdb is generally useless..I find that true generally lately: Failed to read a valid object file image from memory. (gdb) thread apply all bt Thread 1 (Thread -1210542400 (LWP 4640)): #0 0xb7eff410 in ?? () #1 0xbfd35868 in ?? () #2 0x00000002 in ?? () #3 0x00000000 in ?? () #0 0xb7eff410 in ?? () maybe to do with.. strace gdb: open("/proc/5688/mem", O_RDONLY|O_LARGEFILE) = 6 pread64(6, 0xbfcd1d78, 52, 4294959104) = -1 EIO (Input/output error) close(6) = 0 ptrace(PTRACE_PEEKTEXT, 5688, 0xffffe000, [0]) = -1 EIO (Input/output error) rt_sigprocmask(SIG_SETMASK, [CHLD], NULL, 8) = 0 write(2, "Failed to read a valid object fi"..., 53Failed to read a valid object file image from memory.) = 53 Aha I thought I was running Debian 5.0, but only 4.0..maybe with a newer Debian/gdb. (There was a known problem in older kernels with this signature, I didn't realize I was running old..) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Apr 12 10:12:12 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 12 Apr 2010 10:12:12 +0200 Subject: [M3devel] unused/little used stuff in m3core/unix? In-Reply-To: References: Message-ID: <20100412101212.e3h8b4chco48cc0c@mail.elegosoft.com> Quoting Jay K : > Following are not used: > > fchmod > fchown > getpagesize > sbrk > creat > isatty > > That isn't necessarily all. > > Some are used only in: > > C:\dev2\cm3.2\m3-libs\libm3\src\os\POSIX > e.g. > chdir > getdtablesize > execve > > Some are used only in the unused m3-pkgtools directory or by cvsup. > e.g. umask > > These all traffic in pretty "plain" types (e.g. no structs, no > time_t). So just keep them all? Yes. These are standard POSIX or Unix legacy interfaces. Do not throw them out. > Note of course, uses of these somewhat or significantly inhibit > porting to native Win32. As these are POSIX, that is to be expected. > Account for somewhat arbirary Posix-specific code outside the cm3 tree > and err toward wrapping stuff that is easy? > > Or push the idea that m3core/libm3 are a good (and safe) portability > layer and only provide what they need, and > gradually move them towards C to reduce their needs? As a systems programming language, we should support standard OS interfaces IMO. 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 Mon Apr 12 10:25:20 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 12 Apr 2010 10:25:20 +0200 Subject: [M3devel] regression in m3tests? Message-ID: <20100412102520.dgxs973lk0kgg84s@mail.elegosoft.com> This one is new: http://hudson.modula3.com:8080/job/cm3-test-m3tests-LINUXLIBC6/250/testReport/%28root%29/m3tests/r001__unhandled_exception/ Is it just a new OS version, now writing out an additional line? --- ../src/r0/r001/stderr.build 2008-01-08 17:15:47.000000000 -0800 +++ ../src/r0/r001/LINUXLIBC6/stderr.build 2010-04-11 21:06:07.000000000 -0700 @@ -0,0 +1 @@ +/bin/sh: line 1: 8334 Aborted ./pgm > stdout.pgm.raw 2> stderr.pgm.raw I assume, r002/3/4 are actually OK on Linux, too, just the output is different? We need to adapt the output for r004 (line change in RTAllocator), and probably make our compare a bit more lenient. Any good ideas how to accomplish this easily? 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 jay.krell at cornell.edu Mon Apr 12 11:36:23 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 12 Apr 2010 09:36:23 +0000 Subject: [M3devel] regression in m3tests? In-Reply-To: <20100412102520.dgxs973lk0kgg84s@mail.elegosoft.com> References: <20100412102520.dgxs973lk0kgg84s@mail.elegosoft.com> Message-ID: Tests that abort et. al. have always been a problem. I did a bunch of work to make them less of a problem. But maybe not enough. - Jay > Date: Mon, 12 Apr 2010 10:25:20 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] regression in m3tests? > > This one is new: > > http://hudson.modula3.com:8080/job/cm3-test-m3tests-LINUXLIBC6/250/testReport/%28root%29/m3tests/r001__unhandled_exception/ > > Is it just a new OS version, now writing out an additional line? > > --- ../src/r0/r001/stderr.build 2008-01-08 17:15:47.000000000 -0800 > +++ ../src/r0/r001/LINUXLIBC6/stderr.build 2010-04-11 21:06:07.000000000 -0700 > @@ -0,0 +1 @@ > +/bin/sh: line 1: 8334 Aborted ./pgm > stdout.pgm.raw > 2> stderr.pgm.raw > > I assume, r002/3/4 are actually OK on Linux, too, just the output is > different? > > We need to adapt the output for r004 (line change in RTAllocator), > and probably make our compare a bit more lenient. > > Any good ideas how to accomplish this easily? > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Apr 12 13:13:11 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 12 Apr 2010 13:13:11 +0200 Subject: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? In-Reply-To: <20100411171933.szof1k9n2ss48sg8@mail.elegosoft.com> References: <20100411171933.szof1k9n2ss48sg8@mail.elegosoft.com> Message-ID: <20100412131311.5ax5opbuskcw00sk@mail.elegosoft.com> Quoting wagner at elegosoft.com: > I'm currently tagging the release branch with release_CM3_5_8_RC5. > > Are there still any objections to use the current state of the branch? > > I'll soon try a sample build on birch. As nobody has called `Stop', I've started to build the release packages for RC5. Some can already be found on the download page currently still reachable via the RC4 download (scroll down to the end). http://www.modula3.com/cm3/releng/download.html There have been 401 single changes since the last RC though :-/ See http://hudson.modula3.com:8080/view/makedist/job/cm3-makedist-AMD64_LINUX/changes for details. I don't know how to summarize that or even to motivate this amound of changes that late in a release. Perhaps it's best to just say nothing... If you find any problem with RC5, please let me know as soon as possible. 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 jay.krell at cornell.edu Mon Apr 12 14:45:50 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 12 Apr 2010 12:45:50 +0000 Subject: [M3devel] unused/little used stuff in m3core/unix? In-Reply-To: <20100412101212.e3h8b4chco48cc0c@mail.elegosoft.com> References: , <20100412101212.e3h8b4chco48cc0c@mail.elegosoft.com> Message-ID: Ok on preserving most/all of these but note I'm not keen on preserving like anything dealing with structs or time_t. There are various arguments for/against. This "systems" language interoperates well with C, directly, IF you control the C. Thus we have wrappers. We almost never interface directly with "the OS". Then again, same is true of C. Actual "kernels" have custom calling mechanisms, which gets wrapped in C. I'm not sure we should provide a general set of wrappers, or leave it to each user to write his own, or provide some simple small set. Leaving it to each user is error prone, granted. The historical implementation here was awful and *really* *not* the way. The question then is what should the implementation be. - Jay > Date: Mon, 12 Apr 2010 10:12:12 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] unused/little used stuff in m3core/unix? > > Quoting Jay K : > > > Following are not used: > > > > fchmod > > fchown > > getpagesize > > sbrk > > creat > > isatty > > > > That isn't necessarily all. > > > > Some are used only in: > > > > C:\dev2\cm3.2\m3-libs\libm3\src\os\POSIX > > e.g. > > chdir > > getdtablesize > > execve > > > > Some are used only in the unused m3-pkgtools directory or by cvsup. > > e.g. umask > > > > These all traffic in pretty "plain" types (e.g. no structs, no > > time_t). So just keep them all? > > Yes. These are standard POSIX or Unix legacy interfaces. > Do not throw them out. > > > Note of course, uses of these somewhat or significantly inhibit > > porting to native Win32. > > As these are POSIX, that is to be expected. > > > Account for somewhat arbirary Posix-specific code outside the cm3 tree > > and err toward wrapping stuff that is easy? > > > > Or push the idea that m3core/libm3 are a good (and safe) portability > > layer and only provide what they need, and > > gradually move them towards C to reduce their needs? > > As a systems programming language, we should support standard OS > interfaces IMO. > > Olaf -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Apr 12 15:03:26 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 12 Apr 2010 13:03:26 +0000 Subject: [M3devel] JVideo/struct_timeval? Message-ID: This seems wierd: C:\dev2\cm3.2\m3-ui\jvideo\src\POSIX\jvprotocol.i3(193): timestamp: Utime.struct_timeval; I think they are defining a wire protocol, but embedding platform-specific types in it. How about I just change to Time.T? (64bit floating point, seconds since 1970). We could do like: C:\dev2\cm3.2\m3-ui\jvideo\src\POSIX\decunix\JVSink.m3(440): jvb.timestamp.tv_sec := signed_ntohl(hdr.timestamp.tv_sec); and define it to be transferred as a network order 64bit integer (big endian LONGINT), or maybe an array of 8 bytes. Or maybe define a local struct_timeval separate from Utime that hardcodes the sizes..and maybe using LONGINT? 32bit time_t is apparently still very common, though it seems obviously a big mistake.. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Apr 12 16:46:39 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 12 Apr 2010 14:46:39 +0000 Subject: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? In-Reply-To: <20100412131311.5ax5opbuskcw00sk@mail.elegosoft.com> References: <20100411171933.szof1k9n2ss48sg8@mail.elegosoft.com>, <20100412131311.5ax5opbuskcw00sk@mail.elegosoft.com> Message-ID: Thanks. I see the NT386 packages, but not .msi. - Jay > Date: Mon, 12 Apr 2010 13:13:11 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? > > Quoting wagner at elegosoft.com: > > > I'm currently tagging the release branch with release_CM3_5_8_RC5. > > > > Are there still any objections to use the current state of the branch? > > > > I'll soon try a sample build on birch. > > As nobody has called `Stop', I've started to build the release packages > for RC5. Some can already be found on the download page currently > still reachable via the RC4 download (scroll down to the end). > > http://www.modula3.com/cm3/releng/download.html > > There have been 401 single changes since the last RC though :-/ > See > http://hudson.modula3.com:8080/view/makedist/job/cm3-makedist-AMD64_LINUX/changes > for details. I don't know how to summarize that or even to motivate > this amound of changes that late in a release. Perhaps it's best to > just say nothing... > > If you find any problem with RC5, please let me know as soon as possible. > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Apr 12 17:05:48 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 12 Apr 2010 17:05:48 +0200 Subject: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? In-Reply-To: References: <20100411171933.szof1k9n2ss48sg8@mail.elegosoft.com>, <20100412131311.5ax5opbuskcw00sk@mail.elegosoft.com> Message-ID: <20100412170548.o3go4tu8ys4wgwo4@mail.elegosoft.com> Quoting Jay K : > > Thanks. I see the NT386 packages, but not .msi. I'll check that later; the new index isn't in place, and perhaps the update script is still buggy. Please have a look at the SOLgnu build though: http://hudson.modula3.com:8080/view/makedist/job/cm3-makedist-SOLgnu/16/console This used to work. Anything you changed? Olaf > > > > - Jay > > >> Date: Mon, 12 Apr 2010 13:13:11 +0200 >> From: wagner at elegosoft.com >> To: m3devel at elegosoft.com >> Subject: [M3devel] release 5.8 RC5 build in progress, was: Re: >> release engineering: build release_CM3_5_8_RC5 now? >> >> Quoting wagner at elegosoft.com: >> >> > I'm currently tagging the release branch with release_CM3_5_8_RC5. >> > >> > Are there still any objections to use the current state of the branch? >> > >> > I'll soon try a sample build on birch. >> >> As nobody has called `Stop', I've started to build the release packages >> for RC5. Some can already be found on the download page currently >> still reachable via the RC4 download (scroll down to the end). >> >> http://www.modula3.com/cm3/releng/download.html >> >> There have been 401 single changes since the last RC though :-/ >> See >> http://hudson.modula3.com:8080/view/makedist/job/cm3-makedist-AMD64_LINUX/changes >> for details. I don't know how to summarize that or even to motivate >> this amound of changes that late in a release. Perhaps it's best to >> just say nothing... >> >> If you find any problem with RC5, please let me know as soon as possible. >> >> 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 wagner at elegosoft.com Mon Apr 12 17:26:59 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 12 Apr 2010 17:26:59 +0200 Subject: [M3devel] more RC5 build package problems Message-ID: <20100412172659.fdpk7fn728sgs0c8@mail.elegosoft.com> PPC_DARWIN build failed, too :-( Do you have any idea what could be causing this? http://hudson.modula3.com:8080/view/makedist/job/cm3-makedist-PPC_DARWIN/8/console [...] -rw-r--r-- 1 hudson hudson 1886008 12 Apr 16:18 /Users/hudson/tmp/cm3-bin-ws-tool-PPC_DARWIN-5.8.5-RC5.tgz collection-math.html -rw-r--r-- 1 hudson hudson 2866838 12 Apr 16:19 /Users/hudson/tmp/cm3-bin-ws-math-PPC_DARWIN-5.8.5-RC5.tgz m3-games/columns/PPC_DARWIN/.M3SHIP seems to be broken: Finished: FAILURE The .M3SHIP files looks completely innocent... Olaf PS: Looks like it will take a week to build all target platforms as usual... Invariant could be: never works twice in succession for a give target ;-) -- 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 jay.krell at cornell.edu Mon Apr 12 22:59:34 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 12 Apr 2010 20:59:34 +0000 Subject: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? In-Reply-To: <20100412170548.o3go4tu8ys4wgwo4@mail.elegosoft.com> References: <20100411171933.szof1k9n2ss48sg8@mail.elegosoft.com>, <20100412131311.5ax5opbuskcw00sk@mail.elegosoft.com>, , <20100412170548.o3go4tu8ys4wgwo4@mail.elegosoft.com> Message-ID: SOLgnu partial explanation: Building cm3 itself is going down the path that occurs when you don't -DCM3_VERSION_NUMBER -DCM3_VERSION_TEXT -DCM3_LAST_CHANGED. Not specifying them is supposed to work, but "you" are supposed to specify them really. Enough of a hint? (I don't have the full answer myself.) - Jay > Date: Mon, 12 Apr 2010 17:05:48 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? > > Quoting Jay K : > > > > > Thanks. I see the NT386 packages, but not .msi. > > I'll check that later; the new index isn't in place, and perhaps > the update script is still buggy. > > Please have a look at the SOLgnu build though: > > > http://hudson.modula3.com:8080/view/makedist/job/cm3-makedist-SOLgnu/16/console > > This used to work. Anything you changed? > > Olaf > > > > > > > > - Jay > > > > > >> Date: Mon, 12 Apr 2010 13:13:11 +0200 > >> From: wagner at elegosoft.com > >> To: m3devel at elegosoft.com > >> Subject: [M3devel] release 5.8 RC5 build in progress, was: Re: > >> release engineering: build release_CM3_5_8_RC5 now? > >> > >> Quoting wagner at elegosoft.com: > >> > >> > I'm currently tagging the release branch with release_CM3_5_8_RC5. > >> > > >> > Are there still any objections to use the current state of the branch? > >> > > >> > I'll soon try a sample build on birch. > >> > >> As nobody has called `Stop', I've started to build the release packages > >> for RC5. Some can already be found on the download page currently > >> still reachable via the RC4 download (scroll down to the end). > >> > >> http://www.modula3.com/cm3/releng/download.html > >> > >> There have been 401 single changes since the last RC though :-/ > >> See > >> http://hudson.modula3.com:8080/view/makedist/job/cm3-makedist-AMD64_LINUX/changes > >> for details. I don't know how to summarize that or even to motivate > >> this amound of changes that late in a release. Perhaps it's best to > >> just say nothing... > >> > >> If you find any problem with RC5, please let me know as soon as possible. > >> > >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Apr 12 23:07:02 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 12 Apr 2010 21:07:02 +0000 Subject: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? In-Reply-To: References: <20100411171933.szof1k9n2ss48sg8@mail.elegosoft.com>, , <20100412131311.5ax5opbuskcw00sk@mail.elegosoft.com>, , , , <20100412170548.o3go4tu8ys4wgwo4@mail.elegosoft.com>, Message-ID: I'm *guessing* some *sh problem. Want to try /usr/bin/bash? - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com Date: Mon, 12 Apr 2010 20:59:34 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? SOLgnu partial explanation: Building cm3 itself is going down the path that occurs when you don't -DCM3_VERSION_NUMBER -DCM3_VERSION_TEXT -DCM3_LAST_CHANGED. Not specifying them is supposed to work, but "you" are supposed to specify them really. Enough of a hint? (I don't have the full answer myself.) - Jay > Date: Mon, 12 Apr 2010 17:05:48 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? > > Quoting Jay K : > > > > > Thanks. I see the NT386 packages, but not .msi. > > I'll check that later; the new index isn't in place, and perhaps > the update script is still buggy. > > Please have a look at the SOLgnu build though: > > > http://hudson.modula3.com:8080/view/makedist/job/cm3-makedist-SOLgnu/16/console > > This used to work. Anything you changed? > > Olaf > > > > > > > > - Jay > > > > > >> Date: Mon, 12 Apr 2010 13:13:11 +0200 > >> From: wagner at elegosoft.com > >> To: m3devel at elegosoft.com > >> Subject: [M3devel] release 5.8 RC5 build in progress, was: Re: > >> release engineering: build release_CM3_5_8_RC5 now? > >> > >> Quoting wagner at elegosoft.com: > >> > >> > I'm currently tagging the release branch with release_CM3_5_8_RC5. > >> > > >> > Are there still any objections to use the current state of the branch? > >> > > >> > I'll soon try a sample build on birch. > >> > >> As nobody has called `Stop', I've started to build the release packages > >> for RC5. Some can already be found on the download page currently > >> still reachable via the RC4 download (scroll down to the end). > >> > >> http://www.modula3.com/cm3/releng/download.html > >> > >> There have been 401 single changes since the last RC though :-/ > >> See > >> http://hudson.modula3.com:8080/view/makedist/job/cm3-makedist-AMD64_LINUX/changes > >> for details. I don't know how to summarize that or even to motivate > >> this amound of changes that late in a release. Perhaps it's best to > >> just say nothing... > >> > >> If you find any problem with RC5, please let me know as soon as possible. > >> > >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Apr 12 23:14:47 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 12 Apr 2010 21:14:47 +0000 Subject: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? In-Reply-To: References: <20100411171933.szof1k9n2ss48sg8@mail.elegosoft.com>, ,,<20100412131311.5ax5opbuskcw00sk@mail.elegosoft.com>, ,,, , , <20100412170548.o3go4tu8ys4wgwo4@mail.elegosoft.com>, , , Message-ID: I see part of the problem. - You do define the version earlier in the build, but not later. From reading the log. - I don't know why the grep doesn't work. Searching for '-DROOT'... C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\make-bin-dist-min.sh(133):BUILDLOCAL="${CM3} -build -override -DROOT='${CM3ROOT}'" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\make-bin-dist-min.sh(134):CLEANLOCAL="${CM3} -clean -override -DROOT='${CM3ROOT}'" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\make-bin-dist-min.sh(135):BUILDGLOBAL="${CM3} -build -DROOT='${CM3ROOT}'" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\make-bin-dist-min.sh(136):CLEANGLOBAL="${CM3} -clean -DROOT='${CM3ROOT}'" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\make-bin-dist-min.sh(137):SHIP="${CM3} -ship -DROOT='${CM3ROOT}'" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgcmds.sh(21):DEFS="-DROOT='${CM3ROOT}' -DCM3_VERSION_TEXT='${CM3VERSION}' -DCM3_VERSION_NUMBER='${CM3VERSIONNUM}' -DCM3_LAST_CHANGED='${CM3LASTCHANGED}'" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgmap.sh(424): echo " +++ cm3 -build -override -DTEST -DRUN -DROOT=$ROOT +++" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgmap.sh(429): tres=`cm3 -build -override -DTEST -DRUN -DROOT="${ROOT}" 2> stderr` Maybe use ${DEFS} more? You could also hack cm3/src/m3makefile for the release. Copy the data into it. A better fix in head for the next one? Searching for 'DEFS'... C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgcmds.sh(21):DEFS="-DROOT='${CM3ROOT}' -DCM3_VERSION_TEXT='${CM3VERSION}' -DCM3_VERSION_NUMBER='${CM3VERSIONNUM}' -DCM3_LAST_CHANGED='${CM3LASTCHANGED}'" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgcmds.sh(22):BUILDLOCAL="${BUILDLOCAL:-${CM3} -build -override \$RARGS ${DEFS} ${BUILDARGS}}" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgcmds.sh(23):CLEANLOCAL="${CLEANLOCAL:-${CM3} -clean -override \$RARGS ${DEFS} ${CLEANARGS}}" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgcmds.sh(24):BUILDGLOBAL="${BUILDGLOBAL:-${CM3} -build ${DEFS} \$RARGS ${BUILDARGS}}" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgcmds.sh(25):CLEANGLOBAL="${CLEANGLOBAL:-${CM3} -clean ${DEFS} \$RARGS ${CLEANARGS}}" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgcmds.sh(26):SHIP="${SHIP:-${CM3} -ship \$RARGS ${DEFS} ${SHIPARGS}}" Is DEFS missing somewhere? - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com Date: Mon, 12 Apr 2010 21:07:02 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? I'm *guessing* some *sh problem. Want to try /usr/bin/bash? - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com Date: Mon, 12 Apr 2010 20:59:34 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? SOLgnu partial explanation: Building cm3 itself is going down the path that occurs when you don't -DCM3_VERSION_NUMBER -DCM3_VERSION_TEXT -DCM3_LAST_CHANGED. Not specifying them is supposed to work, but "you" are supposed to specify them really. Enough of a hint? (I don't have the full answer myself.) - Jay > Date: Mon, 12 Apr 2010 17:05:48 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? > > Quoting Jay K : > > > > > Thanks. I see the NT386 packages, but not .msi. > > I'll check that later; the new index isn't in place, and perhaps > the update script is still buggy. > > Please have a look at the SOLgnu build though: > > > http://hudson.modula3.com:8080/view/makedist/job/cm3-makedist-SOLgnu/16/console > > This used to work. Anything you changed? > > Olaf > > > > > > > > - Jay > > > > > >> Date: Mon, 12 Apr 2010 13:13:11 +0200 > >> From: wagner at elegosoft.com > >> To: m3devel at elegosoft.com > >> Subject: [M3devel] release 5.8 RC5 build in progress, was: Re: > >> release engineering: build release_CM3_5_8_RC5 now? > >> > >> Quoting wagner at elegosoft.com: > >> > >> > I'm currently tagging the release branch with release_CM3_5_8_RC5. > >> > > >> > Are there still any objections to use the current state of the branch? > >> > > >> > I'll soon try a sample build on birch. > >> > >> As nobody has called `Stop', I've started to build the release packages > >> for RC5. Some can already be found on the download page currently > >> still reachable via the RC4 download (scroll down to the end). > >> > >> http://www.modula3.com/cm3/releng/download.html > >> > >> There have been 401 single changes since the last RC though :-/ > >> See > >> http://hudson.modula3.com:8080/view/makedist/job/cm3-makedist-AMD64_LINUX/changes > >> for details. I don't know how to summarize that or even to motivate > >> this amound of changes that late in a release. Perhaps it's best to > >> just say nothing... > >> > >> If you find any problem with RC5, please let me know as soon as possible. > >> > >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Apr 12 23:24:03 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 12 Apr 2010 21:24:03 +0000 Subject: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? In-Reply-To: References: <20100411171933.szof1k9n2ss48sg8@mail.elegosoft.com>, , , , <20100412131311.5ax5opbuskcw00sk@mail.elegosoft.com>, , , , , , , , <20100412170548.o3go4tu8ys4wgwo4@mail.elegosoft.com>, , , , , , Message-ID: A good option is to export these three variables: CM3VERSIONNUM CM3VERSION CM3LASTCHANGED and/or use the -D switches. Otherwise m3-sys/cm3/m3makefile goes down a gnarly path (that I put in) of trying to read scripts/version. Which usually works, but could be too sensitive to /bin/sh behavior...often bites us you know. - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com Date: Mon, 12 Apr 2010 21:14:47 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? I see part of the problem. - You do define the version earlier in the build, but not later. From reading the log. - I don't know why the grep doesn't work. Searching for '-DROOT'... C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\make-bin-dist-min.sh(133):BUILDLOCAL="${CM3} -build -override -DROOT='${CM3ROOT}'" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\make-bin-dist-min.sh(134):CLEANLOCAL="${CM3} -clean -override -DROOT='${CM3ROOT}'" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\make-bin-dist-min.sh(135):BUILDGLOBAL="${CM3} -build -DROOT='${CM3ROOT}'" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\make-bin-dist-min.sh(136):CLEANGLOBAL="${CM3} -clean -DROOT='${CM3ROOT}'" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\make-bin-dist-min.sh(137):SHIP="${CM3} -ship -DROOT='${CM3ROOT}'" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgcmds.sh(21):DEFS="-DROOT='${CM3ROOT}' -DCM3_VERSION_TEXT='${CM3VERSION}' -DCM3_VERSION_NUMBER='${CM3VERSIONNUM}' -DCM3_LAST_CHANGED='${CM3LASTCHANGED}'" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgmap.sh(424): echo " +++ cm3 -build -override -DTEST -DRUN -DROOT=$ROOT +++" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgmap.sh(429): tres=`cm3 -build -override -DTEST -DRUN -DROOT="${ROOT}" 2> stderr` Maybe use ${DEFS} more? You could also hack cm3/src/m3makefile for the release. Copy the data into it. A better fix in head for the next one? Searching for 'DEFS'... C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgcmds.sh(21):DEFS="-DROOT='${CM3ROOT}' -DCM3_VERSION_TEXT='${CM3VERSION}' -DCM3_VERSION_NUMBER='${CM3VERSIONNUM}' -DCM3_LAST_CHANGED='${CM3LASTCHANGED}'" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgcmds.sh(22):BUILDLOCAL="${BUILDLOCAL:-${CM3} -build -override \$RARGS ${DEFS} ${BUILDARGS}}" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgcmds.sh(23):CLEANLOCAL="${CLEANLOCAL:-${CM3} -clean -override \$RARGS ${DEFS} ${CLEANARGS}}" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgcmds.sh(24):BUILDGLOBAL="${BUILDGLOBAL:-${CM3} -build ${DEFS} \$RARGS ${BUILDARGS}}" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgcmds.sh(25):CLEANGLOBAL="${CLEANGLOBAL:-${CM3} -clean ${DEFS} \$RARGS ${CLEANARGS}}" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgcmds.sh(26):SHIP="${SHIP:-${CM3} -ship \$RARGS ${DEFS} ${SHIPARGS}}" Is DEFS missing somewhere? - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com Date: Mon, 12 Apr 2010 21:07:02 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? I'm *guessing* some *sh problem. Want to try /usr/bin/bash? - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com Date: Mon, 12 Apr 2010 20:59:34 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? SOLgnu partial explanation: Building cm3 itself is going down the path that occurs when you don't -DCM3_VERSION_NUMBER -DCM3_VERSION_TEXT -DCM3_LAST_CHANGED. Not specifying them is supposed to work, but "you" are supposed to specify them really. Enough of a hint? (I don't have the full answer myself.) - Jay > Date: Mon, 12 Apr 2010 17:05:48 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? > > Quoting Jay K : > > > > > Thanks. I see the NT386 packages, but not .msi. > > I'll check that later; the new index isn't in place, and perhaps > the update script is still buggy. > > Please have a look at the SOLgnu build though: > > > http://hudson.modula3.com:8080/view/makedist/job/cm3-makedist-SOLgnu/16/console > > This used to work. Anything you changed? > > Olaf > > > > > > > > - Jay > > > > > >> Date: Mon, 12 Apr 2010 13:13:11 +0200 > >> From: wagner at elegosoft.com > >> To: m3devel at elegosoft.com > >> Subject: [M3devel] release 5.8 RC5 build in progress, was: Re: > >> release engineering: build release_CM3_5_8_RC5 now? > >> > >> Quoting wagner at elegosoft.com: > >> > >> > I'm currently tagging the release branch with release_CM3_5_8_RC5. > >> > > >> > Are there still any objections to use the current state of the branch? > >> > > >> > I'll soon try a sample build on birch. > >> > >> As nobody has called `Stop', I've started to build the release packages > >> for RC5. Some can already be found on the download page currently > >> still reachable via the RC4 download (scroll down to the end). > >> > >> http://www.modula3.com/cm3/releng/download.html > >> > >> There have been 401 single changes since the last RC though :-/ > >> See > >> http://hudson.modula3.com:8080/view/makedist/job/cm3-makedist-AMD64_LINUX/changes > >> for details. I don't know how to summarize that or even to motivate > >> this amound of changes that late in a release. Perhaps it's best to > >> just say nothing... > >> > >> If you find any problem with RC5, please let me know as soon as possible. > >> > >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Apr 12 23:30:19 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 12 Apr 2010 21:30:19 +0000 Subject: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? In-Reply-To: References: <20100411171933.szof1k9n2ss48sg8@mail.elegosoft.com>, , , , <20100412131311.5ax5opbuskcw00sk@mail.elegosoft.com>, , , , , , , , , <20100412170548.o3go4tu8ys4wgwo4@mail.elegosoft.com>, , , , , , , Message-ID: Actually it looks like the environment path is a little gnarly too. Best to use -D. Maybe we should check in scripts/version.quake along with scripts/version. Two copies are bad, but the machinations in m3-sys/cm3/m3makefile aren't great either. Or maybe version.quake would be the one and only? Depends on where else we really need it, and how easy it is to use in those contexts. Maybe the quake could be written in a better way. I can have another go at it esp. with the newer quake primitives. version.quake would be easy and simple though, at the cost of having the data checked in twice. I'll probably do that in head "soon" (at least 12 hours away). - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com CC: m3devel at elegosoft.com Subject: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? Date: Mon, 12 Apr 2010 21:24:03 +0000 A good option is to export these three variables: CM3VERSIONNUM CM3VERSION CM3LASTCHANGED and/or use the -D switches. Otherwise m3-sys/cm3/m3makefile goes down a gnarly path (that I put in) of trying to read scripts/version. Which usually works, but could be too sensitive to /bin/sh behavior...often bites us you know. - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com Date: Mon, 12 Apr 2010 21:14:47 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? I see part of the problem. - You do define the version earlier in the build, but not later. From reading the log. - I don't know why the grep doesn't work. Searching for '-DROOT'... C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\make-bin-dist-min.sh(133):BUILDLOCAL="${CM3} -build -override -DROOT='${CM3ROOT}'" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\make-bin-dist-min.sh(134):CLEANLOCAL="${CM3} -clean -override -DROOT='${CM3ROOT}'" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\make-bin-dist-min.sh(135):BUILDGLOBAL="${CM3} -build -DROOT='${CM3ROOT}'" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\make-bin-dist-min.sh(136):CLEANGLOBAL="${CM3} -clean -DROOT='${CM3ROOT}'" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\make-bin-dist-min.sh(137):SHIP="${CM3} -ship -DROOT='${CM3ROOT}'" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgcmds.sh(21):DEFS="-DROOT='${CM3ROOT}' -DCM3_VERSION_TEXT='${CM3VERSION}' -DCM3_VERSION_NUMBER='${CM3VERSIONNUM}' -DCM3_LAST_CHANGED='${CM3LASTCHANGED}'" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgmap.sh(424): echo " +++ cm3 -build -override -DTEST -DRUN -DROOT=$ROOT +++" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgmap.sh(429): tres=`cm3 -build -override -DTEST -DRUN -DROOT="${ROOT}" 2> stderr` Maybe use ${DEFS} more? You could also hack cm3/src/m3makefile for the release. Copy the data into it. A better fix in head for the next one? Searching for 'DEFS'... C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgcmds.sh(21):DEFS="-DROOT='${CM3ROOT}' -DCM3_VERSION_TEXT='${CM3VERSION}' -DCM3_VERSION_NUMBER='${CM3VERSIONNUM}' -DCM3_LAST_CHANGED='${CM3LASTCHANGED}'" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgcmds.sh(22):BUILDLOCAL="${BUILDLOCAL:-${CM3} -build -override \$RARGS ${DEFS} ${BUILDARGS}}" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgcmds.sh(23):CLEANLOCAL="${CLEANLOCAL:-${CM3} -clean -override \$RARGS ${DEFS} ${CLEANARGS}}" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgcmds.sh(24):BUILDGLOBAL="${BUILDGLOBAL:-${CM3} -build ${DEFS} \$RARGS ${BUILDARGS}}" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgcmds.sh(25):CLEANGLOBAL="${CLEANGLOBAL:-${CM3} -clean ${DEFS} \$RARGS ${CLEANARGS}}" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgcmds.sh(26):SHIP="${SHIP:-${CM3} -ship \$RARGS ${DEFS} ${SHIPARGS}}" Is DEFS missing somewhere? - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com Date: Mon, 12 Apr 2010 21:07:02 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? I'm *guessing* some *sh problem. Want to try /usr/bin/bash? - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com Date: Mon, 12 Apr 2010 20:59:34 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? SOLgnu partial explanation: Building cm3 itself is going down the path that occurs when you don't -DCM3_VERSION_NUMBER -DCM3_VERSION_TEXT -DCM3_LAST_CHANGED. Not specifying them is supposed to work, but "you" are supposed to specify them really. Enough of a hint? (I don't have the full answer myself.) - Jay > Date: Mon, 12 Apr 2010 17:05:48 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? > > Quoting Jay K : > > > > > Thanks. I see the NT386 packages, but not .msi. > > I'll check that later; the new index isn't in place, and perhaps > the update script is still buggy. > > Please have a look at the SOLgnu build though: > > > http://hudson.modula3.com:8080/view/makedist/job/cm3-makedist-SOLgnu/16/console > > This used to work. Anything you changed? > > Olaf > > > > > > > > - Jay > > > > > >> Date: Mon, 12 Apr 2010 13:13:11 +0200 > >> From: wagner at elegosoft.com > >> To: m3devel at elegosoft.com > >> Subject: [M3devel] release 5.8 RC5 build in progress, was: Re: > >> release engineering: build release_CM3_5_8_RC5 now? > >> > >> Quoting wagner at elegosoft.com: > >> > >> > I'm currently tagging the release branch with release_CM3_5_8_RC5. > >> > > >> > Are there still any objections to use the current state of the branch? > >> > > >> > I'll soon try a sample build on birch. > >> > >> As nobody has called `Stop', I've started to build the release packages > >> for RC5. Some can already be found on the download page currently > >> still reachable via the RC4 download (scroll down to the end). > >> > >> http://www.modula3.com/cm3/releng/download.html > >> > >> There have been 401 single changes since the last RC though :-/ > >> See > >> http://hudson.modula3.com:8080/view/makedist/job/cm3-makedist-AMD64_LINUX/changes > >> for details. I don't know how to summarize that or even to motivate > >> this amound of changes that late in a release. Perhaps it's best to > >> just say nothing... > >> > >> If you find any problem with RC5, please let me know as soon as possible. > >> > >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Apr 12 23:39:57 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 12 Apr 2010 23:39:57 +0200 Subject: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? In-Reply-To: References: <20100411171933.szof1k9n2ss48sg8@mail.elegosoft.com>, , , , <20100412131311.5ax5opbuskcw00sk@mail.elegosoft.com>, , , , , , , , , <20100412170548.o3go4tu8ys4wgwo4@mail.elegosoft.com>, , , , , , , Message-ID: <20100412233957.ftgkq5jpicoo800w@mail.elegosoft.com> Well, I was just wondering what has changed, since the scripts have worked for earlier RCs on your Solaris system. And they're working on half a dozen other platforms. I'll try to follow some of your hints tomorrow. Olaf Quoting Jay K : > Actually it looks like the environment path is a little gnarly too. > > Best to use -D. > > Maybe we should check in scripts/version.quake along with scripts/version. > > Two copies are bad, but the machinations in m3-sys/cm3/m3makefile > aren't great either. > > Or maybe version.quake would be the one and only? > > Depends on where else we really need it, and how easy it is to use > in those contexts. > > Maybe the quake could be written in a better way. I can have > another go at it esp. with the newer quake primitives. > > > > version.quake would be easy and simple though, at the cost of having > the data checked in twice. > > I'll probably do that in head "soon" (at least 12 hours away). > > > > - Jay > > > > > From: jay.krell at cornell.edu > To: wagner at elegosoft.com > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: > release engineering: build release_CM3_5_8_RC5 now? > Date: Mon, 12 Apr 2010 21:24:03 +0000 > > > > A good option is to export these three variables: > > CM3VERSIONNUM > CM3VERSION > CM3LASTCHANGED > > and/or use the -D switches. > Otherwise m3-sys/cm3/m3makefile goes down a gnarly path (that I put > in) of trying to read scripts/version. > Which usually works, but could be too sensitive to /bin/sh > behavior...often bites us you know. > > - Jay > > > > > From: jay.krell at cornell.edu > To: wagner at elegosoft.com > Date: Mon, 12 Apr 2010 21:14:47 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] release 5.8 RC5 build in progress, was: Re: > release engineering: build release_CM3_5_8_RC5 now? > > > > I see part of the problem. > - You do define the version earlier in the build, but not later. > From reading the log. > - I don't know why the grep doesn't work. > > > Searching for '-DROOT'... > C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\make-bin-dist-min.sh(133):BUILDLOCAL="${CM3} -build -override > -DROOT='${CM3ROOT}'" > C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\make-bin-dist-min.sh(134):CLEANLOCAL="${CM3} -clean -override > -DROOT='${CM3ROOT}'" > C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\make-bin-dist-min.sh(135):BUILDGLOBAL="${CM3} -build > -DROOT='${CM3ROOT}'" > C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\make-bin-dist-min.sh(136):CLEANGLOBAL="${CM3} -clean > -DROOT='${CM3ROOT}'" > C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\make-bin-dist-min.sh(137):SHIP="${CM3} -ship > -DROOT='${CM3ROOT}'" > C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgcmds.sh(21):DEFS="-DROOT='${CM3ROOT}' -DCM3_VERSION_TEXT='${CM3VERSION}' -DCM3_VERSION_NUMBER='${CM3VERSIONNUM}' > -DCM3_LAST_CHANGED='${CM3LASTCHANGED}'" > C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgmap.sh(424): > echo " +++ cm3 -build -override -DTEST -DRUN -DROOT=$ROOT +++" > C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgmap.sh(429): > tres=`cm3 -build -override -DTEST -DRUN -DROOT="${ROOT}" 2> stderr` > > > Maybe use ${DEFS} more? > You could also hack cm3/src/m3makefile for the release. Copy the > data into it. > A better fix in head for the next one? > > > Searching for 'DEFS'... > C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgcmds.sh(21):DEFS="-DROOT='${CM3ROOT}' -DCM3_VERSION_TEXT='${CM3VERSION}' -DCM3_VERSION_NUMBER='${CM3VERSIONNUM}' > -DCM3_LAST_CHANGED='${CM3LASTCHANGED}'" > C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgcmds.sh(22):BUILDLOCAL="${BUILDLOCAL:-${CM3} -build -override \$RARGS ${DEFS} > ${BUILDARGS}}" > C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgcmds.sh(23):CLEANLOCAL="${CLEANLOCAL:-${CM3} -clean -override \$RARGS ${DEFS} > ${CLEANARGS}}" > C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgcmds.sh(24):BUILDGLOBAL="${BUILDGLOBAL:-${CM3} -build ${DEFS} \$RARGS > ${BUILDARGS}}" > C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgcmds.sh(25):CLEANGLOBAL="${CLEANGLOBAL:-${CM3} -clean ${DEFS} \$RARGS > ${CLEANARGS}}" > C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgcmds.sh(26):SHIP="${SHIP:-${CM3} -ship \$RARGS ${DEFS} > ${SHIPARGS}}" > > > Is DEFS missing somewhere? > > > - Jay > > > > From: jay.krell at cornell.edu > To: wagner at elegosoft.com > Date: Mon, 12 Apr 2010 21:07:02 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] release 5.8 RC5 build in progress, was: Re: > release engineering: build release_CM3_5_8_RC5 now? > > > > I'm *guessing* some *sh problem. > Want to try /usr/bin/bash? > > - Jay > > > > > > From: jay.krell at cornell.edu > To: wagner at elegosoft.com > Date: Mon, 12 Apr 2010 20:59:34 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] release 5.8 RC5 build in progress, was: Re: > release engineering: build release_CM3_5_8_RC5 now? > > > > SOLgnu partial explanation: > Building cm3 itself is going down the path that occurs when you > don't -DCM3_VERSION_NUMBER -DCM3_VERSION_TEXT -DCM3_LAST_CHANGED. > Not specifying them is supposed to work, but "you" are supposed to > specify them really. > Enough of a hint? (I don't have the full answer myself.) > > - Jay > > >> Date: Mon, 12 Apr 2010 17:05:48 +0200 >> From: wagner at elegosoft.com >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: >> release engineering: build release_CM3_5_8_RC5 now? >> >> Quoting Jay K : >> >> > >> > Thanks. I see the NT386 packages, but not .msi. >> >> I'll check that later; the new index isn't in place, and perhaps >> the update script is still buggy. >> >> Please have a look at the SOLgnu build though: >> >> >> http://hudson.modula3.com:8080/view/makedist/job/cm3-makedist-SOLgnu/16/console >> >> This used to work. Anything you changed? >> >> Olaf >> > >> > >> > >> > - Jay >> > >> > >> >> Date: Mon, 12 Apr 2010 13:13:11 +0200 >> >> From: wagner at elegosoft.com >> >> To: m3devel at elegosoft.com >> >> Subject: [M3devel] release 5.8 RC5 build in progress, was: Re: >> >> release engineering: build release_CM3_5_8_RC5 now? >> >> >> >> Quoting wagner at elegosoft.com: >> >> >> >> > I'm currently tagging the release branch with release_CM3_5_8_RC5. >> >> > >> >> > Are there still any objections to use the current state of the branch? >> >> > >> >> > I'll soon try a sample build on birch. >> >> >> >> As nobody has called `Stop', I've started to build the release packages >> >> for RC5. Some can already be found on the download page currently >> >> still reachable via the RC4 download (scroll down to the end). >> >> >> >> http://www.modula3.com/cm3/releng/download.html >> >> >> >> There have been 401 single changes since the last RC though :-/ >> >> See >> >> >> http://hudson.modula3.com:8080/view/makedist/job/cm3-makedist-AMD64_LINUX/changes >> >> for details. I don't know how to summarize that or even to motivate >> >> this amound of changes that late in a release. Perhaps it's best to >> >> just say nothing... >> >> >> >> If you find any problem with RC5, please let me know as soon as possible. >> >> >> >> 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 >> > -- 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 jay.krell at cornell.edu Wed Apr 14 11:18:05 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 14 Apr 2010 09:18:05 +0000 Subject: [M3devel] SchedulerPosix.IOWait, IOAlertWait Message-ID: SchedulerPosix.IOWait, IOAlertWait: I think the pthread implementation here leaks for every call. The user thread implementation has global bit arrays for a select call, that it makes large enough to hold the largest file descriptor seen. The posix implementation seems to have made them locals, good, but never cleans them up. I'll see if I can confirm and fix. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Apr 14 11:32:32 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 14 Apr 2010 09:32:32 +0000 Subject: [M3devel] SchedulerPosix.IOWait, IOAlertWait In-Reply-To: References: Message-ID: sorry, nevermind, I thought it was untraced for some reaosn. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Wed, 14 Apr 2010 09:18:05 +0000 Subject: [M3devel] SchedulerPosix.IOWait, IOAlertWait SchedulerPosix.IOWait, IOAlertWait: I think the pthread implementation here leaks for every call. The user thread implementation has global bit arrays for a select call, that it makes large enough to hold the largest file descriptor seen. The posix implementation seems to have made them locals, good, but never cleans them up. I'll see if I can confirm and fix. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Apr 14 12:44:08 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 14 Apr 2010 10:44:08 +0000 Subject: [M3devel] hidden interface vs. public Interface? hidden isn't hidden? Message-ID: I tried changing from Interface("Utime") to interface("Utime"). Now, it turns out, that is a mistake anyway, there are still uses, and they aren't going away. But even so, this change doesn't do what it is supposed to. Utime gets marked "hidden" in the .M3EXPORTS files. I haven't yet decipered the .m3x file. I'm still able to build clients e.g. m3-games/tetris. I'm certain I'm using the updated one. I even rm -rf /cm3/pkg/m3core. It seems "hidden" doesn't work? I'll have to dig into the .m3x file I think. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Wed Apr 14 13:01:26 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 14 Apr 2010 13:01:26 +0200 Subject: [M3devel] hidden interface vs. public Interface? hidden isn't hidden? Message-ID: <20100414130126.b9g9pq79escw0g8c@mail.elegosoft.com> Quoting Jay K : > > I tried changing from Interface("Utime") to interface("Utime"). > > Now, it turns out, that is a mistake anyway, there are still > uses, and they aren't going away. > > But even so, this change doesn't do what it is supposed to. > Utime gets marked "hidden" in the .M3EXPORTS files. > I haven't yet decipered the .m3x file. > I'm still able to build clients e.g. m3-games/tetris. > I'm certain I'm using the updated one. I even rm -rf /cm3/pkg/m3core. > > It seems "hidden" doesn't work? > > I'll have to dig into the .m3x file I think. I remember that in the SRC system, hidden files weren't shipped at all to the global package pool. Critical Mass changed that, because hey wanted the source to be available for browsing. I always assumed that the compiler was able to hnour the hidden state of the interface nonetheless. If it doesn't work, we should fix 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 jay.krell at cornell.edu Wed Apr 14 13:37:19 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 14 Apr 2010 11:37:19 +0000 Subject: [M3devel] hidden interface vs. public Interface? hidden isn't hidden? In-Reply-To: <20100414130126.b9g9pq79escw0g8c@mail.elegosoft.com> References: <20100414130126.b9g9pq79escw0g8c@mail.elegosoft.com> Message-ID: Given that public interface TimePosix has functions that return types from Utime, it seems reasonable, though maybe with a warning. But I think when I hid TimePosix, just as an experiment, it still made them public. Something to be looked into much later. - Jay > Date: Wed, 14 Apr 2010 13:01:26 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] hidden interface vs. public Interface? hidden isn't hidden? > > Quoting Jay K : > > > > > I tried changing from Interface("Utime") to interface("Utime"). > > > > Now, it turns out, that is a mistake anyway, there are still > > uses, and they aren't going away. > > > > But even so, this change doesn't do what it is supposed to. > > Utime gets marked "hidden" in the .M3EXPORTS files. > > I haven't yet decipered the .m3x file. > > I'm still able to build clients e.g. m3-games/tetris. > > I'm certain I'm using the updated one. I even rm -rf /cm3/pkg/m3core. > > > > It seems "hidden" doesn't work? > > > > I'll have to dig into the .m3x file I think. > > I remember that in the SRC system, hidden files weren't shipped at all > to the global package pool. Critical Mass changed that, because hey > wanted the source to be available for browsing. > > I always assumed that the compiler was able to hnour the hidden state > of the interface nonetheless. > > If it doesn't work, we should fix 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Apr 14 13:41:30 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 14 Apr 2010 11:41:30 +0000 Subject: [M3devel] checking of timezone in DateBsd.m3 vs. DatePosix.m3? Message-ID: Seems inconsistent: DateBsd.m3: IF (z = NIL) OR (z^ = Local^) THEN tm := Utime.localtime(ADR(tv.tv_sec)); ELSIF z^ = UTC^ THEN tm := Utime.gmtime(ADR(tv.tv_sec)); ELSE (* unknown timezone *) <* ASSERT FALSE *> ? DatePosix.m3: IF (z = NIL) OR (z^ = 0) THEN EVAL Utime.localtime_r (tv.tv_sec, ADR (tm)); ELSE EVAL Utime.gmtime_r (tv.tv_sec, ADR(tm)); END; ? DateBsd.m3 is the overwhelmingly used version, so presumably we should be like it. ? readonly _DateImpls = { "CYGWIN" : "DatePosix", (* hardly counts *) "DARWIN" : "DateBsd", "FREEBSD" : "DateBsd", "HPUX" : "DatePosix", (* hardly counts *) "INTERIX" : "DatePosix", (* hardly counts *) "LINUX" : "DateBsd", "NETBSD" : "DateBsd", "NT" : "DatePosix", (* not actually used *) "OPENBSD" : "DateBsd", "SOLARIS" : "DatePosix", (* counts! *) } In both cases timezone is opaque but revealed to be a branded ref to an integer. Of course, I'm going through this code again for purposes of porting to C, a) to remove struct tm, b) use http://code.google.com/p/y2038/ c) remove struct_timeval/gettimeofday. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Wed Apr 14 16:10:43 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 14 Apr 2010 16:10:43 +0200 Subject: [M3devel] more release build problems, was: RE: release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? In-Reply-To: References: <20100411171933.szof1k9n2ss48sg8@mail.elegosoft.com>, , , , <20100412131311.5ax5opbuskcw00sk@mail.elegosoft.com>, , , , , , , , , , <20100412170548.o3go4tu8ys4wgwo4@mail.elegosoft.com>, , , , , , , , , <20100413171231.bvpqvjz0g0s08k4o@mail.elegosoft.com>, <20100413205035.s01zgk7nk4gggkso@mail.elegosoft.com>, <20100413224251.m5n8tfabk004gc40@mail.elegosoft.com>, , <20100414130624.ej61zwd0dcg0w848@mail.elegosoft.com>, <20100414131755.y55odckn404ws80c@mail.elegosoft.com> Message-ID: <20100414161043.xqhxn8nr40cockko@mail.elegosoft.com> Quoting Jay K : > Olaf, something I don't understand is why the distribution building > is a separate Hudson task. > > Or more specifically, why these don't just run "all the time", > either once a day, or after checkins, or something like that. Because it is a considerable load and we build a fixed (frozen) configuration with it. Once this release is out, we may try to build packages once a day, as tinderbox did/does. > Perhaps this stuff was occuring but I wasn't noticing the failures? > I do look sometimes but not enough. We just haven't looked. Breakage can be seen at http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLgnu/ http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLgnu/lastBuild/testReport/ m3core installation fails, too: "/home/hudson/workspace/cm3-test-all-pkgs-SOLgnu/cm3/m3-libs/m3core/SOLgnu/.M3SHIP", line 4: quake runtime error: unable to copy "libm3core.so.5" to "/home/hudson/work/cm3-inst/ssol/last-ok/lib/libm3core.so.5": errno=2 libm3core.so.5 Fatal Error: package build failed I'll try to improve the checks for serious failures before the next release. Olaf > - Jay > > > > From: jay.krell at cornell.edu > To: wagner at elegosoft.com > Subject: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: > release engineering: build release_CM3_5_8_RC5 now? > Date: Wed, 14 Apr 2010 12:55:23 +0000 > > > > For cvsup/zlib: > The libz hack for Solaris wasn't in release. > I noticed and fixed another minor problem. > > > Try these files: > > > scripts/branch.quake > m3-tools/cvsup/quake/cvsup.quake > > > There is also a more conservative fix if you just take > part of the m3-tools/m3-tools/cvsup/quake/cvsup.quake change. > Just adding SOLgnu and SOLsun to the list of platforms to check. > > > - Jay > > > > > From: jay.krell at cornell.edu > To: wagner at elegosoft.com > Subject: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: > release engineering: build release_CM3_5_8_RC5 now? > Date: Wed, 14 Apr 2010 11:55:46 +0000 > > > > I commited a simple untested fix for the tar -z problem. > Need a bit longer on cvsup/zlib. > > - Jay > > > > > From: jay.krell at cornell.edu > To: wagner at elegosoft.com > Subject: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: > release engineering: build release_CM3_5_8_RC5 now? > Date: Wed, 14 Apr 2010 11:47:47 +0000 > > > > Arg. First is something to do with libz. I thought I actually built > cvsup at least once on Solaris. > Granted, I've definitely noticed that machine is slow, been > testing Posix stuff lately, but Darwin/amd64 and Linux/x86.. > > We can either use /usr/sfw/bin/gtar if it exists (it does, Sun puts > it there), or use tar followed by gzip (optionally with a pipe). > tar + gzip is presumably more portable. > > - Jay > >> Date: Wed, 14 Apr 2010 13:17:55 +0200 >> From: wagner at elegosoft.com >> To: jay.krell at cornell.edu >> Subject: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: >> release engineering: build release_CM3_5_8_RC5 now? >> >> Quoting Olaf Wagner : >> >> > The build has finished, but most of the SOLgnu archives seem to be broken: >> > >> > >> http://hudson.modula3.com:8080/view/test-install/job/cm3-test-install-SOLgnu/7/testReport/ >> > >> > Any ideas why the .M3SHIP files are missing just on this target? >> >> The log shows that package building just stopped after this failure >> in cvsup: >> >> === package m3-tools/cvsup/suplib === >> +++ cm3 -build >> -DROOT='/home/hudson/workspace/cm3-makedist-SOLgnu/cm3' >> -DCM3_VERSION_TEXT='5.8.5' -DCM3_VERSION_NUMBER='050805' >> -DCM3_LAST_CHANGED='2010-04-11' $RARGS && cm3 -ship $RARGS >> -DROOT='/home/hudson/workspace/cm3-makedist-SOLgnu/cm3' >> -DCM3_VERSION_TEXT='5.8.5' -DCM3_VERSION_NUMBER='050805' >> -DCM3_LAST_CHANGED='2010-04-11' +++ >> Undefined first referenced >> symbol in file >> inflate GzipRd.mo >> deflateEnd GzipWr.mo >> inflateEnd GzipRd.mo >> deflate GzipWr.mo >> deflateInit_ Ugzip.mo >> inflateInit_ Ugzip.mo >> ld: fatal: Symbol referencing errors. No output written to libsuplib.so.5 >> collect2: ld returned 1 exit status >> make_lib => 1 >> librarian failed building: suplib >> >> And the .deb package is broken because the Sun tar does not understand >> the -z option you seem to use... >> >> 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 hosking at cs.purdue.edu Wed Apr 14 16:22:22 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 14 Apr 2010 10:22:22 -0400 Subject: [M3devel] hidden interface vs. public Interface? hidden isn't hidden? In-Reply-To: <20100414130126.b9g9pq79escw0g8c@mail.elegosoft.com> References: <20100414130126.b9g9pq79escw0g8c@mail.elegosoft.com> Message-ID: <8D709810-3ED8-4911-8D72-1E27564C8E60@cs.purdue.edu> This being hidden *source* files are not shipped. I'm pretty sure that is still the behaviour. Jay, is it possible that you had a source file left behind from previous install? On 14 Apr 2010, at 07:01, Olaf Wagner wrote: > Quoting Jay K : > >> >> I tried changing from Interface("Utime") to interface("Utime"). >> >> Now, it turns out, that is a mistake anyway, there are still uses, and they aren't going away. >> >> But even so, this change doesn't do what it is supposed to. >> Utime gets marked "hidden" in the .M3EXPORTS files. >> I haven't yet decipered the .m3x file. >> I'm still able to build clients e.g. m3-games/tetris. >> I'm certain I'm using the updated one. I even rm -rf /cm3/pkg/m3core. >> >> It seems "hidden" doesn't work? >> >> I'll have to dig into the .m3x file I think. > > I remember that in the SRC system, hidden files weren't shipped at all > to the global package pool. Critical Mass changed that, because hey > wanted the source to be available for browsing. > > I always assumed that the compiler was able to hnour the hidden state > of the interface nonetheless. > > If it doesn't work, we should fix 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 jay.krell at cornell.edu Wed Apr 14 18:17:53 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 14 Apr 2010 16:17:53 +0000 Subject: [M3devel] hidden interface vs. public Interface? hidden isn't hidden? In-Reply-To: <8D709810-3ED8-4911-8D72-1E27564C8E60@cs.purdue.edu> References: <20100414130126.b9g9pq79escw0g8c@mail.elegosoft.com>, <8D709810-3ED8-4911-8D72-1E27564C8E60@cs.purdue.edu> Message-ID: > Jay, is it possible that you had a source file left behind from previous install? Unlikely. I thought I did rm -rf /cm3/pkg/m3core. I'm testing it again. Just to experiment, I changed all "Interface" to "interface" in m3core/src/unix/Common. It still ships 19 .i3 files to /cm3/pkg/m3core/src/unix/Common. Though I don't think that's a problem. Frontend doesn't reparse imported .i3 files, right? The information is all in .m3x? Not a big concern for me right now though. - Jay > From: hosking at cs.purdue.edu > Date: Wed, 14 Apr 2010 10:22:22 -0400 > To: wagner at elegosoft.com > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] hidden interface vs. public Interface? hidden isn't hidden? > > This being hidden *source* files are not shipped. > I'm pretty sure that is still the behaviour. > Jay, is it possible that you had a source file left behind from previous install? > > On 14 Apr 2010, at 07:01, Olaf Wagner wrote: > > > Quoting Jay K : > > > >> > >> I tried changing from Interface("Utime") to interface("Utime"). > >> > >> Now, it turns out, that is a mistake anyway, there are still uses, and they aren't going away. > >> > >> But even so, this change doesn't do what it is supposed to. > >> Utime gets marked "hidden" in the .M3EXPORTS files. > >> I haven't yet decipered the .m3x file. > >> I'm still able to build clients e.g. m3-games/tetris. > >> I'm certain I'm using the updated one. I even rm -rf /cm3/pkg/m3core. > >> > >> It seems "hidden" doesn't work? > >> > >> I'll have to dig into the .m3x file I think. > > > > I remember that in the SRC system, hidden files weren't shipped at all > > to the global package pool. Critical Mass changed that, because hey > > wanted the source to be available for browsing. > > > > I always assumed that the compiler was able to hnour the hidden state > > of the interface nonetheless. > > > > If it doesn't work, we should fix 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 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Apr 14 18:19:32 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 14 Apr 2010 16:19:32 +0000 Subject: [M3devel] more release build problems, was: RE: release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? In-Reply-To: <20100414161043.xqhxn8nr40cockko@mail.elegosoft.com> References: <20100411171933.szof1k9n2ss48sg8@mail.elegosoft.com>, , , , <20100412131311.5ax5opbuskcw00sk@mail.elegosoft.com>, , , , , , , , , , <20100412170548.o3go4tu8ys4wgwo4@mail.elegosoft.com>, , , , , , , , , <20100413171231.bvpqvjz0g0s08k4o@mail.elegosoft.com>, <20100413205035.s01zgk7nk4gggkso@mail.elegosoft.com>, <20100413224251.m5n8tfabk004gc40@mail.elegosoft.com>, , <20100414130624.ej61zwd0dcg0w848@mail.elegosoft.com>, <20100414131755.y55odckn404ws80c@mail.elegosoft.com>, , <20100414161043.xqhxn8nr40cockko@mail.elegosoft.com> Message-ID: > "HasTrestle" My fault. - Jay > Date: Wed, 14 Apr 2010 16:10:43 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: more release build problems, was: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? > > Quoting Jay K : > > > Olaf, something I don't understand is why the distribution building > > is a separate Hudson task. > > > > Or more specifically, why these don't just run "all the time", > > either once a day, or after checkins, or something like that. > > Because it is a considerable load and we build a fixed (frozen) > configuration with it. > > Once this release is out, we may try to build packages once a day, > as tinderbox did/does. > > > Perhaps this stuff was occuring but I wasn't noticing the failures? > > I do look sometimes but not enough. > > We just haven't looked. Breakage can be seen at > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLgnu/ > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLgnu/lastBuild/testReport/ > > m3core installation fails, too: > > "/home/hudson/workspace/cm3-test-all-pkgs-SOLgnu/cm3/m3-libs/m3core/SOLgnu/.M3SHIP", line 4: quake runtime error: unable to copy "libm3core.so.5" to "/home/hudson/work/cm3-inst/ssol/last-ok/lib/libm3core.so.5": > errno=2 > libm3core.so.5 Fatal Error: package build failed > > I'll try to improve the checks for serious failures before the next release. > > Olaf > > > > - Jay > > > > > > > > From: jay.krell at cornell.edu > > To: wagner at elegosoft.com > > Subject: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: > > release engineering: build release_CM3_5_8_RC5 now? > > Date: Wed, 14 Apr 2010 12:55:23 +0000 > > > > > > > > For cvsup/zlib: > > The libz hack for Solaris wasn't in release. > > I noticed and fixed another minor problem. > > > > > > Try these files: > > > > > > scripts/branch.quake > > m3-tools/cvsup/quake/cvsup.quake > > > > > > There is also a more conservative fix if you just take > > part of the m3-tools/m3-tools/cvsup/quake/cvsup.quake change. > > Just adding SOLgnu and SOLsun to the list of platforms to check. > > > > > > - Jay > > > > > > > > > > From: jay.krell at cornell.edu > > To: wagner at elegosoft.com > > Subject: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: > > release engineering: build release_CM3_5_8_RC5 now? > > Date: Wed, 14 Apr 2010 11:55:46 +0000 > > > > > > > > I commited a simple untested fix for the tar -z problem. > > Need a bit longer on cvsup/zlib. > > > > - Jay > > > > > > > > > > From: jay.krell at cornell.edu > > To: wagner at elegosoft.com > > Subject: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: > > release engineering: build release_CM3_5_8_RC5 now? > > Date: Wed, 14 Apr 2010 11:47:47 +0000 > > > > > > > > Arg. First is something to do with libz. I thought I actually built > > cvsup at least once on Solaris. > > Granted, I've definitely noticed that machine is slow, been > > testing Posix stuff lately, but Darwin/amd64 and Linux/x86.. > > > > We can either use /usr/sfw/bin/gtar if it exists (it does, Sun puts > > it there), or use tar followed by gzip (optionally with a pipe). > > tar + gzip is presumably more portable. > > > > - Jay > > > >> Date: Wed, 14 Apr 2010 13:17:55 +0200 > >> From: wagner at elegosoft.com > >> To: jay.krell at cornell.edu > >> Subject: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: > >> release engineering: build release_CM3_5_8_RC5 now? > >> > >> Quoting Olaf Wagner : > >> > >> > The build has finished, but most of the SOLgnu archives seem to be broken: > >> > > >> > > >> http://hudson.modula3.com:8080/view/test-install/job/cm3-test-install-SOLgnu/7/testReport/ > >> > > >> > Any ideas why the .M3SHIP files are missing just on this target? > >> > >> The log shows that package building just stopped after this failure > >> in cvsup: > >> > >> === package m3-tools/cvsup/suplib === > >> +++ cm3 -build > >> -DROOT='/home/hudson/workspace/cm3-makedist-SOLgnu/cm3' > >> -DCM3_VERSION_TEXT='5.8.5' -DCM3_VERSION_NUMBER='050805' > >> -DCM3_LAST_CHANGED='2010-04-11' $RARGS && cm3 -ship $RARGS > >> -DROOT='/home/hudson/workspace/cm3-makedist-SOLgnu/cm3' > >> -DCM3_VERSION_TEXT='5.8.5' -DCM3_VERSION_NUMBER='050805' > >> -DCM3_LAST_CHANGED='2010-04-11' +++ > >> Undefined first referenced > >> symbol in file > >> inflate GzipRd.mo > >> deflateEnd GzipWr.mo > >> inflateEnd GzipRd.mo > >> deflate GzipWr.mo > >> deflateInit_ Ugzip.mo > >> inflateInit_ Ugzip.mo > >> ld: fatal: Symbol referencing errors. No output written to libsuplib.so.5 > >> collect2: ld returned 1 exit status > >> make_lib => 1 > >> librarian failed building: suplib > >> > >> And the .deb package is broken because the Sun tar does not understand > >> the -z option you seem to use... > >> > >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Apr 14 18:20:39 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 14 Apr 2010 16:20:39 +0000 Subject: [M3devel] more release build problems, was: RE: release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? In-Reply-To: <20100414161043.xqhxn8nr40cockko@mail.elegosoft.com> References: <20100411171933.szof1k9n2ss48sg8@mail.elegosoft.com>, , , , <20100412131311.5ax5opbuskcw00sk@mail.elegosoft.com>, , , , , , , , , , <20100412170548.o3go4tu8ys4wgwo4@mail.elegosoft.com>, , , , , , , , , <20100413171231.bvpqvjz0g0s08k4o@mail.elegosoft.com>, <20100413205035.s01zgk7nk4gggkso@mail.elegosoft.com>, <20100413224251.m5n8tfabk004gc40@mail.elegosoft.com>, , <20100414130624.ej61zwd0dcg0w848@mail.elegosoft.com>, <20100414131755.y55odckn404ws80c@mail.elegosoft.com>, , <20100414161043.xqhxn8nr40cockko@mail.elegosoft.com> Message-ID: er. wait, that function is in release though. - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com CC: m3devel at elegosoft.com Subject: RE: more release build problems, was: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? Date: Wed, 14 Apr 2010 16:19:32 +0000 > "HasTrestle" My fault. - Jay > Date: Wed, 14 Apr 2010 16:10:43 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: more release build problems, was: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? > > Quoting Jay K : > > > Olaf, something I don't understand is why the distribution building > > is a separate Hudson task. > > > > Or more specifically, why these don't just run "all the time", > > either once a day, or after checkins, or something like that. > > Because it is a considerable load and we build a fixed (frozen) > configuration with it. > > Once this release is out, we may try to build packages once a day, > as tinderbox did/does. > > > Perhaps this stuff was occuring but I wasn't noticing the failures? > > I do look sometimes but not enough. > > We just haven't looked. Breakage can be seen at > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLgnu/ > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLgnu/lastBuild/testReport/ > > m3core installation fails, too: > > "/home/hudson/workspace/cm3-test-all-pkgs-SOLgnu/cm3/m3-libs/m3core/SOLgnu/.M3SHIP", line 4: quake runtime error: unable to copy "libm3core.so.5" to "/home/hudson/work/cm3-inst/ssol/last-ok/lib/libm3core.so.5": > errno=2 > libm3core.so.5 Fatal Error: package build failed > > I'll try to improve the checks for serious failures before the next release. > > Olaf > > > > - Jay > > > > > > > > From: jay.krell at cornell.edu > > To: wagner at elegosoft.com > > Subject: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: > > release engineering: build release_CM3_5_8_RC5 now? > > Date: Wed, 14 Apr 2010 12:55:23 +0000 > > > > > > > > For cvsup/zlib: > > The libz hack for Solaris wasn't in release. > > I noticed and fixed another minor problem. > > > > > > Try these files: > > > > > > scripts/branch.quake > > m3-tools/cvsup/quake/cvsup.quake > > > > > > There is also a more conservative fix if you just take > > part of the m3-tools/m3-tools/cvsup/quake/cvsup.quake change. > > Just adding SOLgnu and SOLsun to the list of platforms to check. > > > > > > - Jay > > > > > > > > > > From: jay.krell at cornell.edu > > To: wagner at elegosoft.com > > Subject: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: > > release engineering: build release_CM3_5_8_RC5 now? > > Date: Wed, 14 Apr 2010 11:55:46 +0000 > > > > > > > > I commited a simple untested fix for the tar -z problem. > > Need a bit longer on cvsup/zlib. > > > > - Jay > > > > > > > > > > From: jay.krell at cornell.edu > > To: wagner at elegosoft.com > > Subject: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: > > release engineering: build release_CM3_5_8_RC5 now? > > Date: Wed, 14 Apr 2010 11:47:47 +0000 > > > > > > > > Arg. First is something to do with libz. I thought I actually built > > cvsup at least once on Solaris. > > Granted, I've definitely noticed that machine is slow, been > > testing Posix stuff lately, but Darwin/amd64 and Linux/x86.. > > > > We can either use /usr/sfw/bin/gtar if it exists (it does, Sun puts > > it there), or use tar followed by gzip (optionally with a pipe). > > tar + gzip is presumably more portable. > > > > - Jay > > > >> Date: Wed, 14 Apr 2010 13:17:55 +0200 > >> From: wagner at elegosoft.com > >> To: jay.krell at cornell.edu > >> Subject: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: > >> release engineering: build release_CM3_5_8_RC5 now? > >> > >> Quoting Olaf Wagner : > >> > >> > The build has finished, but most of the SOLgnu archives seem to be broken: > >> > > >> > > >> http://hudson.modula3.com:8080/view/test-install/job/cm3-test-install-SOLgnu/7/testReport/ > >> > > >> > Any ideas why the .M3SHIP files are missing just on this target? > >> > >> The log shows that package building just stopped after this failure > >> in cvsup: > >> > >> === package m3-tools/cvsup/suplib === > >> +++ cm3 -build > >> -DROOT='/home/hudson/workspace/cm3-makedist-SOLgnu/cm3' > >> -DCM3_VERSION_TEXT='5.8.5' -DCM3_VERSION_NUMBER='050805' > >> -DCM3_LAST_CHANGED='2010-04-11' $RARGS && cm3 -ship $RARGS > >> -DROOT='/home/hudson/workspace/cm3-makedist-SOLgnu/cm3' > >> -DCM3_VERSION_TEXT='5.8.5' -DCM3_VERSION_NUMBER='050805' > >> -DCM3_LAST_CHANGED='2010-04-11' +++ > >> Undefined first referenced > >> symbol in file > >> inflate GzipRd.mo > >> deflateEnd GzipWr.mo > >> inflateEnd GzipRd.mo > >> deflate GzipWr.mo > >> deflateInit_ Ugzip.mo > >> inflateInit_ Ugzip.mo > >> ld: fatal: Symbol referencing errors. No output written to libsuplib.so.5 > >> collect2: ld returned 1 exit status > >> make_lib => 1 > >> librarian failed building: suplib > >> > >> And the .deb package is broken because the Sun tar does not understand > >> the -z option you seem to use... > >> > >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Apr 14 18:28:48 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 14 Apr 2010 16:28:48 +0000 Subject: [M3devel] more release build problems, was: RE: release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? In-Reply-To: <20100414161043.xqhxn8nr40cockko@mail.elegosoft.com> References: <20100411171933.szof1k9n2ss48sg8@mail.elegosoft.com>, , , , <20100412131311.5ax5opbuskcw00sk@mail.elegosoft.com>, , , , , , , , , , <20100412170548.o3go4tu8ys4wgwo4@mail.elegosoft.com>, , , , , , , , , <20100413171231.bvpqvjz0g0s08k4o@mail.elegosoft.com>, <20100413205035.s01zgk7nk4gggkso@mail.elegosoft.com>, <20100413224251.m5n8tfabk004gc40@mail.elegosoft.com>, , <20100414130624.ej61zwd0dcg0w848@mail.elegosoft.com>, <20100414131755.y55odckn404ws80c@mail.elegosoft.com>, , <20100414161043.xqhxn8nr40cockko@mail.elegosoft.com> Message-ID: This will help but more looking ineeded. C:\dev2\cm3.release_branch_cm3_5_8\m3-obliq>cvs -z3 commit -m "acceptable hack for release branch, don't put in head" obliqbinanim/src/m3makefile obliqbinui/src/m3makefile /usr/cvs/cm3/m3-obliq/obliqbinanim/src/m3makefile,v <-- obliqbinanim/src/m3makefile new revision: 1.1.1.1.8.2; previous revision: 1.1.1.1.8.1 /usr/cvs/cm3/m3-obliq/obliqbinui/src/m3makefile,v <-- obliqbinui/src/m3makefile new revision: 1.1.1.1.8.2; previous revision: 1.1.1.1.8.1 - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com CC: m3devel at elegosoft.com Subject: RE: more release build problems, was: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? Date: Wed, 14 Apr 2010 16:20:39 +0000 er. wait, that function is in release though. - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com CC: m3devel at elegosoft.com Subject: RE: more release build problems, was: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? Date: Wed, 14 Apr 2010 16:19:32 +0000 > "HasTrestle" My fault. - Jay > Date: Wed, 14 Apr 2010 16:10:43 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: more release build problems, was: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? > > Quoting Jay K : > > > Olaf, something I don't understand is why the distribution building > > is a separate Hudson task. > > > > Or more specifically, why these don't just run "all the time", > > either once a day, or after checkins, or something like that. > > Because it is a considerable load and we build a fixed (frozen) > configuration with it. > > Once this release is out, we may try to build packages once a day, > as tinderbox did/does. > > > Perhaps this stuff was occuring but I wasn't noticing the failures? > > I do look sometimes but not enough. > > We just haven't looked. Breakage can be seen at > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLgnu/ > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLgnu/lastBuild/testReport/ > > m3core installation fails, too: > > "/home/hudson/workspace/cm3-test-all-pkgs-SOLgnu/cm3/m3-libs/m3core/SOLgnu/.M3SHIP", line 4: quake runtime error: unable to copy "libm3core.so.5" to "/home/hudson/work/cm3-inst/ssol/last-ok/lib/libm3core.so.5": > errno=2 > libm3core.so.5 Fatal Error: package build failed > > I'll try to improve the checks for serious failures before the next release. > > Olaf > > > > - Jay > > > > > > > > From: jay.krell at cornell.edu > > To: wagner at elegosoft.com > > Subject: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: > > release engineering: build release_CM3_5_8_RC5 now? > > Date: Wed, 14 Apr 2010 12:55:23 +0000 > > > > > > > > For cvsup/zlib: > > The libz hack for Solaris wasn't in release. > > I noticed and fixed another minor problem. > > > > > > Try these files: > > > > > > scripts/branch.quake > > m3-tools/cvsup/quake/cvsup.quake > > > > > > There is also a more conservative fix if you just take > > part of the m3-tools/m3-tools/cvsup/quake/cvsup.quake change. > > Just adding SOLgnu and SOLsun to the list of platforms to check. > > > > > > - Jay > > > > > > > > > > From: jay.krell at cornell.edu > > To: wagner at elegosoft.com > > Subject: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: > > release engineering: build release_CM3_5_8_RC5 now? > > Date: Wed, 14 Apr 2010 11:55:46 +0000 > > > > > > > > I commited a simple untested fix for the tar -z problem. > > Need a bit longer on cvsup/zlib. > > > > - Jay > > > > > > > > > > From: jay.krell at cornell.edu > > To: wagner at elegosoft.com > > Subject: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: > > release engineering: build release_CM3_5_8_RC5 now? > > Date: Wed, 14 Apr 2010 11:47:47 +0000 > > > > > > > > Arg. First is something to do with libz. I thought I actually built > > cvsup at least once on Solaris. > > Granted, I've definitely noticed that machine is slow, been > > testing Posix stuff lately, but Darwin/amd64 and Linux/x86.. > > > > We can either use /usr/sfw/bin/gtar if it exists (it does, Sun puts > > it there), or use tar followed by gzip (optionally with a pipe). > > tar + gzip is presumably more portable. > > > > - Jay > > > >> Date: Wed, 14 Apr 2010 13:17:55 +0200 > >> From: wagner at elegosoft.com > >> To: jay.krell at cornell.edu > >> Subject: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: > >> release engineering: build release_CM3_5_8_RC5 now? > >> > >> Quoting Olaf Wagner : > >> > >> > The build has finished, but most of the SOLgnu archives seem to be broken: > >> > > >> > > >> http://hudson.modula3.com:8080/view/test-install/job/cm3-test-install-SOLgnu/7/testReport/ > >> > > >> > Any ideas why the .M3SHIP files are missing just on this target? > >> > >> The log shows that package building just stopped after this failure > >> in cvsup: > >> > >> === package m3-tools/cvsup/suplib === > >> +++ cm3 -build > >> -DROOT='/home/hudson/workspace/cm3-makedist-SOLgnu/cm3' > >> -DCM3_VERSION_TEXT='5.8.5' -DCM3_VERSION_NUMBER='050805' > >> -DCM3_LAST_CHANGED='2010-04-11' $RARGS && cm3 -ship $RARGS > >> -DROOT='/home/hudson/workspace/cm3-makedist-SOLgnu/cm3' > >> -DCM3_VERSION_TEXT='5.8.5' -DCM3_VERSION_NUMBER='050805' > >> -DCM3_LAST_CHANGED='2010-04-11' +++ > >> Undefined first referenced > >> symbol in file > >> inflate GzipRd.mo > >> deflateEnd GzipWr.mo > >> inflateEnd GzipRd.mo > >> deflate GzipWr.mo > >> deflateInit_ Ugzip.mo > >> inflateInit_ Ugzip.mo > >> ld: fatal: Symbol referencing errors. No output written to libsuplib.so.5 > >> collect2: ld returned 1 exit status > >> make_lib => 1 > >> librarian failed building: suplib > >> > >> And the .deb package is broken because the Sun tar does not understand > >> the -z option you seem to use... > >> > >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Wed Apr 14 18:40:02 2010 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Wed, 14 Apr 2010 16:40:02 +0000 (GMT) Subject: [M3devel] hidden interface vs. public Interface? hidden isn't hidden? In-Reply-To: <8D709810-3ED8-4911-8D72-1E27564C8E60@cs.purdue.edu> Message-ID: <962394.19120.qm@web23606.mail.ird.yahoo.com> Hi all: there is a quake directive to export or hide interfaces to packages in cm3 this is from the DEC SRC packages and later pm3, heck the information is the same in all: http://modula3.com/cm3/doc/help/cm3/m3build/hiding.html http://cs.wheaton.edu/~cgray/misc/m3/pm3pkg/m3build/src/html/hiding.html http://www.cs.arizona.edu/~collberg/Research/Modula-3/modula-3/html/m3build/hiding.html Please note they mention they accept capitalization convention in commands initial letter but partly to support old style m3makefiles so they provide that to clarify better I think you can try with export_interface("Utime") and to check capitalization convention with /* interface("Utime")*/ Interface("Utime") export_interface("Utime") I remember there are some issues tough if the Unix file has owner only read permissions because the file will be exported as it is so other users included m3browser won't be able to read the file (for instance if you exported as root user and reading from the web in m3browser), same sort of things happens in NT386. Though in the above links mention they had this convention of uppercase first 'i' of Interface("Utime") I know related examples of this kind of missing of meaning, as as source directory called 'SRC' is not accepted (i.e it doesn't find source directory) in Unix platforms but it was accepted in NT386 (in DEC SRC M3, i.e it builds) perhaps because of capital letter symbols (in)discrimination in terminal platforms I guess (I'm aware unix make looks for Makefile and if not for makefile). Now I don't know what was is the case in M3/PC Klagenfurt (but as I see the the m3makefiles they had in M3PC 1994 release are C preprocessor directives with special function names a kind of similar to quake and mostly beginning in capital letters) port because it was a DOS platform and they wrote a shell into which can build programs (they didn't have m3make DEC SRC program which because it worked with unix make), I know the long names are ignored in DOS terminals (they substitute the last part with a ~) but they sort of fixed this behavior in the builder/shell they wrote using a name map see: http://web.archive.org/web/20000520073936/www.ifi.uni-klu.ac.at/Modula-3/m3pc/m3pc.html Thanks, I hope it helps --- El mi?, 14/4/10, Tony Hosking escribi?: > De: Tony Hosking > Asunto: Re: [M3devel] hidden interface vs. public Interface? hidden isn't hidden? > Para: "Olaf Wagner" > CC: m3devel at elegosoft.com > Fecha: mi?rcoles, 14 de abril, 2010 09:22 > This being hidden *source* files are > not shipped. > I'm pretty sure that is still the behaviour. > Jay, is it possible that you had a source file left behind > from previous install? > > On 14 Apr 2010, at 07:01, Olaf Wagner wrote: > > > Quoting Jay K : > > > >> > >> I tried changing from Interface("Utime") to > interface("Utime"). > >> > >> Now, it turns out, that is a mistake > anyway, there are still uses, and they aren't going > away. > >> > >> But even so, this change doesn't do what it is > supposed to. > >> Utime gets marked "hidden" in the .M3EXPORTS > files. > >> I haven't yet decipered the .m3x file. > >> I'm still able to build clients e.g. > m3-games/tetris. > >> I'm certain I'm using the updated one. I even rm > -rf /cm3/pkg/m3core. > >> > >> It seems "hidden" doesn't work? > >> > >> I'll have to dig into the .m3x file I think. > > > > I remember that in the SRC system, hidden files > weren't shipped at all > > to the global package pool. Critical Mass changed > that, because hey > > wanted the source to be available for browsing. > > > > I always assumed that the compiler was able to hnour > the hidden state > > of the interface nonetheless. > > > > If it doesn't work, we should fix 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 jay.krell at cornell.edu Wed Apr 14 18:48:04 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 14 Apr 2010 16:48:04 +0000 Subject: [M3devel] more release build problems, was: RE: release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? In-Reply-To: References: <20100411171933.szof1k9n2ss48sg8@mail.elegosoft.com>, , , ,,<20100412131311.5ax5opbuskcw00sk@mail.elegosoft.com>, , , ,,, , , , , ,,<20100412170548.o3go4tu8ys4wgwo4@mail.elegosoft.com>, , , ,,, , , , , , , , , <20100413171231.bvpqvjz0g0s08k4o@mail.elegosoft.com>, , <20100413205035.s01zgk7nk4gggkso@mail.elegosoft.com>, , <20100413224251.m5n8tfabk004gc40@mail.elegosoft.com>, , , , <20100414130624.ej61zwd0dcg0w848@mail.elegosoft.com>, , <20100414131755.y55odckn404ws80c@mail.elegosoft.com>, , , , <20100414161043.xqhxn8nr40cockko@mail.elegosoft.com>, Message-ID: postgres95/test and odbc/test I added filtering to match the package, should help. That's still not everything. The m3core error is odd. The cvsup one about merger.tmpl also. - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com Date: Wed, 14 Apr 2010 16:28:48 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] more release build problems, was: RE: release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? This will help but more looking ineeded. C:\dev2\cm3.release_branch_cm3_5_8\m3-obliq>cvs -z3 commit -m "acceptable hack for release branch, don't put in head" obliqbinanim/src/m3makefile obliqbinui/src/m3makefile /usr/cvs/cm3/m3-obliq/obliqbinanim/src/m3makefile,v <-- obliqbinanim/src/m3makefile new revision: 1.1.1.1.8.2; previous revision: 1.1.1.1.8.1 /usr/cvs/cm3/m3-obliq/obliqbinui/src/m3makefile,v <-- obliqbinui/src/m3makefile new revision: 1.1.1.1.8.2; previous revision: 1.1.1.1.8.1 - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com CC: m3devel at elegosoft.com Subject: RE: more release build problems, was: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? Date: Wed, 14 Apr 2010 16:20:39 +0000 er. wait, that function is in release though. - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com CC: m3devel at elegosoft.com Subject: RE: more release build problems, was: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? Date: Wed, 14 Apr 2010 16:19:32 +0000 > "HasTrestle" My fault. - Jay > Date: Wed, 14 Apr 2010 16:10:43 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: more release build problems, was: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? > > Quoting Jay K : > > > Olaf, something I don't understand is why the distribution building > > is a separate Hudson task. > > > > Or more specifically, why these don't just run "all the time", > > either once a day, or after checkins, or something like that. > > Because it is a considerable load and we build a fixed (frozen) > configuration with it. > > Once this release is out, we may try to build packages once a day, > as tinderbox did/does. > > > Perhaps this stuff was occuring but I wasn't noticing the failures? > > I do look sometimes but not enough. > > We just haven't looked. Breakage can be seen at > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLgnu/ > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLgnu/lastBuild/testReport/ > > m3core installation fails, too: > > "/home/hudson/workspace/cm3-test-all-pkgs-SOLgnu/cm3/m3-libs/m3core/SOLgnu/.M3SHIP", line 4: quake runtime error: unable to copy "libm3core.so.5" to "/home/hudson/work/cm3-inst/ssol/last-ok/lib/libm3core.so.5": > errno=2 > libm3core.so.5 Fatal Error: package build failed > > I'll try to improve the checks for serious failures before the next release. > > Olaf > > > > - Jay > > > > > > > > From: jay.krell at cornell.edu > > To: wagner at elegosoft.com > > Subject: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: > > release engineering: build release_CM3_5_8_RC5 now? > > Date: Wed, 14 Apr 2010 12:55:23 +0000 > > > > > > > > For cvsup/zlib: > > The libz hack for Solaris wasn't in release. > > I noticed and fixed another minor problem. > > > > > > Try these files: > > > > > > scripts/branch.quake > > m3-tools/cvsup/quake/cvsup.quake > > > > > > There is also a more conservative fix if you just take > > part of the m3-tools/m3-tools/cvsup/quake/cvsup.quake change. > > Just adding SOLgnu and SOLsun to the list of platforms to check. > > > > > > - Jay > > > > > > > > > > From: jay.krell at cornell.edu > > To: wagner at elegosoft.com > > Subject: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: > > release engineering: build release_CM3_5_8_RC5 now? > > Date: Wed, 14 Apr 2010 11:55:46 +0000 > > > > > > > > I commited a simple untested fix for the tar -z problem. > > Need a bit longer on cvsup/zlib. > > > > - Jay > > > > > > > > > > From: jay.krell at cornell.edu > > To: wagner at elegosoft.com > > Subject: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: > > release engineering: build release_CM3_5_8_RC5 now? > > Date: Wed, 14 Apr 2010 11:47:47 +0000 > > > > > > > > Arg. First is something to do with libz. I thought I actually built > > cvsup at least once on Solaris. > > Granted, I've definitely noticed that machine is slow, been > > testing Posix stuff lately, but Darwin/amd64 and Linux/x86.. > > > > We can either use /usr/sfw/bin/gtar if it exists (it does, Sun puts > > it there), or use tar followed by gzip (optionally with a pipe). > > tar + gzip is presumably more portable. > > > > - Jay > > > >> Date: Wed, 14 Apr 2010 13:17:55 +0200 > >> From: wagner at elegosoft.com > >> To: jay.krell at cornell.edu > >> Subject: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: > >> release engineering: build release_CM3_5_8_RC5 now? > >> > >> Quoting Olaf Wagner : > >> > >> > The build has finished, but most of the SOLgnu archives seem to be broken: > >> > > >> > > >> http://hudson.modula3.com:8080/view/test-install/job/cm3-test-install-SOLgnu/7/testReport/ > >> > > >> > Any ideas why the .M3SHIP files are missing just on this target? > >> > >> The log shows that package building just stopped after this failure > >> in cvsup: > >> > >> === package m3-tools/cvsup/suplib === > >> +++ cm3 -build > >> -DROOT='/home/hudson/workspace/cm3-makedist-SOLgnu/cm3' > >> -DCM3_VERSION_TEXT='5.8.5' -DCM3_VERSION_NUMBER='050805' > >> -DCM3_LAST_CHANGED='2010-04-11' $RARGS && cm3 -ship $RARGS > >> -DROOT='/home/hudson/workspace/cm3-makedist-SOLgnu/cm3' > >> -DCM3_VERSION_TEXT='5.8.5' -DCM3_VERSION_NUMBER='050805' > >> -DCM3_LAST_CHANGED='2010-04-11' +++ > >> Undefined first referenced > >> symbol in file > >> inflate GzipRd.mo > >> deflateEnd GzipWr.mo > >> inflateEnd GzipRd.mo > >> deflate GzipWr.mo > >> deflateInit_ Ugzip.mo > >> inflateInit_ Ugzip.mo > >> ld: fatal: Symbol referencing errors. No output written to libsuplib.so.5 > >> collect2: ld returned 1 exit status > >> make_lib => 1 > >> librarian failed building: suplib > >> > >> And the .deb package is broken because the Sun tar does not understand > >> the -z option you seem to use... > >> > >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Apr 14 18:59:15 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 14 Apr 2010 16:59:15 +0000 Subject: [M3devel] more release build problems, was: RE: release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? In-Reply-To: References: <20100411171933.szof1k9n2ss48sg8@mail.elegosoft.com>, , ,,,,<20100412131311.5ax5opbuskcw00sk@mail.elegosoft.com>, , ,,,,, , , , ,,,,<20100412170548.o3go4tu8ys4wgwo4@mail.elegosoft.com>, , ,,,,,,, , , ,,, ,,, ,,<20100413171231.bvpqvjz0g0s08k4o@mail.elegosoft.com>, ,,<20100413205035.s01zgk7nk4gggkso@mail.elegosoft.com>, ,,<20100413224251.m5n8tfabk004gc40@mail.elegosoft.com>, ,,, ,,<20100414130624.ej61zwd0dcg0w848@mail.elegosoft.com>, ,,<20100414131755.y55odckn404ws80c@mail.elegosoft.com>, ,,, , , <20100414161043.xqhxn8nr40cockko@mail.elegosoft.com>, , , Message-ID: pattern matching has some other odd problem, though this could be something in head or my machine: new source -> compiling regex.i3 "../src/regex.i3", line 20: Could not find a legal alignment for the packed type . it's just: regmatch_t = RECORD rm_so: off_t; rm_eo: off_t; END; though again, this is head and SOLsun. - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com Date: Wed, 14 Apr 2010 16:48:04 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] more release build problems, was: RE: release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? postgres95/test and odbc/test I added filtering to match the package, should help. That's still not everything. The m3core error is odd. The cvsup one about merger.tmpl also. - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com Date: Wed, 14 Apr 2010 16:28:48 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] more release build problems, was: RE: release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? This will help but more looking ineeded. C:\dev2\cm3.release_branch_cm3_5_8\m3-obliq>cvs -z3 commit -m "acceptable hack for release branch, don't put in head" obliqbinanim/src/m3makefile obliqbinui/src/m3makefile /usr/cvs/cm3/m3-obliq/obliqbinanim/src/m3makefile,v <-- obliqbinanim/src/m3makefile new revision: 1.1.1.1.8.2; previous revision: 1.1.1.1.8.1 /usr/cvs/cm3/m3-obliq/obliqbinui/src/m3makefile,v <-- obliqbinui/src/m3makefile new revision: 1.1.1.1.8.2; previous revision: 1.1.1.1.8.1 - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com CC: m3devel at elegosoft.com Subject: RE: more release build problems, was: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? Date: Wed, 14 Apr 2010 16:20:39 +0000 er. wait, that function is in release though. - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com CC: m3devel at elegosoft.com Subject: RE: more release build problems, was: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? Date: Wed, 14 Apr 2010 16:19:32 +0000 > "HasTrestle" My fault. - Jay > Date: Wed, 14 Apr 2010 16:10:43 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: more release build problems, was: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? > > Quoting Jay K : > > > Olaf, something I don't understand is why the distribution building > > is a separate Hudson task. > > > > Or more specifically, why these don't just run "all the time", > > either once a day, or after checkins, or something like that. > > Because it is a considerable load and we build a fixed (frozen) > configuration with it. > > Once this release is out, we may try to build packages once a day, > as tinderbox did/does. > > > Perhaps this stuff was occuring but I wasn't noticing the failures? > > I do look sometimes but not enough. > > We just haven't looked. Breakage can be seen at > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLgnu/ > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLgnu/lastBuild/testReport/ > > m3core installation fails, too: > > "/home/hudson/workspace/cm3-test-all-pkgs-SOLgnu/cm3/m3-libs/m3core/SOLgnu/.M3SHIP", line 4: quake runtime error: unable to copy "libm3core.so.5" to "/home/hudson/work/cm3-inst/ssol/last-ok/lib/libm3core.so.5": > errno=2 > libm3core.so.5 Fatal Error: package build failed > > I'll try to improve the checks for serious failures before the next release. > > Olaf > > > > - Jay > > > > > > > > From: jay.krell at cornell.edu > > To: wagner at elegosoft.com > > Subject: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: > > release engineering: build release_CM3_5_8_RC5 now? > > Date: Wed, 14 Apr 2010 12:55:23 +0000 > > > > > > > > For cvsup/zlib: > > The libz hack for Solaris wasn't in release. > > I noticed and fixed another minor problem. > > > > > > Try these files: > > > > > > scripts/branch.quake > > m3-tools/cvsup/quake/cvsup.quake > > > > > > There is also a more conservative fix if you just take > > part of the m3-tools/m3-tools/cvsup/quake/cvsup.quake change. > > Just adding SOLgnu and SOLsun to the list of platforms to check. > > > > > > - Jay > > > > > > > > > > From: jay.krell at cornell.edu > > To: wagner at elegosoft.com > > Subject: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: > > release engineering: build release_CM3_5_8_RC5 now? > > Date: Wed, 14 Apr 2010 11:55:46 +0000 > > > > > > > > I commited a simple untested fix for the tar -z problem. > > Need a bit longer on cvsup/zlib. > > > > - Jay > > > > > > > > > > From: jay.krell at cornell.edu > > To: wagner at elegosoft.com > > Subject: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: > > release engineering: build release_CM3_5_8_RC5 now? > > Date: Wed, 14 Apr 2010 11:47:47 +0000 > > > > > > > > Arg. First is something to do with libz. I thought I actually built > > cvsup at least once on Solaris. > > Granted, I've definitely noticed that machine is slow, been > > testing Posix stuff lately, but Darwin/amd64 and Linux/x86.. > > > > We can either use /usr/sfw/bin/gtar if it exists (it does, Sun puts > > it there), or use tar followed by gzip (optionally with a pipe). > > tar + gzip is presumably more portable. > > > > - Jay > > > >> Date: Wed, 14 Apr 2010 13:17:55 +0200 > >> From: wagner at elegosoft.com > >> To: jay.krell at cornell.edu > >> Subject: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: > >> release engineering: build release_CM3_5_8_RC5 now? > >> > >> Quoting Olaf Wagner : > >> > >> > The build has finished, but most of the SOLgnu archives seem to be broken: > >> > > >> > > >> http://hudson.modula3.com:8080/view/test-install/job/cm3-test-install-SOLgnu/7/testReport/ > >> > > >> > Any ideas why the .M3SHIP files are missing just on this target? > >> > >> The log shows that package building just stopped after this failure > >> in cvsup: > >> > >> === package m3-tools/cvsup/suplib === > >> +++ cm3 -build > >> -DROOT='/home/hudson/workspace/cm3-makedist-SOLgnu/cm3' > >> -DCM3_VERSION_TEXT='5.8.5' -DCM3_VERSION_NUMBER='050805' > >> -DCM3_LAST_CHANGED='2010-04-11' $RARGS && cm3 -ship $RARGS > >> -DROOT='/home/hudson/workspace/cm3-makedist-SOLgnu/cm3' > >> -DCM3_VERSION_TEXT='5.8.5' -DCM3_VERSION_NUMBER='050805' > >> -DCM3_LAST_CHANGED='2010-04-11' +++ > >> Undefined first referenced > >> symbol in file > >> inflate GzipRd.mo > >> deflateEnd GzipWr.mo > >> inflateEnd GzipRd.mo > >> deflate GzipWr.mo > >> deflateInit_ Ugzip.mo > >> inflateInit_ Ugzip.mo > >> ld: fatal: Symbol referencing errors. No output written to libsuplib.so.5 > >> collect2: ld returned 1 exit status > >> make_lib => 1 > >> librarian failed building: suplib > >> > >> And the .deb package is broken because the Sun tar does not understand > >> the -z option you seem to use... > >> > >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Apr 14 18:51:40 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 14 Apr 2010 16:51:40 +0000 Subject: [M3devel] hidden interface vs. public Interface? hidden isn't hidden? In-Reply-To: <962394.19120.qm@web23606.mail.ird.yahoo.com> References: <8D709810-3ED8-4911-8D72-1E27564C8E60@cs.purdue.edu>, <962394.19120.qm@web23606.mail.ird.yahoo.com> Message-ID: Daniel, "interface" and "Interface" aren't filenames. There's no issue regarding file name lengths and file system case sensitivity. I can see that "interface" results in "hidden" in the .m3exports file, at least. There are (many) parts of the system that I'm unaware how they work. Like, does importing just read the .m3x file, or not? Hopefully yes, because it is very efficiently encoded. But I don't know. - Jay > Date: Wed, 14 Apr 2010 16:40:02 +0000 > From: dabenavidesd at yahoo.es > To: wagner at elegosoft.com; hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] hidden interface vs. public Interface? hidden isn't hidden? > > Hi all: > there is a quake directive to export or hide interfaces to packages in cm3 this is from the DEC SRC packages and later pm3, heck the information is the same in all: > http://modula3.com/cm3/doc/help/cm3/m3build/hiding.html > http://cs.wheaton.edu/~cgray/misc/m3/pm3pkg/m3build/src/html/hiding.html > http://www.cs.arizona.edu/~collberg/Research/Modula-3/modula-3/html/m3build/hiding.html > > Please note they mention they accept capitalization convention in commands initial letter but partly to support old style m3makefiles so they provide that to clarify better > > I think you can try with > export_interface("Utime") > and to check capitalization convention with > /* interface("Utime")*/ > Interface("Utime") > export_interface("Utime") > > I remember there are some issues tough if the Unix file has owner only read permissions because the file will be exported as it is so other users included m3browser won't be able to read the file (for instance if you exported as root user and reading from the web in m3browser), same sort of things happens in NT386. > > Though in the above links mention they had this convention of uppercase first 'i' of Interface("Utime") > > I know related examples of this kind of missing of meaning, as as source directory called 'SRC' is not accepted (i.e it doesn't find source directory) in Unix platforms but it was accepted in NT386 (in DEC SRC M3, i.e it builds) perhaps because of capital letter symbols (in)discrimination in terminal platforms I guess (I'm aware unix make looks for Makefile and if not for makefile). > Now I don't know what was is the case in M3/PC Klagenfurt (but as I see the the m3makefiles they had in M3PC 1994 release are C preprocessor directives with special function names a kind of similar to quake and mostly beginning in capital letters) port because it was a DOS platform and they wrote a shell into which can build programs (they didn't have m3make DEC SRC program which because it worked with unix make), I know the long names are ignored in DOS terminals (they substitute the last part with a ~) but they sort of fixed this behavior in the builder/shell they wrote using a name map see: http://web.archive.org/web/20000520073936/www.ifi.uni-klu.ac.at/Modula-3/m3pc/m3pc.html > > Thanks, I hope it helps > > --- El mi?, 14/4/10, Tony Hosking escribi?: > > > De: Tony Hosking > > Asunto: Re: [M3devel] hidden interface vs. public Interface? hidden isn't hidden? > > Para: "Olaf Wagner" > > CC: m3devel at elegosoft.com > > Fecha: mi?rcoles, 14 de abril, 2010 09:22 > > This being hidden *source* files are > > not shipped. > > I'm pretty sure that is still the behaviour. > > Jay, is it possible that you had a source file left behind > > from previous install? > > > > On 14 Apr 2010, at 07:01, Olaf Wagner wrote: > > > > > Quoting Jay K : > > > > > >> > > >> I tried changing from Interface("Utime") to > > interface("Utime"). > > >> > > >> Now, it turns out, that is a mistake > > anyway, there are still uses, and they aren't going > > away. > > >> > > >> But even so, this change doesn't do what it is > > supposed to. > > >> Utime gets marked "hidden" in the .M3EXPORTS > > files. > > >> I haven't yet decipered the .m3x file. > > >> I'm still able to build clients e.g. > > m3-games/tetris. > > >> I'm certain I'm using the updated one. I even rm > > -rf /cm3/pkg/m3core. > > >> > > >> It seems "hidden" doesn't work? > > >> > > >> I'll have to dig into the .m3x file I think. > > > > > > I remember that in the SRC system, hidden files > > weren't shipped at all > > > to the global package pool. Critical Mass changed > > that, because hey > > > wanted the source to be available for browsing. > > > > > > I always assumed that the compiler was able to hnour > > the hidden state > > > of the interface nonetheless. > > > > > > If it doesn't work, we should fix 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 > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Apr 15 08:45:48 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 15 Apr 2010 06:45:48 +0000 Subject: [M3devel] Modula-3/C interop in Date/Time? Message-ID: Is this legal/correct? Date.i3: TYPE TimeZone <: REFANY; VAR Local, UTC: TimeZone; (* granted, will maybe change these to extern *) Date.m3:? REVEAL TimeZone = BRANDED "Date.TimeZone" REF INTEGER; ? DatePosixC.c: static const int Local = 0; static const int UTC = 1; extern const int const * const Date__Local = &Local; extern const int const * const Date__UTC = &UTC; ? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Apr 15 14:18:44 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 15 Apr 2010 12:18:44 +0000 Subject: [M3devel] date/time stuff In-Reply-To: References: <20100415114428.52D0D2474004@birch.elegosoft.com>, Message-ID: I still have small lingering concerns here. - when to call tzset? Historically we called at in the Posix version startup only. I believe localtime implicitcally calls tzset, so we kind of had it backwards? - foo vs. foo_r? I changed any to _r. However there are differences relative, again, to tzset. It seems to me, program can be long running, can span a timezone change. Calling tzset just at startup, not great. - So maybe a better approach is DisableScheduling/EnableScheduling Don't use the _r functions? and/or call tzset more often? - I think I should probably introduce an "idealized" "DatePosix.T" just containing INTEGERs or LONGINTs and no subranges. Besides making the layout totally clear, unlike today, that will also cause subrange checks when the Modula-3 code copies the C values out. Today there are no subrange checks. One needs to be careful defining the ranges, due to various "leap" conditions (not just days, but also seconds, etc.) - I have not run tests that span timezone changes. I think that should be done. It's not difficult actually. Just put an infinite loop around p235 and require user to press enter between iterations, meanwhile changing the system clock/timezone. I can get to that within a week. - There is some possibility here of sharing implementation with Win32! ANSI C has localtime/gmtime, of course and msvcr*.dll do expose daylight, tzname[]. Possibly we can have just one "Posix" implementation. Instead of today's three implementations. - Jay From: jay.krell at cornell.edu To: jkrell at elego.de; m3commit at elegosoft.com Date: Thu, 15 Apr 2010 11:49:09 +0000 Subject: Re: [M3commit] CVS Update: cm3 diff attached > Date: Thu, 15 Apr 2010 13:44:28 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/04/15 13:44:28 > > Modified files: > cm3/m3-libs/m3core/src/: m3core.h > cm3/m3-libs/m3core/src/time/POSIX/: DatePosix.m3 DatePosixC.c > TimePosix.i3 TimePosix.m3 > TimePosixC.c m3makefile > cm3/m3-libs/m3core/src/unix/: m3makefile > cm3/m3-libs/m3core/src/unix/Common/: Unix.i3 Utime.i3 UtimeC.c > Utypes.i3 > Added files: > cm3/m3-libs/m3core/src/time/POSIX/: DatePosix.i3 > > Log message: > eliminate struct_tm (somewhat platform specific) > eliminate struct_timeval (somewhat platform specific) > eliminate FDSet (somewhat platform specific) > eliminate MAX_FDSET (somewhat platform specific) > eliminate lots of functions from Utime > i.e. functions that use those types, like gettimeofday, localtime, gmtime > functions that were used only in m3core/src/time/*.m3 like get_timezone, altzone > > eliminate "all" the m3core/src/unix platform dependent directories *except* > Solaris/sparc32 (SOLgnu/SOLsun) for stack walking support > uin-common vs. uin-len > > change time_t to be 64bits for all platforms > but underlying implementation still needs work (elaborated below) > > tested on SOLgnu, AMD64_DARWIN, LINUXLIBC6 > It compiles and the assertions all hold. > Local and utc data appears correct, cross checking with date and date -u, including > setting Linux/x86 and Solaris/sparc32 system clocks back to Jan 1 2010. > Did not test functionaly on Darwin or any BSD (but note that Linux uses the BSD code). > > still to do: > use 64bit time_t code from http://code.google.com/p/y2038/ > combine some of lingering code in UtimeC.c into Time/DatePosixC.c, as static functions > We can actually add stuff back like localtime/gmtime trafficing in 64bit time_t, > as long as we use our own carefully controlled/copied types (i.e. omit the > extra two fields in struct tm). Just as well as we can provide gettimeofday, select. If we must. > Maybe test on Darwin, *BSD, Cygwin, Interix, etc. > Test in other timezones. > Enable a regularly run test? > Consider relayout Date.T to it doesn't have padding in the middle or perhaps anywhere. > (Hard to avoid if there are subranges, will be padded at least at end.) > > We can't achieve 64bit gettimeofday or file timestamps beyond year 2038 > but if you fill in a Date.T with year > 2038, that can be useful and be made > to work. It should roundtrip with Time.T and be printable. > > structure is a little odd > DatePosix.i3, TimePosix.i3 describe C code > DatePosix.m3, TimePosix.m3 expose Date, Time, call into DatePosix, TimePosix > This is just to reuse existing names or name patterns. > We could just as well introduce new interfaes TimeC, DateC, TimeInternal, DateTimeInternal, etc. > > Note: This also fixes the UTC timezone on Solaris, Interix, HP-UX, Cygwin, which appear to have been historically broken. > > Note: This also uncovered that my Solaris clock was behind by a few minutes. > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 1.txt URL: From jay.krell at cornell.edu Thu Apr 15 15:48:04 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 15 Apr 2010 13:48:04 +0000 Subject: [M3devel] date/time stuff In-Reply-To: References: <20100415114428.52D0D2474004@birch.elegosoft.com>, Message-ID: I forgot to mention another old bug I noticed here: they never check the return value of localtime/localtime_r/gmtime/gmtime_r. It is NULL for error. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Subject: RE: date/time stuff Date: Thu, 15 Apr 2010 13:47:03 +0000 Something went very wrong in the history here. Long ago. Not today. I think we never got the 5.1 changes out of a branch, or something. In version 1.2 I accidentally did copy them out of the branch somehow, and then in 1.3 I put it back, since I wasn't intending to do that. I don't know how I would have gotten that content. Maybe I scrolled down in the cvsweb and selected what I thought was previous, as part of editing/reverting my work. At the time now way I would have used cvs upd -r. I didn't learn till much later. See http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/time/POSIX/DatePosix.m3.diff?r1=1.1;r2=1.3 1.1 and 1.3 are identical. 1.1 to 1.4 http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/time/POSIX/DatePosix.m3.diff?r1=1.1;r2=1.4 is the change I was after. That leaves me uncertain which historical behavior to aim for. :( Need to write more tests.. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Subject: date/time stuff Date: Thu, 15 Apr 2010 12:18:44 +0000 I still have small lingering concerns here. - when to call tzset? Historically we called at in the Posix version startup only. I believe localtime implicitcally calls tzset, so we kind of had it backwards? - foo vs. foo_r? I changed any to _r. However there are differences relative, again, to tzset. It seems to me, program can be long running, can span a timezone change. Calling tzset just at startup, not great. - So maybe a better approach is DisableScheduling/EnableScheduling Don't use the _r functions? and/or call tzset more often? - I think I should probably introduce an "idealized" "DatePosix.T" just containing INTEGERs or LONGINTs and no subranges. Besides making the layout totally clear, unlike today, that will also cause subrange checks when the Modula-3 code copies the C values out. Today there are no subrange checks. One needs to be careful defining the ranges, due to various "leap" conditions (not just days, but also seconds, etc.) - I have not run tests that span timezone changes. I think that should be done. It's not difficult actually. Just put an infinite loop around p235 and require user to press enter between iterations, meanwhile changing the system clock/timezone. I can get to that within a week. - There is some possibility here of sharing implementation with Win32! ANSI C has localtime/gmtime, of course and msvcr*.dll do expose daylight, tzname[]. Possibly we can have just one "Posix" implementation. Instead of today's three implementations. - Jay From: jay.krell at cornell.edu To: jkrell at elego.de; m3commit at elegosoft.com Date: Thu, 15 Apr 2010 11:49:09 +0000 Subject: Re: [M3commit] CVS Update: cm3 diff attached > Date: Thu, 15 Apr 2010 13:44:28 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/04/15 13:44:28 > > Modified files: > cm3/m3-libs/m3core/src/: m3core.h > cm3/m3-libs/m3core/src/time/POSIX/: DatePosix.m3 DatePosixC.c > TimePosix.i3 TimePosix.m3 > TimePosixC.c m3makefile > cm3/m3-libs/m3core/src/unix/: m3makefile > cm3/m3-libs/m3core/src/unix/Common/: Unix.i3 Utime.i3 UtimeC.c > Utypes.i3 > Added files: > cm3/m3-libs/m3core/src/time/POSIX/: DatePosix.i3 > > Log message: > eliminate struct_tm (somewhat platform specific) > eliminate struct_timeval (somewhat platform specific) > eliminate FDSet (somewhat platform specific) > eliminate MAX_FDSET (somewhat platform specific) > eliminate lots of functions from Utime > i.e. functions that use those types, like gettimeofday, localtime, gmtime > functions that were used only in m3core/src/time/*.m3 like get_timezone, altzone > > eliminate "all" the m3core/src/unix platform dependent directories *except* > Solaris/sparc32 (SOLgnu/SOLsun) for stack walking support > uin-common vs. uin-len > > change time_t to be 64bits for all platforms > but underlying implementation still needs work (elaborated below) > > tested on SOLgnu, AMD64_DARWIN, LINUXLIBC6 > It compiles and the assertions all hold. > Local and utc data appears correct, cross checking with date and date -u, including > setting Linux/x86 and Solaris/sparc32 system clocks back to Jan 1 2010. > Did not test functionaly on Darwin or any BSD (but note that Linux uses the BSD code). > > still to do: > use 64bit time_t code from http://code.google.com/p/y2038/ > combine some of lingering code in UtimeC.c into Time/DatePosixC.c, as static functions > We can actually add stuff back like localtime/gmtime trafficing in 64bit time_t, > as long as we use our own carefully controlled/copied types (i.e. omit the > extra two fields in struct tm). Just as well as we can provide gettimeofday, select. If we must. > Maybe test on Darwin, *BSD, Cygwin, Interix, etc. > Test in other timezones. > Enable a regularly run test? > Consider relayout Date.T to it doesn't have padding in the middle or perhaps anywhere. > (Hard to avoid if there are subranges, will be padded at least at end.) > > We can't achieve 64bit gettimeofday or file timestamps beyond year 2038 > but if you fill in a Date.T with year > 2038, that can be useful and be made > to work. It should roundtrip with Time.T and be printable. > > structure is a little odd > DatePosix.i3, TimePosix.i3 describe C code > DatePosix.m3, TimePosix.m3 expose Date, Time, call into DatePosix, TimePosix > This is just to reuse existing names or name patterns. > We could just as well introduce new interfaes TimeC, DateC, TimeInternal, DateTimeInternal, etc. > > Note: This also fixes the UTC timezone on Solaris, Interix, HP-UX, Cygwin, which appear to have been historically broken. > > Note: This also uncovered that my Solaris clock was behind by a few minutes. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Apr 15 15:47:03 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 15 Apr 2010 13:47:03 +0000 Subject: [M3devel] date/time stuff In-Reply-To: References: <20100415114428.52D0D2474004@birch.elegosoft.com>, Message-ID: Something went very wrong in the history here. Long ago. Not today. I think we never got the 5.1 changes out of a branch, or something. In version 1.2 I accidentally did copy them out of the branch somehow, and then in 1.3 I put it back, since I wasn't intending to do that. I don't know how I would have gotten that content. Maybe I scrolled down in the cvsweb and selected what I thought was previous, as part of editing/reverting my work. At the time now way I would have used cvs upd -r. I didn't learn till much later. See http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/time/POSIX/DatePosix.m3.diff?r1=1.1;r2=1.3 1.1 and 1.3 are identical. 1.1 to 1.4 http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/time/POSIX/DatePosix.m3.diff?r1=1.1;r2=1.4 is the change I was after. That leaves me uncertain which historical behavior to aim for. :( Need to write more tests.. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Subject: date/time stuff Date: Thu, 15 Apr 2010 12:18:44 +0000 I still have small lingering concerns here. - when to call tzset? Historically we called at in the Posix version startup only. I believe localtime implicitcally calls tzset, so we kind of had it backwards? - foo vs. foo_r? I changed any to _r. However there are differences relative, again, to tzset. It seems to me, program can be long running, can span a timezone change. Calling tzset just at startup, not great. - So maybe a better approach is DisableScheduling/EnableScheduling Don't use the _r functions? and/or call tzset more often? - I think I should probably introduce an "idealized" "DatePosix.T" just containing INTEGERs or LONGINTs and no subranges. Besides making the layout totally clear, unlike today, that will also cause subrange checks when the Modula-3 code copies the C values out. Today there are no subrange checks. One needs to be careful defining the ranges, due to various "leap" conditions (not just days, but also seconds, etc.) - I have not run tests that span timezone changes. I think that should be done. It's not difficult actually. Just put an infinite loop around p235 and require user to press enter between iterations, meanwhile changing the system clock/timezone. I can get to that within a week. - There is some possibility here of sharing implementation with Win32! ANSI C has localtime/gmtime, of course and msvcr*.dll do expose daylight, tzname[]. Possibly we can have just one "Posix" implementation. Instead of today's three implementations. - Jay From: jay.krell at cornell.edu To: jkrell at elego.de; m3commit at elegosoft.com Date: Thu, 15 Apr 2010 11:49:09 +0000 Subject: Re: [M3commit] CVS Update: cm3 diff attached > Date: Thu, 15 Apr 2010 13:44:28 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/04/15 13:44:28 > > Modified files: > cm3/m3-libs/m3core/src/: m3core.h > cm3/m3-libs/m3core/src/time/POSIX/: DatePosix.m3 DatePosixC.c > TimePosix.i3 TimePosix.m3 > TimePosixC.c m3makefile > cm3/m3-libs/m3core/src/unix/: m3makefile > cm3/m3-libs/m3core/src/unix/Common/: Unix.i3 Utime.i3 UtimeC.c > Utypes.i3 > Added files: > cm3/m3-libs/m3core/src/time/POSIX/: DatePosix.i3 > > Log message: > eliminate struct_tm (somewhat platform specific) > eliminate struct_timeval (somewhat platform specific) > eliminate FDSet (somewhat platform specific) > eliminate MAX_FDSET (somewhat platform specific) > eliminate lots of functions from Utime > i.e. functions that use those types, like gettimeofday, localtime, gmtime > functions that were used only in m3core/src/time/*.m3 like get_timezone, altzone > > eliminate "all" the m3core/src/unix platform dependent directories *except* > Solaris/sparc32 (SOLgnu/SOLsun) for stack walking support > uin-common vs. uin-len > > change time_t to be 64bits for all platforms > but underlying implementation still needs work (elaborated below) > > tested on SOLgnu, AMD64_DARWIN, LINUXLIBC6 > It compiles and the assertions all hold. > Local and utc data appears correct, cross checking with date and date -u, including > setting Linux/x86 and Solaris/sparc32 system clocks back to Jan 1 2010. > Did not test functionaly on Darwin or any BSD (but note that Linux uses the BSD code). > > still to do: > use 64bit time_t code from http://code.google.com/p/y2038/ > combine some of lingering code in UtimeC.c into Time/DatePosixC.c, as static functions > We can actually add stuff back like localtime/gmtime trafficing in 64bit time_t, > as long as we use our own carefully controlled/copied types (i.e. omit the > extra two fields in struct tm). Just as well as we can provide gettimeofday, select. If we must. > Maybe test on Darwin, *BSD, Cygwin, Interix, etc. > Test in other timezones. > Enable a regularly run test? > Consider relayout Date.T to it doesn't have padding in the middle or perhaps anywhere. > (Hard to avoid if there are subranges, will be padded at least at end.) > > We can't achieve 64bit gettimeofday or file timestamps beyond year 2038 > but if you fill in a Date.T with year > 2038, that can be useful and be made > to work. It should roundtrip with Time.T and be printable. > > structure is a little odd > DatePosix.i3, TimePosix.i3 describe C code > DatePosix.m3, TimePosix.m3 expose Date, Time, call into DatePosix, TimePosix > This is just to reuse existing names or name patterns. > We could just as well introduce new interfaes TimeC, DateC, TimeInternal, DateTimeInternal, etc. > > Note: This also fixes the UTC timezone on Solaris, Interix, HP-UX, Cygwin, which appear to have been historically broken. > > Note: This also uncovered that my Solaris clock was behind by a few minutes. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Apr 15 16:43:23 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 15 Apr 2010 14:43:23 +0000 Subject: [M3devel] deleting most of m3core/src/unix? Message-ID: Ok..maybe now time to delete all of m3core/src/unix except for uin-*, Common, and part of solaris-2-x? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Apr 15 18:55:52 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 15 Apr 2010 12:55:52 -0400 Subject: [M3devel] Modula-3/C interop in Date/Time? In-Reply-To: References: Message-ID: <7C7408D0-9A40-4988-BADA-A9FD8C15D388@cs.purdue.edu> Excepting that INTEGER is not the same as int on 64-bit platforms. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 15 Apr 2010, at 02:45, Jay K wrote: > Is this legal/correct? > > > Date.i3: > TYPE TimeZone <: REFANY; > VAR Local, UTC: TimeZone; (* granted, will maybe change these to extern *) > > > Date.m3:? > REVEAL TimeZone = BRANDED "Date.TimeZone" REF INTEGER; > ? > > DatePosixC.c: > static const int Local = 0; > static const int UTC = 1; > extern const int const * const Date__Local = &Local; > extern const int const * const Date__UTC = &UTC; > ? > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Apr 15 23:26:06 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 15 Apr 2010 21:26:06 +0000 Subject: [M3devel] Modula-3/C interop in Date/Time? In-Reply-To: <7C7408D0-9A40-4988-BADA-A9FD8C15D388@cs.purdue.edu> References: , <7C7408D0-9A40-4988-BADA-A9FD8C15D388@cs.purdue.edu> Message-ID: Oops, right, of course. Important to get the things right I know to keep the question clear/narrow. - Jay From: hosking at cs.purdue.edu Date: Thu, 15 Apr 2010 12:55:52 -0400 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] Modula-3/C interop in Date/Time? Excepting that INTEGER is not the same as int on 64-bit platforms. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 15 Apr 2010, at 02:45, Jay K wrote: Is this legal/correct? Date.i3: TYPE TimeZone <: REFANY; VAR Local, UTC: TimeZone; (* granted, will maybe change these to extern *) Date.m3:? REVEAL TimeZone = BRANDED "Date.TimeZone" REF INTEGER; ? DatePosixC.c: static const int Local = 0; static const int UTC = 1; extern const int const * const Date__Local = &Local; extern const int const * const Date__UTC = &UTC; ? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcolebur at SCIRES.COM Fri Apr 16 00:10:44 2010 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Thu, 15 Apr 2010 18:10:44 -0400 Subject: [M3devel] Modula-3/C interop in Date/Time? In-Reply-To: References: , <7C7408D0-9A40-4988-BADA-A9FD8C15D388@cs.purdue.edu> Message-ID: Jay: I?m still catching up after being in hospital, but noticed you are working on the Date.i3/m3 interface and module. There is a problem that I?d like to post on the newsgroup that may be related. I?m not sure if the problem is due to the way Date.i3/m3 is coded, or perhaps a problem in the network objects stub generator, but I thought whilst you are looking at Date.i3/m3 something might trigger in your mind about how to fix the problem. I have several interfaces that export a Network Object. Of course, these get processed by the network objects stub generator at compile time. For some of these, the generated files fail to compile due to Date.i3 not being listed in the IMPORT list. Since these offending modules are generated at compile time, it?s not a programming error in the new source package that is being compiled. The way I work around the problem is by editing the generated files after the compile fails. Namely, I go to the target folder (in this case NT386) and edit the generated m3 files by adding ?IMPORT Date;?, then recompile and all is well. Of course, the next time you erase the target folder, change the underlying interface, or run ?cm3 -clean?, the generated file has to be created again and you have to go thru the compile-edit-compile cycle again to repair the problem. If you are delivering source code to a customer, you then have to document the work-around for them so that they can get the package to compile. I reported this problem years ago, but that was back before we were tracking bugs using the new system. It could be that the way Date.i3/m3 is coded is causing the stub generator not to think it needs to import it, or it could be that the stub generator isn?t doing its job right in the first place. Now after saying all this, I know I should provide a concrete example. I?ll have to go back and see if I ever reduced the code to a smaller set that demonstrates the problem. Otherwise, I can?t give anyone the full source code because it was a ?work-for-hire? and I don?t have the right to publish these sources. Let me know if you want a concrete example and I?ll see what I can do. Regards, Randy From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K Sent: Thursday, April 15, 2010 5:26 PM To: Tony Cc: m3devel Subject: Re: [M3devel] Modula-3/C interop in Date/Time? Oops, right, of course. Important to get the things right I know to keep the question clear/narrow. - Jay ________________________________ From: hosking at cs.purdue.edu Date: Thu, 15 Apr 2010 12:55:52 -0400 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] Modula-3/C interop in Date/Time? Excepting that INTEGER is not the same as int on 64-bit platforms. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 15 Apr 2010, at 02:45, Jay K wrote: Is this legal/correct? Date.i3: TYPE TimeZone <: REFANY; VAR Local, UTC: TimeZone; (* granted, will maybe change these to extern *) Date.m3:? REVEAL TimeZone = BRANDED "Date.TimeZone" REF INTEGER; ? DatePosixC.c: static const int Local = 0; static const int UTC = 1; extern const int const * const Date__Local = &Local; extern const int const * const Date__UTC = &UTC; ? - Jay ________________________________ CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This email may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from reviewing, copying, using, disclosing or distributing to others the information in this email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require advance export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Fri Apr 16 00:44:07 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 15 Apr 2010 17:44:07 -0500 Subject: [M3devel] Modula-3/C interop in Date/Time? In-Reply-To: References: Message-ID: <4BC796B7.7090707@lcwb.coop> Since these pointer variables are initialized by C code and their referents are also provided by C code as global variables, shouldn't the type be untraced? I suppose that, since they don't point into the traced heap, the collector implementation we have would quietly ignore them as roots. But that's relying on implementation- dependent information. Also, if someone created a field of type Date.TimeZone, (or an array of them) in a traced-heap-allocated object, which is a perfectly legitimate thing to do, what would our collector do then? Jay K wrote: > Is this legal/correct? > > > Date.i3: > TYPE TimeZone <: REFANY; > VAR Local, UTC: TimeZone; (* granted, will maybe change these to extern *) > > > Date.m3:? > REVEAL TimeZone = BRANDED "Date.TimeZone" REF INTEGER; > ? > > DatePosixC.c: > static const int Local = 0; > static const int UTC = 1; > extern const int const * const Date__Local = &Local; > extern const int const * const Date__UTC = &UTC; > ? > > - Jay From jay.krell at cornell.edu Fri Apr 16 01:13:23 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 15 Apr 2010 23:13:23 +0000 Subject: [M3devel] Modula-3/C interop in Date/Time? In-Reply-To: References: , , <7C7408D0-9A40-4988-BADA-A9FD8C15D388@cs.purdue.edu>, , Message-ID: Randy, I think I understand but yes please commit a small concrete example like in m3-sys/m3tests/src/p2/p237 or such. I think this is a bug in the stub generator. Probably time/date could workaround it with slight restructuring/renaming. But probably should fix the stub generator. While at it, maybe have it stop outputing unused stuff that triggers so many warnings... - Jay From: rcolebur at SCIRES.COM To: m3devel at elegosoft.com Date: Thu, 15 Apr 2010 18:10:44 -0400 Subject: Re: [M3devel] Modula-3/C interop in Date/Time? Jay: I?m still catching up after being in hospital, but noticed you are working on the Date.i3/m3 interface and module. There is a problem that I?d like to post on the newsgroup that may be related. I?m not sure if the problem is due to the way Date.i3/m3 is coded, or perhaps a problem in the network objects stub generator, but I thought whilst you are looking at Date.i3/m3 something might trigger in your mind about how to fix the problem. I have several interfaces that export a Network Object. Of course, these get processed by the network objects stub generator at compile time. For some of these, the generated files fail to compile due to Date.i3 not being listed in the IMPORT list. Since these offending modules are generated at compile time, it?s not a programming error in the new source package that is being compiled. The way I work around the problem is by editing the generated files after the compile fails. Namely, I go to the target folder (in this case NT386) and edit the generated m3 files by adding ?IMPORT Date;?, then recompile and all is well. Of course, the next time you erase the target folder, change the underlying interface, or run ?cm3 ?clean?, the generated file has to be created again and you have to go thru the compile-edit-compile cycle again to repair the problem. If you are delivering source code to a customer, you then have to document the work-around for them so that they can get the package to compile. I reported this problem years ago, but that was back before we were tracking bugs using the new system. It could be that the way Date.i3/m3 is coded is causing the stub generator not to think it needs to import it, or it could be that the stub generator isn?t doing its job right in the first place. Now after saying all this, I know I should provide a concrete example. I?ll have to go back and see if I ever reduced the code to a smaller set that demonstrates the problem. Otherwise, I can?t give anyone the full source code because it was a ?work-for-hire? and I don?t have the right to publish these sources. Let me know if you want a concrete example and I?ll see what I can do. Regards, Randy From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K Sent: Thursday, April 15, 2010 5:26 PM To: Tony Cc: m3devel Subject: Re: [M3devel] Modula-3/C interop in Date/Time? Oops, right, of course. Important to get the things right I know to keep the question clear/narrow. - Jay From: hosking at cs.purdue.edu Date: Thu, 15 Apr 2010 12:55:52 -0400 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] Modula-3/C interop in Date/Time? Excepting that INTEGER is not the same as int on 64-bit platforms. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 15 Apr 2010, at 02:45, Jay K wrote: Is this legal/correct? Date.i3: TYPE TimeZone <: REFANY; VAR Local, UTC: TimeZone; (* granted, will maybe change these to extern *) Date.m3:? REVEAL TimeZone = BRANDED "Date.TimeZone" REF INTEGER; ? DatePosixC.c: static const int Local = 0; static const int UTC = 1; extern const int const * const Date__Local = &Local; extern const int const * const Date__UTC = &UTC; ? - Jay CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This email may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from reviewing, copying, using, disclosing or distributing to others the information in this email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require advance export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Fri Apr 16 00:55:58 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 15 Apr 2010 17:55:58 -0500 Subject: [M3devel] Modula-3/C interop in Date/Time? In-Reply-To: References: , <7C7408D0-9A40-4988-BADA-A9FD8C15D388@cs.purdue.edu> Message-ID: <4BC7997E.5050708@lcwb.coop> Coleburn, Randy wrote: > Jay: > > > > I?m still catching up after being in hospital, but noticed you are > working on the Date.i3/m3 interface and module. > > > > There is a problem that I?d like to post on the newsgroup that may be > related. > > > > I?m not sure if the problem is due to the way Date.i3/m3 is coded, or > perhaps a problem in the network objects stub generator, but I thought > whilst you are looking at Date.i3/m3 something might trigger in your > mind about how to fix the problem. > > > > I have several interfaces that export a Network Object. Of course, > these get processed by the network objects stub generator at compile > time. For some of these, the generated files fail to compile due to > Date.i3 not being listed in the IMPORT list. > > > > Since these offending modules are generated at compile time, it?s not a > programming error in the new source package that is being compiled. > > > > The way I work around the problem is by editing the generated files > after the compile fails. Namely, I go to the target folder (in this > case NT386) and edit the generated m3 files by adding ?IMPORT Date;?, > then recompile and all is well. > > > > Of course, the next time you erase the target folder, change the > underlying interface, or run ?cm3 ?clean?, the generated file has to be > created again and you have to go thru the compile-edit-compile cycle > again to repair the problem. If you are delivering source code to a > customer, you then have to document the work-around for them so that > they can get the package to compile. > > > > I reported this problem years ago, but that was back before we were > tracking bugs using the new system. > > > > It could be that the way Date.i3/m3 is coded is causing the stub > generator not to think it needs to import it, or it could be that the > stub generator isn?t doing its job right in the first place. I can't think of a way this could be anything but a bug in stubgen. The very fact (and only the fact) that the generated stub code refers to Date necessitates the IMPORT Date, regardless of what is coded in interface Date or what within Date is being referred to. Is the reference to Date in the generated stub derived from a reference to Date in the interface that stubgen is processing, or is it produced within stubgen itself? Actually, either way, stubgen should produce the IMPORT. > > > > Now after saying all this, I know I should provide a concrete example. > I?ll have to go back and see if I ever reduced the code to a smaller set > that demonstrates the problem. Otherwise, I can?t give anyone the full > source code because it was a ?work-for-hire? and I don?t have the right > to publish these sources. > > > > Let me know if you want a concrete example and I?ll see what I can do. > > > > Regards, > > Randy > > > > *From:* jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] *On Behalf Of > *Jay K > *Sent:* Thursday, April 15, 2010 5:26 PM > *To:* Tony > *Cc:* m3devel > *Subject:* Re: [M3devel] Modula-3/C interop in Date/Time? > > > > Oops, right, of course. Important to get the things right I know to keep > the question clear/narrow. > > - Jay > > > > ------------------------------------------------------------------------ > > From: hosking at cs.purdue.edu > Date: Thu, 15 Apr 2010 12:55:52 -0400 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Modula-3/C interop in Date/Time? > > Excepting that INTEGER is not the same as int on 64-bit platforms. > > > > Antony Hosking | Associate Professor | Computer Science | Purdue University > > 305 N. University Street | West Lafayette | IN 47907 | USA > > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > > > > > > On 15 Apr 2010, at 02:45, Jay K wrote: > > > > Is this legal/correct? > > > Date.i3: > TYPE TimeZone <: REFANY; > VAR Local, UTC: TimeZone; (* granted, will maybe change these to > extern *) > > > Date.m3:? > REVEAL TimeZone = BRANDED "Date.TimeZone" REF INTEGER; > ? > > DatePosixC.c: > static const int Local = 0; > static const int UTC = 1; > extern const int const * const Date__Local = &Local; > extern const int const * const Date__UTC = &UTC; > ? > > - Jay > > > > > ------------------------------------------------------------------------ > CONFIDENTIALITY NOTICE: This email and any attachments are intended > solely for the use of the named recipient(s). This email may contain > confidential and/or proprietary information of Scientific Research > Corporation. If you are not a named recipient, you are prohibited from > reviewing, copying, using, disclosing or distributing to others the > information in this email and attachments. If you believe you have > received this email in error, please notify the sender immediately and > permanently delete the email, any attachments, and all copies thereof > from any drives or storage media and destroy any printouts of the email > or attachments. > > EXPORT COMPLIANCE NOTICE: This email and any attachments may contain > technical data subject to U.S export restrictions under the > International Traffic in Arms Regulations (ITAR) or the Export > Administration Regulations (EAR). Export or transfer of this technical > data and/or related information to any foreign person(s) or entity(ies), > either within the U.S. or outside of the U.S., may require advance > export authorization by the appropriate U.S. Government agency prior to > export or transfer. In addition, technical data may not be exported or > transferred to certain countries or specified designated nationals > identified by U.S. embargo controls without prior export authorization. > By accepting this email and any attachments, all recipients confirm that > they understand and will comply with all applicable ITAR, EAR and > embargo compliance requirements. From jay.krell at cornell.edu Fri Apr 16 01:17:38 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 15 Apr 2010 23:17:38 +0000 Subject: [M3devel] Modula-3/C interop in Date/Time? In-Reply-To: <4BC796B7.7090707@lcwb.coop> References: , <4BC796B7.7090707@lcwb.coop> Message-ID: Rodney, right, I was wondering about traced vs. untraced also. I think having a traced pointer point outside the traced heap is ok though. The data will never be collected, the pointer never updated. If the untraced data were ever freed (such as e.g. unloading the .dll! Which people usually forget about as a scenario..) then the traced pointers would go stale and there'd be a safety problem. In either case I'm not "rewriting" it, because there is a "unified interface" between Posix and Win32, and I can't make it <*external*> in one but not the other, unless I fork the file, not particularly worthwhile. - Jay > Date: Thu, 15 Apr 2010 17:44:07 -0500 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Modula-3/C interop in Date/Time? > > Since these pointer variables are initialized by > C code and their referents are also provided by C code > as global variables, shouldn't the type be untraced? > > I suppose that, since they don't point into the traced > heap, the collector implementation we have would quietly > ignore them as roots. But that's relying on implementation- > dependent information. > > Also, if someone created a field of type Date.TimeZone, > (or an array of them) in a traced-heap-allocated object, > which is a perfectly legitimate thing to do, what would > our collector do then? > > > > Jay K wrote: > > Is this legal/correct? > > > > > > Date.i3: > > TYPE TimeZone <: REFANY; > > VAR Local, UTC: TimeZone; (* granted, will maybe change these to extern *) > > > > > > Date.m3:? > > REVEAL TimeZone = BRANDED "Date.TimeZone" REF INTEGER; > > ? > > > > DatePosixC.c: > > static const int Local = 0; > > static const int UTC = 1; > > extern const int const * const Date__Local = &Local; > > extern const int const * const Date__UTC = &UTC; > > ? > > > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Apr 16 04:08:35 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 15 Apr 2010 22:08:35 -0400 Subject: [M3devel] Modula-3/C interop in Date/Time? In-Reply-To: References: , <4BC796B7.7090707@lcwb.coop> Message-ID: On 15 Apr 2010, at 19:17, Jay K wrote: > Rodney, right, I was wondering about traced vs. untraced also. I think having a traced pointer point outside the traced heap is ok though. The data will never be collected, the pointer never updated. There are assertions in the @M3paranoid collector that will complain if a reference outside the heap is not to a TEXT literal. Those should be the only ones we see. Correctness dictates that we use UNTRACED references (ADDRESS, UNTRACED REF...) here. > If the untraced data were ever freed (such as e.g. unloading the .dll! Which people usually forget about as a scenario..) then the traced pointers would go stale and there'd be a safety problem. > > > In either case I'm not "rewriting" it, because there is a "unified interface" between Posix and Win32, and I can't make it <*external*> in one but not the other, unless I fork the file, not particularly worthwhile. > > > - Jay > > > Date: Thu, 15 Apr 2010 17:44:07 -0500 > > From: rodney_bates at lcwb.coop > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] Modula-3/C interop in Date/Time? > > > > Since these pointer variables are initialized by > > C code and their referents are also provided by C code > > as global variables, shouldn't the type be untraced? > > > > I suppose that, since they don't point into the traced > > heap, the collector implementation we have would quietly > > ignore them as roots. But that's relying on implementation- > > dependent information. > > > > Also, if someone created a field of type Date.TimeZone, > > (or an array of them) in a traced-heap-allocated object, > > which is a perfectly legitimate thing to do, what would > > our collector do then? > > > > > > > > Jay K wrote: > > > Is this legal/correct? > > > > > > > > > Date.i3: > > & gt; TYPE TimeZone <: REFANY; > > > VAR Local, UTC: TimeZone; (* granted, will maybe change these to extern *) > > > > > > > > > Date.m3:? > > > REVEAL TimeZone = BRANDED "Date.TimeZone" REF INTEGER; > > > ? > > > > > > DatePosixC.c: > > > static const int Local = 0; > > > static const int UTC = 1; > > > extern const int const * const Date__Local = &Local; > > > extern const int const * const Date__UTC = &UTC; > > > ? > > > > > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Apr 16 04:06:14 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 15 Apr 2010 22:06:14 -0400 Subject: [M3devel] Modula-3/C interop in Date/Time? In-Reply-To: <4BC796B7.7090707@lcwb.coop> References: <4BC796B7.7090707@lcwb.coop> Message-ID: Indeed! UNTRACED. On 15 Apr 2010, at 18:44, Rodney M. Bates wrote: > Since these pointer variables are initialized by > C code and their referents are also provided by C code > as global variables, shouldn't the type be untraced? > > I suppose that, since they don't point into the traced > heap, the collector implementation we have would quietly > ignore them as roots. But that's relying on implementation- > dependent information. > > Also, if someone created a field of type Date.TimeZone, > (or an array of them) in a traced-heap-allocated object, > which is a perfectly legitimate thing to do, what would > our collector do then? > > > > Jay K wrote: >> Is this legal/correct? >> >> >> Date.i3: >> TYPE TimeZone <: REFANY; >> VAR Local, UTC: TimeZone; (* granted, will maybe change these to extern *) >> >> >> Date.m3:? >> REVEAL TimeZone = BRANDED "Date.TimeZone" REF INTEGER; >> ? >> >> DatePosixC.c: >> static const int Local = 0; >> static const int UTC = 1; >> extern const int const * const Date__Local = &Local; >> extern const int const * const Date__UTC = &UTC; >> ? >> >> - Jay From jay.krell at cornell.edu Fri Apr 16 06:24:43 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 16 Apr 2010 04:24:43 +0000 Subject: [M3devel] Modula-3/C interop in Date/Time? In-Reply-To: References: , <4BC796B7.7090707@lcwb.coop>, Message-ID: But then unsafe, right? - Jay > From: hosking at cs.purdue.edu > Date: Thu, 15 Apr 2010 22:06:14 -0400 > To: rodney_bates at lcwb.coop > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Modula-3/C interop in Date/Time? > > Indeed! UNTRACED. > > > On 15 Apr 2010, at 18:44, Rodney M. Bates wrote: > > > Since these pointer variables are initialized by > > C code and their referents are also provided by C code > > as global variables, shouldn't the type be untraced? > > > > I suppose that, since they don't point into the traced > > heap, the collector implementation we have would quietly > > ignore them as roots. But that's relying on implementation- > > dependent information. > > > > Also, if someone created a field of type Date.TimeZone, > > (or an array of them) in a traced-heap-allocated object, > > which is a perfectly legitimate thing to do, what would > > our collector do then? > > > > > > > > Jay K wrote: > >> Is this legal/correct? > >> > >> > >> Date.i3: > >> TYPE TimeZone <: REFANY; > >> VAR Local, UTC: TimeZone; (* granted, will maybe change these to extern *) > >> > >> > >> Date.m3:? > >> REVEAL TimeZone = BRANDED "Date.TimeZone" REF INTEGER; > >> ? > >> > >> DatePosixC.c: > >> static const int Local = 0; > >> static const int UTC = 1; > >> extern const int const * const Date__Local = &Local; > >> extern const int const * const Date__UTC = &UTC; > >> ? > >> > >> - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.async.caltech.edu Fri Apr 16 09:00:34 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Fri, 16 Apr 2010 00:00:34 -0700 Subject: [M3devel] Modula-3/C interop in Date/Time? In-Reply-To: References: , <4BC796B7.7090707@lcwb.coop>, Message-ID: <20100416070034.9C0911A20EB@async.async.caltech.edu> I don't think there's anything unsafe about UNTRACED. It's DISPOSE that's unsafe... Mika Jay K writes: >--_cbaca81c-f322-4f31-8684-e7f171e67f3d_ >Content-Type: text/plain; charset="iso-2022-jp" >Content-Transfer-Encoding: 7bit > >But then unsafe, right? > > - Jay > >> From: hosking at cs.purdue.edu >> Date: Thu, 15 Apr 2010 22:06:14 -0400 >> To: rodney_bates at lcwb.coop >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] Modula-3/C interop in Date/Time? >> >> Indeed! UNTRACED. >> >> >> On 15 Apr 2010, at 18:44, Rodney M. Bates wrote: >> >> > Since these pointer variables are initialized by >> > C code and their referents are also provided by C code >> > as global variables, shouldn't the type be untraced? >> > >> > I suppose that, since they don't point into the traced >> > heap, the collector implementation we have would quietly >> > ignore them as roots. But that's relying on implementation- >> > dependent information. >> > >> > Also, if someone created a field of type Date.TimeZone, >> > (or an array of them) in a traced-heap-allocated object, > > which is a perfectly legitimate thing to do, what would >> > our collector do then? >> > >> > >> > >> > Jay K wrote: >> >> Is this legal/correct? >> >> >> >> >> >> Date.i3: >> >> TYPE TimeZone <: REFANY; >> >> VAR Local, UTC: TimeZone; (* granted, will maybe change these to extern *) >> >> >> >> >> >> Date.m3:$B!!(B >> >> REVEAL TimeZone = BRANDED "Date.TimeZone" REF INTEGER; >> >> $B!!(B >> >> >> >> DatePosixC.c: >> >> static const int Local = 0; >> >> static const int UTC = 1; >> >> extern const int const * const Date__Local = &Local; >> >> extern const int const * const Date__UTC = &UTC; >> >> $B!!(B >> >> >> >> - Jay >> > >--_cbaca81c-f322-4f31-8684-e7f171e67f3d_ >Content-Type: text/html; charset="iso-2022-jp" >Content-Transfer-Encoding: 7bit > > > > > >But then unsafe, right?

- Jay

> From: hosking@cs.purdue.edu
> Date: Thu, 15 Apr 2010 22:06:14 -0400
> To: rodney_bates& >#64;lcwb.coop
> CC: m3devel@elegosoft.com
> Subject: Re: [M3devel] Modula-3/C interop in Date/Time?
>
> Indeed! UNTRACED.
>
> < >br>> On 15 Apr 2010, at 18:44, Rodney M. Bates wrote:
>
> > Since these pointer variables are initialized by
> > C code and their referents are also provided by C > code
> > as global variables, shouldn't the type be untraced?
> >
> > I suppose that, since they don't point into the traced
> > heap, the collect >or implementation we have would quietly
> > ignore them as roots. But that's relying on implementation-
> > dependent information.
> >
> > Also, if someon >e created a field of type Date.TimeZone,
> > > ; (or an array of them) in a traced-heap-allocated object,
> > which is a perfectly legitimate thing to do, what would
> > our collector do then?
> >
>> >
> >
> > Jay K wrote:
> >> Is this legal/correct?
> >>
> >>
> >> Date.i3:
> >> TYPE TimeZone > <: REFANY;
> >> VAR Local, UTC: TimeZone; (* granted, will maybe change these to extern *)
> >>
> >>
> >> > Date.m3: 
> >> REVEAL TimeZone = BRANDED "Date.TimeZone" REF INTEGER;
> >>  
> >>
> >> DatePosixC.c:
>> >> static const int Local = 0;
> >> static const int UTC = 1;
> >> extern const int const * const Date__Local = &Local;
> > >> extern const int const * const Dat > e__UTC = &UTC;
> >>  
> >>
> >> - Jay
>
> >--_cbaca81c-f322-4f31-8684-e7f171e67f3d_-- From jay.krell at cornell.edu Fri Apr 16 10:18:29 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 16 Apr 2010 08:18:29 +0000 Subject: [M3devel] Modula-3/C interop in Date/Time? In-Reply-To: <20100416070034.9C0911A20EB@async.async.caltech.edu> References: , , <4BC796B7.7090707@lcwb.coop>, , , , <20100416070034.9C0911A20EB@async.async.caltech.edu> Message-ID: Isn't making them unsafe? ADR? I'll try.. - Jay > To: jay.krell at cornell.edu > Date: Fri, 16 Apr 2010 00:00:34 -0700 > From: mika at async.async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Modula-3/C interop in Date/Time? > > I don't think there's anything unsafe about UNTRACED. > > It's DISPOSE that's unsafe... > > Mika > > Jay K writes: > >--_cbaca81c-f322-4f31-8684-e7f171e67f3d_ > >Content-Type: text/plain; charset="iso-2022-jp" > >Content-Transfer-Encoding: 7bit > > > >But then unsafe, right? > > > > - Jay > > > >> From: hosking at cs.purdue.edu > >> Date: Thu, 15 Apr 2010 22:06:14 -0400 > >> To: rodney_bates at lcwb.coop > >> CC: m3devel at elegosoft.com > >> Subject: Re: [M3devel] Modula-3/C interop in Date/Time? > >> > >> Indeed! UNTRACED. > >> > >> > >> On 15 Apr 2010, at 18:44, Rodney M. Bates wrote: > >> > >> > Since these pointer variables are initialized by > >> > C code and their referents are also provided by C code > >> > as global variables, shouldn't the type be untraced? > >> > > >> > I suppose that, since they don't point into the traced > >> > heap, the collector implementation we have would quietly > >> > ignore them as roots. But that's relying on implementation- > >> > dependent information. > >> > > >> > Also, if someone created a field of type Date.TimeZone, > >> > (or an array of them) in a traced-heap-allocated object, > > > which is a perfectly legitimate thing to do, what would > >> > our collector do then? > >> > > >> > > >> > > >> > Jay K wrote: > >> >> Is this legal/correct? > >> >> > >> >> > >> >> Date.i3: > >> >> TYPE TimeZone <: REFANY; > >> >> VAR Local, UTC: TimeZone; (* granted, will maybe change these to extern *) > >> >> > >> >> > >> >> Date.m3:? > >> >> REVEAL TimeZone = BRANDED "Date.TimeZone" REF INTEGER; > >> >> ? > >> >> > >> >> DatePosixC.c: > >> >> static const int Local = 0; > >> >> static const int UTC = 1; > >> >> extern const int const * const Date__Local = &Local; > >> >> extern const int const * const Date__UTC = &UTC; > >> >> ? > >> >> > >> >> - Jay > >> > > > >--_cbaca81c-f322-4f31-8684-e7f171e67f3d_ > >Content-Type: text/html; charset="iso-2022-jp" > >Content-Transfer-Encoding: 7bit > > > > > > > > > > > >But then unsafe, right?

- Jay

> From: hosking@cs.purdue.edu
> Date: Thu, 15 Apr 2010 22:06:14 -0400
> To: rodney_bates& > >#64;lcwb.coop
> CC: m3devel@elegosoft.com
> Subject: Re: [M3devel] Modula-3/C interop in Date/Time?
>
> Indeed! UNTRACED.
>
> < > >br>> On 15 Apr 2010, at 18:44, Rodney M. Bates wrote:
>
> > Since these pointer variables are initialized by
> > C code and their referents are also provided by C > > code
> > as global variables, shouldn't the type be untraced?
> >
> > I suppose that, since they don't point into the traced
> > heap, the collect > >or implementation we have would quietly
> > ignore them as roots. But that's relying on implementation-
> > dependent information.
> >
> > Also, if someon > >e created a field of type Date.TimeZone,
> > > > ; (or an array of them) in a traced-heap-allocated object,
> > which is a perfectly legitimate thing to do, what would
> > our collector do then?
> >
> >> >
> >
> > Jay K wrote:
> >> Is this legal/correct?
> >>
> >>
> >> Date.i3:
> >> TYPE TimeZone > > <: REFANY;
> >> VAR Local, UTC: TimeZone; (* granted, will maybe change these to extern *)
> >>
> >>
> >> > > Date.m3: 
> >> REVEAL TimeZone = BRANDED "Date.TimeZone" REF INTEGER;
> >>  
> >>
> >> DatePosixC.c:
> >> >> static const int Local = 0;
> >> static const int UTC = 1;
> >> extern const int const * const Date__Local = &Local;
> > > >> extern const int const * const Dat > > e__UTC = &UTC;
> >>  
> >>
> >> - Jay
>
> > > >--_cbaca81c-f322-4f31-8684-e7f171e67f3d_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Fri Apr 16 11:38:14 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 16 Apr 2010 11:38:14 +0200 Subject: [M3devel] release engineering 5.8: trac issue 1005 (open array initializers) Message-ID: <20100416113814.xwn126mk800808kc@mail.elegosoft.com> I'm currently reviewing the open issues again, and came across https://projects.elego.de/cm3/ticket/1005 Not sure if I've asked before, but do we need to solve this for this release? The GC error seems strange: --- ../src/p2/p209/stderr.build 2009-06-29 21:47:53.000000000 +0200 +++ ../src/p2/p209/AMD64_LINUX/stderr.build 2009-07-20 08:17:17.000000000 +0200 @@ -0,0 +1,13 @@ +o is 0x348 +init_pc is 0x0 +bias is 0x5c8 +Target.Address.align is 0x40 +Target.Byte is 0x8 + + +*** +*** runtime error: +*** <*ASSERT*> failed. +*** file "../src/misc/CG.m3", line 1077 +*** + 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 Fri Apr 16 11:45:09 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 16 Apr 2010 11:45:09 +0200 Subject: [M3devel] release engineering 5.8: code generator error for IP address initializers Message-ID: <20100416114509.eh8r662dwss44oo8@mail.elegosoft.com> We also have this error, which should perhaps not be ignored? http://hudson.modula3.com:8080/job/cm3-test-m3tests-AMD64_FREEBSD/lastBuild/testReport/(root)/m3tests/p204__IP_address_initializers 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 jay.krell at cornell.edu Fri Apr 16 11:58:13 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 16 Apr 2010 09:58:13 +0000 Subject: [M3devel] release engineering 5.8: trac issue 1005 (open array initializers) In-Reply-To: <20100416113814.xwn126mk800808kc@mail.elegosoft.com> References: <20100416113814.xwn126mk800808kc@mail.elegosoft.com> Message-ID: I believe Tony removed the print outs but imho they should be left in until the assertion failure is understood and fixed. They try to inform on what is going on when the assertion fails. - Jay > Date: Fri, 16 Apr 2010 11:38:14 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] release engineering 5.8: trac issue 1005 (open array initializers) > > I'm currently reviewing the open issues again, and came across > > https://projects.elego.de/cm3/ticket/1005 > > Not sure if I've asked before, but do we need to solve this for this > release? The GC error seems strange: > > --- ../src/p2/p209/stderr.build 2009-06-29 21:47:53.000000000 +0200 > +++ ../src/p2/p209/AMD64_LINUX/stderr.build 2009-07-20 > 08:17:17.000000000 +0200 > @@ -0,0 +1,13 @@ > +o is 0x348 > +init_pc is 0x0 > +bias is 0x5c8 > +Target.Address.align is 0x40 > +Target.Byte is 0x8 > + > + > +*** > +*** runtime error: > +*** <*ASSERT*> failed. > +*** file "../src/misc/CG.m3", line 1077 > +*** > + > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Apr 16 12:01:30 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 16 Apr 2010 10:01:30 +0000 Subject: [M3devel] release engineering 5.8: code generator error for IP address initializers In-Reply-To: <20100416114509.eh8r662dwss44oo8@mail.elegosoft.com> References: <20100416114509.eh8r662dwss44oo8@mail.elegosoft.com> Message-ID: "aside": http://hudson.modula3.com:8080/job/cm3-test-m3tests-AMD64_FREEBSD/lastBuild/testReport/(root)/m3tests/p206__ARRAY_constructors_in_var_decls_using_named_open_array_types/ http://hudson.modula3.com:8080/job/cm3-test-m3tests-AMD64_FREEBSD/lastBuild/testReport/(root)/m3tests/r004__negative_size_for_an_open_array/ It'd be nice if in Quake we had something regular expression-ish, so that we could factor out the line numbers, such as e.g. to match any decimal number. Maybe just check for lines that start how we expect and cut them off at some position. That might be doable with today's Quake. - Jay > Date: Fri, 16 Apr 2010 11:45:09 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] release engineering 5.8: code generator error for IP address initializers > > We also have this error, which should perhaps not be ignored? > > http://hudson.modula3.com:8080/job/cm3-test-m3tests-AMD64_FREEBSD/lastBuild/testReport/(root)/m3tests/p204__IP_address_initializers > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Fri Apr 16 12:50:48 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 16 Apr 2010 12:50:48 +0200 Subject: [M3devel] release engineering 5.8: code generator error for IP address initializers In-Reply-To: References: <20100416114509.eh8r662dwss44oo8@mail.elegosoft.com> Message-ID: <20100416125048.183752ukg4os0kgk@mail.elegosoft.com> I agree. Regular expressions in quake would be great for regression tests. Perhaps for the next release? Olaf Quoting Jay K : > "aside": > > http://hudson.modula3.com:8080/job/cm3-test-m3tests-AMD64_FREEBSD/lastBuild/testReport/(root)/m3tests/p206__ARRAY_constructors_in_var_decls_using_named_open_array_types/ > > http://hudson.modula3.com:8080/job/cm3-test-m3tests-AMD64_FREEBSD/lastBuild/testReport/(root)/m3tests/r004__negative_size_for_an_open_array/ > > > It'd be nice if in Quake we had something regular expression-ish, so > that we could factor out the line numbers, such as e.g. to match > any decimal number. > > > Maybe just check for lines that start how we expect and cut them off > at some position. > That might be doable with today's Quake. > > > > - Jay > > > >> Date: Fri, 16 Apr 2010 11:45:09 +0200 >> From: wagner at elegosoft.com >> To: m3devel at elegosoft.com >> Subject: [M3devel] release engineering 5.8: code generator error >> for IP address initializers >> >> We also have this error, which should perhaps not be ignored? >> >> http://hudson.modula3.com:8080/job/cm3-test-m3tests-AMD64_FREEBSD/lastBuild/testReport/(root)/m3tests/p204__IP_address_initializers >> >> 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 wagner at elegosoft.com Fri Apr 16 13:09:06 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 16 Apr 2010 13:09:06 +0200 Subject: [M3devel] unused/little used stuff in m3core/unix? Message-ID: <20100416130906.o573xyu9co004gks@mail.elegosoft.com> Quoting Jay K : > Ok on preserving most/all of these but note I'm not keen on > preserving like anything dealing with structs or time_t. > > There are various arguments for/against. > > This "systems" language interoperates well with C, directly, IF you > control the C. > > Thus we have wrappers. We almost never interface directly with "the OS". > > Then again, same is true of C. Actual "kernels" have custom > calling mechanisms, which gets wrapped in C. > > I'm not sure we should provide a general set of wrappers, or leave > it to each user to write his own, > or provide some simple small set. Leaving it to each user is error > prone, granted. > > The historical implementation here was awful and *really* *not* the way. > > The question then is what should the implementation be. One more or less POSIXish API within m3core would be OK with me. It even needs not be complete, but I'd expect some well-known standard functions there. Of course this doesn't answer the question what should be included and what not. Olaf >> Date: Mon, 12 Apr 2010 10:12:12 +0200 >> From: wagner at elegosoft.com >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] unused/little used stuff in m3core/unix? >> >> Quoting Jay K : >> >> > Following are not used: >> > >> > fchmod >> > fchown >> > getpagesize >> > sbrk >> > creat >> > isatty >> > >> > That isn't necessarily all. >> > >> > Some are used only in: >> > >> > C:\dev2\cm3.2\m3-libs\libm3\src\os\POSIX >> > e.g. >> > chdir >> > getdtablesize >> > execve >> > >> > Some are used only in the unused m3-pkgtools directory or by cvsup. >> > e.g. umask >> > >> > These all traffic in pretty "plain" types (e.g. no structs, no >> > time_t). So just keep them all? >> >> Yes. These are standard POSIX or Unix legacy interfaces. >> Do not throw them out. >> >> > Note of course, uses of these somewhat or significantly inhibit >> > porting to native Win32. >> >> As these are POSIX, that is to be expected. >> >> > Account for somewhat arbirary Posix-specific code outside the cm3 tree >> > and err toward wrapping stuff that is easy? >> > >> > Or push the idea that m3core/libm3 are a good (and safe) portability >> > layer and only provide what they need, and >> > gradually move them towards C to reduce their needs? >> >> As a systems programming language, we should support standard OS >> interfaces IMO. >> >> 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 jay.krell at cornell.edu Fri Apr 16 14:15:03 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 16 Apr 2010 12:15:03 +0000 Subject: [M3devel] release engineering 5.8: code generator error for IP address initializers In-Reply-To: <20100416125048.183752ukg4os0kgk@mail.elegosoft.com> References: <20100416114509.eh8r662dwss44oo8@mail.elegosoft.com>, , <20100416125048.183752ukg4os0kgk@mail.elegosoft.com> Message-ID: (back to the topic :) ) somewhat reduced case: MODULE Main; TYPE T1 = ARRAY [0..0] OF INTEGER; CONST const: T1 = ARRAY OF INTEGER{2}; BEGIN END Main. The problem is two global integers are overlapping. The open array size and its first element. new source -> compiling Main.m3 "..\Main.m3", line 5: warning: not used (const) m3front:cg:Init_int:NOT in_init: o: 32 s:32 value:2 <== m3front:cg:Init_int:NOT in_init: o: 32 s:32 value:1 <== m3front:cg:Init_int:NOT in_init: o: 384 s:32 value:3 m3front:cg:Init_int:in_init: o: 32 s:32 value:1 m3front:cg:Init_int:in_init: o: 32 s:32 value:2 Are these syntaxes legal? This apparent mixing of open and fixed arrays? - Jay > Date: Fri, 16 Apr 2010 12:50:48 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] release engineering 5.8: code generator error for IP address initializers > > I agree. Regular expressions in quake would be great for regression tests. > Perhaps for the next release? > > Olaf > > Quoting Jay K : > > > "aside": > > > > http://hudson.modula3.com:8080/job/cm3-test-m3tests-AMD64_FREEBSD/lastBuild/testReport/(root)/m3tests/p206__ARRAY_constructors_in_var_decls_using_named_open_array_types/ > > > > http://hudson.modula3.com:8080/job/cm3-test-m3tests-AMD64_FREEBSD/lastBuild/testReport/(root)/m3tests/r004__negative_size_for_an_open_array/ > > > > > > It'd be nice if in Quake we had something regular expression-ish, so > > that we could factor out the line numbers, such as e.g. to match > > any decimal number. > > > > > > Maybe just check for lines that start how we expect and cut them off > > at some position. > > That might be doable with today's Quake. > > > > > > > > - Jay > > > > > > > >> Date: Fri, 16 Apr 2010 11:45:09 +0200 > >> From: wagner at elegosoft.com > >> To: m3devel at elegosoft.com > >> Subject: [M3devel] release engineering 5.8: code generator error > >> for IP address initializers > >> > >> We also have this error, which should perhaps not be ignored? > >> > >> http://hudson.modula3.com:8080/job/cm3-test-m3tests-AMD64_FREEBSD/lastBuild/testReport/(root)/m3tests/p204__IP_address_initializers > >> > >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Fri Apr 16 14:55:21 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 16 Apr 2010 14:55:21 +0200 Subject: [M3devel] assignability of fixed and open arrays, was: RE: release engineering 5.8: code generator error for IP address initializers In-Reply-To: References: <20100416114509.eh8r662dwss44oo8@mail.elegosoft.com>, , <20100416125048.183752ukg4os0kgk@mail.elegosoft.com> Message-ID: <20100416145521.sywubhm3kgk440w4@mail.elegosoft.com> Quoting Jay K : > (back to the topic :) ) > > somewhat reduced case: > > MODULE Main; > > TYPE T1 = ARRAY [0..0] OF INTEGER; > > CONST const: T1 = ARRAY OF INTEGER{2}; > BEGIN > END Main. > > The problem is two global integers are overlapping. > The open array size and its first element. > > Are these syntaxes legal? > This apparent mixing of open and fixed arrays? You mean it would work for CONST const: T1 = ARRAY [0..0] OF INTEGER{2}; The type of const is no open array, but the fixed array A1. So the question would be: is an open array (of the correct size) assignable to a fixed array type? An expression e is assignable to a variable v if: * the type of e is assignable to the type of v, and * the value of e is a member of the type of v, is not a local procedure, and if it is an array, then it has the same shape as v. though this is not a variable assignment, but a constant definition. Nonetheless, if that's assumed to be equivalent, then it would depend on the definition of shape: does it include the length field or not? I'd tend to think it does not (since that's just a representation the compiler (writer) chose), but only the number of dimensions and elements should count. But this is certainly subtle and others may see it differently. 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 jay.krell at cornell.edu Fri Apr 16 14:53:35 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 16 Apr 2010 12:53:35 +0000 Subject: [M3devel] the checked in .html files vs. $Id and such Message-ID: Some of the checked in generated .html files only vary because they use $Id-type stuff -- $Log or such. We should remove those, so the files aren't always stale. There's over 90 of these in m3-comm/events. Needs some scripting to remove. I suggest throw out the lines between "created" and "history", and throw out empty history. "history" is actually "abstract" and worth keeping when it isn't empty. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Apr 16 16:28:08 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 16 Apr 2010 10:28:08 -0400 Subject: [M3devel] Modula-3/C interop in Date/Time? In-Reply-To: References: , <4BC796B7.7090707@lcwb.coop>, Message-ID: <655C3BEA-B54B-434B-B3E9-E42AF4FD6FA1@cs.purdue.edu> Why unsafe? Depends what you do with it. On 16 Apr 2010, at 00:24, Jay K wrote: > But then unsafe, right? > > - Jay > > > From: hosking at cs.purdue.edu > > Date: Thu, 15 Apr 2010 22:06:14 -0400 > > To: rodney_bates at lcwb.coop > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] Modula-3/C interop in Date/Time? > > > > Indeed! UNTRACED. > > > > > > On 15 Apr 2010, at 18:44, Rodney M. Bates wrote: > > > > > Since these pointer variables are initialized by > > > C code and their referents are also provided by C code > > > as global variables, shouldn't the type be untraced? > > > > > > I suppose that, since they don't point into the traced > > > heap, the collector implementation we have would quietly > > > ignore them as roots. But that's relying on implementation- > > > dependent information. > > > > > > Also, if someone created a field of type Date.TimeZone, > > ! 2; (or an array of them) in a traced-heap-allocated object, > > > which is a perfectly legitimate thing to do, what would > > > our collector do then? > > > > > > > > > > > > Jay K wrote: > > >> Is this legal/correct? > > >> > > >> > > >> Date.i3: > > >> TYPE TimeZone <: REFANY; > > >> VAR Local, UTC: TimeZone; (* granted, will maybe change these to extern *) > > >> > > >> > > >> Date.m3:? > > >> REVEAL TimeZone = BRANDED "Date.TimeZone" REF INTEGER; > > >> ? > > >> > > >> DatePosixC.c: > > >> static const int Local = 0; > > >> static const int UTC = 1; > > >> extern const int const * const Date__Local = &Local; > > >> extern const int const * const D! ate__UTC = &UTC; > > >> ? > > >> > > >> - Jay > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Apr 16 16:30:48 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 16 Apr 2010 10:30:48 -0400 Subject: [M3devel] Modula-3/C interop in Date/Time? In-Reply-To: References: , , <4BC796B7.7090707@lcwb.coop>, , , , <20100416070034.9C0911A20EB@async.async.caltech.edu> Message-ID: <81B495C9-A0B2-4884-A6FC-5D928FC38340@cs.purdue.edu> What is the use-case here? Merely having UNTRACED references doesn't make your code unsafe. Using ADR does. But why not have an interface with C that makes use of the fact that VAR parameters are passed as pointers to C. e.g., C function f(int *ref p) can be declared as <*EXTERNAL*> f(VAR i: INTEGER) and this is still safe. On 16 Apr 2010, at 04:18, Jay K wrote: > Isn't making them unsafe? ADR? I'll try.. > > - Jay > > > To: jay.krell at cornell.edu > > Date: Fri, 16 Apr 2010 00:00:34 -0700 > > From: mika at async.async.caltech.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] Modula-3/C interop in Date/Time? > > > > I don't think there's anything unsafe about UNTRACED. > > > > It's DISPOSE that's unsafe... > > > > Mika > > > > Jay K writes: > > >--_cbaca81c-f322-4f31-8684-e7f171e67f3d_ > > >Content-Type: text/plain; charset="iso-2022-jp" > > >Content-Transfer-Encoding: 7bit > > > > > >But then unsafe, right? > > > > > > - Jay > > > > > >> From: hosking at cs.purdue.edu > > >> Date: Thu, 15 Apr 2010 22:06:14 -0400 > > >> To: rodney_bates at lcwb.coop > > >> CC: m3dev el at elegosoft.com > > >> Subject: Re: [M3devel] Modula-3/C interop in Date/Time? > > >> > > >> Indeed! UNTRACED. > > >> > > >> > > >> On 15 Apr 2010, at 18:44, Rodney M. Bates wrote: > > >> > > >> > Since these pointer variables are initialized by > > >> > C code and their referents are also provided by C code > > >> > as global variables, shouldn't the type be untraced? > > >> > > > >> > I suppose that, since they don't point into the traced > > >> > heap, the collector implementation we have would quietly > > >> > ignore them as roots. But that's relying on implementation- > > >> > dependent information. > > >> > > > >> > Also, if someone created a field of type Date.TimeZone, > > >> > (or an array of them) in a traced-heap-allocated object, > > > > which is a perfectly legitimate thing to do, what would > > >> > our collector do then? > > >> > > > >> > > > >> > > > >> > Jay K wrote: > > >> >> Is this legal/correct? > > >> >> > > >> >> > > >> >> Date.i3: > > >> >> TYPE TimeZone <: REFANY; > > >> >> VAR Local, UTC: TimeZone; (* granted, will maybe change these to extern *) > > >> >> > > >> >> > > >> >> Date.m3:? > > >> >> REVEAL TimeZone = BRANDED "Date.TimeZone" REF INTEGER; > > >> >> ? > > >> >> > > >> >> DatePosixC.c: > > >> >> static const int Local = 0& #59; > > >> >> static const int UTC = 1; > > >> >> extern const int const * const Date__Local = &Local; > > >> >> extern const int const * const Date__UTC = &UTC; > > >> >> ? > > >> >> > > >> >> - Jay > > >> > > > > > >--_cbaca81c-f322-4f31-8684-e7f171e67f3d_ > > >Content-Type: text/html; charset="iso-2022-jp" > > >Content-Transfer-Encoding: 7bit > > > > > > > > > > > > > > > > >But then unsafe, right?

- Jay

> From: hosking@cs.purdue.edu
> Date: Thu, 15 Apr 2010 22:06:14 -0400
> To: rodney_bates& > > >#64;lcwb.coop
> CC: m3devel@elegosoft.com
> Subject: Re: [M3devel] Modula-3/C interop in Date/Time?
>
> Indeed! UNTRACED.
>
> < > > >br>> On 15 Apr 2010, at 18:44, Rodney M. Bates wrote:
>
> > Since these pointer variables are initialized by
> & #38;#62; C code and their referents are also provided by C > > > code
> > as global variables, shouldn't the type be untraced?
> >
> > I suppose that, since they don't point into the traced
> > heap, the collect > > >or implementation we have would quietly
> > ignore them as roots. But that's relying on implementation-
> > dependent information.
> >
> > Also, if someon > > >e created a field of type Date.TimeZone,
> > > > > ; (or an array of them) in a traced-heap-allocated object,
> > which is a perfectly legitimate thing to do, what would
> > our collector do then?
> >
> > >> >
> >
> > Jay K wrote:
> >> Is this legal/correct?
> >>
> >>
> >> Date.i3:
> >> TYPE TimeZone > > > <: REFANY;
> >> VAR Local, UTC: TimeZone; (* granted, will maybe change these to extern *)
> >>
> >&# 38;#62;
> >> > > > Date.m3: 
> >> REVEAL TimeZone = BRANDED "Date.TimeZone" REF INTEGER;
> >>  
> >>
> >> DatePosixC.c:
> > >> >> static const int Local = 0;
> >> static const int UTC = 1;
> >> extern const int const * const Date__Local = &Local;
> > > > >> extern const int con st * const Dat > > > e__UTC = &UTC;
> >>  
> >>
> >> - Jay
>
> > > > > >--_cbaca81c-f322-4f31-8684-e7f171e67f3d_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Apr 16 16:45:41 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 16 Apr 2010 10:45:41 -0400 Subject: [M3devel] release engineering 5.8: trac issue 1005 (open array initializers) In-Reply-To: <20100416113814.xwn126mk800808kc@mail.elegosoft.com> References: <20100416113814.xwn126mk800808kc@mail.elegosoft.com> Message-ID: Here's the testcase: MODULE Main; IMPORT IO; <*UNUSED*> VAR a : ARRAY [0..0] OF CHAR := ARRAY OF CHAR {'a'}; <*UNUSED*> VAR b : ARRAY [0..0] OF CHAR := ARRAY OF CHAR {'b'}; <*UNUSED*> VAR c : ARRAY [0..0] OF CHAR := ARRAY OF CHAR {'c'}; <*UNUSED*> VAR d : ARRAY [0..0] OF CHAR := ARRAY OF CHAR {'d'}; BEGIN IO.Put("OK\n"); END Main. I looked into this a while back and have some understanding of what is going on. Still no fix yet. Note that this is weird code that does have a more concise workaround, which is probably why we don't see it often: MODULE Main; IMPORT IO; <*UNUSED*> VAR a := ARRAY [0,0] OF CHAR {'a'}; <*UNUSED*> VAR b := ARRAY [0,0] OF CHAR {'b'}; <*UNUSED*> VAR c := ARRAY [0,0] OF CHAR {'c'}; <*UNUSED*> VAR d := ARRAY [0,0] OF CHAR {'d'}; BEGIN IO.Put("OK\n"); END Main. The problem arises because in the first form the compiler tries to initialise a literal array constant for each of the array constructor expressions before assigning them to the variables. In the second form it initialises the variables directly from the elements of the constructor. Need to dig deeper. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 16 Apr 2010, at 05:38, Olaf Wagner wrote: > I'm currently reviewing the open issues again, and came across > > https://projects.elego.de/cm3/ticket/1005 > > Not sure if I've asked before, but do we need to solve this for this > release? The GC error seems strange: > > --- ../src/p2/p209/stderr.build 2009-06-29 21:47:53.000000000 +0200 > +++ ../src/p2/p209/AMD64_LINUX/stderr.build 2009-07-20 08:17:17.000000000 +0200 > @@ -0,0 +1,13 @@ > +o is 0x348 > +init_pc is 0x0 > +bias is 0x5c8 > +Target.Address.align is 0x40 > +Target.Byte is 0x8 > + > + > +*** > +*** runtime error: > +*** <*ASSERT*> failed. > +*** file "../src/misc/CG.m3", line 1077 > +*** > + > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Apr 16 16:46:41 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 16 Apr 2010 10:46:41 -0400 Subject: [M3devel] release engineering 5.8: trac issue 1005 (open array initializers) In-Reply-To: References: <20100416113814.xwn126mk800808kc@mail.elegosoft.com> Message-ID: <9B6A5ED8-BB05-4856-96AC-1A28C498C443@cs.purdue.edu> PS I don't use printouts when debugging. I use a debugger. There is never a need to put verbose debugging printouts into the source tree. They just litter the code. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 16 Apr 2010, at 05:58, Jay K wrote: > I believe Tony removed the print outs but imho they should be left in until the assertion failure is understood and fixed. They try to inform on what is going on when the assertion fails. > > - Jay > > > Date: Fri, 16 Apr 2010 11:38:14 +0200 > > From: wagner at elegosoft.com > > To: m3devel at elegosoft.com > > Subject: [M3devel] release engineering 5.8: trac issue 1005 (open array initializers) > > > > I'm currently reviewing the open issues again, and came across > > > > https://projects.elego.de/cm3/ticket/1005 > > > > Not sure if I've asked before, but do we need to solve this for this > > release? The GC error seems strange: > > > > --- ../src/p2/p209/stderr.build 2009-06-29 21:47:53.000000000 +0200 > > +++ ../src/p2/p209/AMD64_LINUX/stderr.build 2009-07-20 > > 08:17:17.000000000 +0200 > > @@ -0,0 +1,13 @@ > > +o is 0x348 > > +init_pc is 0x0 > > +bias is 0x5c8 > > +Target.Address.align is 0x40 > > +Target.Byte is 0x8 > > + > > + > > +*** > > +*** runtime error: > > +*** <*ASSERT*> failed. > > +*** file "../src/misc/CG.m3", line 1077 > > +*** > > + > > > > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Apr 16 17:04:49 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 16 Apr 2010 11:04:49 -0400 Subject: [M3devel] release engineering 5.8: code generator error for IP address initializers In-Reply-To: References: <20100416114509.eh8r662dwss44oo8@mail.elegosoft.com>, , <20100416125048.183752ukg4os0kgk@mail.elegosoft.com> Message-ID: <908A7AC8-565B-4749-A325-BE13F99F70D7@cs.purdue.edu> You are confusing open array types with array constructors. On 16 Apr 2010, at 08:15, Jay K wrote: > (back to the topic :) ) > > somewhat reduced case: > MODULE Main; > TYPE T1 = ARRAY [0..0] OF INTEGER; > CONST const: T1 = ARRAY OF INTEGER{2}; This is an array constructor. I suspect this is the same issue as in my previous e-mail. The following concise rewrite should work: CONST const = T1{2}; > BEGIN > END Main. > > The problem is two global integers are overlapping. > The open array size and its first element. > > new source -> compiling Main.m3 > "..\Main.m3", line 5: warning: not used (const) > m3front:cg:Init_int:NOT in_init: o: 32 s:32 value:2 <== > m3front:cg:Init_int:NOT in_init: o: 32 s:32 value:1 <== > m3front:cg:Init_int:NOT in_init: o: 384 s:32 value:3 > m3front:cg:Init_int:in_init: o: 32 s:32 value:1 > m3front:cg:Init_int:in_init: o: 32 s:32 value:2 > > Are these syntaxes legal? > This apparent mixing of open and fixed arrays? > > - Jay > > > > Date: Fri, 16 Apr 2010 12:50:48 +0200 > > From: wagner at elegosoft.com > > To: jay.krell at cornell.edu > > CC: m3devel at elegosoft.com > > Subject: RE: [M3devel] release engineering 5.8: code generator error for IP address initializers > > > > I agree. Regular expressions in quake would be great for regression tests. > > Perhaps for the next release? > > > > Olaf > > > > Quoting Jay K : > > > > > "aside": > > > > > > http://hudson.modula3.com:8080/job/cm3-test-m3tests-AMD64_FREEBSD/lastBuild/testReport/(root)/m3tests/p206__ARRAY_constructors_in_var_decls_using_named_open_array_types/ > > > > > > http://hudson.modula3.com:8080/job/cm3-test-m3tests-AMD64_FREEBSD/lastBuild/testReport/(root)/m3tests/r004__negative_size_for_an_open_array/ > > > > > > > > > It'd be nice if in Quake we had something regular expression-ish, so > > > that we could factor out the line numbers, such as e.g. to match > > > any decimal number. > > > > > > > > > Maybe just check for lines that start how we expect and cut them off > > > at some position. > > > That might be doable with today's Quake. > > > > > > > > > > > > - Jay > > > > > > > > > > > >> Date: Fri, 16 Apr 2010 11:45:09 +0200 > > >> From: wagner at elegosoft.com > > >> To: m3devel at elegosoft.com > > >> Subject: [M3devel] release engineering 5.8: code generator error > > >> for IP address initializers > > >> > > >> We also have this error, which should perhaps not be ignored? > > >> > > >> http://hudson.modula3.com:8080/job/cm3-test-m3tests-AMD64_FREEBSD/lastBuild/testReport/(root)/m3tests/p204__IP_address_initializers > > >> > > >> 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Apr 16 17:06:27 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 16 Apr 2010 11:06:27 -0400 Subject: [M3devel] assignability of fixed and open arrays, was: RE: release engineering 5.8: code generator error for IP address initializers In-Reply-To: <20100416145521.sywubhm3kgk440w4@mail.elegosoft.com> References: <20100416114509.eh8r662dwss44oo8@mail.elegosoft.com>, , <20100416125048.183752ukg4os0kgk@mail.elegosoft.com> <20100416145521.sywubhm3kgk440w4@mail.elegosoft.com> Message-ID: <5DB7169E-073B-480B-A043-046E08ED53DE@cs.purdue.edu> There is no open array in this code. Just a fixed array type and an array constructor. It is perfectly reasonable code. On 16 Apr 2010, at 08:55, Olaf Wagner wrote: > Quoting Jay K : > >> (back to the topic :) ) >> >> somewhat reduced case: >> >> MODULE Main; >> >> TYPE T1 = ARRAY [0..0] OF INTEGER; >> >> CONST const: T1 = ARRAY OF INTEGER{2}; >> BEGIN >> END Main. >> >> The problem is two global integers are overlapping. >> The open array size and its first element. >> >> Are these syntaxes legal? >> This apparent mixing of open and fixed arrays? > > You mean it would work for > > CONST const: T1 = ARRAY [0..0] OF INTEGER{2}; > > The type of const is no open array, but the fixed array A1. > So the question would be: is an open array (of the correct size) > assignable to a fixed array type? > > An expression e is assignable to a variable v if: > > * the type of e is assignable to the type of v, and > * the value of e is a member of the type of v, is not a local procedure, > and if it is an array, then it has the same shape as v. > > though this is not a variable assignment, but a constant definition. > Nonetheless, if that's assumed to be equivalent, then it would depend > on the definition of shape: does it include the length field or not? > > I'd tend to think it does not (since that's just a representation the > compiler (writer) chose), but only the number of dimensions and elements > should count. > > But this is certainly subtle and others may see it differently. > > 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 rcolebur at SCIRES.COM Fri Apr 16 23:07:04 2010 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Fri, 16 Apr 2010 17:07:04 -0400 Subject: [M3devel] example of bug in NetObj Stub Generator In-Reply-To: References: , , <7C7408D0-9A40-4988-BADA-A9FD8C15D388@cs.purdue.edu>, , Message-ID: Jay / Rodney / et al: I?ve attached a ZIP file containing a stripped-down source package and NT386 folder that demonstrates the problem I am having with the stub generator. The generated file ?NT386\CV_Server_T_v2.m3? is missing the import of the ?Date? interface. The source interface that I wrote is in ?src\CV_Server.i3?. Regards, Randy From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K Sent: Thursday, April 15, 2010 7:13 PM To: Coleburn, Randy; m3devel Subject: RE: [M3devel] Modula-3/C interop in Date/Time? Randy, I think I understand but yes please commit a small concrete example like in m3-sys/m3tests/src/p2/p237 or such. I think this is a bug in the stub generator. Probably time/date could workaround it with slight restructuring/renaming. But probably should fix the stub generator. While at it, maybe have it stop outputing unused stuff that triggers so many warnings... - Jay ________________________________ From: rcolebur at SCIRES.COM To: m3devel at elegosoft.com Date: Thu, 15 Apr 2010 18:10:44 -0400 Subject: Re: [M3devel] Modula-3/C interop in Date/Time? Jay: I?m still catching up after being in hospital, but noticed you are working on the Date.i3/m3 interface and module. There is a problem that I?d like to post on the newsgroup that may be related. I?m not sure if the problem is due to the way Date.i3/m3 is coded, or perhaps a problem in the network objects stub generator, but I thought whilst you are looking at Date.i3/m3 something might trigger in your mind about how to fix the problem. I have several interfaces that export a Network Object. Of course, these get processed by the network objects stub generator at compile time. For some of these, the generated files fail to compile due to Date.i3 not being listed in the IMPORT list. Since these offending modules are generated at compile time, it?s not a programming error in the new source package that is being compiled. The way I work around the problem is by editing the generated files after the compile fails. Namely, I go to the target folder (in this case NT386) and edit the generated m3 files by adding ?IMPORT Date;?, then recompile and all is well. Of course, the next time you erase the target folder, change the underlying interface, or run ?cm3 -clean?, the generated file has to be created again and you have to go thru the compile-edit-compile cycle again to repair the problem. If you are delivering source code to a customer, you then have to document the work-around for them so that they can get the package to compile. I reported this problem years ago, but that was back before we were tracking bugs using the new system. It could be that the way Date.i3/m3 is coded is causing the stub generator not to think it needs to import it, or it could be that the stub generator isn?t doing its job right in the first place. Now after saying all this, I know I should provide a concrete example. I?ll have to go back and see if I ever reduced the code to a smaller set that demonstrates the problem. Otherwise, I can?t give anyone the full source code because it was a ?work-for-hire? and I don?t have the right to publish these sources. Let me know if you want a concrete example and I?ll see what I can do. Regards, Randy From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K Sent: Thursday, April 15, 2010 5:26 PM To: Tony Cc: m3devel Subject: Re: [M3devel] Modula-3/C interop in Date/Time? Oops, right, of course. Important to get the things right I know to keep the question clear/narrow. - Jay ________________________________ From: hosking at cs.purdue.edu Date: Thu, 15 Apr 2010 12:55:52 -0400 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] Modula-3/C interop in Date/Time? Excepting that INTEGER is not the same as int on 64-bit platforms. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 15 Apr 2010, at 02:45, Jay K wrote: Is this legal/correct? Date.i3: TYPE TimeZone <: REFANY; VAR Local, UTC: TimeZone; (* granted, will maybe change these to extern *) Date.m3:? REVEAL TimeZone = BRANDED "Date.TimeZone" REF INTEGER; ? DatePosixC.c: static const int Local = 0; static const int UTC = 1; extern const int const * const Date__Local = &Local; extern const int const * const Date__UTC = &UTC; ? - Jay ________________________________ CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This email may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from reviewing, copying, using, disclosing or distributing to others the information in this email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require advance export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. ________________________________ CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This email may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from reviewing, copying, using, disclosing or distributing to others the information in this email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require advance export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: BugExample.zip Type: application/x-zip-compressed Size: 8839 bytes Desc: BugExample.zip URL: From jay.krell at cornell.edu Sat Apr 17 03:50:54 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 17 Apr 2010 01:50:54 +0000 Subject: [M3devel] release engineering 5.8: code generator error for IP address initializers In-Reply-To: <908A7AC8-565B-4749-A325-BE13F99F70D7@cs.purdue.edu> References: <20100416114509.eh8r662dwss44oo8@mail.elegosoft.com>, , <20100416125048.183752ukg4os0kgk@mail.elegosoft.com> , <908A7AC8-565B-4749-A325-BE13F99F70D7@cs.purdue.edu> Message-ID: There is this thing I read, where the types of values/constants are known without context. The left hand side does not change the type of the right. That confuses me here. It would imply the right is an open array. - Jay Subject: Re: [M3devel] release engineering 5.8: code generator error for IP address initializers From: hosking at cs.purdue.edu Date: Fri, 16 Apr 2010 11:04:49 -0400 CC: wagner at elegosoft.com; m3devel at elegosoft.com To: jay.krell at cornell.edu You are confusing open array types with array constructors. On 16 Apr 2010, at 08:15, Jay K wrote: (back to the topic :) ) somewhat reduced case: MODULE Main; TYPE T1 = ARRAY [0..0] OF INTEGER; CONST const: T1 = ARRAY OF INTEGER{2}; This is an array constructor. I suspect this is the same issue as in my previous e-mail. The following concise rewrite should work: CONST const = T1{2}; BEGIN END Main. The problem is two global integers are overlapping. The open array size and its first element. new source -> compiling Main.m3 "..\Main.m3", line 5: warning: not used (const) m3front:cg:Init_int:NOT in_init: o: 32 s:32 value:2 <== m3front:cg:Init_int:NOT in_init: o: 32 s:32 value:1 <== m3front:cg:Init_int:NOT in_init: o: 384 s:32 value:3 m3front:cg:Init_int:in_init: o: 32 s:32 value:1 m3front:cg:Init_int:in_init: o: 32 s:32 value:2 Are these syntaxes legal? This apparent mixing of open and fixed arrays? - Jay > Date: Fri, 16 Apr 2010 12:50:48 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] release engineering 5.8: code generator error for IP address initializers > > I agree. Regular expressions in quake would be great for regression tests. > Perhaps for the next release? > > Olaf > > Quoting Jay K : > > > "aside": > > > > http://hudson.modula3.com:8080/job/cm3-test-m3tests-AMD64_FREEBSD/lastBuild/testReport/(root)/m3tests/p206__ARRAY_constructors_in_var_decls_using_named_open_array_types/ > > > > http://hudson.modula3.com:8080/job/cm3-test-m3tests-AMD64_FREEBSD/lastBuild/testReport/(root)/m3tests/r004__negative_size_for_an_open_array/ > > > > > > It'd be nice if in Quake we had something regular expression-ish, so > > that we could factor out the line numbers, such as e.g. to match > > any decimal number. > > > > > > Maybe just check for lines that start how we expect and cut them off > > at some position. > > That might be doable with today's Quake. > > > > > > > > - Jay > > > > > > > >> Date: Fri, 16 Apr 2010 11:45:09 +0200 > >> From: wagner at elegosoft.com > >> To: m3devel at elegosoft.com > >> Subject: [M3devel] release engineering 5.8: code generator error > >> for IP address initializers > >> > >> We also have this error, which should perhaps not be ignored? > >> > >> http://hudson.modula3.com:8080/job/cm3-test-m3tests-AMD64_FREEBSD/lastBuild/testReport/(root)/m3tests/p204__IP_address_initializers > >> > >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Apr 17 03:48:44 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 17 Apr 2010 01:48:44 +0000 Subject: [M3devel] release engineering 5.8: trac issue 1005 (open array initializers) In-Reply-To: <9B6A5ED8-BB05-4856-96AC-1A28C498C443@cs.purdue.edu> References: <20100416113814.xwn126mk800808kc@mail.elegosoft.com>, , <9B6A5ED8-BB05-4856-96AC-1A28C498C443@cs.purdue.edu> Message-ID: I haven't found a viable debugger for Modula-3. Could be better now that I'm on Debian 5.0 though. gdb is now good, eveything is void*. VisualStudio/cdb/windbb are no good due to lack of CodeView information. I'll try m3gdb again, since upgrading to Debian 5.0. I'm keen on generating good CodeView information because of this. - Jay From: hosking at cs.purdue.edu Date: Fri, 16 Apr 2010 10:46:41 -0400 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] release engineering 5.8: trac issue 1005 (open array initializers) PS I don't use printouts when debugging. I use a debugger. There is never a need to put verbose debugging printouts into the source tree. They just litter the code. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 16 Apr 2010, at 05:58, Jay K wrote: I believe Tony removed the print outs but imho they should be left in until the assertion failure is understood and fixed. They try to inform on what is going on when the assertion fails. - Jay > Date: Fri, 16 Apr 2010 11:38:14 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] release engineering 5.8: trac issue 1005 (open array initializers) > > I'm currently reviewing the open issues again, and came across > > https://projects.elego.de/cm3/ticket/1005 > > Not sure if I've asked before, but do we need to solve this for this > release? The GC error seems strange: > > --- ../src/p2/p209/stderr.build 2009-06-29 21:47:53.000000000 +0200 > +++ ../src/p2/p209/AMD64_LINUX/stderr.build 2009-07-20 > 08:17:17.000000000 +0200 > @@ -0,0 +1,13 @@ > +o is 0x348 > +init_pc is 0x0 > +bias is 0x5c8 > +Target.Address.align is 0x40 > +Target.Byte is 0x8 > + > + > +*** > +*** runtime error: > +*** <*ASSERT*> failed. > +*** file "../src/misc/CG.m3", line 1077 > +*** > + > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Apr 17 10:05:39 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 17 Apr 2010 08:05:39 +0000 Subject: [M3devel] picking which files to package? Message-ID: Olaf, any chance you can limit what files are picked up to the $TARGET and src directories? The I386_DARWIN/AMD64_DARWIN packages I made contain each of other's files due to just picking up "everything". Maybe: iff -u -r1.26.2.51 make-dist.sh --- make-dist.sh 17 Apr 2010 03:55:43 -0000 1.26.2.51 +++ make-dist.sh 17 Apr 2010 08:05:13 -0000 @@ -338,12 +338,16 @@ ) > collection-${c}.html echo "collection-${c}.html" ARCHIVE="${STAGE}/cm3-bin-ws-${c}-${TARGET}-${CM3VERSION}-${DS}.tgz" + a="" + for b in ${PKGS}; do + a="${a} ${b}/src ${b}/${TARGET}" + done if [ -z "${NOARCHIVE}" -a "${c}" != "min" ]; then "${TAR}" --exclude '*.o' --exclude '*.mo' --exclude '*.io' \ --exclude '*/CVS/*' --exclude '*/CVS' --exclude '*~' \ --exclude '*.tar.*' --exclude '*.tgz' --exclude "*/${TARGET}/gcc" \ --exclude "*/${TARGET}/*/*" \ - -czf "${ARCHIVE}" collection-${c}.html install.sh setup.txt setup.cmd ${PKGS} + -czf "${ARCHIVE}" collection-${c}.html install.sh setup.txt setup.cmd ${a} ls -l "${ARCHIVE}" fi done - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Apr 17 06:26:59 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 17 Apr 2010 04:26:59 +0000 Subject: [M3devel] ROUND vs. FLOOR in ThreadPThread.m3 nano vs. micro time conversions? Message-ID: I've gone ahead and "rewritten" this code (it's only a few lines), and I removed this distinction. New form uses modf to split floating point at the decimal point and then multiplies the fractional part by a million (struct timeval) or a billion (struct timespec). Should be equivalent to seconds = (int)floatseconds; microsseconds = (floatseconds - seconds) * billion or million or such I ended up not using the C99 stuff. Sometimes we know the time is less than a second and greater than 0 and so just pass around a microsecond or nanosecond count. Hm. Maybe it has to do with negative times? Rounding down vs. toward zero? I'll probably rereread the code with negative times in mind. Not too worried, as the select uses in the thread code doesn't pass negative times, gettimeofday can't return a negative time, the user thread scheduling intervals I believe are all positive, etc. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Subject: ROUND vs. FLOOR in ThreadPThread.m3 nano vs. micro time conversions? Date: Fri, 9 Apr 2010 10:52:09 +0000 Why does UTimeFromTime use FLOOR but ToNTime uses ROUND? PROCEDURE ToNTime (n: LONGREAL; VAR ts: Utime.struct_timespec) = BEGIN ts.tv_sec := TRUNC(n); ts.tv_nsec := ROUND((n - FLOAT(ts.tv_sec, LONGREAL)) * 1.0D9); END ToNTime; TYPE UTime = Utime.struct_timeval; PROCEDURE UTimeFromTime (time: Time.T): UTime = VAR floor := FLOOR(time); BEGIN RETURN UTime{floor, FLOOR(1.0D6 * (time - FLOAT(floor, LONGREAL)))}; END UTimeFromTime; I've changed this code to pass doubles to C and do the conversion there. To reduce/eliminate use of cloned headers. For ROUND I'm using C99: /* C99, very portable */ long lround(double); long long llround(double); #ifdef __CYGWIN__ #define ROUND lround #else #define ROUND llround #endif typedef double FloatSeconds, LONGREAL; typedef struct timeval MicrosecondsStruct_t; #define FLOAT(value, type) ((type)value) #define FLOOR floor static MicrosecondsStruct_t* FloatSecondsToNanosecondsStruct(LONGREAL n, MicrosecondsStruct_t* ts) { ts->tv_sec = (time_t)n; ts->tv_nsec = ROUND((n - FLOAT(ts->tv_sec, LONGREAL)) * 1.0E9); return ts; } static MicrosecondsStruct_t* FloatSecondsToMicrosecondsStruct(FloatSeconds timeout, MicrosecondsStruct_t* utime) { LONGINT sec = FLOOR(timeout); utime->tv_sec = (time_t)sec; utime->tv_usec = (suseconds_t)FLOOR(1.0E6 * (timeout - FLOAT(sec, LONGREAL))); return utime; } Just arbitrarily a little more correct in the nano case vs. the micro case? Matters little? Would matter more for micro due to lower resolution? Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Apr 17 04:31:25 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 17 Apr 2010 02:31:25 +0000 Subject: [M3devel] release engineering 5.8: trac issue 1005 (open array initializers) In-Reply-To: <9B6A5ED8-BB05-4856-96AC-1A28C498C443@cs.purdue.edu> References: <20100416113814.xwn126mk800808kc@mail.elegosoft.com>, , <9B6A5ED8-BB05-4856-96AC-1A28C498C443@cs.purdue.edu> Message-ID: There is another vague philosophical point I should maybe explore/teach here. The vaguer I make it, the more irrefutable it is. :) "Logging has a place". And debuggers do too. I have seen countless examples where logging exists, in some "reasonable" volume bugs are often largly or completely diagnosed from a log alone getting a debugger to the right point would be quite difficult Logging is always "in situ" and often enabled proactively -- all the time. That is, no need to figure out exactly which command line to run, where to insert the debugger command, no need to try to keep temp files, etc. Very good example: Our Hudson/Tinderbox jobs. Callstacks upon assertion failures are a form of logging. Would be even better if they showed the local variables of every frame. Maybe expanding pointers one level. I often make the prints subject to whether or not an upcoming assertion is going to fail. There are counterpoints, of course. Logging wastes time and space. It makes the source code bigger, the object code bigger. When it is enabled it slows down runtime and usually "wastes" space to store the logs. Except when they end up used. The vast majority of logged date goes unread. You can't log everything. Good debuggers show things at a much lower level than most logging. (Except gdb on Debian 4.0 can't do anything, and CodeView-based debuggers against Modula-3 show very little...) I'll have to try m3gdb again, on Debian 5.0. And generate CodeView information. The CodeView stuff I consider pretty high priority. I've done a fair amount of research and am better prepared to implement it than previously. A C generating backend has about the same value and more. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu CC: m3devel at elegosoft.com Subject: RE: [M3devel] release engineering 5.8: trac issue 1005 (open array initializers) Date: Sat, 17 Apr 2010 01:48:44 +0000 I haven't found a viable debugger for Modula-3. Could be better now that I'm on Debian 5.0 though. gdb is now good, eveything is void*. VisualStudio/cdb/windbb are no good due to lack of CodeView information. I'll try m3gdb again, since upgrading to Debian 5.0. I'm keen on generating good CodeView information because of this. - Jay From: hosking at cs.purdue.edu Date: Fri, 16 Apr 2010 10:46:41 -0400 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] release engineering 5.8: trac issue 1005 (open array initializers) PS I don't use printouts when debugging. I use a debugger. There is never a need to put verbose debugging printouts into the source tree. They just litter the code. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 16 Apr 2010, at 05:58, Jay K wrote: I believe Tony removed the print outs but imho they should be left in until the assertion failure is understood and fixed. They try to inform on what is going on when the assertion fails. - Jay > Date: Fri, 16 Apr 2010 11:38:14 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] release engineering 5.8: trac issue 1005 (open array initializers) > > I'm currently reviewing the open issues again, and came across > > https://projects.elego.de/cm3/ticket/1005 > > Not sure if I've asked before, but do we need to solve this for this > release? The GC error seems strange: > > --- ../src/p2/p209/stderr.build 2009-06-29 21:47:53.000000000 +0200 > +++ ../src/p2/p209/AMD64_LINUX/stderr.build 2009-07-20 > 08:17:17.000000000 +0200 > @@ -0,0 +1,13 @@ > +o is 0x348 > +init_pc is 0x0 > +bias is 0x5c8 > +Target.Address.align is 0x40 > +Target.Byte is 0x8 > + > + > +*** > +*** runtime error: > +*** <*ASSERT*> failed. > +*** file "../src/misc/CG.m3", line 1077 > +*** > + > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Apr 17 12:50:34 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 17 Apr 2010 10:50:34 +0000 Subject: [M3devel] new target names -- SOLsun vs. SOLgnu? Message-ID: If we have targets, say, I386_NT, I386_CYGWIN, I386_MINGW, I386_LINUX, I386_FREEBSD, I386_NETBSD, SPARC32_SOLARIS or SPARC_SOLARIS..how does one capture the SOLsun vs. SOLgnu difference? SPARC32_SOLARIS_SUN vs. SPARC32_SOLARIS_GNU? SPARC_SOLARIS_SUNCC, SPARC_SOLARIS_GCC? "target is underscore separated list of relevant names, usually two but not limited to two"? Drop SOLgnu and just equate SPARC32_SOLARIS with SOLsun? Given that the reason for SOLgnu was because cc was not bundled with OS at some point? But now gcc and cc are both bundled as I understand! Do some sort of autoconfig, sensitive to the CC environment variable? That's actually pretty easy and pretty cheap. Not a terrible idea. I'm not really pushing hard on this topic, just that I want to cross build Cygwin from non-NT and was hitting minor problems. Mainly I want to see if Cygwin pthreads works now, now that the hanging test case got "rewritten", so I can drop the SchedulerPosix.m3 file which duplicates content verbatim out of ThreadPThread.m3.. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Apr 17 10:31:05 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 17 Apr 2010 08:31:05 +0000 Subject: [M3devel] select vs. poll? Message-ID: It looks to me like poll is usually preferred over select? It appears to be standard and widely available. Appears to be *BSD, Solaris, Linux, Interix, AIX, Irix. At least searching the web and checking headers. It has no limit on the number or value of file descriptors waited on. It does use more memory for its parameters and more time to construct and read them. However I believe we only ever select/poll either one file at a time on pthreads one file per thread on user threads There are other better mechanisms -- /dev/poll on Solaris, kqueue on FreeBSD and maybe others, epoll on Linux. Though these are mostly (completely?) concerned with scaling to waiting on large number of file descriptors. I think I'll change over to poll very soon. I haven't yet figured out if select's read/write/except maps directly to poll's flags. I'm guessing: select read => poll POLLIN or maybe POLLPRI also? select write => poll POLLOUT select except => POLLERR or maybe POLLHUP also? I haven't yet found a description of "error conditions" with respect to select. Still looking. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Apr 17 04:44:39 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 17 Apr 2010 02:44:39 +0000 Subject: [M3devel] Modula-3/C interop in Date/Time? In-Reply-To: <81B495C9-A0B2-4884-A6FC-5D928FC38340@cs.purdue.edu> References: , ,,<4BC796B7.7090707@lcwb.coop>, , , , , , , <20100416070034.9C0911A20EB@async.async.caltech.edu>, , <81B495C9-A0B2-4884-A6FC-5D928FC38340@cs.purdue.edu> Message-ID: The use case is the TimeZone's in DatePosix.m3. It's not a big deal. There are just two constant timezones, "local", and "utc", identified by references to integers: NIL, ^ = 1 and ^ = 0. Where NIL is interpreted as 0 or 1. It could just be an enum, but the public type is REFANY and it is revealed in the Win32 flavor to actually be a reference to something else. I could maybe change that. But what is the effect on pickles either way? The Win32 one isn't picklable in either case?? I'm not sure. So Timezone isn't portably pickable? And therefore pickles of Posix timezones can be broken? If they were to be pickled, I think the representation is dubious -- probably should pickle the "offset" from GMT/UTC, not 0 or 1. The Win32 code is also dubious given evolution of the Win32 API over the years. It is more flexible now and I wonder if that implies the old API was insufficient. (Though "local" can change in time, not really "constant", as the daylight savings cutoff is crossed, or indeed when I travel with a computer and stuff says running but "asleep" and then "resumed". I'm quite suspicious that lots of code doesn't account for timezone changes. I'm also quite suspicious of any code that does anything timezone sensitive or uses "local" time for anything. Using GMT/UTC for everything, except display, is the way to go. It makes things vastly simpler and better defined. Could be that Unix/Posixy stuff is generally ok. Could be just an historical bogus favoring of localtime on PCs (and Macs?).) I actually strongly suspect as well that we can get by with just the one Posix implementation of this stuff, no BSD, no Win32. In particular, msvcr*.dll does expose tzname, timezone, daylight. Besides of course "small" localtime/gmtime. Have to think though "Time" vs. "Date". Win32 epoch is earlier, which is useful for representating dates in the past. Basically "this stuff" is more about "Date" and less about "Time", though they interact. I'm pretty sure we have bugs as well where we assume the current "daylight" status applies to all times/dates. Switching to "time64" is part of the equation. Maybe I should attack more from that angle. Make things work for Date{year := 2040} and see what all that implies. - Jay From: hosking at cs.purdue.edu Date: Fri, 16 Apr 2010 10:30:48 -0400 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] Modula-3/C interop in Date/Time? What is the use-case here? Merely having UNTRACED references doesn't make your code unsafe. Using ADR does. But why not have an interface with C that makes use of the fact that VAR parameters are passed as pointers to C. e.g., C function f(int *ref p) can be declared as <*EXTERNAL*> f(VAR i: INTEGER) and this is still safe. On 16 Apr 2010, at 04:18, Jay K wrote: Isn't making them unsafe? ADR? I'll try.. - Jay > To: jay.krell at cornell.edu > Date: Fri, 16 Apr 2010 00:00:34 -0700 > From: mika at async.async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Modula-3/C interop in Date/Time? > > I don't think there's anything unsafe about UNTRACED. > > It's DISPOSE that's unsafe... > > Mika > > Jay K writes: > >--_cbaca81c-f322-4f31-8684-e7f171e67f3d_ > >Content-Type: text/plain; charset="iso-2022-jp" > >Content-Transfer-Encoding: 7bit > > > >But then unsafe, right? > > > > - Jay > > > >> From: hosking at cs.purdue.edu > >> Date: Thu, 15 Apr 2010 22:06:14 -0400 > >> To: rodney_bates at lcwb.coop > >> CC: m3dev el at elegosoft.com > >> Subject: Re: [M3devel] Modula-3/C interop in Date/Time? > >> > >> Indeed! UNTRACED. > >> > >> > >> On 15 Apr 2010, at 18:44, Rodney M. Bates wrote: > >> > >> > Since these pointer variables are initialized by > >> > C code and their referents are also provided by C code > >> > as global variables, shouldn't the type be untraced? > >> > > >> > I suppose that, since they don't point into the traced > >> > heap, the collector implementation we have would quietly > >> > ignore them as roots. But that's relying on implementation- > >> > dependent information. > >> > > >> > Also, if someone created a field of type Date.TimeZone, > >> > (or an array of them) in a traced-heap-allocated object, > > > which is a perfectly legitimate thing to do, what would > >> > our collector do then? > >> > > >> > > >> > > >> > Jay K wrote: > >> >> Is this legal/correct? > >> >> > >> >> > >> >> Date.i3: > >> >> TYPE TimeZone <: REFANY; > >> >> VAR Local, UTC: TimeZone; (* granted, will maybe change these to extern *) > >> >> > >> >> > >> >> Date.m3:? > >> >> REVEAL TimeZone = BRANDED "Date.TimeZone" REF INTEGER; > >> >> ? > >> >> > >> >> DatePosixC.c: > >> >> static const int Local = 0& #59; > >> >> static const int UTC = 1; > >> >> extern const int const * const Date__Local = &Local; > >> >> extern const int const * const Date__UTC = &UTC; > >> >> ? > >> >> > >> >> - Jay > >> > > > >--_cbaca81c-f322-4f31-8684-e7f171e67f3d_ > >Content-Type: text/html; charset="iso-2022-jp" > >Content-Transfer-Encoding: 7bit > > > > > > > > > > >But then unsafe, right?

- Jay

> From: hosking@cs.purdue.edu
> Date: Thu, 15 Apr 2010 22:06:14 -0400
> To: rodney_bates& > >#64;lcwb.coop
> CC: m3devel@elegosoft.com
> Subject: Re: [M3devel] Modula-3/C interop in Date/Time?
>
> Indeed! UNTRACED.
>
> < > >br>> On 15 Apr 2010, at 18:44, Rodney M. Bates wrote:
>
> > Since these pointer variables are initialized by
> & #38;#62; C code and their referents are also provided by C > > code
> > as global variables, shouldn't the type be untraced?
> >
> > I suppose that, since they don't point into the traced
> > heap, the collect > >or implementation we have would quietly
> > ignore them as roots. But that's relying on implementation-
> > dependent information.
> >
> > Also, if someon > >e created a field of type Date.TimeZone,
> > > > ; (or an array of them) in a traced-heap-allocated object,
> > which is a perfectly legitimate thing to do, what would
> > our collector do then?
> >
> >> >
> >
> > Jay K wrote:
> >> Is this legal/correct?
> >>
> >>
> >> Date.i3:
> >> TYPE TimeZone > > <: REFANY;
> >> VAR Local, UTC: TimeZone; (* granted, will maybe change these to extern *)
> >>
> >&# 38;#62;
> >> > > Date.m3: 
> >> REVEAL TimeZone = BRANDED "Date.TimeZone" REF INTEGER;
> >>  
> >>
> >> DatePosixC.c:
> >> >> static const int Local = 0;
> >> static const int UTC = 1;
> >> extern const int const * const Date__Local = &Local;
> > > >> extern const int con st * const Dat > > e__UTC = &UTC;
> >>  
> >>
> >> - Jay
>
> > > >--_cbaca81c-f322-4f31-8684-e7f171e67f3d_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sat Apr 17 13:22:14 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 17 Apr 2010 13:22:14 +0200 Subject: [M3devel] picking which files to package? In-Reply-To: References: Message-ID: <20100417132214.a2z13qxcoc8g0gs4@mail.elegosoft.com> You need to set STAGE differently if you want to run make-dist for different targets on the same machine. It's been done for SOLgnu and SOLsun, too. If you really want to build concurrently, you also need to change INSTBASE before sourcing defs.sh. Olaf Quoting Jay K : > > Olaf, any chance you can limit what files are picked up to the > $TARGET and src directories? > The I386_DARWIN/AMD64_DARWIN packages I made contain each of other's files > due to just picking up "everything". > > Maybe: > > iff -u -r1.26.2.51 make-dist.sh > --- make-dist.sh 17 Apr 2010 03:55:43 -0000 1.26.2.51 > +++ make-dist.sh 17 Apr 2010 08:05:13 -0000 > @@ -338,12 +338,16 @@ > ) > collection-${c}.html > echo "collection-${c}.html" > ARCHIVE="${STAGE}/cm3-bin-ws-${c}-${TARGET}-${CM3VERSION}-${DS}.tgz" > + a="" > + for b in ${PKGS}; do > + a="${a} ${b}/src ${b}/${TARGET}" > + done > if [ -z "${NOARCHIVE}" -a "${c}" != "min" ]; then > "${TAR}" --exclude '*.o' --exclude '*.mo' --exclude '*.io' \ > --exclude '*/CVS/*' --exclude '*/CVS' --exclude '*~' \ > --exclude '*.tar.*' --exclude '*.tgz' --exclude "*/${TARGET}/gcc" \ > --exclude "*/${TARGET}/*/*" \ > - -czf "${ARCHIVE}" collection-${c}.html install.sh setup.txt > setup.cmd ${PKGS} > + -czf "${ARCHIVE}" collection-${c}.html install.sh setup.txt > setup.cmd ${a} > ls -l "${ARCHIVE}" > fi > done > > > - Jay > -- 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 Sat Apr 17 13:55:39 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 17 Apr 2010 13:55:39 +0200 Subject: [M3devel] releng 5.8 for I386_DARWIN In-Reply-To: References: <20100416141032.doe6pi088o0w8gsk@mail.elegosoft.com>, , <20100416150010.7yzjrn8dwkkwowcc@mail.elegosoft.com> Message-ID: <20100417135539.8bjp68negwk480ks@mail.elegosoft.com> Quoting Jay K : > I just made a somewhat significant change in head and then copied > head to release in m3-sys/cm3 to deal with this. > > I get other problems on AMD64_DARWIN I believe unrelated. > > I'll keep looking. Let's not put that in RC5 unless it's really broken for other targets, too. In this case we have to remove the existing packages and rebuild everything. I'd like to avoid that. I've moved the Darwin files into post-RC5. I'd really like to finish this release... Olaf > From: jay.krell at cornell.edu > To: wagner at elegosoft.com > Subject: RE: releng 5.8 for I386_DARWIN > Date: Fri, 16 Apr 2010 13:13:49 +0000 > > > > drat, AMD64_DARWIN gets far, but then complains about bad .M3SHIP files. > > - Jay -- 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 jay.krell at cornell.edu Sat Apr 17 14:03:17 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 17 Apr 2010 12:03:17 +0000 Subject: [M3devel] releng 5.8 for I386_DARWIN In-Reply-To: <20100417135539.8bjp68negwk480ks@mail.elegosoft.com> References: <20100416141032.doe6pi088o0w8gsk@mail.elegosoft.com>, , <20100416150010.7yzjrn8dwkkwowcc@mail.elegosoft.com>, , <20100417135539.8bjp68negwk480ks@mail.elegosoft.com> Message-ID: I don't actually understand the .M3SHIP breakage. Instead I made the code a bit more obviously correct -- apply some path canonicalization. I can understand that root/bin/../lib would prevent replacement with LIB_INSTALL, but BIN_INSTALL or INSTALL_ROOT should still have been unresolved. There's still an inconsistency in that all but one of the unresolved paths do not end in a slash. But it should be ok. Just that that the slash will or not be unresolved along with the rest. I understand it's not a great situation. I'm going to rebuild I386_DARWIN and AMD64_DARWIN, sequentially. - Jay > Date: Sat, 17 Apr 2010 13:55:39 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: RE: releng 5.8 for I386_DARWIN > > Quoting Jay K : > > > I just made a somewhat significant change in head and then copied > > head to release in m3-sys/cm3 to deal with this. > > > > I get other problems on AMD64_DARWIN I believe unrelated. > > > > I'll keep looking. > > Let's not put that in RC5 unless it's really broken for other targets, too. > In this case we have to remove the existing packages and rebuild everything. > I'd like to avoid that. > > I've moved the Darwin files into post-RC5. > > I'd really like to finish this release... > > Olaf > > > From: jay.krell at cornell.edu > > To: wagner at elegosoft.com > > Subject: RE: releng 5.8 for I386_DARWIN > > Date: Fri, 16 Apr 2010 13:13:49 +0000 > > > > > > > > drat, AMD64_DARWIN gets far, but then complains about bad .M3SHIP files. > > > > - Jay > -- > 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 jay.krell at cornell.edu Sat Apr 17 14:08:45 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 17 Apr 2010 12:08:45 +0000 Subject: [M3devel] picking which files to package? In-Reply-To: <20100417132214.a2z13qxcoc8g0gs4@mail.elegosoft.com> References: , <20100417132214.a2z13qxcoc8g0gs4@mail.elegosoft.com> Message-ID: Can you maybe append TARGET to $STAGE, $INSTBASE, etc. consistently, as needed, on all platforms? - There are other bi/multiarch platforms? I'm not sure how widely that notion has taken hold, e.g. AMD64_LINUX? - For when we extensively cross build. (soon?) I'll run sequentially for now. - Jay > Date: Sat, 17 Apr 2010 13:22:14 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: picking which files to package? > > You need to set STAGE differently if you want to run make-dist > for different targets on the same machine. It's been done for SOLgnu and > SOLsun, too. If you really want to build concurrently, you also need to > change INSTBASE before sourcing defs.sh. > > Olaf > > Quoting Jay K : > > > > > Olaf, any chance you can limit what files are picked up to the > > $TARGET and src directories? > > The I386_DARWIN/AMD64_DARWIN packages I made contain each of other's files > > due to just picking up "everything". > > > > Maybe: > > > > iff -u -r1.26.2.51 make-dist.sh > > --- make-dist.sh 17 Apr 2010 03:55:43 -0000 1.26.2.51 > > +++ make-dist.sh 17 Apr 2010 08:05:13 -0000 > > @@ -338,12 +338,16 @@ > > ) > collection-${c}.html > > echo "collection-${c}.html" > > ARCHIVE="${STAGE}/cm3-bin-ws-${c}-${TARGET}-${CM3VERSION}-${DS}.tgz" > > + a="" > > + for b in ${PKGS}; do > > + a="${a} ${b}/src ${b}/${TARGET}" > > + done > > if [ -z "${NOARCHIVE}" -a "${c}" != "min" ]; then > > "${TAR}" --exclude '*.o' --exclude '*.mo' --exclude '*.io' \ > > --exclude '*/CVS/*' --exclude '*/CVS' --exclude '*~' \ > > --exclude '*.tar.*' --exclude '*.tgz' --exclude "*/${TARGET}/gcc" \ > > --exclude "*/${TARGET}/*/*" \ > > - -czf "${ARCHIVE}" collection-${c}.html install.sh setup.txt > > setup.cmd ${PKGS} > > + -czf "${ARCHIVE}" collection-${c}.html install.sh setup.txt > > setup.cmd ${a} > > ls -l "${ARCHIVE}" > > fi > > done > > > > > > - Jay > > > > > > -- > 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 Sat Apr 17 14:34:34 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 17 Apr 2010 14:34:34 +0200 Subject: [M3devel] picking which files to package? In-Reply-To: References: , <20100417132214.a2z13qxcoc8g0gs4@mail.elegosoft.com> Message-ID: <20100417143434.lbf1epa6ec4kogsg@mail.elegosoft.com> Quoting Jay K : > > Can you maybe append TARGET to $STAGE, $INSTBASE, etc. consistently, > as needed, on all platforms? > - There are other bi/multiarch platforms? I'm not sure how widely > that notion has taken hold, e.g. AMD64_LINUX? > > - For when we extensively cross build. (soon?) > > I'll run sequentially for now. We can do that for the next builds. But let's be careful not to break the release tooling again. Olaf > - Jay > > >> Date: Sat, 17 Apr 2010 13:22:14 +0200 >> From: wagner at elegosoft.com >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: Re: picking which files to package? >> >> You need to set STAGE differently if you want to run make-dist >> for different targets on the same machine. It's been done for SOLgnu and >> SOLsun, too. If you really want to build concurrently, you also need to >> change INSTBASE before sourcing defs.sh. >> >> Olaf >> >> Quoting Jay K : >> >> > >> > Olaf, any chance you can limit what files are picked up to the >> > $TARGET and src directories? >> > The I386_DARWIN/AMD64_DARWIN packages I made contain each of other's files >> > due to just picking up "everything". >> > >> > Maybe: >> > >> > iff -u -r1.26.2.51 make-dist.sh >> > --- make-dist.sh 17 Apr 2010 03:55:43 -0000 1.26.2.51 >> > +++ make-dist.sh 17 Apr 2010 08:05:13 -0000 >> > @@ -338,12 +338,16 @@ >> > ) > collection-${c}.html >> > echo "collection-${c}.html" >> > ARCHIVE="${STAGE}/cm3-bin-ws-${c}-${TARGET}-${CM3VERSION}-${DS}.tgz" >> > + a="" >> > + for b in ${PKGS}; do >> > + a="${a} ${b}/src ${b}/${TARGET}" >> > + done >> > if [ -z "${NOARCHIVE}" -a "${c}" != "min" ]; then >> > "${TAR}" --exclude '*.o' --exclude '*.mo' --exclude '*.io' \ >> > --exclude '*/CVS/*' --exclude '*/CVS' --exclude '*~' \ >> > --exclude '*.tar.*' --exclude '*.tgz' --exclude "*/${TARGET}/gcc" \ >> > --exclude "*/${TARGET}/*/*" \ >> > - -czf "${ARCHIVE}" collection-${c}.html install.sh setup.txt >> > setup.cmd ${PKGS} >> > + -czf "${ARCHIVE}" collection-${c}.html install.sh setup.txt >> > setup.cmd ${a} >> > ls -l "${ARCHIVE}" >> > fi >> > done >> > >> > >> > - Jay >> > >> >> >> >> -- >> 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 Sat Apr 17 14:53:55 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 17 Apr 2010 08:53:55 -0400 Subject: [M3devel] release engineering 5.8: code generator error for IP address initializers In-Reply-To: References: <20100416114509.eh8r662dwss44oo8@mail.elegosoft.com>, , <20100416125048.183752ukg4os0kgk@mail.elegosoft.com> , <908A7AC8-565B-4749-A325-BE13F99F70D7@cs.purdue.edu> Message-ID: <64998360-2467-4204-9967-8C0B158FECC5@cs.purdue.edu> The RHS is a constant array *constructor*. On 16 Apr 2010, at 21:50, Jay K wrote: > There is this thing I read, where the types of values/constants are known without context. > The left hand side does not change the type of the right. > That confuses me here. It would imply the right is an open array. > > - Jay > > > Subject: Re: [M3devel] release engineering 5.8: code generator error for IP address initializers > From: hosking at cs.purdue.edu > Date: Fri, 16 Apr 2010 11:04:49 -0400 > CC: wagner at elegosoft.com; m3devel at elegosoft.com > To: jay.krell at cornell.edu > > You are confusing open array types with array constructors. > > On 16 Apr 2010, at 08:15, Jay K wrote: > > (back to the topic :) ) > > somewhat reduced case: > MODULE Main; > TYPE T1 = ARRAY [0..0] OF INTEGER; > CONST const: T1 = ARRAY OF INTEGER{2}; > > This is an array constructor. > > I suspect this is the same issue as in my previous e-mail. The following concise rewrite should work: > > CONST const = T1{2}; > > BEGIN > END Main. > > The problem is two global integers are overlapping. > The open array size and its first element. > > new source -> compiling Main.m3 > "..\Main.m3", line 5: warning: not used (const) > m3front:cg:Init_int:NOT in_init: o: 32 s:32 value:2 <== > m3front:cg:Init_int:NOT in_init: o: 32 s:32 value:1 <== > m3front:cg:Init_int:NOT in_init: o: 384 s:32 value:3 > m3front:cg:Init_int:in_init: o: 32 s:32 value:1 > m3front:cg:Init_int:in_init: o: 32 s:32 value:2 > > Are these syntaxes legal? > This apparent mixing of open and fixed arrays? > > - Jay > > > > Date: Fri, 16 Apr 2010 12:50:48 +0200 > > From: wagner at elegosoft.com > > To: jay.krell at cornell.edu > > CC: m3devel at elegosoft.com > > Subject: RE: [M3devel] release engineering 5.8: code generator error for IP address initializers > > > > I agree. Regular expressions in quake would be great for regression tests. > > Perhaps for the next release? > > > > Olaf > > > > Quoting Jay K : > > > > > "aside": > > > > > > http://hudson.modula3.com:8080/job/cm3-test-m3tests-AMD64_FREEBSD/lastBuild/testReport/(root)/m3tests/p206__ARRAY_constructors_in_var_decls_using_named_open_array_types/ > > > > > > http://hudson.modula3.com:8080/job/cm3-test-m3tests-AMD64_FREEBSD/lastBuild/testReport/(root)/m3tests/r004__negative_size_for_an_open_array/ > > > > > > > > > It'd be nice if in Quake we had something regular expression-ish, so > > > that we could factor out the line numbers, such as e.g. to match > > > any decimal number. > > > > > > > > > Maybe just check for lines that start how we expect and cut them off > > > at some position. > > > That might be doable with today's Quake. > > > > > > > > > > > > - Jay > > > > > > > > > > > >> Date: Fri, 16 Apr 2010 11:45:09 +0200 > > >> From: wagner at elegosoft.com > > >> To: m3devel at elegosoft.com > > >> Subject: [M3devel] release engineering 5.8: code generator error > > >> for IP address initializers > > >> > > >> We also have this error, which should perhaps not be ignored? > > >> > > >> http://hudson.modula3.com:8080/job/cm3-test-m3tests-AMD64_FREEBSD/lastBuild/testReport/(root)/m3tests/p204__IP_address_initializers > > >> > > >> 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 > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Sat Apr 17 02:41:34 2010 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sat, 17 Apr 2010 00:41:34 +0000 (GMT) Subject: [M3devel] About problem compiling with cm3-bin-core-AMD64_LINUX-5.8.5-RC5 Message-ID: <493637.42836.qm@web23603.mail.ird.yahoo.com> Hi all: I think I made a silly mistake I did compile the d5.7 tree so I guess m3cc is different than of the current RC5 m3cc. If you have a md5sum of RC5 please put it in the web page. I'm rebuilding it again now with the RC5 tree, so far it looks good. Thanks for your attention, --- El vie, 16/4/10, Daniel Alejandro Benavides D. escribi?: > De: Daniel Alejandro Benavides D. > Asunto: About problem compiling with cm3-bin-core-AMD64_LINUX-5.8.5-RC5 > Para: m3devel at elegosoft.com > Fecha: viernes, 16 de abril, 2010 19:18 > Hi all: > I'm trying to build in kubuntu karmic 9.10 the RC5 but got > early after compiling succesfully m3cc in this output a > problem at: > "internal compiler error: in emit_move_insn, at > expr.c:3379 > > > > > " > The file I downloaded has the following md5sum, is that > correct?: > d9ac8a12cdeccb8b5d7ee856c113366f > cm3-bin-core-AMD64_LINUX-5.8.5-RC5.tgz > > Could you suggest me something to do here? > Thanks in advance > > root at mm01:/home/dabenavidesd/code/cm3/scripts# ./do-pkg.sh > buildship m3core libm3 m3middle m3linker m3front sysutils > m3quake m3objfile m3back cm3 > > > > /home/dabenavidesd/code/cm3/scripts/pkgmap.sh -c > "/usr/local/cm3/bin/cm3 -build > -DROOT='/home/dabenavidesd/code/cm3' > -DCM3_VERSION_TEXT='d5.7.0' -DCM3_VERSION_NUMBER='050700' > -DCM3_LAST_CHANGED='2008-03-16' && > /usr/local/cm3/bin/cm3 -ship > -DROOT='/home/dabenavidesd/code/cm3' > -DCM3_VERSION_TEXT='d5.7.0' -DCM3_VERSION_NUMBER='050700' > -DCM3_LAST_CHANGED='2008-03-16' " m3core libm3 m3middle > m3linker m3front sysutils m3quake m3objfile m3back cm3 > > === package /home/dabenavidesd/code/cm3/m3-libs/m3core > === > > > +++ /usr/local/cm3/bin/cm3 -build > -DROOT='/home/dabenavidesd/code/cm3' > -DCM3_VERSION_TEXT='d5.7.0' -DCM3_VERSION_NUMBER='050700' > -DCM3_LAST_CHANGED='2008-03-16' && > /usr/local/cm3/bin/cm3 -ship > -DROOT='/home/dabenavidesd/code/cm3' > -DCM3_VERSION_TEXT='d5.7.0' -DCM3_VERSION_NUMBER='050700' > -DCM3_LAST_CHANGED='2008-03-16' +++ > > > > --- building in AMD64_LINUX --- > > > > > > ignoring ../src/m3overrides > > new source -> compiling RTHooks.i3 > new source -> compiling RT0.i3 > new source -> compiling RuntimeError.i3 > new source -> compiling WordRep.i3 > > new source -> compiling Word.i3 > > new source -> compiling RTException.i3 > new source -> compiling RTHooks.m3 > > ../src/runtime/common/RTHooks.m3: In function > 'RTHooks__ReportFault': > ../src/runtime/common/RTHooks.m3:95: internal compiler > error: in emit_move_insn, at expr.c:3379 > > > > > > > Please submit a full bug report, > > > > > with preprocessed source if appropriate. > > > > See for > instructions. > > > m3_backend => 4 > > > > > > m3cc (aka cm3cg) failed compiling: RTHooks.mc > > > > new source -> compiling RT0.m3 > > > > > new source -> compiling Compiler.i3 > > > > > new source -> compiling RuntimeError.m3 > > > > > ../src/runtime/common/RuntimeError.m3: In function > 'RuntimeError__Self': > > ../src/runtime/common/RuntimeError.m3:13: internal compiler > error: in int_mode_for_mode, at stor-layout.c:258 > > > > > > Please submit a full bug report, > > > > > with preprocessed source if appropriate. > > > > See for > instructions. > > > m3_backend => 4 > > > > > > m3cc (aka cm3cg) failed compiling: RuntimeError.mc > > > > > From jay.krell at cornell.edu Sat Apr 17 17:08:04 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 17 Apr 2010 15:08:04 +0000 Subject: [M3devel] getting mac address with netbios Message-ID: We have this code: C:\dev2\cm3.2\m3-libs\libm3\src\uid\WIN32\MachineIDWin32.m3(33): EVAL NB30.Netbios(ADR(ncb)); C:\dev2\cm3.2\m3-libs\libm3\src\uid\WIN32\MachineIDWin32.m3(41): EVAL NB30.Netbios(ADR(ncb)); C:\dev2\cm3.2\m3-libs\libm3\src\uid\WIN32\MachineIDWin32.m3(48): EVAL NB30.Netbios(ADR(ncb)); I just noticed: http://msdn.microsoft.com/en-us/library/bb870913(VS.85).aspx [Netbios is not supported on Windows Vista, Windows Server 2008, and subsequent versions of the operating system] someone should try this out.. and change it to work if needed.. http://www.codeguru.com/Cpp/I-N/network/networkinformation/article.php/c5451 I'm pretty partial to the UuidCreate/UuidCreateSequential solution really. This MachineID probably needs more work anyway -- support for more operating systems. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.async.caltech.edu Sat Apr 17 19:40:28 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Sat, 17 Apr 2010 10:40:28 -0700 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <7430A649-C3AF-4D02-A943-46844E2323D7@cs.purdue.edu> References: <20100417111631.901C22474008@birch.elegosoft.com> <7430A649-C3AF-4D02-A943-46844E2323D7@cs.purdue.edu> Message-ID: <20100417174028.41B551A20FA@async.async.caltech.edu> Tony Hosking writes: >I actually still have an ALPHA_OSF box that I sometimes think of = >resurrecting. Is it really dead? ;-) Me, too. Furthermore, I (and the Internet) have a binary for the Extended Static Checker for Modula-3 for OSF/1 on Alpha. Not sure it exists in any other form nowadays... :-/ Mika > >On 17 Apr 2010, at 13:16, Jay Krell wrote: > >> CVSROOT: /usr/cvs >> Changes by: jkrell at birch. 10/04/17 13:16:31 >>=20 >> Removed files: >> cm3/m3-libs/m3core/src/C/: ChangeLog=20 >> cm3/m3-libs/m3core/src/C/AIX386/: Csetjmp.i3 m3makefile=20 >> cm3/m3-libs/m3core/src/C/ALPHA_OSF/: Csetjmp.i3 m3makefile=20 >> cm3/m3-libs/m3core/src/C/AP3000/: Csetjmp.i3 m3makefile=20 >> cm3/m3-libs/m3core/src/C/ARM/: Csetjmp.i3 m3makefile=20 >> cm3/m3-libs/m3core/src/C/DS3100/: Csetjmp.i3 m3makefile=20 >> cm3/m3-libs/m3core/src/C/FreeBSD/: COPYRIGHT Csetjmp.i3=20 >> m3makefile=20 >> cm3/m3-libs/m3core/src/C/FreeBSD2/: Csetjmp.i3 m3makefile=20 >> cm3/m3-libs/m3core/src/C/FreeBSD3/: COPYRIGHT Csetjmp.i3=20 >> m3makefile=20 >> cm3/m3-libs/m3core/src/C/HP300/: Csetjmp.i3 m3makefile=20 >> cm3/m3-libs/m3core/src/C/HPPA/: Csetjmp.i3 m3makefile=20 >> cm3/m3-libs/m3core/src/C/IBMR2/: Csetjmp.i3 m3makefile=20 >> cm3/m3-libs/m3core/src/C/IBMRT/: Csetjmp.i3 m3makefile=20 >> cm3/m3-libs/m3core/src/C/IRIX5/: Csetjmp.i3 m3makefile=20 >> cm3/m3-libs/m3core/src/C/LINUX/: Csetjmp.i3 m3makefile=20 >> cm3/m3-libs/m3core/src/C/LINUXELF/: Csetjmp.i3 m3makefile=20 >> cm3/m3-libs/m3core/src/C/NEXT/: Csetjmp.i3 m3makefile=20 >> cm3/m3-libs/m3core/src/C/OKI/: Csetjmp.i3 m3makefile setjmp.s=20 >> signal.o=20 >> cm3/m3-libs/m3core/src/C/OS2/: Csetjmp.i3 m3makefile=20 >> cm3/m3-libs/m3core/src/C/SEQUENT/: Csetjmp.i3 m3makefile=20 >> cm3/m3-libs/m3core/src/C/SPARC/: Csetjmp.i3 m3makefile=20 >> cm3/m3-libs/m3core/src/C/SUN3/: Csetjmp.i3 m3makefile=20 >> cm3/m3-libs/m3core/src/C/SUN386/: Csetjmp.i3 m3makefile=20 >> cm3/m3-libs/m3core/src/C/VAX/: Csetjmp.i3 m3makefile=20 >>=20 >> Log message: >> delete lots of dead/dormant platforms, even some that *might* = >come back >> It is easy enough to bring them back. From mika at async.async.caltech.edu Sat Apr 17 20:35:54 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Sat, 17 Apr 2010 11:35:54 -0700 Subject: [M3devel] example of bug in NetObj Stub Generator In-Reply-To: References: , , <7C7408D0-9A40-4988-BADA-A9FD8C15D388@cs.purdue.edu>, , Message-ID: <20100417183554.431441A20FA@async.async.caltech.edu> Hi Randy, The issue is that RECORDs are marshalled "manually" by the stub code, rather than being passed as a Pickle. Therefore, imports are needed for record fields. The change that is needed is the following: Line 291 of CodeForType.m3, currently IF byName AND t.name # NIL THEN change to IF NOT ISTYPE(t,Type.Record) AND byName AND t.name # NIL THEN I would commit this myself but I have lost track of my non-anon CM3 checkout. Can someone do the honors, please? Mika P.S. It is possible the fix is a bit pessimistic, not sure the literal type name is required for every type of record field. Worst-case breakage: stub code generates a warning when compiled. From dabenavidesd at yahoo.es Sat Apr 17 02:18:27 2010 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sat, 17 Apr 2010 00:18:27 +0000 (GMT) Subject: [M3devel] About problem compiling with cm3-bin-core-AMD64_LINUX-5.8.5-RC5 Message-ID: <316058.64510.qm@web23604.mail.ird.yahoo.com> Hi all: I'm trying to build in kubuntu karmic 9.10 the RC5 but got early after compiling succesfully m3cc in this output a problem at: "internal compiler error: in emit_move_insn, at expr.c:3379 " The file I downloaded has the following md5sum, is that correct?: d9ac8a12cdeccb8b5d7ee856c113366f cm3-bin-core-AMD64_LINUX-5.8.5-RC5.tgz Could you suggest me something to do here? Thanks in advance root at mm01:/home/dabenavidesd/code/cm3/scripts# ./do-pkg.sh buildship m3core libm3 m3middle m3linker m3front sysutils m3quake m3objfile m3back cm3 /home/dabenavidesd/code/cm3/scripts/pkgmap.sh -c "/usr/local/cm3/bin/cm3 -build -DROOT='/home/dabenavidesd/code/cm3' -DCM3_VERSION_TEXT='d5.7.0' -DCM3_VERSION_NUMBER='050700' -DCM3_LAST_CHANGED='2008-03-16' && /usr/local/cm3/bin/cm3 -ship -DROOT='/home/dabenavidesd/code/cm3' -DCM3_VERSION_TEXT='d5.7.0' -DCM3_VERSION_NUMBER='050700' -DCM3_LAST_CHANGED='2008-03-16' " m3core libm3 m3middle m3linker m3front sysutils m3quake m3objfile m3back cm3 === package /home/dabenavidesd/code/cm3/m3-libs/m3core === +++ /usr/local/cm3/bin/cm3 -build -DROOT='/home/dabenavidesd/code/cm3' -DCM3_VERSION_TEXT='d5.7.0' -DCM3_VERSION_NUMBER='050700' -DCM3_LAST_CHANGED='2008-03-16' && /usr/local/cm3/bin/cm3 -ship -DROOT='/home/dabenavidesd/code/cm3' -DCM3_VERSION_TEXT='d5.7.0' -DCM3_VERSION_NUMBER='050700' -DCM3_LAST_CHANGED='2008-03-16' +++ --- building in AMD64_LINUX --- ignoring ../src/m3overrides new source -> compiling RTHooks.i3 new source -> compiling RT0.i3 new source -> compiling RuntimeError.i3 new source -> compiling WordRep.i3 new source -> compiling Word.i3 new source -> compiling RTException.i3 new source -> compiling RTHooks.m3 ../src/runtime/common/RTHooks.m3: In function 'RTHooks__ReportFault': ../src/runtime/common/RTHooks.m3:95: internal compiler error: in emit_move_insn, at expr.c:3379 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. m3_backend => 4 m3cc (aka cm3cg) failed compiling: RTHooks.mc new source -> compiling RT0.m3 new source -> compiling Compiler.i3 new source -> compiling RuntimeError.m3 ../src/runtime/common/RuntimeError.m3: In function 'RuntimeError__Self': ../src/runtime/common/RuntimeError.m3:13: internal compiler error: in int_mode_for_mode, at stor-layout.c:258 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. m3_backend => 4 m3cc (aka cm3cg) failed compiling: RuntimeError.mc From jay.krell at cornell.edu Sun Apr 18 00:50:28 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 17 Apr 2010 22:50:28 +0000 Subject: [M3devel] About problem compiling with cm3-bin-core-AMD64_LINUX-5.8.5-RC5 In-Reply-To: <316058.64510.qm@web23604.mail.ird.yahoo.com> References: <316058.64510.qm@web23604.mail.ird.yahoo.com> Message-ID: (probably the mail arrived out of order?) From: jay.krell at cornell.edu To: dabenavidesd at yahoo.es; m3devel at elegosoft.com Subject: RE: [M3devel] About problem compiling with cm3-bin-core-AMD64_LINUX-5.8.5-RC5 Date: Sat, 17 Apr 2010 22:49:34 +0000 Daniel, As your other mail indicated, you are building some old source. >> DCM3_VERSION_TEXT='d5.7.0' -DCM3_VERSION_NUMBER='050700' -DCM3_LAST_CHANGED='2008-03-16' Please try head or release. (Head doesn't even pass these -D version switches any more, but release does). "install" almost any release export PATH=/usr/local/cm3/bin:$PATH cvs -z3 checkout ... cd .../scripts/python ./upgrade.py ./do-cm3-all.py skipgcc realclean ./do-cm3-all.py skipgcc buildship (upgrade.py only builds the compiler and the libraries it uses; upgrade.sh builds everything) (Granted, whatever tree you are using, should work, but...) - Jay > Date: Sat, 17 Apr 2010 00:18:27 +0000 > From: dabenavidesd at yahoo.es > To: m3devel at elegosoft.com > Subject: [M3devel] About problem compiling with cm3-bin-core-AMD64_LINUX-5.8.5-RC5 > > Hi all: > I'm trying to build in kubuntu karmic 9.10 the RC5 but got early after compiling succesfully m3cc in this output a problem at: > "internal compiler error: in emit_move_insn, at expr.c:3379 " > The file I downloaded has the following md5sum, is that correct?: > d9ac8a12cdeccb8b5d7ee856c113366f cm3-bin-core-AMD64_LINUX-5.8.5-RC5.tgz > > Could you suggest me something to do here? > Thanks in advance > > root at mm01:/home/dabenavidesd/code/cm3/scripts# ./do-pkg.sh buildship m3core libm3 m3middle m3linker m3front sysutils m3quake m3objfile m3back cm3 > /home/dabenavidesd/code/cm3/scripts/pkgmap.sh -c "/usr/local/cm3/bin/cm3 -build -DROOT='/home/dabenavidesd/code/cm3' -DCM3_VERSION_TEXT='d5.7.0' -DCM3_VERSION_NUMBER='050700' -DCM3_LAST_CHANGED='2008-03-16' && /usr/local/cm3/bin/cm3 -ship -DROOT='/home/dabenavidesd/code/cm3' -DCM3_VERSION_TEXT='d5.7.0' -DCM3_VERSION_NUMBER='050700' -DCM3_LAST_CHANGED='2008-03-16' " m3core libm3 m3middle m3linker m3front sysutils m3quake m3objfile m3back cm3 > === package /home/dabenavidesd/code/cm3/m3-libs/m3core === > +++ /usr/local/cm3/bin/cm3 -build -DROOT='/home/dabenavidesd/code/cm3' -DCM3_VERSION_TEXT='d5.7.0' -DCM3_VERSION_NUMBER='050700' -DCM3_LAST_CHANGED='2008-03-16' && /usr/local/cm3/bin/cm3 -ship -DROOT='/home/dabenavidesd/code/cm3' -DCM3_VERSION_TEXT='d5.7.0' -DCM3_VERSION_NUMBER='050700' -DCM3_LAST_CHANGED='2008-03-16' +++ > --- building in AMD64_LINUX --- > > ignoring ../src/m3overrides > > new source -> compiling RTHooks.i3 > new source -> compiling RT0.i3 > new source -> compiling RuntimeError.i3 > new source -> compiling WordRep.i3 > new source -> compiling Word.i3 > new source -> compiling RTException.i3 > new source -> compiling RTHooks.m3 > ../src/runtime/common/RTHooks.m3: In function 'RTHooks__ReportFault': > ../src/runtime/common/RTHooks.m3:95: internal compiler error: in emit_move_insn, at expr.c:3379 > Please submit a full bug report, > with preprocessed source if appropriate. > See for instructions. > m3_backend => 4 > m3cc (aka cm3cg) failed compiling: RTHooks.mc > new source -> compiling RT0.m3 > new source -> compiling Compiler.i3 > new source -> compiling RuntimeError.m3 > ../src/runtime/common/RuntimeError.m3: In function 'RuntimeError__Self': > ../src/runtime/common/RuntimeError.m3:13: internal compiler error: in int_mode_for_mode, at stor-layout.c:258 > Please submit a full bug report, > with preprocessed source if appropriate. > See for instructions. > m3_backend => 4 > m3cc (aka cm3cg) failed compiling: RuntimeError.mc > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Apr 18 00:49:34 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 17 Apr 2010 22:49:34 +0000 Subject: [M3devel] About problem compiling with cm3-bin-core-AMD64_LINUX-5.8.5-RC5 In-Reply-To: <316058.64510.qm@web23604.mail.ird.yahoo.com> References: <316058.64510.qm@web23604.mail.ird.yahoo.com> Message-ID: Daniel, As your other mail indicated, you are building some old source. >> DCM3_VERSION_TEXT='d5.7.0' -DCM3_VERSION_NUMBER='050700' -DCM3_LAST_CHANGED='2008-03-16' Please try head or release. (Head doesn't even pass these -D version switches any more, but release does). "install" almost any release export PATH=/usr/local/cm3/bin:$PATH cvs -z3 checkout ... cd .../scripts/python ./upgrade.py ./do-cm3-all.py skipgcc realclean ./do-cm3-all.py skipgcc buildship (upgrade.py only builds the compiler and the libraries it uses; upgrade.sh builds everything) (Granted, whatever tree you are using, should work, but...) - Jay > Date: Sat, 17 Apr 2010 00:18:27 +0000 > From: dabenavidesd at yahoo.es > To: m3devel at elegosoft.com > Subject: [M3devel] About problem compiling with cm3-bin-core-AMD64_LINUX-5.8.5-RC5 > > Hi all: > I'm trying to build in kubuntu karmic 9.10 the RC5 but got early after compiling succesfully m3cc in this output a problem at: > "internal compiler error: in emit_move_insn, at expr.c:3379 " > The file I downloaded has the following md5sum, is that correct?: > d9ac8a12cdeccb8b5d7ee856c113366f cm3-bin-core-AMD64_LINUX-5.8.5-RC5.tgz > > Could you suggest me something to do here? > Thanks in advance > > root at mm01:/home/dabenavidesd/code/cm3/scripts# ./do-pkg.sh buildship m3core libm3 m3middle m3linker m3front sysutils m3quake m3objfile m3back cm3 > /home/dabenavidesd/code/cm3/scripts/pkgmap.sh -c "/usr/local/cm3/bin/cm3 -build -DROOT='/home/dabenavidesd/code/cm3' -DCM3_VERSION_TEXT='d5.7.0' -DCM3_VERSION_NUMBER='050700' -DCM3_LAST_CHANGED='2008-03-16' && /usr/local/cm3/bin/cm3 -ship -DROOT='/home/dabenavidesd/code/cm3' -DCM3_VERSION_TEXT='d5.7.0' -DCM3_VERSION_NUMBER='050700' -DCM3_LAST_CHANGED='2008-03-16' " m3core libm3 m3middle m3linker m3front sysutils m3quake m3objfile m3back cm3 > === package /home/dabenavidesd/code/cm3/m3-libs/m3core === > +++ /usr/local/cm3/bin/cm3 -build -DROOT='/home/dabenavidesd/code/cm3' -DCM3_VERSION_TEXT='d5.7.0' -DCM3_VERSION_NUMBER='050700' -DCM3_LAST_CHANGED='2008-03-16' && /usr/local/cm3/bin/cm3 -ship -DROOT='/home/dabenavidesd/code/cm3' -DCM3_VERSION_TEXT='d5.7.0' -DCM3_VERSION_NUMBER='050700' -DCM3_LAST_CHANGED='2008-03-16' +++ > --- building in AMD64_LINUX --- > > ignoring ../src/m3overrides > > new source -> compiling RTHooks.i3 > new source -> compiling RT0.i3 > new source -> compiling RuntimeError.i3 > new source -> compiling WordRep.i3 > new source -> compiling Word.i3 > new source -> compiling RTException.i3 > new source -> compiling RTHooks.m3 > ../src/runtime/common/RTHooks.m3: In function 'RTHooks__ReportFault': > ../src/runtime/common/RTHooks.m3:95: internal compiler error: in emit_move_insn, at expr.c:3379 > Please submit a full bug report, > with preprocessed source if appropriate. > See for instructions. > m3_backend => 4 > m3cc (aka cm3cg) failed compiling: RTHooks.mc > new source -> compiling RT0.m3 > new source -> compiling Compiler.i3 > new source -> compiling RuntimeError.m3 > ../src/runtime/common/RuntimeError.m3: In function 'RuntimeError__Self': > ../src/runtime/common/RuntimeError.m3:13: internal compiler error: in int_mode_for_mode, at stor-layout.c:258 > Please submit a full bug report, > with preprocessed source if appropriate. > See for instructions. > m3_backend => 4 > m3cc (aka cm3cg) failed compiling: RuntimeError.mc > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.async.caltech.edu Sun Apr 18 04:35:35 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Sat, 17 Apr 2010 19:35:35 -0700 Subject: [M3devel] INTEGER In-Reply-To: References: , , <7C7408D0-9A40-4988-BADA-A9FD8C15D388@cs.purdue.edu>, , Message-ID: <20100418023535.3BA9E1A2103@async.async.caltech.edu> Ok, sorry if I am beating a dead horse here. What is INTEGER on a 64-bit machine? Modula-3 doesn't specify it to be one or the other does it? But normally, 64 bits? I am asking because I was looking through some stub generator code, and I'm really wondering about the LONGINT. Now there are "longcard" things showing up, which means another set of changes to a lot of code. The rationale for LONGINT is, again? We need it to match 64-bit integers on 32-bit machines? That seems like a very weak rationale indeed, if the same functionality could be provided through some other mechanism (e.g., ARRAY [0..1] OF INTEGER---even with a pragma e.g. <*CLONGLONG*>.. if it is necessary to tell the compiler that a special linkage convention is needed). On a 64-bit machine INTEGER and CARDINAL are 64/63 bits (right?), so there is really no need for LONGINT there. And having an array with a LONGINT index seems silly since you can't address more memory than you can fit in an INTEGER anyhow... Mika >________________________________ >From: hosking at cs.purdue.edu >Date: Thu, 15 Apr 2010 12:55:52 -0400 >To: jay.krell at cornell.edu >CC: m3devel at elegosoft.com >Subject: Re: [M3devel] Modula-3/C interop in Date/Time? >Excepting that INTEGER is not the same as int on 64-bit platforms. > >Antony Hosking | Associate Professor | Computer Science | Purdue University >305 N. University Street | West Lafayette | IN 47907 | USA >Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > >On 15 Apr 2010, at 02:45, Jay K wrote: > >Is this legal/correct? > > >Date.i3: >TYPE TimeZone <: REFANY; >VAR Local, UTC: TimeZone; (* granted, will maybe change these to extern *) > > >Date.m3:=1B$B!!=1B(B >REVEAL TimeZone =3D BRANDED "Date.TimeZone" REF INTEGER; >=1B$B!!=1B(B > >DatePosixC.c: >static const int Local =3D 0; >static const int UTC =3D 1; >extern const int const * const Date__Local =3D &Local; >extern const int const * const Date__UTC =3D &UTC; >=1B$B!!=1B(B > >- Jay From hosking at cs.purdue.edu Sun Apr 18 04:40:20 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 17 Apr 2010 22:40:20 -0400 Subject: [M3devel] INTEGER In-Reply-To: <20100418023535.3BA9E1A2103@async.async.caltech.edu> References: , , <7C7408D0-9A40-4988-BADA-A9FD8C15D388@cs.purdue.edu>, , <20100418023535.3BA9E1A2103@async.async.caltech.edu> Message-ID: On 17 Apr 2010, at 22:35, Mika Nystrom wrote: > Ok, sorry if I am beating a dead horse here. > > What is INTEGER on a 64-bit machine? The language spec doesn't say, but CM3 pretty strongly assumes BITSIZE(INTEGER)=BITSIZE(ADDRESS). So, that means 64 bits. > Modula-3 doesn't specify it to be one or the other does it? > But normally, 64 bits? > > I am asking because I was looking through some stub generator code, > and I'm really wondering about the LONGINT. Now there are "longcard" > things showing up, which means another set of changes to a lot of code. > > The rationale for LONGINT is, again? Yes, LONGINT is to permit longer than "efficient" INTEGER. Mainly for 32 bit machines where we'd like to have a C "long long" equivalent. > We need it to match 64-bit integers on 32-bit machines? That seems like > a very weak rationale indeed, if the same functionality could be provided > through some other mechanism (e.g., ARRAY [0..1] OF INTEGER---even with > a pragma e.g. <*CLONGLONG*>.. if it is necessary to tell the compiler that > a special linkage convention is needed). There's no special linkage convention. Not sure what you mean here. > On a 64-bit machine INTEGER and CARDINAL are 64/63 bits (right?), so > there is really no need for LONGINT there. True. The only expectation is BITSIZE(LONGINT) >= BITSIZE(INTEGER). > And having an array with a LONGINT index seems silly since you can't > address more memory than you can fit in an INTEGER anyhow... We don't allow arrays with LONGINT indexes in the current implementation. > > Mika > >> ________________________________ >> From: hosking at cs.purdue.edu >> Date: Thu, 15 Apr 2010 12:55:52 -0400 >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] Modula-3/C interop in Date/Time? >> Excepting that INTEGER is not the same as int on 64-bit platforms. >> >> Antony Hosking | Associate Professor | Computer Science | Purdue University >> 305 N. University Street | West Lafayette | IN 47907 | USA >> Office +1 765 494 6001 | Mobile +1 765 427 5484 >> >> >> >> >> On 15 Apr 2010, at 02:45, Jay K wrote: >> >> Is this legal/correct? >> >> >> Date.i3: >> TYPE TimeZone <: REFANY; >> VAR Local, UTC: TimeZone; (* granted, will maybe change these to extern *) >> >> >> Date.m3:=1B$B!!=1B(B >> REVEAL TimeZone =3D BRANDED "Date.TimeZone" REF INTEGER; >> =1B$B!!=1B(B >> >> DatePosixC.c: >> static const int Local =3D 0; >> static const int UTC =3D 1; >> extern const int const * const Date__Local =3D &Local; >> extern const int const * const Date__UTC =3D &UTC; >> =1B$B!!=1B(B >> >> - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Apr 18 04:46:17 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 17 Apr 2010 22:46:17 -0400 Subject: [M3devel] INTEGER In-Reply-To: References: , , <7C7408D0-9A40-4988-BADA-A9FD8C15D388@cs.purdue.edu>, , <20100418023535.3BA9E1A2103@async.async.caltech.edu> Message-ID: <8604EE57-9661-4F82-BB51-DBFDC93844DC@cs.purdue.edu> On 17 Apr 2010, at 22:40, Tony Hosking wrote: > > On 17 Apr 2010, at 22:35, Mika Nystrom wrote: > >> Ok, sorry if I am beating a dead horse here. >> >> What is INTEGER on a 64-bit machine? > > The language spec doesn't say, but CM3 pretty strongly assumes BITSIZE(INTEGER)=BITSIZE(ADDRESS). > So, that means 64 bits. > >> Modula-3 doesn't specify it to be one or the other does it? >> But normally, 64 bits? >> >> I am asking because I was looking through some stub generator code, >> and I'm really wondering about the LONGINT. Now there are "longcard" >> things showing up, which means another set of changes to a lot of code. >> >> The rationale for LONGINT is, again? > > Yes, LONGINT is to permit longer than "efficient" INTEGER. Mainly for 32 bit machines where we'd like to have a C "long long" equivalent. > >> We need it to match 64-bit integers on 32-bit machines? That seems like >> a very weak rationale indeed, if the same functionality could be provided >> through some other mechanism (e.g., ARRAY [0..1] OF INTEGER---even with >> a pragma e.g. <*CLONGLONG*>.. if it is necessary to tell the compiler that >> a special linkage convention is needed). > > There's no special linkage convention. Not sure what you mean here. > >> On a 64-bit machine INTEGER and CARDINAL are 64/63 bits (right?), so >> there is really no need for LONGINT there. > > True. The only expectation is BITSIZE(LONGINT) >= BITSIZE(INTEGER). > >> And having an array with a LONGINT index seems silly since you can't >> address more memory than you can fit in an INTEGER anyhow... > > We don't allow arrays with LONGINT indexes in the current implementation. Correction. We do allow arrays with LONGINT subrange indexes, but the restriction is that NUMBER be representable as an INTEGER. > >> >> Mika >> >>> ________________________________ >>> From: hosking at cs.purdue.edu >>> Date: Thu, 15 Apr 2010 12:55:52 -0400 >>> To: jay.krell at cornell.edu >>> CC: m3devel at elegosoft.com >>> Subject: Re: [M3devel] Modula-3/C interop in Date/Time? >>> Excepting that INTEGER is not the same as int on 64-bit platforms. >>> >>> Antony Hosking | Associate Professor | Computer Science | Purdue University >>> 305 N. University Street | West Lafayette | IN 47907 | USA >>> Office +1 765 494 6001 | Mobile +1 765 427 5484 >>> >>> >>> >>> >>> On 15 Apr 2010, at 02:45, Jay K wrote: >>> >>> Is this legal/correct? >>> >>> >>> Date.i3: >>> TYPE TimeZone <: REFANY; >>> VAR Local, UTC: TimeZone; (* granted, will maybe change these to extern *) >>> >>> >>> Date.m3:=1B$B!!=1B(B >>> REVEAL TimeZone =3D BRANDED "Date.TimeZone" REF INTEGER; >>> =1B$B!!=1B(B >>> >>> DatePosixC.c: >>> static const int Local =3D 0; >>> static const int UTC =3D 1; >>> extern const int const * const Date__Local =3D &Local; >>> extern const int const * const Date__UTC =3D &UTC; >>> =1B$B!!=1B(B >>> >>> - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.async.caltech.edu Sun Apr 18 04:47:03 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Sat, 17 Apr 2010 19:47:03 -0700 Subject: [M3devel] INTEGER In-Reply-To: References: , , <7C7408D0-9A40-4988-BADA-A9FD8C15D388@cs.purdue.edu>, , <20100418023535.3BA9E1A2103@async.async.caltech.edu> Message-ID: <20100418024703.6965B1A2103@async.async.caltech.edu> Tony Hosking writes: > ... > >> We need it to match 64-bit integers on 32-bit machines? That seems = >like >> a very weak rationale indeed, if the same functionality could be = >provided >> through some other mechanism (e.g., ARRAY [0..1] OF INTEGER---even = >with >> a pragma e.g. <*CLONGLONG*>.. if it is necessary to tell the compiler = >that >> a special linkage convention is needed). > >There's no special linkage convention. Not sure what you mean here. > I just mean if we had TYPE LONGINT = ARRAY [0..1] OF INTEGER that would perhaps not match how C handles "long long" on the same platform (which is how, come to think of it?), and that would require special linkage tricks. But what would be lost? The ability to type literals. You could get the same code interface on 32- and 64-bit machine by defining TYPE FileOffset = ARRAY[0..1] OF [-16_80000000 .. +16_7fffffff ] and using that. Mika From jay.krell at cornell.edu Sun Apr 18 09:14:14 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 18 Apr 2010 07:14:14 +0000 Subject: [M3devel] INTEGER In-Reply-To: <20100418024703.6965B1A2103@async.async.caltech.edu> References: , , , <7C7408D0-9A40-4988-BADA-A9FD8C15D388@cs.purdue.edu>, , , , , , , <20100418023535.3BA9E1A2103@async.async.caltech.edu>, , <20100418024703.6965B1A2103@async.async.caltech.edu> Message-ID: TYPE LONGINT = ARRAY [0..1] OF INTEGER on a 32bit system is very close to LONGINT. Plus treating it opaquely and providing a bunch of functions to operate on it. Just as well therefore could be RECORD hi,lo:LONGINT END (see LARGE_INTEGER and ULARGE_INTEGER in winnt.h) Differences that come to mind: infix operators <=== possibly passed differently as a parameter or returned differently as a result ie. probably "directly compatible with" "long long", passed by value (of course you could always pass by pointer and achieve compatibilitity trivially) I have to say though, the biggest reason is in-fix operators. Convenient syntax. C++ is the best and some way worst of example of the general right way to do this -- you let programmers define types and their infix operators. Other languages just come with a passle of special cases of types that have in-fix operators. A good example is that Java infix operator + on string, besides the various integers, and nothing else. I think C# lets you define operators, yet people don't complain that it is "a mess" as they do of C++. I think Python does now too. So it is feature growing in popularity among "mainstream" languages, not just C++. C++ of course is extremely mainstream, but also a favorite target. (http://www.relisoft.com/tools/CppCritic.html) We also have subranges of LONGINT. I'm not sure what the generalization of subranges are, granted. Maybe some sort of C++ template that takes constants in the template and does range checks at runtime. Yeah, maybe. And as you point out, convenient literal syntax. People reasonably argue for library extension in place of language extension, but that requires a language which is flexible enough to write libraries with the desired interface, and so many languages don't let infix operators be in a user-written library. (There is a subtle but useless distinction here -- infix operators being in libraries vs. "user-written" libraries. The infix set operations for example are in a library, but not user-written, special, the compiler knows about it.) > that would perhaps not match how C handles "long long" on the same > platform (which is how, come to think of it?), and that would require On NT/x86, __int64/long long is returned in the register pair edx:eax. edx is high, eax is low. When passed as a parameter to __stdcall or __cdecl is just passed as two 32bit values adjacent on the stack, "hi, lo, hi, lo, it's off to push we go" is the Snow White-influenced mantra to remember how to pass them, at least on little endian stack-growing-down machines (which includes x86). For __fastcall I'm not sure they are passed in registers or on the stack. Passing and/or returning small structs also has special efficient handling in the ABI, so __int64 really might be equivalent to a small record. Not that cm3 necessarily implements that "correctly" -- for interop with C; for Modula-3 calling Modula-3 we can make up our own ABI so there isn't really an "incorrect" way. Notice the mingw problem I had passing a Win32 point struct by value, I cheated and passed it by VAR to a C wrapper to workaround the gcc backend bug (which was mentioned a few times and which I looked into the code for, but took the easy route) I don't know how long long works on other platforms but probably similar. Probably a certain register pair for return values. - Jay > To: hosking at cs.purdue.edu > Date: Sat, 17 Apr 2010 19:47:03 -0700 > From: mika at async.async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] INTEGER > > Tony Hosking writes: > > > ... > > > >> We need it to match 64-bit integers on 32-bit machines? That seems = > >like > >> a very weak rationale indeed, if the same functionality could be = > >provided > >> through some other mechanism (e.g., ARRAY [0..1] OF INTEGER---even = > >with > >> a pragma e.g. <*CLONGLONG*>.. if it is necessary to tell the compiler = > >that > >> a special linkage convention is needed). > > > >There's no special linkage convention. Not sure what you mean here. > > > > I just mean if we had > > TYPE LONGINT = ARRAY [0..1] OF INTEGER > > that would perhaps not match how C handles "long long" on the same > platform (which is how, come to think of it?), and that would require > special linkage tricks. > > But what would be lost? The ability to type literals. > > You could get the same code interface on 32- and 64-bit machine by > defining > > TYPE FileOffset = ARRAY[0..1] OF [-16_80000000 .. +16_7fffffff ] > > and using that. > > > Mika -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.async.caltech.edu Sun Apr 18 09:49:27 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Sun, 18 Apr 2010 00:49:27 -0700 Subject: [M3devel] INTEGER In-Reply-To: References: , , , <7C7408D0-9A40-4988-BADA-A9FD8C15D388@cs.purdue.edu>, , , , , , , <20100418023535.3BA9E1A2103@async.async.caltech.edu>, , <20100418024703.6965B1A2103@async.async.caltech.edu> Message-ID: <20100418074927.934461A2117@async.async.caltech.edu> Jay I know most of this, and it doesn't really answer the question "what is it for?" I think we've already established that LONGINT isn't useful for counting anything that might actually reside in the computer's memory: it makes no sense as an array index, for instance. INTEGER suffices for that. I thought that the only real reason for LONGINT was to match C's declaration of various seek-related routines on 32-bit machines. That's not a very good reason. C++ succeeds because it does very well in the area(s) it is good at. People who want to program in C++ will clearly program in C++, not Modula-3. Modula-3 is never, ever going to be the language of choice for people who want lots of snazzy infix operators. Modula-3 is supposed to be a language with about as powerful semantics as C++ and an extremely simple syntax and definition---snazzy infix is one of the things you give up for that. I don't see how LONGINT fits into this picture. Now we have LONGCARD too? And it's infected the definitions of FIRST and LAST? But not NUMBER... argh! so, NUMBER(a) and LAST(a) - FIRST(a) + 1 no longer mean the same thing? Are we going to see lots of comments in generics in the future where it says T may not be an open array type nor an array type indexed on LONGINT or a subrange thereof? Your comments about different parameter-passing techniques was what I was trying to address with my suggestion to have a pragma for this---just to match C (and Fortran?), of course. Name me a single Modula-3 programmer who cares in what order the bits in his parameters are pushed on the stack in a Modula-3-to-Modula-3 call. And I am definitely in that school of thought that says that programming languages should not "evolve". Better to leave well enough alone. How much Modula-3 code has been written that uses LONGINT? Other than to talk to C? I've certainly never used it. Mika Jay K writes: >--_264cb69b-0215-44c3-807c-8b4d8ea0ea59_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >TYPE LONGINT =3D ARRAY [0..1] OF INTEGER on a 32bit system is very close to= > LONGINT. > > Plus treating it opaquely and providing a bunch of functions to operate on= > it. > > Just as well therefore could be RECORD hi=2Clo:LONGINT END (see LARGE_INTE= >GER and ULARGE_INTEGER in winnt.h) > >=20 > >Differences that come to mind: > > infix operators <=3D=3D=3D=20 > > possibly passed differently as a parameter > > or returned differently as a result > > ie. probably "directly compatible with" "long long"=2C passed by value (o= >f course you could always pass by pointer and achieve compatibilitity trivi= >ally) > >=20 > >=20 > >I have to say though=2C the biggest reason is in-fix operators. Convenient = >syntax. > >C++ is the best and some way worst of example of the general right way to d= >o this -- you let programmers define types and their infix operators. Other= > languages just come with a passle of special cases of types that have in-f= >ix operators. > >A good example is that Java infix operator + on string=2C besides the vario= >us integers=2C and nothing else. > >=20 > >=20 > >I think C# lets you define operators=2C yet people don't complain that it i= >s "a mess" as they do of C++. > >I think Python does now too. > >So it is feature growing in popularity among "mainstream" languages=2C not = >just C++. > > C++ of course is extremely mainstream=2C but also a favorite target. (ht= >tp://www.relisoft.com/tools/CppCritic.html) > >=20 > >=20 > >We also have subranges of LONGINT. > >I'm not sure what the generalization of subranges are=2C granted. > > Maybe some sort of C++ template that takes constants in the template and d= >oes range checks at runtime. Yeah=2C maybe. > >=20 > >=20 > >And as you point out=2C convenient literal syntax. > >=20 > >=20 > >People reasonably argue for library extension in place of language extensio= >n=2C but that requires a language which is flexible enough to write librari= >es with the desired interface=2C and so many languages don't let infix oper= >ators be in a user-written library. > >(There is a subtle but useless distinction here -- infix operators being in= > libraries vs. "user-written" libraries. The infix set operations for examp= >le are in a library=2C but not user-written=2C special=2C the compiler know= >s about it.) > >=20 > >> that would perhaps not match how C handles "long long" on the same >> platform (which is how=2C come to think of it?)=2C and that would require > > >=20 > >On NT/x86=2C __int64/long long is returned in the register pair edx:eax. > >edx is high=2C eax is low. > >When passed as a parameter to __stdcall or __cdecl is just passed as two 32= >bit values adjacent on the stack=2C "hi=2C lo=2C hi=2C lo=2C it's off to pu= >sh we go" is the Snow White-influenced mantra to remember how to pass them= >=2C at least on little endian stack-growing-down machines (which includes x= >86). For __fastcall I'm not sure they are passed in registers or on the sta= >ck. > >Passing and/or returning small structs also has special efficient handling = >in the ABI=2C so __int64 really might be equivalent to a small record. Not = >that cm3 necessarily implements that "correctly" -- for interop with C=3B = >for Modula-3 calling Modula-3 we can make up our own ABI so there isn't rea= >lly an "incorrect" way. Notice the mingw problem I had passing a Win32 poin= >t struct by value=2C I cheated and passed it by VAR to a C wrapper to worka= >round the gcc backend bug (which was mentioned a few times and which I look= >ed into the code for=2C but took the easy route) > >=20 > >=20 > >I don't know how long long works on other platforms but probably similar. > >Probably a certain register pair for return values. > >=20 > > - Jay > >=20 >> To: hosking at cs.purdue.edu >> Date: Sat=2C 17 Apr 2010 19:47:03 -0700 >> From: mika at async.async.caltech.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] INTEGER >>=20 >> Tony Hosking writes: >> > >> ... >> > >> >> We need it to match 64-bit integers on 32-bit machines? That seems =3D >> >like >> >> a very weak rationale indeed=2C if the same functionality could be =3D >> >provided >> >> through some other mechanism (e.g.=2C ARRAY [0..1] OF INTEGER---even = >=3D >> >with >> >> a pragma e.g. <*CLONGLONG*>.. if it is necessary to tell the compiler = >=3D >> >that >> >> a special linkage convention is needed). >> > >> >There's no special linkage convention. Not sure what you mean here. >> > >>=20 >> I just mean if we had >>=20 >> TYPE LONGINT =3D ARRAY [0..1] OF INTEGER >>=20 >> that would perhaps not match how C handles "long long" on the same >> platform (which is how=2C come to think of it?)=2C and that would require >> special linkage tricks. >>=20 >> But what would be lost? The ability to type literals.=20 >>=20 >> You could get the same code interface on 32- and 64-bit machine by >> defining >>=20 >> TYPE FileOffset =3D ARRAY[0..1] OF [-16_80000000 .. +16_7fffffff ] >>=20 >> and using that. >>=20 >>=20 >> Mika > = > >--_264cb69b-0215-44c3-807c-8b4d8ea0ea59_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > > >TYPE LONGINT =3D ARRAY [0..1] OF INTEGER on a =3B32bit system is very c= >lose to LONGINT.
> =3BPlus treating it opaquely and providing a bunch of functions to ope= >rate on it.
> =3BJust as well therefore could be RECORD hi=2Clo:LONGINT END (see LAR= >GE_INTEGER and ULARGE_INTEGER in winnt.h)
> =3B
>Differences that come to mind:
> =3B =3Binfix operators =3B <=3B=3D=3D=3D
> =3B possibly passed differently =3Bas a parameter
> =3B or returned differently as a result
> =3B ie. probably "directly compatible with" "long long"=2C passed by v= >alue (of course you could always pass by pointer and achieve compatibilitit= >y trivially)
> =3B
> =3B
>I have to say though=2C the biggest reason is in-fix operators. Convenient = >syntax.
>C++ is the best and some way worst of example of the general right way to d= >o this -- you let programmers define types and their infix operators. Other= > languages just come with a passle of special cases of types that have in-f= >ix operators.
>A good example is that Java infix operator + on string=2C besides the vario= >us integers=2C and nothing else.
> =3B
> =3B
>I think C# lets you define operators=2C yet people don't complain that it i= >s "a mess" as they do of C++.
>I think Python does now too.
>So it is feature growing in popularity among "mainstream" languages=2C not = >just C++.
> =3B =3B C++ of course is extremely mainstream=2C but also a favori= >te target. (http:/= >/www.relisoft.com/tools/CppCritic.html)
> =3B
> =3B
>We also have subranges of LONGINT.
>I'm not sure what the generalization of subranges are=2C granted.
> =3BMaybe some sort of C++ template that takes constants in the templat= >e and does range checks at runtime. Yeah=2C maybe.
> =3B
> =3B
>And as you point out=2C convenient literal syntax.
> =3B
> =3B
>People reasonably argue for library extension in place of language extensio= >n=2C but that requires a language which is flexible enough to write librari= >es with the desired interface=2C and so many languages don't let infix oper= >ators be in a user-written library.
>(There is a subtle but useless distinction here -- infix operators being in= > libraries vs. "user-written" libraries. The infix set operations for examp= >le are in a library=2C but not user-written=2C special=2C the compiler know= >s about it.)
> =3B
>>=3B that would perhaps not match how C handles "long long" on the sameR>>=3B platform (which is how=2C come to think of it?)=2C and that would = >require

> =3B
>On NT/x86=2C __int64/long long is returned in the register pair edx:eax.> >edx is high=2C eax is low.
>When passed as a parameter to __stdcall or __cdecl is just passed as two 32= >bit values adjacent on the stack=2C "hi=2C lo=2C hi=2C lo=2C it's off to pu= >sh we go" is the Snow White-influenced mantra to remember how to pass them= >=2C at least on little endian stack-growing-down machines (which includes x= >86). For __fastcall I'm not sure they are passed in registers or on the sta= >ck.
>Passing and/or returning small structs also has special efficient handling = >in the ABI=2C so __int64 really might be equivalent to a small record. Not = >that cm3 necessarily implements that "correctly" =3B -- for interop wit= >h C=3B for Modula-3 calling Modula-3 we can make up our own ABI so there is= >n't =3Breally an "incorrect" way. =3BNotice the mingw problem I had= > passing a Win32 point struct by value=2C I cheated and passed it by VAR to= > a =3BC wrapper to workaround the gcc backend bug (which was mentioned = >a few times and which I looked into the code for=2C but took the easy route= >)
> =3B
> =3B
>I don't know how long long works on other platforms but probably similar.R> >Probably a certain register pair for return values.
> =3B
> =3B- Jay

 =3B
>=3B To: hosking at cs.purdue.edu
>=3B= > Date: Sat=2C 17 Apr 2010 19:47:03 -0700
>=3B From: mika at async.async.c= >altech.edu
>=3B CC: m3devel at elegosoft.com
>=3B Subject: Re: [M3de= >vel] INTEGER
>=3B
>=3B Tony Hosking writes:
>=3B >=3B
= >>=3B ...
>=3B >=3B
>=3B >=3B>=3B We need it to match 64-b= >it integers on 32-bit machines? That seems =3D
>=3B >=3Blike
>= >=3B >=3B>=3B a very weak rationale indeed=2C if the same functionality = >could be =3D
>=3B >=3Bprovided
>=3B >=3B>=3B through some o= >ther mechanism (e.g.=2C ARRAY [0..1] OF INTEGER---even =3D
>=3B >=3B= >with
>=3B >=3B>=3B a pragma e.g. <=3B*CLONGLONG*>=3B.. if it i= >s necessary to tell the compiler =3D
>=3B >=3Bthat
>=3B >=3B&= >gt=3B a special linkage convention is needed).
>=3B >=3B
>=3B &= >gt=3BThere's no special linkage convention. Not sure what you mean here.>>=3B >=3B
>=3B
>=3B I just mean if we had
>=3B
>= >=3B TYPE LONGINT =3D ARRAY [0..1] OF INTEGER
>=3B
>=3B that woul= >d perhaps not match how C handles "long long" on the same
>=3B platfor= >m (which is how=2C come to think of it?)=2C and that would require
>= >=3B special linkage tricks.
>=3B
>=3B But what would be lost? Th= >e ability to type literals.
>=3B
>=3B You could get the same co= >de interface on 32- and 64-bit machine by
>=3B defining
>=3B
= >>=3B TYPE FileOffset =3D ARRAY[0..1] OF [-16_80000000 .. +16_7fffffff ]R>>=3B
>=3B and using that.
>=3B
>=3B
>=3B Mika> >= > >--_264cb69b-0215-44c3-807c-8b4d8ea0ea59_-- From jay.krell at cornell.edu Sun Apr 18 11:23:24 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 18 Apr 2010 09:23:24 +0000 Subject: [M3devel] INTEGER In-Reply-To: <20100418074927.934461A2117@async.async.caltech.edu> References: , , ,,<7C7408D0-9A40-4988-BADA-A9FD8C15D388@cs.purdue.edu>, ,,, , , , , , , , , <20100418023535.3BA9E1A2103@async.async.caltech.edu>, , , , <20100418024703.6965B1A2103@async.async.caltech.edu>, , <20100418074927.934461A2117@async.async.caltech.edu> Message-ID: Mika, I'm not sure what the answer is. You might recall that Tony questioned the need for LONGINT, because it is "only" there to interface with C, and I've rewritten all the C interfacing, providing perhaps other means to solve that problem...I'm not sure what means Tony had in mind, but perhaps an array or record as you/I show. Others spoke up about the need to work with files larger than 2GB. Which isn't necessarily enabled by providing LONGINT, but it is a small convenient step ("convenient" to who? Not the compiler developer. :) ) A very small amount of code has been "fixed" to pass along large file sizes with complete fidelity. The Rd/Wr interface continues to not work, or work well or easily, with streams beyond 2GB in size. I still that that should be dealt with. And I still suspect a 64bit size is near enough to infinity (for I/O purposes), that the interfaces don't need a significant redesign, merely a widening of INTEGER to LONGINT. Pass the problem up yet one more level. Granted, I vaguely recall that most/many/all rd/wr users require their data to fit into memory, so they'll fail with >2GB file sizes. Recall that merely browsing to a directory with a large file with the normal Trestle GUI would hit a subrange fault and generally terminate the running program -- no need to try to open the file. That bug at least should now be fixed by LONGINT. Granted, it probably could have been fixed e.g. by lying and giving such files a size of LAST(INTEGER). ? "Obviously" 64 is just one special spot on a range of integer sizes. Realize however that a number of 64bit integer operations really can be very efficiently implemented on most 32bit processors. Though not all operations -- add, subtract, compare are reasonable, multiply, divide less so. However arbitrary precision arithmetic, not just double precision, can be done about as efficiently -- the critical piece is "exposing the carry flag efficiently", if it exists, and we don't actually do that. Another opinion is that 64bit platforms already work..and perhaps 32bit platforms won't be around much longer anyway. This feature is 10-20 years too late and its impact therefore won't be significant. ? (http://yarchive.net/comp/longlong.html dates "long long" to circa 18 years ago.) Again, I don't have an anwer. - Jay > To: jay.krell at cornell.edu > Date: Sun, 18 Apr 2010 00:49:27 -0700 > From: mika at async.async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] INTEGER > > > Jay I know most of this, and it doesn't really answer the question > "what is it for?" > > I think we've already established that LONGINT isn't useful for counting > anything that might actually reside in the computer's memory: it makes > no sense as an array index, for instance. INTEGER suffices for that. > > I thought that the only real reason for LONGINT was to match C's > declaration of various seek-related routines on 32-bit machines. > That's not a very good reason. > > C++ succeeds because it does very well in the area(s) it is good at. > People who want to program in C++ will clearly program in C++, not > Modula-3. Modula-3 is never, ever going to be the language of choice for > people who want lots of snazzy infix operators. Modula-3 is supposed to > be a language with about as powerful semantics as C++ and an extremely > simple syntax and definition---snazzy infix is one of the things you > give up for that. I don't see how LONGINT fits into this picture. > Now we have LONGCARD too? And it's infected the definitions > of FIRST and LAST? But not NUMBER... argh! > > so, > > NUMBER(a) and LAST(a) - FIRST(a) + 1 > > no longer mean the same thing? Are we going to see lots of comments > in generics in the future where it says T may not be an open array > type nor an array type indexed on LONGINT or a subrange thereof? > > Your comments about different parameter-passing techniques was what I was > trying to address with my suggestion to have a pragma for this---just to > match C (and Fortran?), of course. Name me a single Modula-3 programmer > who cares in what order the bits in his parameters are pushed on the > stack in a Modula-3-to-Modula-3 call. > > And I am definitely in that school of thought that says that programming > languages should not "evolve". Better to leave well enough alone. > > How much Modula-3 code has been written that uses LONGINT? Other than > to talk to C? I've certainly never used it. > > Mika > > > > Jay K writes: > >--_264cb69b-0215-44c3-807c-8b4d8ea0ea59_ > >Content-Type: text/plain; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > >TYPE LONGINT =3D ARRAY [0..1] OF INTEGER on a 32bit system is very close to= > > LONGINT. > > > > Plus treating it opaquely and providing a bunch of functions to operate on= > > it. > > > > Just as well therefore could be RECORD hi=2Clo:LONGINT END (see LARGE_INTE= > >GER and ULARGE_INTEGER in winnt.h) > > > >=20 > > > >Differences that come to mind: > > > > infix operators <=3D=3D=3D=20 > > > > possibly passed differently as a parameter > > > > or returned differently as a result > > > > ie. probably "directly compatible with" "long long"=2C passed by value (o= > >f course you could always pass by pointer and achieve compatibilitity trivi= > >ally) > > > >=20 > > > >=20 > > > >I have to say though=2C the biggest reason is in-fix operators. Convenient = > >syntax. > > > >C++ is the best and some way worst of example of the general right way to d= > >o this -- you let programmers define types and their infix operators. Other= > > languages just come with a passle of special cases of types that have in-f= > >ix operators. > > > >A good example is that Java infix operator + on string=2C besides the vario= > >us integers=2C and nothing else. > > > >=20 > > > >=20 > > > >I think C# lets you define operators=2C yet people don't complain that it i= > >s "a mess" as they do of C++. > > > >I think Python does now too. > > > >So it is feature growing in popularity among "mainstream" languages=2C not = > >just C++. > > > > C++ of course is extremely mainstream=2C but also a favorite target. (ht= > >tp://www.relisoft.com/tools/CppCritic.html) > > > >=20 > > > >=20 > > > >We also have subranges of LONGINT. > > > >I'm not sure what the generalization of subranges are=2C granted. > > > > Maybe some sort of C++ template that takes constants in the template and d= > >oes range checks at runtime. Yeah=2C maybe. > > > >=20 > > > >=20 > > > >And as you point out=2C convenient literal syntax. > > > >=20 > > > >=20 > > > >People reasonably argue for library extension in place of language extensio= > >n=2C but that requires a language which is flexible enough to write librari= > >es with the desired interface=2C and so many languages don't let infix oper= > >ators be in a user-written library. > > > >(There is a subtle but useless distinction here -- infix operators being in= > > libraries vs. "user-written" libraries. The infix set operations for examp= > >le are in a library=2C but not user-written=2C special=2C the compiler know= > >s about it.) > > > >=20 > > > >> that would perhaps not match how C handles "long long" on the same > >> platform (which is how=2C come to think of it?)=2C and that would require > > > > > >=20 > > > >On NT/x86=2C __int64/long long is returned in the register pair edx:eax. > > > >edx is high=2C eax is low. > > > >When passed as a parameter to __stdcall or __cdecl is just passed as two 32= > >bit values adjacent on the stack=2C "hi=2C lo=2C hi=2C lo=2C it's off to pu= > >sh we go" is the Snow White-influenced mantra to remember how to pass them= > >=2C at least on little endian stack-growing-down machines (which includes x= > >86). For __fastcall I'm not sure they are passed in registers or on the sta= > >ck. > > > >Passing and/or returning small structs also has special efficient handling = > >in the ABI=2C so __int64 really might be equivalent to a small record. Not = > >that cm3 necessarily implements that "correctly" -- for interop with C=3B = > >for Modula-3 calling Modula-3 we can make up our own ABI so there isn't rea= > >lly an "incorrect" way. Notice the mingw problem I had passing a Win32 poin= > >t struct by value=2C I cheated and passed it by VAR to a C wrapper to worka= > >round the gcc backend bug (which was mentioned a few times and which I look= > >ed into the code for=2C but took the easy route) > > > >=20 > > > >=20 > > > >I don't know how long long works on other platforms but probably similar. > > > >Probably a certain register pair for return values. > > > >=20 > > > > - Jay > > > >=20 > >> To: hosking at cs.purdue.edu > >> Date: Sat=2C 17 Apr 2010 19:47:03 -0700 > >> From: mika at async.async.caltech.edu > >> CC: m3devel at elegosoft.com > >> Subject: Re: [M3devel] INTEGER > >>=20 > >> Tony Hosking writes: > >> > > >> ... > >> > > >> >> We need it to match 64-bit integers on 32-bit machines? That seems =3D > >> >like > >> >> a very weak rationale indeed=2C if the same functionality could be =3D > >> >provided > >> >> through some other mechanism (e.g.=2C ARRAY [0..1] OF INTEGER---even = > >=3D > >> >with > >> >> a pragma e.g. <*CLONGLONG*>.. if it is necessary to tell the compiler = > >=3D > >> >that > >> >> a special linkage convention is needed). > >> > > >> >There's no special linkage convention. Not sure what you mean here. > >> > > >>=20 > >> I just mean if we had > >>=20 > >> TYPE LONGINT =3D ARRAY [0..1] OF INTEGER > >>=20 > >> that would perhaps not match how C handles "long long" on the same > >> platform (which is how=2C come to think of it?)=2C and that would require > >> special linkage tricks. > >>=20 > >> But what would be lost? The ability to type literals.=20 > >>=20 > >> You could get the same code interface on 32- and 64-bit machine by > >> defining > >>=20 > >> TYPE FileOffset =3D ARRAY[0..1] OF [-16_80000000 .. +16_7fffffff ] > >>=20 > >> and using that. > >>=20 > >>=20 > >> Mika > > = > > > >--_264cb69b-0215-44c3-807c-8b4d8ea0ea59_ > >Content-Type: text/html; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > > > > > > > > > >TYPE LONGINT =3D ARRAY [0..1] OF INTEGER on a =3B32bit system is very c= > >lose to LONGINT.
> > =3BPlus treating it opaquely and providing a bunch of functions to ope= > >rate on it.
> > =3BJust as well therefore could be RECORD hi=2Clo:LONGINT END (see LAR= > >GE_INTEGER and ULARGE_INTEGER in winnt.h)
> > =3B
> >Differences that come to mind:
> > =3B =3Binfix operators =3B <=3B=3D=3D=3D
> > =3B possibly passed differently =3Bas a parameter
> > =3B or returned differently as a result
> > =3B ie. probably "directly compatible with" "long long"=2C passed by v= > >alue (of course you could always pass by pointer and achieve compatibilitit= > >y trivially)
> > =3B
> > =3B
> >I have to say though=2C the biggest reason is in-fix operators. Convenient = > >syntax.
> >C++ is the best and some way worst of example of the general right way to d= > >o this -- you let programmers define types and their infix operators. Other= > > languages just come with a passle of special cases of types that have in-f= > >ix operators.
> >A good example is that Java infix operator + on string=2C besides the vario= > >us integers=2C and nothing else.
> > =3B
> > =3B
> >I think C# lets you define operators=2C yet people don't complain that it i= > >s "a mess" as they do of C++.
> >I think Python does now too.
> >So it is feature growing in popularity among "mainstream" languages=2C not = > >just C++.
> > =3B =3B C++ of course is extremely mainstream=2C but also a favori= > >te target. (http:/= > >/www.relisoft.com/tools/CppCritic.html)
> > =3B
> > =3B
> >We also have subranges of LONGINT.
> >I'm not sure what the generalization of subranges are=2C granted.
> > =3BMaybe some sort of C++ template that takes constants in the templat= > >e and does range checks at runtime. Yeah=2C maybe.
> > =3B
> > =3B
> >And as you point out=2C convenient literal syntax.
> > =3B
> > =3B
> >People reasonably argue for library extension in place of language extensio= > >n=2C but that requires a language which is flexible enough to write librari= > >es with the desired interface=2C and so many languages don't let infix oper= > >ators be in a user-written library.
> >(There is a subtle but useless distinction here -- infix operators being in= > > libraries vs. "user-written" libraries. The infix set operations for examp= > >le are in a library=2C but not user-written=2C special=2C the compiler know= > >s about it.)
> > =3B
> >>=3B that would perhaps not match how C handles "long long" on the same >R>>=3B platform (which is how=2C come to think of it?)=2C and that would = > >require

> > =3B
> >On NT/x86=2C __int64/long long is returned in the register pair edx:eax. >> > >edx is high=2C eax is low.
> >When passed as a parameter to __stdcall or __cdecl is just passed as two 32= > >bit values adjacent on the stack=2C "hi=2C lo=2C hi=2C lo=2C it's off to pu= > >sh we go" is the Snow White-influenced mantra to remember how to pass them= > >=2C at least on little endian stack-growing-down machines (which includes x= > >86). For __fastcall I'm not sure they are passed in registers or on the sta= > >ck.
> >Passing and/or returning small structs also has special efficient handling = > >in the ABI=2C so __int64 really might be equivalent to a small record. Not = > >that cm3 necessarily implements that "correctly" =3B -- for interop wit= > >h C=3B for Modula-3 calling Modula-3 we can make up our own ABI so there is= > >n't =3Breally an "incorrect" way. =3BNotice the mingw problem I had= > > passing a Win32 point struct by value=2C I cheated and passed it by VAR to= > > a =3BC wrapper to workaround the gcc backend bug (which was mentioned = > >a few times and which I looked into the code for=2C but took the easy route= > >)
> > =3B
> > =3B
> >I don't know how long long works on other platforms but probably similar. >R> > >Probably a certain register pair for return values.
> > =3B
> > =3B- Jay

 =3B
>=3B To: hosking at cs.purdue.edu
>=3B= > > Date: Sat=2C 17 Apr 2010 19:47:03 -0700
>=3B From: mika at async.async.c= > >altech.edu
>=3B CC: m3devel at elegosoft.com
>=3B Subject: Re: [M3de= > >vel] INTEGER
>=3B
>=3B Tony Hosking writes:
>=3B >=3B
= > >>=3B ...
>=3B >=3B
>=3B >=3B>=3B We need it to match 64-b= > >it integers on 32-bit machines? That seems =3D
>=3B >=3Blike
>= > >=3B >=3B>=3B a very weak rationale indeed=2C if the same functionality = > >could be =3D
>=3B >=3Bprovided
>=3B >=3B>=3B through some o= > >ther mechanism (e.g.=2C ARRAY [0..1] OF INTEGER---even =3D
>=3B >=3B= > >with
>=3B >=3B>=3B a pragma e.g. <=3B*CLONGLONG*>=3B.. if it i= > >s necessary to tell the compiler =3D
>=3B >=3Bthat
>=3B >=3B&= > >gt=3B a special linkage convention is needed).
>=3B >=3B
>=3B &= > >gt=3BThere's no special linkage convention. Not sure what you mean here. >>>=3B >=3B
>=3B
>=3B I just mean if we had
>=3B
>= > >=3B TYPE LONGINT =3D ARRAY [0..1] OF INTEGER
>=3B
>=3B that woul= > >d perhaps not match how C handles "long long" on the same
>=3B platfor= > >m (which is how=2C come to think of it?)=2C and that would require
>= > >=3B special linkage tricks.
>=3B
>=3B But what would be lost? Th= > >e ability to type literals.
>=3B
>=3B You could get the same co= > >de interface on 32- and 64-bit machine by
>=3B defining
>=3B
= > >>=3B TYPE FileOffset =3D ARRAY[0..1] OF [-16_80000000 .. +16_7fffffff ] >R>>=3B
>=3B and using that.
>=3B
>=3B
>=3B Mika >> > >= > > > >--_264cb69b-0215-44c3-807c-8b4d8ea0ea59_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Apr 18 15:57:23 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 18 Apr 2010 13:57:23 +0000 Subject: [M3devel] Posix < 0 vs. # 0 vs. = -1? Message-ID: Posix often says: function foo() returns 0 for success, -1 for error m3core/libm3/etc, often say if foo() < 0 or if foo() # 0 "instead". Generally ok to tighten these up to "= -1", perhaps upon checking manpages, or a known rat's nest of inconsistencies? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Apr 18 16:10:50 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 18 Apr 2010 14:10:50 +0000 Subject: [M3devel] giant lock in SocketWin32.m3? In-Reply-To: <20100418140821.428882474008@birch.elegosoft.com> References: <20100418140821.428882474008@birch.elegosoft.com> Message-ID: Anyone know why SocketWin32.m3 has had a giant lock around everything? I see no point to it. The only global variable is related to on-demand initialization. And even that wasn't handled correctly.. - Jay > Date: Sun, 18 Apr 2010 16:08:20 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/04/18 16:08:20 > > Modified files: > cm3/m3-libs/libm3/src/os/WIN32/: SocketWin32.m3 > > Log message: > fix race condition and eliminate giant lock > I'm guessing the original authors didn't realize WSAGetLastError returns a thread local. ? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Apr 18 21:07:28 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 18 Apr 2010 15:07:28 -0400 Subject: [M3devel] INTEGER In-Reply-To: <20100418074927.934461A2117@async.async.caltech.edu> References: , , , <7C7408D0-9A40-4988-BADA-A9FD8C15D388@cs.purdue.edu>, , , , , , , <20100418023535.3BA9E1A2103@async.async.caltech.edu>, , <20100418024703.6965B1A2103@async.async.caltech.edu> <20100418074927.934461A2117@async.async.caltech.edu> Message-ID: <04EB7FF8-D304-428D-839E-233FCE009C98@cs.purdue.edu> In the language spec NUMBER(a) and LAST(a) - FIRST(a) + 1 are *not* defined to mean the same thing for all types. NUMBER does have an INTEGER value, as expected for subranges of LONGINT that are not too large. This is as it has always been for subranges of INTEGER that are not too large. Mika, I'm not sure I see any of the problems you are worrying about in the current definition of LONGINT/LONGCARD. On 18 Apr 2010, at 03:49, Mika Nystrom wrote: > > Jay I know most of this, and it doesn't really answer the question > "what is it for?" > > I think we've already established that LONGINT isn't useful for counting > anything that might actually reside in the computer's memory: it makes > no sense as an array index, for instance. INTEGER suffices for that. > > I thought that the only real reason for LONGINT was to match C's > declaration of various seek-related routines on 32-bit machines. > That's not a very good reason. > > C++ succeeds because it does very well in the area(s) it is good at. > People who want to program in C++ will clearly program in C++, not > Modula-3. Modula-3 is never, ever going to be the language of choice for > people who want lots of snazzy infix operators. Modula-3 is supposed to > be a language with about as powerful semantics as C++ and an extremely > simple syntax and definition---snazzy infix is one of the things you > give up for that. I don't see how LONGINT fits into this picture. > Now we have LONGCARD too? And it's infected the definitions > of FIRST and LAST? But not NUMBER... argh! > > so, > > NUMBER(a) and LAST(a) - FIRST(a) + 1 > > no longer mean the same thing? Are we going to see lots of comments > in generics in the future where it says T may not be an open array > type nor an array type indexed on LONGINT or a subrange thereof? > > Your comments about different parameter-passing techniques was what I was > trying to address with my suggestion to have a pragma for this---just to > match C (and Fortran?), of course. Name me a single Modula-3 programmer > who cares in what order the bits in his parameters are pushed on the > stack in a Modula-3-to-Modula-3 call. > > And I am definitely in that school of thought that says that programming > languages should not "evolve". Better to leave well enough alone. > > How much Modula-3 code has been written that uses LONGINT? Other than > to talk to C? I've certainly never used it. > > Mika > > > > Jay K writes: >> --_264cb69b-0215-44c3-807c-8b4d8ea0ea59_ >> Content-Type: text/plain; charset="iso-8859-1" >> Content-Transfer-Encoding: quoted-printable >> >> >> TYPE LONGINT =3D ARRAY [0..1] OF INTEGER on a 32bit system is very close to= >> LONGINT. >> >> Plus treating it opaquely and providing a bunch of functions to operate on= >> it. >> >> Just as well therefore could be RECORD hi=2Clo:LONGINT END (see LARGE_INTE= >> GER and ULARGE_INTEGER in winnt.h) >> >> =20 >> >> Differences that come to mind: >> >> infix operators <=3D=3D=3D=20 >> >> possibly passed differently as a parameter >> >> or returned differently as a result >> >> ie. probably "directly compatible with" "long long"=2C passed by value (o= >> f course you could always pass by pointer and achieve compatibilitity trivi= >> ally) >> >> =20 >> >> =20 >> >> I have to say though=2C the biggest reason is in-fix operators. Convenient = >> syntax. >> >> C++ is the best and some way worst of example of the general right way to d= >> o this -- you let programmers define types and their infix operators. Other= >> languages just come with a passle of special cases of types that have in-f= >> ix operators. >> >> A good example is that Java infix operator + on string=2C besides the vario= >> us integers=2C and nothing else. >> >> =20 >> >> =20 >> >> I think C# lets you define operators=2C yet people don't complain that it i= >> s "a mess" as they do of C++. >> >> I think Python does now too. >> >> So it is feature growing in popularity among "mainstream" languages=2C not = >> just C++. >> >> C++ of course is extremely mainstream=2C but also a favorite target. (ht= >> tp://www.relisoft.com/tools/CppCritic.html) >> >> =20 >> >> =20 >> >> We also have subranges of LONGINT. >> >> I'm not sure what the generalization of subranges are=2C granted. >> >> Maybe some sort of C++ template that takes constants in the template and d= >> oes range checks at runtime. Yeah=2C maybe. >> >> =20 >> >> =20 >> >> And as you point out=2C convenient literal syntax. >> >> =20 >> >> =20 >> >> People reasonably argue for library extension in place of language extensio= >> n=2C but that requires a language which is flexible enough to write librari= >> es with the desired interface=2C and so many languages don't let infix oper= >> ators be in a user-written library. >> >> (There is a subtle but useless distinction here -- infix operators being in= >> libraries vs. "user-written" libraries. The infix set operations for examp= >> le are in a library=2C but not user-written=2C special=2C the compiler know= >> s about it.) >> >> =20 >> >>> that would perhaps not match how C handles "long long" on the same >>> platform (which is how=2C come to think of it?)=2C and that would require >> >> >> =20 >> >> On NT/x86=2C __int64/long long is returned in the register pair edx:eax. >> >> edx is high=2C eax is low. >> >> When passed as a parameter to __stdcall or __cdecl is just passed as two 32= >> bit values adjacent on the stack=2C "hi=2C lo=2C hi=2C lo=2C it's off to pu= >> sh we go" is the Snow White-influenced mantra to remember how to pass them= >> =2C at least on little endian stack-growing-down machines (which includes x= >> 86). For __fastcall I'm not sure they are passed in registers or on the sta= >> ck. >> >> Passing and/or returning small structs also has special efficient handling = >> in the ABI=2C so __int64 really might be equivalent to a small record. Not = >> that cm3 necessarily implements that "correctly" -- for interop with C=3B = >> for Modula-3 calling Modula-3 we can make up our own ABI so there isn't rea= >> lly an "incorrect" way. Notice the mingw problem I had passing a Win32 poin= >> t struct by value=2C I cheated and passed it by VAR to a C wrapper to worka= >> round the gcc backend bug (which was mentioned a few times and which I look= >> ed into the code for=2C but took the easy route) >> >> =20 >> >> =20 >> >> I don't know how long long works on other platforms but probably similar. >> >> Probably a certain register pair for return values. >> >> =20 >> >> - Jay >> >> =20 >>> To: hosking at cs.purdue.edu >>> Date: Sat=2C 17 Apr 2010 19:47:03 -0700 >>> From: mika at async.async.caltech.edu >>> CC: m3devel at elegosoft.com >>> Subject: Re: [M3devel] INTEGER >>> =20 >>> Tony Hosking writes: >>>> >>> ... >>>> >>>>> We need it to match 64-bit integers on 32-bit machines? That seems =3D >>>> like >>>>> a very weak rationale indeed=2C if the same functionality could be =3D >>>> provided >>>>> through some other mechanism (e.g.=2C ARRAY [0..1] OF INTEGER---even = >> =3D >>>> with >>>>> a pragma e.g. <*CLONGLONG*>.. if it is necessary to tell the compiler = >> =3D >>>> that >>>>> a special linkage convention is needed). >>>> >>>> There's no special linkage convention. Not sure what you mean here. >>>> >>> =20 >>> I just mean if we had >>> =20 >>> TYPE LONGINT =3D ARRAY [0..1] OF INTEGER >>> =20 >>> that would perhaps not match how C handles "long long" on the same >>> platform (which is how=2C come to think of it?)=2C and that would require >>> special linkage tricks. >>> =20 >>> But what would be lost? The ability to type literals.=20 >>> =20 >>> You could get the same code interface on 32- and 64-bit machine by >>> defining >>> =20 >>> TYPE FileOffset =3D ARRAY[0..1] OF [-16_80000000 .. +16_7fffffff ] >>> =20 >>> and using that. >>> =20 >>> =20 >>> Mika >> = >> >> --_264cb69b-0215-44c3-807c-8b4d8ea0ea59_ >> Content-Type: text/html; charset="iso-8859-1" >> Content-Transfer-Encoding: quoted-printable >> >> >> >> >> >> >> TYPE LONGINT =3D ARRAY [0..1] OF INTEGER on a =3B32bit system is very c= >> lose to LONGINT.
>>  =3BPlus treating it opaquely and providing a bunch of functions to ope= >> rate on it.
>>  =3BJust as well therefore could be RECORD hi=2Clo:LONGINT END (see LAR= >> GE_INTEGER and ULARGE_INTEGER in winnt.h)
>>  =3B
>> Differences that come to mind:
>>  =3B =3Binfix operators =3B <=3B=3D=3D=3D
>>  =3B possibly passed differently =3Bas a parameter
>>  =3B or returned differently as a result
>>  =3B ie. probably "directly compatible with" "long long"=2C passed by v= >> alue (of course you could always pass by pointer and achieve compatibilitit= >> y trivially)
>>  =3B
>>  =3B
>> I have to say though=2C the biggest reason is in-fix operators. Convenient = >> syntax.
>> C++ is the best and some way worst of example of the general right way to d= >> o this -- you let programmers define types and their infix operators. Other= >> languages just come with a passle of special cases of types that have in-f= >> ix operators.
>> A good example is that Java infix operator + on string=2C besides the vario= >> us integers=2C and nothing else.
>>  =3B
>>  =3B
>> I think C# lets you define operators=2C yet people don't complain that it i= >> s "a mess" as they do of C++.
>> I think Python does now too.
>> So it is feature growing in popularity among "mainstream" languages=2C not = >> just C++.
>>  =3B =3B C++ of course is extremely mainstream=2C but also a favori= >> te target. (http:/= >> /www.relisoft.com/tools/CppCritic.html)
>>  =3B
>>  =3B
>> We also have subranges of LONGINT.
>> I'm not sure what the generalization of subranges are=2C granted.
>>  =3BMaybe some sort of C++ template that takes constants in the templat= >> e and does range checks at runtime. Yeah=2C maybe.
>>  =3B
>>  =3B
>> And as you point out=2C convenient literal syntax.
>>  =3B
>>  =3B
>> People reasonably argue for library extension in place of language extensio= >> n=2C but that requires a language which is flexible enough to write librari= >> es with the desired interface=2C and so many languages don't let infix oper= >> ators be in a user-written library.
>> (There is a subtle but useless distinction here -- infix operators being in= >> libraries vs. "user-written" libraries. The infix set operations for examp= >> le are in a library=2C but not user-written=2C special=2C the compiler know= >> s about it.)
>>  =3B
>> >=3B that would perhaps not match how C handles "long long" on the same> R>>=3B platform (which is how=2C come to think of it?)=2C and that would = >> require

>>  =3B
>> On NT/x86=2C __int64/long long is returned in the register pair edx:eax.>> >> edx is high=2C eax is low.
>> When passed as a parameter to __stdcall or __cdecl is just passed as two 32= >> bit values adjacent on the stack=2C "hi=2C lo=2C hi=2C lo=2C it's off to pu= >> sh we go" is the Snow White-influenced mantra to remember how to pass them= >> =2C at least on little endian stack-growing-down machines (which includes x= >> 86). For __fastcall I'm not sure they are passed in registers or on the sta= >> ck.
>> Passing and/or returning small structs also has special efficient handling = >> in the ABI=2C so __int64 really might be equivalent to a small record. Not = >> that cm3 necessarily implements that "correctly" =3B -- for interop wit= >> h C=3B for Modula-3 calling Modula-3 we can make up our own ABI so there is= >> n't =3Breally an "incorrect" way. =3BNotice the mingw problem I had= >> passing a Win32 point struct by value=2C I cheated and passed it by VAR to= >> a =3BC wrapper to workaround the gcc backend bug (which was mentioned = >> a few times and which I looked into the code for=2C but took the easy route= >> )
>>  =3B
>>  =3B
>> I don't know how long long works on other platforms but probably similar.> R> >> Probably a certain register pair for return values.
>>  =3B
>>  =3B- Jay

 =3B
>=3B To: hosking at cs.purdue.edu
>=3B= >> Date: Sat=2C 17 Apr 2010 19:47:03 -0700
>=3B From: mika at async.async.c= >> altech.edu
>=3B CC: m3devel at elegosoft.com
>=3B Subject: Re: [M3de= >> vel] INTEGER
>=3B
>=3B Tony Hosking writes:
>=3B >=3B
= >> >=3B ...
>=3B >=3B
>=3B >=3B>=3B We need it to match 64-b= >> it integers on 32-bit machines? That seems =3D
>=3B >=3Blike
>= >> =3B >=3B>=3B a very weak rationale indeed=2C if the same functionality = >> could be =3D
>=3B >=3Bprovided
>=3B >=3B>=3B through some o= >> ther mechanism (e.g.=2C ARRAY [0..1] OF INTEGER---even =3D
>=3B >=3B= >> with
>=3B >=3B>=3B a pragma e.g. <=3B*CLONGLONG*>=3B.. if it i= >> s necessary to tell the compiler =3D
>=3B >=3Bthat
>=3B >=3B&= >> gt=3B a special linkage convention is needed).
>=3B >=3B
>=3B &= >> gt=3BThere's no special linkage convention. Not sure what you mean here.>> >=3B >=3B
>=3B
>=3B I just mean if we had
>=3B
>= >> =3B TYPE LONGINT =3D ARRAY [0..1] OF INTEGER
>=3B
>=3B that woul= >> d perhaps not match how C handles "long long" on the same
>=3B platfor= >> m (which is how=2C come to think of it?)=2C and that would require
>= >> =3B special linkage tricks.
>=3B
>=3B But what would be lost? Th= >> e ability to type literals.
>=3B
>=3B You could get the same co= >> de interface on 32- and 64-bit machine by
>=3B defining
>=3B
= >> >=3B TYPE FileOffset =3D ARRAY[0..1] OF [-16_80000000 .. +16_7fffffff ]> R>>=3B
>=3B and using that.
>=3B
>=3B
>=3B Mika>> >> = >> >> --_264cb69b-0215-44c3-807c-8b4d8ea0ea59_-- From hosking at cs.purdue.edu Sun Apr 18 21:09:00 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 18 Apr 2010 15:09:00 -0400 Subject: [M3devel] Posix < 0 vs. # 0 vs. = -1? In-Reply-To: References: Message-ID: Checking < 0 is much cheaper than checking = -1. C idioms typically check < 0. -1 is simply a convenient negative value to return. Leave it as is. On 18 Apr 2010, at 09:57, Jay K wrote: > Posix often says: > function foo() returns 0 for success, -1 for error > > m3core/libm3/etc, often say if foo() < 0 or if foo() # 0 "instead". > Generally ok to tighten these up to "= -1", perhaps upon checking manpages, > or a known rat's nest of inconsistencies? > > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.async.caltech.edu Sun Apr 18 21:41:59 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Sun, 18 Apr 2010 12:41:59 -0700 Subject: [M3devel] Posix < 0 vs. # 0 vs. = -1? In-Reply-To: References: Message-ID: <20100418194159.E07411A2119@async.async.caltech.edu> Jay K writes: >--_201b8a99-e8e8-4887-bb32-c65e8edd0b1a_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >Posix often says: > > function foo() returns 0 for success=2C -1 for error > >=20 > > m3core/libm3/etc=2C often say if foo() < 0 or if foo() # 0 "instead". > Generally ok to tighten these up to "=3D -1"=2C perhaps upon checking manp= >ages=2C > or a known rat's nest of inconsistencies? > Maybe this is just my personal style, but I would code it thus: <*EXTERNAL*> PROCEDURE F() : INTEGER; (* matches C declaration *) ... VAR result : [0..1] := F(); (* matches man page specification *) BEGIN CASE result OF 0 => ... | -1 => ... END END No way for any sneaky value problems to get through. The use of CASE also guards against typos. Mika From mika at async.async.caltech.edu Sun Apr 18 21:59:01 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Sun, 18 Apr 2010 12:59:01 -0700 Subject: [M3devel] INTEGER In-Reply-To: <04EB7FF8-D304-428D-839E-233FCE009C98@cs.purdue.edu> References: , , , <7C7408D0-9A40-4988-BADA-A9FD8C15D388@cs.purdue.edu>, , , , , , , <20100418023535.3BA9E1A2103@async.async.caltech.edu>, , <20100418024703.6965B1A2103@async.async.caltech.edu> <20100418074927.934461A2117@async.async.caltech.edu> <04EB7FF8-D304-428D-839E-233FCE009C98@cs.purdue.edu> Message-ID: <20100418195901.CDACB1A20F6@async.async.caltech.edu> My problem is really just that it's ugly. LONGx is showing up as an issue in all sorts of low-level code, which is not surprising since Modula-3 with LONGx is not the same language as Modula-3 (maybe we should call it Modula-3+?) The compiler bootstrapping process has gotten more complicated due to it, and when I cvs updated m3tk yesterday stubgen wouldn't compile because there was something "long" in it that wasn't there before. I have no idea what library or components I needed to update and recompile and didn't have the time to deal with the issue at the time. And the new m3tk, stubgen, and compiler(?) won't compile using PM3 or SRC M3 since we're no longer using the language of the Green Book. (Same comment goes for WIDECHAR, by the way.) One of the wonderful things about Modula-3 *used to be* that I could grab some old package from DECSRC and just use it without changes since no one had messed with the language definition. This is still true as far as programs that just use the tools go, but it's no longer true for programs that process Modula-3 code as input data. Of which there are more than a few: many aspects of Modula-3 were specifically designed to make the language easy to process by program, as an intermediate format and whatnot. To quote E.W.D.: 'Unfathomed misunderstanding is further revealed by the term "software maintenance", as a result of which many people continue to believe that programs and even programming languages themselves are subject to wear and tear. Your car needs maintenance too, doesn't it? Famous is the story of the oil company that believed that its PASCAL programs did not last as long as its FORTRAN programs "because PASCAL was not maintained".' LONGx is causing me to have to do "software maintenance" on Modula-3 programs... for a feature that no one appears to be using and is quickly becoming irrelevant. Mika Tony Hosking writes: >In the language spec NUMBER(a) and LAST(a) - FIRST(a) + 1 are *not* = >defined to mean the same thing for all types. >NUMBER does have an INTEGER value, as expected for subranges of LONGINT = >that are not too large. >This is as it has always been for subranges of INTEGER that are not too = >large. > >Mika, I'm not sure I see any of the problems you are worrying about in = >the current definition of LONGINT/LONGCARD. > >On 18 Apr 2010, at 03:49, Mika Nystrom wrote: > >>=20 >> Jay I know most of this, and it doesn't really answer the question >> "what is it for?" >>=20 >> I think we've already established that LONGINT isn't useful for = >counting >> anything that might actually reside in the computer's memory: it makes >> no sense as an array index, for instance. INTEGER suffices for that. >>=20 >> I thought that the only real reason for LONGINT was to match C's >> declaration of various seek-related routines on 32-bit machines. >> That's not a very good reason. >>=20 >> C++ succeeds because it does very well in the area(s) it is good at. >> People who want to program in C++ will clearly program in C++, not >> Modula-3. Modula-3 is never, ever going to be the language of choice = >for >> people who want lots of snazzy infix operators. Modula-3 is supposed = >to >> be a language with about as powerful semantics as C++ and an extremely >> simple syntax and definition---snazzy infix is one of the things you >> give up for that. I don't see how LONGINT fits into this picture. >> Now we have LONGCARD too? And it's infected the definitions >> of FIRST and LAST? But not NUMBER... argh! >>=20 >> so, >>=20 >> NUMBER(a) and LAST(a) - FIRST(a) + 1 >>=20 >> no longer mean the same thing? Are we going to see lots of comments >> in generics in the future where it says T may not be an open array >> type nor an array type indexed on LONGINT or a subrange thereof? >>=20 >> Your comments about different parameter-passing techniques was what I = >was >> trying to address with my suggestion to have a pragma for this---just = >to >> match C (and Fortran?), of course. Name me a single Modula-3 = >programmer >> who cares in what order the bits in his parameters are pushed on the >> stack in a Modula-3-to-Modula-3 call. >>=20 >> And I am definitely in that school of thought that says that = >programming >> languages should not "evolve". Better to leave well enough alone. >>=20 >> How much Modula-3 code has been written that uses LONGINT? Other than >> to talk to C? I've certainly never used it. >>=20 >> Mika >>=20 >>=20 >>=20 >> Jay K writes: >>> --_264cb69b-0215-44c3-807c-8b4d8ea0ea59_ >>> Content-Type: text/plain; charset=3D"iso-8859-1" >>> Content-Transfer-Encoding: quoted-printable >>>=20 >>>=20 >>> TYPE LONGINT =3D3D ARRAY [0..1] OF INTEGER on a 32bit system is very = >close to=3D >>> LONGINT. >>>=20 >>> Plus treating it opaquely and providing a bunch of functions to = >operate on=3D >>> it. >>>=20 >>> Just as well therefore could be RECORD hi=3D2Clo:LONGINT END (see = >LARGE_INTE=3D >>> GER and ULARGE_INTEGER in winnt.h) >>>=20 >>> =3D20 >>>=20 >>> Differences that come to mind: >>>=20 >>> infix operators <=3D3D=3D3D=3D3D=3D20 >>>=20 >>> possibly passed differently as a parameter >>>=20 >>> or returned differently as a result >>>=20 >>> ie. probably "directly compatible with" "long long"=3D2C passed by = >value (o=3D >>> f course you could always pass by pointer and achieve compatibilitity = >trivi=3D >>> ally) >>>=20 >>> =3D20 >>>=20 >>> =3D20 >>>=20 >>> I have to say though=3D2C the biggest reason is in-fix operators. = >Convenient =3D >>> syntax. >>>=20 >>> C++ is the best and some way worst of example of the general right = >way to d=3D >>> o this -- you let programmers define types and their infix operators. = >Other=3D >>> languages just come with a passle of special cases of types that have = >in-f=3D >>> ix operators. >>>=20 >>> A good example is that Java infix operator + on string=3D2C besides = >the vario=3D >>> us integers=3D2C and nothing else. >>>=20 >>> =3D20 >>>=20 >>> =3D20 >>>=20 >>> I think C# lets you define operators=3D2C yet people don't complain = >that it i=3D >>> s "a mess" as they do of C++. >>>=20 >>> I think Python does now too. >>>=20 >>> So it is feature growing in popularity among "mainstream" = >languages=3D2C not =3D >>> just C++. >>>=20 >>> C++ of course is extremely mainstream=3D2C but also a favorite = >target. (ht=3D >>> tp://www.relisoft.com/tools/CppCritic.html) >>>=20 >>> =3D20 >>>=20 >>> =3D20 >>>=20 >>> We also have subranges of LONGINT. >>>=20 >>> I'm not sure what the generalization of subranges are=3D2C granted. >>>=20 >>> Maybe some sort of C++ template that takes constants in the template = >and d=3D >>> oes range checks at runtime. Yeah=3D2C maybe. >>>=20 >>> =3D20 >>>=20 >>> =3D20 >>>=20 >>> And as you point out=3D2C convenient literal syntax. >>>=20 >>> =3D20 >>>=20 >>> =3D20 >>>=20 >>> People reasonably argue for library extension in place of language = >extensio=3D >>> n=3D2C but that requires a language which is flexible enough to write = >librari=3D >>> es with the desired interface=3D2C and so many languages don't let = >infix oper=3D >>> ators be in a user-written library. >>>=20 >>> (There is a subtle but useless distinction here -- infix operators = >being in=3D >>> libraries vs. "user-written" libraries. The infix set operations for = >examp=3D >>> le are in a library=3D2C but not user-written=3D2C special=3D2C the = >compiler know=3D >>> s about it.) >>>=20 >>> =3D20 >>>=20 >>>> that would perhaps not match how C handles "long long" on the same >>>> platform (which is how=3D2C come to think of it?)=3D2C and that = >would require >>>=20 >>>=20 >>> =3D20 >>>=20 >>> On NT/x86=3D2C __int64/long long is returned in the register pair = >edx:eax. >>>=20 >>> edx is high=3D2C eax is low. >>>=20 >>> When passed as a parameter to __stdcall or __cdecl is just passed as = >two 32=3D >>> bit values adjacent on the stack=3D2C "hi=3D2C lo=3D2C hi=3D2C lo=3D2C = >it's off to pu=3D >> sh we go" is the Snow White-influenced mantra to remember how to pass = >them=3D >>> =3D2C at least on little endian stack-growing-down machines (which = >includes x=3D >>> 86). For __fastcall I'm not sure they are passed in registers or on = >the sta=3D >>> ck. >>>=20 >>> Passing and/or returning small structs also has special efficient = >handling =3D >>> in the ABI=3D2C so __int64 really might be equivalent to a small = >record. Not =3D >>> that cm3 necessarily implements that "correctly" -- for interop with = >C=3D3B =3D >>> for Modula-3 calling Modula-3 we can make up our own ABI so there = >isn't rea=3D >>> lly an "incorrect" way. Notice the mingw problem I had passing a = >Win32 poin=3D >>> t struct by value=3D2C I cheated and passed it by VAR to a C wrapper = >to worka=3D >>> round the gcc backend bug (which was mentioned a few times and which = >I look=3D >>> ed into the code for=3D2C but took the easy route) >>>=20 >>> =3D20 >>>=20 >>> =3D20 >>>=20 >>> I don't know how long long works on other platforms but probably = >similar. >>>=20 >>> Probably a certain register pair for return values. >>>=20 >>> =3D20 >>>=20 >>> - Jay >>>=20 >>> =3D20 >>>> To: hosking at cs.purdue.edu >>>> Date: Sat=3D2C 17 Apr 2010 19:47:03 -0700 >>>> From: mika at async.async.caltech.edu >>>> CC: m3devel at elegosoft.com >>>> Subject: Re: [M3devel] INTEGER >>>> =3D20 >>>> Tony Hosking writes: >>>>>=20 >>>> ... >>>>>=20 >>>>>> We need it to match 64-bit integers on 32-bit machines? That seems = >=3D3D >>>>> like >>>>>> a very weak rationale indeed=3D2C if the same functionality could = >be =3D3D >>>>> provided >>>>>> through some other mechanism (e.g.=3D2C ARRAY [0..1] OF = >INTEGER---even =3D >>> =3D3D >>>>> with >>>>>> a pragma e.g. <*CLONGLONG*>.. if it is necessary to tell the = >compiler =3D >>> =3D3D >>>>> that >>>>>> a special linkage convention is needed). >>>>>=20 >>>>> There's no special linkage convention. Not sure what you mean here. >>>>>=20 >>>> =3D20 >>>> I just mean if we had >>>> =3D20 >>>> TYPE LONGINT =3D3D ARRAY [0..1] OF INTEGER >>>> =3D20 >>>> that would perhaps not match how C handles "long long" on the same >>>> platform (which is how=3D2C come to think of it?)=3D2C and that = >would require >>>> special linkage tricks. >>>> =3D20 >>>> But what would be lost? The ability to type literals.=3D20 >>>> =3D20 >>>> You could get the same code interface on 32- and 64-bit machine by >>>> defining >>>> =3D20 >>>> TYPE FileOffset =3D3D ARRAY[0..1] OF [-16_80000000 .. +16_7fffffff ] >>>> =3D20 >>>> and using that. >>>> =3D20 >>>> =3D20 >>>> Mika >>> =3D >>>=20 >>> --_264cb69b-0215-44c3-807c-8b4d8ea0ea59_ >>> Content-Type: text/html; charset=3D"iso-8859-1" >>> Content-Transfer-Encoding: quoted-printable >>>=20 >>> >>> >>> >>> >>> >>> TYPE LONGINT =3D3D ARRAY [0..1] OF INTEGER on a =3D3B32bit system = >is very c=3D >>> lose to LONGINT.
>>>  =3D3BPlus treating it opaquely and providing a bunch of = >functions to ope=3D >>> rate on it.
>>>  =3D3BJust as well therefore could be RECORD hi=3D2Clo:LONGINT = >END (see LAR=3D >>> GE_INTEGER and ULARGE_INTEGER in winnt.h)
>>>  =3D3B
>>> Differences that come to mind:
>>>  =3D3B =3D3Binfix operators =3D3B <=3D3B=3D3D=3D3D=3D3D = >
>>>  =3D3B possibly passed differently =3D3Bas a parameter
>>>  =3D3B or returned differently as a result
>>>  =3D3B ie. probably "directly compatible with" "long long"=3D2C = >passed by v=3D >>> alue (of course you could always pass by pointer and achieve = >compatibilitit=3D >>> y trivially)
>>>  =3D3B
>>>  =3D3B
>>> I have to say though=3D2C the biggest reason is in-fix operators. = >Convenient =3D >>> syntax.
>>> C++ is the best and some way worst of example of the general right = >way to d=3D >>> o this -- you let programmers define types and their infix operators. = >Other=3D >>> languages just come with a passle of special cases of types that have = >in-f=3D >>> ix operators.
>>> A good example is that Java infix operator + on string=3D2C besides = >the vario=3D >>> us integers=3D2C and nothing else.
>>>  =3D3B
>>>  =3D3B
>>> I think C# lets you define operators=3D2C yet people don't complain = >that it i=3D >>> s "a mess" as they do of C++.
>>> I think Python does now too.
>>> So it is feature growing in popularity among "mainstream" = >languages=3D2C not =3D >>> just C++.
>>>  =3D3B =3D3B C++ of course is extremely mainstream=3D2C but = >also a favori=3D >>> te target. (href=3D3D"http://www.relisoft.com/tools/CppCritic.html">http:/=3D >>> /www.relisoft.com/tools/CppCritic.html)
>>>  =3D3B
>>>  =3D3B
>>> We also have subranges of LONGINT.
>>> I'm not sure what the generalization of subranges are=3D2C = >granted.
>>>  =3D3BMaybe some sort of C++ template that takes constants in the = >templat=3D >>> e and does range checks at runtime. Yeah=3D2C maybe.
>>>  =3D3B
>>>  =3D3B
>>> And as you point out=3D2C convenient literal syntax.
>>>  =3D3B
>>>  =3D3B
>>> People reasonably argue for library extension in place of language = >extensio=3D >>> n=3D2C but that requires a language which is flexible enough to write = >librari=3D >>> es with the desired interface=3D2C and so many languages don't let = >infix oper=3D >>> ators be in a user-written library.
>>> (There is a subtle but useless distinction here -- infix operators = >being in=3D >>> libraries vs. "user-written" libraries. The infix set operations for = >examp=3D >>> le are in a library=3D2C but not user-written=3D2C special=3D2C the = >compiler know=3D >>> s about it.)
>>>  =3D3B
>>> >=3D3B that would perhaps not match how C handles "long long" on = >the same>> R>>=3D3B platform (which is how=3D2C come to think of it?)=3D2C and = >that would =3D >>> require

>>>  =3D3B
>>> On NT/x86=3D2C __int64/long long is returned in the register pair = >edx:eax.>>>=20 >>> edx is high=3D2C eax is low.
>>> When passed as a parameter to __stdcall or __cdecl is just passed as = >two 32=3D >>> bit values adjacent on the stack=3D2C "hi=3D2C lo=3D2C hi=3D2C lo=3D2C = >it's off to pu=3D >>> sh we go" is the Snow White-influenced mantra to remember how to pass = >them=3D >>> =3D2C at least on little endian stack-growing-down machines (which = >includes x=3D >>> 86). For __fastcall I'm not sure they are passed in registers or on = >the sta=3D >>> ck.
>>> Passing and/or returning small structs also has special efficient = >handling =3D >>> in the ABI=3D2C so __int64 really might be equivalent to a small = >record. Not =3D >>> that cm3 necessarily implements that "correctly" =3D3B -- for = >interop wit=3D >>> h C=3D3B for Modula-3 calling Modula-3 we can make up our own ABI so = >there is=3D >>> n't =3D3Breally an "incorrect" way. =3D3BNotice the mingw = >problem I had=3D >>> passing a Win32 point struct by value=3D2C I cheated and passed it by = >VAR to=3D >>> a =3D3BC wrapper to workaround the gcc backend bug (which was = >mentioned =3D >>> a few times and which I looked into the code for=3D2C but took the = >easy route=3D >>> )
>>>  =3D3B
>>>  =3D3B
>>> I don't know how long long works on other platforms but probably = >similar.>> R> >>> Probably a certain register pair for return values.
>>>  =3D3B
>>>  =3D3B- Jay

 =3D3B
>=3D3B To: = >hosking at cs.purdue.edu
>=3D3B=3D >>> Date: Sat=3D2C 17 Apr 2010 19:47:03 -0700
>=3D3B From: = >mika at async.async.c=3D >>> altech.edu
>=3D3B CC: m3devel at elegosoft.com
>=3D3B Subject: = >Re: [M3de=3D >>> vel] INTEGER
>=3D3B
>=3D3B Tony Hosking writes:
>=3D3B = >>=3D3B
=3D >>> >=3D3B ...
>=3D3B >=3D3B
>=3D3B >=3D3B>=3D3B We = >need it to match 64-b=3D >>> it integers on 32-bit machines? That seems =3D3D
>=3D3B = >>=3D3Blike
>=3D >>> =3D3B >=3D3B>=3D3B a very weak rationale indeed=3D2C if the same = >functionality =3D >>> could be =3D3D
>=3D3B >=3D3Bprovided
>=3D3B >=3D3B>=3D3= >B through some o=3D >>> ther mechanism (e.g.=3D2C ARRAY [0..1] OF INTEGER---even = >=3D3D
>=3D3B >=3D3B=3D >>> with
>=3D3B >=3D3B>=3D3B a pragma e.g. = ><=3D3B*CLONGLONG*>=3D3B.. if it i=3D >>> s necessary to tell the compiler =3D3D
>=3D3B = >>=3D3Bthat
>=3D3B >=3D3B&=3D >>> gt=3D3B a special linkage convention is needed).
>=3D3B = >>=3D3B
>=3D3B &=3D >>> gt=3D3BThere's no special linkage convention. Not sure what you mean = >here.>>> >=3D3B >=3D3B
>=3D3B
>=3D3B I just mean if we = >had
>=3D3B
>=3D >>> =3D3B TYPE LONGINT =3D3D ARRAY [0..1] OF INTEGER
>=3D3B = >
>=3D3B that woul=3D >>> d perhaps not match how C handles "long long" on the same
>=3D3B = >platfor=3D >>> m (which is how=3D2C come to think of it?)=3D2C and that would = >require
>=3D >>> =3D3B special linkage tricks.
>=3D3B
>=3D3B But what would = >be lost? Th=3D >>> e ability to type literals.
>=3D3B
>=3D3B You could get = >the same co=3D >>> de interface on 32- and 64-bit machine by
>=3D3B = >defining
>=3D3B
=3D >>> >=3D3B TYPE FileOffset =3D3D ARRAY[0..1] OF [-16_80000000 .. = >+16_7fffffff ]>> R>>=3D3B
>=3D3B and using that.
>=3D3B
>=3D3B = >
>=3D3B Mika>>> >>> =3D >>>=20 >>> --_264cb69b-0215-44c3-807c-8b4d8ea0ea59_-- From hosking at cs.purdue.edu Mon Apr 19 02:38:43 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 18 Apr 2010 20:38:43 -0400 Subject: [M3devel] INTEGER In-Reply-To: <20100418195901.CDACB1A20F6@async.async.caltech.edu> References: , , , <7C7408D0-9A40-4988-BADA-A9FD8C15D388@cs.purdue.edu>, , , , , , , <20100418023535.3BA9E1A2103@async.async.caltech.edu>, , <20100418024703.6965B1A2103@async.async.caltech.edu> <20100418074927.934461A2117@async.async.caltech.edu> <04EB7FF8-D304-428D-839E-233FCE009C98@cs.purdue.edu> <20100418195901.CDACB1A20F6@async.async.caltech.edu> Message-ID: Mika, First off, I'd be very interested to know what the issues are with LONGINT and stubgen. We are building that every day in regression testing. It would be really good to get some precise feedback. True, LONGINT is integrated with all of the language tools (same as WIDECHAR). I suppose that is the price we pay for the language having evolved. Nevertheless, CM3 should be totally backward compatible with the green book. There is no reason it should not build packages from PM3 or SRC. Now, this is not to say that perhaps we haven't overreached with LONGINT given that 64-bit is more prevalent. But then it is also useful to be able to interoperate with C libraries. The previous interfacing was pretty much a kludge, using ARRAY[0..1] OF INTEGER for "long long" but then not propagating the double INTEGER value properly throughout the Modula-3 libraries. I'm sorry to say that EWD was not particularly renowned for his practicality; pedant more like. Nice to be high and mighty but we also need to interact with the real world. We should be able to make this work. Is there a better alternative? Revoke LONGINT, and WIDECHAR? On 18 Apr 2010, at 15:59, Mika Nystrom wrote: > > My problem is really just that it's ugly. LONGx is showing up as an issue > in all sorts of low-level code, which is not surprising since Modula-3 > with LONGx is not the same language as Modula-3 (maybe we should call > it Modula-3+?) > > The compiler bootstrapping process has gotten more complicated due to it, > and when I cvs updated m3tk yesterday stubgen wouldn't compile because there > was something "long" in it that wasn't there before. I have no idea what > library or components I needed to update and recompile and didn't have the > time to deal with the issue at the time. > > And the new m3tk, stubgen, and compiler(?) won't compile using PM3 or > SRC M3 since we're no longer using the language of the Green Book. > (Same comment goes for WIDECHAR, by the way.) > > One of the wonderful things about Modula-3 *used to be* that I could > grab some old package from DECSRC and just use it without changes since > no one had messed with the language definition. This is still true as > far as programs that just use the tools go, but it's no longer true for > programs that process Modula-3 code as input data. Of which there are > more than a few: many aspects of Modula-3 were specifically designed to > make the language easy to process by program, as an intermediate format > and whatnot. > > To quote E.W.D.: > > 'Unfathomed misunderstanding is further revealed by the term "software > maintenance", as a result of which many people continue to believe that > programs and even programming languages themselves are subject to wear > and tear. Your car needs maintenance too, doesn't it? Famous is the story > of the oil company that believed that its PASCAL programs did not last > as long as its FORTRAN programs "because PASCAL was not maintained".' > > LONGx is causing me to have to do "software maintenance" on Modula-3 > programs... for a feature that no one appears to be using and is quickly > becoming irrelevant. > > Mika > > > Tony Hosking writes: >> In the language spec NUMBER(a) and LAST(a) - FIRST(a) + 1 are *not* = >> defined to mean the same thing for all types. >> NUMBER does have an INTEGER value, as expected for subranges of LONGINT = >> that are not too large. >> This is as it has always been for subranges of INTEGER that are not too = >> large. >> >> Mika, I'm not sure I see any of the problems you are worrying about in = >> the current definition of LONGINT/LONGCARD. >> >> On 18 Apr 2010, at 03:49, Mika Nystrom wrote: >> >>> =20 >>> Jay I know most of this, and it doesn't really answer the question >>> "what is it for?" >>> =20 >>> I think we've already established that LONGINT isn't useful for = >> counting >>> anything that might actually reside in the computer's memory: it makes >>> no sense as an array index, for instance. INTEGER suffices for that. >>> =20 >>> I thought that the only real reason for LONGINT was to match C's >>> declaration of various seek-related routines on 32-bit machines. >>> That's not a very good reason. >>> =20 >>> C++ succeeds because it does very well in the area(s) it is good at. >>> People who want to program in C++ will clearly program in C++, not >>> Modula-3. Modula-3 is never, ever going to be the language of choice = >> for >>> people who want lots of snazzy infix operators. Modula-3 is supposed = >> to >>> be a language with about as powerful semantics as C++ and an extremely >>> simple syntax and definition---snazzy infix is one of the things you >>> give up for that. I don't see how LONGINT fits into this picture. >>> Now we have LONGCARD too? And it's infected the definitions >>> of FIRST and LAST? But not NUMBER... argh! >>> =20 >>> so, >>> =20 >>> NUMBER(a) and LAST(a) - FIRST(a) + 1 >>> =20 >>> no longer mean the same thing? Are we going to see lots of comments >>> in generics in the future where it says T may not be an open array >>> type nor an array type indexed on LONGINT or a subrange thereof? >>> =20 >>> Your comments about different parameter-passing techniques was what I = >> was >>> trying to address with my suggestion to have a pragma for this---just = >> to >>> match C (and Fortran?), of course. Name me a single Modula-3 = >> programmer >>> who cares in what order the bits in his parameters are pushed on the >>> stack in a Modula-3-to-Modula-3 call. >>> =20 >>> And I am definitely in that school of thought that says that = >> programming >>> languages should not "evolve". Better to leave well enough alone. >>> =20 >>> How much Modula-3 code has been written that uses LONGINT? Other than >>> to talk to C? I've certainly never used it. >>> =20 >>> Mika >>> =20 >>> =20 >>> =20 >>> Jay K writes: >>>> --_264cb69b-0215-44c3-807c-8b4d8ea0ea59_ >>>> Content-Type: text/plain; charset=3D"iso-8859-1" >>>> Content-Transfer-Encoding: quoted-printable >>>> =20 >>>> =20 >>>> TYPE LONGINT =3D3D ARRAY [0..1] OF INTEGER on a 32bit system is very = >> close to=3D >>>> LONGINT. >>>> =20 >>>> Plus treating it opaquely and providing a bunch of functions to = >> operate on=3D >>>> it. >>>> =20 >>>> Just as well therefore could be RECORD hi=3D2Clo:LONGINT END (see = >> LARGE_INTE=3D >>>> GER and ULARGE_INTEGER in winnt.h) >>>> =20 >>>> =3D20 >>>> =20 >>>> Differences that come to mind: >>>> =20 >>>> infix operators <=3D3D=3D3D=3D3D=3D20 >>>> =20 >>>> possibly passed differently as a parameter >>>> =20 >>>> or returned differently as a result >>>> =20 >>>> ie. probably "directly compatible with" "long long"=3D2C passed by = >> value (o=3D >>>> f course you could always pass by pointer and achieve compatibilitity = >> trivi=3D >>>> ally) >>>> =20 >>>> =3D20 >>>> =20 >>>> =3D20 >>>> =20 >>>> I have to say though=3D2C the biggest reason is in-fix operators. = >> Convenient =3D >>>> syntax. >>>> =20 >>>> C++ is the best and some way worst of example of the general right = >> way to d=3D >>>> o this -- you let programmers define types and their infix operators. = >> Other=3D >>>> languages just come with a passle of special cases of types that have = >> in-f=3D >>>> ix operators. >>>> =20 >>>> A good example is that Java infix operator + on string=3D2C besides = >> the vario=3D >>>> us integers=3D2C and nothing else. >>>> =20 >>>> =3D20 >>>> =20 >>>> =3D20 >>>> =20 >>>> I think C# lets you define operators=3D2C yet people don't complain = >> that it i=3D >>>> s "a mess" as they do of C++. >>>> =20 >>>> I think Python does now too. >>>> =20 >>>> So it is feature growing in popularity among "mainstream" = >> languages=3D2C not =3D >>>> just C++. >>>> =20 >>>> C++ of course is extremely mainstream=3D2C but also a favorite = >> target. (ht=3D >>>> tp://www.relisoft.com/tools/CppCritic.html) >>>> =20 >>>> =3D20 >>>> =20 >>>> =3D20 >>>> =20 >>>> We also have subranges of LONGINT. >>>> =20 >>>> I'm not sure what the generalization of subranges are=3D2C granted. >>>> =20 >>>> Maybe some sort of C++ template that takes constants in the template = >> and d=3D >>>> oes range checks at runtime. Yeah=3D2C maybe. >>>> =20 >>>> =3D20 >>>> =20 >>>> =3D20 >>>> =20 >>>> And as you point out=3D2C convenient literal syntax. >>>> =20 >>>> =3D20 >>>> =20 >>>> =3D20 >>>> =20 >>>> People reasonably argue for library extension in place of language = >> extensio=3D >>>> n=3D2C but that requires a language which is flexible enough to write = >> librari=3D >>>> es with the desired interface=3D2C and so many languages don't let = >> infix oper=3D >>>> ators be in a user-written library. >>>> =20 >>>> (There is a subtle but useless distinction here -- infix operators = >> being in=3D >>>> libraries vs. "user-written" libraries. The infix set operations for = >> examp=3D >>>> le are in a library=3D2C but not user-written=3D2C special=3D2C the = >> compiler know=3D >>>> s about it.) >>>> =20 >>>> =3D20 >>>> =20 >>>>> that would perhaps not match how C handles "long long" on the same >>>>> platform (which is how=3D2C come to think of it?)=3D2C and that = >> would require >>>> =20 >>>> =20 >>>> =3D20 >>>> =20 >>>> On NT/x86=3D2C __int64/long long is returned in the register pair = >> edx:eax. >>>> =20 >>>> edx is high=3D2C eax is low. >>>> =20 >>>> When passed as a parameter to __stdcall or __cdecl is just passed as = >> two 32=3D >>>> bit values adjacent on the stack=3D2C "hi=3D2C lo=3D2C hi=3D2C lo=3D2C = >> it's off to pu=3D >>> sh we go" is the Snow White-influenced mantra to remember how to pass = >> them=3D >>>> =3D2C at least on little endian stack-growing-down machines (which = >> includes x=3D >>>> 86). For __fastcall I'm not sure they are passed in registers or on = >> the sta=3D >>>> ck. >>>> =20 >>>> Passing and/or returning small structs also has special efficient = >> handling =3D >>>> in the ABI=3D2C so __int64 really might be equivalent to a small = >> record. Not =3D >>>> that cm3 necessarily implements that "correctly" -- for interop with = >> C=3D3B =3D >>>> for Modula-3 calling Modula-3 we can make up our own ABI so there = >> isn't rea=3D >>>> lly an "incorrect" way. Notice the mingw problem I had passing a = >> Win32 poin=3D >>>> t struct by value=3D2C I cheated and passed it by VAR to a C wrapper = >> to worka=3D >>>> round the gcc backend bug (which was mentioned a few times and which = >> I look=3D >>>> ed into the code for=3D2C but took the easy route) >>>> =20 >>>> =3D20 >>>> =20 >>>> =3D20 >>>> =20 >>>> I don't know how long long works on other platforms but probably = >> similar. >>>> =20 >>>> Probably a certain register pair for return values. >>>> =20 >>>> =3D20 >>>> =20 >>>> - Jay >>>> =20 >>>> =3D20 >>>>> To: hosking at cs.purdue.edu >>>>> Date: Sat=3D2C 17 Apr 2010 19:47:03 -0700 >>>>> From: mika at async.async.caltech.edu >>>>> CC: m3devel at elegosoft.com >>>>> Subject: Re: [M3devel] INTEGER >>>>> =3D20 >>>>> Tony Hosking writes: >>>>>> =20 >>>>> ... >>>>>> =20 >>>>>>> We need it to match 64-bit integers on 32-bit machines? That seems = >> =3D3D >>>>>> like >>>>>>> a very weak rationale indeed=3D2C if the same functionality could = >> be =3D3D >>>>>> provided >>>>>>> through some other mechanism (e.g.=3D2C ARRAY [0..1] OF = >> INTEGER---even =3D >>>> =3D3D >>>>>> with >>>>>>> a pragma e.g. <*CLONGLONG*>.. if it is necessary to tell the = >> compiler =3D >>>> =3D3D >>>>>> that >>>>>>> a special linkage convention is needed). >>>>>> =20 >>>>>> There's no special linkage convention. Not sure what you mean here. >>>>>> =20 >>>>> =3D20 >>>>> I just mean if we had >>>>> =3D20 >>>>> TYPE LONGINT =3D3D ARRAY [0..1] OF INTEGER >>>>> =3D20 >>>>> that would perhaps not match how C handles "long long" on the same >>>>> platform (which is how=3D2C come to think of it?)=3D2C and that = >> would require >>>>> special linkage tricks. >>>>> =3D20 >>>>> But what would be lost? The ability to type literals.=3D20 >>>>> =3D20 >>>>> You could get the same code interface on 32- and 64-bit machine by >>>>> defining >>>>> =3D20 >>>>> TYPE FileOffset =3D3D ARRAY[0..1] OF [-16_80000000 .. +16_7fffffff ] >>>>> =3D20 >>>>> and using that. >>>>> =3D20 >>>>> =3D20 >>>>> Mika >>>> =3D >>>> =20 >>>> --_264cb69b-0215-44c3-807c-8b4d8ea0ea59_ >>>> Content-Type: text/html; charset=3D"iso-8859-1" >>>> Content-Transfer-Encoding: quoted-printable >>>> =20 >>>> >>>> >>>> >>>> >>>> >>>> TYPE LONGINT =3D3D ARRAY [0..1] OF INTEGER on a =3D3B32bit system = >> is very c=3D >>>> lose to LONGINT.
>>>>  =3D3BPlus treating it opaquely and providing a bunch of = >> functions to ope=3D >>>> rate on it.
>>>>  =3D3BJust as well therefore could be RECORD hi=3D2Clo:LONGINT = >> END (see LAR=3D >>>> GE_INTEGER and ULARGE_INTEGER in winnt.h)
>>>>  =3D3B
>>>> Differences that come to mind:
>>>>  =3D3B =3D3Binfix operators =3D3B <=3D3B=3D3D=3D3D=3D3D = >>
>>>>  =3D3B possibly passed differently =3D3Bas a parameter
>>>>  =3D3B or returned differently as a result
>>>>  =3D3B ie. probably "directly compatible with" "long long"=3D2C = >> passed by v=3D >>>> alue (of course you could always pass by pointer and achieve = >> compatibilitit=3D >>>> y trivially)
>>>>  =3D3B
>>>>  =3D3B
>>>> I have to say though=3D2C the biggest reason is in-fix operators. = >> Convenient =3D >>>> syntax.
>>>> C++ is the best and some way worst of example of the general right = >> way to d=3D >>>> o this -- you let programmers define types and their infix operators. = >> Other=3D >>>> languages just come with a passle of special cases of types that have = >> in-f=3D >>>> ix operators.
>>>> A good example is that Java infix operator + on string=3D2C besides = >> the vario=3D >>>> us integers=3D2C and nothing else.
>>>>  =3D3B
>>>>  =3D3B
>>>> I think C# lets you define operators=3D2C yet people don't complain = >> that it i=3D >>>> s "a mess" as they do of C++.
>>>> I think Python does now too.
>>>> So it is feature growing in popularity among "mainstream" = >> languages=3D2C not =3D >>>> just C++.
>>>>  =3D3B =3D3B C++ of course is extremely mainstream=3D2C but = >> also a favori=3D >>>> te target. (> href=3D3D"http://www.relisoft.com/tools/CppCritic.html">http:/=3D >>>> /www.relisoft.com/tools/CppCritic.html)
>>>>  =3D3B
>>>>  =3D3B
>>>> We also have subranges of LONGINT.
>>>> I'm not sure what the generalization of subranges are=3D2C = >> granted.
>>>>  =3D3BMaybe some sort of C++ template that takes constants in the = >> templat=3D >>>> e and does range checks at runtime. Yeah=3D2C maybe.
>>>>  =3D3B
>>>>  =3D3B
>>>> And as you point out=3D2C convenient literal syntax.
>>>>  =3D3B
>>>>  =3D3B
>>>> People reasonably argue for library extension in place of language = >> extensio=3D >>>> n=3D2C but that requires a language which is flexible enough to write = >> librari=3D >>>> es with the desired interface=3D2C and so many languages don't let = >> infix oper=3D >>>> ators be in a user-written library.
>>>> (There is a subtle but useless distinction here -- infix operators = >> being in=3D >>>> libraries vs. "user-written" libraries. The infix set operations for = >> examp=3D >>>> le are in a library=3D2C but not user-written=3D2C special=3D2C the = >> compiler know=3D >>>> s about it.)
>>>>  =3D3B
>>>> >=3D3B that would perhaps not match how C handles "long long" on = >> the same>>> R>>=3D3B platform (which is how=3D2C come to think of it?)=3D2C and = >> that would =3D >>>> require

>>>>  =3D3B
>>>> On NT/x86=3D2C __int64/long long is returned in the register pair = >> edx:eax.>>>> =20 >>>> edx is high=3D2C eax is low.
>>>> When passed as a parameter to __stdcall or __cdecl is just passed as = >> two 32=3D >>>> bit values adjacent on the stack=3D2C "hi=3D2C lo=3D2C hi=3D2C lo=3D2C = >> it's off to pu=3D >>>> sh we go" is the Snow White-influenced mantra to remember how to pass = >> them=3D >>>> =3D2C at least on little endian stack-growing-down machines (which = >> includes x=3D >>>> 86). For __fastcall I'm not sure they are passed in registers or on = >> the sta=3D >>>> ck.
>>>> Passing and/or returning small structs also has special efficient = >> handling =3D >>>> in the ABI=3D2C so __int64 really might be equivalent to a small = >> record. Not =3D >>>> that cm3 necessarily implements that "correctly" =3D3B -- for = >> interop wit=3D >>>> h C=3D3B for Modula-3 calling Modula-3 we can make up our own ABI so = >> there is=3D >>>> n't =3D3Breally an "incorrect" way. =3D3BNotice the mingw = >> problem I had=3D >>>> passing a Win32 point struct by value=3D2C I cheated and passed it by = >> VAR to=3D >>>> a =3D3BC wrapper to workaround the gcc backend bug (which was = >> mentioned =3D >>>> a few times and which I looked into the code for=3D2C but took the = >> easy route=3D >>>> )
>>>>  =3D3B
>>>>  =3D3B
>>>> I don't know how long long works on other platforms but probably = >> similar.>>> R> >>>> Probably a certain register pair for return values.
>>>>  =3D3B
>>>>  =3D3B- Jay

 =3D3B
>=3D3B To: = >> hosking at cs.purdue.edu
>=3D3B=3D >>>> Date: Sat=3D2C 17 Apr 2010 19:47:03 -0700
>=3D3B From: = >> mika at async.async.c=3D >>>> altech.edu
>=3D3B CC: m3devel at elegosoft.com
>=3D3B Subject: = >> Re: [M3de=3D >>>> vel] INTEGER
>=3D3B
>=3D3B Tony Hosking writes:
>=3D3B = >> >=3D3B
=3D >>>> >=3D3B ...
>=3D3B >=3D3B
>=3D3B >=3D3B>=3D3B We = >> need it to match 64-b=3D >>>> it integers on 32-bit machines? That seems =3D3D
>=3D3B = >> >=3D3Blike
>=3D >>>> =3D3B >=3D3B>=3D3B a very weak rationale indeed=3D2C if the same = >> functionality =3D >>>> could be =3D3D
>=3D3B >=3D3Bprovided
>=3D3B >=3D3B>=3D3= >> B through some o=3D >>>> ther mechanism (e.g.=3D2C ARRAY [0..1] OF INTEGER---even = >> =3D3D
>=3D3B >=3D3B=3D >>>> with
>=3D3B >=3D3B>=3D3B a pragma e.g. = >> <=3D3B*CLONGLONG*>=3D3B.. if it i=3D >>>> s necessary to tell the compiler =3D3D
>=3D3B = >> >=3D3Bthat
>=3D3B >=3D3B&=3D >>>> gt=3D3B a special linkage convention is needed).
>=3D3B = >> >=3D3B
>=3D3B &=3D >>>> gt=3D3BThere's no special linkage convention. Not sure what you mean = >> here.>>>> >=3D3B >=3D3B
>=3D3B
>=3D3B I just mean if we = >> had
>=3D3B
>=3D >>>> =3D3B TYPE LONGINT =3D3D ARRAY [0..1] OF INTEGER
>=3D3B = >>
>=3D3B that woul=3D >>>> d perhaps not match how C handles "long long" on the same
>=3D3B = >> platfor=3D >>>> m (which is how=3D2C come to think of it?)=3D2C and that would = >> require
>=3D >>>> =3D3B special linkage tricks.
>=3D3B
>=3D3B But what would = >> be lost? Th=3D >>>> e ability to type literals.
>=3D3B
>=3D3B You could get = >> the same co=3D >>>> de interface on 32- and 64-bit machine by
>=3D3B = >> defining
>=3D3B
=3D >>>> >=3D3B TYPE FileOffset =3D3D ARRAY[0..1] OF [-16_80000000 .. = >> +16_7fffffff ]>>> R>>=3D3B
>=3D3B and using that.
>=3D3B
>=3D3B = >>
>=3D3B Mika>>>> >>>> =3D >>>> =20 >>>> --_264cb69b-0215-44c3-807c-8b4d8ea0ea59_-- From jay.krell at cornell.edu Mon Apr 19 04:44:51 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 19 Apr 2010 02:44:51 +0000 Subject: [M3devel] INTEGER In-Reply-To: References: , , ,,<7C7408D0-9A40-4988-BADA-A9FD8C15D388@cs.purdue.edu>, ,,, , , , , , , , , <20100418023535.3BA9E1A2103@async.async.caltech.edu>, , , , <20100418024703.6965B1A2103@async.async.caltech.edu>, , <20100418074927.934461A2117@async.async.caltech.edu>, <04EB7FF8-D304-428D-839E-233FCE009C98@cs.purdue.edu>, <20100418195901.CDACB1A20F6@async.async.caltech.edu>, Message-ID: Mika, the build process hasn't "really" changed. There was always an occasional "bump" where you had to build the compiler skipping m3core/libm3, and then again with building m3core/libm3. It used to happen any time a target was added. But I fixed that. Then it also happened with WIDECHAR, then with LONGINT, then with LONGCARD and the VAL changes. There was also a "bump" when cm3 started using m3core's TextUtils, though I've removed that -- I've removed a few "bumps" where possible, but some remain. Old cm3 cannot compile "modern" m3core/libm3. Other than needing this "skipping" of m3core/libm3, you can actually build the current system starting with an old 5.x release. I haven't tried 5.1/4.1/3.6 yet but maybe I will soon. I actually use current configuration files when doing that though, so that probably inhibits 3.6 (unless I use its configuration files). Having skimmed through http://yarchive.net/comp/longlong.html ... wow folks are *adamant* that C needed long long, like in order to 32bit systems to cross compile for 64bit... I continue to suspect that infix operators and efficiency are the primary motivators. "efficiency" in terms of being sure to avoid function calls for some operations, which is likely doable otherwise. People really want their compiler to handle multiple precision arithmetic, at least to attain 64bit precision. It is nice and convenient, if not strictly necessary. Another view though, besides "interop" with C, is "keeping up" with C. Again that link suggests C has had long long for something like 18 years. We are late. Even C changed, C99 must be around 10 years old now? and has lnog long. Granted, I tend to think of C like you think of Modula-3 --- nice that it never changes. It is somewhat small, very well known. One only needs keep up with libraries now :) and one can assume a certain baseline is everywhere and write portable code to it. (But I've happened upon K&R compiler *recently* -- HP-UX/hppa only bundles a compiler for purposes of changing kernel configuration (constant data) and relinking kernel. The libraries that comprise the kernel are shipped. K&R suffices and is therefore bundled. Best is probably to use that compiler to build old gcc, and then use old gcc to build current gcc (current gcc can't be compiled with K&R)). WIDECHAR is maybe a bit funny. Notice how in C and C++, until subtle small later changes in C++, wchar_t was just a typedef of unsigned short, you could write literals L'a' and L"foo", and there was a bunch of library functions -- again, the "language" aspect being just literals, close to the situation with LONGINT where the language provides literals and infix notation. In fact I think the next version of C++ improves the situation for "literals" of user defined types, like the "constexpr" feature will make constructors better able to stand in for literals, I think. - Jay > From: hosking at cs.purdue.edu > Date: Sun, 18 Apr 2010 20:38:43 -0400 > To: mika at async.async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] INTEGER > > Mika, > > First off, I'd be very interested to know what the issues are with LONGINT and stubgen. We are building that every day in regression testing. It would be really good to get some precise feedback. > > True, LONGINT is integrated with all of the language tools (same as WIDECHAR). > > I suppose that is the price we pay for the language having evolved. Nevertheless, CM3 should be totally backward compatible with the green book. There is no reason it should not build packages from PM3 or SRC. > > Now, this is not to say that perhaps we haven't overreached with LONGINT given that 64-bit is more prevalent. But then it is also useful to be able to interoperate with C libraries. The previous interfacing was pretty much a kludge, using ARRAY[0..1] OF INTEGER for "long long" but then not propagating the double INTEGER value properly throughout the Modula-3 libraries. > > I'm sorry to say that EWD was not particularly renowned for his practicality; pedant more like. Nice to be high and mighty but we also need to interact with the real world. > > We should be able to make this work. Is there a better alternative? Revoke LONGINT, and WIDECHAR? > > On 18 Apr 2010, at 15:59, Mika Nystrom wrote: > > > > > My problem is really just that it's ugly. LONGx is showing up as an issue > > in all sorts of low-level code, which is not surprising since Modula-3 > > with LONGx is not the same language as Modula-3 (maybe we should call > > it Modula-3+?) > > > > The compiler bootstrapping process has gotten more complicated due to it, > > and when I cvs updated m3tk yesterday stubgen wouldn't compile because there > > was something "long" in it that wasn't there before. I have no idea what > > library or components I needed to update and recompile and didn't have the > > time to deal with the issue at the time. > > > > And the new m3tk, stubgen, and compiler(?) won't compile using PM3 or > > SRC M3 since we're no longer using the language of the Green Book. > > (Same comment goes for WIDECHAR, by the way.) > > > > One of the wonderful things about Modula-3 *used to be* that I could > > grab some old package from DECSRC and just use it without changes since > > no one had messed with the language definition. This is still true as > > far as programs that just use the tools go, but it's no longer true for > > programs that process Modula-3 code as input data. Of which there are > > more than a few: many aspects of Modula-3 were specifically designed to > > make the language easy to process by program, as an intermediate format > > and whatnot. > > > > To quote E.W.D.: > > > > 'Unfathomed misunderstanding is further revealed by the term "software > > maintenance", as a result of which many people continue to believe that > > programs and even programming languages themselves are subject to wear > > and tear. Your car needs maintenance too, doesn't it? Famous is the story > > of the oil company that believed that its PASCAL programs did not last > > as long as its FORTRAN programs "because PASCAL was not maintained".' > > > > LONGx is causing me to have to do "software maintenance" on Modula-3 > > programs... for a feature that no one appears to be using and is quickly > > becoming irrelevant. > > > > Mika > > > > > > Tony Hosking writes: > >> In the language spec NUMBER(a) and LAST(a) - FIRST(a) + 1 are *not* = > >> defined to mean the same thing for all types. > >> NUMBER does have an INTEGER value, as expected for subranges of LONGINT = > >> that are not too large. > >> This is as it has always been for subranges of INTEGER that are not too = > >> large. > >> > >> Mika, I'm not sure I see any of the problems you are worrying about in = > >> the current definition of LONGINT/LONGCARD. > >> > >> On 18 Apr 2010, at 03:49, Mika Nystrom wrote: > >> > >>> =20 > >>> Jay I know most of this, and it doesn't really answer the question > >>> "what is it for?" > >>> =20 > >>> I think we've already established that LONGINT isn't useful for = > >> counting > >>> anything that might actually reside in the computer's memory: it makes > >>> no sense as an array index, for instance. INTEGER suffices for that. > >>> =20 > >>> I thought that the only real reason for LONGINT was to match C's > >>> declaration of various seek-related routines on 32-bit machines. > >>> That's not a very good reason. > >>> =20 > >>> C++ succeeds because it does very well in the area(s) it is good at. > >>> People who want to program in C++ will clearly program in C++, not > >>> Modula-3. Modula-3 is never, ever going to be the language of choice = > >> for > >>> people who want lots of snazzy infix operators. Modula-3 is supposed = > >> to > >>> be a language with about as powerful semantics as C++ and an extremely > >>> simple syntax and definition---snazzy infix is one of the things you > >>> give up for that. I don't see how LONGINT fits into this picture. > >>> Now we have LONGCARD too? And it's infected the definitions > >>> of FIRST and LAST? But not NUMBER... argh! > >>> =20 > >>> so, > >>> =20 > >>> NUMBER(a) and LAST(a) - FIRST(a) + 1 > >>> =20 > >>> no longer mean the same thing? Are we going to see lots of comments > >>> in generics in the future where it says T may not be an open array > >>> type nor an array type indexed on LONGINT or a subrange thereof? > >>> =20 > >>> Your comments about different parameter-passing techniques was what I = > >> was > >>> trying to address with my suggestion to have a pragma for this---just = > >> to > >>> match C (and Fortran?), of course. Name me a single Modula-3 = > >> programmer > >>> who cares in what order the bits in his parameters are pushed on the > >>> stack in a Modula-3-to-Modula-3 call. > >>> =20 > >>> And I am definitely in that school of thought that says that = > >> programming > >>> languages should not "evolve". Better to leave well enough alone. > >>> =20 > >>> How much Modula-3 code has been written that uses LONGINT? Other than > >>> to talk to C? I've certainly never used it. > >>> =20 > >>> Mika > >>> =20 > >>> =20 > >>> =20 > >>> Jay K writes: > >>>> --_264cb69b-0215-44c3-807c-8b4d8ea0ea59_ > >>>> Content-Type: text/plain; charset=3D"iso-8859-1" > >>>> Content-Transfer-Encoding: quoted-printable > >>>> =20 > >>>> =20 > >>>> TYPE LONGINT =3D3D ARRAY [0..1] OF INTEGER on a 32bit system is very = > >> close to=3D > >>>> LONGINT. > >>>> =20 > >>>> Plus treating it opaquely and providing a bunch of functions to = > >> operate on=3D > >>>> it. > >>>> =20 > >>>> Just as well therefore could be RECORD hi=3D2Clo:LONGINT END (see = > >> LARGE_INTE=3D > >>>> GER and ULARGE_INTEGER in winnt.h) > >>>> =20 > >>>> =3D20 > >>>> =20 > >>>> Differences that come to mind: > >>>> =20 > >>>> infix operators <=3D3D=3D3D=3D3D=3D20 > >>>> =20 > >>>> possibly passed differently as a parameter > >>>> =20 > >>>> or returned differently as a result > >>>> =20 > >>>> ie. probably "directly compatible with" "long long"=3D2C passed by = > >> value (o=3D > >>>> f course you could always pass by pointer and achieve compatibilitity = > >> trivi=3D > >>>> ally) > >>>> =20 > >>>> =3D20 > >>>> =20 > >>>> =3D20 > >>>> =20 > >>>> I have to say though=3D2C the biggest reason is in-fix operators. = > >> Convenient =3D > >>>> syntax. > >>>> =20 > >>>> C++ is the best and some way worst of example of the general right = > >> way to d=3D > >>>> o this -- you let programmers define types and their infix operators. = > >> Other=3D > >>>> languages just come with a passle of special cases of types that have = > >> in-f=3D > >>>> ix operators. > >>>> =20 > >>>> A good example is that Java infix operator + on string=3D2C besides = > >> the vario=3D > >>>> us integers=3D2C and nothing else. > >>>> =20 > >>>> =3D20 > >>>> =20 > >>>> =3D20 > >>>> =20 > >>>> I think C# lets you define operators=3D2C yet people don't complain = > >> that it i=3D > >>>> s "a mess" as they do of C++. > >>>> =20 > >>>> I think Python does now too. > >>>> =20 > >>>> So it is feature growing in popularity among "mainstream" = > >> languages=3D2C not =3D > >>>> just C++. > >>>> =20 > >>>> C++ of course is extremely mainstream=3D2C but also a favorite = > >> target. (ht=3D > >>>> tp://www.relisoft.com/tools/CppCritic.html) > >>>> =20 > >>>> =3D20 > >>>> =20 > >>>> =3D20 > >>>> =20 > >>>> We also have subranges of LONGINT. > >>>> =20 > >>>> I'm not sure what the generalization of subranges are=3D2C granted. > >>>> =20 > >>>> Maybe some sort of C++ template that takes constants in the template = > >> and d=3D > >>>> oes range checks at runtime. Yeah=3D2C maybe. > >>>> =20 > >>>> =3D20 > >>>> =20 > >>>> =3D20 > >>>> =20 > >>>> And as you point out=3D2C convenient literal syntax. > >>>> =20 > >>>> =3D20 > >>>> =20 > >>>> =3D20 > >>>> =20 > >>>> People reasonably argue for library extension in place of language = > >> extensio=3D > >>>> n=3D2C but that requires a language which is flexible enough to write = > >> librari=3D > >>>> es with the desired interface=3D2C and so many languages don't let = > >> infix oper=3D > >>>> ators be in a user-written library. > >>>> =20 > >>>> (There is a subtle but useless distinction here -- infix operators = > >> being in=3D > >>>> libraries vs. "user-written" libraries. The infix set operations for = > >> examp=3D > >>>> le are in a library=3D2C but not user-written=3D2C special=3D2C the = > >> compiler know=3D > >>>> s about it.) > >>>> =20 > >>>> =3D20 > >>>> =20 > >>>>> that would perhaps not match how C handles "long long" on the same > >>>>> platform (which is how=3D2C come to think of it?)=3D2C and that = > >> would require > >>>> =20 > >>>> =20 > >>>> =3D20 > >>>> =20 > >>>> On NT/x86=3D2C __int64/long long is returned in the register pair = > >> edx:eax. > >>>> =20 > >>>> edx is high=3D2C eax is low. > >>>> =20 > >>>> When passed as a parameter to __stdcall or __cdecl is just passed as = > >> two 32=3D > >>>> bit values adjacent on the stack=3D2C "hi=3D2C lo=3D2C hi=3D2C lo=3D2C = > >> it's off to pu=3D > >>> sh we go" is the Snow White-influenced mantra to remember how to pass = > >> them=3D > >>>> =3D2C at least on little endian stack-growing-down machines (which = > >> includes x=3D > >>>> 86). For __fastcall I'm not sure they are passed in registers or on = > >> the sta=3D > >>>> ck. > >>>> =20 > >>>> Passing and/or returning small structs also has special efficient = > >> handling =3D > >>>> in the ABI=3D2C so __int64 really might be equivalent to a small = > >> record. Not =3D > >>>> that cm3 necessarily implements that "correctly" -- for interop with = > >> C=3D3B =3D > >>>> for Modula-3 calling Modula-3 we can make up our own ABI so there = > >> isn't rea=3D > >>>> lly an "incorrect" way. Notice the mingw problem I had passing a = > >> Win32 poin=3D > >>>> t struct by value=3D2C I cheated and passed it by VAR to a C wrapper = > >> to worka=3D > >>>> round the gcc backend bug (which was mentioned a few times and which = > >> I look=3D > >>>> ed into the code for=3D2C but took the easy route) > >>>> =20 > >>>> =3D20 > >>>> =20 > >>>> =3D20 > >>>> =20 > >>>> I don't know how long long works on other platforms but probably = > >> similar. > >>>> =20 > >>>> Probably a certain register pair for return values. > >>>> =20 > >>>> =3D20 > >>>> =20 > >>>> - Jay > >>>> =20 > >>>> =3D20 > >>>>> To: hosking at cs.purdue.edu > >>>>> Date: Sat=3D2C 17 Apr 2010 19:47:03 -0700 > >>>>> From: mika at async.async.caltech.edu > >>>>> CC: m3devel at elegosoft.com > >>>>> Subject: Re: [M3devel] INTEGER > >>>>> =3D20 > >>>>> Tony Hosking writes: > >>>>>> =20 > >>>>> ... > >>>>>> =20 > >>>>>>> We need it to match 64-bit integers on 32-bit machines? That seems = > >> =3D3D > >>>>>> like > >>>>>>> a very weak rationale indeed=3D2C if the same functionality could = > >> be =3D3D > >>>>>> provided > >>>>>>> through some other mechanism (e.g.=3D2C ARRAY [0..1] OF = > >> INTEGER---even =3D > >>>> =3D3D > >>>>>> with > >>>>>>> a pragma e.g. <*CLONGLONG*>.. if it is necessary to tell the = > >> compiler =3D > >>>> =3D3D > >>>>>> that > >>>>>>> a special linkage convention is needed). > >>>>>> =20 > >>>>>> There's no special linkage convention. Not sure what you mean here. > >>>>>> =20 > >>>>> =3D20 > >>>>> I just mean if we had > >>>>> =3D20 > >>>>> TYPE LONGINT =3D3D ARRAY [0..1] OF INTEGER > >>>>> =3D20 > >>>>> that would perhaps not match how C handles "long long" on the same > >>>>> platform (which is how=3D2C come to think of it?)=3D2C and that = > >> would require > >>>>> special linkage tricks. > >>>>> =3D20 > >>>>> But what would be lost? The ability to type literals.=3D20 > >>>>> =3D20 > >>>>> You could get the same code interface on 32- and 64-bit machine by > >>>>> defining > >>>>> =3D20 > >>>>> TYPE FileOffset =3D3D ARRAY[0..1] OF [-16_80000000 .. +16_7fffffff ] > >>>>> =3D20 > >>>>> and using that. > >>>>> =3D20 > >>>>> =3D20 > >>>>> Mika > >>>> =3D > >>>> =20 > >>>> --_264cb69b-0215-44c3-807c-8b4d8ea0ea59_ > >>>> Content-Type: text/html; charset=3D"iso-8859-1" > >>>> Content-Transfer-Encoding: quoted-printable > >>>> =20 > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> TYPE LONGINT =3D3D ARRAY [0..1] OF INTEGER on a =3D3B32bit system = > >> is very c=3D > >>>> lose to LONGINT.
> >>>>  =3D3BPlus treating it opaquely and providing a bunch of = > >> functions to ope=3D > >>>> rate on it.
> >>>>  =3D3BJust as well therefore could be RECORD hi=3D2Clo:LONGINT = > >> END (see LAR=3D > >>>> GE_INTEGER and ULARGE_INTEGER in winnt.h)
> >>>>  =3D3B
> >>>> Differences that come to mind:
> >>>>  =3D3B =3D3Binfix operators =3D3B <=3D3B=3D3D=3D3D=3D3D = > >>
> >>>>  =3D3B possibly passed differently =3D3Bas a parameter
> >>>>  =3D3B or returned differently as a result
> >>>>  =3D3B ie. probably "directly compatible with" "long long"=3D2C = > >> passed by v=3D > >>>> alue (of course you could always pass by pointer and achieve = > >> compatibilitit=3D > >>>> y trivially)
> >>>>  =3D3B
> >>>>  =3D3B
> >>>> I have to say though=3D2C the biggest reason is in-fix operators. = > >> Convenient =3D > >>>> syntax.
> >>>> C++ is the best and some way worst of example of the general right = > >> way to d=3D > >>>> o this -- you let programmers define types and their infix operators. = > >> Other=3D > >>>> languages just come with a passle of special cases of types that have = > >> in-f=3D > >>>> ix operators.
> >>>> A good example is that Java infix operator + on string=3D2C besides = > >> the vario=3D > >>>> us integers=3D2C and nothing else.
> >>>>  =3D3B
> >>>>  =3D3B
> >>>> I think C# lets you define operators=3D2C yet people don't complain = > >> that it i=3D > >>>> s "a mess" as they do of C++.
> >>>> I think Python does now too.
> >>>> So it is feature growing in popularity among "mainstream" = > >> languages=3D2C not =3D > >>>> just C++.
> >>>>  =3D3B =3D3B C++ of course is extremely mainstream=3D2C but = > >> also a favori=3D > >>>> te target. ( >> href=3D3D"http://www.relisoft.com/tools/CppCritic.html">http:/=3D > >>>> /www.relisoft.com/tools/CppCritic.html)
> >>>>  =3D3B
> >>>>  =3D3B
> >>>> We also have subranges of LONGINT.
> >>>> I'm not sure what the generalization of subranges are=3D2C = > >> granted.
> >>>>  =3D3BMaybe some sort of C++ template that takes constants in the = > >> templat=3D > >>>> e and does range checks at runtime. Yeah=3D2C maybe.
> >>>>  =3D3B
> >>>>  =3D3B
> >>>> And as you point out=3D2C convenient literal syntax.
> >>>>  =3D3B
> >>>>  =3D3B
> >>>> People reasonably argue for library extension in place of language = > >> extensio=3D > >>>> n=3D2C but that requires a language which is flexible enough to write = > >> librari=3D > >>>> es with the desired interface=3D2C and so many languages don't let = > >> infix oper=3D > >>>> ators be in a user-written library.
> >>>> (There is a subtle but useless distinction here -- infix operators = > >> being in=3D > >>>> libraries vs. "user-written" libraries. The infix set operations for = > >> examp=3D > >>>> le are in a library=3D2C but not user-written=3D2C special=3D2C the = > >> compiler know=3D > >>>> s about it.)
> >>>>  =3D3B
> >>>> >=3D3B that would perhaps not match how C handles "long long" on = > >> the same >>>> R>>=3D3B platform (which is how=3D2C come to think of it?)=3D2C and = > >> that would =3D > >>>> require

> >>>>  =3D3B
> >>>> On NT/x86=3D2C __int64/long long is returned in the register pair = > >> edx:eax. >>>>> =20 > >>>> edx is high=3D2C eax is low.
> >>>> When passed as a parameter to __stdcall or __cdecl is just passed as = > >> two 32=3D > >>>> bit values adjacent on the stack=3D2C "hi=3D2C lo=3D2C hi=3D2C lo=3D2C = > >> it's off to pu=3D > >>>> sh we go" is the Snow White-influenced mantra to remember how to pass = > >> them=3D > >>>> =3D2C at least on little endian stack-growing-down machines (which = > >> includes x=3D > >>>> 86). For __fastcall I'm not sure they are passed in registers or on = > >> the sta=3D > >>>> ck.
> >>>> Passing and/or returning small structs also has special efficient = > >> handling =3D > >>>> in the ABI=3D2C so __int64 really might be equivalent to a small = > >> record. Not =3D > >>>> that cm3 necessarily implements that "correctly" =3D3B -- for = > >> interop wit=3D > >>>> h C=3D3B for Modula-3 calling Modula-3 we can make up our own ABI so = > >> there is=3D > >>>> n't =3D3Breally an "incorrect" way. =3D3BNotice the mingw = > >> problem I had=3D > >>>> passing a Win32 point struct by value=3D2C I cheated and passed it by = > >> VAR to=3D > >>>> a =3D3BC wrapper to workaround the gcc backend bug (which was = > >> mentioned =3D > >>>> a few times and which I looked into the code for=3D2C but took the = > >> easy route=3D > >>>> )
> >>>>  =3D3B
> >>>>  =3D3B
> >>>> I don't know how long long works on other platforms but probably = > >> similar. >>>> R> > >>>> Probably a certain register pair for return values.
> >>>>  =3D3B
> >>>>  =3D3B- Jay

 =3D3B
>=3D3B To: = > >> hosking at cs.purdue.edu
>=3D3B=3D > >>>> Date: Sat=3D2C 17 Apr 2010 19:47:03 -0700
>=3D3B From: = > >> mika at async.async.c=3D > >>>> altech.edu
>=3D3B CC: m3devel at elegosoft.com
>=3D3B Subject: = > >> Re: [M3de=3D > >>>> vel] INTEGER
>=3D3B
>=3D3B Tony Hosking writes:
>=3D3B = > >> >=3D3B
=3D > >>>> >=3D3B ...
>=3D3B >=3D3B
>=3D3B >=3D3B>=3D3B We = > >> need it to match 64-b=3D > >>>> it integers on 32-bit machines? That seems =3D3D
>=3D3B = > >> >=3D3Blike
>=3D > >>>> =3D3B >=3D3B>=3D3B a very weak rationale indeed=3D2C if the same = > >> functionality =3D > >>>> could be =3D3D
>=3D3B >=3D3Bprovided
>=3D3B >=3D3B>=3D3= > >> B through some o=3D > >>>> ther mechanism (e.g.=3D2C ARRAY [0..1] OF INTEGER---even = > >> =3D3D
>=3D3B >=3D3B=3D > >>>> with
>=3D3B >=3D3B>=3D3B a pragma e.g. = > >> <=3D3B*CLONGLONG*>=3D3B.. if it i=3D > >>>> s necessary to tell the compiler =3D3D
>=3D3B = > >> >=3D3Bthat
>=3D3B >=3D3B&=3D > >>>> gt=3D3B a special linkage convention is needed).
>=3D3B = > >> >=3D3B
>=3D3B &=3D > >>>> gt=3D3BThere's no special linkage convention. Not sure what you mean = > >> here. >>>>> >=3D3B >=3D3B
>=3D3B
>=3D3B I just mean if we = > >> had
>=3D3B
>=3D > >>>> =3D3B TYPE LONGINT =3D3D ARRAY [0..1] OF INTEGER
>=3D3B = > >>
>=3D3B that woul=3D > >>>> d perhaps not match how C handles "long long" on the same
>=3D3B = > >> platfor=3D > >>>> m (which is how=3D2C come to think of it?)=3D2C and that would = > >> require
>=3D > >>>> =3D3B special linkage tricks.
>=3D3B
>=3D3B But what would = > >> be lost? Th=3D > >>>> e ability to type literals.
>=3D3B
>=3D3B You could get = > >> the same co=3D > >>>> de interface on 32- and 64-bit machine by
>=3D3B = > >> defining
>=3D3B
=3D > >>>> >=3D3B TYPE FileOffset =3D3D ARRAY[0..1] OF [-16_80000000 .. = > >> +16_7fffffff ] >>>> R>>=3D3B
>=3D3B and using that.
>=3D3B
>=3D3B = > >>
>=3D3B Mika >>>>> > >>>> =3D > >>>> =20 > >>>> --_264cb69b-0215-44c3-807c-8b4d8ea0ea59_-- > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Apr 19 05:27:01 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 19 Apr 2010 03:27:01 +0000 Subject: [M3devel] the lingering socket linger question, non-blocking Win32 sockets? Message-ID: shorter story: - Does anyone have significant socket-using Modula-3 code to test? That is used on Posix and Win32? - Given the extremely high similarly between the Windows and Posix (BSD) socket interfaces, I strongly suggest we unify the implementations, including removing some of the historical differences. I also strongly suspect the Posix implementation is the "better" one, that has recieved more thought and testing. The Win32 variants of the Modula-3 libraries often seem..suspicious. Like they were a very initial version but never really recieved the attention needed. longer story: So..I've asked a few times, why this seemingly opposite code: C:\dev2\cm3.2\m3-libs\libm3\src\os\POSIX\SocketPosix.m3(453): linger := struct_linger{1, 1}; C:\dev2\cm3.2\m3-libs\libm3\src\os\WIN32\SocketWin32.m3(401): linger := struct_linger{0, 0}; I have a *little* more information. Windows documentation warns about using linger{1} on non-blocking sockets. The default {0} seems to be what you'd want. Seems like the setsockopt isn't needed. SocketPosix.m3 sets sockets to be non-blocking. I associate "non blocking" with "prone to be slow or hang-until-timeout in real world, want to avoid that". Older SocketWin32.m3 seems to have in mind non-blocking: Searching for 'WSAEWOULDBLOCK'... C:\dev2\cm3.2\m3-libs\libm3\src\os\WIN32\SocketWin32.m3.sav(137): | WinSock.WSAEWOULDBLOCK => C:\dev2\cm3.2\m3-libs\libm3\src\os\WIN32\SocketWin32.m3.sav(189): | WinSock.WSAEWOULDBLOCK => C:\dev2\cm3.2\m3-libs\libm3\src\os\WIN32\SocketWin32.m3.sav(241): | WinSock.WSAEWOULDBLOCK => C:\dev2\cm3.2\m3-libs\libm3\src\os\WIN32\SocketWin32.m3.sav(274): | WinSock.WSAEWOULDBLOCK => C:\dev2\cm3.2\m3-libs\libm3\src\os\WIN32\SocketWin32.m3.sav(315): | WinSock.WSAEWOULDBLOCK => C:\dev2\cm3.2\m3-libs\libm3\src\os\WIN32\SocketWin32.m3.sav(356): | WinSock.WSAEWOULDBLOCK => current SocketWin32.m3 does *not* set the sockets to non-blocking. And there seems to be patterns to account for that -- checking BytesAvailable at the start of operations like Read and ReceiveFrom, where the Posix version does not. The Posix version using select/poll where the Win32 version does not (though the win32 ".sav" files does). SocketWin32.m3.sav: IF WinSock.ioctlsocket (sock, WinSock.FIONBIO, ADR(one)) = SockErr THEN Using select/poll in Posix is slightly complicated by user threads. The complexity is under the covers in the thread implementation. Win32 doesn't have that problem. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Apr 19 06:37:12 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 19 Apr 2010 04:37:12 +0000 Subject: [M3devel] Posix < 0 vs. # 0 vs. = -1? In-Reply-To: <20100418194159.E07411A2119@async.async.caltech.edu> References: , <20100418194159.E07411A2119@async.async.caltech.edu> Message-ID: Mika, you mean [-1..LAST(INTEGER)] right? - Jay > To: jay.krell at cornell.edu > Date: Sun, 18 Apr 2010 12:41:59 -0700 > From: mika at async.async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Posix < 0 vs. # 0 vs. = -1? > > Jay K writes: > >--_201b8a99-e8e8-4887-bb32-c65e8edd0b1a_ > >Content-Type: text/plain; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > >Posix often says: > > > > function foo() returns 0 for success=2C -1 for error > > > >=20 > > > > m3core/libm3/etc=2C often say if foo() < 0 or if foo() # 0 "instead". > > Generally ok to tighten these up to "=3D -1"=2C perhaps upon checking manp= > >ages=2C > > or a known rat's nest of inconsistencies? > > > > Maybe this is just my personal style, but I would code it thus: > > <*EXTERNAL*> > PROCEDURE F() : INTEGER; (* matches C declaration *) > > ... > > VAR result : [0..1] := F(); (* matches man page specification *) > BEGIN > CASE result OF > 0 => ... > | > -1 => ... > END > END > > No way for any sneaky value problems to get through. The use of > CASE also guards against typos. > > Mika -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Mon Apr 19 06:47:14 2010 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Mon, 19 Apr 2010 04:47:14 +0000 (GMT) Subject: [M3devel] INTEGER In-Reply-To: <20100418195901.CDACB1A20F6@async.async.caltech.edu> Message-ID: <141192.73575.qm@web23603.mail.ird.yahoo.com> Hi: I think the irrelevant point is arguable as there are SIMD instructions of 128-bit and later will be 256-bit packed types registers so the point of becoming irrelevant could be worrisome in time, probably not now. As packed types weren't to traumatic but are more needed now by this fact. If you wish more generality, a language change will be needed, not an extension, language extensions are easily doable with enough knowledge but right now you would need to do it or it will become harder and harder to reconstruct your own code. If you need backward compatibility why don't host cm3 with pm3, that is old cm3 can't compile cm3 but its negative inverse is true and it is old known old cm3 can build pm3 and src m3 (current cm3 built itself as I saw with RC5 on AMD64_LINUX). Still you want to host other older environments look for doing it with CM3, I think it wouldn't be so much traumatic, wouldn't it? You would compile and have two different runtime but you could do what you want to do, as I guess you were doing for other reasons and it wouldn't be so much effort to do it, maybe the ugly parts would be system dependent things as I think. I think there are many other options as to be backwards compatible like drop new features or build against other specific libraries, but again is not that the purpose you are looking for, then is simpler if you think the above intention in some sense to you? It's just an idea, hope it helps something. --- El dom, 18/4/10, Mika Nystrom escribi?: > De: Mika Nystrom > Asunto: Re: [M3devel] INTEGER > Para: "Tony Hosking" > CC: m3devel at elegosoft.com > Fecha: domingo, 18 de abril, 2010 14:59 > > My problem is really just that it's ugly. LONGx is > showing up as an issue > in all sorts of low-level code, which is not surprising > since Modula-3 > with LONGx is not the same language as Modula-3 (maybe we > should call > it Modula-3+?) > > The compiler bootstrapping process has gotten more > complicated due to it, > and when I cvs updated m3tk yesterday stubgen wouldn't > compile because there > was something "long" in it that wasn't there before. > I have no idea what > library or components I needed to update and recompile and > didn't have the > time to deal with the issue at the time. > > And the new m3tk, stubgen, and compiler(?) won't compile > using PM3 or > SRC M3 since we're no longer using the language of the > Green Book. > (Same comment goes for WIDECHAR, by the way.) > > One of the wonderful things about Modula-3 *used to be* > that I could > grab some old package from DECSRC and just use it without > changes since > no one had messed with the language definition. This > is still true as > far as programs that just use the tools go, but it's no > longer true for > programs that process Modula-3 code as input data. Of > which there are > more than a few: many aspects of Modula-3 were specifically > designed to > make the language easy to process by program, as an > intermediate format > and whatnot. > > To quote E.W.D.: > > 'Unfathomed misunderstanding is further revealed by the > term "software > maintenance", as a result of which many people continue to > believe that > programs and even programming languages themselves are > subject to wear > and tear. Your car needs maintenance too, doesn't it? > Famous is the story > of the oil company that believed that its PASCAL programs > did not last > as long as its FORTRAN programs "because PASCAL was not > maintained".' > > LONGx is causing me to have to do "software maintenance" on > Modula-3 > programs... for a feature that no one appears to be using > and is quickly > becoming irrelevant. > > Mika > > > Tony Hosking writes: > >In the language spec NUMBER(a) and LAST(a) - FIRST(a) + > 1 are *not* = > >defined to mean the same thing for all types. > >NUMBER does have an INTEGER value, as expected for > subranges of LONGINT = > >that are not too large. > >This is as it has always been for subranges of INTEGER > that are not too = > >large. > > > >Mika, I'm not sure I see any of the problems you are > worrying about in = > >the current definition of LONGINT/LONGCARD. > > > >On 18 Apr 2010, at 03:49, Mika Nystrom wrote: > > > >>=20 > >> Jay I know most of this, and it doesn't really > answer the question > >> "what is it for?" > >>=20 > >> I think we've already established that LONGINT > isn't useful for = > >counting > >> anything that might actually reside in the > computer's memory: it makes > >> no sense as an array index, for instance. > INTEGER suffices for that. > >>=20 > >> I thought that the only real reason for LONGINT > was to match C's > >> declaration of various seek-related routines on > 32-bit machines. > >> That's not a very good reason. > >>=20 > >> C++ succeeds because it does very well in the > area(s) it is good at. > >> People who want to program in C++ will clearly > program in C++, not > >> Modula-3. Modula-3 is never, ever going to > be the language of choice = > >for > >> people who want lots of snazzy infix > operators. Modula-3 is supposed = > >to > >> be a language with about as powerful semantics as > C++ and an extremely > >> simple syntax and definition---snazzy infix is one > of the things you > >> give up for that. I don't see how LONGINT > fits into this picture. > >> Now we have LONGCARD too? And it's infected > the definitions > >> of FIRST and LAST? But not NUMBER... argh! > >>=20 > >> so, > >>=20 > >> NUMBER(a) and LAST(a) - FIRST(a) + 1 > >>=20 > >> no longer mean the same thing? Are we going > to see lots of comments > >> in generics in the future where it says T may not > be an open array > >> type nor an array type indexed on LONGINT or a > subrange thereof? > >>=20 > >> Your comments about different parameter-passing > techniques was what I = > >was > >> trying to address with my suggestion to have a > pragma for this---just = > >to > >> match C (and Fortran?), of course. Name me a > single Modula-3 = > >programmer > >> who cares in what order the bits in his parameters > are pushed on the > >> stack in a Modula-3-to-Modula-3 call. > >>=20 > >> And I am definitely in that school of thought that > says that = > >programming > >> languages should not "evolve". Better to > leave well enough alone. > >>=20 > >> How much Modula-3 code has been written that uses > LONGINT? Other than > >> to talk to C? I've certainly never used it. > >>=20 > >> Mika > >>=20 > >>=20 > >>=20 > >> Jay K writes: > >>> --_264cb69b-0215-44c3-807c-8b4d8ea0ea59_ > >>> Content-Type: text/plain; > charset=3D"iso-8859-1" > >>> Content-Transfer-Encoding: quoted-printable > >>>=20 > >>>=20 > >>> TYPE LONGINT =3D3D ARRAY [0..1] OF INTEGER on > a 32bit system is very = > >close to=3D > >>> LONGINT. > >>>=20 > >>> Plus treating it opaquely and providing a > bunch of functions to = > >operate on=3D > >>> it. > >>>=20 > >>> Just as well therefore could be RECORD > hi=3D2Clo:LONGINT END (see = > >LARGE_INTE=3D > >>> GER and ULARGE_INTEGER in winnt.h) > >>>=20 > >>> =3D20 > >>>=20 > >>> Differences that come to mind: > >>>=20 > >>> infix operators > <=3D3D=3D3D=3D3D=3D20 > >>>=20 > >>> possibly passed differently as a parameter > >>>=20 > >>> or returned differently as a result > >>>=20 > >>> ie. probably "directly compatible with" "long > long"=3D2C passed by = > >value (o=3D > >>> f course you could always pass by pointer and > achieve compatibilitity = > >trivi=3D > >>> ally) > >>>=20 > >>> =3D20 > >>>=20 > >>> =3D20 > >>>=20 > >>> I have to say though=3D2C the biggest reason > is in-fix operators. = > >Convenient =3D > >>> syntax. > >>>=20 > >>> C++ is the best and some way worst of example > of the general right = > >way to d=3D > >>> o this -- you let programmers define types and > their infix operators. = > >Other=3D > >>> languages just come with a passle of special > cases of types that have = > >in-f=3D > >>> ix operators. > >>>=20 > >>> A good example is that Java infix operator + > on string=3D2C besides = > >the vario=3D > >>> us integers=3D2C and nothing else. > >>>=20 > >>> =3D20 > >>>=20 > >>> =3D20 > >>>=20 > >>> I think C# lets you define operators=3D2C yet > people don't complain = > >that it i=3D > >>> s "a mess" as they do of C++. > >>>=20 > >>> I think Python does now too. > >>>=20 > >>> So it is feature growing in popularity among > "mainstream" = > >languages=3D2C not =3D > >>> just C++. > >>>=20 > >>> C++ of course is extremely > mainstream=3D2C but also a favorite = > >target. (ht=3D > >>> tp://www.relisoft.com/tools/CppCritic.html) > >>>=20 > >>> =3D20 > >>>=20 > >>> =3D20 > >>>=20 > >>> We also have subranges of LONGINT. > >>>=20 > >>> I'm not sure what the generalization of > subranges are=3D2C granted. > >>>=20 > >>> Maybe some sort of C++ template that takes > constants in the template = > >and d=3D > >>> oes range checks at runtime. Yeah=3D2C maybe. > >>>=20 > >>> =3D20 > >>>=20 > >>> =3D20 > >>>=20 > >>> And as you point out=3D2C convenient literal > syntax. > >>>=20 > >>> =3D20 > >>>=20 > >>> =3D20 > >>>=20 > >>> People reasonably argue for library extension > in place of language = > >extensio=3D > >>> n=3D2C but that requires a language which is > flexible enough to write = > >librari=3D > >>> es with the desired interface=3D2C and so many > languages don't let = > >infix oper=3D > >>> ators be in a user-written library. > >>>=20 > >>> (There is a subtle but useless distinction > here -- infix operators = > >being in=3D > >>> libraries vs. "user-written" libraries. The > infix set operations for = > >examp=3D > >>> le are in a library=3D2C but not > user-written=3D2C special=3D2C the = > >compiler know=3D > >>> s about it.) > >>>=20 > >>> =3D20 > >>>=20 > >>>> that would perhaps not match how C handles > "long long" on the same > >>>> platform (which is how=3D2C come to think > of it?)=3D2C and that = > >would require > >>>=20 > >>>=20 > >>> =3D20 > >>>=20 > >>> On NT/x86=3D2C __int64/long long is returned > in the register pair = > >edx:eax. > >>>=20 > >>> edx is high=3D2C eax is low. > >>>=20 > >>> When passed as a parameter to __stdcall or > __cdecl is just passed as = > >two 32=3D > >>> bit values adjacent on the stack=3D2C "hi=3D2C > lo=3D2C hi=3D2C lo=3D2C = > >it's off to pu=3D > >> sh we go" is the Snow White-influenced mantra to > remember how to pass = > >them=3D > >>> =3D2C at least on little endian > stack-growing-down machines (which = > >includes x=3D > >>> 86). For __fastcall I'm not sure they are > passed in registers or on = > >the sta=3D > >>> ck. > >>>=20 > >>> Passing and/or returning small structs also > has special efficient = > >handling =3D > >>> in the ABI=3D2C so __int64 really might be > equivalent to a small = > >record. Not =3D > >>> that cm3 necessarily implements that > "correctly" -- for interop with = > >C=3D3B =3D > >>> for Modula-3 calling Modula-3 we can make up > our own ABI so there = > >isn't rea=3D > >>> lly an "incorrect" way. Notice the mingw > problem I had passing a = > >Win32 poin=3D > >>> t struct by value=3D2C I cheated and passed it > by VAR to a C wrapper = > >to worka=3D > >>> round the gcc backend bug (which was mentioned > a few times and which = > >I look=3D > >>> ed into the code for=3D2C but took the easy > route) > >>>=20 > >>> =3D20 > >>>=20 > >>> =3D20 > >>>=20 > >>> I don't know how long long works on other > platforms but probably = > >similar. > >>>=20 > >>> Probably a certain register pair for return > values. > >>>=20 > >>> =3D20 > >>>=20 > >>> - Jay > >>>=20 > >>> =3D20 > >>>> To: hosking at cs.purdue.edu > >>>> Date: Sat=3D2C 17 Apr 2010 19:47:03 -0700 > >>>> From: mika at async.async.caltech.edu > >>>> CC: m3devel at elegosoft.com > >>>> Subject: Re: [M3devel] INTEGER > >>>> =3D20 > >>>> Tony Hosking writes: > >>>>>=20 > >>>> ... > >>>>>=20 > >>>>>> We need it to match 64-bit > integers on 32-bit machines? That seems = > >=3D3D > >>>>> like > >>>>>> a very weak rationale indeed=3D2C > if the same functionality could = > >be =3D3D > >>>>> provided > >>>>>> through some other mechanism > (e.g.=3D2C ARRAY [0..1] OF = > >INTEGER---even =3D > >>> =3D3D > >>>>> with > >>>>>> a pragma e.g. > <*CLONGLONG*>.. if it is necessary to tell the = > >compiler =3D > >>> =3D3D > >>>>> that > >>>>>> a special linkage convention is > needed). > >>>>>=20 > >>>>> There's no special linkage convention. > Not sure what you mean here. > >>>>>=20 > >>>> =3D20 > >>>> I just mean if we had > >>>> =3D20 > >>>> TYPE LONGINT =3D3D ARRAY [0..1] OF > INTEGER > >>>> =3D20 > >>>> that would perhaps not match how C handles > "long long" on the same > >>>> platform (which is how=3D2C come to think > of it?)=3D2C and that = > >would require > >>>> special linkage tricks. > >>>> =3D20 > >>>> But what would be lost? The ability to > type literals.=3D20 > >>>> =3D20 > >>>> You could get the same code interface on > 32- and 64-bit machine by > >>>> defining > >>>> =3D20 > >>>> TYPE FileOffset =3D3D ARRAY[0..1] OF > [-16_80000000 .. +16_7fffffff ] > >>>> =3D20 > >>>> and using that. > >>>> =3D20 > >>>> =3D20 > >>>> Mika > >>> > > > =3D > >>>=20 > >>> --_264cb69b-0215-44c3-807c-8b4d8ea0ea59_ > >>> Content-Type: text/html; > charset=3D"iso-8859-1" > >>> Content-Transfer-Encoding: quoted-printable > >>>=20 > >>> > >>> > >>> > >>> > >>> > >>> TYPE LONGINT =3D3D ARRAY [0..1] OF INTEGER on > a =3D3B32bit system = > >is very c=3D > >>> lose to LONGINT.
> >>>  =3D3BPlus treating it opaquely and > providing a bunch of = > >functions to ope=3D > >>> rate on it.
> >>>  =3D3BJust as well therefore could be > RECORD hi=3D2Clo:LONGINT = > >END (see LAR=3D > >>> GE_INTEGER and ULARGE_INTEGER in > winnt.h)
> >>>  =3D3B
> >>> Differences that come to mind:
> >>>  =3D3B =3D3Binfix > operators =3D3B <=3D3B=3D3D=3D3D=3D3D = > >
> >>>  =3D3B possibly passed > differently =3D3Bas a parameter
> >>>  =3D3B or returned differently as a > result
> >>>  =3D3B ie. probably "directly > compatible with" "long long"=3D2C = > >passed by v=3D > >>> alue (of course you could always pass by > pointer and achieve = > >compatibilitit=3D > >>> y trivially)
> >>>  =3D3B
> >>>  =3D3B
> >>> I have to say though=3D2C the biggest reason > is in-fix operators. = > >Convenient =3D > >>> syntax.
> >>> C++ is the best and some way worst of example > of the general right = > >way to d=3D > >>> o this -- you let programmers define types and > their infix operators. = > >Other=3D > >>> languages just come with a passle of special > cases of types that have = > >in-f=3D > >>> ix operators.
> >>> A good example is that Java infix operator + > on string=3D2C besides = > >the vario=3D > >>> us integers=3D2C and nothing else.
> >>>  =3D3B
> >>>  =3D3B
> >>> I think C# lets you define operators=3D2C yet > people don't complain = > >that it i=3D > >>> s "a mess" as they do of C++.
> >>> I think Python does now too.
> >>> So it is feature growing in popularity among > "mainstream" = > >languages=3D2C not =3D > >>> just C++.
> >>>  =3D3B =3D3B C++ of course is > extremely mainstream=3D2C but = > >also a favori=3D > >>> te target. ( >href=3D3D"http://www.relisoft.com/tools/CppCritic.html">http:/=3D > >>> > /www.relisoft.com/tools/CppCritic.html)
> >>>  =3D3B
> >>>  =3D3B
> >>> We also have subranges of LONGINT.
> >>> I'm not sure what the generalization of > subranges are=3D2C = > >granted.
> >>>  =3D3BMaybe some sort of C++ template > that takes constants in the = > >templat=3D > >>> e and does range checks at runtime. Yeah=3D2C > maybe.
> >>>  =3D3B
> >>>  =3D3B
> >>> And as you point out=3D2C convenient literal > syntax.
> >>>  =3D3B
> >>>  =3D3B
> >>> People reasonably argue for library extension > in place of language = > >extensio=3D > >>> n=3D2C but that requires a language which is > flexible enough to write = > >librari=3D > >>> es with the desired interface=3D2C and so many > languages don't let = > >infix oper=3D > >>> ators be in a user-written library.
> >>> (There is a subtle but useless distinction > here -- infix operators = > >being in=3D > >>> libraries vs. "user-written" libraries. The > infix set operations for = > >examp=3D > >>> le are in a library=3D2C but not > user-written=3D2C special=3D2C the = > >compiler know=3D > >>> s about it.)
> >>>  =3D3B
> >>> >=3D3B that would perhaps not match how > C handles "long long" on = > >the same >>> R>>=3D3B platform (which is how=3D2C > come to think of it?)=3D2C and = > >that would =3D > >>> require

> >>>  =3D3B
> >>> On NT/x86=3D2C __int64/long long is returned > in the register pair = > >edx:eax. >>>>=20 > >>> edx is high=3D2C eax is low.
> >>> When passed as a parameter to __stdcall or > __cdecl is just passed as = > >two 32=3D > >>> bit values adjacent on the stack=3D2C "hi=3D2C > lo=3D2C hi=3D2C lo=3D2C = > >it's off to pu=3D > >>> sh we go" is the Snow White-influenced mantra > to remember how to pass = > >them=3D > >>> =3D2C at least on little endian > stack-growing-down machines (which = > >includes x=3D > >>> 86). For __fastcall I'm not sure they are > passed in registers or on = > >the sta=3D > >>> ck.
> >>> Passing and/or returning small structs also > has special efficient = > >handling =3D > >>> in the ABI=3D2C so __int64 really might be > equivalent to a small = > >record. Not =3D > >>> that cm3 necessarily implements that > "correctly" =3D3B -- for = > >interop wit=3D > >>> h C=3D3B for Modula-3 calling Modula-3 we can > make up our own ABI so = > >there is=3D > >>> n't =3D3Breally an "incorrect" > way. =3D3BNotice the mingw = > >problem I had=3D > >>> passing a Win32 point struct by value=3D2C I > cheated and passed it by = > >VAR to=3D > >>> a =3D3BC wrapper to workaround the gcc > backend bug (which was = > >mentioned =3D > >>> a few times and which I looked into the code > for=3D2C but took the = > >easy route=3D > >>> )
> >>>  =3D3B
> >>>  =3D3B
> >>> I don't know how long long works on other > platforms but probably = > >similar. >>> R> > >>> Probably a certain register pair for return > values.
> >>>  =3D3B
> >>>  =3D3B- > Jay

 =3D3B
>=3D3B > To: = > >hosking at cs.purdue.edu
>=3D3B=3D > >>> Date: Sat=3D2C 17 Apr 2010 19:47:03 > -0700
>=3D3B From: = > >mika at async.async.c=3D > >>> altech.edu
>=3D3B CC: m3devel at elegosoft.com
>=3D3B > Subject: = > >Re: [M3de=3D > >>> vel] INTEGER
>=3D3B >
>=3D3B Tony Hosking > writes:
>=3D3B = > >>=3D3B
=3D > >>> >=3D3B ...
>=3D3B > >=3D3B
>=3D3B >=3D3B>=3D3B > We = > >need it to match 64-b=3D > >>> it integers on 32-bit machines? That seems > =3D3D
>=3D3B = > >>=3D3Blike
>=3D > >>> =3D3B >=3D3B>=3D3B a very weak > rationale indeed=3D2C if the same = > >functionality =3D > >>> could be =3D3D
>=3D3B > >=3D3Bprovided
>=3D3B > >=3D3B>=3D3= > >B through some o=3D > >>> ther mechanism (e.g.=3D2C ARRAY [0..1] OF > INTEGER---even = > >=3D3D
>=3D3B >=3D3B=3D > >>> with
>=3D3B > >=3D3B>=3D3B a pragma e.g. = > ><=3D3B*CLONGLONG*>=3D3B.. if it i=3D > >>> s necessary to tell the compiler > =3D3D
>=3D3B = > >>=3D3Bthat
>=3D3B > >=3D3B&=3D > >>> gt=3D3B a special linkage convention is > needed).
>=3D3B = > >>=3D3B
>=3D3B &=3D > >>> gt=3D3BThere's no special linkage convention. > Not sure what you mean = > >here. >>>> >=3D3B > >=3D3B
>=3D3B
>=3D3B I > just mean if we = > >had
>=3D3B
>=3D > >>> =3D3B TYPE LONGINT =3D3D ARRAY [0..1] OF > INTEGER
>=3D3B = > >
>=3D3B that woul=3D > >>> d perhaps not match how C handles "long long" > on the same
>=3D3B = > >platfor=3D > >>> m (which is how=3D2C come to think of > it?)=3D2C and that would = > >require
>=3D > >>> =3D3B special linkage > tricks.
>=3D3B
>=3D3B But > what would = > >be lost? Th=3D > >>> e ability to type literals. >
>=3D3B
>=3D3B You could get > = > >the same co=3D > >>> de interface on 32- and 64-bit machine > by
>=3D3B = > >defining
>=3D3B
=3D > >>> >=3D3B TYPE FileOffset =3D3D ARRAY[0..1] > OF [-16_80000000 .. = > >+16_7fffffff ] >>> R>>=3D3B
>=3D3B and > using that.
>=3D3B
>=3D3B = > >
>=3D3B Mika >>>> > > > > >>> =3D > >>>=20 > >>> --_264cb69b-0215-44c3-807c-8b4d8ea0ea59_-- > From jay.krell at cornell.edu Mon Apr 19 06:43:54 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 19 Apr 2010 04:43:54 +0000 Subject: [M3devel] Posix < 0 vs. # 0 vs. = -1? In-Reply-To: References: , Message-ID: > much cheaper Ah. I hadn't considered that. It looks like we might gain commonality in socket code though by checking for a specific value. C:\dev2\cm3.2\m3-libs\m3core\src\win32\WinSock.i3(293): SOCKET_ERROR = -1; - Jay From: hosking at cs.purdue.edu Date: Sun, 18 Apr 2010 15:09:00 -0400 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] Posix < 0 vs. # 0 vs. = -1? Checking < 0 is much cheaper than checking = -1. C idioms typically check < 0. -1 is simply a convenient negative value to return. Leave it as is. On 18 Apr 2010, at 09:57, Jay K wrote: Posix often says: function foo() returns 0 for success, -1 for error m3core/libm3/etc, often say if foo() < 0 or if foo() # 0 "instead". Generally ok to tighten these up to "= -1", perhaps upon checking manpages, or a known rat's nest of inconsistencies? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Apr 19 08:54:09 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 19 Apr 2010 06:54:09 +0000 Subject: [M3devel] INTEGER In-Reply-To: <141192.73575.qm@web23603.mail.ird.yahoo.com> References: <20100418195901.CDACB1A20F6@async.async.caltech.edu>, <141192.73575.qm@web23603.mail.ird.yahoo.com> Message-ID: I believe the 128bit and 256bit types are implemented with compiler extensions but not language extensions. They declare records and "functions", but the compilers implement the "functions" inline (roughly one instruction each). This is akin to interface Word and generic interface Atomic. They are "just" libraries from a language point of view, but the compiler knows about them and inlines them. Well, at least the "packed" types. There are larger "scalar" types coming? That support infix operators? Again, so far as we have all figured out (I'm guessing and building on a hint Mika provided), it is mostly just about literals and infix notation. And if that is the case, it really shows that a language ought to be a bit more flexible in the first place (user defined infix operators on user defined types), and then it won't need as much extending later on. Nobody really prefers "Word.Plus(a, b)" over "a + b"... - Jay > Date: Mon, 19 Apr 2010 04:47:14 +0000 > From: dabenavidesd at yahoo.es > To: hosking at cs.purdue.edu; mika at async.async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] INTEGER > > Hi: > I think the irrelevant point is arguable as there are SIMD instructions of 128-bit and later will be 256-bit packed types registers so the point of becoming irrelevant could be worrisome in time, probably not now. As packed types weren't to traumatic but are more needed now by this fact. > If you wish more generality, a language change will be needed, not an extension, language extensions are easily doable with enough knowledge but right now you would need to do it or it will become harder and harder to reconstruct your own code. If you need backward compatibility why don't host cm3 with pm3, that is old cm3 can't compile cm3 but its negative inverse is true and it is old known old cm3 can build pm3 and src m3 (current cm3 built itself as I saw with RC5 on AMD64_LINUX). Still you want to host other older environments look for doing it with CM3, I think it wouldn't be so much traumatic, wouldn't it? You would compile and have two different runtime but you could do what you want to do, as I guess you were doing for other reasons and it wouldn't be so much effort to do it, maybe the ugly parts would be system dependent things as I think. > I think there are many other options as to be backwards compatible like drop new features or build against other specific libraries, but again is not that the purpose you are looking for, then is simpler if you think the above intention in some sense to you? > It's just an idea, hope it helps something. > > --- El dom, 18/4/10, Mika Nystrom escribi?: > > > De: Mika Nystrom > > Asunto: Re: [M3devel] INTEGER > > Para: "Tony Hosking" > > CC: m3devel at elegosoft.com > > Fecha: domingo, 18 de abril, 2010 14:59 > > > > My problem is really just that it's ugly. LONGx is > > showing up as an issue > > in all sorts of low-level code, which is not surprising > > since Modula-3 > > with LONGx is not the same language as Modula-3 (maybe we > > should call > > it Modula-3+?) > > > > The compiler bootstrapping process has gotten more > > complicated due to it, > > and when I cvs updated m3tk yesterday stubgen wouldn't > > compile because there > > was something "long" in it that wasn't there before. > > I have no idea what > > library or components I needed to update and recompile and > > didn't have the > > time to deal with the issue at the time. > > > > And the new m3tk, stubgen, and compiler(?) won't compile > > using PM3 or > > SRC M3 since we're no longer using the language of the > > Green Book. > > (Same comment goes for WIDECHAR, by the way.) > > > > One of the wonderful things about Modula-3 *used to be* > > that I could > > grab some old package from DECSRC and just use it without > > changes since > > no one had messed with the language definition. This > > is still true as > > far as programs that just use the tools go, but it's no > > longer true for > > programs that process Modula-3 code as input data. Of > > which there are > > more than a few: many aspects of Modula-3 were specifically > > designed to > > make the language easy to process by program, as an > > intermediate format > > and whatnot. > > > > To quote E.W.D.: > > > > 'Unfathomed misunderstanding is further revealed by the > > term "software > > maintenance", as a result of which many people continue to > > believe that > > programs and even programming languages themselves are > > subject to wear > > and tear. Your car needs maintenance too, doesn't it? > > Famous is the story > > of the oil company that believed that its PASCAL programs > > did not last > > as long as its FORTRAN programs "because PASCAL was not > > maintained".' > > > > LONGx is causing me to have to do "software maintenance" on > > Modula-3 > > programs... for a feature that no one appears to be using > > and is quickly > > becoming irrelevant. > > > > Mika > > > > > > Tony Hosking writes: > > >In the language spec NUMBER(a) and LAST(a) - FIRST(a) + > > 1 are *not* = > > >defined to mean the same thing for all types. > > >NUMBER does have an INTEGER value, as expected for > > subranges of LONGINT = > > >that are not too large. > > >This is as it has always been for subranges of INTEGER > > that are not too = > > >large. > > > > > >Mika, I'm not sure I see any of the problems you are > > worrying about in = > > >the current definition of LONGINT/LONGCARD. > > > > > >On 18 Apr 2010, at 03:49, Mika Nystrom wrote: > > > > > >>=20 > > >> Jay I know most of this, and it doesn't really > > answer the question > > >> "what is it for?" > > >>=20 > > >> I think we've already established that LONGINT > > isn't useful for = > > >counting > > >> anything that might actually reside in the > > computer's memory: it makes > > >> no sense as an array index, for instance. > > INTEGER suffices for that. > > >>=20 > > >> I thought that the only real reason for LONGINT > > was to match C's > > >> declaration of various seek-related routines on > > 32-bit machines. > > >> That's not a very good reason. > > >>=20 > > >> C++ succeeds because it does very well in the > > area(s) it is good at. > > >> People who want to program in C++ will clearly > > program in C++, not > > >> Modula-3. Modula-3 is never, ever going to > > be the language of choice = > > >for > > >> people who want lots of snazzy infix > > operators. Modula-3 is supposed = > > >to > > >> be a language with about as powerful semantics as > > C++ and an extremely > > >> simple syntax and definition---snazzy infix is one > > of the things you > > >> give up for that. I don't see how LONGINT > > fits into this picture. > > >> Now we have LONGCARD too? And it's infected > > the definitions > > >> of FIRST and LAST? But not NUMBER... argh! > > >>=20 > > >> so, > > >>=20 > > >> NUMBER(a) and LAST(a) - FIRST(a) + 1 > > >>=20 > > >> no longer mean the same thing? Are we going > > to see lots of comments > > >> in generics in the future where it says T may not > > be an open array > > >> type nor an array type indexed on LONGINT or a > > subrange thereof? > > >>=20 > > >> Your comments about different parameter-passing > > techniques was what I = > > >was > > >> trying to address with my suggestion to have a > > pragma for this---just = > > >to > > >> match C (and Fortran?), of course. Name me a > > single Modula-3 = > > >programmer > > >> who cares in what order the bits in his parameters > > are pushed on the > > >> stack in a Modula-3-to-Modula-3 call. > > >>=20 > > >> And I am definitely in that school of thought that > > says that = > > >programming > > >> languages should not "evolve". Better to > > leave well enough alone. > > >>=20 > > >> How much Modula-3 code has been written that uses > > LONGINT? Other than > > >> to talk to C? I've certainly never used it. > > >>=20 > > >> Mika > > >>=20 > > >>=20 > > >>=20 > > >> Jay K writes: > > >>> --_264cb69b-0215-44c3-807c-8b4d8ea0ea59_ > > >>> Content-Type: text/plain; > > charset=3D"iso-8859-1" > > >>> Content-Transfer-Encoding: quoted-printable > > >>>=20 > > >>>=20 > > >>> TYPE LONGINT =3D3D ARRAY [0..1] OF INTEGER on > > a 32bit system is very = > > >close to=3D > > >>> LONGINT. > > >>>=20 > > >>> Plus treating it opaquely and providing a > > bunch of functions to = > > >operate on=3D > > >>> it. > > >>>=20 > > >>> Just as well therefore could be RECORD > > hi=3D2Clo:LONGINT END (see = > > >LARGE_INTE=3D > > >>> GER and ULARGE_INTEGER in winnt.h) > > >>>=20 > > >>> =3D20 > > >>>=20 > > >>> Differences that come to mind: > > >>>=20 > > >>> infix operators > > <=3D3D=3D3D=3D3D=3D20 > > >>>=20 > > >>> possibly passed differently as a parameter > > >>>=20 > > >>> or returned differently as a result > > >>>=20 > > >>> ie. probably "directly compatible with" "long > > long"=3D2C passed by = > > >value (o=3D > > >>> f course you could always pass by pointer and > > achieve compatibilitity = > > >trivi=3D > > >>> ally) > > >>>=20 > > >>> =3D20 > > >>>=20 > > >>> =3D20 > > >>>=20 > > >>> I have to say though=3D2C the biggest reason > > is in-fix operators. = > > >Convenient =3D > > >>> syntax. > > >>>=20 > > >>> C++ is the best and some way worst of example > > of the general right = > > >way to d=3D > > >>> o this -- you let programmers define types and > > their infix operators. = > > >Other=3D > > >>> languages just come with a passle of special > > cases of types that have = > > >in-f=3D > > >>> ix operators. > > >>>=20 > > >>> A good example is that Java infix operator + > > on string=3D2C besides = > > >the vario=3D > > >>> us integers=3D2C and nothing else. > > >>>=20 > > >>> =3D20 > > >>>=20 > > >>> =3D20 > > >>>=20 > > >>> I think C# lets you define operators=3D2C yet > > people don't complain = > > >that it i=3D > > >>> s "a mess" as they do of C++. > > >>>=20 > > >>> I think Python does now too. > > >>>=20 > > >>> So it is feature growing in popularity among > > "mainstream" = > > >languages=3D2C not =3D > > >>> just C++. > > >>>=20 > > >>> C++ of course is extremely > > mainstream=3D2C but also a favorite = > > >target. (ht=3D > > >>> tp://www.relisoft.com/tools/CppCritic.html) > > >>>=20 > > >>> =3D20 > > >>>=20 > > >>> =3D20 > > >>>=20 > > >>> We also have subranges of LONGINT. > > >>>=20 > > >>> I'm not sure what the generalization of > > subranges are=3D2C granted. > > >>>=20 > > >>> Maybe some sort of C++ template that takes > > constants in the template = > > >and d=3D > > >>> oes range checks at runtime. Yeah=3D2C maybe. > > >>>=20 > > >>> =3D20 > > >>>=20 > > >>> =3D20 > > >>>=20 > > >>> And as you point out=3D2C convenient literal > > syntax. > > >>>=20 > > >>> =3D20 > > >>>=20 > > >>> =3D20 > > >>>=20 > > >>> People reasonably argue for library extension > > in place of language = > > >extensio=3D > > >>> n=3D2C but that requires a language which is > > flexible enough to write = > > >librari=3D > > >>> es with the desired interface=3D2C and so many > > languages don't let = > > >infix oper=3D > > >>> ators be in a user-written library. > > >>>=20 > > >>> (There is a subtle but useless distinction > > here -- infix operators = > > >being in=3D > > >>> libraries vs. "user-written" libraries. The > > infix set operations for = > > >examp=3D > > >>> le are in a library=3D2C but not > > user-written=3D2C special=3D2C the = > > >compiler know=3D > > >>> s about it.) > > >>>=20 > > >>> =3D20 > > >>>=20 > > >>>> that would perhaps not match how C handles > > "long long" on the same > > >>>> platform (which is how=3D2C come to think > > of it?)=3D2C and that = > > >would require > > >>>=20 > > >>>=20 > > >>> =3D20 > > >>>=20 > > >>> On NT/x86=3D2C __int64/long long is returned > > in the register pair = > > >edx:eax. > > >>>=20 > > >>> edx is high=3D2C eax is low. > > >>>=20 > > >>> When passed as a parameter to __stdcall or > > __cdecl is just passed as = > > >two 32=3D > > >>> bit values adjacent on the stack=3D2C "hi=3D2C > > lo=3D2C hi=3D2C lo=3D2C = > > >it's off to pu=3D > > >> sh we go" is the Snow White-influenced mantra to > > remember how to pass = > > >them=3D > > >>> =3D2C at least on little endian > > stack-growing-down machines (which = > > >includes x=3D > > >>> 86). For __fastcall I'm not sure they are > > passed in registers or on = > > >the sta=3D > > >>> ck. > > >>>=20 > > >>> Passing and/or returning small structs also > > has special efficient = > > >handling =3D > > >>> in the ABI=3D2C so __int64 really might be > > equivalent to a small = > > >record. Not =3D > > >>> that cm3 necessarily implements that > > "correctly" -- for interop with = > > >C=3D3B =3D > > >>> for Modula-3 calling Modula-3 we can make up > > our own ABI so there = > > >isn't rea=3D > > >>> lly an "incorrect" way. Notice the mingw > > problem I had passing a = > > >Win32 poin=3D > > >>> t struct by value=3D2C I cheated and passed it > > by VAR to a C wrapper = > > >to worka=3D > > >>> round the gcc backend bug (which was mentioned > > a few times and which = > > >I look=3D > > >>> ed into the code for=3D2C but took the easy > > route) > > >>>=20 > > >>> =3D20 > > >>>=20 > > >>> =3D20 > > >>>=20 > > >>> I don't know how long long works on other > > platforms but probably = > > >similar. > > >>>=20 > > >>> Probably a certain register pair for return > > values. > > >>>=20 > > >>> =3D20 > > >>>=20 > > >>> - Jay > > >>>=20 > > >>> =3D20 > > >>>> To: hosking at cs.purdue.edu > > >>>> Date: Sat=3D2C 17 Apr 2010 19:47:03 -0700 > > >>>> From: mika at async.async.caltech.edu > > >>>> CC: m3devel at elegosoft.com > > >>>> Subject: Re: [M3devel] INTEGER > > >>>> =3D20 > > >>>> Tony Hosking writes: > > >>>>>=20 > > >>>> ... > > >>>>>=20 > > >>>>>> We need it to match 64-bit > > integers on 32-bit machines? That seems = > > >=3D3D > > >>>>> like > > >>>>>> a very weak rationale indeed=3D2C > > if the same functionality could = > > >be =3D3D > > >>>>> provided > > >>>>>> through some other mechanism > > (e.g.=3D2C ARRAY [0..1] OF = > > >INTEGER---even =3D > > >>> =3D3D > > >>>>> with > > >>>>>> a pragma e.g. > > <*CLONGLONG*>.. if it is necessary to tell the = > > >compiler =3D > > >>> =3D3D > > >>>>> that > > >>>>>> a special linkage convention is > > needed). > > >>>>>=20 > > >>>>> There's no special linkage convention. > > Not sure what you mean here. > > >>>>>=20 > > >>>> =3D20 > > >>>> I just mean if we had > > >>>> =3D20 > > >>>> TYPE LONGINT =3D3D ARRAY [0..1] OF > > INTEGER > > >>>> =3D20 > > >>>> that would perhaps not match how C handles > > "long long" on the same > > >>>> platform (which is how=3D2C come to think > > of it?)=3D2C and that = > > >would require > > >>>> special linkage tricks. > > >>>> =3D20 > > >>>> But what would be lost? The ability to > > type literals.=3D20 > > >>>> =3D20 > > >>>> You could get the same code interface on > > 32- and 64-bit machine by > > >>>> defining > > >>>> =3D20 > > >>>> TYPE FileOffset =3D3D ARRAY[0..1] OF > > [-16_80000000 .. +16_7fffffff ] > > >>>> =3D20 > > >>>> and using that. > > >>>> =3D20 > > >>>> =3D20 > > >>>> Mika > > >>> > > > > > > =3D > > >>>=20 > > >>> --_264cb69b-0215-44c3-807c-8b4d8ea0ea59_ > > >>> Content-Type: text/html; > > charset=3D"iso-8859-1" > > >>> Content-Transfer-Encoding: quoted-printable > > >>>=20 > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> TYPE LONGINT =3D3D ARRAY [0..1] OF INTEGER on > > a =3D3B32bit system = > > >is very c=3D > > >>> lose to LONGINT.
> > >>>  =3D3BPlus treating it opaquely and > > providing a bunch of = > > >functions to ope=3D > > >>> rate on it.
> > >>>  =3D3BJust as well therefore could be > > RECORD hi=3D2Clo:LONGINT = > > >END (see LAR=3D > > >>> GE_INTEGER and ULARGE_INTEGER in > > winnt.h)
> > >>>  =3D3B
> > >>> Differences that come to mind:
> > >>>  =3D3B =3D3Binfix > > operators =3D3B <=3D3B=3D3D=3D3D=3D3D = > > >
> > >>>  =3D3B possibly passed > > differently =3D3Bas a parameter
> > >>>  =3D3B or returned differently as a > > result
> > >>>  =3D3B ie. probably "directly > > compatible with" "long long"=3D2C = > > >passed by v=3D > > >>> alue (of course you could always pass by > > pointer and achieve = > > >compatibilitit=3D > > >>> y trivially)
> > >>>  =3D3B
> > >>>  =3D3B
> > >>> I have to say though=3D2C the biggest reason > > is in-fix operators. = > > >Convenient =3D > > >>> syntax.
> > >>> C++ is the best and some way worst of example > > of the general right = > > >way to d=3D > > >>> o this -- you let programmers define types and > > their infix operators. = > > >Other=3D > > >>> languages just come with a passle of special > > cases of types that have = > > >in-f=3D > > >>> ix operators.
> > >>> A good example is that Java infix operator + > > on string=3D2C besides = > > >the vario=3D > > >>> us integers=3D2C and nothing else.
> > >>>  =3D3B
> > >>>  =3D3B
> > >>> I think C# lets you define operators=3D2C yet > > people don't complain = > > >that it i=3D > > >>> s "a mess" as they do of C++.
> > >>> I think Python does now too.
> > >>> So it is feature growing in popularity among > > "mainstream" = > > >languages=3D2C not =3D > > >>> just C++.
> > >>>  =3D3B =3D3B C++ of course is > > extremely mainstream=3D2C but = > > >also a favori=3D > > >>> te target. ( > >href=3D3D"http://www.relisoft.com/tools/CppCritic.html">http:/=3D > > >>> > > /www.relisoft.com/tools/CppCritic.html)
> > >>>  =3D3B
> > >>>  =3D3B
> > >>> We also have subranges of LONGINT.
> > >>> I'm not sure what the generalization of > > subranges are=3D2C = > > >granted.
> > >>>  =3D3BMaybe some sort of C++ template > > that takes constants in the = > > >templat=3D > > >>> e and does range checks at runtime. Yeah=3D2C > > maybe.
> > >>>  =3D3B
> > >>>  =3D3B
> > >>> And as you point out=3D2C convenient literal > > syntax.
> > >>>  =3D3B
> > >>>  =3D3B
> > >>> People reasonably argue for library extension > > in place of language = > > >extensio=3D > > >>> n=3D2C but that requires a language which is > > flexible enough to write = > > >librari=3D > > >>> es with the desired interface=3D2C and so many > > languages don't let = > > >infix oper=3D > > >>> ators be in a user-written library.
> > >>> (There is a subtle but useless distinction > > here -- infix operators = > > >being in=3D > > >>> libraries vs. "user-written" libraries. The > > infix set operations for = > > >examp=3D > > >>> le are in a library=3D2C but not > > user-written=3D2C special=3D2C the = > > >compiler know=3D > > >>> s about it.)
> > >>>  =3D3B
> > >>> >=3D3B that would perhaps not match how > > C handles "long long" on = > > >the same > >>> R>>=3D3B platform (which is how=3D2C > > come to think of it?)=3D2C and = > > >that would =3D > > >>> require

> > >>>  =3D3B
> > >>> On NT/x86=3D2C __int64/long long is returned > > in the register pair = > > >edx:eax. > >>>>=20 > > >>> edx is high=3D2C eax is low.
> > >>> When passed as a parameter to __stdcall or > > __cdecl is just passed as = > > >two 32=3D > > >>> bit values adjacent on the stack=3D2C "hi=3D2C > > lo=3D2C hi=3D2C lo=3D2C = > > >it's off to pu=3D > > >>> sh we go" is the Snow White-influenced mantra > > to remember how to pass = > > >them=3D > > >>> =3D2C at least on little endian > > stack-growing-down machines (which = > > >includes x=3D > > >>> 86). For __fastcall I'm not sure they are > > passed in registers or on = > > >the sta=3D > > >>> ck.
> > >>> Passing and/or returning small structs also > > has special efficient = > > >handling =3D > > >>> in the ABI=3D2C so __int64 really might be > > equivalent to a small = > > >record. Not =3D > > >>> that cm3 necessarily implements that > > "correctly" =3D3B -- for = > > >interop wit=3D > > >>> h C=3D3B for Modula-3 calling Modula-3 we can > > make up our own ABI so = > > >there is=3D > > >>> n't =3D3Breally an "incorrect" > > way. =3D3BNotice the mingw = > > >problem I had=3D > > >>> passing a Win32 point struct by value=3D2C I > > cheated and passed it by = > > >VAR to=3D > > >>> a =3D3BC wrapper to workaround the gcc > > backend bug (which was = > > >mentioned =3D > > >>> a few times and which I looked into the code > > for=3D2C but took the = > > >easy route=3D > > >>> )
> > >>>  =3D3B
> > >>>  =3D3B
> > >>> I don't know how long long works on other > > platforms but probably = > > >similar. > >>> R> > > >>> Probably a certain register pair for return > > values.
> > >>>  =3D3B
> > >>>  =3D3B- > > Jay

 =3D3B
>=3D3B > > To: = > > >hosking at cs.purdue.edu
>=3D3B=3D > > >>> Date: Sat=3D2C 17 Apr 2010 19:47:03 > > -0700
>=3D3B From: = > > >mika at async.async.c=3D > > >>> altech.edu
>=3D3B CC: m3devel at elegosoft.com
>=3D3B > > Subject: = > > >Re: [M3de=3D > > >>> vel] INTEGER
>=3D3B > >
>=3D3B Tony Hosking > > writes:
>=3D3B = > > >>=3D3B
=3D > > >>> >=3D3B ...
>=3D3B > > >=3D3B
>=3D3B >=3D3B>=3D3B > > We = > > >need it to match 64-b=3D > > >>> it integers on 32-bit machines? That seems > > =3D3D
>=3D3B = > > >>=3D3Blike
>=3D > > >>> =3D3B >=3D3B>=3D3B a very weak > > rationale indeed=3D2C if the same = > > >functionality =3D > > >>> could be =3D3D
>=3D3B > > >=3D3Bprovided
>=3D3B > > >=3D3B>=3D3= > > >B through some o=3D > > >>> ther mechanism (e.g.=3D2C ARRAY [0..1] OF > > INTEGER---even = > > >=3D3D
>=3D3B >=3D3B=3D > > >>> with
>=3D3B > > >=3D3B>=3D3B a pragma e.g. = > > ><=3D3B*CLONGLONG*>=3D3B.. if it i=3D > > >>> s necessary to tell the compiler > > =3D3D
>=3D3B = > > >>=3D3Bthat
>=3D3B > > >=3D3B&=3D > > >>> gt=3D3B a special linkage convention is > > needed).
>=3D3B = > > >>=3D3B
>=3D3B &=3D > > >>> gt=3D3BThere's no special linkage convention. > > Not sure what you mean = > > >here. > >>>> >=3D3B > > >=3D3B
>=3D3B
>=3D3B I > > just mean if we = > > >had
>=3D3B
>=3D > > >>> =3D3B TYPE LONGINT =3D3D ARRAY [0..1] OF > > INTEGER
>=3D3B = > > >
>=3D3B that woul=3D > > >>> d perhaps not match how C handles "long long" > > on the same
>=3D3B = > > >platfor=3D > > >>> m (which is how=3D2C come to think of > > it?)=3D2C and that would = > > >require
>=3D > > >>> =3D3B special linkage > > tricks.
>=3D3B
>=3D3B But > > what would = > > >be lost? Th=3D > > >>> e ability to type literals. > >
>=3D3B
>=3D3B You could get > > = > > >the same co=3D > > >>> de interface on 32- and 64-bit machine > > by
>=3D3B = > > >defining
>=3D3B
=3D > > >>> >=3D3B TYPE FileOffset =3D3D ARRAY[0..1] > > OF [-16_80000000 .. = > > >+16_7fffffff ] > >>> R>>=3D3B
>=3D3B and > > using that.
>=3D3B
>=3D3B = > > >
>=3D3B Mika > >>>> > > > > > > > > >>> =3D > > >>>=20 > > >>> --_264cb69b-0215-44c3-807c-8b4d8ea0ea59_-- > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Apr 19 12:20:45 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 19 Apr 2010 10:20:45 +0000 Subject: [M3devel] "post rc5" Message-ID: "post" archives appear on the main page. I'll try again to build AMD64/I386_DARWIN just via Hudson. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Apr 19 13:48:02 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 19 Apr 2010 13:48:02 +0200 Subject: [M3devel] hudson on birch down again Message-ID: <20100419134802.vxcfp982s0k4sgsc@mail.elegosoft.com> Can you please have a look and fix that? 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 kay.haeusler at elego.de Mon Apr 19 13:58:21 2010 From: kay.haeusler at elego.de (Kay =?UTF-8?B?SMOkdXNsZXI=?=) Date: Mon, 19 Apr 2010 13:58:21 +0200 Subject: [M3devel] hudson on birch down again In-Reply-To: <20100419134802.vxcfp982s0k4sgsc@mail.elegosoft.com> References: <20100419134802.vxcfp982s0k4sgsc@mail.elegosoft.com> Message-ID: <20100419135821.266c5b2e@pine.elego.de> Hallo Olaf, Olaf Wagner wrote: > Can you please have a look and fix that? I've restarted hudson. -- Mit freundlichen Gr??en Kay H?usler mailto:kay.haeusler at elego.de elego Software Solutions GmbH http://www.elego.de Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 13355 Berlin, Germany Amtsgericht Charlottenburg Tel.: +49 30 23458696 Sitz der Gesellschaft: Berlin Fax: +49 30 23458695 Gesch?ftsf?hrer: Olaf Wagner From jay.krell at cornell.edu Mon Apr 19 14:10:41 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 19 Apr 2010 12:10:41 +0000 Subject: [M3devel] SchedulerPosix/Win32/sockets Message-ID: short story: I think we should have SchedulerPosix.IOWait and SchedulerPosix.IOAlertWait, but not SchedulerPosix.WaitProces, on Win32. With the CARDINAL changed back to INTEGER. As well, as before, I'd like to only have one implementation of this. Currently there are two identical copies, due to Cygwin. But this proposal is for regular Win32. long story: Win32 has select, for sockets. Instead of a bitset, it uses an array of 64, so doesn't have the problem that poll fixes. SocketPosix.m3 makes sockets non-blocking and uses IOWait and IOAlertWait. SocketPosix.Connect/Accept are alertable. SocketWin32.Connect/Accept are not alertable. That seems wrong, eh? I assume this difference is due to original implementers not realizing their options on Win32. I assume this difference would be good to remove. IOWait is merely a call to select (assuming kernel threads). In rewritten-in-C, I can easily just #ifdef and call select on Win32. IOAlertWait is implemented by polling via select/poll for up to a maximum of a second at a time, testing alert between each. It is this code that I don't think should be duplicated. We already have two copies of it due to Cygwin. (I think we might be able to do better on Win32 though, by using Win32 alerting as part of Modula-3 alerting, but for the time being, sharing code with Posix that polls every second would be ok.) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Apr 19 14:11:52 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 19 Apr 2010 12:11:52 +0000 Subject: [M3devel] SchedulerPosix/Win32/sockets Message-ID: short story: I think we should have SchedulerPosix.IOWait and SchedulerPosix.IOAlertWait, but not SchedulerPosix.WaitProces, on Win32. With the CARDINAL changed back to INTEGER. As well, as before, I'd like to only have one implementation of this. Currently there are two identical copies, due to Cygwin. But this proposal is for regular Win32. long story: Win32 has select, for sockets. Instead of a bitset, it uses an array of 64, so doesn't have the problem that poll fixes. SocketPosix.m3 makes sockets non-blocking and uses IOWait and IOAlertWait. SocketPosix.Connect/Accept are alertable. SocketWin32.Connect/Accept are not alertable. That seems wrong, eh? I assume this difference is due to original implementers not realizing their options on Win32. I assume this difference would be good to remove. IOWait is merely a call to select (assuming kernel threads). In rewritten-in-C, I can easily just #ifdef and call select on Win32. IOAlertWait is implemented by polling via select/poll for up to a maximum of a second at a time, testing alert between each. It is this code that I don't think should be duplicated. We already have two copies of it due to Cygwin. (I think we might be able to do better on Win32 though, by using Win32 alerting as part of Modula-3 alerting, but for the time being, sharing code with Posix that polls every second would be ok.) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Apr 19 16:03:16 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 19 Apr 2010 14:03:16 +0000 Subject: [M3devel] deleting most of m3core/src/unix? Message-ID: I went ahead and did this. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Subject: deleting most of m3core/src/unix? Date: Thu, 15 Apr 2010 14:43:23 +0000 Ok..maybe now time to delete all of m3core/src/unix except for uin-*, Common, and part of solaris-2-x? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Apr 19 16:04:39 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 19 Apr 2010 14:04:39 +0000 Subject: [M3devel] JVideo/struct_timeval? Message-ID: I went ahead and put in a local type. Utime.struct_timeval is now gone. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Subject: JVideo/struct_timeval? Date: Mon, 12 Apr 2010 13:03:26 +0000 This seems wierd: C:\dev2\cm3.2\m3-ui\jvideo\src\POSIX\jvprotocol.i3(193): timestamp: Utime.struct_timeval; I think they are defining a wire protocol, but embedding platform-specific types in it. How about I just change to Time.T? (64bit floating point, seconds since 1970). We could do like: C:\dev2\cm3.2\m3-ui\jvideo\src\POSIX\decunix\JVSink.m3(440): jvb.timestamp.tv_sec := signed_ntohl(hdr.timestamp.tv_sec); and define it to be transferred as a network order 64bit integer (big endian LONGINT), or maybe an array of 8 bytes. Or maybe define a local struct_timeval separate from Utime that hardcodes the sizes..and maybe using LONGINT? 32bit time_t is apparently still very common, though it seems obviously a big mistake.. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Apr 19 16:15:06 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 19 Apr 2010 16:15:06 +0200 Subject: [M3devel] giant lock in SocketWin32.m3? In-Reply-To: References: <20100418140821.428882474008@birch.elegosoft.com> Message-ID: <20100419161506.w9l7qydxc08sggwk@mail.elegosoft.com> Quoting Jay K : > > Anyone know why SocketWin32.m3 has had a giant lock around everything? > > I see no point to it. > > The only global variable is related to on-demand initialization. > > And even that wasn't handled correctly.. Perhaps the network stack on Windows95/98 wasn't really reentrant? Just a guess though. The code is quite old as far as I know. 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 jay.krell at cornell.edu Mon Apr 19 17:31:33 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 19 Apr 2010 15:31:33 +0000 Subject: [M3devel] giant lock in SocketWin32.m3? In-Reply-To: <20100419161506.w9l7qydxc08sggwk@mail.elegosoft.com> References: <20100418140821.428882474008@birch.elegosoft.com>, , <20100419161506.w9l7qydxc08sggwk@mail.elegosoft.com> Message-ID: > Perhaps the network stack on Windows95/98 wasn't really reentrant? No. Your expectations are much too low. Imagine if this was true. Then all Windows networking code would have its own giant locks, and you'd read about this in documentation and such. I'm not sure of the terminology, but: "Reentrant" is a strong word. "Thread safe" is a weaker more common one. For example strtok is not reentrant, but typically thread safe, through use of "thread locals". You can't use strtok in a nested for loop though. It's not that the code is old per se. I think a lot of it was slapped together quickly and then not really reviewed or tested much, and doesn't get much use either. I constantly see incorrect on-demand initialization as well. This code had it as well. - Jay > Date: Mon, 19 Apr 2010 16:15:06 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] giant lock in SocketWin32.m3? > > Quoting Jay K : > > > > > Anyone know why SocketWin32.m3 has had a giant lock around everything? > > > > I see no point to it. > > > > The only global variable is related to on-demand initialization. > > > > And even that wasn't handled correctly.. > > Perhaps the network stack on Windows95/98 wasn't really reentrant? > > Just a guess though. The code is quite old as far as I know. > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.async.caltech.edu Mon Apr 19 19:23:13 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Mon, 19 Apr 2010 10:23:13 -0700 Subject: [M3devel] INTEGER In-Reply-To: References: , , , <7C7408D0-9A40-4988-BADA-A9FD8C15D388@cs.purdue.edu>, , , , , , , <20100418023535.3BA9E1A2103@async.async.caltech.edu>, , <20100418024703.6965B1A2103@async.async.caltech.edu> <20100418074927.934461A2117@async.async.caltech.edu> <04EB7FF8-D304-428D-839E-233FCE009C98@cs.purdue.edu> <20100418195901.CDACB1A20F6@async.async.caltech.edu> Message-ID: <20100419172313.68B241A20D6@async.async.caltech.edu> Well *my* problem is that I still use PM3 for a lot of things. Trying to switch to CM3, yes, but I can't "certify" CM3 for critical stuff yet. So I'm maintaining a significant amount of code that needs to compile under both PM3 and CM3. Two problems crop up. 1. If there are bugs in m3tk/stubgen, the fixes only apply to one or the other version of m3tk/stubgen. 2. Some of the code I'm maintaining processes Modula-3 code as input. It needs to be in two versions. In this kind of environment, programming languages don't really evolve, since the system depends on their being both forward- and backward-compatible. They "change" is more correct. The way Java changes. More in general, though, Modula-3's designers were clearly well acquainted with C, Fortran, and other languages that provide different-range integers. They chose not to indulge. I even have a version of Modula-3 for a 16-bit machine that doesn't do it, even though on this machine the need for a 32-bit integer is arguably greater than the need for 64-bit integers on 32-bit machines. Now we indulge in this language complication to solve what is clearly a temporary problem, since anyone who cares about large problems is going to have 64-bit systems yesterday... and meanwhile no one seems to have availed himself of the solution! My worst fear is that once the process gets started, the reason for staying with the original Green-Book specification has now been defeated and we will see more and more "evolution". Trying to actually build systems that process Modula-3 like data becomes, at that point, like trying to stand in quicksand. I'm not incredibly picky here... I just hope it doesn't go further. I would personally support either sticking with the current status quo or going back to the Green Book w.r.t. integers and characters. Saying that EWD wasn't renowned for his practicality is something he would have taken as a great compliment, I'm sure. Mika Tony Hosking writes: >Mika, > >First off, I'd be very interested to know what the issues are with = >LONGINT and stubgen. We are building that every day in regression = >testing. It would be really good to get some precise feedback. > >True, LONGINT is integrated with all of the language tools (same as = >WIDECHAR). > >I suppose that is the price we pay for the language having evolved. = >Nevertheless, CM3 should be totally backward compatible with the green = >book. There is no reason it should not build packages from PM3 or SRC. > >Now, this is not to say that perhaps we haven't overreached with LONGINT = >given that 64-bit is more prevalent. But then it is also useful to be = >able to interoperate with C libraries. The previous interfacing was = >pretty much a kludge, using ARRAY[0..1] OF INTEGER for "long long" but = >then not propagating the double INTEGER value properly throughout the = >Modula-3 libraries. > >I'm sorry to say that EWD was not particularly renowned for his = >practicality; pedant more like. Nice to be high and mighty but we also = >need to interact with the real world. > >We should be able to make this work. Is there a better alternative? = >Revoke LONGINT, and WIDECHAR? > >On 18 Apr 2010, at 15:59, Mika Nystrom wrote: > >>=20 >> My problem is really just that it's ugly. LONGx is showing up as an = >issue >> in all sorts of low-level code, which is not surprising since Modula-3 >> with LONGx is not the same language as Modula-3 (maybe we should call >> it Modula-3+?)=20 >>=20 >> The compiler bootstrapping process has gotten more complicated due to = >it, >> and when I cvs updated m3tk yesterday stubgen wouldn't compile because = >there >> was something "long" in it that wasn't there before. I have no idea = >what >> library or components I needed to update and recompile and didn't have = >the >> time to deal with the issue at the time. >>=20 >> And the new m3tk, stubgen, and compiler(?) won't compile using PM3 or >> SRC M3 since we're no longer using the language of the Green Book. >> (Same comment goes for WIDECHAR, by the way.) >>=20 >> One of the wonderful things about Modula-3 *used to be* that I could >> grab some old package from DECSRC and just use it without changes = >since >> no one had messed with the language definition. This is still true as >> far as programs that just use the tools go, but it's no longer true = >for >> programs that process Modula-3 code as input data. Of which there are >> more than a few: many aspects of Modula-3 were specifically designed = >to >> make the language easy to process by program, as an intermediate = >format >> and whatnot. >>=20 >> To quote E.W.D.: >>=20 >> 'Unfathomed misunderstanding is further revealed by the term "software >> maintenance", as a result of which many people continue to believe = >that >> programs and even programming languages themselves are subject to wear >> and tear. Your car needs maintenance too, doesn't it? Famous is the = >story >> of the oil company that believed that its PASCAL programs did not last >> as long as its FORTRAN programs "because PASCAL was not maintained".' >>=20 >> LONGx is causing me to have to do "software maintenance" on Modula-3 >> programs... for a feature that no one appears to be using and is = >quickly >> becoming irrelevant. >>=20 >> Mika >>=20 >>=20 >> Tony Hosking writes: >>> In the language spec NUMBER(a) and LAST(a) - FIRST(a) + 1 are *not* =3D= > >>> defined to mean the same thing for all types. >>> NUMBER does have an INTEGER value, as expected for subranges of = >LONGINT =3D >>> that are not too large. >>> This is as it has always been for subranges of INTEGER that are not = >too =3D >>> large. >>>=20 >>> Mika, I'm not sure I see any of the problems you are worrying about = >in =3D >>> the current definition of LONGINT/LONGCARD. >>>=20 >>> On 18 Apr 2010, at 03:49, Mika Nystrom wrote: >>>=20 >>>> =3D20 >>>> Jay I know most of this, and it doesn't really answer the question >>>> "what is it for?" >>>> =3D20 >>>> I think we've already established that LONGINT isn't useful for =3D >>> counting >>>> anything that might actually reside in the computer's memory: it = >makes >>>> no sense as an array index, for instance. INTEGER suffices for = >that. >>>> =3D20 >>>> I thought that the only real reason for LONGINT was to match C's >>>> declaration of various seek-related routines on 32-bit machines. >>>> That's not a very good reason. >>>> =3D20 >>>> C++ succeeds because it does very well in the area(s) it is good at. >>>> People who want to program in C++ will clearly program in C++, not >>>> Modula-3. Modula-3 is never, ever going to be the language of = >choice =3D >>> for >>>> people who want lots of snazzy infix operators. Modula-3 is = >supposed =3D >>> to >>>> be a language with about as powerful semantics as C++ and an = >extremely >>>> simple syntax and definition---snazzy infix is one of the things you >>>> give up for that. I don't see how LONGINT fits into this picture. >>>> Now we have LONGCARD too? And it's infected the definitions >>>> of FIRST and LAST? But not NUMBER... argh! >>>> =3D20 >>>> so, >>>> =3D20 >>>> NUMBER(a) and LAST(a) - FIRST(a) + 1 >>>> =3D20 >>>> no longer mean the same thing? Are we going to see lots of comments >>>> in generics in the future where it says T may not be an open array >>>> type nor an array type indexed on LONGINT or a subrange thereof? >>>> =3D20 >>>> Your comments about different parameter-passing techniques was what = >I =3D >>> was >>>> trying to address with my suggestion to have a pragma for = >this---just =3D >>> to >>>> match C (and Fortran?), of course. Name me a single Modula-3 =3D >>> programmer >>>> who cares in what order the bits in his parameters are pushed on the >>>> stack in a Modula-3-to-Modula-3 call. >>>> =3D20 >>>> And I am definitely in that school of thought that says that =3D >>> programming >>>> languages should not "evolve". Better to leave well enough alone. >>>> =3D20 >>>> How much Modula-3 code has been written that uses LONGINT? Other = >than >>>> to talk to C? I've certainly never used it. >>>> =3D20 >>>> Mika >>>> =3D20 >>>> =3D20 >>>> =3D20 >>>> Jay K writes: >>>>> --_264cb69b-0215-44c3-807c-8b4d8ea0ea59_ >>>>> Content-Type: text/plain; charset=3D3D"iso-8859-1" >>>>> Content-Transfer-Encoding: quoted-printable >>>>> =3D20 >>>>> =3D20 >>>>> TYPE LONGINT =3D3D3D ARRAY [0..1] OF INTEGER on a 32bit system is = >very =3D >>> close to=3D3D >>>>> LONGINT. >>>>> =3D20 >>>>> Plus treating it opaquely and providing a bunch of functions to =3D >>> operate on=3D3D >>>>> it. >>>>> =3D20 >>>>> Just as well therefore could be RECORD hi=3D3D2Clo:LONGINT END (see = >=3D >>> LARGE_INTE=3D3D >>>>> GER and ULARGE_INTEGER in winnt.h) >>>>> =3D20 >>>>> =3D3D20 >>>>> =3D20 >>>>> Differences that come to mind: >>>>> =3D20 >>>>> infix operators <=3D3D3D=3D3D3D=3D3D3D=3D3D20 >>>>> =3D20 >>>>> possibly passed differently as a parameter >>>>> =3D20 >>>>> or returned differently as a result >>>>> =3D20 >>>>> ie. probably "directly compatible with" "long long"=3D3D2C passed = >by =3D >>> value (o=3D3D >>>>> f course you could always pass by pointer and achieve = >compatibilitity =3D >>> trivi=3D3D >>>>> ally) >>>>> =3D20 >>>>> =3D3D20 >>>>> =3D20 >>>>> =3D3D20 >>>>> =3D20 >>>>> I have to say though=3D3D2C the biggest reason is in-fix operators. = >=3D >>> Convenient =3D3D >>>>> syntax. >>>>> =3D20 >>>>> C++ is the best and some way worst of example of the general right = >=3D >>> way to d=3D3D >>>>> o this -- you let programmers define types and their infix = >operators. =3D >>> Other=3D3D >>>>> languages just come with a passle of special cases of types that = >have =3D >>> in-f=3D3D >>>>> ix operators. >>>>> =3D20 >>>>> A good example is that Java infix operator + on string=3D3D2C = >besides =3D >>> the vario=3D3D >>>>> us integers=3D3D2C and nothing else. >>>>> =3D20 >>>>> =3D3D20 >>>>> =3D20 >>>>> =3D3D20 >>>>> =3D20 >>>>> I think C# lets you define operators=3D3D2C yet people don't = >complain =3D >>> that it i=3D3D >>>>> s "a mess" as they do of C++. >>>>> =3D20 >>>>> I think Python does now too. >>>>> =3D20 >>>>> So it is feature growing in popularity among "mainstream" =3D >>> languages=3D3D2C not =3D3D >>>>> just C++. >>>>> =3D20 >>>>> C++ of course is extremely mainstream=3D3D2C but also a favorite =3D >>> target. (ht=3D3D >>>>> tp://www.relisoft.com/tools/CppCritic.html) >>>>> =3D20 >>>>> =3D3D20 >>>>> =3D20 >>>>> =3D3D20 >>>>> =3D20 >>>>> We also have subranges of LONGINT. >>>>> =3D20 >>>>> I'm not sure what the generalization of subranges are=3D3D2C = >granted. >>>>> =3D20 >>>>> Maybe some sort of C++ template that takes constants in the = >template =3D >>> and d=3D3D >>>>> oes range checks at runtime. Yeah=3D3D2C maybe. >>>>> =3D20 >>>>> =3D3D20 >>>>> =3D20 >>>>> =3D3D20 >>>>> =3D20 >>>>> And as you point out=3D3D2C convenient literal syntax. >>>>> =3D20 >>>>> =3D3D20 >>>>> =3D20 >>>>> =3D3D20 >>>>> =3D20 >>>>> People reasonably argue for library extension in place of language = >=3D >>> extensio=3D3D >>>>> n=3D3D2C but that requires a language which is flexible enough to = >write =3D >>> librari=3D3D >>>>> es with the desired interface=3D3D2C and so many languages don't = >let =3D >>> infix oper=3D3D >>>>> ators be in a user-written library. >>>>> =3D20 >>>>> (There is a subtle but useless distinction here -- infix operators = >=3D >>> being in=3D3D >>>>> libraries vs. "user-written" libraries. The infix set operations = >for =3D >>> examp=3D3D >>>>> le are in a library=3D3D2C but not user-written=3D3D2C special=3D3D2C= > the =3D >>> compiler know=3D3D >>>>> s about it.) >>>>> =3D20 >>>>> =3D3D20 >>>>> =3D20 >>>>>> that would perhaps not match how C handles "long long" on the same >>>>>> platform (which is how=3D3D2C come to think of it?)=3D3D2C and = >that =3D >>> would require >>>>> =3D20 >>>>> =3D20 >>>>> =3D3D20 >>>>> =3D20 >>>>> On NT/x86=3D3D2C __int64/long long is returned in the register pair = >=3D >>> edx:eax. >>>>> =3D20 >>>>> edx is high=3D3D2C eax is low. >>>>> =3D20 >>>>> When passed as a parameter to __stdcall or __cdecl is just passed = >as =3D >>> two 32=3D3D >>>>> bit values adjacent on the stack=3D3D2C "hi=3D3D2C lo=3D3D2C = >hi=3D3D2C lo=3D3D2C =3D >>> it's off to pu=3D3D >>>> sh we go" is the Snow White-influenced mantra to remember how to = >pass =3D >>> them=3D3D >>>>> =3D3D2C at least on little endian stack-growing-down machines = >(which =3D >>> includes x=3D3D >>>>> 86). For __fastcall I'm not sure they are passed in registers or on = >=3D >>> the sta=3D3D >>>>> ck. >>>>> =3D20 >>>>> Passing and/or returning small structs also has special efficient =3D= > >>> handling =3D3D >>>>> in the ABI=3D3D2C so __int64 really might be equivalent to a small = >=3D >>> record. Not =3D3D >>>>> that cm3 necessarily implements that "correctly" -- for interop = >with =3D >>> C=3D3D3B =3D3D >>>>> for Modula-3 calling Modula-3 we can make up our own ABI so there =3D= > >>> isn't rea=3D3D >>>>> lly an "incorrect" way. Notice the mingw problem I had passing a =3D >>> Win32 poin=3D3D >>>>> t struct by value=3D3D2C I cheated and passed it by VAR to a C = >wrapper =3D >>> to worka=3D3D >>>>> round the gcc backend bug (which was mentioned a few times and = >which =3D >>> I look=3D3D >>>>> ed into the code for=3D3D2C but took the easy route) >>>>> =3D20 >>>>> =3D3D20 >>>>> =3D20 >>>>> =3D3D20 >>>>> =3D20 >>>>> I don't know how long long works on other platforms but probably =3D >>> similar. >>>>> =3D20 >>>>> Probably a certain register pair for return values. >>>>> =3D20 >>>>> =3D3D20 >>>>> =3D20 >>>>> - Jay >>>>> =3D20 >>>>> =3D3D20 >>>>>> To: hosking at cs.purdue.edu >>>>>> Date: Sat=3D3D2C 17 Apr 2010 19:47:03 -0700 >>>>>> From: mika at async.async.caltech.edu >>>>>> CC: m3devel at elegosoft.com >>>>>> Subject: Re: [M3devel] INTEGER >>>>>> =3D3D20 >>>>>> Tony Hosking writes: >>>>>>> =3D20 >>>>>> ... >>>>>>> =3D20 >>>>>>>> We need it to match 64-bit integers on 32-bit machines? That = >seems =3D >>> =3D3D3D >>>>>>> like >>>>>>>> a very weak rationale indeed=3D3D2C if the same functionality = >could =3D >>> be =3D3D3D >>>>>>> provided >>>>>>>> through some other mechanism (e.g.=3D3D2C ARRAY [0..1] OF =3D >>> INTEGER---even =3D3D >>>>> =3D3D3D >>>>>>> with >>>>>>>> a pragma e.g. <*CLONGLONG*>.. if it is necessary to tell the =3D >>> compiler =3D3D >>>>> =3D3D3D >>>>>>> that >>>>>>>> a special linkage convention is needed). >>>>>>> =3D20 >>>>>>> There's no special linkage convention. Not sure what you mean = >here. >>>>>>> =3D20 >>>>>> =3D3D20 >>>>>> I just mean if we had >>>>>> =3D3D20 >>>>>> TYPE LONGINT =3D3D3D ARRAY [0..1] OF INTEGER >>>>>> =3D3D20 >>>>>> that would perhaps not match how C handles "long long" on the same >>>>>> platform (which is how=3D3D2C come to think of it?)=3D3D2C and = >that =3D >>> would require >>>>>> special linkage tricks. >>>>>> =3D3D20 >>>>>> But what would be lost? The ability to type literals.=3D3D20 >>>>>> =3D3D20 >>>>>> You could get the same code interface on 32- and 64-bit machine by >>>>>> defining >>>>>> =3D3D20 >>>>>> TYPE FileOffset =3D3D3D ARRAY[0..1] OF [-16_80000000 .. = >+16_7fffffff ] >>>>>> =3D3D20 >>>>>> and using that. >>>>>> =3D3D20 >>>>>> =3D3D20 >>>>>> Mika >>>>> =3D3D >>>>> =3D20 >>>>> --_264cb69b-0215-44c3-807c-8b4d8ea0ea59_ >>>>> Content-Type: text/html; charset=3D3D"iso-8859-1" >>>>> Content-Transfer-Encoding: quoted-printable >>>>> =3D20 >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> TYPE LONGINT =3D3D3D ARRAY [0..1] OF INTEGER on a =3D3D3B32bit = >system =3D >>> is very c=3D3D >>>>> lose to LONGINT.
>>>>>  =3D3D3BPlus treating it opaquely and providing a bunch of =3D >>> functions to ope=3D3D >>>>> rate on it.
>>>>>  =3D3D3BJust as well therefore could be RECORD = >hi=3D3D2Clo:LONGINT =3D >>> END (see LAR=3D3D >>>>> GE_INTEGER and ULARGE_INTEGER in winnt.h)
>>>>>  =3D3D3B
>>>>> Differences that come to mind:
>>>>>  =3D3D3B =3D3D3Binfix operators =3D3D3B = ><=3D3D3B=3D3D3D=3D3D3D=3D3D3D =3D >>>
>>>>>  =3D3D3B possibly passed differently =3D3D3Bas a = >parameter
>>>>>  =3D3D3B or returned differently as a result
>>>>>  =3D3D3B ie. probably "directly compatible with" "long = >long"=3D3D2C =3D >>> passed by v=3D3D >>>>> alue (of course you could always pass by pointer and achieve =3D >>> compatibilitit=3D3D >>>>> y trivially)
>>>>>  =3D3D3B
>>>>>  =3D3D3B
>>>>> I have to say though=3D3D2C the biggest reason is in-fix operators. = >=3D >>> Convenient =3D3D >>>>> syntax.
>>>>> C++ is the best and some way worst of example of the general right = >=3D >>> way to d=3D3D >>>>> o this -- you let programmers define types and their infix = >operators. =3D >>> Other=3D3D >>>>> languages just come with a passle of special cases of types that = >have =3D >>> in-f=3D3D >>>>> ix operators.
>>>>> A good example is that Java infix operator + on string=3D3D2C = >besides =3D >>> the vario=3D3D >>>>> us integers=3D3D2C and nothing else.
>>>>>  =3D3D3B
>>>>>  =3D3D3B
>>>>> I think C# lets you define operators=3D3D2C yet people don't = >complain =3D >>> that it i=3D3D >>>>> s "a mess" as they do of C++.
>>>>> I think Python does now too.
>>>>> So it is feature growing in popularity among "mainstream" =3D >>> languages=3D3D2C not =3D3D >>>>> just C++.
>>>>>  =3D3D3B =3D3D3B C++ of course is extremely mainstream=3D3D2C= > but =3D >>> also a favori=3D3D >>>>> te target. (>> href=3D3D3D"http://www.relisoft.com/tools/CppCritic.html">http:/=3D3D >>>>> /www.relisoft.com/tools/CppCritic.html)
>>>>>  =3D3D3B
>>>>>  =3D3D3B
>>>>> We also have subranges of LONGINT.
>>>>> I'm not sure what the generalization of subranges are=3D3D2C =3D >>> granted.
>>>>>  =3D3D3BMaybe some sort of C++ template that takes constants in = >the =3D >>> templat=3D3D >>>>> e and does range checks at runtime. Yeah=3D3D2C maybe.
>>>>>  =3D3D3B
>>>>>  =3D3D3B
>>>>> And as you point out=3D3D2C convenient literal syntax.
>>>>>  =3D3D3B
>>>>>  =3D3D3B
>>>>> People reasonably argue for library extension in place of language = >=3D >>> extensio=3D3D >>>>> n=3D3D2C but that requires a language which is flexible enough to = >write =3D >>> librari=3D3D >>>>> es with the desired interface=3D3D2C and so many languages don't = >let =3D >>> infix oper=3D3D >>>>> ators be in a user-written library.
>>>>> (There is a subtle but useless distinction here -- infix operators = >=3D >>> being in=3D3D >>>>> libraries vs. "user-written" libraries. The infix set operations = >for =3D >>> examp=3D3D >>>>> le are in a library=3D3D2C but not user-written=3D3D2C special=3D3D2C= > the =3D >>> compiler know=3D3D >>>>> s about it.)
>>>>>  =3D3D3B
>>>>> >=3D3D3B that would perhaps not match how C handles "long long" = >on =3D >>> the same>>>> R>>=3D3D3B platform (which is how=3D3D2C come to think of = >it?)=3D3D2C and =3D >>> that would =3D3D >>>>> require

>>>>>  =3D3D3B
>>>>> On NT/x86=3D3D2C __int64/long long is returned in the register pair = >=3D >>> edx:eax.>>>>> =3D20 >>>>> edx is high=3D3D2C eax is low.
>>>>> When passed as a parameter to __stdcall or __cdecl is just passed = >as =3D >>> two 32=3D3D >>>>> bit values adjacent on the stack=3D3D2C "hi=3D3D2C lo=3D3D2C = >hi=3D3D2C lo=3D3D2C =3D >>> it's off to pu=3D3D >>>>> sh we go" is the Snow White-influenced mantra to remember how to = >pass =3D >>> them=3D3D >>>>> =3D3D2C at least on little endian stack-growing-down machines = >(which =3D >>> includes x=3D3D >>>>> 86). For __fastcall I'm not sure they are passed in registers or on = >=3D >>> the sta=3D3D >>>>> ck.
>>>>> Passing and/or returning small structs also has special efficient =3D= > >>> handling =3D3D >>>>> in the ABI=3D3D2C so __int64 really might be equivalent to a small = >=3D >>> record. Not =3D3D >>>>> that cm3 necessarily implements that "correctly" =3D3D3B -- for = >=3D >>> interop wit=3D3D >>>>> h C=3D3D3B for Modula-3 calling Modula-3 we can make up our own ABI = >so =3D >>> there is=3D3D >>>>> n't =3D3D3Breally an "incorrect" way. =3D3D3BNotice the = >mingw =3D >>> problem I had=3D3D >>>>> passing a Win32 point struct by value=3D3D2C I cheated and passed = >it by =3D >>> VAR to=3D3D >>>>> a =3D3D3BC wrapper to workaround the gcc backend bug (which was = >=3D >>> mentioned =3D3D >>>>> a few times and which I looked into the code for=3D3D2C but took = >the =3D >>> easy route=3D3D >>>>> )
>>>>>  =3D3D3B
>>>>>  =3D3D3B
>>>>> I don't know how long long works on other platforms but probably =3D >>> similar.>>>> R> >>>>> Probably a certain register pair for return values.
>>>>>  =3D3D3B
>>>>>  =3D3D3B- Jay

 =3D3D3B
>=3D3D3B To: =3D >>> hosking at cs.purdue.edu
>=3D3D3B=3D3D >>>>> Date: Sat=3D3D2C 17 Apr 2010 19:47:03 -0700
>=3D3D3B From: =3D >>> mika at async.async.c=3D3D >>>>> altech.edu
>=3D3D3B CC: m3devel at elegosoft.com
>=3D3D3B = >Subject: =3D >>> Re: [M3de=3D3D >>>>> vel] INTEGER
>=3D3D3B
>=3D3D3B Tony Hosking = >writes:
>=3D3D3B =3D >>> >=3D3D3B
=3D3D >>>>> >=3D3D3B ...
>=3D3D3B >=3D3D3B
>=3D3D3B = >>=3D3D3B>=3D3D3B We =3D >>> need it to match 64-b=3D3D >>>>> it integers on 32-bit machines? That seems =3D3D3D
>=3D3D3B =3D >>> >=3D3D3Blike
>=3D3D >>>>> =3D3D3B >=3D3D3B>=3D3D3B a very weak rationale indeed=3D3D2C if = >the same =3D >>> functionality =3D3D >>>>> could be =3D3D3D
>=3D3D3B >=3D3D3Bprovided
>=3D3D3B = >>=3D3D3B>=3D3D3=3D >>> B through some o=3D3D >>>>> ther mechanism (e.g.=3D3D2C ARRAY [0..1] OF INTEGER---even =3D >>> =3D3D3D
>=3D3D3B >=3D3D3B=3D3D >>>>> with
>=3D3D3B >=3D3D3B>=3D3D3B a pragma e.g. =3D >>> <=3D3D3B*CLONGLONG*>=3D3D3B.. if it i=3D3D >>>>> s necessary to tell the compiler =3D3D3D
>=3D3D3B =3D >>> >=3D3D3Bthat
>=3D3D3B >=3D3D3B&=3D3D >>>>> gt=3D3D3B a special linkage convention is needed).
>=3D3D3B =3D >>> >=3D3D3B
>=3D3D3B &=3D3D >>>>> gt=3D3D3BThere's no special linkage convention. Not sure what you = >mean =3D >>> here.>>>>> >=3D3D3B >=3D3D3B
>=3D3D3B
>=3D3D3B I just mean if = >we =3D >>> had
>=3D3D3B
>=3D3D >>>>> =3D3D3B TYPE LONGINT =3D3D3D ARRAY [0..1] OF INTEGER
>=3D3D3B = >=3D >>>
>=3D3D3B that woul=3D3D >>>>> d perhaps not match how C handles "long long" on the = >same
>=3D3D3B =3D >>> platfor=3D3D >>>>> m (which is how=3D3D2C come to think of it?)=3D3D2C and that would = >=3D >>> require
>=3D3D >>>>> =3D3D3B special linkage tricks.
>=3D3D3B
>=3D3D3B But = >what would =3D >>> be lost? Th=3D3D >>>>> e ability to type literals.
>=3D3D3B
>=3D3D3B You could = >get =3D >>> the same co=3D3D >>>>> de interface on 32- and 64-bit machine by
>=3D3D3B =3D >>> defining
>=3D3D3B
=3D3D >>>>> >=3D3D3B TYPE FileOffset =3D3D3D ARRAY[0..1] OF [-16_80000000 .. = >=3D >>> +16_7fffffff ]>>>> R>>=3D3D3B
>=3D3D3B and using that.
>=3D3D3B = >
>=3D3D3B =3D >>>
>=3D3D3B Mika>>>>> >>>>> =3D3D >>>>> =3D20 >>>>> --_264cb69b-0215-44c3-807c-8b4d8ea0ea59_-- From mika at async.async.caltech.edu Mon Apr 19 19:40:55 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Mon, 19 Apr 2010 10:40:55 -0700 Subject: [M3devel] INTEGER In-Reply-To: References: , , , , <7C7408D0-9A40-4988-BADA-A9FD8C15D388@cs.purdue.edu>, , , , , , , , , , , , <20100418023535.3BA9E1A2103@async.async.caltech.edu>, , , , <20100418024703.6965B1A2103@async.async.caltech.edu>, , <20100418074927.934461A2117@async.async.caltech.edu>, <04EB7FF8-D304-428D-839E-233FCE009C98@cs.purdue.edu>, <20100418195901.CDACB1A20F6@async.async.caltech.edu>, Message-ID: <20100419174055.D1A371A20EB@async.async.caltech.edu> Jay K writes: >--_54bd4884-6c8e-48b7-9b5f-c39a87170d04_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >Mika=2C the build process hasn't "really" changed. There was always an occa= ... > >I haven't tried 5.1/4.1/3.6 yet but maybe I will soon. I actually use curre= >nt configuration files when doing that though=2C so that probably inhibits = >3.6 (unless I use its configuration files). Sure, but as I mentioned to Tony, it is actually nice to be able to go "backwards" as well. ... >People really want their compiler to handle multiple precision arithmetic= >=2C at least to attain 64bit precision. > >It is nice and convenient=2C if not strictly necessary. > >=20 > >=20 > >Another view though=2C besides "interop" with C=2C is "keeping up" with C. > > Again that link suggests C has had long long for something like 18 years.= > We are late. > > Even C changed=2C C99 must be around 10 years old now? and has lnog long. > > Granted=2C I tend to think of C like you think of Modula-3 --- nice that = >it never changes. > C had all sorts of things long before Modula-3 was designed. Modula-3's designers *very specifically avoided* these things. To quote directly from the Green Book: "In the early days of the Ada project, a general in the Ada Program Office opined that 'obviously the Department of Defense is not interested in an artifically simplified language such as Pascal'. Modula-3 represents the opposite point of view. We used every artifice that we could find or invent to make the language simple." There is perhaps a place for "keeping up with C". It's not in Modula-3! It's more than "nice" that Modula-3 never changes. It's critical to what makes it special. The C/Java/whathaveyou crowd is constantly sinking in in the costs of maintaining their programs because everything needs to be rewritten every few years to "keep up", and---even worse---because bugs resulting from the changes are absolutely everywhere and no one is ever quite sure that anything works right. I don't have time for this kind of nonsense. I'll use F-77 if that's the only way to get out of that rat race, but hopefully there's a better way. > It is somewhat small=2C very well known. One only needs keep up with libr= >aries now :) and one can assume a certain baseline is everywhere and write = >portable code to it. (But I've happened upon K&R compiler *recently* -- HP-= >UX/hppa only bundles a compiler for purposes of changing kernel configurati= >on (constant data) and relinking kernel. The libraries that comprise the ke= >rnel are shipped. K&R suffices and is therefore bundled. Best is probably t= >o use that compiler to build old gcc=2C and then use old gcc to build curre= >nt gcc (current gcc can't be compiled with K&R)). > Yes, let's not forget that what made C popular was its *simplicity* (used to be that didn't have to be qualified with "somewhat"). Look at what they were competing with: PL/I! All the "features" you could shake a stick at, and where is it now? Mika From jay.krell at cornell.edu Mon Apr 19 19:44:32 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 19 Apr 2010 17:44:32 +0000 Subject: [M3devel] fw: deleting files In-Reply-To: <20100419173955.08CF82474003@birch.elegosoft.com> References: <20100419173955.08CF82474003@birch.elegosoft.com> Message-ID: Deleting files doesn't remove them from the package store. Arg. We should probably have a set of quake directives: delete_interface() delete_module() delete_implementation() delete_c_source() delete_h_source() I was tempted to empty out this stuff instead of deleting, anticipating that delete wouldn't work. I suspect attempting to import will still correctly fail, since I hope import uses the conside *.m3x files. - Jay > Date: Mon, 19 Apr 2010 19:39:54 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/04/19 19:39:54 > > Modified files: > cm3/m3-libs/libm3/src/os/Common/: m3makefile > cm3/m3-libs/libm3/src/os/POSIX/: m3makefile > cm3/m3-libs/libm3/src/os/WIN32/: m3makefile > Removed files: > cm3/m3-libs/libm3/src/os/Common/: Socket.i3 Socket.m3 > cm3/m3-libs/libm3/src/os/POSIX/: SocketPosix.m3 SocketPosixC.c > cm3/m3-libs/libm3/src/os/WIN32/: SocketWin32.m3 > SocketWin32.m3.sav > > Log message: > Nobody uses libm3's socket support. > So empty it out instead of fixing it. > Let's focus effort elsewhere, e.g. m3-comm/tcp. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Apr 19 20:05:15 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 19 Apr 2010 18:05:15 +0000 Subject: [M3devel] INTEGER In-Reply-To: <20100419172313.68B241A20D6@async.async.caltech.edu> References: , , ,,<7C7408D0-9A40-4988-BADA-A9FD8C15D388@cs.purdue.edu>, ,,, , , , , , , , , <20100418023535.3BA9E1A2103@async.async.caltech.edu>, , , , <20100418024703.6965B1A2103@async.async.caltech.edu>, , <20100418074927.934461A2117@async.async.caltech.edu>, <04EB7FF8-D304-428D-839E-233FCE009C98@cs.purdue.edu>, <20100418195901.CDACB1A20F6@async.async.caltech.edu>, , <20100419172313.68B241A20D6@async.async.caltech.edu> Message-ID: Mika, I must disagree on one point -- that people with large problems have 64bit machines. Large problem does not mean "large in memory" or large working set. It can mean "large on disk" and be combined with mostly sequential access to that disk. While 32bit is on the way out, we've had >2GB files for many years already, while 32bit was still very entrenched. You know -- disk costs vs. memory cost. It is memory beyond 4GB driving 64bit adoption, whereas disks went past 4GB long before at lower cost.. In your defense, I'll add "literals can be strings", something like: INTERFACE Int64; TYPE T = (* opaque! *) RECORD hi: INTEGER; low: Word.T; END; PROCEDURE Add(a,b:T):T; PROCEDURE Sub(a,b:T):T; PROCEDURE LT(a,b:T):BOOLEAN; PROCEDURE FromText(a:TEXT):T; <== PROCEDURE FromInt(a:INTEGER):T; PROCEDURE FromUInt64(a:UInt64.T):T RAISES{Overflow}; INTERFACE UInt64; TYPE T = (* opaque! *) RECORD hi, low: Word.T; END; PROCEDURE Add(a,b:T):T; PROCEDURE Sub(a,b:T):T; PROCEDURE LT(a,b:T):BOOLEAN; PROCEDURE FromText(a:TEXT):T; <== PROCEDURE FromInt(a:INTEGER):T; PROCEDURE FromInt64(a:Int64.T):T RAISES{Overflow}; thus reducing the need. Does Modula-3 offer opaque types whose size is known to the client? That is something I'd like, opacity without paying for heap allocation. (Notice these interfaces are circularly dependent, seems reasonable, but I believe not allowed?) ? I still say though, everyone prefers infix operators. "Things change". New needs are discovered. Better ways of doing things. Old restrictions fall away. Sometimes progress is made. Sometimes missteps are taken. I believe we even had some proposals that didn't change the language, e.g. big subranges or big packed types? TYPE INT64 = [-16_8000000000000000..16_7FFFFFFFFFFFFFFF] ? or TYPE INT64 = BITS 64 FOR[-16_8000000000000000..16_7FFFFFFFFFFFFFFF] ? but that's maybe not so simple? Well, I recently found that the compiler does chose sizes based on ranges: VAR a:[0..255] is only a byte, even without saying BITS 8 (at least when in a record). Do your language processing tools handle the notion that they are "cross compiling" to 64bit machines, where target integers don't fit in host integers? - Jay > To: hosking at cs.purdue.edu > Date: Mon, 19 Apr 2010 10:23:13 -0700 > From: mika at async.async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] INTEGER > > > Well *my* problem is that I still use PM3 for a lot of things. Trying to > switch to CM3, yes, but I can't "certify" CM3 for critical stuff yet. > > So I'm maintaining a significant amount of code that needs to compile > under both PM3 and CM3. Two problems crop up. > > 1. If there are bugs in m3tk/stubgen, the fixes only apply to one or > the other version of m3tk/stubgen. > > 2. Some of the code I'm maintaining processes Modula-3 code as input. > It needs to be in two versions. > > In this kind of environment, programming languages don't really > evolve, since the system depends on their being both forward- and > backward-compatible. They "change" is more correct. The way Java > changes. > > More in general, though, Modula-3's designers were clearly well acquainted > with C, Fortran, and other languages that provide different-range > integers. They chose not to indulge. I even have a version of Modula-3 > for a 16-bit machine that doesn't do it, even though on this machine the > need for a 32-bit integer is arguably greater than the need for 64-bit > integers on 32-bit machines. Now we indulge in this language complication > to solve what is clearly a temporary problem, since anyone who cares > about large problems is going to have 64-bit systems yesterday... and > meanwhile no one seems to have availed himself of the solution! > > My worst fear is that once the process gets started, the reason for > staying with the original Green-Book specification has now been defeated > and we will see more and more "evolution". Trying to actually build > systems that process Modula-3 like data becomes, at that point, like > trying to stand in quicksand. > > I'm not incredibly picky here... I just hope it doesn't go further. > I would personally support either sticking with the current status quo > or going back to the Green Book w.r.t. integers and characters. > > Saying that EWD wasn't renowned for his practicality is something he > would have taken as a great compliment, I'm sure. > > Mika > > Tony Hosking writes: > >Mika, > > > >First off, I'd be very interested to know what the issues are with = > >LONGINT and stubgen. We are building that every day in regression = > >testing. It would be really good to get some precise feedback. > > > >True, LONGINT is integrated with all of the language tools (same as = > >WIDECHAR). > > > >I suppose that is the price we pay for the language having evolved. = > >Nevertheless, CM3 should be totally backward compatible with the green = > >book. There is no reason it should not build packages from PM3 or SRC. > > > >Now, this is not to say that perhaps we haven't overreached with LONGINT = > >given that 64-bit is more prevalent. But then it is also useful to be = > >able to interoperate with C libraries. The previous interfacing was = > >pretty much a kludge, using ARRAY[0..1] OF INTEGER for "long long" but = > >then not propagating the double INTEGER value properly throughout the = > >Modula-3 libraries. > > > >I'm sorry to say that EWD was not particularly renowned for his = > >practicality; pedant more like. Nice to be high and mighty but we also = > >need to interact with the real world. > > > >We should be able to make this work. Is there a better alternative? = > >Revoke LONGINT, and WIDECHAR? > > > >On 18 Apr 2010, at 15:59, Mika Nystrom wrote: > > > >>=20 > >> My problem is really just that it's ugly. LONGx is showing up as an = > >issue > >> in all sorts of low-level code, which is not surprising since Modula-3 > >> with LONGx is not the same language as Modula-3 (maybe we should call > >> it Modula-3+?)=20 > >>=20 > >> The compiler bootstrapping process has gotten more complicated due to = > >it, > >> and when I cvs updated m3tk yesterday stubgen wouldn't compile because = > >there > >> was something "long" in it that wasn't there before. I have no idea = > >what > >> library or components I needed to update and recompile and didn't have = > >the > >> time to deal with the issue at the time. > >>=20 > >> And the new m3tk, stubgen, and compiler(?) won't compile using PM3 or > >> SRC M3 since we're no longer using the language of the Green Book. > >> (Same comment goes for WIDECHAR, by the way.) > >>=20 > >> One of the wonderful things about Modula-3 *used to be* that I could > >> grab some old package from DECSRC and just use it without changes = > >since > >> no one had messed with the language definition. This is still true as > >> far as programs that just use the tools go, but it's no longer true = > >for > >> programs that process Modula-3 code as input data. Of which there are > >> more than a few: many aspects of Modula-3 were specifically designed = > >to > >> make the language easy to process by program, as an intermediate = > >format > >> and whatnot. > >>=20 > >> To quote E.W.D.: > >>=20 > >> 'Unfathomed misunderstanding is further revealed by the term "software > >> maintenance", as a result of which many people continue to believe = > >that > >> programs and even programming languages themselves are subject to wear > >> and tear. Your car needs maintenance too, doesn't it? Famous is the = > >story > >> of the oil company that believed that its PASCAL programs did not last > >> as long as its FORTRAN programs "because PASCAL was not maintained".' > >>=20 > >> LONGx is causing me to have to do "software maintenance" on Modula-3 > >> programs... for a feature that no one appears to be using and is = > >quickly > >> becoming irrelevant. > >>=20 > >> Mika > >>=20 > >>=20 > >> Tony Hosking writes: > >>> In the language spec NUMBER(a) and LAST(a) - FIRST(a) + 1 are *not* =3D= > > > >>> defined to mean the same thing for all types. > >>> NUMBER does have an INTEGER value, as expected for subranges of = > >LONGINT =3D > >>> that are not too large. > >>> This is as it has always been for subranges of INTEGER that are not = > >too =3D > >>> large. > >>>=20 > >>> Mika, I'm not sure I see any of the problems you are worrying about = > >in =3D > >>> the current definition of LONGINT/LONGCARD. > >>>=20 > >>> On 18 Apr 2010, at 03:49, Mika Nystrom wrote: > >>>=20 > >>>> =3D20 > >>>> Jay I know most of this, and it doesn't really answer the question > >>>> "what is it for?" > >>>> =3D20 > >>>> I think we've already established that LONGINT isn't useful for =3D > >>> counting > >>>> anything that might actually reside in the computer's memory: it = > >makes > >>>> no sense as an array index, for instance. INTEGER suffices for = > >that. > >>>> =3D20 > >>>> I thought that the only real reason for LONGINT was to match C's > >>>> declaration of various seek-related routines on 32-bit machines. > >>>> That's not a very good reason. > >>>> =3D20 > >>>> C++ succeeds because it does very well in the area(s) it is good at. > >>>> People who want to program in C++ will clearly program in C++, not > >>>> Modula-3. Modula-3 is never, ever going to be the language of = > >choice =3D > >>> for > >>>> people who want lots of snazzy infix operators. Modula-3 is = > >supposed =3D > >>> to > >>>> be a language with about as powerful semantics as C++ and an = > >extremely > >>>> simple syntax and definition---snazzy infix is one of the things you > >>>> give up for that. I don't see how LONGINT fits into this picture. > >>>> Now we have LONGCARD too? And it's infected the definitions > >>>> of FIRST and LAST? But not NUMBER... argh! > >>>> =3D20 > >>>> so, > >>>> =3D20 > >>>> NUMBER(a) and LAST(a) - FIRST(a) + 1 > >>>> =3D20 > >>>> no longer mean the same thing? Are we going to see lots of comments > >>>> in generics in the future where it says T may not be an open array > >>>> type nor an array type indexed on LONGINT or a subrange thereof? > >>>> =3D20 > >>>> Your comments about different parameter-passing techniques was what = > >I =3D > >>> was > >>>> trying to address with my suggestion to have a pragma for = > >this---just =3D > >>> to > >>>> match C (and Fortran?), of course. Name me a single Modula-3 =3D > >>> programmer > >>>> who cares in what order the bits in his parameters are pushed on the > >>>> stack in a Modula-3-to-Modula-3 call. > >>>> =3D20 > >>>> And I am definitely in that school of thought that says that =3D > >>> programming > >>>> languages should not "evolve". Better to leave well enough alone. > >>>> =3D20 > >>>> How much Modula-3 code has been written that uses LONGINT? Other = > >than > >>>> to talk to C? I've certainly never used it. > >>>> =3D20 > >>>> Mika > >>>> =3D20 > >>>> =3D20 > >>>> =3D20 > >>>> Jay K writes: > >>>>> --_264cb69b-0215-44c3-807c-8b4d8ea0ea59_ > >>>>> Content-Type: text/plain; charset=3D3D"iso-8859-1" > >>>>> Content-Transfer-Encoding: quoted-printable > >>>>> =3D20 > >>>>> =3D20 > >>>>> TYPE LONGINT =3D3D3D ARRAY [0..1] OF INTEGER on a 32bit system is = > >very =3D > >>> close to=3D3D > >>>>> LONGINT. > >>>>> =3D20 > >>>>> Plus treating it opaquely and providing a bunch of functions to =3D > >>> operate on=3D3D > >>>>> it. > >>>>> =3D20 > >>>>> Just as well therefore could be RECORD hi=3D3D2Clo:LONGINT END (see = > >=3D > >>> LARGE_INTE=3D3D > >>>>> GER and ULARGE_INTEGER in winnt.h) > >>>>> =3D20 > >>>>> =3D3D20 > >>>>> =3D20 > >>>>> Differences that come to mind: > >>>>> =3D20 > >>>>> infix operators <=3D3D3D=3D3D3D=3D3D3D=3D3D20 > >>>>> =3D20 > >>>>> possibly passed differently as a parameter > >>>>> =3D20 > >>>>> or returned differently as a result > >>>>> =3D20 > >>>>> ie. probably "directly compatible with" "long long"=3D3D2C passed = > >by =3D > >>> value (o=3D3D > >>>>> f course you could always pass by pointer and achieve = > >compatibilitity =3D > >>> trivi=3D3D > >>>>> ally) > >>>>> =3D20 > >>>>> =3D3D20 > >>>>> =3D20 > >>>>> =3D3D20 > >>>>> =3D20 > >>>>> I have to say though=3D3D2C the biggest reason is in-fix operators. = > >=3D > >>> Convenient =3D3D > >>>>> syntax. > >>>>> =3D20 > >>>>> C++ is the best and some way worst of example of the general right = > >=3D > >>> way to d=3D3D > >>>>> o this -- you let programmers define types and their infix = > >operators. =3D > >>> Other=3D3D > >>>>> languages just come with a passle of special cases of types that = > >have =3D > >>> in-f=3D3D > >>>>> ix operators. > >>>>> =3D20 > >>>>> A good example is that Java infix operator + on string=3D3D2C = > >besides =3D > >>> the vario=3D3D > >>>>> us integers=3D3D2C and nothing else. > >>>>> =3D20 > >>>>> =3D3D20 > >>>>> =3D20 > >>>>> =3D3D20 > >>>>> =3D20 > >>>>> I think C# lets you define operators=3D3D2C yet people don't = > >complain =3D > >>> that it i=3D3D > >>>>> s "a mess" as they do of C++. > >>>>> =3D20 > >>>>> I think Python does now too. > >>>>> =3D20 > >>>>> So it is feature growing in popularity among "mainstream" =3D > >>> languages=3D3D2C not =3D3D > >>>>> just C++. > >>>>> =3D20 > >>>>> C++ of course is extremely mainstream=3D3D2C but also a favorite =3D > >>> target. (ht=3D3D > >>>>> tp://www.relisoft.com/tools/CppCritic.html) > >>>>> =3D20 > >>>>> =3D3D20 > >>>>> =3D20 > >>>>> =3D3D20 > >>>>> =3D20 > >>>>> We also have subranges of LONGINT. > >>>>> =3D20 > >>>>> I'm not sure what the generalization of subranges are=3D3D2C = > >granted. > >>>>> =3D20 > >>>>> Maybe some sort of C++ template that takes constants in the = > >template =3D > >>> and d=3D3D > >>>>> oes range checks at runtime. Yeah=3D3D2C maybe. > >>>>> =3D20 > >>>>> =3D3D20 > >>>>> =3D20 > >>>>> =3D3D20 > >>>>> =3D20 > >>>>> And as you point out=3D3D2C convenient literal syntax. > >>>>> =3D20 > >>>>> =3D3D20 > >>>>> =3D20 > >>>>> =3D3D20 > >>>>> =3D20 > >>>>> People reasonably argue for library extension in place of language = > >=3D > >>> extensio=3D3D > >>>>> n=3D3D2C but that requires a language which is flexible enough to = > >write =3D > >>> librari=3D3D > >>>>> es with the desired interface=3D3D2C and so many languages don't = > >let =3D > >>> infix oper=3D3D > >>>>> ators be in a user-written library. > >>>>> =3D20 > >>>>> (There is a subtle but useless distinction here -- infix operators = > >=3D > >>> being in=3D3D > >>>>> libraries vs. "user-written" libraries. The infix set operations = > >for =3D > >>> examp=3D3D > >>>>> le are in a library=3D3D2C but not user-written=3D3D2C special=3D3D2C= > > the =3D > >>> compiler know=3D3D > >>>>> s about it.) > >>>>> =3D20 > >>>>> =3D3D20 > >>>>> =3D20 > >>>>>> that would perhaps not match how C handles "long long" on the same > >>>>>> platform (which is how=3D3D2C come to think of it?)=3D3D2C and = > >that =3D > >>> would require > >>>>> =3D20 > >>>>> =3D20 > >>>>> =3D3D20 > >>>>> =3D20 > >>>>> On NT/x86=3D3D2C __int64/long long is returned in the register pair = > >=3D > >>> edx:eax. > >>>>> =3D20 > >>>>> edx is high=3D3D2C eax is low. > >>>>> =3D20 > >>>>> When passed as a parameter to __stdcall or __cdecl is just passed = > >as =3D > >>> two 32=3D3D > >>>>> bit values adjacent on the stack=3D3D2C "hi=3D3D2C lo=3D3D2C = > >hi=3D3D2C lo=3D3D2C =3D > >>> it's off to pu=3D3D > >>>> sh we go" is the Snow White-influenced mantra to remember how to = > >pass =3D > >>> them=3D3D > >>>>> =3D3D2C at least on little endian stack-growing-down machines = > >(which =3D > >>> includes x=3D3D > >>>>> 86). For __fastcall I'm not sure they are passed in registers or on = > >=3D > >>> the sta=3D3D > >>>>> ck. > >>>>> =3D20 > >>>>> Passing and/or returning small structs also has special efficient =3D= > > > >>> handling =3D3D > >>>>> in the ABI=3D3D2C so __int64 really might be equivalent to a small = > >=3D > >>> record. Not =3D3D > >>>>> that cm3 necessarily implements that "correctly" -- for interop = > >with =3D > >>> C=3D3D3B =3D3D > >>>>> for Modula-3 calling Modula-3 we can make up our own ABI so there =3D= > > > >>> isn't rea=3D3D > >>>>> lly an "incorrect" way. Notice the mingw problem I had passing a =3D > >>> Win32 poin=3D3D > >>>>> t struct by value=3D3D2C I cheated and passed it by VAR to a C = > >wrapper =3D > >>> to worka=3D3D > >>>>> round the gcc backend bug (which was mentioned a few times and = > >which =3D > >>> I look=3D3D > >>>>> ed into the code for=3D3D2C but took the easy route) > >>>>> =3D20 > >>>>> =3D3D20 > >>>>> =3D20 > >>>>> =3D3D20 > >>>>> =3D20 > >>>>> I don't know how long long works on other platforms but probably =3D > >>> similar. > >>>>> =3D20 > >>>>> Probably a certain register pair for return values. > >>>>> =3D20 > >>>>> =3D3D20 > >>>>> =3D20 > >>>>> - Jay > >>>>> =3D20 > >>>>> =3D3D20 > >>>>>> To: hosking at cs.purdue.edu > >>>>>> Date: Sat=3D3D2C 17 Apr 2010 19:47:03 -0700 > >>>>>> From: mika at async.async.caltech.edu > >>>>>> CC: m3devel at elegosoft.com > >>>>>> Subject: Re: [M3devel] INTEGER > >>>>>> =3D3D20 > >>>>>> Tony Hosking writes: > >>>>>>> =3D20 > >>>>>> ... > >>>>>>> =3D20 > >>>>>>>> We need it to match 64-bit integers on 32-bit machines? That = > >seems =3D > >>> =3D3D3D > >>>>>>> like > >>>>>>>> a very weak rationale indeed=3D3D2C if the same functionality = > >could =3D > >>> be =3D3D3D > >>>>>>> provided > >>>>>>>> through some other mechanism (e.g.=3D3D2C ARRAY [0..1] OF =3D > >>> INTEGER---even =3D3D > >>>>> =3D3D3D > >>>>>>> with > >>>>>>>> a pragma e.g. <*CLONGLONG*>.. if it is necessary to tell the =3D > >>> compiler =3D3D > >>>>> =3D3D3D > >>>>>>> that > >>>>>>>> a special linkage convention is needed). > >>>>>>> =3D20 > >>>>>>> There's no special linkage convention. Not sure what you mean = > >here. > >>>>>>> =3D20 > >>>>>> =3D3D20 > >>>>>> I just mean if we had > >>>>>> =3D3D20 > >>>>>> TYPE LONGINT =3D3D3D ARRAY [0..1] OF INTEGER > >>>>>> =3D3D20 > >>>>>> that would perhaps not match how C handles "long long" on the same > >>>>>> platform (which is how=3D3D2C come to think of it?)=3D3D2C and = > >that =3D > >>> would require > >>>>>> special linkage tricks. > >>>>>> =3D3D20 > >>>>>> But what would be lost? The ability to type literals.=3D3D20 > >>>>>> =3D3D20 > >>>>>> You could get the same code interface on 32- and 64-bit machine by > >>>>>> defining > >>>>>> =3D3D20 > >>>>>> TYPE FileOffset =3D3D3D ARRAY[0..1] OF [-16_80000000 .. = > >+16_7fffffff ] > >>>>>> =3D3D20 > >>>>>> and using that. > >>>>>> =3D3D20 > >>>>>> =3D3D20 > >>>>>> Mika > >>>>> =3D3D > >>>>> =3D20 > >>>>> --_264cb69b-0215-44c3-807c-8b4d8ea0ea59_ > >>>>> Content-Type: text/html; charset=3D3D"iso-8859-1" > >>>>> Content-Transfer-Encoding: quoted-printable > >>>>> =3D20 > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> TYPE LONGINT =3D3D3D ARRAY [0..1] OF INTEGER on a =3D3D3B32bit = > >system =3D > >>> is very c=3D3D > >>>>> lose to LONGINT.
> >>>>>  =3D3D3BPlus treating it opaquely and providing a bunch of =3D > >>> functions to ope=3D3D > >>>>> rate on it.
> >>>>>  =3D3D3BJust as well therefore could be RECORD = > >hi=3D3D2Clo:LONGINT =3D > >>> END (see LAR=3D3D > >>>>> GE_INTEGER and ULARGE_INTEGER in winnt.h)
> >>>>>  =3D3D3B
> >>>>> Differences that come to mind:
> >>>>>  =3D3D3B =3D3D3Binfix operators =3D3D3B = > ><=3D3D3B=3D3D3D=3D3D3D=3D3D3D =3D > >>>
> >>>>>  =3D3D3B possibly passed differently =3D3D3Bas a = > >parameter
> >>>>>  =3D3D3B or returned differently as a result
> >>>>>  =3D3D3B ie. probably "directly compatible with" "long = > >long"=3D3D2C =3D > >>> passed by v=3D3D > >>>>> alue (of course you could always pass by pointer and achieve =3D > >>> compatibilitit=3D3D > >>>>> y trivially)
> >>>>>  =3D3D3B
> >>>>>  =3D3D3B
> >>>>> I have to say though=3D3D2C the biggest reason is in-fix operators. = > >=3D > >>> Convenient =3D3D > >>>>> syntax.
> >>>>> C++ is the best and some way worst of example of the general right = > >=3D > >>> way to d=3D3D > >>>>> o this -- you let programmers define types and their infix = > >operators. =3D > >>> Other=3D3D > >>>>> languages just come with a passle of special cases of types that = > >have =3D > >>> in-f=3D3D > >>>>> ix operators.
> >>>>> A good example is that Java infix operator + on string=3D3D2C = > >besides =3D > >>> the vario=3D3D > >>>>> us integers=3D3D2C and nothing else.
> >>>>>  =3D3D3B
> >>>>>  =3D3D3B
> >>>>> I think C# lets you define operators=3D3D2C yet people don't = > >complain =3D > >>> that it i=3D3D > >>>>> s "a mess" as they do of C++.
> >>>>> I think Python does now too.
> >>>>> So it is feature growing in popularity among "mainstream" =3D > >>> languages=3D3D2C not =3D3D > >>>>> just C++.
> >>>>>  =3D3D3B =3D3D3B C++ of course is extremely mainstream=3D3D2C= > > but =3D > >>> also a favori=3D3D > >>>>> te target. ( >>> href=3D3D3D"http://www.relisoft.com/tools/CppCritic.html">http:/=3D3D > >>>>> /www.relisoft.com/tools/CppCritic.html)
> >>>>>  =3D3D3B
> >>>>>  =3D3D3B
> >>>>> We also have subranges of LONGINT.
> >>>>> I'm not sure what the generalization of subranges are=3D3D2C =3D > >>> granted.
> >>>>>  =3D3D3BMaybe some sort of C++ template that takes constants in = > >the =3D > >>> templat=3D3D > >>>>> e and does range checks at runtime. Yeah=3D3D2C maybe.
> >>>>>  =3D3D3B
> >>>>>  =3D3D3B
> >>>>> And as you point out=3D3D2C convenient literal syntax.
> >>>>>  =3D3D3B
> >>>>>  =3D3D3B
> >>>>> People reasonably argue for library extension in place of language = > >=3D > >>> extensio=3D3D > >>>>> n=3D3D2C but that requires a language which is flexible enough to = > >write =3D > >>> librari=3D3D > >>>>> es with the desired interface=3D3D2C and so many languages don't = > >let =3D > >>> infix oper=3D3D > >>>>> ators be in a user-written library.
> >>>>> (There is a subtle but useless distinction here -- infix operators = > >=3D > >>> being in=3D3D > >>>>> libraries vs. "user-written" libraries. The infix set operations = > >for =3D > >>> examp=3D3D > >>>>> le are in a library=3D3D2C but not user-written=3D3D2C special=3D3D2C= > > the =3D > >>> compiler know=3D3D > >>>>> s about it.)
> >>>>>  =3D3D3B
> >>>>> >=3D3D3B that would perhaps not match how C handles "long long" = > >on =3D > >>> the same >>>>> R>>=3D3D3B platform (which is how=3D3D2C come to think of = > >it?)=3D3D2C and =3D > >>> that would =3D3D > >>>>> require

> >>>>>  =3D3D3B
> >>>>> On NT/x86=3D3D2C __int64/long long is returned in the register pair = > >=3D > >>> edx:eax. >>>>>> =3D20 > >>>>> edx is high=3D3D2C eax is low.
> >>>>> When passed as a parameter to __stdcall or __cdecl is just passed = > >as =3D > >>> two 32=3D3D > >>>>> bit values adjacent on the stack=3D3D2C "hi=3D3D2C lo=3D3D2C = > >hi=3D3D2C lo=3D3D2C =3D > >>> it's off to pu=3D3D > >>>>> sh we go" is the Snow White-influenced mantra to remember how to = > >pass =3D > >>> them=3D3D > >>>>> =3D3D2C at least on little endian stack-growing-down machines = > >(which =3D > >>> includes x=3D3D > >>>>> 86). For __fastcall I'm not sure they are passed in registers or on = > >=3D > >>> the sta=3D3D > >>>>> ck.
> >>>>> Passing and/or returning small structs also has special efficient =3D= > > > >>> handling =3D3D > >>>>> in the ABI=3D3D2C so __int64 really might be equivalent to a small = > >=3D > >>> record. Not =3D3D > >>>>> that cm3 necessarily implements that "correctly" =3D3D3B -- for = > >=3D > >>> interop wit=3D3D > >>>>> h C=3D3D3B for Modula-3 calling Modula-3 we can make up our own ABI = > >so =3D > >>> there is=3D3D > >>>>> n't =3D3D3Breally an "incorrect" way. =3D3D3BNotice the = > >mingw =3D > >>> problem I had=3D3D > >>>>> passing a Win32 point struct by value=3D3D2C I cheated and passed = > >it by =3D > >>> VAR to=3D3D > >>>>> a =3D3D3BC wrapper to workaround the gcc backend bug (which was = > >=3D > >>> mentioned =3D3D > >>>>> a few times and which I looked into the code for=3D3D2C but took = > >the =3D > >>> easy route=3D3D > >>>>> )
> >>>>>  =3D3D3B
> >>>>>  =3D3D3B
> >>>>> I don't know how long long works on other platforms but probably =3D > >>> similar. >>>>> R> > >>>>> Probably a certain register pair for return values.
> >>>>>  =3D3D3B
> >>>>>  =3D3D3B- Jay

 =3D3D3B
>=3D3D3B To: =3D > >>> hosking at cs.purdue.edu
>=3D3D3B=3D3D > >>>>> Date: Sat=3D3D2C 17 Apr 2010 19:47:03 -0700
>=3D3D3B From: =3D > >>> mika at async.async.c=3D3D > >>>>> altech.edu
>=3D3D3B CC: m3devel at elegosoft.com
>=3D3D3B = > >Subject: =3D > >>> Re: [M3de=3D3D > >>>>> vel] INTEGER
>=3D3D3B
>=3D3D3B Tony Hosking = > >writes:
>=3D3D3B =3D > >>> >=3D3D3B
=3D3D > >>>>> >=3D3D3B ...
>=3D3D3B >=3D3D3B
>=3D3D3B = > >>=3D3D3B>=3D3D3B We =3D > >>> need it to match 64-b=3D3D > >>>>> it integers on 32-bit machines? That seems =3D3D3D
>=3D3D3B =3D > >>> >=3D3D3Blike
>=3D3D > >>>>> =3D3D3B >=3D3D3B>=3D3D3B a very weak rationale indeed=3D3D2C if = > >the same =3D > >>> functionality =3D3D > >>>>> could be =3D3D3D
>=3D3D3B >=3D3D3Bprovided
>=3D3D3B = > >>=3D3D3B>=3D3D3=3D > >>> B through some o=3D3D > >>>>> ther mechanism (e.g.=3D3D2C ARRAY [0..1] OF INTEGER---even =3D > >>> =3D3D3D
>=3D3D3B >=3D3D3B=3D3D > >>>>> with
>=3D3D3B >=3D3D3B>=3D3D3B a pragma e.g. =3D > >>> <=3D3D3B*CLONGLONG*>=3D3D3B.. if it i=3D3D > >>>>> s necessary to tell the compiler =3D3D3D
>=3D3D3B =3D > >>> >=3D3D3Bthat
>=3D3D3B >=3D3D3B&=3D3D > >>>>> gt=3D3D3B a special linkage convention is needed).
>=3D3D3B =3D > >>> >=3D3D3B
>=3D3D3B &=3D3D > >>>>> gt=3D3D3BThere's no special linkage convention. Not sure what you = > >mean =3D > >>> here. >>>>>> >=3D3D3B >=3D3D3B
>=3D3D3B
>=3D3D3B I just mean if = > >we =3D > >>> had
>=3D3D3B
>=3D3D > >>>>> =3D3D3B TYPE LONGINT =3D3D3D ARRAY [0..1] OF INTEGER
>=3D3D3B = > >=3D > >>>
>=3D3D3B that woul=3D3D > >>>>> d perhaps not match how C handles "long long" on the = > >same
>=3D3D3B =3D > >>> platfor=3D3D > >>>>> m (which is how=3D3D2C come to think of it?)=3D3D2C and that would = > >=3D > >>> require
>=3D3D > >>>>> =3D3D3B special linkage tricks.
>=3D3D3B
>=3D3D3B But = > >what would =3D > >>> be lost? Th=3D3D > >>>>> e ability to type literals.
>=3D3D3B
>=3D3D3B You could = > >get =3D > >>> the same co=3D3D > >>>>> de interface on 32- and 64-bit machine by
>=3D3D3B =3D > >>> defining
>=3D3D3B
=3D3D > >>>>> >=3D3D3B TYPE FileOffset =3D3D3D ARRAY[0..1] OF [-16_80000000 .. = > >=3D > >>> +16_7fffffff ] >>>>> R>>=3D3D3B
>=3D3D3B and using that.
>=3D3D3B = > >
>=3D3D3B =3D > >>>
>=3D3D3B Mika >>>>>> > >>>>> =3D3D > >>>>> =3D20 > >>>>> --_264cb69b-0215-44c3-807c-8b4d8ea0ea59_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Apr 19 20:44:00 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 19 Apr 2010 14:44:00 -0400 Subject: [M3devel] INTEGER In-Reply-To: <20100419172313.68B241A20D6@async.async.caltech.edu> References: , , , <7C7408D0-9A40-4988-BADA-A9FD8C15D388@cs.purdue.edu>, , , , , , , <20100418023535.3BA9E1A2103@async.async.caltech.edu>, , <20100418024703.6965B1A2103@async.async.caltech.edu> <20100418074927.934461A2117@async.async.caltech.edu> <04EB7FF8-D304-428D-839E-233FCE009C98@cs.purdue.edu> <20100418195901.CDACB1A20F6@async.async.caltech.edu> <20100419172313.68B241A20D6@async.async.caltech.edu> Message-ID: <4F3EE437-0298-410B-9642-C0381E333430@cs.purdue.edu> On 19 Apr 2010, at 13:23, Mika Nystrom wrote: > > Well *my* problem is that I still use PM3 for a lot of things. Trying to > switch to CM3, yes, but I can't "certify" CM3 for critical stuff yet. > > So I'm maintaining a significant amount of code that needs to compile > under both PM3 and CM3. Two problems crop up. > > 1. If there are bugs in m3tk/stubgen, the fixes only apply to one or > the other version of m3tk/stubgen. > > 2. Some of the code I'm maintaining processes Modula-3 code as input. > It needs to be in two versions. > > In this kind of environment, programming languages don't really > evolve, since the system depends on their being both forward- and > backward-compatible. They "change" is more correct. The way Java > changes. Indeed: Growing a Language, by Guy Steele > > More in general, though, Modula-3's designers were clearly well acquainted > with C, Fortran, and other languages that provide different-range > integers. They chose not to indulge. I even have a version of Modula-3 > for a 16-bit machine that doesn't do it, even though on this machine the > need for a 32-bit integer is arguably greater than the need for 64-bit > integers on 32-bit machines. Now we indulge in this language complication > to solve what is clearly a temporary problem, since anyone who cares > about large problems is going to have 64-bit systems yesterday... and > meanwhile no one seems to have availed himself of the solution! If we were to revert, I have no idea what the implications would be. Jay? > My worst fear is that once the process gets started, the reason for > staying with the original Green-Book specification has now been defeated > and we will see more and more "evolution". Trying to actually build > systems that process Modula-3 like data becomes, at that point, like > trying to stand in quicksand. Indeed! > > I'm not incredibly picky here... I just hope it doesn't go further. > I would personally support either sticking with the current status quo > or going back to the Green Book w.r.t. integers and characters. Indeed, I would not want to see this go any further. I am still not sure I am comfortable with the LONGINT extension (even though I put a lot of time into it). There just seemed to be a lot of pressure for it to so CM3 could handle large file indexes. I've never been convinced that WIDECHAR was a winner either -- it was a reflexive action in the face of Java's Unicode. The CM3 people were building a Java VM above CM3 at the time. > > Saying that EWD wasn't renowned for his practicality is something he > would have taken as a great compliment, I'm sure. ;-) > > Mika > > Tony Hosking writes: >> Mika, >> >> First off, I'd be very interested to know what the issues are with = >> LONGINT and stubgen. We are building that every day in regression = >> testing. It would be really good to get some precise feedback. >> >> True, LONGINT is integrated with all of the language tools (same as = >> WIDECHAR). >> >> I suppose that is the price we pay for the language having evolved. = >> Nevertheless, CM3 should be totally backward compatible with the green = >> book. There is no reason it should not build packages from PM3 or SRC. >> >> Now, this is not to say that perhaps we haven't overreached with LONGINT = >> given that 64-bit is more prevalent. But then it is also useful to be = >> able to interoperate with C libraries. The previous interfacing was = >> pretty much a kludge, using ARRAY[0..1] OF INTEGER for "long long" but = >> then not propagating the double INTEGER value properly throughout the = >> Modula-3 libraries. >> >> I'm sorry to say that EWD was not particularly renowned for his = >> practicality; pedant more like. Nice to be high and mighty but we also = >> need to interact with the real world. >> >> We should be able to make this work. Is there a better alternative? = >> Revoke LONGINT, and WIDECHAR? >> >> On 18 Apr 2010, at 15:59, Mika Nystrom wrote: >> >>> =20 >>> My problem is really just that it's ugly. LONGx is showing up as an = >> issue >>> in all sorts of low-level code, which is not surprising since Modula-3 >>> with LONGx is not the same language as Modula-3 (maybe we should call >>> it Modula-3+?)=20 >>> =20 >>> The compiler bootstrapping process has gotten more complicated due to = >> it, >>> and when I cvs updated m3tk yesterday stubgen wouldn't compile because = >> there >>> was something "long" in it that wasn't there before. I have no idea = >> what >>> library or components I needed to update and recompile and didn't have = >> the >>> time to deal with the issue at the time. >>> =20 >>> And the new m3tk, stubgen, and compiler(?) won't compile using PM3 or >>> SRC M3 since we're no longer using the language of the Green Book. >>> (Same comment goes for WIDECHAR, by the way.) >>> =20 >>> One of the wonderful things about Modula-3 *used to be* that I could >>> grab some old package from DECSRC and just use it without changes = >> since >>> no one had messed with the language definition. This is still true as >>> far as programs that just use the tools go, but it's no longer true = >> for >>> programs that process Modula-3 code as input data. Of which there are >>> more than a few: many aspects of Modula-3 were specifically designed = >> to >>> make the language easy to process by program, as an intermediate = >> format >>> and whatnot. >>> =20 >>> To quote E.W.D.: >>> =20 >>> 'Unfathomed misunderstanding is further revealed by the term "software >>> maintenance", as a result of which many people continue to believe = >> that >>> programs and even programming languages themselves are subject to wear >>> and tear. Your car needs maintenance too, doesn't it? Famous is the = >> story >>> of the oil company that believed that its PASCAL programs did not last >>> as long as its FORTRAN programs "because PASCAL was not maintained".' >>> =20 >>> LONGx is causing me to have to do "software maintenance" on Modula-3 >>> programs... for a feature that no one appears to be using and is = >> quickly >>> becoming irrelevant. >>> =20 >>> Mika >>> =20 >>> =20 >>> Tony Hosking writes: >>>> In the language spec NUMBER(a) and LAST(a) - FIRST(a) + 1 are *not* =3D= >> >>>> defined to mean the same thing for all types. >>>> NUMBER does have an INTEGER value, as expected for subranges of = >> LONGINT =3D >>>> that are not too large. >>>> This is as it has always been for subranges of INTEGER that are not = >> too =3D >>>> large. >>>> =20 >>>> Mika, I'm not sure I see any of the problems you are worrying about = >> in =3D >>>> the current definition of LONGINT/LONGCARD. >>>> =20 >>>> On 18 Apr 2010, at 03:49, Mika Nystrom wrote: >>>> =20 >>>>> =3D20 >>>>> Jay I know most of this, and it doesn't really answer the question >>>>> "what is it for?" >>>>> =3D20 >>>>> I think we've already established that LONGINT isn't useful for =3D >>>> counting >>>>> anything that might actually reside in the computer's memory: it = >> makes >>>>> no sense as an array index, for instance. INTEGER suffices for = >> that. >>>>> =3D20 >>>>> I thought that the only real reason for LONGINT was to match C's >>>>> declaration of various seek-related routines on 32-bit machines. >>>>> That's not a very good reason. >>>>> =3D20 >>>>> C++ succeeds because it does very well in the area(s) it is good at. >>>>> People who want to program in C++ will clearly program in C++, not >>>>> Modula-3. Modula-3 is never, ever going to be the language of = >> choice =3D >>>> for >>>>> people who want lots of snazzy infix operators. Modula-3 is = >> supposed =3D >>>> to >>>>> be a language with about as powerful semantics as C++ and an = >> extremely >>>>> simple syntax and definition---snazzy infix is one of the things you >>>>> give up for that. I don't see how LONGINT fits into this picture. >>>>> Now we have LONGCARD too? And it's infected the definitions >>>>> of FIRST and LAST? But not NUMBER... argh! >>>>> =3D20 >>>>> so, >>>>> =3D20 >>>>> NUMBER(a) and LAST(a) - FIRST(a) + 1 >>>>> =3D20 >>>>> no longer mean the same thing? Are we going to see lots of comments >>>>> in generics in the future where it says T may not be an open array >>>>> type nor an array type indexed on LONGINT or a subrange thereof? >>>>> =3D20 >>>>> Your comments about different parameter-passing techniques was what = >> I =3D >>>> was >>>>> trying to address with my suggestion to have a pragma for = >> this---just =3D >>>> to >>>>> match C (and Fortran?), of course. Name me a single Modula-3 =3D >>>> programmer >>>>> who cares in what order the bits in his parameters are pushed on the >>>>> stack in a Modula-3-to-Modula-3 call. >>>>> =3D20 >>>>> And I am definitely in that school of thought that says that =3D >>>> programming >>>>> languages should not "evolve". Better to leave well enough alone. >>>>> =3D20 >>>>> How much Modula-3 code has been written that uses LONGINT? Other = >> than >>>>> to talk to C? I've certainly never used it. >>>>> =3D20 >>>>> Mika >>>>> =3D20 >>>>> =3D20 >>>>> =3D20 >>>>> Jay K writes: >>>>>> --_264cb69b-0215-44c3-807c-8b4d8ea0ea59_ >>>>>> Content-Type: text/plain; charset=3D3D"iso-8859-1" >>>>>> Content-Transfer-Encoding: quoted-printable >>>>>> =3D20 >>>>>> =3D20 >>>>>> TYPE LONGINT =3D3D3D ARRAY [0..1] OF INTEGER on a 32bit system is = >> very =3D >>>> close to=3D3D >>>>>> LONGINT. >>>>>> =3D20 >>>>>> Plus treating it opaquely and providing a bunch of functions to =3D >>>> operate on=3D3D >>>>>> it. >>>>>> =3D20 >>>>>> Just as well therefore could be RECORD hi=3D3D2Clo:LONGINT END (see = >> =3D >>>> LARGE_INTE=3D3D >>>>>> GER and ULARGE_INTEGER in winnt.h) >>>>>> =3D20 >>>>>> =3D3D20 >>>>>> =3D20 >>>>>> Differences that come to mind: >>>>>> =3D20 >>>>>> infix operators <=3D3D3D=3D3D3D=3D3D3D=3D3D20 >>>>>> =3D20 >>>>>> possibly passed differently as a parameter >>>>>> =3D20 >>>>>> or returned differently as a result >>>>>> =3D20 >>>>>> ie. probably "directly compatible with" "long long"=3D3D2C passed = >> by =3D >>>> value (o=3D3D >>>>>> f course you could always pass by pointer and achieve = >> compatibilitity =3D >>>> trivi=3D3D >>>>>> ally) >>>>>> =3D20 >>>>>> =3D3D20 >>>>>> =3D20 >>>>>> =3D3D20 >>>>>> =3D20 >>>>>> I have to say though=3D3D2C the biggest reason is in-fix operators. = >> =3D >>>> Convenient =3D3D >>>>>> syntax. >>>>>> =3D20 >>>>>> C++ is the best and some way worst of example of the general right = >> =3D >>>> way to d=3D3D >>>>>> o this -- you let programmers define types and their infix = >> operators. =3D >>>> Other=3D3D >>>>>> languages just come with a passle of special cases of types that = >> have =3D >>>> in-f=3D3D >>>>>> ix operators. >>>>>> =3D20 >>>>>> A good example is that Java infix operator + on string=3D3D2C = >> besides =3D >>>> the vario=3D3D >>>>>> us integers=3D3D2C and nothing else. >>>>>> =3D20 >>>>>> =3D3D20 >>>>>> =3D20 >>>>>> =3D3D20 >>>>>> =3D20 >>>>>> I think C# lets you define operators=3D3D2C yet people don't = >> complain =3D >>>> that it i=3D3D >>>>>> s "a mess" as they do of C++. >>>>>> =3D20 >>>>>> I think Python does now too. >>>>>> =3D20 >>>>>> So it is feature growing in popularity among "mainstream" =3D >>>> languages=3D3D2C not =3D3D >>>>>> just C++. >>>>>> =3D20 >>>>>> C++ of course is extremely mainstream=3D3D2C but also a favorite =3D >>>> target. (ht=3D3D >>>>>> tp://www.relisoft.com/tools/CppCritic.html) >>>>>> =3D20 >>>>>> =3D3D20 >>>>>> =3D20 >>>>>> =3D3D20 >>>>>> =3D20 >>>>>> We also have subranges of LONGINT. >>>>>> =3D20 >>>>>> I'm not sure what the generalization of subranges are=3D3D2C = >> granted. >>>>>> =3D20 >>>>>> Maybe some sort of C++ template that takes constants in the = >> template =3D >>>> and d=3D3D >>>>>> oes range checks at runtime. Yeah=3D3D2C maybe. >>>>>> =3D20 >>>>>> =3D3D20 >>>>>> =3D20 >>>>>> =3D3D20 >>>>>> =3D20 >>>>>> And as you point out=3D3D2C convenient literal syntax. >>>>>> =3D20 >>>>>> =3D3D20 >>>>>> =3D20 >>>>>> =3D3D20 >>>>>> =3D20 >>>>>> People reasonably argue for library extension in place of language = >> =3D >>>> extensio=3D3D >>>>>> n=3D3D2C but that requires a language which is flexible enough to = >> write =3D >>>> librari=3D3D >>>>>> es with the desired interface=3D3D2C and so many languages don't = >> let =3D >>>> infix oper=3D3D >>>>>> ators be in a user-written library. >>>>>> =3D20 >>>>>> (There is a subtle but useless distinction here -- infix operators = >> =3D >>>> being in=3D3D >>>>>> libraries vs. "user-written" libraries. The infix set operations = >> for =3D >>>> examp=3D3D >>>>>> le are in a library=3D3D2C but not user-written=3D3D2C special=3D3D2C= >> the =3D >>>> compiler know=3D3D >>>>>> s about it.) >>>>>> =3D20 >>>>>> =3D3D20 >>>>>> =3D20 >>>>>>> that would perhaps not match how C handles "long long" on the same >>>>>>> platform (which is how=3D3D2C come to think of it?)=3D3D2C and = >> that =3D >>>> would require >>>>>> =3D20 >>>>>> =3D20 >>>>>> =3D3D20 >>>>>> =3D20 >>>>>> On NT/x86=3D3D2C __int64/long long is returned in the register pair = >> =3D >>>> edx:eax. >>>>>> =3D20 >>>>>> edx is high=3D3D2C eax is low. >>>>>> =3D20 >>>>>> When passed as a parameter to __stdcall or __cdecl is just passed = >> as =3D >>>> two 32=3D3D >>>>>> bit values adjacent on the stack=3D3D2C "hi=3D3D2C lo=3D3D2C = >> hi=3D3D2C lo=3D3D2C =3D >>>> it's off to pu=3D3D >>>>> sh we go" is the Snow White-influenced mantra to remember how to = >> pass =3D >>>> them=3D3D >>>>>> =3D3D2C at least on little endian stack-growing-down machines = >> (which =3D >>>> includes x=3D3D >>>>>> 86). For __fastcall I'm not sure they are passed in registers or on = >> =3D >>>> the sta=3D3D >>>>>> ck. >>>>>> =3D20 >>>>>> Passing and/or returning small structs also has special efficient =3D= >> >>>> handling =3D3D >>>>>> in the ABI=3D3D2C so __int64 really might be equivalent to a small = >> =3D >>>> record. Not =3D3D >>>>>> that cm3 necessarily implements that "correctly" -- for interop = >> with =3D >>>> C=3D3D3B =3D3D >>>>>> for Modula-3 calling Modula-3 we can make up our own ABI so there =3D= >> >>>> isn't rea=3D3D >>>>>> lly an "incorrect" way. Notice the mingw problem I had passing a =3D >>>> Win32 poin=3D3D >>>>>> t struct by value=3D3D2C I cheated and passed it by VAR to a C = >> wrapper =3D >>>> to worka=3D3D >>>>>> round the gcc backend bug (which was mentioned a few times and = >> which =3D >>>> I look=3D3D >>>>>> ed into the code for=3D3D2C but took the easy route) >>>>>> =3D20 >>>>>> =3D3D20 >>>>>> =3D20 >>>>>> =3D3D20 >>>>>> =3D20 >>>>>> I don't know how long long works on other platforms but probably =3D >>>> similar. >>>>>> =3D20 >>>>>> Probably a certain register pair for return values. >>>>>> =3D20 >>>>>> =3D3D20 >>>>>> =3D20 >>>>>> - Jay >>>>>> =3D20 >>>>>> =3D3D20 >>>>>>> To: hosking at cs.purdue.edu >>>>>>> Date: Sat=3D3D2C 17 Apr 2010 19:47:03 -0700 >>>>>>> From: mika at async.async.caltech.edu >>>>>>> CC: m3devel at elegosoft.com >>>>>>> Subject: Re: [M3devel] INTEGER >>>>>>> =3D3D20 >>>>>>> Tony Hosking writes: >>>>>>>> =3D20 >>>>>>> ... >>>>>>>> =3D20 >>>>>>>>> We need it to match 64-bit integers on 32-bit machines? That = >> seems =3D >>>> =3D3D3D >>>>>>>> like >>>>>>>>> a very weak rationale indeed=3D3D2C if the same functionality = >> could =3D >>>> be =3D3D3D >>>>>>>> provided >>>>>>>>> through some other mechanism (e.g.=3D3D2C ARRAY [0..1] OF =3D >>>> INTEGER---even =3D3D >>>>>> =3D3D3D >>>>>>>> with >>>>>>>>> a pragma e.g. <*CLONGLONG*>.. if it is necessary to tell the =3D >>>> compiler =3D3D >>>>>> =3D3D3D >>>>>>>> that >>>>>>>>> a special linkage convention is needed). >>>>>>>> =3D20 >>>>>>>> There's no special linkage convention. Not sure what you mean = >> here. >>>>>>>> =3D20 >>>>>>> =3D3D20 >>>>>>> I just mean if we had >>>>>>> =3D3D20 >>>>>>> TYPE LONGINT =3D3D3D ARRAY [0..1] OF INTEGER >>>>>>> =3D3D20 >>>>>>> that would perhaps not match how C handles "long long" on the same >>>>>>> platform (which is how=3D3D2C come to think of it?)=3D3D2C and = >> that =3D >>>> would require >>>>>>> special linkage tricks. >>>>>>> =3D3D20 >>>>>>> But what would be lost? The ability to type literals.=3D3D20 >>>>>>> =3D3D20 >>>>>>> You could get the same code interface on 32- and 64-bit machine by >>>>>>> defining >>>>>>> =3D3D20 >>>>>>> TYPE FileOffset =3D3D3D ARRAY[0..1] OF [-16_80000000 .. = >> +16_7fffffff ] >>>>>>> =3D3D20 >>>>>>> and using that. >>>>>>> =3D3D20 >>>>>>> =3D3D20 >>>>>>> Mika >>>>>> =3D3D >>>>>> =3D20 >>>>>> --_264cb69b-0215-44c3-807c-8b4d8ea0ea59_ >>>>>> Content-Type: text/html; charset=3D3D"iso-8859-1" >>>>>> Content-Transfer-Encoding: quoted-printable >>>>>> =3D20 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> TYPE LONGINT =3D3D3D ARRAY [0..1] OF INTEGER on a =3D3D3B32bit = >> system =3D >>>> is very c=3D3D >>>>>> lose to LONGINT.
>>>>>>  =3D3D3BPlus treating it opaquely and providing a bunch of =3D >>>> functions to ope=3D3D >>>>>> rate on it.
>>>>>>  =3D3D3BJust as well therefore could be RECORD = >> hi=3D3D2Clo:LONGINT =3D >>>> END (see LAR=3D3D >>>>>> GE_INTEGER and ULARGE_INTEGER in winnt.h)
>>>>>>  =3D3D3B
>>>>>> Differences that come to mind:
>>>>>>  =3D3D3B =3D3D3Binfix operators =3D3D3B = >> <=3D3D3B=3D3D3D=3D3D3D=3D3D3D =3D >>>>
>>>>>>  =3D3D3B possibly passed differently =3D3D3Bas a = >> parameter
>>>>>>  =3D3D3B or returned differently as a result
>>>>>>  =3D3D3B ie. probably "directly compatible with" "long = >> long"=3D3D2C =3D >>>> passed by v=3D3D >>>>>> alue (of course you could always pass by pointer and achieve =3D >>>> compatibilitit=3D3D >>>>>> y trivially)
>>>>>>  =3D3D3B
>>>>>>  =3D3D3B
>>>>>> I have to say though=3D3D2C the biggest reason is in-fix operators. = >> =3D >>>> Convenient =3D3D >>>>>> syntax.
>>>>>> C++ is the best and some way worst of example of the general right = >> =3D >>>> way to d=3D3D >>>>>> o this -- you let programmers define types and their infix = >> operators. =3D >>>> Other=3D3D >>>>>> languages just come with a passle of special cases of types that = >> have =3D >>>> in-f=3D3D >>>>>> ix operators.
>>>>>> A good example is that Java infix operator + on string=3D3D2C = >> besides =3D >>>> the vario=3D3D >>>>>> us integers=3D3D2C and nothing else.
>>>>>>  =3D3D3B
>>>>>>  =3D3D3B
>>>>>> I think C# lets you define operators=3D3D2C yet people don't = >> complain =3D >>>> that it i=3D3D >>>>>> s "a mess" as they do of C++.
>>>>>> I think Python does now too.
>>>>>> So it is feature growing in popularity among "mainstream" =3D >>>> languages=3D3D2C not =3D3D >>>>>> just C++.
>>>>>>  =3D3D3B =3D3D3B C++ of course is extremely mainstream=3D3D2C= >> but =3D >>>> also a favori=3D3D >>>>>> te target. (>>> href=3D3D3D"http://www.relisoft.com/tools/CppCritic.html">http:/=3D3D >>>>>> /www.relisoft.com/tools/CppCritic.html)
>>>>>>  =3D3D3B
>>>>>>  =3D3D3B
>>>>>> We also have subranges of LONGINT.
>>>>>> I'm not sure what the generalization of subranges are=3D3D2C =3D >>>> granted.
>>>>>>  =3D3D3BMaybe some sort of C++ template that takes constants in = >> the =3D >>>> templat=3D3D >>>>>> e and does range checks at runtime. Yeah=3D3D2C maybe.
>>>>>>  =3D3D3B
>>>>>>  =3D3D3B
>>>>>> And as you point out=3D3D2C convenient literal syntax.
>>>>>>  =3D3D3B
>>>>>>  =3D3D3B
>>>>>> People reasonably argue for library extension in place of language = >> =3D >>>> extensio=3D3D >>>>>> n=3D3D2C but that requires a language which is flexible enough to = >> write =3D >>>> librari=3D3D >>>>>> es with the desired interface=3D3D2C and so many languages don't = >> let =3D >>>> infix oper=3D3D >>>>>> ators be in a user-written library.
>>>>>> (There is a subtle but useless distinction here -- infix operators = >> =3D >>>> being in=3D3D >>>>>> libraries vs. "user-written" libraries. The infix set operations = >> for =3D >>>> examp=3D3D >>>>>> le are in a library=3D3D2C but not user-written=3D3D2C special=3D3D2C= >> the =3D >>>> compiler know=3D3D >>>>>> s about it.)
>>>>>>  =3D3D3B
>>>>>> >=3D3D3B that would perhaps not match how C handles "long long" = >> on =3D >>>> the same>>>>> R>>=3D3D3B platform (which is how=3D3D2C come to think of = >> it?)=3D3D2C and =3D >>>> that would =3D3D >>>>>> require

>>>>>>  =3D3D3B
>>>>>> On NT/x86=3D3D2C __int64/long long is returned in the register pair = >> =3D >>>> edx:eax.>>>>>> =3D20 >>>>>> edx is high=3D3D2C eax is low.
>>>>>> When passed as a parameter to __stdcall or __cdecl is just passed = >> as =3D >>>> two 32=3D3D >>>>>> bit values adjacent on the stack=3D3D2C "hi=3D3D2C lo=3D3D2C = >> hi=3D3D2C lo=3D3D2C =3D >>>> it's off to pu=3D3D >>>>>> sh we go" is the Snow White-influenced mantra to remember how to = >> pass =3D >>>> them=3D3D >>>>>> =3D3D2C at least on little endian stack-growing-down machines = >> (which =3D >>>> includes x=3D3D >>>>>> 86). For __fastcall I'm not sure they are passed in registers or on = >> =3D >>>> the sta=3D3D >>>>>> ck.
>>>>>> Passing and/or returning small structs also has special efficient =3D= >> >>>> handling =3D3D >>>>>> in the ABI=3D3D2C so __int64 really might be equivalent to a small = >> =3D >>>> record. Not =3D3D >>>>>> that cm3 necessarily implements that "correctly" =3D3D3B -- for = >> =3D >>>> interop wit=3D3D >>>>>> h C=3D3D3B for Modula-3 calling Modula-3 we can make up our own ABI = >> so =3D >>>> there is=3D3D >>>>>> n't =3D3D3Breally an "incorrect" way. =3D3D3BNotice the = >> mingw =3D >>>> problem I had=3D3D >>>>>> passing a Win32 point struct by value=3D3D2C I cheated and passed = >> it by =3D >>>> VAR to=3D3D >>>>>> a =3D3D3BC wrapper to workaround the gcc backend bug (which was = >> =3D >>>> mentioned =3D3D >>>>>> a few times and which I looked into the code for=3D3D2C but took = >> the =3D >>>> easy route=3D3D >>>>>> )
>>>>>>  =3D3D3B
>>>>>>  =3D3D3B
>>>>>> I don't know how long long works on other platforms but probably =3D >>>> similar.>>>>> R> >>>>>> Probably a certain register pair for return values.
>>>>>>  =3D3D3B
>>>>>>  =3D3D3B- Jay

 =3D3D3B
>=3D3D3B To: =3D >>>> hosking at cs.purdue.edu
>=3D3D3B=3D3D >>>>>> Date: Sat=3D3D2C 17 Apr 2010 19:47:03 -0700
>=3D3D3B From: =3D >>>> mika at async.async.c=3D3D >>>>>> altech.edu
>=3D3D3B CC: m3devel at elegosoft.com
>=3D3D3B = >> Subject: =3D >>>> Re: [M3de=3D3D >>>>>> vel] INTEGER
>=3D3D3B
>=3D3D3B Tony Hosking = >> writes:
>=3D3D3B =3D >>>> >=3D3D3B
=3D3D >>>>>> >=3D3D3B ...
>=3D3D3B >=3D3D3B
>=3D3D3B = >> >=3D3D3B>=3D3D3B We =3D >>>> need it to match 64-b=3D3D >>>>>> it integers on 32-bit machines? That seems =3D3D3D
>=3D3D3B =3D >>>> >=3D3D3Blike
>=3D3D >>>>>> =3D3D3B >=3D3D3B>=3D3D3B a very weak rationale indeed=3D3D2C if = >> the same =3D >>>> functionality =3D3D >>>>>> could be =3D3D3D
>=3D3D3B >=3D3D3Bprovided
>=3D3D3B = >> >=3D3D3B>=3D3D3=3D >>>> B through some o=3D3D >>>>>> ther mechanism (e.g.=3D3D2C ARRAY [0..1] OF INTEGER---even =3D >>>> =3D3D3D
>=3D3D3B >=3D3D3B=3D3D >>>>>> with
>=3D3D3B >=3D3D3B>=3D3D3B a pragma e.g. =3D >>>> <=3D3D3B*CLONGLONG*>=3D3D3B.. if it i=3D3D >>>>>> s necessary to tell the compiler =3D3D3D
>=3D3D3B =3D >>>> >=3D3D3Bthat
>=3D3D3B >=3D3D3B&=3D3D >>>>>> gt=3D3D3B a special linkage convention is needed).
>=3D3D3B =3D >>>> >=3D3D3B
>=3D3D3B &=3D3D >>>>>> gt=3D3D3BThere's no special linkage convention. Not sure what you = >> mean =3D >>>> here.>>>>>> >=3D3D3B >=3D3D3B
>=3D3D3B
>=3D3D3B I just mean if = >> we =3D >>>> had
>=3D3D3B
>=3D3D >>>>>> =3D3D3B TYPE LONGINT =3D3D3D ARRAY [0..1] OF INTEGER
>=3D3D3B = >> =3D >>>>
>=3D3D3B that woul=3D3D >>>>>> d perhaps not match how C handles "long long" on the = >> same
>=3D3D3B =3D >>>> platfor=3D3D >>>>>> m (which is how=3D3D2C come to think of it?)=3D3D2C and that would = >> =3D >>>> require
>=3D3D >>>>>> =3D3D3B special linkage tricks.
>=3D3D3B
>=3D3D3B But = >> what would =3D >>>> be lost? Th=3D3D >>>>>> e ability to type literals.
>=3D3D3B
>=3D3D3B You could = >> get =3D >>>> the same co=3D3D >>>>>> de interface on 32- and 64-bit machine by
>=3D3D3B =3D >>>> defining
>=3D3D3B
=3D3D >>>>>> >=3D3D3B TYPE FileOffset =3D3D3D ARRAY[0..1] OF [-16_80000000 .. = >> =3D >>>> +16_7fffffff ]>>>>> R>>=3D3D3B
>=3D3D3B and using that.
>=3D3D3B = >>
>=3D3D3B =3D >>>>
>=3D3D3B Mika>>>>>> >>>>>> =3D3D >>>>>> =3D20 >>>>>> --_264cb69b-0215-44c3-807c-8b4d8ea0ea59_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Mon Apr 19 17:48:02 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 19 Apr 2010 11:48:02 -0400 Subject: [M3devel] INTEGER In-Reply-To: <4F3EE437-0298-410B-9642-C0381E333430@cs.purdue.edu> References: <20100418024703.6965B1A2103@async.async.caltech.edu> <20100418074927.934461A2117@async.async.caltech.edu> <04EB7FF8-D304-428D-839E-233FCE009C98@cs.purdue.edu> <20100418195901.CDACB1A20F6@async.async.caltech.edu> <20100419172313.68B241A20D6@async.async.caltech.edu> <4F3EE437-0298-410B-9642-C0381E333430@cs.purdue.edu> Message-ID: <20100419154802.GA8759@topoi.pooq.com> On Mon, Apr 19, 2010 at 02:44:00PM -0400, Tony Hosking wrote: > > > On 19 Apr 2010, at 13:23, Mika Nystrom wrote: > > > > > Well *my* problem is that I still use PM3 for a lot of things. Trying to > > switch to CM3, yes, but I can't "certify" CM3 for critical stuff yet. > > > > So I'm maintaining a significant amount of code that needs to compile > > under both PM3 and CM3. Two problems crop up. > > > > 1. If there are bugs in m3tk/stubgen, the fixes only apply to one or > > the other version of m3tk/stubgen. > > > > 2. Some of the code I'm maintaining processes Modula-3 code as input. > > It needs to be in two versions. > > > > In this kind of environment, programming languages don't really > > evolve, since the system depends on their being both forward- and > > backward-compatible. They "change" is more correct. The way Java > > changes. > > Indeed: Growing a Language, by Guy Steele > > > > > More in general, though, Modula-3's designers were clearly well acquainted > > with C, Fortran, and other languages that provide different-range > > integers. They chose not to indulge. I even have a version of Modula-3 > > for a 16-bit machine that doesn't do it, even though on this machine the > > need for a 32-bit integer is arguably greater than the need for 64-bit > > integers on 32-bit machines. Now we indulge in this language complication > > to solve what is clearly a temporary problem, since anyone who cares > > about large problems is going to have 64-bit systems yesterday... and > > meanwhile no one seems to have availed himself of the solution! > > If we were to revert, I have no idea what the implications would be. Jay? > > > My worst fear is that once the process gets started, the reason for > > staying with the original Green-Book specification has now been defeated > > and we will see more and more "evolution". Trying to actually build > > systems that process Modula-3 like data becomes, at that point, like > > trying to stand in quicksand. > > Indeed! > > > > > I'm not incredibly picky here... I just hope it doesn't go further. > > I would personally support either sticking with the current status quo > > or going back to the Green Book w.r.t. integers and characters. > > Indeed, I would not want to see this go any further. I am still not > sure I am comfortable with the LONGINT extension (even though I put a > lot of time into it). There just seemed to be a lot of pressure for > it to so CM3 could handle large file indexes. I've never been > convinced that WIDECHAR was a winner either -- it was a reflexive > action in the face of Java's Unicode. The CM3 people were building a > Java VM above CM3 at the time. The LONGINT problem has several causes: (1) INTEGER being defined as the largest integer type in the language. (2) INTEGER being implemented as a specific fixed-size type that can be implemented "efficiently", whatever that means. (3) The world of Modula 3 programmers using INTEGER whenever they didn't want to worry about what actual range they needed. These three facts make it difficult to implement integer types that are larger than the ones that are "efficient" on the hardware. In my opinion it was a mistake to define the "efficient" integer type to necessarily be the "largest" integer type. It was this that made it necessary to invent a new type hierarchy of LONGINTs, which are not necessarily implemented efficiently. But I see no need to make the largest type in this hierarchy explicitly available to the programmer. It is possible to have only subranges of LONGINT available, and it is possible to track the maximum values achievable with arithmetic operations, and thus determine the subranges needed for intermediate results. Had we left LONGINT unconstrained, we could have had the simple rule: use INTEGER if efficiency is more important thatn correctness (or you know you'll be in-range), use LONGINT otherwise. Doing that thoroughly would have required some compiler energetics. Still, the necessaries could all have been done statically, without causing any further grief the day a third length of integer is needed. I have no idea whether that day will ever arrive, but it seems foolish to design the language in such a way as to make that day difficult to accomodate. My druthers would have been to have more-or-less the present LONGINT, but restrict programmers to use only subtypes of it. If there is to be a maximum LONGINT value (possibly as an implementation reastriciton), overflowing past it must be checked. -- hendrik > > > > > Saying that EWD wasn't renowned for his practicality is something he > > would have taken as a great compliment, I'm sure. > > ;-) > Actually, I kind of suspect he thought he *was* being practical. -- hendrik From hendrik at topoi.pooq.com Mon Apr 19 17:57:02 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 19 Apr 2010 11:57:02 -0400 Subject: [M3devel] INTEGER In-Reply-To: <20100418195901.CDACB1A20F6@async.async.caltech.edu> References: <20100418024703.6965B1A2103@async.async.caltech.edu> <20100418074927.934461A2117@async.async.caltech.edu> <04EB7FF8-D304-428D-839E-233FCE009C98@cs.purdue.edu> <20100418195901.CDACB1A20F6@async.async.caltech.edu> Message-ID: <20100419155702.GB8759@topoi.pooq.com> On Sun, Apr 18, 2010 at 12:59:01PM -0700, Mika Nystrom wrote: > > And the new m3tk, stubgen, and compiler(?) won't compile using PM3 or > SRC M3 since we're no longer using the language of the Green Book. > (Same comment goes for WIDECHAR, by the way.) When I use Unicode characters, I find myself defining them to be INTEGERs, because I'm always worried that WIDECHARs might be omly 16 bits. Strings of WIDECHARS are probably unnecesary. The last program I wrote that used Unicode used INTEGERs for characters, and arrays of INTEGERS for strings. But I think it was a mistake to do it this way, and when I have time I'll rewrite it. UTF-8 seems to be the way to go; strings of Unicode can easily be manipulated as ordinary TEXT. In fact, I think there are few if any places in my code where I would have had to do anything special whatsoever if I had just used UTF8 in TEXT. The program would simply become simpler. -- hendrik From jay.krell at cornell.edu Mon Apr 19 23:20:00 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 19 Apr 2010 21:20:00 +0000 Subject: [M3devel] INTEGER In-Reply-To: <20100419155702.GB8759@topoi.pooq.com> References: <20100418024703.6965B1A2103@async.async.caltech.edu>, , <20100418074927.934461A2117@async.async.caltech.edu>, <04EB7FF8-D304-428D-839E-233FCE009C98@cs.purdue.edu>, <20100418195901.CDACB1A20F6@async.async.caltech.edu>, <20100419155702.GB8759@topoi.pooq.com> Message-ID: For the record, anyone using Windows (NT/2000/XP/2003/etc.) is using 16bit characters *all the time*. MacOSX maybe also. I think utf8 is kind of a hack to let folks get away without really doing anything. Granted, I didn't realize till recently that strcmp works on utf8..maybe a really clever idea.. - Jay > Date: Mon, 19 Apr 2010 11:57:02 -0400 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] INTEGER > > On Sun, Apr 18, 2010 at 12:59:01PM -0700, Mika Nystrom wrote: > > > > And the new m3tk, stubgen, and compiler(?) won't compile using PM3 or > > SRC M3 since we're no longer using the language of the Green Book. > > (Same comment goes for WIDECHAR, by the way.) > > When I use Unicode characters, I find myself defining them to be > INTEGERs, because I'm always worried that WIDECHARs might be omly 16 bits. > > Strings of WIDECHARS are probably unnecesary. The last program I wrote > that used Unicode used INTEGERs for characters, and arrays of INTEGERS > for strings. But I think it was a mistake to do it this way, and when I > have time I'll rewrite it. UTF-8 seems to be the way to go; strings of > Unicode can easily be manipulated as ordinary TEXT. In fact, I > think there are few if any places in my code where I would have had to > do anything special whatsoever if I had just used UTF8 in TEXT. The > program would simply become simpler. > > -- hendrik -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Apr 19 23:25:48 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 19 Apr 2010 21:25:48 +0000 Subject: [M3devel] INTEGER In-Reply-To: <4F3EE437-0298-410B-9642-C0381E333430@cs.purdue.edu> References: , , ,,<7C7408D0-9A40-4988-BADA-A9FD8C15D388@cs.purdue.edu>, ,,, , , , , , , , , <20100418023535.3BA9E1A2103@async.async.caltech.edu>, , , , <20100418024703.6965B1A2103@async.async.caltech.edu>, , <20100418074927.934461A2117@async.async.caltech.edu>, <04EB7FF8-D304-428D-839E-233FCE009C98@cs.purdue.edu>, <20100418195901.CDACB1A20F6@async.async.caltech.edu>, , <20100419172313.68B241A20D6@async.async.caltech.edu>, <4F3EE437-0298-410B-9642-C0381E333430@cs.purdue.edu> Message-ID: > If we were to revert, I have no idea what the implications would be. Jay? I'm sure we could cope. Besides, we'd put in a library-based solution anyway? That the compiler inlines? Like atomics? Let me suggest a small exercise though: I'm not going to do it. Write a program that copies files. Or just one file. "cp.exe". Have it print "progress feedback" to the user -- how many bytes and percentage copied. Leave out "time estimation". And also write "ls.exe". And maybe one last program, like "dos2unix.exe" or "fix_nl.exe" that alters newlines. This program should work on files that don't fit in memory. That is, get some experience working with files that don't fit in memory/address space. But also for which lots memory/address space really aren't needed. Also think about what an idea representation of time is. Isn't a 64bit integer number of units smaller than a second a very good one? And aren't infix operators darned nice? - Jay From: hosking at cs.purdue.edu Date: Mon, 19 Apr 2010 14:44:00 -0400 To: mika at async.async.caltech.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] INTEGER On 19 Apr 2010, at 13:23, Mika Nystrom wrote: Well *my* problem is that I still use PM3 for a lot of things. Trying to switch to CM3, yes, but I can't "certify" CM3 for critical stuff yet. So I'm maintaining a significant amount of code that needs to compile under both PM3 and CM3. Two problems crop up. 1. If there are bugs in m3tk/stubgen, the fixes only apply to one or the other version of m3tk/stubgen. 2. Some of the code I'm maintaining processes Modula-3 code as input. It needs to be in two versions. In this kind of environment, programming languages don't really evolve, since the system depends on their being both forward- and backward-compatible. They "change" is more correct. The way Java changes. Indeed: Growing a Language, by Guy Steele More in general, though, Modula-3's designers were clearly well acquainted with C, Fortran, and other languages that provide different-range integers. They chose not to indulge. I even have a version of Modula-3 for a 16-bit machine that doesn't do it, even though on this machine the need for a 32-bit integer is arguably greater than the need for 64-bit integers on 32-bit machines. Now we indulge in this language complication to solve what is clearly a temporary problem, since anyone who cares about large problems is going to have 64-bit systems yesterday... and meanwhile no one seems to have availed himself of the solution! If we were to revert, I have no idea what the implications would be. Jay? My worst fear is that once the process gets started, the reason for staying with the original Green-Book specification has now been defeated and we will see more and more "evolution". Trying to actually build systems that process Modula-3 like data becomes, at that point, like trying to stand in quicksand. Indeed! I'm not incredibly picky here... I just hope it doesn't go further. I would personally support either sticking with the current status quo or going back to the Green Book w.r.t. integers and characters. Indeed, I would not want to see this go any further. I am still not sure I am comfortable with the LONGINT extension (even though I put a lot of time into it). There just seemed to be a lot of pressure for it to so CM3 could handle large file indexes. I've never been convinced that WIDECHAR was a winner either -- it was a reflexive action in the face of Java's Unicode. The CM3 people were building a Java VM above CM3 at the time. Saying that EWD wasn't renowned for his practicality is something he would have taken as a great compliment, I'm sure. ;-) Mika Tony Hosking writes: Mika, First off, I'd be very interested to know what the issues are with = LONGINT and stubgen. We are building that every day in regression = testing. It would be really good to get some precise feedback. True, LONGINT is integrated with all of the language tools (same as = WIDECHAR). I suppose that is the price we pay for the language having evolved. = Nevertheless, CM3 should be totally backward compatible with the green = book. There is no reason it should not build packages from PM3 or SRC. Now, this is not to say that perhaps we haven't overreached with LONGINT = given that 64-bit is more prevalent. But then it is also useful to be = able to interoperate with C libraries. The previous interfacing was = pretty much a kludge, using ARRAY[0..1] OF INTEGER for "long long" but = then not propagating the double INTEGER value properly throughout the = Modula-3 libraries. I'm sorry to say that EWD was not particularly renowned for his = practicality; pedant more like. Nice to be high and mighty but we also = need to interact with the real world. We should be able to make this work. Is there a better alternative? = Revoke LONGINT, and WIDECHAR? On 18 Apr 2010, at 15:59, Mika Nystrom wrote: =20 My problem is really just that it's ugly. LONGx is showing up as an = issue in all sorts of low-level code, which is not surprising since Modula-3 with LONGx is not the same language as Modula-3 (maybe we should call it Modula-3+?)=20 =20 The compiler bootstrapping process has gotten more complicated due to = it, and when I cvs updated m3tk yesterday stubgen wouldn't compile because = there was something "long" in it that wasn't there before. I have no idea = what library or components I needed to update and recompile and didn't have = the time to deal with the issue at the time. =20 And the new m3tk, stubgen, and compiler(?) won't compile using PM3 or SRC M3 since we're no longer using the language of the Green Book. (Same comment goes for WIDECHAR, by the way.) =20 One of the wonderful things about Modula-3 *used to be* that I could grab some old package from DECSRC and just use it without changes = since no one had messed with the language definition. This is still true as far as programs that just use the tools go, but it's no longer true = for programs that process Modula-3 code as input data. Of which there are more than a few: many aspects of Modula-3 were specifically designed = to make the language easy to process by program, as an intermediate = format and whatnot. =20 To quote E.W.D.: =20 'Unfathomed misunderstanding is further revealed by the term "software maintenance", as a result of which many people continue to believe = that programs and even programming languages themselves are subject to wear and tear. Your car needs maintenance too, doesn't it? Famous is the = story of the oil company that believed that its PASCAL programs did not last as long as its FORTRAN programs "because PASCAL was not maintained".' =20 LONGx is causing me to have to do "software maintenance" on Modula-3 programs... for a feature that no one appears to be using and is = quickly becoming irrelevant. =20 Mika =20 =20 Tony Hosking writes: In the language spec NUMBER(a) and LAST(a) - FIRST(a) + 1 are *not* =3D= defined to mean the same thing for all types. NUMBER does have an INTEGER value, as expected for subranges of = LONGINT =3D that are not too large. This is as it has always been for subranges of INTEGER that are not = too =3D large. =20 Mika, I'm not sure I see any of the problems you are worrying about = in =3D the current definition of LONGINT/LONGCARD. =20 On 18 Apr 2010, at 03:49, Mika Nystrom wrote: =20 =3D20 Jay I know most of this, and it doesn't really answer the question "what is it for?" =3D20 I think we've already established that LONGINT isn't useful for =3D counting anything that might actually reside in the computer's memory: it = makes no sense as an array index, for instance. INTEGER suffices for = that. =3D20 I thought that the only real reason for LONGINT was to match C's declaration of various seek-related routines on 32-bit machines. That's not a very good reason. =3D20 C++ succeeds because it does very well in the area(s) it is good at. People who want to program in C++ will clearly program in C++, not Modula-3. Modula-3 is never, ever going to be the language of = choice =3D for people who want lots of snazzy infix operators. Modula-3 is = supposed =3D to be a language with about as powerful semantics as C++ and an = extremely simple syntax and definition---snazzy infix is one of the things you give up for that. I don't see how LONGINT fits into this picture. Now we have LONGCARD too? And it's infected the definitions of FIRST and LAST? But not NUMBER... argh! =3D20 so, =3D20 NUMBER(a) and LAST(a) - FIRST(a) + 1 =3D20 no longer mean the same thing? Are we going to see lots of comments in generics in the future where it says T may not be an open array type nor an array type indexed on LONGINT or a subrange thereof? =3D20 Your comments about different parameter-passing techniques was what = I =3D was trying to address with my suggestion to have a pragma for = this---just =3D to match C (and Fortran?), of course. Name me a single Modula-3 =3D programmer who cares in what order the bits in his parameters are pushed on the stack in a Modula-3-to-Modula-3 call. =3D20 And I am definitely in that school of thought that says that =3D programming languages should not "evolve". Better to leave well enough alone. =3D20 How much Modula-3 code has been written that uses LONGINT? Other = than to talk to C? I've certainly never used it. =3D20 Mika =3D20 =3D20 =3D20 Jay K writes: --_264cb69b-0215-44c3-807c-8b4d8ea0ea59_ Content-Type: text/plain; charset=3D3D"iso-8859-1" Content-Transfer-Encoding: quoted-printable =3D20 =3D20 TYPE LONGINT =3D3D3D ARRAY [0..1] OF INTEGER on a 32bit system is = very =3D close to=3D3D LONGINT. =3D20 Plus treating it opaquely and providing a bunch of functions to =3D operate on=3D3D it. =3D20 Just as well therefore could be RECORD hi=3D3D2Clo:LONGINT END (see = =3D LARGE_INTE=3D3D GER and ULARGE_INTEGER in winnt.h) =3D20 =3D3D20 =3D20 Differences that come to mind: =3D20 infix operators <=3D3D3D=3D3D3D=3D3D3D=3D3D20 =3D20 possibly passed differently as a parameter =3D20 or returned differently as a result =3D20 ie. probably "directly compatible with" "long long"=3D3D2C passed = by =3D value (o=3D3D f course you could always pass by pointer and achieve = compatibilitity =3D trivi=3D3D ally) =3D20 =3D3D20 =3D20 =3D3D20 =3D20 I have to say though=3D3D2C the biggest reason is in-fix operators. = =3D Convenient =3D3D syntax. =3D20 C++ is the best and some way worst of example of the general right = =3D way to d=3D3D o this -- you let programmers define types and their infix = operators. =3D Other=3D3D languages just come with a passle of special cases of types that = have =3D in-f=3D3D ix operators. =3D20 A good example is that Java infix operator + on string=3D3D2C = besides =3D the vario=3D3D us integers=3D3D2C and nothing else. =3D20 =3D3D20 =3D20 =3D3D20 =3D20 I think C# lets you define operators=3D3D2C yet people don't = complain =3D that it i=3D3D s "a mess" as they do of C++. =3D20 I think Python does now too. =3D20 So it is feature growing in popularity among "mainstream" =3D languages=3D3D2C not =3D3D just C++. =3D20 C++ of course is extremely mainstream=3D3D2C but also a favorite =3D target. (ht=3D3D tp://www.relisoft.com/tools/CppCritic.html) =3D20 =3D3D20 =3D20 =3D3D20 =3D20 We also have subranges of LONGINT. =3D20 I'm not sure what the generalization of subranges are=3D3D2C = granted. =3D20 Maybe some sort of C++ template that takes constants in the = template =3D and d=3D3D oes range checks at runtime. Yeah=3D3D2C maybe. =3D20 =3D3D20 =3D20 =3D3D20 =3D20 And as you point out=3D3D2C convenient literal syntax. =3D20 =3D3D20 =3D20 =3D3D20 =3D20 People reasonably argue for library extension in place of language = =3D extensio=3D3D n=3D3D2C but that requires a language which is flexible enough to = write =3D librari=3D3D es with the desired interface=3D3D2C and so many languages don't = let =3D infix oper=3D3D ators be in a user-written library. =3D20 (There is a subtle but useless distinction here -- infix operators = =3D being in=3D3D libraries vs. "user-written" libraries. The infix set operations = for =3D examp=3D3D le are in a library=3D3D2C but not user-written=3D3D2C special=3D3D2C= the =3D compiler know=3D3D s about it.) =3D20 =3D3D20 =3D20 that would perhaps not match how C handles "long long" on the same platform (which is how=3D3D2C come to think of it?)=3D3D2C and = that =3D would require =3D20 =3D20 =3D3D20 =3D20 On NT/x86=3D3D2C __int64/long long is returned in the register pair = =3D edx:eax. =3D20 edx is high=3D3D2C eax is low. =3D20 When passed as a parameter to __stdcall or __cdecl is just passed = as =3D two 32=3D3D bit values adjacent on the stack=3D3D2C "hi=3D3D2C lo=3D3D2C = hi=3D3D2C lo=3D3D2C =3D it's off to pu=3D3D sh we go" is the Snow White-influenced mantra to remember how to = pass =3D them=3D3D =3D3D2C at least on little endian stack-growing-down machines = (which =3D includes x=3D3D 86). For __fastcall I'm not sure they are passed in registers or on = =3D the sta=3D3D ck. =3D20 Passing and/or returning small structs also has special efficient =3D= handling =3D3D in the ABI=3D3D2C so __int64 really might be equivalent to a small = =3D record. Not =3D3D that cm3 necessarily implements that "correctly" -- for interop = with =3D C=3D3D3B =3D3D for Modula-3 calling Modula-3 we can make up our own ABI so there =3D= isn't rea=3D3D lly an "incorrect" way. Notice the mingw problem I had passing a =3D Win32 poin=3D3D t struct by value=3D3D2C I cheated and passed it by VAR to a C = wrapper =3D to worka=3D3D round the gcc backend bug (which was mentioned a few times and = which =3D I look=3D3D ed into the code for=3D3D2C but took the easy route) =3D20 =3D3D20 =3D20 =3D3D20 =3D20 I don't know how long long works on other platforms but probably =3D similar. =3D20 Probably a certain register pair for return values. =3D20 =3D3D20 =3D20 - Jay =3D20 =3D3D20 To: hosking at cs.purdue.edu Date: Sat=3D3D2C 17 Apr 2010 19:47:03 -0700 From: mika at async.async.caltech.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] INTEGER =3D3D20 Tony Hosking writes: =3D20 ... =3D20 We need it to match 64-bit integers on 32-bit machines? That = seems =3D =3D3D3D like a very weak rationale indeed=3D3D2C if the same functionality = could =3D be =3D3D3D provided through some other mechanism (e.g.=3D3D2C ARRAY [0..1] OF =3D INTEGER---even =3D3D =3D3D3D with a pragma e.g. <*CLONGLONG*>.. if it is necessary to tell the =3D compiler =3D3D =3D3D3D that a special linkage convention is needed). =3D20 There's no special linkage convention. Not sure what you mean = here. =3D20 =3D3D20 I just mean if we had =3D3D20 TYPE LONGINT =3D3D3D ARRAY [0..1] OF INTEGER =3D3D20 that would perhaps not match how C handles "long long" on the same platform (which is how=3D3D2C come to think of it?)=3D3D2C and = that =3D would require special linkage tricks. =3D3D20 But what would be lost? The ability to type literals.=3D3D20 =3D3D20 You could get the same code interface on 32- and 64-bit machine by defining =3D3D20 TYPE FileOffset =3D3D3D ARRAY[0..1] OF [-16_80000000 .. = +16_7fffffff ] =3D3D20 and using that. =3D3D20 =3D3D20 Mika =3D3D =3D20 --_264cb69b-0215-44c3-807c-8b4d8ea0ea59_ Content-Type: text/html; charset=3D3D"iso-8859-1" Content-Transfer-Encoding: quoted-printable =3D20 TYPE LONGINT =3D3D3D ARRAY [0..1] OF INTEGER on a =3D3D3B32bit = system =3D is very c=3D3D lose to LONGINT.
 =3D3D3BPlus treating it opaquely and providing a bunch of =3D functions to ope=3D3D rate on it.
 =3D3D3BJust as well therefore could be RECORD = hi=3D3D2Clo:LONGINT =3D END (see LAR=3D3D GE_INTEGER and ULARGE_INTEGER in winnt.h)
 =3D3D3B
Differences that come to mind:
 =3D3D3B =3D3D3Binfix operators =3D3D3B = <=3D3D3B=3D3D3D=3D3D3D=3D3D3D =3D
 =3D3D3B possibly passed differently =3D3D3Bas a = parameter
 =3D3D3B or returned differently as a result
 =3D3D3B ie. probably "directly compatible with" "long = long"=3D3D2C =3D passed by v=3D3D alue (of course you could always pass by pointer and achieve =3D compatibilitit=3D3D y trivially)
 =3D3D3B
 =3D3D3B
I have to say though=3D3D2C the biggest reason is in-fix operators. = =3D Convenient =3D3D syntax.
C++ is the best and some way worst of example of the general right = =3D way to d=3D3D o this -- you let programmers define types and their infix = operators. =3D Other=3D3D languages just come with a passle of special cases of types that = have =3D in-f=3D3D ix operators.
A good example is that Java infix operator + on string=3D3D2C = besides =3D the vario=3D3D us integers=3D3D2C and nothing else.
 =3D3D3B
 =3D3D3B
I think C# lets you define operators=3D3D2C yet people don't = complain =3D that it i=3D3D s "a mess" as they do of C++.
I think Python does now too.
So it is feature growing in popularity among "mainstream" =3D languages=3D3D2C not =3D3D just C++.
 =3D3D3B =3D3D3B C++ of course is extremely mainstream=3D3D2C= but =3D also a favori=3D3D te target. (http:/=3D3D /www.relisoft.com/tools/CppCritic.html)
 =3D3D3B
 =3D3D3B
We also have subranges of LONGINT.
I'm not sure what the generalization of subranges are=3D3D2C =3D granted.
 =3D3D3BMaybe some sort of C++ template that takes constants in = the =3D templat=3D3D e and does range checks at runtime. Yeah=3D3D2C maybe.
 =3D3D3B
 =3D3D3B
And as you point out=3D3D2C convenient literal syntax.
 =3D3D3B
 =3D3D3B
People reasonably argue for library extension in place of language = =3D extensio=3D3D n=3D3D2C but that requires a language which is flexible enough to = write =3D librari=3D3D es with the desired interface=3D3D2C and so many languages don't = let =3D infix oper=3D3D ators be in a user-written library.
(There is a subtle but useless distinction here -- infix operators = =3D being in=3D3D libraries vs. "user-written" libraries. The infix set operations = for =3D examp=3D3D le are in a library=3D3D2C but not user-written=3D3D2C special=3D3D2C= the =3D compiler know=3D3D s about it.)
 =3D3D3B
>=3D3D3B that would perhaps not match how C handles "long long" = on =3D the same>=3D3D3B platform (which is how=3D3D2C come to think of = it?)=3D3D2C and =3D that would =3D3D require

 =3D3D3B
On NT/x86=3D3D2C __int64/long long is returned in the register pair = =3D edx:eax. When passed as a parameter to __stdcall or __cdecl is just passed = as =3D two 32=3D3D bit values adjacent on the stack=3D3D2C "hi=3D3D2C lo=3D3D2C = hi=3D3D2C lo=3D3D2C =3D it's off to pu=3D3D sh we go" is the Snow White-influenced mantra to remember how to = pass =3D them=3D3D =3D3D2C at least on little endian stack-growing-down machines = (which =3D includes x=3D3D 86). For __fastcall I'm not sure they are passed in registers or on = =3D the sta=3D3D ck.
Passing and/or returning small structs also has special efficient =3D= handling =3D3D in the ABI=3D3D2C so __int64 really might be equivalent to a small = =3D record. Not =3D3D that cm3 necessarily implements that "correctly" =3D3D3B -- for = =3D interop wit=3D3D h C=3D3D3B for Modula-3 calling Modula-3 we can make up our own ABI = so =3D there is=3D3D n't =3D3D3Breally an "incorrect" way. =3D3D3BNotice the = mingw =3D problem I had=3D3D passing a Win32 point struct by value=3D3D2C I cheated and passed = it by =3D VAR to=3D3D a =3D3D3BC wrapper to workaround the gcc backend bug (which was = =3D mentioned =3D3D a few times and which I looked into the code for=3D3D2C but took = the =3D easy route=3D3D )
 =3D3D3B
 =3D3D3B
I don't know how long long works on other platforms but probably =3D similar. Probably a certain register pair for return values.
 =3D3D3B
 =3D3D3B- Jay

 =3D3D3B
>=3D3D3B To: =3D hosking at cs.purdue.edu
>=3D3D3B=3D3D Date: Sat=3D3D2C 17 Apr 2010 19:47:03 -0700
>=3D3D3B From: =3D mika at async.async.c=3D3D altech.edu
>=3D3D3B CC: m3devel at elegosoft.com
>=3D3D3B = Subject: =3D Re: [M3de=3D3D vel] INTEGER
>=3D3D3B
>=3D3D3B Tony Hosking = writes:
>=3D3D3B =3D >=3D3D3B
=3D3D >=3D3D3B ...
>=3D3D3B >=3D3D3B
>=3D3D3B = >=3D3D3B>=3D3D3B We =3D need it to match 64-b=3D3D it integers on 32-bit machines? That seems =3D3D3D
>=3D3D3B =3D >=3D3D3Blike
>=3D3D =3D3D3B >=3D3D3B>=3D3D3B a very weak rationale indeed=3D3D2C if = the same =3D functionality =3D3D could be =3D3D3D
>=3D3D3B >=3D3D3Bprovided
>=3D3D3B = >=3D3D3B>=3D3D3=3D B through some o=3D3D ther mechanism (e.g.=3D3D2C ARRAY [0..1] OF INTEGER---even =3D =3D3D3D
>=3D3D3B >=3D3D3B=3D3D with
>=3D3D3B >=3D3D3B>=3D3D3B a pragma e.g. =3D <=3D3D3B*CLONGLONG*>=3D3D3B.. if it i=3D3D s necessary to tell the compiler =3D3D3D
>=3D3D3B =3D >=3D3D3Bthat
>=3D3D3B >=3D3D3B&=3D3D gt=3D3D3B a special linkage convention is needed).
>=3D3D3B =3D >=3D3D3B
>=3D3D3B &=3D3D gt=3D3D3BThere's no special linkage convention. Not sure what you = mean =3D here.>=3D3D3B
>=3D3D3B I just mean if = we =3D had
>=3D3D3B
>=3D3D =3D3D3B TYPE LONGINT =3D3D3D ARRAY [0..1] OF INTEGER
>=3D3D3B = =3D
>=3D3D3B that woul=3D3D d perhaps not match how C handles "long long" on the = same
>=3D3D3B =3D platfor=3D3D m (which is how=3D3D2C come to think of it?)=3D3D2C and that would = =3D require
>=3D3D =3D3D3B special linkage tricks.
>=3D3D3B
>=3D3D3B But = what would =3D be lost? Th=3D3D e ability to type literals.
>=3D3D3B
>=3D3D3B You could = get =3D the same co=3D3D de interface on 32- and 64-bit machine by
>=3D3D3B =3D defining
>=3D3D3B
=3D3D >=3D3D3B TYPE FileOffset =3D3D3D ARRAY[0..1] OF [-16_80000000 .. = =3D +16_7fffffff ]>=3D3D3B
>=3D3D3B and using that.
>=3D3D3B =
>=3D3D3B =3D
>=3D3D3B Mika =3D3D =3D20 --_264cb69b-0215-44c3-807c-8b4d8ea0ea59_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Apr 19 23:29:26 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 19 Apr 2010 21:29:26 +0000 Subject: [M3devel] libm3/socket? In-Reply-To: References: <20100419173955.08CF82474003@birch.elegosoft.com>, Message-ID: Yeah.. anyone one m3devel using it? I guess we'll have to support it either way. The m3-comm/tcp stuff seems to be heavily "based" on it -- copy/paste. This stuff has ipv4 address in its public interface. That really made me not want to deal with it. Though the m3-comm stuff too. Pickles are bound to get broken by any sort of IPv6 support, unless maybe we make new interfaces for it. The new interfaces will work with IPv4 or IPv6. - Jay From: hosking at cs.purdue.edu Date: Mon, 19 Apr 2010 14:36:59 -0400 To: jkrell at elego.de CC: m3commit at elegosoft.com Subject: Re: [M3commit] CVS Update: cm3 Who's nobody? Just because there are no CM3 sources that use does not mean that there are no users out there. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 19 Apr 2010, at 19:39, Jay Krell wrote: CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/04/19 19:39:54 Modified files: cm3/m3-libs/libm3/src/os/Common/: m3makefile cm3/m3-libs/libm3/src/os/POSIX/: m3makefile cm3/m3-libs/libm3/src/os/WIN32/: m3makefile Removed files: cm3/m3-libs/libm3/src/os/Common/: Socket.i3 Socket.m3 cm3/m3-libs/libm3/src/os/POSIX/: SocketPosix.m3 SocketPosixC.c cm3/m3-libs/libm3/src/os/WIN32/: SocketWin32.m3 SocketWin32.m3.sav Log message: Nobody uses libm3's socket support. So empty it out instead of fixing it. Let's focus effort elsewhere, e.g. m3-comm/tcp. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.async.caltech.edu Tue Apr 20 00:31:52 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Mon, 19 Apr 2010 15:31:52 -0700 Subject: [M3devel] INTEGER In-Reply-To: References: , , , , <7C7408D0-9A40-4988-BADA-A9FD8C15D388@cs.purdue.edu>, , , , , , , , , , , , <20100418023535.3BA9E1A2103@async.async.caltech.edu>, , , , <20100418024703.6965B1A2103@async.async.caltech.edu>, , <20100418074927.934461A2117@async.async.caltech.edu>, <04EB7FF8-D304-428D-839E-233FCE009C98@cs.purdue.edu>, <20100418195901.CDACB1A20F6@async.async.caltech.edu>, , <20100419172313.68B241A20D6@async.async.caltech.edu>, <4F3EE437-0298-410B-9642-C0381E333430@cs.purdue.edu> Message-ID: <20100419223152.3D7331A2122@async.async.caltech.edu> Jay K writes: ... >Let me suggest a small exercise though: > > I'm not going to do it. > > Write a program that copies files. Or just one file. "cp.exe". > > Have it print "progress feedback" to the user -- how many bytes and percen= >tage copied. Leave out "time estimation". > > And also write "ls.exe". > > And maybe one last program=2C like "dos2unix.exe" or "fix_nl.exe" that alt= >ers newlines. This program should work on files that don't fit in memory. > I use the rdwrreset package under PM3. It solves the most glaring problems. But clearly the file sizes should be done with some sort of data structure different from 32-bit INTEGER. ARRAY [0..1] OF INTEGER seems to be a candidate... ... >Also think about what an idea representation of time is. > >Isn't a 64bit integer number of units smaller than a second a very good one= >? Modula-3 already uses floating point for this, which has the advantage you don't need to worry what the base is. > >And aren't infix operators darned nice? I have mixed feelings about this. Yes, but... every infix operator takes several lines of language definition. Those lines can turn into ungodly amounts of code somewhere. I actually do like Hendrik's idea of providing some sort of bignum support. The reason I don't like LONGINT as much is that it seems it's just a waste if we're all going to be using 64-bit machines anyhow. It's arbitrary to have two fixed-width types. Why not three or four? And why not 128 bits or 16 bits or 36 bits? If on the other hand you got something substantial out of it that might be another story. In that case, I would say LONGINT would be a reference type (much like TEXT) with its associated Longint interface, and infix operators (the way TEXT has &) per Jay's fondest dreams. Come to think of it, TEXT and such a LONGINT would have a lot in common. Mika From hosking at cs.purdue.edu Tue Apr 20 01:16:59 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 19 Apr 2010 19:16:59 -0400 Subject: [M3devel] libm3/socket? In-Reply-To: References: <20100419173955.08CF82474003@birch.elegosoft.com>, Message-ID: <13143F7F-3922-4D49-AB31-74F7E366DB4A@cs.purdue.edu> An opportunity to build a better abstraction... ;-) Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 19 Apr 2010, at 17:29, Jay K wrote: > Yeah.. anyone one m3devel using it? > > I guess we'll have to support it either way. > The m3-comm/tcp stuff seems to be heavily "based" on it -- copy/paste. > > This stuff has ipv4 address in its public interface. > That really made me not want to deal with it. > Though the m3-comm stuff too. > Pickles are bound to get broken by any sort of IPv6 support, unless maybe we make new interfaces for it. > The new interfaces will work with IPv4 or IPv6. > > - Jay > > > From: hosking at cs.purdue.edu > Date: Mon, 19 Apr 2010 14:36:59 -0400 > To: jkrell at elego.de > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > Who's nobody? > > Just because there are no CM3 sources that use does not mean that there are no users out there. > > Antony Hosking | Associate Professor | Computer Science | Purdue University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > On 19 Apr 2010, at 19:39, Jay Krell wrote: > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/04/19 19:39:54 > > Modified files: > cm3/m3-libs/libm3/src/os/Common/: m3makefile > cm3/m3-libs/libm3/src/os/POSIX/: m3makefile > cm3/m3-libs/libm3/src/os/WIN32/: m3makefile > Removed files: > cm3/m3-libs/libm3/src/os/Common/: Socket.i3 Socket.m3 > cm3/m3-libs/libm3/src/os/POSIX/: SocketPosix.m3 SocketPosixC.c > cm3/m3-libs/libm3/src/os/WIN32/: SocketWin32.m3 > SocketWin32.m3.sav > > Log message: > Nobody uses libm3's socket support. > So empty it out instead of fixing it. > Let's focus effort elsewhere, e.g. m3-comm/tcp. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Apr 20 01:57:43 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 19 Apr 2010 23:57:43 +0000 Subject: [M3devel] INTEGER In-Reply-To: <20100419223152.3D7331A2122@async.async.caltech.edu> References: , , , ,,<7C7408D0-9A40-4988-BADA-A9FD8C15D388@cs.purdue.edu>, , ,,, , , , , , , , , , , , , <20100418023535.3BA9E1A2103@async.async.caltech.edu>, ,,, , , <20100418024703.6965B1A2103@async.async.caltech.edu>, , , , <20100418074927.934461A2117@async.async.caltech.edu>, , <04EB7FF8-D304-428D-839E-233FCE009C98@cs.purdue.edu>, , <20100418195901.CDACB1A20F6@async.async.caltech.edu>, , , , <20100419172313.68B241A20D6@async.async.caltech.edu>, , <4F3EE437-0298-410B-9642-C0381E333430@cs.purdue.edu>, , <20100419223152.3D7331A2122@async.async.caltech.edu> Message-ID: > Modula-3 already uses floating point for this, which has the advantage > you don't need to worry what the base is. What do you mean not worry about the "base"? I'm not a fan of floating point. > support. The reason I don't like LONGINT as much is that it seems it's > just a waste if we're all going to be using 64-bit machines anyhow. Again, you might be right. C got 64bit integers ~18 years ago. We are late. Do you think phones and embedded devices will move to 64bits soon too? Are gaming consoles 64bits? > I use the rdwrreset package under PM3 Probably we should plunder PM3 for anything we are missing. > different from 32-bit INTEGER. ARRAY [0..1] OF INTEGER seems to be a > candidate... Again, aside, can such an array be made truly abstract? I'd like opaque data structures without forcing heap allocation. Because, you know, it is somewhat tricky how to deal with, and people will differ as to their assumptions of the order of the integers. There is a bignum package, I haven't looked into it. I find code quality tends to go down the higher level you look. e.g. libm3's socket stuff.. so I haven't looked at a lot, but I should. - Jay > To: jay.krell at cornell.edu > Date: Mon, 19 Apr 2010 15:31:52 -0700 > From: mika at async.async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] INTEGER > > Jay K writes: > ... > >Let me suggest a small exercise though: > > > > I'm not going to do it. > > > > Write a program that copies files. Or just one file. "cp.exe". > > > > Have it print "progress feedback" to the user -- how many bytes and percen= > >tage copied. Leave out "time estimation". > > > > And also write "ls.exe". > > > > And maybe one last program=2C like "dos2unix.exe" or "fix_nl.exe" that alt= > >ers newlines. This program should work on files that don't fit in memory. > > > > I use the rdwrreset package under PM3. It solves the most glaring problems. > But clearly the file sizes should be done with some sort of data structure > different from 32-bit INTEGER. ARRAY [0..1] OF INTEGER seems to be a > candidate... > > ... > >Also think about what an idea representation of time is. > > > >Isn't a 64bit integer number of units smaller than a second a very good one= > >? > > Modula-3 already uses floating point for this, which has the advantage > you don't need to worry what the base is. > > > > >And aren't infix operators darned nice? > > I have mixed feelings about this. Yes, but... every infix operator takes > several lines of language definition. Those lines can turn into ungodly > amounts of code somewhere. > > I actually do like Hendrik's idea of providing some sort of bignum > support. The reason I don't like LONGINT as much is that it seems it's > just a waste if we're all going to be using 64-bit machines anyhow. > It's arbitrary to have two fixed-width types. Why not three or four? > And why not 128 bits or 16 bits or 36 bits? If on the other hand > you got something substantial out of it that might be another story. > In that case, I would say LONGINT would be a reference type (much like > TEXT) with its associated Longint interface, and infix operators (the > way TEXT has &) per Jay's fondest dreams. Come to think of it, > TEXT and such a LONGINT would have a lot in common. > > Mika -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.async.caltech.edu Tue Apr 20 02:09:58 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Mon, 19 Apr 2010 17:09:58 -0700 Subject: [M3devel] INTEGER In-Reply-To: References: , , , , , <7C7408D0-9A40-4988-BADA-A9FD8C15D388@cs.purdue.edu>, , , , , , , , , , , , , , , , , <20100418023535.3BA9E1A2103@async.async.caltech.edu>, , , , , , <20100418024703.6965B1A2103@async.async.caltech.edu>, , , , <20100418074927.934461A2117@async.async.caltech.edu>, , <04EB7FF8-D304-428D-839E-233FCE009C98@cs.purdue.edu>, , <20100418195901.CDACB1A20F6@async.async.caltech.edu>, , , , <20100419172313.68B241A20D6@async.async.caltech.edu>, , <4F3EE437-0298-410B-9642-C0381E333430@cs.purdue.edu>, , <20100419223152.3D7331A2122@async.async. caltech.edu> Message-ID: <20100420000958.7F5991A2122@async.async.caltech.edu> Jay K writes: >--_747381e9-b91f-4765-9877-7c09d53c76c7_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > Modula-3 already uses floating point for this=2C which has the advantage > > you don't need to worry what the base is.=20 > >=20 > >What do you mean not worry about the "base"? > >I'm not a fan of floating point. If you use integer counts of some small interval, that small interval is what I mean has to be specified somewhere. There's nothing much wrong with floating point. It works fine and Time.T can certainly represent intervals much smaller than a second using any reasonable epoch (almost the age of the universe, I think). > >=20 > >=20 > >> support. The reason I don't like LONGINT as much is that it seems it's >> just a waste if we're all going to be using 64-bit machines anyhow. > > >=20 > >Again=2C you might be right. C got 64bit integers ~18 years ago. We are lat= >e. > >Do you think phones and embedded devices will move to 64bits soon too? > >Are gaming consoles 64bits? No, but again the fact that C does something is not a good reason for us to do it. We need a new language type just to deal with file lengths? I think not. That's the only real use case I've seen so far...? > >Again=2C aside=2C can such an array be made truly abstract? > > I'd like opaque data structures without forcing heap allocation. > >Because=2C you know=2C it is somewhat tricky how to deal with=2C and people > >will differ as to their assumptions of the order of the integers. > Of course it has to be little endian. Mika From jay.krell at cornell.edu Tue Apr 20 02:01:44 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 20 Apr 2010 00:01:44 +0000 Subject: [M3devel] libm3/socket? In-Reply-To: <13143F7F-3922-4D49-AB31-74F7E366DB4A@cs.purdue.edu> References: <20100419173955.08CF82474003@birch.elegosoft.com>, , , , <13143F7F-3922-4D49-AB31-74F7E366DB4A@cs.purdue.edu> Message-ID: Do you think we should leave this one exactly asis, and anyone wanting IPv6 must move to a new abstraction? Or should we provide some partial source (in)compatibility but keep everything in interface Socket. I do believe, btw, that code should work with either IPv4 or v6, or even for that matter IPX. Just pass strings along and let layers below you figure it out. I wouldn't want to introduce Socket6 that only works with IPv6. The likely abstraction therefore is Address = TEXT. << I'm also not sure, but my rough reading of IPv6 stuff is that you don't call socket() until after you resolve the string -- getaddrinfo returns a list of families, so you can't just pass one to socket() and be done. That is, the current separation of Create/Bind/Connect/Accept is a bit off. It can be preserved, but Create wouldn't actually call socket(), it'd just store stream or dgram and put off the rest till Connect/Bind/Listen/Accept (probably just two of the four, when I really know what does what..) - Jay From: hosking at cs.purdue.edu Date: Mon, 19 Apr 2010 19:16:59 -0400 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] libm3/socket? An opportunity to build a better abstraction... ;-) Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 19 Apr 2010, at 17:29, Jay K wrote: Yeah.. anyone one m3devel using it? I guess we'll have to support it either way. The m3-comm/tcp stuff seems to be heavily "based" on it -- copy/paste. This stuff has ipv4 address in its public interface. That really made me not want to deal with it. Though the m3-comm stuff too. Pickles are bound to get broken by any sort of IPv6 support, unless maybe we make new interfaces for it. The new interfaces will work with IPv4 or IPv6. - Jay From: hosking at cs.purdue.edu Date: Mon, 19 Apr 2010 14:36:59 -0400 To: jkrell at elego.de CC: m3commit at elegosoft.com Subject: Re: [M3commit] CVS Update: cm3 Who's nobody? Just because there are no CM3 sources that use does not mean that there are no users out there. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 19 Apr 2010, at 19:39, Jay Krell wrote: CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/04/19 19:39:54 Modified files: cm3/m3-libs/libm3/src/os/Common/: m3makefile cm3/m3-libs/libm3/src/os/POSIX/: m3makefile cm3/m3-libs/libm3/src/os/WIN32/: m3makefile Removed files: cm3/m3-libs/libm3/src/os/Common/: Socket.i3 Socket.m3 cm3/m3-libs/libm3/src/os/POSIX/: SocketPosix.m3 SocketPosixC.c cm3/m3-libs/libm3/src/os/WIN32/: SocketWin32.m3 SocketWin32.m3.sav Log message: Nobody uses libm3's socket support. So empty it out instead of fixing it. Let's focus effort elsewhere, e.g. m3-comm/tcp. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Apr 20 02:43:25 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 20 Apr 2010 00:43:25 +0000 Subject: [M3devel] INTEGER In-Reply-To: <20100420000958.7F5991A2122@async.async.caltech.edu> References: , , , , ,,<7C7408D0-9A40-4988-BADA-A9FD8C15D388@cs.purdue.edu>, , , ,,, , , , , , , , , , , , , , , , , <20100418023535.3BA9E1A2103@async.async.caltech.edu>, , ,,, , ,,<20100418024703.6965B1A2103@async.async.caltech.edu>, ,,, ,,<20100418074927.934461A2117@async.async.caltech.edu>, ,,<04EB7FF8-D304-428D-839E-233FCE009C98@cs.purdue.edu>, ,,<20100418195901.CDACB1A20F6@async.async.caltech.edu>, ,,, ,,<20100419172313.68B241A20D6@async.async.caltech.edu>, , , <4F3EE437-0298-410B-9642-C0381E333430@cs.purdue.edu>, , , , <20100419223152.3D7331A2122@async.async., caltech.edu> , <20100420000958.7F5991A2122@async.async.caltech.edu> Message-ID: > If you use integer counts of some small interval, that small interval > is what I mean has to be specified somewhere. There would be one and only interval for all time measurements. => Whatever NT uses. 10s of nanoseconds I believe. Isn't that similar to saying you have to specify it is seconds? Or seconds is easier to remember and understand? NT's unit is a little difficult for me, granted. > There's nothing much wrong with floating point. It works fine and Time.T > can certainly represent intervals much smaller than a second using any > reasonable epoch (almost the age of the universe, I think). Does Time.T have a large range actually? I haven't figured it out. And are negative times allowed? If no negative times, then not a wide range. > No, but again the fact that C does something is not a good reason for us to do > it. We need a new language type just to deal with file lengths? I think not. > That's the only real use case I've seen so far...? National debt as an integer? I don't know if there are other uses. > Of course it has to be little endian. That's what I think, but I might just be corrupted. It still needs to abstract/opaque, though, so people don't get confused about the lower bits being unsigned, for example. gotta run, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Tue Apr 20 04:46:16 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Mon, 19 Apr 2010 21:46:16 -0500 Subject: [M3devel] INTEGER (and floating point) In-Reply-To: <20100419223152.3D7331A2122@async.async.caltech.edu> References: , , , , , , , , , , , , , <20100418023535.3BA9E1A2103@async.async.caltech.edu>, , , , <20100418024703.6965B1A2103@async.async.caltech.edu>, , <20100418074927.934461A2117@async.async.caltech.edu>, <04EB7FF8-D304-428D-839E-233FCE009C98@cs.purdue.edu>, <20100418195901.CDACB1A20F6@async.async.caltech.edu>, , <20100419172313.68B241A20D6@async.async.caltech.edu>, <4F3EE437-0298-410B-9642-C0381E333430@cs.purdue.edu> <20100419223152.3D7331A2122@async.async.caltech.edu> Message-ID: <4BCD1578.3050900@lcwb.coop> Mika Nystrom wrote: > > Modula-3 already uses floating point for this, which has the advantage > you don't need to worry what the base is. The designers of Algol 60 gave us several good new ideas, but one place they did a huge disservice was in renaming what had been called "floating point" as "real". This was and still is a lie. One ugly property that floating point has is that the smallest interval between representable values keeps getting larger as the value gets larger. Moreover, for representations of equal bit counts, floating will always eventually get to the point that it no longer can even represent the integers. The interval eventually becomes two, then four, eight, etc. (if the exponent is a power of two, as it usually is). There are places where you care about large value range *and* precision down to the integers, and file sizes are likely to be one of them. National budgets might be too. Ditto times. Sometimes you can stand the erosion of precision in large values, but not always. Of course, if you compare a 32-bit integer to a 64-bit float, this won't happen. But I think the 64-bit float should be compared to a 64-bit integer. > Mika > From hendrik at topoi.pooq.com Tue Apr 20 01:52:12 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 19 Apr 2010 19:52:12 -0400 Subject: [M3devel] INTEGER In-Reply-To: References: <20100419155702.GB8759@topoi.pooq.com> Message-ID: <20100419235212.GA10670@topoi.pooq.com> On Mon, Apr 19, 2010 at 09:20:00PM +0000, Jay K wrote: > > For the record, anyone using Windows (NT/2000/XP/2003/etc.) is using 16bit characters *all the time*. > > MacOSX maybe also. > > I think utf8 is kind of a hack to let folks get away without really doing anything. > > Granted, I didn't realize till recently that strcmp works on > utf8..maybe a really clever idea.. utf8 was a really clever idea. Unless you need to isolate specific characters and do something with them, most code manipulating text needn't care whether it's UTF8 or not. -- hendrik From jay.krell at cornell.edu Tue Apr 20 07:34:10 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 20 Apr 2010 05:34:10 +0000 Subject: [M3devel] INTEGER (and floating point) In-Reply-To: <4BCD1578.3050900@lcwb.coop> References: , , , ,,, , , , , , , , , , , , , <20100418023535.3BA9E1A2103@async.async.caltech.edu>, ,,, , , <20100418024703.6965B1A2103@async.async.caltech.edu>, , , , <20100418074927.934461A2117@async.async.caltech.edu>, , <04EB7FF8-D304-428D-839E-233FCE009C98@cs.purdue.edu>, , <20100418195901.CDACB1A20F6@async.async.caltech.edu>, , , , <20100419172313.68B241A20D6@async.async.caltech.edu>, , <4F3EE437-0298-410B-9642-C0381E333430@cs.purdue.edu> , <20100419223152.3D7331A2122@async.async.caltech.edu>, <4BCD1578.3050900@lcwb.coop> Message-ID: Floating point is just wierd. very large + very small = the same very large I realize that is approximately correct, but approximations can be worrisome. And it can be costly to avoid making them as well. Stuck. > Of course, if you compare a 32-bit integer to a 64-bit float, this > won't happen. But I think the 64-bit float should be compared to > a 64-bit integer. Eh? A 64bit float cannot store all 64bit integer values. Typically 64bit float has about 53bits of precision. Local float.h: #define DBL_MANT_DIG 53 /* # of bits in mantissa */ #define FLT_MANT_DIG 24 /* # of bits in mantissa */ Now, interestingly, the IA64 floating point registers are large enough, they do have at least 64bits of precision, and integer division/mod is implemented using floating point. I was surprised to step through my hash table code and see floating point used. :) - Jay > Date: Mon, 19 Apr 2010 21:46:16 -0500 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: Re: [M3devel] INTEGER (and floating point) > > > > Mika Nystrom wrote: > > > > Modula-3 already uses floating point for this, which has the advantage > > you don't need to worry what the base is. > > The designers of Algol 60 gave us several good new ideas, but one place > they did a huge disservice was in renaming what had been called "floating > point" as "real". This was and still is a lie. > > One ugly property that floating point has is that the smallest interval > between representable values keeps getting larger as the value gets > larger. Moreover, for representations of equal bit counts, floating > will always eventually get to the point that it no longer can even represent > the integers. The interval eventually becomes two, then four, eight, > etc. (if the exponent is a power of two, as it usually is). > > There are places where you care about large value range *and* precision > down to the integers, and file sizes are likely to be one of them. > National budgets might be too. Ditto times. Sometimes you can stand > the erosion of precision in large values, but not always. > > Of course, if you compare a 32-bit integer to a 64-bit float, this > won't happen. But I think the 64-bit float should be compared to > a 64-bit integer. > > > Mika > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Tue Apr 20 17:29:42 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Tue, 20 Apr 2010 10:29:42 -0500 Subject: [M3devel] INTEGER In-Reply-To: <20100419223152.3D7331A2122@async.async.caltech.edu> References: , , , , , , , , , , , , , <20100418023535.3BA9E1A2103@async.async.caltech.edu>, , , , <20100418024703.6965B1A2103@async.async.caltech.edu>, , <20100418074927.934461A2117@async.async.caltech.edu>, <04EB7FF8-D304-428D-839E-233FCE009C98@cs.purdue.edu>, <20100418195901.CDACB1A20F6@async.async.caltech.edu>, , <20100419172313.68B241A20D6@async.async.caltech.edu>, <4F3EE437-0298-410B-9642-C0381E333430@cs.purdue.edu> <20100419223152.3D7331A2122@async.async.caltech.edu> Message-ID: <4BCDC866.6050804@lcwb.coop> The designers of Modula-3 gave use not one but three floating point types. They explicitly justified this as matching the range of hardware arithmetic provided by set of common processors of the day. They didn't say this (to my knowledge), but one integer type also matched the hardware of the day. But the period when practically all processors had the same word size was a historical anomaly. It was a nice halcyon time in that respect, and it allowed us to avoid some messy problems. But it never was true prior to that era, and it is no longer true. I doubt it will be again. Despite the proliferation of 64-bit machines, there will be useful 32-bit ones around for a years. Not everybody buys the newest every three years, and 32 bits is still capable of a lot. I don't see them being retired at anything like the rate 16-bit machines were, because they don't suffer the limitations. And then we have the proliferation of embedded and hand-held devices, which as I am hearing, are already well out ahead of server and desktop computers in raw processor count. So I think keeping two integer sizes in the language removes what many people would consider a serious obstacle. Moreover, the way the two integer sizes is are now defined is cleaner than I have seen in any other language. It also somewhat follows the way the three floating types were done in the original language in that it preserves the type-uniqueness of every expression. It further makes the static legality and semantics of code as close to implementation-independent as it was in the unmodified language. And it does not change the legality or static semantics of any old code. Mika Nystrom wrote: > > I actually do like Hendrik's idea of providing some sort of bignum > support. The reason I don't like LONGINT as much is that it seems it's > just a waste if we're all going to be using 64-bit machines anyhow. > It's arbitrary to have two fixed-width types. Why not three or four? > And why not 128 bits or 16 bits or 36 bits? If on the other hand > you got something substantial out of it that might be another story. > In that case, I would say LONGINT would be a reference type (much like > TEXT) with its associated Longint interface, and infix operators (the > way TEXT has &) per Jay's fondest dreams. Come to think of it, > TEXT and such a LONGINT would have a lot in common. > > Mika > From rodney_bates at lcwb.coop Tue Apr 20 17:59:57 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Tue, 20 Apr 2010 10:59:57 -0500 Subject: [M3devel] INTEGER In-Reply-To: <20100419155702.GB8759@topoi.pooq.com> References: <20100418024703.6965B1A2103@async.async.caltech.edu> <20100418074927.934461A2117@async.async.caltech.edu> <04EB7FF8-D304-428D-839E-233FCE009C98@cs.purdue.edu> <20100418195901.CDACB1A20F6@async.async.caltech.edu> <20100419155702.GB8759@topoi.pooq.com> Message-ID: <4BCDCF7D.604@lcwb.coop> hendrik at topoi.pooq.com wrote: > On Sun, Apr 18, 2010 at 12:59:01PM -0700, Mika Nystrom wrote: >> And the new m3tk, stubgen, and compiler(?) won't compile using PM3 or >> SRC M3 since we're no longer using the language of the Green Book. >> (Same comment goes for WIDECHAR, by the way.) > > When I use Unicode characters, I find myself defining them to be > INTEGERs, because I'm always worried that WIDECHARs might be omly 16 bits. Actually, I favor making WIDECHAR big enough to hold all the defined Unicode values, which I understand have been more that 2^16 for some time now. The only thing the language definition says about WIDECHAR is that it has at least 65536 values and the first 65536 correspond to the first 65536 Unicode characters. It could be bigger. Moreover, as I recall from a while back, the compiler, old and new Text implementation, other libraries, m3gdb, and maybe pickles are only a couple of declaration changes away from supporting some bigger range for WIDECHAR. (I think I am the one who put WIDECHAR into the language reference, and that was only recently, despite its being in the cm3 language for years. I also see that this has not propagated from the .tex version into the .html and .pdf files.) > > Strings of WIDECHARS are probably unnecesary. The last program I wrote > that used Unicode used INTEGERs for characters, and arrays of INTEGERS > for strings. But I think it was a mistake to do it this way, and when I > have time I'll rewrite it. UTF-8 seems to be the way to go; strings of > Unicode can easily be manipulated as ordinary TEXT. In fact, I > think there are few if any places in my code where I would have had to > do anything special whatsoever if I had just used UTF8 in TEXT. The > program would simply become simpler. This is only true if you handle strings in certain common but restricted ways. If you just move strings around, UTF-8 will often work with little or no code change. OTOH, if you need to access characters non-sequentially or make any examination or production of individual characters not in the Iso-latin-1 subset, any variable-length encoding quickly becomes unworkable. Text.Sub and Text.GetChar won't work in any sensible way if they view the string as a string of 8-bit bytes, when it's actually not. Reimplementing these to understand UTF-8 would make what was O(1) become O(n). Ditto Text.Length. > > -- hendrik > From jay.krell at cornell.edu Tue Apr 20 18:59:53 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 20 Apr 2010 16:59:53 +0000 Subject: [M3devel] INTEGER In-Reply-To: <4BCDC866.6050804@lcwb.coop> References: , , , ,,, , , , , , , , , , , , , <20100418023535.3BA9E1A2103@async.async.caltech.edu>, ,,, , , <20100418024703.6965B1A2103@async.async.caltech.edu>, , , , <20100418074927.934461A2117@async.async.caltech.edu>, , <04EB7FF8-D304-428D-839E-233FCE009C98@cs.purdue.edu>, , <20100418195901.CDACB1A20F6@async.async.caltech.edu>, , , , <20100419172313.68B241A20D6@async.async.caltech.edu>, , <4F3EE437-0298-410B-9642-C0381E333430@cs.purdue.edu> , <20100419223152.3D7331A2122@async.async.caltech.edu>, <4BCDC866.6050804@lcwb.coop> Message-ID: Thank you Rodney. Good, interesting points. > and 32 bits is still capable of a lot Agreed. There is an interesting construct that seems common -- 64bit kernels that can run 32bit or 64bit usermode code. That is what NT looks like, and Solaris, and Linux on sparc, and Irix (obsolete thought it may be..), and AIX, and HP-UX, and at least some configurations of Mac. In particular I read that sparc32 is quite obsolete from the Linux kernel point of view, there is no 32bit sparc Linux kernel, but 32bit usermode code is still fine. There is probably some correlation to like "systems that moved to 64bit processors earlier provide better support for 32bit usermode", and "systems that moved to 64bit processors later see 32bit support as more temporary". ie. commercial Unix moved to 64bit first, NT and free Unix later. OpenBSD is "pure", they only ever support one "architecture". The seeming "problem" (not a problem in this context) is managing multiple GB of cheap physical RAM across an entire physical system. The overall system these days can have so much memory, but individual processes don't necessarily need it. As well, people often speak of 64bit being slower due to larger pointers, larger data. As well as larger code to load 64bit values. x86 is a bit of anomaly here in that the widening to 64bits also "cleaned up" a lot -- added many more registers not just wider registers, established a baseline for a different floating point instruction set (SSE), easier to generate position independent code via RIP-relative addressing, and at least on NT a better model for exception handling. So x86 switching to 64bit is a better sell than others. But still has the larger pointers/data. So you know, what size buffer do I need to hold the concatenation of two strings whose maximum length is 100? Or what size integer do I need to hold the result of multiplying two n bit integers? The kernel overarches all pieces/processes and needs perhaps larger capacity to handle it all than the pieces themselves need. > proliferation of embedded and hand-held devices, which as I am > hearing, are already well out ahead of server and desktop computers in raw processor count I heard this over 10 years ago, that embedded systems ship far more processors than "computers", though it was lower end devices -- cars, microwaves, digital watches. This world lingered in programming in assembly and using cheaper 8 and 16bit CPUs and MMU-less hardware longer. Manufacturing in such large volume, it was worth saving money. Nowadays we hear about them all being 32bit and having MMUs (e.g. phones). > Not everybody buys the newest every three years We are closer to 7 years into AMD64 though. :) Except then 32bit came back -- Atom. :) - Jay > Date: Tue, 20 Apr 2010 10:29:42 -0500 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: Re: [M3devel] INTEGER > > The designers of Modula-3 gave use not one but three floating point types. > They explicitly justified this as matching the range of hardware arithmetic > provided by set of common processors of the day. > > They didn't say this (to my knowledge), but one integer type also matched > the hardware of the day. But the period when practically all processors > had the same word size was a historical anomaly. It was a nice halcyon > time in that respect, and it allowed us to avoid some messy problems. > > But it never was true prior to that era, and it is no longer true. > I doubt it will be again. Despite the proliferation of 64-bit > machines, there will be useful 32-bit ones around for a years. > Not everybody buys the newest every three years, and 32 bits is > still capable of a lot. I don't see them being retired at anything > like the rate 16-bit machines were, because they don't suffer the > limitations. And then we have the proliferation of embedded and > hand-held devices, which as I am hearing, are already well out ahead > of server and desktop computers in raw processor count. > > So I think keeping two integer sizes in the language removes what > many people would consider a serious obstacle. Moreover, the way > the two integer sizes is are now defined is cleaner than I have > seen in any other language. It also somewhat follows the way the > three floating types were done in the original language in that > it preserves the type-uniqueness of every expression. It further > makes the static legality and semantics of code as close to > implementation-independent as it was in the unmodified language. > And it does not change the legality or static semantics of any > old code. > > Mika Nystrom wrote: > > > > I actually do like Hendrik's idea of providing some sort of bignum > > support. The reason I don't like LONGINT as much is that it seems it's > > just a waste if we're all going to be using 64-bit machines anyhow. > > It's arbitrary to have two fixed-width types. Why not three or four? > > And why not 128 bits or 16 bits or 36 bits? If on the other hand > > you got something substantial out of it that might be another story. > > In that case, I would say LONGINT would be a reference type (much like > > TEXT) with its associated Longint interface, and infix operators (the > > way TEXT has &) per Jay's fondest dreams. Come to think of it, > > TEXT and such a LONGINT would have a lot in common. > > > > Mika > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.async.caltech.edu Tue Apr 20 19:12:35 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Tue, 20 Apr 2010 10:12:35 -0700 Subject: [M3devel] INTEGER In-Reply-To: <4BCDC866.6050804@lcwb.coop> References: , , , , , , , , , , , , , <20100418023535.3BA9E1A2103@async.async.caltech.edu>, , , , <20100418024703.6965B1A2103@async.async.caltech.edu>, , <20100418074927.934461A2117@async.async.caltech.edu>, <04EB7FF8-D304-428D-839E-233FCE009C98@cs.purdue.edu>, <20100418195901.CDACB1A20F6@async.async.caltech.edu>, , <20100419172313.68B241A20D6@async.async.caltech.edu>, <4F3EE437-0298-410B-9642-C0381E333430@cs.purdue.edu> <20100419223152.3D7331A2122@async.async.caltech.edu> <4BCDC866.6050804@lcwb.coop> Message-ID: <20100420171235.B8F0C1A2103@async.async.caltech.edu> "Rodney M. Bates" writes: >The designers of Modula-3 gave use not one but three floating point types. >They explicitly justified this as matching the range of hardware arithmetic >provided by set of common processors of the day. > >They didn't say this (to my knowledge), but one integer type also matched >the hardware of the day. But the period when practically all processors >had the same word size was a historical anomaly. It was a nice halcyon >time in that respect, and it allowed us to avoid some messy problems. > >But it never was true prior to that era, and it is no longer true. >I doubt it will be again. Despite the proliferation of 64-bit >machines, there will be useful 32-bit ones around for a years. >Not everybody buys the newest every three years, and 32 bits is >still capable of a lot. I don't see them being retired at anything >like the rate 16-bit machines were, because they don't suffer the >limitations. And then we have the proliferation of embedded and >hand-held devices, which as I am hearing, are already well out ahead >of server and desktop computers in raw processor count. > >So I think keeping two integer sizes in the language removes what >many people would consider a serious obstacle. Moreover, the way >the two integer sizes is are now defined is cleaner than I have >seen in any other language. It also somewhat follows the way the >three floating types were done in the original language in that >it preserves the type-uniqueness of every expression. It further >makes the static legality and semantics of code as close to >implementation-independent as it was in the unmodified language. >And it does not change the legality or static semantics of any >old code. I agree LONGINT isn't horrible. However, I am not sure I agree with your description above. 1. Modula-3 provides three floating-point formats because *each* common processor architecture provided (and provides) support for generally at least three floating-point formats. The point was to give programmers easy access to the hardware in their own machines, not really so that IBM programmers could have an extra format for VAX compatibility. Note that I don't believe that it was intended that EXTENDED would be emulated by the compiler either: the point was really to give programmers access to the formats provided efficiently by their hardware. 2. 64-bit machines don't actually get two different integer formats with the way LONGINT works. INTEGER and LONGINT are both 64 bits. That was not the intention with the floating-point formats either. 3. 64-bit machines were hardly unforeseen by DEC's research people, given that their company introduced Alpha just after Modula-3 and that DECWRL across town was working on 64-bit ECL machines. In fact I think Modula-3 had versions with 64-bit INTEGERs already in 1992? (To use Jay's expression, it's now 18 years later, and many C environments still haven't caught up---int is still 32 bits in many of them!) People at SRC surely had a lot of 64-bit machines with Modula-3 programs running on them in the early 90s. Somehow the problem of representing 64-bit integers on older VAX, MIPS, i386 systems just didn't arise for them? 4. I still haven't seen any really convincing use cases. What's it for? The lack of LONGINT was an obstacle to what, precisely? 5. Finally, is it the intention that LONGINT be fixed at 64 bits forevermore? (See point 2.) This seems to completely fly in the face of M3's philosophy. (See Hendrik's arguments.) Mika From hosking at cs.purdue.edu Tue Apr 20 19:31:45 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 20 Apr 2010 13:31:45 -0400 Subject: [M3devel] INTEGER In-Reply-To: <20100420171235.B8F0C1A2103@async.async.caltech.edu> References: , , , , , , , , , , , , , <20100418023535.3BA9E1A2103@async.async.caltech.edu>, , , , <20100418024703.6965B1A2103@async.async.caltech.edu>, , <20100418074927.934461A2117@async.async.caltech.edu>, <04EB7FF8-D304-428D-839E-233FCE009C98@cs.purdue.edu>, <20100418195901.CDACB1A20F6@async.async.caltech.edu>, , <20100419172313.68B241A20D6@async.async.caltech.edu>, <4F3EE437-0298-410B-9642-C0381E333430@cs.purdue.edu> <20100419223152.3D7331A2122@async.async.caltech.edu> <4BCDC866.6050804@lcwb.coop> <20100420171235! .B8F0C1A2103@async.async.caltech.edu> Message-ID: On 20 Apr 2010, at 13:12, Mika Nystrom wrote: > "Rodney M. Bates" writes: >> The designers of Modula-3 gave use not one but three floating point types. >> They explicitly justified this as matching the range of hardware arithmetic >> provided by set of common processors of the day. >> >> They didn't say this (to my knowledge), but one integer type also matched >> the hardware of the day. But the period when practically all processors >> had the same word size was a historical anomaly. It was a nice halcyon >> time in that respect, and it allowed us to avoid some messy problems. >> >> But it never was true prior to that era, and it is no longer true. >> I doubt it will be again. Despite the proliferation of 64-bit >> machines, there will be useful 32-bit ones around for a years. >> Not everybody buys the newest every three years, and 32 bits is >> still capable of a lot. I don't see them being retired at anything >> like the rate 16-bit machines were, because they don't suffer the >> limitations. And then we have the proliferation of embedded and >> hand-held devices, which as I am hearing, are already well out ahead >> of server and desktop computers in raw processor count. >> >> So I think keeping two integer sizes in the language removes what >> many people would consider a serious obstacle. Moreover, the way >> the two integer sizes is are now defined is cleaner than I have >> seen in any other language. It also somewhat follows the way the >> three floating types were done in the original language in that >> it preserves the type-uniqueness of every expression. It further >> makes the static legality and semantics of code as close to >> implementation-independent as it was in the unmodified language. >> And it does not change the legality or static semantics of any >> old code. > > I agree LONGINT isn't horrible. However, I am not sure I agree > with your description above. > > 1. Modula-3 provides three floating-point formats because *each* common > processor architecture provided (and provides) support for generally at > least three floating-point formats. The point was to give programmers > easy access to the hardware in their own machines, not really so that IBM > programmers could have an extra format for VAX compatibility. Note that > I don't believe that it was intended that EXTENDED would be emulated by > the compiler either: the point was really to give programmers access to > the formats provided efficiently by their hardware. In the current implementation EXTENDED=LONGREAL. > 2. 64-bit machines don't actually get two different integer formats > with the way LONGINT works. INTEGER and LONGINT are both 64 bits. > That was not the intention with the floating-point formats either. Current implementation, yes, but this is not fixed. > 3. 64-bit machines were hardly unforeseen by DEC's research people, > given that their company introduced Alpha just after Modula-3 and that > DECWRL across town was working on 64-bit ECL machines. In fact I think > Modula-3 had versions with 64-bit INTEGERs already in 1992? (To use > Jay's expression, it's now 18 years later, and many C environments still > haven't caught up---int is still 32 bits in many of them!) People at > SRC surely had a lot of 64-bit machines with Modula-3 programs running > on them in the early 90s. Somehow the problem of representing 64-bit > integers on older VAX, MIPS, i386 systems just didn't arise for them? Yep. Love my Alpha so much I can't bear to throw it away. > 4. I still haven't seen any really convincing use cases. What's it for? > The lack of LONGINT was an obstacle to what, precisely? I think the only one we have is file sizes... > 5. Finally, is it the intention that LONGINT be fixed at 64 bits > forevermore? (See point 2.) This seems to completely fly in the face > of M3's philosophy. (See Hendrik's arguments.) The only constraint imposed is BITSIZE(LONGINT) >= BITSIZE(INTEGER). > > Mika > > > From jay.krell at cornell.edu Tue Apr 20 20:05:25 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 20 Apr 2010 18:05:25 +0000 Subject: [M3devel] INTEGER In-Reply-To: <20100420171235.B8F0C1A2103@async.async.caltech.edu> References: , , , ,,, , , , , , , , , , , , , <20100418023535.3BA9E1A2103@async.async.caltech.edu>, ,,, , , <20100418024703.6965B1A2103@async.async.caltech.edu>, , , , <20100418074927.934461A2117@async.async.caltech.edu>, , <04EB7FF8-D304-428D-839E-233FCE009C98@cs.purdue.edu>, , <20100418195901.CDACB1A20F6@async.async.caltech.edu>, , , , <20100419172313.68B241A20D6@async.async.caltech.edu>, , <4F3EE437-0298-410B-9642-C0381E333430@cs.purdue.edu>, , <20100419223152.3D7331A2122@async.async.caltech.edu>, <4BCDC866.6050804@lcwb.coop>, <20100420171235.B8F0C1A2103@async.async.caltech.edu> Message-ID: > (To use Jay's expression, it's now 18 years later, and > many C environments still haven't caught up---int is still 32 bits in many of them!) Int is 32 bits in almost every C environment. Maybe some Cray has 64bit int. But every system I've seen has 32 bit (or 16 bit) int. Do any C environments lack a 64bit "long" or "long long" or "__int64"? I believe gcc is written to not depend on any 64bit integer or "long long" being guaranteed available, so it can compile with a compiler that only has up to "long", be it 32bits or 64bits. I believe they represent 64bit integers internally as a pair of longs and always take 32bits from each. It is a little confusing but also makes sense. On systems with 64bit long, which there are many of, they waste space. It'd seem better to use a pair of 32bits ints or one 64bit long or long long. But it is portable, even if int is 16 bits. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.async.caltech.edu Tue Apr 20 20:07:15 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Tue, 20 Apr 2010 11:07:15 -0700 Subject: [M3devel] INTEGER In-Reply-To: References: , , , , , , , , , , , , , <20100418023535.3BA9E1A2103@async.async.caltech.edu>, , , , <20100418024703.6965B1A2103@async.async.caltech.edu>, , <20100418074927.934461A2117@async.async.caltech.edu>, <04EB7FF8-D304-428D-839E-233FCE009C98@cs.purdue.edu>, <20100418195901.CDACB1A20F6@async.async.caltech.edu>, , <20100419172313.68B241A20D6@async.async.caltech.edu>, <4F3EE437-0298-410B-9642-C0381E333430@cs.purdue.edu> <20100419223152.3D7331A2122@async.async.caltech.edu> <4BCDC866.6050804@lcwb.coop> <20100420171235! .B8F0C1A2103@async.async.caltech.edu> Message-ID: <20100420180715.52C391A2103@async.async.caltech.edu> Tony Hosking writes: >On 20 Apr 2010, at 13:12, Mika Nystrom wrote: ... >> easy access to the hardware in their own machines, not really so that = >IBM >> programmers could have an extra format for VAX compatibility. Note = >that >> I don't believe that it was intended that EXTENDED would be emulated = >by >> the compiler either: the point was really to give programmers access = >to >> the formats provided efficiently by their hardware. > >In the current implementation EXTENDED=3DLONGREAL. Ok, but EXTENDED is still something that is efficiently provided by my hardware. Not something efficiently provided by someone else's hardware! >> 4. I still haven't seen any really convincing use cases. What's it = >for? >> The lack of LONGINT was an obstacle to what, precisely? > >I think the only one we have is file sizes... > >> 5. Finally, is it the intention that LONGINT be fixed at 64 bits >> forevermore? (See point 2.) This seems to completely fly in the face >> of M3's philosophy. (See Hendrik's arguments.) > >The only constraint imposed is BITSIZE(LONGINT) >=3D BITSIZE(INTEGER). I am not so sure here. Rodney's argument has in fact convinced me that the current version of LONGINT is wrong and perhaps evil. It should either go away completely or be replaced by Hendrik's suggestion. Here's why. The argument is that if I have an N-bit machine, for N References: , , , , , , , , , , , , , <20100418023535.3BA9E1A2103@async.async.caltech.edu>, , , , <20100418024703.6965B1A2103@async.async.caltech.edu>, , <20100418074927.934461A2117@async.async.caltech.edu>, <04EB7FF8-D304-428D-839E-233FCE009C98@cs.purdue.edu>, <20100418195901.CDACB1A20F6@async.async.caltech.edu>, , <20100419172313.68B241A20D6@async.async.caltech.edu>, <4F3EE437-0298-410B-9642-C0381E333430@cs.purdue.edu> <20100419223152.3D7331A2122@async.async.caltech.edu> <4BCDC866.6050804@lcwb.coop> <20100420171235.B8F0C1A2103@async.async.caltech.edu> Message-ID: >-----Original Message----- >From: Mika Nystrom [mailto:mika at async.async.caltech.edu] >Sent: Tuesday, April 20, 2010 1:13 PM > >5. Finally, is it the intention that LONGINT be fixed at 64 bits >forevermore? (See point 2.) This seems to completely fly in the face >of M3's philosophy. (See Hendrik's arguments.) > Mika My "understanding" was that LONGINT would be a MINimum of 64-bits, but could be larger on certain platforms. For those platforms where the native integer size is already 64-bits, it could be possible that BITSIZE of INTEGER and LONGINT are indeed the same, 64-bits. It could also be that on some platforms we could have 64-bit INTEGER and maybe 128-bit LONGINT. Thus, the BITSIZE of LONGINT is both platform and implementation-dependent, but constrained to have a lower-bound of 64-bits. If I'm not understanding this correctly, someone please enlighten me. --Randy CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This email may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from reviewing, copying, using, disclosing or distributing to others the information in this email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require advance export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. From jay.krell at cornell.edu Tue Apr 20 23:36:12 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 20 Apr 2010 21:36:12 +0000 Subject: [M3devel] INTEGER In-Reply-To: References: , , , ,,, , , , , ,,, , , , ,,<20100418023535.3BA9E1A2103@async.async.caltech.edu>, ,,, , , <20100418024703.6965B1A2103@async.async.caltech.edu>, , , , <20100418074927.934461A2117@async.async.caltech.edu>, , <04EB7FF8-D304-428D-839E-233FCE009C98@cs.purdue.edu>, , <20100418195901.CDACB1A20F6@async.async.caltech.edu>, , , , <20100419172313.68B241A20D6@async.async.caltech.edu>, , <4F3EE437-0298-410B-9642-C0381E333430@cs.purdue.edu>, , <20100419223152.3D7331A2122@async.async.caltech.edu>, <4BCDC866.6050804@lcwb.coop>, <20100420171235.B8F0C1A2103@async.async.caltech.edu>, Message-ID: Randy, This is correct. Are we subtly suggesting that LONGINT be 128 bits on 64 bit systems, to avoid the creeping assumption that it is 64 bits? Seems ok, though it'd be some work in the compiler -- but maybe, again, a library based implementation, like how atomic is structured and possibly implemented. Would anyone use this type? Or there'd be m3core/unix/32bit/types.i3 off_t = LONGINT, m3core/unix/64bit/types.i3 off_t = INTEGER? And everywhere else anyone wanted a 64 bit type? Or we would say off_t = BITS 64 FOR [(-?)16_800000000000L..16_7FFFFFFFFFFFL]? That is preferable since it avoids forking a file..though it might be incorrect. 16_800000000000L is positive if 128bits, and -16_800000000000L is correct for 128bits but overflows for 64 bits. I think maybe. - Jay > From: rcolebur at SCIRES.COM > To: m3devel at elegosoft.com > Date: Tue, 20 Apr 2010 15:56:26 -0400 > Subject: Re: [M3devel] INTEGER > > >-----Original Message----- > >From: Mika Nystrom [mailto:mika at async.async.caltech.edu] > >Sent: Tuesday, April 20, 2010 1:13 PM > > > >5. Finally, is it the intention that LONGINT be fixed at 64 bits > >forevermore? (See point 2.) This seems to completely fly in the face > >of M3's philosophy. (See Hendrik's arguments.) > > Mika > > My "understanding" was that LONGINT would be a MINimum of 64-bits, but could be larger on certain platforms. For those platforms where the native integer size is already 64-bits, it could be possible that BITSIZE of INTEGER and LONGINT are indeed the same, 64-bits. It could also be that on some platforms we could have 64-bit INTEGER and maybe 128-bit LONGINT. Thus, the BITSIZE of LONGINT is both platform and implementation-dependent, but constrained to have a lower-bound of 64-bits. If I'm not understanding this correctly, someone please enlighten me. > --Randy > > > > > > CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This email may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from reviewing, copying, using, disclosing or distributing to others the information in this email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. > > EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require advance export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Apr 20 23:42:49 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 20 Apr 2010 21:42:49 +0000 Subject: [M3devel] INTEGER In-Reply-To: <20100420180715.52C391A2103@async.async.caltech.edu> References: , , , ,,, , , , , , , , , , , , , <20100418023535.3BA9E1A2103@async.async.caltech.edu>, ,,, , , <20100418024703.6965B1A2103@async.async.caltech.edu>, , , , <20100418074927.934461A2117@async.async.caltech.edu>, , <04EB7FF8-D304-428D-839E-233FCE009C98@cs.purdue.edu>, , <20100418195901.CDACB1A20F6@async.async.caltech.edu>, , , , <20100419172313.68B241A20D6@async.async.caltech.edu>, , <4F3EE437-0298-410B-9642-C0381E333430@cs.purdue.edu>, , <20100419223152.3D7331A2122@async.async.caltech.edu>, <4BCDC866.6050804@lcwb.coop> <20100420171235!, .B8F0C1A2103@async.async.caltech.edu>, , <20100420180715.52C391A2103@async.async.caltech.edu> Message-ID: Mika I think your point, which I missed for a while is that: Just because some hardware has an efficient 64bit integer called INTEGER, does not justify giving other (32bit) hardware a somewhat efficient 64bit integer called LONGINT. ? The analogy I missed is, just because EXTENDED ought to be 80 bits on x86, it should still be 64bits on most other systems. A "maximum" of 3 floating point types are provided names, but systems that don't want that many can equate some of them. In fact..one might argue... 64bit hardware has very efficient 32bit integer and very efficient 64bit integer, you almost want: 32bit: INTEGER = LONGINT = 32bits 64bit: INTEGER = 32bits, LONGINT = 64bits While I doubt that's is where we are heading, it is in fact what all current C environments do, with one exception, if you map "int" = "INTEGER", "long" = "LONGINT". (The exception is Win64.) But Modula-3 has subranges and packed types, so I guess: INT32 = BITS 32 for [16_80000000..16_7FFFFFFF]; suffices? - Jay > To: hosking at cs.purdue.edu > Date: Tue, 20 Apr 2010 11:07:15 -0700 > From: mika at async.async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] INTEGER > > Tony Hosking writes: > >On 20 Apr 2010, at 13:12, Mika Nystrom wrote: > ... > >> easy access to the hardware in their own machines, not really so that = > >IBM > >> programmers could have an extra format for VAX compatibility. Note = > >that > >> I don't believe that it was intended that EXTENDED would be emulated = > >by > >> the compiler either: the point was really to give programmers access = > >to > >> the formats provided efficiently by their hardware. > > > >In the current implementation EXTENDED=3DLONGREAL. > > Ok, but EXTENDED is still something that is efficiently provided by > my hardware. Not something efficiently provided by someone else's > hardware! > > >> 4. I still haven't seen any really convincing use cases. What's it = > >for? > >> The lack of LONGINT was an obstacle to what, precisely? > > > >I think the only one we have is file sizes... > > > >> 5. Finally, is it the intention that LONGINT be fixed at 64 bits > >> forevermore? (See point 2.) This seems to completely fly in the face > >> of M3's philosophy. (See Hendrik's arguments.) > > > >The only constraint imposed is BITSIZE(LONGINT) >=3D BITSIZE(INTEGER). > > I am not so sure here. > > Rodney's argument has in fact convinced me that the current version of > LONGINT is wrong and perhaps evil. It should either go away completely > or be replaced by Hendrik's suggestion. > > Here's why. The argument is that if I have an N-bit machine, for N out there in the world there is an M-bit machine that for some reason > matters a great deal to me. For some reason I need to be able to write > code that manipulates M-bit integers---because of the existence of this > M-bit machine (or machines)! (Normally we're dealing with the situation > that N=32 and M=64.) So we introduce an M-bit LONGINT. Now it stands to > reason that if the M-bit machine (which I do not own and upon which my > program does not run) is important to me, it is also important to other > Modula-3 programmers. Hence all other implementations of Modula-3 will > *also* provide M-bit integers. > > The M-bit machine of the previous paragraph is of course, in the real > world, a machine with the 64-bit version of the Intel x86 instruction set, > "amd64". How long is it from here to the point where we have programmers > who write code that depends on the fact that M=64, always? > > Mika > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Tue Apr 20 20:00:40 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 20 Apr 2010 14:00:40 -0400 Subject: [M3devel] INTEGER In-Reply-To: <4BCDCF7D.604@lcwb.coop> References: <20100418024703.6965B1A2103@async.async.caltech.edu> <20100418074927.934461A2117@async.async.caltech.edu> <04EB7FF8-D304-428D-839E-233FCE009C98@cs.purdue.edu> <20100418195901.CDACB1A20F6@async.async.caltech.edu> <20100419155702.GB8759@topoi.pooq.com> <4BCDCF7D.604@lcwb.coop> Message-ID: <20100420180040.GA13012@topoi.pooq.com> On Tue, Apr 20, 2010 at 10:59:57AM -0500, Rodney M. Bates wrote: > > > hendrik at topoi.pooq.com wrote: >> On Sun, Apr 18, 2010 at 12:59:01PM -0700, Mika Nystrom wrote: >>> And the new m3tk, stubgen, and compiler(?) won't compile using PM3 or >>> SRC M3 since we're no longer using the language of the Green Book. >>> (Same comment goes for WIDECHAR, by the way.) >> >> When I use Unicode characters, I find myself defining them to be >> INTEGERs, because I'm always worried that WIDECHARs might be omly 16 >> bits. > > Actually, I favor making WIDECHAR big enough to hold all the defined > Unicode values, which I understand have been more that 2^16 for some > time now. The only thing the language definition says about WIDECHAR > is that it has at least 65536 values and the first 65536 correspond to > the first 65536 Unicode characters. It could be bigger. Moreover, as > I recall from a while back, the compiler, old and new Text implementation, > other libraries, m3gdb, and maybe pickles are only a couple of declaration > changes away from supporting some bigger range for WIDECHAR. > > (I think I am the one who put WIDECHAR into the language reference, and > that was only recently, despite its being in the cm3 language for years. I > also see that this has not propagated from the .tex version into the .html > and .pdf files.) > > >> >> Strings of WIDECHARS are probably unnecesary. The last program I wrote >> that used Unicode used INTEGERs for characters, and arrays of INTEGERS >> for strings. But I think it was a mistake to do it this way, and when >> I have time I'll rewrite it. UTF-8 seems to be the way to go; strings >> of Unicode can easily be manipulated as ordinary TEXT. In fact, I >> think there are few if any places in my code where I would have had to >> do anything special whatsoever if I had just used UTF8 in TEXT. The >> program would simply become simpler. > > This is only true if you handle strings in certain common but restricted > ways. If you just move strings around, UTF-8 will often work with little > or no code change. OTOH, if you need to access characters non-sequentially > or make any examination or production of individual characters not in the > Iso-latin-1 subset, any variable-length encoding quickly becomes unworkable. Whe you are doing things like this, you are probably doing something like -- shall I say it? -- *parsing*. There's no need for parsing to stop at the character level. You might as well parse all the way down to bytes. And UTF-8 is designed so that that is particularly easy. > > Text.Sub and Text.GetChar won't work in any sensible way if they view the > string as a string of 8-bit bytes, when it's actually not. Reimplementing > these to understand UTF-8 would make what was O(1) become O(n). > Ditto Text.Length. Exactly. That's why you leave them as byte operations. It's pretty rare that you want to pull six characters out of a string. It's pretty common that you want to pull a word out of a string, having parsed part of it and discovering that the work is n characters wide. You could instead have parsed it and discovered that it is m bytes long. The point is, that it's almost never worthwhile to parse it once and turn it into an array of WIDECHARS and then to parse the result again. Just like compilers -- they don't start by lexically scanning the entire source code and storing it somewhere, and then parsing it afterward. Not normally, anyway. -- hendrik From jay.krell at cornell.edu Wed Apr 21 09:56:22 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 21 Apr 2010 07:56:22 +0000 Subject: [M3devel] Alpha is 32bits! Message-ID: Huh. I found that OpenVMS on Alpha is a hybrid 32bit/64bit system. The default pointer size is 32 bits. You can change it to 64 bits with compiler command line option. I guess this is for greater compatibility with VAX. There are two of many functions. Some are missing in 64 bits. size_t is always 32 bits! http://www.openvms.compaq.com/doc/72final/6467/6467pro_contents.html esp. http://www.openvms.compaq.com/doc/72final/6467/6467pro_006.html#64_bit_obtaining_long_ptrs_sec and newer similar: http://www.openvms.compaq.com/doc/83final/5763/5763pro_007.html#the_64_bit_sec WALLIS> type jmpbuf.c #include #include #include #define SIZE(x) ((unsigned)sizeof(x)) int main() { ? printf("%u %u %u %u %u\n", ??? SIZE(int), ??? SIZE(long), ??? SIZE(void*), ??? SIZE(size_t), ??? SIZE(jmp_buf)); ? return 0; } WALLIS> cc jmpbuf.c WALLIS> link jmpbuf.obj WALLIS> run jmpbuf 4 4 4 4 544 WALLIS> cc /pointer_size=64 jmpbuf.c WALLIS> link jmpbuf.obj WALLIS> run jmpbuf 4 4 8 4 544 I still haven't found the actual header files! So I'm going to work toward ALPHA32_VMS for now. I can try ALPHA64_VMS later. Assuming m3cg offers -m32 and -m64 to handle this. :) ?- Jay From mika at async.async.caltech.edu Wed Apr 21 10:10:22 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Wed, 21 Apr 2010 01:10:22 -0700 Subject: [M3devel] Alpha is 32bits! In-Reply-To: References: Message-ID: <20100421081022.358C01A20E1@async.async.caltech.edu> I remember that DEC cc had options on OSF/1 to use memory in such a way that you could guarantee the first 4 GB you touched were sign-extended 32-bit numbers (so the upper doubleword was 0xffffffff or 0x00000000 always) for some sort of compatibility. But Alpha doesn't have hardware instructions to do memory references with 32-bit pointers as far as I remember. I have the architecture reference here to look in... Mika Jay K writes: > >Huh. I found that OpenVMS on Alpha is a hybrid 32bit/64bit system. > >The default pointer size is 32 bits. You can change it to 64 bits with comp= >iler command line option. >I guess this is for greater compatibility with VAX. >There are two of many functions. Some are missing in 64 bits. >size_t is always 32 bits! > >http://www.openvms.compaq.com/doc/72final/6467/6467pro_contents.html >esp. http://www.openvms.compaq.com/doc/72final/6467/6467pro_006.html#64_bit= >_obtaining_long_ptrs_sec > >and newer similar: http://www.openvms.compaq.com/doc/83final/5763/5763pro_0= >07.html#the_64_bit_sec > >WALLIS> type jmpbuf.c > >#include > >#include > >#include > > > >#define SIZE(x) ((unsigned)sizeof(x)) > > > >int main() > >{ > >=A0 printf("%u %u %u %u %u\n"=2C > >=A0=A0=A0 SIZE(int)=2C > >=A0=A0=A0 SIZE(long)=2C > >=A0=A0=A0 SIZE(void*)=2C > >=A0=A0=A0 SIZE(size_t)=2C > >=A0=A0=A0 SIZE(jmp_buf))=3B > >=A0 return 0=3B > >} > > > >WALLIS> cc jmpbuf.c > >WALLIS> link jmpbuf.obj > >WALLIS> run jmpbuf > >4 4 4 4 544 > > > >WALLIS> cc /pointer_size=3D64 jmpbuf.c > >WALLIS> link jmpbuf.obj > >WALLIS> run jmpbuf > >4 4 8 4 544 > > > >I still haven't found the actual header files! > > >So I'm going to work toward ALPHA32_VMS for now. >I can try ALPHA64_VMS later. >Assuming m3cg offers -m32 and -m64 to handle this. :) > >=A0- Jay > = From jay.krell at cornell.edu Wed Apr 21 10:56:29 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 21 Apr 2010 08:56:29 +0000 Subject: [M3devel] Alpha is 32bits! In-Reply-To: <20100421081022.358C01A20E1@async.async.caltech.edu> References: , <20100421081022.358C01A20E1@async.async.caltech.edu> Message-ID: I believe registers are always 64bits, pointers are sign extended, memory is sure to be allocated in the top/bottom 2GB. The two types of functions can call each other, and 32bit pointers can be passed to functions expecting 64bit pointers. It looks like gcc supports alpha-dec-vms => 32bit and alpha64-dec-vms => 64bits. I'm going to introduce ALPHA32_VMS and ALPHA64_VMS but probably work more on the first initially. ?- Jay ---------------------------------------- > To: jay.krell at cornell.edu > Date: Wed, 21 Apr 2010 01:10:22 -0700 > From: mika at async.async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Alpha is 32bits! > > > > I remember that DEC cc had options on OSF/1 to use memory in such a > way that you could guarantee the first 4 GB you touched were sign-extended > 32-bit numbers (so the upper doubleword was 0xffffffff or 0x00000000 always) > for some sort of compatibility. > > But Alpha doesn't have hardware instructions to do memory references with > 32-bit pointers as far as I remember. I have the architecture reference > here to look in... > > Mika > > Jay K writes: >> >>Huh. I found that OpenVMS on Alpha is a hybrid 32bit/64bit system. >> >>The default pointer size is 32 bits. You can change it to 64 bits with comp= >>iler command line option. >>I guess this is for greater compatibility with VAX. >>There are two of many functions. Some are missing in 64 bits. >>size_t is always 32 bits! >> >>http://www.openvms.compaq.com/doc/72final/6467/6467pro_contents.html >>esp. http://www.openvms.compaq.com/doc/72final/6467/6467pro_006.html#64_bit= >>_obtaining_long_ptrs_sec >> >>and newer similar: http://www.openvms.compaq.com/doc/83final/5763/5763pro_0= >>07.html#the_64_bit_sec >> >>WALLIS> type jmpbuf.c >> >>#include >> >>#include >> >>#include >> >> >> >>#define SIZE(x) ((unsigned)sizeof(x)) >> >> >> >>int main() >> >>{ >> >>=A0 printf("%u %u %u %u %u\n"=2C >> >>=A0=A0=A0 SIZE(int)=2C >> >>=A0=A0=A0 SIZE(long)=2C >> >>=A0=A0=A0 SIZE(void*)=2C >> >>=A0=A0=A0 SIZE(size_t)=2C >> >>=A0=A0=A0 SIZE(jmp_buf))=3B >> >>=A0 return 0=3B >> >>} >> >> >> >>WALLIS> cc jmpbuf.c >> >>WALLIS> link jmpbuf.obj >> >>WALLIS> run jmpbuf >> >>4 4 4 4 544 >> >> >> >>WALLIS> cc /pointer_size=3D64 jmpbuf.c >> >>WALLIS> link jmpbuf.obj >> >>WALLIS> run jmpbuf >> >>4 4 8 4 544 >> >> >> >>I still haven't found the actual header files! >> >> >>So I'm going to work toward ALPHA32_VMS for now. >>I can try ALPHA64_VMS later. >>Assuming m3cg offers -m32 and -m64 to handle this. :) >> >>=A0- Jay >> = From rodney_bates at lcwb.coop Wed Apr 21 16:55:29 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Wed, 21 Apr 2010 09:55:29 -0500 Subject: [M3devel] INTEGER In-Reply-To: <20100420180715.52C391A2103@async.async.caltech.edu> References: , , , , , , <20100418023535.3BA9E1A2103@async.async.caltech.edu>, , , , <20100418024703.6965B1A2103@async.async.caltech.edu>, , <20100418074927.934461A2117@async.async.caltech.edu>, <04EB7FF8-D304-428D-839E-233FCE009C98@cs.purdue.edu>, <20100418195901.CDACB1A20F6@async.async.caltech.edu>, , <20100419172313.68B241A20D6@async.async.caltech.edu>, <4F3EE437-0298-410B-9642-C0381E333430@cs.purdue.edu> <20100419223152.3D7331A2122@async.async.caltech.edu> <4BCDC866.6050804@lcwb.coop> <20100420171235! .B8F0C1A2103@async.async.caltech.edu> <20100420180715.52C391A2103@async.async.caltech.edu> Message-ID: <4BCF11E1.5090609@lcwb.coop> Mika Nystrom wrote: > Tony Hosking writes: >> On 20 Apr 2010, at 13:12, Mika Nystrom wrote: > ... >>> easy access to the hardware in their own machines, not really so that = >> IBM >>> programmers could have an extra format for VAX compatibility. Note = >> that >>> I don't believe that it was intended that EXTENDED would be emulated = >> by >>> the compiler either: the point was really to give programmers access = >> to >>> the formats provided efficiently by their hardware. >> In the current implementation EXTENDED=3DLONGREAL. > > Ok, but EXTENDED is still something that is efficiently provided by > my hardware. Not something efficiently provided by someone else's > hardware! > >>> 4. I still haven't seen any really convincing use cases. What's it = >> for? >>> The lack of LONGINT was an obstacle to what, precisely? >> I think the only one we have is file sizes... >> >>> 5. Finally, is it the intention that LONGINT be fixed at 64 bits >>> forevermore? (See point 2.) This seems to completely fly in the face >>> of M3's philosophy. (See Hendrik's arguments.) >> The only constraint imposed is BITSIZE(LONGINT) >=3D BITSIZE(INTEGER). > > I am not so sure here. > > Rodney's argument has in fact convinced me that the current version of > LONGINT is wrong and perhaps evil. It should either go away completely > or be replaced by Hendrik's suggestion. > > Here's why. The argument is that if I have an N-bit machine, for N out there in the world there is an M-bit machine that for some reason > matters a great deal to me. For some reason I need to be able to write > code that manipulates M-bit integers---because of the existence of this > M-bit machine (or machines)! It has never been motivated by the existence of machines with various native arithmetic sizes. It is about problems that need big value ranges to work. Its also about making it convenient to write portable code that solves them. (Well, that part does have to do with the machines that exist.) And making the type checking, etc. not change on the different machines. And using the most efficient arithmetic consistent with correct answers. Normally we're dealing with the situation > that N=32 and M=64.) So we introduce an M-bit LONGINT. Now it stands to > reason that if the M-bit machine (which I do not own and upon which my > program does not run) is important to me, it is also important to other > Modula-3 programmers. Hence all other implementations of Modula-3 will > *also* provide M-bit integers. > > The M-bit machine of the previous paragraph is of course, in the real > world, a machine with the 64-bit version of the Intel x86 instruction set, > "amd64". How long is it from here to the point where we have programmers > who write code that depends on the fact that M=64, always? LONGINT presents the same opportunity/invitation/temptation to write code that make such assumptions as does INTEGER, or for that matter, REFANY, or gobs of other things in the original language. So LONGINT is just as evil as INTEGER. > > Mika > > From hendrik at topoi.pooq.com Wed Apr 21 20:56:31 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Wed, 21 Apr 2010 14:56:31 -0400 Subject: [M3devel] INTEGER In-Reply-To: <4BCF11E1.5090609@lcwb.coop> References: <4F3EE437-0298-410B-9642-C0381E333430@cs.purdue.edu> <20100419223152.3D7331A2122@async.async.caltech.edu> <4BCDC866.6050804@lcwb.coop> <20100420171235!.B8F0C1A2103@async.async.caltech.edu> <20100420180715.52C391A2103@async.async.caltech.edu> <4BCF11E1.5090609@lcwb.coop> Message-ID: <20100421185631.GA17051@topoi.pooq.com> On Wed, Apr 21, 2010 at 09:55:29AM -0500, Rodney M. Bates wrote: > > > Mika Nystrom wrote: >> Tony Hosking writes: >>> On 20 Apr 2010, at 13:12, Mika Nystrom wrote: >> ... >>>> easy access to the hardware in their own machines, not really so that = >>> IBM >>>> programmers could have an extra format for VAX compatibility. Note = >>> that >>>> I don't believe that it was intended that EXTENDED would be emulated = >>> by >>>> the compiler either: the point was really to give programmers access = >>> to >>>> the formats provided efficiently by their hardware. >>> In the current implementation EXTENDED=3DLONGREAL. >> >> Ok, but EXTENDED is still something that is efficiently provided by >> my hardware. Not something efficiently provided by someone else's >> hardware! >> >>>> 4. I still haven't seen any really convincing use cases. What's it = >>> for? >>>> The lack of LONGINT was an obstacle to what, precisely? >>> I think the only one we have is file sizes... >>> >>>> 5. Finally, is it the intention that LONGINT be fixed at 64 bits >>>> forevermore? (See point 2.) This seems to completely fly in the face >>>> of M3's philosophy. (See Hendrik's arguments.) >>> The only constraint imposed is BITSIZE(LONGINT) >=3D BITSIZE(INTEGER). >> >> I am not so sure here. >> >> Rodney's argument has in fact convinced me that the current version of >> LONGINT is wrong and perhaps evil. It should either go away completely >> or be replaced by Hendrik's suggestion. >> >> Here's why. The argument is that if I have an N-bit machine, for N> out there in the world there is an M-bit machine that for some reason >> matters a great deal to me. For some reason I need to be able to write >> code that manipulates M-bit integers---because of the existence of this >> M-bit machine (or machines)! > > It has never been motivated by the existence of machines with various native > arithmetic sizes. It is about problems that need big value ranges to work. > > Its also about making it convenient to write portable code that solves > them. (Well, that part does have to do with the machines that exist.) > And making the type checking, etc. not change on the different machines. > And using the most efficient arithmetic consistent with correct answers. > > Normally we're dealing with the situation >> that N=32 and M=64.) So we introduce an M-bit LONGINT. Now it stands to >> reason that if the M-bit machine (which I do not own and upon which my >> program does not run) is important to me, it is also important to other >> Modula-3 programmers. Hence all other implementations of Modula-3 will >> *also* provide M-bit integers. >> >> The M-bit machine of the previous paragraph is of course, in the real >> world, a machine with the 64-bit version of the Intel x86 instruction set, >> "amd64". How long is it from here to the point where we have programmers >> who write code that depends on the fact that M=64, always? > > LONGINT presents the same opportunity/invitation/temptation to > write code that make such assumptions as does INTEGER, or for that matter, > REFANY, or gobs of other things in the original language. So LONGINT is > just as evil as INTEGER. Which is why I'd allow only subranges of LONGINT to be mentioned in programs. -- hendrik > >> >> Mika >> >> From hosking at cs.purdue.edu Thu Apr 22 17:57:16 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 22 Apr 2010 11:57:16 -0400 Subject: [M3devel] INTEGER In-Reply-To: <20100421185631.GA17051@topoi.pooq.com> References: <4F3EE437-0298-410B-9642-C0381E333430@cs.purdue.edu> <20100419223152.3D7331A2122@async.async.caltech.edu> <4BCDC866.6050804@lcwb.coop> <20100420171235!.B8F0C1A2103@async.async.caltech.edu> <20100420180715.52C391A2103@async.async.caltech.edu> <4BCF11E1.5090609@lcwb.coop> <20100421185631.GA17051@topoi.pooq.com> Message-ID: <80775CA2-A2FD-40AF-B235-7DB84127762E@cs.purdue.edu> But this is bizarre. What type does an element of a subrange of LONGINT have if not LONGINT? If the subrange has a base type of INTEGER then we need a mapping between the elements of the subrange and the base INTEGER values. But then, values of the LONGINT subrange don't have the same representation as their INTEGER counterpart. All very odd. On 21 Apr 2010, at 14:56, hendrik at topoi.pooq.com wrote: > On Wed, Apr 21, 2010 at 09:55:29AM -0500, Rodney M. Bates wrote: >> >> >> Mika Nystrom wrote: >>> Tony Hosking writes: >>>> On 20 Apr 2010, at 13:12, Mika Nystrom wrote: >>> ... >>>>> easy access to the hardware in their own machines, not really so that = >>>> IBM >>>>> programmers could have an extra format for VAX compatibility. Note = >>>> that >>>>> I don't believe that it was intended that EXTENDED would be emulated = >>>> by >>>>> the compiler either: the point was really to give programmers access = >>>> to >>>>> the formats provided efficiently by their hardware. >>>> In the current implementation EXTENDED=3DLONGREAL. >>> >>> Ok, but EXTENDED is still something that is efficiently provided by >>> my hardware. Not something efficiently provided by someone else's >>> hardware! >>> >>>>> 4. I still haven't seen any really convincing use cases. What's it = >>>> for? >>>>> The lack of LONGINT was an obstacle to what, precisely? >>>> I think the only one we have is file sizes... >>>> >>>>> 5. Finally, is it the intention that LONGINT be fixed at 64 bits >>>>> forevermore? (See point 2.) This seems to completely fly in the face >>>>> of M3's philosophy. (See Hendrik's arguments.) >>>> The only constraint imposed is BITSIZE(LONGINT) >=3D BITSIZE(INTEGER). >>> >>> I am not so sure here. >>> >>> Rodney's argument has in fact convinced me that the current version of >>> LONGINT is wrong and perhaps evil. It should either go away completely >>> or be replaced by Hendrik's suggestion. >>> >>> Here's why. The argument is that if I have an N-bit machine, for N>> out there in the world there is an M-bit machine that for some reason >>> matters a great deal to me. For some reason I need to be able to write >>> code that manipulates M-bit integers---because of the existence of this >>> M-bit machine (or machines)! >> >> It has never been motivated by the existence of machines with various native >> arithmetic sizes. It is about problems that need big value ranges to work. >> >> Its also about making it convenient to write portable code that solves >> them. (Well, that part does have to do with the machines that exist.) >> And making the type checking, etc. not change on the different machines. >> And using the most efficient arithmetic consistent with correct answers. >> >> Normally we're dealing with the situation >>> that N=32 and M=64.) So we introduce an M-bit LONGINT. Now it stands to >>> reason that if the M-bit machine (which I do not own and upon which my >>> program does not run) is important to me, it is also important to other >>> Modula-3 programmers. Hence all other implementations of Modula-3 will >>> *also* provide M-bit integers. >>> >>> The M-bit machine of the previous paragraph is of course, in the real >>> world, a machine with the 64-bit version of the Intel x86 instruction set, >>> "amd64". How long is it from here to the point where we have programmers >>> who write code that depends on the fact that M=64, always? >> >> LONGINT presents the same opportunity/invitation/temptation to >> write code that make such assumptions as does INTEGER, or for that matter, >> REFANY, or gobs of other things in the original language. So LONGINT is >> just as evil as INTEGER. > > Which is why I'd allow only subranges of LONGINT to be mentioned in > programs. > > -- hendrik > >> >>> >>> Mika >>> >>> From hendrik at topoi.pooq.com Thu Apr 22 14:38:06 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 22 Apr 2010 08:38:06 -0400 Subject: [M3devel] INTEGER In-Reply-To: <80775CA2-A2FD-40AF-B235-7DB84127762E@cs.purdue.edu> References: <4F3EE437-0298-410B-9642-C0381E333430@cs.purdue.edu> <20100419223152.3D7331A2122@async.async.caltech.edu> <4BCDC866.6050804@lcwb.coop> <20100420171235!.B8F0C1A2103@async.async.caltech.edu> <20100420180715.52C391A2103@async.async.caltech.edu> <4BCF11E1.5090609@lcwb.coop> <20100421185631.GA17051@topoi.pooq.com> <80775CA2-A2FD-40AF-B235-7DB84127762E@cs.purdue.edu> Message-ID: <20100422123805.GA19259@topoi.pooq.com> On Thu, Apr 22, 2010 at 11:57:16AM -0400, Tony Hosking wrote: > But this is bizarre. What type does an element of a subrange of > LONGINT have if not LONGINT? It has LONGINT as a type. > If the subrange has a base type of INTEGER then we need a mapping > between the elements of the subrange and the base INTEGER values. Yes. And INTEGER is different from the notion mathematicians have of integers in that there is a limit on the size of integers. It's a machine or implementation-dependent limit, and it's imposed for efficiency reasons, but it's a specific limit just the same. This limit is precisely what we're up against. > But then, values of the LONGINT subrange don't have the same > representation as their INTEGER counterpart. Of course not. If they did have the same representation, there would be in-range for INTEGERs, and there would be no need to have LONGINT at all. LONGINT is there precisely for the integers that *don't* fit in INTEGER. > > All very odd. But dictated by the intended use -- that of having integral ranges whose bounds are dictated by the problem, not the hardware. -- hendrik From hosking at cs.purdue.edu Thu Apr 22 20:36:17 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 22 Apr 2010 14:36:17 -0400 Subject: [M3devel] INTEGER In-Reply-To: <20100422123805.GA19259@topoi.pooq.com> References: <4F3EE437-0298-410B-9642-C0381E333430@cs.purdue.edu> <20100419223152.3D7331A2122@async.async.caltech.edu> <4BCDC866.6050804@lcwb.coop> <20100420171235!.B8F0C1A2103@async.async.caltech.edu> <20100420180715.52C391A2103@async.async.caltech.edu> <4BCF11E1.5090609@lcwb.coop> <20100421185631.GA17051@topoi.pooq.com> <80775CA2-A2FD-40AF-B235-7DB84127762E@cs.purdue.edu> <20100422123805.GA19259@topoi.pooq.com> Message-ID: <87B45DCC-2B8A-4C69-97D7-240BC1E2252D@cs.purdue.edu> Let me see. The green book definition says the base type of a subrange of INTEGER literals is INTEGER. You say that the base type of a subrange of LONGINT literals is LONGINT. But you say that LONGINT is not a defined type. So, what is the type of a LONGINT literal? ... [I think I misunderstood you previously. I had interpreted that you meant LONGINT subranges to have base type INTEGER.] On 22 Apr 2010, at 08:38, hendrik at topoi.pooq.com wrote: > On Thu, Apr 22, 2010 at 11:57:16AM -0400, Tony Hosking wrote: >> But this is bizarre. What type does an element of a subrange of >> LONGINT have if not LONGINT? > > It has LONGINT as a type. > >> If the subrange has a base type of INTEGER then we need a mapping >> between the elements of the subrange and the base INTEGER values. > > Yes. And INTEGER is different from the notion mathematicians have of > integers in that there is a limit on the size of integers. It's a > machine or implementation-dependent limit, and it's imposed for > efficiency reasons, but it's a specific limit just the same. > This limit is precisely what we're up against. > >> But then, values of the LONGINT subrange don't have the same >> representation as their INTEGER counterpart. > > Of course not. If they did have the same representation, there would be > in-range for INTEGERs, and there would be no need to have LONGINT at > all. > > LONGINT is there precisely for the integers that *don't* fit in INTEGER. > >> >> All very odd. > > But dictated by the intended use -- that of having integral ranges > whose bounds are dictated by the problem, not the hardware. > > -- hendrik From hendrik at topoi.pooq.com Thu Apr 22 16:55:23 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 22 Apr 2010 10:55:23 -0400 Subject: [M3devel] INTEGER In-Reply-To: <87B45DCC-2B8A-4C69-97D7-240BC1E2252D@cs.purdue.edu> References: <20100419223152.3D7331A2122@async.async.caltech.edu> <4BCDC866.6050804@lcwb.coop> <20100420171235!.B8F0C1A2103@async.async.caltech.edu> <20100420180715.52C391A2103@async.async.caltech.edu> <4BCF11E1.5090609@lcwb.coop> <20100421185631.GA17051@topoi.pooq.com> <80775CA2-A2FD-40AF-B235-7DB84127762E@cs.purdue.edu> <20100422123805.GA19259@topoi.pooq.com> <87B45DCC-2B8A-4C69-97D7-240BC1E2252D@cs.purdue.edu> Message-ID: <20100422145522.GA19946@topoi.pooq.com> On Thu, Apr 22, 2010 at 02:36:17PM -0400, Tony Hosking wrote: > Let me see. > > The green book definition says the base type of a subrange of INTEGER literals is INTEGER. > You say that the base type of a subrange of LONGINT literals is LONGINT. > But you say that LONGINT is not a defined type. So, what is the type > of a LONGINT literal? (a) 3849587394875493920398438483929293484L could very well be of type 3849587394875493920398438483929293484L..3849587394875493920398438483929293484L which is a one-element subtype of LONGINT. LONGINY is a type. It's just one that's not available directly to the programmer. It would not need to have a defined size, if the language allowed LONGINT values to occur *only* where an upper bound on their size is known, such as by being elements of a subrange. -- hendrik > > [I think I misunderstood you previously. I had interpreted that you meant LONGINT subranges to have base type INTEGER.] > > On 22 Apr 2010, at 08:38, hendrik at topoi.pooq.com wrote: > > > On Thu, Apr 22, 2010 at 11:57:16AM -0400, Tony Hosking wrote: > >> But this is bizarre. What type does an element of a subrange of > >> LONGINT have if not LONGINT? > > > > It has LONGINT as a type. > > > >> If the subrange has a base type of INTEGER then we need a mapping > >> between the elements of the subrange and the base INTEGER values. > > > > Yes. And INTEGER is different from the notion mathematicians have of > > integers in that there is a limit on the size of integers. It's a > > machine or implementation-dependent limit, and it's imposed for > > efficiency reasons, but it's a specific limit just the same. > > This limit is precisely what we're up against. > > > >> But then, values of the LONGINT subrange don't have the same > >> representation as their INTEGER counterpart. > > > > Of course not. If they did have the same representation, there would be > > in-range for INTEGERs, and there would be no need to have LONGINT at > > all. > > > > LONGINT is there precisely for the integers that *don't* fit in INTEGER. > > > >> > >> All very odd. > > > > But dictated by the intended use -- that of having integral ranges > > whose bounds are dictated by the problem, not the hardware. > > > > -- hendrik > From hosking at cs.purdue.edu Thu Apr 22 21:27:50 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 22 Apr 2010 15:27:50 -0400 Subject: [M3devel] INTEGER In-Reply-To: <20100422145522.GA19946@topoi.pooq.com> References: <20100419223152.3D7331A2122@async.async.caltech.edu> <4BCDC866.6050804@lcwb.coop> <20100420171235!.B8F0C1A2103@async.async.caltech.edu> <20100420180715.52C391A2103@async.async.caltech.edu> <4BCF11E1.5090609@lcwb.coop> <20100421185631.GA17051@topoi.pooq.com> <80775CA2-A2FD-40AF-B235-7DB84127762E@cs.purdue.edu> <20100422123805.GA19259@topoi.pooq.com> <87B45DCC-2B8A-4C69-97D7-240BC1E2252D@cs.purdue.edu> <20100422145522.GA19946@topoi.pooq.com> Message-ID: <28339030-6005-4C28-872C-A68CF24BF4DF@cs.purdue.edu> This is bizarre, and perverts the language definition significantly more than the current scheme. What is the base type of that subrange? On 22 Apr 2010, at 10:55, hendrik at topoi.pooq.com wrote: > On Thu, Apr 22, 2010 at 02:36:17PM -0400, Tony Hosking wrote: >> Let me see. >> >> The green book definition says the base type of a subrange of INTEGER literals is INTEGER. >> You say that the base type of a subrange of LONGINT literals is LONGINT. >> But you say that LONGINT is not a defined type. So, what is the type >> of a LONGINT literal? > > (a) 3849587394875493920398438483929293484L could very well be of type > 3849587394875493920398438483929293484L..3849587394875493920398438483929293484L > which is a one-element subtype of LONGINT. > > LONGINY is a type. It's just one that's not available directly to the > programmer. It would not need to have a defined size, if the language > allowed LONGINT values to occur *only* where an upper bound on > their size is known, such as by being elements of a subrange. > > -- hendrik > >> >> [I think I misunderstood you previously. I had interpreted that you meant LONGINT subranges to have base type INTEGER.] >> >> On 22 Apr 2010, at 08:38, hendrik at topoi.pooq.com wrote: >> >>> On Thu, Apr 22, 2010 at 11:57:16AM -0400, Tony Hosking wrote: >>>> But this is bizarre. What type does an element of a subrange of >>>> LONGINT have if not LONGINT? >>> >>> It has LONGINT as a type. >>> >>>> If the subrange has a base type of INTEGER then we need a mapping >>>> between the elements of the subrange and the base INTEGER values. >>> >>> Yes. And INTEGER is different from the notion mathematicians have of >>> integers in that there is a limit on the size of integers. It's a >>> machine or implementation-dependent limit, and it's imposed for >>> efficiency reasons, but it's a specific limit just the same. >>> This limit is precisely what we're up against. >>> >>>> But then, values of the LONGINT subrange don't have the same >>>> representation as their INTEGER counterpart. >>> >>> Of course not. If they did have the same representation, there would be >>> in-range for INTEGERs, and there would be no need to have LONGINT at >>> all. >>> >>> LONGINT is there precisely for the integers that *don't* fit in INTEGER. >>> >>>> >>>> All very odd. >>> >>> But dictated by the intended use -- that of having integral ranges >>> whose bounds are dictated by the problem, not the hardware. >>> >>> -- hendrik >> From hendrik at topoi.pooq.com Thu Apr 22 17:43:57 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 22 Apr 2010 11:43:57 -0400 Subject: [M3devel] INTEGER In-Reply-To: <28339030-6005-4C28-872C-A68CF24BF4DF@cs.purdue.edu> References: <20100420171235!.B8F0C1A2103@async.async.caltech.edu> <20100420180715.52C391A2103@async.async.caltech.edu> <4BCF11E1.5090609@lcwb.coop> <20100421185631.GA17051@topoi.pooq.com> <80775CA2-A2FD-40AF-B235-7DB84127762E@cs.purdue.edu> <20100422123805.GA19259@topoi.pooq.com> <87B45DCC-2B8A-4C69-97D7-240BC1E2252D@cs.purdue.edu> <20100422145522.GA19946@topoi.pooq.com> <28339030-6005-4C28-872C-A68CF24BF4DF@cs.purdue.edu> Message-ID: <20100422154357.GA20043@topoi.pooq.com> On Thu, Apr 22, 2010 at 03:27:50PM -0400, Tony Hosking wrote: > This is bizarre, and perverts the language definition significantly more than the current scheme. > What is the base type of that subrange? LONGINT. -- hendrik > > On 22 Apr 2010, at 10:55, hendrik at topoi.pooq.com wrote: > > > On Thu, Apr 22, 2010 at 02:36:17PM -0400, Tony Hosking wrote: > >> Let me see. > >> > >> The green book definition says the base type of a subrange of INTEGER literals is INTEGER. > >> You say that the base type of a subrange of LONGINT literals is LONGINT. > >> But you say that LONGINT is not a defined type. So, what is the type > >> of a LONGINT literal? > > > > (a) 3849587394875493920398438483929293484L could very well be of type > > 3849587394875493920398438483929293484L..3849587394875493920398438483929293484L > > which is a one-element subtype of LONGINT. > > > > LONGINY is a type. It's just one that's not available directly to the > > programmer. It would not need to have a defined size, if the language > > allowed LONGINT values to occur *only* where an upper bound on > > their size is known, such as by being elements of a subrange. > > > > -- hendrik > > > >> > >> [I think I misunderstood you previously. I had interpreted that you meant LONGINT subranges to have base type INTEGER.] > >> > >> On 22 Apr 2010, at 08:38, hendrik at topoi.pooq.com wrote: > >> > >>> On Thu, Apr 22, 2010 at 11:57:16AM -0400, Tony Hosking wrote: > >>>> But this is bizarre. What type does an element of a subrange of > >>>> LONGINT have if not LONGINT? > >>> > >>> It has LONGINT as a type. > >>> > >>>> If the subrange has a base type of INTEGER then we need a mapping > >>>> between the elements of the subrange and the base INTEGER values. > >>> > >>> Yes. And INTEGER is different from the notion mathematicians have of > >>> integers in that there is a limit on the size of integers. It's a > >>> machine or implementation-dependent limit, and it's imposed for > >>> efficiency reasons, but it's a specific limit just the same. > >>> This limit is precisely what we're up against. > >>> > >>>> But then, values of the LONGINT subrange don't have the same > >>>> representation as their INTEGER counterpart. > >>> > >>> Of course not. If they did have the same representation, there would be > >>> in-range for INTEGERs, and there would be no need to have LONGINT at > >>> all. > >>> > >>> LONGINT is there precisely for the integers that *don't* fit in INTEGER. > >>> > >>>> > >>>> All very odd. > >>> > >>> But dictated by the intended use -- that of having integral ranges > >>> whose bounds are dictated by the problem, not the hardware. > >>> > >>> -- hendrik > >> > From hosking at cs.purdue.edu Thu Apr 22 21:44:03 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 22 Apr 2010 15:44:03 -0400 Subject: [M3devel] INTEGER In-Reply-To: <20100422154357.GA20043@topoi.pooq.com> References: <20100420171235!.B8F0C1A2103@async.async.caltech.edu> <20100420180715.52C391A2103@async.async.caltech.edu> <4BCF11E1.5090609@lcwb.coop> <20100421185631.GA17051@topoi.pooq.com> <80775CA2-A2FD-40AF-B235-7DB84127762E@cs.purdue.edu> <20100422123805.GA19259@topoi.pooq.com> <87B45DCC-2B8A-4C69-97D7-240BC1E2252D@cs.purdue.edu> <20100422145522.GA19946@topoi.pooq.com> <28339030-6005-4C28-872C-A68CF24BF4DF@cs.purdue.edu> <20100422154357.GA20043@topoi.pooq.com> Message-ID: <270A99B5-173E-413B-8C28-E1CA68870FD4@cs.purdue.edu> Defined as... On 22 Apr 2010, at 11:43, hendrik at topoi.pooq.com wrote: > On Thu, Apr 22, 2010 at 03:27:50PM -0400, Tony Hosking wrote: >> This is bizarre, and perverts the language definition significantly more than the current scheme. >> What is the base type of that subrange? > > LONGINT. > > -- hendrik > >> >> On 22 Apr 2010, at 10:55, hendrik at topoi.pooq.com wrote: >> >>> On Thu, Apr 22, 2010 at 02:36:17PM -0400, Tony Hosking wrote: >>>> Let me see. >>>> >>>> The green book definition says the base type of a subrange of INTEGER literals is INTEGER. >>>> You say that the base type of a subrange of LONGINT literals is LONGINT. >>>> But you say that LONGINT is not a defined type. So, what is the type >>>> of a LONGINT literal? >>> >>> (a) 3849587394875493920398438483929293484L could very well be of type >>> 3849587394875493920398438483929293484L..3849587394875493920398438483929293484L >>> which is a one-element subtype of LONGINT. >>> >>> LONGINY is a type. It's just one that's not available directly to the >>> programmer. It would not need to have a defined size, if the language >>> allowed LONGINT values to occur *only* where an upper bound on >>> their size is known, such as by being elements of a subrange. >>> >>> -- hendrik >>> >>>> >>>> [I think I misunderstood you previously. I had interpreted that you meant LONGINT subranges to have base type INTEGER.] >>>> >>>> On 22 Apr 2010, at 08:38, hendrik at topoi.pooq.com wrote: >>>> >>>>> On Thu, Apr 22, 2010 at 11:57:16AM -0400, Tony Hosking wrote: >>>>>> But this is bizarre. What type does an element of a subrange of >>>>>> LONGINT have if not LONGINT? >>>>> >>>>> It has LONGINT as a type. >>>>> >>>>>> If the subrange has a base type of INTEGER then we need a mapping >>>>>> between the elements of the subrange and the base INTEGER values. >>>>> >>>>> Yes. And INTEGER is different from the notion mathematicians have of >>>>> integers in that there is a limit on the size of integers. It's a >>>>> machine or implementation-dependent limit, and it's imposed for >>>>> efficiency reasons, but it's a specific limit just the same. >>>>> This limit is precisely what we're up against. >>>>> >>>>>> But then, values of the LONGINT subrange don't have the same >>>>>> representation as their INTEGER counterpart. >>>>> >>>>> Of course not. If they did have the same representation, there would be >>>>> in-range for INTEGERs, and there would be no need to have LONGINT at >>>>> all. >>>>> >>>>> LONGINT is there precisely for the integers that *don't* fit in INTEGER. >>>>> >>>>>> >>>>>> All very odd. >>>>> >>>>> But dictated by the intended use -- that of having integral ranges >>>>> whose bounds are dictated by the problem, not the hardware. >>>>> >>>>> -- hendrik >>>> >> From jay.krell at cornell.edu Thu Apr 22 21:38:03 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 22 Apr 2010 19:38:03 +0000 Subject: [M3devel] INTEGER In-Reply-To: <20100422145522.GA19946@topoi.pooq.com> References: <20100419223152.3D7331A2122@async.async.caltech.edu>, <4BCDC866.6050804@lcwb.coop>, <20100420171235!.B8F0C1A2103@async.async.caltech.edu>, , <20100420180715.52C391A2103@async.async.caltech.edu>, <4BCF11E1.5090609@lcwb.coop>, <20100421185631.GA17051@topoi.pooq.com>, <80775CA2-A2FD-40AF-B235-7DB84127762E@cs.purdue.edu>, <20100422123805.GA19259@topoi.pooq.com>, <87B45DCC-2B8A-4C69-97D7-240BC1E2252D@cs.purdue.edu>, <20100422145522.GA19946@topoi.pooq.com> Message-ID: I have to add something. There is another use of LONGINT. Kind of an annoying practical one, and a minor side affect. Not really a nice abstract one. And in fact, it implies a sort of use of "INT128". To declare opaque data with a particular alignment. To match an external definition. Specifically, jmpbuf. Many systems want a 64bit aligned jmpbuf. Even some 32bit ones. e.g. ALPHA32_VMS. But it isn't the only one. There are systems that prefer as high as 128 bit aligned jmpbuf, but I think are ok with less aligned (PPC_LINUX), or not (PA64_HPUX?). I'm not able to declare these today. And C doesn't do this necessarily with larger types, but with other syntax. I think 32bit Linux/ppc says something like: typedef struct __attribute___(align(128)) { /* 32 is ok, but 128 is ideal */ ... } jmpbuf; Ok, details: Oh. Maybe I should use "double" for this purpose? I did sometimes. I forgot. That solves part of the problem, as much as LONGINT solves. http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/C/PA32_HPUX/Csetjmp.i3?rev=1.3;content-type=text%2Fplain (* 200 bytes with 8 byte alignment *) TYPE jmp_buf = ARRAY [0..24] OF double; http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/C/PPC_LINUX/Csetjmp.i3?rev=1.10;content-type=text%2Fplain (* ideal alignment is 16 bytes but 4 is ok; 8 here *) TYPE jmp_buf = ARRAY [0..73] OF LONGINT; http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/C/PA64_HPUX/Csetjmp.i3?rev=1.3;content-type=text%2Fplain (* 640 bytes with 16 byte alignment if we can get it, else 8 byte alignment, which is the best we can ask for (front end internally uses 16 byte alignment) *) TYPE jmp_buf = ARRAY [0..79] OF double; I should use double? Or we should have another way to say this? Or, for that matter, as I've suggested, we shouldn't duplicate the information both in Csetjmp.i3 and Target.m3? Target.m3 has available to it arbitrary alignment. Ok, PPC_LINUX and PA32/64_HPUX were the only ones I could find that want >4 alignment on 32bit, or >8 on 64bit. And 8 on 32 you can get with double. I had forgotten about that technique. I think this is at least another good argument for removing the type declaration from Csetjmp.i3, maybe the function too, and putting it only in Target.m3 (Target.m3 currently only declares setjmp, not longjmp). If not a way to declare alignment in the language. The thing is, you know, the only need for this is to match external/C definitions, and those definitions are now tremendously more under our control than they used to be, so the need to describe "anything" is reduced. Tony is that at all difficult? Injecting the jmpbuf and longjmp information from Target.m3 instead of in Csetjmp.i3? I'll try to get to it. I'd like to further reduce the volume and "wide distribution" of target-specific data. There's still a lot of duplication and non-centralization. - Jay > Date: Thu, 22 Apr 2010 10:55:23 -0400 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] INTEGER > > On Thu, Apr 22, 2010 at 02:36:17PM -0400, Tony Hosking wrote: > > Let me see. > > > > The green book definition says the base type of a subrange of INTEGER literals is INTEGER. > > You say that the base type of a subrange of LONGINT literals is LONGINT. > > But you say that LONGINT is not a defined type. So, what is the type > > of a LONGINT literal? > > (a) 3849587394875493920398438483929293484L could very well be of type > 3849587394875493920398438483929293484L..3849587394875493920398438483929293484L > which is a one-element subtype of LONGINT. > > LONGINY is a type. It's just one that's not available directly to the > programmer. It would not need to have a defined size, if the language > allowed LONGINT values to occur *only* where an upper bound on > their size is known, such as by being elements of a subrange. > > -- hendrik > > > > > [I think I misunderstood you previously. I had interpreted that you meant LONGINT subranges to have base type INTEGER.] > > > > On 22 Apr 2010, at 08:38, hendrik at topoi.pooq.com wrote: > > > > > On Thu, Apr 22, 2010 at 11:57:16AM -0400, Tony Hosking wrote: > > >> But this is bizarre. What type does an element of a subrange of > > >> LONGINT have if not LONGINT? > > > > > > It has LONGINT as a type. > > > > > >> If the subrange has a base type of INTEGER then we need a mapping > > >> between the elements of the subrange and the base INTEGER values. > > > > > > Yes. And INTEGER is different from the notion mathematicians have of > > > integers in that there is a limit on the size of integers. It's a > > > machine or implementation-dependent limit, and it's imposed for > > > efficiency reasons, but it's a specific limit just the same. > > > This limit is precisely what we're up against. > > > > > >> But then, values of the LONGINT subrange don't have the same > > >> representation as their INTEGER counterpart. > > > > > > Of course not. If they did have the same representation, there would be > > > in-range for INTEGERs, and there would be no need to have LONGINT at > > > all. > > > > > > LONGINT is there precisely for the integers that *don't* fit in INTEGER. > > > > > >> > > >> All very odd. > > > > > > But dictated by the intended use -- that of having integral ranges > > > whose bounds are dictated by the problem, not the hardware. > > > > > > -- hendrik > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.async.caltech.edu Fri Apr 23 07:04:24 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Thu, 22 Apr 2010 22:04:24 -0700 Subject: [M3devel] INTEGER In-Reply-To: <4BCF11E1.5090609@lcwb.coop> References: , , , , , , <20100418023535.3BA9E1A2103@async.async.caltech.edu>, , , , <20100418024703.6965B1A2103@async.async.caltech.edu>, , <20100418074927.934461A2117@async.async.caltech.edu>, <04EB7FF8-D304-428D-839E-233FCE009C98@cs.purdue.edu>, <20100418195901.CDACB1A20F6@async.async.caltech.edu>, , <20100419172313.68B241A20D6@async.async.caltech.edu>, <4F3EE437-0298-410B-9642-C0381E333430@cs.purdue.edu> <20100419223152.3D7331A2122@async.async.caltech.edu> <4BCDC866.6050804@lcwb.coop> <20100420171235! .B8F0C1A2103@async.async.caltech.edu> <20100420180715.52C391A2103@async.async.caltech.edu> <4BCF11E1.5090609@lcwb.coop> Message-ID: <20100423050424.77EBE1A2106@async.async.caltech.edu> "Rodney M. Bates" writes: ... >It has never been motivated by the existence of machines with various native >arithmetic sizes. It is about problems that need big value ranges to work. > >Its also about making it convenient to write portable code that solves >them. (Well, that part does have to do with the machines that exist.) >And making the type checking, etc. not change on the different machines. >And using the most efficient arithmetic consistent with correct answers. > >Normally we're dealing with the situation >> that N=32 and M=64.) So we introduce an M-bit LONGINT. Now it stands to >> reason that if the M-bit machine (which I do not own and upon which my >> program does not run) is important to me, it is also important to other >> Modula-3 programmers. Hence all other implementations of Modula-3 will >> *also* provide M-bit integers. >> >> The M-bit machine of the previous paragraph is of course, in the real >> world, a machine with the 64-bit version of the Intel x86 instruction set, >> "amd64". How long is it from here to the point where we have programmers >> who write code that depends on the fact that M=64, always? > >LONGINT presents the same opportunity/invitation/temptation to >write code that make such assumptions as does INTEGER, or for that matter, >REFANY, or gobs of other things in the original language. So LONGINT is >just as evil as INTEGER. It is precisely my point that LONGINT is equally evil as INTEGER. The language doesn't need two "evil" integer types. If there is to be another one (an inefficient one, to boot!) I think it had better offer something that INTEGER does not (such as Hendrik's suggestion). In fact since I have now seen it suggested that LONGINT be at least 64 bits wide, (correct) LONGINT-based code will be *less* portable than (correct) INTEGER code, which is allowed to make no such assumptions and hence has to work whether INTEGER is 16, 32, 36, or even 666 bits wide. Mika From mika at async.async.caltech.edu Fri Apr 23 07:29:35 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Thu, 22 Apr 2010 22:29:35 -0700 Subject: [M3devel] INTEGER In-Reply-To: <80775CA2-A2FD-40AF-B235-7DB84127762E@cs.purdue.edu> References: <4F3EE437-0298-410B-9642-C0381E333430@cs.purdue.edu> <20100419223152.3D7331A2122@async.async.caltech.edu> <4BCDC866.6050804@lcwb.coop> <20100420171235!.B8F0C1A2103@async.async.caltech.edu> <20100420180715.52C391A2103@async.async.caltech.edu> <4BCF11E1.5090609@lcwb.coop> <20100421185631.GA17051@topoi.pooq.com> <80775CA2-A2FD-40AF-B235-7DB84127762E@cs.purdue.edu> Message-ID: <20100423052935.07F7C1A20F1@async.async.caltech.edu> My "proposal" would be TEXT-like bignums. Subranges would have to be based on LONGINT constants. Decree that they are instances of a particular GENERIC INTERFACE maybe. Hrmmm... TYPE Range = [ 1L .. 1000L*1000L*1000L*1000L ]; equivalent to REVEAL LONGINT <: ROOT; TYPE LongInt.T = LONGINT; GENERIC INTERFACE LongIntRange(R); TYPE T = LONGINT BRANDED LongInt.ToText(R.Low) & "_" & LongInt.ToText(R.High) OBJECT END; END LongIntRange. INTERFACE RR; CONST Low = 1L; High = 1000L*1000L*1000L*1000L; END RR. INTERFACE RRType = LongIntRange(RR) END RRType. TYPE Range = RRType.T; or somesuch... hrmph too complicated? It looks a lot like TEXT still. I just introduced a new function that the compiler needs to know: LongInt.ToText. And a fake interface. Ho hum, yes complicated. But it looks like a pretty normal Modula-3 type after these gyrations... Mika Tony Hosking writes: >But this is bizarre. What type does an element of a subrange of LONGINT = >have if not LONGINT? If the subrange has a base type of INTEGER then we = >need a mapping between the elements of the subrange and the base INTEGER = >values. But then, values of the LONGINT subrange don't have the same = >representation as their INTEGER counterpart. > >All very odd. > >On 21 Apr 2010, at 14:56, hendrik at topoi.pooq.com wrote: > >> On Wed, Apr 21, 2010 at 09:55:29AM -0500, Rodney M. Bates wrote: >>>=20 >>>=20 >>> Mika Nystrom wrote: >>>> Tony Hosking writes: >>>>> On 20 Apr 2010, at 13:12, Mika Nystrom wrote: >>>> ... >>>>>> easy access to the hardware in their own machines, not really so = >that =3D >>>>> IBM >>>>>> programmers could have an extra format for VAX compatibility. = >Note =3D >>>>> that >>>>>> I don't believe that it was intended that EXTENDED would be = >emulated =3D >>>>> by >>>>>> the compiler either: the point was really to give programmers = >access =3D >>>>> to >>>>>> the formats provided efficiently by their hardware. >>>>> In the current implementation EXTENDED=3D3DLONGREAL. >>>>=20 >>>> Ok, but EXTENDED is still something that is efficiently provided by >>>> my hardware. Not something efficiently provided by someone else's >>>> hardware! >>>>=20 >>>>>> 4. I still haven't seen any really convincing use cases. What's = >it =3D >>>>> for? >>>>>> The lack of LONGINT was an obstacle to what, precisely? >>>>> I think the only one we have is file sizes... >>>>>=20 >>>>>> 5. Finally, is it the intention that LONGINT be fixed at 64 bits >>>>>> forevermore? (See point 2.) This seems to completely fly in the = >face >>>>>> of M3's philosophy. (See Hendrik's arguments.) >>>>> The only constraint imposed is BITSIZE(LONGINT) >=3D3D = >BITSIZE(INTEGER). >>>>=20 >>>> I am not so sure here. >>>>=20 >>>> Rodney's argument has in fact convinced me that the current version = >of >>>> LONGINT is wrong and perhaps evil. It should either go away = >completely >>>> or be replaced by Hendrik's suggestion. >>>>=20 >>>> Here's why. The argument is that if I have an N-bit machine, for = >N>>> out there in the world there is an M-bit machine that for some = >reason >>>> matters a great deal to me. For some reason I need to be able to = >write >>>> code that manipulates M-bit integers---because of the existence of = >this >>>> M-bit machine (or machines)! =20 >>>=20 >>> It has never been motivated by the existence of machines with various = >native >>> arithmetic sizes. It is about problems that need big value ranges to = >work. >>>=20 >>> Its also about making it convenient to write portable code that = >solves >>> them. (Well, that part does have to do with the machines that exist.) >>> And making the type checking, etc. not change on the different = >machines. >>> And using the most efficient arithmetic consistent with correct = >answers. >>>=20 >>> Normally we're dealing with the situation >>>> that N=3D32 and M=3D64.) So we introduce an M-bit LONGINT. Now it = >stands to >>>> reason that if the M-bit machine (which I do not own and upon which = >my >>>> program does not run) is important to me, it is also important to = >other >>>> Modula-3 programmers. Hence all other implementations of Modula-3 = >will >>>> *also* provide M-bit integers. =20 >>>>=20 >>>> The M-bit machine of the previous paragraph is of course, in the = >real >>>> world, a machine with the 64-bit version of the Intel x86 = >instruction set, >>>> "amd64". How long is it from here to the point where we have = >programmers >>>> who write code that depends on the fact that M=3D64, always? >>>=20 >>> LONGINT presents the same opportunity/invitation/temptation to >>> write code that make such assumptions as does INTEGER, or for that = >matter, >>> REFANY, or gobs of other things in the original language. So LONGINT = >is >>> just as evil as INTEGER. >>=20 >> Which is why I'd allow only subranges of LONGINT to be mentioned in=20 >> programs. >>=20 >> -- hendrik >>=20 >>>=20 >>>>=20 >>>> Mika >>>>=20 >>>>=20 From mika at async.async.caltech.edu Fri Apr 23 07:38:51 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Thu, 22 Apr 2010 22:38:51 -0700 Subject: [M3devel] INTEGER In-Reply-To: References: <20100419223152.3D7331A2122@async.async.caltech.edu>, <4BCDC866.6050804@lcwb.coop>, <20100420171235!.B8F0C1A2103@async.async.caltech.edu>, , <20100420180715.52C391A2103@async.async.caltech.edu>, <4BCF11E1.5090609@lcwb.coop>, <20100421185631.GA17051@topoi.pooq.com>, <80775CA2-A2FD-40AF-B235-7DB84127762E@cs.purdue.edu>, <20100422123805.GA19259@topoi.pooq.com>, <87B45DCC-2B8A-4C69-97D7-240BC1E2252D@cs.purdue.edu>, <20100422145522.GA19946@topoi.pooq.com> Message-ID: <20100423053851.DB8DB1A20CF@async.async.caltech.edu> Jay K writes: >--_7f0c333b-7807-4538-bdd6-306666b4a0e7_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >I have to add something. There is another use of LONGINT. > >Kind of an annoying practical one=2C and a minor side affect. Not really a = >nice abstract one. > >And in fact=2C it implies a sort of use of "INT128". > >=20 > >=20 > >To declare opaque data with a particular alignment. > >=20 > >=20 > >To match an external definition. > >Specifically=2C jmpbuf. > >Many systems want a 64bit aligned jmpbuf. But does Modula-3 *allocate* jmpbufs? If not, why does the declaration have to record that C is guaranteed to allocate the jmpbufs with a certain alignment? I don't think this type of stuff belongs anywhere near the language definition. If it's really needed it ought to be in compiler pragmas. (I think.) Mika From wagner at elegosoft.com Fri Apr 23 09:52:08 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 23 Apr 2010 09:52:08 +0200 Subject: [M3devel] type in m3tests/src/m3makefile Message-ID: <20100423095208.ut3mklu58gkg00kw@mail.elegosoft.com> It seems I've just committed a syntax error to the m3tests makefile this morning: "/ad0e/home/hudson/workspace/cm3-test-m3tests-AMD64_FREEBSD/cm3/m3-sys/m3tests/AMD64_FREEBSD/m3make.args", line 5: quake runtime error: /ad0e/home/hudson/workspace/cm3-test-m3tests-AMD64_FREEBSD/cm3/m3-sys/m3tests/src/m3makefile, line 331: syntax error: missing: ] (found: ) This is on the release branch. I can only fix it tonight. If anybody is faster, that would be welcome. 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 hendrik at topoi.pooq.com Fri Apr 23 11:49:03 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 23 Apr 2010 05:49:03 -0400 Subject: [M3devel] INTEGER In-Reply-To: <270A99B5-173E-413B-8C28-E1CA68870FD4@cs.purdue.edu> References: <20100420180715.52C391A2103@async.async.caltech.edu> <4BCF11E1.5090609@lcwb.coop> <20100421185631.GA17051@topoi.pooq.com> <80775CA2-A2FD-40AF-B235-7DB84127762E@cs.purdue.edu> <20100422123805.GA19259@topoi.pooq.com> <87B45DCC-2B8A-4C69-97D7-240BC1E2252D@cs.purdue.edu> <20100422145522.GA19946@topoi.pooq.com> <28339030-6005-4C28-872C-A68CF24BF4DF@cs.purdue.edu> <20100422154357.GA20043@topoi.pooq.com> <270A99B5-173E-413B-8C28-E1CA68870FD4@cs.purdue.edu> Message-ID: <20100423094903.GC21281@topoi.pooq.com> On Thu, Apr 22, 2010 at 03:44:03PM -0400, Tony Hosking wrote: > Defined as... A type whose values are integers. If it's only used as subranges, its infinite extent is not an implementation difficulty. -- hendrik > > On 22 Apr 2010, at 11:43, hendrik at topoi.pooq.com wrote: > > > On Thu, Apr 22, 2010 at 03:27:50PM -0400, Tony Hosking wrote: > >> This is bizarre, and perverts the language definition significantly more than the current scheme. > >> What is the base type of that subrange? > > > > LONGINT. > > > > -- hendrik > > k From mika at async.async.caltech.edu Fri Apr 23 20:52:14 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Fri, 23 Apr 2010 11:52:14 -0700 Subject: [M3devel] INTEGER In-Reply-To: <20100423094903.GC21281@topoi.pooq.com> References: <20100420180715.52C391A2103@async.async.caltech.edu> <4BCF11E1.5090609@lcwb.coop> <20100421185631.GA17051@topoi.pooq.com> <80775CA2-A2FD-40AF-B235-7DB84127762E@cs.purdue.edu> <20100422123805.GA19259@topoi.pooq.com> <87B45DCC-2B8A-4C69-97D7-240BC1E2252D@cs.purdue.edu> <20100422145522.GA19946@topoi.pooq.com> <28339030-6005-4C28-872C-A68CF24BF4DF@cs.purdue.edu> <20100422154357.GA20043@topoi.pooq.com> <270A99B5-173E-413B-8C28-E1CA68870FD4@cs.purdue.edu> <20100423094903.GC21281@topoi.pooq.com> Message-ID: <20100423185214.BA2EF1A20E1@async.async.caltech.edu> Is the infinite extent of the TEXT type a serious implementation difficulty? :-) Mika hendrik at topoi.pooq.com writes: >On Thu, Apr 22, 2010 at 03:44:03PM -0400, Tony Hosking wrote: >> Defined as... > >A type whose values are integers. If it's only used as subranges, >its infinite extent is not an implementation difficulty. > >-- hendrik > >> >> On 22 Apr 2010, at 11:43, hendrik at topoi.pooq.com wrote: >> >> > On Thu, Apr 22, 2010 at 03:27:50PM -0400, Tony Hosking wrote: >> >> This is bizarre, and perverts the language definition significantly more than the current scheme. >> >> What is the base type of that subrange? >> > >> > LONGINT. >> > >> > -- hendrik >> > >k From jay.krell at cornell.edu Fri Apr 23 22:29:57 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 23 Apr 2010 20:29:57 +0000 Subject: [M3devel] word vs. long vs. pointer in parse.c Message-ID: I believe where parse.c uses BITS_PER_WORD, it should use POINTER_SIZE. The docs allude that "word" is a register. On Alpha32, that is 64 bits. However on Alpha32, LONG_SIZE and POINTER_SIZE are 32. This leads to assertion failures in parse.c about the type to the set functions being t_int. I imagine Alpha32 is a little strange, but that it exists for better source compatibility with VAX and maybe even HP-UX, and to keep data stored in memory and on disk smaller where 32bits suffices. (IA64 has 32bit modes also, I forgot if in HP-UX or VMS or both. Not necessarily hardware modes, but code gen modes. I wasn't planning on an IA6432_HPUX, IA6432_VMS ports though, just IA64_HPUX and IA64_VMS) The assertion failures went away when I tried LONG_SIZE. For purposes of AMD64_MINGW though, LONG_SIZE might be wrong and POINTER_SIZE the all around answer. I still have to test this on other platforms. That leaves I think just atomics failing all over for ALPHA32_VMS. ALPHA64_VMS I can already produce all the assembly for cm3 (including atomics apparently). I haven't yet assembled/linked/run it. Doing native-hosted builds of cm3cg might not be viable. (Since I haven't assembled/linked, and didn't look at the code, could be the atomics are function calls.) Another strange thing I think I saw is that sizeof(long,size_t,ptrdiff_t) with cc /pointer_size=64 is 4, but with alpha64-dec-vms-gcc it is 8. I think we might want something like: #if __pointer_size == 64 /* whatever cc /pointer_size=64 defines */ typedef __int64 INTEGER; typedef unsigned __int64 WORD; #else typedef ptrdiff_t INTEGER; typedef size_t WORD; #endif and use INTEGER and WORD whenever C code is interoperating with Modula-3. Maybe just punt ALPHA32_VMS? These systems don't have gobs of memory by modern standards -- the one I'm using is multi-user and has 768MB -- so the smaller data size might be worthwhile over ALPHA64_VMS. ? The platform seems fairly viable so far though. - Jay From hendrik at topoi.pooq.com Fri Apr 23 18:56:13 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 23 Apr 2010 12:56:13 -0400 Subject: [M3devel] INTEGER In-Reply-To: <20100423185214.BA2EF1A20E1@async.async.caltech.edu> References: <20100421185631.GA17051@topoi.pooq.com> <80775CA2-A2FD-40AF-B235-7DB84127762E@cs.purdue.edu> <20100422123805.GA19259@topoi.pooq.com> <87B45DCC-2B8A-4C69-97D7-240BC1E2252D@cs.purdue.edu> <20100422145522.GA19946@topoi.pooq.com> <28339030-6005-4C28-872C-A68CF24BF4DF@cs.purdue.edu> <20100422154357.GA20043@topoi.pooq.com> <270A99B5-173E-413B-8C28-E1CA68870FD4@cs.purdue.edu> <20100423094903.GC21281@topoi.pooq.com> <20100423185214.BA2EF1A20E1@async.async.caltech.edu> Message-ID: <20100423165613.GA22126@topoi.pooq.com> On Fri, Apr 23, 2010 at 11:52:14AM -0700, Mika Nystrom wrote: > > Is the infinite extent of the TEXT type a serious implementation difficulty? :-) Yes, actually. It requires heap storage allocation and indirection. That's just what it costs, so we pay it, since fixed-width strings aren't all that useful. But integer ranges of a size that matches the application (instead of the hardware) are quite feasible and useful; I'd rather not pay the proce of dynamic heap allocation for each integer. -- hendrik > > Mika > > hendrik at topoi.pooq.com writes: > >On Thu, Apr 22, 2010 at 03:44:03PM -0400, Tony Hosking wrote: > >> Defined as... > > > >A type whose values are integers. If it's only used as subranges, > >its infinite extent is not an implementation difficulty. > > > >-- hendrik > > > >> > >> On 22 Apr 2010, at 11:43, hendrik at topoi.pooq.com wrote: > >> > >> > On Thu, Apr 22, 2010 at 03:27:50PM -0400, Tony Hosking wrote: > >> >> This is bizarre, and perverts the language definition significantly more than the current scheme. > >> >> What is the base type of that subrange? > >> > > >> > LONGINT. > >> > > >> > -- hendrik > >> > > >k From mika at async.async.caltech.edu Sat Apr 24 12:34:35 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Sat, 24 Apr 2010 03:34:35 -0700 Subject: [M3devel] INTEGER In-Reply-To: <20100423165613.GA22126@topoi.pooq.com> References: <20100421185631.GA17051@topoi.pooq.com> <80775CA2-A2FD-40AF-B235-7DB84127762E@cs.purdue.edu> <20100422123805.GA19259@topoi.pooq.com> <87B45DCC-2B8A-4C69-97D7-240BC1E2252D@cs.purdue.edu> <20100422145522.GA19946@topoi.pooq.com> <28339030-6005-4C28-872C-A68CF24BF4DF@cs.purdue.edu> <20100422154357.GA20043@topoi.pooq.com> <270A99B5-173E-413B-8C28-E1CA68870FD4@cs.purdue.edu> <20100423094903.GC21281@topoi.pooq.com> <20100423185214.BA2EF1A20E1@async.async.caltech.edu> <20100423165613.GA22126@topoi.pooq.com> Message-ID: <20100424103435.A1CC41A20C2@async.async.caltech.edu> hendrik at topoi.pooq.com writes: >On Fri, Apr 23, 2010 at 11:52:14AM -0700, Mika Nystrom wrote: >> >> Is the infinite extent of the TEXT type a serious implementation difficulty? :-) > >Yes, actually. It requires heap storage allocation and indirection. That's just what >it costs, so we pay it, since fixed-width strings aren't all that useful. > >But integer ranges of a size that matches the application (instead of the hardware) >are quite feasible and useful; I'd rather not pay the proce of dynamic heap allocation >for each integer. > >-- hendrik Ok here I have a proposal, modeled on how Modula-3 does arrays. The type specifier LONGINT to be valid in every context where an open array is valid. A subrange of LONGINT to be treated like a non-open array. NEW(REF LONGINT, ..) would take two "size" specifiers, a minimum and a maximum, of type LONGINT. For L, U, LONGINT literals, NEW(REF LONGINT, L, U) would produce the same thing as NEW(REF [L..U]) NEW(REF LONGINT, ..) is needed for dynamically sized LONGINTs. And then overload the arithmetic operations, the way arrays and REF RECORDs are, so that for b and c REF LONGINT, b + c = b^ + c = b + c^ = b^ + c^ Assignments carry an implicit range check. Assignment rules the same as INTEGER and its subranges. Use VAL to convert...? In short, expressions involving LONGINT have type LONGINT, but no "bare" LONGINT can ever be created. However note the following, perfectly legal. WITH a = b + c, r = NEW(REF LONGINT, a, a) DO r^ := a END Also legal, note parameters: PROCEDURE Collatz(READONLY a : LONGINT; VAR b : LONGINT) = BEGIN CASE a MOD 2L OF 0L => b := a DIV 2L | 1L => b := 3L * a + 1L END END Collatz; VALUE a : LONGINT would be discouraged. Returning LONGINT would *not* be legal. ARRAY OF LONGINT would mean the LONGINTs are limited to the same range, and used in NEW would take three arguments, one of type INTEGER for the array size and two of type LONGINT to specify the LONGINTs' bounds. Perhaps... PROCEDURE Collatz2(READONLY a : LONGINT; VAR b : LONGINT) RAISES { Range } = BEGIN CASE a MOD 2L OF 0L => b := a DIV 2L | 1L => WITH new = 3L * a + 1L DO (* is new actually stored anywhere!? *) IF new > LAST(b) THEN RAISE Range ELSE b := new END END END END Collatz2; My proposal gives you both heap-allocated dynamically sized LONGINT and stack-allocated fixed-sized longints and allows you to mix them at will. Collatz2 does seem a little bit disturbing, however. Can we rely on alloca "under the covers"? (Architectures that don't provide alloca could heap-allocate new in that example, *if* they need to.) Another thing that occurs to me is that while + and - are straightforward, *, DIV, and MOD are things you may well want to use very special and specific algorithms for in a given application. It makes sense to let the user replace the code for these operations. And now it begins to look like C++. Sigh. Hendrik, I do think WITH causes similar problems even for strictly range-limited numbers like the ones you are proposing? (And so does expression evaluation, of course...) Now is it even reasonable to have this built in? What if the user wants lazy evaluation? Are non-lazy LONGINTs very useful? Of course, I have to admit I am using a hardware simulation environment where non-lazy LONGINTs would indeed be very useful. Mika From hosking at cs.purdue.edu Sat Apr 24 18:42:07 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 24 Apr 2010 12:42:07 -0400 Subject: [M3devel] INTEGER In-Reply-To: <20100424103435.A1CC41A20C2@async.async.caltech.edu> References: <20100421185631.GA17051@topoi.pooq.com> <80775CA2-A2FD-40AF-B235-7DB84127762E@cs.purdue.edu> <20100422123805.GA19259@topoi.pooq.com> <87B45DCC-2B8A-4C69-97D7-240BC1E2252D@cs.purdue.edu> <20100422145522.GA19946@topoi.pooq.com> <28339030-6005-4C28-872C-A68CF24BF4DF@cs.purdue.edu> <20100422154357.GA20043@topoi.pooq.com> <270A99B5-173E-413B-8C28-E1CA68870FD4@cs.purdue.edu> <20100423094903.GC21281@topoi.pooq.com> <20100423185214.BA2EF1A20E1@async.async.caltech.edu> <20100423165613.GA22126@topoi.pooq.com> <20100424103435.A1CC41A20C2@async.async.caltech.edu> Message-ID: This sounds like something that should be implemented initially as a library so it can be evaluated for its usefulness. If we need built-ins for efficiency then that could come later as needed. To that end, why not simply say: TYPE LONGINT = ARRAY OF INTEGER and implement operations in the same way as Word? On 24 Apr 2010, at 06:34, Mika Nystrom wrote: > hendrik at topoi.pooq.com writes: >> On Fri, Apr 23, 2010 at 11:52:14AM -0700, Mika Nystrom wrote: >>> >>> Is the infinite extent of the TEXT type a serious implementation difficulty? :-) >> >> Yes, actually. It requires heap storage allocation and indirection. That's just what >> it costs, so we pay it, since fixed-width strings aren't all that useful. >> >> But integer ranges of a size that matches the application (instead of the hardware) >> are quite feasible and useful; I'd rather not pay the proce of dynamic heap allocation >> for each integer. >> >> -- hendrik > > Ok here I have a proposal, modeled on how Modula-3 does arrays. > > The type specifier LONGINT to be valid in every context where an open > array is valid. > > A subrange of LONGINT to be treated like a non-open array. > > NEW(REF LONGINT, ..) would take two "size" specifiers, a minimum and a maximum, > of type LONGINT. > > For L, U, LONGINT literals, > > NEW(REF LONGINT, L, U) > > would produce the same thing as > > NEW(REF [L..U]) > > NEW(REF LONGINT, ..) is needed for dynamically sized LONGINTs. > > And then overload the arithmetic operations, the way arrays and REF RECORDs are, so > that for b and c REF LONGINT, > > b + c = b^ + c = b + c^ = b^ + c^ > > Assignments carry an implicit range check. > > Assignment rules the same as INTEGER and its subranges. > > Use VAL to convert...? > > In short, expressions involving LONGINT have type LONGINT, but no "bare" LONGINT can > ever be created. > > However note the following, perfectly legal. > > WITH a = b + c, > r = NEW(REF LONGINT, a, a) DO > r^ := a > END > > Also legal, note parameters: > > PROCEDURE Collatz(READONLY a : LONGINT; VAR b : LONGINT) = > BEGIN > CASE a MOD 2L OF > 0L => b := a DIV 2L > | > 1L => b := 3L * a + 1L > END > END Collatz; > > VALUE a : LONGINT would be discouraged. Returning LONGINT > would *not* be legal. ARRAY OF LONGINT would mean the LONGINTs > are limited to the same range, and used in NEW would take three > arguments, one of type INTEGER for the array size and two of type > LONGINT to specify the LONGINTs' bounds. > > Perhaps... > > PROCEDURE Collatz2(READONLY a : LONGINT; VAR b : LONGINT) > RAISES { Range } = > BEGIN > CASE a MOD 2L OF > 0L => b := a DIV 2L > | > 1L => > WITH new = 3L * a + 1L DO (* is new actually stored anywhere!? *) > IF new > LAST(b) THEN > RAISE Range > ELSE > b := new > END > END > END > END Collatz2; > > My proposal gives you both heap-allocated dynamically sized LONGINT and > stack-allocated fixed-sized longints and allows you to mix them at will. > Collatz2 does seem a little bit disturbing, however. Can we rely on > alloca "under the covers"? (Architectures that don't provide alloca > could heap-allocate new in that example, *if* they need to.) > > Another thing that occurs to me is that while + and - are straightforward, > *, DIV, and MOD are things you may well want to use very special and > specific algorithms for in a given application. It makes sense to let the > user replace the code for these operations. And now it begins to look > like C++. Sigh. > > Hendrik, I do think WITH causes similar problems even for strictly > range-limited numbers like the ones you are proposing? (And so does > expression evaluation, of course...) > > Now is it even reasonable to have this built in? What if the user wants > lazy evaluation? Are non-lazy LONGINTs very useful? > > Of course, I have to admit I am using a hardware simulation environment > where non-lazy LONGINTs would indeed be very useful. > > Mika From jay.krell at cornell.edu Sat Apr 24 23:20:49 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 24 Apr 2010 21:20:49 +0000 Subject: [M3devel] unsafe functions that read/write raw memory, integer conversions, obligation of unsafe code? Message-ID: What is the obligation of stuff like:? UNSAFE INTERFACE UnixIO; PROCEDURE read(file:int; buffer: ADDRESS; length: INTEGER); PROCEDURE write(file: int; ADDRESS; length: INTEGER); The reason I ask is kind of tangential. I'll explain it, but it again it doesn't necessarily matter: In m3core/src/unix/Usocket.c we have, my doing: /* assert that *plen fits in a 32 bit signed integer, no matter if it is unsigned or signed, or 32 bits or 64 bits */ #define ASSERT_PLEN \ ??? assert((plen == NULL) || (((*plen)>= 0) && ((*plen) < (m3_socklen_t)(1UL << 30)))); Sometimes *plen is signed, sometimes unsigned. I'm going to make it consistent from platform to platform. I used to try to match the underlying platform and avoid copying. The VMS C compiler is reasonably warning about *plen>= 0 always being true, given unsigned *plen. So I'm wondering again what m3_socklen_t should be anyway. There are at least four candidates: ?? 32bit signed int ?? 32bit unsigned int ?? pointer sized int (INTEGER) ?? pointer sized unsigned integer (Word.T, which is INTEGER but with a different interpretation) The numbers involves are always small and positive. ? It isn't a "buffer" size, but the size of a small struct. Most 64bit C environments use a 32bit unsigned int. Though, again, we don't have to match them. The comments I left say: Cygwin is 32bit int, HP-UX is size_t (32 or 64), the rest are unsigned int. VMS is usually size_t, or int under old setting. An size_t is surprisingly always 32 bits. But again the C settings aren't super relevant. I'm thinking I should definitely make it unsigned. That matches most platforms (which, again, doesn't matter), lets the assertion be cut in half, and thereby removing the warning. But again, what is my "safety obligation"? If some Modula-3 code passes in a "negative" number, am I doing a legitimate favor in failing an assertion? Or they might just as well have passed in an incorrectly very large integer and overflowed their buffer just as well? ? Making negative numbers invalid seems useful at first glance, but then when you realize that pretty darn large numbers ?? will still get through, it seems less useful. Now, thinking about this more, it is not just about avoiding buffer overflow. There is also the matter of truncating integers. If some Modula-3 code passes me the value 4GB + 1 and I in turm truncate that to just 1, I have done something wrong. Integer conversions have to be checked. Therefore, for one thing, I think these wrappers do need to know with certainty what the underlying socken_t is. ? Even on platforms that don't declare it. :) Cygwin and VMS. Asserting that they fit in a half range 32 bit integer is a way to avoid being completely precise. It is acceptable here -- it not the size of a "buffer", but the size of a fairly small struct, a struct addr. ?- Jay From mika at async.async.caltech.edu Sat Apr 24 23:25:23 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Sat, 24 Apr 2010 14:25:23 -0700 Subject: [M3devel] unsafe functions that read/write raw memory, integer conversions, obligation of unsafe code? In-Reply-To: References: Message-ID: <20100424212523.E37411A20B6@async.async.caltech.edu> Unsafe code that exports only an UNSAFE INTERFACE has no particular obligation. Unsafe code that exports a non-UNSAFE INTERFACE has to guarantee the absence of unchecked runtime errors regardless of input---this can be weakened to "regardless of input as long as that input can possibly be provided by a non-UNSAFE module", but the latter might be difficult to verify as it is a global property. Mika Jay K writes: > >What is the obligation of stuff like:? > > >UNSAFE INTERFACE UnixIO=3B > > >PROCEDURE read(file:int=3B buffer: ADDRESS=3B length: INTEGER)=3B >PROCEDURE write(file: int=3B ADDRESS=3B length: INTEGER)=3B > > > >The reason I ask is kind of tangential. > >I'll explain it=2C but it again it doesn't necessarily matter: > >In m3core/src/unix/Usocket.c we have=2C my doing: > > >/* assert that *plen fits in a 32 bit signed integer=2C no matter >if it is unsigned or signed=2C or 32 bits or 64 bits */ > >#define ASSERT_PLEN \ >=A0=A0=A0 assert((plen =3D=3D NULL) || (((*plen)>=3D 0) && ((*plen) < (m3_s= >ocklen_t)(1UL << 30))))=3B > > > >Sometimes *plen is signed=2C sometimes unsigned. >I'm going to make it consistent from platform to platform. >I used to try to match the underlying platform and avoid copying. > > > >The VMS C compiler is reasonably warning about *plen>=3D 0 always being tru= >e=2C given unsigned *plen. >So I'm wondering again what m3_socklen_t should be anyway. >There are at least four candidates: >=A0=A0 32bit signed int >=A0=A0 32bit unsigned int=20 >=A0=A0 pointer sized int (INTEGER) >=A0=A0 pointer sized unsigned integer (Word.T=2C which is INTEGER but with = >a different interpretation) > > >The numbers involves are always small and positive. >=A0 It isn't a "buffer" size=2C but the size of a small struct. >Most 64bit C environments use a 32bit unsigned int. Though=2C again=2C we d= >on't have to match them. >The comments I left say: Cygwin is 32bit int=2C HP-UX is size_t (32 or 64)= >=2C the rest are unsigned int. >VMS is usually size_t=2C or int under old setting. An size_t is surprisingl= >y always 32 bits. >But again the C settings aren't super relevant. > > >I'm thinking I should definitely make it unsigned. >That matches most platforms (which=2C again=2C doesn't matter)=2C lets the = >assertion be cut in half=2C and thereby removing the warning. > > >But again=2C what is my "safety obligation"? >If some Modula-3 code passes in a "negative" number=2C am I doing a legitim= >ate favor in failing an assertion? >Or they might just as well have passed in an incorrectly very large integer= > and overflowed their buffer just as well? >=A0 Making negative numbers invalid seems useful at first glance=2C but the= >n when you realize that pretty darn large numbers >=A0=A0 will still get through=2C it seems less useful. > > >Now=2C thinking about this more=2C it is not just about avoiding buffer ove= >rflow. >There is also the matter of truncating integers. >If some Modula-3 code passes me the value 4GB + 1 and I in turm truncate th= >at to just 1=2C I have done something wrong. >Integer conversions have to be checked. >Therefore=2C for one thing=2C I think these wrappers do need to know with c= >ertainty what the underlying socken_t is. >=A0 Even on platforms that don't declare it. :) Cygwin and VMS. > > >Asserting that they fit in a half range 32 bit integer is a way to avoid be= >ing completely precise. >It is acceptable here -- it not the size of a "buffer"=2C but the size of a= > fairly small struct=2C a struct addr. > > >=A0- Jay > > = From mika at async.async.caltech.edu Sat Apr 24 23:29:52 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Sat, 24 Apr 2010 14:29:52 -0700 Subject: [M3devel] Compiling Modula-3 to C Message-ID: <20100424212952.D9BDE1A20B7@async.async.caltech.edu> The question of making a Modula-3 compiler emit C code as output comes up on this mailing list from time to time. I just discovered a reference to a real example of this. http://caltechcstr.library.caltech.edu/218/01/93-15.pdf Note pages 49-50 (54-55 in the PDF). I also find the byte counts on page 49 interesting. I wish my m3core were that small! Mika From jay.krell at cornell.edu Sat Apr 24 23:58:18 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 24 Apr 2010 21:58:18 +0000 Subject: [M3devel] Compiling Modula-3 to C In-Reply-To: <20100424212952.D9BDE1A20B7@async.async.caltech.edu> References: <20100424212952.D9BDE1A20B7@async.async.caltech.edu> Message-ID: I haven't read this closely yet, I admit. I'm sure we'll get a Modula-3 to C backend before much longer. It greatly increases your real and theoretical platform support for one medium upfront cost, and perhaps a little bit of ongoing maintenance if some oddities are reported. I'll be tired of the old way fairly soon. There remain too many viable but unsupported targets. If it has pthreads (or sigaltstack), POSIX (or NT), and a C compiler, that should be all it takes. Notice that there are now affordable and somewhat performant MIPS laptops that ? run at least Linux and OpenBSD. Notice that FreeBSD is slowly expanding ? its targets, including PowerPC, MIPS, SPARC64. There will probably be an option to generate C++ as well, which should offer more efficient exception handling than portable C. Whether or not it it is all idiomatic and intuitive to interoperate with, unknown. Regarding that paper: One should try to remain mindful of when language change is needed vs. merely library. ?? I didn't read enough to see if they need language changes. ?? I do believe Modula-3 could benefit from some language changes. Though that might be mitigated ?? and/or eliminated by me knowing Modula-3 better. For example, can I have a type with ?? compiler-enforced opacity without requiring heap allocation? C compilers are probably better these days. ?Look -- gcc 4.5 just caught up some with Visual C++ and others and has "LTO": link time optimization. ? I believe Sun also has had this a while, and I'm sure others. ? I rarely turn on optimization though, I admit. ? Disk and network I/O tend to dominate all costs. I don't do heavy computation. Shared libraries are always going to seem bloated because they export everything, even unused stuff. The paper seems little confused on this matter, depending on the quality/behavior of the linker, and whether or not functions are "separated" within object files. Visual C++ has the -Gy flag which you should *always* use. I don't know why it is an even an option. It makes each function within an object separate, so you only link in what you use, and what that references, transitive closure. For better and for worse, data is not linked in with that same high level of granularity. If you get any data from an object, you get it all. And that includes pointers to functions, and whatever those functions call, even if the data isn't referenced. I know that historically linkers didn't strip out anything. I'm surprised such linkers existed. Are they still in use? (What do GNU, Sun, Mac do?) ?- Jay ---------------------------------------- > To: m3devel at elegosoft.com > Date: Sat, 24 Apr 2010 14:29:52 -0700 > From: mika at async.async.caltech.edu > Subject: [M3devel] Compiling Modula-3 to C > > > The question of making a Modula-3 compiler emit C code as output comes > up on this mailing list from time to time. > > I just discovered a reference to a real example of this. > > http://caltechcstr.library.caltech.edu/218/01/93-15.pdf > > Note pages 49-50 (54-55 in the PDF). > > I also find the byte counts on page 49 interesting. I wish my m3core > were that small! > > Mika From mika at async.async.caltech.edu Sun Apr 25 00:23:18 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Sat, 24 Apr 2010 15:23:18 -0700 Subject: [M3devel] Compiling Modula-3 to C In-Reply-To: References: <20100424212952.D9BDE1A20B7@async.async.caltech.edu> Message-ID: <20100424222319.08FF71A20B5@async.async.caltech.edu> Jay, My point in sharing that was not to agitate for making the changes in Modula-3 that Rustan did for his project. (It's his M.S. thesis.) I wanted to show the quality of the assembly code that one existing Modula-3-to-C-to-ASM toolchain has generated. It doesn't look *horrendous* to me, honestly, only maybe the footprint is a bit on the large side. One thing one could try of course is to type in Rustan's generated C code and compare what gcc spits out from compiling it it to the ASM generated by compiling the original M3 code. (On one's favorite modern architecture.) I have Modula-3D in source form so I am sure the Modula-3-to-C compiler is in there, and most of it is in the SRC sources anyhow. MIPS especially. No need to write a brand new one. No you cannot have a type with compiler-enforced opacity without requiring heap allocation. It's a shortcoming of the language, yes. But you know, you can just leave a comment that says the type is opaque. The point of M3's safety rules is to prevent unchecked runtime errors. M3's opaqueness rules are defined in terms of OBJECT which are always references. The designers felt that the C++ objects were too hard to achieve. BY THE WAY, the whole way Modula-3 does opaqueness is in the minds of anal-retentive OO people completely wrong (I think it is brilliant). They would have you declare in your object type who can touch the bits of it. friends, protected, etc. In Modula-3 it's mostly up to the *client* to decide how much opaqueness is right. For example: INTERFACE Q; TYPE T <: Public; END Q. INTERFACE QFriends; REVEAL Q.T <: Friendly; END QFriends. INTERFACE QPrivate; REVEAL Q.T <: Private; END QPrivate. A client R of Q can then go ahead and IMPORT QFriends and QPrivate as it pleases, regardless of what the relationship between R and Q is. (There is a hack in quake to hide certain interfaces but it's only done at one level and it's not part of the Modula-3 language proper.) Thus, Modula-3 assumes that programmers are a bit more responsible than the hiding rules available in C++ or Java. Which is why I say that not having the opaqueness available for non-ref types is not such a big deal, really. The language is trying to help you not make stupid mistakes---it's not some kind of "OO cleanliness police". I have written a lot of M3 code and have indeed missed opaque nonreference objects from time to time, but you learn to live with it, just like you learn to live with the idiosyncracies of any programming language. >From personal experience all I can say is that M3's idiosyncracies are far less annoying than those of any other "practical" programming language I've ever used. (This is not a criticism, but how much M3 have you actually written?) Oh, regarding link-time optimization, see: http://www.modula3.org/threads/2/#linkTimeOptimization Mika Jay K writes: > >I haven't read this closely yet=2C I admit. > > >I'm sure we'll get a Modula-3 to C backend before much longer. >It greatly increases your real and theoretical platform support for >one medium upfront cost=2C and perhaps a little bit of ongoing maintenance = >if some oddities are reported. >I'll be tired of the old way fairly soon. >There remain too many viable but unsupported targets. >If it has pthreads (or sigaltstack)=2C POSIX (or NT)=2C and a C compiler=2C= > that should be all it takes. >Notice that there are now affordable and somewhat performant MIPS laptops t= >hat >=A0 run at least Linux and OpenBSD. Notice that FreeBSD is slowly expanding >=A0 its targets=2C including PowerPC=2C MIPS=2C SPARC64. > > >There will probably be an option to generate C++ as well=2C which >should offer more efficient exception handling than portable C. > >Whether or not it it is all idiomatic and intuitive to interoperate with=2C= > unknown. > >Regarding that paper: > >One should try to remain mindful of when language change is needed vs. mere= >ly library. >=A0=A0 I didn't read enough to see if they need language changes. >=A0=A0 I do believe Modula-3 could benefit from some language changes. Thou= >gh that might be mitigated >=A0=A0 and/or eliminated by me knowing Modula-3 better. For example=2C can = >I have a type with >=A0=A0 compiler-enforced opacity without requiring heap allocation? > >C compilers are probably better these days. >=A0Look -- gcc 4.5 just caught up some with Visual C++ and others and has "= >LTO": link time optimization. >=A0 I believe Sun also has had this a while=2C and I'm sure others. >=A0 I rarely turn on optimization though=2C I admit. >=A0 Disk and network I/O tend to dominate all costs. I don't do heavy compu= >tation. > > >Shared libraries are always going to seem bloated because they export every= >thing=2C >even unused stuff. > > >The paper seems little confused on this matter=2C depending on the >quality/behavior of the linker=2C and whether or not functions are "separat= >ed" within >object files. Visual C++ has the -Gy flag which you should *always* use. >I don't know why it is an even an option. It makes each function within an = >object >separate=2C so you only link in what you use=2C and what that references=2C= > transitive closure. >For better and for worse=2C data is not linked in with that same high level= > of granularity. >If you get any data from an object=2C you get it all. >And that includes pointers to functions=2C and whatever those functions cal= >l=2C even >if the data isn't referenced. > > >I know that historically linkers didn't strip out anything. >I'm surprised such linkers existed. Are they still in use? >(What do GNU=2C Sun=2C Mac do?) > > >=A0- Jay > >---------------------------------------- >> To: m3devel at elegosoft.com >> Date: Sat=2C 24 Apr 2010 14:29:52 -0700 >> From: mika at async.async.caltech.edu >> Subject: [M3devel] Compiling Modula-3 to C >> >> >> The question of making a Modula-3 compiler emit C code as output comes >> up on this mailing list from time to time. >> >> I just discovered a reference to a real example of this. >> >> http://caltechcstr.library.caltech.edu/218/01/93-15.pdf >> >> Note pages 49-50 (54-55 in the PDF). >> >> I also find the byte counts on page 49 interesting. I wish my m3core >> were that small! >> >> Mika > = From jay.krell at cornell.edu Sun Apr 25 00:56:28 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 24 Apr 2010 22:56:28 +0000 Subject: [M3devel] Compiling Modula-3 to C In-Reply-To: <20100424222319.08FF71A20B5@async.async.caltech.edu> References: <20100424212952.D9BDE1A20B7@async.async.caltech.edu>, , <20100424222319.08FF71A20B5@async.async.caltech.edu> Message-ID: Agitation not necessarly inferred. :) Mika, the thing is.. consider "safety". I can argue..as a C programmer..I know what is safe, I don't need the language protection. Practise proves this is somewhat true, somewhat false. ?? ? Similar to your argument: ?I know what is opaque, I don't need the language protection. ? I don't think a comment declaring opacity is strong enough. C++ does this better, even though also a little weak. In C++ I would put in "private:" and the compiler enforces it. If someone is determined to break through, they must edit the header, possibly recompile, or duplicate the declaration without private and cast. There is no accidental violation of private. I understand there is the issue of the size still being revealed ? which is an important practical matter in terms of coupling ? and need to rebuild. But at the abstract enforced interface ? level, it doesn't matter. I understand that C++ is a little bit complicated, with public/private/protected, and friends. And C# has more options (visible to the assembly/.dll). I think at least one bit is worthwhile though. public or private. Public to all or nobody. I doubt new syntax would even be needed. Just like: foo.i3: TYPE Foo; or TYPE FooPublic = RECORD END; TYPE <: FooPublic; foo.m3 ?REVEAL Foo = RECORD ... END; Target.Int I think is a good example. It is small, fixed size, not a reference, not separately/heap allocated. But it is opaque only via comment. I have a 2.x tree somewhere, recently downloaded from the web. It does Modula-3-to-C within what was and is m3front. The "design" of the output C can be reclaimed. The code has to/should be sprinkled around elsewhere, behind an implementation of CG.i3. And as you allude, I might try doing it from scratch anyway. :) ?- Jay ---------------------------------------- > To: jay.krell at cornell.edu > Date: Sat, 24 Apr 2010 15:23:18 -0700 > From: mika at async.async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Compiling Modula-3 to C > > Jay, > > My point in sharing that was not to agitate for making the changes in > Modula-3 that Rustan did for his project. (It's his M.S. thesis.) > > I wanted to show the quality of the assembly code that one existing > Modula-3-to-C-to-ASM toolchain has generated. It doesn't look > *horrendous* to me, honestly, only maybe the footprint is a bit on the > large side. One thing one could try of course is to type in Rustan's > generated C code and compare what gcc spits out from compiling it it to > the ASM generated by compiling the original M3 code. (On one's favorite > modern architecture.) > > I have Modula-3D in source form so I am sure the Modula-3-to-C compiler is > in there, and most of it is in the SRC sources anyhow. MIPS especially. > No need to write a brand new one. > > No you cannot have a type with compiler-enforced opacity without requiring > heap allocation. It's a shortcoming of the language, yes. But you know, > you can just leave a comment that says the type is opaque. > > The point of M3's safety rules is to prevent unchecked runtime errors. > > M3's opaqueness rules are defined in terms of OBJECT which are always > references. The designers felt that the C++ objects were too hard to > achieve. > > BY THE WAY, the whole way Modula-3 does opaqueness is in the minds of > anal-retentive OO people completely wrong (I think it is brilliant). > They would have you declare in your object type who can touch the > bits of it. friends, protected, etc. In Modula-3 it's mostly up to > the *client* to decide how much opaqueness is right. > > For example: > > INTERFACE Q; TYPE T <: Public; END Q. > > INTERFACE QFriends; REVEAL Q.T <: Friendly; END QFriends. > > INTERFACE QPrivate; REVEAL Q.T <: Private; END QPrivate. > > A client R of Q can then go ahead and IMPORT QFriends and QPrivate as > it pleases, regardless of what the relationship between R and Q is. > (There is a hack in quake to hide certain interfaces but it's only > done at one level and it's not part of the Modula-3 language proper.) > > Thus, Modula-3 assumes that programmers are a bit more responsible than > the hiding rules available in C++ or Java. Which is why I say that > not having the opaqueness available for non-ref types is not such a big > deal, really. The language is trying to help you not make stupid > mistakes---it's not some kind of "OO cleanliness police". > > I have written a lot of M3 code and have indeed missed opaque nonreference > objects from time to time, but you learn to live with it, just like > you learn to live with the idiosyncracies of any programming language. > From personal experience all I can say is that M3's idiosyncracies > are far less annoying than those of any other "practical" programming > language I've ever used. (This is not a criticism, but how much M3 have > you actually written?) > > Oh, regarding link-time optimization, see: > > http://www.modula3.org/threads/2/#linkTimeOptimization > > Mika > > > > Jay K writes: >> >>I haven't read this closely yet=2C I admit. >> >> >>I'm sure we'll get a Modula-3 to C backend before much longer. >>It greatly increases your real and theoretical platform support for >>one medium upfront cost=2C and perhaps a little bit of ongoing maintenance = >>if some oddities are reported. >>I'll be tired of the old way fairly soon. >>There remain too many viable but unsupported targets. >>If it has pthreads (or sigaltstack)=2C POSIX (or NT)=2C and a C compiler=2C= >> that should be all it takes. >>Notice that there are now affordable and somewhat performant MIPS laptops t= >>hat >>=A0 run at least Linux and OpenBSD. Notice that FreeBSD is slowly expanding >>=A0 its targets=2C including PowerPC=2C MIPS=2C SPARC64. >> >> >>There will probably be an option to generate C++ as well=2C which >>should offer more efficient exception handling than portable C. >> >>Whether or not it it is all idiomatic and intuitive to interoperate with=2C= >> unknown. >> >>Regarding that paper: >> >>One should try to remain mindful of when language change is needed vs. mere= >>ly library. >>=A0=A0 I didn't read enough to see if they need language changes. >>=A0=A0 I do believe Modula-3 could benefit from some language changes. Thou= >>gh that might be mitigated >>=A0=A0 and/or eliminated by me knowing Modula-3 better. For example=2C can = >>I have a type with >>=A0=A0 compiler-enforced opacity without requiring heap allocation? >> >>C compilers are probably better these days. >>=A0Look -- gcc 4.5 just caught up some with Visual C++ and others and has "= >>LTO": link time optimization. >>=A0 I believe Sun also has had this a while=2C and I'm sure others. >>=A0 I rarely turn on optimization though=2C I admit. >>=A0 Disk and network I/O tend to dominate all costs. I don't do heavy compu= >>tation. >> >> >>Shared libraries are always going to seem bloated because they export every= >>thing=2C >>even unused stuff. >> >> >>The paper seems little confused on this matter=2C depending on the >>quality/behavior of the linker=2C and whether or not functions are "separat= >>ed" within >>object files. Visual C++ has the -Gy flag which you should *always* use. >>I don't know why it is an even an option. It makes each function within an = >>object >>separate=2C so you only link in what you use=2C and what that references=2C= >> transitive closure. >>For better and for worse=2C data is not linked in with that same high level= >> of granularity. >>If you get any data from an object=2C you get it all. >>And that includes pointers to functions=2C and whatever those functions cal= >>l=2C even >>if the data isn't referenced. >> >> >>I know that historically linkers didn't strip out anything. >>I'm surprised such linkers existed. Are they still in use? >>(What do GNU=2C Sun=2C Mac do?) >> >> >>=A0- Jay >> >>---------------------------------------- >>> To: m3devel at elegosoft.com >>> Date: Sat=2C 24 Apr 2010 14:29:52 -0700 >>> From: mika at async.async.caltech.edu >>> Subject: [M3devel] Compiling Modula-3 to C >>> >>> >>> The question of making a Modula-3 compiler emit C code as output comes >>> up on this mailing list from time to time. >>> >>> I just discovered a reference to a real example of this. >>> >>> http://caltechcstr.library.caltech.edu/218/01/93-15.pdf >>> >>> Note pages 49-50 (54-55 in the PDF). >>> >>> I also find the byte counts on page 49 interesting. I wish my m3core >>> were that small! >>> >>> Mika >> = From jay.krell at cornell.edu Sun Apr 25 02:00:57 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 25 Apr 2010 00:00:57 +0000 Subject: [M3devel] alpha32 atomic exchange char/widechar? Message-ID: Tony, any idea why on Alpha32 atomic exchange of char/widechar would hit assertion failures in the compiler? It works on Alpha64, and it works on Alpha32 from C (gcc 4.3.0) ? So it isn't for lacking the necessary instructions. ? It works with ev4 or ev6, just more efficiently with ev6. I edited Atomic.mg to just: (* Copyright (C) 1989, Digital Equipment Corporation?????????? *) (* All rights reserved.??????????????????????????????????????? *) (* See the file COPYRIGHT for a full description.????????????? *) GENERIC MODULE Atomic(Rep, Impl); PROCEDURE Swap (VAR var: T; val: Rep.T; order: Order): Rep.T = ? BEGIN RETURN Impl.Swap (var, val, Order.Sequential); ? END Swap; BEGIN END Atomic. and then I get: ../ALPHA32_VMS/AtomicChar.m3 => ../src/atomic/Atomic.mg:9: internal compiler error: in emit_move_insn, at expr.c:3379 ../ALPHA32_VMS/AtomicWideChar.m3 => ../src/atomic/Atomic.mg: In function 'AtomicWideChar__Swap': ../ALPHA32_VMS/AtomicWideChar.m3 => ../src/atomic/Atomic.mg:9: internal compiler error: in emit_move_insn, at expr.c:3379 Please submit a full bug report, rtx emit_move_insn (rtx x, rtx y) { ? enum machine_mode mode = GET_MODE (x); ? rtx y_cst = NULL_RTX; ? rtx last_insn, set; ? gcc_assert (mode != BLKmode ??? ????? && (GET_MODE (y) == mode || GET_MODE (y) == VOIDmode)); I'll dig a bit. ?- Jay From mika at async.async.caltech.edu Sun Apr 25 06:52:02 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Sat, 24 Apr 2010 21:52:02 -0700 Subject: [M3devel] Compiling Modula-3 to C In-Reply-To: References: <20100424212952.D9BDE1A20B7@async.async.caltech.edu>, , <20100424222319.08FF71A20B5@async.async.caltech.edu> Message-ID: <20100425045202.D57B91A20B4@async.async.caltech.edu> Jay K writes: > >Agitation not necessarly inferred. :) > > >Mika=2C the thing is.. consider "safety". >I can argue..as a C programmer..I know what is safe=2C I don't >need the language protection. >Practise proves this is somewhat true=2C somewhat false. >=A0=A0=20 >=A0 >Similar to your argument: >=A0I know what is opaque=2C I don't need the language protection. > >=A0 >I don't think a comment declaring opacity is strong enough. A little different. C never lets you have safety. Modula-3 gives you opacity. You just can't have it at the same time as stack allocation. Same thing with anything else that you only get with OBJECTs for that matter (e.g., dynamic method dispatch). You can't break through the opacity with a cast, either. ... > >I understand that C++ is a little bit complicated=2C with public/private/pr= >otected=2C and friends. >And C# has more options (visible to the assembly/.dll). >I think at least one bit is worthwhile though. >public or private. >Public to all or nobody. >I doubt new syntax would even be needed. >Just like: > >foo.i3: >TYPE Foo=3B >or TYPE FooPublic =3D RECORD END=3B TYPE <: FooPublic=3B > >foo.m3 >=A0REVEAL Foo =3D RECORD ... END=3B > I think you'd just want fully opaque types. Mixing in <: here seems inappropriate. <: has meaning for the abstract types (up till now), whereas I can't figure out what it means for RECORDs. If you want to reveal fields you can always do it through a PROCEDURE that converts from the opaque type to a visible type. TYPE T = OPAQUE RECORD; TYPE Visible = RECORD ... END; PROCEDURE MakeVisible(READONLY t : T) : Visible; Then in the implementation all you have is REVEAL T = RECORD ... END; Mika From jay.krell at cornell.edu Sun Apr 25 15:26:43 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 25 Apr 2010 13:26:43 +0000 Subject: [M3devel] alpha32 atomic exchange char/widechar? Message-ID: aha, gcc 4.3 hits the same assertion failure with -O1 or -O2. I should have noticed that earlier. ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: alpha32 atomic exchange char/widechar? > Date: Sun, 25 Apr 2010 00:00:57 +0000 > > > Tony, any idea why on Alpha32 atomic exchange of char/widechar would hit assertion failures in the compiler? > It works on Alpha64, and it works on Alpha32 from C (gcc 4.3.0) > So it isn't for lacking the necessary instructions. > It works with ev4 or ev6, just more efficiently with ev6. > > I edited Atomic.mg to just: > > (* Copyright (C) 1989, Digital Equipment Corporation *) > (* All rights reserved. *) > (* See the file COPYRIGHT for a full description. *) > > GENERIC MODULE Atomic(Rep, Impl); > > PROCEDURE Swap (VAR var: T; val: Rep.T; order: Order): Rep.T = > BEGIN > RETURN Impl.Swap (var, val, Order.Sequential); > END Swap; > > BEGIN > END Atomic. > > and then I get: > > ../ALPHA32_VMS/AtomicChar.m3 => ../src/atomic/Atomic.mg:9: internal compiler error: in emit_move_insn, at expr.c:3379 > ../ALPHA32_VMS/AtomicWideChar.m3 => ../src/atomic/Atomic.mg: In function 'AtomicWideChar__Swap': > ../ALPHA32_VMS/AtomicWideChar.m3 => ../src/atomic/Atomic.mg:9: internal compiler error: in emit_move_insn, at expr.c:3379 > Please submit a full bug report, > > rtx > emit_move_insn (rtx x, rtx y) > { > enum machine_mode mode = GET_MODE (x); > rtx y_cst = NULL_RTX; > rtx last_insn, set; > > gcc_assert (mode != BLKmode > && (GET_MODE (y) == mode || GET_MODE (y) == VOIDmode)); > > I'll dig a bit. > > - Jay > From jay.krell at cornell.edu Mon Apr 26 01:29:59 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 25 Apr 2010 23:29:59 +0000 Subject: [M3devel] fork/vfork Message-ID: so..in the area of not cloning C headers..fork/vfork has been a lingering still cloned thing. It was already bothering me. I was going to make fork a function pointer at least, so it could honor any #defines or renaming via target specific #pragmas. That way as well we could also go back to vfork where it is a /little/ faster. Fork and/or vfork are not portably wrappable in the usual way because the caller of one or both of them cannot return without calling _exit or an exec function. A wrapper would violate this. I believe I had this violation in temporarily and I believe it did cause a problem. But now there is a bigger problem: VMS: #if defined(__ALPHA) ??? __int64_ptr32 decc$$get_vfork_jmpbuf(void); ??? int LIB$GET_CURRENT_INVO_CONTEXT(__int64 *__invo_context); ??? int decc$$alloc_vfork_blocks(void); #?? define vfork() (decc$$alloc_vfork_blocks()>= 0 ? \ ??? LIB$GET_CURRENT_INVO_CONTEXT(decc$$get_vfork_jmpbuf()) : -1) which further motivates "rewriting" vfork users in C. There are only about two of them. I intend to look into and do this unless there is strong protest. vfork is implemented with a trick that is also mentioned in some Cygwin documentation, something Cygwin attempted but doesn't do. vfork calls setjmp. It returns -1 so the caller thinks it is in the child process. exec calls longjmp, returning the pid on the second return to the parent. Something like that. I almost wonder if we can do this ourselves. But not calling fork/vfork from Modula-3 directly was already a good idea. Now even better. We can leave in fork/vfork external declarations and folks that don't care to run on VMS can still call them. ?(and convert them to function pointers as per my previous thinking) ?- Jay From jay.krell at cornell.edu Tue Apr 27 11:01:23 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 27 Apr 2010 09:01:23 +0000 Subject: [M3devel] cooperative suspend? Message-ID: cooperative suspend Tony, you mind if I take a stab at "cooperative suspend" fairly soon? I can't find a good way to suspend threads on VMS. ? Or even get context in a signal handler. It will be a boolen in Target.i3, so no existing targets affected. ? Of course I'll test it on an existing target with the boolean set wrong. :) ? ? To optimize size instead of speed, I think the "every so often extra generated code" should be a call to a parameter-less function. Instead of checking a per-thread or global variable. Something like: VAR threadRequestingSuspend: ADDRESS; PROCEDURE Thread.PollSuspend() ? BEGIN ??? IF threadRequestingSuspend = NIL THEN RETURN END; ??? PollSuspendSlow(); ? END PollSuspend; (* This is split to avoid needing a frame in PollSuspend. *)? PROCEDURE PollSuspendSlow() ? VAR self: ADDRESS; ? BEGIN ??? IF threadRequestingSuspend = NIL THEN RETURN END; ??? self := GetActivation(); ??? IF self = threadRequestingSuspend THEN RETURN END; (* important consideration! *) ??? GetContext(self.context); (* roughly *) ??? self.suspended := TRUE; (* roughly *) ??? WaitForResume(); (* details to be determined, either the semaphore ????????????????????? * or maybe acquire per-thread lock. *) ? END PollSuspendSlow; The poll call could also be a function pointer and usually point to a function that does nothing. But that'd require loading the address from a global, and calling it. Probably more bloat than calling direct instead of indirect. ?- Jay From rodney_bates at lcwb.coop Tue Apr 27 16:40:47 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Tue, 27 Apr 2010 09:40:47 -0500 Subject: [M3devel] INTEGER In-Reply-To: <20100424103435.A1CC41A20C2@async.async.caltech.edu> References: <20100421185631.GA17051@topoi.pooq.com> <80775CA2-A2FD-40AF-B235-7DB84127762E@cs.purdue.edu> <20100422123805.GA19259@topoi.pooq.com> <87B45DCC-2B8A-4C69-97D7-240BC1E2252D@cs.purdue.edu> <20100422145522.GA19946@topoi.pooq.com> <28339030-6005-4C28-872C-A68CF24BF4DF@cs.purdue.edu> <20100422154357.GA20043@topoi.pooq.com> <270A99B5-173E-413B-8C28-E1CA68870FD4@cs.purdue.edu> <20100423094903.GC21281@topoi.pooq.com> <20100423185214.BA2EF1A20E1@async.async.caltech.edu> <20100423165613.GA22126@topoi.pooq.com> <20100424103435.A1CC41A20C2@async.async.caltech.edu> Message-ID: <4BD6F76F.6090603@lcwb.coop> A general discussion: (More to come on Mika's specific proposal) The problem with using subranges and only one integer type lies in the size of intermediate results of operators. This is sometimes important for programmers to manage carefully. All the more so in the age of network insecurity, where system crackers exploit boundary cases that would never occur in legitimate use. In original Modula-3, this is handled by making all intermediate results have type INTEGER, even if the operands have subrange types. This is a good compromise among conflicting needs, with these properties: 1) It is a simple rule for both compilers and programmers, and it satisfies the language properties that every expression has a unique type and it does not depend on how the expression is used. 2) Assuming the implementors choose the native word size for INTEGER, it is the most efficient arithmetic available. 3) It's the most liberal rule that doesn't have an efficiency penalty. 4) But it doesn't work when a value range greater than the native word size is needed for correctness. The problem arises when the application requirements make 4) relevant. Making INTEGER wider than the native word size necessarily sacrifices either 1) or 2). If all arithmetic were done in, say, double word size, there would be an efficiency penalty on it all. Not huge, but probably a factor of two for the best case of machine and operator. Integer arithmetic is especially sensitive to this kind of slowdown, since it is used in so many very basic ways. Any attempt at defining some system that does intermediate results conditionally in different sizes inevitably gets messy. Having two (or more) integer base types is about as simple as it can get. It satisfies 1) and gives a lot more slack before 4) becomes relevant. It gives programmers control over the efficiency/range tradeoff in a way that is about as simple to define as possible. Having different intermediate result sizes with the same base type gets a lot messier. To give satisfactory results, it would probably have to make types of operator expressions depend on how they are used, violating a fundamental principle of Modula-3. At best, I think the rules would be a lot more complicated that just having two integer base types. But anyone is welcome to prove me wrong with a proposal. Just be sure it completely defines all the type analysis and intermediate result size cases for the subranges, operators, and constant expressions, and allows programmers to control which size is used. And then see if it is simpler than separate integer types. Of course, there is always the library approach, like BigInteger It's much more flexible and much less efficient in general. Not to mention not as syntactically sweet. Two integer sizes seems like a good intermediate solution. Mika Nystrom wrote: > hendrik at topoi.pooq.com writes: >> On Fri, Apr 23, 2010 at 11:52:14AM -0700, Mika Nystrom wrote: >>> Is the infinite extent of the TEXT type a serious implementation difficulty? :-) >> Yes, actually. It requires heap storage allocation and indirection. That's just what >> it costs, so we pay it, since fixed-width strings aren't all that useful. >> >> But integer ranges of a size that matches the application (instead of the hardware) >> are quite feasible and useful; I'd rather not pay the proce of dynamic heap allocation >> for each integer. >> >> -- hendrik > > Ok here I have a proposal, modeled on how Modula-3 does arrays. > > The type specifier LONGINT to be valid in every context where an open > array is valid. > > A subrange of LONGINT to be treated like a non-open array. > > NEW(REF LONGINT, ..) would take two "size" specifiers, a minimum and a maximum, > of type LONGINT. > > For L, U, LONGINT literals, > > NEW(REF LONGINT, L, U) > > would produce the same thing as > > NEW(REF [L..U]) > > NEW(REF LONGINT, ..) is needed for dynamically sized LONGINTs. > > And then overload the arithmetic operations, the way arrays and REF RECORDs are, so > that for b and c REF LONGINT, > > b + c = b^ + c = b + c^ = b^ + c^ > > Assignments carry an implicit range check. > > Assignment rules the same as INTEGER and its subranges. > > Use VAL to convert...? > > In short, expressions involving LONGINT have type LONGINT, but no "bare" LONGINT can > ever be created. > > However note the following, perfectly legal. > > WITH a = b + c, > r = NEW(REF LONGINT, a, a) DO > r^ := a > END > > Also legal, note parameters: > > PROCEDURE Collatz(READONLY a : LONGINT; VAR b : LONGINT) = > BEGIN > CASE a MOD 2L OF > 0L => b := a DIV 2L > | > 1L => b := 3L * a + 1L > END > END Collatz; > > VALUE a : LONGINT would be discouraged. Returning LONGINT > would *not* be legal. ARRAY OF LONGINT would mean the LONGINTs > are limited to the same range, and used in NEW would take three > arguments, one of type INTEGER for the array size and two of type > LONGINT to specify the LONGINTs' bounds. > > Perhaps... > > PROCEDURE Collatz2(READONLY a : LONGINT; VAR b : LONGINT) > RAISES { Range } = > BEGIN > CASE a MOD 2L OF > 0L => b := a DIV 2L > | > 1L => > WITH new = 3L * a + 1L DO (* is new actually stored anywhere!? *) > IF new > LAST(b) THEN > RAISE Range > ELSE > b := new > END > END > END > END Collatz2; > > My proposal gives you both heap-allocated dynamically sized LONGINT and > stack-allocated fixed-sized longints and allows you to mix them at will. > Collatz2 does seem a little bit disturbing, however. Can we rely on > alloca "under the covers"? (Architectures that don't provide alloca > could heap-allocate new in that example, *if* they need to.) > > Another thing that occurs to me is that while + and - are straightforward, > *, DIV, and MOD are things you may well want to use very special and > specific algorithms for in a given application. It makes sense to let the > user replace the code for these operations. And now it begins to look > like C++. Sigh. > > Hendrik, I do think WITH causes similar problems even for strictly > range-limited numbers like the ones you are proposing? (And so does > expression evaluation, of course...) > > Now is it even reasonable to have this built in? What if the user wants > lazy evaluation? Are non-lazy LONGINTs very useful? > > Of course, I have to admit I am using a hardware simulation environment > where non-lazy LONGINTs would indeed be very useful. > > Mika > > From rodney_bates at lcwb.coop Tue Apr 27 18:41:43 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Tue, 27 Apr 2010 11:41:43 -0500 Subject: [M3devel] INTEGER In-Reply-To: <20100424103435.A1CC41A20C2@async.async.caltech.edu> References: <20100421185631.GA17051@topoi.pooq.com> <80775CA2-A2FD-40AF-B235-7DB84127762E@cs.purdue.edu> <20100422123805.GA19259@topoi.pooq.com> <87B45DCC-2B8A-4C69-97D7-240BC1E2252D@cs.purdue.edu> <20100422145522.GA19946@topoi.pooq.com> <28339030-6005-4C28-872C-A68CF24BF4DF@cs.purdue.edu> <20100422154357.GA20043@topoi.pooq.com> <270A99B5-173E-413B-8C28-E1CA68870FD4@cs.purdue.edu> <20100423094903.GC21281@topoi.pooq.com> <20100423185214.BA2EF1A20E1@async.async.caltech.edu> <20100423165613.GA22126@topoi.pooq.com> <20100424103435.A1CC41A20C2@async.async.caltech.edu> Message-ID: <4BD713C7.2060607@lcwb.coop> Mika Nystrom wrote: > hendrik at topoi.pooq.com writes: >> On Fri, Apr 23, 2010 at 11:52:14AM -0700, Mika Nystrom wrote: >>> Is the infinite extent of the TEXT type a serious implementation difficulty? :-) >> Yes, actually. It requires heap storage allocation and indirection. That's just what >> it costs, so we pay it, since fixed-width strings aren't all that useful. >> >> But integer ranges of a size that matches the application (instead of the hardware) >> are quite feasible and useful; I'd rather not pay the proce of dynamic heap allocation >> for each integer. >> >> -- hendrik > > Ok here I have a proposal, modeled on how Modula-3 does arrays. > > The type specifier LONGINT to be valid in every context where an open > array is valid. > > A subrange of LONGINT to be treated like a non-open array. > > NEW(REF LONGINT, ..) would take two "size" specifiers, a minimum and a maximum, > of type LONGINT. It would be better to call these "bounds". The implementation presumably needs to have a variable number of native words to hold values that is derived from, but different from the bounds. The word "size", plus the analogy to open arrays made me at first try to interpret these these specifiers as word counts. > > For L, U, LONGINT literals, > > NEW(REF LONGINT, L, U) Presumably, you want to allow the bounds above to be runtime expressions, not just literals. The WITH statement example below suggests so. > > would produce the same thing as > > NEW(REF [L..U]) But [L..U] by itself would require L and U to be constants, so [L..U] is analogous to a fixed array? > > NEW(REF LONGINT, ..) is needed for dynamically sized LONGINTs. > So, again in analogy to open arrays, a _variable_ of type LONGINT would have bounds that, although computable at runtime, remain unchanged for the lifetime of the variable? > And then overload the arithmetic operations, the way arrays and REF RECORDs are, so > that for b and c REF LONGINT, > > b + c = b^ + c = b + c^ = b^ + c^ Here is where the tough problem in intermediate results rears its ugly head. What is the type of b + c and what are the bounds of b + c? Each of b and c could be: Literals, which don't have any bounds defined at all, expressions of type [L..U], with static bounds, or LONGINT, with dynamic bounds. If b + c ends up having type LONGINT (i.e., not [L..U]), what are its bounds, which the type LONGINT doesn't specify. In the case where b and/or c have type LONGINT, is there a shape check analogy that requires b and c both to have the same bounds? Open arrays don't get into these problems because there are no operators that deliver a newly-computed open array result. You can only move values around, and that will never change the size/bounds. > > Assignments carry an implicit range check. > > Assignment rules the same as INTEGER and its subranges. > > Use VAL to convert...? > > In short, expressions involving LONGINT have type LONGINT, but no "bare" LONGINT can > ever be created. I can't intuit the meaning of "bare" LONGINT. > > However note the following, perfectly legal. > > WITH a = b + c, > r = NEW(REF LONGINT, a, a) DO > r^ := a > END > > Also legal, note parameters: > > PROCEDURE Collatz(READONLY a : LONGINT; VAR b : LONGINT) = > BEGIN > CASE a MOD 2L OF > 0L => b := a DIV 2L > | > 1L => b := 3L * a + 1L > END > END Collatz; > > VALUE a : LONGINT would be discouraged. Returning LONGINT > would *not* be legal. ARRAY OF LONGINT would mean the LONGINTs > are limited to the same range, and used in NEW would take three > arguments, one of type INTEGER for the array size and two of type > LONGINT to specify the LONGINTs' bounds. I haven't thought this through fully, but I think this is going to need: 1) ARRAY [c..d] OF LONGINT is not legal, (most interestingly as a formal parameter), analogous to the existing rule that ARRAY [c..d] OF ARRAY OF INTEGER is illegal. 2) An expanded subtype rule for open/fixed arrays of LONGINT/subrange-of-LONGINT, analogous the one existing rule for just open/fixed arrays. > > Perhaps... > > PROCEDURE Collatz2(READONLY a : LONGINT; VAR b : LONGINT) > RAISES { Range } = > BEGIN > CASE a MOD 2L OF > 0L => b := a DIV 2L In this case, a DIV 2L could lie below the lower end of the range of b. > | > 1L => > WITH new = 3L * a + 1L DO (* is new actually stored anywhere!? *) Yes, it would have to be ------------^ I take it from this example (and the open array analogy) that variables of type LONGINT, unlike BigInteger, can't grow in range by assigning to them. > IF new > LAST(b) THEN > RAISE Range > ELSE > b := new > END > END > END > END Collatz2; > > My proposal gives you both heap-allocated dynamically sized LONGINT and > stack-allocated fixed-sized longints and allows you to mix them at will. > Collatz2 does seem a little bit disturbing, however. Can we rely on > alloca "under the covers"? (Architectures that don't provide alloca > could heap-allocate new in that example, *if* they need to.) I am not half as bothered by the implementation problem of allocating space for dynamically-sized temporaries as by defining the language rules for what the bounds/sizes are. If you say an intermediate result such as b + c has bounds that come from the bounds of b and c, then you lose my property 3) in my previous, general post. That is, you lose the property that INTEGER and its subranges currently have, that the intermediate result is the biggest possible without expanding into more memory and paying a performance penalty. If you try to preserve this property and allow intermediate results to occupy as much space as the operands do, then you have to expose into the language semantics, the mapping between bounds, which the programmer is aware of, and representation sizes (probably native word counts). This gets complicated really fast. If you make intermediate results unbounded and fully dynamic, i.e., as big as needed to hold the computed value, then you don't have an open array analogue any more, you have BigInteger, which has its own pros and cons, but is a quite different abstraction. This is further complicated by the fact that LONGINT literals don't have either defined bounds or defined representation size, so how do you specify these properties of intermediate results when an operand is a literal? This will probably lose the long-standing principles that an expression has an unambiguous, unique type, and that does not depend on how the expression is used. Only the BigInteger approach seems to work here. To make VAL reasonably usable for programmer-specified range changes, which will definitely be needed, you will probably have to allow for arithmetic where both operands are literals, as well as declarations of named constants with values specified in this way. And it all is probably complicated by the distinction that the bounds bounds are static and part of the type, (as for type [L..U]), but dynamic and part of the value (as for LONGINT), > > Another thing that occurs to me is that while + and - are straightforward, > *, DIV, and MOD are things you may well want to use very special and > specific algorithms for in a given application. It makes sense to let the > user replace the code for these operations. And now it begins to look > like C++. Sigh. > > Hendrik, I do think WITH causes similar problems even for strictly > range-limited numbers like the ones you are proposing? (And so does > expression evaluation, of course...) > > Now is it even reasonable to have this built in? What if the user wants > lazy evaluation? Are non-lazy LONGINTs very useful? > > Of course, I have to admit I am using a hardware simulation environment > where non-lazy LONGINTs would indeed be very useful. > > Mika > > Perhaps what you really want is to replace the two-member set {INTEGER, LONGINT} with an unbounded set of multi-word arithmetics, for different word counts. To do this and keep the (relative) semantic integrity of {INTEGER, LONGINT}, you would need to make each size a distinct base type. But then, I fear it would be very difficult to have open-array-like formal parameters and heap objects. We, of course, don't have anything like this with INTEGER, LONGINT}. From mika at async.async.caltech.edu Tue Apr 27 19:24:00 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Tue, 27 Apr 2010 10:24:00 -0700 Subject: [M3devel] INTEGER In-Reply-To: <4BD713C7.2060607@lcwb.coop> References: <20100421185631.GA17051@topoi.pooq.com> <80775CA2-A2FD-40AF-B235-7DB84127762E@cs.purdue.edu> <20100422123805.GA19259@topoi.pooq.com> <87B45DCC-2B8A-4C69-97D7-240BC1E2252D@cs.purdue.edu> <20100422145522.GA19946@topoi.pooq.com> <28339030-6005-4C28-872C-A68CF24BF4DF@cs.purdue.edu> <20100422154357.GA20043@topoi.pooq.com> <270A99B5-173E-413B-8C28-E1CA68870FD4@cs.purdue.edu> <20100423094903.GC21281@topoi.pooq.com> <20100423185214.BA2EF1A20E1@async.async.caltech.edu> <20100423165613.GA22126@topoi.pooq.com> <20100424103435.A1CC41A20C2@async.async.caltech.edu> <4BD713C7.2060607@lcwb.coop> Message-ID: <20100427172400.D491F1A2096@async.async.caltech.edu> Hi Rodney, Yes most of what you write is exactly as I was thinking too. It is a bit odd that you can't have ARRAY OF LONGINT. You can have ARRAY OF REF LONGINT, though. You say the subtyping rule for open/fixed arrays has to be expanded. Can you expand on this statement? I am not worried as you are by the range problem. The saving grace is that the language has very few arithmetic operators on integers. + - * DIV MOD. It's not hard to do range arithmetic on these such that one can easily figure out how much memory is required to hold intermediate results. If you're happy with alloca (I don't mind it), that's what you do. You have three options in so far as calculating the required space: 1. For known subranges of LONGINT, do it at compile time (no alloca required) 2. For "open" LONGINTs, at runtime, based on the passed-in types 3. For "open" LONGINTs, at runtime, based on the passed-in values Now as I said the proposal is that variables can themselves not be of type LONGINT but only subranges thereof. That means you can get away with stack allocation and don't need to do heap allocation. Since you bring up BigInteger, yes, it's precisely BigInteger, except the fact that since variables are always of fixed range, you can do it completely on the stack (as long as you are allowed to use alloca). The "type" of a longint literal x can be [x..x]. Mika "Rodney M. Bates" writes: > > >Mika Nystrom wrote: >> hendrik at topoi.pooq.com writes: >>> On Fri, Apr 23, 2010 at 11:52:14AM -0700, Mika Nystrom wrote: >>>> Is the infinite extent of the TEXT type a serious implementation difficult >y? :-) >>> Yes, actually. It requires heap storage allocation and indirection. That' >s just what >>> it costs, so we pay it, since fixed-width strings aren't all that useful. >>> >>> But integer ranges of a size that matches the application (instead of the h >ardware) >>> are quite feasible and useful; I'd rather not pay the proce of dynamic heap > allocation >>> for each integer. >>> >>> -- hendrik >> >> Ok here I have a proposal, modeled on how Modula-3 does arrays. >> >> The type specifier LONGINT to be valid in every context where an open >> array is valid. >> >> A subrange of LONGINT to be treated like a non-open array. >> >> NEW(REF LONGINT, ..) would take two "size" specifiers, a minimum and a maxim >um, >> of type LONGINT. > >It would be better to call these "bounds". The implementation presumably need >s >to have a variable number of native words to hold values that is derived from, >but different from the bounds. The word "size", plus the analogy to open arra >ys >made me at first try to interpret these these specifiers as word counts. > >> >> For L, U, LONGINT literals, >> >> NEW(REF LONGINT, L, U) > >Presumably, you want to allow the bounds above to be runtime >expressions, not just literals. The WITH statement example below >suggests so. > >> >> would produce the same thing as >> >> NEW(REF [L..U]) > >But [L..U] by itself would require L and U to be constants, so >[L..U] is analogous to a fixed array? > >> >> NEW(REF LONGINT, ..) is needed for dynamically sized LONGINTs. >> > >So, again in analogy to open arrays, a _variable_ of type LONGINT would >have bounds that, although computable at runtime, remain unchanged for >the lifetime of the variable? > >> And then overload the arithmetic operations, the way arrays and REF RECORDs >are, so >> that for b and c REF LONGINT, >> >> b + c = b^ + c = b + c^ = b^ + c^ > >Here is where the tough problem in intermediate results rears its ugly head. >What is the type of b + c and what are the bounds of b + c? Each of b and c >could be: Literals, which don't have any bounds defined at all, expressions >of type [L..U], with static bounds, or LONGINT, with dynamic bounds. > >If b + c ends up having type LONGINT (i.e., not [L..U]), what are its bounds, >which the type LONGINT doesn't specify. > >In the case where b and/or c have type LONGINT, is there a shape check analogy >that requires b and c both to have the same bounds? > >Open arrays don't get into these problems because there are no operators that >deliver a newly-computed open array result. You can only move values around, >and that will never change the size/bounds. > >> >> Assignments carry an implicit range check. >> >> Assignment rules the same as INTEGER and its subranges. >> >> Use VAL to convert...? >> >> In short, expressions involving LONGINT have type LONGINT, but no "bare" LON >GINT can >> ever be created. > >I can't intuit the meaning of "bare" LONGINT. >> >> However note the following, perfectly legal. >> >> WITH a = b + c, >> r = NEW(REF LONGINT, a, a) DO >> r^ := a >> END >> >> Also legal, note parameters: >> >> PROCEDURE Collatz(READONLY a : LONGINT; VAR b : LONGINT) = >> BEGIN >> CASE a MOD 2L OF >> 0L => b := a DIV 2L >> | >> 1L => b := 3L * a + 1L >> END >> END Collatz; >> >> VALUE a : LONGINT would be discouraged. Returning LONGINT >> would *not* be legal. ARRAY OF LONGINT would mean the LONGINTs >> are limited to the same range, and used in NEW would take three >> arguments, one of type INTEGER for the array size and two of type >> LONGINT to specify the LONGINTs' bounds. > >I haven't thought this through fully, but I think this is going to need: > >1) ARRAY [c..d] OF LONGINT is not legal, (most interestingly as a formal param >eter), > analogous to the existing rule that ARRAY [c..d] OF ARRAY OF INTEGER is il >legal. > >2) An expanded subtype rule for open/fixed arrays of LONGINT/subrange-of-LONGI >NT, > analogous the one existing rule for just open/fixed arrays. > >> >> Perhaps... >> >> PROCEDURE Collatz2(READONLY a : LONGINT; VAR b : LONGINT) >> RAISES { Range } = >> BEGIN >> CASE a MOD 2L OF >> 0L => b := a DIV 2L > >In this case, a DIV 2L could lie below the lower end of the range of b. > >> | >> 1L => >> WITH new = 3L * a + 1L DO (* is new actually stored anywhere!? *) > >Yes, it would have to be ------------^ > >I take it from this example (and the open array analogy) that variables >of type LONGINT, unlike BigInteger, can't grow in range by assigning to them. > >> IF new > LAST(b) THEN >> RAISE Range >> ELSE >> b := new >> END >> END >> END >> END Collatz2; >> >> My proposal gives you both heap-allocated dynamically sized LONGINT and >> stack-allocated fixed-sized longints and allows you to mix them at will. >> Collatz2 does seem a little bit disturbing, however. Can we rely on >> alloca "under the covers"? (Architectures that don't provide alloca >> could heap-allocate new in that example, *if* they need to.) > >I am not half as bothered by the implementation problem of allocating >space for dynamically-sized temporaries as by defining the language rules >for what the bounds/sizes are. If you say an intermediate result such as >b + c has bounds that come from the bounds of b and c, then you lose my >property 3) in my previous, general post. That is, you lose the >property that INTEGER and its subranges currently have, that the intermediate >result is the biggest possible without expanding into more memory and >paying a performance penalty. > >If you try to preserve this property and allow intermediate results to >occupy as much space as the operands do, then you have to expose into the >language semantics, the mapping between bounds, which the programmer >is aware of, and representation sizes (probably native word counts). >This gets complicated really fast. > >If you make intermediate results unbounded and fully dynamic, i.e., as big >as needed to hold the computed value, then you don't have an open array >analogue any more, you have BigInteger, which has its own pros and cons, >but is a quite different abstraction. > >This is further complicated by the fact that LONGINT literals don't have >either defined bounds or defined representation size, so how do you >specify these properties of intermediate results when an operand is >a literal? This will probably lose the long-standing principles that >an expression has an unambiguous, unique type, and that does not depend on >how the expression is used. Only the BigInteger approach seems to work here. > >To make VAL reasonably usable for programmer-specified range changes, which wi >ll >definitely be needed, you will probably have to allow for arithmetic where bot >h >operands are literals, as well as declarations of named constants with >values specified in this way. > >And it all is probably complicated by the distinction that the bounds >bounds are static and part of the type, (as for type [L..U]), but dynamic >and part of the value (as for LONGINT), > > >> >> Another thing that occurs to me is that while + and - are straightforward, >> *, DIV, and MOD are things you may well want to use very special and >> specific algorithms for in a given application. It makes sense to let the >> user replace the code for these operations. And now it begins to look >> like C++. Sigh. >> >> Hendrik, I do think WITH causes similar problems even for strictly >> range-limited numbers like the ones you are proposing? (And so does >> expression evaluation, of course...) >> >> Now is it even reasonable to have this built in? What if the user wants >> lazy evaluation? Are non-lazy LONGINTs very useful? >> >> Of course, I have to admit I am using a hardware simulation environment >> where non-lazy LONGINTs would indeed be very useful. >> >> Mika >> >> > >Perhaps what you really want is to replace the two-member set {INTEGER, LONGIN >T} >with an unbounded set of multi-word arithmetics, for different word counts. > >To do this and keep the (relative) semantic integrity of {INTEGER, LONGINT}, >you would need to make each size a distinct base type. But then, I fear it >would be very difficult to have open-array-like formal parameters and >heap objects. We, of course, don't have anything like this with INTEGER, LONG >INT}. From mika at async.async.caltech.edu Tue Apr 27 19:30:36 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Tue, 27 Apr 2010 10:30:36 -0700 Subject: [M3devel] INTEGER In-Reply-To: <20100427172400.D491F1A2096@async.async.caltech.edu> References: <20100421185631.GA17051@topoi.pooq.com> <80775CA2-A2FD-40AF-B235-7DB84127762E@cs.purdue.edu> <20100422123805.GA19259@topoi.pooq.com> <87B45DCC-2B8A-4C69-97D7-240BC1E2252D@cs.purdue.edu> <20100422145522.GA19946@topoi.pooq.com> <28339030-6005-4C28-872C-A68CF24BF4DF@cs.purdue.edu> <20100422154357.GA20043@topoi.pooq.com> <270A99B5-173E-413B-8C28-E1CA68870FD4@cs.purdue.edu> <20100423094903.GC21281@topoi.pooq.com> <20100423185214.BA2EF1A20E1@async.async.caltech.edu> <20100423165613.GA22126@topoi.pooq.com> <20100424103435.A1CC41A20C2@async.async.caltech.edu> <4BD713C7.2060607@lcwb.coop> <20100427172400.D491F1A2096@async.async.caltech.edu> Message-ID: <20100427173036.7DC501A2096@async.async.caltech.edu> Mika Nystrom writes: ... >I am not worried as you are by the range problem. The saving grace is >that the language has very few arithmetic operators on integers. >+ - * DIV MOD. It's not hard to do range arithmetic on these such that >one can easily figure out how much memory is required to hold intermediate >results. If you're happy with alloca (I don't mind it), that's what >you do. You have three options in so far as calculating the required >space: ... To clarify a bit further, my proposal is that the ranges be lost in the evaluation. Everything in the expression is simply of type LONGINT. When the final result is assigned to a variable, there is a range check (which can be dispensed with if the compiler can prove that there can be no overrun). Isn't this how INTEGER subranges work? a : [0..2]; b : [0..1]; a := 4*b - 2*b Mika From jay.krell at cornell.edu Tue Apr 27 19:55:12 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 27 Apr 2010 17:55:12 +0000 Subject: [M3devel] INTEGER In-Reply-To: <20100427172400.D491F1A2096@async.async.caltech.edu> References: <20100421185631.GA17051@topoi.pooq.com>, <80775CA2-A2FD-40AF-B235-7DB84127762E@cs.purdue.edu>, <20100422123805.GA19259@topoi.pooq.com>, <87B45DCC-2B8A-4C69-97D7-240BC1E2252D@cs.purdue.edu>, <20100422145522.GA19946@topoi.pooq.com>, <28339030-6005-4C28-872C-A68CF24BF4DF@cs.purdue.edu>, <20100422154357.GA20043@topoi.pooq.com>, <270A99B5-173E-413B-8C28-E1CA68870FD4@cs.purdue.edu>, <20100423094903.GC21281@topoi.pooq.com>, <20100423185214.BA2EF1A20E1@async.async.caltech.edu>, <20100423165613.GA22126@topoi.pooq.com>, <20100424103435.A1CC41A20C2@async.async.caltech.edu>, <4BD713C7.2060607@lcwb.coop>, <20100427172400.D491F1A2096@async.async.caltech.edu> Message-ID: > Since you bring up BigInteger, yes, it's precisely BigInteger, except > the fact that since variables are always of fixed range, you can do it > completely on the stack (as long as you are allowed to use alloca). You could implement a generic biginteger parameterized by how many bits/bytes/integers of precision it has and therefore be a fixed small size. Target.Int for example always has 64 bits, which is determined on roughly one line (ie: almost "generic"). When you read through the various multiprecision libraries, you often find likewise two such sets of types/functions -- fixed precision and precision that grows to fit values. ?- Jay ---------------------------------------- > To: rodney_bates at lcwb.coop > Date: Tue, 27 Apr 2010 10:24:00 -0700 > From: mika at async.async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] INTEGER > > Hi Rodney, > > Yes most of what you write is exactly as I was thinking too. > It is a bit odd that you can't have ARRAY OF LONGINT. You can have > ARRAY OF REF LONGINT, though. > > You say the subtyping rule for open/fixed arrays has to be expanded. > Can you expand on this statement? > > I am not worried as you are by the range problem. The saving grace is > that the language has very few arithmetic operators on integers. > + - * DIV MOD. It's not hard to do range arithmetic on these such that > one can easily figure out how much memory is required to hold intermediate > results. If you're happy with alloca (I don't mind it), that's what > you do. You have three options in so far as calculating the required > space: > > 1. For known subranges of LONGINT, do it at compile time (no alloca > required) > 2. For "open" LONGINTs, at runtime, based on the passed-in types > 3. For "open" LONGINTs, at runtime, based on the passed-in values > > Now as I said the proposal is that variables can themselves not be of > type LONGINT but only subranges thereof. That means you can get away > with stack allocation and don't need to do heap allocation. > > Since you bring up BigInteger, yes, it's precisely BigInteger, except > the fact that since variables are always of fixed range, you can do it > completely on the stack (as long as you are allowed to use alloca). > > The "type" of a longint literal x can be [x..x]. > > Mika > > > "Rodney M. Bates" writes: >> >> >>Mika Nystrom wrote: >>> hendrik at topoi.pooq.com writes: >>>> On Fri, Apr 23, 2010 at 11:52:14AM -0700, Mika Nystrom wrote: >>>>> Is the infinite extent of the TEXT type a serious implementation difficult >>y? :-) >>>> Yes, actually. It requires heap storage allocation and indirection. That' >>s just what >>>> it costs, so we pay it, since fixed-width strings aren't all that useful. >>>> >>>> But integer ranges of a size that matches the application (instead of the h >>ardware) >>>> are quite feasible and useful; I'd rather not pay the proce of dynamic heap >> allocation >>>> for each integer. >>>> >>>> -- hendrik >>> >>> Ok here I have a proposal, modeled on how Modula-3 does arrays. >>> >>> The type specifier LONGINT to be valid in every context where an open >>> array is valid. >>> >>> A subrange of LONGINT to be treated like a non-open array. >>> >>> NEW(REF LONGINT, ..) would take two "size" specifiers, a minimum and a maxim >>um, >>> of type LONGINT. >> >>It would be better to call these "bounds". The implementation presumably need >>s >>to have a variable number of native words to hold values that is derived from, >>but different from the bounds. The word "size", plus the analogy to open arra >>ys >>made me at first try to interpret these these specifiers as word counts. >> >>> >>> For L, U, LONGINT literals, >>> >>> NEW(REF LONGINT, L, U) >> >>Presumably, you want to allow the bounds above to be runtime >>expressions, not just literals. The WITH statement example below >>suggests so. >> >>> >>> would produce the same thing as >>> >>> NEW(REF [L..U]) >> >>But [L..U] by itself would require L and U to be constants, so >>[L..U] is analogous to a fixed array? >> >>> >>> NEW(REF LONGINT, ..) is needed for dynamically sized LONGINTs. >>> >> >>So, again in analogy to open arrays, a _variable_ of type LONGINT would >>have bounds that, although computable at runtime, remain unchanged for >>the lifetime of the variable? >> >>> And then overload the arithmetic operations, the way arrays and REF RECORDs >>are, so >>> that for b and c REF LONGINT, >>> >>> b + c = b^ + c = b + c^ = b^ + c^ >> >>Here is where the tough problem in intermediate results rears its ugly head. >>What is the type of b + c and what are the bounds of b + c? Each of b and c >>could be: Literals, which don't have any bounds defined at all, expressions >>of type [L..U], with static bounds, or LONGINT, with dynamic bounds. >> >>If b + c ends up having type LONGINT (i.e., not [L..U]), what are its bounds, >>which the type LONGINT doesn't specify. >> >>In the case where b and/or c have type LONGINT, is there a shape check analogy >>that requires b and c both to have the same bounds? >> >>Open arrays don't get into these problems because there are no operators that >>deliver a newly-computed open array result. You can only move values around, >>and that will never change the size/bounds. >> >>> >>> Assignments carry an implicit range check. >>> >>> Assignment rules the same as INTEGER and its subranges. >>> >>> Use VAL to convert...? >>> >>> In short, expressions involving LONGINT have type LONGINT, but no "bare" LON >>GINT can >>> ever be created. >> >>I can't intuit the meaning of "bare" LONGINT. >>> >>> However note the following, perfectly legal. >>> >>> WITH a = b + c, >>> r = NEW(REF LONGINT, a, a) DO >>> r^ := a >>> END >>> >>> Also legal, note parameters: >>> >>> PROCEDURE Collatz(READONLY a : LONGINT; VAR b : LONGINT) = >>> BEGIN >>> CASE a MOD 2L OF >>> 0L => b := a DIV 2L >>> | >>> 1L => b := 3L * a + 1L >>> END >>> END Collatz; >>> >>> VALUE a : LONGINT would be discouraged. Returning LONGINT >>> would *not* be legal. ARRAY OF LONGINT would mean the LONGINTs >>> are limited to the same range, and used in NEW would take three >>> arguments, one of type INTEGER for the array size and two of type >>> LONGINT to specify the LONGINTs' bounds. >> >>I haven't thought this through fully, but I think this is going to need: >> >>1) ARRAY [c..d] OF LONGINT is not legal, (most interestingly as a formal param >>eter), >> analogous to the existing rule that ARRAY [c..d] OF ARRAY OF INTEGER is il >>legal. >> >>2) An expanded subtype rule for open/fixed arrays of LONGINT/subrange-of-LONGI >>NT, >> analogous the one existing rule for just open/fixed arrays. >> >>> >>> Perhaps... >>> >>> PROCEDURE Collatz2(READONLY a : LONGINT; VAR b : LONGINT) >>> RAISES { Range } = >>> BEGIN >>> CASE a MOD 2L OF >>> 0L => b := a DIV 2L >> >>In this case, a DIV 2L could lie below the lower end of the range of b. >> >>> | >>> 1L => >>> WITH new = 3L * a + 1L DO (* is new actually stored anywhere!? *) >> >>Yes, it would have to be ------------^ >> >>I take it from this example (and the open array analogy) that variables >>of type LONGINT, unlike BigInteger, can't grow in range by assigning to them. >> >>> IF new> LAST(b) THEN >>> RAISE Range >>> ELSE >>> b := new >>> END >>> END >>> END >>> END Collatz2; >>> >>> My proposal gives you both heap-allocated dynamically sized LONGINT and >>> stack-allocated fixed-sized longints and allows you to mix them at will. >>> Collatz2 does seem a little bit disturbing, however. Can we rely on >>> alloca "under the covers"? (Architectures that don't provide alloca >>> could heap-allocate new in that example, *if* they need to.) >> >>I am not half as bothered by the implementation problem of allocating >>space for dynamically-sized temporaries as by defining the language rules >>for what the bounds/sizes are. If you say an intermediate result such as >>b + c has bounds that come from the bounds of b and c, then you lose my >>property 3) in my previous, general post. That is, you lose the >>property that INTEGER and its subranges currently have, that the intermediate >>result is the biggest possible without expanding into more memory and >>paying a performance penalty. >> >>If you try to preserve this property and allow intermediate results to >>occupy as much space as the operands do, then you have to expose into the >>language semantics, the mapping between bounds, which the programmer >>is aware of, and representation sizes (probably native word counts). >>This gets complicated really fast. >> >>If you make intermediate results unbounded and fully dynamic, i.e., as big >>as needed to hold the computed value, then you don't have an open array >>analogue any more, you have BigInteger, which has its own pros and cons, >>but is a quite different abstraction. >> >>This is further complicated by the fact that LONGINT literals don't have >>either defined bounds or defined representation size, so how do you >>specify these properties of intermediate results when an operand is >>a literal? This will probably lose the long-standing principles that >>an expression has an unambiguous, unique type, and that does not depend on >>how the expression is used. Only the BigInteger approach seems to work here. >> >>To make VAL reasonably usable for programmer-specified range changes, which wi >>ll >>definitely be needed, you will probably have to allow for arithmetic where bot >>h >>operands are literals, as well as declarations of named constants with >>values specified in this way. >> >>And it all is probably complicated by the distinction that the bounds >>bounds are static and part of the type, (as for type [L..U]), but dynamic >>and part of the value (as for LONGINT), >> >> >>> >>> Another thing that occurs to me is that while + and - are straightforward, >>> *, DIV, and MOD are things you may well want to use very special and >>> specific algorithms for in a given application. It makes sense to let the >>> user replace the code for these operations. And now it begins to look >>> like C++. Sigh. >>> >>> Hendrik, I do think WITH causes similar problems even for strictly >>> range-limited numbers like the ones you are proposing? (And so does >>> expression evaluation, of course...) >>> >>> Now is it even reasonable to have this built in? What if the user wants >>> lazy evaluation? Are non-lazy LONGINTs very useful? >>> >>> Of course, I have to admit I am using a hardware simulation environment >>> where non-lazy LONGINTs would indeed be very useful. >>> >>> Mika >>> >>> >> >>Perhaps what you really want is to replace the two-member set {INTEGER, LONGIN >>T} >>with an unbounded set of multi-word arithmetics, for different word counts. >> >>To do this and keep the (relative) semantic integrity of {INTEGER, LONGINT}, >>you would need to make each size a distinct base type. But then, I fear it >>would be very difficult to have open-array-like formal parameters and >>heap objects. We, of course, don't have anything like this with INTEGER, LONG >>INT}. From hosking at cs.purdue.edu Wed Apr 28 03:51:53 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 27 Apr 2010 21:51:53 -0400 Subject: [M3devel] cooperative suspend? In-Reply-To: References: Message-ID: <19A8CA05-F586-4F54-8BAF-10BACFB1C45C@cs.purdue.edu> Ultimately we don't really want stop-the-world at all. What we really need is per-thread suspension. For scalability we should be aiming to stop threads individually rather than all at once. This means some sort of per-thread (local) mechanism. On 27 Apr 2010, at 05:01, Jay K wrote: > > cooperative suspend > > > Tony, you mind if I take a stab at "cooperative suspend" > fairly soon? > I can't find a good way to suspend threads on VMS. > Or even get context in a signal handler. > It will be a boolen in Target.i3, so no existing targets affected. > Of course I'll test it on an existing target with the boolean set wrong. :) > > > To optimize size instead of speed, I think the "every so often > extra generated code" should be a call to a parameter-less function. > Instead of checking a per-thread or global variable. > > Something like: > > > VAR threadRequestingSuspend: ADDRESS; > > > PROCEDURE Thread.PollSuspend() > BEGIN > IF threadRequestingSuspend = NIL THEN RETURN END; > PollSuspendSlow(); > END PollSuspend; > > > (* This is split to avoid needing a frame in PollSuspend. *) > PROCEDURE PollSuspendSlow() > VAR self: ADDRESS; > BEGIN > IF threadRequestingSuspend = NIL THEN RETURN END; > self := GetActivation(); > IF self = threadRequestingSuspend THEN RETURN END; (* important consideration! *) > GetContext(self.context); (* roughly *) > self.suspended := TRUE; (* roughly *) > WaitForResume(); (* details to be determined, either the semaphore > * or maybe acquire per-thread lock. *) > END PollSuspendSlow; > > > The poll call could also be a function pointer and usually point to a function that does nothing. > But that'd require loading the address from a global, and calling it. > Probably more bloat than calling direct instead of indirect. > > > - Jay > From jay.krell at cornell.edu Wed Apr 28 05:32:08 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 28 Apr 2010 03:32:08 +0000 Subject: [M3devel] cooperative suspend? In-Reply-To: <19A8CA05-F586-4F54-8BAF-10BACFB1C45C@cs.purdue.edu> References: , <19A8CA05-F586-4F54-8BAF-10BACFB1C45C@cs.purdue.edu> Message-ID: Ok. I still like calling a parameter-less function for code size. That would lead to perhaps, if any number of threads can be suspended, and compatible with current direction of suspending all of them: VAR anyThreadsBeingSuspended: BOOLEAN; PROCEDURE PollSuspend() = BEGIN IF anyThreadsBeingSuspended = FALSE THEN RETURN END; PollSuspendSlow(); END PollSuspend; PROCEDURE PollSuspendSlow() = VAR self := GetActivation(); BEGIN IF NOT self.suspend THEN RETURN END; .. more stuff here .. END PollSuspendSlow; or if only one suspend would be requested a time: VAR threadToSuspend: ADDRESS; PROCEDURE PollSuspend() = BEGIN IF threadToSuspend = NIL THEN RETURN END; PollSuspendSlow(); END PollSuspend; PROCEDURE PollSuspendSlow() = VAR self := GetActivation(); BEGIN IF self <> threadToSuspend THEN RETURN END; .. more stuff here .. END PollSuspendSlow; I imagine what is "really" ideal is to request 1 or more threads to suspend, and then in the "more stuff here", they tell the requester they have suspended. ? That way, if some thread takes a while to suspend, the whole process isn't backed up behind it. ? That would would favor my first exposition (with per thread self.suspend boolean). Which fits current scheme in that you'd just set them all to true. - Jay ---------------------------------------- > From: hosking at cs.purdue.edu > Date: Tue, 27 Apr 2010 21:51:53 -0400 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] cooperative suspend? > > Ultimately we don't really want stop-the-world at all. What we really need is per-thread suspension. For scalability we should be aiming to stop threads individually rather than all at once. This means some sort of per-thread (local) mechanism. > > On 27 Apr 2010, at 05:01, Jay K wrote: > >> >> cooperative suspend >> >> >> Tony, you mind if I take a stab at "cooperative suspend" >> fairly soon? >> I can't find a good way to suspend threads on VMS. >> Or even get context in a signal handler. >> It will be a boolen in Target.i3, so no existing targets affected. >> Of course I'll test it on an existing target with the boolean set wrong. :) >> >> >> To optimize size instead of speed, I think the "every so often >> extra generated code" should be a call to a parameter-less function. >> Instead of checking a per-thread or global variable. >> >> Something like: >> >> >> VAR threadRequestingSuspend: ADDRESS; >> >> >> PROCEDURE Thread.PollSuspend() >> BEGIN >> IF threadRequestingSuspend = NIL THEN RETURN END; >> PollSuspendSlow(); >> END PollSuspend; >> >> >> (* This is split to avoid needing a frame in PollSuspend. *) >> PROCEDURE PollSuspendSlow() >> VAR self: ADDRESS; >> BEGIN >> IF threadRequestingSuspend = NIL THEN RETURN END; >> self := GetActivation(); >> IF self = threadRequestingSuspend THEN RETURN END; (* important consideration! *) >> GetContext(self.context); (* roughly *) >> self.suspended := TRUE; (* roughly *) >> WaitForResume(); (* details to be determined, either the semaphore >> * or maybe acquire per-thread lock. *) >> END PollSuspendSlow; >> >> >> The poll call could also be a function pointer and usually point to a function that does nothing. >> But that'd require loading the address from a global, and calling it. >> Probably more bloat than calling direct instead of indirect. >> >> >> - Jay >> > From wagner at elegosoft.com Wed Apr 28 10:40:44 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 28 Apr 2010 10:40:44 +0200 Subject: [M3devel] Fwd: Re: [CM3] #1084: CM3 for Solaris X86? Message-ID: <20100428104044.14rqktckgk0w8kws@mail.elegosoft.com> Seems to have been discarded, so I forward it explicitly. Anybody interested? Olaf ----- Forwarded message from bugs at elego.de ----- Date: Wed, 28 Apr 2010 08:31:06 -0000 From: CM3 Reply-To: CM3 Subject: Re: [CM3] #1084: CM3 for Solaris X86? To: @MISSING_DOMAIN #1084: CM3 for Solaris X86? -------------------------------+-------------------------------------------- Reporter: risaac@? | Owner: wagner Type: sw-feature | Status: new Priority: medium | Milestone: CM3 Release 5.9 Component: installation | Version: 5.8-RC2 Severity: non-critical | Keywords: solaris x86 Relnote: | Confidential: no Org: | Estimatedhours: 0 Hours: 0 | Billable: 0 Totalhours: 0 | Internal: 0 -------------------------------+-------------------------------------------- Htr: Fix: Env: Solaris 10 x86: SunOS localhost 5.10 Generic_137138-09 i86pc i386 i86pc -------------------------------+-------------------------------------------- Changes (by wagner): * cc: m3devel@? (added) * milestone: => CM3 Release 5.9 Comment: Solaris for x86 probably wouldn't be difficult to add, as both operating system specific code and processor specific code should already be there. None of the developers seems to have set up such a system yet though. For more than a short-time availability and from a release engineering point of view the acquiration of an appropriate build and test server (preferrably working as a Hudson slave) would be important. So if you or one of the cm3 developers can arrange to place such a machine at Hudson's disposal (will generate some load now and then), that would be a great start. Jay Krell has a whole zoo of hardware/OS setup; I'm not sure if he's interested and willing to provide one more. But of course this request should not be restricted to his person, but to all who may be interested (CC'ed to m3devel for this purpose). A (virtual) machine with remote ssh access for an ordinary user should be all that is needed for a CM3 deveoper to add the target platform and for Hudson to run builds and tests. -- Ticket URL: CM3 Critical Mass Modula3 Compiler ----- End forwarded message ----- -- 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 Apr 28 16:22:55 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 28 Apr 2010 10:22:55 -0400 Subject: [M3devel] cooperative suspend? In-Reply-To: References: , <19A8CA05-F586-4F54-8BAF-10BACFB1C45C@cs.purdue.edu> Message-ID: <8E176F01-29AD-4A64-8395-966AE9A19181@cs.purdue.edu> On 27 Apr 2010, at 23:32, Jay K wrote: > > Ok. I still like calling a parameter-less function for code size. > > > That would lead to perhaps, if any number of threads can be suspended, > and compatible with current direction of suspending all of them: > > > VAR anyThreadsBeingSuspended: BOOLEAN; We could have a global array with an entry/bit per thread. It would limit the number of total threads (because we'd want it statically allocated), but has the advantage that we never divert threads that don't need to suspend. > PROCEDURE PollSuspend() = > BEGIN > IF anyThreadsBeingSuspended = FALSE THEN RETURN END; > PollSuspendSlow(); > END PollSuspend; We could easily inline the pollcheck using the compiler. > PROCEDURE PollSuspendSlow() = > VAR self := GetActivation(); > BEGIN > IF NOT self.suspend THEN RETURN END; > .. more stuff here .. > END PollSuspendSlow; > > > or if only one suspend would be requested a time: > > > VAR threadToSuspend: ADDRESS; Ultimately we want more than just suspend. We really want pairwise handshakes between threads, with the possibility of many in flight simultaneously. This gives us the ability to do biased lock revocation very efficiently. > PROCEDURE PollSuspend() = > BEGIN > IF threadToSuspend = NIL THEN RETURN END; > PollSuspendSlow(); > END PollSuspend; > > > PROCEDURE PollSuspendSlow() = > VAR self := GetActivation(); > BEGIN > IF self <> threadToSuspend THEN RETURN END; > .. more stuff here .. > END PollSuspendSlow; > > > I imagine what is "really" ideal is to request 1 or more threads to suspend, and then in the "more stuff here", they tell the requester they have suspended. ? Yeah, or simply deliver an ack that they have seen the event. > That way, if some thread takes a while to suspend, the whole process isn't backed up behind it. ? Exactly. > That would would favor my first exposition (with per thread self.suspend boolean). > Which fits current scheme in that you'd just set them all to true. Yes, that would work. I like it. > > > > - Jay > > > ---------------------------------------- >> From: hosking at cs.purdue.edu >> Date: Tue, 27 Apr 2010 21:51:53 -0400 >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] cooperative suspend? >> >> Ultimately we don't really want stop-the-world at all. What we really need is per-thread suspension. For scalability we should be aiming to stop threads individually rather than all at once. This means some sort of per-thread (local) mechanism. >> >> On 27 Apr 2010, at 05:01, Jay K wrote: >> >>> >>> cooperative suspend >>> >>> >>> Tony, you mind if I take a stab at "cooperative suspend" >>> fairly soon? >>> I can't find a good way to suspend threads on VMS. >>> Or even get context in a signal handler. >>> It will be a boolen in Target.i3, so no existing targets affected. >>> Of course I'll test it on an existing target with the boolean set wrong. :) >>> >>> >>> To optimize size instead of speed, I think the "every so often >>> extra generated code" should be a call to a parameter-less function. >>> Instead of checking a per-thread or global variable. >>> >>> Something like: >>> >>> >>> VAR threadRequestingSuspend: ADDRESS; >>> >>> >>> PROCEDURE Thread.PollSuspend() >>> BEGIN >>> IF threadRequestingSuspend = NIL THEN RETURN END; >>> PollSuspendSlow(); >>> END PollSuspend; >>> >>> >>> (* This is split to avoid needing a frame in PollSuspend. *) >>> PROCEDURE PollSuspendSlow() >>> VAR self: ADDRESS; >>> BEGIN >>> IF threadRequestingSuspend = NIL THEN RETURN END; >>> self := GetActivation(); >>> IF self = threadRequestingSuspend THEN RETURN END; (* important consideration! *) >>> GetContext(self.context); (* roughly *) >>> self.suspended := TRUE; (* roughly *) >>> WaitForResume(); (* details to be determined, either the semaphore >>> * or maybe acquire per-thread lock. *) >>> END PollSuspendSlow; >>> >>> >>> The poll call could also be a function pointer and usually point to a function that does nothing. >>> But that'd require loading the address from a global, and calling it. >>> Probably more bloat than calling direct instead of indirect. >>> >>> >>> - Jay >>> >> From rodney_bates at lcwb.coop Thu Apr 29 18:07:00 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 29 Apr 2010 11:07:00 -0500 Subject: [M3devel] INTEGER In-Reply-To: <20100427173036.7DC501A2096@async.async.caltech.edu> References: <20100421185631.GA17051@topoi.pooq.com> <80775CA2-A2FD-40AF-B235-7DB84127762E@cs.purdue.edu> <20100422123805.GA19259@topoi.pooq.com> <87B45DCC-2B8A-4C69-97D7-240BC1E2252D@cs.purdue.edu> <20100422145522.GA19946@topoi.pooq.com> <28339030-6005-4C28-872C-A68CF24BF4DF@cs.purdue.edu> <20100422154357.GA20043@topoi.pooq.com> <270A99B5-173E-413B-8C28-E1CA68870FD4@cs.purdue.edu> <20100423094903.GC21281@topoi.pooq.com> <20100423185214.BA2EF1A20E1@async.async.caltech.edu> <20100423165613.GA22126@topoi.pooq.com> <20100424103435.A1CC41A20C2@async.async.caltech.edu> <4BD713C7.2060607@lcwb.coop> <20100427172400.D491F1A2096@async.async.caltech.edu> <20100427173036.7DC501A2096@async.async.caltech.edu> Message-ID: <4BD9AEA4.9080505@lcwb.coop> Oh, I get it! You are proposing a _mixed_ approach, where the values the programmer can designate are of fixed (though possibly nonstatic) size (like open arrays) but the intermediate results are of unbounded size that re-adapts to hold the actual value each time an operator is evaluated, (like BigInteger). And because only intermediate results work this way, they can be stack allocated, because intermediate results have LIFO lifetimes. These are quite different approaches to arithmetic. It does seem at least a bit strange to mix them in this way. Mika Nystrom wrote: > Mika Nystrom writes: > ... >> I am not worried as you are by the range problem. The saving grace is >> that the language has very few arithmetic operators on integers. >> + - * DIV MOD. It's not hard to do range arithmetic on these such that >> one can easily figure out how much memory is required to hold intermediate >> results. If you're happy with alloca (I don't mind it), that's what >> you do. You have three options in so far as calculating the required >> space: > ... > > To clarify a bit further, my proposal is that the ranges be lost in > the evaluation. Everything in the expression is simply of type LONGINT. > When the final result is assigned to a variable, there is a range check > (which can be dispensed with if the compiler can prove that there can > be no overrun). > > Isn't this how INTEGER subranges work? > > a : [0..2]; > b : [0..1]; > > a := 4*b - 2*b Well, not really. INTEGER intermediate results (even when the operands have subrange type) are computed in the fixed size INTEGER. This could sometimes be a lot bigger than the subranges and in some cases big enough to hold all possible results, given small subrange operandss. But they are still fixed size (and maximally efficient). The intermediate result can still overflow in many cases. This is quite different from a size that always adapts to the actual value computed, every time the operator is evaluated, and thus can never overflow. I thought you were trying to do this in your proposal, just with bigger sizes. Of course, what happens when an overflow occurs is a different question. Not very satisfactorily handled now, even for INTEGER, IMO. But it is not really possible in any language to handle overflows both well and efficiently, given current hardware. In any case, it's an orthogonal issue to when overflows happen. > > Mika > From hendrik at topoi.pooq.com Thu Apr 29 14:43:15 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 29 Apr 2010 08:43:15 -0400 Subject: [M3devel] INTEGER In-Reply-To: <4BD9AEA4.9080505@lcwb.coop> References: <20100422154357.GA20043@topoi.pooq.com> <270A99B5-173E-413B-8C28-E1CA68870FD4@cs.purdue.edu> <20100423094903.GC21281@topoi.pooq.com> <20100423185214.BA2EF1A20E1@async.async.caltech.edu> <20100423165613.GA22126@topoi.pooq.com> <20100424103435.A1CC41A20C2@async.async.caltech.edu> <4BD713C7.2060607@lcwb.coop> <20100427172400.D491F1A2096@async.async.caltech.edu> <20100427173036.7DC501A2096@async.async.caltech.edu> <4BD9AEA4.9080505@lcwb.coop> Message-ID: <20100429124315.GB12060@topoi.pooq.com> On Thu, Apr 29, 2010 at 11:07:00AM -0500, Rodney M. Bates wrote: > Oh, I get it! You are proposing a _mixed_ approach, where the values > the programmer can designate are of fixed (though possibly nonstatic) > size (like open arrays) but the intermediate results are of unbounded > size that re-adapts to hold the actual value each time an operator is > evaluated, (like BigInteger). And because only intermediate results > work this way, they can be stack allocated, because intermediate > results have LIFO lifetimes. In fact, the sizes of intermediate results can be determined statically, in theory, at least. An arithmetic operation with subranges as arguments has at most a finite number of possible argument pairs, and therefore at mist a finite number of possible results. A finite set of integers has a maximum and a minimum. In practices, there might be operations (such as shifts and exponentiation) for which there bounds are impractical. -- hendrik > > These are quite different approaches to arithmetic. It does seem > at least a bit strange to mix them in this way. Keeping track of the maximum sizes statically makes it a little less strange. -- hendrik From mika at async.async.caltech.edu Thu Apr 29 20:59:43 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Thu, 29 Apr 2010 11:59:43 -0700 Subject: [M3devel] INTEGER In-Reply-To: <20100429124315.GB12060@topoi.pooq.com> References: <20100422154357.GA20043@topoi.pooq.com> <270A99B5-173E-413B-8C28-E1CA68870FD4@cs.purdue.edu> <20100423094903.GC21281@topoi.pooq.com> <20100423185214.BA2EF1A20E1@async.async.caltech.edu> <20100423165613.GA22126@topoi.pooq.com> <20100424103435.A1CC41A20C2@async.async.caltech.edu> <4BD713C7.2060607@lcwb.coop> <20100427172400.D491F1A2096@async.async.caltech.edu> <20100427173036.7DC501A2096@async.async.caltech.edu> <4BD9AEA4.9080505@lcwb.coop> <20100429124315.GB12060@topoi.pooq.com> Message-ID: <20100429185943.334171A20A4@async.async.caltech.edu> hendrik at topoi.pooq.com writes: >On Thu, Apr 29, 2010 at 11:07:00AM -0500, Rodney M. Bates wrote: >> Oh, I get it! You are proposing a _mixed_ approach, where the values >> the programmer can designate are of fixed (though possibly nonstatic) >> size (like open arrays) but the intermediate results are of unbounded >> size that re-adapts to hold the actual value each time an operator is >> evaluated, (like BigInteger). And because only intermediate results >> work this way, they can be stack allocated, because intermediate >> results have LIFO lifetimes. > >In fact, the sizes of intermediate results can be determined statically, >in theory, at least. An arithmetic operation with subranges as >arguments has at most a finite number of possible argument pairs, and >therefore at mist a finite number of possible results. A finite set of >integers has a maximum and a minimum. > >In practices, there might be operations (such as shifts and >exponentiation) for which there bounds are impractical. > >-- hendrik Well, the language only has built-in operations for which the range checks are easy. The problem with only allowing static sized LONGINTs is that you can't write PROCEDURE F(READONLY a, b : LONGINT; VAR c : LONGINT) = BEGIN c := a + b END F; Instead you get a proliferation of Fs to cover every possible range... I suppose you can do it with generics but oh what a pain. Mika From wagner at elegosoft.com Thu Apr 29 21:43:16 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 29 Apr 2010 21:43:16 +0200 Subject: [M3devel] one more (64 bit) m3tests issue Message-ID: <20100429214316.p9i0v1j5kw04swwk@mail.elegosoft.com> For AMD64_..., there is one more unexpected test failure: http://hudson.modula3.com:8080/view/cm3/job/cm3-test-m3tests-AMD64_LINUX/555/testReport/(root)/m3tests/p179__alignment_of_ARRAY_OF_BITS_32_FOR_INTEGER This test fails on all AMD64 platforms. Comments? Ignore? I think all the others are either ancient legacy or have been looked at by Tony and Jay and postponed. 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 Thu Apr 29 22:32:42 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 29 Apr 2010 22:32:42 +0200 Subject: [M3devel] M3 language definition in cm3/doc Message-ID: <20100429223242.qanzwguv4wks80kc@mail.elegosoft.com> The M3 language definition is contained in several formats in the cm3 repository and web pages. Recent changes to the language have been added by Antony Hosking and Rodney Bates to cm3/doc/reference/complete/m3-defn-complete.tex There are also versions in other formats: cm3/doc/reference/complete/m3-defn-complete.html cm3/doc/reference/complete/m3-defn-complete.ps cm3/doc/reference/complete/m3-defn-complete.pdf Critical Mass added a split-up HTML version for online access, which I was not able to exactly recreate: cm3/doc/reference/*.html There is now a new variant of split HTML files in cm3/doc/reference/complete/html/*.html The files in this directory as well as the complete versions above can now be generated automatically by simply running `make' in the directory cm3/doc/reference/complete/. latex2html is used for HTML conversion, dvips for PS, and dvipdf for PDF creation. Of course latex2e must also be installed to create the device independent file (.dvi). I have updated all the formats based on the (hopefully) latest and greatest language spec in m3-defn-complete.tex. I haven't checked that thoroughly but trusted that it was all right. If you find any mistakes, please let me know. Please also note that I had to change some tabbing environments, as the latex2html script had some problems with generating readable HTML for existing ones. To ensure readable indentation, all lines should begin with a tab (\>). I have merged all the changes from the release branch to the trunk, too. I haven't tested them there though. Thanks for your attention, 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 lcwb.coop Thu Apr 29 23:19:09 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 29 Apr 2010 16:19:09 -0500 Subject: [M3devel] INTEGER In-Reply-To: <20100429124315.GB12060@topoi.pooq.com> References: <20100422154357.GA20043@topoi.pooq.com> <270A99B5-173E-413B-8C28-E1CA68870FD4@cs.purdue.edu> <20100423094903.GC21281@topoi.pooq.com> <20100423185214.BA2EF1A20E1@async.async.caltech.edu> <20100423165613.GA22126@topoi.pooq.com> <20100424103435.A1CC41A20C2@async.async.caltech.edu> <4BD713C7.2060607@lcwb.coop> <20100427172400.D491F1A2096@async.async.caltech.edu> <20100427173036.7DC501A2096@async.async.caltech.edu> <4BD9AEA4.9080505@lcwb.coop> <20100429124315.GB12060@topoi.pooq.com> Message-ID: <4BD9F7CD.50704@lcwb.coop> hendrik at topoi.pooq.com wrote: > On Thu, Apr 29, 2010 at 11:07:00AM -0500, Rodney M. Bates wrote: >> Oh, I get it! You are proposing a _mixed_ approach, where the values >> the programmer can designate are of fixed (though possibly nonstatic) >> size (like open arrays) but the intermediate results are of unbounded >> size that re-adapts to hold the actual value each time an operator is >> evaluated, (like BigInteger). And because only intermediate results >> work this way, they can be stack allocated, because intermediate >> results have LIFO lifetimes. > > In fact, the sizes of intermediate results can be determined statically, > in theory, at least. Yes. But only when all operands are "fixed" longint types, i.e. [L..U]. If any of them are "open" LONGINT, then the bounds are dynamic, in the proposal. An arithmetic operation with subranges as > arguments has at most a finite number of possible argument pairs, and > therefore at mist a finite number of possible results. A finite set of > integers has a maximum and a minimum. > > In practices, there might be operations (such as shifts and > exponentiation) for which there bounds are impractical. > > -- hendrik > >> These are quite different approaches to arithmetic. It does seem >> at least a bit strange to mix them in this way. > > Keeping track of the maximum sizes statically makes it a little less > strange. > > -- hendrik > From rodney_bates at lcwb.coop Thu Apr 29 23:45:23 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 29 Apr 2010 16:45:23 -0500 Subject: [M3devel] one more (64 bit) m3tests issue In-Reply-To: <20100429214316.p9i0v1j5kw04swwk@mail.elegosoft.com> References: <20100429214316.p9i0v1j5kw04swwk@mail.elegosoft.com> Message-ID: <4BD9FDF3.6070701@lcwb.coop> Looks like a 32/64 bit independence bug in the test. The test description, from m3tests/src/makefile says "alignment of ARRAY OF BITS 32 FOR INTEGER". This type would be illegal on a 64-bit machine. But the description is wrong. The type in the source file m3test/src/p1/p179/Main.m3 is actually "BITS 32 FOR [16_80000000..16_7FFFFFFF]" And, on a 64-bit native machine, this really is an empty type, as the compiler complains. On a 64-bit machine, 16_80000000 means 16_00000000800000, positive and larger than the upper bound. How about BITS 32 FOR [Word.Shift(-1,31)..16_7FFFFFFF], to be the same on any machine with >= 32-bit native word size? Or (-16_7FFFFFFF)-1?, which would be non-overflowing and same value on >= 32 bits. I don't think this test can be coded for < 32 bits or other than 2's complement and still be the same test. Wasn't there a discussion of this a while back? Olaf Wagner wrote: > For AMD64_..., there is one more unexpected test failure: > > http://hudson.modula3.com:8080/view/cm3/job/cm3-test-m3tests-AMD64_LINUX/555/testReport/(root)/m3tests/p179__alignment_of_ARRAY_OF_BITS_32_FOR_INTEGER > > > This test fails on all AMD64 platforms. > > Comments? Ignore? > > I think all the others are either ancient legacy or have been looked at > by Tony and Jay and postponed. > > Olaf From mika at async.async.caltech.edu Fri Apr 30 00:07:19 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Thu, 29 Apr 2010 15:07:19 -0700 Subject: [M3devel] INTEGER In-Reply-To: <4BD9AEA4.9080505@lcwb.coop> References: <20100421185631.GA17051@topoi.pooq.com> <80775CA2-A2FD-40AF-B235-7DB84127762E@cs.purdue.edu> <20100422123805.GA19259@topoi.pooq.com> <87B45DCC-2B8A-4C69-97D7-240BC1E2252D@cs.purdue.edu> <20100422145522.GA19946@topoi.pooq.com> <28339030-6005-4C28-872C-A68CF24BF4DF@cs.purdue.edu> <20100422154357.GA20043@topoi.pooq.com> <270A99B5-173E-413B-8C28-E1CA68870FD4@cs.purdue.edu> <20100423094903.GC21281@topoi.pooq.com> <20100423185214.BA2EF1A20E1@async.async.caltech.edu> <20100423165613.GA22126@topoi.pooq.com> <20100424103435.A1CC41A20C2@async.async.caltech.edu> <4BD713C7.2060607@lcwb.coop> <20100427172400.D491F1A2096@async.async.caltech.edu> <20100427173036.7DC501A2096@async.async.caltech.edu> <4BD9AEA4.9080505@lcwb.coop> Message-ID: <20100429220719.6DD991A20A4@async.async.caltech.edu> "Rodney M. Bates" writes: >Oh, I get it! You are proposing a _mixed_ approach, where the values >the programmer can designate are of fixed (though possibly nonstatic) >size (like open arrays) but the intermediate results are of unbounded >size that re-adapts to hold the actual value each time an operator is >evaluated, (like BigInteger). And because only intermediate results >work this way, they can be stack allocated, because intermediate >results have LIFO lifetimes. > >These are quite different approaches to arithmetic. It does seem >at least a bit strange to mix them in this way. Speeeaking of stack allocation's being possible owing to LIFO lifetimes..... The Green Book says the following: "[Lisp, ML, Smalltalk, and CLU's] general disposition towards heap allocation rather than stack allocation remains" May I draw the conclusion that exposing the difference between stack and heap allocation in the language is fair game for the Modula-3 definition? What I'm getting at is this. If my LONGINT proposal is workable, the following ought to be workable too: VAR a : NEW(ARRAY OF T, n); (Note: no REF, also no =.) It's an object upon which it is legal to perform exactly those things that are legal to do to b^, where previously b := NEW(REF ARRAY OF T, n) I don't have a good name for the type of a ("evanescent array"?), but I think being able to do this would make it possible to write efficient code in ways that today only C++ (to my knowledge) allows. I think the Modula-3 rules on what can (more importantly can't) be done with open arrays may be enough to restrict the feature so it doesn't lead to new complications (in the language definition---the implementation I'm not sure about). The lowest levels of the implementation would use alloca with a fallback to heap allocation if for some reason variable-sized stack objects are not allowed. LONGINT is then a rather natural specialization of the same rules. (Cf. ARRAY OF BITS 1 FOR BOOLEAN vs. SET OF.) Mika From rodney_bates at lcwb.coop Fri Apr 30 02:30:44 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 29 Apr 2010 19:30:44 -0500 Subject: [M3devel] INTEGER In-Reply-To: <20100429220719.6DD991A20A4@async.async.caltech.edu> References: <20100421185631.GA17051@topoi.pooq.com> <80775CA2-A2FD-40AF-B235-7DB84127762E@cs.purdue.edu> <20100422123805.GA19259@topoi.pooq.com> <87B45DCC-2B8A-4C69-97D7-240BC1E2252D@cs.purdue.edu> <20100422145522.GA19946@topoi.pooq.com> <28339030-6005-4C28-872C-A68CF24BF4DF@cs.purdue.edu> <20100422154357.GA20043@topoi.pooq.com> <270A99B5-173E-413B-8C28-E1CA68870FD4@cs.purdue.edu> <20100423094903.GC21281@topoi.pooq.com> <20100423185214.BA2EF1A20E1@async.async.caltech.edu> <20100423165613.GA22126@topoi.pooq.com> <20100424103435.A1CC41A20C2@async.async.caltech.edu> <4BD713C7.2060607@lcwb.coop> <20100427172400.D491F1A2096@async.async.caltech.edu> <20100427173036.7DC501A2096@async.async.caltech.edu> <4BD9AEA4.9080505@lcwb.coop> <20100429220719.6DD991A20A4@async.async.caltech.edu> Message-ID: <4BDA24B4.3090100@lcwb.coop> Mika Nystrom wrote: > "Rodney M. Bates" writes: >> Oh, I get it! You are proposing a _mixed_ approach, where the values >> the programmer can designate are of fixed (though possibly nonstatic) >> size (like open arrays) but the intermediate results are of unbounded >> size that re-adapts to hold the actual value each time an operator is >> evaluated, (like BigInteger). And because only intermediate results >> work this way, they can be stack allocated, because intermediate >> results have LIFO lifetimes. >> >> These are quite different approaches to arithmetic. It does seem >> at least a bit strange to mix them in this way. > > Speeeaking of stack allocation's being possible owing to LIFO lifetimes..... > > The Green Book says the following: > > "[Lisp, ML, Smalltalk, and CLU's] general disposition towards heap allocation > rather than stack allocation remains" > > May I draw the conclusion that exposing the difference between stack and > heap allocation in the language is fair game for the Modula-3 definition? I think the distinction is already exposed. If it's created by NEW, it's heap allocated. If it's a declared variable by VAR, it's stack allocated. > > What I'm getting at is this. If my LONGINT proposal is workable, the > following ought to be workable too: > > VAR a : NEW(ARRAY OF T, n); I seem to recall an argument the original designers made to the effect they felt declared variables of non-constant size were not worth the complication over just heap allocating them. I don't remember where, or the details. But yes, it could be made to work, I think. > > (Note: no REF, also no =.) It's an object upon which it is legal to > perform exactly those things that are legal to do to b^, where previously > > b := NEW(REF ARRAY OF T, n) > > I don't have a good name for the type of a ("evanescent array"?), but > I think being able to do this would make it possible to write efficient > code in ways that today only C++ (to my knowledge) allows. I think the > Modula-3 rules on what can (more importantly can't) be done with open > arrays may be enough to restrict the feature so it doesn't lead to new > complications (in the language definition---the implementation I'm not > sure about). To be precise, the severe limitations on open arrays apply only to how you can use an open array _type_. A _variable_ (or formal, field, element of open array, WITH-temp, etc.) of open array type can be used just about any way one of fixed array type can be. The lowest levels of the implementation would use alloca > with a fallback to heap allocation if for some reason variable-sized > stack objects are not allowed. > > LONGINT is then a rather natural specialization of the same rules. > (Cf. ARRAY OF BITS 1 FOR BOOLEAN vs. SET OF.) > > Mika > > From mika at async.async.caltech.edu Fri Apr 30 03:39:22 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Thu, 29 Apr 2010 18:39:22 -0700 Subject: [M3devel] INTEGER In-Reply-To: <4BDA24B4.3090100@lcwb.coop> References: <20100421185631.GA17051@topoi.pooq.com> <80775CA2-A2FD-40AF-B235-7DB84127762E@cs.purdue.edu> <20100422123805.GA19259@topoi.pooq.com> <87B45DCC-2B8A-4C69-97D7-240BC1E2252D@cs.purdue.edu> <20100422145522.GA19946@topoi.pooq.com> <28339030-6005-4C28-872C-A68CF24BF4DF@cs.purdue.edu> <20100422154357.GA20043@topoi.pooq.com> <270A99B5-173E-413B-8C28-E1CA68870FD4@cs.purdue.edu> <20100423094903.GC21281@topoi.pooq.com> <20100423185214.BA2EF1A20E1@async.async.caltech.edu> <20100423165613.GA22126@topoi.pooq.com> <20100424103435.A1CC41A20C2@async.async.caltech.edu> <4BD713C7.2060607@lcwb.coop> <20100427172400.D491F1A2096@async.async.caltech.edu> <20100427173036.7DC501A2096@async.async.caltech.edu> <4BD9AEA4.9080505@lcwb.coop> <20100429220719.6DD991A20A4@async.async.caltech.edu> <4BDA24B4.3090100@lcwb.coop> Message-ID: <20100430013922.5DCB21A20A9@async.async.caltech.edu> "Rodney M. Bates" writes: > > >I seem to recall an argument the original designers made to the effect >they felt declared variables of non-constant size were not worth the >complication over just heap allocating them. I don't remember where, >or the details. But yes, it could be made to work, I think. Yes, of course, that is why they didn't do it. I'm not sure it's even particularly difficult. > >> >> (Note: no REF, also no =.) It's an object upon which it is legal to >> perform exactly those things that are legal to do to b^, where previously >> >> b := NEW(REF ARRAY OF T, n) >> >> I don't have a good name for the type of a ("evanescent array"?), but >> I think being able to do this would make it possible to write efficient >> code in ways that today only C++ (to my knowledge) allows. I think the >> Modula-3 rules on what can (more importantly can't) be done with open >> arrays may be enough to restrict the feature so it doesn't lead to new >> complications (in the language definition---the implementation I'm not >> sure about). > >To be precise, the severe limitations on open arrays apply only to how >you can use an open array _type_. A _variable_ (or formal, field, element >of open array, WITH-temp, etc.) of open array type can be used just >about any way one of fixed array type can be. Right, and I think it's enough. What we care about here is that we can't return the variable-sized array nor assign it to anything. I think it falls out rather naturally. E.g., to take an already fairly nasty example: PROCEDURE F() : ARRAY [0..1] OF T = VAR x : NEW(ARRAY OF T, 2); BEGIN RETURN x END F; here there is an implicit type check on return. This is probably already implemented by the compiler as: PROCEDURE F(VAR retval : ARRAY [0..1] OF T) = VAR x : NEW(ARRAY OF T, 2); BEGIN retval := x; (* implicit shape check *) RETURN END F; Another fairly nasty example: PROCEDURE G(x : ARRAY OF T) = ... VAR x : NEW(ARRAY OF T, 2); BEGIN G(x) END This is no different from writing VAR x : ARRAY [0..1] OF T; BEGIN G(x) END and I don't see how introducing the variable size makes it really any more difficult. If the compiler writer doesn't know how to do it in one particular case he can also just punt the problem to heap allocation. Maybe there is something I'm missing but it has always bugged me that most of the time I have to heap-allocate array temporaries. Mika From wagner at elegosoft.com Thu Apr 1 10:33:13 2010 From: wagner at elegosoft.com (wagner at elegosoft.com) Date: Thu, 01 Apr 2010 10:33:13 +0200 Subject: [M3devel] m3back directions? In-Reply-To: References: <20100331121830.22q33okrokkwsgwk@mail.elegosoft.com> Message-ID: <20100401103313.j86zit1w0kc0wkoc@mail.elegosoft.com> Quoting Tony Hosking : > On 31 Mar 2010, at 06:18, wagner at elegosoft.com wrote: > >> Quoting Jay K : >> >>> I'm curious what, if anything, people are interested in in m3back? >>> >>> There are several mostly independent directions: >>> >>> - remove it; use the gcc backend or other (burg, llvm, generate C) >>> >>> - expand to support other targets, AMD64_*, including AMD64_NT >>> >>> m3objfile would need macho/elf support for non-NT >> >> It would be great if we could use the integrated backend for other >> targets, too. Adding ELF support will be a lot of work, but it's probably >> worth it. > > Have you looked at the pm3 Linux support? Indeed I had forgotten about that. I'll take at look at the Easter holidays, Olaf From jay.krell at cornell.edu Thu Apr 1 14:33:52 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 1 Apr 2010 12:33:52 +0000 Subject: [M3devel] m3back directions? In-Reply-To: <20100401103313.j86zit1w0kc0wkoc@mail.elegosoft.com> References: , <20100331121830.22q33okrokkwsgwk@mail.elegosoft.com>, , <20100401103313.j86zit1w0kc0wkoc@mail.elegosoft.com> Message-ID: I think it was GPL though. - Jay > Date: Thu, 1 Apr 2010 10:33:13 +0200 > From: wagner at elegosoft.com > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] m3back directions? > > Quoting Tony Hosking : > > > On 31 Mar 2010, at 06:18, wagner at elegosoft.com wrote: > > > >> Quoting Jay K : > >> > >>> I'm curious what, if anything, people are interested in in m3back? > >>> > >>> There are several mostly independent directions: > >>> > >>> - remove it; use the gcc backend or other (burg, llvm, generate C) > >>> > >>> - expand to support other targets, AMD64_*, including AMD64_NT > >>> > >>> m3objfile would need macho/elf support for non-NT > >> > >> It would be great if we could use the integrated backend for other > >> targets, too. Adding ELF support will be a lot of work, but it's probably > >> worth it. > > > > Have you looked at the pm3 Linux support? > > Indeed I had forgotten about that. I'll take at look at the Easter > holidays, > > Olaf > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Thu Apr 1 16:28:53 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 01 Apr 2010 09:28:53 -0500 Subject: [M3devel] changing m3middle/m3back to have multiple passes? In-Reply-To: References: Message-ID: <4BB4ADA5.70003@lcwb.coop> Jay K wrote: > I'm thinking m3back could use multiple passes. This would be a big reversal of the fundamental design philosophy of this back end. Its primary design criterion was to be simple and fast. That means single-pass. There have been several compilers (often whole compilers, not just code generators) written to this principle. For some purposes, it is a good thing. This, of course, inevitably means the generated code is not as small/fast as it could be. It's part of the trade off. We have two points on this trade off scale now. I think we want to keep the one-pass code generator. If you change it, at least make a branch and keep the original design easily accessible. > > > There a few reasons, things that would be easier/possible if it had them. > > > I know adding passes will slow it down, but I suspect it will still be > about as pleasantly fast as it is now. > > > The optimizations I have in mind: > inlining, including where function definitions come after the call > I think inlining where the "small" functions come first is doable in > pass, > but not if uses come before calls. > > > not saving unused registers > This only a small optimization and could probably be done in one > pass if m3objfile got a "memmove" operation. Well, I already > have the optimization in somewhat, but it involves nop-ing out > code instead of removing it completely. > > > dead store removal, and then removing the resulting dead code to > compute the value > > > possibly better register allocation -- e.g. based on noticing which > variables are used often, or based on how they are used, for example > if a variable (or expression/temporary) ends serving a shift count, > we should favor putting it in ecx up front, instead of moving it to > ecx later, but we don't generally know this till too late > > > As I understand, m3middle already has the notion of "recording" > and "playing back" calls to the M3CG interface. > That seems like a good starting point? > > > Some optimizations can be made via "CG to CG" transforms. > > > However I think in general I think the required design would include: > - ability to add in "private operations"; maybe > - ability to add "private data" to existing operations > A very simple one is annotate functions with required frame size. > This isn't currently known until the end of the function. > - clearly, ability to remove operations > > > Can/should we somehow augment m3middle in support of this line of thinking? > > > Or is that just not the way to go? > Each backend should have its own internal representation and loop over it? > > - Jay > From jay.krell at cornell.edu Thu Apr 1 17:10:04 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 1 Apr 2010 15:10:04 +0000 Subject: [M3devel] changing m3middle/m3back to have multiple passes? In-Reply-To: <4BB4ADA5.70003@lcwb.coop> References: , <4BB4ADA5.70003@lcwb.coop> Message-ID: Simple and fast does not entirely preclude multiple passes, and one pass does not equate to simple, though yes probably fast. The front end already makes multiple passes I believe, and is still fast. Sometimes decomposition into more smaller pieces (passes, layers, etc.) make things simpler. Albeit slower. A more historical factor here is that multiple passes imply keeping more data in memory longer. Implies slower. However memory capacity has increased tremendously. Whereas I'm only thinking about multiple passes, while still compiling one file at a time, other compilation systems have capitalized on larger memories and now compile entire programs at once, including multiple passes. This goes by multiple names -- "whole program optimization", "link time codegen (LTCG)". And enables even more aggressive but still "fairly simple" optimization, such as cross module inlining, custom calling conventions. I say "fairly simple", because these are just the same optimizations one would perform within a module, merely applied across module boundaries. (Sometimes what people do is #include all .c files into one master .c file, to help get the compiler to see everything at once. sqllite does this, for example.) Surely we can afford multiple passes on a per-file basis. ? The code is already not that easy to understand imho. It took me quite some time to get comfortable and add the 64 bit integer support, years. And there's a few things I still don't understand (you can tell from my comments in the code, like where do I need to call "newdest")? Embrace it and make it incrementally harder to understand (by virtue of simply adding to it), or decide it is stuck asis? I'm not entirely sure. While it is an interesting compromise in its current form, I'm fairly certain there are other viable compromises that achieve better code quality, are still plenty fast, and aren't much more difficult to understand. Heck, I found it confusing at first that the -debug output is wrong in some places. That is a fallout from it being single pass "plus patching". The debug output doesn't include the "patches". I have some very simple small optimizations in mind. And then, in stepping through code, and writing code, inlining constantly comes to mind. In fact, I frequently see "manual partial inlining" in the Modula-3 code. It'd be nifty if the Modula-3 code could have less duplication, relying on the compiler more. I don't see inlining as entirely simple, but I've given it a little thought and it might not be so hard. I think it can be done, roughly, by taking the body of a procedure as expressed as cg.i3 calls, omitting the begin/procedure, and just "playing them back" at the call site. You'd only do this for "small" functions. You'd have to make some adjustments like merging local variables and exception handling, though really the inlined function would just be a "block". Probably the way to go here, if inlining is really to be considered, is first implement it as "one pass plus some memory", and only inline when the definition comes before the call. Once that is achieved, no small feat, further considering can be made to allow for inlining when the call precedes the definition. eh, sorry, I'm tried, rambling. - Jay > Date: Thu, 1 Apr 2010 09:28:53 -0500 > From: rodney_bates at lcwb.coop > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] changing m3middle/m3back to have multiple passes? > > > > Jay K wrote: > > I'm thinking m3back could use multiple passes. > > This would be a big reversal of the fundamental design philosophy of this > back end. Its primary design criterion was to be simple and fast. That > means single-pass. There have been several compilers (often whole compilers, > not just code generators) written to this principle. For some purposes, > it is a good thing. > > This, of course, inevitably means the generated code is not as small/fast > as it could be. It's part of the trade off. We have two points on this > trade off scale now. I think we want to keep the one-pass code generator. > If you change it, at least make a branch and keep the original design > easily accessible. > > > > > > > > There a few reasons, things that would be easier/possible if it had them. > > > > > > I know adding passes will slow it down, but I suspect it will still be > > about as pleasantly fast as it is now. > > > > > > The optimizations I have in mind: > > inlining, including where function definitions come after the call > > I think inlining where the "small" functions come first is doable in > > pass, > > but not if uses come before calls. > > > > > > not saving unused registers > > This only a small optimization and could probably be done in one > > pass if m3objfile got a "memmove" operation. Well, I already > > have the optimization in somewhat, but it involves nop-ing out > > code instead of removing it completely. > > > > > > dead store removal, and then removing the resulting dead code to > > compute the value > > > > > > possibly better register allocation -- e.g. based on noticing which > > variables are used often, or based on how they are used, for example > > if a variable (or expression/temporary) ends serving a shift count, > > we should favor putting it in ecx up front, instead of moving it to > > ecx later, but we don't generally know this till too late > > > > > > As I understand, m3middle already has the notion of "recording" > > and "playing back" calls to the M3CG interface. > > That seems like a good starting point? > > > > > > Some optimizations can be made via "CG to CG" transforms. > > > > > > However I think in general I think the required design would include: > > - ability to add in "private operations"; maybe > > - ability to add "private data" to existing operations > > A very simple one is annotate functions with required frame size. > > This isn't currently known until the end of the function. > > - clearly, ability to remove operations > > > > > > Can/should we somehow augment m3middle in support of this line of thinking? > > > > > > Or is that just not the way to go? > > Each backend should have its own internal representation and loop over it? > > > > - Jay > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Apr 1 17:59:58 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 1 Apr 2010 11:59:58 -0400 Subject: [M3devel] m3back directions? In-Reply-To: References: , <20100331121830.22q33okrokkwsgwk@mail.elegosoft.com>, , <20100401103313.j86zit1w0kc0wkoc@mail.elegosoft.com> Message-ID: All of PM3 is licensed the same way as CM3 (they both derive from the same DEC SRC sources). On 1 Apr 2010, at 08:33, Jay K wrote: > I think it was GPL though. > > - Jay > > > Date: Thu, 1 Apr 2010 10:33:13 +0200 > > From: wagner at elegosoft.com > > To: hosking at cs.purdue.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] m3back directions? > > > > Quoting Tony Hosking : > > > > > On 31 Mar 2010, at 06:18, wagner at elegosoft.com wrote: > > > > > >> Quoting Jay K : > > >> > > >>> I'm curious what, if anything, people are interested in in m3back? > > >>> > > >>> There are several mostly independent directions: > > >>> > > >>> - remove it; use the gcc backend or other (burg, llvm, generate C) > > >>> > > >>> - expand to support other targets, AMD64_*, including AMD64_NT > > >>> > > >>> m3objfile would need macho/elf support for non-NT > > >> > > >> It would be great if we could use the integrated backend for other > > >> targets, too. Adding ELF support will be a lot of work, but it's probably > > >> worth it. > > > > > > Have you looked at the pm3 Linux support? > > > > Indeed I had forgotten about that. I'll take at look at the Easter > > holidays, > > > > Olaf > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Apr 1 18:08:52 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 1 Apr 2010 12:08:52 -0400 Subject: [M3devel] changing m3middle/m3back to have multiple passes? In-Reply-To: <4BB4ADA5.70003@lcwb.coop> References: <4BB4ADA5.70003@lcwb.coop> Message-ID: <452F7418-679D-49D3-BC44-EA07B157AEF5@cs.purdue.edu> Indeed. I think we would be better served exploring alternatives like LLVM where we can rely on others to implement the grungy compiler optimisations and we can sail above the fray worrying about the language proper On 1 Apr 2010, at 10:28, Rodney M. Bates wrote: > > > Jay K wrote: >> I'm thinking m3back could use multiple passes. > > This would be a big reversal of the fundamental design philosophy of this > back end. Its primary design criterion was to be simple and fast. That > means single-pass. There have been several compilers (often whole compilers, > not just code generators) written to this principle. For some purposes, > it is a good thing. > > This, of course, inevitably means the generated code is not as small/fast > as it could be. It's part of the trade off. We have two points on this > trade off scale now. I think we want to keep the one-pass code generator. > If you change it, at least make a branch and keep the original design > easily accessible. > > >> There a few reasons, things that would be easier/possible if it had them. >> I know adding passes will slow it down, but I suspect it will still be >> about as pleasantly fast as it is now. >> The optimizations I have in mind: >> inlining, including where function definitions come after the call >> I think inlining where the "small" functions come first is doable in pass, >> but not if uses come before calls. >> not saving unused registers >> This only a small optimization and could probably be done in one >> pass if m3objfile got a "memmove" operation. Well, I already >> have the optimization in somewhat, but it involves nop-ing out >> code instead of removing it completely. >> dead store removal, and then removing the resulting dead code to compute the value >> possibly better register allocation -- e.g. based on noticing which >> variables are used often, or based on how they are used, for example >> if a variable (or expression/temporary) ends serving a shift count, >> we should favor putting it in ecx up front, instead of moving it to >> ecx later, but we don't generally know this till too late >> As I understand, m3middle already has the notion of "recording" >> and "playing back" calls to the M3CG interface. >> That seems like a good starting point? >> Some optimizations can be made via "CG to CG" transforms. >> However I think in general I think the required design would include: >> - ability to add in "private operations"; maybe >> - ability to add "private data" to existing operations >> A very simple one is annotate functions with required frame size. >> This isn't currently known until the end of the function. >> - clearly, ability to remove operations >> Can/should we somehow augment m3middle in support of this line of thinking? >> Or is that just not the way to go? >> Each backend should have its own internal representation and loop over it? >> - Jay From hendrik at topoi.pooq.com Sun Apr 4 03:20:57 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sat, 3 Apr 2010 21:20:57 -0400 Subject: [M3devel] changing m3middle/m3back to have multiple passes? In-Reply-To: References: <4BB4ADA5.70003@lcwb.coop> Message-ID: <20100404012057.GA20078@topoi.pooq.com> On Thu, Apr 01, 2010 at 03:10:04PM +0000, Jay K wrote: > > However memory capacity has increased tremendously. > > > > > > Whereas I'm only thinking about multiple passes, while still compiling > one file at a time, > > other compilation systems have capitalized on larger memories and now > compile entire programs at once, including multiple passes. > > This goes by multiple names -- "whole program optimization", "link > time codegen (LTCG)". Link-time code generation was already involved in Mark Rain's Mary 2 compiler in the early 80's. It didn't actually require today's huge memories. Every now and then the Modula 3 compiler seems to decide to recompile something because new source had been discovered, or soething like that. I suspect this is because a new .m3 file changes the memory layout that was assumed in aanother source file, so that other one needs to be reconsidered. Is the complexity of tracking that simpler or more complex than doing whole-program compilation? It's possible that file-by-file compilation is a simpler match for interacting with foreign-language compilations, theough. It two languages insist on only compiling whole programs, it makes mixed-language programming difficult. -- hendrik From jay.krell at cornell.edu Sat Apr 3 03:34:22 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 3 Apr 2010 01:34:22 +0000 Subject: [M3devel] changing m3middle/m3back to have multiple passes? In-Reply-To: <20100404012057.GA20078@topoi.pooq.com> References: <4BB4ADA5.70003@lcwb.coop>, , <20100404012057.GA20078@topoi.pooq.com> Message-ID: Good points. I forgot to clarify that to some extent I just want to make multiple passes over functions, not files. => even less memory and slow down In particular, I want to know if a frame size is < 256, or < 4K or >= 4K. The >= 4K case isn't handled correctly today I believe, though will generally work. < 256 affords one byte of savings. I'd also like to know what registers are used, for 1, 2, or 3 bytes saved. While these are small, they are very broadly applicable. Consider that even the smallest of functions: PROCEDURE F(): INTEGER = BEGIN RETURN 1 END F; compiles/compiled to something like: push ebp mov ebp, esp sub esp, 0 ; yes, we are willing to put zero here, and it takes 2 bytes push esi ; I nop this out now. push edi ; I nop this out now. push ebx ; I nop this out now. mov eax, 1 pop ebx ; I optimize this out now. pop edi ; I optimize this out now. pop esi ; I optimize this out now. leave 0 ; I think ret when, if you punt the point of frame point omission, it could be: push ebp mov ebp, esp mov eax, 1 leave 0 ; I think. ret or if you allow for frame pointer omission: mov eax, 1 ret (Let's assume the address is taken, therefore it can't always easily be inlined.) "imagine if all code was multiplied out like this" Omitting the frame pointer hurts stack walk and debugging, however I think there is a midddle ground that people don't discuss: if a function takes no parameters and has no locals, then omit the frame pointer Possibly also if it has no locals and/or makes no function calls. Like, if it never uses esp or ebp. Actually this is encoded in PowerPC and AMD64 calling conventions, leaf functions can optimize their prologue/epilogue. But it doesn't seem come up with regarding x86. There again, multiple passes help. Multiple passes over a function would also offer things like eliminating dead stores, and cascading elimination of dead code, e.g: a := b + 1; (* eliminate this whole line *) a := b + 2; Granted, I am interested in multiple passes over a file too, for inlining. What I'm really going to do though is try to provide ObjFile.Move so that at the end of the function, I can "move" the entire function up or down a few bytes, or maybe only up. You can imagine "down" to fix the >= 4K case, but you might as well model that as reserving room for the worst case in first pass, and then move down usually. I think it just requires that I understand relocs much better, which is a good goal anyway for working with the code. You know -- perform a not well motivated change to some code, for purposes of exercise -- understanding the code and how to change it, so that when a better motivated change comes along, we aren't stuck. Also, I only recently realized/learned the high value of "sequential access" as it relates to "working set". Let's say you really have more data than memory? In a compiler we don't, but some applications do (plain text indexing of large data). Then what you do is: To whatever extent you can, break the data down into smaller pieces. At some level, random access is unavoidable, say, to sort small data. When you can't break the data down: Access it linearly, not randomly: mergesort instead of quicksort. Minimize the number of passes, but there is tradeoff between number of passes and working set size. Linear access keeps working set "constant", even if you are slowed down by having to reread data from disk. Yes I do see that message from the front end. I haven't looked into what it means, but yeah presumably something like a pessimistic first pass, followed by discovery of layout information, followed by more optimistic second pass. You might imagine, for example, knowing the sizes of opaque or object types. The front end makes multiple passes. I suspect for significant simplicity or "possibility" -- it might be darn difficult to implement in fewer passes, without contorting the code a lot. If you look how how "patching" and "labels" work in the backend, that's probably an example of where multiple passes would be more general and simpler, but where the "contortions" are well known and not too bad. It uses "patching" to fill in the frame size for example, and I now use that to nop out unnecessary prolog instructions (on the theory that nop it is a small optimization). Though, again, patching isn't sufficient for >4K frames. Very long standing bug there, I have to confirm and fix soon. Good points about whole program optimization. I think there are ways to address this. Not any time soon. Doing optimization and codegen at "link time" I think is somewhat of a hack in these systems. One we can't easily play into, as you point out. However, where we use the gcc backend and linker, we probably can, easily. That is many platforms. gcc does have this option. Also we could optimize "among" all the *.m3 files, just lose out on any M3<=>C optimizations. In reality, let me first think about NTObjFile.Move as a way to do some small optimizations, NTObjFile CodeView generation, maybe inlining, maybe LLVM. Testing/optimizing the atomics (add,sub,xor can improve, also store and probably load). Everything else is too much for the time being. Maybe we can do some target independent optimizations in m3front or m3front/cg or m3middle as well. Inlining could be done there, but the metrics of when to do it aren't really available. Only for *extremely* cheap seeming functions could the front end make a reliable target-independent choice. Oh wait -- that is interesting. If you consider just the case of inlining functions whose definitions precede use, the backend could "measure" a function, after generating it, and report back to the frontend if it should strongly consider inlining it. Then upon subsequent calls, the frontend could do the inlining. Such measurement is always going to be heuristic, but you can imagine stuff like number of cg calls number of parameters does it return a value As well, if had a <* FORCEINLINE *> pragma, the frontend could implement that. I'm pretty sure. Not clear if better to leave the decision to the compiler or not. After all, C and C++ have "inline" and "__inline" that are just hints that modern compilers ignore, and Visual C++ has "__forceinline", which generates a warning when not honored. Seems to be a bit of an arms race in terms of who things he knows better, programmer or compiler. Used to always be the programmer, then shifted to compiler, now not clear. - Jay > Date: Sat, 3 Apr 2010 21:20:57 -0400 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] changing m3middle/m3back to have multiple passes? > > On Thu, Apr 01, 2010 at 03:10:04PM +0000, Jay K wrote: > > > > However memory capacity has increased tremendously. > > > > > > > > > > > > Whereas I'm only thinking about multiple passes, while still compiling > > one file at a time, > > > > other compilation systems have capitalized on larger memories and now > > compile entire programs at once, including multiple passes. > > > > This goes by multiple names -- "whole program optimization", "link > > time codegen (LTCG)". > > Link-time code generation was already involved in Mark Rain's Mary 2 > compiler in the early 80's. It didn't actually require today's huge > memories. > > Every now and then the Modula 3 compiler seems to decide to recompile > something because new source had been discovered, or soething like that. > I suspect this is because a new .m3 file changes the memory layout that > was assumed in aanother source file, so that other one needs to be > reconsidered. Is the complexity of tracking that simpler or more > complex than doing whole-program compilation? > > It's possible that file-by-file compilation is a simpler match for > interacting with foreign-language compilations, theough. It two > languages insist on only compiling whole programs, it makes > mixed-language programming difficult. > > -- hendrik -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Apr 3 13:02:56 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 3 Apr 2010 11:02:56 +0000 Subject: [M3devel] m3back directions? In-Reply-To: References: , , <20100331121830.22q33okrokkwsgwk@mail.elegosoft.com>, , , , <20100401103313.j86zit1w0kc0wkoc@mail.elegosoft.com>, , Message-ID: No, really. GPL. http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/pm3/m3/pm3/language/modula3/m3compiler/m3back/src/linux/Codex86.m3?rev=1.3;content-type=text%2Fplain http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/pm3/m3/pm3/language/modula3/m3compiler/m3objfile/src/linux/ELFObjFile.m3?rev=1.2;content-type=text%2Fplain - Jay From: hosking at cs.purdue.edu Date: Thu, 1 Apr 2010 11:59:58 -0400 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] m3back directions? All of PM3 is licensed the same way as CM3 (they both derive from the same DEC SRC sources). On 1 Apr 2010, at 08:33, Jay K wrote: I think it was GPL though. - Jay > Date: Thu, 1 Apr 2010 10:33:13 +0200 > From: wagner at elegosoft.com > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] m3back directions? > > Quoting Tony Hosking : > > > On 31 Mar 2010, at 06:18, wagner at elegosoft.com wrote: > > > >> Quoting Jay K : > >> > >>> I'm curious what, if anything, people are interested in in m3back? > >>> > >>> There are several mostly independent directions: > >>> > >>> - remove it; use the gcc backend or other (burg, llvm, generate C) > >>> > >>> - expand to support other targets, AMD64_*, including AMD64_NT > >>> > >>> m3objfile would need macho/elf support for non-NT > >> > >> It would be great if we could use the integrated backend for other > >> targets, too. Adding ELF support will be a lot of work, but it's probably > >> worth it. > > > > Have you looked at the pm3 Linux support? > > Indeed I had forgotten about that. I'll take at look at the Easter > holidays, > > Olaf > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Apr 3 19:24:16 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 3 Apr 2010 13:24:16 -0400 Subject: [M3devel] m3back directions? In-Reply-To: References: , , <20100331121830.22q33okrokkwsgwk@mail.elegosoft.com>, , , , <20100401103313.j86zit1w0kc0wkoc@mail.elegosoft.com>, , Message-ID: <4C7DFD56-676D-4E33-983F-29FA41357053@cs.purdue.edu> Interesting. We can still use it (like gcc) right? Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 3 Apr 2010, at 07:02, Jay K wrote: > No, really. GPL. > > http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/pm3/m3/pm3/language/modula3/m3compiler/m3back/src/linux/Codex86.m3?rev=1.3;content-type=text%2Fplain > > http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/pm3/m3/pm3/language/modula3/m3compiler/m3objfile/src/linux/ELFObjFile.m3?rev=1.2;content-type=text%2Fplain > > - Jay > > > From: hosking at cs.purdue.edu > Date: Thu, 1 Apr 2010 11:59:58 -0400 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] m3back directions? > > All of PM3 is licensed the same way as CM3 (they both derive from the same DEC SRC sources). > > > On 1 Apr 2010, at 08:33, Jay K wrote: > > I think it was GPL though. > > - Jay > > > Date: Thu, 1 Apr 2010 10:33:13 +0200 > > From: wagner at elegosoft.com > > To: hosking at cs.purdue.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] m3back directions? > > > > Quoting Tony Hosking : > > > > > On 31 Mar 2010, at 06:18, wagner at elegosoft.com wrote: > > > > > >> Quoting Jay K : > > >> > > >>> I'm curious what, if anything, people are interested in in m3back? > > >>> > > >>> There are several mostly independent directions: > > >>> > > >>> - remove it; use the gcc backend or other (burg, llvm, generate C) > > >>> > > >>> - expand to support other targets, AMD64_*, including AMD64_NT > > >>> > > >>> m3objfile would need macho/elf support for non-NT > > >> > > >> It would be great if we could use the integrated backend for other > > >> targets, too. Adding ELF support will be a lot of work, but it's probably > > >> worth it. > > > > > > Have you looked at the pm3 Linux support? > > > > Indeed I had forgotten about that. I'll take at look at the Easter > > holidays, > > > > Olaf > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Sun Apr 4 01:41:31 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sat, 03 Apr 2010 18:41:31 -0500 Subject: [M3devel] m3back directions? In-Reply-To: References: , , <20100331121830.22q33okrokkwsgwk@mail.elegosoft.com>, , , , <20100401103313.j86zit1w0kc0wkoc@mail.elegosoft.com>, , Message-ID: <4BB7D22B.5000107@lcwb.coop> Wasn't it written an Montreal Poly as a student project or something? Jay K wrote: > No, really. GPL. > > http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/pm3/m3/pm3/language/modula3/m3compiler/m3back/src/linux/Codex86.m3?rev=1.3;content-type=text%2Fplain > > http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/pm3/m3/pm3/language/modula3/m3compiler/m3objfile/src/linux/ELFObjFile.m3?rev=1.2;content-type=text%2Fplain > > - Jay > > > ------------------------------------------------------------------------ > From: hosking at cs.purdue.edu > Date: Thu, 1 Apr 2010 11:59:58 -0400 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] m3back directions? > > All of PM3 is licensed the same way as CM3 (they both derive from the > same DEC SRC sources). > > > On 1 Apr 2010, at 08:33, Jay K wrote: > > I think it was GPL though. > > - Jay > > > Date: Thu, 1 Apr 2010 10:33:13 +0200 > > From: wagner at elegosoft.com > > To: hosking at cs.purdue.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] m3back directions? > > > > Quoting Tony Hosking >: > > > > > On 31 Mar 2010, at 06:18, wagner at elegosoft.com > wrote: > > > > > >> Quoting Jay K >: > > >> > > >>> I'm curious what, if anything, people are interested in in m3back? > > >>> > > >>> There are several mostly independent directions: > > >>> > > >>> - remove it; use the gcc backend or other (burg, llvm, generate C) > > >>> > > >>> - expand to support other targets, AMD64_*, including AMD64_NT > > >>> > > >>> m3objfile would need macho/elf support for non-NT > > >> > > >> It would be great if we could use the integrated backend for other > > >> targets, too. Adding ELF support will be a lot of work, but > it's probably > > >> worth it. > > > > > > Have you looked at the pm3 Linux support? > > > > Indeed I had forgotten about that. I'll take at look at the Easter > > holidays, > > > > Olaf > > > > > > From jay.krell at cornell.edu Sun Apr 4 02:35:32 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 4 Apr 2010 00:35:32 +0000 Subject: [M3devel] m3back directions? In-Reply-To: <4BB7D22B.5000107@lcwb.coop> References: , ,,<20100331121830.22q33okrokkwsgwk@mail.elegosoft.com>, ,,, , , <20100401103313.j86zit1w0kc0wkoc@mail.elegosoft.com>, , , , , , <4BB7D22B.5000107@lcwb.coop> Message-ID: Do you mean to ask, am I embarassed that I nor any of us have done it ourselves by now? Yes. :) (Though I don't know about the question as stated.) Interest level here is higher than I expected in non-gcc backends. And Tony gave the answer I expected. :) I don't know. It's kind of cheating, less fun, very hard to ramp up on, but once there very useful and good reuse and code quality. So I'll consider this higher priority, if nobody beats me to it. I also noticed the two burg backends in the 3.6 tree. Did they build and work? Eh, rhetorical mostly. It's hard to get one's head around this stuff. Easier to improve m3back. Though they had a MIPS backend too and I do have some MIPS machines.. (SGIs and router). I'd like to first: current release CodeView debugging test/optimize atomics (anyone can test this, please do) test/fix 64bit range checks (anyone can test this, please do) the micro optimizations I've been repeatedly describing (not multi pass, just "objfile.move") And then once I have "move", fix the >4K frame bug. And then I'll try to consider other x86 backends again. - Jay > Date: Sat, 3 Apr 2010 18:41:31 -0500 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: Re: [M3devel] m3back directions? > > Wasn't it written an Montreal Poly as a student project or something? > > Jay K wrote: > > No, really. GPL. > > > > http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/pm3/m3/pm3/language/modula3/m3compiler/m3back/src/linux/Codex86.m3?rev=1.3;content-type=text%2Fplain > > > > http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/pm3/m3/pm3/language/modula3/m3compiler/m3objfile/src/linux/ELFObjFile.m3?rev=1.2;content-type=text%2Fplain > > > > - Jay > > > > > > ------------------------------------------------------------------------ > > From: hosking at cs.purdue.edu > > Date: Thu, 1 Apr 2010 11:59:58 -0400 > > To: jay.krell at cornell.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] m3back directions? > > > > All of PM3 is licensed the same way as CM3 (they both derive from the > > same DEC SRC sources). > > > > > > On 1 Apr 2010, at 08:33, Jay K wrote: > > > > I think it was GPL though. > > > > - Jay > > > > > Date: Thu, 1 Apr 2010 10:33:13 +0200 > > > From: wagner at elegosoft.com > > > To: hosking at cs.purdue.edu > > > CC: m3devel at elegosoft.com > > > Subject: Re: [M3devel] m3back directions? > > > > > > Quoting Tony Hosking > >: > > > > > > > On 31 Mar 2010, at 06:18, wagner at elegosoft.com > > wrote: > > > > > > > >> Quoting Jay K > >: > > > >> > > > >>> I'm curious what, if anything, people are interested in in m3back? > > > >>> > > > >>> There are several mostly independent directions: > > > >>> > > > >>> - remove it; use the gcc backend or other (burg, llvm, generate C) > > > >>> > > > >>> - expand to support other targets, AMD64_*, including AMD64_NT > > > >>> > > > >>> m3objfile would need macho/elf support for non-NT > > > >> > > > >> It would be great if we could use the integrated backend for other > > > >> targets, too. Adding ELF support will be a lot of work, but > > it's probably > > > >> worth it. > > > > > > > > Have you looked at the pm3 Linux support? > > > > > > Indeed I had forgotten about that. I'll take at look at the Easter > > > holidays, > > > > > > Olaf > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Apr 4 10:29:31 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 4 Apr 2010 08:29:31 +0000 Subject: [M3devel] interesting comment in caltech-parser m3overrides Message-ID: /* when overriding, ld.so doesn't know where to find libraries */ /* this is even more true if we want to move the binaries or */ /* clean.. */ %if defined("pm3_version") % /* Polytechnique de Montreal Modula-3 */ % option("shared_lib","") %else % /* SRC Modula-3 */ % m3_option ("-X2 at -static@") %end which is the same problem we discussed here a bunch. To which there is no good solution, just various compromises. For the next (not current) release though I think all .so and executables should build (not just ship) into a common place. So $ORIGIN works, without having to ship. They also have this interesting technique: /* these are the packages that are part of this distribution */ override("prsparse",TOP) ... % override other libraries if they exist locally (use not stale on each) m3core = ROOT & SL & "m3-libs" & SL & "m3core" if not stale(m3core, m3core) override("m3core", ROOT & SL & "m3-libs") end ... override should probably do the existance check if it doesn't already. Though the idea of building stuff to a common directory I believe obsoletes this entire override thing. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Apr 4 12:02:09 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 4 Apr 2010 10:02:09 +0000 Subject: [M3devel] initializing field with record size? Message-ID: TYPE struct_stat = RECORD type_size: LONGINT := VAL(BYTESIZE(struct_stat), LONGINT); st_dev : LONGINT; (* Utypes.dev_t *) ... END; new source -> compiling Ustat.i3 "..\src\unix\Common\Ustat.i3", line 57: illegal recursive declaration (struct_stat) "..\src\unix\Common\Ustat.i3", line 57: illegal recursive type declaration 2 errors encountered compilation failed => not building library "m3core.lib" Fatal Error: package build failed really can't be allowed? I know, I can compute it myself, or I can make it a default parameter to functions that traffic in the type. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Apr 4 12:25:08 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 4 Apr 2010 10:25:08 +0000 Subject: [M3devel] some new NT386 builds from release branch Message-ID: http://modula3.elegosoft.com/cm3/uploaded-archives/index.html Has some new NT386 builds out of the release branch. e.g. http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-all-x86-pre5.8.5-VC80.msi http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-all-x86-pre5.8.5-VC90.msi http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-x86-pre5.8.5-VC80.msi http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-x86-pre5.8.5-VC70.zip http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-x86-pre5.8.5-VC60.zip etc. It is all very automated. I can trivially update them if/when we fix more bugs. It is really no trouble to support the older versions of Visual C++. I can provide .msis or "all" for the older Visual C++ if anyone needs. There's a bug that strongly suggests we should provide separate per-toolset builds like this. (#1077 win32 install problem's jkrell sw-bug medium installation current) I've taken the liberty of assuming .msi and even .zip imply NT, thus the file names. Next step maybe is for the web page to suggest the right target download, like how http://www.mozilla.com does? (with a link to other systems, etc.) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Apr 4 15:01:35 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 4 Apr 2010 09:01:35 -0400 Subject: [M3devel] interesting comment in caltech-parser m3overrides In-Reply-To: References: Message-ID: override was used before the existence of shared libs in CM3/PM3 so not surprising. On 4 Apr 2010, at 04:29, Jay K wrote: > /* when overriding, ld.so doesn't know where to find libraries */ > /* this is even more true if we want to move the binaries or */ > /* clean.. */ > > %if defined("pm3_version") > % /* Polytechnique de Montreal Modula-3 */ > % option("shared_lib","") > %else > % /* SRC Modula-3 */ > % m3_option ("-X2 at -static@") > %end > > > which is the same problem we discussed here a bunch. > To which there is no good solution, just various compromises. > For the next (not current) release though I think all .so and executables should build (not just ship) into a common place. > So $ORIGIN works, without having to ship. > > > They also have this interesting technique: > > /* these are the packages that are part of this distribution */ > override("prsparse",TOP) > ... > > > % override other libraries if they exist locally (use not stale on each) > > m3core = ROOT & SL & "m3-libs" & SL & "m3core" > if not stale(m3core, m3core) > override("m3core", ROOT & SL & "m3-libs") > end > ... > > > override should probably do the existance check if it doesn't already. > Though the idea of building stuff to a common directory I believe obsoletes this entire override thing. > > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Apr 5 13:41:10 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 5 Apr 2010 11:41:10 +0000 Subject: [M3devel] RTMachine.PointerAlignment = 1 on NT? Message-ID: For the vast majority of platforms: RTMachine.PointerAlignment = BYTESIZE(INTEGER). except 1 for NT386, 2 for M68K (dead). PointerAlignment = BYTESIZE(INTEGER); (* The C compiler allocates all pointers on 'PointerAlignment'-byte boundaries. The garbage collector scans thread stacks, but only looks at these possible pointer locations. Setting this value smaller than is needed will only make your system run slower. Setting it too large will cause the collector to collect storage that is not free. *) I suggest this is not exactly true. 1) Of what relevance is the C compiler? vs. the Modula-3 compiler. 2) We really think the number is 1 for NT386? I understand I could say: void F(void* traced) { #pragma pack(1) struct { char a; void* p} = {0, traced}; } but 1) That seems highly unlikely. 2) Do we really anticipate the case where C code is the *only* holder of a traced reference? And more so, it wasn't a parameter to the C code -- the location of parameters is controlled by Modula-3, assuming a pointer-aligned stack. 3) Can't we know/assume/verify that Modula-3 code only stores pointers at more aligned location? My real goal is to make there only be one RTMachine for systems that don't have stack walkers. Leave SOLgnu/SOLsun alone. (Later on implement stack walking for many platforms via libunwind.) There are I believe only two differences to iron out. Allocation size (8K vs. 64K) and PointerAlignment (1 vs. BYTESIZE(INTEGER)). There is a reason for NT to be 64K allocation size -- that is what VirtualAlloc uses. I can test 64K on others. Historically smaller is probably more efficient. These days larger but not *too* large is probably more efficient. 64K should work fine on all platforms. Heck, even something larger like 1MB is probably good. I'll test out 64K. Can/should we have "paranoidgc" imply PointerAlignment = 1, and report whenever a pointer is found at a location with alignment less than BYTESIZE(pointer)? A form of this is reasonable today, right? If PointerAligment = 1, I can have it report any found at less than BYTESIZE(pointer), test it a while, if none found, elevate NT386 to that value? If any found, that'll help educate me/us on why it is 1, and maybe how to change it, or why leave it alone. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Apr 5 13:55:16 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 5 Apr 2010 11:55:16 +0000 Subject: [M3devel] RTMachine.PointerAlignment = 1 on NT? In-Reply-To: References: Message-ID: Interesting: PROCEDURE NoteStackLocations (start, stop: ADDRESS) = VAR fp : UNTRACED REF ADDRESS := start; BEGIN IF NOT (start < stop) THEN RETURN END; stop := stop - ADRSIZE (ADDRESS); (* so we don't overrun the valid addresses *) WHILE fp <= stop DO (* with the memory read on the next line. *) WITH page = AddressToPage(fp^) DO IF page # NIL AND page.desc.space = Space.Previous THEN IF RTMachine.PointerAlignment = 1 THEN IF Word.And(LOOPHOLE(fp, INTEGER), BYTESIZE(INTEGER) - 1) # 0 THEN RTIO.PutText("pointer found on unaligned stack stack="); RTIO.PutAddr(fp); RTIO.PutText(" addr="); RTIO.PutAddr(fp^); RTIO.PutText("\n"); RTIO.Flush(); END; END; IF page.desc.pure THEN PromotePage(page, PromoteReason.AmbiguousPure); ELSE PromotePage(page, PromoteReason.AmbiguousImpure); END; END; END; INC(fp, RTMachine.PointerAlignment); END; END NoteStackLocations; generates a fair amount of output: C:\dev2\cm3.2\m3-sys\mklib>cm3 --- building in NT386 --- ignoring ..\src\m3overrides pointer found on unaligned stack stack=0x12f3d2 addr=0x1400000 pointer found on unaligned stack stack=0x12f11e addr=0x1400000 pointer found on unaligned stack stack=0x12f186 addr=0x1400000 pointer found on unaligned stack stack=0x12f12e addr=0x1780000 pointer found on unaligned stack stack=0x12f1ba addr=0x1400000 pointer found on unaligned stack stack=0x12f442 addr=0x1460147 new source -> compiling Main.m3 pointer found on unaligned stack stack=0x12f3d2 addr=0x1400000 -> linking mklib.exe I need to look a bit more, see what these values are. We are probably being way over conservative, on NT. Such unaligned values as 0x1460147 surely shouldn't count as traced pointers. This example only has one but usually I see many more. C:\dev2\cm3.2\m3-sys\cm3>cm3 --- building in NT386 --- ignoring ..\src\m3overrides pointer found on unaligned stack stack=0x12f3d2 addr=0x1400000 pointer found on unaligned stack stack=0x12f642 addr=0x1400000 pointer found on unaligned stack stack=0x12f176 addr=0x1400000 pointer found on unaligned stack stack=0x12f11e addr=0x1400000 pointer found on unaligned stack stack=0x12f12a addr=0x1780000 pointer found on unaligned stack stack=0x12f1b6 addr=0x1400000 pointer found on unaligned stack stack=0x12f61e addr=0x1400000 pointer found on unaligned stack stack=0x12f6de addr=0x1900069 pointer found on unaligned stack stack=0x12f43e addr=0x1400000 pointer found on unaligned stack stack=0x12f156 addr=0x1400000 pointer found on unaligned stack stack=0x12f66e addr=0x1400000 pointer found on unaligned stack stack=0x12f72e addr=0x1900069 pointer found on unaligned stack stack=0x12f792 addr=0x1cc0000 pointer found on unaligned stack stack=0x12fb26 addr=0x1d7015c pointer found on unaligned stack stack=0x12fb52 addr=0x1d90142 All this scanning around in memory the garbage collector has to do, doesn't that kill working set? It makes all heap and stack part of the working set? Even if I'm not going to access it for long periods? - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Mon, 5 Apr 2010 11:41:10 +0000 Subject: [M3devel] RTMachine.PointerAlignment = 1 on NT? For the vast majority of platforms: RTMachine.PointerAlignment = BYTESIZE(INTEGER). except 1 for NT386, 2 for M68K (dead). PointerAlignment = BYTESIZE(INTEGER); (* The C compiler allocates all pointers on 'PointerAlignment'-byte boundaries. The garbage collector scans thread stacks, but only looks at these possible pointer locations. Setting this value smaller than is needed will only make your system run slower. Setting it too large will cause the collector to collect storage that is not free. *) I suggest this is not exactly true. 1) Of what relevance is the C compiler? vs. the Modula-3 compiler. 2) We really think the number is 1 for NT386? I understand I could say: void F(void* traced) { #pragma pack(1) struct { char a; void* p} = {0, traced}; } but 1) That seems highly unlikely. 2) Do we really anticipate the case where C code is the *only* holder of a traced reference? And more so, it wasn't a parameter to the C code -- the location of parameters is controlled by Modula-3, assuming a pointer-aligned stack. 3) Can't we know/assume/verify that Modula-3 code only stores pointers at more aligned location? My real goal is to make there only be one RTMachine for systems that don't have stack walkers. Leave SOLgnu/SOLsun alone. (Later on implement stack walking for many platforms via libunwind.) There are I believe only two differences to iron out. Allocation size (8K vs. 64K) and PointerAlignment (1 vs. BYTESIZE(INTEGER)). There is a reason for NT to be 64K allocation size -- that is what VirtualAlloc uses. I can test 64K on others. Historically smaller is probably more efficient. These days larger but not *too* large is probably more efficient. 64K should work fine on all platforms. Heck, even something larger like 1MB is probably good. I'll test out 64K. Can/should we have "paranoidgc" imply PointerAlignment = 1, and report whenever a pointer is found at a location with alignment less than BYTESIZE(pointer)? A form of this is reasonable today, right? If PointerAligment = 1, I can have it report any found at less than BYTESIZE(pointer), test it a while, if none found, elevate NT386 to that value? If any found, that'll help educate me/us on why it is 1, and maybe how to change it, or why leave it alone. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Apr 5 14:03:45 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 5 Apr 2010 12:03:45 +0000 Subject: [M3devel] RTMachine.PointerAlignment = 1 on NT? In-Reply-To: References: , Message-ID: hm I guess pointers themselves (not where they are stored) need not have any alignemnt? We might only have a pointer into an array of bytes to keep the array alive, no pointer to the base of the array? PROCEDURE F1() VAR a: ARRAY OF CHAR := NEW(CHAR, 10); i: INTEGER; BEGIN FOR i := FIRST(a) TO LAST(a) DO something with a[i]; END END F1; might only have pointers to elements in a? - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Mon, 5 Apr 2010 11:55:16 +0000 Subject: Re: [M3devel] RTMachine.PointerAlignment = 1 on NT? Interesting: PROCEDURE NoteStackLocations (start, stop: ADDRESS) = VAR fp : UNTRACED REF ADDRESS := start; BEGIN IF NOT (start < stop) THEN RETURN END; stop := stop - ADRSIZE (ADDRESS); (* so we don't overrun the valid addresses *) WHILE fp <= stop DO (* with the memory read on the next line. *) WITH page = AddressToPage(fp^) DO IF page # NIL AND page.desc.space = Space.Previous THEN IF RTMachine.PointerAlignment = 1 THEN IF Word.And(LOOPHOLE(fp, INTEGER), BYTESIZE(INTEGER) - 1) # 0 THEN RTIO.PutText("pointer found on unaligned stack stack="); RTIO.PutAddr(fp); RTIO.PutText(" addr="); RTIO.PutAddr(fp^); RTIO.PutText("\n"); RTIO.Flush(); END; END; IF page.desc.pure THEN PromotePage(page, PromoteReason.AmbiguousPure); ELSE PromotePage(page, PromoteReason.AmbiguousImpure); END; END; END; INC(fp, RTMachine.PointerAlignment); END; END NoteStackLocations; generates a fair amount of output: C:\dev2\cm3.2\m3-sys\mklib>cm3 --- building in NT386 --- ignoring ..\src\m3overrides pointer found on unaligned stack stack=0x12f3d2 addr=0x1400000 pointer found on unaligned stack stack=0x12f11e addr=0x1400000 pointer found on unaligned stack stack=0x12f186 addr=0x1400000 pointer found on unaligned stack stack=0x12f12e addr=0x1780000 pointer found on unaligned stack stack=0x12f1ba addr=0x1400000 pointer found on unaligned stack stack=0x12f442 addr=0x1460147 new source -> compiling Main.m3 pointer found on unaligned stack stack=0x12f3d2 addr=0x1400000 -> linking mklib.exe I need to look a bit more, see what these values are. We are probably being way over conservative, on NT. Such unaligned values as 0x1460147 surely shouldn't count as traced pointers. This example only has one but usually I see many more. C:\dev2\cm3.2\m3-sys\cm3>cm3 --- building in NT386 --- ignoring ..\src\m3overrides pointer found on unaligned stack stack=0x12f3d2 addr=0x1400000 pointer found on unaligned stack stack=0x12f642 addr=0x1400000 pointer found on unaligned stack stack=0x12f176 addr=0x1400000 pointer found on unaligned stack stack=0x12f11e addr=0x1400000 pointer found on unaligned stack stack=0x12f12a addr=0x1780000 pointer found on unaligned stack stack=0x12f1b6 addr=0x1400000 pointer found on unaligned stack stack=0x12f61e addr=0x1400000 pointer found on unaligned stack stack=0x12f6de addr=0x1900069 pointer found on unaligned stack stack=0x12f43e addr=0x1400000 pointer found on unaligned stack stack=0x12f156 addr=0x1400000 pointer found on unaligned stack stack=0x12f66e addr=0x1400000 pointer found on unaligned stack stack=0x12f72e addr=0x1900069 pointer found on unaligned stack stack=0x12f792 addr=0x1cc0000 pointer found on unaligned stack stack=0x12fb26 addr=0x1d7015c pointer found on unaligned stack stack=0x12fb52 addr=0x1d90142 All this scanning around in memory the garbage collector has to do, doesn't that kill working set? It makes all heap and stack part of the working set? Even if I'm not going to access it for long periods? - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Mon, 5 Apr 2010 11:41:10 +0000 Subject: [M3devel] RTMachine.PointerAlignment = 1 on NT? For the vast majority of platforms: RTMachine.PointerAlignment = BYTESIZE(INTEGER). except 1 for NT386, 2 for M68K (dead). PointerAlignment = BYTESIZE(INTEGER); (* The C compiler allocates all pointers on 'PointerAlignment'-byte boundaries. The garbage collector scans thread stacks, but only looks at these possible pointer locations. Setting this value smaller than is needed will only make your system run slower. Setting it too large will cause the collector to collect storage that is not free. *) I suggest this is not exactly true. 1) Of what relevance is the C compiler? vs. the Modula-3 compiler. 2) We really think the number is 1 for NT386? I understand I could say: void F(void* traced) { #pragma pack(1) struct { char a; void* p} = {0, traced}; } but 1) That seems highly unlikely. 2) Do we really anticipate the case where C code is the *only* holder of a traced reference? And more so, it wasn't a parameter to the C code -- the location of parameters is controlled by Modula-3, assuming a pointer-aligned stack. 3) Can't we know/assume/verify that Modula-3 code only stores pointers at more aligned location? My real goal is to make there only be one RTMachine for systems that don't have stack walkers. Leave SOLgnu/SOLsun alone. (Later on implement stack walking for many platforms via libunwind.) There are I believe only two differences to iron out. Allocation size (8K vs. 64K) and PointerAlignment (1 vs. BYTESIZE(INTEGER)). There is a reason for NT to be 64K allocation size -- that is what VirtualAlloc uses. I can test 64K on others. Historically smaller is probably more efficient. These days larger but not *too* large is probably more efficient. 64K should work fine on all platforms. Heck, even something larger like 1MB is probably good. I'll test out 64K. Can/should we have "paranoidgc" imply PointerAlignment = 1, and report whenever a pointer is found at a location with alignment less than BYTESIZE(pointer)? A form of this is reasonable today, right? If PointerAligment = 1, I can have it report any found at less than BYTESIZE(pointer), test it a while, if none found, elevate NT386 to that value? If any found, that'll help educate me/us on why it is 1, and maybe how to change it, or why leave it alone. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Apr 5 16:25:20 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 5 Apr 2010 10:25:20 -0400 Subject: [M3devel] RTMachine.PointerAlignment = 1 on NT? In-Reply-To: References: , Message-ID: <76C0DE79-7904-49B4-AE3F-83632B48CFDD@cs.purdue.edu> Yes, correct. Pointers from the stacks may be "derived" from object base references by the compiler or through use of VAR/READONLY parameters. So, the pointer values from the stack themselves need not be aligned. The PointerAlignment tells the collector at what alignment to expect to find pointers stored in the stack. Some compilers/targets may not require that pointer-valued fields in the stack be stored at aligned locations. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 5 Apr 2010, at 08:03, Jay K wrote: > hm I guess pointers themselves (not where they are stored) need not have any alignemnt? > We might only have a pointer into an array of bytes to keep the array alive, > no pointer to the base of the array? > > PROCEDURE F1() > VAR a: ARRAY OF CHAR := NEW(CHAR, 10); > i: INTEGER; > BEGIN > FOR i := FIRST(a) TO LAST(a) DO > something with a[i]; > END > END F1; > > might only have pointers to elements in a? > > - Jay > > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Mon, 5 Apr 2010 11:55:16 +0000 > Subject: Re: [M3devel] RTMachine.PointerAlignment = 1 on NT? > > Interesting: > > PROCEDURE NoteStackLocations (start, stop: ADDRESS) = > VAR fp : UNTRACED REF ADDRESS := start; > BEGIN > IF NOT (start < stop) THEN RETURN END; > stop := stop - ADRSIZE (ADDRESS); (* so we don't overrun the valid addresses *) > WHILE fp <= stop DO (* with the memory read on the next line. *) > WITH page = AddressToPage(fp^) DO > IF page # NIL AND page.desc.space = Space.Previous THEN > IF RTMachine.PointerAlignment = 1 THEN > IF Word.And(LOOPHOLE(fp, INTEGER), BYTESIZE(INTEGER) - 1) # 0 THEN > RTIO.PutText("pointer found on unaligned stack stack="); > RTIO.PutAddr(fp); > RTIO.PutText(" addr="); > RTIO.PutAddr(fp^); > RTIO.PutText("\n"); > RTIO.Flush(); > END; > END; > IF page.desc.pure > THEN PromotePage(page, PromoteReason.AmbiguousPure); > ELSE PromotePage(page, PromoteReason.AmbiguousImpure); > END; > END; > END; > INC(fp, RTMachine.PointerAlignment); > END; > END NoteStackLocations; > > > generates a fair amount of output: > > > C:\dev2\cm3.2\m3-sys\mklib>cm3 > --- building in NT386 --- > ignoring ..\src\m3overrides > pointer found on unaligned stack stack=0x12f3d2 addr=0x1400000 > pointer found on unaligned stack stack=0x12f11e addr=0x1400000 > pointer found on unaligned stack stack=0x12f186 addr=0x1400000 > pointer found on unaligned stack stack=0x12f12e addr=0x1780000 > pointer found on unaligned stack stack=0x12f1ba addr=0x1400000 > pointer found on unaligned stack stack=0x12f442 addr=0x1460147 > new source -> compiling Main.m3 > pointer found on unaligned stack stack=0x12f3d2 addr=0x1400000 > -> linking mklib.exe > > > I need to look a bit more, see what these values are. > We are probably being way over conservative, on NT. > Such unaligned values as 0x1460147 surely shouldn't count as traced pointers. > This example only has one but usually I see many more. > > > C:\dev2\cm3.2\m3-sys\cm3>cm3 > --- building in NT386 --- > ignoring ..\src\m3overrides > pointer found on unaligned stack stack=0x12f3d2 addr=0x1400000 > pointer found on unaligned stack stack=0x12f642 addr=0x1400000 > pointer found on unaligned stack stack=0x12f176 addr=0x1400000 > pointer found on unaligned stack stack=0x12f11e addr=0x1400000 > pointer found on unaligned stack stack=0x12f12a addr=0x1780000 > pointer found on unaligned stack stack=0x12f1b6 addr=0x1400000 > pointer found on unaligned stack stack=0x12f61e addr=0x1400000 > pointer found on unaligned stack stack=0x12f6de addr=0x1900069 > pointer found on unaligned stack stack=0x12f43e addr=0x1400000 > pointer found on unaligned stack stack=0x12f156 addr=0x1400000 > pointer found on unaligned stack stack=0x12f66e addr=0x1400000 > pointer found on unaligned stack stack=0x12f72e addr=0x1900069 > pointer found on unaligned stack stack=0x12f792 addr=0x1cc0000 > pointer found on unaligned stack stack=0x12fb26 addr=0x1d7015c > pointer found on unaligned stack stack=0x12fb52 addr=0x1d90142 > > > All this scanning around in memory the garbage collector has to do, doesn't that kill working set? > It makes all heap and stack part of the working set? Even if I'm not going to access it for long periods? > > > - Jay > > > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Mon, 5 Apr 2010 11:41:10 +0000 > Subject: [M3devel] RTMachine.PointerAlignment = 1 on NT? > > For the vast majority of platforms: > > > RTMachine.PointerAlignment = BYTESIZE(INTEGER). > > > except 1 for NT386, 2 for M68K (dead). > > > PointerAlignment = BYTESIZE(INTEGER); > (* The C compiler allocates all pointers on 'PointerAlignment'-byte > boundaries. The garbage collector scans thread stacks, but only > looks at these possible pointer locations. Setting this value > smaller than is needed will only make your system run slower. > Setting it too large will cause the collector to collect storage > that is not free. *) > > > I suggest this is not exactly true. > 1) Of what relevance is the C compiler? vs. the Modula-3 compiler. > 2) We really think the number is 1 for NT386? > > I understand I could say: > void F(void* traced) > { > #pragma pack(1) > struct { char a; void* p} = {0, traced}; > } > > but > 1) That seems highly unlikely. > 2) Do we really anticipate the case where C code is the *only* holder of a traced reference? > And more so, it wasn't a parameter to the C code -- the location of parameters is controlled by Modula-3, assuming a pointer-aligned stack. > 3) Can't we know/assume/verify that Modula-3 code only stores pointers at more aligned location? > > > My real goal is to make there only be one RTMachine for systems that don't have stack walkers. > Leave SOLgnu/SOLsun alone. > (Later on implement stack walking for many platforms via libunwind.) > > > There are I believe only two differences to iron out. Allocation size (8K vs. 64K) and PointerAlignment (1 vs. BYTESIZE(INTEGER)). > There is a reason for NT to be 64K allocation size -- that is what VirtualAlloc uses. > I can test 64K on others. > Historically smaller is probably more efficient. > These days larger but not *too* large is probably more efficient. > 64K should work fine on all platforms. Heck, even something larger like 1MB is probably good. > I'll test out 64K. > > > Can/should we have "paranoidgc" imply PointerAlignment = 1, and report whenever a pointer is found at a location with alignment less than BYTESIZE(pointer)? > > > A form of this is reasonable today, right? If PointerAligment = 1, I can have it report any found at less than BYTESIZE(pointer), test it a while, if none found, elevate NT386 to that value? > If any found, that'll help educate me/us on why it is 1, and maybe how to change it, or why leave it alone. > > > - Jay > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Apr 5 16:40:36 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 5 Apr 2010 14:40:36 +0000 Subject: [M3devel] RTMachine.PointerAlignment = 1 on NT? In-Reply-To: <76C0DE79-7904-49B4-AE3F-83632B48CFDD@cs.purdue.edu> References: , , <76C0DE79-7904-49B4-AE3F-83632B48CFDD@cs.purdue.edu> Message-ID: I think we can safely dispense with RTMachine.PointerAlignment and use BYTESIZE(INTEGER). NT386 is the only current exception. Even though it isn't required, of any x86 target, it seems the overwhelming practice. - Jay Subject: Re: [M3devel] RTMachine.PointerAlignment = 1 on NT? From: hosking at cs.purdue.edu Date: Mon, 5 Apr 2010 10:25:20 -0400 CC: m3devel at elegosoft.com To: jay.krell at cornell.edu Yes, correct. Pointers from the stacks may be "derived" from object base references by the compiler or through use of VAR/READONLY parameters. So, the pointer values from the stack themselves need not be aligned. The PointerAlignment tells the collector at what alignment to expect to find pointers stored in the stack. Some compilers/targets may not require that pointer-valued fields in the stack be stored at aligned locations. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 5 Apr 2010, at 08:03, Jay K wrote: hm I guess pointers themselves (not where they are stored) need not have any alignemnt? We might only have a pointer into an array of bytes to keep the array alive, no pointer to the base of the array? PROCEDURE F1() VAR a: ARRAY OF CHAR := NEW(CHAR, 10); i: INTEGER; BEGIN FOR i := FIRST(a) TO LAST(a) DO something with a[i]; END END F1; might only have pointers to elements in a? - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Mon, 5 Apr 2010 11:55:16 +0000 Subject: Re: [M3devel] RTMachine.PointerAlignment = 1 on NT? Interesting: PROCEDURE NoteStackLocations (start, stop: ADDRESS) = VAR fp : UNTRACED REF ADDRESS := start; BEGIN IF NOT (start < stop) THEN RETURN END; stop := stop - ADRSIZE (ADDRESS); (* so we don't overrun the valid addresses *) WHILE fp <= stop DO (* with the memory read on the next line. *) WITH page = AddressToPage(fp^) DO IF page # NIL AND page.desc.space = Space.Previous THEN IF RTMachine.PointerAlignment = 1 THEN IF Word.And(LOOPHOLE(fp, INTEGER), BYTESIZE(INTEGER) - 1) # 0 THEN RTIO.PutText("pointer found on unaligned stack stack="); RTIO.PutAddr(fp); RTIO.PutText(" addr="); RTIO.PutAddr(fp^); RTIO.PutText("\n"); RTIO.Flush(); END; END; IF page.desc.pure THEN PromotePage(page, PromoteReason.AmbiguousPure); ELSE PromotePage(page, PromoteReason.AmbiguousImpure); END; END; END; INC(fp, RTMachine.PointerAlignment); END; END NoteStackLocations; generates a fair amount of output: C:\dev2\cm3.2\m3-sys\mklib>cm3 --- building in NT386 --- ignoring ..\src\m3overrides pointer found on unaligned stack stack=0x12f3d2 addr=0x1400000 pointer found on unaligned stack stack=0x12f11e addr=0x1400000 pointer found on unaligned stack stack=0x12f186 addr=0x1400000 pointer found on unaligned stack stack=0x12f12e addr=0x1780000 pointer found on unaligned stack stack=0x12f1ba addr=0x1400000 pointer found on unaligned stack stack=0x12f442 addr=0x1460147 new source -> compiling Main.m3 pointer found on unaligned stack stack=0x12f3d2 addr=0x1400000 -> linking mklib.exe I need to look a bit more, see what these values are. We are probably being way over conservative, on NT. Such unaligned values as 0x1460147 surely shouldn't count as traced pointers. This example only has one but usually I see many more. C:\dev2\cm3.2\m3-sys\cm3>cm3 --- building in NT386 --- ignoring ..\src\m3overrides pointer found on unaligned stack stack=0x12f3d2 addr=0x1400000 pointer found on unaligned stack stack=0x12f642 addr=0x1400000 pointer found on unaligned stack stack=0x12f176 addr=0x1400000 pointer found on unaligned stack stack=0x12f11e addr=0x1400000 pointer found on unaligned stack stack=0x12f12a addr=0x1780000 pointer found on unaligned stack stack=0x12f1b6 addr=0x1400000 pointer found on unaligned stack stack=0x12f61e addr=0x1400000 pointer found on unaligned stack stack=0x12f6de addr=0x1900069 pointer found on unaligned stack stack=0x12f43e addr=0x1400000 pointer found on unaligned stack stack=0x12f156 addr=0x1400000 pointer found on unaligned stack stack=0x12f66e addr=0x1400000 pointer found on unaligned stack stack=0x12f72e addr=0x1900069 pointer found on unaligned stack stack=0x12f792 addr=0x1cc0000 pointer found on unaligned stack stack=0x12fb26 addr=0x1d7015c pointer found on unaligned stack stack=0x12fb52 addr=0x1d90142 All this scanning around in memory the garbage collector has to do, doesn't that kill working set? It makes all heap and stack part of the working set? Even if I'm not going to access it for long periods? - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Mon, 5 Apr 2010 11:41:10 +0000 Subject: [M3devel] RTMachine.PointerAlignment = 1 on NT? For the vast majority of platforms: RTMachine.PointerAlignment = BYTESIZE(INTEGER). except 1 for NT386, 2 for M68K (dead). PointerAlignment = BYTESIZE(INTEGER); (* The C compiler allocates all pointers on 'PointerAlignment'-byte boundaries. The garbage collector scans thread stacks, but only looks at these possible pointer locations. Setting this value smaller than is needed will only make your system run slower. Setting it too large will cause the collector to collect storage that is not free. *) I suggest this is not exactly true. 1) Of what relevance is the C compiler? vs. the Modula-3 compiler. 2) We really think the number is 1 for NT386? I understand I could say: void F(void* traced) { #pragma pack(1) struct { char a; void* p} = {0, traced}; } but 1) That seems highly unlikely. 2) Do we really anticipate the case where C code is the *only* holder of a traced reference? And more so, it wasn't a parameter to the C code -- the location of parameters is controlled by Modula-3, assuming a pointer-aligned stack. 3) Can't we know/assume/verify that Modula-3 code only stores pointers at more aligned location? My real goal is to make there only be one RTMachine for systems that don't have stack walkers. Leave SOLgnu/SOLsun alone. (Later on implement stack walking for many platforms via libunwind.) There are I believe only two differences to iron out. Allocation size (8K vs. 64K) and PointerAlignment (1 vs. BYTESIZE(INTEGER)). There is a reason for NT to be 64K allocation size -- that is what VirtualAlloc uses. I can test 64K on others. Historically smaller is probably more efficient. These days larger but not *too* large is probably more efficient. 64K should work fine on all platforms. Heck, even something larger like 1MB is probably good. I'll test out 64K. Can/should we have "paranoidgc" imply PointerAlignment = 1, and report whenever a pointer is found at a location with alignment less than BYTESIZE(pointer)? A form of this is reasonable today, right? If PointerAligment = 1, I can have it report any found at less than BYTESIZE(pointer), test it a while, if none found, elevate NT386 to that value? If any found, that'll help educate me/us on why it is 1, and maybe how to change it, or why leave it alone. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Apr 5 19:31:45 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 5 Apr 2010 13:31:45 -0400 Subject: [M3devel] RTMachine.PointerAlignment = 1 on NT? In-Reply-To: References: , , <76C0DE79-7904-49B4-AE3F-83632B48CFDD@cs.purdue.edu> Message-ID: More accurately, BYTESIZE(ADDRESS)? Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 5 Apr 2010, at 10:40, Jay K wrote: > I think we can safely dispense with RTMachine.PointerAlignment and use BYTESIZE(INTEGER). > NT386 is the only current exception. > Even though it isn't required, of any x86 target, it seems the overwhelming practice. > > - Jay > > Subject: Re: [M3devel] RTMachine.PointerAlignment = 1 on NT? > From: hosking at cs.purdue.edu > Date: Mon, 5 Apr 2010 10:25:20 -0400 > CC: m3devel at elegosoft.com > To: jay.krell at cornell.edu > > Yes, correct. Pointers from the stacks may be "derived" from object base references by the compiler or through use of VAR/READONLY parameters. So, the pointer values from the stack themselves need not be aligned. The PointerAlignment tells the collector at what alignment to expect to find pointers stored in the stack. Some compilers/targets may not require that pointer-valued fields in the stack be stored at aligned locations. > > > > Antony Hosking | Associate Professor | Computer Science | Purdue University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > On 5 Apr 2010, at 08:03, Jay K wrote: > > hm I guess pointers themselves (not where they are stored) need not have any alignemnt? > We might only have a pointer into an array of bytes to keep the array alive, > no pointer to the base of the array? > > PROCEDURE F1() > VAR a: ARRAY OF CHAR := NEW(CHAR, 10); > i: INTEGER; > BEGIN > FOR i := FIRST(a) TO LAST(a) DO > something with a[i]; > END > END F1; > > might only have pointers to elements in a? > > - Jay > > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Mon, 5 Apr 2010 11:55:16 +0000 > Subject: Re: [M3devel] RTMachine.PointerAlignment = 1 on NT? > > Interesting: > > PROCEDURE NoteStackLocations (start, stop: ADDRESS) = > VAR fp : UNTRACED REF ADDRESS := start; > BEGIN > IF NOT (start < stop) THEN RETURN END; > stop := stop - ADRSIZE (ADDRESS); (* so we don't overrun the valid addresses *) > WHILE fp <= stop DO (* with the memory read on the next line. *) > WITH page = AddressToPage(fp^) DO > IF page # NIL AND page.desc.space = Space.Previous THEN > IF RTMachine.PointerAlignment = 1 THEN > IF Word.And(LOOPHOLE(fp, INTEGER), BYTESIZE(INTEGER) - 1) # 0 THEN > RTIO.PutText("pointer found on unaligned stack stack="); > RTIO.PutAddr(fp); > RTIO.PutText(" addr="); > RTIO.PutAddr(fp^); > RTIO.PutText("\n"); > RTIO.Flush(); > END; > END; > IF page.desc.pure > THEN PromotePage(page, PromoteReason.AmbiguousPure); > ELSE PromotePage(page, PromoteReason.AmbiguousImpure); > END; > END; > END; > INC(fp, RTMachine.PointerAlignment); > END; > END NoteStackLocations; > > > generates a fair amount of output: > > > C:\dev2\cm3.2\m3-sys\mklib>cm3 > --- building in NT386 --- > ignoring ..\src\m3overrides > pointer found on unaligned stack stack=0x12f3d2 addr=0x1400000 > pointer found on unaligned stack stack=0x12f11e addr=0x1400000 > pointer found on unaligned stack stack=0x12f186 addr=0x1400000 > pointer found on unaligned stack stack=0x12f12e addr=0x1780000 > pointer found on unaligned stack stack=0x12f1ba addr=0x1400000 > pointer found on unaligned stack stack=0x12f442 addr=0x1460147 > new source -> compiling Main.m3 > pointer found on unaligned stack stack=0x12f3d2 addr=0x1400000 > -> linking mklib.exe > > > I need to look a bit more, see what these values are. > We are probably being way over conservative, on NT. > Such unaligned values as 0x1460147 surely shouldn't count as traced pointers. > This example only has one but usually I see many more. > > > C:\dev2\cm3.2\m3-sys\cm3>cm3 > --- building in NT386 --- > ignoring ..\src\m3overrides > pointer found on unaligned stack stack=0x12f3d2 addr=0x1400000 > pointer found on unaligned stack stack=0x12f642 addr=0x1400000 > pointer found on unaligned stack stack=0x12f176 addr=0x1400000 > pointer found on unaligned stack stack=0x12f11e addr=0x1400000 > pointer found on unaligned stack stack=0x12f12a addr=0x1780000 > pointer found on unaligned stack stack=0x12f1b6 addr=0x1400000 > pointer found on unaligned stack stack=0x12f61e addr=0x1400000 > pointer found on unaligned stack stack=0x12f6de addr=0x1900069 > pointer found on unaligned stack stack=0x12f43e addr=0x1400000 > pointer found on unaligned stack stack=0x12f156 addr=0x1400000 > pointer found on unaligned stack stack=0x12f66e addr=0x1400000 > pointer found on unaligned stack stack=0x12f72e addr=0x1900069 > pointer found on unaligned stack stack=0x12f792 addr=0x1cc0000 > pointer found on unaligned stack stack=0x12fb26 addr=0x1d7015c > pointer found on unaligned stack stack=0x12fb52 addr=0x1d90142 > > > All this scanning around in memory the garbage collector has to do, doesn't that kill working set? > It makes all heap and stack part of the working set? Even if I'm not going to access it for long periods? > > > - Jay > > > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Mon, 5 Apr 2010 11:41:10 +0000 > Subject: [M3devel] RTMachine.PointerAlignment = 1 on NT? > > For the vast majority of platforms: > > > RTMachine.PointerAlignment = BYTESIZE(INTEGER). > > > except 1 for NT386, 2 for M68K (dead). > > > PointerAlignment = BYTESIZE(INTEGER); > (* The C compiler allocates all pointers on 'PointerAlignment'-byte > boundaries. The garbage collector scans thread stacks, but only > looks at these possible pointer locations. Setting this value > smaller than is needed will only make your system run slower. > Setting it too large will cause the collector to collect storage > that is not free. *) > > > I suggest this is not exactly true. > 1) Of what relevance is the C compiler? vs. the Modula-3 compiler. > 2) We really think the number is 1 for NT386? > > I understand I could say: > void F(void* traced) > { > #pragma pack(1) > struct { char a; void* p} = {0, traced}; > } > > but > 1) That seems highly unlikely. > 2) Do we really anticipate the case where C code is the *only* holder of a traced reference? > And more so, it wasn't a parameter to the C code -- the location of parameters is controlled by Modula-3, assuming a pointer-aligned stack. > 3) Can't we know/assume/verify that Modula-3 code only stores pointers at more aligned location? > > > My real goal is to make there only be one RTMachine for systems that don't have stack walkers. > Leave SOLgnu/SOLsun alone. > (Later on implement stack walking for many platforms via libunwind.) > > > There are I believe only two differences to iron out. Allocation size (8K vs. 64K) and PointerAlignment (1 vs. BYTESIZE(INTEGER)). > There is a reason for NT to be 64K allocation size -- that is what VirtualAlloc uses. > I can test 64K on others. > Historically smaller is probably more efficient. > These days larger but not *too* large is probably more efficient. > 64K should work fine on all platforms. Heck, even something larger like 1MB is probably good. > I'll test out 64K. > > > Can/should we have "paranoidgc" imply PointerAlignment = 1, and report whenever a pointer is found at a location with alignment less than BYTESIZE(pointer)? > > > A form of this is reasonable today, right? If PointerAligment = 1, I can have it report any found at less than BYTESIZE(pointer), test it a while, if none found, elevate NT386 to that value? > If any found, that'll help educate me/us on why it is 1, and maybe how to change it, or why leave it alone. > > > - Jay > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Apr 6 00:03:25 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 5 Apr 2010 22:03:25 +0000 Subject: [M3devel] RTMachine.PointerAlignment = 1 on NT? In-Reply-To: References: , , , , , <76C0DE79-7904-49B4-AE3F-83632B48CFDD@cs.purdue.edu>, , Message-ID: Yes. Same thing. - Jay From: hosking at cs.purdue.edu Date: Mon, 5 Apr 2010 13:31:45 -0400 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] RTMachine.PointerAlignment = 1 on NT? More accurately, BYTESIZE(ADDRESS)? Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 5 Apr 2010, at 10:40, Jay K wrote: I think we can safely dispense with RTMachine.PointerAlignment and use BYTESIZE(INTEGER). NT386 is the only current exception. Even though it isn't required, of any x86 target, it seems the overwhelming practice. - Jay Subject: Re: [M3devel] RTMachine.PointerAlignment = 1 on NT? From: hosking at cs.purdue.edu Date: Mon, 5 Apr 2010 10:25:20 -0400 CC: m3devel at elegosoft.com To: jay.krell at cornell.edu Yes, correct. Pointers from the stacks may be "derived" from object base references by the compiler or through use of VAR/READONLY parameters. So, the pointer values from the stack themselves need not be aligned. The PointerAlignment tells the collector at what alignment to expect to find pointers stored in the stack. Some compilers/targets may not require that pointer-valued fields in the stack be stored at aligned locations. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 5 Apr 2010, at 08:03, Jay K wrote: hm I guess pointers themselves (not where they are stored) need not have any alignemnt? We might only have a pointer into an array of bytes to keep the array alive, no pointer to the base of the array? PROCEDURE F1() VAR a: ARRAY OF CHAR := NEW(CHAR, 10); i: INTEGER; BEGIN FOR i := FIRST(a) TO LAST(a) DO something with a[i]; END END F1; might only have pointers to elements in a? - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Mon, 5 Apr 2010 11:55:16 +0000 Subject: Re: [M3devel] RTMachine.PointerAlignment = 1 on NT? Interesting: PROCEDURE NoteStackLocations (start, stop: ADDRESS) = VAR fp : UNTRACED REF ADDRESS := start; BEGIN IF NOT (start < stop) THEN RETURN END; stop := stop - ADRSIZE (ADDRESS); (* so we don't overrun the valid addresses *) WHILE fp <= stop DO (* with the memory read on the next line. *) WITH page = AddressToPage(fp^) DO IF page # NIL AND page.desc.space = Space.Previous THEN IF RTMachine.PointerAlignment = 1 THEN IF Word.And(LOOPHOLE(fp, INTEGER), BYTESIZE(INTEGER) - 1) # 0 THEN RTIO.PutText("pointer found on unaligned stack stack="); RTIO.PutAddr(fp); RTIO.PutText(" addr="); RTIO.PutAddr(fp^); RTIO.PutText("\n"); RTIO.Flush(); END; END; IF page.desc.pure THEN PromotePage(page, PromoteReason.AmbiguousPure); ELSE PromotePage(page, PromoteReason.AmbiguousImpure); END; END; END; INC(fp, RTMachine.PointerAlignment); END; END NoteStackLocations; generates a fair amount of output: C:\dev2\cm3.2\m3-sys\mklib>cm3 --- building in NT386 --- ignoring ..\src\m3overrides pointer found on unaligned stack stack=0x12f3d2 addr=0x1400000 pointer found on unaligned stack stack=0x12f11e addr=0x1400000 pointer found on unaligned stack stack=0x12f186 addr=0x1400000 pointer found on unaligned stack stack=0x12f12e addr=0x1780000 pointer found on unaligned stack stack=0x12f1ba addr=0x1400000 pointer found on unaligned stack stack=0x12f442 addr=0x1460147 new source -> compiling Main.m3 pointer found on unaligned stack stack=0x12f3d2 addr=0x1400000 -> linking mklib.exe I need to look a bit more, see what these values are. We are probably being way over conservative, on NT. Such unaligned values as 0x1460147 surely shouldn't count as traced pointers. This example only has one but usually I see many more. C:\dev2\cm3.2\m3-sys\cm3>cm3 --- building in NT386 --- ignoring ..\src\m3overrides pointer found on unaligned stack stack=0x12f3d2 addr=0x1400000 pointer found on unaligned stack stack=0x12f642 addr=0x1400000 pointer found on unaligned stack stack=0x12f176 addr=0x1400000 pointer found on unaligned stack stack=0x12f11e addr=0x1400000 pointer found on unaligned stack stack=0x12f12a addr=0x1780000 pointer found on unaligned stack stack=0x12f1b6 addr=0x1400000 pointer found on unaligned stack stack=0x12f61e addr=0x1400000 pointer found on unaligned stack stack=0x12f6de addr=0x1900069 pointer found on unaligned stack stack=0x12f43e addr=0x1400000 pointer found on unaligned stack stack=0x12f156 addr=0x1400000 pointer found on unaligned stack stack=0x12f66e addr=0x1400000 pointer found on unaligned stack stack=0x12f72e addr=0x1900069 pointer found on unaligned stack stack=0x12f792 addr=0x1cc0000 pointer found on unaligned stack stack=0x12fb26 addr=0x1d7015c pointer found on unaligned stack stack=0x12fb52 addr=0x1d90142 All this scanning around in memory the garbage collector has to do, doesn't that kill working set? It makes all heap and stack part of the working set? Even if I'm not going to access it for long periods? - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Mon, 5 Apr 2010 11:41:10 +0000 Subject: [M3devel] RTMachine.PointerAlignment = 1 on NT? For the vast majority of platforms: RTMachine.PointerAlignment = BYTESIZE(INTEGER). except 1 for NT386, 2 for M68K (dead). PointerAlignment = BYTESIZE(INTEGER); (* The C compiler allocates all pointers on 'PointerAlignment'-byte boundaries. The garbage collector scans thread stacks, but only looks at these possible pointer locations. Setting this value smaller than is needed will only make your system run slower. Setting it too large will cause the collector to collect storage that is not free. *) I suggest this is not exactly true. 1) Of what relevance is the C compiler? vs. the Modula-3 compiler. 2) We really think the number is 1 for NT386? I understand I could say: void F(void* traced) { #pragma pack(1) struct { char a; void* p} = {0, traced}; } but 1) That seems highly unlikely. 2) Do we really anticipate the case where C code is the *only* holder of a traced reference? And more so, it wasn't a parameter to the C code -- the location of parameters is controlled by Modula-3, assuming a pointer-aligned stack. 3) Can't we know/assume/verify that Modula-3 code only stores pointers at more aligned location? My real goal is to make there only be one RTMachine for systems that don't have stack walkers. Leave SOLgnu/SOLsun alone. (Later on implement stack walking for many platforms via libunwind.) There are I believe only two differences to iron out. Allocation size (8K vs. 64K) and PointerAlignment (1 vs. BYTESIZE(INTEGER)). There is a reason for NT to be 64K allocation size -- that is what VirtualAlloc uses. I can test 64K on others. Historically smaller is probably more efficient. These days larger but not *too* large is probably more efficient. 64K should work fine on all platforms. Heck, even something larger like 1MB is probably good. I'll test out 64K. Can/should we have "paranoidgc" imply PointerAlignment = 1, and report whenever a pointer is found at a location with alignment less than BYTESIZE(pointer)? A form of this is reasonable today, right? If PointerAligment = 1, I can have it report any found at less than BYTESIZE(pointer), test it a while, if none found, elevate NT386 to that value? If any found, that'll help educate me/us on why it is 1, and maybe how to change it, or why leave it alone. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Tue Apr 6 01:35:32 2010 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Tue, 06 Apr 2010 01:35:32 +0200 Subject: [M3devel] lock performance, random thoughts Message-ID: <1270510533.10280.32.camel@faramir.m3w.org> I've been thinking few days about this lock performance thing. As POSIX mutexes are getting us too many times into kernel space by way of syscalls, maybe we can get some performance back while not loosing scheduling efficiency and multi-processor side of kernel-space/POSIX threading? User-space threads were two things. One - user-space threads. Two - user-space synchronizing. If we implement former inCritical by using lockfree abilities of modern multi-processor/multi-core/cluster systems and then revert to user-space synchronizing _only_ we can have best of both worlds. We need user-space threads because we need to have our Modula-3 process spread it's threads over whatever we run it on. And we will be very happy to have synchronizing efficency back. Few details to decide how to implement would be preempting/wakeup cycle, and waiting loop on our inCritical flag. Both can be solved by POSIX primitives. What do you think about this? dd -- Dragi?a Duri? From hosking at cs.purdue.edu Tue Apr 6 01:44:02 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 5 Apr 2010 19:44:02 -0400 Subject: [M3devel] RTMachine.PointerAlignment = 1 on NT? In-Reply-To: References: , , , , , <76C0DE79-7904-49B4-AE3F-83632B48CFDD@cs.purdue.edu>, , Message-ID: Same thing only for implementations where BYTESIZE(Word.T) = BYTESIZE(INTEGER) = BYTESIZE(ADDRESS). But that's all of ours. On 5 Apr 2010, at 18:03, Jay K wrote: > Yes. Same thing. > > - Jay > > From: hosking at cs.purdue.edu > Date: Mon, 5 Apr 2010 13:31:45 -0400 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] RTMachine.PointerAlignment = 1 on NT? > > More accurately, BYTESIZE(ADDRESS)? > > Antony Hosking | Associate Professor | Computer Science | Purdue University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > On 5 Apr 2010, at 10:40, Jay K wrote: > > I think we can safely dispense with RTMachine.PointerAlignment and use BYTESIZE(INTEGER). > NT386 is the only current exception. > Even though it isn't required, of any x86 target, it seems the overwhelming practice. > > - Jay > > Subject: Re: [M3devel] RTMachine.PointerAlignment = 1 on NT? > From: hosking at cs.purdue.edu > Date: Mon, 5 Apr 2010 10:25:20 -0400 > CC: m3devel at elegosoft.com > To: jay.krell at cornell.edu > > Yes, correct. Pointers from the stacks may be "derived" from object base references by the compiler or through use of VAR/READONLY parameters. So, the pointer values from the stack themselves need not be aligned. The PointerAlignment tells the collector at what alignment to expect to find pointers stored in the stack. Some compilers/targets may not require that pointer-valued fields in the stack be stored at aligned locations. > > > > Antony Hosking | Associate Professor | Computer Science | Purdue University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > On 5 Apr 2010, at 08:03, Jay K wrote: > > hm I guess pointers themselves (not where they are stored) need not have any alignemnt? > We might only have a pointer into an array of bytes to keep the array alive, > no pointer to the base of the array? > > PROCEDURE F1() > VAR a: ARRAY OF CHAR := NEW(CHAR, 10); > i: INTEGER; > BEGIN > FOR i := FIRST(a) TO LAST(a) DO > something with a[i]; > END > END F1; > > might only have pointers to elements in a? > > - Jay > > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Mon, 5 Apr 2010 11:55:16 +0000 > Subject: Re: [M3devel] RTMachine.PointerAlignment = 1 on NT? > > Interesting: > > PROCEDURE NoteStackLocations (start, stop: ADDRESS) = > VAR fp : UNTRACED REF ADDRESS := start; > BEGIN > IF NOT (start < stop) THEN RETURN END; > stop := stop - ADRSIZE (ADDRESS); (* so we don't overrun the valid addresses *) > WHILE fp <= stop DO (* with the memory read on the next line. *) > WITH page = AddressToPage(fp^) DO > IF page # NIL AND page.desc.space = Space.Previous THEN > IF RTMachine.PointerAlignment = 1 THEN > IF Word.And(LOOPHOLE(fp, INTEGER), BYTESIZE(INTEGER) - 1) # 0 THEN > RTIO.PutText("pointer found on unaligned stack stack="); > RTIO.PutAddr(fp); > RTIO.PutText(" addr="); > RTIO.PutAddr(fp^); > RTIO.PutText("\n"); > RTIO.Flush(); > END; > END; > IF page.desc.pure > THEN PromotePage(page, PromoteReason.AmbiguousPure); > ELSE PromotePage(page, PromoteReason.AmbiguousImpure); > END; > END; > END; > INC(fp, RTMachine.PointerAlignment); > END; > END NoteStackLocations; > > > generates a fair amount of output: > > > C:\dev2\cm3.2\m3-sys\mklib>cm3 > --- building in NT386 --- > ignoring ..\src\m3overrides > pointer found on unaligned stack stack=0x12f3d2 addr=0x1400000 > pointer found on unaligned stack stack=0x12f11e addr=0x1400000 > pointer found on unaligned stack stack=0x12f186 addr=0x1400000 > pointer found on unaligned stack stack=0x12f12e addr=0x1780000 > pointer found on unaligned stack stack=0x12f1ba addr=0x1400000 > pointer found on unaligned stack stack=0x12f442 addr=0x1460147 > new source -> compiling Main.m3 > pointer found on unaligned stack stack=0x12f3d2 addr=0x1400000 > -> linking mklib.exe > > > I need to look a bit more, see what these values are. > We are probably being way over conservative, on NT. > Such unaligned values as 0x1460147 surely shouldn't count as traced pointers. > This example only has one but usually I see many more. > > > C:\dev2\cm3.2\m3-sys\cm3>cm3 > --- building in NT386 --- > ignoring ..\src\m3overrides > pointer found on unaligned stack stack=0x12f3d2 addr=0x1400000 > pointer found on unaligned stack stack=0x12f642 addr=0x1400000 > pointer found on unaligned stack stack=0x12f176 addr=0x1400000 > pointer found on unaligned stack stack=0x12f11e addr=0x1400000 > pointer found on unaligned stack stack=0x12f12a addr=0x1780000 > pointer found on unaligned stack stack=0x12f1b6 addr=0x1400000 > pointer found on unaligned stack stack=0x12f61e addr=0x1400000 > pointer found on unaligned stack stack=0x12f6de addr=0x1900069 > pointer found on unaligned stack stack=0x12f43e addr=0x1400000 > pointer found on unaligned stack stack=0x12f156 addr=0x1400000 > pointer found on unaligned stack stack=0x12f66e addr=0x1400000 > pointer found on unaligned stack stack=0x12f72e addr=0x1900069 > pointer found on unaligned stack stack=0x12f792 addr=0x1cc0000 > pointer found on unaligned stack stack=0x12fb26 addr=0x1d7015c > pointer found on unaligned stack stack=0x12fb52 addr=0x1d90142 > > > All this scanning around in memory the garbage collector has to do, doesn't that kill working set? > It makes all heap and stack part of the working set? Even if I'm not going to access it for long periods? > > > - Jay > > > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Mon, 5 Apr 2010 11:41:10 +0000 > Subject: [M3devel] RTMachine.PointerAlignment = 1 on NT? > > For the vast majority of platforms: > > > RTMachine.PointerAlignment = BYTESIZE(INTEGER). > > > except 1 for NT386, 2 for M68K (dead). > > > PointerAlignment = BYTESIZE(INTEGER); > (* The C compiler allocates all pointers on 'PointerAlignment'-byte > boundaries. The garbage collector scans thread stacks, but only > looks at these possible pointer locations. Setting this value > smaller than is needed will only make your system run slower. > Setting it too large will cause the collector to collect storage > that is not free. *) > > > I suggest this is not exactly true. > 1) Of what relevance is the C compiler? vs. the Modula-3 compiler. > 2) We really think the number is 1 for NT386? > > I understand I could say: > void F(void* traced) > { > #pragma pack(1) > struct { char a; void* p} = {0, traced}; > } > > but > 1) That seems highly unlikely. > 2) Do we really anticipate the case where C code is the *only* holder of a traced reference? > And more so, it wasn't a parameter to the C code -- the location of parameters is controlled by Modula-3, assuming a pointer-aligned stack. > 3) Can't we know/assume/verify that Modula-3 code only stores pointers at more aligned location? > > > My real goal is to make there only be one RTMachine for systems that don't have stack walkers. > Leave SOLgnu/SOLsun alone. > (Later on implement stack walking for many platforms via libunwind.) > > > There are I believe only two differences to iron out. Allocation size (8K vs. 64K) and PointerAlignment (1 vs. BYTESIZE(INTEGER)). > There is a reason for NT to be 64K allocation size -- that is what VirtualAlloc uses. > I can test 64K on others. > Historically smaller is probably more efficient. > These days larger but not *too* large is probably more efficient. > 64K should work fine on all platforms. Heck, even something larger like 1MB is probably good. > I'll test out 64K. > > > Can/should we have "paranoidgc" imply PointerAlignment = 1, and report whenever a pointer is found at a location with alignment less than BYTESIZE(pointer)? > > > A form of this is reasonable today, right? If PointerAligment = 1, I can have it report any found at less than BYTESIZE(pointer), test it a while, if none found, elevate NT386 to that value? > If any found, that'll help educate me/us on why it is 1, and maybe how to change it, or why leave it alone. > > > - Jay > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Apr 6 01:45:20 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 5 Apr 2010 19:45:20 -0400 Subject: [M3devel] lock performance, random thoughts In-Reply-To: <1270510533.10280.32.camel@faramir.m3w.org> References: <1270510533.10280.32.camel@faramir.m3w.org> Message-ID: <1F5A794A-40AB-4F94-B11A-9218DAA30ED4@cs.purdue.edu> Yes, that's pretty much what modern Java implementations do. On 5 Apr 2010, at 19:35, Dragi?a Duri? wrote: > I've been thinking few days about this lock performance thing. As POSIX > mutexes are getting us too many times into kernel space by way of > syscalls, maybe we can get some performance back while not loosing > scheduling efficiency and multi-processor side of kernel-space/POSIX > threading? > > User-space threads were two things. One - user-space threads. Two - > user-space synchronizing. If we implement former inCritical by using > lockfree abilities of modern multi-processor/multi-core/cluster systems > and then revert to user-space synchronizing _only_ we can have best of > both worlds. > > We need user-space threads because we need to have our Modula-3 process > spread it's threads over whatever we run it on. And we will be very > happy to have synchronizing efficency back. > > Few details to decide how to implement would be preempting/wakeup cycle, > and waiting loop on our inCritical flag. Both can be solved by POSIX > primitives. > > What do you think about this? > > dd > > -- > Dragi?a Duri? From dragisha at m3w.org Tue Apr 6 01:57:07 2010 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Tue, 06 Apr 2010 01:57:07 +0200 Subject: [M3devel] lock performance, random thoughts In-Reply-To: <1F5A794A-40AB-4F94-B11A-9218DAA30ED4@cs.purdue.edu> References: <1270510533.10280.32.camel@faramir.m3w.org> <1F5A794A-40AB-4F94-B11A-9218DAA30ED4@cs.purdue.edu> Message-ID: <1270511827.10280.37.camel@faramir.m3w.org> I've used Java for one project, "GUI" app frontend for mobile phones... What I saw first was their mixup of mutex/condition/cheese in single root object... But, ok... offtopic there :) What I think is important about whole idea is it's simplicity and (almost) obvious efficiency. It also needs nothing fancy (not today, at least) and nothing maybe-it-works to implement. Nothing comparable to early implementations of kernel space threading/thread suspending for gc/... Any takers? :) On Mon, 2010-04-05 at 19:45 -0400, Tony Hosking wrote: > Yes, that's pretty much what modern Java implementations do. > > -- Dragi?a Duri? From jay.krell at cornell.edu Tue Apr 6 02:13:07 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 6 Apr 2010 00:13:07 +0000 Subject: [M3devel] lock performance, random thoughts In-Reply-To: <1270511827.10280.37.camel@faramir.m3w.org> References: <1270510533.10280.32.camel@faramir.m3w.org>, <1F5A794A-40AB-4F94-B11A-9218DAA30ED4@cs.purdue.edu>, <1270511827.10280.37.camel@faramir.m3w.org> Message-ID: pthread_mutex_lock/unlock does not imply a kernel call. ! pthreads can synchronize in usermode just as well (or only almost as well?) as Tony's design. Only upon contention is a kernel call needed, in both. That's not to say that everyone implements this well. Linux does. Win32 does. The others I don't know. Also Tony avoids even atomic operations often. I'm not sure how others compare there. I'm just referring to kernel/syscalls. Are they really so terrible? - Jay > From: dragisha at m3w.org > To: hosking at cs.purdue.edu > Date: Tue, 6 Apr 2010 01:57:07 +0200 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] lock performance, random thoughts > > I've used Java for one project, "GUI" app frontend for mobile phones... > What I saw first was their mixup of mutex/condition/cheese in single > root object... But, ok... offtopic there :) > > What I think is important about whole idea is it's simplicity and > (almost) obvious efficiency. It also needs nothing fancy (not today, at > least) and nothing maybe-it-works to implement. Nothing comparable to > early implementations of kernel space threading/thread suspending for > gc/... > > Any takers? :) > > > On Mon, 2010-04-05 at 19:45 -0400, Tony Hosking wrote: > > Yes, that's pretty much what modern Java implementations do. > > > > > -- > Dragi?a Duri? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Apr 6 02:20:18 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 6 Apr 2010 00:20:18 +0000 Subject: [M3devel] RTMachine.PointerAlignment = 1 on NT? In-Reply-To: References: , , , , , , , , <76C0DE79-7904-49B4-AE3F-83632B48CFDD@cs.purdue.edu>, , , , , , Message-ID: Isn't this kind of "architectural"? Like, assumed in a bunch of code, too hard to change, better to adhere to than change? Can continue to write code assuming it. Consider AMD64_NT. I assume INTEGER there should be 64bits, even though int and long are both 32. Corralary: long shouldn't be used for anything, ever. int is 32 bits, always; ignoring old systems INTEGER is pointer size, always (the question here) long is sometimes 32 bits, sometimes pointer size, but neither is always true, on modern systems If you consider Win64. If you ignore Win64, then, yes, I realize, long is always a pointer. The types to use in C for pointer sized integers are size_t and ptrdiff_t. For that matter..BYTESIZE and ADRSIZE, they are always the same and will always be, right? "All machines are byte-addressable", these days and forever more? - Jay From: hosking at cs.purdue.edu Date: Mon, 5 Apr 2010 19:44:02 -0400 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] RTMachine.PointerAlignment = 1 on NT? Same thing only for implementations where BYTESIZE(Word.T) = BYTESIZE(INTEGER) = BYTESIZE(ADDRESS). But that's all of ours. On 5 Apr 2010, at 18:03, Jay K wrote: Yes. Same thing. - Jay From: hosking at cs.purdue.edu Date: Mon, 5 Apr 2010 13:31:45 -0400 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] RTMachine.PointerAlignment = 1 on NT? More accurately, BYTESIZE(ADDRESS)? Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 5 Apr 2010, at 10:40, Jay K wrote: I think we can safely dispense with RTMachine.PointerAlignment and use BYTESIZE(INTEGER). NT386 is the only current exception. Even though it isn't required, of any x86 target, it seems the overwhelming practice. - Jay Subject: Re: [M3devel] RTMachine.PointerAlignment = 1 on NT? From: hosking at cs.purdue.edu Date: Mon, 5 Apr 2010 10:25:20 -0400 CC: m3devel at elegosoft.com To: jay.krell at cornell.edu Yes, correct. Pointers from the stacks may be "derived" from object base references by the compiler or through use of VAR/READONLY parameters. So, the pointer values from the stack themselves need not be aligned. The PointerAlignment tells the collector at what alignment to expect to find pointers stored in the stack. Some compilers/targets may not require that pointer-valued fields in the stack be stored at aligned locations. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 5 Apr 2010, at 08:03, Jay K wrote: hm I guess pointers themselves (not where they are stored) need not have any alignemnt? We might only have a pointer into an array of bytes to keep the array alive, no pointer to the base of the array? PROCEDURE F1() VAR a: ARRAY OF CHAR := NEW(CHAR, 10); i: INTEGER; BEGIN FOR i := FIRST(a) TO LAST(a) DO something with a[i]; END END F1; might only have pointers to elements in a? - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Mon, 5 Apr 2010 11:55:16 +0000 Subject: Re: [M3devel] RTMachine.PointerAlignment = 1 on NT? Interesting: PROCEDURE NoteStackLocations (start, stop: ADDRESS) = VAR fp : UNTRACED REF ADDRESS := start; BEGIN IF NOT (start < stop) THEN RETURN END; stop := stop - ADRSIZE (ADDRESS); (* so we don't overrun the valid addresses *) WHILE fp <= stop DO (* with the memory read on the next line. *) WITH page = AddressToPage(fp^) DO IF page # NIL AND page.desc.space = Space.Previous THEN IF RTMachine.PointerAlignment = 1 THEN IF Word.And(LOOPHOLE(fp, INTEGER), BYTESIZE(INTEGER) - 1) # 0 THEN RTIO.PutText("pointer found on unaligned stack stack="); RTIO.PutAddr(fp); RTIO.PutText(" addr="); RTIO.PutAddr(fp^); RTIO.PutText("\n"); RTIO.Flush(); END; END; IF page.desc.pure THEN PromotePage(page, PromoteReason.AmbiguousPure); ELSE PromotePage(page, PromoteReason.AmbiguousImpure); END; END; END; INC(fp, RTMachine.PointerAlignment); END; END NoteStackLocations; generates a fair amount of output: C:\dev2\cm3.2\m3-sys\mklib>cm3 --- building in NT386 --- ignoring ..\src\m3overrides pointer found on unaligned stack stack=0x12f3d2 addr=0x1400000 pointer found on unaligned stack stack=0x12f11e addr=0x1400000 pointer found on unaligned stack stack=0x12f186 addr=0x1400000 pointer found on unaligned stack stack=0x12f12e addr=0x1780000 pointer found on unaligned stack stack=0x12f1ba addr=0x1400000 pointer found on unaligned stack stack=0x12f442 addr=0x1460147 new source -> compiling Main.m3 pointer found on unaligned stack stack=0x12f3d2 addr=0x1400000 -> linking mklib.exe I need to look a bit more, see what these values are. We are probably being way over conservative, on NT. Such unaligned values as 0x1460147 surely shouldn't count as traced pointers. This example only has one but usually I see many more. C:\dev2\cm3.2\m3-sys\cm3>cm3 --- building in NT386 --- ignoring ..\src\m3overrides pointer found on unaligned stack stack=0x12f3d2 addr=0x1400000 pointer found on unaligned stack stack=0x12f642 addr=0x1400000 pointer found on unaligned stack stack=0x12f176 addr=0x1400000 pointer found on unaligned stack stack=0x12f11e addr=0x1400000 pointer found on unaligned stack stack=0x12f12a addr=0x1780000 pointer found on unaligned stack stack=0x12f1b6 addr=0x1400000 pointer found on unaligned stack stack=0x12f61e addr=0x1400000 pointer found on unaligned stack stack=0x12f6de addr=0x1900069 pointer found on unaligned stack stack=0x12f43e addr=0x1400000 pointer found on unaligned stack stack=0x12f156 addr=0x1400000 pointer found on unaligned stack stack=0x12f66e addr=0x1400000 pointer found on unaligned stack stack=0x12f72e addr=0x1900069 pointer found on unaligned stack stack=0x12f792 addr=0x1cc0000 pointer found on unaligned stack stack=0x12fb26 addr=0x1d7015c pointer found on unaligned stack stack=0x12fb52 addr=0x1d90142 All this scanning around in memory the garbage collector has to do, doesn't that kill working set? It makes all heap and stack part of the working set? Even if I'm not going to access it for long periods? - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Mon, 5 Apr 2010 11:41:10 +0000 Subject: [M3devel] RTMachine.PointerAlignment = 1 on NT? For the vast majority of platforms: RTMachine.PointerAlignment = BYTESIZE(INTEGER). except 1 for NT386, 2 for M68K (dead). PointerAlignment = BYTESIZE(INTEGER); (* The C compiler allocates all pointers on 'PointerAlignment'-byte boundaries. The garbage collector scans thread stacks, but only looks at these possible pointer locations. Setting this value smaller than is needed will only make your system run slower. Setting it too large will cause the collector to collect storage that is not free. *) I suggest this is not exactly true. 1) Of what relevance is the C compiler? vs. the Modula-3 compiler. 2) We really think the number is 1 for NT386? I understand I could say: void F(void* traced) { #pragma pack(1) struct { char a; void* p} = {0, traced}; } but 1) That seems highly unlikely. 2) Do we really anticipate the case where C code is the *only* holder of a traced reference? And more so, it wasn't a parameter to the C code -- the location of parameters is controlled by Modula-3, assuming a pointer-aligned stack. 3) Can't we know/assume/verify that Modula-3 code only stores pointers at more aligned location? My real goal is to make there only be one RTMachine for systems that don't have stack walkers. Leave SOLgnu/SOLsun alone. (Later on implement stack walking for many platforms via libunwind.) There are I believe only two differences to iron out. Allocation size (8K vs. 64K) and PointerAlignment (1 vs. BYTESIZE(INTEGER)). There is a reason for NT to be 64K allocation size -- that is what VirtualAlloc uses. I can test 64K on others. Historically smaller is probably more efficient. These days larger but not *too* large is probably more efficient. 64K should work fine on all platforms. Heck, even something larger like 1MB is probably good. I'll test out 64K. Can/should we have "paranoidgc" imply PointerAlignment = 1, and report whenever a pointer is found at a location with alignment less than BYTESIZE(pointer)? A form of this is reasonable today, right? If PointerAligment = 1, I can have it report any found at less than BYTESIZE(pointer), test it a while, if none found, elevate NT386 to that value? If any found, that'll help educate me/us on why it is 1, and maybe how to change it, or why leave it alone. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Apr 6 02:38:19 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 6 Apr 2010 00:38:19 +0000 Subject: [M3devel] lock performance, random thoughts In-Reply-To: References: <1270510533.10280.32.camel@faramir.m3w.org>, , <1F5A794A-40AB-4F94-B11A-9218DAA30ED4@cs.purdue.edu>, , <1270511827.10280.37.camel@faramir.m3w.org>, Message-ID: > pthread_mutex_lock/unlock does not imply a kernel call. ! > pthreads can synchronize in usermode just as well (or only almost as well?) as Tony's design. > Only upon contention is a kernel call needed, in both. Without the extra biasing and avoiding atomic ops, I believe it goes something like: typedef struct recursive_exclusive_lock_t { long owner; long count = -1; /* -1 for 386 compat, else 0 is ok and adjust below */ void* kernel object; /* may or may not initialize this up front or on demand, if on demand, beware low resources in the middle of locking */ } recursive_exclusive_lock_t; recursive_exclusive_lock: while (1) new_count = InterlockedIncrement(count); if new_count == 0 /* 1 for 486+, allows for zero initialization */ owner = current thread return if new_count > 0 /* 1 for 486+, allows for zero initialization */ if owner == current thread id return InterlockedDecrement(count); maybe an extra brief spin here on MP systems, in case contention is very short wait on kernel object recursive_exclusive_unlock: assert(owner == current thread id) InterlockedDecrement(count); typedef struct exclusive_lock_t { long owner; void* kernel object; } exclusive_lock_t; exclusive_lock: while (1) if interlocked compare exchange(owner, 0, current thread id) == 0 return maybe an extra brief spin here on MP systems, in case contention is very short wait on kernel object exclusive_unlock: assert(owner == current thread id) owner = 0 The first resembles Win32 critical sections. The second is what the Sun Java VM does on Win32. kernel_lock is a Win32 event. I had that in Modula-3 but only briefly. No kernel call in uncontended cases. But still atomics. - Jay From: jay.krell at cornell.edu To: dragisha at m3w.org; hosking at cs.purdue.edu Date: Tue, 6 Apr 2010 00:13:07 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] lock performance, random thoughts pthread_mutex_lock/unlock does not imply a kernel call. ! pthreads can synchronize in usermode just as well (or only almost as well?) as Tony's design. Only upon contention is a kernel call needed, in both. That's not to say that everyone implements this well. Linux does. Win32 does. The others I don't know. Also Tony avoids even atomic operations often. I'm not sure how others compare there. I'm just referring to kernel/syscalls. Are they really so terrible? - Jay > From: dragisha at m3w.org > To: hosking at cs.purdue.edu > Date: Tue, 6 Apr 2010 01:57:07 +0200 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] lock performance, random thoughts > > I've used Java for one project, "GUI" app frontend for mobile phones... > What I saw first was their mixup of mutex/condition/cheese in single > root object... But, ok... offtopic there :) > > What I think is important about whole idea is it's simplicity and > (almost) obvious efficiency. It also needs nothing fancy (not today, at > least) and nothing maybe-it-works to implement. Nothing comparable to > early implementations of kernel space threading/thread suspending for > gc/... > > Any takers? :) > > > On Mon, 2010-04-05 at 19:45 -0400, Tony Hosking wrote: > > Yes, that's pretty much what modern Java implementations do. > > > > > -- > Dragi?a Duri? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Apr 6 03:21:03 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 5 Apr 2010 21:21:03 -0400 Subject: [M3devel] RTMachine.PointerAlignment = 1 on NT? In-Reply-To: References: , , , , , , , , <76C0DE79-7904-49B4-AE3F-83632B48CFDD@cs.purdue.edu>, , , , , , Message-ID: <141A7DFE-839D-4DD6-B8B4-934476DAE9A6@cs.purdue.edu> Fair enough. That says it should be ADRSIZE(ADDRESS). ;-) On 5 Apr 2010, at 20:20, Jay K wrote: > Isn't this kind of "architectural"? > Like, assumed in a bunch of code, too hard to change, better to adhere to than change? > Can continue to write code assuming it. > > > Consider AMD64_NT. > I assume INTEGER there should be 64bits, even though int and long are both 32. > Corralary: long shouldn't be used for anything, ever. > int is 32 bits, always; ignoring old systems > INTEGER is pointer size, always (the question here) > long is sometimes 32 bits, sometimes pointer size, but neither is always true, on modern systems > If you consider Win64. If you ignore Win64, then, yes, I realize, long is always a pointer. > The types to use in C for pointer sized integers are size_t and ptrdiff_t. > > > For that matter..BYTESIZE and ADRSIZE, they are always the same and will always be, right? > "All machines are byte-addressable", these days and forever more? > > > - Jay > > > From: hosking at cs.purdue.edu > Date: Mon, 5 Apr 2010 19:44:02 -0400 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] RTMachine.PointerAlignment = 1 on NT? > > Same thing only for implementations where BYTESIZE(Word.T) = BYTESIZE(INTEGER) = BYTESIZE(ADDRESS). But that's all of ours. > > On 5 Apr 2010, at 18:03, Jay K wrote: > > Yes. Same thing. > > - Jay > > From: hosking at cs.purdue.edu > Date: Mon, 5 Apr 2010 13:31:45 -0400 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] RTMachine.PointerAlignment = 1 on NT? > > More accurately, BYTESIZE(ADDRESS)? > > Antony Hosking | Associate Professor | Computer Science | Purdue University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > On 5 Apr 2010, at 10:40, Jay K wrote: > > I think we can safely dispense with RTMachine.PointerAlignment and use BYTESIZE(INTEGER). > NT386 is the only current exception. > Even though it isn't required, of any x86 target, it seems the overwhelming practice. > > - Jay > > Subject: Re: [M3devel] RTMachine.PointerAlignment = 1 on NT? > From: hosking at cs.purdue.edu > Date: Mon, 5 Apr 2010 10:25:20 -0400 > CC: m3devel at elegosoft.com > To: jay.krell at cornell.edu > > Yes, correct. Pointers from the stacks may be "derived" from object base references by the compiler or through use of VAR/READONLY parameters. So, the pointer values from the stack themselves need not be aligned. The PointerAlignment tells the collector at what alignment to expect to find pointers stored in the stack. Some compilers/targets may not require that pointer-valued fields in the stack be stored at aligned locations. > > > > Antony Hosking | Associate Professor | Computer Science | Purdue University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > On 5 Apr 2010, at 08:03, Jay K wrote: > > hm I guess pointers themselves (not where they are stored) need not have any alignemnt? > We might only have a pointer into an array of bytes to keep the array alive, > no pointer to the base of the array? > > PROCEDURE F1() > VAR a: ARRAY OF CHAR := NEW(CHAR, 10); > i: INTEGER; > BEGIN > FOR i := FIRST(a) TO LAST(a) DO > something with a[i]; > END > END F1; > > might only have pointers to elements in a? > > - Jay > > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Mon, 5 Apr 2010 11:55:16 +0000 > Subject: Re: [M3devel] RTMachine.PointerAlignment = 1 on NT? > > Interesting: > > PROCEDURE NoteStackLocations (start, stop: ADDRESS) = > VAR fp : UNTRACED REF ADDRESS := start; > BEGIN > IF NOT (start < stop) THEN RETURN END; > stop := stop - ADRSIZE (ADDRESS); (* so we don't overrun the valid addresses *) > WHILE fp <= stop DO (* with the memory read on the next line. *) > WITH page = AddressToPage(fp^) DO > IF page # NIL AND page.desc.space = Space.Previous THEN > IF RTMachine.PointerAlignment = 1 THEN > IF Word.And(LOOPHOLE(fp, INTEGER), BYTESIZE(INTEGER) - 1) # 0 THEN > RTIO.PutText("pointer found on unaligned stack stack="); > RTIO.PutAddr(fp); > RTIO.PutText(" addr="); > RTIO.PutAddr(fp^); > RTIO.PutText("\n"); > RTIO.Flush(); > END; > END; > IF page.desc.pure > THEN PromotePage(page, PromoteReason.AmbiguousPure); > ELSE PromotePage(page, PromoteReason.AmbiguousImpure); > END; > END; > END; > INC(fp, RTMachine.PointerAlignment); > END; > END NoteStackLocations; > > > generates a fair amount of output: > > > C:\dev2\cm3.2\m3-sys\mklib>cm3 > --- building in NT386 --- > ignoring ..\src\m3overrides > pointer found on unaligned stack stack=0x12f3d2 addr=0x1400000 > pointer found on unaligned stack stack=0x12f11e addr=0x1400000 > pointer found on unaligned stack stack=0x12f186 addr=0x1400000 > pointer found on unaligned stack stack=0x12f12e addr=0x1780000 > pointer found on unaligned stack stack=0x12f1ba addr=0x1400000 > pointer found on unaligned stack stack=0x12f442 addr=0x1460147 > new source -> compiling Main.m3 > pointer found on unaligned stack stack=0x12f3d2 addr=0x1400000 > -> linking mklib.exe > > > I need to look a bit more, see what these values are. > We are probably being way over conservative, on NT. > Such unaligned values as 0x1460147 surely shouldn't count as traced pointers. > This example only has one but usually I see many more. > > > C:\dev2\cm3.2\m3-sys\cm3>cm3 > --- building in NT386 --- > ignoring ..\src\m3overrides > pointer found on unaligned stack stack=0x12f3d2 addr=0x1400000 > pointer found on unaligned stack stack=0x12f642 addr=0x1400000 > pointer found on unaligned stack stack=0x12f176 addr=0x1400000 > pointer found on unaligned stack stack=0x12f11e addr=0x1400000 > pointer found on unaligned stack stack=0x12f12a addr=0x1780000 > pointer found on unaligned stack stack=0x12f1b6 addr=0x1400000 > pointer found on unaligned stack stack=0x12f61e addr=0x1400000 > pointer found on unaligned stack stack=0x12f6de addr=0x1900069 > pointer found on unaligned stack stack=0x12f43e addr=0x1400000 > pointer found on unaligned stack stack=0x12f156 addr=0x1400000 > pointer found on unaligned stack stack=0x12f66e addr=0x1400000 > pointer found on unaligned stack stack=0x12f72e addr=0x1900069 > pointer found on unaligned stack stack=0x12f792 addr=0x1cc0000 > pointer found on unaligned stack stack=0x12fb26 addr=0x1d7015c > pointer found on unaligned stack stack=0x12fb52 addr=0x1d90142 > > > All this scanning around in memory the garbage collector has to do, doesn't that kill working set? > It makes all heap and stack part of the working set? Even if I'm not going to access it for long periods? > > > - Jay > > > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Mon, 5 Apr 2010 11:41:10 +0000 > Subject: [M3devel] RTMachine.PointerAlignment = 1 on NT? > > For the vast majority of platforms: > > > RTMachine.PointerAlignment = BYTESIZE(INTEGER). > > > except 1 for NT386, 2 for M68K (dead). > > > PointerAlignment = BYTESIZE(INTEGER); > (* The C compiler allocates all pointers on 'PointerAlignment'-byte > boundaries. The garbage collector scans thread stacks, but only > looks at these possible pointer locations. Setting this value > smaller than is needed will only make your system run slower. > Setting it too large will cause the collector to collect storage > that is not free. *) > > > I suggest this is not exactly true. > 1) Of what relevance is the C compiler? vs. the Modula-3 compiler. > 2) We really think the number is 1 for NT386? > > I understand I could say: > void F(void* traced) > { > #pragma pack(1) > struct { char a; void* p} = {0, traced}; > } > > but > 1) That seems highly unlikely. > 2) Do we really anticipate the case where C code is the *only* holder of a traced reference? > And more so, it wasn't a parameter to the C code -- the location of parameters is controlled by Modula-3, assuming a pointer-aligned stack. > 3) Can't we know/assume/verify that Modula-3 code only stores pointers at more aligned location? > > > My real goal is to make there only be one RTMachine for systems that don't have stack walkers. > Leave SOLgnu/SOLsun alone. > (Later on implement stack walking for many platforms via libunwind.) > > > There are I believe only two differences to iron out. Allocation size (8K vs. 64K) and PointerAlignment (1 vs. BYTESIZE(INTEGER)). > There is a reason for NT to be 64K allocation size -- that is what VirtualAlloc uses. > I can test 64K on others. > Historically smaller is probably more efficient. > These days larger but not *too* large is probably more efficient. > 64K should work fine on all platforms. Heck, even something larger like 1MB is probably good. > I'll test out 64K. > > > Can/should we have "paranoidgc" imply PointerAlignment = 1, and report whenever a pointer is found at a location with alignment less than BYTESIZE(pointer)? > > > A form of this is reasonable today, right? If PointerAligment = 1, I can have it report any found at less than BYTESIZE(pointer), test it a while, if none found, elevate NT386 to that value? > If any found, that'll help educate me/us on why it is 1, and maybe how to change it, or why leave it alone. > > > - Jay > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Wed Apr 7 20:56:54 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Wed, 7 Apr 2010 14:56:54 -0400 Subject: [M3devel] RTMachine.PointerAlignment = 1 on NT? In-Reply-To: References: Message-ID: <20100407185654.GA29570@topoi.pooq.com> On Mon, Apr 05, 2010 at 11:41:10AM +0000, Jay K wrote: > > For the vast majority of platforms: > > > > > > RTMachine.PointerAlignment = BYTESIZE(INTEGER). > > > > > > except 1 for NT386, 2 for M68K (dead). > > > > > > PointerAlignment = BYTESIZE(INTEGER); > (* The C compiler allocates all pointers on 'PointerAlignment'-byte > boundaries. The garbage collector scans thread stacks, but only > looks at these possible pointer locations. Setting this value > smaller than is needed will only make your system run slower. > Setting it too large will cause the collector to collect storage > that is not free. *) > > > > > I suggest this is not exactly true. > > 1) Of what relevance is the C compiler? vs. the Modula-3 compiler. The C compiler is not that relevant. What is relevant is possible other languages that might want to share a garbage collector. I dream of the day when multilanguage programming can be done cleanly for other than the malloc/free kinds of languages. The one big problem with garbage-collected languages at the moment is that they interwork very poorly because they have incompatible storage layouts. Let's not make it harder than necessary. As far as I know, most allocate pointers on pointer-sized boundaries. But pointers may point into objects as well as to them, not necessarily at nice boundaries. -- hendrik From jay.krell at cornell.edu Tue Apr 6 07:31:39 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 6 Apr 2010 05:31:39 +0000 Subject: [M3devel] RTMachine.PointerAlignment = 1 on NT? In-Reply-To: <20100407185654.GA29570@topoi.pooq.com> References: , <20100407185654.GA29570@topoi.pooq.com> Message-ID: > I dream of the day when multilanguage programming can be done cleanly > for other than the malloc/free kinds of languages. The point of .NET, eh? > The one big problem with garbage-collected languages at the moment is > that they interwork very poorly because they have incompatible storage > layouts. "storage layout"? Isn't that kind of underselling it? Seems to me these things encompass like the whole system. You either play into it or you don't. There is a bit of a pick and chose option as I understand, like with "managed C++" you can have native code instead of IL+JIT. Seems to me, syntax isn't all that interesting, but libraries and runtimes are. Syntax matters to the extent that editor supports it. While .NET may support various syntaxes, the point is really to use the one and only runtime and library. You might as well just use C#. Mono works fairly well. Imho. ..Jay > Date: Wed, 7 Apr 2010 14:56:54 -0400 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] RTMachine.PointerAlignment = 1 on NT? > > On Mon, Apr 05, 2010 at 11:41:10AM +0000, Jay K wrote: > > > > For the vast majority of platforms: > > > > RTMachine.PointerAlignment = BYTESIZE(INTEGER). > > > > except 1 for NT386, 2 for M68K (dead). > > > > PointerAlignment = BYTESIZE(INTEGER); > > (* The C compiler allocates all pointers on 'PointerAlignment'-byte > > boundaries. The garbage collector scans thread stacks, but only > > looks at these possible pointer locations. Setting this value > > smaller than is needed will only make your system run slower. > > Setting it too large will cause the collector to collect storage > > that is not free. *) > > > > I suggest this is not exactly true. > > > > 1) Of what relevance is the C compiler? vs. the Modula-3 compiler. > > The C compiler is not that relevant. What is relevant is possible other > languages that might want to share a garbage collector. > > I dream of the day when multilanguage programming can be done cleanly > for other than the malloc/free kinds of languages. > > The one big problem with garbage-collected languages at the moment is > that they interwork very poorly because they have incompatible storage > layouts. > > Let's not make it harder than necessary. > > As far as I know, most allocate pointers on pointer-sized boundaries. > But pointers may point into objects as well as to them, not necessarily > at nice boundaries. > > -- hendrik -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Tue Apr 6 08:14:40 2010 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Tue, 06 Apr 2010 08:14:40 +0200 Subject: [M3devel] lock performance, random thoughts (also current cvsup situation) In-Reply-To: <1F5A794A-40AB-4F94-B11A-9218DAA30ED4@cs.purdue.edu> References: <1270510533.10280.32.camel@faramir.m3w.org> <1F5A794A-40AB-4F94-B11A-9218DAA30ED4@cs.purdue.edu> Message-ID: <1270534480.10280.43.camel@faramir.m3w.org> It's good to read more about subject, which is what I usually do after some tabula rasa thinking on it :). It looks like Linux has optimized this for some time now. Bias by way of very fast operation in uncontended cases. What is current m3devel decision on this? And how I (with Linux and only Linux) can feel this slowdown in cvsup at all? Is it because Elego rebuild cvsupd and is not using Linux server-side?? On Mon, 2010-04-05 at 19:45 -0400, Tony Hosking wrote: > Yes, that's pretty much what modern Java implementations do. -- Dragi?a Duri? From jay.krell at cornell.edu Tue Apr 6 08:41:39 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 6 Apr 2010 06:41:39 +0000 Subject: [M3devel] lock performance, random thoughts (also current cvsup situation) In-Reply-To: <1270534480.10280.43.camel@faramir.m3w.org> References: <1270510533.10280.32.camel@faramir.m3w.org>, <1F5A794A-40AB-4F94-B11A-9218DAA30ED4@cs.purdue.edu>, <1270534480.10280.43.camel@faramir.m3w.org> Message-ID: I don't quite understand your question. I'll answer related things. Do you know notice the slow down in cvsup/cvsupd? I do. But I'm curious if it is just me. Everything except OpenBSD uses pthreads in cm3. Which I believe are always kernel threads though don't know 100%. (FreeBSD? NetBSD?) OpenBSD always uses user threads. Its pthreads are user threads and don't work well enough for us. Always pthreads: Unless you do something "special" -- rebuild with cm3 -DUSER_THREADS or such -- I edit m3core/src/thread.quake, since I don't have support for passing extra parameters around from scripts, dumb, I know. The code I showed is not what Modula-3 does. We just call pthread_lock_mutex. It is what pthread_lock_mutex should look like. Or perhaps something even better, but it is a simple efficient start. We don't inline the locking, which Tony is keen on doing. I don't think we inline for user threads locking either though. Inline is often very good, but I don't know if it would be significant here. Some profiling is probably in order. You? had said that pthread_self or pthread_getspecific/set were showing in profiling? Some kernel calls where? I don't believe any of those three are kernel calls, nor as well that pthread_lock_mutex is without contention. We call self/getspecific/setspecific too often. But they should be fairly fast. There is an approximate plan to improve this post-release -- use libunwind. Again, maybe some profiling is in order. Maybe just of hello world? I'd have to test hello world user threads and kernel threads. See if it is noticably different. Again, cvsup/cvsupd it is very noticable the speed of userthreads vs. kernelthreads. Heck, it maybe isn't even threads. Maybe it is just startup/shutdown. - Jay > From: dragisha at m3w.org > To: hosking at cs.purdue.edu > Date: Tue, 6 Apr 2010 08:14:40 +0200 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] lock performance, random thoughts (also current cvsup situation) > > It's good to read more about subject, which is what I usually do after > some tabula rasa thinking on it :). > > It looks like Linux has optimized this for some time now. Bias by way of > very fast operation in uncontended cases. > > What is current m3devel decision on this? And how I (with Linux and only > Linux) can feel this slowdown in cvsup at all? Is it because Elego > rebuild cvsupd and is not using Linux server-side?? > > On Mon, 2010-04-05 at 19:45 -0400, Tony Hosking wrote: > > Yes, that's pretty much what modern Java implementations do. > > -- > Dragi?a Duri? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Wed Apr 7 05:30:38 2010 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Wed, 7 Apr 2010 03:30:38 +0000 (GMT) Subject: [M3devel] lock performance, random thoughts In-Reply-To: Message-ID: <694635.45812.qm@web23602.mail.ird.yahoo.com> Hi all: I remember that someone inside Acorn reported their use was overwhelming if running in user mode and gave an interesting idea about that in terms of operating system development. They wrote a huge amount of Modula-2+ code even with GUI in Acorn (Olivetti) for the Acorn Archimedes workstation in middle end eighties for its development As the language primitives were the same in use at DEC SRC I guess they didn't consider the language as the problem, but a machine architecture lack of performance factor and in turn affect programs performance by itself. However this got into the development of the ARM architecture introduced since then for the Archimedes ARM and the OS itself. http://lists.cloud9.co.uk/pipermail/bbc-micro/2010-January/007795.html http://www.chiark.greenend.org.uk/~theom/riscos/docs/ultimate/a252swp.txt As a new operating system belongs to a new era the SPIN OS was ahead of its time in terms of performance improvements and no been hit by itself (in terms of performance) which was not an issue because of its nature of safety but still they addressed the use of other operating system code at the operating system level which of course gave problems of performance? but didn't? play a important issue by itself as non safe code could be extra checked or run in space of kernel with no user rights to modify heap allocated space or if not needed to be run in kernel space as a client of an extern library OS in user space with no use in kernel space IMO both approaches either hardware level and operating system level have pros and cons as the operating system level threading is a plus nowadays in multi threaded programs running on multi core equipped hardware but in most cases the use of it could be not a winning situation because not all hardware by its own is multi core in new computer Minis (net books) or systems run in hardware assisted virtualization and not to forget old machines which in most cases can run many applications no multi threaded of today like we use in normal with no performance improvement in new ones on tasks which may no benefit of the extra hardware that may still have at hand so there could be a balance that could benefit most of all cases. Therefore not to say that we may suck user level threading but still considering as a important part of it and needing a new development for the cases of lack of performance an improvement over the cases it lacks and better use of the better hardware like in Acorn did use of the new development to aid it. Probably the best solution is a matter of match between the underlying hardware with proper system-level handling of it to best performance and less penalty in favour of the language developer and final user just to get easier of development and performance gain solution. ?? My vote for operating system level threading (i.e of SPIN) if lacks of performance of faster user threading as a solution for the performance hit problems and user level threading for the systems with no gain over it? so we may gain of language and hardware capabilities to extract the best of both. --- El lun, 5/4/10, Jay K escribi?: De: Jay K Asunto: Re: [M3devel] lock performance, random thoughts Para: dragisha at m3w.org, "Tony" CC: "m3devel" Fecha: lunes, 5 de abril, 2010 19:13 pthread_mutex_lock/unlock does not imply a kernel call. ! pthreads can synchronize in usermode just as well (or only almost as well?) as Tony's design. Only upon contention is a kernel call needed, in both. ? ? That's not to say that everyone implements this well. Linux does. Win32 does. The others I don't know. ? ? Also Tony avoids even atomic operations often. I'm not sure how others compare there. I'm just referring to kernel/syscalls. Are they really so terrible? ? ? ?- Jay ? > From: dragisha at m3w.org > To: hosking at cs.purdue.edu > Date: Tue, 6 Apr 2010 01:57:07 +0200 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] lock performance, random thoughts > > I've used Java for one project, "GUI" app frontend for mobile phones... > What I saw first was their mixup of mutex/condition/cheese in single > root object... But, ok... offtopic there :) > > What I think is important about whole idea is it's simplicity and > (almost) obvious efficiency. It also needs nothing fancy (not today, at > least) and nothing maybe-it-works to implement. Nothing comparable to > early implementations of kernel space threading/thread suspending for > gc/... > > Any takers? :) > > > On Mon, 2010-04-05 at 19:45 -0400, Tony Hosking wrote: > > Yes, that's pretty much what modern Java implementations do. > > > > > -- > Dragi?a Duri? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Highjinks at gmx.com Wed Apr 7 22:09:27 2010 From: Highjinks at gmx.com (Chris) Date: Wed, 7 Apr 2010 22:09:27 +0200 (CEST) Subject: [M3devel] lock performance, random thoughts In-Reply-To: <694635.45812.qm@web23602.mail.ird.yahoo.com> References: <694635.45812.qm@web23602.mail.ird.yahoo.com> Message-ID: <20100407161333.014d6539.Highjinks@gmx.com> As I've said before, this really has NOTHING to do with user/kernel level threading. It's all about synchronization. The only thing a user level thread offers is the possibility to completely avoid context switches, such as is common in a State Machine/Automata. You could also approach it as a Direct Threaded environment, as is common in many Forth implementations. Look at pthreads read and write barriers. Look at http://www-sop.inria.fr/meije/rp/LOFT/ This is a tool which comfortably integrates both Kernel Space and User Space threads into a whole. In general the Synchronous Model(typically implemented as user space threads, due to lack of Kernel support) will typically be much faster when doing interactive and multimedia programming. The Asynchronous model(typically done as Kernel Space threads) will usually be faster at Batch processing. You can do both with Posix Threads. No need to limit the environment exclusively to one or the other. A mixed model provides the best flexibility. -- Chris From dragisha at m3w.org Thu Apr 8 00:06:29 2010 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Thu, 08 Apr 2010 00:06:29 +0200 Subject: [M3devel] lock performance, random thoughts In-Reply-To: <20100407161333.014d6539.Highjinks@gmx.com> References: <694635.45812.qm@web23602.mail.ird.yahoo.com> <20100407161333.014d6539.Highjinks@gmx.com> Message-ID: <1270677989.3816.7.camel@faramir.m3w.org> It's all about synchronization in kernel space, ie part of it when it comes to kernel space through syscalls. Context switching is lesser problem as it is what happens a lot less often than synchronization. Synchronization problem is with systems which are, unlike Linux, doing syscalls on every pthread_mutex_lock and friends. Hybridization of thread system (mixing user and kernel threads) is done talk and I hope nobody takes such thing seriously anymore. On Wed, 2010-04-07 at 22:09 +0200, Chris wrote: > As I've said before, this really has NOTHING to do with user/kernel > level threading. It's all about synchronization. -- Dragi?a Duri? From jay.krell at cornell.edu Thu Apr 8 02:39:05 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 8 Apr 2010 00:39:05 +0000 Subject: [M3devel] lock performance, random thoughts In-Reply-To: <1270677989.3816.7.camel@faramir.m3w.org> References: , <694635.45812.qm@web23602.mail.ird.yahoo.com>, <20100407161333.014d6539.Highjinks@gmx.com>, <1270677989.3816.7.camel@faramir.m3w.org> Message-ID: uncontended pthread_mutex_lock/unlock: syscall on FreeBSD? Solaris? NetBSD? Darwin? Not on Linux. I really doubt on Solaris. Ditto pthread_self, pthread_getspecific, pthread_setspecific? (Though I don't believe we call them frequently on Solaris, and I have a very rough plan to reduce them *later* -- libunwind.) - Jay > From: dragisha at m3w.org > To: Highjinks at gmx.com > Date: Thu, 8 Apr 2010 00:06:29 +0200 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] lock performance, random thoughts > > It's all about synchronization in kernel space, ie part of it when it > comes to kernel space through syscalls. > > Context switching is lesser problem as it is what happens a lot less > often than synchronization. > > Synchronization problem is with systems which are, unlike Linux, doing > syscalls on every pthread_mutex_lock and friends. > > Hybridization of thread system (mixing user and kernel threads) is done > talk and I hope nobody takes such thing seriously anymore. > > On Wed, 2010-04-07 at 22:09 +0200, Chris wrote: > > As I've said before, this really has NOTHING to do with user/kernel > > level threading. It's all about synchronization. > -- > Dragi?a Duri? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Apr 9 12:04:16 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 9 Apr 2010 10:04:16 +0000 Subject: [M3devel] gcc atomics supported ordering? Message-ID: Tony I thought you recently said all memory orderings are supported by the gcc backend with atomics. But there is still: jbook2:m3cg jay$ grep Relaxed * parse.c:typedef enum { Relaxed, Release, Acquire, AcquireRelease, Sequential } O rder; parse.c: if (order != Relaxed) parse.c: warning (0, "only Relaxed memory order for stores is supported"); parse.c: if (order != Relaxed) parse.c: warning (0, "only Relaxed memory order for loads is supported"); - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Apr 9 12:52:09 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 9 Apr 2010 10:52:09 +0000 Subject: [M3devel] ROUND vs. FLOOR in ThreadPThread.m3 nano vs. micro time conversions? Message-ID: Why does UTimeFromTime use FLOOR but ToNTime uses ROUND? PROCEDURE ToNTime (n: LONGREAL; VAR ts: Utime.struct_timespec) = BEGIN ts.tv_sec := TRUNC(n); ts.tv_nsec := ROUND((n - FLOAT(ts.tv_sec, LONGREAL)) * 1.0D9); END ToNTime; TYPE UTime = Utime.struct_timeval; PROCEDURE UTimeFromTime (time: Time.T): UTime = VAR floor := FLOOR(time); BEGIN RETURN UTime{floor, FLOOR(1.0D6 * (time - FLOAT(floor, LONGREAL)))}; END UTimeFromTime; I've changed this code to pass doubles to C and do the conversion there. To reduce/eliminate use of cloned headers. For ROUND I'm using C99: /* C99, very portable */ long lround(double); long long llround(double); #ifdef __CYGWIN__ #define ROUND lround #else #define ROUND llround #endif typedef double FloatSeconds, LONGREAL; typedef struct timeval MicrosecondsStruct_t; #define FLOAT(value, type) ((type)value) #define FLOOR floor static MicrosecondsStruct_t* FloatSecondsToNanosecondsStruct(LONGREAL n, MicrosecondsStruct_t* ts) { ts->tv_sec = (time_t)n; ts->tv_nsec = ROUND((n - FLOAT(ts->tv_sec, LONGREAL)) * 1.0E9); return ts; } static MicrosecondsStruct_t* FloatSecondsToMicrosecondsStruct(FloatSeconds timeout, MicrosecondsStruct_t* utime) { LONGINT sec = FLOOR(timeout); utime->tv_sec = (time_t)sec; utime->tv_usec = (suseconds_t)FLOOR(1.0E6 * (timeout - FLOAT(sec, LONGREAL))); return utime; } Just arbitrarily a little more correct in the nano case vs. the micro case? Matters little? Would matter more for micro due to lower resolution? Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Apr 9 19:01:19 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 9 Apr 2010 13:01:19 -0400 Subject: [M3devel] gcc atomics supported ordering? In-Reply-To: References: Message-ID: Never said any such thing. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 9 Apr 2010, at 06:04, Jay K wrote: > Tony I thought you recently said all memory orderings are supported by the gcc backend with atomics. > But there is still: > > jbook2:m3cg jay$ grep Relaxed * > parse.c:typedef enum { Relaxed, Release, Acquire, AcquireRelease, Sequential } O > rder; > parse.c: if (order != Relaxed) > parse.c: warning (0, "only Relaxed memory order for stores is supported"); > parse.c: if (order != Relaxed) > parse.c: warning (0, "only Relaxed memory order for loads is supported"); > > - Jay > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Apr 11 07:08:07 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 11 Apr 2010 05:08:07 +0000 Subject: [M3devel] m3core/unix directions Message-ID: m3core/unix directions My intent here is to further reduce platform dependencies and header cloning. I know there isn't much left, but there is some. In particular: eliminate struct_timespec (done) eliminate struct_timeval (partly done, more to do) implies eliminating select wrapper implies eliminating gettimeofday wrapper eliminate MAX_FDSET Though there is a possible bug workaround in m3core, that Interix's header is wrong. eliminate time_t (I'd also like to find some way to get 64bit time_t everywhere, though my research so far says it isn't available) eliminate struct_tm Mainly used by m3core/src/time. As well as fix m3-mail/webcard, m3-mail/postcard which have crashing bugs due to declaring their own form. eliminate struct_sockaddr_in maybe eliminate struct_sockaddr_un (I know it was requested) eliminate all of the Usysdep.i3 files (MAX_FDSET, struct_tm) maybe eliminate ioctl/fcntl; there are precious few uses; is the Solaris bug workaround for them needed? That bug workaround is a good reason to keep the wrappers. maybe eliminate stat; there there again there are interesting bug workarounds in the wrappers, the incorrect headers I had for Darwin/arm maybe reduce what all m3core/src/unix provides/wraps, leave it to the clients; however to the extent that they are just const char* and int, probably ok to just leave asis (e.g. open/read/write/close) I'm not sure I'll succeed at all of this, but each step I believe has value. General strategy is to push C up one level. Pass around types that we have complete control of. There is always C below the Posix ports of Modula-3, as well as the Win32/NT port. It is "just" a matter at where the line is. A hypothetical Modula-3 "OS" wouldn't necessarily use any of this C, if it provided m3core/libm3/tcp directly. btw, here's a likely example of the bugs these patterns have caused: C:\dev2\cm3.2\m3-www\http\src\AppBackup.m3(77):(* Nov 16: file.lock broken in call to fcntl - int vs. long confusion C:\dev2\cm3.2\m3-www\http\src\AppBackup.m3(103):(* Nov 16: file.lock broken in call to fcntl - int vs. long confusion To mitigate appearance of hypocrisy, I'm willing to do this work on the Win32 header clones also. Though I think they are a smaller and bigger problem. Bigger because we have cloned *a lot*. Smaller because they vary less across the various Win32 architectures. Similar in size because we use only a small part of them, analogous to what we use for Unix. I speculate that stuff like OpenGL and X Windows aren't as problematic because they are fairly independent of OS/kernel. It is the "libc as kernel wrapper" where the problems are worse, given the relatively large number of varieties (Linux, *BSD, NT, Solaris, Darwin). Though they could still embed e.g. time_t, struct timeval, etc. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Apr 11 07:15:44 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 11 Apr 2010 05:15:44 +0000 Subject: [M3devel] UtimeExtra.i3 Message-ID: Just a note that the following are both duplicated and slightly buggy: C:\dev2\cm3.2\m3-mail\postcard\src\UtimeExtra.i3 C:\dev2\cm3.2\m3-mail\postcard\src\OSUtils.m3 C:\dev2\cm3.2\m3-mail\postcard\src\OSUtils.i3 C:\dev2\cm3.2\m3-mail\webcard\src\UtimeExtra.i3 C:\dev2\cm3.2\m3-mail\webcard\src\OSUtils.m3 C:\dev2\cm3.2\m3-mail\webcard\src\OSUtils.i3 The copies are identical. UtimeExtra.i3: (* The declaration of struct_tm in Utime omits "gmtoff"; mktime isn there at all. *) TYPE struct_tm = RECORD tm_sec: int; (* seconds (0 - 59) *) tm_min: int; (* minutes (0 - 59) *) tm_hour: int; (* hours (0 - 23) *) tm_mday: int; (* day of month (1 - 31) *) tm_mon: int; (* month of year (0 - 11) *) tm_year: int; (* year - 1900 *) tm_wday: int; (* day of week (Sunday = 0) *) tm_yday: int; (* day of year (0 - 365) *) tm_isdst: int; (* flag: daylight savings time in effect *) tm_gmtoff: long; (* offset from GMT in seconds *) tm_zone: char_star;(* abbreviation of timezone name *) END; struct_tm_star = UNTRACED REF struct_tm; <*EXTERNAL*> PROCEDURE localtime (clock: long_star): struct_tm_star; <*EXTERNAL*> PROCEDURE gmtime (clock: long_star): struct_tm_star; <*EXTERNAL*> PROCEDURE mktime (VAR tm: struct_tm): long; gmtoff is omitted deliberately, because it isn't always there. e.g. on Cygwin, Solaris, Interix, Posix. They are #ifed on Linux -- they are there. I don't believe the order of the fields is guaranteed either, but everything I looked at has them the same. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Apr 11 07:43:35 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 11 Apr 2010 05:43:35 +0000 Subject: [M3devel] unused/little used stuff in m3core/unix? Message-ID: Following are not used: fchmod fchown getpagesize sbrk creat isatty That isn't necessarily all. Some are used only in: C:\dev2\cm3.2\m3-libs\libm3\src\os\POSIX e.g. chdir getdtablesize execve Some are used only in the unused m3-pkgtools directory or by cvsup. e.g. umask These all traffic in pretty "plain" types (e.g. no structs, no time_t). So just keep them all? Note of course, uses of these somewhat or significantly inhibit porting to native Win32. Account for somewhat arbirary Posix-specific code outside the cm3 tree and err toward wrapping stuff that is easy? Or push the idea that m3core/libm3 are a good (and safe) portability layer and only provide what they need, and gradually move them towards C to reduce their needs? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Apr 11 16:30:44 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 11 Apr 2010 14:30:44 +0000 Subject: [M3devel] Control-c tends to hang? Message-ID: I'm seeing that pressing control-C has a very high propensity to hang. e.g. release branch, LINUXLIBC6, pthreads cd m3-libs/m3core rm -rf LINUXLIBC6 /cm3/bin/cm3 wait for it to print a file or two control-C if it doesn't hang, again: /cm3/bin/cm3 wait a second control-c It hangs about 25% of the time. gdb is generally useless..I find that true generally lately: Failed to read a valid object file image from memory. (gdb) thread apply all bt Thread 1 (Thread -1210542400 (LWP 4640)): #0 0xb7eff410 in ?? () #1 0xbfd35868 in ?? () #2 0x00000002 in ?? () #3 0x00000000 in ?? () #0 0xb7eff410 in ?? () maybe to do with.. strace gdb: open("/proc/5688/mem", O_RDONLY|O_LARGEFILE) = 6 pread64(6, 0xbfcd1d78, 52, 4294959104) = -1 EIO (Input/output error) close(6) = 0 ptrace(PTRACE_PEEKTEXT, 5688, 0xffffe000, [0]) = -1 EIO (Input/output error) rt_sigprocmask(SIG_SETMASK, [CHLD], NULL, 8) = 0 write(2, "Failed to read a valid object fi"..., 53Failed to read a valid object file image from memory.) = 53 Aha I thought I was running Debian 5.0, but only 4.0..maybe with a newer Debian/gdb. (There was a known problem in older kernels with this signature, I didn't realize I was running old..) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sun Apr 11 17:19:33 2010 From: wagner at elegosoft.com (wagner at elegosoft.com) Date: Sun, 11 Apr 2010 17:19:33 +0200 Subject: [M3devel] release engineering: build release_CM3_5_8_RC5 now? Message-ID: <20100411171933.szof1k9n2ss48sg8@mail.elegosoft.com> I'm currently tagging the release branch with release_CM3_5_8_RC5. Are there still any objections to use the current state of the branch? I'll soon try a sample build on birch. Olaf From jay.krell at cornell.edu Mon Apr 12 01:50:14 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 11 Apr 2010 23:50:14 +0000 Subject: [M3devel] Control-c tends to hang? Message-ID: I upgraded to Debian 5.0 to fix the debugging, and now I haven't been able to get the hang to occur. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Subject: Control-c tends to hang? Date: Sun, 11 Apr 2010 14:30:44 +0000 I'm seeing that pressing control-C has a very high propensity to hang. e.g. release branch, LINUXLIBC6, pthreads cd m3-libs/m3core rm -rf LINUXLIBC6 /cm3/bin/cm3 wait for it to print a file or two control-C if it doesn't hang, again: /cm3/bin/cm3 wait a second control-c It hangs about 25% of the time. gdb is generally useless..I find that true generally lately: Failed to read a valid object file image from memory. (gdb) thread apply all bt Thread 1 (Thread -1210542400 (LWP 4640)): #0 0xb7eff410 in ?? () #1 0xbfd35868 in ?? () #2 0x00000002 in ?? () #3 0x00000000 in ?? () #0 0xb7eff410 in ?? () maybe to do with.. strace gdb: open("/proc/5688/mem", O_RDONLY|O_LARGEFILE) = 6 pread64(6, 0xbfcd1d78, 52, 4294959104) = -1 EIO (Input/output error) close(6) = 0 ptrace(PTRACE_PEEKTEXT, 5688, 0xffffe000, [0]) = -1 EIO (Input/output error) rt_sigprocmask(SIG_SETMASK, [CHLD], NULL, 8) = 0 write(2, "Failed to read a valid object fi"..., 53Failed to read a valid object file image from memory.) = 53 Aha I thought I was running Debian 5.0, but only 4.0..maybe with a newer Debian/gdb. (There was a known problem in older kernels with this signature, I didn't realize I was running old..) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Apr 12 10:12:12 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 12 Apr 2010 10:12:12 +0200 Subject: [M3devel] unused/little used stuff in m3core/unix? In-Reply-To: References: Message-ID: <20100412101212.e3h8b4chco48cc0c@mail.elegosoft.com> Quoting Jay K : > Following are not used: > > fchmod > fchown > getpagesize > sbrk > creat > isatty > > That isn't necessarily all. > > Some are used only in: > > C:\dev2\cm3.2\m3-libs\libm3\src\os\POSIX > e.g. > chdir > getdtablesize > execve > > Some are used only in the unused m3-pkgtools directory or by cvsup. > e.g. umask > > These all traffic in pretty "plain" types (e.g. no structs, no > time_t). So just keep them all? Yes. These are standard POSIX or Unix legacy interfaces. Do not throw them out. > Note of course, uses of these somewhat or significantly inhibit > porting to native Win32. As these are POSIX, that is to be expected. > Account for somewhat arbirary Posix-specific code outside the cm3 tree > and err toward wrapping stuff that is easy? > > Or push the idea that m3core/libm3 are a good (and safe) portability > layer and only provide what they need, and > gradually move them towards C to reduce their needs? As a systems programming language, we should support standard OS interfaces IMO. 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 Mon Apr 12 10:25:20 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 12 Apr 2010 10:25:20 +0200 Subject: [M3devel] regression in m3tests? Message-ID: <20100412102520.dgxs973lk0kgg84s@mail.elegosoft.com> This one is new: http://hudson.modula3.com:8080/job/cm3-test-m3tests-LINUXLIBC6/250/testReport/%28root%29/m3tests/r001__unhandled_exception/ Is it just a new OS version, now writing out an additional line? --- ../src/r0/r001/stderr.build 2008-01-08 17:15:47.000000000 -0800 +++ ../src/r0/r001/LINUXLIBC6/stderr.build 2010-04-11 21:06:07.000000000 -0700 @@ -0,0 +1 @@ +/bin/sh: line 1: 8334 Aborted ./pgm > stdout.pgm.raw 2> stderr.pgm.raw I assume, r002/3/4 are actually OK on Linux, too, just the output is different? We need to adapt the output for r004 (line change in RTAllocator), and probably make our compare a bit more lenient. Any good ideas how to accomplish this easily? 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 jay.krell at cornell.edu Mon Apr 12 11:36:23 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 12 Apr 2010 09:36:23 +0000 Subject: [M3devel] regression in m3tests? In-Reply-To: <20100412102520.dgxs973lk0kgg84s@mail.elegosoft.com> References: <20100412102520.dgxs973lk0kgg84s@mail.elegosoft.com> Message-ID: Tests that abort et. al. have always been a problem. I did a bunch of work to make them less of a problem. But maybe not enough. - Jay > Date: Mon, 12 Apr 2010 10:25:20 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] regression in m3tests? > > This one is new: > > http://hudson.modula3.com:8080/job/cm3-test-m3tests-LINUXLIBC6/250/testReport/%28root%29/m3tests/r001__unhandled_exception/ > > Is it just a new OS version, now writing out an additional line? > > --- ../src/r0/r001/stderr.build 2008-01-08 17:15:47.000000000 -0800 > +++ ../src/r0/r001/LINUXLIBC6/stderr.build 2010-04-11 21:06:07.000000000 -0700 > @@ -0,0 +1 @@ > +/bin/sh: line 1: 8334 Aborted ./pgm > stdout.pgm.raw > 2> stderr.pgm.raw > > I assume, r002/3/4 are actually OK on Linux, too, just the output is > different? > > We need to adapt the output for r004 (line change in RTAllocator), > and probably make our compare a bit more lenient. > > Any good ideas how to accomplish this easily? > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Apr 12 13:13:11 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 12 Apr 2010 13:13:11 +0200 Subject: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? In-Reply-To: <20100411171933.szof1k9n2ss48sg8@mail.elegosoft.com> References: <20100411171933.szof1k9n2ss48sg8@mail.elegosoft.com> Message-ID: <20100412131311.5ax5opbuskcw00sk@mail.elegosoft.com> Quoting wagner at elegosoft.com: > I'm currently tagging the release branch with release_CM3_5_8_RC5. > > Are there still any objections to use the current state of the branch? > > I'll soon try a sample build on birch. As nobody has called `Stop', I've started to build the release packages for RC5. Some can already be found on the download page currently still reachable via the RC4 download (scroll down to the end). http://www.modula3.com/cm3/releng/download.html There have been 401 single changes since the last RC though :-/ See http://hudson.modula3.com:8080/view/makedist/job/cm3-makedist-AMD64_LINUX/changes for details. I don't know how to summarize that or even to motivate this amound of changes that late in a release. Perhaps it's best to just say nothing... If you find any problem with RC5, please let me know as soon as possible. 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 jay.krell at cornell.edu Mon Apr 12 14:45:50 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 12 Apr 2010 12:45:50 +0000 Subject: [M3devel] unused/little used stuff in m3core/unix? In-Reply-To: <20100412101212.e3h8b4chco48cc0c@mail.elegosoft.com> References: , <20100412101212.e3h8b4chco48cc0c@mail.elegosoft.com> Message-ID: Ok on preserving most/all of these but note I'm not keen on preserving like anything dealing with structs or time_t. There are various arguments for/against. This "systems" language interoperates well with C, directly, IF you control the C. Thus we have wrappers. We almost never interface directly with "the OS". Then again, same is true of C. Actual "kernels" have custom calling mechanisms, which gets wrapped in C. I'm not sure we should provide a general set of wrappers, or leave it to each user to write his own, or provide some simple small set. Leaving it to each user is error prone, granted. The historical implementation here was awful and *really* *not* the way. The question then is what should the implementation be. - Jay > Date: Mon, 12 Apr 2010 10:12:12 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] unused/little used stuff in m3core/unix? > > Quoting Jay K : > > > Following are not used: > > > > fchmod > > fchown > > getpagesize > > sbrk > > creat > > isatty > > > > That isn't necessarily all. > > > > Some are used only in: > > > > C:\dev2\cm3.2\m3-libs\libm3\src\os\POSIX > > e.g. > > chdir > > getdtablesize > > execve > > > > Some are used only in the unused m3-pkgtools directory or by cvsup. > > e.g. umask > > > > These all traffic in pretty "plain" types (e.g. no structs, no > > time_t). So just keep them all? > > Yes. These are standard POSIX or Unix legacy interfaces. > Do not throw them out. > > > Note of course, uses of these somewhat or significantly inhibit > > porting to native Win32. > > As these are POSIX, that is to be expected. > > > Account for somewhat arbirary Posix-specific code outside the cm3 tree > > and err toward wrapping stuff that is easy? > > > > Or push the idea that m3core/libm3 are a good (and safe) portability > > layer and only provide what they need, and > > gradually move them towards C to reduce their needs? > > As a systems programming language, we should support standard OS > interfaces IMO. > > Olaf -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Apr 12 15:03:26 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 12 Apr 2010 13:03:26 +0000 Subject: [M3devel] JVideo/struct_timeval? Message-ID: This seems wierd: C:\dev2\cm3.2\m3-ui\jvideo\src\POSIX\jvprotocol.i3(193): timestamp: Utime.struct_timeval; I think they are defining a wire protocol, but embedding platform-specific types in it. How about I just change to Time.T? (64bit floating point, seconds since 1970). We could do like: C:\dev2\cm3.2\m3-ui\jvideo\src\POSIX\decunix\JVSink.m3(440): jvb.timestamp.tv_sec := signed_ntohl(hdr.timestamp.tv_sec); and define it to be transferred as a network order 64bit integer (big endian LONGINT), or maybe an array of 8 bytes. Or maybe define a local struct_timeval separate from Utime that hardcodes the sizes..and maybe using LONGINT? 32bit time_t is apparently still very common, though it seems obviously a big mistake.. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Apr 12 16:46:39 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 12 Apr 2010 14:46:39 +0000 Subject: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? In-Reply-To: <20100412131311.5ax5opbuskcw00sk@mail.elegosoft.com> References: <20100411171933.szof1k9n2ss48sg8@mail.elegosoft.com>, <20100412131311.5ax5opbuskcw00sk@mail.elegosoft.com> Message-ID: Thanks. I see the NT386 packages, but not .msi. - Jay > Date: Mon, 12 Apr 2010 13:13:11 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? > > Quoting wagner at elegosoft.com: > > > I'm currently tagging the release branch with release_CM3_5_8_RC5. > > > > Are there still any objections to use the current state of the branch? > > > > I'll soon try a sample build on birch. > > As nobody has called `Stop', I've started to build the release packages > for RC5. Some can already be found on the download page currently > still reachable via the RC4 download (scroll down to the end). > > http://www.modula3.com/cm3/releng/download.html > > There have been 401 single changes since the last RC though :-/ > See > http://hudson.modula3.com:8080/view/makedist/job/cm3-makedist-AMD64_LINUX/changes > for details. I don't know how to summarize that or even to motivate > this amound of changes that late in a release. Perhaps it's best to > just say nothing... > > If you find any problem with RC5, please let me know as soon as possible. > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Apr 12 17:05:48 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 12 Apr 2010 17:05:48 +0200 Subject: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? In-Reply-To: References: <20100411171933.szof1k9n2ss48sg8@mail.elegosoft.com>, <20100412131311.5ax5opbuskcw00sk@mail.elegosoft.com> Message-ID: <20100412170548.o3go4tu8ys4wgwo4@mail.elegosoft.com> Quoting Jay K : > > Thanks. I see the NT386 packages, but not .msi. I'll check that later; the new index isn't in place, and perhaps the update script is still buggy. Please have a look at the SOLgnu build though: http://hudson.modula3.com:8080/view/makedist/job/cm3-makedist-SOLgnu/16/console This used to work. Anything you changed? Olaf > > > > - Jay > > >> Date: Mon, 12 Apr 2010 13:13:11 +0200 >> From: wagner at elegosoft.com >> To: m3devel at elegosoft.com >> Subject: [M3devel] release 5.8 RC5 build in progress, was: Re: >> release engineering: build release_CM3_5_8_RC5 now? >> >> Quoting wagner at elegosoft.com: >> >> > I'm currently tagging the release branch with release_CM3_5_8_RC5. >> > >> > Are there still any objections to use the current state of the branch? >> > >> > I'll soon try a sample build on birch. >> >> As nobody has called `Stop', I've started to build the release packages >> for RC5. Some can already be found on the download page currently >> still reachable via the RC4 download (scroll down to the end). >> >> http://www.modula3.com/cm3/releng/download.html >> >> There have been 401 single changes since the last RC though :-/ >> See >> http://hudson.modula3.com:8080/view/makedist/job/cm3-makedist-AMD64_LINUX/changes >> for details. I don't know how to summarize that or even to motivate >> this amound of changes that late in a release. Perhaps it's best to >> just say nothing... >> >> If you find any problem with RC5, please let me know as soon as possible. >> >> 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 wagner at elegosoft.com Mon Apr 12 17:26:59 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 12 Apr 2010 17:26:59 +0200 Subject: [M3devel] more RC5 build package problems Message-ID: <20100412172659.fdpk7fn728sgs0c8@mail.elegosoft.com> PPC_DARWIN build failed, too :-( Do you have any idea what could be causing this? http://hudson.modula3.com:8080/view/makedist/job/cm3-makedist-PPC_DARWIN/8/console [...] -rw-r--r-- 1 hudson hudson 1886008 12 Apr 16:18 /Users/hudson/tmp/cm3-bin-ws-tool-PPC_DARWIN-5.8.5-RC5.tgz collection-math.html -rw-r--r-- 1 hudson hudson 2866838 12 Apr 16:19 /Users/hudson/tmp/cm3-bin-ws-math-PPC_DARWIN-5.8.5-RC5.tgz m3-games/columns/PPC_DARWIN/.M3SHIP seems to be broken: Finished: FAILURE The .M3SHIP files looks completely innocent... Olaf PS: Looks like it will take a week to build all target platforms as usual... Invariant could be: never works twice in succession for a give target ;-) -- 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 jay.krell at cornell.edu Mon Apr 12 22:59:34 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 12 Apr 2010 20:59:34 +0000 Subject: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? In-Reply-To: <20100412170548.o3go4tu8ys4wgwo4@mail.elegosoft.com> References: <20100411171933.szof1k9n2ss48sg8@mail.elegosoft.com>, <20100412131311.5ax5opbuskcw00sk@mail.elegosoft.com>, , <20100412170548.o3go4tu8ys4wgwo4@mail.elegosoft.com> Message-ID: SOLgnu partial explanation: Building cm3 itself is going down the path that occurs when you don't -DCM3_VERSION_NUMBER -DCM3_VERSION_TEXT -DCM3_LAST_CHANGED. Not specifying them is supposed to work, but "you" are supposed to specify them really. Enough of a hint? (I don't have the full answer myself.) - Jay > Date: Mon, 12 Apr 2010 17:05:48 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? > > Quoting Jay K : > > > > > Thanks. I see the NT386 packages, but not .msi. > > I'll check that later; the new index isn't in place, and perhaps > the update script is still buggy. > > Please have a look at the SOLgnu build though: > > > http://hudson.modula3.com:8080/view/makedist/job/cm3-makedist-SOLgnu/16/console > > This used to work. Anything you changed? > > Olaf > > > > > > > > - Jay > > > > > >> Date: Mon, 12 Apr 2010 13:13:11 +0200 > >> From: wagner at elegosoft.com > >> To: m3devel at elegosoft.com > >> Subject: [M3devel] release 5.8 RC5 build in progress, was: Re: > >> release engineering: build release_CM3_5_8_RC5 now? > >> > >> Quoting wagner at elegosoft.com: > >> > >> > I'm currently tagging the release branch with release_CM3_5_8_RC5. > >> > > >> > Are there still any objections to use the current state of the branch? > >> > > >> > I'll soon try a sample build on birch. > >> > >> As nobody has called `Stop', I've started to build the release packages > >> for RC5. Some can already be found on the download page currently > >> still reachable via the RC4 download (scroll down to the end). > >> > >> http://www.modula3.com/cm3/releng/download.html > >> > >> There have been 401 single changes since the last RC though :-/ > >> See > >> http://hudson.modula3.com:8080/view/makedist/job/cm3-makedist-AMD64_LINUX/changes > >> for details. I don't know how to summarize that or even to motivate > >> this amound of changes that late in a release. Perhaps it's best to > >> just say nothing... > >> > >> If you find any problem with RC5, please let me know as soon as possible. > >> > >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Apr 12 23:07:02 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 12 Apr 2010 21:07:02 +0000 Subject: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? In-Reply-To: References: <20100411171933.szof1k9n2ss48sg8@mail.elegosoft.com>, , <20100412131311.5ax5opbuskcw00sk@mail.elegosoft.com>, , , , <20100412170548.o3go4tu8ys4wgwo4@mail.elegosoft.com>, Message-ID: I'm *guessing* some *sh problem. Want to try /usr/bin/bash? - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com Date: Mon, 12 Apr 2010 20:59:34 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? SOLgnu partial explanation: Building cm3 itself is going down the path that occurs when you don't -DCM3_VERSION_NUMBER -DCM3_VERSION_TEXT -DCM3_LAST_CHANGED. Not specifying them is supposed to work, but "you" are supposed to specify them really. Enough of a hint? (I don't have the full answer myself.) - Jay > Date: Mon, 12 Apr 2010 17:05:48 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? > > Quoting Jay K : > > > > > Thanks. I see the NT386 packages, but not .msi. > > I'll check that later; the new index isn't in place, and perhaps > the update script is still buggy. > > Please have a look at the SOLgnu build though: > > > http://hudson.modula3.com:8080/view/makedist/job/cm3-makedist-SOLgnu/16/console > > This used to work. Anything you changed? > > Olaf > > > > > > > > - Jay > > > > > >> Date: Mon, 12 Apr 2010 13:13:11 +0200 > >> From: wagner at elegosoft.com > >> To: m3devel at elegosoft.com > >> Subject: [M3devel] release 5.8 RC5 build in progress, was: Re: > >> release engineering: build release_CM3_5_8_RC5 now? > >> > >> Quoting wagner at elegosoft.com: > >> > >> > I'm currently tagging the release branch with release_CM3_5_8_RC5. > >> > > >> > Are there still any objections to use the current state of the branch? > >> > > >> > I'll soon try a sample build on birch. > >> > >> As nobody has called `Stop', I've started to build the release packages > >> for RC5. Some can already be found on the download page currently > >> still reachable via the RC4 download (scroll down to the end). > >> > >> http://www.modula3.com/cm3/releng/download.html > >> > >> There have been 401 single changes since the last RC though :-/ > >> See > >> http://hudson.modula3.com:8080/view/makedist/job/cm3-makedist-AMD64_LINUX/changes > >> for details. I don't know how to summarize that or even to motivate > >> this amound of changes that late in a release. Perhaps it's best to > >> just say nothing... > >> > >> If you find any problem with RC5, please let me know as soon as possible. > >> > >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Apr 12 23:14:47 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 12 Apr 2010 21:14:47 +0000 Subject: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? In-Reply-To: References: <20100411171933.szof1k9n2ss48sg8@mail.elegosoft.com>, ,,<20100412131311.5ax5opbuskcw00sk@mail.elegosoft.com>, ,,, , , <20100412170548.o3go4tu8ys4wgwo4@mail.elegosoft.com>, , , Message-ID: I see part of the problem. - You do define the version earlier in the build, but not later. From reading the log. - I don't know why the grep doesn't work. Searching for '-DROOT'... C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\make-bin-dist-min.sh(133):BUILDLOCAL="${CM3} -build -override -DROOT='${CM3ROOT}'" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\make-bin-dist-min.sh(134):CLEANLOCAL="${CM3} -clean -override -DROOT='${CM3ROOT}'" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\make-bin-dist-min.sh(135):BUILDGLOBAL="${CM3} -build -DROOT='${CM3ROOT}'" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\make-bin-dist-min.sh(136):CLEANGLOBAL="${CM3} -clean -DROOT='${CM3ROOT}'" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\make-bin-dist-min.sh(137):SHIP="${CM3} -ship -DROOT='${CM3ROOT}'" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgcmds.sh(21):DEFS="-DROOT='${CM3ROOT}' -DCM3_VERSION_TEXT='${CM3VERSION}' -DCM3_VERSION_NUMBER='${CM3VERSIONNUM}' -DCM3_LAST_CHANGED='${CM3LASTCHANGED}'" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgmap.sh(424): echo " +++ cm3 -build -override -DTEST -DRUN -DROOT=$ROOT +++" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgmap.sh(429): tres=`cm3 -build -override -DTEST -DRUN -DROOT="${ROOT}" 2> stderr` Maybe use ${DEFS} more? You could also hack cm3/src/m3makefile for the release. Copy the data into it. A better fix in head for the next one? Searching for 'DEFS'... C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgcmds.sh(21):DEFS="-DROOT='${CM3ROOT}' -DCM3_VERSION_TEXT='${CM3VERSION}' -DCM3_VERSION_NUMBER='${CM3VERSIONNUM}' -DCM3_LAST_CHANGED='${CM3LASTCHANGED}'" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgcmds.sh(22):BUILDLOCAL="${BUILDLOCAL:-${CM3} -build -override \$RARGS ${DEFS} ${BUILDARGS}}" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgcmds.sh(23):CLEANLOCAL="${CLEANLOCAL:-${CM3} -clean -override \$RARGS ${DEFS} ${CLEANARGS}}" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgcmds.sh(24):BUILDGLOBAL="${BUILDGLOBAL:-${CM3} -build ${DEFS} \$RARGS ${BUILDARGS}}" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgcmds.sh(25):CLEANGLOBAL="${CLEANGLOBAL:-${CM3} -clean ${DEFS} \$RARGS ${CLEANARGS}}" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgcmds.sh(26):SHIP="${SHIP:-${CM3} -ship \$RARGS ${DEFS} ${SHIPARGS}}" Is DEFS missing somewhere? - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com Date: Mon, 12 Apr 2010 21:07:02 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? I'm *guessing* some *sh problem. Want to try /usr/bin/bash? - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com Date: Mon, 12 Apr 2010 20:59:34 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? SOLgnu partial explanation: Building cm3 itself is going down the path that occurs when you don't -DCM3_VERSION_NUMBER -DCM3_VERSION_TEXT -DCM3_LAST_CHANGED. Not specifying them is supposed to work, but "you" are supposed to specify them really. Enough of a hint? (I don't have the full answer myself.) - Jay > Date: Mon, 12 Apr 2010 17:05:48 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? > > Quoting Jay K : > > > > > Thanks. I see the NT386 packages, but not .msi. > > I'll check that later; the new index isn't in place, and perhaps > the update script is still buggy. > > Please have a look at the SOLgnu build though: > > > http://hudson.modula3.com:8080/view/makedist/job/cm3-makedist-SOLgnu/16/console > > This used to work. Anything you changed? > > Olaf > > > > > > > > - Jay > > > > > >> Date: Mon, 12 Apr 2010 13:13:11 +0200 > >> From: wagner at elegosoft.com > >> To: m3devel at elegosoft.com > >> Subject: [M3devel] release 5.8 RC5 build in progress, was: Re: > >> release engineering: build release_CM3_5_8_RC5 now? > >> > >> Quoting wagner at elegosoft.com: > >> > >> > I'm currently tagging the release branch with release_CM3_5_8_RC5. > >> > > >> > Are there still any objections to use the current state of the branch? > >> > > >> > I'll soon try a sample build on birch. > >> > >> As nobody has called `Stop', I've started to build the release packages > >> for RC5. Some can already be found on the download page currently > >> still reachable via the RC4 download (scroll down to the end). > >> > >> http://www.modula3.com/cm3/releng/download.html > >> > >> There have been 401 single changes since the last RC though :-/ > >> See > >> http://hudson.modula3.com:8080/view/makedist/job/cm3-makedist-AMD64_LINUX/changes > >> for details. I don't know how to summarize that or even to motivate > >> this amound of changes that late in a release. Perhaps it's best to > >> just say nothing... > >> > >> If you find any problem with RC5, please let me know as soon as possible. > >> > >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Apr 12 23:24:03 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 12 Apr 2010 21:24:03 +0000 Subject: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? In-Reply-To: References: <20100411171933.szof1k9n2ss48sg8@mail.elegosoft.com>, , , , <20100412131311.5ax5opbuskcw00sk@mail.elegosoft.com>, , , , , , , , <20100412170548.o3go4tu8ys4wgwo4@mail.elegosoft.com>, , , , , , Message-ID: A good option is to export these three variables: CM3VERSIONNUM CM3VERSION CM3LASTCHANGED and/or use the -D switches. Otherwise m3-sys/cm3/m3makefile goes down a gnarly path (that I put in) of trying to read scripts/version. Which usually works, but could be too sensitive to /bin/sh behavior...often bites us you know. - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com Date: Mon, 12 Apr 2010 21:14:47 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? I see part of the problem. - You do define the version earlier in the build, but not later. From reading the log. - I don't know why the grep doesn't work. Searching for '-DROOT'... C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\make-bin-dist-min.sh(133):BUILDLOCAL="${CM3} -build -override -DROOT='${CM3ROOT}'" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\make-bin-dist-min.sh(134):CLEANLOCAL="${CM3} -clean -override -DROOT='${CM3ROOT}'" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\make-bin-dist-min.sh(135):BUILDGLOBAL="${CM3} -build -DROOT='${CM3ROOT}'" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\make-bin-dist-min.sh(136):CLEANGLOBAL="${CM3} -clean -DROOT='${CM3ROOT}'" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\make-bin-dist-min.sh(137):SHIP="${CM3} -ship -DROOT='${CM3ROOT}'" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgcmds.sh(21):DEFS="-DROOT='${CM3ROOT}' -DCM3_VERSION_TEXT='${CM3VERSION}' -DCM3_VERSION_NUMBER='${CM3VERSIONNUM}' -DCM3_LAST_CHANGED='${CM3LASTCHANGED}'" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgmap.sh(424): echo " +++ cm3 -build -override -DTEST -DRUN -DROOT=$ROOT +++" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgmap.sh(429): tres=`cm3 -build -override -DTEST -DRUN -DROOT="${ROOT}" 2> stderr` Maybe use ${DEFS} more? You could also hack cm3/src/m3makefile for the release. Copy the data into it. A better fix in head for the next one? Searching for 'DEFS'... C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgcmds.sh(21):DEFS="-DROOT='${CM3ROOT}' -DCM3_VERSION_TEXT='${CM3VERSION}' -DCM3_VERSION_NUMBER='${CM3VERSIONNUM}' -DCM3_LAST_CHANGED='${CM3LASTCHANGED}'" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgcmds.sh(22):BUILDLOCAL="${BUILDLOCAL:-${CM3} -build -override \$RARGS ${DEFS} ${BUILDARGS}}" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgcmds.sh(23):CLEANLOCAL="${CLEANLOCAL:-${CM3} -clean -override \$RARGS ${DEFS} ${CLEANARGS}}" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgcmds.sh(24):BUILDGLOBAL="${BUILDGLOBAL:-${CM3} -build ${DEFS} \$RARGS ${BUILDARGS}}" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgcmds.sh(25):CLEANGLOBAL="${CLEANGLOBAL:-${CM3} -clean ${DEFS} \$RARGS ${CLEANARGS}}" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgcmds.sh(26):SHIP="${SHIP:-${CM3} -ship \$RARGS ${DEFS} ${SHIPARGS}}" Is DEFS missing somewhere? - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com Date: Mon, 12 Apr 2010 21:07:02 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? I'm *guessing* some *sh problem. Want to try /usr/bin/bash? - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com Date: Mon, 12 Apr 2010 20:59:34 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? SOLgnu partial explanation: Building cm3 itself is going down the path that occurs when you don't -DCM3_VERSION_NUMBER -DCM3_VERSION_TEXT -DCM3_LAST_CHANGED. Not specifying them is supposed to work, but "you" are supposed to specify them really. Enough of a hint? (I don't have the full answer myself.) - Jay > Date: Mon, 12 Apr 2010 17:05:48 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? > > Quoting Jay K : > > > > > Thanks. I see the NT386 packages, but not .msi. > > I'll check that later; the new index isn't in place, and perhaps > the update script is still buggy. > > Please have a look at the SOLgnu build though: > > > http://hudson.modula3.com:8080/view/makedist/job/cm3-makedist-SOLgnu/16/console > > This used to work. Anything you changed? > > Olaf > > > > > > > > - Jay > > > > > >> Date: Mon, 12 Apr 2010 13:13:11 +0200 > >> From: wagner at elegosoft.com > >> To: m3devel at elegosoft.com > >> Subject: [M3devel] release 5.8 RC5 build in progress, was: Re: > >> release engineering: build release_CM3_5_8_RC5 now? > >> > >> Quoting wagner at elegosoft.com: > >> > >> > I'm currently tagging the release branch with release_CM3_5_8_RC5. > >> > > >> > Are there still any objections to use the current state of the branch? > >> > > >> > I'll soon try a sample build on birch. > >> > >> As nobody has called `Stop', I've started to build the release packages > >> for RC5. Some can already be found on the download page currently > >> still reachable via the RC4 download (scroll down to the end). > >> > >> http://www.modula3.com/cm3/releng/download.html > >> > >> There have been 401 single changes since the last RC though :-/ > >> See > >> http://hudson.modula3.com:8080/view/makedist/job/cm3-makedist-AMD64_LINUX/changes > >> for details. I don't know how to summarize that or even to motivate > >> this amound of changes that late in a release. Perhaps it's best to > >> just say nothing... > >> > >> If you find any problem with RC5, please let me know as soon as possible. > >> > >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Apr 12 23:30:19 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 12 Apr 2010 21:30:19 +0000 Subject: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? In-Reply-To: References: <20100411171933.szof1k9n2ss48sg8@mail.elegosoft.com>, , , , <20100412131311.5ax5opbuskcw00sk@mail.elegosoft.com>, , , , , , , , , <20100412170548.o3go4tu8ys4wgwo4@mail.elegosoft.com>, , , , , , , Message-ID: Actually it looks like the environment path is a little gnarly too. Best to use -D. Maybe we should check in scripts/version.quake along with scripts/version. Two copies are bad, but the machinations in m3-sys/cm3/m3makefile aren't great either. Or maybe version.quake would be the one and only? Depends on where else we really need it, and how easy it is to use in those contexts. Maybe the quake could be written in a better way. I can have another go at it esp. with the newer quake primitives. version.quake would be easy and simple though, at the cost of having the data checked in twice. I'll probably do that in head "soon" (at least 12 hours away). - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com CC: m3devel at elegosoft.com Subject: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? Date: Mon, 12 Apr 2010 21:24:03 +0000 A good option is to export these three variables: CM3VERSIONNUM CM3VERSION CM3LASTCHANGED and/or use the -D switches. Otherwise m3-sys/cm3/m3makefile goes down a gnarly path (that I put in) of trying to read scripts/version. Which usually works, but could be too sensitive to /bin/sh behavior...often bites us you know. - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com Date: Mon, 12 Apr 2010 21:14:47 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? I see part of the problem. - You do define the version earlier in the build, but not later. From reading the log. - I don't know why the grep doesn't work. Searching for '-DROOT'... C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\make-bin-dist-min.sh(133):BUILDLOCAL="${CM3} -build -override -DROOT='${CM3ROOT}'" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\make-bin-dist-min.sh(134):CLEANLOCAL="${CM3} -clean -override -DROOT='${CM3ROOT}'" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\make-bin-dist-min.sh(135):BUILDGLOBAL="${CM3} -build -DROOT='${CM3ROOT}'" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\make-bin-dist-min.sh(136):CLEANGLOBAL="${CM3} -clean -DROOT='${CM3ROOT}'" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\make-bin-dist-min.sh(137):SHIP="${CM3} -ship -DROOT='${CM3ROOT}'" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgcmds.sh(21):DEFS="-DROOT='${CM3ROOT}' -DCM3_VERSION_TEXT='${CM3VERSION}' -DCM3_VERSION_NUMBER='${CM3VERSIONNUM}' -DCM3_LAST_CHANGED='${CM3LASTCHANGED}'" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgmap.sh(424): echo " +++ cm3 -build -override -DTEST -DRUN -DROOT=$ROOT +++" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgmap.sh(429): tres=`cm3 -build -override -DTEST -DRUN -DROOT="${ROOT}" 2> stderr` Maybe use ${DEFS} more? You could also hack cm3/src/m3makefile for the release. Copy the data into it. A better fix in head for the next one? Searching for 'DEFS'... C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgcmds.sh(21):DEFS="-DROOT='${CM3ROOT}' -DCM3_VERSION_TEXT='${CM3VERSION}' -DCM3_VERSION_NUMBER='${CM3VERSIONNUM}' -DCM3_LAST_CHANGED='${CM3LASTCHANGED}'" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgcmds.sh(22):BUILDLOCAL="${BUILDLOCAL:-${CM3} -build -override \$RARGS ${DEFS} ${BUILDARGS}}" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgcmds.sh(23):CLEANLOCAL="${CLEANLOCAL:-${CM3} -clean -override \$RARGS ${DEFS} ${CLEANARGS}}" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgcmds.sh(24):BUILDGLOBAL="${BUILDGLOBAL:-${CM3} -build ${DEFS} \$RARGS ${BUILDARGS}}" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgcmds.sh(25):CLEANGLOBAL="${CLEANGLOBAL:-${CM3} -clean ${DEFS} \$RARGS ${CLEANARGS}}" C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgcmds.sh(26):SHIP="${SHIP:-${CM3} -ship \$RARGS ${DEFS} ${SHIPARGS}}" Is DEFS missing somewhere? - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com Date: Mon, 12 Apr 2010 21:07:02 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? I'm *guessing* some *sh problem. Want to try /usr/bin/bash? - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com Date: Mon, 12 Apr 2010 20:59:34 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? SOLgnu partial explanation: Building cm3 itself is going down the path that occurs when you don't -DCM3_VERSION_NUMBER -DCM3_VERSION_TEXT -DCM3_LAST_CHANGED. Not specifying them is supposed to work, but "you" are supposed to specify them really. Enough of a hint? (I don't have the full answer myself.) - Jay > Date: Mon, 12 Apr 2010 17:05:48 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? > > Quoting Jay K : > > > > > Thanks. I see the NT386 packages, but not .msi. > > I'll check that later; the new index isn't in place, and perhaps > the update script is still buggy. > > Please have a look at the SOLgnu build though: > > > http://hudson.modula3.com:8080/view/makedist/job/cm3-makedist-SOLgnu/16/console > > This used to work. Anything you changed? > > Olaf > > > > > > > > - Jay > > > > > >> Date: Mon, 12 Apr 2010 13:13:11 +0200 > >> From: wagner at elegosoft.com > >> To: m3devel at elegosoft.com > >> Subject: [M3devel] release 5.8 RC5 build in progress, was: Re: > >> release engineering: build release_CM3_5_8_RC5 now? > >> > >> Quoting wagner at elegosoft.com: > >> > >> > I'm currently tagging the release branch with release_CM3_5_8_RC5. > >> > > >> > Are there still any objections to use the current state of the branch? > >> > > >> > I'll soon try a sample build on birch. > >> > >> As nobody has called `Stop', I've started to build the release packages > >> for RC5. Some can already be found on the download page currently > >> still reachable via the RC4 download (scroll down to the end). > >> > >> http://www.modula3.com/cm3/releng/download.html > >> > >> There have been 401 single changes since the last RC though :-/ > >> See > >> http://hudson.modula3.com:8080/view/makedist/job/cm3-makedist-AMD64_LINUX/changes > >> for details. I don't know how to summarize that or even to motivate > >> this amound of changes that late in a release. Perhaps it's best to > >> just say nothing... > >> > >> If you find any problem with RC5, please let me know as soon as possible. > >> > >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Apr 12 23:39:57 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 12 Apr 2010 23:39:57 +0200 Subject: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? In-Reply-To: References: <20100411171933.szof1k9n2ss48sg8@mail.elegosoft.com>, , , , <20100412131311.5ax5opbuskcw00sk@mail.elegosoft.com>, , , , , , , , , <20100412170548.o3go4tu8ys4wgwo4@mail.elegosoft.com>, , , , , , , Message-ID: <20100412233957.ftgkq5jpicoo800w@mail.elegosoft.com> Well, I was just wondering what has changed, since the scripts have worked for earlier RCs on your Solaris system. And they're working on half a dozen other platforms. I'll try to follow some of your hints tomorrow. Olaf Quoting Jay K : > Actually it looks like the environment path is a little gnarly too. > > Best to use -D. > > Maybe we should check in scripts/version.quake along with scripts/version. > > Two copies are bad, but the machinations in m3-sys/cm3/m3makefile > aren't great either. > > Or maybe version.quake would be the one and only? > > Depends on where else we really need it, and how easy it is to use > in those contexts. > > Maybe the quake could be written in a better way. I can have > another go at it esp. with the newer quake primitives. > > > > version.quake would be easy and simple though, at the cost of having > the data checked in twice. > > I'll probably do that in head "soon" (at least 12 hours away). > > > > - Jay > > > > > From: jay.krell at cornell.edu > To: wagner at elegosoft.com > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: > release engineering: build release_CM3_5_8_RC5 now? > Date: Mon, 12 Apr 2010 21:24:03 +0000 > > > > A good option is to export these three variables: > > CM3VERSIONNUM > CM3VERSION > CM3LASTCHANGED > > and/or use the -D switches. > Otherwise m3-sys/cm3/m3makefile goes down a gnarly path (that I put > in) of trying to read scripts/version. > Which usually works, but could be too sensitive to /bin/sh > behavior...often bites us you know. > > - Jay > > > > > From: jay.krell at cornell.edu > To: wagner at elegosoft.com > Date: Mon, 12 Apr 2010 21:14:47 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] release 5.8 RC5 build in progress, was: Re: > release engineering: build release_CM3_5_8_RC5 now? > > > > I see part of the problem. > - You do define the version earlier in the build, but not later. > From reading the log. > - I don't know why the grep doesn't work. > > > Searching for '-DROOT'... > C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\make-bin-dist-min.sh(133):BUILDLOCAL="${CM3} -build -override > -DROOT='${CM3ROOT}'" > C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\make-bin-dist-min.sh(134):CLEANLOCAL="${CM3} -clean -override > -DROOT='${CM3ROOT}'" > C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\make-bin-dist-min.sh(135):BUILDGLOBAL="${CM3} -build > -DROOT='${CM3ROOT}'" > C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\make-bin-dist-min.sh(136):CLEANGLOBAL="${CM3} -clean > -DROOT='${CM3ROOT}'" > C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\make-bin-dist-min.sh(137):SHIP="${CM3} -ship > -DROOT='${CM3ROOT}'" > C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgcmds.sh(21):DEFS="-DROOT='${CM3ROOT}' -DCM3_VERSION_TEXT='${CM3VERSION}' -DCM3_VERSION_NUMBER='${CM3VERSIONNUM}' > -DCM3_LAST_CHANGED='${CM3LASTCHANGED}'" > C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgmap.sh(424): > echo " +++ cm3 -build -override -DTEST -DRUN -DROOT=$ROOT +++" > C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgmap.sh(429): > tres=`cm3 -build -override -DTEST -DRUN -DROOT="${ROOT}" 2> stderr` > > > Maybe use ${DEFS} more? > You could also hack cm3/src/m3makefile for the release. Copy the > data into it. > A better fix in head for the next one? > > > Searching for 'DEFS'... > C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgcmds.sh(21):DEFS="-DROOT='${CM3ROOT}' -DCM3_VERSION_TEXT='${CM3VERSION}' -DCM3_VERSION_NUMBER='${CM3VERSIONNUM}' > -DCM3_LAST_CHANGED='${CM3LASTCHANGED}'" > C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgcmds.sh(22):BUILDLOCAL="${BUILDLOCAL:-${CM3} -build -override \$RARGS ${DEFS} > ${BUILDARGS}}" > C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgcmds.sh(23):CLEANLOCAL="${CLEANLOCAL:-${CM3} -clean -override \$RARGS ${DEFS} > ${CLEANARGS}}" > C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgcmds.sh(24):BUILDGLOBAL="${BUILDGLOBAL:-${CM3} -build ${DEFS} \$RARGS > ${BUILDARGS}}" > C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgcmds.sh(25):CLEANGLOBAL="${CLEANGLOBAL:-${CM3} -clean ${DEFS} \$RARGS > ${CLEANARGS}}" > C:\DEV2\CM3.RELEASE_BRANCH_CM3_5_8\SCRIPTS\pkgcmds.sh(26):SHIP="${SHIP:-${CM3} -ship \$RARGS ${DEFS} > ${SHIPARGS}}" > > > Is DEFS missing somewhere? > > > - Jay > > > > From: jay.krell at cornell.edu > To: wagner at elegosoft.com > Date: Mon, 12 Apr 2010 21:07:02 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] release 5.8 RC5 build in progress, was: Re: > release engineering: build release_CM3_5_8_RC5 now? > > > > I'm *guessing* some *sh problem. > Want to try /usr/bin/bash? > > - Jay > > > > > > From: jay.krell at cornell.edu > To: wagner at elegosoft.com > Date: Mon, 12 Apr 2010 20:59:34 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] release 5.8 RC5 build in progress, was: Re: > release engineering: build release_CM3_5_8_RC5 now? > > > > SOLgnu partial explanation: > Building cm3 itself is going down the path that occurs when you > don't -DCM3_VERSION_NUMBER -DCM3_VERSION_TEXT -DCM3_LAST_CHANGED. > Not specifying them is supposed to work, but "you" are supposed to > specify them really. > Enough of a hint? (I don't have the full answer myself.) > > - Jay > > >> Date: Mon, 12 Apr 2010 17:05:48 +0200 >> From: wagner at elegosoft.com >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: >> release engineering: build release_CM3_5_8_RC5 now? >> >> Quoting Jay K : >> >> > >> > Thanks. I see the NT386 packages, but not .msi. >> >> I'll check that later; the new index isn't in place, and perhaps >> the update script is still buggy. >> >> Please have a look at the SOLgnu build though: >> >> >> http://hudson.modula3.com:8080/view/makedist/job/cm3-makedist-SOLgnu/16/console >> >> This used to work. Anything you changed? >> >> Olaf >> > >> > >> > >> > - Jay >> > >> > >> >> Date: Mon, 12 Apr 2010 13:13:11 +0200 >> >> From: wagner at elegosoft.com >> >> To: m3devel at elegosoft.com >> >> Subject: [M3devel] release 5.8 RC5 build in progress, was: Re: >> >> release engineering: build release_CM3_5_8_RC5 now? >> >> >> >> Quoting wagner at elegosoft.com: >> >> >> >> > I'm currently tagging the release branch with release_CM3_5_8_RC5. >> >> > >> >> > Are there still any objections to use the current state of the branch? >> >> > >> >> > I'll soon try a sample build on birch. >> >> >> >> As nobody has called `Stop', I've started to build the release packages >> >> for RC5. Some can already be found on the download page currently >> >> still reachable via the RC4 download (scroll down to the end). >> >> >> >> http://www.modula3.com/cm3/releng/download.html >> >> >> >> There have been 401 single changes since the last RC though :-/ >> >> See >> >> >> http://hudson.modula3.com:8080/view/makedist/job/cm3-makedist-AMD64_LINUX/changes >> >> for details. I don't know how to summarize that or even to motivate >> >> this amound of changes that late in a release. Perhaps it's best to >> >> just say nothing... >> >> >> >> If you find any problem with RC5, please let me know as soon as possible. >> >> >> >> 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 >> > -- 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 jay.krell at cornell.edu Wed Apr 14 11:18:05 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 14 Apr 2010 09:18:05 +0000 Subject: [M3devel] SchedulerPosix.IOWait, IOAlertWait Message-ID: SchedulerPosix.IOWait, IOAlertWait: I think the pthread implementation here leaks for every call. The user thread implementation has global bit arrays for a select call, that it makes large enough to hold the largest file descriptor seen. The posix implementation seems to have made them locals, good, but never cleans them up. I'll see if I can confirm and fix. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Apr 14 11:32:32 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 14 Apr 2010 09:32:32 +0000 Subject: [M3devel] SchedulerPosix.IOWait, IOAlertWait In-Reply-To: References: Message-ID: sorry, nevermind, I thought it was untraced for some reaosn. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Wed, 14 Apr 2010 09:18:05 +0000 Subject: [M3devel] SchedulerPosix.IOWait, IOAlertWait SchedulerPosix.IOWait, IOAlertWait: I think the pthread implementation here leaks for every call. The user thread implementation has global bit arrays for a select call, that it makes large enough to hold the largest file descriptor seen. The posix implementation seems to have made them locals, good, but never cleans them up. I'll see if I can confirm and fix. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Apr 14 12:44:08 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 14 Apr 2010 10:44:08 +0000 Subject: [M3devel] hidden interface vs. public Interface? hidden isn't hidden? Message-ID: I tried changing from Interface("Utime") to interface("Utime"). Now, it turns out, that is a mistake anyway, there are still uses, and they aren't going away. But even so, this change doesn't do what it is supposed to. Utime gets marked "hidden" in the .M3EXPORTS files. I haven't yet decipered the .m3x file. I'm still able to build clients e.g. m3-games/tetris. I'm certain I'm using the updated one. I even rm -rf /cm3/pkg/m3core. It seems "hidden" doesn't work? I'll have to dig into the .m3x file I think. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Wed Apr 14 13:01:26 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 14 Apr 2010 13:01:26 +0200 Subject: [M3devel] hidden interface vs. public Interface? hidden isn't hidden? Message-ID: <20100414130126.b9g9pq79escw0g8c@mail.elegosoft.com> Quoting Jay K : > > I tried changing from Interface("Utime") to interface("Utime"). > > Now, it turns out, that is a mistake anyway, there are still > uses, and they aren't going away. > > But even so, this change doesn't do what it is supposed to. > Utime gets marked "hidden" in the .M3EXPORTS files. > I haven't yet decipered the .m3x file. > I'm still able to build clients e.g. m3-games/tetris. > I'm certain I'm using the updated one. I even rm -rf /cm3/pkg/m3core. > > It seems "hidden" doesn't work? > > I'll have to dig into the .m3x file I think. I remember that in the SRC system, hidden files weren't shipped at all to the global package pool. Critical Mass changed that, because hey wanted the source to be available for browsing. I always assumed that the compiler was able to hnour the hidden state of the interface nonetheless. If it doesn't work, we should fix 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 jay.krell at cornell.edu Wed Apr 14 13:37:19 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 14 Apr 2010 11:37:19 +0000 Subject: [M3devel] hidden interface vs. public Interface? hidden isn't hidden? In-Reply-To: <20100414130126.b9g9pq79escw0g8c@mail.elegosoft.com> References: <20100414130126.b9g9pq79escw0g8c@mail.elegosoft.com> Message-ID: Given that public interface TimePosix has functions that return types from Utime, it seems reasonable, though maybe with a warning. But I think when I hid TimePosix, just as an experiment, it still made them public. Something to be looked into much later. - Jay > Date: Wed, 14 Apr 2010 13:01:26 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] hidden interface vs. public Interface? hidden isn't hidden? > > Quoting Jay K : > > > > > I tried changing from Interface("Utime") to interface("Utime"). > > > > Now, it turns out, that is a mistake anyway, there are still > > uses, and they aren't going away. > > > > But even so, this change doesn't do what it is supposed to. > > Utime gets marked "hidden" in the .M3EXPORTS files. > > I haven't yet decipered the .m3x file. > > I'm still able to build clients e.g. m3-games/tetris. > > I'm certain I'm using the updated one. I even rm -rf /cm3/pkg/m3core. > > > > It seems "hidden" doesn't work? > > > > I'll have to dig into the .m3x file I think. > > I remember that in the SRC system, hidden files weren't shipped at all > to the global package pool. Critical Mass changed that, because hey > wanted the source to be available for browsing. > > I always assumed that the compiler was able to hnour the hidden state > of the interface nonetheless. > > If it doesn't work, we should fix 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Apr 14 13:41:30 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 14 Apr 2010 11:41:30 +0000 Subject: [M3devel] checking of timezone in DateBsd.m3 vs. DatePosix.m3? Message-ID: Seems inconsistent: DateBsd.m3: IF (z = NIL) OR (z^ = Local^) THEN tm := Utime.localtime(ADR(tv.tv_sec)); ELSIF z^ = UTC^ THEN tm := Utime.gmtime(ADR(tv.tv_sec)); ELSE (* unknown timezone *) <* ASSERT FALSE *> ? DatePosix.m3: IF (z = NIL) OR (z^ = 0) THEN EVAL Utime.localtime_r (tv.tv_sec, ADR (tm)); ELSE EVAL Utime.gmtime_r (tv.tv_sec, ADR(tm)); END; ? DateBsd.m3 is the overwhelmingly used version, so presumably we should be like it. ? readonly _DateImpls = { "CYGWIN" : "DatePosix", (* hardly counts *) "DARWIN" : "DateBsd", "FREEBSD" : "DateBsd", "HPUX" : "DatePosix", (* hardly counts *) "INTERIX" : "DatePosix", (* hardly counts *) "LINUX" : "DateBsd", "NETBSD" : "DateBsd", "NT" : "DatePosix", (* not actually used *) "OPENBSD" : "DateBsd", "SOLARIS" : "DatePosix", (* counts! *) } In both cases timezone is opaque but revealed to be a branded ref to an integer. Of course, I'm going through this code again for purposes of porting to C, a) to remove struct tm, b) use http://code.google.com/p/y2038/ c) remove struct_timeval/gettimeofday. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Wed Apr 14 16:10:43 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 14 Apr 2010 16:10:43 +0200 Subject: [M3devel] more release build problems, was: RE: release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? In-Reply-To: References: <20100411171933.szof1k9n2ss48sg8@mail.elegosoft.com>, , , , <20100412131311.5ax5opbuskcw00sk@mail.elegosoft.com>, , , , , , , , , , <20100412170548.o3go4tu8ys4wgwo4@mail.elegosoft.com>, , , , , , , , , <20100413171231.bvpqvjz0g0s08k4o@mail.elegosoft.com>, <20100413205035.s01zgk7nk4gggkso@mail.elegosoft.com>, <20100413224251.m5n8tfabk004gc40@mail.elegosoft.com>, , <20100414130624.ej61zwd0dcg0w848@mail.elegosoft.com>, <20100414131755.y55odckn404ws80c@mail.elegosoft.com> Message-ID: <20100414161043.xqhxn8nr40cockko@mail.elegosoft.com> Quoting Jay K : > Olaf, something I don't understand is why the distribution building > is a separate Hudson task. > > Or more specifically, why these don't just run "all the time", > either once a day, or after checkins, or something like that. Because it is a considerable load and we build a fixed (frozen) configuration with it. Once this release is out, we may try to build packages once a day, as tinderbox did/does. > Perhaps this stuff was occuring but I wasn't noticing the failures? > I do look sometimes but not enough. We just haven't looked. Breakage can be seen at http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLgnu/ http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLgnu/lastBuild/testReport/ m3core installation fails, too: "/home/hudson/workspace/cm3-test-all-pkgs-SOLgnu/cm3/m3-libs/m3core/SOLgnu/.M3SHIP", line 4: quake runtime error: unable to copy "libm3core.so.5" to "/home/hudson/work/cm3-inst/ssol/last-ok/lib/libm3core.so.5": errno=2 libm3core.so.5 Fatal Error: package build failed I'll try to improve the checks for serious failures before the next release. Olaf > - Jay > > > > From: jay.krell at cornell.edu > To: wagner at elegosoft.com > Subject: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: > release engineering: build release_CM3_5_8_RC5 now? > Date: Wed, 14 Apr 2010 12:55:23 +0000 > > > > For cvsup/zlib: > The libz hack for Solaris wasn't in release. > I noticed and fixed another minor problem. > > > Try these files: > > > scripts/branch.quake > m3-tools/cvsup/quake/cvsup.quake > > > There is also a more conservative fix if you just take > part of the m3-tools/m3-tools/cvsup/quake/cvsup.quake change. > Just adding SOLgnu and SOLsun to the list of platforms to check. > > > - Jay > > > > > From: jay.krell at cornell.edu > To: wagner at elegosoft.com > Subject: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: > release engineering: build release_CM3_5_8_RC5 now? > Date: Wed, 14 Apr 2010 11:55:46 +0000 > > > > I commited a simple untested fix for the tar -z problem. > Need a bit longer on cvsup/zlib. > > - Jay > > > > > From: jay.krell at cornell.edu > To: wagner at elegosoft.com > Subject: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: > release engineering: build release_CM3_5_8_RC5 now? > Date: Wed, 14 Apr 2010 11:47:47 +0000 > > > > Arg. First is something to do with libz. I thought I actually built > cvsup at least once on Solaris. > Granted, I've definitely noticed that machine is slow, been > testing Posix stuff lately, but Darwin/amd64 and Linux/x86.. > > We can either use /usr/sfw/bin/gtar if it exists (it does, Sun puts > it there), or use tar followed by gzip (optionally with a pipe). > tar + gzip is presumably more portable. > > - Jay > >> Date: Wed, 14 Apr 2010 13:17:55 +0200 >> From: wagner at elegosoft.com >> To: jay.krell at cornell.edu >> Subject: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: >> release engineering: build release_CM3_5_8_RC5 now? >> >> Quoting Olaf Wagner : >> >> > The build has finished, but most of the SOLgnu archives seem to be broken: >> > >> > >> http://hudson.modula3.com:8080/view/test-install/job/cm3-test-install-SOLgnu/7/testReport/ >> > >> > Any ideas why the .M3SHIP files are missing just on this target? >> >> The log shows that package building just stopped after this failure >> in cvsup: >> >> === package m3-tools/cvsup/suplib === >> +++ cm3 -build >> -DROOT='/home/hudson/workspace/cm3-makedist-SOLgnu/cm3' >> -DCM3_VERSION_TEXT='5.8.5' -DCM3_VERSION_NUMBER='050805' >> -DCM3_LAST_CHANGED='2010-04-11' $RARGS && cm3 -ship $RARGS >> -DROOT='/home/hudson/workspace/cm3-makedist-SOLgnu/cm3' >> -DCM3_VERSION_TEXT='5.8.5' -DCM3_VERSION_NUMBER='050805' >> -DCM3_LAST_CHANGED='2010-04-11' +++ >> Undefined first referenced >> symbol in file >> inflate GzipRd.mo >> deflateEnd GzipWr.mo >> inflateEnd GzipRd.mo >> deflate GzipWr.mo >> deflateInit_ Ugzip.mo >> inflateInit_ Ugzip.mo >> ld: fatal: Symbol referencing errors. No output written to libsuplib.so.5 >> collect2: ld returned 1 exit status >> make_lib => 1 >> librarian failed building: suplib >> >> And the .deb package is broken because the Sun tar does not understand >> the -z option you seem to use... >> >> 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 hosking at cs.purdue.edu Wed Apr 14 16:22:22 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 14 Apr 2010 10:22:22 -0400 Subject: [M3devel] hidden interface vs. public Interface? hidden isn't hidden? In-Reply-To: <20100414130126.b9g9pq79escw0g8c@mail.elegosoft.com> References: <20100414130126.b9g9pq79escw0g8c@mail.elegosoft.com> Message-ID: <8D709810-3ED8-4911-8D72-1E27564C8E60@cs.purdue.edu> This being hidden *source* files are not shipped. I'm pretty sure that is still the behaviour. Jay, is it possible that you had a source file left behind from previous install? On 14 Apr 2010, at 07:01, Olaf Wagner wrote: > Quoting Jay K : > >> >> I tried changing from Interface("Utime") to interface("Utime"). >> >> Now, it turns out, that is a mistake anyway, there are still uses, and they aren't going away. >> >> But even so, this change doesn't do what it is supposed to. >> Utime gets marked "hidden" in the .M3EXPORTS files. >> I haven't yet decipered the .m3x file. >> I'm still able to build clients e.g. m3-games/tetris. >> I'm certain I'm using the updated one. I even rm -rf /cm3/pkg/m3core. >> >> It seems "hidden" doesn't work? >> >> I'll have to dig into the .m3x file I think. > > I remember that in the SRC system, hidden files weren't shipped at all > to the global package pool. Critical Mass changed that, because hey > wanted the source to be available for browsing. > > I always assumed that the compiler was able to hnour the hidden state > of the interface nonetheless. > > If it doesn't work, we should fix 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 jay.krell at cornell.edu Wed Apr 14 18:17:53 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 14 Apr 2010 16:17:53 +0000 Subject: [M3devel] hidden interface vs. public Interface? hidden isn't hidden? In-Reply-To: <8D709810-3ED8-4911-8D72-1E27564C8E60@cs.purdue.edu> References: <20100414130126.b9g9pq79escw0g8c@mail.elegosoft.com>, <8D709810-3ED8-4911-8D72-1E27564C8E60@cs.purdue.edu> Message-ID: > Jay, is it possible that you had a source file left behind from previous install? Unlikely. I thought I did rm -rf /cm3/pkg/m3core. I'm testing it again. Just to experiment, I changed all "Interface" to "interface" in m3core/src/unix/Common. It still ships 19 .i3 files to /cm3/pkg/m3core/src/unix/Common. Though I don't think that's a problem. Frontend doesn't reparse imported .i3 files, right? The information is all in .m3x? Not a big concern for me right now though. - Jay > From: hosking at cs.purdue.edu > Date: Wed, 14 Apr 2010 10:22:22 -0400 > To: wagner at elegosoft.com > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] hidden interface vs. public Interface? hidden isn't hidden? > > This being hidden *source* files are not shipped. > I'm pretty sure that is still the behaviour. > Jay, is it possible that you had a source file left behind from previous install? > > On 14 Apr 2010, at 07:01, Olaf Wagner wrote: > > > Quoting Jay K : > > > >> > >> I tried changing from Interface("Utime") to interface("Utime"). > >> > >> Now, it turns out, that is a mistake anyway, there are still uses, and they aren't going away. > >> > >> But even so, this change doesn't do what it is supposed to. > >> Utime gets marked "hidden" in the .M3EXPORTS files. > >> I haven't yet decipered the .m3x file. > >> I'm still able to build clients e.g. m3-games/tetris. > >> I'm certain I'm using the updated one. I even rm -rf /cm3/pkg/m3core. > >> > >> It seems "hidden" doesn't work? > >> > >> I'll have to dig into the .m3x file I think. > > > > I remember that in the SRC system, hidden files weren't shipped at all > > to the global package pool. Critical Mass changed that, because hey > > wanted the source to be available for browsing. > > > > I always assumed that the compiler was able to hnour the hidden state > > of the interface nonetheless. > > > > If it doesn't work, we should fix 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 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Apr 14 18:19:32 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 14 Apr 2010 16:19:32 +0000 Subject: [M3devel] more release build problems, was: RE: release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? In-Reply-To: <20100414161043.xqhxn8nr40cockko@mail.elegosoft.com> References: <20100411171933.szof1k9n2ss48sg8@mail.elegosoft.com>, , , , <20100412131311.5ax5opbuskcw00sk@mail.elegosoft.com>, , , , , , , , , , <20100412170548.o3go4tu8ys4wgwo4@mail.elegosoft.com>, , , , , , , , , <20100413171231.bvpqvjz0g0s08k4o@mail.elegosoft.com>, <20100413205035.s01zgk7nk4gggkso@mail.elegosoft.com>, <20100413224251.m5n8tfabk004gc40@mail.elegosoft.com>, , <20100414130624.ej61zwd0dcg0w848@mail.elegosoft.com>, <20100414131755.y55odckn404ws80c@mail.elegosoft.com>, , <20100414161043.xqhxn8nr40cockko@mail.elegosoft.com> Message-ID: > "HasTrestle" My fault. - Jay > Date: Wed, 14 Apr 2010 16:10:43 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: more release build problems, was: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? > > Quoting Jay K : > > > Olaf, something I don't understand is why the distribution building > > is a separate Hudson task. > > > > Or more specifically, why these don't just run "all the time", > > either once a day, or after checkins, or something like that. > > Because it is a considerable load and we build a fixed (frozen) > configuration with it. > > Once this release is out, we may try to build packages once a day, > as tinderbox did/does. > > > Perhaps this stuff was occuring but I wasn't noticing the failures? > > I do look sometimes but not enough. > > We just haven't looked. Breakage can be seen at > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLgnu/ > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLgnu/lastBuild/testReport/ > > m3core installation fails, too: > > "/home/hudson/workspace/cm3-test-all-pkgs-SOLgnu/cm3/m3-libs/m3core/SOLgnu/.M3SHIP", line 4: quake runtime error: unable to copy "libm3core.so.5" to "/home/hudson/work/cm3-inst/ssol/last-ok/lib/libm3core.so.5": > errno=2 > libm3core.so.5 Fatal Error: package build failed > > I'll try to improve the checks for serious failures before the next release. > > Olaf > > > > - Jay > > > > > > > > From: jay.krell at cornell.edu > > To: wagner at elegosoft.com > > Subject: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: > > release engineering: build release_CM3_5_8_RC5 now? > > Date: Wed, 14 Apr 2010 12:55:23 +0000 > > > > > > > > For cvsup/zlib: > > The libz hack for Solaris wasn't in release. > > I noticed and fixed another minor problem. > > > > > > Try these files: > > > > > > scripts/branch.quake > > m3-tools/cvsup/quake/cvsup.quake > > > > > > There is also a more conservative fix if you just take > > part of the m3-tools/m3-tools/cvsup/quake/cvsup.quake change. > > Just adding SOLgnu and SOLsun to the list of platforms to check. > > > > > > - Jay > > > > > > > > > > From: jay.krell at cornell.edu > > To: wagner at elegosoft.com > > Subject: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: > > release engineering: build release_CM3_5_8_RC5 now? > > Date: Wed, 14 Apr 2010 11:55:46 +0000 > > > > > > > > I commited a simple untested fix for the tar -z problem. > > Need a bit longer on cvsup/zlib. > > > > - Jay > > > > > > > > > > From: jay.krell at cornell.edu > > To: wagner at elegosoft.com > > Subject: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: > > release engineering: build release_CM3_5_8_RC5 now? > > Date: Wed, 14 Apr 2010 11:47:47 +0000 > > > > > > > > Arg. First is something to do with libz. I thought I actually built > > cvsup at least once on Solaris. > > Granted, I've definitely noticed that machine is slow, been > > testing Posix stuff lately, but Darwin/amd64 and Linux/x86.. > > > > We can either use /usr/sfw/bin/gtar if it exists (it does, Sun puts > > it there), or use tar followed by gzip (optionally with a pipe). > > tar + gzip is presumably more portable. > > > > - Jay > > > >> Date: Wed, 14 Apr 2010 13:17:55 +0200 > >> From: wagner at elegosoft.com > >> To: jay.krell at cornell.edu > >> Subject: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: > >> release engineering: build release_CM3_5_8_RC5 now? > >> > >> Quoting Olaf Wagner : > >> > >> > The build has finished, but most of the SOLgnu archives seem to be broken: > >> > > >> > > >> http://hudson.modula3.com:8080/view/test-install/job/cm3-test-install-SOLgnu/7/testReport/ > >> > > >> > Any ideas why the .M3SHIP files are missing just on this target? > >> > >> The log shows that package building just stopped after this failure > >> in cvsup: > >> > >> === package m3-tools/cvsup/suplib === > >> +++ cm3 -build > >> -DROOT='/home/hudson/workspace/cm3-makedist-SOLgnu/cm3' > >> -DCM3_VERSION_TEXT='5.8.5' -DCM3_VERSION_NUMBER='050805' > >> -DCM3_LAST_CHANGED='2010-04-11' $RARGS && cm3 -ship $RARGS > >> -DROOT='/home/hudson/workspace/cm3-makedist-SOLgnu/cm3' > >> -DCM3_VERSION_TEXT='5.8.5' -DCM3_VERSION_NUMBER='050805' > >> -DCM3_LAST_CHANGED='2010-04-11' +++ > >> Undefined first referenced > >> symbol in file > >> inflate GzipRd.mo > >> deflateEnd GzipWr.mo > >> inflateEnd GzipRd.mo > >> deflate GzipWr.mo > >> deflateInit_ Ugzip.mo > >> inflateInit_ Ugzip.mo > >> ld: fatal: Symbol referencing errors. No output written to libsuplib.so.5 > >> collect2: ld returned 1 exit status > >> make_lib => 1 > >> librarian failed building: suplib > >> > >> And the .deb package is broken because the Sun tar does not understand > >> the -z option you seem to use... > >> > >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Apr 14 18:20:39 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 14 Apr 2010 16:20:39 +0000 Subject: [M3devel] more release build problems, was: RE: release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? In-Reply-To: <20100414161043.xqhxn8nr40cockko@mail.elegosoft.com> References: <20100411171933.szof1k9n2ss48sg8@mail.elegosoft.com>, , , , <20100412131311.5ax5opbuskcw00sk@mail.elegosoft.com>, , , , , , , , , , <20100412170548.o3go4tu8ys4wgwo4@mail.elegosoft.com>, , , , , , , , , <20100413171231.bvpqvjz0g0s08k4o@mail.elegosoft.com>, <20100413205035.s01zgk7nk4gggkso@mail.elegosoft.com>, <20100413224251.m5n8tfabk004gc40@mail.elegosoft.com>, , <20100414130624.ej61zwd0dcg0w848@mail.elegosoft.com>, <20100414131755.y55odckn404ws80c@mail.elegosoft.com>, , <20100414161043.xqhxn8nr40cockko@mail.elegosoft.com> Message-ID: er. wait, that function is in release though. - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com CC: m3devel at elegosoft.com Subject: RE: more release build problems, was: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? Date: Wed, 14 Apr 2010 16:19:32 +0000 > "HasTrestle" My fault. - Jay > Date: Wed, 14 Apr 2010 16:10:43 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: more release build problems, was: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? > > Quoting Jay K : > > > Olaf, something I don't understand is why the distribution building > > is a separate Hudson task. > > > > Or more specifically, why these don't just run "all the time", > > either once a day, or after checkins, or something like that. > > Because it is a considerable load and we build a fixed (frozen) > configuration with it. > > Once this release is out, we may try to build packages once a day, > as tinderbox did/does. > > > Perhaps this stuff was occuring but I wasn't noticing the failures? > > I do look sometimes but not enough. > > We just haven't looked. Breakage can be seen at > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLgnu/ > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLgnu/lastBuild/testReport/ > > m3core installation fails, too: > > "/home/hudson/workspace/cm3-test-all-pkgs-SOLgnu/cm3/m3-libs/m3core/SOLgnu/.M3SHIP", line 4: quake runtime error: unable to copy "libm3core.so.5" to "/home/hudson/work/cm3-inst/ssol/last-ok/lib/libm3core.so.5": > errno=2 > libm3core.so.5 Fatal Error: package build failed > > I'll try to improve the checks for serious failures before the next release. > > Olaf > > > > - Jay > > > > > > > > From: jay.krell at cornell.edu > > To: wagner at elegosoft.com > > Subject: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: > > release engineering: build release_CM3_5_8_RC5 now? > > Date: Wed, 14 Apr 2010 12:55:23 +0000 > > > > > > > > For cvsup/zlib: > > The libz hack for Solaris wasn't in release. > > I noticed and fixed another minor problem. > > > > > > Try these files: > > > > > > scripts/branch.quake > > m3-tools/cvsup/quake/cvsup.quake > > > > > > There is also a more conservative fix if you just take > > part of the m3-tools/m3-tools/cvsup/quake/cvsup.quake change. > > Just adding SOLgnu and SOLsun to the list of platforms to check. > > > > > > - Jay > > > > > > > > > > From: jay.krell at cornell.edu > > To: wagner at elegosoft.com > > Subject: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: > > release engineering: build release_CM3_5_8_RC5 now? > > Date: Wed, 14 Apr 2010 11:55:46 +0000 > > > > > > > > I commited a simple untested fix for the tar -z problem. > > Need a bit longer on cvsup/zlib. > > > > - Jay > > > > > > > > > > From: jay.krell at cornell.edu > > To: wagner at elegosoft.com > > Subject: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: > > release engineering: build release_CM3_5_8_RC5 now? > > Date: Wed, 14 Apr 2010 11:47:47 +0000 > > > > > > > > Arg. First is something to do with libz. I thought I actually built > > cvsup at least once on Solaris. > > Granted, I've definitely noticed that machine is slow, been > > testing Posix stuff lately, but Darwin/amd64 and Linux/x86.. > > > > We can either use /usr/sfw/bin/gtar if it exists (it does, Sun puts > > it there), or use tar followed by gzip (optionally with a pipe). > > tar + gzip is presumably more portable. > > > > - Jay > > > >> Date: Wed, 14 Apr 2010 13:17:55 +0200 > >> From: wagner at elegosoft.com > >> To: jay.krell at cornell.edu > >> Subject: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: > >> release engineering: build release_CM3_5_8_RC5 now? > >> > >> Quoting Olaf Wagner : > >> > >> > The build has finished, but most of the SOLgnu archives seem to be broken: > >> > > >> > > >> http://hudson.modula3.com:8080/view/test-install/job/cm3-test-install-SOLgnu/7/testReport/ > >> > > >> > Any ideas why the .M3SHIP files are missing just on this target? > >> > >> The log shows that package building just stopped after this failure > >> in cvsup: > >> > >> === package m3-tools/cvsup/suplib === > >> +++ cm3 -build > >> -DROOT='/home/hudson/workspace/cm3-makedist-SOLgnu/cm3' > >> -DCM3_VERSION_TEXT='5.8.5' -DCM3_VERSION_NUMBER='050805' > >> -DCM3_LAST_CHANGED='2010-04-11' $RARGS && cm3 -ship $RARGS > >> -DROOT='/home/hudson/workspace/cm3-makedist-SOLgnu/cm3' > >> -DCM3_VERSION_TEXT='5.8.5' -DCM3_VERSION_NUMBER='050805' > >> -DCM3_LAST_CHANGED='2010-04-11' +++ > >> Undefined first referenced > >> symbol in file > >> inflate GzipRd.mo > >> deflateEnd GzipWr.mo > >> inflateEnd GzipRd.mo > >> deflate GzipWr.mo > >> deflateInit_ Ugzip.mo > >> inflateInit_ Ugzip.mo > >> ld: fatal: Symbol referencing errors. No output written to libsuplib.so.5 > >> collect2: ld returned 1 exit status > >> make_lib => 1 > >> librarian failed building: suplib > >> > >> And the .deb package is broken because the Sun tar does not understand > >> the -z option you seem to use... > >> > >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Apr 14 18:28:48 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 14 Apr 2010 16:28:48 +0000 Subject: [M3devel] more release build problems, was: RE: release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? In-Reply-To: <20100414161043.xqhxn8nr40cockko@mail.elegosoft.com> References: <20100411171933.szof1k9n2ss48sg8@mail.elegosoft.com>, , , , <20100412131311.5ax5opbuskcw00sk@mail.elegosoft.com>, , , , , , , , , , <20100412170548.o3go4tu8ys4wgwo4@mail.elegosoft.com>, , , , , , , , , <20100413171231.bvpqvjz0g0s08k4o@mail.elegosoft.com>, <20100413205035.s01zgk7nk4gggkso@mail.elegosoft.com>, <20100413224251.m5n8tfabk004gc40@mail.elegosoft.com>, , <20100414130624.ej61zwd0dcg0w848@mail.elegosoft.com>, <20100414131755.y55odckn404ws80c@mail.elegosoft.com>, , <20100414161043.xqhxn8nr40cockko@mail.elegosoft.com> Message-ID: This will help but more looking ineeded. C:\dev2\cm3.release_branch_cm3_5_8\m3-obliq>cvs -z3 commit -m "acceptable hack for release branch, don't put in head" obliqbinanim/src/m3makefile obliqbinui/src/m3makefile /usr/cvs/cm3/m3-obliq/obliqbinanim/src/m3makefile,v <-- obliqbinanim/src/m3makefile new revision: 1.1.1.1.8.2; previous revision: 1.1.1.1.8.1 /usr/cvs/cm3/m3-obliq/obliqbinui/src/m3makefile,v <-- obliqbinui/src/m3makefile new revision: 1.1.1.1.8.2; previous revision: 1.1.1.1.8.1 - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com CC: m3devel at elegosoft.com Subject: RE: more release build problems, was: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? Date: Wed, 14 Apr 2010 16:20:39 +0000 er. wait, that function is in release though. - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com CC: m3devel at elegosoft.com Subject: RE: more release build problems, was: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? Date: Wed, 14 Apr 2010 16:19:32 +0000 > "HasTrestle" My fault. - Jay > Date: Wed, 14 Apr 2010 16:10:43 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: more release build problems, was: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? > > Quoting Jay K : > > > Olaf, something I don't understand is why the distribution building > > is a separate Hudson task. > > > > Or more specifically, why these don't just run "all the time", > > either once a day, or after checkins, or something like that. > > Because it is a considerable load and we build a fixed (frozen) > configuration with it. > > Once this release is out, we may try to build packages once a day, > as tinderbox did/does. > > > Perhaps this stuff was occuring but I wasn't noticing the failures? > > I do look sometimes but not enough. > > We just haven't looked. Breakage can be seen at > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLgnu/ > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLgnu/lastBuild/testReport/ > > m3core installation fails, too: > > "/home/hudson/workspace/cm3-test-all-pkgs-SOLgnu/cm3/m3-libs/m3core/SOLgnu/.M3SHIP", line 4: quake runtime error: unable to copy "libm3core.so.5" to "/home/hudson/work/cm3-inst/ssol/last-ok/lib/libm3core.so.5": > errno=2 > libm3core.so.5 Fatal Error: package build failed > > I'll try to improve the checks for serious failures before the next release. > > Olaf > > > > - Jay > > > > > > > > From: jay.krell at cornell.edu > > To: wagner at elegosoft.com > > Subject: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: > > release engineering: build release_CM3_5_8_RC5 now? > > Date: Wed, 14 Apr 2010 12:55:23 +0000 > > > > > > > > For cvsup/zlib: > > The libz hack for Solaris wasn't in release. > > I noticed and fixed another minor problem. > > > > > > Try these files: > > > > > > scripts/branch.quake > > m3-tools/cvsup/quake/cvsup.quake > > > > > > There is also a more conservative fix if you just take > > part of the m3-tools/m3-tools/cvsup/quake/cvsup.quake change. > > Just adding SOLgnu and SOLsun to the list of platforms to check. > > > > > > - Jay > > > > > > > > > > From: jay.krell at cornell.edu > > To: wagner at elegosoft.com > > Subject: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: > > release engineering: build release_CM3_5_8_RC5 now? > > Date: Wed, 14 Apr 2010 11:55:46 +0000 > > > > > > > > I commited a simple untested fix for the tar -z problem. > > Need a bit longer on cvsup/zlib. > > > > - Jay > > > > > > > > > > From: jay.krell at cornell.edu > > To: wagner at elegosoft.com > > Subject: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: > > release engineering: build release_CM3_5_8_RC5 now? > > Date: Wed, 14 Apr 2010 11:47:47 +0000 > > > > > > > > Arg. First is something to do with libz. I thought I actually built > > cvsup at least once on Solaris. > > Granted, I've definitely noticed that machine is slow, been > > testing Posix stuff lately, but Darwin/amd64 and Linux/x86.. > > > > We can either use /usr/sfw/bin/gtar if it exists (it does, Sun puts > > it there), or use tar followed by gzip (optionally with a pipe). > > tar + gzip is presumably more portable. > > > > - Jay > > > >> Date: Wed, 14 Apr 2010 13:17:55 +0200 > >> From: wagner at elegosoft.com > >> To: jay.krell at cornell.edu > >> Subject: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: > >> release engineering: build release_CM3_5_8_RC5 now? > >> > >> Quoting Olaf Wagner : > >> > >> > The build has finished, but most of the SOLgnu archives seem to be broken: > >> > > >> > > >> http://hudson.modula3.com:8080/view/test-install/job/cm3-test-install-SOLgnu/7/testReport/ > >> > > >> > Any ideas why the .M3SHIP files are missing just on this target? > >> > >> The log shows that package building just stopped after this failure > >> in cvsup: > >> > >> === package m3-tools/cvsup/suplib === > >> +++ cm3 -build > >> -DROOT='/home/hudson/workspace/cm3-makedist-SOLgnu/cm3' > >> -DCM3_VERSION_TEXT='5.8.5' -DCM3_VERSION_NUMBER='050805' > >> -DCM3_LAST_CHANGED='2010-04-11' $RARGS && cm3 -ship $RARGS > >> -DROOT='/home/hudson/workspace/cm3-makedist-SOLgnu/cm3' > >> -DCM3_VERSION_TEXT='5.8.5' -DCM3_VERSION_NUMBER='050805' > >> -DCM3_LAST_CHANGED='2010-04-11' +++ > >> Undefined first referenced > >> symbol in file > >> inflate GzipRd.mo > >> deflateEnd GzipWr.mo > >> inflateEnd GzipRd.mo > >> deflate GzipWr.mo > >> deflateInit_ Ugzip.mo > >> inflateInit_ Ugzip.mo > >> ld: fatal: Symbol referencing errors. No output written to libsuplib.so.5 > >> collect2: ld returned 1 exit status > >> make_lib => 1 > >> librarian failed building: suplib > >> > >> And the .deb package is broken because the Sun tar does not understand > >> the -z option you seem to use... > >> > >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Wed Apr 14 18:40:02 2010 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Wed, 14 Apr 2010 16:40:02 +0000 (GMT) Subject: [M3devel] hidden interface vs. public Interface? hidden isn't hidden? In-Reply-To: <8D709810-3ED8-4911-8D72-1E27564C8E60@cs.purdue.edu> Message-ID: <962394.19120.qm@web23606.mail.ird.yahoo.com> Hi all: there is a quake directive to export or hide interfaces to packages in cm3 this is from the DEC SRC packages and later pm3, heck the information is the same in all: http://modula3.com/cm3/doc/help/cm3/m3build/hiding.html http://cs.wheaton.edu/~cgray/misc/m3/pm3pkg/m3build/src/html/hiding.html http://www.cs.arizona.edu/~collberg/Research/Modula-3/modula-3/html/m3build/hiding.html Please note they mention they accept capitalization convention in commands initial letter but partly to support old style m3makefiles so they provide that to clarify better I think you can try with export_interface("Utime") and to check capitalization convention with /* interface("Utime")*/ Interface("Utime") export_interface("Utime") I remember there are some issues tough if the Unix file has owner only read permissions because the file will be exported as it is so other users included m3browser won't be able to read the file (for instance if you exported as root user and reading from the web in m3browser), same sort of things happens in NT386. Though in the above links mention they had this convention of uppercase first 'i' of Interface("Utime") I know related examples of this kind of missing of meaning, as as source directory called 'SRC' is not accepted (i.e it doesn't find source directory) in Unix platforms but it was accepted in NT386 (in DEC SRC M3, i.e it builds) perhaps because of capital letter symbols (in)discrimination in terminal platforms I guess (I'm aware unix make looks for Makefile and if not for makefile). Now I don't know what was is the case in M3/PC Klagenfurt (but as I see the the m3makefiles they had in M3PC 1994 release are C preprocessor directives with special function names a kind of similar to quake and mostly beginning in capital letters) port because it was a DOS platform and they wrote a shell into which can build programs (they didn't have m3make DEC SRC program which because it worked with unix make), I know the long names are ignored in DOS terminals (they substitute the last part with a ~) but they sort of fixed this behavior in the builder/shell they wrote using a name map see: http://web.archive.org/web/20000520073936/www.ifi.uni-klu.ac.at/Modula-3/m3pc/m3pc.html Thanks, I hope it helps --- El mi?, 14/4/10, Tony Hosking escribi?: > De: Tony Hosking > Asunto: Re: [M3devel] hidden interface vs. public Interface? hidden isn't hidden? > Para: "Olaf Wagner" > CC: m3devel at elegosoft.com > Fecha: mi?rcoles, 14 de abril, 2010 09:22 > This being hidden *source* files are > not shipped. > I'm pretty sure that is still the behaviour. > Jay, is it possible that you had a source file left behind > from previous install? > > On 14 Apr 2010, at 07:01, Olaf Wagner wrote: > > > Quoting Jay K : > > > >> > >> I tried changing from Interface("Utime") to > interface("Utime"). > >> > >> Now, it turns out, that is a mistake > anyway, there are still uses, and they aren't going > away. > >> > >> But even so, this change doesn't do what it is > supposed to. > >> Utime gets marked "hidden" in the .M3EXPORTS > files. > >> I haven't yet decipered the .m3x file. > >> I'm still able to build clients e.g. > m3-games/tetris. > >> I'm certain I'm using the updated one. I even rm > -rf /cm3/pkg/m3core. > >> > >> It seems "hidden" doesn't work? > >> > >> I'll have to dig into the .m3x file I think. > > > > I remember that in the SRC system, hidden files > weren't shipped at all > > to the global package pool. Critical Mass changed > that, because hey > > wanted the source to be available for browsing. > > > > I always assumed that the compiler was able to hnour > the hidden state > > of the interface nonetheless. > > > > If it doesn't work, we should fix 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 jay.krell at cornell.edu Wed Apr 14 18:48:04 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 14 Apr 2010 16:48:04 +0000 Subject: [M3devel] more release build problems, was: RE: release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? In-Reply-To: References: <20100411171933.szof1k9n2ss48sg8@mail.elegosoft.com>, , , ,,<20100412131311.5ax5opbuskcw00sk@mail.elegosoft.com>, , , ,,, , , , , ,,<20100412170548.o3go4tu8ys4wgwo4@mail.elegosoft.com>, , , ,,, , , , , , , , , <20100413171231.bvpqvjz0g0s08k4o@mail.elegosoft.com>, , <20100413205035.s01zgk7nk4gggkso@mail.elegosoft.com>, , <20100413224251.m5n8tfabk004gc40@mail.elegosoft.com>, , , , <20100414130624.ej61zwd0dcg0w848@mail.elegosoft.com>, , <20100414131755.y55odckn404ws80c@mail.elegosoft.com>, , , , <20100414161043.xqhxn8nr40cockko@mail.elegosoft.com>, Message-ID: postgres95/test and odbc/test I added filtering to match the package, should help. That's still not everything. The m3core error is odd. The cvsup one about merger.tmpl also. - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com Date: Wed, 14 Apr 2010 16:28:48 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] more release build problems, was: RE: release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? This will help but more looking ineeded. C:\dev2\cm3.release_branch_cm3_5_8\m3-obliq>cvs -z3 commit -m "acceptable hack for release branch, don't put in head" obliqbinanim/src/m3makefile obliqbinui/src/m3makefile /usr/cvs/cm3/m3-obliq/obliqbinanim/src/m3makefile,v <-- obliqbinanim/src/m3makefile new revision: 1.1.1.1.8.2; previous revision: 1.1.1.1.8.1 /usr/cvs/cm3/m3-obliq/obliqbinui/src/m3makefile,v <-- obliqbinui/src/m3makefile new revision: 1.1.1.1.8.2; previous revision: 1.1.1.1.8.1 - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com CC: m3devel at elegosoft.com Subject: RE: more release build problems, was: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? Date: Wed, 14 Apr 2010 16:20:39 +0000 er. wait, that function is in release though. - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com CC: m3devel at elegosoft.com Subject: RE: more release build problems, was: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? Date: Wed, 14 Apr 2010 16:19:32 +0000 > "HasTrestle" My fault. - Jay > Date: Wed, 14 Apr 2010 16:10:43 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: more release build problems, was: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? > > Quoting Jay K : > > > Olaf, something I don't understand is why the distribution building > > is a separate Hudson task. > > > > Or more specifically, why these don't just run "all the time", > > either once a day, or after checkins, or something like that. > > Because it is a considerable load and we build a fixed (frozen) > configuration with it. > > Once this release is out, we may try to build packages once a day, > as tinderbox did/does. > > > Perhaps this stuff was occuring but I wasn't noticing the failures? > > I do look sometimes but not enough. > > We just haven't looked. Breakage can be seen at > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLgnu/ > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLgnu/lastBuild/testReport/ > > m3core installation fails, too: > > "/home/hudson/workspace/cm3-test-all-pkgs-SOLgnu/cm3/m3-libs/m3core/SOLgnu/.M3SHIP", line 4: quake runtime error: unable to copy "libm3core.so.5" to "/home/hudson/work/cm3-inst/ssol/last-ok/lib/libm3core.so.5": > errno=2 > libm3core.so.5 Fatal Error: package build failed > > I'll try to improve the checks for serious failures before the next release. > > Olaf > > > > - Jay > > > > > > > > From: jay.krell at cornell.edu > > To: wagner at elegosoft.com > > Subject: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: > > release engineering: build release_CM3_5_8_RC5 now? > > Date: Wed, 14 Apr 2010 12:55:23 +0000 > > > > > > > > For cvsup/zlib: > > The libz hack for Solaris wasn't in release. > > I noticed and fixed another minor problem. > > > > > > Try these files: > > > > > > scripts/branch.quake > > m3-tools/cvsup/quake/cvsup.quake > > > > > > There is also a more conservative fix if you just take > > part of the m3-tools/m3-tools/cvsup/quake/cvsup.quake change. > > Just adding SOLgnu and SOLsun to the list of platforms to check. > > > > > > - Jay > > > > > > > > > > From: jay.krell at cornell.edu > > To: wagner at elegosoft.com > > Subject: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: > > release engineering: build release_CM3_5_8_RC5 now? > > Date: Wed, 14 Apr 2010 11:55:46 +0000 > > > > > > > > I commited a simple untested fix for the tar -z problem. > > Need a bit longer on cvsup/zlib. > > > > - Jay > > > > > > > > > > From: jay.krell at cornell.edu > > To: wagner at elegosoft.com > > Subject: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: > > release engineering: build release_CM3_5_8_RC5 now? > > Date: Wed, 14 Apr 2010 11:47:47 +0000 > > > > > > > > Arg. First is something to do with libz. I thought I actually built > > cvsup at least once on Solaris. > > Granted, I've definitely noticed that machine is slow, been > > testing Posix stuff lately, but Darwin/amd64 and Linux/x86.. > > > > We can either use /usr/sfw/bin/gtar if it exists (it does, Sun puts > > it there), or use tar followed by gzip (optionally with a pipe). > > tar + gzip is presumably more portable. > > > > - Jay > > > >> Date: Wed, 14 Apr 2010 13:17:55 +0200 > >> From: wagner at elegosoft.com > >> To: jay.krell at cornell.edu > >> Subject: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: > >> release engineering: build release_CM3_5_8_RC5 now? > >> > >> Quoting Olaf Wagner : > >> > >> > The build has finished, but most of the SOLgnu archives seem to be broken: > >> > > >> > > >> http://hudson.modula3.com:8080/view/test-install/job/cm3-test-install-SOLgnu/7/testReport/ > >> > > >> > Any ideas why the .M3SHIP files are missing just on this target? > >> > >> The log shows that package building just stopped after this failure > >> in cvsup: > >> > >> === package m3-tools/cvsup/suplib === > >> +++ cm3 -build > >> -DROOT='/home/hudson/workspace/cm3-makedist-SOLgnu/cm3' > >> -DCM3_VERSION_TEXT='5.8.5' -DCM3_VERSION_NUMBER='050805' > >> -DCM3_LAST_CHANGED='2010-04-11' $RARGS && cm3 -ship $RARGS > >> -DROOT='/home/hudson/workspace/cm3-makedist-SOLgnu/cm3' > >> -DCM3_VERSION_TEXT='5.8.5' -DCM3_VERSION_NUMBER='050805' > >> -DCM3_LAST_CHANGED='2010-04-11' +++ > >> Undefined first referenced > >> symbol in file > >> inflate GzipRd.mo > >> deflateEnd GzipWr.mo > >> inflateEnd GzipRd.mo > >> deflate GzipWr.mo > >> deflateInit_ Ugzip.mo > >> inflateInit_ Ugzip.mo > >> ld: fatal: Symbol referencing errors. No output written to libsuplib.so.5 > >> collect2: ld returned 1 exit status > >> make_lib => 1 > >> librarian failed building: suplib > >> > >> And the .deb package is broken because the Sun tar does not understand > >> the -z option you seem to use... > >> > >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Apr 14 18:59:15 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 14 Apr 2010 16:59:15 +0000 Subject: [M3devel] more release build problems, was: RE: release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? In-Reply-To: References: <20100411171933.szof1k9n2ss48sg8@mail.elegosoft.com>, , ,,,,<20100412131311.5ax5opbuskcw00sk@mail.elegosoft.com>, , ,,,,, , , , ,,,,<20100412170548.o3go4tu8ys4wgwo4@mail.elegosoft.com>, , ,,,,,,, , , ,,, ,,, ,,<20100413171231.bvpqvjz0g0s08k4o@mail.elegosoft.com>, ,,<20100413205035.s01zgk7nk4gggkso@mail.elegosoft.com>, ,,<20100413224251.m5n8tfabk004gc40@mail.elegosoft.com>, ,,, ,,<20100414130624.ej61zwd0dcg0w848@mail.elegosoft.com>, ,,<20100414131755.y55odckn404ws80c@mail.elegosoft.com>, ,,, , , <20100414161043.xqhxn8nr40cockko@mail.elegosoft.com>, , , Message-ID: pattern matching has some other odd problem, though this could be something in head or my machine: new source -> compiling regex.i3 "../src/regex.i3", line 20: Could not find a legal alignment for the packed type . it's just: regmatch_t = RECORD rm_so: off_t; rm_eo: off_t; END; though again, this is head and SOLsun. - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com Date: Wed, 14 Apr 2010 16:48:04 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] more release build problems, was: RE: release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? postgres95/test and odbc/test I added filtering to match the package, should help. That's still not everything. The m3core error is odd. The cvsup one about merger.tmpl also. - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com Date: Wed, 14 Apr 2010 16:28:48 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] more release build problems, was: RE: release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? This will help but more looking ineeded. C:\dev2\cm3.release_branch_cm3_5_8\m3-obliq>cvs -z3 commit -m "acceptable hack for release branch, don't put in head" obliqbinanim/src/m3makefile obliqbinui/src/m3makefile /usr/cvs/cm3/m3-obliq/obliqbinanim/src/m3makefile,v <-- obliqbinanim/src/m3makefile new revision: 1.1.1.1.8.2; previous revision: 1.1.1.1.8.1 /usr/cvs/cm3/m3-obliq/obliqbinui/src/m3makefile,v <-- obliqbinui/src/m3makefile new revision: 1.1.1.1.8.2; previous revision: 1.1.1.1.8.1 - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com CC: m3devel at elegosoft.com Subject: RE: more release build problems, was: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? Date: Wed, 14 Apr 2010 16:20:39 +0000 er. wait, that function is in release though. - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com CC: m3devel at elegosoft.com Subject: RE: more release build problems, was: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? Date: Wed, 14 Apr 2010 16:19:32 +0000 > "HasTrestle" My fault. - Jay > Date: Wed, 14 Apr 2010 16:10:43 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: more release build problems, was: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: release engineering: build release_CM3_5_8_RC5 now? > > Quoting Jay K : > > > Olaf, something I don't understand is why the distribution building > > is a separate Hudson task. > > > > Or more specifically, why these don't just run "all the time", > > either once a day, or after checkins, or something like that. > > Because it is a considerable load and we build a fixed (frozen) > configuration with it. > > Once this release is out, we may try to build packages once a day, > as tinderbox did/does. > > > Perhaps this stuff was occuring but I wasn't noticing the failures? > > I do look sometimes but not enough. > > We just haven't looked. Breakage can be seen at > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLgnu/ > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLgnu/lastBuild/testReport/ > > m3core installation fails, too: > > "/home/hudson/workspace/cm3-test-all-pkgs-SOLgnu/cm3/m3-libs/m3core/SOLgnu/.M3SHIP", line 4: quake runtime error: unable to copy "libm3core.so.5" to "/home/hudson/work/cm3-inst/ssol/last-ok/lib/libm3core.so.5": > errno=2 > libm3core.so.5 Fatal Error: package build failed > > I'll try to improve the checks for serious failures before the next release. > > Olaf > > > > - Jay > > > > > > > > From: jay.krell at cornell.edu > > To: wagner at elegosoft.com > > Subject: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: > > release engineering: build release_CM3_5_8_RC5 now? > > Date: Wed, 14 Apr 2010 12:55:23 +0000 > > > > > > > > For cvsup/zlib: > > The libz hack for Solaris wasn't in release. > > I noticed and fixed another minor problem. > > > > > > Try these files: > > > > > > scripts/branch.quake > > m3-tools/cvsup/quake/cvsup.quake > > > > > > There is also a more conservative fix if you just take > > part of the m3-tools/m3-tools/cvsup/quake/cvsup.quake change. > > Just adding SOLgnu and SOLsun to the list of platforms to check. > > > > > > - Jay > > > > > > > > > > From: jay.krell at cornell.edu > > To: wagner at elegosoft.com > > Subject: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: > > release engineering: build release_CM3_5_8_RC5 now? > > Date: Wed, 14 Apr 2010 11:55:46 +0000 > > > > > > > > I commited a simple untested fix for the tar -z problem. > > Need a bit longer on cvsup/zlib. > > > > - Jay > > > > > > > > > > From: jay.krell at cornell.edu > > To: wagner at elegosoft.com > > Subject: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: > > release engineering: build release_CM3_5_8_RC5 now? > > Date: Wed, 14 Apr 2010 11:47:47 +0000 > > > > > > > > Arg. First is something to do with libz. I thought I actually built > > cvsup at least once on Solaris. > > Granted, I've definitely noticed that machine is slow, been > > testing Posix stuff lately, but Darwin/amd64 and Linux/x86.. > > > > We can either use /usr/sfw/bin/gtar if it exists (it does, Sun puts > > it there), or use tar followed by gzip (optionally with a pipe). > > tar + gzip is presumably more portable. > > > > - Jay > > > >> Date: Wed, 14 Apr 2010 13:17:55 +0200 > >> From: wagner at elegosoft.com > >> To: jay.krell at cornell.edu > >> Subject: RE: [M3devel] release 5.8 RC5 build in progress, was: Re: > >> release engineering: build release_CM3_5_8_RC5 now? > >> > >> Quoting Olaf Wagner : > >> > >> > The build has finished, but most of the SOLgnu archives seem to be broken: > >> > > >> > > >> http://hudson.modula3.com:8080/view/test-install/job/cm3-test-install-SOLgnu/7/testReport/ > >> > > >> > Any ideas why the .M3SHIP files are missing just on this target? > >> > >> The log shows that package building just stopped after this failure > >> in cvsup: > >> > >> === package m3-tools/cvsup/suplib === > >> +++ cm3 -build > >> -DROOT='/home/hudson/workspace/cm3-makedist-SOLgnu/cm3' > >> -DCM3_VERSION_TEXT='5.8.5' -DCM3_VERSION_NUMBER='050805' > >> -DCM3_LAST_CHANGED='2010-04-11' $RARGS && cm3 -ship $RARGS > >> -DROOT='/home/hudson/workspace/cm3-makedist-SOLgnu/cm3' > >> -DCM3_VERSION_TEXT='5.8.5' -DCM3_VERSION_NUMBER='050805' > >> -DCM3_LAST_CHANGED='2010-04-11' +++ > >> Undefined first referenced > >> symbol in file > >> inflate GzipRd.mo > >> deflateEnd GzipWr.mo > >> inflateEnd GzipRd.mo > >> deflate GzipWr.mo > >> deflateInit_ Ugzip.mo > >> inflateInit_ Ugzip.mo > >> ld: fatal: Symbol referencing errors. No output written to libsuplib.so.5 > >> collect2: ld returned 1 exit status > >> make_lib => 1 > >> librarian failed building: suplib > >> > >> And the .deb package is broken because the Sun tar does not understand > >> the -z option you seem to use... > >> > >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Apr 14 18:51:40 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 14 Apr 2010 16:51:40 +0000 Subject: [M3devel] hidden interface vs. public Interface? hidden isn't hidden? In-Reply-To: <962394.19120.qm@web23606.mail.ird.yahoo.com> References: <8D709810-3ED8-4911-8D72-1E27564C8E60@cs.purdue.edu>, <962394.19120.qm@web23606.mail.ird.yahoo.com> Message-ID: Daniel, "interface" and "Interface" aren't filenames. There's no issue regarding file name lengths and file system case sensitivity. I can see that "interface" results in "hidden" in the .m3exports file, at least. There are (many) parts of the system that I'm unaware how they work. Like, does importing just read the .m3x file, or not? Hopefully yes, because it is very efficiently encoded. But I don't know. - Jay > Date: Wed, 14 Apr 2010 16:40:02 +0000 > From: dabenavidesd at yahoo.es > To: wagner at elegosoft.com; hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] hidden interface vs. public Interface? hidden isn't hidden? > > Hi all: > there is a quake directive to export or hide interfaces to packages in cm3 this is from the DEC SRC packages and later pm3, heck the information is the same in all: > http://modula3.com/cm3/doc/help/cm3/m3build/hiding.html > http://cs.wheaton.edu/~cgray/misc/m3/pm3pkg/m3build/src/html/hiding.html > http://www.cs.arizona.edu/~collberg/Research/Modula-3/modula-3/html/m3build/hiding.html > > Please note they mention they accept capitalization convention in commands initial letter but partly to support old style m3makefiles so they provide that to clarify better > > I think you can try with > export_interface("Utime") > and to check capitalization convention with > /* interface("Utime")*/ > Interface("Utime") > export_interface("Utime") > > I remember there are some issues tough if the Unix file has owner only read permissions because the file will be exported as it is so other users included m3browser won't be able to read the file (for instance if you exported as root user and reading from the web in m3browser), same sort of things happens in NT386. > > Though in the above links mention they had this convention of uppercase first 'i' of Interface("Utime") > > I know related examples of this kind of missing of meaning, as as source directory called 'SRC' is not accepted (i.e it doesn't find source directory) in Unix platforms but it was accepted in NT386 (in DEC SRC M3, i.e it builds) perhaps because of capital letter symbols (in)discrimination in terminal platforms I guess (I'm aware unix make looks for Makefile and if not for makefile). > Now I don't know what was is the case in M3/PC Klagenfurt (but as I see the the m3makefiles they had in M3PC 1994 release are C preprocessor directives with special function names a kind of similar to quake and mostly beginning in capital letters) port because it was a DOS platform and they wrote a shell into which can build programs (they didn't have m3make DEC SRC program which because it worked with unix make), I know the long names are ignored in DOS terminals (they substitute the last part with a ~) but they sort of fixed this behavior in the builder/shell they wrote using a name map see: http://web.archive.org/web/20000520073936/www.ifi.uni-klu.ac.at/Modula-3/m3pc/m3pc.html > > Thanks, I hope it helps > > --- El mi?, 14/4/10, Tony Hosking escribi?: > > > De: Tony Hosking > > Asunto: Re: [M3devel] hidden interface vs. public Interface? hidden isn't hidden? > > Para: "Olaf Wagner" > > CC: m3devel at elegosoft.com > > Fecha: mi?rcoles, 14 de abril, 2010 09:22 > > This being hidden *source* files are > > not shipped. > > I'm pretty sure that is still the behaviour. > > Jay, is it possible that you had a source file left behind > > from previous install? > > > > On 14 Apr 2010, at 07:01, Olaf Wagner wrote: > > > > > Quoting Jay K : > > > > > >> > > >> I tried changing from Interface("Utime") to > > interface("Utime"). > > >> > > >> Now, it turns out, that is a mistake > > anyway, there are still uses, and they aren't going > > away. > > >> > > >> But even so, this change doesn't do what it is > > supposed to. > > >> Utime gets marked "hidden" in the .M3EXPORTS > > files. > > >> I haven't yet decipered the .m3x file. > > >> I'm still able to build clients e.g. > > m3-games/tetris. > > >> I'm certain I'm using the updated one. I even rm > > -rf /cm3/pkg/m3core. > > >> > > >> It seems "hidden" doesn't work? > > >> > > >> I'll have to dig into the .m3x file I think. > > > > > > I remember that in the SRC system, hidden files > > weren't shipped at all > > > to the global package pool. Critical Mass changed > > that, because hey > > > wanted the source to be available for browsing. > > > > > > I always assumed that the compiler was able to hnour > > the hidden state > > > of the interface nonetheless. > > > > > > If it doesn't work, we should fix 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 > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Apr 15 08:45:48 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 15 Apr 2010 06:45:48 +0000 Subject: [M3devel] Modula-3/C interop in Date/Time? Message-ID: Is this legal/correct? Date.i3: TYPE TimeZone <: REFANY; VAR Local, UTC: TimeZone; (* granted, will maybe change these to extern *) Date.m3:? REVEAL TimeZone = BRANDED "Date.TimeZone" REF INTEGER; ? DatePosixC.c: static const int Local = 0; static const int UTC = 1; extern const int const * const Date__Local = &Local; extern const int const * const Date__UTC = &UTC; ? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Apr 15 14:18:44 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 15 Apr 2010 12:18:44 +0000 Subject: [M3devel] date/time stuff In-Reply-To: References: <20100415114428.52D0D2474004@birch.elegosoft.com>, Message-ID: I still have small lingering concerns here. - when to call tzset? Historically we called at in the Posix version startup only. I believe localtime implicitcally calls tzset, so we kind of had it backwards? - foo vs. foo_r? I changed any to _r. However there are differences relative, again, to tzset. It seems to me, program can be long running, can span a timezone change. Calling tzset just at startup, not great. - So maybe a better approach is DisableScheduling/EnableScheduling Don't use the _r functions? and/or call tzset more often? - I think I should probably introduce an "idealized" "DatePosix.T" just containing INTEGERs or LONGINTs and no subranges. Besides making the layout totally clear, unlike today, that will also cause subrange checks when the Modula-3 code copies the C values out. Today there are no subrange checks. One needs to be careful defining the ranges, due to various "leap" conditions (not just days, but also seconds, etc.) - I have not run tests that span timezone changes. I think that should be done. It's not difficult actually. Just put an infinite loop around p235 and require user to press enter between iterations, meanwhile changing the system clock/timezone. I can get to that within a week. - There is some possibility here of sharing implementation with Win32! ANSI C has localtime/gmtime, of course and msvcr*.dll do expose daylight, tzname[]. Possibly we can have just one "Posix" implementation. Instead of today's three implementations. - Jay From: jay.krell at cornell.edu To: jkrell at elego.de; m3commit at elegosoft.com Date: Thu, 15 Apr 2010 11:49:09 +0000 Subject: Re: [M3commit] CVS Update: cm3 diff attached > Date: Thu, 15 Apr 2010 13:44:28 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/04/15 13:44:28 > > Modified files: > cm3/m3-libs/m3core/src/: m3core.h > cm3/m3-libs/m3core/src/time/POSIX/: DatePosix.m3 DatePosixC.c > TimePosix.i3 TimePosix.m3 > TimePosixC.c m3makefile > cm3/m3-libs/m3core/src/unix/: m3makefile > cm3/m3-libs/m3core/src/unix/Common/: Unix.i3 Utime.i3 UtimeC.c > Utypes.i3 > Added files: > cm3/m3-libs/m3core/src/time/POSIX/: DatePosix.i3 > > Log message: > eliminate struct_tm (somewhat platform specific) > eliminate struct_timeval (somewhat platform specific) > eliminate FDSet (somewhat platform specific) > eliminate MAX_FDSET (somewhat platform specific) > eliminate lots of functions from Utime > i.e. functions that use those types, like gettimeofday, localtime, gmtime > functions that were used only in m3core/src/time/*.m3 like get_timezone, altzone > > eliminate "all" the m3core/src/unix platform dependent directories *except* > Solaris/sparc32 (SOLgnu/SOLsun) for stack walking support > uin-common vs. uin-len > > change time_t to be 64bits for all platforms > but underlying implementation still needs work (elaborated below) > > tested on SOLgnu, AMD64_DARWIN, LINUXLIBC6 > It compiles and the assertions all hold. > Local and utc data appears correct, cross checking with date and date -u, including > setting Linux/x86 and Solaris/sparc32 system clocks back to Jan 1 2010. > Did not test functionaly on Darwin or any BSD (but note that Linux uses the BSD code). > > still to do: > use 64bit time_t code from http://code.google.com/p/y2038/ > combine some of lingering code in UtimeC.c into Time/DatePosixC.c, as static functions > We can actually add stuff back like localtime/gmtime trafficing in 64bit time_t, > as long as we use our own carefully controlled/copied types (i.e. omit the > extra two fields in struct tm). Just as well as we can provide gettimeofday, select. If we must. > Maybe test on Darwin, *BSD, Cygwin, Interix, etc. > Test in other timezones. > Enable a regularly run test? > Consider relayout Date.T to it doesn't have padding in the middle or perhaps anywhere. > (Hard to avoid if there are subranges, will be padded at least at end.) > > We can't achieve 64bit gettimeofday or file timestamps beyond year 2038 > but if you fill in a Date.T with year > 2038, that can be useful and be made > to work. It should roundtrip with Time.T and be printable. > > structure is a little odd > DatePosix.i3, TimePosix.i3 describe C code > DatePosix.m3, TimePosix.m3 expose Date, Time, call into DatePosix, TimePosix > This is just to reuse existing names or name patterns. > We could just as well introduce new interfaes TimeC, DateC, TimeInternal, DateTimeInternal, etc. > > Note: This also fixes the UTC timezone on Solaris, Interix, HP-UX, Cygwin, which appear to have been historically broken. > > Note: This also uncovered that my Solaris clock was behind by a few minutes. > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 1.txt URL: From jay.krell at cornell.edu Thu Apr 15 15:48:04 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 15 Apr 2010 13:48:04 +0000 Subject: [M3devel] date/time stuff In-Reply-To: References: <20100415114428.52D0D2474004@birch.elegosoft.com>, Message-ID: I forgot to mention another old bug I noticed here: they never check the return value of localtime/localtime_r/gmtime/gmtime_r. It is NULL for error. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Subject: RE: date/time stuff Date: Thu, 15 Apr 2010 13:47:03 +0000 Something went very wrong in the history here. Long ago. Not today. I think we never got the 5.1 changes out of a branch, or something. In version 1.2 I accidentally did copy them out of the branch somehow, and then in 1.3 I put it back, since I wasn't intending to do that. I don't know how I would have gotten that content. Maybe I scrolled down in the cvsweb and selected what I thought was previous, as part of editing/reverting my work. At the time now way I would have used cvs upd -r. I didn't learn till much later. See http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/time/POSIX/DatePosix.m3.diff?r1=1.1;r2=1.3 1.1 and 1.3 are identical. 1.1 to 1.4 http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/time/POSIX/DatePosix.m3.diff?r1=1.1;r2=1.4 is the change I was after. That leaves me uncertain which historical behavior to aim for. :( Need to write more tests.. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Subject: date/time stuff Date: Thu, 15 Apr 2010 12:18:44 +0000 I still have small lingering concerns here. - when to call tzset? Historically we called at in the Posix version startup only. I believe localtime implicitcally calls tzset, so we kind of had it backwards? - foo vs. foo_r? I changed any to _r. However there are differences relative, again, to tzset. It seems to me, program can be long running, can span a timezone change. Calling tzset just at startup, not great. - So maybe a better approach is DisableScheduling/EnableScheduling Don't use the _r functions? and/or call tzset more often? - I think I should probably introduce an "idealized" "DatePosix.T" just containing INTEGERs or LONGINTs and no subranges. Besides making the layout totally clear, unlike today, that will also cause subrange checks when the Modula-3 code copies the C values out. Today there are no subrange checks. One needs to be careful defining the ranges, due to various "leap" conditions (not just days, but also seconds, etc.) - I have not run tests that span timezone changes. I think that should be done. It's not difficult actually. Just put an infinite loop around p235 and require user to press enter between iterations, meanwhile changing the system clock/timezone. I can get to that within a week. - There is some possibility here of sharing implementation with Win32! ANSI C has localtime/gmtime, of course and msvcr*.dll do expose daylight, tzname[]. Possibly we can have just one "Posix" implementation. Instead of today's three implementations. - Jay From: jay.krell at cornell.edu To: jkrell at elego.de; m3commit at elegosoft.com Date: Thu, 15 Apr 2010 11:49:09 +0000 Subject: Re: [M3commit] CVS Update: cm3 diff attached > Date: Thu, 15 Apr 2010 13:44:28 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/04/15 13:44:28 > > Modified files: > cm3/m3-libs/m3core/src/: m3core.h > cm3/m3-libs/m3core/src/time/POSIX/: DatePosix.m3 DatePosixC.c > TimePosix.i3 TimePosix.m3 > TimePosixC.c m3makefile > cm3/m3-libs/m3core/src/unix/: m3makefile > cm3/m3-libs/m3core/src/unix/Common/: Unix.i3 Utime.i3 UtimeC.c > Utypes.i3 > Added files: > cm3/m3-libs/m3core/src/time/POSIX/: DatePosix.i3 > > Log message: > eliminate struct_tm (somewhat platform specific) > eliminate struct_timeval (somewhat platform specific) > eliminate FDSet (somewhat platform specific) > eliminate MAX_FDSET (somewhat platform specific) > eliminate lots of functions from Utime > i.e. functions that use those types, like gettimeofday, localtime, gmtime > functions that were used only in m3core/src/time/*.m3 like get_timezone, altzone > > eliminate "all" the m3core/src/unix platform dependent directories *except* > Solaris/sparc32 (SOLgnu/SOLsun) for stack walking support > uin-common vs. uin-len > > change time_t to be 64bits for all platforms > but underlying implementation still needs work (elaborated below) > > tested on SOLgnu, AMD64_DARWIN, LINUXLIBC6 > It compiles and the assertions all hold. > Local and utc data appears correct, cross checking with date and date -u, including > setting Linux/x86 and Solaris/sparc32 system clocks back to Jan 1 2010. > Did not test functionaly on Darwin or any BSD (but note that Linux uses the BSD code). > > still to do: > use 64bit time_t code from http://code.google.com/p/y2038/ > combine some of lingering code in UtimeC.c into Time/DatePosixC.c, as static functions > We can actually add stuff back like localtime/gmtime trafficing in 64bit time_t, > as long as we use our own carefully controlled/copied types (i.e. omit the > extra two fields in struct tm). Just as well as we can provide gettimeofday, select. If we must. > Maybe test on Darwin, *BSD, Cygwin, Interix, etc. > Test in other timezones. > Enable a regularly run test? > Consider relayout Date.T to it doesn't have padding in the middle or perhaps anywhere. > (Hard to avoid if there are subranges, will be padded at least at end.) > > We can't achieve 64bit gettimeofday or file timestamps beyond year 2038 > but if you fill in a Date.T with year > 2038, that can be useful and be made > to work. It should roundtrip with Time.T and be printable. > > structure is a little odd > DatePosix.i3, TimePosix.i3 describe C code > DatePosix.m3, TimePosix.m3 expose Date, Time, call into DatePosix, TimePosix > This is just to reuse existing names or name patterns. > We could just as well introduce new interfaes TimeC, DateC, TimeInternal, DateTimeInternal, etc. > > Note: This also fixes the UTC timezone on Solaris, Interix, HP-UX, Cygwin, which appear to have been historically broken. > > Note: This also uncovered that my Solaris clock was behind by a few minutes. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Apr 15 15:47:03 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 15 Apr 2010 13:47:03 +0000 Subject: [M3devel] date/time stuff In-Reply-To: References: <20100415114428.52D0D2474004@birch.elegosoft.com>, Message-ID: Something went very wrong in the history here. Long ago. Not today. I think we never got the 5.1 changes out of a branch, or something. In version 1.2 I accidentally did copy them out of the branch somehow, and then in 1.3 I put it back, since I wasn't intending to do that. I don't know how I would have gotten that content. Maybe I scrolled down in the cvsweb and selected what I thought was previous, as part of editing/reverting my work. At the time now way I would have used cvs upd -r. I didn't learn till much later. See http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/time/POSIX/DatePosix.m3.diff?r1=1.1;r2=1.3 1.1 and 1.3 are identical. 1.1 to 1.4 http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/time/POSIX/DatePosix.m3.diff?r1=1.1;r2=1.4 is the change I was after. That leaves me uncertain which historical behavior to aim for. :( Need to write more tests.. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Subject: date/time stuff Date: Thu, 15 Apr 2010 12:18:44 +0000 I still have small lingering concerns here. - when to call tzset? Historically we called at in the Posix version startup only. I believe localtime implicitcally calls tzset, so we kind of had it backwards? - foo vs. foo_r? I changed any to _r. However there are differences relative, again, to tzset. It seems to me, program can be long running, can span a timezone change. Calling tzset just at startup, not great. - So maybe a better approach is DisableScheduling/EnableScheduling Don't use the _r functions? and/or call tzset more often? - I think I should probably introduce an "idealized" "DatePosix.T" just containing INTEGERs or LONGINTs and no subranges. Besides making the layout totally clear, unlike today, that will also cause subrange checks when the Modula-3 code copies the C values out. Today there are no subrange checks. One needs to be careful defining the ranges, due to various "leap" conditions (not just days, but also seconds, etc.) - I have not run tests that span timezone changes. I think that should be done. It's not difficult actually. Just put an infinite loop around p235 and require user to press enter between iterations, meanwhile changing the system clock/timezone. I can get to that within a week. - There is some possibility here of sharing implementation with Win32! ANSI C has localtime/gmtime, of course and msvcr*.dll do expose daylight, tzname[]. Possibly we can have just one "Posix" implementation. Instead of today's three implementations. - Jay From: jay.krell at cornell.edu To: jkrell at elego.de; m3commit at elegosoft.com Date: Thu, 15 Apr 2010 11:49:09 +0000 Subject: Re: [M3commit] CVS Update: cm3 diff attached > Date: Thu, 15 Apr 2010 13:44:28 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/04/15 13:44:28 > > Modified files: > cm3/m3-libs/m3core/src/: m3core.h > cm3/m3-libs/m3core/src/time/POSIX/: DatePosix.m3 DatePosixC.c > TimePosix.i3 TimePosix.m3 > TimePosixC.c m3makefile > cm3/m3-libs/m3core/src/unix/: m3makefile > cm3/m3-libs/m3core/src/unix/Common/: Unix.i3 Utime.i3 UtimeC.c > Utypes.i3 > Added files: > cm3/m3-libs/m3core/src/time/POSIX/: DatePosix.i3 > > Log message: > eliminate struct_tm (somewhat platform specific) > eliminate struct_timeval (somewhat platform specific) > eliminate FDSet (somewhat platform specific) > eliminate MAX_FDSET (somewhat platform specific) > eliminate lots of functions from Utime > i.e. functions that use those types, like gettimeofday, localtime, gmtime > functions that were used only in m3core/src/time/*.m3 like get_timezone, altzone > > eliminate "all" the m3core/src/unix platform dependent directories *except* > Solaris/sparc32 (SOLgnu/SOLsun) for stack walking support > uin-common vs. uin-len > > change time_t to be 64bits for all platforms > but underlying implementation still needs work (elaborated below) > > tested on SOLgnu, AMD64_DARWIN, LINUXLIBC6 > It compiles and the assertions all hold. > Local and utc data appears correct, cross checking with date and date -u, including > setting Linux/x86 and Solaris/sparc32 system clocks back to Jan 1 2010. > Did not test functionaly on Darwin or any BSD (but note that Linux uses the BSD code). > > still to do: > use 64bit time_t code from http://code.google.com/p/y2038/ > combine some of lingering code in UtimeC.c into Time/DatePosixC.c, as static functions > We can actually add stuff back like localtime/gmtime trafficing in 64bit time_t, > as long as we use our own carefully controlled/copied types (i.e. omit the > extra two fields in struct tm). Just as well as we can provide gettimeofday, select. If we must. > Maybe test on Darwin, *BSD, Cygwin, Interix, etc. > Test in other timezones. > Enable a regularly run test? > Consider relayout Date.T to it doesn't have padding in the middle or perhaps anywhere. > (Hard to avoid if there are subranges, will be padded at least at end.) > > We can't achieve 64bit gettimeofday or file timestamps beyond year 2038 > but if you fill in a Date.T with year > 2038, that can be useful and be made > to work. It should roundtrip with Time.T and be printable. > > structure is a little odd > DatePosix.i3, TimePosix.i3 describe C code > DatePosix.m3, TimePosix.m3 expose Date, Time, call into DatePosix, TimePosix > This is just to reuse existing names or name patterns. > We could just as well introduce new interfaes TimeC, DateC, TimeInternal, DateTimeInternal, etc. > > Note: This also fixes the UTC timezone on Solaris, Interix, HP-UX, Cygwin, which appear to have been historically broken. > > Note: This also uncovered that my Solaris clock was behind by a few minutes. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Apr 15 16:43:23 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 15 Apr 2010 14:43:23 +0000 Subject: [M3devel] deleting most of m3core/src/unix? Message-ID: Ok..maybe now time to delete all of m3core/src/unix except for uin-*, Common, and part of solaris-2-x? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Apr 15 18:55:52 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 15 Apr 2010 12:55:52 -0400 Subject: [M3devel] Modula-3/C interop in Date/Time? In-Reply-To: References: Message-ID: <7C7408D0-9A40-4988-BADA-A9FD8C15D388@cs.purdue.edu> Excepting that INTEGER is not the same as int on 64-bit platforms. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 15 Apr 2010, at 02:45, Jay K wrote: > Is this legal/correct? > > > Date.i3: > TYPE TimeZone <: REFANY; > VAR Local, UTC: TimeZone; (* granted, will maybe change these to extern *) > > > Date.m3:? > REVEAL TimeZone = BRANDED "Date.TimeZone" REF INTEGER; > ? > > DatePosixC.c: > static const int Local = 0; > static const int UTC = 1; > extern const int const * const Date__Local = &Local; > extern const int const * const Date__UTC = &UTC; > ? > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Apr 15 23:26:06 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 15 Apr 2010 21:26:06 +0000 Subject: [M3devel] Modula-3/C interop in Date/Time? In-Reply-To: <7C7408D0-9A40-4988-BADA-A9FD8C15D388@cs.purdue.edu> References: , <7C7408D0-9A40-4988-BADA-A9FD8C15D388@cs.purdue.edu> Message-ID: Oops, right, of course. Important to get the things right I know to keep the question clear/narrow. - Jay From: hosking at cs.purdue.edu Date: Thu, 15 Apr 2010 12:55:52 -0400 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] Modula-3/C interop in Date/Time? Excepting that INTEGER is not the same as int on 64-bit platforms. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 15 Apr 2010, at 02:45, Jay K wrote: Is this legal/correct? Date.i3: TYPE TimeZone <: REFANY; VAR Local, UTC: TimeZone; (* granted, will maybe change these to extern *) Date.m3:? REVEAL TimeZone = BRANDED "Date.TimeZone" REF INTEGER; ? DatePosixC.c: static const int Local = 0; static const int UTC = 1; extern const int const * const Date__Local = &Local; extern const int const * const Date__UTC = &UTC; ? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcolebur at SCIRES.COM Fri Apr 16 00:10:44 2010 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Thu, 15 Apr 2010 18:10:44 -0400 Subject: [M3devel] Modula-3/C interop in Date/Time? In-Reply-To: References: , <7C7408D0-9A40-4988-BADA-A9FD8C15D388@cs.purdue.edu> Message-ID: Jay: I?m still catching up after being in hospital, but noticed you are working on the Date.i3/m3 interface and module. There is a problem that I?d like to post on the newsgroup that may be related. I?m not sure if the problem is due to the way Date.i3/m3 is coded, or perhaps a problem in the network objects stub generator, but I thought whilst you are looking at Date.i3/m3 something might trigger in your mind about how to fix the problem. I have several interfaces that export a Network Object. Of course, these get processed by the network objects stub generator at compile time. For some of these, the generated files fail to compile due to Date.i3 not being listed in the IMPORT list. Since these offending modules are generated at compile time, it?s not a programming error in the new source package that is being compiled. The way I work around the problem is by editing the generated files after the compile fails. Namely, I go to the target folder (in this case NT386) and edit the generated m3 files by adding ?IMPORT Date;?, then recompile and all is well. Of course, the next time you erase the target folder, change the underlying interface, or run ?cm3 -clean?, the generated file has to be created again and you have to go thru the compile-edit-compile cycle again to repair the problem. If you are delivering source code to a customer, you then have to document the work-around for them so that they can get the package to compile. I reported this problem years ago, but that was back before we were tracking bugs using the new system. It could be that the way Date.i3/m3 is coded is causing the stub generator not to think it needs to import it, or it could be that the stub generator isn?t doing its job right in the first place. Now after saying all this, I know I should provide a concrete example. I?ll have to go back and see if I ever reduced the code to a smaller set that demonstrates the problem. Otherwise, I can?t give anyone the full source code because it was a ?work-for-hire? and I don?t have the right to publish these sources. Let me know if you want a concrete example and I?ll see what I can do. Regards, Randy From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K Sent: Thursday, April 15, 2010 5:26 PM To: Tony Cc: m3devel Subject: Re: [M3devel] Modula-3/C interop in Date/Time? Oops, right, of course. Important to get the things right I know to keep the question clear/narrow. - Jay ________________________________ From: hosking at cs.purdue.edu Date: Thu, 15 Apr 2010 12:55:52 -0400 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] Modula-3/C interop in Date/Time? Excepting that INTEGER is not the same as int on 64-bit platforms. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 15 Apr 2010, at 02:45, Jay K wrote: Is this legal/correct? Date.i3: TYPE TimeZone <: REFANY; VAR Local, UTC: TimeZone; (* granted, will maybe change these to extern *) Date.m3:? REVEAL TimeZone = BRANDED "Date.TimeZone" REF INTEGER; ? DatePosixC.c: static const int Local = 0; static const int UTC = 1; extern const int const * const Date__Local = &Local; extern const int const * const Date__UTC = &UTC; ? - Jay ________________________________ CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This email may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from reviewing, copying, using, disclosing or distributing to others the information in this email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require advance export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Fri Apr 16 00:44:07 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 15 Apr 2010 17:44:07 -0500 Subject: [M3devel] Modula-3/C interop in Date/Time? In-Reply-To: References: Message-ID: <4BC796B7.7090707@lcwb.coop> Since these pointer variables are initialized by C code and their referents are also provided by C code as global variables, shouldn't the type be untraced? I suppose that, since they don't point into the traced heap, the collector implementation we have would quietly ignore them as roots. But that's relying on implementation- dependent information. Also, if someone created a field of type Date.TimeZone, (or an array of them) in a traced-heap-allocated object, which is a perfectly legitimate thing to do, what would our collector do then? Jay K wrote: > Is this legal/correct? > > > Date.i3: > TYPE TimeZone <: REFANY; > VAR Local, UTC: TimeZone; (* granted, will maybe change these to extern *) > > > Date.m3:? > REVEAL TimeZone = BRANDED "Date.TimeZone" REF INTEGER; > ? > > DatePosixC.c: > static const int Local = 0; > static const int UTC = 1; > extern const int const * const Date__Local = &Local; > extern const int const * const Date__UTC = &UTC; > ? > > - Jay From jay.krell at cornell.edu Fri Apr 16 01:13:23 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 15 Apr 2010 23:13:23 +0000 Subject: [M3devel] Modula-3/C interop in Date/Time? In-Reply-To: References: , , <7C7408D0-9A40-4988-BADA-A9FD8C15D388@cs.purdue.edu>, , Message-ID: Randy, I think I understand but yes please commit a small concrete example like in m3-sys/m3tests/src/p2/p237 or such. I think this is a bug in the stub generator. Probably time/date could workaround it with slight restructuring/renaming. But probably should fix the stub generator. While at it, maybe have it stop outputing unused stuff that triggers so many warnings... - Jay From: rcolebur at SCIRES.COM To: m3devel at elegosoft.com Date: Thu, 15 Apr 2010 18:10:44 -0400 Subject: Re: [M3devel] Modula-3/C interop in Date/Time? Jay: I?m still catching up after being in hospital, but noticed you are working on the Date.i3/m3 interface and module. There is a problem that I?d like to post on the newsgroup that may be related. I?m not sure if the problem is due to the way Date.i3/m3 is coded, or perhaps a problem in the network objects stub generator, but I thought whilst you are looking at Date.i3/m3 something might trigger in your mind about how to fix the problem. I have several interfaces that export a Network Object. Of course, these get processed by the network objects stub generator at compile time. For some of these, the generated files fail to compile due to Date.i3 not being listed in the IMPORT list. Since these offending modules are generated at compile time, it?s not a programming error in the new source package that is being compiled. The way I work around the problem is by editing the generated files after the compile fails. Namely, I go to the target folder (in this case NT386) and edit the generated m3 files by adding ?IMPORT Date;?, then recompile and all is well. Of course, the next time you erase the target folder, change the underlying interface, or run ?cm3 ?clean?, the generated file has to be created again and you have to go thru the compile-edit-compile cycle again to repair the problem. If you are delivering source code to a customer, you then have to document the work-around for them so that they can get the package to compile. I reported this problem years ago, but that was back before we were tracking bugs using the new system. It could be that the way Date.i3/m3 is coded is causing the stub generator not to think it needs to import it, or it could be that the stub generator isn?t doing its job right in the first place. Now after saying all this, I know I should provide a concrete example. I?ll have to go back and see if I ever reduced the code to a smaller set that demonstrates the problem. Otherwise, I can?t give anyone the full source code because it was a ?work-for-hire? and I don?t have the right to publish these sources. Let me know if you want a concrete example and I?ll see what I can do. Regards, Randy From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K Sent: Thursday, April 15, 2010 5:26 PM To: Tony Cc: m3devel Subject: Re: [M3devel] Modula-3/C interop in Date/Time? Oops, right, of course. Important to get the things right I know to keep the question clear/narrow. - Jay From: hosking at cs.purdue.edu Date: Thu, 15 Apr 2010 12:55:52 -0400 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] Modula-3/C interop in Date/Time? Excepting that INTEGER is not the same as int on 64-bit platforms. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 15 Apr 2010, at 02:45, Jay K wrote: Is this legal/correct? Date.i3: TYPE TimeZone <: REFANY; VAR Local, UTC: TimeZone; (* granted, will maybe change these to extern *) Date.m3:? REVEAL TimeZone = BRANDED "Date.TimeZone" REF INTEGER; ? DatePosixC.c: static const int Local = 0; static const int UTC = 1; extern const int const * const Date__Local = &Local; extern const int const * const Date__UTC = &UTC; ? - Jay CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This email may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from reviewing, copying, using, disclosing or distributing to others the information in this email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require advance export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Fri Apr 16 00:55:58 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 15 Apr 2010 17:55:58 -0500 Subject: [M3devel] Modula-3/C interop in Date/Time? In-Reply-To: References: , <7C7408D0-9A40-4988-BADA-A9FD8C15D388@cs.purdue.edu> Message-ID: <4BC7997E.5050708@lcwb.coop> Coleburn, Randy wrote: > Jay: > > > > I?m still catching up after being in hospital, but noticed you are > working on the Date.i3/m3 interface and module. > > > > There is a problem that I?d like to post on the newsgroup that may be > related. > > > > I?m not sure if the problem is due to the way Date.i3/m3 is coded, or > perhaps a problem in the network objects stub generator, but I thought > whilst you are looking at Date.i3/m3 something might trigger in your > mind about how to fix the problem. > > > > I have several interfaces that export a Network Object. Of course, > these get processed by the network objects stub generator at compile > time. For some of these, the generated files fail to compile due to > Date.i3 not being listed in the IMPORT list. > > > > Since these offending modules are generated at compile time, it?s not a > programming error in the new source package that is being compiled. > > > > The way I work around the problem is by editing the generated files > after the compile fails. Namely, I go to the target folder (in this > case NT386) and edit the generated m3 files by adding ?IMPORT Date;?, > then recompile and all is well. > > > > Of course, the next time you erase the target folder, change the > underlying interface, or run ?cm3 ?clean?, the generated file has to be > created again and you have to go thru the compile-edit-compile cycle > again to repair the problem. If you are delivering source code to a > customer, you then have to document the work-around for them so that > they can get the package to compile. > > > > I reported this problem years ago, but that was back before we were > tracking bugs using the new system. > > > > It could be that the way Date.i3/m3 is coded is causing the stub > generator not to think it needs to import it, or it could be that the > stub generator isn?t doing its job right in the first place. I can't think of a way this could be anything but a bug in stubgen. The very fact (and only the fact) that the generated stub code refers to Date necessitates the IMPORT Date, regardless of what is coded in interface Date or what within Date is being referred to. Is the reference to Date in the generated stub derived from a reference to Date in the interface that stubgen is processing, or is it produced within stubgen itself? Actually, either way, stubgen should produce the IMPORT. > > > > Now after saying all this, I know I should provide a concrete example. > I?ll have to go back and see if I ever reduced the code to a smaller set > that demonstrates the problem. Otherwise, I can?t give anyone the full > source code because it was a ?work-for-hire? and I don?t have the right > to publish these sources. > > > > Let me know if you want a concrete example and I?ll see what I can do. > > > > Regards, > > Randy > > > > *From:* jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] *On Behalf Of > *Jay K > *Sent:* Thursday, April 15, 2010 5:26 PM > *To:* Tony > *Cc:* m3devel > *Subject:* Re: [M3devel] Modula-3/C interop in Date/Time? > > > > Oops, right, of course. Important to get the things right I know to keep > the question clear/narrow. > > - Jay > > > > ------------------------------------------------------------------------ > > From: hosking at cs.purdue.edu > Date: Thu, 15 Apr 2010 12:55:52 -0400 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Modula-3/C interop in Date/Time? > > Excepting that INTEGER is not the same as int on 64-bit platforms. > > > > Antony Hosking | Associate Professor | Computer Science | Purdue University > > 305 N. University Street | West Lafayette | IN 47907 | USA > > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > > > > > > On 15 Apr 2010, at 02:45, Jay K wrote: > > > > Is this legal/correct? > > > Date.i3: > TYPE TimeZone <: REFANY; > VAR Local, UTC: TimeZone; (* granted, will maybe change these to > extern *) > > > Date.m3:? > REVEAL TimeZone = BRANDED "Date.TimeZone" REF INTEGER; > ? > > DatePosixC.c: > static const int Local = 0; > static const int UTC = 1; > extern const int const * const Date__Local = &Local; > extern const int const * const Date__UTC = &UTC; > ? > > - Jay > > > > > ------------------------------------------------------------------------ > CONFIDENTIALITY NOTICE: This email and any attachments are intended > solely for the use of the named recipient(s). This email may contain > confidential and/or proprietary information of Scientific Research > Corporation. If you are not a named recipient, you are prohibited from > reviewing, copying, using, disclosing or distributing to others the > information in this email and attachments. If you believe you have > received this email in error, please notify the sender immediately and > permanently delete the email, any attachments, and all copies thereof > from any drives or storage media and destroy any printouts of the email > or attachments. > > EXPORT COMPLIANCE NOTICE: This email and any attachments may contain > technical data subject to U.S export restrictions under the > International Traffic in Arms Regulations (ITAR) or the Export > Administration Regulations (EAR). Export or transfer of this technical > data and/or related information to any foreign person(s) or entity(ies), > either within the U.S. or outside of the U.S., may require advance > export authorization by the appropriate U.S. Government agency prior to > export or transfer. In addition, technical data may not be exported or > transferred to certain countries or specified designated nationals > identified by U.S. embargo controls without prior export authorization. > By accepting this email and any attachments, all recipients confirm that > they understand and will comply with all applicable ITAR, EAR and > embargo compliance requirements. From jay.krell at cornell.edu Fri Apr 16 01:17:38 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 15 Apr 2010 23:17:38 +0000 Subject: [M3devel] Modula-3/C interop in Date/Time? In-Reply-To: <4BC796B7.7090707@lcwb.coop> References: , <4BC796B7.7090707@lcwb.coop> Message-ID: Rodney, right, I was wondering about traced vs. untraced also. I think having a traced pointer point outside the traced heap is ok though. The data will never be collected, the pointer never updated. If the untraced data were ever freed (such as e.g. unloading the .dll! Which people usually forget about as a scenario..) then the traced pointers would go stale and there'd be a safety problem. In either case I'm not "rewriting" it, because there is a "unified interface" between Posix and Win32, and I can't make it <*external*> in one but not the other, unless I fork the file, not particularly worthwhile. - Jay > Date: Thu, 15 Apr 2010 17:44:07 -0500 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Modula-3/C interop in Date/Time? > > Since these pointer variables are initialized by > C code and their referents are also provided by C code > as global variables, shouldn't the type be untraced? > > I suppose that, since they don't point into the traced > heap, the collector implementation we have would quietly > ignore them as roots. But that's relying on implementation- > dependent information. > > Also, if someone created a field of type Date.TimeZone, > (or an array of them) in a traced-heap-allocated object, > which is a perfectly legitimate thing to do, what would > our collector do then? > > > > Jay K wrote: > > Is this legal/correct? > > > > > > Date.i3: > > TYPE TimeZone <: REFANY; > > VAR Local, UTC: TimeZone; (* granted, will maybe change these to extern *) > > > > > > Date.m3:? > > REVEAL TimeZone = BRANDED "Date.TimeZone" REF INTEGER; > > ? > > > > DatePosixC.c: > > static const int Local = 0; > > static const int UTC = 1; > > extern const int const * const Date__Local = &Local; > > extern const int const * const Date__UTC = &UTC; > > ? > > > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Apr 16 04:08:35 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 15 Apr 2010 22:08:35 -0400 Subject: [M3devel] Modula-3/C interop in Date/Time? In-Reply-To: References: , <4BC796B7.7090707@lcwb.coop> Message-ID: On 15 Apr 2010, at 19:17, Jay K wrote: > Rodney, right, I was wondering about traced vs. untraced also. I think having a traced pointer point outside the traced heap is ok though. The data will never be collected, the pointer never updated. There are assertions in the @M3paranoid collector that will complain if a reference outside the heap is not to a TEXT literal. Those should be the only ones we see. Correctness dictates that we use UNTRACED references (ADDRESS, UNTRACED REF...) here. > If the untraced data were ever freed (such as e.g. unloading the .dll! Which people usually forget about as a scenario..) then the traced pointers would go stale and there'd be a safety problem. > > > In either case I'm not "rewriting" it, because there is a "unified interface" between Posix and Win32, and I can't make it <*external*> in one but not the other, unless I fork the file, not particularly worthwhile. > > > - Jay > > > Date: Thu, 15 Apr 2010 17:44:07 -0500 > > From: rodney_bates at lcwb.coop > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] Modula-3/C interop in Date/Time? > > > > Since these pointer variables are initialized by > > C code and their referents are also provided by C code > > as global variables, shouldn't the type be untraced? > > > > I suppose that, since they don't point into the traced > > heap, the collector implementation we have would quietly > > ignore them as roots. But that's relying on implementation- > > dependent information. > > > > Also, if someone created a field of type Date.TimeZone, > > (or an array of them) in a traced-heap-allocated object, > > which is a perfectly legitimate thing to do, what would > > our collector do then? > > > > > > > > Jay K wrote: > > > Is this legal/correct? > > > > > > > > > Date.i3: > > & gt; TYPE TimeZone <: REFANY; > > > VAR Local, UTC: TimeZone; (* granted, will maybe change these to extern *) > > > > > > > > > Date.m3:? > > > REVEAL TimeZone = BRANDED "Date.TimeZone" REF INTEGER; > > > ? > > > > > > DatePosixC.c: > > > static const int Local = 0; > > > static const int UTC = 1; > > > extern const int const * const Date__Local = &Local; > > > extern const int const * const Date__UTC = &UTC; > > > ? > > > > > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Apr 16 04:06:14 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 15 Apr 2010 22:06:14 -0400 Subject: [M3devel] Modula-3/C interop in Date/Time? In-Reply-To: <4BC796B7.7090707@lcwb.coop> References: <4BC796B7.7090707@lcwb.coop> Message-ID: Indeed! UNTRACED. On 15 Apr 2010, at 18:44, Rodney M. Bates wrote: > Since these pointer variables are initialized by > C code and their referents are also provided by C code > as global variables, shouldn't the type be untraced? > > I suppose that, since they don't point into the traced > heap, the collector implementation we have would quietly > ignore them as roots. But that's relying on implementation- > dependent information. > > Also, if someone created a field of type Date.TimeZone, > (or an array of them) in a traced-heap-allocated object, > which is a perfectly legitimate thing to do, what would > our collector do then? > > > > Jay K wrote: >> Is this legal/correct? >> >> >> Date.i3: >> TYPE TimeZone <: REFANY; >> VAR Local, UTC: TimeZone; (* granted, will maybe change these to extern *) >> >> >> Date.m3:? >> REVEAL TimeZone = BRANDED "Date.TimeZone" REF INTEGER; >> ? >> >> DatePosixC.c: >> static const int Local = 0; >> static const int UTC = 1; >> extern const int const * const Date__Local = &Local; >> extern const int const * const Date__UTC = &UTC; >> ? >> >> - Jay From jay.krell at cornell.edu Fri Apr 16 06:24:43 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 16 Apr 2010 04:24:43 +0000 Subject: [M3devel] Modula-3/C interop in Date/Time? In-Reply-To: References: , <4BC796B7.7090707@lcwb.coop>, Message-ID: But then unsafe, right? - Jay > From: hosking at cs.purdue.edu > Date: Thu, 15 Apr 2010 22:06:14 -0400 > To: rodney_bates at lcwb.coop > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Modula-3/C interop in Date/Time? > > Indeed! UNTRACED. > > > On 15 Apr 2010, at 18:44, Rodney M. Bates wrote: > > > Since these pointer variables are initialized by > > C code and their referents are also provided by C code > > as global variables, shouldn't the type be untraced? > > > > I suppose that, since they don't point into the traced > > heap, the collector implementation we have would quietly > > ignore them as roots. But that's relying on implementation- > > dependent information. > > > > Also, if someone created a field of type Date.TimeZone, > > (or an array of them) in a traced-heap-allocated object, > > which is a perfectly legitimate thing to do, what would > > our collector do then? > > > > > > > > Jay K wrote: > >> Is this legal/correct? > >> > >> > >> Date.i3: > >> TYPE TimeZone <: REFANY; > >> VAR Local, UTC: TimeZone; (* granted, will maybe change these to extern *) > >> > >> > >> Date.m3:? > >> REVEAL TimeZone = BRANDED "Date.TimeZone" REF INTEGER; > >> ? > >> > >> DatePosixC.c: > >> static const int Local = 0; > >> static const int UTC = 1; > >> extern const int const * const Date__Local = &Local; > >> extern const int const * const Date__UTC = &UTC; > >> ? > >> > >> - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.async.caltech.edu Fri Apr 16 09:00:34 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Fri, 16 Apr 2010 00:00:34 -0700 Subject: [M3devel] Modula-3/C interop in Date/Time? In-Reply-To: References: , <4BC796B7.7090707@lcwb.coop>, Message-ID: <20100416070034.9C0911A20EB@async.async.caltech.edu> I don't think there's anything unsafe about UNTRACED. It's DISPOSE that's unsafe... Mika Jay K writes: >--_cbaca81c-f322-4f31-8684-e7f171e67f3d_ >Content-Type: text/plain; charset="iso-2022-jp" >Content-Transfer-Encoding: 7bit > >But then unsafe, right? > > - Jay > >> From: hosking at cs.purdue.edu >> Date: Thu, 15 Apr 2010 22:06:14 -0400 >> To: rodney_bates at lcwb.coop >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] Modula-3/C interop in Date/Time? >> >> Indeed! UNTRACED. >> >> >> On 15 Apr 2010, at 18:44, Rodney M. Bates wrote: >> >> > Since these pointer variables are initialized by >> > C code and their referents are also provided by C code >> > as global variables, shouldn't the type be untraced? >> > >> > I suppose that, since they don't point into the traced >> > heap, the collector implementation we have would quietly >> > ignore them as roots. But that's relying on implementation- >> > dependent information. >> > >> > Also, if someone created a field of type Date.TimeZone, >> > (or an array of them) in a traced-heap-allocated object, > > which is a perfectly legitimate thing to do, what would >> > our collector do then? >> > >> > >> > >> > Jay K wrote: >> >> Is this legal/correct? >> >> >> >> >> >> Date.i3: >> >> TYPE TimeZone <: REFANY; >> >> VAR Local, UTC: TimeZone; (* granted, will maybe change these to extern *) >> >> >> >> >> >> Date.m3:$B!!(B >> >> REVEAL TimeZone = BRANDED "Date.TimeZone" REF INTEGER; >> >> $B!!(B >> >> >> >> DatePosixC.c: >> >> static const int Local = 0; >> >> static const int UTC = 1; >> >> extern const int const * const Date__Local = &Local; >> >> extern const int const * const Date__UTC = &UTC; >> >> $B!!(B >> >> >> >> - Jay >> > >--_cbaca81c-f322-4f31-8684-e7f171e67f3d_ >Content-Type: text/html; charset="iso-2022-jp" >Content-Transfer-Encoding: 7bit > > > > > >But then unsafe, right?

- Jay

> From: hosking@cs.purdue.edu
> Date: Thu, 15 Apr 2010 22:06:14 -0400
> To: rodney_bates& >#64;lcwb.coop
> CC: m3devel@elegosoft.com
> Subject: Re: [M3devel] Modula-3/C interop in Date/Time?
>
> Indeed! UNTRACED.
>
> < >br>> On 15 Apr 2010, at 18:44, Rodney M. Bates wrote:
>
> > Since these pointer variables are initialized by
> > C code and their referents are also provided by C > code
> > as global variables, shouldn't the type be untraced?
> >
> > I suppose that, since they don't point into the traced
> > heap, the collect >or implementation we have would quietly
> > ignore them as roots. But that's relying on implementation-
> > dependent information.
> >
> > Also, if someon >e created a field of type Date.TimeZone,
> > > ; (or an array of them) in a traced-heap-allocated object,
> > which is a perfectly legitimate thing to do, what would
> > our collector do then?
> >
>> >
> >
> > Jay K wrote:
> >> Is this legal/correct?
> >>
> >>
> >> Date.i3:
> >> TYPE TimeZone > <: REFANY;
> >> VAR Local, UTC: TimeZone; (* granted, will maybe change these to extern *)
> >>
> >>
> >> > Date.m3: 
> >> REVEAL TimeZone = BRANDED "Date.TimeZone" REF INTEGER;
> >>  
> >>
> >> DatePosixC.c:
>> >> static const int Local = 0;
> >> static const int UTC = 1;
> >> extern const int const * const Date__Local = &Local;
> > >> extern const int const * const Dat > e__UTC = &UTC;
> >>  
> >>
> >> - Jay
>
> >--_cbaca81c-f322-4f31-8684-e7f171e67f3d_-- From jay.krell at cornell.edu Fri Apr 16 10:18:29 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 16 Apr 2010 08:18:29 +0000 Subject: [M3devel] Modula-3/C interop in Date/Time? In-Reply-To: <20100416070034.9C0911A20EB@async.async.caltech.edu> References: , , <4BC796B7.7090707@lcwb.coop>, , , , <20100416070034.9C0911A20EB@async.async.caltech.edu> Message-ID: Isn't making them unsafe? ADR? I'll try.. - Jay > To: jay.krell at cornell.edu > Date: Fri, 16 Apr 2010 00:00:34 -0700 > From: mika at async.async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Modula-3/C interop in Date/Time? > > I don't think there's anything unsafe about UNTRACED. > > It's DISPOSE that's unsafe... > > Mika > > Jay K writes: > >--_cbaca81c-f322-4f31-8684-e7f171e67f3d_ > >Content-Type: text/plain; charset="iso-2022-jp" > >Content-Transfer-Encoding: 7bit > > > >But then unsafe, right? > > > > - Jay > > > >> From: hosking at cs.purdue.edu > >> Date: Thu, 15 Apr 2010 22:06:14 -0400 > >> To: rodney_bates at lcwb.coop > >> CC: m3devel at elegosoft.com > >> Subject: Re: [M3devel] Modula-3/C interop in Date/Time? > >> > >> Indeed! UNTRACED. > >> > >> > >> On 15 Apr 2010, at 18:44, Rodney M. Bates wrote: > >> > >> > Since these pointer variables are initialized by > >> > C code and their referents are also provided by C code > >> > as global variables, shouldn't the type be untraced? > >> > > >> > I suppose that, since they don't point into the traced > >> > heap, the collector implementation we have would quietly > >> > ignore them as roots. But that's relying on implementation- > >> > dependent information. > >> > > >> > Also, if someone created a field of type Date.TimeZone, > >> > (or an array of them) in a traced-heap-allocated object, > > > which is a perfectly legitimate thing to do, what would > >> > our collector do then? > >> > > >> > > >> > > >> > Jay K wrote: > >> >> Is this legal/correct? > >> >> > >> >> > >> >> Date.i3: > >> >> TYPE TimeZone <: REFANY; > >> >> VAR Local, UTC: TimeZone; (* granted, will maybe change these to extern *) > >> >> > >> >> > >> >> Date.m3:? > >> >> REVEAL TimeZone = BRANDED "Date.TimeZone" REF INTEGER; > >> >> ? > >> >> > >> >> DatePosixC.c: > >> >> static const int Local = 0; > >> >> static const int UTC = 1; > >> >> extern const int const * const Date__Local = &Local; > >> >> extern const int const * const Date__UTC = &UTC; > >> >> ? > >> >> > >> >> - Jay > >> > > > >--_cbaca81c-f322-4f31-8684-e7f171e67f3d_ > >Content-Type: text/html; charset="iso-2022-jp" > >Content-Transfer-Encoding: 7bit > > > > > > > > > > > >But then unsafe, right?

- Jay

> From: hosking@cs.purdue.edu
> Date: Thu, 15 Apr 2010 22:06:14 -0400
> To: rodney_bates& > >#64;lcwb.coop
> CC: m3devel@elegosoft.com
> Subject: Re: [M3devel] Modula-3/C interop in Date/Time?
>
> Indeed! UNTRACED.
>
> < > >br>> On 15 Apr 2010, at 18:44, Rodney M. Bates wrote:
>
> > Since these pointer variables are initialized by
> > C code and their referents are also provided by C > > code
> > as global variables, shouldn't the type be untraced?
> >
> > I suppose that, since they don't point into the traced
> > heap, the collect > >or implementation we have would quietly
> > ignore them as roots. But that's relying on implementation-
> > dependent information.
> >
> > Also, if someon > >e created a field of type Date.TimeZone,
> > > > ; (or an array of them) in a traced-heap-allocated object,
> > which is a perfectly legitimate thing to do, what would
> > our collector do then?
> >
> >> >
> >
> > Jay K wrote:
> >> Is this legal/correct?
> >>
> >>
> >> Date.i3:
> >> TYPE TimeZone > > <: REFANY;
> >> VAR Local, UTC: TimeZone; (* granted, will maybe change these to extern *)
> >>
> >>
> >> > > Date.m3: 
> >> REVEAL TimeZone = BRANDED "Date.TimeZone" REF INTEGER;
> >>  
> >>
> >> DatePosixC.c:
> >> >> static const int Local = 0;
> >> static const int UTC = 1;
> >> extern const int const * const Date__Local = &Local;
> > > >> extern const int const * const Dat > > e__UTC = &UTC;
> >>  
> >>
> >> - Jay
>
> > > >--_cbaca81c-f322-4f31-8684-e7f171e67f3d_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Fri Apr 16 11:38:14 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 16 Apr 2010 11:38:14 +0200 Subject: [M3devel] release engineering 5.8: trac issue 1005 (open array initializers) Message-ID: <20100416113814.xwn126mk800808kc@mail.elegosoft.com> I'm currently reviewing the open issues again, and came across https://projects.elego.de/cm3/ticket/1005 Not sure if I've asked before, but do we need to solve this for this release? The GC error seems strange: --- ../src/p2/p209/stderr.build 2009-06-29 21:47:53.000000000 +0200 +++ ../src/p2/p209/AMD64_LINUX/stderr.build 2009-07-20 08:17:17.000000000 +0200 @@ -0,0 +1,13 @@ +o is 0x348 +init_pc is 0x0 +bias is 0x5c8 +Target.Address.align is 0x40 +Target.Byte is 0x8 + + +*** +*** runtime error: +*** <*ASSERT*> failed. +*** file "../src/misc/CG.m3", line 1077 +*** + 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 Fri Apr 16 11:45:09 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 16 Apr 2010 11:45:09 +0200 Subject: [M3devel] release engineering 5.8: code generator error for IP address initializers Message-ID: <20100416114509.eh8r662dwss44oo8@mail.elegosoft.com> We also have this error, which should perhaps not be ignored? http://hudson.modula3.com:8080/job/cm3-test-m3tests-AMD64_FREEBSD/lastBuild/testReport/(root)/m3tests/p204__IP_address_initializers 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 jay.krell at cornell.edu Fri Apr 16 11:58:13 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 16 Apr 2010 09:58:13 +0000 Subject: [M3devel] release engineering 5.8: trac issue 1005 (open array initializers) In-Reply-To: <20100416113814.xwn126mk800808kc@mail.elegosoft.com> References: <20100416113814.xwn126mk800808kc@mail.elegosoft.com> Message-ID: I believe Tony removed the print outs but imho they should be left in until the assertion failure is understood and fixed. They try to inform on what is going on when the assertion fails. - Jay > Date: Fri, 16 Apr 2010 11:38:14 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] release engineering 5.8: trac issue 1005 (open array initializers) > > I'm currently reviewing the open issues again, and came across > > https://projects.elego.de/cm3/ticket/1005 > > Not sure if I've asked before, but do we need to solve this for this > release? The GC error seems strange: > > --- ../src/p2/p209/stderr.build 2009-06-29 21:47:53.000000000 +0200 > +++ ../src/p2/p209/AMD64_LINUX/stderr.build 2009-07-20 > 08:17:17.000000000 +0200 > @@ -0,0 +1,13 @@ > +o is 0x348 > +init_pc is 0x0 > +bias is 0x5c8 > +Target.Address.align is 0x40 > +Target.Byte is 0x8 > + > + > +*** > +*** runtime error: > +*** <*ASSERT*> failed. > +*** file "../src/misc/CG.m3", line 1077 > +*** > + > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Apr 16 12:01:30 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 16 Apr 2010 10:01:30 +0000 Subject: [M3devel] release engineering 5.8: code generator error for IP address initializers In-Reply-To: <20100416114509.eh8r662dwss44oo8@mail.elegosoft.com> References: <20100416114509.eh8r662dwss44oo8@mail.elegosoft.com> Message-ID: "aside": http://hudson.modula3.com:8080/job/cm3-test-m3tests-AMD64_FREEBSD/lastBuild/testReport/(root)/m3tests/p206__ARRAY_constructors_in_var_decls_using_named_open_array_types/ http://hudson.modula3.com:8080/job/cm3-test-m3tests-AMD64_FREEBSD/lastBuild/testReport/(root)/m3tests/r004__negative_size_for_an_open_array/ It'd be nice if in Quake we had something regular expression-ish, so that we could factor out the line numbers, such as e.g. to match any decimal number. Maybe just check for lines that start how we expect and cut them off at some position. That might be doable with today's Quake. - Jay > Date: Fri, 16 Apr 2010 11:45:09 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] release engineering 5.8: code generator error for IP address initializers > > We also have this error, which should perhaps not be ignored? > > http://hudson.modula3.com:8080/job/cm3-test-m3tests-AMD64_FREEBSD/lastBuild/testReport/(root)/m3tests/p204__IP_address_initializers > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Fri Apr 16 12:50:48 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 16 Apr 2010 12:50:48 +0200 Subject: [M3devel] release engineering 5.8: code generator error for IP address initializers In-Reply-To: References: <20100416114509.eh8r662dwss44oo8@mail.elegosoft.com> Message-ID: <20100416125048.183752ukg4os0kgk@mail.elegosoft.com> I agree. Regular expressions in quake would be great for regression tests. Perhaps for the next release? Olaf Quoting Jay K : > "aside": > > http://hudson.modula3.com:8080/job/cm3-test-m3tests-AMD64_FREEBSD/lastBuild/testReport/(root)/m3tests/p206__ARRAY_constructors_in_var_decls_using_named_open_array_types/ > > http://hudson.modula3.com:8080/job/cm3-test-m3tests-AMD64_FREEBSD/lastBuild/testReport/(root)/m3tests/r004__negative_size_for_an_open_array/ > > > It'd be nice if in Quake we had something regular expression-ish, so > that we could factor out the line numbers, such as e.g. to match > any decimal number. > > > Maybe just check for lines that start how we expect and cut them off > at some position. > That might be doable with today's Quake. > > > > - Jay > > > >> Date: Fri, 16 Apr 2010 11:45:09 +0200 >> From: wagner at elegosoft.com >> To: m3devel at elegosoft.com >> Subject: [M3devel] release engineering 5.8: code generator error >> for IP address initializers >> >> We also have this error, which should perhaps not be ignored? >> >> http://hudson.modula3.com:8080/job/cm3-test-m3tests-AMD64_FREEBSD/lastBuild/testReport/(root)/m3tests/p204__IP_address_initializers >> >> 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 wagner at elegosoft.com Fri Apr 16 13:09:06 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 16 Apr 2010 13:09:06 +0200 Subject: [M3devel] unused/little used stuff in m3core/unix? Message-ID: <20100416130906.o573xyu9co004gks@mail.elegosoft.com> Quoting Jay K : > Ok on preserving most/all of these but note I'm not keen on > preserving like anything dealing with structs or time_t. > > There are various arguments for/against. > > This "systems" language interoperates well with C, directly, IF you > control the C. > > Thus we have wrappers. We almost never interface directly with "the OS". > > Then again, same is true of C. Actual "kernels" have custom > calling mechanisms, which gets wrapped in C. > > I'm not sure we should provide a general set of wrappers, or leave > it to each user to write his own, > or provide some simple small set. Leaving it to each user is error > prone, granted. > > The historical implementation here was awful and *really* *not* the way. > > The question then is what should the implementation be. One more or less POSIXish API within m3core would be OK with me. It even needs not be complete, but I'd expect some well-known standard functions there. Of course this doesn't answer the question what should be included and what not. Olaf >> Date: Mon, 12 Apr 2010 10:12:12 +0200 >> From: wagner at elegosoft.com >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] unused/little used stuff in m3core/unix? >> >> Quoting Jay K : >> >> > Following are not used: >> > >> > fchmod >> > fchown >> > getpagesize >> > sbrk >> > creat >> > isatty >> > >> > That isn't necessarily all. >> > >> > Some are used only in: >> > >> > C:\dev2\cm3.2\m3-libs\libm3\src\os\POSIX >> > e.g. >> > chdir >> > getdtablesize >> > execve >> > >> > Some are used only in the unused m3-pkgtools directory or by cvsup. >> > e.g. umask >> > >> > These all traffic in pretty "plain" types (e.g. no structs, no >> > time_t). So just keep them all? >> >> Yes. These are standard POSIX or Unix legacy interfaces. >> Do not throw them out. >> >> > Note of course, uses of these somewhat or significantly inhibit >> > porting to native Win32. >> >> As these are POSIX, that is to be expected. >> >> > Account for somewhat arbirary Posix-specific code outside the cm3 tree >> > and err toward wrapping stuff that is easy? >> > >> > Or push the idea that m3core/libm3 are a good (and safe) portability >> > layer and only provide what they need, and >> > gradually move them towards C to reduce their needs? >> >> As a systems programming language, we should support standard OS >> interfaces IMO. >> >> 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 jay.krell at cornell.edu Fri Apr 16 14:15:03 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 16 Apr 2010 12:15:03 +0000 Subject: [M3devel] release engineering 5.8: code generator error for IP address initializers In-Reply-To: <20100416125048.183752ukg4os0kgk@mail.elegosoft.com> References: <20100416114509.eh8r662dwss44oo8@mail.elegosoft.com>, , <20100416125048.183752ukg4os0kgk@mail.elegosoft.com> Message-ID: (back to the topic :) ) somewhat reduced case: MODULE Main; TYPE T1 = ARRAY [0..0] OF INTEGER; CONST const: T1 = ARRAY OF INTEGER{2}; BEGIN END Main. The problem is two global integers are overlapping. The open array size and its first element. new source -> compiling Main.m3 "..\Main.m3", line 5: warning: not used (const) m3front:cg:Init_int:NOT in_init: o: 32 s:32 value:2 <== m3front:cg:Init_int:NOT in_init: o: 32 s:32 value:1 <== m3front:cg:Init_int:NOT in_init: o: 384 s:32 value:3 m3front:cg:Init_int:in_init: o: 32 s:32 value:1 m3front:cg:Init_int:in_init: o: 32 s:32 value:2 Are these syntaxes legal? This apparent mixing of open and fixed arrays? - Jay > Date: Fri, 16 Apr 2010 12:50:48 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] release engineering 5.8: code generator error for IP address initializers > > I agree. Regular expressions in quake would be great for regression tests. > Perhaps for the next release? > > Olaf > > Quoting Jay K : > > > "aside": > > > > http://hudson.modula3.com:8080/job/cm3-test-m3tests-AMD64_FREEBSD/lastBuild/testReport/(root)/m3tests/p206__ARRAY_constructors_in_var_decls_using_named_open_array_types/ > > > > http://hudson.modula3.com:8080/job/cm3-test-m3tests-AMD64_FREEBSD/lastBuild/testReport/(root)/m3tests/r004__negative_size_for_an_open_array/ > > > > > > It'd be nice if in Quake we had something regular expression-ish, so > > that we could factor out the line numbers, such as e.g. to match > > any decimal number. > > > > > > Maybe just check for lines that start how we expect and cut them off > > at some position. > > That might be doable with today's Quake. > > > > > > > > - Jay > > > > > > > >> Date: Fri, 16 Apr 2010 11:45:09 +0200 > >> From: wagner at elegosoft.com > >> To: m3devel at elegosoft.com > >> Subject: [M3devel] release engineering 5.8: code generator error > >> for IP address initializers > >> > >> We also have this error, which should perhaps not be ignored? > >> > >> http://hudson.modula3.com:8080/job/cm3-test-m3tests-AMD64_FREEBSD/lastBuild/testReport/(root)/m3tests/p204__IP_address_initializers > >> > >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Fri Apr 16 14:55:21 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 16 Apr 2010 14:55:21 +0200 Subject: [M3devel] assignability of fixed and open arrays, was: RE: release engineering 5.8: code generator error for IP address initializers In-Reply-To: References: <20100416114509.eh8r662dwss44oo8@mail.elegosoft.com>, , <20100416125048.183752ukg4os0kgk@mail.elegosoft.com> Message-ID: <20100416145521.sywubhm3kgk440w4@mail.elegosoft.com> Quoting Jay K : > (back to the topic :) ) > > somewhat reduced case: > > MODULE Main; > > TYPE T1 = ARRAY [0..0] OF INTEGER; > > CONST const: T1 = ARRAY OF INTEGER{2}; > BEGIN > END Main. > > The problem is two global integers are overlapping. > The open array size and its first element. > > Are these syntaxes legal? > This apparent mixing of open and fixed arrays? You mean it would work for CONST const: T1 = ARRAY [0..0] OF INTEGER{2}; The type of const is no open array, but the fixed array A1. So the question would be: is an open array (of the correct size) assignable to a fixed array type? An expression e is assignable to a variable v if: * the type of e is assignable to the type of v, and * the value of e is a member of the type of v, is not a local procedure, and if it is an array, then it has the same shape as v. though this is not a variable assignment, but a constant definition. Nonetheless, if that's assumed to be equivalent, then it would depend on the definition of shape: does it include the length field or not? I'd tend to think it does not (since that's just a representation the compiler (writer) chose), but only the number of dimensions and elements should count. But this is certainly subtle and others may see it differently. 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 jay.krell at cornell.edu Fri Apr 16 14:53:35 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 16 Apr 2010 12:53:35 +0000 Subject: [M3devel] the checked in .html files vs. $Id and such Message-ID: Some of the checked in generated .html files only vary because they use $Id-type stuff -- $Log or such. We should remove those, so the files aren't always stale. There's over 90 of these in m3-comm/events. Needs some scripting to remove. I suggest throw out the lines between "created" and "history", and throw out empty history. "history" is actually "abstract" and worth keeping when it isn't empty. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Apr 16 16:28:08 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 16 Apr 2010 10:28:08 -0400 Subject: [M3devel] Modula-3/C interop in Date/Time? In-Reply-To: References: , <4BC796B7.7090707@lcwb.coop>, Message-ID: <655C3BEA-B54B-434B-B3E9-E42AF4FD6FA1@cs.purdue.edu> Why unsafe? Depends what you do with it. On 16 Apr 2010, at 00:24, Jay K wrote: > But then unsafe, right? > > - Jay > > > From: hosking at cs.purdue.edu > > Date: Thu, 15 Apr 2010 22:06:14 -0400 > > To: rodney_bates at lcwb.coop > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] Modula-3/C interop in Date/Time? > > > > Indeed! UNTRACED. > > > > > > On 15 Apr 2010, at 18:44, Rodney M. Bates wrote: > > > > > Since these pointer variables are initialized by > > > C code and their referents are also provided by C code > > > as global variables, shouldn't the type be untraced? > > > > > > I suppose that, since they don't point into the traced > > > heap, the collector implementation we have would quietly > > > ignore them as roots. But that's relying on implementation- > > > dependent information. > > > > > > Also, if someone created a field of type Date.TimeZone, > > ! 2; (or an array of them) in a traced-heap-allocated object, > > > which is a perfectly legitimate thing to do, what would > > > our collector do then? > > > > > > > > > > > > Jay K wrote: > > >> Is this legal/correct? > > >> > > >> > > >> Date.i3: > > >> TYPE TimeZone <: REFANY; > > >> VAR Local, UTC: TimeZone; (* granted, will maybe change these to extern *) > > >> > > >> > > >> Date.m3:? > > >> REVEAL TimeZone = BRANDED "Date.TimeZone" REF INTEGER; > > >> ? > > >> > > >> DatePosixC.c: > > >> static const int Local = 0; > > >> static const int UTC = 1; > > >> extern const int const * const Date__Local = &Local; > > >> extern const int const * const D! ate__UTC = &UTC; > > >> ? > > >> > > >> - Jay > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Apr 16 16:30:48 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 16 Apr 2010 10:30:48 -0400 Subject: [M3devel] Modula-3/C interop in Date/Time? In-Reply-To: References: , , <4BC796B7.7090707@lcwb.coop>, , , , <20100416070034.9C0911A20EB@async.async.caltech.edu> Message-ID: <81B495C9-A0B2-4884-A6FC-5D928FC38340@cs.purdue.edu> What is the use-case here? Merely having UNTRACED references doesn't make your code unsafe. Using ADR does. But why not have an interface with C that makes use of the fact that VAR parameters are passed as pointers to C. e.g., C function f(int *ref p) can be declared as <*EXTERNAL*> f(VAR i: INTEGER) and this is still safe. On 16 Apr 2010, at 04:18, Jay K wrote: > Isn't making them unsafe? ADR? I'll try.. > > - Jay > > > To: jay.krell at cornell.edu > > Date: Fri, 16 Apr 2010 00:00:34 -0700 > > From: mika at async.async.caltech.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] Modula-3/C interop in Date/Time? > > > > I don't think there's anything unsafe about UNTRACED. > > > > It's DISPOSE that's unsafe... > > > > Mika > > > > Jay K writes: > > >--_cbaca81c-f322-4f31-8684-e7f171e67f3d_ > > >Content-Type: text/plain; charset="iso-2022-jp" > > >Content-Transfer-Encoding: 7bit > > > > > >But then unsafe, right? > > > > > > - Jay > > > > > >> From: hosking at cs.purdue.edu > > >> Date: Thu, 15 Apr 2010 22:06:14 -0400 > > >> To: rodney_bates at lcwb.coop > > >> CC: m3dev el at elegosoft.com > > >> Subject: Re: [M3devel] Modula-3/C interop in Date/Time? > > >> > > >> Indeed! UNTRACED. > > >> > > >> > > >> On 15 Apr 2010, at 18:44, Rodney M. Bates wrote: > > >> > > >> > Since these pointer variables are initialized by > > >> > C code and their referents are also provided by C code > > >> > as global variables, shouldn't the type be untraced? > > >> > > > >> > I suppose that, since they don't point into the traced > > >> > heap, the collector implementation we have would quietly > > >> > ignore them as roots. But that's relying on implementation- > > >> > dependent information. > > >> > > > >> > Also, if someone created a field of type Date.TimeZone, > > >> > (or an array of them) in a traced-heap-allocated object, > > > > which is a perfectly legitimate thing to do, what would > > >> > our collector do then? > > >> > > > >> > > > >> > > > >> > Jay K wrote: > > >> >> Is this legal/correct? > > >> >> > > >> >> > > >> >> Date.i3: > > >> >> TYPE TimeZone <: REFANY; > > >> >> VAR Local, UTC: TimeZone; (* granted, will maybe change these to extern *) > > >> >> > > >> >> > > >> >> Date.m3:? > > >> >> REVEAL TimeZone = BRANDED "Date.TimeZone" REF INTEGER; > > >> >> ? > > >> >> > > >> >> DatePosixC.c: > > >> >> static const int Local = 0& #59; > > >> >> static const int UTC = 1; > > >> >> extern const int const * const Date__Local = &Local; > > >> >> extern const int const * const Date__UTC = &UTC; > > >> >> ? > > >> >> > > >> >> - Jay > > >> > > > > > >--_cbaca81c-f322-4f31-8684-e7f171e67f3d_ > > >Content-Type: text/html; charset="iso-2022-jp" > > >Content-Transfer-Encoding: 7bit > > > > > > > > > > > > > > > > >But then unsafe, right?

- Jay

> From: hosking@cs.purdue.edu
> Date: Thu, 15 Apr 2010 22:06:14 -0400
> To: rodney_bates& > > >#64;lcwb.coop
> CC: m3devel@elegosoft.com
> Subject: Re: [M3devel] Modula-3/C interop in Date/Time?
>
> Indeed! UNTRACED.
>
> < > > >br>> On 15 Apr 2010, at 18:44, Rodney M. Bates wrote:
>
> > Since these pointer variables are initialized by
> & #38;#62; C code and their referents are also provided by C > > > code
> > as global variables, shouldn't the type be untraced?
> >
> > I suppose that, since they don't point into the traced
> > heap, the collect > > >or implementation we have would quietly
> > ignore them as roots. But that's relying on implementation-
> > dependent information.
> >
> > Also, if someon > > >e created a field of type Date.TimeZone,
> > > > > ; (or an array of them) in a traced-heap-allocated object,
> > which is a perfectly legitimate thing to do, what would
> > our collector do then?
> >
> > >> >
> >
> > Jay K wrote:
> >> Is this legal/correct?
> >>
> >>
> >> Date.i3:
> >> TYPE TimeZone > > > <: REFANY;
> >> VAR Local, UTC: TimeZone; (* granted, will maybe change these to extern *)
> >>
> >&# 38;#62;
> >> > > > Date.m3: 
> >> REVEAL TimeZone = BRANDED "Date.TimeZone" REF INTEGER;
> >>  
> >>
> >> DatePosixC.c:
> > >> >> static const int Local = 0;
> >> static const int UTC = 1;
> >> extern const int const * const Date__Local = &Local;
> > > > >> extern const int con st * const Dat > > > e__UTC = &UTC;
> >>  
> >>
> >> - Jay
>
> > > > > >--_cbaca81c-f322-4f31-8684-e7f171e67f3d_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Apr 16 16:45:41 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 16 Apr 2010 10:45:41 -0400 Subject: [M3devel] release engineering 5.8: trac issue 1005 (open array initializers) In-Reply-To: <20100416113814.xwn126mk800808kc@mail.elegosoft.com> References: <20100416113814.xwn126mk800808kc@mail.elegosoft.com> Message-ID: Here's the testcase: MODULE Main; IMPORT IO; <*UNUSED*> VAR a : ARRAY [0..0] OF CHAR := ARRAY OF CHAR {'a'}; <*UNUSED*> VAR b : ARRAY [0..0] OF CHAR := ARRAY OF CHAR {'b'}; <*UNUSED*> VAR c : ARRAY [0..0] OF CHAR := ARRAY OF CHAR {'c'}; <*UNUSED*> VAR d : ARRAY [0..0] OF CHAR := ARRAY OF CHAR {'d'}; BEGIN IO.Put("OK\n"); END Main. I looked into this a while back and have some understanding of what is going on. Still no fix yet. Note that this is weird code that does have a more concise workaround, which is probably why we don't see it often: MODULE Main; IMPORT IO; <*UNUSED*> VAR a := ARRAY [0,0] OF CHAR {'a'}; <*UNUSED*> VAR b := ARRAY [0,0] OF CHAR {'b'}; <*UNUSED*> VAR c := ARRAY [0,0] OF CHAR {'c'}; <*UNUSED*> VAR d := ARRAY [0,0] OF CHAR {'d'}; BEGIN IO.Put("OK\n"); END Main. The problem arises because in the first form the compiler tries to initialise a literal array constant for each of the array constructor expressions before assigning them to the variables. In the second form it initialises the variables directly from the elements of the constructor. Need to dig deeper. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 16 Apr 2010, at 05:38, Olaf Wagner wrote: > I'm currently reviewing the open issues again, and came across > > https://projects.elego.de/cm3/ticket/1005 > > Not sure if I've asked before, but do we need to solve this for this > release? The GC error seems strange: > > --- ../src/p2/p209/stderr.build 2009-06-29 21:47:53.000000000 +0200 > +++ ../src/p2/p209/AMD64_LINUX/stderr.build 2009-07-20 08:17:17.000000000 +0200 > @@ -0,0 +1,13 @@ > +o is 0x348 > +init_pc is 0x0 > +bias is 0x5c8 > +Target.Address.align is 0x40 > +Target.Byte is 0x8 > + > + > +*** > +*** runtime error: > +*** <*ASSERT*> failed. > +*** file "../src/misc/CG.m3", line 1077 > +*** > + > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Apr 16 16:46:41 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 16 Apr 2010 10:46:41 -0400 Subject: [M3devel] release engineering 5.8: trac issue 1005 (open array initializers) In-Reply-To: References: <20100416113814.xwn126mk800808kc@mail.elegosoft.com> Message-ID: <9B6A5ED8-BB05-4856-96AC-1A28C498C443@cs.purdue.edu> PS I don't use printouts when debugging. I use a debugger. There is never a need to put verbose debugging printouts into the source tree. They just litter the code. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 16 Apr 2010, at 05:58, Jay K wrote: > I believe Tony removed the print outs but imho they should be left in until the assertion failure is understood and fixed. They try to inform on what is going on when the assertion fails. > > - Jay > > > Date: Fri, 16 Apr 2010 11:38:14 +0200 > > From: wagner at elegosoft.com > > To: m3devel at elegosoft.com > > Subject: [M3devel] release engineering 5.8: trac issue 1005 (open array initializers) > > > > I'm currently reviewing the open issues again, and came across > > > > https://projects.elego.de/cm3/ticket/1005 > > > > Not sure if I've asked before, but do we need to solve this for this > > release? The GC error seems strange: > > > > --- ../src/p2/p209/stderr.build 2009-06-29 21:47:53.000000000 +0200 > > +++ ../src/p2/p209/AMD64_LINUX/stderr.build 2009-07-20 > > 08:17:17.000000000 +0200 > > @@ -0,0 +1,13 @@ > > +o is 0x348 > > +init_pc is 0x0 > > +bias is 0x5c8 > > +Target.Address.align is 0x40 > > +Target.Byte is 0x8 > > + > > + > > +*** > > +*** runtime error: > > +*** <*ASSERT*> failed. > > +*** file "../src/misc/CG.m3", line 1077 > > +*** > > + > > > > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Apr 16 17:04:49 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 16 Apr 2010 11:04:49 -0400 Subject: [M3devel] release engineering 5.8: code generator error for IP address initializers In-Reply-To: References: <20100416114509.eh8r662dwss44oo8@mail.elegosoft.com>, , <20100416125048.183752ukg4os0kgk@mail.elegosoft.com> Message-ID: <908A7AC8-565B-4749-A325-BE13F99F70D7@cs.purdue.edu> You are confusing open array types with array constructors. On 16 Apr 2010, at 08:15, Jay K wrote: > (back to the topic :) ) > > somewhat reduced case: > MODULE Main; > TYPE T1 = ARRAY [0..0] OF INTEGER; > CONST const: T1 = ARRAY OF INTEGER{2}; This is an array constructor. I suspect this is the same issue as in my previous e-mail. The following concise rewrite should work: CONST const = T1{2}; > BEGIN > END Main. > > The problem is two global integers are overlapping. > The open array size and its first element. > > new source -> compiling Main.m3 > "..\Main.m3", line 5: warning: not used (const) > m3front:cg:Init_int:NOT in_init: o: 32 s:32 value:2 <== > m3front:cg:Init_int:NOT in_init: o: 32 s:32 value:1 <== > m3front:cg:Init_int:NOT in_init: o: 384 s:32 value:3 > m3front:cg:Init_int:in_init: o: 32 s:32 value:1 > m3front:cg:Init_int:in_init: o: 32 s:32 value:2 > > Are these syntaxes legal? > This apparent mixing of open and fixed arrays? > > - Jay > > > > Date: Fri, 16 Apr 2010 12:50:48 +0200 > > From: wagner at elegosoft.com > > To: jay.krell at cornell.edu > > CC: m3devel at elegosoft.com > > Subject: RE: [M3devel] release engineering 5.8: code generator error for IP address initializers > > > > I agree. Regular expressions in quake would be great for regression tests. > > Perhaps for the next release? > > > > Olaf > > > > Quoting Jay K : > > > > > "aside": > > > > > > http://hudson.modula3.com:8080/job/cm3-test-m3tests-AMD64_FREEBSD/lastBuild/testReport/(root)/m3tests/p206__ARRAY_constructors_in_var_decls_using_named_open_array_types/ > > > > > > http://hudson.modula3.com:8080/job/cm3-test-m3tests-AMD64_FREEBSD/lastBuild/testReport/(root)/m3tests/r004__negative_size_for_an_open_array/ > > > > > > > > > It'd be nice if in Quake we had something regular expression-ish, so > > > that we could factor out the line numbers, such as e.g. to match > > > any decimal number. > > > > > > > > > Maybe just check for lines that start how we expect and cut them off > > > at some position. > > > That might be doable with today's Quake. > > > > > > > > > > > > - Jay > > > > > > > > > > > >> Date: Fri, 16 Apr 2010 11:45:09 +0200 > > >> From: wagner at elegosoft.com > > >> To: m3devel at elegosoft.com > > >> Subject: [M3devel] release engineering 5.8: code generator error > > >> for IP address initializers > > >> > > >> We also have this error, which should perhaps not be ignored? > > >> > > >> http://hudson.modula3.com:8080/job/cm3-test-m3tests-AMD64_FREEBSD/lastBuild/testReport/(root)/m3tests/p204__IP_address_initializers > > >> > > >> 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Apr 16 17:06:27 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 16 Apr 2010 11:06:27 -0400 Subject: [M3devel] assignability of fixed and open arrays, was: RE: release engineering 5.8: code generator error for IP address initializers In-Reply-To: <20100416145521.sywubhm3kgk440w4@mail.elegosoft.com> References: <20100416114509.eh8r662dwss44oo8@mail.elegosoft.com>, , <20100416125048.183752ukg4os0kgk@mail.elegosoft.com> <20100416145521.sywubhm3kgk440w4@mail.elegosoft.com> Message-ID: <5DB7169E-073B-480B-A043-046E08ED53DE@cs.purdue.edu> There is no open array in this code. Just a fixed array type and an array constructor. It is perfectly reasonable code. On 16 Apr 2010, at 08:55, Olaf Wagner wrote: > Quoting Jay K : > >> (back to the topic :) ) >> >> somewhat reduced case: >> >> MODULE Main; >> >> TYPE T1 = ARRAY [0..0] OF INTEGER; >> >> CONST const: T1 = ARRAY OF INTEGER{2}; >> BEGIN >> END Main. >> >> The problem is two global integers are overlapping. >> The open array size and its first element. >> >> Are these syntaxes legal? >> This apparent mixing of open and fixed arrays? > > You mean it would work for > > CONST const: T1 = ARRAY [0..0] OF INTEGER{2}; > > The type of const is no open array, but the fixed array A1. > So the question would be: is an open array (of the correct size) > assignable to a fixed array type? > > An expression e is assignable to a variable v if: > > * the type of e is assignable to the type of v, and > * the value of e is a member of the type of v, is not a local procedure, > and if it is an array, then it has the same shape as v. > > though this is not a variable assignment, but a constant definition. > Nonetheless, if that's assumed to be equivalent, then it would depend > on the definition of shape: does it include the length field or not? > > I'd tend to think it does not (since that's just a representation the > compiler (writer) chose), but only the number of dimensions and elements > should count. > > But this is certainly subtle and others may see it differently. > > 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 rcolebur at SCIRES.COM Fri Apr 16 23:07:04 2010 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Fri, 16 Apr 2010 17:07:04 -0400 Subject: [M3devel] example of bug in NetObj Stub Generator In-Reply-To: References: , , <7C7408D0-9A40-4988-BADA-A9FD8C15D388@cs.purdue.edu>, , Message-ID: Jay / Rodney / et al: I?ve attached a ZIP file containing a stripped-down source package and NT386 folder that demonstrates the problem I am having with the stub generator. The generated file ?NT386\CV_Server_T_v2.m3? is missing the import of the ?Date? interface. The source interface that I wrote is in ?src\CV_Server.i3?. Regards, Randy From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K Sent: Thursday, April 15, 2010 7:13 PM To: Coleburn, Randy; m3devel Subject: RE: [M3devel] Modula-3/C interop in Date/Time? Randy, I think I understand but yes please commit a small concrete example like in m3-sys/m3tests/src/p2/p237 or such. I think this is a bug in the stub generator. Probably time/date could workaround it with slight restructuring/renaming. But probably should fix the stub generator. While at it, maybe have it stop outputing unused stuff that triggers so many warnings... - Jay ________________________________ From: rcolebur at SCIRES.COM To: m3devel at elegosoft.com Date: Thu, 15 Apr 2010 18:10:44 -0400 Subject: Re: [M3devel] Modula-3/C interop in Date/Time? Jay: I?m still catching up after being in hospital, but noticed you are working on the Date.i3/m3 interface and module. There is a problem that I?d like to post on the newsgroup that may be related. I?m not sure if the problem is due to the way Date.i3/m3 is coded, or perhaps a problem in the network objects stub generator, but I thought whilst you are looking at Date.i3/m3 something might trigger in your mind about how to fix the problem. I have several interfaces that export a Network Object. Of course, these get processed by the network objects stub generator at compile time. For some of these, the generated files fail to compile due to Date.i3 not being listed in the IMPORT list. Since these offending modules are generated at compile time, it?s not a programming error in the new source package that is being compiled. The way I work around the problem is by editing the generated files after the compile fails. Namely, I go to the target folder (in this case NT386) and edit the generated m3 files by adding ?IMPORT Date;?, then recompile and all is well. Of course, the next time you erase the target folder, change the underlying interface, or run ?cm3 -clean?, the generated file has to be created again and you have to go thru the compile-edit-compile cycle again to repair the problem. If you are delivering source code to a customer, you then have to document the work-around for them so that they can get the package to compile. I reported this problem years ago, but that was back before we were tracking bugs using the new system. It could be that the way Date.i3/m3 is coded is causing the stub generator not to think it needs to import it, or it could be that the stub generator isn?t doing its job right in the first place. Now after saying all this, I know I should provide a concrete example. I?ll have to go back and see if I ever reduced the code to a smaller set that demonstrates the problem. Otherwise, I can?t give anyone the full source code because it was a ?work-for-hire? and I don?t have the right to publish these sources. Let me know if you want a concrete example and I?ll see what I can do. Regards, Randy From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K Sent: Thursday, April 15, 2010 5:26 PM To: Tony Cc: m3devel Subject: Re: [M3devel] Modula-3/C interop in Date/Time? Oops, right, of course. Important to get the things right I know to keep the question clear/narrow. - Jay ________________________________ From: hosking at cs.purdue.edu Date: Thu, 15 Apr 2010 12:55:52 -0400 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] Modula-3/C interop in Date/Time? Excepting that INTEGER is not the same as int on 64-bit platforms. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 15 Apr 2010, at 02:45, Jay K wrote: Is this legal/correct? Date.i3: TYPE TimeZone <: REFANY; VAR Local, UTC: TimeZone; (* granted, will maybe change these to extern *) Date.m3:? REVEAL TimeZone = BRANDED "Date.TimeZone" REF INTEGER; ? DatePosixC.c: static const int Local = 0; static const int UTC = 1; extern const int const * const Date__Local = &Local; extern const int const * const Date__UTC = &UTC; ? - Jay ________________________________ CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This email may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from reviewing, copying, using, disclosing or distributing to others the information in this email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require advance export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. ________________________________ CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This email may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from reviewing, copying, using, disclosing or distributing to others the information in this email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require advance export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: BugExample.zip Type: application/x-zip-compressed Size: 8839 bytes Desc: BugExample.zip URL: From jay.krell at cornell.edu Sat Apr 17 03:50:54 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 17 Apr 2010 01:50:54 +0000 Subject: [M3devel] release engineering 5.8: code generator error for IP address initializers In-Reply-To: <908A7AC8-565B-4749-A325-BE13F99F70D7@cs.purdue.edu> References: <20100416114509.eh8r662dwss44oo8@mail.elegosoft.com>, , <20100416125048.183752ukg4os0kgk@mail.elegosoft.com> , <908A7AC8-565B-4749-A325-BE13F99F70D7@cs.purdue.edu> Message-ID: There is this thing I read, where the types of values/constants are known without context. The left hand side does not change the type of the right. That confuses me here. It would imply the right is an open array. - Jay Subject: Re: [M3devel] release engineering 5.8: code generator error for IP address initializers From: hosking at cs.purdue.edu Date: Fri, 16 Apr 2010 11:04:49 -0400 CC: wagner at elegosoft.com; m3devel at elegosoft.com To: jay.krell at cornell.edu You are confusing open array types with array constructors. On 16 Apr 2010, at 08:15, Jay K wrote: (back to the topic :) ) somewhat reduced case: MODULE Main; TYPE T1 = ARRAY [0..0] OF INTEGER; CONST const: T1 = ARRAY OF INTEGER{2}; This is an array constructor. I suspect this is the same issue as in my previous e-mail. The following concise rewrite should work: CONST const = T1{2}; BEGIN END Main. The problem is two global integers are overlapping. The open array size and its first element. new source -> compiling Main.m3 "..\Main.m3", line 5: warning: not used (const) m3front:cg:Init_int:NOT in_init: o: 32 s:32 value:2 <== m3front:cg:Init_int:NOT in_init: o: 32 s:32 value:1 <== m3front:cg:Init_int:NOT in_init: o: 384 s:32 value:3 m3front:cg:Init_int:in_init: o: 32 s:32 value:1 m3front:cg:Init_int:in_init: o: 32 s:32 value:2 Are these syntaxes legal? This apparent mixing of open and fixed arrays? - Jay > Date: Fri, 16 Apr 2010 12:50:48 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] release engineering 5.8: code generator error for IP address initializers > > I agree. Regular expressions in quake would be great for regression tests. > Perhaps for the next release? > > Olaf > > Quoting Jay K : > > > "aside": > > > > http://hudson.modula3.com:8080/job/cm3-test-m3tests-AMD64_FREEBSD/lastBuild/testReport/(root)/m3tests/p206__ARRAY_constructors_in_var_decls_using_named_open_array_types/ > > > > http://hudson.modula3.com:8080/job/cm3-test-m3tests-AMD64_FREEBSD/lastBuild/testReport/(root)/m3tests/r004__negative_size_for_an_open_array/ > > > > > > It'd be nice if in Quake we had something regular expression-ish, so > > that we could factor out the line numbers, such as e.g. to match > > any decimal number. > > > > > > Maybe just check for lines that start how we expect and cut them off > > at some position. > > That might be doable with today's Quake. > > > > > > > > - Jay > > > > > > > >> Date: Fri, 16 Apr 2010 11:45:09 +0200 > >> From: wagner at elegosoft.com > >> To: m3devel at elegosoft.com > >> Subject: [M3devel] release engineering 5.8: code generator error > >> for IP address initializers > >> > >> We also have this error, which should perhaps not be ignored? > >> > >> http://hudson.modula3.com:8080/job/cm3-test-m3tests-AMD64_FREEBSD/lastBuild/testReport/(root)/m3tests/p204__IP_address_initializers > >> > >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Apr 17 03:48:44 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 17 Apr 2010 01:48:44 +0000 Subject: [M3devel] release engineering 5.8: trac issue 1005 (open array initializers) In-Reply-To: <9B6A5ED8-BB05-4856-96AC-1A28C498C443@cs.purdue.edu> References: <20100416113814.xwn126mk800808kc@mail.elegosoft.com>, , <9B6A5ED8-BB05-4856-96AC-1A28C498C443@cs.purdue.edu> Message-ID: I haven't found a viable debugger for Modula-3. Could be better now that I'm on Debian 5.0 though. gdb is now good, eveything is void*. VisualStudio/cdb/windbb are no good due to lack of CodeView information. I'll try m3gdb again, since upgrading to Debian 5.0. I'm keen on generating good CodeView information because of this. - Jay From: hosking at cs.purdue.edu Date: Fri, 16 Apr 2010 10:46:41 -0400 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] release engineering 5.8: trac issue 1005 (open array initializers) PS I don't use printouts when debugging. I use a debugger. There is never a need to put verbose debugging printouts into the source tree. They just litter the code. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 16 Apr 2010, at 05:58, Jay K wrote: I believe Tony removed the print outs but imho they should be left in until the assertion failure is understood and fixed. They try to inform on what is going on when the assertion fails. - Jay > Date: Fri, 16 Apr 2010 11:38:14 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] release engineering 5.8: trac issue 1005 (open array initializers) > > I'm currently reviewing the open issues again, and came across > > https://projects.elego.de/cm3/ticket/1005 > > Not sure if I've asked before, but do we need to solve this for this > release? The GC error seems strange: > > --- ../src/p2/p209/stderr.build 2009-06-29 21:47:53.000000000 +0200 > +++ ../src/p2/p209/AMD64_LINUX/stderr.build 2009-07-20 > 08:17:17.000000000 +0200 > @@ -0,0 +1,13 @@ > +o is 0x348 > +init_pc is 0x0 > +bias is 0x5c8 > +Target.Address.align is 0x40 > +Target.Byte is 0x8 > + > + > +*** > +*** runtime error: > +*** <*ASSERT*> failed. > +*** file "../src/misc/CG.m3", line 1077 > +*** > + > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Apr 17 10:05:39 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 17 Apr 2010 08:05:39 +0000 Subject: [M3devel] picking which files to package? Message-ID: Olaf, any chance you can limit what files are picked up to the $TARGET and src directories? The I386_DARWIN/AMD64_DARWIN packages I made contain each of other's files due to just picking up "everything". Maybe: iff -u -r1.26.2.51 make-dist.sh --- make-dist.sh 17 Apr 2010 03:55:43 -0000 1.26.2.51 +++ make-dist.sh 17 Apr 2010 08:05:13 -0000 @@ -338,12 +338,16 @@ ) > collection-${c}.html echo "collection-${c}.html" ARCHIVE="${STAGE}/cm3-bin-ws-${c}-${TARGET}-${CM3VERSION}-${DS}.tgz" + a="" + for b in ${PKGS}; do + a="${a} ${b}/src ${b}/${TARGET}" + done if [ -z "${NOARCHIVE}" -a "${c}" != "min" ]; then "${TAR}" --exclude '*.o' --exclude '*.mo' --exclude '*.io' \ --exclude '*/CVS/*' --exclude '*/CVS' --exclude '*~' \ --exclude '*.tar.*' --exclude '*.tgz' --exclude "*/${TARGET}/gcc" \ --exclude "*/${TARGET}/*/*" \ - -czf "${ARCHIVE}" collection-${c}.html install.sh setup.txt setup.cmd ${PKGS} + -czf "${ARCHIVE}" collection-${c}.html install.sh setup.txt setup.cmd ${a} ls -l "${ARCHIVE}" fi done - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Apr 17 06:26:59 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 17 Apr 2010 04:26:59 +0000 Subject: [M3devel] ROUND vs. FLOOR in ThreadPThread.m3 nano vs. micro time conversions? Message-ID: I've gone ahead and "rewritten" this code (it's only a few lines), and I removed this distinction. New form uses modf to split floating point at the decimal point and then multiplies the fractional part by a million (struct timeval) or a billion (struct timespec). Should be equivalent to seconds = (int)floatseconds; microsseconds = (floatseconds - seconds) * billion or million or such I ended up not using the C99 stuff. Sometimes we know the time is less than a second and greater than 0 and so just pass around a microsecond or nanosecond count. Hm. Maybe it has to do with negative times? Rounding down vs. toward zero? I'll probably rereread the code with negative times in mind. Not too worried, as the select uses in the thread code doesn't pass negative times, gettimeofday can't return a negative time, the user thread scheduling intervals I believe are all positive, etc. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Subject: ROUND vs. FLOOR in ThreadPThread.m3 nano vs. micro time conversions? Date: Fri, 9 Apr 2010 10:52:09 +0000 Why does UTimeFromTime use FLOOR but ToNTime uses ROUND? PROCEDURE ToNTime (n: LONGREAL; VAR ts: Utime.struct_timespec) = BEGIN ts.tv_sec := TRUNC(n); ts.tv_nsec := ROUND((n - FLOAT(ts.tv_sec, LONGREAL)) * 1.0D9); END ToNTime; TYPE UTime = Utime.struct_timeval; PROCEDURE UTimeFromTime (time: Time.T): UTime = VAR floor := FLOOR(time); BEGIN RETURN UTime{floor, FLOOR(1.0D6 * (time - FLOAT(floor, LONGREAL)))}; END UTimeFromTime; I've changed this code to pass doubles to C and do the conversion there. To reduce/eliminate use of cloned headers. For ROUND I'm using C99: /* C99, very portable */ long lround(double); long long llround(double); #ifdef __CYGWIN__ #define ROUND lround #else #define ROUND llround #endif typedef double FloatSeconds, LONGREAL; typedef struct timeval MicrosecondsStruct_t; #define FLOAT(value, type) ((type)value) #define FLOOR floor static MicrosecondsStruct_t* FloatSecondsToNanosecondsStruct(LONGREAL n, MicrosecondsStruct_t* ts) { ts->tv_sec = (time_t)n; ts->tv_nsec = ROUND((n - FLOAT(ts->tv_sec, LONGREAL)) * 1.0E9); return ts; } static MicrosecondsStruct_t* FloatSecondsToMicrosecondsStruct(FloatSeconds timeout, MicrosecondsStruct_t* utime) { LONGINT sec = FLOOR(timeout); utime->tv_sec = (time_t)sec; utime->tv_usec = (suseconds_t)FLOOR(1.0E6 * (timeout - FLOAT(sec, LONGREAL))); return utime; } Just arbitrarily a little more correct in the nano case vs. the micro case? Matters little? Would matter more for micro due to lower resolution? Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Apr 17 04:31:25 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 17 Apr 2010 02:31:25 +0000 Subject: [M3devel] release engineering 5.8: trac issue 1005 (open array initializers) In-Reply-To: <9B6A5ED8-BB05-4856-96AC-1A28C498C443@cs.purdue.edu> References: <20100416113814.xwn126mk800808kc@mail.elegosoft.com>, , <9B6A5ED8-BB05-4856-96AC-1A28C498C443@cs.purdue.edu> Message-ID: There is another vague philosophical point I should maybe explore/teach here. The vaguer I make it, the more irrefutable it is. :) "Logging has a place". And debuggers do too. I have seen countless examples where logging exists, in some "reasonable" volume bugs are often largly or completely diagnosed from a log alone getting a debugger to the right point would be quite difficult Logging is always "in situ" and often enabled proactively -- all the time. That is, no need to figure out exactly which command line to run, where to insert the debugger command, no need to try to keep temp files, etc. Very good example: Our Hudson/Tinderbox jobs. Callstacks upon assertion failures are a form of logging. Would be even better if they showed the local variables of every frame. Maybe expanding pointers one level. I often make the prints subject to whether or not an upcoming assertion is going to fail. There are counterpoints, of course. Logging wastes time and space. It makes the source code bigger, the object code bigger. When it is enabled it slows down runtime and usually "wastes" space to store the logs. Except when they end up used. The vast majority of logged date goes unread. You can't log everything. Good debuggers show things at a much lower level than most logging. (Except gdb on Debian 4.0 can't do anything, and CodeView-based debuggers against Modula-3 show very little...) I'll have to try m3gdb again, on Debian 5.0. And generate CodeView information. The CodeView stuff I consider pretty high priority. I've done a fair amount of research and am better prepared to implement it than previously. A C generating backend has about the same value and more. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu CC: m3devel at elegosoft.com Subject: RE: [M3devel] release engineering 5.8: trac issue 1005 (open array initializers) Date: Sat, 17 Apr 2010 01:48:44 +0000 I haven't found a viable debugger for Modula-3. Could be better now that I'm on Debian 5.0 though. gdb is now good, eveything is void*. VisualStudio/cdb/windbb are no good due to lack of CodeView information. I'll try m3gdb again, since upgrading to Debian 5.0. I'm keen on generating good CodeView information because of this. - Jay From: hosking at cs.purdue.edu Date: Fri, 16 Apr 2010 10:46:41 -0400 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] release engineering 5.8: trac issue 1005 (open array initializers) PS I don't use printouts when debugging. I use a debugger. There is never a need to put verbose debugging printouts into the source tree. They just litter the code. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 16 Apr 2010, at 05:58, Jay K wrote: I believe Tony removed the print outs but imho they should be left in until the assertion failure is understood and fixed. They try to inform on what is going on when the assertion fails. - Jay > Date: Fri, 16 Apr 2010 11:38:14 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] release engineering 5.8: trac issue 1005 (open array initializers) > > I'm currently reviewing the open issues again, and came across > > https://projects.elego.de/cm3/ticket/1005 > > Not sure if I've asked before, but do we need to solve this for this > release? The GC error seems strange: > > --- ../src/p2/p209/stderr.build 2009-06-29 21:47:53.000000000 +0200 > +++ ../src/p2/p209/AMD64_LINUX/stderr.build 2009-07-20 > 08:17:17.000000000 +0200 > @@ -0,0 +1,13 @@ > +o is 0x348 > +init_pc is 0x0 > +bias is 0x5c8 > +Target.Address.align is 0x40 > +Target.Byte is 0x8 > + > + > +*** > +*** runtime error: > +*** <*ASSERT*> failed. > +*** file "../src/misc/CG.m3", line 1077 > +*** > + > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Apr 17 12:50:34 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 17 Apr 2010 10:50:34 +0000 Subject: [M3devel] new target names -- SOLsun vs. SOLgnu? Message-ID: If we have targets, say, I386_NT, I386_CYGWIN, I386_MINGW, I386_LINUX, I386_FREEBSD, I386_NETBSD, SPARC32_SOLARIS or SPARC_SOLARIS..how does one capture the SOLsun vs. SOLgnu difference? SPARC32_SOLARIS_SUN vs. SPARC32_SOLARIS_GNU? SPARC_SOLARIS_SUNCC, SPARC_SOLARIS_GCC? "target is underscore separated list of relevant names, usually two but not limited to two"? Drop SOLgnu and just equate SPARC32_SOLARIS with SOLsun? Given that the reason for SOLgnu was because cc was not bundled with OS at some point? But now gcc and cc are both bundled as I understand! Do some sort of autoconfig, sensitive to the CC environment variable? That's actually pretty easy and pretty cheap. Not a terrible idea. I'm not really pushing hard on this topic, just that I want to cross build Cygwin from non-NT and was hitting minor problems. Mainly I want to see if Cygwin pthreads works now, now that the hanging test case got "rewritten", so I can drop the SchedulerPosix.m3 file which duplicates content verbatim out of ThreadPThread.m3.. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Apr 17 10:31:05 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 17 Apr 2010 08:31:05 +0000 Subject: [M3devel] select vs. poll? Message-ID: It looks to me like poll is usually preferred over select? It appears to be standard and widely available. Appears to be *BSD, Solaris, Linux, Interix, AIX, Irix. At least searching the web and checking headers. It has no limit on the number or value of file descriptors waited on. It does use more memory for its parameters and more time to construct and read them. However I believe we only ever select/poll either one file at a time on pthreads one file per thread on user threads There are other better mechanisms -- /dev/poll on Solaris, kqueue on FreeBSD and maybe others, epoll on Linux. Though these are mostly (completely?) concerned with scaling to waiting on large number of file descriptors. I think I'll change over to poll very soon. I haven't yet figured out if select's read/write/except maps directly to poll's flags. I'm guessing: select read => poll POLLIN or maybe POLLPRI also? select write => poll POLLOUT select except => POLLERR or maybe POLLHUP also? I haven't yet found a description of "error conditions" with respect to select. Still looking. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Apr 17 04:44:39 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 17 Apr 2010 02:44:39 +0000 Subject: [M3devel] Modula-3/C interop in Date/Time? In-Reply-To: <81B495C9-A0B2-4884-A6FC-5D928FC38340@cs.purdue.edu> References: , ,,<4BC796B7.7090707@lcwb.coop>, , , , , , , <20100416070034.9C0911A20EB@async.async.caltech.edu>, , <81B495C9-A0B2-4884-A6FC-5D928FC38340@cs.purdue.edu> Message-ID: The use case is the TimeZone's in DatePosix.m3. It's not a big deal. There are just two constant timezones, "local", and "utc", identified by references to integers: NIL, ^ = 1 and ^ = 0. Where NIL is interpreted as 0 or 1. It could just be an enum, but the public type is REFANY and it is revealed in the Win32 flavor to actually be a reference to something else. I could maybe change that. But what is the effect on pickles either way? The Win32 one isn't picklable in either case?? I'm not sure. So Timezone isn't portably pickable? And therefore pickles of Posix timezones can be broken? If they were to be pickled, I think the representation is dubious -- probably should pickle the "offset" from GMT/UTC, not 0 or 1. The Win32 code is also dubious given evolution of the Win32 API over the years. It is more flexible now and I wonder if that implies the old API was insufficient. (Though "local" can change in time, not really "constant", as the daylight savings cutoff is crossed, or indeed when I travel with a computer and stuff says running but "asleep" and then "resumed". I'm quite suspicious that lots of code doesn't account for timezone changes. I'm also quite suspicious of any code that does anything timezone sensitive or uses "local" time for anything. Using GMT/UTC for everything, except display, is the way to go. It makes things vastly simpler and better defined. Could be that Unix/Posixy stuff is generally ok. Could be just an historical bogus favoring of localtime on PCs (and Macs?).) I actually strongly suspect as well that we can get by with just the one Posix implementation of this stuff, no BSD, no Win32. In particular, msvcr*.dll does expose tzname, timezone, daylight. Besides of course "small" localtime/gmtime. Have to think though "Time" vs. "Date". Win32 epoch is earlier, which is useful for representating dates in the past. Basically "this stuff" is more about "Date" and less about "Time", though they interact. I'm pretty sure we have bugs as well where we assume the current "daylight" status applies to all times/dates. Switching to "time64" is part of the equation. Maybe I should attack more from that angle. Make things work for Date{year := 2040} and see what all that implies. - Jay From: hosking at cs.purdue.edu Date: Fri, 16 Apr 2010 10:30:48 -0400 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] Modula-3/C interop in Date/Time? What is the use-case here? Merely having UNTRACED references doesn't make your code unsafe. Using ADR does. But why not have an interface with C that makes use of the fact that VAR parameters are passed as pointers to C. e.g., C function f(int *ref p) can be declared as <*EXTERNAL*> f(VAR i: INTEGER) and this is still safe. On 16 Apr 2010, at 04:18, Jay K wrote: Isn't making them unsafe? ADR? I'll try.. - Jay > To: jay.krell at cornell.edu > Date: Fri, 16 Apr 2010 00:00:34 -0700 > From: mika at async.async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Modula-3/C interop in Date/Time? > > I don't think there's anything unsafe about UNTRACED. > > It's DISPOSE that's unsafe... > > Mika > > Jay K writes: > >--_cbaca81c-f322-4f31-8684-e7f171e67f3d_ > >Content-Type: text/plain; charset="iso-2022-jp" > >Content-Transfer-Encoding: 7bit > > > >But then unsafe, right? > > > > - Jay > > > >> From: hosking at cs.purdue.edu > >> Date: Thu, 15 Apr 2010 22:06:14 -0400 > >> To: rodney_bates at lcwb.coop > >> CC: m3dev el at elegosoft.com > >> Subject: Re: [M3devel] Modula-3/C interop in Date/Time? > >> > >> Indeed! UNTRACED. > >> > >> > >> On 15 Apr 2010, at 18:44, Rodney M. Bates wrote: > >> > >> > Since these pointer variables are initialized by > >> > C code and their referents are also provided by C code > >> > as global variables, shouldn't the type be untraced? > >> > > >> > I suppose that, since they don't point into the traced > >> > heap, the collector implementation we have would quietly > >> > ignore them as roots. But that's relying on implementation- > >> > dependent information. > >> > > >> > Also, if someone created a field of type Date.TimeZone, > >> > (or an array of them) in a traced-heap-allocated object, > > > which is a perfectly legitimate thing to do, what would > >> > our collector do then? > >> > > >> > > >> > > >> > Jay K wrote: > >> >> Is this legal/correct? > >> >> > >> >> > >> >> Date.i3: > >> >> TYPE TimeZone <: REFANY; > >> >> VAR Local, UTC: TimeZone; (* granted, will maybe change these to extern *) > >> >> > >> >> > >> >> Date.m3:? > >> >> REVEAL TimeZone = BRANDED "Date.TimeZone" REF INTEGER; > >> >> ? > >> >> > >> >> DatePosixC.c: > >> >> static const int Local = 0& #59; > >> >> static const int UTC = 1; > >> >> extern const int const * const Date__Local = &Local; > >> >> extern const int const * const Date__UTC = &UTC; > >> >> ? > >> >> > >> >> - Jay > >> > > > >--_cbaca81c-f322-4f31-8684-e7f171e67f3d_ > >Content-Type: text/html; charset="iso-2022-jp" > >Content-Transfer-Encoding: 7bit > > > > > > > > > > >But then unsafe, right?

- Jay

> From: hosking@cs.purdue.edu
> Date: Thu, 15 Apr 2010 22:06:14 -0400
> To: rodney_bates& > >#64;lcwb.coop
> CC: m3devel@elegosoft.com
> Subject: Re: [M3devel] Modula-3/C interop in Date/Time?
>
> Indeed! UNTRACED.
>
> < > >br>> On 15 Apr 2010, at 18:44, Rodney M. Bates wrote:
>
> > Since these pointer variables are initialized by
> & #38;#62; C code and their referents are also provided by C > > code
> > as global variables, shouldn't the type be untraced?
> >
> > I suppose that, since they don't point into the traced
> > heap, the collect > >or implementation we have would quietly
> > ignore them as roots. But that's relying on implementation-
> > dependent information.
> >
> > Also, if someon > >e created a field of type Date.TimeZone,
> > > > ; (or an array of them) in a traced-heap-allocated object,
> > which is a perfectly legitimate thing to do, what would
> > our collector do then?
> >
> >> >
> >
> > Jay K wrote:
> >> Is this legal/correct?
> >>
> >>
> >> Date.i3:
> >> TYPE TimeZone > > <: REFANY;
> >> VAR Local, UTC: TimeZone; (* granted, will maybe change these to extern *)
> >>
> >&# 38;#62;
> >> > > Date.m3: 
> >> REVEAL TimeZone = BRANDED "Date.TimeZone" REF INTEGER;
> >>  
> >>
> >> DatePosixC.c:
> >> >> static const int Local = 0;
> >> static const int UTC = 1;
> >> extern const int const * const Date__Local = &Local;
> > > >> extern const int con st * const Dat > > e__UTC = &UTC;
> >>  
> >>
> >> - Jay
>
> > > >--_cbaca81c-f322-4f31-8684-e7f171e67f3d_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sat Apr 17 13:22:14 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 17 Apr 2010 13:22:14 +0200 Subject: [M3devel] picking which files to package? In-Reply-To: References: Message-ID: <20100417132214.a2z13qxcoc8g0gs4@mail.elegosoft.com> You need to set STAGE differently if you want to run make-dist for different targets on the same machine. It's been done for SOLgnu and SOLsun, too. If you really want to build concurrently, you also need to change INSTBASE before sourcing defs.sh. Olaf Quoting Jay K : > > Olaf, any chance you can limit what files are picked up to the > $TARGET and src directories? > The I386_DARWIN/AMD64_DARWIN packages I made contain each of other's files > due to just picking up "everything". > > Maybe: > > iff -u -r1.26.2.51 make-dist.sh > --- make-dist.sh 17 Apr 2010 03:55:43 -0000 1.26.2.51 > +++ make-dist.sh 17 Apr 2010 08:05:13 -0000 > @@ -338,12 +338,16 @@ > ) > collection-${c}.html > echo "collection-${c}.html" > ARCHIVE="${STAGE}/cm3-bin-ws-${c}-${TARGET}-${CM3VERSION}-${DS}.tgz" > + a="" > + for b in ${PKGS}; do > + a="${a} ${b}/src ${b}/${TARGET}" > + done > if [ -z "${NOARCHIVE}" -a "${c}" != "min" ]; then > "${TAR}" --exclude '*.o' --exclude '*.mo' --exclude '*.io' \ > --exclude '*/CVS/*' --exclude '*/CVS' --exclude '*~' \ > --exclude '*.tar.*' --exclude '*.tgz' --exclude "*/${TARGET}/gcc" \ > --exclude "*/${TARGET}/*/*" \ > - -czf "${ARCHIVE}" collection-${c}.html install.sh setup.txt > setup.cmd ${PKGS} > + -czf "${ARCHIVE}" collection-${c}.html install.sh setup.txt > setup.cmd ${a} > ls -l "${ARCHIVE}" > fi > done > > > - Jay > -- 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 Sat Apr 17 13:55:39 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 17 Apr 2010 13:55:39 +0200 Subject: [M3devel] releng 5.8 for I386_DARWIN In-Reply-To: References: <20100416141032.doe6pi088o0w8gsk@mail.elegosoft.com>, , <20100416150010.7yzjrn8dwkkwowcc@mail.elegosoft.com> Message-ID: <20100417135539.8bjp68negwk480ks@mail.elegosoft.com> Quoting Jay K : > I just made a somewhat significant change in head and then copied > head to release in m3-sys/cm3 to deal with this. > > I get other problems on AMD64_DARWIN I believe unrelated. > > I'll keep looking. Let's not put that in RC5 unless it's really broken for other targets, too. In this case we have to remove the existing packages and rebuild everything. I'd like to avoid that. I've moved the Darwin files into post-RC5. I'd really like to finish this release... Olaf > From: jay.krell at cornell.edu > To: wagner at elegosoft.com > Subject: RE: releng 5.8 for I386_DARWIN > Date: Fri, 16 Apr 2010 13:13:49 +0000 > > > > drat, AMD64_DARWIN gets far, but then complains about bad .M3SHIP files. > > - Jay -- 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 jay.krell at cornell.edu Sat Apr 17 14:03:17 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 17 Apr 2010 12:03:17 +0000 Subject: [M3devel] releng 5.8 for I386_DARWIN In-Reply-To: <20100417135539.8bjp68negwk480ks@mail.elegosoft.com> References: <20100416141032.doe6pi088o0w8gsk@mail.elegosoft.com>, , <20100416150010.7yzjrn8dwkkwowcc@mail.elegosoft.com>, , <20100417135539.8bjp68negwk480ks@mail.elegosoft.com> Message-ID: I don't actually understand the .M3SHIP breakage. Instead I made the code a bit more obviously correct -- apply some path canonicalization. I can understand that root/bin/../lib would prevent replacement with LIB_INSTALL, but BIN_INSTALL or INSTALL_ROOT should still have been unresolved. There's still an inconsistency in that all but one of the unresolved paths do not end in a slash. But it should be ok. Just that that the slash will or not be unresolved along with the rest. I understand it's not a great situation. I'm going to rebuild I386_DARWIN and AMD64_DARWIN, sequentially. - Jay > Date: Sat, 17 Apr 2010 13:55:39 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: RE: releng 5.8 for I386_DARWIN > > Quoting Jay K : > > > I just made a somewhat significant change in head and then copied > > head to release in m3-sys/cm3 to deal with this. > > > > I get other problems on AMD64_DARWIN I believe unrelated. > > > > I'll keep looking. > > Let's not put that in RC5 unless it's really broken for other targets, too. > In this case we have to remove the existing packages and rebuild everything. > I'd like to avoid that. > > I've moved the Darwin files into post-RC5. > > I'd really like to finish this release... > > Olaf > > > From: jay.krell at cornell.edu > > To: wagner at elegosoft.com > > Subject: RE: releng 5.8 for I386_DARWIN > > Date: Fri, 16 Apr 2010 13:13:49 +0000 > > > > > > > > drat, AMD64_DARWIN gets far, but then complains about bad .M3SHIP files. > > > > - Jay > -- > 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 jay.krell at cornell.edu Sat Apr 17 14:08:45 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 17 Apr 2010 12:08:45 +0000 Subject: [M3devel] picking which files to package? In-Reply-To: <20100417132214.a2z13qxcoc8g0gs4@mail.elegosoft.com> References: , <20100417132214.a2z13qxcoc8g0gs4@mail.elegosoft.com> Message-ID: Can you maybe append TARGET to $STAGE, $INSTBASE, etc. consistently, as needed, on all platforms? - There are other bi/multiarch platforms? I'm not sure how widely that notion has taken hold, e.g. AMD64_LINUX? - For when we extensively cross build. (soon?) I'll run sequentially for now. - Jay > Date: Sat, 17 Apr 2010 13:22:14 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: picking which files to package? > > You need to set STAGE differently if you want to run make-dist > for different targets on the same machine. It's been done for SOLgnu and > SOLsun, too. If you really want to build concurrently, you also need to > change INSTBASE before sourcing defs.sh. > > Olaf > > Quoting Jay K : > > > > > Olaf, any chance you can limit what files are picked up to the > > $TARGET and src directories? > > The I386_DARWIN/AMD64_DARWIN packages I made contain each of other's files > > due to just picking up "everything". > > > > Maybe: > > > > iff -u -r1.26.2.51 make-dist.sh > > --- make-dist.sh 17 Apr 2010 03:55:43 -0000 1.26.2.51 > > +++ make-dist.sh 17 Apr 2010 08:05:13 -0000 > > @@ -338,12 +338,16 @@ > > ) > collection-${c}.html > > echo "collection-${c}.html" > > ARCHIVE="${STAGE}/cm3-bin-ws-${c}-${TARGET}-${CM3VERSION}-${DS}.tgz" > > + a="" > > + for b in ${PKGS}; do > > + a="${a} ${b}/src ${b}/${TARGET}" > > + done > > if [ -z "${NOARCHIVE}" -a "${c}" != "min" ]; then > > "${TAR}" --exclude '*.o' --exclude '*.mo' --exclude '*.io' \ > > --exclude '*/CVS/*' --exclude '*/CVS' --exclude '*~' \ > > --exclude '*.tar.*' --exclude '*.tgz' --exclude "*/${TARGET}/gcc" \ > > --exclude "*/${TARGET}/*/*" \ > > - -czf "${ARCHIVE}" collection-${c}.html install.sh setup.txt > > setup.cmd ${PKGS} > > + -czf "${ARCHIVE}" collection-${c}.html install.sh setup.txt > > setup.cmd ${a} > > ls -l "${ARCHIVE}" > > fi > > done > > > > > > - Jay > > > > > > -- > 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 Sat Apr 17 14:34:34 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 17 Apr 2010 14:34:34 +0200 Subject: [M3devel] picking which files to package? In-Reply-To: References: , <20100417132214.a2z13qxcoc8g0gs4@mail.elegosoft.com> Message-ID: <20100417143434.lbf1epa6ec4kogsg@mail.elegosoft.com> Quoting Jay K : > > Can you maybe append TARGET to $STAGE, $INSTBASE, etc. consistently, > as needed, on all platforms? > - There are other bi/multiarch platforms? I'm not sure how widely > that notion has taken hold, e.g. AMD64_LINUX? > > - For when we extensively cross build. (soon?) > > I'll run sequentially for now. We can do that for the next builds. But let's be careful not to break the release tooling again. Olaf > - Jay > > >> Date: Sat, 17 Apr 2010 13:22:14 +0200 >> From: wagner at elegosoft.com >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: Re: picking which files to package? >> >> You need to set STAGE differently if you want to run make-dist >> for different targets on the same machine. It's been done for SOLgnu and >> SOLsun, too. If you really want to build concurrently, you also need to >> change INSTBASE before sourcing defs.sh. >> >> Olaf >> >> Quoting Jay K : >> >> > >> > Olaf, any chance you can limit what files are picked up to the >> > $TARGET and src directories? >> > The I386_DARWIN/AMD64_DARWIN packages I made contain each of other's files >> > due to just picking up "everything". >> > >> > Maybe: >> > >> > iff -u -r1.26.2.51 make-dist.sh >> > --- make-dist.sh 17 Apr 2010 03:55:43 -0000 1.26.2.51 >> > +++ make-dist.sh 17 Apr 2010 08:05:13 -0000 >> > @@ -338,12 +338,16 @@ >> > ) > collection-${c}.html >> > echo "collection-${c}.html" >> > ARCHIVE="${STAGE}/cm3-bin-ws-${c}-${TARGET}-${CM3VERSION}-${DS}.tgz" >> > + a="" >> > + for b in ${PKGS}; do >> > + a="${a} ${b}/src ${b}/${TARGET}" >> > + done >> > if [ -z "${NOARCHIVE}" -a "${c}" != "min" ]; then >> > "${TAR}" --exclude '*.o' --exclude '*.mo' --exclude '*.io' \ >> > --exclude '*/CVS/*' --exclude '*/CVS' --exclude '*~' \ >> > --exclude '*.tar.*' --exclude '*.tgz' --exclude "*/${TARGET}/gcc" \ >> > --exclude "*/${TARGET}/*/*" \ >> > - -czf "${ARCHIVE}" collection-${c}.html install.sh setup.txt >> > setup.cmd ${PKGS} >> > + -czf "${ARCHIVE}" collection-${c}.html install.sh setup.txt >> > setup.cmd ${a} >> > ls -l "${ARCHIVE}" >> > fi >> > done >> > >> > >> > - Jay >> > >> >> >> >> -- >> 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 Sat Apr 17 14:53:55 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 17 Apr 2010 08:53:55 -0400 Subject: [M3devel] release engineering 5.8: code generator error for IP address initializers In-Reply-To: References: <20100416114509.eh8r662dwss44oo8@mail.elegosoft.com>, , <20100416125048.183752ukg4os0kgk@mail.elegosoft.com> , <908A7AC8-565B-4749-A325-BE13F99F70D7@cs.purdue.edu> Message-ID: <64998360-2467-4204-9967-8C0B158FECC5@cs.purdue.edu> The RHS is a constant array *constructor*. On 16 Apr 2010, at 21:50, Jay K wrote: > There is this thing I read, where the types of values/constants are known without context. > The left hand side does not change the type of the right. > That confuses me here. It would imply the right is an open array. > > - Jay > > > Subject: Re: [M3devel] release engineering 5.8: code generator error for IP address initializers > From: hosking at cs.purdue.edu > Date: Fri, 16 Apr 2010 11:04:49 -0400 > CC: wagner at elegosoft.com; m3devel at elegosoft.com > To: jay.krell at cornell.edu > > You are confusing open array types with array constructors. > > On 16 Apr 2010, at 08:15, Jay K wrote: > > (back to the topic :) ) > > somewhat reduced case: > MODULE Main; > TYPE T1 = ARRAY [0..0] OF INTEGER; > CONST const: T1 = ARRAY OF INTEGER{2}; > > This is an array constructor. > > I suspect this is the same issue as in my previous e-mail. The following concise rewrite should work: > > CONST const = T1{2}; > > BEGIN > END Main. > > The problem is two global integers are overlapping. > The open array size and its first element. > > new source -> compiling Main.m3 > "..\Main.m3", line 5: warning: not used (const) > m3front:cg:Init_int:NOT in_init: o: 32 s:32 value:2 <== > m3front:cg:Init_int:NOT in_init: o: 32 s:32 value:1 <== > m3front:cg:Init_int:NOT in_init: o: 384 s:32 value:3 > m3front:cg:Init_int:in_init: o: 32 s:32 value:1 > m3front:cg:Init_int:in_init: o: 32 s:32 value:2 > > Are these syntaxes legal? > This apparent mixing of open and fixed arrays? > > - Jay > > > > Date: Fri, 16 Apr 2010 12:50:48 +0200 > > From: wagner at elegosoft.com > > To: jay.krell at cornell.edu > > CC: m3devel at elegosoft.com > > Subject: RE: [M3devel] release engineering 5.8: code generator error for IP address initializers > > > > I agree. Regular expressions in quake would be great for regression tests. > > Perhaps for the next release? > > > > Olaf > > > > Quoting Jay K : > > > > > "aside": > > > > > > http://hudson.modula3.com:8080/job/cm3-test-m3tests-AMD64_FREEBSD/lastBuild/testReport/(root)/m3tests/p206__ARRAY_constructors_in_var_decls_using_named_open_array_types/ > > > > > > http://hudson.modula3.com:8080/job/cm3-test-m3tests-AMD64_FREEBSD/lastBuild/testReport/(root)/m3tests/r004__negative_size_for_an_open_array/ > > > > > > > > > It'd be nice if in Quake we had something regular expression-ish, so > > > that we could factor out the line numbers, such as e.g. to match > > > any decimal number. > > > > > > > > > Maybe just check for lines that start how we expect and cut them off > > > at some position. > > > That might be doable with today's Quake. > > > > > > > > > > > > - Jay > > > > > > > > > > > >> Date: Fri, 16 Apr 2010 11:45:09 +0200 > > >> From: wagner at elegosoft.com > > >> To: m3devel at elegosoft.com > > >> Subject: [M3devel] release engineering 5.8: code generator error > > >> for IP address initializers > > >> > > >> We also have this error, which should perhaps not be ignored? > > >> > > >> http://hudson.modula3.com:8080/job/cm3-test-m3tests-AMD64_FREEBSD/lastBuild/testReport/(root)/m3tests/p204__IP_address_initializers > > >> > > >> 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 > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Sat Apr 17 02:41:34 2010 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sat, 17 Apr 2010 00:41:34 +0000 (GMT) Subject: [M3devel] About problem compiling with cm3-bin-core-AMD64_LINUX-5.8.5-RC5 Message-ID: <493637.42836.qm@web23603.mail.ird.yahoo.com> Hi all: I think I made a silly mistake I did compile the d5.7 tree so I guess m3cc is different than of the current RC5 m3cc. If you have a md5sum of RC5 please put it in the web page. I'm rebuilding it again now with the RC5 tree, so far it looks good. Thanks for your attention, --- El vie, 16/4/10, Daniel Alejandro Benavides D. escribi?: > De: Daniel Alejandro Benavides D. > Asunto: About problem compiling with cm3-bin-core-AMD64_LINUX-5.8.5-RC5 > Para: m3devel at elegosoft.com > Fecha: viernes, 16 de abril, 2010 19:18 > Hi all: > I'm trying to build in kubuntu karmic 9.10 the RC5 but got > early after compiling succesfully m3cc in this output a > problem at: > "internal compiler error: in emit_move_insn, at > expr.c:3379 > > > > > " > The file I downloaded has the following md5sum, is that > correct?: > d9ac8a12cdeccb8b5d7ee856c113366f > cm3-bin-core-AMD64_LINUX-5.8.5-RC5.tgz > > Could you suggest me something to do here? > Thanks in advance > > root at mm01:/home/dabenavidesd/code/cm3/scripts# ./do-pkg.sh > buildship m3core libm3 m3middle m3linker m3front sysutils > m3quake m3objfile m3back cm3 > > > > /home/dabenavidesd/code/cm3/scripts/pkgmap.sh -c > "/usr/local/cm3/bin/cm3 -build > -DROOT='/home/dabenavidesd/code/cm3' > -DCM3_VERSION_TEXT='d5.7.0' -DCM3_VERSION_NUMBER='050700' > -DCM3_LAST_CHANGED='2008-03-16' && > /usr/local/cm3/bin/cm3 -ship > -DROOT='/home/dabenavidesd/code/cm3' > -DCM3_VERSION_TEXT='d5.7.0' -DCM3_VERSION_NUMBER='050700' > -DCM3_LAST_CHANGED='2008-03-16' " m3core libm3 m3middle > m3linker m3front sysutils m3quake m3objfile m3back cm3 > > === package /home/dabenavidesd/code/cm3/m3-libs/m3core > === > > > +++ /usr/local/cm3/bin/cm3 -build > -DROOT='/home/dabenavidesd/code/cm3' > -DCM3_VERSION_TEXT='d5.7.0' -DCM3_VERSION_NUMBER='050700' > -DCM3_LAST_CHANGED='2008-03-16' && > /usr/local/cm3/bin/cm3 -ship > -DROOT='/home/dabenavidesd/code/cm3' > -DCM3_VERSION_TEXT='d5.7.0' -DCM3_VERSION_NUMBER='050700' > -DCM3_LAST_CHANGED='2008-03-16' +++ > > > > --- building in AMD64_LINUX --- > > > > > > ignoring ../src/m3overrides > > new source -> compiling RTHooks.i3 > new source -> compiling RT0.i3 > new source -> compiling RuntimeError.i3 > new source -> compiling WordRep.i3 > > new source -> compiling Word.i3 > > new source -> compiling RTException.i3 > new source -> compiling RTHooks.m3 > > ../src/runtime/common/RTHooks.m3: In function > 'RTHooks__ReportFault': > ../src/runtime/common/RTHooks.m3:95: internal compiler > error: in emit_move_insn, at expr.c:3379 > > > > > > > Please submit a full bug report, > > > > > with preprocessed source if appropriate. > > > > See for > instructions. > > > m3_backend => 4 > > > > > > m3cc (aka cm3cg) failed compiling: RTHooks.mc > > > > new source -> compiling RT0.m3 > > > > > new source -> compiling Compiler.i3 > > > > > new source -> compiling RuntimeError.m3 > > > > > ../src/runtime/common/RuntimeError.m3: In function > 'RuntimeError__Self': > > ../src/runtime/common/RuntimeError.m3:13: internal compiler > error: in int_mode_for_mode, at stor-layout.c:258 > > > > > > Please submit a full bug report, > > > > > with preprocessed source if appropriate. > > > > See for > instructions. > > > m3_backend => 4 > > > > > > m3cc (aka cm3cg) failed compiling: RuntimeError.mc > > > > > From jay.krell at cornell.edu Sat Apr 17 17:08:04 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 17 Apr 2010 15:08:04 +0000 Subject: [M3devel] getting mac address with netbios Message-ID: We have this code: C:\dev2\cm3.2\m3-libs\libm3\src\uid\WIN32\MachineIDWin32.m3(33): EVAL NB30.Netbios(ADR(ncb)); C:\dev2\cm3.2\m3-libs\libm3\src\uid\WIN32\MachineIDWin32.m3(41): EVAL NB30.Netbios(ADR(ncb)); C:\dev2\cm3.2\m3-libs\libm3\src\uid\WIN32\MachineIDWin32.m3(48): EVAL NB30.Netbios(ADR(ncb)); I just noticed: http://msdn.microsoft.com/en-us/library/bb870913(VS.85).aspx [Netbios is not supported on Windows Vista, Windows Server 2008, and subsequent versions of the operating system] someone should try this out.. and change it to work if needed.. http://www.codeguru.com/Cpp/I-N/network/networkinformation/article.php/c5451 I'm pretty partial to the UuidCreate/UuidCreateSequential solution really. This MachineID probably needs more work anyway -- support for more operating systems. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.async.caltech.edu Sat Apr 17 19:40:28 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Sat, 17 Apr 2010 10:40:28 -0700 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <7430A649-C3AF-4D02-A943-46844E2323D7@cs.purdue.edu> References: <20100417111631.901C22474008@birch.elegosoft.com> <7430A649-C3AF-4D02-A943-46844E2323D7@cs.purdue.edu> Message-ID: <20100417174028.41B551A20FA@async.async.caltech.edu> Tony Hosking writes: >I actually still have an ALPHA_OSF box that I sometimes think of = >resurrecting. Is it really dead? ;-) Me, too. Furthermore, I (and the Internet) have a binary for the Extended Static Checker for Modula-3 for OSF/1 on Alpha. Not sure it exists in any other form nowadays... :-/ Mika > >On 17 Apr 2010, at 13:16, Jay Krell wrote: > >> CVSROOT: /usr/cvs >> Changes by: jkrell at birch. 10/04/17 13:16:31 >>=20 >> Removed files: >> cm3/m3-libs/m3core/src/C/: ChangeLog=20 >> cm3/m3-libs/m3core/src/C/AIX386/: Csetjmp.i3 m3makefile=20 >> cm3/m3-libs/m3core/src/C/ALPHA_OSF/: Csetjmp.i3 m3makefile=20 >> cm3/m3-libs/m3core/src/C/AP3000/: Csetjmp.i3 m3makefile=20 >> cm3/m3-libs/m3core/src/C/ARM/: Csetjmp.i3 m3makefile=20 >> cm3/m3-libs/m3core/src/C/DS3100/: Csetjmp.i3 m3makefile=20 >> cm3/m3-libs/m3core/src/C/FreeBSD/: COPYRIGHT Csetjmp.i3=20 >> m3makefile=20 >> cm3/m3-libs/m3core/src/C/FreeBSD2/: Csetjmp.i3 m3makefile=20 >> cm3/m3-libs/m3core/src/C/FreeBSD3/: COPYRIGHT Csetjmp.i3=20 >> m3makefile=20 >> cm3/m3-libs/m3core/src/C/HP300/: Csetjmp.i3 m3makefile=20 >> cm3/m3-libs/m3core/src/C/HPPA/: Csetjmp.i3 m3makefile=20 >> cm3/m3-libs/m3core/src/C/IBMR2/: Csetjmp.i3 m3makefile=20 >> cm3/m3-libs/m3core/src/C/IBMRT/: Csetjmp.i3 m3makefile=20 >> cm3/m3-libs/m3core/src/C/IRIX5/: Csetjmp.i3 m3makefile=20 >> cm3/m3-libs/m3core/src/C/LINUX/: Csetjmp.i3 m3makefile=20 >> cm3/m3-libs/m3core/src/C/LINUXELF/: Csetjmp.i3 m3makefile=20 >> cm3/m3-libs/m3core/src/C/NEXT/: Csetjmp.i3 m3makefile=20 >> cm3/m3-libs/m3core/src/C/OKI/: Csetjmp.i3 m3makefile setjmp.s=20 >> signal.o=20 >> cm3/m3-libs/m3core/src/C/OS2/: Csetjmp.i3 m3makefile=20 >> cm3/m3-libs/m3core/src/C/SEQUENT/: Csetjmp.i3 m3makefile=20 >> cm3/m3-libs/m3core/src/C/SPARC/: Csetjmp.i3 m3makefile=20 >> cm3/m3-libs/m3core/src/C/SUN3/: Csetjmp.i3 m3makefile=20 >> cm3/m3-libs/m3core/src/C/SUN386/: Csetjmp.i3 m3makefile=20 >> cm3/m3-libs/m3core/src/C/VAX/: Csetjmp.i3 m3makefile=20 >>=20 >> Log message: >> delete lots of dead/dormant platforms, even some that *might* = >come back >> It is easy enough to bring them back. From mika at async.async.caltech.edu Sat Apr 17 20:35:54 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Sat, 17 Apr 2010 11:35:54 -0700 Subject: [M3devel] example of bug in NetObj Stub Generator In-Reply-To: References: , , <7C7408D0-9A40-4988-BADA-A9FD8C15D388@cs.purdue.edu>, , Message-ID: <20100417183554.431441A20FA@async.async.caltech.edu> Hi Randy, The issue is that RECORDs are marshalled "manually" by the stub code, rather than being passed as a Pickle. Therefore, imports are needed for record fields. The change that is needed is the following: Line 291 of CodeForType.m3, currently IF byName AND t.name # NIL THEN change to IF NOT ISTYPE(t,Type.Record) AND byName AND t.name # NIL THEN I would commit this myself but I have lost track of my non-anon CM3 checkout. Can someone do the honors, please? Mika P.S. It is possible the fix is a bit pessimistic, not sure the literal type name is required for every type of record field. Worst-case breakage: stub code generates a warning when compiled. From dabenavidesd at yahoo.es Sat Apr 17 02:18:27 2010 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sat, 17 Apr 2010 00:18:27 +0000 (GMT) Subject: [M3devel] About problem compiling with cm3-bin-core-AMD64_LINUX-5.8.5-RC5 Message-ID: <316058.64510.qm@web23604.mail.ird.yahoo.com> Hi all: I'm trying to build in kubuntu karmic 9.10 the RC5 but got early after compiling succesfully m3cc in this output a problem at: "internal compiler error: in emit_move_insn, at expr.c:3379 " The file I downloaded has the following md5sum, is that correct?: d9ac8a12cdeccb8b5d7ee856c113366f cm3-bin-core-AMD64_LINUX-5.8.5-RC5.tgz Could you suggest me something to do here? Thanks in advance root at mm01:/home/dabenavidesd/code/cm3/scripts# ./do-pkg.sh buildship m3core libm3 m3middle m3linker m3front sysutils m3quake m3objfile m3back cm3 /home/dabenavidesd/code/cm3/scripts/pkgmap.sh -c "/usr/local/cm3/bin/cm3 -build -DROOT='/home/dabenavidesd/code/cm3' -DCM3_VERSION_TEXT='d5.7.0' -DCM3_VERSION_NUMBER='050700' -DCM3_LAST_CHANGED='2008-03-16' && /usr/local/cm3/bin/cm3 -ship -DROOT='/home/dabenavidesd/code/cm3' -DCM3_VERSION_TEXT='d5.7.0' -DCM3_VERSION_NUMBER='050700' -DCM3_LAST_CHANGED='2008-03-16' " m3core libm3 m3middle m3linker m3front sysutils m3quake m3objfile m3back cm3 === package /home/dabenavidesd/code/cm3/m3-libs/m3core === +++ /usr/local/cm3/bin/cm3 -build -DROOT='/home/dabenavidesd/code/cm3' -DCM3_VERSION_TEXT='d5.7.0' -DCM3_VERSION_NUMBER='050700' -DCM3_LAST_CHANGED='2008-03-16' && /usr/local/cm3/bin/cm3 -ship -DROOT='/home/dabenavidesd/code/cm3' -DCM3_VERSION_TEXT='d5.7.0' -DCM3_VERSION_NUMBER='050700' -DCM3_LAST_CHANGED='2008-03-16' +++ --- building in AMD64_LINUX --- ignoring ../src/m3overrides new source -> compiling RTHooks.i3 new source -> compiling RT0.i3 new source -> compiling RuntimeError.i3 new source -> compiling WordRep.i3 new source -> compiling Word.i3 new source -> compiling RTException.i3 new source -> compiling RTHooks.m3 ../src/runtime/common/RTHooks.m3: In function 'RTHooks__ReportFault': ../src/runtime/common/RTHooks.m3:95: internal compiler error: in emit_move_insn, at expr.c:3379 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. m3_backend => 4 m3cc (aka cm3cg) failed compiling: RTHooks.mc new source -> compiling RT0.m3 new source -> compiling Compiler.i3 new source -> compiling RuntimeError.m3 ../src/runtime/common/RuntimeError.m3: In function 'RuntimeError__Self': ../src/runtime/common/RuntimeError.m3:13: internal compiler error: in int_mode_for_mode, at stor-layout.c:258 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. m3_backend => 4 m3cc (aka cm3cg) failed compiling: RuntimeError.mc From jay.krell at cornell.edu Sun Apr 18 00:50:28 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 17 Apr 2010 22:50:28 +0000 Subject: [M3devel] About problem compiling with cm3-bin-core-AMD64_LINUX-5.8.5-RC5 In-Reply-To: <316058.64510.qm@web23604.mail.ird.yahoo.com> References: <316058.64510.qm@web23604.mail.ird.yahoo.com> Message-ID: (probably the mail arrived out of order?) From: jay.krell at cornell.edu To: dabenavidesd at yahoo.es; m3devel at elegosoft.com Subject: RE: [M3devel] About problem compiling with cm3-bin-core-AMD64_LINUX-5.8.5-RC5 Date: Sat, 17 Apr 2010 22:49:34 +0000 Daniel, As your other mail indicated, you are building some old source. >> DCM3_VERSION_TEXT='d5.7.0' -DCM3_VERSION_NUMBER='050700' -DCM3_LAST_CHANGED='2008-03-16' Please try head or release. (Head doesn't even pass these -D version switches any more, but release does). "install" almost any release export PATH=/usr/local/cm3/bin:$PATH cvs -z3 checkout ... cd .../scripts/python ./upgrade.py ./do-cm3-all.py skipgcc realclean ./do-cm3-all.py skipgcc buildship (upgrade.py only builds the compiler and the libraries it uses; upgrade.sh builds everything) (Granted, whatever tree you are using, should work, but...) - Jay > Date: Sat, 17 Apr 2010 00:18:27 +0000 > From: dabenavidesd at yahoo.es > To: m3devel at elegosoft.com > Subject: [M3devel] About problem compiling with cm3-bin-core-AMD64_LINUX-5.8.5-RC5 > > Hi all: > I'm trying to build in kubuntu karmic 9.10 the RC5 but got early after compiling succesfully m3cc in this output a problem at: > "internal compiler error: in emit_move_insn, at expr.c:3379 " > The file I downloaded has the following md5sum, is that correct?: > d9ac8a12cdeccb8b5d7ee856c113366f cm3-bin-core-AMD64_LINUX-5.8.5-RC5.tgz > > Could you suggest me something to do here? > Thanks in advance > > root at mm01:/home/dabenavidesd/code/cm3/scripts# ./do-pkg.sh buildship m3core libm3 m3middle m3linker m3front sysutils m3quake m3objfile m3back cm3 > /home/dabenavidesd/code/cm3/scripts/pkgmap.sh -c "/usr/local/cm3/bin/cm3 -build -DROOT='/home/dabenavidesd/code/cm3' -DCM3_VERSION_TEXT='d5.7.0' -DCM3_VERSION_NUMBER='050700' -DCM3_LAST_CHANGED='2008-03-16' && /usr/local/cm3/bin/cm3 -ship -DROOT='/home/dabenavidesd/code/cm3' -DCM3_VERSION_TEXT='d5.7.0' -DCM3_VERSION_NUMBER='050700' -DCM3_LAST_CHANGED='2008-03-16' " m3core libm3 m3middle m3linker m3front sysutils m3quake m3objfile m3back cm3 > === package /home/dabenavidesd/code/cm3/m3-libs/m3core === > +++ /usr/local/cm3/bin/cm3 -build -DROOT='/home/dabenavidesd/code/cm3' -DCM3_VERSION_TEXT='d5.7.0' -DCM3_VERSION_NUMBER='050700' -DCM3_LAST_CHANGED='2008-03-16' && /usr/local/cm3/bin/cm3 -ship -DROOT='/home/dabenavidesd/code/cm3' -DCM3_VERSION_TEXT='d5.7.0' -DCM3_VERSION_NUMBER='050700' -DCM3_LAST_CHANGED='2008-03-16' +++ > --- building in AMD64_LINUX --- > > ignoring ../src/m3overrides > > new source -> compiling RTHooks.i3 > new source -> compiling RT0.i3 > new source -> compiling RuntimeError.i3 > new source -> compiling WordRep.i3 > new source -> compiling Word.i3 > new source -> compiling RTException.i3 > new source -> compiling RTHooks.m3 > ../src/runtime/common/RTHooks.m3: In function 'RTHooks__ReportFault': > ../src/runtime/common/RTHooks.m3:95: internal compiler error: in emit_move_insn, at expr.c:3379 > Please submit a full bug report, > with preprocessed source if appropriate. > See for instructions. > m3_backend => 4 > m3cc (aka cm3cg) failed compiling: RTHooks.mc > new source -> compiling RT0.m3 > new source -> compiling Compiler.i3 > new source -> compiling RuntimeError.m3 > ../src/runtime/common/RuntimeError.m3: In function 'RuntimeError__Self': > ../src/runtime/common/RuntimeError.m3:13: internal compiler error: in int_mode_for_mode, at stor-layout.c:258 > Please submit a full bug report, > with preprocessed source if appropriate. > See for instructions. > m3_backend => 4 > m3cc (aka cm3cg) failed compiling: RuntimeError.mc > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Apr 18 00:49:34 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 17 Apr 2010 22:49:34 +0000 Subject: [M3devel] About problem compiling with cm3-bin-core-AMD64_LINUX-5.8.5-RC5 In-Reply-To: <316058.64510.qm@web23604.mail.ird.yahoo.com> References: <316058.64510.qm@web23604.mail.ird.yahoo.com> Message-ID: Daniel, As your other mail indicated, you are building some old source. >> DCM3_VERSION_TEXT='d5.7.0' -DCM3_VERSION_NUMBER='050700' -DCM3_LAST_CHANGED='2008-03-16' Please try head or release. (Head doesn't even pass these -D version switches any more, but release does). "install" almost any release export PATH=/usr/local/cm3/bin:$PATH cvs -z3 checkout ... cd .../scripts/python ./upgrade.py ./do-cm3-all.py skipgcc realclean ./do-cm3-all.py skipgcc buildship (upgrade.py only builds the compiler and the libraries it uses; upgrade.sh builds everything) (Granted, whatever tree you are using, should work, but...) - Jay > Date: Sat, 17 Apr 2010 00:18:27 +0000 > From: dabenavidesd at yahoo.es > To: m3devel at elegosoft.com > Subject: [M3devel] About problem compiling with cm3-bin-core-AMD64_LINUX-5.8.5-RC5 > > Hi all: > I'm trying to build in kubuntu karmic 9.10 the RC5 but got early after compiling succesfully m3cc in this output a problem at: > "internal compiler error: in emit_move_insn, at expr.c:3379 " > The file I downloaded has the following md5sum, is that correct?: > d9ac8a12cdeccb8b5d7ee856c113366f cm3-bin-core-AMD64_LINUX-5.8.5-RC5.tgz > > Could you suggest me something to do here? > Thanks in advance > > root at mm01:/home/dabenavidesd/code/cm3/scripts# ./do-pkg.sh buildship m3core libm3 m3middle m3linker m3front sysutils m3quake m3objfile m3back cm3 > /home/dabenavidesd/code/cm3/scripts/pkgmap.sh -c "/usr/local/cm3/bin/cm3 -build -DROOT='/home/dabenavidesd/code/cm3' -DCM3_VERSION_TEXT='d5.7.0' -DCM3_VERSION_NUMBER='050700' -DCM3_LAST_CHANGED='2008-03-16' && /usr/local/cm3/bin/cm3 -ship -DROOT='/home/dabenavidesd/code/cm3' -DCM3_VERSION_TEXT='d5.7.0' -DCM3_VERSION_NUMBER='050700' -DCM3_LAST_CHANGED='2008-03-16' " m3core libm3 m3middle m3linker m3front sysutils m3quake m3objfile m3back cm3 > === package /home/dabenavidesd/code/cm3/m3-libs/m3core === > +++ /usr/local/cm3/bin/cm3 -build -DROOT='/home/dabenavidesd/code/cm3' -DCM3_VERSION_TEXT='d5.7.0' -DCM3_VERSION_NUMBER='050700' -DCM3_LAST_CHANGED='2008-03-16' && /usr/local/cm3/bin/cm3 -ship -DROOT='/home/dabenavidesd/code/cm3' -DCM3_VERSION_TEXT='d5.7.0' -DCM3_VERSION_NUMBER='050700' -DCM3_LAST_CHANGED='2008-03-16' +++ > --- building in AMD64_LINUX --- > > ignoring ../src/m3overrides > > new source -> compiling RTHooks.i3 > new source -> compiling RT0.i3 > new source -> compiling RuntimeError.i3 > new source -> compiling WordRep.i3 > new source -> compiling Word.i3 > new source -> compiling RTException.i3 > new source -> compiling RTHooks.m3 > ../src/runtime/common/RTHooks.m3: In function 'RTHooks__ReportFault': > ../src/runtime/common/RTHooks.m3:95: internal compiler error: in emit_move_insn, at expr.c:3379 > Please submit a full bug report, > with preprocessed source if appropriate. > See for instructions. > m3_backend => 4 > m3cc (aka cm3cg) failed compiling: RTHooks.mc > new source -> compiling RT0.m3 > new source -> compiling Compiler.i3 > new source -> compiling RuntimeError.m3 > ../src/runtime/common/RuntimeError.m3: In function 'RuntimeError__Self': > ../src/runtime/common/RuntimeError.m3:13: internal compiler error: in int_mode_for_mode, at stor-layout.c:258 > Please submit a full bug report, > with preprocessed source if appropriate. > See for instructions. > m3_backend => 4 > m3cc (aka cm3cg) failed compiling: RuntimeError.mc > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.async.caltech.edu Sun Apr 18 04:35:35 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Sat, 17 Apr 2010 19:35:35 -0700 Subject: [M3devel] INTEGER In-Reply-To: References: , , <7C7408D0-9A40-4988-BADA-A9FD8C15D388@cs.purdue.edu>, , Message-ID: <20100418023535.3BA9E1A2103@async.async.caltech.edu> Ok, sorry if I am beating a dead horse here. What is INTEGER on a 64-bit machine? Modula-3 doesn't specify it to be one or the other does it? But normally, 64 bits? I am asking because I was looking through some stub generator code, and I'm really wondering about the LONGINT. Now there are "longcard" things showing up, which means another set of changes to a lot of code. The rationale for LONGINT is, again? We need it to match 64-bit integers on 32-bit machines? That seems like a very weak rationale indeed, if the same functionality could be provided through some other mechanism (e.g., ARRAY [0..1] OF INTEGER---even with a pragma e.g. <*CLONGLONG*>.. if it is necessary to tell the compiler that a special linkage convention is needed). On a 64-bit machine INTEGER and CARDINAL are 64/63 bits (right?), so there is really no need for LONGINT there. And having an array with a LONGINT index seems silly since you can't address more memory than you can fit in an INTEGER anyhow... Mika >________________________________ >From: hosking at cs.purdue.edu >Date: Thu, 15 Apr 2010 12:55:52 -0400 >To: jay.krell at cornell.edu >CC: m3devel at elegosoft.com >Subject: Re: [M3devel] Modula-3/C interop in Date/Time? >Excepting that INTEGER is not the same as int on 64-bit platforms. > >Antony Hosking | Associate Professor | Computer Science | Purdue University >305 N. University Street | West Lafayette | IN 47907 | USA >Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > >On 15 Apr 2010, at 02:45, Jay K wrote: > >Is this legal/correct? > > >Date.i3: >TYPE TimeZone <: REFANY; >VAR Local, UTC: TimeZone; (* granted, will maybe change these to extern *) > > >Date.m3:=1B$B!!=1B(B >REVEAL TimeZone =3D BRANDED "Date.TimeZone" REF INTEGER; >=1B$B!!=1B(B > >DatePosixC.c: >static const int Local =3D 0; >static const int UTC =3D 1; >extern const int const * const Date__Local =3D &Local; >extern const int const * const Date__UTC =3D &UTC; >=1B$B!!=1B(B > >- Jay From hosking at cs.purdue.edu Sun Apr 18 04:40:20 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 17 Apr 2010 22:40:20 -0400 Subject: [M3devel] INTEGER In-Reply-To: <20100418023535.3BA9E1A2103@async.async.caltech.edu> References: , , <7C7408D0-9A40-4988-BADA-A9FD8C15D388@cs.purdue.edu>, , <20100418023535.3BA9E1A2103@async.async.caltech.edu> Message-ID: On 17 Apr 2010, at 22:35, Mika Nystrom wrote: > Ok, sorry if I am beating a dead horse here. > > What is INTEGER on a 64-bit machine? The language spec doesn't say, but CM3 pretty strongly assumes BITSIZE(INTEGER)=BITSIZE(ADDRESS). So, that means 64 bits. > Modula-3 doesn't specify it to be one or the other does it? > But normally, 64 bits? > > I am asking because I was looking through some stub generator code, > and I'm really wondering about the LONGINT. Now there are "longcard" > things showing up, which means another set of changes to a lot of code. > > The rationale for LONGINT is, again? Yes, LONGINT is to permit longer than "efficient" INTEGER. Mainly for 32 bit machines where we'd like to have a C "long long" equivalent. > We need it to match 64-bit integers on 32-bit machines? That seems like > a very weak rationale indeed, if the same functionality could be provided > through some other mechanism (e.g., ARRAY [0..1] OF INTEGER---even with > a pragma e.g. <*CLONGLONG*>.. if it is necessary to tell the compiler that > a special linkage convention is needed). There's no special linkage convention. Not sure what you mean here. > On a 64-bit machine INTEGER and CARDINAL are 64/63 bits (right?), so > there is really no need for LONGINT there. True. The only expectation is BITSIZE(LONGINT) >= BITSIZE(INTEGER). > And having an array with a LONGINT index seems silly since you can't > address more memory than you can fit in an INTEGER anyhow... We don't allow arrays with LONGINT indexes in the current implementation. > > Mika > >> ________________________________ >> From: hosking at cs.purdue.edu >> Date: Thu, 15 Apr 2010 12:55:52 -0400 >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] Modula-3/C interop in Date/Time? >> Excepting that INTEGER is not the same as int on 64-bit platforms. >> >> Antony Hosking | Associate Professor | Computer Science | Purdue University >> 305 N. University Street | West Lafayette | IN 47907 | USA >> Office +1 765 494 6001 | Mobile +1 765 427 5484 >> >> >> >> >> On 15 Apr 2010, at 02:45, Jay K wrote: >> >> Is this legal/correct? >> >> >> Date.i3: >> TYPE TimeZone <: REFANY; >> VAR Local, UTC: TimeZone; (* granted, will maybe change these to extern *) >> >> >> Date.m3:=1B$B!!=1B(B >> REVEAL TimeZone =3D BRANDED "Date.TimeZone" REF INTEGER; >> =1B$B!!=1B(B >> >> DatePosixC.c: >> static const int Local =3D 0; >> static const int UTC =3D 1; >> extern const int const * const Date__Local =3D &Local; >> extern const int const * const Date__UTC =3D &UTC; >> =1B$B!!=1B(B >> >> - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Apr 18 04:46:17 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 17 Apr 2010 22:46:17 -0400 Subject: [M3devel] INTEGER In-Reply-To: References: , , <7C7408D0-9A40-4988-BADA-A9FD8C15D388@cs.purdue.edu>, , <20100418023535.3BA9E1A2103@async.async.caltech.edu> Message-ID: <8604EE57-9661-4F82-BB51-DBFDC93844DC@cs.purdue.edu> On 17 Apr 2010, at 22:40, Tony Hosking wrote: > > On 17 Apr 2010, at 22:35, Mika Nystrom wrote: > >> Ok, sorry if I am beating a dead horse here. >> >> What is INTEGER on a 64-bit machine? > > The language spec doesn't say, but CM3 pretty strongly assumes BITSIZE(INTEGER)=BITSIZE(ADDRESS). > So, that means 64 bits. > >> Modula-3 doesn't specify it to be one or the other does it? >> But normally, 64 bits? >> >> I am asking because I was looking through some stub generator code, >> and I'm really wondering about the LONGINT. Now there are "longcard" >> things showing up, which means another set of changes to a lot of code. >> >> The rationale for LONGINT is, again? > > Yes, LONGINT is to permit longer than "efficient" INTEGER. Mainly for 32 bit machines where we'd like to have a C "long long" equivalent. > >> We need it to match 64-bit integers on 32-bit machines? That seems like >> a very weak rationale indeed, if the same functionality could be provided >> through some other mechanism (e.g., ARRAY [0..1] OF INTEGER---even with >> a pragma e.g. <*CLONGLONG*>.. if it is necessary to tell the compiler that >> a special linkage convention is needed). > > There's no special linkage convention. Not sure what you mean here. > >> On a 64-bit machine INTEGER and CARDINAL are 64/63 bits (right?), so >> there is really no need for LONGINT there. > > True. The only expectation is BITSIZE(LONGINT) >= BITSIZE(INTEGER). > >> And having an array with a LONGINT index seems silly since you can't >> address more memory than you can fit in an INTEGER anyhow... > > We don't allow arrays with LONGINT indexes in the current implementation. Correction. We do allow arrays with LONGINT subrange indexes, but the restriction is that NUMBER be representable as an INTEGER. > >> >> Mika >> >>> ________________________________ >>> From: hosking at cs.purdue.edu >>> Date: Thu, 15 Apr 2010 12:55:52 -0400 >>> To: jay.krell at cornell.edu >>> CC: m3devel at elegosoft.com >>> Subject: Re: [M3devel] Modula-3/C interop in Date/Time? >>> Excepting that INTEGER is not the same as int on 64-bit platforms. >>> >>> Antony Hosking | Associate Professor | Computer Science | Purdue University >>> 305 N. University Street | West Lafayette | IN 47907 | USA >>> Office +1 765 494 6001 | Mobile +1 765 427 5484 >>> >>> >>> >>> >>> On 15 Apr 2010, at 02:45, Jay K wrote: >>> >>> Is this legal/correct? >>> >>> >>> Date.i3: >>> TYPE TimeZone <: REFANY; >>> VAR Local, UTC: TimeZone; (* granted, will maybe change these to extern *) >>> >>> >>> Date.m3:=1B$B!!=1B(B >>> REVEAL TimeZone =3D BRANDED "Date.TimeZone" REF INTEGER; >>> =1B$B!!=1B(B >>> >>> DatePosixC.c: >>> static const int Local =3D 0; >>> static const int UTC =3D 1; >>> extern const int const * const Date__Local =3D &Local; >>> extern const int const * const Date__UTC =3D &UTC; >>> =1B$B!!=1B(B >>> >>> - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.async.caltech.edu Sun Apr 18 04:47:03 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Sat, 17 Apr 2010 19:47:03 -0700 Subject: [M3devel] INTEGER In-Reply-To: References: , , <7C7408D0-9A40-4988-BADA-A9FD8C15D388@cs.purdue.edu>, , <20100418023535.3BA9E1A2103@async.async.caltech.edu> Message-ID: <20100418024703.6965B1A2103@async.async.caltech.edu> Tony Hosking writes: > ... > >> We need it to match 64-bit integers on 32-bit machines? That seems = >like >> a very weak rationale indeed, if the same functionality could be = >provided >> through some other mechanism (e.g., ARRAY [0..1] OF INTEGER---even = >with >> a pragma e.g. <*CLONGLONG*>.. if it is necessary to tell the compiler = >that >> a special linkage convention is needed). > >There's no special linkage convention. Not sure what you mean here. > I just mean if we had TYPE LONGINT = ARRAY [0..1] OF INTEGER that would perhaps not match how C handles "long long" on the same platform (which is how, come to think of it?), and that would require special linkage tricks. But what would be lost? The ability to type literals. You could get the same code interface on 32- and 64-bit machine by defining TYPE FileOffset = ARRAY[0..1] OF [-16_80000000 .. +16_7fffffff ] and using that. Mika From jay.krell at cornell.edu Sun Apr 18 09:14:14 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 18 Apr 2010 07:14:14 +0000 Subject: [M3devel] INTEGER In-Reply-To: <20100418024703.6965B1A2103@async.async.caltech.edu> References: , , , <7C7408D0-9A40-4988-BADA-A9FD8C15D388@cs.purdue.edu>, , , , , , , <20100418023535.3BA9E1A2103@async.async.caltech.edu>, , <20100418024703.6965B1A2103@async.async.caltech.edu> Message-ID: TYPE LONGINT = ARRAY [0..1] OF INTEGER on a 32bit system is very close to LONGINT. Plus treating it opaquely and providing a bunch of functions to operate on it. Just as well therefore could be RECORD hi,lo:LONGINT END (see LARGE_INTEGER and ULARGE_INTEGER in winnt.h) Differences that come to mind: infix operators <=== possibly passed differently as a parameter or returned differently as a result ie. probably "directly compatible with" "long long", passed by value (of course you could always pass by pointer and achieve compatibilitity trivially) I have to say though, the biggest reason is in-fix operators. Convenient syntax. C++ is the best and some way worst of example of the general right way to do this -- you let programmers define types and their infix operators. Other languages just come with a passle of special cases of types that have in-fix operators. A good example is that Java infix operator + on string, besides the various integers, and nothing else. I think C# lets you define operators, yet people don't complain that it is "a mess" as they do of C++. I think Python does now too. So it is feature growing in popularity among "mainstream" languages, not just C++. C++ of course is extremely mainstream, but also a favorite target. (http://www.relisoft.com/tools/CppCritic.html) We also have subranges of LONGINT. I'm not sure what the generalization of subranges are, granted. Maybe some sort of C++ template that takes constants in the template and does range checks at runtime. Yeah, maybe. And as you point out, convenient literal syntax. People reasonably argue for library extension in place of language extension, but that requires a language which is flexible enough to write libraries with the desired interface, and so many languages don't let infix operators be in a user-written library. (There is a subtle but useless distinction here -- infix operators being in libraries vs. "user-written" libraries. The infix set operations for example are in a library, but not user-written, special, the compiler knows about it.) > that would perhaps not match how C handles "long long" on the same > platform (which is how, come to think of it?), and that would require On NT/x86, __int64/long long is returned in the register pair edx:eax. edx is high, eax is low. When passed as a parameter to __stdcall or __cdecl is just passed as two 32bit values adjacent on the stack, "hi, lo, hi, lo, it's off to push we go" is the Snow White-influenced mantra to remember how to pass them, at least on little endian stack-growing-down machines (which includes x86). For __fastcall I'm not sure they are passed in registers or on the stack. Passing and/or returning small structs also has special efficient handling in the ABI, so __int64 really might be equivalent to a small record. Not that cm3 necessarily implements that "correctly" -- for interop with C; for Modula-3 calling Modula-3 we can make up our own ABI so there isn't really an "incorrect" way. Notice the mingw problem I had passing a Win32 point struct by value, I cheated and passed it by VAR to a C wrapper to workaround the gcc backend bug (which was mentioned a few times and which I looked into the code for, but took the easy route) I don't know how long long works on other platforms but probably similar. Probably a certain register pair for return values. - Jay > To: hosking at cs.purdue.edu > Date: Sat, 17 Apr 2010 19:47:03 -0700 > From: mika at async.async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] INTEGER > > Tony Hosking writes: > > > ... > > > >> We need it to match 64-bit integers on 32-bit machines? That seems = > >like > >> a very weak rationale indeed, if the same functionality could be = > >provided > >> through some other mechanism (e.g., ARRAY [0..1] OF INTEGER---even = > >with > >> a pragma e.g. <*CLONGLONG*>.. if it is necessary to tell the compiler = > >that > >> a special linkage convention is needed). > > > >There's no special linkage convention. Not sure what you mean here. > > > > I just mean if we had > > TYPE LONGINT = ARRAY [0..1] OF INTEGER > > that would perhaps not match how C handles "long long" on the same > platform (which is how, come to think of it?), and that would require > special linkage tricks. > > But what would be lost? The ability to type literals. > > You could get the same code interface on 32- and 64-bit machine by > defining > > TYPE FileOffset = ARRAY[0..1] OF [-16_80000000 .. +16_7fffffff ] > > and using that. > > > Mika -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.async.caltech.edu Sun Apr 18 09:49:27 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Sun, 18 Apr 2010 00:49:27 -0700 Subject: [M3devel] INTEGER In-Reply-To: References: , , , <7C7408D0-9A40-4988-BADA-A9FD8C15D388@cs.purdue.edu>, , , , , , , <20100418023535.3BA9E1A2103@async.async.caltech.edu>, , <20100418024703.6965B1A2103@async.async.caltech.edu> Message-ID: <20100418074927.934461A2117@async.async.caltech.edu> Jay I know most of this, and it doesn't really answer the question "what is it for?" I think we've already established that LONGINT isn't useful for counting anything that might actually reside in the computer's memory: it makes no sense as an array index, for instance. INTEGER suffices for that. I thought that the only real reason for LONGINT was to match C's declaration of various seek-related routines on 32-bit machines. That's not a very good reason. C++ succeeds because it does very well in the area(s) it is good at. People who want to program in C++ will clearly program in C++, not Modula-3. Modula-3 is never, ever going to be the language of choice for people who want lots of snazzy infix operators. Modula-3 is supposed to be a language with about as powerful semantics as C++ and an extremely simple syntax and definition---snazzy infix is one of the things you give up for that. I don't see how LONGINT fits into this picture. Now we have LONGCARD too? And it's infected the definitions of FIRST and LAST? But not NUMBER... argh! so, NUMBER(a) and LAST(a) - FIRST(a) + 1 no longer mean the same thing? Are we going to see lots of comments in generics in the future where it says T may not be an open array type nor an array type indexed on LONGINT or a subrange thereof? Your comments about different parameter-passing techniques was what I was trying to address with my suggestion to have a pragma for this---just to match C (and Fortran?), of course. Name me a single Modula-3 programmer who cares in what order the bits in his parameters are pushed on the stack in a Modula-3-to-Modula-3 call. And I am definitely in that school of thought that says that programming languages should not "evolve". Better to leave well enough alone. How much Modula-3 code has been written that uses LONGINT? Other than to talk to C? I've certainly never used it. Mika Jay K writes: >--_264cb69b-0215-44c3-807c-8b4d8ea0ea59_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >TYPE LONGINT =3D ARRAY [0..1] OF INTEGER on a 32bit system is very close to= > LONGINT. > > Plus treating it opaquely and providing a bunch of functions to operate on= > it. > > Just as well therefore could be RECORD hi=2Clo:LONGINT END (see LARGE_INTE= >GER and ULARGE_INTEGER in winnt.h) > >=20 > >Differences that come to mind: > > infix operators <=3D=3D=3D=20 > > possibly passed differently as a parameter > > or returned differently as a result > > ie. probably "directly compatible with" "long long"=2C passed by value (o= >f course you could always pass by pointer and achieve compatibilitity trivi= >ally) > >=20 > >=20 > >I have to say though=2C the biggest reason is in-fix operators. Convenient = >syntax. > >C++ is the best and some way worst of example of the general right way to d= >o this -- you let programmers define types and their infix operators. Other= > languages just come with a passle of special cases of types that have in-f= >ix operators. > >A good example is that Java infix operator + on string=2C besides the vario= >us integers=2C and nothing else. > >=20 > >=20 > >I think C# lets you define operators=2C yet people don't complain that it i= >s "a mess" as they do of C++. > >I think Python does now too. > >So it is feature growing in popularity among "mainstream" languages=2C not = >just C++. > > C++ of course is extremely mainstream=2C but also a favorite target. (ht= >tp://www.relisoft.com/tools/CppCritic.html) > >=20 > >=20 > >We also have subranges of LONGINT. > >I'm not sure what the generalization of subranges are=2C granted. > > Maybe some sort of C++ template that takes constants in the template and d= >oes range checks at runtime. Yeah=2C maybe. > >=20 > >=20 > >And as you point out=2C convenient literal syntax. > >=20 > >=20 > >People reasonably argue for library extension in place of language extensio= >n=2C but that requires a language which is flexible enough to write librari= >es with the desired interface=2C and so many languages don't let infix oper= >ators be in a user-written library. > >(There is a subtle but useless distinction here -- infix operators being in= > libraries vs. "user-written" libraries. The infix set operations for examp= >le are in a library=2C but not user-written=2C special=2C the compiler know= >s about it.) > >=20 > >> that would perhaps not match how C handles "long long" on the same >> platform (which is how=2C come to think of it?)=2C and that would require > > >=20 > >On NT/x86=2C __int64/long long is returned in the register pair edx:eax. > >edx is high=2C eax is low. > >When passed as a parameter to __stdcall or __cdecl is just passed as two 32= >bit values adjacent on the stack=2C "hi=2C lo=2C hi=2C lo=2C it's off to pu= >sh we go" is the Snow White-influenced mantra to remember how to pass them= >=2C at least on little endian stack-growing-down machines (which includes x= >86). For __fastcall I'm not sure they are passed in registers or on the sta= >ck. > >Passing and/or returning small structs also has special efficient handling = >in the ABI=2C so __int64 really might be equivalent to a small record. Not = >that cm3 necessarily implements that "correctly" -- for interop with C=3B = >for Modula-3 calling Modula-3 we can make up our own ABI so there isn't rea= >lly an "incorrect" way. Notice the mingw problem I had passing a Win32 poin= >t struct by value=2C I cheated and passed it by VAR to a C wrapper to worka= >round the gcc backend bug (which was mentioned a few times and which I look= >ed into the code for=2C but took the easy route) > >=20 > >=20 > >I don't know how long long works on other platforms but probably similar. > >Probably a certain register pair for return values. > >=20 > > - Jay > >=20 >> To: hosking at cs.purdue.edu >> Date: Sat=2C 17 Apr 2010 19:47:03 -0700 >> From: mika at async.async.caltech.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] INTEGER >>=20 >> Tony Hosking writes: >> > >> ... >> > >> >> We need it to match 64-bit integers on 32-bit machines? That seems =3D >> >like >> >> a very weak rationale indeed=2C if the same functionality could be =3D >> >provided >> >> through some other mechanism (e.g.=2C ARRAY [0..1] OF INTEGER---even = >=3D >> >with >> >> a pragma e.g. <*CLONGLONG*>.. if it is necessary to tell the compiler = >=3D >> >that >> >> a special linkage convention is needed). >> > >> >There's no special linkage convention. Not sure what you mean here. >> > >>=20 >> I just mean if we had >>=20 >> TYPE LONGINT =3D ARRAY [0..1] OF INTEGER >>=20 >> that would perhaps not match how C handles "long long" on the same >> platform (which is how=2C come to think of it?)=2C and that would require >> special linkage tricks. >>=20 >> But what would be lost? The ability to type literals.=20 >>=20 >> You could get the same code interface on 32- and 64-bit machine by >> defining >>=20 >> TYPE FileOffset =3D ARRAY[0..1] OF [-16_80000000 .. +16_7fffffff ] >>=20 >> and using that. >>=20 >>=20 >> Mika > = > >--_264cb69b-0215-44c3-807c-8b4d8ea0ea59_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > > >TYPE LONGINT =3D ARRAY [0..1] OF INTEGER on a =3B32bit system is very c= >lose to LONGINT.
> =3BPlus treating it opaquely and providing a bunch of functions to ope= >rate on it.
> =3BJust as well therefore could be RECORD hi=2Clo:LONGINT END (see LAR= >GE_INTEGER and ULARGE_INTEGER in winnt.h)
> =3B
>Differences that come to mind:
> =3B =3Binfix operators =3B <=3B=3D=3D=3D
> =3B possibly passed differently =3Bas a parameter
> =3B or returned differently as a result
> =3B ie. probably "directly compatible with" "long long"=2C passed by v= >alue (of course you could always pass by pointer and achieve compatibilitit= >y trivially)
> =3B
> =3B
>I have to say though=2C the biggest reason is in-fix operators. Convenient = >syntax.
>C++ is the best and some way worst of example of the general right way to d= >o this -- you let programmers define types and their infix operators. Other= > languages just come with a passle of special cases of types that have in-f= >ix operators.
>A good example is that Java infix operator + on string=2C besides the vario= >us integers=2C and nothing else.
> =3B
> =3B
>I think C# lets you define operators=2C yet people don't complain that it i= >s "a mess" as they do of C++.
>I think Python does now too.
>So it is feature growing in popularity among "mainstream" languages=2C not = >just C++.
> =3B =3B C++ of course is extremely mainstream=2C but also a favori= >te target. (http:/= >/www.relisoft.com/tools/CppCritic.html)
> =3B
> =3B
>We also have subranges of LONGINT.
>I'm not sure what the generalization of subranges are=2C granted.
> =3BMaybe some sort of C++ template that takes constants in the templat= >e and does range checks at runtime. Yeah=2C maybe.
> =3B
> =3B
>And as you point out=2C convenient literal syntax.
> =3B
> =3B
>People reasonably argue for library extension in place of language extensio= >n=2C but that requires a language which is flexible enough to write librari= >es with the desired interface=2C and so many languages don't let infix oper= >ators be in a user-written library.
>(There is a subtle but useless distinction here -- infix operators being in= > libraries vs. "user-written" libraries. The infix set operations for examp= >le are in a library=2C but not user-written=2C special=2C the compiler know= >s about it.)
> =3B
>>=3B that would perhaps not match how C handles "long long" on the sameR>>=3B platform (which is how=2C come to think of it?)=2C and that would = >require

> =3B
>On NT/x86=2C __int64/long long is returned in the register pair edx:eax.> >edx is high=2C eax is low.
>When passed as a parameter to __stdcall or __cdecl is just passed as two 32= >bit values adjacent on the stack=2C "hi=2C lo=2C hi=2C lo=2C it's off to pu= >sh we go" is the Snow White-influenced mantra to remember how to pass them= >=2C at least on little endian stack-growing-down machines (which includes x= >86). For __fastcall I'm not sure they are passed in registers or on the sta= >ck.
>Passing and/or returning small structs also has special efficient handling = >in the ABI=2C so __int64 really might be equivalent to a small record. Not = >that cm3 necessarily implements that "correctly" =3B -- for interop wit= >h C=3B for Modula-3 calling Modula-3 we can make up our own ABI so there is= >n't =3Breally an "incorrect" way. =3BNotice the mingw problem I had= > passing a Win32 point struct by value=2C I cheated and passed it by VAR to= > a =3BC wrapper to workaround the gcc backend bug (which was mentioned = >a few times and which I looked into the code for=2C but took the easy route= >)
> =3B
> =3B
>I don't know how long long works on other platforms but probably similar.R> >Probably a certain register pair for return values.
> =3B
> =3B- Jay

 =3B
>=3B To: hosking at cs.purdue.edu
>=3B= > Date: Sat=2C 17 Apr 2010 19:47:03 -0700
>=3B From: mika at async.async.c= >altech.edu
>=3B CC: m3devel at elegosoft.com
>=3B Subject: Re: [M3de= >vel] INTEGER
>=3B
>=3B Tony Hosking writes:
>=3B >=3B
= >>=3B ...
>=3B >=3B
>=3B >=3B>=3B We need it to match 64-b= >it integers on 32-bit machines? That seems =3D
>=3B >=3Blike
>= >=3B >=3B>=3B a very weak rationale indeed=2C if the same functionality = >could be =3D
>=3B >=3Bprovided
>=3B >=3B>=3B through some o= >ther mechanism (e.g.=2C ARRAY [0..1] OF INTEGER---even =3D
>=3B >=3B= >with
>=3B >=3B>=3B a pragma e.g. <=3B*CLONGLONG*>=3B.. if it i= >s necessary to tell the compiler =3D
>=3B >=3Bthat
>=3B >=3B&= >gt=3B a special linkage convention is needed).
>=3B >=3B
>=3B &= >gt=3BThere's no special linkage convention. Not sure what you mean here.>>=3B >=3B
>=3B
>=3B I just mean if we had
>=3B
>= >=3B TYPE LONGINT =3D ARRAY [0..1] OF INTEGER
>=3B
>=3B that woul= >d perhaps not match how C handles "long long" on the same
>=3B platfor= >m (which is how=2C come to think of it?)=2C and that would require
>= >=3B special linkage tricks.
>=3B
>=3B But what would be lost? Th= >e ability to type literals.
>=3B
>=3B You could get the same co= >de interface on 32- and 64-bit machine by
>=3B defining
>=3B
= >>=3B TYPE FileOffset =3D ARRAY[0..1] OF [-16_80000000 .. +16_7fffffff ]R>>=3B
>=3B and using that.
>=3B
>=3B
>=3B Mika> >= > >--_264cb69b-0215-44c3-807c-8b4d8ea0ea59_-- From jay.krell at cornell.edu Sun Apr 18 11:23:24 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 18 Apr 2010 09:23:24 +0000 Subject: [M3devel] INTEGER In-Reply-To: <20100418074927.934461A2117@async.async.caltech.edu> References: , , ,,<7C7408D0-9A40-4988-BADA-A9FD8C15D388@cs.purdue.edu>, ,,, , , , , , , , , <20100418023535.3BA9E1A2103@async.async.caltech.edu>, , , , <20100418024703.6965B1A2103@async.async.caltech.edu>, , <20100418074927.934461A2117@async.async.caltech.edu> Message-ID: Mika, I'm not sure what the answer is. You might recall that Tony questioned the need for LONGINT, because it is "only" there to interface with C, and I've rewritten all the C interfacing, providing perhaps other means to solve that problem...I'm not sure what means Tony had in mind, but perhaps an array or record as you/I show. Others spoke up about the need to work with files larger than 2GB. Which isn't necessarily enabled by providing LONGINT, but it is a small convenient step ("convenient" to who? Not the compiler developer. :) ) A very small amount of code has been "fixed" to pass along large file sizes with complete fidelity. The Rd/Wr interface continues to not work, or work well or easily, with streams beyond 2GB in size. I still that that should be dealt with. And I still suspect a 64bit size is near enough to infinity (for I/O purposes), that the interfaces don't need a significant redesign, merely a widening of INTEGER to LONGINT. Pass the problem up yet one more level. Granted, I vaguely recall that most/many/all rd/wr users require their data to fit into memory, so they'll fail with >2GB file sizes. Recall that merely browsing to a directory with a large file with the normal Trestle GUI would hit a subrange fault and generally terminate the running program -- no need to try to open the file. That bug at least should now be fixed by LONGINT. Granted, it probably could have been fixed e.g. by lying and giving such files a size of LAST(INTEGER). ? "Obviously" 64 is just one special spot on a range of integer sizes. Realize however that a number of 64bit integer operations really can be very efficiently implemented on most 32bit processors. Though not all operations -- add, subtract, compare are reasonable, multiply, divide less so. However arbitrary precision arithmetic, not just double precision, can be done about as efficiently -- the critical piece is "exposing the carry flag efficiently", if it exists, and we don't actually do that. Another opinion is that 64bit platforms already work..and perhaps 32bit platforms won't be around much longer anyway. This feature is 10-20 years too late and its impact therefore won't be significant. ? (http://yarchive.net/comp/longlong.html dates "long long" to circa 18 years ago.) Again, I don't have an anwer. - Jay > To: jay.krell at cornell.edu > Date: Sun, 18 Apr 2010 00:49:27 -0700 > From: mika at async.async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] INTEGER > > > Jay I know most of this, and it doesn't really answer the question > "what is it for?" > > I think we've already established that LONGINT isn't useful for counting > anything that might actually reside in the computer's memory: it makes > no sense as an array index, for instance. INTEGER suffices for that. > > I thought that the only real reason for LONGINT was to match C's > declaration of various seek-related routines on 32-bit machines. > That's not a very good reason. > > C++ succeeds because it does very well in the area(s) it is good at. > People who want to program in C++ will clearly program in C++, not > Modula-3. Modula-3 is never, ever going to be the language of choice for > people who want lots of snazzy infix operators. Modula-3 is supposed to > be a language with about as powerful semantics as C++ and an extremely > simple syntax and definition---snazzy infix is one of the things you > give up for that. I don't see how LONGINT fits into this picture. > Now we have LONGCARD too? And it's infected the definitions > of FIRST and LAST? But not NUMBER... argh! > > so, > > NUMBER(a) and LAST(a) - FIRST(a) + 1 > > no longer mean the same thing? Are we going to see lots of comments > in generics in the future where it says T may not be an open array > type nor an array type indexed on LONGINT or a subrange thereof? > > Your comments about different parameter-passing techniques was what I was > trying to address with my suggestion to have a pragma for this---just to > match C (and Fortran?), of course. Name me a single Modula-3 programmer > who cares in what order the bits in his parameters are pushed on the > stack in a Modula-3-to-Modula-3 call. > > And I am definitely in that school of thought that says that programming > languages should not "evolve". Better to leave well enough alone. > > How much Modula-3 code has been written that uses LONGINT? Other than > to talk to C? I've certainly never used it. > > Mika > > > > Jay K writes: > >--_264cb69b-0215-44c3-807c-8b4d8ea0ea59_ > >Content-Type: text/plain; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > >TYPE LONGINT =3D ARRAY [0..1] OF INTEGER on a 32bit system is very close to= > > LONGINT. > > > > Plus treating it opaquely and providing a bunch of functions to operate on= > > it. > > > > Just as well therefore could be RECORD hi=2Clo:LONGINT END (see LARGE_INTE= > >GER and ULARGE_INTEGER in winnt.h) > > > >=20 > > > >Differences that come to mind: > > > > infix operators <=3D=3D=3D=20 > > > > possibly passed differently as a parameter > > > > or returned differently as a result > > > > ie. probably "directly compatible with" "long long"=2C passed by value (o= > >f course you could always pass by pointer and achieve compatibilitity trivi= > >ally) > > > >=20 > > > >=20 > > > >I have to say though=2C the biggest reason is in-fix operators. Convenient = > >syntax. > > > >C++ is the best and some way worst of example of the general right way to d= > >o this -- you let programmers define types and their infix operators. Other= > > languages just come with a passle of special cases of types that have in-f= > >ix operators. > > > >A good example is that Java infix operator + on string=2C besides the vario= > >us integers=2C and nothing else. > > > >=20 > > > >=20 > > > >I think C# lets you define operators=2C yet people don't complain that it i= > >s "a mess" as they do of C++. > > > >I think Python does now too. > > > >So it is feature growing in popularity among "mainstream" languages=2C not = > >just C++. > > > > C++ of course is extremely mainstream=2C but also a favorite target. (ht= > >tp://www.relisoft.com/tools/CppCritic.html) > > > >=20 > > > >=20 > > > >We also have subranges of LONGINT. > > > >I'm not sure what the generalization of subranges are=2C granted. > > > > Maybe some sort of C++ template that takes constants in the template and d= > >oes range checks at runtime. Yeah=2C maybe. > > > >=20 > > > >=20 > > > >And as you point out=2C convenient literal syntax. > > > >=20 > > > >=20 > > > >People reasonably argue for library extension in place of language extensio= > >n=2C but that requires a language which is flexible enough to write librari= > >es with the desired interface=2C and so many languages don't let infix oper= > >ators be in a user-written library. > > > >(There is a subtle but useless distinction here -- infix operators being in= > > libraries vs. "user-written" libraries. The infix set operations for examp= > >le are in a library=2C but not user-written=2C special=2C the compiler know= > >s about it.) > > > >=20 > > > >> that would perhaps not match how C handles "long long" on the same > >> platform (which is how=2C come to think of it?)=2C and that would require > > > > > >=20 > > > >On NT/x86=2C __int64/long long is returned in the register pair edx:eax. > > > >edx is high=2C eax is low. > > > >When passed as a parameter to __stdcall or __cdecl is just passed as two 32= > >bit values adjacent on the stack=2C "hi=2C lo=2C hi=2C lo=2C it's off to pu= > >sh we go" is the Snow White-influenced mantra to remember how to pass them= > >=2C at least on little endian stack-growing-down machines (which includes x= > >86). For __fastcall I'm not sure they are passed in registers or on the sta= > >ck. > > > >Passing and/or returning small structs also has special efficient handling = > >in the ABI=2C so __int64 really might be equivalent to a small record. Not = > >that cm3 necessarily implements that "correctly" -- for interop with C=3B = > >for Modula-3 calling Modula-3 we can make up our own ABI so there isn't rea= > >lly an "incorrect" way. Notice the mingw problem I had passing a Win32 poin= > >t struct by value=2C I cheated and passed it by VAR to a C wrapper to worka= > >round the gcc backend bug (which was mentioned a few times and which I look= > >ed into the code for=2C but took the easy route) > > > >=20 > > > >=20 > > > >I don't know how long long works on other platforms but probably similar. > > > >Probably a certain register pair for return values. > > > >=20 > > > > - Jay > > > >=20 > >> To: hosking at cs.purdue.edu > >> Date: Sat=2C 17 Apr 2010 19:47:03 -0700 > >> From: mika at async.async.caltech.edu > >> CC: m3devel at elegosoft.com > >> Subject: Re: [M3devel] INTEGER > >>=20 > >> Tony Hosking writes: > >> > > >> ... > >> > > >> >> We need it to match 64-bit integers on 32-bit machines? That seems =3D > >> >like > >> >> a very weak rationale indeed=2C if the same functionality could be =3D > >> >provided > >> >> through some other mechanism (e.g.=2C ARRAY [0..1] OF INTEGER---even = > >=3D > >> >with > >> >> a pragma e.g. <*CLONGLONG*>.. if it is necessary to tell the compiler = > >=3D > >> >that > >> >> a special linkage convention is needed). > >> > > >> >There's no special linkage convention. Not sure what you mean here. > >> > > >>=20 > >> I just mean if we had > >>=20 > >> TYPE LONGINT =3D ARRAY [0..1] OF INTEGER > >>=20 > >> that would perhaps not match how C handles "long long" on the same > >> platform (which is how=2C come to think of it?)=2C and that would require > >> special linkage tricks. > >>=20 > >> But what would be lost? The ability to type literals.=20 > >>=20 > >> You could get the same code interface on 32- and 64-bit machine by > >> defining > >>=20 > >> TYPE FileOffset =3D ARRAY[0..1] OF [-16_80000000 .. +16_7fffffff ] > >>=20 > >> and using that. > >>=20 > >>=20 > >> Mika > > = > > > >--_264cb69b-0215-44c3-807c-8b4d8ea0ea59_ > >Content-Type: text/html; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > > > > > > > > > >TYPE LONGINT =3D ARRAY [0..1] OF INTEGER on a =3B32bit system is very c= > >lose to LONGINT.
> > =3BPlus treating it opaquely and providing a bunch of functions to ope= > >rate on it.
> > =3BJust as well therefore could be RECORD hi=2Clo:LONGINT END (see LAR= > >GE_INTEGER and ULARGE_INTEGER in winnt.h)
> > =3B
> >Differences that come to mind:
> > =3B =3Binfix operators =3B <=3B=3D=3D=3D
> > =3B possibly passed differently =3Bas a parameter
> > =3B or returned differently as a result
> > =3B ie. probably "directly compatible with" "long long"=2C passed by v= > >alue (of course you could always pass by pointer and achieve compatibilitit= > >y trivially)
> > =3B
> > =3B
> >I have to say though=2C the biggest reason is in-fix operators. Convenient = > >syntax.
> >C++ is the best and some way worst of example of the general right way to d= > >o this -- you let programmers define types and their infix operators. Other= > > languages just come with a passle of special cases of types that have in-f= > >ix operators.
> >A good example is that Java infix operator + on string=2C besides the vario= > >us integers=2C and nothing else.
> > =3B
> > =3B
> >I think C# lets you define operators=2C yet people don't complain that it i= > >s "a mess" as they do of C++.
> >I think Python does now too.
> >So it is feature growing in popularity among "mainstream" languages=2C not = > >just C++.
> > =3B =3B C++ of course is extremely mainstream=2C but also a favori= > >te target. (http:/= > >/www.relisoft.com/tools/CppCritic.html)
> > =3B
> > =3B
> >We also have subranges of LONGINT.
> >I'm not sure what the generalization of subranges are=2C granted.
> > =3BMaybe some sort of C++ template that takes constants in the templat= > >e and does range checks at runtime. Yeah=2C maybe.
> > =3B
> > =3B
> >And as you point out=2C convenient literal syntax.
> > =3B
> > =3B
> >People reasonably argue for library extension in place of language extensio= > >n=2C but that requires a language which is flexible enough to write librari= > >es with the desired interface=2C and so many languages don't let infix oper= > >ators be in a user-written library.
> >(There is a subtle but useless distinction here -- infix operators being in= > > libraries vs. "user-written" libraries. The infix set operations for examp= > >le are in a library=2C but not user-written=2C special=2C the compiler know= > >s about it.)
> > =3B
> >>=3B that would perhaps not match how C handles "long long" on the same >R>>=3B platform (which is how=2C come to think of it?)=2C and that would = > >require

> > =3B
> >On NT/x86=2C __int64/long long is returned in the register pair edx:eax. >> > >edx is high=2C eax is low.
> >When passed as a parameter to __stdcall or __cdecl is just passed as two 32= > >bit values adjacent on the stack=2C "hi=2C lo=2C hi=2C lo=2C it's off to pu= > >sh we go" is the Snow White-influenced mantra to remember how to pass them= > >=2C at least on little endian stack-growing-down machines (which includes x= > >86). For __fastcall I'm not sure they are passed in registers or on the sta= > >ck.
> >Passing and/or returning small structs also has special efficient handling = > >in the ABI=2C so __int64 really might be equivalent to a small record. Not = > >that cm3 necessarily implements that "correctly" =3B -- for interop wit= > >h C=3B for Modula-3 calling Modula-3 we can make up our own ABI so there is= > >n't =3Breally an "incorrect" way. =3BNotice the mingw problem I had= > > passing a Win32 point struct by value=2C I cheated and passed it by VAR to= > > a =3BC wrapper to workaround the gcc backend bug (which was mentioned = > >a few times and which I looked into the code for=2C but took the easy route= > >)
> > =3B
> > =3B
> >I don't know how long long works on other platforms but probably similar. >R> > >Probably a certain register pair for return values.
> > =3B
> > =3B- Jay

 =3B
>=3B To: hosking at cs.purdue.edu
>=3B= > > Date: Sat=2C 17 Apr 2010 19:47:03 -0700
>=3B From: mika at async.async.c= > >altech.edu
>=3B CC: m3devel at elegosoft.com
>=3B Subject: Re: [M3de= > >vel] INTEGER
>=3B
>=3B Tony Hosking writes:
>=3B >=3B
= > >>=3B ...
>=3B >=3B
>=3B >=3B>=3B We need it to match 64-b= > >it integers on 32-bit machines? That seems =3D
>=3B >=3Blike
>= > >=3B >=3B>=3B a very weak rationale indeed=2C if the same functionality = > >could be =3D
>=3B >=3Bprovided
>=3B >=3B>=3B through some o= > >ther mechanism (e.g.=2C ARRAY [0..1] OF INTEGER---even =3D
>=3B >=3B= > >with
>=3B >=3B>=3B a pragma e.g. <=3B*CLONGLONG*>=3B.. if it i= > >s necessary to tell the compiler =3D
>=3B >=3Bthat
>=3B >=3B&= > >gt=3B a special linkage convention is needed).
>=3B >=3B
>=3B &= > >gt=3BThere's no special linkage convention. Not sure what you mean here. >>>=3B >=3B
>=3B
>=3B I just mean if we had
>=3B
>= > >=3B TYPE LONGINT =3D ARRAY [0..1] OF INTEGER
>=3B
>=3B that woul= > >d perhaps not match how C handles "long long" on the same
>=3B platfor= > >m (which is how=2C come to think of it?)=2C and that would require
>= > >=3B special linkage tricks.
>=3B
>=3B But what would be lost? Th= > >e ability to type literals.
>=3B
>=3B You could get the same co= > >de interface on 32- and 64-bit machine by
>=3B defining
>=3B
= > >>=3B TYPE FileOffset =3D ARRAY[0..1] OF [-16_80000000 .. +16_7fffffff ] >R>>=3B
>=3B and using that.
>=3B
>=3B
>=3B Mika >> > >= > > > >--_264cb69b-0215-44c3-807c-8b4d8ea0ea59_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Apr 18 15:57:23 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 18 Apr 2010 13:57:23 +0000 Subject: [M3devel] Posix < 0 vs. # 0 vs. = -1? Message-ID: Posix often says: function foo() returns 0 for success, -1 for error m3core/libm3/etc, often say if foo() < 0 or if foo() # 0 "instead". Generally ok to tighten these up to "= -1", perhaps upon checking manpages, or a known rat's nest of inconsistencies? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Apr 18 16:10:50 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 18 Apr 2010 14:10:50 +0000 Subject: [M3devel] giant lock in SocketWin32.m3? In-Reply-To: <20100418140821.428882474008@birch.elegosoft.com> References: <20100418140821.428882474008@birch.elegosoft.com> Message-ID: Anyone know why SocketWin32.m3 has had a giant lock around everything? I see no point to it. The only global variable is related to on-demand initialization. And even that wasn't handled correctly.. - Jay > Date: Sun, 18 Apr 2010 16:08:20 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/04/18 16:08:20 > > Modified files: > cm3/m3-libs/libm3/src/os/WIN32/: SocketWin32.m3 > > Log message: > fix race condition and eliminate giant lock > I'm guessing the original authors didn't realize WSAGetLastError returns a thread local. ? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Apr 18 21:07:28 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 18 Apr 2010 15:07:28 -0400 Subject: [M3devel] INTEGER In-Reply-To: <20100418074927.934461A2117@async.async.caltech.edu> References: , , , <7C7408D0-9A40-4988-BADA-A9FD8C15D388@cs.purdue.edu>, , , , , , , <20100418023535.3BA9E1A2103@async.async.caltech.edu>, , <20100418024703.6965B1A2103@async.async.caltech.edu> <20100418074927.934461A2117@async.async.caltech.edu> Message-ID: <04EB7FF8-D304-428D-839E-233FCE009C98@cs.purdue.edu> In the language spec NUMBER(a) and LAST(a) - FIRST(a) + 1 are *not* defined to mean the same thing for all types. NUMBER does have an INTEGER value, as expected for subranges of LONGINT that are not too large. This is as it has always been for subranges of INTEGER that are not too large. Mika, I'm not sure I see any of the problems you are worrying about in the current definition of LONGINT/LONGCARD. On 18 Apr 2010, at 03:49, Mika Nystrom wrote: > > Jay I know most of this, and it doesn't really answer the question > "what is it for?" > > I think we've already established that LONGINT isn't useful for counting > anything that might actually reside in the computer's memory: it makes > no sense as an array index, for instance. INTEGER suffices for that. > > I thought that the only real reason for LONGINT was to match C's > declaration of various seek-related routines on 32-bit machines. > That's not a very good reason. > > C++ succeeds because it does very well in the area(s) it is good at. > People who want to program in C++ will clearly program in C++, not > Modula-3. Modula-3 is never, ever going to be the language of choice for > people who want lots of snazzy infix operators. Modula-3 is supposed to > be a language with about as powerful semantics as C++ and an extremely > simple syntax and definition---snazzy infix is one of the things you > give up for that. I don't see how LONGINT fits into this picture. > Now we have LONGCARD too? And it's infected the definitions > of FIRST and LAST? But not NUMBER... argh! > > so, > > NUMBER(a) and LAST(a) - FIRST(a) + 1 > > no longer mean the same thing? Are we going to see lots of comments > in generics in the future where it says T may not be an open array > type nor an array type indexed on LONGINT or a subrange thereof? > > Your comments about different parameter-passing techniques was what I was > trying to address with my suggestion to have a pragma for this---just to > match C (and Fortran?), of course. Name me a single Modula-3 programmer > who cares in what order the bits in his parameters are pushed on the > stack in a Modula-3-to-Modula-3 call. > > And I am definitely in that school of thought that says that programming > languages should not "evolve". Better to leave well enough alone. > > How much Modula-3 code has been written that uses LONGINT? Other than > to talk to C? I've certainly never used it. > > Mika > > > > Jay K writes: >> --_264cb69b-0215-44c3-807c-8b4d8ea0ea59_ >> Content-Type: text/plain; charset="iso-8859-1" >> Content-Transfer-Encoding: quoted-printable >> >> >> TYPE LONGINT =3D ARRAY [0..1] OF INTEGER on a 32bit system is very close to= >> LONGINT. >> >> Plus treating it opaquely and providing a bunch of functions to operate on= >> it. >> >> Just as well therefore could be RECORD hi=2Clo:LONGINT END (see LARGE_INTE= >> GER and ULARGE_INTEGER in winnt.h) >> >> =20 >> >> Differences that come to mind: >> >> infix operators <=3D=3D=3D=20 >> >> possibly passed differently as a parameter >> >> or returned differently as a result >> >> ie. probably "directly compatible with" "long long"=2C passed by value (o= >> f course you could always pass by pointer and achieve compatibilitity trivi= >> ally) >> >> =20 >> >> =20 >> >> I have to say though=2C the biggest reason is in-fix operators. Convenient = >> syntax. >> >> C++ is the best and some way worst of example of the general right way to d= >> o this -- you let programmers define types and their infix operators. Other= >> languages just come with a passle of special cases of types that have in-f= >> ix operators. >> >> A good example is that Java infix operator + on string=2C besides the vario= >> us integers=2C and nothing else. >> >> =20 >> >> =20 >> >> I think C# lets you define operators=2C yet people don't complain that it i= >> s "a mess" as they do of C++. >> >> I think Python does now too. >> >> So it is feature growing in popularity among "mainstream" languages=2C not = >> just C++. >> >> C++ of course is extremely mainstream=2C but also a favorite target. (ht= >> tp://www.relisoft.com/tools/CppCritic.html) >> >> =20 >> >> =20 >> >> We also have subranges of LONGINT. >> >> I'm not sure what the generalization of subranges are=2C granted. >> >> Maybe some sort of C++ template that takes constants in the template and d= >> oes range checks at runtime. Yeah=2C maybe. >> >> =20 >> >> =20 >> >> And as you point out=2C convenient literal syntax. >> >> =20 >> >> =20 >> >> People reasonably argue for library extension in place of language extensio= >> n=2C but that requires a language which is flexible enough to write librari= >> es with the desired interface=2C and so many languages don't let infix oper= >> ators be in a user-written library. >> >> (There is a subtle but useless distinction here -- infix operators being in= >> libraries vs. "user-written" libraries. The infix set operations for examp= >> le are in a library=2C but not user-written=2C special=2C the compiler know= >> s about it.) >> >> =20 >> >>> that would perhaps not match how C handles "long long" on the same >>> platform (which is how=2C come to think of it?)=2C and that would require >> >> >> =20 >> >> On NT/x86=2C __int64/long long is returned in the register pair edx:eax. >> >> edx is high=2C eax is low. >> >> When passed as a parameter to __stdcall or __cdecl is just passed as two 32= >> bit values adjacent on the stack=2C "hi=2C lo=2C hi=2C lo=2C it's off to pu= >> sh we go" is the Snow White-influenced mantra to remember how to pass them= >> =2C at least on little endian stack-growing-down machines (which includes x= >> 86). For __fastcall I'm not sure they are passed in registers or on the sta= >> ck. >> >> Passing and/or returning small structs also has special efficient handling = >> in the ABI=2C so __int64 really might be equivalent to a small record. Not = >> that cm3 necessarily implements that "correctly" -- for interop with C=3B = >> for Modula-3 calling Modula-3 we can make up our own ABI so there isn't rea= >> lly an "incorrect" way. Notice the mingw problem I had passing a Win32 poin= >> t struct by value=2C I cheated and passed it by VAR to a C wrapper to worka= >> round the gcc backend bug (which was mentioned a few times and which I look= >> ed into the code for=2C but took the easy route) >> >> =20 >> >> =20 >> >> I don't know how long long works on other platforms but probably similar. >> >> Probably a certain register pair for return values. >> >> =20 >> >> - Jay >> >> =20 >>> To: hosking at cs.purdue.edu >>> Date: Sat=2C 17 Apr 2010 19:47:03 -0700 >>> From: mika at async.async.caltech.edu >>> CC: m3devel at elegosoft.com >>> Subject: Re: [M3devel] INTEGER >>> =20 >>> Tony Hosking writes: >>>> >>> ... >>>> >>>>> We need it to match 64-bit integers on 32-bit machines? That seems =3D >>>> like >>>>> a very weak rationale indeed=2C if the same functionality could be =3D >>>> provided >>>>> through some other mechanism (e.g.=2C ARRAY [0..1] OF INTEGER---even = >> =3D >>>> with >>>>> a pragma e.g. <*CLONGLONG*>.. if it is necessary to tell the compiler = >> =3D >>>> that >>>>> a special linkage convention is needed). >>>> >>>> There's no special linkage convention. Not sure what you mean here. >>>> >>> =20 >>> I just mean if we had >>> =20 >>> TYPE LONGINT =3D ARRAY [0..1] OF INTEGER >>> =20 >>> that would perhaps not match how C handles "long long" on the same >>> platform (which is how=2C come to think of it?)=2C and that would require >>> special linkage tricks. >>> =20 >>> But what would be lost? The ability to type literals.=20 >>> =20 >>> You could get the same code interface on 32- and 64-bit machine by >>> defining >>> =20 >>> TYPE FileOffset =3D ARRAY[0..1] OF [-16_80000000 .. +16_7fffffff ] >>> =20 >>> and using that. >>> =20 >>> =20 >>> Mika >> = >> >> --_264cb69b-0215-44c3-807c-8b4d8ea0ea59_ >> Content-Type: text/html; charset="iso-8859-1" >> Content-Transfer-Encoding: quoted-printable >> >> >> >> >> >> >> TYPE LONGINT =3D ARRAY [0..1] OF INTEGER on a =3B32bit system is very c= >> lose to LONGINT.
>>  =3BPlus treating it opaquely and providing a bunch of functions to ope= >> rate on it.
>>  =3BJust as well therefore could be RECORD hi=2Clo:LONGINT END (see LAR= >> GE_INTEGER and ULARGE_INTEGER in winnt.h)
>>  =3B
>> Differences that come to mind:
>>  =3B =3Binfix operators =3B <=3B=3D=3D=3D
>>  =3B possibly passed differently =3Bas a parameter
>>  =3B or returned differently as a result
>>  =3B ie. probably "directly compatible with" "long long"=2C passed by v= >> alue (of course you could always pass by pointer and achieve compatibilitit= >> y trivially)
>>  =3B
>>  =3B
>> I have to say though=2C the biggest reason is in-fix operators. Convenient = >> syntax.
>> C++ is the best and some way worst of example of the general right way to d= >> o this -- you let programmers define types and their infix operators. Other= >> languages just come with a passle of special cases of types that have in-f= >> ix operators.
>> A good example is that Java infix operator + on string=2C besides the vario= >> us integers=2C and nothing else.
>>  =3B
>>  =3B
>> I think C# lets you define operators=2C yet people don't complain that it i= >> s "a mess" as they do of C++.
>> I think Python does now too.
>> So it is feature growing in popularity among "mainstream" languages=2C not = >> just C++.
>>  =3B =3B C++ of course is extremely mainstream=2C but also a favori= >> te target. (http:/= >> /www.relisoft.com/tools/CppCritic.html)
>>  =3B
>>  =3B
>> We also have subranges of LONGINT.
>> I'm not sure what the generalization of subranges are=2C granted.
>>  =3BMaybe some sort of C++ template that takes constants in the templat= >> e and does range checks at runtime. Yeah=2C maybe.
>>  =3B
>>  =3B
>> And as you point out=2C convenient literal syntax.
>>  =3B
>>  =3B
>> People reasonably argue for library extension in place of language extensio= >> n=2C but that requires a language which is flexible enough to write librari= >> es with the desired interface=2C and so many languages don't let infix oper= >> ators be in a user-written library.
>> (There is a subtle but useless distinction here -- infix operators being in= >> libraries vs. "user-written" libraries. The infix set operations for examp= >> le are in a library=2C but not user-written=2C special=2C the compiler know= >> s about it.)
>>  =3B
>> >=3B that would perhaps not match how C handles "long long" on the same> R>>=3B platform (which is how=2C come to think of it?)=2C and that would = >> require

>>  =3B
>> On NT/x86=2C __int64/long long is returned in the register pair edx:eax.>> >> edx is high=2C eax is low.
>> When passed as a parameter to __stdcall or __cdecl is just passed as two 32= >> bit values adjacent on the stack=2C "hi=2C lo=2C hi=2C lo=2C it's off to pu= >> sh we go" is the Snow White-influenced mantra to remember how to pass them= >> =2C at least on little endian stack-growing-down machines (which includes x= >> 86). For __fastcall I'm not sure they are passed in registers or on the sta= >> ck.
>> Passing and/or returning small structs also has special efficient handling = >> in the ABI=2C so __int64 really might be equivalent to a small record. Not = >> that cm3 necessarily implements that "correctly" =3B -- for interop wit= >> h C=3B for Modula-3 calling Modula-3 we can make up our own ABI so there is= >> n't =3Breally an "incorrect" way. =3BNotice the mingw problem I had= >> passing a Win32 point struct by value=2C I cheated and passed it by VAR to= >> a =3BC wrapper to workaround the gcc backend bug (which was mentioned = >> a few times and which I looked into the code for=2C but took the easy route= >> )
>>  =3B
>>  =3B
>> I don't know how long long works on other platforms but probably similar.> R> >> Probably a certain register pair for return values.
>>  =3B
>>  =3B- Jay

 =3B
>=3B To: hosking at cs.purdue.edu
>=3B= >> Date: Sat=2C 17 Apr 2010 19:47:03 -0700
>=3B From: mika at async.async.c= >> altech.edu
>=3B CC: m3devel at elegosoft.com
>=3B Subject: Re: [M3de= >> vel] INTEGER
>=3B
>=3B Tony Hosking writes:
>=3B >=3B
= >> >=3B ...
>=3B >=3B
>=3B >=3B>=3B We need it to match 64-b= >> it integers on 32-bit machines? That seems =3D
>=3B >=3Blike
>= >> =3B >=3B>=3B a very weak rationale indeed=2C if the same functionality = >> could be =3D
>=3B >=3Bprovided
>=3B >=3B>=3B through some o= >> ther mechanism (e.g.=2C ARRAY [0..1] OF INTEGER---even =3D
>=3B >=3B= >> with
>=3B >=3B>=3B a pragma e.g. <=3B*CLONGLONG*>=3B.. if it i= >> s necessary to tell the compiler =3D
>=3B >=3Bthat
>=3B >=3B&= >> gt=3B a special linkage convention is needed).
>=3B >=3B
>=3B &= >> gt=3BThere's no special linkage convention. Not sure what you mean here.>> >=3B >=3B
>=3B
>=3B I just mean if we had
>=3B
>= >> =3B TYPE LONGINT =3D ARRAY [0..1] OF INTEGER
>=3B
>=3B that woul= >> d perhaps not match how C handles "long long" on the same
>=3B platfor= >> m (which is how=2C come to think of it?)=2C and that would require
>= >> =3B special linkage tricks.
>=3B
>=3B But what would be lost? Th= >> e ability to type literals.
>=3B
>=3B You could get the same co= >> de interface on 32- and 64-bit machine by
>=3B defining
>=3B
= >> >=3B TYPE FileOffset =3D ARRAY[0..1] OF [-16_80000000 .. +16_7fffffff ]> R>>=3B
>=3B and using that.
>=3B
>=3B
>=3B Mika>> >> = >> >> --_264cb69b-0215-44c3-807c-8b4d8ea0ea59_-- From hosking at cs.purdue.edu Sun Apr 18 21:09:00 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 18 Apr 2010 15:09:00 -0400 Subject: [M3devel] Posix < 0 vs. # 0 vs. = -1? In-Reply-To: References: Message-ID: Checking < 0 is much cheaper than checking = -1. C idioms typically check < 0. -1 is simply a convenient negative value to return. Leave it as is. On 18 Apr 2010, at 09:57, Jay K wrote: > Posix often says: > function foo() returns 0 for success, -1 for error > > m3core/libm3/etc, often say if foo() < 0 or if foo() # 0 "instead". > Generally ok to tighten these up to "= -1", perhaps upon checking manpages, > or a known rat's nest of inconsistencies? > > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.async.caltech.edu Sun Apr 18 21:41:59 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Sun, 18 Apr 2010 12:41:59 -0700 Subject: [M3devel] Posix < 0 vs. # 0 vs. = -1? In-Reply-To: References: Message-ID: <20100418194159.E07411A2119@async.async.caltech.edu> Jay K writes: >--_201b8a99-e8e8-4887-bb32-c65e8edd0b1a_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >Posix often says: > > function foo() returns 0 for success=2C -1 for error > >=20 > > m3core/libm3/etc=2C often say if foo() < 0 or if foo() # 0 "instead". > Generally ok to tighten these up to "=3D -1"=2C perhaps upon checking manp= >ages=2C > or a known rat's nest of inconsistencies? > Maybe this is just my personal style, but I would code it thus: <*EXTERNAL*> PROCEDURE F() : INTEGER; (* matches C declaration *) ... VAR result : [0..1] := F(); (* matches man page specification *) BEGIN CASE result OF 0 => ... | -1 => ... END END No way for any sneaky value problems to get through. The use of CASE also guards against typos. Mika From mika at async.async.caltech.edu Sun Apr 18 21:59:01 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Sun, 18 Apr 2010 12:59:01 -0700 Subject: [M3devel] INTEGER In-Reply-To: <04EB7FF8-D304-428D-839E-233FCE009C98@cs.purdue.edu> References: , , , <7C7408D0-9A40-4988-BADA-A9FD8C15D388@cs.purdue.edu>, , , , , , , <20100418023535.3BA9E1A2103@async.async.caltech.edu>, , <20100418024703.6965B1A2103@async.async.caltech.edu> <20100418074927.934461A2117@async.async.caltech.edu> <04EB7FF8-D304-428D-839E-233FCE009C98@cs.purdue.edu> Message-ID: <20100418195901.CDACB1A20F6@async.async.caltech.edu> My problem is really just that it's ugly. LONGx is showing up as an issue in all sorts of low-level code, which is not surprising since Modula-3 with LONGx is not the same language as Modula-3 (maybe we should call it Modula-3+?) The compiler bootstrapping process has gotten more complicated due to it, and when I cvs updated m3tk yesterday stubgen wouldn't compile because there was something "long" in it that wasn't there before. I have no idea what library or components I needed to update and recompile and didn't have the time to deal with the issue at the time. And the new m3tk, stubgen, and compiler(?) won't compile using PM3 or SRC M3 since we're no longer using the language of the Green Book. (Same comment goes for WIDECHAR, by the way.) One of the wonderful things about Modula-3 *used to be* that I could grab some old package from DECSRC and just use it without changes since no one had messed with the language definition. This is still true as far as programs that just use the tools go, but it's no longer true for programs that process Modula-3 code as input data. Of which there are more than a few: many aspects of Modula-3 were specifically designed to make the language easy to process by program, as an intermediate format and whatnot. To quote E.W.D.: 'Unfathomed misunderstanding is further revealed by the term "software maintenance", as a result of which many people continue to believe that programs and even programming languages themselves are subject to wear and tear. Your car needs maintenance too, doesn't it? Famous is the story of the oil company that believed that its PASCAL programs did not last as long as its FORTRAN programs "because PASCAL was not maintained".' LONGx is causing me to have to do "software maintenance" on Modula-3 programs... for a feature that no one appears to be using and is quickly becoming irrelevant. Mika Tony Hosking writes: >In the language spec NUMBER(a) and LAST(a) - FIRST(a) + 1 are *not* = >defined to mean the same thing for all types. >NUMBER does have an INTEGER value, as expected for subranges of LONGINT = >that are not too large. >This is as it has always been for subranges of INTEGER that are not too = >large. > >Mika, I'm not sure I see any of the problems you are worrying about in = >the current definition of LONGINT/LONGCARD. > >On 18 Apr 2010, at 03:49, Mika Nystrom wrote: > >>=20 >> Jay I know most of this, and it doesn't really answer the question >> "what is it for?" >>=20 >> I think we've already established that LONGINT isn't useful for = >counting >> anything that might actually reside in the computer's memory: it makes >> no sense as an array index, for instance. INTEGER suffices for that. >>=20 >> I thought that the only real reason for LONGINT was to match C's >> declaration of various seek-related routines on 32-bit machines. >> That's not a very good reason. >>=20 >> C++ succeeds because it does very well in the area(s) it is good at. >> People who want to program in C++ will clearly program in C++, not >> Modula-3. Modula-3 is never, ever going to be the language of choice = >for >> people who want lots of snazzy infix operators. Modula-3 is supposed = >to >> be a language with about as powerful semantics as C++ and an extremely >> simple syntax and definition---snazzy infix is one of the things you >> give up for that. I don't see how LONGINT fits into this picture. >> Now we have LONGCARD too? And it's infected the definitions >> of FIRST and LAST? But not NUMBER... argh! >>=20 >> so, >>=20 >> NUMBER(a) and LAST(a) - FIRST(a) + 1 >>=20 >> no longer mean the same thing? Are we going to see lots of comments >> in generics in the future where it says T may not be an open array >> type nor an array type indexed on LONGINT or a subrange thereof? >>=20 >> Your comments about different parameter-passing techniques was what I = >was >> trying to address with my suggestion to have a pragma for this---just = >to >> match C (and Fortran?), of course. Name me a single Modula-3 = >programmer >> who cares in what order the bits in his parameters are pushed on the >> stack in a Modula-3-to-Modula-3 call. >>=20 >> And I am definitely in that school of thought that says that = >programming >> languages should not "evolve". Better to leave well enough alone. >>=20 >> How much Modula-3 code has been written that uses LONGINT? Other than >> to talk to C? I've certainly never used it. >>=20 >> Mika >>=20 >>=20 >>=20 >> Jay K writes: >>> --_264cb69b-0215-44c3-807c-8b4d8ea0ea59_ >>> Content-Type: text/plain; charset=3D"iso-8859-1" >>> Content-Transfer-Encoding: quoted-printable >>>=20 >>>=20 >>> TYPE LONGINT =3D3D ARRAY [0..1] OF INTEGER on a 32bit system is very = >close to=3D >>> LONGINT. >>>=20 >>> Plus treating it opaquely and providing a bunch of functions to = >operate on=3D >>> it. >>>=20 >>> Just as well therefore could be RECORD hi=3D2Clo:LONGINT END (see = >LARGE_INTE=3D >>> GER and ULARGE_INTEGER in winnt.h) >>>=20 >>> =3D20 >>>=20 >>> Differences that come to mind: >>>=20 >>> infix operators <=3D3D=3D3D=3D3D=3D20 >>>=20 >>> possibly passed differently as a parameter >>>=20 >>> or returned differently as a result >>>=20 >>> ie. probably "directly compatible with" "long long"=3D2C passed by = >value (o=3D >>> f course you could always pass by pointer and achieve compatibilitity = >trivi=3D >>> ally) >>>=20 >>> =3D20 >>>=20 >>> =3D20 >>>=20 >>> I have to say though=3D2C the biggest reason is in-fix operators. = >Convenient =3D >>> syntax. >>>=20 >>> C++ is the best and some way worst of example of the general right = >way to d=3D >>> o this -- you let programmers define types and their infix operators. = >Other=3D >>> languages just come with a passle of special cases of types that have = >in-f=3D >>> ix operators. >>>=20 >>> A good example is that Java infix operator + on string=3D2C besides = >the vario=3D >>> us integers=3D2C and nothing else. >>>=20 >>> =3D20 >>>=20 >>> =3D20 >>>=20 >>> I think C# lets you define operators=3D2C yet people don't complain = >that it i=3D >>> s "a mess" as they do of C++. >>>=20 >>> I think Python does now too. >>>=20 >>> So it is feature growing in popularity among "mainstream" = >languages=3D2C not =3D >>> just C++. >>>=20 >>> C++ of course is extremely mainstream=3D2C but also a favorite = >target. (ht=3D >>> tp://www.relisoft.com/tools/CppCritic.html) >>>=20 >>> =3D20 >>>=20 >>> =3D20 >>>=20 >>> We also have subranges of LONGINT. >>>=20 >>> I'm not sure what the generalization of subranges are=3D2C granted. >>>=20 >>> Maybe some sort of C++ template that takes constants in the template = >and d=3D >>> oes range checks at runtime. Yeah=3D2C maybe. >>>=20 >>> =3D20 >>>=20 >>> =3D20 >>>=20 >>> And as you point out=3D2C convenient literal syntax. >>>=20 >>> =3D20 >>>=20 >>> =3D20 >>>=20 >>> People reasonably argue for library extension in place of language = >extensio=3D >>> n=3D2C but that requires a language which is flexible enough to write = >librari=3D >>> es with the desired interface=3D2C and so many languages don't let = >infix oper=3D >>> ators be in a user-written library. >>>=20 >>> (There is a subtle but useless distinction here -- infix operators = >being in=3D >>> libraries vs. "user-written" libraries. The infix set operations for = >examp=3D >>> le are in a library=3D2C but not user-written=3D2C special=3D2C the = >compiler know=3D >>> s about it.) >>>=20 >>> =3D20 >>>=20 >>>> that would perhaps not match how C handles "long long" on the same >>>> platform (which is how=3D2C come to think of it?)=3D2C and that = >would require >>>=20 >>>=20 >>> =3D20 >>>=20 >>> On NT/x86=3D2C __int64/long long is returned in the register pair = >edx:eax. >>>=20 >>> edx is high=3D2C eax is low. >>>=20 >>> When passed as a parameter to __stdcall or __cdecl is just passed as = >two 32=3D >>> bit values adjacent on the stack=3D2C "hi=3D2C lo=3D2C hi=3D2C lo=3D2C = >it's off to pu=3D >> sh we go" is the Snow White-influenced mantra to remember how to pass = >them=3D >>> =3D2C at least on little endian stack-growing-down machines (which = >includes x=3D >>> 86). For __fastcall I'm not sure they are passed in registers or on = >the sta=3D >>> ck. >>>=20 >>> Passing and/or returning small structs also has special efficient = >handling =3D >>> in the ABI=3D2C so __int64 really might be equivalent to a small = >record. Not =3D >>> that cm3 necessarily implements that "correctly" -- for interop with = >C=3D3B =3D >>> for Modula-3 calling Modula-3 we can make up our own ABI so there = >isn't rea=3D >>> lly an "incorrect" way. Notice the mingw problem I had passing a = >Win32 poin=3D >>> t struct by value=3D2C I cheated and passed it by VAR to a C wrapper = >to worka=3D >>> round the gcc backend bug (which was mentioned a few times and which = >I look=3D >>> ed into the code for=3D2C but took the easy route) >>>=20 >>> =3D20 >>>=20 >>> =3D20 >>>=20 >>> I don't know how long long works on other platforms but probably = >similar. >>>=20 >>> Probably a certain register pair for return values. >>>=20 >>> =3D20 >>>=20 >>> - Jay >>>=20 >>> =3D20 >>>> To: hosking at cs.purdue.edu >>>> Date: Sat=3D2C 17 Apr 2010 19:47:03 -0700 >>>> From: mika at async.async.caltech.edu >>>> CC: m3devel at elegosoft.com >>>> Subject: Re: [M3devel] INTEGER >>>> =3D20 >>>> Tony Hosking writes: >>>>>=20 >>>> ... >>>>>=20 >>>>>> We need it to match 64-bit integers on 32-bit machines? That seems = >=3D3D >>>>> like >>>>>> a very weak rationale indeed=3D2C if the same functionality could = >be =3D3D >>>>> provided >>>>>> through some other mechanism (e.g.=3D2C ARRAY [0..1] OF = >INTEGER---even =3D >>> =3D3D >>>>> with >>>>>> a pragma e.g. <*CLONGLONG*>.. if it is necessary to tell the = >compiler =3D >>> =3D3D >>>>> that >>>>>> a special linkage convention is needed). >>>>>=20 >>>>> There's no special linkage convention. Not sure what you mean here. >>>>>=20 >>>> =3D20 >>>> I just mean if we had >>>> =3D20 >>>> TYPE LONGINT =3D3D ARRAY [0..1] OF INTEGER >>>> =3D20 >>>> that would perhaps not match how C handles "long long" on the same >>>> platform (which is how=3D2C come to think of it?)=3D2C and that = >would require >>>> special linkage tricks. >>>> =3D20 >>>> But what would be lost? The ability to type literals.=3D20 >>>> =3D20 >>>> You could get the same code interface on 32- and 64-bit machine by >>>> defining >>>> =3D20 >>>> TYPE FileOffset =3D3D ARRAY[0..1] OF [-16_80000000 .. +16_7fffffff ] >>>> =3D20 >>>> and using that. >>>> =3D20 >>>> =3D20 >>>> Mika >>> =3D >>>=20 >>> --_264cb69b-0215-44c3-807c-8b4d8ea0ea59_ >>> Content-Type: text/html; charset=3D"iso-8859-1" >>> Content-Transfer-Encoding: quoted-printable >>>=20 >>> >>> >>> >>> >>> >>> TYPE LONGINT =3D3D ARRAY [0..1] OF INTEGER on a =3D3B32bit system = >is very c=3D >>> lose to LONGINT.
>>>  =3D3BPlus treating it opaquely and providing a bunch of = >functions to ope=3D >>> rate on it.
>>>  =3D3BJust as well therefore could be RECORD hi=3D2Clo:LONGINT = >END (see LAR=3D >>> GE_INTEGER and ULARGE_INTEGER in winnt.h)
>>>  =3D3B
>>> Differences that come to mind:
>>>  =3D3B =3D3Binfix operators =3D3B <=3D3B=3D3D=3D3D=3D3D = >
>>>  =3D3B possibly passed differently =3D3Bas a parameter
>>>  =3D3B or returned differently as a result
>>>  =3D3B ie. probably "directly compatible with" "long long"=3D2C = >passed by v=3D >>> alue (of course you could always pass by pointer and achieve = >compatibilitit=3D >>> y trivially)
>>>  =3D3B
>>>  =3D3B
>>> I have to say though=3D2C the biggest reason is in-fix operators. = >Convenient =3D >>> syntax.
>>> C++ is the best and some way worst of example of the general right = >way to d=3D >>> o this -- you let programmers define types and their infix operators. = >Other=3D >>> languages just come with a passle of special cases of types that have = >in-f=3D >>> ix operators.
>>> A good example is that Java infix operator + on string=3D2C besides = >the vario=3D >>> us integers=3D2C and nothing else.
>>>  =3D3B
>>>  =3D3B
>>> I think C# lets you define operators=3D2C yet people don't complain = >that it i=3D >>> s "a mess" as they do of C++.
>>> I think Python does now too.
>>> So it is feature growing in popularity among "mainstream" = >languages=3D2C not =3D >>> just C++.
>>>  =3D3B =3D3B C++ of course is extremely mainstream=3D2C but = >also a favori=3D >>> te target. (href=3D3D"http://www.relisoft.com/tools/CppCritic.html">http:/=3D >>> /www.relisoft.com/tools/CppCritic.html)
>>>  =3D3B
>>>  =3D3B
>>> We also have subranges of LONGINT.
>>> I'm not sure what the generalization of subranges are=3D2C = >granted.
>>>  =3D3BMaybe some sort of C++ template that takes constants in the = >templat=3D >>> e and does range checks at runtime. Yeah=3D2C maybe.
>>>  =3D3B
>>>  =3D3B
>>> And as you point out=3D2C convenient literal syntax.
>>>  =3D3B
>>>  =3D3B
>>> People reasonably argue for library extension in place of language = >extensio=3D >>> n=3D2C but that requires a language which is flexible enough to write = >librari=3D >>> es with the desired interface=3D2C and so many languages don't let = >infix oper=3D >>> ators be in a user-written library.
>>> (There is a subtle but useless distinction here -- infix operators = >being in=3D >>> libraries vs. "user-written" libraries. The infix set operations for = >examp=3D >>> le are in a library=3D2C but not user-written=3D2C special=3D2C the = >compiler know=3D >>> s about it.)
>>>  =3D3B
>>> >=3D3B that would perhaps not match how C handles "long long" on = >the same>> R>>=3D3B platform (which is how=3D2C come to think of it?)=3D2C and = >that would =3D >>> require

>>>  =3D3B
>>> On NT/x86=3D2C __int64/long long is returned in the register pair = >edx:eax.>>>=20 >>> edx is high=3D2C eax is low.
>>> When passed as a parameter to __stdcall or __cdecl is just passed as = >two 32=3D >>> bit values adjacent on the stack=3D2C "hi=3D2C lo=3D2C hi=3D2C lo=3D2C = >it's off to pu=3D >>> sh we go" is the Snow White-influenced mantra to remember how to pass = >them=3D >>> =3D2C at least on little endian stack-growing-down machines (which = >includes x=3D >>> 86). For __fastcall I'm not sure they are passed in registers or on = >the sta=3D >>> ck.
>>> Passing and/or returning small structs also has special efficient = >handling =3D >>> in the ABI=3D2C so __int64 really might be equivalent to a small = >record. Not =3D >>> that cm3 necessarily implements that "correctly" =3D3B -- for = >interop wit=3D >>> h C=3D3B for Modula-3 calling Modula-3 we can make up our own ABI so = >there is=3D >>> n't =3D3Breally an "incorrect" way. =3D3BNotice the mingw = >problem I had=3D >>> passing a Win32 point struct by value=3D2C I cheated and passed it by = >VAR to=3D >>> a =3D3BC wrapper to workaround the gcc backend bug (which was = >mentioned =3D >>> a few times and which I looked into the code for=3D2C but took the = >easy route=3D >>> )
>>>  =3D3B
>>>  =3D3B
>>> I don't know how long long works on other platforms but probably = >similar.>> R> >>> Probably a certain register pair for return values.
>>>  =3D3B
>>>  =3D3B- Jay

 =3D3B
>=3D3B To: = >hosking at cs.purdue.edu
>=3D3B=3D >>> Date: Sat=3D2C 17 Apr 2010 19:47:03 -0700
>=3D3B From: = >mika at async.async.c=3D >>> altech.edu
>=3D3B CC: m3devel at elegosoft.com
>=3D3B Subject: = >Re: [M3de=3D >>> vel] INTEGER
>=3D3B
>=3D3B Tony Hosking writes:
>=3D3B = >>=3D3B
=3D >>> >=3D3B ...
>=3D3B >=3D3B
>=3D3B >=3D3B>=3D3B We = >need it to match 64-b=3D >>> it integers on 32-bit machines? That seems =3D3D
>=3D3B = >>=3D3Blike
>=3D >>> =3D3B >=3D3B>=3D3B a very weak rationale indeed=3D2C if the same = >functionality =3D >>> could be =3D3D
>=3D3B >=3D3Bprovided
>=3D3B >=3D3B>=3D3= >B through some o=3D >>> ther mechanism (e.g.=3D2C ARRAY [0..1] OF INTEGER---even = >=3D3D
>=3D3B >=3D3B=3D >>> with
>=3D3B >=3D3B>=3D3B a pragma e.g. = ><=3D3B*CLONGLONG*>=3D3B.. if it i=3D >>> s necessary to tell the compiler =3D3D
>=3D3B = >>=3D3Bthat
>=3D3B >=3D3B&=3D >>> gt=3D3B a special linkage convention is needed).
>=3D3B = >>=3D3B
>=3D3B &=3D >>> gt=3D3BThere's no special linkage convention. Not sure what you mean = >here.>>> >=3D3B >=3D3B
>=3D3B
>=3D3B I just mean if we = >had
>=3D3B
>=3D >>> =3D3B TYPE LONGINT =3D3D ARRAY [0..1] OF INTEGER
>=3D3B = >
>=3D3B that woul=3D >>> d perhaps not match how C handles "long long" on the same
>=3D3B = >platfor=3D >>> m (which is how=3D2C come to think of it?)=3D2C and that would = >require
>=3D >>> =3D3B special linkage tricks.
>=3D3B
>=3D3B But what would = >be lost? Th=3D >>> e ability to type literals.
>=3D3B
>=3D3B You could get = >the same co=3D >>> de interface on 32- and 64-bit machine by
>=3D3B = >defining
>=3D3B
=3D >>> >=3D3B TYPE FileOffset =3D3D ARRAY[0..1] OF [-16_80000000 .. = >+16_7fffffff ]>> R>>=3D3B
>=3D3B and using that.
>=3D3B
>=3D3B = >
>=3D3B Mika>>> >>> =3D >>>=20 >>> --_264cb69b-0215-44c3-807c-8b4d8ea0ea59_-- From hosking at cs.purdue.edu Mon Apr 19 02:38:43 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 18 Apr 2010 20:38:43 -0400 Subject: [M3devel] INTEGER In-Reply-To: <20100418195901.CDACB1A20F6@async.async.caltech.edu> References: , , , <7C7408D0-9A40-4988-BADA-A9FD8C15D388@cs.purdue.edu>, , , , , , , <20100418023535.3BA9E1A2103@async.async.caltech.edu>, , <20100418024703.6965B1A2103@async.async.caltech.edu> <20100418074927.934461A2117@async.async.caltech.edu> <04EB7FF8-D304-428D-839E-233FCE009C98@cs.purdue.edu> <20100418195901.CDACB1A20F6@async.async.caltech.edu> Message-ID: Mika, First off, I'd be very interested to know what the issues are with LONGINT and stubgen. We are building that every day in regression testing. It would be really good to get some precise feedback. True, LONGINT is integrated with all of the language tools (same as WIDECHAR). I suppose that is the price we pay for the language having evolved. Nevertheless, CM3 should be totally backward compatible with the green book. There is no reason it should not build packages from PM3 or SRC. Now, this is not to say that perhaps we haven't overreached with LONGINT given that 64-bit is more prevalent. But then it is also useful to be able to interoperate with C libraries. The previous interfacing was pretty much a kludge, using ARRAY[0..1] OF INTEGER for "long long" but then not propagating the double INTEGER value properly throughout the Modula-3 libraries. I'm sorry to say that EWD was not particularly renowned for his practicality; pedant more like. Nice to be high and mighty but we also need to interact with the real world. We should be able to make this work. Is there a better alternative? Revoke LONGINT, and WIDECHAR? On 18 Apr 2010, at 15:59, Mika Nystrom wrote: > > My problem is really just that it's ugly. LONGx is showing up as an issue > in all sorts of low-level code, which is not surprising since Modula-3 > with LONGx is not the same language as Modula-3 (maybe we should call > it Modula-3+?) > > The compiler bootstrapping process has gotten more complicated due to it, > and when I cvs updated m3tk yesterday stubgen wouldn't compile because there > was something "long" in it that wasn't there before. I have no idea what > library or components I needed to update and recompile and didn't have the > time to deal with the issue at the time. > > And the new m3tk, stubgen, and compiler(?) won't compile using PM3 or > SRC M3 since we're no longer using the language of the Green Book. > (Same comment goes for WIDECHAR, by the way.) > > One of the wonderful things about Modula-3 *used to be* that I could > grab some old package from DECSRC and just use it without changes since > no one had messed with the language definition. This is still true as > far as programs that just use the tools go, but it's no longer true for > programs that process Modula-3 code as input data. Of which there are > more than a few: many aspects of Modula-3 were specifically designed to > make the language easy to process by program, as an intermediate format > and whatnot. > > To quote E.W.D.: > > 'Unfathomed misunderstanding is further revealed by the term "software > maintenance", as a result of which many people continue to believe that > programs and even programming languages themselves are subject to wear > and tear. Your car needs maintenance too, doesn't it? Famous is the story > of the oil company that believed that its PASCAL programs did not last > as long as its FORTRAN programs "because PASCAL was not maintained".' > > LONGx is causing me to have to do "software maintenance" on Modula-3 > programs... for a feature that no one appears to be using and is quickly > becoming irrelevant. > > Mika > > > Tony Hosking writes: >> In the language spec NUMBER(a) and LAST(a) - FIRST(a) + 1 are *not* = >> defined to mean the same thing for all types. >> NUMBER does have an INTEGER value, as expected for subranges of LONGINT = >> that are not too large. >> This is as it has always been for subranges of INTEGER that are not too = >> large. >> >> Mika, I'm not sure I see any of the problems you are worrying about in = >> the current definition of LONGINT/LONGCARD. >> >> On 18 Apr 2010, at 03:49, Mika Nystrom wrote: >> >>> =20 >>> Jay I know most of this, and it doesn't really answer the question >>> "what is it for?" >>> =20 >>> I think we've already established that LONGINT isn't useful for = >> counting >>> anything that might actually reside in the computer's memory: it makes >>> no sense as an array index, for instance. INTEGER suffices for that. >>> =20 >>> I thought that the only real reason for LONGINT was to match C's >>> declaration of various seek-related routines on 32-bit machines. >>> That's not a very good reason. >>> =20 >>> C++ succeeds because it does very well in the area(s) it is good at. >>> People who want to program in C++ will clearly program in C++, not >>> Modula-3. Modula-3 is never, ever going to be the language of choice = >> for >>> people who want lots of snazzy infix operators. Modula-3 is supposed = >> to >>> be a language with about as powerful semantics as C++ and an extremely >>> simple syntax and definition---snazzy infix is one of the things you >>> give up for that. I don't see how LONGINT fits into this picture. >>> Now we have LONGCARD too? And it's infected the definitions >>> of FIRST and LAST? But not NUMBER... argh! >>> =20 >>> so, >>> =20 >>> NUMBER(a) and LAST(a) - FIRST(a) + 1 >>> =20 >>> no longer mean the same thing? Are we going to see lots of comments >>> in generics in the future where it says T may not be an open array >>> type nor an array type indexed on LONGINT or a subrange thereof? >>> =20 >>> Your comments about different parameter-passing techniques was what I = >> was >>> trying to address with my suggestion to have a pragma for this---just = >> to >>> match C (and Fortran?), of course. Name me a single Modula-3 = >> programmer >>> who cares in what order the bits in his parameters are pushed on the >>> stack in a Modula-3-to-Modula-3 call. >>> =20 >>> And I am definitely in that school of thought that says that = >> programming >>> languages should not "evolve". Better to leave well enough alone. >>> =20 >>> How much Modula-3 code has been written that uses LONGINT? Other than >>> to talk to C? I've certainly never used it. >>> =20 >>> Mika >>> =20 >>> =20 >>> =20 >>> Jay K writes: >>>> --_264cb69b-0215-44c3-807c-8b4d8ea0ea59_ >>>> Content-Type: text/plain; charset=3D"iso-8859-1" >>>> Content-Transfer-Encoding: quoted-printable >>>> =20 >>>> =20 >>>> TYPE LONGINT =3D3D ARRAY [0..1] OF INTEGER on a 32bit system is very = >> close to=3D >>>> LONGINT. >>>> =20 >>>> Plus treating it opaquely and providing a bunch of functions to = >> operate on=3D >>>> it. >>>> =20 >>>> Just as well therefore could be RECORD hi=3D2Clo:LONGINT END (see = >> LARGE_INTE=3D >>>> GER and ULARGE_INTEGER in winnt.h) >>>> =20 >>>> =3D20 >>>> =20 >>>> Differences that come to mind: >>>> =20 >>>> infix operators <=3D3D=3D3D=3D3D=3D20 >>>> =20 >>>> possibly passed differently as a parameter >>>> =20 >>>> or returned differently as a result >>>> =20 >>>> ie. probably "directly compatible with" "long long"=3D2C passed by = >> value (o=3D >>>> f course you could always pass by pointer and achieve compatibilitity = >> trivi=3D >>>> ally) >>>> =20 >>>> =3D20 >>>> =20 >>>> =3D20 >>>> =20 >>>> I have to say though=3D2C the biggest reason is in-fix operators. = >> Convenient =3D >>>> syntax. >>>> =20 >>>> C++ is the best and some way worst of example of the general right = >> way to d=3D >>>> o this -- you let programmers define types and their infix operators. = >> Other=3D >>>> languages just come with a passle of special cases of types that have = >> in-f=3D >>>> ix operators. >>>> =20 >>>> A good example is that Java infix operator + on string=3D2C besides = >> the vario=3D >>>> us integers=3D2C and nothing else. >>>> =20 >>>> =3D20 >>>> =20 >>>> =3D20 >>>> =20 >>>> I think C# lets you define operators=3D2C yet people don't complain = >> that it i=3D >>>> s "a mess" as they do of C++. >>>> =20 >>>> I think Python does now too. >>>> =20 >>>> So it is feature growing in popularity among "mainstream" = >> languages=3D2C not =3D >>>> just C++. >>>> =20 >>>> C++ of course is extremely mainstream=3D2C but also a favorite = >> target. (ht=3D >>>> tp://www.relisoft.com/tools/CppCritic.html) >>>> =20 >>>> =3D20 >>>> =20 >>>> =3D20 >>>> =20 >>>> We also have subranges of LONGINT. >>>> =20 >>>> I'm not sure what the generalization of subranges are=3D2C granted. >>>> =20 >>>> Maybe some sort of C++ template that takes constants in the template = >> and d=3D >>>> oes range checks at runtime. Yeah=3D2C maybe. >>>> =20 >>>> =3D20 >>>> =20 >>>> =3D20 >>>> =20 >>>> And as you point out=3D2C convenient literal syntax. >>>> =20 >>>> =3D20 >>>> =20 >>>> =3D20 >>>> =20 >>>> People reasonably argue for library extension in place of language = >> extensio=3D >>>> n=3D2C but that requires a language which is flexible enough to write = >> librari=3D >>>> es with the desired interface=3D2C and so many languages don't let = >> infix oper=3D >>>> ators be in a user-written library. >>>> =20 >>>> (There is a subtle but useless distinction here -- infix operators = >> being in=3D >>>> libraries vs. "user-written" libraries. The infix set operations for = >> examp=3D >>>> le are in a library=3D2C but not user-written=3D2C special=3D2C the = >> compiler know=3D >>>> s about it.) >>>> =20 >>>> =3D20 >>>> =20 >>>>> that would perhaps not match how C handles "long long" on the same >>>>> platform (which is how=3D2C come to think of it?)=3D2C and that = >> would require >>>> =20 >>>> =20 >>>> =3D20 >>>> =20 >>>> On NT/x86=3D2C __int64/long long is returned in the register pair = >> edx:eax. >>>> =20 >>>> edx is high=3D2C eax is low. >>>> =20 >>>> When passed as a parameter to __stdcall or __cdecl is just passed as = >> two 32=3D >>>> bit values adjacent on the stack=3D2C "hi=3D2C lo=3D2C hi=3D2C lo=3D2C = >> it's off to pu=3D >>> sh we go" is the Snow White-influenced mantra to remember how to pass = >> them=3D >>>> =3D2C at least on little endian stack-growing-down machines (which = >> includes x=3D >>>> 86). For __fastcall I'm not sure they are passed in registers or on = >> the sta=3D >>>> ck. >>>> =20 >>>> Passing and/or returning small structs also has special efficient = >> handling =3D >>>> in the ABI=3D2C so __int64 really might be equivalent to a small = >> record. Not =3D >>>> that cm3 necessarily implements that "correctly" -- for interop with = >> C=3D3B =3D >>>> for Modula-3 calling Modula-3 we can make up our own ABI so there = >> isn't rea=3D >>>> lly an "incorrect" way. Notice the mingw problem I had passing a = >> Win32 poin=3D >>>> t struct by value=3D2C I cheated and passed it by VAR to a C wrapper = >> to worka=3D >>>> round the gcc backend bug (which was mentioned a few times and which = >> I look=3D >>>> ed into the code for=3D2C but took the easy route) >>>> =20 >>>> =3D20 >>>> =20 >>>> =3D20 >>>> =20 >>>> I don't know how long long works on other platforms but probably = >> similar. >>>> =20 >>>> Probably a certain register pair for return values. >>>> =20 >>>> =3D20 >>>> =20 >>>> - Jay >>>> =20 >>>> =3D20 >>>>> To: hosking at cs.purdue.edu >>>>> Date: Sat=3D2C 17 Apr 2010 19:47:03 -0700 >>>>> From: mika at async.async.caltech.edu >>>>> CC: m3devel at elegosoft.com >>>>> Subject: Re: [M3devel] INTEGER >>>>> =3D20 >>>>> Tony Hosking writes: >>>>>> =20 >>>>> ... >>>>>> =20 >>>>>>> We need it to match 64-bit integers on 32-bit machines? That seems = >> =3D3D >>>>>> like >>>>>>> a very weak rationale indeed=3D2C if the same functionality could = >> be =3D3D >>>>>> provided >>>>>>> through some other mechanism (e.g.=3D2C ARRAY [0..1] OF = >> INTEGER---even =3D >>>> =3D3D >>>>>> with >>>>>>> a pragma e.g. <*CLONGLONG*>.. if it is necessary to tell the = >> compiler =3D >>>> =3D3D >>>>>> that >>>>>>> a special linkage convention is needed). >>>>>> =20 >>>>>> There's no special linkage convention. Not sure what you mean here. >>>>>> =20 >>>>> =3D20 >>>>> I just mean if we had >>>>> =3D20 >>>>> TYPE LONGINT =3D3D ARRAY [0..1] OF INTEGER >>>>> =3D20 >>>>> that would perhaps not match how C handles "long long" on the same >>>>> platform (which is how=3D2C come to think of it?)=3D2C and that = >> would require >>>>> special linkage tricks. >>>>> =3D20 >>>>> But what would be lost? The ability to type literals.=3D20 >>>>> =3D20 >>>>> You could get the same code interface on 32- and 64-bit machine by >>>>> defining >>>>> =3D20 >>>>> TYPE FileOffset =3D3D ARRAY[0..1] OF [-16_80000000 .. +16_7fffffff ] >>>>> =3D20 >>>>> and using that. >>>>> =3D20 >>>>> =3D20 >>>>> Mika >>>> =3D >>>> =20 >>>> --_264cb69b-0215-44c3-807c-8b4d8ea0ea59_ >>>> Content-Type: text/html; charset=3D"iso-8859-1" >>>> Content-Transfer-Encoding: quoted-printable >>>> =20 >>>> >>>> >>>> >>>> >>>> >>>> TYPE LONGINT =3D3D ARRAY [0..1] OF INTEGER on a =3D3B32bit system = >> is very c=3D >>>> lose to LONGINT.
>>>>  =3D3BPlus treating it opaquely and providing a bunch of = >> functions to ope=3D >>>> rate on it.
>>>>  =3D3BJust as well therefore could be RECORD hi=3D2Clo:LONGINT = >> END (see LAR=3D >>>> GE_INTEGER and ULARGE_INTEGER in winnt.h)
>>>>  =3D3B
>>>> Differences that come to mind:
>>>>  =3D3B =3D3Binfix operators =3D3B <=3D3B=3D3D=3D3D=3D3D = >>
>>>>  =3D3B possibly passed differently =3D3Bas a parameter
>>>>  =3D3B or returned differently as a result
>>>>  =3D3B ie. probably "directly compatible with" "long long"=3D2C = >> passed by v=3D >>>> alue (of course you could always pass by pointer and achieve = >> compatibilitit=3D >>>> y trivially)
>>>>  =3D3B
>>>>  =3D3B
>>>> I have to say though=3D2C the biggest reason is in-fix operators. = >> Convenient =3D >>>> syntax.
>>>> C++ is the best and some way worst of example of the general right = >> way to d=3D >>>> o this -- you let programmers define types and their infix operators. = >> Other=3D >>>> languages just come with a passle of special cases of types that have = >> in-f=3D >>>> ix operators.
>>>> A good example is that Java infix operator + on string=3D2C besides = >> the vario=3D >>>> us integers=3D2C and nothing else.
>>>>  =3D3B
>>>>  =3D3B
>>>> I think C# lets you define operators=3D2C yet people don't complain = >> that it i=3D >>>> s "a mess" as they do of C++.
>>>> I think Python does now too.
>>>> So it is feature growing in popularity among "mainstream" = >> languages=3D2C not =3D >>>> just C++.
>>>>  =3D3B =3D3B C++ of course is extremely mainstream=3D2C but = >> also a favori=3D >>>> te target. (> href=3D3D"http://www.relisoft.com/tools/CppCritic.html">http:/=3D >>>> /www.relisoft.com/tools/CppCritic.html)
>>>>  =3D3B
>>>>  =3D3B
>>>> We also have subranges of LONGINT.
>>>> I'm not sure what the generalization of subranges are=3D2C = >> granted.
>>>>  =3D3BMaybe some sort of C++ template that takes constants in the = >> templat=3D >>>> e and does range checks at runtime. Yeah=3D2C maybe.
>>>>  =3D3B
>>>>  =3D3B
>>>> And as you point out=3D2C convenient literal syntax.
>>>>  =3D3B
>>>>  =3D3B
>>>> People reasonably argue for library extension in place of language = >> extensio=3D >>>> n=3D2C but that requires a language which is flexible enough to write = >> librari=3D >>>> es with the desired interface=3D2C and so many languages don't let = >> infix oper=3D >>>> ators be in a user-written library.
>>>> (There is a subtle but useless distinction here -- infix operators = >> being in=3D >>>> libraries vs. "user-written" libraries. The infix set operations for = >> examp=3D >>>> le are in a library=3D2C but not user-written=3D2C special=3D2C the = >> compiler know=3D >>>> s about it.)
>>>>  =3D3B
>>>> >=3D3B that would perhaps not match how C handles "long long" on = >> the same>>> R>>=3D3B platform (which is how=3D2C come to think of it?)=3D2C and = >> that would =3D >>>> require

>>>>  =3D3B
>>>> On NT/x86=3D2C __int64/long long is returned in the register pair = >> edx:eax.>>>> =20 >>>> edx is high=3D2C eax is low.
>>>> When passed as a parameter to __stdcall or __cdecl is just passed as = >> two 32=3D >>>> bit values adjacent on the stack=3D2C "hi=3D2C lo=3D2C hi=3D2C lo=3D2C = >> it's off to pu=3D >>>> sh we go" is the Snow White-influenced mantra to remember how to pass = >> them=3D >>>> =3D2C at least on little endian stack-growing-down machines (which = >> includes x=3D >>>> 86). For __fastcall I'm not sure they are passed in registers or on = >> the sta=3D >>>> ck.
>>>> Passing and/or returning small structs also has special efficient = >> handling =3D >>>> in the ABI=3D2C so __int64 really might be equivalent to a small = >> record. Not =3D >>>> that cm3 necessarily implements that "correctly" =3D3B -- for = >> interop wit=3D >>>> h C=3D3B for Modula-3 calling Modula-3 we can make up our own ABI so = >> there is=3D >>>> n't =3D3Breally an "incorrect" way. =3D3BNotice the mingw = >> problem I had=3D >>>> passing a Win32 point struct by value=3D2C I cheated and passed it by = >> VAR to=3D >>>> a =3D3BC wrapper to workaround the gcc backend bug (which was = >> mentioned =3D >>>> a few times and which I looked into the code for=3D2C but took the = >> easy route=3D >>>> )
>>>>  =3D3B
>>>>  =3D3B
>>>> I don't know how long long works on other platforms but probably = >> similar.>>> R> >>>> Probably a certain register pair for return values.
>>>>  =3D3B
>>>>  =3D3B- Jay

 =3D3B
>=3D3B To: = >> hosking at cs.purdue.edu
>=3D3B=3D >>>> Date: Sat=3D2C 17 Apr 2010 19:47:03 -0700
>=3D3B From: = >> mika at async.async.c=3D >>>> altech.edu
>=3D3B CC: m3devel at elegosoft.com
>=3D3B Subject: = >> Re: [M3de=3D >>>> vel] INTEGER
>=3D3B
>=3D3B Tony Hosking writes:
>=3D3B = >> >=3D3B
=3D >>>> >=3D3B ...
>=3D3B >=3D3B
>=3D3B >=3D3B>=3D3B We = >> need it to match 64-b=3D >>>> it integers on 32-bit machines? That seems =3D3D
>=3D3B = >> >=3D3Blike
>=3D >>>> =3D3B >=3D3B>=3D3B a very weak rationale indeed=3D2C if the same = >> functionality =3D >>>> could be =3D3D
>=3D3B >=3D3Bprovided
>=3D3B >=3D3B>=3D3= >> B through some o=3D >>>> ther mechanism (e.g.=3D2C ARRAY [0..1] OF INTEGER---even = >> =3D3D
>=3D3B >=3D3B=3D >>>> with
>=3D3B >=3D3B>=3D3B a pragma e.g. = >> <=3D3B*CLONGLONG*>=3D3B.. if it i=3D >>>> s necessary to tell the compiler =3D3D
>=3D3B = >> >=3D3Bthat
>=3D3B >=3D3B&=3D >>>> gt=3D3B a special linkage convention is needed).
>=3D3B = >> >=3D3B
>=3D3B &=3D >>>> gt=3D3BThere's no special linkage convention. Not sure what you mean = >> here.>>>> >=3D3B >=3D3B
>=3D3B
>=3D3B I just mean if we = >> had
>=3D3B
>=3D >>>> =3D3B TYPE LONGINT =3D3D ARRAY [0..1] OF INTEGER
>=3D3B = >>
>=3D3B that woul=3D >>>> d perhaps not match how C handles "long long" on the same
>=3D3B = >> platfor=3D >>>> m (which is how=3D2C come to think of it?)=3D2C and that would = >> require
>=3D >>>> =3D3B special linkage tricks.
>=3D3B
>=3D3B But what would = >> be lost? Th=3D >>>> e ability to type literals.
>=3D3B
>=3D3B You could get = >> the same co=3D >>>> de interface on 32- and 64-bit machine by
>=3D3B = >> defining
>=3D3B
=3D >>>> >=3D3B TYPE FileOffset =3D3D ARRAY[0..1] OF [-16_80000000 .. = >> +16_7fffffff ]>>> R>>=3D3B
>=3D3B and using that.
>=3D3B
>=3D3B = >>
>=3D3B Mika>>>> >>>> =3D >>>> =20 >>>> --_264cb69b-0215-44c3-807c-8b4d8ea0ea59_-- From jay.krell at cornell.edu Mon Apr 19 04:44:51 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 19 Apr 2010 02:44:51 +0000 Subject: [M3devel] INTEGER In-Reply-To: References: , , ,,<7C7408D0-9A40-4988-BADA-A9FD8C15D388@cs.purdue.edu>, ,,, , , , , , , , , <20100418023535.3BA9E1A2103@async.async.caltech.edu>, , , , <20100418024703.6965B1A2103@async.async.caltech.edu>, , <20100418074927.934461A2117@async.async.caltech.edu>, <04EB7FF8-D304-428D-839E-233FCE009C98@cs.purdue.edu>, <20100418195901.CDACB1A20F6@async.async.caltech.edu>, Message-ID: Mika, the build process hasn't "really" changed. There was always an occasional "bump" where you had to build the compiler skipping m3core/libm3, and then again with building m3core/libm3. It used to happen any time a target was added. But I fixed that. Then it also happened with WIDECHAR, then with LONGINT, then with LONGCARD and the VAL changes. There was also a "bump" when cm3 started using m3core's TextUtils, though I've removed that -- I've removed a few "bumps" where possible, but some remain. Old cm3 cannot compile "modern" m3core/libm3. Other than needing this "skipping" of m3core/libm3, you can actually build the current system starting with an old 5.x release. I haven't tried 5.1/4.1/3.6 yet but maybe I will soon. I actually use current configuration files when doing that though, so that probably inhibits 3.6 (unless I use its configuration files). Having skimmed through http://yarchive.net/comp/longlong.html ... wow folks are *adamant* that C needed long long, like in order to 32bit systems to cross compile for 64bit... I continue to suspect that infix operators and efficiency are the primary motivators. "efficiency" in terms of being sure to avoid function calls for some operations, which is likely doable otherwise. People really want their compiler to handle multiple precision arithmetic, at least to attain 64bit precision. It is nice and convenient, if not strictly necessary. Another view though, besides "interop" with C, is "keeping up" with C. Again that link suggests C has had long long for something like 18 years. We are late. Even C changed, C99 must be around 10 years old now? and has lnog long. Granted, I tend to think of C like you think of Modula-3 --- nice that it never changes. It is somewhat small, very well known. One only needs keep up with libraries now :) and one can assume a certain baseline is everywhere and write portable code to it. (But I've happened upon K&R compiler *recently* -- HP-UX/hppa only bundles a compiler for purposes of changing kernel configuration (constant data) and relinking kernel. The libraries that comprise the kernel are shipped. K&R suffices and is therefore bundled. Best is probably to use that compiler to build old gcc, and then use old gcc to build current gcc (current gcc can't be compiled with K&R)). WIDECHAR is maybe a bit funny. Notice how in C and C++, until subtle small later changes in C++, wchar_t was just a typedef of unsigned short, you could write literals L'a' and L"foo", and there was a bunch of library functions -- again, the "language" aspect being just literals, close to the situation with LONGINT where the language provides literals and infix notation. In fact I think the next version of C++ improves the situation for "literals" of user defined types, like the "constexpr" feature will make constructors better able to stand in for literals, I think. - Jay > From: hosking at cs.purdue.edu > Date: Sun, 18 Apr 2010 20:38:43 -0400 > To: mika at async.async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] INTEGER > > Mika, > > First off, I'd be very interested to know what the issues are with LONGINT and stubgen. We are building that every day in regression testing. It would be really good to get some precise feedback. > > True, LONGINT is integrated with all of the language tools (same as WIDECHAR). > > I suppose that is the price we pay for the language having evolved. Nevertheless, CM3 should be totally backward compatible with the green book. There is no reason it should not build packages from PM3 or SRC. > > Now, this is not to say that perhaps we haven't overreached with LONGINT given that 64-bit is more prevalent. But then it is also useful to be able to interoperate with C libraries. The previous interfacing was pretty much a kludge, using ARRAY[0..1] OF INTEGER for "long long" but then not propagating the double INTEGER value properly throughout the Modula-3 libraries. > > I'm sorry to say that EWD was not particularly renowned for his practicality; pedant more like. Nice to be high and mighty but we also need to interact with the real world. > > We should be able to make this work. Is there a better alternative? Revoke LONGINT, and WIDECHAR? > > On 18 Apr 2010, at 15:59, Mika Nystrom wrote: > > > > > My problem is really just that it's ugly. LONGx is showing up as an issue > > in all sorts of low-level code, which is not surprising since Modula-3 > > with LONGx is not the same language as Modula-3 (maybe we should call > > it Modula-3+?) > > > > The compiler bootstrapping process has gotten more complicated due to it, > > and when I cvs updated m3tk yesterday stubgen wouldn't compile because there > > was something "long" in it that wasn't there before. I have no idea what > > library or components I needed to update and recompile and didn't have the > > time to deal with the issue at the time. > > > > And the new m3tk, stubgen, and compiler(?) won't compile using PM3 or > > SRC M3 since we're no longer using the language of the Green Book. > > (Same comment goes for WIDECHAR, by the way.) > > > > One of the wonderful things about Modula-3 *used to be* that I could > > grab some old package from DECSRC and just use it without changes since > > no one had messed with the language definition. This is still true as > > far as programs that just use the tools go, but it's no longer true for > > programs that process Modula-3 code as input data. Of which there are > > more than a few: many aspects of Modula-3 were specifically designed to > > make the language easy to process by program, as an intermediate format > > and whatnot. > > > > To quote E.W.D.: > > > > 'Unfathomed misunderstanding is further revealed by the term "software > > maintenance", as a result of which many people continue to believe that > > programs and even programming languages themselves are subject to wear > > and tear. Your car needs maintenance too, doesn't it? Famous is the story > > of the oil company that believed that its PASCAL programs did not last > > as long as its FORTRAN programs "because PASCAL was not maintained".' > > > > LONGx is causing me to have to do "software maintenance" on Modula-3 > > programs... for a feature that no one appears to be using and is quickly > > becoming irrelevant. > > > > Mika > > > > > > Tony Hosking writes: > >> In the language spec NUMBER(a) and LAST(a) - FIRST(a) + 1 are *not* = > >> defined to mean the same thing for all types. > >> NUMBER does have an INTEGER value, as expected for subranges of LONGINT = > >> that are not too large. > >> This is as it has always been for subranges of INTEGER that are not too = > >> large. > >> > >> Mika, I'm not sure I see any of the problems you are worrying about in = > >> the current definition of LONGINT/LONGCARD. > >> > >> On 18 Apr 2010, at 03:49, Mika Nystrom wrote: > >> > >>> =20 > >>> Jay I know most of this, and it doesn't really answer the question > >>> "what is it for?" > >>> =20 > >>> I think we've already established that LONGINT isn't useful for = > >> counting > >>> anything that might actually reside in the computer's memory: it makes > >>> no sense as an array index, for instance. INTEGER suffices for that. > >>> =20 > >>> I thought that the only real reason for LONGINT was to match C's > >>> declaration of various seek-related routines on 32-bit machines. > >>> That's not a very good reason. > >>> =20 > >>> C++ succeeds because it does very well in the area(s) it is good at. > >>> People who want to program in C++ will clearly program in C++, not > >>> Modula-3. Modula-3 is never, ever going to be the language of choice = > >> for > >>> people who want lots of snazzy infix operators. Modula-3 is supposed = > >> to > >>> be a language with about as powerful semantics as C++ and an extremely > >>> simple syntax and definition---snazzy infix is one of the things you > >>> give up for that. I don't see how LONGINT fits into this picture. > >>> Now we have LONGCARD too? And it's infected the definitions > >>> of FIRST and LAST? But not NUMBER... argh! > >>> =20 > >>> so, > >>> =20 > >>> NUMBER(a) and LAST(a) - FIRST(a) + 1 > >>> =20 > >>> no longer mean the same thing? Are we going to see lots of comments > >>> in generics in the future where it says T may not be an open array > >>> type nor an array type indexed on LONGINT or a subrange thereof? > >>> =20 > >>> Your comments about different parameter-passing techniques was what I = > >> was > >>> trying to address with my suggestion to have a pragma for this---just = > >> to > >>> match C (and Fortran?), of course. Name me a single Modula-3 = > >> programmer > >>> who cares in what order the bits in his parameters are pushed on the > >>> stack in a Modula-3-to-Modula-3 call. > >>> =20 > >>> And I am definitely in that school of thought that says that = > >> programming > >>> languages should not "evolve". Better to leave well enough alone. > >>> =20 > >>> How much Modula-3 code has been written that uses LONGINT? Other than > >>> to talk to C? I've certainly never used it. > >>> =20 > >>> Mika > >>> =20 > >>> =20 > >>> =20 > >>> Jay K writes: > >>>> --_264cb69b-0215-44c3-807c-8b4d8ea0ea59_ > >>>> Content-Type: text/plain; charset=3D"iso-8859-1" > >>>> Content-Transfer-Encoding: quoted-printable > >>>> =20 > >>>> =20 > >>>> TYPE LONGINT =3D3D ARRAY [0..1] OF INTEGER on a 32bit system is very = > >> close to=3D > >>>> LONGINT. > >>>> =20 > >>>> Plus treating it opaquely and providing a bunch of functions to = > >> operate on=3D > >>>> it. > >>>> =20 > >>>> Just as well therefore could be RECORD hi=3D2Clo:LONGINT END (see = > >> LARGE_INTE=3D > >>>> GER and ULARGE_INTEGER in winnt.h) > >>>> =20 > >>>> =3D20 > >>>> =20 > >>>> Differences that come to mind: > >>>> =20 > >>>> infix operators <=3D3D=3D3D=3D3D=3D20 > >>>> =20 > >>>> possibly passed differently as a parameter > >>>> =20 > >>>> or returned differently as a result > >>>> =20 > >>>> ie. probably "directly compatible with" "long long"=3D2C passed by = > >> value (o=3D > >>>> f course you could always pass by pointer and achieve compatibilitity = > >> trivi=3D > >>>> ally) > >>>> =20 > >>>> =3D20 > >>>> =20 > >>>> =3D20 > >>>> =20 > >>>> I have to say though=3D2C the biggest reason is in-fix operators. = > >> Convenient =3D > >>>> syntax. > >>>> =20 > >>>> C++ is the best and some way worst of example of the general right = > >> way to d=3D > >>>> o this -- you let programmers define types and their infix operators. = > >> Other=3D > >>>> languages just come with a passle of special cases of types that have = > >> in-f=3D > >>>> ix operators. > >>>> =20 > >>>> A good example is that Java infix operator + on string=3D2C besides = > >> the vario=3D > >>>> us integers=3D2C and nothing else. > >>>> =20 > >>>> =3D20 > >>>> =20 > >>>> =3D20 > >>>> =20 > >>>> I think C# lets you define operators=3D2C yet people don't complain = > >> that it i=3D > >>>> s "a mess" as they do of C++. > >>>> =20 > >>>> I think Python does now too. > >>>> =20 > >>>> So it is feature growing in popularity among "mainstream" = > >> languages=3D2C not =3D > >>>> just C++. > >>>> =20 > >>>> C++ of course is extremely mainstream=3D2C but also a favorite = > >> target. (ht=3D > >>>> tp://www.relisoft.com/tools/CppCritic.html) > >>>> =20 > >>>> =3D20 > >>>> =20 > >>>> =3D20 > >>>> =20 > >>>> We also have subranges of LONGINT. > >>>> =20 > >>>> I'm not sure what the generalization of subranges are=3D2C granted. > >>>> =20 > >>>> Maybe some sort of C++ template that takes constants in the template = > >> and d=3D > >>>> oes range checks at runtime. Yeah=3D2C maybe. > >>>> =20 > >>>> =3D20 > >>>> =20 > >>>> =3D20 > >>>> =20 > >>>> And as you point out=3D2C convenient literal syntax. > >>>> =20 > >>>> =3D20 > >>>> =20 > >>>> =3D20 > >>>> =20 > >>>> People reasonably argue for library extension in place of language = > >> extensio=3D > >>>> n=3D2C but that requires a language which is flexible enough to write = > >> librari=3D > >>>> es with the desired interface=3D2C and so many languages don't let = > >> infix oper=3D > >>>> ators be in a user-written library. > >>>> =20 > >>>> (There is a subtle but useless distinction here -- infix operators = > >> being in=3D > >>>> libraries vs. "user-written" libraries. The infix set operations for = > >> examp=3D > >>>> le are in a library=3D2C but not user-written=3D2C special=3D2C the = > >> compiler know=3D > >>>> s about it.) > >>>> =20 > >>>> =3D20 > >>>> =20 > >>>>> that would perhaps not match how C handles "long long" on the same > >>>>> platform (which is how=3D2C come to think of it?)=3D2C and that = > >> would require > >>>> =20 > >>>> =20 > >>>> =3D20 > >>>> =20 > >>>> On NT/x86=3D2C __int64/long long is returned in the register pair = > >> edx:eax. > >>>> =20 > >>>> edx is high=3D2C eax is low. > >>>> =20 > >>>> When passed as a parameter to __stdcall or __cdecl is just passed as = > >> two 32=3D > >>>> bit values adjacent on the stack=3D2C "hi=3D2C lo=3D2C hi=3D2C lo=3D2C = > >> it's off to pu=3D > >>> sh we go" is the Snow White-influenced mantra to remember how to pass = > >> them=3D > >>>> =3D2C at least on little endian stack-growing-down machines (which = > >> includes x=3D > >>>> 86). For __fastcall I'm not sure they are passed in registers or on = > >> the sta=3D > >>>> ck. > >>>> =20 > >>>> Passing and/or returning small structs also has special efficient = > >> handling =3D > >>>> in the ABI=3D2C so __int64 really might be equivalent to a small = > >> record. Not =3D > >>>> that cm3 necessarily implements that "correctly" -- for interop with = > >> C=3D3B =3D > >>>> for Modula-3 calling Modula-3 we can make up our own ABI so there = > >> isn't rea=3D > >>>> lly an "incorrect" way. Notice the mingw problem I had passing a = > >> Win32 poin=3D > >>>> t struct by value=3D2C I cheated and passed it by VAR to a C wrapper = > >> to worka=3D > >>>> round the gcc backend bug (which was mentioned a few times and which = > >> I look=3D > >>>> ed into the code for=3D2C but took the easy route) > >>>> =20 > >>>> =3D20 > >>>> =20 > >>>> =3D20 > >>>> =20 > >>>> I don't know how long long works on other platforms but probably = > >> similar. > >>>> =20 > >>>> Probably a certain register pair for return values. > >>>> =20 > >>>> =3D20 > >>>> =20 > >>>> - Jay > >>>> =20 > >>>> =3D20 > >>>>> To: hosking at cs.purdue.edu > >>>>> Date: Sat=3D2C 17 Apr 2010 19:47:03 -0700 > >>>>> From: mika at async.async.caltech.edu > >>>>> CC: m3devel at elegosoft.com > >>>>> Subject: Re: [M3devel] INTEGER > >>>>> =3D20 > >>>>> Tony Hosking writes: > >>>>>> =20 > >>>>> ... > >>>>>> =20 > >>>>>>> We need it to match 64-bit integers on 32-bit machines? That seems = > >> =3D3D > >>>>>> like > >>>>>>> a very weak rationale indeed=3D2C if the same functionality could = > >> be =3D3D > >>>>>> provided > >>>>>>> through some other mechanism (e.g.=3D2C ARRAY [0..1] OF = > >> INTEGER---even =3D > >>>> =3D3D > >>>>>> with > >>>>>>> a pragma e.g. <*CLONGLONG*>.. if it is necessary to tell the = > >> compiler =3D > >>>> =3D3D > >>>>>> that > >>>>>>> a special linkage convention is needed). > >>>>>> =20 > >>>>>> There's no special linkage convention. Not sure what you mean here. > >>>>>> =20 > >>>>> =3D20 > >>>>> I just mean if we had > >>>>> =3D20 > >>>>> TYPE LONGINT =3D3D ARRAY [0..1] OF INTEGER > >>>>> =3D20 > >>>>> that would perhaps not match how C handles "long long" on the same > >>>>> platform (which is how=3D2C come to think of it?)=3D2C and that = > >> would require > >>>>> special linkage tricks. > >>>>> =3D20 > >>>>> But what would be lost? The ability to type literals.=3D20 > >>>>> =3D20 > >>>>> You could get the same code interface on 32- and 64-bit machine by > >>>>> defining > >>>>> =3D20 > >>>>> TYPE FileOffset =3D3D ARRAY[0..1] OF [-16_80000000 .. +16_7fffffff ] > >>>>> =3D20 > >>>>> and using that. > >>>>> =3D20 > >>>>> =3D20 > >>>>> Mika > >>>> =3D > >>>> =20 > >>>> --_264cb69b-0215-44c3-807c-8b4d8ea0ea59_ > >>>> Content-Type: text/html; charset=3D"iso-8859-1" > >>>> Content-Transfer-Encoding: quoted-printable > >>>> =20 > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> TYPE LONGINT =3D3D ARRAY [0..1] OF INTEGER on a =3D3B32bit system = > >> is very c=3D > >>>> lose to LONGINT.
> >>>>  =3D3BPlus treating it opaquely and providing a bunch of = > >> functions to ope=3D > >>>> rate on it.
> >>>>  =3D3BJust as well therefore could be RECORD hi=3D2Clo:LONGINT = > >> END (see LAR=3D > >>>> GE_INTEGER and ULARGE_INTEGER in winnt.h)
> >>>>  =3D3B
> >>>> Differences that come to mind:
> >>>>  =3D3B =3D3Binfix operators =3D3B <=3D3B=3D3D=3D3D=3D3D = > >>
> >>>>  =3D3B possibly passed differently =3D3Bas a parameter
> >>>>  =3D3B or returned differently as a result
> >>>>  =3D3B ie. probably "directly compatible with" "long long"=3D2C = > >> passed by v=3D > >>>> alue (of course you could always pass by pointer and achieve = > >> compatibilitit=3D > >>>> y trivially)
> >>>>  =3D3B
> >>>>  =3D3B
> >>>> I have to say though=3D2C the biggest reason is in-fix operators. = > >> Convenient =3D > >>>> syntax.
> >>>> C++ is the best and some way worst of example of the general right = > >> way to d=3D > >>>> o this -- you let programmers define types and their infix operators. = > >> Other=3D > >>>> languages just come with a passle of special cases of types that have = > >> in-f=3D > >>>> ix operators.
> >>>> A good example is that Java infix operator + on string=3D2C besides = > >> the vario=3D > >>>> us integers=3D2C and nothing else.
> >>>>  =3D3B
> >>>>  =3D3B
> >>>> I think C# lets you define operators=3D2C yet people don't complain = > >> that it i=3D > >>>> s "a mess" as they do of C++.
> >>>> I think Python does now too.
> >>>> So it is feature growing in popularity among "mainstream" = > >> languages=3D2C not =3D > >>>> just C++.
> >>>>  =3D3B =3D3B C++ of course is extremely mainstream=3D2C but = > >> also a favori=3D > >>>> te target. ( >> href=3D3D"http://www.relisoft.com/tools/CppCritic.html">http:/=3D > >>>> /www.relisoft.com/tools/CppCritic.html)
> >>>>  =3D3B
> >>>>  =3D3B
> >>>> We also have subranges of LONGINT.
> >>>> I'm not sure what the generalization of subranges are=3D2C = > >> granted.
> >>>>  =3D3BMaybe some sort of C++ template that takes constants in the = > >> templat=3D > >>>> e and does range checks at runtime. Yeah=3D2C maybe.
> >>>>  =3D3B
> >>>>  =3D3B
> >>>> And as you point out=3D2C convenient literal syntax.
> >>>>  =3D3B
> >>>>  =3D3B
> >>>> People reasonably argue for library extension in place of language = > >> extensio=3D > >>>> n=3D2C but that requires a language which is flexible enough to write = > >> librari=3D > >>>> es with the desired interface=3D2C and so many languages don't let = > >> infix oper=3D > >>>> ators be in a user-written library.
> >>>> (There is a subtle but useless distinction here -- infix operators = > >> being in=3D > >>>> libraries vs. "user-written" libraries. The infix set operations for = > >> examp=3D > >>>> le are in a library=3D2C but not user-written=3D2C special=3D2C the = > >> compiler know=3D > >>>> s about it.)
> >>>>  =3D3B
> >>>> >=3D3B that would perhaps not match how C handles "long long" on = > >> the same >>>> R>>=3D3B platform (which is how=3D2C come to think of it?)=3D2C and = > >> that would =3D > >>>> require

> >>>>  =3D3B
> >>>> On NT/x86=3D2C __int64/long long is returned in the register pair = > >> edx:eax. >>>>> =20 > >>>> edx is high=3D2C eax is low.
> >>>> When passed as a parameter to __stdcall or __cdecl is just passed as = > >> two 32=3D > >>>> bit values adjacent on the stack=3D2C "hi=3D2C lo=3D2C hi=3D2C lo=3D2C = > >> it's off to pu=3D > >>>> sh we go" is the Snow White-influenced mantra to remember how to pass = > >> them=3D > >>>> =3D2C at least on little endian stack-growing-down machines (which = > >> includes x=3D > >>>> 86). For __fastcall I'm not sure they are passed in registers or on = > >> the sta=3D > >>>> ck.
> >>>> Passing and/or returning small structs also has special efficient = > >> handling =3D > >>>> in the ABI=3D2C so __int64 really might be equivalent to a small = > >> record. Not =3D > >>>> that cm3 necessarily implements that "correctly" =3D3B -- for = > >> interop wit=3D > >>>> h C=3D3B for Modula-3 calling Modula-3 we can make up our own ABI so = > >> there is=3D > >>>> n't =3D3Breally an "incorrect" way. =3D3BNotice the mingw = > >> problem I had=3D > >>>> passing a Win32 point struct by value=3D2C I cheated and passed it by = > >> VAR to=3D > >>>> a =3D3BC wrapper to workaround the gcc backend bug (which was = > >> mentioned =3D > >>>> a few times and which I looked into the code for=3D2C but took the = > >> easy route=3D > >>>> )
> >>>>  =3D3B
> >>>>  =3D3B
> >>>> I don't know how long long works on other platforms but probably = > >> similar. >>>> R> > >>>> Probably a certain register pair for return values.
> >>>>  =3D3B
> >>>>  =3D3B- Jay

 =3D3B
>=3D3B To: = > >> hosking at cs.purdue.edu
>=3D3B=3D > >>>> Date: Sat=3D2C 17 Apr 2010 19:47:03 -0700
>=3D3B From: = > >> mika at async.async.c=3D > >>>> altech.edu
>=3D3B CC: m3devel at elegosoft.com
>=3D3B Subject: = > >> Re: [M3de=3D > >>>> vel] INTEGER
>=3D3B
>=3D3B Tony Hosking writes:
>=3D3B = > >> >=3D3B
=3D > >>>> >=3D3B ...
>=3D3B >=3D3B
>=3D3B >=3D3B>=3D3B We = > >> need it to match 64-b=3D > >>>> it integers on 32-bit machines? That seems =3D3D
>=3D3B = > >> >=3D3Blike
>=3D > >>>> =3D3B >=3D3B>=3D3B a very weak rationale indeed=3D2C if the same = > >> functionality =3D > >>>> could be =3D3D
>=3D3B >=3D3Bprovided
>=3D3B >=3D3B>=3D3= > >> B through some o=3D > >>>> ther mechanism (e.g.=3D2C ARRAY [0..1] OF INTEGER---even = > >> =3D3D
>=3D3B >=3D3B=3D > >>>> with
>=3D3B >=3D3B>=3D3B a pragma e.g. = > >> <=3D3B*CLONGLONG*>=3D3B.. if it i=3D > >>>> s necessary to tell the compiler =3D3D
>=3D3B = > >> >=3D3Bthat
>=3D3B >=3D3B&=3D > >>>> gt=3D3B a special linkage convention is needed).
>=3D3B = > >> >=3D3B
>=3D3B &=3D > >>>> gt=3D3BThere's no special linkage convention. Not sure what you mean = > >> here. >>>>> >=3D3B >=3D3B
>=3D3B
>=3D3B I just mean if we = > >> had
>=3D3B
>=3D > >>>> =3D3B TYPE LONGINT =3D3D ARRAY [0..1] OF INTEGER
>=3D3B = > >>
>=3D3B that woul=3D > >>>> d perhaps not match how C handles "long long" on the same
>=3D3B = > >> platfor=3D > >>>> m (which is how=3D2C come to think of it?)=3D2C and that would = > >> require
>=3D > >>>> =3D3B special linkage tricks.
>=3D3B
>=3D3B But what would = > >> be lost? Th=3D > >>>> e ability to type literals.
>=3D3B
>=3D3B You could get = > >> the same co=3D > >>>> de interface on 32- and 64-bit machine by
>=3D3B = > >> defining
>=3D3B
=3D > >>>> >=3D3B TYPE FileOffset =3D3D ARRAY[0..1] OF [-16_80000000 .. = > >> +16_7fffffff ] >>>> R>>=3D3B
>=3D3B and using that.
>=3D3B
>=3D3B = > >>
>=3D3B Mika >>>>> > >>>> =3D > >>>> =20 > >>>> --_264cb69b-0215-44c3-807c-8b4d8ea0ea59_-- > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Apr 19 05:27:01 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 19 Apr 2010 03:27:01 +0000 Subject: [M3devel] the lingering socket linger question, non-blocking Win32 sockets? Message-ID: shorter story: - Does anyone have significant socket-using Modula-3 code to test? That is used on Posix and Win32? - Given the extremely high similarly between the Windows and Posix (BSD) socket interfaces, I strongly suggest we unify the implementations, including removing some of the historical differences. I also strongly suspect the Posix implementation is the "better" one, that has recieved more thought and testing. The Win32 variants of the Modula-3 libraries often seem..suspicious. Like they were a very initial version but never really recieved the attention needed. longer story: So..I've asked a few times, why this seemingly opposite code: C:\dev2\cm3.2\m3-libs\libm3\src\os\POSIX\SocketPosix.m3(453): linger := struct_linger{1, 1}; C:\dev2\cm3.2\m3-libs\libm3\src\os\WIN32\SocketWin32.m3(401): linger := struct_linger{0, 0}; I have a *little* more information. Windows documentation warns about using linger{1} on non-blocking sockets. The default {0} seems to be what you'd want. Seems like the setsockopt isn't needed. SocketPosix.m3 sets sockets to be non-blocking. I associate "non blocking" with "prone to be slow or hang-until-timeout in real world, want to avoid that". Older SocketWin32.m3 seems to have in mind non-blocking: Searching for 'WSAEWOULDBLOCK'... C:\dev2\cm3.2\m3-libs\libm3\src\os\WIN32\SocketWin32.m3.sav(137): | WinSock.WSAEWOULDBLOCK => C:\dev2\cm3.2\m3-libs\libm3\src\os\WIN32\SocketWin32.m3.sav(189): | WinSock.WSAEWOULDBLOCK => C:\dev2\cm3.2\m3-libs\libm3\src\os\WIN32\SocketWin32.m3.sav(241): | WinSock.WSAEWOULDBLOCK => C:\dev2\cm3.2\m3-libs\libm3\src\os\WIN32\SocketWin32.m3.sav(274): | WinSock.WSAEWOULDBLOCK => C:\dev2\cm3.2\m3-libs\libm3\src\os\WIN32\SocketWin32.m3.sav(315): | WinSock.WSAEWOULDBLOCK => C:\dev2\cm3.2\m3-libs\libm3\src\os\WIN32\SocketWin32.m3.sav(356): | WinSock.WSAEWOULDBLOCK => current SocketWin32.m3 does *not* set the sockets to non-blocking. And there seems to be patterns to account for that -- checking BytesAvailable at the start of operations like Read and ReceiveFrom, where the Posix version does not. The Posix version using select/poll where the Win32 version does not (though the win32 ".sav" files does). SocketWin32.m3.sav: IF WinSock.ioctlsocket (sock, WinSock.FIONBIO, ADR(one)) = SockErr THEN Using select/poll in Posix is slightly complicated by user threads. The complexity is under the covers in the thread implementation. Win32 doesn't have that problem. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Apr 19 06:37:12 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 19 Apr 2010 04:37:12 +0000 Subject: [M3devel] Posix < 0 vs. # 0 vs. = -1? In-Reply-To: <20100418194159.E07411A2119@async.async.caltech.edu> References: , <20100418194159.E07411A2119@async.async.caltech.edu> Message-ID: Mika, you mean [-1..LAST(INTEGER)] right? - Jay > To: jay.krell at cornell.edu > Date: Sun, 18 Apr 2010 12:41:59 -0700 > From: mika at async.async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Posix < 0 vs. # 0 vs. = -1? > > Jay K writes: > >--_201b8a99-e8e8-4887-bb32-c65e8edd0b1a_ > >Content-Type: text/plain; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > >Posix often says: > > > > function foo() returns 0 for success=2C -1 for error > > > >=20 > > > > m3core/libm3/etc=2C often say if foo() < 0 or if foo() # 0 "instead". > > Generally ok to tighten these up to "=3D -1"=2C perhaps upon checking manp= > >ages=2C > > or a known rat's nest of inconsistencies? > > > > Maybe this is just my personal style, but I would code it thus: > > <*EXTERNAL*> > PROCEDURE F() : INTEGER; (* matches C declaration *) > > ... > > VAR result : [0..1] := F(); (* matches man page specification *) > BEGIN > CASE result OF > 0 => ... > | > -1 => ... > END > END > > No way for any sneaky value problems to get through. The use of > CASE also guards against typos. > > Mika -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Mon Apr 19 06:47:14 2010 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Mon, 19 Apr 2010 04:47:14 +0000 (GMT) Subject: [M3devel] INTEGER In-Reply-To: <20100418195901.CDACB1A20F6@async.async.caltech.edu> Message-ID: <141192.73575.qm@web23603.mail.ird.yahoo.com> Hi: I think the irrelevant point is arguable as there are SIMD instructions of 128-bit and later will be 256-bit packed types registers so the point of becoming irrelevant could be worrisome in time, probably not now. As packed types weren't to traumatic but are more needed now by this fact. If you wish more generality, a language change will be needed, not an extension, language extensions are easily doable with enough knowledge but right now you would need to do it or it will become harder and harder to reconstruct your own code. If you need backward compatibility why don't host cm3 with pm3, that is old cm3 can't compile cm3 but its negative inverse is true and it is old known old cm3 can build pm3 and src m3 (current cm3 built itself as I saw with RC5 on AMD64_LINUX). Still you want to host other older environments look for doing it with CM3, I think it wouldn't be so much traumatic, wouldn't it? You would compile and have two different runtime but you could do what you want to do, as I guess you were doing for other reasons and it wouldn't be so much effort to do it, maybe the ugly parts would be system dependent things as I think. I think there are many other options as to be backwards compatible like drop new features or build against other specific libraries, but again is not that the purpose you are looking for, then is simpler if you think the above intention in some sense to you? It's just an idea, hope it helps something. --- El dom, 18/4/10, Mika Nystrom escribi?: > De: Mika Nystrom > Asunto: Re: [M3devel] INTEGER > Para: "Tony Hosking" > CC: m3devel at elegosoft.com > Fecha: domingo, 18 de abril, 2010 14:59 > > My problem is really just that it's ugly. LONGx is > showing up as an issue > in all sorts of low-level code, which is not surprising > since Modula-3 > with LONGx is not the same language as Modula-3 (maybe we > should call > it Modula-3+?) > > The compiler bootstrapping process has gotten more > complicated due to it, > and when I cvs updated m3tk yesterday stubgen wouldn't > compile because there > was something "long" in it that wasn't there before. > I have no idea what > library or components I needed to update and recompile and > didn't have the > time to deal with the issue at the time. > > And the new m3tk, stubgen, and compiler(?) won't compile > using PM3 or > SRC M3 since we're no longer using the language of the > Green Book. > (Same comment goes for WIDECHAR, by the way.) > > One of the wonderful things about Modula-3 *used to be* > that I could > grab some old package from DECSRC and just use it without > changes since > no one had messed with the language definition. This > is still true as > far as programs that just use the tools go, but it's no > longer true for > programs that process Modula-3 code as input data. Of > which there are > more than a few: many aspects of Modula-3 were specifically > designed to > make the language easy to process by program, as an > intermediate format > and whatnot. > > To quote E.W.D.: > > 'Unfathomed misunderstanding is further revealed by the > term "software > maintenance", as a result of which many people continue to > believe that > programs and even programming languages themselves are > subject to wear > and tear. Your car needs maintenance too, doesn't it? > Famous is the story > of the oil company that believed that its PASCAL programs > did not last > as long as its FORTRAN programs "because PASCAL was not > maintained".' > > LONGx is causing me to have to do "software maintenance" on > Modula-3 > programs... for a feature that no one appears to be using > and is quickly > becoming irrelevant. > > Mika > > > Tony Hosking writes: > >In the language spec NUMBER(a) and LAST(a) - FIRST(a) + > 1 are *not* = > >defined to mean the same thing for all types. > >NUMBER does have an INTEGER value, as expected for > subranges of LONGINT = > >that are not too large. > >This is as it has always been for subranges of INTEGER > that are not too = > >large. > > > >Mika, I'm not sure I see any of the problems you are > worrying about in = > >the current definition of LONGINT/LONGCARD. > > > >On 18 Apr 2010, at 03:49, Mika Nystrom wrote: > > > >>=20 > >> Jay I know most of this, and it doesn't really > answer the question > >> "what is it for?" > >>=20 > >> I think we've already established that LONGINT > isn't useful for = > >counting > >> anything that might actually reside in the > computer's memory: it makes > >> no sense as an array index, for instance. > INTEGER suffices for that. > >>=20 > >> I thought that the only real reason for LONGINT > was to match C's > >> declaration of various seek-related routines on > 32-bit machines. > >> That's not a very good reason. > >>=20 > >> C++ succeeds because it does very well in the > area(s) it is good at. > >> People who want to program in C++ will clearly > program in C++, not > >> Modula-3. Modula-3 is never, ever going to > be the language of choice = > >for > >> people who want lots of snazzy infix > operators. Modula-3 is supposed = > >to > >> be a language with about as powerful semantics as > C++ and an extremely > >> simple syntax and definition---snazzy infix is one > of the things you > >> give up for that. I don't see how LONGINT > fits into this picture. > >> Now we have LONGCARD too? And it's infected > the definitions > >> of FIRST and LAST? But not NUMBER... argh! > >>=20 > >> so, > >>=20 > >> NUMBER(a) and LAST(a) - FIRST(a) + 1 > >>=20 > >> no longer mean the same thing? Are we going > to see lots of comments > >> in generics in the future where it says T may not > be an open array > >> type nor an array type indexed on LONGINT or a > subrange thereof? > >>=20 > >> Your comments about different parameter-passing > techniques was what I = > >was > >> trying to address with my suggestion to have a > pragma for this---just = > >to > >> match C (and Fortran?), of course. Name me a > single Modula-3 = > >programmer > >> who cares in what order the bits in his parameters > are pushed on the > >> stack in a Modula-3-to-Modula-3 call. > >>=20 > >> And I am definitely in that school of thought that > says that = > >programming > >> languages should not "evolve". Better to > leave well enough alone. > >>=20 > >> How much Modula-3 code has been written that uses > LONGINT? Other than > >> to talk to C? I've certainly never used it. > >>=20 > >> Mika > >>=20 > >>=20 > >>=20 > >> Jay K writes: > >>> --_264cb69b-0215-44c3-807c-8b4d8ea0ea59_ > >>> Content-Type: text/plain; > charset=3D"iso-8859-1" > >>> Content-Transfer-Encoding: quoted-printable > >>>=20 > >>>=20 > >>> TYPE LONGINT =3D3D ARRAY [0..1] OF INTEGER on > a 32bit system is very = > >close to=3D > >>> LONGINT. > >>>=20 > >>> Plus treating it opaquely and providing a > bunch of functions to = > >operate on=3D > >>> it. > >>>=20 > >>> Just as well therefore could be RECORD > hi=3D2Clo:LONGINT END (see = > >LARGE_INTE=3D > >>> GER and ULARGE_INTEGER in winnt.h) > >>>=20 > >>> =3D20 > >>>=20 > >>> Differences that come to mind: > >>>=20 > >>> infix operators > <=3D3D=3D3D=3D3D=3D20 > >>>=20 > >>> possibly passed differently as a parameter > >>>=20 > >>> or returned differently as a result > >>>=20 > >>> ie. probably "directly compatible with" "long > long"=3D2C passed by = > >value (o=3D > >>> f course you could always pass by pointer and > achieve compatibilitity = > >trivi=3D > >>> ally) > >>>=20 > >>> =3D20 > >>>=20 > >>> =3D20 > >>>=20 > >>> I have to say though=3D2C the biggest reason > is in-fix operators. = > >Convenient =3D > >>> syntax. > >>>=20 > >>> C++ is the best and some way worst of example > of the general right = > >way to d=3D > >>> o this -- you let programmers define types and > their infix operators. = > >Other=3D > >>> languages just come with a passle of special > cases of types that have = > >in-f=3D > >>> ix operators. > >>>=20 > >>> A good example is that Java infix operator + > on string=3D2C besides = > >the vario=3D > >>> us integers=3D2C and nothing else. > >>>=20 > >>> =3D20 > >>>=20 > >>> =3D20 > >>>=20 > >>> I think C# lets you define operators=3D2C yet > people don't complain = > >that it i=3D > >>> s "a mess" as they do of C++. > >>>=20 > >>> I think Python does now too. > >>>=20 > >>> So it is feature growing in popularity among > "mainstream" = > >languages=3D2C not =3D > >>> just C++. > >>>=20 > >>> C++ of course is extremely > mainstream=3D2C but also a favorite = > >target. (ht=3D > >>> tp://www.relisoft.com/tools/CppCritic.html) > >>>=20 > >>> =3D20 > >>>=20 > >>> =3D20 > >>>=20 > >>> We also have subranges of LONGINT. > >>>=20 > >>> I'm not sure what the generalization of > subranges are=3D2C granted. > >>>=20 > >>> Maybe some sort of C++ template that takes > constants in the template = > >and d=3D > >>> oes range checks at runtime. Yeah=3D2C maybe. > >>>=20 > >>> =3D20 > >>>=20 > >>> =3D20 > >>>=20 > >>> And as you point out=3D2C convenient literal > syntax. > >>>=20 > >>> =3D20 > >>>=20 > >>> =3D20 > >>>=20 > >>> People reasonably argue for library extension > in place of language = > >extensio=3D > >>> n=3D2C but that requires a language which is > flexible enough to write = > >librari=3D > >>> es with the desired interface=3D2C and so many > languages don't let = > >infix oper=3D > >>> ators be in a user-written library. > >>>=20 > >>> (There is a subtle but useless distinction > here -- infix operators = > >being in=3D > >>> libraries vs. "user-written" libraries. The > infix set operations for = > >examp=3D > >>> le are in a library=3D2C but not > user-written=3D2C special=3D2C the = > >compiler know=3D > >>> s about it.) > >>>=20 > >>> =3D20 > >>>=20 > >>>> that would perhaps not match how C handles > "long long" on the same > >>>> platform (which is how=3D2C come to think > of it?)=3D2C and that = > >would require > >>>=20 > >>>=20 > >>> =3D20 > >>>=20 > >>> On NT/x86=3D2C __int64/long long is returned > in the register pair = > >edx:eax. > >>>=20 > >>> edx is high=3D2C eax is low. > >>>=20 > >>> When passed as a parameter to __stdcall or > __cdecl is just passed as = > >two 32=3D > >>> bit values adjacent on the stack=3D2C "hi=3D2C > lo=3D2C hi=3D2C lo=3D2C = > >it's off to pu=3D > >> sh we go" is the Snow White-influenced mantra to > remember how to pass = > >them=3D > >>> =3D2C at least on little endian > stack-growing-down machines (which = > >includes x=3D > >>> 86). For __fastcall I'm not sure they are > passed in registers or on = > >the sta=3D > >>> ck. > >>>=20 > >>> Passing and/or returning small structs also > has special efficient = > >handling =3D > >>> in the ABI=3D2C so __int64 really might be > equivalent to a small = > >record. Not =3D > >>> that cm3 necessarily implements that > "correctly" -- for interop with = > >C=3D3B =3D > >>> for Modula-3 calling Modula-3 we can make up > our own ABI so there = > >isn't rea=3D > >>> lly an "incorrect" way. Notice the mingw > problem I had passing a = > >Win32 poin=3D > >>> t struct by value=3D2C I cheated and passed it > by VAR to a C wrapper = > >to worka=3D > >>> round the gcc backend bug (which was mentioned > a few times and which = > >I look=3D > >>> ed into the code for=3D2C but took the easy > route) > >>>=20 > >>> =3D20 > >>>=20 > >>> =3D20 > >>>=20 > >>> I don't know how long long works on other > platforms but probably = > >similar. > >>>=20 > >>> Probably a certain register pair for return > values. > >>>=20 > >>> =3D20 > >>>=20 > >>> - Jay > >>>=20 > >>> =3D20 > >>>> To: hosking at cs.purdue.edu > >>>> Date: Sat=3D2C 17 Apr 2010 19:47:03 -0700 > >>>> From: mika at async.async.caltech.edu > >>>> CC: m3devel at elegosoft.com > >>>> Subject: Re: [M3devel] INTEGER > >>>> =3D20 > >>>> Tony Hosking writes: > >>>>>=20 > >>>> ... > >>>>>=20 > >>>>>> We need it to match 64-bit > integers on 32-bit machines? That seems = > >=3D3D > >>>>> like > >>>>>> a very weak rationale indeed=3D2C > if the same functionality could = > >be =3D3D > >>>>> provided > >>>>>> through some other mechanism > (e.g.=3D2C ARRAY [0..1] OF = > >INTEGER---even =3D > >>> =3D3D > >>>>> with > >>>>>> a pragma e.g. > <*CLONGLONG*>.. if it is necessary to tell the = > >compiler =3D > >>> =3D3D > >>>>> that > >>>>>> a special linkage convention is > needed). > >>>>>=20 > >>>>> There's no special linkage convention. > Not sure what you mean here. > >>>>>=20 > >>>> =3D20 > >>>> I just mean if we had > >>>> =3D20 > >>>> TYPE LONGINT =3D3D ARRAY [0..1] OF > INTEGER > >>>> =3D20 > >>>> that would perhaps not match how C handles > "long long" on the same > >>>> platform (which is how=3D2C come to think > of it?)=3D2C and that = > >would require > >>>> special linkage tricks. > >>>> =3D20 > >>>> But what would be lost? The ability to > type literals.=3D20 > >>>> =3D20 > >>>> You could get the same code interface on > 32- and 64-bit machine by > >>>> defining > >>>> =3D20 > >>>> TYPE FileOffset =3D3D ARRAY[0..1] OF > [-16_80000000 .. +16_7fffffff ] > >>>> =3D20 > >>>> and using that. > >>>> =3D20 > >>>> =3D20 > >>>> Mika > >>> > > > =3D > >>>=20 > >>> --_264cb69b-0215-44c3-807c-8b4d8ea0ea59_ > >>> Content-Type: text/html; > charset=3D"iso-8859-1" > >>> Content-Transfer-Encoding: quoted-printable > >>>=20 > >>> > >>> > >>> > >>> > >>> > >>> TYPE LONGINT =3D3D ARRAY [0..1] OF INTEGER on > a =3D3B32bit system = > >is very c=3D > >>> lose to LONGINT.
> >>>  =3D3BPlus treating it opaquely and > providing a bunch of = > >functions to ope=3D > >>> rate on it.
> >>>  =3D3BJust as well therefore could be > RECORD hi=3D2Clo:LONGINT = > >END (see LAR=3D > >>> GE_INTEGER and ULARGE_INTEGER in > winnt.h)
> >>>  =3D3B
> >>> Differences that come to mind:
> >>>  =3D3B =3D3Binfix > operators =3D3B <=3D3B=3D3D=3D3D=3D3D = > >
> >>>  =3D3B possibly passed > differently =3D3Bas a parameter
> >>>  =3D3B or returned differently as a > result
> >>>  =3D3B ie. probably "directly > compatible with" "long long"=3D2C = > >passed by v=3D > >>> alue (of course you could always pass by > pointer and achieve = > >compatibilitit=3D > >>> y trivially)
> >>>  =3D3B
> >>>  =3D3B
> >>> I have to say though=3D2C the biggest reason > is in-fix operators. = > >Convenient =3D > >>> syntax.
> >>> C++ is the best and some way worst of example > of the general right = > >way to d=3D > >>> o this -- you let programmers define types and > their infix operators. = > >Other=3D > >>> languages just come with a passle of special > cases of types that have = > >in-f=3D > >>> ix operators.
> >>> A good example is that Java infix operator + > on string=3D2C besides = > >the vario=3D > >>> us integers=3D2C and nothing else.
> >>>  =3D3B
> >>>  =3D3B
> >>> I think C# lets you define operators=3D2C yet > people don't complain = > >that it i=3D > >>> s "a mess" as they do of C++.
> >>> I think Python does now too.
> >>> So it is feature growing in popularity among > "mainstream" = > >languages=3D2C not =3D > >>> just C++.
> >>>  =3D3B =3D3B C++ of course is > extremely mainstream=3D2C but = > >also a favori=3D > >>> te target. ( >href=3D3D"http://www.relisoft.com/tools/CppCritic.html">http:/=3D > >>> > /www.relisoft.com/tools/CppCritic.html)
> >>>  =3D3B
> >>>  =3D3B
> >>> We also have subranges of LONGINT.
> >>> I'm not sure what the generalization of > subranges are=3D2C = > >granted.
> >>>  =3D3BMaybe some sort of C++ template > that takes constants in the = > >templat=3D > >>> e and does range checks at runtime. Yeah=3D2C > maybe.
> >>>  =3D3B
> >>>  =3D3B
> >>> And as you point out=3D2C convenient literal > syntax.
> >>>  =3D3B
> >>>  =3D3B
> >>> People reasonably argue for library extension > in place of language = > >extensio=3D > >>> n=3D2C but that requires a language which is > flexible enough to write = > >librari=3D > >>> es with the desired interface=3D2C and so many > languages don't let = > >infix oper=3D > >>> ators be in a user-written library.
> >>> (There is a subtle but useless distinction > here -- infix operators = > >being in=3D > >>> libraries vs. "user-written" libraries. The > infix set operations for = > >examp=3D > >>> le are in a library=3D2C but not > user-written=3D2C special=3D2C the = > >compiler know=3D > >>> s about it.)
> >>>  =3D3B
> >>> >=3D3B that would perhaps not match how > C handles "long long" on = > >the same >>> R>>=3D3B platform (which is how=3D2C > come to think of it?)=3D2C and = > >that would =3D > >>> require

> >>>  =3D3B
> >>> On NT/x86=3D2C __int64/long long is returned > in the register pair = > >edx:eax. >>>>=20 > >>> edx is high=3D2C eax is low.
> >>> When passed as a parameter to __stdcall or > __cdecl is just passed as = > >two 32=3D > >>> bit values adjacent on the stack=3D2C "hi=3D2C > lo=3D2C hi=3D2C lo=3D2C = > >it's off to pu=3D > >>> sh we go" is the Snow White-influenced mantra > to remember how to pass = > >them=3D > >>> =3D2C at least on little endian > stack-growing-down machines (which = > >includes x=3D > >>> 86). For __fastcall I'm not sure they are > passed in registers or on = > >the sta=3D > >>> ck.
> >>> Passing and/or returning small structs also > has special efficient = > >handling =3D > >>> in the ABI=3D2C so __int64 really might be > equivalent to a small = > >record. Not =3D > >>> that cm3 necessarily implements that > "correctly" =3D3B -- for = > >interop wit=3D > >>> h C=3D3B for Modula-3 calling Modula-3 we can > make up our own ABI so = > >there is=3D > >>> n't =3D3Breally an "incorrect" > way. =3D3BNotice the mingw = > >problem I had=3D > >>> passing a Win32 point struct by value=3D2C I > cheated and passed it by = > >VAR to=3D > >>> a =3D3BC wrapper to workaround the gcc > backend bug (which was = > >mentioned =3D > >>> a few times and which I looked into the code > for=3D2C but took the = > >easy route=3D > >>> )
> >>>  =3D3B
> >>>  =3D3B
> >>> I don't know how long long works on other > platforms but probably = > >similar. >>> R> > >>> Probably a certain register pair for return > values.
> >>>  =3D3B
> >>>  =3D3B- > Jay

 =3D3B
>=3D3B > To: = > >hosking at cs.purdue.edu
>=3D3B=3D > >>> Date: Sat=3D2C 17 Apr 2010 19:47:03 > -0700
>=3D3B From: = > >mika at async.async.c=3D > >>> altech.edu
>=3D3B CC: m3devel at elegosoft.com
>=3D3B > Subject: = > >Re: [M3de=3D > >>> vel] INTEGER
>=3D3B >
>=3D3B Tony Hosking > writes:
>=3D3B = > >>=3D3B
=3D > >>> >=3D3B ...
>=3D3B > >=3D3B
>=3D3B >=3D3B>=3D3B > We = > >need it to match 64-b=3D > >>> it integers on 32-bit machines? That seems > =3D3D
>=3D3B = > >>=3D3Blike
>=3D > >>> =3D3B >=3D3B>=3D3B a very weak > rationale indeed=3D2C if the same = > >functionality =3D > >>> could be =3D3D
>=3D3B > >=3D3Bprovided
>=3D3B > >=3D3B>=3D3= > >B through some o=3D > >>> ther mechanism (e.g.=3D2C ARRAY [0..1] OF > INTEGER---even = > >=3D3D
>=3D3B >=3D3B=3D > >>> with
>=3D3B > >=3D3B>=3D3B a pragma e.g. = > ><=3D3B*CLONGLONG*>=3D3B.. if it i=3D > >>> s necessary to tell the compiler > =3D3D
>=3D3B = > >>=3D3Bthat
>=3D3B > >=3D3B&=3D > >>> gt=3D3B a special linkage convention is > needed).
>=3D3B = > >>=3D3B
>=3D3B &=3D > >>> gt=3D3BThere's no special linkage convention. > Not sure what you mean = > >here. >>>> >=3D3B > >=3D3B
>=3D3B
>=3D3B I > just mean if we = > >had
>=3D3B
>=3D > >>> =3D3B TYPE LONGINT =3D3D ARRAY [0..1] OF > INTEGER
>=3D3B = > >
>=3D3B that woul=3D > >>> d perhaps not match how C handles "long long" > on the same
>=3D3B = > >platfor=3D > >>> m (which is how=3D2C come to think of > it?)=3D2C and that would = > >require
>=3D > >>> =3D3B special linkage > tricks.
>=3D3B
>=3D3B But > what would = > >be lost? Th=3D > >>> e ability to type literals. >
>=3D3B
>=3D3B You could get > = > >the same co=3D > >>> de interface on 32- and 64-bit machine > by
>=3D3B = > >defining
>=3D3B
=3D > >>> >=3D3B TYPE FileOffset =3D3D ARRAY[0..1] > OF [-16_80000000 .. = > >+16_7fffffff ] >>> R>>=3D3B
>=3D3B and > using that.
>=3D3B
>=3D3B = > >
>=3D3B Mika >>>> > > > > >>> =3D > >>>=20 > >>> --_264cb69b-0215-44c3-807c-8b4d8ea0ea59_-- > From jay.krell at cornell.edu Mon Apr 19 06:43:54 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 19 Apr 2010 04:43:54 +0000 Subject: [M3devel] Posix < 0 vs. # 0 vs. = -1? In-Reply-To: References: , Message-ID: > much cheaper Ah. I hadn't considered that. It looks like we might gain commonality in socket code though by checking for a specific value. C:\dev2\cm3.2\m3-libs\m3core\src\win32\WinSock.i3(293): SOCKET_ERROR = -1; - Jay From: hosking at cs.purdue.edu Date: Sun, 18 Apr 2010 15:09:00 -0400 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] Posix < 0 vs. # 0 vs. = -1? Checking < 0 is much cheaper than checking = -1. C idioms typically check < 0. -1 is simply a convenient negative value to return. Leave it as is. On 18 Apr 2010, at 09:57, Jay K wrote: Posix often says: function foo() returns 0 for success, -1 for error m3core/libm3/etc, often say if foo() < 0 or if foo() # 0 "instead". Generally ok to tighten these up to "= -1", perhaps upon checking manpages, or a known rat's nest of inconsistencies? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Apr 19 08:54:09 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 19 Apr 2010 06:54:09 +0000 Subject: [M3devel] INTEGER In-Reply-To: <141192.73575.qm@web23603.mail.ird.yahoo.com> References: <20100418195901.CDACB1A20F6@async.async.caltech.edu>, <141192.73575.qm@web23603.mail.ird.yahoo.com> Message-ID: I believe the 128bit and 256bit types are implemented with compiler extensions but not language extensions. They declare records and "functions", but the compilers implement the "functions" inline (roughly one instruction each). This is akin to interface Word and generic interface Atomic. They are "just" libraries from a language point of view, but the compiler knows about them and inlines them. Well, at least the "packed" types. There are larger "scalar" types coming? That support infix operators? Again, so far as we have all figured out (I'm guessing and building on a hint Mika provided), it is mostly just about literals and infix notation. And if that is the case, it really shows that a language ought to be a bit more flexible in the first place (user defined infix operators on user defined types), and then it won't need as much extending later on. Nobody really prefers "Word.Plus(a, b)" over "a + b"... - Jay > Date: Mon, 19 Apr 2010 04:47:14 +0000 > From: dabenavidesd at yahoo.es > To: hosking at cs.purdue.edu; mika at async.async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] INTEGER > > Hi: > I think the irrelevant point is arguable as there are SIMD instructions of 128-bit and later will be 256-bit packed types registers so the point of becoming irrelevant could be worrisome in time, probably not now. As packed types weren't to traumatic but are more needed now by this fact. > If you wish more generality, a language change will be needed, not an extension, language extensions are easily doable with enough knowledge but right now you would need to do it or it will become harder and harder to reconstruct your own code. If you need backward compatibility why don't host cm3 with pm3, that is old cm3 can't compile cm3 but its negative inverse is true and it is old known old cm3 can build pm3 and src m3 (current cm3 built itself as I saw with RC5 on AMD64_LINUX). Still you want to host other older environments look for doing it with CM3, I think it wouldn't be so much traumatic, wouldn't it? You would compile and have two different runtime but you could do what you want to do, as I guess you were doing for other reasons and it wouldn't be so much effort to do it, maybe the ugly parts would be system dependent things as I think. > I think there are many other options as to be backwards compatible like drop new features or build against other specific libraries, but again is not that the purpose you are looking for, then is simpler if you think the above intention in some sense to you? > It's just an idea, hope it helps something. > > --- El dom, 18/4/10, Mika Nystrom escribi?: > > > De: Mika Nystrom > > Asunto: Re: [M3devel] INTEGER > > Para: "Tony Hosking" > > CC: m3devel at elegosoft.com > > Fecha: domingo, 18 de abril, 2010 14:59 > > > > My problem is really just that it's ugly. LONGx is > > showing up as an issue > > in all sorts of low-level code, which is not surprising > > since Modula-3 > > with LONGx is not the same language as Modula-3 (maybe we > > should call > > it Modula-3+?) > > > > The compiler bootstrapping process has gotten more > > complicated due to it, > > and when I cvs updated m3tk yesterday stubgen wouldn't > > compile because there > > was something "long" in it that wasn't there before. > > I have no idea what > > library or components I needed to update and recompile and > > didn't have the > > time to deal with the issue at the time. > > > > And the new m3tk, stubgen, and compiler(?) won't compile > > using PM3 or > > SRC M3 since we're no longer using the language of the > > Green Book. > > (Same comment goes for WIDECHAR, by the way.) > > > > One of the wonderful things about Modula-3 *used to be* > > that I could > > grab some old package from DECSRC and just use it without > > changes since > > no one had messed with the language definition. This > > is still true as > > far as programs that just use the tools go, but it's no > > longer true for > > programs that process Modula-3 code as input data. Of > > which there are > > more than a few: many aspects of Modula-3 were specifically > > designed to > > make the language easy to process by program, as an > > intermediate format > > and whatnot. > > > > To quote E.W.D.: > > > > 'Unfathomed misunderstanding is further revealed by the > > term "software > > maintenance", as a result of which many people continue to > > believe that > > programs and even programming languages themselves are > > subject to wear > > and tear. Your car needs maintenance too, doesn't it? > > Famous is the story > > of the oil company that believed that its PASCAL programs > > did not last > > as long as its FORTRAN programs "because PASCAL was not > > maintained".' > > > > LONGx is causing me to have to do "software maintenance" on > > Modula-3 > > programs... for a feature that no one appears to be using > > and is quickly > > becoming irrelevant. > > > > Mika > > > > > > Tony Hosking writes: > > >In the language spec NUMBER(a) and LAST(a) - FIRST(a) + > > 1 are *not* = > > >defined to mean the same thing for all types. > > >NUMBER does have an INTEGER value, as expected for > > subranges of LONGINT = > > >that are not too large. > > >This is as it has always been for subranges of INTEGER > > that are not too = > > >large. > > > > > >Mika, I'm not sure I see any of the problems you are > > worrying about in = > > >the current definition of LONGINT/LONGCARD. > > > > > >On 18 Apr 2010, at 03:49, Mika Nystrom wrote: > > > > > >>=20 > > >> Jay I know most of this, and it doesn't really > > answer the question > > >> "what is it for?" > > >>=20 > > >> I think we've already established that LONGINT > > isn't useful for = > > >counting > > >> anything that might actually reside in the > > computer's memory: it makes > > >> no sense as an array index, for instance. > > INTEGER suffices for that. > > >>=20 > > >> I thought that the only real reason for LONGINT > > was to match C's > > >> declaration of various seek-related routines on > > 32-bit machines. > > >> That's not a very good reason. > > >>=20 > > >> C++ succeeds because it does very well in the > > area(s) it is good at. > > >> People who want to program in C++ will clearly > > program in C++, not > > >> Modula-3. Modula-3 is never, ever going to > > be the language of choice = > > >for > > >> people who want lots of snazzy infix > > operators. Modula-3 is supposed = > > >to > > >> be a language with about as powerful semantics as > > C++ and an extremely > > >> simple syntax and definition---snazzy infix is one > > of the things you > > >> give up for that. I don't see how LONGINT > > fits into this picture. > > >> Now we have LONGCARD too? And it's infected > > the definitions > > >> of FIRST and LAST? But not NUMBER... argh! > > >>=20 > > >> so, > > >>=20 > > >> NUMBER(a) and LAST(a) - FIRST(a) + 1 > > >>=20 > > >> no longer mean the same thing? Are we going > > to see lots of comments > > >> in generics in the future where it says T may not > > be an open array > > >> type nor an array type indexed on LONGINT or a > > subrange thereof? > > >>=20 > > >> Your comments about different parameter-passing > > techniques was what I = > > >was > > >> trying to address with my suggestion to have a > > pragma for this---just = > > >to > > >> match C (and Fortran?), of course. Name me a > > single Modula-3 = > > >programmer > > >> who cares in what order the bits in his parameters > > are pushed on the > > >> stack in a Modula-3-to-Modula-3 call. > > >>=20 > > >> And I am definitely in that school of thought that > > says that = > > >programming > > >> languages should not "evolve". Better to > > leave well enough alone. > > >>=20 > > >> How much Modula-3 code has been written that uses > > LONGINT? Other than > > >> to talk to C? I've certainly never used it. > > >>=20 > > >> Mika > > >>=20 > > >>=20 > > >>=20 > > >> Jay K writes: > > >>> --_264cb69b-0215-44c3-807c-8b4d8ea0ea59_ > > >>> Content-Type: text/plain; > > charset=3D"iso-8859-1" > > >>> Content-Transfer-Encoding: quoted-printable > > >>>=20 > > >>>=20 > > >>> TYPE LONGINT =3D3D ARRAY [0..1] OF INTEGER on > > a 32bit system is very = > > >close to=3D > > >>> LONGINT. > > >>>=20 > > >>> Plus treating it opaquely and providing a > > bunch of functions to = > > >operate on=3D > > >>> it. > > >>>=20 > > >>> Just as well therefore could be RECORD > > hi=3D2Clo:LONGINT END (see = > > >LARGE_INTE=3D > > >>> GER and ULARGE_INTEGER in winnt.h) > > >>>=20 > > >>> =3D20 > > >>>=20 > > >>> Differences that come to mind: > > >>>=20 > > >>> infix operators > > <=3D3D=3D3D=3D3D=3D20 > > >>>=20 > > >>> possibly passed differently as a parameter > > >>>=20 > > >>> or returned differently as a result > > >>>=20 > > >>> ie. probably "directly compatible with" "long > > long"=3D2C passed by = > > >value (o=3D > > >>> f course you could always pass by pointer and > > achieve compatibilitity = > > >trivi=3D > > >>> ally) > > >>>=20 > > >>> =3D20 > > >>>=20 > > >>> =3D20 > > >>>=20 > > >>> I have to say though=3D2C the biggest reason > > is in-fix operators. = > > >Convenient =3D > > >>> syntax. > > >>>=20 > > >>> C++ is the best and some way worst of example > > of the general right = > > >way to d=3D > > >>> o this -- you let programmers define types and > > their infix operators. = > > >Other=3D > > >>> languages just come with a passle of special > > cases of types that have = > > >in-f=3D > > >>> ix operators. > > >>>=20 > > >>> A good example is that Java infix operator + > > on string=3D2C besides = > > >the vario=3D > > >>> us integers=3D2C and nothing else. > > >>>=20 > > >>> =3D20 > > >>>=20 > > >>> =3D20 > > >>>=20 > > >>> I think C# lets you define operators=3D2C yet > > people don't complain = > > >that it i=3D > > >>> s "a mess" as they do of C++. > > >>>=20 > > >>> I think Python does now too. > > >>>=20 > > >>> So it is feature growing in popularity among > > "mainstream" = > > >languages=3D2C not =3D > > >>> just C++. > > >>>=20 > > >>> C++ of course is extremely > > mainstream=3D2C but also a favorite = > > >target. (ht=3D > > >>> tp://www.relisoft.com/tools/CppCritic.html) > > >>>=20 > > >>> =3D20 > > >>>=20 > > >>> =3D20 > > >>>=20 > > >>> We also have subranges of LONGINT. > > >>>=20 > > >>> I'm not sure what the generalization of > > subranges are=3D2C granted. > > >>>=20 > > >>> Maybe some sort of C++ template that takes > > constants in the template = > > >and d=3D > > >>> oes range checks at runtime. Yeah=3D2C maybe. > > >>>=20 > > >>> =3D20 > > >>>=20 > > >>> =3D20 > > >>>=20 > > >>> And as you point out=3D2C convenient literal > > syntax. > > >>>=20 > > >>> =3D20 > > >>>=20 > > >>> =3D20 > > >>>=20 > > >>> People reasonably argue for library extension > > in place of language = > > >extensio=3D > > >>> n=3D2C but that requires a language which is > > flexible enough to write = > > >librari=3D > > >>> es with the desired interface=3D2C and so many > > languages don't let = > > >infix oper=3D > > >>> ators be in a user-written library. > > >>>=20 > > >>> (There is a subtle but useless distinction > > here -- infix operators = > > >being in=3D > > >>> libraries vs. "user-written" libraries. The > > infix set operations for = > > >examp=3D > > >>> le are in a library=3D2C but not > > user-written=3D2C special=3D2C the = > > >compiler know=3D > > >>> s about it.) > > >>>=20 > > >>> =3D20 > > >>>=20 > > >>>> that would perhaps not match how C handles > > "long long" on the same > > >>>> platform (which is how=3D2C come to think > > of it?)=3D2C and that = > > >would require > > >>>=20 > > >>>=20 > > >>> =3D20 > > >>>=20 > > >>> On NT/x86=3D2C __int64/long long is returned > > in the register pair = > > >edx:eax. > > >>>=20 > > >>> edx is high=3D2C eax is low. > > >>>=20 > > >>> When passed as a parameter to __stdcall or > > __cdecl is just passed as = > > >two 32=3D > > >>> bit values adjacent on the stack=3D2C "hi=3D2C > > lo=3D2C hi=3D2C lo=3D2C = > > >it's off to pu=3D > > >> sh we go" is the Snow White-influenced mantra to > > remember how to pass = > > >them=3D > > >>> =3D2C at least on little endian > > stack-growing-down machines (which = > > >includes x=3D > > >>> 86). For __fastcall I'm not sure they are > > passed in registers or on = > > >the sta=3D > > >>> ck. > > >>>=20 > > >>> Passing and/or returning small structs also > > has special efficient = > > >handling =3D > > >>> in the ABI=3D2C so __int64 really might be > > equivalent to a small = > > >record. Not =3D > > >>> that cm3 necessarily implements that > > "correctly" -- for interop with = > > >C=3D3B =3D > > >>> for Modula-3 calling Modula-3 we can make up > > our own ABI so there = > > >isn't rea=3D > > >>> lly an "incorrect" way. Notice the mingw > > problem I had passing a = > > >Win32 poin=3D > > >>> t struct by value=3D2C I cheated and passed it > > by VAR to a C wrapper = > > >to worka=3D > > >>> round the gcc backend bug (which was mentioned > > a few times and which = > > >I look=3D > > >>> ed into the code for=3D2C but took the easy > > route) > > >>>=20 > > >>> =3D20 > > >>>=20 > > >>> =3D20 > > >>>=20 > > >>> I don't know how long long works on other > > platforms but probably = > > >similar. > > >>>=20 > > >>> Probably a certain register pair for return > > values. > > >>>=20 > > >>> =3D20 > > >>>=20 > > >>> - Jay > > >>>=20 > > >>> =3D20 > > >>>> To: hosking at cs.purdue.edu > > >>>> Date: Sat=3D2C 17 Apr 2010 19:47:03 -0700 > > >>>> From: mika at async.async.caltech.edu > > >>>> CC: m3devel at elegosoft.com > > >>>> Subject: Re: [M3devel] INTEGER > > >>>> =3D20 > > >>>> Tony Hosking writes: > > >>>>>=20 > > >>>> ... > > >>>>>=20 > > >>>>>> We need it to match 64-bit > > integers on 32-bit machines? That seems = > > >=3D3D > > >>>>> like > > >>>>>> a very weak rationale indeed=3D2C > > if the same functionality could = > > >be =3D3D > > >>>>> provided > > >>>>>> through some other mechanism > > (e.g.=3D2C ARRAY [0..1] OF = > > >INTEGER---even =3D > > >>> =3D3D > > >>>>> with > > >>>>>> a pragma e.g. > > <*CLONGLONG*>.. if it is necessary to tell the = > > >compiler =3D > > >>> =3D3D > > >>>>> that > > >>>>>> a special linkage convention is > > needed). > > >>>>>=20 > > >>>>> There's no special linkage convention. > > Not sure what you mean here. > > >>>>>=20 > > >>>> =3D20 > > >>>> I just mean if we had > > >>>> =3D20 > > >>>> TYPE LONGINT =3D3D ARRAY [0..1] OF > > INTEGER > > >>>> =3D20 > > >>>> that would perhaps not match how C handles > > "long long" on the same > > >>>> platform (which is how=3D2C come to think > > of it?)=3D2C and that = > > >would require > > >>>> special linkage tricks. > > >>>> =3D20 > > >>>> But what would be lost? The ability to > > type literals.=3D20 > > >>>> =3D20 > > >>>> You could get the same code interface on > > 32- and 64-bit machine by > > >>>> defining > > >>>> =3D20 > > >>>> TYPE FileOffset =3D3D ARRAY[0..1] OF > > [-16_80000000 .. +16_7fffffff ] > > >>>> =3D20 > > >>>> and using that. > > >>>> =3D20 > > >>>> =3D20 > > >>>> Mika > > >>> > > > > > > =3D > > >>>=20 > > >>> --_264cb69b-0215-44c3-807c-8b4d8ea0ea59_ > > >>> Content-Type: text/html; > > charset=3D"iso-8859-1" > > >>> Content-Transfer-Encoding: quoted-printable > > >>>=20 > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> TYPE LONGINT =3D3D ARRAY [0..1] OF INTEGER on > > a =3D3B32bit system = > > >is very c=3D > > >>> lose to LONGINT.
> > >>>  =3D3BPlus treating it opaquely and > > providing a bunch of = > > >functions to ope=3D > > >>> rate on it.
> > >>>  =3D3BJust as well therefore could be > > RECORD hi=3D2Clo:LONGINT = > > >END (see LAR=3D > > >>> GE_INTEGER and ULARGE_INTEGER in > > winnt.h)
> > >>>  =3D3B
> > >>> Differences that come to mind:
> > >>>  =3D3B =3D3Binfix > > operators =3D3B <=3D3B=3D3D=3D3D=3D3D = > > >
> > >>>  =3D3B possibly passed > > differently =3D3Bas a parameter
> > >>>  =3D3B or returned differently as a > > result
> > >>>  =3D3B ie. probably "directly > > compatible with" "long long"=3D2C = > > >passed by v=3D > > >>> alue (of course you could always pass by > > pointer and achieve = > > >compatibilitit=3D > > >>> y trivially)
> > >>>  =3D3B
> > >>>  =3D3B
> > >>> I have to say though=3D2C the biggest reason > > is in-fix operators. = > > >Convenient =3D > > >>> syntax.
> > >>> C++ is the best and some way worst of example > > of the general right = > > >way to d=3D > > >>> o this -- you let programmers define types and > > their infix operators. = > > >Other=3D > > >>> languages just come with a passle of special > > cases of types that have = > > >in-f=3D > > >>> ix operators.
> > >>> A good example is that Java infix operator + > > on string=3D2C besides = > > >the vario=3D > > >>> us integers=3D2C and nothing else.
> > >>>  =3D3B
> > >>>  =3D3B
> > >>> I think C# lets you define operators=3D2C yet > > people don't complain = > > >that it i=3D > > >>> s "a mess" as they do of C++.
> > >>> I think Python does now too.
> > >>> So it is feature growing in popularity among > > "mainstream" = > > >languages=3D2C not =3D > > >>> just C++.
> > >>>  =3D3B =3D3B C++ of course is > > extremely mainstream=3D2C but = > > >also a favori=3D > > >>> te target. ( > >href=3D3D"http://www.relisoft.com/tools/CppCritic.html">http:/=3D > > >>> > > /www.relisoft.com/tools/CppCritic.html)
> > >>>  =3D3B
> > >>>  =3D3B
> > >>> We also have subranges of LONGINT.
> > >>> I'm not sure what the generalization of > > subranges are=3D2C = > > >granted.
> > >>>  =3D3BMaybe some sort of C++ template > > that takes constants in the = > > >templat=3D > > >>> e and does range checks at runtime. Yeah=3D2C > > maybe.
> > >>>  =3D3B
> > >>>  =3D3B
> > >>> And as you point out=3D2C convenient literal > > syntax.
> > >>>  =3D3B
> > >>>  =3D3B
> > >>> People reasonably argue for library extension > > in place of language = > > >extensio=3D > > >>> n=3D2C but that requires a language which is > > flexible enough to write = > > >librari=3D > > >>> es with the desired interface=3D2C and so many > > languages don't let = > > >infix oper=3D > > >>> ators be in a user-written library.
> > >>> (There is a subtle but useless distinction > > here -- infix operators = > > >being in=3D > > >>> libraries vs. "user-written" libraries. The > > infix set operations for = > > >examp=3D > > >>> le are in a library=3D2C but not > > user-written=3D2C special=3D2C the = > > >compiler know=3D > > >>> s about it.)
> > >>>  =3D3B
> > >>> >=3D3B that would perhaps not match how > > C handles "long long" on = > > >the same > >>> R>>=3D3B platform (which is how=3D2C > > come to think of it?)=3D2C and = > > >that would =3D > > >>> require

> > >>>  =3D3B
> > >>> On NT/x86=3D2C __int64/long long is returned > > in the register pair = > > >edx:eax. > >>>>=20 > > >>> edx is high=3D2C eax is low.
> > >>> When passed as a parameter to __stdcall or > > __cdecl is just passed as = > > >two 32=3D > > >>> bit values adjacent on the stack=3D2C "hi=3D2C > > lo=3D2C hi=3D2C lo=3D2C = > > >it's off to pu=3D > > >>> sh we go" is the Snow White-influenced mantra > > to remember how to pass = > > >them=3D > > >>> =3D2C at least on little endian > > stack-growing-down machines (which = > > >includes x=3D > > >>> 86). For __fastcall I'm not sure they are > > passed in registers or on = > > >the sta=3D > > >>> ck.
> > >>> Passing and/or returning small structs also > > has special efficient = > > >handling =3D > > >>> in the ABI=3D2C so __int64 really might be > > equivalent to a small = > > >record. Not =3D > > >>> that cm3 necessarily implements that > > "correctly" =3D3B -- for = > > >interop wit=3D > > >>> h C=3D3B for Modula-3 calling Modula-3 we can > > make up our own ABI so = > > >there is=3D > > >>> n't =3D3Breally an "incorrect" > > way. =3D3BNotice the mingw = > > >problem I had=3D > > >>> passing a Win32 point struct by value=3D2C I > > cheated and passed it by = > > >VAR to=3D > > >>> a =3D3BC wrapper to workaround the gcc > > backend bug (which was = > > >mentioned =3D > > >>> a few times and which I looked into the code > > for=3D2C but took the = > > >easy route=3D > > >>> )
> > >>>  =3D3B
> > >>>  =3D3B
> > >>> I don't know how long long works on other > > platforms but probably = > > >similar. > >>> R> > > >>> Probably a certain register pair for return > > values.
> > >>>  =3D3B
> > >>>  =3D3B- > > Jay

 =3D3B
>=3D3B > > To: = > > >hosking at cs.purdue.edu
>=3D3B=3D > > >>> Date: Sat=3D2C 17 Apr 2010 19:47:03 > > -0700
>=3D3B From: = > > >mika at async.async.c=3D > > >>> altech.edu
>=3D3B CC: m3devel at elegosoft.com
>=3D3B > > Subject: = > > >Re: [M3de=3D > > >>> vel] INTEGER
>=3D3B > >
>=3D3B Tony Hosking > > writes:
>=3D3B = > > >>=3D3B
=3D > > >>> >=3D3B ...
>=3D3B > > >=3D3B
>=3D3B >=3D3B>=3D3B > > We = > > >need it to match 64-b=3D > > >>> it integers on 32-bit machines? That seems > > =3D3D
>=3D3B = > > >>=3D3Blike
>=3D > > >>> =3D3B >=3D3B>=3D3B a very weak > > rationale indeed=3D2C if the same = > > >functionality =3D > > >>> could be =3D3D
>=3D3B > > >=3D3Bprovided
>=3D3B > > >=3D3B>=3D3= > > >B through some o=3D > > >>> ther mechanism (e.g.=3D2C ARRAY [0..1] OF > > INTEGER---even = > > >=3D3D
>=3D3B >=3D3B=3D > > >>> with
>=3D3B > > >=3D3B>=3D3B a pragma e.g. = > > ><=3D3B*CLONGLONG*>=3D3B.. if it i=3D > > >>> s necessary to tell the compiler > > =3D3D
>=3D3B = > > >>=3D3Bthat
>=3D3B > > >=3D3B&=3D > > >>> gt=3D3B a special linkage convention is > > needed).
>=3D3B = > > >>=3D3B
>=3D3B &=3D > > >>> gt=3D3BThere's no special linkage convention. > > Not sure what you mean = > > >here. > >>>> >=3D3B > > >=3D3B
>=3D3B
>=3D3B I > > just mean if we = > > >had
>=3D3B
>=3D > > >>> =3D3B TYPE LONGINT =3D3D ARRAY [0..1] OF > > INTEGER
>=3D3B = > > >
>=3D3B that woul=3D > > >>> d perhaps not match how C handles "long long" > > on the same
>=3D3B = > > >platfor=3D > > >>> m (which is how=3D2C come to think of > > it?)=3D2C and that would = > > >require
>=3D > > >>> =3D3B special linkage > > tricks.
>=3D3B
>=3D3B But > > what would = > > >be lost? Th=3D > > >>> e ability to type literals. > >
>=3D3B
>=3D3B You could get > > = > > >the same co=3D > > >>> de interface on 32- and 64-bit machine > > by
>=3D3B = > > >defining
>=3D3B
=3D > > >>> >=3D3B TYPE FileOffset =3D3D ARRAY[0..1] > > OF [-16_80000000 .. = > > >+16_7fffffff ] > >>> R>>=3D3B
>=3D3B and > > using that.
>=3D3B
>=3D3B = > > >
>=3D3B Mika > >>>> > > > > > > > > >>> =3D > > >>>=20 > > >>> --_264cb69b-0215-44c3-807c-8b4d8ea0ea59_-- > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Apr 19 12:20:45 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 19 Apr 2010 10:20:45 +0000 Subject: [M3devel] "post rc5" Message-ID: "post" archives appear on the main page. I'll try again to build AMD64/I386_DARWIN just via Hudson. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Apr 19 13:48:02 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 19 Apr 2010 13:48:02 +0200 Subject: [M3devel] hudson on birch down again Message-ID: <20100419134802.vxcfp982s0k4sgsc@mail.elegosoft.com> Can you please have a look and fix that? 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 kay.haeusler at elego.de Mon Apr 19 13:58:21 2010 From: kay.haeusler at elego.de (Kay =?UTF-8?B?SMOkdXNsZXI=?=) Date: Mon, 19 Apr 2010 13:58:21 +0200 Subject: [M3devel] hudson on birch down again In-Reply-To: <20100419134802.vxcfp982s0k4sgsc@mail.elegosoft.com> References: <20100419134802.vxcfp982s0k4sgsc@mail.elegosoft.com> Message-ID: <20100419135821.266c5b2e@pine.elego.de> Hallo Olaf, Olaf Wagner wrote: > Can you please have a look and fix that? I've restarted hudson. -- Mit freundlichen Gr??en Kay H?usler mailto:kay.haeusler at elego.de elego Software Solutions GmbH http://www.elego.de Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 13355 Berlin, Germany Amtsgericht Charlottenburg Tel.: +49 30 23458696 Sitz der Gesellschaft: Berlin Fax: +49 30 23458695 Gesch?ftsf?hrer: Olaf Wagner From jay.krell at cornell.edu Mon Apr 19 14:10:41 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 19 Apr 2010 12:10:41 +0000 Subject: [M3devel] SchedulerPosix/Win32/sockets Message-ID: short story: I think we should have SchedulerPosix.IOWait and SchedulerPosix.IOAlertWait, but not SchedulerPosix.WaitProces, on Win32. With the CARDINAL changed back to INTEGER. As well, as before, I'd like to only have one implementation of this. Currently there are two identical copies, due to Cygwin. But this proposal is for regular Win32. long story: Win32 has select, for sockets. Instead of a bitset, it uses an array of 64, so doesn't have the problem that poll fixes. SocketPosix.m3 makes sockets non-blocking and uses IOWait and IOAlertWait. SocketPosix.Connect/Accept are alertable. SocketWin32.Connect/Accept are not alertable. That seems wrong, eh? I assume this difference is due to original implementers not realizing their options on Win32. I assume this difference would be good to remove. IOWait is merely a call to select (assuming kernel threads). In rewritten-in-C, I can easily just #ifdef and call select on Win32. IOAlertWait is implemented by polling via select/poll for up to a maximum of a second at a time, testing alert between each. It is this code that I don't think should be duplicated. We already have two copies of it due to Cygwin. (I think we might be able to do better on Win32 though, by using Win32 alerting as part of Modula-3 alerting, but for the time being, sharing code with Posix that polls every second would be ok.) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Apr 19 14:11:52 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 19 Apr 2010 12:11:52 +0000 Subject: [M3devel] SchedulerPosix/Win32/sockets Message-ID: short story: I think we should have SchedulerPosix.IOWait and SchedulerPosix.IOAlertWait, but not SchedulerPosix.WaitProces, on Win32. With the CARDINAL changed back to INTEGER. As well, as before, I'd like to only have one implementation of this. Currently there are two identical copies, due to Cygwin. But this proposal is for regular Win32. long story: Win32 has select, for sockets. Instead of a bitset, it uses an array of 64, so doesn't have the problem that poll fixes. SocketPosix.m3 makes sockets non-blocking and uses IOWait and IOAlertWait. SocketPosix.Connect/Accept are alertable. SocketWin32.Connect/Accept are not alertable. That seems wrong, eh? I assume this difference is due to original implementers not realizing their options on Win32. I assume this difference would be good to remove. IOWait is merely a call to select (assuming kernel threads). In rewritten-in-C, I can easily just #ifdef and call select on Win32. IOAlertWait is implemented by polling via select/poll for up to a maximum of a second at a time, testing alert between each. It is this code that I don't think should be duplicated. We already have two copies of it due to Cygwin. (I think we might be able to do better on Win32 though, by using Win32 alerting as part of Modula-3 alerting, but for the time being, sharing code with Posix that polls every second would be ok.) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Apr 19 16:03:16 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 19 Apr 2010 14:03:16 +0000 Subject: [M3devel] deleting most of m3core/src/unix? Message-ID: I went ahead and did this. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Subject: deleting most of m3core/src/unix? Date: Thu, 15 Apr 2010 14:43:23 +0000 Ok..maybe now time to delete all of m3core/src/unix except for uin-*, Common, and part of solaris-2-x? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Apr 19 16:04:39 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 19 Apr 2010 14:04:39 +0000 Subject: [M3devel] JVideo/struct_timeval? Message-ID: I went ahead and put in a local type. Utime.struct_timeval is now gone. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Subject: JVideo/struct_timeval? Date: Mon, 12 Apr 2010 13:03:26 +0000 This seems wierd: C:\dev2\cm3.2\m3-ui\jvideo\src\POSIX\jvprotocol.i3(193): timestamp: Utime.struct_timeval; I think they are defining a wire protocol, but embedding platform-specific types in it. How about I just change to Time.T? (64bit floating point, seconds since 1970). We could do like: C:\dev2\cm3.2\m3-ui\jvideo\src\POSIX\decunix\JVSink.m3(440): jvb.timestamp.tv_sec := signed_ntohl(hdr.timestamp.tv_sec); and define it to be transferred as a network order 64bit integer (big endian LONGINT), or maybe an array of 8 bytes. Or maybe define a local struct_timeval separate from Utime that hardcodes the sizes..and maybe using LONGINT? 32bit time_t is apparently still very common, though it seems obviously a big mistake.. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Apr 19 16:15:06 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 19 Apr 2010 16:15:06 +0200 Subject: [M3devel] giant lock in SocketWin32.m3? In-Reply-To: References: <20100418140821.428882474008@birch.elegosoft.com> Message-ID: <20100419161506.w9l7qydxc08sggwk@mail.elegosoft.com> Quoting Jay K : > > Anyone know why SocketWin32.m3 has had a giant lock around everything? > > I see no point to it. > > The only global variable is related to on-demand initialization. > > And even that wasn't handled correctly.. Perhaps the network stack on Windows95/98 wasn't really reentrant? Just a guess though. The code is quite old as far as I know. 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 jay.krell at cornell.edu Mon Apr 19 17:31:33 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 19 Apr 2010 15:31:33 +0000 Subject: [M3devel] giant lock in SocketWin32.m3? In-Reply-To: <20100419161506.w9l7qydxc08sggwk@mail.elegosoft.com> References: <20100418140821.428882474008@birch.elegosoft.com>, , <20100419161506.w9l7qydxc08sggwk@mail.elegosoft.com> Message-ID: > Perhaps the network stack on Windows95/98 wasn't really reentrant? No. Your expectations are much too low. Imagine if this was true. Then all Windows networking code would have its own giant locks, and you'd read about this in documentation and such. I'm not sure of the terminology, but: "Reentrant" is a strong word. "Thread safe" is a weaker more common one. For example strtok is not reentrant, but typically thread safe, through use of "thread locals". You can't use strtok in a nested for loop though. It's not that the code is old per se. I think a lot of it was slapped together quickly and then not really reviewed or tested much, and doesn't get much use either. I constantly see incorrect on-demand initialization as well. This code had it as well. - Jay > Date: Mon, 19 Apr 2010 16:15:06 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] giant lock in SocketWin32.m3? > > Quoting Jay K : > > > > > Anyone know why SocketWin32.m3 has had a giant lock around everything? > > > > I see no point to it. > > > > The only global variable is related to on-demand initialization. > > > > And even that wasn't handled correctly.. > > Perhaps the network stack on Windows95/98 wasn't really reentrant? > > Just a guess though. The code is quite old as far as I know. > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.async.caltech.edu Mon Apr 19 19:23:13 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Mon, 19 Apr 2010 10:23:13 -0700 Subject: [M3devel] INTEGER In-Reply-To: References: , , , <7C7408D0-9A40-4988-BADA-A9FD8C15D388@cs.purdue.edu>, , , , , , , <20100418023535.3BA9E1A2103@async.async.caltech.edu>, , <20100418024703.6965B1A2103@async.async.caltech.edu> <20100418074927.934461A2117@async.async.caltech.edu> <04EB7FF8-D304-428D-839E-233FCE009C98@cs.purdue.edu> <20100418195901.CDACB1A20F6@async.async.caltech.edu> Message-ID: <20100419172313.68B241A20D6@async.async.caltech.edu> Well *my* problem is that I still use PM3 for a lot of things. Trying to switch to CM3, yes, but I can't "certify" CM3 for critical stuff yet. So I'm maintaining a significant amount of code that needs to compile under both PM3 and CM3. Two problems crop up. 1. If there are bugs in m3tk/stubgen, the fixes only apply to one or the other version of m3tk/stubgen. 2. Some of the code I'm maintaining processes Modula-3 code as input. It needs to be in two versions. In this kind of environment, programming languages don't really evolve, since the system depends on their being both forward- and backward-compatible. They "change" is more correct. The way Java changes. More in general, though, Modula-3's designers were clearly well acquainted with C, Fortran, and other languages that provide different-range integers. They chose not to indulge. I even have a version of Modula-3 for a 16-bit machine that doesn't do it, even though on this machine the need for a 32-bit integer is arguably greater than the need for 64-bit integers on 32-bit machines. Now we indulge in this language complication to solve what is clearly a temporary problem, since anyone who cares about large problems is going to have 64-bit systems yesterday... and meanwhile no one seems to have availed himself of the solution! My worst fear is that once the process gets started, the reason for staying with the original Green-Book specification has now been defeated and we will see more and more "evolution". Trying to actually build systems that process Modula-3 like data becomes, at that point, like trying to stand in quicksand. I'm not incredibly picky here... I just hope it doesn't go further. I would personally support either sticking with the current status quo or going back to the Green Book w.r.t. integers and characters. Saying that EWD wasn't renowned for his practicality is something he would have taken as a great compliment, I'm sure. Mika Tony Hosking writes: >Mika, > >First off, I'd be very interested to know what the issues are with = >LONGINT and stubgen. We are building that every day in regression = >testing. It would be really good to get some precise feedback. > >True, LONGINT is integrated with all of the language tools (same as = >WIDECHAR). > >I suppose that is the price we pay for the language having evolved. = >Nevertheless, CM3 should be totally backward compatible with the green = >book. There is no reason it should not build packages from PM3 or SRC. > >Now, this is not to say that perhaps we haven't overreached with LONGINT = >given that 64-bit is more prevalent. But then it is also useful to be = >able to interoperate with C libraries. The previous interfacing was = >pretty much a kludge, using ARRAY[0..1] OF INTEGER for "long long" but = >then not propagating the double INTEGER value properly throughout the = >Modula-3 libraries. > >I'm sorry to say that EWD was not particularly renowned for his = >practicality; pedant more like. Nice to be high and mighty but we also = >need to interact with the real world. > >We should be able to make this work. Is there a better alternative? = >Revoke LONGINT, and WIDECHAR? > >On 18 Apr 2010, at 15:59, Mika Nystrom wrote: > >>=20 >> My problem is really just that it's ugly. LONGx is showing up as an = >issue >> in all sorts of low-level code, which is not surprising since Modula-3 >> with LONGx is not the same language as Modula-3 (maybe we should call >> it Modula-3+?)=20 >>=20 >> The compiler bootstrapping process has gotten more complicated due to = >it, >> and when I cvs updated m3tk yesterday stubgen wouldn't compile because = >there >> was something "long" in it that wasn't there before. I have no idea = >what >> library or components I needed to update and recompile and didn't have = >the >> time to deal with the issue at the time. >>=20 >> And the new m3tk, stubgen, and compiler(?) won't compile using PM3 or >> SRC M3 since we're no longer using the language of the Green Book. >> (Same comment goes for WIDECHAR, by the way.) >>=20 >> One of the wonderful things about Modula-3 *used to be* that I could >> grab some old package from DECSRC and just use it without changes = >since >> no one had messed with the language definition. This is still true as >> far as programs that just use the tools go, but it's no longer true = >for >> programs that process Modula-3 code as input data. Of which there are >> more than a few: many aspects of Modula-3 were specifically designed = >to >> make the language easy to process by program, as an intermediate = >format >> and whatnot. >>=20 >> To quote E.W.D.: >>=20 >> 'Unfathomed misunderstanding is further revealed by the term "software >> maintenance", as a result of which many people continue to believe = >that >> programs and even programming languages themselves are subject to wear >> and tear. Your car needs maintenance too, doesn't it? Famous is the = >story >> of the oil company that believed that its PASCAL programs did not last >> as long as its FORTRAN programs "because PASCAL was not maintained".' >>=20 >> LONGx is causing me to have to do "software maintenance" on Modula-3 >> programs... for a feature that no one appears to be using and is = >quickly >> becoming irrelevant. >>=20 >> Mika >>=20 >>=20 >> Tony Hosking writes: >>> In the language spec NUMBER(a) and LAST(a) - FIRST(a) + 1 are *not* =3D= > >>> defined to mean the same thing for all types. >>> NUMBER does have an INTEGER value, as expected for subranges of = >LONGINT =3D >>> that are not too large. >>> This is as it has always been for subranges of INTEGER that are not = >too =3D >>> large. >>>=20 >>> Mika, I'm not sure I see any of the problems you are worrying about = >in =3D >>> the current definition of LONGINT/LONGCARD. >>>=20 >>> On 18 Apr 2010, at 03:49, Mika Nystrom wrote: >>>=20 >>>> =3D20 >>>> Jay I know most of this, and it doesn't really answer the question >>>> "what is it for?" >>>> =3D20 >>>> I think we've already established that LONGINT isn't useful for =3D >>> counting >>>> anything that might actually reside in the computer's memory: it = >makes >>>> no sense as an array index, for instance. INTEGER suffices for = >that. >>>> =3D20 >>>> I thought that the only real reason for LONGINT was to match C's >>>> declaration of various seek-related routines on 32-bit machines. >>>> That's not a very good reason. >>>> =3D20 >>>> C++ succeeds because it does very well in the area(s) it is good at. >>>> People who want to program in C++ will clearly program in C++, not >>>> Modula-3. Modula-3 is never, ever going to be the language of = >choice =3D >>> for >>>> people who want lots of snazzy infix operators. Modula-3 is = >supposed =3D >>> to >>>> be a language with about as powerful semantics as C++ and an = >extremely >>>> simple syntax and definition---snazzy infix is one of the things you >>>> give up for that. I don't see how LONGINT fits into this picture. >>>> Now we have LONGCARD too? And it's infected the definitions >>>> of FIRST and LAST? But not NUMBER... argh! >>>> =3D20 >>>> so, >>>> =3D20 >>>> NUMBER(a) and LAST(a) - FIRST(a) + 1 >>>> =3D20 >>>> no longer mean the same thing? Are we going to see lots of comments >>>> in generics in the future where it says T may not be an open array >>>> type nor an array type indexed on LONGINT or a subrange thereof? >>>> =3D20 >>>> Your comments about different parameter-passing techniques was what = >I =3D >>> was >>>> trying to address with my suggestion to have a pragma for = >this---just =3D >>> to >>>> match C (and Fortran?), of course. Name me a single Modula-3 =3D >>> programmer >>>> who cares in what order the bits in his parameters are pushed on the >>>> stack in a Modula-3-to-Modula-3 call. >>>> =3D20 >>>> And I am definitely in that school of thought that says that =3D >>> programming >>>> languages should not "evolve". Better to leave well enough alone. >>>> =3D20 >>>> How much Modula-3 code has been written that uses LONGINT? Other = >than >>>> to talk to C? I've certainly never used it. >>>> =3D20 >>>> Mika >>>> =3D20 >>>> =3D20 >>>> =3D20 >>>> Jay K writes: >>>>> --_264cb69b-0215-44c3-807c-8b4d8ea0ea59_ >>>>> Content-Type: text/plain; charset=3D3D"iso-8859-1" >>>>> Content-Transfer-Encoding: quoted-printable >>>>> =3D20 >>>>> =3D20 >>>>> TYPE LONGINT =3D3D3D ARRAY [0..1] OF INTEGER on a 32bit system is = >very =3D >>> close to=3D3D >>>>> LONGINT. >>>>> =3D20 >>>>> Plus treating it opaquely and providing a bunch of functions to =3D >>> operate on=3D3D >>>>> it. >>>>> =3D20 >>>>> Just as well therefore could be RECORD hi=3D3D2Clo:LONGINT END (see = >=3D >>> LARGE_INTE=3D3D >>>>> GER and ULARGE_INTEGER in winnt.h) >>>>> =3D20 >>>>> =3D3D20 >>>>> =3D20 >>>>> Differences that come to mind: >>>>> =3D20 >>>>> infix operators <=3D3D3D=3D3D3D=3D3D3D=3D3D20 >>>>> =3D20 >>>>> possibly passed differently as a parameter >>>>> =3D20 >>>>> or returned differently as a result >>>>> =3D20 >>>>> ie. probably "directly compatible with" "long long"=3D3D2C passed = >by =3D >>> value (o=3D3D >>>>> f course you could always pass by pointer and achieve = >compatibilitity =3D >>> trivi=3D3D >>>>> ally) >>>>> =3D20 >>>>> =3D3D20 >>>>> =3D20 >>>>> =3D3D20 >>>>> =3D20 >>>>> I have to say though=3D3D2C the biggest reason is in-fix operators. = >=3D >>> Convenient =3D3D >>>>> syntax. >>>>> =3D20 >>>>> C++ is the best and some way worst of example of the general right = >=3D >>> way to d=3D3D >>>>> o this -- you let programmers define types and their infix = >operators. =3D >>> Other=3D3D >>>>> languages just come with a passle of special cases of types that = >have =3D >>> in-f=3D3D >>>>> ix operators. >>>>> =3D20 >>>>> A good example is that Java infix operator + on string=3D3D2C = >besides =3D >>> the vario=3D3D >>>>> us integers=3D3D2C and nothing else. >>>>> =3D20 >>>>> =3D3D20 >>>>> =3D20 >>>>> =3D3D20 >>>>> =3D20 >>>>> I think C# lets you define operators=3D3D2C yet people don't = >complain =3D >>> that it i=3D3D >>>>> s "a mess" as they do of C++. >>>>> =3D20 >>>>> I think Python does now too. >>>>> =3D20 >>>>> So it is feature growing in popularity among "mainstream" =3D >>> languages=3D3D2C not =3D3D >>>>> just C++. >>>>> =3D20 >>>>> C++ of course is extremely mainstream=3D3D2C but also a favorite =3D >>> target. (ht=3D3D >>>>> tp://www.relisoft.com/tools/CppCritic.html) >>>>> =3D20 >>>>> =3D3D20 >>>>> =3D20 >>>>> =3D3D20 >>>>> =3D20 >>>>> We also have subranges of LONGINT. >>>>> =3D20 >>>>> I'm not sure what the generalization of subranges are=3D3D2C = >granted. >>>>> =3D20 >>>>> Maybe some sort of C++ template that takes constants in the = >template =3D >>> and d=3D3D >>>>> oes range checks at runtime. Yeah=3D3D2C maybe. >>>>> =3D20 >>>>> =3D3D20 >>>>> =3D20 >>>>> =3D3D20 >>>>> =3D20 >>>>> And as you point out=3D3D2C convenient literal syntax. >>>>> =3D20 >>>>> =3D3D20 >>>>> =3D20 >>>>> =3D3D20 >>>>> =3D20 >>>>> People reasonably argue for library extension in place of language = >=3D >>> extensio=3D3D >>>>> n=3D3D2C but that requires a language which is flexible enough to = >write =3D >>> librari=3D3D >>>>> es with the desired interface=3D3D2C and so many languages don't = >let =3D >>> infix oper=3D3D >>>>> ators be in a user-written library. >>>>> =3D20 >>>>> (There is a subtle but useless distinction here -- infix operators = >=3D >>> being in=3D3D >>>>> libraries vs. "user-written" libraries. The infix set operations = >for =3D >>> examp=3D3D >>>>> le are in a library=3D3D2C but not user-written=3D3D2C special=3D3D2C= > the =3D >>> compiler know=3D3D >>>>> s about it.) >>>>> =3D20 >>>>> =3D3D20 >>>>> =3D20 >>>>>> that would perhaps not match how C handles "long long" on the same >>>>>> platform (which is how=3D3D2C come to think of it?)=3D3D2C and = >that =3D >>> would require >>>>> =3D20 >>>>> =3D20 >>>>> =3D3D20 >>>>> =3D20 >>>>> On NT/x86=3D3D2C __int64/long long is returned in the register pair = >=3D >>> edx:eax. >>>>> =3D20 >>>>> edx is high=3D3D2C eax is low. >>>>> =3D20 >>>>> When passed as a parameter to __stdcall or __cdecl is just passed = >as =3D >>> two 32=3D3D >>>>> bit values adjacent on the stack=3D3D2C "hi=3D3D2C lo=3D3D2C = >hi=3D3D2C lo=3D3D2C =3D >>> it's off to pu=3D3D >>>> sh we go" is the Snow White-influenced mantra to remember how to = >pass =3D >>> them=3D3D >>>>> =3D3D2C at least on little endian stack-growing-down machines = >(which =3D >>> includes x=3D3D >>>>> 86). For __fastcall I'm not sure they are passed in registers or on = >=3D >>> the sta=3D3D >>>>> ck. >>>>> =3D20 >>>>> Passing and/or returning small structs also has special efficient =3D= > >>> handling =3D3D >>>>> in the ABI=3D3D2C so __int64 really might be equivalent to a small = >=3D >>> record. Not =3D3D >>>>> that cm3 necessarily implements that "correctly" -- for interop = >with =3D >>> C=3D3D3B =3D3D >>>>> for Modula-3 calling Modula-3 we can make up our own ABI so there =3D= > >>> isn't rea=3D3D >>>>> lly an "incorrect" way. Notice the mingw problem I had passing a =3D >>> Win32 poin=3D3D >>>>> t struct by value=3D3D2C I cheated and passed it by VAR to a C = >wrapper =3D >>> to worka=3D3D >>>>> round the gcc backend bug (which was mentioned a few times and = >which =3D >>> I look=3D3D >>>>> ed into the code for=3D3D2C but took the easy route) >>>>> =3D20 >>>>> =3D3D20 >>>>> =3D20 >>>>> =3D3D20 >>>>> =3D20 >>>>> I don't know how long long works on other platforms but probably =3D >>> similar. >>>>> =3D20 >>>>> Probably a certain register pair for return values. >>>>> =3D20 >>>>> =3D3D20 >>>>> =3D20 >>>>> - Jay >>>>> =3D20 >>>>> =3D3D20 >>>>>> To: hosking at cs.purdue.edu >>>>>> Date: Sat=3D3D2C 17 Apr 2010 19:47:03 -0700 >>>>>> From: mika at async.async.caltech.edu >>>>>> CC: m3devel at elegosoft.com >>>>>> Subject: Re: [M3devel] INTEGER >>>>>> =3D3D20 >>>>>> Tony Hosking writes: >>>>>>> =3D20 >>>>>> ... >>>>>>> =3D20 >>>>>>>> We need it to match 64-bit integers on 32-bit machines? That = >seems =3D >>> =3D3D3D >>>>>>> like >>>>>>>> a very weak rationale indeed=3D3D2C if the same functionality = >could =3D >>> be =3D3D3D >>>>>>> provided >>>>>>>> through some other mechanism (e.g.=3D3D2C ARRAY [0..1] OF =3D >>> INTEGER---even =3D3D >>>>> =3D3D3D >>>>>>> with >>>>>>>> a pragma e.g. <*CLONGLONG*>.. if it is necessary to tell the =3D >>> compiler =3D3D >>>>> =3D3D3D >>>>>>> that >>>>>>>> a special linkage convention is needed). >>>>>>> =3D20 >>>>>>> There's no special linkage convention. Not sure what you mean = >here. >>>>>>> =3D20 >>>>>> =3D3D20 >>>>>> I just mean if we had >>>>>> =3D3D20 >>>>>> TYPE LONGINT =3D3D3D ARRAY [0..1] OF INTEGER >>>>>> =3D3D20 >>>>>> that would perhaps not match how C handles "long long" on the same >>>>>> platform (which is how=3D3D2C come to think of it?)=3D3D2C and = >that =3D >>> would require >>>>>> special linkage tricks. >>>>>> =3D3D20 >>>>>> But what would be lost? The ability to type literals.=3D3D20 >>>>>> =3D3D20 >>>>>> You could get the same code interface on 32- and 64-bit machine by >>>>>> defining >>>>>> =3D3D20 >>>>>> TYPE FileOffset =3D3D3D ARRAY[0..1] OF [-16_80000000 .. = >+16_7fffffff ] >>>>>> =3D3D20 >>>>>> and using that. >>>>>> =3D3D20 >>>>>> =3D3D20 >>>>>> Mika >>>>> =3D3D >>>>> =3D20 >>>>> --_264cb69b-0215-44c3-807c-8b4d8ea0ea59_ >>>>> Content-Type: text/html; charset=3D3D"iso-8859-1" >>>>> Content-Transfer-Encoding: quoted-printable >>>>> =3D20 >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> TYPE LONGINT =3D3D3D ARRAY [0..1] OF INTEGER on a =3D3D3B32bit = >system =3D >>> is very c=3D3D >>>>> lose to LONGINT.
>>>>>  =3D3D3BPlus treating it opaquely and providing a bunch of =3D >>> functions to ope=3D3D >>>>> rate on it.
>>>>>  =3D3D3BJust as well therefore could be RECORD = >hi=3D3D2Clo:LONGINT =3D >>> END (see LAR=3D3D >>>>> GE_INTEGER and ULARGE_INTEGER in winnt.h)
>>>>>  =3D3D3B
>>>>> Differences that come to mind:
>>>>>  =3D3D3B =3D3D3Binfix operators =3D3D3B = ><=3D3D3B=3D3D3D=3D3D3D=3D3D3D =3D >>>
>>>>>  =3D3D3B possibly passed differently =3D3D3Bas a = >parameter
>>>>>  =3D3D3B or returned differently as a result
>>>>>  =3D3D3B ie. probably "directly compatible with" "long = >long"=3D3D2C =3D >>> passed by v=3D3D >>>>> alue (of course you could always pass by pointer and achieve =3D >>> compatibilitit=3D3D >>>>> y trivially)
>>>>>  =3D3D3B
>>>>>  =3D3D3B
>>>>> I have to say though=3D3D2C the biggest reason is in-fix operators. = >=3D >>> Convenient =3D3D >>>>> syntax.
>>>>> C++ is the best and some way worst of example of the general right = >=3D >>> way to d=3D3D >>>>> o this -- you let programmers define types and their infix = >operators. =3D >>> Other=3D3D >>>>> languages just come with a passle of special cases of types that = >have =3D >>> in-f=3D3D >>>>> ix operators.
>>>>> A good example is that Java infix operator + on string=3D3D2C = >besides =3D >>> the vario=3D3D >>>>> us integers=3D3D2C and nothing else.
>>>>>  =3D3D3B
>>>>>  =3D3D3B
>>>>> I think C# lets you define operators=3D3D2C yet people don't = >complain =3D >>> that it i=3D3D >>>>> s "a mess" as they do of C++.
>>>>> I think Python does now too.
>>>>> So it is feature growing in popularity among "mainstream" =3D >>> languages=3D3D2C not =3D3D >>>>> just C++.
>>>>>  =3D3D3B =3D3D3B C++ of course is extremely mainstream=3D3D2C= > but =3D >>> also a favori=3D3D >>>>> te target. (>> href=3D3D3D"http://www.relisoft.com/tools/CppCritic.html">http:/=3D3D >>>>> /www.relisoft.com/tools/CppCritic.html)
>>>>>  =3D3D3B
>>>>>  =3D3D3B
>>>>> We also have subranges of LONGINT.
>>>>> I'm not sure what the generalization of subranges are=3D3D2C =3D >>> granted.
>>>>>  =3D3D3BMaybe some sort of C++ template that takes constants in = >the =3D >>> templat=3D3D >>>>> e and does range checks at runtime. Yeah=3D3D2C maybe.
>>>>>  =3D3D3B
>>>>>  =3D3D3B
>>>>> And as you point out=3D3D2C convenient literal syntax.
>>>>>  =3D3D3B
>>>>>  =3D3D3B
>>>>> People reasonably argue for library extension in place of language = >=3D >>> extensio=3D3D >>>>> n=3D3D2C but that requires a language which is flexible enough to = >write =3D >>> librari=3D3D >>>>> es with the desired interface=3D3D2C and so many languages don't = >let =3D >>> infix oper=3D3D >>>>> ators be in a user-written library.
>>>>> (There is a subtle but useless distinction here -- infix operators = >=3D >>> being in=3D3D >>>>> libraries vs. "user-written" libraries. The infix set operations = >for =3D >>> examp=3D3D >>>>> le are in a library=3D3D2C but not user-written=3D3D2C special=3D3D2C= > the =3D >>> compiler know=3D3D >>>>> s about it.)
>>>>>  =3D3D3B
>>>>> >=3D3D3B that would perhaps not match how C handles "long long" = >on =3D >>> the same>>>> R>>=3D3D3B platform (which is how=3D3D2C come to think of = >it?)=3D3D2C and =3D >>> that would =3D3D >>>>> require

>>>>>  =3D3D3B
>>>>> On NT/x86=3D3D2C __int64/long long is returned in the register pair = >=3D >>> edx:eax.>>>>> =3D20 >>>>> edx is high=3D3D2C eax is low.
>>>>> When passed as a parameter to __stdcall or __cdecl is just passed = >as =3D >>> two 32=3D3D >>>>> bit values adjacent on the stack=3D3D2C "hi=3D3D2C lo=3D3D2C = >hi=3D3D2C lo=3D3D2C =3D >>> it's off to pu=3D3D >>>>> sh we go" is the Snow White-influenced mantra to remember how to = >pass =3D >>> them=3D3D >>>>> =3D3D2C at least on little endian stack-growing-down machines = >(which =3D >>> includes x=3D3D >>>>> 86). For __fastcall I'm not sure they are passed in registers or on = >=3D >>> the sta=3D3D >>>>> ck.
>>>>> Passing and/or returning small structs also has special efficient =3D= > >>> handling =3D3D >>>>> in the ABI=3D3D2C so __int64 really might be equivalent to a small = >=3D >>> record. Not =3D3D >>>>> that cm3 necessarily implements that "correctly" =3D3D3B -- for = >=3D >>> interop wit=3D3D >>>>> h C=3D3D3B for Modula-3 calling Modula-3 we can make up our own ABI = >so =3D >>> there is=3D3D >>>>> n't =3D3D3Breally an "incorrect" way. =3D3D3BNotice the = >mingw =3D >>> problem I had=3D3D >>>>> passing a Win32 point struct by value=3D3D2C I cheated and passed = >it by =3D >>> VAR to=3D3D >>>>> a =3D3D3BC wrapper to workaround the gcc backend bug (which was = >=3D >>> mentioned =3D3D >>>>> a few times and which I looked into the code for=3D3D2C but took = >the =3D >>> easy route=3D3D >>>>> )
>>>>>  =3D3D3B
>>>>>  =3D3D3B
>>>>> I don't know how long long works on other platforms but probably =3D >>> similar.>>>> R> >>>>> Probably a certain register pair for return values.
>>>>>  =3D3D3B
>>>>>  =3D3D3B- Jay

 =3D3D3B
>=3D3D3B To: =3D >>> hosking at cs.purdue.edu
>=3D3D3B=3D3D >>>>> Date: Sat=3D3D2C 17 Apr 2010 19:47:03 -0700
>=3D3D3B From: =3D >>> mika at async.async.c=3D3D >>>>> altech.edu
>=3D3D3B CC: m3devel at elegosoft.com
>=3D3D3B = >Subject: =3D >>> Re: [M3de=3D3D >>>>> vel] INTEGER
>=3D3D3B
>=3D3D3B Tony Hosking = >writes:
>=3D3D3B =3D >>> >=3D3D3B
=3D3D >>>>> >=3D3D3B ...
>=3D3D3B >=3D3D3B
>=3D3D3B = >>=3D3D3B>=3D3D3B We =3D >>> need it to match 64-b=3D3D >>>>> it integers on 32-bit machines? That seems =3D3D3D
>=3D3D3B =3D >>> >=3D3D3Blike
>=3D3D >>>>> =3D3D3B >=3D3D3B>=3D3D3B a very weak rationale indeed=3D3D2C if = >the same =3D >>> functionality =3D3D >>>>> could be =3D3D3D
>=3D3D3B >=3D3D3Bprovided
>=3D3D3B = >>=3D3D3B>=3D3D3=3D >>> B through some o=3D3D >>>>> ther mechanism (e.g.=3D3D2C ARRAY [0..1] OF INTEGER---even =3D >>> =3D3D3D
>=3D3D3B >=3D3D3B=3D3D >>>>> with
>=3D3D3B >=3D3D3B>=3D3D3B a pragma e.g. =3D >>> <=3D3D3B*CLONGLONG*>=3D3D3B.. if it i=3D3D >>>>> s necessary to tell the compiler =3D3D3D
>=3D3D3B =3D >>> >=3D3D3Bthat
>=3D3D3B >=3D3D3B&=3D3D >>>>> gt=3D3D3B a special linkage convention is needed).
>=3D3D3B =3D >>> >=3D3D3B
>=3D3D3B &=3D3D >>>>> gt=3D3D3BThere's no special linkage convention. Not sure what you = >mean =3D >>> here.>>>>> >=3D3D3B >=3D3D3B
>=3D3D3B
>=3D3D3B I just mean if = >we =3D >>> had
>=3D3D3B
>=3D3D >>>>> =3D3D3B TYPE LONGINT =3D3D3D ARRAY [0..1] OF INTEGER
>=3D3D3B = >=3D >>>
>=3D3D3B that woul=3D3D >>>>> d perhaps not match how C handles "long long" on the = >same
>=3D3D3B =3D >>> platfor=3D3D >>>>> m (which is how=3D3D2C come to think of it?)=3D3D2C and that would = >=3D >>> require
>=3D3D >>>>> =3D3D3B special linkage tricks.
>=3D3D3B
>=3D3D3B But = >what would =3D >>> be lost? Th=3D3D >>>>> e ability to type literals.
>=3D3D3B
>=3D3D3B You could = >get =3D >>> the same co=3D3D >>>>> de interface on 32- and 64-bit machine by
>=3D3D3B =3D >>> defining
>=3D3D3B
=3D3D >>>>> >=3D3D3B TYPE FileOffset =3D3D3D ARRAY[0..1] OF [-16_80000000 .. = >=3D >>> +16_7fffffff ]>>>> R>>=3D3D3B
>=3D3D3B and using that.
>=3D3D3B = >
>=3D3D3B =3D >>>
>=3D3D3B Mika>>>>> >>>>> =3D3D >>>>> =3D20 >>>>> --_264cb69b-0215-44c3-807c-8b4d8ea0ea59_-- From mika at async.async.caltech.edu Mon Apr 19 19:40:55 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Mon, 19 Apr 2010 10:40:55 -0700 Subject: [M3devel] INTEGER In-Reply-To: References: , , , , <7C7408D0-9A40-4988-BADA-A9FD8C15D388@cs.purdue.edu>, , , , , , , , , , , , <20100418023535.3BA9E1A2103@async.async.caltech.edu>, , , , <20100418024703.6965B1A2103@async.async.caltech.edu>, , <20100418074927.934461A2117@async.async.caltech.edu>, <04EB7FF8-D304-428D-839E-233FCE009C98@cs.purdue.edu>, <20100418195901.CDACB1A20F6@async.async.caltech.edu>, Message-ID: <20100419174055.D1A371A20EB@async.async.caltech.edu> Jay K writes: >--_54bd4884-6c8e-48b7-9b5f-c39a87170d04_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >Mika=2C the build process hasn't "really" changed. There was always an occa= ... > >I haven't tried 5.1/4.1/3.6 yet but maybe I will soon. I actually use curre= >nt configuration files when doing that though=2C so that probably inhibits = >3.6 (unless I use its configuration files). Sure, but as I mentioned to Tony, it is actually nice to be able to go "backwards" as well. ... >People really want their compiler to handle multiple precision arithmetic= >=2C at least to attain 64bit precision. > >It is nice and convenient=2C if not strictly necessary. > >=20 > >=20 > >Another view though=2C besides "interop" with C=2C is "keeping up" with C. > > Again that link suggests C has had long long for something like 18 years.= > We are late. > > Even C changed=2C C99 must be around 10 years old now? and has lnog long. > > Granted=2C I tend to think of C like you think of Modula-3 --- nice that = >it never changes. > C had all sorts of things long before Modula-3 was designed. Modula-3's designers *very specifically avoided* these things. To quote directly from the Green Book: "In the early days of the Ada project, a general in the Ada Program Office opined that 'obviously the Department of Defense is not interested in an artifically simplified language such as Pascal'. Modula-3 represents the opposite point of view. We used every artifice that we could find or invent to make the language simple." There is perhaps a place for "keeping up with C". It's not in Modula-3! It's more than "nice" that Modula-3 never changes. It's critical to what makes it special. The C/Java/whathaveyou crowd is constantly sinking in in the costs of maintaining their programs because everything needs to be rewritten every few years to "keep up", and---even worse---because bugs resulting from the changes are absolutely everywhere and no one is ever quite sure that anything works right. I don't have time for this kind of nonsense. I'll use F-77 if that's the only way to get out of that rat race, but hopefully there's a better way. > It is somewhat small=2C very well known. One only needs keep up with libr= >aries now :) and one can assume a certain baseline is everywhere and write = >portable code to it. (But I've happened upon K&R compiler *recently* -- HP-= >UX/hppa only bundles a compiler for purposes of changing kernel configurati= >on (constant data) and relinking kernel. The libraries that comprise the ke= >rnel are shipped. K&R suffices and is therefore bundled. Best is probably t= >o use that compiler to build old gcc=2C and then use old gcc to build curre= >nt gcc (current gcc can't be compiled with K&R)). > Yes, let's not forget that what made C popular was its *simplicity* (used to be that didn't have to be qualified with "somewhat"). Look at what they were competing with: PL/I! All the "features" you could shake a stick at, and where is it now? Mika From jay.krell at cornell.edu Mon Apr 19 19:44:32 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 19 Apr 2010 17:44:32 +0000 Subject: [M3devel] fw: deleting files In-Reply-To: <20100419173955.08CF82474003@birch.elegosoft.com> References: <20100419173955.08CF82474003@birch.elegosoft.com> Message-ID: Deleting files doesn't remove them from the package store. Arg. We should probably have a set of quake directives: delete_interface() delete_module() delete_implementation() delete_c_source() delete_h_source() I was tempted to empty out this stuff instead of deleting, anticipating that delete wouldn't work. I suspect attempting to import will still correctly fail, since I hope import uses the conside *.m3x files. - Jay > Date: Mon, 19 Apr 2010 19:39:54 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/04/19 19:39:54 > > Modified files: > cm3/m3-libs/libm3/src/os/Common/: m3makefile > cm3/m3-libs/libm3/src/os/POSIX/: m3makefile > cm3/m3-libs/libm3/src/os/WIN32/: m3makefile > Removed files: > cm3/m3-libs/libm3/src/os/Common/: Socket.i3 Socket.m3 > cm3/m3-libs/libm3/src/os/POSIX/: SocketPosix.m3 SocketPosixC.c > cm3/m3-libs/libm3/src/os/WIN32/: SocketWin32.m3 > SocketWin32.m3.sav > > Log message: > Nobody uses libm3's socket support. > So empty it out instead of fixing it. > Let's focus effort elsewhere, e.g. m3-comm/tcp. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Apr 19 20:05:15 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 19 Apr 2010 18:05:15 +0000 Subject: [M3devel] INTEGER In-Reply-To: <20100419172313.68B241A20D6@async.async.caltech.edu> References: , , ,,<7C7408D0-9A40-4988-BADA-A9FD8C15D388@cs.purdue.edu>, ,,, , , , , , , , , <20100418023535.3BA9E1A2103@async.async.caltech.edu>, , , , <20100418024703.6965B1A2103@async.async.caltech.edu>, , <20100418074927.934461A2117@async.async.caltech.edu>, <04EB7FF8-D304-428D-839E-233FCE009C98@cs.purdue.edu>, <20100418195901.CDACB1A20F6@async.async.caltech.edu>, , <20100419172313.68B241A20D6@async.async.caltech.edu> Message-ID: Mika, I must disagree on one point -- that people with large problems have 64bit machines. Large problem does not mean "large in memory" or large working set. It can mean "large on disk" and be combined with mostly sequential access to that disk. While 32bit is on the way out, we've had >2GB files for many years already, while 32bit was still very entrenched. You know -- disk costs vs. memory cost. It is memory beyond 4GB driving 64bit adoption, whereas disks went past 4GB long before at lower cost.. In your defense, I'll add "literals can be strings", something like: INTERFACE Int64; TYPE T = (* opaque! *) RECORD hi: INTEGER; low: Word.T; END; PROCEDURE Add(a,b:T):T; PROCEDURE Sub(a,b:T):T; PROCEDURE LT(a,b:T):BOOLEAN; PROCEDURE FromText(a:TEXT):T; <== PROCEDURE FromInt(a:INTEGER):T; PROCEDURE FromUInt64(a:UInt64.T):T RAISES{Overflow}; INTERFACE UInt64; TYPE T = (* opaque! *) RECORD hi, low: Word.T; END; PROCEDURE Add(a,b:T):T; PROCEDURE Sub(a,b:T):T; PROCEDURE LT(a,b:T):BOOLEAN; PROCEDURE FromText(a:TEXT):T; <== PROCEDURE FromInt(a:INTEGER):T; PROCEDURE FromInt64(a:Int64.T):T RAISES{Overflow}; thus reducing the need. Does Modula-3 offer opaque types whose size is known to the client? That is something I'd like, opacity without paying for heap allocation. (Notice these interfaces are circularly dependent, seems reasonable, but I believe not allowed?) ? I still say though, everyone prefers infix operators. "Things change". New needs are discovered. Better ways of doing things. Old restrictions fall away. Sometimes progress is made. Sometimes missteps are taken. I believe we even had some proposals that didn't change the language, e.g. big subranges or big packed types? TYPE INT64 = [-16_8000000000000000..16_7FFFFFFFFFFFFFFF] ? or TYPE INT64 = BITS 64 FOR[-16_8000000000000000..16_7FFFFFFFFFFFFFFF] ? but that's maybe not so simple? Well, I recently found that the compiler does chose sizes based on ranges: VAR a:[0..255] is only a byte, even without saying BITS 8 (at least when in a record). Do your language processing tools handle the notion that they are "cross compiling" to 64bit machines, where target integers don't fit in host integers? - Jay > To: hosking at cs.purdue.edu > Date: Mon, 19 Apr 2010 10:23:13 -0700 > From: mika at async.async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] INTEGER > > > Well *my* problem is that I still use PM3 for a lot of things. Trying to > switch to CM3, yes, but I can't "certify" CM3 for critical stuff yet. > > So I'm maintaining a significant amount of code that needs to compile > under both PM3 and CM3. Two problems crop up. > > 1. If there are bugs in m3tk/stubgen, the fixes only apply to one or > the other version of m3tk/stubgen. > > 2. Some of the code I'm maintaining processes Modula-3 code as input. > It needs to be in two versions. > > In this kind of environment, programming languages don't really > evolve, since the system depends on their being both forward- and > backward-compatible. They "change" is more correct. The way Java > changes. > > More in general, though, Modula-3's designers were clearly well acquainted > with C, Fortran, and other languages that provide different-range > integers. They chose not to indulge. I even have a version of Modula-3 > for a 16-bit machine that doesn't do it, even though on this machine the > need for a 32-bit integer is arguably greater than the need for 64-bit > integers on 32-bit machines. Now we indulge in this language complication > to solve what is clearly a temporary problem, since anyone who cares > about large problems is going to have 64-bit systems yesterday... and > meanwhile no one seems to have availed himself of the solution! > > My worst fear is that once the process gets started, the reason for > staying with the original Green-Book specification has now been defeated > and we will see more and more "evolution". Trying to actually build > systems that process Modula-3 like data becomes, at that point, like > trying to stand in quicksand. > > I'm not incredibly picky here... I just hope it doesn't go further. > I would personally support either sticking with the current status quo > or going back to the Green Book w.r.t. integers and characters. > > Saying that EWD wasn't renowned for his practicality is something he > would have taken as a great compliment, I'm sure. > > Mika > > Tony Hosking writes: > >Mika, > > > >First off, I'd be very interested to know what the issues are with = > >LONGINT and stubgen. We are building that every day in regression = > >testing. It would be really good to get some precise feedback. > > > >True, LONGINT is integrated with all of the language tools (same as = > >WIDECHAR). > > > >I suppose that is the price we pay for the language having evolved. = > >Nevertheless, CM3 should be totally backward compatible with the green = > >book. There is no reason it should not build packages from PM3 or SRC. > > > >Now, this is not to say that perhaps we haven't overreached with LONGINT = > >given that 64-bit is more prevalent. But then it is also useful to be = > >able to interoperate with C libraries. The previous interfacing was = > >pretty much a kludge, using ARRAY[0..1] OF INTEGER for "long long" but = > >then not propagating the double INTEGER value properly throughout the = > >Modula-3 libraries. > > > >I'm sorry to say that EWD was not particularly renowned for his = > >practicality; pedant more like. Nice to be high and mighty but we also = > >need to interact with the real world. > > > >We should be able to make this work. Is there a better alternative? = > >Revoke LONGINT, and WIDECHAR? > > > >On 18 Apr 2010, at 15:59, Mika Nystrom wrote: > > > >>=20 > >> My problem is really just that it's ugly. LONGx is showing up as an = > >issue > >> in all sorts of low-level code, which is not surprising since Modula-3 > >> with LONGx is not the same language as Modula-3 (maybe we should call > >> it Modula-3+?)=20 > >>=20 > >> The compiler bootstrapping process has gotten more complicated due to = > >it, > >> and when I cvs updated m3tk yesterday stubgen wouldn't compile because = > >there > >> was something "long" in it that wasn't there before. I have no idea = > >what > >> library or components I needed to update and recompile and didn't have = > >the > >> time to deal with the issue at the time. > >>=20 > >> And the new m3tk, stubgen, and compiler(?) won't compile using PM3 or > >> SRC M3 since we're no longer using the language of the Green Book. > >> (Same comment goes for WIDECHAR, by the way.) > >>=20 > >> One of the wonderful things about Modula-3 *used to be* that I could > >> grab some old package from DECSRC and just use it without changes = > >since > >> no one had messed with the language definition. This is still true as > >> far as programs that just use the tools go, but it's no longer true = > >for > >> programs that process Modula-3 code as input data. Of which there are > >> more than a few: many aspects of Modula-3 were specifically designed = > >to > >> make the language easy to process by program, as an intermediate = > >format > >> and whatnot. > >>=20 > >> To quote E.W.D.: > >>=20 > >> 'Unfathomed misunderstanding is further revealed by the term "software > >> maintenance", as a result of which many people continue to believe = > >that > >> programs and even programming languages themselves are subject to wear > >> and tear. Your car needs maintenance too, doesn't it? Famous is the = > >story > >> of the oil company that believed that its PASCAL programs did not last > >> as long as its FORTRAN programs "because PASCAL was not maintained".' > >>=20 > >> LONGx is causing me to have to do "software maintenance" on Modula-3 > >> programs... for a feature that no one appears to be using and is = > >quickly > >> becoming irrelevant. > >>=20 > >> Mika > >>=20 > >>=20 > >> Tony Hosking writes: > >>> In the language spec NUMBER(a) and LAST(a) - FIRST(a) + 1 are *not* =3D= > > > >>> defined to mean the same thing for all types. > >>> NUMBER does have an INTEGER value, as expected for subranges of = > >LONGINT =3D > >>> that are not too large. > >>> This is as it has always been for subranges of INTEGER that are not = > >too =3D > >>> large. > >>>=20 > >>> Mika, I'm not sure I see any of the problems you are worrying about = > >in =3D > >>> the current definition of LONGINT/LONGCARD. > >>>=20 > >>> On 18 Apr 2010, at 03:49, Mika Nystrom wrote: > >>>=20 > >>>> =3D20 > >>>> Jay I know most of this, and it doesn't really answer the question > >>>> "what is it for?" > >>>> =3D20 > >>>> I think we've already established that LONGINT isn't useful for =3D > >>> counting > >>>> anything that might actually reside in the computer's memory: it = > >makes > >>>> no sense as an array index, for instance. INTEGER suffices for = > >that. > >>>> =3D20 > >>>> I thought that the only real reason for LONGINT was to match C's > >>>> declaration of various seek-related routines on 32-bit machines. > >>>> That's not a very good reason. > >>>> =3D20 > >>>> C++ succeeds because it does very well in the area(s) it is good at. > >>>> People who want to program in C++ will clearly program in C++, not > >>>> Modula-3. Modula-3 is never, ever going to be the language of = > >choice =3D > >>> for > >>>> people who want lots of snazzy infix operators. Modula-3 is = > >supposed =3D > >>> to > >>>> be a language with about as powerful semantics as C++ and an = > >extremely > >>>> simple syntax and definition---snazzy infix is one of the things you > >>>> give up for that. I don't see how LONGINT fits into this picture. > >>>> Now we have LONGCARD too? And it's infected the definitions > >>>> of FIRST and LAST? But not NUMBER... argh! > >>>> =3D20 > >>>> so, > >>>> =3D20 > >>>> NUMBER(a) and LAST(a) - FIRST(a) + 1 > >>>> =3D20 > >>>> no longer mean the same thing? Are we going to see lots of comments > >>>> in generics in the future where it says T may not be an open array > >>>> type nor an array type indexed on LONGINT or a subrange thereof? > >>>> =3D20 > >>>> Your comments about different parameter-passing techniques was what = > >I =3D > >>> was > >>>> trying to address with my suggestion to have a pragma for = > >this---just =3D > >>> to > >>>> match C (and Fortran?), of course. Name me a single Modula-3 =3D > >>> programmer > >>>> who cares in what order the bits in his parameters are pushed on the > >>>> stack in a Modula-3-to-Modula-3 call. > >>>> =3D20 > >>>> And I am definitely in that school of thought that says that =3D > >>> programming > >>>> languages should not "evolve". Better to leave well enough alone. > >>>> =3D20 > >>>> How much Modula-3 code has been written that uses LONGINT? Other = > >than > >>>> to talk to C? I've certainly never used it. > >>>> =3D20 > >>>> Mika > >>>> =3D20 > >>>> =3D20 > >>>> =3D20 > >>>> Jay K writes: > >>>>> --_264cb69b-0215-44c3-807c-8b4d8ea0ea59_ > >>>>> Content-Type: text/plain; charset=3D3D"iso-8859-1" > >>>>> Content-Transfer-Encoding: quoted-printable > >>>>> =3D20 > >>>>> =3D20 > >>>>> TYPE LONGINT =3D3D3D ARRAY [0..1] OF INTEGER on a 32bit system is = > >very =3D > >>> close to=3D3D > >>>>> LONGINT. > >>>>> =3D20 > >>>>> Plus treating it opaquely and providing a bunch of functions to =3D > >>> operate on=3D3D > >>>>> it. > >>>>> =3D20 > >>>>> Just as well therefore could be RECORD hi=3D3D2Clo:LONGINT END (see = > >=3D > >>> LARGE_INTE=3D3D > >>>>> GER and ULARGE_INTEGER in winnt.h) > >>>>> =3D20 > >>>>> =3D3D20 > >>>>> =3D20 > >>>>> Differences that come to mind: > >>>>> =3D20 > >>>>> infix operators <=3D3D3D=3D3D3D=3D3D3D=3D3D20 > >>>>> =3D20 > >>>>> possibly passed differently as a parameter > >>>>> =3D20 > >>>>> or returned differently as a result > >>>>> =3D20 > >>>>> ie. probably "directly compatible with" "long long"=3D3D2C passed = > >by =3D > >>> value (o=3D3D > >>>>> f course you could always pass by pointer and achieve = > >compatibilitity =3D > >>> trivi=3D3D > >>>>> ally) > >>>>> =3D20 > >>>>> =3D3D20 > >>>>> =3D20 > >>>>> =3D3D20 > >>>>> =3D20 > >>>>> I have to say though=3D3D2C the biggest reason is in-fix operators. = > >=3D > >>> Convenient =3D3D > >>>>> syntax. > >>>>> =3D20 > >>>>> C++ is the best and some way worst of example of the general right = > >=3D > >>> way to d=3D3D > >>>>> o this -- you let programmers define types and their infix = > >operators. =3D > >>> Other=3D3D > >>>>> languages just come with a passle of special cases of types that = > >have =3D > >>> in-f=3D3D > >>>>> ix operators. > >>>>> =3D20 > >>>>> A good example is that Java infix operator + on string=3D3D2C = > >besides =3D > >>> the vario=3D3D > >>>>> us integers=3D3D2C and nothing else. > >>>>> =3D20 > >>>>> =3D3D20 > >>>>> =3D20 > >>>>> =3D3D20 > >>>>> =3D20 > >>>>> I think C# lets you define operators=3D3D2C yet people don't = > >complain =3D > >>> that it i=3D3D > >>>>> s "a mess" as they do of C++. > >>>>> =3D20 > >>>>> I think Python does now too. > >>>>> =3D20 > >>>>> So it is feature growing in popularity among "mainstream" =3D > >>> languages=3D3D2C not =3D3D > >>>>> just C++. > >>>>> =3D20 > >>>>> C++ of course is extremely mainstream=3D3D2C but also a favorite =3D > >>> target. (ht=3D3D > >>>>> tp://www.relisoft.com/tools/CppCritic.html) > >>>>> =3D20 > >>>>> =3D3D20 > >>>>> =3D20 > >>>>> =3D3D20 > >>>>> =3D20 > >>>>> We also have subranges of LONGINT. > >>>>> =3D20 > >>>>> I'm not sure what the generalization of subranges are=3D3D2C = > >granted. > >>>>> =3D20 > >>>>> Maybe some sort of C++ template that takes constants in the = > >template =3D > >>> and d=3D3D > >>>>> oes range checks at runtime. Yeah=3D3D2C maybe. > >>>>> =3D20 > >>>>> =3D3D20 > >>>>> =3D20 > >>>>> =3D3D20 > >>>>> =3D20 > >>>>> And as you point out=3D3D2C convenient literal syntax. > >>>>> =3D20 > >>>>> =3D3D20 > >>>>> =3D20 > >>>>> =3D3D20 > >>>>> =3D20 > >>>>> People reasonably argue for library extension in place of language = > >=3D > >>> extensio=3D3D > >>>>> n=3D3D2C but that requires a language which is flexible enough to = > >write =3D > >>> librari=3D3D > >>>>> es with the desired interface=3D3D2C and so many languages don't = > >let =3D > >>> infix oper=3D3D > >>>>> ators be in a user-written library. > >>>>> =3D20 > >>>>> (There is a subtle but useless distinction here -- infix operators = > >=3D > >>> being in=3D3D > >>>>> libraries vs. "user-written" libraries. The infix set operations = > >for =3D > >>> examp=3D3D > >>>>> le are in a library=3D3D2C but not user-written=3D3D2C special=3D3D2C= > > the =3D > >>> compiler know=3D3D > >>>>> s about it.) > >>>>> =3D20 > >>>>> =3D3D20 > >>>>> =3D20 > >>>>>> that would perhaps not match how C handles "long long" on the same > >>>>>> platform (which is how=3D3D2C come to think of it?)=3D3D2C and = > >that =3D > >>> would require > >>>>> =3D20 > >>>>> =3D20 > >>>>> =3D3D20 > >>>>> =3D20 > >>>>> On NT/x86=3D3D2C __int64/long long is returned in the register pair = > >=3D > >>> edx:eax. > >>>>> =3D20 > >>>>> edx is high=3D3D2C eax is low. > >>>>> =3D20 > >>>>> When passed as a parameter to __stdcall or __cdecl is just passed = > >as =3D > >>> two 32=3D3D > >>>>> bit values adjacent on the stack=3D3D2C "hi=3D3D2C lo=3D3D2C = > >hi=3D3D2C lo=3D3D2C =3D > >>> it's off to pu=3D3D > >>>> sh we go" is the Snow White-influenced mantra to remember how to = > >pass =3D > >>> them=3D3D > >>>>> =3D3D2C at least on little endian stack-growing-down machines = > >(which =3D > >>> includes x=3D3D > >>>>> 86). For __fastcall I'm not sure they are passed in registers or on = > >=3D > >>> the sta=3D3D > >>>>> ck. > >>>>> =3D20 > >>>>> Passing and/or returning small structs also has special efficient =3D= > > > >>> handling =3D3D > >>>>> in the ABI=3D3D2C so __int64 really might be equivalent to a small = > >=3D > >>> record. Not =3D3D > >>>>> that cm3 necessarily implements that "correctly" -- for interop = > >with =3D > >>> C=3D3D3B =3D3D > >>>>> for Modula-3 calling Modula-3 we can make up our own ABI so there =3D= > > > >>> isn't rea=3D3D > >>>>> lly an "incorrect" way. Notice the mingw problem I had passing a =3D > >>> Win32 poin=3D3D > >>>>> t struct by value=3D3D2C I cheated and passed it by VAR to a C = > >wrapper =3D > >>> to worka=3D3D > >>>>> round the gcc backend bug (which was mentioned a few times and = > >which =3D > >>> I look=3D3D > >>>>> ed into the code for=3D3D2C but took the easy route) > >>>>> =3D20 > >>>>> =3D3D20 > >>>>> =3D20 > >>>>> =3D3D20 > >>>>> =3D20 > >>>>> I don't know how long long works on other platforms but probably =3D > >>> similar. > >>>>> =3D20 > >>>>> Probably a certain register pair for return values. > >>>>> =3D20 > >>>>> =3D3D20 > >>>>> =3D20 > >>>>> - Jay > >>>>> =3D20 > >>>>> =3D3D20 > >>>>>> To: hosking at cs.purdue.edu > >>>>>> Date: Sat=3D3D2C 17 Apr 2010 19:47:03 -0700 > >>>>>> From: mika at async.async.caltech.edu > >>>>>> CC: m3devel at elegosoft.com > >>>>>> Subject: Re: [M3devel] INTEGER > >>>>>> =3D3D20 > >>>>>> Tony Hosking writes: > >>>>>>> =3D20 > >>>>>> ... > >>>>>>> =3D20 > >>>>>>>> We need it to match 64-bit integers on 32-bit machines? That = > >seems =3D > >>> =3D3D3D > >>>>>>> like > >>>>>>>> a very weak rationale indeed=3D3D2C if the same functionality = > >could =3D > >>> be =3D3D3D > >>>>>>> provided > >>>>>>>> through some other mechanism (e.g.=3D3D2C ARRAY [0..1] OF =3D > >>> INTEGER---even =3D3D > >>>>> =3D3D3D > >>>>>>> with > >>>>>>>> a pragma e.g. <*CLONGLONG*>.. if it is necessary to tell the =3D > >>> compiler =3D3D > >>>>> =3D3D3D > >>>>>>> that > >>>>>>>> a special linkage convention is needed). > >>>>>>> =3D20 > >>>>>>> There's no special linkage convention. Not sure what you mean = > >here. > >>>>>>> =3D20 > >>>>>> =3D3D20 > >>>>>> I just mean if we had > >>>>>> =3D3D20 > >>>>>> TYPE LONGINT =3D3D3D ARRAY [0..1] OF INTEGER > >>>>>> =3D3D20 > >>>>>> that would perhaps not match how C handles "long long" on the same > >>>>>> platform (which is how=3D3D2C come to think of it?)=3D3D2C and = > >that =3D > >>> would require > >>>>>> special linkage tricks. > >>>>>> =3D3D20 > >>>>>> But what would be lost? The ability to type literals.=3D3D20 > >>>>>> =3D3D20 > >>>>>> You could get the same code interface on 32- and 64-bit machine by > >>>>>> defining > >>>>>> =3D3D20 > >>>>>> TYPE FileOffset =3D3D3D ARRAY[0..1] OF [-16_80000000 .. = > >+16_7fffffff ] > >>>>>> =3D3D20 > >>>>>> and using that. > >>>>>> =3D3D20 > >>>>>> =3D3D20 > >>>>>> Mika > >>>>> =3D3D > >>>>> =3D20 > >>>>> --_264cb69b-0215-44c3-807c-8b4d8ea0ea59_ > >>>>> Content-Type: text/html; charset=3D3D"iso-8859-1" > >>>>> Content-Transfer-Encoding: quoted-printable > >>>>> =3D20 > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> TYPE LONGINT =3D3D3D ARRAY [0..1] OF INTEGER on a =3D3D3B32bit = > >system =3D > >>> is very c=3D3D > >>>>> lose to LONGINT.
> >>>>>  =3D3D3BPlus treating it opaquely and providing a bunch of =3D > >>> functions to ope=3D3D > >>>>> rate on it.
> >>>>>  =3D3D3BJust as well therefore could be RECORD = > >hi=3D3D2Clo:LONGINT =3D > >>> END (see LAR=3D3D > >>>>> GE_INTEGER and ULARGE_INTEGER in winnt.h)
> >>>>>  =3D3D3B
> >>>>> Differences that come to mind:
> >>>>>  =3D3D3B =3D3D3Binfix operators =3D3D3B = > ><=3D3D3B=3D3D3D=3D3D3D=3D3D3D =3D > >>>
> >>>>>  =3D3D3B possibly passed differently =3D3D3Bas a = > >parameter
> >>>>>  =3D3D3B or returned differently as a result
> >>>>>  =3D3D3B ie. probably "directly compatible with" "long = > >long"=3D3D2C =3D > >>> passed by v=3D3D > >>>>> alue (of course you could always pass by pointer and achieve =3D > >>> compatibilitit=3D3D > >>>>> y trivially)
> >>>>>  =3D3D3B
> >>>>>  =3D3D3B
> >>>>> I have to say though=3D3D2C the biggest reason is in-fix operators. = > >=3D > >>> Convenient =3D3D > >>>>> syntax.
> >>>>> C++ is the best and some way worst of example of the general right = > >=3D > >>> way to d=3D3D > >>>>> o this -- you let programmers define types and their infix = > >operators. =3D > >>> Other=3D3D > >>>>> languages just come with a passle of special cases of types that = > >have =3D > >>> in-f=3D3D > >>>>> ix operators.
> >>>>> A good example is that Java infix operator + on string=3D3D2C = > >besides =3D > >>> the vario=3D3D > >>>>> us integers=3D3D2C and nothing else.
> >>>>>  =3D3D3B
> >>>>>  =3D3D3B
> >>>>> I think C# lets you define operators=3D3D2C yet people don't = > >complain =3D > >>> that it i=3D3D > >>>>> s "a mess" as they do of C++.
> >>>>> I think Python does now too.
> >>>>> So it is feature growing in popularity among "mainstream" =3D > >>> languages=3D3D2C not =3D3D > >>>>> just C++.
> >>>>>  =3D3D3B =3D3D3B C++ of course is extremely mainstream=3D3D2C= > > but =3D > >>> also a favori=3D3D > >>>>> te target. ( >>> href=3D3D3D"http://www.relisoft.com/tools/CppCritic.html">http:/=3D3D > >>>>> /www.relisoft.com/tools/CppCritic.html)
> >>>>>  =3D3D3B
> >>>>>  =3D3D3B
> >>>>> We also have subranges of LONGINT.
> >>>>> I'm not sure what the generalization of subranges are=3D3D2C =3D > >>> granted.
> >>>>>  =3D3D3BMaybe some sort of C++ template that takes constants in = > >the =3D > >>> templat=3D3D > >>>>> e and does range checks at runtime. Yeah=3D3D2C maybe.
> >>>>>  =3D3D3B
> >>>>>  =3D3D3B
> >>>>> And as you point out=3D3D2C convenient literal syntax.
> >>>>>  =3D3D3B
> >>>>>  =3D3D3B
> >>>>> People reasonably argue for library extension in place of language = > >=3D > >>> extensio=3D3D > >>>>> n=3D3D2C but that requires a language which is flexible enough to = > >write =3D > >>> librari=3D3D > >>>>> es with the desired interface=3D3D2C and so many languages don't = > >let =3D > >>> infix oper=3D3D > >>>>> ators be in a user-written library.
> >>>>> (There is a subtle but useless distinction here -- infix operators = > >=3D > >>> being in=3D3D > >>>>> libraries vs. "user-written" libraries. The infix set operations = > >for =3D > >>> examp=3D3D > >>>>> le are in a library=3D3D2C but not user-written=3D3D2C special=3D3D2C= > > the =3D > >>> compiler know=3D3D > >>>>> s about it.)
> >>>>>  =3D3D3B
> >>>>> >=3D3D3B that would perhaps not match how C handles "long long" = > >on =3D > >>> the same >>>>> R>>=3D3D3B platform (which is how=3D3D2C come to think of = > >it?)=3D3D2C and =3D > >>> that would =3D3D > >>>>> require

> >>>>>  =3D3D3B
> >>>>> On NT/x86=3D3D2C __int64/long long is returned in the register pair = > >=3D > >>> edx:eax. >>>>>> =3D20 > >>>>> edx is high=3D3D2C eax is low.
> >>>>> When passed as a parameter to __stdcall or __cdecl is just passed = > >as =3D > >>> two 32=3D3D > >>>>> bit values adjacent on the stack=3D3D2C "hi=3D3D2C lo=3D3D2C = > >hi=3D3D2C lo=3D3D2C =3D > >>> it's off to pu=3D3D > >>>>> sh we go" is the Snow White-influenced mantra to remember how to = > >pass =3D > >>> them=3D3D > >>>>> =3D3D2C at least on little endian stack-growing-down machines = > >(which =3D > >>> includes x=3D3D > >>>>> 86). For __fastcall I'm not sure they are passed in registers or on = > >=3D > >>> the sta=3D3D > >>>>> ck.
> >>>>> Passing and/or returning small structs also has special efficient =3D= > > > >>> handling =3D3D > >>>>> in the ABI=3D3D2C so __int64 really might be equivalent to a small = > >=3D > >>> record. Not =3D3D > >>>>> that cm3 necessarily implements that "correctly" =3D3D3B -- for = > >=3D > >>> interop wit=3D3D > >>>>> h C=3D3D3B for Modula-3 calling Modula-3 we can make up our own ABI = > >so =3D > >>> there is=3D3D > >>>>> n't =3D3D3Breally an "incorrect" way. =3D3D3BNotice the = > >mingw =3D > >>> problem I had=3D3D > >>>>> passing a Win32 point struct by value=3D3D2C I cheated and passed = > >it by =3D > >>> VAR to=3D3D > >>>>> a =3D3D3BC wrapper to workaround the gcc backend bug (which was = > >=3D > >>> mentioned =3D3D > >>>>> a few times and which I looked into the code for=3D3D2C but took = > >the =3D > >>> easy route=3D3D > >>>>> )
> >>>>>  =3D3D3B
> >>>>>  =3D3D3B
> >>>>> I don't know how long long works on other platforms but probably =3D > >>> similar. >>>>> R> > >>>>> Probably a certain register pair for return values.
> >>>>>  =3D3D3B
> >>>>>  =3D3D3B- Jay

 =3D3D3B
>=3D3D3B To: =3D > >>> hosking at cs.purdue.edu
>=3D3D3B=3D3D > >>>>> Date: Sat=3D3D2C 17 Apr 2010 19:47:03 -0700
>=3D3D3B From: =3D > >>> mika at async.async.c=3D3D > >>>>> altech.edu
>=3D3D3B CC: m3devel at elegosoft.com
>=3D3D3B = > >Subject: =3D > >>> Re: [M3de=3D3D > >>>>> vel] INTEGER
>=3D3D3B
>=3D3D3B Tony Hosking = > >writes:
>=3D3D3B =3D > >>> >=3D3D3B
=3D3D > >>>>> >=3D3D3B ...
>=3D3D3B >=3D3D3B
>=3D3D3B = > >>=3D3D3B>=3D3D3B We =3D > >>> need it to match 64-b=3D3D > >>>>> it integers on 32-bit machines? That seems =3D3D3D
>=3D3D3B =3D > >>> >=3D3D3Blike
>=3D3D > >>>>> =3D3D3B >=3D3D3B>=3D3D3B a very weak rationale indeed=3D3D2C if = > >the same =3D > >>> functionality =3D3D > >>>>> could be =3D3D3D
>=3D3D3B >=3D3D3Bprovided
>=3D3D3B = > >>=3D3D3B>=3D3D3=3D > >>> B through some o=3D3D > >>>>> ther mechanism (e.g.=3D3D2C ARRAY [0..1] OF INTEGER---even =3D > >>> =3D3D3D
>=3D3D3B >=3D3D3B=3D3D > >>>>> with
>=3D3D3B >=3D3D3B>=3D3D3B a pragma e.g. =3D > >>> <=3D3D3B*CLONGLONG*>=3D3D3B.. if it i=3D3D > >>>>> s necessary to tell the compiler =3D3D3D
>=3D3D3B =3D > >>> >=3D3D3Bthat
>=3D3D3B >=3D3D3B&=3D3D > >>>>> gt=3D3D3B a special linkage convention is needed).
>=3D3D3B =3D > >>> >=3D3D3B
>=3D3D3B &=3D3D > >>>>> gt=3D3D3BThere's no special linkage convention. Not sure what you = > >mean =3D > >>> here. >>>>>> >=3D3D3B >=3D3D3B
>=3D3D3B
>=3D3D3B I just mean if = > >we =3D > >>> had
>=3D3D3B
>=3D3D > >>>>> =3D3D3B TYPE LONGINT =3D3D3D ARRAY [0..1] OF INTEGER
>=3D3D3B = > >=3D > >>>
>=3D3D3B that woul=3D3D > >>>>> d perhaps not match how C handles "long long" on the = > >same
>=3D3D3B =3D > >>> platfor=3D3D > >>>>> m (which is how=3D3D2C come to think of it?)=3D3D2C and that would = > >=3D > >>> require
>=3D3D > >>>>> =3D3D3B special linkage tricks.
>=3D3D3B
>=3D3D3B But = > >what would =3D > >>> be lost? Th=3D3D > >>>>> e ability to type literals.
>=3D3D3B
>=3D3D3B You could = > >get =3D > >>> the same co=3D3D > >>>>> de interface on 32- and 64-bit machine by
>=3D3D3B =3D > >>> defining
>=3D3D3B
=3D3D > >>>>> >=3D3D3B TYPE FileOffset =3D3D3D ARRAY[0..1] OF [-16_80000000 .. = > >=3D > >>> +16_7fffffff ] >>>>> R>>=3D3D3B
>=3D3D3B and using that.
>=3D3D3B = > >
>=3D3D3B =3D > >>>
>=3D3D3B Mika >>>>>> > >>>>> =3D3D > >>>>> =3D20 > >>>>> --_264cb69b-0215-44c3-807c-8b4d8ea0ea59_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Apr 19 20:44:00 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 19 Apr 2010 14:44:00 -0400 Subject: [M3devel] INTEGER In-Reply-To: <20100419172313.68B241A20D6@async.async.caltech.edu> References: , , , <7C7408D0-9A40-4988-BADA-A9FD8C15D388@cs.purdue.edu>, , , , , , , <20100418023535.3BA9E1A2103@async.async.caltech.edu>, , <20100418024703.6965B1A2103@async.async.caltech.edu> <20100418074927.934461A2117@async.async.caltech.edu> <04EB7FF8-D304-428D-839E-233FCE009C98@cs.purdue.edu> <20100418195901.CDACB1A20F6@async.async.caltech.edu> <20100419172313.68B241A20D6@async.async.caltech.edu> Message-ID: <4F3EE437-0298-410B-9642-C0381E333430@cs.purdue.edu> On 19 Apr 2010, at 13:23, Mika Nystrom wrote: > > Well *my* problem is that I still use PM3 for a lot of things. Trying to > switch to CM3, yes, but I can't "certify" CM3 for critical stuff yet. > > So I'm maintaining a significant amount of code that needs to compile > under both PM3 and CM3. Two problems crop up. > > 1. If there are bugs in m3tk/stubgen, the fixes only apply to one or > the other version of m3tk/stubgen. > > 2. Some of the code I'm maintaining processes Modula-3 code as input. > It needs to be in two versions. > > In this kind of environment, programming languages don't really > evolve, since the system depends on their being both forward- and > backward-compatible. They "change" is more correct. The way Java > changes. Indeed: Growing a Language, by Guy Steele > > More in general, though, Modula-3's designers were clearly well acquainted > with C, Fortran, and other languages that provide different-range > integers. They chose not to indulge. I even have a version of Modula-3 > for a 16-bit machine that doesn't do it, even though on this machine the > need for a 32-bit integer is arguably greater than the need for 64-bit > integers on 32-bit machines. Now we indulge in this language complication > to solve what is clearly a temporary problem, since anyone who cares > about large problems is going to have 64-bit systems yesterday... and > meanwhile no one seems to have availed himself of the solution! If we were to revert, I have no idea what the implications would be. Jay? > My worst fear is that once the process gets started, the reason for > staying with the original Green-Book specification has now been defeated > and we will see more and more "evolution". Trying to actually build > systems that process Modula-3 like data becomes, at that point, like > trying to stand in quicksand. Indeed! > > I'm not incredibly picky here... I just hope it doesn't go further. > I would personally support either sticking with the current status quo > or going back to the Green Book w.r.t. integers and characters. Indeed, I would not want to see this go any further. I am still not sure I am comfortable with the LONGINT extension (even though I put a lot of time into it). There just seemed to be a lot of pressure for it to so CM3 could handle large file indexes. I've never been convinced that WIDECHAR was a winner either -- it was a reflexive action in the face of Java's Unicode. The CM3 people were building a Java VM above CM3 at the time. > > Saying that EWD wasn't renowned for his practicality is something he > would have taken as a great compliment, I'm sure. ;-) > > Mika > > Tony Hosking writes: >> Mika, >> >> First off, I'd be very interested to know what the issues are with = >> LONGINT and stubgen. We are building that every day in regression = >> testing. It would be really good to get some precise feedback. >> >> True, LONGINT is integrated with all of the language tools (same as = >> WIDECHAR). >> >> I suppose that is the price we pay for the language having evolved. = >> Nevertheless, CM3 should be totally backward compatible with the green = >> book. There is no reason it should not build packages from PM3 or SRC. >> >> Now, this is not to say that perhaps we haven't overreached with LONGINT = >> given that 64-bit is more prevalent. But then it is also useful to be = >> able to interoperate with C libraries. The previous interfacing was = >> pretty much a kludge, using ARRAY[0..1] OF INTEGER for "long long" but = >> then not propagating the double INTEGER value properly throughout the = >> Modula-3 libraries. >> >> I'm sorry to say that EWD was not particularly renowned for his = >> practicality; pedant more like. Nice to be high and mighty but we also = >> need to interact with the real world. >> >> We should be able to make this work. Is there a better alternative? = >> Revoke LONGINT, and WIDECHAR? >> >> On 18 Apr 2010, at 15:59, Mika Nystrom wrote: >> >>> =20 >>> My problem is really just that it's ugly. LONGx is showing up as an = >> issue >>> in all sorts of low-level code, which is not surprising since Modula-3 >>> with LONGx is not the same language as Modula-3 (maybe we should call >>> it Modula-3+?)=20 >>> =20 >>> The compiler bootstrapping process has gotten more complicated due to = >> it, >>> and when I cvs updated m3tk yesterday stubgen wouldn't compile because = >> there >>> was something "long" in it that wasn't there before. I have no idea = >> what >>> library or components I needed to update and recompile and didn't have = >> the >>> time to deal with the issue at the time. >>> =20 >>> And the new m3tk, stubgen, and compiler(?) won't compile using PM3 or >>> SRC M3 since we're no longer using the language of the Green Book. >>> (Same comment goes for WIDECHAR, by the way.) >>> =20 >>> One of the wonderful things about Modula-3 *used to be* that I could >>> grab some old package from DECSRC and just use it without changes = >> since >>> no one had messed with the language definition. This is still true as >>> far as programs that just use the tools go, but it's no longer true = >> for >>> programs that process Modula-3 code as input data. Of which there are >>> more than a few: many aspects of Modula-3 were specifically designed = >> to >>> make the language easy to process by program, as an intermediate = >> format >>> and whatnot. >>> =20 >>> To quote E.W.D.: >>> =20 >>> 'Unfathomed misunderstanding is further revealed by the term "software >>> maintenance", as a result of which many people continue to believe = >> that >>> programs and even programming languages themselves are subject to wear >>> and tear. Your car needs maintenance too, doesn't it? Famous is the = >> story >>> of the oil company that believed that its PASCAL programs did not last >>> as long as its FORTRAN programs "because PASCAL was not maintained".' >>> =20 >>> LONGx is causing me to have to do "software maintenance" on Modula-3 >>> programs... for a feature that no one appears to be using and is = >> quickly >>> becoming irrelevant. >>> =20 >>> Mika >>> =20 >>> =20 >>> Tony Hosking writes: >>>> In the language spec NUMBER(a) and LAST(a) - FIRST(a) + 1 are *not* =3D= >> >>>> defined to mean the same thing for all types. >>>> NUMBER does have an INTEGER value, as expected for subranges of = >> LONGINT =3D >>>> that are not too large. >>>> This is as it has always been for subranges of INTEGER that are not = >> too =3D >>>> large. >>>> =20 >>>> Mika, I'm not sure I see any of the problems you are worrying about = >> in =3D >>>> the current definition of LONGINT/LONGCARD. >>>> =20 >>>> On 18 Apr 2010, at 03:49, Mika Nystrom wrote: >>>> =20 >>>>> =3D20 >>>>> Jay I know most of this, and it doesn't really answer the question >>>>> "what is it for?" >>>>> =3D20 >>>>> I think we've already established that LONGINT isn't useful for =3D >>>> counting >>>>> anything that might actually reside in the computer's memory: it = >> makes >>>>> no sense as an array index, for instance. INTEGER suffices for = >> that. >>>>> =3D20 >>>>> I thought that the only real reason for LONGINT was to match C's >>>>> declaration of various seek-related routines on 32-bit machines. >>>>> That's not a very good reason. >>>>> =3D20 >>>>> C++ succeeds because it does very well in the area(s) it is good at. >>>>> People who want to program in C++ will clearly program in C++, not >>>>> Modula-3. Modula-3 is never, ever going to be the language of = >> choice =3D >>>> for >>>>> people who want lots of snazzy infix operators. Modula-3 is = >> supposed =3D >>>> to >>>>> be a language with about as powerful semantics as C++ and an = >> extremely >>>>> simple syntax and definition---snazzy infix is one of the things you >>>>> give up for that. I don't see how LONGINT fits into this picture. >>>>> Now we have LONGCARD too? And it's infected the definitions >>>>> of FIRST and LAST? But not NUMBER... argh! >>>>> =3D20 >>>>> so, >>>>> =3D20 >>>>> NUMBER(a) and LAST(a) - FIRST(a) + 1 >>>>> =3D20 >>>>> no longer mean the same thing? Are we going to see lots of comments >>>>> in generics in the future where it says T may not be an open array >>>>> type nor an array type indexed on LONGINT or a subrange thereof? >>>>> =3D20 >>>>> Your comments about different parameter-passing techniques was what = >> I =3D >>>> was >>>>> trying to address with my suggestion to have a pragma for = >> this---just =3D >>>> to >>>>> match C (and Fortran?), of course. Name me a single Modula-3 =3D >>>> programmer >>>>> who cares in what order the bits in his parameters are pushed on the >>>>> stack in a Modula-3-to-Modula-3 call. >>>>> =3D20 >>>>> And I am definitely in that school of thought that says that =3D >>>> programming >>>>> languages should not "evolve". Better to leave well enough alone. >>>>> =3D20 >>>>> How much Modula-3 code has been written that uses LONGINT? Other = >> than >>>>> to talk to C? I've certainly never used it. >>>>> =3D20 >>>>> Mika >>>>> =3D20 >>>>> =3D20 >>>>> =3D20 >>>>> Jay K writes: >>>>>> --_264cb69b-0215-44c3-807c-8b4d8ea0ea59_ >>>>>> Content-Type: text/plain; charset=3D3D"iso-8859-1" >>>>>> Content-Transfer-Encoding: quoted-printable >>>>>> =3D20 >>>>>> =3D20 >>>>>> TYPE LONGINT =3D3D3D ARRAY [0..1] OF INTEGER on a 32bit system is = >> very =3D >>>> close to=3D3D >>>>>> LONGINT. >>>>>> =3D20 >>>>>> Plus treating it opaquely and providing a bunch of functions to =3D >>>> operate on=3D3D >>>>>> it. >>>>>> =3D20 >>>>>> Just as well therefore could be RECORD hi=3D3D2Clo:LONGINT END (see = >> =3D >>>> LARGE_INTE=3D3D >>>>>> GER and ULARGE_INTEGER in winnt.h) >>>>>> =3D20 >>>>>> =3D3D20 >>>>>> =3D20 >>>>>> Differences that come to mind: >>>>>> =3D20 >>>>>> infix operators <=3D3D3D=3D3D3D=3D3D3D=3D3D20 >>>>>> =3D20 >>>>>> possibly passed differently as a parameter >>>>>> =3D20 >>>>>> or returned differently as a result >>>>>> =3D20 >>>>>> ie. probably "directly compatible with" "long long"=3D3D2C passed = >> by =3D >>>> value (o=3D3D >>>>>> f course you could always pass by pointer and achieve = >> compatibilitity =3D >>>> trivi=3D3D >>>>>> ally) >>>>>> =3D20 >>>>>> =3D3D20 >>>>>> =3D20 >>>>>> =3D3D20 >>>>>> =3D20 >>>>>> I have to say though=3D3D2C the biggest reason is in-fix operators. = >> =3D >>>> Convenient =3D3D >>>>>> syntax. >>>>>> =3D20 >>>>>> C++ is the best and some way worst of example of the general right = >> =3D >>>> way to d=3D3D >>>>>> o this -- you let programmers define types and their infix = >> operators. =3D >>>> Other=3D3D >>>>>> languages just come with a passle of special cases of types that = >> have =3D >>>> in-f=3D3D >>>>>> ix operators. >>>>>> =3D20 >>>>>> A good example is that Java infix operator + on string=3D3D2C = >> besides =3D >>>> the vario=3D3D >>>>>> us integers=3D3D2C and nothing else. >>>>>> =3D20 >>>>>> =3D3D20 >>>>>> =3D20 >>>>>> =3D3D20 >>>>>> =3D20 >>>>>> I think C# lets you define operators=3D3D2C yet people don't = >> complain =3D >>>> that it i=3D3D >>>>>> s "a mess" as they do of C++. >>>>>> =3D20 >>>>>> I think Python does now too. >>>>>> =3D20 >>>>>> So it is feature growing in popularity among "mainstream" =3D >>>> languages=3D3D2C not =3D3D >>>>>> just C++. >>>>>> =3D20 >>>>>> C++ of course is extremely mainstream=3D3D2C but also a favorite =3D >>>> target. (ht=3D3D >>>>>> tp://www.relisoft.com/tools/CppCritic.html) >>>>>> =3D20 >>>>>> =3D3D20 >>>>>> =3D20 >>>>>> =3D3D20 >>>>>> =3D20 >>>>>> We also have subranges of LONGINT. >>>>>> =3D20 >>>>>> I'm not sure what the generalization of subranges are=3D3D2C = >> granted. >>>>>> =3D20 >>>>>> Maybe some sort of C++ template that takes constants in the = >> template =3D >>>> and d=3D3D >>>>>> oes range checks at runtime. Yeah=3D3D2C maybe. >>>>>> =3D20 >>>>>> =3D3D20 >>>>>> =3D20 >>>>>> =3D3D20 >>>>>> =3D20 >>>>>> And as you point out=3D3D2C convenient literal syntax. >>>>>> =3D20 >>>>>> =3D3D20 >>>>>> =3D20 >>>>>> =3D3D20 >>>>>> =3D20 >>>>>> People reasonably argue for library extension in place of language = >> =3D >>>> extensio=3D3D >>>>>> n=3D3D2C but that requires a language which is flexible enough to = >> write =3D >>>> librari=3D3D >>>>>> es with the desired interface=3D3D2C and so many languages don't = >> let =3D >>>> infix oper=3D3D >>>>>> ators be in a user-written library. >>>>>> =3D20 >>>>>> (There is a subtle but useless distinction here -- infix operators = >> =3D >>>> being in=3D3D >>>>>> libraries vs. "user-written" libraries. The infix set operations = >> for =3D >>>> examp=3D3D >>>>>> le are in a library=3D3D2C but not user-written=3D3D2C special=3D3D2C= >> the =3D >>>> compiler know=3D3D >>>>>> s about it.) >>>>>> =3D20 >>>>>> =3D3D20 >>>>>> =3D20 >>>>>>> that would perhaps not match how C handles "long long" on the same >>>>>>> platform (which is how=3D3D2C come to think of it?)=3D3D2C and = >> that =3D >>>> would require >>>>>> =3D20 >>>>>> =3D20 >>>>>> =3D3D20 >>>>>> =3D20 >>>>>> On NT/x86=3D3D2C __int64/long long is returned in the register pair = >> =3D >>>> edx:eax. >>>>>> =3D20 >>>>>> edx is high=3D3D2C eax is low. >>>>>> =3D20 >>>>>> When passed as a parameter to __stdcall or __cdecl is just passed = >> as =3D >>>> two 32=3D3D >>>>>> bit values adjacent on the stack=3D3D2C "hi=3D3D2C lo=3D3D2C = >> hi=3D3D2C lo=3D3D2C =3D >>>> it's off to pu=3D3D >>>>> sh we go" is the Snow White-influenced mantra to remember how to = >> pass =3D >>>> them=3D3D >>>>>> =3D3D2C at least on little endian stack-growing-down machines = >> (which =3D >>>> includes x=3D3D >>>>>> 86). For __fastcall I'm not sure they are passed in registers or on = >> =3D >>>> the sta=3D3D >>>>>> ck. >>>>>> =3D20 >>>>>> Passing and/or returning small structs also has special efficient =3D= >> >>>> handling =3D3D >>>>>> in the ABI=3D3D2C so __int64 really might be equivalent to a small = >> =3D >>>> record. Not =3D3D >>>>>> that cm3 necessarily implements that "correctly" -- for interop = >> with =3D >>>> C=3D3D3B =3D3D >>>>>> for Modula-3 calling Modula-3 we can make up our own ABI so there =3D= >> >>>> isn't rea=3D3D >>>>>> lly an "incorrect" way. Notice the mingw problem I had passing a =3D >>>> Win32 poin=3D3D >>>>>> t struct by value=3D3D2C I cheated and passed it by VAR to a C = >> wrapper =3D >>>> to worka=3D3D >>>>>> round the gcc backend bug (which was mentioned a few times and = >> which =3D >>>> I look=3D3D >>>>>> ed into the code for=3D3D2C but took the easy route) >>>>>> =3D20 >>>>>> =3D3D20 >>>>>> =3D20 >>>>>> =3D3D20 >>>>>> =3D20 >>>>>> I don't know how long long works on other platforms but probably =3D >>>> similar. >>>>>> =3D20 >>>>>> Probably a certain register pair for return values. >>>>>> =3D20 >>>>>> =3D3D20 >>>>>> =3D20 >>>>>> - Jay >>>>>> =3D20 >>>>>> =3D3D20 >>>>>>> To: hosking at cs.purdue.edu >>>>>>> Date: Sat=3D3D2C 17 Apr 2010 19:47:03 -0700 >>>>>>> From: mika at async.async.caltech.edu >>>>>>> CC: m3devel at elegosoft.com >>>>>>> Subject: Re: [M3devel] INTEGER >>>>>>> =3D3D20 >>>>>>> Tony Hosking writes: >>>>>>>> =3D20 >>>>>>> ... >>>>>>>> =3D20 >>>>>>>>> We need it to match 64-bit integers on 32-bit machines? That = >> seems =3D >>>> =3D3D3D >>>>>>>> like >>>>>>>>> a very weak rationale indeed=3D3D2C if the same functionality = >> could =3D >>>> be =3D3D3D >>>>>>>> provided >>>>>>>>> through some other mechanism (e.g.=3D3D2C ARRAY [0..1] OF =3D >>>> INTEGER---even =3D3D >>>>>> =3D3D3D >>>>>>>> with >>>>>>>>> a pragma e.g. <*CLONGLONG*>.. if it is necessary to tell the =3D >>>> compiler =3D3D >>>>>> =3D3D3D >>>>>>>> that >>>>>>>>> a special linkage convention is needed). >>>>>>>> =3D20 >>>>>>>> There's no special linkage convention. Not sure what you mean = >> here. >>>>>>>> =3D20 >>>>>>> =3D3D20 >>>>>>> I just mean if we had >>>>>>> =3D3D20 >>>>>>> TYPE LONGINT =3D3D3D ARRAY [0..1] OF INTEGER >>>>>>> =3D3D20 >>>>>>> that would perhaps not match how C handles "long long" on the same >>>>>>> platform (which is how=3D3D2C come to think of it?)=3D3D2C and = >> that =3D >>>> would require >>>>>>> special linkage tricks. >>>>>>> =3D3D20 >>>>>>> But what would be lost? The ability to type literals.=3D3D20 >>>>>>> =3D3D20 >>>>>>> You could get the same code interface on 32- and 64-bit machine by >>>>>>> defining >>>>>>> =3D3D20 >>>>>>> TYPE FileOffset =3D3D3D ARRAY[0..1] OF [-16_80000000 .. = >> +16_7fffffff ] >>>>>>> =3D3D20 >>>>>>> and using that. >>>>>>> =3D3D20 >>>>>>> =3D3D20 >>>>>>> Mika >>>>>> =3D3D >>>>>> =3D20 >>>>>> --_264cb69b-0215-44c3-807c-8b4d8ea0ea59_ >>>>>> Content-Type: text/html; charset=3D3D"iso-8859-1" >>>>>> Content-Transfer-Encoding: quoted-printable >>>>>> =3D20 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> TYPE LONGINT =3D3D3D ARRAY [0..1] OF INTEGER on a =3D3D3B32bit = >> system =3D >>>> is very c=3D3D >>>>>> lose to LONGINT.
>>>>>>  =3D3D3BPlus treating it opaquely and providing a bunch of =3D >>>> functions to ope=3D3D >>>>>> rate on it.
>>>>>>  =3D3D3BJust as well therefore could be RECORD = >> hi=3D3D2Clo:LONGINT =3D >>>> END (see LAR=3D3D >>>>>> GE_INTEGER and ULARGE_INTEGER in winnt.h)
>>>>>>  =3D3D3B
>>>>>> Differences that come to mind:
>>>>>>  =3D3D3B =3D3D3Binfix operators =3D3D3B = >> <=3D3D3B=3D3D3D=3D3D3D=3D3D3D =3D >>>>
>>>>>>  =3D3D3B possibly passed differently =3D3D3Bas a = >> parameter
>>>>>>  =3D3D3B or returned differently as a result
>>>>>>  =3D3D3B ie. probably "directly compatible with" "long = >> long"=3D3D2C =3D >>>> passed by v=3D3D >>>>>> alue (of course you could always pass by pointer and achieve =3D >>>> compatibilitit=3D3D >>>>>> y trivially)
>>>>>>  =3D3D3B
>>>>>>  =3D3D3B
>>>>>> I have to say though=3D3D2C the biggest reason is in-fix operators. = >> =3D >>>> Convenient =3D3D >>>>>> syntax.
>>>>>> C++ is the best and some way worst of example of the general right = >> =3D >>>> way to d=3D3D >>>>>> o this -- you let programmers define types and their infix = >> operators. =3D >>>> Other=3D3D >>>>>> languages just come with a passle of special cases of types that = >> have =3D >>>> in-f=3D3D >>>>>> ix operators.
>>>>>> A good example is that Java infix operator + on string=3D3D2C = >> besides =3D >>>> the vario=3D3D >>>>>> us integers=3D3D2C and nothing else.
>>>>>>  =3D3D3B
>>>>>>  =3D3D3B
>>>>>> I think C# lets you define operators=3D3D2C yet people don't = >> complain =3D >>>> that it i=3D3D >>>>>> s "a mess" as they do of C++.
>>>>>> I think Python does now too.
>>>>>> So it is feature growing in popularity among "mainstream" =3D >>>> languages=3D3D2C not =3D3D >>>>>> just C++.
>>>>>>  =3D3D3B =3D3D3B C++ of course is extremely mainstream=3D3D2C= >> but =3D >>>> also a favori=3D3D >>>>>> te target. (>>> href=3D3D3D"http://www.relisoft.com/tools/CppCritic.html">http:/=3D3D >>>>>> /www.relisoft.com/tools/CppCritic.html)
>>>>>>  =3D3D3B
>>>>>>  =3D3D3B
>>>>>> We also have subranges of LONGINT.
>>>>>> I'm not sure what the generalization of subranges are=3D3D2C =3D >>>> granted.
>>>>>>  =3D3D3BMaybe some sort of C++ template that takes constants in = >> the =3D >>>> templat=3D3D >>>>>> e and does range checks at runtime. Yeah=3D3D2C maybe.
>>>>>>  =3D3D3B
>>>>>>  =3D3D3B
>>>>>> And as you point out=3D3D2C convenient literal syntax.
>>>>>>  =3D3D3B
>>>>>>  =3D3D3B
>>>>>> People reasonably argue for library extension in place of language = >> =3D >>>> extensio=3D3D >>>>>> n=3D3D2C but that requires a language which is flexible enough to = >> write =3D >>>> librari=3D3D >>>>>> es with the desired interface=3D3D2C and so many languages don't = >> let =3D >>>> infix oper=3D3D >>>>>> ators be in a user-written library.
>>>>>> (There is a subtle but useless distinction here -- infix operators = >> =3D >>>> being in=3D3D >>>>>> libraries vs. "user-written" libraries. The infix set operations = >> for =3D >>>> examp=3D3D >>>>>> le are in a library=3D3D2C but not user-written=3D3D2C special=3D3D2C= >> the =3D >>>> compiler know=3D3D >>>>>> s about it.)
>>>>>>  =3D3D3B
>>>>>> >=3D3D3B that would perhaps not match how C handles "long long" = >> on =3D >>>> the same>>>>> R>>=3D3D3B platform (which is how=3D3D2C come to think of = >> it?)=3D3D2C and =3D >>>> that would =3D3D >>>>>> require

>>>>>>  =3D3D3B
>>>>>> On NT/x86=3D3D2C __int64/long long is returned in the register pair = >> =3D >>>> edx:eax.>>>>>> =3D20 >>>>>> edx is high=3D3D2C eax is low.
>>>>>> When passed as a parameter to __stdcall or __cdecl is just passed = >> as =3D >>>> two 32=3D3D >>>>>> bit values adjacent on the stack=3D3D2C "hi=3D3D2C lo=3D3D2C = >> hi=3D3D2C lo=3D3D2C =3D >>>> it's off to pu=3D3D >>>>>> sh we go" is the Snow White-influenced mantra to remember how to = >> pass =3D >>>> them=3D3D >>>>>> =3D3D2C at least on little endian stack-growing-down machines = >> (which =3D >>>> includes x=3D3D >>>>>> 86). For __fastcall I'm not sure they are passed in registers or on = >> =3D >>>> the sta=3D3D >>>>>> ck.
>>>>>> Passing and/or returning small structs also has special efficient =3D= >> >>>> handling =3D3D >>>>>> in the ABI=3D3D2C so __int64 really might be equivalent to a small = >> =3D >>>> record. Not =3D3D >>>>>> that cm3 necessarily implements that "correctly" =3D3D3B -- for = >> =3D >>>> interop wit=3D3D >>>>>> h C=3D3D3B for Modula-3 calling Modula-3 we can make up our own ABI = >> so =3D >>>> there is=3D3D >>>>>> n't =3D3D3Breally an "incorrect" way. =3D3D3BNotice the = >> mingw =3D >>>> problem I had=3D3D >>>>>> passing a Win32 point struct by value=3D3D2C I cheated and passed = >> it by =3D >>>> VAR to=3D3D >>>>>> a =3D3D3BC wrapper to workaround the gcc backend bug (which was = >> =3D >>>> mentioned =3D3D >>>>>> a few times and which I looked into the code for=3D3D2C but took = >> the =3D >>>> easy route=3D3D >>>>>> )
>>>>>>  =3D3D3B
>>>>>>  =3D3D3B
>>>>>> I don't know how long long works on other platforms but probably =3D >>>> similar.>>>>> R> >>>>>> Probably a certain register pair for return values.
>>>>>>  =3D3D3B
>>>>>>  =3D3D3B- Jay

 =3D3D3B
>=3D3D3B To: =3D >>>> hosking at cs.purdue.edu
>=3D3D3B=3D3D >>>>>> Date: Sat=3D3D2C 17 Apr 2010 19:47:03 -0700
>=3D3D3B From: =3D >>>> mika at async.async.c=3D3D >>>>>> altech.edu
>=3D3D3B CC: m3devel at elegosoft.com
>=3D3D3B = >> Subject: =3D >>>> Re: [M3de=3D3D >>>>>> vel] INTEGER
>=3D3D3B
>=3D3D3B Tony Hosking = >> writes:
>=3D3D3B =3D >>>> >=3D3D3B
=3D3D >>>>>> >=3D3D3B ...
>=3D3D3B >=3D3D3B
>=3D3D3B = >> >=3D3D3B>=3D3D3B We =3D >>>> need it to match 64-b=3D3D >>>>>> it integers on 32-bit machines? That seems =3D3D3D
>=3D3D3B =3D >>>> >=3D3D3Blike
>=3D3D >>>>>> =3D3D3B >=3D3D3B>=3D3D3B a very weak rationale indeed=3D3D2C if = >> the same =3D >>>> functionality =3D3D >>>>>> could be =3D3D3D
>=3D3D3B >=3D3D3Bprovided
>=3D3D3B = >> >=3D3D3B>=3D3D3=3D >>>> B through some o=3D3D >>>>>> ther mechanism (e.g.=3D3D2C ARRAY [0..1] OF INTEGER---even =3D >>>> =3D3D3D
>=3D3D3B >=3D3D3B=3D3D >>>>>> with
>=3D3D3B >=3D3D3B>=3D3D3B a pragma e.g. =3D >>>> <=3D3D3B*CLONGLONG*>=3D3D3B.. if it i=3D3D >>>>>> s necessary to tell the compiler =3D3D3D
>=3D3D3B =3D >>>> >=3D3D3Bthat
>=3D3D3B >=3D3D3B&=3D3D >>>>>> gt=3D3D3B a special linkage convention is needed).
>=3D3D3B =3D >>>> >=3D3D3B
>=3D3D3B &=3D3D >>>>>> gt=3D3D3BThere's no special linkage convention. Not sure what you = >> mean =3D >>>> here.>>>>>> >=3D3D3B >=3D3D3B
>=3D3D3B
>=3D3D3B I just mean if = >> we =3D >>>> had
>=3D3D3B
>=3D3D >>>>>> =3D3D3B TYPE LONGINT =3D3D3D ARRAY [0..1] OF INTEGER
>=3D3D3B = >> =3D >>>>
>=3D3D3B that woul=3D3D >>>>>> d perhaps not match how C handles "long long" on the = >> same
>=3D3D3B =3D >>>> platfor=3D3D >>>>>> m (which is how=3D3D2C come to think of it?)=3D3D2C and that would = >> =3D >>>> require
>=3D3D >>>>>> =3D3D3B special linkage tricks.
>=3D3D3B
>=3D3D3B But = >> what would =3D >>>> be lost? Th=3D3D >>>>>> e ability to type literals.
>=3D3D3B
>=3D3D3B You could = >> get =3D >>>> the same co=3D3D >>>>>> de interface on 32- and 64-bit machine by
>=3D3D3B =3D >>>> defining
>=3D3D3B
=3D3D >>>>>> >=3D3D3B TYPE FileOffset =3D3D3D ARRAY[0..1] OF [-16_80000000 .. = >> =3D >>>> +16_7fffffff ]>>>>> R>>=3D3D3B
>=3D3D3B and using that.
>=3D3D3B = >>
>=3D3D3B =3D >>>>
>=3D3D3B Mika>>>>>> >>>>>> =3D3D >>>>>> =3D20 >>>>>> --_264cb69b-0215-44c3-807c-8b4d8ea0ea59_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Mon Apr 19 17:48:02 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 19 Apr 2010 11:48:02 -0400 Subject: [M3devel] INTEGER In-Reply-To: <4F3EE437-0298-410B-9642-C0381E333430@cs.purdue.edu> References: <20100418024703.6965B1A2103@async.async.caltech.edu> <20100418074927.934461A2117@async.async.caltech.edu> <04EB7FF8-D304-428D-839E-233FCE009C98@cs.purdue.edu> <20100418195901.CDACB1A20F6@async.async.caltech.edu> <20100419172313.68B241A20D6@async.async.caltech.edu> <4F3EE437-0298-410B-9642-C0381E333430@cs.purdue.edu> Message-ID: <20100419154802.GA8759@topoi.pooq.com> On Mon, Apr 19, 2010 at 02:44:00PM -0400, Tony Hosking wrote: > > > On 19 Apr 2010, at 13:23, Mika Nystrom wrote: > > > > > Well *my* problem is that I still use PM3 for a lot of things. Trying to > > switch to CM3, yes, but I can't "certify" CM3 for critical stuff yet. > > > > So I'm maintaining a significant amount of code that needs to compile > > under both PM3 and CM3. Two problems crop up. > > > > 1. If there are bugs in m3tk/stubgen, the fixes only apply to one or > > the other version of m3tk/stubgen. > > > > 2. Some of the code I'm maintaining processes Modula-3 code as input. > > It needs to be in two versions. > > > > In this kind of environment, programming languages don't really > > evolve, since the system depends on their being both forward- and > > backward-compatible. They "change" is more correct. The way Java > > changes. > > Indeed: Growing a Language, by Guy Steele > > > > > More in general, though, Modula-3's designers were clearly well acquainted > > with C, Fortran, and other languages that provide different-range > > integers. They chose not to indulge. I even have a version of Modula-3 > > for a 16-bit machine that doesn't do it, even though on this machine the > > need for a 32-bit integer is arguably greater than the need for 64-bit > > integers on 32-bit machines. Now we indulge in this language complication > > to solve what is clearly a temporary problem, since anyone who cares > > about large problems is going to have 64-bit systems yesterday... and > > meanwhile no one seems to have availed himself of the solution! > > If we were to revert, I have no idea what the implications would be. Jay? > > > My worst fear is that once the process gets started, the reason for > > staying with the original Green-Book specification has now been defeated > > and we will see more and more "evolution". Trying to actually build > > systems that process Modula-3 like data becomes, at that point, like > > trying to stand in quicksand. > > Indeed! > > > > > I'm not incredibly picky here... I just hope it doesn't go further. > > I would personally support either sticking with the current status quo > > or going back to the Green Book w.r.t. integers and characters. > > Indeed, I would not want to see this go any further. I am still not > sure I am comfortable with the LONGINT extension (even though I put a > lot of time into it). There just seemed to be a lot of pressure for > it to so CM3 could handle large file indexes. I've never been > convinced that WIDECHAR was a winner either -- it was a reflexive > action in the face of Java's Unicode. The CM3 people were building a > Java VM above CM3 at the time. The LONGINT problem has several causes: (1) INTEGER being defined as the largest integer type in the language. (2) INTEGER being implemented as a specific fixed-size type that can be implemented "efficiently", whatever that means. (3) The world of Modula 3 programmers using INTEGER whenever they didn't want to worry about what actual range they needed. These three facts make it difficult to implement integer types that are larger than the ones that are "efficient" on the hardware. In my opinion it was a mistake to define the "efficient" integer type to necessarily be the "largest" integer type. It was this that made it necessary to invent a new type hierarchy of LONGINTs, which are not necessarily implemented efficiently. But I see no need to make the largest type in this hierarchy explicitly available to the programmer. It is possible to have only subranges of LONGINT available, and it is possible to track the maximum values achievable with arithmetic operations, and thus determine the subranges needed for intermediate results. Had we left LONGINT unconstrained, we could have had the simple rule: use INTEGER if efficiency is more important thatn correctness (or you know you'll be in-range), use LONGINT otherwise. Doing that thoroughly would have required some compiler energetics. Still, the necessaries could all have been done statically, without causing any further grief the day a third length of integer is needed. I have no idea whether that day will ever arrive, but it seems foolish to design the language in such a way as to make that day difficult to accomodate. My druthers would have been to have more-or-less the present LONGINT, but restrict programmers to use only subtypes of it. If there is to be a maximum LONGINT value (possibly as an implementation reastriciton), overflowing past it must be checked. -- hendrik > > > > > Saying that EWD wasn't renowned for his practicality is something he > > would have taken as a great compliment, I'm sure. > > ;-) > Actually, I kind of suspect he thought he *was* being practical. -- hendrik From hendrik at topoi.pooq.com Mon Apr 19 17:57:02 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 19 Apr 2010 11:57:02 -0400 Subject: [M3devel] INTEGER In-Reply-To: <20100418195901.CDACB1A20F6@async.async.caltech.edu> References: <20100418024703.6965B1A2103@async.async.caltech.edu> <20100418074927.934461A2117@async.async.caltech.edu> <04EB7FF8-D304-428D-839E-233FCE009C98@cs.purdue.edu> <20100418195901.CDACB1A20F6@async.async.caltech.edu> Message-ID: <20100419155702.GB8759@topoi.pooq.com> On Sun, Apr 18, 2010 at 12:59:01PM -0700, Mika Nystrom wrote: > > And the new m3tk, stubgen, and compiler(?) won't compile using PM3 or > SRC M3 since we're no longer using the language of the Green Book. > (Same comment goes for WIDECHAR, by the way.) When I use Unicode characters, I find myself defining them to be INTEGERs, because I'm always worried that WIDECHARs might be omly 16 bits. Strings of WIDECHARS are probably unnecesary. The last program I wrote that used Unicode used INTEGERs for characters, and arrays of INTEGERS for strings. But I think it was a mistake to do it this way, and when I have time I'll rewrite it. UTF-8 seems to be the way to go; strings of Unicode can easily be manipulated as ordinary TEXT. In fact, I think there are few if any places in my code where I would have had to do anything special whatsoever if I had just used UTF8 in TEXT. The program would simply become simpler. -- hendrik From jay.krell at cornell.edu Mon Apr 19 23:20:00 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 19 Apr 2010 21:20:00 +0000 Subject: [M3devel] INTEGER In-Reply-To: <20100419155702.GB8759@topoi.pooq.com> References: <20100418024703.6965B1A2103@async.async.caltech.edu>, , <20100418074927.934461A2117@async.async.caltech.edu>, <04EB7FF8-D304-428D-839E-233FCE009C98@cs.purdue.edu>, <20100418195901.CDACB1A20F6@async.async.caltech.edu>, <20100419155702.GB8759@topoi.pooq.com> Message-ID: For the record, anyone using Windows (NT/2000/XP/2003/etc.) is using 16bit characters *all the time*. MacOSX maybe also. I think utf8 is kind of a hack to let folks get away without really doing anything. Granted, I didn't realize till recently that strcmp works on utf8..maybe a really clever idea.. - Jay > Date: Mon, 19 Apr 2010 11:57:02 -0400 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] INTEGER > > On Sun, Apr 18, 2010 at 12:59:01PM -0700, Mika Nystrom wrote: > > > > And the new m3tk, stubgen, and compiler(?) won't compile using PM3 or > > SRC M3 since we're no longer using the language of the Green Book. > > (Same comment goes for WIDECHAR, by the way.) > > When I use Unicode characters, I find myself defining them to be > INTEGERs, because I'm always worried that WIDECHARs might be omly 16 bits. > > Strings of WIDECHARS are probably unnecesary. The last program I wrote > that used Unicode used INTEGERs for characters, and arrays of INTEGERS > for strings. But I think it was a mistake to do it this way, and when I > have time I'll rewrite it. UTF-8 seems to be the way to go; strings of > Unicode can easily be manipulated as ordinary TEXT. In fact, I > think there are few if any places in my code where I would have had to > do anything special whatsoever if I had just used UTF8 in TEXT. The > program would simply become simpler. > > -- hendrik -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Apr 19 23:25:48 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 19 Apr 2010 21:25:48 +0000 Subject: [M3devel] INTEGER In-Reply-To: <4F3EE437-0298-410B-9642-C0381E333430@cs.purdue.edu> References: , , ,,<7C7408D0-9A40-4988-BADA-A9FD8C15D388@cs.purdue.edu>, ,,, , , , , , , , , <20100418023535.3BA9E1A2103@async.async.caltech.edu>, , , , <20100418024703.6965B1A2103@async.async.caltech.edu>, , <20100418074927.934461A2117@async.async.caltech.edu>, <04EB7FF8-D304-428D-839E-233FCE009C98@cs.purdue.edu>, <20100418195901.CDACB1A20F6@async.async.caltech.edu>, , <20100419172313.68B241A20D6@async.async.caltech.edu>, <4F3EE437-0298-410B-9642-C0381E333430@cs.purdue.edu> Message-ID: > If we were to revert, I have no idea what the implications would be. Jay? I'm sure we could cope. Besides, we'd put in a library-based solution anyway? That the compiler inlines? Like atomics? Let me suggest a small exercise though: I'm not going to do it. Write a program that copies files. Or just one file. "cp.exe". Have it print "progress feedback" to the user -- how many bytes and percentage copied. Leave out "time estimation". And also write "ls.exe". And maybe one last program, like "dos2unix.exe" or "fix_nl.exe" that alters newlines. This program should work on files that don't fit in memory. That is, get some experience working with files that don't fit in memory/address space. But also for which lots memory/address space really aren't needed. Also think about what an idea representation of time is. Isn't a 64bit integer number of units smaller than a second a very good one? And aren't infix operators darned nice? - Jay From: hosking at cs.purdue.edu Date: Mon, 19 Apr 2010 14:44:00 -0400 To: mika at async.async.caltech.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] INTEGER On 19 Apr 2010, at 13:23, Mika Nystrom wrote: Well *my* problem is that I still use PM3 for a lot of things. Trying to switch to CM3, yes, but I can't "certify" CM3 for critical stuff yet. So I'm maintaining a significant amount of code that needs to compile under both PM3 and CM3. Two problems crop up. 1. If there are bugs in m3tk/stubgen, the fixes only apply to one or the other version of m3tk/stubgen. 2. Some of the code I'm maintaining processes Modula-3 code as input. It needs to be in two versions. In this kind of environment, programming languages don't really evolve, since the system depends on their being both forward- and backward-compatible. They "change" is more correct. The way Java changes. Indeed: Growing a Language, by Guy Steele More in general, though, Modula-3's designers were clearly well acquainted with C, Fortran, and other languages that provide different-range integers. They chose not to indulge. I even have a version of Modula-3 for a 16-bit machine that doesn't do it, even though on this machine the need for a 32-bit integer is arguably greater than the need for 64-bit integers on 32-bit machines. Now we indulge in this language complication to solve what is clearly a temporary problem, since anyone who cares about large problems is going to have 64-bit systems yesterday... and meanwhile no one seems to have availed himself of the solution! If we were to revert, I have no idea what the implications would be. Jay? My worst fear is that once the process gets started, the reason for staying with the original Green-Book specification has now been defeated and we will see more and more "evolution". Trying to actually build systems that process Modula-3 like data becomes, at that point, like trying to stand in quicksand. Indeed! I'm not incredibly picky here... I just hope it doesn't go further. I would personally support either sticking with the current status quo or going back to the Green Book w.r.t. integers and characters. Indeed, I would not want to see this go any further. I am still not sure I am comfortable with the LONGINT extension (even though I put a lot of time into it). There just seemed to be a lot of pressure for it to so CM3 could handle large file indexes. I've never been convinced that WIDECHAR was a winner either -- it was a reflexive action in the face of Java's Unicode. The CM3 people were building a Java VM above CM3 at the time. Saying that EWD wasn't renowned for his practicality is something he would have taken as a great compliment, I'm sure. ;-) Mika Tony Hosking writes: Mika, First off, I'd be very interested to know what the issues are with = LONGINT and stubgen. We are building that every day in regression = testing. It would be really good to get some precise feedback. True, LONGINT is integrated with all of the language tools (same as = WIDECHAR). I suppose that is the price we pay for the language having evolved. = Nevertheless, CM3 should be totally backward compatible with the green = book. There is no reason it should not build packages from PM3 or SRC. Now, this is not to say that perhaps we haven't overreached with LONGINT = given that 64-bit is more prevalent. But then it is also useful to be = able to interoperate with C libraries. The previous interfacing was = pretty much a kludge, using ARRAY[0..1] OF INTEGER for "long long" but = then not propagating the double INTEGER value properly throughout the = Modula-3 libraries. I'm sorry to say that EWD was not particularly renowned for his = practicality; pedant more like. Nice to be high and mighty but we also = need to interact with the real world. We should be able to make this work. Is there a better alternative? = Revoke LONGINT, and WIDECHAR? On 18 Apr 2010, at 15:59, Mika Nystrom wrote: =20 My problem is really just that it's ugly. LONGx is showing up as an = issue in all sorts of low-level code, which is not surprising since Modula-3 with LONGx is not the same language as Modula-3 (maybe we should call it Modula-3+?)=20 =20 The compiler bootstrapping process has gotten more complicated due to = it, and when I cvs updated m3tk yesterday stubgen wouldn't compile because = there was something "long" in it that wasn't there before. I have no idea = what library or components I needed to update and recompile and didn't have = the time to deal with the issue at the time. =20 And the new m3tk, stubgen, and compiler(?) won't compile using PM3 or SRC M3 since we're no longer using the language of the Green Book. (Same comment goes for WIDECHAR, by the way.) =20 One of the wonderful things about Modula-3 *used to be* that I could grab some old package from DECSRC and just use it without changes = since no one had messed with the language definition. This is still true as far as programs that just use the tools go, but it's no longer true = for programs that process Modula-3 code as input data. Of which there are more than a few: many aspects of Modula-3 were specifically designed = to make the language easy to process by program, as an intermediate = format and whatnot. =20 To quote E.W.D.: =20 'Unfathomed misunderstanding is further revealed by the term "software maintenance", as a result of which many people continue to believe = that programs and even programming languages themselves are subject to wear and tear. Your car needs maintenance too, doesn't it? Famous is the = story of the oil company that believed that its PASCAL programs did not last as long as its FORTRAN programs "because PASCAL was not maintained".' =20 LONGx is causing me to have to do "software maintenance" on Modula-3 programs... for a feature that no one appears to be using and is = quickly becoming irrelevant. =20 Mika =20 =20 Tony Hosking writes: In the language spec NUMBER(a) and LAST(a) - FIRST(a) + 1 are *not* =3D= defined to mean the same thing for all types. NUMBER does have an INTEGER value, as expected for subranges of = LONGINT =3D that are not too large. This is as it has always been for subranges of INTEGER that are not = too =3D large. =20 Mika, I'm not sure I see any of the problems you are worrying about = in =3D the current definition of LONGINT/LONGCARD. =20 On 18 Apr 2010, at 03:49, Mika Nystrom wrote: =20 =3D20 Jay I know most of this, and it doesn't really answer the question "what is it for?" =3D20 I think we've already established that LONGINT isn't useful for =3D counting anything that might actually reside in the computer's memory: it = makes no sense as an array index, for instance. INTEGER suffices for = that. =3D20 I thought that the only real reason for LONGINT was to match C's declaration of various seek-related routines on 32-bit machines. That's not a very good reason. =3D20 C++ succeeds because it does very well in the area(s) it is good at. People who want to program in C++ will clearly program in C++, not Modula-3. Modula-3 is never, ever going to be the language of = choice =3D for people who want lots of snazzy infix operators. Modula-3 is = supposed =3D to be a language with about as powerful semantics as C++ and an = extremely simple syntax and definition---snazzy infix is one of the things you give up for that. I don't see how LONGINT fits into this picture. Now we have LONGCARD too? And it's infected the definitions of FIRST and LAST? But not NUMBER... argh! =3D20 so, =3D20 NUMBER(a) and LAST(a) - FIRST(a) + 1 =3D20 no longer mean the same thing? Are we going to see lots of comments in generics in the future where it says T may not be an open array type nor an array type indexed on LONGINT or a subrange thereof? =3D20 Your comments about different parameter-passing techniques was what = I =3D was trying to address with my suggestion to have a pragma for = this---just =3D to match C (and Fortran?), of course. Name me a single Modula-3 =3D programmer who cares in what order the bits in his parameters are pushed on the stack in a Modula-3-to-Modula-3 call. =3D20 And I am definitely in that school of thought that says that =3D programming languages should not "evolve". Better to leave well enough alone. =3D20 How much Modula-3 code has been written that uses LONGINT? Other = than to talk to C? I've certainly never used it. =3D20 Mika =3D20 =3D20 =3D20 Jay K writes: --_264cb69b-0215-44c3-807c-8b4d8ea0ea59_ Content-Type: text/plain; charset=3D3D"iso-8859-1" Content-Transfer-Encoding: quoted-printable =3D20 =3D20 TYPE LONGINT =3D3D3D ARRAY [0..1] OF INTEGER on a 32bit system is = very =3D close to=3D3D LONGINT. =3D20 Plus treating it opaquely and providing a bunch of functions to =3D operate on=3D3D it. =3D20 Just as well therefore could be RECORD hi=3D3D2Clo:LONGINT END (see = =3D LARGE_INTE=3D3D GER and ULARGE_INTEGER in winnt.h) =3D20 =3D3D20 =3D20 Differences that come to mind: =3D20 infix operators <=3D3D3D=3D3D3D=3D3D3D=3D3D20 =3D20 possibly passed differently as a parameter =3D20 or returned differently as a result =3D20 ie. probably "directly compatible with" "long long"=3D3D2C passed = by =3D value (o=3D3D f course you could always pass by pointer and achieve = compatibilitity =3D trivi=3D3D ally) =3D20 =3D3D20 =3D20 =3D3D20 =3D20 I have to say though=3D3D2C the biggest reason is in-fix operators. = =3D Convenient =3D3D syntax. =3D20 C++ is the best and some way worst of example of the general right = =3D way to d=3D3D o this -- you let programmers define types and their infix = operators. =3D Other=3D3D languages just come with a passle of special cases of types that = have =3D in-f=3D3D ix operators. =3D20 A good example is that Java infix operator + on string=3D3D2C = besides =3D the vario=3D3D us integers=3D3D2C and nothing else. =3D20 =3D3D20 =3D20 =3D3D20 =3D20 I think C# lets you define operators=3D3D2C yet people don't = complain =3D that it i=3D3D s "a mess" as they do of C++. =3D20 I think Python does now too. =3D20 So it is feature growing in popularity among "mainstream" =3D languages=3D3D2C not =3D3D just C++. =3D20 C++ of course is extremely mainstream=3D3D2C but also a favorite =3D target. (ht=3D3D tp://www.relisoft.com/tools/CppCritic.html) =3D20 =3D3D20 =3D20 =3D3D20 =3D20 We also have subranges of LONGINT. =3D20 I'm not sure what the generalization of subranges are=3D3D2C = granted. =3D20 Maybe some sort of C++ template that takes constants in the = template =3D and d=3D3D oes range checks at runtime. Yeah=3D3D2C maybe. =3D20 =3D3D20 =3D20 =3D3D20 =3D20 And as you point out=3D3D2C convenient literal syntax. =3D20 =3D3D20 =3D20 =3D3D20 =3D20 People reasonably argue for library extension in place of language = =3D extensio=3D3D n=3D3D2C but that requires a language which is flexible enough to = write =3D librari=3D3D es with the desired interface=3D3D2C and so many languages don't = let =3D infix oper=3D3D ators be in a user-written library. =3D20 (There is a subtle but useless distinction here -- infix operators = =3D being in=3D3D libraries vs. "user-written" libraries. The infix set operations = for =3D examp=3D3D le are in a library=3D3D2C but not user-written=3D3D2C special=3D3D2C= the =3D compiler know=3D3D s about it.) =3D20 =3D3D20 =3D20 that would perhaps not match how C handles "long long" on the same platform (which is how=3D3D2C come to think of it?)=3D3D2C and = that =3D would require =3D20 =3D20 =3D3D20 =3D20 On NT/x86=3D3D2C __int64/long long is returned in the register pair = =3D edx:eax. =3D20 edx is high=3D3D2C eax is low. =3D20 When passed as a parameter to __stdcall or __cdecl is just passed = as =3D two 32=3D3D bit values adjacent on the stack=3D3D2C "hi=3D3D2C lo=3D3D2C = hi=3D3D2C lo=3D3D2C =3D it's off to pu=3D3D sh we go" is the Snow White-influenced mantra to remember how to = pass =3D them=3D3D =3D3D2C at least on little endian stack-growing-down machines = (which =3D includes x=3D3D 86). For __fastcall I'm not sure they are passed in registers or on = =3D the sta=3D3D ck. =3D20 Passing and/or returning small structs also has special efficient =3D= handling =3D3D in the ABI=3D3D2C so __int64 really might be equivalent to a small = =3D record. Not =3D3D that cm3 necessarily implements that "correctly" -- for interop = with =3D C=3D3D3B =3D3D for Modula-3 calling Modula-3 we can make up our own ABI so there =3D= isn't rea=3D3D lly an "incorrect" way. Notice the mingw problem I had passing a =3D Win32 poin=3D3D t struct by value=3D3D2C I cheated and passed it by VAR to a C = wrapper =3D to worka=3D3D round the gcc backend bug (which was mentioned a few times and = which =3D I look=3D3D ed into the code for=3D3D2C but took the easy route) =3D20 =3D3D20 =3D20 =3D3D20 =3D20 I don't know how long long works on other platforms but probably =3D similar. =3D20 Probably a certain register pair for return values. =3D20 =3D3D20 =3D20 - Jay =3D20 =3D3D20 To: hosking at cs.purdue.edu Date: Sat=3D3D2C 17 Apr 2010 19:47:03 -0700 From: mika at async.async.caltech.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] INTEGER =3D3D20 Tony Hosking writes: =3D20 ... =3D20 We need it to match 64-bit integers on 32-bit machines? That = seems =3D =3D3D3D like a very weak rationale indeed=3D3D2C if the same functionality = could =3D be =3D3D3D provided through some other mechanism (e.g.=3D3D2C ARRAY [0..1] OF =3D INTEGER---even =3D3D =3D3D3D with a pragma e.g. <*CLONGLONG*>.. if it is necessary to tell the =3D compiler =3D3D =3D3D3D that a special linkage convention is needed). =3D20 There's no special linkage convention. Not sure what you mean = here. =3D20 =3D3D20 I just mean if we had =3D3D20 TYPE LONGINT =3D3D3D ARRAY [0..1] OF INTEGER =3D3D20 that would perhaps not match how C handles "long long" on the same platform (which is how=3D3D2C come to think of it?)=3D3D2C and = that =3D would require special linkage tricks. =3D3D20 But what would be lost? The ability to type literals.=3D3D20 =3D3D20 You could get the same code interface on 32- and 64-bit machine by defining =3D3D20 TYPE FileOffset =3D3D3D ARRAY[0..1] OF [-16_80000000 .. = +16_7fffffff ] =3D3D20 and using that. =3D3D20 =3D3D20 Mika =3D3D =3D20 --_264cb69b-0215-44c3-807c-8b4d8ea0ea59_ Content-Type: text/html; charset=3D3D"iso-8859-1" Content-Transfer-Encoding: quoted-printable =3D20 TYPE LONGINT =3D3D3D ARRAY [0..1] OF INTEGER on a =3D3D3B32bit = system =3D is very c=3D3D lose to LONGINT.
 =3D3D3BPlus treating it opaquely and providing a bunch of =3D functions to ope=3D3D rate on it.
 =3D3D3BJust as well therefore could be RECORD = hi=3D3D2Clo:LONGINT =3D END (see LAR=3D3D GE_INTEGER and ULARGE_INTEGER in winnt.h)
 =3D3D3B
Differences that come to mind:
 =3D3D3B =3D3D3Binfix operators =3D3D3B = <=3D3D3B=3D3D3D=3D3D3D=3D3D3D =3D
 =3D3D3B possibly passed differently =3D3D3Bas a = parameter
 =3D3D3B or returned differently as a result
 =3D3D3B ie. probably "directly compatible with" "long = long"=3D3D2C =3D passed by v=3D3D alue (of course you could always pass by pointer and achieve =3D compatibilitit=3D3D y trivially)
 =3D3D3B
 =3D3D3B
I have to say though=3D3D2C the biggest reason is in-fix operators. = =3D Convenient =3D3D syntax.
C++ is the best and some way worst of example of the general right = =3D way to d=3D3D o this -- you let programmers define types and their infix = operators. =3D Other=3D3D languages just come with a passle of special cases of types that = have =3D in-f=3D3D ix operators.
A good example is that Java infix operator + on string=3D3D2C = besides =3D the vario=3D3D us integers=3D3D2C and nothing else.
 =3D3D3B
 =3D3D3B
I think C# lets you define operators=3D3D2C yet people don't = complain =3D that it i=3D3D s "a mess" as they do of C++.
I think Python does now too.
So it is feature growing in popularity among "mainstream" =3D languages=3D3D2C not =3D3D just C++.
 =3D3D3B =3D3D3B C++ of course is extremely mainstream=3D3D2C= but =3D also a favori=3D3D te target. (http:/=3D3D /www.relisoft.com/tools/CppCritic.html)
 =3D3D3B
 =3D3D3B
We also have subranges of LONGINT.
I'm not sure what the generalization of subranges are=3D3D2C =3D granted.
 =3D3D3BMaybe some sort of C++ template that takes constants in = the =3D templat=3D3D e and does range checks at runtime. Yeah=3D3D2C maybe.
 =3D3D3B
 =3D3D3B
And as you point out=3D3D2C convenient literal syntax.
 =3D3D3B
 =3D3D3B
People reasonably argue for library extension in place of language = =3D extensio=3D3D n=3D3D2C but that requires a language which is flexible enough to = write =3D librari=3D3D es with the desired interface=3D3D2C and so many languages don't = let =3D infix oper=3D3D ators be in a user-written library.
(There is a subtle but useless distinction here -- infix operators = =3D being in=3D3D libraries vs. "user-written" libraries. The infix set operations = for =3D examp=3D3D le are in a library=3D3D2C but not user-written=3D3D2C special=3D3D2C= the =3D compiler know=3D3D s about it.)
 =3D3D3B
>=3D3D3B that would perhaps not match how C handles "long long" = on =3D the same>=3D3D3B platform (which is how=3D3D2C come to think of = it?)=3D3D2C and =3D that would =3D3D require

 =3D3D3B
On NT/x86=3D3D2C __int64/long long is returned in the register pair = =3D edx:eax. When passed as a parameter to __stdcall or __cdecl is just passed = as =3D two 32=3D3D bit values adjacent on the stack=3D3D2C "hi=3D3D2C lo=3D3D2C = hi=3D3D2C lo=3D3D2C =3D it's off to pu=3D3D sh we go" is the Snow White-influenced mantra to remember how to = pass =3D them=3D3D =3D3D2C at least on little endian stack-growing-down machines = (which =3D includes x=3D3D 86). For __fastcall I'm not sure they are passed in registers or on = =3D the sta=3D3D ck.
Passing and/or returning small structs also has special efficient =3D= handling =3D3D in the ABI=3D3D2C so __int64 really might be equivalent to a small = =3D record. Not =3D3D that cm3 necessarily implements that "correctly" =3D3D3B -- for = =3D interop wit=3D3D h C=3D3D3B for Modula-3 calling Modula-3 we can make up our own ABI = so =3D there is=3D3D n't =3D3D3Breally an "incorrect" way. =3D3D3BNotice the = mingw =3D problem I had=3D3D passing a Win32 point struct by value=3D3D2C I cheated and passed = it by =3D VAR to=3D3D a =3D3D3BC wrapper to workaround the gcc backend bug (which was = =3D mentioned =3D3D a few times and which I looked into the code for=3D3D2C but took = the =3D easy route=3D3D )
 =3D3D3B
 =3D3D3B
I don't know how long long works on other platforms but probably =3D similar. Probably a certain register pair for return values.
 =3D3D3B
 =3D3D3B- Jay

 =3D3D3B
>=3D3D3B To: =3D hosking at cs.purdue.edu
>=3D3D3B=3D3D Date: Sat=3D3D2C 17 Apr 2010 19:47:03 -0700
>=3D3D3B From: =3D mika at async.async.c=3D3D altech.edu
>=3D3D3B CC: m3devel at elegosoft.com
>=3D3D3B = Subject: =3D Re: [M3de=3D3D vel] INTEGER
>=3D3D3B
>=3D3D3B Tony Hosking = writes:
>=3D3D3B =3D >=3D3D3B
=3D3D >=3D3D3B ...
>=3D3D3B >=3D3D3B
>=3D3D3B = >=3D3D3B>=3D3D3B We =3D need it to match 64-b=3D3D it integers on 32-bit machines? That seems =3D3D3D
>=3D3D3B =3D >=3D3D3Blike
>=3D3D =3D3D3B >=3D3D3B>=3D3D3B a very weak rationale indeed=3D3D2C if = the same =3D functionality =3D3D could be =3D3D3D
>=3D3D3B >=3D3D3Bprovided
>=3D3D3B = >=3D3D3B>=3D3D3=3D B through some o=3D3D ther mechanism (e.g.=3D3D2C ARRAY [0..1] OF INTEGER---even =3D =3D3D3D
>=3D3D3B >=3D3D3B=3D3D with
>=3D3D3B >=3D3D3B>=3D3D3B a pragma e.g. =3D <=3D3D3B*CLONGLONG*>=3D3D3B.. if it i=3D3D s necessary to tell the compiler =3D3D3D
>=3D3D3B =3D >=3D3D3Bthat
>=3D3D3B >=3D3D3B&=3D3D gt=3D3D3B a special linkage convention is needed).
>=3D3D3B =3D >=3D3D3B
>=3D3D3B &=3D3D gt=3D3D3BThere's no special linkage convention. Not sure what you = mean =3D here.>=3D3D3B
>=3D3D3B I just mean if = we =3D had
>=3D3D3B
>=3D3D =3D3D3B TYPE LONGINT =3D3D3D ARRAY [0..1] OF INTEGER
>=3D3D3B = =3D
>=3D3D3B that woul=3D3D d perhaps not match how C handles "long long" on the = same
>=3D3D3B =3D platfor=3D3D m (which is how=3D3D2C come to think of it?)=3D3D2C and that would = =3D require
>=3D3D =3D3D3B special linkage tricks.
>=3D3D3B
>=3D3D3B But = what would =3D be lost? Th=3D3D e ability to type literals.
>=3D3D3B
>=3D3D3B You could = get =3D the same co=3D3D de interface on 32- and 64-bit machine by
>=3D3D3B =3D defining
>=3D3D3B
=3D3D >=3D3D3B TYPE FileOffset =3D3D3D ARRAY[0..1] OF [-16_80000000 .. = =3D +16_7fffffff ]>=3D3D3B
>=3D3D3B and using that.
>=3D3D3B =
>=3D3D3B =3D
>=3D3D3B Mika =3D3D =3D20 --_264cb69b-0215-44c3-807c-8b4d8ea0ea59_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Apr 19 23:29:26 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 19 Apr 2010 21:29:26 +0000 Subject: [M3devel] libm3/socket? In-Reply-To: References: <20100419173955.08CF82474003@birch.elegosoft.com>, Message-ID: Yeah.. anyone one m3devel using it? I guess we'll have to support it either way. The m3-comm/tcp stuff seems to be heavily "based" on it -- copy/paste. This stuff has ipv4 address in its public interface. That really made me not want to deal with it. Though the m3-comm stuff too. Pickles are bound to get broken by any sort of IPv6 support, unless maybe we make new interfaces for it. The new interfaces will work with IPv4 or IPv6. - Jay From: hosking at cs.purdue.edu Date: Mon, 19 Apr 2010 14:36:59 -0400 To: jkrell at elego.de CC: m3commit at elegosoft.com Subject: Re: [M3commit] CVS Update: cm3 Who's nobody? Just because there are no CM3 sources that use does not mean that there are no users out there. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 19 Apr 2010, at 19:39, Jay Krell wrote: CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/04/19 19:39:54 Modified files: cm3/m3-libs/libm3/src/os/Common/: m3makefile cm3/m3-libs/libm3/src/os/POSIX/: m3makefile cm3/m3-libs/libm3/src/os/WIN32/: m3makefile Removed files: cm3/m3-libs/libm3/src/os/Common/: Socket.i3 Socket.m3 cm3/m3-libs/libm3/src/os/POSIX/: SocketPosix.m3 SocketPosixC.c cm3/m3-libs/libm3/src/os/WIN32/: SocketWin32.m3 SocketWin32.m3.sav Log message: Nobody uses libm3's socket support. So empty it out instead of fixing it. Let's focus effort elsewhere, e.g. m3-comm/tcp. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.async.caltech.edu Tue Apr 20 00:31:52 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Mon, 19 Apr 2010 15:31:52 -0700 Subject: [M3devel] INTEGER In-Reply-To: References: , , , , <7C7408D0-9A40-4988-BADA-A9FD8C15D388@cs.purdue.edu>, , , , , , , , , , , , <20100418023535.3BA9E1A2103@async.async.caltech.edu>, , , , <20100418024703.6965B1A2103@async.async.caltech.edu>, , <20100418074927.934461A2117@async.async.caltech.edu>, <04EB7FF8-D304-428D-839E-233FCE009C98@cs.purdue.edu>, <20100418195901.CDACB1A20F6@async.async.caltech.edu>, , <20100419172313.68B241A20D6@async.async.caltech.edu>, <4F3EE437-0298-410B-9642-C0381E333430@cs.purdue.edu> Message-ID: <20100419223152.3D7331A2122@async.async.caltech.edu> Jay K writes: ... >Let me suggest a small exercise though: > > I'm not going to do it. > > Write a program that copies files. Or just one file. "cp.exe". > > Have it print "progress feedback" to the user -- how many bytes and percen= >tage copied. Leave out "time estimation". > > And also write "ls.exe". > > And maybe one last program=2C like "dos2unix.exe" or "fix_nl.exe" that alt= >ers newlines. This program should work on files that don't fit in memory. > I use the rdwrreset package under PM3. It solves the most glaring problems. But clearly the file sizes should be done with some sort of data structure different from 32-bit INTEGER. ARRAY [0..1] OF INTEGER seems to be a candidate... ... >Also think about what an idea representation of time is. > >Isn't a 64bit integer number of units smaller than a second a very good one= >? Modula-3 already uses floating point for this, which has the advantage you don't need to worry what the base is. > >And aren't infix operators darned nice? I have mixed feelings about this. Yes, but... every infix operator takes several lines of language definition. Those lines can turn into ungodly amounts of code somewhere. I actually do like Hendrik's idea of providing some sort of bignum support. The reason I don't like LONGINT as much is that it seems it's just a waste if we're all going to be using 64-bit machines anyhow. It's arbitrary to have two fixed-width types. Why not three or four? And why not 128 bits or 16 bits or 36 bits? If on the other hand you got something substantial out of it that might be another story. In that case, I would say LONGINT would be a reference type (much like TEXT) with its associated Longint interface, and infix operators (the way TEXT has &) per Jay's fondest dreams. Come to think of it, TEXT and such a LONGINT would have a lot in common. Mika From hosking at cs.purdue.edu Tue Apr 20 01:16:59 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 19 Apr 2010 19:16:59 -0400 Subject: [M3devel] libm3/socket? In-Reply-To: References: <20100419173955.08CF82474003@birch.elegosoft.com>, Message-ID: <13143F7F-3922-4D49-AB31-74F7E366DB4A@cs.purdue.edu> An opportunity to build a better abstraction... ;-) Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 19 Apr 2010, at 17:29, Jay K wrote: > Yeah.. anyone one m3devel using it? > > I guess we'll have to support it either way. > The m3-comm/tcp stuff seems to be heavily "based" on it -- copy/paste. > > This stuff has ipv4 address in its public interface. > That really made me not want to deal with it. > Though the m3-comm stuff too. > Pickles are bound to get broken by any sort of IPv6 support, unless maybe we make new interfaces for it. > The new interfaces will work with IPv4 or IPv6. > > - Jay > > > From: hosking at cs.purdue.edu > Date: Mon, 19 Apr 2010 14:36:59 -0400 > To: jkrell at elego.de > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > Who's nobody? > > Just because there are no CM3 sources that use does not mean that there are no users out there. > > Antony Hosking | Associate Professor | Computer Science | Purdue University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > On 19 Apr 2010, at 19:39, Jay Krell wrote: > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/04/19 19:39:54 > > Modified files: > cm3/m3-libs/libm3/src/os/Common/: m3makefile > cm3/m3-libs/libm3/src/os/POSIX/: m3makefile > cm3/m3-libs/libm3/src/os/WIN32/: m3makefile > Removed files: > cm3/m3-libs/libm3/src/os/Common/: Socket.i3 Socket.m3 > cm3/m3-libs/libm3/src/os/POSIX/: SocketPosix.m3 SocketPosixC.c > cm3/m3-libs/libm3/src/os/WIN32/: SocketWin32.m3 > SocketWin32.m3.sav > > Log message: > Nobody uses libm3's socket support. > So empty it out instead of fixing it. > Let's focus effort elsewhere, e.g. m3-comm/tcp. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Apr 20 01:57:43 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 19 Apr 2010 23:57:43 +0000 Subject: [M3devel] INTEGER In-Reply-To: <20100419223152.3D7331A2122@async.async.caltech.edu> References: , , , ,,<7C7408D0-9A40-4988-BADA-A9FD8C15D388@cs.purdue.edu>, , ,,, , , , , , , , , , , , , <20100418023535.3BA9E1A2103@async.async.caltech.edu>, ,,, , , <20100418024703.6965B1A2103@async.async.caltech.edu>, , , , <20100418074927.934461A2117@async.async.caltech.edu>, , <04EB7FF8-D304-428D-839E-233FCE009C98@cs.purdue.edu>, , <20100418195901.CDACB1A20F6@async.async.caltech.edu>, , , , <20100419172313.68B241A20D6@async.async.caltech.edu>, , <4F3EE437-0298-410B-9642-C0381E333430@cs.purdue.edu>, , <20100419223152.3D7331A2122@async.async.caltech.edu> Message-ID: > Modula-3 already uses floating point for this, which has the advantage > you don't need to worry what the base is. What do you mean not worry about the "base"? I'm not a fan of floating point. > support. The reason I don't like LONGINT as much is that it seems it's > just a waste if we're all going to be using 64-bit machines anyhow. Again, you might be right. C got 64bit integers ~18 years ago. We are late. Do you think phones and embedded devices will move to 64bits soon too? Are gaming consoles 64bits? > I use the rdwrreset package under PM3 Probably we should plunder PM3 for anything we are missing. > different from 32-bit INTEGER. ARRAY [0..1] OF INTEGER seems to be a > candidate... Again, aside, can such an array be made truly abstract? I'd like opaque data structures without forcing heap allocation. Because, you know, it is somewhat tricky how to deal with, and people will differ as to their assumptions of the order of the integers. There is a bignum package, I haven't looked into it. I find code quality tends to go down the higher level you look. e.g. libm3's socket stuff.. so I haven't looked at a lot, but I should. - Jay > To: jay.krell at cornell.edu > Date: Mon, 19 Apr 2010 15:31:52 -0700 > From: mika at async.async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] INTEGER > > Jay K writes: > ... > >Let me suggest a small exercise though: > > > > I'm not going to do it. > > > > Write a program that copies files. Or just one file. "cp.exe". > > > > Have it print "progress feedback" to the user -- how many bytes and percen= > >tage copied. Leave out "time estimation". > > > > And also write "ls.exe". > > > > And maybe one last program=2C like "dos2unix.exe" or "fix_nl.exe" that alt= > >ers newlines. This program should work on files that don't fit in memory. > > > > I use the rdwrreset package under PM3. It solves the most glaring problems. > But clearly the file sizes should be done with some sort of data structure > different from 32-bit INTEGER. ARRAY [0..1] OF INTEGER seems to be a > candidate... > > ... > >Also think about what an idea representation of time is. > > > >Isn't a 64bit integer number of units smaller than a second a very good one= > >? > > Modula-3 already uses floating point for this, which has the advantage > you don't need to worry what the base is. > > > > >And aren't infix operators darned nice? > > I have mixed feelings about this. Yes, but... every infix operator takes > several lines of language definition. Those lines can turn into ungodly > amounts of code somewhere. > > I actually do like Hendrik's idea of providing some sort of bignum > support. The reason I don't like LONGINT as much is that it seems it's > just a waste if we're all going to be using 64-bit machines anyhow. > It's arbitrary to have two fixed-width types. Why not three or four? > And why not 128 bits or 16 bits or 36 bits? If on the other hand > you got something substantial out of it that might be another story. > In that case, I would say LONGINT would be a reference type (much like > TEXT) with its associated Longint interface, and infix operators (the > way TEXT has &) per Jay's fondest dreams. Come to think of it, > TEXT and such a LONGINT would have a lot in common. > > Mika -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.async.caltech.edu Tue Apr 20 02:09:58 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Mon, 19 Apr 2010 17:09:58 -0700 Subject: [M3devel] INTEGER In-Reply-To: References: , , , , , <7C7408D0-9A40-4988-BADA-A9FD8C15D388@cs.purdue.edu>, , , , , , , , , , , , , , , , , <20100418023535.3BA9E1A2103@async.async.caltech.edu>, , , , , , <20100418024703.6965B1A2103@async.async.caltech.edu>, , , , <20100418074927.934461A2117@async.async.caltech.edu>, , <04EB7FF8-D304-428D-839E-233FCE009C98@cs.purdue.edu>, , <20100418195901.CDACB1A20F6@async.async.caltech.edu>, , , , <20100419172313.68B241A20D6@async.async.caltech.edu>, , <4F3EE437-0298-410B-9642-C0381E333430@cs.purdue.edu>, , <20100419223152.3D7331A2122@async.async. caltech.edu> Message-ID: <20100420000958.7F5991A2122@async.async.caltech.edu> Jay K writes: >--_747381e9-b91f-4765-9877-7c09d53c76c7_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > Modula-3 already uses floating point for this=2C which has the advantage > > you don't need to worry what the base is.=20 > >=20 > >What do you mean not worry about the "base"? > >I'm not a fan of floating point. If you use integer counts of some small interval, that small interval is what I mean has to be specified somewhere. There's nothing much wrong with floating point. It works fine and Time.T can certainly represent intervals much smaller than a second using any reasonable epoch (almost the age of the universe, I think). > >=20 > >=20 > >> support. The reason I don't like LONGINT as much is that it seems it's >> just a waste if we're all going to be using 64-bit machines anyhow. > > >=20 > >Again=2C you might be right. C got 64bit integers ~18 years ago. We are lat= >e. > >Do you think phones and embedded devices will move to 64bits soon too? > >Are gaming consoles 64bits? No, but again the fact that C does something is not a good reason for us to do it. We need a new language type just to deal with file lengths? I think not. That's the only real use case I've seen so far...? > >Again=2C aside=2C can such an array be made truly abstract? > > I'd like opaque data structures without forcing heap allocation. > >Because=2C you know=2C it is somewhat tricky how to deal with=2C and people > >will differ as to their assumptions of the order of the integers. > Of course it has to be little endian. Mika From jay.krell at cornell.edu Tue Apr 20 02:01:44 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 20 Apr 2010 00:01:44 +0000 Subject: [M3devel] libm3/socket? In-Reply-To: <13143F7F-3922-4D49-AB31-74F7E366DB4A@cs.purdue.edu> References: <20100419173955.08CF82474003@birch.elegosoft.com>, , , , <13143F7F-3922-4D49-AB31-74F7E366DB4A@cs.purdue.edu> Message-ID: Do you think we should leave this one exactly asis, and anyone wanting IPv6 must move to a new abstraction? Or should we provide some partial source (in)compatibility but keep everything in interface Socket. I do believe, btw, that code should work with either IPv4 or v6, or even for that matter IPX. Just pass strings along and let layers below you figure it out. I wouldn't want to introduce Socket6 that only works with IPv6. The likely abstraction therefore is Address = TEXT. << I'm also not sure, but my rough reading of IPv6 stuff is that you don't call socket() until after you resolve the string -- getaddrinfo returns a list of families, so you can't just pass one to socket() and be done. That is, the current separation of Create/Bind/Connect/Accept is a bit off. It can be preserved, but Create wouldn't actually call socket(), it'd just store stream or dgram and put off the rest till Connect/Bind/Listen/Accept (probably just two of the four, when I really know what does what..) - Jay From: hosking at cs.purdue.edu Date: Mon, 19 Apr 2010 19:16:59 -0400 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] libm3/socket? An opportunity to build a better abstraction... ;-) Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 19 Apr 2010, at 17:29, Jay K wrote: Yeah.. anyone one m3devel using it? I guess we'll have to support it either way. The m3-comm/tcp stuff seems to be heavily "based" on it -- copy/paste. This stuff has ipv4 address in its public interface. That really made me not want to deal with it. Though the m3-comm stuff too. Pickles are bound to get broken by any sort of IPv6 support, unless maybe we make new interfaces for it. The new interfaces will work with IPv4 or IPv6. - Jay From: hosking at cs.purdue.edu Date: Mon, 19 Apr 2010 14:36:59 -0400 To: jkrell at elego.de CC: m3commit at elegosoft.com Subject: Re: [M3commit] CVS Update: cm3 Who's nobody? Just because there are no CM3 sources that use does not mean that there are no users out there. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 19 Apr 2010, at 19:39, Jay Krell wrote: CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/04/19 19:39:54 Modified files: cm3/m3-libs/libm3/src/os/Common/: m3makefile cm3/m3-libs/libm3/src/os/POSIX/: m3makefile cm3/m3-libs/libm3/src/os/WIN32/: m3makefile Removed files: cm3/m3-libs/libm3/src/os/Common/: Socket.i3 Socket.m3 cm3/m3-libs/libm3/src/os/POSIX/: SocketPosix.m3 SocketPosixC.c cm3/m3-libs/libm3/src/os/WIN32/: SocketWin32.m3 SocketWin32.m3.sav Log message: Nobody uses libm3's socket support. So empty it out instead of fixing it. Let's focus effort elsewhere, e.g. m3-comm/tcp. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Apr 20 02:43:25 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 20 Apr 2010 00:43:25 +0000 Subject: [M3devel] INTEGER In-Reply-To: <20100420000958.7F5991A2122@async.async.caltech.edu> References: , , , , ,,<7C7408D0-9A40-4988-BADA-A9FD8C15D388@cs.purdue.edu>, , , ,,, , , , , , , , , , , , , , , , , <20100418023535.3BA9E1A2103@async.async.caltech.edu>, , ,,, , ,,<20100418024703.6965B1A2103@async.async.caltech.edu>, ,,, ,,<20100418074927.934461A2117@async.async.caltech.edu>, ,,<04EB7FF8-D304-428D-839E-233FCE009C98@cs.purdue.edu>, ,,<20100418195901.CDACB1A20F6@async.async.caltech.edu>, ,,, ,,<20100419172313.68B241A20D6@async.async.caltech.edu>, , , <4F3EE437-0298-410B-9642-C0381E333430@cs.purdue.edu>, , , , <20100419223152.3D7331A2122@async.async., caltech.edu> , <20100420000958.7F5991A2122@async.async.caltech.edu> Message-ID: > If you use integer counts of some small interval, that small interval > is what I mean has to be specified somewhere. There would be one and only interval for all time measurements. => Whatever NT uses. 10s of nanoseconds I believe. Isn't that similar to saying you have to specify it is seconds? Or seconds is easier to remember and understand? NT's unit is a little difficult for me, granted. > There's nothing much wrong with floating point. It works fine and Time.T > can certainly represent intervals much smaller than a second using any > reasonable epoch (almost the age of the universe, I think). Does Time.T have a large range actually? I haven't figured it out. And are negative times allowed? If no negative times, then not a wide range. > No, but again the fact that C does something is not a good reason for us to do > it. We need a new language type just to deal with file lengths? I think not. > That's the only real use case I've seen so far...? National debt as an integer? I don't know if there are other uses. > Of course it has to be little endian. That's what I think, but I might just be corrupted. It still needs to abstract/opaque, though, so people don't get confused about the lower bits being unsigned, for example. gotta run, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Tue Apr 20 04:46:16 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Mon, 19 Apr 2010 21:46:16 -0500 Subject: [M3devel] INTEGER (and floating point) In-Reply-To: <20100419223152.3D7331A2122@async.async.caltech.edu> References: , , , , , , , , , , , , , <20100418023535.3BA9E1A2103@async.async.caltech.edu>, , , , <20100418024703.6965B1A2103@async.async.caltech.edu>, , <20100418074927.934461A2117@async.async.caltech.edu>, <04EB7FF8-D304-428D-839E-233FCE009C98@cs.purdue.edu>, <20100418195901.CDACB1A20F6@async.async.caltech.edu>, , <20100419172313.68B241A20D6@async.async.caltech.edu>, <4F3EE437-0298-410B-9642-C0381E333430@cs.purdue.edu> <20100419223152.3D7331A2122@async.async.caltech.edu> Message-ID: <4BCD1578.3050900@lcwb.coop> Mika Nystrom wrote: > > Modula-3 already uses floating point for this, which has the advantage > you don't need to worry what the base is. The designers of Algol 60 gave us several good new ideas, but one place they did a huge disservice was in renaming what had been called "floating point" as "real". This was and still is a lie. One ugly property that floating point has is that the smallest interval between representable values keeps getting larger as the value gets larger. Moreover, for representations of equal bit counts, floating will always eventually get to the point that it no longer can even represent the integers. The interval eventually becomes two, then four, eight, etc. (if the exponent is a power of two, as it usually is). There are places where you care about large value range *and* precision down to the integers, and file sizes are likely to be one of them. National budgets might be too. Ditto times. Sometimes you can stand the erosion of precision in large values, but not always. Of course, if you compare a 32-bit integer to a 64-bit float, this won't happen. But I think the 64-bit float should be compared to a 64-bit integer. > Mika > From hendrik at topoi.pooq.com Tue Apr 20 01:52:12 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 19 Apr 2010 19:52:12 -0400 Subject: [M3devel] INTEGER In-Reply-To: References: <20100419155702.GB8759@topoi.pooq.com> Message-ID: <20100419235212.GA10670@topoi.pooq.com> On Mon, Apr 19, 2010 at 09:20:00PM +0000, Jay K wrote: > > For the record, anyone using Windows (NT/2000/XP/2003/etc.) is using 16bit characters *all the time*. > > MacOSX maybe also. > > I think utf8 is kind of a hack to let folks get away without really doing anything. > > Granted, I didn't realize till recently that strcmp works on > utf8..maybe a really clever idea.. utf8 was a really clever idea. Unless you need to isolate specific characters and do something with them, most code manipulating text needn't care whether it's UTF8 or not. -- hendrik From jay.krell at cornell.edu Tue Apr 20 07:34:10 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 20 Apr 2010 05:34:10 +0000 Subject: [M3devel] INTEGER (and floating point) In-Reply-To: <4BCD1578.3050900@lcwb.coop> References: , , , ,,, , , , , , , , , , , , , <20100418023535.3BA9E1A2103@async.async.caltech.edu>, ,,, , , <20100418024703.6965B1A2103@async.async.caltech.edu>, , , , <20100418074927.934461A2117@async.async.caltech.edu>, , <04EB7FF8-D304-428D-839E-233FCE009C98@cs.purdue.edu>, , <20100418195901.CDACB1A20F6@async.async.caltech.edu>, , , , <20100419172313.68B241A20D6@async.async.caltech.edu>, , <4F3EE437-0298-410B-9642-C0381E333430@cs.purdue.edu> , <20100419223152.3D7331A2122@async.async.caltech.edu>, <4BCD1578.3050900@lcwb.coop> Message-ID: Floating point is just wierd. very large + very small = the same very large I realize that is approximately correct, but approximations can be worrisome. And it can be costly to avoid making them as well. Stuck. > Of course, if you compare a 32-bit integer to a 64-bit float, this > won't happen. But I think the 64-bit float should be compared to > a 64-bit integer. Eh? A 64bit float cannot store all 64bit integer values. Typically 64bit float has about 53bits of precision. Local float.h: #define DBL_MANT_DIG 53 /* # of bits in mantissa */ #define FLT_MANT_DIG 24 /* # of bits in mantissa */ Now, interestingly, the IA64 floating point registers are large enough, they do have at least 64bits of precision, and integer division/mod is implemented using floating point. I was surprised to step through my hash table code and see floating point used. :) - Jay > Date: Mon, 19 Apr 2010 21:46:16 -0500 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: Re: [M3devel] INTEGER (and floating point) > > > > Mika Nystrom wrote: > > > > Modula-3 already uses floating point for this, which has the advantage > > you don't need to worry what the base is. > > The designers of Algol 60 gave us several good new ideas, but one place > they did a huge disservice was in renaming what had been called "floating > point" as "real". This was and still is a lie. > > One ugly property that floating point has is that the smallest interval > between representable values keeps getting larger as the value gets > larger. Moreover, for representations of equal bit counts, floating > will always eventually get to the point that it no longer can even represent > the integers. The interval eventually becomes two, then four, eight, > etc. (if the exponent is a power of two, as it usually is). > > There are places where you care about large value range *and* precision > down to the integers, and file sizes are likely to be one of them. > National budgets might be too. Ditto times. Sometimes you can stand > the erosion of precision in large values, but not always. > > Of course, if you compare a 32-bit integer to a 64-bit float, this > won't happen. But I think the 64-bit float should be compared to > a 64-bit integer. > > > Mika > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Tue Apr 20 17:29:42 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Tue, 20 Apr 2010 10:29:42 -0500 Subject: [M3devel] INTEGER In-Reply-To: <20100419223152.3D7331A2122@async.async.caltech.edu> References: , , , , , , , , , , , , , <20100418023535.3BA9E1A2103@async.async.caltech.edu>, , , , <20100418024703.6965B1A2103@async.async.caltech.edu>, , <20100418074927.934461A2117@async.async.caltech.edu>, <04EB7FF8-D304-428D-839E-233FCE009C98@cs.purdue.edu>, <20100418195901.CDACB1A20F6@async.async.caltech.edu>, , <20100419172313.68B241A20D6@async.async.caltech.edu>, <4F3EE437-0298-410B-9642-C0381E333430@cs.purdue.edu> <20100419223152.3D7331A2122@async.async.caltech.edu> Message-ID: <4BCDC866.6050804@lcwb.coop> The designers of Modula-3 gave use not one but three floating point types. They explicitly justified this as matching the range of hardware arithmetic provided by set of common processors of the day. They didn't say this (to my knowledge), but one integer type also matched the hardware of the day. But the period when practically all processors had the same word size was a historical anomaly. It was a nice halcyon time in that respect, and it allowed us to avoid some messy problems. But it never was true prior to that era, and it is no longer true. I doubt it will be again. Despite the proliferation of 64-bit machines, there will be useful 32-bit ones around for a years. Not everybody buys the newest every three years, and 32 bits is still capable of a lot. I don't see them being retired at anything like the rate 16-bit machines were, because they don't suffer the limitations. And then we have the proliferation of embedded and hand-held devices, which as I am hearing, are already well out ahead of server and desktop computers in raw processor count. So I think keeping two integer sizes in the language removes what many people would consider a serious obstacle. Moreover, the way the two integer sizes is are now defined is cleaner than I have seen in any other language. It also somewhat follows the way the three floating types were done in the original language in that it preserves the type-uniqueness of every expression. It further makes the static legality and semantics of code as close to implementation-independent as it was in the unmodified language. And it does not change the legality or static semantics of any old code. Mika Nystrom wrote: > > I actually do like Hendrik's idea of providing some sort of bignum > support. The reason I don't like LONGINT as much is that it seems it's > just a waste if we're all going to be using 64-bit machines anyhow. > It's arbitrary to have two fixed-width types. Why not three or four? > And why not 128 bits or 16 bits or 36 bits? If on the other hand > you got something substantial out of it that might be another story. > In that case, I would say LONGINT would be a reference type (much like > TEXT) with its associated Longint interface, and infix operators (the > way TEXT has &) per Jay's fondest dreams. Come to think of it, > TEXT and such a LONGINT would have a lot in common. > > Mika > From rodney_bates at lcwb.coop Tue Apr 20 17:59:57 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Tue, 20 Apr 2010 10:59:57 -0500 Subject: [M3devel] INTEGER In-Reply-To: <20100419155702.GB8759@topoi.pooq.com> References: <20100418024703.6965B1A2103@async.async.caltech.edu> <20100418074927.934461A2117@async.async.caltech.edu> <04EB7FF8-D304-428D-839E-233FCE009C98@cs.purdue.edu> <20100418195901.CDACB1A20F6@async.async.caltech.edu> <20100419155702.GB8759@topoi.pooq.com> Message-ID: <4BCDCF7D.604@lcwb.coop> hendrik at topoi.pooq.com wrote: > On Sun, Apr 18, 2010 at 12:59:01PM -0700, Mika Nystrom wrote: >> And the new m3tk, stubgen, and compiler(?) won't compile using PM3 or >> SRC M3 since we're no longer using the language of the Green Book. >> (Same comment goes for WIDECHAR, by the way.) > > When I use Unicode characters, I find myself defining them to be > INTEGERs, because I'm always worried that WIDECHARs might be omly 16 bits. Actually, I favor making WIDECHAR big enough to hold all the defined Unicode values, which I understand have been more that 2^16 for some time now. The only thing the language definition says about WIDECHAR is that it has at least 65536 values and the first 65536 correspond to the first 65536 Unicode characters. It could be bigger. Moreover, as I recall from a while back, the compiler, old and new Text implementation, other libraries, m3gdb, and maybe pickles are only a couple of declaration changes away from supporting some bigger range for WIDECHAR. (I think I am the one who put WIDECHAR into the language reference, and that was only recently, despite its being in the cm3 language for years. I also see that this has not propagated from the .tex version into the .html and .pdf files.) > > Strings of WIDECHARS are probably unnecesary. The last program I wrote > that used Unicode used INTEGERs for characters, and arrays of INTEGERS > for strings. But I think it was a mistake to do it this way, and when I > have time I'll rewrite it. UTF-8 seems to be the way to go; strings of > Unicode can easily be manipulated as ordinary TEXT. In fact, I > think there are few if any places in my code where I would have had to > do anything special whatsoever if I had just used UTF8 in TEXT. The > program would simply become simpler. This is only true if you handle strings in certain common but restricted ways. If you just move strings around, UTF-8 will often work with little or no code change. OTOH, if you need to access characters non-sequentially or make any examination or production of individual characters not in the Iso-latin-1 subset, any variable-length encoding quickly becomes unworkable. Text.Sub and Text.GetChar won't work in any sensible way if they view the string as a string of 8-bit bytes, when it's actually not. Reimplementing these to understand UTF-8 would make what was O(1) become O(n). Ditto Text.Length. > > -- hendrik > From jay.krell at cornell.edu Tue Apr 20 18:59:53 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 20 Apr 2010 16:59:53 +0000 Subject: [M3devel] INTEGER In-Reply-To: <4BCDC866.6050804@lcwb.coop> References: , , , ,,, , , , , , , , , , , , , <20100418023535.3BA9E1A2103@async.async.caltech.edu>, ,,, , , <20100418024703.6965B1A2103@async.async.caltech.edu>, , , , <20100418074927.934461A2117@async.async.caltech.edu>, , <04EB7FF8-D304-428D-839E-233FCE009C98@cs.purdue.edu>, , <20100418195901.CDACB1A20F6@async.async.caltech.edu>, , , , <20100419172313.68B241A20D6@async.async.caltech.edu>, , <4F3EE437-0298-410B-9642-C0381E333430@cs.purdue.edu> , <20100419223152.3D7331A2122@async.async.caltech.edu>, <4BCDC866.6050804@lcwb.coop> Message-ID: Thank you Rodney. Good, interesting points. > and 32 bits is still capable of a lot Agreed. There is an interesting construct that seems common -- 64bit kernels that can run 32bit or 64bit usermode code. That is what NT looks like, and Solaris, and Linux on sparc, and Irix (obsolete thought it may be..), and AIX, and HP-UX, and at least some configurations of Mac. In particular I read that sparc32 is quite obsolete from the Linux kernel point of view, there is no 32bit sparc Linux kernel, but 32bit usermode code is still fine. There is probably some correlation to like "systems that moved to 64bit processors earlier provide better support for 32bit usermode", and "systems that moved to 64bit processors later see 32bit support as more temporary". ie. commercial Unix moved to 64bit first, NT and free Unix later. OpenBSD is "pure", they only ever support one "architecture". The seeming "problem" (not a problem in this context) is managing multiple GB of cheap physical RAM across an entire physical system. The overall system these days can have so much memory, but individual processes don't necessarily need it. As well, people often speak of 64bit being slower due to larger pointers, larger data. As well as larger code to load 64bit values. x86 is a bit of anomaly here in that the widening to 64bits also "cleaned up" a lot -- added many more registers not just wider registers, established a baseline for a different floating point instruction set (SSE), easier to generate position independent code via RIP-relative addressing, and at least on NT a better model for exception handling. So x86 switching to 64bit is a better sell than others. But still has the larger pointers/data. So you know, what size buffer do I need to hold the concatenation of two strings whose maximum length is 100? Or what size integer do I need to hold the result of multiplying two n bit integers? The kernel overarches all pieces/processes and needs perhaps larger capacity to handle it all than the pieces themselves need. > proliferation of embedded and hand-held devices, which as I am > hearing, are already well out ahead of server and desktop computers in raw processor count I heard this over 10 years ago, that embedded systems ship far more processors than "computers", though it was lower end devices -- cars, microwaves, digital watches. This world lingered in programming in assembly and using cheaper 8 and 16bit CPUs and MMU-less hardware longer. Manufacturing in such large volume, it was worth saving money. Nowadays we hear about them all being 32bit and having MMUs (e.g. phones). > Not everybody buys the newest every three years We are closer to 7 years into AMD64 though. :) Except then 32bit came back -- Atom. :) - Jay > Date: Tue, 20 Apr 2010 10:29:42 -0500 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: Re: [M3devel] INTEGER > > The designers of Modula-3 gave use not one but three floating point types. > They explicitly justified this as matching the range of hardware arithmetic > provided by set of common processors of the day. > > They didn't say this (to my knowledge), but one integer type also matched > the hardware of the day. But the period when practically all processors > had the same word size was a historical anomaly. It was a nice halcyon > time in that respect, and it allowed us to avoid some messy problems. > > But it never was true prior to that era, and it is no longer true. > I doubt it will be again. Despite the proliferation of 64-bit > machines, there will be useful 32-bit ones around for a years. > Not everybody buys the newest every three years, and 32 bits is > still capable of a lot. I don't see them being retired at anything > like the rate 16-bit machines were, because they don't suffer the > limitations. And then we have the proliferation of embedded and > hand-held devices, which as I am hearing, are already well out ahead > of server and desktop computers in raw processor count. > > So I think keeping two integer sizes in the language removes what > many people would consider a serious obstacle. Moreover, the way > the two integer sizes is are now defined is cleaner than I have > seen in any other language. It also somewhat follows the way the > three floating types were done in the original language in that > it preserves the type-uniqueness of every expression. It further > makes the static legality and semantics of code as close to > implementation-independent as it was in the unmodified language. > And it does not change the legality or static semantics of any > old code. > > Mika Nystrom wrote: > > > > I actually do like Hendrik's idea of providing some sort of bignum > > support. The reason I don't like LONGINT as much is that it seems it's > > just a waste if we're all going to be using 64-bit machines anyhow. > > It's arbitrary to have two fixed-width types. Why not three or four? > > And why not 128 bits or 16 bits or 36 bits? If on the other hand > > you got something substantial out of it that might be another story. > > In that case, I would say LONGINT would be a reference type (much like > > TEXT) with its associated Longint interface, and infix operators (the > > way TEXT has &) per Jay's fondest dreams. Come to think of it, > > TEXT and such a LONGINT would have a lot in common. > > > > Mika > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.async.caltech.edu Tue Apr 20 19:12:35 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Tue, 20 Apr 2010 10:12:35 -0700 Subject: [M3devel] INTEGER In-Reply-To: <4BCDC866.6050804@lcwb.coop> References: , , , , , , , , , , , , , <20100418023535.3BA9E1A2103@async.async.caltech.edu>, , , , <20100418024703.6965B1A2103@async.async.caltech.edu>, , <20100418074927.934461A2117@async.async.caltech.edu>, <04EB7FF8-D304-428D-839E-233FCE009C98@cs.purdue.edu>, <20100418195901.CDACB1A20F6@async.async.caltech.edu>, , <20100419172313.68B241A20D6@async.async.caltech.edu>, <4F3EE437-0298-410B-9642-C0381E333430@cs.purdue.edu> <20100419223152.3D7331A2122@async.async.caltech.edu> <4BCDC866.6050804@lcwb.coop> Message-ID: <20100420171235.B8F0C1A2103@async.async.caltech.edu> "Rodney M. Bates" writes: >The designers of Modula-3 gave use not one but three floating point types. >They explicitly justified this as matching the range of hardware arithmetic >provided by set of common processors of the day. > >They didn't say this (to my knowledge), but one integer type also matched >the hardware of the day. But the period when practically all processors >had the same word size was a historical anomaly. It was a nice halcyon >time in that respect, and it allowed us to avoid some messy problems. > >But it never was true prior to that era, and it is no longer true. >I doubt it will be again. Despite the proliferation of 64-bit >machines, there will be useful 32-bit ones around for a years. >Not everybody buys the newest every three years, and 32 bits is >still capable of a lot. I don't see them being retired at anything >like the rate 16-bit machines were, because they don't suffer the >limitations. And then we have the proliferation of embedded and >hand-held devices, which as I am hearing, are already well out ahead >of server and desktop computers in raw processor count. > >So I think keeping two integer sizes in the language removes what >many people would consider a serious obstacle. Moreover, the way >the two integer sizes is are now defined is cleaner than I have >seen in any other language. It also somewhat follows the way the >three floating types were done in the original language in that >it preserves the type-uniqueness of every expression. It further >makes the static legality and semantics of code as close to >implementation-independent as it was in the unmodified language. >And it does not change the legality or static semantics of any >old code. I agree LONGINT isn't horrible. However, I am not sure I agree with your description above. 1. Modula-3 provides three floating-point formats because *each* common processor architecture provided (and provides) support for generally at least three floating-point formats. The point was to give programmers easy access to the hardware in their own machines, not really so that IBM programmers could have an extra format for VAX compatibility. Note that I don't believe that it was intended that EXTENDED would be emulated by the compiler either: the point was really to give programmers access to the formats provided efficiently by their hardware. 2. 64-bit machines don't actually get two different integer formats with the way LONGINT works. INTEGER and LONGINT are both 64 bits. That was not the intention with the floating-point formats either. 3. 64-bit machines were hardly unforeseen by DEC's research people, given that their company introduced Alpha just after Modula-3 and that DECWRL across town was working on 64-bit ECL machines. In fact I think Modula-3 had versions with 64-bit INTEGERs already in 1992? (To use Jay's expression, it's now 18 years later, and many C environments still haven't caught up---int is still 32 bits in many of them!) People at SRC surely had a lot of 64-bit machines with Modula-3 programs running on them in the early 90s. Somehow the problem of representing 64-bit integers on older VAX, MIPS, i386 systems just didn't arise for them? 4. I still haven't seen any really convincing use cases. What's it for? The lack of LONGINT was an obstacle to what, precisely? 5. Finally, is it the intention that LONGINT be fixed at 64 bits forevermore? (See point 2.) This seems to completely fly in the face of M3's philosophy. (See Hendrik's arguments.) Mika From hosking at cs.purdue.edu Tue Apr 20 19:31:45 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 20 Apr 2010 13:31:45 -0400 Subject: [M3devel] INTEGER In-Reply-To: <20100420171235.B8F0C1A2103@async.async.caltech.edu> References: , , , , , , , , , , , , , <20100418023535.3BA9E1A2103@async.async.caltech.edu>, , , , <20100418024703.6965B1A2103@async.async.caltech.edu>, , <20100418074927.934461A2117@async.async.caltech.edu>, <04EB7FF8-D304-428D-839E-233FCE009C98@cs.purdue.edu>, <20100418195901.CDACB1A20F6@async.async.caltech.edu>, , <20100419172313.68B241A20D6@async.async.caltech.edu>, <4F3EE437-0298-410B-9642-C0381E333430@cs.purdue.edu> <20100419223152.3D7331A2122@async.async.caltech.edu> <4BCDC866.6050804@lcwb.coop> <20100420171235! .B8F0C1A2103@async.async.caltech.edu> Message-ID: On 20 Apr 2010, at 13:12, Mika Nystrom wrote: > "Rodney M. Bates" writes: >> The designers of Modula-3 gave use not one but three floating point types. >> They explicitly justified this as matching the range of hardware arithmetic >> provided by set of common processors of the day. >> >> They didn't say this (to my knowledge), but one integer type also matched >> the hardware of the day. But the period when practically all processors >> had the same word size was a historical anomaly. It was a nice halcyon >> time in that respect, and it allowed us to avoid some messy problems. >> >> But it never was true prior to that era, and it is no longer true. >> I doubt it will be again. Despite the proliferation of 64-bit >> machines, there will be useful 32-bit ones around for a years. >> Not everybody buys the newest every three years, and 32 bits is >> still capable of a lot. I don't see them being retired at anything >> like the rate 16-bit machines were, because they don't suffer the >> limitations. And then we have the proliferation of embedded and >> hand-held devices, which as I am hearing, are already well out ahead >> of server and desktop computers in raw processor count. >> >> So I think keeping two integer sizes in the language removes what >> many people would consider a serious obstacle. Moreover, the way >> the two integer sizes is are now defined is cleaner than I have >> seen in any other language. It also somewhat follows the way the >> three floating types were done in the original language in that >> it preserves the type-uniqueness of every expression. It further >> makes the static legality and semantics of code as close to >> implementation-independent as it was in the unmodified language. >> And it does not change the legality or static semantics of any >> old code. > > I agree LONGINT isn't horrible. However, I am not sure I agree > with your description above. > > 1. Modula-3 provides three floating-point formats because *each* common > processor architecture provided (and provides) support for generally at > least three floating-point formats. The point was to give programmers > easy access to the hardware in their own machines, not really so that IBM > programmers could have an extra format for VAX compatibility. Note that > I don't believe that it was intended that EXTENDED would be emulated by > the compiler either: the point was really to give programmers access to > the formats provided efficiently by their hardware. In the current implementation EXTENDED=LONGREAL. > 2. 64-bit machines don't actually get two different integer formats > with the way LONGINT works. INTEGER and LONGINT are both 64 bits. > That was not the intention with the floating-point formats either. Current implementation, yes, but this is not fixed. > 3. 64-bit machines were hardly unforeseen by DEC's research people, > given that their company introduced Alpha just after Modula-3 and that > DECWRL across town was working on 64-bit ECL machines. In fact I think > Modula-3 had versions with 64-bit INTEGERs already in 1992? (To use > Jay's expression, it's now 18 years later, and many C environments still > haven't caught up---int is still 32 bits in many of them!) People at > SRC surely had a lot of 64-bit machines with Modula-3 programs running > on them in the early 90s. Somehow the problem of representing 64-bit > integers on older VAX, MIPS, i386 systems just didn't arise for them? Yep. Love my Alpha so much I can't bear to throw it away. > 4. I still haven't seen any really convincing use cases. What's it for? > The lack of LONGINT was an obstacle to what, precisely? I think the only one we have is file sizes... > 5. Finally, is it the intention that LONGINT be fixed at 64 bits > forevermore? (See point 2.) This seems to completely fly in the face > of M3's philosophy. (See Hendrik's arguments.) The only constraint imposed is BITSIZE(LONGINT) >= BITSIZE(INTEGER). > > Mika > > > From jay.krell at cornell.edu Tue Apr 20 20:05:25 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 20 Apr 2010 18:05:25 +0000 Subject: [M3devel] INTEGER In-Reply-To: <20100420171235.B8F0C1A2103@async.async.caltech.edu> References: , , , ,,, , , , , , , , , , , , , <20100418023535.3BA9E1A2103@async.async.caltech.edu>, ,,, , , <20100418024703.6965B1A2103@async.async.caltech.edu>, , , , <20100418074927.934461A2117@async.async.caltech.edu>, , <04EB7FF8-D304-428D-839E-233FCE009C98@cs.purdue.edu>, , <20100418195901.CDACB1A20F6@async.async.caltech.edu>, , , , <20100419172313.68B241A20D6@async.async.caltech.edu>, , <4F3EE437-0298-410B-9642-C0381E333430@cs.purdue.edu>, , <20100419223152.3D7331A2122@async.async.caltech.edu>, <4BCDC866.6050804@lcwb.coop>, <20100420171235.B8F0C1A2103@async.async.caltech.edu> Message-ID: > (To use Jay's expression, it's now 18 years later, and > many C environments still haven't caught up---int is still 32 bits in many of them!) Int is 32 bits in almost every C environment. Maybe some Cray has 64bit int. But every system I've seen has 32 bit (or 16 bit) int. Do any C environments lack a 64bit "long" or "long long" or "__int64"? I believe gcc is written to not depend on any 64bit integer or "long long" being guaranteed available, so it can compile with a compiler that only has up to "long", be it 32bits or 64bits. I believe they represent 64bit integers internally as a pair of longs and always take 32bits from each. It is a little confusing but also makes sense. On systems with 64bit long, which there are many of, they waste space. It'd seem better to use a pair of 32bits ints or one 64bit long or long long. But it is portable, even if int is 16 bits. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.async.caltech.edu Tue Apr 20 20:07:15 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Tue, 20 Apr 2010 11:07:15 -0700 Subject: [M3devel] INTEGER In-Reply-To: References: , , , , , , , , , , , , , <20100418023535.3BA9E1A2103@async.async.caltech.edu>, , , , <20100418024703.6965B1A2103@async.async.caltech.edu>, , <20100418074927.934461A2117@async.async.caltech.edu>, <04EB7FF8-D304-428D-839E-233FCE009C98@cs.purdue.edu>, <20100418195901.CDACB1A20F6@async.async.caltech.edu>, , <20100419172313.68B241A20D6@async.async.caltech.edu>, <4F3EE437-0298-410B-9642-C0381E333430@cs.purdue.edu> <20100419223152.3D7331A2122@async.async.caltech.edu> <4BCDC866.6050804@lcwb.coop> <20100420171235! .B8F0C1A2103@async.async.caltech.edu> Message-ID: <20100420180715.52C391A2103@async.async.caltech.edu> Tony Hosking writes: >On 20 Apr 2010, at 13:12, Mika Nystrom wrote: ... >> easy access to the hardware in their own machines, not really so that = >IBM >> programmers could have an extra format for VAX compatibility. Note = >that >> I don't believe that it was intended that EXTENDED would be emulated = >by >> the compiler either: the point was really to give programmers access = >to >> the formats provided efficiently by their hardware. > >In the current implementation EXTENDED=3DLONGREAL. Ok, but EXTENDED is still something that is efficiently provided by my hardware. Not something efficiently provided by someone else's hardware! >> 4. I still haven't seen any really convincing use cases. What's it = >for? >> The lack of LONGINT was an obstacle to what, precisely? > >I think the only one we have is file sizes... > >> 5. Finally, is it the intention that LONGINT be fixed at 64 bits >> forevermore? (See point 2.) This seems to completely fly in the face >> of M3's philosophy. (See Hendrik's arguments.) > >The only constraint imposed is BITSIZE(LONGINT) >=3D BITSIZE(INTEGER). I am not so sure here. Rodney's argument has in fact convinced me that the current version of LONGINT is wrong and perhaps evil. It should either go away completely or be replaced by Hendrik's suggestion. Here's why. The argument is that if I have an N-bit machine, for N References: , , , , , , , , , , , , , <20100418023535.3BA9E1A2103@async.async.caltech.edu>, , , , <20100418024703.6965B1A2103@async.async.caltech.edu>, , <20100418074927.934461A2117@async.async.caltech.edu>, <04EB7FF8-D304-428D-839E-233FCE009C98@cs.purdue.edu>, <20100418195901.CDACB1A20F6@async.async.caltech.edu>, , <20100419172313.68B241A20D6@async.async.caltech.edu>, <4F3EE437-0298-410B-9642-C0381E333430@cs.purdue.edu> <20100419223152.3D7331A2122@async.async.caltech.edu> <4BCDC866.6050804@lcwb.coop> <20100420171235.B8F0C1A2103@async.async.caltech.edu> Message-ID: >-----Original Message----- >From: Mika Nystrom [mailto:mika at async.async.caltech.edu] >Sent: Tuesday, April 20, 2010 1:13 PM > >5. Finally, is it the intention that LONGINT be fixed at 64 bits >forevermore? (See point 2.) This seems to completely fly in the face >of M3's philosophy. (See Hendrik's arguments.) > Mika My "understanding" was that LONGINT would be a MINimum of 64-bits, but could be larger on certain platforms. For those platforms where the native integer size is already 64-bits, it could be possible that BITSIZE of INTEGER and LONGINT are indeed the same, 64-bits. It could also be that on some platforms we could have 64-bit INTEGER and maybe 128-bit LONGINT. Thus, the BITSIZE of LONGINT is both platform and implementation-dependent, but constrained to have a lower-bound of 64-bits. If I'm not understanding this correctly, someone please enlighten me. --Randy CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This email may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from reviewing, copying, using, disclosing or distributing to others the information in this email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require advance export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. From jay.krell at cornell.edu Tue Apr 20 23:36:12 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 20 Apr 2010 21:36:12 +0000 Subject: [M3devel] INTEGER In-Reply-To: References: , , , ,,, , , , , ,,, , , , ,,<20100418023535.3BA9E1A2103@async.async.caltech.edu>, ,,, , , <20100418024703.6965B1A2103@async.async.caltech.edu>, , , , <20100418074927.934461A2117@async.async.caltech.edu>, , <04EB7FF8-D304-428D-839E-233FCE009C98@cs.purdue.edu>, , <20100418195901.CDACB1A20F6@async.async.caltech.edu>, , , , <20100419172313.68B241A20D6@async.async.caltech.edu>, , <4F3EE437-0298-410B-9642-C0381E333430@cs.purdue.edu>, , <20100419223152.3D7331A2122@async.async.caltech.edu>, <4BCDC866.6050804@lcwb.coop>, <20100420171235.B8F0C1A2103@async.async.caltech.edu>, Message-ID: Randy, This is correct. Are we subtly suggesting that LONGINT be 128 bits on 64 bit systems, to avoid the creeping assumption that it is 64 bits? Seems ok, though it'd be some work in the compiler -- but maybe, again, a library based implementation, like how atomic is structured and possibly implemented. Would anyone use this type? Or there'd be m3core/unix/32bit/types.i3 off_t = LONGINT, m3core/unix/64bit/types.i3 off_t = INTEGER? And everywhere else anyone wanted a 64 bit type? Or we would say off_t = BITS 64 FOR [(-?)16_800000000000L..16_7FFFFFFFFFFFL]? That is preferable since it avoids forking a file..though it might be incorrect. 16_800000000000L is positive if 128bits, and -16_800000000000L is correct for 128bits but overflows for 64 bits. I think maybe. - Jay > From: rcolebur at SCIRES.COM > To: m3devel at elegosoft.com > Date: Tue, 20 Apr 2010 15:56:26 -0400 > Subject: Re: [M3devel] INTEGER > > >-----Original Message----- > >From: Mika Nystrom [mailto:mika at async.async.caltech.edu] > >Sent: Tuesday, April 20, 2010 1:13 PM > > > >5. Finally, is it the intention that LONGINT be fixed at 64 bits > >forevermore? (See point 2.) This seems to completely fly in the face > >of M3's philosophy. (See Hendrik's arguments.) > > Mika > > My "understanding" was that LONGINT would be a MINimum of 64-bits, but could be larger on certain platforms. For those platforms where the native integer size is already 64-bits, it could be possible that BITSIZE of INTEGER and LONGINT are indeed the same, 64-bits. It could also be that on some platforms we could have 64-bit INTEGER and maybe 128-bit LONGINT. Thus, the BITSIZE of LONGINT is both platform and implementation-dependent, but constrained to have a lower-bound of 64-bits. If I'm not understanding this correctly, someone please enlighten me. > --Randy > > > > > > CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This email may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from reviewing, copying, using, disclosing or distributing to others the information in this email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. > > EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require advance export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Apr 20 23:42:49 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 20 Apr 2010 21:42:49 +0000 Subject: [M3devel] INTEGER In-Reply-To: <20100420180715.52C391A2103@async.async.caltech.edu> References: , , , ,,, , , , , , , , , , , , , <20100418023535.3BA9E1A2103@async.async.caltech.edu>, ,,, , , <20100418024703.6965B1A2103@async.async.caltech.edu>, , , , <20100418074927.934461A2117@async.async.caltech.edu>, , <04EB7FF8-D304-428D-839E-233FCE009C98@cs.purdue.edu>, , <20100418195901.CDACB1A20F6@async.async.caltech.edu>, , , , <20100419172313.68B241A20D6@async.async.caltech.edu>, , <4F3EE437-0298-410B-9642-C0381E333430@cs.purdue.edu>, , <20100419223152.3D7331A2122@async.async.caltech.edu>, <4BCDC866.6050804@lcwb.coop> <20100420171235!, .B8F0C1A2103@async.async.caltech.edu>, , <20100420180715.52C391A2103@async.async.caltech.edu> Message-ID: Mika I think your point, which I missed for a while is that: Just because some hardware has an efficient 64bit integer called INTEGER, does not justify giving other (32bit) hardware a somewhat efficient 64bit integer called LONGINT. ? The analogy I missed is, just because EXTENDED ought to be 80 bits on x86, it should still be 64bits on most other systems. A "maximum" of 3 floating point types are provided names, but systems that don't want that many can equate some of them. In fact..one might argue... 64bit hardware has very efficient 32bit integer and very efficient 64bit integer, you almost want: 32bit: INTEGER = LONGINT = 32bits 64bit: INTEGER = 32bits, LONGINT = 64bits While I doubt that's is where we are heading, it is in fact what all current C environments do, with one exception, if you map "int" = "INTEGER", "long" = "LONGINT". (The exception is Win64.) But Modula-3 has subranges and packed types, so I guess: INT32 = BITS 32 for [16_80000000..16_7FFFFFFF]; suffices? - Jay > To: hosking at cs.purdue.edu > Date: Tue, 20 Apr 2010 11:07:15 -0700 > From: mika at async.async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] INTEGER > > Tony Hosking writes: > >On 20 Apr 2010, at 13:12, Mika Nystrom wrote: > ... > >> easy access to the hardware in their own machines, not really so that = > >IBM > >> programmers could have an extra format for VAX compatibility. Note = > >that > >> I don't believe that it was intended that EXTENDED would be emulated = > >by > >> the compiler either: the point was really to give programmers access = > >to > >> the formats provided efficiently by their hardware. > > > >In the current implementation EXTENDED=3DLONGREAL. > > Ok, but EXTENDED is still something that is efficiently provided by > my hardware. Not something efficiently provided by someone else's > hardware! > > >> 4. I still haven't seen any really convincing use cases. What's it = > >for? > >> The lack of LONGINT was an obstacle to what, precisely? > > > >I think the only one we have is file sizes... > > > >> 5. Finally, is it the intention that LONGINT be fixed at 64 bits > >> forevermore? (See point 2.) This seems to completely fly in the face > >> of M3's philosophy. (See Hendrik's arguments.) > > > >The only constraint imposed is BITSIZE(LONGINT) >=3D BITSIZE(INTEGER). > > I am not so sure here. > > Rodney's argument has in fact convinced me that the current version of > LONGINT is wrong and perhaps evil. It should either go away completely > or be replaced by Hendrik's suggestion. > > Here's why. The argument is that if I have an N-bit machine, for N out there in the world there is an M-bit machine that for some reason > matters a great deal to me. For some reason I need to be able to write > code that manipulates M-bit integers---because of the existence of this > M-bit machine (or machines)! (Normally we're dealing with the situation > that N=32 and M=64.) So we introduce an M-bit LONGINT. Now it stands to > reason that if the M-bit machine (which I do not own and upon which my > program does not run) is important to me, it is also important to other > Modula-3 programmers. Hence all other implementations of Modula-3 will > *also* provide M-bit integers. > > The M-bit machine of the previous paragraph is of course, in the real > world, a machine with the 64-bit version of the Intel x86 instruction set, > "amd64". How long is it from here to the point where we have programmers > who write code that depends on the fact that M=64, always? > > Mika > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Tue Apr 20 20:00:40 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 20 Apr 2010 14:00:40 -0400 Subject: [M3devel] INTEGER In-Reply-To: <4BCDCF7D.604@lcwb.coop> References: <20100418024703.6965B1A2103@async.async.caltech.edu> <20100418074927.934461A2117@async.async.caltech.edu> <04EB7FF8-D304-428D-839E-233FCE009C98@cs.purdue.edu> <20100418195901.CDACB1A20F6@async.async.caltech.edu> <20100419155702.GB8759@topoi.pooq.com> <4BCDCF7D.604@lcwb.coop> Message-ID: <20100420180040.GA13012@topoi.pooq.com> On Tue, Apr 20, 2010 at 10:59:57AM -0500, Rodney M. Bates wrote: > > > hendrik at topoi.pooq.com wrote: >> On Sun, Apr 18, 2010 at 12:59:01PM -0700, Mika Nystrom wrote: >>> And the new m3tk, stubgen, and compiler(?) won't compile using PM3 or >>> SRC M3 since we're no longer using the language of the Green Book. >>> (Same comment goes for WIDECHAR, by the way.) >> >> When I use Unicode characters, I find myself defining them to be >> INTEGERs, because I'm always worried that WIDECHARs might be omly 16 >> bits. > > Actually, I favor making WIDECHAR big enough to hold all the defined > Unicode values, which I understand have been more that 2^16 for some > time now. The only thing the language definition says about WIDECHAR > is that it has at least 65536 values and the first 65536 correspond to > the first 65536 Unicode characters. It could be bigger. Moreover, as > I recall from a while back, the compiler, old and new Text implementation, > other libraries, m3gdb, and maybe pickles are only a couple of declaration > changes away from supporting some bigger range for WIDECHAR. > > (I think I am the one who put WIDECHAR into the language reference, and > that was only recently, despite its being in the cm3 language for years. I > also see that this has not propagated from the .tex version into the .html > and .pdf files.) > > >> >> Strings of WIDECHARS are probably unnecesary. The last program I wrote >> that used Unicode used INTEGERs for characters, and arrays of INTEGERS >> for strings. But I think it was a mistake to do it this way, and when >> I have time I'll rewrite it. UTF-8 seems to be the way to go; strings >> of Unicode can easily be manipulated as ordinary TEXT. In fact, I >> think there are few if any places in my code where I would have had to >> do anything special whatsoever if I had just used UTF8 in TEXT. The >> program would simply become simpler. > > This is only true if you handle strings in certain common but restricted > ways. If you just move strings around, UTF-8 will often work with little > or no code change. OTOH, if you need to access characters non-sequentially > or make any examination or production of individual characters not in the > Iso-latin-1 subset, any variable-length encoding quickly becomes unworkable. Whe you are doing things like this, you are probably doing something like -- shall I say it? -- *parsing*. There's no need for parsing to stop at the character level. You might as well parse all the way down to bytes. And UTF-8 is designed so that that is particularly easy. > > Text.Sub and Text.GetChar won't work in any sensible way if they view the > string as a string of 8-bit bytes, when it's actually not. Reimplementing > these to understand UTF-8 would make what was O(1) become O(n). > Ditto Text.Length. Exactly. That's why you leave them as byte operations. It's pretty rare that you want to pull six characters out of a string. It's pretty common that you want to pull a word out of a string, having parsed part of it and discovering that the work is n characters wide. You could instead have parsed it and discovered that it is m bytes long. The point is, that it's almost never worthwhile to parse it once and turn it into an array of WIDECHARS and then to parse the result again. Just like compilers -- they don't start by lexically scanning the entire source code and storing it somewhere, and then parsing it afterward. Not normally, anyway. -- hendrik From jay.krell at cornell.edu Wed Apr 21 09:56:22 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 21 Apr 2010 07:56:22 +0000 Subject: [M3devel] Alpha is 32bits! Message-ID: Huh. I found that OpenVMS on Alpha is a hybrid 32bit/64bit system. The default pointer size is 32 bits. You can change it to 64 bits with compiler command line option. I guess this is for greater compatibility with VAX. There are two of many functions. Some are missing in 64 bits. size_t is always 32 bits! http://www.openvms.compaq.com/doc/72final/6467/6467pro_contents.html esp. http://www.openvms.compaq.com/doc/72final/6467/6467pro_006.html#64_bit_obtaining_long_ptrs_sec and newer similar: http://www.openvms.compaq.com/doc/83final/5763/5763pro_007.html#the_64_bit_sec WALLIS> type jmpbuf.c #include #include #include #define SIZE(x) ((unsigned)sizeof(x)) int main() { ? printf("%u %u %u %u %u\n", ??? SIZE(int), ??? SIZE(long), ??? SIZE(void*), ??? SIZE(size_t), ??? SIZE(jmp_buf)); ? return 0; } WALLIS> cc jmpbuf.c WALLIS> link jmpbuf.obj WALLIS> run jmpbuf 4 4 4 4 544 WALLIS> cc /pointer_size=64 jmpbuf.c WALLIS> link jmpbuf.obj WALLIS> run jmpbuf 4 4 8 4 544 I still haven't found the actual header files! So I'm going to work toward ALPHA32_VMS for now. I can try ALPHA64_VMS later. Assuming m3cg offers -m32 and -m64 to handle this. :) ?- Jay From mika at async.async.caltech.edu Wed Apr 21 10:10:22 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Wed, 21 Apr 2010 01:10:22 -0700 Subject: [M3devel] Alpha is 32bits! In-Reply-To: References: Message-ID: <20100421081022.358C01A20E1@async.async.caltech.edu> I remember that DEC cc had options on OSF/1 to use memory in such a way that you could guarantee the first 4 GB you touched were sign-extended 32-bit numbers (so the upper doubleword was 0xffffffff or 0x00000000 always) for some sort of compatibility. But Alpha doesn't have hardware instructions to do memory references with 32-bit pointers as far as I remember. I have the architecture reference here to look in... Mika Jay K writes: > >Huh. I found that OpenVMS on Alpha is a hybrid 32bit/64bit system. > >The default pointer size is 32 bits. You can change it to 64 bits with comp= >iler command line option. >I guess this is for greater compatibility with VAX. >There are two of many functions. Some are missing in 64 bits. >size_t is always 32 bits! > >http://www.openvms.compaq.com/doc/72final/6467/6467pro_contents.html >esp. http://www.openvms.compaq.com/doc/72final/6467/6467pro_006.html#64_bit= >_obtaining_long_ptrs_sec > >and newer similar: http://www.openvms.compaq.com/doc/83final/5763/5763pro_0= >07.html#the_64_bit_sec > >WALLIS> type jmpbuf.c > >#include > >#include > >#include > > > >#define SIZE(x) ((unsigned)sizeof(x)) > > > >int main() > >{ > >=A0 printf("%u %u %u %u %u\n"=2C > >=A0=A0=A0 SIZE(int)=2C > >=A0=A0=A0 SIZE(long)=2C > >=A0=A0=A0 SIZE(void*)=2C > >=A0=A0=A0 SIZE(size_t)=2C > >=A0=A0=A0 SIZE(jmp_buf))=3B > >=A0 return 0=3B > >} > > > >WALLIS> cc jmpbuf.c > >WALLIS> link jmpbuf.obj > >WALLIS> run jmpbuf > >4 4 4 4 544 > > > >WALLIS> cc /pointer_size=3D64 jmpbuf.c > >WALLIS> link jmpbuf.obj > >WALLIS> run jmpbuf > >4 4 8 4 544 > > > >I still haven't found the actual header files! > > >So I'm going to work toward ALPHA32_VMS for now. >I can try ALPHA64_VMS later. >Assuming m3cg offers -m32 and -m64 to handle this. :) > >=A0- Jay > = From jay.krell at cornell.edu Wed Apr 21 10:56:29 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 21 Apr 2010 08:56:29 +0000 Subject: [M3devel] Alpha is 32bits! In-Reply-To: <20100421081022.358C01A20E1@async.async.caltech.edu> References: , <20100421081022.358C01A20E1@async.async.caltech.edu> Message-ID: I believe registers are always 64bits, pointers are sign extended, memory is sure to be allocated in the top/bottom 2GB. The two types of functions can call each other, and 32bit pointers can be passed to functions expecting 64bit pointers. It looks like gcc supports alpha-dec-vms => 32bit and alpha64-dec-vms => 64bits. I'm going to introduce ALPHA32_VMS and ALPHA64_VMS but probably work more on the first initially. ?- Jay ---------------------------------------- > To: jay.krell at cornell.edu > Date: Wed, 21 Apr 2010 01:10:22 -0700 > From: mika at async.async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Alpha is 32bits! > > > > I remember that DEC cc had options on OSF/1 to use memory in such a > way that you could guarantee the first 4 GB you touched were sign-extended > 32-bit numbers (so the upper doubleword was 0xffffffff or 0x00000000 always) > for some sort of compatibility. > > But Alpha doesn't have hardware instructions to do memory references with > 32-bit pointers as far as I remember. I have the architecture reference > here to look in... > > Mika > > Jay K writes: >> >>Huh. I found that OpenVMS on Alpha is a hybrid 32bit/64bit system. >> >>The default pointer size is 32 bits. You can change it to 64 bits with comp= >>iler command line option. >>I guess this is for greater compatibility with VAX. >>There are two of many functions. Some are missing in 64 bits. >>size_t is always 32 bits! >> >>http://www.openvms.compaq.com/doc/72final/6467/6467pro_contents.html >>esp. http://www.openvms.compaq.com/doc/72final/6467/6467pro_006.html#64_bit= >>_obtaining_long_ptrs_sec >> >>and newer similar: http://www.openvms.compaq.com/doc/83final/5763/5763pro_0= >>07.html#the_64_bit_sec >> >>WALLIS> type jmpbuf.c >> >>#include >> >>#include >> >>#include >> >> >> >>#define SIZE(x) ((unsigned)sizeof(x)) >> >> >> >>int main() >> >>{ >> >>=A0 printf("%u %u %u %u %u\n"=2C >> >>=A0=A0=A0 SIZE(int)=2C >> >>=A0=A0=A0 SIZE(long)=2C >> >>=A0=A0=A0 SIZE(void*)=2C >> >>=A0=A0=A0 SIZE(size_t)=2C >> >>=A0=A0=A0 SIZE(jmp_buf))=3B >> >>=A0 return 0=3B >> >>} >> >> >> >>WALLIS> cc jmpbuf.c >> >>WALLIS> link jmpbuf.obj >> >>WALLIS> run jmpbuf >> >>4 4 4 4 544 >> >> >> >>WALLIS> cc /pointer_size=3D64 jmpbuf.c >> >>WALLIS> link jmpbuf.obj >> >>WALLIS> run jmpbuf >> >>4 4 8 4 544 >> >> >> >>I still haven't found the actual header files! >> >> >>So I'm going to work toward ALPHA32_VMS for now. >>I can try ALPHA64_VMS later. >>Assuming m3cg offers -m32 and -m64 to handle this. :) >> >>=A0- Jay >> = From rodney_bates at lcwb.coop Wed Apr 21 16:55:29 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Wed, 21 Apr 2010 09:55:29 -0500 Subject: [M3devel] INTEGER In-Reply-To: <20100420180715.52C391A2103@async.async.caltech.edu> References: , , , , , , <20100418023535.3BA9E1A2103@async.async.caltech.edu>, , , , <20100418024703.6965B1A2103@async.async.caltech.edu>, , <20100418074927.934461A2117@async.async.caltech.edu>, <04EB7FF8-D304-428D-839E-233FCE009C98@cs.purdue.edu>, <20100418195901.CDACB1A20F6@async.async.caltech.edu>, , <20100419172313.68B241A20D6@async.async.caltech.edu>, <4F3EE437-0298-410B-9642-C0381E333430@cs.purdue.edu> <20100419223152.3D7331A2122@async.async.caltech.edu> <4BCDC866.6050804@lcwb.coop> <20100420171235! .B8F0C1A2103@async.async.caltech.edu> <20100420180715.52C391A2103@async.async.caltech.edu> Message-ID: <4BCF11E1.5090609@lcwb.coop> Mika Nystrom wrote: > Tony Hosking writes: >> On 20 Apr 2010, at 13:12, Mika Nystrom wrote: > ... >>> easy access to the hardware in their own machines, not really so that = >> IBM >>> programmers could have an extra format for VAX compatibility. Note = >> that >>> I don't believe that it was intended that EXTENDED would be emulated = >> by >>> the compiler either: the point was really to give programmers access = >> to >>> the formats provided efficiently by their hardware. >> In the current implementation EXTENDED=3DLONGREAL. > > Ok, but EXTENDED is still something that is efficiently provided by > my hardware. Not something efficiently provided by someone else's > hardware! > >>> 4. I still haven't seen any really convincing use cases. What's it = >> for? >>> The lack of LONGINT was an obstacle to what, precisely? >> I think the only one we have is file sizes... >> >>> 5. Finally, is it the intention that LONGINT be fixed at 64 bits >>> forevermore? (See point 2.) This seems to completely fly in the face >>> of M3's philosophy. (See Hendrik's arguments.) >> The only constraint imposed is BITSIZE(LONGINT) >=3D BITSIZE(INTEGER). > > I am not so sure here. > > Rodney's argument has in fact convinced me that the current version of > LONGINT is wrong and perhaps evil. It should either go away completely > or be replaced by Hendrik's suggestion. > > Here's why. The argument is that if I have an N-bit machine, for N out there in the world there is an M-bit machine that for some reason > matters a great deal to me. For some reason I need to be able to write > code that manipulates M-bit integers---because of the existence of this > M-bit machine (or machines)! It has never been motivated by the existence of machines with various native arithmetic sizes. It is about problems that need big value ranges to work. Its also about making it convenient to write portable code that solves them. (Well, that part does have to do with the machines that exist.) And making the type checking, etc. not change on the different machines. And using the most efficient arithmetic consistent with correct answers. Normally we're dealing with the situation > that N=32 and M=64.) So we introduce an M-bit LONGINT. Now it stands to > reason that if the M-bit machine (which I do not own and upon which my > program does not run) is important to me, it is also important to other > Modula-3 programmers. Hence all other implementations of Modula-3 will > *also* provide M-bit integers. > > The M-bit machine of the previous paragraph is of course, in the real > world, a machine with the 64-bit version of the Intel x86 instruction set, > "amd64". How long is it from here to the point where we have programmers > who write code that depends on the fact that M=64, always? LONGINT presents the same opportunity/invitation/temptation to write code that make such assumptions as does INTEGER, or for that matter, REFANY, or gobs of other things in the original language. So LONGINT is just as evil as INTEGER. > > Mika > > From hendrik at topoi.pooq.com Wed Apr 21 20:56:31 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Wed, 21 Apr 2010 14:56:31 -0400 Subject: [M3devel] INTEGER In-Reply-To: <4BCF11E1.5090609@lcwb.coop> References: <4F3EE437-0298-410B-9642-C0381E333430@cs.purdue.edu> <20100419223152.3D7331A2122@async.async.caltech.edu> <4BCDC866.6050804@lcwb.coop> <20100420171235!.B8F0C1A2103@async.async.caltech.edu> <20100420180715.52C391A2103@async.async.caltech.edu> <4BCF11E1.5090609@lcwb.coop> Message-ID: <20100421185631.GA17051@topoi.pooq.com> On Wed, Apr 21, 2010 at 09:55:29AM -0500, Rodney M. Bates wrote: > > > Mika Nystrom wrote: >> Tony Hosking writes: >>> On 20 Apr 2010, at 13:12, Mika Nystrom wrote: >> ... >>>> easy access to the hardware in their own machines, not really so that = >>> IBM >>>> programmers could have an extra format for VAX compatibility. Note = >>> that >>>> I don't believe that it was intended that EXTENDED would be emulated = >>> by >>>> the compiler either: the point was really to give programmers access = >>> to >>>> the formats provided efficiently by their hardware. >>> In the current implementation EXTENDED=3DLONGREAL. >> >> Ok, but EXTENDED is still something that is efficiently provided by >> my hardware. Not something efficiently provided by someone else's >> hardware! >> >>>> 4. I still haven't seen any really convincing use cases. What's it = >>> for? >>>> The lack of LONGINT was an obstacle to what, precisely? >>> I think the only one we have is file sizes... >>> >>>> 5. Finally, is it the intention that LONGINT be fixed at 64 bits >>>> forevermore? (See point 2.) This seems to completely fly in the face >>>> of M3's philosophy. (See Hendrik's arguments.) >>> The only constraint imposed is BITSIZE(LONGINT) >=3D BITSIZE(INTEGER). >> >> I am not so sure here. >> >> Rodney's argument has in fact convinced me that the current version of >> LONGINT is wrong and perhaps evil. It should either go away completely >> or be replaced by Hendrik's suggestion. >> >> Here's why. The argument is that if I have an N-bit machine, for N> out there in the world there is an M-bit machine that for some reason >> matters a great deal to me. For some reason I need to be able to write >> code that manipulates M-bit integers---because of the existence of this >> M-bit machine (or machines)! > > It has never been motivated by the existence of machines with various native > arithmetic sizes. It is about problems that need big value ranges to work. > > Its also about making it convenient to write portable code that solves > them. (Well, that part does have to do with the machines that exist.) > And making the type checking, etc. not change on the different machines. > And using the most efficient arithmetic consistent with correct answers. > > Normally we're dealing with the situation >> that N=32 and M=64.) So we introduce an M-bit LONGINT. Now it stands to >> reason that if the M-bit machine (which I do not own and upon which my >> program does not run) is important to me, it is also important to other >> Modula-3 programmers. Hence all other implementations of Modula-3 will >> *also* provide M-bit integers. >> >> The M-bit machine of the previous paragraph is of course, in the real >> world, a machine with the 64-bit version of the Intel x86 instruction set, >> "amd64". How long is it from here to the point where we have programmers >> who write code that depends on the fact that M=64, always? > > LONGINT presents the same opportunity/invitation/temptation to > write code that make such assumptions as does INTEGER, or for that matter, > REFANY, or gobs of other things in the original language. So LONGINT is > just as evil as INTEGER. Which is why I'd allow only subranges of LONGINT to be mentioned in programs. -- hendrik > >> >> Mika >> >> From hosking at cs.purdue.edu Thu Apr 22 17:57:16 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 22 Apr 2010 11:57:16 -0400 Subject: [M3devel] INTEGER In-Reply-To: <20100421185631.GA17051@topoi.pooq.com> References: <4F3EE437-0298-410B-9642-C0381E333430@cs.purdue.edu> <20100419223152.3D7331A2122@async.async.caltech.edu> <4BCDC866.6050804@lcwb.coop> <20100420171235!.B8F0C1A2103@async.async.caltech.edu> <20100420180715.52C391A2103@async.async.caltech.edu> <4BCF11E1.5090609@lcwb.coop> <20100421185631.GA17051@topoi.pooq.com> Message-ID: <80775CA2-A2FD-40AF-B235-7DB84127762E@cs.purdue.edu> But this is bizarre. What type does an element of a subrange of LONGINT have if not LONGINT? If the subrange has a base type of INTEGER then we need a mapping between the elements of the subrange and the base INTEGER values. But then, values of the LONGINT subrange don't have the same representation as their INTEGER counterpart. All very odd. On 21 Apr 2010, at 14:56, hendrik at topoi.pooq.com wrote: > On Wed, Apr 21, 2010 at 09:55:29AM -0500, Rodney M. Bates wrote: >> >> >> Mika Nystrom wrote: >>> Tony Hosking writes: >>>> On 20 Apr 2010, at 13:12, Mika Nystrom wrote: >>> ... >>>>> easy access to the hardware in their own machines, not really so that = >>>> IBM >>>>> programmers could have an extra format for VAX compatibility. Note = >>>> that >>>>> I don't believe that it was intended that EXTENDED would be emulated = >>>> by >>>>> the compiler either: the point was really to give programmers access = >>>> to >>>>> the formats provided efficiently by their hardware. >>>> In the current implementation EXTENDED=3DLONGREAL. >>> >>> Ok, but EXTENDED is still something that is efficiently provided by >>> my hardware. Not something efficiently provided by someone else's >>> hardware! >>> >>>>> 4. I still haven't seen any really convincing use cases. What's it = >>>> for? >>>>> The lack of LONGINT was an obstacle to what, precisely? >>>> I think the only one we have is file sizes... >>>> >>>>> 5. Finally, is it the intention that LONGINT be fixed at 64 bits >>>>> forevermore? (See point 2.) This seems to completely fly in the face >>>>> of M3's philosophy. (See Hendrik's arguments.) >>>> The only constraint imposed is BITSIZE(LONGINT) >=3D BITSIZE(INTEGER). >>> >>> I am not so sure here. >>> >>> Rodney's argument has in fact convinced me that the current version of >>> LONGINT is wrong and perhaps evil. It should either go away completely >>> or be replaced by Hendrik's suggestion. >>> >>> Here's why. The argument is that if I have an N-bit machine, for N>> out there in the world there is an M-bit machine that for some reason >>> matters a great deal to me. For some reason I need to be able to write >>> code that manipulates M-bit integers---because of the existence of this >>> M-bit machine (or machines)! >> >> It has never been motivated by the existence of machines with various native >> arithmetic sizes. It is about problems that need big value ranges to work. >> >> Its also about making it convenient to write portable code that solves >> them. (Well, that part does have to do with the machines that exist.) >> And making the type checking, etc. not change on the different machines. >> And using the most efficient arithmetic consistent with correct answers. >> >> Normally we're dealing with the situation >>> that N=32 and M=64.) So we introduce an M-bit LONGINT. Now it stands to >>> reason that if the M-bit machine (which I do not own and upon which my >>> program does not run) is important to me, it is also important to other >>> Modula-3 programmers. Hence all other implementations of Modula-3 will >>> *also* provide M-bit integers. >>> >>> The M-bit machine of the previous paragraph is of course, in the real >>> world, a machine with the 64-bit version of the Intel x86 instruction set, >>> "amd64". How long is it from here to the point where we have programmers >>> who write code that depends on the fact that M=64, always? >> >> LONGINT presents the same opportunity/invitation/temptation to >> write code that make such assumptions as does INTEGER, or for that matter, >> REFANY, or gobs of other things in the original language. So LONGINT is >> just as evil as INTEGER. > > Which is why I'd allow only subranges of LONGINT to be mentioned in > programs. > > -- hendrik > >> >>> >>> Mika >>> >>> From hendrik at topoi.pooq.com Thu Apr 22 14:38:06 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 22 Apr 2010 08:38:06 -0400 Subject: [M3devel] INTEGER In-Reply-To: <80775CA2-A2FD-40AF-B235-7DB84127762E@cs.purdue.edu> References: <4F3EE437-0298-410B-9642-C0381E333430@cs.purdue.edu> <20100419223152.3D7331A2122@async.async.caltech.edu> <4BCDC866.6050804@lcwb.coop> <20100420171235!.B8F0C1A2103@async.async.caltech.edu> <20100420180715.52C391A2103@async.async.caltech.edu> <4BCF11E1.5090609@lcwb.coop> <20100421185631.GA17051@topoi.pooq.com> <80775CA2-A2FD-40AF-B235-7DB84127762E@cs.purdue.edu> Message-ID: <20100422123805.GA19259@topoi.pooq.com> On Thu, Apr 22, 2010 at 11:57:16AM -0400, Tony Hosking wrote: > But this is bizarre. What type does an element of a subrange of > LONGINT have if not LONGINT? It has LONGINT as a type. > If the subrange has a base type of INTEGER then we need a mapping > between the elements of the subrange and the base INTEGER values. Yes. And INTEGER is different from the notion mathematicians have of integers in that there is a limit on the size of integers. It's a machine or implementation-dependent limit, and it's imposed for efficiency reasons, but it's a specific limit just the same. This limit is precisely what we're up against. > But then, values of the LONGINT subrange don't have the same > representation as their INTEGER counterpart. Of course not. If they did have the same representation, there would be in-range for INTEGERs, and there would be no need to have LONGINT at all. LONGINT is there precisely for the integers that *don't* fit in INTEGER. > > All very odd. But dictated by the intended use -- that of having integral ranges whose bounds are dictated by the problem, not the hardware. -- hendrik From hosking at cs.purdue.edu Thu Apr 22 20:36:17 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 22 Apr 2010 14:36:17 -0400 Subject: [M3devel] INTEGER In-Reply-To: <20100422123805.GA19259@topoi.pooq.com> References: <4F3EE437-0298-410B-9642-C0381E333430@cs.purdue.edu> <20100419223152.3D7331A2122@async.async.caltech.edu> <4BCDC866.6050804@lcwb.coop> <20100420171235!.B8F0C1A2103@async.async.caltech.edu> <20100420180715.52C391A2103@async.async.caltech.edu> <4BCF11E1.5090609@lcwb.coop> <20100421185631.GA17051@topoi.pooq.com> <80775CA2-A2FD-40AF-B235-7DB84127762E@cs.purdue.edu> <20100422123805.GA19259@topoi.pooq.com> Message-ID: <87B45DCC-2B8A-4C69-97D7-240BC1E2252D@cs.purdue.edu> Let me see. The green book definition says the base type of a subrange of INTEGER literals is INTEGER. You say that the base type of a subrange of LONGINT literals is LONGINT. But you say that LONGINT is not a defined type. So, what is the type of a LONGINT literal? ... [I think I misunderstood you previously. I had interpreted that you meant LONGINT subranges to have base type INTEGER.] On 22 Apr 2010, at 08:38, hendrik at topoi.pooq.com wrote: > On Thu, Apr 22, 2010 at 11:57:16AM -0400, Tony Hosking wrote: >> But this is bizarre. What type does an element of a subrange of >> LONGINT have if not LONGINT? > > It has LONGINT as a type. > >> If the subrange has a base type of INTEGER then we need a mapping >> between the elements of the subrange and the base INTEGER values. > > Yes. And INTEGER is different from the notion mathematicians have of > integers in that there is a limit on the size of integers. It's a > machine or implementation-dependent limit, and it's imposed for > efficiency reasons, but it's a specific limit just the same. > This limit is precisely what we're up against. > >> But then, values of the LONGINT subrange don't have the same >> representation as their INTEGER counterpart. > > Of course not. If they did have the same representation, there would be > in-range for INTEGERs, and there would be no need to have LONGINT at > all. > > LONGINT is there precisely for the integers that *don't* fit in INTEGER. > >> >> All very odd. > > But dictated by the intended use -- that of having integral ranges > whose bounds are dictated by the problem, not the hardware. > > -- hendrik From hendrik at topoi.pooq.com Thu Apr 22 16:55:23 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 22 Apr 2010 10:55:23 -0400 Subject: [M3devel] INTEGER In-Reply-To: <87B45DCC-2B8A-4C69-97D7-240BC1E2252D@cs.purdue.edu> References: <20100419223152.3D7331A2122@async.async.caltech.edu> <4BCDC866.6050804@lcwb.coop> <20100420171235!.B8F0C1A2103@async.async.caltech.edu> <20100420180715.52C391A2103@async.async.caltech.edu> <4BCF11E1.5090609@lcwb.coop> <20100421185631.GA17051@topoi.pooq.com> <80775CA2-A2FD-40AF-B235-7DB84127762E@cs.purdue.edu> <20100422123805.GA19259@topoi.pooq.com> <87B45DCC-2B8A-4C69-97D7-240BC1E2252D@cs.purdue.edu> Message-ID: <20100422145522.GA19946@topoi.pooq.com> On Thu, Apr 22, 2010 at 02:36:17PM -0400, Tony Hosking wrote: > Let me see. > > The green book definition says the base type of a subrange of INTEGER literals is INTEGER. > You say that the base type of a subrange of LONGINT literals is LONGINT. > But you say that LONGINT is not a defined type. So, what is the type > of a LONGINT literal? (a) 3849587394875493920398438483929293484L could very well be of type 3849587394875493920398438483929293484L..3849587394875493920398438483929293484L which is a one-element subtype of LONGINT. LONGINY is a type. It's just one that's not available directly to the programmer. It would not need to have a defined size, if the language allowed LONGINT values to occur *only* where an upper bound on their size is known, such as by being elements of a subrange. -- hendrik > > [I think I misunderstood you previously. I had interpreted that you meant LONGINT subranges to have base type INTEGER.] > > On 22 Apr 2010, at 08:38, hendrik at topoi.pooq.com wrote: > > > On Thu, Apr 22, 2010 at 11:57:16AM -0400, Tony Hosking wrote: > >> But this is bizarre. What type does an element of a subrange of > >> LONGINT have if not LONGINT? > > > > It has LONGINT as a type. > > > >> If the subrange has a base type of INTEGER then we need a mapping > >> between the elements of the subrange and the base INTEGER values. > > > > Yes. And INTEGER is different from the notion mathematicians have of > > integers in that there is a limit on the size of integers. It's a > > machine or implementation-dependent limit, and it's imposed for > > efficiency reasons, but it's a specific limit just the same. > > This limit is precisely what we're up against. > > > >> But then, values of the LONGINT subrange don't have the same > >> representation as their INTEGER counterpart. > > > > Of course not. If they did have the same representation, there would be > > in-range for INTEGERs, and there would be no need to have LONGINT at > > all. > > > > LONGINT is there precisely for the integers that *don't* fit in INTEGER. > > > >> > >> All very odd. > > > > But dictated by the intended use -- that of having integral ranges > > whose bounds are dictated by the problem, not the hardware. > > > > -- hendrik > From hosking at cs.purdue.edu Thu Apr 22 21:27:50 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 22 Apr 2010 15:27:50 -0400 Subject: [M3devel] INTEGER In-Reply-To: <20100422145522.GA19946@topoi.pooq.com> References: <20100419223152.3D7331A2122@async.async.caltech.edu> <4BCDC866.6050804@lcwb.coop> <20100420171235!.B8F0C1A2103@async.async.caltech.edu> <20100420180715.52C391A2103@async.async.caltech.edu> <4BCF11E1.5090609@lcwb.coop> <20100421185631.GA17051@topoi.pooq.com> <80775CA2-A2FD-40AF-B235-7DB84127762E@cs.purdue.edu> <20100422123805.GA19259@topoi.pooq.com> <87B45DCC-2B8A-4C69-97D7-240BC1E2252D@cs.purdue.edu> <20100422145522.GA19946@topoi.pooq.com> Message-ID: <28339030-6005-4C28-872C-A68CF24BF4DF@cs.purdue.edu> This is bizarre, and perverts the language definition significantly more than the current scheme. What is the base type of that subrange? On 22 Apr 2010, at 10:55, hendrik at topoi.pooq.com wrote: > On Thu, Apr 22, 2010 at 02:36:17PM -0400, Tony Hosking wrote: >> Let me see. >> >> The green book definition says the base type of a subrange of INTEGER literals is INTEGER. >> You say that the base type of a subrange of LONGINT literals is LONGINT. >> But you say that LONGINT is not a defined type. So, what is the type >> of a LONGINT literal? > > (a) 3849587394875493920398438483929293484L could very well be of type > 3849587394875493920398438483929293484L..3849587394875493920398438483929293484L > which is a one-element subtype of LONGINT. > > LONGINY is a type. It's just one that's not available directly to the > programmer. It would not need to have a defined size, if the language > allowed LONGINT values to occur *only* where an upper bound on > their size is known, such as by being elements of a subrange. > > -- hendrik > >> >> [I think I misunderstood you previously. I had interpreted that you meant LONGINT subranges to have base type INTEGER.] >> >> On 22 Apr 2010, at 08:38, hendrik at topoi.pooq.com wrote: >> >>> On Thu, Apr 22, 2010 at 11:57:16AM -0400, Tony Hosking wrote: >>>> But this is bizarre. What type does an element of a subrange of >>>> LONGINT have if not LONGINT? >>> >>> It has LONGINT as a type. >>> >>>> If the subrange has a base type of INTEGER then we need a mapping >>>> between the elements of the subrange and the base INTEGER values. >>> >>> Yes. And INTEGER is different from the notion mathematicians have of >>> integers in that there is a limit on the size of integers. It's a >>> machine or implementation-dependent limit, and it's imposed for >>> efficiency reasons, but it's a specific limit just the same. >>> This limit is precisely what we're up against. >>> >>>> But then, values of the LONGINT subrange don't have the same >>>> representation as their INTEGER counterpart. >>> >>> Of course not. If they did have the same representation, there would be >>> in-range for INTEGERs, and there would be no need to have LONGINT at >>> all. >>> >>> LONGINT is there precisely for the integers that *don't* fit in INTEGER. >>> >>>> >>>> All very odd. >>> >>> But dictated by the intended use -- that of having integral ranges >>> whose bounds are dictated by the problem, not the hardware. >>> >>> -- hendrik >> From hendrik at topoi.pooq.com Thu Apr 22 17:43:57 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 22 Apr 2010 11:43:57 -0400 Subject: [M3devel] INTEGER In-Reply-To: <28339030-6005-4C28-872C-A68CF24BF4DF@cs.purdue.edu> References: <20100420171235!.B8F0C1A2103@async.async.caltech.edu> <20100420180715.52C391A2103@async.async.caltech.edu> <4BCF11E1.5090609@lcwb.coop> <20100421185631.GA17051@topoi.pooq.com> <80775CA2-A2FD-40AF-B235-7DB84127762E@cs.purdue.edu> <20100422123805.GA19259@topoi.pooq.com> <87B45DCC-2B8A-4C69-97D7-240BC1E2252D@cs.purdue.edu> <20100422145522.GA19946@topoi.pooq.com> <28339030-6005-4C28-872C-A68CF24BF4DF@cs.purdue.edu> Message-ID: <20100422154357.GA20043@topoi.pooq.com> On Thu, Apr 22, 2010 at 03:27:50PM -0400, Tony Hosking wrote: > This is bizarre, and perverts the language definition significantly more than the current scheme. > What is the base type of that subrange? LONGINT. -- hendrik > > On 22 Apr 2010, at 10:55, hendrik at topoi.pooq.com wrote: > > > On Thu, Apr 22, 2010 at 02:36:17PM -0400, Tony Hosking wrote: > >> Let me see. > >> > >> The green book definition says the base type of a subrange of INTEGER literals is INTEGER. > >> You say that the base type of a subrange of LONGINT literals is LONGINT. > >> But you say that LONGINT is not a defined type. So, what is the type > >> of a LONGINT literal? > > > > (a) 3849587394875493920398438483929293484L could very well be of type > > 3849587394875493920398438483929293484L..3849587394875493920398438483929293484L > > which is a one-element subtype of LONGINT. > > > > LONGINY is a type. It's just one that's not available directly to the > > programmer. It would not need to have a defined size, if the language > > allowed LONGINT values to occur *only* where an upper bound on > > their size is known, such as by being elements of a subrange. > > > > -- hendrik > > > >> > >> [I think I misunderstood you previously. I had interpreted that you meant LONGINT subranges to have base type INTEGER.] > >> > >> On 22 Apr 2010, at 08:38, hendrik at topoi.pooq.com wrote: > >> > >>> On Thu, Apr 22, 2010 at 11:57:16AM -0400, Tony Hosking wrote: > >>>> But this is bizarre. What type does an element of a subrange of > >>>> LONGINT have if not LONGINT? > >>> > >>> It has LONGINT as a type. > >>> > >>>> If the subrange has a base type of INTEGER then we need a mapping > >>>> between the elements of the subrange and the base INTEGER values. > >>> > >>> Yes. And INTEGER is different from the notion mathematicians have of > >>> integers in that there is a limit on the size of integers. It's a > >>> machine or implementation-dependent limit, and it's imposed for > >>> efficiency reasons, but it's a specific limit just the same. > >>> This limit is precisely what we're up against. > >>> > >>>> But then, values of the LONGINT subrange don't have the same > >>>> representation as their INTEGER counterpart. > >>> > >>> Of course not. If they did have the same representation, there would be > >>> in-range for INTEGERs, and there would be no need to have LONGINT at > >>> all. > >>> > >>> LONGINT is there precisely for the integers that *don't* fit in INTEGER. > >>> > >>>> > >>>> All very odd. > >>> > >>> But dictated by the intended use -- that of having integral ranges > >>> whose bounds are dictated by the problem, not the hardware. > >>> > >>> -- hendrik > >> > From hosking at cs.purdue.edu Thu Apr 22 21:44:03 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 22 Apr 2010 15:44:03 -0400 Subject: [M3devel] INTEGER In-Reply-To: <20100422154357.GA20043@topoi.pooq.com> References: <20100420171235!.B8F0C1A2103@async.async.caltech.edu> <20100420180715.52C391A2103@async.async.caltech.edu> <4BCF11E1.5090609@lcwb.coop> <20100421185631.GA17051@topoi.pooq.com> <80775CA2-A2FD-40AF-B235-7DB84127762E@cs.purdue.edu> <20100422123805.GA19259@topoi.pooq.com> <87B45DCC-2B8A-4C69-97D7-240BC1E2252D@cs.purdue.edu> <20100422145522.GA19946@topoi.pooq.com> <28339030-6005-4C28-872C-A68CF24BF4DF@cs.purdue.edu> <20100422154357.GA20043@topoi.pooq.com> Message-ID: <270A99B5-173E-413B-8C28-E1CA68870FD4@cs.purdue.edu> Defined as... On 22 Apr 2010, at 11:43, hendrik at topoi.pooq.com wrote: > On Thu, Apr 22, 2010 at 03:27:50PM -0400, Tony Hosking wrote: >> This is bizarre, and perverts the language definition significantly more than the current scheme. >> What is the base type of that subrange? > > LONGINT. > > -- hendrik > >> >> On 22 Apr 2010, at 10:55, hendrik at topoi.pooq.com wrote: >> >>> On Thu, Apr 22, 2010 at 02:36:17PM -0400, Tony Hosking wrote: >>>> Let me see. >>>> >>>> The green book definition says the base type of a subrange of INTEGER literals is INTEGER. >>>> You say that the base type of a subrange of LONGINT literals is LONGINT. >>>> But you say that LONGINT is not a defined type. So, what is the type >>>> of a LONGINT literal? >>> >>> (a) 3849587394875493920398438483929293484L could very well be of type >>> 3849587394875493920398438483929293484L..3849587394875493920398438483929293484L >>> which is a one-element subtype of LONGINT. >>> >>> LONGINY is a type. It's just one that's not available directly to the >>> programmer. It would not need to have a defined size, if the language >>> allowed LONGINT values to occur *only* where an upper bound on >>> their size is known, such as by being elements of a subrange. >>> >>> -- hendrik >>> >>>> >>>> [I think I misunderstood you previously. I had interpreted that you meant LONGINT subranges to have base type INTEGER.] >>>> >>>> On 22 Apr 2010, at 08:38, hendrik at topoi.pooq.com wrote: >>>> >>>>> On Thu, Apr 22, 2010 at 11:57:16AM -0400, Tony Hosking wrote: >>>>>> But this is bizarre. What type does an element of a subrange of >>>>>> LONGINT have if not LONGINT? >>>>> >>>>> It has LONGINT as a type. >>>>> >>>>>> If the subrange has a base type of INTEGER then we need a mapping >>>>>> between the elements of the subrange and the base INTEGER values. >>>>> >>>>> Yes. And INTEGER is different from the notion mathematicians have of >>>>> integers in that there is a limit on the size of integers. It's a >>>>> machine or implementation-dependent limit, and it's imposed for >>>>> efficiency reasons, but it's a specific limit just the same. >>>>> This limit is precisely what we're up against. >>>>> >>>>>> But then, values of the LONGINT subrange don't have the same >>>>>> representation as their INTEGER counterpart. >>>>> >>>>> Of course not. If they did have the same representation, there would be >>>>> in-range for INTEGERs, and there would be no need to have LONGINT at >>>>> all. >>>>> >>>>> LONGINT is there precisely for the integers that *don't* fit in INTEGER. >>>>> >>>>>> >>>>>> All very odd. >>>>> >>>>> But dictated by the intended use -- that of having integral ranges >>>>> whose bounds are dictated by the problem, not the hardware. >>>>> >>>>> -- hendrik >>>> >> From jay.krell at cornell.edu Thu Apr 22 21:38:03 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 22 Apr 2010 19:38:03 +0000 Subject: [M3devel] INTEGER In-Reply-To: <20100422145522.GA19946@topoi.pooq.com> References: <20100419223152.3D7331A2122@async.async.caltech.edu>, <4BCDC866.6050804@lcwb.coop>, <20100420171235!.B8F0C1A2103@async.async.caltech.edu>, , <20100420180715.52C391A2103@async.async.caltech.edu>, <4BCF11E1.5090609@lcwb.coop>, <20100421185631.GA17051@topoi.pooq.com>, <80775CA2-A2FD-40AF-B235-7DB84127762E@cs.purdue.edu>, <20100422123805.GA19259@topoi.pooq.com>, <87B45DCC-2B8A-4C69-97D7-240BC1E2252D@cs.purdue.edu>, <20100422145522.GA19946@topoi.pooq.com> Message-ID: I have to add something. There is another use of LONGINT. Kind of an annoying practical one, and a minor side affect. Not really a nice abstract one. And in fact, it implies a sort of use of "INT128". To declare opaque data with a particular alignment. To match an external definition. Specifically, jmpbuf. Many systems want a 64bit aligned jmpbuf. Even some 32bit ones. e.g. ALPHA32_VMS. But it isn't the only one. There are systems that prefer as high as 128 bit aligned jmpbuf, but I think are ok with less aligned (PPC_LINUX), or not (PA64_HPUX?). I'm not able to declare these today. And C doesn't do this necessarily with larger types, but with other syntax. I think 32bit Linux/ppc says something like: typedef struct __attribute___(align(128)) { /* 32 is ok, but 128 is ideal */ ... } jmpbuf; Ok, details: Oh. Maybe I should use "double" for this purpose? I did sometimes. I forgot. That solves part of the problem, as much as LONGINT solves. http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/C/PA32_HPUX/Csetjmp.i3?rev=1.3;content-type=text%2Fplain (* 200 bytes with 8 byte alignment *) TYPE jmp_buf = ARRAY [0..24] OF double; http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/C/PPC_LINUX/Csetjmp.i3?rev=1.10;content-type=text%2Fplain (* ideal alignment is 16 bytes but 4 is ok; 8 here *) TYPE jmp_buf = ARRAY [0..73] OF LONGINT; http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/C/PA64_HPUX/Csetjmp.i3?rev=1.3;content-type=text%2Fplain (* 640 bytes with 16 byte alignment if we can get it, else 8 byte alignment, which is the best we can ask for (front end internally uses 16 byte alignment) *) TYPE jmp_buf = ARRAY [0..79] OF double; I should use double? Or we should have another way to say this? Or, for that matter, as I've suggested, we shouldn't duplicate the information both in Csetjmp.i3 and Target.m3? Target.m3 has available to it arbitrary alignment. Ok, PPC_LINUX and PA32/64_HPUX were the only ones I could find that want >4 alignment on 32bit, or >8 on 64bit. And 8 on 32 you can get with double. I had forgotten about that technique. I think this is at least another good argument for removing the type declaration from Csetjmp.i3, maybe the function too, and putting it only in Target.m3 (Target.m3 currently only declares setjmp, not longjmp). If not a way to declare alignment in the language. The thing is, you know, the only need for this is to match external/C definitions, and those definitions are now tremendously more under our control than they used to be, so the need to describe "anything" is reduced. Tony is that at all difficult? Injecting the jmpbuf and longjmp information from Target.m3 instead of in Csetjmp.i3? I'll try to get to it. I'd like to further reduce the volume and "wide distribution" of target-specific data. There's still a lot of duplication and non-centralization. - Jay > Date: Thu, 22 Apr 2010 10:55:23 -0400 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] INTEGER > > On Thu, Apr 22, 2010 at 02:36:17PM -0400, Tony Hosking wrote: > > Let me see. > > > > The green book definition says the base type of a subrange of INTEGER literals is INTEGER. > > You say that the base type of a subrange of LONGINT literals is LONGINT. > > But you say that LONGINT is not a defined type. So, what is the type > > of a LONGINT literal? > > (a) 3849587394875493920398438483929293484L could very well be of type > 3849587394875493920398438483929293484L..3849587394875493920398438483929293484L > which is a one-element subtype of LONGINT. > > LONGINY is a type. It's just one that's not available directly to the > programmer. It would not need to have a defined size, if the language > allowed LONGINT values to occur *only* where an upper bound on > their size is known, such as by being elements of a subrange. > > -- hendrik > > > > > [I think I misunderstood you previously. I had interpreted that you meant LONGINT subranges to have base type INTEGER.] > > > > On 22 Apr 2010, at 08:38, hendrik at topoi.pooq.com wrote: > > > > > On Thu, Apr 22, 2010 at 11:57:16AM -0400, Tony Hosking wrote: > > >> But this is bizarre. What type does an element of a subrange of > > >> LONGINT have if not LONGINT? > > > > > > It has LONGINT as a type. > > > > > >> If the subrange has a base type of INTEGER then we need a mapping > > >> between the elements of the subrange and the base INTEGER values. > > > > > > Yes. And INTEGER is different from the notion mathematicians have of > > > integers in that there is a limit on the size of integers. It's a > > > machine or implementation-dependent limit, and it's imposed for > > > efficiency reasons, but it's a specific limit just the same. > > > This limit is precisely what we're up against. > > > > > >> But then, values of the LONGINT subrange don't have the same > > >> representation as their INTEGER counterpart. > > > > > > Of course not. If they did have the same representation, there would be > > > in-range for INTEGERs, and there would be no need to have LONGINT at > > > all. > > > > > > LONGINT is there precisely for the integers that *don't* fit in INTEGER. > > > > > >> > > >> All very odd. > > > > > > But dictated by the intended use -- that of having integral ranges > > > whose bounds are dictated by the problem, not the hardware. > > > > > > -- hendrik > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.async.caltech.edu Fri Apr 23 07:04:24 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Thu, 22 Apr 2010 22:04:24 -0700 Subject: [M3devel] INTEGER In-Reply-To: <4BCF11E1.5090609@lcwb.coop> References: , , , , , , <20100418023535.3BA9E1A2103@async.async.caltech.edu>, , , , <20100418024703.6965B1A2103@async.async.caltech.edu>, , <20100418074927.934461A2117@async.async.caltech.edu>, <04EB7FF8-D304-428D-839E-233FCE009C98@cs.purdue.edu>, <20100418195901.CDACB1A20F6@async.async.caltech.edu>, , <20100419172313.68B241A20D6@async.async.caltech.edu>, <4F3EE437-0298-410B-9642-C0381E333430@cs.purdue.edu> <20100419223152.3D7331A2122@async.async.caltech.edu> <4BCDC866.6050804@lcwb.coop> <20100420171235! .B8F0C1A2103@async.async.caltech.edu> <20100420180715.52C391A2103@async.async.caltech.edu> <4BCF11E1.5090609@lcwb.coop> Message-ID: <20100423050424.77EBE1A2106@async.async.caltech.edu> "Rodney M. Bates" writes: ... >It has never been motivated by the existence of machines with various native >arithmetic sizes. It is about problems that need big value ranges to work. > >Its also about making it convenient to write portable code that solves >them. (Well, that part does have to do with the machines that exist.) >And making the type checking, etc. not change on the different machines. >And using the most efficient arithmetic consistent with correct answers. > >Normally we're dealing with the situation >> that N=32 and M=64.) So we introduce an M-bit LONGINT. Now it stands to >> reason that if the M-bit machine (which I do not own and upon which my >> program does not run) is important to me, it is also important to other >> Modula-3 programmers. Hence all other implementations of Modula-3 will >> *also* provide M-bit integers. >> >> The M-bit machine of the previous paragraph is of course, in the real >> world, a machine with the 64-bit version of the Intel x86 instruction set, >> "amd64". How long is it from here to the point where we have programmers >> who write code that depends on the fact that M=64, always? > >LONGINT presents the same opportunity/invitation/temptation to >write code that make such assumptions as does INTEGER, or for that matter, >REFANY, or gobs of other things in the original language. So LONGINT is >just as evil as INTEGER. It is precisely my point that LONGINT is equally evil as INTEGER. The language doesn't need two "evil" integer types. If there is to be another one (an inefficient one, to boot!) I think it had better offer something that INTEGER does not (such as Hendrik's suggestion). In fact since I have now seen it suggested that LONGINT be at least 64 bits wide, (correct) LONGINT-based code will be *less* portable than (correct) INTEGER code, which is allowed to make no such assumptions and hence has to work whether INTEGER is 16, 32, 36, or even 666 bits wide. Mika From mika at async.async.caltech.edu Fri Apr 23 07:29:35 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Thu, 22 Apr 2010 22:29:35 -0700 Subject: [M3devel] INTEGER In-Reply-To: <80775CA2-A2FD-40AF-B235-7DB84127762E@cs.purdue.edu> References: <4F3EE437-0298-410B-9642-C0381E333430@cs.purdue.edu> <20100419223152.3D7331A2122@async.async.caltech.edu> <4BCDC866.6050804@lcwb.coop> <20100420171235!.B8F0C1A2103@async.async.caltech.edu> <20100420180715.52C391A2103@async.async.caltech.edu> <4BCF11E1.5090609@lcwb.coop> <20100421185631.GA17051@topoi.pooq.com> <80775CA2-A2FD-40AF-B235-7DB84127762E@cs.purdue.edu> Message-ID: <20100423052935.07F7C1A20F1@async.async.caltech.edu> My "proposal" would be TEXT-like bignums. Subranges would have to be based on LONGINT constants. Decree that they are instances of a particular GENERIC INTERFACE maybe. Hrmmm... TYPE Range = [ 1L .. 1000L*1000L*1000L*1000L ]; equivalent to REVEAL LONGINT <: ROOT; TYPE LongInt.T = LONGINT; GENERIC INTERFACE LongIntRange(R); TYPE T = LONGINT BRANDED LongInt.ToText(R.Low) & "_" & LongInt.ToText(R.High) OBJECT END; END LongIntRange. INTERFACE RR; CONST Low = 1L; High = 1000L*1000L*1000L*1000L; END RR. INTERFACE RRType = LongIntRange(RR) END RRType. TYPE Range = RRType.T; or somesuch... hrmph too complicated? It looks a lot like TEXT still. I just introduced a new function that the compiler needs to know: LongInt.ToText. And a fake interface. Ho hum, yes complicated. But it looks like a pretty normal Modula-3 type after these gyrations... Mika Tony Hosking writes: >But this is bizarre. What type does an element of a subrange of LONGINT = >have if not LONGINT? If the subrange has a base type of INTEGER then we = >need a mapping between the elements of the subrange and the base INTEGER = >values. But then, values of the LONGINT subrange don't have the same = >representation as their INTEGER counterpart. > >All very odd. > >On 21 Apr 2010, at 14:56, hendrik at topoi.pooq.com wrote: > >> On Wed, Apr 21, 2010 at 09:55:29AM -0500, Rodney M. Bates wrote: >>>=20 >>>=20 >>> Mika Nystrom wrote: >>>> Tony Hosking writes: >>>>> On 20 Apr 2010, at 13:12, Mika Nystrom wrote: >>>> ... >>>>>> easy access to the hardware in their own machines, not really so = >that =3D >>>>> IBM >>>>>> programmers could have an extra format for VAX compatibility. = >Note =3D >>>>> that >>>>>> I don't believe that it was intended that EXTENDED would be = >emulated =3D >>>>> by >>>>>> the compiler either: the point was really to give programmers = >access =3D >>>>> to >>>>>> the formats provided efficiently by their hardware. >>>>> In the current implementation EXTENDED=3D3DLONGREAL. >>>>=20 >>>> Ok, but EXTENDED is still something that is efficiently provided by >>>> my hardware. Not something efficiently provided by someone else's >>>> hardware! >>>>=20 >>>>>> 4. I still haven't seen any really convincing use cases. What's = >it =3D >>>>> for? >>>>>> The lack of LONGINT was an obstacle to what, precisely? >>>>> I think the only one we have is file sizes... >>>>>=20 >>>>>> 5. Finally, is it the intention that LONGINT be fixed at 64 bits >>>>>> forevermore? (See point 2.) This seems to completely fly in the = >face >>>>>> of M3's philosophy. (See Hendrik's arguments.) >>>>> The only constraint imposed is BITSIZE(LONGINT) >=3D3D = >BITSIZE(INTEGER). >>>>=20 >>>> I am not so sure here. >>>>=20 >>>> Rodney's argument has in fact convinced me that the current version = >of >>>> LONGINT is wrong and perhaps evil. It should either go away = >completely >>>> or be replaced by Hendrik's suggestion. >>>>=20 >>>> Here's why. The argument is that if I have an N-bit machine, for = >N>>> out there in the world there is an M-bit machine that for some = >reason >>>> matters a great deal to me. For some reason I need to be able to = >write >>>> code that manipulates M-bit integers---because of the existence of = >this >>>> M-bit machine (or machines)! =20 >>>=20 >>> It has never been motivated by the existence of machines with various = >native >>> arithmetic sizes. It is about problems that need big value ranges to = >work. >>>=20 >>> Its also about making it convenient to write portable code that = >solves >>> them. (Well, that part does have to do with the machines that exist.) >>> And making the type checking, etc. not change on the different = >machines. >>> And using the most efficient arithmetic consistent with correct = >answers. >>>=20 >>> Normally we're dealing with the situation >>>> that N=3D32 and M=3D64.) So we introduce an M-bit LONGINT. Now it = >stands to >>>> reason that if the M-bit machine (which I do not own and upon which = >my >>>> program does not run) is important to me, it is also important to = >other >>>> Modula-3 programmers. Hence all other implementations of Modula-3 = >will >>>> *also* provide M-bit integers. =20 >>>>=20 >>>> The M-bit machine of the previous paragraph is of course, in the = >real >>>> world, a machine with the 64-bit version of the Intel x86 = >instruction set, >>>> "amd64". How long is it from here to the point where we have = >programmers >>>> who write code that depends on the fact that M=3D64, always? >>>=20 >>> LONGINT presents the same opportunity/invitation/temptation to >>> write code that make such assumptions as does INTEGER, or for that = >matter, >>> REFANY, or gobs of other things in the original language. So LONGINT = >is >>> just as evil as INTEGER. >>=20 >> Which is why I'd allow only subranges of LONGINT to be mentioned in=20 >> programs. >>=20 >> -- hendrik >>=20 >>>=20 >>>>=20 >>>> Mika >>>>=20 >>>>=20 From mika at async.async.caltech.edu Fri Apr 23 07:38:51 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Thu, 22 Apr 2010 22:38:51 -0700 Subject: [M3devel] INTEGER In-Reply-To: References: <20100419223152.3D7331A2122@async.async.caltech.edu>, <4BCDC866.6050804@lcwb.coop>, <20100420171235!.B8F0C1A2103@async.async.caltech.edu>, , <20100420180715.52C391A2103@async.async.caltech.edu>, <4BCF11E1.5090609@lcwb.coop>, <20100421185631.GA17051@topoi.pooq.com>, <80775CA2-A2FD-40AF-B235-7DB84127762E@cs.purdue.edu>, <20100422123805.GA19259@topoi.pooq.com>, <87B45DCC-2B8A-4C69-97D7-240BC1E2252D@cs.purdue.edu>, <20100422145522.GA19946@topoi.pooq.com> Message-ID: <20100423053851.DB8DB1A20CF@async.async.caltech.edu> Jay K writes: >--_7f0c333b-7807-4538-bdd6-306666b4a0e7_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >I have to add something. There is another use of LONGINT. > >Kind of an annoying practical one=2C and a minor side affect. Not really a = >nice abstract one. > >And in fact=2C it implies a sort of use of "INT128". > >=20 > >=20 > >To declare opaque data with a particular alignment. > >=20 > >=20 > >To match an external definition. > >Specifically=2C jmpbuf. > >Many systems want a 64bit aligned jmpbuf. But does Modula-3 *allocate* jmpbufs? If not, why does the declaration have to record that C is guaranteed to allocate the jmpbufs with a certain alignment? I don't think this type of stuff belongs anywhere near the language definition. If it's really needed it ought to be in compiler pragmas. (I think.) Mika From wagner at elegosoft.com Fri Apr 23 09:52:08 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 23 Apr 2010 09:52:08 +0200 Subject: [M3devel] type in m3tests/src/m3makefile Message-ID: <20100423095208.ut3mklu58gkg00kw@mail.elegosoft.com> It seems I've just committed a syntax error to the m3tests makefile this morning: "/ad0e/home/hudson/workspace/cm3-test-m3tests-AMD64_FREEBSD/cm3/m3-sys/m3tests/AMD64_FREEBSD/m3make.args", line 5: quake runtime error: /ad0e/home/hudson/workspace/cm3-test-m3tests-AMD64_FREEBSD/cm3/m3-sys/m3tests/src/m3makefile, line 331: syntax error: missing: ] (found: ) This is on the release branch. I can only fix it tonight. If anybody is faster, that would be welcome. 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 hendrik at topoi.pooq.com Fri Apr 23 11:49:03 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 23 Apr 2010 05:49:03 -0400 Subject: [M3devel] INTEGER In-Reply-To: <270A99B5-173E-413B-8C28-E1CA68870FD4@cs.purdue.edu> References: <20100420180715.52C391A2103@async.async.caltech.edu> <4BCF11E1.5090609@lcwb.coop> <20100421185631.GA17051@topoi.pooq.com> <80775CA2-A2FD-40AF-B235-7DB84127762E@cs.purdue.edu> <20100422123805.GA19259@topoi.pooq.com> <87B45DCC-2B8A-4C69-97D7-240BC1E2252D@cs.purdue.edu> <20100422145522.GA19946@topoi.pooq.com> <28339030-6005-4C28-872C-A68CF24BF4DF@cs.purdue.edu> <20100422154357.GA20043@topoi.pooq.com> <270A99B5-173E-413B-8C28-E1CA68870FD4@cs.purdue.edu> Message-ID: <20100423094903.GC21281@topoi.pooq.com> On Thu, Apr 22, 2010 at 03:44:03PM -0400, Tony Hosking wrote: > Defined as... A type whose values are integers. If it's only used as subranges, its infinite extent is not an implementation difficulty. -- hendrik > > On 22 Apr 2010, at 11:43, hendrik at topoi.pooq.com wrote: > > > On Thu, Apr 22, 2010 at 03:27:50PM -0400, Tony Hosking wrote: > >> This is bizarre, and perverts the language definition significantly more than the current scheme. > >> What is the base type of that subrange? > > > > LONGINT. > > > > -- hendrik > > k From mika at async.async.caltech.edu Fri Apr 23 20:52:14 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Fri, 23 Apr 2010 11:52:14 -0700 Subject: [M3devel] INTEGER In-Reply-To: <20100423094903.GC21281@topoi.pooq.com> References: <20100420180715.52C391A2103@async.async.caltech.edu> <4BCF11E1.5090609@lcwb.coop> <20100421185631.GA17051@topoi.pooq.com> <80775CA2-A2FD-40AF-B235-7DB84127762E@cs.purdue.edu> <20100422123805.GA19259@topoi.pooq.com> <87B45DCC-2B8A-4C69-97D7-240BC1E2252D@cs.purdue.edu> <20100422145522.GA19946@topoi.pooq.com> <28339030-6005-4C28-872C-A68CF24BF4DF@cs.purdue.edu> <20100422154357.GA20043@topoi.pooq.com> <270A99B5-173E-413B-8C28-E1CA68870FD4@cs.purdue.edu> <20100423094903.GC21281@topoi.pooq.com> Message-ID: <20100423185214.BA2EF1A20E1@async.async.caltech.edu> Is the infinite extent of the TEXT type a serious implementation difficulty? :-) Mika hendrik at topoi.pooq.com writes: >On Thu, Apr 22, 2010 at 03:44:03PM -0400, Tony Hosking wrote: >> Defined as... > >A type whose values are integers. If it's only used as subranges, >its infinite extent is not an implementation difficulty. > >-- hendrik > >> >> On 22 Apr 2010, at 11:43, hendrik at topoi.pooq.com wrote: >> >> > On Thu, Apr 22, 2010 at 03:27:50PM -0400, Tony Hosking wrote: >> >> This is bizarre, and perverts the language definition significantly more than the current scheme. >> >> What is the base type of that subrange? >> > >> > LONGINT. >> > >> > -- hendrik >> > >k From jay.krell at cornell.edu Fri Apr 23 22:29:57 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 23 Apr 2010 20:29:57 +0000 Subject: [M3devel] word vs. long vs. pointer in parse.c Message-ID: I believe where parse.c uses BITS_PER_WORD, it should use POINTER_SIZE. The docs allude that "word" is a register. On Alpha32, that is 64 bits. However on Alpha32, LONG_SIZE and POINTER_SIZE are 32. This leads to assertion failures in parse.c about the type to the set functions being t_int. I imagine Alpha32 is a little strange, but that it exists for better source compatibility with VAX and maybe even HP-UX, and to keep data stored in memory and on disk smaller where 32bits suffices. (IA64 has 32bit modes also, I forgot if in HP-UX or VMS or both. Not necessarily hardware modes, but code gen modes. I wasn't planning on an IA6432_HPUX, IA6432_VMS ports though, just IA64_HPUX and IA64_VMS) The assertion failures went away when I tried LONG_SIZE. For purposes of AMD64_MINGW though, LONG_SIZE might be wrong and POINTER_SIZE the all around answer. I still have to test this on other platforms. That leaves I think just atomics failing all over for ALPHA32_VMS. ALPHA64_VMS I can already produce all the assembly for cm3 (including atomics apparently). I haven't yet assembled/linked/run it. Doing native-hosted builds of cm3cg might not be viable. (Since I haven't assembled/linked, and didn't look at the code, could be the atomics are function calls.) Another strange thing I think I saw is that sizeof(long,size_t,ptrdiff_t) with cc /pointer_size=64 is 4, but with alpha64-dec-vms-gcc it is 8. I think we might want something like: #if __pointer_size == 64 /* whatever cc /pointer_size=64 defines */ typedef __int64 INTEGER; typedef unsigned __int64 WORD; #else typedef ptrdiff_t INTEGER; typedef size_t WORD; #endif and use INTEGER and WORD whenever C code is interoperating with Modula-3. Maybe just punt ALPHA32_VMS? These systems don't have gobs of memory by modern standards -- the one I'm using is multi-user and has 768MB -- so the smaller data size might be worthwhile over ALPHA64_VMS. ? The platform seems fairly viable so far though. - Jay From hendrik at topoi.pooq.com Fri Apr 23 18:56:13 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 23 Apr 2010 12:56:13 -0400 Subject: [M3devel] INTEGER In-Reply-To: <20100423185214.BA2EF1A20E1@async.async.caltech.edu> References: <20100421185631.GA17051@topoi.pooq.com> <80775CA2-A2FD-40AF-B235-7DB84127762E@cs.purdue.edu> <20100422123805.GA19259@topoi.pooq.com> <87B45DCC-2B8A-4C69-97D7-240BC1E2252D@cs.purdue.edu> <20100422145522.GA19946@topoi.pooq.com> <28339030-6005-4C28-872C-A68CF24BF4DF@cs.purdue.edu> <20100422154357.GA20043@topoi.pooq.com> <270A99B5-173E-413B-8C28-E1CA68870FD4@cs.purdue.edu> <20100423094903.GC21281@topoi.pooq.com> <20100423185214.BA2EF1A20E1@async.async.caltech.edu> Message-ID: <20100423165613.GA22126@topoi.pooq.com> On Fri, Apr 23, 2010 at 11:52:14AM -0700, Mika Nystrom wrote: > > Is the infinite extent of the TEXT type a serious implementation difficulty? :-) Yes, actually. It requires heap storage allocation and indirection. That's just what it costs, so we pay it, since fixed-width strings aren't all that useful. But integer ranges of a size that matches the application (instead of the hardware) are quite feasible and useful; I'd rather not pay the proce of dynamic heap allocation for each integer. -- hendrik > > Mika > > hendrik at topoi.pooq.com writes: > >On Thu, Apr 22, 2010 at 03:44:03PM -0400, Tony Hosking wrote: > >> Defined as... > > > >A type whose values are integers. If it's only used as subranges, > >its infinite extent is not an implementation difficulty. > > > >-- hendrik > > > >> > >> On 22 Apr 2010, at 11:43, hendrik at topoi.pooq.com wrote: > >> > >> > On Thu, Apr 22, 2010 at 03:27:50PM -0400, Tony Hosking wrote: > >> >> This is bizarre, and perverts the language definition significantly more than the current scheme. > >> >> What is the base type of that subrange? > >> > > >> > LONGINT. > >> > > >> > -- hendrik > >> > > >k From mika at async.async.caltech.edu Sat Apr 24 12:34:35 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Sat, 24 Apr 2010 03:34:35 -0700 Subject: [M3devel] INTEGER In-Reply-To: <20100423165613.GA22126@topoi.pooq.com> References: <20100421185631.GA17051@topoi.pooq.com> <80775CA2-A2FD-40AF-B235-7DB84127762E@cs.purdue.edu> <20100422123805.GA19259@topoi.pooq.com> <87B45DCC-2B8A-4C69-97D7-240BC1E2252D@cs.purdue.edu> <20100422145522.GA19946@topoi.pooq.com> <28339030-6005-4C28-872C-A68CF24BF4DF@cs.purdue.edu> <20100422154357.GA20043@topoi.pooq.com> <270A99B5-173E-413B-8C28-E1CA68870FD4@cs.purdue.edu> <20100423094903.GC21281@topoi.pooq.com> <20100423185214.BA2EF1A20E1@async.async.caltech.edu> <20100423165613.GA22126@topoi.pooq.com> Message-ID: <20100424103435.A1CC41A20C2@async.async.caltech.edu> hendrik at topoi.pooq.com writes: >On Fri, Apr 23, 2010 at 11:52:14AM -0700, Mika Nystrom wrote: >> >> Is the infinite extent of the TEXT type a serious implementation difficulty? :-) > >Yes, actually. It requires heap storage allocation and indirection. That's just what >it costs, so we pay it, since fixed-width strings aren't all that useful. > >But integer ranges of a size that matches the application (instead of the hardware) >are quite feasible and useful; I'd rather not pay the proce of dynamic heap allocation >for each integer. > >-- hendrik Ok here I have a proposal, modeled on how Modula-3 does arrays. The type specifier LONGINT to be valid in every context where an open array is valid. A subrange of LONGINT to be treated like a non-open array. NEW(REF LONGINT, ..) would take two "size" specifiers, a minimum and a maximum, of type LONGINT. For L, U, LONGINT literals, NEW(REF LONGINT, L, U) would produce the same thing as NEW(REF [L..U]) NEW(REF LONGINT, ..) is needed for dynamically sized LONGINTs. And then overload the arithmetic operations, the way arrays and REF RECORDs are, so that for b and c REF LONGINT, b + c = b^ + c = b + c^ = b^ + c^ Assignments carry an implicit range check. Assignment rules the same as INTEGER and its subranges. Use VAL to convert...? In short, expressions involving LONGINT have type LONGINT, but no "bare" LONGINT can ever be created. However note the following, perfectly legal. WITH a = b + c, r = NEW(REF LONGINT, a, a) DO r^ := a END Also legal, note parameters: PROCEDURE Collatz(READONLY a : LONGINT; VAR b : LONGINT) = BEGIN CASE a MOD 2L OF 0L => b := a DIV 2L | 1L => b := 3L * a + 1L END END Collatz; VALUE a : LONGINT would be discouraged. Returning LONGINT would *not* be legal. ARRAY OF LONGINT would mean the LONGINTs are limited to the same range, and used in NEW would take three arguments, one of type INTEGER for the array size and two of type LONGINT to specify the LONGINTs' bounds. Perhaps... PROCEDURE Collatz2(READONLY a : LONGINT; VAR b : LONGINT) RAISES { Range } = BEGIN CASE a MOD 2L OF 0L => b := a DIV 2L | 1L => WITH new = 3L * a + 1L DO (* is new actually stored anywhere!? *) IF new > LAST(b) THEN RAISE Range ELSE b := new END END END END Collatz2; My proposal gives you both heap-allocated dynamically sized LONGINT and stack-allocated fixed-sized longints and allows you to mix them at will. Collatz2 does seem a little bit disturbing, however. Can we rely on alloca "under the covers"? (Architectures that don't provide alloca could heap-allocate new in that example, *if* they need to.) Another thing that occurs to me is that while + and - are straightforward, *, DIV, and MOD are things you may well want to use very special and specific algorithms for in a given application. It makes sense to let the user replace the code for these operations. And now it begins to look like C++. Sigh. Hendrik, I do think WITH causes similar problems even for strictly range-limited numbers like the ones you are proposing? (And so does expression evaluation, of course...) Now is it even reasonable to have this built in? What if the user wants lazy evaluation? Are non-lazy LONGINTs very useful? Of course, I have to admit I am using a hardware simulation environment where non-lazy LONGINTs would indeed be very useful. Mika From hosking at cs.purdue.edu Sat Apr 24 18:42:07 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 24 Apr 2010 12:42:07 -0400 Subject: [M3devel] INTEGER In-Reply-To: <20100424103435.A1CC41A20C2@async.async.caltech.edu> References: <20100421185631.GA17051@topoi.pooq.com> <80775CA2-A2FD-40AF-B235-7DB84127762E@cs.purdue.edu> <20100422123805.GA19259@topoi.pooq.com> <87B45DCC-2B8A-4C69-97D7-240BC1E2252D@cs.purdue.edu> <20100422145522.GA19946@topoi.pooq.com> <28339030-6005-4C28-872C-A68CF24BF4DF@cs.purdue.edu> <20100422154357.GA20043@topoi.pooq.com> <270A99B5-173E-413B-8C28-E1CA68870FD4@cs.purdue.edu> <20100423094903.GC21281@topoi.pooq.com> <20100423185214.BA2EF1A20E1@async.async.caltech.edu> <20100423165613.GA22126@topoi.pooq.com> <20100424103435.A1CC41A20C2@async.async.caltech.edu> Message-ID: This sounds like something that should be implemented initially as a library so it can be evaluated for its usefulness. If we need built-ins for efficiency then that could come later as needed. To that end, why not simply say: TYPE LONGINT = ARRAY OF INTEGER and implement operations in the same way as Word? On 24 Apr 2010, at 06:34, Mika Nystrom wrote: > hendrik at topoi.pooq.com writes: >> On Fri, Apr 23, 2010 at 11:52:14AM -0700, Mika Nystrom wrote: >>> >>> Is the infinite extent of the TEXT type a serious implementation difficulty? :-) >> >> Yes, actually. It requires heap storage allocation and indirection. That's just what >> it costs, so we pay it, since fixed-width strings aren't all that useful. >> >> But integer ranges of a size that matches the application (instead of the hardware) >> are quite feasible and useful; I'd rather not pay the proce of dynamic heap allocation >> for each integer. >> >> -- hendrik > > Ok here I have a proposal, modeled on how Modula-3 does arrays. > > The type specifier LONGINT to be valid in every context where an open > array is valid. > > A subrange of LONGINT to be treated like a non-open array. > > NEW(REF LONGINT, ..) would take two "size" specifiers, a minimum and a maximum, > of type LONGINT. > > For L, U, LONGINT literals, > > NEW(REF LONGINT, L, U) > > would produce the same thing as > > NEW(REF [L..U]) > > NEW(REF LONGINT, ..) is needed for dynamically sized LONGINTs. > > And then overload the arithmetic operations, the way arrays and REF RECORDs are, so > that for b and c REF LONGINT, > > b + c = b^ + c = b + c^ = b^ + c^ > > Assignments carry an implicit range check. > > Assignment rules the same as INTEGER and its subranges. > > Use VAL to convert...? > > In short, expressions involving LONGINT have type LONGINT, but no "bare" LONGINT can > ever be created. > > However note the following, perfectly legal. > > WITH a = b + c, > r = NEW(REF LONGINT, a, a) DO > r^ := a > END > > Also legal, note parameters: > > PROCEDURE Collatz(READONLY a : LONGINT; VAR b : LONGINT) = > BEGIN > CASE a MOD 2L OF > 0L => b := a DIV 2L > | > 1L => b := 3L * a + 1L > END > END Collatz; > > VALUE a : LONGINT would be discouraged. Returning LONGINT > would *not* be legal. ARRAY OF LONGINT would mean the LONGINTs > are limited to the same range, and used in NEW would take three > arguments, one of type INTEGER for the array size and two of type > LONGINT to specify the LONGINTs' bounds. > > Perhaps... > > PROCEDURE Collatz2(READONLY a : LONGINT; VAR b : LONGINT) > RAISES { Range } = > BEGIN > CASE a MOD 2L OF > 0L => b := a DIV 2L > | > 1L => > WITH new = 3L * a + 1L DO (* is new actually stored anywhere!? *) > IF new > LAST(b) THEN > RAISE Range > ELSE > b := new > END > END > END > END Collatz2; > > My proposal gives you both heap-allocated dynamically sized LONGINT and > stack-allocated fixed-sized longints and allows you to mix them at will. > Collatz2 does seem a little bit disturbing, however. Can we rely on > alloca "under the covers"? (Architectures that don't provide alloca > could heap-allocate new in that example, *if* they need to.) > > Another thing that occurs to me is that while + and - are straightforward, > *, DIV, and MOD are things you may well want to use very special and > specific algorithms for in a given application. It makes sense to let the > user replace the code for these operations. And now it begins to look > like C++. Sigh. > > Hendrik, I do think WITH causes similar problems even for strictly > range-limited numbers like the ones you are proposing? (And so does > expression evaluation, of course...) > > Now is it even reasonable to have this built in? What if the user wants > lazy evaluation? Are non-lazy LONGINTs very useful? > > Of course, I have to admit I am using a hardware simulation environment > where non-lazy LONGINTs would indeed be very useful. > > Mika From jay.krell at cornell.edu Sat Apr 24 23:20:49 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 24 Apr 2010 21:20:49 +0000 Subject: [M3devel] unsafe functions that read/write raw memory, integer conversions, obligation of unsafe code? Message-ID: What is the obligation of stuff like:? UNSAFE INTERFACE UnixIO; PROCEDURE read(file:int; buffer: ADDRESS; length: INTEGER); PROCEDURE write(file: int; ADDRESS; length: INTEGER); The reason I ask is kind of tangential. I'll explain it, but it again it doesn't necessarily matter: In m3core/src/unix/Usocket.c we have, my doing: /* assert that *plen fits in a 32 bit signed integer, no matter if it is unsigned or signed, or 32 bits or 64 bits */ #define ASSERT_PLEN \ ??? assert((plen == NULL) || (((*plen)>= 0) && ((*plen) < (m3_socklen_t)(1UL << 30)))); Sometimes *plen is signed, sometimes unsigned. I'm going to make it consistent from platform to platform. I used to try to match the underlying platform and avoid copying. The VMS C compiler is reasonably warning about *plen>= 0 always being true, given unsigned *plen. So I'm wondering again what m3_socklen_t should be anyway. There are at least four candidates: ?? 32bit signed int ?? 32bit unsigned int ?? pointer sized int (INTEGER) ?? pointer sized unsigned integer (Word.T, which is INTEGER but with a different interpretation) The numbers involves are always small and positive. ? It isn't a "buffer" size, but the size of a small struct. Most 64bit C environments use a 32bit unsigned int. Though, again, we don't have to match them. The comments I left say: Cygwin is 32bit int, HP-UX is size_t (32 or 64), the rest are unsigned int. VMS is usually size_t, or int under old setting. An size_t is surprisingly always 32 bits. But again the C settings aren't super relevant. I'm thinking I should definitely make it unsigned. That matches most platforms (which, again, doesn't matter), lets the assertion be cut in half, and thereby removing the warning. But again, what is my "safety obligation"? If some Modula-3 code passes in a "negative" number, am I doing a legitimate favor in failing an assertion? Or they might just as well have passed in an incorrectly very large integer and overflowed their buffer just as well? ? Making negative numbers invalid seems useful at first glance, but then when you realize that pretty darn large numbers ?? will still get through, it seems less useful. Now, thinking about this more, it is not just about avoiding buffer overflow. There is also the matter of truncating integers. If some Modula-3 code passes me the value 4GB + 1 and I in turm truncate that to just 1, I have done something wrong. Integer conversions have to be checked. Therefore, for one thing, I think these wrappers do need to know with certainty what the underlying socken_t is. ? Even on platforms that don't declare it. :) Cygwin and VMS. Asserting that they fit in a half range 32 bit integer is a way to avoid being completely precise. It is acceptable here -- it not the size of a "buffer", but the size of a fairly small struct, a struct addr. ?- Jay From mika at async.async.caltech.edu Sat Apr 24 23:25:23 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Sat, 24 Apr 2010 14:25:23 -0700 Subject: [M3devel] unsafe functions that read/write raw memory, integer conversions, obligation of unsafe code? In-Reply-To: References: Message-ID: <20100424212523.E37411A20B6@async.async.caltech.edu> Unsafe code that exports only an UNSAFE INTERFACE has no particular obligation. Unsafe code that exports a non-UNSAFE INTERFACE has to guarantee the absence of unchecked runtime errors regardless of input---this can be weakened to "regardless of input as long as that input can possibly be provided by a non-UNSAFE module", but the latter might be difficult to verify as it is a global property. Mika Jay K writes: > >What is the obligation of stuff like:? > > >UNSAFE INTERFACE UnixIO=3B > > >PROCEDURE read(file:int=3B buffer: ADDRESS=3B length: INTEGER)=3B >PROCEDURE write(file: int=3B ADDRESS=3B length: INTEGER)=3B > > > >The reason I ask is kind of tangential. > >I'll explain it=2C but it again it doesn't necessarily matter: > >In m3core/src/unix/Usocket.c we have=2C my doing: > > >/* assert that *plen fits in a 32 bit signed integer=2C no matter >if it is unsigned or signed=2C or 32 bits or 64 bits */ > >#define ASSERT_PLEN \ >=A0=A0=A0 assert((plen =3D=3D NULL) || (((*plen)>=3D 0) && ((*plen) < (m3_s= >ocklen_t)(1UL << 30))))=3B > > > >Sometimes *plen is signed=2C sometimes unsigned. >I'm going to make it consistent from platform to platform. >I used to try to match the underlying platform and avoid copying. > > > >The VMS C compiler is reasonably warning about *plen>=3D 0 always being tru= >e=2C given unsigned *plen. >So I'm wondering again what m3_socklen_t should be anyway. >There are at least four candidates: >=A0=A0 32bit signed int >=A0=A0 32bit unsigned int=20 >=A0=A0 pointer sized int (INTEGER) >=A0=A0 pointer sized unsigned integer (Word.T=2C which is INTEGER but with = >a different interpretation) > > >The numbers involves are always small and positive. >=A0 It isn't a "buffer" size=2C but the size of a small struct. >Most 64bit C environments use a 32bit unsigned int. Though=2C again=2C we d= >on't have to match them. >The comments I left say: Cygwin is 32bit int=2C HP-UX is size_t (32 or 64)= >=2C the rest are unsigned int. >VMS is usually size_t=2C or int under old setting. An size_t is surprisingl= >y always 32 bits. >But again the C settings aren't super relevant. > > >I'm thinking I should definitely make it unsigned. >That matches most platforms (which=2C again=2C doesn't matter)=2C lets the = >assertion be cut in half=2C and thereby removing the warning. > > >But again=2C what is my "safety obligation"? >If some Modula-3 code passes in a "negative" number=2C am I doing a legitim= >ate favor in failing an assertion? >Or they might just as well have passed in an incorrectly very large integer= > and overflowed their buffer just as well? >=A0 Making negative numbers invalid seems useful at first glance=2C but the= >n when you realize that pretty darn large numbers >=A0=A0 will still get through=2C it seems less useful. > > >Now=2C thinking about this more=2C it is not just about avoiding buffer ove= >rflow. >There is also the matter of truncating integers. >If some Modula-3 code passes me the value 4GB + 1 and I in turm truncate th= >at to just 1=2C I have done something wrong. >Integer conversions have to be checked. >Therefore=2C for one thing=2C I think these wrappers do need to know with c= >ertainty what the underlying socken_t is. >=A0 Even on platforms that don't declare it. :) Cygwin and VMS. > > >Asserting that they fit in a half range 32 bit integer is a way to avoid be= >ing completely precise. >It is acceptable here -- it not the size of a "buffer"=2C but the size of a= > fairly small struct=2C a struct addr. > > >=A0- Jay > > = From mika at async.async.caltech.edu Sat Apr 24 23:29:52 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Sat, 24 Apr 2010 14:29:52 -0700 Subject: [M3devel] Compiling Modula-3 to C Message-ID: <20100424212952.D9BDE1A20B7@async.async.caltech.edu> The question of making a Modula-3 compiler emit C code as output comes up on this mailing list from time to time. I just discovered a reference to a real example of this. http://caltechcstr.library.caltech.edu/218/01/93-15.pdf Note pages 49-50 (54-55 in the PDF). I also find the byte counts on page 49 interesting. I wish my m3core were that small! Mika From jay.krell at cornell.edu Sat Apr 24 23:58:18 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 24 Apr 2010 21:58:18 +0000 Subject: [M3devel] Compiling Modula-3 to C In-Reply-To: <20100424212952.D9BDE1A20B7@async.async.caltech.edu> References: <20100424212952.D9BDE1A20B7@async.async.caltech.edu> Message-ID: I haven't read this closely yet, I admit. I'm sure we'll get a Modula-3 to C backend before much longer. It greatly increases your real and theoretical platform support for one medium upfront cost, and perhaps a little bit of ongoing maintenance if some oddities are reported. I'll be tired of the old way fairly soon. There remain too many viable but unsupported targets. If it has pthreads (or sigaltstack), POSIX (or NT), and a C compiler, that should be all it takes. Notice that there are now affordable and somewhat performant MIPS laptops that ? run at least Linux and OpenBSD. Notice that FreeBSD is slowly expanding ? its targets, including PowerPC, MIPS, SPARC64. There will probably be an option to generate C++ as well, which should offer more efficient exception handling than portable C. Whether or not it it is all idiomatic and intuitive to interoperate with, unknown. Regarding that paper: One should try to remain mindful of when language change is needed vs. merely library. ?? I didn't read enough to see if they need language changes. ?? I do believe Modula-3 could benefit from some language changes. Though that might be mitigated ?? and/or eliminated by me knowing Modula-3 better. For example, can I have a type with ?? compiler-enforced opacity without requiring heap allocation? C compilers are probably better these days. ?Look -- gcc 4.5 just caught up some with Visual C++ and others and has "LTO": link time optimization. ? I believe Sun also has had this a while, and I'm sure others. ? I rarely turn on optimization though, I admit. ? Disk and network I/O tend to dominate all costs. I don't do heavy computation. Shared libraries are always going to seem bloated because they export everything, even unused stuff. The paper seems little confused on this matter, depending on the quality/behavior of the linker, and whether or not functions are "separated" within object files. Visual C++ has the -Gy flag which you should *always* use. I don't know why it is an even an option. It makes each function within an object separate, so you only link in what you use, and what that references, transitive closure. For better and for worse, data is not linked in with that same high level of granularity. If you get any data from an object, you get it all. And that includes pointers to functions, and whatever those functions call, even if the data isn't referenced. I know that historically linkers didn't strip out anything. I'm surprised such linkers existed. Are they still in use? (What do GNU, Sun, Mac do?) ?- Jay ---------------------------------------- > To: m3devel at elegosoft.com > Date: Sat, 24 Apr 2010 14:29:52 -0700 > From: mika at async.async.caltech.edu > Subject: [M3devel] Compiling Modula-3 to C > > > The question of making a Modula-3 compiler emit C code as output comes > up on this mailing list from time to time. > > I just discovered a reference to a real example of this. > > http://caltechcstr.library.caltech.edu/218/01/93-15.pdf > > Note pages 49-50 (54-55 in the PDF). > > I also find the byte counts on page 49 interesting. I wish my m3core > were that small! > > Mika From mika at async.async.caltech.edu Sun Apr 25 00:23:18 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Sat, 24 Apr 2010 15:23:18 -0700 Subject: [M3devel] Compiling Modula-3 to C In-Reply-To: References: <20100424212952.D9BDE1A20B7@async.async.caltech.edu> Message-ID: <20100424222319.08FF71A20B5@async.async.caltech.edu> Jay, My point in sharing that was not to agitate for making the changes in Modula-3 that Rustan did for his project. (It's his M.S. thesis.) I wanted to show the quality of the assembly code that one existing Modula-3-to-C-to-ASM toolchain has generated. It doesn't look *horrendous* to me, honestly, only maybe the footprint is a bit on the large side. One thing one could try of course is to type in Rustan's generated C code and compare what gcc spits out from compiling it it to the ASM generated by compiling the original M3 code. (On one's favorite modern architecture.) I have Modula-3D in source form so I am sure the Modula-3-to-C compiler is in there, and most of it is in the SRC sources anyhow. MIPS especially. No need to write a brand new one. No you cannot have a type with compiler-enforced opacity without requiring heap allocation. It's a shortcoming of the language, yes. But you know, you can just leave a comment that says the type is opaque. The point of M3's safety rules is to prevent unchecked runtime errors. M3's opaqueness rules are defined in terms of OBJECT which are always references. The designers felt that the C++ objects were too hard to achieve. BY THE WAY, the whole way Modula-3 does opaqueness is in the minds of anal-retentive OO people completely wrong (I think it is brilliant). They would have you declare in your object type who can touch the bits of it. friends, protected, etc. In Modula-3 it's mostly up to the *client* to decide how much opaqueness is right. For example: INTERFACE Q; TYPE T <: Public; END Q. INTERFACE QFriends; REVEAL Q.T <: Friendly; END QFriends. INTERFACE QPrivate; REVEAL Q.T <: Private; END QPrivate. A client R of Q can then go ahead and IMPORT QFriends and QPrivate as it pleases, regardless of what the relationship between R and Q is. (There is a hack in quake to hide certain interfaces but it's only done at one level and it's not part of the Modula-3 language proper.) Thus, Modula-3 assumes that programmers are a bit more responsible than the hiding rules available in C++ or Java. Which is why I say that not having the opaqueness available for non-ref types is not such a big deal, really. The language is trying to help you not make stupid mistakes---it's not some kind of "OO cleanliness police". I have written a lot of M3 code and have indeed missed opaque nonreference objects from time to time, but you learn to live with it, just like you learn to live with the idiosyncracies of any programming language. >From personal experience all I can say is that M3's idiosyncracies are far less annoying than those of any other "practical" programming language I've ever used. (This is not a criticism, but how much M3 have you actually written?) Oh, regarding link-time optimization, see: http://www.modula3.org/threads/2/#linkTimeOptimization Mika Jay K writes: > >I haven't read this closely yet=2C I admit. > > >I'm sure we'll get a Modula-3 to C backend before much longer. >It greatly increases your real and theoretical platform support for >one medium upfront cost=2C and perhaps a little bit of ongoing maintenance = >if some oddities are reported. >I'll be tired of the old way fairly soon. >There remain too many viable but unsupported targets. >If it has pthreads (or sigaltstack)=2C POSIX (or NT)=2C and a C compiler=2C= > that should be all it takes. >Notice that there are now affordable and somewhat performant MIPS laptops t= >hat >=A0 run at least Linux and OpenBSD. Notice that FreeBSD is slowly expanding >=A0 its targets=2C including PowerPC=2C MIPS=2C SPARC64. > > >There will probably be an option to generate C++ as well=2C which >should offer more efficient exception handling than portable C. > >Whether or not it it is all idiomatic and intuitive to interoperate with=2C= > unknown. > >Regarding that paper: > >One should try to remain mindful of when language change is needed vs. mere= >ly library. >=A0=A0 I didn't read enough to see if they need language changes. >=A0=A0 I do believe Modula-3 could benefit from some language changes. Thou= >gh that might be mitigated >=A0=A0 and/or eliminated by me knowing Modula-3 better. For example=2C can = >I have a type with >=A0=A0 compiler-enforced opacity without requiring heap allocation? > >C compilers are probably better these days. >=A0Look -- gcc 4.5 just caught up some with Visual C++ and others and has "= >LTO": link time optimization. >=A0 I believe Sun also has had this a while=2C and I'm sure others. >=A0 I rarely turn on optimization though=2C I admit. >=A0 Disk and network I/O tend to dominate all costs. I don't do heavy compu= >tation. > > >Shared libraries are always going to seem bloated because they export every= >thing=2C >even unused stuff. > > >The paper seems little confused on this matter=2C depending on the >quality/behavior of the linker=2C and whether or not functions are "separat= >ed" within >object files. Visual C++ has the -Gy flag which you should *always* use. >I don't know why it is an even an option. It makes each function within an = >object >separate=2C so you only link in what you use=2C and what that references=2C= > transitive closure. >For better and for worse=2C data is not linked in with that same high level= > of granularity. >If you get any data from an object=2C you get it all. >And that includes pointers to functions=2C and whatever those functions cal= >l=2C even >if the data isn't referenced. > > >I know that historically linkers didn't strip out anything. >I'm surprised such linkers existed. Are they still in use? >(What do GNU=2C Sun=2C Mac do?) > > >=A0- Jay > >---------------------------------------- >> To: m3devel at elegosoft.com >> Date: Sat=2C 24 Apr 2010 14:29:52 -0700 >> From: mika at async.async.caltech.edu >> Subject: [M3devel] Compiling Modula-3 to C >> >> >> The question of making a Modula-3 compiler emit C code as output comes >> up on this mailing list from time to time. >> >> I just discovered a reference to a real example of this. >> >> http://caltechcstr.library.caltech.edu/218/01/93-15.pdf >> >> Note pages 49-50 (54-55 in the PDF). >> >> I also find the byte counts on page 49 interesting. I wish my m3core >> were that small! >> >> Mika > = From jay.krell at cornell.edu Sun Apr 25 00:56:28 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 24 Apr 2010 22:56:28 +0000 Subject: [M3devel] Compiling Modula-3 to C In-Reply-To: <20100424222319.08FF71A20B5@async.async.caltech.edu> References: <20100424212952.D9BDE1A20B7@async.async.caltech.edu>, , <20100424222319.08FF71A20B5@async.async.caltech.edu> Message-ID: Agitation not necessarly inferred. :) Mika, the thing is.. consider "safety". I can argue..as a C programmer..I know what is safe, I don't need the language protection. Practise proves this is somewhat true, somewhat false. ?? ? Similar to your argument: ?I know what is opaque, I don't need the language protection. ? I don't think a comment declaring opacity is strong enough. C++ does this better, even though also a little weak. In C++ I would put in "private:" and the compiler enforces it. If someone is determined to break through, they must edit the header, possibly recompile, or duplicate the declaration without private and cast. There is no accidental violation of private. I understand there is the issue of the size still being revealed ? which is an important practical matter in terms of coupling ? and need to rebuild. But at the abstract enforced interface ? level, it doesn't matter. I understand that C++ is a little bit complicated, with public/private/protected, and friends. And C# has more options (visible to the assembly/.dll). I think at least one bit is worthwhile though. public or private. Public to all or nobody. I doubt new syntax would even be needed. Just like: foo.i3: TYPE Foo; or TYPE FooPublic = RECORD END; TYPE <: FooPublic; foo.m3 ?REVEAL Foo = RECORD ... END; Target.Int I think is a good example. It is small, fixed size, not a reference, not separately/heap allocated. But it is opaque only via comment. I have a 2.x tree somewhere, recently downloaded from the web. It does Modula-3-to-C within what was and is m3front. The "design" of the output C can be reclaimed. The code has to/should be sprinkled around elsewhere, behind an implementation of CG.i3. And as you allude, I might try doing it from scratch anyway. :) ?- Jay ---------------------------------------- > To: jay.krell at cornell.edu > Date: Sat, 24 Apr 2010 15:23:18 -0700 > From: mika at async.async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Compiling Modula-3 to C > > Jay, > > My point in sharing that was not to agitate for making the changes in > Modula-3 that Rustan did for his project. (It's his M.S. thesis.) > > I wanted to show the quality of the assembly code that one existing > Modula-3-to-C-to-ASM toolchain has generated. It doesn't look > *horrendous* to me, honestly, only maybe the footprint is a bit on the > large side. One thing one could try of course is to type in Rustan's > generated C code and compare what gcc spits out from compiling it it to > the ASM generated by compiling the original M3 code. (On one's favorite > modern architecture.) > > I have Modula-3D in source form so I am sure the Modula-3-to-C compiler is > in there, and most of it is in the SRC sources anyhow. MIPS especially. > No need to write a brand new one. > > No you cannot have a type with compiler-enforced opacity without requiring > heap allocation. It's a shortcoming of the language, yes. But you know, > you can just leave a comment that says the type is opaque. > > The point of M3's safety rules is to prevent unchecked runtime errors. > > M3's opaqueness rules are defined in terms of OBJECT which are always > references. The designers felt that the C++ objects were too hard to > achieve. > > BY THE WAY, the whole way Modula-3 does opaqueness is in the minds of > anal-retentive OO people completely wrong (I think it is brilliant). > They would have you declare in your object type who can touch the > bits of it. friends, protected, etc. In Modula-3 it's mostly up to > the *client* to decide how much opaqueness is right. > > For example: > > INTERFACE Q; TYPE T <: Public; END Q. > > INTERFACE QFriends; REVEAL Q.T <: Friendly; END QFriends. > > INTERFACE QPrivate; REVEAL Q.T <: Private; END QPrivate. > > A client R of Q can then go ahead and IMPORT QFriends and QPrivate as > it pleases, regardless of what the relationship between R and Q is. > (There is a hack in quake to hide certain interfaces but it's only > done at one level and it's not part of the Modula-3 language proper.) > > Thus, Modula-3 assumes that programmers are a bit more responsible than > the hiding rules available in C++ or Java. Which is why I say that > not having the opaqueness available for non-ref types is not such a big > deal, really. The language is trying to help you not make stupid > mistakes---it's not some kind of "OO cleanliness police". > > I have written a lot of M3 code and have indeed missed opaque nonreference > objects from time to time, but you learn to live with it, just like > you learn to live with the idiosyncracies of any programming language. > From personal experience all I can say is that M3's idiosyncracies > are far less annoying than those of any other "practical" programming > language I've ever used. (This is not a criticism, but how much M3 have > you actually written?) > > Oh, regarding link-time optimization, see: > > http://www.modula3.org/threads/2/#linkTimeOptimization > > Mika > > > > Jay K writes: >> >>I haven't read this closely yet=2C I admit. >> >> >>I'm sure we'll get a Modula-3 to C backend before much longer. >>It greatly increases your real and theoretical platform support for >>one medium upfront cost=2C and perhaps a little bit of ongoing maintenance = >>if some oddities are reported. >>I'll be tired of the old way fairly soon. >>There remain too many viable but unsupported targets. >>If it has pthreads (or sigaltstack)=2C POSIX (or NT)=2C and a C compiler=2C= >> that should be all it takes. >>Notice that there are now affordable and somewhat performant MIPS laptops t= >>hat >>=A0 run at least Linux and OpenBSD. Notice that FreeBSD is slowly expanding >>=A0 its targets=2C including PowerPC=2C MIPS=2C SPARC64. >> >> >>There will probably be an option to generate C++ as well=2C which >>should offer more efficient exception handling than portable C. >> >>Whether or not it it is all idiomatic and intuitive to interoperate with=2C= >> unknown. >> >>Regarding that paper: >> >>One should try to remain mindful of when language change is needed vs. mere= >>ly library. >>=A0=A0 I didn't read enough to see if they need language changes. >>=A0=A0 I do believe Modula-3 could benefit from some language changes. Thou= >>gh that might be mitigated >>=A0=A0 and/or eliminated by me knowing Modula-3 better. For example=2C can = >>I have a type with >>=A0=A0 compiler-enforced opacity without requiring heap allocation? >> >>C compilers are probably better these days. >>=A0Look -- gcc 4.5 just caught up some with Visual C++ and others and has "= >>LTO": link time optimization. >>=A0 I believe Sun also has had this a while=2C and I'm sure others. >>=A0 I rarely turn on optimization though=2C I admit. >>=A0 Disk and network I/O tend to dominate all costs. I don't do heavy compu= >>tation. >> >> >>Shared libraries are always going to seem bloated because they export every= >>thing=2C >>even unused stuff. >> >> >>The paper seems little confused on this matter=2C depending on the >>quality/behavior of the linker=2C and whether or not functions are "separat= >>ed" within >>object files. Visual C++ has the -Gy flag which you should *always* use. >>I don't know why it is an even an option. It makes each function within an = >>object >>separate=2C so you only link in what you use=2C and what that references=2C= >> transitive closure. >>For better and for worse=2C data is not linked in with that same high level= >> of granularity. >>If you get any data from an object=2C you get it all. >>And that includes pointers to functions=2C and whatever those functions cal= >>l=2C even >>if the data isn't referenced. >> >> >>I know that historically linkers didn't strip out anything. >>I'm surprised such linkers existed. Are they still in use? >>(What do GNU=2C Sun=2C Mac do?) >> >> >>=A0- Jay >> >>---------------------------------------- >>> To: m3devel at elegosoft.com >>> Date: Sat=2C 24 Apr 2010 14:29:52 -0700 >>> From: mika at async.async.caltech.edu >>> Subject: [M3devel] Compiling Modula-3 to C >>> >>> >>> The question of making a Modula-3 compiler emit C code as output comes >>> up on this mailing list from time to time. >>> >>> I just discovered a reference to a real example of this. >>> >>> http://caltechcstr.library.caltech.edu/218/01/93-15.pdf >>> >>> Note pages 49-50 (54-55 in the PDF). >>> >>> I also find the byte counts on page 49 interesting. I wish my m3core >>> were that small! >>> >>> Mika >> = From jay.krell at cornell.edu Sun Apr 25 02:00:57 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 25 Apr 2010 00:00:57 +0000 Subject: [M3devel] alpha32 atomic exchange char/widechar? Message-ID: Tony, any idea why on Alpha32 atomic exchange of char/widechar would hit assertion failures in the compiler? It works on Alpha64, and it works on Alpha32 from C (gcc 4.3.0) ? So it isn't for lacking the necessary instructions. ? It works with ev4 or ev6, just more efficiently with ev6. I edited Atomic.mg to just: (* Copyright (C) 1989, Digital Equipment Corporation?????????? *) (* All rights reserved.??????????????????????????????????????? *) (* See the file COPYRIGHT for a full description.????????????? *) GENERIC MODULE Atomic(Rep, Impl); PROCEDURE Swap (VAR var: T; val: Rep.T; order: Order): Rep.T = ? BEGIN RETURN Impl.Swap (var, val, Order.Sequential); ? END Swap; BEGIN END Atomic. and then I get: ../ALPHA32_VMS/AtomicChar.m3 => ../src/atomic/Atomic.mg:9: internal compiler error: in emit_move_insn, at expr.c:3379 ../ALPHA32_VMS/AtomicWideChar.m3 => ../src/atomic/Atomic.mg: In function 'AtomicWideChar__Swap': ../ALPHA32_VMS/AtomicWideChar.m3 => ../src/atomic/Atomic.mg:9: internal compiler error: in emit_move_insn, at expr.c:3379 Please submit a full bug report, rtx emit_move_insn (rtx x, rtx y) { ? enum machine_mode mode = GET_MODE (x); ? rtx y_cst = NULL_RTX; ? rtx last_insn, set; ? gcc_assert (mode != BLKmode ??? ????? && (GET_MODE (y) == mode || GET_MODE (y) == VOIDmode)); I'll dig a bit. ?- Jay From mika at async.async.caltech.edu Sun Apr 25 06:52:02 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Sat, 24 Apr 2010 21:52:02 -0700 Subject: [M3devel] Compiling Modula-3 to C In-Reply-To: References: <20100424212952.D9BDE1A20B7@async.async.caltech.edu>, , <20100424222319.08FF71A20B5@async.async.caltech.edu> Message-ID: <20100425045202.D57B91A20B4@async.async.caltech.edu> Jay K writes: > >Agitation not necessarly inferred. :) > > >Mika=2C the thing is.. consider "safety". >I can argue..as a C programmer..I know what is safe=2C I don't >need the language protection. >Practise proves this is somewhat true=2C somewhat false. >=A0=A0=20 >=A0 >Similar to your argument: >=A0I know what is opaque=2C I don't need the language protection. > >=A0 >I don't think a comment declaring opacity is strong enough. A little different. C never lets you have safety. Modula-3 gives you opacity. You just can't have it at the same time as stack allocation. Same thing with anything else that you only get with OBJECTs for that matter (e.g., dynamic method dispatch). You can't break through the opacity with a cast, either. ... > >I understand that C++ is a little bit complicated=2C with public/private/pr= >otected=2C and friends. >And C# has more options (visible to the assembly/.dll). >I think at least one bit is worthwhile though. >public or private. >Public to all or nobody. >I doubt new syntax would even be needed. >Just like: > >foo.i3: >TYPE Foo=3B >or TYPE FooPublic =3D RECORD END=3B TYPE <: FooPublic=3B > >foo.m3 >=A0REVEAL Foo =3D RECORD ... END=3B > I think you'd just want fully opaque types. Mixing in <: here seems inappropriate. <: has meaning for the abstract types (up till now), whereas I can't figure out what it means for RECORDs. If you want to reveal fields you can always do it through a PROCEDURE that converts from the opaque type to a visible type. TYPE T = OPAQUE RECORD; TYPE Visible = RECORD ... END; PROCEDURE MakeVisible(READONLY t : T) : Visible; Then in the implementation all you have is REVEAL T = RECORD ... END; Mika From jay.krell at cornell.edu Sun Apr 25 15:26:43 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 25 Apr 2010 13:26:43 +0000 Subject: [M3devel] alpha32 atomic exchange char/widechar? Message-ID: aha, gcc 4.3 hits the same assertion failure with -O1 or -O2. I should have noticed that earlier. ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: alpha32 atomic exchange char/widechar? > Date: Sun, 25 Apr 2010 00:00:57 +0000 > > > Tony, any idea why on Alpha32 atomic exchange of char/widechar would hit assertion failures in the compiler? > It works on Alpha64, and it works on Alpha32 from C (gcc 4.3.0) > So it isn't for lacking the necessary instructions. > It works with ev4 or ev6, just more efficiently with ev6. > > I edited Atomic.mg to just: > > (* Copyright (C) 1989, Digital Equipment Corporation *) > (* All rights reserved. *) > (* See the file COPYRIGHT for a full description. *) > > GENERIC MODULE Atomic(Rep, Impl); > > PROCEDURE Swap (VAR var: T; val: Rep.T; order: Order): Rep.T = > BEGIN > RETURN Impl.Swap (var, val, Order.Sequential); > END Swap; > > BEGIN > END Atomic. > > and then I get: > > ../ALPHA32_VMS/AtomicChar.m3 => ../src/atomic/Atomic.mg:9: internal compiler error: in emit_move_insn, at expr.c:3379 > ../ALPHA32_VMS/AtomicWideChar.m3 => ../src/atomic/Atomic.mg: In function 'AtomicWideChar__Swap': > ../ALPHA32_VMS/AtomicWideChar.m3 => ../src/atomic/Atomic.mg:9: internal compiler error: in emit_move_insn, at expr.c:3379 > Please submit a full bug report, > > rtx > emit_move_insn (rtx x, rtx y) > { > enum machine_mode mode = GET_MODE (x); > rtx y_cst = NULL_RTX; > rtx last_insn, set; > > gcc_assert (mode != BLKmode > && (GET_MODE (y) == mode || GET_MODE (y) == VOIDmode)); > > I'll dig a bit. > > - Jay > From jay.krell at cornell.edu Mon Apr 26 01:29:59 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 25 Apr 2010 23:29:59 +0000 Subject: [M3devel] fork/vfork Message-ID: so..in the area of not cloning C headers..fork/vfork has been a lingering still cloned thing. It was already bothering me. I was going to make fork a function pointer at least, so it could honor any #defines or renaming via target specific #pragmas. That way as well we could also go back to vfork where it is a /little/ faster. Fork and/or vfork are not portably wrappable in the usual way because the caller of one or both of them cannot return without calling _exit or an exec function. A wrapper would violate this. I believe I had this violation in temporarily and I believe it did cause a problem. But now there is a bigger problem: VMS: #if defined(__ALPHA) ??? __int64_ptr32 decc$$get_vfork_jmpbuf(void); ??? int LIB$GET_CURRENT_INVO_CONTEXT(__int64 *__invo_context); ??? int decc$$alloc_vfork_blocks(void); #?? define vfork() (decc$$alloc_vfork_blocks()>= 0 ? \ ??? LIB$GET_CURRENT_INVO_CONTEXT(decc$$get_vfork_jmpbuf()) : -1) which further motivates "rewriting" vfork users in C. There are only about two of them. I intend to look into and do this unless there is strong protest. vfork is implemented with a trick that is also mentioned in some Cygwin documentation, something Cygwin attempted but doesn't do. vfork calls setjmp. It returns -1 so the caller thinks it is in the child process. exec calls longjmp, returning the pid on the second return to the parent. Something like that. I almost wonder if we can do this ourselves. But not calling fork/vfork from Modula-3 directly was already a good idea. Now even better. We can leave in fork/vfork external declarations and folks that don't care to run on VMS can still call them. ?(and convert them to function pointers as per my previous thinking) ?- Jay From jay.krell at cornell.edu Tue Apr 27 11:01:23 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 27 Apr 2010 09:01:23 +0000 Subject: [M3devel] cooperative suspend? Message-ID: cooperative suspend Tony, you mind if I take a stab at "cooperative suspend" fairly soon? I can't find a good way to suspend threads on VMS. ? Or even get context in a signal handler. It will be a boolen in Target.i3, so no existing targets affected. ? Of course I'll test it on an existing target with the boolean set wrong. :) ? ? To optimize size instead of speed, I think the "every so often extra generated code" should be a call to a parameter-less function. Instead of checking a per-thread or global variable. Something like: VAR threadRequestingSuspend: ADDRESS; PROCEDURE Thread.PollSuspend() ? BEGIN ??? IF threadRequestingSuspend = NIL THEN RETURN END; ??? PollSuspendSlow(); ? END PollSuspend; (* This is split to avoid needing a frame in PollSuspend. *)? PROCEDURE PollSuspendSlow() ? VAR self: ADDRESS; ? BEGIN ??? IF threadRequestingSuspend = NIL THEN RETURN END; ??? self := GetActivation(); ??? IF self = threadRequestingSuspend THEN RETURN END; (* important consideration! *) ??? GetContext(self.context); (* roughly *) ??? self.suspended := TRUE; (* roughly *) ??? WaitForResume(); (* details to be determined, either the semaphore ????????????????????? * or maybe acquire per-thread lock. *) ? END PollSuspendSlow; The poll call could also be a function pointer and usually point to a function that does nothing. But that'd require loading the address from a global, and calling it. Probably more bloat than calling direct instead of indirect. ?- Jay From rodney_bates at lcwb.coop Tue Apr 27 16:40:47 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Tue, 27 Apr 2010 09:40:47 -0500 Subject: [M3devel] INTEGER In-Reply-To: <20100424103435.A1CC41A20C2@async.async.caltech.edu> References: <20100421185631.GA17051@topoi.pooq.com> <80775CA2-A2FD-40AF-B235-7DB84127762E@cs.purdue.edu> <20100422123805.GA19259@topoi.pooq.com> <87B45DCC-2B8A-4C69-97D7-240BC1E2252D@cs.purdue.edu> <20100422145522.GA19946@topoi.pooq.com> <28339030-6005-4C28-872C-A68CF24BF4DF@cs.purdue.edu> <20100422154357.GA20043@topoi.pooq.com> <270A99B5-173E-413B-8C28-E1CA68870FD4@cs.purdue.edu> <20100423094903.GC21281@topoi.pooq.com> <20100423185214.BA2EF1A20E1@async.async.caltech.edu> <20100423165613.GA22126@topoi.pooq.com> <20100424103435.A1CC41A20C2@async.async.caltech.edu> Message-ID: <4BD6F76F.6090603@lcwb.coop> A general discussion: (More to come on Mika's specific proposal) The problem with using subranges and only one integer type lies in the size of intermediate results of operators. This is sometimes important for programmers to manage carefully. All the more so in the age of network insecurity, where system crackers exploit boundary cases that would never occur in legitimate use. In original Modula-3, this is handled by making all intermediate results have type INTEGER, even if the operands have subrange types. This is a good compromise among conflicting needs, with these properties: 1) It is a simple rule for both compilers and programmers, and it satisfies the language properties that every expression has a unique type and it does not depend on how the expression is used. 2) Assuming the implementors choose the native word size for INTEGER, it is the most efficient arithmetic available. 3) It's the most liberal rule that doesn't have an efficiency penalty. 4) But it doesn't work when a value range greater than the native word size is needed for correctness. The problem arises when the application requirements make 4) relevant. Making INTEGER wider than the native word size necessarily sacrifices either 1) or 2). If all arithmetic were done in, say, double word size, there would be an efficiency penalty on it all. Not huge, but probably a factor of two for the best case of machine and operator. Integer arithmetic is especially sensitive to this kind of slowdown, since it is used in so many very basic ways. Any attempt at defining some system that does intermediate results conditionally in different sizes inevitably gets messy. Having two (or more) integer base types is about as simple as it can get. It satisfies 1) and gives a lot more slack before 4) becomes relevant. It gives programmers control over the efficiency/range tradeoff in a way that is about as simple to define as possible. Having different intermediate result sizes with the same base type gets a lot messier. To give satisfactory results, it would probably have to make types of operator expressions depend on how they are used, violating a fundamental principle of Modula-3. At best, I think the rules would be a lot more complicated that just having two integer base types. But anyone is welcome to prove me wrong with a proposal. Just be sure it completely defines all the type analysis and intermediate result size cases for the subranges, operators, and constant expressions, and allows programmers to control which size is used. And then see if it is simpler than separate integer types. Of course, there is always the library approach, like BigInteger It's much more flexible and much less efficient in general. Not to mention not as syntactically sweet. Two integer sizes seems like a good intermediate solution. Mika Nystrom wrote: > hendrik at topoi.pooq.com writes: >> On Fri, Apr 23, 2010 at 11:52:14AM -0700, Mika Nystrom wrote: >>> Is the infinite extent of the TEXT type a serious implementation difficulty? :-) >> Yes, actually. It requires heap storage allocation and indirection. That's just what >> it costs, so we pay it, since fixed-width strings aren't all that useful. >> >> But integer ranges of a size that matches the application (instead of the hardware) >> are quite feasible and useful; I'd rather not pay the proce of dynamic heap allocation >> for each integer. >> >> -- hendrik > > Ok here I have a proposal, modeled on how Modula-3 does arrays. > > The type specifier LONGINT to be valid in every context where an open > array is valid. > > A subrange of LONGINT to be treated like a non-open array. > > NEW(REF LONGINT, ..) would take two "size" specifiers, a minimum and a maximum, > of type LONGINT. > > For L, U, LONGINT literals, > > NEW(REF LONGINT, L, U) > > would produce the same thing as > > NEW(REF [L..U]) > > NEW(REF LONGINT, ..) is needed for dynamically sized LONGINTs. > > And then overload the arithmetic operations, the way arrays and REF RECORDs are, so > that for b and c REF LONGINT, > > b + c = b^ + c = b + c^ = b^ + c^ > > Assignments carry an implicit range check. > > Assignment rules the same as INTEGER and its subranges. > > Use VAL to convert...? > > In short, expressions involving LONGINT have type LONGINT, but no "bare" LONGINT can > ever be created. > > However note the following, perfectly legal. > > WITH a = b + c, > r = NEW(REF LONGINT, a, a) DO > r^ := a > END > > Also legal, note parameters: > > PROCEDURE Collatz(READONLY a : LONGINT; VAR b : LONGINT) = > BEGIN > CASE a MOD 2L OF > 0L => b := a DIV 2L > | > 1L => b := 3L * a + 1L > END > END Collatz; > > VALUE a : LONGINT would be discouraged. Returning LONGINT > would *not* be legal. ARRAY OF LONGINT would mean the LONGINTs > are limited to the same range, and used in NEW would take three > arguments, one of type INTEGER for the array size and two of type > LONGINT to specify the LONGINTs' bounds. > > Perhaps... > > PROCEDURE Collatz2(READONLY a : LONGINT; VAR b : LONGINT) > RAISES { Range } = > BEGIN > CASE a MOD 2L OF > 0L => b := a DIV 2L > | > 1L => > WITH new = 3L * a + 1L DO (* is new actually stored anywhere!? *) > IF new > LAST(b) THEN > RAISE Range > ELSE > b := new > END > END > END > END Collatz2; > > My proposal gives you both heap-allocated dynamically sized LONGINT and > stack-allocated fixed-sized longints and allows you to mix them at will. > Collatz2 does seem a little bit disturbing, however. Can we rely on > alloca "under the covers"? (Architectures that don't provide alloca > could heap-allocate new in that example, *if* they need to.) > > Another thing that occurs to me is that while + and - are straightforward, > *, DIV, and MOD are things you may well want to use very special and > specific algorithms for in a given application. It makes sense to let the > user replace the code for these operations. And now it begins to look > like C++. Sigh. > > Hendrik, I do think WITH causes similar problems even for strictly > range-limited numbers like the ones you are proposing? (And so does > expression evaluation, of course...) > > Now is it even reasonable to have this built in? What if the user wants > lazy evaluation? Are non-lazy LONGINTs very useful? > > Of course, I have to admit I am using a hardware simulation environment > where non-lazy LONGINTs would indeed be very useful. > > Mika > > From rodney_bates at lcwb.coop Tue Apr 27 18:41:43 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Tue, 27 Apr 2010 11:41:43 -0500 Subject: [M3devel] INTEGER In-Reply-To: <20100424103435.A1CC41A20C2@async.async.caltech.edu> References: <20100421185631.GA17051@topoi.pooq.com> <80775CA2-A2FD-40AF-B235-7DB84127762E@cs.purdue.edu> <20100422123805.GA19259@topoi.pooq.com> <87B45DCC-2B8A-4C69-97D7-240BC1E2252D@cs.purdue.edu> <20100422145522.GA19946@topoi.pooq.com> <28339030-6005-4C28-872C-A68CF24BF4DF@cs.purdue.edu> <20100422154357.GA20043@topoi.pooq.com> <270A99B5-173E-413B-8C28-E1CA68870FD4@cs.purdue.edu> <20100423094903.GC21281@topoi.pooq.com> <20100423185214.BA2EF1A20E1@async.async.caltech.edu> <20100423165613.GA22126@topoi.pooq.com> <20100424103435.A1CC41A20C2@async.async.caltech.edu> Message-ID: <4BD713C7.2060607@lcwb.coop> Mika Nystrom wrote: > hendrik at topoi.pooq.com writes: >> On Fri, Apr 23, 2010 at 11:52:14AM -0700, Mika Nystrom wrote: >>> Is the infinite extent of the TEXT type a serious implementation difficulty? :-) >> Yes, actually. It requires heap storage allocation and indirection. That's just what >> it costs, so we pay it, since fixed-width strings aren't all that useful. >> >> But integer ranges of a size that matches the application (instead of the hardware) >> are quite feasible and useful; I'd rather not pay the proce of dynamic heap allocation >> for each integer. >> >> -- hendrik > > Ok here I have a proposal, modeled on how Modula-3 does arrays. > > The type specifier LONGINT to be valid in every context where an open > array is valid. > > A subrange of LONGINT to be treated like a non-open array. > > NEW(REF LONGINT, ..) would take two "size" specifiers, a minimum and a maximum, > of type LONGINT. It would be better to call these "bounds". The implementation presumably needs to have a variable number of native words to hold values that is derived from, but different from the bounds. The word "size", plus the analogy to open arrays made me at first try to interpret these these specifiers as word counts. > > For L, U, LONGINT literals, > > NEW(REF LONGINT, L, U) Presumably, you want to allow the bounds above to be runtime expressions, not just literals. The WITH statement example below suggests so. > > would produce the same thing as > > NEW(REF [L..U]) But [L..U] by itself would require L and U to be constants, so [L..U] is analogous to a fixed array? > > NEW(REF LONGINT, ..) is needed for dynamically sized LONGINTs. > So, again in analogy to open arrays, a _variable_ of type LONGINT would have bounds that, although computable at runtime, remain unchanged for the lifetime of the variable? > And then overload the arithmetic operations, the way arrays and REF RECORDs are, so > that for b and c REF LONGINT, > > b + c = b^ + c = b + c^ = b^ + c^ Here is where the tough problem in intermediate results rears its ugly head. What is the type of b + c and what are the bounds of b + c? Each of b and c could be: Literals, which don't have any bounds defined at all, expressions of type [L..U], with static bounds, or LONGINT, with dynamic bounds. If b + c ends up having type LONGINT (i.e., not [L..U]), what are its bounds, which the type LONGINT doesn't specify. In the case where b and/or c have type LONGINT, is there a shape check analogy that requires b and c both to have the same bounds? Open arrays don't get into these problems because there are no operators that deliver a newly-computed open array result. You can only move values around, and that will never change the size/bounds. > > Assignments carry an implicit range check. > > Assignment rules the same as INTEGER and its subranges. > > Use VAL to convert...? > > In short, expressions involving LONGINT have type LONGINT, but no "bare" LONGINT can > ever be created. I can't intuit the meaning of "bare" LONGINT. > > However note the following, perfectly legal. > > WITH a = b + c, > r = NEW(REF LONGINT, a, a) DO > r^ := a > END > > Also legal, note parameters: > > PROCEDURE Collatz(READONLY a : LONGINT; VAR b : LONGINT) = > BEGIN > CASE a MOD 2L OF > 0L => b := a DIV 2L > | > 1L => b := 3L * a + 1L > END > END Collatz; > > VALUE a : LONGINT would be discouraged. Returning LONGINT > would *not* be legal. ARRAY OF LONGINT would mean the LONGINTs > are limited to the same range, and used in NEW would take three > arguments, one of type INTEGER for the array size and two of type > LONGINT to specify the LONGINTs' bounds. I haven't thought this through fully, but I think this is going to need: 1) ARRAY [c..d] OF LONGINT is not legal, (most interestingly as a formal parameter), analogous to the existing rule that ARRAY [c..d] OF ARRAY OF INTEGER is illegal. 2) An expanded subtype rule for open/fixed arrays of LONGINT/subrange-of-LONGINT, analogous the one existing rule for just open/fixed arrays. > > Perhaps... > > PROCEDURE Collatz2(READONLY a : LONGINT; VAR b : LONGINT) > RAISES { Range } = > BEGIN > CASE a MOD 2L OF > 0L => b := a DIV 2L In this case, a DIV 2L could lie below the lower end of the range of b. > | > 1L => > WITH new = 3L * a + 1L DO (* is new actually stored anywhere!? *) Yes, it would have to be ------------^ I take it from this example (and the open array analogy) that variables of type LONGINT, unlike BigInteger, can't grow in range by assigning to them. > IF new > LAST(b) THEN > RAISE Range > ELSE > b := new > END > END > END > END Collatz2; > > My proposal gives you both heap-allocated dynamically sized LONGINT and > stack-allocated fixed-sized longints and allows you to mix them at will. > Collatz2 does seem a little bit disturbing, however. Can we rely on > alloca "under the covers"? (Architectures that don't provide alloca > could heap-allocate new in that example, *if* they need to.) I am not half as bothered by the implementation problem of allocating space for dynamically-sized temporaries as by defining the language rules for what the bounds/sizes are. If you say an intermediate result such as b + c has bounds that come from the bounds of b and c, then you lose my property 3) in my previous, general post. That is, you lose the property that INTEGER and its subranges currently have, that the intermediate result is the biggest possible without expanding into more memory and paying a performance penalty. If you try to preserve this property and allow intermediate results to occupy as much space as the operands do, then you have to expose into the language semantics, the mapping between bounds, which the programmer is aware of, and representation sizes (probably native word counts). This gets complicated really fast. If you make intermediate results unbounded and fully dynamic, i.e., as big as needed to hold the computed value, then you don't have an open array analogue any more, you have BigInteger, which has its own pros and cons, but is a quite different abstraction. This is further complicated by the fact that LONGINT literals don't have either defined bounds or defined representation size, so how do you specify these properties of intermediate results when an operand is a literal? This will probably lose the long-standing principles that an expression has an unambiguous, unique type, and that does not depend on how the expression is used. Only the BigInteger approach seems to work here. To make VAL reasonably usable for programmer-specified range changes, which will definitely be needed, you will probably have to allow for arithmetic where both operands are literals, as well as declarations of named constants with values specified in this way. And it all is probably complicated by the distinction that the bounds bounds are static and part of the type, (as for type [L..U]), but dynamic and part of the value (as for LONGINT), > > Another thing that occurs to me is that while + and - are straightforward, > *, DIV, and MOD are things you may well want to use very special and > specific algorithms for in a given application. It makes sense to let the > user replace the code for these operations. And now it begins to look > like C++. Sigh. > > Hendrik, I do think WITH causes similar problems even for strictly > range-limited numbers like the ones you are proposing? (And so does > expression evaluation, of course...) > > Now is it even reasonable to have this built in? What if the user wants > lazy evaluation? Are non-lazy LONGINTs very useful? > > Of course, I have to admit I am using a hardware simulation environment > where non-lazy LONGINTs would indeed be very useful. > > Mika > > Perhaps what you really want is to replace the two-member set {INTEGER, LONGINT} with an unbounded set of multi-word arithmetics, for different word counts. To do this and keep the (relative) semantic integrity of {INTEGER, LONGINT}, you would need to make each size a distinct base type. But then, I fear it would be very difficult to have open-array-like formal parameters and heap objects. We, of course, don't have anything like this with INTEGER, LONGINT}. From mika at async.async.caltech.edu Tue Apr 27 19:24:00 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Tue, 27 Apr 2010 10:24:00 -0700 Subject: [M3devel] INTEGER In-Reply-To: <4BD713C7.2060607@lcwb.coop> References: <20100421185631.GA17051@topoi.pooq.com> <80775CA2-A2FD-40AF-B235-7DB84127762E@cs.purdue.edu> <20100422123805.GA19259@topoi.pooq.com> <87B45DCC-2B8A-4C69-97D7-240BC1E2252D@cs.purdue.edu> <20100422145522.GA19946@topoi.pooq.com> <28339030-6005-4C28-872C-A68CF24BF4DF@cs.purdue.edu> <20100422154357.GA20043@topoi.pooq.com> <270A99B5-173E-413B-8C28-E1CA68870FD4@cs.purdue.edu> <20100423094903.GC21281@topoi.pooq.com> <20100423185214.BA2EF1A20E1@async.async.caltech.edu> <20100423165613.GA22126@topoi.pooq.com> <20100424103435.A1CC41A20C2@async.async.caltech.edu> <4BD713C7.2060607@lcwb.coop> Message-ID: <20100427172400.D491F1A2096@async.async.caltech.edu> Hi Rodney, Yes most of what you write is exactly as I was thinking too. It is a bit odd that you can't have ARRAY OF LONGINT. You can have ARRAY OF REF LONGINT, though. You say the subtyping rule for open/fixed arrays has to be expanded. Can you expand on this statement? I am not worried as you are by the range problem. The saving grace is that the language has very few arithmetic operators on integers. + - * DIV MOD. It's not hard to do range arithmetic on these such that one can easily figure out how much memory is required to hold intermediate results. If you're happy with alloca (I don't mind it), that's what you do. You have three options in so far as calculating the required space: 1. For known subranges of LONGINT, do it at compile time (no alloca required) 2. For "open" LONGINTs, at runtime, based on the passed-in types 3. For "open" LONGINTs, at runtime, based on the passed-in values Now as I said the proposal is that variables can themselves not be of type LONGINT but only subranges thereof. That means you can get away with stack allocation and don't need to do heap allocation. Since you bring up BigInteger, yes, it's precisely BigInteger, except the fact that since variables are always of fixed range, you can do it completely on the stack (as long as you are allowed to use alloca). The "type" of a longint literal x can be [x..x]. Mika "Rodney M. Bates" writes: > > >Mika Nystrom wrote: >> hendrik at topoi.pooq.com writes: >>> On Fri, Apr 23, 2010 at 11:52:14AM -0700, Mika Nystrom wrote: >>>> Is the infinite extent of the TEXT type a serious implementation difficult >y? :-) >>> Yes, actually. It requires heap storage allocation and indirection. That' >s just what >>> it costs, so we pay it, since fixed-width strings aren't all that useful. >>> >>> But integer ranges of a size that matches the application (instead of the h >ardware) >>> are quite feasible and useful; I'd rather not pay the proce of dynamic heap > allocation >>> for each integer. >>> >>> -- hendrik >> >> Ok here I have a proposal, modeled on how Modula-3 does arrays. >> >> The type specifier LONGINT to be valid in every context where an open >> array is valid. >> >> A subrange of LONGINT to be treated like a non-open array. >> >> NEW(REF LONGINT, ..) would take two "size" specifiers, a minimum and a maxim >um, >> of type LONGINT. > >It would be better to call these "bounds". The implementation presumably need >s >to have a variable number of native words to hold values that is derived from, >but different from the bounds. The word "size", plus the analogy to open arra >ys >made me at first try to interpret these these specifiers as word counts. > >> >> For L, U, LONGINT literals, >> >> NEW(REF LONGINT, L, U) > >Presumably, you want to allow the bounds above to be runtime >expressions, not just literals. The WITH statement example below >suggests so. > >> >> would produce the same thing as >> >> NEW(REF [L..U]) > >But [L..U] by itself would require L and U to be constants, so >[L..U] is analogous to a fixed array? > >> >> NEW(REF LONGINT, ..) is needed for dynamically sized LONGINTs. >> > >So, again in analogy to open arrays, a _variable_ of type LONGINT would >have bounds that, although computable at runtime, remain unchanged for >the lifetime of the variable? > >> And then overload the arithmetic operations, the way arrays and REF RECORDs >are, so >> that for b and c REF LONGINT, >> >> b + c = b^ + c = b + c^ = b^ + c^ > >Here is where the tough problem in intermediate results rears its ugly head. >What is the type of b + c and what are the bounds of b + c? Each of b and c >could be: Literals, which don't have any bounds defined at all, expressions >of type [L..U], with static bounds, or LONGINT, with dynamic bounds. > >If b + c ends up having type LONGINT (i.e., not [L..U]), what are its bounds, >which the type LONGINT doesn't specify. > >In the case where b and/or c have type LONGINT, is there a shape check analogy >that requires b and c both to have the same bounds? > >Open arrays don't get into these problems because there are no operators that >deliver a newly-computed open array result. You can only move values around, >and that will never change the size/bounds. > >> >> Assignments carry an implicit range check. >> >> Assignment rules the same as INTEGER and its subranges. >> >> Use VAL to convert...? >> >> In short, expressions involving LONGINT have type LONGINT, but no "bare" LON >GINT can >> ever be created. > >I can't intuit the meaning of "bare" LONGINT. >> >> However note the following, perfectly legal. >> >> WITH a = b + c, >> r = NEW(REF LONGINT, a, a) DO >> r^ := a >> END >> >> Also legal, note parameters: >> >> PROCEDURE Collatz(READONLY a : LONGINT; VAR b : LONGINT) = >> BEGIN >> CASE a MOD 2L OF >> 0L => b := a DIV 2L >> | >> 1L => b := 3L * a + 1L >> END >> END Collatz; >> >> VALUE a : LONGINT would be discouraged. Returning LONGINT >> would *not* be legal. ARRAY OF LONGINT would mean the LONGINTs >> are limited to the same range, and used in NEW would take three >> arguments, one of type INTEGER for the array size and two of type >> LONGINT to specify the LONGINTs' bounds. > >I haven't thought this through fully, but I think this is going to need: > >1) ARRAY [c..d] OF LONGINT is not legal, (most interestingly as a formal param >eter), > analogous to the existing rule that ARRAY [c..d] OF ARRAY OF INTEGER is il >legal. > >2) An expanded subtype rule for open/fixed arrays of LONGINT/subrange-of-LONGI >NT, > analogous the one existing rule for just open/fixed arrays. > >> >> Perhaps... >> >> PROCEDURE Collatz2(READONLY a : LONGINT; VAR b : LONGINT) >> RAISES { Range } = >> BEGIN >> CASE a MOD 2L OF >> 0L => b := a DIV 2L > >In this case, a DIV 2L could lie below the lower end of the range of b. > >> | >> 1L => >> WITH new = 3L * a + 1L DO (* is new actually stored anywhere!? *) > >Yes, it would have to be ------------^ > >I take it from this example (and the open array analogy) that variables >of type LONGINT, unlike BigInteger, can't grow in range by assigning to them. > >> IF new > LAST(b) THEN >> RAISE Range >> ELSE >> b := new >> END >> END >> END >> END Collatz2; >> >> My proposal gives you both heap-allocated dynamically sized LONGINT and >> stack-allocated fixed-sized longints and allows you to mix them at will. >> Collatz2 does seem a little bit disturbing, however. Can we rely on >> alloca "under the covers"? (Architectures that don't provide alloca >> could heap-allocate new in that example, *if* they need to.) > >I am not half as bothered by the implementation problem of allocating >space for dynamically-sized temporaries as by defining the language rules >for what the bounds/sizes are. If you say an intermediate result such as >b + c has bounds that come from the bounds of b and c, then you lose my >property 3) in my previous, general post. That is, you lose the >property that INTEGER and its subranges currently have, that the intermediate >result is the biggest possible without expanding into more memory and >paying a performance penalty. > >If you try to preserve this property and allow intermediate results to >occupy as much space as the operands do, then you have to expose into the >language semantics, the mapping between bounds, which the programmer >is aware of, and representation sizes (probably native word counts). >This gets complicated really fast. > >If you make intermediate results unbounded and fully dynamic, i.e., as big >as needed to hold the computed value, then you don't have an open array >analogue any more, you have BigInteger, which has its own pros and cons, >but is a quite different abstraction. > >This is further complicated by the fact that LONGINT literals don't have >either defined bounds or defined representation size, so how do you >specify these properties of intermediate results when an operand is >a literal? This will probably lose the long-standing principles that >an expression has an unambiguous, unique type, and that does not depend on >how the expression is used. Only the BigInteger approach seems to work here. > >To make VAL reasonably usable for programmer-specified range changes, which wi >ll >definitely be needed, you will probably have to allow for arithmetic where bot >h >operands are literals, as well as declarations of named constants with >values specified in this way. > >And it all is probably complicated by the distinction that the bounds >bounds are static and part of the type, (as for type [L..U]), but dynamic >and part of the value (as for LONGINT), > > >> >> Another thing that occurs to me is that while + and - are straightforward, >> *, DIV, and MOD are things you may well want to use very special and >> specific algorithms for in a given application. It makes sense to let the >> user replace the code for these operations. And now it begins to look >> like C++. Sigh. >> >> Hendrik, I do think WITH causes similar problems even for strictly >> range-limited numbers like the ones you are proposing? (And so does >> expression evaluation, of course...) >> >> Now is it even reasonable to have this built in? What if the user wants >> lazy evaluation? Are non-lazy LONGINTs very useful? >> >> Of course, I have to admit I am using a hardware simulation environment >> where non-lazy LONGINTs would indeed be very useful. >> >> Mika >> >> > >Perhaps what you really want is to replace the two-member set {INTEGER, LONGIN >T} >with an unbounded set of multi-word arithmetics, for different word counts. > >To do this and keep the (relative) semantic integrity of {INTEGER, LONGINT}, >you would need to make each size a distinct base type. But then, I fear it >would be very difficult to have open-array-like formal parameters and >heap objects. We, of course, don't have anything like this with INTEGER, LONG >INT}. From mika at async.async.caltech.edu Tue Apr 27 19:30:36 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Tue, 27 Apr 2010 10:30:36 -0700 Subject: [M3devel] INTEGER In-Reply-To: <20100427172400.D491F1A2096@async.async.caltech.edu> References: <20100421185631.GA17051@topoi.pooq.com> <80775CA2-A2FD-40AF-B235-7DB84127762E@cs.purdue.edu> <20100422123805.GA19259@topoi.pooq.com> <87B45DCC-2B8A-4C69-97D7-240BC1E2252D@cs.purdue.edu> <20100422145522.GA19946@topoi.pooq.com> <28339030-6005-4C28-872C-A68CF24BF4DF@cs.purdue.edu> <20100422154357.GA20043@topoi.pooq.com> <270A99B5-173E-413B-8C28-E1CA68870FD4@cs.purdue.edu> <20100423094903.GC21281@topoi.pooq.com> <20100423185214.BA2EF1A20E1@async.async.caltech.edu> <20100423165613.GA22126@topoi.pooq.com> <20100424103435.A1CC41A20C2@async.async.caltech.edu> <4BD713C7.2060607@lcwb.coop> <20100427172400.D491F1A2096@async.async.caltech.edu> Message-ID: <20100427173036.7DC501A2096@async.async.caltech.edu> Mika Nystrom writes: ... >I am not worried as you are by the range problem. The saving grace is >that the language has very few arithmetic operators on integers. >+ - * DIV MOD. It's not hard to do range arithmetic on these such that >one can easily figure out how much memory is required to hold intermediate >results. If you're happy with alloca (I don't mind it), that's what >you do. You have three options in so far as calculating the required >space: ... To clarify a bit further, my proposal is that the ranges be lost in the evaluation. Everything in the expression is simply of type LONGINT. When the final result is assigned to a variable, there is a range check (which can be dispensed with if the compiler can prove that there can be no overrun). Isn't this how INTEGER subranges work? a : [0..2]; b : [0..1]; a := 4*b - 2*b Mika From jay.krell at cornell.edu Tue Apr 27 19:55:12 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 27 Apr 2010 17:55:12 +0000 Subject: [M3devel] INTEGER In-Reply-To: <20100427172400.D491F1A2096@async.async.caltech.edu> References: <20100421185631.GA17051@topoi.pooq.com>, <80775CA2-A2FD-40AF-B235-7DB84127762E@cs.purdue.edu>, <20100422123805.GA19259@topoi.pooq.com>, <87B45DCC-2B8A-4C69-97D7-240BC1E2252D@cs.purdue.edu>, <20100422145522.GA19946@topoi.pooq.com>, <28339030-6005-4C28-872C-A68CF24BF4DF@cs.purdue.edu>, <20100422154357.GA20043@topoi.pooq.com>, <270A99B5-173E-413B-8C28-E1CA68870FD4@cs.purdue.edu>, <20100423094903.GC21281@topoi.pooq.com>, <20100423185214.BA2EF1A20E1@async.async.caltech.edu>, <20100423165613.GA22126@topoi.pooq.com>, <20100424103435.A1CC41A20C2@async.async.caltech.edu>, <4BD713C7.2060607@lcwb.coop>, <20100427172400.D491F1A2096@async.async.caltech.edu> Message-ID: > Since you bring up BigInteger, yes, it's precisely BigInteger, except > the fact that since variables are always of fixed range, you can do it > completely on the stack (as long as you are allowed to use alloca). You could implement a generic biginteger parameterized by how many bits/bytes/integers of precision it has and therefore be a fixed small size. Target.Int for example always has 64 bits, which is determined on roughly one line (ie: almost "generic"). When you read through the various multiprecision libraries, you often find likewise two such sets of types/functions -- fixed precision and precision that grows to fit values. ?- Jay ---------------------------------------- > To: rodney_bates at lcwb.coop > Date: Tue, 27 Apr 2010 10:24:00 -0700 > From: mika at async.async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] INTEGER > > Hi Rodney, > > Yes most of what you write is exactly as I was thinking too. > It is a bit odd that you can't have ARRAY OF LONGINT. You can have > ARRAY OF REF LONGINT, though. > > You say the subtyping rule for open/fixed arrays has to be expanded. > Can you expand on this statement? > > I am not worried as you are by the range problem. The saving grace is > that the language has very few arithmetic operators on integers. > + - * DIV MOD. It's not hard to do range arithmetic on these such that > one can easily figure out how much memory is required to hold intermediate > results. If you're happy with alloca (I don't mind it), that's what > you do. You have three options in so far as calculating the required > space: > > 1. For known subranges of LONGINT, do it at compile time (no alloca > required) > 2. For "open" LONGINTs, at runtime, based on the passed-in types > 3. For "open" LONGINTs, at runtime, based on the passed-in values > > Now as I said the proposal is that variables can themselves not be of > type LONGINT but only subranges thereof. That means you can get away > with stack allocation and don't need to do heap allocation. > > Since you bring up BigInteger, yes, it's precisely BigInteger, except > the fact that since variables are always of fixed range, you can do it > completely on the stack (as long as you are allowed to use alloca). > > The "type" of a longint literal x can be [x..x]. > > Mika > > > "Rodney M. Bates" writes: >> >> >>Mika Nystrom wrote: >>> hendrik at topoi.pooq.com writes: >>>> On Fri, Apr 23, 2010 at 11:52:14AM -0700, Mika Nystrom wrote: >>>>> Is the infinite extent of the TEXT type a serious implementation difficult >>y? :-) >>>> Yes, actually. It requires heap storage allocation and indirection. That' >>s just what >>>> it costs, so we pay it, since fixed-width strings aren't all that useful. >>>> >>>> But integer ranges of a size that matches the application (instead of the h >>ardware) >>>> are quite feasible and useful; I'd rather not pay the proce of dynamic heap >> allocation >>>> for each integer. >>>> >>>> -- hendrik >>> >>> Ok here I have a proposal, modeled on how Modula-3 does arrays. >>> >>> The type specifier LONGINT to be valid in every context where an open >>> array is valid. >>> >>> A subrange of LONGINT to be treated like a non-open array. >>> >>> NEW(REF LONGINT, ..) would take two "size" specifiers, a minimum and a maxim >>um, >>> of type LONGINT. >> >>It would be better to call these "bounds". The implementation presumably need >>s >>to have a variable number of native words to hold values that is derived from, >>but different from the bounds. The word "size", plus the analogy to open arra >>ys >>made me at first try to interpret these these specifiers as word counts. >> >>> >>> For L, U, LONGINT literals, >>> >>> NEW(REF LONGINT, L, U) >> >>Presumably, you want to allow the bounds above to be runtime >>expressions, not just literals. The WITH statement example below >>suggests so. >> >>> >>> would produce the same thing as >>> >>> NEW(REF [L..U]) >> >>But [L..U] by itself would require L and U to be constants, so >>[L..U] is analogous to a fixed array? >> >>> >>> NEW(REF LONGINT, ..) is needed for dynamically sized LONGINTs. >>> >> >>So, again in analogy to open arrays, a _variable_ of type LONGINT would >>have bounds that, although computable at runtime, remain unchanged for >>the lifetime of the variable? >> >>> And then overload the arithmetic operations, the way arrays and REF RECORDs >>are, so >>> that for b and c REF LONGINT, >>> >>> b + c = b^ + c = b + c^ = b^ + c^ >> >>Here is where the tough problem in intermediate results rears its ugly head. >>What is the type of b + c and what are the bounds of b + c? Each of b and c >>could be: Literals, which don't have any bounds defined at all, expressions >>of type [L..U], with static bounds, or LONGINT, with dynamic bounds. >> >>If b + c ends up having type LONGINT (i.e., not [L..U]), what are its bounds, >>which the type LONGINT doesn't specify. >> >>In the case where b and/or c have type LONGINT, is there a shape check analogy >>that requires b and c both to have the same bounds? >> >>Open arrays don't get into these problems because there are no operators that >>deliver a newly-computed open array result. You can only move values around, >>and that will never change the size/bounds. >> >>> >>> Assignments carry an implicit range check. >>> >>> Assignment rules the same as INTEGER and its subranges. >>> >>> Use VAL to convert...? >>> >>> In short, expressions involving LONGINT have type LONGINT, but no "bare" LON >>GINT can >>> ever be created. >> >>I can't intuit the meaning of "bare" LONGINT. >>> >>> However note the following, perfectly legal. >>> >>> WITH a = b + c, >>> r = NEW(REF LONGINT, a, a) DO >>> r^ := a >>> END >>> >>> Also legal, note parameters: >>> >>> PROCEDURE Collatz(READONLY a : LONGINT; VAR b : LONGINT) = >>> BEGIN >>> CASE a MOD 2L OF >>> 0L => b := a DIV 2L >>> | >>> 1L => b := 3L * a + 1L >>> END >>> END Collatz; >>> >>> VALUE a : LONGINT would be discouraged. Returning LONGINT >>> would *not* be legal. ARRAY OF LONGINT would mean the LONGINTs >>> are limited to the same range, and used in NEW would take three >>> arguments, one of type INTEGER for the array size and two of type >>> LONGINT to specify the LONGINTs' bounds. >> >>I haven't thought this through fully, but I think this is going to need: >> >>1) ARRAY [c..d] OF LONGINT is not legal, (most interestingly as a formal param >>eter), >> analogous to the existing rule that ARRAY [c..d] OF ARRAY OF INTEGER is il >>legal. >> >>2) An expanded subtype rule for open/fixed arrays of LONGINT/subrange-of-LONGI >>NT, >> analogous the one existing rule for just open/fixed arrays. >> >>> >>> Perhaps... >>> >>> PROCEDURE Collatz2(READONLY a : LONGINT; VAR b : LONGINT) >>> RAISES { Range } = >>> BEGIN >>> CASE a MOD 2L OF >>> 0L => b := a DIV 2L >> >>In this case, a DIV 2L could lie below the lower end of the range of b. >> >>> | >>> 1L => >>> WITH new = 3L * a + 1L DO (* is new actually stored anywhere!? *) >> >>Yes, it would have to be ------------^ >> >>I take it from this example (and the open array analogy) that variables >>of type LONGINT, unlike BigInteger, can't grow in range by assigning to them. >> >>> IF new> LAST(b) THEN >>> RAISE Range >>> ELSE >>> b := new >>> END >>> END >>> END >>> END Collatz2; >>> >>> My proposal gives you both heap-allocated dynamically sized LONGINT and >>> stack-allocated fixed-sized longints and allows you to mix them at will. >>> Collatz2 does seem a little bit disturbing, however. Can we rely on >>> alloca "under the covers"? (Architectures that don't provide alloca >>> could heap-allocate new in that example, *if* they need to.) >> >>I am not half as bothered by the implementation problem of allocating >>space for dynamically-sized temporaries as by defining the language rules >>for what the bounds/sizes are. If you say an intermediate result such as >>b + c has bounds that come from the bounds of b and c, then you lose my >>property 3) in my previous, general post. That is, you lose the >>property that INTEGER and its subranges currently have, that the intermediate >>result is the biggest possible without expanding into more memory and >>paying a performance penalty. >> >>If you try to preserve this property and allow intermediate results to >>occupy as much space as the operands do, then you have to expose into the >>language semantics, the mapping between bounds, which the programmer >>is aware of, and representation sizes (probably native word counts). >>This gets complicated really fast. >> >>If you make intermediate results unbounded and fully dynamic, i.e., as big >>as needed to hold the computed value, then you don't have an open array >>analogue any more, you have BigInteger, which has its own pros and cons, >>but is a quite different abstraction. >> >>This is further complicated by the fact that LONGINT literals don't have >>either defined bounds or defined representation size, so how do you >>specify these properties of intermediate results when an operand is >>a literal? This will probably lose the long-standing principles that >>an expression has an unambiguous, unique type, and that does not depend on >>how the expression is used. Only the BigInteger approach seems to work here. >> >>To make VAL reasonably usable for programmer-specified range changes, which wi >>ll >>definitely be needed, you will probably have to allow for arithmetic where bot >>h >>operands are literals, as well as declarations of named constants with >>values specified in this way. >> >>And it all is probably complicated by the distinction that the bounds >>bounds are static and part of the type, (as for type [L..U]), but dynamic >>and part of the value (as for LONGINT), >> >> >>> >>> Another thing that occurs to me is that while + and - are straightforward, >>> *, DIV, and MOD are things you may well want to use very special and >>> specific algorithms for in a given application. It makes sense to let the >>> user replace the code for these operations. And now it begins to look >>> like C++. Sigh. >>> >>> Hendrik, I do think WITH causes similar problems even for strictly >>> range-limited numbers like the ones you are proposing? (And so does >>> expression evaluation, of course...) >>> >>> Now is it even reasonable to have this built in? What if the user wants >>> lazy evaluation? Are non-lazy LONGINTs very useful? >>> >>> Of course, I have to admit I am using a hardware simulation environment >>> where non-lazy LONGINTs would indeed be very useful. >>> >>> Mika >>> >>> >> >>Perhaps what you really want is to replace the two-member set {INTEGER, LONGIN >>T} >>with an unbounded set of multi-word arithmetics, for different word counts. >> >>To do this and keep the (relative) semantic integrity of {INTEGER, LONGINT}, >>you would need to make each size a distinct base type. But then, I fear it >>would be very difficult to have open-array-like formal parameters and >>heap objects. We, of course, don't have anything like this with INTEGER, LONG >>INT}. From hosking at cs.purdue.edu Wed Apr 28 03:51:53 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 27 Apr 2010 21:51:53 -0400 Subject: [M3devel] cooperative suspend? In-Reply-To: References: Message-ID: <19A8CA05-F586-4F54-8BAF-10BACFB1C45C@cs.purdue.edu> Ultimately we don't really want stop-the-world at all. What we really need is per-thread suspension. For scalability we should be aiming to stop threads individually rather than all at once. This means some sort of per-thread (local) mechanism. On 27 Apr 2010, at 05:01, Jay K wrote: > > cooperative suspend > > > Tony, you mind if I take a stab at "cooperative suspend" > fairly soon? > I can't find a good way to suspend threads on VMS. > Or even get context in a signal handler. > It will be a boolen in Target.i3, so no existing targets affected. > Of course I'll test it on an existing target with the boolean set wrong. :) > > > To optimize size instead of speed, I think the "every so often > extra generated code" should be a call to a parameter-less function. > Instead of checking a per-thread or global variable. > > Something like: > > > VAR threadRequestingSuspend: ADDRESS; > > > PROCEDURE Thread.PollSuspend() > BEGIN > IF threadRequestingSuspend = NIL THEN RETURN END; > PollSuspendSlow(); > END PollSuspend; > > > (* This is split to avoid needing a frame in PollSuspend. *) > PROCEDURE PollSuspendSlow() > VAR self: ADDRESS; > BEGIN > IF threadRequestingSuspend = NIL THEN RETURN END; > self := GetActivation(); > IF self = threadRequestingSuspend THEN RETURN END; (* important consideration! *) > GetContext(self.context); (* roughly *) > self.suspended := TRUE; (* roughly *) > WaitForResume(); (* details to be determined, either the semaphore > * or maybe acquire per-thread lock. *) > END PollSuspendSlow; > > > The poll call could also be a function pointer and usually point to a function that does nothing. > But that'd require loading the address from a global, and calling it. > Probably more bloat than calling direct instead of indirect. > > > - Jay > From jay.krell at cornell.edu Wed Apr 28 05:32:08 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 28 Apr 2010 03:32:08 +0000 Subject: [M3devel] cooperative suspend? In-Reply-To: <19A8CA05-F586-4F54-8BAF-10BACFB1C45C@cs.purdue.edu> References: , <19A8CA05-F586-4F54-8BAF-10BACFB1C45C@cs.purdue.edu> Message-ID: Ok. I still like calling a parameter-less function for code size. That would lead to perhaps, if any number of threads can be suspended, and compatible with current direction of suspending all of them: VAR anyThreadsBeingSuspended: BOOLEAN; PROCEDURE PollSuspend() = BEGIN IF anyThreadsBeingSuspended = FALSE THEN RETURN END; PollSuspendSlow(); END PollSuspend; PROCEDURE PollSuspendSlow() = VAR self := GetActivation(); BEGIN IF NOT self.suspend THEN RETURN END; .. more stuff here .. END PollSuspendSlow; or if only one suspend would be requested a time: VAR threadToSuspend: ADDRESS; PROCEDURE PollSuspend() = BEGIN IF threadToSuspend = NIL THEN RETURN END; PollSuspendSlow(); END PollSuspend; PROCEDURE PollSuspendSlow() = VAR self := GetActivation(); BEGIN IF self <> threadToSuspend THEN RETURN END; .. more stuff here .. END PollSuspendSlow; I imagine what is "really" ideal is to request 1 or more threads to suspend, and then in the "more stuff here", they tell the requester they have suspended. ? That way, if some thread takes a while to suspend, the whole process isn't backed up behind it. ? That would would favor my first exposition (with per thread self.suspend boolean). Which fits current scheme in that you'd just set them all to true. - Jay ---------------------------------------- > From: hosking at cs.purdue.edu > Date: Tue, 27 Apr 2010 21:51:53 -0400 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] cooperative suspend? > > Ultimately we don't really want stop-the-world at all. What we really need is per-thread suspension. For scalability we should be aiming to stop threads individually rather than all at once. This means some sort of per-thread (local) mechanism. > > On 27 Apr 2010, at 05:01, Jay K wrote: > >> >> cooperative suspend >> >> >> Tony, you mind if I take a stab at "cooperative suspend" >> fairly soon? >> I can't find a good way to suspend threads on VMS. >> Or even get context in a signal handler. >> It will be a boolen in Target.i3, so no existing targets affected. >> Of course I'll test it on an existing target with the boolean set wrong. :) >> >> >> To optimize size instead of speed, I think the "every so often >> extra generated code" should be a call to a parameter-less function. >> Instead of checking a per-thread or global variable. >> >> Something like: >> >> >> VAR threadRequestingSuspend: ADDRESS; >> >> >> PROCEDURE Thread.PollSuspend() >> BEGIN >> IF threadRequestingSuspend = NIL THEN RETURN END; >> PollSuspendSlow(); >> END PollSuspend; >> >> >> (* This is split to avoid needing a frame in PollSuspend. *) >> PROCEDURE PollSuspendSlow() >> VAR self: ADDRESS; >> BEGIN >> IF threadRequestingSuspend = NIL THEN RETURN END; >> self := GetActivation(); >> IF self = threadRequestingSuspend THEN RETURN END; (* important consideration! *) >> GetContext(self.context); (* roughly *) >> self.suspended := TRUE; (* roughly *) >> WaitForResume(); (* details to be determined, either the semaphore >> * or maybe acquire per-thread lock. *) >> END PollSuspendSlow; >> >> >> The poll call could also be a function pointer and usually point to a function that does nothing. >> But that'd require loading the address from a global, and calling it. >> Probably more bloat than calling direct instead of indirect. >> >> >> - Jay >> > From wagner at elegosoft.com Wed Apr 28 10:40:44 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 28 Apr 2010 10:40:44 +0200 Subject: [M3devel] Fwd: Re: [CM3] #1084: CM3 for Solaris X86? Message-ID: <20100428104044.14rqktckgk0w8kws@mail.elegosoft.com> Seems to have been discarded, so I forward it explicitly. Anybody interested? Olaf ----- Forwarded message from bugs at elego.de ----- Date: Wed, 28 Apr 2010 08:31:06 -0000 From: CM3 Reply-To: CM3 Subject: Re: [CM3] #1084: CM3 for Solaris X86? To: @MISSING_DOMAIN #1084: CM3 for Solaris X86? -------------------------------+-------------------------------------------- Reporter: risaac@? | Owner: wagner Type: sw-feature | Status: new Priority: medium | Milestone: CM3 Release 5.9 Component: installation | Version: 5.8-RC2 Severity: non-critical | Keywords: solaris x86 Relnote: | Confidential: no Org: | Estimatedhours: 0 Hours: 0 | Billable: 0 Totalhours: 0 | Internal: 0 -------------------------------+-------------------------------------------- Htr: Fix: Env: Solaris 10 x86: SunOS localhost 5.10 Generic_137138-09 i86pc i386 i86pc -------------------------------+-------------------------------------------- Changes (by wagner): * cc: m3devel@? (added) * milestone: => CM3 Release 5.9 Comment: Solaris for x86 probably wouldn't be difficult to add, as both operating system specific code and processor specific code should already be there. None of the developers seems to have set up such a system yet though. For more than a short-time availability and from a release engineering point of view the acquiration of an appropriate build and test server (preferrably working as a Hudson slave) would be important. So if you or one of the cm3 developers can arrange to place such a machine at Hudson's disposal (will generate some load now and then), that would be a great start. Jay Krell has a whole zoo of hardware/OS setup; I'm not sure if he's interested and willing to provide one more. But of course this request should not be restricted to his person, but to all who may be interested (CC'ed to m3devel for this purpose). A (virtual) machine with remote ssh access for an ordinary user should be all that is needed for a CM3 deveoper to add the target platform and for Hudson to run builds and tests. -- Ticket URL: CM3 Critical Mass Modula3 Compiler ----- End forwarded message ----- -- 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 Apr 28 16:22:55 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 28 Apr 2010 10:22:55 -0400 Subject: [M3devel] cooperative suspend? In-Reply-To: References: , <19A8CA05-F586-4F54-8BAF-10BACFB1C45C@cs.purdue.edu> Message-ID: <8E176F01-29AD-4A64-8395-966AE9A19181@cs.purdue.edu> On 27 Apr 2010, at 23:32, Jay K wrote: > > Ok. I still like calling a parameter-less function for code size. > > > That would lead to perhaps, if any number of threads can be suspended, > and compatible with current direction of suspending all of them: > > > VAR anyThreadsBeingSuspended: BOOLEAN; We could have a global array with an entry/bit per thread. It would limit the number of total threads (because we'd want it statically allocated), but has the advantage that we never divert threads that don't need to suspend. > PROCEDURE PollSuspend() = > BEGIN > IF anyThreadsBeingSuspended = FALSE THEN RETURN END; > PollSuspendSlow(); > END PollSuspend; We could easily inline the pollcheck using the compiler. > PROCEDURE PollSuspendSlow() = > VAR self := GetActivation(); > BEGIN > IF NOT self.suspend THEN RETURN END; > .. more stuff here .. > END PollSuspendSlow; > > > or if only one suspend would be requested a time: > > > VAR threadToSuspend: ADDRESS; Ultimately we want more than just suspend. We really want pairwise handshakes between threads, with the possibility of many in flight simultaneously. This gives us the ability to do biased lock revocation very efficiently. > PROCEDURE PollSuspend() = > BEGIN > IF threadToSuspend = NIL THEN RETURN END; > PollSuspendSlow(); > END PollSuspend; > > > PROCEDURE PollSuspendSlow() = > VAR self := GetActivation(); > BEGIN > IF self <> threadToSuspend THEN RETURN END; > .. more stuff here .. > END PollSuspendSlow; > > > I imagine what is "really" ideal is to request 1 or more threads to suspend, and then in the "more stuff here", they tell the requester they have suspended. ? Yeah, or simply deliver an ack that they have seen the event. > That way, if some thread takes a while to suspend, the whole process isn't backed up behind it. ? Exactly. > That would would favor my first exposition (with per thread self.suspend boolean). > Which fits current scheme in that you'd just set them all to true. Yes, that would work. I like it. > > > > - Jay > > > ---------------------------------------- >> From: hosking at cs.purdue.edu >> Date: Tue, 27 Apr 2010 21:51:53 -0400 >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] cooperative suspend? >> >> Ultimately we don't really want stop-the-world at all. What we really need is per-thread suspension. For scalability we should be aiming to stop threads individually rather than all at once. This means some sort of per-thread (local) mechanism. >> >> On 27 Apr 2010, at 05:01, Jay K wrote: >> >>> >>> cooperative suspend >>> >>> >>> Tony, you mind if I take a stab at "cooperative suspend" >>> fairly soon? >>> I can't find a good way to suspend threads on VMS. >>> Or even get context in a signal handler. >>> It will be a boolen in Target.i3, so no existing targets affected. >>> Of course I'll test it on an existing target with the boolean set wrong. :) >>> >>> >>> To optimize size instead of speed, I think the "every so often >>> extra generated code" should be a call to a parameter-less function. >>> Instead of checking a per-thread or global variable. >>> >>> Something like: >>> >>> >>> VAR threadRequestingSuspend: ADDRESS; >>> >>> >>> PROCEDURE Thread.PollSuspend() >>> BEGIN >>> IF threadRequestingSuspend = NIL THEN RETURN END; >>> PollSuspendSlow(); >>> END PollSuspend; >>> >>> >>> (* This is split to avoid needing a frame in PollSuspend. *) >>> PROCEDURE PollSuspendSlow() >>> VAR self: ADDRESS; >>> BEGIN >>> IF threadRequestingSuspend = NIL THEN RETURN END; >>> self := GetActivation(); >>> IF self = threadRequestingSuspend THEN RETURN END; (* important consideration! *) >>> GetContext(self.context); (* roughly *) >>> self.suspended := TRUE; (* roughly *) >>> WaitForResume(); (* details to be determined, either the semaphore >>> * or maybe acquire per-thread lock. *) >>> END PollSuspendSlow; >>> >>> >>> The poll call could also be a function pointer and usually point to a function that does nothing. >>> But that'd require loading the address from a global, and calling it. >>> Probably more bloat than calling direct instead of indirect. >>> >>> >>> - Jay >>> >> From rodney_bates at lcwb.coop Thu Apr 29 18:07:00 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 29 Apr 2010 11:07:00 -0500 Subject: [M3devel] INTEGER In-Reply-To: <20100427173036.7DC501A2096@async.async.caltech.edu> References: <20100421185631.GA17051@topoi.pooq.com> <80775CA2-A2FD-40AF-B235-7DB84127762E@cs.purdue.edu> <20100422123805.GA19259@topoi.pooq.com> <87B45DCC-2B8A-4C69-97D7-240BC1E2252D@cs.purdue.edu> <20100422145522.GA19946@topoi.pooq.com> <28339030-6005-4C28-872C-A68CF24BF4DF@cs.purdue.edu> <20100422154357.GA20043@topoi.pooq.com> <270A99B5-173E-413B-8C28-E1CA68870FD4@cs.purdue.edu> <20100423094903.GC21281@topoi.pooq.com> <20100423185214.BA2EF1A20E1@async.async.caltech.edu> <20100423165613.GA22126@topoi.pooq.com> <20100424103435.A1CC41A20C2@async.async.caltech.edu> <4BD713C7.2060607@lcwb.coop> <20100427172400.D491F1A2096@async.async.caltech.edu> <20100427173036.7DC501A2096@async.async.caltech.edu> Message-ID: <4BD9AEA4.9080505@lcwb.coop> Oh, I get it! You are proposing a _mixed_ approach, where the values the programmer can designate are of fixed (though possibly nonstatic) size (like open arrays) but the intermediate results are of unbounded size that re-adapts to hold the actual value each time an operator is evaluated, (like BigInteger). And because only intermediate results work this way, they can be stack allocated, because intermediate results have LIFO lifetimes. These are quite different approaches to arithmetic. It does seem at least a bit strange to mix them in this way. Mika Nystrom wrote: > Mika Nystrom writes: > ... >> I am not worried as you are by the range problem. The saving grace is >> that the language has very few arithmetic operators on integers. >> + - * DIV MOD. It's not hard to do range arithmetic on these such that >> one can easily figure out how much memory is required to hold intermediate >> results. If you're happy with alloca (I don't mind it), that's what >> you do. You have three options in so far as calculating the required >> space: > ... > > To clarify a bit further, my proposal is that the ranges be lost in > the evaluation. Everything in the expression is simply of type LONGINT. > When the final result is assigned to a variable, there is a range check > (which can be dispensed with if the compiler can prove that there can > be no overrun). > > Isn't this how INTEGER subranges work? > > a : [0..2]; > b : [0..1]; > > a := 4*b - 2*b Well, not really. INTEGER intermediate results (even when the operands have subrange type) are computed in the fixed size INTEGER. This could sometimes be a lot bigger than the subranges and in some cases big enough to hold all possible results, given small subrange operandss. But they are still fixed size (and maximally efficient). The intermediate result can still overflow in many cases. This is quite different from a size that always adapts to the actual value computed, every time the operator is evaluated, and thus can never overflow. I thought you were trying to do this in your proposal, just with bigger sizes. Of course, what happens when an overflow occurs is a different question. Not very satisfactorily handled now, even for INTEGER, IMO. But it is not really possible in any language to handle overflows both well and efficiently, given current hardware. In any case, it's an orthogonal issue to when overflows happen. > > Mika > From hendrik at topoi.pooq.com Thu Apr 29 14:43:15 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 29 Apr 2010 08:43:15 -0400 Subject: [M3devel] INTEGER In-Reply-To: <4BD9AEA4.9080505@lcwb.coop> References: <20100422154357.GA20043@topoi.pooq.com> <270A99B5-173E-413B-8C28-E1CA68870FD4@cs.purdue.edu> <20100423094903.GC21281@topoi.pooq.com> <20100423185214.BA2EF1A20E1@async.async.caltech.edu> <20100423165613.GA22126@topoi.pooq.com> <20100424103435.A1CC41A20C2@async.async.caltech.edu> <4BD713C7.2060607@lcwb.coop> <20100427172400.D491F1A2096@async.async.caltech.edu> <20100427173036.7DC501A2096@async.async.caltech.edu> <4BD9AEA4.9080505@lcwb.coop> Message-ID: <20100429124315.GB12060@topoi.pooq.com> On Thu, Apr 29, 2010 at 11:07:00AM -0500, Rodney M. Bates wrote: > Oh, I get it! You are proposing a _mixed_ approach, where the values > the programmer can designate are of fixed (though possibly nonstatic) > size (like open arrays) but the intermediate results are of unbounded > size that re-adapts to hold the actual value each time an operator is > evaluated, (like BigInteger). And because only intermediate results > work this way, they can be stack allocated, because intermediate > results have LIFO lifetimes. In fact, the sizes of intermediate results can be determined statically, in theory, at least. An arithmetic operation with subranges as arguments has at most a finite number of possible argument pairs, and therefore at mist a finite number of possible results. A finite set of integers has a maximum and a minimum. In practices, there might be operations (such as shifts and exponentiation) for which there bounds are impractical. -- hendrik > > These are quite different approaches to arithmetic. It does seem > at least a bit strange to mix them in this way. Keeping track of the maximum sizes statically makes it a little less strange. -- hendrik From mika at async.async.caltech.edu Thu Apr 29 20:59:43 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Thu, 29 Apr 2010 11:59:43 -0700 Subject: [M3devel] INTEGER In-Reply-To: <20100429124315.GB12060@topoi.pooq.com> References: <20100422154357.GA20043@topoi.pooq.com> <270A99B5-173E-413B-8C28-E1CA68870FD4@cs.purdue.edu> <20100423094903.GC21281@topoi.pooq.com> <20100423185214.BA2EF1A20E1@async.async.caltech.edu> <20100423165613.GA22126@topoi.pooq.com> <20100424103435.A1CC41A20C2@async.async.caltech.edu> <4BD713C7.2060607@lcwb.coop> <20100427172400.D491F1A2096@async.async.caltech.edu> <20100427173036.7DC501A2096@async.async.caltech.edu> <4BD9AEA4.9080505@lcwb.coop> <20100429124315.GB12060@topoi.pooq.com> Message-ID: <20100429185943.334171A20A4@async.async.caltech.edu> hendrik at topoi.pooq.com writes: >On Thu, Apr 29, 2010 at 11:07:00AM -0500, Rodney M. Bates wrote: >> Oh, I get it! You are proposing a _mixed_ approach, where the values >> the programmer can designate are of fixed (though possibly nonstatic) >> size (like open arrays) but the intermediate results are of unbounded >> size that re-adapts to hold the actual value each time an operator is >> evaluated, (like BigInteger). And because only intermediate results >> work this way, they can be stack allocated, because intermediate >> results have LIFO lifetimes. > >In fact, the sizes of intermediate results can be determined statically, >in theory, at least. An arithmetic operation with subranges as >arguments has at most a finite number of possible argument pairs, and >therefore at mist a finite number of possible results. A finite set of >integers has a maximum and a minimum. > >In practices, there might be operations (such as shifts and >exponentiation) for which there bounds are impractical. > >-- hendrik Well, the language only has built-in operations for which the range checks are easy. The problem with only allowing static sized LONGINTs is that you can't write PROCEDURE F(READONLY a, b : LONGINT; VAR c : LONGINT) = BEGIN c := a + b END F; Instead you get a proliferation of Fs to cover every possible range... I suppose you can do it with generics but oh what a pain. Mika From wagner at elegosoft.com Thu Apr 29 21:43:16 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 29 Apr 2010 21:43:16 +0200 Subject: [M3devel] one more (64 bit) m3tests issue Message-ID: <20100429214316.p9i0v1j5kw04swwk@mail.elegosoft.com> For AMD64_..., there is one more unexpected test failure: http://hudson.modula3.com:8080/view/cm3/job/cm3-test-m3tests-AMD64_LINUX/555/testReport/(root)/m3tests/p179__alignment_of_ARRAY_OF_BITS_32_FOR_INTEGER This test fails on all AMD64 platforms. Comments? Ignore? I think all the others are either ancient legacy or have been looked at by Tony and Jay and postponed. 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 Thu Apr 29 22:32:42 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 29 Apr 2010 22:32:42 +0200 Subject: [M3devel] M3 language definition in cm3/doc Message-ID: <20100429223242.qanzwguv4wks80kc@mail.elegosoft.com> The M3 language definition is contained in several formats in the cm3 repository and web pages. Recent changes to the language have been added by Antony Hosking and Rodney Bates to cm3/doc/reference/complete/m3-defn-complete.tex There are also versions in other formats: cm3/doc/reference/complete/m3-defn-complete.html cm3/doc/reference/complete/m3-defn-complete.ps cm3/doc/reference/complete/m3-defn-complete.pdf Critical Mass added a split-up HTML version for online access, which I was not able to exactly recreate: cm3/doc/reference/*.html There is now a new variant of split HTML files in cm3/doc/reference/complete/html/*.html The files in this directory as well as the complete versions above can now be generated automatically by simply running `make' in the directory cm3/doc/reference/complete/. latex2html is used for HTML conversion, dvips for PS, and dvipdf for PDF creation. Of course latex2e must also be installed to create the device independent file (.dvi). I have updated all the formats based on the (hopefully) latest and greatest language spec in m3-defn-complete.tex. I haven't checked that thoroughly but trusted that it was all right. If you find any mistakes, please let me know. Please also note that I had to change some tabbing environments, as the latex2html script had some problems with generating readable HTML for existing ones. To ensure readable indentation, all lines should begin with a tab (\>). I have merged all the changes from the release branch to the trunk, too. I haven't tested them there though. Thanks for your attention, 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 lcwb.coop Thu Apr 29 23:19:09 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 29 Apr 2010 16:19:09 -0500 Subject: [M3devel] INTEGER In-Reply-To: <20100429124315.GB12060@topoi.pooq.com> References: <20100422154357.GA20043@topoi.pooq.com> <270A99B5-173E-413B-8C28-E1CA68870FD4@cs.purdue.edu> <20100423094903.GC21281@topoi.pooq.com> <20100423185214.BA2EF1A20E1@async.async.caltech.edu> <20100423165613.GA22126@topoi.pooq.com> <20100424103435.A1CC41A20C2@async.async.caltech.edu> <4BD713C7.2060607@lcwb.coop> <20100427172400.D491F1A2096@async.async.caltech.edu> <20100427173036.7DC501A2096@async.async.caltech.edu> <4BD9AEA4.9080505@lcwb.coop> <20100429124315.GB12060@topoi.pooq.com> Message-ID: <4BD9F7CD.50704@lcwb.coop> hendrik at topoi.pooq.com wrote: > On Thu, Apr 29, 2010 at 11:07:00AM -0500, Rodney M. Bates wrote: >> Oh, I get it! You are proposing a _mixed_ approach, where the values >> the programmer can designate are of fixed (though possibly nonstatic) >> size (like open arrays) but the intermediate results are of unbounded >> size that re-adapts to hold the actual value each time an operator is >> evaluated, (like BigInteger). And because only intermediate results >> work this way, they can be stack allocated, because intermediate >> results have LIFO lifetimes. > > In fact, the sizes of intermediate results can be determined statically, > in theory, at least. Yes. But only when all operands are "fixed" longint types, i.e. [L..U]. If any of them are "open" LONGINT, then the bounds are dynamic, in the proposal. An arithmetic operation with subranges as > arguments has at most a finite number of possible argument pairs, and > therefore at mist a finite number of possible results. A finite set of > integers has a maximum and a minimum. > > In practices, there might be operations (such as shifts and > exponentiation) for which there bounds are impractical. > > -- hendrik > >> These are quite different approaches to arithmetic. It does seem >> at least a bit strange to mix them in this way. > > Keeping track of the maximum sizes statically makes it a little less > strange. > > -- hendrik > From rodney_bates at lcwb.coop Thu Apr 29 23:45:23 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 29 Apr 2010 16:45:23 -0500 Subject: [M3devel] one more (64 bit) m3tests issue In-Reply-To: <20100429214316.p9i0v1j5kw04swwk@mail.elegosoft.com> References: <20100429214316.p9i0v1j5kw04swwk@mail.elegosoft.com> Message-ID: <4BD9FDF3.6070701@lcwb.coop> Looks like a 32/64 bit independence bug in the test. The test description, from m3tests/src/makefile says "alignment of ARRAY OF BITS 32 FOR INTEGER". This type would be illegal on a 64-bit machine. But the description is wrong. The type in the source file m3test/src/p1/p179/Main.m3 is actually "BITS 32 FOR [16_80000000..16_7FFFFFFF]" And, on a 64-bit native machine, this really is an empty type, as the compiler complains. On a 64-bit machine, 16_80000000 means 16_00000000800000, positive and larger than the upper bound. How about BITS 32 FOR [Word.Shift(-1,31)..16_7FFFFFFF], to be the same on any machine with >= 32-bit native word size? Or (-16_7FFFFFFF)-1?, which would be non-overflowing and same value on >= 32 bits. I don't think this test can be coded for < 32 bits or other than 2's complement and still be the same test. Wasn't there a discussion of this a while back? Olaf Wagner wrote: > For AMD64_..., there is one more unexpected test failure: > > http://hudson.modula3.com:8080/view/cm3/job/cm3-test-m3tests-AMD64_LINUX/555/testReport/(root)/m3tests/p179__alignment_of_ARRAY_OF_BITS_32_FOR_INTEGER > > > This test fails on all AMD64 platforms. > > Comments? Ignore? > > I think all the others are either ancient legacy or have been looked at > by Tony and Jay and postponed. > > Olaf From mika at async.async.caltech.edu Fri Apr 30 00:07:19 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Thu, 29 Apr 2010 15:07:19 -0700 Subject: [M3devel] INTEGER In-Reply-To: <4BD9AEA4.9080505@lcwb.coop> References: <20100421185631.GA17051@topoi.pooq.com> <80775CA2-A2FD-40AF-B235-7DB84127762E@cs.purdue.edu> <20100422123805.GA19259@topoi.pooq.com> <87B45DCC-2B8A-4C69-97D7-240BC1E2252D@cs.purdue.edu> <20100422145522.GA19946@topoi.pooq.com> <28339030-6005-4C28-872C-A68CF24BF4DF@cs.purdue.edu> <20100422154357.GA20043@topoi.pooq.com> <270A99B5-173E-413B-8C28-E1CA68870FD4@cs.purdue.edu> <20100423094903.GC21281@topoi.pooq.com> <20100423185214.BA2EF1A20E1@async.async.caltech.edu> <20100423165613.GA22126@topoi.pooq.com> <20100424103435.A1CC41A20C2@async.async.caltech.edu> <4BD713C7.2060607@lcwb.coop> <20100427172400.D491F1A2096@async.async.caltech.edu> <20100427173036.7DC501A2096@async.async.caltech.edu> <4BD9AEA4.9080505@lcwb.coop> Message-ID: <20100429220719.6DD991A20A4@async.async.caltech.edu> "Rodney M. Bates" writes: >Oh, I get it! You are proposing a _mixed_ approach, where the values >the programmer can designate are of fixed (though possibly nonstatic) >size (like open arrays) but the intermediate results are of unbounded >size that re-adapts to hold the actual value each time an operator is >evaluated, (like BigInteger). And because only intermediate results >work this way, they can be stack allocated, because intermediate >results have LIFO lifetimes. > >These are quite different approaches to arithmetic. It does seem >at least a bit strange to mix them in this way. Speeeaking of stack allocation's being possible owing to LIFO lifetimes..... The Green Book says the following: "[Lisp, ML, Smalltalk, and CLU's] general disposition towards heap allocation rather than stack allocation remains" May I draw the conclusion that exposing the difference between stack and heap allocation in the language is fair game for the Modula-3 definition? What I'm getting at is this. If my LONGINT proposal is workable, the following ought to be workable too: VAR a : NEW(ARRAY OF T, n); (Note: no REF, also no =.) It's an object upon which it is legal to perform exactly those things that are legal to do to b^, where previously b := NEW(REF ARRAY OF T, n) I don't have a good name for the type of a ("evanescent array"?), but I think being able to do this would make it possible to write efficient code in ways that today only C++ (to my knowledge) allows. I think the Modula-3 rules on what can (more importantly can't) be done with open arrays may be enough to restrict the feature so it doesn't lead to new complications (in the language definition---the implementation I'm not sure about). The lowest levels of the implementation would use alloca with a fallback to heap allocation if for some reason variable-sized stack objects are not allowed. LONGINT is then a rather natural specialization of the same rules. (Cf. ARRAY OF BITS 1 FOR BOOLEAN vs. SET OF.) Mika From rodney_bates at lcwb.coop Fri Apr 30 02:30:44 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 29 Apr 2010 19:30:44 -0500 Subject: [M3devel] INTEGER In-Reply-To: <20100429220719.6DD991A20A4@async.async.caltech.edu> References: <20100421185631.GA17051@topoi.pooq.com> <80775CA2-A2FD-40AF-B235-7DB84127762E@cs.purdue.edu> <20100422123805.GA19259@topoi.pooq.com> <87B45DCC-2B8A-4C69-97D7-240BC1E2252D@cs.purdue.edu> <20100422145522.GA19946@topoi.pooq.com> <28339030-6005-4C28-872C-A68CF24BF4DF@cs.purdue.edu> <20100422154357.GA20043@topoi.pooq.com> <270A99B5-173E-413B-8C28-E1CA68870FD4@cs.purdue.edu> <20100423094903.GC21281@topoi.pooq.com> <20100423185214.BA2EF1A20E1@async.async.caltech.edu> <20100423165613.GA22126@topoi.pooq.com> <20100424103435.A1CC41A20C2@async.async.caltech.edu> <4BD713C7.2060607@lcwb.coop> <20100427172400.D491F1A2096@async.async.caltech.edu> <20100427173036.7DC501A2096@async.async.caltech.edu> <4BD9AEA4.9080505@lcwb.coop> <20100429220719.6DD991A20A4@async.async.caltech.edu> Message-ID: <4BDA24B4.3090100@lcwb.coop> Mika Nystrom wrote: > "Rodney M. Bates" writes: >> Oh, I get it! You are proposing a _mixed_ approach, where the values >> the programmer can designate are of fixed (though possibly nonstatic) >> size (like open arrays) but the intermediate results are of unbounded >> size that re-adapts to hold the actual value each time an operator is >> evaluated, (like BigInteger). And because only intermediate results >> work this way, they can be stack allocated, because intermediate >> results have LIFO lifetimes. >> >> These are quite different approaches to arithmetic. It does seem >> at least a bit strange to mix them in this way. > > Speeeaking of stack allocation's being possible owing to LIFO lifetimes..... > > The Green Book says the following: > > "[Lisp, ML, Smalltalk, and CLU's] general disposition towards heap allocation > rather than stack allocation remains" > > May I draw the conclusion that exposing the difference between stack and > heap allocation in the language is fair game for the Modula-3 definition? I think the distinction is already exposed. If it's created by NEW, it's heap allocated. If it's a declared variable by VAR, it's stack allocated. > > What I'm getting at is this. If my LONGINT proposal is workable, the > following ought to be workable too: > > VAR a : NEW(ARRAY OF T, n); I seem to recall an argument the original designers made to the effect they felt declared variables of non-constant size were not worth the complication over just heap allocating them. I don't remember where, or the details. But yes, it could be made to work, I think. > > (Note: no REF, also no =.) It's an object upon which it is legal to > perform exactly those things that are legal to do to b^, where previously > > b := NEW(REF ARRAY OF T, n) > > I don't have a good name for the type of a ("evanescent array"?), but > I think being able to do this would make it possible to write efficient > code in ways that today only C++ (to my knowledge) allows. I think the > Modula-3 rules on what can (more importantly can't) be done with open > arrays may be enough to restrict the feature so it doesn't lead to new > complications (in the language definition---the implementation I'm not > sure about). To be precise, the severe limitations on open arrays apply only to how you can use an open array _type_. A _variable_ (or formal, field, element of open array, WITH-temp, etc.) of open array type can be used just about any way one of fixed array type can be. The lowest levels of the implementation would use alloca > with a fallback to heap allocation if for some reason variable-sized > stack objects are not allowed. > > LONGINT is then a rather natural specialization of the same rules. > (Cf. ARRAY OF BITS 1 FOR BOOLEAN vs. SET OF.) > > Mika > > From mika at async.async.caltech.edu Fri Apr 30 03:39:22 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Thu, 29 Apr 2010 18:39:22 -0700 Subject: [M3devel] INTEGER In-Reply-To: <4BDA24B4.3090100@lcwb.coop> References: <20100421185631.GA17051@topoi.pooq.com> <80775CA2-A2FD-40AF-B235-7DB84127762E@cs.purdue.edu> <20100422123805.GA19259@topoi.pooq.com> <87B45DCC-2B8A-4C69-97D7-240BC1E2252D@cs.purdue.edu> <20100422145522.GA19946@topoi.pooq.com> <28339030-6005-4C28-872C-A68CF24BF4DF@cs.purdue.edu> <20100422154357.GA20043@topoi.pooq.com> <270A99B5-173E-413B-8C28-E1CA68870FD4@cs.purdue.edu> <20100423094903.GC21281@topoi.pooq.com> <20100423185214.BA2EF1A20E1@async.async.caltech.edu> <20100423165613.GA22126@topoi.pooq.com> <20100424103435.A1CC41A20C2@async.async.caltech.edu> <4BD713C7.2060607@lcwb.coop> <20100427172400.D491F1A2096@async.async.caltech.edu> <20100427173036.7DC501A2096@async.async.caltech.edu> <4BD9AEA4.9080505@lcwb.coop> <20100429220719.6DD991A20A4@async.async.caltech.edu> <4BDA24B4.3090100@lcwb.coop> Message-ID: <20100430013922.5DCB21A20A9@async.async.caltech.edu> "Rodney M. Bates" writes: > > >I seem to recall an argument the original designers made to the effect >they felt declared variables of non-constant size were not worth the >complication over just heap allocating them. I don't remember where, >or the details. But yes, it could be made to work, I think. Yes, of course, that is why they didn't do it. I'm not sure it's even particularly difficult. > >> >> (Note: no REF, also no =.) It's an object upon which it is legal to >> perform exactly those things that are legal to do to b^, where previously >> >> b := NEW(REF ARRAY OF T, n) >> >> I don't have a good name for the type of a ("evanescent array"?), but >> I think being able to do this would make it possible to write efficient >> code in ways that today only C++ (to my knowledge) allows. I think the >> Modula-3 rules on what can (more importantly can't) be done with open >> arrays may be enough to restrict the feature so it doesn't lead to new >> complications (in the language definition---the implementation I'm not >> sure about). > >To be precise, the severe limitations on open arrays apply only to how >you can use an open array _type_. A _variable_ (or formal, field, element >of open array, WITH-temp, etc.) of open array type can be used just >about any way one of fixed array type can be. Right, and I think it's enough. What we care about here is that we can't return the variable-sized array nor assign it to anything. I think it falls out rather naturally. E.g., to take an already fairly nasty example: PROCEDURE F() : ARRAY [0..1] OF T = VAR x : NEW(ARRAY OF T, 2); BEGIN RETURN x END F; here there is an implicit type check on return. This is probably already implemented by the compiler as: PROCEDURE F(VAR retval : ARRAY [0..1] OF T) = VAR x : NEW(ARRAY OF T, 2); BEGIN retval := x; (* implicit shape check *) RETURN END F; Another fairly nasty example: PROCEDURE G(x : ARRAY OF T) = ... VAR x : NEW(ARRAY OF T, 2); BEGIN G(x) END This is no different from writing VAR x : ARRAY [0..1] OF T; BEGIN G(x) END and I don't see how introducing the variable size makes it really any more difficult. If the compiler writer doesn't know how to do it in one particular case he can also just punt the problem to heap allocation. Maybe there is something I'm missing but it has always bugged me that most of the time I have to heap-allocate array temporaries. Mika