From jkrell at elego.de Thu Sep 6 11:11:49 2012 From: jkrell at elego.de (Jay Krell) Date: Thu, 6 Sep 2012 11:11:49 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911211914.9E5DECC85E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/06 11:11:49 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: work in progress -- 4 space indent From jkrell at elego.de Sat Sep 8 11:24:09 2012 From: jkrell at elego.de (Jay Krell) Date: Sat, 8 Sep 2012 11:24:09 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911211914.EC6FFCC85A@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/08 11:24:09 Modified files: cm3/m3-libs/m3core/src/float/: m3makefile Log message: generally assume all targets are IEEE This is overridable. (i.e. Cray, VAX...) generally assume all targets support C99 This is also overridable. (NT still uses IEEE-default) I am assuming C99 is widespread. Like to everything but NT. Including FreeBSD, NetBSD, OpenBSD, Solaris, Darwin, VMS, OSF, Interix, Linux, HPUX, Cygwin, MINGW. This could break folks. It goes like this: For special case targets, fill in _FloatPieces with all the pieces. else: fill in _FloatPiecesNoC99 or _FloatPiecesC99 with "LINUX", "NT", etc. get C99 or IEEE-default get IEEE get IEEE-le or IEEE-be depending on TARGET_ENDIAN, which config files all now set From hosking at elego.de Tue Sep 4 16:52:46 2012 From: hosking at elego.de (Antony Hosking) Date: Tue, 4 Sep 2012 16:52:46 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911211915.42D5ECC85C@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 12/09/04 16:52:46 Modified files: cm3/m3-sys/m3middle/src/: M3CG_Rd.m3 Log message: Best to retain error checking on return values from Convert.ToInt. From jkrell at elego.de Fri Sep 7 14:43:01 2012 From: jkrell at elego.de (Jay Krell) Date: Fri, 7 Sep 2012 14:43:01 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911211915.B793ECC84F@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/07 14:43:01 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: fix declare_global -- completely? hack Cstring__strcpy, strcat From hosking at elego.de Tue Sep 4 16:44:20 2012 From: hosking at elego.de (Antony Hosking) Date: Tue, 4 Sep 2012 16:44:20 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911211917.98EAECC934@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 12/09/04 16:44:20 Modified files: cm3/m3-sys/m3middle/src/: M3CG_BinWr.m3 Log message: Revert for consistency, but retain ChunkSize exposure. From jkrell at elego.de Thu Sep 6 11:05:52 2012 From: jkrell at elego.de (Jay Krell) Date: Thu, 6 Sep 2012 11:05:52 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911211935.57877CC85C@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/06 11:05:52 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: implement case_jump From hosking at elego.de Thu Sep 6 04:03:07 2012 From: hosking at elego.de (Antony Hosking) Date: Thu, 6 Sep 2012 4:03:07 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911211946.A611ACC919@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 12/09/06 04:03:07 Modified files: cm3/m3-sys/m3middle/src/: M3CG.i3 Log message: For Jay, so he can put Int32 in a record... (not sure why, but hey, let's humor him). From jkrell at elego.de Sat Sep 8 11:34:39 2012 From: jkrell at elego.de (Jay Krell) Date: Sat, 8 Sep 2012 11:34:39 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911211946.F1A98CC960@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/08 11:34:39 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: go back to old INTEGER/WORD_T to fix problem with ReportFault, change MAKE_ to M3_ From jkrell at elego.de Sat Sep 8 11:56:13 2012 From: jkrell at elego.de (Jay Krell) Date: Sat, 8 Sep 2012 11:56:13 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911211947.2B033CC90A@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/08 11:56:13 Modified files: cm3/m3-libs/m3core/src/float/Common/: m3makefile Removed files: cm3/m3-libs/m3core/src/float/Common/: FPU.c Log message: ldexp takes an int, not an INTEGER call it and sqrt directly From hosking at elego.de Tue Sep 4 16:43:27 2012 From: hosking at elego.de (Antony Hosking) Date: Tue, 4 Sep 2012 16:43:27 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911211948.CF3BBCC909@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 12/09/04 16:43:27 Modified files: cm3/m3-sys/m3middle/src/: M3Buf.m3 Log message: ChunkSize was exposed elsewhere. I agree with Jay that it may be better to be consistent, but leave the rest as was for efficiency. From hosking at elego.de Tue Sep 4 15:47:04 2012 From: hosking at elego.de (Antony Hosking) Date: Tue, 4 Sep 2012 15:47:04 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911211949.08287CC922@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 12/09/04 15:47:04 Modified files: cm3/m3-sys/m3middle/src/: M3CG.i3 Log message: Revert DAMAGE From hosking at elego.de Thu Sep 6 15:50:48 2012 From: hosking at elego.de (Antony Hosking) Date: Thu, 6 Sep 2012 15:50:48 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911211949.2A584CC85C@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 12/09/06 15:50:48 Modified files: cm3/m3-sys/m3middle/src/: M3CG_Wr.m3 Log message: Need a more principled solution than this. From pmckinna at elego.de Sat Sep 8 03:40:15 2012 From: pmckinna at elego.de (Peter McKinna) Date: Sat, 8 Sep 2012 3:40:15 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911211950.3FB28CC95D@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: pmckinna at birch. 12/09/08 03:40:15 Modified files: cm3/m3-ui/glut/src/: GLUT.i3 GLUT.m3 GLUTRaw.i3 GLUTRaw.m3 m3makefile Log message: Update glut to 2.04 From jkrell at elego.de Sat Sep 8 09:56:50 2012 From: jkrell at elego.de (Jay Krell) Date: Sat, 8 Sep 2012 9:56:50 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911211950.83F52CC97C@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/08 09:56:50 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: pop just one from not instead of two, of course From hosking at elego.de Mon Sep 10 18:14:08 2012 From: hosking at elego.de (Antony Hosking) Date: Mon, 10 Sep 2012 18:14:08 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911211950.58DFBCC96D@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 12/09/10 18:14:08 Modified files: cm3/m3-sys/m3front/src/values/: Formal.m3 Log message: Make sure that we don't treat BITS FOR ARRAY as assignable to VAR formals of type ARRAY OF. From jkrell at elego.de Wed Sep 5 08:42:01 2012 From: jkrell at elego.de (Jay Krell) Date: Wed, 5 Sep 2012 8:42:01 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911211950.85F47CC991@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/05 08:42:01 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: fix some of the C++ problems but really we need to put the globals before all of the code (and cast function pointers to the right type) From jkrell at elego.de Fri Sep 7 13:27:03 2012 From: jkrell at elego.de (Jay Krell) Date: Fri, 7 Sep 2012 13:27:03 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911211950.B25BCCC92D@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/07 13:27:03 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: void => m3_void int => m3_int etc. handle all C and C++ keywords This is needed sooner rather than later. Fix load_float/init_float to: 1.2e3 => 1.2e3F float/REAL 1.2d3 => 1.2e3 double/LONGREAL 1.2x3 => 1.2e3L long double/EXTENDED While at it, add "U" to uint8/16/32 literals and LL/ULL/I64/UI64 to uint64/int64 literals. From jkrell at elego.de Fri Sep 7 15:13:27 2012 From: jkrell at elego.de (Jay Krell) Date: Fri, 7 Sep 2012 15:13:27 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911211952.16428CC925@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/07 15:13:27 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: can compile many files now...work in progress... From jkrell at elego.de Sat Sep 8 11:57:04 2012 From: jkrell at elego.de (Jay Krell) Date: Sat, 8 Sep 2012 11:57:04 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911211951.B0ED7CC935@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/08 11:57:04 Added files: cm3/m3-libs/m3core/src/float/Common/: FPU.i3 Log message: ldexp takes int not INTEGER call it and sqrt directly forgot to add this file a few minutes ago and then editing it now From pmckinna at elego.de Sat Sep 8 03:34:17 2012 From: pmckinna at elego.de (Peter McKinna) Date: Sat, 8 Sep 2012 3:34:17 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911211951.AD273CC92D@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: pmckinna at birch. 12/09/08 03:34:17 Modified files: cm3/m3-ui/glut/swig/: glut.i glutcallback.i glutext.i glutfont.i glutinit.i Log message: Updated glut to swig 2.04 and removed GL dependancy From hosking at elego.de Tue Sep 4 16:47:46 2012 From: hosking at elego.de (Antony Hosking) Date: Tue, 4 Sep 2012 16:47:46 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911211951.07387CC904@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 12/09/04 16:47:46 Modified files: cm3/m3-sys/m3middle/src/: M3CG_Check.m3 Log message: PutErr is not intended to be a method. From jkrell at elego.de Sat Sep 8 10:25:48 2012 From: jkrell at elego.de (Jay Krell) Date: Sat, 8 Sep 2012 10:25:48 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911211952.8A17DCC9BD@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/08 10:25:48 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: 1) put suffixes in integer literals (could be inlined except for 64bit), 2) handle import_global From jkrell at elego.de Thu Sep 6 11:08:04 2012 From: jkrell at elego.de (Jay Krell) Date: Thu, 6 Sep 2012 11:08:04 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911211952.B0C07CC9C7@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/06 11:08:04 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: work in progress -- 4 space indent From jkrell at elego.de Sat Sep 1 10:13:57 2012 From: jkrell at elego.de (Jay Krell) Date: Sat, 1 Sep 2012 10:13:57 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911211952.4D346CC998@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/01 10:13:57 Modified files: cm3/m3-sys/m3middle/src/: M3CG.i3 Log message: remove backing from TypeUID so it can be put in a record on more platforms From hosking at elego.de Tue Sep 4 16:20:48 2012 From: hosking at elego.de (Antony Hosking) Date: Tue, 4 Sep 2012 16:20:48 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911211952.71783CC90C@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 12/09/04 16:20:48 Modified files: cm3/m3-sys/m3middle/src/: M3Buf.m3 Log message: Undo gratuitous damage: 1) ChunkSize is carefully designed to have an alignable size. 2) Comparison order is logical given dependent IF clause. 3) digits arrays are designed for speed to avoid overhead of DIV/MOD when not needed. From hosking at elego.de Tue Sep 4 17:13:51 2012 From: hosking at elego.de (Antony Hosking) Date: Tue, 4 Sep 2012 17:13:51 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911211953.B2FFFCC935@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 12/09/04 17:13:51 Modified files: cm3/m3-sys/m3middle/src/: m3makefile Removed files: cm3/m3-sys/m3middle/src/: TCardinal.i3 TCardinal.m3 Log message: Remove dead TCardinal. Don't build speculative stuff in production (so regressions don't fail). From jkrell at elego.de Fri Sep 7 13:34:29 2012 From: jkrell at elego.de (Jay Krell) Date: Fri, 7 Sep 2012 13:34:29 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911211955.CFCE3CC90D@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/07 13:34:29 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: semicolons after memmove/memcpy From jkrell at elego.de Sun Sep 2 23:08:27 2012 From: jkrell at elego.de (Jay Krell) Date: Sun, 2 Sep 2012 23:08:27 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911211957.8AAC8CC942@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/02 23:08:27 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: work in progress on nested functions and static links, based on M3x86.m3 From jkrell at elego.de Wed Sep 5 07:21:20 2012 From: jkrell at elego.de (Jay Krell) Date: Wed, 5 Sep 2012 7:21:20 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911211958.057ABCC972@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/05 07:21:20 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: and now m3-sys/cm3/src/Makefile.m3 can be compiled to compilable C\! From jkrell at elego.de Sat Sep 8 11:33:11 2012 From: jkrell at elego.de (Jay Krell) Date: Sat, 8 Sep 2012 11:33:11 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911211956.B2CE2CC915@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/08 11:33:11 Modified files: cm3/m3-libs/m3core/src/float/C99/: m3makefile ./: m3makefile cm3/m3-libs/m3core/src/float/Common/: m3makefile ./: m3makefile cm3/m3-libs/m3core/src/float/IEEE-default/: m3makefile Added files: cm3/m3-libs/m3core/src/float/Common/: FPU.c ./: FPU.c Removed files: cm3/m3-libs/m3core/src/float/C99/: FPU.c FPU.i3 ./: FPU.c FPU.i3 cm3/m3-libs/m3core/src/float/IEEE-default/: FPU.i3 FPU.m3 Log message: move FPU.i3, FPU.c to common wrap sqrt in C also From jkrell at elego.de Sat Sep 8 11:24:43 2012 From: jkrell at elego.de (Jay Krell) Date: Sat, 8 Sep 2012 11:24:43 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911211957.4DD41CC935@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/08 11:24:43 Modified files: cm3/m3-libs/m3core/src/float/C99/: FPU.i3 m3makefile Added files: cm3/m3-libs/m3core/src/float/C99/: FPU.c Removed files: cm3/m3-libs/m3core/src/float/C99/: FPU.m3 Log message: implement FPU.scalb via FPU__ldexp, via a C wrapper, as is common now I caught this because the declaration is wrong here, int vs. INTEGER. The C backend causes an interesting interop feature -- we actually get static checking of our redeclarations, if #include is in the C code, or if the compiler knows the function. gcc does let us pass INTEGER to int w/o truncation warning, so do that. Ok? From jkrell at elego.de Wed Sep 5 08:53:20 2012 From: jkrell at elego.de (Jay Krell) Date: Wed, 5 Sep 2012 8:53:20 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911211957.48556CC933@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/05 08:53:20 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: typo in comment From hosking at elego.de Tue Sep 4 16:29:54 2012 From: hosking at elego.de (Antony Hosking) Date: Tue, 4 Sep 2012 16:29:54 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911212000.63428CC84F@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 12/09/04 16:29:54 Modified files: cm3/m3-sys/m3middle/src/: M3CG_BinRd.m3 Log message: Remove <*ASSERT TRUE*> in module block. (?) From jkrell at elego.de Thu Sep 6 11:43:37 2012 From: jkrell at elego.de (Jay Krell) Date: Thu, 6 Sep 2012 11:43:37 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911212003.92DBFCC8E8@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/06 11:43:37 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: void => m3_void (in user identifiers), etc. -- all C reserved words foo => m3_foo, for a list I came up with; so cm3/Utils.m3 compiles From hosking at elego.de Tue Sep 4 17:11:09 2012 From: hosking at elego.de (Antony Hosking) Date: Tue, 4 Sep 2012 17:11:09 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911212003.A5E4FCC84F@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 12/09/04 17:11:09 Modified files: cm3/m3-sys/m3middle/src/: Target.i3 Target.m3 Log message: Remove unnecessary paranoia. CARDINAL is always sufficient to capture alignment, byte size, packing, for builtin (target) types. From jkrell at elego.de Sun Sep 2 23:27:31 2012 From: jkrell at elego.de (Jay Krell) Date: Sun, 2 Sep 2012 23:27:31 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911212004.1DF91CC8E2@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/02 23:27:31 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: work in progress on nested functions and static links, based on M3x86.m3 From jkrell at elego.de Sun Sep 2 10:57:19 2012 From: jkrell at elego.de (Jay Krell) Date: Sun, 2 Sep 2012 10:57:19 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911212006.0BD24CC862@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/02 10:57:19 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: work in progress on nested functions and static links; based on M3x86.m3; not quite right From hosking at elego.de Tue Sep 4 17:20:10 2012 From: hosking at elego.de (Antony Hosking) Date: Tue, 4 Sep 2012 17:20:10 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911212006.10600CC851@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 12/09/04 17:20:10 Modified files: cm3/m3-sys/m3middle/src/: M3CG_BinWr.m3 Log message: Fix compile error. From jay.krell at cornell.edu Wed Sep 12 01:24:41 2012 From: jay.krell at cornell.edu (Jay K) Date: Tue, 11 Sep 2012 23:24:41 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20120911211952.71783CC90C@birch.elegosoft.com> References: <20120911211952.71783CC90C@birch.elegosoft.com> Message-ID: Fyi, 32bit DIV/MOD by any constant is optimizable by any decent compiler with 64bit operations available. Worst case, they get implemented as 64bit fixed point operations.This works for all 32bit values. The AMD optimization manual prescribes this and includes code for computing reciprocals.For example, division by 10: E:\>type 1.c int div10(int a) { return a / 10; } E:\>cl -Ox -c 1.c Microsoft (R) C/C++ Optimizing Compiler Version 14.00.50727.278 for x64 Copyright (C) Microsoft Corporation. All rights reserved. E:\>link -dump -disasm 1.obj div10: 0000000000000000: B8 67 66 66 66 mov eax,66666667h 0000000000000005: F7 E9 imul ecx 0000000000000007: C1 FA 02 sar edx,2 000000000000000A: 8B C2 mov eax,edx 000000000000000C: C1 E8 1F shr eax,1Fh 000000000000000F: 03 C2 add eax,edx 0000000000000011: C3 ret That's still not free, but it is much cheaper than general division. I should fix M3x86 do to this. :)On the other hand, it makes for larger code. E:\>cl -c 1.c Microsoft (R) C/C++ Optimizing Compiler Version 14.00.50727.278 for x64 Copyright (C) Microsoft Corporation. All rights reserved.1.cE:\>link -dump -disasm 1.obj Microsoft (R) COFF/PE Dumper Version 8.00.50727.278 Copyright (C) Microsoft Corporation. All rights reserved. Dump of file 1.objFile Type: COFF OBJECTdiv10: 0000000000000000: 89 4C 24 08 mov dword ptr [rsp+8],ecx 0000000000000004: 8B 44 24 08 mov eax,dword ptr [rsp+8] 0000000000000008: 99 cdq 0000000000000009: B9 0A 00 00 00 mov ecx,0Ah 000000000000000E: F7 F9 idiv eax,ecx 0000000000000010: C3 ret - Jay > Date: Tue, 4 Sep 2012 16:20:48 +0000 > To: m3commit at elegosoft.com > From: hosking at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: hosking at birch. 12/09/04 16:20:48 > > Modified files: > cm3/m3-sys/m3middle/src/: M3Buf.m3 > > Log message: > Undo gratuitous damage: > > 1) ChunkSize is carefully designed to have an alignable size. > 2) Comparison order is logical given dependent IF clause. > 3) digits arrays are designed for speed to avoid overhead of DIV/MOD when not > needed. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Sep 12 03:01:02 2012 From: jay.krell at cornell.edu (Jay K) Date: Wed, 12 Sep 2012 01:01:02 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20120911211948.CF3BBCC909@birch.elegosoft.com> References: <20120911211948.CF3BBCC909@birch.elegosoft.com> Message-ID: Blech, looking at the change: Generally size optimizations beat speed optimizations. Those lookup tables are wasteful. And tedious to read/write for a human, vs., the clear compact logic I put in.And as I said, division/mod by a constant is efficient, at least on 32bit systems with 64bit operations.Hm. I tried 64bit div and that was still optimized into a multiplication.The code size for that is going to be much smaller than the tables.And the affects on cache probably better too. Generally I find "if (variable relation constant)" easier to read than "if (constant relation variable)". I understand the isomorphisms, but it is still more usual to state the first. 2K is a pretty small buffer size these days. Even 64K that I chose is small. Yes I know I'm arguing both sides of size here. One is code size, the other is buffer size. Integer to text has been implemented countless times. I suspect my way with one table is way more common than your way with three tables. - Jay > Date: Tue, 4 Sep 2012 16:43:27 +0000 > To: m3commit at elegosoft.com > From: hosking at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: hosking at birch. 12/09/04 16:43:27 > > Modified files: > cm3/m3-sys/m3middle/src/: M3Buf.m3 > > Log message: > ChunkSize was exposed elsewhere. I agree with Jay that it may be better to be > consistent, but leave the rest as was for efficiency. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Wed Sep 12 19:18:55 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Wed, 12 Sep 2012 18:18:55 +0100 (BST) Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20120911211957.4DD41CC935@birch.elegosoft.com> Message-ID: <1347470335.11446.YahooMailClassic@web29705.mail.ird.yahoo.com> Hi all: with all due respect this is what I warned about mixing RTs in one compiler, most unsafety of C in Modula-3 is not a good idea, good C ideas are indeed needed, e.g. Fail-Safe C, gcc will have a Fail-safe plugin, if c is what you want to, use it. Jay I know of a way to ask old DEC-SRC Modula-3 -> C compiler, if you want even possibly asking the compiler in C, wouldn't that make the trick for us of compiling in AMD64_NT? We don't need to have the whole world in C to do that, do we? You could recompile itself and make a ready to boot compiler. Thanks in advance --- El s?b, 8/9/12, Jay Krell escribi?: De: Jay Krell Asunto: [M3commit] CVS Update: cm3 Para: m3commit at elegosoft.com Fecha: s?bado, 8 de septiembre, 2012 06:24 CVSROOT:??? /usr/cvs Changes by:??? jkrell at birch.??? 12/09/08 11:24:43 Modified files: ??? cm3/m3-libs/m3core/src/float/C99/: FPU.i3 m3makefile Added files: ??? cm3/m3-libs/m3core/src/float/C99/: FPU.c Removed files: ??? cm3/m3-libs/m3core/src/float/C99/: FPU.m3 Log message: ??? implement FPU.scalb via FPU__ldexp, via a C wrapper, ??? as is common now ??? ??? I caught this because the declaration is wrong here, ??? int vs. INTEGER. The C backend causes an interesting ??? interop feature -- we actually get static checking ??? of our redeclarations, if #include is in the C code, ??? or if the compiler knows the function. ??? ??? gcc does let us pass INTEGER to int w/o truncation warning, ??? so do that. Ok? -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Wed Sep 12 23:37:52 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Wed, 12 Sep 2012 22:37:52 +0100 (BST) Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20120911212000.63428CC84F@birch.elegosoft.com> Message-ID: <1347485872.13135.YahooMailClassic@web29705.mail.ird.yahoo.com> Hi all: RT assumptions must be hold true the same at compile time as at RT, so it's safe if both pragmas ("nested one") and outer one there hold at RT, not just first one case. Thanks in advance --- El mar, 4/9/12, Antony Hosking escribi?: De: Antony Hosking Asunto: [M3commit] CVS Update: cm3 Para: m3commit at elegosoft.com Fecha: martes, 4 de septiembre, 2012 11:29 CVSROOT:??? /usr/cvs Changes by:??? hosking at birch.??? 12/09/04 16:29:54 Modified files: ??? cm3/m3-sys/m3middle/src/: M3CG_BinRd.m3 Log message: ??? Remove <*ASSERT TRUE*> in module block.? (?) -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkrell at elego.de Thu Sep 13 12:09:05 2012 From: jkrell at elego.de (Jay Krell) Date: Thu, 13 Sep 2012 12:09:05 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120913100905.28F5CCC85C@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/13 12:09:05 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: do our own integer to text conversions workaround more bad declarations: ldexp signgam cabs frexp modf jn yn From jkrell at elego.de Fri Sep 14 10:03:59 2012 From: jkrell at elego.de (Jay Krell) Date: Fri, 14 Sep 2012 10:03:59 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120914080359.DA316CC85C@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/14 10:03:59 Modified files: cm3/m3-libs/libm3/src/arith/POSIX/: Math.i3 ./: Math.i3 cm3/m3-libs/libm3/src/arith/WIN32/: Math.i3 Log message: change INTEGER to int for correctness revert old whitespace comment change "may be" to "may be" From jkrell at elego.de Fri Sep 14 10:27:06 2012 From: jkrell at elego.de (Jay Krell) Date: Fri, 14 Sep 2012 10:27:06 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120914082706.4FE23CC85C@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/14 10:27:06 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: Darwin.common Log message: some of the calls to configure_c_compiler seem unnecessary they were added here: http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/cminstall/src/config-no-install/Darwin.common.diff?r1=1.41;r2=1.42 just add comment "why?" and the link should open bugs to revisit.. From jkrell at elego.de Fri Sep 14 11:03:28 2012 From: jkrell at elego.de (Jay Krell) Date: Fri, 14 Sep 2012 11:03:28 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120914090328.45A16CC85E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/14 11:03:28 Modified files: cm3/m3-sys/m3quake/src/: M3Path.m3 Log message: lowercase NONAME.EXE to noname.exe From jkrell at elego.de Fri Sep 14 11:03:58 2012 From: jkrell at elego.de (Jay Krell) Date: Fri, 14 Sep 2012 11:03:58 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120914090358.5CD81CC85C@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/14 11:03:58 Modified files: cm3/m3-sys/m3quake/src/: M3Path.m3 Log message: leave it alone..might be useful on VMS? From jkrell at elego.de Fri Sep 14 14:07:49 2012 From: jkrell at elego.de (Jay Krell) Date: Fri, 14 Sep 2012 14:07:49 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120914120749.D1594CC85A@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/14 14:07:49 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: "rewrite" get_static_link...so it doesn't access violate.. test case is compiling m3core/.../DragonT.m3 for PPC_DARWIN... I'm still not sure I understand this...maybe Tony will look.. From jkrell at elego.de Fri Sep 14 14:23:21 2012 From: jkrell at elego.de (Jay Krell) Date: Fri, 14 Sep 2012 14:23:21 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120914122321.3ACEF2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/14 14:23:21 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: fix RTHooks__ReportFault declaration...yuck... From jkrell at elego.de Fri Sep 14 14:54:36 2012 From: jkrell at elego.de (Jay Krell) Date: Fri, 14 Sep 2012 14:54:36 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120914125436.F07BB2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/14 14:54:36 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: more often declare static link correct...PPC_DARWIN m3core now all compiles..some link problems..looks minor.. From jkrell at elego.de Fri Sep 14 14:57:39 2012 From: jkrell at elego.de (Jay Krell) Date: Fri, 14 Sep 2012 14:57:39 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120914125739.4E4A0CC851@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/14 14:57:39 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: missing underscore in helper function names, and missing abs(float) -- I thought abs was only for integers From jkrell at elego.de Fri Sep 14 14:59:52 2012 From: jkrell at elego.de (Jay Krell) Date: Fri, 14 Sep 2012 14:59:52 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120914125952.E69CDCC851@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/14 14:59:52 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: fix abs(float) From jkrell at elego.de Fri Sep 14 15:01:46 2012 From: jkrell at elego.de (Jay Krell) Date: Fri, 14 Sep 2012 15:01:46 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120914130146.12F6F2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/14 15:01:46 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: add more helpers From jkrell at elego.de Fri Sep 14 15:05:03 2012 From: jkrell at elego.de (Jay Krell) Date: Fri, 14 Sep 2012 15:05:03 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120914130503.6E117CC851@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/14 15:05:03 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: fix signextend name, consider suppressing some imports to fix other problems.. From jkrell at elego.de Fri Sep 14 15:08:57 2012 From: jkrell at elego.de (Jay Krell) Date: Fri, 14 Sep 2012 15:08:57 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120914130857.332A9CC851@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/14 15:08:57 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: in insert_n, insert_mn, extract_n, extract_mn, change 'm' to 'offset', 'n' to 'count' for clarity and I hope correctness add extra required parameter 'count' to sign_extend From jkrell at elego.de Fri Sep 14 15:12:30 2012 From: jkrell at elego.de (Jay Krell) Date: Fri, 14 Sep 2012 15:12:30 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120914131230.444E92474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/14 15:12:30 Modified files: cm3/m3-sys/cm3/src/: Makefile.m3 Log message: remove whitespace from ends of lines From jkrell at elego.de Fri Sep 14 15:31:03 2012 From: jkrell at elego.de (Jay Krell) Date: Fri, 14 Sep 2012 15:31:03 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120914133103.E53782474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/14 15:31:03 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: predeclare struct sizes up to 28 for libm3/Transform.m3 add casts to WORD_T* for set operations include set sizes in set operations (bit counts of byte counts?) From jkrell at elego.de Sun Sep 16 09:44:45 2012 From: jkrell at elego.de (Jay Krell) Date: Sun, 16 Sep 2012 9:44:45 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120917054345.F024FCC862@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/16 09:44:45 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: Unix.common Log message: use -o object in compile_c, so e.g. we can compile foo.m3.c to foo.mo (rather than foo.m3.o..which really isn't a bad idea, but not what the 'builder' is used to..) From jkrell at elego.de Sun Sep 16 10:27:01 2012 From: jkrell at elego.de (Jay Krell) Date: Sun, 16 Sep 2012 10:27:01 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120917054455.3DFFCCC85E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/16 10:27:01 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: PPC_DARWIN Unix.common cm3cfg.common Log message: support: USE_C_BACKEND = TRUE From jkrell at elego.de Sun Sep 16 10:03:48 2012 From: jkrell at elego.de (Jay Krell) Date: Sun, 16 Sep 2012 10:03:48 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120917054746.5237ECC85E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/16 10:03:48 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: Unix.common Log message: previous checkin added -g unconditionally in compile_c; undo that, but add it conditionally on 'debug' -- not clear what is the best option here, -g, -ggdb, -g2, -gstabs, etc. From jkrell at elego.de Sun Sep 16 09:55:58 2012 From: jkrell at elego.de (Jay Krell) Date: Sun, 16 Sep 2012 9:55:58 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120917054749.9A7BCCC862@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/16 09:55:58 Modified files: cm3/m3-sys/m3cgcat/src/: Main.m3 m3makefile Log message: repeated Params.Get(0) => arg0 := Params.Get(0) and use arg0 program => Program, so it gets installed to bin instead of pkg fix warnings i.e. get this into shape to avoid the 'builder' changes since I don't want to wait for them to be approved, just use the existing mode=ExternalObject or even mode=ExternalAssembly support It's not a terrible model, esp. while in development. More files and more processes make for more "entry points" i.e. "easy to debug points". From jkrell at elego.de Sun Sep 16 00:40:10 2012 From: jkrell at elego.de (Jay Krell) Date: Sun, 16 Sep 2012 0:40:10 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120917054904.5EE7ACC84F@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/16 00:40:10 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: some struct reworking -- use the lame non-deal "standard structs", since we don't easily know the size of returned structs Pass structs by pointer, and copy into a local value. (Uplevel structs?) I don't want to do it this way.. C has perfectly good by-value struct parameters and results, and we aren't ABI-compliant this way, if it matters. (need to check the other front ends -- "standard structs" is basically always at high risk of being non-compliant on modern systems, "standard" of course being another name for "usually wrong"! but yes I should know the ABIs better on all systems..) Notice how we cast to void* when passing structs, where otherwise we have no void* casts, always ADDRESS which is char* and we get types more correct in general..but not here.. Need to confirm my observations here..need to get the Builder changes in so Tony maybe can look? (or redo it via config/quake to look like an existing mode.. maybe... I don't like the modes and now I've added another..) avoid #include math.h/string.h -- seems to speed it up still #include stddef.h unfortunately, need to try to fix that need to collect size_t and ptrdiff_t and typedef them ourselves where possible, else fallback to #include stddef.h declare the following ourselves, without #include: ceil, floor, memcpy, memmove, memset This might be a losing battle though. We could either bite the bullet and #include. Or #include if needed (making a second pass over the code). Or provide wrappers in m3core, losing inlining. add more min/max/abs wrappers, e.g. for REAL and EXTENDED (REAL needed, EXTENDED not) tentatively Var => M3CG.Var tentatively Proc => M3CG.Proc tentatively CVar => Var tentatively CProc => Proc compose structs of short/int/INT64, not just char, to try to raise their alignment fix typo internal_declara_param => internal_declare_param ongoing conversion to 4 space indentation change set operations between bit_size and byte_size correct now? fix fatal error in compare where it popped 1 instead of 2 (and then pushed, overall pop 1) this causes an access violation in TextLitInfo because it was writing into readonly memory; horrendous little problem, took a while to track down..need to be careful, the debugging costs are high... From jkrell at elego.de Sun Sep 16 10:17:49 2012 From: jkrell at elego.de (Jay Krell) Date: Sun, 16 Sep 2012 10:17:49 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120917054844.EE9EACC85E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/16 10:17:49 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: PPC_DARWIN Log message: have m3_backend use m3cgcat and compile_c and reuse existing builder mode ExternalObject (2) but this is less efficient than calling M3C directly w/o going through M3CG_BinWr/Rd/m3cgcat Actually switch PPC_DARWIN to C backend. In case anyone else wants to try it, to debug it. It certainly doesn't work yet! Eventually, if we stick with this model (hopefully not), this m3_backend should move to a common place, e.g. BackendC.common or cm3cfg.common triggered by a global boolean BACKEND_GENERATES_C or USE_C_BACKEND.. From jkrell at elego.de Mon Sep 17 13:03:54 2012 From: jkrell at elego.de (Jay Krell) Date: Mon, 17 Sep 2012 13:03:54 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120917110354.10E44CC85A@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/17 13:03:54 Modified files: cm3/m3-libs/m3core/src/runtime/common/: RTLinkerX.i3 Log message: remove extra newline from end of file From jkrell at elego.de Mon Sep 17 13:07:11 2012 From: jkrell at elego.de (Jay Krell) Date: Mon, 17 Sep 2012 13:07:11 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120917110712.03421CC85A@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/17 13:07:11 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: is_const => const const => const_text 4 space indentation (work in progress) add target/wordsize at top of C restore "static" on non-exported globals (important! avoids duplicates and errors) and then most importantly, pad out segments to their declared sizes very important -- to get the zeros at the end instead of garbage this fixes crashing at "startup" (in RTLinker.InitRuntime) ..it still crashes in RTLinker.InitRuntime, but it gets significantly further From jkrell at elego.de Wed Sep 19 06:55:39 2012 From: jkrell at elego.de (Jay Krell) Date: Wed, 19 Sep 2012 6:55:39 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120919045546.5CD402474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/19 06:55:39 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: put line directives in comments (for now) put static_link last instead of first This lets us get much further: RunMainBody: exec: ../src/etimer/ETimer.m3(3) Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x00000004 0x00343511 in ETimer__Push (t=0x16bc1b8 "??B") at ETimer.mc.c:743 743 (*(volatile INT32*)(4+(ADDRESS)*(volatile ADDRESS*)&L_14))=(INT32)(((INT32)(((INT32)(((INT32)(*(volatile INT32*)(4+(ADDRESS)*(volatile ADDRESS*)&L_14)))+((INT32)(((INT32)1)))))))); (gdb) (before at Main(0) we ran the body, which was wrong) print min32 and min64 as -max32 and -max64-1 to fix warning From jkrell at elego.de Thu Sep 20 14:27:23 2012 From: jkrell at elego.de (Jay Krell) Date: Thu, 20 Sep 2012 14:27:23 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120920122723.D4E5E2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/20 14:27:23 Added files: cm3/m3-sys/m3tests/src/c1/c138/: Main.m3 m3makefile Log message: some exception handling tests..surely I need more.. From jkrell at elego.de Thu Sep 20 14:37:10 2012 From: jkrell at elego.de (Jay Krell) Date: Thu, 20 Sep 2012 14:37:10 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120920123710.EDB6B2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/20 14:37:10 Modified files: cm3/m3-sys/m3tests/src/c1/c138/: Main.m3 Log message: augment test some From jkrell at elego.de Thu Sep 20 14:43:40 2012 From: jkrell at elego.de (Jay Krell) Date: Thu, 20 Sep 2012 14:43:40 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120920124340.A35802474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/20 14:43:40 Modified files: cm3/m3-sys/m3tests/src/c1/c138/: Main.m3 Log message: augment..and found a frontend bug? this program fails to link, but should From jkrell at elego.de Thu Sep 20 14:52:28 2012 From: jkrell at elego.de (Jay Krell) Date: Thu, 20 Sep 2012 14:52:28 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120920125228.4E0E52474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/20 14:52:28 Added files: cm3/m3-sys/m3tests/src/c1/c139/: Main.m3 m3makefile Log message: valid program that fails to link with current backend From jkrell at elego.de Thu Sep 20 14:53:40 2012 From: jkrell at elego.de (Jay Krell) Date: Thu, 20 Sep 2012 14:53:40 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120920125340.4B6D72474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/20 14:53:40 Modified files: cm3/m3-sys/m3tests/src/c1/c138/: Main.m3 Log message: augments tests, remove the link failure for now From jkrell at elego.de Thu Sep 20 14:54:39 2012 From: jkrell at elego.de (Jay Krell) Date: Thu, 20 Sep 2012 14:54:39 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120920125439.503952474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/20 14:54:39 Modified files: cm3/m3-sys/m3tests/src/c1/c138/: Main.m3 Log message: renumber From jkrell at elego.de Thu Sep 20 15:16:52 2012 From: jkrell at elego.de (Jay Krell) Date: Thu, 20 Sep 2012 15:16:52 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120920131652.AA7A52474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/20 15:16:52 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: declare/implement finally procs as K&R instead of ANSI since they are not always passed the activation/exception record (I need to write tests to see when they use it, and if never, then just omit it) for nested functions in general, put static_link last, not first, since it is often passed for indirect calls to non-nested functions but for finally procs, put it first, since it is always passed, and the other parameter isn't always passed at all but note, in call_indirect, we put it always last, so that is a bug I think frontend needs to always pass the exception/activation information, even if nil, to fix this. uniquify all local names, for now, since begin/end_block don't provide the scoping they are meant to, because declare/import_procedure comes in at arbitrary times.. fix struct sizes, but it probably wasn't really wrong current state uncertain, but previously, by putting the static link last, I got much much further..lots of code ran, and then assertion failure deep in garbage collector...moving attention maybe to m3-sys/m3tests.. if fixing this finally proc stuff doesn't fix the garbage collector.. From jkrell at elego.de Thu Sep 20 15:21:21 2012 From: jkrell at elego.de (Jay Krell) Date: Thu, 20 Sep 2012 15:21:21 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120920132121.8B5402474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/20 15:21:21 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: add m3_sign_extend_T(INT64) helper From jkrell at elego.de Thu Sep 20 15:23:48 2012 From: jkrell at elego.de (Jay Krell) Date: Thu, 20 Sep 2012 15:23:48 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120920132348.B9E312474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/20 15:23:48 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: Darwin.common Log message: -g works much better than -gstabs+ on Darwin (at least my old version, but really, it isn't surprising, stabs isn't the native symbol type on most systems and -g is what people usually use..)) From jkrell at elego.de Thu Sep 20 15:35:54 2012 From: jkrell at elego.de (Jay Krell) Date: Thu, 20 Sep 2012 15:35:54 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120920133554.E82D82474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/20 15:35:54 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: oops -- use div/mod helpers! fixes test p227 From jkrell at elego.de Thu Sep 20 15:38:51 2012 From: jkrell at elego.de (Jay Krell) Date: Thu, 20 Sep 2012 15:38:51 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120920133851.187E82474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/20 15:38:51 Modified files: cm3/scripts/python/: pylib.py Log message: allow saying buildship more than once -- last action wins From jkrell at elego.de Thu Sep 20 15:46:26 2012 From: jkrell at elego.de (Jay Krell) Date: Thu, 20 Sep 2012 15:46:26 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120920134626.394CB2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/20 15:46:26 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: oops -- div/mod helpers only for signed types From jkrell at elego.de Thu Sep 20 16:00:00 2012 From: jkrell at elego.de (Jay Krell) Date: Thu, 20 Sep 2012 16:00:00 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120920140000.61D3A2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/20 16:00:00 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: oops -- shift by negative value needs to negate the shift count! (see test p227 with -lp flag) From jkrell at elego.de Thu Sep 20 16:07:33 2012 From: jkrell at elego.de (Jay Krell) Date: Thu, 20 Sep 2012 16:07:33 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120920140734.3C3E42474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/20 16:07:33 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: oops -- shift the other direction\! (and reverse the cases for possible micro optimization) From jkrell at elego.de Thu Sep 20 16:37:00 2012 From: jkrell at elego.de (Jay Krell) Date: Thu, 20 Sep 2012 16:37:00 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120920143700.8DA41CC8B8@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/20 16:37:00 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: wow, oops, bit by mixing signed and unsigned\! when range checking INTEGER shift against 8 * sizeof(x) and -(8 * sizeof(x)) -- sizeof is unsigned, all 'negative' values are NOT less than it.. (again, see test p227) From jkrell at elego.de Thu Sep 20 22:52:36 2012 From: jkrell at elego.de (Jay Krell) Date: Thu, 20 Sep 2012 22:52:36 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120920205236.A943FCC8BB@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/20 22:52:36 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: hack, workaround frontend bug? when making direct calls to finally blocks, pass an extra parameter restore consistent order that static_link is always last disable K&R hack for finally blocks keep K&R code..in future I expect K&R will be a global option here NOW CM3 BUILT WITH C BACKEND CAN ITSELF COMPILE M3CORE. This is a huge milestone. The next ones to look at are: compiling all of cm3, m3-sys/m3tests (at least one hits an assertion failure in the compiler), and compiling the entire system, and running some of it (we don't have a good way to test running the entire system) From dabenavidesd at yahoo.es Thu Sep 20 23:12:18 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Thu, 20 Sep 2012 22:12:18 +0100 (BST) Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20120920205236.A943FCC8BB@birch.elegosoft.com> Message-ID: <1348175538.24375.YahooMailClassic@web29702.mail.ird.yahoo.com> Hi all: Who can create a common RT from C and Modula-3, I guess you can but should we create a libc in Modula-3? Like LINUXLIBC6 to be compatible with your linked code (C NT RT and a glibc in one model)? That way we have a true multiplatform, systems programming language. Is this approach what M3 people wanted? DEC-SRC again experimented with it, maybe useful to consider that. Thanks in advance --- El jue, 20/9/12, Jay Krell escribi?: De: Jay Krell Asunto: [M3commit] CVS Update: cm3 Para: m3commit at elegosoft.com Fecha: jueves, 20 de septiembre, 2012 17:52 CVSROOT:??? /usr/cvs Changes by:??? jkrell at birch.??? 12/09/20 22:52:36 Modified files: ??? cm3/m3-sys/m3back/src/: M3C.m3 Log message: ??? hack, workaround frontend bug? ??? ??? when making direct calls to finally blocks, pass an extra ??? parameter ??? ??? restore consistent order that static_link is always last ??? disable K&R hack for finally blocks ??? keep K&R code..in future I expect K&R will be a global option here ??? ??? NOW CM3 BUILT WITH C BACKEND CAN ITSELF COMPILE M3CORE. ??? This is a huge milestone. ??? The next ones to look at are: compiling all of cm3, m3-sys/m3tests ??? (at least one hits an assertion failure in the compiler), and compiling ??? the entire system, and running some of it (we don't have a good way ??? to test running the entire system) -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkrell at elego.de Fri Sep 21 01:18:32 2012 From: jkrell at elego.de (Jay Krell) Date: Fri, 21 Sep 2012 1:18:32 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120920231832.C867B2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/21 01:18:32 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: == package /Users/jay/dev2/cm3/m3-comm/tcp == new source -> compiling StreamWrClass.m3 StreamWrClass.mc.c: In function ???StreamWr__ByteCount???: StreamWrClass.mc.c:312: warning: passing argument 1 of ???StreamWrClass_M3_LINE_43_1??? from incompatible pointer type StreamWrClass.mc.c:312: error: too few arguments to function ???StreamWrClass_M3_LINE_43_1??? Fix this: recognize finally blocks module_line_number_number and not just module_line_number (Imho the backend shouldn't know about any of this stuff, but the frontend is wierd..) From jkrell at elego.de Sat Sep 22 02:31:18 2012 From: jkrell at elego.de (Jay Krell) Date: Sat, 22 Sep 2012 2:31:18 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120924194455.409CDCC90E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/22 02:31:17 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: various remove volatile from loads/stores add volatile to struct fields 4 space indent cleanup casting -- add it in consistently there are no very few uses of "cast" -- they are all in "get" some code sharing -- "unop", "binop" turn on #line directives remove globals start prototyping "symbolic expressions" -- needed I think to fix that we shift by constants greater than size CVar, Var => Var_t (I'm also sympathetic to var_t) avoid comments across line boundaries, so we can add comments in almost arbitrarily for debugging reduce default debug output remove spaces from ends of lines From jkrell at elego.de Sat Sep 22 06:00:57 2012 From: jkrell at elego.de (Jay Krell) Date: Sat, 22 Sep 2012 6:00:57 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120924194455.8BDA7CC926@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/22 06:00:57 Modified files: cm3/m3-sys/m3middle/src/: m3makefile Log message: compile multipass and donothing I don't like these names particularly..suggestions? From jkrell at elego.de Sat Sep 22 02:20:38 2012 From: jkrell at elego.de (Jay Krell) Date: Sat, 22 Sep 2012 2:20:38 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120924194455.BA425CC935@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/22 02:20:37 Modified files: cm3/m3-sys/m3middle/src/: M3CG_MultiPass.i3 M3CG_MultiPass.m3 Log message: significant work in progress on data structures useful to backends -- storing up all the m3cg in memory, to be looped over/played back, in order to get it into the order needed This is a LOT of tedious work. It was SO much easier to do in m3cc via the preprocessor. A macro processor can be incredibly useful. Really. Three or so modes are allowed for (which does increase the tedium). One can loop over the array of refs and use ISTYPE/NARROW/LOOPHOLE. ISTYPE/NARROW would be unnecessarily slow, LOOPHOLE would be fast One can loop pver and switch on a type tag (not all filled in). One can pass in a M3CG and the data will all be passed to its appropriate functions (work in progress). And then pass in a different M3CG, that shares state with the first. Like, "mini" M3CGs that do nothing (inherit from M3CG_DoNothing) but pay attention to only a few functions, like e.g. to accumulate a list of all struct sizes. I will probably use that last option. This will give us the power to fix several things: - support arbitrary struct sizes as parameters - pass and esp. return structs by value letting the C compiler do the work, as well as being ABI compliant (what we haven't isn't a violation per se, for our code, as you can write your C this way; it is a violation for <*extern*> though.) - only declare/implement static helper functions that we use - support uplevel locals in nested blocks -- to enable building the whole system! - forward declare all imports ahead of all functions, and therefore - just once - honor begin/end_block; stop tacking numbers onto identifiers - maybe honor free_temp - generate valid C++ for the module globals (w/o an extra indirection) - possibly use real structs and infer real field accesses - maybe more (there is more to improve, not sure if this stuff needed for it; e.g. move globals out of the "segment" would be nice remove obviously unused functions; fix shifts by greater than size (requires symbolic expressions instead of strings) - much better stock debugging! (due to the structs) ` From jkrell at elego.de Sat Sep 22 02:33:15 2012 From: jkrell at elego.de (Jay Krell) Date: Sat, 22 Sep 2012 2:33:15 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120924194455.958A9CC928@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/22 02:33:15 Modified files: cm3/m3-sys/m3middle/src/: M3CG_DoNothing.i3 Log message: comment only From hosking at elego.de Sun Sep 23 05:33:08 2012 From: hosking at elego.de (Antony Hosking) Date: Sun, 23 Sep 2012 5:33:08 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120924194456.1B45ECC953@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 12/09/23 05:33:08 Added files: cm3/m3-sys/llvm/src/: LLVM.i3 Log message: Modula-3 interface to LLVM C APIs. From jkrell at elego.de Mon Sep 24 22:37:10 2012 From: jkrell at elego.de (Jay Krell) Date: Mon, 24 Sep 2012 22:37:10 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120924203710.DD8F9CC90A@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/24 22:37:10 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: don't discard pop side effects trim the logging code -- can/should use other M3CGs for logging trim commented out code cleanup shift/insert/extract wrt reuse "binop" => "op2" "unop" => "op1" "ADDRESS" => "WORD_T*" in a few places as needed, for sets fix comment in set_intersection/difference/etc. "pop(2)" => "pop(3)" Use IntLiteral instead of IntToDec -- it can make a difference sometimes fix shift/rotate counts to be word or int, not the type of the values (aka some cleanup before the real work) From dabenavidesd at yahoo.es Tue Sep 25 00:22:40 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Mon, 24 Sep 2012 23:22:40 +0100 (BST) Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20120924194455.BA425CC935@birch.elegosoft.com> Message-ID: <1348525360.11590.YahooMailClassic@web29702.mail.ird.yahoo.com> Hi all: if a pre processor is more powerful than the language we are designing is a design mistake or we are not getting the whole picture here, the language code generator is to maintain portability in one way using different code generator for each platform. Other approaches are not recommended for this scenario (but are possible), or if you want why you don't use C Code Generating - Modula-3 compiler (it will make compiler faster?), you can remove the m3cg step and be quicker if you might on that agreeing in that M3CG is minded for light weight fast turn around backend or slow high quality back-end compiler. Why do you think writing high quality compiler is better in C than in Modula-3? Of course C is far better to hack, but if you can write **same** purpose compiler in Modula-3, that's better IMHO. What do you think Jay? See M3CG interface generator speed versus C compiling speed perhaps using a standard complexity test of grammars will tell the truth. I believe that's the idea in M3CG to make the lowest complexity making biggest speed up, I believe the same for C but not for the speed but for space of memory, that was its design goal. SO if you ask about expressive power of the language both are about the same, but for speed and complexity (in grammar terms is an open question: http://event.cwi.nl/pem/2011/2011-02-24-Zaytsev.pdf ) due its different scenario is not fair to compare Thanks in advance --- El vie, 21/9/12, Jay Krell escribi?: De: Jay Krell Asunto: [M3commit] CVS Update: cm3 Para: m3commit at elegosoft.com Fecha: viernes, 21 de septiembre, 2012 21:20 CVSROOT:??? /usr/cvs Changes by:??? jkrell at birch.??? 12/09/22 02:20:37 Modified files: ??? cm3/m3-sys/m3middle/src/: M3CG_MultiPass.i3 M3CG_MultiPass.m3 Log message: ??? significant work in progress on data structures ??? useful to backends -- storing up all the m3cg ??? in memory, to be looped over/played back, in order ??? to get it into the order needed ??? ??? This is a LOT of tedious work. ??? It was SO much easier to do in m3cc via the preprocessor. ??? A macro processor can be incredibly useful. Really. ??? ??? Three or so modes are allowed for (which does increase the tedium). ??? One can loop over the array of refs and use ISTYPE/NARROW/LOOPHOLE. ??? ISTYPE/NARROW would be unnecessarily slow, LOOPHOLE would be fast ??? One can loop pver and switch on a type tag (not all filled in). ??? One can pass in a M3CG and the data will all be passed to ??? its appropriate functions (work in progress). ??? And then pass in a different M3CG, that shares state with the first. ??? Like, "mini" M3CGs that do nothing (inherit from M3CG_DoNothing) ??? but pay attention to only a few functions, like e.g. to accumulate ??? a list of all struct sizes. ??? ??? I will probably use that last option. ??? ??? This will give us the power to fix several things: ??? - support arbitrary struct sizes as parameters ??? - pass and esp. return structs by value letting the C compiler do the work, ??? as well as being ABI compliant (what we haven't isn't a violation per se, ??? for our code, as you can write your C this way; it is a violation for <*extern*> though.) ??? - only declare/implement static helper functions that we use ??? - support uplevel locals in nested blocks -- to enable building the whole system! ??? - forward declare all imports ahead of all functions, and therefore ??? - just once ??? - honor begin/end_block; stop tacking numbers onto identifiers ??? - maybe honor free_temp ??? - generate valid C++ for the module globals (w/o an extra indirection) ??? - possibly use real structs and infer real field accesses ??? - maybe more (there is more to improve, not sure if this stuff ??? needed for it; e.g. move globals out of the "segment" would be nice ??? remove obviously unused functions; fix shifts by greater than size ??? (requires symbolic expressions instead of strings) ??? - much better stock debugging! (due to the structs) ??? ` -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Tue Sep 25 01:38:01 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Tue, 25 Sep 2012 00:38:01 +0100 (BST) Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20120924194455.8BDA7CC926@birch.elegosoft.com> Message-ID: <1348529881.1480.YahooMailClassic@web29704.mail.ird.yahoo.com> Hi all: Jay, what about M3CG_NOps I don't think MultiPass looks very informative, what about M3CG_Proxy Thanks in advance --- El s?b, 22/9/12, Jay Krell escribi?: De: Jay Krell Asunto: [M3commit] CVS Update: cm3 Para: m3commit at elegosoft.com Fecha: s?bado, 22 de septiembre, 2012 01:00 CVSROOT:??? /usr/cvs Changes by:??? jkrell at birch.??? 12/09/22 06:00:57 Modified files: ??? cm3/m3-sys/m3middle/src/: m3makefile Log message: ??? compile multipass and donothing ??? I don't like these names particularly..suggestions? -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at elego.de Tue Sep 25 04:53:07 2012 From: hosking at elego.de (Antony Hosking) Date: Tue, 25 Sep 2012 4:53:07 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120925025307.2DFBACC90E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 12/09/25 04:53:07 Modified files: cm3/m3-sys/m3middle/src/: M3ID.i3 M3ID.m3 Log message: Allow C code to share M3ID strings. From hosking at elego.de Tue Sep 25 19:07:46 2012 From: hosking at elego.de (Antony Hosking) Date: Tue, 25 Sep 2012 19:07:46 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120925170746.68F1DCC912@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 12/09/25 19:07:46 Modified files: cm3/m3-sys/llvm/src/: LLVM.i3 Log message: Missed some. From jkrell at elego.de Wed Sep 26 09:36:13 2012 From: jkrell at elego.de (Jay Krell) Date: Wed, 26 Sep 2012 9:36:13 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120926073613.D210F2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/26 09:36:13 Modified files: cm3/m3-sys/cm3/src/: Makefile.m3 Log message: cleanup: cnt: INTEGER => got_mode: BOOLEAN It is safer, cleaner, more correct to set bool := TRUE than to INC(int). The integer can wraparound and become FALSE. There is no extra value in it -- we only check for cnt > 0. We don't need the read/modify/write of INC, just the write of assignment to FALSE I don't know why people use this pattern, but I've seen it before. It seems like extra work for no value. From jkrell at elego.de Wed Sep 26 09:39:19 2012 From: jkrell at elego.de (Jay Krell) Date: Wed, 26 Sep 2012 9:39:19 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120926073920.04C2E2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/26 09:39:19 Modified files: cm3/m3-sys/cm3/src/: M3Backend.m3 Log message: cleanup with an eye toward preserving horizontal space From hosking at elego.de Wed Sep 26 19:12:38 2012 From: hosking at elego.de (Antony Hosking) Date: Wed, 26 Sep 2012 19:12:38 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120926171238.1D96BCC916@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 12/09/26 19:12:38 Modified files: cm3/m3-sys/m3front/src/values/: Formal.m3 Log message: Restore fix from 1.14. The loop should check every dimension of the array. From jkrell at elego.de Thu Sep 27 07:29:00 2012 From: jkrell at elego.de (Jay Krell) Date: Thu, 27 Sep 2012 7:29:00 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120927052901.2C2FCCC919@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/27 07:29:00 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: cm3.cfg Log message: fix typo in error message that suggests targets: I386_SOLARS => I386_SOLARIS From jkrell at elego.de Fri Sep 28 07:57:22 2012 From: jkrell at elego.de (Jay Krell) Date: Fri, 28 Sep 2012 7:57:22 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120928055722.52E5CCC92A@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/28 07:57:22 Modified files: cm3/m3-sys/m3middle/src/: M3ID.m3 Log message: fix it to compile From jkrell at elego.de Fri Sep 28 07:58:22 2012 From: jkrell at elego.de (Jay Krell) Date: Fri, 28 Sep 2012 7:58:22 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120928055822.E93432474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/28 07:58:22 Modified files: cm3/m3-sys/m3back/src/: M3C.i3 M3C.m3 ./: M3C.i3 M3C.m3 cm3/m3-sys/m3middle/src/: M3CG_MultiPass.i3 M3CG_MultiPass.m3 Log message: "u" => "self" "U" => "T" finish the multipass infrastructure including working out the Var/Proc vs. tag/INTEGER stuff I kind of wanted to stop trafficing in the pointers and only traffic in tag/INTEGER, to save some efficiency, but the result isn't all that bad -- it leaves M3C oblivious/unchanged hookup M3CG to multipass and actually make it multipass but don't take any advantate of it yet Remove commented out code that tried to swap the parameter order in except blocks. This was to try to deal with the frontend wierdness where it doesn't always pass the exception argument. But it didn't work because of indirect calls? I also tried K&R as a hack. No go. Workaround I went with is to push extra parameter for direct calls. Lame all around here. Result can still upgrade itself, very nice. We can build up to libarithmetic, which hits the known problem: ../AMD64_DARWIN/BigIntegerComplexGCD.m3 => ../src/algebra/misc/GCD.mg:118: warning: anonymous struct declared inside parameter list add some more builtin struct sizes for that multipass is also meant to address that problem cleanly: discovering all struct sizes and declaring them all early, not just lame hardcoded list which is both too many and not enough (I previously compiled up to a different point -- uplevel locals declared in sub-blocks; why the difference? I don't know. It is possible there were other changes and I hadn't tried compiling everything, maybe only up to cm3. In particular, maybe not the passing of structs correctly by value (by pointer and then copied into a local)? That is where the error is here. That is another area where multipass will help a lot..maybe.. passing/returning structs by value -- letting the C compiler do the work. The reason we can't return them by value is because m3cg doesn't tell us the size of a function's return type! We might be able to guess it from the "_result" variable -- lame...) Indeed..I now compile up to: == package /Users/jay/dev2/cm3/m3-libs/m3tk-misc == *** *** runtime error: *** <*ASSERT*> failed. *** file "../src/M3C.m3", line 1614 * which is where I got to before -- uplevel local declared when already in the middle of a function..too late in the current code for putting it in the frame struct..will fix soon now that multiple passes are easy. (in particular -- I haven't invented an M3C-specific IR. The IR is a faithful storing of the M3CG calls, in memory.) From jkrell at elego.de Fri Sep 28 12:50:15 2012 From: jkrell at elego.de (Jay Krell) Date: Fri, 28 Sep 2012 12:50:15 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120928105015.BF8D8CC92D@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/28 12:50:15 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 ./: M3C.m3 cm3/m3-sys/m3middle/src/: M3CG_DoNothing.i3 M3CG_DoNothing.m3 M3CG_MultiPass.i3 M3CG_MultiPass.m3 m3makefile Log message: first use of multipass: make an extra pass to discover all struct sizes, so all structs can be predeclared, and no extra (eventually to be replaced by better typing, but this is useful in the current context) Also, to ensure M3C.T implements all METHODS of M3CG_Ops.Public, derive it from M3CG_AssertFalse.T instead of the bogus M3CG.T. M3CG_MultiPass: in end_unit, flatten into plain public array instead of slower sequence separate out per-op also, since sometims that provides for optimization From jkrell at elego.de Fri Sep 28 13:00:14 2012 From: jkrell at elego.de (Jay Krell) Date: Fri, 28 Sep 2012 13:00:14 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120928110014.7E8F3CC92D@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/28 13:00:14 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: remove RTIO, add comments From jkrell at elego.de Fri Sep 28 13:05:04 2012 From: jkrell at elego.de (Jay Krell) Date: Fri, 28 Sep 2012 13:05:04 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120928110504.622EBCC92D@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/28 13:05:04 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: fix brand style From hosking at cs.purdue.edu Fri Sep 28 16:01:47 2012 From: hosking at cs.purdue.edu (Antony Hosking) Date: Fri, 28 Sep 2012 10:01:47 -0400 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20120928055822.E93432474003@birch.elegosoft.com> References: <20120928055822.E93432474003@birch.elegosoft.com> Message-ID: Jay, I?m not convinced that you need multiple passes if you simply cache state in the Proc structures and then dump it at the end of the procedure. There is no need for you to write to output on every opcode. You can accumulate all you need and then dump at the end. ? T On Sep 28, 2012, at 7:58 AM, jkrell at elego.de (Jay Krell) wrote: > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 12/09/28 07:58:22 > > Modified files: > cm3/m3-sys/m3back/src/: M3C.i3 M3C.m3 > ./: M3C.i3 M3C.m3 > cm3/m3-sys/m3middle/src/: M3CG_MultiPass.i3 M3CG_MultiPass.m3 > > Log message: > "u" => "self" > "U" => "T" > > finish the multipass infrastructure > including working out the Var/Proc vs. tag/INTEGER stuff > I kind of wanted to stop trafficing in the pointers and > only traffic in tag/INTEGER, to save some efficiency, > but the result isn't all that bad -- it leaves M3C oblivious/unchanged > > hookup M3CG to multipass and actually make it multipass > but don't take any advantate of it yet > > Remove commented out code that tried to swap the parameter > order in except blocks. This was to try to deal with > the frontend wierdness where it doesn't always pass the exception argument. > But it didn't work because of indirect calls? > I also tried K&R as a hack. No go. > Workaround I went with is to push extra parameter for direct calls. > Lame all around here. > > Result can still upgrade itself, very nice. > > We can build up to libarithmetic, which hits > the known problem: > ../AMD64_DARWIN/BigIntegerComplexGCD.m3 => ../src/algebra/misc/GCD.mg:118: > warning: anonymous struct declared inside parameter list > > add some more builtin struct sizes for that > multipass is also meant to address that problem cleanly: discovering > all struct sizes and declaring them all early, not just lame hardcoded list > which is both too many and not enough > > (I previously compiled up to a different point -- uplevel locals > declared in sub-blocks; why the difference? I don't know. It is possible > there were other changes and I hadn't tried compiling everything, maybe > only up to cm3. In particular, maybe not the passing of structs correctly > by value (by pointer and then copied into a local)? That is where the error > is here. That is another area where multipass will help a lot..maybe.. > passing/returning structs by value -- letting the C compiler do the work. > The reason we can't return them by value is because m3cg doesn't tell us > the size of a function's return type! We might be able to guess it > from the "_result" variable -- lame...) > > Indeed..I now compile up to: > > == package /Users/jay/dev2/cm3/m3-libs/m3tk-misc == > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "../src/M3C.m3", line 1614 > * > > which is where I got to before -- uplevel local declared > when already in the middle of a function..too late in the current > code for putting it in the frame struct..will fix soon now > that multiple passes are easy. > (in particular -- I haven't invented an M3C-specific IR. > The IR is a faithful storing of the M3CG calls, in memory.) > From jay.krell at cornell.edu Sat Sep 29 20:56:41 2012 From: jay.krell at cornell.edu (Jay K) Date: Sat, 29 Sep 2012 18:56:41 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20120928055822.E93432474003@birch.elegosoft.com>, Message-ID: Maybe. Just to declare the parameters and possibly return typerequires such "buffering" though -- if they include structs,of sizes we haven't seen before. Also, the reordering afforded by multiple passes will letme put module globals first instead of last.Currently otherwise I have to chose between an extra pointerindirection, or generating invalid C++. It is just rather liberating to have this power. It is true that function-at-a-time instead of unit-at-a-timeaffords much of the same power. There are other examples where reordering/buffering/multiple passeswill help but true that function-at-a-time often suffices. For example, I only want to output helper functions that are used. I'll try to come to some decision and proceed.My next step was/is to fix the uplevel-locals-in-nested-blocks problem. - Jay > From: hosking at cs.purdue.edu > Date: Fri, 28 Sep 2012 10:01:47 -0400 > To: jkrell at elego.de > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > Jay, > > I?m not convinced that you need multiple passes if you simply cache state in the Proc structures and then dump it at the end of the procedure. There is no need for you to write to output on every opcode. You can accumulate all you need and then dump at the end. > > ? T > > On Sep 28, 2012, at 7:58 AM, jkrell at elego.de (Jay Krell) wrote: > > > CVSROOT: /usr/cvs > > Changes by: jkrell at birch. 12/09/28 07:58:22 > > > > Modified files: > > cm3/m3-sys/m3back/src/: M3C.i3 M3C.m3 > > ./: M3C.i3 M3C.m3 > > cm3/m3-sys/m3middle/src/: M3CG_MultiPass.i3 M3CG_MultiPass.m3 > > > > Log message: > > "u" => "self" > > "U" => "T" > > > > finish the multipass infrastructure > > including working out the Var/Proc vs. tag/INTEGER stuff > > I kind of wanted to stop trafficing in the pointers and > > only traffic in tag/INTEGER, to save some efficiency, > > but the result isn't all that bad -- it leaves M3C oblivious/unchanged > > > > hookup M3CG to multipass and actually make it multipass > > but don't take any advantate of it yet > > > > Remove commented out code that tried to swap the parameter > > order in except blocks. This was to try to deal with > > the frontend wierdness where it doesn't always pass the exception argument. > > But it didn't work because of indirect calls? > > I also tried K&R as a hack. No go. > > Workaround I went with is to push extra parameter for direct calls. > > Lame all around here. > > > > Result can still upgrade itself, very nice. > > > > We can build up to libarithmetic, which hits > > the known problem: > > ../AMD64_DARWIN/BigIntegerComplexGCD.m3 => ../src/algebra/misc/GCD.mg:118: > > warning: anonymous struct declared inside parameter list > > > > add some more builtin struct sizes for that > > multipass is also meant to address that problem cleanly: discovering > > all struct sizes and declaring them all early, not just lame hardcoded list > > which is both too many and not enough > > > > (I previously compiled up to a different point -- uplevel locals > > declared in sub-blocks; why the difference? I don't know. It is possible > > there were other changes and I hadn't tried compiling everything, maybe > > only up to cm3. In particular, maybe not the passing of structs correctly > > by value (by pointer and then copied into a local)? That is where the error > > is here. That is another area where multipass will help a lot..maybe.. > > passing/returning structs by value -- letting the C compiler do the work. > > The reason we can't return them by value is because m3cg doesn't tell us > > the size of a function's return type! We might be able to guess it > > from the "_result" variable -- lame...) > > > > Indeed..I now compile up to: > > > > == package /Users/jay/dev2/cm3/m3-libs/m3tk-misc == > > > > *** > > *** runtime error: > > *** <*ASSERT*> failed. > > *** file "../src/M3C.m3", line 1614 > > * > > > > which is where I got to before -- uplevel local declared > > when already in the middle of a function..too late in the current > > code for putting it in the frame struct..will fix soon now > > that multiple passes are easy. > > (in particular -- I haven't invented an M3C-specific IR. > > The IR is a faithful storing of the M3CG calls, in memory.) > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkrell at elego.de Sat Sep 29 21:30:18 2012 From: jkrell at elego.de (Jay Krell) Date: Sat, 29 Sep 2012 21:30:18 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120929193018.312B02474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/29 21:30:18 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: cleanup struct size handling to be more efficient no sort -- we can unique through an array of booleans indexed by size Still we have linear + two allocations. C++ would be nlgn and one allocation. Not clear which is better. Linear is good. Allocations are bad. Still the C++/STL way is a good general design that so far eludes me in Modula-3. I compete here by taking advantage of the element type being reasonably ranged integers. If the data was more arbitrary, we couldn't use the array of booleans. Even so -- this is badness e.g. on 32bit host when compiling 64bit code with a large struct size..need to think about this and probably put it back.. we shouldn't be allocating arrays whose size equals the size of user defined data structures..not good... (Modula-3 would be one allocation but I want to be lazy and have the container tell me the size. The C++ STL design might actually be doable in Modula-3, but I don't think m3core provides it. Something to work on, another time.) From jkrell at elego.de Sat Sep 29 21:39:48 2012 From: jkrell at elego.de (Jay Krell) Date: Sat, 29 Sep 2012 21:39:48 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120929193948.AED8C2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/29 21:39:48 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: Go back to using sort to unique. This way code can declare arbitrarily large structs, w/o having compiler allocate arrays that grow with struct sizes. Only arrays that grow with number of ops. (We could do much better and arrays that grow with number of struct sizes. This is a tradeof on my part..because IntSeq isn't easily efficiently sorted..whereas arrays are..because ArraySort isn't general enough..alas..) From jkrell at elego.de Sun Sep 30 08:40:23 2012 From: jkrell at elego.de (Jay Krell) Date: Sun, 30 Sep 2012 8:40:23 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120930064023.74BFB2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/30 08:40:23 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 ./: M3C.m3 cm3/m3-sys/m3middle/src/: M3CG_MultiPass.i3 M3CG_MultiPass.m3 Log message: next application of "multipass" move all imports up to before any functions so now we never need to repeat imports, because they were in the middle of a function "import_repeat" goes away, yeah. In Tony's approach, probably what we would do is not move them up before any function, but move them to just before any function they occur in the middle of. Two partial changes here also. One I ventured into by accident prematurely or incompletely. One I was too lazy to finish today but will come back to. First is that I started processing declare_procedure early, along with its declare_local, declare_temp..and then begin/end_procedure. There is a point to that, to build up frame types earlier, and to push up temps, so that I don't need "extra scopes", so that I can honor begin/end_block. (Here I have eliminated some of the "extra scopes", for imports.) for now I'm just moving up imports, not also declare_procededure/temp/local. Second is that in M3CG_MultiPass, major oops, I failed to fill in the "op" field in many of the records. MultiPass has two usage modes (at least) -- playback via virtual functions (er, OBJECT METHODS), or all the data, and playback of selective ops. The first works. The second depends on ops being set correctly..do only partly works now. There is no question this should be fixed. But it is very tedious (for lack of preprocessor), so I didn't finish it yet. Must do. Experiment: jumble labels. I don't understand the meaning of labels. Like, I understand procs/vars are created by backend, returned to frontend, and then send back to the backend. The correlation is critical. I don't understand labels in this regard. Either the correlation is critical and this messes it up. Or it doesn't matter. If it does matter, then we maybe we working only by accident. I need to do a more focused test here -- be sure to test a case/switch. If it does matter, I need to introduce "translation" in M3CG_MultiPass for labels similar to what I do for vars/procs, so it works deliberately and not by accident (the accident is the various M3CG implementations doling out the same labels, whereas they are free to assign their own "random" values, I think). My suspicion is that it can matter. If you look at how the M3x86 backend actually does work for label allocation. But M3C just uses them to format up names. In which case the internal consistency within the first pass -- M3CG.MultiPass -- I think I understand how that suffices. We'll see...I have to think about this... From jkrell at elego.de Sun Sep 30 08:48:44 2012 From: jkrell at elego.de (Jay Krell) Date: Sun, 30 Sep 2012 8:48:44 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120930064844.D04E22474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/30 08:48:44 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: rename ForwardDeclarations to Imports remove for-now-abandoned reordering of declare_procedure, etc. remove now unused import_repeat From jkrell at elego.de Thu Sep 6 11:11:49 2012 From: jkrell at elego.de (Jay Krell) Date: Thu, 6 Sep 2012 11:11:49 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911211914.9E5DECC85E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/06 11:11:49 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: work in progress -- 4 space indent From jkrell at elego.de Sat Sep 8 11:24:09 2012 From: jkrell at elego.de (Jay Krell) Date: Sat, 8 Sep 2012 11:24:09 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911211914.EC6FFCC85A@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/08 11:24:09 Modified files: cm3/m3-libs/m3core/src/float/: m3makefile Log message: generally assume all targets are IEEE This is overridable. (i.e. Cray, VAX...) generally assume all targets support C99 This is also overridable. (NT still uses IEEE-default) I am assuming C99 is widespread. Like to everything but NT. Including FreeBSD, NetBSD, OpenBSD, Solaris, Darwin, VMS, OSF, Interix, Linux, HPUX, Cygwin, MINGW. This could break folks. It goes like this: For special case targets, fill in _FloatPieces with all the pieces. else: fill in _FloatPiecesNoC99 or _FloatPiecesC99 with "LINUX", "NT", etc. get C99 or IEEE-default get IEEE get IEEE-le or IEEE-be depending on TARGET_ENDIAN, which config files all now set From hosking at elego.de Tue Sep 4 16:52:46 2012 From: hosking at elego.de (Antony Hosking) Date: Tue, 4 Sep 2012 16:52:46 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911211915.42D5ECC85C@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 12/09/04 16:52:46 Modified files: cm3/m3-sys/m3middle/src/: M3CG_Rd.m3 Log message: Best to retain error checking on return values from Convert.ToInt. From jkrell at elego.de Fri Sep 7 14:43:01 2012 From: jkrell at elego.de (Jay Krell) Date: Fri, 7 Sep 2012 14:43:01 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911211915.B793ECC84F@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/07 14:43:01 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: fix declare_global -- completely? hack Cstring__strcpy, strcat From hosking at elego.de Tue Sep 4 16:44:20 2012 From: hosking at elego.de (Antony Hosking) Date: Tue, 4 Sep 2012 16:44:20 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911211917.98EAECC934@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 12/09/04 16:44:20 Modified files: cm3/m3-sys/m3middle/src/: M3CG_BinWr.m3 Log message: Revert for consistency, but retain ChunkSize exposure. From jkrell at elego.de Thu Sep 6 11:05:52 2012 From: jkrell at elego.de (Jay Krell) Date: Thu, 6 Sep 2012 11:05:52 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911211935.57877CC85C@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/06 11:05:52 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: implement case_jump From hosking at elego.de Thu Sep 6 04:03:07 2012 From: hosking at elego.de (Antony Hosking) Date: Thu, 6 Sep 2012 4:03:07 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911211946.A611ACC919@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 12/09/06 04:03:07 Modified files: cm3/m3-sys/m3middle/src/: M3CG.i3 Log message: For Jay, so he can put Int32 in a record... (not sure why, but hey, let's humor him). From jkrell at elego.de Sat Sep 8 11:34:39 2012 From: jkrell at elego.de (Jay Krell) Date: Sat, 8 Sep 2012 11:34:39 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911211946.F1A98CC960@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/08 11:34:39 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: go back to old INTEGER/WORD_T to fix problem with ReportFault, change MAKE_ to M3_ From jkrell at elego.de Sat Sep 8 11:56:13 2012 From: jkrell at elego.de (Jay Krell) Date: Sat, 8 Sep 2012 11:56:13 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911211947.2B033CC90A@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/08 11:56:13 Modified files: cm3/m3-libs/m3core/src/float/Common/: m3makefile Removed files: cm3/m3-libs/m3core/src/float/Common/: FPU.c Log message: ldexp takes an int, not an INTEGER call it and sqrt directly From hosking at elego.de Tue Sep 4 16:43:27 2012 From: hosking at elego.de (Antony Hosking) Date: Tue, 4 Sep 2012 16:43:27 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911211948.CF3BBCC909@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 12/09/04 16:43:27 Modified files: cm3/m3-sys/m3middle/src/: M3Buf.m3 Log message: ChunkSize was exposed elsewhere. I agree with Jay that it may be better to be consistent, but leave the rest as was for efficiency. From hosking at elego.de Tue Sep 4 15:47:04 2012 From: hosking at elego.de (Antony Hosking) Date: Tue, 4 Sep 2012 15:47:04 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911211949.08287CC922@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 12/09/04 15:47:04 Modified files: cm3/m3-sys/m3middle/src/: M3CG.i3 Log message: Revert DAMAGE From hosking at elego.de Thu Sep 6 15:50:48 2012 From: hosking at elego.de (Antony Hosking) Date: Thu, 6 Sep 2012 15:50:48 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911211949.2A584CC85C@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 12/09/06 15:50:48 Modified files: cm3/m3-sys/m3middle/src/: M3CG_Wr.m3 Log message: Need a more principled solution than this. From pmckinna at elego.de Sat Sep 8 03:40:15 2012 From: pmckinna at elego.de (Peter McKinna) Date: Sat, 8 Sep 2012 3:40:15 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911211950.3FB28CC95D@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: pmckinna at birch. 12/09/08 03:40:15 Modified files: cm3/m3-ui/glut/src/: GLUT.i3 GLUT.m3 GLUTRaw.i3 GLUTRaw.m3 m3makefile Log message: Update glut to 2.04 From jkrell at elego.de Sat Sep 8 09:56:50 2012 From: jkrell at elego.de (Jay Krell) Date: Sat, 8 Sep 2012 9:56:50 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911211950.83F52CC97C@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/08 09:56:50 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: pop just one from not instead of two, of course From hosking at elego.de Mon Sep 10 18:14:08 2012 From: hosking at elego.de (Antony Hosking) Date: Mon, 10 Sep 2012 18:14:08 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911211950.58DFBCC96D@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 12/09/10 18:14:08 Modified files: cm3/m3-sys/m3front/src/values/: Formal.m3 Log message: Make sure that we don't treat BITS FOR ARRAY as assignable to VAR formals of type ARRAY OF. From jkrell at elego.de Wed Sep 5 08:42:01 2012 From: jkrell at elego.de (Jay Krell) Date: Wed, 5 Sep 2012 8:42:01 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911211950.85F47CC991@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/05 08:42:01 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: fix some of the C++ problems but really we need to put the globals before all of the code (and cast function pointers to the right type) From jkrell at elego.de Fri Sep 7 13:27:03 2012 From: jkrell at elego.de (Jay Krell) Date: Fri, 7 Sep 2012 13:27:03 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911211950.B25BCCC92D@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/07 13:27:03 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: void => m3_void int => m3_int etc. handle all C and C++ keywords This is needed sooner rather than later. Fix load_float/init_float to: 1.2e3 => 1.2e3F float/REAL 1.2d3 => 1.2e3 double/LONGREAL 1.2x3 => 1.2e3L long double/EXTENDED While at it, add "U" to uint8/16/32 literals and LL/ULL/I64/UI64 to uint64/int64 literals. From jkrell at elego.de Fri Sep 7 15:13:27 2012 From: jkrell at elego.de (Jay Krell) Date: Fri, 7 Sep 2012 15:13:27 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911211952.16428CC925@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/07 15:13:27 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: can compile many files now...work in progress... From jkrell at elego.de Sat Sep 8 11:57:04 2012 From: jkrell at elego.de (Jay Krell) Date: Sat, 8 Sep 2012 11:57:04 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911211951.B0ED7CC935@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/08 11:57:04 Added files: cm3/m3-libs/m3core/src/float/Common/: FPU.i3 Log message: ldexp takes int not INTEGER call it and sqrt directly forgot to add this file a few minutes ago and then editing it now From pmckinna at elego.de Sat Sep 8 03:34:17 2012 From: pmckinna at elego.de (Peter McKinna) Date: Sat, 8 Sep 2012 3:34:17 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911211951.AD273CC92D@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: pmckinna at birch. 12/09/08 03:34:17 Modified files: cm3/m3-ui/glut/swig/: glut.i glutcallback.i glutext.i glutfont.i glutinit.i Log message: Updated glut to swig 2.04 and removed GL dependancy From hosking at elego.de Tue Sep 4 16:47:46 2012 From: hosking at elego.de (Antony Hosking) Date: Tue, 4 Sep 2012 16:47:46 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911211951.07387CC904@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 12/09/04 16:47:46 Modified files: cm3/m3-sys/m3middle/src/: M3CG_Check.m3 Log message: PutErr is not intended to be a method. From jkrell at elego.de Sat Sep 8 10:25:48 2012 From: jkrell at elego.de (Jay Krell) Date: Sat, 8 Sep 2012 10:25:48 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911211952.8A17DCC9BD@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/08 10:25:48 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: 1) put suffixes in integer literals (could be inlined except for 64bit), 2) handle import_global From jkrell at elego.de Thu Sep 6 11:08:04 2012 From: jkrell at elego.de (Jay Krell) Date: Thu, 6 Sep 2012 11:08:04 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911211952.B0C07CC9C7@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/06 11:08:04 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: work in progress -- 4 space indent From jkrell at elego.de Sat Sep 1 10:13:57 2012 From: jkrell at elego.de (Jay Krell) Date: Sat, 1 Sep 2012 10:13:57 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911211952.4D346CC998@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/01 10:13:57 Modified files: cm3/m3-sys/m3middle/src/: M3CG.i3 Log message: remove backing from TypeUID so it can be put in a record on more platforms From hosking at elego.de Tue Sep 4 16:20:48 2012 From: hosking at elego.de (Antony Hosking) Date: Tue, 4 Sep 2012 16:20:48 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911211952.71783CC90C@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 12/09/04 16:20:48 Modified files: cm3/m3-sys/m3middle/src/: M3Buf.m3 Log message: Undo gratuitous damage: 1) ChunkSize is carefully designed to have an alignable size. 2) Comparison order is logical given dependent IF clause. 3) digits arrays are designed for speed to avoid overhead of DIV/MOD when not needed. From hosking at elego.de Tue Sep 4 17:13:51 2012 From: hosking at elego.de (Antony Hosking) Date: Tue, 4 Sep 2012 17:13:51 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911211953.B2FFFCC935@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 12/09/04 17:13:51 Modified files: cm3/m3-sys/m3middle/src/: m3makefile Removed files: cm3/m3-sys/m3middle/src/: TCardinal.i3 TCardinal.m3 Log message: Remove dead TCardinal. Don't build speculative stuff in production (so regressions don't fail). From jkrell at elego.de Fri Sep 7 13:34:29 2012 From: jkrell at elego.de (Jay Krell) Date: Fri, 7 Sep 2012 13:34:29 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911211955.CFCE3CC90D@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/07 13:34:29 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: semicolons after memmove/memcpy From jkrell at elego.de Sun Sep 2 23:08:27 2012 From: jkrell at elego.de (Jay Krell) Date: Sun, 2 Sep 2012 23:08:27 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911211957.8AAC8CC942@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/02 23:08:27 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: work in progress on nested functions and static links, based on M3x86.m3 From jkrell at elego.de Wed Sep 5 07:21:20 2012 From: jkrell at elego.de (Jay Krell) Date: Wed, 5 Sep 2012 7:21:20 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911211958.057ABCC972@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/05 07:21:20 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: and now m3-sys/cm3/src/Makefile.m3 can be compiled to compilable C\! From jkrell at elego.de Sat Sep 8 11:33:11 2012 From: jkrell at elego.de (Jay Krell) Date: Sat, 8 Sep 2012 11:33:11 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911211956.B2CE2CC915@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/08 11:33:11 Modified files: cm3/m3-libs/m3core/src/float/C99/: m3makefile ./: m3makefile cm3/m3-libs/m3core/src/float/Common/: m3makefile ./: m3makefile cm3/m3-libs/m3core/src/float/IEEE-default/: m3makefile Added files: cm3/m3-libs/m3core/src/float/Common/: FPU.c ./: FPU.c Removed files: cm3/m3-libs/m3core/src/float/C99/: FPU.c FPU.i3 ./: FPU.c FPU.i3 cm3/m3-libs/m3core/src/float/IEEE-default/: FPU.i3 FPU.m3 Log message: move FPU.i3, FPU.c to common wrap sqrt in C also From jkrell at elego.de Sat Sep 8 11:24:43 2012 From: jkrell at elego.de (Jay Krell) Date: Sat, 8 Sep 2012 11:24:43 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911211957.4DD41CC935@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/08 11:24:43 Modified files: cm3/m3-libs/m3core/src/float/C99/: FPU.i3 m3makefile Added files: cm3/m3-libs/m3core/src/float/C99/: FPU.c Removed files: cm3/m3-libs/m3core/src/float/C99/: FPU.m3 Log message: implement FPU.scalb via FPU__ldexp, via a C wrapper, as is common now I caught this because the declaration is wrong here, int vs. INTEGER. The C backend causes an interesting interop feature -- we actually get static checking of our redeclarations, if #include is in the C code, or if the compiler knows the function. gcc does let us pass INTEGER to int w/o truncation warning, so do that. Ok? From jkrell at elego.de Wed Sep 5 08:53:20 2012 From: jkrell at elego.de (Jay Krell) Date: Wed, 5 Sep 2012 8:53:20 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911211957.48556CC933@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/05 08:53:20 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: typo in comment From hosking at elego.de Tue Sep 4 16:29:54 2012 From: hosking at elego.de (Antony Hosking) Date: Tue, 4 Sep 2012 16:29:54 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911212000.63428CC84F@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 12/09/04 16:29:54 Modified files: cm3/m3-sys/m3middle/src/: M3CG_BinRd.m3 Log message: Remove <*ASSERT TRUE*> in module block. (?) From jkrell at elego.de Thu Sep 6 11:43:37 2012 From: jkrell at elego.de (Jay Krell) Date: Thu, 6 Sep 2012 11:43:37 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911212003.92DBFCC8E8@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/06 11:43:37 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: void => m3_void (in user identifiers), etc. -- all C reserved words foo => m3_foo, for a list I came up with; so cm3/Utils.m3 compiles From hosking at elego.de Tue Sep 4 17:11:09 2012 From: hosking at elego.de (Antony Hosking) Date: Tue, 4 Sep 2012 17:11:09 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911212003.A5E4FCC84F@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 12/09/04 17:11:09 Modified files: cm3/m3-sys/m3middle/src/: Target.i3 Target.m3 Log message: Remove unnecessary paranoia. CARDINAL is always sufficient to capture alignment, byte size, packing, for builtin (target) types. From jkrell at elego.de Sun Sep 2 23:27:31 2012 From: jkrell at elego.de (Jay Krell) Date: Sun, 2 Sep 2012 23:27:31 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911212004.1DF91CC8E2@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/02 23:27:31 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: work in progress on nested functions and static links, based on M3x86.m3 From jkrell at elego.de Sun Sep 2 10:57:19 2012 From: jkrell at elego.de (Jay Krell) Date: Sun, 2 Sep 2012 10:57:19 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911212006.0BD24CC862@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/02 10:57:19 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: work in progress on nested functions and static links; based on M3x86.m3; not quite right From hosking at elego.de Tue Sep 4 17:20:10 2012 From: hosking at elego.de (Antony Hosking) Date: Tue, 4 Sep 2012 17:20:10 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911212006.10600CC851@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 12/09/04 17:20:10 Modified files: cm3/m3-sys/m3middle/src/: M3CG_BinWr.m3 Log message: Fix compile error. From jay.krell at cornell.edu Wed Sep 12 01:24:41 2012 From: jay.krell at cornell.edu (Jay K) Date: Tue, 11 Sep 2012 23:24:41 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20120911211952.71783CC90C@birch.elegosoft.com> References: <20120911211952.71783CC90C@birch.elegosoft.com> Message-ID: Fyi, 32bit DIV/MOD by any constant is optimizable by any decent compiler with 64bit operations available. Worst case, they get implemented as 64bit fixed point operations.This works for all 32bit values. The AMD optimization manual prescribes this and includes code for computing reciprocals.For example, division by 10: E:\>type 1.c int div10(int a) { return a / 10; } E:\>cl -Ox -c 1.c Microsoft (R) C/C++ Optimizing Compiler Version 14.00.50727.278 for x64 Copyright (C) Microsoft Corporation. All rights reserved. E:\>link -dump -disasm 1.obj div10: 0000000000000000: B8 67 66 66 66 mov eax,66666667h 0000000000000005: F7 E9 imul ecx 0000000000000007: C1 FA 02 sar edx,2 000000000000000A: 8B C2 mov eax,edx 000000000000000C: C1 E8 1F shr eax,1Fh 000000000000000F: 03 C2 add eax,edx 0000000000000011: C3 ret That's still not free, but it is much cheaper than general division. I should fix M3x86 do to this. :)On the other hand, it makes for larger code. E:\>cl -c 1.c Microsoft (R) C/C++ Optimizing Compiler Version 14.00.50727.278 for x64 Copyright (C) Microsoft Corporation. All rights reserved.1.cE:\>link -dump -disasm 1.obj Microsoft (R) COFF/PE Dumper Version 8.00.50727.278 Copyright (C) Microsoft Corporation. All rights reserved. Dump of file 1.objFile Type: COFF OBJECTdiv10: 0000000000000000: 89 4C 24 08 mov dword ptr [rsp+8],ecx 0000000000000004: 8B 44 24 08 mov eax,dword ptr [rsp+8] 0000000000000008: 99 cdq 0000000000000009: B9 0A 00 00 00 mov ecx,0Ah 000000000000000E: F7 F9 idiv eax,ecx 0000000000000010: C3 ret - Jay > Date: Tue, 4 Sep 2012 16:20:48 +0000 > To: m3commit at elegosoft.com > From: hosking at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: hosking at birch. 12/09/04 16:20:48 > > Modified files: > cm3/m3-sys/m3middle/src/: M3Buf.m3 > > Log message: > Undo gratuitous damage: > > 1) ChunkSize is carefully designed to have an alignable size. > 2) Comparison order is logical given dependent IF clause. > 3) digits arrays are designed for speed to avoid overhead of DIV/MOD when not > needed. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Sep 12 03:01:02 2012 From: jay.krell at cornell.edu (Jay K) Date: Wed, 12 Sep 2012 01:01:02 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20120911211948.CF3BBCC909@birch.elegosoft.com> References: <20120911211948.CF3BBCC909@birch.elegosoft.com> Message-ID: Blech, looking at the change: Generally size optimizations beat speed optimizations. Those lookup tables are wasteful. And tedious to read/write for a human, vs., the clear compact logic I put in.And as I said, division/mod by a constant is efficient, at least on 32bit systems with 64bit operations.Hm. I tried 64bit div and that was still optimized into a multiplication.The code size for that is going to be much smaller than the tables.And the affects on cache probably better too. Generally I find "if (variable relation constant)" easier to read than "if (constant relation variable)". I understand the isomorphisms, but it is still more usual to state the first. 2K is a pretty small buffer size these days. Even 64K that I chose is small. Yes I know I'm arguing both sides of size here. One is code size, the other is buffer size. Integer to text has been implemented countless times. I suspect my way with one table is way more common than your way with three tables. - Jay > Date: Tue, 4 Sep 2012 16:43:27 +0000 > To: m3commit at elegosoft.com > From: hosking at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: hosking at birch. 12/09/04 16:43:27 > > Modified files: > cm3/m3-sys/m3middle/src/: M3Buf.m3 > > Log message: > ChunkSize was exposed elsewhere. I agree with Jay that it may be better to be > consistent, but leave the rest as was for efficiency. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Wed Sep 12 19:18:55 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Wed, 12 Sep 2012 18:18:55 +0100 (BST) Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20120911211957.4DD41CC935@birch.elegosoft.com> Message-ID: <1347470335.11446.YahooMailClassic@web29705.mail.ird.yahoo.com> Hi all: with all due respect this is what I warned about mixing RTs in one compiler, most unsafety of C in Modula-3 is not a good idea, good C ideas are indeed needed, e.g. Fail-Safe C, gcc will have a Fail-safe plugin, if c is what you want to, use it. Jay I know of a way to ask old DEC-SRC Modula-3 -> C compiler, if you want even possibly asking the compiler in C, wouldn't that make the trick for us of compiling in AMD64_NT? We don't need to have the whole world in C to do that, do we? You could recompile itself and make a ready to boot compiler. Thanks in advance --- El s?b, 8/9/12, Jay Krell escribi?: De: Jay Krell Asunto: [M3commit] CVS Update: cm3 Para: m3commit at elegosoft.com Fecha: s?bado, 8 de septiembre, 2012 06:24 CVSROOT:??? /usr/cvs Changes by:??? jkrell at birch.??? 12/09/08 11:24:43 Modified files: ??? cm3/m3-libs/m3core/src/float/C99/: FPU.i3 m3makefile Added files: ??? cm3/m3-libs/m3core/src/float/C99/: FPU.c Removed files: ??? cm3/m3-libs/m3core/src/float/C99/: FPU.m3 Log message: ??? implement FPU.scalb via FPU__ldexp, via a C wrapper, ??? as is common now ??? ??? I caught this because the declaration is wrong here, ??? int vs. INTEGER. The C backend causes an interesting ??? interop feature -- we actually get static checking ??? of our redeclarations, if #include is in the C code, ??? or if the compiler knows the function. ??? ??? gcc does let us pass INTEGER to int w/o truncation warning, ??? so do that. Ok? -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Wed Sep 12 23:37:52 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Wed, 12 Sep 2012 22:37:52 +0100 (BST) Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20120911212000.63428CC84F@birch.elegosoft.com> Message-ID: <1347485872.13135.YahooMailClassic@web29705.mail.ird.yahoo.com> Hi all: RT assumptions must be hold true the same at compile time as at RT, so it's safe if both pragmas ("nested one") and outer one there hold at RT, not just first one case. Thanks in advance --- El mar, 4/9/12, Antony Hosking escribi?: De: Antony Hosking Asunto: [M3commit] CVS Update: cm3 Para: m3commit at elegosoft.com Fecha: martes, 4 de septiembre, 2012 11:29 CVSROOT:??? /usr/cvs Changes by:??? hosking at birch.??? 12/09/04 16:29:54 Modified files: ??? cm3/m3-sys/m3middle/src/: M3CG_BinRd.m3 Log message: ??? Remove <*ASSERT TRUE*> in module block.? (?) -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkrell at elego.de Thu Sep 13 12:09:05 2012 From: jkrell at elego.de (Jay Krell) Date: Thu, 13 Sep 2012 12:09:05 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120913100905.28F5CCC85C@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/13 12:09:05 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: do our own integer to text conversions workaround more bad declarations: ldexp signgam cabs frexp modf jn yn From jkrell at elego.de Fri Sep 14 10:03:59 2012 From: jkrell at elego.de (Jay Krell) Date: Fri, 14 Sep 2012 10:03:59 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120914080359.DA316CC85C@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/14 10:03:59 Modified files: cm3/m3-libs/libm3/src/arith/POSIX/: Math.i3 ./: Math.i3 cm3/m3-libs/libm3/src/arith/WIN32/: Math.i3 Log message: change INTEGER to int for correctness revert old whitespace comment change "may be" to "may be" From jkrell at elego.de Fri Sep 14 10:27:06 2012 From: jkrell at elego.de (Jay Krell) Date: Fri, 14 Sep 2012 10:27:06 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120914082706.4FE23CC85C@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/14 10:27:06 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: Darwin.common Log message: some of the calls to configure_c_compiler seem unnecessary they were added here: http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/cminstall/src/config-no-install/Darwin.common.diff?r1=1.41;r2=1.42 just add comment "why?" and the link should open bugs to revisit.. From jkrell at elego.de Fri Sep 14 11:03:28 2012 From: jkrell at elego.de (Jay Krell) Date: Fri, 14 Sep 2012 11:03:28 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120914090328.45A16CC85E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/14 11:03:28 Modified files: cm3/m3-sys/m3quake/src/: M3Path.m3 Log message: lowercase NONAME.EXE to noname.exe From jkrell at elego.de Fri Sep 14 11:03:58 2012 From: jkrell at elego.de (Jay Krell) Date: Fri, 14 Sep 2012 11:03:58 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120914090358.5CD81CC85C@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/14 11:03:58 Modified files: cm3/m3-sys/m3quake/src/: M3Path.m3 Log message: leave it alone..might be useful on VMS? From jkrell at elego.de Fri Sep 14 14:07:49 2012 From: jkrell at elego.de (Jay Krell) Date: Fri, 14 Sep 2012 14:07:49 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120914120749.D1594CC85A@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/14 14:07:49 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: "rewrite" get_static_link...so it doesn't access violate.. test case is compiling m3core/.../DragonT.m3 for PPC_DARWIN... I'm still not sure I understand this...maybe Tony will look.. From jkrell at elego.de Fri Sep 14 14:23:21 2012 From: jkrell at elego.de (Jay Krell) Date: Fri, 14 Sep 2012 14:23:21 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120914122321.3ACEF2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/14 14:23:21 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: fix RTHooks__ReportFault declaration...yuck... From jkrell at elego.de Fri Sep 14 14:54:36 2012 From: jkrell at elego.de (Jay Krell) Date: Fri, 14 Sep 2012 14:54:36 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120914125436.F07BB2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/14 14:54:36 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: more often declare static link correct...PPC_DARWIN m3core now all compiles..some link problems..looks minor.. From jkrell at elego.de Fri Sep 14 14:57:39 2012 From: jkrell at elego.de (Jay Krell) Date: Fri, 14 Sep 2012 14:57:39 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120914125739.4E4A0CC851@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/14 14:57:39 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: missing underscore in helper function names, and missing abs(float) -- I thought abs was only for integers From jkrell at elego.de Fri Sep 14 14:59:52 2012 From: jkrell at elego.de (Jay Krell) Date: Fri, 14 Sep 2012 14:59:52 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120914125952.E69CDCC851@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/14 14:59:52 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: fix abs(float) From jkrell at elego.de Fri Sep 14 15:01:46 2012 From: jkrell at elego.de (Jay Krell) Date: Fri, 14 Sep 2012 15:01:46 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120914130146.12F6F2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/14 15:01:46 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: add more helpers From jkrell at elego.de Fri Sep 14 15:05:03 2012 From: jkrell at elego.de (Jay Krell) Date: Fri, 14 Sep 2012 15:05:03 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120914130503.6E117CC851@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/14 15:05:03 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: fix signextend name, consider suppressing some imports to fix other problems.. From jkrell at elego.de Fri Sep 14 15:08:57 2012 From: jkrell at elego.de (Jay Krell) Date: Fri, 14 Sep 2012 15:08:57 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120914130857.332A9CC851@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/14 15:08:57 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: in insert_n, insert_mn, extract_n, extract_mn, change 'm' to 'offset', 'n' to 'count' for clarity and I hope correctness add extra required parameter 'count' to sign_extend From jkrell at elego.de Fri Sep 14 15:12:30 2012 From: jkrell at elego.de (Jay Krell) Date: Fri, 14 Sep 2012 15:12:30 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120914131230.444E92474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/14 15:12:30 Modified files: cm3/m3-sys/cm3/src/: Makefile.m3 Log message: remove whitespace from ends of lines From jkrell at elego.de Fri Sep 14 15:31:03 2012 From: jkrell at elego.de (Jay Krell) Date: Fri, 14 Sep 2012 15:31:03 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120914133103.E53782474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/14 15:31:03 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: predeclare struct sizes up to 28 for libm3/Transform.m3 add casts to WORD_T* for set operations include set sizes in set operations (bit counts of byte counts?) From jkrell at elego.de Sun Sep 16 09:44:45 2012 From: jkrell at elego.de (Jay Krell) Date: Sun, 16 Sep 2012 9:44:45 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120917054345.F024FCC862@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/16 09:44:45 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: Unix.common Log message: use -o object in compile_c, so e.g. we can compile foo.m3.c to foo.mo (rather than foo.m3.o..which really isn't a bad idea, but not what the 'builder' is used to..) From jkrell at elego.de Sun Sep 16 10:27:01 2012 From: jkrell at elego.de (Jay Krell) Date: Sun, 16 Sep 2012 10:27:01 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120917054455.3DFFCCC85E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/16 10:27:01 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: PPC_DARWIN Unix.common cm3cfg.common Log message: support: USE_C_BACKEND = TRUE From jkrell at elego.de Sun Sep 16 10:03:48 2012 From: jkrell at elego.de (Jay Krell) Date: Sun, 16 Sep 2012 10:03:48 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120917054746.5237ECC85E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/16 10:03:48 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: Unix.common Log message: previous checkin added -g unconditionally in compile_c; undo that, but add it conditionally on 'debug' -- not clear what is the best option here, -g, -ggdb, -g2, -gstabs, etc. From jkrell at elego.de Sun Sep 16 09:55:58 2012 From: jkrell at elego.de (Jay Krell) Date: Sun, 16 Sep 2012 9:55:58 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120917054749.9A7BCCC862@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/16 09:55:58 Modified files: cm3/m3-sys/m3cgcat/src/: Main.m3 m3makefile Log message: repeated Params.Get(0) => arg0 := Params.Get(0) and use arg0 program => Program, so it gets installed to bin instead of pkg fix warnings i.e. get this into shape to avoid the 'builder' changes since I don't want to wait for them to be approved, just use the existing mode=ExternalObject or even mode=ExternalAssembly support It's not a terrible model, esp. while in development. More files and more processes make for more "entry points" i.e. "easy to debug points". From jkrell at elego.de Sun Sep 16 00:40:10 2012 From: jkrell at elego.de (Jay Krell) Date: Sun, 16 Sep 2012 0:40:10 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120917054904.5EE7ACC84F@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/16 00:40:10 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: some struct reworking -- use the lame non-deal "standard structs", since we don't easily know the size of returned structs Pass structs by pointer, and copy into a local value. (Uplevel structs?) I don't want to do it this way.. C has perfectly good by-value struct parameters and results, and we aren't ABI-compliant this way, if it matters. (need to check the other front ends -- "standard structs" is basically always at high risk of being non-compliant on modern systems, "standard" of course being another name for "usually wrong"! but yes I should know the ABIs better on all systems..) Notice how we cast to void* when passing structs, where otherwise we have no void* casts, always ADDRESS which is char* and we get types more correct in general..but not here.. Need to confirm my observations here..need to get the Builder changes in so Tony maybe can look? (or redo it via config/quake to look like an existing mode.. maybe... I don't like the modes and now I've added another..) avoid #include math.h/string.h -- seems to speed it up still #include stddef.h unfortunately, need to try to fix that need to collect size_t and ptrdiff_t and typedef them ourselves where possible, else fallback to #include stddef.h declare the following ourselves, without #include: ceil, floor, memcpy, memmove, memset This might be a losing battle though. We could either bite the bullet and #include. Or #include if needed (making a second pass over the code). Or provide wrappers in m3core, losing inlining. add more min/max/abs wrappers, e.g. for REAL and EXTENDED (REAL needed, EXTENDED not) tentatively Var => M3CG.Var tentatively Proc => M3CG.Proc tentatively CVar => Var tentatively CProc => Proc compose structs of short/int/INT64, not just char, to try to raise their alignment fix typo internal_declara_param => internal_declare_param ongoing conversion to 4 space indentation change set operations between bit_size and byte_size correct now? fix fatal error in compare where it popped 1 instead of 2 (and then pushed, overall pop 1) this causes an access violation in TextLitInfo because it was writing into readonly memory; horrendous little problem, took a while to track down..need to be careful, the debugging costs are high... From jkrell at elego.de Sun Sep 16 10:17:49 2012 From: jkrell at elego.de (Jay Krell) Date: Sun, 16 Sep 2012 10:17:49 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120917054844.EE9EACC85E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/16 10:17:49 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: PPC_DARWIN Log message: have m3_backend use m3cgcat and compile_c and reuse existing builder mode ExternalObject (2) but this is less efficient than calling M3C directly w/o going through M3CG_BinWr/Rd/m3cgcat Actually switch PPC_DARWIN to C backend. In case anyone else wants to try it, to debug it. It certainly doesn't work yet! Eventually, if we stick with this model (hopefully not), this m3_backend should move to a common place, e.g. BackendC.common or cm3cfg.common triggered by a global boolean BACKEND_GENERATES_C or USE_C_BACKEND.. From jkrell at elego.de Mon Sep 17 13:03:54 2012 From: jkrell at elego.de (Jay Krell) Date: Mon, 17 Sep 2012 13:03:54 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120917110354.10E44CC85A@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/17 13:03:54 Modified files: cm3/m3-libs/m3core/src/runtime/common/: RTLinkerX.i3 Log message: remove extra newline from end of file From jkrell at elego.de Mon Sep 17 13:07:11 2012 From: jkrell at elego.de (Jay Krell) Date: Mon, 17 Sep 2012 13:07:11 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120917110712.03421CC85A@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/17 13:07:11 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: is_const => const const => const_text 4 space indentation (work in progress) add target/wordsize at top of C restore "static" on non-exported globals (important! avoids duplicates and errors) and then most importantly, pad out segments to their declared sizes very important -- to get the zeros at the end instead of garbage this fixes crashing at "startup" (in RTLinker.InitRuntime) ..it still crashes in RTLinker.InitRuntime, but it gets significantly further From jkrell at elego.de Wed Sep 19 06:55:39 2012 From: jkrell at elego.de (Jay Krell) Date: Wed, 19 Sep 2012 6:55:39 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120919045546.5CD402474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/19 06:55:39 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: put line directives in comments (for now) put static_link last instead of first This lets us get much further: RunMainBody: exec: ../src/etimer/ETimer.m3(3) Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x00000004 0x00343511 in ETimer__Push (t=0x16bc1b8 "??B") at ETimer.mc.c:743 743 (*(volatile INT32*)(4+(ADDRESS)*(volatile ADDRESS*)&L_14))=(INT32)(((INT32)(((INT32)(((INT32)(*(volatile INT32*)(4+(ADDRESS)*(volatile ADDRESS*)&L_14)))+((INT32)(((INT32)1)))))))); (gdb) (before at Main(0) we ran the body, which was wrong) print min32 and min64 as -max32 and -max64-1 to fix warning From jkrell at elego.de Thu Sep 20 14:27:23 2012 From: jkrell at elego.de (Jay Krell) Date: Thu, 20 Sep 2012 14:27:23 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120920122723.D4E5E2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/20 14:27:23 Added files: cm3/m3-sys/m3tests/src/c1/c138/: Main.m3 m3makefile Log message: some exception handling tests..surely I need more.. From jkrell at elego.de Thu Sep 20 14:37:10 2012 From: jkrell at elego.de (Jay Krell) Date: Thu, 20 Sep 2012 14:37:10 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120920123710.EDB6B2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/20 14:37:10 Modified files: cm3/m3-sys/m3tests/src/c1/c138/: Main.m3 Log message: augment test some From jkrell at elego.de Thu Sep 20 14:43:40 2012 From: jkrell at elego.de (Jay Krell) Date: Thu, 20 Sep 2012 14:43:40 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120920124340.A35802474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/20 14:43:40 Modified files: cm3/m3-sys/m3tests/src/c1/c138/: Main.m3 Log message: augment..and found a frontend bug? this program fails to link, but should From jkrell at elego.de Thu Sep 20 14:52:28 2012 From: jkrell at elego.de (Jay Krell) Date: Thu, 20 Sep 2012 14:52:28 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120920125228.4E0E52474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/20 14:52:28 Added files: cm3/m3-sys/m3tests/src/c1/c139/: Main.m3 m3makefile Log message: valid program that fails to link with current backend From jkrell at elego.de Thu Sep 20 14:53:40 2012 From: jkrell at elego.de (Jay Krell) Date: Thu, 20 Sep 2012 14:53:40 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120920125340.4B6D72474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/20 14:53:40 Modified files: cm3/m3-sys/m3tests/src/c1/c138/: Main.m3 Log message: augments tests, remove the link failure for now From jkrell at elego.de Thu Sep 20 14:54:39 2012 From: jkrell at elego.de (Jay Krell) Date: Thu, 20 Sep 2012 14:54:39 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120920125439.503952474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/20 14:54:39 Modified files: cm3/m3-sys/m3tests/src/c1/c138/: Main.m3 Log message: renumber From jkrell at elego.de Thu Sep 20 15:16:52 2012 From: jkrell at elego.de (Jay Krell) Date: Thu, 20 Sep 2012 15:16:52 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120920131652.AA7A52474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/20 15:16:52 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: declare/implement finally procs as K&R instead of ANSI since they are not always passed the activation/exception record (I need to write tests to see when they use it, and if never, then just omit it) for nested functions in general, put static_link last, not first, since it is often passed for indirect calls to non-nested functions but for finally procs, put it first, since it is always passed, and the other parameter isn't always passed at all but note, in call_indirect, we put it always last, so that is a bug I think frontend needs to always pass the exception/activation information, even if nil, to fix this. uniquify all local names, for now, since begin/end_block don't provide the scoping they are meant to, because declare/import_procedure comes in at arbitrary times.. fix struct sizes, but it probably wasn't really wrong current state uncertain, but previously, by putting the static link last, I got much much further..lots of code ran, and then assertion failure deep in garbage collector...moving attention maybe to m3-sys/m3tests.. if fixing this finally proc stuff doesn't fix the garbage collector.. From jkrell at elego.de Thu Sep 20 15:21:21 2012 From: jkrell at elego.de (Jay Krell) Date: Thu, 20 Sep 2012 15:21:21 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120920132121.8B5402474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/20 15:21:21 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: add m3_sign_extend_T(INT64) helper From jkrell at elego.de Thu Sep 20 15:23:48 2012 From: jkrell at elego.de (Jay Krell) Date: Thu, 20 Sep 2012 15:23:48 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120920132348.B9E312474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/20 15:23:48 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: Darwin.common Log message: -g works much better than -gstabs+ on Darwin (at least my old version, but really, it isn't surprising, stabs isn't the native symbol type on most systems and -g is what people usually use..)) From jkrell at elego.de Thu Sep 20 15:35:54 2012 From: jkrell at elego.de (Jay Krell) Date: Thu, 20 Sep 2012 15:35:54 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120920133554.E82D82474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/20 15:35:54 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: oops -- use div/mod helpers! fixes test p227 From jkrell at elego.de Thu Sep 20 15:38:51 2012 From: jkrell at elego.de (Jay Krell) Date: Thu, 20 Sep 2012 15:38:51 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120920133851.187E82474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/20 15:38:51 Modified files: cm3/scripts/python/: pylib.py Log message: allow saying buildship more than once -- last action wins From jkrell at elego.de Thu Sep 20 15:46:26 2012 From: jkrell at elego.de (Jay Krell) Date: Thu, 20 Sep 2012 15:46:26 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120920134626.394CB2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/20 15:46:26 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: oops -- div/mod helpers only for signed types From jkrell at elego.de Thu Sep 20 16:00:00 2012 From: jkrell at elego.de (Jay Krell) Date: Thu, 20 Sep 2012 16:00:00 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120920140000.61D3A2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/20 16:00:00 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: oops -- shift by negative value needs to negate the shift count! (see test p227 with -lp flag) From jkrell at elego.de Thu Sep 20 16:07:33 2012 From: jkrell at elego.de (Jay Krell) Date: Thu, 20 Sep 2012 16:07:33 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120920140734.3C3E42474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/20 16:07:33 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: oops -- shift the other direction\! (and reverse the cases for possible micro optimization) From jkrell at elego.de Thu Sep 20 16:37:00 2012 From: jkrell at elego.de (Jay Krell) Date: Thu, 20 Sep 2012 16:37:00 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120920143700.8DA41CC8B8@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/20 16:37:00 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: wow, oops, bit by mixing signed and unsigned\! when range checking INTEGER shift against 8 * sizeof(x) and -(8 * sizeof(x)) -- sizeof is unsigned, all 'negative' values are NOT less than it.. (again, see test p227) From jkrell at elego.de Thu Sep 20 22:52:36 2012 From: jkrell at elego.de (Jay Krell) Date: Thu, 20 Sep 2012 22:52:36 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120920205236.A943FCC8BB@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/20 22:52:36 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: hack, workaround frontend bug? when making direct calls to finally blocks, pass an extra parameter restore consistent order that static_link is always last disable K&R hack for finally blocks keep K&R code..in future I expect K&R will be a global option here NOW CM3 BUILT WITH C BACKEND CAN ITSELF COMPILE M3CORE. This is a huge milestone. The next ones to look at are: compiling all of cm3, m3-sys/m3tests (at least one hits an assertion failure in the compiler), and compiling the entire system, and running some of it (we don't have a good way to test running the entire system) From dabenavidesd at yahoo.es Thu Sep 20 23:12:18 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Thu, 20 Sep 2012 22:12:18 +0100 (BST) Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20120920205236.A943FCC8BB@birch.elegosoft.com> Message-ID: <1348175538.24375.YahooMailClassic@web29702.mail.ird.yahoo.com> Hi all: Who can create a common RT from C and Modula-3, I guess you can but should we create a libc in Modula-3? Like LINUXLIBC6 to be compatible with your linked code (C NT RT and a glibc in one model)? That way we have a true multiplatform, systems programming language. Is this approach what M3 people wanted? DEC-SRC again experimented with it, maybe useful to consider that. Thanks in advance --- El jue, 20/9/12, Jay Krell escribi?: De: Jay Krell Asunto: [M3commit] CVS Update: cm3 Para: m3commit at elegosoft.com Fecha: jueves, 20 de septiembre, 2012 17:52 CVSROOT:??? /usr/cvs Changes by:??? jkrell at birch.??? 12/09/20 22:52:36 Modified files: ??? cm3/m3-sys/m3back/src/: M3C.m3 Log message: ??? hack, workaround frontend bug? ??? ??? when making direct calls to finally blocks, pass an extra ??? parameter ??? ??? restore consistent order that static_link is always last ??? disable K&R hack for finally blocks ??? keep K&R code..in future I expect K&R will be a global option here ??? ??? NOW CM3 BUILT WITH C BACKEND CAN ITSELF COMPILE M3CORE. ??? This is a huge milestone. ??? The next ones to look at are: compiling all of cm3, m3-sys/m3tests ??? (at least one hits an assertion failure in the compiler), and compiling ??? the entire system, and running some of it (we don't have a good way ??? to test running the entire system) -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkrell at elego.de Fri Sep 21 01:18:32 2012 From: jkrell at elego.de (Jay Krell) Date: Fri, 21 Sep 2012 1:18:32 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120920231832.C867B2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/21 01:18:32 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: == package /Users/jay/dev2/cm3/m3-comm/tcp == new source -> compiling StreamWrClass.m3 StreamWrClass.mc.c: In function ???StreamWr__ByteCount???: StreamWrClass.mc.c:312: warning: passing argument 1 of ???StreamWrClass_M3_LINE_43_1??? from incompatible pointer type StreamWrClass.mc.c:312: error: too few arguments to function ???StreamWrClass_M3_LINE_43_1??? Fix this: recognize finally blocks module_line_number_number and not just module_line_number (Imho the backend shouldn't know about any of this stuff, but the frontend is wierd..) From jkrell at elego.de Sat Sep 22 02:31:18 2012 From: jkrell at elego.de (Jay Krell) Date: Sat, 22 Sep 2012 2:31:18 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120924194455.409CDCC90E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/22 02:31:17 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: various remove volatile from loads/stores add volatile to struct fields 4 space indent cleanup casting -- add it in consistently there are no very few uses of "cast" -- they are all in "get" some code sharing -- "unop", "binop" turn on #line directives remove globals start prototyping "symbolic expressions" -- needed I think to fix that we shift by constants greater than size CVar, Var => Var_t (I'm also sympathetic to var_t) avoid comments across line boundaries, so we can add comments in almost arbitrarily for debugging reduce default debug output remove spaces from ends of lines From jkrell at elego.de Sat Sep 22 06:00:57 2012 From: jkrell at elego.de (Jay Krell) Date: Sat, 22 Sep 2012 6:00:57 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120924194455.8BDA7CC926@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/22 06:00:57 Modified files: cm3/m3-sys/m3middle/src/: m3makefile Log message: compile multipass and donothing I don't like these names particularly..suggestions? From jkrell at elego.de Sat Sep 22 02:20:38 2012 From: jkrell at elego.de (Jay Krell) Date: Sat, 22 Sep 2012 2:20:38 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120924194455.BA425CC935@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/22 02:20:37 Modified files: cm3/m3-sys/m3middle/src/: M3CG_MultiPass.i3 M3CG_MultiPass.m3 Log message: significant work in progress on data structures useful to backends -- storing up all the m3cg in memory, to be looped over/played back, in order to get it into the order needed This is a LOT of tedious work. It was SO much easier to do in m3cc via the preprocessor. A macro processor can be incredibly useful. Really. Three or so modes are allowed for (which does increase the tedium). One can loop over the array of refs and use ISTYPE/NARROW/LOOPHOLE. ISTYPE/NARROW would be unnecessarily slow, LOOPHOLE would be fast One can loop pver and switch on a type tag (not all filled in). One can pass in a M3CG and the data will all be passed to its appropriate functions (work in progress). And then pass in a different M3CG, that shares state with the first. Like, "mini" M3CGs that do nothing (inherit from M3CG_DoNothing) but pay attention to only a few functions, like e.g. to accumulate a list of all struct sizes. I will probably use that last option. This will give us the power to fix several things: - support arbitrary struct sizes as parameters - pass and esp. return structs by value letting the C compiler do the work, as well as being ABI compliant (what we haven't isn't a violation per se, for our code, as you can write your C this way; it is a violation for <*extern*> though.) - only declare/implement static helper functions that we use - support uplevel locals in nested blocks -- to enable building the whole system! - forward declare all imports ahead of all functions, and therefore - just once - honor begin/end_block; stop tacking numbers onto identifiers - maybe honor free_temp - generate valid C++ for the module globals (w/o an extra indirection) - possibly use real structs and infer real field accesses - maybe more (there is more to improve, not sure if this stuff needed for it; e.g. move globals out of the "segment" would be nice remove obviously unused functions; fix shifts by greater than size (requires symbolic expressions instead of strings) - much better stock debugging! (due to the structs) ` From jkrell at elego.de Sat Sep 22 02:33:15 2012 From: jkrell at elego.de (Jay Krell) Date: Sat, 22 Sep 2012 2:33:15 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120924194455.958A9CC928@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/22 02:33:15 Modified files: cm3/m3-sys/m3middle/src/: M3CG_DoNothing.i3 Log message: comment only From hosking at elego.de Sun Sep 23 05:33:08 2012 From: hosking at elego.de (Antony Hosking) Date: Sun, 23 Sep 2012 5:33:08 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120924194456.1B45ECC953@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 12/09/23 05:33:08 Added files: cm3/m3-sys/llvm/src/: LLVM.i3 Log message: Modula-3 interface to LLVM C APIs. From jkrell at elego.de Mon Sep 24 22:37:10 2012 From: jkrell at elego.de (Jay Krell) Date: Mon, 24 Sep 2012 22:37:10 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120924203710.DD8F9CC90A@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/24 22:37:10 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: don't discard pop side effects trim the logging code -- can/should use other M3CGs for logging trim commented out code cleanup shift/insert/extract wrt reuse "binop" => "op2" "unop" => "op1" "ADDRESS" => "WORD_T*" in a few places as needed, for sets fix comment in set_intersection/difference/etc. "pop(2)" => "pop(3)" Use IntLiteral instead of IntToDec -- it can make a difference sometimes fix shift/rotate counts to be word or int, not the type of the values (aka some cleanup before the real work) From dabenavidesd at yahoo.es Tue Sep 25 00:22:40 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Mon, 24 Sep 2012 23:22:40 +0100 (BST) Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20120924194455.BA425CC935@birch.elegosoft.com> Message-ID: <1348525360.11590.YahooMailClassic@web29702.mail.ird.yahoo.com> Hi all: if a pre processor is more powerful than the language we are designing is a design mistake or we are not getting the whole picture here, the language code generator is to maintain portability in one way using different code generator for each platform. Other approaches are not recommended for this scenario (but are possible), or if you want why you don't use C Code Generating - Modula-3 compiler (it will make compiler faster?), you can remove the m3cg step and be quicker if you might on that agreeing in that M3CG is minded for light weight fast turn around backend or slow high quality back-end compiler. Why do you think writing high quality compiler is better in C than in Modula-3? Of course C is far better to hack, but if you can write **same** purpose compiler in Modula-3, that's better IMHO. What do you think Jay? See M3CG interface generator speed versus C compiling speed perhaps using a standard complexity test of grammars will tell the truth. I believe that's the idea in M3CG to make the lowest complexity making biggest speed up, I believe the same for C but not for the speed but for space of memory, that was its design goal. SO if you ask about expressive power of the language both are about the same, but for speed and complexity (in grammar terms is an open question: http://event.cwi.nl/pem/2011/2011-02-24-Zaytsev.pdf ) due its different scenario is not fair to compare Thanks in advance --- El vie, 21/9/12, Jay Krell escribi?: De: Jay Krell Asunto: [M3commit] CVS Update: cm3 Para: m3commit at elegosoft.com Fecha: viernes, 21 de septiembre, 2012 21:20 CVSROOT:??? /usr/cvs Changes by:??? jkrell at birch.??? 12/09/22 02:20:37 Modified files: ??? cm3/m3-sys/m3middle/src/: M3CG_MultiPass.i3 M3CG_MultiPass.m3 Log message: ??? significant work in progress on data structures ??? useful to backends -- storing up all the m3cg ??? in memory, to be looped over/played back, in order ??? to get it into the order needed ??? ??? This is a LOT of tedious work. ??? It was SO much easier to do in m3cc via the preprocessor. ??? A macro processor can be incredibly useful. Really. ??? ??? Three or so modes are allowed for (which does increase the tedium). ??? One can loop over the array of refs and use ISTYPE/NARROW/LOOPHOLE. ??? ISTYPE/NARROW would be unnecessarily slow, LOOPHOLE would be fast ??? One can loop pver and switch on a type tag (not all filled in). ??? One can pass in a M3CG and the data will all be passed to ??? its appropriate functions (work in progress). ??? And then pass in a different M3CG, that shares state with the first. ??? Like, "mini" M3CGs that do nothing (inherit from M3CG_DoNothing) ??? but pay attention to only a few functions, like e.g. to accumulate ??? a list of all struct sizes. ??? ??? I will probably use that last option. ??? ??? This will give us the power to fix several things: ??? - support arbitrary struct sizes as parameters ??? - pass and esp. return structs by value letting the C compiler do the work, ??? as well as being ABI compliant (what we haven't isn't a violation per se, ??? for our code, as you can write your C this way; it is a violation for <*extern*> though.) ??? - only declare/implement static helper functions that we use ??? - support uplevel locals in nested blocks -- to enable building the whole system! ??? - forward declare all imports ahead of all functions, and therefore ??? - just once ??? - honor begin/end_block; stop tacking numbers onto identifiers ??? - maybe honor free_temp ??? - generate valid C++ for the module globals (w/o an extra indirection) ??? - possibly use real structs and infer real field accesses ??? - maybe more (there is more to improve, not sure if this stuff ??? needed for it; e.g. move globals out of the "segment" would be nice ??? remove obviously unused functions; fix shifts by greater than size ??? (requires symbolic expressions instead of strings) ??? - much better stock debugging! (due to the structs) ??? ` -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Tue Sep 25 01:38:01 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Tue, 25 Sep 2012 00:38:01 +0100 (BST) Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20120924194455.8BDA7CC926@birch.elegosoft.com> Message-ID: <1348529881.1480.YahooMailClassic@web29704.mail.ird.yahoo.com> Hi all: Jay, what about M3CG_NOps I don't think MultiPass looks very informative, what about M3CG_Proxy Thanks in advance --- El s?b, 22/9/12, Jay Krell escribi?: De: Jay Krell Asunto: [M3commit] CVS Update: cm3 Para: m3commit at elegosoft.com Fecha: s?bado, 22 de septiembre, 2012 01:00 CVSROOT:??? /usr/cvs Changes by:??? jkrell at birch.??? 12/09/22 06:00:57 Modified files: ??? cm3/m3-sys/m3middle/src/: m3makefile Log message: ??? compile multipass and donothing ??? I don't like these names particularly..suggestions? -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at elego.de Tue Sep 25 04:53:07 2012 From: hosking at elego.de (Antony Hosking) Date: Tue, 25 Sep 2012 4:53:07 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120925025307.2DFBACC90E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 12/09/25 04:53:07 Modified files: cm3/m3-sys/m3middle/src/: M3ID.i3 M3ID.m3 Log message: Allow C code to share M3ID strings. From hosking at elego.de Tue Sep 25 19:07:46 2012 From: hosking at elego.de (Antony Hosking) Date: Tue, 25 Sep 2012 19:07:46 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120925170746.68F1DCC912@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 12/09/25 19:07:46 Modified files: cm3/m3-sys/llvm/src/: LLVM.i3 Log message: Missed some. From jkrell at elego.de Wed Sep 26 09:36:13 2012 From: jkrell at elego.de (Jay Krell) Date: Wed, 26 Sep 2012 9:36:13 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120926073613.D210F2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/26 09:36:13 Modified files: cm3/m3-sys/cm3/src/: Makefile.m3 Log message: cleanup: cnt: INTEGER => got_mode: BOOLEAN It is safer, cleaner, more correct to set bool := TRUE than to INC(int). The integer can wraparound and become FALSE. There is no extra value in it -- we only check for cnt > 0. We don't need the read/modify/write of INC, just the write of assignment to FALSE I don't know why people use this pattern, but I've seen it before. It seems like extra work for no value. From jkrell at elego.de Wed Sep 26 09:39:19 2012 From: jkrell at elego.de (Jay Krell) Date: Wed, 26 Sep 2012 9:39:19 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120926073920.04C2E2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/26 09:39:19 Modified files: cm3/m3-sys/cm3/src/: M3Backend.m3 Log message: cleanup with an eye toward preserving horizontal space From hosking at elego.de Wed Sep 26 19:12:38 2012 From: hosking at elego.de (Antony Hosking) Date: Wed, 26 Sep 2012 19:12:38 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120926171238.1D96BCC916@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 12/09/26 19:12:38 Modified files: cm3/m3-sys/m3front/src/values/: Formal.m3 Log message: Restore fix from 1.14. The loop should check every dimension of the array. From jkrell at elego.de Thu Sep 27 07:29:00 2012 From: jkrell at elego.de (Jay Krell) Date: Thu, 27 Sep 2012 7:29:00 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120927052901.2C2FCCC919@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/27 07:29:00 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: cm3.cfg Log message: fix typo in error message that suggests targets: I386_SOLARS => I386_SOLARIS From jkrell at elego.de Fri Sep 28 07:57:22 2012 From: jkrell at elego.de (Jay Krell) Date: Fri, 28 Sep 2012 7:57:22 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120928055722.52E5CCC92A@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/28 07:57:22 Modified files: cm3/m3-sys/m3middle/src/: M3ID.m3 Log message: fix it to compile From jkrell at elego.de Fri Sep 28 07:58:22 2012 From: jkrell at elego.de (Jay Krell) Date: Fri, 28 Sep 2012 7:58:22 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120928055822.E93432474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/28 07:58:22 Modified files: cm3/m3-sys/m3back/src/: M3C.i3 M3C.m3 ./: M3C.i3 M3C.m3 cm3/m3-sys/m3middle/src/: M3CG_MultiPass.i3 M3CG_MultiPass.m3 Log message: "u" => "self" "U" => "T" finish the multipass infrastructure including working out the Var/Proc vs. tag/INTEGER stuff I kind of wanted to stop trafficing in the pointers and only traffic in tag/INTEGER, to save some efficiency, but the result isn't all that bad -- it leaves M3C oblivious/unchanged hookup M3CG to multipass and actually make it multipass but don't take any advantate of it yet Remove commented out code that tried to swap the parameter order in except blocks. This was to try to deal with the frontend wierdness where it doesn't always pass the exception argument. But it didn't work because of indirect calls? I also tried K&R as a hack. No go. Workaround I went with is to push extra parameter for direct calls. Lame all around here. Result can still upgrade itself, very nice. We can build up to libarithmetic, which hits the known problem: ../AMD64_DARWIN/BigIntegerComplexGCD.m3 => ../src/algebra/misc/GCD.mg:118: warning: anonymous struct declared inside parameter list add some more builtin struct sizes for that multipass is also meant to address that problem cleanly: discovering all struct sizes and declaring them all early, not just lame hardcoded list which is both too many and not enough (I previously compiled up to a different point -- uplevel locals declared in sub-blocks; why the difference? I don't know. It is possible there were other changes and I hadn't tried compiling everything, maybe only up to cm3. In particular, maybe not the passing of structs correctly by value (by pointer and then copied into a local)? That is where the error is here. That is another area where multipass will help a lot..maybe.. passing/returning structs by value -- letting the C compiler do the work. The reason we can't return them by value is because m3cg doesn't tell us the size of a function's return type! We might be able to guess it from the "_result" variable -- lame...) Indeed..I now compile up to: == package /Users/jay/dev2/cm3/m3-libs/m3tk-misc == *** *** runtime error: *** <*ASSERT*> failed. *** file "../src/M3C.m3", line 1614 * which is where I got to before -- uplevel local declared when already in the middle of a function..too late in the current code for putting it in the frame struct..will fix soon now that multiple passes are easy. (in particular -- I haven't invented an M3C-specific IR. The IR is a faithful storing of the M3CG calls, in memory.) From jkrell at elego.de Fri Sep 28 12:50:15 2012 From: jkrell at elego.de (Jay Krell) Date: Fri, 28 Sep 2012 12:50:15 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120928105015.BF8D8CC92D@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/28 12:50:15 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 ./: M3C.m3 cm3/m3-sys/m3middle/src/: M3CG_DoNothing.i3 M3CG_DoNothing.m3 M3CG_MultiPass.i3 M3CG_MultiPass.m3 m3makefile Log message: first use of multipass: make an extra pass to discover all struct sizes, so all structs can be predeclared, and no extra (eventually to be replaced by better typing, but this is useful in the current context) Also, to ensure M3C.T implements all METHODS of M3CG_Ops.Public, derive it from M3CG_AssertFalse.T instead of the bogus M3CG.T. M3CG_MultiPass: in end_unit, flatten into plain public array instead of slower sequence separate out per-op also, since sometims that provides for optimization From jkrell at elego.de Fri Sep 28 13:00:14 2012 From: jkrell at elego.de (Jay Krell) Date: Fri, 28 Sep 2012 13:00:14 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120928110014.7E8F3CC92D@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/28 13:00:14 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: remove RTIO, add comments From jkrell at elego.de Fri Sep 28 13:05:04 2012 From: jkrell at elego.de (Jay Krell) Date: Fri, 28 Sep 2012 13:05:04 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120928110504.622EBCC92D@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/28 13:05:04 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: fix brand style From hosking at cs.purdue.edu Fri Sep 28 16:01:47 2012 From: hosking at cs.purdue.edu (Antony Hosking) Date: Fri, 28 Sep 2012 10:01:47 -0400 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20120928055822.E93432474003@birch.elegosoft.com> References: <20120928055822.E93432474003@birch.elegosoft.com> Message-ID: Jay, I?m not convinced that you need multiple passes if you simply cache state in the Proc structures and then dump it at the end of the procedure. There is no need for you to write to output on every opcode. You can accumulate all you need and then dump at the end. ? T On Sep 28, 2012, at 7:58 AM, jkrell at elego.de (Jay Krell) wrote: > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 12/09/28 07:58:22 > > Modified files: > cm3/m3-sys/m3back/src/: M3C.i3 M3C.m3 > ./: M3C.i3 M3C.m3 > cm3/m3-sys/m3middle/src/: M3CG_MultiPass.i3 M3CG_MultiPass.m3 > > Log message: > "u" => "self" > "U" => "T" > > finish the multipass infrastructure > including working out the Var/Proc vs. tag/INTEGER stuff > I kind of wanted to stop trafficing in the pointers and > only traffic in tag/INTEGER, to save some efficiency, > but the result isn't all that bad -- it leaves M3C oblivious/unchanged > > hookup M3CG to multipass and actually make it multipass > but don't take any advantate of it yet > > Remove commented out code that tried to swap the parameter > order in except blocks. This was to try to deal with > the frontend wierdness where it doesn't always pass the exception argument. > But it didn't work because of indirect calls? > I also tried K&R as a hack. No go. > Workaround I went with is to push extra parameter for direct calls. > Lame all around here. > > Result can still upgrade itself, very nice. > > We can build up to libarithmetic, which hits > the known problem: > ../AMD64_DARWIN/BigIntegerComplexGCD.m3 => ../src/algebra/misc/GCD.mg:118: > warning: anonymous struct declared inside parameter list > > add some more builtin struct sizes for that > multipass is also meant to address that problem cleanly: discovering > all struct sizes and declaring them all early, not just lame hardcoded list > which is both too many and not enough > > (I previously compiled up to a different point -- uplevel locals > declared in sub-blocks; why the difference? I don't know. It is possible > there were other changes and I hadn't tried compiling everything, maybe > only up to cm3. In particular, maybe not the passing of structs correctly > by value (by pointer and then copied into a local)? That is where the error > is here. That is another area where multipass will help a lot..maybe.. > passing/returning structs by value -- letting the C compiler do the work. > The reason we can't return them by value is because m3cg doesn't tell us > the size of a function's return type! We might be able to guess it > from the "_result" variable -- lame...) > > Indeed..I now compile up to: > > == package /Users/jay/dev2/cm3/m3-libs/m3tk-misc == > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "../src/M3C.m3", line 1614 > * > > which is where I got to before -- uplevel local declared > when already in the middle of a function..too late in the current > code for putting it in the frame struct..will fix soon now > that multiple passes are easy. > (in particular -- I haven't invented an M3C-specific IR. > The IR is a faithful storing of the M3CG calls, in memory.) > From jay.krell at cornell.edu Sat Sep 29 20:56:41 2012 From: jay.krell at cornell.edu (Jay K) Date: Sat, 29 Sep 2012 18:56:41 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20120928055822.E93432474003@birch.elegosoft.com>, Message-ID: Maybe. Just to declare the parameters and possibly return typerequires such "buffering" though -- if they include structs,of sizes we haven't seen before. Also, the reordering afforded by multiple passes will letme put module globals first instead of last.Currently otherwise I have to chose between an extra pointerindirection, or generating invalid C++. It is just rather liberating to have this power. It is true that function-at-a-time instead of unit-at-a-timeaffords much of the same power. There are other examples where reordering/buffering/multiple passeswill help but true that function-at-a-time often suffices. For example, I only want to output helper functions that are used. I'll try to come to some decision and proceed.My next step was/is to fix the uplevel-locals-in-nested-blocks problem. - Jay > From: hosking at cs.purdue.edu > Date: Fri, 28 Sep 2012 10:01:47 -0400 > To: jkrell at elego.de > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > Jay, > > I?m not convinced that you need multiple passes if you simply cache state in the Proc structures and then dump it at the end of the procedure. There is no need for you to write to output on every opcode. You can accumulate all you need and then dump at the end. > > ? T > > On Sep 28, 2012, at 7:58 AM, jkrell at elego.de (Jay Krell) wrote: > > > CVSROOT: /usr/cvs > > Changes by: jkrell at birch. 12/09/28 07:58:22 > > > > Modified files: > > cm3/m3-sys/m3back/src/: M3C.i3 M3C.m3 > > ./: M3C.i3 M3C.m3 > > cm3/m3-sys/m3middle/src/: M3CG_MultiPass.i3 M3CG_MultiPass.m3 > > > > Log message: > > "u" => "self" > > "U" => "T" > > > > finish the multipass infrastructure > > including working out the Var/Proc vs. tag/INTEGER stuff > > I kind of wanted to stop trafficing in the pointers and > > only traffic in tag/INTEGER, to save some efficiency, > > but the result isn't all that bad -- it leaves M3C oblivious/unchanged > > > > hookup M3CG to multipass and actually make it multipass > > but don't take any advantate of it yet > > > > Remove commented out code that tried to swap the parameter > > order in except blocks. This was to try to deal with > > the frontend wierdness where it doesn't always pass the exception argument. > > But it didn't work because of indirect calls? > > I also tried K&R as a hack. No go. > > Workaround I went with is to push extra parameter for direct calls. > > Lame all around here. > > > > Result can still upgrade itself, very nice. > > > > We can build up to libarithmetic, which hits > > the known problem: > > ../AMD64_DARWIN/BigIntegerComplexGCD.m3 => ../src/algebra/misc/GCD.mg:118: > > warning: anonymous struct declared inside parameter list > > > > add some more builtin struct sizes for that > > multipass is also meant to address that problem cleanly: discovering > > all struct sizes and declaring them all early, not just lame hardcoded list > > which is both too many and not enough > > > > (I previously compiled up to a different point -- uplevel locals > > declared in sub-blocks; why the difference? I don't know. It is possible > > there were other changes and I hadn't tried compiling everything, maybe > > only up to cm3. In particular, maybe not the passing of structs correctly > > by value (by pointer and then copied into a local)? That is where the error > > is here. That is another area where multipass will help a lot..maybe.. > > passing/returning structs by value -- letting the C compiler do the work. > > The reason we can't return them by value is because m3cg doesn't tell us > > the size of a function's return type! We might be able to guess it > > from the "_result" variable -- lame...) > > > > Indeed..I now compile up to: > > > > == package /Users/jay/dev2/cm3/m3-libs/m3tk-misc == > > > > *** > > *** runtime error: > > *** <*ASSERT*> failed. > > *** file "../src/M3C.m3", line 1614 > > * > > > > which is where I got to before -- uplevel local declared > > when already in the middle of a function..too late in the current > > code for putting it in the frame struct..will fix soon now > > that multiple passes are easy. > > (in particular -- I haven't invented an M3C-specific IR. > > The IR is a faithful storing of the M3CG calls, in memory.) > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkrell at elego.de Sat Sep 29 21:30:18 2012 From: jkrell at elego.de (Jay Krell) Date: Sat, 29 Sep 2012 21:30:18 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120929193018.312B02474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/29 21:30:18 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: cleanup struct size handling to be more efficient no sort -- we can unique through an array of booleans indexed by size Still we have linear + two allocations. C++ would be nlgn and one allocation. Not clear which is better. Linear is good. Allocations are bad. Still the C++/STL way is a good general design that so far eludes me in Modula-3. I compete here by taking advantage of the element type being reasonably ranged integers. If the data was more arbitrary, we couldn't use the array of booleans. Even so -- this is badness e.g. on 32bit host when compiling 64bit code with a large struct size..need to think about this and probably put it back.. we shouldn't be allocating arrays whose size equals the size of user defined data structures..not good... (Modula-3 would be one allocation but I want to be lazy and have the container tell me the size. The C++ STL design might actually be doable in Modula-3, but I don't think m3core provides it. Something to work on, another time.) From jkrell at elego.de Sat Sep 29 21:39:48 2012 From: jkrell at elego.de (Jay Krell) Date: Sat, 29 Sep 2012 21:39:48 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120929193948.AED8C2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/29 21:39:48 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: Go back to using sort to unique. This way code can declare arbitrarily large structs, w/o having compiler allocate arrays that grow with struct sizes. Only arrays that grow with number of ops. (We could do much better and arrays that grow with number of struct sizes. This is a tradeof on my part..because IntSeq isn't easily efficiently sorted..whereas arrays are..because ArraySort isn't general enough..alas..) From jkrell at elego.de Sun Sep 30 08:40:23 2012 From: jkrell at elego.de (Jay Krell) Date: Sun, 30 Sep 2012 8:40:23 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120930064023.74BFB2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/30 08:40:23 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 ./: M3C.m3 cm3/m3-sys/m3middle/src/: M3CG_MultiPass.i3 M3CG_MultiPass.m3 Log message: next application of "multipass" move all imports up to before any functions so now we never need to repeat imports, because they were in the middle of a function "import_repeat" goes away, yeah. In Tony's approach, probably what we would do is not move them up before any function, but move them to just before any function they occur in the middle of. Two partial changes here also. One I ventured into by accident prematurely or incompletely. One I was too lazy to finish today but will come back to. First is that I started processing declare_procedure early, along with its declare_local, declare_temp..and then begin/end_procedure. There is a point to that, to build up frame types earlier, and to push up temps, so that I don't need "extra scopes", so that I can honor begin/end_block. (Here I have eliminated some of the "extra scopes", for imports.) for now I'm just moving up imports, not also declare_procededure/temp/local. Second is that in M3CG_MultiPass, major oops, I failed to fill in the "op" field in many of the records. MultiPass has two usage modes (at least) -- playback via virtual functions (er, OBJECT METHODS), or all the data, and playback of selective ops. The first works. The second depends on ops being set correctly..do only partly works now. There is no question this should be fixed. But it is very tedious (for lack of preprocessor), so I didn't finish it yet. Must do. Experiment: jumble labels. I don't understand the meaning of labels. Like, I understand procs/vars are created by backend, returned to frontend, and then send back to the backend. The correlation is critical. I don't understand labels in this regard. Either the correlation is critical and this messes it up. Or it doesn't matter. If it does matter, then we maybe we working only by accident. I need to do a more focused test here -- be sure to test a case/switch. If it does matter, I need to introduce "translation" in M3CG_MultiPass for labels similar to what I do for vars/procs, so it works deliberately and not by accident (the accident is the various M3CG implementations doling out the same labels, whereas they are free to assign their own "random" values, I think). My suspicion is that it can matter. If you look at how the M3x86 backend actually does work for label allocation. But M3C just uses them to format up names. In which case the internal consistency within the first pass -- M3CG.MultiPass -- I think I understand how that suffices. We'll see...I have to think about this... From jkrell at elego.de Sun Sep 30 08:48:44 2012 From: jkrell at elego.de (Jay Krell) Date: Sun, 30 Sep 2012 8:48:44 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120930064844.D04E22474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/30 08:48:44 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: rename ForwardDeclarations to Imports remove for-now-abandoned reordering of declare_procedure, etc. remove now unused import_repeat From jkrell at elego.de Thu Sep 6 11:11:49 2012 From: jkrell at elego.de (Jay Krell) Date: Thu, 6 Sep 2012 11:11:49 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911211914.9E5DECC85E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/06 11:11:49 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: work in progress -- 4 space indent From jkrell at elego.de Sat Sep 8 11:24:09 2012 From: jkrell at elego.de (Jay Krell) Date: Sat, 8 Sep 2012 11:24:09 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911211914.EC6FFCC85A@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/08 11:24:09 Modified files: cm3/m3-libs/m3core/src/float/: m3makefile Log message: generally assume all targets are IEEE This is overridable. (i.e. Cray, VAX...) generally assume all targets support C99 This is also overridable. (NT still uses IEEE-default) I am assuming C99 is widespread. Like to everything but NT. Including FreeBSD, NetBSD, OpenBSD, Solaris, Darwin, VMS, OSF, Interix, Linux, HPUX, Cygwin, MINGW. This could break folks. It goes like this: For special case targets, fill in _FloatPieces with all the pieces. else: fill in _FloatPiecesNoC99 or _FloatPiecesC99 with "LINUX", "NT", etc. get C99 or IEEE-default get IEEE get IEEE-le or IEEE-be depending on TARGET_ENDIAN, which config files all now set From hosking at elego.de Tue Sep 4 16:52:46 2012 From: hosking at elego.de (Antony Hosking) Date: Tue, 4 Sep 2012 16:52:46 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911211915.42D5ECC85C@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 12/09/04 16:52:46 Modified files: cm3/m3-sys/m3middle/src/: M3CG_Rd.m3 Log message: Best to retain error checking on return values from Convert.ToInt. From jkrell at elego.de Fri Sep 7 14:43:01 2012 From: jkrell at elego.de (Jay Krell) Date: Fri, 7 Sep 2012 14:43:01 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911211915.B793ECC84F@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/07 14:43:01 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: fix declare_global -- completely? hack Cstring__strcpy, strcat From hosking at elego.de Tue Sep 4 16:44:20 2012 From: hosking at elego.de (Antony Hosking) Date: Tue, 4 Sep 2012 16:44:20 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911211917.98EAECC934@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 12/09/04 16:44:20 Modified files: cm3/m3-sys/m3middle/src/: M3CG_BinWr.m3 Log message: Revert for consistency, but retain ChunkSize exposure. From jkrell at elego.de Thu Sep 6 11:05:52 2012 From: jkrell at elego.de (Jay Krell) Date: Thu, 6 Sep 2012 11:05:52 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911211935.57877CC85C@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/06 11:05:52 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: implement case_jump From hosking at elego.de Thu Sep 6 04:03:07 2012 From: hosking at elego.de (Antony Hosking) Date: Thu, 6 Sep 2012 4:03:07 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911211946.A611ACC919@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 12/09/06 04:03:07 Modified files: cm3/m3-sys/m3middle/src/: M3CG.i3 Log message: For Jay, so he can put Int32 in a record... (not sure why, but hey, let's humor him). From jkrell at elego.de Sat Sep 8 11:34:39 2012 From: jkrell at elego.de (Jay Krell) Date: Sat, 8 Sep 2012 11:34:39 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911211946.F1A98CC960@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/08 11:34:39 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: go back to old INTEGER/WORD_T to fix problem with ReportFault, change MAKE_ to M3_ From jkrell at elego.de Sat Sep 8 11:56:13 2012 From: jkrell at elego.de (Jay Krell) Date: Sat, 8 Sep 2012 11:56:13 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911211947.2B033CC90A@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/08 11:56:13 Modified files: cm3/m3-libs/m3core/src/float/Common/: m3makefile Removed files: cm3/m3-libs/m3core/src/float/Common/: FPU.c Log message: ldexp takes an int, not an INTEGER call it and sqrt directly From hosking at elego.de Tue Sep 4 16:43:27 2012 From: hosking at elego.de (Antony Hosking) Date: Tue, 4 Sep 2012 16:43:27 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911211948.CF3BBCC909@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 12/09/04 16:43:27 Modified files: cm3/m3-sys/m3middle/src/: M3Buf.m3 Log message: ChunkSize was exposed elsewhere. I agree with Jay that it may be better to be consistent, but leave the rest as was for efficiency. From hosking at elego.de Tue Sep 4 15:47:04 2012 From: hosking at elego.de (Antony Hosking) Date: Tue, 4 Sep 2012 15:47:04 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911211949.08287CC922@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 12/09/04 15:47:04 Modified files: cm3/m3-sys/m3middle/src/: M3CG.i3 Log message: Revert DAMAGE From hosking at elego.de Thu Sep 6 15:50:48 2012 From: hosking at elego.de (Antony Hosking) Date: Thu, 6 Sep 2012 15:50:48 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911211949.2A584CC85C@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 12/09/06 15:50:48 Modified files: cm3/m3-sys/m3middle/src/: M3CG_Wr.m3 Log message: Need a more principled solution than this. From pmckinna at elego.de Sat Sep 8 03:40:15 2012 From: pmckinna at elego.de (Peter McKinna) Date: Sat, 8 Sep 2012 3:40:15 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911211950.3FB28CC95D@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: pmckinna at birch. 12/09/08 03:40:15 Modified files: cm3/m3-ui/glut/src/: GLUT.i3 GLUT.m3 GLUTRaw.i3 GLUTRaw.m3 m3makefile Log message: Update glut to 2.04 From jkrell at elego.de Sat Sep 8 09:56:50 2012 From: jkrell at elego.de (Jay Krell) Date: Sat, 8 Sep 2012 9:56:50 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911211950.83F52CC97C@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/08 09:56:50 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: pop just one from not instead of two, of course From hosking at elego.de Mon Sep 10 18:14:08 2012 From: hosking at elego.de (Antony Hosking) Date: Mon, 10 Sep 2012 18:14:08 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911211950.58DFBCC96D@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 12/09/10 18:14:08 Modified files: cm3/m3-sys/m3front/src/values/: Formal.m3 Log message: Make sure that we don't treat BITS FOR ARRAY as assignable to VAR formals of type ARRAY OF. From jkrell at elego.de Wed Sep 5 08:42:01 2012 From: jkrell at elego.de (Jay Krell) Date: Wed, 5 Sep 2012 8:42:01 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911211950.85F47CC991@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/05 08:42:01 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: fix some of the C++ problems but really we need to put the globals before all of the code (and cast function pointers to the right type) From jkrell at elego.de Fri Sep 7 13:27:03 2012 From: jkrell at elego.de (Jay Krell) Date: Fri, 7 Sep 2012 13:27:03 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911211950.B25BCCC92D@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/07 13:27:03 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: void => m3_void int => m3_int etc. handle all C and C++ keywords This is needed sooner rather than later. Fix load_float/init_float to: 1.2e3 => 1.2e3F float/REAL 1.2d3 => 1.2e3 double/LONGREAL 1.2x3 => 1.2e3L long double/EXTENDED While at it, add "U" to uint8/16/32 literals and LL/ULL/I64/UI64 to uint64/int64 literals. From jkrell at elego.de Fri Sep 7 15:13:27 2012 From: jkrell at elego.de (Jay Krell) Date: Fri, 7 Sep 2012 15:13:27 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911211952.16428CC925@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/07 15:13:27 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: can compile many files now...work in progress... From jkrell at elego.de Sat Sep 8 11:57:04 2012 From: jkrell at elego.de (Jay Krell) Date: Sat, 8 Sep 2012 11:57:04 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911211951.B0ED7CC935@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/08 11:57:04 Added files: cm3/m3-libs/m3core/src/float/Common/: FPU.i3 Log message: ldexp takes int not INTEGER call it and sqrt directly forgot to add this file a few minutes ago and then editing it now From pmckinna at elego.de Sat Sep 8 03:34:17 2012 From: pmckinna at elego.de (Peter McKinna) Date: Sat, 8 Sep 2012 3:34:17 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911211951.AD273CC92D@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: pmckinna at birch. 12/09/08 03:34:17 Modified files: cm3/m3-ui/glut/swig/: glut.i glutcallback.i glutext.i glutfont.i glutinit.i Log message: Updated glut to swig 2.04 and removed GL dependancy From hosking at elego.de Tue Sep 4 16:47:46 2012 From: hosking at elego.de (Antony Hosking) Date: Tue, 4 Sep 2012 16:47:46 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911211951.07387CC904@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 12/09/04 16:47:46 Modified files: cm3/m3-sys/m3middle/src/: M3CG_Check.m3 Log message: PutErr is not intended to be a method. From jkrell at elego.de Sat Sep 8 10:25:48 2012 From: jkrell at elego.de (Jay Krell) Date: Sat, 8 Sep 2012 10:25:48 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911211952.8A17DCC9BD@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/08 10:25:48 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: 1) put suffixes in integer literals (could be inlined except for 64bit), 2) handle import_global From jkrell at elego.de Thu Sep 6 11:08:04 2012 From: jkrell at elego.de (Jay Krell) Date: Thu, 6 Sep 2012 11:08:04 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911211952.B0C07CC9C7@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/06 11:08:04 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: work in progress -- 4 space indent From jkrell at elego.de Sat Sep 1 10:13:57 2012 From: jkrell at elego.de (Jay Krell) Date: Sat, 1 Sep 2012 10:13:57 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911211952.4D346CC998@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/01 10:13:57 Modified files: cm3/m3-sys/m3middle/src/: M3CG.i3 Log message: remove backing from TypeUID so it can be put in a record on more platforms From hosking at elego.de Tue Sep 4 16:20:48 2012 From: hosking at elego.de (Antony Hosking) Date: Tue, 4 Sep 2012 16:20:48 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911211952.71783CC90C@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 12/09/04 16:20:48 Modified files: cm3/m3-sys/m3middle/src/: M3Buf.m3 Log message: Undo gratuitous damage: 1) ChunkSize is carefully designed to have an alignable size. 2) Comparison order is logical given dependent IF clause. 3) digits arrays are designed for speed to avoid overhead of DIV/MOD when not needed. From hosking at elego.de Tue Sep 4 17:13:51 2012 From: hosking at elego.de (Antony Hosking) Date: Tue, 4 Sep 2012 17:13:51 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911211953.B2FFFCC935@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 12/09/04 17:13:51 Modified files: cm3/m3-sys/m3middle/src/: m3makefile Removed files: cm3/m3-sys/m3middle/src/: TCardinal.i3 TCardinal.m3 Log message: Remove dead TCardinal. Don't build speculative stuff in production (so regressions don't fail). From jkrell at elego.de Fri Sep 7 13:34:29 2012 From: jkrell at elego.de (Jay Krell) Date: Fri, 7 Sep 2012 13:34:29 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911211955.CFCE3CC90D@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/07 13:34:29 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: semicolons after memmove/memcpy From jkrell at elego.de Sun Sep 2 23:08:27 2012 From: jkrell at elego.de (Jay Krell) Date: Sun, 2 Sep 2012 23:08:27 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911211957.8AAC8CC942@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/02 23:08:27 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: work in progress on nested functions and static links, based on M3x86.m3 From jkrell at elego.de Wed Sep 5 07:21:20 2012 From: jkrell at elego.de (Jay Krell) Date: Wed, 5 Sep 2012 7:21:20 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911211958.057ABCC972@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/05 07:21:20 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: and now m3-sys/cm3/src/Makefile.m3 can be compiled to compilable C\! From jkrell at elego.de Sat Sep 8 11:33:11 2012 From: jkrell at elego.de (Jay Krell) Date: Sat, 8 Sep 2012 11:33:11 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911211956.B2CE2CC915@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/08 11:33:11 Modified files: cm3/m3-libs/m3core/src/float/C99/: m3makefile ./: m3makefile cm3/m3-libs/m3core/src/float/Common/: m3makefile ./: m3makefile cm3/m3-libs/m3core/src/float/IEEE-default/: m3makefile Added files: cm3/m3-libs/m3core/src/float/Common/: FPU.c ./: FPU.c Removed files: cm3/m3-libs/m3core/src/float/C99/: FPU.c FPU.i3 ./: FPU.c FPU.i3 cm3/m3-libs/m3core/src/float/IEEE-default/: FPU.i3 FPU.m3 Log message: move FPU.i3, FPU.c to common wrap sqrt in C also From jkrell at elego.de Sat Sep 8 11:24:43 2012 From: jkrell at elego.de (Jay Krell) Date: Sat, 8 Sep 2012 11:24:43 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911211957.4DD41CC935@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/08 11:24:43 Modified files: cm3/m3-libs/m3core/src/float/C99/: FPU.i3 m3makefile Added files: cm3/m3-libs/m3core/src/float/C99/: FPU.c Removed files: cm3/m3-libs/m3core/src/float/C99/: FPU.m3 Log message: implement FPU.scalb via FPU__ldexp, via a C wrapper, as is common now I caught this because the declaration is wrong here, int vs. INTEGER. The C backend causes an interesting interop feature -- we actually get static checking of our redeclarations, if #include is in the C code, or if the compiler knows the function. gcc does let us pass INTEGER to int w/o truncation warning, so do that. Ok? From jkrell at elego.de Wed Sep 5 08:53:20 2012 From: jkrell at elego.de (Jay Krell) Date: Wed, 5 Sep 2012 8:53:20 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911211957.48556CC933@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/05 08:53:20 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: typo in comment From hosking at elego.de Tue Sep 4 16:29:54 2012 From: hosking at elego.de (Antony Hosking) Date: Tue, 4 Sep 2012 16:29:54 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911212000.63428CC84F@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 12/09/04 16:29:54 Modified files: cm3/m3-sys/m3middle/src/: M3CG_BinRd.m3 Log message: Remove <*ASSERT TRUE*> in module block. (?) From jkrell at elego.de Thu Sep 6 11:43:37 2012 From: jkrell at elego.de (Jay Krell) Date: Thu, 6 Sep 2012 11:43:37 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911212003.92DBFCC8E8@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/06 11:43:37 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: void => m3_void (in user identifiers), etc. -- all C reserved words foo => m3_foo, for a list I came up with; so cm3/Utils.m3 compiles From hosking at elego.de Tue Sep 4 17:11:09 2012 From: hosking at elego.de (Antony Hosking) Date: Tue, 4 Sep 2012 17:11:09 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911212003.A5E4FCC84F@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 12/09/04 17:11:09 Modified files: cm3/m3-sys/m3middle/src/: Target.i3 Target.m3 Log message: Remove unnecessary paranoia. CARDINAL is always sufficient to capture alignment, byte size, packing, for builtin (target) types. From jkrell at elego.de Sun Sep 2 23:27:31 2012 From: jkrell at elego.de (Jay Krell) Date: Sun, 2 Sep 2012 23:27:31 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911212004.1DF91CC8E2@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/02 23:27:31 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: work in progress on nested functions and static links, based on M3x86.m3 From jkrell at elego.de Sun Sep 2 10:57:19 2012 From: jkrell at elego.de (Jay Krell) Date: Sun, 2 Sep 2012 10:57:19 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911212006.0BD24CC862@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/02 10:57:19 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: work in progress on nested functions and static links; based on M3x86.m3; not quite right From hosking at elego.de Tue Sep 4 17:20:10 2012 From: hosking at elego.de (Antony Hosking) Date: Tue, 4 Sep 2012 17:20:10 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120911212006.10600CC851@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 12/09/04 17:20:10 Modified files: cm3/m3-sys/m3middle/src/: M3CG_BinWr.m3 Log message: Fix compile error. From jay.krell at cornell.edu Wed Sep 12 01:24:41 2012 From: jay.krell at cornell.edu (Jay K) Date: Tue, 11 Sep 2012 23:24:41 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20120911211952.71783CC90C@birch.elegosoft.com> References: <20120911211952.71783CC90C@birch.elegosoft.com> Message-ID: Fyi, 32bit DIV/MOD by any constant is optimizable by any decent compiler with 64bit operations available. Worst case, they get implemented as 64bit fixed point operations.This works for all 32bit values. The AMD optimization manual prescribes this and includes code for computing reciprocals.For example, division by 10: E:\>type 1.c int div10(int a) { return a / 10; } E:\>cl -Ox -c 1.c Microsoft (R) C/C++ Optimizing Compiler Version 14.00.50727.278 for x64 Copyright (C) Microsoft Corporation. All rights reserved. E:\>link -dump -disasm 1.obj div10: 0000000000000000: B8 67 66 66 66 mov eax,66666667h 0000000000000005: F7 E9 imul ecx 0000000000000007: C1 FA 02 sar edx,2 000000000000000A: 8B C2 mov eax,edx 000000000000000C: C1 E8 1F shr eax,1Fh 000000000000000F: 03 C2 add eax,edx 0000000000000011: C3 ret That's still not free, but it is much cheaper than general division. I should fix M3x86 do to this. :)On the other hand, it makes for larger code. E:\>cl -c 1.c Microsoft (R) C/C++ Optimizing Compiler Version 14.00.50727.278 for x64 Copyright (C) Microsoft Corporation. All rights reserved.1.cE:\>link -dump -disasm 1.obj Microsoft (R) COFF/PE Dumper Version 8.00.50727.278 Copyright (C) Microsoft Corporation. All rights reserved. Dump of file 1.objFile Type: COFF OBJECTdiv10: 0000000000000000: 89 4C 24 08 mov dword ptr [rsp+8],ecx 0000000000000004: 8B 44 24 08 mov eax,dword ptr [rsp+8] 0000000000000008: 99 cdq 0000000000000009: B9 0A 00 00 00 mov ecx,0Ah 000000000000000E: F7 F9 idiv eax,ecx 0000000000000010: C3 ret - Jay > Date: Tue, 4 Sep 2012 16:20:48 +0000 > To: m3commit at elegosoft.com > From: hosking at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: hosking at birch. 12/09/04 16:20:48 > > Modified files: > cm3/m3-sys/m3middle/src/: M3Buf.m3 > > Log message: > Undo gratuitous damage: > > 1) ChunkSize is carefully designed to have an alignable size. > 2) Comparison order is logical given dependent IF clause. > 3) digits arrays are designed for speed to avoid overhead of DIV/MOD when not > needed. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Sep 12 03:01:02 2012 From: jay.krell at cornell.edu (Jay K) Date: Wed, 12 Sep 2012 01:01:02 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20120911211948.CF3BBCC909@birch.elegosoft.com> References: <20120911211948.CF3BBCC909@birch.elegosoft.com> Message-ID: Blech, looking at the change: Generally size optimizations beat speed optimizations. Those lookup tables are wasteful. And tedious to read/write for a human, vs., the clear compact logic I put in.And as I said, division/mod by a constant is efficient, at least on 32bit systems with 64bit operations.Hm. I tried 64bit div and that was still optimized into a multiplication.The code size for that is going to be much smaller than the tables.And the affects on cache probably better too. Generally I find "if (variable relation constant)" easier to read than "if (constant relation variable)". I understand the isomorphisms, but it is still more usual to state the first. 2K is a pretty small buffer size these days. Even 64K that I chose is small. Yes I know I'm arguing both sides of size here. One is code size, the other is buffer size. Integer to text has been implemented countless times. I suspect my way with one table is way more common than your way with three tables. - Jay > Date: Tue, 4 Sep 2012 16:43:27 +0000 > To: m3commit at elegosoft.com > From: hosking at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: hosking at birch. 12/09/04 16:43:27 > > Modified files: > cm3/m3-sys/m3middle/src/: M3Buf.m3 > > Log message: > ChunkSize was exposed elsewhere. I agree with Jay that it may be better to be > consistent, but leave the rest as was for efficiency. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Wed Sep 12 19:18:55 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Wed, 12 Sep 2012 18:18:55 +0100 (BST) Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20120911211957.4DD41CC935@birch.elegosoft.com> Message-ID: <1347470335.11446.YahooMailClassic@web29705.mail.ird.yahoo.com> Hi all: with all due respect this is what I warned about mixing RTs in one compiler, most unsafety of C in Modula-3 is not a good idea, good C ideas are indeed needed, e.g. Fail-Safe C, gcc will have a Fail-safe plugin, if c is what you want to, use it. Jay I know of a way to ask old DEC-SRC Modula-3 -> C compiler, if you want even possibly asking the compiler in C, wouldn't that make the trick for us of compiling in AMD64_NT? We don't need to have the whole world in C to do that, do we? You could recompile itself and make a ready to boot compiler. Thanks in advance --- El s?b, 8/9/12, Jay Krell escribi?: De: Jay Krell Asunto: [M3commit] CVS Update: cm3 Para: m3commit at elegosoft.com Fecha: s?bado, 8 de septiembre, 2012 06:24 CVSROOT:??? /usr/cvs Changes by:??? jkrell at birch.??? 12/09/08 11:24:43 Modified files: ??? cm3/m3-libs/m3core/src/float/C99/: FPU.i3 m3makefile Added files: ??? cm3/m3-libs/m3core/src/float/C99/: FPU.c Removed files: ??? cm3/m3-libs/m3core/src/float/C99/: FPU.m3 Log message: ??? implement FPU.scalb via FPU__ldexp, via a C wrapper, ??? as is common now ??? ??? I caught this because the declaration is wrong here, ??? int vs. INTEGER. The C backend causes an interesting ??? interop feature -- we actually get static checking ??? of our redeclarations, if #include is in the C code, ??? or if the compiler knows the function. ??? ??? gcc does let us pass INTEGER to int w/o truncation warning, ??? so do that. Ok? -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Wed Sep 12 23:37:52 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Wed, 12 Sep 2012 22:37:52 +0100 (BST) Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20120911212000.63428CC84F@birch.elegosoft.com> Message-ID: <1347485872.13135.YahooMailClassic@web29705.mail.ird.yahoo.com> Hi all: RT assumptions must be hold true the same at compile time as at RT, so it's safe if both pragmas ("nested one") and outer one there hold at RT, not just first one case. Thanks in advance --- El mar, 4/9/12, Antony Hosking escribi?: De: Antony Hosking Asunto: [M3commit] CVS Update: cm3 Para: m3commit at elegosoft.com Fecha: martes, 4 de septiembre, 2012 11:29 CVSROOT:??? /usr/cvs Changes by:??? hosking at birch.??? 12/09/04 16:29:54 Modified files: ??? cm3/m3-sys/m3middle/src/: M3CG_BinRd.m3 Log message: ??? Remove <*ASSERT TRUE*> in module block.? (?) -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkrell at elego.de Thu Sep 13 12:09:05 2012 From: jkrell at elego.de (Jay Krell) Date: Thu, 13 Sep 2012 12:09:05 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120913100905.28F5CCC85C@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/13 12:09:05 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: do our own integer to text conversions workaround more bad declarations: ldexp signgam cabs frexp modf jn yn From jkrell at elego.de Fri Sep 14 10:03:59 2012 From: jkrell at elego.de (Jay Krell) Date: Fri, 14 Sep 2012 10:03:59 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120914080359.DA316CC85C@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/14 10:03:59 Modified files: cm3/m3-libs/libm3/src/arith/POSIX/: Math.i3 ./: Math.i3 cm3/m3-libs/libm3/src/arith/WIN32/: Math.i3 Log message: change INTEGER to int for correctness revert old whitespace comment change "may be" to "may be" From jkrell at elego.de Fri Sep 14 10:27:06 2012 From: jkrell at elego.de (Jay Krell) Date: Fri, 14 Sep 2012 10:27:06 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120914082706.4FE23CC85C@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/14 10:27:06 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: Darwin.common Log message: some of the calls to configure_c_compiler seem unnecessary they were added here: http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/cminstall/src/config-no-install/Darwin.common.diff?r1=1.41;r2=1.42 just add comment "why?" and the link should open bugs to revisit.. From jkrell at elego.de Fri Sep 14 11:03:28 2012 From: jkrell at elego.de (Jay Krell) Date: Fri, 14 Sep 2012 11:03:28 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120914090328.45A16CC85E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/14 11:03:28 Modified files: cm3/m3-sys/m3quake/src/: M3Path.m3 Log message: lowercase NONAME.EXE to noname.exe From jkrell at elego.de Fri Sep 14 11:03:58 2012 From: jkrell at elego.de (Jay Krell) Date: Fri, 14 Sep 2012 11:03:58 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120914090358.5CD81CC85C@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/14 11:03:58 Modified files: cm3/m3-sys/m3quake/src/: M3Path.m3 Log message: leave it alone..might be useful on VMS? From jkrell at elego.de Fri Sep 14 14:07:49 2012 From: jkrell at elego.de (Jay Krell) Date: Fri, 14 Sep 2012 14:07:49 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120914120749.D1594CC85A@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/14 14:07:49 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: "rewrite" get_static_link...so it doesn't access violate.. test case is compiling m3core/.../DragonT.m3 for PPC_DARWIN... I'm still not sure I understand this...maybe Tony will look.. From jkrell at elego.de Fri Sep 14 14:23:21 2012 From: jkrell at elego.de (Jay Krell) Date: Fri, 14 Sep 2012 14:23:21 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120914122321.3ACEF2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/14 14:23:21 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: fix RTHooks__ReportFault declaration...yuck... From jkrell at elego.de Fri Sep 14 14:54:36 2012 From: jkrell at elego.de (Jay Krell) Date: Fri, 14 Sep 2012 14:54:36 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120914125436.F07BB2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/14 14:54:36 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: more often declare static link correct...PPC_DARWIN m3core now all compiles..some link problems..looks minor.. From jkrell at elego.de Fri Sep 14 14:57:39 2012 From: jkrell at elego.de (Jay Krell) Date: Fri, 14 Sep 2012 14:57:39 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120914125739.4E4A0CC851@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/14 14:57:39 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: missing underscore in helper function names, and missing abs(float) -- I thought abs was only for integers From jkrell at elego.de Fri Sep 14 14:59:52 2012 From: jkrell at elego.de (Jay Krell) Date: Fri, 14 Sep 2012 14:59:52 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120914125952.E69CDCC851@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/14 14:59:52 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: fix abs(float) From jkrell at elego.de Fri Sep 14 15:01:46 2012 From: jkrell at elego.de (Jay Krell) Date: Fri, 14 Sep 2012 15:01:46 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120914130146.12F6F2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/14 15:01:46 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: add more helpers From jkrell at elego.de Fri Sep 14 15:05:03 2012 From: jkrell at elego.de (Jay Krell) Date: Fri, 14 Sep 2012 15:05:03 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120914130503.6E117CC851@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/14 15:05:03 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: fix signextend name, consider suppressing some imports to fix other problems.. From jkrell at elego.de Fri Sep 14 15:08:57 2012 From: jkrell at elego.de (Jay Krell) Date: Fri, 14 Sep 2012 15:08:57 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120914130857.332A9CC851@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/14 15:08:57 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: in insert_n, insert_mn, extract_n, extract_mn, change 'm' to 'offset', 'n' to 'count' for clarity and I hope correctness add extra required parameter 'count' to sign_extend From jkrell at elego.de Fri Sep 14 15:12:30 2012 From: jkrell at elego.de (Jay Krell) Date: Fri, 14 Sep 2012 15:12:30 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120914131230.444E92474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/14 15:12:30 Modified files: cm3/m3-sys/cm3/src/: Makefile.m3 Log message: remove whitespace from ends of lines From jkrell at elego.de Fri Sep 14 15:31:03 2012 From: jkrell at elego.de (Jay Krell) Date: Fri, 14 Sep 2012 15:31:03 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120914133103.E53782474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/14 15:31:03 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: predeclare struct sizes up to 28 for libm3/Transform.m3 add casts to WORD_T* for set operations include set sizes in set operations (bit counts of byte counts?) From jkrell at elego.de Sun Sep 16 09:44:45 2012 From: jkrell at elego.de (Jay Krell) Date: Sun, 16 Sep 2012 9:44:45 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120917054345.F024FCC862@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/16 09:44:45 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: Unix.common Log message: use -o object in compile_c, so e.g. we can compile foo.m3.c to foo.mo (rather than foo.m3.o..which really isn't a bad idea, but not what the 'builder' is used to..) From jkrell at elego.de Sun Sep 16 10:27:01 2012 From: jkrell at elego.de (Jay Krell) Date: Sun, 16 Sep 2012 10:27:01 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120917054455.3DFFCCC85E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/16 10:27:01 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: PPC_DARWIN Unix.common cm3cfg.common Log message: support: USE_C_BACKEND = TRUE From jkrell at elego.de Sun Sep 16 10:03:48 2012 From: jkrell at elego.de (Jay Krell) Date: Sun, 16 Sep 2012 10:03:48 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120917054746.5237ECC85E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/16 10:03:48 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: Unix.common Log message: previous checkin added -g unconditionally in compile_c; undo that, but add it conditionally on 'debug' -- not clear what is the best option here, -g, -ggdb, -g2, -gstabs, etc. From jkrell at elego.de Sun Sep 16 09:55:58 2012 From: jkrell at elego.de (Jay Krell) Date: Sun, 16 Sep 2012 9:55:58 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120917054749.9A7BCCC862@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/16 09:55:58 Modified files: cm3/m3-sys/m3cgcat/src/: Main.m3 m3makefile Log message: repeated Params.Get(0) => arg0 := Params.Get(0) and use arg0 program => Program, so it gets installed to bin instead of pkg fix warnings i.e. get this into shape to avoid the 'builder' changes since I don't want to wait for them to be approved, just use the existing mode=ExternalObject or even mode=ExternalAssembly support It's not a terrible model, esp. while in development. More files and more processes make for more "entry points" i.e. "easy to debug points". From jkrell at elego.de Sun Sep 16 00:40:10 2012 From: jkrell at elego.de (Jay Krell) Date: Sun, 16 Sep 2012 0:40:10 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120917054904.5EE7ACC84F@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/16 00:40:10 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: some struct reworking -- use the lame non-deal "standard structs", since we don't easily know the size of returned structs Pass structs by pointer, and copy into a local value. (Uplevel structs?) I don't want to do it this way.. C has perfectly good by-value struct parameters and results, and we aren't ABI-compliant this way, if it matters. (need to check the other front ends -- "standard structs" is basically always at high risk of being non-compliant on modern systems, "standard" of course being another name for "usually wrong"! but yes I should know the ABIs better on all systems..) Notice how we cast to void* when passing structs, where otherwise we have no void* casts, always ADDRESS which is char* and we get types more correct in general..but not here.. Need to confirm my observations here..need to get the Builder changes in so Tony maybe can look? (or redo it via config/quake to look like an existing mode.. maybe... I don't like the modes and now I've added another..) avoid #include math.h/string.h -- seems to speed it up still #include stddef.h unfortunately, need to try to fix that need to collect size_t and ptrdiff_t and typedef them ourselves where possible, else fallback to #include stddef.h declare the following ourselves, without #include: ceil, floor, memcpy, memmove, memset This might be a losing battle though. We could either bite the bullet and #include. Or #include if needed (making a second pass over the code). Or provide wrappers in m3core, losing inlining. add more min/max/abs wrappers, e.g. for REAL and EXTENDED (REAL needed, EXTENDED not) tentatively Var => M3CG.Var tentatively Proc => M3CG.Proc tentatively CVar => Var tentatively CProc => Proc compose structs of short/int/INT64, not just char, to try to raise their alignment fix typo internal_declara_param => internal_declare_param ongoing conversion to 4 space indentation change set operations between bit_size and byte_size correct now? fix fatal error in compare where it popped 1 instead of 2 (and then pushed, overall pop 1) this causes an access violation in TextLitInfo because it was writing into readonly memory; horrendous little problem, took a while to track down..need to be careful, the debugging costs are high... From jkrell at elego.de Sun Sep 16 10:17:49 2012 From: jkrell at elego.de (Jay Krell) Date: Sun, 16 Sep 2012 10:17:49 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120917054844.EE9EACC85E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/16 10:17:49 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: PPC_DARWIN Log message: have m3_backend use m3cgcat and compile_c and reuse existing builder mode ExternalObject (2) but this is less efficient than calling M3C directly w/o going through M3CG_BinWr/Rd/m3cgcat Actually switch PPC_DARWIN to C backend. In case anyone else wants to try it, to debug it. It certainly doesn't work yet! Eventually, if we stick with this model (hopefully not), this m3_backend should move to a common place, e.g. BackendC.common or cm3cfg.common triggered by a global boolean BACKEND_GENERATES_C or USE_C_BACKEND.. From jkrell at elego.de Mon Sep 17 13:03:54 2012 From: jkrell at elego.de (Jay Krell) Date: Mon, 17 Sep 2012 13:03:54 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120917110354.10E44CC85A@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/17 13:03:54 Modified files: cm3/m3-libs/m3core/src/runtime/common/: RTLinkerX.i3 Log message: remove extra newline from end of file From jkrell at elego.de Mon Sep 17 13:07:11 2012 From: jkrell at elego.de (Jay Krell) Date: Mon, 17 Sep 2012 13:07:11 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120917110712.03421CC85A@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/17 13:07:11 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: is_const => const const => const_text 4 space indentation (work in progress) add target/wordsize at top of C restore "static" on non-exported globals (important! avoids duplicates and errors) and then most importantly, pad out segments to their declared sizes very important -- to get the zeros at the end instead of garbage this fixes crashing at "startup" (in RTLinker.InitRuntime) ..it still crashes in RTLinker.InitRuntime, but it gets significantly further From jkrell at elego.de Wed Sep 19 06:55:39 2012 From: jkrell at elego.de (Jay Krell) Date: Wed, 19 Sep 2012 6:55:39 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120919045546.5CD402474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/19 06:55:39 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: put line directives in comments (for now) put static_link last instead of first This lets us get much further: RunMainBody: exec: ../src/etimer/ETimer.m3(3) Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x00000004 0x00343511 in ETimer__Push (t=0x16bc1b8 "??B") at ETimer.mc.c:743 743 (*(volatile INT32*)(4+(ADDRESS)*(volatile ADDRESS*)&L_14))=(INT32)(((INT32)(((INT32)(((INT32)(*(volatile INT32*)(4+(ADDRESS)*(volatile ADDRESS*)&L_14)))+((INT32)(((INT32)1)))))))); (gdb) (before at Main(0) we ran the body, which was wrong) print min32 and min64 as -max32 and -max64-1 to fix warning From jkrell at elego.de Thu Sep 20 14:27:23 2012 From: jkrell at elego.de (Jay Krell) Date: Thu, 20 Sep 2012 14:27:23 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120920122723.D4E5E2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/20 14:27:23 Added files: cm3/m3-sys/m3tests/src/c1/c138/: Main.m3 m3makefile Log message: some exception handling tests..surely I need more.. From jkrell at elego.de Thu Sep 20 14:37:10 2012 From: jkrell at elego.de (Jay Krell) Date: Thu, 20 Sep 2012 14:37:10 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120920123710.EDB6B2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/20 14:37:10 Modified files: cm3/m3-sys/m3tests/src/c1/c138/: Main.m3 Log message: augment test some From jkrell at elego.de Thu Sep 20 14:43:40 2012 From: jkrell at elego.de (Jay Krell) Date: Thu, 20 Sep 2012 14:43:40 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120920124340.A35802474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/20 14:43:40 Modified files: cm3/m3-sys/m3tests/src/c1/c138/: Main.m3 Log message: augment..and found a frontend bug? this program fails to link, but should From jkrell at elego.de Thu Sep 20 14:52:28 2012 From: jkrell at elego.de (Jay Krell) Date: Thu, 20 Sep 2012 14:52:28 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120920125228.4E0E52474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/20 14:52:28 Added files: cm3/m3-sys/m3tests/src/c1/c139/: Main.m3 m3makefile Log message: valid program that fails to link with current backend From jkrell at elego.de Thu Sep 20 14:53:40 2012 From: jkrell at elego.de (Jay Krell) Date: Thu, 20 Sep 2012 14:53:40 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120920125340.4B6D72474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/20 14:53:40 Modified files: cm3/m3-sys/m3tests/src/c1/c138/: Main.m3 Log message: augments tests, remove the link failure for now From jkrell at elego.de Thu Sep 20 14:54:39 2012 From: jkrell at elego.de (Jay Krell) Date: Thu, 20 Sep 2012 14:54:39 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120920125439.503952474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/20 14:54:39 Modified files: cm3/m3-sys/m3tests/src/c1/c138/: Main.m3 Log message: renumber From jkrell at elego.de Thu Sep 20 15:16:52 2012 From: jkrell at elego.de (Jay Krell) Date: Thu, 20 Sep 2012 15:16:52 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120920131652.AA7A52474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/20 15:16:52 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: declare/implement finally procs as K&R instead of ANSI since they are not always passed the activation/exception record (I need to write tests to see when they use it, and if never, then just omit it) for nested functions in general, put static_link last, not first, since it is often passed for indirect calls to non-nested functions but for finally procs, put it first, since it is always passed, and the other parameter isn't always passed at all but note, in call_indirect, we put it always last, so that is a bug I think frontend needs to always pass the exception/activation information, even if nil, to fix this. uniquify all local names, for now, since begin/end_block don't provide the scoping they are meant to, because declare/import_procedure comes in at arbitrary times.. fix struct sizes, but it probably wasn't really wrong current state uncertain, but previously, by putting the static link last, I got much much further..lots of code ran, and then assertion failure deep in garbage collector...moving attention maybe to m3-sys/m3tests.. if fixing this finally proc stuff doesn't fix the garbage collector.. From jkrell at elego.de Thu Sep 20 15:21:21 2012 From: jkrell at elego.de (Jay Krell) Date: Thu, 20 Sep 2012 15:21:21 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120920132121.8B5402474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/20 15:21:21 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: add m3_sign_extend_T(INT64) helper From jkrell at elego.de Thu Sep 20 15:23:48 2012 From: jkrell at elego.de (Jay Krell) Date: Thu, 20 Sep 2012 15:23:48 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120920132348.B9E312474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/20 15:23:48 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: Darwin.common Log message: -g works much better than -gstabs+ on Darwin (at least my old version, but really, it isn't surprising, stabs isn't the native symbol type on most systems and -g is what people usually use..)) From jkrell at elego.de Thu Sep 20 15:35:54 2012 From: jkrell at elego.de (Jay Krell) Date: Thu, 20 Sep 2012 15:35:54 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120920133554.E82D82474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/20 15:35:54 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: oops -- use div/mod helpers! fixes test p227 From jkrell at elego.de Thu Sep 20 15:38:51 2012 From: jkrell at elego.de (Jay Krell) Date: Thu, 20 Sep 2012 15:38:51 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120920133851.187E82474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/20 15:38:51 Modified files: cm3/scripts/python/: pylib.py Log message: allow saying buildship more than once -- last action wins From jkrell at elego.de Thu Sep 20 15:46:26 2012 From: jkrell at elego.de (Jay Krell) Date: Thu, 20 Sep 2012 15:46:26 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120920134626.394CB2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/20 15:46:26 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: oops -- div/mod helpers only for signed types From jkrell at elego.de Thu Sep 20 16:00:00 2012 From: jkrell at elego.de (Jay Krell) Date: Thu, 20 Sep 2012 16:00:00 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120920140000.61D3A2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/20 16:00:00 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: oops -- shift by negative value needs to negate the shift count! (see test p227 with -lp flag) From jkrell at elego.de Thu Sep 20 16:07:33 2012 From: jkrell at elego.de (Jay Krell) Date: Thu, 20 Sep 2012 16:07:33 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120920140734.3C3E42474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/20 16:07:33 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: oops -- shift the other direction\! (and reverse the cases for possible micro optimization) From jkrell at elego.de Thu Sep 20 16:37:00 2012 From: jkrell at elego.de (Jay Krell) Date: Thu, 20 Sep 2012 16:37:00 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120920143700.8DA41CC8B8@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/20 16:37:00 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: wow, oops, bit by mixing signed and unsigned\! when range checking INTEGER shift against 8 * sizeof(x) and -(8 * sizeof(x)) -- sizeof is unsigned, all 'negative' values are NOT less than it.. (again, see test p227) From jkrell at elego.de Thu Sep 20 22:52:36 2012 From: jkrell at elego.de (Jay Krell) Date: Thu, 20 Sep 2012 22:52:36 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120920205236.A943FCC8BB@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/20 22:52:36 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: hack, workaround frontend bug? when making direct calls to finally blocks, pass an extra parameter restore consistent order that static_link is always last disable K&R hack for finally blocks keep K&R code..in future I expect K&R will be a global option here NOW CM3 BUILT WITH C BACKEND CAN ITSELF COMPILE M3CORE. This is a huge milestone. The next ones to look at are: compiling all of cm3, m3-sys/m3tests (at least one hits an assertion failure in the compiler), and compiling the entire system, and running some of it (we don't have a good way to test running the entire system) From dabenavidesd at yahoo.es Thu Sep 20 23:12:18 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Thu, 20 Sep 2012 22:12:18 +0100 (BST) Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20120920205236.A943FCC8BB@birch.elegosoft.com> Message-ID: <1348175538.24375.YahooMailClassic@web29702.mail.ird.yahoo.com> Hi all: Who can create a common RT from C and Modula-3, I guess you can but should we create a libc in Modula-3? Like LINUXLIBC6 to be compatible with your linked code (C NT RT and a glibc in one model)? That way we have a true multiplatform, systems programming language. Is this approach what M3 people wanted? DEC-SRC again experimented with it, maybe useful to consider that. Thanks in advance --- El jue, 20/9/12, Jay Krell escribi?: De: Jay Krell Asunto: [M3commit] CVS Update: cm3 Para: m3commit at elegosoft.com Fecha: jueves, 20 de septiembre, 2012 17:52 CVSROOT:??? /usr/cvs Changes by:??? jkrell at birch.??? 12/09/20 22:52:36 Modified files: ??? cm3/m3-sys/m3back/src/: M3C.m3 Log message: ??? hack, workaround frontend bug? ??? ??? when making direct calls to finally blocks, pass an extra ??? parameter ??? ??? restore consistent order that static_link is always last ??? disable K&R hack for finally blocks ??? keep K&R code..in future I expect K&R will be a global option here ??? ??? NOW CM3 BUILT WITH C BACKEND CAN ITSELF COMPILE M3CORE. ??? This is a huge milestone. ??? The next ones to look at are: compiling all of cm3, m3-sys/m3tests ??? (at least one hits an assertion failure in the compiler), and compiling ??? the entire system, and running some of it (we don't have a good way ??? to test running the entire system) -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkrell at elego.de Fri Sep 21 01:18:32 2012 From: jkrell at elego.de (Jay Krell) Date: Fri, 21 Sep 2012 1:18:32 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120920231832.C867B2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/21 01:18:32 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: == package /Users/jay/dev2/cm3/m3-comm/tcp == new source -> compiling StreamWrClass.m3 StreamWrClass.mc.c: In function ???StreamWr__ByteCount???: StreamWrClass.mc.c:312: warning: passing argument 1 of ???StreamWrClass_M3_LINE_43_1??? from incompatible pointer type StreamWrClass.mc.c:312: error: too few arguments to function ???StreamWrClass_M3_LINE_43_1??? Fix this: recognize finally blocks module_line_number_number and not just module_line_number (Imho the backend shouldn't know about any of this stuff, but the frontend is wierd..) From jkrell at elego.de Sat Sep 22 02:31:18 2012 From: jkrell at elego.de (Jay Krell) Date: Sat, 22 Sep 2012 2:31:18 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120924194455.409CDCC90E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/22 02:31:17 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: various remove volatile from loads/stores add volatile to struct fields 4 space indent cleanup casting -- add it in consistently there are no very few uses of "cast" -- they are all in "get" some code sharing -- "unop", "binop" turn on #line directives remove globals start prototyping "symbolic expressions" -- needed I think to fix that we shift by constants greater than size CVar, Var => Var_t (I'm also sympathetic to var_t) avoid comments across line boundaries, so we can add comments in almost arbitrarily for debugging reduce default debug output remove spaces from ends of lines From jkrell at elego.de Sat Sep 22 06:00:57 2012 From: jkrell at elego.de (Jay Krell) Date: Sat, 22 Sep 2012 6:00:57 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120924194455.8BDA7CC926@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/22 06:00:57 Modified files: cm3/m3-sys/m3middle/src/: m3makefile Log message: compile multipass and donothing I don't like these names particularly..suggestions? From jkrell at elego.de Sat Sep 22 02:20:38 2012 From: jkrell at elego.de (Jay Krell) Date: Sat, 22 Sep 2012 2:20:38 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120924194455.BA425CC935@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/22 02:20:37 Modified files: cm3/m3-sys/m3middle/src/: M3CG_MultiPass.i3 M3CG_MultiPass.m3 Log message: significant work in progress on data structures useful to backends -- storing up all the m3cg in memory, to be looped over/played back, in order to get it into the order needed This is a LOT of tedious work. It was SO much easier to do in m3cc via the preprocessor. A macro processor can be incredibly useful. Really. Three or so modes are allowed for (which does increase the tedium). One can loop over the array of refs and use ISTYPE/NARROW/LOOPHOLE. ISTYPE/NARROW would be unnecessarily slow, LOOPHOLE would be fast One can loop pver and switch on a type tag (not all filled in). One can pass in a M3CG and the data will all be passed to its appropriate functions (work in progress). And then pass in a different M3CG, that shares state with the first. Like, "mini" M3CGs that do nothing (inherit from M3CG_DoNothing) but pay attention to only a few functions, like e.g. to accumulate a list of all struct sizes. I will probably use that last option. This will give us the power to fix several things: - support arbitrary struct sizes as parameters - pass and esp. return structs by value letting the C compiler do the work, as well as being ABI compliant (what we haven't isn't a violation per se, for our code, as you can write your C this way; it is a violation for <*extern*> though.) - only declare/implement static helper functions that we use - support uplevel locals in nested blocks -- to enable building the whole system! - forward declare all imports ahead of all functions, and therefore - just once - honor begin/end_block; stop tacking numbers onto identifiers - maybe honor free_temp - generate valid C++ for the module globals (w/o an extra indirection) - possibly use real structs and infer real field accesses - maybe more (there is more to improve, not sure if this stuff needed for it; e.g. move globals out of the "segment" would be nice remove obviously unused functions; fix shifts by greater than size (requires symbolic expressions instead of strings) - much better stock debugging! (due to the structs) ` From jkrell at elego.de Sat Sep 22 02:33:15 2012 From: jkrell at elego.de (Jay Krell) Date: Sat, 22 Sep 2012 2:33:15 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120924194455.958A9CC928@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/22 02:33:15 Modified files: cm3/m3-sys/m3middle/src/: M3CG_DoNothing.i3 Log message: comment only From hosking at elego.de Sun Sep 23 05:33:08 2012 From: hosking at elego.de (Antony Hosking) Date: Sun, 23 Sep 2012 5:33:08 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120924194456.1B45ECC953@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 12/09/23 05:33:08 Added files: cm3/m3-sys/llvm/src/: LLVM.i3 Log message: Modula-3 interface to LLVM C APIs. From jkrell at elego.de Mon Sep 24 22:37:10 2012 From: jkrell at elego.de (Jay Krell) Date: Mon, 24 Sep 2012 22:37:10 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120924203710.DD8F9CC90A@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/24 22:37:10 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: don't discard pop side effects trim the logging code -- can/should use other M3CGs for logging trim commented out code cleanup shift/insert/extract wrt reuse "binop" => "op2" "unop" => "op1" "ADDRESS" => "WORD_T*" in a few places as needed, for sets fix comment in set_intersection/difference/etc. "pop(2)" => "pop(3)" Use IntLiteral instead of IntToDec -- it can make a difference sometimes fix shift/rotate counts to be word or int, not the type of the values (aka some cleanup before the real work) From dabenavidesd at yahoo.es Tue Sep 25 00:22:40 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Mon, 24 Sep 2012 23:22:40 +0100 (BST) Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20120924194455.BA425CC935@birch.elegosoft.com> Message-ID: <1348525360.11590.YahooMailClassic@web29702.mail.ird.yahoo.com> Hi all: if a pre processor is more powerful than the language we are designing is a design mistake or we are not getting the whole picture here, the language code generator is to maintain portability in one way using different code generator for each platform. Other approaches are not recommended for this scenario (but are possible), or if you want why you don't use C Code Generating - Modula-3 compiler (it will make compiler faster?), you can remove the m3cg step and be quicker if you might on that agreeing in that M3CG is minded for light weight fast turn around backend or slow high quality back-end compiler. Why do you think writing high quality compiler is better in C than in Modula-3? Of course C is far better to hack, but if you can write **same** purpose compiler in Modula-3, that's better IMHO. What do you think Jay? See M3CG interface generator speed versus C compiling speed perhaps using a standard complexity test of grammars will tell the truth. I believe that's the idea in M3CG to make the lowest complexity making biggest speed up, I believe the same for C but not for the speed but for space of memory, that was its design goal. SO if you ask about expressive power of the language both are about the same, but for speed and complexity (in grammar terms is an open question: http://event.cwi.nl/pem/2011/2011-02-24-Zaytsev.pdf ) due its different scenario is not fair to compare Thanks in advance --- El vie, 21/9/12, Jay Krell escribi?: De: Jay Krell Asunto: [M3commit] CVS Update: cm3 Para: m3commit at elegosoft.com Fecha: viernes, 21 de septiembre, 2012 21:20 CVSROOT:??? /usr/cvs Changes by:??? jkrell at birch.??? 12/09/22 02:20:37 Modified files: ??? cm3/m3-sys/m3middle/src/: M3CG_MultiPass.i3 M3CG_MultiPass.m3 Log message: ??? significant work in progress on data structures ??? useful to backends -- storing up all the m3cg ??? in memory, to be looped over/played back, in order ??? to get it into the order needed ??? ??? This is a LOT of tedious work. ??? It was SO much easier to do in m3cc via the preprocessor. ??? A macro processor can be incredibly useful. Really. ??? ??? Three or so modes are allowed for (which does increase the tedium). ??? One can loop over the array of refs and use ISTYPE/NARROW/LOOPHOLE. ??? ISTYPE/NARROW would be unnecessarily slow, LOOPHOLE would be fast ??? One can loop pver and switch on a type tag (not all filled in). ??? One can pass in a M3CG and the data will all be passed to ??? its appropriate functions (work in progress). ??? And then pass in a different M3CG, that shares state with the first. ??? Like, "mini" M3CGs that do nothing (inherit from M3CG_DoNothing) ??? but pay attention to only a few functions, like e.g. to accumulate ??? a list of all struct sizes. ??? ??? I will probably use that last option. ??? ??? This will give us the power to fix several things: ??? - support arbitrary struct sizes as parameters ??? - pass and esp. return structs by value letting the C compiler do the work, ??? as well as being ABI compliant (what we haven't isn't a violation per se, ??? for our code, as you can write your C this way; it is a violation for <*extern*> though.) ??? - only declare/implement static helper functions that we use ??? - support uplevel locals in nested blocks -- to enable building the whole system! ??? - forward declare all imports ahead of all functions, and therefore ??? - just once ??? - honor begin/end_block; stop tacking numbers onto identifiers ??? - maybe honor free_temp ??? - generate valid C++ for the module globals (w/o an extra indirection) ??? - possibly use real structs and infer real field accesses ??? - maybe more (there is more to improve, not sure if this stuff ??? needed for it; e.g. move globals out of the "segment" would be nice ??? remove obviously unused functions; fix shifts by greater than size ??? (requires symbolic expressions instead of strings) ??? - much better stock debugging! (due to the structs) ??? ` -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Tue Sep 25 01:38:01 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Tue, 25 Sep 2012 00:38:01 +0100 (BST) Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20120924194455.8BDA7CC926@birch.elegosoft.com> Message-ID: <1348529881.1480.YahooMailClassic@web29704.mail.ird.yahoo.com> Hi all: Jay, what about M3CG_NOps I don't think MultiPass looks very informative, what about M3CG_Proxy Thanks in advance --- El s?b, 22/9/12, Jay Krell escribi?: De: Jay Krell Asunto: [M3commit] CVS Update: cm3 Para: m3commit at elegosoft.com Fecha: s?bado, 22 de septiembre, 2012 01:00 CVSROOT:??? /usr/cvs Changes by:??? jkrell at birch.??? 12/09/22 06:00:57 Modified files: ??? cm3/m3-sys/m3middle/src/: m3makefile Log message: ??? compile multipass and donothing ??? I don't like these names particularly..suggestions? -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at elego.de Tue Sep 25 04:53:07 2012 From: hosking at elego.de (Antony Hosking) Date: Tue, 25 Sep 2012 4:53:07 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120925025307.2DFBACC90E@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 12/09/25 04:53:07 Modified files: cm3/m3-sys/m3middle/src/: M3ID.i3 M3ID.m3 Log message: Allow C code to share M3ID strings. From hosking at elego.de Tue Sep 25 19:07:46 2012 From: hosking at elego.de (Antony Hosking) Date: Tue, 25 Sep 2012 19:07:46 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120925170746.68F1DCC912@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 12/09/25 19:07:46 Modified files: cm3/m3-sys/llvm/src/: LLVM.i3 Log message: Missed some. From jkrell at elego.de Wed Sep 26 09:36:13 2012 From: jkrell at elego.de (Jay Krell) Date: Wed, 26 Sep 2012 9:36:13 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120926073613.D210F2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/26 09:36:13 Modified files: cm3/m3-sys/cm3/src/: Makefile.m3 Log message: cleanup: cnt: INTEGER => got_mode: BOOLEAN It is safer, cleaner, more correct to set bool := TRUE than to INC(int). The integer can wraparound and become FALSE. There is no extra value in it -- we only check for cnt > 0. We don't need the read/modify/write of INC, just the write of assignment to FALSE I don't know why people use this pattern, but I've seen it before. It seems like extra work for no value. From jkrell at elego.de Wed Sep 26 09:39:19 2012 From: jkrell at elego.de (Jay Krell) Date: Wed, 26 Sep 2012 9:39:19 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120926073920.04C2E2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/26 09:39:19 Modified files: cm3/m3-sys/cm3/src/: M3Backend.m3 Log message: cleanup with an eye toward preserving horizontal space From hosking at elego.de Wed Sep 26 19:12:38 2012 From: hosking at elego.de (Antony Hosking) Date: Wed, 26 Sep 2012 19:12:38 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120926171238.1D96BCC916@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 12/09/26 19:12:38 Modified files: cm3/m3-sys/m3front/src/values/: Formal.m3 Log message: Restore fix from 1.14. The loop should check every dimension of the array. From jkrell at elego.de Thu Sep 27 07:29:00 2012 From: jkrell at elego.de (Jay Krell) Date: Thu, 27 Sep 2012 7:29:00 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120927052901.2C2FCCC919@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/27 07:29:00 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: cm3.cfg Log message: fix typo in error message that suggests targets: I386_SOLARS => I386_SOLARIS From jkrell at elego.de Fri Sep 28 07:57:22 2012 From: jkrell at elego.de (Jay Krell) Date: Fri, 28 Sep 2012 7:57:22 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120928055722.52E5CCC92A@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/28 07:57:22 Modified files: cm3/m3-sys/m3middle/src/: M3ID.m3 Log message: fix it to compile From jkrell at elego.de Fri Sep 28 07:58:22 2012 From: jkrell at elego.de (Jay Krell) Date: Fri, 28 Sep 2012 7:58:22 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120928055822.E93432474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/28 07:58:22 Modified files: cm3/m3-sys/m3back/src/: M3C.i3 M3C.m3 ./: M3C.i3 M3C.m3 cm3/m3-sys/m3middle/src/: M3CG_MultiPass.i3 M3CG_MultiPass.m3 Log message: "u" => "self" "U" => "T" finish the multipass infrastructure including working out the Var/Proc vs. tag/INTEGER stuff I kind of wanted to stop trafficing in the pointers and only traffic in tag/INTEGER, to save some efficiency, but the result isn't all that bad -- it leaves M3C oblivious/unchanged hookup M3CG to multipass and actually make it multipass but don't take any advantate of it yet Remove commented out code that tried to swap the parameter order in except blocks. This was to try to deal with the frontend wierdness where it doesn't always pass the exception argument. But it didn't work because of indirect calls? I also tried K&R as a hack. No go. Workaround I went with is to push extra parameter for direct calls. Lame all around here. Result can still upgrade itself, very nice. We can build up to libarithmetic, which hits the known problem: ../AMD64_DARWIN/BigIntegerComplexGCD.m3 => ../src/algebra/misc/GCD.mg:118: warning: anonymous struct declared inside parameter list add some more builtin struct sizes for that multipass is also meant to address that problem cleanly: discovering all struct sizes and declaring them all early, not just lame hardcoded list which is both too many and not enough (I previously compiled up to a different point -- uplevel locals declared in sub-blocks; why the difference? I don't know. It is possible there were other changes and I hadn't tried compiling everything, maybe only up to cm3. In particular, maybe not the passing of structs correctly by value (by pointer and then copied into a local)? That is where the error is here. That is another area where multipass will help a lot..maybe.. passing/returning structs by value -- letting the C compiler do the work. The reason we can't return them by value is because m3cg doesn't tell us the size of a function's return type! We might be able to guess it from the "_result" variable -- lame...) Indeed..I now compile up to: == package /Users/jay/dev2/cm3/m3-libs/m3tk-misc == *** *** runtime error: *** <*ASSERT*> failed. *** file "../src/M3C.m3", line 1614 * which is where I got to before -- uplevel local declared when already in the middle of a function..too late in the current code for putting it in the frame struct..will fix soon now that multiple passes are easy. (in particular -- I haven't invented an M3C-specific IR. The IR is a faithful storing of the M3CG calls, in memory.) From jkrell at elego.de Fri Sep 28 12:50:15 2012 From: jkrell at elego.de (Jay Krell) Date: Fri, 28 Sep 2012 12:50:15 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120928105015.BF8D8CC92D@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/28 12:50:15 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 ./: M3C.m3 cm3/m3-sys/m3middle/src/: M3CG_DoNothing.i3 M3CG_DoNothing.m3 M3CG_MultiPass.i3 M3CG_MultiPass.m3 m3makefile Log message: first use of multipass: make an extra pass to discover all struct sizes, so all structs can be predeclared, and no extra (eventually to be replaced by better typing, but this is useful in the current context) Also, to ensure M3C.T implements all METHODS of M3CG_Ops.Public, derive it from M3CG_AssertFalse.T instead of the bogus M3CG.T. M3CG_MultiPass: in end_unit, flatten into plain public array instead of slower sequence separate out per-op also, since sometims that provides for optimization From jkrell at elego.de Fri Sep 28 13:00:14 2012 From: jkrell at elego.de (Jay Krell) Date: Fri, 28 Sep 2012 13:00:14 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120928110014.7E8F3CC92D@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/28 13:00:14 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: remove RTIO, add comments From jkrell at elego.de Fri Sep 28 13:05:04 2012 From: jkrell at elego.de (Jay Krell) Date: Fri, 28 Sep 2012 13:05:04 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120928110504.622EBCC92D@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/28 13:05:04 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: fix brand style From hosking at cs.purdue.edu Fri Sep 28 16:01:47 2012 From: hosking at cs.purdue.edu (Antony Hosking) Date: Fri, 28 Sep 2012 10:01:47 -0400 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20120928055822.E93432474003@birch.elegosoft.com> References: <20120928055822.E93432474003@birch.elegosoft.com> Message-ID: Jay, I?m not convinced that you need multiple passes if you simply cache state in the Proc structures and then dump it at the end of the procedure. There is no need for you to write to output on every opcode. You can accumulate all you need and then dump at the end. ? T On Sep 28, 2012, at 7:58 AM, jkrell at elego.de (Jay Krell) wrote: > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 12/09/28 07:58:22 > > Modified files: > cm3/m3-sys/m3back/src/: M3C.i3 M3C.m3 > ./: M3C.i3 M3C.m3 > cm3/m3-sys/m3middle/src/: M3CG_MultiPass.i3 M3CG_MultiPass.m3 > > Log message: > "u" => "self" > "U" => "T" > > finish the multipass infrastructure > including working out the Var/Proc vs. tag/INTEGER stuff > I kind of wanted to stop trafficing in the pointers and > only traffic in tag/INTEGER, to save some efficiency, > but the result isn't all that bad -- it leaves M3C oblivious/unchanged > > hookup M3CG to multipass and actually make it multipass > but don't take any advantate of it yet > > Remove commented out code that tried to swap the parameter > order in except blocks. This was to try to deal with > the frontend wierdness where it doesn't always pass the exception argument. > But it didn't work because of indirect calls? > I also tried K&R as a hack. No go. > Workaround I went with is to push extra parameter for direct calls. > Lame all around here. > > Result can still upgrade itself, very nice. > > We can build up to libarithmetic, which hits > the known problem: > ../AMD64_DARWIN/BigIntegerComplexGCD.m3 => ../src/algebra/misc/GCD.mg:118: > warning: anonymous struct declared inside parameter list > > add some more builtin struct sizes for that > multipass is also meant to address that problem cleanly: discovering > all struct sizes and declaring them all early, not just lame hardcoded list > which is both too many and not enough > > (I previously compiled up to a different point -- uplevel locals > declared in sub-blocks; why the difference? I don't know. It is possible > there were other changes and I hadn't tried compiling everything, maybe > only up to cm3. In particular, maybe not the passing of structs correctly > by value (by pointer and then copied into a local)? That is where the error > is here. That is another area where multipass will help a lot..maybe.. > passing/returning structs by value -- letting the C compiler do the work. > The reason we can't return them by value is because m3cg doesn't tell us > the size of a function's return type! We might be able to guess it > from the "_result" variable -- lame...) > > Indeed..I now compile up to: > > == package /Users/jay/dev2/cm3/m3-libs/m3tk-misc == > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "../src/M3C.m3", line 1614 > * > > which is where I got to before -- uplevel local declared > when already in the middle of a function..too late in the current > code for putting it in the frame struct..will fix soon now > that multiple passes are easy. > (in particular -- I haven't invented an M3C-specific IR. > The IR is a faithful storing of the M3CG calls, in memory.) > From jay.krell at cornell.edu Sat Sep 29 20:56:41 2012 From: jay.krell at cornell.edu (Jay K) Date: Sat, 29 Sep 2012 18:56:41 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20120928055822.E93432474003@birch.elegosoft.com>, Message-ID: Maybe. Just to declare the parameters and possibly return typerequires such "buffering" though -- if they include structs,of sizes we haven't seen before. Also, the reordering afforded by multiple passes will letme put module globals first instead of last.Currently otherwise I have to chose between an extra pointerindirection, or generating invalid C++. It is just rather liberating to have this power. It is true that function-at-a-time instead of unit-at-a-timeaffords much of the same power. There are other examples where reordering/buffering/multiple passeswill help but true that function-at-a-time often suffices. For example, I only want to output helper functions that are used. I'll try to come to some decision and proceed.My next step was/is to fix the uplevel-locals-in-nested-blocks problem. - Jay > From: hosking at cs.purdue.edu > Date: Fri, 28 Sep 2012 10:01:47 -0400 > To: jkrell at elego.de > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > Jay, > > I?m not convinced that you need multiple passes if you simply cache state in the Proc structures and then dump it at the end of the procedure. There is no need for you to write to output on every opcode. You can accumulate all you need and then dump at the end. > > ? T > > On Sep 28, 2012, at 7:58 AM, jkrell at elego.de (Jay Krell) wrote: > > > CVSROOT: /usr/cvs > > Changes by: jkrell at birch. 12/09/28 07:58:22 > > > > Modified files: > > cm3/m3-sys/m3back/src/: M3C.i3 M3C.m3 > > ./: M3C.i3 M3C.m3 > > cm3/m3-sys/m3middle/src/: M3CG_MultiPass.i3 M3CG_MultiPass.m3 > > > > Log message: > > "u" => "self" > > "U" => "T" > > > > finish the multipass infrastructure > > including working out the Var/Proc vs. tag/INTEGER stuff > > I kind of wanted to stop trafficing in the pointers and > > only traffic in tag/INTEGER, to save some efficiency, > > but the result isn't all that bad -- it leaves M3C oblivious/unchanged > > > > hookup M3CG to multipass and actually make it multipass > > but don't take any advantate of it yet > > > > Remove commented out code that tried to swap the parameter > > order in except blocks. This was to try to deal with > > the frontend wierdness where it doesn't always pass the exception argument. > > But it didn't work because of indirect calls? > > I also tried K&R as a hack. No go. > > Workaround I went with is to push extra parameter for direct calls. > > Lame all around here. > > > > Result can still upgrade itself, very nice. > > > > We can build up to libarithmetic, which hits > > the known problem: > > ../AMD64_DARWIN/BigIntegerComplexGCD.m3 => ../src/algebra/misc/GCD.mg:118: > > warning: anonymous struct declared inside parameter list > > > > add some more builtin struct sizes for that > > multipass is also meant to address that problem cleanly: discovering > > all struct sizes and declaring them all early, not just lame hardcoded list > > which is both too many and not enough > > > > (I previously compiled up to a different point -- uplevel locals > > declared in sub-blocks; why the difference? I don't know. It is possible > > there were other changes and I hadn't tried compiling everything, maybe > > only up to cm3. In particular, maybe not the passing of structs correctly > > by value (by pointer and then copied into a local)? That is where the error > > is here. That is another area where multipass will help a lot..maybe.. > > passing/returning structs by value -- letting the C compiler do the work. > > The reason we can't return them by value is because m3cg doesn't tell us > > the size of a function's return type! We might be able to guess it > > from the "_result" variable -- lame...) > > > > Indeed..I now compile up to: > > > > == package /Users/jay/dev2/cm3/m3-libs/m3tk-misc == > > > > *** > > *** runtime error: > > *** <*ASSERT*> failed. > > *** file "../src/M3C.m3", line 1614 > > * > > > > which is where I got to before -- uplevel local declared > > when already in the middle of a function..too late in the current > > code for putting it in the frame struct..will fix soon now > > that multiple passes are easy. > > (in particular -- I haven't invented an M3C-specific IR. > > The IR is a faithful storing of the M3CG calls, in memory.) > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkrell at elego.de Sat Sep 29 21:30:18 2012 From: jkrell at elego.de (Jay Krell) Date: Sat, 29 Sep 2012 21:30:18 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120929193018.312B02474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/29 21:30:18 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: cleanup struct size handling to be more efficient no sort -- we can unique through an array of booleans indexed by size Still we have linear + two allocations. C++ would be nlgn and one allocation. Not clear which is better. Linear is good. Allocations are bad. Still the C++/STL way is a good general design that so far eludes me in Modula-3. I compete here by taking advantage of the element type being reasonably ranged integers. If the data was more arbitrary, we couldn't use the array of booleans. Even so -- this is badness e.g. on 32bit host when compiling 64bit code with a large struct size..need to think about this and probably put it back.. we shouldn't be allocating arrays whose size equals the size of user defined data structures..not good... (Modula-3 would be one allocation but I want to be lazy and have the container tell me the size. The C++ STL design might actually be doable in Modula-3, but I don't think m3core provides it. Something to work on, another time.) From jkrell at elego.de Sat Sep 29 21:39:48 2012 From: jkrell at elego.de (Jay Krell) Date: Sat, 29 Sep 2012 21:39:48 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120929193948.AED8C2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/29 21:39:48 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: Go back to using sort to unique. This way code can declare arbitrarily large structs, w/o having compiler allocate arrays that grow with struct sizes. Only arrays that grow with number of ops. (We could do much better and arrays that grow with number of struct sizes. This is a tradeof on my part..because IntSeq isn't easily efficiently sorted..whereas arrays are..because ArraySort isn't general enough..alas..) From jkrell at elego.de Sun Sep 30 08:40:23 2012 From: jkrell at elego.de (Jay Krell) Date: Sun, 30 Sep 2012 8:40:23 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120930064023.74BFB2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/30 08:40:23 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 ./: M3C.m3 cm3/m3-sys/m3middle/src/: M3CG_MultiPass.i3 M3CG_MultiPass.m3 Log message: next application of "multipass" move all imports up to before any functions so now we never need to repeat imports, because they were in the middle of a function "import_repeat" goes away, yeah. In Tony's approach, probably what we would do is not move them up before any function, but move them to just before any function they occur in the middle of. Two partial changes here also. One I ventured into by accident prematurely or incompletely. One I was too lazy to finish today but will come back to. First is that I started processing declare_procedure early, along with its declare_local, declare_temp..and then begin/end_procedure. There is a point to that, to build up frame types earlier, and to push up temps, so that I don't need "extra scopes", so that I can honor begin/end_block. (Here I have eliminated some of the "extra scopes", for imports.) for now I'm just moving up imports, not also declare_procededure/temp/local. Second is that in M3CG_MultiPass, major oops, I failed to fill in the "op" field in many of the records. MultiPass has two usage modes (at least) -- playback via virtual functions (er, OBJECT METHODS), or all the data, and playback of selective ops. The first works. The second depends on ops being set correctly..do only partly works now. There is no question this should be fixed. But it is very tedious (for lack of preprocessor), so I didn't finish it yet. Must do. Experiment: jumble labels. I don't understand the meaning of labels. Like, I understand procs/vars are created by backend, returned to frontend, and then send back to the backend. The correlation is critical. I don't understand labels in this regard. Either the correlation is critical and this messes it up. Or it doesn't matter. If it does matter, then we maybe we working only by accident. I need to do a more focused test here -- be sure to test a case/switch. If it does matter, I need to introduce "translation" in M3CG_MultiPass for labels similar to what I do for vars/procs, so it works deliberately and not by accident (the accident is the various M3CG implementations doling out the same labels, whereas they are free to assign their own "random" values, I think). My suspicion is that it can matter. If you look at how the M3x86 backend actually does work for label allocation. But M3C just uses them to format up names. In which case the internal consistency within the first pass -- M3CG.MultiPass -- I think I understand how that suffices. We'll see...I have to think about this... From jkrell at elego.de Sun Sep 30 08:48:44 2012 From: jkrell at elego.de (Jay Krell) Date: Sun, 30 Sep 2012 8:48:44 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20120930064844.D04E22474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 12/09/30 08:48:44 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: rename ForwardDeclarations to Imports remove for-now-abandoned reordering of declare_procedure, etc. remove now unused import_repeat