From jkrell at elego.de Fri Oct 1 12:58:36 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 1 Oct 2010 12:58:36 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101001105836.E7FF6CC125@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/01 12:58:36 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: Eliminate INTEGER vs. TARGET_INTEGER distinction. INTEGER is HOST_WIDE_INT which is at least 64bits when targeting 64bit. Equivalent to using LONGINT more instead of INTEGER. Typical 32bit C compilers have had 64bit long long/__int64 for something like 20 years now I think. (ok, at least 15, for certain) From jkrell at elego.de Fri Oct 1 13:03:46 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 1 Oct 2010 13:03:46 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101001110346.82CCBCC125@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/01 13:03:46 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: odd, go back a version From jkrell at elego.de Sat Oct 2 11:48:20 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 2 Oct 2010 11:48:20 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101002094820.BCA7C2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/02 11:48:20 Modified files: cm3/m3-sys/m3cc/gcc-4.5/gcc/: fixed-value.c Log message: gut file hardly used for Modula-3 backend, or I believe in most use of C backend as well From jkrell at elego.de Sat Oct 2 11:53:34 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 2 Oct 2010 11:53:34 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101002095334.A1BA42474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/02 11:53:34 Modified files: cm3/m3-sys/m3cc/gcc/gcc/: config.gcc config.in configure configure.ac hwint.h cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c cm3/m3-sys/m3cc/gcc-4.5/gcc/: config.gcc config.in configure configure.ac hwint.h cm3/m3-sys/m3cc/gcc-apple/gcc/: config.gcc config.in configure configure.ac hwint.h cm3/m3-sys/m3cc/src/: clean_marker.txt m3makefile Log message: small cleanup in target integer reading make sure HOST_WIDE_INT is always at least 64bits which was already the case on most targets anyway due to "biarch", the fact that x86 backends can target AMD64 with -m64 From jkrell at elego.de Sat Oct 2 12:36:50 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 2 Oct 2010 12:36:50 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101002103651.11B132474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/02 12:36:50 Modified files: cm3/m3-sys/m3cc/gcc-4.5/libiberty/: pex-common.h cm3/m3-sys/m3cc/gcc/libiberty/: pex-common.h Log message: #include for pid_t, for VMS see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44002 From jkrell at elego.de Sat Oct 2 12:39:20 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 2 Oct 2010 12:39:20 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101002103920.BCE322474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/02 12:39:20 Modified files: cm3/m3-sys/m3cc/gcc-apple/gcc/ginclude/: stddef.h cm3/m3-sys/m3cc/gcc/gcc/ginclude/: stddef.h Log message: Don't trash __size_t, on VMS. Already applied to 4.5. See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44003 From jkrell at elego.de Sat Oct 2 13:20:07 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 2 Oct 2010 13:20:07 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101002112007.5936E2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/02 13:20:07 Modified files: cm3/m3-sys/m3cc/gcc-4.5/gcc/: c-common.c cm3/m3-sys/m3cc/gcc-apple/gcc/: c-common.c cm3/m3-sys/m3cc/gcc/gcc/: c-common.c Log message: workaround ffs problem on VMS see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44037 From jkrell at elego.de Sat Oct 2 13:36:31 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 2 Oct 2010 13:36:31 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101002113631.3E8B42474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/02 13:36:31 Modified files: cm3/m3-sys/m3cc/gcc-4.5/gcc/: config.gcc cm3/m3-sys/m3cc/gcc-4.5/gcc/config/vms/: t-vms Added files: cm3/m3-sys/m3cc/gcc-4.5/gcc/config/vms/: vms-ucrt0.c Removed files: cm3/m3-sys/m3cc/gcc-4.5/gcc/config/vms/: t-vms64 vms-crt0-64.c vms-crt0.c vms-psxcrt0-64.c vms-psxcrt0.c Log message: VMS fixes from trunk see http://gcc.gnu.org/viewcvs/trunk/gcc/config/vms/t-vms?revision=164587&view=markup (i.e. for building C compiler here) From jkrell at elego.de Sat Oct 2 14:16:50 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 2 Oct 2010 14:16:50 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101002121650.897E42474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/02 14:16:50 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: again eliminate INTEGER vs. TARGET_INTEGER distinction INTEGER always suffices, TARGET_INTEGER is no more callers can call build_int_cst if they need a tree, as many but not all do 64bits is always enough I think the problem in previous attempt was the cast to long in get_int () where HOST_WIDE_INT is needed (32bits vs. 64bits) eliminate a little bit of 64bit math on 32bit hosts Though overall we overuse 64bit math on purpose. eliminate a little unnecessary signed math unsigned is generally preferred m3cg sign parameter is never used, in div/mod, adjust code accordingly (They used to be used to optimize our unusual div/mod operations, but now we always optimize; hm..could probably do better though, using the signs -- if both positive or both negative, use truncation, which is more commonly what the processors do?) eliminate some temporaries unoptimized code probably affected accordingly positively From jkrell at elego.de Sat Oct 2 15:17:30 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 2 Oct 2010 15:17:30 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101002131731.13D6A2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/02 15:17:30 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: tipe => type tipe is a Modula-3-ism, where "TYPE" is a reserved word? type is not a reserved word in C or C++ From jkrell at elego.de Sat Oct 2 15:21:28 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 2 Oct 2010 15:21:28 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101002132128.D65D62474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/02 15:21:28 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: t => type s => size a => align #if 0 unused function (avoid warning) #define foo bar when foo is just a function that calls bar From jkrell at elego.de Sat Oct 2 15:21:51 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 2 Oct 2010 15:21:51 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101002132151.DCAAE2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/02 15:21:51 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: a => align From jkrell at elego.de Sat Oct 2 15:37:04 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 2 Oct 2010 15:37:04 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101002133704.5BC832474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/02 15:37:04 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: rename variables whose name is just a single lowercase l to avoid ambiguity with the number 1 l => label l => length l => m (as in a, b, c, d, ..., j, k, m) From jkrell at elego.de Sun Oct 3 07:16:19 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 3 Oct 2010 7:16:19 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101003051620.010AD2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/03 07:16:19 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: 1 => true 0 => false or NULL but still intialize with the nice generic form { 0 } From jkrell at elego.de Sun Oct 3 07:17:13 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 3 Oct 2010 7:17:13 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101003051713.B9B822474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/03 07:17:13 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: go ahead and just always use 64bit math in get_int From jkrell at elego.de Sun Oct 3 07:18:20 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 3 Oct 2010 7:18:20 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101003051820.908BB2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/03 07:18:20 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: two missing spaces after function calls (formating) From jkrell at elego.de Sun Oct 3 07:21:24 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 3 Oct 2010 7:21:24 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101003052124.F1D892474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/03 07:21:24 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: no point to: #define NAME STRING just use STRING everywhere From jkrell at elego.de Sun Oct 3 08:38:34 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 3 Oct 2010 8:38:34 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101003063834.369152474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/03 08:38:34 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: enable debugging of enums, in stock gdb start code for debugging of globals, which are always embedded in global structs debugging of structs has the indirection off wrong, for example: t.r1 := 2; t.r2 := 3; t.r3 := 10; (gdb) p *t $4 = (struct Main.T1 *) 0xa32 oops. To be fixed shortly. There are probably many cases that don't debug correctly, because typenames, subranges, and esp. packing probably aren't handled correctly. The code is careful given an untyped integer, not to assign it a type of a different types. That is, when the frontend gives us: TYPE typecode = BITS 20 FOR [...] VAR tc:typecode; and it tells backend tc is a word32 of type typecode, we ignore the stronger type and just say it is word32. Not doing that was caused me a lot of grief/debugging/staring at code. Since this is a subrange and not an enum anyway, not clear we should do anything different. Subranges aren't really types, unless, e.g. you wanted the backend to generate the range checks (which isn't crazy, as it could optimize away redundant checks). As well, what does it mean: TYPE Color={Red,Blue}; TYPE T1 = BITS 2 FOR Color; TYPE T2 = BITS 8 FOR Color; TYPE T3 = BITS 800 FOR Color; Currently enum names are probably wrong, they show as Red, Blue in this example, probably should be Interface.Color.Red. same some pointer overhead in backend 0 => NULL a bit more add function m3_make_integer_type for maybe future use, that can create integers of any number of bits from 1 to 64 remove some more signed math From jkrell at elego.de Sun Oct 3 08:40:02 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 3 Oct 2010 8:40:02 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101003064002.3AEF72474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/03 08:40:02 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: remove growable and fixed size type table, just use VEC version From jkrell at elego.de Sun Oct 3 09:32:44 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 3 Oct 2010 9:32:44 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101003073244.AE4222474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/03 09:32:44 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: m3gty43.h m3gty45.h parse.c Log message: t => type id => typeid MTYPE2 => MTYPE where adequate From jkrell at elego.de Sun Oct 3 09:38:02 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 3 Oct 2010 9:38:02 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101003073802.D04B02474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/03 09:38:02 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: more manual tracing cleanup, not much manual tracing left now From jkrell at elego.de Sun Oct 3 10:00:48 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 3 Oct 2010 10:00:48 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101003080048.4D8AF2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/03 10:00:48 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: Darwin.common Log message: default to -g on Darwin, since there is no m3gdb to consume -gstabs From jkrell at elego.de Sun Oct 3 14:20:03 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 3 Oct 2010 14:20:03 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101003122003.B94562474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/03 14:20:03 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: read entire file into memory Even if the file is large, they usually aren't, our access pattern is linear, so virtual memory suffices. This can help with some possible simplifications and speedups, including the next item, which ends up separting the buffer from any file. To deal with circular types, which inhibit us from building good type information in one pass, introduce a mechanism where an opcode can request that it be "replayed"; still, some amount of type information must be created to make forward progress; this is not fully fleshed out yet; what we need to do be sure to create The node that will represent the types, even if we don't fill in its details until later; and then, later, retrieve the node, and fill in more. That is, during "replay", we must not create brand new nodes. e.g. records could be initially empty, then define all the types of their constituent fields, including perhaps pointers to the record itself, and then go back and fill in the fields In general, due to circularities, there is not an ordering that can work in one pass. There are multiple examples in the tree where the declarations come in in a non-working order (possibly there not being a working order). sortedtableextras, for example. To this end, of the "replay" feature, generally move "M3_TYPES" code ahead of the m3gdb code, to avoid the m3gdb code running twice, since I don't know if that will work. The m3gdb code will be deferred until the M3_TYPES code has enough information to complete. disable all type code for now put back all volatile because something is amiss neither of these edits are meant to last remove the mechanism for altering return types That which I recently cleaned up to stop widening return types. put in the missing builtin WIDECHAR Should this be in RTBuiltin.m3x? Put in UID_NULL as well. These last two get us somewhat more complete typeinfo, but there are still circularities we don't likely handle correctly yet. (Not to mention not handling the various array types correctly.) Use VOID_TYPE_P instead of comparison to t_void. Probably no difference in Modula-3, but we were already inconsistent. Make line number unsigned. From jay.krell at cornell.edu Sun Oct 3 14:39:01 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 3 Oct 2010 12:39:01 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20101003122003.B94562474003@birch.elegosoft.com> References: <20101003122003.B94562474003@birch.elegosoft.com> Message-ID: The problem was I declaring subranges to have the same type as their domain. Which would often make them too large. Which broke the sizes of fields. This should be better shortly. ?- Jay ---------------------------------------- > Date: Sun, 3 Oct 2010 14:20:03 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/10/03 14:20:03 > > Modified files: > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > Log message: > read entire file into memory > Even if the file is large, they usually aren't, > our access pattern is linear, so virtual memory suffices. > This can help with some possible simplifications and speedups, > including the next item, which ends up separting the > buffer from any file. > > To deal with circular types, which inhibit > us from building good type information in one pass, > introduce a mechanism where an opcode can request that it > be "replayed"; still, some amount of type information > must be created to make forward progress; this is not > fully fleshed out yet; what we need to do be sure to > create The node that will represent the types, even > if we don't fill in its details until later; and then, later, > retrieve the node, and fill in more. That is, during "replay", > we must not create brand new nodes. > > e.g. records could be initially empty, then define all the > types of their constituent fields, including perhaps pointers > to the record itself, and then go back and fill in the fields > In general, due to circularities, there is not an ordering > that can work in one pass. > > There are multiple examples in the tree where the declarations > come in in a non-working order (possibly there not being > a working order). sortedtableextras, for example. > > To this end, of the "replay" feature, generally move "M3_TYPES" code > ahead of the m3gdb code, to avoid the m3gdb code running twice, > since I don't know if that will work. > The m3gdb code will be deferred until the M3_TYPES code has enough > information to complete. > > disable all type code for now > put back all volatile > because something is amiss > neither of these edits are meant to last > > remove the mechanism for altering return types > That which I recently cleaned up to stop widening > return types. > > put in the missing builtin WIDECHAR > Should this be in RTBuiltin.m3x? > > Put in UID_NULL as well. > > These last two get us somewhat more complete typeinfo, > but there are still circularities we don't likely handle correctly yet. > (Not to mention not handling the various array types correctly.) > > Use VOID_TYPE_P instead of comparison to t_void. > Probably no difference in Modula-3, but we were already inconsistent. > > Make line number unsigned. > From jkrell at elego.de Sun Oct 3 20:28:48 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 3 Oct 2010 20:28:48 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101003182848.37BC52474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/03 20:28:48 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: fix subranges, to be small in size restore not volatile turn back on type code make it easy to turn on/off replay; turn it on remove assert that subrange min <= max, as it breaks X some small tweaks combine code for declare_pointer and declare_indirect consider using stabilize_reference more (after every indirect_ref remove temporaries from: shift rotate check_nil check_lo check_hi check_range check_eq very few temporaries remain: ones the frontend asks for (indefinite) floating point (round, floor, ceiling) loophole sometimes, pop_static_link, compare_exchange From jkrell at elego.de Mon Oct 4 01:21:44 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 4 Oct 2010 1:21:44 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101003232144.C9D6A2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/04 01:21:44 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: sprinkle stabilize_reference eveywhere it will likely save some recompution and is otherwise often a no-op From jkrell at elego.de Mon Oct 4 01:23:33 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 4 Oct 2010 1:23:33 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101003232333.4B8532474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/04 01:23:33 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: turn off the tracing about forward type references From jkrell at elego.de Mon Oct 4 01:29:51 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 4 Oct 2010 1:29:51 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101003232951.B60982474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/04 01:29:51 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: limit replay passes to 100 instead of hanging; in practise 1 seems to suffice, and they go very fast so 100 won't be a long lag (I know because an earlier version went forever, looking for end_unit to repeat) From jkrell at elego.de Mon Oct 4 11:59:56 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 4 Oct 2010 11:59:56 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101004095956.ACF542474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/04 11:59:56 Modified files: cm3/m3-libs/m3core/src/text/: TextLiteral.i3 Log message: allow larger TEXTs, breaking 32 to 64 bit cross builds, as they always were (frontend needs to be fixed to either use LONGINT or Target.Int, to enable the level of cross building that is normal in C and C++!) From jkrell at elego.de Mon Oct 4 20:56:04 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 4 Oct 2010 20:56:04 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101004185604.87F532474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/04 20:56:04 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: take advantage of the entire file being in memory and for strings, use a direct pointer into the buffer instead of copying byte by byte into alloca'ed buffer (which I think was malloced until recently) (note that access is no longer linear, if these strings are used much, they will bring into working set nearby unused data) and then the attendant reduction/elimination of nul terminated strings From jkrell at elego.de Mon Oct 4 21:06:58 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 4 Oct 2010 21:06:58 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101004190658.943072474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/04 21:06:58 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: missed a dependency on nul termination (beware strdup) From jkrell at elego.de Mon Oct 4 21:11:51 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 4 Oct 2010 21:11:51 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101004191152.319932474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/04 21:11:51 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: squeeze out a bit more nul termination inefficiency -- don't allocate room for it or copy it in From jkrell at elego.de Mon Oct 4 21:14:25 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 4 Oct 2010 21:14:25 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101004191425.84F202474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/04 21:14:25 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: grow some buffers from 100 to 256 (there's another one, but it should be growable and start small) From jkrell at elego.de Wed Oct 6 11:03:54 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 6 Oct 2010 11:03:54 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101006090354.BD40E2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/06 11:03:54 Modified files: cm3/m3-sys/m3cc/gcc/gcc/: ipa.c Log message: neuter 4.3 cgraph_remove_unreachable_nodes that doesn't like our trees From jkrell at elego.de Wed Oct 6 11:15:44 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 6 Oct 2010 11:15:44 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101006091544.B9B8F2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/06 11:15:44 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: turn off stablize_reference and all the type code, on SPARC32_SOLARIS (which is also volatile_all, and gcc 4.3) From jkrell at elego.de Wed Oct 6 11:16:59 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 6 Oct 2010 11:16:59 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101006091659.ABEDB2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/06 11:16:59 Modified files: cm3/m3-sys/m3cc/gcc/gcc/: ipa.c Log message: go back a version From jkrell at elego.de Wed Oct 6 11:22:57 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 6 Oct 2010 11:22:57 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101006092258.030BC2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/06 11:22:57 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: cleaner and add comment -- disabling all type code on SPARC32_SOLARIS From jkrell at elego.de Wed Oct 6 11:24:25 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 6 Oct 2010 11:24:25 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101006092425.208732474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/06 11:24:25 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: cleaner From jkrell at elego.de Wed Oct 6 11:31:54 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 6 Oct 2010 11:31:54 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101006093154.9D6F72474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/06 11:31:54 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: fix typo From jkrell at elego.de Wed Oct 6 12:45:43 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 6 Oct 2010 12:45:43 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101006104543.A18DB2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/06 12:45:43 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: -O3 breaks Solaris/sparc32 internally silently convert it to -O2, for this target only (when you run a bootstrap cm3 from -O3, the exception upon not finding cm3.cfg isn't dispatched correctly) From jkrell at elego.de Wed Oct 6 13:41:10 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 6 Oct 2010 13:41:10 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101006114110.CB7FA2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/06 13:41:10 Modified files: cm3/m3-libs/m3core/src/runtime/SOLgnu/: m3makefile Log message: use forward slash directly instead of SL From jkrell at elego.de Wed Oct 6 13:52:52 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 6 Oct 2010 13:52:52 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101006115252.B14D92474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/06 13:52:52 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: NetBSD.common Log message: also look in /usr/X11R7/lib in addition to /usr/X11R6/lib, as that is where things are on my 5.0.2 system (really should use $ORIGIN here..at least if on a 5.0+ system From jkrell at elego.de Wed Oct 6 14:03:27 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 6 Oct 2010 14:03:27 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101006120328.004A72474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/06 14:03:27 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: I386.common Log message: remove -mno-align-double I would really like the cm3cg command lines to be very cruft free, and this should no longer make a difference. Frontend aligns doubles to 8 bytes on all platforms, even though it could get away with 4 bytes on some e.g. x86. If there are any problems on any x86 platforms, try putting this back. It was especially painful at some point to debug this on Cygwin. Tested only I386_LINUX, but affects far more. From jkrell at elego.de Wed Oct 6 14:06:04 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 6 Oct 2010 14:06:04 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101006120604.E40F22474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/06 14:06:04 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: NT386.common Log message: remove -mno-align-double it should no longer matter But anyone using Cygwin or MinGW, beware! From jkrell at elego.de Wed Oct 6 14:08:08 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 6 Oct 2010 14:08:08 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101006120808.63F8D2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/06 14:08:08 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: AMD64.common AMD64_LINUX I386_LINUX.common Log message: remove -mno-align-double from m3back_flags and SYSTEM_CC Beware From jkrell at elego.de Wed Oct 6 14:47:22 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 6 Oct 2010 14:47:22 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101006124723.0AA192474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/06 14:47:22 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: NetBSD.common Log message: fix typo, now PklFonts can run From hosking at cs.purdue.edu Wed Oct 6 15:11:00 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 6 Oct 2010 09:11:00 -0400 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20101006090354.BD40E2474003@birch.elegosoft.com> References: <20101006090354.BD40E2474003@birch.elegosoft.com> Message-ID: <2E507E51-9600-47B0-8849-99297B3841E9@cs.purdue.edu> What's wrong with them? On 6 Oct 2010, at 11:03, Jay Krell wrote: > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/10/06 11:03:54 > > Modified files: > cm3/m3-sys/m3cc/gcc/gcc/: ipa.c > > Log message: > neuter 4.3 cgraph_remove_unreachable_nodes that doesn't like our trees From hosking at cs.purdue.edu Wed Oct 6 15:12:02 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 6 Oct 2010 09:12:02 -0400 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20101006104543.A18DB2474003@birch.elegosoft.com> References: <20101006104543.A18DB2474003@birch.elegosoft.com> Message-ID: This suggests we lost information about exception blocks. It used to work... On 6 Oct 2010, at 12:45, Jay Krell wrote: > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/10/06 12:45:43 > > Modified files: > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > Log message: > -O3 breaks Solaris/sparc32 > internally silently convert it to -O2, for this target only > (when you run a bootstrap cm3 from -O3, the exception upon > not finding cm3.cfg isn't dispatched correctly) From jay.krell at cornell.edu Wed Oct 6 15:20:33 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 6 Oct 2010 13:20:33 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <2E507E51-9600-47B0-8849-99297B3841E9@cs.purdue.edu> References: <20101006090354.BD40E2474003@birch.elegosoft.com>, <2E507E51-9600-47B0-8849-99297B3841E9@cs.purdue.edu> Message-ID: I don't know, but there are many obvious candidates. We don't generate much type information, and we generate now some incorrect type information (wrong level of pointers sometimes on structs) In this case, it was getting a null pointer: edit /dev2/cm3/m3-sys/m3cc/gcc/gcc/ipa.c line 164 ??? ? if (DECL_STRUCT_FUNCTION (decl)) configure -enable-checking still complains about many things. Though I have fixed some. ? Turning it on all the time makes things much slower and I think also actually breaks things (!). It doesn't like the bitfield refs, something about missing a "VUSE". ?? Maybe volatile would be the better tradeoff?? It doesn't like various expressions that mix integer types. ? These shouldn't be hard to fix, and I have fixed some. ? They included that we were mixing up the return types of all functions that return ?? integers smaller than a word. It complains about the module initializers confusing structs and struct pointers in their return type. However I think not using the bitfield refs generates incorrect code now. ?ie: when I address configure -enable-checking, I get bad code. ? I have to look into this more. The configure -enable-checking problems seem to be somewhat large and very long standing. Configure -enable-checking also complains something about our use of static chain. It was hard enough just to get the static chain working 4.5...I don't look forward to understanding also figuring out why configure enable-checking doesn't like it. ?- Jay ---------------------------------------- > From: hosking at cs.purdue.edu > Date: Wed, 6 Oct 2010 09:11:00 -0400 > To: jkrell at elego.de > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > What's wrong with them? > > On 6 Oct 2010, at 11:03, Jay Krell wrote: > > > CVSROOT: /usr/cvs > > Changes by: jkrell at birch. 10/10/06 11:03:54 > > > > Modified files: > > cm3/m3-sys/m3cc/gcc/gcc/: ipa.c > > > > Log message: > > neuter 4.3 cgraph_remove_unreachable_nodes that doesn't like our trees > From hosking at cs.purdue.edu Wed Oct 6 15:28:05 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 6 Oct 2010 09:28:05 -0400 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20101006090354.BD40E2474003@birch.elegosoft.com>, <2E507E51-9600-47B0-8849-99297B3841E9@cs.purdue.edu> Message-ID: <4E2BB803-F603-4D9B-8E06-6B7D73CC7392@cs.purdue.edu> On 6 Oct 2010, at 09:20, Jay K wrote: > I don't know, but there are many obvious candidates. > We don't generate much type information, and we generate now some incorrect type information (wrong level > of pointers sometimes on structs) > In this case, it was getting a null pointer: > edit /dev2/cm3/m3-sys/m3cc/gcc/gcc/ipa.c line 164 > if (DECL_STRUCT_FUNCTION (decl)) > > > configure -enable-checking still complains about many things. Though I have fixed some. Yes, this has been most helpful. I would like to push it further but don't currently have the time. > Turning it on all the time makes things much slower and I think also actually breaks things (!). Yikes, really? > It doesn't like the bitfield refs, something about missing a "VUSE". > Maybe volatile would be the better tradeoff?? I think ultimately we should be good gcc citizens and generate proper type information. Then we can use properly named symbolic bitfield references. (So long as we can ensure that the front-end and back-end agree on layout.) > It doesn't like various expressions that mix integer types. > These shouldn't be hard to fix, and I have fixed some. > They included that we were mixing up the return types of all functions that return > integers smaller than a word. RIght. > It complains about the module initializers confusing structs and struct pointers in their return type. Should be fixable. > However I think not using the bitfield refs generates incorrect code now. > ie: when I address configure -enable-checking, I get bad code. > I have to look into this more. Sigh. > The configure -enable-checking problems seem to be somewhat large and very long standing. > > > Configure -enable-checking also complains something about our use of static chain. > It was hard enough just to get the static chain working 4.5...I don't look forward to > understanding also figuring out why configure enable-checking doesn't like it. Hmm. Do we know what Pascal/Ada/D and friends do in this instance? > > > - Jay > > ---------------------------------------- >> From: hosking at cs.purdue.edu >> Date: Wed, 6 Oct 2010 09:11:00 -0400 >> To: jkrell at elego.de >> CC: m3commit at elegosoft.com >> Subject: Re: [M3commit] CVS Update: cm3 >> >> What's wrong with them? >> >> On 6 Oct 2010, at 11:03, Jay Krell wrote: >> >>> CVSROOT: /usr/cvs >>> Changes by: jkrell at birch. 10/10/06 11:03:54 >>> >>> Modified files: >>> cm3/m3-sys/m3cc/gcc/gcc/: ipa.c >>> >>> Log message: >>> neuter 4.3 cgraph_remove_unreachable_nodes that doesn't like our trees >> > From jay.krell at cornell.edu Wed Oct 6 15:26:52 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 6 Oct 2010 13:26:52 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20101006104543.A18DB2474003@birch.elegosoft.com>, Message-ID: -O3 definitely worked on Solaris/sparc32? None of the optimization flags get tested in Hudson. I don't test Solaris/sparc32 much -- local machine is slow, network seems slow using remote machines. ?- Jay ---------------------------------------- > From: hosking at cs.purdue.edu > Date: Wed, 6 Oct 2010 09:12:02 -0400 > To: jkrell at elego.de > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > This suggests we lost information about exception blocks. It used to work... > > On 6 Oct 2010, at 12:45, Jay Krell wrote: > > > CVSROOT: /usr/cvs > > Changes by: jkrell at birch. 10/10/06 12:45:43 > > > > Modified files: > > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > > > Log message: > > -O3 breaks Solaris/sparc32 > > internally silently convert it to -O2, for this target only > > (when you run a bootstrap cm3 from -O3, the exception upon > > not finding cm3.cfg isn't dispatched correctly) > From jay.krell at cornell.edu Wed Oct 6 15:40:03 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 6 Oct 2010 13:40:03 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <4E2BB803-F603-4D9B-8E06-6B7D73CC7392@cs.purdue.edu> References: <20101006090354.BD40E2474003@birch.elegosoft.com>, <2E507E51-9600-47B0-8849-99297B3841E9@cs.purdue.edu> , <4E2BB803-F603-4D9B-8E06-6B7D73CC7392@cs.purdue.edu> Message-ID: > I think ultimately we should be good gcc citizens and generate proper type information Me too, but it is a can of worms. It is hard to get from current situation to typeful situation in small working steps. I don't have a long attention span, it is difficult to get through large items.. > Then we can use properly named symbolic bitfield references Field/component references. The underlying field will have one of any type: integer, float, pointer, bitfield, etc. We can use this for records, objects, arrays. > > Turning it on all the time makes things much slower and I think also actually breaks things (!). > > Yikes, really? It definitely slows things down. I'm pretty sure when I don't use bitfield refs, I get bad code. I have to try again. I don't have things well automated in terms of keeping around various configurations and easily switching them, and I often go overboard and build too much and don't do a good job of reducing the problem, but "stare" at too much. What I should do is like, binary search where the variable is which compiler and the data being "searched" is, say, all of m3core. And then once the difference found, have to see why the compiler made the decision. I haven't debugged the compiler much. I don't know its domain -- ssa, vdefs, vuses, etc. > > It complains about the module initializers confusing structs and struct pointers in their return type. > > Should be fixable. Yes. Thing is. I have to test each change both with and without configure enable-checking. I rely too much on scripts..end up rebuilding backend more than needed (much quicker now with gmp reduced!) > Hmm. Do we know what Pascal/Ada/D and friends do in this instance? Good point. I don't know. Could be they let gcc use its regular trampolines. Which has advantages and disadvantages. But I don't know. (advantages: leaves the work/maintanence to mainline gcc, more interopable with C; disadvantages: doesn't work on all platforms, is slower (mprotect on some platforms) and faster (no need to check for the marker)). But I don't know. I'd be in favor of transforming this away in the frontend, or maybe in parse.c. It does require more or less dataflow analysis to see which locals/parameters ared used by nested functions, which is probably easy to make a safe guess at, but then difficult to make an optimized guess at. i.e. you'd end up reserving space for and storing locals/parameters that are then not used. ?- Jay ---------------------------------------- > Subject: Re: [M3commit] CVS Update: cm3 > From: hosking at cs.purdue.edu > Date: Wed, 6 Oct 2010 09:28:05 -0400 > CC: jkrell at elego.de; m3commit at elegosoft.com > To: jay.krell at cornell.edu > > On 6 Oct 2010, at 09:20, Jay K wrote: > > > I don't know, but there are many obvious candidates. > > We don't generate much type information, and we generate now some incorrect type information (wrong level > > of pointers sometimes on structs) > > In this case, it was getting a null pointer: > > edit /dev2/cm3/m3-sys/m3cc/gcc/gcc/ipa.c line 164 > > if (DECL_STRUCT_FUNCTION (decl)) > > > > > > configure -enable-checking still complains about many things. Though I have fixed some. > > Yes, this has been most helpful. I would like to push it further but don't currently have the time. > > > Turning it on all the time makes things much slower and I think also actually breaks things (!). > > Yikes, really? > > > It doesn't like the bitfield refs, something about missing a "VUSE". > > Maybe volatile would be the better tradeoff?? > > I think ultimately we should be good gcc citizens and generate proper type information. Then we can use properly named symbolic bitfield references. (So long as we can ensure that the front-end and back-end agree on layout.) > > > It doesn't like various expressions that mix integer types. > > These shouldn't be hard to fix, and I have fixed some. > > They included that we were mixing up the return types of all functions that return > > integers smaller than a word. > > RIght. > > > It complains about the module initializers confusing structs and struct pointers in their return type. > > Should be fixable. > > > However I think not using the bitfield refs generates incorrect code now. > > ie: when I address configure -enable-checking, I get bad code. > > I have to look into this more. > > Sigh. > > > The configure -enable-checking problems seem to be somewhat large and very long standing. > > > > > > Configure -enable-checking also complains something about our use of static chain. > > It was hard enough just to get the static chain working 4.5...I don't look forward to > > understanding also figuring out why configure enable-checking doesn't like it. > > Hmm. Do we know what Pascal/Ada/D and friends do in this instance? > > > > > > > - Jay > > > > ---------------------------------------- > >> From: hosking at cs.purdue.edu > >> Date: Wed, 6 Oct 2010 09:11:00 -0400 > >> To: jkrell at elego.de > >> CC: m3commit at elegosoft.com > >> Subject: Re: [M3commit] CVS Update: cm3 > >> > >> What's wrong with them? > >> > >> On 6 Oct 2010, at 11:03, Jay Krell wrote: > >> > >>> CVSROOT: /usr/cvs > >>> Changes by: jkrell at birch. 10/10/06 11:03:54 > >>> > >>> Modified files: > >>> cm3/m3-sys/m3cc/gcc/gcc/: ipa.c > >>> > >>> Log message: > >>> neuter 4.3 cgraph_remove_unreachable_nodes that doesn't like our trees > >> > > > From jkrell at elego.de Wed Oct 6 16:20:18 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 6 Oct 2010 16:20:18 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101006142018.A76712474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/06 16:20:18 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: SPARC64.common Log message: just remove the second trailing newline From jkrell at elego.de Wed Oct 6 16:20:36 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 6 Oct 2010 16:20:36 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101006142036.6D7562474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/06 16:20:36 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: SPARC.common SPARC32_LINUX Log message: just remove the second trailing newline From jay.krell at cornell.edu Wed Oct 6 16:24:41 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 6 Oct 2010 14:24:41 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20101006142036.6D7562474003@birch.elegosoft.com> References: <20101006142036.6D7562474003@birch.elegosoft.com> Message-ID: darnit, that was supposed to be diff, not commit I'm still testing it. What it really is is: ? use -K PIC on SPARC32_LINUX assembler (to be matched in pylib.py) ? use -mno-app-regs in m3back_flags and gcc (also to be matched in pylib.py, for Linux, I have to check the Sun cc flags) ? remove unnecessary flags about double alignment I frequently see a problem where -fPIC breaks cross cm3. It might be this -K PIC or -mno-app-regs. And I'm seeing SPARC32_LINUX fail early with gcc 4.5. Might be these. These might also explain SPARC32_SOLARIS problems. I'm still testing. For some reason I only noticed -mno-app-regs when working on SPARC64, but it seems to maybe related to SPARC32 also. ?- Jay ---------------------------------------- > Date: Wed, 6 Oct 2010 16:20:36 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/10/06 16:20:36 > > Modified files: > cm3/m3-sys/cminstall/src/config-no-install/: SPARC.common > SPARC32_LINUX > > Log message: > just remove the second trailing newline > From jkrell at elego.de Wed Oct 6 16:44:45 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 6 Oct 2010 16:44:45 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101006144445.7917F2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/06 16:44:45 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: SPARC.common SPARC32_LINUX SPARC64_LINUX SPARC64_OPENBSD Log message: work in progress (or possibly done) on pic/regs flags (SPARC64 less actively tested!) From jkrell at elego.de Wed Oct 6 16:52:09 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 6 Oct 2010 16:52:09 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101006145220.2B07C2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/06 16:52:09 Modified files: cm3/scripts/python/: pylib.py Log message: fidget with pic/app-regs flags -- looking better for SPARC32_LINUX but still not for SPARC32_SOLARIS From hosking at cs.purdue.edu Wed Oct 6 16:50:30 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 6 Oct 2010 10:50:30 -0400 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20101006104543.A18DB2474003@birch.elegosoft.com>, Message-ID: <074A9418-7240-4678-B3CE-C98C2C8B1908@cs.purdue.edu> Yes, at some point in the past 5 years it worked on Solaris/Sparc32. Not sure when... :-( On 6 Oct 2010, at 09:26, Jay K wrote: > > -O3 definitely worked on Solaris/sparc32? > None of the optimization flags get tested in Hudson. > I don't test Solaris/sparc32 much -- local machine is slow, network seems slow using remote machines. > > - Jay > > ---------------------------------------- >> From: hosking at cs.purdue.edu >> Date: Wed, 6 Oct 2010 09:12:02 -0400 >> To: jkrell at elego.de >> CC: m3commit at elegosoft.com >> Subject: Re: [M3commit] CVS Update: cm3 >> >> This suggests we lost information about exception blocks. It used to work... >> >> On 6 Oct 2010, at 12:45, Jay Krell wrote: >> >>> CVSROOT: /usr/cvs >>> Changes by: jkrell at birch. 10/10/06 12:45:43 >>> >>> Modified files: >>> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c >>> >>> Log message: >>> -O3 breaks Solaris/sparc32 >>> internally silently convert it to -O2, for this target only >>> (when you run a bootstrap cm3 from -O3, the exception upon >>> not finding cm3.cfg isn't dispatched correctly) >> > From jkrell at elego.de Wed Oct 6 16:59:40 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 6 Oct 2010 16:59:40 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101006145940.566F42474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/06 16:59:40 Modified files: cm3/m3-sys/m3cc/src/: m3makefile Log message: move SPARC32_LINUX to gcc 4.5.1 backend still testing but looking ok, bootstrap cm3 runs ok move I386_OPENBSD to gcc 4.5.1 backend I think I tested it. It is the only I386 target not moved. move MIPS64_OPENBSD to gcc 4.5.1 backend Not tested. This platform hasn't really arrived and isn't very likely -- SGI hardware, which I do have.. move MIPS64EL_OPENBSD to gcc 4.5.1 backend. Not tested. Much more viable than MIPS64_OPENBSD as there is recently developed laptops running it (yes, I have one). (They run Linux too.) From jay.krell at cornell.edu Wed Oct 6 17:06:03 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 6 Oct 2010 15:06:03 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <074A9418-7240-4678-B3CE-C98C2C8B1908@cs.purdue.edu> References: <20101006104543.A18DB2474003@birch.elegosoft.com>, , , , <074A9418-7240-4678-B3CE-C98C2C8B1908@cs.purdue.edu> Message-ID: Let me maybe get 4.5.1 working before -O3. Granted..I agree it was probably working as recently as the recent release. What changed since then? In the 4.3 tree? ==> I moved from 4.3.0 to 4.3.5. So if we want to find -O3 working, it is probably there. ?- Jay ---------------------------------------- > From: hosking at cs.purdue.edu > Date: Wed, 6 Oct 2010 10:50:30 -0400 > To: jay.krell at cornell.edu > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > Yes, at some point in the past 5 years it worked on Solaris/Sparc32. Not sure when... :-( > > On 6 Oct 2010, at 09:26, Jay K wrote: > > > > > -O3 definitely worked on Solaris/sparc32? > > None of the optimization flags get tested in Hudson. > > I don't test Solaris/sparc32 much -- local machine is slow, network seems slow using remote machines. > > > > - Jay > > > > ---------------------------------------- > >> From: hosking at cs.purdue.edu > >> Date: Wed, 6 Oct 2010 09:12:02 -0400 > >> To: jkrell at elego.de > >> CC: m3commit at elegosoft.com > >> Subject: Re: [M3commit] CVS Update: cm3 > >> > >> This suggests we lost information about exception blocks. It used to work... > >> > >> On 6 Oct 2010, at 12:45, Jay Krell wrote: > >> > >>> CVSROOT: /usr/cvs > >>> Changes by: jkrell at birch. 10/10/06 12:45:43 > >>> > >>> Modified files: > >>> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > >>> > >>> Log message: > >>> -O3 breaks Solaris/sparc32 > >>> internally silently convert it to -O2, for this target only > >>> (when you run a bootstrap cm3 from -O3, the exception upon > >>> not finding cm3.cfg isn't dispatched correctly) > >> > > > From rodney_bates at lcwb.coop Wed Oct 6 21:51:06 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Wed, 06 Oct 2010 14:51:06 -0500 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20101006090354.BD40E2474003@birch.elegosoft.com>, <2E507E51-9600-47B0-8849-99297B3841E9@cs.purdue.edu> , <4E2BB803-F603-4D9B-8E06-6B7D73CC7392@cs.purdue.edu> Message-ID: <4CACD32A.6030906@lcwb.coop> Jay K wrote: --snip-- > > (Tony)>> Hmm. Do we know what Pascal/Ada/D and friends do in this instance? > > > Good point. I don't know. > Could be they let gcc use its regular trampolines. > Which has advantages and disadvantages. But I don't know. > (advantages: leaves the work/maintanence to mainline gcc, more interopable with C; disadvantages: > doesn't work on all platforms, is slower (mprotect on some platforms) and faster (no need > to check for the marker)). > But I don't know. > I'd be in favor of transforming this away in the frontend, or maybe in parse.c. > It does require more or less dataflow analysis to see which locals/parameters ared used by nested functions, > which is probably easy to make a safe guess at, but then difficult to make an optimized guess at. > i.e. you'd end up reserving space for and storing locals/parameters that are then not used. > tree-nested.c in gcc now does this. There is extensive tree-rewriting as a result. Local variables and parameters that are accessed nonlocally (i.e., from within a more deeply-nested procedure) are collected into a record, which is then placed as a local variable. It can be accessed by two different static links, located in different places. I forget all the details. I understood it once. There are a _lot_ of multiple copies of things, duplicate copies of parameters passed by value, duplicate pointers to things passed by reference, etc. I think there can even be three copies of these things. It all leads to activation record expansion and extra code executed in prologs and in accessing things. The apparent reason is that it greatly simplifies the compile-time interaction among nested procedures, nonlocal access, and inlining. The generated record of nonlocally-accessed stuff doesn't have to be known to be located inside any particular activation record, and with inlining, it may not be. Or something like that. Note that this is all about ordinary nonlocal accesses from nested procedures, which use neither trampolines nor closures. The latter are only used when creating and using parameters of procedure type, whose runtime values can sometimes be nested procedures. This is largely independent of static links, etc. The trampolines/closures are only a way of storing static link values in formals of procedure type. Where the values come from before they are stored and where they go and how they are used after they are extracted is independent. For static links themselves, the runtime model is the same for C and Modula-3 code. > > - Jay From jkrell at elego.de Thu Oct 7 09:46:56 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 7 Oct 2010 9:46:56 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101007074657.0BCC82474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/07 09:46:56 Modified files: cm3/m3-sys/m3cc/src/: m3makefile Log message: switch AMD64_SOLARIS to gcc 4.5.1 backend It worked far enough to build and run a cross/boot cm3. workaround http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45927 From jkrell at elego.de Thu Oct 7 11:46:14 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 7 Oct 2010 11:46:14 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101007094614.813842474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/07 11:46:14 Modified files: cm3/scripts/: pkgmap.sh cm3/scripts/regression/: hudson_build_system.sh Log message: instrumentation: try to find when the PPC_LINUX directory permisions get broken, if indeed it is even within here; maybe should reinstall OS... From jkrell at elego.de Thu Oct 7 12:40:53 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 7 Oct 2010 12:40:53 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101007104055.714A12474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/07 12:40:53 Modified files: cm3/m3-sys/m3cc/src/: gnucc.common Log message: gcc 3.4.3 can't compile gcc 4.5.1 targeting AMD64_SOLARIS see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45929 It would be nice to split up the files for portability. So favor gcc 4.x on the opencsw machines, where we can find it. When doing native AMD64_SOLARIS builds. Other folks will have to modify $PATH. Note that cc in path should and I think also does take precedence. We generally favor Sun cc. Eh? From jkrell at elego.de Thu Oct 7 13:26:28 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 7 Oct 2010 13:26:28 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101007112628.E76FA2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/07 13:26:28 Modified files: cm3/m3-sys/m3cc/gcc-4.5/gcc/config/sparc/: sparc.h Log message: Duh! #define TARGET_SPARC 1 like for 4.3.5 to trigger volatile madness in parse.c. From jkrell at elego.de Thu Oct 7 13:50:37 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 7 Oct 2010 13:50:37 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101007115038.171202474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/07 13:50:37 Modified files: cm3/m3-sys/m3cc/gcc-4.5/gcc/config/: sol2.h cm3/m3-sys/m3cc/gcc-apple/gcc/config/: sol2.h cm3/m3-sys/m3cc/gcc-apple/gcc/config/sparc/: sparc.h Log message: Duh! #define TARGET_SOLARIS 1 also and follow suit in gcc-apple for no reason. From jkrell at elego.de Thu Oct 7 14:22:13 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 7 Oct 2010 14:22:13 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101007122213.CB3F72474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/07 14:22:13 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: safe keeping: use volatile more consistently and more often From jkrell at elego.de Thu Oct 7 14:22:37 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 7 Oct 2010 14:22:37 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101007122238.19F0C2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/07 14:22:37 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: go back a version From jkrell at elego.de Sat Oct 9 13:36:40 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 9 Oct 2010 13:36:40 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101009113640.971012474032@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/09 13:36:40 Modified files: cm3/m3-sys/m3cc/src/: m3makefile Log message: cleanup the "NOACTION" feature, by wrapping the whole thing in a function and using early return NOTE: This would also be perfectly clean and natural using goto. Goto is not evil! Compare it to the contortions people go through to avoid it. Those are evil. It would be evil to not have the option of if/else/switch/for/while/break/continue, but not having goto is also evil. let PREBUILT_CM3CG work with cross builds, by copying to build_dir instead of just dot (move the code down to after build_dir is computed/created) PREBUILT_CM3CG doesn't use $WORKSPACE but requires it be set. Why? To avoid honoring it in other random settings? Let PREBUILT_CM3CG also work if $USER = jay. Really: we should not be defining our own environment variables that don't start with CM3_! Even that isn't great. And we should try to use cm3 -D options instead? Environment variables are fairly flat namespace (though you can use underscores and long names) and they flow into unrelated processes, so perhaps to be avoided. However they also flow automatically into child processes, which can be good, when you don't control the command lines all the way through. (It turns out, there's just no perfect solution here. You can also store configuration state globally like in files or registry, but then you can't scope it to a particular process or process tree. A good hybrid, if there is much parameters/state, is stash it in a temporary file/directory, and put that file/directory path in an environment variable -- ie: use just one environment variable). From jkrell at elego.de Wed Oct 13 13:18:53 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 13 Oct 2010 13:18:53 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101013111853.858402474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/13 13:18:53 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: SPARC32_SOLARIS.common cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c cm3/m3-sys/m3cc/gcc-4.5/gcc/: function.c cm3/m3-sys/m3cc/src/: clean_marker.txt m3makefile cm3/m3-sys/m3middle/src/: Target.m3 cm3/m3-libs/m3core/src/runtime/: m3makefile Added files: cm3/m3-libs/m3core/src/runtime/SOLgnu/: m3makefile-old cm3/m3-libs/m3core/src/runtime/SOLsun/: m3makefile-old Removed files: cm3/m3-libs/m3core/src/runtime/SOLgnu/: m3makefile cm3/m3-libs/m3core/src/runtime/SOLsun/: m3makefile Log message: disable Solaris/sparc32 stack walker switch Solaris/sparc32 to gcc 4.5 backend function.c: make failure to volatilize when setjmp/vfork present an error instead of a warning add missing volatilization pin Solaris/sparc32 at -O1 in the config file as -O2/-O3 were seen to hit internal compiler errors (assertion failures) remove the "all volatile" paths from parse.c (since they were only for Solaris/sparc32's stack walker) From jkrell at elego.de Wed Oct 13 17:57:26 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 13 Oct 2010 17:57:26 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101013155726.A77D82474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/13 17:57:26 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: SPARC32_SOLARIS.common Log message: let it be -O3 From jkrell at elego.de Wed Oct 13 18:01:48 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 13 Oct 2010 18:01:48 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101013160148.7F09E2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/13 18:01:48 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: SPARC32_SOLARIS.common Log message: go back a version: unresolved symbols, probably we can just disable a small number of optimizations though From jkrell at elego.de Wed Oct 13 18:10:32 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 13 Oct 2010 18:10:32 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101013161032.360432474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/13 18:10:32 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: SPARC32_SOLARIS.common Log message: cm3 bootstapped ok with -O2 so let's try that From jkrell at elego.de Wed Oct 13 18:29:30 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 13 Oct 2010 18:29:30 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101013162930.C4BEBCC123@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/13 18:29:30 Modified files: cm3/scripts/python/: pylib.py Log message: experimental: don't set M3CONFIG into the source tree; e.g. so we can upgrade from SOLsun with stack walker to without From jkrell at elego.de Wed Oct 13 18:31:22 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 13 Oct 2010 18:31:22 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101013163122.D21FB2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/13 18:31:22 Modified files: cm3/scripts/regression/: hudson_build_system.sh Log message: fix plin instrumentation that broke everything From jkrell at elego.de Wed Oct 13 18:31:53 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 13 Oct 2010 18:31:53 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101013163153.5CD452474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/13 18:31:53 Modified files: cm3/scripts/regression/: hudson_build_system.sh Log message: fix plin instrumentation that broke everything From jkrell at elego.de Wed Oct 13 18:32:31 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 13 Oct 2010 18:32:31 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101013163231.B282D2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/13 18:32:31 Modified files: cm3/scripts/: pkgmap.sh Log message: fix plin instrumentation that broke everything From jkrell at elego.de Sat Oct 16 07:33:41 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 16 Oct 2010 7:33:41 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101016053341.AACB3CC362@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/16 07:33:41 Modified files: cm3/scripts/win/: cvs.c Log message: remove wcscmp use and tabs From jkrell at elego.de Sat Oct 16 08:20:00 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 16 Oct 2010 8:20:00 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101016062000.353F9CC124@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/16 08:20:00 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Added files: cm3/m3-sys/m3back/src/: M3C.i3 Log message: work in progress From jkrell at elego.de Sat Oct 16 10:39:30 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 16 Oct 2010 10:39:30 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101016083930.C2BEFCC124@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/16 10:39:30 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: work in progress From jkrell at elego.de Sat Oct 16 10:42:41 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 16 Oct 2010 10:42:41 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101016084242.290E82474010@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/16 10:42:41 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: work in progress From jkrell at elego.de Sat Oct 16 11:24:39 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 16 Oct 2010 11:24:39 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101016092439.DC8A32474010@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/16 11:24:39 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: work in progress: it compiles and has a few lines of real code, but is missing *a lot* From jkrell at elego.de Sat Oct 16 11:27:27 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 16 Oct 2010 11:27:27 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101016092727.85D802474010@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/16 11:27:27 Modified files: cm3/m3-sys/m3back/src/: M3C.i3 m3makefile Log message: compile nascent C backend again, there is almost nothing actually here From jkrell at elego.de Sat Oct 16 12:16:12 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 16 Oct 2010 12:16:12 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101016101613.0F2CB2474010@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/16 12:16:12 Modified files: cm3/m3-libs/m3core/src/C/Common/: CstdioC.c CstdlibC.c CstringC.c cm3/m3-libs/m3core/src/Csupport/Common/: dtoa.h hand.c cm3/m3-libs/m3core/src/runtime/WIN32/: RTOSc.c cm3/m3-libs/m3core/src/runtime/common/: RTIOc.c RTMiscC.c RTUntracedMemoryC.c cm3/m3-libs/m3core/src/runtime/ex_frame/: RTStackC.c cm3/m3-libs/m3core/src/thread/WIN32/: ThreadWin32C.c cm3/m3-libs/m3core/src/unix/Common/: Uexec.c Uin.c Unetdb.c UnixC.c UnixLink.c Uprocess.c UtimeC.c Uuio.c cm3/m3-libs/sysutils/src/: SystemC.c Log message: Remove the _DLL/_MT hacking that I had put in, which purported to let one set of object code link with either msvcrt.lib or libcmt.lib. Not a bad idea, not a bad implementation, but a bit on the unsupported side. If user really wants to use libcmt.lib, he should modify the config file and rebuild everything (esp. m3core). We should possibly make such a configuration in Hudson. We should possibly automatically multiply out compile/link for any directories that contain any C? And then build_standalone could imply libmt.lib. Not a bad idea, but unlikely to happen. From jkrell at elego.de Sat Oct 16 12:19:53 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 16 Oct 2010 12:19:53 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101016101953.0DFD12474010@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/16 12:19:53 Modified files: cm3/m3-libs/m3core/src/runtime/common/: RTUntracedMemoryC.c Log message: remove K&R From jkrell at elego.de Sat Oct 16 12:22:17 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 16 Oct 2010 12:22:17 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101016102219.259E22474010@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/16 12:22:17 Modified files: cm3/m3-libs/m3core/src/: m3core.h Log message: move up #ifdef _MSC_VER #pragma warning(disable...) in order to quash: ../..\m3core.h(33) : warning C4668: '__GNUC__' is not defined as a preprocessor macro, replacing with '0' for '#if/#elif' when compiling with -Wall From jay.krell at cornell.edu Sat Oct 16 12:17:24 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 16 Oct 2010 10:17:24 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20101016101613.0F2CB2474010@birch.elegosoft.com> References: <20101016101613.0F2CB2474010@birch.elegosoft.com> Message-ID: diff attached ---------------------------------------- > Date: Sat, 16 Oct 2010 12:16:12 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/10/16 12:16:12 > > Modified files: > cm3/m3-libs/m3core/src/C/Common/: CstdioC.c CstdlibC.c > CstringC.c > cm3/m3-libs/m3core/src/Csupport/Common/: dtoa.h hand.c > cm3/m3-libs/m3core/src/runtime/WIN32/: RTOSc.c > cm3/m3-libs/m3core/src/runtime/common/: RTIOc.c RTMiscC.c > RTUntracedMemoryC.c > cm3/m3-libs/m3core/src/runtime/ex_frame/: RTStackC.c > cm3/m3-libs/m3core/src/thread/WIN32/: ThreadWin32C.c > cm3/m3-libs/m3core/src/unix/Common/: Uexec.c Uin.c Unetdb.c > UnixC.c UnixLink.c > Uprocess.c UtimeC.c Uuio.c > cm3/m3-libs/sysutils/src/: SystemC.c > > Log message: > Remove the _DLL/_MT hacking that I had put in, > which purported to let one set of object code > link with either msvcrt.lib or libcmt.lib. > > Not a bad idea, not a bad implementation, but > a bit on the unsupported side. > > If user really wants to use libcmt.lib, he should > modify the config file and rebuild everything (esp. m3core). > We should possibly make such a configuration in Hudson. > We should possibly automatically multiply out compile/link > for any directories that contain any C? And then build_standalone > could imply libmt.lib. Not a bad idea, but unlikely to happen. > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 1.txt URL: From jkrell at elego.de Sat Oct 16 12:26:02 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 16 Oct 2010 12:26:02 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101016102602.24D902474010@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/16 12:26:02 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: test_hand.c Log message: add __fastcall versions of set_member, set_singleton: point being to read the code and have m3back use it instead of what currently does, which is very very well size optimized but not very well speed optimized, since the instruction it uses imply an interlock, unfortunate From jkrell at elego.de Sat Oct 16 12:31:20 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 16 Oct 2010 12:31:20 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101016103120.88EE32474010@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/16 12:31:20 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: remove comments that say set_member and set_singleton are never used, as I'm inclined at least temporary to go back to function calls From jkrell at elego.de Sat Oct 16 12:39:59 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 16 Oct 2010 12:39:59 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101016104003.9F8622474010@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/16 12:39:59 Modified files: cm3/m3-sys/m3back/src/: M3x86.m3 Log message: go back to function calls for set_member and set_range The inline code was wonderfully small, but unfortunately had an implied and unremovable interlock, which is not good. From jkrell at elego.de Sat Oct 16 12:44:21 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 16 Oct 2010 12:44:21 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101016104421.F1E232474010@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/16 12:44:21 Modified files: cm3/m3-sys/m3back/src/: Codex86.i3 Codex86.m3 Log message: add "interlocked" or "Interlocked" to the various BitOp, BitTestOp, BitTestAndSetOp identifiers, to indicate that they are, alas, interlocked. They would be so much more useful of they were only interlocked if they had a lock prefix. These functions are now unused and should probably be removed. From jkrell at elego.de Sat Oct 16 12:58:33 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 16 Oct 2010 12:58:33 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101016105833.450732474010@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/16 12:58:33 Modified files: cm3/m3-sys/m3back/src/: Codex86.m3 M3x86Rep.i3 Log message: generate the constant 1 with xor and inc for a total of 3 bytes instead of a 5 byte mov, just like the C compiler does (when optimizing for size instead of speed) From jkrell at elego.de Sat Oct 16 13:06:47 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 16 Oct 2010 13:06:47 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101016110647.C3BAD2474010@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/16 13:06:47 Modified files: cm3/m3-sys/m3back/src/: Codex86.m3 Log message: don't duplicate code -- having assignment be an expression sure would be handy! From jkrell at elego.de Sat Oct 16 14:12:02 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 16 Oct 2010 14:12:02 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101016121203.17A7D2474010@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/16 14:12:02 Modified files: cm3/m3-sys/m3back/src/: Codex86.m3 Log message: push one byte integers with 2 byte 0x6A instruction instead of 5 byte 0x68 instruction load one byte integers into registers with 2 byte push followed by 1 byte pop, instead of 5 byte move (except for 0 which is xor and 1 which is xor/inc) pessimize this and previous xor/inc for 1 to only handle 32 bit integers (it'd work for 64bit as xor/xor/inc but we might check for the overflow upon inc, conditional branch, etc. (0 is still xor; a pair of xors is still better than almost anything else; notice though that there are optimizations based on knowing you are modifying two registers, where one is computed from the other, such as via a mov or mov/inc) From jkrell at elego.de Sat Oct 16 14:23:29 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 16 Oct 2010 14:23:29 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101016122329.41CC02474010@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/16 14:23:29 Modified files: cm3/m3-sys/m3back/src/: Codex86.m3 Log message: handle -1 before handling -128 through 127 (3 byte or with -1, one instruction, vs. 3 bytes 2 instructions..anyway..I don't know the cycle count or scheduling nuances, but emulate the C compiler!) From jkrell at elego.de Sat Oct 16 14:26:35 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 16 Oct 2010 14:26:35 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101016122635.DBF532474010@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/16 14:26:35 Modified files: cm3/m3-sys/m3back/src/: Codex86.m3 Log message: just add a comment From jkrell at elego.de Sat Oct 16 14:31:22 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 16 Oct 2010 14:31:22 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101016123122.A5F602474010@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/16 14:31:22 Modified files: cm3/m3-sys/m3back/src/: Codex86.m3 Log message: don't use push/pop to load esp with a one byte constant -- highly highly unlikely to ever hit this From jkrell at elego.de Sat Oct 16 14:31:58 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 16 Oct 2010 14:31:58 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101016123158.8B9042474010@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/16 14:31:58 Modified files: cm3/m3-sys/m3back/src/: Codex86.m3 Log message: parens From jay.krell at cornell.edu Mon Oct 18 11:17:38 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 18 Oct 2010 09:17:38 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20101006090354.BD40E2474003@birch.elegosoft.com>, , <2E507E51-9600-47B0-8849-99297B3841E9@cs.purdue.edu>, , <4E2BB803-F603-4D9B-8E06-6B7D73CC7392@cs.purdue.edu>, Message-ID: ?> ?> > > Turning it on all the time makes things much slower and I think also actually breaks things (!). ?> ?> > Yikes, really? > ?> It definitely slows things down. ?> I'm pretty sure when I don't use bitfield refs, I get bad code. ?> I have to try again. ?> I don't have things well automated in terms of keeping around various configurations ?> and easily switching them, and I often go overboard and build too much and don't ?>? do a good job of reducing the problem, but "stare" at too much. I tested this again. Of course, it isn't enable-checking that generates bad code. But the "safe" non-bitfield code now does -- produces a crashing cm3 I386_DARWIN. I haven't looked into it, just that I tried it again. It also still generates less efficient code, at least when not optmizing. The add is a separate instruction, instead of building it in as an offset into the dereferencing instruction. You probably know that already. Perhaps the problem is applying the non-bitfield code for, um, bitfields? For offsets/sizes that aren't multiples of BITS_PER_UNIT? (er..I guess only offsets are relevant here). I'll try that. - Jay From jkrell at elego.de Tue Oct 19 10:03:29 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 19 Oct 2010 10:03:29 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101019080329.EBB8ACC85B@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/19 10:03:29 Modified files: cm3/m3-sys/m3back/src/: Codex86.i3 Codex86.m3 M3x86.m3 Log message: back to bt/bts/btr/btc instructions for set_member, set_singleton They are not in fact slow/atomic, I was mislead by a comment in gcc/config/i386/i386.md and I thought other finds on the Internet. From jkrell at elego.de Tue Oct 19 10:45:09 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 19 Oct 2010 10:45:09 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101019084509.C102ECC85B@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/19 10:45:09 Modified files: cm3/m3-sys/m3back/src/: Codex86.m3 M3x86.m3 M3x86Rep.i3 Stackx86.m3 Log message: rename TypeIs64 to TypeIsDoubleInt many other "64" remain however and I doubt we'll retarget this to AMD64 or any other architecture more likely to generate C In gcc parlance, SI is single int, 32bits, DI is double int, 64bits however here that's not what I mean, but rather an integer that uses two registers. It is tempting to call it just "double", but that means double precision floating point. From jkrell at elego.de Tue Oct 19 10:46:28 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 19 Oct 2010 10:46:28 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101019084628.917B3CC85B@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/19 10:46:28 Modified files: cm3/m3-sys/m3back/src/: M3x86.m3 Log message: just some whitespace changes From jkrell at elego.de Tue Oct 19 10:55:23 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 19 Oct 2010 10:55:23 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101019085523.738F4CC85B@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/19 10:55:23 Modified files: cm3/m3-sys/m3back/src/: Codex86.m3 M3x86.m3 M3x86Rep.i3 Stackx86.m3 Log message: go back from IsTypeDoubleInt to IsType64 From jkrell at elego.de Tue Oct 19 11:49:27 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 19 Oct 2010 11:49:27 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101019094927.203A0CC85B@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/19 11:49:27 Added files: cm3/scripts/win/: dos2unix.c Log message: copy of cvs.c From jkrell at elego.de Tue Oct 19 12:13:33 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 19 Oct 2010 12:13:33 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101019101333.340CDCC85B@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/19 12:13:33 Modified files: cm3/scripts/win/: dos2unix.c Log message: change it from cvs to dos2unix From jkrell at elego.de Tue Oct 19 12:27:54 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 19 Oct 2010 12:27:54 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101019102754.D9DFDCC85B@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/19 12:27:54 Modified files: cm3/scripts/win/: dos2unix.c cvs.c Log message: smaller From jkrell at elego.de Tue Oct 19 12:28:17 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 19 Oct 2010 12:28:17 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101019102817.231E1CC85B@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/19 12:28:17 Modified files: cm3/scripts/win/: dos2unix.c Log message: fix comment From jkrell at elego.de Tue Oct 19 12:28:54 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 19 Oct 2010 12:28:54 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101019102854.EA19CCC85B@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/19 12:28:54 Modified files: cm3/scripts/win/: cvs.c Log message: whitespace From jkrell at elego.de Tue Oct 19 12:55:40 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 19 Oct 2010 12:55:40 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101019105540.58DBFCC85B@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/19 12:55:40 Modified files: cm3/m3-sys/m3back/src/: Codex86.i3 Codex86.m3 M3x86.m3 Stackx86.i3 Stackx86.m3 Log message: atomic add, sub, xor of 32bit variables don't need to use compare/exchange loop (not enabled, not tested, odds of working slim, but it is in the right direction) From jkrell at elego.de Wed Oct 20 00:28:02 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 20 Oct 2010 0:28:02 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101019222804.7786BCC85A@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/20 00:28:02 Modified files: cm3/m3-sys/m3back/src/: M3x86.m3 Log message: xor is not reversible -- the new value is in memory and not atomically readable; only add/sub are reversible From jkrell at elego.de Wed Oct 20 09:47:36 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 20 Oct 2010 9:47:36 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101020074737.29882CC85B@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/20 09:47:36 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: typedef const char* PCSTR; typedef unsigned char UCHAR; typedef unsigned int UINT; typedef unsigned long ULONG; typedef unsigned HOST_WIDE_INT UWIDE; From jkrell at elego.de Wed Oct 20 11:37:23 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 20 Oct 2010 11:37:23 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101020093724.29F0ECC859@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/20 11:37:23 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: typedef char* PSTR; typedef HOST_WIDE_INT WIDE; #define WIDE_PRINT_HEX HOST_WIDE_INT_PRINT_HEX #define WIDE_PRINT_DEC HOST_WIDE_INT_PRINT_DEC From jkrell at elego.de Thu Oct 21 08:43:21 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 21 Oct 2010 8:43:21 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101021064321.B8D13CC127@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/21 08:43:21 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: cosmetic -- casts to ULONG in tracing, uppercase %lX in tracing, remove space in cast operator From jkrell at elego.de Thu Oct 21 09:14:49 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 21 Oct 2010 9:14:49 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101021071452.6BD352474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/21 09:14:48 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: remove whitespace from ends of lines From jkrell at elego.de Thu Oct 21 09:21:49 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 21 Oct 2010 9:21:49 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101021072149.CAC7CCC127@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/21 09:21:49 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: long => WIDE so that 32bit hosts can target 64bit and access fields/sizes beyond 2GB (some of these should probably be UWIDE but that ignored) From jkrell at elego.de Thu Oct 21 09:39:43 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 21 Oct 2010 9:39:43 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101021073943.D6F23CC127@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/21 09:39:43 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: add pointer_size and bits_per_unit visible in debugger, unlike the macros BITS_PER_UNIT, POINTER_SIZE From jkrell at elego.de Thu Oct 21 09:53:08 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 21 Oct 2010 9:53:08 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101021075309.0B94C2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/21 09:53:08 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: cosmetic; more substantial coming soon From jkrell at elego.de Thu Oct 21 12:45:19 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 21 Oct 2010 12:45:19 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101021104520.110052474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/21 12:45:19 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: exprerimental work in progress, but actually making progress (disabled here) added function m3_deduce_field_reference and it sometimes work note that it uses linear search, lame would be really great to do something else here.. fields should probably be given typeids, based on their containing record and name or offset, and then we can use binary search against all fields, OR fields should be given small indices 0..n per containing record struct lang_type could/should be brought to bear note that array references still have nothing done for them (even this m3_deduce_field_reference isn't really doing anything yet) widen current_record_size from ULONG to UWIDE so 32bit host can target 64bit and deal with large records (frontend is still broken here, due to use of INTEGER instead of Target.Int or LONGINT (32bit C implementations have had 64bit integers for something like 20 years now..) fix type comparison in load/store to account for the fact that we now have many pointer types -- make all pointer types compare equal change the level of indirection on pointers to records This might fix debugging them, not yet tested. From jkrell at elego.de Thu Oct 28 09:18:55 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 28 Oct 2010 9:18:55 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101028071855.EA73A2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/28 09:18:55 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: o => offset declare subranges properly work in progress: declare open arrays properly introduce UNSIGNED_INTEGER besides INTEGER among the marshaling macros -- that assert the value is >= 0 and use it a lot change more types to WIDE or UWIDE disabled prototype to find where type information is inadequate (e.g. open arrays) From jkrell at elego.de Fri Oct 29 21:13:43 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 29 Oct 2010 21:13:43 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101029191343.E3AE02474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/29 21:13:43 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: consider VIEW_CONVERT_EXPR for loophole From jkrell at elego.de Fri Oct 29 21:14:56 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 29 Oct 2010 21:14:56 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101029191456.210E42474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/29 21:14:56 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: m3gty43.h m3gty45.h Log message: I forgot to commit these files. From jkrell at elego.de Sun Oct 31 13:33:18 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 31 Oct 2010 13:33:18 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101031123318.EEADECC12B@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/31 13:33:18 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: loophole: for integer to integer, continue using cast otherwise, assert the types are equal size and use view_convert I looked at m3core and libm3, but I forget what happened in m3core, possibly nothing. In libm3, unoptimized, this affected only Transform.Hash and PickleStubs.SwapReal, both slightly positively. In the optimized case, this affected only Transform.Hash, a slight reordering but not any obvious improvement. (Maybe it is slightly faster but it isn't *obvious*.) loophole is of course rare. We might want to do similar in load/store, which will have bigger effect. From jkrell at elego.de Sun Oct 31 13:38:55 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 31 Oct 2010 13:38:55 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101031123855.86D2ECC12B@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/31 13:38:55 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: fix unfortunate gcc warnings From jkrell at elego.de Sun Oct 31 13:52:08 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 31 Oct 2010 13:52:08 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101031125208.8903BCC12B@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/31 13:52:08 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: m3gty45.h Log message: work in progress: in-memory deserialized form of m3cg, use a union, use the property gty annotations for union From jkrell at elego.de Sun Oct 31 14:14:47 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 31 Oct 2010 14:14:47 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101031131447.6A82BCC12B@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/31 14:14:47 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c m3gty43.h m3gty45.h Log message: remove all the type stuff, I'm not sure it will be structured that way From jkrell at elego.de Sun Oct 31 14:49:22 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 31 Oct 2010 14:49:22 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101031134922.AAE1FCC12B@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/31 14:49:22 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: -O3 is broken again disable some optimizations I checked and it didn't seem to be caused the loophole/view_convert change or the subrange declaration change. From jkrell at elego.de Sun Oct 31 14:58:13 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 31 Oct 2010 14:58:13 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101031135813.F165FCC12B@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/31 14:58:13 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: allow back a few optimizations From jkrell at elego.de Sun Oct 31 21:55:28 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 31 Oct 2010 21:55:28 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101031205528.C7B99CC12B@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/31 21:55:28 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: allow back a few more optimizations From jkrell at elego.de Sun Oct 31 23:09:42 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 31 Oct 2010 23:09:42 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101031220942.843F7CC12B@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/31 23:09:42 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: allow two more optimizations unfortunately, dead store elimination seems to be the problem dead store elimination is a nice sound optimization disabled prototype to use view_convert on load/store this seemed to break things From jkrell at elego.de Sun Oct 31 23:37:40 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 31 Oct 2010 23:37:40 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101031223740.B536CCC12B@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/31 23:37:40 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: alas: == package /Users/jay/dev2/cm3/m3-demo/fisheye == ../src/GraphData.m3: In function 'GraphData__ReadEdge': ../src/GraphData.m3:308:0: internal compiler error: in create_tmp_var, at gimplify.c:505 so disable a few optimizations again From jkrell at elego.de Fri Oct 1 12:58:36 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 1 Oct 2010 12:58:36 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101001105836.E7FF6CC125@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/01 12:58:36 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: Eliminate INTEGER vs. TARGET_INTEGER distinction. INTEGER is HOST_WIDE_INT which is at least 64bits when targeting 64bit. Equivalent to using LONGINT more instead of INTEGER. Typical 32bit C compilers have had 64bit long long/__int64 for something like 20 years now I think. (ok, at least 15, for certain) From jkrell at elego.de Fri Oct 1 13:03:46 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 1 Oct 2010 13:03:46 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101001110346.82CCBCC125@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/01 13:03:46 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: odd, go back a version From jkrell at elego.de Sat Oct 2 11:48:20 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 2 Oct 2010 11:48:20 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101002094820.BCA7C2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/02 11:48:20 Modified files: cm3/m3-sys/m3cc/gcc-4.5/gcc/: fixed-value.c Log message: gut file hardly used for Modula-3 backend, or I believe in most use of C backend as well From jkrell at elego.de Sat Oct 2 11:53:34 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 2 Oct 2010 11:53:34 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101002095334.A1BA42474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/02 11:53:34 Modified files: cm3/m3-sys/m3cc/gcc/gcc/: config.gcc config.in configure configure.ac hwint.h cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c cm3/m3-sys/m3cc/gcc-4.5/gcc/: config.gcc config.in configure configure.ac hwint.h cm3/m3-sys/m3cc/gcc-apple/gcc/: config.gcc config.in configure configure.ac hwint.h cm3/m3-sys/m3cc/src/: clean_marker.txt m3makefile Log message: small cleanup in target integer reading make sure HOST_WIDE_INT is always at least 64bits which was already the case on most targets anyway due to "biarch", the fact that x86 backends can target AMD64 with -m64 From jkrell at elego.de Sat Oct 2 12:36:50 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 2 Oct 2010 12:36:50 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101002103651.11B132474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/02 12:36:50 Modified files: cm3/m3-sys/m3cc/gcc-4.5/libiberty/: pex-common.h cm3/m3-sys/m3cc/gcc/libiberty/: pex-common.h Log message: #include for pid_t, for VMS see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44002 From jkrell at elego.de Sat Oct 2 12:39:20 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 2 Oct 2010 12:39:20 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101002103920.BCE322474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/02 12:39:20 Modified files: cm3/m3-sys/m3cc/gcc-apple/gcc/ginclude/: stddef.h cm3/m3-sys/m3cc/gcc/gcc/ginclude/: stddef.h Log message: Don't trash __size_t, on VMS. Already applied to 4.5. See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44003 From jkrell at elego.de Sat Oct 2 13:20:07 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 2 Oct 2010 13:20:07 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101002112007.5936E2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/02 13:20:07 Modified files: cm3/m3-sys/m3cc/gcc-4.5/gcc/: c-common.c cm3/m3-sys/m3cc/gcc-apple/gcc/: c-common.c cm3/m3-sys/m3cc/gcc/gcc/: c-common.c Log message: workaround ffs problem on VMS see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44037 From jkrell at elego.de Sat Oct 2 13:36:31 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 2 Oct 2010 13:36:31 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101002113631.3E8B42474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/02 13:36:31 Modified files: cm3/m3-sys/m3cc/gcc-4.5/gcc/: config.gcc cm3/m3-sys/m3cc/gcc-4.5/gcc/config/vms/: t-vms Added files: cm3/m3-sys/m3cc/gcc-4.5/gcc/config/vms/: vms-ucrt0.c Removed files: cm3/m3-sys/m3cc/gcc-4.5/gcc/config/vms/: t-vms64 vms-crt0-64.c vms-crt0.c vms-psxcrt0-64.c vms-psxcrt0.c Log message: VMS fixes from trunk see http://gcc.gnu.org/viewcvs/trunk/gcc/config/vms/t-vms?revision=164587&view=markup (i.e. for building C compiler here) From jkrell at elego.de Sat Oct 2 14:16:50 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 2 Oct 2010 14:16:50 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101002121650.897E42474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/02 14:16:50 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: again eliminate INTEGER vs. TARGET_INTEGER distinction INTEGER always suffices, TARGET_INTEGER is no more callers can call build_int_cst if they need a tree, as many but not all do 64bits is always enough I think the problem in previous attempt was the cast to long in get_int () where HOST_WIDE_INT is needed (32bits vs. 64bits) eliminate a little bit of 64bit math on 32bit hosts Though overall we overuse 64bit math on purpose. eliminate a little unnecessary signed math unsigned is generally preferred m3cg sign parameter is never used, in div/mod, adjust code accordingly (They used to be used to optimize our unusual div/mod operations, but now we always optimize; hm..could probably do better though, using the signs -- if both positive or both negative, use truncation, which is more commonly what the processors do?) eliminate some temporaries unoptimized code probably affected accordingly positively From jkrell at elego.de Sat Oct 2 15:17:30 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 2 Oct 2010 15:17:30 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101002131731.13D6A2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/02 15:17:30 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: tipe => type tipe is a Modula-3-ism, where "TYPE" is a reserved word? type is not a reserved word in C or C++ From jkrell at elego.de Sat Oct 2 15:21:28 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 2 Oct 2010 15:21:28 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101002132128.D65D62474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/02 15:21:28 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: t => type s => size a => align #if 0 unused function (avoid warning) #define foo bar when foo is just a function that calls bar From jkrell at elego.de Sat Oct 2 15:21:51 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 2 Oct 2010 15:21:51 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101002132151.DCAAE2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/02 15:21:51 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: a => align From jkrell at elego.de Sat Oct 2 15:37:04 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 2 Oct 2010 15:37:04 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101002133704.5BC832474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/02 15:37:04 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: rename variables whose name is just a single lowercase l to avoid ambiguity with the number 1 l => label l => length l => m (as in a, b, c, d, ..., j, k, m) From jkrell at elego.de Sun Oct 3 07:16:19 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 3 Oct 2010 7:16:19 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101003051620.010AD2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/03 07:16:19 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: 1 => true 0 => false or NULL but still intialize with the nice generic form { 0 } From jkrell at elego.de Sun Oct 3 07:17:13 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 3 Oct 2010 7:17:13 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101003051713.B9B822474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/03 07:17:13 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: go ahead and just always use 64bit math in get_int From jkrell at elego.de Sun Oct 3 07:18:20 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 3 Oct 2010 7:18:20 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101003051820.908BB2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/03 07:18:20 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: two missing spaces after function calls (formating) From jkrell at elego.de Sun Oct 3 07:21:24 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 3 Oct 2010 7:21:24 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101003052124.F1D892474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/03 07:21:24 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: no point to: #define NAME STRING just use STRING everywhere From jkrell at elego.de Sun Oct 3 08:38:34 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 3 Oct 2010 8:38:34 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101003063834.369152474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/03 08:38:34 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: enable debugging of enums, in stock gdb start code for debugging of globals, which are always embedded in global structs debugging of structs has the indirection off wrong, for example: t.r1 := 2; t.r2 := 3; t.r3 := 10; (gdb) p *t $4 = (struct Main.T1 *) 0xa32 oops. To be fixed shortly. There are probably many cases that don't debug correctly, because typenames, subranges, and esp. packing probably aren't handled correctly. The code is careful given an untyped integer, not to assign it a type of a different types. That is, when the frontend gives us: TYPE typecode = BITS 20 FOR [...] VAR tc:typecode; and it tells backend tc is a word32 of type typecode, we ignore the stronger type and just say it is word32. Not doing that was caused me a lot of grief/debugging/staring at code. Since this is a subrange and not an enum anyway, not clear we should do anything different. Subranges aren't really types, unless, e.g. you wanted the backend to generate the range checks (which isn't crazy, as it could optimize away redundant checks). As well, what does it mean: TYPE Color={Red,Blue}; TYPE T1 = BITS 2 FOR Color; TYPE T2 = BITS 8 FOR Color; TYPE T3 = BITS 800 FOR Color; Currently enum names are probably wrong, they show as Red, Blue in this example, probably should be Interface.Color.Red. same some pointer overhead in backend 0 => NULL a bit more add function m3_make_integer_type for maybe future use, that can create integers of any number of bits from 1 to 64 remove some more signed math From jkrell at elego.de Sun Oct 3 08:40:02 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 3 Oct 2010 8:40:02 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101003064002.3AEF72474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/03 08:40:02 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: remove growable and fixed size type table, just use VEC version From jkrell at elego.de Sun Oct 3 09:32:44 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 3 Oct 2010 9:32:44 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101003073244.AE4222474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/03 09:32:44 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: m3gty43.h m3gty45.h parse.c Log message: t => type id => typeid MTYPE2 => MTYPE where adequate From jkrell at elego.de Sun Oct 3 09:38:02 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 3 Oct 2010 9:38:02 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101003073802.D04B02474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/03 09:38:02 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: more manual tracing cleanup, not much manual tracing left now From jkrell at elego.de Sun Oct 3 10:00:48 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 3 Oct 2010 10:00:48 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101003080048.4D8AF2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/03 10:00:48 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: Darwin.common Log message: default to -g on Darwin, since there is no m3gdb to consume -gstabs From jkrell at elego.de Sun Oct 3 14:20:03 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 3 Oct 2010 14:20:03 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101003122003.B94562474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/03 14:20:03 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: read entire file into memory Even if the file is large, they usually aren't, our access pattern is linear, so virtual memory suffices. This can help with some possible simplifications and speedups, including the next item, which ends up separting the buffer from any file. To deal with circular types, which inhibit us from building good type information in one pass, introduce a mechanism where an opcode can request that it be "replayed"; still, some amount of type information must be created to make forward progress; this is not fully fleshed out yet; what we need to do be sure to create The node that will represent the types, even if we don't fill in its details until later; and then, later, retrieve the node, and fill in more. That is, during "replay", we must not create brand new nodes. e.g. records could be initially empty, then define all the types of their constituent fields, including perhaps pointers to the record itself, and then go back and fill in the fields In general, due to circularities, there is not an ordering that can work in one pass. There are multiple examples in the tree where the declarations come in in a non-working order (possibly there not being a working order). sortedtableextras, for example. To this end, of the "replay" feature, generally move "M3_TYPES" code ahead of the m3gdb code, to avoid the m3gdb code running twice, since I don't know if that will work. The m3gdb code will be deferred until the M3_TYPES code has enough information to complete. disable all type code for now put back all volatile because something is amiss neither of these edits are meant to last remove the mechanism for altering return types That which I recently cleaned up to stop widening return types. put in the missing builtin WIDECHAR Should this be in RTBuiltin.m3x? Put in UID_NULL as well. These last two get us somewhat more complete typeinfo, but there are still circularities we don't likely handle correctly yet. (Not to mention not handling the various array types correctly.) Use VOID_TYPE_P instead of comparison to t_void. Probably no difference in Modula-3, but we were already inconsistent. Make line number unsigned. From jay.krell at cornell.edu Sun Oct 3 14:39:01 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 3 Oct 2010 12:39:01 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20101003122003.B94562474003@birch.elegosoft.com> References: <20101003122003.B94562474003@birch.elegosoft.com> Message-ID: The problem was I declaring subranges to have the same type as their domain. Which would often make them too large. Which broke the sizes of fields. This should be better shortly. ?- Jay ---------------------------------------- > Date: Sun, 3 Oct 2010 14:20:03 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/10/03 14:20:03 > > Modified files: > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > Log message: > read entire file into memory > Even if the file is large, they usually aren't, > our access pattern is linear, so virtual memory suffices. > This can help with some possible simplifications and speedups, > including the next item, which ends up separting the > buffer from any file. > > To deal with circular types, which inhibit > us from building good type information in one pass, > introduce a mechanism where an opcode can request that it > be "replayed"; still, some amount of type information > must be created to make forward progress; this is not > fully fleshed out yet; what we need to do be sure to > create The node that will represent the types, even > if we don't fill in its details until later; and then, later, > retrieve the node, and fill in more. That is, during "replay", > we must not create brand new nodes. > > e.g. records could be initially empty, then define all the > types of their constituent fields, including perhaps pointers > to the record itself, and then go back and fill in the fields > In general, due to circularities, there is not an ordering > that can work in one pass. > > There are multiple examples in the tree where the declarations > come in in a non-working order (possibly there not being > a working order). sortedtableextras, for example. > > To this end, of the "replay" feature, generally move "M3_TYPES" code > ahead of the m3gdb code, to avoid the m3gdb code running twice, > since I don't know if that will work. > The m3gdb code will be deferred until the M3_TYPES code has enough > information to complete. > > disable all type code for now > put back all volatile > because something is amiss > neither of these edits are meant to last > > remove the mechanism for altering return types > That which I recently cleaned up to stop widening > return types. > > put in the missing builtin WIDECHAR > Should this be in RTBuiltin.m3x? > > Put in UID_NULL as well. > > These last two get us somewhat more complete typeinfo, > but there are still circularities we don't likely handle correctly yet. > (Not to mention not handling the various array types correctly.) > > Use VOID_TYPE_P instead of comparison to t_void. > Probably no difference in Modula-3, but we were already inconsistent. > > Make line number unsigned. > From jkrell at elego.de Sun Oct 3 20:28:48 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 3 Oct 2010 20:28:48 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101003182848.37BC52474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/03 20:28:48 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: fix subranges, to be small in size restore not volatile turn back on type code make it easy to turn on/off replay; turn it on remove assert that subrange min <= max, as it breaks X some small tweaks combine code for declare_pointer and declare_indirect consider using stabilize_reference more (after every indirect_ref remove temporaries from: shift rotate check_nil check_lo check_hi check_range check_eq very few temporaries remain: ones the frontend asks for (indefinite) floating point (round, floor, ceiling) loophole sometimes, pop_static_link, compare_exchange From jkrell at elego.de Mon Oct 4 01:21:44 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 4 Oct 2010 1:21:44 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101003232144.C9D6A2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/04 01:21:44 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: sprinkle stabilize_reference eveywhere it will likely save some recompution and is otherwise often a no-op From jkrell at elego.de Mon Oct 4 01:23:33 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 4 Oct 2010 1:23:33 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101003232333.4B8532474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/04 01:23:33 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: turn off the tracing about forward type references From jkrell at elego.de Mon Oct 4 01:29:51 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 4 Oct 2010 1:29:51 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101003232951.B60982474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/04 01:29:51 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: limit replay passes to 100 instead of hanging; in practise 1 seems to suffice, and they go very fast so 100 won't be a long lag (I know because an earlier version went forever, looking for end_unit to repeat) From jkrell at elego.de Mon Oct 4 11:59:56 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 4 Oct 2010 11:59:56 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101004095956.ACF542474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/04 11:59:56 Modified files: cm3/m3-libs/m3core/src/text/: TextLiteral.i3 Log message: allow larger TEXTs, breaking 32 to 64 bit cross builds, as they always were (frontend needs to be fixed to either use LONGINT or Target.Int, to enable the level of cross building that is normal in C and C++!) From jkrell at elego.de Mon Oct 4 20:56:04 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 4 Oct 2010 20:56:04 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101004185604.87F532474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/04 20:56:04 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: take advantage of the entire file being in memory and for strings, use a direct pointer into the buffer instead of copying byte by byte into alloca'ed buffer (which I think was malloced until recently) (note that access is no longer linear, if these strings are used much, they will bring into working set nearby unused data) and then the attendant reduction/elimination of nul terminated strings From jkrell at elego.de Mon Oct 4 21:06:58 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 4 Oct 2010 21:06:58 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101004190658.943072474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/04 21:06:58 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: missed a dependency on nul termination (beware strdup) From jkrell at elego.de Mon Oct 4 21:11:51 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 4 Oct 2010 21:11:51 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101004191152.319932474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/04 21:11:51 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: squeeze out a bit more nul termination inefficiency -- don't allocate room for it or copy it in From jkrell at elego.de Mon Oct 4 21:14:25 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 4 Oct 2010 21:14:25 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101004191425.84F202474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/04 21:14:25 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: grow some buffers from 100 to 256 (there's another one, but it should be growable and start small) From jkrell at elego.de Wed Oct 6 11:03:54 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 6 Oct 2010 11:03:54 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101006090354.BD40E2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/06 11:03:54 Modified files: cm3/m3-sys/m3cc/gcc/gcc/: ipa.c Log message: neuter 4.3 cgraph_remove_unreachable_nodes that doesn't like our trees From jkrell at elego.de Wed Oct 6 11:15:44 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 6 Oct 2010 11:15:44 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101006091544.B9B8F2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/06 11:15:44 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: turn off stablize_reference and all the type code, on SPARC32_SOLARIS (which is also volatile_all, and gcc 4.3) From jkrell at elego.de Wed Oct 6 11:16:59 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 6 Oct 2010 11:16:59 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101006091659.ABEDB2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/06 11:16:59 Modified files: cm3/m3-sys/m3cc/gcc/gcc/: ipa.c Log message: go back a version From jkrell at elego.de Wed Oct 6 11:22:57 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 6 Oct 2010 11:22:57 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101006092258.030BC2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/06 11:22:57 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: cleaner and add comment -- disabling all type code on SPARC32_SOLARIS From jkrell at elego.de Wed Oct 6 11:24:25 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 6 Oct 2010 11:24:25 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101006092425.208732474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/06 11:24:25 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: cleaner From jkrell at elego.de Wed Oct 6 11:31:54 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 6 Oct 2010 11:31:54 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101006093154.9D6F72474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/06 11:31:54 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: fix typo From jkrell at elego.de Wed Oct 6 12:45:43 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 6 Oct 2010 12:45:43 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101006104543.A18DB2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/06 12:45:43 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: -O3 breaks Solaris/sparc32 internally silently convert it to -O2, for this target only (when you run a bootstrap cm3 from -O3, the exception upon not finding cm3.cfg isn't dispatched correctly) From jkrell at elego.de Wed Oct 6 13:41:10 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 6 Oct 2010 13:41:10 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101006114110.CB7FA2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/06 13:41:10 Modified files: cm3/m3-libs/m3core/src/runtime/SOLgnu/: m3makefile Log message: use forward slash directly instead of SL From jkrell at elego.de Wed Oct 6 13:52:52 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 6 Oct 2010 13:52:52 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101006115252.B14D92474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/06 13:52:52 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: NetBSD.common Log message: also look in /usr/X11R7/lib in addition to /usr/X11R6/lib, as that is where things are on my 5.0.2 system (really should use $ORIGIN here..at least if on a 5.0+ system From jkrell at elego.de Wed Oct 6 14:03:27 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 6 Oct 2010 14:03:27 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101006120328.004A72474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/06 14:03:27 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: I386.common Log message: remove -mno-align-double I would really like the cm3cg command lines to be very cruft free, and this should no longer make a difference. Frontend aligns doubles to 8 bytes on all platforms, even though it could get away with 4 bytes on some e.g. x86. If there are any problems on any x86 platforms, try putting this back. It was especially painful at some point to debug this on Cygwin. Tested only I386_LINUX, but affects far more. From jkrell at elego.de Wed Oct 6 14:06:04 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 6 Oct 2010 14:06:04 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101006120604.E40F22474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/06 14:06:04 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: NT386.common Log message: remove -mno-align-double it should no longer matter But anyone using Cygwin or MinGW, beware! From jkrell at elego.de Wed Oct 6 14:08:08 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 6 Oct 2010 14:08:08 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101006120808.63F8D2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/06 14:08:08 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: AMD64.common AMD64_LINUX I386_LINUX.common Log message: remove -mno-align-double from m3back_flags and SYSTEM_CC Beware From jkrell at elego.de Wed Oct 6 14:47:22 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 6 Oct 2010 14:47:22 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101006124723.0AA192474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/06 14:47:22 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: NetBSD.common Log message: fix typo, now PklFonts can run From hosking at cs.purdue.edu Wed Oct 6 15:11:00 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 6 Oct 2010 09:11:00 -0400 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20101006090354.BD40E2474003@birch.elegosoft.com> References: <20101006090354.BD40E2474003@birch.elegosoft.com> Message-ID: <2E507E51-9600-47B0-8849-99297B3841E9@cs.purdue.edu> What's wrong with them? On 6 Oct 2010, at 11:03, Jay Krell wrote: > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/10/06 11:03:54 > > Modified files: > cm3/m3-sys/m3cc/gcc/gcc/: ipa.c > > Log message: > neuter 4.3 cgraph_remove_unreachable_nodes that doesn't like our trees From hosking at cs.purdue.edu Wed Oct 6 15:12:02 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 6 Oct 2010 09:12:02 -0400 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20101006104543.A18DB2474003@birch.elegosoft.com> References: <20101006104543.A18DB2474003@birch.elegosoft.com> Message-ID: This suggests we lost information about exception blocks. It used to work... On 6 Oct 2010, at 12:45, Jay Krell wrote: > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/10/06 12:45:43 > > Modified files: > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > Log message: > -O3 breaks Solaris/sparc32 > internally silently convert it to -O2, for this target only > (when you run a bootstrap cm3 from -O3, the exception upon > not finding cm3.cfg isn't dispatched correctly) From jay.krell at cornell.edu Wed Oct 6 15:20:33 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 6 Oct 2010 13:20:33 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <2E507E51-9600-47B0-8849-99297B3841E9@cs.purdue.edu> References: <20101006090354.BD40E2474003@birch.elegosoft.com>, <2E507E51-9600-47B0-8849-99297B3841E9@cs.purdue.edu> Message-ID: I don't know, but there are many obvious candidates. We don't generate much type information, and we generate now some incorrect type information (wrong level of pointers sometimes on structs) In this case, it was getting a null pointer: edit /dev2/cm3/m3-sys/m3cc/gcc/gcc/ipa.c line 164 ??? ? if (DECL_STRUCT_FUNCTION (decl)) configure -enable-checking still complains about many things. Though I have fixed some. ? Turning it on all the time makes things much slower and I think also actually breaks things (!). It doesn't like the bitfield refs, something about missing a "VUSE". ?? Maybe volatile would be the better tradeoff?? It doesn't like various expressions that mix integer types. ? These shouldn't be hard to fix, and I have fixed some. ? They included that we were mixing up the return types of all functions that return ?? integers smaller than a word. It complains about the module initializers confusing structs and struct pointers in their return type. However I think not using the bitfield refs generates incorrect code now. ?ie: when I address configure -enable-checking, I get bad code. ? I have to look into this more. The configure -enable-checking problems seem to be somewhat large and very long standing. Configure -enable-checking also complains something about our use of static chain. It was hard enough just to get the static chain working 4.5...I don't look forward to understanding also figuring out why configure enable-checking doesn't like it. ?- Jay ---------------------------------------- > From: hosking at cs.purdue.edu > Date: Wed, 6 Oct 2010 09:11:00 -0400 > To: jkrell at elego.de > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > What's wrong with them? > > On 6 Oct 2010, at 11:03, Jay Krell wrote: > > > CVSROOT: /usr/cvs > > Changes by: jkrell at birch. 10/10/06 11:03:54 > > > > Modified files: > > cm3/m3-sys/m3cc/gcc/gcc/: ipa.c > > > > Log message: > > neuter 4.3 cgraph_remove_unreachable_nodes that doesn't like our trees > From hosking at cs.purdue.edu Wed Oct 6 15:28:05 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 6 Oct 2010 09:28:05 -0400 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20101006090354.BD40E2474003@birch.elegosoft.com>, <2E507E51-9600-47B0-8849-99297B3841E9@cs.purdue.edu> Message-ID: <4E2BB803-F603-4D9B-8E06-6B7D73CC7392@cs.purdue.edu> On 6 Oct 2010, at 09:20, Jay K wrote: > I don't know, but there are many obvious candidates. > We don't generate much type information, and we generate now some incorrect type information (wrong level > of pointers sometimes on structs) > In this case, it was getting a null pointer: > edit /dev2/cm3/m3-sys/m3cc/gcc/gcc/ipa.c line 164 > if (DECL_STRUCT_FUNCTION (decl)) > > > configure -enable-checking still complains about many things. Though I have fixed some. Yes, this has been most helpful. I would like to push it further but don't currently have the time. > Turning it on all the time makes things much slower and I think also actually breaks things (!). Yikes, really? > It doesn't like the bitfield refs, something about missing a "VUSE". > Maybe volatile would be the better tradeoff?? I think ultimately we should be good gcc citizens and generate proper type information. Then we can use properly named symbolic bitfield references. (So long as we can ensure that the front-end and back-end agree on layout.) > It doesn't like various expressions that mix integer types. > These shouldn't be hard to fix, and I have fixed some. > They included that we were mixing up the return types of all functions that return > integers smaller than a word. RIght. > It complains about the module initializers confusing structs and struct pointers in their return type. Should be fixable. > However I think not using the bitfield refs generates incorrect code now. > ie: when I address configure -enable-checking, I get bad code. > I have to look into this more. Sigh. > The configure -enable-checking problems seem to be somewhat large and very long standing. > > > Configure -enable-checking also complains something about our use of static chain. > It was hard enough just to get the static chain working 4.5...I don't look forward to > understanding also figuring out why configure enable-checking doesn't like it. Hmm. Do we know what Pascal/Ada/D and friends do in this instance? > > > - Jay > > ---------------------------------------- >> From: hosking at cs.purdue.edu >> Date: Wed, 6 Oct 2010 09:11:00 -0400 >> To: jkrell at elego.de >> CC: m3commit at elegosoft.com >> Subject: Re: [M3commit] CVS Update: cm3 >> >> What's wrong with them? >> >> On 6 Oct 2010, at 11:03, Jay Krell wrote: >> >>> CVSROOT: /usr/cvs >>> Changes by: jkrell at birch. 10/10/06 11:03:54 >>> >>> Modified files: >>> cm3/m3-sys/m3cc/gcc/gcc/: ipa.c >>> >>> Log message: >>> neuter 4.3 cgraph_remove_unreachable_nodes that doesn't like our trees >> > From jay.krell at cornell.edu Wed Oct 6 15:26:52 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 6 Oct 2010 13:26:52 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20101006104543.A18DB2474003@birch.elegosoft.com>, Message-ID: -O3 definitely worked on Solaris/sparc32? None of the optimization flags get tested in Hudson. I don't test Solaris/sparc32 much -- local machine is slow, network seems slow using remote machines. ?- Jay ---------------------------------------- > From: hosking at cs.purdue.edu > Date: Wed, 6 Oct 2010 09:12:02 -0400 > To: jkrell at elego.de > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > This suggests we lost information about exception blocks. It used to work... > > On 6 Oct 2010, at 12:45, Jay Krell wrote: > > > CVSROOT: /usr/cvs > > Changes by: jkrell at birch. 10/10/06 12:45:43 > > > > Modified files: > > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > > > Log message: > > -O3 breaks Solaris/sparc32 > > internally silently convert it to -O2, for this target only > > (when you run a bootstrap cm3 from -O3, the exception upon > > not finding cm3.cfg isn't dispatched correctly) > From jay.krell at cornell.edu Wed Oct 6 15:40:03 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 6 Oct 2010 13:40:03 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <4E2BB803-F603-4D9B-8E06-6B7D73CC7392@cs.purdue.edu> References: <20101006090354.BD40E2474003@birch.elegosoft.com>, <2E507E51-9600-47B0-8849-99297B3841E9@cs.purdue.edu> , <4E2BB803-F603-4D9B-8E06-6B7D73CC7392@cs.purdue.edu> Message-ID: > I think ultimately we should be good gcc citizens and generate proper type information Me too, but it is a can of worms. It is hard to get from current situation to typeful situation in small working steps. I don't have a long attention span, it is difficult to get through large items.. > Then we can use properly named symbolic bitfield references Field/component references. The underlying field will have one of any type: integer, float, pointer, bitfield, etc. We can use this for records, objects, arrays. > > Turning it on all the time makes things much slower and I think also actually breaks things (!). > > Yikes, really? It definitely slows things down. I'm pretty sure when I don't use bitfield refs, I get bad code. I have to try again. I don't have things well automated in terms of keeping around various configurations and easily switching them, and I often go overboard and build too much and don't do a good job of reducing the problem, but "stare" at too much. What I should do is like, binary search where the variable is which compiler and the data being "searched" is, say, all of m3core. And then once the difference found, have to see why the compiler made the decision. I haven't debugged the compiler much. I don't know its domain -- ssa, vdefs, vuses, etc. > > It complains about the module initializers confusing structs and struct pointers in their return type. > > Should be fixable. Yes. Thing is. I have to test each change both with and without configure enable-checking. I rely too much on scripts..end up rebuilding backend more than needed (much quicker now with gmp reduced!) > Hmm. Do we know what Pascal/Ada/D and friends do in this instance? Good point. I don't know. Could be they let gcc use its regular trampolines. Which has advantages and disadvantages. But I don't know. (advantages: leaves the work/maintanence to mainline gcc, more interopable with C; disadvantages: doesn't work on all platforms, is slower (mprotect on some platforms) and faster (no need to check for the marker)). But I don't know. I'd be in favor of transforming this away in the frontend, or maybe in parse.c. It does require more or less dataflow analysis to see which locals/parameters ared used by nested functions, which is probably easy to make a safe guess at, but then difficult to make an optimized guess at. i.e. you'd end up reserving space for and storing locals/parameters that are then not used. ?- Jay ---------------------------------------- > Subject: Re: [M3commit] CVS Update: cm3 > From: hosking at cs.purdue.edu > Date: Wed, 6 Oct 2010 09:28:05 -0400 > CC: jkrell at elego.de; m3commit at elegosoft.com > To: jay.krell at cornell.edu > > On 6 Oct 2010, at 09:20, Jay K wrote: > > > I don't know, but there are many obvious candidates. > > We don't generate much type information, and we generate now some incorrect type information (wrong level > > of pointers sometimes on structs) > > In this case, it was getting a null pointer: > > edit /dev2/cm3/m3-sys/m3cc/gcc/gcc/ipa.c line 164 > > if (DECL_STRUCT_FUNCTION (decl)) > > > > > > configure -enable-checking still complains about many things. Though I have fixed some. > > Yes, this has been most helpful. I would like to push it further but don't currently have the time. > > > Turning it on all the time makes things much slower and I think also actually breaks things (!). > > Yikes, really? > > > It doesn't like the bitfield refs, something about missing a "VUSE". > > Maybe volatile would be the better tradeoff?? > > I think ultimately we should be good gcc citizens and generate proper type information. Then we can use properly named symbolic bitfield references. (So long as we can ensure that the front-end and back-end agree on layout.) > > > It doesn't like various expressions that mix integer types. > > These shouldn't be hard to fix, and I have fixed some. > > They included that we were mixing up the return types of all functions that return > > integers smaller than a word. > > RIght. > > > It complains about the module initializers confusing structs and struct pointers in their return type. > > Should be fixable. > > > However I think not using the bitfield refs generates incorrect code now. > > ie: when I address configure -enable-checking, I get bad code. > > I have to look into this more. > > Sigh. > > > The configure -enable-checking problems seem to be somewhat large and very long standing. > > > > > > Configure -enable-checking also complains something about our use of static chain. > > It was hard enough just to get the static chain working 4.5...I don't look forward to > > understanding also figuring out why configure enable-checking doesn't like it. > > Hmm. Do we know what Pascal/Ada/D and friends do in this instance? > > > > > > > - Jay > > > > ---------------------------------------- > >> From: hosking at cs.purdue.edu > >> Date: Wed, 6 Oct 2010 09:11:00 -0400 > >> To: jkrell at elego.de > >> CC: m3commit at elegosoft.com > >> Subject: Re: [M3commit] CVS Update: cm3 > >> > >> What's wrong with them? > >> > >> On 6 Oct 2010, at 11:03, Jay Krell wrote: > >> > >>> CVSROOT: /usr/cvs > >>> Changes by: jkrell at birch. 10/10/06 11:03:54 > >>> > >>> Modified files: > >>> cm3/m3-sys/m3cc/gcc/gcc/: ipa.c > >>> > >>> Log message: > >>> neuter 4.3 cgraph_remove_unreachable_nodes that doesn't like our trees > >> > > > From jkrell at elego.de Wed Oct 6 16:20:18 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 6 Oct 2010 16:20:18 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101006142018.A76712474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/06 16:20:18 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: SPARC64.common Log message: just remove the second trailing newline From jkrell at elego.de Wed Oct 6 16:20:36 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 6 Oct 2010 16:20:36 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101006142036.6D7562474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/06 16:20:36 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: SPARC.common SPARC32_LINUX Log message: just remove the second trailing newline From jay.krell at cornell.edu Wed Oct 6 16:24:41 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 6 Oct 2010 14:24:41 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20101006142036.6D7562474003@birch.elegosoft.com> References: <20101006142036.6D7562474003@birch.elegosoft.com> Message-ID: darnit, that was supposed to be diff, not commit I'm still testing it. What it really is is: ? use -K PIC on SPARC32_LINUX assembler (to be matched in pylib.py) ? use -mno-app-regs in m3back_flags and gcc (also to be matched in pylib.py, for Linux, I have to check the Sun cc flags) ? remove unnecessary flags about double alignment I frequently see a problem where -fPIC breaks cross cm3. It might be this -K PIC or -mno-app-regs. And I'm seeing SPARC32_LINUX fail early with gcc 4.5. Might be these. These might also explain SPARC32_SOLARIS problems. I'm still testing. For some reason I only noticed -mno-app-regs when working on SPARC64, but it seems to maybe related to SPARC32 also. ?- Jay ---------------------------------------- > Date: Wed, 6 Oct 2010 16:20:36 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/10/06 16:20:36 > > Modified files: > cm3/m3-sys/cminstall/src/config-no-install/: SPARC.common > SPARC32_LINUX > > Log message: > just remove the second trailing newline > From jkrell at elego.de Wed Oct 6 16:44:45 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 6 Oct 2010 16:44:45 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101006144445.7917F2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/06 16:44:45 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: SPARC.common SPARC32_LINUX SPARC64_LINUX SPARC64_OPENBSD Log message: work in progress (or possibly done) on pic/regs flags (SPARC64 less actively tested!) From jkrell at elego.de Wed Oct 6 16:52:09 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 6 Oct 2010 16:52:09 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101006145220.2B07C2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/06 16:52:09 Modified files: cm3/scripts/python/: pylib.py Log message: fidget with pic/app-regs flags -- looking better for SPARC32_LINUX but still not for SPARC32_SOLARIS From hosking at cs.purdue.edu Wed Oct 6 16:50:30 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 6 Oct 2010 10:50:30 -0400 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20101006104543.A18DB2474003@birch.elegosoft.com>, Message-ID: <074A9418-7240-4678-B3CE-C98C2C8B1908@cs.purdue.edu> Yes, at some point in the past 5 years it worked on Solaris/Sparc32. Not sure when... :-( On 6 Oct 2010, at 09:26, Jay K wrote: > > -O3 definitely worked on Solaris/sparc32? > None of the optimization flags get tested in Hudson. > I don't test Solaris/sparc32 much -- local machine is slow, network seems slow using remote machines. > > - Jay > > ---------------------------------------- >> From: hosking at cs.purdue.edu >> Date: Wed, 6 Oct 2010 09:12:02 -0400 >> To: jkrell at elego.de >> CC: m3commit at elegosoft.com >> Subject: Re: [M3commit] CVS Update: cm3 >> >> This suggests we lost information about exception blocks. It used to work... >> >> On 6 Oct 2010, at 12:45, Jay Krell wrote: >> >>> CVSROOT: /usr/cvs >>> Changes by: jkrell at birch. 10/10/06 12:45:43 >>> >>> Modified files: >>> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c >>> >>> Log message: >>> -O3 breaks Solaris/sparc32 >>> internally silently convert it to -O2, for this target only >>> (when you run a bootstrap cm3 from -O3, the exception upon >>> not finding cm3.cfg isn't dispatched correctly) >> > From jkrell at elego.de Wed Oct 6 16:59:40 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 6 Oct 2010 16:59:40 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101006145940.566F42474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/06 16:59:40 Modified files: cm3/m3-sys/m3cc/src/: m3makefile Log message: move SPARC32_LINUX to gcc 4.5.1 backend still testing but looking ok, bootstrap cm3 runs ok move I386_OPENBSD to gcc 4.5.1 backend I think I tested it. It is the only I386 target not moved. move MIPS64_OPENBSD to gcc 4.5.1 backend Not tested. This platform hasn't really arrived and isn't very likely -- SGI hardware, which I do have.. move MIPS64EL_OPENBSD to gcc 4.5.1 backend. Not tested. Much more viable than MIPS64_OPENBSD as there is recently developed laptops running it (yes, I have one). (They run Linux too.) From jay.krell at cornell.edu Wed Oct 6 17:06:03 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 6 Oct 2010 15:06:03 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <074A9418-7240-4678-B3CE-C98C2C8B1908@cs.purdue.edu> References: <20101006104543.A18DB2474003@birch.elegosoft.com>, , , , <074A9418-7240-4678-B3CE-C98C2C8B1908@cs.purdue.edu> Message-ID: Let me maybe get 4.5.1 working before -O3. Granted..I agree it was probably working as recently as the recent release. What changed since then? In the 4.3 tree? ==> I moved from 4.3.0 to 4.3.5. So if we want to find -O3 working, it is probably there. ?- Jay ---------------------------------------- > From: hosking at cs.purdue.edu > Date: Wed, 6 Oct 2010 10:50:30 -0400 > To: jay.krell at cornell.edu > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > Yes, at some point in the past 5 years it worked on Solaris/Sparc32. Not sure when... :-( > > On 6 Oct 2010, at 09:26, Jay K wrote: > > > > > -O3 definitely worked on Solaris/sparc32? > > None of the optimization flags get tested in Hudson. > > I don't test Solaris/sparc32 much -- local machine is slow, network seems slow using remote machines. > > > > - Jay > > > > ---------------------------------------- > >> From: hosking at cs.purdue.edu > >> Date: Wed, 6 Oct 2010 09:12:02 -0400 > >> To: jkrell at elego.de > >> CC: m3commit at elegosoft.com > >> Subject: Re: [M3commit] CVS Update: cm3 > >> > >> This suggests we lost information about exception blocks. It used to work... > >> > >> On 6 Oct 2010, at 12:45, Jay Krell wrote: > >> > >>> CVSROOT: /usr/cvs > >>> Changes by: jkrell at birch. 10/10/06 12:45:43 > >>> > >>> Modified files: > >>> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > >>> > >>> Log message: > >>> -O3 breaks Solaris/sparc32 > >>> internally silently convert it to -O2, for this target only > >>> (when you run a bootstrap cm3 from -O3, the exception upon > >>> not finding cm3.cfg isn't dispatched correctly) > >> > > > From rodney_bates at lcwb.coop Wed Oct 6 21:51:06 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Wed, 06 Oct 2010 14:51:06 -0500 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20101006090354.BD40E2474003@birch.elegosoft.com>, <2E507E51-9600-47B0-8849-99297B3841E9@cs.purdue.edu> , <4E2BB803-F603-4D9B-8E06-6B7D73CC7392@cs.purdue.edu> Message-ID: <4CACD32A.6030906@lcwb.coop> Jay K wrote: --snip-- > > (Tony)>> Hmm. Do we know what Pascal/Ada/D and friends do in this instance? > > > Good point. I don't know. > Could be they let gcc use its regular trampolines. > Which has advantages and disadvantages. But I don't know. > (advantages: leaves the work/maintanence to mainline gcc, more interopable with C; disadvantages: > doesn't work on all platforms, is slower (mprotect on some platforms) and faster (no need > to check for the marker)). > But I don't know. > I'd be in favor of transforming this away in the frontend, or maybe in parse.c. > It does require more or less dataflow analysis to see which locals/parameters ared used by nested functions, > which is probably easy to make a safe guess at, but then difficult to make an optimized guess at. > i.e. you'd end up reserving space for and storing locals/parameters that are then not used. > tree-nested.c in gcc now does this. There is extensive tree-rewriting as a result. Local variables and parameters that are accessed nonlocally (i.e., from within a more deeply-nested procedure) are collected into a record, which is then placed as a local variable. It can be accessed by two different static links, located in different places. I forget all the details. I understood it once. There are a _lot_ of multiple copies of things, duplicate copies of parameters passed by value, duplicate pointers to things passed by reference, etc. I think there can even be three copies of these things. It all leads to activation record expansion and extra code executed in prologs and in accessing things. The apparent reason is that it greatly simplifies the compile-time interaction among nested procedures, nonlocal access, and inlining. The generated record of nonlocally-accessed stuff doesn't have to be known to be located inside any particular activation record, and with inlining, it may not be. Or something like that. Note that this is all about ordinary nonlocal accesses from nested procedures, which use neither trampolines nor closures. The latter are only used when creating and using parameters of procedure type, whose runtime values can sometimes be nested procedures. This is largely independent of static links, etc. The trampolines/closures are only a way of storing static link values in formals of procedure type. Where the values come from before they are stored and where they go and how they are used after they are extracted is independent. For static links themselves, the runtime model is the same for C and Modula-3 code. > > - Jay From jkrell at elego.de Thu Oct 7 09:46:56 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 7 Oct 2010 9:46:56 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101007074657.0BCC82474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/07 09:46:56 Modified files: cm3/m3-sys/m3cc/src/: m3makefile Log message: switch AMD64_SOLARIS to gcc 4.5.1 backend It worked far enough to build and run a cross/boot cm3. workaround http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45927 From jkrell at elego.de Thu Oct 7 11:46:14 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 7 Oct 2010 11:46:14 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101007094614.813842474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/07 11:46:14 Modified files: cm3/scripts/: pkgmap.sh cm3/scripts/regression/: hudson_build_system.sh Log message: instrumentation: try to find when the PPC_LINUX directory permisions get broken, if indeed it is even within here; maybe should reinstall OS... From jkrell at elego.de Thu Oct 7 12:40:53 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 7 Oct 2010 12:40:53 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101007104055.714A12474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/07 12:40:53 Modified files: cm3/m3-sys/m3cc/src/: gnucc.common Log message: gcc 3.4.3 can't compile gcc 4.5.1 targeting AMD64_SOLARIS see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45929 It would be nice to split up the files for portability. So favor gcc 4.x on the opencsw machines, where we can find it. When doing native AMD64_SOLARIS builds. Other folks will have to modify $PATH. Note that cc in path should and I think also does take precedence. We generally favor Sun cc. Eh? From jkrell at elego.de Thu Oct 7 13:26:28 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 7 Oct 2010 13:26:28 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101007112628.E76FA2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/07 13:26:28 Modified files: cm3/m3-sys/m3cc/gcc-4.5/gcc/config/sparc/: sparc.h Log message: Duh! #define TARGET_SPARC 1 like for 4.3.5 to trigger volatile madness in parse.c. From jkrell at elego.de Thu Oct 7 13:50:37 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 7 Oct 2010 13:50:37 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101007115038.171202474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/07 13:50:37 Modified files: cm3/m3-sys/m3cc/gcc-4.5/gcc/config/: sol2.h cm3/m3-sys/m3cc/gcc-apple/gcc/config/: sol2.h cm3/m3-sys/m3cc/gcc-apple/gcc/config/sparc/: sparc.h Log message: Duh! #define TARGET_SOLARIS 1 also and follow suit in gcc-apple for no reason. From jkrell at elego.de Thu Oct 7 14:22:13 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 7 Oct 2010 14:22:13 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101007122213.CB3F72474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/07 14:22:13 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: safe keeping: use volatile more consistently and more often From jkrell at elego.de Thu Oct 7 14:22:37 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 7 Oct 2010 14:22:37 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101007122238.19F0C2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/07 14:22:37 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: go back a version From jkrell at elego.de Sat Oct 9 13:36:40 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 9 Oct 2010 13:36:40 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101009113640.971012474032@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/09 13:36:40 Modified files: cm3/m3-sys/m3cc/src/: m3makefile Log message: cleanup the "NOACTION" feature, by wrapping the whole thing in a function and using early return NOTE: This would also be perfectly clean and natural using goto. Goto is not evil! Compare it to the contortions people go through to avoid it. Those are evil. It would be evil to not have the option of if/else/switch/for/while/break/continue, but not having goto is also evil. let PREBUILT_CM3CG work with cross builds, by copying to build_dir instead of just dot (move the code down to after build_dir is computed/created) PREBUILT_CM3CG doesn't use $WORKSPACE but requires it be set. Why? To avoid honoring it in other random settings? Let PREBUILT_CM3CG also work if $USER = jay. Really: we should not be defining our own environment variables that don't start with CM3_! Even that isn't great. And we should try to use cm3 -D options instead? Environment variables are fairly flat namespace (though you can use underscores and long names) and they flow into unrelated processes, so perhaps to be avoided. However they also flow automatically into child processes, which can be good, when you don't control the command lines all the way through. (It turns out, there's just no perfect solution here. You can also store configuration state globally like in files or registry, but then you can't scope it to a particular process or process tree. A good hybrid, if there is much parameters/state, is stash it in a temporary file/directory, and put that file/directory path in an environment variable -- ie: use just one environment variable). From jkrell at elego.de Wed Oct 13 13:18:53 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 13 Oct 2010 13:18:53 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101013111853.858402474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/13 13:18:53 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: SPARC32_SOLARIS.common cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c cm3/m3-sys/m3cc/gcc-4.5/gcc/: function.c cm3/m3-sys/m3cc/src/: clean_marker.txt m3makefile cm3/m3-sys/m3middle/src/: Target.m3 cm3/m3-libs/m3core/src/runtime/: m3makefile Added files: cm3/m3-libs/m3core/src/runtime/SOLgnu/: m3makefile-old cm3/m3-libs/m3core/src/runtime/SOLsun/: m3makefile-old Removed files: cm3/m3-libs/m3core/src/runtime/SOLgnu/: m3makefile cm3/m3-libs/m3core/src/runtime/SOLsun/: m3makefile Log message: disable Solaris/sparc32 stack walker switch Solaris/sparc32 to gcc 4.5 backend function.c: make failure to volatilize when setjmp/vfork present an error instead of a warning add missing volatilization pin Solaris/sparc32 at -O1 in the config file as -O2/-O3 were seen to hit internal compiler errors (assertion failures) remove the "all volatile" paths from parse.c (since they were only for Solaris/sparc32's stack walker) From jkrell at elego.de Wed Oct 13 17:57:26 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 13 Oct 2010 17:57:26 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101013155726.A77D82474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/13 17:57:26 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: SPARC32_SOLARIS.common Log message: let it be -O3 From jkrell at elego.de Wed Oct 13 18:01:48 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 13 Oct 2010 18:01:48 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101013160148.7F09E2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/13 18:01:48 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: SPARC32_SOLARIS.common Log message: go back a version: unresolved symbols, probably we can just disable a small number of optimizations though From jkrell at elego.de Wed Oct 13 18:10:32 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 13 Oct 2010 18:10:32 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101013161032.360432474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/13 18:10:32 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: SPARC32_SOLARIS.common Log message: cm3 bootstapped ok with -O2 so let's try that From jkrell at elego.de Wed Oct 13 18:29:30 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 13 Oct 2010 18:29:30 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101013162930.C4BEBCC123@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/13 18:29:30 Modified files: cm3/scripts/python/: pylib.py Log message: experimental: don't set M3CONFIG into the source tree; e.g. so we can upgrade from SOLsun with stack walker to without From jkrell at elego.de Wed Oct 13 18:31:22 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 13 Oct 2010 18:31:22 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101013163122.D21FB2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/13 18:31:22 Modified files: cm3/scripts/regression/: hudson_build_system.sh Log message: fix plin instrumentation that broke everything From jkrell at elego.de Wed Oct 13 18:31:53 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 13 Oct 2010 18:31:53 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101013163153.5CD452474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/13 18:31:53 Modified files: cm3/scripts/regression/: hudson_build_system.sh Log message: fix plin instrumentation that broke everything From jkrell at elego.de Wed Oct 13 18:32:31 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 13 Oct 2010 18:32:31 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101013163231.B282D2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/13 18:32:31 Modified files: cm3/scripts/: pkgmap.sh Log message: fix plin instrumentation that broke everything From jkrell at elego.de Sat Oct 16 07:33:41 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 16 Oct 2010 7:33:41 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101016053341.AACB3CC362@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/16 07:33:41 Modified files: cm3/scripts/win/: cvs.c Log message: remove wcscmp use and tabs From jkrell at elego.de Sat Oct 16 08:20:00 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 16 Oct 2010 8:20:00 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101016062000.353F9CC124@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/16 08:20:00 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Added files: cm3/m3-sys/m3back/src/: M3C.i3 Log message: work in progress From jkrell at elego.de Sat Oct 16 10:39:30 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 16 Oct 2010 10:39:30 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101016083930.C2BEFCC124@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/16 10:39:30 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: work in progress From jkrell at elego.de Sat Oct 16 10:42:41 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 16 Oct 2010 10:42:41 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101016084242.290E82474010@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/16 10:42:41 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: work in progress From jkrell at elego.de Sat Oct 16 11:24:39 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 16 Oct 2010 11:24:39 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101016092439.DC8A32474010@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/16 11:24:39 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: work in progress: it compiles and has a few lines of real code, but is missing *a lot* From jkrell at elego.de Sat Oct 16 11:27:27 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 16 Oct 2010 11:27:27 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101016092727.85D802474010@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/16 11:27:27 Modified files: cm3/m3-sys/m3back/src/: M3C.i3 m3makefile Log message: compile nascent C backend again, there is almost nothing actually here From jkrell at elego.de Sat Oct 16 12:16:12 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 16 Oct 2010 12:16:12 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101016101613.0F2CB2474010@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/16 12:16:12 Modified files: cm3/m3-libs/m3core/src/C/Common/: CstdioC.c CstdlibC.c CstringC.c cm3/m3-libs/m3core/src/Csupport/Common/: dtoa.h hand.c cm3/m3-libs/m3core/src/runtime/WIN32/: RTOSc.c cm3/m3-libs/m3core/src/runtime/common/: RTIOc.c RTMiscC.c RTUntracedMemoryC.c cm3/m3-libs/m3core/src/runtime/ex_frame/: RTStackC.c cm3/m3-libs/m3core/src/thread/WIN32/: ThreadWin32C.c cm3/m3-libs/m3core/src/unix/Common/: Uexec.c Uin.c Unetdb.c UnixC.c UnixLink.c Uprocess.c UtimeC.c Uuio.c cm3/m3-libs/sysutils/src/: SystemC.c Log message: Remove the _DLL/_MT hacking that I had put in, which purported to let one set of object code link with either msvcrt.lib or libcmt.lib. Not a bad idea, not a bad implementation, but a bit on the unsupported side. If user really wants to use libcmt.lib, he should modify the config file and rebuild everything (esp. m3core). We should possibly make such a configuration in Hudson. We should possibly automatically multiply out compile/link for any directories that contain any C? And then build_standalone could imply libmt.lib. Not a bad idea, but unlikely to happen. From jkrell at elego.de Sat Oct 16 12:19:53 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 16 Oct 2010 12:19:53 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101016101953.0DFD12474010@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/16 12:19:53 Modified files: cm3/m3-libs/m3core/src/runtime/common/: RTUntracedMemoryC.c Log message: remove K&R From jkrell at elego.de Sat Oct 16 12:22:17 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 16 Oct 2010 12:22:17 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101016102219.259E22474010@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/16 12:22:17 Modified files: cm3/m3-libs/m3core/src/: m3core.h Log message: move up #ifdef _MSC_VER #pragma warning(disable...) in order to quash: ../..\m3core.h(33) : warning C4668: '__GNUC__' is not defined as a preprocessor macro, replacing with '0' for '#if/#elif' when compiling with -Wall From jay.krell at cornell.edu Sat Oct 16 12:17:24 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 16 Oct 2010 10:17:24 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20101016101613.0F2CB2474010@birch.elegosoft.com> References: <20101016101613.0F2CB2474010@birch.elegosoft.com> Message-ID: diff attached ---------------------------------------- > Date: Sat, 16 Oct 2010 12:16:12 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/10/16 12:16:12 > > Modified files: > cm3/m3-libs/m3core/src/C/Common/: CstdioC.c CstdlibC.c > CstringC.c > cm3/m3-libs/m3core/src/Csupport/Common/: dtoa.h hand.c > cm3/m3-libs/m3core/src/runtime/WIN32/: RTOSc.c > cm3/m3-libs/m3core/src/runtime/common/: RTIOc.c RTMiscC.c > RTUntracedMemoryC.c > cm3/m3-libs/m3core/src/runtime/ex_frame/: RTStackC.c > cm3/m3-libs/m3core/src/thread/WIN32/: ThreadWin32C.c > cm3/m3-libs/m3core/src/unix/Common/: Uexec.c Uin.c Unetdb.c > UnixC.c UnixLink.c > Uprocess.c UtimeC.c Uuio.c > cm3/m3-libs/sysutils/src/: SystemC.c > > Log message: > Remove the _DLL/_MT hacking that I had put in, > which purported to let one set of object code > link with either msvcrt.lib or libcmt.lib. > > Not a bad idea, not a bad implementation, but > a bit on the unsupported side. > > If user really wants to use libcmt.lib, he should > modify the config file and rebuild everything (esp. m3core). > We should possibly make such a configuration in Hudson. > We should possibly automatically multiply out compile/link > for any directories that contain any C? And then build_standalone > could imply libmt.lib. Not a bad idea, but unlikely to happen. > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 1.txt URL: From jkrell at elego.de Sat Oct 16 12:26:02 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 16 Oct 2010 12:26:02 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101016102602.24D902474010@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/16 12:26:02 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: test_hand.c Log message: add __fastcall versions of set_member, set_singleton: point being to read the code and have m3back use it instead of what currently does, which is very very well size optimized but not very well speed optimized, since the instruction it uses imply an interlock, unfortunate From jkrell at elego.de Sat Oct 16 12:31:20 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 16 Oct 2010 12:31:20 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101016103120.88EE32474010@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/16 12:31:20 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: remove comments that say set_member and set_singleton are never used, as I'm inclined at least temporary to go back to function calls From jkrell at elego.de Sat Oct 16 12:39:59 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 16 Oct 2010 12:39:59 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101016104003.9F8622474010@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/16 12:39:59 Modified files: cm3/m3-sys/m3back/src/: M3x86.m3 Log message: go back to function calls for set_member and set_range The inline code was wonderfully small, but unfortunately had an implied and unremovable interlock, which is not good. From jkrell at elego.de Sat Oct 16 12:44:21 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 16 Oct 2010 12:44:21 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101016104421.F1E232474010@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/16 12:44:21 Modified files: cm3/m3-sys/m3back/src/: Codex86.i3 Codex86.m3 Log message: add "interlocked" or "Interlocked" to the various BitOp, BitTestOp, BitTestAndSetOp identifiers, to indicate that they are, alas, interlocked. They would be so much more useful of they were only interlocked if they had a lock prefix. These functions are now unused and should probably be removed. From jkrell at elego.de Sat Oct 16 12:58:33 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 16 Oct 2010 12:58:33 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101016105833.450732474010@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/16 12:58:33 Modified files: cm3/m3-sys/m3back/src/: Codex86.m3 M3x86Rep.i3 Log message: generate the constant 1 with xor and inc for a total of 3 bytes instead of a 5 byte mov, just like the C compiler does (when optimizing for size instead of speed) From jkrell at elego.de Sat Oct 16 13:06:47 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 16 Oct 2010 13:06:47 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101016110647.C3BAD2474010@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/16 13:06:47 Modified files: cm3/m3-sys/m3back/src/: Codex86.m3 Log message: don't duplicate code -- having assignment be an expression sure would be handy! From jkrell at elego.de Sat Oct 16 14:12:02 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 16 Oct 2010 14:12:02 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101016121203.17A7D2474010@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/16 14:12:02 Modified files: cm3/m3-sys/m3back/src/: Codex86.m3 Log message: push one byte integers with 2 byte 0x6A instruction instead of 5 byte 0x68 instruction load one byte integers into registers with 2 byte push followed by 1 byte pop, instead of 5 byte move (except for 0 which is xor and 1 which is xor/inc) pessimize this and previous xor/inc for 1 to only handle 32 bit integers (it'd work for 64bit as xor/xor/inc but we might check for the overflow upon inc, conditional branch, etc. (0 is still xor; a pair of xors is still better than almost anything else; notice though that there are optimizations based on knowing you are modifying two registers, where one is computed from the other, such as via a mov or mov/inc) From jkrell at elego.de Sat Oct 16 14:23:29 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 16 Oct 2010 14:23:29 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101016122329.41CC02474010@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/16 14:23:29 Modified files: cm3/m3-sys/m3back/src/: Codex86.m3 Log message: handle -1 before handling -128 through 127 (3 byte or with -1, one instruction, vs. 3 bytes 2 instructions..anyway..I don't know the cycle count or scheduling nuances, but emulate the C compiler!) From jkrell at elego.de Sat Oct 16 14:26:35 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 16 Oct 2010 14:26:35 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101016122635.DBF532474010@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/16 14:26:35 Modified files: cm3/m3-sys/m3back/src/: Codex86.m3 Log message: just add a comment From jkrell at elego.de Sat Oct 16 14:31:22 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 16 Oct 2010 14:31:22 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101016123122.A5F602474010@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/16 14:31:22 Modified files: cm3/m3-sys/m3back/src/: Codex86.m3 Log message: don't use push/pop to load esp with a one byte constant -- highly highly unlikely to ever hit this From jkrell at elego.de Sat Oct 16 14:31:58 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 16 Oct 2010 14:31:58 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101016123158.8B9042474010@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/16 14:31:58 Modified files: cm3/m3-sys/m3back/src/: Codex86.m3 Log message: parens From jay.krell at cornell.edu Mon Oct 18 11:17:38 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 18 Oct 2010 09:17:38 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20101006090354.BD40E2474003@birch.elegosoft.com>, , <2E507E51-9600-47B0-8849-99297B3841E9@cs.purdue.edu>, , <4E2BB803-F603-4D9B-8E06-6B7D73CC7392@cs.purdue.edu>, Message-ID: ?> ?> > > Turning it on all the time makes things much slower and I think also actually breaks things (!). ?> ?> > Yikes, really? > ?> It definitely slows things down. ?> I'm pretty sure when I don't use bitfield refs, I get bad code. ?> I have to try again. ?> I don't have things well automated in terms of keeping around various configurations ?> and easily switching them, and I often go overboard and build too much and don't ?>? do a good job of reducing the problem, but "stare" at too much. I tested this again. Of course, it isn't enable-checking that generates bad code. But the "safe" non-bitfield code now does -- produces a crashing cm3 I386_DARWIN. I haven't looked into it, just that I tried it again. It also still generates less efficient code, at least when not optmizing. The add is a separate instruction, instead of building it in as an offset into the dereferencing instruction. You probably know that already. Perhaps the problem is applying the non-bitfield code for, um, bitfields? For offsets/sizes that aren't multiples of BITS_PER_UNIT? (er..I guess only offsets are relevant here). I'll try that. - Jay From jkrell at elego.de Tue Oct 19 10:03:29 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 19 Oct 2010 10:03:29 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101019080329.EBB8ACC85B@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/19 10:03:29 Modified files: cm3/m3-sys/m3back/src/: Codex86.i3 Codex86.m3 M3x86.m3 Log message: back to bt/bts/btr/btc instructions for set_member, set_singleton They are not in fact slow/atomic, I was mislead by a comment in gcc/config/i386/i386.md and I thought other finds on the Internet. From jkrell at elego.de Tue Oct 19 10:45:09 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 19 Oct 2010 10:45:09 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101019084509.C102ECC85B@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/19 10:45:09 Modified files: cm3/m3-sys/m3back/src/: Codex86.m3 M3x86.m3 M3x86Rep.i3 Stackx86.m3 Log message: rename TypeIs64 to TypeIsDoubleInt many other "64" remain however and I doubt we'll retarget this to AMD64 or any other architecture more likely to generate C In gcc parlance, SI is single int, 32bits, DI is double int, 64bits however here that's not what I mean, but rather an integer that uses two registers. It is tempting to call it just "double", but that means double precision floating point. From jkrell at elego.de Tue Oct 19 10:46:28 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 19 Oct 2010 10:46:28 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101019084628.917B3CC85B@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/19 10:46:28 Modified files: cm3/m3-sys/m3back/src/: M3x86.m3 Log message: just some whitespace changes From jkrell at elego.de Tue Oct 19 10:55:23 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 19 Oct 2010 10:55:23 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101019085523.738F4CC85B@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/19 10:55:23 Modified files: cm3/m3-sys/m3back/src/: Codex86.m3 M3x86.m3 M3x86Rep.i3 Stackx86.m3 Log message: go back from IsTypeDoubleInt to IsType64 From jkrell at elego.de Tue Oct 19 11:49:27 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 19 Oct 2010 11:49:27 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101019094927.203A0CC85B@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/19 11:49:27 Added files: cm3/scripts/win/: dos2unix.c Log message: copy of cvs.c From jkrell at elego.de Tue Oct 19 12:13:33 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 19 Oct 2010 12:13:33 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101019101333.340CDCC85B@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/19 12:13:33 Modified files: cm3/scripts/win/: dos2unix.c Log message: change it from cvs to dos2unix From jkrell at elego.de Tue Oct 19 12:27:54 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 19 Oct 2010 12:27:54 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101019102754.D9DFDCC85B@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/19 12:27:54 Modified files: cm3/scripts/win/: dos2unix.c cvs.c Log message: smaller From jkrell at elego.de Tue Oct 19 12:28:17 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 19 Oct 2010 12:28:17 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101019102817.231E1CC85B@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/19 12:28:17 Modified files: cm3/scripts/win/: dos2unix.c Log message: fix comment From jkrell at elego.de Tue Oct 19 12:28:54 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 19 Oct 2010 12:28:54 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101019102854.EA19CCC85B@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/19 12:28:54 Modified files: cm3/scripts/win/: cvs.c Log message: whitespace From jkrell at elego.de Tue Oct 19 12:55:40 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 19 Oct 2010 12:55:40 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101019105540.58DBFCC85B@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/19 12:55:40 Modified files: cm3/m3-sys/m3back/src/: Codex86.i3 Codex86.m3 M3x86.m3 Stackx86.i3 Stackx86.m3 Log message: atomic add, sub, xor of 32bit variables don't need to use compare/exchange loop (not enabled, not tested, odds of working slim, but it is in the right direction) From jkrell at elego.de Wed Oct 20 00:28:02 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 20 Oct 2010 0:28:02 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101019222804.7786BCC85A@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/20 00:28:02 Modified files: cm3/m3-sys/m3back/src/: M3x86.m3 Log message: xor is not reversible -- the new value is in memory and not atomically readable; only add/sub are reversible From jkrell at elego.de Wed Oct 20 09:47:36 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 20 Oct 2010 9:47:36 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101020074737.29882CC85B@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/20 09:47:36 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: typedef const char* PCSTR; typedef unsigned char UCHAR; typedef unsigned int UINT; typedef unsigned long ULONG; typedef unsigned HOST_WIDE_INT UWIDE; From jkrell at elego.de Wed Oct 20 11:37:23 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 20 Oct 2010 11:37:23 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101020093724.29F0ECC859@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/20 11:37:23 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: typedef char* PSTR; typedef HOST_WIDE_INT WIDE; #define WIDE_PRINT_HEX HOST_WIDE_INT_PRINT_HEX #define WIDE_PRINT_DEC HOST_WIDE_INT_PRINT_DEC From jkrell at elego.de Thu Oct 21 08:43:21 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 21 Oct 2010 8:43:21 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101021064321.B8D13CC127@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/21 08:43:21 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: cosmetic -- casts to ULONG in tracing, uppercase %lX in tracing, remove space in cast operator From jkrell at elego.de Thu Oct 21 09:14:49 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 21 Oct 2010 9:14:49 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101021071452.6BD352474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/21 09:14:48 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: remove whitespace from ends of lines From jkrell at elego.de Thu Oct 21 09:21:49 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 21 Oct 2010 9:21:49 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101021072149.CAC7CCC127@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/21 09:21:49 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: long => WIDE so that 32bit hosts can target 64bit and access fields/sizes beyond 2GB (some of these should probably be UWIDE but that ignored) From jkrell at elego.de Thu Oct 21 09:39:43 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 21 Oct 2010 9:39:43 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101021073943.D6F23CC127@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/21 09:39:43 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: add pointer_size and bits_per_unit visible in debugger, unlike the macros BITS_PER_UNIT, POINTER_SIZE From jkrell at elego.de Thu Oct 21 09:53:08 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 21 Oct 2010 9:53:08 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101021075309.0B94C2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/21 09:53:08 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: cosmetic; more substantial coming soon From jkrell at elego.de Thu Oct 21 12:45:19 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 21 Oct 2010 12:45:19 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101021104520.110052474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/21 12:45:19 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: exprerimental work in progress, but actually making progress (disabled here) added function m3_deduce_field_reference and it sometimes work note that it uses linear search, lame would be really great to do something else here.. fields should probably be given typeids, based on their containing record and name or offset, and then we can use binary search against all fields, OR fields should be given small indices 0..n per containing record struct lang_type could/should be brought to bear note that array references still have nothing done for them (even this m3_deduce_field_reference isn't really doing anything yet) widen current_record_size from ULONG to UWIDE so 32bit host can target 64bit and deal with large records (frontend is still broken here, due to use of INTEGER instead of Target.Int or LONGINT (32bit C implementations have had 64bit integers for something like 20 years now..) fix type comparison in load/store to account for the fact that we now have many pointer types -- make all pointer types compare equal change the level of indirection on pointers to records This might fix debugging them, not yet tested. From jkrell at elego.de Thu Oct 28 09:18:55 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 28 Oct 2010 9:18:55 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101028071855.EA73A2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/28 09:18:55 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: o => offset declare subranges properly work in progress: declare open arrays properly introduce UNSIGNED_INTEGER besides INTEGER among the marshaling macros -- that assert the value is >= 0 and use it a lot change more types to WIDE or UWIDE disabled prototype to find where type information is inadequate (e.g. open arrays) From jkrell at elego.de Fri Oct 29 21:13:43 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 29 Oct 2010 21:13:43 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101029191343.E3AE02474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/29 21:13:43 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: consider VIEW_CONVERT_EXPR for loophole From jkrell at elego.de Fri Oct 29 21:14:56 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 29 Oct 2010 21:14:56 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101029191456.210E42474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/29 21:14:56 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: m3gty43.h m3gty45.h Log message: I forgot to commit these files. From jkrell at elego.de Sun Oct 31 13:33:18 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 31 Oct 2010 13:33:18 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101031123318.EEADECC12B@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/31 13:33:18 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: loophole: for integer to integer, continue using cast otherwise, assert the types are equal size and use view_convert I looked at m3core and libm3, but I forget what happened in m3core, possibly nothing. In libm3, unoptimized, this affected only Transform.Hash and PickleStubs.SwapReal, both slightly positively. In the optimized case, this affected only Transform.Hash, a slight reordering but not any obvious improvement. (Maybe it is slightly faster but it isn't *obvious*.) loophole is of course rare. We might want to do similar in load/store, which will have bigger effect. From jkrell at elego.de Sun Oct 31 13:38:55 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 31 Oct 2010 13:38:55 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101031123855.86D2ECC12B@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/31 13:38:55 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: fix unfortunate gcc warnings From jkrell at elego.de Sun Oct 31 13:52:08 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 31 Oct 2010 13:52:08 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101031125208.8903BCC12B@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/31 13:52:08 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: m3gty45.h Log message: work in progress: in-memory deserialized form of m3cg, use a union, use the property gty annotations for union From jkrell at elego.de Sun Oct 31 14:14:47 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 31 Oct 2010 14:14:47 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101031131447.6A82BCC12B@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/31 14:14:47 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c m3gty43.h m3gty45.h Log message: remove all the type stuff, I'm not sure it will be structured that way From jkrell at elego.de Sun Oct 31 14:49:22 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 31 Oct 2010 14:49:22 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101031134922.AAE1FCC12B@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/31 14:49:22 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: -O3 is broken again disable some optimizations I checked and it didn't seem to be caused the loophole/view_convert change or the subrange declaration change. From jkrell at elego.de Sun Oct 31 14:58:13 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 31 Oct 2010 14:58:13 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101031135813.F165FCC12B@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/31 14:58:13 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: allow back a few optimizations From jkrell at elego.de Sun Oct 31 21:55:28 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 31 Oct 2010 21:55:28 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101031205528.C7B99CC12B@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/31 21:55:28 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: allow back a few more optimizations From jkrell at elego.de Sun Oct 31 23:09:42 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 31 Oct 2010 23:09:42 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101031220942.843F7CC12B@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/31 23:09:42 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: allow two more optimizations unfortunately, dead store elimination seems to be the problem dead store elimination is a nice sound optimization disabled prototype to use view_convert on load/store this seemed to break things From jkrell at elego.de Sun Oct 31 23:37:40 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 31 Oct 2010 23:37:40 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101031223740.B536CCC12B@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/31 23:37:40 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: alas: == package /Users/jay/dev2/cm3/m3-demo/fisheye == ../src/GraphData.m3: In function 'GraphData__ReadEdge': ../src/GraphData.m3:308:0: internal compiler error: in create_tmp_var, at gimplify.c:505 so disable a few optimizations again From jkrell at elego.de Fri Oct 1 12:58:36 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 1 Oct 2010 12:58:36 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101001105836.E7FF6CC125@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/01 12:58:36 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: Eliminate INTEGER vs. TARGET_INTEGER distinction. INTEGER is HOST_WIDE_INT which is at least 64bits when targeting 64bit. Equivalent to using LONGINT more instead of INTEGER. Typical 32bit C compilers have had 64bit long long/__int64 for something like 20 years now I think. (ok, at least 15, for certain) From jkrell at elego.de Fri Oct 1 13:03:46 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 1 Oct 2010 13:03:46 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101001110346.82CCBCC125@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/01 13:03:46 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: odd, go back a version From jkrell at elego.de Sat Oct 2 11:48:20 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 2 Oct 2010 11:48:20 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101002094820.BCA7C2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/02 11:48:20 Modified files: cm3/m3-sys/m3cc/gcc-4.5/gcc/: fixed-value.c Log message: gut file hardly used for Modula-3 backend, or I believe in most use of C backend as well From jkrell at elego.de Sat Oct 2 11:53:34 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 2 Oct 2010 11:53:34 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101002095334.A1BA42474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/02 11:53:34 Modified files: cm3/m3-sys/m3cc/gcc/gcc/: config.gcc config.in configure configure.ac hwint.h cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c cm3/m3-sys/m3cc/gcc-4.5/gcc/: config.gcc config.in configure configure.ac hwint.h cm3/m3-sys/m3cc/gcc-apple/gcc/: config.gcc config.in configure configure.ac hwint.h cm3/m3-sys/m3cc/src/: clean_marker.txt m3makefile Log message: small cleanup in target integer reading make sure HOST_WIDE_INT is always at least 64bits which was already the case on most targets anyway due to "biarch", the fact that x86 backends can target AMD64 with -m64 From jkrell at elego.de Sat Oct 2 12:36:50 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 2 Oct 2010 12:36:50 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101002103651.11B132474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/02 12:36:50 Modified files: cm3/m3-sys/m3cc/gcc-4.5/libiberty/: pex-common.h cm3/m3-sys/m3cc/gcc/libiberty/: pex-common.h Log message: #include for pid_t, for VMS see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44002 From jkrell at elego.de Sat Oct 2 12:39:20 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 2 Oct 2010 12:39:20 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101002103920.BCE322474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/02 12:39:20 Modified files: cm3/m3-sys/m3cc/gcc-apple/gcc/ginclude/: stddef.h cm3/m3-sys/m3cc/gcc/gcc/ginclude/: stddef.h Log message: Don't trash __size_t, on VMS. Already applied to 4.5. See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44003 From jkrell at elego.de Sat Oct 2 13:20:07 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 2 Oct 2010 13:20:07 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101002112007.5936E2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/02 13:20:07 Modified files: cm3/m3-sys/m3cc/gcc-4.5/gcc/: c-common.c cm3/m3-sys/m3cc/gcc-apple/gcc/: c-common.c cm3/m3-sys/m3cc/gcc/gcc/: c-common.c Log message: workaround ffs problem on VMS see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44037 From jkrell at elego.de Sat Oct 2 13:36:31 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 2 Oct 2010 13:36:31 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101002113631.3E8B42474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/02 13:36:31 Modified files: cm3/m3-sys/m3cc/gcc-4.5/gcc/: config.gcc cm3/m3-sys/m3cc/gcc-4.5/gcc/config/vms/: t-vms Added files: cm3/m3-sys/m3cc/gcc-4.5/gcc/config/vms/: vms-ucrt0.c Removed files: cm3/m3-sys/m3cc/gcc-4.5/gcc/config/vms/: t-vms64 vms-crt0-64.c vms-crt0.c vms-psxcrt0-64.c vms-psxcrt0.c Log message: VMS fixes from trunk see http://gcc.gnu.org/viewcvs/trunk/gcc/config/vms/t-vms?revision=164587&view=markup (i.e. for building C compiler here) From jkrell at elego.de Sat Oct 2 14:16:50 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 2 Oct 2010 14:16:50 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101002121650.897E42474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/02 14:16:50 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: again eliminate INTEGER vs. TARGET_INTEGER distinction INTEGER always suffices, TARGET_INTEGER is no more callers can call build_int_cst if they need a tree, as many but not all do 64bits is always enough I think the problem in previous attempt was the cast to long in get_int () where HOST_WIDE_INT is needed (32bits vs. 64bits) eliminate a little bit of 64bit math on 32bit hosts Though overall we overuse 64bit math on purpose. eliminate a little unnecessary signed math unsigned is generally preferred m3cg sign parameter is never used, in div/mod, adjust code accordingly (They used to be used to optimize our unusual div/mod operations, but now we always optimize; hm..could probably do better though, using the signs -- if both positive or both negative, use truncation, which is more commonly what the processors do?) eliminate some temporaries unoptimized code probably affected accordingly positively From jkrell at elego.de Sat Oct 2 15:17:30 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 2 Oct 2010 15:17:30 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101002131731.13D6A2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/02 15:17:30 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: tipe => type tipe is a Modula-3-ism, where "TYPE" is a reserved word? type is not a reserved word in C or C++ From jkrell at elego.de Sat Oct 2 15:21:28 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 2 Oct 2010 15:21:28 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101002132128.D65D62474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/02 15:21:28 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: t => type s => size a => align #if 0 unused function (avoid warning) #define foo bar when foo is just a function that calls bar From jkrell at elego.de Sat Oct 2 15:21:51 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 2 Oct 2010 15:21:51 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101002132151.DCAAE2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/02 15:21:51 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: a => align From jkrell at elego.de Sat Oct 2 15:37:04 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 2 Oct 2010 15:37:04 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101002133704.5BC832474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/02 15:37:04 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: rename variables whose name is just a single lowercase l to avoid ambiguity with the number 1 l => label l => length l => m (as in a, b, c, d, ..., j, k, m) From jkrell at elego.de Sun Oct 3 07:16:19 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 3 Oct 2010 7:16:19 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101003051620.010AD2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/03 07:16:19 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: 1 => true 0 => false or NULL but still intialize with the nice generic form { 0 } From jkrell at elego.de Sun Oct 3 07:17:13 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 3 Oct 2010 7:17:13 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101003051713.B9B822474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/03 07:17:13 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: go ahead and just always use 64bit math in get_int From jkrell at elego.de Sun Oct 3 07:18:20 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 3 Oct 2010 7:18:20 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101003051820.908BB2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/03 07:18:20 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: two missing spaces after function calls (formating) From jkrell at elego.de Sun Oct 3 07:21:24 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 3 Oct 2010 7:21:24 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101003052124.F1D892474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/03 07:21:24 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: no point to: #define NAME STRING just use STRING everywhere From jkrell at elego.de Sun Oct 3 08:38:34 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 3 Oct 2010 8:38:34 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101003063834.369152474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/03 08:38:34 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: enable debugging of enums, in stock gdb start code for debugging of globals, which are always embedded in global structs debugging of structs has the indirection off wrong, for example: t.r1 := 2; t.r2 := 3; t.r3 := 10; (gdb) p *t $4 = (struct Main.T1 *) 0xa32 oops. To be fixed shortly. There are probably many cases that don't debug correctly, because typenames, subranges, and esp. packing probably aren't handled correctly. The code is careful given an untyped integer, not to assign it a type of a different types. That is, when the frontend gives us: TYPE typecode = BITS 20 FOR [...] VAR tc:typecode; and it tells backend tc is a word32 of type typecode, we ignore the stronger type and just say it is word32. Not doing that was caused me a lot of grief/debugging/staring at code. Since this is a subrange and not an enum anyway, not clear we should do anything different. Subranges aren't really types, unless, e.g. you wanted the backend to generate the range checks (which isn't crazy, as it could optimize away redundant checks). As well, what does it mean: TYPE Color={Red,Blue}; TYPE T1 = BITS 2 FOR Color; TYPE T2 = BITS 8 FOR Color; TYPE T3 = BITS 800 FOR Color; Currently enum names are probably wrong, they show as Red, Blue in this example, probably should be Interface.Color.Red. same some pointer overhead in backend 0 => NULL a bit more add function m3_make_integer_type for maybe future use, that can create integers of any number of bits from 1 to 64 remove some more signed math From jkrell at elego.de Sun Oct 3 08:40:02 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 3 Oct 2010 8:40:02 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101003064002.3AEF72474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/03 08:40:02 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: remove growable and fixed size type table, just use VEC version From jkrell at elego.de Sun Oct 3 09:32:44 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 3 Oct 2010 9:32:44 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101003073244.AE4222474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/03 09:32:44 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: m3gty43.h m3gty45.h parse.c Log message: t => type id => typeid MTYPE2 => MTYPE where adequate From jkrell at elego.de Sun Oct 3 09:38:02 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 3 Oct 2010 9:38:02 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101003073802.D04B02474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/03 09:38:02 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: more manual tracing cleanup, not much manual tracing left now From jkrell at elego.de Sun Oct 3 10:00:48 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 3 Oct 2010 10:00:48 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101003080048.4D8AF2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/03 10:00:48 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: Darwin.common Log message: default to -g on Darwin, since there is no m3gdb to consume -gstabs From jkrell at elego.de Sun Oct 3 14:20:03 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 3 Oct 2010 14:20:03 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101003122003.B94562474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/03 14:20:03 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: read entire file into memory Even if the file is large, they usually aren't, our access pattern is linear, so virtual memory suffices. This can help with some possible simplifications and speedups, including the next item, which ends up separting the buffer from any file. To deal with circular types, which inhibit us from building good type information in one pass, introduce a mechanism where an opcode can request that it be "replayed"; still, some amount of type information must be created to make forward progress; this is not fully fleshed out yet; what we need to do be sure to create The node that will represent the types, even if we don't fill in its details until later; and then, later, retrieve the node, and fill in more. That is, during "replay", we must not create brand new nodes. e.g. records could be initially empty, then define all the types of their constituent fields, including perhaps pointers to the record itself, and then go back and fill in the fields In general, due to circularities, there is not an ordering that can work in one pass. There are multiple examples in the tree where the declarations come in in a non-working order (possibly there not being a working order). sortedtableextras, for example. To this end, of the "replay" feature, generally move "M3_TYPES" code ahead of the m3gdb code, to avoid the m3gdb code running twice, since I don't know if that will work. The m3gdb code will be deferred until the M3_TYPES code has enough information to complete. disable all type code for now put back all volatile because something is amiss neither of these edits are meant to last remove the mechanism for altering return types That which I recently cleaned up to stop widening return types. put in the missing builtin WIDECHAR Should this be in RTBuiltin.m3x? Put in UID_NULL as well. These last two get us somewhat more complete typeinfo, but there are still circularities we don't likely handle correctly yet. (Not to mention not handling the various array types correctly.) Use VOID_TYPE_P instead of comparison to t_void. Probably no difference in Modula-3, but we were already inconsistent. Make line number unsigned. From jay.krell at cornell.edu Sun Oct 3 14:39:01 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 3 Oct 2010 12:39:01 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20101003122003.B94562474003@birch.elegosoft.com> References: <20101003122003.B94562474003@birch.elegosoft.com> Message-ID: The problem was I declaring subranges to have the same type as their domain. Which would often make them too large. Which broke the sizes of fields. This should be better shortly. ?- Jay ---------------------------------------- > Date: Sun, 3 Oct 2010 14:20:03 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/10/03 14:20:03 > > Modified files: > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > Log message: > read entire file into memory > Even if the file is large, they usually aren't, > our access pattern is linear, so virtual memory suffices. > This can help with some possible simplifications and speedups, > including the next item, which ends up separting the > buffer from any file. > > To deal with circular types, which inhibit > us from building good type information in one pass, > introduce a mechanism where an opcode can request that it > be "replayed"; still, some amount of type information > must be created to make forward progress; this is not > fully fleshed out yet; what we need to do be sure to > create The node that will represent the types, even > if we don't fill in its details until later; and then, later, > retrieve the node, and fill in more. That is, during "replay", > we must not create brand new nodes. > > e.g. records could be initially empty, then define all the > types of their constituent fields, including perhaps pointers > to the record itself, and then go back and fill in the fields > In general, due to circularities, there is not an ordering > that can work in one pass. > > There are multiple examples in the tree where the declarations > come in in a non-working order (possibly there not being > a working order). sortedtableextras, for example. > > To this end, of the "replay" feature, generally move "M3_TYPES" code > ahead of the m3gdb code, to avoid the m3gdb code running twice, > since I don't know if that will work. > The m3gdb code will be deferred until the M3_TYPES code has enough > information to complete. > > disable all type code for now > put back all volatile > because something is amiss > neither of these edits are meant to last > > remove the mechanism for altering return types > That which I recently cleaned up to stop widening > return types. > > put in the missing builtin WIDECHAR > Should this be in RTBuiltin.m3x? > > Put in UID_NULL as well. > > These last two get us somewhat more complete typeinfo, > but there are still circularities we don't likely handle correctly yet. > (Not to mention not handling the various array types correctly.) > > Use VOID_TYPE_P instead of comparison to t_void. > Probably no difference in Modula-3, but we were already inconsistent. > > Make line number unsigned. > From jkrell at elego.de Sun Oct 3 20:28:48 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 3 Oct 2010 20:28:48 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101003182848.37BC52474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/03 20:28:48 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: fix subranges, to be small in size restore not volatile turn back on type code make it easy to turn on/off replay; turn it on remove assert that subrange min <= max, as it breaks X some small tweaks combine code for declare_pointer and declare_indirect consider using stabilize_reference more (after every indirect_ref remove temporaries from: shift rotate check_nil check_lo check_hi check_range check_eq very few temporaries remain: ones the frontend asks for (indefinite) floating point (round, floor, ceiling) loophole sometimes, pop_static_link, compare_exchange From jkrell at elego.de Mon Oct 4 01:21:44 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 4 Oct 2010 1:21:44 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101003232144.C9D6A2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/04 01:21:44 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: sprinkle stabilize_reference eveywhere it will likely save some recompution and is otherwise often a no-op From jkrell at elego.de Mon Oct 4 01:23:33 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 4 Oct 2010 1:23:33 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101003232333.4B8532474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/04 01:23:33 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: turn off the tracing about forward type references From jkrell at elego.de Mon Oct 4 01:29:51 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 4 Oct 2010 1:29:51 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101003232951.B60982474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/04 01:29:51 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: limit replay passes to 100 instead of hanging; in practise 1 seems to suffice, and they go very fast so 100 won't be a long lag (I know because an earlier version went forever, looking for end_unit to repeat) From jkrell at elego.de Mon Oct 4 11:59:56 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 4 Oct 2010 11:59:56 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101004095956.ACF542474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/04 11:59:56 Modified files: cm3/m3-libs/m3core/src/text/: TextLiteral.i3 Log message: allow larger TEXTs, breaking 32 to 64 bit cross builds, as they always were (frontend needs to be fixed to either use LONGINT or Target.Int, to enable the level of cross building that is normal in C and C++!) From jkrell at elego.de Mon Oct 4 20:56:04 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 4 Oct 2010 20:56:04 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101004185604.87F532474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/04 20:56:04 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: take advantage of the entire file being in memory and for strings, use a direct pointer into the buffer instead of copying byte by byte into alloca'ed buffer (which I think was malloced until recently) (note that access is no longer linear, if these strings are used much, they will bring into working set nearby unused data) and then the attendant reduction/elimination of nul terminated strings From jkrell at elego.de Mon Oct 4 21:06:58 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 4 Oct 2010 21:06:58 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101004190658.943072474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/04 21:06:58 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: missed a dependency on nul termination (beware strdup) From jkrell at elego.de Mon Oct 4 21:11:51 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 4 Oct 2010 21:11:51 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101004191152.319932474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/04 21:11:51 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: squeeze out a bit more nul termination inefficiency -- don't allocate room for it or copy it in From jkrell at elego.de Mon Oct 4 21:14:25 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 4 Oct 2010 21:14:25 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101004191425.84F202474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/04 21:14:25 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: grow some buffers from 100 to 256 (there's another one, but it should be growable and start small) From jkrell at elego.de Wed Oct 6 11:03:54 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 6 Oct 2010 11:03:54 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101006090354.BD40E2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/06 11:03:54 Modified files: cm3/m3-sys/m3cc/gcc/gcc/: ipa.c Log message: neuter 4.3 cgraph_remove_unreachable_nodes that doesn't like our trees From jkrell at elego.de Wed Oct 6 11:15:44 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 6 Oct 2010 11:15:44 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101006091544.B9B8F2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/06 11:15:44 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: turn off stablize_reference and all the type code, on SPARC32_SOLARIS (which is also volatile_all, and gcc 4.3) From jkrell at elego.de Wed Oct 6 11:16:59 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 6 Oct 2010 11:16:59 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101006091659.ABEDB2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/06 11:16:59 Modified files: cm3/m3-sys/m3cc/gcc/gcc/: ipa.c Log message: go back a version From jkrell at elego.de Wed Oct 6 11:22:57 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 6 Oct 2010 11:22:57 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101006092258.030BC2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/06 11:22:57 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: cleaner and add comment -- disabling all type code on SPARC32_SOLARIS From jkrell at elego.de Wed Oct 6 11:24:25 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 6 Oct 2010 11:24:25 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101006092425.208732474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/06 11:24:25 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: cleaner From jkrell at elego.de Wed Oct 6 11:31:54 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 6 Oct 2010 11:31:54 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101006093154.9D6F72474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/06 11:31:54 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: fix typo From jkrell at elego.de Wed Oct 6 12:45:43 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 6 Oct 2010 12:45:43 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101006104543.A18DB2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/06 12:45:43 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: -O3 breaks Solaris/sparc32 internally silently convert it to -O2, for this target only (when you run a bootstrap cm3 from -O3, the exception upon not finding cm3.cfg isn't dispatched correctly) From jkrell at elego.de Wed Oct 6 13:41:10 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 6 Oct 2010 13:41:10 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101006114110.CB7FA2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/06 13:41:10 Modified files: cm3/m3-libs/m3core/src/runtime/SOLgnu/: m3makefile Log message: use forward slash directly instead of SL From jkrell at elego.de Wed Oct 6 13:52:52 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 6 Oct 2010 13:52:52 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101006115252.B14D92474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/06 13:52:52 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: NetBSD.common Log message: also look in /usr/X11R7/lib in addition to /usr/X11R6/lib, as that is where things are on my 5.0.2 system (really should use $ORIGIN here..at least if on a 5.0+ system From jkrell at elego.de Wed Oct 6 14:03:27 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 6 Oct 2010 14:03:27 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101006120328.004A72474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/06 14:03:27 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: I386.common Log message: remove -mno-align-double I would really like the cm3cg command lines to be very cruft free, and this should no longer make a difference. Frontend aligns doubles to 8 bytes on all platforms, even though it could get away with 4 bytes on some e.g. x86. If there are any problems on any x86 platforms, try putting this back. It was especially painful at some point to debug this on Cygwin. Tested only I386_LINUX, but affects far more. From jkrell at elego.de Wed Oct 6 14:06:04 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 6 Oct 2010 14:06:04 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101006120604.E40F22474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/06 14:06:04 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: NT386.common Log message: remove -mno-align-double it should no longer matter But anyone using Cygwin or MinGW, beware! From jkrell at elego.de Wed Oct 6 14:08:08 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 6 Oct 2010 14:08:08 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101006120808.63F8D2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/06 14:08:08 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: AMD64.common AMD64_LINUX I386_LINUX.common Log message: remove -mno-align-double from m3back_flags and SYSTEM_CC Beware From jkrell at elego.de Wed Oct 6 14:47:22 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 6 Oct 2010 14:47:22 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101006124723.0AA192474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/06 14:47:22 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: NetBSD.common Log message: fix typo, now PklFonts can run From hosking at cs.purdue.edu Wed Oct 6 15:11:00 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 6 Oct 2010 09:11:00 -0400 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20101006090354.BD40E2474003@birch.elegosoft.com> References: <20101006090354.BD40E2474003@birch.elegosoft.com> Message-ID: <2E507E51-9600-47B0-8849-99297B3841E9@cs.purdue.edu> What's wrong with them? On 6 Oct 2010, at 11:03, Jay Krell wrote: > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/10/06 11:03:54 > > Modified files: > cm3/m3-sys/m3cc/gcc/gcc/: ipa.c > > Log message: > neuter 4.3 cgraph_remove_unreachable_nodes that doesn't like our trees From hosking at cs.purdue.edu Wed Oct 6 15:12:02 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 6 Oct 2010 09:12:02 -0400 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20101006104543.A18DB2474003@birch.elegosoft.com> References: <20101006104543.A18DB2474003@birch.elegosoft.com> Message-ID: This suggests we lost information about exception blocks. It used to work... On 6 Oct 2010, at 12:45, Jay Krell wrote: > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/10/06 12:45:43 > > Modified files: > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > Log message: > -O3 breaks Solaris/sparc32 > internally silently convert it to -O2, for this target only > (when you run a bootstrap cm3 from -O3, the exception upon > not finding cm3.cfg isn't dispatched correctly) From jay.krell at cornell.edu Wed Oct 6 15:20:33 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 6 Oct 2010 13:20:33 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <2E507E51-9600-47B0-8849-99297B3841E9@cs.purdue.edu> References: <20101006090354.BD40E2474003@birch.elegosoft.com>, <2E507E51-9600-47B0-8849-99297B3841E9@cs.purdue.edu> Message-ID: I don't know, but there are many obvious candidates. We don't generate much type information, and we generate now some incorrect type information (wrong level of pointers sometimes on structs) In this case, it was getting a null pointer: edit /dev2/cm3/m3-sys/m3cc/gcc/gcc/ipa.c line 164 ??? ? if (DECL_STRUCT_FUNCTION (decl)) configure -enable-checking still complains about many things. Though I have fixed some. ? Turning it on all the time makes things much slower and I think also actually breaks things (!). It doesn't like the bitfield refs, something about missing a "VUSE". ?? Maybe volatile would be the better tradeoff?? It doesn't like various expressions that mix integer types. ? These shouldn't be hard to fix, and I have fixed some. ? They included that we were mixing up the return types of all functions that return ?? integers smaller than a word. It complains about the module initializers confusing structs and struct pointers in their return type. However I think not using the bitfield refs generates incorrect code now. ?ie: when I address configure -enable-checking, I get bad code. ? I have to look into this more. The configure -enable-checking problems seem to be somewhat large and very long standing. Configure -enable-checking also complains something about our use of static chain. It was hard enough just to get the static chain working 4.5...I don't look forward to understanding also figuring out why configure enable-checking doesn't like it. ?- Jay ---------------------------------------- > From: hosking at cs.purdue.edu > Date: Wed, 6 Oct 2010 09:11:00 -0400 > To: jkrell at elego.de > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > What's wrong with them? > > On 6 Oct 2010, at 11:03, Jay Krell wrote: > > > CVSROOT: /usr/cvs > > Changes by: jkrell at birch. 10/10/06 11:03:54 > > > > Modified files: > > cm3/m3-sys/m3cc/gcc/gcc/: ipa.c > > > > Log message: > > neuter 4.3 cgraph_remove_unreachable_nodes that doesn't like our trees > From hosking at cs.purdue.edu Wed Oct 6 15:28:05 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 6 Oct 2010 09:28:05 -0400 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20101006090354.BD40E2474003@birch.elegosoft.com>, <2E507E51-9600-47B0-8849-99297B3841E9@cs.purdue.edu> Message-ID: <4E2BB803-F603-4D9B-8E06-6B7D73CC7392@cs.purdue.edu> On 6 Oct 2010, at 09:20, Jay K wrote: > I don't know, but there are many obvious candidates. > We don't generate much type information, and we generate now some incorrect type information (wrong level > of pointers sometimes on structs) > In this case, it was getting a null pointer: > edit /dev2/cm3/m3-sys/m3cc/gcc/gcc/ipa.c line 164 > if (DECL_STRUCT_FUNCTION (decl)) > > > configure -enable-checking still complains about many things. Though I have fixed some. Yes, this has been most helpful. I would like to push it further but don't currently have the time. > Turning it on all the time makes things much slower and I think also actually breaks things (!). Yikes, really? > It doesn't like the bitfield refs, something about missing a "VUSE". > Maybe volatile would be the better tradeoff?? I think ultimately we should be good gcc citizens and generate proper type information. Then we can use properly named symbolic bitfield references. (So long as we can ensure that the front-end and back-end agree on layout.) > It doesn't like various expressions that mix integer types. > These shouldn't be hard to fix, and I have fixed some. > They included that we were mixing up the return types of all functions that return > integers smaller than a word. RIght. > It complains about the module initializers confusing structs and struct pointers in their return type. Should be fixable. > However I think not using the bitfield refs generates incorrect code now. > ie: when I address configure -enable-checking, I get bad code. > I have to look into this more. Sigh. > The configure -enable-checking problems seem to be somewhat large and very long standing. > > > Configure -enable-checking also complains something about our use of static chain. > It was hard enough just to get the static chain working 4.5...I don't look forward to > understanding also figuring out why configure enable-checking doesn't like it. Hmm. Do we know what Pascal/Ada/D and friends do in this instance? > > > - Jay > > ---------------------------------------- >> From: hosking at cs.purdue.edu >> Date: Wed, 6 Oct 2010 09:11:00 -0400 >> To: jkrell at elego.de >> CC: m3commit at elegosoft.com >> Subject: Re: [M3commit] CVS Update: cm3 >> >> What's wrong with them? >> >> On 6 Oct 2010, at 11:03, Jay Krell wrote: >> >>> CVSROOT: /usr/cvs >>> Changes by: jkrell at birch. 10/10/06 11:03:54 >>> >>> Modified files: >>> cm3/m3-sys/m3cc/gcc/gcc/: ipa.c >>> >>> Log message: >>> neuter 4.3 cgraph_remove_unreachable_nodes that doesn't like our trees >> > From jay.krell at cornell.edu Wed Oct 6 15:26:52 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 6 Oct 2010 13:26:52 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20101006104543.A18DB2474003@birch.elegosoft.com>, Message-ID: -O3 definitely worked on Solaris/sparc32? None of the optimization flags get tested in Hudson. I don't test Solaris/sparc32 much -- local machine is slow, network seems slow using remote machines. ?- Jay ---------------------------------------- > From: hosking at cs.purdue.edu > Date: Wed, 6 Oct 2010 09:12:02 -0400 > To: jkrell at elego.de > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > This suggests we lost information about exception blocks. It used to work... > > On 6 Oct 2010, at 12:45, Jay Krell wrote: > > > CVSROOT: /usr/cvs > > Changes by: jkrell at birch. 10/10/06 12:45:43 > > > > Modified files: > > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > > > Log message: > > -O3 breaks Solaris/sparc32 > > internally silently convert it to -O2, for this target only > > (when you run a bootstrap cm3 from -O3, the exception upon > > not finding cm3.cfg isn't dispatched correctly) > From jay.krell at cornell.edu Wed Oct 6 15:40:03 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 6 Oct 2010 13:40:03 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <4E2BB803-F603-4D9B-8E06-6B7D73CC7392@cs.purdue.edu> References: <20101006090354.BD40E2474003@birch.elegosoft.com>, <2E507E51-9600-47B0-8849-99297B3841E9@cs.purdue.edu> , <4E2BB803-F603-4D9B-8E06-6B7D73CC7392@cs.purdue.edu> Message-ID: > I think ultimately we should be good gcc citizens and generate proper type information Me too, but it is a can of worms. It is hard to get from current situation to typeful situation in small working steps. I don't have a long attention span, it is difficult to get through large items.. > Then we can use properly named symbolic bitfield references Field/component references. The underlying field will have one of any type: integer, float, pointer, bitfield, etc. We can use this for records, objects, arrays. > > Turning it on all the time makes things much slower and I think also actually breaks things (!). > > Yikes, really? It definitely slows things down. I'm pretty sure when I don't use bitfield refs, I get bad code. I have to try again. I don't have things well automated in terms of keeping around various configurations and easily switching them, and I often go overboard and build too much and don't do a good job of reducing the problem, but "stare" at too much. What I should do is like, binary search where the variable is which compiler and the data being "searched" is, say, all of m3core. And then once the difference found, have to see why the compiler made the decision. I haven't debugged the compiler much. I don't know its domain -- ssa, vdefs, vuses, etc. > > It complains about the module initializers confusing structs and struct pointers in their return type. > > Should be fixable. Yes. Thing is. I have to test each change both with and without configure enable-checking. I rely too much on scripts..end up rebuilding backend more than needed (much quicker now with gmp reduced!) > Hmm. Do we know what Pascal/Ada/D and friends do in this instance? Good point. I don't know. Could be they let gcc use its regular trampolines. Which has advantages and disadvantages. But I don't know. (advantages: leaves the work/maintanence to mainline gcc, more interopable with C; disadvantages: doesn't work on all platforms, is slower (mprotect on some platforms) and faster (no need to check for the marker)). But I don't know. I'd be in favor of transforming this away in the frontend, or maybe in parse.c. It does require more or less dataflow analysis to see which locals/parameters ared used by nested functions, which is probably easy to make a safe guess at, but then difficult to make an optimized guess at. i.e. you'd end up reserving space for and storing locals/parameters that are then not used. ?- Jay ---------------------------------------- > Subject: Re: [M3commit] CVS Update: cm3 > From: hosking at cs.purdue.edu > Date: Wed, 6 Oct 2010 09:28:05 -0400 > CC: jkrell at elego.de; m3commit at elegosoft.com > To: jay.krell at cornell.edu > > On 6 Oct 2010, at 09:20, Jay K wrote: > > > I don't know, but there are many obvious candidates. > > We don't generate much type information, and we generate now some incorrect type information (wrong level > > of pointers sometimes on structs) > > In this case, it was getting a null pointer: > > edit /dev2/cm3/m3-sys/m3cc/gcc/gcc/ipa.c line 164 > > if (DECL_STRUCT_FUNCTION (decl)) > > > > > > configure -enable-checking still complains about many things. Though I have fixed some. > > Yes, this has been most helpful. I would like to push it further but don't currently have the time. > > > Turning it on all the time makes things much slower and I think also actually breaks things (!). > > Yikes, really? > > > It doesn't like the bitfield refs, something about missing a "VUSE". > > Maybe volatile would be the better tradeoff?? > > I think ultimately we should be good gcc citizens and generate proper type information. Then we can use properly named symbolic bitfield references. (So long as we can ensure that the front-end and back-end agree on layout.) > > > It doesn't like various expressions that mix integer types. > > These shouldn't be hard to fix, and I have fixed some. > > They included that we were mixing up the return types of all functions that return > > integers smaller than a word. > > RIght. > > > It complains about the module initializers confusing structs and struct pointers in their return type. > > Should be fixable. > > > However I think not using the bitfield refs generates incorrect code now. > > ie: when I address configure -enable-checking, I get bad code. > > I have to look into this more. > > Sigh. > > > The configure -enable-checking problems seem to be somewhat large and very long standing. > > > > > > Configure -enable-checking also complains something about our use of static chain. > > It was hard enough just to get the static chain working 4.5...I don't look forward to > > understanding also figuring out why configure enable-checking doesn't like it. > > Hmm. Do we know what Pascal/Ada/D and friends do in this instance? > > > > > > > - Jay > > > > ---------------------------------------- > >> From: hosking at cs.purdue.edu > >> Date: Wed, 6 Oct 2010 09:11:00 -0400 > >> To: jkrell at elego.de > >> CC: m3commit at elegosoft.com > >> Subject: Re: [M3commit] CVS Update: cm3 > >> > >> What's wrong with them? > >> > >> On 6 Oct 2010, at 11:03, Jay Krell wrote: > >> > >>> CVSROOT: /usr/cvs > >>> Changes by: jkrell at birch. 10/10/06 11:03:54 > >>> > >>> Modified files: > >>> cm3/m3-sys/m3cc/gcc/gcc/: ipa.c > >>> > >>> Log message: > >>> neuter 4.3 cgraph_remove_unreachable_nodes that doesn't like our trees > >> > > > From jkrell at elego.de Wed Oct 6 16:20:18 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 6 Oct 2010 16:20:18 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101006142018.A76712474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/06 16:20:18 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: SPARC64.common Log message: just remove the second trailing newline From jkrell at elego.de Wed Oct 6 16:20:36 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 6 Oct 2010 16:20:36 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101006142036.6D7562474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/06 16:20:36 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: SPARC.common SPARC32_LINUX Log message: just remove the second trailing newline From jay.krell at cornell.edu Wed Oct 6 16:24:41 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 6 Oct 2010 14:24:41 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20101006142036.6D7562474003@birch.elegosoft.com> References: <20101006142036.6D7562474003@birch.elegosoft.com> Message-ID: darnit, that was supposed to be diff, not commit I'm still testing it. What it really is is: ? use -K PIC on SPARC32_LINUX assembler (to be matched in pylib.py) ? use -mno-app-regs in m3back_flags and gcc (also to be matched in pylib.py, for Linux, I have to check the Sun cc flags) ? remove unnecessary flags about double alignment I frequently see a problem where -fPIC breaks cross cm3. It might be this -K PIC or -mno-app-regs. And I'm seeing SPARC32_LINUX fail early with gcc 4.5. Might be these. These might also explain SPARC32_SOLARIS problems. I'm still testing. For some reason I only noticed -mno-app-regs when working on SPARC64, but it seems to maybe related to SPARC32 also. ?- Jay ---------------------------------------- > Date: Wed, 6 Oct 2010 16:20:36 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/10/06 16:20:36 > > Modified files: > cm3/m3-sys/cminstall/src/config-no-install/: SPARC.common > SPARC32_LINUX > > Log message: > just remove the second trailing newline > From jkrell at elego.de Wed Oct 6 16:44:45 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 6 Oct 2010 16:44:45 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101006144445.7917F2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/06 16:44:45 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: SPARC.common SPARC32_LINUX SPARC64_LINUX SPARC64_OPENBSD Log message: work in progress (or possibly done) on pic/regs flags (SPARC64 less actively tested!) From jkrell at elego.de Wed Oct 6 16:52:09 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 6 Oct 2010 16:52:09 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101006145220.2B07C2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/06 16:52:09 Modified files: cm3/scripts/python/: pylib.py Log message: fidget with pic/app-regs flags -- looking better for SPARC32_LINUX but still not for SPARC32_SOLARIS From hosking at cs.purdue.edu Wed Oct 6 16:50:30 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 6 Oct 2010 10:50:30 -0400 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20101006104543.A18DB2474003@birch.elegosoft.com>, Message-ID: <074A9418-7240-4678-B3CE-C98C2C8B1908@cs.purdue.edu> Yes, at some point in the past 5 years it worked on Solaris/Sparc32. Not sure when... :-( On 6 Oct 2010, at 09:26, Jay K wrote: > > -O3 definitely worked on Solaris/sparc32? > None of the optimization flags get tested in Hudson. > I don't test Solaris/sparc32 much -- local machine is slow, network seems slow using remote machines. > > - Jay > > ---------------------------------------- >> From: hosking at cs.purdue.edu >> Date: Wed, 6 Oct 2010 09:12:02 -0400 >> To: jkrell at elego.de >> CC: m3commit at elegosoft.com >> Subject: Re: [M3commit] CVS Update: cm3 >> >> This suggests we lost information about exception blocks. It used to work... >> >> On 6 Oct 2010, at 12:45, Jay Krell wrote: >> >>> CVSROOT: /usr/cvs >>> Changes by: jkrell at birch. 10/10/06 12:45:43 >>> >>> Modified files: >>> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c >>> >>> Log message: >>> -O3 breaks Solaris/sparc32 >>> internally silently convert it to -O2, for this target only >>> (when you run a bootstrap cm3 from -O3, the exception upon >>> not finding cm3.cfg isn't dispatched correctly) >> > From jkrell at elego.de Wed Oct 6 16:59:40 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 6 Oct 2010 16:59:40 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101006145940.566F42474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/06 16:59:40 Modified files: cm3/m3-sys/m3cc/src/: m3makefile Log message: move SPARC32_LINUX to gcc 4.5.1 backend still testing but looking ok, bootstrap cm3 runs ok move I386_OPENBSD to gcc 4.5.1 backend I think I tested it. It is the only I386 target not moved. move MIPS64_OPENBSD to gcc 4.5.1 backend Not tested. This platform hasn't really arrived and isn't very likely -- SGI hardware, which I do have.. move MIPS64EL_OPENBSD to gcc 4.5.1 backend. Not tested. Much more viable than MIPS64_OPENBSD as there is recently developed laptops running it (yes, I have one). (They run Linux too.) From jay.krell at cornell.edu Wed Oct 6 17:06:03 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 6 Oct 2010 15:06:03 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <074A9418-7240-4678-B3CE-C98C2C8B1908@cs.purdue.edu> References: <20101006104543.A18DB2474003@birch.elegosoft.com>, , , , <074A9418-7240-4678-B3CE-C98C2C8B1908@cs.purdue.edu> Message-ID: Let me maybe get 4.5.1 working before -O3. Granted..I agree it was probably working as recently as the recent release. What changed since then? In the 4.3 tree? ==> I moved from 4.3.0 to 4.3.5. So if we want to find -O3 working, it is probably there. ?- Jay ---------------------------------------- > From: hosking at cs.purdue.edu > Date: Wed, 6 Oct 2010 10:50:30 -0400 > To: jay.krell at cornell.edu > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > Yes, at some point in the past 5 years it worked on Solaris/Sparc32. Not sure when... :-( > > On 6 Oct 2010, at 09:26, Jay K wrote: > > > > > -O3 definitely worked on Solaris/sparc32? > > None of the optimization flags get tested in Hudson. > > I don't test Solaris/sparc32 much -- local machine is slow, network seems slow using remote machines. > > > > - Jay > > > > ---------------------------------------- > >> From: hosking at cs.purdue.edu > >> Date: Wed, 6 Oct 2010 09:12:02 -0400 > >> To: jkrell at elego.de > >> CC: m3commit at elegosoft.com > >> Subject: Re: [M3commit] CVS Update: cm3 > >> > >> This suggests we lost information about exception blocks. It used to work... > >> > >> On 6 Oct 2010, at 12:45, Jay Krell wrote: > >> > >>> CVSROOT: /usr/cvs > >>> Changes by: jkrell at birch. 10/10/06 12:45:43 > >>> > >>> Modified files: > >>> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > >>> > >>> Log message: > >>> -O3 breaks Solaris/sparc32 > >>> internally silently convert it to -O2, for this target only > >>> (when you run a bootstrap cm3 from -O3, the exception upon > >>> not finding cm3.cfg isn't dispatched correctly) > >> > > > From rodney_bates at lcwb.coop Wed Oct 6 21:51:06 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Wed, 06 Oct 2010 14:51:06 -0500 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20101006090354.BD40E2474003@birch.elegosoft.com>, <2E507E51-9600-47B0-8849-99297B3841E9@cs.purdue.edu> , <4E2BB803-F603-4D9B-8E06-6B7D73CC7392@cs.purdue.edu> Message-ID: <4CACD32A.6030906@lcwb.coop> Jay K wrote: --snip-- > > (Tony)>> Hmm. Do we know what Pascal/Ada/D and friends do in this instance? > > > Good point. I don't know. > Could be they let gcc use its regular trampolines. > Which has advantages and disadvantages. But I don't know. > (advantages: leaves the work/maintanence to mainline gcc, more interopable with C; disadvantages: > doesn't work on all platforms, is slower (mprotect on some platforms) and faster (no need > to check for the marker)). > But I don't know. > I'd be in favor of transforming this away in the frontend, or maybe in parse.c. > It does require more or less dataflow analysis to see which locals/parameters ared used by nested functions, > which is probably easy to make a safe guess at, but then difficult to make an optimized guess at. > i.e. you'd end up reserving space for and storing locals/parameters that are then not used. > tree-nested.c in gcc now does this. There is extensive tree-rewriting as a result. Local variables and parameters that are accessed nonlocally (i.e., from within a more deeply-nested procedure) are collected into a record, which is then placed as a local variable. It can be accessed by two different static links, located in different places. I forget all the details. I understood it once. There are a _lot_ of multiple copies of things, duplicate copies of parameters passed by value, duplicate pointers to things passed by reference, etc. I think there can even be three copies of these things. It all leads to activation record expansion and extra code executed in prologs and in accessing things. The apparent reason is that it greatly simplifies the compile-time interaction among nested procedures, nonlocal access, and inlining. The generated record of nonlocally-accessed stuff doesn't have to be known to be located inside any particular activation record, and with inlining, it may not be. Or something like that. Note that this is all about ordinary nonlocal accesses from nested procedures, which use neither trampolines nor closures. The latter are only used when creating and using parameters of procedure type, whose runtime values can sometimes be nested procedures. This is largely independent of static links, etc. The trampolines/closures are only a way of storing static link values in formals of procedure type. Where the values come from before they are stored and where they go and how they are used after they are extracted is independent. For static links themselves, the runtime model is the same for C and Modula-3 code. > > - Jay From jkrell at elego.de Thu Oct 7 09:46:56 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 7 Oct 2010 9:46:56 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101007074657.0BCC82474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/07 09:46:56 Modified files: cm3/m3-sys/m3cc/src/: m3makefile Log message: switch AMD64_SOLARIS to gcc 4.5.1 backend It worked far enough to build and run a cross/boot cm3. workaround http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45927 From jkrell at elego.de Thu Oct 7 11:46:14 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 7 Oct 2010 11:46:14 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101007094614.813842474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/07 11:46:14 Modified files: cm3/scripts/: pkgmap.sh cm3/scripts/regression/: hudson_build_system.sh Log message: instrumentation: try to find when the PPC_LINUX directory permisions get broken, if indeed it is even within here; maybe should reinstall OS... From jkrell at elego.de Thu Oct 7 12:40:53 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 7 Oct 2010 12:40:53 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101007104055.714A12474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/07 12:40:53 Modified files: cm3/m3-sys/m3cc/src/: gnucc.common Log message: gcc 3.4.3 can't compile gcc 4.5.1 targeting AMD64_SOLARIS see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45929 It would be nice to split up the files for portability. So favor gcc 4.x on the opencsw machines, where we can find it. When doing native AMD64_SOLARIS builds. Other folks will have to modify $PATH. Note that cc in path should and I think also does take precedence. We generally favor Sun cc. Eh? From jkrell at elego.de Thu Oct 7 13:26:28 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 7 Oct 2010 13:26:28 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101007112628.E76FA2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/07 13:26:28 Modified files: cm3/m3-sys/m3cc/gcc-4.5/gcc/config/sparc/: sparc.h Log message: Duh! #define TARGET_SPARC 1 like for 4.3.5 to trigger volatile madness in parse.c. From jkrell at elego.de Thu Oct 7 13:50:37 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 7 Oct 2010 13:50:37 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101007115038.171202474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/07 13:50:37 Modified files: cm3/m3-sys/m3cc/gcc-4.5/gcc/config/: sol2.h cm3/m3-sys/m3cc/gcc-apple/gcc/config/: sol2.h cm3/m3-sys/m3cc/gcc-apple/gcc/config/sparc/: sparc.h Log message: Duh! #define TARGET_SOLARIS 1 also and follow suit in gcc-apple for no reason. From jkrell at elego.de Thu Oct 7 14:22:13 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 7 Oct 2010 14:22:13 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101007122213.CB3F72474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/07 14:22:13 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: safe keeping: use volatile more consistently and more often From jkrell at elego.de Thu Oct 7 14:22:37 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 7 Oct 2010 14:22:37 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101007122238.19F0C2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/07 14:22:37 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: go back a version From jkrell at elego.de Sat Oct 9 13:36:40 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 9 Oct 2010 13:36:40 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101009113640.971012474032@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/09 13:36:40 Modified files: cm3/m3-sys/m3cc/src/: m3makefile Log message: cleanup the "NOACTION" feature, by wrapping the whole thing in a function and using early return NOTE: This would also be perfectly clean and natural using goto. Goto is not evil! Compare it to the contortions people go through to avoid it. Those are evil. It would be evil to not have the option of if/else/switch/for/while/break/continue, but not having goto is also evil. let PREBUILT_CM3CG work with cross builds, by copying to build_dir instead of just dot (move the code down to after build_dir is computed/created) PREBUILT_CM3CG doesn't use $WORKSPACE but requires it be set. Why? To avoid honoring it in other random settings? Let PREBUILT_CM3CG also work if $USER = jay. Really: we should not be defining our own environment variables that don't start with CM3_! Even that isn't great. And we should try to use cm3 -D options instead? Environment variables are fairly flat namespace (though you can use underscores and long names) and they flow into unrelated processes, so perhaps to be avoided. However they also flow automatically into child processes, which can be good, when you don't control the command lines all the way through. (It turns out, there's just no perfect solution here. You can also store configuration state globally like in files or registry, but then you can't scope it to a particular process or process tree. A good hybrid, if there is much parameters/state, is stash it in a temporary file/directory, and put that file/directory path in an environment variable -- ie: use just one environment variable). From jkrell at elego.de Wed Oct 13 13:18:53 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 13 Oct 2010 13:18:53 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101013111853.858402474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/13 13:18:53 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: SPARC32_SOLARIS.common cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c cm3/m3-sys/m3cc/gcc-4.5/gcc/: function.c cm3/m3-sys/m3cc/src/: clean_marker.txt m3makefile cm3/m3-sys/m3middle/src/: Target.m3 cm3/m3-libs/m3core/src/runtime/: m3makefile Added files: cm3/m3-libs/m3core/src/runtime/SOLgnu/: m3makefile-old cm3/m3-libs/m3core/src/runtime/SOLsun/: m3makefile-old Removed files: cm3/m3-libs/m3core/src/runtime/SOLgnu/: m3makefile cm3/m3-libs/m3core/src/runtime/SOLsun/: m3makefile Log message: disable Solaris/sparc32 stack walker switch Solaris/sparc32 to gcc 4.5 backend function.c: make failure to volatilize when setjmp/vfork present an error instead of a warning add missing volatilization pin Solaris/sparc32 at -O1 in the config file as -O2/-O3 were seen to hit internal compiler errors (assertion failures) remove the "all volatile" paths from parse.c (since they were only for Solaris/sparc32's stack walker) From jkrell at elego.de Wed Oct 13 17:57:26 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 13 Oct 2010 17:57:26 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101013155726.A77D82474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/13 17:57:26 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: SPARC32_SOLARIS.common Log message: let it be -O3 From jkrell at elego.de Wed Oct 13 18:01:48 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 13 Oct 2010 18:01:48 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101013160148.7F09E2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/13 18:01:48 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: SPARC32_SOLARIS.common Log message: go back a version: unresolved symbols, probably we can just disable a small number of optimizations though From jkrell at elego.de Wed Oct 13 18:10:32 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 13 Oct 2010 18:10:32 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101013161032.360432474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/13 18:10:32 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: SPARC32_SOLARIS.common Log message: cm3 bootstapped ok with -O2 so let's try that From jkrell at elego.de Wed Oct 13 18:29:30 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 13 Oct 2010 18:29:30 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101013162930.C4BEBCC123@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/13 18:29:30 Modified files: cm3/scripts/python/: pylib.py Log message: experimental: don't set M3CONFIG into the source tree; e.g. so we can upgrade from SOLsun with stack walker to without From jkrell at elego.de Wed Oct 13 18:31:22 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 13 Oct 2010 18:31:22 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101013163122.D21FB2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/13 18:31:22 Modified files: cm3/scripts/regression/: hudson_build_system.sh Log message: fix plin instrumentation that broke everything From jkrell at elego.de Wed Oct 13 18:31:53 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 13 Oct 2010 18:31:53 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101013163153.5CD452474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/13 18:31:53 Modified files: cm3/scripts/regression/: hudson_build_system.sh Log message: fix plin instrumentation that broke everything From jkrell at elego.de Wed Oct 13 18:32:31 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 13 Oct 2010 18:32:31 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101013163231.B282D2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/13 18:32:31 Modified files: cm3/scripts/: pkgmap.sh Log message: fix plin instrumentation that broke everything From jkrell at elego.de Sat Oct 16 07:33:41 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 16 Oct 2010 7:33:41 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101016053341.AACB3CC362@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/16 07:33:41 Modified files: cm3/scripts/win/: cvs.c Log message: remove wcscmp use and tabs From jkrell at elego.de Sat Oct 16 08:20:00 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 16 Oct 2010 8:20:00 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101016062000.353F9CC124@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/16 08:20:00 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Added files: cm3/m3-sys/m3back/src/: M3C.i3 Log message: work in progress From jkrell at elego.de Sat Oct 16 10:39:30 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 16 Oct 2010 10:39:30 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101016083930.C2BEFCC124@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/16 10:39:30 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: work in progress From jkrell at elego.de Sat Oct 16 10:42:41 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 16 Oct 2010 10:42:41 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101016084242.290E82474010@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/16 10:42:41 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: work in progress From jkrell at elego.de Sat Oct 16 11:24:39 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 16 Oct 2010 11:24:39 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101016092439.DC8A32474010@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/16 11:24:39 Modified files: cm3/m3-sys/m3back/src/: M3C.m3 Log message: work in progress: it compiles and has a few lines of real code, but is missing *a lot* From jkrell at elego.de Sat Oct 16 11:27:27 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 16 Oct 2010 11:27:27 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101016092727.85D802474010@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/16 11:27:27 Modified files: cm3/m3-sys/m3back/src/: M3C.i3 m3makefile Log message: compile nascent C backend again, there is almost nothing actually here From jkrell at elego.de Sat Oct 16 12:16:12 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 16 Oct 2010 12:16:12 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101016101613.0F2CB2474010@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/16 12:16:12 Modified files: cm3/m3-libs/m3core/src/C/Common/: CstdioC.c CstdlibC.c CstringC.c cm3/m3-libs/m3core/src/Csupport/Common/: dtoa.h hand.c cm3/m3-libs/m3core/src/runtime/WIN32/: RTOSc.c cm3/m3-libs/m3core/src/runtime/common/: RTIOc.c RTMiscC.c RTUntracedMemoryC.c cm3/m3-libs/m3core/src/runtime/ex_frame/: RTStackC.c cm3/m3-libs/m3core/src/thread/WIN32/: ThreadWin32C.c cm3/m3-libs/m3core/src/unix/Common/: Uexec.c Uin.c Unetdb.c UnixC.c UnixLink.c Uprocess.c UtimeC.c Uuio.c cm3/m3-libs/sysutils/src/: SystemC.c Log message: Remove the _DLL/_MT hacking that I had put in, which purported to let one set of object code link with either msvcrt.lib or libcmt.lib. Not a bad idea, not a bad implementation, but a bit on the unsupported side. If user really wants to use libcmt.lib, he should modify the config file and rebuild everything (esp. m3core). We should possibly make such a configuration in Hudson. We should possibly automatically multiply out compile/link for any directories that contain any C? And then build_standalone could imply libmt.lib. Not a bad idea, but unlikely to happen. From jkrell at elego.de Sat Oct 16 12:19:53 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 16 Oct 2010 12:19:53 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101016101953.0DFD12474010@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/16 12:19:53 Modified files: cm3/m3-libs/m3core/src/runtime/common/: RTUntracedMemoryC.c Log message: remove K&R From jkrell at elego.de Sat Oct 16 12:22:17 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 16 Oct 2010 12:22:17 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101016102219.259E22474010@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/16 12:22:17 Modified files: cm3/m3-libs/m3core/src/: m3core.h Log message: move up #ifdef _MSC_VER #pragma warning(disable...) in order to quash: ../..\m3core.h(33) : warning C4668: '__GNUC__' is not defined as a preprocessor macro, replacing with '0' for '#if/#elif' when compiling with -Wall From jay.krell at cornell.edu Sat Oct 16 12:17:24 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 16 Oct 2010 10:17:24 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20101016101613.0F2CB2474010@birch.elegosoft.com> References: <20101016101613.0F2CB2474010@birch.elegosoft.com> Message-ID: diff attached ---------------------------------------- > Date: Sat, 16 Oct 2010 12:16:12 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/10/16 12:16:12 > > Modified files: > cm3/m3-libs/m3core/src/C/Common/: CstdioC.c CstdlibC.c > CstringC.c > cm3/m3-libs/m3core/src/Csupport/Common/: dtoa.h hand.c > cm3/m3-libs/m3core/src/runtime/WIN32/: RTOSc.c > cm3/m3-libs/m3core/src/runtime/common/: RTIOc.c RTMiscC.c > RTUntracedMemoryC.c > cm3/m3-libs/m3core/src/runtime/ex_frame/: RTStackC.c > cm3/m3-libs/m3core/src/thread/WIN32/: ThreadWin32C.c > cm3/m3-libs/m3core/src/unix/Common/: Uexec.c Uin.c Unetdb.c > UnixC.c UnixLink.c > Uprocess.c UtimeC.c Uuio.c > cm3/m3-libs/sysutils/src/: SystemC.c > > Log message: > Remove the _DLL/_MT hacking that I had put in, > which purported to let one set of object code > link with either msvcrt.lib or libcmt.lib. > > Not a bad idea, not a bad implementation, but > a bit on the unsupported side. > > If user really wants to use libcmt.lib, he should > modify the config file and rebuild everything (esp. m3core). > We should possibly make such a configuration in Hudson. > We should possibly automatically multiply out compile/link > for any directories that contain any C? And then build_standalone > could imply libmt.lib. Not a bad idea, but unlikely to happen. > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 1.txt URL: From jkrell at elego.de Sat Oct 16 12:26:02 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 16 Oct 2010 12:26:02 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101016102602.24D902474010@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/16 12:26:02 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: test_hand.c Log message: add __fastcall versions of set_member, set_singleton: point being to read the code and have m3back use it instead of what currently does, which is very very well size optimized but not very well speed optimized, since the instruction it uses imply an interlock, unfortunate From jkrell at elego.de Sat Oct 16 12:31:20 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 16 Oct 2010 12:31:20 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101016103120.88EE32474010@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/16 12:31:20 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: remove comments that say set_member and set_singleton are never used, as I'm inclined at least temporary to go back to function calls From jkrell at elego.de Sat Oct 16 12:39:59 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 16 Oct 2010 12:39:59 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101016104003.9F8622474010@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/16 12:39:59 Modified files: cm3/m3-sys/m3back/src/: M3x86.m3 Log message: go back to function calls for set_member and set_range The inline code was wonderfully small, but unfortunately had an implied and unremovable interlock, which is not good. From jkrell at elego.de Sat Oct 16 12:44:21 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 16 Oct 2010 12:44:21 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101016104421.F1E232474010@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/16 12:44:21 Modified files: cm3/m3-sys/m3back/src/: Codex86.i3 Codex86.m3 Log message: add "interlocked" or "Interlocked" to the various BitOp, BitTestOp, BitTestAndSetOp identifiers, to indicate that they are, alas, interlocked. They would be so much more useful of they were only interlocked if they had a lock prefix. These functions are now unused and should probably be removed. From jkrell at elego.de Sat Oct 16 12:58:33 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 16 Oct 2010 12:58:33 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101016105833.450732474010@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/16 12:58:33 Modified files: cm3/m3-sys/m3back/src/: Codex86.m3 M3x86Rep.i3 Log message: generate the constant 1 with xor and inc for a total of 3 bytes instead of a 5 byte mov, just like the C compiler does (when optimizing for size instead of speed) From jkrell at elego.de Sat Oct 16 13:06:47 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 16 Oct 2010 13:06:47 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101016110647.C3BAD2474010@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/16 13:06:47 Modified files: cm3/m3-sys/m3back/src/: Codex86.m3 Log message: don't duplicate code -- having assignment be an expression sure would be handy! From jkrell at elego.de Sat Oct 16 14:12:02 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 16 Oct 2010 14:12:02 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101016121203.17A7D2474010@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/16 14:12:02 Modified files: cm3/m3-sys/m3back/src/: Codex86.m3 Log message: push one byte integers with 2 byte 0x6A instruction instead of 5 byte 0x68 instruction load one byte integers into registers with 2 byte push followed by 1 byte pop, instead of 5 byte move (except for 0 which is xor and 1 which is xor/inc) pessimize this and previous xor/inc for 1 to only handle 32 bit integers (it'd work for 64bit as xor/xor/inc but we might check for the overflow upon inc, conditional branch, etc. (0 is still xor; a pair of xors is still better than almost anything else; notice though that there are optimizations based on knowing you are modifying two registers, where one is computed from the other, such as via a mov or mov/inc) From jkrell at elego.de Sat Oct 16 14:23:29 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 16 Oct 2010 14:23:29 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101016122329.41CC02474010@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/16 14:23:29 Modified files: cm3/m3-sys/m3back/src/: Codex86.m3 Log message: handle -1 before handling -128 through 127 (3 byte or with -1, one instruction, vs. 3 bytes 2 instructions..anyway..I don't know the cycle count or scheduling nuances, but emulate the C compiler!) From jkrell at elego.de Sat Oct 16 14:26:35 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 16 Oct 2010 14:26:35 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101016122635.DBF532474010@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/16 14:26:35 Modified files: cm3/m3-sys/m3back/src/: Codex86.m3 Log message: just add a comment From jkrell at elego.de Sat Oct 16 14:31:22 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 16 Oct 2010 14:31:22 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101016123122.A5F602474010@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/16 14:31:22 Modified files: cm3/m3-sys/m3back/src/: Codex86.m3 Log message: don't use push/pop to load esp with a one byte constant -- highly highly unlikely to ever hit this From jkrell at elego.de Sat Oct 16 14:31:58 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 16 Oct 2010 14:31:58 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101016123158.8B9042474010@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/16 14:31:58 Modified files: cm3/m3-sys/m3back/src/: Codex86.m3 Log message: parens From jay.krell at cornell.edu Mon Oct 18 11:17:38 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 18 Oct 2010 09:17:38 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20101006090354.BD40E2474003@birch.elegosoft.com>, , <2E507E51-9600-47B0-8849-99297B3841E9@cs.purdue.edu>, , <4E2BB803-F603-4D9B-8E06-6B7D73CC7392@cs.purdue.edu>, Message-ID: ?> ?> > > Turning it on all the time makes things much slower and I think also actually breaks things (!). ?> ?> > Yikes, really? > ?> It definitely slows things down. ?> I'm pretty sure when I don't use bitfield refs, I get bad code. ?> I have to try again. ?> I don't have things well automated in terms of keeping around various configurations ?> and easily switching them, and I often go overboard and build too much and don't ?>? do a good job of reducing the problem, but "stare" at too much. I tested this again. Of course, it isn't enable-checking that generates bad code. But the "safe" non-bitfield code now does -- produces a crashing cm3 I386_DARWIN. I haven't looked into it, just that I tried it again. It also still generates less efficient code, at least when not optmizing. The add is a separate instruction, instead of building it in as an offset into the dereferencing instruction. You probably know that already. Perhaps the problem is applying the non-bitfield code for, um, bitfields? For offsets/sizes that aren't multiples of BITS_PER_UNIT? (er..I guess only offsets are relevant here). I'll try that. - Jay From jkrell at elego.de Tue Oct 19 10:03:29 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 19 Oct 2010 10:03:29 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101019080329.EBB8ACC85B@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/19 10:03:29 Modified files: cm3/m3-sys/m3back/src/: Codex86.i3 Codex86.m3 M3x86.m3 Log message: back to bt/bts/btr/btc instructions for set_member, set_singleton They are not in fact slow/atomic, I was mislead by a comment in gcc/config/i386/i386.md and I thought other finds on the Internet. From jkrell at elego.de Tue Oct 19 10:45:09 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 19 Oct 2010 10:45:09 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101019084509.C102ECC85B@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/19 10:45:09 Modified files: cm3/m3-sys/m3back/src/: Codex86.m3 M3x86.m3 M3x86Rep.i3 Stackx86.m3 Log message: rename TypeIs64 to TypeIsDoubleInt many other "64" remain however and I doubt we'll retarget this to AMD64 or any other architecture more likely to generate C In gcc parlance, SI is single int, 32bits, DI is double int, 64bits however here that's not what I mean, but rather an integer that uses two registers. It is tempting to call it just "double", but that means double precision floating point. From jkrell at elego.de Tue Oct 19 10:46:28 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 19 Oct 2010 10:46:28 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101019084628.917B3CC85B@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/19 10:46:28 Modified files: cm3/m3-sys/m3back/src/: M3x86.m3 Log message: just some whitespace changes From jkrell at elego.de Tue Oct 19 10:55:23 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 19 Oct 2010 10:55:23 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101019085523.738F4CC85B@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/19 10:55:23 Modified files: cm3/m3-sys/m3back/src/: Codex86.m3 M3x86.m3 M3x86Rep.i3 Stackx86.m3 Log message: go back from IsTypeDoubleInt to IsType64 From jkrell at elego.de Tue Oct 19 11:49:27 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 19 Oct 2010 11:49:27 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101019094927.203A0CC85B@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/19 11:49:27 Added files: cm3/scripts/win/: dos2unix.c Log message: copy of cvs.c From jkrell at elego.de Tue Oct 19 12:13:33 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 19 Oct 2010 12:13:33 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101019101333.340CDCC85B@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/19 12:13:33 Modified files: cm3/scripts/win/: dos2unix.c Log message: change it from cvs to dos2unix From jkrell at elego.de Tue Oct 19 12:27:54 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 19 Oct 2010 12:27:54 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101019102754.D9DFDCC85B@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/19 12:27:54 Modified files: cm3/scripts/win/: dos2unix.c cvs.c Log message: smaller From jkrell at elego.de Tue Oct 19 12:28:17 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 19 Oct 2010 12:28:17 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101019102817.231E1CC85B@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/19 12:28:17 Modified files: cm3/scripts/win/: dos2unix.c Log message: fix comment From jkrell at elego.de Tue Oct 19 12:28:54 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 19 Oct 2010 12:28:54 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101019102854.EA19CCC85B@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/19 12:28:54 Modified files: cm3/scripts/win/: cvs.c Log message: whitespace From jkrell at elego.de Tue Oct 19 12:55:40 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 19 Oct 2010 12:55:40 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101019105540.58DBFCC85B@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/19 12:55:40 Modified files: cm3/m3-sys/m3back/src/: Codex86.i3 Codex86.m3 M3x86.m3 Stackx86.i3 Stackx86.m3 Log message: atomic add, sub, xor of 32bit variables don't need to use compare/exchange loop (not enabled, not tested, odds of working slim, but it is in the right direction) From jkrell at elego.de Wed Oct 20 00:28:02 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 20 Oct 2010 0:28:02 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101019222804.7786BCC85A@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/20 00:28:02 Modified files: cm3/m3-sys/m3back/src/: M3x86.m3 Log message: xor is not reversible -- the new value is in memory and not atomically readable; only add/sub are reversible From jkrell at elego.de Wed Oct 20 09:47:36 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 20 Oct 2010 9:47:36 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101020074737.29882CC85B@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/20 09:47:36 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: typedef const char* PCSTR; typedef unsigned char UCHAR; typedef unsigned int UINT; typedef unsigned long ULONG; typedef unsigned HOST_WIDE_INT UWIDE; From jkrell at elego.de Wed Oct 20 11:37:23 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 20 Oct 2010 11:37:23 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101020093724.29F0ECC859@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/20 11:37:23 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: typedef char* PSTR; typedef HOST_WIDE_INT WIDE; #define WIDE_PRINT_HEX HOST_WIDE_INT_PRINT_HEX #define WIDE_PRINT_DEC HOST_WIDE_INT_PRINT_DEC From jkrell at elego.de Thu Oct 21 08:43:21 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 21 Oct 2010 8:43:21 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101021064321.B8D13CC127@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/21 08:43:21 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: cosmetic -- casts to ULONG in tracing, uppercase %lX in tracing, remove space in cast operator From jkrell at elego.de Thu Oct 21 09:14:49 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 21 Oct 2010 9:14:49 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101021071452.6BD352474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/21 09:14:48 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: remove whitespace from ends of lines From jkrell at elego.de Thu Oct 21 09:21:49 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 21 Oct 2010 9:21:49 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101021072149.CAC7CCC127@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/21 09:21:49 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: long => WIDE so that 32bit hosts can target 64bit and access fields/sizes beyond 2GB (some of these should probably be UWIDE but that ignored) From jkrell at elego.de Thu Oct 21 09:39:43 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 21 Oct 2010 9:39:43 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101021073943.D6F23CC127@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/21 09:39:43 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: add pointer_size and bits_per_unit visible in debugger, unlike the macros BITS_PER_UNIT, POINTER_SIZE From jkrell at elego.de Thu Oct 21 09:53:08 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 21 Oct 2010 9:53:08 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101021075309.0B94C2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/21 09:53:08 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: cosmetic; more substantial coming soon From jkrell at elego.de Thu Oct 21 12:45:19 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 21 Oct 2010 12:45:19 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101021104520.110052474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/21 12:45:19 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: exprerimental work in progress, but actually making progress (disabled here) added function m3_deduce_field_reference and it sometimes work note that it uses linear search, lame would be really great to do something else here.. fields should probably be given typeids, based on their containing record and name or offset, and then we can use binary search against all fields, OR fields should be given small indices 0..n per containing record struct lang_type could/should be brought to bear note that array references still have nothing done for them (even this m3_deduce_field_reference isn't really doing anything yet) widen current_record_size from ULONG to UWIDE so 32bit host can target 64bit and deal with large records (frontend is still broken here, due to use of INTEGER instead of Target.Int or LONGINT (32bit C implementations have had 64bit integers for something like 20 years now..) fix type comparison in load/store to account for the fact that we now have many pointer types -- make all pointer types compare equal change the level of indirection on pointers to records This might fix debugging them, not yet tested. From jkrell at elego.de Thu Oct 28 09:18:55 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 28 Oct 2010 9:18:55 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101028071855.EA73A2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/28 09:18:55 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: o => offset declare subranges properly work in progress: declare open arrays properly introduce UNSIGNED_INTEGER besides INTEGER among the marshaling macros -- that assert the value is >= 0 and use it a lot change more types to WIDE or UWIDE disabled prototype to find where type information is inadequate (e.g. open arrays) From jkrell at elego.de Fri Oct 29 21:13:43 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 29 Oct 2010 21:13:43 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101029191343.E3AE02474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/29 21:13:43 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: consider VIEW_CONVERT_EXPR for loophole From jkrell at elego.de Fri Oct 29 21:14:56 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 29 Oct 2010 21:14:56 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101029191456.210E42474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/29 21:14:56 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: m3gty43.h m3gty45.h Log message: I forgot to commit these files. From jkrell at elego.de Sun Oct 31 13:33:18 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 31 Oct 2010 13:33:18 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101031123318.EEADECC12B@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/31 13:33:18 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: loophole: for integer to integer, continue using cast otherwise, assert the types are equal size and use view_convert I looked at m3core and libm3, but I forget what happened in m3core, possibly nothing. In libm3, unoptimized, this affected only Transform.Hash and PickleStubs.SwapReal, both slightly positively. In the optimized case, this affected only Transform.Hash, a slight reordering but not any obvious improvement. (Maybe it is slightly faster but it isn't *obvious*.) loophole is of course rare. We might want to do similar in load/store, which will have bigger effect. From jkrell at elego.de Sun Oct 31 13:38:55 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 31 Oct 2010 13:38:55 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101031123855.86D2ECC12B@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/31 13:38:55 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: fix unfortunate gcc warnings From jkrell at elego.de Sun Oct 31 13:52:08 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 31 Oct 2010 13:52:08 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101031125208.8903BCC12B@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/31 13:52:08 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: m3gty45.h Log message: work in progress: in-memory deserialized form of m3cg, use a union, use the property gty annotations for union From jkrell at elego.de Sun Oct 31 14:14:47 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 31 Oct 2010 14:14:47 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101031131447.6A82BCC12B@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/31 14:14:47 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c m3gty43.h m3gty45.h Log message: remove all the type stuff, I'm not sure it will be structured that way From jkrell at elego.de Sun Oct 31 14:49:22 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 31 Oct 2010 14:49:22 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101031134922.AAE1FCC12B@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/31 14:49:22 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: -O3 is broken again disable some optimizations I checked and it didn't seem to be caused the loophole/view_convert change or the subrange declaration change. From jkrell at elego.de Sun Oct 31 14:58:13 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 31 Oct 2010 14:58:13 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101031135813.F165FCC12B@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/31 14:58:13 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: allow back a few optimizations From jkrell at elego.de Sun Oct 31 21:55:28 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 31 Oct 2010 21:55:28 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101031205528.C7B99CC12B@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/31 21:55:28 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: allow back a few more optimizations From jkrell at elego.de Sun Oct 31 23:09:42 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 31 Oct 2010 23:09:42 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101031220942.843F7CC12B@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/31 23:09:42 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: allow two more optimizations unfortunately, dead store elimination seems to be the problem dead store elimination is a nice sound optimization disabled prototype to use view_convert on load/store this seemed to break things From jkrell at elego.de Sun Oct 31 23:37:40 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 31 Oct 2010 23:37:40 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20101031223740.B536CCC12B@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/10/31 23:37:40 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: alas: == package /Users/jay/dev2/cm3/m3-demo/fisheye == ../src/GraphData.m3: In function 'GraphData__ReadEdge': ../src/GraphData.m3:308:0: internal compiler error: in create_tmp_var, at gimplify.c:505 so disable a few optimizations again