From jay.krell at cornell.edu Thu Dec 6 09:26:33 2012 From: jay.krell at cornell.edu (Jay K) Date: Thu, 6 Dec 2012 08:26:33 +0000 Subject: [M3devel] redundant range checks? Message-ID: m3-libs/m3core/src/fingerprint/Poly.i3 Int32 = [-16_7fffffff-1 .. 16_7fffffff]; T = ARRAY [0..1] OF Int32; m3-libs/m3core/src/fingerprint/Poly.m3 PROCEDURE Sum (READONLY p, q: T) : T = VAR r : T; BEGIN r[0] := Word.Xor (p[0], q[0]); line 48 r[1] := Word.Xor (p[1], q[1]); RETURN r; END Sum; -----LINE 48 ----- load v.5 0 Addr Addr load_indirect 0 Int.32 Int.64 load v.6 0 Addr Addr load_indirect 0 Int.32 Int.64 xor Word.64 ... check_range Int.64 -2147483648 2147483647 1 if((((INT64)(((UINT64)(((UINT64)(((INT64)(*((INT32*)(p_L_7)))))) ^((UINT64)(((INT64)(*((INT32*)(q_L_8)))))))))) <((INT64)(M3_INT64(-2147483648)))) || (((INT64)(M3_INT64(2147483647))) < ((INT64)(((UINT64)(((UINT64)(((INT64)(*((INT32*)(p_L_7))))))^((UINT64)(((INT64)(*((INT32*)(q_L_8))))))))))))M_Poly_L_4_CRASH(1537); Poly.mc.c:325: warning: comparison is always false due to limited range of data type or, like: typedef long long INT64; typedef unsigned long long UINT64; typedef int INT32; #define MAXINT32 2147483647 #define MININT32 (-2147483648) void ReportFault(void); #define AssignINT64ToINT32(a, b) \ if (((INT64)(b)) < MININT32 || ((INT64)(b)) > MAXINT32) ReportFault(); \ a = (INT32)(INT64)(b); \ INT32 Sum(INT32 p, INT32 q) { INT32 r; AssignINT64ToINT32(r, ((UINT64)(INT64)*(INT32*)&p) ^ ((UINT64)(INT64)*(INT32*)&q)); // or this AssignINT64ToINT32(r, ((UINT64)(INT64)p) ^ ((UINT64)(INT64)q)); // or heck even this AssignINT64ToINT32(r, p ^ q); return r; } the operands get widened from 32bits to 64bits, operation done, then range checked, and assigned back to 32bits. The range check is redundant. It is subtle. 32bit operands sign extended to 64bits will succeed the range check. The upper bits will all be set or clear. If you xor them, the upper bits will still be either all set or all clear, which succeeds the range check. The C compiler notices it and warns. I'd like to avoid warnings. I think the frontend could catch this, easily enough. Thoughts? I'm just about in position to fix this in the C backend. But it'd be cool if the frontend did some cheap analysis always. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Dec 13 09:25:48 2012 From: jay.krell at cornell.edu (Jay K) Date: Thu, 13 Dec 2012 08:25:48 +0000 Subject: [M3devel] (no subject) Message-ID: I strongly suggest that Target.Int be extended from 8 bytes to 9. The reason is thus: I was trying to mix TWord and TInt in M3C.m3. It become tedious and error prone. If Target.Int were extended to 9 bytes internally, then it would have a range exceeding a signed 64bit integer and a full range unsigned 64bit integer, and the need for TWord would, I believe, go away. The result would be *slightly* *slightly* *slightly* less efficient, but more convenient. I have already applied this change locally and built with it. It was very simple. I did have to visit the initializations of this mostly-opaque type, i.e. in Target.m3 and TInt.i3. Furthermore, I weakly suggest that Target.Int internally be changed to separately store the sign and the magnitude. This would be a hidden implementation detail and I believe it would simplify the implementation. It would *slightly* deoptimize the representation size, but the code, I think, would be smaller and simpler. This would not affect the public interface. I came to this suggestion when someone recently asked me how to implement this sort of thing. I realize it is slightly easier to store the sign and magnitude separately. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Dec 13 09:32:27 2012 From: jay.krell at cornell.edu (Jay K) Date: Thu, 13 Dec 2012 08:32:27 +0000 Subject: [M3devel] suggested Target.Int change In-Reply-To: References: Message-ID: [added subject] I strongly suggest that Target.Int be extended from 8 bytes to 9. The reason is thus: I was trying to mix TWord and TInt in M3C.m3. It become tedious and error prone. If Target.Int were extended to 9 bytes internally, then it would have a range exceeding a signed 64bit integer and a full range unsigned 64bit integer, and the need for TWord would, I believe, go away. The result would be *slightly* *slightly* *slightly* less efficient, but more convenient. I have already applied this change locally and built with it. It was very simple. I did have to visit the initializations of this mostly-opaque type, i.e. in Target.m3 and TInt.i3. Furthermore, I weakly suggest that Target.Int internally be changed to separately store the sign and the magnitude. This would be a hidden implementation detail and I believe it would simplify the implementation. It would *slightly* deoptimize the representation size, but the code, I think, would be smaller and simpler. This would not affect the public interface. I came to this suggestion when someone recently asked me how to implement this sort of thing. I realize it is slightly easier to store the sign and magnitude separately. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From cornstalk at columbus.rr.com Fri Dec 14 04:37:21 2012 From: cornstalk at columbus.rr.com (Mark Morss) Date: Thu, 13 Dec 2012 22:37:21 -0500 Subject: [M3devel] emacs config for modula 3 Message-ID: <1355456241.27560.4.camel@thebeast> Hello to all. I'm sorry to make this minor housekeeping issue my first post to the list, but is there another emacs person here who has the right code to insert in .emacs to make emacs-mode work from modula3.el and m3font.el? I don't seem to have it right. Best to all. From im_ikram at yahoo.com Fri Dec 14 17:50:50 2012 From: im_ikram at yahoo.com (I.M. Ikram) Date: Fri, 14 Dec 2012 08:50:50 -0800 (PST) Subject: [M3devel] emacs config for modula 3 Message-ID: <1355503850.94677.YahooMailNeo@web162603.mail.bf1.yahoo.com> Hi. I'm another first-time poster here... > right code to insert in .emacs to make emacs-mode work from modula3.el > and m3font.el? I don't seem to have it right. The following snippet is from my .emacs: (add-to-list 'load-path "/path/to/modula3mode/directory") (autoload 'modula-3-mode "modula3") (load "m3font") ;; <--- enables syntax highlighting (setq auto-mode-alist (append '(("\\.ig$" . modula-3-mode) ("\\.mg$" . modula-3-mode) ("\\.i3$" . modula-3-mode) ("\\.m3$" . modula-3-mode)) auto-mode-alist)) Copied from the docs at http://modula3.elegosoft.com/cm3/doc/help/cm3/gnuemacs.html However, the indicated 'load' line is missing in those instructions. From dragisha at m3w.org Sat Dec 15 09:13:11 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sat, 15 Dec 2012 09:13:11 +0100 Subject: [M3devel] emacs config for modula 3 In-Reply-To: <1355503850.94677.YahooMailNeo@web162603.mail.bf1.yahoo.com> References: <1355503850.94677.YahooMailNeo@web162603.mail.bf1.yahoo.com> Message-ID: In my .emacs: (load-file "~/.emacs.d/modula3.el") (setq auto-mode-alist (append '(("\\.[im][3g]$" . modula-3-mode)) auto-mode-alist)) (setq completion-ignored-extensions (append '(".mo" ".mx" ".mc" ".io" ".ix") completion-ignored-extensions)) And I just copied modula3.el from cm3 distribution. No m3font needed for syntax highlighting, at least in my Aquamacs. I don't see m3font anywhere, it's some old version, maybe? Anyway - it just works. dd -- Divided by a common language Dragi?a Duri? dragisha at m3w.org On Dec 14, 2012, at 5:50 PM, I.M. Ikram wrote: > Hi. I'm another first-time poster here... > >> right code to insert in .emacs to make emacs-mode work from modula3.el >> and m3font.el? I don't seem to have it right. > > The following snippet is from my .emacs: > > (add-to-list 'load-path "/path/to/modula3mode/directory") > (autoload 'modula-3-mode "modula3") > (load "m3font") ;; <--- enables syntax highlighting > (setq auto-mode-alist > (append '(("\\.ig$" . modula-3-mode) > ("\\.mg$" . modula-3-mode) > ("\\.i3$" . modula-3-mode) > ("\\.m3$" . modula-3-mode)) > auto-mode-alist)) > > Copied from the docs at > http://modula3.elegosoft.com/cm3/doc/help/cm3/gnuemacs.html > However, the indicated 'load' line is missing in those instructions. > From jay.krell at cornell.edu Sun Dec 16 10:58:10 2012 From: jay.krell at cornell.edu (Jay K) Date: Sun, 16 Dec 2012 09:58:10 +0000 Subject: [M3devel] thouhts on -Wall with C backend output Message-ID: I've tried to generate "very good C". I've fixed some of what gcc -Wall complains about. For default gcc on my old MacBook -- old enough that it can still emulate PowerPC, gcc is 4.0.1. (at least one of what I deal with, I think anything newer won't complain..) do-cm3-all with -Wall -Werror gets very far, to: == package /Users/jay/dev2/cm3/m3-db/stablegen == +++ /cm3/bin/cm3 -build -DROOT=/Users/jay/dev2/cm3 +++ --- building in AMD64_DARWIN --- ignoring ../src/m3overrides w source -> compiling GenCode.m3 cc1: warnings being treated as errors GenCode.mc.c: In function ?GenCode__BuildMethods__Search?: GenCode.mc.c:3505: warning: control reaches end of non-void function m3_backend => 1 PROCEDURE Search ( type : Type.Reference; VAR count : INTEGER; VAR top : CARDINAL; umethods: AtomList.T ): ImportList.MethodList RAISES {StablegenError.E} = VAR methods: ImportList.MethodList; BEGIN IF (type = Type.root) OR (type = NIL) THEN (* base of recursion *) RETURN NEW(ImportList.MethodList, ABS(count)) ELSE TYPECASE type OF Type.Object (ob) => IF count <= 0 THEN count:= count - NUMBER(ob.methods^) END; methods := Search(ob.super, count, top, umethods); FOR i := 0 TO LAST(ob.methods^) DO IF umethods = NIL OR AtomList.Member( umethods, ob.methods[i].name) THEN IF AtomList.Member(reserved, ob.methods[i].name) THEN RAISE StablegenError.E(Atom.ToText(ob.methods[i].name) &" is a reserved method name in stable objects. " &"Must not be an update method.") END; methods[top].name := ob.methods[i].name; methods[top].sig := ob.methods[i].sig; INC(top) END END; RETURN methods | Type.Opaque (op) => RETURN Search(op.revealedSuperType, count, top, umethods) | Type.Reference => <*ASSERT FALSE*> END END END Search; I think we can't expect gcc -Wall -Werror to pass. I really wanted it to, and I tried, and I fixed stuff. But I don't think it is viable. Ok? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sun Dec 16 15:01:07 2012 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 16 Dec 2012 15:01:07 +0100 Subject: [M3devel] thouhts on -Wall with C backend output In-Reply-To: References: Message-ID: <20121216150107.efba68a3.wagner@elegosoft.com> On Sun, 16 Dec 2012 09:58:10 +0000 Jay K wrote: > -Wall -Werror I don't think it should be mandatory for our generated C code to pass this test, as long as we (you or somebody else ;-) are convinced that it's semantically correct. Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From rodney_bates at lcwb.coop Sun Dec 16 17:24:06 2012 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sun, 16 Dec 2012 10:24:06 -0600 Subject: [M3devel] thouhts on -Wall with C backend output In-Reply-To: References: Message-ID: <50CDF5A6.60400@lcwb.coop> You know, here is my view on the whole subject. A compiler, used in the usual way, has two functions: help to find a lot of programming errors that are statically detectable, and translate to machine code. When you feed a compiler with mechanically produced source code, the former function is not really that important. Ideally, the translator (including its own front end, in this case, the M3 front end) should take care of all the static error checking and just produce code that will translate properly. So once the translator is stable, it makes sense for ordinary users to ignore warnings from the back end compiler. They may still be very useful for testing the translator. I know this is a bit idealistic, and it takes more work for the translator developer to do it this way. But it's best for the user. Trying to correlate a warning (or error) issued by the back end compiler back to the original problem (if there is one) in the original source code can be exasperating for a user. So I'd say put the effort into making sure anything a user should care about is detected by the M3 front end and/or M3C. Then tell your users not to worry about messages from gcc. Yeah, I know this ignores the question of a user's wondering of messages from gcc are actually evidence of bugs in M3front/M3C. On 12/16/2012 03:58 AM, Jay K wrote: > I've tried to generate "very good C". > I've fixed some of what gcc -Wall complains about. > For default gcc on my old MacBook -- old enough that it can still emulate PowerPC, gcc is 4.0.1. > (at least one of what I deal with, I think anything newer won't complain..) > > > > do-cm3-all with -Wall -Werror gets very far, to: > > == package /Users/jay/dev2/cm3/m3-db/stablegen == > > +++ /cm3/bin/cm3 -build -DROOT=/Users/jay/dev2/cm3 +++ > --- building in AMD64_DARWIN --- > > ignoring ../src/m3overrides > > w source -> compiling GenCode.m3 > cc1: warnings being treated as errors > GenCode.mc.c: In function ?GenCode__BuildMethods__Search?: > GenCode.mc.c:3505: warning: control reaches end of non-void function > m3_backend => 1 > > PROCEDURE Search ( type : Type.Reference; > VAR count : INTEGER; > VAR top : CARDINAL; > umethods: AtomList.T ): > ImportList.MethodList RAISES {StablegenError.E} = > VAR methods: ImportList.MethodList; > BEGIN > IF (type = Type.root) OR (type = NIL) THEN (* base of > recursion *) > RETURN NEW(ImportList.MethodList, ABS(count)) > ELSE > TYPECASE type OF > Type.Object (ob) => > IF count <= 0 THEN > count:= count - NUMBER(ob.methods^) > END; > methods := Search(ob.super, count, top, umethods); > FOR i := 0 TO LAST(ob.methods^) DO > IF umethods = NIL > OR AtomList.Member( > umethods, ob.methods[i].name) THEN > IF AtomList.Member(reserved, ob.methods[i].name) THEN > RAISE StablegenError.E(Atom.ToText(ob.methods[i].name) > &" is a reserved method name in stable objects. " > &"Must not be an update method.") > END; > methods[top].name := ob.methods[i].name; > methods[top].sig := ob.methods[i].sig; > INC(top) > END > END; > RETURN methods > | Type.Opaque (op) => > RETURN Search(op.revealedSuperType, count, top, umethods) > | Type.Reference => <*ASSERT FALSE*> > END > END > END Search; > > I think we can't expect gcc -Wall -Werror to pass. > I really wanted it to, and I tried, and I fixed stuff. > But I don't think it is viable. > Ok? > > > - Jay From hendrik at topoi.pooq.com Sun Dec 16 19:43:06 2012 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Sun, 16 Dec 2012 13:43:06 -0500 Subject: [M3devel] thouhts on -Wall with C backend output In-Reply-To: References: Message-ID: <20121216184306.GA29473@topoi.pooq.com> On Sun, Dec 16, 2012 at 09:58:10AM +0000, Jay K wrote: > > I've tried to generate "very good C". > I've fixed some of what gcc -Wall complains about. > For default gcc on my old MacBook -- old enough that it can still emulate PowerPC, gcc is 4.0.1. > (at least one of what I deal with, I think anything newer won't complain..) > > > > do-cm3-all with -Wall -Werror gets very far, to: > > == package /Users/jay/dev2/cm3/m3-db/stablegen == > > +++ /cm3/bin/cm3 -build -DROOT=/Users/jay/dev2/cm3 +++ > --- building in AMD64_DARWIN --- > > ignoring ../src/m3overrides > > w source -> compiling GenCode.m3 > cc1: warnings being treated as errors > GenCode.mc.c: In function ?GenCode__BuildMethods__Search?: > GenCode.mc.c:3505: warning: control reaches end of non-void function > m3_backend => 1 > > PROCEDURE Search ( type : Type.Reference; > VAR count : INTEGER; > VAR top : CARDINAL; > umethods: AtomList.T ): > ImportList.MethodList RAISES {StablegenError.E} = > VAR methods: ImportList.MethodList; > BEGIN > IF (type = Type.root) OR (type = NIL) THEN (* base of > recursion *) > RETURN NEW(ImportList.MethodList, ABS(count)) > ELSE > TYPECASE type OF > Type.Object (ob) => > IF count <= 0 THEN > count:= count - NUMBER(ob.methods^) > END; > methods := Search(ob.super, count, top, umethods); > FOR i := 0 TO LAST(ob.methods^) DO > IF umethods = NIL > OR AtomList.Member( > umethods, ob.methods[i].name) THEN > IF AtomList.Member(reserved, ob.methods[i].name) THEN > RAISE StablegenError.E(Atom.ToText(ob.methods[i].name) > &" is a reserved method name in stable objects. " > &"Must not be an update method.") > END; > methods[top].name := ob.methods[i].name; > methods[top].sig := ob.methods[i].sig; > INC(top) > END > END; > RETURN methods > | Type.Opaque (op) => > RETURN Search(op.revealedSuperType, count, top, umethods) > | Type.Reference => <*ASSERT FALSE*> > END > END > END Search; > > I think we can't expect gcc -Wall -Werror to pass. > I really wanted it to, and I tried, and I fixed stuff. > But I don't think it is viable. > Ok? Could it be that the TYPECASE doesn't have an ELSE clause, possibly translated to a switch withouy a default: label? This would give the C code an apparent path to the end of the function. M3 may know that the TYPECASE exhausts all the possibilities, but C will not. -- hendrik From mika at async.caltech.edu Sun Dec 16 19:55:29 2012 From: mika at async.caltech.edu (mika at async.caltech.edu) Date: Sun, 16 Dec 2012 10:55:29 -0800 Subject: [M3devel] thouhts on -Wall with C backend output In-Reply-To: <20121216184306.GA29473@topoi.pooq.com> References: <20121216184306.GA29473@topoi.pooq.com> Message-ID: <20121216185529.AD9681A2094@async.async.caltech.edu> Can you have an option to add an assertion in the output for these cases? Here either 1. gcc has found a bug in the C code generator and/or front end, in that there's no default (abortion) case or 2. the front end has deduced there is no need for abortion because it can see that the missing ELSE is never going to be exercised, based on the already existing type information What I'm proposing is two modes for the compiler: -- ignore the errors or -- add proper assertions to the C code, e.g., assert(false, "front-end deduced this cant happen by inspecting type information") which, when enabled, should make gcc shut up, and instead turn into runtime checks on the compiler Mika Hendrik Boom writes: >On Sun, Dec 16, 2012 at 09:58:10AM +0000, Jay K wrote: >> >> I've tried to generate "very good C". >> I've fixed some of what gcc -Wall complains about. >> For default gcc on my old MacBook -- old enough that it can still emulate PowerPC, gcc is 4.0.1. >> (at least one of what I deal with, I think anything newer won't complain..) >> >> >> >> do-cm3-all with -Wall -Werror gets very far, to: >> >> == package /Users/jay/dev2/cm3/m3-db/stablegen == >> >> +++ /cm3/bin/cm3 -build -DROOT=/Users/jay/dev2/cm3 +++ >> --- building in AMD64_DARWIN --- >> >> ignoring ../src/m3overrides >> >> w source -> compiling GenCode.m3 >> cc1: warnings being treated as errors >> GenCode.mc.c: In function ???GenCode__BuildMethods__Search???: >> GenCode.mc.c:3505: warning: control reaches end of non-void function >> m3_backend => 1 >> >> PROCEDURE Search ( type : Type.Reference; >> VAR count : INTEGER; >> VAR top : CARDINAL; >> umethods: AtomList.T ): >> ImportList.MethodList RAISES {StablegenError.E} = >> VAR methods: ImportList.MethodList; >> BEGIN >> IF (type = Type.root) OR (type = NIL) THEN (* base of >> recursion *) >> RETURN NEW(ImportList.MethodList, ABS(count)) >> ELSE >> TYPECASE type OF >> Type.Object (ob) => >> IF count <= 0 THEN >> count:= count - NUMBER(ob.methods^) >> END; >> methods := Search(ob.super, count, top, umethods); >> FOR i := 0 TO LAST(ob.methods^) DO >> IF umethods = NIL >> OR AtomList.Member( >> umethods, ob.methods[i].name) THEN >> IF AtomList.Member(reserved, ob.methods[i].name) THEN >> RAISE StablegenError.E(Atom.ToText(ob.methods[i].name) >> &" is a reserved method name in stable objects. " >> &"Must not be an update method.") >> END; >> methods[top].name := ob.methods[i].name; >> methods[top].sig := ob.methods[i].sig; >> INC(top) >> END >> END; >> RETURN methods >> | Type.Opaque (op) => >> RETURN Search(op.revealedSuperType, count, top, umethods) >> | Type.Reference => <*ASSERT FALSE*> >> END >> END >> END Search; >> >> I think we can't expect gcc -Wall -Werror to pass. >> I really wanted it to, and I tried, and I fixed stuff. >> But I don't think it is viable. >> Ok? > >Could it be that the TYPECASE doesn't have an ELSE clause, possibly >translated to a switch withouy a default: label? This would give the >C code an apparent path to the end of the function. M3 may know that >the TYPECASE exhausts all the possibilities, but C will not. > >-- hendrik From jay.krell at cornell.edu Mon Dec 17 08:26:29 2012 From: jay.krell at cornell.edu (Jay K) Date: Mon, 17 Dec 2012 07:26:29 +0000 Subject: [M3devel] thouhts on -Wall with C backend output In-Reply-To: <20121216185529.AD9681A2094@async.async.caltech.edu> References: , <20121216184306.GA29473@topoi.pooq.com>, <20121216185529.AD9681A2094@async.async.caltech.edu> Message-ID: drat, these are worse: "../src/Macro.m3", line 949: warning: unreachable ELSE in TYPECASE == package /Users/jay/dev2/cm3/m3-ui/formsvbt == +++ /cm3/bin/cm3 -build -DROOT=/Users/jay/dev2/cm3 +++ --- building in AMD64_DARWIN --- ignoring ../src/m3overrides new source -> compiling Macro.m3 cc1plus: warnings being treated as errors Macro.mc.c: In function ?char* Macro__EvalLength(char*, char*)?: Macro.mc.c:5271: warning: control reaches end of non-void function Macro.mc.c: In function ?char* Macro__EvalPlus(char*, char*)?: Macro.mc.c:9004: warning: control reaches end of non-void function Macro.mc.c: In function ?char* Macro__EvalMinus(char*, char*)?: Macro.mc.c:9468: warning: control reaches end of non-void function If I put in the somewhat obvious: ELSE <* ASSERT FALSE *> then: new source -> compiling Macro.m3 "../src/Macro.m3", line 949: warning: unreachable ELSE in TYPECASE 1 warning encountered cc1plus: warnings being treated as errors Macro.mc.c: In function ?char* Macro__EvalLength(char*, char*)?: Macro.mc.c:5271: warning: control reaches end of non-void function Macro.mc.c: In function ?char* Macro__EvalPlus(char*, char*)?: Macro.mc.c:9004: warning: control reaches end of non-void function For stablegen, I am inclined to put in that ELSE <* ASSERT FALSE *>. I might might might be able to put in C assert(false) in these places. - Jay > To: hendrik at topoi.pooq.com > Date: Sun, 16 Dec 2012 10:55:29 -0800 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] thouhts on -Wall with C backend output > > Can you have an option to add an assertion in the output for these cases? > > Here either > > 1. gcc has found a bug in the C code generator and/or front end, in that > there's no default (abortion) case > > or > > 2. the front end has deduced there is no need for abortion because it can > see that the missing ELSE is never going to be exercised, based on the > already existing type information > > What I'm proposing is two modes for the compiler: > > -- ignore the errors > > or > > -- add proper assertions to the C code, e.g., > > assert(false, "front-end deduced this cant happen by inspecting type information") > > which, when enabled, should make gcc shut up, and instead turn into > runtime checks on the compiler > > Mika > > Hendrik Boom writes: > >On Sun, Dec 16, 2012 at 09:58:10AM +0000, Jay K wrote: > >> > >> I've tried to generate "very good C". > >> I've fixed some of what gcc -Wall complains about. > >> For default gcc on my old MacBook -- old enough that it can still emulate PowerPC, gcc is 4.0.1. > >> (at least one of what I deal with, I think anything newer won't complain..) > >> > >> > >> > >> do-cm3-all with -Wall -Werror gets very far, to: > >> > >> == package /Users/jay/dev2/cm3/m3-db/stablegen == > >> > >> +++ /cm3/bin/cm3 -build -DROOT=/Users/jay/dev2/cm3 +++ > >> --- building in AMD64_DARWIN --- > >> > >> ignoring ../src/m3overrides > >> > >> w source -> compiling GenCode.m3 > >> cc1: warnings being treated as errors > >> GenCode.mc.c: In function ?GenCode__BuildMethods__Search?: > >> GenCode.mc.c:3505: warning: control reaches end of non-void function > >> m3_backend => 1 > >> > >> PROCEDURE Search ( type : Type.Reference; > >> VAR count : INTEGER; > >> VAR top : CARDINAL; > >> umethods: AtomList.T ): > >> ImportList.MethodList RAISES {StablegenError.E} = > >> VAR methods: ImportList.MethodList; > >> BEGIN > >> IF (type = Type.root) OR (type = NIL) THEN (* base of > >> recursion *) > >> RETURN NEW(ImportList.MethodList, ABS(count)) > >> ELSE > >> TYPECASE type OF > >> Type.Object (ob) => > >> IF count <= 0 THEN > >> count:= count - NUMBER(ob.methods^) > >> END; > >> methods := Search(ob.super, count, top, umethods); > >> FOR i := 0 TO LAST(ob.methods^) DO > >> IF umethods = NIL > >> OR AtomList.Member( > >> umethods, ob.methods[i].name) THEN > >> IF AtomList.Member(reserved, ob.methods[i].name) THEN > >> RAISE StablegenError.E(Atom.ToText(ob.methods[i].name) > >> &" is a reserved method name in stable objects. " > >> &"Must not be an update method.") > >> END; > >> methods[top].name := ob.methods[i].name; > >> methods[top].sig := ob.methods[i].sig; > >> INC(top) > >> END > >> END; > >> RETURN methods > >> | Type.Opaque (op) => > >> RETURN Search(op.revealedSuperType, count, top, umethods) > >> | Type.Reference => <*ASSERT FALSE*> > >> END > >> END > >> END Search; > >> > >> I think we can't expect gcc -Wall -Werror to pass. > >> I really wanted it to, and I tried, and I fixed stuff. > >> But I don't think it is viable. > >> Ok? > > > >Could it be that the TYPECASE doesn't have an ELSE clause, possibly > >translated to a switch withouy a default: label? This would give the > >C code an apparent path to the end of the function. M3 may know that > >the TYPECASE exhausts all the possibilities, but C will not. > > > >-- hendrik -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Mon Dec 17 08:49:35 2012 From: mika at async.caltech.edu (mika at async.caltech.edu) Date: Sun, 16 Dec 2012 23:49:35 -0800 Subject: [M3devel] thouhts on -Wall with C backend output In-Reply-To: References: , <20121216184306.GA29473@topoi.pooq.com>, <20121216185529.AD9681A2094@async.async.caltech.edu> Message-ID: <20121217074935.5DD971A2094@async.async.caltech.edu> Yeah it sounds like the frontend knows something that it's not telling the backend about... if I am reading your emails right. Jay K writes: >--_ad389312-f922-410e-bb8f-e7106388428f_ >Content-Type: text/plain; charset="Windows-1252" >Content-Transfer-Encoding: quoted-printable > > >drat=2C these are worse: > >"../src/Macro.m3"=2C line 949: warning: unreachable ELSE in TYPECASE > > >=3D=3D package /Users/jay/dev2/cm3/m3-ui/formsvbt =3D=3D > > +++ /cm3/bin/cm3 -build -DROOT=3D/Users/jay/dev2/cm3 +++ >--- building in AMD64_DARWIN --- > >ignoring ../src/m3overrides > >new source -> compiling Macro.m3 >cc1plus: warnings being treated as errors >Macro.mc.c: In function =91char* Macro__EvalLength(char*=2C char*)=92: >Macro.mc.c:5271: warning: control reaches end of non-void function >Macro.mc.c: In function =91char* Macro__EvalPlus(char*=2C char*)=92: >Macro.mc.c:9004: warning: control reaches end of non-void function >Macro.mc.c: In function =91char* Macro__EvalMinus(char*=2C char*)=92: >Macro.mc.c:9468: warning: control reaches end of non-void function > > >If I put in the somewhat obvious: > > > ELSE <* ASSERT FALSE *> > > >then: > >new source -> compiling Macro.m3 >"../src/Macro.m3"=2C line 949: warning: unreachable ELSE in TYPECASE >1 warning encountered >cc1plus: warnings being treated as errors >Macro.mc.c: In function =91char* Macro__EvalLength(char*=2C char*)=92: >Macro.mc.c:5271: warning: control reaches end of non-void function >Macro.mc.c: In function =91char* Macro__EvalPlus(char*=2C char*)=92: >Macro.mc.c:9004: warning: control reaches end of non-void function > > > >For stablegen=2C I am inclined to put in that ELSE <* ASSERT FALSE *>. > > >I might might might be able to put in C assert(false) in these places. > > - Jay > > >> To: hendrik at topoi.pooq.com >> Date: Sun=2C 16 Dec 2012 10:55:29 -0800 >> From: mika at async.caltech.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] thouhts on -Wall with C backend output >>=20 >> Can you have an option to add an assertion in the output for these cases? >>=20 >> Here either >>=20 >> 1. gcc has found a bug in the C code generator and/or front end=2C in tha= >t >> there's no default (abortion) case >>=20 >> or >>=20 >> 2. the front end has deduced there is no need for abortion because it can >> see that the missing ELSE is never going to be exercised=2C based on t= >he >> already existing type information >>=20 >> What I'm proposing is two modes for the compiler: >>=20 >> -- ignore the errors >>=20 >> or >>=20 >> -- add proper assertions to the C code=2C e.g.=2C=20 >>=20 >> assert(false=2C "front-end deduced this cant happen by inspecting typ= >e information") >>=20 >> which=2C when enabled=2C should make gcc shut up=2C and instead turn i= >nto >> runtime checks on the compiler >>=20 >> Mika >>=20 >> Hendrik Boom writes: >> >On Sun=2C Dec 16=2C 2012 at 09:58:10AM +0000=2C Jay K wrote: >> >>=20 >> >> I've tried to generate "very good C". >> >> I've fixed some of what gcc -Wall complains about. >> >> For default gcc on my old MacBook -- old enough that it can still emul= >ate PowerPC=2C gcc is 4.0.1. >> >> (at least one of what I deal with=2C I think anything newer won't comp= >lain..) >> >>=20 >> >>=20 >> >>=20 >> >> do-cm3-all with -Wall -Werror gets very far=2C to: >> >>=20 >> >> =3D=3D package /Users/jay/dev2/cm3/m3-db/stablegen =3D=3D >> >>=20 >> >> +++ /cm3/bin/cm3 -build -DROOT=3D/Users/jay/dev2/cm3 +++ >> >> --- building in AMD64_DARWIN --- >> >>=20 >> >> ignoring ../src/m3overrides >> >>=20 >> >> w source -> compiling GenCode.m3 >> >> cc1: warnings being treated as errors >> >> GenCode.mc.c: In function =91GenCode__BuildMethods__Search=92: >> >> GenCode.mc.c:3505: warning: control reaches end of non-void function >> >> m3_backend =3D> 1 >> >>=20 >> >> PROCEDURE Search ( type : Type.Reference=3B >> >> VAR count : INTEGER=3B >> >> VAR top : CARDINAL=3B >> >> umethods: AtomList.T ): >> >> ImportList.MethodList RAISES {StablegenError.E} =3D >> >> VAR methods: ImportList.MethodList=3B >> >> BEGIN >> >> IF (type =3D Type.root) OR (type =3D NIL) THEN (* base of >> >> recursion *) >> >> RETURN NEW(ImportList.MethodList=2C ABS(count)) >> >> ELSE >> >> TYPECASE type OF >> >> Type.Object (ob) =3D>=20 >> >> IF count <=3D 0 THEN >> >> count:=3D count - NUMBER(ob.methods^) >> >> END=3B >> >> methods :=3D Search(ob.super=2C count=2C top=2C umethods)=3B >> >> FOR i :=3D 0 TO LAST(ob.methods^) DO >> >> IF umethods =3D NIL >> >> OR AtomList.Member( >> >> umethods=2C ob.methods[i].name) THEN >> >> IF AtomList.Member(reserved=2C ob.methods[i].name) THEN >> >> RAISE StablegenError.E(Atom.ToText(ob.methods[i].name) >> >> &" is a reserved method name in stable objects. " >> >> &"Must not be an update method.") >> >> END=3B >> >> methods[top].name :=3D ob.methods[i].name=3B >> >> methods[top].sig :=3D ob.methods[i].sig=3B >> >> INC(top) >> >> END >> >> END=3B >> >> RETURN methods >> >> | Type.Opaque (op) =3D> >> >> RETURN Search(op.revealedSuperType=2C count=2C top=2C umetho= >ds) >> >> | Type.Reference =3D> <*ASSERT FALSE*> >> >> END >> >> END >> >> END Search=3B >> >>=20 >> >> I think we can't expect gcc -Wall -Werror to pass. >> >> I really wanted it to=2C and I tried=2C and I fixed stuff. >> >> But I don't think it is viable. >> >> Ok? >> > >> >Could it be that the TYPECASE doesn't have an ELSE clause=2C possibly >> >translated to a switch withouy a default: label? This would give the >> >C code an apparent path to the end of the function. M3 may know that >> >the TYPECASE exhausts all the possibilities=2C but C will not. >> > >> >-- hendrik > = > >--_ad389312-f922-410e-bb8f-e7106388428f_ >Content-Type: text/html; charset="Windows-1252" >Content-Transfer-Encoding: quoted-printable > > > > >
>drat=2C these are worse:

"../src/Macro.m3"=2C line 949: warning: unr= >eachable ELSE in TYPECASE


=3D=3D package /Users/jay/dev2/cm3/m3-= >ui/formsvbt =3D=3D

 =3B+++ /cm3/bin/cm3 =3B =3B =3B = >-build -DROOT=3D/Users/jay/dev2/cm3 +++
--- building in AMD64_DARWIN ---= >

ignoring ../src/m3overrides

new source ->=3B compiling Mac= >ro.m3
cc1plus: warnings being treated as errors
Macro.mc.c: In functi= >on =91char* Macro__EvalLength(char*=2C char*)=92:
Macro.mc.c:5271: warni= >ng: control reaches end of non-void function
Macro.mc.c: In function =91= >char* Macro__EvalPlus(char*=2C char*)=92:
Macro.mc.c:9004: warning: cont= >rol reaches end of non-void function
Macro.mc.c: In function =91char* Ma= >cro__EvalMinus(char*=2C char*)=92:
Macro.mc.c:9468: warning: control rea= >ches end of non-void function


If I put in the somewhat obvious:<= >br>

 =3B =3B =3B ELSE <=3B* ASSERT FALSE *>=3B
r>
then:

new source ->=3B compiling Macro.m3
"../src/Macro.m= >3"=2C line 949: warning: unreachable ELSE in TYPECASE
1 warning encounte= >red
cc1plus: warnings being treated as errors
Macro.mc.c: In function= > =91char* Macro__EvalLength(char*=2C char*)=92:
Macro.mc.c:5271: warning= >: control reaches end of non-void function
Macro.mc.c: In function =91ch= >ar* Macro__EvalPlus(char*=2C char*)=92:
Macro.mc.c:9004: warning: contro= >l reaches end of non-void function



For stablegen=2C I am inc= >lined to put in that ELSE <=3B* ASSERT FALSE *>=3B.


I might = >might might be able to put in C assert(false) in these places.

 = >=3B- Jay


>=3B To: h= >endrik at topoi.pooq.com
>=3B Date: Sun=2C 16 Dec 2012 10:55:29 -0800
= >>=3B From: mika at async.caltech.edu
>=3B CC: m3devel at elegosoft.com
= >>=3B Subject: Re: [M3devel] thouhts on -Wall with C backend output
>= >=3B
>=3B Can you have an option to add an assertion in the output for= > these cases?
>=3B
>=3B Here either
>=3B
>=3B 1. gcc = >has found a bug in the C code generator and/or front end=2C in that
>= >=3B there's no default (abortion) case
>=3B
>=3B or
>=3B= >
>=3B 2. the front end has deduced there is no need for abortion beca= >use it can
>=3B see that the missing ELSE is never going to be exer= >cised=2C based on the
>=3B already existing type information
>= >=3B
>=3B What I'm proposing is two modes for the compiler:
>=3B = >
>=3B -- ignore the errors
>=3B
>=3B or
>=3B
>= >=3B -- add proper assertions to the C code=2C e.g.=2C
>=3B
>=3B= > assert(false=2C "front-end deduced this cant happen by inspecting type= > information")
>=3B
>=3B which=2C when enabled=2C should make= > gcc shut up=2C and instead turn into
>=3B runtime checks on the co= >mpiler
>=3B
>=3B Mika
>=3B
>=3B Hendrik Boom wr= >ites:
>=3B >=3BOn Sun=2C Dec 16=2C 2012 at 09:58:10AM +0000=2C Jay K= > wrote:
>=3B >=3B>=3B
>=3B >=3B>=3B I've tried to genera= >te "very good C".
>=3B >=3B>=3B I've fixed some of what gcc -Wall = >complains about.
>=3B >=3B>=3B For default gcc on my old MacBook -= >- old enough that it can still emulate PowerPC=2C gcc is 4.0.1.
>=3B &= >gt=3B>=3B (at least one of what I deal with=2C I think anything newer won= >'t complain..)
>=3B >=3B>=3B
>=3B >=3B>=3B
>=3B &g= >t=3B>=3B
>=3B >=3B>=3B do-cm3-all with -Wall -Werror gets very = >far=2C to:
>=3B >=3B>=3B
>=3B >=3B>=3B =3D=3D package /U= >sers/jay/dev2/cm3/m3-db/stablegen =3D=3D
>=3B >=3B>=3B
>=3B = >>=3B>=3B +++ /cm3/bin/cm3 -build -DROOT=3D/Users/jay/dev2/cm3 +++r>>=3B >=3B>=3B --- building in AMD64_DARWIN ---
>=3B >=3B>= >=3B
>=3B >=3B>=3B ignoring ../src/m3overrides
>=3B >=3B>= >=3B
>=3B >=3B>=3B w source ->=3B compiling GenCode.m3
>=3B= > >=3B>=3B cc1: warnings being treated as errors
>=3B >=3B>=3B = >GenCode.mc.c: In function =91GenCode__BuildMethods__Search=92:
>=3B &g= >t=3B>=3B GenCode.mc.c:3505: warning: control reaches end of non-void func= >tion
>=3B >=3B>=3B m3_backend =3D>=3B 1
>=3B >=3B>=3B= >
>=3B >=3B>=3B PROCEDURE Search ( type : Type.Reference= >=3B
>=3B >=3B>=3B VAR count : INTEGER=3B
= >>=3B >=3B>=3B VAR top : CARDINAL=3B
>=3B= > >=3B>=3B umethods: AtomList.T ):
>=3B &= >gt=3B>=3B ImportList.MethodList RAISES {StablegenError.E} =3D
>= >=3B >=3B>=3B VAR methods: ImportList.MethodList=3B
>=3B >=3B= >>=3B BEGIN
>=3B >=3B>=3B IF (type =3D Type.root) OR (t= >ype =3D NIL) THEN (* base of
>=3B >=3B>=3B = > recursion *)
>=3B >=3B>=3B RE= >TURN NEW(ImportList.MethodList=2C ABS(count))
>=3B >=3B>=3B = >ELSE
>=3B >=3B>=3B TYPECASE type OF
>=3B >=3B>=3B = > Type.Object (ob) =3D>=3B
>=3B >=3B>=3B IF coun= >t <=3B=3D 0 THEN
>=3B >=3B>=3B count:=3D count - NUM= >BER(ob.methods^)
>=3B >=3B>=3B END=3B
>=3B >=3B&g= >t=3B methods :=3D Search(ob.super=2C count=2C top=2C umethods)=3B= >
>=3B >=3B>=3B FOR i :=3D 0 TO LAST(ob.methods^) DO
&= >gt=3B >=3B>=3B IF umethods =3D NIL
>=3B >=3B>=3B = > OR AtomList.Member(
>=3B >=3B>=3B = > umethods=2C ob.methods[i].name) THEN
>=3B >=3B>=3B = > IF AtomList.Member(reserved=2C ob.methods[i].name) THEN
>=3B >=3B&g= >t=3B RAISE StablegenError.E(Atom.ToText(ob.methods[i].name)= >
>=3B >=3B>=3B &=3B" is a reserved method name = >in stable objects. "
>=3B >=3B>=3B &=3B"Must no= >t be an update method.")
>=3B >=3B>=3B END=3B
>= >=3B >=3B>=3B methods[top].name :=3D ob.methods[i].name=3B= >
>=3B >=3B>=3B methods[top].sig :=3D ob.methods[i].s= >ig=3B
>=3B >=3B>=3B INC(top)
>=3B >=3B>=3B = > END
>=3B >=3B>=3B END=3B
>=3B >=3B>= >=3B RETURN methods
>=3B >=3B>=3B | Type.Opaque (= >op) =3D>=3B
>=3B >=3B>=3B RETURN Search(op.revealedSup= >erType=2C count=2C top=2C umethods)
>=3B >=3B>=3B | Type.R= >eference =3D>=3B <=3B*ASSERT FALSE*>=3B
>=3B >=3B>=3B = > END
>=3B >=3B>=3B END
>=3B >=3B>=3B END Searc= >h=3B
>=3B >=3B>=3B
>=3B >=3B>=3B I think we can't expect= > gcc -Wall -Werror to pass.
>=3B >=3B>=3B I really wanted it to=2C= > and I tried=2C and I fixed stuff.
>=3B >=3B>=3B But I don't think= > it is viable.
>=3B >=3B>=3B Ok?
>=3B >=3B
>=3B >=3B= >Could it be that the TYPECASE doesn't have an ELSE clause=2C possibly
&= >gt=3B >=3Btranslated to a switch withouy a default: label? This would gi= >ve the
>=3B >=3BC code an apparent path to the end of the function. = > M3 may know that
>=3B >=3Bthe TYPECASE exhausts all the possibiliti= >es=2C but C will not.
>=3B >=3B
>=3B >=3B-- hendrik
= >
>= > >--_ad389312-f922-410e-bb8f-e7106388428f_-- From jay.krell at cornell.edu Tue Dec 18 20:12:53 2012 From: jay.krell at cornell.edu (Jay K) Date: Tue, 18 Dec 2012 19:12:53 +0000 Subject: [M3devel] suggested Target.Int change In-Reply-To: References: , Message-ID: Here is the suggested change. Ok? Index: m3middle/src/TInt.i3 =================================================================== RCS file: /usr/cvs/cm3/m3-sys/m3middle/src/TInt.i3,v retrieving revision 1.34 diff -u -r1.34 TInt.i3 --- m3middle/src/TInt.i3 15 Dec 2010 16:10:46 -0000 1.34 +++ m3middle/src/TInt.i3 18 Dec 2012 18:43:44 -0000 @@ -33,8 +33,8 @@ Max16 = Int{16_FF, 16_7f, 16_00,..}; Min32 = Int{16_00, 16_00, 16_00, 16_80, 16_FF,..}; Max32 = Int{16_FF, 16_FF, 16_FF, 16_7f, 16_00,..}; - Min64 = Int{16_00, 16_00, 16_00, 16_00, 16_00, 16_00, 16_00, 16_80}; - Max64 = Int{16_FF, 16_FF, 16_FF, 16_FF, 16_FF, 16_FF, 16_FF, 16_7f}; + Min64 = Int{16_00, 16_00, 16_00, 16_00, 16_00, 16_00, 16_00, 16_80, 16_FF}; + Max64 = Int{16_FF, 16_FF, 16_FF, 16_FF, 16_FF, 16_FF, 16_FF, 16_7f, 0}; PROCEDURE FromInt (x: INTEGER; VAR i: Int): BOOLEAN; (* converts a host integer 'x' to a target integer 'i' *) Index: m3middle/src/TWord.i3 =================================================================== RCS file: /usr/cvs/cm3/m3-sys/m3middle/src/TWord.i3,v retrieving revision 1.11 diff -u -r1.11 TWord.i3 --- m3middle/src/TWord.i3 27 Feb 2010 00:43:06 -0000 1.11 +++ m3middle/src/TWord.i3 18 Dec 2012 18:43:44 -0000 @@ -26,7 +26,7 @@ Max8 = Int{16_FF, 0, ..}; Max16 = Int{16_FF, 16_FF, 0, ..}; Max32 = Int{16_FF, 16_FF, 16_FF, 16_FF, 0, ..}; - Max64 = Int{16_FF, 16_FF, 16_FF, 16_FF, 16_FF, 16_FF, 16_FF, 16_FF}; + Max64 = Int{16_FF, 16_FF, 16_FF, 16_FF, 16_FF, 16_FF, 16_FF, 16_FF, 0}; PROCEDURE New (READONLY chars: ARRAY OF CHAR; base: [2..16]; VAR i: Int): BOOLEAN; Index: m3middle/src/Target.i3 =================================================================== RCS file: /usr/cvs/cm3/m3-sys/m3middle/src/Target.i3,v retrieving revision 1.70 diff -u -r1.70 Target.i3 --- m3middle/src/Target.i3 4 Sep 2012 15:11:09 -0000 1.70 +++ m3middle/src/Target.i3 18 Dec 2012 18:43:44 -0000 @@ -224,7 +226,7 @@ element of the array. *) TYPE - Int = (* OPAQUE *) ARRAY [0..7] OF IByte; + Int = (* OPAQUE *) ARRAY [0..8] OF IByte; IByte = BITS 8 FOR [0..16_ff]; TYPE As a follow up, TWord could change so that many but not all of its procedure are just constants assigned from TInt. i.e. INTERFACE TWord; CONST LT = TInt.LT; - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Subject: suggested Target.Int change Date: Thu, 13 Dec 2012 08:32:27 +0000 [added subject] I strongly suggest that Target.Int be extended from 8 bytes to 9. The reason is thus: I was trying to mix TWord and TInt in M3C.m3. It become tedious and error prone. If Target.Int were extended to 9 bytes internally, then it would have a range exceeding a signed 64bit integer and a full range unsigned 64bit integer, and the need for TWord would, I believe, go away. The result would be *slightly* *slightly* *slightly* less efficient, but more convenient. I have already applied this change locally and built with it. It was very simple. I did have to visit the initializations of this mostly-opaque type, i.e. in Target.m3 and TInt.i3. Furthermore, I weakly suggest that Target.Int internally be changed to separately store the sign and the magnitude. This would be a hidden implementation detail and I believe it would simplify the implementation. It would *slightly* deoptimize the representation size, but the code, I think, would be smaller and simpler. This would not affect the public interface. I came to this suggestion when someone recently asked me how to implement this sort of thing. I realize it is slightly easier to store the sign and magnitude separately. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Dec 20 05:31:32 2012 From: jay.krell at cornell.edu (Jay K) Date: Thu, 20 Dec 2012 04:31:32 +0000 Subject: [M3devel] BITSIZE on constants? Message-ID: Why isn't BITSIZE valid on constants? Only on variables? Or types? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Dec 20 05:44:43 2012 From: hosking at cs.purdue.edu (Antony Hosking) Date: Thu, 20 Dec 2012 15:44:43 +1100 Subject: [M3devel] BITSIZE on constants? In-Reply-To: References: Message-ID: <12EE7CD0-CD58-478F-8B22-571EAD172758@cs.purdue.edu> Constants don?t occupy any storage. So they have no size. On Dec 20, 2012, at 3:31 PM, Jay K wrote: > Why isn't BITSIZE valid on constants? Only on variables? Or types? > > - Jay > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Dec 20 06:08:25 2012 From: jay.krell at cornell.edu (Jay) Date: Wed, 19 Dec 2012 21:08:25 -0800 Subject: [M3devel] BITSIZE on constants? In-Reply-To: <12EE7CD0-CD58-478F-8B22-571EAD172758@cs.purdue.edu> References: <12EE7CD0-CD58-478F-8B22-571EAD172758@cs.purdue.edu> Message-ID: <6090D9C2-ED9E-42FF-9C8B-0A594C934DFC@gmail.com> Eh? isn't bitsize(type) valid? It is in C and seems confroversy-free. - Jay (briefly/pocket-sized-computer-aka-phone) On Dec 19, 2012, at 8:44 PM, Antony Hosking wrote: > Constants don?t occupy any storage. So they have no size. > > > On Dec 20, 2012, at 3:31 PM, Jay K wrote: > >> Why isn't BITSIZE valid on constants? Only on variables? Or types? >> >> - Jay >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Thu Dec 20 18:16:32 2012 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 20 Dec 2012 11:16:32 -0600 Subject: [M3devel] BITSIZE on constants? In-Reply-To: <6090D9C2-ED9E-42FF-9C8B-0A594C934DFC@gmail.com> References: <12EE7CD0-CD58-478F-8B22-571EAD172758@cs.purdue.edu> <6090D9C2-ED9E-42FF-9C8B-0A594C934DFC@gmail.com> Message-ID: <50D347F0.8010508@lcwb.coop> On 12/19/2012 11:08 PM, Jay wrote: > Eh? isn't bitsize(type) valid? It is in C and seems confroversy-free. BITSIZE(type) (and BYTESIZE and ADRSIZE) is indeed valid on a _type_ in Modula-3. At the last paragraph of 2.6.13, it is defined as the size of a _variable_ of that type. The whole idea is that a compiler should not be obligated to store a constant in memory. Presumably, you know statically what the type of a CONST is, so can't you just use BITSIZE(TypeOfConst)? If you later changed the constant to a different type, it wouldn't self-adapt, but likely other places wouldn't either, or maybe would, but not correctly for your program. > > - Jay (briefly/pocket-sized-computer-aka-phone) > > On Dec 19, 2012, at 8:44 PM, Antony Hosking > wrote: > >> Constants don?t occupy any storage. So they have no size. >> >> >> On Dec 20, 2012, at 3:31 PM, Jay K <jay.krell at cornell.edu > wrote: >> >>> Why isn't BITSIZE valid on constants? Only on variables? Or types? >>> >>> - Jay >>> >>> >> From hendrik at topoi.pooq.com Thu Dec 20 19:08:08 2012 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Thu, 20 Dec 2012 13:08:08 -0500 Subject: [M3devel] BITSIZE on constants? In-Reply-To: <50D347F0.8010508@lcwb.coop> References: <12EE7CD0-CD58-478F-8B22-571EAD172758@cs.purdue.edu> <6090D9C2-ED9E-42FF-9C8B-0A594C934DFC@gmail.com> <50D347F0.8010508@lcwb.coop> Message-ID: <20121220180808.GC26848@topoi.pooq.com> On Thu, Dec 20, 2012 at 11:16:32AM -0600, Rodney M. Bates wrote: > > > On 12/19/2012 11:08 PM, Jay wrote: > >Eh? isn't bitsize(type) valid? It is in C and seems confroversy-free. > > BITSIZE(type) (and BYTESIZE and ADRSIZE) is indeed valid on a _type_ in > Modula-3. At the last paragraph of 2.6.13, it is defined as the size of a > _variable_ of that type. The whole idea is that a compiler should not be > obligated to store a constant in memory. > > Presumably, you know statically what the type of a CONST is, so can't you > just use BITSIZE(TypeOfConst)? If you later changed the constant > to a different type, it wouldn't self-adapt, but likely other places wouldn't > either, or maybe would, but not correctly for your program. Consider BITSIZE(-3). Doesn't it make a difference whether this -3 is to be considered as of type -3..0 or INTEGER, or even -3..-3? THis isn't inherent in the constant, and might on some implementations give BITSIZEs of 2, 64, or even 0, respectively, if meaningful. And if you were to change the language syntax so you'd always have to write something like (-3..0)(-3) to be explicit you'd end up writing everything you's write with BITSIZE(TypeOfConst) and more. What you might gain is a static check that the constant isn't out of bounds. -- hendrik From jay.krell at cornell.edu Thu Dec 20 21:50:36 2012 From: jay.krell at cornell.edu (Jay K) Date: Thu, 20 Dec 2012 20:50:36 +0000 Subject: [M3devel] BITSIZE on constants? In-Reply-To: <20121220180808.GC26848@topoi.pooq.com> References: , <12EE7CD0-CD58-478F-8B22-571EAD172758@cs.purdue.edu>, <6090D9C2-ED9E-42FF-9C8B-0A594C934DFC@gmail.com>, <50D347F0.8010508@lcwb.coop>, <20121220180808.GC26848@topoi.pooq.com> Message-ID: I think go has untyped constants. But I think Modula-3 constants (expressions) always have a type independent of their use. - Jay > Date: Thu, 20 Dec 2012 13:08:08 -0500 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] BITSIZE on constants? > > On Thu, Dec 20, 2012 at 11:16:32AM -0600, Rodney M. Bates wrote: > > > > > > On 12/19/2012 11:08 PM, Jay wrote: > > >Eh? isn't bitsize(type) valid? It is in C and seems confroversy-free. > > > > BITSIZE(type) (and BYTESIZE and ADRSIZE) is indeed valid on a _type_ in > > Modula-3. At the last paragraph of 2.6.13, it is defined as the size of a > > _variable_ of that type. The whole idea is that a compiler should not be > > obligated to store a constant in memory. > > > > Presumably, you know statically what the type of a CONST is, so can't you > > just use BITSIZE(TypeOfConst)? If you later changed the constant > > to a different type, it wouldn't self-adapt, but likely other places wouldn't > > either, or maybe would, but not correctly for your program. > > Consider BITSIZE(-3). Doesn't it make a difference whether this -3 is > to be considered as of type -3..0 or INTEGER, or even -3..-3? THis > isn't inherent in the constant, and might on some implementations give > BITSIZEs of 2, 64, or even 0, respectively, if meaningful. > > And if you were to change the language syntax so you'd always have to > write something like (-3..0)(-3) to be explicit you'd end up writing > everything you's write with BITSIZE(TypeOfConst) and more. What you > might gain is a static check that the constant isn't out of bounds. > > -- hendrik -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Thu Dec 20 23:34:07 2012 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 20 Dec 2012 16:34:07 -0600 Subject: [M3devel] BITSIZE on constants? In-Reply-To: References: , <12EE7CD0-CD58-478F-8B22-571EAD172758@cs.purdue.edu>, <6090D9C2-ED9E-42FF-9C8B-0A594C934DFC@gmail.com>, <50D347F0.8010508@lcwb.coop>, <20121220180808.GC26848@topoi.pooq.com> Message-ID: <50D3925F.4090204@lcwb.coop> On 12/20/2012 02:50 PM, Jay K wrote: > I think go has untyped constants. Ada has them too, but the rules for when they get implicitly converted to a runtime type are, well, IMO, bizarre. Even if they were more straightforward, there is inevitably a lot of complexity here that few working programmers will learn or think about, instead hoping everything will "just work". This can only be according their individual idea of how it should work, which is nowhere close to being either obvious or universal. Thus do very subtle bugs occasionally occur, and cause grief all out of proportion to their frequency. > But I think Modula-3 constants (expressions) always have a type independent of their use. Yes. All in 2.4.2: You can give a constant a type explicitly: CONST C : [ - 3 .. 0 ] = - 2; in which case, the value must be a member of the type. Or you can omit it, in which case, the type of the constant is the type of the _expression_. CONST D = - 2; There are many values that belong to more than one type (e.g., - 2 belongs to any subrange of INTEGER that contains it). But every expression has exactly one type. In this case, the type of every integer literal is INTEGER. And unary "-" applied to an INTEGER also has type INTEGER, which is the type of D. BTW, this is why we need different spellings for INTEGER and LONGINT literals, e.g. 10 and 10L. It avoids a morass of implied type conversion rules, etc., that the language already avoided before LONGINT. In fact, the same idea is in the original language for the floating point literals, with "E". "D", or "X" in the literal spelling, to uniquely denote its type. > > - Jay > > > > Date: Thu, 20 Dec 2012 13:08:08 -0500 > > From: hendrik at topoi.pooq.com > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] BITSIZE on constants? > > > > On Thu, Dec 20, 2012 at 11:16:32AM -0600, Rodney M. Bates wrote: > > > > > > > > > On 12/19/2012 11:08 PM, Jay wrote: > > > >Eh? isn't bitsize(type) valid? It is in C and seems confroversy-free. > > > > > > BITSIZE(type) (and BYTESIZE and ADRSIZE) is indeed valid on a _type_ in > > > Modula-3. At the last paragraph of 2.6.13, it is defined as the size of a > > > _variable_ of that type. The whole idea is that a compiler should not be > > > obligated to store a constant in memory. > > > > > > Presumably, you know statically what the type of a CONST is, so can't you > > > just use BITSIZE(TypeOfConst)? If you later changed the constant > > > to a different type, it wouldn't self-adapt, but likely other places wouldn't > > > either, or maybe would, but not correctly for your program. > > > > Consider BITSIZE(-3). Doesn't it make a difference whether this -3 is > > to be considered as of type -3..0 or INTEGER, or even -3..-3? THis > > isn't inherent in the constant, and might on some implementations give > > BITSIZEs of 2, 64, or even 0, respectively, if meaningful. > > > > And if you were to change the language syntax so you'd always have to > > write something like (-3..0)(-3) to be explicit you'd end up writing > > everything you's write with BITSIZE(TypeOfConst) and more. What you > > might gain is a static check that the constant isn't out of bounds. > > > > -- hendrik From jay.krell at cornell.edu Fri Dec 21 02:16:43 2012 From: jay.krell at cornell.edu (Jay K) Date: Fri, 21 Dec 2012 01:16:43 +0000 Subject: [M3devel] BITSIZE on constants? In-Reply-To: <50D3925F.4090204@lcwb.coop> References: , , <12EE7CD0-CD58-478F-8B22-571EAD172758@cs.purdue.edu>, , <6090D9C2-ED9E-42FF-9C8B-0A594C934DFC@gmail.com>, , <50D347F0.8010508@lcwb.coop>, , <20121220180808.GC26848@topoi.pooq.com>, , <50D3925F.4090204@lcwb.coop> Message-ID: I am NOT asking for untyped constants. Constants are typed, and BITSIZE ought to work on them. That is what I am asking for: CONST a = 1; CONST b = BITSIZE(a); - Jay > Date: Thu, 20 Dec 2012 16:34:07 -0600 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: Re: [M3devel] BITSIZE on constants? > > > > On 12/20/2012 02:50 PM, Jay K wrote: > > I think go has untyped constants. > > Ada has them too, but the rules for when they get implicitly converted to a runtime > type are, well, IMO, bizarre. > > Even if they were more straightforward, there is inevitably a lot of complexity here > that few working programmers will learn or think about, instead hoping everything > will "just work". This can only be according their individual idea of how it > should work, which is nowhere close to being either obvious or universal. Thus > do very subtle bugs occasionally occur, and cause grief all out of proportion to > their frequency. > > > But I think Modula-3 constants (expressions) always have a type independent of their use. > > Yes. All in 2.4.2: > > You can give a constant a type explicitly: > > CONST C : [ - 3 .. 0 ] = - 2; > > in which case, the value must be a member of the type. > > Or you can omit it, in which case, the type of the constant is the type > of the _expression_. > > CONST D = - 2; > > There are many values that belong to more than one type (e.g., - 2 > belongs to any subrange of INTEGER that contains it). But every > expression has exactly one type. In this case, the type of every > integer literal is INTEGER. And unary "-" applied to an INTEGER > also has type INTEGER, which is the type of D. > > BTW, this is why we need different spellings for INTEGER and > LONGINT literals, e.g. 10 and 10L. It avoids a morass of implied > type conversion rules, etc., that the language already avoided > before LONGINT. In fact, the same idea is in the original > language for the floating point literals, with "E". "D", or > "X" in the literal spelling, to uniquely denote its type. > > > > > - Jay > > > > > > > Date: Thu, 20 Dec 2012 13:08:08 -0500 > > > From: hendrik at topoi.pooq.com > > > To: m3devel at elegosoft.com > > > Subject: Re: [M3devel] BITSIZE on constants? > > > > > > On Thu, Dec 20, 2012 at 11:16:32AM -0600, Rodney M. Bates wrote: > > > > > > > > > > > > On 12/19/2012 11:08 PM, Jay wrote: > > > > >Eh? isn't bitsize(type) valid? It is in C and seems confroversy-free. > > > > > > > > BITSIZE(type) (and BYTESIZE and ADRSIZE) is indeed valid on a _type_ in > > > > Modula-3. At the last paragraph of 2.6.13, it is defined as the size of a > > > > _variable_ of that type. The whole idea is that a compiler should not be > > > > obligated to store a constant in memory. > > > > > > > > Presumably, you know statically what the type of a CONST is, so can't you > > > > just use BITSIZE(TypeOfConst)? If you later changed the constant > > > > to a different type, it wouldn't self-adapt, but likely other places wouldn't > > > > either, or maybe would, but not correctly for your program. > > > > > > Consider BITSIZE(-3). Doesn't it make a difference whether this -3 is > > > to be considered as of type -3..0 or INTEGER, or even -3..-3? THis > > > isn't inherent in the constant, and might on some implementations give > > > BITSIZEs of 2, 64, or even 0, respectively, if meaningful. > > > > > > And if you were to change the language syntax so you'd always have to > > > write something like (-3..0)(-3) to be explicit you'd end up writing > > > everything you's write with BITSIZE(TypeOfConst) and more. What you > > > might gain is a static check that the constant isn't out of bounds. > > > > > > -- hendrik > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Dec 21 11:00:08 2012 From: jay.krell at cornell.edu (Jay K) Date: Fri, 21 Dec 2012 10:00:08 +0000 Subject: [M3devel] repeat evaluation in check_range/hi/low/index/nil? Message-ID: I was going to fix M3C to allocate temporaries to avoid repeat evaluation for check_hi/lo/range/index/nil. I went looking at cm3cg, to confirm that check_eq is different -- it pops its inputs, so no need for a temporary there. Ok. And then, it doesn't look like cm3cg avoids the repeat evaluation? Still I should do it? It never matters, because frontend allocates temporaries for all function call return values? (It seems to.) Therefore whatever is repeatedly evaluated, has no side effects? And because "assignment isn't expression" -- store pops its value from the stack. I think. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Thu Dec 27 16:10:29 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Thu, 27 Dec 2012 15:10:29 +0000 (GMT) Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20121224201107.F2C89CCA97@birch.elegosoft.com> Message-ID: <1356621029.55706.YahooMailClassic@web133103.mail.ir2.yahoo.com> Hi Jay: even if this does not work OK for you doesn't mean you can break code clarity, please reconsider writing values instead of constants it can lead to misunderstand the purpose of those values (even if there are limitations in current implementation). Anyway, the CONS values must be transparent bit converted from decimal arithmetic. Why don't you convert it from it and solve this in Modula-3 style. Take my advice, but if not explain me please why not so Thanks in advance --- El lun, 24/12/12, Jay Krell escribi?: De: Jay Krell Asunto: [M3commit] CVS Update: cm3 Para: m3commit at elegosoft.com Fecha: lunes, 24 de diciembre, 2012 16:11 CVSROOT:??? /usr/cvs Changes by:??? jkrell at birch.??? 12/12/24 21:11:07 Modified files: ??? cm3/m3-sys/m3middle/src/: Target.i3 Log message: ??? remove new internal_Real_max, internal_Longreal_max and ??? copy around the values 3.40282346638528860x+38, 1.79769313486231570x+308 ??? intead of expanding the public interface -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Dec 6 09:26:33 2012 From: jay.krell at cornell.edu (Jay K) Date: Thu, 6 Dec 2012 08:26:33 +0000 Subject: [M3devel] redundant range checks? Message-ID: m3-libs/m3core/src/fingerprint/Poly.i3 Int32 = [-16_7fffffff-1 .. 16_7fffffff]; T = ARRAY [0..1] OF Int32; m3-libs/m3core/src/fingerprint/Poly.m3 PROCEDURE Sum (READONLY p, q: T) : T = VAR r : T; BEGIN r[0] := Word.Xor (p[0], q[0]); line 48 r[1] := Word.Xor (p[1], q[1]); RETURN r; END Sum; -----LINE 48 ----- load v.5 0 Addr Addr load_indirect 0 Int.32 Int.64 load v.6 0 Addr Addr load_indirect 0 Int.32 Int.64 xor Word.64 ... check_range Int.64 -2147483648 2147483647 1 if((((INT64)(((UINT64)(((UINT64)(((INT64)(*((INT32*)(p_L_7)))))) ^((UINT64)(((INT64)(*((INT32*)(q_L_8)))))))))) <((INT64)(M3_INT64(-2147483648)))) || (((INT64)(M3_INT64(2147483647))) < ((INT64)(((UINT64)(((UINT64)(((INT64)(*((INT32*)(p_L_7))))))^((UINT64)(((INT64)(*((INT32*)(q_L_8))))))))))))M_Poly_L_4_CRASH(1537); Poly.mc.c:325: warning: comparison is always false due to limited range of data type or, like: typedef long long INT64; typedef unsigned long long UINT64; typedef int INT32; #define MAXINT32 2147483647 #define MININT32 (-2147483648) void ReportFault(void); #define AssignINT64ToINT32(a, b) \ if (((INT64)(b)) < MININT32 || ((INT64)(b)) > MAXINT32) ReportFault(); \ a = (INT32)(INT64)(b); \ INT32 Sum(INT32 p, INT32 q) { INT32 r; AssignINT64ToINT32(r, ((UINT64)(INT64)*(INT32*)&p) ^ ((UINT64)(INT64)*(INT32*)&q)); // or this AssignINT64ToINT32(r, ((UINT64)(INT64)p) ^ ((UINT64)(INT64)q)); // or heck even this AssignINT64ToINT32(r, p ^ q); return r; } the operands get widened from 32bits to 64bits, operation done, then range checked, and assigned back to 32bits. The range check is redundant. It is subtle. 32bit operands sign extended to 64bits will succeed the range check. The upper bits will all be set or clear. If you xor them, the upper bits will still be either all set or all clear, which succeeds the range check. The C compiler notices it and warns. I'd like to avoid warnings. I think the frontend could catch this, easily enough. Thoughts? I'm just about in position to fix this in the C backend. But it'd be cool if the frontend did some cheap analysis always. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Dec 13 09:25:48 2012 From: jay.krell at cornell.edu (Jay K) Date: Thu, 13 Dec 2012 08:25:48 +0000 Subject: [M3devel] (no subject) Message-ID: I strongly suggest that Target.Int be extended from 8 bytes to 9. The reason is thus: I was trying to mix TWord and TInt in M3C.m3. It become tedious and error prone. If Target.Int were extended to 9 bytes internally, then it would have a range exceeding a signed 64bit integer and a full range unsigned 64bit integer, and the need for TWord would, I believe, go away. The result would be *slightly* *slightly* *slightly* less efficient, but more convenient. I have already applied this change locally and built with it. It was very simple. I did have to visit the initializations of this mostly-opaque type, i.e. in Target.m3 and TInt.i3. Furthermore, I weakly suggest that Target.Int internally be changed to separately store the sign and the magnitude. This would be a hidden implementation detail and I believe it would simplify the implementation. It would *slightly* deoptimize the representation size, but the code, I think, would be smaller and simpler. This would not affect the public interface. I came to this suggestion when someone recently asked me how to implement this sort of thing. I realize it is slightly easier to store the sign and magnitude separately. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Dec 13 09:32:27 2012 From: jay.krell at cornell.edu (Jay K) Date: Thu, 13 Dec 2012 08:32:27 +0000 Subject: [M3devel] suggested Target.Int change In-Reply-To: References: Message-ID: [added subject] I strongly suggest that Target.Int be extended from 8 bytes to 9. The reason is thus: I was trying to mix TWord and TInt in M3C.m3. It become tedious and error prone. If Target.Int were extended to 9 bytes internally, then it would have a range exceeding a signed 64bit integer and a full range unsigned 64bit integer, and the need for TWord would, I believe, go away. The result would be *slightly* *slightly* *slightly* less efficient, but more convenient. I have already applied this change locally and built with it. It was very simple. I did have to visit the initializations of this mostly-opaque type, i.e. in Target.m3 and TInt.i3. Furthermore, I weakly suggest that Target.Int internally be changed to separately store the sign and the magnitude. This would be a hidden implementation detail and I believe it would simplify the implementation. It would *slightly* deoptimize the representation size, but the code, I think, would be smaller and simpler. This would not affect the public interface. I came to this suggestion when someone recently asked me how to implement this sort of thing. I realize it is slightly easier to store the sign and magnitude separately. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From cornstalk at columbus.rr.com Fri Dec 14 04:37:21 2012 From: cornstalk at columbus.rr.com (Mark Morss) Date: Thu, 13 Dec 2012 22:37:21 -0500 Subject: [M3devel] emacs config for modula 3 Message-ID: <1355456241.27560.4.camel@thebeast> Hello to all. I'm sorry to make this minor housekeeping issue my first post to the list, but is there another emacs person here who has the right code to insert in .emacs to make emacs-mode work from modula3.el and m3font.el? I don't seem to have it right. Best to all. From im_ikram at yahoo.com Fri Dec 14 17:50:50 2012 From: im_ikram at yahoo.com (I.M. Ikram) Date: Fri, 14 Dec 2012 08:50:50 -0800 (PST) Subject: [M3devel] emacs config for modula 3 Message-ID: <1355503850.94677.YahooMailNeo@web162603.mail.bf1.yahoo.com> Hi. I'm another first-time poster here... > right code to insert in .emacs to make emacs-mode work from modula3.el > and m3font.el? I don't seem to have it right. The following snippet is from my .emacs: (add-to-list 'load-path "/path/to/modula3mode/directory") (autoload 'modula-3-mode "modula3") (load "m3font") ;; <--- enables syntax highlighting (setq auto-mode-alist (append '(("\\.ig$" . modula-3-mode) ("\\.mg$" . modula-3-mode) ("\\.i3$" . modula-3-mode) ("\\.m3$" . modula-3-mode)) auto-mode-alist)) Copied from the docs at http://modula3.elegosoft.com/cm3/doc/help/cm3/gnuemacs.html However, the indicated 'load' line is missing in those instructions. From dragisha at m3w.org Sat Dec 15 09:13:11 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sat, 15 Dec 2012 09:13:11 +0100 Subject: [M3devel] emacs config for modula 3 In-Reply-To: <1355503850.94677.YahooMailNeo@web162603.mail.bf1.yahoo.com> References: <1355503850.94677.YahooMailNeo@web162603.mail.bf1.yahoo.com> Message-ID: In my .emacs: (load-file "~/.emacs.d/modula3.el") (setq auto-mode-alist (append '(("\\.[im][3g]$" . modula-3-mode)) auto-mode-alist)) (setq completion-ignored-extensions (append '(".mo" ".mx" ".mc" ".io" ".ix") completion-ignored-extensions)) And I just copied modula3.el from cm3 distribution. No m3font needed for syntax highlighting, at least in my Aquamacs. I don't see m3font anywhere, it's some old version, maybe? Anyway - it just works. dd -- Divided by a common language Dragi?a Duri? dragisha at m3w.org On Dec 14, 2012, at 5:50 PM, I.M. Ikram wrote: > Hi. I'm another first-time poster here... > >> right code to insert in .emacs to make emacs-mode work from modula3.el >> and m3font.el? I don't seem to have it right. > > The following snippet is from my .emacs: > > (add-to-list 'load-path "/path/to/modula3mode/directory") > (autoload 'modula-3-mode "modula3") > (load "m3font") ;; <--- enables syntax highlighting > (setq auto-mode-alist > (append '(("\\.ig$" . modula-3-mode) > ("\\.mg$" . modula-3-mode) > ("\\.i3$" . modula-3-mode) > ("\\.m3$" . modula-3-mode)) > auto-mode-alist)) > > Copied from the docs at > http://modula3.elegosoft.com/cm3/doc/help/cm3/gnuemacs.html > However, the indicated 'load' line is missing in those instructions. > From jay.krell at cornell.edu Sun Dec 16 10:58:10 2012 From: jay.krell at cornell.edu (Jay K) Date: Sun, 16 Dec 2012 09:58:10 +0000 Subject: [M3devel] thouhts on -Wall with C backend output Message-ID: I've tried to generate "very good C". I've fixed some of what gcc -Wall complains about. For default gcc on my old MacBook -- old enough that it can still emulate PowerPC, gcc is 4.0.1. (at least one of what I deal with, I think anything newer won't complain..) do-cm3-all with -Wall -Werror gets very far, to: == package /Users/jay/dev2/cm3/m3-db/stablegen == +++ /cm3/bin/cm3 -build -DROOT=/Users/jay/dev2/cm3 +++ --- building in AMD64_DARWIN --- ignoring ../src/m3overrides w source -> compiling GenCode.m3 cc1: warnings being treated as errors GenCode.mc.c: In function ?GenCode__BuildMethods__Search?: GenCode.mc.c:3505: warning: control reaches end of non-void function m3_backend => 1 PROCEDURE Search ( type : Type.Reference; VAR count : INTEGER; VAR top : CARDINAL; umethods: AtomList.T ): ImportList.MethodList RAISES {StablegenError.E} = VAR methods: ImportList.MethodList; BEGIN IF (type = Type.root) OR (type = NIL) THEN (* base of recursion *) RETURN NEW(ImportList.MethodList, ABS(count)) ELSE TYPECASE type OF Type.Object (ob) => IF count <= 0 THEN count:= count - NUMBER(ob.methods^) END; methods := Search(ob.super, count, top, umethods); FOR i := 0 TO LAST(ob.methods^) DO IF umethods = NIL OR AtomList.Member( umethods, ob.methods[i].name) THEN IF AtomList.Member(reserved, ob.methods[i].name) THEN RAISE StablegenError.E(Atom.ToText(ob.methods[i].name) &" is a reserved method name in stable objects. " &"Must not be an update method.") END; methods[top].name := ob.methods[i].name; methods[top].sig := ob.methods[i].sig; INC(top) END END; RETURN methods | Type.Opaque (op) => RETURN Search(op.revealedSuperType, count, top, umethods) | Type.Reference => <*ASSERT FALSE*> END END END Search; I think we can't expect gcc -Wall -Werror to pass. I really wanted it to, and I tried, and I fixed stuff. But I don't think it is viable. Ok? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sun Dec 16 15:01:07 2012 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 16 Dec 2012 15:01:07 +0100 Subject: [M3devel] thouhts on -Wall with C backend output In-Reply-To: References: Message-ID: <20121216150107.efba68a3.wagner@elegosoft.com> On Sun, 16 Dec 2012 09:58:10 +0000 Jay K wrote: > -Wall -Werror I don't think it should be mandatory for our generated C code to pass this test, as long as we (you or somebody else ;-) are convinced that it's semantically correct. Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From rodney_bates at lcwb.coop Sun Dec 16 17:24:06 2012 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sun, 16 Dec 2012 10:24:06 -0600 Subject: [M3devel] thouhts on -Wall with C backend output In-Reply-To: References: Message-ID: <50CDF5A6.60400@lcwb.coop> You know, here is my view on the whole subject. A compiler, used in the usual way, has two functions: help to find a lot of programming errors that are statically detectable, and translate to machine code. When you feed a compiler with mechanically produced source code, the former function is not really that important. Ideally, the translator (including its own front end, in this case, the M3 front end) should take care of all the static error checking and just produce code that will translate properly. So once the translator is stable, it makes sense for ordinary users to ignore warnings from the back end compiler. They may still be very useful for testing the translator. I know this is a bit idealistic, and it takes more work for the translator developer to do it this way. But it's best for the user. Trying to correlate a warning (or error) issued by the back end compiler back to the original problem (if there is one) in the original source code can be exasperating for a user. So I'd say put the effort into making sure anything a user should care about is detected by the M3 front end and/or M3C. Then tell your users not to worry about messages from gcc. Yeah, I know this ignores the question of a user's wondering of messages from gcc are actually evidence of bugs in M3front/M3C. On 12/16/2012 03:58 AM, Jay K wrote: > I've tried to generate "very good C". > I've fixed some of what gcc -Wall complains about. > For default gcc on my old MacBook -- old enough that it can still emulate PowerPC, gcc is 4.0.1. > (at least one of what I deal with, I think anything newer won't complain..) > > > > do-cm3-all with -Wall -Werror gets very far, to: > > == package /Users/jay/dev2/cm3/m3-db/stablegen == > > +++ /cm3/bin/cm3 -build -DROOT=/Users/jay/dev2/cm3 +++ > --- building in AMD64_DARWIN --- > > ignoring ../src/m3overrides > > w source -> compiling GenCode.m3 > cc1: warnings being treated as errors > GenCode.mc.c: In function ?GenCode__BuildMethods__Search?: > GenCode.mc.c:3505: warning: control reaches end of non-void function > m3_backend => 1 > > PROCEDURE Search ( type : Type.Reference; > VAR count : INTEGER; > VAR top : CARDINAL; > umethods: AtomList.T ): > ImportList.MethodList RAISES {StablegenError.E} = > VAR methods: ImportList.MethodList; > BEGIN > IF (type = Type.root) OR (type = NIL) THEN (* base of > recursion *) > RETURN NEW(ImportList.MethodList, ABS(count)) > ELSE > TYPECASE type OF > Type.Object (ob) => > IF count <= 0 THEN > count:= count - NUMBER(ob.methods^) > END; > methods := Search(ob.super, count, top, umethods); > FOR i := 0 TO LAST(ob.methods^) DO > IF umethods = NIL > OR AtomList.Member( > umethods, ob.methods[i].name) THEN > IF AtomList.Member(reserved, ob.methods[i].name) THEN > RAISE StablegenError.E(Atom.ToText(ob.methods[i].name) > &" is a reserved method name in stable objects. " > &"Must not be an update method.") > END; > methods[top].name := ob.methods[i].name; > methods[top].sig := ob.methods[i].sig; > INC(top) > END > END; > RETURN methods > | Type.Opaque (op) => > RETURN Search(op.revealedSuperType, count, top, umethods) > | Type.Reference => <*ASSERT FALSE*> > END > END > END Search; > > I think we can't expect gcc -Wall -Werror to pass. > I really wanted it to, and I tried, and I fixed stuff. > But I don't think it is viable. > Ok? > > > - Jay From hendrik at topoi.pooq.com Sun Dec 16 19:43:06 2012 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Sun, 16 Dec 2012 13:43:06 -0500 Subject: [M3devel] thouhts on -Wall with C backend output In-Reply-To: References: Message-ID: <20121216184306.GA29473@topoi.pooq.com> On Sun, Dec 16, 2012 at 09:58:10AM +0000, Jay K wrote: > > I've tried to generate "very good C". > I've fixed some of what gcc -Wall complains about. > For default gcc on my old MacBook -- old enough that it can still emulate PowerPC, gcc is 4.0.1. > (at least one of what I deal with, I think anything newer won't complain..) > > > > do-cm3-all with -Wall -Werror gets very far, to: > > == package /Users/jay/dev2/cm3/m3-db/stablegen == > > +++ /cm3/bin/cm3 -build -DROOT=/Users/jay/dev2/cm3 +++ > --- building in AMD64_DARWIN --- > > ignoring ../src/m3overrides > > w source -> compiling GenCode.m3 > cc1: warnings being treated as errors > GenCode.mc.c: In function ?GenCode__BuildMethods__Search?: > GenCode.mc.c:3505: warning: control reaches end of non-void function > m3_backend => 1 > > PROCEDURE Search ( type : Type.Reference; > VAR count : INTEGER; > VAR top : CARDINAL; > umethods: AtomList.T ): > ImportList.MethodList RAISES {StablegenError.E} = > VAR methods: ImportList.MethodList; > BEGIN > IF (type = Type.root) OR (type = NIL) THEN (* base of > recursion *) > RETURN NEW(ImportList.MethodList, ABS(count)) > ELSE > TYPECASE type OF > Type.Object (ob) => > IF count <= 0 THEN > count:= count - NUMBER(ob.methods^) > END; > methods := Search(ob.super, count, top, umethods); > FOR i := 0 TO LAST(ob.methods^) DO > IF umethods = NIL > OR AtomList.Member( > umethods, ob.methods[i].name) THEN > IF AtomList.Member(reserved, ob.methods[i].name) THEN > RAISE StablegenError.E(Atom.ToText(ob.methods[i].name) > &" is a reserved method name in stable objects. " > &"Must not be an update method.") > END; > methods[top].name := ob.methods[i].name; > methods[top].sig := ob.methods[i].sig; > INC(top) > END > END; > RETURN methods > | Type.Opaque (op) => > RETURN Search(op.revealedSuperType, count, top, umethods) > | Type.Reference => <*ASSERT FALSE*> > END > END > END Search; > > I think we can't expect gcc -Wall -Werror to pass. > I really wanted it to, and I tried, and I fixed stuff. > But I don't think it is viable. > Ok? Could it be that the TYPECASE doesn't have an ELSE clause, possibly translated to a switch withouy a default: label? This would give the C code an apparent path to the end of the function. M3 may know that the TYPECASE exhausts all the possibilities, but C will not. -- hendrik From mika at async.caltech.edu Sun Dec 16 19:55:29 2012 From: mika at async.caltech.edu (mika at async.caltech.edu) Date: Sun, 16 Dec 2012 10:55:29 -0800 Subject: [M3devel] thouhts on -Wall with C backend output In-Reply-To: <20121216184306.GA29473@topoi.pooq.com> References: <20121216184306.GA29473@topoi.pooq.com> Message-ID: <20121216185529.AD9681A2094@async.async.caltech.edu> Can you have an option to add an assertion in the output for these cases? Here either 1. gcc has found a bug in the C code generator and/or front end, in that there's no default (abortion) case or 2. the front end has deduced there is no need for abortion because it can see that the missing ELSE is never going to be exercised, based on the already existing type information What I'm proposing is two modes for the compiler: -- ignore the errors or -- add proper assertions to the C code, e.g., assert(false, "front-end deduced this cant happen by inspecting type information") which, when enabled, should make gcc shut up, and instead turn into runtime checks on the compiler Mika Hendrik Boom writes: >On Sun, Dec 16, 2012 at 09:58:10AM +0000, Jay K wrote: >> >> I've tried to generate "very good C". >> I've fixed some of what gcc -Wall complains about. >> For default gcc on my old MacBook -- old enough that it can still emulate PowerPC, gcc is 4.0.1. >> (at least one of what I deal with, I think anything newer won't complain..) >> >> >> >> do-cm3-all with -Wall -Werror gets very far, to: >> >> == package /Users/jay/dev2/cm3/m3-db/stablegen == >> >> +++ /cm3/bin/cm3 -build -DROOT=/Users/jay/dev2/cm3 +++ >> --- building in AMD64_DARWIN --- >> >> ignoring ../src/m3overrides >> >> w source -> compiling GenCode.m3 >> cc1: warnings being treated as errors >> GenCode.mc.c: In function ???GenCode__BuildMethods__Search???: >> GenCode.mc.c:3505: warning: control reaches end of non-void function >> m3_backend => 1 >> >> PROCEDURE Search ( type : Type.Reference; >> VAR count : INTEGER; >> VAR top : CARDINAL; >> umethods: AtomList.T ): >> ImportList.MethodList RAISES {StablegenError.E} = >> VAR methods: ImportList.MethodList; >> BEGIN >> IF (type = Type.root) OR (type = NIL) THEN (* base of >> recursion *) >> RETURN NEW(ImportList.MethodList, ABS(count)) >> ELSE >> TYPECASE type OF >> Type.Object (ob) => >> IF count <= 0 THEN >> count:= count - NUMBER(ob.methods^) >> END; >> methods := Search(ob.super, count, top, umethods); >> FOR i := 0 TO LAST(ob.methods^) DO >> IF umethods = NIL >> OR AtomList.Member( >> umethods, ob.methods[i].name) THEN >> IF AtomList.Member(reserved, ob.methods[i].name) THEN >> RAISE StablegenError.E(Atom.ToText(ob.methods[i].name) >> &" is a reserved method name in stable objects. " >> &"Must not be an update method.") >> END; >> methods[top].name := ob.methods[i].name; >> methods[top].sig := ob.methods[i].sig; >> INC(top) >> END >> END; >> RETURN methods >> | Type.Opaque (op) => >> RETURN Search(op.revealedSuperType, count, top, umethods) >> | Type.Reference => <*ASSERT FALSE*> >> END >> END >> END Search; >> >> I think we can't expect gcc -Wall -Werror to pass. >> I really wanted it to, and I tried, and I fixed stuff. >> But I don't think it is viable. >> Ok? > >Could it be that the TYPECASE doesn't have an ELSE clause, possibly >translated to a switch withouy a default: label? This would give the >C code an apparent path to the end of the function. M3 may know that >the TYPECASE exhausts all the possibilities, but C will not. > >-- hendrik From jay.krell at cornell.edu Mon Dec 17 08:26:29 2012 From: jay.krell at cornell.edu (Jay K) Date: Mon, 17 Dec 2012 07:26:29 +0000 Subject: [M3devel] thouhts on -Wall with C backend output In-Reply-To: <20121216185529.AD9681A2094@async.async.caltech.edu> References: , <20121216184306.GA29473@topoi.pooq.com>, <20121216185529.AD9681A2094@async.async.caltech.edu> Message-ID: drat, these are worse: "../src/Macro.m3", line 949: warning: unreachable ELSE in TYPECASE == package /Users/jay/dev2/cm3/m3-ui/formsvbt == +++ /cm3/bin/cm3 -build -DROOT=/Users/jay/dev2/cm3 +++ --- building in AMD64_DARWIN --- ignoring ../src/m3overrides new source -> compiling Macro.m3 cc1plus: warnings being treated as errors Macro.mc.c: In function ?char* Macro__EvalLength(char*, char*)?: Macro.mc.c:5271: warning: control reaches end of non-void function Macro.mc.c: In function ?char* Macro__EvalPlus(char*, char*)?: Macro.mc.c:9004: warning: control reaches end of non-void function Macro.mc.c: In function ?char* Macro__EvalMinus(char*, char*)?: Macro.mc.c:9468: warning: control reaches end of non-void function If I put in the somewhat obvious: ELSE <* ASSERT FALSE *> then: new source -> compiling Macro.m3 "../src/Macro.m3", line 949: warning: unreachable ELSE in TYPECASE 1 warning encountered cc1plus: warnings being treated as errors Macro.mc.c: In function ?char* Macro__EvalLength(char*, char*)?: Macro.mc.c:5271: warning: control reaches end of non-void function Macro.mc.c: In function ?char* Macro__EvalPlus(char*, char*)?: Macro.mc.c:9004: warning: control reaches end of non-void function For stablegen, I am inclined to put in that ELSE <* ASSERT FALSE *>. I might might might be able to put in C assert(false) in these places. - Jay > To: hendrik at topoi.pooq.com > Date: Sun, 16 Dec 2012 10:55:29 -0800 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] thouhts on -Wall with C backend output > > Can you have an option to add an assertion in the output for these cases? > > Here either > > 1. gcc has found a bug in the C code generator and/or front end, in that > there's no default (abortion) case > > or > > 2. the front end has deduced there is no need for abortion because it can > see that the missing ELSE is never going to be exercised, based on the > already existing type information > > What I'm proposing is two modes for the compiler: > > -- ignore the errors > > or > > -- add proper assertions to the C code, e.g., > > assert(false, "front-end deduced this cant happen by inspecting type information") > > which, when enabled, should make gcc shut up, and instead turn into > runtime checks on the compiler > > Mika > > Hendrik Boom writes: > >On Sun, Dec 16, 2012 at 09:58:10AM +0000, Jay K wrote: > >> > >> I've tried to generate "very good C". > >> I've fixed some of what gcc -Wall complains about. > >> For default gcc on my old MacBook -- old enough that it can still emulate PowerPC, gcc is 4.0.1. > >> (at least one of what I deal with, I think anything newer won't complain..) > >> > >> > >> > >> do-cm3-all with -Wall -Werror gets very far, to: > >> > >> == package /Users/jay/dev2/cm3/m3-db/stablegen == > >> > >> +++ /cm3/bin/cm3 -build -DROOT=/Users/jay/dev2/cm3 +++ > >> --- building in AMD64_DARWIN --- > >> > >> ignoring ../src/m3overrides > >> > >> w source -> compiling GenCode.m3 > >> cc1: warnings being treated as errors > >> GenCode.mc.c: In function ?GenCode__BuildMethods__Search?: > >> GenCode.mc.c:3505: warning: control reaches end of non-void function > >> m3_backend => 1 > >> > >> PROCEDURE Search ( type : Type.Reference; > >> VAR count : INTEGER; > >> VAR top : CARDINAL; > >> umethods: AtomList.T ): > >> ImportList.MethodList RAISES {StablegenError.E} = > >> VAR methods: ImportList.MethodList; > >> BEGIN > >> IF (type = Type.root) OR (type = NIL) THEN (* base of > >> recursion *) > >> RETURN NEW(ImportList.MethodList, ABS(count)) > >> ELSE > >> TYPECASE type OF > >> Type.Object (ob) => > >> IF count <= 0 THEN > >> count:= count - NUMBER(ob.methods^) > >> END; > >> methods := Search(ob.super, count, top, umethods); > >> FOR i := 0 TO LAST(ob.methods^) DO > >> IF umethods = NIL > >> OR AtomList.Member( > >> umethods, ob.methods[i].name) THEN > >> IF AtomList.Member(reserved, ob.methods[i].name) THEN > >> RAISE StablegenError.E(Atom.ToText(ob.methods[i].name) > >> &" is a reserved method name in stable objects. " > >> &"Must not be an update method.") > >> END; > >> methods[top].name := ob.methods[i].name; > >> methods[top].sig := ob.methods[i].sig; > >> INC(top) > >> END > >> END; > >> RETURN methods > >> | Type.Opaque (op) => > >> RETURN Search(op.revealedSuperType, count, top, umethods) > >> | Type.Reference => <*ASSERT FALSE*> > >> END > >> END > >> END Search; > >> > >> I think we can't expect gcc -Wall -Werror to pass. > >> I really wanted it to, and I tried, and I fixed stuff. > >> But I don't think it is viable. > >> Ok? > > > >Could it be that the TYPECASE doesn't have an ELSE clause, possibly > >translated to a switch withouy a default: label? This would give the > >C code an apparent path to the end of the function. M3 may know that > >the TYPECASE exhausts all the possibilities, but C will not. > > > >-- hendrik -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Mon Dec 17 08:49:35 2012 From: mika at async.caltech.edu (mika at async.caltech.edu) Date: Sun, 16 Dec 2012 23:49:35 -0800 Subject: [M3devel] thouhts on -Wall with C backend output In-Reply-To: References: , <20121216184306.GA29473@topoi.pooq.com>, <20121216185529.AD9681A2094@async.async.caltech.edu> Message-ID: <20121217074935.5DD971A2094@async.async.caltech.edu> Yeah it sounds like the frontend knows something that it's not telling the backend about... if I am reading your emails right. Jay K writes: >--_ad389312-f922-410e-bb8f-e7106388428f_ >Content-Type: text/plain; charset="Windows-1252" >Content-Transfer-Encoding: quoted-printable > > >drat=2C these are worse: > >"../src/Macro.m3"=2C line 949: warning: unreachable ELSE in TYPECASE > > >=3D=3D package /Users/jay/dev2/cm3/m3-ui/formsvbt =3D=3D > > +++ /cm3/bin/cm3 -build -DROOT=3D/Users/jay/dev2/cm3 +++ >--- building in AMD64_DARWIN --- > >ignoring ../src/m3overrides > >new source -> compiling Macro.m3 >cc1plus: warnings being treated as errors >Macro.mc.c: In function =91char* Macro__EvalLength(char*=2C char*)=92: >Macro.mc.c:5271: warning: control reaches end of non-void function >Macro.mc.c: In function =91char* Macro__EvalPlus(char*=2C char*)=92: >Macro.mc.c:9004: warning: control reaches end of non-void function >Macro.mc.c: In function =91char* Macro__EvalMinus(char*=2C char*)=92: >Macro.mc.c:9468: warning: control reaches end of non-void function > > >If I put in the somewhat obvious: > > > ELSE <* ASSERT FALSE *> > > >then: > >new source -> compiling Macro.m3 >"../src/Macro.m3"=2C line 949: warning: unreachable ELSE in TYPECASE >1 warning encountered >cc1plus: warnings being treated as errors >Macro.mc.c: In function =91char* Macro__EvalLength(char*=2C char*)=92: >Macro.mc.c:5271: warning: control reaches end of non-void function >Macro.mc.c: In function =91char* Macro__EvalPlus(char*=2C char*)=92: >Macro.mc.c:9004: warning: control reaches end of non-void function > > > >For stablegen=2C I am inclined to put in that ELSE <* ASSERT FALSE *>. > > >I might might might be able to put in C assert(false) in these places. > > - Jay > > >> To: hendrik at topoi.pooq.com >> Date: Sun=2C 16 Dec 2012 10:55:29 -0800 >> From: mika at async.caltech.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] thouhts on -Wall with C backend output >>=20 >> Can you have an option to add an assertion in the output for these cases? >>=20 >> Here either >>=20 >> 1. gcc has found a bug in the C code generator and/or front end=2C in tha= >t >> there's no default (abortion) case >>=20 >> or >>=20 >> 2. the front end has deduced there is no need for abortion because it can >> see that the missing ELSE is never going to be exercised=2C based on t= >he >> already existing type information >>=20 >> What I'm proposing is two modes for the compiler: >>=20 >> -- ignore the errors >>=20 >> or >>=20 >> -- add proper assertions to the C code=2C e.g.=2C=20 >>=20 >> assert(false=2C "front-end deduced this cant happen by inspecting typ= >e information") >>=20 >> which=2C when enabled=2C should make gcc shut up=2C and instead turn i= >nto >> runtime checks on the compiler >>=20 >> Mika >>=20 >> Hendrik Boom writes: >> >On Sun=2C Dec 16=2C 2012 at 09:58:10AM +0000=2C Jay K wrote: >> >>=20 >> >> I've tried to generate "very good C". >> >> I've fixed some of what gcc -Wall complains about. >> >> For default gcc on my old MacBook -- old enough that it can still emul= >ate PowerPC=2C gcc is 4.0.1. >> >> (at least one of what I deal with=2C I think anything newer won't comp= >lain..) >> >>=20 >> >>=20 >> >>=20 >> >> do-cm3-all with -Wall -Werror gets very far=2C to: >> >>=20 >> >> =3D=3D package /Users/jay/dev2/cm3/m3-db/stablegen =3D=3D >> >>=20 >> >> +++ /cm3/bin/cm3 -build -DROOT=3D/Users/jay/dev2/cm3 +++ >> >> --- building in AMD64_DARWIN --- >> >>=20 >> >> ignoring ../src/m3overrides >> >>=20 >> >> w source -> compiling GenCode.m3 >> >> cc1: warnings being treated as errors >> >> GenCode.mc.c: In function =91GenCode__BuildMethods__Search=92: >> >> GenCode.mc.c:3505: warning: control reaches end of non-void function >> >> m3_backend =3D> 1 >> >>=20 >> >> PROCEDURE Search ( type : Type.Reference=3B >> >> VAR count : INTEGER=3B >> >> VAR top : CARDINAL=3B >> >> umethods: AtomList.T ): >> >> ImportList.MethodList RAISES {StablegenError.E} =3D >> >> VAR methods: ImportList.MethodList=3B >> >> BEGIN >> >> IF (type =3D Type.root) OR (type =3D NIL) THEN (* base of >> >> recursion *) >> >> RETURN NEW(ImportList.MethodList=2C ABS(count)) >> >> ELSE >> >> TYPECASE type OF >> >> Type.Object (ob) =3D>=20 >> >> IF count <=3D 0 THEN >> >> count:=3D count - NUMBER(ob.methods^) >> >> END=3B >> >> methods :=3D Search(ob.super=2C count=2C top=2C umethods)=3B >> >> FOR i :=3D 0 TO LAST(ob.methods^) DO >> >> IF umethods =3D NIL >> >> OR AtomList.Member( >> >> umethods=2C ob.methods[i].name) THEN >> >> IF AtomList.Member(reserved=2C ob.methods[i].name) THEN >> >> RAISE StablegenError.E(Atom.ToText(ob.methods[i].name) >> >> &" is a reserved method name in stable objects. " >> >> &"Must not be an update method.") >> >> END=3B >> >> methods[top].name :=3D ob.methods[i].name=3B >> >> methods[top].sig :=3D ob.methods[i].sig=3B >> >> INC(top) >> >> END >> >> END=3B >> >> RETURN methods >> >> | Type.Opaque (op) =3D> >> >> RETURN Search(op.revealedSuperType=2C count=2C top=2C umetho= >ds) >> >> | Type.Reference =3D> <*ASSERT FALSE*> >> >> END >> >> END >> >> END Search=3B >> >>=20 >> >> I think we can't expect gcc -Wall -Werror to pass. >> >> I really wanted it to=2C and I tried=2C and I fixed stuff. >> >> But I don't think it is viable. >> >> Ok? >> > >> >Could it be that the TYPECASE doesn't have an ELSE clause=2C possibly >> >translated to a switch withouy a default: label? This would give the >> >C code an apparent path to the end of the function. M3 may know that >> >the TYPECASE exhausts all the possibilities=2C but C will not. >> > >> >-- hendrik > = > >--_ad389312-f922-410e-bb8f-e7106388428f_ >Content-Type: text/html; charset="Windows-1252" >Content-Transfer-Encoding: quoted-printable > > > > >
>drat=2C these are worse:

"../src/Macro.m3"=2C line 949: warning: unr= >eachable ELSE in TYPECASE


=3D=3D package /Users/jay/dev2/cm3/m3-= >ui/formsvbt =3D=3D

 =3B+++ /cm3/bin/cm3 =3B =3B =3B = >-build -DROOT=3D/Users/jay/dev2/cm3 +++
--- building in AMD64_DARWIN ---= >

ignoring ../src/m3overrides

new source ->=3B compiling Mac= >ro.m3
cc1plus: warnings being treated as errors
Macro.mc.c: In functi= >on =91char* Macro__EvalLength(char*=2C char*)=92:
Macro.mc.c:5271: warni= >ng: control reaches end of non-void function
Macro.mc.c: In function =91= >char* Macro__EvalPlus(char*=2C char*)=92:
Macro.mc.c:9004: warning: cont= >rol reaches end of non-void function
Macro.mc.c: In function =91char* Ma= >cro__EvalMinus(char*=2C char*)=92:
Macro.mc.c:9468: warning: control rea= >ches end of non-void function


If I put in the somewhat obvious:<= >br>

 =3B =3B =3B ELSE <=3B* ASSERT FALSE *>=3B
r>
then:

new source ->=3B compiling Macro.m3
"../src/Macro.m= >3"=2C line 949: warning: unreachable ELSE in TYPECASE
1 warning encounte= >red
cc1plus: warnings being treated as errors
Macro.mc.c: In function= > =91char* Macro__EvalLength(char*=2C char*)=92:
Macro.mc.c:5271: warning= >: control reaches end of non-void function
Macro.mc.c: In function =91ch= >ar* Macro__EvalPlus(char*=2C char*)=92:
Macro.mc.c:9004: warning: contro= >l reaches end of non-void function



For stablegen=2C I am inc= >lined to put in that ELSE <=3B* ASSERT FALSE *>=3B.


I might = >might might be able to put in C assert(false) in these places.

 = >=3B- Jay


>=3B To: h= >endrik at topoi.pooq.com
>=3B Date: Sun=2C 16 Dec 2012 10:55:29 -0800
= >>=3B From: mika at async.caltech.edu
>=3B CC: m3devel at elegosoft.com
= >>=3B Subject: Re: [M3devel] thouhts on -Wall with C backend output
>= >=3B
>=3B Can you have an option to add an assertion in the output for= > these cases?
>=3B
>=3B Here either
>=3B
>=3B 1. gcc = >has found a bug in the C code generator and/or front end=2C in that
>= >=3B there's no default (abortion) case
>=3B
>=3B or
>=3B= >
>=3B 2. the front end has deduced there is no need for abortion beca= >use it can
>=3B see that the missing ELSE is never going to be exer= >cised=2C based on the
>=3B already existing type information
>= >=3B
>=3B What I'm proposing is two modes for the compiler:
>=3B = >
>=3B -- ignore the errors
>=3B
>=3B or
>=3B
>= >=3B -- add proper assertions to the C code=2C e.g.=2C
>=3B
>=3B= > assert(false=2C "front-end deduced this cant happen by inspecting type= > information")
>=3B
>=3B which=2C when enabled=2C should make= > gcc shut up=2C and instead turn into
>=3B runtime checks on the co= >mpiler
>=3B
>=3B Mika
>=3B
>=3B Hendrik Boom wr= >ites:
>=3B >=3BOn Sun=2C Dec 16=2C 2012 at 09:58:10AM +0000=2C Jay K= > wrote:
>=3B >=3B>=3B
>=3B >=3B>=3B I've tried to genera= >te "very good C".
>=3B >=3B>=3B I've fixed some of what gcc -Wall = >complains about.
>=3B >=3B>=3B For default gcc on my old MacBook -= >- old enough that it can still emulate PowerPC=2C gcc is 4.0.1.
>=3B &= >gt=3B>=3B (at least one of what I deal with=2C I think anything newer won= >'t complain..)
>=3B >=3B>=3B
>=3B >=3B>=3B
>=3B &g= >t=3B>=3B
>=3B >=3B>=3B do-cm3-all with -Wall -Werror gets very = >far=2C to:
>=3B >=3B>=3B
>=3B >=3B>=3B =3D=3D package /U= >sers/jay/dev2/cm3/m3-db/stablegen =3D=3D
>=3B >=3B>=3B
>=3B = >>=3B>=3B +++ /cm3/bin/cm3 -build -DROOT=3D/Users/jay/dev2/cm3 +++r>>=3B >=3B>=3B --- building in AMD64_DARWIN ---
>=3B >=3B>= >=3B
>=3B >=3B>=3B ignoring ../src/m3overrides
>=3B >=3B>= >=3B
>=3B >=3B>=3B w source ->=3B compiling GenCode.m3
>=3B= > >=3B>=3B cc1: warnings being treated as errors
>=3B >=3B>=3B = >GenCode.mc.c: In function =91GenCode__BuildMethods__Search=92:
>=3B &g= >t=3B>=3B GenCode.mc.c:3505: warning: control reaches end of non-void func= >tion
>=3B >=3B>=3B m3_backend =3D>=3B 1
>=3B >=3B>=3B= >
>=3B >=3B>=3B PROCEDURE Search ( type : Type.Reference= >=3B
>=3B >=3B>=3B VAR count : INTEGER=3B
= >>=3B >=3B>=3B VAR top : CARDINAL=3B
>=3B= > >=3B>=3B umethods: AtomList.T ):
>=3B &= >gt=3B>=3B ImportList.MethodList RAISES {StablegenError.E} =3D
>= >=3B >=3B>=3B VAR methods: ImportList.MethodList=3B
>=3B >=3B= >>=3B BEGIN
>=3B >=3B>=3B IF (type =3D Type.root) OR (t= >ype =3D NIL) THEN (* base of
>=3B >=3B>=3B = > recursion *)
>=3B >=3B>=3B RE= >TURN NEW(ImportList.MethodList=2C ABS(count))
>=3B >=3B>=3B = >ELSE
>=3B >=3B>=3B TYPECASE type OF
>=3B >=3B>=3B = > Type.Object (ob) =3D>=3B
>=3B >=3B>=3B IF coun= >t <=3B=3D 0 THEN
>=3B >=3B>=3B count:=3D count - NUM= >BER(ob.methods^)
>=3B >=3B>=3B END=3B
>=3B >=3B&g= >t=3B methods :=3D Search(ob.super=2C count=2C top=2C umethods)=3B= >
>=3B >=3B>=3B FOR i :=3D 0 TO LAST(ob.methods^) DO
&= >gt=3B >=3B>=3B IF umethods =3D NIL
>=3B >=3B>=3B = > OR AtomList.Member(
>=3B >=3B>=3B = > umethods=2C ob.methods[i].name) THEN
>=3B >=3B>=3B = > IF AtomList.Member(reserved=2C ob.methods[i].name) THEN
>=3B >=3B&g= >t=3B RAISE StablegenError.E(Atom.ToText(ob.methods[i].name)= >
>=3B >=3B>=3B &=3B" is a reserved method name = >in stable objects. "
>=3B >=3B>=3B &=3B"Must no= >t be an update method.")
>=3B >=3B>=3B END=3B
>= >=3B >=3B>=3B methods[top].name :=3D ob.methods[i].name=3B= >
>=3B >=3B>=3B methods[top].sig :=3D ob.methods[i].s= >ig=3B
>=3B >=3B>=3B INC(top)
>=3B >=3B>=3B = > END
>=3B >=3B>=3B END=3B
>=3B >=3B>= >=3B RETURN methods
>=3B >=3B>=3B | Type.Opaque (= >op) =3D>=3B
>=3B >=3B>=3B RETURN Search(op.revealedSup= >erType=2C count=2C top=2C umethods)
>=3B >=3B>=3B | Type.R= >eference =3D>=3B <=3B*ASSERT FALSE*>=3B
>=3B >=3B>=3B = > END
>=3B >=3B>=3B END
>=3B >=3B>=3B END Searc= >h=3B
>=3B >=3B>=3B
>=3B >=3B>=3B I think we can't expect= > gcc -Wall -Werror to pass.
>=3B >=3B>=3B I really wanted it to=2C= > and I tried=2C and I fixed stuff.
>=3B >=3B>=3B But I don't think= > it is viable.
>=3B >=3B>=3B Ok?
>=3B >=3B
>=3B >=3B= >Could it be that the TYPECASE doesn't have an ELSE clause=2C possibly
&= >gt=3B >=3Btranslated to a switch withouy a default: label? This would gi= >ve the
>=3B >=3BC code an apparent path to the end of the function. = > M3 may know that
>=3B >=3Bthe TYPECASE exhausts all the possibiliti= >es=2C but C will not.
>=3B >=3B
>=3B >=3B-- hendrik
= >
>= > >--_ad389312-f922-410e-bb8f-e7106388428f_-- From jay.krell at cornell.edu Tue Dec 18 20:12:53 2012 From: jay.krell at cornell.edu (Jay K) Date: Tue, 18 Dec 2012 19:12:53 +0000 Subject: [M3devel] suggested Target.Int change In-Reply-To: References: , Message-ID: Here is the suggested change. Ok? Index: m3middle/src/TInt.i3 =================================================================== RCS file: /usr/cvs/cm3/m3-sys/m3middle/src/TInt.i3,v retrieving revision 1.34 diff -u -r1.34 TInt.i3 --- m3middle/src/TInt.i3 15 Dec 2010 16:10:46 -0000 1.34 +++ m3middle/src/TInt.i3 18 Dec 2012 18:43:44 -0000 @@ -33,8 +33,8 @@ Max16 = Int{16_FF, 16_7f, 16_00,..}; Min32 = Int{16_00, 16_00, 16_00, 16_80, 16_FF,..}; Max32 = Int{16_FF, 16_FF, 16_FF, 16_7f, 16_00,..}; - Min64 = Int{16_00, 16_00, 16_00, 16_00, 16_00, 16_00, 16_00, 16_80}; - Max64 = Int{16_FF, 16_FF, 16_FF, 16_FF, 16_FF, 16_FF, 16_FF, 16_7f}; + Min64 = Int{16_00, 16_00, 16_00, 16_00, 16_00, 16_00, 16_00, 16_80, 16_FF}; + Max64 = Int{16_FF, 16_FF, 16_FF, 16_FF, 16_FF, 16_FF, 16_FF, 16_7f, 0}; PROCEDURE FromInt (x: INTEGER; VAR i: Int): BOOLEAN; (* converts a host integer 'x' to a target integer 'i' *) Index: m3middle/src/TWord.i3 =================================================================== RCS file: /usr/cvs/cm3/m3-sys/m3middle/src/TWord.i3,v retrieving revision 1.11 diff -u -r1.11 TWord.i3 --- m3middle/src/TWord.i3 27 Feb 2010 00:43:06 -0000 1.11 +++ m3middle/src/TWord.i3 18 Dec 2012 18:43:44 -0000 @@ -26,7 +26,7 @@ Max8 = Int{16_FF, 0, ..}; Max16 = Int{16_FF, 16_FF, 0, ..}; Max32 = Int{16_FF, 16_FF, 16_FF, 16_FF, 0, ..}; - Max64 = Int{16_FF, 16_FF, 16_FF, 16_FF, 16_FF, 16_FF, 16_FF, 16_FF}; + Max64 = Int{16_FF, 16_FF, 16_FF, 16_FF, 16_FF, 16_FF, 16_FF, 16_FF, 0}; PROCEDURE New (READONLY chars: ARRAY OF CHAR; base: [2..16]; VAR i: Int): BOOLEAN; Index: m3middle/src/Target.i3 =================================================================== RCS file: /usr/cvs/cm3/m3-sys/m3middle/src/Target.i3,v retrieving revision 1.70 diff -u -r1.70 Target.i3 --- m3middle/src/Target.i3 4 Sep 2012 15:11:09 -0000 1.70 +++ m3middle/src/Target.i3 18 Dec 2012 18:43:44 -0000 @@ -224,7 +226,7 @@ element of the array. *) TYPE - Int = (* OPAQUE *) ARRAY [0..7] OF IByte; + Int = (* OPAQUE *) ARRAY [0..8] OF IByte; IByte = BITS 8 FOR [0..16_ff]; TYPE As a follow up, TWord could change so that many but not all of its procedure are just constants assigned from TInt. i.e. INTERFACE TWord; CONST LT = TInt.LT; - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Subject: suggested Target.Int change Date: Thu, 13 Dec 2012 08:32:27 +0000 [added subject] I strongly suggest that Target.Int be extended from 8 bytes to 9. The reason is thus: I was trying to mix TWord and TInt in M3C.m3. It become tedious and error prone. If Target.Int were extended to 9 bytes internally, then it would have a range exceeding a signed 64bit integer and a full range unsigned 64bit integer, and the need for TWord would, I believe, go away. The result would be *slightly* *slightly* *slightly* less efficient, but more convenient. I have already applied this change locally and built with it. It was very simple. I did have to visit the initializations of this mostly-opaque type, i.e. in Target.m3 and TInt.i3. Furthermore, I weakly suggest that Target.Int internally be changed to separately store the sign and the magnitude. This would be a hidden implementation detail and I believe it would simplify the implementation. It would *slightly* deoptimize the representation size, but the code, I think, would be smaller and simpler. This would not affect the public interface. I came to this suggestion when someone recently asked me how to implement this sort of thing. I realize it is slightly easier to store the sign and magnitude separately. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Dec 20 05:31:32 2012 From: jay.krell at cornell.edu (Jay K) Date: Thu, 20 Dec 2012 04:31:32 +0000 Subject: [M3devel] BITSIZE on constants? Message-ID: Why isn't BITSIZE valid on constants? Only on variables? Or types? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Dec 20 05:44:43 2012 From: hosking at cs.purdue.edu (Antony Hosking) Date: Thu, 20 Dec 2012 15:44:43 +1100 Subject: [M3devel] BITSIZE on constants? In-Reply-To: References: Message-ID: <12EE7CD0-CD58-478F-8B22-571EAD172758@cs.purdue.edu> Constants don?t occupy any storage. So they have no size. On Dec 20, 2012, at 3:31 PM, Jay K wrote: > Why isn't BITSIZE valid on constants? Only on variables? Or types? > > - Jay > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Dec 20 06:08:25 2012 From: jay.krell at cornell.edu (Jay) Date: Wed, 19 Dec 2012 21:08:25 -0800 Subject: [M3devel] BITSIZE on constants? In-Reply-To: <12EE7CD0-CD58-478F-8B22-571EAD172758@cs.purdue.edu> References: <12EE7CD0-CD58-478F-8B22-571EAD172758@cs.purdue.edu> Message-ID: <6090D9C2-ED9E-42FF-9C8B-0A594C934DFC@gmail.com> Eh? isn't bitsize(type) valid? It is in C and seems confroversy-free. - Jay (briefly/pocket-sized-computer-aka-phone) On Dec 19, 2012, at 8:44 PM, Antony Hosking wrote: > Constants don?t occupy any storage. So they have no size. > > > On Dec 20, 2012, at 3:31 PM, Jay K wrote: > >> Why isn't BITSIZE valid on constants? Only on variables? Or types? >> >> - Jay >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Thu Dec 20 18:16:32 2012 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 20 Dec 2012 11:16:32 -0600 Subject: [M3devel] BITSIZE on constants? In-Reply-To: <6090D9C2-ED9E-42FF-9C8B-0A594C934DFC@gmail.com> References: <12EE7CD0-CD58-478F-8B22-571EAD172758@cs.purdue.edu> <6090D9C2-ED9E-42FF-9C8B-0A594C934DFC@gmail.com> Message-ID: <50D347F0.8010508@lcwb.coop> On 12/19/2012 11:08 PM, Jay wrote: > Eh? isn't bitsize(type) valid? It is in C and seems confroversy-free. BITSIZE(type) (and BYTESIZE and ADRSIZE) is indeed valid on a _type_ in Modula-3. At the last paragraph of 2.6.13, it is defined as the size of a _variable_ of that type. The whole idea is that a compiler should not be obligated to store a constant in memory. Presumably, you know statically what the type of a CONST is, so can't you just use BITSIZE(TypeOfConst)? If you later changed the constant to a different type, it wouldn't self-adapt, but likely other places wouldn't either, or maybe would, but not correctly for your program. > > - Jay (briefly/pocket-sized-computer-aka-phone) > > On Dec 19, 2012, at 8:44 PM, Antony Hosking > wrote: > >> Constants don?t occupy any storage. So they have no size. >> >> >> On Dec 20, 2012, at 3:31 PM, Jay K <jay.krell at cornell.edu > wrote: >> >>> Why isn't BITSIZE valid on constants? Only on variables? Or types? >>> >>> - Jay >>> >>> >> From hendrik at topoi.pooq.com Thu Dec 20 19:08:08 2012 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Thu, 20 Dec 2012 13:08:08 -0500 Subject: [M3devel] BITSIZE on constants? In-Reply-To: <50D347F0.8010508@lcwb.coop> References: <12EE7CD0-CD58-478F-8B22-571EAD172758@cs.purdue.edu> <6090D9C2-ED9E-42FF-9C8B-0A594C934DFC@gmail.com> <50D347F0.8010508@lcwb.coop> Message-ID: <20121220180808.GC26848@topoi.pooq.com> On Thu, Dec 20, 2012 at 11:16:32AM -0600, Rodney M. Bates wrote: > > > On 12/19/2012 11:08 PM, Jay wrote: > >Eh? isn't bitsize(type) valid? It is in C and seems confroversy-free. > > BITSIZE(type) (and BYTESIZE and ADRSIZE) is indeed valid on a _type_ in > Modula-3. At the last paragraph of 2.6.13, it is defined as the size of a > _variable_ of that type. The whole idea is that a compiler should not be > obligated to store a constant in memory. > > Presumably, you know statically what the type of a CONST is, so can't you > just use BITSIZE(TypeOfConst)? If you later changed the constant > to a different type, it wouldn't self-adapt, but likely other places wouldn't > either, or maybe would, but not correctly for your program. Consider BITSIZE(-3). Doesn't it make a difference whether this -3 is to be considered as of type -3..0 or INTEGER, or even -3..-3? THis isn't inherent in the constant, and might on some implementations give BITSIZEs of 2, 64, or even 0, respectively, if meaningful. And if you were to change the language syntax so you'd always have to write something like (-3..0)(-3) to be explicit you'd end up writing everything you's write with BITSIZE(TypeOfConst) and more. What you might gain is a static check that the constant isn't out of bounds. -- hendrik From jay.krell at cornell.edu Thu Dec 20 21:50:36 2012 From: jay.krell at cornell.edu (Jay K) Date: Thu, 20 Dec 2012 20:50:36 +0000 Subject: [M3devel] BITSIZE on constants? In-Reply-To: <20121220180808.GC26848@topoi.pooq.com> References: , <12EE7CD0-CD58-478F-8B22-571EAD172758@cs.purdue.edu>, <6090D9C2-ED9E-42FF-9C8B-0A594C934DFC@gmail.com>, <50D347F0.8010508@lcwb.coop>, <20121220180808.GC26848@topoi.pooq.com> Message-ID: I think go has untyped constants. But I think Modula-3 constants (expressions) always have a type independent of their use. - Jay > Date: Thu, 20 Dec 2012 13:08:08 -0500 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] BITSIZE on constants? > > On Thu, Dec 20, 2012 at 11:16:32AM -0600, Rodney M. Bates wrote: > > > > > > On 12/19/2012 11:08 PM, Jay wrote: > > >Eh? isn't bitsize(type) valid? It is in C and seems confroversy-free. > > > > BITSIZE(type) (and BYTESIZE and ADRSIZE) is indeed valid on a _type_ in > > Modula-3. At the last paragraph of 2.6.13, it is defined as the size of a > > _variable_ of that type. The whole idea is that a compiler should not be > > obligated to store a constant in memory. > > > > Presumably, you know statically what the type of a CONST is, so can't you > > just use BITSIZE(TypeOfConst)? If you later changed the constant > > to a different type, it wouldn't self-adapt, but likely other places wouldn't > > either, or maybe would, but not correctly for your program. > > Consider BITSIZE(-3). Doesn't it make a difference whether this -3 is > to be considered as of type -3..0 or INTEGER, or even -3..-3? THis > isn't inherent in the constant, and might on some implementations give > BITSIZEs of 2, 64, or even 0, respectively, if meaningful. > > And if you were to change the language syntax so you'd always have to > write something like (-3..0)(-3) to be explicit you'd end up writing > everything you's write with BITSIZE(TypeOfConst) and more. What you > might gain is a static check that the constant isn't out of bounds. > > -- hendrik -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Thu Dec 20 23:34:07 2012 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 20 Dec 2012 16:34:07 -0600 Subject: [M3devel] BITSIZE on constants? In-Reply-To: References: , <12EE7CD0-CD58-478F-8B22-571EAD172758@cs.purdue.edu>, <6090D9C2-ED9E-42FF-9C8B-0A594C934DFC@gmail.com>, <50D347F0.8010508@lcwb.coop>, <20121220180808.GC26848@topoi.pooq.com> Message-ID: <50D3925F.4090204@lcwb.coop> On 12/20/2012 02:50 PM, Jay K wrote: > I think go has untyped constants. Ada has them too, but the rules for when they get implicitly converted to a runtime type are, well, IMO, bizarre. Even if they were more straightforward, there is inevitably a lot of complexity here that few working programmers will learn or think about, instead hoping everything will "just work". This can only be according their individual idea of how it should work, which is nowhere close to being either obvious or universal. Thus do very subtle bugs occasionally occur, and cause grief all out of proportion to their frequency. > But I think Modula-3 constants (expressions) always have a type independent of their use. Yes. All in 2.4.2: You can give a constant a type explicitly: CONST C : [ - 3 .. 0 ] = - 2; in which case, the value must be a member of the type. Or you can omit it, in which case, the type of the constant is the type of the _expression_. CONST D = - 2; There are many values that belong to more than one type (e.g., - 2 belongs to any subrange of INTEGER that contains it). But every expression has exactly one type. In this case, the type of every integer literal is INTEGER. And unary "-" applied to an INTEGER also has type INTEGER, which is the type of D. BTW, this is why we need different spellings for INTEGER and LONGINT literals, e.g. 10 and 10L. It avoids a morass of implied type conversion rules, etc., that the language already avoided before LONGINT. In fact, the same idea is in the original language for the floating point literals, with "E". "D", or "X" in the literal spelling, to uniquely denote its type. > > - Jay > > > > Date: Thu, 20 Dec 2012 13:08:08 -0500 > > From: hendrik at topoi.pooq.com > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] BITSIZE on constants? > > > > On Thu, Dec 20, 2012 at 11:16:32AM -0600, Rodney M. Bates wrote: > > > > > > > > > On 12/19/2012 11:08 PM, Jay wrote: > > > >Eh? isn't bitsize(type) valid? It is in C and seems confroversy-free. > > > > > > BITSIZE(type) (and BYTESIZE and ADRSIZE) is indeed valid on a _type_ in > > > Modula-3. At the last paragraph of 2.6.13, it is defined as the size of a > > > _variable_ of that type. The whole idea is that a compiler should not be > > > obligated to store a constant in memory. > > > > > > Presumably, you know statically what the type of a CONST is, so can't you > > > just use BITSIZE(TypeOfConst)? If you later changed the constant > > > to a different type, it wouldn't self-adapt, but likely other places wouldn't > > > either, or maybe would, but not correctly for your program. > > > > Consider BITSIZE(-3). Doesn't it make a difference whether this -3 is > > to be considered as of type -3..0 or INTEGER, or even -3..-3? THis > > isn't inherent in the constant, and might on some implementations give > > BITSIZEs of 2, 64, or even 0, respectively, if meaningful. > > > > And if you were to change the language syntax so you'd always have to > > write something like (-3..0)(-3) to be explicit you'd end up writing > > everything you's write with BITSIZE(TypeOfConst) and more. What you > > might gain is a static check that the constant isn't out of bounds. > > > > -- hendrik From jay.krell at cornell.edu Fri Dec 21 02:16:43 2012 From: jay.krell at cornell.edu (Jay K) Date: Fri, 21 Dec 2012 01:16:43 +0000 Subject: [M3devel] BITSIZE on constants? In-Reply-To: <50D3925F.4090204@lcwb.coop> References: , , <12EE7CD0-CD58-478F-8B22-571EAD172758@cs.purdue.edu>, , <6090D9C2-ED9E-42FF-9C8B-0A594C934DFC@gmail.com>, , <50D347F0.8010508@lcwb.coop>, , <20121220180808.GC26848@topoi.pooq.com>, , <50D3925F.4090204@lcwb.coop> Message-ID: I am NOT asking for untyped constants. Constants are typed, and BITSIZE ought to work on them. That is what I am asking for: CONST a = 1; CONST b = BITSIZE(a); - Jay > Date: Thu, 20 Dec 2012 16:34:07 -0600 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: Re: [M3devel] BITSIZE on constants? > > > > On 12/20/2012 02:50 PM, Jay K wrote: > > I think go has untyped constants. > > Ada has them too, but the rules for when they get implicitly converted to a runtime > type are, well, IMO, bizarre. > > Even if they were more straightforward, there is inevitably a lot of complexity here > that few working programmers will learn or think about, instead hoping everything > will "just work". This can only be according their individual idea of how it > should work, which is nowhere close to being either obvious or universal. Thus > do very subtle bugs occasionally occur, and cause grief all out of proportion to > their frequency. > > > But I think Modula-3 constants (expressions) always have a type independent of their use. > > Yes. All in 2.4.2: > > You can give a constant a type explicitly: > > CONST C : [ - 3 .. 0 ] = - 2; > > in which case, the value must be a member of the type. > > Or you can omit it, in which case, the type of the constant is the type > of the _expression_. > > CONST D = - 2; > > There are many values that belong to more than one type (e.g., - 2 > belongs to any subrange of INTEGER that contains it). But every > expression has exactly one type. In this case, the type of every > integer literal is INTEGER. And unary "-" applied to an INTEGER > also has type INTEGER, which is the type of D. > > BTW, this is why we need different spellings for INTEGER and > LONGINT literals, e.g. 10 and 10L. It avoids a morass of implied > type conversion rules, etc., that the language already avoided > before LONGINT. In fact, the same idea is in the original > language for the floating point literals, with "E". "D", or > "X" in the literal spelling, to uniquely denote its type. > > > > > - Jay > > > > > > > Date: Thu, 20 Dec 2012 13:08:08 -0500 > > > From: hendrik at topoi.pooq.com > > > To: m3devel at elegosoft.com > > > Subject: Re: [M3devel] BITSIZE on constants? > > > > > > On Thu, Dec 20, 2012 at 11:16:32AM -0600, Rodney M. Bates wrote: > > > > > > > > > > > > On 12/19/2012 11:08 PM, Jay wrote: > > > > >Eh? isn't bitsize(type) valid? It is in C and seems confroversy-free. > > > > > > > > BITSIZE(type) (and BYTESIZE and ADRSIZE) is indeed valid on a _type_ in > > > > Modula-3. At the last paragraph of 2.6.13, it is defined as the size of a > > > > _variable_ of that type. The whole idea is that a compiler should not be > > > > obligated to store a constant in memory. > > > > > > > > Presumably, you know statically what the type of a CONST is, so can't you > > > > just use BITSIZE(TypeOfConst)? If you later changed the constant > > > > to a different type, it wouldn't self-adapt, but likely other places wouldn't > > > > either, or maybe would, but not correctly for your program. > > > > > > Consider BITSIZE(-3). Doesn't it make a difference whether this -3 is > > > to be considered as of type -3..0 or INTEGER, or even -3..-3? THis > > > isn't inherent in the constant, and might on some implementations give > > > BITSIZEs of 2, 64, or even 0, respectively, if meaningful. > > > > > > And if you were to change the language syntax so you'd always have to > > > write something like (-3..0)(-3) to be explicit you'd end up writing > > > everything you's write with BITSIZE(TypeOfConst) and more. What you > > > might gain is a static check that the constant isn't out of bounds. > > > > > > -- hendrik > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Dec 21 11:00:08 2012 From: jay.krell at cornell.edu (Jay K) Date: Fri, 21 Dec 2012 10:00:08 +0000 Subject: [M3devel] repeat evaluation in check_range/hi/low/index/nil? Message-ID: I was going to fix M3C to allocate temporaries to avoid repeat evaluation for check_hi/lo/range/index/nil. I went looking at cm3cg, to confirm that check_eq is different -- it pops its inputs, so no need for a temporary there. Ok. And then, it doesn't look like cm3cg avoids the repeat evaluation? Still I should do it? It never matters, because frontend allocates temporaries for all function call return values? (It seems to.) Therefore whatever is repeatedly evaluated, has no side effects? And because "assignment isn't expression" -- store pops its value from the stack. I think. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Thu Dec 27 16:10:29 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Thu, 27 Dec 2012 15:10:29 +0000 (GMT) Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20121224201107.F2C89CCA97@birch.elegosoft.com> Message-ID: <1356621029.55706.YahooMailClassic@web133103.mail.ir2.yahoo.com> Hi Jay: even if this does not work OK for you doesn't mean you can break code clarity, please reconsider writing values instead of constants it can lead to misunderstand the purpose of those values (even if there are limitations in current implementation). Anyway, the CONS values must be transparent bit converted from decimal arithmetic. Why don't you convert it from it and solve this in Modula-3 style. Take my advice, but if not explain me please why not so Thanks in advance --- El lun, 24/12/12, Jay Krell escribi?: De: Jay Krell Asunto: [M3commit] CVS Update: cm3 Para: m3commit at elegosoft.com Fecha: lunes, 24 de diciembre, 2012 16:11 CVSROOT:??? /usr/cvs Changes by:??? jkrell at birch.??? 12/12/24 21:11:07 Modified files: ??? cm3/m3-sys/m3middle/src/: Target.i3 Log message: ??? remove new internal_Real_max, internal_Longreal_max and ??? copy around the values 3.40282346638528860x+38, 1.79769313486231570x+308 ??? intead of expanding the public interface -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Dec 6 09:26:33 2012 From: jay.krell at cornell.edu (Jay K) Date: Thu, 6 Dec 2012 08:26:33 +0000 Subject: [M3devel] redundant range checks? Message-ID: m3-libs/m3core/src/fingerprint/Poly.i3 Int32 = [-16_7fffffff-1 .. 16_7fffffff]; T = ARRAY [0..1] OF Int32; m3-libs/m3core/src/fingerprint/Poly.m3 PROCEDURE Sum (READONLY p, q: T) : T = VAR r : T; BEGIN r[0] := Word.Xor (p[0], q[0]); line 48 r[1] := Word.Xor (p[1], q[1]); RETURN r; END Sum; -----LINE 48 ----- load v.5 0 Addr Addr load_indirect 0 Int.32 Int.64 load v.6 0 Addr Addr load_indirect 0 Int.32 Int.64 xor Word.64 ... check_range Int.64 -2147483648 2147483647 1 if((((INT64)(((UINT64)(((UINT64)(((INT64)(*((INT32*)(p_L_7)))))) ^((UINT64)(((INT64)(*((INT32*)(q_L_8)))))))))) <((INT64)(M3_INT64(-2147483648)))) || (((INT64)(M3_INT64(2147483647))) < ((INT64)(((UINT64)(((UINT64)(((INT64)(*((INT32*)(p_L_7))))))^((UINT64)(((INT64)(*((INT32*)(q_L_8))))))))))))M_Poly_L_4_CRASH(1537); Poly.mc.c:325: warning: comparison is always false due to limited range of data type or, like: typedef long long INT64; typedef unsigned long long UINT64; typedef int INT32; #define MAXINT32 2147483647 #define MININT32 (-2147483648) void ReportFault(void); #define AssignINT64ToINT32(a, b) \ if (((INT64)(b)) < MININT32 || ((INT64)(b)) > MAXINT32) ReportFault(); \ a = (INT32)(INT64)(b); \ INT32 Sum(INT32 p, INT32 q) { INT32 r; AssignINT64ToINT32(r, ((UINT64)(INT64)*(INT32*)&p) ^ ((UINT64)(INT64)*(INT32*)&q)); // or this AssignINT64ToINT32(r, ((UINT64)(INT64)p) ^ ((UINT64)(INT64)q)); // or heck even this AssignINT64ToINT32(r, p ^ q); return r; } the operands get widened from 32bits to 64bits, operation done, then range checked, and assigned back to 32bits. The range check is redundant. It is subtle. 32bit operands sign extended to 64bits will succeed the range check. The upper bits will all be set or clear. If you xor them, the upper bits will still be either all set or all clear, which succeeds the range check. The C compiler notices it and warns. I'd like to avoid warnings. I think the frontend could catch this, easily enough. Thoughts? I'm just about in position to fix this in the C backend. But it'd be cool if the frontend did some cheap analysis always. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Dec 13 09:25:48 2012 From: jay.krell at cornell.edu (Jay K) Date: Thu, 13 Dec 2012 08:25:48 +0000 Subject: [M3devel] (no subject) Message-ID: I strongly suggest that Target.Int be extended from 8 bytes to 9. The reason is thus: I was trying to mix TWord and TInt in M3C.m3. It become tedious and error prone. If Target.Int were extended to 9 bytes internally, then it would have a range exceeding a signed 64bit integer and a full range unsigned 64bit integer, and the need for TWord would, I believe, go away. The result would be *slightly* *slightly* *slightly* less efficient, but more convenient. I have already applied this change locally and built with it. It was very simple. I did have to visit the initializations of this mostly-opaque type, i.e. in Target.m3 and TInt.i3. Furthermore, I weakly suggest that Target.Int internally be changed to separately store the sign and the magnitude. This would be a hidden implementation detail and I believe it would simplify the implementation. It would *slightly* deoptimize the representation size, but the code, I think, would be smaller and simpler. This would not affect the public interface. I came to this suggestion when someone recently asked me how to implement this sort of thing. I realize it is slightly easier to store the sign and magnitude separately. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Dec 13 09:32:27 2012 From: jay.krell at cornell.edu (Jay K) Date: Thu, 13 Dec 2012 08:32:27 +0000 Subject: [M3devel] suggested Target.Int change In-Reply-To: References: Message-ID: [added subject] I strongly suggest that Target.Int be extended from 8 bytes to 9. The reason is thus: I was trying to mix TWord and TInt in M3C.m3. It become tedious and error prone. If Target.Int were extended to 9 bytes internally, then it would have a range exceeding a signed 64bit integer and a full range unsigned 64bit integer, and the need for TWord would, I believe, go away. The result would be *slightly* *slightly* *slightly* less efficient, but more convenient. I have already applied this change locally and built with it. It was very simple. I did have to visit the initializations of this mostly-opaque type, i.e. in Target.m3 and TInt.i3. Furthermore, I weakly suggest that Target.Int internally be changed to separately store the sign and the magnitude. This would be a hidden implementation detail and I believe it would simplify the implementation. It would *slightly* deoptimize the representation size, but the code, I think, would be smaller and simpler. This would not affect the public interface. I came to this suggestion when someone recently asked me how to implement this sort of thing. I realize it is slightly easier to store the sign and magnitude separately. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From cornstalk at columbus.rr.com Fri Dec 14 04:37:21 2012 From: cornstalk at columbus.rr.com (Mark Morss) Date: Thu, 13 Dec 2012 22:37:21 -0500 Subject: [M3devel] emacs config for modula 3 Message-ID: <1355456241.27560.4.camel@thebeast> Hello to all. I'm sorry to make this minor housekeeping issue my first post to the list, but is there another emacs person here who has the right code to insert in .emacs to make emacs-mode work from modula3.el and m3font.el? I don't seem to have it right. Best to all. From im_ikram at yahoo.com Fri Dec 14 17:50:50 2012 From: im_ikram at yahoo.com (I.M. Ikram) Date: Fri, 14 Dec 2012 08:50:50 -0800 (PST) Subject: [M3devel] emacs config for modula 3 Message-ID: <1355503850.94677.YahooMailNeo@web162603.mail.bf1.yahoo.com> Hi. I'm another first-time poster here... > right code to insert in .emacs to make emacs-mode work from modula3.el > and m3font.el? I don't seem to have it right. The following snippet is from my .emacs: (add-to-list 'load-path "/path/to/modula3mode/directory") (autoload 'modula-3-mode "modula3") (load "m3font") ;; <--- enables syntax highlighting (setq auto-mode-alist (append '(("\\.ig$" . modula-3-mode) ("\\.mg$" . modula-3-mode) ("\\.i3$" . modula-3-mode) ("\\.m3$" . modula-3-mode)) auto-mode-alist)) Copied from the docs at http://modula3.elegosoft.com/cm3/doc/help/cm3/gnuemacs.html However, the indicated 'load' line is missing in those instructions. From dragisha at m3w.org Sat Dec 15 09:13:11 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sat, 15 Dec 2012 09:13:11 +0100 Subject: [M3devel] emacs config for modula 3 In-Reply-To: <1355503850.94677.YahooMailNeo@web162603.mail.bf1.yahoo.com> References: <1355503850.94677.YahooMailNeo@web162603.mail.bf1.yahoo.com> Message-ID: In my .emacs: (load-file "~/.emacs.d/modula3.el") (setq auto-mode-alist (append '(("\\.[im][3g]$" . modula-3-mode)) auto-mode-alist)) (setq completion-ignored-extensions (append '(".mo" ".mx" ".mc" ".io" ".ix") completion-ignored-extensions)) And I just copied modula3.el from cm3 distribution. No m3font needed for syntax highlighting, at least in my Aquamacs. I don't see m3font anywhere, it's some old version, maybe? Anyway - it just works. dd -- Divided by a common language Dragi?a Duri? dragisha at m3w.org On Dec 14, 2012, at 5:50 PM, I.M. Ikram wrote: > Hi. I'm another first-time poster here... > >> right code to insert in .emacs to make emacs-mode work from modula3.el >> and m3font.el? I don't seem to have it right. > > The following snippet is from my .emacs: > > (add-to-list 'load-path "/path/to/modula3mode/directory") > (autoload 'modula-3-mode "modula3") > (load "m3font") ;; <--- enables syntax highlighting > (setq auto-mode-alist > (append '(("\\.ig$" . modula-3-mode) > ("\\.mg$" . modula-3-mode) > ("\\.i3$" . modula-3-mode) > ("\\.m3$" . modula-3-mode)) > auto-mode-alist)) > > Copied from the docs at > http://modula3.elegosoft.com/cm3/doc/help/cm3/gnuemacs.html > However, the indicated 'load' line is missing in those instructions. > From jay.krell at cornell.edu Sun Dec 16 10:58:10 2012 From: jay.krell at cornell.edu (Jay K) Date: Sun, 16 Dec 2012 09:58:10 +0000 Subject: [M3devel] thouhts on -Wall with C backend output Message-ID: I've tried to generate "very good C". I've fixed some of what gcc -Wall complains about. For default gcc on my old MacBook -- old enough that it can still emulate PowerPC, gcc is 4.0.1. (at least one of what I deal with, I think anything newer won't complain..) do-cm3-all with -Wall -Werror gets very far, to: == package /Users/jay/dev2/cm3/m3-db/stablegen == +++ /cm3/bin/cm3 -build -DROOT=/Users/jay/dev2/cm3 +++ --- building in AMD64_DARWIN --- ignoring ../src/m3overrides w source -> compiling GenCode.m3 cc1: warnings being treated as errors GenCode.mc.c: In function ?GenCode__BuildMethods__Search?: GenCode.mc.c:3505: warning: control reaches end of non-void function m3_backend => 1 PROCEDURE Search ( type : Type.Reference; VAR count : INTEGER; VAR top : CARDINAL; umethods: AtomList.T ): ImportList.MethodList RAISES {StablegenError.E} = VAR methods: ImportList.MethodList; BEGIN IF (type = Type.root) OR (type = NIL) THEN (* base of recursion *) RETURN NEW(ImportList.MethodList, ABS(count)) ELSE TYPECASE type OF Type.Object (ob) => IF count <= 0 THEN count:= count - NUMBER(ob.methods^) END; methods := Search(ob.super, count, top, umethods); FOR i := 0 TO LAST(ob.methods^) DO IF umethods = NIL OR AtomList.Member( umethods, ob.methods[i].name) THEN IF AtomList.Member(reserved, ob.methods[i].name) THEN RAISE StablegenError.E(Atom.ToText(ob.methods[i].name) &" is a reserved method name in stable objects. " &"Must not be an update method.") END; methods[top].name := ob.methods[i].name; methods[top].sig := ob.methods[i].sig; INC(top) END END; RETURN methods | Type.Opaque (op) => RETURN Search(op.revealedSuperType, count, top, umethods) | Type.Reference => <*ASSERT FALSE*> END END END Search; I think we can't expect gcc -Wall -Werror to pass. I really wanted it to, and I tried, and I fixed stuff. But I don't think it is viable. Ok? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sun Dec 16 15:01:07 2012 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 16 Dec 2012 15:01:07 +0100 Subject: [M3devel] thouhts on -Wall with C backend output In-Reply-To: References: Message-ID: <20121216150107.efba68a3.wagner@elegosoft.com> On Sun, 16 Dec 2012 09:58:10 +0000 Jay K wrote: > -Wall -Werror I don't think it should be mandatory for our generated C code to pass this test, as long as we (you or somebody else ;-) are convinced that it's semantically correct. Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From rodney_bates at lcwb.coop Sun Dec 16 17:24:06 2012 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sun, 16 Dec 2012 10:24:06 -0600 Subject: [M3devel] thouhts on -Wall with C backend output In-Reply-To: References: Message-ID: <50CDF5A6.60400@lcwb.coop> You know, here is my view on the whole subject. A compiler, used in the usual way, has two functions: help to find a lot of programming errors that are statically detectable, and translate to machine code. When you feed a compiler with mechanically produced source code, the former function is not really that important. Ideally, the translator (including its own front end, in this case, the M3 front end) should take care of all the static error checking and just produce code that will translate properly. So once the translator is stable, it makes sense for ordinary users to ignore warnings from the back end compiler. They may still be very useful for testing the translator. I know this is a bit idealistic, and it takes more work for the translator developer to do it this way. But it's best for the user. Trying to correlate a warning (or error) issued by the back end compiler back to the original problem (if there is one) in the original source code can be exasperating for a user. So I'd say put the effort into making sure anything a user should care about is detected by the M3 front end and/or M3C. Then tell your users not to worry about messages from gcc. Yeah, I know this ignores the question of a user's wondering of messages from gcc are actually evidence of bugs in M3front/M3C. On 12/16/2012 03:58 AM, Jay K wrote: > I've tried to generate "very good C". > I've fixed some of what gcc -Wall complains about. > For default gcc on my old MacBook -- old enough that it can still emulate PowerPC, gcc is 4.0.1. > (at least one of what I deal with, I think anything newer won't complain..) > > > > do-cm3-all with -Wall -Werror gets very far, to: > > == package /Users/jay/dev2/cm3/m3-db/stablegen == > > +++ /cm3/bin/cm3 -build -DROOT=/Users/jay/dev2/cm3 +++ > --- building in AMD64_DARWIN --- > > ignoring ../src/m3overrides > > w source -> compiling GenCode.m3 > cc1: warnings being treated as errors > GenCode.mc.c: In function ?GenCode__BuildMethods__Search?: > GenCode.mc.c:3505: warning: control reaches end of non-void function > m3_backend => 1 > > PROCEDURE Search ( type : Type.Reference; > VAR count : INTEGER; > VAR top : CARDINAL; > umethods: AtomList.T ): > ImportList.MethodList RAISES {StablegenError.E} = > VAR methods: ImportList.MethodList; > BEGIN > IF (type = Type.root) OR (type = NIL) THEN (* base of > recursion *) > RETURN NEW(ImportList.MethodList, ABS(count)) > ELSE > TYPECASE type OF > Type.Object (ob) => > IF count <= 0 THEN > count:= count - NUMBER(ob.methods^) > END; > methods := Search(ob.super, count, top, umethods); > FOR i := 0 TO LAST(ob.methods^) DO > IF umethods = NIL > OR AtomList.Member( > umethods, ob.methods[i].name) THEN > IF AtomList.Member(reserved, ob.methods[i].name) THEN > RAISE StablegenError.E(Atom.ToText(ob.methods[i].name) > &" is a reserved method name in stable objects. " > &"Must not be an update method.") > END; > methods[top].name := ob.methods[i].name; > methods[top].sig := ob.methods[i].sig; > INC(top) > END > END; > RETURN methods > | Type.Opaque (op) => > RETURN Search(op.revealedSuperType, count, top, umethods) > | Type.Reference => <*ASSERT FALSE*> > END > END > END Search; > > I think we can't expect gcc -Wall -Werror to pass. > I really wanted it to, and I tried, and I fixed stuff. > But I don't think it is viable. > Ok? > > > - Jay From hendrik at topoi.pooq.com Sun Dec 16 19:43:06 2012 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Sun, 16 Dec 2012 13:43:06 -0500 Subject: [M3devel] thouhts on -Wall with C backend output In-Reply-To: References: Message-ID: <20121216184306.GA29473@topoi.pooq.com> On Sun, Dec 16, 2012 at 09:58:10AM +0000, Jay K wrote: > > I've tried to generate "very good C". > I've fixed some of what gcc -Wall complains about. > For default gcc on my old MacBook -- old enough that it can still emulate PowerPC, gcc is 4.0.1. > (at least one of what I deal with, I think anything newer won't complain..) > > > > do-cm3-all with -Wall -Werror gets very far, to: > > == package /Users/jay/dev2/cm3/m3-db/stablegen == > > +++ /cm3/bin/cm3 -build -DROOT=/Users/jay/dev2/cm3 +++ > --- building in AMD64_DARWIN --- > > ignoring ../src/m3overrides > > w source -> compiling GenCode.m3 > cc1: warnings being treated as errors > GenCode.mc.c: In function ?GenCode__BuildMethods__Search?: > GenCode.mc.c:3505: warning: control reaches end of non-void function > m3_backend => 1 > > PROCEDURE Search ( type : Type.Reference; > VAR count : INTEGER; > VAR top : CARDINAL; > umethods: AtomList.T ): > ImportList.MethodList RAISES {StablegenError.E} = > VAR methods: ImportList.MethodList; > BEGIN > IF (type = Type.root) OR (type = NIL) THEN (* base of > recursion *) > RETURN NEW(ImportList.MethodList, ABS(count)) > ELSE > TYPECASE type OF > Type.Object (ob) => > IF count <= 0 THEN > count:= count - NUMBER(ob.methods^) > END; > methods := Search(ob.super, count, top, umethods); > FOR i := 0 TO LAST(ob.methods^) DO > IF umethods = NIL > OR AtomList.Member( > umethods, ob.methods[i].name) THEN > IF AtomList.Member(reserved, ob.methods[i].name) THEN > RAISE StablegenError.E(Atom.ToText(ob.methods[i].name) > &" is a reserved method name in stable objects. " > &"Must not be an update method.") > END; > methods[top].name := ob.methods[i].name; > methods[top].sig := ob.methods[i].sig; > INC(top) > END > END; > RETURN methods > | Type.Opaque (op) => > RETURN Search(op.revealedSuperType, count, top, umethods) > | Type.Reference => <*ASSERT FALSE*> > END > END > END Search; > > I think we can't expect gcc -Wall -Werror to pass. > I really wanted it to, and I tried, and I fixed stuff. > But I don't think it is viable. > Ok? Could it be that the TYPECASE doesn't have an ELSE clause, possibly translated to a switch withouy a default: label? This would give the C code an apparent path to the end of the function. M3 may know that the TYPECASE exhausts all the possibilities, but C will not. -- hendrik From mika at async.caltech.edu Sun Dec 16 19:55:29 2012 From: mika at async.caltech.edu (mika at async.caltech.edu) Date: Sun, 16 Dec 2012 10:55:29 -0800 Subject: [M3devel] thouhts on -Wall with C backend output In-Reply-To: <20121216184306.GA29473@topoi.pooq.com> References: <20121216184306.GA29473@topoi.pooq.com> Message-ID: <20121216185529.AD9681A2094@async.async.caltech.edu> Can you have an option to add an assertion in the output for these cases? Here either 1. gcc has found a bug in the C code generator and/or front end, in that there's no default (abortion) case or 2. the front end has deduced there is no need for abortion because it can see that the missing ELSE is never going to be exercised, based on the already existing type information What I'm proposing is two modes for the compiler: -- ignore the errors or -- add proper assertions to the C code, e.g., assert(false, "front-end deduced this cant happen by inspecting type information") which, when enabled, should make gcc shut up, and instead turn into runtime checks on the compiler Mika Hendrik Boom writes: >On Sun, Dec 16, 2012 at 09:58:10AM +0000, Jay K wrote: >> >> I've tried to generate "very good C". >> I've fixed some of what gcc -Wall complains about. >> For default gcc on my old MacBook -- old enough that it can still emulate PowerPC, gcc is 4.0.1. >> (at least one of what I deal with, I think anything newer won't complain..) >> >> >> >> do-cm3-all with -Wall -Werror gets very far, to: >> >> == package /Users/jay/dev2/cm3/m3-db/stablegen == >> >> +++ /cm3/bin/cm3 -build -DROOT=/Users/jay/dev2/cm3 +++ >> --- building in AMD64_DARWIN --- >> >> ignoring ../src/m3overrides >> >> w source -> compiling GenCode.m3 >> cc1: warnings being treated as errors >> GenCode.mc.c: In function ???GenCode__BuildMethods__Search???: >> GenCode.mc.c:3505: warning: control reaches end of non-void function >> m3_backend => 1 >> >> PROCEDURE Search ( type : Type.Reference; >> VAR count : INTEGER; >> VAR top : CARDINAL; >> umethods: AtomList.T ): >> ImportList.MethodList RAISES {StablegenError.E} = >> VAR methods: ImportList.MethodList; >> BEGIN >> IF (type = Type.root) OR (type = NIL) THEN (* base of >> recursion *) >> RETURN NEW(ImportList.MethodList, ABS(count)) >> ELSE >> TYPECASE type OF >> Type.Object (ob) => >> IF count <= 0 THEN >> count:= count - NUMBER(ob.methods^) >> END; >> methods := Search(ob.super, count, top, umethods); >> FOR i := 0 TO LAST(ob.methods^) DO >> IF umethods = NIL >> OR AtomList.Member( >> umethods, ob.methods[i].name) THEN >> IF AtomList.Member(reserved, ob.methods[i].name) THEN >> RAISE StablegenError.E(Atom.ToText(ob.methods[i].name) >> &" is a reserved method name in stable objects. " >> &"Must not be an update method.") >> END; >> methods[top].name := ob.methods[i].name; >> methods[top].sig := ob.methods[i].sig; >> INC(top) >> END >> END; >> RETURN methods >> | Type.Opaque (op) => >> RETURN Search(op.revealedSuperType, count, top, umethods) >> | Type.Reference => <*ASSERT FALSE*> >> END >> END >> END Search; >> >> I think we can't expect gcc -Wall -Werror to pass. >> I really wanted it to, and I tried, and I fixed stuff. >> But I don't think it is viable. >> Ok? > >Could it be that the TYPECASE doesn't have an ELSE clause, possibly >translated to a switch withouy a default: label? This would give the >C code an apparent path to the end of the function. M3 may know that >the TYPECASE exhausts all the possibilities, but C will not. > >-- hendrik From jay.krell at cornell.edu Mon Dec 17 08:26:29 2012 From: jay.krell at cornell.edu (Jay K) Date: Mon, 17 Dec 2012 07:26:29 +0000 Subject: [M3devel] thouhts on -Wall with C backend output In-Reply-To: <20121216185529.AD9681A2094@async.async.caltech.edu> References: , <20121216184306.GA29473@topoi.pooq.com>, <20121216185529.AD9681A2094@async.async.caltech.edu> Message-ID: drat, these are worse: "../src/Macro.m3", line 949: warning: unreachable ELSE in TYPECASE == package /Users/jay/dev2/cm3/m3-ui/formsvbt == +++ /cm3/bin/cm3 -build -DROOT=/Users/jay/dev2/cm3 +++ --- building in AMD64_DARWIN --- ignoring ../src/m3overrides new source -> compiling Macro.m3 cc1plus: warnings being treated as errors Macro.mc.c: In function ?char* Macro__EvalLength(char*, char*)?: Macro.mc.c:5271: warning: control reaches end of non-void function Macro.mc.c: In function ?char* Macro__EvalPlus(char*, char*)?: Macro.mc.c:9004: warning: control reaches end of non-void function Macro.mc.c: In function ?char* Macro__EvalMinus(char*, char*)?: Macro.mc.c:9468: warning: control reaches end of non-void function If I put in the somewhat obvious: ELSE <* ASSERT FALSE *> then: new source -> compiling Macro.m3 "../src/Macro.m3", line 949: warning: unreachable ELSE in TYPECASE 1 warning encountered cc1plus: warnings being treated as errors Macro.mc.c: In function ?char* Macro__EvalLength(char*, char*)?: Macro.mc.c:5271: warning: control reaches end of non-void function Macro.mc.c: In function ?char* Macro__EvalPlus(char*, char*)?: Macro.mc.c:9004: warning: control reaches end of non-void function For stablegen, I am inclined to put in that ELSE <* ASSERT FALSE *>. I might might might be able to put in C assert(false) in these places. - Jay > To: hendrik at topoi.pooq.com > Date: Sun, 16 Dec 2012 10:55:29 -0800 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] thouhts on -Wall with C backend output > > Can you have an option to add an assertion in the output for these cases? > > Here either > > 1. gcc has found a bug in the C code generator and/or front end, in that > there's no default (abortion) case > > or > > 2. the front end has deduced there is no need for abortion because it can > see that the missing ELSE is never going to be exercised, based on the > already existing type information > > What I'm proposing is two modes for the compiler: > > -- ignore the errors > > or > > -- add proper assertions to the C code, e.g., > > assert(false, "front-end deduced this cant happen by inspecting type information") > > which, when enabled, should make gcc shut up, and instead turn into > runtime checks on the compiler > > Mika > > Hendrik Boom writes: > >On Sun, Dec 16, 2012 at 09:58:10AM +0000, Jay K wrote: > >> > >> I've tried to generate "very good C". > >> I've fixed some of what gcc -Wall complains about. > >> For default gcc on my old MacBook -- old enough that it can still emulate PowerPC, gcc is 4.0.1. > >> (at least one of what I deal with, I think anything newer won't complain..) > >> > >> > >> > >> do-cm3-all with -Wall -Werror gets very far, to: > >> > >> == package /Users/jay/dev2/cm3/m3-db/stablegen == > >> > >> +++ /cm3/bin/cm3 -build -DROOT=/Users/jay/dev2/cm3 +++ > >> --- building in AMD64_DARWIN --- > >> > >> ignoring ../src/m3overrides > >> > >> w source -> compiling GenCode.m3 > >> cc1: warnings being treated as errors > >> GenCode.mc.c: In function ?GenCode__BuildMethods__Search?: > >> GenCode.mc.c:3505: warning: control reaches end of non-void function > >> m3_backend => 1 > >> > >> PROCEDURE Search ( type : Type.Reference; > >> VAR count : INTEGER; > >> VAR top : CARDINAL; > >> umethods: AtomList.T ): > >> ImportList.MethodList RAISES {StablegenError.E} = > >> VAR methods: ImportList.MethodList; > >> BEGIN > >> IF (type = Type.root) OR (type = NIL) THEN (* base of > >> recursion *) > >> RETURN NEW(ImportList.MethodList, ABS(count)) > >> ELSE > >> TYPECASE type OF > >> Type.Object (ob) => > >> IF count <= 0 THEN > >> count:= count - NUMBER(ob.methods^) > >> END; > >> methods := Search(ob.super, count, top, umethods); > >> FOR i := 0 TO LAST(ob.methods^) DO > >> IF umethods = NIL > >> OR AtomList.Member( > >> umethods, ob.methods[i].name) THEN > >> IF AtomList.Member(reserved, ob.methods[i].name) THEN > >> RAISE StablegenError.E(Atom.ToText(ob.methods[i].name) > >> &" is a reserved method name in stable objects. " > >> &"Must not be an update method.") > >> END; > >> methods[top].name := ob.methods[i].name; > >> methods[top].sig := ob.methods[i].sig; > >> INC(top) > >> END > >> END; > >> RETURN methods > >> | Type.Opaque (op) => > >> RETURN Search(op.revealedSuperType, count, top, umethods) > >> | Type.Reference => <*ASSERT FALSE*> > >> END > >> END > >> END Search; > >> > >> I think we can't expect gcc -Wall -Werror to pass. > >> I really wanted it to, and I tried, and I fixed stuff. > >> But I don't think it is viable. > >> Ok? > > > >Could it be that the TYPECASE doesn't have an ELSE clause, possibly > >translated to a switch withouy a default: label? This would give the > >C code an apparent path to the end of the function. M3 may know that > >the TYPECASE exhausts all the possibilities, but C will not. > > > >-- hendrik -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Mon Dec 17 08:49:35 2012 From: mika at async.caltech.edu (mika at async.caltech.edu) Date: Sun, 16 Dec 2012 23:49:35 -0800 Subject: [M3devel] thouhts on -Wall with C backend output In-Reply-To: References: , <20121216184306.GA29473@topoi.pooq.com>, <20121216185529.AD9681A2094@async.async.caltech.edu> Message-ID: <20121217074935.5DD971A2094@async.async.caltech.edu> Yeah it sounds like the frontend knows something that it's not telling the backend about... if I am reading your emails right. Jay K writes: >--_ad389312-f922-410e-bb8f-e7106388428f_ >Content-Type: text/plain; charset="Windows-1252" >Content-Transfer-Encoding: quoted-printable > > >drat=2C these are worse: > >"../src/Macro.m3"=2C line 949: warning: unreachable ELSE in TYPECASE > > >=3D=3D package /Users/jay/dev2/cm3/m3-ui/formsvbt =3D=3D > > +++ /cm3/bin/cm3 -build -DROOT=3D/Users/jay/dev2/cm3 +++ >--- building in AMD64_DARWIN --- > >ignoring ../src/m3overrides > >new source -> compiling Macro.m3 >cc1plus: warnings being treated as errors >Macro.mc.c: In function =91char* Macro__EvalLength(char*=2C char*)=92: >Macro.mc.c:5271: warning: control reaches end of non-void function >Macro.mc.c: In function =91char* Macro__EvalPlus(char*=2C char*)=92: >Macro.mc.c:9004: warning: control reaches end of non-void function >Macro.mc.c: In function =91char* Macro__EvalMinus(char*=2C char*)=92: >Macro.mc.c:9468: warning: control reaches end of non-void function > > >If I put in the somewhat obvious: > > > ELSE <* ASSERT FALSE *> > > >then: > >new source -> compiling Macro.m3 >"../src/Macro.m3"=2C line 949: warning: unreachable ELSE in TYPECASE >1 warning encountered >cc1plus: warnings being treated as errors >Macro.mc.c: In function =91char* Macro__EvalLength(char*=2C char*)=92: >Macro.mc.c:5271: warning: control reaches end of non-void function >Macro.mc.c: In function =91char* Macro__EvalPlus(char*=2C char*)=92: >Macro.mc.c:9004: warning: control reaches end of non-void function > > > >For stablegen=2C I am inclined to put in that ELSE <* ASSERT FALSE *>. > > >I might might might be able to put in C assert(false) in these places. > > - Jay > > >> To: hendrik at topoi.pooq.com >> Date: Sun=2C 16 Dec 2012 10:55:29 -0800 >> From: mika at async.caltech.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] thouhts on -Wall with C backend output >>=20 >> Can you have an option to add an assertion in the output for these cases? >>=20 >> Here either >>=20 >> 1. gcc has found a bug in the C code generator and/or front end=2C in tha= >t >> there's no default (abortion) case >>=20 >> or >>=20 >> 2. the front end has deduced there is no need for abortion because it can >> see that the missing ELSE is never going to be exercised=2C based on t= >he >> already existing type information >>=20 >> What I'm proposing is two modes for the compiler: >>=20 >> -- ignore the errors >>=20 >> or >>=20 >> -- add proper assertions to the C code=2C e.g.=2C=20 >>=20 >> assert(false=2C "front-end deduced this cant happen by inspecting typ= >e information") >>=20 >> which=2C when enabled=2C should make gcc shut up=2C and instead turn i= >nto >> runtime checks on the compiler >>=20 >> Mika >>=20 >> Hendrik Boom writes: >> >On Sun=2C Dec 16=2C 2012 at 09:58:10AM +0000=2C Jay K wrote: >> >>=20 >> >> I've tried to generate "very good C". >> >> I've fixed some of what gcc -Wall complains about. >> >> For default gcc on my old MacBook -- old enough that it can still emul= >ate PowerPC=2C gcc is 4.0.1. >> >> (at least one of what I deal with=2C I think anything newer won't comp= >lain..) >> >>=20 >> >>=20 >> >>=20 >> >> do-cm3-all with -Wall -Werror gets very far=2C to: >> >>=20 >> >> =3D=3D package /Users/jay/dev2/cm3/m3-db/stablegen =3D=3D >> >>=20 >> >> +++ /cm3/bin/cm3 -build -DROOT=3D/Users/jay/dev2/cm3 +++ >> >> --- building in AMD64_DARWIN --- >> >>=20 >> >> ignoring ../src/m3overrides >> >>=20 >> >> w source -> compiling GenCode.m3 >> >> cc1: warnings being treated as errors >> >> GenCode.mc.c: In function =91GenCode__BuildMethods__Search=92: >> >> GenCode.mc.c:3505: warning: control reaches end of non-void function >> >> m3_backend =3D> 1 >> >>=20 >> >> PROCEDURE Search ( type : Type.Reference=3B >> >> VAR count : INTEGER=3B >> >> VAR top : CARDINAL=3B >> >> umethods: AtomList.T ): >> >> ImportList.MethodList RAISES {StablegenError.E} =3D >> >> VAR methods: ImportList.MethodList=3B >> >> BEGIN >> >> IF (type =3D Type.root) OR (type =3D NIL) THEN (* base of >> >> recursion *) >> >> RETURN NEW(ImportList.MethodList=2C ABS(count)) >> >> ELSE >> >> TYPECASE type OF >> >> Type.Object (ob) =3D>=20 >> >> IF count <=3D 0 THEN >> >> count:=3D count - NUMBER(ob.methods^) >> >> END=3B >> >> methods :=3D Search(ob.super=2C count=2C top=2C umethods)=3B >> >> FOR i :=3D 0 TO LAST(ob.methods^) DO >> >> IF umethods =3D NIL >> >> OR AtomList.Member( >> >> umethods=2C ob.methods[i].name) THEN >> >> IF AtomList.Member(reserved=2C ob.methods[i].name) THEN >> >> RAISE StablegenError.E(Atom.ToText(ob.methods[i].name) >> >> &" is a reserved method name in stable objects. " >> >> &"Must not be an update method.") >> >> END=3B >> >> methods[top].name :=3D ob.methods[i].name=3B >> >> methods[top].sig :=3D ob.methods[i].sig=3B >> >> INC(top) >> >> END >> >> END=3B >> >> RETURN methods >> >> | Type.Opaque (op) =3D> >> >> RETURN Search(op.revealedSuperType=2C count=2C top=2C umetho= >ds) >> >> | Type.Reference =3D> <*ASSERT FALSE*> >> >> END >> >> END >> >> END Search=3B >> >>=20 >> >> I think we can't expect gcc -Wall -Werror to pass. >> >> I really wanted it to=2C and I tried=2C and I fixed stuff. >> >> But I don't think it is viable. >> >> Ok? >> > >> >Could it be that the TYPECASE doesn't have an ELSE clause=2C possibly >> >translated to a switch withouy a default: label? This would give the >> >C code an apparent path to the end of the function. M3 may know that >> >the TYPECASE exhausts all the possibilities=2C but C will not. >> > >> >-- hendrik > = > >--_ad389312-f922-410e-bb8f-e7106388428f_ >Content-Type: text/html; charset="Windows-1252" >Content-Transfer-Encoding: quoted-printable > > > > >
>drat=2C these are worse:

"../src/Macro.m3"=2C line 949: warning: unr= >eachable ELSE in TYPECASE


=3D=3D package /Users/jay/dev2/cm3/m3-= >ui/formsvbt =3D=3D

 =3B+++ /cm3/bin/cm3 =3B =3B =3B = >-build -DROOT=3D/Users/jay/dev2/cm3 +++
--- building in AMD64_DARWIN ---= >

ignoring ../src/m3overrides

new source ->=3B compiling Mac= >ro.m3
cc1plus: warnings being treated as errors
Macro.mc.c: In functi= >on =91char* Macro__EvalLength(char*=2C char*)=92:
Macro.mc.c:5271: warni= >ng: control reaches end of non-void function
Macro.mc.c: In function =91= >char* Macro__EvalPlus(char*=2C char*)=92:
Macro.mc.c:9004: warning: cont= >rol reaches end of non-void function
Macro.mc.c: In function =91char* Ma= >cro__EvalMinus(char*=2C char*)=92:
Macro.mc.c:9468: warning: control rea= >ches end of non-void function


If I put in the somewhat obvious:<= >br>

 =3B =3B =3B ELSE <=3B* ASSERT FALSE *>=3B
r>
then:

new source ->=3B compiling Macro.m3
"../src/Macro.m= >3"=2C line 949: warning: unreachable ELSE in TYPECASE
1 warning encounte= >red
cc1plus: warnings being treated as errors
Macro.mc.c: In function= > =91char* Macro__EvalLength(char*=2C char*)=92:
Macro.mc.c:5271: warning= >: control reaches end of non-void function
Macro.mc.c: In function =91ch= >ar* Macro__EvalPlus(char*=2C char*)=92:
Macro.mc.c:9004: warning: contro= >l reaches end of non-void function



For stablegen=2C I am inc= >lined to put in that ELSE <=3B* ASSERT FALSE *>=3B.


I might = >might might be able to put in C assert(false) in these places.

 = >=3B- Jay


>=3B To: h= >endrik at topoi.pooq.com
>=3B Date: Sun=2C 16 Dec 2012 10:55:29 -0800
= >>=3B From: mika at async.caltech.edu
>=3B CC: m3devel at elegosoft.com
= >>=3B Subject: Re: [M3devel] thouhts on -Wall with C backend output
>= >=3B
>=3B Can you have an option to add an assertion in the output for= > these cases?
>=3B
>=3B Here either
>=3B
>=3B 1. gcc = >has found a bug in the C code generator and/or front end=2C in that
>= >=3B there's no default (abortion) case
>=3B
>=3B or
>=3B= >
>=3B 2. the front end has deduced there is no need for abortion beca= >use it can
>=3B see that the missing ELSE is never going to be exer= >cised=2C based on the
>=3B already existing type information
>= >=3B
>=3B What I'm proposing is two modes for the compiler:
>=3B = >
>=3B -- ignore the errors
>=3B
>=3B or
>=3B
>= >=3B -- add proper assertions to the C code=2C e.g.=2C
>=3B
>=3B= > assert(false=2C "front-end deduced this cant happen by inspecting type= > information")
>=3B
>=3B which=2C when enabled=2C should make= > gcc shut up=2C and instead turn into
>=3B runtime checks on the co= >mpiler
>=3B
>=3B Mika
>=3B
>=3B Hendrik Boom wr= >ites:
>=3B >=3BOn Sun=2C Dec 16=2C 2012 at 09:58:10AM +0000=2C Jay K= > wrote:
>=3B >=3B>=3B
>=3B >=3B>=3B I've tried to genera= >te "very good C".
>=3B >=3B>=3B I've fixed some of what gcc -Wall = >complains about.
>=3B >=3B>=3B For default gcc on my old MacBook -= >- old enough that it can still emulate PowerPC=2C gcc is 4.0.1.
>=3B &= >gt=3B>=3B (at least one of what I deal with=2C I think anything newer won= >'t complain..)
>=3B >=3B>=3B
>=3B >=3B>=3B
>=3B &g= >t=3B>=3B
>=3B >=3B>=3B do-cm3-all with -Wall -Werror gets very = >far=2C to:
>=3B >=3B>=3B
>=3B >=3B>=3B =3D=3D package /U= >sers/jay/dev2/cm3/m3-db/stablegen =3D=3D
>=3B >=3B>=3B
>=3B = >>=3B>=3B +++ /cm3/bin/cm3 -build -DROOT=3D/Users/jay/dev2/cm3 +++r>>=3B >=3B>=3B --- building in AMD64_DARWIN ---
>=3B >=3B>= >=3B
>=3B >=3B>=3B ignoring ../src/m3overrides
>=3B >=3B>= >=3B
>=3B >=3B>=3B w source ->=3B compiling GenCode.m3
>=3B= > >=3B>=3B cc1: warnings being treated as errors
>=3B >=3B>=3B = >GenCode.mc.c: In function =91GenCode__BuildMethods__Search=92:
>=3B &g= >t=3B>=3B GenCode.mc.c:3505: warning: control reaches end of non-void func= >tion
>=3B >=3B>=3B m3_backend =3D>=3B 1
>=3B >=3B>=3B= >
>=3B >=3B>=3B PROCEDURE Search ( type : Type.Reference= >=3B
>=3B >=3B>=3B VAR count : INTEGER=3B
= >>=3B >=3B>=3B VAR top : CARDINAL=3B
>=3B= > >=3B>=3B umethods: AtomList.T ):
>=3B &= >gt=3B>=3B ImportList.MethodList RAISES {StablegenError.E} =3D
>= >=3B >=3B>=3B VAR methods: ImportList.MethodList=3B
>=3B >=3B= >>=3B BEGIN
>=3B >=3B>=3B IF (type =3D Type.root) OR (t= >ype =3D NIL) THEN (* base of
>=3B >=3B>=3B = > recursion *)
>=3B >=3B>=3B RE= >TURN NEW(ImportList.MethodList=2C ABS(count))
>=3B >=3B>=3B = >ELSE
>=3B >=3B>=3B TYPECASE type OF
>=3B >=3B>=3B = > Type.Object (ob) =3D>=3B
>=3B >=3B>=3B IF coun= >t <=3B=3D 0 THEN
>=3B >=3B>=3B count:=3D count - NUM= >BER(ob.methods^)
>=3B >=3B>=3B END=3B
>=3B >=3B&g= >t=3B methods :=3D Search(ob.super=2C count=2C top=2C umethods)=3B= >
>=3B >=3B>=3B FOR i :=3D 0 TO LAST(ob.methods^) DO
&= >gt=3B >=3B>=3B IF umethods =3D NIL
>=3B >=3B>=3B = > OR AtomList.Member(
>=3B >=3B>=3B = > umethods=2C ob.methods[i].name) THEN
>=3B >=3B>=3B = > IF AtomList.Member(reserved=2C ob.methods[i].name) THEN
>=3B >=3B&g= >t=3B RAISE StablegenError.E(Atom.ToText(ob.methods[i].name)= >
>=3B >=3B>=3B &=3B" is a reserved method name = >in stable objects. "
>=3B >=3B>=3B &=3B"Must no= >t be an update method.")
>=3B >=3B>=3B END=3B
>= >=3B >=3B>=3B methods[top].name :=3D ob.methods[i].name=3B= >
>=3B >=3B>=3B methods[top].sig :=3D ob.methods[i].s= >ig=3B
>=3B >=3B>=3B INC(top)
>=3B >=3B>=3B = > END
>=3B >=3B>=3B END=3B
>=3B >=3B>= >=3B RETURN methods
>=3B >=3B>=3B | Type.Opaque (= >op) =3D>=3B
>=3B >=3B>=3B RETURN Search(op.revealedSup= >erType=2C count=2C top=2C umethods)
>=3B >=3B>=3B | Type.R= >eference =3D>=3B <=3B*ASSERT FALSE*>=3B
>=3B >=3B>=3B = > END
>=3B >=3B>=3B END
>=3B >=3B>=3B END Searc= >h=3B
>=3B >=3B>=3B
>=3B >=3B>=3B I think we can't expect= > gcc -Wall -Werror to pass.
>=3B >=3B>=3B I really wanted it to=2C= > and I tried=2C and I fixed stuff.
>=3B >=3B>=3B But I don't think= > it is viable.
>=3B >=3B>=3B Ok?
>=3B >=3B
>=3B >=3B= >Could it be that the TYPECASE doesn't have an ELSE clause=2C possibly
&= >gt=3B >=3Btranslated to a switch withouy a default: label? This would gi= >ve the
>=3B >=3BC code an apparent path to the end of the function. = > M3 may know that
>=3B >=3Bthe TYPECASE exhausts all the possibiliti= >es=2C but C will not.
>=3B >=3B
>=3B >=3B-- hendrik
= >
>= > >--_ad389312-f922-410e-bb8f-e7106388428f_-- From jay.krell at cornell.edu Tue Dec 18 20:12:53 2012 From: jay.krell at cornell.edu (Jay K) Date: Tue, 18 Dec 2012 19:12:53 +0000 Subject: [M3devel] suggested Target.Int change In-Reply-To: References: , Message-ID: Here is the suggested change. Ok? Index: m3middle/src/TInt.i3 =================================================================== RCS file: /usr/cvs/cm3/m3-sys/m3middle/src/TInt.i3,v retrieving revision 1.34 diff -u -r1.34 TInt.i3 --- m3middle/src/TInt.i3 15 Dec 2010 16:10:46 -0000 1.34 +++ m3middle/src/TInt.i3 18 Dec 2012 18:43:44 -0000 @@ -33,8 +33,8 @@ Max16 = Int{16_FF, 16_7f, 16_00,..}; Min32 = Int{16_00, 16_00, 16_00, 16_80, 16_FF,..}; Max32 = Int{16_FF, 16_FF, 16_FF, 16_7f, 16_00,..}; - Min64 = Int{16_00, 16_00, 16_00, 16_00, 16_00, 16_00, 16_00, 16_80}; - Max64 = Int{16_FF, 16_FF, 16_FF, 16_FF, 16_FF, 16_FF, 16_FF, 16_7f}; + Min64 = Int{16_00, 16_00, 16_00, 16_00, 16_00, 16_00, 16_00, 16_80, 16_FF}; + Max64 = Int{16_FF, 16_FF, 16_FF, 16_FF, 16_FF, 16_FF, 16_FF, 16_7f, 0}; PROCEDURE FromInt (x: INTEGER; VAR i: Int): BOOLEAN; (* converts a host integer 'x' to a target integer 'i' *) Index: m3middle/src/TWord.i3 =================================================================== RCS file: /usr/cvs/cm3/m3-sys/m3middle/src/TWord.i3,v retrieving revision 1.11 diff -u -r1.11 TWord.i3 --- m3middle/src/TWord.i3 27 Feb 2010 00:43:06 -0000 1.11 +++ m3middle/src/TWord.i3 18 Dec 2012 18:43:44 -0000 @@ -26,7 +26,7 @@ Max8 = Int{16_FF, 0, ..}; Max16 = Int{16_FF, 16_FF, 0, ..}; Max32 = Int{16_FF, 16_FF, 16_FF, 16_FF, 0, ..}; - Max64 = Int{16_FF, 16_FF, 16_FF, 16_FF, 16_FF, 16_FF, 16_FF, 16_FF}; + Max64 = Int{16_FF, 16_FF, 16_FF, 16_FF, 16_FF, 16_FF, 16_FF, 16_FF, 0}; PROCEDURE New (READONLY chars: ARRAY OF CHAR; base: [2..16]; VAR i: Int): BOOLEAN; Index: m3middle/src/Target.i3 =================================================================== RCS file: /usr/cvs/cm3/m3-sys/m3middle/src/Target.i3,v retrieving revision 1.70 diff -u -r1.70 Target.i3 --- m3middle/src/Target.i3 4 Sep 2012 15:11:09 -0000 1.70 +++ m3middle/src/Target.i3 18 Dec 2012 18:43:44 -0000 @@ -224,7 +226,7 @@ element of the array. *) TYPE - Int = (* OPAQUE *) ARRAY [0..7] OF IByte; + Int = (* OPAQUE *) ARRAY [0..8] OF IByte; IByte = BITS 8 FOR [0..16_ff]; TYPE As a follow up, TWord could change so that many but not all of its procedure are just constants assigned from TInt. i.e. INTERFACE TWord; CONST LT = TInt.LT; - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Subject: suggested Target.Int change Date: Thu, 13 Dec 2012 08:32:27 +0000 [added subject] I strongly suggest that Target.Int be extended from 8 bytes to 9. The reason is thus: I was trying to mix TWord and TInt in M3C.m3. It become tedious and error prone. If Target.Int were extended to 9 bytes internally, then it would have a range exceeding a signed 64bit integer and a full range unsigned 64bit integer, and the need for TWord would, I believe, go away. The result would be *slightly* *slightly* *slightly* less efficient, but more convenient. I have already applied this change locally and built with it. It was very simple. I did have to visit the initializations of this mostly-opaque type, i.e. in Target.m3 and TInt.i3. Furthermore, I weakly suggest that Target.Int internally be changed to separately store the sign and the magnitude. This would be a hidden implementation detail and I believe it would simplify the implementation. It would *slightly* deoptimize the representation size, but the code, I think, would be smaller and simpler. This would not affect the public interface. I came to this suggestion when someone recently asked me how to implement this sort of thing. I realize it is slightly easier to store the sign and magnitude separately. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Dec 20 05:31:32 2012 From: jay.krell at cornell.edu (Jay K) Date: Thu, 20 Dec 2012 04:31:32 +0000 Subject: [M3devel] BITSIZE on constants? Message-ID: Why isn't BITSIZE valid on constants? Only on variables? Or types? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Dec 20 05:44:43 2012 From: hosking at cs.purdue.edu (Antony Hosking) Date: Thu, 20 Dec 2012 15:44:43 +1100 Subject: [M3devel] BITSIZE on constants? In-Reply-To: References: Message-ID: <12EE7CD0-CD58-478F-8B22-571EAD172758@cs.purdue.edu> Constants don?t occupy any storage. So they have no size. On Dec 20, 2012, at 3:31 PM, Jay K wrote: > Why isn't BITSIZE valid on constants? Only on variables? Or types? > > - Jay > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Dec 20 06:08:25 2012 From: jay.krell at cornell.edu (Jay) Date: Wed, 19 Dec 2012 21:08:25 -0800 Subject: [M3devel] BITSIZE on constants? In-Reply-To: <12EE7CD0-CD58-478F-8B22-571EAD172758@cs.purdue.edu> References: <12EE7CD0-CD58-478F-8B22-571EAD172758@cs.purdue.edu> Message-ID: <6090D9C2-ED9E-42FF-9C8B-0A594C934DFC@gmail.com> Eh? isn't bitsize(type) valid? It is in C and seems confroversy-free. - Jay (briefly/pocket-sized-computer-aka-phone) On Dec 19, 2012, at 8:44 PM, Antony Hosking wrote: > Constants don?t occupy any storage. So they have no size. > > > On Dec 20, 2012, at 3:31 PM, Jay K wrote: > >> Why isn't BITSIZE valid on constants? Only on variables? Or types? >> >> - Jay >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Thu Dec 20 18:16:32 2012 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 20 Dec 2012 11:16:32 -0600 Subject: [M3devel] BITSIZE on constants? In-Reply-To: <6090D9C2-ED9E-42FF-9C8B-0A594C934DFC@gmail.com> References: <12EE7CD0-CD58-478F-8B22-571EAD172758@cs.purdue.edu> <6090D9C2-ED9E-42FF-9C8B-0A594C934DFC@gmail.com> Message-ID: <50D347F0.8010508@lcwb.coop> On 12/19/2012 11:08 PM, Jay wrote: > Eh? isn't bitsize(type) valid? It is in C and seems confroversy-free. BITSIZE(type) (and BYTESIZE and ADRSIZE) is indeed valid on a _type_ in Modula-3. At the last paragraph of 2.6.13, it is defined as the size of a _variable_ of that type. The whole idea is that a compiler should not be obligated to store a constant in memory. Presumably, you know statically what the type of a CONST is, so can't you just use BITSIZE(TypeOfConst)? If you later changed the constant to a different type, it wouldn't self-adapt, but likely other places wouldn't either, or maybe would, but not correctly for your program. > > - Jay (briefly/pocket-sized-computer-aka-phone) > > On Dec 19, 2012, at 8:44 PM, Antony Hosking > wrote: > >> Constants don?t occupy any storage. So they have no size. >> >> >> On Dec 20, 2012, at 3:31 PM, Jay K <jay.krell at cornell.edu > wrote: >> >>> Why isn't BITSIZE valid on constants? Only on variables? Or types? >>> >>> - Jay >>> >>> >> From hendrik at topoi.pooq.com Thu Dec 20 19:08:08 2012 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Thu, 20 Dec 2012 13:08:08 -0500 Subject: [M3devel] BITSIZE on constants? In-Reply-To: <50D347F0.8010508@lcwb.coop> References: <12EE7CD0-CD58-478F-8B22-571EAD172758@cs.purdue.edu> <6090D9C2-ED9E-42FF-9C8B-0A594C934DFC@gmail.com> <50D347F0.8010508@lcwb.coop> Message-ID: <20121220180808.GC26848@topoi.pooq.com> On Thu, Dec 20, 2012 at 11:16:32AM -0600, Rodney M. Bates wrote: > > > On 12/19/2012 11:08 PM, Jay wrote: > >Eh? isn't bitsize(type) valid? It is in C and seems confroversy-free. > > BITSIZE(type) (and BYTESIZE and ADRSIZE) is indeed valid on a _type_ in > Modula-3. At the last paragraph of 2.6.13, it is defined as the size of a > _variable_ of that type. The whole idea is that a compiler should not be > obligated to store a constant in memory. > > Presumably, you know statically what the type of a CONST is, so can't you > just use BITSIZE(TypeOfConst)? If you later changed the constant > to a different type, it wouldn't self-adapt, but likely other places wouldn't > either, or maybe would, but not correctly for your program. Consider BITSIZE(-3). Doesn't it make a difference whether this -3 is to be considered as of type -3..0 or INTEGER, or even -3..-3? THis isn't inherent in the constant, and might on some implementations give BITSIZEs of 2, 64, or even 0, respectively, if meaningful. And if you were to change the language syntax so you'd always have to write something like (-3..0)(-3) to be explicit you'd end up writing everything you's write with BITSIZE(TypeOfConst) and more. What you might gain is a static check that the constant isn't out of bounds. -- hendrik From jay.krell at cornell.edu Thu Dec 20 21:50:36 2012 From: jay.krell at cornell.edu (Jay K) Date: Thu, 20 Dec 2012 20:50:36 +0000 Subject: [M3devel] BITSIZE on constants? In-Reply-To: <20121220180808.GC26848@topoi.pooq.com> References: , <12EE7CD0-CD58-478F-8B22-571EAD172758@cs.purdue.edu>, <6090D9C2-ED9E-42FF-9C8B-0A594C934DFC@gmail.com>, <50D347F0.8010508@lcwb.coop>, <20121220180808.GC26848@topoi.pooq.com> Message-ID: I think go has untyped constants. But I think Modula-3 constants (expressions) always have a type independent of their use. - Jay > Date: Thu, 20 Dec 2012 13:08:08 -0500 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] BITSIZE on constants? > > On Thu, Dec 20, 2012 at 11:16:32AM -0600, Rodney M. Bates wrote: > > > > > > On 12/19/2012 11:08 PM, Jay wrote: > > >Eh? isn't bitsize(type) valid? It is in C and seems confroversy-free. > > > > BITSIZE(type) (and BYTESIZE and ADRSIZE) is indeed valid on a _type_ in > > Modula-3. At the last paragraph of 2.6.13, it is defined as the size of a > > _variable_ of that type. The whole idea is that a compiler should not be > > obligated to store a constant in memory. > > > > Presumably, you know statically what the type of a CONST is, so can't you > > just use BITSIZE(TypeOfConst)? If you later changed the constant > > to a different type, it wouldn't self-adapt, but likely other places wouldn't > > either, or maybe would, but not correctly for your program. > > Consider BITSIZE(-3). Doesn't it make a difference whether this -3 is > to be considered as of type -3..0 or INTEGER, or even -3..-3? THis > isn't inherent in the constant, and might on some implementations give > BITSIZEs of 2, 64, or even 0, respectively, if meaningful. > > And if you were to change the language syntax so you'd always have to > write something like (-3..0)(-3) to be explicit you'd end up writing > everything you's write with BITSIZE(TypeOfConst) and more. What you > might gain is a static check that the constant isn't out of bounds. > > -- hendrik -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Thu Dec 20 23:34:07 2012 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 20 Dec 2012 16:34:07 -0600 Subject: [M3devel] BITSIZE on constants? In-Reply-To: References: , <12EE7CD0-CD58-478F-8B22-571EAD172758@cs.purdue.edu>, <6090D9C2-ED9E-42FF-9C8B-0A594C934DFC@gmail.com>, <50D347F0.8010508@lcwb.coop>, <20121220180808.GC26848@topoi.pooq.com> Message-ID: <50D3925F.4090204@lcwb.coop> On 12/20/2012 02:50 PM, Jay K wrote: > I think go has untyped constants. Ada has them too, but the rules for when they get implicitly converted to a runtime type are, well, IMO, bizarre. Even if they were more straightforward, there is inevitably a lot of complexity here that few working programmers will learn or think about, instead hoping everything will "just work". This can only be according their individual idea of how it should work, which is nowhere close to being either obvious or universal. Thus do very subtle bugs occasionally occur, and cause grief all out of proportion to their frequency. > But I think Modula-3 constants (expressions) always have a type independent of their use. Yes. All in 2.4.2: You can give a constant a type explicitly: CONST C : [ - 3 .. 0 ] = - 2; in which case, the value must be a member of the type. Or you can omit it, in which case, the type of the constant is the type of the _expression_. CONST D = - 2; There are many values that belong to more than one type (e.g., - 2 belongs to any subrange of INTEGER that contains it). But every expression has exactly one type. In this case, the type of every integer literal is INTEGER. And unary "-" applied to an INTEGER also has type INTEGER, which is the type of D. BTW, this is why we need different spellings for INTEGER and LONGINT literals, e.g. 10 and 10L. It avoids a morass of implied type conversion rules, etc., that the language already avoided before LONGINT. In fact, the same idea is in the original language for the floating point literals, with "E". "D", or "X" in the literal spelling, to uniquely denote its type. > > - Jay > > > > Date: Thu, 20 Dec 2012 13:08:08 -0500 > > From: hendrik at topoi.pooq.com > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] BITSIZE on constants? > > > > On Thu, Dec 20, 2012 at 11:16:32AM -0600, Rodney M. Bates wrote: > > > > > > > > > On 12/19/2012 11:08 PM, Jay wrote: > > > >Eh? isn't bitsize(type) valid? It is in C and seems confroversy-free. > > > > > > BITSIZE(type) (and BYTESIZE and ADRSIZE) is indeed valid on a _type_ in > > > Modula-3. At the last paragraph of 2.6.13, it is defined as the size of a > > > _variable_ of that type. The whole idea is that a compiler should not be > > > obligated to store a constant in memory. > > > > > > Presumably, you know statically what the type of a CONST is, so can't you > > > just use BITSIZE(TypeOfConst)? If you later changed the constant > > > to a different type, it wouldn't self-adapt, but likely other places wouldn't > > > either, or maybe would, but not correctly for your program. > > > > Consider BITSIZE(-3). Doesn't it make a difference whether this -3 is > > to be considered as of type -3..0 or INTEGER, or even -3..-3? THis > > isn't inherent in the constant, and might on some implementations give > > BITSIZEs of 2, 64, or even 0, respectively, if meaningful. > > > > And if you were to change the language syntax so you'd always have to > > write something like (-3..0)(-3) to be explicit you'd end up writing > > everything you's write with BITSIZE(TypeOfConst) and more. What you > > might gain is a static check that the constant isn't out of bounds. > > > > -- hendrik From jay.krell at cornell.edu Fri Dec 21 02:16:43 2012 From: jay.krell at cornell.edu (Jay K) Date: Fri, 21 Dec 2012 01:16:43 +0000 Subject: [M3devel] BITSIZE on constants? In-Reply-To: <50D3925F.4090204@lcwb.coop> References: , , <12EE7CD0-CD58-478F-8B22-571EAD172758@cs.purdue.edu>, , <6090D9C2-ED9E-42FF-9C8B-0A594C934DFC@gmail.com>, , <50D347F0.8010508@lcwb.coop>, , <20121220180808.GC26848@topoi.pooq.com>, , <50D3925F.4090204@lcwb.coop> Message-ID: I am NOT asking for untyped constants. Constants are typed, and BITSIZE ought to work on them. That is what I am asking for: CONST a = 1; CONST b = BITSIZE(a); - Jay > Date: Thu, 20 Dec 2012 16:34:07 -0600 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: Re: [M3devel] BITSIZE on constants? > > > > On 12/20/2012 02:50 PM, Jay K wrote: > > I think go has untyped constants. > > Ada has them too, but the rules for when they get implicitly converted to a runtime > type are, well, IMO, bizarre. > > Even if they were more straightforward, there is inevitably a lot of complexity here > that few working programmers will learn or think about, instead hoping everything > will "just work". This can only be according their individual idea of how it > should work, which is nowhere close to being either obvious or universal. Thus > do very subtle bugs occasionally occur, and cause grief all out of proportion to > their frequency. > > > But I think Modula-3 constants (expressions) always have a type independent of their use. > > Yes. All in 2.4.2: > > You can give a constant a type explicitly: > > CONST C : [ - 3 .. 0 ] = - 2; > > in which case, the value must be a member of the type. > > Or you can omit it, in which case, the type of the constant is the type > of the _expression_. > > CONST D = - 2; > > There are many values that belong to more than one type (e.g., - 2 > belongs to any subrange of INTEGER that contains it). But every > expression has exactly one type. In this case, the type of every > integer literal is INTEGER. And unary "-" applied to an INTEGER > also has type INTEGER, which is the type of D. > > BTW, this is why we need different spellings for INTEGER and > LONGINT literals, e.g. 10 and 10L. It avoids a morass of implied > type conversion rules, etc., that the language already avoided > before LONGINT. In fact, the same idea is in the original > language for the floating point literals, with "E". "D", or > "X" in the literal spelling, to uniquely denote its type. > > > > > - Jay > > > > > > > Date: Thu, 20 Dec 2012 13:08:08 -0500 > > > From: hendrik at topoi.pooq.com > > > To: m3devel at elegosoft.com > > > Subject: Re: [M3devel] BITSIZE on constants? > > > > > > On Thu, Dec 20, 2012 at 11:16:32AM -0600, Rodney M. Bates wrote: > > > > > > > > > > > > On 12/19/2012 11:08 PM, Jay wrote: > > > > >Eh? isn't bitsize(type) valid? It is in C and seems confroversy-free. > > > > > > > > BITSIZE(type) (and BYTESIZE and ADRSIZE) is indeed valid on a _type_ in > > > > Modula-3. At the last paragraph of 2.6.13, it is defined as the size of a > > > > _variable_ of that type. The whole idea is that a compiler should not be > > > > obligated to store a constant in memory. > > > > > > > > Presumably, you know statically what the type of a CONST is, so can't you > > > > just use BITSIZE(TypeOfConst)? If you later changed the constant > > > > to a different type, it wouldn't self-adapt, but likely other places wouldn't > > > > either, or maybe would, but not correctly for your program. > > > > > > Consider BITSIZE(-3). Doesn't it make a difference whether this -3 is > > > to be considered as of type -3..0 or INTEGER, or even -3..-3? THis > > > isn't inherent in the constant, and might on some implementations give > > > BITSIZEs of 2, 64, or even 0, respectively, if meaningful. > > > > > > And if you were to change the language syntax so you'd always have to > > > write something like (-3..0)(-3) to be explicit you'd end up writing > > > everything you's write with BITSIZE(TypeOfConst) and more. What you > > > might gain is a static check that the constant isn't out of bounds. > > > > > > -- hendrik > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Dec 21 11:00:08 2012 From: jay.krell at cornell.edu (Jay K) Date: Fri, 21 Dec 2012 10:00:08 +0000 Subject: [M3devel] repeat evaluation in check_range/hi/low/index/nil? Message-ID: I was going to fix M3C to allocate temporaries to avoid repeat evaluation for check_hi/lo/range/index/nil. I went looking at cm3cg, to confirm that check_eq is different -- it pops its inputs, so no need for a temporary there. Ok. And then, it doesn't look like cm3cg avoids the repeat evaluation? Still I should do it? It never matters, because frontend allocates temporaries for all function call return values? (It seems to.) Therefore whatever is repeatedly evaluated, has no side effects? And because "assignment isn't expression" -- store pops its value from the stack. I think. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Thu Dec 27 16:10:29 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Thu, 27 Dec 2012 15:10:29 +0000 (GMT) Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20121224201107.F2C89CCA97@birch.elegosoft.com> Message-ID: <1356621029.55706.YahooMailClassic@web133103.mail.ir2.yahoo.com> Hi Jay: even if this does not work OK for you doesn't mean you can break code clarity, please reconsider writing values instead of constants it can lead to misunderstand the purpose of those values (even if there are limitations in current implementation). Anyway, the CONS values must be transparent bit converted from decimal arithmetic. Why don't you convert it from it and solve this in Modula-3 style. Take my advice, but if not explain me please why not so Thanks in advance --- El lun, 24/12/12, Jay Krell escribi?: De: Jay Krell Asunto: [M3commit] CVS Update: cm3 Para: m3commit at elegosoft.com Fecha: lunes, 24 de diciembre, 2012 16:11 CVSROOT:??? /usr/cvs Changes by:??? jkrell at birch.??? 12/12/24 21:11:07 Modified files: ??? cm3/m3-sys/m3middle/src/: Target.i3 Log message: ??? remove new internal_Real_max, internal_Longreal_max and ??? copy around the values 3.40282346638528860x+38, 1.79769313486231570x+308 ??? intead of expanding the public interface -------------- next part -------------- An HTML attachment was scrubbed... URL: