From jayk123 at hotmail.com Sat Mar 11 13:38:51 2017 From: jayk123 at hotmail.com (Jay K) Date: Sat, 11 Mar 2017 12:38:51 +0000 Subject: [M3devel] subtle IR differences for platforms that are really the same Message-ID: Trying to get back into things..not sure I sent this from a while ago.. This is both a question and an explanation of hopefully an uncoming chnage, if I figure it out. Most platforms are almost the same. For example I386_FREEBSD and I386_NETBSD. You want their IR to generally be the same, along as they aren't printing their actual target name. And they mostly are. Here is a difference for example: jair:libm3 jay$ diff -du I386_NETBSD/NullRd.mc.txt I386_FREEBSD/NullRd.mc.txt --- I386_NETBSD/NullRd.mc.txt 2016-06-30 19:13:11.000000000 -0700 +++ I386_FREEBSD/NullRd.mc.txt 2016-06-30 19:13:23.000000000 -0700 @@ -44,7 +44,6 @@ declare_procedure NullRd__Length 1 Int.32 0 0 F * p.7 declare_param rd 4 4 Addr 34129018 F F 50 v.10 declare_local _result 4 4 Int.32 425470580 F F 50 v.11 - reveal_opaque 34129018 -885236436 declare_opaque 483796623 -1651526519 declare_proctype -2116580915 2 -915982019 2 0 declare_formal n -1746782238 @@ -85,6 +84,7 @@ declare_field closed 416 8 509158269 declare_field seekable 424 8 509158269 declare_field intermittent 432 8 509158269 + reveal_opaque 34129018 -885236436 # Init -----LINE 22 ----- begin_procedure p.5 One line of the IR is moved. The meaning is the same (the IR is somewhat order-independent, e.g. for type declarations). What causes this? Do we output sometimes in hash order? And target affects that? Or when buffers fill up, and target length can affect that? I'd like to remove these differences. If it is a buffer length matter, I might just expand the buffers, as systems have far far more memory than when this was all written. If it is hash ordering matter -- one should avoid outputting data in hash order. so: 1. if anyone knows the difference, please tell me, before I debug it? 2. Ok if I make changes to converge the IR, i.e. I386_LINUX/Darwin/Solaris/FreeBSD/NetBSD/OpenBSD/Interix should all be the same, AMD64/ditto, SPARC32/ditto, SPARC64/ditto. Only variation should be endian and word size, and maybe NT vs. Posix but probably not. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Sat Mar 11 23:12:53 2017 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sat, 11 Mar 2017 16:12:53 -0600 Subject: [M3devel] subtle IR differences for platforms that are really the same In-Reply-To: References: Message-ID: Hmm, looks like all reveal_opaque ops in a unit are are emitted at one time by Revelation.Declare. It uses a "Set" that has both a linear linked list and a hash table. The hash table sounds suspicious, but at a glance, I don't see anything other than all the reveal_opaque's being emitted here, with nothing interspersed. So that would only reorder multiple reveal_opaque's relative to each other, with nothing in between them. If there is only one, maybe something about the calls to Revelation.Declare in Module.CompileModule? The comment at :979: (**** moved below **** External.GenImports (t.externals); *) would change where the reveal_opaque's were relative to other things. Are both targets compiled using identical source code for Module.m3? On 03/11/2017 06:38 AM, Jay K wrote: > Trying to get back into things..not sure I sent this from a while ago.. > > > > This is both a question and an explanation > of hopefully an uncoming chnage, if I figure it out. > > > Most platforms are almost the same. > > For example I386_FREEBSD and I386_NETBSD. > > You want their IR to generally be the same, along > as they aren't printing their actual target name. > > And they mostly are. > > Here is a difference for example: > > jair:libm3 jay$ diff -du I386_NETBSD/NullRd.mc.txt I386_FREEBSD/NullRd.mc.txt > --- I386_NETBSD/NullRd.mc.txt 2016-06-30 19:13:11.000000000 -0700 > +++ I386_FREEBSD/NullRd.mc.txt 2016-06-30 19:13:23.000000000 -0700 > @@ -44,7 +44,6 @@ > declare_procedure NullRd__Length 1 Int.32 0 0 F * p.7 > declare_param rd 4 4 Addr 34129018 F F 50 v.10 > declare_local _result 4 4 Int.32 425470580 F F 50 v.11 > - reveal_opaque 34129018 -885236436 > declare_opaque 483796623 -1651526519 > declare_proctype -2116580915 2 -915982019 2 0 > declare_formal n -1746782238 > @@ -85,6 +84,7 @@ > declare_field closed 416 8 509158269 > declare_field seekable 424 8 509158269 > declare_field intermittent 432 8 509158269 > + reveal_opaque 34129018 -885236436 > # Init > -----LINE 22 ----- > begin_procedure p.5 > > > One line of the IR is moved. > The meaning is the same (the IR is somewhat order-independent, e.g. for type declarations). > > What causes this? > > Do we output sometimes in hash order? > And target affects that? > > Or when buffers fill up, and target length can affect that? > > I'd like to remove these differences. > If it is a buffer length matter, I might just expand the buffers, > as systems have far far more memory than when this was all written. > > > If it is hash ordering matter -- one should avoid outputting data > in hash order. > > so: > 1. if anyone knows the difference, please tell me, before I debug it? > 2. Ok if I make changes to converge the IR, i.e. I386_LINUX/Darwin/Solaris/FreeBSD/NetBSD/OpenBSD/Interix should all > be the same, AMD64/ditto, SPARC32/ditto, SPARC64/ditto. Only variation should be endian and word size, > and maybe NT vs. Posix but probably not. > > - Jay > > > > > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://m3lists.elegosoft.com/mailman/listinfo/m3devel > -- Rodney Bates rodney.m.bates at acm.org From jayk123 at hotmail.com Sat Mar 11 23:20:37 2017 From: jayk123 at hotmail.com (Jay K) Date: Sat, 11 Mar 2017 22:20:37 +0000 Subject: [M3devel] subtle IR differences for platforms that are really the same In-Reply-To: References: , Message-ID: > same source? I did this a while ago but yes I suspect so. I'll have to restart the experiment. - Jay ________________________________ From: M3devel on behalf of Rodney M. Bates Sent: Saturday, March 11, 2017 10:12 PM To: m3devel at elegosoft.com Subject: Re: [M3devel] subtle IR differences for platforms that are really the same Hmm, looks like all reveal_opaque ops in a unit are are emitted at one time by Revelation.Declare. It uses a "Set" that has both a linear linked list and a hash table. The hash table sounds suspicious, but at a glance, I don't see anything other than all the reveal_opaque's being emitted here, with nothing interspersed. So that would only reorder multiple reveal_opaque's relative to each other, with nothing in between them. If there is only one, maybe something about the calls to Revelation.Declare in Module.CompileModule? The comment at :979: (**** moved below **** External.GenImports (t.externals); *) would change where the reveal_opaque's were relative to other things. Are both targets compiled using identical source code for Module.m3? On 03/11/2017 06:38 AM, Jay K wrote: > Trying to get back into things..not sure I sent this from a while ago.. > > > > This is both a question and an explanation > of hopefully an uncoming chnage, if I figure it out. > > > Most platforms are almost the same. > > For example I386_FREEBSD and I386_NETBSD. > > You want their IR to generally be the same, along > as they aren't printing their actual target name. > > And they mostly are. > > Here is a difference for example: > > jair:libm3 jay$ diff -du I386_NETBSD/NullRd.mc.txt I386_FREEBSD/NullRd.mc.txt > --- I386_NETBSD/NullRd.mc.txt 2016-06-30 19:13:11.000000000 -0700 > +++ I386_FREEBSD/NullRd.mc.txt 2016-06-30 19:13:23.000000000 -0700 > @@ -44,7 +44,6 @@ > declare_procedure NullRd__Length 1 Int.32 0 0 F * p.7 > declare_param rd 4 4 Addr 34129018 F F 50 v.10 > declare_local _result 4 4 Int.32 425470580 F F 50 v.11 > - reveal_opaque 34129018 -885236436 > declare_opaque 483796623 -1651526519 > declare_proctype -2116580915 2 -915982019 2 0 > declare_formal n -1746782238 > @@ -85,6 +84,7 @@ > declare_field closed 416 8 509158269 > declare_field seekable 424 8 509158269 > declare_field intermittent 432 8 509158269 > + reveal_opaque 34129018 -885236436 > # Init > -----LINE 22 ----- > begin_procedure p.5 > > > One line of the IR is moved. > The meaning is the same (the IR is somewhat order-independent, e.g. for type declarations). > > What causes this? > > Do we output sometimes in hash order? > And target affects that? > > Or when buffers fill up, and target length can affect that? > > I'd like to remove these differences. > If it is a buffer length matter, I might just expand the buffers, > as systems have far far more memory than when this was all written. > > > If it is hash ordering matter -- one should avoid outputting data > in hash order. > > so: > 1. if anyone knows the difference, please tell me, before I debug it? > 2. Ok if I make changes to converge the IR, i.e. I386_LINUX/Darwin/Solaris/FreeBSD/NetBSD/OpenBSD/Interix should all > be the same, AMD64/ditto, SPARC32/ditto, SPARC64/ditto. Only variation should be endian and word size, > and maybe NT vs. Posix but probably not. > > - Jay > > > > > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://m3lists.elegosoft.com/mailman/listinfo/m3devel > -- Rodney Bates rodney.m.bates at acm.org _______________________________________________ M3devel mailing list M3devel at elegosoft.com https://m3lists.elegosoft.com/mailman/listinfo/m3devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Mon Mar 13 00:28:00 2017 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sun, 12 Mar 2017 23:28:00 +0000 (UTC) Subject: [M3devel] subtle IR differences for platforms that are really the same In-Reply-To: References: Message-ID: <1505132347.5413335.1489361280649@mail.yahoo.com> Hi Jay and all:if it doesn't bother try to read the first chapter of UWM CS Chair Johhn Boyland on his PhD Thesis. He cites in its examples Gcc and Modula-3 rational, although he develops an internal laanguage to handle compiler phases to Gcc RTL (and C). It's almost 500 pages, and uses Oberon2; I know he from a long time while I was in the US studying language theoretic things. Hope you find it fun.https://www2.eecs.berkeley.edu/Pubs/TechRpts/1996/5816.html Thanks in advance El S?bado 11 de marzo de 2017 17:21, Jay K escribi?: #yiv0943922932 #yiv0943922932 -- P {margin-top:0;margin-bottom:0;}#yiv0943922932 > same source? I did this a while ago but yes I suspect so. I'll have to restart the experiment. ?- Jay From: M3devel on behalf of Rodney M. Bates Sent: Saturday, March 11, 2017 10:12 PM To: m3devel at elegosoft.com Subject: Re: [M3devel] subtle IR differences for platforms that are really the same?Hmm, looks like all reveal_opaque ops in a unit are are emitted at one time by Revelation.Declare.? It uses a "Set" that has both a linear linked list and a hash table.? The hash table sounds suspicious, but at a glance, I don't see anything other than all the reveal_opaque's being emitted here, with nothing interspersed. So that would only reorder multiple reveal_opaque's relative to each other, with nothing in between them. If there is only one, maybe something about the calls to Revelation.Declare in Module.CompileModule?? The comment at :979: ? (**** moved below **** External.GenImports (t.externals); *) would change where the reveal_opaque's were relative to other things. Are both targets compiled using identical source code for Module.m3? On 03/11/2017 06:38 AM, Jay K wrote: > Trying to get back into things..not sure I sent this from a while ago.. > > > > This is both a question and an explanation > of hopefully an uncoming chnage, if I figure it out. > > > Most platforms are almost the same. > > For example I386_FREEBSD and I386_NETBSD. > > You want their IR to generally be the same, along > as they aren't printing their actual target name. > > And they mostly are. > > Here is a difference for example: > > jair:libm3 jay$ diff -du I386_NETBSD/NullRd.mc.txt I386_FREEBSD/NullRd.mc.txt > --- I386_NETBSD/NullRd.mc.txt??? 2016-06-30 19:13:11.000000000 -0700 > +++ I386_FREEBSD/NullRd.mc.txt??? 2016-06-30 19:13:23.000000000 -0700 > @@ -44,7 +44,6 @@ >????? declare_procedure???? NullRd__Length 1 Int.32 0 0 F * p.7 >????? declare_param???? rd 4 4 Addr 34129018 F F 50 v.10 >????? declare_local???? _result 4 4 Int.32 425470580 F F 50 v.11 > -??? reveal_opaque???? 34129018 -885236436 >????? declare_opaque???? 483796623 -1651526519 >????? declare_proctype???? -2116580915 2 -915982019 2 0 >????? declare_formal???? n -1746782238 > @@ -85,6 +84,7 @@ >????? declare_field???? closed 416 8 509158269 >????? declare_field???? seekable 424 8 509158269 >????? declare_field???? intermittent 432 8 509158269 > +??? reveal_opaque???? 34129018 -885236436 >????? # Init >????????????????????? -----LINE 22? ----- >????? begin_procedure???? p.5 > > > One line of the IR is moved. > The meaning is the same (the IR is somewhat order-independent, e.g. for type declarations). > > What causes this? > > Do we output sometimes in hash order? > And target affects that? > > Or when buffers fill up, and target length can affect that? > > I'd like to remove these differences. > If it is a buffer length matter, I might just expand the buffers, > as systems have far far more memory than when this was all written. > > > If it is hash ordering matter -- one should avoid outputting data > in hash order. > > so: > 1. if anyone knows the difference, please tell me, before I debug it? > 2. Ok if I make changes to converge the IR, i.e. I386_LINUX/Darwin/Solaris/FreeBSD/NetBSD/OpenBSD/Interix should all > be the same, AMD64/ditto, SPARC32/ditto, SPARC64/ditto. Only variation should be endian and word size, > and maybe NT vs. Posix but probably not. > >? - Jay > > > > > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://m3lists.elegosoft.com/mailman/listinfo/m3devel > -- Rodney Bates rodney.m.bates at acm.org _______________________________________________ M3devel mailing list M3devel at elegosoft.com https://m3lists.elegosoft.com/mailman/listinfo/m3devel _______________________________________________ M3devel mailing list M3devel at elegosoft.com https://m3lists.elegosoft.com/mailman/listinfo/m3devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Wed Mar 15 09:37:53 2017 From: jayk123 at hotmail.com (Jay K) Date: Wed, 15 Mar 2017 08:37:53 +0000 Subject: [M3devel] compiler switch "reduce target variation"? Message-ID: Tangent: Should we start use git branches and pull requests? Are people here reasonable able to view textual diffs? It pushes my limits personally. But I know some developers work this way. This is some old stuff I was working on. I kinda think it should be the default, but almost everyone here protests almost all of my changes, so here is a new switch instead. The idea is to remove somewhat gratituous target variation. One would have to argue over each difference and if it is gratuitous and if it should be removed by default, or under a switch, and which switch. So I'm proposing generally one switch to put everything under. The differences I had noticed in my investigation months ago is the name of the TARGET appearing, for example in paths. Such as maybe in generic instantiations, in debug symbols, in output logs. I actually think debug symbols need full paths, and so for generics, they end up with target. But for now, I desist on that agenda in favor of rougly the opposite. The goal here, as I mentioned before, is to establish that I386_LINUX == I386_FREEBSD == I386_NETBSD == I386_OPENBSD == I386_SOLARIS == I386_DARWIN == I386_CYGWIN == I386_SOLARIS maybe == I386_NT ditto AMD64, SPARC32, SPARC64, PPC32, PPC64, etc. So that we might collapse targets down. A soon/later step would establish even fewer equivalence classes: PP32be == SPARC32, PPC64be == SPARC64, => BigEndian64 or PosixBigEndian64 I386 == ARM => LittleEndian32 AMD64 == ARM64 == PPC64le => LittleEndian64 etc. and then eventually we could have one or a small number of C-based distributions. I have to go back and build and test all this anew. Reasonable? Maybe the default? Maybe add a switch for restore-target-difference or preserve-target-differences? diff --git a/m3-sys/cm3/src/Main.m3 b/m3-sys/cm3/src/Main.m3 index 5d753e6..61b3f18 100644 --- a/m3-sys/cm3/src/Main.m3 +++ b/m3-sys/cm3/src/Main.m3 @@ -5,7 +5,7 @@ MODULE Main; IMPORT M3Timers, Pathname, Process, Quake; IMPORT RTCollector, RTParams, RTutils, Thread, Wr; -IMPORT TextTextTbl; +IMPORT TextTextTbl, Target; IMPORT Builder, Dirs, M3Build, M3Options, Makefile, Msg, Utils, WebFile; IMPORT MxConfig(*, M3Config, CMKey, CMCurrent *); @@ -18,6 +18,8 @@ VAR build_dir : TEXT := NIL; mach : Quake.Machine := NIL; +CONST BoolToText = ARRAY BOOLEAN OF TEXT{"FALSE", "TRUE"}; + PROCEDURE DefineIfNotDefined (qmachine: Quake.Machine; symbol, value: TEXT) RAISES {Quake.Error} = BEGIN @@ -73,6 +75,7 @@ VAR defs: TextTextTbl.T; (* DefineIfNotDefined (mach, "THREAD_LIBRARY", Version.ThreadLibrary); *) (* DefineIfNotDefined (mach, "WINDOW_LIBRARY", Version.WindowLibrary); *) DefineIfNotDefined (mach, "WORD_SIZE", MxConfig.HOST_WORD_SIZE); + DefineIfNotDefined (mach, "REDUCE_TARGET_VARIATION", BoolToText[Target.ReduceTargetVariation]); (* Even if the config file overrides the defaults, such as to do a cross build, the host characteristics are still available. *) diff --git a/m3-sys/cm3/src/Makefile.m3 b/m3-sys/cm3/src/Makefile.m3 index 64e169e..f2e1c7b 100644 --- a/m3-sys/cm3/src/Makefile.m3 +++ b/m3-sys/cm3/src/Makefile.m3 @@ -5,7 +5,7 @@ MODULE Makefile; IMPORT FS, M3File, M3Timers, OSError, Params, Process, Text, Thread, Wr; IMPORT Arg, M3Build, M3Options, M3Path, Msg, Utils, TextSeq, TextTextTbl; -IMPORT MxConfig, Dirs, Version; +IMPORT MxConfig, Dirs, Version, Target; TYPE NK = M3Path.Kind; @@ -267,6 +267,9 @@ PROCEDURE ConvertOption (VAR s: State; arg: TEXT; arg_len: INTEGER) | 'r' => IF Text.Equal(arg, "-realclean") THEN ok := TRUE; (* mode set during the pre-scan *) s.found_work := TRUE; + ELSIF Text.Equal(arg, "-reduce-target-variation") THEN + ok := TRUE; + Target.ReduceTargetVariation := TRUE; END; | 's' => IF Text.Equal (arg, "-silent") THEN @@ -707,6 +710,9 @@ CONST " -group-writable \"", " -pb allow parallelism in running back-end (experimental)", " -no-m3ship-resolution use quake variables in .M3SHIP (experimental)", + " -reduce-target-variation omit target in some minor places such as", + " current working directory in debug information", + " for internal development purposes (showing target equivalence)", "", "environment variables:", " M3CONFIG platform dependent configuration file to use (cm3.cfg)", diff --git a/m3-sys/cminstall/src/config-no-install/cm3cfg.common b/m3-sys/cminstall/src/config-no-install/cm3cfg.common index 7334252..42db06f 100644 --- a/m3-sys/cminstall/src/config-no-install/cm3cfg.common +++ b/m3-sys/cminstall/src/config-no-install/cm3cfg.common @@ -458,8 +458,14 @@ proc GetM3Back() is else if equal(HOST, TARGET) m3back = INSTALL_ROOT & "/bin/" end end - + m3back = "@" & m3back & "cm3cg " & GetM3BackFlags() + + if defined ("REDUCE_TARGET_VARIATION") + if REDUCE_TARGET_VARIATION + m3back = m3back & " -freduce-target-variation" + end + end return m3back end diff --git a/m3-sys/m3back/src/M3C.m3 b/m3-sys/m3back/src/M3C.m3 index f6740c7..d584fea 100644 --- a/m3-sys/m3back/src/M3C.m3 +++ b/m3-sys/m3back/src/M3C.m3 @@ -29,7 +29,7 @@ VAR CaseDefaultAssertFalse := FALSE; (* Taken together, these help debugging, as you get more lines in the C and the error messages reference C line numbers *) - CONST output_line_directives = TRUE; + VAR output_line_directives := TRUE; CONST output_extra_newlines = FALSE; CONST inline_extract = FALSE; @@ -2197,7 +2197,9 @@ BEGIN END; IF (*self.suppress_line_directive < 1 AND*) text_last_char = '\n' THEN - Wr.PutText(self.c, self.line_directive); + IF NOT Target.ReduceTargetVariation THEN + Wr.PutText(self.c, self.line_directive); + END; self.width := 0; self.last_char_was_newline := TRUE; RETURN; @@ -2205,7 +2207,9 @@ BEGIN IF Text.FindChar(text, '\n') # -1 THEN self.width := 0; (* roughly *) - Wr.PutText(self.c, self.nl_line_directive); + IF NOT Target.ReduceTargetVariation THEN + Wr.PutText(self.c, self.nl_line_directive); + END; self.last_char_was_newline := TRUE; RETURN; END; @@ -2217,10 +2221,12 @@ BEGIN END; self.width := 0; - IF self.last_char_was_newline THEN - Wr.PutText(self.c, self.line_directive); - ELSE - Wr.PutText(self.c, self.nl_line_directive); + IF NOT Target.ReduceTargetVariation THEN + IF self.last_char_was_newline THEN + Wr.PutText(self.c, self.line_directive); + ELSE + Wr.PutText(self.c, self.nl_line_directive); + END; END; self.last_char_was_newline := TRUE; END print; @@ -2339,9 +2345,10 @@ END set_error_handler; PROCEDURE Prefix_Print(self: T; multipass: Multipass_t) = BEGIN self.comment("begin unit"); - self.comment("M3_TARGET = ", Target.System_name); - (* This is an unnecessary target-specific output. *) - (* self.comment("M3_TARGET = ", Target.System_name); *) + output_line_directives := output_line_directives AND NOT Target.ReduceTargetVariation; + IF NOT Target.ReduceTargetVariation THEN + self.comment("M3_TARGET = ", Target.System_name); + END; self.comment("M3_WORDSIZE = ", IntToDec(Target.Word.size)); self.static_link_id := M3ID.Add("_static_link"); self.alloca_id := M3ID.Add("alloca"); @@ -4836,7 +4843,8 @@ BEGIN & " ok2=" & BoolToText[ok2] & "\n" ); RTIO.Flush(); - <* ASSERT FALSE *> + <* ASSERT ok1 *> + <* ASSERT ok2 *> END; IF type = CGType.Int32 AND TInt.EQ(i, TInt.Min32) THEN RETURN "-" & intLiteralPrefix[type] & TInt.ToText(TInt.Max32) & intLiteralSuffix[type] & "-1"; diff --git a/m3-sys/m3cc/gcc-4.7/gcc/dbxout.c b/m3-sys/m3cc/gcc-4.7/gcc/dbxout.c index dc52576..33f8844 100644 --- a/m3-sys/m3cc/gcc-4.7/gcc/dbxout.c +++ b/m3-sys/m3cc/gcc-4.7/gcc/dbxout.c @@ -1065,8 +1065,11 @@ dbxout_init (const char *input_file_name) labels. */ ASM_GENERATE_INTERNAL_LABEL (ltext_label_name, "Ltext", 0); - /* Put the current working directory in an N_SO symbol. */ - if (use_gnu_debug_info_extensions && !NO_DBX_MAIN_SOURCE_DIRECTORY) + /* Limit paths in debug output, to limit target variation. */ + if (!reduce_target_variation) + { + /* Put the current working directory in an N_SO symbol. */ + if (use_gnu_debug_info_extensions && !NO_DBX_MAIN_SOURCE_DIRECTORY) { static const char *cwd; @@ -1087,6 +1090,7 @@ dbxout_init (const char *input_file_name) used_ltext_label_name = true; #endif /* no DBX_OUTPUT_MAIN_SOURCE_DIRECTORY */ } + } mapped_name = remap_debug_filename (input_file_name); #ifdef DBX_OUTPUT_MAIN_SOURCE_FILENAME diff --git a/m3-sys/m3cc/gcc-4.7/gcc/dwarf2out.c b/m3-sys/m3cc/gcc-4.7/gcc/dwarf2out.c index 6f60742..291aea3 100644 --- a/m3-sys/m3cc/gcc-4.7/gcc/dwarf2out.c +++ b/m3-sys/m3cc/gcc-4.7/gcc/dwarf2out.c @@ -15450,15 +15450,18 @@ add_gnat_descriptive_type_attribute (dw_die_ref die, tree type, static void add_comp_dir_attribute (dw_die_ref die) { + /* Limit paths in debug output, to limit target variation. */ + if (reduce_target_variation) + return; + const char *wd = get_src_pwd (); - char *wd1; if (wd == NULL) return; if (DWARF2_DIR_SHOULD_END_WITH_SEPARATOR) { - int const wdlen = (int)strlen (wd); + size_t const wdlen = strlen (wd); char * const wd1 = (char *) ggc_alloc_atomic (wdlen + 2); memcpy (wd1, wd, wdlen); wd1 [wdlen] = DIR_SEPARATOR; diff --git a/m3-sys/m3cc/gcc-4.7/gcc/toplev.c b/m3-sys/m3cc/gcc-4.7/gcc/toplev.c index 63e4b92..d468632 100644 --- a/m3-sys/m3cc/gcc-4.7/gcc/toplev.c +++ b/m3-sys/m3cc/gcc-4.7/gcc/toplev.c @@ -217,11 +217,8 @@ const char * get_src_pwd (void) { if (! src_pwd) - { - src_pwd = getpwd (); - if (!src_pwd) - src_pwd = "."; - } + if (reduce_target_variation || !(src_pwd = getpwd ())) + src_pwd = "."; return src_pwd; } diff --git a/m3-sys/m3cc/gcc-4.7/gcc/toplev.h b/m3-sys/m3cc/gcc-4.7/gcc/toplev.h index 588cfdb..f4f7cc7 100644 --- a/m3-sys/m3cc/gcc-4.7/gcc/toplev.h +++ b/m3-sys/m3cc/gcc-4.7/gcc/toplev.h @@ -80,4 +80,6 @@ extern bool set_src_pwd (const char *); extern HOST_WIDE_INT get_random_seed (bool); extern const char *set_random_seed (const char *); +extern bool reduce_target_variation; + #endif /* ! GCC_TOPLEV_H */ diff --git a/m3-sys/m3cc/gcc/gcc/m3cg/lang.opt b/m3-sys/m3cc/gcc/gcc/m3cg/lang.opt index 3bd0469..cb0189f 100644 --- a/m3-sys/m3cc/gcc/gcc/m3cg/lang.opt +++ b/m3-sys/m3cc/gcc/gcc/m3cg/lang.opt @@ -28,9 +28,6 @@ m3cg Language M3CG -y -m3cg M3CG - fopcodes-trace m3cg M3CG Trace opcodes @@ -59,10 +56,17 @@ ftypes-trace m3cg M3CG Trace types +reduce-target-variation +m3cg M3CG +Reduce target variation somewhat, such as by omitting current working +directory from debug info. Many necessary target variations remain. + v m3cg M3CG +print version y m3cg M3CG +Trace opcodes ; This comment is to ensure we retain the blank line above. diff --git a/m3-sys/m3cc/gcc/gcc/m3cg/parse.c b/m3-sys/m3cc/gcc/gcc/m3cg/parse.c index 03417ed..071bbc8 100644 --- a/m3-sys/m3cc/gcc/gcc/m3cg/parse.c +++ b/m3-sys/m3cc/gcc/gcc/m3cg/parse.c @@ -246,6 +246,7 @@ build_case_label (tree low_value, tree high_value, tree label_decl) /*======================================================= OPTION HANDLING ===*/ static int option_trace_all; +bool reduce_target_variation; /*===========================================================================*/ @@ -6364,6 +6365,10 @@ m3_handle_option (size_t code, PCSTR /*arg*/, int /*value*/) case OPT_ftypes_trace: option_trace_all += 1; break; + + case OPT_reduce_target_variation: + reduce_target_variation = true; + break; } return 1; diff --git a/m3-sys/m3front/src/misc/Coverage.m3 b/m3-sys/m3front/src/misc/Coverage.m3 index c04c902..73fff21 100644 I don't remember what is going on here, but coverage isn't used much.. I suspect it might just have to do with forward vs. backward slashes, and that this distinction does not really matter -- Windows accepts forward slashes so we should just use them everywhere. --- a/m3-sys/m3front/src/misc/Coverage.m3 +++ b/m3-sys/m3front/src/misc/Coverage.m3 @@ -77,8 +77,9 @@ PROCEDURE NoteProcedure (v: Value.T) = PROCEDURE GenerateTables () = VAR nLines := MAX (0, maxLine - minLine) + 1; + fname := Host.FileTail (Host.filename); l_header := TLen (Header); - l_fname := TLen (Host.filename); + l_fname := TLen (fname); l_trailer := TLen (Trailer); size : INTEGER; p : ProcHead; @@ -124,10 +125,10 @@ PROCEDURE GenerateTables () = (* CG.Init_int (size, Target.Integer.size, TInt.Zero, FALSE); *) INC (size, Target.Integer.size); (*timestamp*) - CG.Init_intt (size, Target.Integer.size, Text.Length (Host.filename), FALSE); + CG.Init_intt (size, Target.Integer.size, Text.Length (fname), FALSE); INC (size, Target.Integer.size); (*fileLen*) - CG.Init_chars (size, Host.filename, FALSE); + CG.Init_chars (size, fname, FALSE); INC (size, l_fname * Target.Char.size); (*file*) CG.Init_intt (size, Target.Integer.size, minLine, FALSE); diff --git a/m3-sys/m3front/src/misc/Host.i3 b/m3-sys/m3front/src/misc/Host.i3 index c71489f..af6a89a 100644 --- a/m3-sys/m3front/src/misc/Host.i3 +++ b/m3-sys/m3front/src/misc/Host.i3 @@ -75,4 +75,7 @@ PROCEDURE OpenUnit (name: M3ID.T; interface, generic: BOOLEAN; PROCEDURE CloseFile (rd: File.T); +PROCEDURE FileTail (path: TEXT): TEXT; + (* returns the 'tail' of 'path' -- after any slashes or even spaces *) + END Host. diff --git a/m3-sys/m3front/src/misc/Host.m3 b/m3-sys/m3front/src/misc/Host.m3 index 962d3c6..79042e3 100644 --- a/m3-sys/m3front/src/misc/Host.m3 +++ b/m3-sys/m3front/src/misc/Host.m3 @@ -9,7 +9,7 @@ MODULE Host; -IMPORT File, Text, (*ETimer, M3Timers,*) M3ID, M3Compiler; +IMPORT File, Text, (*ETimer, M3Timers,*) M3ID, M3Compiler, Target; PROCEDURE Initialize (READONLY options: ARRAY OF TEXT): BOOLEAN = BEGIN @@ -192,5 +192,24 @@ PROCEDURE CloseFile (rd: File.T) = END; END CloseFile; +PROCEDURE FileTail (path: TEXT): TEXT = + VAR c: CHAR; + BEGIN + IF NOT Target.ReduceTargetVariation THEN RETURN path; END; + + IF (path = NIL) THEN RETURN NIL END; + + (* search for the last slash or blank in the string *) + FOR x := Text.Length (path) - 1 TO 0 BY -1 DO + c := Text.GetChar (path, x); + IF (c = '/') OR (c = ' ') OR (c = '\\') THEN + RETURN Text.Sub (path, x+1); + END; + END; + + (* no slashes *) + RETURN path; + END FileTail; + BEGIN END Host. diff --git a/m3-sys/m3front/src/misc/M3Header.m3 b/m3-sys/m3front/src/misc/M3Header.m3 index 1e4decf..877d77c 100644 --- a/m3-sys/m3front/src/misc/M3Header.m3 +++ b/m3-sys/m3front/src/misc/M3Header.m3 @@ -104,7 +104,7 @@ PROCEDURE PushGeneric (VAR s: State) = IF (s.generic = NIL) THEN s.failed := TRUE; RETURN; END; (* build a synthetic file name & start reading *) - filename := old_filename & " => " & filename; + filename := Host.FileTail(old_filename) & " => " & filename; Scanner.Push (filename, s.generic, is_main := Scanner.in_main); (* make sure we got what we wanted *) diff --git a/m3-sys/m3front/src/misc/Scanner.m3 b/m3-sys/m3front/src/misc/Scanner.m3 index 7470374..e1dc024 100644 --- a/m3-sys/m3front/src/misc/Scanner.m3 +++ b/m3-sys/m3front/src/misc/Scanner.m3 @@ -228,13 +228,16 @@ PROCEDURE Here (VAR file: TEXT; VAR line: INTEGER) = BEGIN file := files [offset DIV MaxLines]; line := offset MOD MaxLines; + IF Target.ReduceTargetVariation THEN + file := Host.FileTail(file); + END; END Here; PROCEDURE LocalHere (VAR file: TEXT; VAR line: INTEGER) = VAR fnum := offset DIV MaxLines; BEGIN IF (local_files[fnum] = NIL) THEN - local_files[fnum] := files[fnum]; + local_files[fnum] := Host.FileTail(files[fnum]); END; file := local_files [fnum]; line := offset MOD MaxLines; diff --git a/m3-sys/m3front/src/values/Module.m3 b/m3-sys/m3front/src/values/Module.m3 index a085eab..576c857 100644 --- a/m3-sys/m3front/src/values/Module.m3 +++ b/m3-sys/m3front/src/values/Module.m3 @@ -421,7 +421,7 @@ PROCEDURE PushGeneric (t: T; VAR rd: File.T): M3ID.T = END; (* build a synthetic file name & start reading *) - filename := old_filename & " => " & filename; + filename := Host.FileTail(old_filename) & " => " & filename; Scanner.Push (filename, rd, is_main := Scanner.in_main); t.genericFile := filename; diff --git a/m3-sys/m3middle/src/Target.i3 b/m3-sys/m3middle/src/Target.i3 index fe198d2..cd7acee 100644 --- a/m3-sys/m3middle/src/Target.i3 +++ b/m3-sys/m3middle/src/Target.i3 @@ -529,4 +529,8 @@ VAR (*CONST*) test for nested procedures passed as parameters must be more elaborate (e.g. HPPA). *) + (* This removes some unnecessary target variation in the output, + * such as current working directory in debug output. *) + ReduceTargetVariation: BOOLEAN; + END Target. diff --git a/scripts/python/pylib.py b/scripts/python/pylib.py index 73e622f..487ad17 100755 --- a/scripts/python/pylib.py +++ b/scripts/python/pylib.py @@ -388,7 +388,7 @@ def _GetAllTargets(): _CBackend = "c" in sys.argv or "C" in sys.argv _BuildDirC = ["", "c"][_CBackend] -_PossibleCm3Flags = ["boot", "keep", "override", "commands", "verbose", "why"] +_PossibleCm3Flags = ["boot", "keep", "override", "commands", "verbose", "why", "reduce-target-variation", "reducetargetvariation"] _SkipGccFlags = ["nogcc", "skipgcc", "omitgcc"] _PossiblePylibFlags = ["noclean", "nocleangcc", "c", "C"] + _SkipGccFlags + _PossibleCm3Flags @@ -1610,9 +1610,9 @@ def Boot(): Makefile.close() if vms or nt: - _MakeZip(BootDir[2:]) + pass#_MakeZip(BootDir[2:]) else: - _MakeTGZ(BootDir[2:]) + pass#_MakeTGZ(BootDir[2:]) #----------------------------------------------------------------------------- # map action names to code and possibly other data -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Wed Mar 15 10:00:42 2017 From: jayk123 at hotmail.com (Jay K) Date: Wed, 15 Mar 2017 09:00:42 +0000 Subject: [M3devel] no-m3ship-resolution should be the default and only option? Message-ID: Propose: -no-m3ship-resolution be the default and only option Accept and ignore it, always doing what it implies. Specifically: 1) when you ship right after building, the resolutions occurs just after it would have. 2) Is there any advantage to the old behavior? Does it allow some easier bootstrapping across machines that have the same file system layout, but which somehow can't correctly resolve at ship time?? Olaf added this switch a few years ago. I believe it enabled distribution across across machines right before shipping. Basically, probably few people realize this, but cm3 reproduces many many parts of build systems. If you view the traditional build system as configure && make && make install. 1. configure is built in hardcoded for a few platforms (not great) 2. make == cm3 3. cm3 -ship == make install But by default, step #2 actually generates "install scripts" so that #3 has a bit less to do -- it just runs generated quake. What Olaf's switch does, is still generate about the same quake, but paths remain starting with a symbolic prefix instead of full hardcoded paths. I really don't see any reason to favor the old behavior. Again, I propose the old behavior be removed, the switch be accepted and ignored for compatibility, and the new behavior be the only one remaining. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Wed Mar 15 10:14:29 2017 From: jayk123 at hotmail.com (Jay K) Date: Wed, 15 Mar 2017 09:14:29 +0000 Subject: [M3devel] Rants about an improbable release In-Reply-To: <581363DE.9060401@lcwb.coop> References: , <581363DE.9060401@lcwb.coop> Message-ID: I don't think you should worry about when you make IR changes. Make them when you decide they are needed and you have them correct and working. The various build scripts are meant to build things properly no matter when/which such changes are presented. Just please try to update all 3 or 4 backends (gcc, integrated, C, llvm). If not, then do so in some sort of optional way, like how Tony left LONGINT as 32bits on NT386. Regarding a release, I would really like to get the system sooner-than-later to a state where we can distribute it as C. So that installation does not require a working compiler. The 3.6 release was kind of like this, though not quite what I am after. (it distributed C source for quake, assembly source for some parts -- C + assembly to build cm3 (m3build + m3?) -- and then cm3 to build everything else. In my vision, the C/assembly are just C, maybe the entire system...really need to sit a few days and script/python it all out -- I did get over some cmake/autoconf hump a few months -- such that the bootstrap system can use them instead of make directly...) There is still a fair amount of work needed to make this happen though, maybe not worth waiting for. I am somewhat encouraged by the fact that gradually more and more people have tried and succeeded at this. I know the system is confusing, but some people do understand. - Jay ________________________________ From: M3devel on behalf of Rodney M. Bates Sent: Friday, October 28, 2016 2:42 PM To: m3devel at elegosoft.com Subject: Re: [M3devel] Rants about an improbable release I agree, we very much need to make a new release. There has been a lot of development since the last one, especially for having a small developer community. I have often thought I would be willing to do the work to do it, but every time, I get stuck not having any idea what needs to be done. For one thing, I presume it entails verifying that things build and work on all the various targets, which would further entail having access to one of each of them. Are such machines available? Any advice on how to proceed? On a related topic, we need to make some changes to the compiler IR, as defined in M3CG.i3 and M3CG_Ops.i3. I have been collecting a list of my own for some time. This is a lot of (mostly rather mundane) work, and it creates front/back end compatibility issues. It would be best to do as many as possible at one time and get them in before a release, so those not doing compiler development could just use the release without being bothered. Anybody have any changes to propose? On 10/21/2016 12:56 PM, dirk muysers wrote: > If you want to improve your home you go to the builders market and acquire a drill, a hammer and so on. I you have taken a fancy to a programming language, you download and install --or pay for-- a compiler and start to program in it. Not so for Modula-3. Its source code is in the hands of a small community of dedicated people for which its maintenance has become an endeavour by itself. This is laudable and great, but what about the simple potential Modula 3 USER ? One cannot hope that he (or she, let's remain PC) will clone the whole shebang from Github and begin to dabble in configuration files, Python and Shell scripts to build his version of what represents only a tool after all. All he wants is to have a compiler and begin to work on his apps and favorite software projects. So keeping alive a language is not enough, it has also to be made easily available to those wanting to use it as their tool and who are not interested in compiler building or simply have more urgent > things to do. So when will there be the next Modula 3 release? > > > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://m3lists.elegosoft.com/mailman/listinfo/m3devel > -- Rodney Bates rodney.m.bates at acm.org _______________________________________________ M3devel mailing list M3devel at elegosoft.com https://m3lists.elegosoft.com/mailman/listinfo/m3devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Fri Mar 24 21:18:09 2017 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Fri, 24 Mar 2017 15:18:09 -0500 Subject: [M3devel] Rants about an improbable release In-Reply-To: References: <581363DE.9060401@lcwb.coop> Message-ID: <8e33339c-033c-b0fc-edf4-e571be5181cc@lcwb.coop> On 03/15/2017 04:14 AM, Jay K wrote: > I don't think you should worry about when you make IR changes. > > Make them when you decide they are needed and you have them correct and working. > > > The various build scripts are meant to build things properly no matter when/which such changes are presented. > > > Just please try to update all 3 or 4 backends (gcc, integrated, C, llvm). Well, yes, I was assuming that without saying. The reason I would like to do as much as can be anticipated in a single change, is that it entails making matching changes to the front end, 4 back ends, 8 other smaller IR processing modules, and 2 declarations packages, (if I didn't miss any). That's a lot to do multiple times. > > If not, then do so in some sort of optional way, like how Tony left LONGINT as 32bits on NT386. > > > Regarding a release, I would really like to get the system sooner-than-later to a state where we can distribute it as C. > > So that installation does not require a working compiler. > > > The 3.6 release was kind of like this, though not quite what I am after. > > (it distributed C source for quake, assembly source for some parts -- C + assembly to build cm3 (m3build + m3?) -- and then cm3 to build everything else. In my vision, the C/assembly are just C, maybe the entire system...really need to sit a few days and script/python it all out -- I did get over some cmake/autoconf hump a few months -- such that the bootstrap system can use them instead of make directly...) > > > There is still a fair amount of work needed to make this happen though, maybe not worth waiting for. > > > I am somewhat encouraged by the fact that gradually more and more people have tried and succeeded at this. > > I know the system is confusing, but some people do understand. > > > - Jay > > > > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ > *From:* M3devel on behalf of Rodney M. Bates > *Sent:* Friday, October 28, 2016 2:42 PM > *To:* m3devel at elegosoft.com > *Subject:* Re: [M3devel] Rants about an improbable release > > I agree, we very much need to make a new release. There has been a lot > of development since the last one, especially for having a small developer > community. > > I have often thought I would be willing to do the work to do it, but every > time, I get stuck not having any idea what needs to be done. For one > thing, I presume it entails verifying that things build and work on all > the various targets, which would further entail having access to one > of each of them. > > Are such machines available? Any advice on how to proceed? > > On a related topic, we need to make some changes to the compiler IR, as defined > in M3CG.i3 and M3CG_Ops.i3. I have been collecting a list of my own for > some time. This is a lot of (mostly rather mundane) work, and it creates > front/back end compatibility issues. It would be best to do as many > as possible at one time and get them in before a release, so those not > doing compiler development could just use the release without being > bothered. > > Anybody have any changes to propose? > > On 10/21/2016 12:56 PM, dirk muysers wrote: >> If you want to improve your home you go to the builders market and acquire a drill, a hammer and so on. I you have taken a fancy to a programming language, you download and install --or pay for-- a compiler and start to program in it. Not so for Modula-3. Its source code is in the hands of a small community of dedicated people for which its maintenance has become an endeavour by itself. This is laudable and great, but what about the simple potential Modula 3 USER ? One cannot hope that he (or she, let's remain PC) will clone the whole shebang from Github and begin to dabble in configuration files, Python and Shell scripts to build his version of what represents only a tool after all. All he wants is to have a compiler and begin to work on his apps and favorite software projects. So keeping alive a language is not enough, it has also to be made easily available to those wanting to use it as their tool and who are not interested in compiler building or simply have more urgent >> things to do. So when will there be the next Modula 3 release? >> >> >> _______________________________________________ >> M3devel mailing list >> M3devel at elegosoft.com >> https://m3lists.elegosoft.com/mailman/listinfo/m3devel >> > > -- > Rodney Bates > rodney.m.bates at acm.org > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://m3lists.elegosoft.com/mailman/listinfo/m3devel -- Rodney Bates rodney.m.bates at acm.org