From rodney_bates at lcwb.coop Thu Feb 4 18:12:35 2021 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 4 Feb 2021 11:12:35 -0600 Subject: [M3devel] Schutz, a someday-to-be semantic text editor for Modula3 Message-ID: I have created a github repository for Schutz, a someday-to-be semantic editor for multiple, nicely defined programming languages. It is in github.com/RodneyBates/schutz. One day, the goal of this is to be an editor capable of doing semantic browsing and editing on code that need not be complete or compilable. Examples are finding all actual parameters corresponding to a formal and nesting/unnesting procedures and other blocks of code. As a base for semantic editing, this has entailed a many-year project to allow editing to be done textually, while also maintaining an AST view of the parsable portions of code. Syntax directed editing has turned out to be too ponderous for serious work, so the actual editing works as text editing. So far, as of 2021-02-04, Schutz mostly only does text editing with a very strange and complicated internal representation, which can be viewed as an abstract syntax tree. The majority of the implementation is language-independent, subject to some reasonable assumptions that not all programming languages comply with, such as lexical scanning and parsing can be done without getting entangled with nested scope analysis. A specific language is configured with a formal language definition in a specialized language. Currently, a lexical scanner for each language must be hand-coded and follow an unusual interface. Languages currently defined comprise two versions of its language definition language (a primitive one used only for internal bootstrapping) and Modula-3. These are used in Schutz's own implementation. Schutz mostly maintains comments as typed, but does automated layout of syntactic constructs. If you don't like its layout rules, you can rewrite them in the language definition. There are several forms of conditional layout rules you can use, e.g. conditional line breaks. By default, Schutz maintains syntactically incorrect code as typed, for you to correct as you desire, but it displays its suggested error repairs and will apply them if asked to. For syntactically incorrect code, it uses the repaired portion to construct the AST. The error repair algorithm is elaborate. Lexical scanning and parsing are incremental, reexamining only a region nearby to textual edits that have been made. Schutz does this only when asked. It is hopefully apparent that reparsing after every keystroke would be a user nightmare. The planned semantic analysis system is also partial and incremental. A great deal of effort has gone into making the internal representation compact. Early estimates showed around 5 times pure text file size. This is good, compared to most internal tree forms, which tend to be more like ten times or more. However, moving to 64-bit machines will have increased this. To learn more or try it out, start by looking at the embryonic documentation files in subdirectory ./doc/pdf or ./doc/html of the repository. -- Rodney Bates rodney.m.bates at acm.org From dabenavidesd at yahoo.es Sat Feb 6 22:48:23 2021 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sat, 6 Feb 2021 21:48:23 +0000 (UTC) Subject: [M3devel] Schutz, a someday-to-be semantic text editor for Modula3 In-Reply-To: References: Message-ID: <365453751.4103964.1612648103789@mail.yahoo.com> Hi Rodney:does it mean it can infer types?Thanks in advance En jueves, 4 de febrero de 2021 12:13:22 GMT-5, Rodney M. Bates escribi?: I have created a github repository for Schutz, a someday-to-be semantic editor for multiple, nicely defined programming languages. It is in github.com/RodneyBates/schutz. One day, the goal of this is to be an editor capable of doing semantic browsing and editing on code that need not be complete or compilable. Examples are finding all actual parameters corresponding to a formal and nesting/unnesting procedures and other blocks of code. As a base for semantic editing, this has entailed a many-year project to allow editing to be done textually, while also maintaining an AST view of the parsable portions of code.? Syntax directed editing has turned out to be too ponderous for serious work, so the actual editing works as text editing. So far, as of 2021-02-04, Schutz mostly only does text editing with a very strange and complicated internal representation, which can be viewed as an abstract syntax tree. The majority of the implementation is language-independent, subject to some reasonable assumptions that not all programming languages comply with, such as lexical scanning and parsing can be done without getting entangled with nested scope analysis.? A specific language is configured with a formal language definition in a specialized language.? Currently, a lexical scanner for each language must be hand-coded and follow an unusual interface. Languages currently defined comprise two versions of its language definition language (a primitive one used only for internal bootstrapping) and Modula-3.? These are used in Schutz's own implementation. Schutz mostly maintains comments as typed, but does automated layout of syntactic constructs.? If you don't like its layout rules, you can rewrite them in the language definition.? There are several forms of conditional layout rules you can use, e.g. conditional line breaks. By default, Schutz maintains syntactically incorrect code as typed, for you to correct as you desire, but it displays its suggested error repairs and will apply them if asked to.? For syntactically incorrect code, it uses the repaired portion to construct the AST.? The error repair algorithm is elaborate. Lexical scanning and parsing are incremental, reexamining only a region nearby to textual edits that have been made.? Schutz does this only when asked.? It is hopefully apparent that reparsing after every keystroke would be a user nightmare.? The planned semantic analysis system is also partial and incremental. A great deal of effort has gone into making the internal representation compact.? Early estimates showed around 5 times pure text file size.? This is good, compared to most internal tree forms, which tend to be more like ten times or more.? However, moving to 64-bit machines will have increased this. To learn more or try it out, start by looking at the embryonic documentation files in subdirectory ./doc/pdf or ./doc/html of the repository. -- 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 hendrik at topoi.pooq.com Sun Feb 7 00:27:38 2021 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Sat, 6 Feb 2021 18:27:38 -0500 Subject: [M3devel] Schutz, a someday-to-be semantic text editor for Modula3 In-Reply-To: <365453751.4103964.1612648103789@mail.yahoo.com> References: <365453751.4103964.1612648103789@mail.yahoo.com> Message-ID: <20210206232738.wbrzsa6enpejnm3z@topoi.pooq.com> On Sat, Feb 06, 2021 at 09:48:23PM +0000, Daniel Alejandro Benavides D. wrote: > Hi Rodney:does it mean it can infer types?Thanks in advance > > En jueves, 4 de febrero de 2021 12:13:22 GMT-5, Rodney M. Bates escribi?: > > I have created a github repository for Schutz, a someday-to-be > semantic editor for multiple, nicely defined programming languages. > It is in github.com/RodneyBates/schutz. > > One day, the goal of this is to be an editor capable of doing semantic > browsing and editing on code that need not be complete or compilable. > Examples are finding all actual parameters corresponding to a formal > and nesting/unnesting procedures and other blocks of code. Looking forward to it. > > As a base for semantic editing, this has entailed a many-year project > to allow editing to be done textually, while also maintaining an AST > view of the parsable portions of code.? Syntax directed editing has > turned out to be too ponderous for serious work, so the actual editing > works as text editing. Adjusting indentation during editing is OK; but menus in which you choose whether you're going to have an if statement or an assignment statement are too ponderous. I presume that's what you meant with "syntax-directed edting". > > So far, as of 2021-02-04, Schutz mostly only does text editing with a > very strange and complicated internal representation, which can be > viewed as an abstract syntax tree. Yes. > > The majority of the implementation is language-independent, subject to > some reasonable assumptions that not all programming languages comply > with, such as lexical scanning and parsing can be done without getting > entangled with nested scope analysis. If I remember correctly from when I was implementing it, C++ does not satisfy this restriction. Too bad for C++. >? A specific language is > configured with a formal language definition in a specialized > language.? Currently, a lexical scanner for each language must be > hand-coded and follow an unusual interface. > > Languages currently defined comprise two versions of its language > definition language (a primitive one used only for internal > bootstrapping) and Modula-3.? These are used in Schutz's own > implementation. > > Schutz mostly maintains comments as typed, but does automated layout > of syntactic constructs.? If you don't like its layout rules, you can > rewrite them in the language definition.? There are several forms of > conditional layout rules you can use, e.g. conditional line breaks. > > By default, Schutz maintains syntactically incorrect code as typed, > for you to correct as you desire, but it displays its suggested error > repairs and will apply them if asked to.? For syntactically incorrect > code, it uses the repaired portion to construct the AST.? The error > repair algorithm is elaborate. Don't ignore the possibility of using the last correct parse tree as a possible 'repaired" portion. > > Lexical scanning and parsing are incremental, reexamining only a > region nearby to textual edits that have been made. You should perhaps reexamine every phrase that contains a textual edit, leaving nested phrases without such edits alone. > Schutz does this > only when asked.? It is hopefully apparent that reparsing after every > keystroke would be a user nightmare.? The planned semantic analysis > system is also partial and incremental. Not apparent to me. You have to mark the part of the parse tree where changes have been made, and skip around any "errors" that you find there. You probably don't even need to reparse anything from the previous parse that hasn't changed -- just keep the existing parse tree. Exception -- if a change happened outside an existing phrase but within the lookahead that had been used t parse it. Of course, you'll have to treat bracketing structures specially -- you don't want to renest the entire file when the user types the first of what will be a pair of brackets. Since you're being general about grammar, though, it may be difficult to identify what is a bracketing structure. > > A great deal of effort has gone into making the internal > representation compact.? Early estimates showed around 5 times pure > text file size. Impressive. > This is good, compared to most internal tree forms, > which tend to be more like ten times or more.? However, moving to > 64-bit machines will have increased this. > > To learn more or try it out, start by looking at the embryonic > documentation files in subdirectory ./doc/pdf or ./doc/html of the > repository. Haven't looked there yet, but it looks as if this is the kind of thing I'd like to use when it's ready. -- hendrik > > -- > 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 From rodney_bates at lcwb.coop Sun Feb 7 19:00:33 2021 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sun, 7 Feb 2021 12:00:33 -0600 Subject: [M3devel] Schutz, a someday-to-be semantic text editor for Modula3 In-Reply-To: <365453751.4103964.1612648103789@mail.yahoo.com> References: <365453751.4103964.1612648103789@mail.yahoo.com> Message-ID: On 2/6/21 3:48 PM, Daniel Alejandro Benavides D. wrote: > Hi Rodney: > does it mean it can infer types? > Thanks in advance Not now, but that is my eventual intention. > > En jueves, 4 de febrero de 2021 12:13:22 GMT-5, Rodney M. Bates escribi?: > > > I have created a github repository for Schutz, a someday-to-be > semantic editor for multiple, nicely defined programming languages. > It is in github.com/RodneyBates/schutz. > > One day, the goal of this is to be an editor capable of doing semantic > browsing and editing on code that need not be complete or compilable. > Examples are finding all actual parameters corresponding to a formal > and nesting/unnesting procedures and other blocks of code. > > As a base for semantic editing, this has entailed a many-year project > to allow editing to be done textually, while also maintaining an AST > view of the parsable portions of code.? Syntax directed editing has > turned out to be too ponderous for serious work, so the actual editing > works as text editing. > > So far, as of 2021-02-04, Schutz mostly only does text editing with a > very strange and complicated internal representation, which can be > viewed as an abstract syntax tree. > > The majority of the implementation is language-independent, subject to > some reasonable assumptions that not all programming languages comply > with, such as lexical scanning and parsing can be done without getting > entangled with nested scope analysis.? A specific language is > configured with a formal language definition in a specialized > language.? Currently, a lexical scanner for each language must be > hand-coded and follow an unusual interface. > > Languages currently defined comprise two versions of its language > definition language (a primitive one used only for internal > bootstrapping) and Modula-3.? These are used in Schutz's own > implementation. > > Schutz mostly maintains comments as typed, but does automated layout > of syntactic constructs.? If you don't like its layout rules, you can > rewrite them in the language definition.? There are several forms of > conditional layout rules you can use, e.g. conditional line breaks. > > By default, Schutz maintains syntactically incorrect code as typed, > for you to correct as you desire, but it displays its suggested error > repairs and will apply them if asked to.? For syntactically incorrect > code, it uses the repaired portion to construct the AST.? The error > repair algorithm is elaborate. > > Lexical scanning and parsing are incremental, reexamining only a > region nearby to textual edits that have been made.? Schutz does this > only when asked.? It is hopefully apparent that reparsing after every > keystroke would be a user nightmare.? The planned semantic analysis > system is also partial and incremental. > > A great deal of effort has gone into making the internal > representation compact.? Early estimates showed around 5 times pure > text file size.? This is good, compared to most internal tree forms, > which tend to be more like ten times or more.? However, moving to > 64-bit machines will have increased this. > > To learn more or try it out, start by looking at the embryonic > documentation files in subdirectory ./doc/pdf or ./doc/html of the > repository. > > -- > 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 > -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Sun Feb 7 19:25:49 2021 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sun, 7 Feb 2021 12:25:49 -0600 Subject: [M3devel] Schutz, a someday-to-be semantic text editor for Modula3 In-Reply-To: <20210206232738.wbrzsa6enpejnm3z@topoi.pooq.com> References: <365453751.4103964.1612648103789@mail.yahoo.com> <20210206232738.wbrzsa6enpejnm3z@topoi.pooq.com> Message-ID: <01ae779a-df89-472a-06d1-615ac7885c2b@lcwb.coop> On 2/6/21 5:27 PM, Hendrik Boom wrote: > On Sat, Feb 06, 2021 at 09:48:23PM +0000, Daniel Alejandro Benavides D. wrote: >> Hi Rodney:does it mean it can infer types?Thanks in advance >> >> En jueves, 4 de febrero de 2021 12:13:22 GMT-5, Rodney M. Bates escribi?: >> >> I have created a github repository for Schutz, a someday-to-be >> semantic editor for multiple, nicely defined programming languages. >> It is in github.com/RodneyBates/schutz. >> >> One day, the goal of this is to be an editor capable of doing semantic >> browsing and editing on code that need not be complete or compilable. >> Examples are finding all actual parameters corresponding to a formal >> and nesting/unnesting procedures and other blocks of code. > > Looking forward to it. > >> >> As a base for semantic editing, this has entailed a many-year project >> to allow editing to be done textually, while also maintaining an AST >> view of the parsable portions of code.? Syntax directed editing has >> turned out to be too ponderous for serious work, so the actual editing >> works as text editing. > > Adjusting indentation during editing is OK; but menus in which you > choose whether you're going to have an if statement or an assignment > statement are too ponderous. I presume that's what you meant with > "syntax-directed edting". > >> >> So far, as of 2021-02-04, Schutz mostly only does text editing with a >> very strange and complicated internal representation, which can be >> viewed as an abstract syntax tree. > > Yes. > >> >> The majority of the implementation is language-independent, subject to >> some reasonable assumptions that not all programming languages comply >> with, such as lexical scanning and parsing can be done without getting >> entangled with nested scope analysis. > > If I remember correctly from when I was implementing it, > C++ does not satisfy this restriction. Too bad for C++. > >> ? A specific language is >> configured with a formal language definition in a specialized >> language.? Currently, a lexical scanner for each language must be >> hand-coded and follow an unusual interface. >> >> Languages currently defined comprise two versions of its language >> definition language (a primitive one used only for internal >> bootstrapping) and Modula-3.? These are used in Schutz's own >> implementation. >> >> Schutz mostly maintains comments as typed, but does automated layout >> of syntactic constructs.? If you don't like its layout rules, you can >> rewrite them in the language definition.? There are several forms of >> conditional layout rules you can use, e.g. conditional line breaks. >> >> By default, Schutz maintains syntactically incorrect code as typed, >> for you to correct as you desire, but it displays its suggested error >> repairs and will apply them if asked to.? For syntactically incorrect >> code, it uses the repaired portion to construct the AST.? The error >> repair algorithm is elaborate. > > Don't ignore the possibility of using the last correct parse tree as a > possible 'repaired" portion. Hmm, never thought of that for repairs. It can, when asked, roll everything back to the last state after an assertion failure. I'm today working on the same for a runtime error. > >> >> Lexical scanning and parsing are incremental, reexamining only a >> region nearby to textual edits that have been made. > > You should perhaps reexamine every phrase that contains a textual edit, > leaving nested phrases without such edits alone. > Hard to articulate, but: It rescans everything touched by textual edits. Reparses every subtree with rescans or containing former repairs from before. Also, it may need to descend into and reparse an otherwise good subtree, depending on the state of the parser when arriving at the subtree. Otherwise, it treats the subtree as a nonterminal. >> Schutz does this >> only when asked.? It is hopefully apparent that reparsing after every >> keystroke would be a user nightmare.? The planned semantic analysis >> system is also partial and incremental. > > Not apparent to me. You have to mark the part of the parse tree where > changes have been made, and skip around any "errors" that you find > there. You probably don't even need to reparse anything from the > previous parse that hasn't changed -- just keep the existing parse tree. > Exception -- if a change happened outside an existing phrase but within > the lookahead that had been used t parse it. I am not altering the appearance of anything besides actual user-typed edits, until the user clicks "reparse". > > Of course, you'll have to treat bracketing structures specially -- you > don't want to renest the entire file when the user types the first of > what will be a pair of brackets. Since you're being general about > grammar, though, it may be difficult to identify what is a bracketing > structure. > Yes, exactly. This is why I wait for a reparse request. The user has the chance to first put in both brackets, before any re-bracketing or other layout changes happen. >> >> A great deal of effort has gone into making the internal >> representation compact.? Early estimates showed around 5 times pure >> text file size. > > Impressive. > I'd love to do even better, but it doesn't seem to be easy. Since 64-bit computers have become the norm, sizes will have gotten worse, though I haven't done any estimates lately. You can't easily make a pointer any smaller than a native word. >> This is good, compared to most internal tree forms, >> which tend to be more like ten times or more.? However, moving to >> 64-bit machines will have increased this. >> >> To learn more or try it out, start by looking at the embryonic >> documentation files in subdirectory ./doc/pdf or ./doc/html of the >> repository. > > Haven't looked there yet, but it looks as if this is the kind of thing > I'd like to use when it's ready. > > -- hendrik > >> >> -- -- Rodney Bates rodney.m.bates at acm.org From jayk123 at hotmail.com Sun Feb 21 19:20:28 2021 From: jayk123 at hotmail.com (Jay K) Date: Sun, 21 Feb 2021 18:20:28 +0000 Subject: [M3devel] Win32 compilation of "voronoi" package In-Reply-To: References: Message-ID: C:\s\cm3\caltech-other\voronoi\src\mymalloc.c(30):#include ________________________________ From: Mika Nystrom Sent: Sunday, February 21, 2021 11:02 AM To: Jay K ; m3devel Subject: Win32 compilation of "voronoi" package Hi Jay, Can you send me the error messages from compiling this on Windows? I would like to take a look at what's wrong with it. It looks like it's mostly in C. Mika -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sun Feb 21 19:21:50 2021 From: jayk123 at hotmail.com (Jay K) Date: Sun, 21 Feb 2021 18:21:50 +0000 Subject: [M3devel] Win32 compilation of "voronoi" package In-Reply-To: References: , Message-ID: C:\s\cm3\m3-scheme\mscheme\src\schemeUnixDeps.c(3):#include ________________________________ From: M3devel on behalf of Jay K Sent: Sunday, February 21, 2021 6:20 PM To: Mika Nystrom ; m3devel Subject: Re: [M3devel] Win32 compilation of "voronoi" package C:\s\cm3\caltech-other\voronoi\src\mymalloc.c(30):#include ________________________________ From: Mika Nystrom Sent: Sunday, February 21, 2021 11:02 AM To: Jay K ; m3devel Subject: Win32 compilation of "voronoi" package Hi Jay, Can you send me the error messages from compiling this on Windows? I would like to take a look at what's wrong with it. It looks like it's mostly in C. Mika -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sun Feb 21 23:08:59 2021 From: jayk123 at hotmail.com (Jay K) Date: Sun, 21 Feb 2021 22:08:59 +0000 Subject: [M3devel] Modula-3 subranges vs. opaque arbitrary 32bit constants? Message-ID: Maybe it is a bug in the Modula-3 Windows headers cloning, or in the C backend. I'm not sure. Please help me to understand? The AMD64_NT port works well enough, again, that it can build the runtime and compiler, and the compiler can build everything. But networking fails, here: 0:000> k # Child-SP RetAddr Call Site 00 (Inline Function) --------`-------- KERNELBASE!DebugBreak [minkernel\kernelbase\debug.c @ 143] 01 00000053`b8cff188 00007fff`b8a35e93 KERNELBASE!wil::details::DebugBreak+0x2 [onecore\internal\sdk\inc\wil\opensource\wil\result_macros.h @ 1737] 02 00000053`b8cff190 00007fff`b8a2682f m3core!RTOS__Crash+0x43 [C:\s\cm3\m3-libs\m3core\src\runtime\WIN32\RTOS.m3 @ 26] 03 00000053`b8cff1e0 00007fff`b8a23bef m3core!RTProcess__Crash+0x6f [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTProcess.m3 @ 66] 04 00000053`b8cff220 00007fff`b8a23820 m3core!RTError__EndError+0x3f [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTError.m3 @ 119] 05 00000053`b8cff260 00007fff`b8a24257 m3core!RTError__MsgS+0xa0 [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTError.m3 @ 41] 06 00000053`b8cff2a0 00007fff`b8a23e5e m3core!RTException__Crash+0x317 [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 81] 07 00000053`b8cff330 00007fff`b8a23d4b m3core!RTException__DefaultBackstop+0xce [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 39] 08 00000053`b8cff3a0 00007fff`b8a37d7a m3core!RTException__InvokeBackstop+0x3b [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 25] 09 00000053`b8cff3e0 00007fff`b8a23f2a m3core!RTException__Raise+0x9a [C:\s\cm3\m3-libs\m3core\src\runtime\ex_frame\RTExFrame.m3 @ 90] 0a 00000053`b8cff440 00007fff`b8a23d4b m3core!RTException__DefaultBackstop+0x19a [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 49] 0b 00000053`b8cff4b0 00007fff`b8a37d7a m3core!RTException__InvokeBackstop+0x3b [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 25] 0c 00000053`b8cff4f0 00007fff`b8a06cce m3core!RTException__Raise+0x9a [C:\s\cm3\m3-libs\m3core\src\runtime\ex_frame\RTExFrame.m3 @ 90] 0d 00000053`b8cff550 00007ff8`2d57626a m3core!RTHooks__ReportFault+0xfe [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTHooks.m3 @ 112] 0e 00000053`b8cff5f0 00007ff8`2d5747f2 m3tcp!M_TCP_L_100_CRASH+0x1a [C:\s\cm3\m3-comm\tcp\AMD64_NT\TCP.m3.c @ 2759] 0f 00000053`b8cff620 00007ff8`2d57371c m3tcp!TCP__InitSock+0xc2 [C:\s\cm3\m3-comm\tcp\src\WIN32\TCP.m3 @ 310] 10 00000053`b8cff680 00007fff`fe8302b3 m3tcp!TCP__NewConnector+0xdc [C:\s\cm3\m3-comm\tcp\src\WIN32\TCP.m3 @ 72] 11 00000053`b8cff720 00007fff`fe82d814 sharedobj!LocalObjectSpace__SpaceInit+0x283 [C:\s\cm3\m3-comm\sharedobj\src\LocalObjectSpace.m3 @ 391] 12 00000053`b8cff930 00007fff`b8a21e17 sharedobj!LocalObjectSpace_M3+0x94 [C:\s\cm3\m3-comm\sharedobj\src\LocalObjectSpace.m3 @ 805] 13 00000053`b8cff990 00007fff`b8a21c9a m3core!RTLinker__RunMainBody+0x3e7 [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTLinker.m3 @ 408] 14 00000053`b8cffa30 00007fff`b8a21c9a m3core!RTLinker__RunMainBody+0x26a [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTLinker.m3 @ 389] 15 00000053`b8cffad0 00007fff`b8a21c9a m3core!RTLinker__RunMainBody+0x26a [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTLinker.m3 @ 389] 16 00000053`b8cffb70 00007fff`b8a21c9a m3core!RTLinker__RunMainBody+0x26a [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTLinker.m3 @ 389] 17 00000053`b8cffc10 00007fff`b8a2209b m3core!RTLinker__RunMainBody+0x26a [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTLinker.m3 @ 389] 18 00000053`b8cffcb0 00007fff`b8a21818 m3core!RTLinker__AddUnitI+0x11b [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTLinker.m3 @ 116] 19 00000053`b8cffcf0 00007ff6`f5b31038 m3core!RTLinker__AddUnit+0x118 [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTLinker.m3 @ 125] 1a 00000053`b8cffd50 00007ff6`f5db4d38 mentor!main+0x38 [C:\s\cm3\m3-demo\mentor\AMD64_NT\_m3main.c @ 23] 1b (Inline Function) --------`-------- mentor!invoke_main+0x22 [d:\agent\_work\5\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl @ 78] 1c 00000053`b8cffd80 00007ff8`49a67034 mentor!__scrt_common_main_seh+0x10c [d:\agent\_work\5\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl @ 288] 1d 00000053`b8cffdc0 00007ff8`4a8fd241 KERNEL32!BaseThreadInitThunk+0x14 [clientcore\base\win32\client\thread.c @ 64] 1e 00000053`b8cffdf0 00000000`00000000 ntdll!RtlUserThreadStart+0x21 [minkernel\ntdll\rtlstrt.c @ 1153] *** *** runtime error: *** An enumeration or subrange value was out of range. *** file "..\src\WIN32\TCP.m3", line 310 *** it is "simple" subrange problem. IF WinSock.ioctlsocket(sock, WinSock.FIONBIO, ADR(one)) = SockErr THEN IPError.Die(); END; It is *not* calling that IPError.Die(). ioctlsocket is declared as: PROCEDURE ioctlsocket (s: SOCKET; cmd: INT32; argp: UNTRACED REF UINT32): INT32; INT32 = Cstdint.int32_t; int32_t = Cstdint.int32_t; int32_t = Ctypes.int; int = [-16_7fffffff-1 .. 16_7fffffff]; It is range checking ioctlsocket parameter WinSock.FIONBIO against that and rejecting it. The code is: 307 00007ff8`2d5747ca e847620000 call m3tcp!setsockopt (00007ff8`2d57aa16) previous line 307 00007ff8`2d5747cf 89442430 mov dword ptr [rsp+30h],eax 310 00007ff8`2d5747d3 b87e660880 mov eax,8008667Eh WinSock.FIONBIO 310 00007ff8`2d5747d8 4889442440 mov qword ptr [rsp+40h],rax 310 00007ff8`2d5747dd 48817c2440ffffff7f cmp qword ptr [rsp+40h],7FFFFFFFh 310 00007ff8`2d5747e6 7e0a jle m3tcp!TCP__InitSock+0xc2 (00007ff8`2d5747f2) Branch m3tcp!TCP__InitSock+0xb8 [C:\s\cm3\m3-comm\tcp\src\WIN32\TCP.m3 @ 310]: 310 00007ff8`2d5747e8 b9c1260000 mov ecx,26C1h 310 00007ff8`2d5747ed e85e1a0000 call m3tcp!M_TCP_L_100_CRASH (00007ff8`2d576250) dv /V 00000053`b8cff660 @rsp+0x0040 L_345_L_346 = 0n2148034174 mov eax, constant is zero extending and to confirm: C:\s>type fio.c #include #include int main() { printf("%d %x\n", FIONBIO, FIONBIO); return 0; } C:\s>cl fio.c Microsoft (R) C/C++ Optimizing Compiler Version 19.24.28316 for x64 Copyright (C) Microsoft Corporation. All rights reserved. fio.c Microsoft (R) Incremental Linker Version 14.24.28316.0 Copyright (C) Microsoft Corporation. All rights reserved. /out:fio.exe fio.obj C:\s>fio.exe -2147195266 8004667e What is the right way to do this? Just change to UINT32? Even it works, can you explain it to me? I agree integers should not silently overflow, subranges are good, but this doesn't seem to me like it should be so difficult. I am inclined to further drain the Modula-3 "headers" and make it an "extern constant variable", really, though I'm not sure that will help, though it serves another purpose -- I like to minimally duplicate C headers. That is one way Posix ports became much easier. Thank you, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Feb 22 00:19:25 2021 From: jayk123 at hotmail.com (Jay K) Date: Sun, 21 Feb 2021 23:19:25 +0000 Subject: [M3devel] Modula-3 subranges vs. opaque arbitrary 32bit constants? In-Reply-To: References: Message-ID: Seriously, how do I form arbitrary 32bit constants? ? amd64_nt suffers here. The Windows headers say: #define STD_INPUT_HANDLE ((DWORD)-10) #define STD_OUTPUT_HANDLE ((DWORD)-11) #define STD_ERROR_HANDLE ((DWORD)-12) The historical Modula-3 that only ran on 32bit: STD_INPUT_HANDLE : DWORD = -10; STD_OUTPUT_HANDLE: DWORD = -11; STD_ERROR_HANDLE : DWORD = -12; but I don't think that compiles. I'll try again. Things I've tried include: STD_INPUT_HANDLE : UINT32 = 16_fffffff6; (* -10 *) STD_OUTPUT_HANDLE: UINT32 = 16_fffffff5; (* -11 *) STD_ERROR_HANDLE : UINT32 = 16_fffffff4; (* -12 *) nothing works yet. - Jay ________________________________ From: M3devel on behalf of Jay K Sent: Sunday, February 21, 2021 10:08 PM To: m3devel Subject: [M3devel] Modula-3 subranges vs. opaque arbitrary 32bit constants? Maybe it is a bug in the Modula-3 Windows headers cloning, or in the C backend. I'm not sure. Please help me to understand? The AMD64_NT port works well enough, again, that it can build the runtime and compiler, and the compiler can build everything. But networking fails, here: 0:000> k # Child-SP RetAddr Call Site 00 (Inline Function) --------`-------- KERNELBASE!DebugBreak [minkernel\kernelbase\debug.c @ 143] 01 00000053`b8cff188 00007fff`b8a35e93 KERNELBASE!wil::details::DebugBreak+0x2 [onecore\internal\sdk\inc\wil\opensource\wil\result_macros.h @ 1737] 02 00000053`b8cff190 00007fff`b8a2682f m3core!RTOS__Crash+0x43 [C:\s\cm3\m3-libs\m3core\src\runtime\WIN32\RTOS.m3 @ 26] 03 00000053`b8cff1e0 00007fff`b8a23bef m3core!RTProcess__Crash+0x6f [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTProcess.m3 @ 66] 04 00000053`b8cff220 00007fff`b8a23820 m3core!RTError__EndError+0x3f [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTError.m3 @ 119] 05 00000053`b8cff260 00007fff`b8a24257 m3core!RTError__MsgS+0xa0 [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTError.m3 @ 41] 06 00000053`b8cff2a0 00007fff`b8a23e5e m3core!RTException__Crash+0x317 [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 81] 07 00000053`b8cff330 00007fff`b8a23d4b m3core!RTException__DefaultBackstop+0xce [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 39] 08 00000053`b8cff3a0 00007fff`b8a37d7a m3core!RTException__InvokeBackstop+0x3b [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 25] 09 00000053`b8cff3e0 00007fff`b8a23f2a m3core!RTException__Raise+0x9a [C:\s\cm3\m3-libs\m3core\src\runtime\ex_frame\RTExFrame.m3 @ 90] 0a 00000053`b8cff440 00007fff`b8a23d4b m3core!RTException__DefaultBackstop+0x19a [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 49] 0b 00000053`b8cff4b0 00007fff`b8a37d7a m3core!RTException__InvokeBackstop+0x3b [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 25] 0c 00000053`b8cff4f0 00007fff`b8a06cce m3core!RTException__Raise+0x9a [C:\s\cm3\m3-libs\m3core\src\runtime\ex_frame\RTExFrame.m3 @ 90] 0d 00000053`b8cff550 00007ff8`2d57626a m3core!RTHooks__ReportFault+0xfe [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTHooks.m3 @ 112] 0e 00000053`b8cff5f0 00007ff8`2d5747f2 m3tcp!M_TCP_L_100_CRASH+0x1a [C:\s\cm3\m3-comm\tcp\AMD64_NT\TCP.m3.c @ 2759] 0f 00000053`b8cff620 00007ff8`2d57371c m3tcp!TCP__InitSock+0xc2 [C:\s\cm3\m3-comm\tcp\src\WIN32\TCP.m3 @ 310] 10 00000053`b8cff680 00007fff`fe8302b3 m3tcp!TCP__NewConnector+0xdc [C:\s\cm3\m3-comm\tcp\src\WIN32\TCP.m3 @ 72] 11 00000053`b8cff720 00007fff`fe82d814 sharedobj!LocalObjectSpace__SpaceInit+0x283 [C:\s\cm3\m3-comm\sharedobj\src\LocalObjectSpace.m3 @ 391] 12 00000053`b8cff930 00007fff`b8a21e17 sharedobj!LocalObjectSpace_M3+0x94 [C:\s\cm3\m3-comm\sharedobj\src\LocalObjectSpace.m3 @ 805] 13 00000053`b8cff990 00007fff`b8a21c9a m3core!RTLinker__RunMainBody+0x3e7 [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTLinker.m3 @ 408] 14 00000053`b8cffa30 00007fff`b8a21c9a m3core!RTLinker__RunMainBody+0x26a [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTLinker.m3 @ 389] 15 00000053`b8cffad0 00007fff`b8a21c9a m3core!RTLinker__RunMainBody+0x26a [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTLinker.m3 @ 389] 16 00000053`b8cffb70 00007fff`b8a21c9a m3core!RTLinker__RunMainBody+0x26a [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTLinker.m3 @ 389] 17 00000053`b8cffc10 00007fff`b8a2209b m3core!RTLinker__RunMainBody+0x26a [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTLinker.m3 @ 389] 18 00000053`b8cffcb0 00007fff`b8a21818 m3core!RTLinker__AddUnitI+0x11b [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTLinker.m3 @ 116] 19 00000053`b8cffcf0 00007ff6`f5b31038 m3core!RTLinker__AddUnit+0x118 [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTLinker.m3 @ 125] 1a 00000053`b8cffd50 00007ff6`f5db4d38 mentor!main+0x38 [C:\s\cm3\m3-demo\mentor\AMD64_NT\_m3main.c @ 23] 1b (Inline Function) --------`-------- mentor!invoke_main+0x22 [d:\agent\_work\5\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl @ 78] 1c 00000053`b8cffd80 00007ff8`49a67034 mentor!__scrt_common_main_seh+0x10c [d:\agent\_work\5\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl @ 288] 1d 00000053`b8cffdc0 00007ff8`4a8fd241 KERNEL32!BaseThreadInitThunk+0x14 [clientcore\base\win32\client\thread.c @ 64] 1e 00000053`b8cffdf0 00000000`00000000 ntdll!RtlUserThreadStart+0x21 [minkernel\ntdll\rtlstrt.c @ 1153] *** *** runtime error: *** An enumeration or subrange value was out of range. *** file "..\src\WIN32\TCP.m3", line 310 *** it is "simple" subrange problem. IF WinSock.ioctlsocket(sock, WinSock.FIONBIO, ADR(one)) = SockErr THEN IPError.Die(); END; It is *not* calling that IPError.Die(). ioctlsocket is declared as: PROCEDURE ioctlsocket (s: SOCKET; cmd: INT32; argp: UNTRACED REF UINT32): INT32; INT32 = Cstdint.int32_t; int32_t = Cstdint.int32_t; int32_t = Ctypes.int; int = [-16_7fffffff-1 .. 16_7fffffff]; It is range checking ioctlsocket parameter WinSock.FIONBIO against that and rejecting it. The code is: 307 00007ff8`2d5747ca e847620000 call m3tcp!setsockopt (00007ff8`2d57aa16) previous line 307 00007ff8`2d5747cf 89442430 mov dword ptr [rsp+30h],eax 310 00007ff8`2d5747d3 b87e660880 mov eax,8008667Eh WinSock.FIONBIO 310 00007ff8`2d5747d8 4889442440 mov qword ptr [rsp+40h],rax 310 00007ff8`2d5747dd 48817c2440ffffff7f cmp qword ptr [rsp+40h],7FFFFFFFh 310 00007ff8`2d5747e6 7e0a jle m3tcp!TCP__InitSock+0xc2 (00007ff8`2d5747f2) Branch m3tcp!TCP__InitSock+0xb8 [C:\s\cm3\m3-comm\tcp\src\WIN32\TCP.m3 @ 310]: 310 00007ff8`2d5747e8 b9c1260000 mov ecx,26C1h 310 00007ff8`2d5747ed e85e1a0000 call m3tcp!M_TCP_L_100_CRASH (00007ff8`2d576250) dv /V 00000053`b8cff660 @rsp+0x0040 L_345_L_346 = 0n2148034174 mov eax, constant is zero extending and to confirm: C:\s>type fio.c #include #include int main() { printf("%d %x\n", FIONBIO, FIONBIO); return 0; } C:\s>cl fio.c Microsoft (R) C/C++ Optimizing Compiler Version 19.24.28316 for x64 Copyright (C) Microsoft Corporation. All rights reserved. fio.c Microsoft (R) Incremental Linker Version 14.24.28316.0 Copyright (C) Microsoft Corporation. All rights reserved. /out:fio.exe fio.obj C:\s>fio.exe -2147195266 8004667e What is the right way to do this? Just change to UINT32? Even it works, can you explain it to me? I agree integers should not silently overflow, subranges are good, but this doesn't seem to me like it should be so difficult. I am inclined to further drain the Modula-3 "headers" and make it an "extern constant variable", really, though I'm not sure that will help, though it serves another purpose -- I like to minimally duplicate C headers. That is one way Posix ports became much easier. Thank you, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Feb 22 00:22:06 2021 From: jayk123 at hotmail.com (Jay K) Date: Sun, 21 Feb 2021 23:22:06 +0000 Subject: [M3devel] Modula-3 subranges vs. opaque arbitrary 32bit constants? In-Reply-To: References: , Message-ID: The historical: STD_INPUT_HANDLE : DWORD = -10; STD_OUTPUT_HANDLE: DWORD = -11; STD_ERROR_HANDLE : DWORD = -12; gives: "..\src\win32\WinBase.i3", line 729: warning: value not assignable (range fault) "..\src\win32\WinBase.i3", line 730: warning: value not assignable (range fault) "..\src\win32\WinBase.i3", line 731: warning: value not assignable (range fault) This is why I started changing to INT32, but then I didn't change enough and hit runtime errors. Perhaps still INT32 is the way. Perhaps. But this seems like much ado about little. I will double check if DWORD change. Well, yes, between 32bit and 64bit, it must have. Before it could be Word.T i.e. INTEGER. But that is maybe no longer correct. We need Word32? - Jay ________________________________ From: Jay K Sent: Sunday, February 21, 2021 11:19 PM To: m3devel Subject: Re: Modula-3 subranges vs. opaque arbitrary 32bit constants? Seriously, how do I form arbitrary 32bit constants? ? amd64_nt suffers here. The Windows headers say: #define STD_INPUT_HANDLE ((DWORD)-10) #define STD_OUTPUT_HANDLE ((DWORD)-11) #define STD_ERROR_HANDLE ((DWORD)-12) The historical Modula-3 that only ran on 32bit: STD_INPUT_HANDLE : DWORD = -10; STD_OUTPUT_HANDLE: DWORD = -11; STD_ERROR_HANDLE : DWORD = -12; but I don't think that compiles. I'll try again. Things I've tried include: STD_INPUT_HANDLE : UINT32 = 16_fffffff6; (* -10 *) STD_OUTPUT_HANDLE: UINT32 = 16_fffffff5; (* -11 *) STD_ERROR_HANDLE : UINT32 = 16_fffffff4; (* -12 *) nothing works yet. - Jay ________________________________ From: M3devel on behalf of Jay K Sent: Sunday, February 21, 2021 10:08 PM To: m3devel Subject: [M3devel] Modula-3 subranges vs. opaque arbitrary 32bit constants? Maybe it is a bug in the Modula-3 Windows headers cloning, or in the C backend. I'm not sure. Please help me to understand? The AMD64_NT port works well enough, again, that it can build the runtime and compiler, and the compiler can build everything. But networking fails, here: 0:000> k # Child-SP RetAddr Call Site 00 (Inline Function) --------`-------- KERNELBASE!DebugBreak [minkernel\kernelbase\debug.c @ 143] 01 00000053`b8cff188 00007fff`b8a35e93 KERNELBASE!wil::details::DebugBreak+0x2 [onecore\internal\sdk\inc\wil\opensource\wil\result_macros.h @ 1737] 02 00000053`b8cff190 00007fff`b8a2682f m3core!RTOS__Crash+0x43 [C:\s\cm3\m3-libs\m3core\src\runtime\WIN32\RTOS.m3 @ 26] 03 00000053`b8cff1e0 00007fff`b8a23bef m3core!RTProcess__Crash+0x6f [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTProcess.m3 @ 66] 04 00000053`b8cff220 00007fff`b8a23820 m3core!RTError__EndError+0x3f [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTError.m3 @ 119] 05 00000053`b8cff260 00007fff`b8a24257 m3core!RTError__MsgS+0xa0 [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTError.m3 @ 41] 06 00000053`b8cff2a0 00007fff`b8a23e5e m3core!RTException__Crash+0x317 [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 81] 07 00000053`b8cff330 00007fff`b8a23d4b m3core!RTException__DefaultBackstop+0xce [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 39] 08 00000053`b8cff3a0 00007fff`b8a37d7a m3core!RTException__InvokeBackstop+0x3b [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 25] 09 00000053`b8cff3e0 00007fff`b8a23f2a m3core!RTException__Raise+0x9a [C:\s\cm3\m3-libs\m3core\src\runtime\ex_frame\RTExFrame.m3 @ 90] 0a 00000053`b8cff440 00007fff`b8a23d4b m3core!RTException__DefaultBackstop+0x19a [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 49] 0b 00000053`b8cff4b0 00007fff`b8a37d7a m3core!RTException__InvokeBackstop+0x3b [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 25] 0c 00000053`b8cff4f0 00007fff`b8a06cce m3core!RTException__Raise+0x9a [C:\s\cm3\m3-libs\m3core\src\runtime\ex_frame\RTExFrame.m3 @ 90] 0d 00000053`b8cff550 00007ff8`2d57626a m3core!RTHooks__ReportFault+0xfe [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTHooks.m3 @ 112] 0e 00000053`b8cff5f0 00007ff8`2d5747f2 m3tcp!M_TCP_L_100_CRASH+0x1a [C:\s\cm3\m3-comm\tcp\AMD64_NT\TCP.m3.c @ 2759] 0f 00000053`b8cff620 00007ff8`2d57371c m3tcp!TCP__InitSock+0xc2 [C:\s\cm3\m3-comm\tcp\src\WIN32\TCP.m3 @ 310] 10 00000053`b8cff680 00007fff`fe8302b3 m3tcp!TCP__NewConnector+0xdc [C:\s\cm3\m3-comm\tcp\src\WIN32\TCP.m3 @ 72] 11 00000053`b8cff720 00007fff`fe82d814 sharedobj!LocalObjectSpace__SpaceInit+0x283 [C:\s\cm3\m3-comm\sharedobj\src\LocalObjectSpace.m3 @ 391] 12 00000053`b8cff930 00007fff`b8a21e17 sharedobj!LocalObjectSpace_M3+0x94 [C:\s\cm3\m3-comm\sharedobj\src\LocalObjectSpace.m3 @ 805] 13 00000053`b8cff990 00007fff`b8a21c9a m3core!RTLinker__RunMainBody+0x3e7 [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTLinker.m3 @ 408] 14 00000053`b8cffa30 00007fff`b8a21c9a m3core!RTLinker__RunMainBody+0x26a [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTLinker.m3 @ 389] 15 00000053`b8cffad0 00007fff`b8a21c9a m3core!RTLinker__RunMainBody+0x26a [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTLinker.m3 @ 389] 16 00000053`b8cffb70 00007fff`b8a21c9a m3core!RTLinker__RunMainBody+0x26a [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTLinker.m3 @ 389] 17 00000053`b8cffc10 00007fff`b8a2209b m3core!RTLinker__RunMainBody+0x26a [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTLinker.m3 @ 389] 18 00000053`b8cffcb0 00007fff`b8a21818 m3core!RTLinker__AddUnitI+0x11b [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTLinker.m3 @ 116] 19 00000053`b8cffcf0 00007ff6`f5b31038 m3core!RTLinker__AddUnit+0x118 [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTLinker.m3 @ 125] 1a 00000053`b8cffd50 00007ff6`f5db4d38 mentor!main+0x38 [C:\s\cm3\m3-demo\mentor\AMD64_NT\_m3main.c @ 23] 1b (Inline Function) --------`-------- mentor!invoke_main+0x22 [d:\agent\_work\5\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl @ 78] 1c 00000053`b8cffd80 00007ff8`49a67034 mentor!__scrt_common_main_seh+0x10c [d:\agent\_work\5\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl @ 288] 1d 00000053`b8cffdc0 00007ff8`4a8fd241 KERNEL32!BaseThreadInitThunk+0x14 [clientcore\base\win32\client\thread.c @ 64] 1e 00000053`b8cffdf0 00000000`00000000 ntdll!RtlUserThreadStart+0x21 [minkernel\ntdll\rtlstrt.c @ 1153] *** *** runtime error: *** An enumeration or subrange value was out of range. *** file "..\src\WIN32\TCP.m3", line 310 *** it is "simple" subrange problem. IF WinSock.ioctlsocket(sock, WinSock.FIONBIO, ADR(one)) = SockErr THEN IPError.Die(); END; It is *not* calling that IPError.Die(). ioctlsocket is declared as: PROCEDURE ioctlsocket (s: SOCKET; cmd: INT32; argp: UNTRACED REF UINT32): INT32; INT32 = Cstdint.int32_t; int32_t = Cstdint.int32_t; int32_t = Ctypes.int; int = [-16_7fffffff-1 .. 16_7fffffff]; It is range checking ioctlsocket parameter WinSock.FIONBIO against that and rejecting it. The code is: 307 00007ff8`2d5747ca e847620000 call m3tcp!setsockopt (00007ff8`2d57aa16) previous line 307 00007ff8`2d5747cf 89442430 mov dword ptr [rsp+30h],eax 310 00007ff8`2d5747d3 b87e660880 mov eax,8008667Eh WinSock.FIONBIO 310 00007ff8`2d5747d8 4889442440 mov qword ptr [rsp+40h],rax 310 00007ff8`2d5747dd 48817c2440ffffff7f cmp qword ptr [rsp+40h],7FFFFFFFh 310 00007ff8`2d5747e6 7e0a jle m3tcp!TCP__InitSock+0xc2 (00007ff8`2d5747f2) Branch m3tcp!TCP__InitSock+0xb8 [C:\s\cm3\m3-comm\tcp\src\WIN32\TCP.m3 @ 310]: 310 00007ff8`2d5747e8 b9c1260000 mov ecx,26C1h 310 00007ff8`2d5747ed e85e1a0000 call m3tcp!M_TCP_L_100_CRASH (00007ff8`2d576250) dv /V 00000053`b8cff660 @rsp+0x0040 L_345_L_346 = 0n2148034174 mov eax, constant is zero extending and to confirm: C:\s>type fio.c #include #include int main() { printf("%d %x\n", FIONBIO, FIONBIO); return 0; } C:\s>cl fio.c Microsoft (R) C/C++ Optimizing Compiler Version 19.24.28316 for x64 Copyright (C) Microsoft Corporation. All rights reserved. fio.c Microsoft (R) Incremental Linker Version 14.24.28316.0 Copyright (C) Microsoft Corporation. All rights reserved. /out:fio.exe fio.obj C:\s>fio.exe -2147195266 8004667e What is the right way to do this? Just change to UINT32? Even it works, can you explain it to me? I agree integers should not silently overflow, subranges are good, but this doesn't seem to me like it should be so difficult. I am inclined to further drain the Modula-3 "headers" and make it an "extern constant variable", really, though I'm not sure that will help, though it serves another purpose -- I like to minimally duplicate C headers. That is one way Posix ports became much easier. Thank you, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Feb 22 00:27:31 2021 From: jayk123 at hotmail.com (Jay K) Date: Sun, 21 Feb 2021 23:27:31 +0000 Subject: [M3devel] Modula-3 subranges vs. opaque arbitrary 32bit constants? In-Reply-To: References: , Message-ID: I think this is the basic problem.. On 32bit we have: C:\s\cm3\m3-libs\m3core\src\C\32BITS\BasicCtypes.i3(23): unsigned_int = Word.T; but 64bit: C:\s\cm3\m3-libs\m3core\src\C\64BITS\BasicCtypes.i3 unsigned_int = [16_0 .. 16_ffffffff]; And I guess these are quite different. The first allows negative values, the second does not. This seems bad and wrong. Again I think we need Word32, though I'm not exactly sure what it means. Something like arbitrary 32bit values. I will try to push "int32" through on the affected paths, as I had started long ago. - Jay ________________________________ From: Jay K Sent: Sunday, February 21, 2021 11:19 PM To: m3devel Subject: Re: Modula-3 subranges vs. opaque arbitrary 32bit constants? Seriously, how do I form arbitrary 32bit constants? ? amd64_nt suffers here. The Windows headers say: #define STD_INPUT_HANDLE ((DWORD)-10) #define STD_OUTPUT_HANDLE ((DWORD)-11) #define STD_ERROR_HANDLE ((DWORD)-12) The historical Modula-3 that only ran on 32bit: STD_INPUT_HANDLE : DWORD = -10; STD_OUTPUT_HANDLE: DWORD = -11; STD_ERROR_HANDLE : DWORD = -12; but I don't think that compiles. I'll try again. Things I've tried include: STD_INPUT_HANDLE : UINT32 = 16_fffffff6; (* -10 *) STD_OUTPUT_HANDLE: UINT32 = 16_fffffff5; (* -11 *) STD_ERROR_HANDLE : UINT32 = 16_fffffff4; (* -12 *) nothing works yet. - Jay ________________________________ From: M3devel on behalf of Jay K Sent: Sunday, February 21, 2021 10:08 PM To: m3devel Subject: [M3devel] Modula-3 subranges vs. opaque arbitrary 32bit constants? Maybe it is a bug in the Modula-3 Windows headers cloning, or in the C backend. I'm not sure. Please help me to understand? The AMD64_NT port works well enough, again, that it can build the runtime and compiler, and the compiler can build everything. But networking fails, here: 0:000> k # Child-SP RetAddr Call Site 00 (Inline Function) --------`-------- KERNELBASE!DebugBreak [minkernel\kernelbase\debug.c @ 143] 01 00000053`b8cff188 00007fff`b8a35e93 KERNELBASE!wil::details::DebugBreak+0x2 [onecore\internal\sdk\inc\wil\opensource\wil\result_macros.h @ 1737] 02 00000053`b8cff190 00007fff`b8a2682f m3core!RTOS__Crash+0x43 [C:\s\cm3\m3-libs\m3core\src\runtime\WIN32\RTOS.m3 @ 26] 03 00000053`b8cff1e0 00007fff`b8a23bef m3core!RTProcess__Crash+0x6f [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTProcess.m3 @ 66] 04 00000053`b8cff220 00007fff`b8a23820 m3core!RTError__EndError+0x3f [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTError.m3 @ 119] 05 00000053`b8cff260 00007fff`b8a24257 m3core!RTError__MsgS+0xa0 [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTError.m3 @ 41] 06 00000053`b8cff2a0 00007fff`b8a23e5e m3core!RTException__Crash+0x317 [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 81] 07 00000053`b8cff330 00007fff`b8a23d4b m3core!RTException__DefaultBackstop+0xce [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 39] 08 00000053`b8cff3a0 00007fff`b8a37d7a m3core!RTException__InvokeBackstop+0x3b [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 25] 09 00000053`b8cff3e0 00007fff`b8a23f2a m3core!RTException__Raise+0x9a [C:\s\cm3\m3-libs\m3core\src\runtime\ex_frame\RTExFrame.m3 @ 90] 0a 00000053`b8cff440 00007fff`b8a23d4b m3core!RTException__DefaultBackstop+0x19a [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 49] 0b 00000053`b8cff4b0 00007fff`b8a37d7a m3core!RTException__InvokeBackstop+0x3b [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 25] 0c 00000053`b8cff4f0 00007fff`b8a06cce m3core!RTException__Raise+0x9a [C:\s\cm3\m3-libs\m3core\src\runtime\ex_frame\RTExFrame.m3 @ 90] 0d 00000053`b8cff550 00007ff8`2d57626a m3core!RTHooks__ReportFault+0xfe [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTHooks.m3 @ 112] 0e 00000053`b8cff5f0 00007ff8`2d5747f2 m3tcp!M_TCP_L_100_CRASH+0x1a [C:\s\cm3\m3-comm\tcp\AMD64_NT\TCP.m3.c @ 2759] 0f 00000053`b8cff620 00007ff8`2d57371c m3tcp!TCP__InitSock+0xc2 [C:\s\cm3\m3-comm\tcp\src\WIN32\TCP.m3 @ 310] 10 00000053`b8cff680 00007fff`fe8302b3 m3tcp!TCP__NewConnector+0xdc [C:\s\cm3\m3-comm\tcp\src\WIN32\TCP.m3 @ 72] 11 00000053`b8cff720 00007fff`fe82d814 sharedobj!LocalObjectSpace__SpaceInit+0x283 [C:\s\cm3\m3-comm\sharedobj\src\LocalObjectSpace.m3 @ 391] 12 00000053`b8cff930 00007fff`b8a21e17 sharedobj!LocalObjectSpace_M3+0x94 [C:\s\cm3\m3-comm\sharedobj\src\LocalObjectSpace.m3 @ 805] 13 00000053`b8cff990 00007fff`b8a21c9a m3core!RTLinker__RunMainBody+0x3e7 [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTLinker.m3 @ 408] 14 00000053`b8cffa30 00007fff`b8a21c9a m3core!RTLinker__RunMainBody+0x26a [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTLinker.m3 @ 389] 15 00000053`b8cffad0 00007fff`b8a21c9a m3core!RTLinker__RunMainBody+0x26a [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTLinker.m3 @ 389] 16 00000053`b8cffb70 00007fff`b8a21c9a m3core!RTLinker__RunMainBody+0x26a [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTLinker.m3 @ 389] 17 00000053`b8cffc10 00007fff`b8a2209b m3core!RTLinker__RunMainBody+0x26a [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTLinker.m3 @ 389] 18 00000053`b8cffcb0 00007fff`b8a21818 m3core!RTLinker__AddUnitI+0x11b [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTLinker.m3 @ 116] 19 00000053`b8cffcf0 00007ff6`f5b31038 m3core!RTLinker__AddUnit+0x118 [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTLinker.m3 @ 125] 1a 00000053`b8cffd50 00007ff6`f5db4d38 mentor!main+0x38 [C:\s\cm3\m3-demo\mentor\AMD64_NT\_m3main.c @ 23] 1b (Inline Function) --------`-------- mentor!invoke_main+0x22 [d:\agent\_work\5\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl @ 78] 1c 00000053`b8cffd80 00007ff8`49a67034 mentor!__scrt_common_main_seh+0x10c [d:\agent\_work\5\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl @ 288] 1d 00000053`b8cffdc0 00007ff8`4a8fd241 KERNEL32!BaseThreadInitThunk+0x14 [clientcore\base\win32\client\thread.c @ 64] 1e 00000053`b8cffdf0 00000000`00000000 ntdll!RtlUserThreadStart+0x21 [minkernel\ntdll\rtlstrt.c @ 1153] *** *** runtime error: *** An enumeration or subrange value was out of range. *** file "..\src\WIN32\TCP.m3", line 310 *** it is "simple" subrange problem. IF WinSock.ioctlsocket(sock, WinSock.FIONBIO, ADR(one)) = SockErr THEN IPError.Die(); END; It is *not* calling that IPError.Die(). ioctlsocket is declared as: PROCEDURE ioctlsocket (s: SOCKET; cmd: INT32; argp: UNTRACED REF UINT32): INT32; INT32 = Cstdint.int32_t; int32_t = Cstdint.int32_t; int32_t = Ctypes.int; int = [-16_7fffffff-1 .. 16_7fffffff]; It is range checking ioctlsocket parameter WinSock.FIONBIO against that and rejecting it. The code is: 307 00007ff8`2d5747ca e847620000 call m3tcp!setsockopt (00007ff8`2d57aa16) previous line 307 00007ff8`2d5747cf 89442430 mov dword ptr [rsp+30h],eax 310 00007ff8`2d5747d3 b87e660880 mov eax,8008667Eh WinSock.FIONBIO 310 00007ff8`2d5747d8 4889442440 mov qword ptr [rsp+40h],rax 310 00007ff8`2d5747dd 48817c2440ffffff7f cmp qword ptr [rsp+40h],7FFFFFFFh 310 00007ff8`2d5747e6 7e0a jle m3tcp!TCP__InitSock+0xc2 (00007ff8`2d5747f2) Branch m3tcp!TCP__InitSock+0xb8 [C:\s\cm3\m3-comm\tcp\src\WIN32\TCP.m3 @ 310]: 310 00007ff8`2d5747e8 b9c1260000 mov ecx,26C1h 310 00007ff8`2d5747ed e85e1a0000 call m3tcp!M_TCP_L_100_CRASH (00007ff8`2d576250) dv /V 00000053`b8cff660 @rsp+0x0040 L_345_L_346 = 0n2148034174 mov eax, constant is zero extending and to confirm: C:\s>type fio.c #include #include int main() { printf("%d %x\n", FIONBIO, FIONBIO); return 0; } C:\s>cl fio.c Microsoft (R) C/C++ Optimizing Compiler Version 19.24.28316 for x64 Copyright (C) Microsoft Corporation. All rights reserved. fio.c Microsoft (R) Incremental Linker Version 14.24.28316.0 Copyright (C) Microsoft Corporation. All rights reserved. /out:fio.exe fio.obj C:\s>fio.exe -2147195266 8004667e What is the right way to do this? Just change to UINT32? Even it works, can you explain it to me? I agree integers should not silently overflow, subranges are good, but this doesn't seem to me like it should be so difficult. I am inclined to further drain the Modula-3 "headers" and make it an "extern constant variable", really, though I'm not sure that will help, though it serves another purpose -- I like to minimally duplicate C headers. That is one way Posix ports became much easier. Thank you, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Mon Feb 22 03:54:04 2021 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sun, 21 Feb 2021 20:54:04 -0600 Subject: [M3devel] Modula-3 subranges vs. opaque arbitrary 32bit constants? In-Reply-To: References: Message-ID: <0ea053e7-ecc8-88ab-0355-c1119a71e21f@lcwb.coop> I can explain what is happening and probably what needs to be done. See below --- On 2/21/21 4:08 PM, Jay K wrote: > Maybe it is a bug in the Modula-3 Windows headers cloning, or in the C backend. > I'm not sure. > Please help me to understand? > > The AMD64_NT port works well enough, again, that it can build the runtime and compiler, and the compiler > can build everything. > > But networking fails, here: > > 0:000> k > ?# Child-SP ? ? ? ? ?RetAddr ? ? ? ? ? ? ? Call Site > 00 (Inline Function) --------`-------- ? ? KERNELBASE!DebugBreak [minkernel\kernelbase\debug.c @ 143] > 01 00000053`b8cff188 00007fff`b8a35e93 ? ? KERNELBASE!wil::details::DebugBreak+0x2 [onecore\internal\sdk\inc\wil\opensource\wil\result_macros.h @ 1737] > 02 00000053`b8cff190 00007fff`b8a2682f ? ? m3core!RTOS__Crash+0x43 [C:\s\cm3\m3-libs\m3core\src\runtime\WIN32\RTOS.m3 @ 26] > 03 00000053`b8cff1e0 00007fff`b8a23bef ? ? m3core!RTProcess__Crash+0x6f [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTProcess.m3 @ 66] > 04 00000053`b8cff220 00007fff`b8a23820 ? ? m3core!RTError__EndError+0x3f [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTError.m3 @ 119] > 05 00000053`b8cff260 00007fff`b8a24257 ? ? m3core!RTError__MsgS+0xa0 [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTError.m3 @ 41] > 06 00000053`b8cff2a0 00007fff`b8a23e5e ? ? m3core!RTException__Crash+0x317 [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 81] > 07 00000053`b8cff330 00007fff`b8a23d4b ? ? m3core!RTException__DefaultBackstop+0xce [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 39] > 08 00000053`b8cff3a0 00007fff`b8a37d7a ? ? m3core!RTException__InvokeBackstop+0x3b [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 25] > 09 00000053`b8cff3e0 00007fff`b8a23f2a ? ? m3core!RTException__Raise+0x9a [C:\s\cm3\m3-libs\m3core\src\runtime\ex_frame\RTExFrame.m3 @ 90] > 0a 00000053`b8cff440 00007fff`b8a23d4b ? ? m3core!RTException__DefaultBackstop+0x19a [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 49] > 0b 00000053`b8cff4b0 00007fff`b8a37d7a ? ? m3core!RTException__InvokeBackstop+0x3b [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 25] > 0c 00000053`b8cff4f0 00007fff`b8a06cce ? ? m3core!RTException__Raise+0x9a [C:\s\cm3\m3-libs\m3core\src\runtime\ex_frame\RTExFrame.m3 @ 90] > 0d 00000053`b8cff550 00007ff8`2d57626a ? ? m3core!RTHooks__ReportFault+0xfe [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTHooks.m3 @ 112] > *0e 00000053`b8cff5f0 00007ff8`2d5747f2 ? ? m3tcp!M_TCP_L_100_CRASH+0x1a [C:\s\cm3\m3-comm\tcp\AMD64_NT\TCP.m3.c @ 2759] * > *0f 00000053`b8cff620 00007ff8`2d57371c ? ? m3tcp!TCP__InitSock+0xc2 [C:\s\cm3\m3-comm\tcp\src\WIN32\TCP.m3 @ 310] * > 10 00000053`b8cff680 00007fff`fe8302b3 ? ? m3tcp!TCP__NewConnector+0xdc [C:\s\cm3\m3-comm\tcp\src\WIN32\TCP.m3 @ 72] > 11 00000053`b8cff720 00007fff`fe82d814 ? ? sharedobj!LocalObjectSpace__SpaceInit+0x283 [C:\s\cm3\m3-comm\sharedobj\src\LocalObjectSpace.m3 @ 391] > 12 00000053`b8cff930 00007fff`b8a21e17 ? ? sharedobj!LocalObjectSpace_M3+0x94 [C:\s\cm3\m3-comm\sharedobj\src\LocalObjectSpace.m3 @ 805] > 13 00000053`b8cff990 00007fff`b8a21c9a ? ? m3core!RTLinker__RunMainBody+0x3e7 [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTLinker.m3 @ 408] > 14 00000053`b8cffa30 00007fff`b8a21c9a ? ? m3core!RTLinker__RunMainBody+0x26a [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTLinker.m3 @ 389] > 15 00000053`b8cffad0 00007fff`b8a21c9a ? ? m3core!RTLinker__RunMainBody+0x26a [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTLinker.m3 @ 389] > 16 00000053`b8cffb70 00007fff`b8a21c9a ? ? m3core!RTLinker__RunMainBody+0x26a [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTLinker.m3 @ 389] > 17 00000053`b8cffc10 00007fff`b8a2209b ? ? m3core!RTLinker__RunMainBody+0x26a [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTLinker.m3 @ 389] > 18 00000053`b8cffcb0 00007fff`b8a21818 ? ? m3core!RTLinker__AddUnitI+0x11b [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTLinker.m3 @ 116] > 19 00000053`b8cffcf0 00007ff6`f5b31038 ? ? m3core!RTLinker__AddUnit+0x118 [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTLinker.m3 @ 125] > 1a 00000053`b8cffd50 00007ff6`f5db4d38 ? ? mentor!main+0x38 [C:\s\cm3\m3-demo\mentor\AMD64_NT\_m3main.c @ 23] > 1b (Inline Function) --------`-------- ? ? mentor!invoke_main+0x22 [d:\agent\_work\5\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl @ 78] > 1c 00000053`b8cffd80 00007ff8`49a67034 ? ? mentor!__scrt_common_main_seh+0x10c [d:\agent\_work\5\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl @ 288] > 1d 00000053`b8cffdc0 00007ff8`4a8fd241 ? ? KERNEL32!BaseThreadInitThunk+0x14 [clientcore\base\win32\client\thread.c @ 64] > 1e 00000053`b8cffdf0 00000000`00000000 ? ? ntdll!RtlUserThreadStart+0x21 [minkernel\ntdll\rtlstrt.c @ 1153] > > *** > *** runtime error: > *** ? ?An enumeration or subrange value was out of range. > *** ? ?file "..\src\WIN32\TCP.m3", line 310 > *** > > it is "simple" subrange problem. > > > ? ? IF WinSock.ioctlsocket(sock, *WinSock.FIONBIO*, ADR(one)) = SockErr THEN > ? ? ? IPError.Die(); > ? ? END; > > > It is *not* calling that IPError.Die(). > > ioctlsocket is declared as: > > PROCEDURE ioctlsocket (s: SOCKET; cmd: INT32; argp: UNTRACED REF UINT32): INT32; > > ? INT32 = Cstdint.int32_t; > > ? int32_t = Cstdint.int32_t; > ? ? ? int32_t = Ctypes.int; > ? int ? ? ? ? ? ? ? ?= [-16_7fffffff-1 .. 16_7fffffff]; On 32 bits, -16_7fffffff-1 comes out 16_80000000, which is FIRST((*32-bit*)INTEGER). on 64, it comes out 16_ffffffff80000000, a negative number. and ... > > It is range checking ioctlsocket parameter WinSock.FIONBIO against that and rejecting it. > > The code is: > > ? 307 00007ff8`2d5747ca e847620000 ? ? ?call ? ?m3tcp!setsockopt (00007ff8`2d57aa16) ? previous line > ? 307 00007ff8`2d5747cf 89442430 ? ? ? ?mov ? ? dword ptr [rsp+30h],eax > *? 310 00007ff8`2d5747d3 b87e660880 ? ? ?mov ? ? eax,8008667Eh On 32 bits, 8008667Eh is a negative number, but not as negative as FIRST(INT32), thus in the range, and would not have failed. On 64 bits, when zero extended, its a positive number > LAST (INT32), thus the range failure. To get it similarly in range, it would have to be sign extended to 16_ffffffff8008667e. Looking at WinSock.i3, these commands are all coded as positive numbers, thus the zero-extend is correct for the language and compiler. They certainly look like they should indeed be positive. If so, the formal cmd of ioctlsocket should be UINT32, which, after following renames on a very merry chase around Robin Hood's barn, is [16_0..16_ffffffff]. On a 32-bit machine, UINT32 should really be Word.T, which is the same as INTEGER, but hints to a human reader that the integer is going to be treated as full-range unsigned, in the operators applied to it. This is the way it is declared in C/32BITS/BasicCTypes.i3. For Windows, there are not separate versions of BasicCTypes.i3 for the two word sizes. The declaration in C/WIN64/BasicCTypes.i3 would not compile on a 32-bit host. I would guess that "from the BSD file fcntl.h" probably indicates they are all intended to be positive. I'd bet there are more places in WinSock that also need to be UINT32. ? ? ? ? ? ? ? ? ? ? ? ? ? ?WinSock.FIONBIO* > ? 310 00007ff8`2d5747d8 4889442440 ? ? ?mov ? ? qword ptr [rsp+40h],rax > ? 310 00007ff8`2d5747dd 48817c2440ffffff7f cmp ? qword ptr [rsp+40h],7FFFFFFFh > ? 310 00007ff8`2d5747e6 7e0a ? ? ? ? ? ?jle ? ? m3tcp!TCP__InitSock+0xc2 (00007ff8`2d5747f2) ?Branch > > m3tcp!TCP__InitSock+0xb8 [C:\s\cm3\m3-comm\tcp\src\WIN32\TCP.m3 @ 310]: > ? 310 00007ff8`2d5747e8 b9c1260000 ? ? ?mov ? ? ecx,26C1h > ? 310 00007ff8`2d5747ed e85e1a0000 ? ? ?call ? ?m3tcp!M_TCP_L_100_CRASH (00007ff8`2d576250) > > dv /V > > 00000053`b8cff660 @rsp+0x0040 ? ? ? ? ? L_345_L_346 = 0n2148034174 > > mov eax, constant > > is zero extending > > and to confirm: > > > C:\s>type fio.c > ?#include > #include > > int main() > { > printf("%d %x\n", FIONBIO, FIONBIO); > return 0; > } > > C:\s>cl fio.c > Microsoft (R) C/C++ Optimizing Compiler Version 19.24.28316 for x64 > Copyright (C) Microsoft Corporation. ?All rights reserved. > > fio.c > Microsoft (R) Incremental Linker Version 14.24.28316.0 > Copyright (C) Microsoft Corporation. ?All rights reserved. > > /out:fio.exe > fio.obj > > C:\s>fio.exe > -2147195266 8004667e > > > What is the right way to do this? > > Just change to UINT32? > Even it works, can you explain it to me? > I agree integers should not silently overflow, subranges are good, > but this doesn't seem to me like it should be so difficult. > > I am inclined to further drain the Modula-3 "headers" > and make it an "extern constant variable", really, > though I'm not sure that will help, though it serves > another purpose -- I like to minimally duplicate C headers. > That is one way Posix ports became much easier. > > Thank you, > ?- 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 Mon Feb 22 04:23:44 2021 From: jayk123 at hotmail.com (Jay K) Date: Mon, 22 Feb 2021 03:23:44 +0000 Subject: [M3devel] Modula-3 subranges vs. opaque arbitrary 32bit constants? In-Reply-To: <0ea053e7-ecc8-88ab-0355-c1119a71e21f@lcwb.coop> References: , <0ea053e7-ecc8-88ab-0355-c1119a71e21f@lcwb.coop> Message-ID: Thank you. Right, switching this to UINT32, and others to INT32 worked out: Win64: Fix some unsigned/signed problems around ? modula3/cm3 at aabd114 (github.com) These numbers are all opaque though. I just need to pass them around via assignment. I don't even need equality comparisons. It'd be nice if that was easier. Ok, er, I also need to form constants to them, but I could move that to C, am inclined to really, later. I can now build the AMD64_NT system and for example BadBricks works. Probably "everything" works, as well as NT386 ever did. After this I will move on to ARM64_LINUX, ARM64_DARWIN, ARM64_NT. Which should be pretty trivial. I'd like to do ARM32_{LINUX, DARWIN, NT} releases also, but the Apple M1 cannot run those..maybe under qemu at least ARM32_LINUX. But there are already releases of that, and not clear if anyone cares. And if I get time, maybe after this, some pure C releases, i.e. the dream of the only targets being: {32,64} x {NT,Unix} x {LittleEndian,BigEndian}. And BigEndian is hard to find (Sparc, some Alpha, some PowerPC, HPPA, some Mips), and 32bit can maybe omit entirely these days? And then...what should the distribution format be -- generate cmake? generate autotools? generate custom makefile? Later.. - Jay ________________________________ From: Rodney M. Bates Sent: Monday, February 22, 2021 2:54 AM To: Jay K ; m3devel Subject: Re: [M3devel] Modula-3 subranges vs. opaque arbitrary 32bit constants? I can explain what is happening and probably what needs to be done. See below --- On 2/21/21 4:08 PM, Jay K wrote: > Maybe it is a bug in the Modula-3 Windows headers cloning, or in the C backend. > I'm not sure. > Please help me to understand? > > The AMD64_NT port works well enough, again, that it can build the runtime and compiler, and the compiler > can build everything. > > But networking fails, here: > > 0:000> k > # Child-SP RetAddr Call Site > 00 (Inline Function) --------`-------- KERNELBASE!DebugBreak [minkernel\kernelbase\debug.c @ 143] > 01 00000053`b8cff188 00007fff`b8a35e93 KERNELBASE!wil::details::DebugBreak+0x2 [onecore\internal\sdk\inc\wil\opensource\wil\result_macros.h @ 1737] > 02 00000053`b8cff190 00007fff`b8a2682f m3core!RTOS__Crash+0x43 [C:\s\cm3\m3-libs\m3core\src\runtime\WIN32\RTOS.m3 @ 26] > 03 00000053`b8cff1e0 00007fff`b8a23bef m3core!RTProcess__Crash+0x6f [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTProcess.m3 @ 66] > 04 00000053`b8cff220 00007fff`b8a23820 m3core!RTError__EndError+0x3f [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTError.m3 @ 119] > 05 00000053`b8cff260 00007fff`b8a24257 m3core!RTError__MsgS+0xa0 [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTError.m3 @ 41] > 06 00000053`b8cff2a0 00007fff`b8a23e5e m3core!RTException__Crash+0x317 [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 81] > 07 00000053`b8cff330 00007fff`b8a23d4b m3core!RTException__DefaultBackstop+0xce [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 39] > 08 00000053`b8cff3a0 00007fff`b8a37d7a m3core!RTException__InvokeBackstop+0x3b [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 25] > 09 00000053`b8cff3e0 00007fff`b8a23f2a m3core!RTException__Raise+0x9a [C:\s\cm3\m3-libs\m3core\src\runtime\ex_frame\RTExFrame.m3 @ 90] > 0a 00000053`b8cff440 00007fff`b8a23d4b m3core!RTException__DefaultBackstop+0x19a [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 49] > 0b 00000053`b8cff4b0 00007fff`b8a37d7a m3core!RTException__InvokeBackstop+0x3b [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 25] > 0c 00000053`b8cff4f0 00007fff`b8a06cce m3core!RTException__Raise+0x9a [C:\s\cm3\m3-libs\m3core\src\runtime\ex_frame\RTExFrame.m3 @ 90] > 0d 00000053`b8cff550 00007ff8`2d57626a m3core!RTHooks__ReportFault+0xfe [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTHooks.m3 @ 112] > *0e 00000053`b8cff5f0 00007ff8`2d5747f2 m3tcp!M_TCP_L_100_CRASH+0x1a [C:\s\cm3\m3-comm\tcp\AMD64_NT\TCP.m3.c @ 2759] * > *0f 00000053`b8cff620 00007ff8`2d57371c m3tcp!TCP__InitSock+0xc2 [C:\s\cm3\m3-comm\tcp\src\WIN32\TCP.m3 @ 310] * > 10 00000053`b8cff680 00007fff`fe8302b3 m3tcp!TCP__NewConnector+0xdc [C:\s\cm3\m3-comm\tcp\src\WIN32\TCP.m3 @ 72] > 11 00000053`b8cff720 00007fff`fe82d814 sharedobj!LocalObjectSpace__SpaceInit+0x283 [C:\s\cm3\m3-comm\sharedobj\src\LocalObjectSpace.m3 @ 391] > 12 00000053`b8cff930 00007fff`b8a21e17 sharedobj!LocalObjectSpace_M3+0x94 [C:\s\cm3\m3-comm\sharedobj\src\LocalObjectSpace.m3 @ 805] > 13 00000053`b8cff990 00007fff`b8a21c9a m3core!RTLinker__RunMainBody+0x3e7 [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTLinker.m3 @ 408] > 14 00000053`b8cffa30 00007fff`b8a21c9a m3core!RTLinker__RunMainBody+0x26a [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTLinker.m3 @ 389] > 15 00000053`b8cffad0 00007fff`b8a21c9a m3core!RTLinker__RunMainBody+0x26a [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTLinker.m3 @ 389] > 16 00000053`b8cffb70 00007fff`b8a21c9a m3core!RTLinker__RunMainBody+0x26a [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTLinker.m3 @ 389] > 17 00000053`b8cffc10 00007fff`b8a2209b m3core!RTLinker__RunMainBody+0x26a [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTLinker.m3 @ 389] > 18 00000053`b8cffcb0 00007fff`b8a21818 m3core!RTLinker__AddUnitI+0x11b [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTLinker.m3 @ 116] > 19 00000053`b8cffcf0 00007ff6`f5b31038 m3core!RTLinker__AddUnit+0x118 [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTLinker.m3 @ 125] > 1a 00000053`b8cffd50 00007ff6`f5db4d38 mentor!main+0x38 [C:\s\cm3\m3-demo\mentor\AMD64_NT\_m3main.c @ 23] > 1b (Inline Function) --------`-------- mentor!invoke_main+0x22 [d:\agent\_work\5\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl @ 78] > 1c 00000053`b8cffd80 00007ff8`49a67034 mentor!__scrt_common_main_seh+0x10c [d:\agent\_work\5\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl @ 288] > 1d 00000053`b8cffdc0 00007ff8`4a8fd241 KERNEL32!BaseThreadInitThunk+0x14 [clientcore\base\win32\client\thread.c @ 64] > 1e 00000053`b8cffdf0 00000000`00000000 ntdll!RtlUserThreadStart+0x21 [minkernel\ntdll\rtlstrt.c @ 1153] > > *** > *** runtime error: > *** An enumeration or subrange value was out of range. > *** file "..\src\WIN32\TCP.m3", line 310 > *** > > it is "simple" subrange problem. > > > IF WinSock.ioctlsocket(sock, *WinSock.FIONBIO*, ADR(one)) = SockErr THEN > IPError.Die(); > END; > > > It is *not* calling that IPError.Die(). > > ioctlsocket is declared as: > > PROCEDURE ioctlsocket (s: SOCKET; cmd: INT32; argp: UNTRACED REF UINT32): INT32; > > INT32 = Cstdint.int32_t; > > int32_t = Cstdint.int32_t; > int32_t = Ctypes.int; > int = [-16_7fffffff-1 .. 16_7fffffff]; On 32 bits, -16_7fffffff-1 comes out 16_80000000, which is FIRST((*32-bit*)INTEGER). on 64, it comes out 16_ffffffff80000000, a negative number. and ... > > It is range checking ioctlsocket parameter WinSock.FIONBIO against that and rejecting it. > > The code is: > > 307 00007ff8`2d5747ca e847620000 call m3tcp!setsockopt (00007ff8`2d57aa16) previous line > 307 00007ff8`2d5747cf 89442430 mov dword ptr [rsp+30h],eax > * 310 00007ff8`2d5747d3 b87e660880 mov eax,8008667Eh On 32 bits, 8008667Eh is a negative number, but not as negative as FIRST(INT32), thus in the range, and would not have failed. On 64 bits, when zero extended, its a positive number > LAST (INT32), thus the range failure. To get it similarly in range, it would have to be sign extended to 16_ffffffff8008667e. Looking at WinSock.i3, these commands are all coded as positive numbers, thus the zero-extend is correct for the language and compiler. They certainly look like they should indeed be positive. If so, the formal cmd of ioctlsocket should be UINT32, which, after following renames on a very merry chase around Robin Hood's barn, is [16_0..16_ffffffff]. On a 32-bit machine, UINT32 should really be Word.T, which is the same as INTEGER, but hints to a human reader that the integer is going to be treated as full-range unsigned, in the operators applied to it. This is the way it is declared in C/32BITS/BasicCTypes.i3. For Windows, there are not separate versions of BasicCTypes.i3 for the two word sizes. The declaration in C/WIN64/BasicCTypes.i3 would not compile on a 32-bit host. I would guess that "from the BSD file fcntl.h" probably indicates they are all intended to be positive. I'd bet there are more places in WinSock that also need to be UINT32. WinSock.FIONBIO* > 310 00007ff8`2d5747d8 4889442440 mov qword ptr [rsp+40h],rax > 310 00007ff8`2d5747dd 48817c2440ffffff7f cmp qword ptr [rsp+40h],7FFFFFFFh > 310 00007ff8`2d5747e6 7e0a jle m3tcp!TCP__InitSock+0xc2 (00007ff8`2d5747f2) Branch > > m3tcp!TCP__InitSock+0xb8 [C:\s\cm3\m3-comm\tcp\src\WIN32\TCP.m3 @ 310]: > 310 00007ff8`2d5747e8 b9c1260000 mov ecx,26C1h > 310 00007ff8`2d5747ed e85e1a0000 call m3tcp!M_TCP_L_100_CRASH (00007ff8`2d576250) > > dv /V > > 00000053`b8cff660 @rsp+0x0040 L_345_L_346 = 0n2148034174 > > mov eax, constant > > is zero extending > > and to confirm: > > > C:\s>type fio.c > #include > #include > > int main() > { > printf("%d %x\n", FIONBIO, FIONBIO); > return 0; > } > > C:\s>cl fio.c > Microsoft (R) C/C++ Optimizing Compiler Version 19.24.28316 for x64 > Copyright (C) Microsoft Corporation. All rights reserved. > > fio.c > Microsoft (R) Incremental Linker Version 14.24.28316.0 > Copyright (C) Microsoft Corporation. All rights reserved. > > /out:fio.exe > fio.obj > > C:\s>fio.exe > -2147195266 8004667e > > > What is the right way to do this? > > Just change to UINT32? > Even it works, can you explain it to me? > I agree integers should not silently overflow, subranges are good, > but this doesn't seem to me like it should be so difficult. > > I am inclined to further drain the Modula-3 "headers" > and make it an "extern constant variable", really, > though I'm not sure that will help, though it serves > another purpose -- I like to minimally duplicate C headers. > That is one way Posix ports became much easier. > > Thank you, > - Jay > > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fm3lists.elegosoft.com%2Fmailman%2Flistinfo%2Fm3devel&data=04%7C01%7C%7C8fd1a7a5057a4abf429708d8d6dd3537%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637495592871746870%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=px64IdlrA%2BpfFXi8JCkCJx3jmGIJ%2BVhzZ1dSCOWhB6c%3D&reserved=0 > -- Rodney Bates rodney.m.bates at acm.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Feb 22 04:28:47 2021 From: jayk123 at hotmail.com (Jay K) Date: Mon, 22 Feb 2021 03:28:47 +0000 Subject: [M3devel] new release for AMD64_NT Message-ID: I made a new release, for AMD64_NT. Release AMD64_NT-d5.10.0-VC2019-20210221 ? modula3/cm3 (github.com) Anyone want to try it and report? I guess I should make I386_NT also? People want that and will try it? Not much has changed, except AMD64_NT should, ahem, work. This uses the C backend (of course ? ) Thank you, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Mon Feb 22 04:34:02 2021 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Sun, 21 Feb 2021 22:34:02 -0500 Subject: [M3devel] Modula-3 subranges vs. opaque arbitrary 32bit constants? In-Reply-To: References: <0ea053e7-ecc8-88ab-0355-c1119a71e21f@lcwb.coop> Message-ID: <20210222033402.4xwebtssvlnpuuzx@topoi.pooq.com> On Mon, Feb 22, 2021 at 03:23:44AM +0000, Jay K wrote: > Thank you. Right, switching this to UINT32, and others to INT32 worked out: > Win64: Fix some unsigned/signed problems around ? modula3/cm3 at aabd114 (github.com) > > These numbers are all opaque though. > I just need to pass them around via assignment. > I don't even need equality comparisons. > It'd be nice if that was easier. > Ok, er, I also need to form constants to them, but I could move that to C, am inclined to really, later. > > I can now build the AMD64_NT system and for example BadBricks works. > Probably "everything" works, as well as NT386 ever did. > > After this I will move on to ARM64_LINUX, ARM64_DARWIN, ARM64_NT. > Which should be pretty trivial. > I'd like to do ARM32_{LINUX, DARWIN, NT} releases also, but the Apple M1 cannot run those..maybe under qemu at least ARM32_LINUX. > But there are already releases of that, and not clear if anyone cares. > > And if I get time, maybe after this, some pure C releases, i.e. the dream of the only targets being: > {32,64} x {NT,Unix} x {LittleEndian,BigEndian}. > > And BigEndian is hard to find (Sparc, some Alpha, some PowerPC, > HPPA, some Mips), and 32bit can maybe omit entirely these days? The machine I run Modula 3 on is a Linux 32-bit intel machine. I would be sorry if that were to die. I would like to see the C release, though, just for long-term portability. -- hendrik > > And then...what should the distribution format be -- generate cmake? generate autotools? generate custom makefile? > Later.. > > - Jay > > ________________________________ > From: Rodney M. Bates > Sent: Monday, February 22, 2021 2:54 AM > To: Jay K ; m3devel > Subject: Re: [M3devel] Modula-3 subranges vs. opaque arbitrary 32bit constants? > > I can explain what is happening and probably what needs to be done. See below --- > > On 2/21/21 4:08 PM, Jay K wrote: > > Maybe it is a bug in the Modula-3 Windows headers cloning, or in the C backend. > > I'm not sure. > > Please help me to understand? > > > > The AMD64_NT port works well enough, again, that it can build the runtime and compiler, and the compiler > > can build everything. > > > > But networking fails, here: > > > > 0:000> k > > # Child-SP RetAddr Call Site > > 00 (Inline Function) --------`-------- KERNELBASE!DebugBreak [minkernel\kernelbase\debug.c @ 143] > > 01 00000053`b8cff188 00007fff`b8a35e93 KERNELBASE!wil::details::DebugBreak+0x2 [onecore\internal\sdk\inc\wil\opensource\wil\result_macros.h @ 1737] > > 02 00000053`b8cff190 00007fff`b8a2682f m3core!RTOS__Crash+0x43 [C:\s\cm3\m3-libs\m3core\src\runtime\WIN32\RTOS.m3 @ 26] > > 03 00000053`b8cff1e0 00007fff`b8a23bef m3core!RTProcess__Crash+0x6f [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTProcess.m3 @ 66] > > 04 00000053`b8cff220 00007fff`b8a23820 m3core!RTError__EndError+0x3f [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTError.m3 @ 119] > > 05 00000053`b8cff260 00007fff`b8a24257 m3core!RTError__MsgS+0xa0 [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTError.m3 @ 41] > > 06 00000053`b8cff2a0 00007fff`b8a23e5e m3core!RTException__Crash+0x317 [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 81] > > 07 00000053`b8cff330 00007fff`b8a23d4b m3core!RTException__DefaultBackstop+0xce [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 39] > > 08 00000053`b8cff3a0 00007fff`b8a37d7a m3core!RTException__InvokeBackstop+0x3b [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 25] > > 09 00000053`b8cff3e0 00007fff`b8a23f2a m3core!RTException__Raise+0x9a [C:\s\cm3\m3-libs\m3core\src\runtime\ex_frame\RTExFrame.m3 @ 90] > > 0a 00000053`b8cff440 00007fff`b8a23d4b m3core!RTException__DefaultBackstop+0x19a [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 49] > > 0b 00000053`b8cff4b0 00007fff`b8a37d7a m3core!RTException__InvokeBackstop+0x3b [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 25] > > 0c 00000053`b8cff4f0 00007fff`b8a06cce m3core!RTException__Raise+0x9a [C:\s\cm3\m3-libs\m3core\src\runtime\ex_frame\RTExFrame.m3 @ 90] > > 0d 00000053`b8cff550 00007ff8`2d57626a m3core!RTHooks__ReportFault+0xfe [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTHooks.m3 @ 112] > > *0e 00000053`b8cff5f0 00007ff8`2d5747f2 m3tcp!M_TCP_L_100_CRASH+0x1a [C:\s\cm3\m3-comm\tcp\AMD64_NT\TCP.m3.c @ 2759] * > > *0f 00000053`b8cff620 00007ff8`2d57371c m3tcp!TCP__InitSock+0xc2 [C:\s\cm3\m3-comm\tcp\src\WIN32\TCP.m3 @ 310] * > > 10 00000053`b8cff680 00007fff`fe8302b3 m3tcp!TCP__NewConnector+0xdc [C:\s\cm3\m3-comm\tcp\src\WIN32\TCP.m3 @ 72] > > 11 00000053`b8cff720 00007fff`fe82d814 sharedobj!LocalObjectSpace__SpaceInit+0x283 [C:\s\cm3\m3-comm\sharedobj\src\LocalObjectSpace.m3 @ 391] > > 12 00000053`b8cff930 00007fff`b8a21e17 sharedobj!LocalObjectSpace_M3+0x94 [C:\s\cm3\m3-comm\sharedobj\src\LocalObjectSpace.m3 @ 805] > > 13 00000053`b8cff990 00007fff`b8a21c9a m3core!RTLinker__RunMainBody+0x3e7 [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTLinker.m3 @ 408] > > 14 00000053`b8cffa30 00007fff`b8a21c9a m3core!RTLinker__RunMainBody+0x26a [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTLinker.m3 @ 389] > > 15 00000053`b8cffad0 00007fff`b8a21c9a m3core!RTLinker__RunMainBody+0x26a [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTLinker.m3 @ 389] > > 16 00000053`b8cffb70 00007fff`b8a21c9a m3core!RTLinker__RunMainBody+0x26a [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTLinker.m3 @ 389] > > 17 00000053`b8cffc10 00007fff`b8a2209b m3core!RTLinker__RunMainBody+0x26a [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTLinker.m3 @ 389] > > 18 00000053`b8cffcb0 00007fff`b8a21818 m3core!RTLinker__AddUnitI+0x11b [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTLinker.m3 @ 116] > > 19 00000053`b8cffcf0 00007ff6`f5b31038 m3core!RTLinker__AddUnit+0x118 [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTLinker.m3 @ 125] > > 1a 00000053`b8cffd50 00007ff6`f5db4d38 mentor!main+0x38 [C:\s\cm3\m3-demo\mentor\AMD64_NT\_m3main.c @ 23] > > 1b (Inline Function) --------`-------- mentor!invoke_main+0x22 [d:\agent\_work\5\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl @ 78] > > 1c 00000053`b8cffd80 00007ff8`49a67034 mentor!__scrt_common_main_seh+0x10c [d:\agent\_work\5\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl @ 288] > > 1d 00000053`b8cffdc0 00007ff8`4a8fd241 KERNEL32!BaseThreadInitThunk+0x14 [clientcore\base\win32\client\thread.c @ 64] > > 1e 00000053`b8cffdf0 00000000`00000000 ntdll!RtlUserThreadStart+0x21 [minkernel\ntdll\rtlstrt.c @ 1153] > > > > *** > > *** runtime error: > > *** An enumeration or subrange value was out of range. > > *** file "..\src\WIN32\TCP.m3", line 310 > > *** > > > > it is "simple" subrange problem. > > > > > > IF WinSock.ioctlsocket(sock, *WinSock.FIONBIO*, ADR(one)) = SockErr THEN > > IPError.Die(); > > END; > > > > > > It is *not* calling that IPError.Die(). > > > > ioctlsocket is declared as: > > > > PROCEDURE ioctlsocket (s: SOCKET; cmd: INT32; argp: UNTRACED REF UINT32): INT32; > > > > INT32 = Cstdint.int32_t; > > > > int32_t = Cstdint.int32_t; > > int32_t = Ctypes.int; > > int = [-16_7fffffff-1 .. 16_7fffffff]; > > On 32 bits, -16_7fffffff-1 comes out 16_80000000, which is FIRST((*32-bit*)INTEGER). > on 64, it comes out 16_ffffffff80000000, a negative number. > > and ... > > > > > It is range checking ioctlsocket parameter WinSock.FIONBIO against that and rejecting it. > > > > The code is: > > > > 307 00007ff8`2d5747ca e847620000 call m3tcp!setsockopt (00007ff8`2d57aa16) previous line > > 307 00007ff8`2d5747cf 89442430 mov dword ptr [rsp+30h],eax > > * 310 00007ff8`2d5747d3 b87e660880 mov eax,8008667Eh > > On 32 bits, 8008667Eh is a negative number, but not as negative as FIRST(INT32), > thus in the range, and would not have failed. > > On 64 bits, when zero extended, its a positive number > LAST (INT32), thus the range failure. > To get it similarly in range, it would have to be sign extended to 16_ffffffff8008667e. > > Looking at WinSock.i3, these commands are all coded as positive numbers, thus the zero-extend > is correct for the language and compiler. > > They certainly look like they should indeed be positive. If so, the formal cmd of > ioctlsocket should be UINT32, which, after following renames on a very merry chase > around Robin Hood's barn, is [16_0..16_ffffffff]. > > On a 32-bit machine, UINT32 should really be Word.T, which is the same as > INTEGER, but hints to a human reader that the integer is going to be treated > as full-range unsigned, in the operators applied to it. This is the way > it is declared in C/32BITS/BasicCTypes.i3. > > For Windows, there are not separate versions of BasicCTypes.i3 for the two word sizes. > The declaration in C/WIN64/BasicCTypes.i3 would not compile on a 32-bit host. > > I would guess that "from the BSD file fcntl.h" probably indicates they are all > intended to be positive. I'd bet there are more places in WinSock that also > need to be UINT32. > > > WinSock.FIONBIO* > > 310 00007ff8`2d5747d8 4889442440 mov qword ptr [rsp+40h],rax > > 310 00007ff8`2d5747dd 48817c2440ffffff7f cmp qword ptr [rsp+40h],7FFFFFFFh > > 310 00007ff8`2d5747e6 7e0a jle m3tcp!TCP__InitSock+0xc2 (00007ff8`2d5747f2) Branch > > > > m3tcp!TCP__InitSock+0xb8 [C:\s\cm3\m3-comm\tcp\src\WIN32\TCP.m3 @ 310]: > > 310 00007ff8`2d5747e8 b9c1260000 mov ecx,26C1h > > 310 00007ff8`2d5747ed e85e1a0000 call m3tcp!M_TCP_L_100_CRASH (00007ff8`2d576250) > > > > dv /V > > > > 00000053`b8cff660 @rsp+0x0040 L_345_L_346 = 0n2148034174 > > > > mov eax, constant > > > > is zero extending > > > > and to confirm: > > > > > > C:\s>type fio.c > > #include > > #include > > > > int main() > > { > > printf("%d %x\n", FIONBIO, FIONBIO); > > return 0; > > } > > > > C:\s>cl fio.c > > Microsoft (R) C/C++ Optimizing Compiler Version 19.24.28316 for x64 > > Copyright (C) Microsoft Corporation. All rights reserved. > > > > fio.c > > Microsoft (R) Incremental Linker Version 14.24.28316.0 > > Copyright (C) Microsoft Corporation. All rights reserved. > > > > /out:fio.exe > > fio.obj > > > > C:\s>fio.exe > > -2147195266 8004667e > > > > > > What is the right way to do this? > > > > Just change to UINT32? > > Even it works, can you explain it to me? > > I agree integers should not silently overflow, subranges are good, > > but this doesn't seem to me like it should be so difficult. > > > > I am inclined to further drain the Modula-3 "headers" > > and make it an "extern constant variable", really, > > though I'm not sure that will help, though it serves > > another purpose -- I like to minimally duplicate C headers. > > That is one way Posix ports became much easier. > > > > Thank you, > > - Jay > > > > _______________________________________________ > > M3devel mailing list > > M3devel at elegosoft.com > > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fm3lists.elegosoft.com%2Fmailman%2Flistinfo%2Fm3devel&data=04%7C01%7C%7C8fd1a7a5057a4abf429708d8d6dd3537%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637495592871746870%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=px64IdlrA%2BpfFXi8JCkCJx3jmGIJ%2BVhzZ1dSCOWhB6c%3D&reserved=0 > > > > -- > Rodney Bates > rodney.m.bates at acm.org > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://m3lists.elegosoft.com/mailman/listinfo/m3devel From jayk123 at hotmail.com Mon Feb 22 05:46:56 2021 From: jayk123 at hotmail.com (Jay K) Date: Mon, 22 Feb 2021 04:46:56 +0000 Subject: [M3devel] Modula-3 subranges vs. opaque arbitrary 32bit constants? In-Reply-To: <20210222033402.4xwebtssvlnpuuzx@topoi.pooq.com> References: <0ea053e7-ecc8-88ab-0355-c1119a71e21f@lcwb.coop> , <20210222033402.4xwebtssvlnpuuzx@topoi.pooq.com> Message-ID: Linux/x86 I could make a release, C-backend or not. One wrinkle is that the C backend is not quite interoperable with non-C. In particular, I recall, around pointers to nested functions. The gcc backend usually has a register for the static link. C backend passes extra parameter in "regular" parameters. I wasn't going to remove anything, just, that, the idea is: tar xf m3.tar.gz cd m3 make ; using a minimum of tools, like just cc/ld. make install but the C is slightly "lowered". You cannot use one for all. And this is a step closer to: sudo apt-get install cm3 Some distributions are ok with derived files shipping, as long as the build rederives them and they are equal. This can fit that. Some distributions have other rules. I was going through Github and someone I'll claim was a beginner was able to run make-dist.py no problem once he was guided there. So someone else maybe try? Some controversy remains: - Keep m3cc around? - Make the C backend faster? I probably will, soon. In particular, to run the C compiler once with all the sources, instead of one at a time. - Debugging. I don't think I finished the work to teach m3cg about record fields. That should be done. It'll go a long way toward debugging. Debugging already works line-based, with wierd looking locals, I think better then NT386 or Darwin ever were -- no m3gdb. - And if m3cc goes away, m3gdb too, I hope. ? - Jay ________________________________ From: M3devel on behalf of Hendrik Boom Sent: Monday, February 22, 2021 3:34 AM To: m3devel at elegosoft.com Subject: Re: [M3devel] Modula-3 subranges vs. opaque arbitrary 32bit constants? On Mon, Feb 22, 2021 at 03:23:44AM +0000, Jay K wrote: > Thank you. Right, switching this to UINT32, and others to INT32 worked out: > Win64: Fix some unsigned/signed problems around ? modula3/cm3 at aabd114 (github.com) > > These numbers are all opaque though. > I just need to pass them around via assignment. > I don't even need equality comparisons. > It'd be nice if that was easier. > Ok, er, I also need to form constants to them, but I could move that to C, am inclined to really, later. > > I can now build the AMD64_NT system and for example BadBricks works. > Probably "everything" works, as well as NT386 ever did. > > After this I will move on to ARM64_LINUX, ARM64_DARWIN, ARM64_NT. > Which should be pretty trivial. > I'd like to do ARM32_{LINUX, DARWIN, NT} releases also, but the Apple M1 cannot run those..maybe under qemu at least ARM32_LINUX. > But there are already releases of that, and not clear if anyone cares. > > And if I get time, maybe after this, some pure C releases, i.e. the dream of the only targets being: > {32,64} x {NT,Unix} x {LittleEndian,BigEndian}. > > And BigEndian is hard to find (Sparc, some Alpha, some PowerPC, > HPPA, some Mips), and 32bit can maybe omit entirely these days? The machine I run Modula 3 on is a Linux 32-bit intel machine. I would be sorry if that were to die. I would like to see the C release, though, just for long-term portability. -- hendrik > > And then...what should the distribution format be -- generate cmake? generate autotools? generate custom makefile? > Later.. > > - Jay > > ________________________________ > From: Rodney M. Bates > Sent: Monday, February 22, 2021 2:54 AM > To: Jay K ; m3devel > Subject: Re: [M3devel] Modula-3 subranges vs. opaque arbitrary 32bit constants? > > I can explain what is happening and probably what needs to be done. See below --- > > On 2/21/21 4:08 PM, Jay K wrote: > > Maybe it is a bug in the Modula-3 Windows headers cloning, or in the C backend. > > I'm not sure. > > Please help me to understand? > > > > The AMD64_NT port works well enough, again, that it can build the runtime and compiler, and the compiler > > can build everything. > > > > But networking fails, here: > > > > 0:000> k > > # Child-SP RetAddr Call Site > > 00 (Inline Function) --------`-------- KERNELBASE!DebugBreak [minkernel\kernelbase\debug.c @ 143] > > 01 00000053`b8cff188 00007fff`b8a35e93 KERNELBASE!wil::details::DebugBreak+0x2 [onecore\internal\sdk\inc\wil\opensource\wil\result_macros.h @ 1737] > > 02 00000053`b8cff190 00007fff`b8a2682f m3core!RTOS__Crash+0x43 [C:\s\cm3\m3-libs\m3core\src\runtime\WIN32\RTOS.m3 @ 26] > > 03 00000053`b8cff1e0 00007fff`b8a23bef m3core!RTProcess__Crash+0x6f [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTProcess.m3 @ 66] > > 04 00000053`b8cff220 00007fff`b8a23820 m3core!RTError__EndError+0x3f [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTError.m3 @ 119] > > 05 00000053`b8cff260 00007fff`b8a24257 m3core!RTError__MsgS+0xa0 [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTError.m3 @ 41] > > 06 00000053`b8cff2a0 00007fff`b8a23e5e m3core!RTException__Crash+0x317 [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 81] > > 07 00000053`b8cff330 00007fff`b8a23d4b m3core!RTException__DefaultBackstop+0xce [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 39] > > 08 00000053`b8cff3a0 00007fff`b8a37d7a m3core!RTException__InvokeBackstop+0x3b [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 25] > > 09 00000053`b8cff3e0 00007fff`b8a23f2a m3core!RTException__Raise+0x9a [C:\s\cm3\m3-libs\m3core\src\runtime\ex_frame\RTExFrame.m3 @ 90] > > 0a 00000053`b8cff440 00007fff`b8a23d4b m3core!RTException__DefaultBackstop+0x19a [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 49] > > 0b 00000053`b8cff4b0 00007fff`b8a37d7a m3core!RTException__InvokeBackstop+0x3b [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 25] > > 0c 00000053`b8cff4f0 00007fff`b8a06cce m3core!RTException__Raise+0x9a [C:\s\cm3\m3-libs\m3core\src\runtime\ex_frame\RTExFrame.m3 @ 90] > > 0d 00000053`b8cff550 00007ff8`2d57626a m3core!RTHooks__ReportFault+0xfe [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTHooks.m3 @ 112] > > *0e 00000053`b8cff5f0 00007ff8`2d5747f2 m3tcp!M_TCP_L_100_CRASH+0x1a [C:\s\cm3\m3-comm\tcp\AMD64_NT\TCP.m3.c @ 2759] * > > *0f 00000053`b8cff620 00007ff8`2d57371c m3tcp!TCP__InitSock+0xc2 [C:\s\cm3\m3-comm\tcp\src\WIN32\TCP.m3 @ 310] * > > 10 00000053`b8cff680 00007fff`fe8302b3 m3tcp!TCP__NewConnector+0xdc [C:\s\cm3\m3-comm\tcp\src\WIN32\TCP.m3 @ 72] > > 11 00000053`b8cff720 00007fff`fe82d814 sharedobj!LocalObjectSpace__SpaceInit+0x283 [C:\s\cm3\m3-comm\sharedobj\src\LocalObjectSpace.m3 @ 391] > > 12 00000053`b8cff930 00007fff`b8a21e17 sharedobj!LocalObjectSpace_M3+0x94 [C:\s\cm3\m3-comm\sharedobj\src\LocalObjectSpace.m3 @ 805] > > 13 00000053`b8cff990 00007fff`b8a21c9a m3core!RTLinker__RunMainBody+0x3e7 [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTLinker.m3 @ 408] > > 14 00000053`b8cffa30 00007fff`b8a21c9a m3core!RTLinker__RunMainBody+0x26a [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTLinker.m3 @ 389] > > 15 00000053`b8cffad0 00007fff`b8a21c9a m3core!RTLinker__RunMainBody+0x26a [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTLinker.m3 @ 389] > > 16 00000053`b8cffb70 00007fff`b8a21c9a m3core!RTLinker__RunMainBody+0x26a [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTLinker.m3 @ 389] > > 17 00000053`b8cffc10 00007fff`b8a2209b m3core!RTLinker__RunMainBody+0x26a [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTLinker.m3 @ 389] > > 18 00000053`b8cffcb0 00007fff`b8a21818 m3core!RTLinker__AddUnitI+0x11b [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTLinker.m3 @ 116] > > 19 00000053`b8cffcf0 00007ff6`f5b31038 m3core!RTLinker__AddUnit+0x118 [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTLinker.m3 @ 125] > > 1a 00000053`b8cffd50 00007ff6`f5db4d38 mentor!main+0x38 [C:\s\cm3\m3-demo\mentor\AMD64_NT\_m3main.c @ 23] > > 1b (Inline Function) --------`-------- mentor!invoke_main+0x22 [d:\agent\_work\5\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl @ 78] > > 1c 00000053`b8cffd80 00007ff8`49a67034 mentor!__scrt_common_main_seh+0x10c [d:\agent\_work\5\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl @ 288] > > 1d 00000053`b8cffdc0 00007ff8`4a8fd241 KERNEL32!BaseThreadInitThunk+0x14 [clientcore\base\win32\client\thread.c @ 64] > > 1e 00000053`b8cffdf0 00000000`00000000 ntdll!RtlUserThreadStart+0x21 [minkernel\ntdll\rtlstrt.c @ 1153] > > > > *** > > *** runtime error: > > *** An enumeration or subrange value was out of range. > > *** file "..\src\WIN32\TCP.m3", line 310 > > *** > > > > it is "simple" subrange problem. > > > > > > IF WinSock.ioctlsocket(sock, *WinSock.FIONBIO*, ADR(one)) = SockErr THEN > > IPError.Die(); > > END; > > > > > > It is *not* calling that IPError.Die(). > > > > ioctlsocket is declared as: > > > > PROCEDURE ioctlsocket (s: SOCKET; cmd: INT32; argp: UNTRACED REF UINT32): INT32; > > > > INT32 = Cstdint.int32_t; > > > > int32_t = Cstdint.int32_t; > > int32_t = Ctypes.int; > > int = [-16_7fffffff-1 .. 16_7fffffff]; > > On 32 bits, -16_7fffffff-1 comes out 16_80000000, which is FIRST((*32-bit*)INTEGER). > on 64, it comes out 16_ffffffff80000000, a negative number. > > and ... > > > > > It is range checking ioctlsocket parameter WinSock.FIONBIO against that and rejecting it. > > > > The code is: > > > > 307 00007ff8`2d5747ca e847620000 call m3tcp!setsockopt (00007ff8`2d57aa16) previous line > > 307 00007ff8`2d5747cf 89442430 mov dword ptr [rsp+30h],eax > > * 310 00007ff8`2d5747d3 b87e660880 mov eax,8008667Eh > > On 32 bits, 8008667Eh is a negative number, but not as negative as FIRST(INT32), > thus in the range, and would not have failed. > > On 64 bits, when zero extended, its a positive number > LAST (INT32), thus the range failure. > To get it similarly in range, it would have to be sign extended to 16_ffffffff8008667e. > > Looking at WinSock.i3, these commands are all coded as positive numbers, thus the zero-extend > is correct for the language and compiler. > > They certainly look like they should indeed be positive. If so, the formal cmd of > ioctlsocket should be UINT32, which, after following renames on a very merry chase > around Robin Hood's barn, is [16_0..16_ffffffff]. > > On a 32-bit machine, UINT32 should really be Word.T, which is the same as > INTEGER, but hints to a human reader that the integer is going to be treated > as full-range unsigned, in the operators applied to it. This is the way > it is declared in C/32BITS/BasicCTypes.i3. > > For Windows, there are not separate versions of BasicCTypes.i3 for the two word sizes. > The declaration in C/WIN64/BasicCTypes.i3 would not compile on a 32-bit host. > > I would guess that "from the BSD file fcntl.h" probably indicates they are all > intended to be positive. I'd bet there are more places in WinSock that also > need to be UINT32. > > > WinSock.FIONBIO* > > 310 00007ff8`2d5747d8 4889442440 mov qword ptr [rsp+40h],rax > > 310 00007ff8`2d5747dd 48817c2440ffffff7f cmp qword ptr [rsp+40h],7FFFFFFFh > > 310 00007ff8`2d5747e6 7e0a jle m3tcp!TCP__InitSock+0xc2 (00007ff8`2d5747f2) Branch > > > > m3tcp!TCP__InitSock+0xb8 [C:\s\cm3\m3-comm\tcp\src\WIN32\TCP.m3 @ 310]: > > 310 00007ff8`2d5747e8 b9c1260000 mov ecx,26C1h > > 310 00007ff8`2d5747ed e85e1a0000 call m3tcp!M_TCP_L_100_CRASH (00007ff8`2d576250) > > > > dv /V > > > > 00000053`b8cff660 @rsp+0x0040 L_345_L_346 = 0n2148034174 > > > > mov eax, constant > > > > is zero extending > > > > and to confirm: > > > > > > C:\s>type fio.c > > #include > > #include > > > > int main() > > { > > printf("%d %x\n", FIONBIO, FIONBIO); > > return 0; > > } > > > > C:\s>cl fio.c > > Microsoft (R) C/C++ Optimizing Compiler Version 19.24.28316 for x64 > > Copyright (C) Microsoft Corporation. All rights reserved. > > > > fio.c > > Microsoft (R) Incremental Linker Version 14.24.28316.0 > > Copyright (C) Microsoft Corporation. All rights reserved. > > > > /out:fio.exe > > fio.obj > > > > C:\s>fio.exe > > -2147195266 8004667e > > > > > > What is the right way to do this? > > > > Just change to UINT32? > > Even it works, can you explain it to me? > > I agree integers should not silently overflow, subranges are good, > > but this doesn't seem to me like it should be so difficult. > > > > I am inclined to further drain the Modula-3 "headers" > > and make it an "extern constant variable", really, > > though I'm not sure that will help, though it serves > > another purpose -- I like to minimally duplicate C headers. > > That is one way Posix ports became much easier. > > > > Thank you, > > - Jay > > > > _______________________________________________ > > M3devel mailing list > > M3devel at elegosoft.com > > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fm3lists.elegosoft.com%2Fmailman%2Flistinfo%2Fm3devel&data=04%7C01%7C%7C1e32400e20b747c9a69108d8d6e2c0c0%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637495616693997646%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=I1zW6Dy5wNA8Np6K2i17QPlRa6UBblVzNgPB5OGuKKE%3D&reserved=0 > > > > -- > Rodney Bates > rodney.m.bates at acm.org > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fm3lists.elegosoft.com%2Fmailman%2Flistinfo%2Fm3devel&data=04%7C01%7C%7C1e32400e20b747c9a69108d8d6e2c0c0%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637495616693997646%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=I1zW6Dy5wNA8Np6K2i17QPlRa6UBblVzNgPB5OGuKKE%3D&reserved=0 _______________________________________________ M3devel mailing list M3devel at elegosoft.com https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fm3lists.elegosoft.com%2Fmailman%2Flistinfo%2Fm3devel&data=04%7C01%7C%7C1e32400e20b747c9a69108d8d6e2c0c0%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637495616693997646%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=I1zW6Dy5wNA8Np6K2i17QPlRa6UBblVzNgPB5OGuKKE%3D&reserved=0 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Feb 22 05:51:40 2021 From: jayk123 at hotmail.com (Jay K) Date: Mon, 22 Feb 2021 04:51:40 +0000 Subject: [M3devel] new release for AMD64_NT In-Reply-To: References: , Message-ID: Depends on the starting point? ? There is an .msi. Which is just a bunch of files and sets path (the msi gui reports doing a bunch of other high level things to machine, like "registering components" bogus). There is a .zip. Extract it and set path to the directory holding cm3.exe. You need Visual C++, some version. Run its start menu shortcut and then put cm3.exe in path? Try it out? Write it better than me please? To cross build, there is boot1.py, copy it, and then boot2.cmd. Except I did cheat and edited the boot Makefile. it was for NT386 integrated backend. I need to fix that. - Jay ________________________________ From: Mika Nystrom Sent: Monday, February 22, 2021 4:47 AM To: Jay K Cc: m3devel Subject: Re: [M3devel] new release for AMD64_NT Jay do you have a how-to guide somewhere on how to get this installed on a recent Windows machine? Mika On Sun, Feb 21, 2021 at 7:29 PM Jay K > wrote: I made a new release, for AMD64_NT. Release AMD64_NT-d5.10.0-VC2019-20210221 ? modula3/cm3 (github.com) Anyone want to try it and report? I guess I should make I386_NT also? People want that and will try it? Not much has changed, except AMD64_NT should, ahem, work. This uses the C backend (of course ? ) Thank you, - Jay _______________________________________________ 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 Mon Feb 22 10:01:17 2021 From: jayk123 at hotmail.com (Jay K) Date: Mon, 22 Feb 2021 09:01:17 +0000 Subject: [M3devel] "C backend passthrough"? Message-ID: I'm wondering if a C backend could/should do things like: current: INTERFACE WinBase; <*EXTERNAL CreateFileA:WINAPI*> PROCEDURE CreateFileA (lpFileName : PCSTR; dwDesiredAccess : UINT32; dwShareMode : UINT32; lpSecurityAttributes : PSECURITY_ATTRIBUTES; dwCreationDisposition: UINT32; dwFlagsAndAttributes : UINT32; hTemplateFile : HANDLE ): HANDLE; proposed: INTERFACE WinBase; <*EXTERNAL windows.h:CreateFileA:WINAPI*> PROCEDURE CreateFileA (lpFileName : PCSTR; dwDesiredAccess : UINT32; dwShareMode : UINT32; lpSecurityAttributes : PSECURITY_ATTRIBUTES; dwCreationDisposition: UINT32; dwFlagsAndAttributes : UINT32; hTemplateFile : HANDLE ): HANDLE; this would tell the C backend: - #include - Do not declare CreateFileA. Placing some extra requirements on the declarations to match, a good thing? And similarly, current: STD_OUTPUT_HANDLE: INT32 = -11; proposed: <* EXTERNAL windows.h *> STD_OUTPUT_HANDLE: INT32 = -11; - Again, #include windows.h - More difficult, output "STD_OUTPUT_HANDLE" instead of "-11". This is maybe more problematic. Imagine the Modula-3 backend says something like FormatInt(STD_OUTPUT_HANDLE + 1). You'd have to be sure constant propagation does not occur on the frontend. I'm not sure if it does. But integer constants passed to backend would have to come along with a string, and each backend would chose which it uses. Maybe there is nothing realistic to do here. It just bugs me that *.i3 files duplicate *.h I know it is a recurring problem in many systems and people just muddle along. Occasionally people try to solve it (quite recently the Windows SDK is in a form amenable to multiple languages; internally long ago DEC and Apple authored in internal languages and generated C/Pascall/assembly headers, but I don't think shipped them). - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmuysers at hotmail.com Mon Feb 22 12:29:31 2021 From: dmuysers at hotmail.com (Dirk Muysers) Date: Mon, 22 Feb 2021 12:29:31 +0100 Subject: [M3devel] Modula-3 subranges vs. opaque arbitrary 32bit constants? In-Reply-To: <20210222033402.4xwebtssvlnpuuzx@topoi.pooq.com> References: <0ea053e7-ecc8-88ab-0355-c1119a71e21f@lcwb.coop> <20210222033402.4xwebtssvlnpuuzx@topoi.pooq.com> Message-ID: >> I?would be sorry if that were to die. (32-bit Linux) Same remark for the (a bit neglected) NT386 version! On 22/02/2021 04:34:29, Hendrik Boom wrote: On Mon, Feb 22, 2021 at 03:23:44AM +0000, Jay K wrote: > Thank you. Right, switching this to UINT32, and others to INT32 worked out: > Win64: Fix some unsigned/signed problems around ? modula3/cm3 at aabd114 (github.com) > > These numbers are all opaque though. > I just need to pass them around via assignment. > I don't even need equality comparisons. > It'd be nice if that was easier. > Ok, er, I also need to form constants to them, but I could move that to C, am inclined to really, later. > > I can now build the AMD64_NT system and for example BadBricks works. > Probably "everything" works, as well as NT386 ever did. > > After this I will move on to ARM64_LINUX, ARM64_DARWIN, ARM64_NT. > Which should be pretty trivial. > I'd like to do ARM32_{LINUX, DARWIN, NT} releases also, but the Apple M1 cannot run those..maybe under qemu at least ARM32_LINUX. > But there are already releases of that, and not clear if anyone cares. > > And if I get time, maybe after this, some pure C releases, i.e. the dream of the only targets being: > {32,64} x {NT,Unix} x {LittleEndian,BigEndian}. > > And BigEndian is hard to find (Sparc, some Alpha, some PowerPC, > HPPA, some Mips), and 32bit can maybe omit entirely these days? The machine I run Modula 3 on is a Linux 32-bit intel machine. I would be sorry if that were to die. I would like to see the C release, though, just for long-term portability. -- hendrik > > And then...what should the distribution format be -- generate cmake? generate autotools? generate custom makefile? > Later.. > > - Jay > > ________________________________ > From: Rodney M. Bates > Sent: Monday, February 22, 2021 2:54 AM > To: Jay K ; m3devel > Subject: Re: [M3devel] Modula-3 subranges vs. opaque arbitrary 32bit constants? > > I can explain what is happening and probably what needs to be done. See below --- > > On 2/21/21 4:08 PM, Jay K wrote: > > Maybe it is a bug in the Modula-3 Windows headers cloning, or in the C backend. > > I'm not sure. > > Please help me to understand? > > > > The AMD64_NT port works well enough, again, that it can build the runtime and compiler, and the compiler > > can build everything. > > > > But networking fails, here: > > > > 0:000> k > > # Child-SP RetAddr Call Site > > 00 (Inline Function) --------`-------- KERNELBASE!DebugBreak [minkernel\kernelbase\debug.c @ 143] > > 01 00000053`b8cff188 00007fff`b8a35e93 KERNELBASE!wil::details::DebugBreak+0x2 [onecore\internal\sdk\inc\wil\opensource\wil\result_macros.h @ 1737] > > 02 00000053`b8cff190 00007fff`b8a2682f m3core!RTOS__Crash+0x43 [C:\s\cm3\m3-libs\m3core\src\runtime\WIN32\RTOS.m3 @ 26] > > 03 00000053`b8cff1e0 00007fff`b8a23bef m3core!RTProcess__Crash+0x6f [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTProcess.m3 @ 66] > > 04 00000053`b8cff220 00007fff`b8a23820 m3core!RTError__EndError+0x3f [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTError.m3 @ 119] > > 05 00000053`b8cff260 00007fff`b8a24257 m3core!RTError__MsgS+0xa0 [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTError.m3 @ 41] > > 06 00000053`b8cff2a0 00007fff`b8a23e5e m3core!RTException__Crash+0x317 [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 81] > > 07 00000053`b8cff330 00007fff`b8a23d4b m3core!RTException__DefaultBackstop+0xce [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 39] > > 08 00000053`b8cff3a0 00007fff`b8a37d7a m3core!RTException__InvokeBackstop+0x3b [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 25] > > 09 00000053`b8cff3e0 00007fff`b8a23f2a m3core!RTException__Raise+0x9a [C:\s\cm3\m3-libs\m3core\src\runtime\ex_frame\RTExFrame.m3 @ 90] > > 0a 00000053`b8cff440 00007fff`b8a23d4b m3core!RTException__DefaultBackstop+0x19a [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 49] > > 0b 00000053`b8cff4b0 00007fff`b8a37d7a m3core!RTException__InvokeBackstop+0x3b [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 25] > > 0c 00000053`b8cff4f0 00007fff`b8a06cce m3core!RTException__Raise+0x9a [C:\s\cm3\m3-libs\m3core\src\runtime\ex_frame\RTExFrame.m3 @ 90] > > 0d 00000053`b8cff550 00007ff8`2d57626a m3core!RTHooks__ReportFault+0xfe [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTHooks.m3 @ 112] > > *0e 00000053`b8cff5f0 00007ff8`2d5747f2 m3tcp!M_TCP_L_100_CRASH+0x1a [C:\s\cm3\m3-comm\tcp\AMD64_NT\TCP.m3.c @ 2759] * > > *0f 00000053`b8cff620 00007ff8`2d57371c m3tcp!TCP__InitSock+0xc2 [C:\s\cm3\m3-comm\tcp\src\WIN32\TCP.m3 @ 310] * > > 10 00000053`b8cff680 00007fff`fe8302b3 m3tcp!TCP__NewConnector+0xdc [C:\s\cm3\m3-comm\tcp\src\WIN32\TCP.m3 @ 72] > > 11 00000053`b8cff720 00007fff`fe82d814 sharedobj!LocalObjectSpace__SpaceInit+0x283 [C:\s\cm3\m3-comm\sharedobj\src\LocalObjectSpace.m3 @ 391] > > 12 00000053`b8cff930 00007fff`b8a21e17 sharedobj!LocalObjectSpace_M3+0x94 [C:\s\cm3\m3-comm\sharedobj\src\LocalObjectSpace.m3 @ 805] > > 13 00000053`b8cff990 00007fff`b8a21c9a m3core!RTLinker__RunMainBody+0x3e7 [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTLinker.m3 @ 408] > > 14 00000053`b8cffa30 00007fff`b8a21c9a m3core!RTLinker__RunMainBody+0x26a [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTLinker.m3 @ 389] > > 15 00000053`b8cffad0 00007fff`b8a21c9a m3core!RTLinker__RunMainBody+0x26a [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTLinker.m3 @ 389] > > 16 00000053`b8cffb70 00007fff`b8a21c9a m3core!RTLinker__RunMainBody+0x26a [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTLinker.m3 @ 389] > > 17 00000053`b8cffc10 00007fff`b8a2209b m3core!RTLinker__RunMainBody+0x26a [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTLinker.m3 @ 389] > > 18 00000053`b8cffcb0 00007fff`b8a21818 m3core!RTLinker__AddUnitI+0x11b [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTLinker.m3 @ 116] > > 19 00000053`b8cffcf0 00007ff6`f5b31038 m3core!RTLinker__AddUnit+0x118 [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTLinker.m3 @ 125] > > 1a 00000053`b8cffd50 00007ff6`f5db4d38 mentor!main+0x38 [C:\s\cm3\m3-demo\mentor\AMD64_NT\_m3main.c @ 23] > > 1b (Inline Function) --------`-------- mentor!invoke_main+0x22 [d:\agent\_work\5\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl @ 78] > > 1c 00000053`b8cffd80 00007ff8`49a67034 mentor!__scrt_common_main_seh+0x10c [d:\agent\_work\5\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl @ 288] > > 1d 00000053`b8cffdc0 00007ff8`4a8fd241 KERNEL32!BaseThreadInitThunk+0x14 [clientcore\base\win32\client\thread.c @ 64] > > 1e 00000053`b8cffdf0 00000000`00000000 ntdll!RtlUserThreadStart+0x21 [minkernel\ntdll\rtlstrt.c @ 1153] > > > > *** > > *** runtime error: > > *** An enumeration or subrange value was out of range. > > *** file "..\src\WIN32\TCP.m3", line 310 > > *** > > > > it is "simple" subrange problem. > > > > > > IF WinSock.ioctlsocket(sock, *WinSock.FIONBIO*, ADR(one)) = SockErr THEN > > IPError.Die(); > > END; > > > > > > It is *not* calling that IPError.Die(). > > > > ioctlsocket is declared as: > > > > PROCEDURE ioctlsocket (s: SOCKET; cmd: INT32; argp: UNTRACED REF UINT32): INT32; > > > > INT32 = Cstdint.int32_t; > > > > int32_t = Cstdint.int32_t; > > int32_t = Ctypes.int; > > int = [-16_7fffffff-1 .. 16_7fffffff]; > > On 32 bits, -16_7fffffff-1 comes out 16_80000000, which is FIRST((*32-bit*)INTEGER). > on 64, it comes out 16_ffffffff80000000, a negative number. > > and ... > > > > > It is range checking ioctlsocket parameter WinSock.FIONBIO against that and rejecting it. > > > > The code is: > > > > 307 00007ff8`2d5747ca e847620000 call m3tcp!setsockopt (00007ff8`2d57aa16) previous line > > 307 00007ff8`2d5747cf 89442430 mov dword ptr [rsp+30h],eax > > * 310 00007ff8`2d5747d3 b87e660880 mov eax,8008667Eh > > On 32 bits, 8008667Eh is a negative number, but not as negative as FIRST(INT32), > thus in the range, and would not have failed. > > On 64 bits, when zero extended, its a positive number > LAST (INT32), thus the range failure. > To get it similarly in range, it would have to be sign extended to 16_ffffffff8008667e. > > Looking at WinSock.i3, these commands are all coded as positive numbers, thus the zero-extend > is correct for the language and compiler. > > They certainly look like they should indeed be positive. If so, the formal cmd of > ioctlsocket should be UINT32, which, after following renames on a very merry chase > around Robin Hood's barn, is [16_0..16_ffffffff]. > > On a 32-bit machine, UINT32 should really be Word.T, which is the same as > INTEGER, but hints to a human reader that the integer is going to be treated > as full-range unsigned, in the operators applied to it. This is the way > it is declared in C/32BITS/BasicCTypes.i3. > > For Windows, there are not separate versions of BasicCTypes.i3 for the two word sizes. > The declaration in C/WIN64/BasicCTypes.i3 would not compile on a 32-bit host. > > I would guess that "from the BSD file fcntl.h" probably indicates they are all > intended to be positive. I'd bet there are more places in WinSock that also > need to be UINT32. > > > WinSock.FIONBIO* > > 310 00007ff8`2d5747d8 4889442440 mov qword ptr [rsp+40h],rax > > 310 00007ff8`2d5747dd 48817c2440ffffff7f cmp qword ptr [rsp+40h],7FFFFFFFh > > 310 00007ff8`2d5747e6 7e0a jle m3tcp!TCP__InitSock+0xc2 (00007ff8`2d5747f2) Branch > > > > m3tcp!TCP__InitSock+0xb8 [C:\s\cm3\m3-comm\tcp\src\WIN32\TCP.m3 @ 310]: > > 310 00007ff8`2d5747e8 b9c1260000 mov ecx,26C1h > > 310 00007ff8`2d5747ed e85e1a0000 call m3tcp!M_TCP_L_100_CRASH (00007ff8`2d576250) > > > > dv /V > > > > 00000053`b8cff660 @rsp+0x0040 L_345_L_346 = 0n2148034174 > > > > mov eax, constant > > > > is zero extending > > > > and to confirm: > > > > > > C:\s>type fio.c > > #include > > #include > > > > int main() > > { > > printf("%d %x\n", FIONBIO, FIONBIO); > > return 0; > > } > > > > C:\s>cl fio.c > > Microsoft (R) C/C++ Optimizing Compiler Version 19.24.28316 for x64 > > Copyright (C) Microsoft Corporation. All rights reserved. > > > > fio.c > > Microsoft (R) Incremental Linker Version 14.24.28316.0 > > Copyright (C) Microsoft Corporation. All rights reserved. > > > > /out:fio.exe > > fio.obj > > > > C:\s>fio.exe > > -2147195266 8004667e > > > > > > What is the right way to do this? > > > > Just change to UINT32? > > Even it works, can you explain it to me? > > I agree integers should not silently overflow, subranges are good, > > but this doesn't seem to me like it should be so difficult. > > > > I am inclined to further drain the Modula-3 "headers" > > and make it an "extern constant variable", really, > > though I'm not sure that will help, though it serves > > another purpose -- I like to minimally duplicate C headers. > > That is one way Posix ports became much easier. > > > > Thank you, > > - Jay > > > > _______________________________________________ > > M3devel mailing list > > M3devel at elegosoft.com > > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fm3lists.elegosoft.com%2Fmailman%2Flistinfo%2Fm3devel&data=04%7C01%7C%7C8fd1a7a5057a4abf429708d8d6dd3537%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637495592871746870%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=px64IdlrA%2BpfFXi8JCkCJx3jmGIJ%2BVhzZ1dSCOWhB6c%3D&reserved=0 > > > > -- > 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 Mon Feb 22 12:50:19 2021 From: jayk123 at hotmail.com (Jay K) Date: Mon, 22 Feb 2021 11:50:19 +0000 Subject: [M3devel] Modula-3 subranges vs. opaque arbitrary 32bit constants? In-Reply-To: References: <0ea053e7-ecc8-88ab-0355-c1119a71e21f@lcwb.coop> <20210222033402.4xwebtssvlnpuuzx@topoi.pooq.com>, Message-ID: Can we switch both to C backend? I mean, yes and no, on deleting m3cc/m3gdb..'cause repo size.. I386 users, Darwin, Linux, NT, please try amd64? Do you still use non-amd64 hardware? It's been out for over 15 years. And x86 emulation on Windows is somewhat not convincing really, like when Modula3 suspends threads and gets their context..they could actually be in amd64 code. Nobody is going to remove 32bit support, surely. Anyway, my more immediate concerns are these: ARM64_NT ARM64_LINUX ARM64_DARWIN (Apple? Mac?) RISCV64_LINUX and maybe ARM32_NT. all of which I expect will be totally trivial, using the C backend. Also while I don't want to drop XP/2003 support, we might want to "rewrite for" and "adapt to at runtime via GetVersion" Vista and newer. Which would then leave the old code not run/tested, granted. ARM64 could assume Vista or newer. ? If anyone precisely compare and constrast: Posix condition variables vs. NT condition convariables vs. Modula3 requirements. - Jay ________________________________ From: M3devel on behalf of Dirk Muysers Sent: Monday, February 22, 2021 11:29 AM To: Boom Hendrik ; m3devel at elegosoft.com Subject: Re: [M3devel] Modula-3 subranges vs. opaque arbitrary 32bit constants? >> I would be sorry if that were to die. (32-bit Linux) Same remark for the (a bit neglected) NT386 version! On 22/02/2021 04:34:29, Hendrik Boom wrote: On Mon, Feb 22, 2021 at 03:23:44AM +0000, Jay K wrote: > Thank you. Right, switching this to UINT32, and others to INT32 worked out: > Win64: Fix some unsigned/signed problems around ? modula3/cm3 at aabd114 (github.com) > > These numbers are all opaque though. > I just need to pass them around via assignment. > I don't even need equality comparisons. > It'd be nice if that was easier. > Ok, er, I also need to form constants to them, but I could move that to C, am inclined to really, later. > > I can now build the AMD64_NT system and for example BadBricks works. > Probably "everything" works, as well as NT386 ever did. > > After this I will move on to ARM64_LINUX, ARM64_DARWIN, ARM64_NT. > Which should be pretty trivial. > I'd like to do ARM32_{LINUX, DARWIN, NT} releases also, but the Apple M1 cannot run those..maybe under qemu at least ARM32_LINUX. > But there are already releases of that, and not clear if anyone cares. > > And if I get time, maybe after this, some pure C releases, i.e. the dream of the only targets being: > {32,64} x {NT,Unix} x {LittleEndian,BigEndian}. > > And BigEndian is hard to find (Sparc, some Alpha, some PowerPC, > HPPA, some Mips), and 32bit can maybe omit entirely these days? The machine I run Modula 3 on is a Linux 32-bit intel machine. I would be sorry if that were to die. I would like to see the C release, though, just for long-term portability. -- hendrik > > And then...what should the distribution format be -- generate cmake? generate autotools? generate custom makefile? > Later.. > > - Jay > > ________________________________ > From: Rodney M. Bates > Sent: Monday, February 22, 2021 2:54 AM > To: Jay K ; m3devel > Subject: Re: [M3devel] Modula-3 subranges vs. opaque arbitrary 32bit constants? > > I can explain what is happening and probably what needs to be done. See below --- > > On 2/21/21 4:08 PM, Jay K wrote: > > Maybe it is a bug in the Modula-3 Windows headers cloning, or in the C backend. > > I'm not sure. > > Please help me to understand? > > > > The AMD64_NT port works well enough, again, that it can build the runtime and compiler, and the compiler > > can build everything. > > > > But networking fails, here: > > > > 0:000> k > > # Child-SP RetAddr Call Site > > 00 (Inline Function) --------`-------- KERNELBASE!DebugBreak [minkernel\kernelbase\debug.c @ 143] > > 01 00000053`b8cff188 00007fff`b8a35e93 KERNELBASE!wil::details::DebugBreak+0x2 [onecore\internal\sdk\inc\wil\opensource\wil\result_macros.h @ 1737] > > 02 00000053`b8cff190 00007fff`b8a2682f m3core!RTOS__Crash+0x43 [C:\s\cm3\m3-libs\m3core\src\runtime\WIN32\RTOS.m3 @ 26] > > 03 00000053`b8cff1e0 00007fff`b8a23bef m3core!RTProcess__Crash+0x6f [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTProcess.m3 @ 66] > > 04 00000053`b8cff220 00007fff`b8a23820 m3core!RTError__EndError+0x3f [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTError.m3 @ 119] > > 05 00000053`b8cff260 00007fff`b8a24257 m3core!RTError__MsgS+0xa0 [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTError.m3 @ 41] > > 06 00000053`b8cff2a0 00007fff`b8a23e5e m3core!RTException__Crash+0x317 [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 81] > > 07 00000053`b8cff330 00007fff`b8a23d4b m3core!RTException__DefaultBackstop+0xce [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 39] > > 08 00000053`b8cff3a0 00007fff`b8a37d7a m3core!RTException__InvokeBackstop+0x3b [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 25] > > 09 00000053`b8cff3e0 00007fff`b8a23f2a m3core!RTException__Raise+0x9a [C:\s\cm3\m3-libs\m3core\src\runtime\ex_frame\RTExFrame.m3 @ 90] > > 0a 00000053`b8cff440 00007fff`b8a23d4b m3core!RTException__DefaultBackstop+0x19a [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 49] > > 0b 00000053`b8cff4b0 00007fff`b8a37d7a m3core!RTException__InvokeBackstop+0x3b [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 25] > > 0c 00000053`b8cff4f0 00007fff`b8a06cce m3core!RTException__Raise+0x9a [C:\s\cm3\m3-libs\m3core\src\runtime\ex_frame\RTExFrame.m3 @ 90] > > 0d 00000053`b8cff550 00007ff8`2d57626a m3core!RTHooks__ReportFault+0xfe [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTHooks.m3 @ 112] > > *0e 00000053`b8cff5f0 00007ff8`2d5747f2 m3tcp!M_TCP_L_100_CRASH+0x1a [C:\s\cm3\m3-comm\tcp\AMD64_NT\TCP.m3.c @ 2759] * > > *0f 00000053`b8cff620 00007ff8`2d57371c m3tcp!TCP__InitSock+0xc2 [C:\s\cm3\m3-comm\tcp\src\WIN32\TCP.m3 @ 310] * > > 10 00000053`b8cff680 00007fff`fe8302b3 m3tcp!TCP__NewConnector+0xdc [C:\s\cm3\m3-comm\tcp\src\WIN32\TCP.m3 @ 72] > > 11 00000053`b8cff720 00007fff`fe82d814 sharedobj!LocalObjectSpace__SpaceInit+0x283 [C:\s\cm3\m3-comm\sharedobj\src\LocalObjectSpace.m3 @ 391] > > 12 00000053`b8cff930 00007fff`b8a21e17 sharedobj!LocalObjectSpace_M3+0x94 [C:\s\cm3\m3-comm\sharedobj\src\LocalObjectSpace.m3 @ 805] > > 13 00000053`b8cff990 00007fff`b8a21c9a m3core!RTLinker__RunMainBody+0x3e7 [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTLinker.m3 @ 408] > > 14 00000053`b8cffa30 00007fff`b8a21c9a m3core!RTLinker__RunMainBody+0x26a [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTLinker.m3 @ 389] > > 15 00000053`b8cffad0 00007fff`b8a21c9a m3core!RTLinker__RunMainBody+0x26a [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTLinker.m3 @ 389] > > 16 00000053`b8cffb70 00007fff`b8a21c9a m3core!RTLinker__RunMainBody+0x26a [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTLinker.m3 @ 389] > > 17 00000053`b8cffc10 00007fff`b8a2209b m3core!RTLinker__RunMainBody+0x26a [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTLinker.m3 @ 389] > > 18 00000053`b8cffcb0 00007fff`b8a21818 m3core!RTLinker__AddUnitI+0x11b [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTLinker.m3 @ 116] > > 19 00000053`b8cffcf0 00007ff6`f5b31038 m3core!RTLinker__AddUnit+0x118 [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTLinker.m3 @ 125] > > 1a 00000053`b8cffd50 00007ff6`f5db4d38 mentor!main+0x38 [C:\s\cm3\m3-demo\mentor\AMD64_NT\_m3main.c @ 23] > > 1b (Inline Function) --------`-------- mentor!invoke_main+0x22 [d:\agent\_work\5\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl @ 78] > > 1c 00000053`b8cffd80 00007ff8`49a67034 mentor!__scrt_common_main_seh+0x10c [d:\agent\_work\5\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl @ 288] > > 1d 00000053`b8cffdc0 00007ff8`4a8fd241 KERNEL32!BaseThreadInitThunk+0x14 [clientcore\base\win32\client\thread.c @ 64] > > 1e 00000053`b8cffdf0 00000000`00000000 ntdll!RtlUserThreadStart+0x21 [minkernel\ntdll\rtlstrt.c @ 1153] > > > > *** > > *** runtime error: > > *** An enumeration or subrange value was out of range. > > *** file "..\src\WIN32\TCP.m3", line 310 > > *** > > > > it is "simple" subrange problem. > > > > > > IF WinSock.ioctlsocket(sock, *WinSock.FIONBIO*, ADR(one)) = SockErr THEN > > IPError.Die(); > > END; > > > > > > It is *not* calling that IPError.Die(). > > > > ioctlsocket is declared as: > > > > PROCEDURE ioctlsocket (s: SOCKET; cmd: INT32; argp: UNTRACED REF UINT32): INT32; > > > > INT32 = Cstdint.int32_t; > > > > int32_t = Cstdint.int32_t; > > int32_t = Ctypes.int; > > int = [-16_7fffffff-1 .. 16_7fffffff]; > > On 32 bits, -16_7fffffff-1 comes out 16_80000000, which is FIRST((*32-bit*)INTEGER). > on 64, it comes out 16_ffffffff80000000, a negative number. > > and ... > > > > > It is range checking ioctlsocket parameter WinSock.FIONBIO against that and rejecting it. > > > > The code is: > > > > 307 00007ff8`2d5747ca e847620000 call m3tcp!setsockopt (00007ff8`2d57aa16) previous line > > 307 00007ff8`2d5747cf 89442430 mov dword ptr [rsp+30h],eax > > * 310 00007ff8`2d5747d3 b87e660880 mov eax,8008667Eh > > On 32 bits, 8008667Eh is a negative number, but not as negative as FIRST(INT32), > thus in the range, and would not have failed. > > On 64 bits, when zero extended, its a positive number > LAST (INT32), thus the range failure. > To get it similarly in range, it would have to be sign extended to 16_ffffffff8008667e. > > Looking at WinSock.i3, these commands are all coded as positive numbers, thus the zero-extend > is correct for the language and compiler. > > They certainly look like they should indeed be positive. If so, the formal cmd of > ioctlsocket should be UINT32, which, after following renames on a very merry chase > around Robin Hood's barn, is [16_0..16_ffffffff]. > > On a 32-bit machine, UINT32 should really be Word.T, which is the same as > INTEGER, but hints to a human reader that the integer is going to be treated > as full-range unsigned, in the operators applied to it. This is the way > it is declared in C/32BITS/BasicCTypes.i3. > > For Windows, there are not separate versions of BasicCTypes.i3 for the two word sizes. > The declaration in C/WIN64/BasicCTypes.i3 would not compile on a 32-bit host. > > I would guess that "from the BSD file fcntl.h" probably indicates they are all > intended to be positive. I'd bet there are more places in WinSock that also > need to be UINT32. > > > WinSock.FIONBIO* > > 310 00007ff8`2d5747d8 4889442440 mov qword ptr [rsp+40h],rax > > 310 00007ff8`2d5747dd 48817c2440ffffff7f cmp qword ptr [rsp+40h],7FFFFFFFh > > 310 00007ff8`2d5747e6 7e0a jle m3tcp!TCP__InitSock+0xc2 (00007ff8`2d5747f2) Branch > > > > m3tcp!TCP__InitSock+0xb8 [C:\s\cm3\m3-comm\tcp\src\WIN32\TCP.m3 @ 310]: > > 310 00007ff8`2d5747e8 b9c1260000 mov ecx,26C1h > > 310 00007ff8`2d5747ed e85e1a0000 call m3tcp!M_TCP_L_100_CRASH (00007ff8`2d576250) > > > > dv /V > > > > 00000053`b8cff660 @rsp+0x0040 L_345_L_346 = 0n2148034174 > > > > mov eax, constant > > > > is zero extending > > > > and to confirm: > > > > > > C:\s>type fio.c > > #include > > #include > > > > int main() > > { > > printf("%d %x\n", FIONBIO, FIONBIO); > > return 0; > > } > > > > C:\s>cl fio.c > > Microsoft (R) C/C++ Optimizing Compiler Version 19.24.28316 for x64 > > Copyright (C) Microsoft Corporation. All rights reserved. > > > > fio.c > > Microsoft (R) Incremental Linker Version 14.24.28316.0 > > Copyright (C) Microsoft Corporation. All rights reserved. > > > > /out:fio.exe > > fio.obj > > > > C:\s>fio.exe > > -2147195266 8004667e > > > > > > What is the right way to do this? > > > > Just change to UINT32? > > Even it works, can you explain it to me? > > I agree integers should not silently overflow, subranges are good, > > but this doesn't seem to me like it should be so difficult. > > > > I am inclined to further drain the Modula-3 "headers" > > and make it an "extern constant variable", really, > > though I'm not sure that will help, though it serves > > another purpose -- I like to minimally duplicate C headers. > > That is one way Posix ports became much easier. > > > > Thank you, > > - Jay > > > > _______________________________________________ > > M3devel mailing list > > M3devel at elegosoft.com > > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fm3lists.elegosoft.com%2Fmailman%2Flistinfo%2Fm3devel&data=04%7C01%7C%7C8fd1a7a5057a4abf429708d8d6dd3537%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637495592871746870%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=px64IdlrA%2BpfFXi8JCkCJx3jmGIJ%2BVhzZ1dSCOWhB6c%3D&reserved=0 > > > > -- > 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 vvm at tut.by Mon Feb 22 13:48:15 2021 From: vvm at tut.by (vvm at tut.by) Date: Mon, 22 Feb 2021 15:48:15 +0300 Subject: [M3devel] Modula-3 subranges vs. opaque arbitrary 32bit constants? In-Reply-To: References: Message-ID: <1523101613997774@mail.yandex.by> An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Mon Feb 22 18:00:34 2021 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Mon, 22 Feb 2021 11:00:34 -0600 Subject: [M3devel] Modula-3 subranges vs. opaque arbitrary 32bit constants? In-Reply-To: References: Message-ID: On 2/21/21 5:19 PM, Jay K wrote: > Seriously, how do I form arbitrary 32bit constants? ? > Several years ago, I sent a post about different ways different languages provide arithmetic on both full-range signed full-range unsigned integers. I'll see if I can find it and repost. That will be easier than trying to reconstruct it. But for now, here some thoughts about how to construct constants and subranges for full-range unsigned values. There were three desirable properties, only two of which a programming language can provide. Modula3 chooses a different two than any language I am familiar with. I like the choice, but it too has its limitations. Other languages have different types (signed, unsigned) but use the same overloaded operators with two possible meanings, chosen by the type they are applied to. Modula-3 does it the opposite way, i.e., one type (INTEGER) with different operators that apply either a signed or unsigned interpretation to the bits of their operands. The operator-notation ones (e.g. "+", "*") are signed and the pseudo-functions in Word are unsigned. I am always careful to declare things either INTEGER or Word.T, depending on which interpretation of their bits I intend. These types are the same, as far as the language itself is concerned, but it is effectively a good comment, and helps me greatly in keeping track of what arithmetic I am doing. It's difficult no matter how the language handles it. But there is no subrange type construct that applies unsigned interpretation to the bounds of the range. So you have to give the bounds using the signed interpretation, even if you will use the values as unsigned. One thing that is confusing is that you can define a subrange with zero lower bound and think of it as an unsigned subrange, but only if the upper bound is <= LAST(INTEGER). If you want full-range unsigned, you have to use the equivalent signed bounds. One additional relevant rule, from 2.6.4, on integer literals: "If no explicit base is present, the value of the literal must be at most LAST(INTEGER). If an explicit base is present, the value of the literal must be less than 2^Word.Size, and its interpretation uses the convention of the Word interface. For example, on a 32-bit two's complement machine, 16_FFFFFFFF and -1 represent the same value." And I add that -1 is not a literal. 1 is the literal and the - is a signed operator. So these declarations from WinSock.i3 provide some examples for declaring constants: CONST IOCPARM_MASK = 16_7f; (* parameters must be < 128 bytes *) IOC_OUT = 16_40000000; (* copy out parameters *) IOC_IN = 16_80000000; (* copy in parameters *) (* 16_20000000 distinguishes new & old ioctl's *) FC = Shift (ORD ('f'), 8); INT = Shift (And (BYTESIZE (INTEGER), IOCPARM_MASK), 16); R = IOC_OUT; W = IOC_IN; (* file i/o controls *) FIONBIO = Or (Or (W, INT), Or (FC, 126)); (* Set/clear non-bl.i/o *) All the 16_ literals use the covention of Word, i.e. are unsigned values. The decimal ones with no base are low values within the signed range, so either intepretation is the same. The operations Or, Shift, etc are from Word and unsigned. Everything is defined using unsigned values and unsigned operations. They also all happen to be within the overlap of signed and unsigned ranges. That is why the compiler expanded them to 64 bit using zero-extend instead of sign-extend. The type INT32, on 64-bit, applying signed interpretation, excludes the value of FIONBIO. So UINT32 is the proper type. But what I said yesterday about [0..16_ffffffff] on 32-bits not compiling is wrong. 16_ffffffff is legal, unsigned. However, it's still incorrect because the upper bound means -1 on 32-bit, and the subrange is empty. Legal, but not of much use. So, I would fix the original problem by: 1. Make the type of all variables using these values UINT32. 2. Make UINT32 be Word.T on all 32-bit machines, Windows or not. 3. Keep the declarations of the constants as before, using the unsigned arithmetic, since they show how the value is derived. Note that evaluating to a negative decimal number is not a member of UINT32 on a 64-bit machine. Yes, it's all confusing. The mix of full-range signed and unsigned values/arithmmetic and different native work sizes requires careful attention to detail no matter how the language handles it, but it's really necessary. -- Rodney Bates rodney.m.bates at acm.org From jayk123 at hotmail.com Mon Feb 22 18:36:52 2021 From: jayk123 at hotmail.com (Jay K) Date: Mon, 22 Feb 2021 17:36:52 +0000 Subject: [M3devel] Modula-3 subranges vs. opaque arbitrary 32bit constants? In-Reply-To: <1523101613997774@mail.yandex.by> References: , <1523101613997774@mail.yandex.by> Message-ID: Well. I did not apply your patches. I encountered the errors, and then I fixed them. In some cases possibly the same as you. Please look at the history in master. It isn't much to read. - Jay ________________________________ From: vvm at tut.by Sent: Monday, February 22, 2021 12:48 PM To: Jay K ; m3devel Subject: Re: [M3devel] Modula-3 subranges vs. opaque arbitrary 32bit constants? Hi! > m3tcp!TCP__InitSock+0xb8 [C:\s\cm3\m3-comm\tcp\src\WIN32\TCP.m3 @ 310]: Error's happened even with this patch? https://github.com/modula3/cm3/issues/47#issuecomment-501227088 ( Related patch: --- WinSock.i3 000 Sun Jun 02 21:24:39 2019 +++ WinSock.i3 Wed Jun 12 11:11:53 2019 @@ -80,7 +80,7 @@ (* file i/o controls *) FIONREAD = Or (Or (R, INT), Or (FC, 127)); (* Get # bytes to read *) - FIONBIO = Or (Or (W, INT), Or (FC, 126)); (* Set/clear non-bl.i/o *) + FIONBIO = -2147195266; (* Set/clear non-bl.i/o *) (* Ok only to 32 bit OS FIONBIO = Or (Or (W, INT), Or (FC, 126)); *) FIOASYNC = Or (Or (W, INT), Or (FC, 125)); (* Set/clear async i/o *) (* Socket i/o controls *) ) Best regards, Victor Miasnikov 22.02.2021, 01:09, "Jay K" : Maybe it is a bug in the Modula-3 Windows headers cloning, or in the C backend. I'm not sure. Please help me to understand? The AMD64_NT port works well enough, again, that it can build the runtime and compiler, and the compiler can build everything. But networking fails, here: 0:000> k # Child-SP RetAddr Call Site 00 (Inline Function) --------`-------- KERNELBASE!DebugBreak [minkernel\kernelbase\debug.c @ 143] 01 00000053`b8cff188 00007fff`b8a35e93 KERNELBASE!wil::details::DebugBreak+0x2 [onecore\internal\sdk\inc\wil\opensource\wil\result_macros.h @ 1737] 02 00000053`b8cff190 00007fff`b8a2682f m3core!RTOS__Crash+0x43 [C:\s\cm3\m3-libs\m3core\src\runtime\WIN32\RTOS.m3 @ 26] 03 00000053`b8cff1e0 00007fff`b8a23bef m3core!RTProcess__Crash+0x6f [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTProcess.m3 @ 66] 04 00000053`b8cff220 00007fff`b8a23820 m3core!RTError__EndError+0x3f [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTError.m3 @ 119] 05 00000053`b8cff260 00007fff`b8a24257 m3core!RTError__MsgS+0xa0 [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTError.m3 @ 41] 06 00000053`b8cff2a0 00007fff`b8a23e5e m3core!RTException__Crash+0x317 [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 81] 07 00000053`b8cff330 00007fff`b8a23d4b m3core!RTException__DefaultBackstop+0xce [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 39] 08 00000053`b8cff3a0 00007fff`b8a37d7a m3core!RTException__InvokeBackstop+0x3b [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 25] 09 00000053`b8cff3e0 00007fff`b8a23f2a m3core!RTException__Raise+0x9a [C:\s\cm3\m3-libs\m3core\src\runtime\ex_frame\RTExFrame.m3 @ 90] 0a 00000053`b8cff440 00007fff`b8a23d4b m3core!RTException__DefaultBackstop+0x19a [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 49] 0b 00000053`b8cff4b0 00007fff`b8a37d7a m3core!RTException__InvokeBackstop+0x3b [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 25] 0c 00000053`b8cff4f0 00007fff`b8a06cce m3core!RTException__Raise+0x9a [C:\s\cm3\m3-libs\m3core\src\runtime\ex_frame\RTExFrame.m3 @ 90] 0d 00000053`b8cff550 00007ff8`2d57626a m3core!RTHooks__ReportFault+0xfe [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTHooks.m3 @ 112] 0e 00000053`b8cff5f0 00007ff8`2d5747f2 m3tcp!M_TCP_L_100_CRASH+0x1a [C:\s\cm3\m3-comm\tcp\AMD64_NT\TCP.m3.c @ 2759] 0f 00000053`b8cff620 00007ff8`2d57371c m3tcp!TCP__InitSock+0xc2 [C:\s\cm3\m3-comm\tcp\src\WIN32\TCP.m3 @ 310] 10 00000053`b8cff680 00007fff`fe8302b3 m3tcp!TCP__NewConnector+0xdc [C:\s\cm3\m3-comm\tcp\src\WIN32\TCP.m3 @ 72] 11 00000053`b8cff720 00007fff`fe82d814 sharedobj!LocalObjectSpace__SpaceInit+0x283 [C:\s\cm3\m3-comm\sharedobj\src\LocalObjectSpace.m3 @ 391] 12 00000053`b8cff930 00007fff`b8a21e17 sharedobj!LocalObjectSpace_M3+0x94 [C:\s\cm3\m3-comm\sharedobj\src\LocalObjectSpace.m3 @ 805] 13 00000053`b8cff990 00007fff`b8a21c9a m3core!RTLinker__RunMainBody+0x3e7 [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTLinker.m3 @ 408] 14 00000053`b8cffa30 00007fff`b8a21c9a m3core!RTLinker__RunMainBody+0x26a [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTLinker.m3 @ 389] 15 00000053`b8cffad0 00007fff`b8a21c9a m3core!RTLinker__RunMainBody+0x26a [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTLinker.m3 @ 389] 16 00000053`b8cffb70 00007fff`b8a21c9a m3core!RTLinker__RunMainBody+0x26a [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTLinker.m3 @ 389] 17 00000053`b8cffc10 00007fff`b8a2209b m3core!RTLinker__RunMainBody+0x26a [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTLinker.m3 @ 389] 18 00000053`b8cffcb0 00007fff`b8a21818 m3core!RTLinker__AddUnitI+0x11b [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTLinker.m3 @ 116] 19 00000053`b8cffcf0 00007ff6`f5b31038 m3core!RTLinker__AddUnit+0x118 [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTLinker.m3 @ 125] 1a 00000053`b8cffd50 00007ff6`f5db4d38 mentor!main+0x38 [C:\s\cm3\m3-demo\mentor\AMD64_NT\_m3main.c @ 23] 1b (Inline Function) --------`-------- mentor!invoke_main+0x22 [d:\agent\_work\5\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl @ 78] 1c 00000053`b8cffd80 00007ff8`49a67034 mentor!__scrt_common_main_seh+0x10c [d:\agent\_work\5\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl @ 288] 1d 00000053`b8cffdc0 00007ff8`4a8fd241 KERNEL32!BaseThreadInitThunk+0x14 [clientcore\base\win32\client\thread.c @ 64] 1e 00000053`b8cffdf0 00000000`00000000 ntdll!RtlUserThreadStart+0x21 [minkernel\ntdll\rtlstrt.c @ 1153] *** *** runtime error: *** An enumeration or subrange value was out of range. *** file "..\src\WIN32\TCP.m3", line 310 *** it is "simple" subrange problem. IF WinSock.ioctlsocket(sock, WinSock.FIONBIO, ADR(one)) = SockErr THEN IPError.Die(); END; It is *not* calling that IPError.Die(). ioctlsocket is declared as: PROCEDURE ioctlsocket (s: SOCKET; cmd: INT32; argp: UNTRACED REF UINT32): INT32; INT32 = Cstdint.int32_t; int32_t = Cstdint.int32_t; int32_t = Ctypes.int; int = [-16_7fffffff-1 .. 16_7fffffff]; It is range checking ioctlsocket parameter WinSock.FIONBIO against that and rejecting it. The code is: 307 00007ff8`2d5747ca e847620000 call m3tcp!setsockopt (00007ff8`2d57aa16) previous line 307 00007ff8`2d5747cf 89442430 mov dword ptr [rsp+30h],eax 310 00007ff8`2d5747d3 b87e660880 mov eax,8008667Eh WinSock.FIONBIO 310 00007ff8`2d5747d8 4889442440 mov qword ptr [rsp+40h],rax 310 00007ff8`2d5747dd 48817c2440ffffff7f cmp qword ptr [rsp+40h],7FFFFFFFh 310 00007ff8`2d5747e6 7e0a jle m3tcp!TCP__InitSock+0xc2 (00007ff8`2d5747f2) Branch m3tcp!TCP__InitSock+0xb8 [C:\s\cm3\m3-comm\tcp\src\WIN32\TCP.m3 @ 310]: 310 00007ff8`2d5747e8 b9c1260000 mov ecx,26C1h 310 00007ff8`2d5747ed e85e1a0000 call m3tcp!M_TCP_L_100_CRASH (00007ff8`2d576250) dv /V 00000053`b8cff660 @rsp+0x0040 L_345_L_346 = 0n2148034174 mov eax, constant is zero extending and to confirm: C:\s>type fio.c #include #include int main() { printf("%d %x\n", FIONBIO, FIONBIO); return 0; } C:\s>cl fio.c Microsoft (R) C/C++ Optimizing Compiler Version 19.24.28316 for x64 Copyright (C) Microsoft Corporation. All rights reserved. fio.c Microsoft (R) Incremental Linker Version 14.24.28316.0 Copyright (C) Microsoft Corporation. All rights reserved. /out:fio.exe fio.obj C:\s>fio.exe -2147195266 8004667e What is the right way to do this? Just change to UINT32? Even it works, can you explain it to me? I agree integers should not silently overflow, subranges are good, but this doesn't seem to me like it should be so difficult. I am inclined to further drain the Modula-3 "headers" and make it an "extern constant variable", really, though I'm not sure that will help, though it serves another purpose -- I like to minimally duplicate C headers. That is one way Posix ports became much easier. Thank you, - Jay , _______________________________________________ M3devel mailing list M3devel at elegosoft.com https://m3lists.elegosoft.com/mailman/listinfo/m3devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Mon Feb 22 21:06:02 2021 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Mon, 22 Feb 2021 15:06:02 -0500 Subject: [M3devel] Modula-3 subranges vs. opaque arbitrary 32bit constants? In-Reply-To: References: <0ea053e7-ecc8-88ab-0355-c1119a71e21f@lcwb.coop> <20210222033402.4xwebtssvlnpuuzx@topoi.pooq.com> Message-ID: <20210222200602.lqinta3wr6ugyh2j@topoi.pooq.com> On Mon, Feb 22, 2021 at 11:50:19AM +0000, Jay K wrote: > Can we switch both to C backend? > I mean, yes and no, on deleting m3cc/m3gdb..'cause repo size.. > > I386 users, Darwin, Linux, NT, please try amd64? > Do you still use non-amd64 hardware? Yes. > It's been out for over 15 years. I bought this machine new in 2008. Still works great for everything except memory hogs like firefox. -- hendrik From jayk123 at hotmail.com Mon Feb 22 23:12:45 2021 From: jayk123 at hotmail.com (Jay K) Date: Mon, 22 Feb 2021 22:12:45 +0000 Subject: [M3devel] Modula-3 subranges vs. opaque arbitrary 32bit constants? In-Reply-To: <20210222200602.lqinta3wr6ugyh2j@topoi.pooq.com> References: <0ea053e7-ecc8-88ab-0355-c1119a71e21f@lcwb.coop> <20210222033402.4xwebtssvlnpuuzx@topoi.pooq.com> , <20210222200602.lqinta3wr6ugyh2j@topoi.pooq.com> Message-ID: > I bought this machine new in 2008. Like 5 years after the replacements shipped, and now more than 10 years ago. And this is used a lot, primarily, only? I mean, if we are just chit chatting, I don't mind. ? Personally I have used 32bit systems (kernels) almost never, since around 2003. 32bit usermode continues to be widespread. My editor is 32bit, from around 1997. I recently booted Linux/macppc32 and it was slow, like git clone (not of Modula-3). Even this amd64 stuff is threatening to be obsoleted soon, by arm64 and/or riscv64. I am going to try to get those running shortly. It should be easy with C backend. It becomes super tempting then to delete m3cc and m3gdb entirely. Reduce the repo size (ignoring history) and reduce license "problems". - Jay ________________________________ From: M3devel on behalf of Hendrik Boom Sent: Monday, February 22, 2021 8:06 PM To: m3devel at elegosoft.com Subject: Re: [M3devel] Modula-3 subranges vs. opaque arbitrary 32bit constants? On Mon, Feb 22, 2021 at 11:50:19AM +0000, Jay K wrote: > Can we switch both to C backend? > I mean, yes and no, on deleting m3cc/m3gdb..'cause repo size.. > > I386 users, Darwin, Linux, NT, please try amd64? > Do you still use non-amd64 hardware? Yes. > It's been out for over 15 years. I bought this machine new in 2008. Still works great for everything except memory hogs like firefox. -- hendrik _______________________________________________ M3devel mailing list M3devel at elegosoft.com https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fm3lists.elegosoft.com%2Fmailman%2Flistinfo%2Fm3devel&data=04%7C01%7C%7C7a299a99b3d14a4ce96b08d8d76d5364%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637496211845618287%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=KDahMgw9APfxtET7kS5%2BNpaYQzYm4tvL49Uley4uCfc%3D&reserved=0 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Tue Feb 23 03:39:05 2021 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Mon, 22 Feb 2021 21:39:05 -0500 Subject: [M3devel] Modula-3 subranges vs. opaque arbitrary 32bit constants? In-Reply-To: References: <0ea053e7-ecc8-88ab-0355-c1119a71e21f@lcwb.coop> <20210222033402.4xwebtssvlnpuuzx@topoi.pooq.com> <20210222200602.lqinta3wr6ugyh2j@topoi.pooq.com> Message-ID: <20210223023905.fcwpuewzidpxglt7@topoi.pooq.com> On Mon, Feb 22, 2021 at 10:12:45PM +0000, Jay K wrote: > > I bought this machine new in 2008. > > Like 5 years after the replacements shipped, and now more than 10 years ago. > > And this is used a lot, primarily, only? It is my lightest-weight computer; I take it when I compute away from home. This used to be nearly every day before the pandemic, and it will be again after. For obscure reasons it's also the only computer that seems to talk reliably to my printer (but that's not really relevant to Modula 3). -- hendrik > I mean, if we are just chit chatting, I don't mind. ? > > Personally I have used 32bit systems (kernels) almost never, since around 2003. > 32bit usermode continues to be widespread. My editor is 32bit, from around 1997. > > I recently booted Linux/macppc32 and it was slow, like git clone (not of Modula-3). > > Even this amd64 stuff is threatening to be obsoleted soon, by arm64 and/or riscv64. Or the Power architecture in a few years: https://libre-soc.org/ That's an attempt to design a completely open, free, libre CPU. We'll see. -- hendrik > I am going to try to get those running shortly. It should be easy with C backend. > It becomes super tempting then to delete m3cc and m3gdb entirely. > Reduce the repo size (ignoring history) and reduce license "problems". > > - Jay > > ________________________________ > From: M3devel on behalf of Hendrik Boom > Sent: Monday, February 22, 2021 8:06 PM > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Modula-3 subranges vs. opaque arbitrary 32bit constants? > > On Mon, Feb 22, 2021 at 11:50:19AM +0000, Jay K wrote: > > Can we switch both to C backend? > > I mean, yes and no, on deleting m3cc/m3gdb..'cause repo size.. > > > > I386 users, Darwin, Linux, NT, please try amd64? > > Do you still use non-amd64 hardware? > > Yes. > > > It's been out for over 15 years. > > I bought this machine new in 2008. > > Still works great for everything except memory hogs like firefox. > > -- hendrik > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fm3lists.elegosoft.com%2Fmailman%2Flistinfo%2Fm3devel&data=04%7C01%7C%7C7a299a99b3d14a4ce96b08d8d76d5364%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637496211845618287%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=KDahMgw9APfxtET7kS5%2BNpaYQzYm4tvL49Uley4uCfc%3D&reserved=0 From jayk123 at hotmail.com Tue Feb 23 07:50:05 2021 From: jayk123 at hotmail.com (Jay K) Date: Tue, 23 Feb 2021 06:50:05 +0000 Subject: [M3devel] target names Message-ID: 1. Do we still want to use the name "Darwin". It always struck me as wierd, but I know, it is a name out there. 2. Do we still want target names to be all caps? 3. Any other objections/suggestions? Context is: 4. all existing names, but I understand, hard to change 5. Hypothetical but quite likely new targets: ARM64_NT, ARM64_LINUX, ARM64_DARWIN, RISCV64_LINUX and granted, target names should not matter so much, targets are nearly all identical. Any thoughts on differentiating iphone vs. ipad vs. Mac? ARM64_APPLE? ARM64_MAC? Or just stick to "Darwin" and it is all of them in one, disambiguating "Apple" from pre-OSX, A/AUX, DOS 3.3, SOS, ProDOS, GS/OS, etc. ? (and I wonder about desktop gui...X Windows client/server...) I am not actually likely to try running on iPhone. Honestly, I think WebAssembly is the future for phone and desktop, and we should really target that (including node.js command line)..I'll see if our C is ok...but the static link passed to function pointers in case they are nested, is likely to be a problem, we'll see, later... - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Feb 23 08:56:05 2021 From: jayk123 at hotmail.com (Jay K) Date: Tue, 23 Feb 2021 07:56:05 +0000 Subject: [M3devel] i386_linux buildable? Message-ID: For the record..I'm not sure I care to finish this exercise, but I'm building I386_LINUX on a Linux/amd64 host. I have various cross dev packages installed. I cross bootstrapped from windows using the C backend: ./boot1.py c i386_linux The C backend has problems though, related to setjmp, that I will fix. I thought I'd give the gcc backend a try. It largely works, but ultimately fails: == package /s/cm3/caltech-parser/cit_util == +++ /cm3/bin/cm3 -build -DROOT=/s/cm3 +++ --- building in I386_LINUX --- ignoring ../src/m3overrides new source -> compiling DebugClass.m3 "../src/DebugClass.m3", line 7: warning: not used (IO) 1 warning encountered ../src/DebugClass.m3: In function 'DebugClass__DoInit': ../src/DebugClass.m3:31:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. m3_backend => 4 m3cc (aka cm3cg) failed compiling: DebugClass.mc new source -> compiling RefPairSeq.m3 ../I386_LINUX/RefPairSeq.m3 => /cm3/pkg/libm3/src/sequence/Sequence.mg: In function 'RefPairSeq__Remlo': ../I386_LINUX/RefPairSeq.m3 => /cm3/pkg/libm3/src/sequence/Sequence.mg:127:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. m3_backend => 4 m3cc (aka cm3cg) failed compiling: RefPairSeq.mc new source -> compiling IntPairSeq.m3 ../I386_LINUX/IntPairSeq.m3 => /cm3/pkg/libm3/src/sequence/Sequence.mg: In function 'IntPairSeq__Remlo': ../I386_LINUX/IntPairSeq.m3 => /cm3/pkg/libm3/src/sequence/Sequence.mg:127:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. m3_backend => 4 m3cc (aka cm3cg) failed compiling: IntPairSeq.mc new source -> compiling CardPairSet.m3 ../I386_LINUX/CardPairSet.m3 => /cm3/pkg/set/src/Set.mg: In function 'CardPairSet__Intersect': ../I386_LINUX/CardPairSet.m3 => /cm3/pkg/set/src/Set.mg:69:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. m3_backend => 4 m3cc (aka cm3cg) failed compiling: CardPairSet.mc new source -> compiling CardPairSetDef.m3 ../I386_LINUX/CardPairSetDef.m3 => /cm3/pkg/set/src/SetDef.mg: In function 'CardPairSetDef__Diff': ../I386_LINUX/CardPairSetDef.m3 => /cm3/pkg/set/src/SetDef.mg:96:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. m3_backend => 4 m3cc (aka cm3cg) failed compiling: CardPairSetDef.mc new source -> compiling IntPairSet.m3 ../I386_LINUX/IntPairSet.m3 => /cm3/pkg/set/src/Set.mg: In function 'IntPairSet__Intersect': ../I386_LINUX/IntPairSet.m3 => /cm3/pkg/set/src/Set.mg:69:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. m3_backend => 4 m3cc (aka cm3cg) failed compiling: IntPairSet.mc new source -> compiling IntPairSetDef.m3 ../I386_LINUX/IntPairSetDef.m3 => /cm3/pkg/set/src/SetDef.mg: In function 'IntPairSetDef__Diff': ../I386_LINUX/IntPairSetDef.m3 => /cm3/pkg/set/src/SetDef.mg:96:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. m3_backend => 4 m3cc (aka cm3cg) failed compiling: IntPairSetDef.mc new source -> compiling IntRational.m3 ../I386_LINUX/IntRational.m3 => ../src/Rational.mg: In function 'IntRational__New': ../I386_LINUX/IntRational.m3 => ../src/Rational.mg:21:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. m3_backend => 4 m3cc (aka cm3cg) failed compiling: IntRational.mc new source -> compiling BigRational.m3 ../I386_LINUX/BigRational.m3 => ../src/Rational.mg: In function 'BigRational__Add': ../I386_LINUX/BigRational.m3 => ../src/Rational.mg:60:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. m3_backend => 4 m3cc (aka cm3cg) failed compiling: BigRational.mc new source -> compiling IntIntArraySort.m3 ../I386_LINUX/IntIntArraySort.m3 => /cm3/pkg/libm3/src/sort/ArraySort.mg: In function 'IntIntArraySort__InsertionSort': ../I386_LINUX/IntIntArraySort.m3 => /cm3/pkg/libm3/src/sort/ArraySort.mg:86:0: warning: '' may be used uninitialized in this function [-Wmaybe-uninitialized] ../I386_LINUX/IntIntArraySort.m3 => /cm3/pkg/libm3/src/sort/ArraySort.mg:92:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. m3_backend => 4 m3cc (aka cm3cg) failed compiling: IntIntArraySort.mc new source -> compiling TCPMaker.m3 ../src/TCPMaker.m3: In function 'TCPMaker__MMT': ../src/TCPMaker.m3:75:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. m3_backend => 4 m3cc (aka cm3cg) failed compiling: TCPMaker.mc new source -> compiling AttrWrSeq.m3 ../I386_LINUX/AttrWrSeq.m3 => /cm3/pkg/libm3/src/sequence/Sequence.mg: In function 'AttrWrSeq__Remlo': ../I386_LINUX/AttrWrSeq.m3 => /cm3/pkg/libm3/src/sequence/Sequence.mg:127:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. m3_backend => 4 m3cc (aka cm3cg) failed compiling: AttrWrSeq.mc new source -> compiling SafeTZ.m3 ../src/SafeTZ.m3: In function 'SafeTZ__ParseSimplifiedSubsecond': ../src/SafeTZ.m3:139:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. m3_backend => 4 m3cc (aka cm3cg) failed compiling: SafeTZ.mc new source -> compiling FinDate.m3 ../src/FinDate.m3: In function 'FinDate__MYParseFIX': ../src/FinDate.m3:439:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. m3_backend => 4 m3cc (aka cm3cg) failed compiling: FinDate.mc new source -> compiling FinDateArraySort.m3 ../I386_LINUX/FinDateArraySort.m3 => /cm3/pkg/libm3/src/sort/ArraySort.mg: In function 'FinDateArraySort__InsertionSort': ../I386_LINUX/FinDateArraySort.m3 => /cm3/pkg/libm3/src/sort/ArraySort.mg:86:0: warning: '' may be used uninitialized in this function [-Wmaybe-uninitialized] ../I386_LINUX/FinDateArraySort.m3 => /cm3/pkg/libm3/src/sort/ArraySort.mg:92:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. m3_backend => 4 m3cc (aka cm3cg) failed compiling: FinDateArraySort.mc new source -> compiling XTime.m3 ../src/XTime.m3: In function 'XTime_M3': ../src/XTime.m3:280:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. m3_backend => 4 m3cc (aka cm3cg) failed compiling: XTime.mc compilation failed => not building library "libcit_util.a" Fatal Error: package build failed *** execution of [, ] failed *** ubuntu at ub1:/s/cm3/scripts/python$ I continue to believe C or similar (C++, Zig, Java, asm.js) backend is the path to much better longevity. And I will get back to that. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Feb 23 10:26:13 2021 From: jayk123 at hotmail.com (Jay K) Date: Tue, 23 Feb 2021 09:26:13 +0000 Subject: [M3devel] setjmp/longjmp, exception handling interface between frontend and backend? Message-ID: I want to revise how exception handling works between the front end and backends. Ideally, try, except, and finally would be calls in m3cg. It'd be optional. I'm not sure what they'd look like. Some backends (target/config) would tell the frontend to keep doing the same thing. But also, even with setjmp/longjmp it would be useful to have a higher level interface. So the C backend can easily say: jmpbuf x; setjmp(x); instead of: address x = alloca(m3_jmpbuf_size) setjmp(x); // fails to compile sometimes currently due to type mismatch - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Feb 23 11:47:26 2021 From: jayk123 at hotmail.com (Jay K) Date: Tue, 23 Feb 2021 10:47:26 +0000 Subject: [M3devel] i386_linux buildable? In-Reply-To: References: Message-ID: Not too surprisingly, the variable is the host compiler, used to compile cm3cg. If I turn off optimizations building cm3cg, then it works better. - Jay ________________________________ From: Jay K Sent: Tuesday, February 23, 2021 7:56 AM To: m3devel at elegosoft.com Subject: i386_linux buildable? For the record..I'm not sure I care to finish this exercise, but I'm building I386_LINUX on a Linux/amd64 host. I have various cross dev packages installed. I cross bootstrapped from windows using the C backend: ./boot1.py c i386_linux The C backend has problems though, related to setjmp, that I will fix. I thought I'd give the gcc backend a try. It largely works, but ultimately fails: == package /s/cm3/caltech-parser/cit_util == +++ /cm3/bin/cm3 -build -DROOT=/s/cm3 +++ --- building in I386_LINUX --- ignoring ../src/m3overrides new source -> compiling DebugClass.m3 "../src/DebugClass.m3", line 7: warning: not used (IO) 1 warning encountered ../src/DebugClass.m3: In function 'DebugClass__DoInit': ../src/DebugClass.m3:31:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. m3_backend => 4 m3cc (aka cm3cg) failed compiling: DebugClass.mc new source -> compiling RefPairSeq.m3 ../I386_LINUX/RefPairSeq.m3 => /cm3/pkg/libm3/src/sequence/Sequence.mg: In function 'RefPairSeq__Remlo': ../I386_LINUX/RefPairSeq.m3 => /cm3/pkg/libm3/src/sequence/Sequence.mg:127:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. m3_backend => 4 m3cc (aka cm3cg) failed compiling: RefPairSeq.mc new source -> compiling IntPairSeq.m3 ../I386_LINUX/IntPairSeq.m3 => /cm3/pkg/libm3/src/sequence/Sequence.mg: In function 'IntPairSeq__Remlo': ../I386_LINUX/IntPairSeq.m3 => /cm3/pkg/libm3/src/sequence/Sequence.mg:127:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. m3_backend => 4 m3cc (aka cm3cg) failed compiling: IntPairSeq.mc new source -> compiling CardPairSet.m3 ../I386_LINUX/CardPairSet.m3 => /cm3/pkg/set/src/Set.mg: In function 'CardPairSet__Intersect': ../I386_LINUX/CardPairSet.m3 => /cm3/pkg/set/src/Set.mg:69:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. m3_backend => 4 m3cc (aka cm3cg) failed compiling: CardPairSet.mc new source -> compiling CardPairSetDef.m3 ../I386_LINUX/CardPairSetDef.m3 => /cm3/pkg/set/src/SetDef.mg: In function 'CardPairSetDef__Diff': ../I386_LINUX/CardPairSetDef.m3 => /cm3/pkg/set/src/SetDef.mg:96:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. m3_backend => 4 m3cc (aka cm3cg) failed compiling: CardPairSetDef.mc new source -> compiling IntPairSet.m3 ../I386_LINUX/IntPairSet.m3 => /cm3/pkg/set/src/Set.mg: In function 'IntPairSet__Intersect': ../I386_LINUX/IntPairSet.m3 => /cm3/pkg/set/src/Set.mg:69:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. m3_backend => 4 m3cc (aka cm3cg) failed compiling: IntPairSet.mc new source -> compiling IntPairSetDef.m3 ../I386_LINUX/IntPairSetDef.m3 => /cm3/pkg/set/src/SetDef.mg: In function 'IntPairSetDef__Diff': ../I386_LINUX/IntPairSetDef.m3 => /cm3/pkg/set/src/SetDef.mg:96:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. m3_backend => 4 m3cc (aka cm3cg) failed compiling: IntPairSetDef.mc new source -> compiling IntRational.m3 ../I386_LINUX/IntRational.m3 => ../src/Rational.mg: In function 'IntRational__New': ../I386_LINUX/IntRational.m3 => ../src/Rational.mg:21:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. m3_backend => 4 m3cc (aka cm3cg) failed compiling: IntRational.mc new source -> compiling BigRational.m3 ../I386_LINUX/BigRational.m3 => ../src/Rational.mg: In function 'BigRational__Add': ../I386_LINUX/BigRational.m3 => ../src/Rational.mg:60:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. m3_backend => 4 m3cc (aka cm3cg) failed compiling: BigRational.mc new source -> compiling IntIntArraySort.m3 ../I386_LINUX/IntIntArraySort.m3 => /cm3/pkg/libm3/src/sort/ArraySort.mg: In function 'IntIntArraySort__InsertionSort': ../I386_LINUX/IntIntArraySort.m3 => /cm3/pkg/libm3/src/sort/ArraySort.mg:86:0: warning: '' may be used uninitialized in this function [-Wmaybe-uninitialized] ../I386_LINUX/IntIntArraySort.m3 => /cm3/pkg/libm3/src/sort/ArraySort.mg:92:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. m3_backend => 4 m3cc (aka cm3cg) failed compiling: IntIntArraySort.mc new source -> compiling TCPMaker.m3 ../src/TCPMaker.m3: In function 'TCPMaker__MMT': ../src/TCPMaker.m3:75:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. m3_backend => 4 m3cc (aka cm3cg) failed compiling: TCPMaker.mc new source -> compiling AttrWrSeq.m3 ../I386_LINUX/AttrWrSeq.m3 => /cm3/pkg/libm3/src/sequence/Sequence.mg: In function 'AttrWrSeq__Remlo': ../I386_LINUX/AttrWrSeq.m3 => /cm3/pkg/libm3/src/sequence/Sequence.mg:127:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. m3_backend => 4 m3cc (aka cm3cg) failed compiling: AttrWrSeq.mc new source -> compiling SafeTZ.m3 ../src/SafeTZ.m3: In function 'SafeTZ__ParseSimplifiedSubsecond': ../src/SafeTZ.m3:139:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. m3_backend => 4 m3cc (aka cm3cg) failed compiling: SafeTZ.mc new source -> compiling FinDate.m3 ../src/FinDate.m3: In function 'FinDate__MYParseFIX': ../src/FinDate.m3:439:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. m3_backend => 4 m3cc (aka cm3cg) failed compiling: FinDate.mc new source -> compiling FinDateArraySort.m3 ../I386_LINUX/FinDateArraySort.m3 => /cm3/pkg/libm3/src/sort/ArraySort.mg: In function 'FinDateArraySort__InsertionSort': ../I386_LINUX/FinDateArraySort.m3 => /cm3/pkg/libm3/src/sort/ArraySort.mg:86:0: warning: '' may be used uninitialized in this function [-Wmaybe-uninitialized] ../I386_LINUX/FinDateArraySort.m3 => /cm3/pkg/libm3/src/sort/ArraySort.mg:92:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. m3_backend => 4 m3cc (aka cm3cg) failed compiling: FinDateArraySort.mc new source -> compiling XTime.m3 ../src/XTime.m3: In function 'XTime_M3': ../src/XTime.m3:280:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. m3_backend => 4 m3cc (aka cm3cg) failed compiling: XTime.mc compilation failed => not building library "libcit_util.a" Fatal Error: package build failed *** execution of [, ] failed *** ubuntu at ub1:/s/cm3/scripts/python$ I continue to believe C or similar (C++, Zig, Java, asm.js) backend is the path to much better longevity. And I will get back to that. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Tue Feb 23 15:17:26 2021 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Tue, 23 Feb 2021 09:17:26 -0500 Subject: [M3devel] target names In-Reply-To: References: Message-ID: <20210223141726.wuw7a7qihw5glv6n@topoi.pooq.com> On Tue, Feb 23, 2021 at 06:50:05AM +0000, Jay K wrote: > 1. Do we still want to use the name "Darwin". It always struck me as wierd, but I know, it is a name out there. > 2. Do we still want target names to be all caps? > 3. Any other objections/suggestions? > > Context is: > 4. all existing names, but I understand, hard to change > 5. Hypothetical but quite likely new targets: ARM64_NT, ARM64_LINUX, ARM64_DARWIN, RISCV64_LINUX > > and granted, target names should not matter so much, targets are nearly all identical. > > Any thoughts on differentiating iphone vs. ipad vs. Mac? > ARM64_APPLE? > ARM64_MAC? > > Or just stick to "Darwin" and it is all of them in one, disambiguating "Apple" from pre-OSX, A/AUX, DOS 3.3, SOS, ProDOS, GS/OS, etc. ? > (and I wonder about desktop gui...X Windows client/server...) > > I am not actually likely to try running on iPhone. Honestly, I think WebAssembly is the future for phone and desktop, and we should really target that (including node.js command line)..I'll see if our C is ok...but the static link passed to function pointers in case they are nested, is likely to be a problem, we'll see, later... WebAssembly is good for programs to be run in a web page, and possibly for portability of object code, but is not likely to be as efficient as an object-code generated directly and specifically for the target machine. I'd guess that even C intermediate code would end up faster than WebAssembly. -- hendrik > > - Jay > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://m3lists.elegosoft.com/mailman/listinfo/m3devel From hendrik at topoi.pooq.com Tue Feb 23 15:24:01 2021 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Tue, 23 Feb 2021 09:24:01 -0500 Subject: [M3devel] i386_linux buildable? In-Reply-To: References: Message-ID: <20210223142401.qnibio67g45emtlr@topoi.pooq.com> On Tue, Feb 23, 2021 at 07:56:05AM +0000, Jay K wrote: > For the record..I'm not sure I care to finish this exercise, but I'm building I386_LINUX on a Linux/amd64 host. > > I have various cross dev packages installed. > > I cross bootstrapped from windows using the C backend: > ./boot1.py c i386_linux > > The C backend has problems though, related to setjmp, that I will fix. > > I thought I'd give the gcc backend a try. > > It largely works, but ultimately fails: ... ... > > I continue to believe C or similar (C++, Zig, Java, asm.js) backend is the path to much better longevity. > And I will get back to that. Likely, yes. Because C is more governed by a standard than the gcc back end. And giving up on the gcc backend might ease the license feud between Modula 3 and the FSF. Can we hope they might someday declare that Modula 3's licence is compatible, thought not identical, with the GPL? -- hendrik From rodney_bates at lcwb.coop Tue Feb 23 17:30:54 2021 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Tue, 23 Feb 2021 10:30:54 -0600 Subject: [M3devel] Modula-3 subranges vs. opaque arbitrary 32bit constants? In-Reply-To: References: Message-ID: <5ff943fd-0b7a-af3b-97e0-db88fba5c806@lcwb.coop> On 2/22/21 11:00 AM, Rodney M. Bates wrote: > > > On 2/21/21 5:19 PM, Jay K wrote: >> Seriously, how do I form arbitrary 32bit constants? ? >> > > Several years ago, I sent a post about different ways different > languages provide arithmetic on both full-range signed full-range > unsigned integers.? I'll see if I can fin I'm not sure this is the one I meant. Not so relevant to this thread, but just for completeness, here it is: ---------------------------------------------------------------------- Signed and unsigned integers are inherently confusing and have no easy linguistic solution that doesn't involve tradeoffs. Modula-3 and C have significantly different mechanisms. Correctly translating the former into the latter inevitably is going to require generating some not-so-pretty code. The C and Modula-2 way is to have distinct signed and unsigned types. Usually, the unsigned type is full-range. The builtin operators are overloaded and in general, have different definitions when applied to a signed vs. an unsigned type. Type conversions, implicit or explicit, must be done for an operator to have mixed signed/unsigned operands. The Modula-3 way is to have only a (normally) signed INTEGER type, but different operators with different names, that apply either a signed or unsigned interpretation to the bits of this one type. All the builtins that syntactically use operator notation ('+', etc.) are unconditionally signed. The only unsigned operators are (pseudo-) functions in Word.i3. Note that Word.T = INTEGER. Having on occasions done very careful mixed signed/unsigned code in both Modula-2 and Modula-3, I like the Modula-3 way a bit better. It doesn't really make a lot of difference in how hard you have to think about the signedness of every operand and operator, but it does at least greatly simplify the definition of the language's rules and the difficulty of understanding and remembering them. Compared to Modula-2 (where any signedness type conversions must be explicit), Modula-3 does make it easier to go into denial and ignore the problem. Since C will apply the conversions implicitly, it makes it just as easy to deny, while requiring a lot more semantic rules. So translating Modula-3 to C involves changing the way signed/unsigned operators are done. I don't think there is any way to get it right other than to translate all types into C signed types and explicitly cast every value to/from the corresponding unsigned type exactly when the translation of an operation from Word is applied. (Well, making everything unsigned would work, but generate far more frequent ugly C code.) I suppose a set of macros for the unsigned operators might make for prettier C code. C's casts are inconsistent about when they are true type conversions (defined by a mapping between the abstract values of the two types) and the equivalent of LOOPHOLE (defined by just reinterpreting the same bits via a different set of representation rules). For translating operators in Word, you need a LOOPHOLE equivalent. Fortunately, as I read Harbison and Steele, C's casts in this case can pretty well be depended on to have this meaning. So then back-end shift operators, since only Word has source language equivalents for them, really should always treat the to-be-shifted operand as unsigned, despite the fact that the operand has the back- end equivalent of a signed type. This should be true in any back-end, not just a C-generating one. I suppose this could require explicit casts in the M3CG representation, but that is exactly the pedantic way output from a front-end should be. -- Rodney Bates rodney.m.bates at acm.org From jayk123 at hotmail.com Tue Feb 23 17:48:29 2021 From: jayk123 at hotmail.com (Jay K) Date: Tue, 23 Feb 2021 16:48:29 +0000 Subject: [M3devel] target names In-Reply-To: <20210223141726.wuw7a7qihw5glv6n@topoi.pooq.com> References: , <20210223141726.wuw7a7qihw5glv6n@topoi.pooq.com> Message-ID: WebAssembly is much more than web/browser, as you indicate, it is portable object code. And gives some safety to C and C++, though not as much as most safe systems. The JIT should be pretty good. It can also be considered as a distribution format, and then at install time run the JIT in a different mode, or converted to C, etc. - Jay ________________________________ From: M3devel on behalf of Hendrik Boom Sent: Tuesday, February 23, 2021 2:17 PM To: m3devel at elegosoft.com Subject: Re: [M3devel] target names On Tue, Feb 23, 2021 at 06:50:05AM +0000, Jay K wrote: > 1. Do we still want to use the name "Darwin". It always struck me as wierd, but I know, it is a name out there. > 2. Do we still want target names to be all caps? > 3. Any other objections/suggestions? > > Context is: > 4. all existing names, but I understand, hard to change > 5. Hypothetical but quite likely new targets: ARM64_NT, ARM64_LINUX, ARM64_DARWIN, RISCV64_LINUX > > and granted, target names should not matter so much, targets are nearly all identical. > > Any thoughts on differentiating iphone vs. ipad vs. Mac? > ARM64_APPLE? > ARM64_MAC? > > Or just stick to "Darwin" and it is all of them in one, disambiguating "Apple" from pre-OSX, A/AUX, DOS 3.3, SOS, ProDOS, GS/OS, etc. ? > (and I wonder about desktop gui...X Windows client/server...) > > I am not actually likely to try running on iPhone. Honestly, I think WebAssembly is the future for phone and desktop, and we should really target that (including node.js command line)..I'll see if our C is ok...but the static link passed to function pointers in case they are nested, is likely to be a problem, we'll see, later... WebAssembly is good for programs to be run in a web page, and possibly for portability of object code, but is not likely to be as efficient as an object-code generated directly and specifically for the target machine. I'd guess that even C intermediate code would end up faster than WebAssembly. -- hendrik > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Feb 23 23:35:38 2021 From: jayk123 at hotmail.com (Jay K) Date: Tue, 23 Feb 2021 22:35:38 +0000 Subject: [M3devel] risc-v backend In-Reply-To: References: <1a6fdbed-fa81-5147-4cc4-854f9933616c@lcwb.coop> <1387378483.9393209.1605295683164@mail.yahoo.com> <4e28d62b-c37f-d345-4c64-8c6e3e9c2bab@lcwb.coop> <1248444975.531123.1605528721286@mail.ziggo.nl> <1724a1c2-6330-c108-a93d-447c72d1732d@lcwb.coop> <20201117124642.vo7iqlomgcohj3vf@topoi.pooq.com> , Message-ID: Yes. I hope to get to this quite soon. There is a minor problem with setjmp right now..thought I guess if I just compile as C it'll change error to warning.. Then qemu, and then maybe a friend's board. - Jay ________________________________ From: Mika Nystrom Sent: Tuesday, November 17, 2020 7:16 PM To: Jay K Cc: Henning Thielemann ; Hendrik Boom ; m3devel at elegosoft.com Subject: Re: [M3devel] risc-v backend Jay, people ought to be able to basically get things going on RISC-V right away, with your C backend, no? On Tue, Nov 17, 2020 at 11:14 AM Jay K > wrote: I wholeheartedly agree, from an earlier message in this thread, that: A C/C++ generating backend should be, like, the main portable stable production backend, for use on all targets. And then, additional integrated backends can be written, as time allows, for fun, for practise with LLVM, etc. And then, this part of the system can be considered extremely portable and finished and done. Potentially, porting to new processors becomes a no-op. You would just have the following configurations: Posix little endian 32bit. (x86, arm32) Posix little endian 64bit. (amd64, arm64) Posix big endian 32bit. (sparc32, hppa32, sometimes mips, rarely arm) Posix big endian 64bit. (sparc64, hppa64, sometimes mips, rarely arm) Jmpbuf size is factored out, or generate C++ that uses C++ exceptions. I understand that there are debugging improvements from an integrated backend, but it isn't so simple. The debugging improvements require work that rots even more. Gdb is not even supported on Mac, for example. Let alone the problem of maintaining it. As well, the debugging of generated C can be not horrible. There could be typed structs with members. Which I realize does not completely solve TEXT. But it does solve most types. The debugging experience of the NT386 integrated backend is not so good. It only has functions and line numbers. Keep in mind also that the "mainline" gcc backend is now several years out of date as well. I do also understand that generating C is noticably slow to compile. It is a tradeoff. Maybe some day I'll unrot this stuff, and make it the default. At the same time, a reimplementation of the frontend, might not be so difficult. The language is not huge. - Jay ________________________________ From: M3devel > on behalf of Henning Thielemann > Sent: Tuesday, November 17, 2020 3:16 PM To: Hendrik Boom > Cc: m3devel at elegosoft.com > Subject: Re: [M3devel] risc-v backend On Tue, 17 Nov 2020, Hendrik Boom wrote: > Unless we get the license changed, I suspect the only way to get Modula 3 > into the GNU compiler collection is to reimplement it. > > Which is why I advise that anything we now *add* to the entire Modula 3 > ecosystem be dual-licenced under both the existing license and a > GPL-compatible one (such as the MIT licence). I know the licence was discussed here at length - but I cannot remember that the cm3 licence would be incompatible with GPL. _______________________________________________ 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 Feb 24 00:58:50 2021 From: jayk123 at hotmail.com (Jay K) Date: Tue, 23 Feb 2021 23:58:50 +0000 Subject: [M3devel] i386_linux buildable? In-Reply-To: References: , Message-ID: Here is a workaround: m3cc: Do not optimize gcc register allocator as that causes ? modula3/cm3 at 0257cbf (github.com) I can build the entire I386_LINUX system now with the gcc backend. Maybe someone could debug that more some time. I'll try to make a release shortly, though github was giving me problems. - Jay ________________________________ From: Jay K Sent: Tuesday, February 23, 2021 10:47 AM To: m3devel at elegosoft.com Subject: Re: i386_linux buildable? Not too surprisingly, the variable is the host compiler, used to compile cm3cg. If I turn off optimizations building cm3cg, then it works better. - Jay ________________________________ From: Jay K Sent: Tuesday, February 23, 2021 7:56 AM To: m3devel at elegosoft.com Subject: i386_linux buildable? For the record..I'm not sure I care to finish this exercise, but I'm building I386_LINUX on a Linux/amd64 host. I have various cross dev packages installed. I cross bootstrapped from windows using the C backend: ./boot1.py c i386_linux The C backend has problems though, related to setjmp, that I will fix. I thought I'd give the gcc backend a try. It largely works, but ultimately fails: == package /s/cm3/caltech-parser/cit_util == +++ /cm3/bin/cm3 -build -DROOT=/s/cm3 +++ --- building in I386_LINUX --- ignoring ../src/m3overrides new source -> compiling DebugClass.m3 "../src/DebugClass.m3", line 7: warning: not used (IO) 1 warning encountered ../src/DebugClass.m3: In function 'DebugClass__DoInit': ../src/DebugClass.m3:31:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. m3_backend => 4 m3cc (aka cm3cg) failed compiling: DebugClass.mc new source -> compiling RefPairSeq.m3 ../I386_LINUX/RefPairSeq.m3 => /cm3/pkg/libm3/src/sequence/Sequence.mg: In function 'RefPairSeq__Remlo': ../I386_LINUX/RefPairSeq.m3 => /cm3/pkg/libm3/src/sequence/Sequence.mg:127:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. m3_backend => 4 m3cc (aka cm3cg) failed compiling: RefPairSeq.mc new source -> compiling IntPairSeq.m3 ../I386_LINUX/IntPairSeq.m3 => /cm3/pkg/libm3/src/sequence/Sequence.mg: In function 'IntPairSeq__Remlo': ../I386_LINUX/IntPairSeq.m3 => /cm3/pkg/libm3/src/sequence/Sequence.mg:127:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. m3_backend => 4 m3cc (aka cm3cg) failed compiling: IntPairSeq.mc new source -> compiling CardPairSet.m3 ../I386_LINUX/CardPairSet.m3 => /cm3/pkg/set/src/Set.mg: In function 'CardPairSet__Intersect': ../I386_LINUX/CardPairSet.m3 => /cm3/pkg/set/src/Set.mg:69:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. m3_backend => 4 m3cc (aka cm3cg) failed compiling: CardPairSet.mc new source -> compiling CardPairSetDef.m3 ../I386_LINUX/CardPairSetDef.m3 => /cm3/pkg/set/src/SetDef.mg: In function 'CardPairSetDef__Diff': ../I386_LINUX/CardPairSetDef.m3 => /cm3/pkg/set/src/SetDef.mg:96:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. m3_backend => 4 m3cc (aka cm3cg) failed compiling: CardPairSetDef.mc new source -> compiling IntPairSet.m3 ../I386_LINUX/IntPairSet.m3 => /cm3/pkg/set/src/Set.mg: In function 'IntPairSet__Intersect': ../I386_LINUX/IntPairSet.m3 => /cm3/pkg/set/src/Set.mg:69:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. m3_backend => 4 m3cc (aka cm3cg) failed compiling: IntPairSet.mc new source -> compiling IntPairSetDef.m3 ../I386_LINUX/IntPairSetDef.m3 => /cm3/pkg/set/src/SetDef.mg: In function 'IntPairSetDef__Diff': ../I386_LINUX/IntPairSetDef.m3 => /cm3/pkg/set/src/SetDef.mg:96:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. m3_backend => 4 m3cc (aka cm3cg) failed compiling: IntPairSetDef.mc new source -> compiling IntRational.m3 ../I386_LINUX/IntRational.m3 => ../src/Rational.mg: In function 'IntRational__New': ../I386_LINUX/IntRational.m3 => ../src/Rational.mg:21:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. m3_backend => 4 m3cc (aka cm3cg) failed compiling: IntRational.mc new source -> compiling BigRational.m3 ../I386_LINUX/BigRational.m3 => ../src/Rational.mg: In function 'BigRational__Add': ../I386_LINUX/BigRational.m3 => ../src/Rational.mg:60:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. m3_backend => 4 m3cc (aka cm3cg) failed compiling: BigRational.mc new source -> compiling IntIntArraySort.m3 ../I386_LINUX/IntIntArraySort.m3 => /cm3/pkg/libm3/src/sort/ArraySort.mg: In function 'IntIntArraySort__InsertionSort': ../I386_LINUX/IntIntArraySort.m3 => /cm3/pkg/libm3/src/sort/ArraySort.mg:86:0: warning: '' may be used uninitialized in this function [-Wmaybe-uninitialized] ../I386_LINUX/IntIntArraySort.m3 => /cm3/pkg/libm3/src/sort/ArraySort.mg:92:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. m3_backend => 4 m3cc (aka cm3cg) failed compiling: IntIntArraySort.mc new source -> compiling TCPMaker.m3 ../src/TCPMaker.m3: In function 'TCPMaker__MMT': ../src/TCPMaker.m3:75:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. m3_backend => 4 m3cc (aka cm3cg) failed compiling: TCPMaker.mc new source -> compiling AttrWrSeq.m3 ../I386_LINUX/AttrWrSeq.m3 => /cm3/pkg/libm3/src/sequence/Sequence.mg: In function 'AttrWrSeq__Remlo': ../I386_LINUX/AttrWrSeq.m3 => /cm3/pkg/libm3/src/sequence/Sequence.mg:127:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. m3_backend => 4 m3cc (aka cm3cg) failed compiling: AttrWrSeq.mc new source -> compiling SafeTZ.m3 ../src/SafeTZ.m3: In function 'SafeTZ__ParseSimplifiedSubsecond': ../src/SafeTZ.m3:139:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. m3_backend => 4 m3cc (aka cm3cg) failed compiling: SafeTZ.mc new source -> compiling FinDate.m3 ../src/FinDate.m3: In function 'FinDate__MYParseFIX': ../src/FinDate.m3:439:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. m3_backend => 4 m3cc (aka cm3cg) failed compiling: FinDate.mc new source -> compiling FinDateArraySort.m3 ../I386_LINUX/FinDateArraySort.m3 => /cm3/pkg/libm3/src/sort/ArraySort.mg: In function 'FinDateArraySort__InsertionSort': ../I386_LINUX/FinDateArraySort.m3 => /cm3/pkg/libm3/src/sort/ArraySort.mg:86:0: warning: '' may be used uninitialized in this function [-Wmaybe-uninitialized] ../I386_LINUX/FinDateArraySort.m3 => /cm3/pkg/libm3/src/sort/ArraySort.mg:92:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. m3_backend => 4 m3cc (aka cm3cg) failed compiling: FinDateArraySort.mc new source -> compiling XTime.m3 ../src/XTime.m3: In function 'XTime_M3': ../src/XTime.m3:280:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. m3_backend => 4 m3cc (aka cm3cg) failed compiling: XTime.mc compilation failed => not building library "libcit_util.a" Fatal Error: package build failed *** execution of [, ] failed *** ubuntu at ub1:/s/cm3/scripts/python$ I continue to believe C or similar (C++, Zig, Java, asm.js) backend is the path to much better longevity. And I will get back to that. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Wed Feb 24 08:12:26 2021 From: jayk123 at hotmail.com (Jay K) Date: Wed, 24 Feb 2021 07:12:26 +0000 Subject: [M3devel] setjmp, _setjmp, sigsetjmp et. al.? Message-ID: Hi. I need a little guidance. There are the following: setjmp(jmp_buf) _setjmp(jmp_buf) sigsetjmp(sigjmp_buf, int) The differences: _setjmp is a BSD-ism originally, but I guess quite portable? sigsetjmp is a Posix-ism. Quite portable? setjmp is ANSI, BSD, and Posix. Very portable in its existance, but not its meaning. On BSD, or if sigsetjmp second param is non-zero, signal mask is saved. _setjmp does not save signal mask. One might quibble over if we ought to save/restore the signal mask, but on Linux at least that is a syscall. This stuff is already too slow, that would make it worse. So let's not. (Why is it not a thread local? I don't know.) So from a modern standard perspective, the decision is obviously to use: sigsetjmp(sigjmp_buf, 0) at least ifndef _WIN32. Question becomes as to if that is portable enough. _setjmp is pretty portable too, and what we have been using all along, except on NT and VMS. VMS never having really run. NT being real. But portability is desirable. I'm thinking besides frontend should call m3_setjmp, leaving C backend a little flexibility. Maybe this? // Frontend presently gets the type wrong, which is why I'm here, // it passes a char*. // Wrap in struct to paranoidly avoid taking address of array, which // some compilers might warn about? typedef struct m3_jmpbuf { jmp_buf jb; } m3_jmpbuf; #define m3_setjmp(name, buf) (name((((m3_jmpbuf*)buf)->jb)) and frontend continues to decide what is name? I will try that. Alternatively the C backend could something like: #if __FreeBSD__ | __NetBSD__ | __OpenBSD__ | __APPLE__ #define m3_setjmp(buf) (_setjmp((((m3_jmpbuf*)buf)->jb)) #else #define m3_setjmp(buf) (setjmp((((m3_jmpbuf*)buf)->jb)) #endif Problem is maintaining that #if. I know Linux (glibc) offers #define _BSD_SOURCE as well, and maybe others do too, but I'm wary of "global modes". You know, I don't know what all it does. It could change other things we don't want changed. and..."Like a developer yelling fire in a crowded theater..." maybe really we could/should throw autoconf or cmake at this problem? I've long considered, but never done much about, the idea that we should be producing something that is actually input to autoconf/automake/libtool, or cmake. We could generate *that* input. I know they are all ugly and slow, but they do nicely delegate problems to others, including hypothetical support for systems we haven't seen. And yes, really, I get it, they are disliked. This would also provide for a better cross build story (given matching word size and endian especially). For now I think having frontend pass the name to backend is the smaller change, assuming passing a macro name to a macro isn't asking for trouble. setjmp often being a macro. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Wed Feb 24 09:37:28 2021 From: jayk123 at hotmail.com (Jay K) Date: Wed, 24 Feb 2021 08:37:28 +0000 Subject: [M3devel] try/finally vs. try/except and frame/alloca stuff Message-ID: I noticed something odd tonight. I should have noticed when I wrote the C backend years ago..or I guess when I later moved jmpbuf size out of middle/front. C:\s\cm3\m3-libs\libm3\src\rw\AutoFlushWr.m3 AutoFlushWr.m3 PROCEDURE Init (wr: T; ch: Wr.T; p := -1.0D0): T = BEGIN WrClass.Lock(wr); WrClass.Lock(ch); TRY Copy(ch, wr); wr.buffered := TRUE; wr.child := ch; wr.onQ := FALSE; wr.link := NIL; FINALLY WrClass.Unlock(ch); WrClass.Unlock(wr); END; IF p < 0.0D0 THEN wr.delay := Default ELSE wr.delay := p END; RETURN wr END Init; I always had in my head a rough model, that "try == setjmp". But upon closer inspection and *then* thought (backwards, I know), try does not require setjmp. Only except does. Try establishes a "frame". Which is still slow in current system. Frame includes a function pointer, to a function that is the finally body. The non-exceptional path pops the frame and then calls the body. No big deal, really. But question is, why does this function call alloca? Well, I think this is probably a bug in my work there. I count up trys and alloca a jmpbuf for each. But this is only needed if the jmpbuf if passed to setjmp. i.e. if it matches an except. Because except i.e. catch can "stop" the longjmp. Can be returned to. If there is only try/finally, throw/raise/longjmp never stops there. Yes? I'll try to fix. This is unfortunate, to throw in the alloca and then not use the result. Hopefully the try in try/except is easily differentiated from the try in try/finally in the frontend. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Wed Feb 24 09:45:19 2021 From: jayk123 at hotmail.com (Jay K) Date: Wed, 24 Feb 2021 08:45:19 +0000 Subject: [M3devel] m3cc/m3gdb git submodules? Message-ID: If anyone knows how to setup and use git submodules, I would like m3cc and m3gdb to be moved out. Caveat that making a release with github should still include them, I guess. Maybe optionally, i.e. depending on if the release uses the C backend. Hopefully github already handles that, but I don't know. Git performance on Windows is terrible at least in typical default configuration, and I think this would help a lot. It isn't all that great on Linux on this side repository either. Thank you, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Wed Feb 24 11:11:54 2021 From: jayk123 at hotmail.com (Jay K) Date: Wed, 24 Feb 2021 10:11:54 +0000 Subject: [M3devel] try/finally vs. try/except and frame/alloca stuff In-Reply-To: References: Message-ID: Hm. I wonder if this is more about homing registers so GC can see them?? i.e. CaptureState? - Jay ________________________________ From: M3devel on behalf of Jay K Sent: Wednesday, February 24, 2021 8:37 AM To: m3devel at elegosoft.com Subject: [M3devel] try/finally vs. try/except and frame/alloca stuff I noticed something odd tonight. I should have noticed when I wrote the C backend years ago..or I guess when I later moved jmpbuf size out of middle/front. C:\s\cm3\m3-libs\libm3\src\rw\AutoFlushWr.m3 AutoFlushWr.m3 PROCEDURE Init (wr: T; ch: Wr.T; p := -1.0D0): T = BEGIN WrClass.Lock(wr); WrClass.Lock(ch); TRY Copy(ch, wr); wr.buffered := TRUE; wr.child := ch; wr.onQ := FALSE; wr.link := NIL; FINALLY WrClass.Unlock(ch); WrClass.Unlock(wr); END; IF p < 0.0D0 THEN wr.delay := Default ELSE wr.delay := p END; RETURN wr END Init; I always had in my head a rough model, that "try == setjmp". But upon closer inspection and *then* thought (backwards, I know), try does not require setjmp. Only except does. Try establishes a "frame". Which is still slow in current system. Frame includes a function pointer, to a function that is the finally body. The non-exceptional path pops the frame and then calls the body. No big deal, really. But question is, why does this function call alloca? Well, I think this is probably a bug in my work there. I count up trys and alloca a jmpbuf for each. But this is only needed if the jmpbuf if passed to setjmp. i.e. if it matches an except. Because except i.e. catch can "stop" the longjmp. Can be returned to. If there is only try/finally, throw/raise/longjmp never stops there. Yes? I'll try to fix. This is unfortunate, to throw in the alloca and then not use the result. Hopefully the try in try/except is easily differentiated from the try in try/finally in the frontend. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Wed Feb 24 11:43:40 2021 From: jayk123 at hotmail.com (Jay K) Date: Wed, 24 Feb 2021 10:43:40 +0000 Subject: [M3devel] coroutine gap Message-ID: void * ContextC__PushContext(Context *c) { auto char a[STACK_GAP]; /* the purpose of the gap is to allow other routines to do some small amount of work between when we return and the next GC event, without clobbering the context we are about to push */ (void)memset(a, 0, STACK_GAP); return ContextC__PushContext1(c); } This is not convincing. memset is typically builtin to the compiler, so it is not some extern function the compiler does not understand. It will just optimize this away. And "auto" is redundant, and repurposed by C++. I've heard of people using it in the original meaning, but never seen it. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Wed Feb 24 13:00:56 2021 From: jayk123 at hotmail.com (Jay K) Date: Wed, 24 Feb 2021 12:00:56 +0000 Subject: [M3devel] Grisu problems Message-ID: Folks, this Grisu thing has been unusually problematic. It definitely fails with the C backend, and I'm not sure, maybe with the NT386 integrated backend. I realize it could be/likely-is bugs in those backends, but they do manage to compile a lot else. Maybe someone can investigate? For now I've selectively disabled it, i.e. for Win32 and shortly for the C backend, sorry. I want to move on to other things before investigating this. -> linking shobjcodegen g++ -gstabs+ -m64 -fPIC -g -c -xc++ _m3main.c -o _m3main.o *** *** runtime error: *** <*ASSERT*> failed. *** file "../src/float/Common/grisu/IEEE.m3", line 155 *** More so though, I suggest all endian-specific code be in C or C++..not because Modula-3 cannot do it, but in order to get towards an endian-independent distribution format. Perhaps also floating point formating should be left to sprintf? (Caveat that Win32 sprintf("%f") does a heap allocation, I think, ouch.) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Wed Feb 24 19:59:51 2021 From: jayk123 at hotmail.com (Jay K) Date: Wed, 24 Feb 2021 18:59:51 +0000 Subject: [M3devel] ARM64_DARWIN release Message-ID: ARM64_DARWIN works. The C backend made it easy. ? Release ARM64_DARWIN-20210224 ? modula3/cm3 (github.com) -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Wed Feb 24 23:43:58 2021 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Wed, 24 Feb 2021 16:43:58 -0600 Subject: [M3devel] Grisu problems In-Reply-To: References: Message-ID: <8882d3ad-b0ac-1fc6-99ff-338e4a16676c@lcwb.coop> On 2/24/21 6:00 AM, Jay K wrote: > Folks, this Grisu thing has been unusually problematic. > It definitely fails with the C backend, and I'm not sure, maybe with the NT386 integrated backend. > I realize it could be/likely-is bugs in those backends, but they do manage to compile a lot else. > Maybe someone can investigate? > For now I've selectively disabled it, i.e. for Win32 and shortly for the C backend, sorry. > I want to move on to other things before investigating this. > > ?-> linking shobjcodegen > g++ -gstabs+ -m64 -fPIC -g -c -xc++ _m3main.c -o _m3main.o > How did a g++ command cause execution of Modula-3 code? What is the executable that failed? What work size? What back end compiled it? > > *** > *** runtime error: > *** ? ?<*ASSERT*> failed. > *** ? ?file "../src/float/Common/grisu/IEEE.m3", line 155 > *** > > More so though, I suggest all endian-specific code be in C or C++..not because Modula-3 cannot do it, but in order to get towards an endian-independent distribution format. > > Perhaps also floating point formating should be left to sprintf? > (Caveat that Win32 sprintf("%f") does a heap allocation, I think, ouch.) > > ?- 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 Thu Feb 25 00:13:15 2021 From: jayk123 at hotmail.com (Jay K) Date: Wed, 24 Feb 2021 23:13:15 +0000 Subject: [M3devel] Grisu problems In-Reply-To: <8882d3ad-b0ac-1fc6-99ff-338e4a16676c@lcwb.coop> References: , <8882d3ad-b0ac-1fc6-99ff-338e4a16676c@lcwb.coop> Message-ID: I think that is multi-threaded output. ________________________________ From: Rodney M. Bates Sent: Wednesday, February 24, 2021 10:43 PM To: Jay K ; m3devel at elegosoft.com Subject: Re: [M3devel] Grisu problems On 2/24/21 6:00 AM, Jay K wrote: > Folks, this Grisu thing has been unusually problematic. > It definitely fails with the C backend, and I'm not sure, maybe with the NT386 integrated backend. > I realize it could be/likely-is bugs in those backends, but they do manage to compile a lot else. > Maybe someone can investigate? > For now I've selectively disabled it, i.e. for Win32 and shortly for the C backend, sorry. > I want to move on to other things before investigating this. > > -> linking shobjcodegen > g++ -gstabs+ -m64 -fPIC -g -c -xc++ _m3main.c -o _m3main.o > How did a g++ command cause execution of Modula-3 code? What is the executable that failed? What work size? What back end compiled it? > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "../src/float/Common/grisu/IEEE.m3", line 155 > *** > > More so though, I suggest all endian-specific code be in C or C++..not because Modula-3 cannot do it, but in order to get towards an endian-independent distribution format. > > Perhaps also floating point formating should be left to sprintf? > (Caveat that Win32 sprintf("%f") does a heap allocation, I think, ouch.) > > - Jay > > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fm3lists.elegosoft.com%2Fmailman%2Flistinfo%2Fm3devel&data=04%7C01%7C%7C42f744e1afa048290d5c08d8d915c6f5%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637498034844456909%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=0ammeIIgTwogFoEek3HnJOkClpXltIKOfUerSgkfMA8%3D&reserved=0 > -- Rodney Bates rodney.m.bates at acm.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Thu Feb 25 01:44:10 2021 From: jayk123 at hotmail.com (Jay K) Date: Thu, 25 Feb 2021 00:44:10 +0000 Subject: [M3devel] Grisu problems In-Reply-To: References: <8882d3ad-b0ac-1fc6-99ff-338e4a16676c@lcwb.coop> , Message-ID: I do not mean that threading causes the ?crash?. I mean that threading makes the output confusing. The threading is causing other problems, but that is not conclusively blame. There are bugs everywhere. More debugging is needed. The threading seems ok on Unix host/target. Again, more debugging is needed. - Jay ________________________________ From: Mika Nystrom Sent: Wednesday, February 24, 2021 4:34:04 PM To: Jay K Cc: m3devel at elegosoft.com ; rodney.m.bates at acm.org Subject: Re: [M3devel] Grisu problems Hm, are you saying maybe the error goes away if you turn off parallel compiling? But hold on here. There ought to be a synchronization before g++ is called, no? Why is it attempting to link before all the front-ends are done? That doesn't make much sense. FIRST, compile all the sources into .o THEN, link the .os to the final executable using g++ grisu is some sort of floating library used by the compiler? I don't see any globals in the grisu library, seems like it ought to be reentrant, whatever it is it's doing. On Wed, Feb 24, 2021 at 3:13 PM Jay K > wrote: I think that is multi-threaded output. ________________________________ From: Rodney M. Bates > Sent: Wednesday, February 24, 2021 10:43 PM To: Jay K >; m3devel at elegosoft.com > Subject: Re: [M3devel] Grisu problems On 2/24/21 6:00 AM, Jay K wrote: > Folks, this Grisu thing has been unusually problematic. > It definitely fails with the C backend, and I'm not sure, maybe with the NT386 integrated backend. > I realize it could be/likely-is bugs in those backends, but they do manage to compile a lot else. > Maybe someone can investigate? > For now I've selectively disabled it, i.e. for Win32 and shortly for the C backend, sorry. > I want to move on to other things before investigating this. > > -> linking shobjcodegen > g++ -gstabs+ -m64 -fPIC -g -c -xc++ _m3main.c -o _m3main.o > How did a g++ command cause execution of Modula-3 code? What is the executable that failed? What work size? What back end compiled it? > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "../src/float/Common/grisu/IEEE.m3", line 155 > *** > > More so though, I suggest all endian-specific code be in C or C++..not because Modula-3 cannot do it, but in order to get towards an endian-independent distribution format. > > Perhaps also floating point formating should be left to sprintf? > (Caveat that Win32 sprintf("%f") does a heap allocation, I think, ouch.) > > - Jay > > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fm3lists.elegosoft.com%2Fmailman%2Flistinfo%2Fm3devel&data=04%7C01%7C%7C42f744e1afa048290d5c08d8d915c6f5%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637498034844456909%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=0ammeIIgTwogFoEek3HnJOkClpXltIKOfUerSgkfMA8%3D&reserved=0 > -- 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 jayk123 at hotmail.com Thu Feb 25 01:54:26 2021 From: jayk123 at hotmail.com (Jay K) Date: Thu, 25 Feb 2021 00:54:26 +0000 Subject: [M3devel] Grisu problems In-Reply-To: References: <8882d3ad-b0ac-1fc6-99ff-338e4a16676c@lcwb.coop> , Message-ID: g++ can be the backend. :) And here is compiling main, which is always C, I changed that years ago ? fewer options are better. There is wiggle room in C++ spec to require this to run global constructors also but no modern system works that way, I think. Maybe an old cfront-ism. But fewer configuration knobs is better here imho. - Jay ________________________________ From: Mika Nystrom Sent: Wednesday, February 24, 2021 4:50:04 PM To: Jay K Cc: m3devel at elegosoft.com ; rodney.m.bates at acm.org Subject: Re: [M3devel] Grisu problems yes OK sorry I was conflating two theories in my email just now. One was that threading causes the crash. The other though, at the point when cm3 is running g++, my point was, shouldn't there just be one program thread? It ought to have joined all the threads that were used to compile the .os in parallel long since by the time it runs g++ to link. As far as I remember, anyhow. On Wed, Feb 24, 2021 at 4:44 PM Jay K > wrote: I do not mean that threading causes the ?crash?. I mean that threading makes the output confusing. The threading is causing other problems, but that is not conclusively blame. There are bugs everywhere. More debugging is needed. The threading seems ok on Unix host/target. Again, more debugging is needed. - Jay ________________________________ From: Mika Nystrom > Sent: Wednesday, February 24, 2021 4:34:04 PM To: Jay K > Cc: m3devel at elegosoft.com >; rodney.m.bates at acm.org > Subject: Re: [M3devel] Grisu problems Hm, are you saying maybe the error goes away if you turn off parallel compiling? But hold on here. There ought to be a synchronization before g++ is called, no? Why is it attempting to link before all the front-ends are done? That doesn't make much sense. FIRST, compile all the sources into .o THEN, link the .os to the final executable using g++ grisu is some sort of floating library used by the compiler? I don't see any globals in the grisu library, seems like it ought to be reentrant, whatever it is it's doing. On Wed, Feb 24, 2021 at 3:13 PM Jay K > wrote: I think that is multi-threaded output. ________________________________ From: Rodney M. Bates > Sent: Wednesday, February 24, 2021 10:43 PM To: Jay K >; m3devel at elegosoft.com > Subject: Re: [M3devel] Grisu problems On 2/24/21 6:00 AM, Jay K wrote: > Folks, this Grisu thing has been unusually problematic. > It definitely fails with the C backend, and I'm not sure, maybe with the NT386 integrated backend. > I realize it could be/likely-is bugs in those backends, but they do manage to compile a lot else. > Maybe someone can investigate? > For now I've selectively disabled it, i.e. for Win32 and shortly for the C backend, sorry. > I want to move on to other things before investigating this. > > -> linking shobjcodegen > g++ -gstabs+ -m64 -fPIC -g -c -xc++ _m3main.c -o _m3main.o > How did a g++ command cause execution of Modula-3 code? What is the executable that failed? What work size? What back end compiled it? > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "../src/float/Common/grisu/IEEE.m3", line 155 > *** > > More so though, I suggest all endian-specific code be in C or C++..not because Modula-3 cannot do it, but in order to get towards an endian-independent distribution format. > > Perhaps also floating point formating should be left to sprintf? > (Caveat that Win32 sprintf("%f") does a heap allocation, I think, ouch.) > > - Jay > > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fm3lists.elegosoft.com%2Fmailman%2Flistinfo%2Fm3devel&data=04%7C01%7C%7C42f744e1afa048290d5c08d8d915c6f5%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637498034844456909%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=0ammeIIgTwogFoEek3HnJOkClpXltIKOfUerSgkfMA8%3D&reserved=0 > -- 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 jayk123 at hotmail.com Thu Feb 25 05:45:52 2021 From: jayk123 at hotmail.com (Jay K) Date: Thu, 25 Feb 2021 04:45:52 +0000 Subject: [M3devel] target collapse (making targets less different)? Message-ID: For a long time I've wanted to collapse the target matrix. I'm back at it and e.g. comparing the C bootstrap of i386_FREEBSD with I386_DARWIN I see some differences: 1. The .c files start with the target as a comment. 2. Generic instantiations have source paths in them with target. Sometimes in line directives (which works, so that with the C backend, you step through the Modula-3 source). Sometimes not in line directives. I suspect assertion failure related but I don't know. I think these are things to work out of the system, so we might have an I386_UNIX target, or release/distribution. (or further collapse but this is a nice step) Or at least hash based deduplication. So if I target I386_DARWIN and I386_FREBSD in two separate invocations of cm3, they can share the C output. Or a distribution can have "all" targets, but mostly shared files. So this a request for ideas and discussion and/or rationale for *possible* upcoming changes. Though I'm not sure exactly what to do. The target comment can be omitted or optional. The line directives are valuable but could be omitted, or omitted if they contain target, or target genericized. For generic instantiations, really, the line directives and assertion failures (which I imagine is what some of it is) could reference the non-instantiated source? Would that be ok? Or too little information? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Thu Feb 25 05:48:31 2021 From: jayk123 at hotmail.com (Jay K) Date: Thu, 25 Feb 2021 04:48:31 +0000 Subject: [M3devel] win32 <* ASSERT suspend_cnt = 0 *> ? Message-ID: Today I ran: for /f %a in (targets.txt) do .\boot1.py %a c It worked a lot, and then a lot of: *** *** runtime error: *** <*ASSERT*> failed. *** file "..\src\thread\WIN32\ThreadWin32.m3", line 798 *** which is here: PROCEDURE SuspendOthers () = (* LL=0. Always bracketed with ResumeOthers which releases "activeLock". *) VAR me: Activation; act: Activation; retry: BOOLEAN; BEGIN EnterCriticalSection(ADR(activeLock)); <* ASSERT suspend_cnt = 0 *> <--- INC (suspend_cnt); IF suspend_cnt # 1 THEN RETURN END; any ideas? This is AMD64_NT. I'll try to reproduce it under a debugger. The code looks a little odd, in that it seems prepared for the assertion failure. Thank you, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Thu Feb 25 06:37:29 2021 From: jayk123 at hotmail.com (Jay K) Date: Thu, 25 Feb 2021 05:37:29 +0000 Subject: [M3devel] win32 <* ASSERT suspend_cnt = 0 *> ? another int32 vs. uint32 on win64 problem In-Reply-To: References: Message-ID: Ok it seems like a bug in reporting of assertion failures. The repro is: \python27\python boot1.py PA32_HPUX c or \bin\amd64\windbg /g /G /o \python27\python boot1.py PA32_HPUX c which its an assertion failure in the C backend, I will look into. IF WinBase.IsDebuggerPresent () # 0 THEN WinBase.DebugBreak (); END; 3:013> k # Child-SP RetAddr Call Site KERNELBASE!DebugBreak 02 000000bc`984fd2c0 00007ff6`4baa2e9f cm3!RTOS__Crash+0x43 [C:\s\cm3\m3-libs\m3core\src\runtime\WIN32\RTOS.m3 @ 26] 03 000000bc`984fd310 00007ff6`4bad0b4f cm3!RTProcess__Crash+0x6f [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTProcess.m3 @ 66] 04 000000bc`984fd350 00007ff6`4bad0780 cm3!RTError__EndError+0x3f [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTError.m3 @ 119] 05 000000bc`984fd390 00007ff6`4bae8cd7 cm3!RTError__MsgS+0xa0 [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTError.m3 @ 41] 06 000000bc`984fd3d0 00007ff6`4bae88de cm3!RTException__Crash+0x317 [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 81] 07 000000bc`984fd460 00007ff6`4bae87cb cm3!RTException__DefaultBackstop+0xce [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 39] 08 000000bc`984fd4d0 00007ff6`4bae90ca cm3!RTException__InvokeBackstop+0x3b [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 25] 09 000000bc`984fd510 00007ff6`4bae89aa cm3!RTException__Raise+0x9a [C:\s\cm3\m3-libs\m3core\src\runtime\ex_frame\RTExFrame.m3 @ 90] 0a 000000bc`984fd570 00007ff6`4bae87cb cm3!RTException__DefaultBackstop+0x19a [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 49] 0b 000000bc`984fd5e0 00007ff6`4bae90ca cm3!RTException__InvokeBackstop+0x3b [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 25] 0c 000000bc`984fd620 00007ff6`4babb4fe cm3!RTException__Raise+0x9a [C:\s\cm3\m3-libs\m3core\src\runtime\ex_frame\RTExFrame.m3 @ 90] 0d 000000bc`984fd680 00007ff6`4b71aeca cm3!RTHooks__ReportFault+0xfe [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTHooks.m3 @ 112] 0e 000000bc`984fd720 00007ff6`4b7050f7 cm3!M_M3C_L_166_CRASH+0x1a [C:\s\cm3\m3-sys\m3back\AMD64_NT\M3C.m3.c @ 31094] C backend assertion failure here: 0f 000000bc`984fd750 00007ff6`4b7038d4 cm3!M3C__TIntLiteral+0x5a7 [C:\s\cm3\m3-sys\m3back\src\M3C.m3 @ 4830] 10 000000bc`984fd800 00007ff6`4b703997 cm3!M3C__init_int+0x2b4 [C:\s\cm3\m3-sys\m3back\src\M3C.m3 @ 4658] 11 000000bc`984fd8b0 00007ff6`4ba0b759 cm3!M3C__Segments_init_int+0x97 [C:\s\cm3\m3-sys\m3back\src\M3C.m3 @ 4668] 12 000000bc`984fd8f0 00007ff6`4ba10079 cm3!M3CG_MultiPass__replay_init_int+0x89 [C:\s\cm3\m3-sys\m3middle\src\M3CG_MultiPass.m3 @ 1234] 13 000000bc`984fd940 00007ff6`4b6f285c cm3!M3CG_MultiPass__Replay+0x649 [C:\s\cm3\m3-sys\m3middle\src\M3CG_MultiPass.m3 @ 250] 14 000000bc`984fda30 00007ff6`4ba1d983 cm3!M3C__multipass_end_unit+0x7ac [C:\s\cm3\m3-sys\m3back\src\M3C.m3 @ 2374] 15 000000bc`984fdb30 00007ff6`4b84174d cm3!M3CG_Check__end_unit+0x113 [C:\s\cm3\m3-sys\m3middle\src\M3CG_Check.m3 @ 365] 16 000000bc`984fdba0 00007ff6`4b7f77c1 cm3!CG__End_unit+0x11d [C:\s\cm3\m3-sys\m3front\src\misc\CG.m3 @ 192] 17 000000bc`984fdbf0 00007ff6`4b7dea9c cm3!Module__Compile+0x511 [C:\s\cm3\m3-sys\m3front\src\values\Module.m3 @ 931] 18 000000bc`984fdc80 00007ff6`4b7ddace cm3!M3Front__DoCompile+0xb3c [C:\s\cm3\m3-sys\m3front\src\misc\M3Front.m3 @ 220] 19 000000bc`984fddb0 00007ff6`4b6b2472 cm3!M3Front__Compile+0x32e [C:\s\cm3\m3-sys\m3front\src\misc\M3Front.m3 @ 67] 1a 000000bc`984fde50 00007ff6`4b6b0186 cm3!Builder__RunM3Front+0x6c2 [C:\s\cm3\m3-sys\cm3\src\Builder.m3 @ 1972] 1b 000000bc`984fdf10 00007ff6`4b6af0ab cm3!Builder__PushOneM3+0x816 [C:\s\cm3\m3-sys\cm3\src\Builder.m3 @ 1618] 1c 000000bc`984fe180 00007ff6`4b6ac058 cm3!Builder__CompileM3+0x33b [C:\s\cm3\m3-sys\cm3\src\Builder.m3 @ 1407] 1d 000000bc`984fe1e0 00007ff6`4b6b2e8b cm3!Builder__CompileOne+0x2a8 [C:\s\cm3\m3-sys\cm3\src\Builder.m3 @ 1102] 1e 000000bc`984fe290 00007ff6`4b6b2279 cm3!Builder__Pass0_CheckImports+0x16b [C:\s\cm3\m3-sys\cm3\src\Builder.m3 @ 2017] 1f 000000bc`984fe2f0 00007ff6`4b6b0186 cm3!Builder__RunM3Front+0x4c9 [C:\s\cm3\m3-sys\cm3\src\Builder.m3 @ 1957] 20 000000bc`984fe3b0 00007ff6`4b6af0ab cm3!Builder__PushOneM3+0x816 [C:\s\cm3\m3-sys\cm3\src\Builder.m3 @ 1618] 21 000000bc`984fe620 00007ff6`4b6ac058 cm3!Builder__CompileM3+0x33b [C:\s\cm3\m3-sys\cm3\src\Builder.m3 @ 1407] 22 000000bc`984fe680 00007ff6`4b6ab958 cm3!Builder__CompileOne+0x2a8 [C:\s\cm3\m3-sys\cm3\src\Builder.m3 @ 1102] 23 000000bc`984fe730 00007ff6`4b6a50b2 cm3!Builder__CompileEverything+0x2b8 [C:\s\cm3\m3-sys\cm3\src\Builder.m3 @ 1047] 24 000000bc`984fe930 00007ff6`4b6a2df8 cm3!Builder__CompileUnits+0x1222 [C:\s\cm3\m3-sys\cm3\src\Builder.m3 @ 359] 25 000000bc`984fea20 00007ff6`4b6ccf57 cm3!Builder__BuildLib+0x58 [C:\s\cm3\m3-sys\cm3\src\Builder.m3 @ 40] 26 000000bc`984fea80 00007ff6`4b7b538c cm3!M3Build__DoLibrary+0x227 [C:\s\cm3\m3-sys\cm3\src\M3Build.m3 @ 1466] 27 000000bc`984feb70 00007ff6`4b7b3b22 cm3!QMachine__DoCall+0x80c [C:\s\cm3\m3-sys\m3quake\src\QMachine.m3 @ 547] 28 000000bc`984fec50 00007ff6`4b7c0289 cm3!QMachine__Eval+0x2152 [C:\s\cm3\m3-sys\m3quake\src\QMachine.m3 @ 422] 29 000000bc`984feec0 00007ff6`4b7c000a cm3!QMachine__IncludeFile+0x269 [C:\s\cm3\m3-sys\m3quake\src\QMachine.m3 @ 1774] 2a 000000bc`984ff0c0 00007ff6`4b6c6a6d cm3!QMachine__Include+0x2a [C:\s\cm3\m3-sys\m3quake\src\QMachine.m3 @ 1745] 2b 000000bc`984ff100 00007ff6`4b6c97dd cm3!M3Build__Include+0xfd [C:\s\cm3\m3-sys\cm3\src\M3Build.m3 @ 679] 2c 000000bc`984ff1a0 00007ff6`4b7b538c cm3!M3Build__DoIncludeDir+0xfd [C:\s\cm3\m3-sys\cm3\src\M3Build.m3 @ 1055] 2d 000000bc`984ff210 00007ff6`4b7b3b22 cm3!QMachine__DoCall+0x80c [C:\s\cm3\m3-sys\m3quake\src\QMachine.m3 @ 547] 2e 000000bc`984ff2f0 00007ff6`4b7b19ba cm3!QMachine__Eval+0x2152 [C:\s\cm3\m3-sys\m3quake\src\QMachine.m3 @ 422] 2f 000000bc`984ff560 00007ff6`4b7cc3fd cm3!QMachine__Evaluate+0x7a [C:\s\cm3\m3-sys\m3quake\src\QMachine.m3 @ 166] 30 000000bc`984ff5a0 00007ff6`4b6c408b cm3!Quake__Run+0xdd [C:\s\cm3\m3-sys\m3quake\src\Quake.m3 @ 20] 31 000000bc`984ff600 00007ff6`4b6e5818 cm3!M3Build__Run+0x11b [C:\s\cm3\m3-sys\cm3\src\M3Build.m3 @ 243] 32 000000bc`984ff640 00007ff6`4b6e4a02 cm3!Main__DoIt+0xd88 [C:\s\cm3\m3-sys\cm3\src\Main.m3 @ 117] 33 000000bc`984ff9e0 00007ff6`4baa1ab7 cm3!Main_M3+0x22 [C:\s\cm3\m3-sys\cm3\src\Main.m3 @ 231] 34 000000bc`984ffa20 00007ff6`4baa1d3b cm3!RTLinker__RunMainBody+0x3e7 [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTLinker.m3 @ 408] 35 000000bc`984ffac0 00007ff6`4baa14b8 cm3!RTLinker__AddUnitI+0x11b [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTLinker.m3 @ 116] 36 000000bc`984ffb00 00007ff6`4b6a1038 cm3!RTLinker__AddUnit+0x118 [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTLinker.m3 @ 125] 37 000000bc`984ffb60 00007ff6`4bb12974 cm3!main+0x38 [C:\s\cm3\m3-sys\cm3\AMD64_NT\_m3main.c @ 23] 38 (Inline Function) --------`-------- cm3!invoke_main+0x22 [d:\agent\_work\5\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl @ 78] which if you go past the breakpoint, which simulates no debugger, it hits the assertion failure I reported: 3:013> k . 13 Id: a35c.8d38 Suspend: 1 Teb: 000000bc`982c8000 Unfrozen # Child-SP RetAddr Call Site KERNELBASE!DebugBreak 02 000000bc`984fc8f0 00007ff6`4baa2e9f cm3!RTOS__Crash+0x43 [C:\s\cm3\m3-libs\m3core\src\runtime\WIN32\RTOS.m3 @ 26] 03 000000bc`984fc940 00007ff6`4bad0b4f cm3!RTProcess__Crash+0x6f [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTProcess.m3 @ 66] 04 000000bc`984fc980 00007ff6`4bad0780 cm3!RTError__EndError+0x3f [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTError.m3 @ 119] 05 000000bc`984fc9c0 00007ff6`4bae8cd7 cm3!RTError__MsgS+0xa0 [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTError.m3 @ 41] 06 000000bc`984fca00 00007ff6`4bae88de cm3!RTException__Crash+0x317 [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 81] 07 000000bc`984fca90 00007ff6`4bae87cb cm3!RTException__DefaultBackstop+0xce [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 39] 08 000000bc`984fcb00 00007ff6`4bae90ca cm3!RTException__InvokeBackstop+0x3b [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 25] 09 000000bc`984fcb40 00007ff6`4bae89aa cm3!RTException__Raise+0x9a [C:\s\cm3\m3-libs\m3core\src\runtime\ex_frame\RTExFrame.m3 @ 90] 0a 000000bc`984fcba0 00007ff6`4bae87cb cm3!RTException__DefaultBackstop+0x19a [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 49] 0b 000000bc`984fcc10 00007ff6`4bae90ca cm3!RTException__InvokeBackstop+0x3b [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 25] 0c 000000bc`984fcc50 00007ff6`4babb4fe cm3!RTException__Raise+0x9a [C:\s\cm3\m3-libs\m3core\src\runtime\ex_frame\RTExFrame.m3 @ 90] 0d 000000bc`984fccb0 00007ff6`4bac003a cm3!RTHooks__ReportFault+0xfe [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTHooks.m3 @ 112] The ThreadWin32 assertion failure. 0e 000000bc`984fcd50 00007ff6`4babbf09 cm3!M_ThreadWin32_L_137_CRASH+0x1a [C:\s\cm3\m3-libs\m3core\AMD64_NT\ThreadWin32.m3.c @ 4356] 0f 000000bc`984fcd80 00007ff6`4bae8e28 cm3!RTThread__SuspendOthers+0x89 [C:\s\cm3\m3-libs\m3core\src\thread\WIN32\ThreadWin32.m3 @ 799] 10 000000bc`984fcdf0 00007ff6`4baa2e9f cm3!RTOS__Crash+0x48 [C:\s\cm3\m3-libs\m3core\src\runtime\WIN32\RTOS.m3 @ 27] 11 000000bc`984fce40 00007ff6`4bad0b4f cm3!RTProcess__Crash+0x6f [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTProcess.m3 @ 66] 12 000000bc`984fce80 00007ff6`4bad0780 cm3!RTError__EndError+0x3f [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTError.m3 @ 119] 13 000000bc`984fcec0 00007ff6`4bae8cd7 cm3!RTError__MsgS+0xa0 [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTError.m3 @ 41] 14 000000bc`984fcf00 00007ff6`4bae88de cm3!RTException__Crash+0x317 [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 81] 15 000000bc`984fcf90 00007ff6`4bae87cb cm3!RTException__DefaultBackstop+0xce [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 39] 16 000000bc`984fd000 00007ff6`4bae90ca cm3!RTException__InvokeBackstop+0x3b [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 25] 17 000000bc`984fd040 00007ff6`4bae89aa cm3!RTException__Raise+0x9a [C:\s\cm3\m3-libs\m3core\src\runtime\ex_frame\RTExFrame.m3 @ 90] 18 000000bc`984fd0a0 00007ff6`4bae87cb cm3!RTException__DefaultBackstop+0x19a [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 49] 19 000000bc`984fd110 00007ff6`4bae90ca cm3!RTException__InvokeBackstop+0x3b [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 25] 1a 000000bc`984fd150 00007ff6`4babb4fe cm3!RTException__Raise+0x9a [C:\s\cm3\m3-libs\m3core\src\runtime\ex_frame\RTExFrame.m3 @ 90] 1b 000000bc`984fd1b0 00007ff6`4bae8f4a cm3!RTHooks__ReportFault+0xfe [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTHooks.m3 @ 112] 1c 000000bc`984fd250 00007ff6`4bae8dc4 cm3!M_RTOS_L_15_CRASH+0x1a [C:\s\cm3\m3-libs\m3core\AMD64_NT\RTOS.m3.c @ 544] 1d 000000bc`984fd280 00007ff6`4bae8e4a cm3!RTOS__Exit+0x44 [C:\s\cm3\m3-libs\m3core\src\runtime\WIN32\RTOS.m3 @ 16] 1e 000000bc`984fd2c0 00007ff6`4baa2e9f cm3!RTOS__Crash+0x6a [C:\s\cm3\m3-libs\m3core\src\runtime\WIN32\RTOS.m3 @ 30] 1f 000000bc`984fd310 00007ff6`4bad0b4f cm3!RTProcess__Crash+0x6f [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTProcess.m3 @ 66] 20 000000bc`984fd350 00007ff6`4bad0780 cm3!RTError__EndError+0x3f [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTError.m3 @ 119] 21 000000bc`984fd390 00007ff6`4bae8cd7 cm3!RTError__MsgS+0xa0 [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTError.m3 @ 41] 22 000000bc`984fd3d0 00007ff6`4bae88de cm3!RTException__Crash+0x317 [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 81] 23 000000bc`984fd460 00007ff6`4bae87cb cm3!RTException__DefaultBackstop+0xce [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 39] 24 000000bc`984fd4d0 00007ff6`4bae90ca cm3!RTException__InvokeBackstop+0x3b [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 25] 25 000000bc`984fd510 00007ff6`4bae89aa cm3!RTException__Raise+0x9a [C:\s\cm3\m3-libs\m3core\src\runtime\ex_frame\RTExFrame.m3 @ 90] 26 000000bc`984fd570 00007ff6`4bae87cb cm3!RTException__DefaultBackstop+0x19a [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 49] 27 000000bc`984fd5e0 00007ff6`4bae90ca cm3!RTException__InvokeBackstop+0x3b [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 25] 28 000000bc`984fd620 00007ff6`4babb4fe cm3!RTException__Raise+0x9a [C:\s\cm3\m3-libs\m3core\src\runtime\ex_frame\RTExFrame.m3 @ 90] 29 000000bc`984fd680 00007ff6`4b71aeca cm3!RTHooks__ReportFault+0xfe [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTHooks.m3 @ 112] 2a 000000bc`984fd720 00007ff6`4b7050f7 cm3!M_M3C_L_166_CRASH+0x1a [C:\s\cm3\m3-sys\m3back\AMD64_NT\M3C.m3.c @ 31094] 2b 000000bc`984fd750 00007ff6`4b7038d4 cm3!M3C__TIntLiteral+0x5a7 [C:\s\cm3\m3-sys\m3back\src\M3C.m3 @ 4830] The first suspend is here: 3:013> k # Child-SP RetAddr Call Site 00 000000d3`6839d2d8 00007ff6`4bae8e28 cm3!RTThread__SuspendOthers [C:\s\cm3\m3-libs\m3core\src\thread\WIN32\ThreadWin32.m3 @ 793] 01 000000d3`6839d2e0 00007ff6`4baa2e9f cm3!RTOS__Crash+0x48 [C:\s\cm3\m3-libs\m3core\src\runtime\WIN32\RTOS.m3 @ 27] 02 000000d3`6839d330 00007ff6`4bad0b4f cm3!RTProcess__Crash+0x6f [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTProcess.m3 @ 66] 03 000000d3`6839d370 00007ff6`4bad0780 cm3!RTError__EndError+0x3f [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTError.m3 @ 119] 04 000000d3`6839d3b0 00007ff6`4bae8cd7 cm3!RTError__MsgS+0xa0 [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTError.m3 @ 41] 05 000000d3`6839d3f0 00007ff6`4bae88de cm3!RTException__Crash+0x317 [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 81] 06 000000d3`6839d480 00007ff6`4bae87cb cm3!RTException__DefaultBackstop+0xce [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 39] 07 000000d3`6839d4f0 00007ff6`4bae90ca cm3!RTException__InvokeBackstop+0x3b [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 25] 08 000000d3`6839d530 00007ff6`4bae89aa cm3!RTException__Raise+0x9a [C:\s\cm3\m3-libs\m3core\src\runtime\ex_frame\RTExFrame.m3 @ 90] 09 000000d3`6839d590 00007ff6`4bae87cb cm3!RTException__DefaultBackstop+0x19a [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 49] 0a 000000d3`6839d600 00007ff6`4bae90ca cm3!RTException__InvokeBackstop+0x3b [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 25] 0b 000000d3`6839d640 00007ff6`4babb4fe cm3!RTException__Raise+0x9a [C:\s\cm3\m3-libs\m3core\src\runtime\ex_frame\RTExFrame.m3 @ 90] 0c 000000d3`6839d6a0 00007ff6`4b71aeca cm3!RTHooks__ReportFault+0xfe [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTHooks.m3 @ 112] 0d 000000d3`6839d740 00007ff6`4b7050f7 cm3!M_M3C_L_166_CRASH+0x1a [C:\s\cm3\m3-sys\m3back\AMD64_NT\M3C.m3.c @ 31094] 0e 000000d3`6839d770 00007ff6`4b7038d4 cm3!M3C__TIntLiteral+0x5a7 [C:\s\cm3\m3-sys\m3back\src\M3C.m3 @ 4830] and then.."funny".. PROCEDURE Crash () = CONST Magic = 1 * ADRSIZE (INTEGER); (* == offset of "fp" in this frame *) VAR fp: ADDRESS := ADR (fp) + Magic; (* == my frame pointer *) BEGIN IF WinBase.IsDebuggerPresent () # 0 THEN WinBase.DebugBreak (); END; RTThread.SuspendOthers (); <== probably the first suspend RTMachInfo.DumpStack (LOOPHOLE (Crash, ADDRESS), fp); RTSignal.RestoreHandlers (); (* so we really do crash... *) Exit (-1); <== it gets here END Crash; PROCEDURE Exit (n: INTEGER) = <== and then here BEGIN WinBase.ExitProcess (n); END Exit; and it is our recent friend, a range fault on the exit code. 0f 000000d3`6839d2a0 00007ff6`4bae8e4a cm3!RTOS__Exit( int64 n_L_17 = 0n-1)+0x44 [C:\s\cm3\m3-libs\m3core\src\runtime\WIN32\RTOS.m3 @ 16] 3:013> u cm3!RTOS__Exit cm3!RTOS__Exit [C:\s\cm3\m3-libs\m3core\src\runtime\WIN32\RTOS.m3 @ 18]: 00007ff6`4bae8d80 48894c2408 mov qword ptr [rsp+8],rcx 00007ff6`4bae8d85 4883ec38 sub rsp,38h 00007ff6`4bae8d89 48c744242000000000 mov qword ptr [rsp+20h],0 00007ff6`4bae8d92 488d442428 lea rax,[rsp+28h] 00007ff6`4bae8d97 4889442428 mov qword ptr [rsp+28h],rax 00007ff6`4bae8d9c 488b442440 mov rax,qword ptr [rsp+40h] 00007ff6`4bae8da1 4889442420 mov qword ptr [rsp+20h],rax 00007ff6`4bae8da6 48837c242000 cmp qword ptr [rsp+20h],0 3:013> u cm3!RTOS__Exit+0x2c [C:\s\cm3\m3-libs\m3core\src\runtime\WIN32\RTOS.m3 @ 16]: 00007ff6`4bae8dac 7c0c jl cm3!RTOS__Exit+0x3a (00007ff6`4bae8dba) 00007ff6`4bae8dae b8ffffffff mov eax,0FFFFFFFFh 00007ff6`4bae8db3 4839442420 cmp qword ptr [rsp+20h],rax 00007ff6`4bae8db8 7e0a jle cm3!RTOS__Exit+0x44 (00007ff6`4bae8dc4) 00007ff6`4bae8dba b901020000 mov ecx,201h 00007ff6`4bae8dbf e86c010000 call cm3!M_RTOS_L_15_CRASH (00007ff6`4bae8f30) <== here 00007ff6`4bae8dc4 8b4c2420 mov ecx,dword ptr [rsp+20h] C:\s\cm3\m3-libs\m3core\src\win32\WinBase.i3(1231):<*EXTERNAL ExitProcess:WINAPI*> C:\s\cm3\m3-libs\m3core\src\win32\WinBase.i3(1232):PROCEDURE ExitProcess (uExitCode: UINT32); Voila. ExitProcess is declared as taking an unsigned integer but we pass negative. So again I think we are being somehow overzealous regarding integer ranges. I mean, I get, that quality is important and this seems correct, based on some simple principles, but the result seems very unsatifactory. On the 32bit system this is Word.T and you can pass any INTEGER value, there are no checks I guess, and it works. But the extension to a 64bit system adds checks and not all INTEGER values are valid, not even ones that fit in 32bits like -1. Would it make sense to declare a type with the "1.5" range -2^31..2^32? Again, I am tempted to change to plain 64bit INTEGER. But that changes e.g. the type of taking the address. Pass any value that fits in a register, with the understanding, perhaps not known, that the upper 32bits are silently ignored??? I realize is an exit upon an assertion failure, so it doesn't really matter, in this case, but Exit(-1) imho should be portable between Win32 and Win64. I know I could say Exit(16_ffffffff) or have a wrapper that does Word.And(Last(UINT32)) but I don't think these should be needed. -1 should be portable between 32bit and 64bit. Please help me to understand and advise what to do? The nested suspend should probably be relaxed somehow too? - Jay ________________________________ From: M3devel on behalf of Jay K Sent: Thursday, February 25, 2021 4:48 AM To: m3devel Subject: [M3devel] win32 <* ASSERT suspend_cnt = 0 *> ? Today I ran: for /f %a in (targets.txt) do .\boot1.py %a c It worked a lot, and then a lot of: *** *** runtime error: *** <*ASSERT*> failed. *** file "..\src\thread\WIN32\ThreadWin32.m3", line 798 *** which is here: PROCEDURE SuspendOthers () = (* LL=0. Always bracketed with ResumeOthers which releases "activeLock". *) VAR me: Activation; act: Activation; retry: BOOLEAN; BEGIN EnterCriticalSection(ADR(activeLock)); <* ASSERT suspend_cnt = 0 *> <--- INC (suspend_cnt); IF suspend_cnt # 1 THEN RETURN END; any ideas? This is AMD64_NT. I'll try to reproduce it under a debugger. The code looks a little odd, in that it seems prepared for the assertion failure. Thank you, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Thu Feb 25 08:10:00 2021 From: jayk123 at hotmail.com (Jay K) Date: Thu, 25 Feb 2021 07:10:00 +0000 Subject: [M3devel] win32 parallel back race Message-ID: I think this explains the race. quake: proc compile_c_ms(source, object, options, optimize, debug) is . . % Visual C++ always echos source file names as they are compiled. % This runs afoul of the goals of reducing the output of building. % Therefore, redirect to a file and only be noisy upon errors. local Listing = "_m3.lst" if defined("pos") Listing = Path_GetBase (source) & ".lst" end local readonly Command = ["cl.exe", escape(subst_chars(args, "\\", "/")), "-c", escape(source), "-Fo" & object] local ret = try_exec("@" & Command, ">", Listing) if not equal(ret, 0) and equal(source, "_m3main.c") % for _m3main.c, try also as C instead of C++ for older cm3 ret = try_exec("@" & Command, "-TC >", Listing) end if not equal (ret, 0) write (Command & CR) if defined ("xxfs_contents") % fs_contents requires newer tools write (fs_contents (Listing)) else exec ("@type", Listing) % only one case to test end end return ret proc Path_GetBase (a) is a = Path_GetLastElement (a) local b = pos (a, ".") if not equal (b, "-1") a = sub (a, 0, b) end return a end \tlist cmd | findstr /i cmdl CmdLine: "C:\WINDOWS\system32\cmd.exe" /c cl.exe -nologo -DWIN32 -Zl -Z7 -MT -Oi -c CG.m3.c -FoCG.mo > CG.lst so e.g. CG.i3 and CG.m3 will write to CG.lst. I'll change it to CG.i3.lst I guess. It is also unfortunate to even run cmd there. An extra process. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From vvm at tut.by Thu Feb 25 10:12:49 2021 From: vvm at tut.by (vvm at tut.by) Date: Thu, 25 Feb 2021 12:12:49 +0300 Subject: [M3devel] 1) Disable RTThread.SuspendOthers and RTMachInfo.DumpStack 2) call Exit (4000) with not-negative ( positive) error code number Re: win32 <* ASSERT suspend_cnt = 0 *> ? In-Reply-To: References: Message-ID: <3989261614243168@mail.yandex.by> An HTML attachment was scrubbed... URL: From vvm at tut.by Thu Feb 25 10:50:07 2021 From: vvm at tut.by (vvm at tut.by) Date: Thu, 25 Feb 2021 12:50:07 +0300 Subject: [M3devel] win32 <* ASSERT suspend_cnt = 0 *> ? another int32 vs. uint32 on win64 problem In-Reply-To: References: Message-ID: <4272181614246010@mail.yandex.by> An HTML attachment was scrubbed... URL: From vvm at tut.by Thu Feb 25 10:56:56 2021 From: vvm at tut.by (vvm at tut.by) Date: Thu, 25 Feb 2021 12:56:56 +0300 Subject: [M3devel] Grisu problems In-Reply-To: References: <8882d3ad-b0ac-1fc6-99ff-338e4a16676c@lcwb.coop> , Message-ID: <1013361614246850@mail.yandex.by> An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Thu Feb 25 14:11:38 2021 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Thu, 25 Feb 2021 08:11:38 -0500 Subject: [M3devel] Grisu problems In-Reply-To: References: Message-ID: <20210225131137.5j6qmqnugonzgjil@topoi.pooq.com> On Wed, Feb 24, 2021 at 12:00:56PM +0000, Jay K wrote: > Folks, this Grisu thing has been unusually problematic. > It definitely fails with the C backend, and I'm not sure, maybe with the NT386 integrated backend. > I realize it could be/likely-is bugs in those backends, but they do manage to compile a lot else. > Maybe someone can investigate? > For now I've selectively disabled it, i.e. for Win32 and shortly for the C backend, sorry. > I want to move on to other things before investigating this. > > -> linking shobjcodegen > g++ -gstabs+ -m64 -fPIC -g -c -xc++ _m3main.c -o _m3main.o > > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "../src/float/Common/grisu/IEEE.m3", line 155 > *** > > More so though, I suggest all endian-specific code be in C or C++..not because Modula-3 cannot do it, but in order to get towards an endian-independent distribution format. > > Perhaps also floating point formating should be left to sprintf? > (Caveat that Win32 sprintf("%f") does a heap allocation, I think, ouch.) Not clear what you mean here. Doesn't sprintf require that its first argument is a pointer to a string where the results are to be stored? I doubt that you'd want that to be the format string. I can't see any reason for sprintf to do a heap allocation. I can see many ways for it to go wring if its arguments aren't just so. There's also snprintf, which is presumably safer. -- hendrik From rodney_bates at lcwb.coop Thu Feb 25 17:16:48 2021 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 25 Feb 2021 10:16:48 -0600 Subject: [M3devel] win32 <* ASSERT suspend_cnt = 0 *> ? another int32 vs. uint32 on win64 problem In-Reply-To: References: Message-ID: <73bec3db-45d8-b6d2-d06e-970a974b389f@lcwb.coop> On 2/24/21 11:37 PM, Jay K wrote: > Ok it seems like a bug in reporting of assertion failures. > > The repro is: > > \python27\python boot1.py PA32_HPUX c > > or > > \bin\amd64\windbg /g /G /o \python27\python boot1.py PA32_HPUX c > > which its an assertion failure in the C backend, I will look into. > > ? ? IF WinBase.IsDebuggerPresent () # 0 THEN > ? ? ? WinBase.DebugBreak (); > ? ? END; > > 3:013> k > ?# Child-SP ? ? ? ? ?RetAddr ? ? ? ? ? ? ? Call Site > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?KERNELBASE!DebugBreak > 02 000000bc`984fd2c0 00007ff6`4baa2e9f ? ? cm3!RTOS__Crash+0x43 [C:\s\cm3\m3-libs\m3core\src\runtime\WIN32\RTOS.m3 @ 26] > 03 000000bc`984fd310 00007ff6`4bad0b4f ? ? cm3!RTProcess__Crash+0x6f [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTProcess.m3 @ 66] > 04 000000bc`984fd350 00007ff6`4bad0780 ? ? cm3!RTError__EndError+0x3f [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTError.m3 @ 119] > 05 000000bc`984fd390 00007ff6`4bae8cd7 ? ? cm3!RTError__MsgS+0xa0 [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTError.m3 @ 41] > 06 000000bc`984fd3d0 00007ff6`4bae88de ? ? cm3!RTException__Crash+0x317 [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 81] > 07 000000bc`984fd460 00007ff6`4bae87cb ? ? cm3!RTException__DefaultBackstop+0xce [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 39] > 08 000000bc`984fd4d0 00007ff6`4bae90ca ? ? cm3!RTException__InvokeBackstop+0x3b [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 25] > 09 000000bc`984fd510 00007ff6`4bae89aa ? ? cm3!RTException__Raise+0x9a [C:\s\cm3\m3-libs\m3core\src\runtime\ex_frame\RTExFrame.m3 @ 90] > 0a 000000bc`984fd570 00007ff6`4bae87cb ? ? cm3!RTException__DefaultBackstop+0x19a [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 49] > 0b 000000bc`984fd5e0 00007ff6`4bae90ca ? ? cm3!RTException__InvokeBackstop+0x3b [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 25] > 0c 000000bc`984fd620 00007ff6`4babb4fe ? ? cm3!RTException__Raise+0x9a [C:\s\cm3\m3-libs\m3core\src\runtime\ex_frame\RTExFrame.m3 @ 90] > 0d 000000bc`984fd680 00007ff6`4b71aeca ? ? cm3!RTHooks__ReportFault+0xfe [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTHooks.m3 @ 112] > 0e 000000bc`984fd720 00007ff6`4b7050f7 ? ? cm3!M_M3C_L_166_CRASH+0x1a [C:\s\cm3\m3-sys\m3back\AMD64_NT\M3C.m3.c @ 31094] > > C backend assertion failure here: > > 0f 000000bc`984fd750 00007ff6`4b7038d4 ? ? cm3!M3C__TIntLiteral+0x5a7 [C:\s\cm3\m3-sys\m3back\src\M3C.m3 @ 4830] > 10 000000bc`984fd800 00007ff6`4b703997 ? ? cm3!M3C__init_int+0x2b4 [C:\s\cm3\m3-sys\m3back\src\M3C.m3 @ 4658] > 11 000000bc`984fd8b0 00007ff6`4ba0b759 ? ? cm3!M3C__Segments_init_int+0x97 [C:\s\cm3\m3-sys\m3back\src\M3C.m3 @ 4668] > 12 000000bc`984fd8f0 00007ff6`4ba10079 ? ? cm3!M3CG_MultiPass__replay_init_int+0x89 [C:\s\cm3\m3-sys\m3middle\src\M3CG_MultiPass.m3 @ 1234] > 13 000000bc`984fd940 00007ff6`4b6f285c ? ? cm3!M3CG_MultiPass__Replay+0x649 [C:\s\cm3\m3-sys\m3middle\src\M3CG_MultiPass.m3 @ 250] > 14 000000bc`984fda30 00007ff6`4ba1d983 ? ? cm3!M3C__multipass_end_unit+0x7ac [C:\s\cm3\m3-sys\m3back\src\M3C.m3 @ 2374] > 15 000000bc`984fdb30 00007ff6`4b84174d ? ? cm3!M3CG_Check__end_unit+0x113 [C:\s\cm3\m3-sys\m3middle\src\M3CG_Check.m3 @ 365] > 16 000000bc`984fdba0 00007ff6`4b7f77c1 ? ? cm3!CG__End_unit+0x11d [C:\s\cm3\m3-sys\m3front\src\misc\CG.m3 @ 192] > 17 000000bc`984fdbf0 00007ff6`4b7dea9c ? ? cm3!Module__Compile+0x511 [C:\s\cm3\m3-sys\m3front\src\values\Module.m3 @ 931] > 18 000000bc`984fdc80 00007ff6`4b7ddace ? ? cm3!M3Front__DoCompile+0xb3c [C:\s\cm3\m3-sys\m3front\src\misc\M3Front.m3 @ 220] > 19 000000bc`984fddb0 00007ff6`4b6b2472 ? ? cm3!M3Front__Compile+0x32e [C:\s\cm3\m3-sys\m3front\src\misc\M3Front.m3 @ 67] > 1a 000000bc`984fde50 00007ff6`4b6b0186 ? ? cm3!Builder__RunM3Front+0x6c2 [C:\s\cm3\m3-sys\cm3\src\Builder.m3 @ 1972] > 1b 000000bc`984fdf10 00007ff6`4b6af0ab ? ? cm3!Builder__PushOneM3+0x816 [C:\s\cm3\m3-sys\cm3\src\Builder.m3 @ 1618] > 1c 000000bc`984fe180 00007ff6`4b6ac058 ? ? cm3!Builder__CompileM3+0x33b [C:\s\cm3\m3-sys\cm3\src\Builder.m3 @ 1407] > 1d 000000bc`984fe1e0 00007ff6`4b6b2e8b ? ? cm3!Builder__CompileOne+0x2a8 [C:\s\cm3\m3-sys\cm3\src\Builder.m3 @ 1102] > 1e 000000bc`984fe290 00007ff6`4b6b2279 ? ? cm3!Builder__Pass0_CheckImports+0x16b [C:\s\cm3\m3-sys\cm3\src\Builder.m3 @ 2017] > 1f 000000bc`984fe2f0 00007ff6`4b6b0186 ? ? cm3!Builder__RunM3Front+0x4c9 [C:\s\cm3\m3-sys\cm3\src\Builder.m3 @ 1957] > 20 000000bc`984fe3b0 00007ff6`4b6af0ab ? ? cm3!Builder__PushOneM3+0x816 [C:\s\cm3\m3-sys\cm3\src\Builder.m3 @ 1618] > 21 000000bc`984fe620 00007ff6`4b6ac058 ? ? cm3!Builder__CompileM3+0x33b [C:\s\cm3\m3-sys\cm3\src\Builder.m3 @ 1407] > 22 000000bc`984fe680 00007ff6`4b6ab958 ? ? cm3!Builder__CompileOne+0x2a8 [C:\s\cm3\m3-sys\cm3\src\Builder.m3 @ 1102] > 23 000000bc`984fe730 00007ff6`4b6a50b2 ? ? cm3!Builder__CompileEverything+0x2b8 [C:\s\cm3\m3-sys\cm3\src\Builder.m3 @ 1047] > 24 000000bc`984fe930 00007ff6`4b6a2df8 ? ? cm3!Builder__CompileUnits+0x1222 [C:\s\cm3\m3-sys\cm3\src\Builder.m3 @ 359] > 25 000000bc`984fea20 00007ff6`4b6ccf57 ? ? cm3!Builder__BuildLib+0x58 [C:\s\cm3\m3-sys\cm3\src\Builder.m3 @ 40] > 26 000000bc`984fea80 00007ff6`4b7b538c ? ? cm3!M3Build__DoLibrary+0x227 [C:\s\cm3\m3-sys\cm3\src\M3Build.m3 @ 1466] > 27 000000bc`984feb70 00007ff6`4b7b3b22 ? ? cm3!QMachine__DoCall+0x80c [C:\s\cm3\m3-sys\m3quake\src\QMachine.m3 @ 547] > 28 000000bc`984fec50 00007ff6`4b7c0289 ? ? cm3!QMachine__Eval+0x2152 [C:\s\cm3\m3-sys\m3quake\src\QMachine.m3 @ 422] > 29 000000bc`984feec0 00007ff6`4b7c000a ? ? cm3!QMachine__IncludeFile+0x269 [C:\s\cm3\m3-sys\m3quake\src\QMachine.m3 @ 1774] > 2a 000000bc`984ff0c0 00007ff6`4b6c6a6d ? ? cm3!QMachine__Include+0x2a [C:\s\cm3\m3-sys\m3quake\src\QMachine.m3 @ 1745] > 2b 000000bc`984ff100 00007ff6`4b6c97dd ? ? cm3!M3Build__Include+0xfd [C:\s\cm3\m3-sys\cm3\src\M3Build.m3 @ 679] > 2c 000000bc`984ff1a0 00007ff6`4b7b538c ? ? cm3!M3Build__DoIncludeDir+0xfd [C:\s\cm3\m3-sys\cm3\src\M3Build.m3 @ 1055] > 2d 000000bc`984ff210 00007ff6`4b7b3b22 ? ? cm3!QMachine__DoCall+0x80c [C:\s\cm3\m3-sys\m3quake\src\QMachine.m3 @ 547] > 2e 000000bc`984ff2f0 00007ff6`4b7b19ba ? ? cm3!QMachine__Eval+0x2152 [C:\s\cm3\m3-sys\m3quake\src\QMachine.m3 @ 422] > 2f 000000bc`984ff560 00007ff6`4b7cc3fd ? ? cm3!QMachine__Evaluate+0x7a [C:\s\cm3\m3-sys\m3quake\src\QMachine.m3 @ 166] > 30 000000bc`984ff5a0 00007ff6`4b6c408b ? ? cm3!Quake__Run+0xdd [C:\s\cm3\m3-sys\m3quake\src\Quake.m3 @ 20] > 31 000000bc`984ff600 00007ff6`4b6e5818 ? ? cm3!M3Build__Run+0x11b [C:\s\cm3\m3-sys\cm3\src\M3Build.m3 @ 243] > 32 000000bc`984ff640 00007ff6`4b6e4a02 ? ? cm3!Main__DoIt+0xd88 [C:\s\cm3\m3-sys\cm3\src\Main.m3 @ 117] > 33 000000bc`984ff9e0 00007ff6`4baa1ab7 ? ? cm3!Main_M3+0x22 [C:\s\cm3\m3-sys\cm3\src\Main.m3 @ 231] > 34 000000bc`984ffa20 00007ff6`4baa1d3b ? ? cm3!RTLinker__RunMainBody+0x3e7 [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTLinker.m3 @ 408] > 35 000000bc`984ffac0 00007ff6`4baa14b8 ? ? cm3!RTLinker__AddUnitI+0x11b [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTLinker.m3 @ 116] > 36 000000bc`984ffb00 00007ff6`4b6a1038 ? ? cm3!RTLinker__AddUnit+0x118 [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTLinker.m3 @ 125] > 37 000000bc`984ffb60 00007ff6`4bb12974 ? ? cm3!main+0x38 [C:\s\cm3\m3-sys\cm3\AMD64_NT\_m3main.c @ 23] > 38 (Inline Function) --------`-------- ? ? cm3!invoke_main+0x22 [d:\agent\_work\5\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl @ 78] > > > which if you go past the breakpoint, which simulates no debugger, it hits the assertion failure > I reported: > > 3:013> k > > . 13 ?Id: a35c.8d38 Suspend: 1 Teb: 000000bc`982c8000 Unfrozen > ?# Child-SP ? ? ? ? ?RetAddr ? ? ? ? ? ? ? Call Site > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?KERNELBASE!DebugBreak > 02 000000bc`984fc8f0 00007ff6`4baa2e9f ? ? cm3!RTOS__Crash+0x43 [C:\s\cm3\m3-libs\m3core\src\runtime\WIN32\RTOS.m3 @ 26] > 03 000000bc`984fc940 00007ff6`4bad0b4f ? ? cm3!RTProcess__Crash+0x6f [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTProcess.m3 @ 66] > 04 000000bc`984fc980 00007ff6`4bad0780 ? ? cm3!RTError__EndError+0x3f [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTError.m3 @ 119] > 05 000000bc`984fc9c0 00007ff6`4bae8cd7 ? ? cm3!RTError__MsgS+0xa0 [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTError.m3 @ 41] > 06 000000bc`984fca00 00007ff6`4bae88de ? ? cm3!RTException__Crash+0x317 [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 81] > 07 000000bc`984fca90 00007ff6`4bae87cb ? ? cm3!RTException__DefaultBackstop+0xce [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 39] > 08 000000bc`984fcb00 00007ff6`4bae90ca ? ? cm3!RTException__InvokeBackstop+0x3b [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 25] > 09 000000bc`984fcb40 00007ff6`4bae89aa ? ? cm3!RTException__Raise+0x9a [C:\s\cm3\m3-libs\m3core\src\runtime\ex_frame\RTExFrame.m3 @ 90] > 0a 000000bc`984fcba0 00007ff6`4bae87cb ? ? cm3!RTException__DefaultBackstop+0x19a [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 49] > 0b 000000bc`984fcc10 00007ff6`4bae90ca ? ? cm3!RTException__InvokeBackstop+0x3b [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 25] > 0c 000000bc`984fcc50 00007ff6`4babb4fe ? ? cm3!RTException__Raise+0x9a [C:\s\cm3\m3-libs\m3core\src\runtime\ex_frame\RTExFrame.m3 @ 90] > 0d 000000bc`984fccb0 00007ff6`4bac003a ? ? cm3!RTHooks__ReportFault+0xfe [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTHooks.m3 @ 112] > > The ThreadWin32 assertion failure. > > 0e 000000bc`984fcd50 00007ff6`4babbf09 ? ? cm3!M_ThreadWin32_L_137_CRASH+0x1a [C:\s\cm3\m3-libs\m3core\AMD64_NT\ThreadWin32.m3.c @ 4356] > 0f 000000bc`984fcd80 00007ff6`4bae8e28 ? ? cm3!RTThread__SuspendOthers+0x89 [C:\s\cm3\m3-libs\m3core\src\thread\WIN32\ThreadWin32.m3 @ 799] > 10 000000bc`984fcdf0 00007ff6`4baa2e9f ? ? cm3!RTOS__Crash+0x48 [C:\s\cm3\m3-libs\m3core\src\runtime\WIN32\RTOS.m3 @ 27] > 11 000000bc`984fce40 00007ff6`4bad0b4f ? ? cm3!RTProcess__Crash+0x6f [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTProcess.m3 @ 66] > 12 000000bc`984fce80 00007ff6`4bad0780 ? ? cm3!RTError__EndError+0x3f [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTError.m3 @ 119] > 13 000000bc`984fcec0 00007ff6`4bae8cd7 ? ? cm3!RTError__MsgS+0xa0 [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTError.m3 @ 41] > 14 000000bc`984fcf00 00007ff6`4bae88de ? ? cm3!RTException__Crash+0x317 [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 81] > 15 000000bc`984fcf90 00007ff6`4bae87cb ? ? cm3!RTException__DefaultBackstop+0xce [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 39] > 16 000000bc`984fd000 00007ff6`4bae90ca ? ? cm3!RTException__InvokeBackstop+0x3b [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 25] > 17 000000bc`984fd040 00007ff6`4bae89aa ? ? cm3!RTException__Raise+0x9a [C:\s\cm3\m3-libs\m3core\src\runtime\ex_frame\RTExFrame.m3 @ 90] > 18 000000bc`984fd0a0 00007ff6`4bae87cb ? ? cm3!RTException__DefaultBackstop+0x19a [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 49] > 19 000000bc`984fd110 00007ff6`4bae90ca ? ? cm3!RTException__InvokeBackstop+0x3b [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 25] > 1a 000000bc`984fd150 00007ff6`4babb4fe ? ? cm3!RTException__Raise+0x9a [C:\s\cm3\m3-libs\m3core\src\runtime\ex_frame\RTExFrame.m3 @ 90] > 1b 000000bc`984fd1b0 00007ff6`4bae8f4a ? ? cm3!RTHooks__ReportFault+0xfe [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTHooks.m3 @ 112] > 1c 000000bc`984fd250 00007ff6`4bae8dc4 ? ? cm3!M_RTOS_L_15_CRASH+0x1a [C:\s\cm3\m3-libs\m3core\AMD64_NT\RTOS.m3.c @ 544] > 1d 000000bc`984fd280 00007ff6`4bae8e4a ? ? cm3!RTOS__Exit+0x44 [C:\s\cm3\m3-libs\m3core\src\runtime\WIN32\RTOS.m3 @ 16] > 1e 000000bc`984fd2c0 00007ff6`4baa2e9f ? ? cm3!RTOS__Crash+0x6a [C:\s\cm3\m3-libs\m3core\src\runtime\WIN32\RTOS.m3 @ 30] > 1f 000000bc`984fd310 00007ff6`4bad0b4f ? ? cm3!RTProcess__Crash+0x6f [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTProcess.m3 @ 66] > 20 000000bc`984fd350 00007ff6`4bad0780 ? ? cm3!RTError__EndError+0x3f [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTError.m3 @ 119] > 21 000000bc`984fd390 00007ff6`4bae8cd7 ? ? cm3!RTError__MsgS+0xa0 [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTError.m3 @ 41] > 22 000000bc`984fd3d0 00007ff6`4bae88de ? ? cm3!RTException__Crash+0x317 [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 81] > 23 000000bc`984fd460 00007ff6`4bae87cb ? ? cm3!RTException__DefaultBackstop+0xce [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 39] > 24 000000bc`984fd4d0 00007ff6`4bae90ca ? ? cm3!RTException__InvokeBackstop+0x3b [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 25] > 25 000000bc`984fd510 00007ff6`4bae89aa ? ? cm3!RTException__Raise+0x9a [C:\s\cm3\m3-libs\m3core\src\runtime\ex_frame\RTExFrame.m3 @ 90] > 26 000000bc`984fd570 00007ff6`4bae87cb ? ? cm3!RTException__DefaultBackstop+0x19a [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 49] > 27 000000bc`984fd5e0 00007ff6`4bae90ca ? ? cm3!RTException__InvokeBackstop+0x3b [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 25] > 28 000000bc`984fd620 00007ff6`4babb4fe ? ? cm3!RTException__Raise+0x9a [C:\s\cm3\m3-libs\m3core\src\runtime\ex_frame\RTExFrame.m3 @ 90] > 29 000000bc`984fd680 00007ff6`4b71aeca ? ? cm3!RTHooks__ReportFault+0xfe [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTHooks.m3 @ 112] > 2a 000000bc`984fd720 00007ff6`4b7050f7 ? ? cm3!M_M3C_L_166_CRASH+0x1a [C:\s\cm3\m3-sys\m3back\AMD64_NT\M3C.m3.c @ 31094] > 2b 000000bc`984fd750 00007ff6`4b7038d4 ? ? cm3!M3C__TIntLiteral+0x5a7 [C:\s\cm3\m3-sys\m3back\src\M3C.m3 @ 4830] > > > The first suspend is here: > 3:013> k > ?# Child-SP ? ? ? ? ?RetAddr ? ? ? ? ? ? ? Call Site > 00 000000d3`6839d2d8 00007ff6`4bae8e28 ? ? cm3!RTThread__SuspendOthers [C:\s\cm3\m3-libs\m3core\src\thread\WIN32\ThreadWin32.m3 @ 793] > 01 000000d3`6839d2e0 00007ff6`4baa2e9f ? ? cm3!RTOS__Crash+0x48 [C:\s\cm3\m3-libs\m3core\src\runtime\WIN32\RTOS.m3 @ 27] > 02 000000d3`6839d330 00007ff6`4bad0b4f ? ? cm3!RTProcess__Crash+0x6f [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTProcess.m3 @ 66] > 03 000000d3`6839d370 00007ff6`4bad0780 ? ? cm3!RTError__EndError+0x3f [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTError.m3 @ 119] > 04 000000d3`6839d3b0 00007ff6`4bae8cd7 ? ? cm3!RTError__MsgS+0xa0 [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTError.m3 @ 41] > 05 000000d3`6839d3f0 00007ff6`4bae88de ? ? cm3!RTException__Crash+0x317 [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 81] > 06 000000d3`6839d480 00007ff6`4bae87cb ? ? cm3!RTException__DefaultBackstop+0xce [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 39] > 07 000000d3`6839d4f0 00007ff6`4bae90ca ? ? cm3!RTException__InvokeBackstop+0x3b [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 25] > 08 000000d3`6839d530 00007ff6`4bae89aa ? ? cm3!RTException__Raise+0x9a [C:\s\cm3\m3-libs\m3core\src\runtime\ex_frame\RTExFrame.m3 @ 90] > 09 000000d3`6839d590 00007ff6`4bae87cb ? ? cm3!RTException__DefaultBackstop+0x19a [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 49] > 0a 000000d3`6839d600 00007ff6`4bae90ca ? ? cm3!RTException__InvokeBackstop+0x3b [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 25] > 0b 000000d3`6839d640 00007ff6`4babb4fe ? ? cm3!RTException__Raise+0x9a [C:\s\cm3\m3-libs\m3core\src\runtime\ex_frame\RTExFrame.m3 @ 90] > 0c 000000d3`6839d6a0 00007ff6`4b71aeca ? ? cm3!RTHooks__ReportFault+0xfe [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTHooks.m3 @ 112] > 0d 000000d3`6839d740 00007ff6`4b7050f7 ? ? cm3!M_M3C_L_166_CRASH+0x1a [C:\s\cm3\m3-sys\m3back\AMD64_NT\M3C.m3.c @ 31094] > 0e 000000d3`6839d770 00007ff6`4b7038d4 ? ? cm3!M3C__TIntLiteral+0x5a7 [C:\s\cm3\m3-sys\m3back\src\M3C.m3 @ 4830] > > > and then.."funny".. > > PROCEDURE Crash () = > ? CONST Magic = 1 * ADRSIZE (INTEGER); ?(* == offset of "fp" in this frame *) > ? VAR fp: ADDRESS := ADR (fp) + Magic; ?(* == my frame pointer *) > ? BEGIN > ? ? IF WinBase.IsDebuggerPresent () # 0 THEN > ? ? ? WinBase.DebugBreak (); > ? ? END; > ? ? RTThread.SuspendOthers (); ? ? ? ? ? ? ? ? ? ? ? ? ? ? <== probably the first suspend > ? ? RTMachInfo.DumpStack (LOOPHOLE (Crash, ADDRESS), fp); > ? ? RTSignal.RestoreHandlers (); (* so we really do crash... *) > ? ? Exit (-1); ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? <== it gets here > ? END Crash; > > PROCEDURE Exit (n: INTEGER) = ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?<== and then here > ? BEGIN > ? ? WinBase.ExitProcess (n); > ? END Exit; > > > and it is our recent friend, a range fault on the exit code. > > 0f 000000d3`6839d2a0 00007ff6`4bae8e4a ? ? cm3!RTOS__Exit( > int64 n_L_17 = 0n-1)+0x44 [C:\s\cm3\m3-libs\m3core\src\runtime\WIN32\RTOS.m3 @ 16] > > > 3:013> u cm3!RTOS__Exit > cm3!RTOS__Exit [C:\s\cm3\m3-libs\m3core\src\runtime\WIN32\RTOS.m3 @ 18]: > 00007ff6`4bae8d80 48894c2408 ? ? ?mov ? ? qword ptr [rsp+8],rcx > 00007ff6`4bae8d85 4883ec38 ? ? ? ?sub ? ? rsp,38h > 00007ff6`4bae8d89 48c744242000000000 mov ? qword ptr [rsp+20h],0 > 00007ff6`4bae8d92 488d442428 ? ? ?lea ? ? rax,[rsp+28h] > 00007ff6`4bae8d97 4889442428 ? ? ?mov ? ? qword ptr [rsp+28h],rax > 00007ff6`4bae8d9c 488b442440 ? ? ?mov ? ? rax,qword ptr [rsp+40h] > 00007ff6`4bae8da1 4889442420 ? ? ?mov ? ? qword ptr [rsp+20h],rax > 00007ff6`4bae8da6 48837c242000 ? ?cmp ? ? qword ptr [rsp+20h],0 > 3:013> u > cm3!RTOS__Exit+0x2c [C:\s\cm3\m3-libs\m3core\src\runtime\WIN32\RTOS.m3 @ 16]: > 00007ff6`4bae8dac 7c0c ? ? ? ? ? ?jl ? ? ?cm3!RTOS__Exit+0x3a (00007ff6`4bae8dba) > 00007ff6`4bae8dae b8ffffffff ? ? ?mov ? ? eax,0FFFFFFFFh > 00007ff6`4bae8db3 4839442420 ? ? ?cmp ? ? qword ptr [rsp+20h],rax > 00007ff6`4bae8db8 7e0a ? ? ? ? ? ?jle ? ? cm3!RTOS__Exit+0x44 (00007ff6`4bae8dc4) > 00007ff6`4bae8dba b901020000 ? ? ?mov ? ? ecx,201h > 00007ff6`4bae8dbf e86c010000 ? ? ?call ? ?cm3!M_RTOS_L_15_CRASH (00007ff6`4bae8f30) <== here > 00007ff6`4bae8dc4 8b4c2420 ? ? ? ?mov ? ? ecx,dword ptr [rsp+20h] > > > C:\s\cm3\m3-libs\m3core\src\win32\WinBase.i3(1231):<*EXTERNAL ExitProcess:WINAPI*> > C:\s\cm3\m3-libs\m3core\src\win32\WinBase.i3(1232):PROCEDURE ExitProcess (uExitCode: UINT32); > > Voila. > > ExitProcess is declared as taking an unsigned integer but we pass negative. Well, if a negative value is appropriate here, then the type should not be an unsigned type. Perhaps INT32, or if that is too narrow on 64-bit machines, then INTEGER. Or is it the negative value that is wrong? > > So again I think we are being somehow overzealous regarding integer ranges. > > I mean, I get, that quality is important and this seems correct, based on > some simple principles, but the result seems very unsatifactory. > > > On the 32bit system this is Word.T and you can pass any INTEGER value, there are > no checks I guess, and it works. > > > But the extension to a 64bit system adds checks and not all INTEGER values are valid, > not even ones that fit in 32bits like -1. > > > Would it make sense to declare a type with the "1.5" range -2^31..2^32? > > Again, I am tempted to change to plain 64bit INTEGER. But that changes e.g. > the type of taking the address. > Pass any value that fits in a register, with the understanding, perhaps not known, > that the upper 32bits are silently ignored??? > > I realize is an exit upon an assertion failure, so it doesn't really matter, > in this case, but Exit(-1) imho should be portable between Win32 and Win64. > > I know I could say Exit(16_ffffffff) or have a wrapper that does Word.And(Last(UINT32)) > but I don't think these should be needed. -1 should be portable between 32bit and 64bit. > > Please help me to understand and advise what to do? > > The nested suspend should probably be relaxed somehow too? > > ?- Jay > > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ > *From:* M3devel on behalf of Jay K > *Sent:* Thursday, February 25, 2021 4:48 AM > *To:* m3devel > *Subject:* [M3devel] win32 <* ASSERT suspend_cnt = 0 *> ? > Today I ran: > > for /f %a in (targets.txt) do .\boot1.py %a c > > It worked a lot, and then a lot of: > > > > *** > *** runtime error: > *** ? ?<*ASSERT*> failed. > *** ? ?file "..\src\thread\WIN32\ThreadWin32.m3", line 798 > *** > > > which is here: > > PROCEDURE SuspendOthers () = > ? (* LL=0. Always bracketed with ResumeOthers which releases "activeLock". *) > ? VAR me: Activation; > ? ? ? act: Activation; > ? ? ? retry: BOOLEAN; > ? BEGIN > ? ? EnterCriticalSection(ADR(activeLock)); > > ? ? <* ASSERT suspend_cnt = 0 *> ? <--- > ? ? INC (suspend_cnt); > ? ? IF suspend_cnt # 1 THEN > ? ? ? RETURN > ? ? END; > > > any ideas? > > This is AMD64_NT. > > I'll try to reproduce it under a debugger. > The code looks a little odd, in that it seems prepared for the assertion failure. > > Thank you, > ?- Jay -- Rodney Bates rodney.m.bates at acm.org From jayk123 at hotmail.com Thu Feb 25 18:03:46 2021 From: jayk123 at hotmail.com (Jay K) Date: Thu, 25 Feb 2021 17:03:46 +0000 Subject: [M3devel] Grisu problems In-Reply-To: <20210225131137.5j6qmqnugonzgjil@topoi.pooq.com> References: , <20210225131137.5j6qmqnugonzgjil@topoi.pooq.com> Message-ID: Of course never use regular sprintf. snprintf isn't a good function either. It is probably "unsafe" in that it probably does not always nul terminate, if the string just fits, and probably inefficient in that it probably pads out the output to n (when it does fit). Though the first, worse, problem can be mitigated by zero initializing the buffer and passing buffer size minus 1. At least most of the n functions are bad like that: strncpy, strncat, etc. All bad functions. Along with the non-n functions: strcpy, strcat, also all bad. Besides the inefficiency of strcat, repeated strcat is O(n^2). The standard C library is horrible for strings. I use "sprintf" to refer really to _sprintf_s or _snprintf_s, sorry for the informality. The heap allocation is not for the output. I didn't say that. It is for internal computation. It is unfortunate, but it is allowed to. sprintf need only be thread safe, not reentrant (i.e. heap allocation cannot sprintf). C:\s>type 1.c #include int main() { char buffer[20] = {0}; snprintf(buffer, sizeof(buffer) - 1, "%99e\n", 1.0 / 3.0); printf("%99e\n", 1.0 / 3.0); return 0; } C:\s>cl /Zi 1.c Microsoft (R) C/C++ Optimizing Compiler Version 19.24.28316 for x64 C:\s>\bin\amd64\cdb 1.exe 0:000> bp 1!main 0:000> g 1!main: 0:000> bm ntdll!RtlAllocateHeap 0:000> g 0:000> k Child-SP RetAddr Call Site 00000004`830ff068 00007ff6`c7c944d0 ntdll!RtlAllocateHeap 00000004`830ff070 00007ff6`c7c989ad 1!_malloc_base+0x44 00000004`830ff0a0 00007ff6`c7c72603 1!__acrt_stdio_begin_temporary_buffering_nolock+0x79 (Inline Function) --------`-------- 1!__acrt_stdio_temporary_buffering_guard::{ctor}+0x8 00000004`830ff0d0 00007ff6`c7c6a9ae 1!::operator()+0x3f 00000004`830ff5c0 00007ff6`c7c87815 1!__crt_seh_guarded_call::operator()<, &, >+0x26 (Inline Function) --------`-------- 1!__acrt_lock_stream_and_call+0x41 (Inline Function) --------`-------- 1!common_vfprintf+0x61 00000004`830ff5f0 00007ff6`c7c56c7e 1!__stdio_common_vfprintf+0x85 00000004`830ff660 00007ff6`c7c56ce1 1!_vfprintf_l+0x3e 00000004`830ff6a0 00007ff6`c7c56bf2 1!printf+0x41 00000004`830ff6e0 00007ff6`c7c5712c 1!main+0x62 (Inline Function) --------`-------- 1!invoke_main+0x22 00000004`830ff730 00007ff8`49a67034 1!__scrt_common_main_seh+0x10c 00000004`830ff770 00007ff8`4a8fd241 KERNEL32!BaseThreadInitThunk+0x14 00000004`830ff7a0 00000000`00000000 ntdll!RtlUserThreadStart+0x21 - Jay ________________________________ From: M3devel on behalf of Hendrik Boom Sent: Thursday, February 25, 2021 1:11 PM To: m3devel at elegosoft.com Subject: Re: [M3devel] Grisu problems On Wed, Feb 24, 2021 at 12:00:56PM +0000, Jay K wrote: > Folks, this Grisu thing has been unusually problematic. > It definitely fails with the C backend, and I'm not sure, maybe with the NT386 integrated backend. > I realize it could be/likely-is bugs in those backends, but they do manage to compile a lot else. > Maybe someone can investigate? > For now I've selectively disabled it, i.e. for Win32 and shortly for the C backend, sorry. > I want to move on to other things before investigating this. > > -> linking shobjcodegen > g++ -gstabs+ -m64 -fPIC -g -c -xc++ _m3main.c -o _m3main.o > > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "../src/float/Common/grisu/IEEE.m3", line 155 > *** > > More so though, I suggest all endian-specific code be in C or C++..not because Modula-3 cannot do it, but in order to get towards an endian-independent distribution format. > > Perhaps also floating point formating should be left to sprintf? > (Caveat that Win32 sprintf("%f") does a heap allocation, I think, ouch.) Not clear what you mean here. Doesn't sprintf require that its first argument is a pointer to a string where the results are to be stored? I doubt that you'd want that to be the format string. I can't see any reason for sprintf to do a heap allocation. I can see many ways for it to go wring if its arguments aren't just so. There's also snprintf, which is presumably safer. -- hendrik _______________________________________________ M3devel mailing list M3devel at elegosoft.com https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fm3lists.elegosoft.com%2Fmailman%2Flistinfo%2Fm3devel&data=04%7C01%7C%7Cc6d352c3401f49fadfe208d8d98ef2fb%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637498555290294393%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=R1PCe8FOjezYrAJkwfTyiEFLznBwZW%2FMWi%2BV9YYmGXI%3D&reserved=0 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Thu Feb 25 18:12:44 2021 From: jayk123 at hotmail.com (Jay K) Date: Thu, 25 Feb 2021 17:12:44 +0000 Subject: [M3devel] win32 <* ASSERT suspend_cnt = 0 *> ? another int32 vs. uint32 on win64 problem In-Reply-To: <73bec3db-45d8-b6d2-d06e-970a974b389f@lcwb.coop> References: , <73bec3db-45d8-b6d2-d06e-970a974b389f@lcwb.coop> Message-ID: Neither UINT32 nor INT32 seem sufficient. I assert any 32bit value is ok and the interpretation is up the eventual reciever. Widening it to 64bit INTEGER is probably ok, but risks being wrong depending on how the ABI works. Ok, well, I checked, on NT/amd64, when parameters are smaller than 64bits, and passed on the stack, they still consume 8 bytes, so widening to INTEGER I think is the solution. But, you know, in C++ it is possible at compile time to get the type of a function, the types of its parameters, and do stuff with those types. So it is unfortunate to have to change the signature. But I think that is the solution here, and on some other functions like that networking thing. And again, ignoring this particular function briefly. What if UINT32 was the correct type and we wanted to rule out -1? We can only do that trivially in the 64bit system? Doesn't that seem kinda bad/wrong? 32bit system cannot say TYPE UINT32 = [0...16_FFFFFFFFF]? - Jay ________________________________ From: Rodney M. Bates Sent: Thursday, February 25, 2021 4:16 PM To: Jay K ; m3devel Subject: Re: win32 <* ASSERT suspend_cnt = 0 *> ? another int32 vs. uint32 on win64 problem On 2/24/21 11:37 PM, Jay K wrote: > Ok it seems like a bug in reporting of assertion failures. > > The repro is: > > \python27\python boot1.py PA32_HPUX c > > or > > \bin\amd64\windbg /g /G /o \python27\python boot1.py PA32_HPUX c > > which its an assertion failure in the C backend, I will look into. > > IF WinBase.IsDebuggerPresent () # 0 THEN > WinBase.DebugBreak (); > END; > > 3:013> k > # Child-SP RetAddr Call Site > KERNELBASE!DebugBreak > 02 000000bc`984fd2c0 00007ff6`4baa2e9f cm3!RTOS__Crash+0x43 [C:\s\cm3\m3-libs\m3core\src\runtime\WIN32\RTOS.m3 @ 26] > 03 000000bc`984fd310 00007ff6`4bad0b4f cm3!RTProcess__Crash+0x6f [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTProcess.m3 @ 66] > 04 000000bc`984fd350 00007ff6`4bad0780 cm3!RTError__EndError+0x3f [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTError.m3 @ 119] > 05 000000bc`984fd390 00007ff6`4bae8cd7 cm3!RTError__MsgS+0xa0 [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTError.m3 @ 41] > 06 000000bc`984fd3d0 00007ff6`4bae88de cm3!RTException__Crash+0x317 [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 81] > 07 000000bc`984fd460 00007ff6`4bae87cb cm3!RTException__DefaultBackstop+0xce [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 39] > 08 000000bc`984fd4d0 00007ff6`4bae90ca cm3!RTException__InvokeBackstop+0x3b [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 25] > 09 000000bc`984fd510 00007ff6`4bae89aa cm3!RTException__Raise+0x9a [C:\s\cm3\m3-libs\m3core\src\runtime\ex_frame\RTExFrame.m3 @ 90] > 0a 000000bc`984fd570 00007ff6`4bae87cb cm3!RTException__DefaultBackstop+0x19a [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 49] > 0b 000000bc`984fd5e0 00007ff6`4bae90ca cm3!RTException__InvokeBackstop+0x3b [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 25] > 0c 000000bc`984fd620 00007ff6`4babb4fe cm3!RTException__Raise+0x9a [C:\s\cm3\m3-libs\m3core\src\runtime\ex_frame\RTExFrame.m3 @ 90] > 0d 000000bc`984fd680 00007ff6`4b71aeca cm3!RTHooks__ReportFault+0xfe [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTHooks.m3 @ 112] > 0e 000000bc`984fd720 00007ff6`4b7050f7 cm3!M_M3C_L_166_CRASH+0x1a [C:\s\cm3\m3-sys\m3back\AMD64_NT\M3C.m3.c @ 31094] > > C backend assertion failure here: > > 0f 000000bc`984fd750 00007ff6`4b7038d4 cm3!M3C__TIntLiteral+0x5a7 [C:\s\cm3\m3-sys\m3back\src\M3C.m3 @ 4830] > 10 000000bc`984fd800 00007ff6`4b703997 cm3!M3C__init_int+0x2b4 [C:\s\cm3\m3-sys\m3back\src\M3C.m3 @ 4658] > 11 000000bc`984fd8b0 00007ff6`4ba0b759 cm3!M3C__Segments_init_int+0x97 [C:\s\cm3\m3-sys\m3back\src\M3C.m3 @ 4668] > 12 000000bc`984fd8f0 00007ff6`4ba10079 cm3!M3CG_MultiPass__replay_init_int+0x89 [C:\s\cm3\m3-sys\m3middle\src\M3CG_MultiPass.m3 @ 1234] > 13 000000bc`984fd940 00007ff6`4b6f285c cm3!M3CG_MultiPass__Replay+0x649 [C:\s\cm3\m3-sys\m3middle\src\M3CG_MultiPass.m3 @ 250] > 14 000000bc`984fda30 00007ff6`4ba1d983 cm3!M3C__multipass_end_unit+0x7ac [C:\s\cm3\m3-sys\m3back\src\M3C.m3 @ 2374] > 15 000000bc`984fdb30 00007ff6`4b84174d cm3!M3CG_Check__end_unit+0x113 [C:\s\cm3\m3-sys\m3middle\src\M3CG_Check.m3 @ 365] > 16 000000bc`984fdba0 00007ff6`4b7f77c1 cm3!CG__End_unit+0x11d [C:\s\cm3\m3-sys\m3front\src\misc\CG.m3 @ 192] > 17 000000bc`984fdbf0 00007ff6`4b7dea9c cm3!Module__Compile+0x511 [C:\s\cm3\m3-sys\m3front\src\values\Module.m3 @ 931] > 18 000000bc`984fdc80 00007ff6`4b7ddace cm3!M3Front__DoCompile+0xb3c [C:\s\cm3\m3-sys\m3front\src\misc\M3Front.m3 @ 220] > 19 000000bc`984fddb0 00007ff6`4b6b2472 cm3!M3Front__Compile+0x32e [C:\s\cm3\m3-sys\m3front\src\misc\M3Front.m3 @ 67] > 1a 000000bc`984fde50 00007ff6`4b6b0186 cm3!Builder__RunM3Front+0x6c2 [C:\s\cm3\m3-sys\cm3\src\Builder.m3 @ 1972] > 1b 000000bc`984fdf10 00007ff6`4b6af0ab cm3!Builder__PushOneM3+0x816 [C:\s\cm3\m3-sys\cm3\src\Builder.m3 @ 1618] > 1c 000000bc`984fe180 00007ff6`4b6ac058 cm3!Builder__CompileM3+0x33b [C:\s\cm3\m3-sys\cm3\src\Builder.m3 @ 1407] > 1d 000000bc`984fe1e0 00007ff6`4b6b2e8b cm3!Builder__CompileOne+0x2a8 [C:\s\cm3\m3-sys\cm3\src\Builder.m3 @ 1102] > 1e 000000bc`984fe290 00007ff6`4b6b2279 cm3!Builder__Pass0_CheckImports+0x16b [C:\s\cm3\m3-sys\cm3\src\Builder.m3 @ 2017] > 1f 000000bc`984fe2f0 00007ff6`4b6b0186 cm3!Builder__RunM3Front+0x4c9 [C:\s\cm3\m3-sys\cm3\src\Builder.m3 @ 1957] > 20 000000bc`984fe3b0 00007ff6`4b6af0ab cm3!Builder__PushOneM3+0x816 [C:\s\cm3\m3-sys\cm3\src\Builder.m3 @ 1618] > 21 000000bc`984fe620 00007ff6`4b6ac058 cm3!Builder__CompileM3+0x33b [C:\s\cm3\m3-sys\cm3\src\Builder.m3 @ 1407] > 22 000000bc`984fe680 00007ff6`4b6ab958 cm3!Builder__CompileOne+0x2a8 [C:\s\cm3\m3-sys\cm3\src\Builder.m3 @ 1102] > 23 000000bc`984fe730 00007ff6`4b6a50b2 cm3!Builder__CompileEverything+0x2b8 [C:\s\cm3\m3-sys\cm3\src\Builder.m3 @ 1047] > 24 000000bc`984fe930 00007ff6`4b6a2df8 cm3!Builder__CompileUnits+0x1222 [C:\s\cm3\m3-sys\cm3\src\Builder.m3 @ 359] > 25 000000bc`984fea20 00007ff6`4b6ccf57 cm3!Builder__BuildLib+0x58 [C:\s\cm3\m3-sys\cm3\src\Builder.m3 @ 40] > 26 000000bc`984fea80 00007ff6`4b7b538c cm3!M3Build__DoLibrary+0x227 [C:\s\cm3\m3-sys\cm3\src\M3Build.m3 @ 1466] > 27 000000bc`984feb70 00007ff6`4b7b3b22 cm3!QMachine__DoCall+0x80c [C:\s\cm3\m3-sys\m3quake\src\QMachine.m3 @ 547] > 28 000000bc`984fec50 00007ff6`4b7c0289 cm3!QMachine__Eval+0x2152 [C:\s\cm3\m3-sys\m3quake\src\QMachine.m3 @ 422] > 29 000000bc`984feec0 00007ff6`4b7c000a cm3!QMachine__IncludeFile+0x269 [C:\s\cm3\m3-sys\m3quake\src\QMachine.m3 @ 1774] > 2a 000000bc`984ff0c0 00007ff6`4b6c6a6d cm3!QMachine__Include+0x2a [C:\s\cm3\m3-sys\m3quake\src\QMachine.m3 @ 1745] > 2b 000000bc`984ff100 00007ff6`4b6c97dd cm3!M3Build__Include+0xfd [C:\s\cm3\m3-sys\cm3\src\M3Build.m3 @ 679] > 2c 000000bc`984ff1a0 00007ff6`4b7b538c cm3!M3Build__DoIncludeDir+0xfd [C:\s\cm3\m3-sys\cm3\src\M3Build.m3 @ 1055] > 2d 000000bc`984ff210 00007ff6`4b7b3b22 cm3!QMachine__DoCall+0x80c [C:\s\cm3\m3-sys\m3quake\src\QMachine.m3 @ 547] > 2e 000000bc`984ff2f0 00007ff6`4b7b19ba cm3!QMachine__Eval+0x2152 [C:\s\cm3\m3-sys\m3quake\src\QMachine.m3 @ 422] > 2f 000000bc`984ff560 00007ff6`4b7cc3fd cm3!QMachine__Evaluate+0x7a [C:\s\cm3\m3-sys\m3quake\src\QMachine.m3 @ 166] > 30 000000bc`984ff5a0 00007ff6`4b6c408b cm3!Quake__Run+0xdd [C:\s\cm3\m3-sys\m3quake\src\Quake.m3 @ 20] > 31 000000bc`984ff600 00007ff6`4b6e5818 cm3!M3Build__Run+0x11b [C:\s\cm3\m3-sys\cm3\src\M3Build.m3 @ 243] > 32 000000bc`984ff640 00007ff6`4b6e4a02 cm3!Main__DoIt+0xd88 [C:\s\cm3\m3-sys\cm3\src\Main.m3 @ 117] > 33 000000bc`984ff9e0 00007ff6`4baa1ab7 cm3!Main_M3+0x22 [C:\s\cm3\m3-sys\cm3\src\Main.m3 @ 231] > 34 000000bc`984ffa20 00007ff6`4baa1d3b cm3!RTLinker__RunMainBody+0x3e7 [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTLinker.m3 @ 408] > 35 000000bc`984ffac0 00007ff6`4baa14b8 cm3!RTLinker__AddUnitI+0x11b [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTLinker.m3 @ 116] > 36 000000bc`984ffb00 00007ff6`4b6a1038 cm3!RTLinker__AddUnit+0x118 [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTLinker.m3 @ 125] > 37 000000bc`984ffb60 00007ff6`4bb12974 cm3!main+0x38 [C:\s\cm3\m3-sys\cm3\AMD64_NT\_m3main.c @ 23] > 38 (Inline Function) --------`-------- cm3!invoke_main+0x22 [d:\agent\_work\5\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl @ 78] > > > which if you go past the breakpoint, which simulates no debugger, it hits the assertion failure > I reported: > > 3:013> k > > . 13 Id: a35c.8d38 Suspend: 1 Teb: 000000bc`982c8000 Unfrozen > # Child-SP RetAddr Call Site > KERNELBASE!DebugBreak > 02 000000bc`984fc8f0 00007ff6`4baa2e9f cm3!RTOS__Crash+0x43 [C:\s\cm3\m3-libs\m3core\src\runtime\WIN32\RTOS.m3 @ 26] > 03 000000bc`984fc940 00007ff6`4bad0b4f cm3!RTProcess__Crash+0x6f [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTProcess.m3 @ 66] > 04 000000bc`984fc980 00007ff6`4bad0780 cm3!RTError__EndError+0x3f [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTError.m3 @ 119] > 05 000000bc`984fc9c0 00007ff6`4bae8cd7 cm3!RTError__MsgS+0xa0 [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTError.m3 @ 41] > 06 000000bc`984fca00 00007ff6`4bae88de cm3!RTException__Crash+0x317 [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 81] > 07 000000bc`984fca90 00007ff6`4bae87cb cm3!RTException__DefaultBackstop+0xce [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 39] > 08 000000bc`984fcb00 00007ff6`4bae90ca cm3!RTException__InvokeBackstop+0x3b [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 25] > 09 000000bc`984fcb40 00007ff6`4bae89aa cm3!RTException__Raise+0x9a [C:\s\cm3\m3-libs\m3core\src\runtime\ex_frame\RTExFrame.m3 @ 90] > 0a 000000bc`984fcba0 00007ff6`4bae87cb cm3!RTException__DefaultBackstop+0x19a [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 49] > 0b 000000bc`984fcc10 00007ff6`4bae90ca cm3!RTException__InvokeBackstop+0x3b [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 25] > 0c 000000bc`984fcc50 00007ff6`4babb4fe cm3!RTException__Raise+0x9a [C:\s\cm3\m3-libs\m3core\src\runtime\ex_frame\RTExFrame.m3 @ 90] > 0d 000000bc`984fccb0 00007ff6`4bac003a cm3!RTHooks__ReportFault+0xfe [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTHooks.m3 @ 112] > > The ThreadWin32 assertion failure. > > 0e 000000bc`984fcd50 00007ff6`4babbf09 cm3!M_ThreadWin32_L_137_CRASH+0x1a [C:\s\cm3\m3-libs\m3core\AMD64_NT\ThreadWin32.m3.c @ 4356] > 0f 000000bc`984fcd80 00007ff6`4bae8e28 cm3!RTThread__SuspendOthers+0x89 [C:\s\cm3\m3-libs\m3core\src\thread\WIN32\ThreadWin32.m3 @ 799] > 10 000000bc`984fcdf0 00007ff6`4baa2e9f cm3!RTOS__Crash+0x48 [C:\s\cm3\m3-libs\m3core\src\runtime\WIN32\RTOS.m3 @ 27] > 11 000000bc`984fce40 00007ff6`4bad0b4f cm3!RTProcess__Crash+0x6f [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTProcess.m3 @ 66] > 12 000000bc`984fce80 00007ff6`4bad0780 cm3!RTError__EndError+0x3f [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTError.m3 @ 119] > 13 000000bc`984fcec0 00007ff6`4bae8cd7 cm3!RTError__MsgS+0xa0 [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTError.m3 @ 41] > 14 000000bc`984fcf00 00007ff6`4bae88de cm3!RTException__Crash+0x317 [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 81] > 15 000000bc`984fcf90 00007ff6`4bae87cb cm3!RTException__DefaultBackstop+0xce [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 39] > 16 000000bc`984fd000 00007ff6`4bae90ca cm3!RTException__InvokeBackstop+0x3b [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 25] > 17 000000bc`984fd040 00007ff6`4bae89aa cm3!RTException__Raise+0x9a [C:\s\cm3\m3-libs\m3core\src\runtime\ex_frame\RTExFrame.m3 @ 90] > 18 000000bc`984fd0a0 00007ff6`4bae87cb cm3!RTException__DefaultBackstop+0x19a [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 49] > 19 000000bc`984fd110 00007ff6`4bae90ca cm3!RTException__InvokeBackstop+0x3b [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 25] > 1a 000000bc`984fd150 00007ff6`4babb4fe cm3!RTException__Raise+0x9a [C:\s\cm3\m3-libs\m3core\src\runtime\ex_frame\RTExFrame.m3 @ 90] > 1b 000000bc`984fd1b0 00007ff6`4bae8f4a cm3!RTHooks__ReportFault+0xfe [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTHooks.m3 @ 112] > 1c 000000bc`984fd250 00007ff6`4bae8dc4 cm3!M_RTOS_L_15_CRASH+0x1a [C:\s\cm3\m3-libs\m3core\AMD64_NT\RTOS.m3.c @ 544] > 1d 000000bc`984fd280 00007ff6`4bae8e4a cm3!RTOS__Exit+0x44 [C:\s\cm3\m3-libs\m3core\src\runtime\WIN32\RTOS.m3 @ 16] > 1e 000000bc`984fd2c0 00007ff6`4baa2e9f cm3!RTOS__Crash+0x6a [C:\s\cm3\m3-libs\m3core\src\runtime\WIN32\RTOS.m3 @ 30] > 1f 000000bc`984fd310 00007ff6`4bad0b4f cm3!RTProcess__Crash+0x6f [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTProcess.m3 @ 66] > 20 000000bc`984fd350 00007ff6`4bad0780 cm3!RTError__EndError+0x3f [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTError.m3 @ 119] > 21 000000bc`984fd390 00007ff6`4bae8cd7 cm3!RTError__MsgS+0xa0 [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTError.m3 @ 41] > 22 000000bc`984fd3d0 00007ff6`4bae88de cm3!RTException__Crash+0x317 [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 81] > 23 000000bc`984fd460 00007ff6`4bae87cb cm3!RTException__DefaultBackstop+0xce [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 39] > 24 000000bc`984fd4d0 00007ff6`4bae90ca cm3!RTException__InvokeBackstop+0x3b [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 25] > 25 000000bc`984fd510 00007ff6`4bae89aa cm3!RTException__Raise+0x9a [C:\s\cm3\m3-libs\m3core\src\runtime\ex_frame\RTExFrame.m3 @ 90] > 26 000000bc`984fd570 00007ff6`4bae87cb cm3!RTException__DefaultBackstop+0x19a [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 49] > 27 000000bc`984fd5e0 00007ff6`4bae90ca cm3!RTException__InvokeBackstop+0x3b [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 25] > 28 000000bc`984fd620 00007ff6`4babb4fe cm3!RTException__Raise+0x9a [C:\s\cm3\m3-libs\m3core\src\runtime\ex_frame\RTExFrame.m3 @ 90] > 29 000000bc`984fd680 00007ff6`4b71aeca cm3!RTHooks__ReportFault+0xfe [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTHooks.m3 @ 112] > 2a 000000bc`984fd720 00007ff6`4b7050f7 cm3!M_M3C_L_166_CRASH+0x1a [C:\s\cm3\m3-sys\m3back\AMD64_NT\M3C.m3.c @ 31094] > 2b 000000bc`984fd750 00007ff6`4b7038d4 cm3!M3C__TIntLiteral+0x5a7 [C:\s\cm3\m3-sys\m3back\src\M3C.m3 @ 4830] > > > The first suspend is here: > 3:013> k > # Child-SP RetAddr Call Site > 00 000000d3`6839d2d8 00007ff6`4bae8e28 cm3!RTThread__SuspendOthers [C:\s\cm3\m3-libs\m3core\src\thread\WIN32\ThreadWin32.m3 @ 793] > 01 000000d3`6839d2e0 00007ff6`4baa2e9f cm3!RTOS__Crash+0x48 [C:\s\cm3\m3-libs\m3core\src\runtime\WIN32\RTOS.m3 @ 27] > 02 000000d3`6839d330 00007ff6`4bad0b4f cm3!RTProcess__Crash+0x6f [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTProcess.m3 @ 66] > 03 000000d3`6839d370 00007ff6`4bad0780 cm3!RTError__EndError+0x3f [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTError.m3 @ 119] > 04 000000d3`6839d3b0 00007ff6`4bae8cd7 cm3!RTError__MsgS+0xa0 [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTError.m3 @ 41] > 05 000000d3`6839d3f0 00007ff6`4bae88de cm3!RTException__Crash+0x317 [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 81] > 06 000000d3`6839d480 00007ff6`4bae87cb cm3!RTException__DefaultBackstop+0xce [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 39] > 07 000000d3`6839d4f0 00007ff6`4bae90ca cm3!RTException__InvokeBackstop+0x3b [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 25] > 08 000000d3`6839d530 00007ff6`4bae89aa cm3!RTException__Raise+0x9a [C:\s\cm3\m3-libs\m3core\src\runtime\ex_frame\RTExFrame.m3 @ 90] > 09 000000d3`6839d590 00007ff6`4bae87cb cm3!RTException__DefaultBackstop+0x19a [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 49] > 0a 000000d3`6839d600 00007ff6`4bae90ca cm3!RTException__InvokeBackstop+0x3b [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTException.m3 @ 25] > 0b 000000d3`6839d640 00007ff6`4babb4fe cm3!RTException__Raise+0x9a [C:\s\cm3\m3-libs\m3core\src\runtime\ex_frame\RTExFrame.m3 @ 90] > 0c 000000d3`6839d6a0 00007ff6`4b71aeca cm3!RTHooks__ReportFault+0xfe [C:\s\cm3\m3-libs\m3core\src\runtime\common\RTHooks.m3 @ 112] > 0d 000000d3`6839d740 00007ff6`4b7050f7 cm3!M_M3C_L_166_CRASH+0x1a [C:\s\cm3\m3-sys\m3back\AMD64_NT\M3C.m3.c @ 31094] > 0e 000000d3`6839d770 00007ff6`4b7038d4 cm3!M3C__TIntLiteral+0x5a7 [C:\s\cm3\m3-sys\m3back\src\M3C.m3 @ 4830] > > > and then.."funny".. > > PROCEDURE Crash () = > CONST Magic = 1 * ADRSIZE (INTEGER); (* == offset of "fp" in this frame *) > VAR fp: ADDRESS := ADR (fp) + Magic; (* == my frame pointer *) > BEGIN > IF WinBase.IsDebuggerPresent () # 0 THEN > WinBase.DebugBreak (); > END; > RTThread.SuspendOthers (); <== probably the first suspend > RTMachInfo.DumpStack (LOOPHOLE (Crash, ADDRESS), fp); > RTSignal.RestoreHandlers (); (* so we really do crash... *) > Exit (-1); <== it gets here > END Crash; > > PROCEDURE Exit (n: INTEGER) = <== and then here > BEGIN > WinBase.ExitProcess (n); > END Exit; > > > and it is our recent friend, a range fault on the exit code. > > 0f 000000d3`6839d2a0 00007ff6`4bae8e4a cm3!RTOS__Exit( > int64 n_L_17 = 0n-1)+0x44 [C:\s\cm3\m3-libs\m3core\src\runtime\WIN32\RTOS.m3 @ 16] > > > 3:013> u cm3!RTOS__Exit > cm3!RTOS__Exit [C:\s\cm3\m3-libs\m3core\src\runtime\WIN32\RTOS.m3 @ 18]: > 00007ff6`4bae8d80 48894c2408 mov qword ptr [rsp+8],rcx > 00007ff6`4bae8d85 4883ec38 sub rsp,38h > 00007ff6`4bae8d89 48c744242000000000 mov qword ptr [rsp+20h],0 > 00007ff6`4bae8d92 488d442428 lea rax,[rsp+28h] > 00007ff6`4bae8d97 4889442428 mov qword ptr [rsp+28h],rax > 00007ff6`4bae8d9c 488b442440 mov rax,qword ptr [rsp+40h] > 00007ff6`4bae8da1 4889442420 mov qword ptr [rsp+20h],rax > 00007ff6`4bae8da6 48837c242000 cmp qword ptr [rsp+20h],0 > 3:013> u > cm3!RTOS__Exit+0x2c [C:\s\cm3\m3-libs\m3core\src\runtime\WIN32\RTOS.m3 @ 16]: > 00007ff6`4bae8dac 7c0c jl cm3!RTOS__Exit+0x3a (00007ff6`4bae8dba) > 00007ff6`4bae8dae b8ffffffff mov eax,0FFFFFFFFh > 00007ff6`4bae8db3 4839442420 cmp qword ptr [rsp+20h],rax > 00007ff6`4bae8db8 7e0a jle cm3!RTOS__Exit+0x44 (00007ff6`4bae8dc4) > 00007ff6`4bae8dba b901020000 mov ecx,201h > 00007ff6`4bae8dbf e86c010000 call cm3!M_RTOS_L_15_CRASH (00007ff6`4bae8f30) <== here > 00007ff6`4bae8dc4 8b4c2420 mov ecx,dword ptr [rsp+20h] > > > C:\s\cm3\m3-libs\m3core\src\win32\WinBase.i3(1231):<*EXTERNAL ExitProcess:WINAPI*> > C:\s\cm3\m3-libs\m3core\src\win32\WinBase.i3(1232):PROCEDURE ExitProcess (uExitCode: UINT32); > > Voila. > > ExitProcess is declared as taking an unsigned integer but we pass negative. Well, if a negative value is appropriate here, then the type should not be an unsigned type. Perhaps INT32, or if that is too narrow on 64-bit machines, then INTEGER. Or is it the negative value that is wrong? > > So again I think we are being somehow overzealous regarding integer ranges. > > I mean, I get, that quality is important and this seems correct, based on > some simple principles, but the result seems very unsatifactory. > > > On the 32bit system this is Word.T and you can pass any INTEGER value, there are > no checks I guess, and it works. > > > But the extension to a 64bit system adds checks and not all INTEGER values are valid, > not even ones that fit in 32bits like -1. > > > Would it make sense to declare a type with the "1.5" range -2^31..2^32? > > Again, I am tempted to change to plain 64bit INTEGER. But that changes e.g. > the type of taking the address. > Pass any value that fits in a register, with the understanding, perhaps not known, > that the upper 32bits are silently ignored??? > > I realize is an exit upon an assertion failure, so it doesn't really matter, > in this case, but Exit(-1) imho should be portable between Win32 and Win64. > > I know I could say Exit(16_ffffffff) or have a wrapper that does Word.And(Last(UINT32)) > but I don't think these should be needed. -1 should be portable between 32bit and 64bit. > > Please help me to understand and advise what to do? > > The nested suspend should probably be relaxed somehow too? > > - Jay > > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ > *From:* M3devel on behalf of Jay K > *Sent:* Thursday, February 25, 2021 4:48 AM > *To:* m3devel > *Subject:* [M3devel] win32 <* ASSERT suspend_cnt = 0 *> ? > Today I ran: > > for /f %a in (targets.txt) do .\boot1.py %a c > > It worked a lot, and then a lot of: > > > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "..\src\thread\WIN32\ThreadWin32.m3", line 798 > *** > > > which is here: > > PROCEDURE SuspendOthers () = > (* LL=0. Always bracketed with ResumeOthers which releases "activeLock". *) > VAR me: Activation; > act: Activation; > retry: BOOLEAN; > BEGIN > EnterCriticalSection(ADR(activeLock)); > > <* ASSERT suspend_cnt = 0 *> <--- > INC (suspend_cnt); > IF suspend_cnt # 1 THEN > RETURN > END; > > > any ideas? > > This is AMD64_NT. > > I'll try to reproduce it under a debugger. > The code looks a little odd, in that it seems prepared for the assertion failure. > > Thank you, > - Jay -- Rodney Bates rodney.m.bates at acm.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Thu Feb 25 18:43:10 2021 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 25 Feb 2021 11:43:10 -0600 Subject: [M3devel] win32 <* ASSERT suspend_cnt = 0 *> ? another int32 vs. uint32 on win64 problem In-Reply-To: References: <73bec3db-45d8-b6d2-d06e-970a974b389f@lcwb.coop> Message-ID: On 2/25/21 11:12 AM, Jay K wrote: > Neither UINT32 nor INT32 seem sufficient. > > I assert any 32bit value is ok and the interpretation is up the eventual reciever. Yes, exactly. But on a 32-bit system, the way to denote the type of an arbitrary 32-bit value is Word.T. See below. > > Widening it to 64bit INTEGER is probably ok, but risks > being wrong depending on how the ABI works. > > Ok, well, I checked, on NT/amd64, when parameters are smaller > than 64bits, and passed on the stack, they still consume 8 bytes, > so widening to INTEGER I think is the solution. > > But, you know, in C++ it is possible at compile time > to get the type of a function, the types of its parameters, > and do stuff with those types. > > So it is unfortunate to have to change the signature. > But I think that is the solution here, and on some other functions like that networking thing. > > And again, ignoring this particular function briefly. > What if UINT32 was the correct type and we wanted to rule out -1? > We can only do that trivially in the 64bit system? > Doesn't that seem kinda bad/wrong? > > 32bit system cannot say TYPE UINT32 = [0...16_FFFFFFFFF]? 32-bit system can say this. But subrange types always use a signed interpretation of the bounds. and for 16_FFFFFFFF, that means -1. So with a lower bound of 0, this is an empty subrange, and there is no value you can pass to it at runtime. In contrast, 0n a 64-bit system, 16_FFFFFFFF is well within the positive part of the (signed) range, so this subrange is correct. It is perhaps unfortunate that we don't have a subrange type constructor that applies unsigned interpretation to its bounds, like we have unsigned versions of the expressions. But if we did, this subrange would just mean the same thing as Word.T, i.e., that suppliers and users of values of this type should be interpreting the bits as unsigned, as you say above. > > ?- Jay > > -- Rodney Bates rodney.m.bates at acm.org From hendrik at topoi.pooq.com Thu Feb 25 22:46:47 2021 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Thu, 25 Feb 2021 16:46:47 -0500 Subject: [M3devel] Grisu problems In-Reply-To: References: <20210225131137.5j6qmqnugonzgjil@topoi.pooq.com> Message-ID: <20210225214647.jcu2buk27yqb7n25@topoi.pooq.com> On Thu, Feb 25, 2021 at 05:03:46PM +0000, Jay K wrote: > Of course never use regular sprintf. > > snprintf isn't a good function either. > > It is probably "unsafe" in that it probably does not always nul terminate, > if the string just fits, and probably inefficient in that it > probably pads out the output to n (when it does fit). >From https://www.cplusplus.com/reference/cstdio/snprintf/ : int snprintf ( char * s, size_t n, const char * format, ... ); : : Write formatted output to sized buffer : Composes a string with the same text that would be printed if format was used on printf, but instead of being printed, the content is stored as a C string in the buffer pointed by s (taking n as the maximum buffer capacity to fill). : : If the resulting string would be longer than n-1 characters, the remaining characters are discarded and not stored, but counted for the value returned by the function. : : A terminating null character is automatically appended after the content written. : : After the format parameter, the function expects at least as many additional arguments as needed for format. Looks like it does always provide the terminating null character. -- hendrik > > Though the first, worse, problem can be mitigated by zero initializing > the buffer and passing buffer size minus 1. snprintf already subtracts the 1. > > At least most of the n functions are bad like that: strncpy, strncat, etc. > All bad functions. Along with the non-n functions: strcpy, strcat, also all bad. > Besides the inefficiency of strcat, repeated strcat is O(n^2). > > The standard C library is horrible for strings. I agree. -- hendrik > > I use "sprintf" to refer really to _sprintf_s or _snprintf_s, sorry for the informality. > > The heap allocation is not for the output. > I didn't say that. > > It is for internal computation. > It is unfortunate, but it is allowed to. > sprintf need only be thread safe, not reentrant (i.e. heap allocation cannot sprintf). > > C:\s>type 1.c > #include > > int main() > { > char buffer[20] = {0}; > snprintf(buffer, sizeof(buffer) - 1, "%99e\n", 1.0 / 3.0); > printf("%99e\n", 1.0 / 3.0); > return 0; > } > C:\s>cl /Zi 1.c > Microsoft (R) C/C++ Optimizing Compiler Version 19.24.28316 for x64 > > C:\s>\bin\amd64\cdb 1.exe > > 0:000> bp 1!main > 0:000> g > 1!main: > 0:000> bm ntdll!RtlAllocateHeap > 0:000> g > 0:000> k > Child-SP RetAddr Call Site > 00000004`830ff068 00007ff6`c7c944d0 ntdll!RtlAllocateHeap > 00000004`830ff070 00007ff6`c7c989ad 1!_malloc_base+0x44 > 00000004`830ff0a0 00007ff6`c7c72603 1!__acrt_stdio_begin_temporary_buffering_nolock+0x79 > (Inline Function) --------`-------- 1!__acrt_stdio_temporary_buffering_guard::{ctor}+0x8 > 00000004`830ff0d0 00007ff6`c7c6a9ae 1!::operator()+0x3f > 00000004`830ff5c0 00007ff6`c7c87815 1!__crt_seh_guarded_call::operator()<, &, >+0x26 > (Inline Function) --------`-------- 1!__acrt_lock_stream_and_call+0x41 > (Inline Function) --------`-------- 1!common_vfprintf+0x61 > 00000004`830ff5f0 00007ff6`c7c56c7e 1!__stdio_common_vfprintf+0x85 > 00000004`830ff660 00007ff6`c7c56ce1 1!_vfprintf_l+0x3e > 00000004`830ff6a0 00007ff6`c7c56bf2 1!printf+0x41 > 00000004`830ff6e0 00007ff6`c7c5712c 1!main+0x62 > (Inline Function) --------`-------- 1!invoke_main+0x22 > 00000004`830ff730 00007ff8`49a67034 1!__scrt_common_main_seh+0x10c > 00000004`830ff770 00007ff8`4a8fd241 KERNEL32!BaseThreadInitThunk+0x14 > 00000004`830ff7a0 00000000`00000000 ntdll!RtlUserThreadStart+0x21 > > - Jay > > ________________________________ > From: M3devel on behalf of Hendrik Boom > Sent: Thursday, February 25, 2021 1:11 PM > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Grisu problems > > On Wed, Feb 24, 2021 at 12:00:56PM +0000, Jay K wrote: > > Folks, this Grisu thing has been unusually problematic. > > It definitely fails with the C backend, and I'm not sure, maybe with the NT386 integrated backend. > > I realize it could be/likely-is bugs in those backends, but they do manage to compile a lot else. > > Maybe someone can investigate? > > For now I've selectively disabled it, i.e. for Win32 and shortly for the C backend, sorry. > > I want to move on to other things before investigating this. > > > > -> linking shobjcodegen > > g++ -gstabs+ -m64 -fPIC -g -c -xc++ _m3main.c -o _m3main.o > > > > > > *** > > *** runtime error: > > *** <*ASSERT*> failed. > > *** file "../src/float/Common/grisu/IEEE.m3", line 155 > > *** > > > > More so though, I suggest all endian-specific code be in C or C++..not because Modula-3 cannot do it, but in order to get towards an endian-independent distribution format. > > > > Perhaps also floating point formating should be left to sprintf? > > (Caveat that Win32 sprintf("%f") does a heap allocation, I think, ouch.) > > Not clear what you mean here. > > Doesn't sprintf require that its first argument is a pointer to a string where the > results are to be stored? I doubt that you'd want that to be the format string. > > I can't see any reason for sprintf to do a heap allocation. I can see many ways > for it to go wring if its arguments aren't just so. > > There's also snprintf, which is presumably safer. > > -- hendrik > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fm3lists.elegosoft.com%2Fmailman%2Flistinfo%2Fm3devel&data=04%7C01%7C%7Cc6d352c3401f49fadfe208d8d98ef2fb%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637498555290294393%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=R1PCe8FOjezYrAJkwfTyiEFLznBwZW%2FMWi%2BV9YYmGXI%3D&reserved=0 From jayk123 at hotmail.com Thu Feb 25 22:54:36 2021 From: jayk123 at hotmail.com (Jay K) Date: Thu, 25 Feb 2021 21:54:36 +0000 Subject: [M3devel] another integer range problem? cg.init_init? Message-ID: I'm sorry to drag this out, but here is another related "problem", the assertion failure I was looking at, before the nested suspend and exit(-1) The assert in m3c is this: PROCEDURE TIntLiteral(self: T; type: CGType; READONLY i: Target.Int): TEXT = VAR ok1 := TRUE; ok2 := TRUE; BEGIN CASE type OF | CGType.Int64 => ok2 := TInt.LE(i, TInt.Max64); <* ASSERT ok2 *> given this little source: INTERFACE LongRealRep; (* This interface describes the layout of IEEE double precision reals on big endian machines *) TYPE T = RECORD sign : BITS 1 FOR [0..1] := 0; exponent : BITS 11 FOR [0..16_7FF] := 0; significand0 : BITS 20 FOR [0..16_FFFFF] := 0; significand1 : BITS 32 FOR [-16_7fffffff-1 .. 16_7fffffff] := 0; END; CONST NegInf = T { sign := 1, exponent := 16_7FF }; This? PosInf = T { sign := 0, exponent := 16_7FF }; Nan = T { sign := 0, exponent := 16_7FF, significand0 := 1 }; END LongRealRep. CG sees: . . . /* bind_segment var:L_0_L_1 byte_size:88 cgtype:STRUCT exported:FALSE inited:TRUE */ /* begin_init */ /* init_int offset:0 value:18442240474082181120 type:INT64 */ . . . global data allocation for I_LongRealRep 0 52 4 *module info* 52 4 4 constantNegInf 56 4 4 constantPosInf 60 4 4 constantNan 64 12 4 import RTHooks 76 0 4 *TOTAL* global constants for I_LongRealRep 0 8 4 constant NegInf 8 8 4 constant PosInf 16 8 4 constant Nan 24 15 4 *proc names* 40 12 4 *proc info* 52 36 1 *string* 88 0 4 *TOTAL* 18442240474082181120 is not a valid INT64. Maybe frontend should just be initializing unsigned types? Or bits? I'm guessing unsigned, but I have to look a bunch more. I had already commented out similar assertions for smaller integer types, so maybe m3front just doesn't pay attention to this and my asserts are overeager? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Thu Feb 25 22:59:51 2021 From: jayk123 at hotmail.com (Jay K) Date: Thu, 25 Feb 2021 21:59:51 +0000 Subject: [M3devel] Grisu problems In-Reply-To: <20210225214647.jcu2buk27yqb7n25@topoi.pooq.com> References: <20210225131137.5j6qmqnugonzgjil@topoi.pooq.com> , <20210225214647.jcu2buk27yqb7n25@topoi.pooq.com> Message-ID: Ok, apparently this one is different/better than so many other similar functions. https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/snprintf-snprintf-snprintf-l-snwprintf-snwprintf-l?view=msvc-160 Long list of functions documented on one page. " For all functions, if len < count, len characters are stored in buffer, a null-terminator is appended, and len is returned. The snprintf function truncates the output when len is greater than or equal to count, by placing a null-terminator at buffer[count-1]. The value returned is len, the number of characters that would have been output if count was large enough. The snprintf function returns a negative value if an encoding error occurs. For all functions other than snprintf, if len = count, len characters are stored in buffer, no null-terminator is appended, and len is returned. If len > count, count characters are stored in buffer, no null-terminator is appended, and a negative value is returned. " I would be reluctant to depend on this behavior. I have seen bugs in sprintf and relatives, maybe this exact problem, like when doing: char buffer[1]; snprintf(buffer, 1, "%s", ""); I think that failed on recent libraries. Workaround was to always grow buffer one more than needed. Heap allocation inside sprintf is unfortunate too imho. I would like more reentrant libraries, not merely thread safe. - Jay ________________________________ From: M3devel on behalf of Hendrik Boom Sent: Thursday, February 25, 2021 9:46 PM To: m3devel at elegosoft.com Subject: Re: [M3devel] Grisu problems On Thu, Feb 25, 2021 at 05:03:46PM +0000, Jay K wrote: > Of course never use regular sprintf. > > snprintf isn't a good function either. > > It is probably "unsafe" in that it probably does not always nul terminate, > if the string just fits, and probably inefficient in that it > probably pads out the output to n (when it does fit). >From https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.cplusplus.com%2Freference%2Fcstdio%2Fsnprintf%2F&data=04%7C01%7C%7C150b9e78c3b14417be3408d8d9d6e642%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637498864300008158%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=V8LX%2F8BkvPFZVt10AbRirxBVy1nRLN%2B%2BAOxsnqd5XmQ%3D&reserved=0 : int snprintf ( char * s, size_t n, const char * format, ... ); : : Write formatted output to sized buffer : Composes a string with the same text that would be printed if format was used on printf, but instead of being printed, the content is stored as a C string in the buffer pointed by s (taking n as the maximum buffer capacity to fill). : : If the resulting string would be longer than n-1 characters, the remaining characters are discarded and not stored, but counted for the value returned by the function. : : A terminating null character is automatically appended after the content written. : : After the format parameter, the function expects at least as many additional arguments as needed for format. Looks like it does always provide the terminating null character. -- hendrik > > Though the first, worse, problem can be mitigated by zero initializing > the buffer and passing buffer size minus 1. snprintf already subtracts the 1. > > At least most of the n functions are bad like that: strncpy, strncat, etc. > All bad functions. Along with the non-n functions: strcpy, strcat, also all bad. > Besides the inefficiency of strcat, repeated strcat is O(n^2). > > The standard C library is horrible for strings. I agree. -- hendrik > > I use "sprintf" to refer really to _sprintf_s or _snprintf_s, sorry for the informality. > > The heap allocation is not for the output. > I didn't say that. > > It is for internal computation. > It is unfortunate, but it is allowed to. > sprintf need only be thread safe, not reentrant (i.e. heap allocation cannot sprintf). > > C:\s>type 1.c > #include > > int main() > { > char buffer[20] = {0}; > snprintf(buffer, sizeof(buffer) - 1, "%99e\n", 1.0 / 3.0); > printf("%99e\n", 1.0 / 3.0); > return 0; > } > C:\s>cl /Zi 1.c > Microsoft (R) C/C++ Optimizing Compiler Version 19.24.28316 for x64 > > C:\s>\bin\amd64\cdb 1.exe > > 0:000> bp 1!main > 0:000> g > 1!main: > 0:000> bm ntdll!RtlAllocateHeap > 0:000> g > 0:000> k > Child-SP RetAddr Call Site > 00000004`830ff068 00007ff6`c7c944d0 ntdll!RtlAllocateHeap > 00000004`830ff070 00007ff6`c7c989ad 1!_malloc_base+0x44 > 00000004`830ff0a0 00007ff6`c7c72603 1!__acrt_stdio_begin_temporary_buffering_nolock+0x79 > (Inline Function) --------`-------- 1!__acrt_stdio_temporary_buffering_guard::{ctor}+0x8 > 00000004`830ff0d0 00007ff6`c7c6a9ae 1!::operator()+0x3f > 00000004`830ff5c0 00007ff6`c7c87815 1!__crt_seh_guarded_call::operator()<, &, >+0x26 > (Inline Function) --------`-------- 1!__acrt_lock_stream_and_call+0x41 > (Inline Function) --------`-------- 1!common_vfprintf+0x61 > 00000004`830ff5f0 00007ff6`c7c56c7e 1!__stdio_common_vfprintf+0x85 > 00000004`830ff660 00007ff6`c7c56ce1 1!_vfprintf_l+0x3e > 00000004`830ff6a0 00007ff6`c7c56bf2 1!printf+0x41 > 00000004`830ff6e0 00007ff6`c7c5712c 1!main+0x62 > (Inline Function) --------`-------- 1!invoke_main+0x22 > 00000004`830ff730 00007ff8`49a67034 1!__scrt_common_main_seh+0x10c > 00000004`830ff770 00007ff8`4a8fd241 KERNEL32!BaseThreadInitThunk+0x14 > 00000004`830ff7a0 00000000`00000000 ntdll!RtlUserThreadStart+0x21 > > - Jay > > ________________________________ > From: M3devel on behalf of Hendrik Boom > Sent: Thursday, February 25, 2021 1:11 PM > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Grisu problems > > On Wed, Feb 24, 2021 at 12:00:56PM +0000, Jay K wrote: > > Folks, this Grisu thing has been unusually problematic. > > It definitely fails with the C backend, and I'm not sure, maybe with the NT386 integrated backend. > > I realize it could be/likely-is bugs in those backends, but they do manage to compile a lot else. > > Maybe someone can investigate? > > For now I've selectively disabled it, i.e. for Win32 and shortly for the C backend, sorry. > > I want to move on to other things before investigating this. > > > > -> linking shobjcodegen > > g++ -gstabs+ -m64 -fPIC -g -c -xc++ _m3main.c -o _m3main.o > > > > > > *** > > *** runtime error: > > *** <*ASSERT*> failed. > > *** file "../src/float/Common/grisu/IEEE.m3", line 155 > > *** > > > > More so though, I suggest all endian-specific code be in C or C++..not because Modula-3 cannot do it, but in order to get towards an endian-independent distribution format. > > > > Perhaps also floating point formating should be left to sprintf? > > (Caveat that Win32 sprintf("%f") does a heap allocation, I think, ouch.) > > Not clear what you mean here. > > Doesn't sprintf require that its first argument is a pointer to a string where the > results are to be stored? I doubt that you'd want that to be the format string. > > I can't see any reason for sprintf to do a heap allocation. I can see many ways > for it to go wring if its arguments aren't just so. > > There's also snprintf, which is presumably safer. > > -- hendrik > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fm3lists.elegosoft.com%2Fmailman%2Flistinfo%2Fm3devel&data=04%7C01%7C%7C150b9e78c3b14417be3408d8d9d6e642%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637498864300008158%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=0TZTQzZZq3fhBhIkcTIjEG20SKMUPzHRTq7b%2BgNvM9E%3D&reserved=0 _______________________________________________ M3devel mailing list M3devel at elegosoft.com https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fm3lists.elegosoft.com%2Fmailman%2Flistinfo%2Fm3devel&data=04%7C01%7C%7C150b9e78c3b14417be3408d8d9d6e642%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637498864300008158%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=0TZTQzZZq3fhBhIkcTIjEG20SKMUPzHRTq7b%2BgNvM9E%3D&reserved=0 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri Feb 26 09:26:48 2021 From: jayk123 at hotmail.com (Jay K) Date: Fri, 26 Feb 2021 08:26:48 +0000 Subject: [M3devel] voronoi precedence errors Message-ID: please fix? Or I'll PR it shortly. (if the code is correct, place parens; if the code is incorrect, place parens, or better yet probably, change & to &&) I will remove it from local pkginfo.txt for now. 4/pkg/m3core/src -I/cm3.amd64/pkg/m3core/src/Csupport/Common -I/cm3.amd64/pkg/m3core/src/Csupport/little-endian -I/cm3.amd64/pkg/m3core/src/Csupport/libgcc -I/cm3.amd64/pkg/m3core/src/runtime/common -I/cm3.amd64/pkg/m3core/src/runtime/POSIX -I/cm3.amd64/pkg/m3core/src/runtime/ex_frame -I/cm3.amd64/pkg/m3core/src/thread/Common -I/cm3.amd64/pkg/m3core/src/thread/PTHREAD -I/cm3.amd64/pkg/m3core/src/C/Common -I/cm3.amd64/pkg/m3core/src/float/C99 -I/cm3.amd64/pkg/m3core/src/time/POSIX -I/cm3.amd64/pkg/libm3/src/os/POSIX -I/cm3.amd64/pkg/libm3/src/uid/POSIX -I/cm3.amd64/pkg/tcp/src/POSIX -I/cm3.amd64/pkg/patternmatching/src/libglob -I/cm3.amd64/pkg/cit_util/src -I../src -g -c ../src/output.c -o output.o ../src/output.c:40:4: error: logical not is only applied to the left hand side of this bitwise operator [-Werror,-Wlogical-not-parentheses] if(!triangulate & plot) ^ ~ ../src/output.c:40:4: note: add parentheses after the '!' to evaluate the bitwise operator first if(!triangulate & plot) ^ ( ) ../src/output.c:40:4: note: add parentheses around left hand side expression to silence this warning if(!triangulate & plot) ^ ( ) ../src/output.c:61:4: error: logical not is only applied to the left hand side of this bitwise operator [-Werror,-Wlogical-not-parentheses] if(!triangulate & plot & !debug) ^ ~ ../src/output.c:61:4: note: add parentheses after the '!' to evaluate the bitwise operator first if(!triangulate & plot & !debug) ^ ( ) ../src/output.c:61:4: note: add parentheses around left hand side expression to silence this warning if(!triangulate & plot & !debug) ^ ( ) 2 errors generated. compile_c => 1 C compiler failed compiling: ../src/output.c -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Fri Feb 26 17:58:23 2021 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Fri, 26 Feb 2021 10:58:23 -0600 Subject: [M3devel] another integer range problem? cg.init_init? In-Reply-To: References: Message-ID: <2dc2dcea-fdee-dae0-7134-8e8c8418bf81@lcwb.coop> On 2/25/21 3:54 PM, Jay K wrote: > I'm sorry to drag this out, but here is another related "problem", the assertion failure > I was looking at, before the nested suspend and exit(-1) > > The assert in m3c is this: > > PROCEDURE TIntLiteral(self: T; type: CGType; READONLY i: Target.Int): TEXT = > VAR ok1 := TRUE; > ? ? ok2 := TRUE; > BEGIN > ? ? CASE type OF > ? ? ? ? | CGType.Int64 ?=> > ? ? ? ? ? ? ? ?ok2 := TInt.LE(i, TInt.Max64); > ? ? ? ? <* ASSERT ok2 *> > > given this little source: > > INTERFACE LongRealRep; > > (* This interface describes the layout of IEEE double precision reals > ? ?on big endian machines *) > > TYPE > ? T = RECORD > ? ? sign ? ? ? ? : BITS ?1 FOR [0..1] ? ? ? ? ? ? ? ? ? ? ? ? ?:= 0; > ? ? exponent ? ? : BITS 11 FOR [0..16_7FF] ? ? ? ? ? ? ? ? ? ? := 0; > ? ? significand0 : BITS 20 FOR [0..16_FFFFF] ? ? ? ? ? ? ? ? ? := 0; > ? ? significand1 : BITS 32 FOR [-16_7fffffff-1 .. 16_7fffffff] := 0; > ? END; > > CONST > ? NegInf = T { sign := 1, exponent := 16_7FF }; ?This? > ? PosInf = T { sign := 0, exponent := 16_7FF }; > ? Nan ? ?= T { sign := 0, exponent := 16_7FF, significand0 := 1 }; > > END LongRealRep. > > > CG sees: > > > ?. > ?. > ?. > ?/* bind_segment var:L_0_L_1 byte_size:88 cgtype:STRUCT exported:FALSE inited:TRUE */ > ?/* begin_init */ > ?/* init_int offset:0 value:18442240474082181120 type:INT64 */ > ?. > ?. > ?. > ?global data allocation for I_LongRealRep > ? ? ?0 ? ?52 ?4 ?*module info* > ? ? 52 ? ? 4 ?4 ?constantNegInf > ? ? 56 ? ? 4 ?4 ?constantPosInf > ? ? 60 ? ? 4 ?4 ?constantNan > ? ? 64 ? ?12 ?4 ?import RTHooks > ? ? 76 ? ? 0 ?4 ?*TOTAL* > > > ?global constants for I_LongRealRep > ? ? ?0 ? ? 8 ?4 ?constant NegInf > ? ? ?8 ? ? 8 ?4 ?constant PosInf > ? ? 16 ? ? 8 ?4 ?constant Nan > ? ? 24 ? ?15 ?4 ?*proc names* > ? ? 40 ? ?12 ?4 ?*proc info* > ? ? 52 ? ?36 ?1 ?*string* > ? ? 88 ? ? 0 ?4 ?*TOTAL* > > 18442240474082181120 is not a valid INT64. I see this: (gdb) p /x 18442240474082181120 $1 = 0xfff0000000000000 which is a valid INT64 and correct for NegInf. > > Maybe frontend should just be initializing unsigned types? > Or bits? > I'm guessing unsigned, but I have to look a bunch more. It should be initializing everything, just in possibly different ways. > > I had already commented out similar assertions for smaller integer types, so maybe m3front just doesn't pay attention to this and my asserts are overeager? Well, TIntLiteral should be consistent. If its callers are supposed to ensure 'i' is within 'type', then the commented out checks on Int8, Int16, and Int32 should go back in, and the Word* cases should also check that the lower bound is zero. Then if these fail, the problem needs to be fixed in the the callers, not TIntLiteral. If failures of this type are the result of bad code being compiled, rather than front end bugs, then there should be some kind of compile time message, rather than an assertion failure. Without vetting M3C, I don't know which is really wanted. One other thought: If out-of-range values are detected earlier and provoke compile errors, but not made valid at that time, then probably TIntLiteral should be forcing them into range, rather than assert-failing, just as error recovery. > > ?- Jay > > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://m3lists.elegosoft.com/mailman/listinfo/m3devel > -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Fri Feb 26 19:40:27 2021 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Fri, 26 Feb 2021 12:40:27 -0600 Subject: [M3devel] Compiler tests Message-ID: <6d34df9f-57a8-06c1-e3b9-1b34731267c9@lcwb.coop> Jay, you have mentioned a couple of times suspecting a bug in the C backend, as well as others. Are you periodically running the scripted compiler tests? They can help a lot. -- Rodney Bates rodney.m.bates at acm.org From jayk123 at hotmail.com Sat Feb 27 08:58:31 2021 From: jayk123 at hotmail.com (Jay K) Date: Sat, 27 Feb 2021 07:58:31 +0000 Subject: [M3devel] cooperative suspend? Message-ID: I was trying out cm3 on usermode-only qemu RiscV. It failed to send sigsuspend. system qemu works, albeit much slower. So this reminds me, what is the thinking on cooperative suspend? This remains a goal? And the design is known? Generated code polls on function entry and/or exit, and loop enter/continue. what about calls to native code? And callbacks from native code? i.e. When you call blocking read(), a problem to solve. And then to remind folks, there several reasons for and against cooperative and preemptive suspend. - Suspend is among the most target-specific code. Something more portable would ease porting, sort of. On the other hand, if there is just Posix and NT, the porting is basically done, for a long time. - Suspend and get reg context is always a thorn in emulation environments. It doesn't work for example in PowerPC running on Rosetta1. I tried. It likely doesn't work right in other environments, including x86-on-amd64 NT. - If you look at more esoteric targets that we don't handle like AppleWatch and WebAssembly, you see more possible holes in the story. But it is also not trivial or free. Preemptive suspend has an almost magical zero cost in the mainline case of code running w/o suspend request. It does nothing special. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat Feb 27 23:57:12 2021 From: jayk123 at hotmail.com (Jay K) Date: Sat, 27 Feb 2021 22:57:12 +0000 Subject: [M3devel] RISCV64_LINUX release In-Reply-To: References: Message-ID: RISCV64_LINUX now too. ? Release RISCV64_LINUX-20210227 ? modula3/cm3 (github.com) These are essentially identical -- little endian 64bit Unix. - Jay ________________________________ From: Jay K Sent: Wednesday, February 24, 2021 6:59 PM To: m3devel at elegosoft.com Subject: ARM64_DARWIN release ARM64_DARWIN works. The C backend made it easy. ? Release ARM64_DARWIN-20210224 ? modula3/cm3 (github.com) -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Sun Feb 28 03:30:27 2021 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Sat, 27 Feb 2021 21:30:27 -0500 Subject: [M3devel] risc-v backend In-Reply-To: References: <1387378483.9393209.1605295683164@mail.yahoo.com> <4e28d62b-c37f-d345-4c64-8c6e3e9c2bab@lcwb.coop> <1248444975.531123.1605528721286@mail.ziggo.nl> <1724a1c2-6330-c108-a93d-447c72d1732d@lcwb.coop> <20201117124642.vo7iqlomgcohj3vf@topoi.pooq.com> Message-ID: <20210228023027.ue7pokunp5k6azj5@topoi.pooq.com> On Tue, Feb 23, 2021 at 10:35:38PM +0000, Jay K wrote: > > At the same time, a reimplementation of the frontend, might not be so difficult. > The language is not huge. > > - Jay And it would be another step in freeing us from the SRC licence and adopting a GPL-compatible one (such as MIT). -- hendrik > > > On Tue, 17 Nov 2020, Hendrik Boom wrote: > > > Unless we get the license changed, I suspect the only way to get Modula 3 > > into the GNU compiler collection is to reimplement it. > > > > Which is why I advise that anything we now *add* to the entire Modula 3 > > ecosystem be dual-licenced under both the existing license and a > > GPL-compatible one (such as the MIT licence). From hendrik at topoi.pooq.com Sun Feb 28 03:45:50 2021 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Sat, 27 Feb 2021 21:45:50 -0500 Subject: [M3devel] setjmp, _setjmp, sigsetjmp et. al.? In-Reply-To: References: Message-ID: <20210228024550.kow5trwagtxy42do@topoi.pooq.com> On Wed, Feb 24, 2021 at 07:12:26AM +0000, Jay K wrote: > > I've long considered, but never done much about, the idea that we should > be producing something that is actually input to autoconf/automake/libtool, or cmake. > > We could generate *that* input. I know they are all ugly and slow, but > they do nicely delegate problems to others, including hypothetical > support for systems we haven't seen. > > And yes, really, I get it, they are disliked. I do get the impression that cmake is less disliked than autoconf/automake/libtool, but never having used it myself, I have no sense of my own about it. -- hendrik From jayk123 at hotmail.com Sun Feb 28 03:51:48 2021 From: jayk123 at hotmail.com (Jay K) Date: Sun, 28 Feb 2021 02:51:48 +0000 Subject: [M3devel] setjmp, _setjmp, sigsetjmp et. al.? In-Reply-To: <20210228024550.kow5trwagtxy42do@topoi.pooq.com> References: , <20210228024550.kow5trwagtxy42do@topoi.pooq.com> Message-ID: Every time I almost convince myself to get out of the build system business, I am stuck on the useful simple ?standalone? feature. I haven?t seen any other like it, yet it so simple and useful. I will enquire/investigate again cmake though. Our platform reach is also hard to compete with but maybe no matter or not so much. I.e. I would prefer to preserve Aix, Irix, Osf,Hpux,Solaris. - Jay ________________________________ From: M3devel on behalf of Hendrik Boom Sent: Saturday, February 27, 2021 6:45:50 PM To: m3devel at elegosoft.com Subject: Re: [M3devel] setjmp, _setjmp, sigsetjmp et. al.? On Wed, Feb 24, 2021 at 07:12:26AM +0000, Jay K wrote: > > I've long considered, but never done much about, the idea that we should > be producing something that is actually input to autoconf/automake/libtool, or cmake. > > We could generate *that* input. I know they are all ugly and slow, but > they do nicely delegate problems to others, including hypothetical > support for systems we haven't seen. > > And yes, really, I get it, they are disliked. I do get the impression that cmake is less disliked than autoconf/automake/libtool, but never having used it myself, I have no sense of my own about it. -- hendrik _______________________________________________ M3devel mailing list M3devel at elegosoft.com https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fm3lists.elegosoft.com%2Fmailman%2Flistinfo%2Fm3devel&data=04%7C01%7C%7C37122f23bcb34b3d976708d8db92fffc%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637500771691781168%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ZDEEMvPGaQFM4zQYKG7hkV7fjpjpnJrORfop7ZiVrqM%3D&reserved=0 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Sun Feb 28 03:51:57 2021 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Sat, 27 Feb 2021 21:51:57 -0500 Subject: [M3devel] coroutine gap In-Reply-To: References: Message-ID: <20210228025157.lla7v26ahe5fjr2d@topoi.pooq.com> On Wed, Feb 24, 2021 at 10:43:40AM +0000, Jay K wrote: > void * > ContextC__PushContext(Context *c) > { > auto char a[STACK_GAP]; > > /* the purpose of the gap is to allow other routines to do some small > amount of work between when we return and the next GC event, > without clobbering the context we are about to push */ > > (void)memset(a, 0, STACK_GAP); > > return ContextC__PushContext1(c); > } > > > This is not convincing. > memset is typically builtin to the compiler, so it is not some extern function > the compiler does not understand. > It will just optimize this away. Can a be declared volatile if we really need it? > > And "auto" is redundant, and repurposed by C++. > I've heard of people using it in the original meaning, but never seen it. > > - Jay > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://m3lists.elegosoft.com/mailman/listinfo/m3devel From hendrik at topoi.pooq.com Sun Feb 28 04:27:29 2021 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Sat, 27 Feb 2021 22:27:29 -0500 Subject: [M3devel] cooperative suspend? In-Reply-To: References: Message-ID: <20210228032729.x7furcpmapp53ukm@topoi.pooq.com> On Sat, Feb 27, 2021 at 07:58:31AM +0000, Jay K wrote: > I was trying out cm3 on usermode-only qemu RiscV. > It failed to send sigsuspend. > > system qemu works, albeit much slower. > > So this reminds me, what is the thinking on cooperative suspend? > > This remains a goal? Isn't it necessary to put processes into a state where the garbage collector knows how to examine them/ -- hendrik From hendrik at topoi.pooq.com Sun Feb 28 04:46:51 2021 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Sat, 27 Feb 2021 22:46:51 -0500 Subject: [M3devel] setjmp, _setjmp, sigsetjmp et. al.? In-Reply-To: References: <20210228024550.kow5trwagtxy42do@topoi.pooq.com> Message-ID: <20210228034650.ecmjfi4b3dnvdgq2@topoi.pooq.com> On Sun, Feb 28, 2021 at 02:51:48AM +0000, Jay K wrote: > Every time I almost convince myself to get out of the build system business, I am stuck on the useful simple ?standalone? feature. > > I haven?t seen any other like it, yet it so simple and useful. > > I will enquire/investigate again cmake though. > Our platform reach is also hard to compete with but maybe no matter or not so much. > I.e. I would prefer to preserve Aix, Irix, Osf,Hpux,Solaris. True. > > - Jay > ________________________________ > From: M3devel on behalf of Hendrik Boom > Sent: Saturday, February 27, 2021 6:45:50 PM > To: m3devel at elegosoft.com > Subject: Re: [M3devel] setjmp, _setjmp, sigsetjmp et. al.? > > On Wed, Feb 24, 2021 at 07:12:26AM +0000, Jay K wrote: > > > > I've long considered, but never done much about, the idea that we should > > be producing something that is actually input to autoconf/automake/libtool, or cmake. > > > > We could generate *that* input. I know they are all ugly and slow, but > > they do nicely delegate problems to others, including hypothetical > > support for systems we haven't seen. > > > > And yes, really, I get it, they are disliked. > > I do get the impression that cmake is less disliked than > autoconf/automake/libtool, but never having used it myself, I have > no sense of my own about it. > > -- hendrik > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fm3lists.elegosoft.com%2Fmailman%2Flistinfo%2Fm3devel&data=04%7C01%7C%7C37122f23bcb34b3d976708d8db92fffc%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637500771691781168%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ZDEEMvPGaQFM4zQYKG7hkV7fjpjpnJrORfop7ZiVrqM%3D&reserved=0 From jayk123 at hotmail.com Sun Feb 28 06:10:41 2021 From: jayk123 at hotmail.com (Jay K) Date: Sun, 28 Feb 2021 05:10:41 +0000 Subject: [M3devel] cooperative suspend? In-Reply-To: <20210228032729.x7furcpmapp53ukm@topoi.pooq.com> References: , <20210228032729.x7furcpmapp53ukm@topoi.pooq.com> Message-ID: Yes, that was my short email. Cooperative suspend is not trivial. You have to insert some polling on function entry/exit and in loops. You have to something? when you exit from code in which you insert polling to code that you don't insert polling. Like save context and mark the thread somehow. And then upon return, or enter a callback, you have wait for resume. All w/o being too inefficient. Preemptive suspend has a great efficiency to it, the code generally does nothing, no polling, no transitions in and out of suspend-aware code, etc. And, on a somewhat separate axis, free to store traced refs in registers, etc. Can anyone tell a complete story? I don't know exactly how to make this work, I'm sorry to say. - Jay ________________________________ From: Hendrik Boom Sent: Sunday, February 28, 2021 3:27 AM To: Jay K Cc: m3devel Subject: Re: [M3devel] cooperative suspend? On Sat, Feb 27, 2021 at 07:58:31AM +0000, Jay K wrote: > I was trying out cm3 on usermode-only qemu RiscV. > It failed to send sigsuspend. > > system qemu works, albeit much slower. > > So this reminds me, what is the thinking on cooperative suspend? > > This remains a goal? Isn't it necessary to put processes into a state where the garbage collector knows how to examine them/ -- hendrik -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sun Feb 28 06:46:49 2021 From: jayk123 at hotmail.com (Jay K) Date: Sun, 28 Feb 2021 05:46:49 +0000 Subject: [M3devel] socklen_t int vs. size_t Message-ID: commit ac61f634c7cf87409d1bd2c6bfb2ceaf84abb98c Author: peter mckinna Date: Wed Feb 17 10:44:11 2021 +1100 Fix socklen_t - revert to previous definition. There seems some confusion regarding the C type of socklen_t. If it's not 32 bits it breaks structure definitions sockaddr and if its not word size it asserts in function parameters. Linus absolutely says it should be type int or else it breaks NetBSD sockets. My intent is that we "never" directly call into C libraries, except that we write. For some definition of "C libraries". Obviously not all. In particular I got tired of translating some subset of platform-specific /usr/include for each platform, deciphering all the ifdefs and pragmas, etc. You know, I had Cygwin stat wrong and I'd corrupt stack. It was needlessly tedious error-prone work imho. So now there is an intermediate layer that is simple to read, we duplicate that in *.i3 files and then it calls down to the libc/syscalls, etc. I think this work was a success, but, it looks like I didn't quite finish that work. i.e. I didn't handle Unetdb.i3. (I looked at X and OpenGL at the time, and decided, well, they aren't really platform-specific.. and hopefully never change, and no "tricks" like renaming symbols.) So I propose I push that work along a bit more, and then we can chose socklen_t to be whatever we want. I favor size_t/INTEGER so I can be more sure to not introducing padding for alignment. i.e. everything should be integer if that is large enough, else longint. Ok? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sun Feb 28 07:03:03 2021 From: jayk123 at hotmail.com (Jay K) Date: Sun, 28 Feb 2021 06:03:03 +0000 Subject: [M3devel] ar cr vs. ar cru Message-ID: I don't remember all the reasons I did that. I recall, the ar/ranlib code used to be very platform specific. I wanted one portable thing for all. Like, always run ranlib, but ignore if it fails, 'cause maybe it doesn't exist. The u part, I don't know. Because that is what libtool does? Because some platforms did? I realize it warns, which is annoying. Documentation does not seem to motivate its use. C:\s\cm3\m3-sys\cminstall\src\config-no-install>git log -p Unix.common commit 04707630112aea4c06271684de3aba592607fd13 Author: peter mckinna Date: Wed Feb 17 15:26:29 2021 +1100 Updates for llvm llc and opt ... - ret_code = try_exec("@ar", "cru", lib_a, objects) + ret_code = try_exec("@ar", "cr", lib_a, objects) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sun Feb 28 07:15:37 2021 From: jayk123 at hotmail.com (Jay K) Date: Sun, 28 Feb 2021 06:15:37 +0000 Subject: [M3devel] socklen_t int vs. size_t In-Reply-To: References: Message-ID: I guess the Unetdb .i3 content might be new actually, i.e. I hadn't missed it. Anyway, I suggest we use the usual/old form? I realize there is the lifetime management aspect, which I will look into more. i.e. probably copying to the m3 side. I.e. so that the new stuff is portable w/o worrying about the exact socklen_t type. I think it does vary per platform. - Jay ________________________________ From: M3devel on behalf of Jay K Sent: Sunday, February 28, 2021 5:46 AM To: m3devel ; Peter McKinna Subject: [M3devel] socklen_t int vs. size_t commit ac61f634c7cf87409d1bd2c6bfb2ceaf84abb98c Author: peter mckinna Date: Wed Feb 17 10:44:11 2021 +1100 Fix socklen_t - revert to previous definition. There seems some confusion regarding the C type of socklen_t. If it's not 32 bits it breaks structure definitions sockaddr and if its not word size it asserts in function parameters. Linus absolutely says it should be type int or else it breaks NetBSD sockets. My intent is that we "never" directly call into C libraries, except that we write. For some definition of "C libraries". Obviously not all. In particular I got tired of translating some subset of platform-specific /usr/include for each platform, deciphering all the ifdefs and pragmas, etc. You know, I had Cygwin stat wrong and I'd corrupt stack. It was needlessly tedious error-prone work imho. So now there is an intermediate layer that is simple to read, we duplicate that in *.i3 files and then it calls down to the libc/syscalls, etc. I think this work was a success, but, it looks like I didn't quite finish that work. i.e. I didn't handle Unetdb.i3. (I looked at X and OpenGL at the time, and decided, well, they aren't really platform-specific.. and hopefully never change, and no "tricks" like renaming symbols.) So I propose I push that work along a bit more, and then we can chose socklen_t to be whatever we want. I favor size_t/INTEGER so I can be more sure to not introducing padding for alignment. i.e. everything should be integer if that is large enough, else longint. Ok? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sun Feb 28 11:14:25 2021 From: jayk123 at hotmail.com (Jay K) Date: Sun, 28 Feb 2021 10:14:25 +0000 Subject: [M3devel] coroutine gap In-Reply-To: <20210228025157.lla7v26ahe5fjr2d@topoi.pooq.com> References: , <20210228025157.lla7v26ahe5fjr2d@topoi.pooq.com> Message-ID: Yes but volatile can be overkill on non-x86. I.e. insert CPU barrier. Alloca might work. Might. Though again, compiler intrinic, maybe optimized away l. - Jay ________________________________ From: M3devel on behalf of Hendrik Boom Sent: Saturday, February 27, 2021 6:51:57 PM To: m3devel at elegosoft.com Subject: Re: [M3devel] coroutine gap On Wed, Feb 24, 2021 at 10:43:40AM +0000, Jay K wrote: > void * > ContextC__PushContext(Context *c) > { > auto char a[STACK_GAP]; > > /* the purpose of the gap is to allow other routines to do some small > amount of work between when we return and the next GC event, > without clobbering the context we are about to push */ > > (void)memset(a, 0, STACK_GAP); > > return ContextC__PushContext1(c); > } > > > This is not convincing. > memset is typically builtin to the compiler, so it is not some extern function > the compiler does not understand. > It will just optimize this away. Can a be declared volatile if we really need it? > > And "auto" is redundant, and repurposed by C++. > I've heard of people using it in the original meaning, but never seen it. > > - Jay > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fm3lists.elegosoft.com%2Fmailman%2Flistinfo%2Fm3devel&data=04%7C01%7C%7C183d0779236743fc259308d8db93e733%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637500775582804266%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=WvlBf57eW0CsrX23TtnwbH%2F3vyZQL7LmIOp2UiKP4w4%3D&reserved=0 _______________________________________________ M3devel mailing list M3devel at elegosoft.com https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fm3lists.elegosoft.com%2Fmailman%2Flistinfo%2Fm3devel&data=04%7C01%7C%7C183d0779236743fc259308d8db93e733%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637500775582804266%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=WvlBf57eW0CsrX23TtnwbH%2F3vyZQL7LmIOp2UiKP4w4%3D&reserved=0 -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.mckinna at gmail.com Sun Feb 28 11:17:44 2021 From: peter.mckinna at gmail.com (Peter McKinna) Date: Sun, 28 Feb 2021 21:17:44 +1100 Subject: [M3devel] Parallel build option Message-ID: I know this might sound controversial, but does it make more sense for the parallel build option to be -j rather than -pb just to be consistent with make, ninja and the others? A bit pedantic I know. But I was playing around with it a fair bit just recently while trying to fix the -times function for parallel builds. (They are still not accurate but are better than 0.1 secs for every pass). Dont get me wrong. I think it's brilliant. Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: